《面向对象分析案例：银行储蓄系统.ppt》由会员分享，可在线阅读，更多相关《面向对象分析案例：银行储蓄系统.ppt（82页珍藏版）》请在三一办公上搜索。
1、面向对象分析,1 基本过程 2 需求陈述 3 建立对象模型 4 建立动态模型 5 建立功能模型 6 定义服务,1 面向对象分析的基本过程,面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。通常，面向对象分析过程从分析陈述用户需求的文件开始；接下来，系统分析员应该深入理解用户需求，抽象出目标系统的本质属性，并用模型准确地表示出来。,在面向对象建模的过程中，系统分析员必须认真向领域专家学习。在面向对象建模的过程中，还应该仔细研究以前针对相同的或类似的问题域进行面向对象分析所得到的结果。由于面向对象分析结果的稳定性和可重用性，这些结果在当前项目中往往有许多是可以重用的。,面向对象建模得
2、到的模型包含系统的3个要素，即静态结构(对象模型)、交互次序(动态模型)和数据变换(功能模型)。动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。复杂问题（大型系统）的对象模型通常由下述5个层次组成：主题层、类与对象层、结构层、属性层和服务层。,3个子模型与5个层次,复杂问题的对象模型的5个层次,在概念上可以认为，面向对象分析大体上按照下列顺序进行：寻找类与对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务。,通常，需求陈述的内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等。总之，需求陈述应该阐明“做什么”而不是“怎样做”。它应该描述用户的需求而不
3、是提出解决问题的方法。应该指出哪些是系统必要的性质，哪些是任选的性质。,需求陈述2.1 书写要点,对系统性能及系统与外界环境交互协议的描述，是合适的需求。此外，对采用的软件工程标准、模块构造准则、将来可能做的扩充以及可维护性要求等方面的描述，也都是适当的需求。系统分析员必须与用户及领域专家密切配合协同工作，共同提炼和整理用户需求。在这个过程中，很可能需要快速建立起原型系统，以便与用户更有效地交流。,2.2 ATM系统案例,ATM系统,某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设
4、在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。,柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现
5、金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。,所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码惟一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。,当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从
6、这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型(取款、查询等)。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。,3 建立对象模型,3.1 确定类与对象,1.找出候选的类与对象对象是对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念。具体地说，大多数客观事物可分为下述5类：,(1)可感知的物理实体，例如，飞机、汽车、书、房屋等等
7、。(2)人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等等。(3)应该记忆的事件，例如，飞行、演出、访问、交通事故等等。(4)两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等等。(5)需要说明的概念，例如，政策、保险政策、版权法等等。在分析所面临的问题时，可以参照上列5类常见事物，找出在当前问题域中的候选类与对象。,非正式分析：这种分析方法以用自然语言书写的需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。下面以ATM系统为例，可以把它们作为类与对象的初步的候选者：银行，自动取款机(ATM
8、)，系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。,通常，在需求陈述中不会一个不漏地写出问题域中所有有关的类与对象，因此，分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。例如，在ATM系统的需求陈述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应该包含这两个实体。,2.筛选出正确的类与对象 筛选时主要依据下列标准，删除不正确或不必要的类与对象：,(1)冗余 如果两个类表
9、达了同样的信息，则应该保留在此问题域中最富于描述力的名称。以ATM系统为例，上面用非正式分析法得出了34个候选的类，其中储户与用户，现金兑换卡与磁卡及副本分别描述了相同的两类信息，因此，应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。,(2)无关 现实世界中存在许多对象，不能把它们都纳入到系统中去，仅需要把与本问题密切相关的类与对象放进目标系统中。有些类在其他问题中可能很重要，但与当前要解决的问题无关，同样也应该把它们删掉。以ATM系统为例，这个系统并不处理分摊软件开发成本的问题，而且ATM和柜员终端放置的地点与本软件的关系也不大。因此，应该去掉候选类“
10、成本”、“市”、“街道”、“营业厅”和“储蓄所”。,(3)笼统 在需求陈述中常常使用一些笼统的、泛指的名词，虽然在初步分析时把它们作为候选的类与对象列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求陈述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些笼统的或模糊的类去掉。以ATM系统为例，“银行”实际指总行或分行，“访问”在这里实际指事务，“信息”的具体内容在需求陈述中随后就指明了。此外还有一些笼统含糊的名词。总之，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。,(4)属性 在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名
11、词从候选类与对象中去掉。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。,(5)操作 在需求陈述中有时可能使用一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。例如，谈到电话时通常把“拨号”当作动词，当构造电话模型时确实应该把它作为一个操作，而不是一个类。但是，在开发电话的自动记账系统时，“拨号”需要有自己的属性(例如日期、时间、受话地点等)，因此应该把它作为一个
12、类。总之，本身具有属性需独立存在的操作，应该作为类与对象。,(6)实现 在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选的类与对象。在设计和实现阶段，这些类与对象可能是重要的，但在分析阶段过早地考虑它们反而会分散我们的注意力。在ATM系统的例子中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联类的物理实现。总之，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。,在ATM系统的例子中，经过初步筛选，剩下下列类与对象：ATM、中央计算机、分行计算机、柜员终端、总行
13、、分行、柜员、储户、账户、事务、现金兑换卡。,3.2 确定关联,1.初步确定关联 在需求陈述中使用的描述性动词或动词词组，通常表示关联关系。因此，在初步确定关联时，大多数关联可以通过直接提取需求陈述中的动词词组而得出。通过分析需求陈述，还能发现一些在陈述中隐含的关联。最后，分析员还应该与用户及领域专家讨论问题域实体间的相互依赖、相互作用关系，根据领域知识再进一步补充一些关联。以ATM系统为例，经过分析初步确定出下列关联：,(1)直接提取动词短语得出的关联ATM、中央计算机、分行计算机及柜员终端组成网络。总行拥有多台ATM。ATM设在主要街道上。分行提供分行计算机和柜员终端。柜员终端设在分行营业
14、厅及储蓄所内。分行分摊软件开发成本。储户拥有账户。分行计算机处理针对账户的事务。分行计算机维护账户。,柜员终端与分行计算机通信。柜员输入针对账户的事务。ATM与中央计算机交换关于事务的信息。中央计算机确定事务与分行的对应关系。ATM读现金兑换卡。ATM与用户交互。ATM吐出现金。ATM打印账单。系统处理并发的访问。,(2)需求陈述中隐含的关联总行由各个分行组成。分行保管账户。总行拥有中央计算机。系统维护事务日志。系统提供必要的安全性。储户拥有现金兑换卡。(3)根据问题域知识得出的关联现金兑换卡访问账户。分行雇用柜员。,2.筛选(1)已删去的类之间的关联 如果在分析确定类与对象的过程中已经删掉了
15、某个候选类，则与这个类有关的关联也应该删去，或用其他类重新表达这个关联。以ATM系统为例，由于已经删去了“系统”、“网络”、“市”、“街道”、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”、“账单”等候选类，因此，与这些类有关的下列8个关联也应该删去：,ATM、中央计算机、分行计算机及柜员终 端组成网络。ATM设在主要街道上。分行分摊软件开发成本。系统提供必要的安全性。系统维护事务日志。ATM吐出现金。ATM打印账单。柜员终端设在分行营业厅及储蓄所内。,(2)与问题无关的或应在实现阶段考虑的关联 应该把处在本问题域之外的关联或与实现密切相关的关联删去。例如，在ATM系统的例
16、子中，“系统处理并发的访问”并没有标明对象之间的新关联，它只不过提醒我们在实现阶段需要使用实现并发访问的算法，以处理并发事务。删掉：系统处理并发的访问,(3)瞬时事件 关联应该描述问题域的静态结构，而不应该是一个瞬时事件。以ATM系统为例，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去。类似地，还应该删去“ATM与用户交互”这个候选的关联。如果用动作表述的需求隐含了问题域的某种基本结构，则应该用适当的动词词组重新表示这个关联。例如，在ATM系统的需求陈述中，“中央计算机确定事务与分行的对应关系”隐含了结构上“中央计算机与分行
17、通信”的关系。,(4)三元关联 三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。在ATM系统的例子中，“柜员输入针对账户的事务”可以分解成“柜员输入事务”和“事务修改账户”这样两个二元关联。而“分行计算机处理针对账户的事务”也可以做类似的分解。“ATM与中央计算机交换关于事务的信息”这个候选的关联，实际上隐含了“ATM与中央计算机通信”和“在ATM上输入事务”这两个二元关联。,(5)派生关联应该去掉那些可以用其他关联定义的冗余关联。例如，在ATM系统的例子中，“总行拥有多台ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。而“
18、分行计算机维护账户”的实际含义是“分行保管账户”和“事务修改账户”。3.进一步完善应该进一步完善经筛选后余下的关联，通常从下述几个方面进行改进：,(1)正名好的名字是帮助读者理解的关键因素之一。因此，应该仔细选择含义更明确的名字作为关联名。例如，“分行提供分行计算机和柜员终端”不如改为“分行拥有分行计算机”和“分行拥有柜员终端”。(2)分解为了能够适用于不同的关联，必要时应该分解以前确定的类与对象。例如，在ATM系统中，应该把“事务”分解成“远程事务”和“柜员事务”。,(3)补充发现了遗漏的关联就应该及时补上。例如，在ATM系统中把“事务”分解成上述两类之后，需要补充“柜员输入柜员事务”、“柜
19、员事务输进柜员终端”、“在ATM上输入远程事务”和“远程事务由现金兑换卡授权”等关联。(4)标明重数应该初步判定各个关联的类型，并粗略地确定关联的重数。但是，无须为此花费过多精力，因为在分析过程中随着认识的逐渐深入，重数也会经常改动。下图是经上述分析过程之后得出的ATM系统原始的类图。,总行拥有中央计算机。中央计算机与ATM通信。在ATM上输入远程事务。远程事务由现金兑换卡授权。现金兑换卡访问帐户。中央计算机与分行计算机通信。总行由各个分行组成。分行拥有分行计算机。分行拥有柜员终端。分行计算机与柜员终端通信。分行雇用柜员。储户拥有账户。,储户拥有现金兑换卡。分行保管账户。柜员终端输入柜员事务。
20、柜员输入柜员事务。柜员事务修改帐户远程事务修改帐户。,ATM系统原始的类图,3.3 划分主题,Coad/Yourdon方法中主题的概念：主题是把一组具有较强联系的类组织在一起而得到的类的集合。,主题概念及其用途主题是一种比类和对象抽象层次更高、粒度更大的概念，用以建立系统的高层抽象视图；主题有助于指导系统设计者或用户等理解一个大的系统模型,有助于组织一个大项目的工作。主题层是在OOA基本模型(类图)之上建立一个能帮助人们从不同的认识层次来理解系统的补充模型；,主题概念的特点是由一组类构成的集合一个主题内部的对象类应具有某种意义上的内在联系描述系统中相对独立的组成部分（如一个子系统）描述系统中某
21、一方面的事物（如人员、设备）解决系统中某一方面的问题（如输入输出）主题的划分有一定的灵活性和随意性,主题的表示法三种表示方式:压缩方式 半展开方式 全展开方式,编号 主题名,压缩方式,编号 主题名,半展开方式：,类名 类名 类名,主题名,主题名,下层主题,主题的表示法,全展开方式：,编号,编号,编号,编号,类图上原有的全部内容,如何划分主题把每个结构作为一个主题；(选取结构中最上层的类作为一主题)通过实例连接互相联系的类可划分到一个主题；把不属于任何结构，也没有实例连接的类作为一个主题。,如何精练主题 从问题域和接口复杂性两方面入手:使用问题域精练主题,即用整体/部分结构对问题域进行划分,而不
22、是按功能分解方法划分.按高内聚低偶合原则,通过使主题间依赖性和交互性最小原则保留能反映子问题域的主题.主题数目7个左右,则进一步精练主题.,何时引入主题 依赖于模型自身复杂性小系统:不需引入主题;中等系统:先标识类及对象,然后引入主题;大系统:先标识主题,对问题域进行 划分,分给不同的任务组;,主题层次的控制中小型系统可只设一层主题，最多不超过两层；大型系统可只设两层主题，最多不超过三层。,以ATM系统为例，可以把它划分成总行（包含总行和中央计算机这两个类）、分行（包含分行、分行计算机、柜员终端、柜员事务、柜员和账户等类）和ATM（包含ATM、远程事务、现金兑换卡和储户等类）等3个主题。事实上
23、，我们描述的是一个简化的ATM系统，为了简单起见，在下面讨论这个例子时将忽略主题层。,3.4 确定属性,1.分析通常，在需求陈述中用名词词组表示属性，例如，“汽车的颜色”或“光标的位置”。往往用形容词表示可枚举的具体属性，例如，“红色的”、“打开的”。属性的确定既与问题域有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析过程中应该首先找出最重要的属性，以后再逐渐把其余属性增添进去。在分析阶段不要考虑那些纯粹用于实现的属性。2.选择通常有以下几种常见情况：,(1)误把对象当作属性如果某个实体的独立存在比它的值更重要，则应把它作为一个
24、对象而不是对象的属性。在具体应用领域中具有自身性质的实体，必然是对象。同一个实体在不同应用领域中，到底应该作为对象还是属性，需要具体分析才能确定。例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。,（2）误把关联类的属性当作一般对象的属性如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性，在分析阶段不应该把它作为一般对象的属性。特别是在多对多关联中，关联类属性很明显，即使在以后的开发阶段中，也不能把它归并成相互关联的两个对象中任一个的属性。（3）把限定误当成属性正确使用限定词往往可以减少关联的重数。如果把某个属性值固定下来以后能减少关联的重数，则应该考虑把
25、这个属性重新表述成一个限定词。在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。,(4)误把内部状态当成了属性如果某个性质是对象的非公开的内部状态，则应该从对象模型中删掉这个属性。(5)过于细化在分析阶段应该忽略那些对大多数操作都没有影响的属性。(6)存在不一致的属性类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。经过筛选之后，得到ATM系统中各个类的属性，如P235图10.4所示。,确定了类中应该定义的属性之后，就可以利用继承机制共享公共性质，并对系统中众多的类加以组织。正如以前曾经强调指出过的，继承关系的
26、建立实质上是知识抽取过程，它应该反映出一定深度的领域知识，因此必须有领域专家密切配合才能完成。通常，许多归纳关系都是根据客观世界现有的分类模式建立起来的，只要可能，就应该使用现有的概念。,3.5 识别继承关系,一般说来，可以使用两种方式建立继承(即泛化)关系：(1)自底向上：抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；类似地，可以从“ATM”和“柜员终端”泛化出父类“输入站”。,(2)自顶向下：把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。从应用域中常常能明显看出应该做的自顶
27、向下的具体化工作。例如，带有形容词修饰的名词词组往往暗示了一些具体类。但是，在分析阶段应该避免过度细化。利用多重继承可以提高共享程度，但是同时也增加了概念上以及实现时的复杂程度。使用多重继承机制时，通常应该指定一个主要父类，从它继承大部分属性和行为；次要父类只补充一些属性和行为。图10.5（见书237页）是增加了继承关系之后的ATM对象模型。,3.6 反复修改,下面以ATM系统为例，讨论可能做的修改：,1.分解“现金兑换卡”类实际上，“现金兑换卡”有两个相对独立的功能，它既是鉴别储户使用ATM的权限的卡，又是ATM获得分行代码和卡号等数据的数据载体。因此，把“现金兑换卡”类分解为“卡权限”和“
28、现金兑换卡”两个类，将使每个类的功能更单一：前一个类标志储户访问账户的权限，后一个类是含有分行代码和卡号的数据载体。多张现金兑换卡可能对应着相同的访问权限。,2.“事务”由“更新”组成通常，一个事务包含对账户的若干次更新，这里所说的更新，指的是对账户所做的一个动作(取款、存款或查询)。“更新”虽然代表一个动作，但是它有自己的属性(类型、金额等)，应该独立存在，因此应该把它作为类。3.把“分行”与“分行计算机”合并区分“分行”与“分行计算机”，对于分析这个系统来说，并没有多大意义，为简单起见，应该把它们合并。类似地，应该合并“总行”和“中央计算机”。图10.6（见书238页）给出了修改后的ATM
29、对象模型，与修改前比较起来，它更简单、更清晰。,第一步，编写典型交互行为的脚本。第二步，从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。,4 建立动态模型,在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性和清晰
30、性。编写脚本的过程，实质上就是分析用户对系统交互行为的要求的过程。在编写脚本的过程中，需要与用户充分交换意见，编写后还应该经过他们审查与修改。,4.1 编写脚本,编写脚本时，首先编写正常情况的脚本。然后，考虑特殊情况，例如输入或输出的数据为最大值(或最小值)。最后，考虑出错情况，例如，输入的值为非法值或响应失败。对大多数交互式系统来说，出错处理都是最难实现的部分。如果可能，应该允许用户“异常中止”一个操作或“取消”一个操作。此外，还应该提供诸如“帮助”和状态查询之类的在基本交互行为之上的“通用”交互行为。,脚本描述事件序列。每当系统中的对象与用户(或其他外部设备)交换信息时，就发生一个事件。所
31、交换的信息值就是该事件的参数(例如，“输入密码”事件的参数是所输入的密码)。也有许多事件是无参数的，这样的事件仅传递一个信息该事件已经发生了。对于每个事件，都应该指明触发该事件的动作对象(例如，系统、用户或其他外部事物)、接受事件的目标对象以及该事件的参数。表10.1和表10.2（见书240页）分别给出了ATM系统的正常情况脚本和异常情况脚本。,大多数交互行为都可以分为应用逻辑和用户界面两部分。通常，系统分析员首先集中精力考虑系统的信息流和控制流，而不是首先考虑用户界面。事实上，采用不同界面(例如，命令行或图形用户界面)，可以实现同样的程序逻辑。应用逻辑是内在的、本质的内容，用户界面是外在的表
32、现形式。动态模型着重表示应用系统的控制逻辑。软件开发人员往往快速地建立起用户界面的原型，供用户试用与评价。下图初步设想出的ATM界面格式。,4.2 设想用户界面,ATM的界面格式,完整、正确的脚本为建立动态模型奠定了必要的基础。但是，用自然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图。为此首先需要进一步明确事件及事件与对象的关系。,4.3 画事件跟踪图,1.确定事件应该仔细分析每个脚本，以便从中提取出所有外部事件。事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等等。传递信息的对象的动作也是事件。大多数
33、对象到对象的交互行为都对应着事件。例如，储户插入现金兑换卡、储户输入密码、ATM吐出现金等都是事件。,区分出每类事件的发送对象和接受对象。,2.画出事件跟踪图事件跟踪图把事件序列以及事件与对象的关系表示出来。事件跟踪图实质上是扩充的脚本，可以认为事件跟踪图是简化的UML顺序图。图10.8（见书242页）是ATM系统正常情况下的事件跟踪图。,状态图描绘事件与对象状态的关系。系统分析员应该集中精力仅考虑具有重要交互行为的那些类。,4.4 画状态图,图10.9（见书243页），图10.10和图10.11分别是“ATM”、“总行”和“分行”的状态图。这些状态图都是简化的，尤其对异常情况和出错情况的考虑
34、是相当粗略的(例如，图10.9并没有表示在网络通信链路不通时的系统行为，实际上，在这种情况下ATM停止处理储户事务)。,总行类的状态图,分行类的状态图,各个类的状态图通过共享事件合并起来，构成了系统的动态模型。在完成了每个具有重要交互行为的类的状态图之后，应该检查系统级的完整性和一致性。一般说来，每个事件都应该既有发送对象又有接受对象，当然，有时发送者和接受者是同一个对象。对于没有前驱或没有后继的状态应该着重审查，如果这个状态既不是交互序列的起点也不是终点，则发现了一个错误。,4.5 审查动态模型,应该审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配。以ATM系统为
35、例。在总行类的状态图中，事件“分行代码错”是由总行发出的，但是在ATM类的状态图中并没有一个状态接受这个事件。因此，在ATM类的状态图中应该再补充一个状态“do/显示分行代码错信息”，它接受由前驱状态“do/验证账户”发出的事件“分行代码错”，它的后续状态是“退卡”。,由一组数据流图组成。其中的处理功能可以用IPO图(或表)、伪码等多种方式进一步描述。通常在建立了对象模型和动态模型之后再建立功能模型。,5 建立功能模型,ATM系统的基本系统模型,6 定义服务,1.常规行为在分析阶段可以认为，类中定义的每个属性都是可以访问的，也就是说，假设在每个类中都定义了读、写该类每个属性的操作。但是，通常无
36、需在类图中显式表示这些常规操作。,2.从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须有由消息选择符指定的操作，这个操作修改对象状态(即属性值)并启动相应的服务。例如，在ATM系统中，发往ATM对象的事件“中止取消”，启动该对象的服务“打印账单”；发往分行的事件“请分行验卡”启动该对象的服务“验证卡号”；而事件“处理分行事务”启动分行对象的服务“更新账户”。可以看出，所启动的这些服务通常就是接受事件的对象在相应状态的行为。,3.与数据流图中处理框对应的操作 数据流图中的每个处理框都与一个对象(也可能是若干个对象)上的操作相对应。应该仔细对照状态图和数据流图，以便
37、更正确地确定对象应该提供的服务。例如，在ATM系统中，从状态图上看出分行对象应该提供“验证卡号”服务，而在数据流图上与之对应的处理框是“验卡”，根据实际应该完成的功能看，该对象提供的这个服务应该是“验卡”。,4.利用继承减少冗余操作应该尽量利用继承机制以减少所需定义的服务数目。只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。,分析就是提取系统需求并建立问题域精确模型的过程，它包括理解、表达和验证等3项主要工作内容。面向对象分析的关键工作，是分析、确定问题域中的对象及对象间的关系，并建立起问题域的对象模型。大型、复杂系
38、统的对象模型通常由下述5个层次组成：主题层、类与对象层、结构层、属性层和服务层。它们对应着在建立对象模型的过程中所应完成的5项工作。,小结,大多数分析模型都不是一次完成的，为了理解问题域的全部含义，必须反复多次地进行分析。因此，分析工作不可能严格地按照预定顺序进行；分析工作也不是机械地把需求陈述转变为分析模型的过程。分析员必须与用户及领域专家反复交流、多次磋商，及时纠正错误认识并补充缺少的信息。分析模型是同用户及领域专家交流时有效的通信手段。最终的模型必须得到用户和领域专家的确认。在交流和确认的过程中，原型往往能起很大的促进作用。,一个好的分析模型应该正确完整地反映问题的本质属性，且不包含与问题无关的内容。分析的目标是全面深入地理解问题域，其中不应该涉及具体实现的考虑。但是，在实际的分析过程中完全不受与实现有关的影响也是不现实的。虽然分析的目的是用分析模型取代需求陈述，并把分析模型作为设计的基础，但是事实上，在分析与设计之间并不存在绝对的界线。,
