第6章面向对象分析.

第六章面向对象分析面向对象分析（OOA）与设计的关系：它们采用相同的概念和表示法。只是非形式上的，采取的观点不同，不是技术上的差异。分析—用对象模型表示应用领域。设计—把分析模型转化为一个具体的软件产品本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图分析的目的分析活动的输入：用例和领域模型。用例描述：通过用户与系统的交互来表示外部看到的系统功能。领域模型：定义了重要业务概念之间的关系。分析任务：构造一个模型，说明源于业务实体的这些对象，以怎样的方式协作才能实现用例中规定的行为。在UML中，用交互图定义用例的实化交互图有两种：协作图和顺序图责任人—依据—活动—结果提取分析类转述需求场景整理分析类局部分析设计师ＵseCase报告关键抽象NMUseCase实现(框架)分析模型层次构架（高层）UseCase实现(框架)Claim_record(fromUseCase实现(框架))...)用分析元素描述的UseCase实现用户界面:SubmitClaimForm:SubmitClaim:Claim_record1:2:3:参与类图实体信息A实体信息B用户界面控制逻辑外部系统接口后台系统(fromUseCaseView)...)本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图层次架构以选定的UseCase为研究对象，以相对粗大的粒度用面向对象的概念和方法对问题进行转述，为后续以相对细小的粒度作进一步的设计活动提供铺垫。如何将系统划分为子系统？各个子系统将是什么角色？软件架构：指导定义若干层的策略，并将职责分配到不同子系统，划分出彼此相关的高层决策。比如：MVC架构6.2软件架构6.2软件架构显示层应用层存储层三层架构定义分层结构，每一层由一个包描绘。•表示层：与用户界面有关的类放在表示层。•应用层：维护系统状态和实现应用业务逻辑的类置于应用层。•存储层：维护数据持久存储的类放在存储层。控制类实体类边界类本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图6.3对象设计提出问题领域模型定义了一组具有属性和关系的类设计过程会发现一些在领域模型中没有的类。人们希望在最终的设计对这些概念和它们的关系有一个相对直接的表示，但最后的设计总包含一些类，是领域模型中没有的。领域模型通常不显示操作。对每个用例，通过适当类的实例的交互，产生所需要的系统行为。以致于从每个用例实化都可以看出最终代码中每个交互和方法调用。分析类类型的划分如果立足于软件功能需求，拟建系统往往在三个维度发生变化：第一，拟建系统和外部要素之间交互的边界；第二，拟建系统要记录和维护的信息；第三，拟建系统在运行中的控制逻辑。视图类：控制类：实体类：基本信息系统边界UseCase行为协调边界类控制类实体类边界类边界类用于描述拟建系统外部环境与内部运作之间的交互，主要负责内容的翻译和形式的转换，并表达相应的结果。边界类对拟建系统中依赖于外部环境的部分进行建模，具有良好的隔离作用。边界类主要用于描述三种类型的内容：拟建系统和用户的界面拟建系统和外部系统的接口拟建系统与设备的接口边界类构造型ｂｏｕｎｄａｒｙ控制类控制类用于描述一个UseCase所特有的事件流控制行为。控制类相当于协调人，被那些提出具体任务要求的类所共知；它自己通常不处理具体的任务，但它知道哪些类有能力完成具体的任务。控制类将UseCase所特有的行为进行封装，具有良好的隔离作用。控制类构造型ｃｏｎｔｒｏｌ实体类实体类用于描述必须存储的信息，同时描述相关的行为。实体类代表拟建系统中的核心信息，是拟建系统中最重要的部分，通常需要长期保留。实体类主要的任务是装载信息，同时也具有行为，但是这部分行为具有“向内收敛”的特征，主要包括那些和实体类自身信息直接相关的操作。这是实体类能够独立于外部环境以及特定控制流程的必要条件。。实体类构造型entity提取分析类边界类、控制类和实体类的获取方法:边界类。通常一个Actor和UseCase之间的通信关联对应一个边界类。如果两个UseCase同时和一个Actor交互，它们往往可以共用同一个边界类。用户界面用户控制类。通常一个UseCase对应一个控制类,如果不同的UseCase包含的任务之间联系比较紧密，某个控制类可以参与多个UseCase.实体类。参考“领域模型”中的实体信息。有时，和UseCase相关的Actor会在系统内部有一个实体类与之对应。提取分析类例如，”提交报销申请”用例的场景描述，找出概念类。UseCase“提交报销申请用例”事件流：1．打开报销单[员工]：员工[Employee]选择进入“报销申请”[边界，SubmitClaimForm]功能。[系统]：该员工当月报销单[Claim_report]存在，系统将取出相应信息并展示给员工。2．添加报销记录[员工]：员工要求添加一条报销记录[Claim_record][系统]：系统显示一条空白的报销记录。3．填写报销记录[员工]：员工开始填写报销记录，每条报销记录包括的信息有：业务活动发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。4．验证报销单[员工]：员工填写完毕所有报销记录之后，要求系统验证这些记录的合理性[Valid_Rule]。[系统]：报销记录的初始状态为“未验证”，每当一条报销记录被验证为合理，系统将该报销记录的状态设置为“已验证”，系统在验证所有报销记录（为“已验证”）之后提示用户可以提交本月的报销单。验证为合理的记录必须满足几种条件：第一，不同种类的费用不超过相应的限额：第二，报销费用的类型要和员工的职能匹配。5．提交报销单[员工]：所有报销记录经过验证之后，员工提交当月的报销单。[系统]：系统保存这张报销单，将报销单的状态设置为“已提交”并记录提交日期，同时这张报销单被设为“只读”。系统要从人事管理数据库[边界，HRDatabase]中获知该员工及其经理（负担该员工当月开销者）的电子邮件地址。为了及时通知相关人员，系统将自动生成一份以当前报销单为内容的电子邮件发送到该员工及其经理的信箱(邮件系统[边界，MailSystem])中。当邮件成功发送后，员工得到一个确认信息。实体类，包括以下内容：“报销单”。即《entity》Claim_report。“报销记录”。即《entity》Claim_record。“员工”。即《entity》Employee。“验证规则”。即《entity》Valid_Rule。employeeClaim_recordClaim_reportValid_Rule最后得到的分析类控制类：“提交报销申请”，即《control》SubmitClaim。边界类，包括以下内容：“报销申请”。即《boundary》submitClaimForm。“人事数据库”。即《boundary》HRDatabase。“邮件系统”。即《boundary》MailSystem。最后得到的分析类实体类，包括以下内容：“报销单”。即《entity》Claim_report。“报销记录”。即《entity》Claim_record。“员工”。即《entity》Employee。“验证规则”。即《entity》Valid_Rule。分析类图SubmitClaimFormHRDatabaseMailSystemEmployeeClaim_recordSubmitClaimValid_RuleClaim_report本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图本章内容6.1分析的目的6.2软件架构6.3对象设计6.4交互图6.4交互图交互图包括：•顺序图(sequencediagram)，描述对象按照时间顺序的交互图；•协作图(collaborationdiagram)，描述系统成分如何协同工作。•不同角度，相互转化。什么是职责？职责是一个类的契约或义务。从对象行为的角度看，职责与一个对象的义务相关联。创建交互图时，实际上已经为对象分配了职责。本章内容6.4.1顺序图6.4.2实例：餐馆系统的顺序（时序）图本章内容6.4.1顺序图6.4.2实例：餐馆系统的顺序（时序）图6.4.1顺序图用顺序图来表达动态建模。定义：显示对象之间交互的图,这些对象是按时间顺序排列的.如何对动态方面建模？所谓动态方面，即随着时间的推移，一些对象被创建，属性值的改变，以及其中一些对象的销毁，对象之间的相互调用。顺序图－组成对象对象生命线消息（实际是方法调用）对象的创建与销毁注意－顺序图描述的是对象之间的消息发送关系，而不是类之间的关系:staff:BookingSystemdisplay(date)顺序图时间维对象维生命线消息:staff:BookingSystemdisplay(date)对象/参与者激活期•顺序（时序）图包含了4个元素－对象（Object）－生命线（lifeline）－激活期－消息（message）图21)调用消息：消息的发送者把控制传递给消息的接收者，等待接收者返回或放弃控制。－同步－返回消息与调用关系配对的返回消息可以不用画出顺序图中的消息图3顺序图中的消息2)返回消息：－过程调用：隐含－非过程调用：明确返回消息图6建立顺序图的步骤1.确定交互过程的上下文2.识别参与交互过程的对象3.为每个对象设置生命线4.从引发这个交互过程的初始消息开始，在生命线之间自顶向下依次画出随后的各个消息。5.如果需要嵌套或(和)表示消息发生的时间点，使用FOC。6.如果需要说明时间约束，则在消息旁边加上约束说明。7.如果需要，可以为每个消息设置前置条件和后置条件。举例：登录用例文本：显示登陆界面，用户录入用户名、密码，系统将验证结果返回。普通用户登录管理员添加用户添加用户用例文本：1.打开添加用户的界面，在界面上选择一个组（可以通过一个下拉选择框来选择），然后向后台提交。2.后台系统保存用户信息（同时建立用户和组之间的关联）。UserUserManager1*classUser{Stringname;intpassword;UserManagerum;}*1本章内容6.4.1顺序图的组成6.4.2实例：餐馆系统的顺序（时序）图6.4.2餐馆系统的顺序图分析用例图中提供的功能：检索并显示预约记录新预约调换餐桌取消预约1）检索并显示预约--顺序图分析“显示预约”用例，如何画交互图？基本事件路径：用户输入要求的日期，系统以显示所记录的当天所有的预约进行响应。从系统角度分析，系统响应这个消息的反应是检索和显示所请求的那天的预约。系统如何检索和显示用户请求的数据呢？本例中，以显示预约为例，“谁应该负责获取给定日期相匹配的预约？”根据信息专家模式，我们应该寻找一个对象类，它具有显示预约所需的全部信息。:BookinggetDate()本例中，预约类（Booking）负责存储单个预约信息，但显示预约功能要将该日期中的所有预约提取出来，谁负责维护全部相关联的预约？高内聚模式告诉我们，维护单个实体和实体集合的责任最好分给不同的对象。如果分配在同一个类中，会有什么不好？检索并显示预约顺序图：在顺序图中，找出每个类中的操作。分析：发送消息调用对象中的方法，通过接收消息的对象包含一个操作表示。新增三个类:Receptionist:StaffUI:BookingSystem:Restaurant:booking1:display(date)2:display(date)8:updateDisplay()3:ge