10 第十章 面向对象分析.pptx

第1页：第10章 面向对象分析

第10章 面向对象分析：0.1面向对象分析的基本过程10.1.1概述面向对象分析从分析描写用户需求的文件开始。用户单方书写的需求；系统分析员配合用户书写的需求；项目标书中书写的需求

第2页：三个子模型与五个层次

三个子模型与五个层次：个子模型与5个层次主题层类与对象层结构层属性层服务层复杂问题的对象模型的5个层次（对应5项活动：找出类与对象、识别结构、识别主题、定义属性、定义服务。）3个子模型：对象模型（静态结构）；动态模型（交互次序）；功能模型（数据变换）

第3页：面向对象分析的顺序

面向对象分析的顺序：面向对象分析大体上按照下列顺序进行：寻找类与对象、识别结构、识别主题、定义属性、建立动态模型、建立功能模型、定义服务

第4页：UML分析与设计一般过程

UML分析与设计一般过程：UML面向对象分析与设计一般过程UML是OO思想的一种表现形式，“OO是神，而UML是型”；以CMS（内容管理系统）为例：“内容”包括文件、表格、图片、数据库中的数据，甚至图片、动画、视频等一切要发布到网站的信息。内容管理系统是一种位于Web服务器和后端办公系统或流程（内容创作、编辑）之间的软件系统。重点解决各种数字资源的采集、管理、利用、传递和增值。内容的创作人员、编辑人员、发布人员使用内容管理系统来提交、修改、审批、发布内容

第5页：从需求到业务用例图

从需求到业务用例图：OOA&D的第一步：了解用户需求，并将其转换为业务用例图。CMS描述如下：这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等

第6页：业务用例图

业务用例图：根据上述需求描述，画出业务用例图

第7页：业务用例的注意事项

业务用例的注意事项

• 1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的
• 2.业务用例仅包含客户“感兴趣”的内容
• 3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例

第8页：从业务用例图到活动图

从业务用例图到活动图：完成了业务用例图后，需要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的用途：从业务用例分析出系统用例

第9页：新闻管理的活动图

新闻管理的活动图：例如，“新闻管理”的活动图：是否已登陆用户、密码是否正确

第10页：从活动图分析系统用例

从活动图分析系统用例：“新闻管理”业务用例，分解出若干系统操作。其中很多“活动”都很可能是一个系统用例。例如，从上图知系统至少包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选的系统用例

第11页：从活动图到系统用例图

从活动图到系统用例图：找出所有的备选系统用例后，要对其进行合并和筛选。合并：将相同的用例合并成一个；筛选：将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新闻列表”就不能算一个系统用例，因为它只是某系统用例的一个序列项

第12页：系统用例图

系统用例图：经合并和筛选后的系统用例图

第13页：从系统用例图到用例规约

从系统用例图到用例规约：从系统用例图到用例说明（规约）得出系统用例图后，应该对每一个系统用例给出用例说明（规约）。用例说明没有一个通用的格式，可按照习惯的格式进行编写，要求是“清晰易懂”

第14页：登录用例说明

登录用例说明：如，“登录”系统用例的一个说明

第15页：绘制业务领域类图

绘制业务领域类图

• 5.绘制业务领域类图接着绘制业务领域类图。业务领域类图要描述以下三点
• 系统中有哪些实体
• 这些实体能做什么操作
• 实体间的关系

第16页：业务领域类图

业务领域类图：类图例子

第17页：实体与参与者的区别

实体与参与者的区别：实体不是Actor，而是Actor使用系统时所调用的实体。例如，管理员是Actor，没有作为实体出现在类图中，管理员的工作可以通过调用三个类的方法完成。“注册会员”实体也不是用例图中的注册会员Actor，而是一个系统内的业务实体，供Actor们使用。例如，其中的“注册”功能是给注册会员Actor使用，而“移除”则是给管理员Actor使用的

第18页：绘制实现类图

