分析模型.ppt

分析模型 ncreating an analysis model nanalysis model template nuse case realizations ndocumenting classes ndistributing behavior nsequence diagrams nview of participating classes nsummary creating an analysis model analysis model template noverviews包 ndomain model diagram nkey abstractions diagram nkey controllers diagram nui diagram nanalysis building blocks包 n$functional.area n$use.case n创建功能区域包 use case realizations n用例表示的是系统应当“做什么” n用例实现表示的是系统“如何做”用例中所规定的 功能 n将用例与它们的实现分开，使得可以对每一项进 行独立管理 n对于一个相同的功能，这些系统可能有多个实现 n在uml中，用例实现使用协作（collaboration）来 表示，画作一个虚线的椭圆 n在分析时，要为用例模型中标识出的每个用例都 创建用例实现 n创建用例实现 发现类 nibm rup主张通过寻找边界类、控制类 和实体类来为待开发的系统寻找类 n这三种衍型与mvc的观点一致 n边界类、控制类和实体类如下图所示 实体类 n实体类用来为那些通常长期存在的信息和相关行为建模 n这种类可能反映了真实世界的实体，也可能是系统内部为 了完成任务而产生的实体 n通常，它们独立于应用，这就意味着它们可以用在不止一 个应用中 n第一步是检查所标识的用例的事件流中所记载的职责(例如 ，系统必须做什么) n实体类通常是系统完成某些职责所需要的那些类 n使用名词或名词短语来描述职责会是一个好的开始 n必须对最初列出的名词进行过滤，因为其中可能包含了一 些问题域之外的名词、含义相同而只是语言表达不同的名 词、冗余的名词和描述类结构的名词 边界类 n边界类处理的是系统环境和系统内部之间的通信 n它们为用户或其他系统提供了接口(比如参与者的 接口) n它们构成了系统中依赖于环境的部分。边界类用 来为系统接口建模 n通过检查每个“自然的参与者应用场景”对来发 现边界类 n在分析模型中所发现的边界类通常是高层次的 n例如，可以为一个窗口建模，但不要为每个对话框和按 钮建模 n在此时，你应该记载用户接口的需求，而不应实现这些 接口 边界类（续） n用户接口需求往往非常模糊 n似乎使用了太多的用户友好和灵活性之类的术语 n对于不同的人，用户友好意味着不同的东西 n通过采用原型技术和故事板技术使客户能够得到系统的感 受，并真正地捕获用户友好的意义 n要捕获边界类的结构和行为 n在设计期间，应对这些类进行精炼，从而考虑到所选中的 用户接口机制如何实现它们 n为了便于与其他系统进行通信，也可以增加边界类 n在设计期间，要对这些类进行精炼，从而考虑所选中的通 信协议 控制类 n控制类用来为专门用于一个或多个用例的 有序行为进行建模 n控制类用来协调事件，这些事件是实现用 例中所规定的行为所必需的 n可以把控制类看成一个“运行的”或“可执 行的”用例，它们代表了用例的动态方面 n控制类通常是依赖于应用的类 控制类（续） n在分析模型中，为每个用例增加控制类，控制类负责用 例中的事件流 n控制类的使用是非常主观的 n很多专家都觉得：控制类的使用所导致的结果就是将行为与数据 相分离 n如果一个控制类所做的不只是序列化，那么它所做的就太多了 n例如，在课程注册系统中，学生选择所提供的课程，并 且如果课程可用的话，学生就被加入到这个课程中 n谁知道如何增加学生呢?是控制类还是课程类? n正确的回答是课程类 n控制类知道什么时候应当加入学生；而课程类知道如何 加入学生。如果控制类不仅知道什么时候加入学生，还 知道如何加入学生，这就不是一个好的控制类 撰写类的文档 n应该对类建立文档 n文档应当陈述类的目的，而不应陈述类的结构 n例如，一个student类应当有这样的文档：学生就是现在注册在大学 上课的人 n如果为类命名和编写文档很困难，那就说明它可能不是一个 好的抽象 n可以标识出名称并给出清楚简洁的定义好的候选类 n可以标识出名称，但它的定义和另一个类相同结合这两个类 n可以标识出名称，但需要很大的篇幅才能讲清楚它的目的分解类 n不能确定名称或定义需要做进一步的分析才能确定正确的抽象 寻找esu课程注册系统中的 边界类、控制类和实体类 n“浏览课程目录”用例 n主要能力是让学生能够浏览课程的目录 n寻找边界类 n用例的规格说明表明：学生可以按照课程浏览目录，也 可以搜索特定的所提供的课程 n将创建一个叫做browsecataloghome的边界类，以使学 生能够进行这一决策 n因为有两种不同的浏览目录的方法，所以还要增加两个 额外的边界类：courselist和courseofferinglist n最后，学生可以选择查看某个特定courseoffering的详 细信息，所以创建一个courseofferingdetail边界类 n增加一个控制类 n对于这个用例，要增加个控制类来管理其事件流，我 们把它叫做coursecatalog 寻找实体类 n寻找实体类的第一步是在用例规格说明中寻找名词 n可以找到如下这些名词：课程目录、课程、所提供 的课程、学科领域、课程信息和搜索条件（即 course catalog, course, course offering, subject area, course information, and search criteria） n接着研究每个名词以查看它是否能构成一个好的类 n如果试着写出这些名词的文档，通常就可以确定它们是 否适合作为候选类 寻找实体类（续） n课程目录控制类 n课程在大学中要学习的一个特定领域。课程要按照 学科领域来组织 n课程信息一个课程的详细信息 n所提供的课程一个已经为某个学期分配了具体时间 和位置的课程 n学科领域一种对课程进行分类的方法(比如，数学) n搜索条件你想要找的所提供的课程的编号 n根据实体类的定义并运用上面这些定义，可以得 出这样的结论：course(课程)和courseoffering( 所提供的课程)是好的候选实体类 sequence diagram n显示了按照时间顺序排列的对象交互 n复杂性 n让它们保持简单 n对于条件逻辑的处理 n可以通过检查sequence diagram来评估 对象模型 “浏览课程目录”用例实现中的行为 n两个sequence diagram n一个是按照分类浏览 n一个是搜索某个所提供的课程 n分析模型模板中已经包含了 n用于基本流的图 n用于备选流的图 ncombined fragment 结构 n使用类的属性来描述对象的结构 参与类的视图 n参与类图(participating classes diagram)这一视图显 示了用于特定用例实现的所有类和类之间的关系 n将使用这个图来创建类之间的关系 n可以通过检查用于该用例实现的序列图来寻找关系 n如果在两个对象之间存在一个消息，那么在这两个类之间 必然存在一个关系 n在开发的早期阶段，会使用两种关系：关联和聚集 小结 n用例表示的是系统将做“什么”。用例实现表示的是系统“如何”完成用例 中所规定的功能 n对象是一个具有定义良好的边界并对应用有意义的概念、抽象或事物 n系统中的每个对象都有3个特性：状态、行为和标识符 n类描述了一组对象，它们有共同属性、共同行为(操作)、共同的与其他 对象的关系和共同的语义 n实体类为那些通常长期存在的信息和相关行为建模 n边界类处理的是系统环境和系统内部之间的通信 n控制类为专门用于一个或多个用例的有序行为而建模。控制类协调了实现用 例中所规定的行为而需要的事件 n通过在参与到用例实现中的分析类之间分配行为，可以提供用例中所规 定的功能 n序列图显示了按照时间顺序排列的对象交互 n使用类的属性来描述对象的结构 n参与类的视图这一图显示了用于特定用例实现的所有类和类之间的关系 developerworks links na.4.1crain, a. the simple artifacts of analysis and design. developerworks, june 2004: http:/www- 128./developerworks/rational/library/4871.html na.4.2evans, g. getting from use cases to code (two-part series). developerworks, july 2004. chapter 4: /developerworks/rational/library/5 383.html na.4.3bell, d. uml basics: the class diagram. developerworks, september 2004: http:/www- 128.i