第8章面向对象分析.ppt

《第8章面向对象分析.ppt》由会员分享，可在线阅读，更多相关《第8章面向对象分析.ppt（76页珍藏版）》请在优知文库上搜索。

1、1第第8章章 面向对象分析面向对象分析 领域分析 使用实例的需求获取 用类进行建模 对象-行为模型 RUP分析活动 OO分析小结28.1 领域分析领域分析 1、领域分析的概念、领域分析的概念 面向对象的系统分析可以发生在许多不同的抽象层次。在业务或企业级层次，可定义模拟整个业务的类、对象、关系和行为。在业务域层次，可定义描述某特殊的业务域的工作的对象模型和行为模型；在应用层次，建模着重于特定的用户需求。Firesmith对软件领域分析的定义是：领域分析(Domain Analysis)指特定应用领域中公共需求的标识、分析和规约，即发现或创建那些可广泛应用的类，其目的目的使它们在应用域中多个项目

2、间能被复用在应用域中多个项目间能被复用。领域分析的角色是设计和建造可复用构件（类似于制造环境中工具制造者的角色），它们被很多相似但不一定是相同的应用开发的人所使用。3 Lethbridge的定义是：领域分析是软件工程师了了解背景信息的过程解背景信息的过程。为了理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策，软件工程师必须了解使用该类软件的一般性商业和技术领域中足够的信息。2、领域分析过程的活动、领域分析过程的活动 （1）定义将被调查的领域 分离感兴趣的业务域、系统类型或产品范畴，抽取OO和非OO的“项”。OO项包括：现存OO应用的类的规约、设计和代码，支持类（如GUI类或数据库访问

3、类），和领域相关的构件库以及测试案例。非OO项包括：政策、规程、计划、标准，非OO应用文档和构件。4 （2）对从领域中抽取出来的项进行分类并建立分类层次。（3）收集领域中应用的代表性样本。（4）分析样本中的每个应用 标识候选的每个可复用对象。指明对象被标识为可复用的理由。定义对象的适应性。估算在领域中复用这些对象的应用的百分率。使用配置管理技术控制这些对象。（5）为对象开发分析模型。5 3、领域分析的价值、领域分析的价值 领域分析除了为软件复用奠定基础外，还为较低抽象层次的一般的面向对象分析带来如下好处：快速开发。有助于集中精力关注最重要的问题，更有效地与相关人员进行交流，可以更快的确定需求。

4、优化系统。了解领域的细节有助于保证所采纳的解决方案更有效地解决用户的问题。会少犯错误，知道应该遵循那些规程和标准。领域分析给出一个应用领域的总体视图，会引导出更好的抽象从而改进设计。有了领域知识，就可以洞察新兴趋势及进一步开发的机会，有助于创建适应性更强的系统。了解通用性和特殊性，有助于创建出具有更好的可重用性和更宽的销售市场的软件。6 专家提出，没有坚实的领域分析，任何重大的软件项目都不应该进行。对应用领域的深入理解能极大的提高成功的几率。许多非常成功的软件产品的开发人员以前都在业务领域工作过段时间，对实际需要有着深切的感受。一旦对领域有了真正的理解，就可进行某一个项目（或产品）的需求分析，

5、包括定义待解决的问题以及开发什么软件来解决它。然而，领域分析永远也不应该结束：开发人员有责任在开发过程中不断增进他们的理解，后续版本的系统扩充通常需要对子领域进行进一步的领域分析。78.2 使用实例的需求获取使用实例的需求获取 面向对象的分析过程并不从考虑对象开始，而是从对系统将被使用的方式的理解开始。如果系统是人机交互的，则考虑被人使用的方式；如果系统是涉及过程控制的，则考虑被机器使用的方式；如果系统是协调和控制应用的，则考虑被其他系统使用的方式。一旦使用的场景(scenario)被定义，软件的建模活动就开始了。1、use-case（用例或使用实例）（用例或使用实例）在OOA中，用例是分析模

