第8章面向对象分析.ppt
《第8章面向对象分析.ppt》由会员分享,可在线阅读,更多相关《第8章面向对象分析.ppt(76页珍藏版)》请在三一文库上搜索。
1、1,第8章 面向对象分析,领域分析 使用实例的需求获取 用类进行建模 对象-行为模型 RUP分析活动 OO分析小结,2,8.1 领域分析,1、领域分析的概念 面向对象的系统分析可以发生在许多不同的抽象层次。在业务或企业级层次,可定义模拟整个业务的类、对象、关系和行为。在业务域层次,可定义描述某特殊的业务域的工作的对象模型和行为模型;在应用层次,建模着重于特定的用户需求。 Firesmith对软件领域分析的定义是:领域分析(Domain Analysis)指特定应用领域中公共需求的标识、分析和规约,即发现或创建那些可广泛应用的类,其目的使它们在应用域中多个项目间能被复用。领域分析的角色是设计和建
2、造可复用构件(类似于制造环境中工具制造者的角色),它们被很多相似但不一定是相同的应用开发的人所使用。,3,Lethbridge的定义是:领域分析是软件工程师了解背景信息的过程。为了理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策,软件工程师必须了解使用该类软件的一般性商业和技术领域中足够的信息。 2、领域分析过程的活动 (1)定义将被调查的领域 分离感兴趣的业务域、系统类型或产品范畴,抽取OO和非OO的“项”。OO项包括:现存OO应用的类的规约、设计和代码,支持类(如GUI类或数据库访问类),和领域相关的构件库以及测试案例。非OO项包括:政策、规程、计划、标准,非OO应用文档和构件。
3、,4,(2)对从领域中抽取出来的项进行分类并建立分类层次。 (3)收集领域中应用的代表性样本。 (4)分析样本中的每个应用 标识候选的每个可复用对象。 指明对象被标识为可复用的理由。 定义对象的适应性。 估算在领域中复用这些对象的应用的百分率。 使用配置管理技术控制这些对象。 (5)为对象开发分析模型。,5,3、领域分析的价值 领域分析除了为软件复用奠定基础外,还为较低抽象层次的一般的面向对象分析带来如下好处: 快速开发。有助于集中精力关注最重要的问题,更有效地与相关人员进行交流,可以更快的确定需求。 优化系统。了解领域的细节有助于保证所采纳的解决方案更有效地解决用户的问题。会少犯错误,知道应
4、该遵循那些规程和标准。领域分析给出一个应用领域的总体视图,会引导出更好的抽象从而改进设计。 有了领域知识,就可以洞察新兴趋势及进一步开发的机会,有助于创建适应性更强的系统。 了解通用性和特殊性,有助于创建出具有更好的可重用性和更宽的销售市场的软件。,6,专家提出,没有坚实的领域分析,任何重大的软件项目都不应该进行。对应用领域的深入理解能极大的提高成功的几率。许多非常成功的软件产品的开发人员以前都在业务领域工作过段时间,对实际需要有着深切的感受。 一旦对领域有了真正的理解,就可进行某一个项目(或产品)的需求分析,包括定义待解决的问题以及开发什么软件来解决它。然而,领域分析永远也不应该结束:开发人
5、员有责任在开发过程中不断增进他们的理解,后续版本的系统扩充通常需要对子领域进行进一步的领域分析。,7,8.2 使用实例的需求获取,面向对象的分析过程并不从考虑对象开始,而是从对系统将被使用的方式的理解开始。如果系统是人机交互的,则考虑被人使用的方式;如果系统是涉及过程控制的,则考虑被机器使用的方式;如果系统是协调和控制应用的,则考虑被其他系统使用的方式。一旦使用的场景(scenario) 被定义,软件的建模活动就开始了。 1、use-case(用例或使用实例) 在OOA中,用例是分析模型的第一个元素的基础,以终端用户的观点对系统建模。 用例在需求获取时创建,应达到下列目标: 通过定义由终端用户
6、和开发人员共同认可的使用场景,定义系统的功能和运行需求。 场景是用例的一个实例,表达用例的一个特定发生,在特定的时间,使用特定的数据进行操作 。,8, 提供清楚的、无二义性的终端用户和系统如何相互交 互的描述。 提供确认测试的基础。 用例的描述以及用例图构成了参与者与系统交互的用 例模型 (1)用例的描述 建议:其中只有名称和步骤是必须的。 名称(name) 参与者(actor) 目标(goal) : 参与者要完成的任务。 前置条件(precondition): 列出参与者启动用例前所有必需为真的条件。 相关用例(related use cases): 列出可能是此用例的扩展、包含的用例。,9
7、, 步骤(step): 用两列的格式描述用例的每一步(见例)。 后置条件(postcondition): 用例完成后系统所处的状态。 例1:描述应用程序中打开文件的用例 用例:打开文件 步骤: 参与者动作 系统响应 选择“打开”命令 显示“打开文件”对话框 指定文件名 确认选择 关闭对话框,10,例2、图书管理系统借书 用例 用例:为借阅者借出一本书 参与者:借书员 目标:帮助借阅者借阅书籍并确保输出正确的借出记录 前置条件:借阅者必须有一张有效的借书卡并且没有欠费; 该书藉必须具有有效的条形码并且不是来自于 参考文献区。 步骤: 参与者动作 系统响应 扫描书籍和借书卡 显示允许借阅的信息 在
8、书籍上标记到期日期 确认借出开始 显示借出已被记录的确 认的信息 后置条件:系统有一个该书藉被借出以及到期时间的记录,11,例3、某商店POS系统用例描述实例,用例: 购买商品 参与者:顾客(发起者)、收款员 类型: 主要的 描述: 顾客带着所要购买商品到付款处,收款 员记录商品信息并收款。,用例: 启动/关闭系统 参与者:管理员 类型: 主要的 描述: 管理员接通一台POS机电源,检查时 间、日期正确性,检查完成后,系统处 于就绪 状态,以备收款员使用。,12,(2)用例图 用来显示一系列用例和参与者之间的关系,有助于开发人员表达系统功能的不同的抽象层次的描述。,交互,房主,传感器,配置,监
9、测,SafeHome高层用例图,13,启动/关闭系统,房主,输入密码,询问区域状态,SafeHome交互用例图,询问传感器状态,按紧急按钮,验证密码,询问传感器,include,include,include,(参考教材1 P415),14,用例分析是理解和组织系统应完成任务的直观方法。它还可以用来驱动开发过程。特别是,用例: 可以帮助定义系统的范围,即必须做什么和不必做什么。 可用来计划开发过程。确定的用例数量决定了项目的大 小,开发进度可用完成的用例数量来测量。 用来开发和确认需求。 构成测试用例定义的基础。 可用来构造用户手册。 但是用例也不是万能的!注意:(Lethbridge的观点)
10、 用例必须经确认。用例集应是完全的、表达是一致的和 明确的。 用例分析不一定覆盖到功能需求的所有方面。如,不被 参与者触发的活动不会出现在用例中。 当软件需求来自用例时,软件往往只是简单的反映开发 软件前用户的工作方式,可能没有考虑到创新的解决方 案。,15,2、获取需求的主要活动 (1)确定参与者和用例 与用户一起确定与系统有交互活动的所有角色,并为每个角色设计用例。确定用例的准则: 每个用例都应该为其角色提供有价值的服务避免确定的用例太小;确保每个用例都向主要角色提供有价值的服务避免用例太大。 (2)定义用例的优先级 (3)描述每个用例 用例描述可有不同的抽象层次与描述模板。概要描述主要强
11、调每个用例的主要功能。详细描述包括每个用例的事件流(如何开始,与角色如何交互,如何终止)、每个用例中所涉及到的对象(编入术语表)、执行一个用例所要求的非功能性需求等。,16,(4)建立用例图 用例图用来显示一系列用例和参与者之间的关系。它有助于表达系统功能的高层表述。 用例有特化、扩展和包含关系。特化的使用同类图。一个特化用例代表了几个相似用例,一个或多个特化提供了这些相似用例的细节。 使用包含关系减少用例之间的冗余。即 确定用例中可以被共享的功能。检查每个用例抽取出公共部分创建单独用例。 使用扩展关系区分事件的例外和事件的共有流程,即确定补充功能或可选功能。如果发现一个用例比较复杂,既包含了
12、一般处理又包含了特殊处理,将特殊处理的部分抽取出来,创建单独的用例。,17,打开文件,用户,通过键入文件名打开文件,通过浏览打开文件,试图打开不存在的文件,浏览文件,extend,include,用例的特化、扩展和包含,18,(5)建立用户界面原型 在面向对象的软件开发中,用例模型和用户界面设计息息相关。用例模型创建后,就可确定参与者如何驱动用例,以及用例以什么形式向参与者提供信息。因此可开始用户界面原型化的迭代过程,和构造系统的其他部分并行进行。,19,8.3 用类进行建模,面向对象分析,就是抽取和整理用户需求并建立问题域精确模型的过程。在需求获取阶段已经建立了用例模型等阶段产品,但都是为了
13、容易沟通信息,以用户语言描述的,存在着模糊、冗余、二义性、不一致性等问题。 系统分析阶段要进一步分析、完善前一阶段获取的需求,细化用例模型中的用例、确定系统中的对象、对象的静态和动态特征、对象间的关系及对象的行为约束,建立满足用户需求的、精确的、稳定的、易于维护的、便于后续设计的分析模型。,20,用例图:视图,功能模型:模型,分析模型:模型,类图:视图,对象模型:模型,顺序图:视图,状态图:视图,活动图:视图,动态模型:模型,分析模型的构成,21,几条通用的分析原则: (1)组装与分解相结合的原则 基本对象可组装成复杂对象,对复杂对象进行分解从而完成系统模型的细化。 (2)抽象化与具体化相结合
14、的原则 数据抽象将数据及作用在其上的操作抽象成对象。过程抽象为对象的相互作用提供了依据。 抽象强调对象的本质和内在属性,忽视与问题无关的属性。而具体化指在细化过程中,描述对象的某些特性,加强系统模型的稳定性。 抽象化与具体化相结合可以使具体对象直接从抽象对象的定义中获得已有特性,而不必重复定义它们。,22,(3)封装原则 将对象的各种独立的外部特性与内部实现细节分开。对象接口定义要尽可能的与其内部工作状态相分离。封装有助于减少由于需求的改变而对整个系统所造成的影响。 (4)相关性原则 在分析中要考虑对象间的各种关联,包括静态结构的关联、动态特征的关联。这些关联是对象协作的基础。 (5)行为约束
15、的原则 通过语义特征来刻画。表示了对象合法存在、对象合法操作应满足的条件,有助于深刻理解对象和系统。,23,一旦建立了系统的用例模型,则可以开始标识候选类,并指明它们的责任和协作。Wirfs-Brock等人提出了一种类-责任-协作者(Class-responsibility-collaborator,CRC)开发类图的卡片技术。该技术使用实际的或虚拟的索引卡片(参考教材P417),为定义类提供较多的信息。其中责任是与该类相关的属性和操作,协作者是为一个类提供要完成的责任所需要的信息的那些类。通常,协作意味着对信息的请求或者对某种操作的请求。 在确定属性和操作时,可把它们列在卡片上。由于卡片的空
16、间有限,使得每一个类都不能太复杂。如果不能在一张卡片上列出所有的职责,该类应分成两个相关的类。可在白板上自由移动卡片以组成类图,在卡片之间画线表示关联与泛化。低科技的卡片技术可能比操作软件用户界面要快,对开发人员通过会议讨论确定方案很有效。,24,1、标识类及对象 无论是面向对象分析还是面向对象设计与实现,建立类图都是核心技术。类图是定义其他图的基础,在该基础上用交互图、状态图等进一步描述系统其他方面的特性。 如何识别对象?对象以一系列不同形式展示自身:外部实体、事物、发生的事件、角色、组织单位、位置或结构。一种最简单的方法是从系统处理说明中找出名词。例如,在SafeHome的需求陈述中,找出
17、相关的名词是:用户、传感器 、 控制面板、系统(安全系统)、 传感器编号、 传感器类型、密码、 电话号码、 传感器事件、 警报器 等。 这些候选的对象是否都可作为在系统中承担责任的有用对象?要根据一定原则筛选。见下表:,25,几条筛选特征: 例:SafeHome中潜在的对象及筛选理由 (1)保留的信息 潜在对象 选取理由 筛选理由 (2)需要的服务 用户 角色或外部实体 不符合1/2 (3)多个属性 传感器 外部实体 符合1-6 (4)公共属性 控制面板 外部实体 符合1-6 (5)公共操作 系统(安全系统) 事物或聚集对象 符合1-6 (6)基本的需求 传感器编号 事物或概念实体 不符合3
18、传感器类型 事物或概念实体 不符合3 密码 事物或概念实体 不符合3 电话号码 事物或概念实体 不符合3 传感器事件 事件 符合1-6 警报器 外部实体 符合1-6,几乎满足所有特征的对象才会被考虑为分析模型中的合法对象.,26,在RUP中,将对象分为三种类型: (1) 边界对象(或边界类) 是参与者与系统交互的接口,这些对象位于系统与外部世界的边界上,代表如界面窗口、通信接口、打印机接口、传感器等的抽象,用于阐明和收集系统的边界需求,这样,可把用户界面或通信接口的变化隔离在一个或多个边界类中。在分析问题域时,边界类仍保持较高的概念层次,说明通过交互所实现的目标就可以了。在设计活动中(如用户界
19、面设计)才根据参与者操作需求,添加具体的边界对象。 (2) 控制对象(或控制类) 控制用例的流程,表示协调、顺序、事务处理以及对其他对象的控制(如分派任务给其他对象)。主要用来体现应用程序的执行逻辑,可以使得变化不影响用户界面和数据库中的表。,27,(3) 实体对象(或实体类) 负责保存长效且持久的信息。实体类大多数是直接从业务模型或 领域模型中相应实体类得到的。实体类一般表示为一种逻辑数据结构(通常映射为数据表格或文件),有助于开发人员理解系统所依赖的信息。实体对象不一定都是被动的,有时可能具有与它所表示的信息有关的复杂行为。实体对象能够将变化与它们所表示的信息隔离开。 在RUP的分析中,三
20、类对象分别用下图表示:,边界对象,控制对象,实体对象,28,2、定义属性 类的属性与操作和该类在系统中承担的责任有关。属性表示了类的特性,即类必须保持的以完成软件目标的信息。属性的取值决定了对象可能的状态。 传感器有类型、编号、位置、颜色、重量、工作状态(关闭、待机、监控)、采样频率、报警阈值等特性,哪些与系统责任有关呢? 定义属性的一些经验: 一般常识; 分析问题域,检查与对象相联系的形容词或名词短语; 责任; 保存管理信息; 有些属性在对象模型稳定之前可暂不考虑。,29,3、定义操作 操作反映对象的行为并以某种方式修改对象的属性。对象行为可理解为对象应展现的外部服务的总和。对象的行为分为三
21、类: 对象生命周期中的创建、维护、删除行为。 计算行为 监控行为 通过这些行为体现对象的责任。对象以两种方式完成它们的责任: 使用它自己的操作去操作自己的属性, 对象和其他对象协作。 因此对象的操作可以有以下几种类型: 实现功能的操作:可追溯到用户需求。,30, 管理对象创建和删除的操作。在分析阶段,这些操作可 暂缓定义。 访问属性的操作。一个类的属性通常是私有的或受保护 的,只有通过该类提供的操作来访问。 辅助一个类完成其任务的操作,即协作操作。 如何定义操作呢? 分析问题域:有哪些行为,找有关动词。 如“传感器被赋予一个编号和类型”。 系统的责任:找与责任有关的对象,这些对象为承担责任 应
22、提供哪些服务。 分析类的状态转换,引起类状态转换的动作。 追踪一个用例的执行路线,如顺序图,通过对象间通信发 现操作。 因此类的有些操作是在对象-行为模型建立后才补充进来。下图是传感器类的较为详细的定义及它的STD:,31,传感器类,类型;编号;位置;,工作状态;采样频率;警报阈值;,初始化;,关闭;监视;待机;显示;振铃;拨号;,关闭状态,待机状态,监视状态,初始化命令,关闭命令,监视命令,待机命令,关闭命令,超越阈值/激活显示、振铃、拨号,传感器类的STD,32,4、定义结构与层次 类图中的类并非孤立存在,类之间有很多关系。应该关注类模型的结构以及类和子类出现时产生的类层次。 寻找关系的具
23、体方法如下: 检查交互图,如果一个类向另一个类有请求,则它们之间通常有关联关系。 检查类的聚合关系。 检查类的泛化关系,寻找相似对象的不同点,抽取不同的部分定义为特殊类(自顶向下),或将共性的部分提升为基类(自底向上)。 检查其他类,发现不同类中的共同点,将共同的部分定义一个新类。其他类和新类之间的关系也是泛化关系。 但关系太多的类往往对其他类有更多的要求,较难复用且维护的工作量也很大,一旦其他类发生变化,则对该类产生影响。,33,( 1)关联关系 是类之间的连接关系,可以是双向的也可以是单向的。两个关联之间可以相互发送消息。 订单类的属性放入客户类中,可以找到客户的订单;而客户类的属性放入订
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 面向 对象 分析
链接地址:https://www.31doc.com/p-5170815.html