绘制实现类图：面向对象分析只关心系统本身的功能和业务，而不关心与计算机相关的内容。面向对象设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个通用的设计过程。但是，一般在设计过程中实现类图是要绘制的。实现类图和领域类图不一样，它描述系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系

第19页：实现类图

实现类图：简化的实现类图

第20页：绘制序列图

绘制序列图：有了静态结构，还要给出动态结构，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作

第21页：用户登录的序列图

用户登录的序列图：例子

第22页：序列图的调用过程

序列图的调用过程：注册会员作为Actor，调用UserController的Login方法启动序列，而UserServices作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。注意：序列图在实际应用中是很多的，几乎每个类方法都配有相应的序列图

第23页：分析与设计之后的工作

分析与设计之后的工作：基于软件工具进行编码、调试、测试等。小结：面向对象分析和设计的过程没有一个固定模式，随着系统的不同，过程有所变化。上例可了解基于UML的分析与设计的一般过程。实际的分析和设计，还需要实践的积累

第24页：需求陈述

需求陈述：10.2.1书写要点需求陈述的内容包括：问题范围、功能需求、性能需求、应用环境、假设条件等

第25页：自动取款机系统实例

自动取款机系统实例：实例：自动取款机（ATM）

第26页：确定类与对象

确定类与对象：建立对象模型

• 1.找出候选的类与对象多数客观事物分为5类
• 可感知的物理实体，如汽车、书、房屋
• 人或组织的角色，如雇员、雇主、柜员
• 应该记忆的事件，如演出、访问、事故
• 两个或多个对象的相互作用，如购买
• 需要说明的概念，如政策、法律

第27页：非正式分析方法

非正式分析方法：用自然语言书写需求陈述，把陈述中的名词作为类与对象的候选者，从形容词中考虑属性，把动词作为服务（操作）的候选者

第28页：ATM系统的候选类

ATM系统的候选类：以ATM系统为例：类与对象的候选者：银行、自动取款机（ATM）、系统、中央计算机、分行计算机、柜员终端、网络、总行、分行、软件、成本、市、街道、营业厅、储蓄所、柜员、储户、现金、支票、帐户、事务、现金兑换卡、余额、磁卡、分行代码、卡号、用户、信息、密码、类型、取款额、帐单、访问等

第29页：筛选类与对象的标准

筛选类与对象的标准

• 2.筛选出正确的类与对象主要依据以下标准
• 冗余：如“储户”与“用户”、“磁卡”与“现金兑换卡”
• 无关：如“成本”、“街道”、“营业厅”、“储蓄所”
• 笼统：如“银行”、“网络”、“系统”、“软件”、“信息”
• 属性：如“余额”、“分行代码”、“卡号”、“密码”、“类型”
• 操作：如“访问”
• 实现

第30页：ATM系统筛选结果

ATM系统筛选结果：在ATM实例中，经过初步筛选，剩下的类与对象为：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、帐户、事务、现金兑换卡

第31页：初步确定关联

初步确定关联

• 直接提取动词短语得出的关联总行拥有ATM储户拥有帐户分行计算机维护帐户…… …… ……
• 需求陈述中隐含的关联分行组成总行分行保管帐户…… …… ……
• 根据问题域知识得出的关联现金兑换卡访问帐户分行雇用柜员…… …… ……

第32页：筛选关联

筛选关联

• 2.筛选根据下述标准删除候选关联
• 已删去的类之间的关联如“系统”、“成本”等类已经删除，所以也应该删除的关联：系统维护事务日志分行分摊软件成本
• 与问题无关的或应在实现阶段考虑的关联如应删除的关联：系统处理并发访问

第33页：删除瞬时事件与三元关联

删除瞬时事件与三元关联

• 瞬时事件关联不应是一个瞬时事件，如应该删除：ATM读取现金兑换卡
• 三元关联三个或三个以上对象之间的关联，可分解为二元关联：“柜员输入针对帐户的事务”可分解为：“柜员输入事务”、“事务修改帐户”
• 派生关联去掉可以用其它关联定义的冗余关联，如“分行计算机维护帐户”，可用“分行保管帐户”、“事务修改帐户”代替