6、型的第一个元素的基础，以终端用户的观点对系统建模。用例在需求获取时创建，应达到下列目标目标：通过定义由终端用户和开发人员共同认可的使用场景，定义系统的功能和运行需求。场景是用例的一个实例，表达用例的一个特定发生，在特定的时间，使用特定的数据进行操作。8 提供清楚的、无二义性的终端用户和系统如何相互交 互的描述。提供确认测试的基础。用例的描述以及用例图构成了参与者与系统交互的用 例模型（1）用例的描述 建议：其中只有名称和步骤是必须的。名称(name)参与者(actor)目标(goal)：参与者要完成的任务。前置条件(precondition)：列出参与者启动用例前所有必需为真的条件。相关用例(

7、related use cases)：列出可能是此用例的扩展、包含的用例。9 步骤(step)：用两列的格式描述用例的每一步（见例）。后置条件(postcondition)：用例完成后系统所处的状态。例1：描述应用程序中打开文件的用例 用例用例：打开文件 步骤步骤：参与者动作 系统响应 选择“打开”命令 显示“打开文件”对话框 指定文件名 确认选择 关闭对话框10 例例2、图书管理系统借书、图书管理系统借书 用例用例 用例用例：为借阅者借出一本书 参与者参与者：借书员 目标目标：帮助借阅者借阅书籍并确保输出正确的借出记录 前置条件前置条件：借阅者必须有一张有效的借书卡并且没有欠费；该书藉必须具

8、有有效的条形码并且不是来自于 参考文献区。步骤步骤：参与者动作 系统响应 扫描书籍和借书卡 显示允许借阅的信息 在书籍上标记到期日期 确认借出开始 显示借出已被记录的确 认的信息 后置条件后置条件：系统有一个该书藉被借出以及到期时间的记录 11例3、某商店POS系统用例描述实例用例：购买商品参与者：顾客（发起者）、收款员类型：主要的描述：顾客带着所要购买商品到付款处，收款 员记录商品信息并收款。用例：启动/关闭系统参与者：管理员类型：主要的描述：管理员接通一台POS机电源，检查时 间、日期正确性，检查完成后，系统处 于就绪 状态，以备收款员使用。12（2）用例图 用来显示一系列用例和参与者之间

9、的关系，有助于开发人员表达系统功能的不同的抽象层次的描述。房主房主传感器传感器SafeHome高层用例图13启动启动/关闭系统关闭系统房主房主输入密码输入密码询问区域状态询问区域状态SafeHome交互用例图询问传感器状态询问传感器状态 按紧急按钮按紧急按钮验证密码验证密码询问传感器询问传感器includeincludeinclude(参考教材1 P415)14 用例分析是理解和组织系统应完成任务的直观方法。它还可以用来驱动开发过程驱动开发过程。特别是，用例：可以帮助定义系统的范围，即必须做什么和不必做什么。可用来计划开发过程。确定的用例数量决定了项目的大 小，开发进度可用完成的用例数量来测量

10、。用来开发和确认需求。构成测试用例定义的基础。可用来构造用户手册。但是用例也不是万能的！注意：（Lethbridge的观点）用例必须经确认。用例集应是完全的、表达是一致的和 明确的。用例分析不一定覆盖到功能需求的所有方面。如，不被 参与者触发的活动不会出现在用例中。当软件需求来自用例时，软件往往只是简单的反映开发 软件前用户的工作方式，可能没有考虑到创新的解决方 案。152、获取需求的主要活动、获取需求的主要活动 （1）确定参与者和用例 与用户一起确定与系统有交互活动的所有角色，并为每个角色设计用例。确定用例的准则：每个用例都应该为其角色提供有价值的服务避免确定的用例太小；确保每个用例都向主要

11、角色提供有价值的服务避免用例太大。（2）定义用例的优先级 （3）描述每个用例 用例描述可有不同的抽象层次与描述模板。概要描述主要强调每个用例的主要功能。详细描述包括每个用例的事件流（如何开始，与角色如何交互，如何终止）、每个用例中所涉及到的对象（编入术语表）、执行一个用例所要求的非功能性需求等。16（4）建立用例图 用例图用来显示一系列用例和参与者之间的关系。它有助于表达系统功能的高层表述。用例有特化、扩展和包含关系。特化的使用同类图。一个特化用例代表了几个相似用例，一个或多个特化提供了这些相似用例的细节。使用包含关系减少用例之间的冗余。即 确定用例中可以被共享的功能。检查每个用例抽取出公共部

