面向对象分析与设计分析详解演示文稿

面向对象分析与设计分析详解演示文稿当前第1页\共有60页\编于星期五\16点优选面向对象分析与设计分析当前第2页\共有60页\编于星期五\16点分析与设计过程全景当前第3页\共有60页\编于星期五\16点UML在建模中的使用当前第4页\共有60页\编于星期五\16点面向对象分析过程定义用例（辅助模型，可选）用用例对用户需求进行规范化描述建立类图（基本模型）发现对象、定义对象类识别对象的内部特征识别对象的外部关系建立交互图、状态图和活动图（辅助模型，可选）建立详细说明对模型中的成分进行规范的定义和文字说明可以集中进行，也可分散在各个活动中原型开发结合其他活动反复进行当前第5页\共有60页\编于星期五\16点什么是问题域?“问题域”是指一个包含现实世界事物与概念的领域，这些事物和概念与所设计的系统要解决的问题有关。建立概念模型，又称为问题域建模、域建模，也就是找到代表那些事物与概念的“对象”。建模OO软件的第一步是澄清问题域。当前第6页\共有60页\编于星期五\16点确定核心的抽象概念目的通过采取确定系统必须处理的核心抽象概念（即在业务建模和需求活动中确定的概念）的措施来进行分析必要性需求和业务建模活动通常会揭示系统必须能够处理的核心概念，与此同时，这些概念也证实了其自身是核心的设计抽象概念。因为已经确认，所以没有必要在用例分析活动中重复确认工作。为了利用现有知识，我们初步确定使用实体分析类，来代表这些以系统常识（诸如需求、词汇表、特别是领域模型或业务对象模型）为基础的核心抽象概念关键抽象的来源需求词汇表领域模型业务对象模型当前第7页\共有60页\编于星期五\16点什么是分析类？它代表问题域中的简洁抽象应该映射到真实世界业务概念分析类的最重要方面是应该使用清晰的和无歧义的方法映射到真实世界业务概念当前第8页\共有60页\编于星期五\16点OO分析师的工作力求把混淆或不恰当的业务概念澄清为能够形成分析类基础的事物,是OO分析工作困难的原因。OO分析的真正目的是找出现实对象的类当前第9页\共有60页\编于星期五\16点分析类的思想尽力捕获抽象的本质,忽略实现细节不是从设计角度考虑而产生的类，在具体设计时可能一个分析类被精华为一个或多个设计类在分析中，在创建概念模型时，捕获大场景。分析类的形式名称属性操作当前第10页\共有60页\编于星期五\16点如何产生良好的分析类名称反映目的。建模问题域的一个特定元素是简洁的抽象。清晰地映射到问题域中的可识别的特征。具有小的、良好定义的职责集合。职责是类与其客户的契约或对于客户的义务职责在语义上是内聚的操作集合每个类大约有3~5个职责高内聚。类的所有特征应该有助于实现其目的低耦合。类应该仅同一小部分其他类协作实现其目的当前第11页\共有60页\编于星期五\16点分析类经验法则每个类大约3~5个职责。不存在独立的类。当心很多非常小的类当心少数几个非常庞大的类当心“伪类”当心万能类避免深度继承树设计良好的继承层次的本质是继承层次中每个抽象层次应该具有良好定义的目的当前第12页\共有60页\编于星期五\16点OO分析建模核心问题寻找分析类使用名词/动词分析寻找类使用CRC分析寻找类寻找其他类来源当前第13页\共有60页\编于星期五\16点使用名词/动词分析寻找类名词/动词分析是分析文本尝试找出类、属性和职责的方法。从名词与名词短语中提取对象与属性从动词与动词短语中提取操作与关联所有格短语通常表明名词应该是属性而不是对象当前第14页\共有60页\编于星期五\16点名词/动词分析过程第一步：尽可能多地收集相关信息补充需求规格说明用例项目词汇表任何其他信息源（构架、远景文档）当前第15页\共有60页\编于星期五\16点名词/动词分析过程（续）第二步：使用非常简单方法分析如下内容：名词名词短语动词动词短语当前第16页\共有60页\编于星期五\16点概念模型建模步骤找到备选类决定候选类并不是每一个备选类都是合适的候选类，有些名词对于要开发的系统来说并无关紧要，甚至是系统之外的;而有些名词表述的概念则相对较小，适合于某个候选类的属性

确定类之间的关联为类添加职责什么是类的职责呢？它包括以下两个主要内容：

类所维护的知识；（成员变量）

