第二部分软件需求分析与建模面向对象分析.ppt

注意，用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。用例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。脚本是系统的一次具体执行过程。例如，在自动售货机系统中，张三投入硬币购买矿泉水，系统收到钱后把矿泉水送出来，上述过程就是一个脚本。又如：李四投币买可乐，但是可乐已卖完了，于是系统给出提示信息并把钱退还给李四，这个过程是另一个脚本。第126页，共198页，星期日，2025年，2月5日3.行为者（参与者）行为者是指与系统交互的人或其他系统，它代表外部实体。参与者既可以是使用该系统的用户，也可以是与系统交互的其他外部系统、硬件设备或组织机构。行为者代表一种角色，而不是某个具体的人或物。事实上，一个具体的人可以充当多种不同角色。第127页，共198页，星期日，2025年，2月5日如何确定执行者：1、谁使用系统的主要功能(主执行者)?2、谁需要从系统获得对日常工作的支持和服务？3、需要谁维护管理系统的日常运行（副执行者）？4、系统需要控制哪些硬件设备？5、系统需要与其它哪些系统交互？6、谁需要使用系统产生的结果（值)？第128页，共198页，星期日，2025年，2月5日在用例图中用直线连接行为者和用例，表示两者之间交换信息，称为通信联系。行为者触发（激活）用例，并与用例交换信息。单个行为者可与多个用例联系；反之，一个用例也可与多个行为者联系。实践表明，行为者对确定用例是非常有用的。面对一个大型、复杂的系统，要列出用例清单往往很困难，可以先列出行为者清单，再针对每个行为者列出它的用例。这样做可以比较容易地建立起用例模型。第129页，共198页，星期日，2025年，2月5日4.用例之间的关系UML用例之间主要有扩展和使用两种关系，它们是泛化关系的两种不同形式。（1）扩展关系向一个用例中添加一些动作后构成了另一个用例，这两个用例之间的关系就是扩展关系。后者继承前者的一些行为，通常把后者称为扩展用例。如：自动售货机系统。把提供售罐装饮料的常规动作放在“售货”用例中，而把售散装饮料的非常规动作放置于“售散装饮料”用例中。这两个用例之间的关系就是扩展关系。第130页，共198页，星期日，2025年，2月5日含扩展和使用关系的用例图第131页，共198页，星期日，2025年，2月5日（2）使用关系当一个用例使用另一个用例时，这两个用例之间就构成了使用关系。如果在若干个用例中有某些相同的动作，则可以把这些相同的动作提取出来单独构成一个用例（称为抽象用例）。当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例中的所有动作。结论：（1）在描述一般行为的变化时采用扩展关系；（2）在两个或多个用例中出现重复描述又想避免这种重复时，可以采用使用关系。第132页，共198页，星期日，2025年，2月5日一个用例模型由若干幅用例图组成。创建用例模型的工作包括：定义系统，寻找行为者和用例，描述用例，定义用例之间的关系，确认模型。其中，寻找行为者和用例是关键。1.寻找行为者 a.谁将使用系统的主要功能（主行为者）？b.谁需要借助系统的支持来完成日常工作？c.谁来维护和管理系统（副行为者）？d.系统控制哪些硬件设备？e.系统需要与哪些其他系统交互？f.哪些人或系统对本系统产生的结果感兴趣？第133页，共198页，星期日，2025年，2月5日2.寻找用例一旦找到了行为者，就可以通过请每个行为者回答下述问题来获取用例：a.行为者需要系统提供哪些功能？行为者自身需要做什么？b.行为者是否需要读取、创建、删除、修改或存储系统中的某类信息？c.系统中发生的事件需要通知行为者吗？d.行为者需要通知系统某些事情吗？e.从功能观点看，这些事件能做什么？f.行为者的日常工作是否因为系统的新功能而被简化或提高了效率？第134页，共198页，星期日，2025年，2月5日还有一些不是针对具体行为者而是针对整个系统的问题，也能帮助建模者发现用例。例如：g.系统需要哪些输入输出？输入来自何处？输出到哪里去？h.当前使用的系统（可能是人工系