12、分创建单独用例。使用扩展关系区分事件的例外和事件的共有流程，即确定补充功能或可选功能。如果发现一个用例比较复杂，既包含了一般处理又包含了特殊处理，将特殊处理的部分抽取出来，创建单独的用例。17打开文件用户通过键入文件名打开文件通过浏览打开文件试图打开不存在的文件浏览文件extendinclude用例的特化、扩展和包含18 （5）建立用户界面原型 在面向对象的软件开发中，用例模型和用户界面设计息息相关。用例模型创建后，就可确定参与者如何驱动用例，以及用例以什么形式向参与者提供信息。因此可开始用户界面原型化的迭代过程，和构造系统的其他部分并行进行。198.3 用类进行建模用类进行建模 面向对象分析

13、，就是抽取和整理用户需求并建立问题域精确模型的过程。在需求获取阶段已经建立了用例模型等阶段产品，但都是为了容易沟通信息，以用户语言描述的，存在着模糊、冗余、二义性、不一致性等问题。系统分析阶段要进一步分析、完善前一阶段获取的需求，细化用例模型中的用例、确定系统中的对象、对象的静态和动态特征、对象间的关系及对象的行为约束，建立满足用户需求的、精确的、稳定的、易于维护的、便于后续设计的分析模型。20用例图：视图功能模型：模型分析模型：模型类图：视图对象模型：模型顺序图：视图状态图：视图活动图：视图动态模型：模型分析模型的构成分析模型的构成21 几条通用的分析原则：（1）组装与分解相结合的原则 基本

14、对象可组装成复杂对象，对复杂对象进行分解从而完成系统模型的细化。（2）抽象化与具体化相结合的原则 数据抽象将数据及作用在其上的操作抽象成对象。过程抽象为对象的相互作用提供了依据。抽象强调对象的本质和内在属性，忽视与问题无关的属性。而具体化指在细化过程中，描述对象的某些特性，加强系统模型的稳定性。抽象化与具体化相结合可以使具体对象直接从抽象对象的定义中获得已有特性，而不必重复定义它们。22（3）封装原则 将对象的各种独立的外部特性与内部实现细节分开。对象接口定义要尽可能的与其内部工作状态相分离。封装有助于减少由于需求的改变而对整个系统所造成的影响。（4）相关性原则 在分析中要考虑对象间的各种关联

15、，包括静态结构的关联、动态特征的关联。这些关联是对象协作的基础。（5）行为约束的原则 通过语义特征来刻画。表示了对象合法存在、对象合法操作应满足的条件，有助于深刻理解对象和系统。23 一旦建立了系统的用例模型，则可以开始标识候选类，并指明它们的责任和协作。Wirfs-Brock等人提出了一种类类-责任责任-协作者协作者(Class-responsibility-collaborator,CRC)开发类图的卡片技术。该技术使用实际的或虚拟的索引卡片（参考教材P417)，为定义类提供较多的信息。其中责任是与该类相关的属性和操作，协作者是为一个类提供要完成的责任所需要的信息的那些类。通常，协作意味着

16、对信息的请求或者对某种操作的请求。在确定属性和操作时，可把它们列在卡片上。由于卡片的空间有限，使得每一个类都不能太复杂。如果不能在一张卡片上列出所有的职责，该类应分成两个相关的类。可在白板上自由移动卡片以组成类图，在卡片之间画线表示关联与泛化。低科技的卡片技术可能比操作软件用户界面要快，对开发人员通过会议讨论确定方案很有效。24 1、标识类及对象、标识类及对象 无论是面向对象分析还是面向对象设计与实现，建立类图都是核心技术。类图是定义其他图的基础，在该基础上用交互图、状态图等进一步描述系统其他方面的特性。如何识别对象？对象以一系列不同形式展示自身：外部实体、事物、发生的事件、角色、组织单位、位置或结构。一种最简单的方法是从系统处理说明中找出名词。例如，在SafeHome的需求陈述中，找出相关的名词是：用户、传感器、控制面板、系统(安全系统)、传感器编号、传感器类型、密码、电话号码、传感器事件、警报器 等。这些候选的对象是否都可作为在系统中承担责任的有用对象？要根据一定原则筛选。见下表：25几条筛选特征:例:SafeHome中潜在的对象及筛选理由(1)保留的信息 潜在对象 选取理由 筛选