类能够执行的行为。（成员方法）当前第17页\共有60页\编于星期五\16点举例-创建概念模型一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但不能够删除记录。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时限进行统计。当前第18页\共有60页\编于星期五\16点使用名词/动词法注意在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，这样很容易迷失方向。其实我们的主要目的是对问题域建立概要的了解，无需太过咬文嚼字。当前第19页\共有60页\编于星期五\16点其它方法-CRC分析脑力风暴技术过程要求团队成员命名运转在业务领域的事物要求团队陈述该事物的职责要求团队识别可能一起工作的类当前第20页\共有60页\编于星期五\16点概念模型的意义面向对象的视角使用OO的思想所建立的系统模型就是对问题域的完整、直接的映射,体现了OO思想的关键活动

开发团对的需要概念模型的建立，其主要的作用是帮助开发团队能够对问题域有一个全貌式的了解当前第21页\共有60页\编于星期五\16点概念模型的详细程度模型不是我们要生产的目标产物，而且过程中的一个辅助工作，只要能够利用其帮助团队更好的开发，详细也罢、简约也罢，都是好模型当前第22页\共有60页\编于星期五\16点OO分析总结用例模型帮助开发团队明白客户想解决什么问题将需求整理归纳成为指导全开发过程的“软件需求规格说明书概念模型帮助开发团队了解客户所处的世界当前第23页\共有60页\编于星期五\16点分析用例（行为分析）用例模型补充需求构架描述用例分析用例用例工程师业务模型分析类当前第24页\共有60页\编于星期五\16点用例分析目的确定执行用例事件流的类使用用例实现，将用例行为分配给那些类确定类的职责、属性和关联关系记录构架机制的使用情况角色设计师时机用例分析分两个阶段第一个阶段是“定义备选构架”，同时做“构架分析”活动，目标是定义一个备选构架第二个阶段是“分析行为”，与“确定设计元素”活动一起做，目标是把用例行为分配到分析类中当前第25页\共有60页\编于星期五\16点行为分析之前-用例建模获取可靠的需求--我们需要高层的需求文档和用例结构图来确定需求的可靠性，它并不一定完备、但提供了系统的基本全景；如果在分析过程中发现了一些相当新的用例，那说明需求工作没做到位，它作为分析（行为建模）的基础将是不可靠的；确定用例的优先级—我们通常采用迭代的开发模式，每次只针对一个目标用例集展开分析，而不是全线出击；因此需要根据风险、重要性和团队的适应能力综合考虑，为所有的用例确定优先级；那些级别高的用例应当有详细的规格说明，包括基本流和重要的扩展流，它们是分析的基本素材。当前第26页\共有60页\编于星期五\16点用例实现中的分析与设计用例建模对系统外在的行为进行了分解，每个用例情节最终都落实到内部某个对象群体的协作上；而对象群体行为则进一步将必要职责分配到对象个体上；这便是用例实现，并分为用例分析和用例设计两个阶段。为用例实现建模的元素包括—协作图、序列图、以及类图等。当前第27页\共有60页\编于星期五\16点用例分析的输入和输出输入词汇表补充规约用例模型用例规约用例建模指南用例实现（只是识别出来了，还没有开发）软件构架文档边界类，表示用户界面中的窗口设计模型或分析模型输出用例实现分析模型（可选）或设计模型

当前第28页\共有60页\编于星期五\16点用例实现用例实现对用例模型中的每个用例，在设计模型中都有相应的实现提供从分析和设计到需求的可跟踪性用例实现结构用例实现包是组织用例的类和交互图的方式每个用例都对应一个用例实现包可跟踪性图交互图时序图（SequenceDiagrams）（动态）协作图（CollaborationDiagrams）（动态）类图（ClassDiagrams）（静态）当前第29页\共有60页\编于星期五\16点用例分析的步骤补充用例描述对每个用例实现从用例行为中找出类把用例行为分配到类对每个分析类描述属性和关联描述责任限定分析机制（analysismechanism）确定属性建立分析类之间的关联关系说明分析类之间的事件依赖关系整合分析类当前第30页\共有60页\编于星期五\16点Step1:补充用例描述用例的描述往往不够查找分析类用户通常不关心系统内部的信息，所以开始时的用例描述是黑盒的为了发现分析类，需要从系统内部的视点对用例进行白盒描述例如：课程注册系统中，学生可能喜欢说“系统显示课程列表”，但是这不能说明系统内部是如何实现的。为了给出系统内部是如何工作的，我们要加入:系统从课程目录遗留数据库中取得课程列表当前第31页\共有60页\编于星期五\16点Step2:从用例行为中查找分析类

目的确定一组备选的、能够执行用例行为的分析类分析类分析类代表“系统中具备职责和行为的事物”的初期概念模型。这些概念模型最终将演进为设计模型中的类和子系统分类（根据其担负的职责和表现的行为）边界类（Boundaryclass）接口与系统外部某些事物的媒介。控制类（ControlClass）负责协调用例的行为。实体类（EntityClass）

