UML分析类状态图基本和画法.ppt

《UML分析类状态图基本和画法.ppt》由会员分享，可在线阅读，更多相关《UML分析类状态图基本和画法.ppt（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、分析类、分析模型,1、面向对象分析概念 分析类：边界类、控制类、实体类 2、基于用例的分析建模 识别分析类 定义交互行为 建立分析类图 检查分析模型,分析类,分析类的概念 在分析模型中，分析类是概念层次上的内容，用于描述系 统中较高层次的对象。 分析类直接与应用逻辑相关，而不关注于技术实现的问题。 分析类的类型 实体类：表示系统存储和管理的永久信息 边界类：表示参与者与系统之间的交互 控制类：表示系统在运行过程中的业务控制逻辑,实体类,实体类 描述必须存贮的信息及其相关行为 通常对应现实世界中的“事物” 实体类与数据库中的表对应，类的实例对应于表中的一条记录；类中的属性和记录中的字段对应。 实

2、体类的UML表示,边界类,边界类 描述外部的参与者与系统之间的交互 类型：用户界面、系统接口、设备接口 边界类是系统的用户界面，直接跟系统外部参与者交互，与系统进行信息交流。如网上购物系统中登陆子功能里的登录页面（login.html或index.jsp） 边界类的UML表示,控制类,控制类 描述一个用例所具有的事件流控制行为 实现对用例行为的封装，将用例的执行逻辑与边界和实 体进行隔离 控制类是控制系统中对象之间的交互，通常每个用例都是一个控制类。 控制类的UML表示,课堂作业,图中的实体类为： 图中的控制类为： 图中的边界类为：,内容提纲,1、面向对象分析概念 分析类：边界类、控制类、实体

3、类 用例实现 2、基于用例的分析建模 识别分析类 定义交互行为 建立分析类图 检查分析模型,分析建模过程,理解用例模型 理解用例模型和词汇表，适当补充系统内部情况的描述 识别分析类 找出可能的能够执行用例行为的分析类 定义交互行为 将用例行为分配到分析类中 建立分析类图 确定分析类的关键属性和责任，定义分析类之间的关系 检查分析模型,示例：MiniLibrary,补充用例描述,补充用例描述 为了发现分析类，有必要补充说明系统的内部行为，即系 统内部必须做什么才能响应外部的要求。 可能的情况 用例描述的内容足够充分，不用补充直接可用； 现有事件流中没有明确定义系统内部应该执行的行为，直接在现有用

4、 例描述中作出补充行为； 独立于原始用例描述系统的内部行为。 注意：没有必要规定系统的哪些部分完成哪些特定任务。,MiniLibrary：补充用例描述,举例：“登记还书”用例,识别分析类,识别边界类 通常，一个参与者与一个用例之间的交互或通信关联对应 一个边界类。,识别分析类,识别边界类应当注意的问题 边界类应关注于参与者与用例之间交互的信息或者响应的 事件，不要描述窗口组件等界面的组成元素； 在分析阶段，力求使用用户的术语描述界面； 边界类实例的生命周期并不仅限于用例的事件流，如果两 个用例同时与一个参与者交互，那么它们有可能会共用一个边界类，以便增加边界类的复用性。,MiniLibrary

5、：识别边界类,识别分析类,识别控制类 控制类负责协调边界类和实体类，通常在现实世界中没有 对应的事物。 一般来说，一个用例对应一个控制类。,识别分析类,识别控制类应当注意的问题 当用例比较复杂时，特别是产生分支事件流的情况下，一 个用例可以有多个控制类。 在有些情况下，用例事件流的逻辑结构十分简单，这时没 有必要使用控制类，边界类可以实现用例的行为。 举例：MiniLibrary系统中的用例“登录” 如果不同用例包含的任务之间存在着比较密切的联系，则 这些用例可以使用一个控制类，其目的是复用相似部分以便 降低复杂性。 通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控 制类，再分析这

6、些控制类找出它们之间的共同之处。,MiniLibrary：识别控制类,识别分析类,识别实体类 实体类通常是用例中的参与对象，对应着现实世界中的“事物”,识别分析类,识别实体类应当注意的问题 实体类的识别质量在很大程度上取决于分析人员书写文档 的风格和质量； 自然语言是不精确的，因此在分析自然语言描述时应该规 范化描述文档中的一些措辞，尽量弥补这种不足； 在自然语言描述中，名词可以对应类、属性或同义词等多 种类型，开发人员需要花费大量的时间进行筛选。 思考：如何识别MiniLibrary的实体类？,MiniLibrary：识别实体类,定义交互行为,交互图可以将用例和分析对象联系在一起，实现将用例

7、的行为分配到所识别的分析类中，并且帮助开发人员发现和补充前面遗漏的分析类。,MiniLibrary：“登记借书”基本流,MiniLibrary：“登记借书”基本流,MiniLibrary：分析类,将“登记还书”用例行为分配到相应的分析类之后，系统的一些分析类具有相应的职责,建立分析类图,定义关系 找出分析类之间的关联关系，并通过泛化实现复用。 定义属性 按照一般常识，找出对象的某些属性； 认真研究问题域，找出对象的某些属性； 根据系统责任的要求，找出对象的某些属性； 考虑对象需要系统保存的信息，找出对象的相应属性； 对象为了在服务中实现其功能，需要增设一些属性； 识别对象需要区别的状态，考虑是

8、否需要增加一个属性来 区别这些状态； 确定属性表示整体与部分结构和实例连接。,MiniLibrary：分析类图,检查分析模型,检查“正确性” 用户是否可以理解实体对象的术语表？ 抽象类与用户层次上的概念对应吗？ 所有的描述都与用户定义一致吗？ 所有的实体类和边界类都使用具有实际含义的名词短语吗？ 所有的用例和控制类都使用具有实际含义的动词短语吗？ 所有的异常情况都被描述和处理了吗？ 是否描述了系统的启动和关闭？ 是否描述了系统功能的管理？,检查分析模型,检查“完整性” 每一个分析类都是用例需要的吗？它在什么用例中被创建、 修改和删除？是否存在边界类可以访问它？ 每一个属性是在什么时候设置的？其类型是什么？它是限定 词吗？ 每一个关系是在什么时候被遍历？为什么选定指定的重数？ 一对多和多对多的关系能被限定吗？ 每一个控制类对象是否有必要访问参与用例的对象？,检查分析模型,检查“一致性” 类或用例有重名吗？ 具有相同名字的实体表示相同的现象吗？ 所有的实体都以同样的细节进行描述吗？ 是否存在具有相同属性和关系却不在同一继承层次的对象？ 检查“可行性” 系统中有什么创新之处？建立了什么计划或原型来确保这 些创新的可行性？ 性能是否符合可靠性需求？这些需求是否已被运行在指定 硬件上进行原型验证？,