第34页：进一步完善关联

进一步完善关联

• 3.进一步完善
• 正名选择含义更明确的名字
• 分解必要时分解类与对象，如“事务”分解为：“远程事务”、“柜员事务”
• 补充发现遗漏的关联及时补上
• 标明重数

第35页：

第36页：划分主题

划分主题

第37页：确定属性

确定属性

• 1.分析需求陈述不能得到所有属性，须借助领域知识和常识
• 2.选择根据下述情况，删除不必要的属性
• 误把对象当属性
• 误把关联类的属性当作一般对象的属性
• 误把限定当成属性（如“站号”不是“分行计算机”的属性）
• 误把内部状态当属性

第38页：

第39页：识别继承关系

识别继承关系：可以使用两种方式建立继承（泛化）

• 自底向上：从现有类泛化出父类；如：“远程事务”和“柜员事务”泛化出“事务”；“ATM”和“柜员终端”泛化出“输入终端”
• 自顶向下：把现有类细化成子类

第40页：

第41页：反复修改

反复修改

• 1.分解类如：分解“现金兑换卡”类为“卡权限”和“现金兑换卡”，使每个类功能更单一
• 2.合理组织类如：“事务”由“更新”组成，“更新”包括“取款”、“存款”、“查询”等动作
• 3.合并类如：合并“分行”与“分行计算机”、“总行”与“中央计算机”

第42页：

第43页：建立动态模型的步骤

建立动态模型的步骤

• 第一步，是编写典型交互行为的脚本
• 第二步，从脚本中提取出事件，确定触发每个事件的动作对象，以及接受事件的目标对象

第44页：排列事件与检查一致性

排列事件与检查一致性

• 第三步，排列事件发生的次序，确定每个对象可能有的状态及状态之间的转换关系，并用状态图描绘它们
• 第四步，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配

第45页：编写脚本

编写脚本：在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。脚本描述用户（或其它外部设备）与目标系统之间的一个或多个典型的交互过程。编写脚本的目的：保证不遗漏重要的交互步骤

第46页：脚本的编写要求

脚本的编写要求：编写脚本时，首先考虑正常情况的脚本，然后考虑特殊情况，最后考虑出错情况。脚本描述事件序列。对于每个事件，都应该指明触发事件的动作对象（如：计算机系统；用户；外部事物等）、接受事件的目标对象和该事件的参数

第47页：

第48页：

第49页：设想用户界面

设想用户界面

第50页：画事件跟踪图

画事件跟踪图

• 1.确定事件
• 2.画事件跟踪图事件跟踪图实质上是扩充的脚本，是简化的UML顺序图

第51页：对象与事件的表示

对象与事件的表示：对象：竖线；事件：水平箭头

第52页：画状态图

画状态图：状态图描绘事件与对象状态的关系。通常，用一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。但是，也不是任何一个类都需要有一张状态图描绘它的行为

第53页：状态图的构造过程

状态图的构造过程：根据一张事件跟踪图画出状态图后，再把其他脚本的事件跟踪图合并到已画出的状态图中。考虑完正常事件后考虑边界情况和特殊情况，当所有脚本都被状态图反映出来，该类的状态图就构造好了

第54页：

第55页：审查动态模型

审查动态模型：审查每个事件，跟踪它对系统中各个对象所产生的效果，保证它们与每个脚本都匹配

第56页：画出基本系统模型图

画出基本系统模型图：建立功能模型

第57页：画出功能级数据流图

画出功能级数据流图

第58页：描述处理框功能

描述处理框功能

第59页：定义服务

定义服务

• 1.常规行为（服务）如，读、写类属性的操作
• 2.从事件导出的操作（服务）如，“请分行验卡”事件－>“验证卡号”
• 3.与数据流图中处理框对应的操作（服务）如“更新帐户”等
• 4.利用继承减少冗余操作（服务）

第60页：