软件工程导论课件第10章面向对象的分析.docx
《软件工程导论课件第10章面向对象的分析.docx》由会员分享，可在线阅读，更多相关《软件工程导论课件第10章面向对象的分析.docx（21页珍藏版）》请在冰豆网上搜索。
软件工程导论课件第10章面向对象的分析
第10章面向对象分析
10.1面向对象分析的基本过程
10.2需求陈述
10.3建立对象模型
10.4建立动态模型
10.5建立功能模型
10.6定义服务
10.7小结
1
10.1面向对象分析的基本过程
面向对象分析
抽取和整理用户需求并建立问题域精确模型的过程.
理解----用户、分析员和领域专家
表达----需求规格说明书（对象模型、动态模型、功能模型）
验证----二义性，完善性
对象模型最基本、最重要、最核心。
对象模型
动态模型
功能模型
2
10.1面向对象分析的基本过程
3个子模型
对所解决问题的描述角度进行划分：
静态结构（对象模型）
3个子模型交互次序（动态模型）
数据变换（功能模型）
解决问题不同，三个子模型的重要程度也不同。
3
10.1面向对象分析的基本过程
5个层次
复杂问题的对象模型的5个层次
五个层次像是对象模型的5张水平切片，
一层比一层显示出对象模型的更多细节。
4
面向对象分析的过程
寻找类与对象
识别结构
识别主题
定义属性
建立动态模型
建立功能模型
定义服务
10.1面向对象分析的基本过程
5
10.2需求陈述
需求陈述是阐明“做什么”，而不是“怎样做”
问题范围
功能需求
性能需求
应用环境
假设条件
ATM机系统问题描述
银行网络中包含柜员和ATM，ATM被共享中心所分享。
每家银行利用自己的计算机维护自己的账户并处理账户所属的交易，这些交易包括存款和取款。
某些银行拥有自己的柜员站，柜员站直接和该银行的计算机通信，柜员键入账户数据和交易数据。
ATM和中心计算机通信，中心计算机再和银行清账。
ATM接受金融卡，要求用户做些操作后和中心计算机通信，执行交易给予现金和打印收据。
系统要求保留交易记录和严守安全规定。
能同时存取客户的相同账户。
10.2需求陈述
自动取款机（ATM）系统
ATM系统
10.2需求陈述
10.3建立对象模型
建立对象模型典型的步骤：
确定对象类和关联，对于大型复杂问题还要进一步划分出若干个主题；
给类和关联增添属性，以进一步描述它们；
利用适当的继承关系进一步合并和组织类。
10.3建立对象模型
10.3.1找出候选类与对象
1.找出候选的类与对象
寻找以下五类客观事物
可感知的物理实体
人或组织的角色
应该记忆的事件
两个或多个对象的相互作用，通常具有交易或接触的性质
需要说明的概念
10.3建立对象模型
10.3.1找出候选类与对象
1.找出候选的类与对象（续）
名词解析法
从陈述中找出所有名词，作为类和对象的初步候选者
银行，自动取款机（ATM），系统，中央计算机，
分行计算机，柜员终端，网络，总行，分行，软件，
成本，市，街道，营业厅，储蓄所，柜员，储户，
现金，支票，账户，事物，现金兑换卡，余额，
磁卡，分行代码，卡号，用户，副本，信息，密码，
类型，取款额，账单，访问。
通信链路事务日志
10.3建立对象模型
10.3.1找出候选类与对象
2.筛选出正确的类与对象
筛选时主要依据下列标准，删除不正确或不必要的类与对象
（1）冗余
（2）无关
（3）笼统
（4）属性
（5）操作
（6）实现
银行，自动取款机（ATM），系统，中央计算机
分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事物，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。
通信链路事务日志
（储户、用户；现金兑换卡、磁卡和副本）
（成本、市、街道、营业厅和储蓄所）
（银行、访问、信息、网络、系统、软件等）
（现金、支票、取款额、账单、余额、分行代码、
卡号、密码、类型）
（事务日志、通信链路）
10.3建立对象模型
10.3.1找出候选类与对象
2.筛选出正确的类与对象
ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务、现金兑换卡
13
10.3建立对象模型
10.3.2确定关联
1.初步确定关联
需求陈述中使用的描述性动词或动词词组，通
常表示关联关系。
直接提取动词短语得出关联
需求陈述中隐含的关联
根据问题域知识得出的关联
2.筛选（根据下述标准删除候选关联）
已删去的类之间的关联
与问题无关的或在实现阶段考虑的关联
瞬时事件
三元关联
派生关联
14
直接提取动词短语得出的关联
ATM、中央计算机、分行计算机及柜员终端组成网络。
总行拥有多台ATM。
ATM设在主要街道上。
分行提供分行计算机和柜员终端。
柜员终端设在分行营业厅及储蓄所内。
分行分摊软件开发成本。
储户拥有账户。
分行计算机处理针对账户的事务。
分行计算机维护账户。
柜员终端与分行计算机通信。
柜员输入针对账户的事务。
ATM与中央计算机交换关于事务的信息。
中央计算机确定事务与分行的对应关系。
ATM读现金兑换卡。
ATM与用户交互。
ATM吐出现金。
ATM打印账单。
系统处理并发的访问。
隐含的关联
总行由各个分行组成。
分行保管账户。
总行拥有中央计算机。
系统维护事务日志。
系统提供必要的安全性。
储户拥有现金兑换卡。
中央计算机与分行通信
根据问题域知识得出的关联
现金兑换卡访问账户。
分行雇用柜员。
10.3建立对象模型
10.3.2确定关联
3.进一步完善
正名、分解、补充、标明重数
ATM系统原始的类图
16
10.3建立对象模型
10.3.3划分主题
在概念上把系统包含的内容分解成若干个范畴
应该按问题领域而不是用功能分解的方法来确定主题
不同主题内的对象相互间依赖和交互最少的原则
总行（总行和中央计算机）
ATM系统分行（分行、分行计算机、柜员终端、柜员
事务、柜员和账户等）
ATM（ATM、远程事务、现金兑换卡和储户）
17
10.3建立对象模型
10.3.4确定属性
属性是对象的性质或特征
注意在分析阶段不要用属性来表示对象间的关系，使用关联能够表示两个对象间的任何关系，而且把关系表示得更清晰、更醒目。
确定属性的过程包括分析和选择两个步骤。
18
10.3建立对象模型
10.3.4确定属性
选择
在需求陈述中一般用名词词组表示属性
需藉助于领域知识和常识才能分析得出属性
属性对问题域的基本结构影响很小
属性的确定与问题域和目标系统的任务有关。
不要考虑那些超出所要解决的问题范围的属性。
先找最重要的属性，再逐渐把其余属性增添进去。
分析阶段不考虑那些纯粹用于实现的属性。
19
10.3建立对象模型
10.3.4确定属性
分析
（1）误把对象当作属性
同一个实体在不同应用领域中，到底应该作为对象还是属性，需要具体分析才能确定。
例如，储户/账户.
（2）误把关联类的属性当作对象的属性
如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性，不应该把它作为一般对象的属性。
例如,带宽是体现关联的属性而不是ATM的
20
10.3建立对象模型
10.3.4确定属性
分析
（3）把限定误当成属性
正确使用限定词往往可以减少关联的重数。
如果把某个属性值固定下来以后能减少关联的重数，则应该考虑把这个属性重新表述成一个限定词。
在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。
（4）误把内部状态当成了属性
如果某个性质是对象的非公开的内部状态，则应该从对象模型中删掉这个属性。
21
10.3建立对象模型
10.3.4确定属性
分析
（5）过于细化
在分析阶段应该忽略那些对大多数操作都没有影响的属性。
（6）存在不一致的属性
类应该是简单而且一致的。
如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。
e.g.轮，帆；
22
经过筛选之后，得到ATM系统中各个类的属性，如图所示。
10.3建立对象模型
建立类间的继承是为了共享其公共性质/属性。
继承也对类按层次加以组织。
继承关系反映出一定深度的领域知识，需领域专家密切配合才能完成。
继承前人的成果是提高效率的重要方法，也是复用的基础。
10.3.5识别继承关系
24
两种建立继承（即泛化）关系的方式：
（1）自底向上：
抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。
例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；类似地，从“ATM”和“柜员终端”泛化出父类“输入站”。
（2）自顶向下：
把现有类细化成更具体的子类或从已知类派生出一个新类，这模拟了人类的演绎思维过程：
从一般到特殊。
带有形容词修饰的名词词组往往暗示了一些具体类。
分析阶段应该避免过度细化。
25
增加了继承关系之后的ATM对象模型
26
一次建模过程很难得到完全正确的对象模型。
有些细化工作（例如，定义服务）是在建立了动态模型和功能模型之后才进行的。
由于面向对象的概念和符号在整个开发过程中都是一致的，因此远比使用结构分析、设计技术更容易实现反复修改、逐步完善的过程。
建模的步骤并不一定按照前面讲述的次序进行。
它给初学者提供了一个指南。
下面以ATM系统为例，讨论可能做的修改：
10.3.6反复修改
27
1.分解“现金兑换卡”类
“现金兑换卡”有两个相对独立的功能，它既是鉴别储户及使用ATM的权限的卡，又是ATM获得分行代码和卡号等数据的数据载体。
因此，把“现金兑换卡”类分解为“卡权限”和“现金兑换卡”两个类，将使每个类的功能更单一：
前一个类标志储户访问账户的权限，后一个类是含有分行代码和卡号的数据载体。
多张现金兑换卡可能对应着相同的访问权限。
28
2.“事务”由“更新”组成
一个事务可包含对账户的若干次更新。
更新指的是对账户所做的一个动作（取款、存款或查询）。
“更新”有自己的属性（类型、金额等），应该独立存在，因此应该把它作为类。
3.把“分行”与“分行计算机”合并
区分“分行”与“分行计算机”，对于分析这个系统来说，并没有多大意义，为简单起见，把它们合并。
类似地，应该合并“总行”和“中央计算机”。
下图给出了修改后的ATM对象模型，与修改前比较起来，它更简单、更清晰。
29
修正：
总行/分行的通信，
储户输入事务（ATM）
ATM读卡
拥有/通信
修改后的ATM对象模型
30
对于仅存储静态数据的系统（例如数据库）来说，
动态模型并没有什么意义。
但是若开发交互式系统时，动态模型却起着很重要的作用。
例如:
收集输入信息是目标系统的主要工作
10.4建立动态模型的方法
31
建立动态模型的三步：
编写典型交互行为的脚本,不遗漏常见的交互行为。
从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。
排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。
最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。
32
脚本:
是指系统在某一执行期间内出现的一系列事件。
脚本功能:
描述用户（或其他外部设备）与目标系统之间的一个或多个典型的交互过程。
编写脚本的目的:
是保证不遗漏重要的交互步骤，有助于确保整个交互过程的正确性的和清晰性。
编写脚本内容:
描写既可以包括系统中发生的全部事件，也可以只包括由某些特定对象触发的事件。
对于每个事件，都应该指明触发该事件的动作对象（系统、用户或其他事物）、接受事件的目标对象以及该事件的参数。
编写步骤:
编写正常情况的脚本。
考虑特殊情况，例如输入或输出的数据为最大值（或最小值）。
考虑出错情况，例如，输入的值为非法值或响应失败。
10.4.1编写脚本
33
“脚本”原指“表演戏曲、话剧，拍摄电影、电视剧等所依据的本子，里面记载台词、故事情节等”。
ATM系统正常
和异常脚本
34
交互行为可以分为应用逻辑和用户界面两部分。
不同界面（例如，命令行或图形用户界面），可以实现同样的应用逻辑。
应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。
动态模型着重表示应用系统的控制逻辑。
分析阶段不能忽略用户界面。
应确定界面的轮廓.
可以考虑其他方式,如语音.目的是确保能够完成全部必要的信息交换。
10.4.2设想用户界面
35
事件跟踪图有助于画状态图。
它把事件序列以及事件与对象的关系，形象、清晰地表示出来。
事件跟踪图实质上是扩充的脚本，是简化的UML顺序图。
在事件跟踪图中，一条竖线代表一个对象，每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象。
时间从上向下递增。
下图是ATM系统正常情况下的事件跟踪图。
10.4.3画事件跟踪图
36
如何确定事件
通过分析脚本，可从中提取出所有外部事件。
事件包括系统与用户交互的所有信号、输入、输出、中断、动作等等。
例如，储户插入现金兑换卡。
不能遗漏了异常事件和出错。
某些事件可以按类组合在一起。
例如，“吐出现金”是一个事件类，吐出的具体的现金数
额用参数/属性值表达。
区分出每类事件的发送对象和接受对象。
37
ATM系统正常情况下的事件跟踪图
时间
对象
事件/消息
38
顺序图（SequenceDiagram）
顺序图也称为序列图，它按时间顺序显示对象之间的交互。
39
21
一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。
从一张事件跟踪图出发画状态图时，仅考虑影响对象的一类事件。
两个事件之间的间隔就是一个状态（也可能不变）。
从竖线射出的箭头线，常是对象达到某个状态时所做的行为（也常是引起另一类对象状态转换的事件）。
要把从不同脚本或事件跟踪图得到的同一类的状态图合并。
10.4.4画状态图
40
考虑完正常事件之后再考虑边界情况和特殊情况.
如，用户要求取消该当前事务,“超时”,停电/机。
不能省略对用户出错情况的处理。
一张覆盖了脚本中某类对象的全部事件的状态图仍可能会一些遗漏的情况。
设想各种可能出现的情况，多问几个“如果……，则……”的问题是一种测试完整性的方法.
尽量给每个状态取个有意义的名字。
10.4.4画状态图
41
以ATM系统为例:
“ATM”、“柜员终端”、“总行”和“分行”都是主动对象，它们相互发送事件；
“现金兑换卡”、“事务”和“账户”是被动对象，并不发送事件。
“储户”和“柜员”虽然也是动作对象，但是，它们都是系统外部的因素，无须在系统内实现它们。
42
ATM的状态图
43
Impcomments:
没有查帐事务，退卡，请求继续不在需求中；请求继续=询问，加入停机，考虑断电后电池弱时停机
图10.10总行类的状态图
44
IMP：
合并为一，加等待ATM请求,ONLYONEINITSTATE
若1个类有2个无共态的状态图，可能应为2个类。
+1waytocommunicatewithATM:
a/synchronic,differentefficienciesandsecurities,butitismoreadesignissue.
各个类的状态图通过共享事件联系（合并）起来，构成了系统的动态模型。
应该检查系统级的完整性和一致性。
对于没有前驱或没有后继的状态应该着重审查，如果这个状态既不是交互序列的起点也不是终点，则发现了一个错误。
10.4.5审查动态模型
45
应该审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配。
例:
ATM系统
在总行类的状态图中，事件“无效代码”,是由总行发出的，但是在ATM类的状态图中并没有一个状态接受这个事件。
因此，在ATM类的状态图中应该再补充一个状态“do/显示分行代码错信息”，它接受由前驱状态“do/验证账户”发出的事件“无效代码”，它的后续状态是“退卡”。
10.4.5审查动态模型
46
10.5建立功能模型
功能模型
含义
功能模型描述的是系统内值的变化，以及通过值的变化表现出来的系统功能、映射、约束、功能依赖的条件。
内容
确定输入值和输出值
画出数据流图（DFD）以表示功能之间的依赖关系
描述各功能
确定约束
详细说明优化标准
47
功能模型（续）
基本概念和图形表示
处理
数据流
数据流的克隆vs.数据流的分离
数据存储
数据存储是被动对象
数据存储不产生操作
动作者
动作者是主动对象
动作者位于数据流的源点或终点（即终止符）
动作者产生的操作不包括在DFD中而应属于动态模型
10.5建立功能模型
48
功能模型（续）
功能模型、对象模型、动态模型等之间的关系
就功能模型而言，对象模型表示了功能模型中的动作者、数据流、数据存储的结构；动态模型则表示了功能模型中处理的执行次序。
就对象模型而言，功能模型表示了类上的操作和每个操作的变量，因而也表示了类之间的客户/服务器关系；动态模型则表示了每个对象的状态和当对象接收事件时/当对象改变状态时所执行的操作。
就动态模型而言，功能模型表示了动态模型中未定义的动作和活动的定义；对象模型则表示了是什么改变了状态/是什么接收了操作。
在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。
1.常规行为
在分析阶段可以认为，类中定义的每个属性都是可以访问的，也就是说，假设在每个类中都定义了读、写该类每个属性的操作。
但是，通常无需在类图中显式表示这些常规操作。
10.6定义服务
50
2.从事件导出的操作
状态图中对象接收消息，因此该对象必须有由消息选择符指定的操作，它启动相应的服务。
在ATM系统中，事件“处理分行事务”启动分行对象的服务“更新账户”。
所启动的服务常是接受事件的对象在相应状态的行为。
51
3.与数据流图中处理框对应的操作
数据流图中的每个处理框都与一个对象（也可能是若干个对象）上的操作相对应。
对照状态图和数据流图，以便确定对象应该提供的服务。
在ATM系统中，从状态图上看出分行对象应该提供“验证卡号”服务，而在数据流图上与之对应的处理框是“验卡”，根据实际应该完成的功能看，该对象提供的这个服务应该是“验卡”。
52
4.利用继承减少冗余操作
应该尽量利用继承机制以减少所需定义的服务数目。
只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。
例如,ATM和柜员机提供的相同服务（取现金,查帐）都可在父类输入站中定义.
53
面向对象分析就是提取系统需求并建立问题域精确模型的过程，它包括理解、表达和验证等3项主要工作内容。
面向对象分析的关键工作，是分析、确定问题域中的对象及对象间的关系，并建立起问题域的对象模型。
大型、复杂系统的对象模型通常由下述5个层次组成：
主题层、类与对象层、结构层、属性层和服务层。
它们对应着在建立对象模型的过程中所应完成的5项工作。
10.7小结
54
54
面向对象方法学比较自然地模拟了人类认识客观世界的思维方式，它所追求的目标和遵循的基本原则，就是使描述问题的问题空间和在计算机中解决问题的解空间，在结构上尽可能一致。
大多数分析模型都不是一次完成的，分析工作不可能严格地按照预定顺序进行。
分析员必须与用户及领域专家反复交流、多次磋商，及时纠正错误认识并补充缺少的信息。
最终的模型必须得到用户和领域专家的确认。
在交流和确认的过程中，原型往往能起很大的促进作用。
分析的目标是全面深入地理解问题域，其中不应该涉及具体实现的考虑。
分析的目的是用分析模型取代需求陈述，作为设计的基础.
在分析与设计之间并不存在绝对的界线。
10.7小结
55
55
升级会员 