软件工程第10章ppt.ppt

《软件工程第10章ppt.ppt》由会员分享，可在线阅读，更多相关《软件工程第10章ppt.ppt（69页珍藏版）》请在三一办公上搜索。

1、第10章 面向对象分析,1 面向对象分析的基本过程2 需求陈述3 建立对象模型4 建立动态模型5 建立功能模型6 定义服务,1.不论采用哪种方法开发软件，分析的过程：都是提取系统需求的过程。2.分析工作主要包括3项内容：理解需求 表达需求 验证需求 为什么要验证需求？,3.面向对象分析(OOA)的关键：是识别出问题域内的类与对象，并分析它们相 互间的关系，最终建立起问题域的正确模型。4.在用面向对象观点建立起的3种模型：对象模型 动态模型 功能模型 哪个模型是最基本、最重要、最核心的？,1.面向对象分析：就是抽取和整理用户需求并建立问题域精确模型 的过程。2.面向对象分析的过程：（1）面向对象

2、分析过程从分析陈述用户需求的 文件开始。文件的来源有哪些？,10.1 面向对象分析的基本过程10.1.1 概述,2.面向对象分析的过程：（1）面向对象分析过程从分析陈述用户需求的 文件开始。（2）在分析用户需求的过程中，系统分析员需 要和用户反复协商，必要时，建立一个“原 型系统”，以正确地提炼出用户的需求。（3）在深入理解用户需求后，要进行问题域建 模，在建模的过程中，要考虑OOA的“可 重用性”，仔细研究相同的或类似的问题域 进行OOA的结果。,3.3个子模型与5个层次 面向对象建模得到的3个模型：对象模型 动态模型 功能模型 复杂问题（大型系统）的对象模型通常由 下述5个层次组成：如下图

3、所示：,图10.1 复杂问题的对象模型的5个层次,抽象,具体,什么是主题？.主题又叫范畴，是指导读者理解大型、复杂模型 的一种机制。.读者：指的是？.也就是说，通过划分主题把一个大型、复杂的对 象模型分解成几个不同的概念范畴。.面向对象分析从下述两个方面来体现Miller原则：控制可见性和指导读者的注意力。,上述5个层次对应着在面向对象分析过程中建立 对象模型的5项主要活动：找出类与对象，识别结构，识别主题，定义属 性，定义服务。通常在完整地定义每个类中的服务之前，需要 先建立起动态模型和功能模型。,综上所述，在概念上可以认为，面向对象分析 大体上按照下列顺序进行：（1）寻找类与对象，（2）识

4、别结构，（3）识别主题，（4）定义属性，（5）建立动态模型，（6）建立功能模型，（7）定义服务。但是，正如前面已经多次强调指出过的，分析 不可能严格地按照预定顺序进行，大型、复杂 系统的模型需要反复构造多遍才能建成。,1.需求陈述的内容有哪些？2.书写需求陈述时，要注意哪些问题？3.总结,10.2 需求陈述 10.2.1 书写要点,10.2.2 例子,图10.2 ATM系统,1.面向对象分析首要的工作：是建立问题域的对象模型。这个模型描述了现实世界中的“类与对象”以及 它们之间的关系，表示了目标系统的静态数据 结构。2.建立对象模型时的主要信息来源：需求陈述 应用领域的专业知识 关于客观世界的

5、常识,10.3 建立对象模型,3.建立对象模型的典型工作步骤是：（1）确定对象类和关联（2）进一步划分主题（3）给类和关联增添属性；（4）合并和组织类（5）最后确定类中的操作,工作步骤：1.找出候选的类与对象2.筛选出正确的类与对象,10.3.1 确定类与对象,1.找出候选的类与对象1)可感知的物理实体2)人或组织的角色3)应该记忆的事件4)两个或多个对象的相互作用5)需要说明的概念,10.3.1 确定类与对象,另一种更简单的分析方法:非正式分析1)以用自然语言书写的需求陈述为依据，2)把陈述中的名词作为类与对象的候选者,3)用形容词作为确定属性的线索，4)把动词作为服务(操作)的候选者。,1

6、0.3.1 确定类与对象,下面以ATM系统为例，说明非正式分析过程。银行，自动取款机(ATM)，系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。,通常，在需求陈述中不会全部写出问题域中 所有有关的类与对象，因此，分析员应该根据领域知识或常识进一 步把隐含的类与对象提取出来。例如，在ATM系统的需求陈述中虽然没写“通信链路”和“事务日志”，但是，根据领域 知识和常识可以知道，在ATM系统中应该 包含这两个实体。,2.筛选出正