封装了数据以及数据相关的操作，表达领域概念，负责承担系统中需要持久化的信息及其关联的行为。应用逻辑对象

当前第32页\共有60页\编于星期五\16点识别分析类用例的行为最终都要落实到各分析类的职责上。当前第33页\共有60页\编于星期五\16点边界类承担的角色边界类负责系统与外界的通讯和交互。边界对象将系统与其外部环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。

当前第34页\共有60页\编于星期五\16点边界类的职责转换和翻译交互事件—对内，将外界不同格式的事件和信息转换为内部能够识别的格式，并触发控制类对象（或实体对象）来响应它们；对外，则做类似的反向操作；变更对外的表示内容—在内部状态（特别是外界关注的信息）发生变化时，向外部通知或更新表示内容）常见的边界类对象有：用户接口类帮助与用户进行通信的类，通过标准的I/O设备提供人机界面（GUI）系统接口类帮助与其他系统进行通信的类，系统（通讯协议）接口。设备接口类或Timer提供对硬件设备的软件接口当前第35页\共有60页\编于星期五\16点识别边界类用户界面类关注要呈现给用户的信息是什么不要陷入UI的设计细节系统和设备接口类关注必须定义的协议是什么不要关注协议是如何实现的重点关注职责而不是细节当前第36页\共有60页\编于星期五\16点识别边界类（续）每个用例主角都至少有一个边界类查找用户接口类时需要注意可以复用用户界面建模活动期间存在的边界类仅对系统的核心部分建模，不要对

GUI中的每个按钮、列表和小部件都建模。分析的目的是要大致了解系统是如何构成的，而不是要设计每一个细枝末节查找系统边界类时注意与现有系统的接口可能已有明确定义，如果是这样，即可从接口定义中直接推导出职责如果已经有一个正式的接口定义，则可对它实施逆向工程，这样就不必在此正式界定它查找设备边界类时注意做用例分析的时候可能需要补充原来没有识别出来的设备主角，相应的也要修改用例的说明当前第37页\共有60页\编于星期五\16点实例：用户界面（边界类）当前第38页\共有60页\编于星期五\16点实例：系统接口（边界类）当前第39页\共有60页\编于星期五\16点边界类的职责归类GUI界面边界类承担的职责包括：按要求的格式显示内容（VIEW—文本、表格、图形等控件）输入数据并转换为内部格式（CONTROL—编辑、选择、图形等控件）转换和翻译用户动作并触发响应（CONTROL—菜单、按钮、快捷键）系统接口边界类承担的职责包括：输入/输出数据，并根据协议进行格式转换接收事件并触发响应和向外发送事件当前第40页\共有60页\编于星期五\16点边界类的状态与行为GUI界面边界类可以拥有状态，并可能对其行为产生如下影响：影响用户操作的执行范围（菜单等的使能与禁用，对话框的打开与关闭）影响对外显示的样式和能力边界类的状态除了受用户操作序列的影响，更多地将为控制类和实体类的状态所控制系统接口边界类的状态将与其支持的协议中规定的交互顺序有关设备接口边界类通常拥有复杂的状态，以便支持与硬件设备的适配逻辑当前第41页\共有60页\编于星期五\16点控制类作用：负责协调、调度、处理事务并控制系统内部其它对象的行为。用于对一个或几个用例所特有的控制行为进行建模，控制类封装了用例的特有行为控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发生的变更控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性控制类并不能处理用例需要执行的一切事务。相反，它协调其他用来实施此功能的对象的活动。控制类将工作委派给已被指定负责此项功能的对象。控制类通常被看成一个乐队的指挥，它指挥（控制）参与usecase的其它对象的行为，通知对象什么时候执行以及执行什么。当前第42页\共有60页\编于星期五\16点控制类的角色协调用例的行为当前第43页\共有60页\编于星期五\16点识别控制类可以首先为每个用例实现确定一个控制类，接着，在确定了更多的用例实现并发现更多的共性后，再对其进行改进将性质不同的控制逻辑封装到分离的控制类中将（逻辑复杂的）主事件流和可选/异常事件流封装到不同的控制类中尽量为每个执行者定义单独的控制类当前第44页\共有60页\编于星期五\16点控制类的职责归类用例控制类负责用例的控制序列（应用逻辑），协调其它类的协作以完成用例的不同执行场景，其中包括：控制显示（导航）流程控制系统的执行动作，这些动作将可能改变系统的内部状态、提供结果数据等控制协议的对话顺序当前第45页\共有60页\编于星期五\16点控制类的行为控制类行为有以下特点与周围环境无关定义控制逻辑（event的顺序）和usecase事务如果实体类的内部结构或行为变化，控制类很少会变化使用或设定几个实体类的内容，因此需要协调这几个实体类的行为每次被激活，行为方式不同（flowofevent与多个状态有关）有的用例没有控制类，复杂的用例可以有多个控制类控制对象的生命周期通常和用例实例的生命周期相同控制类可以分为协调对象(状态无关的)和状态相关的控制对象两种

