第5章 系统模型精要.ppt

常见的软件系统模型 上下文模型 交互模型 1 用例建模，2 时序图 结构模型 1 类图，2 泛化，3 聚合 行为模型 1 数据驱动的建模，2 事件驱动模型 上下文模型示例2： MHC-PMS系统的上下文模型 上下文模型通常表示某一环境包括几个其它自动系统，然而并没有描述与其它系统之间的关联关系，通常，和业务系统结合在一起使用，以描述系统之间的关联。 非自愿隔离的过程模型 5.2.1 用例模型 用例图用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的关系。 参与着可以是人，可以是另外一个系统。 用例图仅仅从使用者的角度描述系统中的信息 1 参与者 参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由他们参与用例时所担当的角色来代表。 在图形上，参与者用人形图符表示。 识别参与者 参与者的角色 参与者的角色 系统的启动者 系统的服务者 系统服务的接收者 例如ATM系统中，利用ATM提款的用户，银行内部系统， 收到现款的用户则分别是 系统的启动者，系统的服务者，系统服务的接收者。 使用参与者的识别，有利于建模人员的对系统的分析和设计。 练习 识别“超市进销存管理系统”中的参与者 2 用例 用例是一组连续的操作，当用户使用系统来完成某个过程时出现，它是外部可见的系统功能单元。通过将这些不同功能单元的组合，就构成了对系统总体需求的描述。 用例要点:1.位于系统??--必须由系统运行2.目标导向??--用例运行必须有所目的3.止于边界??--可以观测到结果,并且是在边界和外部有所交互的4.用户观点??--参与者观测5.粒度???--是一组有共同目标或者可以类聚的目标的实例组成 用例的概念 用例的目标是定义一个或整个系统的行为，隐藏了系统的内部结构。一个系统的全部用例分割和覆盖它的行为，每个用例代表量化了的，具有一定功能性的集合。 用例的命名很重要：尽量用动名词短语，例如提取货款，验证身份，其侧重于目的，轻过程。 识别用例 识别用例最好的办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。使用这种策略的过程中可能会找出一个新的参与者，这对完善整个系统建模很有帮助。 识别用例时有用的几个问题 在识别用例的过程中，通过以下的几个问题可以帮助识别用例： （1）特定参与者希望系统提供什么功能？ （2）系统是否存储和检索信息？如果是，这个行为由哪个参与者触发? （3）当系统改变状态时，通知参与者吗？ （4）存在影响系统的外部事件吗？ （5）是哪个参与者通知系统这些事件？（系统需要什么样的输入输出） 用例识别练习 ATM自动柜员机系统是由计算机控制的银行自动出纳系统，主要服务于活期储蓄，实现客户自助服务的电子化设备。统一建模语言UML（Unified Modeling Language）是面向对象技术的一个重要应用，也是软件工程环境中对象分析和设计的重要工具。通过UML对ATM自动取款机建模，实现查询余额、取款、存款、转账、更改密码等业务，根据需求还可以进一步扩展具体功能。 3 泛化关系 用例与参与者之间的连线称为关系，关系也称为关联或通信关联，它表示参与者与用例之间的通信。一般情况下，不用带箭头的直线表示信息流动的方向，因为信息流动是双向的。 如果使用箭头，则特意的表示信息的发起者或接受者；如P77 图5-4. 泛化用例 泛化将特化用例和一般用例联系起来。即子用例是父用例的特化。子用例除了具有父用例的特性外，还具有自己的另外的特征。 例如“身份验证用例”。 口令验证； 指纹验证； 其它方式，密码卡方式等。 泛化用例 泛化可以分层，父用例的子用例可以有自己的子用例 泛化参与者 参与者也可以进行泛化。以图书管理系统中管理员为例，图书管理系统的管理员的参与者有Administrator，Librarian，而Manager则能表示Administrator，Librarian两者的泛化。 4 用例描述 在描述用例时，我们可以用文字来描述，也可以用其他图形来描述，例如，顺序图或者活动图等等。下面给出了一个RUP中推荐的描述用例的完整的结构： 名称：名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。 标识符 [可选]：唯一标识符，如 UC1701，在项目的其他元素（如类模型）中可用它来引用这个用例。 说明：概述用例的几句话。 参与者 [可选]：与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解。 状态 [可选]：指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。 频率：参与者访问此用例