7、确的类与对象,(1)冗余(2)无关(3)笼统(4)属性(5)操作(6)实现,2.筛选出正确的类与对象冗余如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。例如：ATM系统中的“储户与用户”，“现金兑换卡与磁卡及副本”(2)无关仅需要把与本问题密切相关的类与对象放进目标系统中。例如：ATM系统中的候选类“成本”、“市”、“街 道”、“营业厅”和“储蓄所”应该去掉。,(3)笼统在需求陈述中常常使用一些笼统的、泛指的名词，但在需求陈述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些笼统的或模糊的类去掉。例如：ATM系统为例，“银行”实际指总行或分行，“访问”在这里实际

8、指事务，那么在本例中 应该去掉“银行”、“网络”、“系统”、“软 件”、“信息”、“访问”等候选类。,(4)属性在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类与对象中去掉。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。例如：在ATM系统中，“现金”、“支票”、“取款 额”、“账单”、“余额”、“分行代码”、“卡 号”、“密码”、“类型”等，实际上都应该 作为属性对待。,(5)操作在需求陈述中有时可能使用一些既可作为名词，又可作为动词的词，要正确地决定把它们作为类还是作为类中的操作。例如：谈到电话时通常把“拨号”当作动词，当构 造电话模型时确实应该把

9、它作为一个操作，但是，在开发电话的自动记账系统时，“拨 号”需要有自己的属性(例如日期、时间、受话地点等)，因此应该把它作为一个类。总之，本身具有属性需独立存在的操作，应该作为类与对象。,(6)实现例如：在ATM系统中，“事务日志”是对一系列 事务的记录；“通信链路”在逻辑上是一种联系，在系统 实现时它是关联类的物理实现。总之：应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。综上所述，在ATM系统的例子中，经过初步筛选，剩下下列类与对象：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务、现金兑换卡。,1.初步确定关联2.筛选3.进一步完善,

10、10.3.2 确定关联,1.初步确定关联.在需求陈述中使用的描述性动词或动词词组，通 常表示关联关系。.通过分析需求陈述，还能发现一些在陈述中隐含 的关联。.分析员还应该与用户及领域专家讨论问题域实体 间的相互依赖、相互作用关系，根据领域知识再 进一步补充一些关联。以ATM系统为例，经过分析初步确定出下列关联：,10.3.2 确定关联,(1)直接提取动词短语得出的关联.ATM、中央计算机、分行计算机及柜员终端组成 网络。.总行拥有多台ATM。.ATM设在主要街道上。.分行提供分行计算机和柜员终端。.柜员终端设在分行营业厅及储蓄所内。.分行分摊软件开发成本。.储户拥有账户。.分行计算机处理针对账

11、户的事务。.分行计算机维护账户。,.柜员终端与分行计算机通信。.柜员输入针对账户的事务。.ATM与中央计算机交换关于事务的信息。.中央计算机确定事务与分行的对应关系。.ATM读现金兑换卡。.ATM与用户交互。.ATM吐出现金。.ATM打印账单。.系统处理并发的访问。,(2)需求陈述中隐含的关联.总行由各个分行组成。.分行保管账户。.总行拥有中央计算机。.系统维护事务日志。.系统提供必要的安全性。.储户拥有现金兑换卡。(3)根据问题域知识得出的关联.现金兑换卡访问账户。.分行雇用柜员。,2.筛选(1)已删去的类之间的关联例如：以ATM系统为例，由于已经删去了“系统”、“网络”、“市”、“街道”、

12、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”、“账单”等候选类，因此，与这些类有关的下 列8个关联也应该删去：,ATM、中央计算机、分行计算机及柜员终端组 成网络。ATM设在主要街道上。分行分摊软件开发成本。系统提供必要的安全性。系统维护事务日志。ATM吐出现金。ATM打印账单。柜员终端设在分行营业厅及储蓄所内。,(2)与问题无关的或应在实现阶段考虑的关联例如：在ATM系统中，“系统处理并发的访问”并没有标明对象之间的新关联，它只不 过提醒我们在实现阶段需要使用实现并 发访问的算法，以处理并发事务。,(3)瞬时事件关联应该描述问题域的静态结构，而不应该是一个瞬时事件。例如

