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

分析类、分析模型 1、面向对象分析概念 分析类：边界类、控制类、实体类 2、基于用例的分析建模 识别分析类 定义交互行为 建立分析类图 检查分析模型 分析类 分析类的概念 –在分析模型中，分析类是概念层次上的内容，用于描述系 统中较高层次的对象。 –分析类直接与应用逻辑相关，而不关注于技术实现的问题。 分析类的类型 –实体类：表示系统存储和管理的永久信息 –边界类：表示参与者与系统之间的交互 –控制类：表示系统在运行过程中的业务控制逻辑 实体类 实体类 –描述必须存贮的信息及其相关行为 –通常对应现实世界中的“事物” 实体类与数据库中的表对应，类的实例对应于表中的一条记录；类中的属性和记录中的字段对应。 实体类的UML表示 边界类 边界类 –描述外部的参与者与系统之间的交互 –类型：用户界面、系统接口、设备接口 边界类是系统的用户界面，直接跟系统外部参与者交互，与系统进行信息交流。如网上购物系统中登陆子功能里的登录页面（login.html或index.jsp） 边界类的UML表示 控制类 控制类 –描述一个用例所具有的事件流控制行为 –实现对用例行为的封装，将用例的执行逻辑与边界和实 体进行隔离 控制类是控制系统中对象之间的交互，通常每个用例都是一个控制类。 控制类的UML表示 课堂作业 图中的实体类为： 图中的控制类为： 图中的边界类为： 内容提纲 1、面向对象分析概念 分析类：边界类、控制类、实体类 用例实现 2、基于用例的分析建模 识别分析类 定义交互行为 建立分析类图 检查分析模型 分析建模过程 理解用例模型 –理解用例模型和词汇表，适当补充系统内部情况的描述 识别分析类 –找出可能的能够执行用例行为的分析类 定义交互行为 –将用例行为分配到分析类中 建立分析类图 –确定分析类的关键属性和责任，定义分析类之间的关系 检查分析模型 示例：MiniLibrary 补充用例描述 补充用例描述 –为了发现分析类，有必要补充说明系统的内部行为，即系 统内部必须做什么才能响应外部的要求。 –可能的情况 ?用例描述的内容足够充分，不用补充直接可用； ?现有事件流中没有明确定义系统内部应该执行的行为，直接在现有用 例描述中作出补充行为； ?独立于原始用例描述系统的内部行为。 注意：没有必要规定系统的哪些部分完成哪些特定任务。 MiniLibrary：补充用例描述 举例：“登记还书”用例 识别分析类 识别边界类 –通常，一个参与者与一个用例之间的交互或通信关联对应 一个边界类。 识别分析类 识别边界类应当注意的问题 –边界类应关注于参与者与用例之间交互的信息或者响应的 事件，不要描述窗口组件等界面的组成元素； –在分析阶段，力求使用用户的术语描述界面； –边界类实例的生命周期并不仅限于用例的事件流，如果两 个用例同时与一个参与者交互，那么它们有可能会共用一个边界类，以便增加边界类的复用性。 MiniLibrary：识别边界类 识别分析类 识别控制类 –控制类负责协调边界类和实体类，通常在现实世界中没有 对应的事物。 –一般来说，一个用例对应一个控制类。 识别分析类 识别控制类应当注意的问题 –当用例比较复杂时，特别是产生分支事件流的情况下，一 个用例可以有多个控制类。 –在有些情况下，用例事件流的逻辑结构十分简单，这时没 有必要使用控制类，边界类可以实现用例的行为。 ?举例：MiniLibrary系统中的用例“登录” –如果不同用例包含的任务之间存在着比较密切的联系，则 这些用例可以使用一个控制类，其目的是复用相似部分以便 降低复杂性。 ?通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控 制类，再分析这些控制类找出它们之间的共同之处。 MiniLibrary：识别控制类 识别分析类 识别实体类 –实体类通常是用例中的参与对象，对应着现实世界中的“事物” 识别分析类 识别实体类应当注意的问题 –实体类的识别质量在很大程度上取决于分析人员书写文档 的风格和质量； –自然语言是不精确的，因此在分析自然语言描述时应该规 范化描述文档中的一些措辞，尽量弥补这种不足； –在自然语言描述中，名词可以对应类、属性或同义词等多 种类型，开发人员需要花费大量的时间进行筛选。 思考：如