当前第46页\共有60页\编于星期五\16点示例：管理任务队列执行任务用例的事件流主要包含：从任务队列中按顺序取出任务，并为其分配资源，然后开始执行任务（系统可以同时执行多个任务）；根据控制逻辑的不同性质，可以划分为两个控制类，一个负责处理任务队列和分配资源，另一个则负责具体控制任务的执行过程。当前第47页\共有60页\编于星期五\16点实体类实体类(entityclass)系统的关键抽象、是系统的核心概念主要责任是用于保存和管理系统的信息，如一个event，一个人或一些实际存在的对象的信息。通常是持久化的(persistent)通常不特定于某个usecaserealization，有时甚至不特定于系统。实体类承担的角色（存储和管理系统中的信息）当前第48页\共有60页\编于星期五\16点从用例中识别实体类使用用例的事件流作为输入用例中的关键抽象传统的名词过滤法划出用例事件流中的名词条款去掉重复的候选者去掉含糊的候选者去掉执行者ACTORS（超出了系统范围）去掉实施部件去掉属性去掉操作当前第49页\共有60页\编于星期五\16点应用逻辑对象

分为业务逻辑对象和算法对象两种业务逻辑对象（BusinessLogicObjects）

定义业务特定的处理一个用户请求的应用逻辑，目的是封装（隐藏）业务逻辑通常业务逻辑对象在执行过程中可以访问各种实体对象只有在特定情况下才需要业务逻辑对象如果businessrule要通过访问两个或多个实体对象才能执行，就需要有一个单独的业务逻辑对象否则，就是实体类的一个操作业务逻辑对象与协调对象的区别协调对象的责任是监督其他的对象而业务逻辑对象的主要责任是封装和执行businessrule算法对象（AlgorithmObjects）封装了问题域用的算法

算法对象通常也封装了计算算法时需要的数据

当前第50页\共有60页\编于星期五\16点实例：识别的候选分析类当前第51页\共有60页\编于星期五\16点Step3:把用例行为分配到类指南：把责任分配到类边界类和actor交互的行为实体类与数据抽象封装有关的行为控制类特定到一个usecase或一部分非常重要的事件流程的行为动态建模：用时序图和协作图来描述用例行为注意：对所有基本流和备选流都要进行分析当前第52页\共有60页\编于星期五\16点时序图时序图表示如何一步步的完成系统的一个功能时序图是用于决定类责任和接口的主要信息来源时序图描述了对象间的交互模式通过对象的“生命线”和他们相互发送的消息来显示对象时序图与协作图在语义上是相同的，只是时序图中的消息是按时间顺序分布的时序图表示的是一个场景(scenario)组成主角对象消息生命线Focusofcontrol表示对象直接或通过子过程执行动作的一段时间当前第53页\共有60页\编于星期五\16点协作图协作图显示对象之间的交互协作图强调参与交互的对象的组织适合分析活动，适合表示少数对象的简单交互协作图很难显示补充的说明性信息，例如时间、判定点或其他非结构化的信息，而在序列图中这些信息可以方便地添加到注释中

组成主角(actor)对象(object)Links：Link是对象通信的途径消息(message)当前第54页\共有60页\编于星期五\16点记录分析类的职责用简短的（最多几个单词）职责名称和简短的（最多几个句子）说明记录职责。该说明表述对象实现职责需要执行什么操作，以及调用职责时将返回什么结果可以用两种方式来记录职责用分析类的操作：操作名就是职责名称，职责的说明就写到操作的说明中。为了表示该操作是一个职责，应该在操作名前面加上“//”来标记用文字描述：在类的说明中描述类的职责

维护一致性确保类具有一致的责任，如果类的责任是脱节的，要把类分成两个或多个新类，同时要修改交互图

确保没有两个类具有相似的责任，如果两个类具有相同的责任，就把这两个类合并成一个，同时要修改交互图

当前第55页\共有60页\编于星期五\16点实例：用例分析-时序图当前第56页\共有60页\编于星期五\16点确定属性是属性还是类？信息属于以下情况时，需要使用属性“通过值”引用；即在信息中只有值是重要的，而与地址或对象标识符无关由其所属的对象唯一“拥有”；其他对象都不引用这条信息通过获取、设置或者执行对信息的简单转换的操作进行访问；信息除了提供它本身的值以外没有任何“实际”的行为如果信息具有复杂的行为，被两个或更多对象共享，或者在两个或更多对象间“通过引用”