13、：在ATM系统中，“ATM读现金兑换卡”描述 了ATM与用户交互周期中的一个动作，它 并不是ATM与现金兑换卡之间的固有关系，因此应该删去。类似地，还应该删去“ATM 与用户交互”这个候选的关联。,(4)三元关联三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。例如：在ATM系统中，“柜员输入针对账户的事 务”可以分解成“柜员输入事务”和“事务 修改账户”这样两个二元关联。(5)派生关联应该去掉那些可以用其他关联定义的冗余关联。例如，在ATM系统中，“总行拥有多台ATM”实质 上是“总行拥有中央计算机”和“ATM与中央 计算机通信”这两个关联组合的结果。,进一步完善

14、,(1)正名(2)分解(3)补充(4)标明重数,进一步完善(1)正名应该仔细选择含义更明确的名字作为关联名。例如：“分行提供分行计算机和柜员终端”不如改为“分行拥有分行计算机”和“分行拥有柜员终 端”。(2)分解为了能够适用于不同的关联，必要时应该分解以前确定的类与对象。例如：在ATM系统中，应该把“事务”分解成“远程 事务”和“柜员事务”。,(3)补充发现了遗漏的关联就应该及时补上。例如：在ATM系统中把“事务”分解成上述两类之 后，需要补充“柜员输入柜员事务”、“柜员 事务输进柜员终端”、“在ATM上输入远程 事务”和“远程事务由现金兑换卡授权”等关 联。(4)标明重数应该初步判定各个关联

15、的类型，并粗略地确定关联的重数。,图10.3 ATM系统原始的类图,对于含有较多对象的系统，则往往先识别出类与 对象和关联，然后划分主题，并用它作为指导开 发者和用户观察整个模型的一种机制；应该按问题领域而不是用功能分解方法来确定主 题。此外，应该按照使不同主题内的对象相互间 依赖和交互最少的原则来确定主题。以ATM系统为例，可以把它划分成总行、分行和 ATM等3个主题。,10.3.3 划分主题,1.分析.通常，在需求陈述中用名词词组表示属性，例如，“汽车的颜色”或“光标的位置”。.往往用形容词表示可枚举的具体属性，例如，“红色的”、“打开的”。.属性的确定既与问题域有关，也和目标系统的任 务

16、有关。.在分析阶段不要考虑那些纯粹用于实现的属性。,10.3.4 确定属性,2.选择(1)误把对象当作属性如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。(2)误把关联类的属性当作一般对象的属性如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性，也不能把它归并成相互关联的两个对象中任一个的属性。(3)把限定误当成属性如果把某个属性值固定下来以后能减少关联的重数，则应该考虑把这个属性重新表述成一个限定词。,(4)误把内部状态当成了属性如果某个性质是对象的非公开的内部状态，则应该从对象模型中删掉这个属性。(5)过于细化在分析阶段应该忽略那些对大多数操作都没有影响

17、的属性。(6)存在不一致的属性类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。经过筛选后，得到ATM系统中各个类的属性，如图10.4。,(1)自底向上：.抽象出现有类的共同性质泛化出父类，这个过程 实质上模拟了人类归纳思维过程。.例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；类似地，可 以从“ATM”和“柜员终端”泛化出父类“输入站”。(2)自顶向下：.把现有类细化成更具体的子类，这模拟了人类的 演绎思维过程。.在分析阶段应该避免过度细化。图10.5是增加了继承关系之后的ATM对象模型。,10.3.5

18、识别继承关系,.软件开发过程就是一个多次反复修改、逐步完善 的过程。.在建模的任何一个步骤中，如果发现了模型的缺 陷，都必须返回到前期阶段进行修改。.下面以ATM系统为例，讨论可能做的修改：1.分解“现金兑换卡”类.“现金兑换卡”类分解为“卡权限”和“现金兑换卡”两个类；.前一个类代表储户访问账户的权限，后一个类是 含有分行代码和卡号的数据载体。,10.3.6 反复修改,2.“事务”由“更新”组成.一个事务包含对账户的若干次更新，.这里所说的更新，指的是对账户所做的一个动作.“更新”虽然代表一个动作，但是它有自己的属性 应该独立存在，因此应该把它作为类。3.把“分行”与“分行计算机”合并区分“

