《面向对象分析与设计分析精选课件.ppt》由会员分享，可在线阅读，更多相关《面向对象分析与设计分析精选课件.ppt（65页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、关于面向对象分析与设计分析第一页，本课件共有65页面向对象分析的主要工作v用例模型帮助开发团队理解客户对系统的各种功能需求v概念模型（静态模型）帮助开发团队理解问题领域的各种概念、各种名词、以及它们之间的各种关系。描述系统的结构特征 v动态模型描述系统的动态行为特征。v这两方面的工作，将帮助开发团队定义问题，也是分析工作的主要内容 第二页，本课件共有65页分析与设计过程全景第三页，本课件共有65页UML在建模中的使用第四页，本课件共有65页面向对象分析过程v定义用例（辅助模型，可选）用用例对用户需求进行规范化描述v建立类图（基本模型）发现对象、定义对象类识别对象的内部特征识别对象的外部关系v建
2、立交互图、状态图和活动图（辅助模型，可选）v建立详细说明对模型中的成分进行规范的定义和文字说明可以集中进行，也可分散在各个活动中v原型开发结合其他活动反复进行第五页，本课件共有65页什么是问题域?v“问题域”是指一个包含现实世界事物与概念的领域，这些事物和概念与所设计的系统要解决的问题有关。v建立概念模型，又称为问题域建模、域建模，也就是找到代表那些事物与概念的“对象”。v建模OO软件的第一步是澄清问题域。第六页，本课件共有65页确定核心的抽象概念v目的通过采取确定系统必须处理的核心抽象概念（即在业务建模和需求活动中确定的概念）的措施来进行分析v必要性需求和业务建模活动通常会揭示系统必须能够处
3、理的核心概念，与此同时，这些概念也证实了其自身是核心的设计抽象概念。因为已经确认，所以没有必要在用例分析活动中重复确认工作。为了利用现有知识，我们初步确定使用实体分析类，来代表这些以系统常识（诸如需求、词汇表词汇表、特别是领域模型领域模型或业务对象模型业务对象模型）为基础的核心抽象概念v关键抽象的来源需求词汇表领域模型业务对象模型第七页，本课件共有65页什么是分析类？v它代表问题域中的简洁抽象v应该映射到真实世界业务概念v分析类的最重要方面是应该使用清晰的和无歧义的方法映射到真实世界业务概念第八页，本课件共有65页OO分析师的工作v力求把混淆或不恰当的业务概念澄清为能够形成分析类基础的事物,是
4、OO分析工作困难的原因。vOO分析的真正目的是找出现实对象的类第九页，本课件共有65页分析类的思想v尽力捕获抽象的本质,忽略实现细节不是从设计角度考虑而产生的类，在具体设计时可能一个分析类被精华为一个或多个设计类v在分析中，在创建概念模型时，捕获大场景。v分析类的形式名称属性操作第十页，本课件共有65页如何产生良好的分析类v名称反映目的。v建模问题域的一个特定元素是简洁的抽象。v清晰地映射到问题域中的可识别的特征。v具有小的、良好定义的职责集合。职责是类与其客户的契约或对于客户的义务职责在语义上是内聚的操作集合每个类大约有35个职责v高内聚。类的所有特征应该有助于实现其目的v低耦合。类应该仅同
5、一小部分其他类协作实现其目的第十一页，本课件共有65页分析类经验法则v每个类大约35个职责。v不存在独立的类。v当心很多非常小的类v当心少数几个非常庞大的类v当心“伪类”v当心万能类v避免深度继承树设计良好的继承层次的本质是继承层次中每个抽象层次应该具有良好定义的目的第十二页，本课件共有65页OO分析建模核心问题v寻找分析类使用名词使用名词/动词分析寻找类动词分析寻找类使用使用CRC分析寻找类分析寻找类寻找其他类来源寻找其他类来源第十三页，本课件共有65页使用名词/动词分析寻找类v名词/动词分析是分析文本尝试找出类、属性和职责的方法。从名词与名词短语中提取对象与属性 从动词与动词短语中提取操作
6、与关联 所有格短语通常表明名词应该是属性而不是对象 第十四页，本课件共有65页名词/动词分析过程v第一步：尽可能多地收集相关信息补充需求规格说明用例项目词汇表任何其他信息源（构架、远景文档）第十五页，本课件共有65页名词/动词分析过程（续）v第二步：使用非常简单方法分析如下内容：名词名词短语动词动词短语第十六页，本课件共有65页概念模型建模步骤1.找到备选类 2.决定候选类并不是每一个备选类都是合适的候选类，有些名词对于要开发的系统来说并无关紧要，甚至是系统之外的;而有些名词表述的概念则相对较小，适合于某个候选类的属性 3.确定类之间的关联 4.为类添加职责 什么是类的职责呢？它包括以下两个主
7、要内容：v 类所维护的知识；（成员变量）v 类能够执行的行为。（成员方法）第十七页，本课件共有65页举例-创建概念模型v一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但不能够删除记录。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时限进行统计。第十八页，本课件共有65页使用名词/动词法注意v在使用“名词动词法”寻
8、找类的时候，很多团队会在此耗费大量的时间，这样很容易迷失方向。其实我们的主要目的是对问题域建立概要的了解，无需太过咬文嚼字。第十九页，本课件共有65页其它方法-CRC分析v脑力风暴技术v过程要求团队成员命名运转在业务领域的事物要求团队陈述该事物的职责要求团队识别可能一起工作的类第二十页，本课件共有65页概念模型的意义 v面向对象的视角使用OO的思想所建立的系统模型就是对问题域的完整、直接的映射,体现了OO 思想的关键活动 v开发团对的需要概念模型的建立，其主要的作用是帮助开发团队能够对问题域有一个全貌式的了解第二十一页，本课件共有65页概念模型的详细程度v模型不是我们要生产的目标产物，而且过程
9、中的一个辅助工作，只要能够利用其帮助团队更好的开发，详细也罢、简约也罢，都是好模型第二十二页，本课件共有65页OO分析总结v用例模型帮助开发团队明白客户想解决什么问题将需求整理归纳成为指导全开发过程的“软件需求规格说明书v概念模型帮助开发团队了解客户所处的世界第二十三页，本课件共有65页分析用例（行为分析）用例模型补充需求构架描述用例分析用例用例工程师业务模型分析类第二十四页，本课件共有65页用例分析v目的确定执行用例事件流的类使用用例实现，将用例行为分配给那些类确定类的职责、属性和关联关系记录构架机制的使用情况v角色设计师v时机用例分析分两个阶段v第一个阶段是“定义备选构架”，同时做“构架分
10、析”活动，目标是定义一个备选构架v第二个阶段是“分析行为”，与“确定设计元素”活动一起做，目标是把用例行为分配到分析类中第二十五页，本课件共有65页行为分析之前-用例建模v获取可靠的需求-我们需要高层的需求文档和用例结构图来确定需求的可靠性，它并不一定完备、但提供了系统的基本全景；如果在分析过程中发现了一些相当新的用例，那说明需求工作没做到位，它作为分析（行为建模）的基础将是不可靠的；v确定用例的优先级我们通常采用迭代的开发模式，每次只针对一个目标用例集展开分析，而不是全线出击；因此需要根据风险、重要性和团队的适应能力综合考虑，为所有的用例确定优先级；那些级别高的用例应当有详细的规格说明，包括
11、基本流和重要的扩展流，它们是分析的基本素材。第二十六页，本课件共有65页用例实现中的分析与设计v用例建模对系统外在的行为进行了分解，每个用例情节最终都落实到内部某个对象群体的协作上；v而对象群体行为则进一步将必要职责分配到对象个体上；v这便是用例实现，并分为用例分析和用例设计两个阶段。v为用例实现建模的元素包括协作图、序列图、以及类图等。第二十七页，本课件共有65页用例分析的输入和输出v输入词汇表补充规约用例模型用例规约用例建模指南用例实现（只是识别出来了，还没有开发）软件构架文档边界类，表示用户界面中的窗口 设计模型或分析模型v输出用例实现分析模型（可选）或设计模型 第二十八页，本课件共有6
12、5页用例实现v用例实现对用例模型中的每个用例，在设计模型中都有相应的实现提供从分析和设计到需求的可跟踪性v用例实现结构用例实现包v是组织用例的类和交互图的方式v每个用例都对应一个用例实现包可跟踪性图交互图v时序图（Sequence Diagrams）（动态）v协作图（Collaboration Diagrams）（动态）类图（Class Diagrams）（静态）第二十九页，本课件共有65页用例分析的步骤v补充用例描述v对每个用例实现从用例行为中找出类把用例行为分配到类v对每个分析类描述属性和关联描述责任限定分析机制（analysis mechanism）确定属性建立分析类之间的关联关系说明分
13、析类之间的事件依赖关系v整合分析类第三十页，本课件共有65页Step1:补充用例描述v用例的描述往往不够查找分析类用户通常不关心系统内部的信息，所以开始时的用例描述是黑盒的v为了发现分析类，需要从系统内部的视点对用例进行白盒描述例如：课程注册系统中，学生可能喜欢说“系统显示课程列表”，但是这不能说明系统内部是如何实现的。为了给出系统内部是如何工作的，我们要加入:系统从课程目录遗留数据库中取得课程列表第三十一页，本课件共有65页Step2:从用例行为中查找分析类 v目的确定一组备选的、能够执行用例行为的分析类v分析类分析类代表“系统中具备职责和行为的事物”的初期概念模型。这些概念模型最终将演进为
14、设计模型中的类和子系统分类（根据其担负的职责和表现的行为）v边界类（Boundary class）接口与系统外部某些事物的媒介。v控制类（Control Class）负责协调用例的行为。v实体类（Entity Class）封装了数据以及数据相关的操作，表达领域概念，负责承担系统中需要持久化的信息及其关联的行为。v应用逻辑对象 第三十二页，本课件共有65页识别分析类v用例的行为最终都要落实到各分析类的职责上。第三十三页，本课件共有65页边界类承担的角色v边界类负责系统与外界的通讯和交互。边界对象将系统与其外部环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他
15、部分造成影响。第三十四页，本课件共有65页边界类的职责v转换和翻译交互事件对内，将外界不同格式的事件和信息转换为内部能够识别的格式，并触发控制类对象（或实体对象）来响应它们；对外，则做类似的反向操作；v变更对外的表示内容在内部状态（特别是外界关注的信息）发生变化时，向外部通知或更新表示内容）v常见的边界类对象有：用户接口类v帮助与用户进行通信的类，通过标准的I/O设备提供人机界面（GUI）系统接口类v帮助与其他系统进行通信的类，系统（通讯协议）接口。设备接口类或Timer v提供对硬件设备的软件接口第三十五页，本课件共有65页识别边界类v用户界面类关注要呈现给用户的信息是什么不要陷入UI的设计
16、细节v系统和设备接口类关注必须定义的协议是什么不要关注协议是如何实现的v重点关注职责而不是细节第三十六页，本课件共有65页识别边界类（续）v每个用例主角都至少有一个边界类v查找用户接口类时需要注意可以复用用户界面建模活动期间存在的边界类仅对系统的核心部分建模，不要对 GUI 中的每个按钮、列表和小部件都建模。分析的目的是要大致了解系统是如何构成的，而不是要设计每一个细枝末节v查找系统边界类时注意与现有系统的接口可能已有明确定义，如果是这样，即可从接口定义中直接推导出职责如果已经有一个正式的接口定义，则可对它实施逆向工程，这样就不必在此正式界定它v查找设备边界类时注意做用例分析的时候可能需要补充
17、原来没有识别出来的设备主角，相应的也要修改用例的说明第三十七页，本课件共有65页实例：用户界面（边界类）第三十八页，本课件共有65页实例：系统接口（边界类）第三十九页，本课件共有65页边界类的职责归类vGUI界面边界类承担的职责包括：按要求的格式显示内容（VIEW文本、表格、图形等控件）输入数据并转换为内部格式（CONTROL编辑、选择、图形等控件）转换和翻译用户动作并触发响应（CONTROL菜单、按钮、快捷键）v系统接口边界类承担的职责包括：输入/输出数据，并根据协议进行格式转换接收事件并触发响应和向外发送事件第四十页，本课件共有65页边界类的状态与行为vGUI界面边界类可以拥有状态，并可能
18、对其行为产生如下影响：影响用户操作的执行范围（菜单等的使能与禁用，对话框的打开与关闭）影响对外显示的样式和能力边界类的状态除了受用户操作序列的影响，更多地将为控制类和实体类的状态所控制v系统接口边界类的状态将与其支持的协议中规定的交互顺序有关v设备接口边界类通常拥有复杂的状态，以便支持与硬件设备的适配逻辑第四十一页，本课件共有65页控制类v作用：负责协调、调度、处理事务并控制系统内部其它对象的行为。用于对一个或几个用例所特有的控制行为进行建模，控制类封装了用例的特有行为控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质控制类有效地将边界对象与实体对象分开，让系统更能适应其边界
19、内发生的变更控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性控制类并不能处理用例需要执行的一切事务。相反，它协调其他用来实施此功能的对象的活动。控制类将工作委派给已被指定负责此项功能的对象。控制类通常被看成一个乐队的指挥，它指挥（控制）参与use case的其它对象的行为，通知对象什么时候执行以及执行什么。第四十二页，本课件共有65页控制类的角色v协调用例的行为第四十三页，本课件共有65页识别控制类v可以首先为每个用例实现确定一个控制类，接着，在确定了更多的用例实现并发现更多的共性后，再对其进行改进v将性质不同的控制逻辑封装到分离的控制类中v将（逻辑复杂的）主
20、事件流和可选/异常事件流封装到不同的控制类中v尽量为每个执行者定义单独的控制类第四十四页，本课件共有65页控制类的职责归类v用例控制类负责用例的控制序列（应用逻辑），协调其它类的协作以完成用例的不同执行场景，其中包括：控制显示（导航）流程控制系统的执行动作，这些动作将可能改变系统的内部状态、提供结果数据等控制协议的对话顺序第四十五页，本课件共有65页控制类的行为v控制类行为有以下特点与周围环境无关定义控制逻辑（event的顺序）和use case事务如果实体类的内部结构或行为变化，控制类很少会变化使用或设定几个实体类的内容，因此需要协调这几个实体类的行为每次被激活，行为方式不同（flow of
21、 event与多个状态有关）v有的用例没有控制类，复杂的用例可以有多个控制类v控制对象的生命周期通常和用例实例的生命周期相同v控制类可以分为协调对象(状态无关的)和状态相关的控制对象两种 第四十六页，本课件共有65页示例：管理任务队列v执行任务用例的事件流主要包含：从任务队列中按顺序取出任务，并为其分配资源，然后开始执行任务（系统可以同时执行多个任务）；v根据控制逻辑的不同性质，可以划分为两个控制类，一个负责处理任务队列和分配资源，另一个则负责具体控制任务的执行过程。第四十七页，本课件共有65页实体类v实体类(entity class)系统的关键抽象、是系统的核心概念主要责任是用于保存和管理系
22、统的信息，如一个event，一个人或一些实际存在的对象的信息。通常是持久化的(persistent)通常不特定于某个use case realization，有时甚至不特定于系统。v实体类承担的角色（存储和管理系统中的信息）第四十八页，本课件共有65页从用例中识别实体类v使用用例的事件流作为输入v用例中的关键抽象v传统的名词过滤法划出用例事件流中的名词条款去掉重复的候选者去掉含糊的候选者去掉执行者ACTORS（超出了系统范围）去掉实施部件去掉属性去掉操作第四十九页，本课件共有65页应用逻辑对象 v分为业务逻辑对象和算法对象两种v业务逻辑对象（Business Logic Objects）定义业
23、务特定的处理一个用户请求的应用逻辑，目的是封装（隐藏）业务逻辑通常业务逻辑对象在执行过程中可以访问各种实体对象只有在特定情况下才需要业务逻辑对象v如果business rule要通过访问两个或多个实体对象才能执行，就需要有一个单独的业务逻辑对象v否则，就是实体类的一个操作业务逻辑对象与协调对象的区别v协调对象的责任是监督其他的对象v而业务逻辑对象的主要责任是封装和执行business rulev算法对象（Algorithm Objects）封装了问题域用的算法 算法对象通常也封装了计算算法时需要的数据 第五十页，本课件共有65页实例：识别的候选分析类第五十一页，本课件共有65页Step3:把用
24、例行为分配到类v指南：把责任分配到类边界类v和actor交互的行为实体类v与数据抽象封装有关的行为控制类v特定到一个use case或一部分非常重要的事件流程的行为v动态建模：用时序图和协作图来描述用例行为注意：对所有基本流和备选流都要进行分析第五十二页，本课件共有65页时序图v时序图表示如何一步步的完成系统的一个功能时序图是用于决定类责任和接口的主要信息来源时序图描述了对象间的交互模式通过对象的“生命线”和他们相互发送的消息来显示对象时序图与协作图在语义上是相同的，只是时序图中的消息是按时间顺序分布的时序图表示的是一个场景(scenario)v组成主角对象消息生命线Focus of cont
25、rolv表示对象直接或通过子过程执行动作的一段时间第五十三页，本课件共有65页协作图v协作图显示对象之间的交互协作图强调参与交互的对象的组织适合分析活动，适合表示少数对象的简单交互协作图很难显示补充的说明性信息，例如时间、判定点或其他非结构化的信息，而在序列图中这些信息可以方便地添加到注释中 v组成主角(actor)对象(object)Links：Link是对象通信的途径消息(message)第五十四页，本课件共有65页记录分析类的职责v用简短的（最多几个单词）职责名称和简短的（最多几个句子）说明记录职责。该说明表述对象实现职责需要执行什么操作，以及调用职责时将返回什么结果v可以用两种方式来记
26、录职责用分析类的操作：操作名就是职责名称，职责的说明就写到操作的说明中。为了表示该操作是一个职责，应该在操作名前面加上“/”来标记用文字描述：在类的说明中描述类的职责 v维护一致性确保类具有一致的责任，如果类的责任是脱节的，要把类分成两个或多个新类，同时要修改交互图 确保没有两个类具有相似的责任，如果两个类具有相同的责任，就把这两个类合并成一个，同时要修改交互图 第五十五页，本课件共有65页实例：用例分析-时序图第五十六页，本课件共有65页确定属性v是属性还是类？信息属于以下情况时，需要使用属性v“通过值”引用；即在信息中只有值是重要的，而与地址或对象标识符无关v由其所属的对象唯一“拥有”；其
27、他对象都不引用这条信息v通过获取、设置或者执行对信息的简单转换的操作进行访问；信息除了提供它本身的值以外没有任何“实际”的行为如果信息具有复杂的行为，被两个或更多对象共享，或者在两个或更多对象间“通过引用”传递，此时信息应当作为一个单独的类v属性的说明属性名称应当是一个名词，它描述了属性保存的信息属性说明应当说明属性中将要存储的信息；如果从属性名称可以很明显地看出所存储的信息，则可以不说明属性类型就是属性的简单数据类型。例如字符串、整型、数值型等 第五十七页，本课件共有65页确定属性v属性可以来自领域知识需求Glossary领域模型业务模型v分析时属性的类型来自领域，可以不映射到具体的实现语言
28、第五十八页，本课件共有65页识别分析类之间的关系v识别分析类之间的关联关系有两个来源协作图：协作图中对象之间有联系，就意味着相应的类之间存在关联关系领域知识：从中得到实体类之间的聚合关系v注意：不要添加您认为“或许”存在的关联关系，除非协作图要求添加这些关联关系在分析时不用识别出类之间的关系是关联还是依赖，是聚合还是组合，因为我们还没有作出明智决策所需要的足够信息，我们将在类设计活动中改进对于继承关系，在分析时可以识别出来，但是不要求 v是关联还是聚合 选择聚合只是为了阐明一种整体/部分的关系 如果拿不准是什么关系，通常关联关系更合适。聚合关系通常是很明显的，聚合的语义应该很容易的从上下文中理
29、解出来 是聚合关系还是关联关系与开发的具体应用有关第五十九页，本课件共有65页记录类之间的关系v用类图来表示类之间的关系 v用例实现的类图又叫VOPC（View Of Participated Classes）v画类图时，还要给关系加上关系名或角色（Role）名称关联关系名称和角色名称的使用是互斥的：不能同时使用关联关系名称和角色名称。角色名称通常比关联关系名称更可取，除非没有足够的信息来正确命名角色（这常见于分析阶段中；在设计阶段中应始终使用角色名称）关联关系名称就应该反映该关系的目的，并且应该是一个动词词组角色名称应当是一个名词应避免使用“有”和“包含”之类的名称，因为它们不能提供有关类之
30、间关系的信息。在分析的时候可以不给关系取名，也不赋予其角色名，但是如果两个类之间存在多个关系的时候则一定要赋予角色名 第六十页，本课件共有65页记录类之间的关系v画类图时，还要赋予关系多重性（multiplicity）除非能给出明确的证据说明存在其他情况，否则多重性为 0.*，零的多重性意味着关联关系是可选的也可以指定范围更狭窄的多重性（比如 3.8 之间）在多重性范围内，可以指定概率。因此，如果多重性为 0.*，而且期望它在 85%的情况下介于 10 和 20 之间，则请将此信息记录下来；该信息在设计期间非常重要。v画类图时，可以设定Navigability可以根据协作图中的message方
31、向来决定navigability，如果message是单向的navigability的方向要与message的方向相同；如果message是双向的，那么navigability也是双向的。在类设计中将会细化Navigabilityv编写一份关联关系的简短说明，指明如何使用关联关系，或者关联关系表示了什么关系第六十一页，本课件共有65页限定分析机制v目的确定类使用的分析机制（如果有的话）提供更多关于类如何应用分析机制的信息v在分析类使用的每一种分析机制中，限定在选择合适的设计机制与实施机制时必须考虑的相关特征 v无须正式记录类所使用的分析机制以及它们的关联关系特征；在图中加上注释，或者对类的说明
32、进行补充就足以表达这样的信息 v例如，航班类使用的永久性机制的特征可以限定为粒度粒度：每个航班占用 2 到 24 千字节容量容量：上限为 100,000访问频率访问频率v创建/删除：每小时 100 次；更新：每小时 3,000 次；读取：每小时 9,000 次存取第六十二页，本课件共有65页整合分析类v在设计之前，要过滤分析类以保证创建出最少的新概念分析类的名字要能抓住类在系统中扮演的角色的本质，名字要唯一类的描述应该准确的描述出类扮演的角色合并定义了相似行为或者代表相同现象的类合并定义相同属性的实体类，即使定义的行为不同v修改了分析类之后，不要忘了修改交互图和类图，有时甚至需要修改用例规约第
33、六十三页，本课件共有65页检查点v分析类是否合理？每个类的名字是否清晰地反映了它的角色？每个类是否代表了单一的、明确定义的抽象？是否所有的属性和责任在功能上是相关的（coupled）？类是否提供了需要的行为？是否阐述了所有对类的需求？v用例实现所有的主流成和/或子流程，包括例外情形都处理了吗？找到所有需要的对象了吗？所有的行为都明确地分配到对象了吗？所有的行为都分配到正确的对象了吗？有多个交互图时，他们的关系清晰而一致吗？v一个用例实现有多个交互图时，要能容易地理解哪个交互图对应哪个流程v确保从事件流程描述中能清楚交互图之间的关系第六十四页，本课件共有65页感感谢谢大大家家观观看看第六十五页，本课件共有65页