第8章面向对象分析.ppt

1,第8章 面向对象分析,领域分析 使用实例的需求获取 用类进行建模 对象-行为模型 RUP分析活动 OO分析小结,2,8.1 领域分析,1、领域分析的概念 面向对象的系统分析可以发生在许多不同的抽象层次。在业务或企业级层次，可定义模拟整个业务的类、对象、关系和行为。在业务域层次，可定义描述某特殊的业务域的工作的对象模型和行为模型；在应用层次，建模着重于特定的用户需求。 Firesmith对软件领域分析的定义是：领域分析(Domain Analysis)指特定应用领域中公共需求的标识、分析和规约，即发现或创建那些可广泛应用的类，其目的使它们在应用域中多个项目间能被复用。领域分析的角色是设计和建造可复用构件（类似于制造环境中工具制造者的角色），它们被很多相似但不一定是相同的应用开发的人所使用。,3,Lethbridge的定义是：领域分析是软件工程师了解背景信息的过程。为了理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策，软件工程师必须了解使用该类软件的一般性商业和技术领域中足够的信息。 2、领域分析过程的活动 （1）定义将被调查的领域 分离感兴趣的业务域、系统类型或产品范畴，抽取OO和非OO的“项”。OO项包括：现存OO应用的类的规约、设计和代码，支持类（如GUI类或数据库访问类），和领域相关的构件库以及测试案例。非OO项包括：政策、规程、计划、标准，非OO应用文档和构件。,4,（2）对从领域中抽取出来的项进行分类并建立分类层次。 （3）收集领域中应用的代表性样本。 （4）分析样本中的每个应用 标识候选的每个可复用对象。 指明对象被标识为可复用的理由。 定义对象的适应性。 估算在领域中复用这些对象的应用的百分率。 使用配置管理技术控制这些对象。 （5）为对象开发分析模型。,5,3、领域分析的价值 领域分析除了为软件复用奠定基础外，还为较低抽象层次的一般的面向对象分析带来如下好处： 快速开发。有助于集中精力关注最重要的问题，更有效地与相关人员进行交流，可以更快的确定需求。 优化系统。了解领域的细节有助于保证所采纳的解决方案更有效地解决用户的问题。会少犯错误，知道应该遵循那些规程和标准。领域分析给出一个应用领域的总体视图，会引导出更好的抽象从而改进设计。 有了领域知识，就可以洞察新兴趋势及进一步开发的机会，有助于创建适应性更强的系统。 了解通用性和特殊性，有助于创建出具有更好的可重用性和更宽的销售市场的软件。,6,专家提出，没有坚实的领域分析，任何重大的软件项目都不应该进行。对应用领域的深入理解能极大的提高成功的几率。许多非常成功的软件产品的开发人员以前都在业务领域工作过段时间，对实际需要有着深切的感受。 一旦对领域有了真正的理解，就可进行某一个项目（或产品）的需求分析，包括定义待解决的问题以及开发什么软件来解决它。然而，领域分析永远也不应该结束：开发人员有责任在开发过程中不断增进他们的理解，后续版本的系统扩充通常需要对子领域进行进一步的领域分析。,7,8.2 使用实例的需求获取,面向对象的分析过程并不从考虑对象开始，而是从对系统将被使用的方式的理解开始。如果系统是人机交互的，则考虑被人使用的方式；如果系统是涉及过程控制的，则考虑被机器使用的方式；如果系统是协调和控制应用的，则考虑被其他系统使用的方式。一旦使用的场景(scenario) 被定义，软件的建模活动就开始了。 1、use-case（用例或使用实例） 在OOA中，用例是分析模型的第一个元素的基础，以终端用户的观点对系统建模。 用例在需求获取时创建，应达到下列目标： 通过定义由终端用户和开发人员共同认可的使用场景，定义系统的功能和运行需求。 场景是用例的一个实例，表达用例的一个特定发生，在特定的时间，使用特定的数据进行操作 。,8, 提供清楚的、无二义性的终端用户和系统如何相互交 互的描述。 提供确认测试的基础。 用例的描述以及用例图构成了参与者与系统交互的用 例模型 （1）用例的描述 建议：其中只有名称和步骤是必须的。 名称(name) 参与者(actor) 目标(goal) ： 参与者要完成的任务。 前置条件(precondition)： 列出参与者启动用例前所有必需为真的条件。 相关用例(related use cases)： 列出可能是此用例的扩展、包含的用例。,9, 步骤(step)： 用两列的格式描述用例的每一步（见例）。 后置条件(postcondition)： 用例完成后系统所处的状态。 例1：描述应用程序中打开文件的用例 用例：打开文件 步骤： 参与者动作 系统响应 选择“打开”命令 显示“打开文件”对话框 指定文件名 确认选择 关闭对话框,10,例2、图书管理系统借书 用例 用例：为借阅者借出一本书 参与者：借书员 目标：帮助借阅者借阅书籍并确保输出正确的借出记录 前置条件：借阅者必须有一张有效的借书卡并且没有欠费； 该书藉必须具有有效的条形码并且不是来自于 参考文献区。 步骤： 参与者动作 系统响应 扫描书籍和借书卡 显示允许借阅的信息 在书籍上标记到期日期 确认借出开始 显示借出已被记录的确 认的信息 后置条件：系统有一个该书藉被借出以及到期时间的记录,11,例3、某商店POS系统用例描述实例,用例： 购买商品 参与者：顾客（发起者）、收款员 类型： 主要的 描述： 顾客带着所要购买商品到付款处，收款 员记录商品信息并收款。,用例： 启动/关闭系统 参与者：管理员 类型： 主要的 描述： 管理员接通一台POS机电源，检查时 间、日期正确性，检查完成后，系统处 于就绪 状态，以备收款员使用。,12,（2）用例图 用来显示一系列用例和参与者之间的关系，有助于开发人员表达系统功能的不同的抽象层次的描述。,交互,房主,传感器,配置,监测,SafeHome高层用例图,13,启动/关闭系统,房主,输入密码,询问区域状态,SafeHome交互用例图,询问传感器状态,按紧急按钮,验证密码,询问传感器,include,include,include,(参考教材1 P415),14,用例分析是理解和组织系统应完成任务的直观方法。它还可以用来驱动开发过程。特别是，用例： 可以帮助定义系统的范围，即必须做什么和不必做什么。 可用来计划开发过程。确定的用例数量决定了项目的大 小，开发进度可用完成的用例数量来测量。 用来开发和确认需求。 构成测试用例定义的基础。 可用来构造用户手册。 但是用例也不是万能的！注意：（Lethbridge的观点） 用例必须经确认。用例集应是完全的、表达是一致的和 明确的。 用例分析不一定覆盖到功能需求的所有方面。如，不被 参与者触发的活动不会出现在用例中。 当软件需求来自用例时，软件往往只是简单的反映开发 软件前用户的工作方式，可能没有考虑到创新的解决方 案。,15,2、获取需求的主要活动 （1）确定参与者和用例 与用户一起确定与系统有交互活动的所有角色，并为每个角色设计用例。确定用例的准则： 每个用例都应该为其角色提供有价值的服务避免确定的用例太小；确保每个用例都向主要角色提供有价值的服务避免用例太大。 （2）定义用例的优先级 （3）描述每个用例 用例描述可有不同的抽象层次与描述模板。概要描述主要强调每个用例的主要功能。详细描述包括每个用例的事件流（如何开始，与角色如何交互，如何终止）、每个用例中所涉及到的对象（编入术语表）、执行一个用例所要求的非功能性需求等。,16,（4）建立用例图 用例图用来显示一系列用例和参与者之间的关系。它有助于表达系统功能的高层表述。 用例有特化、扩展和包含关系。特化的使用同类图。一个特化用例代表了几个相似用例，一个或多个特化提供了这些相似用例的细节。 使用包含关系减少用例之间的冗余。即 确定用例中可以被共享的功能。检查每个用例抽取出公共部分创建单独用例。 使用扩展关系区分事件的例外和事件的共有流程，即确定补充功能或可选功能。如果发现一个用例比较复杂，既包含了一般处理又包含了特殊处理，将特殊处理的部分抽取出来，创建单独的用例。,17,打开文件,用户,通过键入文件名打开文件,通过浏览打开文件,试图打开不存在的文件,浏览文件,extend,include,用例的特化、扩展和包含,18,（5）建立用户界面原型 在面向对象的软件开发中，用例模型和用户界面设计息息相关。用例模型创建后，就可确定参与者如何驱动用例，以及用例以什么形式向参与者提供信息。因此可开始用户界面原型化的迭代过程，和构造系统的其他部分并行进行。,19,8.3 用类进行建模,面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。在需求获取阶段已经建立了用例模型等阶段产品，但都是为了容易沟通信息，以用户语言描述的，存在着模糊、冗余、二义性、不一致性等问题。 系统分析阶段要进一步分析、完善前一阶段获取的需求，细化用例模型中的用例、确定系统中的对象、对象的静态和动态特征、对象间的关系及对象的行为约束，建立满足用户需求的、精确的、稳定的、易于维护的、便于后续设计的分析模型。,20,用例图：视图,功能模型：模型,分析模型：模型,类图：视图,对象模型：模型,顺序图：视图,状态图：视图,活动图：视图,动态模型：模型,分析模型的构成,21,几条通用的分析原则： （1）组装与分解相结合的原则 基本对象可组装成复杂对象，对复杂对象进行分解从而完成系统模型的细化。 （2）抽象化与具体化相结合的原则 数据抽象将数据及作用在其上的操作抽象成对象。过程抽象为对象的相互作用提供了依据。 抽象强调对象的本质和内在属性，忽视与问题无关的属性。而具体化指在细化过程中，描述对象的某些特性，加强系统模型的稳定性。 抽象化与具体化相结合可以使具体对象直接从抽象对象的定义中获得已有特性，而不必重复定义它们。,22,（3）封装原则 将对象的各种独立的外部特性与内部实现细节分开。对象接口定义要尽可能的与其内部工作状态相分离。封装有助于减少由于需求的改变而对整个系统所造成的影响。 （4）相关性原则 在分析中要考虑对象间的各种关联，包括静态结构的关联、动态特征的关联。这些关联是对象协作的基础。 （5）行为约束的原则 通过语义特征来刻画。表示了对象合法存在、对象合法操作应满足的条件，有助于深刻理解对象和系统。,23,一旦建立了系统的用例模型，则可以开始标识候选类，并指明它们的责任和协作。Wirfs-Brock等人提出了一种类-责任-协作者(Class-responsibility-collaborator,CRC)开发类图的卡片技术。该技术使用实际的或虚拟的索引卡片（参考教材P417)，为定义类提供较多的信息。其中责任是与该类相关的属性和操作，协作者是为一个类提供要完成的责任所需要的信息的那些类。通常，协作意味着对信息的请求或者对某种操作的请求。 在确定属性和操作时，可把它们列在卡片上。由于卡片的空间有限，使得每一个类都不能太复杂。如果不能在一张卡片上列出所有的职责，该类应分成两个相关的类。可在白板上自由移动卡片以组成类图，在卡片之间画线表示关联与泛化。低科技的卡片技术可能比操作软件用户界面要快，对开发人员通过会议讨论确定方案很有效。,24,1、标识类及对象 无论是面向对象分析还是面向对象设计与实现，建立类图都是核心技术。类图是定义其他图的基础，在该基础上用交互图、状态图等进一步描述系统其他方面的特性。 如何识别对象？对象以一系列不同形式展示自身：外部实体、事物、发生的事件、角色、组织单位、位置或结构。一种最简单的方法是从系统处理说明中找出名词。例如，在SafeHome的需求陈述中，找出相关的名词是：用户、传感器 、 控制面板、系统(安全系统)、 传感器编号、 传感器类型、密码、 电话号码、 传感器事件、 警报器 等。 这些候选的对象是否都可作为在系统中承担责任的有用对象？要根据一定原则筛选。见下表：,25,几条筛选特征: 例:SafeHome中潜在的对象及筛选理由 (1)保留的信息 潜在对象 选取理由 筛选理由 (2)需要的服务 用户 角色或外部实体 不符合1/2 (3)多个属性 传感器 外部实体 符合1-6 (4)公共属性 控制面板 外部实体 符合1-6 (5)公共操作 系统(安全系统) 事物或聚集对象 符合1-6 (6)基本的需求 传感器编号 事物或概念实体 不符合3 传感器类型 事物或概念实体 不符合3 密码 事物或概念实体 不符合3 电话号码 事物或概念实体 不符合3 传感器事件 事件 符合1-6 警报器 外部实体 符合1-6,几乎满足所有特征的对象才会被考虑为分析模型中的合法对象.,26,在RUP中，将对象分为三种类型： (1) 边界对象(或边界类) 是参与者与系统交互的接口，这些对象位于系统与外部世界的边界上，代表如界面窗口、通信接口、打印机接口、传感器等的抽象，用于阐明和收集系统的边界需求，这样，可把用户界面或通信接口的变化隔离在一个或多个边界类中。在分析问题域时，边界类仍保持较高的概念层次，说明通过交互所实现的目标就可以了。在设计活动中（如用户界面设计）才根据参与者操作需求，添加具体的边界对象。 (2) 控制对象(或控制类) 控制用例的流程，表示协调、顺序、事务处理以及对其他对象的控制（如分派任务给其他对象）。主要用来体现应用程序的执行逻辑，可以使得变化不影响用户界面和数据库中的表。,27,(3) 实体对象(或实体类) 负责保存长效且持久的信息。实体类大多数是直接从业务模型或 领域模型中相应实体类得到的。实体类一般表示为一种逻辑数据结构（通常映射为数据表格或文件），有助于开发人员理解系统所依赖的信息。实体对象不一定都是被动的，有时可能具有与它所表示的信息有关的复杂行为。实体对象能够将变化与它们所表示的信息隔离开。 在RUP的分析中，三类对象分别用下图表示：,边界对象,控制对象,实体对象,28,2、定义属性 类的属性与操作和该类在系统中承担的责任有关。属性表示了类的特性，即类必须保持的以完成软件目标的信息。属性的取值决定了对象可能的状态。 传感器有类型、编号、位置、颜色、重量、工作状态（关闭、待机、监控）、采样频率、报警阈值等特性，哪些与系统责任有关呢？ 定义属性的一些经验： 一般常识； 分析问题域，检查与对象相联系的形容词或名词短语； 责任； 保存管理信息； 有些属性在对象模型稳定之前可暂不考虑。,29,3、定义操作 操作反映对象的行为并以某种方式修改对象的属性。对象行为可理解为对象应展现的外部服务的总和。对象的行为分为三类： 对象生命周期中的创建、维护、删除行为。 计算行为 监控行为 通过这些行为体现对象的责任。对象以两种方式完成它们的责任： 使用它自己的操作去操作自己的属性， 对象和其他对象协作。 因此对象的操作可以有以下几种类型： 实现功能的操作：可追溯到用户需求。,30, 管理对象创建和删除的操作。在分析阶段，这些操作可 暂缓定义。 访问属性的操作。一个类的属性通常是私有的或受保护 的，只有通过该类提供的操作来访问。 辅助一个类完成其任务的操作，即协作操作。 如何定义操作呢？ 分析问题域：有哪些行为，找有关动词。 如“传感器被赋予一个编号和类型”。 系统的责任：找与责任有关的对象，这些对象为承担责任 应提供哪些服务。 分析类的状态转换，引起类状态转换的动作。 追踪一个用例的执行路线，如顺序图，通过对象间通信发 现操作。 因此类的有些操作是在对象-行为模型建立后才补充进来。下图是传感器类的较为详细的定义及它的STD：,31,传感器类,类型；编号；位置；,工作状态；采样频率；警报阈值；,初始化；,关闭；监视；待机；显示；振铃；拨号；,关闭状态,待机状态,监视状态,初始化命令,关闭命令,监视命令,待机命令,关闭命令,超越阈值/激活显示、振铃、拨号,传感器类的STD,32,4、定义结构与层次 类图中的类并非孤立存在，类之间有很多关系。应该关注类模型的结构以及类和子类出现时产生的类层次。 寻找关系的具体方法如下： 检查交互图，如果一个类向另一个类有请求，则它们之间通常有关联关系。 检查类的聚合关系。 检查类的泛化关系，寻找相似对象的不同点，抽取不同的部分定义为特殊类（自顶向下），或将共性的部分提升为基类（自底向上）。 检查其他类，发现不同类中的共同点，将共同的部分定义一个新类。其他类和新类之间的关系也是泛化关系。 但关系太多的类往往对其他类有更多的要求，较难复用且维护的工作量也很大，一旦其他类发生变化，则对该类产生影响。,33,（ 1）关联关系 是类之间的连接关系，可以是双向的也可以是单向的。两个关联之间可以相互发送消息。 订单类的属性放入客户类中，可以找到客户的订单；而客户类的属性放入订单类中，可以找到订单的客户。 在一对多或多对多的关联中，从重数为1的对象中找到它所对应的类的对象通常是比较困难的。解决的办法是在关联中加入限定，它可以唯一地识别重数为“多”端的对象，以便快速定位到要查找的对象。,订单,客户,* 属于 1,拥有,订单,订单号,客户,属于,34,system,sensor,alarm,sensor event,1 检测 *,1,0*,识别,1,*,激活,SafeHome中几个对象类的关联（参考教材1P423),35,（2）聚合关系 表示类之间整体与部分的关系。 标识类的聚合的优越性： 清晰的表达语义并用重数约束之间的关系。 简化对象的定义。 支持复用。如“发动机类”可以是一个可复用构件，用于其他系统定义中。,飞机,内嵌发动机和导航仪的属性,内嵌发动机和导航仪的操作,飞机,发动机,导航仪,36,身份,人员,会计师身份,经理身份,稳定部分,可变部分,在强聚合关系中，部分依赖于整体，如果整体不存在了，部分会随之消失。实现时一同删除。聚合关系使得类具有了层次结构。, 能表示动态变化的对象特征。不需要经常变化的属性与操作放在整体类，需要动态变化的特征放在部分类。,37,（3）泛化关系 是一般与特殊关系。将具有共同特性的元素抽象成一般类，通过增加其内涵生成特殊类。 通常，符合下属条件之一类的泛化才有存在的价值： 便于实现软件重用。 一般类有两个或两个以上的特殊类。（消除冗余） 需要用它们创建对象实例。 但要避免过渡泛化，否则会增加系统的复杂性。 泛化关系使得类具有了层次结构。下图是SafeHome的部分类图。,38,system,control panel,sensor,alarm,entry sensor,smoke sensor,motion sensor,SafeHome的部分类图,39,（4）包 复杂系统的分析模型可能有数十个结构、上百个类，难以理解与实现。当所有类的某个子集相互协作以完成一组内聚的责任（功能）时，划分为子系统（UML称为包）。 包确定了整个系统抽象粒度更大的结构。包图可产生于类图之后（将类图组合成包），或将用例的功能分派给包，再细化包以产生类图。 如参考教材1P421中将“控制面板类”的整个聚合结构划分成“控制面板包”。下图是某一教学管理系统的包图及包图的细化：,40,MFC类,用户接口,出错处理,教学管理,数据库,教学管理系统的包图,41,subsystem 课程注册子系统,系统与子系统包图,subsystem 成绩管理子系统,system 教学管理系统,42,选课管理,成绩管理,人事信息,教学管理,课程,学生登记,课程登记,开设课程,选课统计,学生成绩登记,成绩统计,学生,教师,身份验证,43,8.4 对象-行为模型,用例中的每个用例都是通过若干对象相互合作实现的。对象-行为模型指明一个系统对外部事件的激励所作出的响应。为创建该模型，应该完成以下工作： 评估所有use-case以完全理解系统中的交互顺序。 标识驱动交互序列的事件并理解这些事件如何和特定的对象相关联。 为每个use-case创建交互图。 为具有主要动态特征的类建立状态转换图。 为描述对象的工作流同时便于识别并发活动建立相应的活动图。 评价对象-行为模型以验证精确性和一致性。,44,1、通过use-case识别事件，为对象的交互行为建模 事件是某个时刻发生的事，包括所有来自或发往用户的信息、外部设备的信号、输入、策略、中断、转换和动作。当系统与参与者（人、设备或外部系统)交换信息时则一个事件发生。为了方便分析对象对外部事件的响应，有必要建立交互图（协作图、顺序图），用于显示一个用例实现中涉及到的对象和这些对象间的消息传递情况。 （1）顺序图 下面通过SafeHome的用例说明，识别出事件，找出与该事件相关的对象，并将用例的责任分派给它们，通过它们的交互，体现了系统完成一个用例的整体行为。,45,检查SafeHome的use-case，带下划线的部分指明了事件。（参考教材1P424) 房主观察控制面板以确定是否系统以准备好接收输入。如果系统未准备好，房主必须物理地关闭门/窗户，以便使“准备好”指示灯亮。 房主使用键盘输入4位密码，系统将密码与存储在配置库中的有效密码比较，如果密码不正确，控制面板鸣叫一次并复位等待再次输入。如果密码正确，控制面板等待进一步的动作。 房主选择键入“stay”（仅激活外部的传感器）或“away”（激活所有的传感器）以启动系统。 当处于激活状态时，房主可观察到一个红色指示灯。,46,一旦所有事件被标识，将它门分配给所涉及的对象。对象可以生成事件（如房主生成密码输入事件）或识别发生在其他地方的事件（如控制面板识别密码比较事件的二进制结果）。 下图是SafeHome的部分顺序图： 房主 控制面板 系统,输入密码,密码比较,密码正确/不正确,不正确启动蜂鸣器,蜂鸣器声响,等待下一个动作,47,房主 控制面板 系统,选择stay/away,激活传感器,传感器被激活,请求指示灯亮,红灯亮,等待下一个动作,Rumbaugh等人在OMT方法中提出，建立反映系统交互行为的动态模型时，需描述正常交互的脚本和例外的脚本。脚本也称为场景，是用例的一个实例。通过脚本中的步骤确定事件，比较方便的建立顺序图、协作图等视图。,48,如ATM系统示意图：,分行计算机,分理处计算机,分理处计算机,帐户,帐户,ATM,ATM,自动出纳机与用户交互的正常脚本： （1）ATM请求用户插入卡：用户插入现金卡。 （2）ATM接受卡片并读出它的卡号。 （3）ATM要求密码：用户输入密码401230。 （4）ATM请求分行确认卡号和密码：由分理处检验并 通知ATM。 （5）ATM要求用户选择事务类型：用户选择取款。,49,（6）ATM要求输入现金数量：用户输入$200。 （7）ATM请求分行处理事务，分行把请求传给分理处， 确认事务成功。 （8）ATM分发现金并要求用户取现金：用户取现金。 （9）ATM提示用户是否要继续：用户键入不继续。 （10）ATM打印收据，退出卡，并提示用户取走它们： 用户取走收据和卡。 （11）ATM请求用户插入卡。（回到初始状态） 还可列出用户与自动取款机交互的例外的脚本。 通过脚本，比较容易确定用例（如取款用例）中的事件（交互信息）、以及事件的发送者和接收者（完成该用例所涉及到的对象）。,50,（2）协作图 用于快速浏览对象间的相互合作。强调对象间的通信，不像顺序图那样强调传递消息间的时序性，它用数字顺序标号表示消息的顺序。 （3）活动图 用来描述对象或构件执行的工作流。突出的优点：用来表示并发活动及活动的执行者。 在分析阶段，活动图用来描述满足用例要求所要进行的活动及之间的约束关系。（有些专家认为用活动图建立用户业务模型比对象模型更易理解）。 在设计阶段，活动图可以反映对象内部的工作流程，可由状态图演化过去，是状态图的一个实例。,51,2、为单个对象类的重要行为建模 Pressman提出，在OO系统的语境内，必须考虑两种不同的状态特征： （1）当系统完成其功能时每个对象的状态； （2）当系统完成其功能时从外界观察到的系统状态，即系统的整体行为。 类的状态图反映了该类中每个对象内部的工作，在它的生命周期内遇到某个事件或动作使它从一种状态转换到另一种状态。通过状态图关注对象类应负有的责任，防止遗漏一些功能，帮助标识对象类的操作，因此需要对有重要行为的对象类建立状态图。 状态图还能为对象设计中建立每个操作体的内部逻辑提供帮助。,52,例如，SafeHome系统中的传感器类是比较重要的类，观察它的状态特征(详见3.4例2）对了解整个系统的动态行为很有帮助。 ATM系统中，自动取款机的行为特征比较重要。下图是自动取款机类在正常取款行为下的状态转换图。,53,开始 do:请求插入卡,检查 do:要求密码,核对 do:确认帐户,选择 do:要求类型,输数据 do:要求数量,事务 do:处理事务,发现金 do:分发现金,继续否 do:询问继续否,结束 do:打印收据,退卡 do:请求取卡,插入卡,输入密码,密码错,帐户正确,输入类型,输入数量,事务成功,取现金,继续,终止,打印指令发出,取走卡,ATM类的部分STD,54,范例：移动电话系统 功能： 用手机做移动通讯 下载铃声 下载图片 管理电话簿。,55,Talk to Others,Download Picture,Manage Phonebook,Download Rings,Mobile user,Mobile Network,56,定义移动电话系统的对象（简化） 手机包括的对象： 手机屏幕 手机按钮 手机（屏幕、按钮以外的部件） 其它对象： 基站,MButton,MDisplqy,MmobileStation,MmobileHandset,移动电话系统的类图,57,移动电话系统对象间的通信,:MButton,:MDisplqy,:MMobileStation,:MMobileHandset,Mobile user,1:pushDigButton() 3:pushSendButton(),2:displayButtonNumber(),4:connectStation(),6:connectSuccess (),5:createConnection(),移动电话系统 的协作图,7:displayConnectSuccess(),58,移动电话系统的顺序图,:MButton,:MDisplqy,Mobile user,pushSendButton(),displayButtonNumber(),displayConnectSuccess(),connectSuccess (),createConnection(),pushDigButton(),connectStation(),:MMobileStation,:MMobileHandset,59,MButton,MDisplqy,MmobileStation,MmobileHandset,pushDigButton() pushSendButton() pushDisconnectButton(),createConnection() cancelConnection () responseError(),displayError() displayButtonNumber() displayConnectSuccess() displayIncomingCall(),connectStation() disconnectStation() connectSuccess () Disconnectsuccess(),移动电话系统的类图之二,（接口）,60,8.5 RUP的分析活动,在统一过程中，用工作流来描述过程。工作人员执行工作流中的一组活动而产生相应的工作产品。 有7种过程工作流，它们是业务建模、需求、分析、设计、实现、测试和实施。其中需求、分析、设计、实现和测试是核心工作流。 需求工作流：列举出候选需求，捕获功能性需求， 捕获非功能性需求。 分析工作流：构架分析，分析用例，分析类，分析包。 设计工作流：构架设计，设计一个用例，设计一个类， 设计一个子系统。 实现工作流：构架实现，系统集成，实现一个子系统， 实现一个类，执行单元测试。 测试工作流：制定测试计划，设计测试，实现测试， 执行集成测试，执行系统测试，评估测试。 实施工作流：可交付系统的配置。,61,分析工作流的任务是通过精化和组织需求捕获阶段所描述的需求来对其进行分析，工作结果是分析模型。下表列出了用例模型和分析模型的简单比较： 用例模型 分析模型 使用用户的语言进行描述； 使用开发人员的语言进行描述； 系统的外部视图； 系统的内部试图； 通过用例来构造，提供外部 通过类、包来构造，提供内部视图 视图的结构； 的结构 ； 主要用于用户和开发人员签 主要为开发人员使用，以理解如何 署合同时明确系统应该做什么； 设计和实现系统； 需求中可能存在冗余和不一致； 不应该存在冗余和不一致等问题； 捕获系统的功能； 概述如何实现系统的功能； 定义在分析阶段中进一步进行 定义用例实现，每个实现代表对 分析的用例 ； 用例模型中一个用例的分析；,62,1、分析活动 （1）构架分析 确定系统的总体框架结构。 以业务模型和用例模型为基础，确定分析包。 一个大的系统包含有许多功能，通过分析业务模型、用例模型，将系统功能组织成大小适中的包。划分包的原则是将与一个业务过程相关的所有用例及其有扩展关系、包含关系的用例都放在一个包中。 好处： 便于实现和管理； 将变化局限在一个包内，减少由于需求变化对整个系统结构的影响。 划分了分析包后，检查每个包是否有公共特性 ，提取出组成公共的分析包，便于其他包使用。要定义分析包之间的依赖关系。,63,检查每个分析包，如果包中含有一些可共享的、较低层的、可选择的功能，将它们组织成独立的服务包，便于为不同的系统复用与选择。 重要的实体类对理解系统结构很有帮助，对它们进行概要说明，包括属性、操作及与其他实体类的关联。 定义系统级的公共特殊需求：系统的可靠性、安全性、可用性、可维护性、容错、分布等非功能性需求。 （2）确定用例实现 在需求获取阶段是从系统外部来看系统的功能。功能放在用例中描述，功能实现的过程用活动图描述，用例中各个对象之间、与外部参与者之间发生的交互关系用协作图、顺序图来反映，一个对象跨越多个用例的完整的行为描述用状态图来反映。但仅有这些还不能满足系统设计与实现的需要，因此，要细化每个用例。具体步骤如下：,64, 分析用例模型的每个用例，确定用例实现的分析类和事件流。分析类代表了类的抽象。将参与用例实现的分析类收集到类图中。分析模型中使用了分析类的3种构造型（边界类、控制类、实体类）。确定分析类注意以下几点： 为以人充当的角色建立一个主要边界类（通常实现为一个主窗口）。 为每个外部系统充当的角色定义一个主要边界类，使其代表通信接口。 确定一个控制类负责处理用例实现的控制和协调关系。有时，一些控制信息是由参与者在与系统交互时处理的，这种情况下可将控制封装在边界对象中。 仔细研究用例说明和已有的业务模型确定实体类。 考虑每个用例实现所涉及到的信息，将它们分配到3类对象中。,65, 描述每个对象之间的交互。 描述每个用例实现的特殊需求。 用例实现是对用例内部比较细节的描述，是分析类之间相互协作的构造。可通过用例实现回溯到用例模型，保持需求获取和分析之间的无缝连接。 （ 3）分析每个类的职责、属性和关联 确定分析类的职责 通过研究一个分析类在每个用例实现中充当的角色，将其在各个用例实现中的职责组合在一起，构成分析类的职责。 确定分析类的属性 注意几点：与人交互的边界类的属性通常是参与者录入的信息项。与外部系统交互的边界类的属性表现为通信接口。实体类的属性往往作为重要信息被录入系统。,66, 从几个分析类中抽取出公共的或可共享的特性，组成新的类。 确定分析类的关联。类之间的关系尽可能简单。 定义分析类的特殊需求。参照用例实现的特殊需求，避免重复定义。 （4）检查分析模型 用例实现、分析类和分析包构成了不同层次的分析模型，隋着分析的用例越来越多，分析模型会逐步完善起来。要检查分析模型中各种成分的准确性、一致性、完整性。在分析阶段的后期要检查分析包之间的关系，尽量独立且内聚性高，每个包实现一个完整的业务逻辑。,67,2、实例 ATM系统的用例模型和分析模型 在ATM系统中，储户是参与者，取款、存款和转帐是3个用例。ATM的用例模型如图所示。,取款,存款,转帐,储户,68,根据用例建立分析模型： 现在只考虑“取款”用例。完成取款用例动作序列的简化路径是：储户表明自己的身份；储户选择从哪个帐户取款；确定取款金额；系统从帐户扣除取款金额；发给储户相应金额的现金。 通过分析取款用例实现时的角色，确定所需的分析类包括： 分发边界类（指分发金额）、出纳接口边界类、 取款控制类、 帐户实体类 。边界类负责与用户进行交互并且处理交互的信息；控制类负责取款的事务处理；实体类负责保存和管理帐户信息。 “取款”用例的分析模型如下图所示。在图中还表示了分析模型的“取款”用例实现跟踪依赖于用例模型的“取款”用例。,69,取款,存款,转帐,储户,取款,参与者,跟踪,用例模型,分析模型,分发,出纳接口,取款,帐户,下图中，描述了“取款”用例如何通过一个带有跟踪（构造型元素）依赖关系的协作来实现，在这个用例实现中有4个类参与并充当角色。图中虚线椭圆表示用例实现或协作。,70,下图显示了每个用例如何实现为分析类的结构。在图中选用不同的底纹来表示一个类参与哪个用例实现并在其中充当什么角色。如，有4个类参与了“取款”用例的实现。“出纳接口”类和“帐户”类参与并在全部3个用例实现中充当角色。,取款,转帐,存款,储户,