19、分行”与“分行计算机”，对于分析这个系统来说，并没有多大意义，为简单起见，应该把它们合并。类似地，应该合并“总行”和“中央计算机”。图10.6给出了修改后的ATM对象模型，与修改前比较起来，它更简单、更清晰。,建立动态模型的步骤：第一步，是编写典型交互行为的脚本。第二步，从脚本中提取出事件，确定触发每个事件 的动作对象以及接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能 有的状态及状态间的转换关系，并用状态 图描绘它们。最 后，比较各个对象的状态图，检查它们之间的 一致性，确保事件之间的匹配。,10.4 建立动态模型,1.脚本：是指系统在某一执行期间内出现的一系列 事件。描述用

20、户(或其他外部设备)与目标系统之 间的一个或多个典型的交互过程，以便对 目标系统的行为有更具体的认识。2.编写脚本的目的：是保证不遗漏重要的交互步骤它有助于确保整个交互过程的正确性的和清晰性。3.脚本描写的范围：并不是固定的，主要由编写脚本的具体目的决定。,10.4.1 编写脚本,4.编写脚本的过程：实质上就是分析用户对系统交互行为的要求的过 程。在编写脚本的过程中，需要与用户充分交换 意见，编写后还应该经过他们审查与修改。5.编写脚本的步骤：首先，编写正常情况的脚本，然后，考虑特殊情况，最后，考虑出错情况，6.脚本描述事件序列：每当系统中的对象与用户(或其他外部设备)交换信 息时，就发生一个

21、事件。所交换的信息值就是该 事件的参数。,1.大多数交互行为都可以分为应用逻辑和用户界面 两部分。应用逻辑是内在的、本质的内容，用户 界面是外在的表现形式。2.动态模型着重表示应用系统的控制逻辑。3.但是，在分析阶段也不能完全忽略用户界面。在这个阶段用户界面的细节并不太重要，重要的 是在这种界面下的信息交换方式。4.不经过实际使用很难评价一个用户界面的优劣，因此，软件开发人员往往快速地建立起用户界面 的原型，供用户试用与评价。,10.4.2 设想用户界面,图10.7 ATM的界面格式,为了有助于建立动态模型，通常在画状态图之前 先画出事件跟踪图。为此首先需要进一步明确事 件及事件与对象的关系。

22、1.确定事件1)事件包括系统与用户(或外部设备)交互的所有信 号、输入、输出、中断、动作等等。从脚本中容易找出正常事件，但是，不要遗漏了 异常事件和出错条件。2)传递信息的对象的动作也是事件。大多数对象到对象的交互行为都对应着事件。,10.4.3 画事件跟踪图,3)应该把对控制流产生相同效果的那些事件组合在 一起作为一类事件，并给它们取一个惟一的名字 例如，“吐出现金”是一个事件类。但是，应该把对控制流有不同影响的那些事件区 分开来，不要误把它们组合在一起。例如“账户有效”、“账户无效”、“密码错”等都是 不同的事件。4)应该区分出每类事件的发送对象和接受对象。一类事件相对它的发送对象来说是输

23、出事件，但 是相对它的接受对象来说则是输入事件。有时一 个对象把事件发送给自己，则该事件既是输出事 件又是输入事件。,2.画出事件跟踪图 从脚本中提取出各类事件并确定了每类事件的发 送对象和接受对象之后，就可以用事件跟踪图把 事件序列以及事件与对象的关系表示出来。在事件跟踪图中，一条竖线代表一个对象，每个 事件用一条水平的箭头线表示；箭头方向从事件的发送对象指向接受对象。时间 从上向下递增；箭头线之间的间距并没有具体含义，仅用箭头线 表示事件发生的先后，并不表示两个事件之间的 精确时间差。,图：ATM系统正常情况脚本的事件追踪图,1.状态图描绘事件与对象状态的关系。2.通常，用一张状态图描绘一

24、类对象的行为，它确 定了由事件序列引出的状态序列。3.从一张事件跟踪图出发画状态图时，应该集中精 力仅考虑影响一类对象的事件。也就是说，仅考 虑事件跟踪图中指向某条竖线的那些箭头线。把 这些事件作为状态图中的有向边(即箭头线)，边 上标以事件名。两个事件之间的间隔就是一个状 态。应该尽量给每个状态取个有意义的名字。,10.4.4 画状态图,4.根据一张事件跟踪图画出状态图之后，再把其他 脚本的事件跟踪图合并到已画出的状态图中。为 此需在事件跟踪图中找出以前考虑过的脚本的分 支点。例如“验证账户”就是一个分支点，因为验证的结 果可能是“账户有效”，也可能是“无效账户”。5.考虑完正常事件之后再考

25、虑边界情况和特殊情况，其中包括在不适当时候发生的事件。例如，系统正在处理某个事务时，用户要求取消该 事务。有时用户(或外部设备)不能做出快速响应，然而某些资源又必须及时收回，于是在一定间隔后 就产生了“超时”事件。,6.当状态图覆盖了所有脚本，包含了影响某类对象 状态的全部事件时，该类的状态图就构造出来了。以ATM系统为例。“ATM”、“柜员终端”、“总行”和“分行”都是主动对象，它们相互发送事件；而“现金兑换卡”、“事务”和“账户”是被动对象，并不发送事件；“储户”和“柜员”虽然也是动作对象，但是，它们 都是系统外部的因素，无须在系统内实现它们。因此，只需要考虑“ATM”、“总行”、“柜员终

26、端”和“分行”的状态图。,图10.9ATM类的状态图,图10.10 总行类的状态图,图10.11 分行类的状态图,1.各个类的状态图通过共享事件合并起来，构成了系统的动 态模型。2.在完成了每个具有重要交互行为的类的状态图之后，应该 检查系统级的完整性和一致性。3.应该审查每个事件，跟踪它对系统中各个对象所产生的效 果，以保证它们与每个脚本都匹配。例如：在总行类的状态图中，事件“分行代码错”是由总行 发出的，但是在ATM类的状态图中并没有一个状态接受这 个事件。因此，在ATM类的状态图中应该再补充一个状态“do/显示分行代码错信息”，它接受由前驱状态“do/验证账 户”发出的事件“分行代码错”

27、，它的后续状态是“退卡”。,10.4.5 审查动态模型,通常在建立了对象模型和动态模型之后再建立功 能模型。功能模型表明了系统中数据之间的依赖关系，以 及有关的数据处理功能，它由一组数据流图组成。其中的处理功能可以用 IPO图(或表)、伪码等多种方式进一步描述。,10.5 建立功能模型,图10.12 ATM系统的基本系统模型,10.5.1 画出基本系统模型图,10.5.2 画出功能级数据流图,图10.13 ATM系统的功能级数据流图,应该注意的是，要着重描述每个处理框所代表的 功能，而不是实现功能的具体算法。描述既可以是说明性的，也可以是过程性的。说明性描述规定了输入值和输出值之间的关系，以及

28、输出值应遵循的规律。过程性描述则通过算法说明“做什么”。一般说来，说明性描述优于过程性描述，因为这类描述中通常不会隐含具体实现方面的 考虑。例：表10.3“更新账户”这个处理功能的描述。,10.5.3 描述处理框功能,1)“对象”是由描述其属性的数据，及可以对这些 数据施加的操作(即服务)，封装在一起构成的独 立单元。2)因此，为建立完整的对象模型，既要确定类中应 该定义的属性，又要确定类中应该定义的服务。3)在确定类中应有的服务时，既要考虑该类实体 的常规行为，又要考虑在本系统中特殊需要的 服务。,10.6 定义服务,1.常规行为 在分析阶段可以认为，类中定义的每个属性都是 可以访问的，也就

29、是说，假设在每个类中都定义 了读、写该类每个属性的操作。但是，通常无需在类图中显式表示这些常规操作2.从事件导出的操作 状态图中发往对象的事件，也就是该对象接收到 的消息，因此该对象必须有由消息选择符指定的 操作，这个操作修改对象状态(即属性值)并启动 相应的服务。例如：在ATM系统中，发行分行的事件“请分行 验卡”启动该对象的服务“验证卡号”。,3.与数据流图中处理框对应的操作数据流图中的每个处理框都与一个对象(也可能是 若干个对象)上的操作相对应。应该仔细对照状态 图和数据流图，以便更正确地确定对象应该提供 的服务。例如，在ATM系统中，从状态图上看出分行对象 应该提供“验证卡号”服务，而在数据流图上与之 对应的处理框是“验卡”，根据实际应该完成的功 能看，该对象提供的这个服务应该是“验卡”。4.利用继承减少冗余操作应该尽量利用继承机制以减少所需定义的服务数目,