1、第三章 面向对象系统分析概述,面向对象系统分析简称为OOA，本章讨论OOA所涉及到的一些主要问题和基本概念，并综述性地介绍目前流行的各种OOA方法。,主要内容：,系统分析面临的主要问题，包括对问题域和系统责任的理解和准确划分、交流问题、如何应对需求的不断变化、软件复用的考虑等。,应用的开发过程概述，各个阶段的主要任务和侧重点，基本方法等；,面向对象系统分析的主要任务和目的。,几种常用的面向对象系统分析方法。,3.1 应用的开发过程概述,我们习惯于将一个应用（Appilication）的开发过程（软件开发过程）划分为以下六个阶段：需求描述、分析、设计、实现、测试、维护。下面分别对各个阶段的主要任
2、务作简单的介绍。,1. 需求描述,1） 需求的概念,需求是“用户解决某个问题或达到某个目标所需的条件或功能”。,需求描述也称为需求分析，它是系统分析的前期和基础，需求描述中应该包含对系统的外部行为的尽可能的详细的刻画。,2）需求描述阶段的侧重点,实际上，需求描述侧重于功能方面的描述，因此系统分析人员必须善于从功能需求中寻找功能的作用者和相关体，也即寻找存在于系统中的一个个对象（或者说：将某一领域分割成各种对象）。否则很可能会诱导后继阶段围绕功能展开，这将有悖于面向对象的宗旨。,2分析阶段,1）分析阶段的目标,理解软件为满足需求所要解决的问题，描述系统应该做什么而不是怎么做。可以看出分析阶段所侧
3、重的是软件方面的需求而不是用户方面的需求。,2）分析阶段的主要任务,在初步理解现实世界的基础上，建立系统的面向对象模型（对象模型和动态模型），在建模过程中不断地加深对问题的理解。,所谓现实世界是指一个组织的现状（例如一个企业用现有的业务过程为顾客服务），以及再工程后的状态（对现有进程进行调整后的状态）。,面向对象的分析方法为后继阶段给问题构造解决方案建立了坚实的基础，同时也为构建“合适”的系统提供了强有力的保证。,3设计阶段,1）目标,考虑如何构造一个好的软件系统框架。,2）主要工作,包括系统设计、对象设计和持久对象设计。,系统设计主要给出分层的系统结构。,一个系统通常分为应用、支撑和服务三个
4、层次，每一 层对应一个子系统。,对象设计主要完成对分析模型的细化和精化以适应实际的实现环境。,持久对象设计主要完成数据库服务器的设计、定义数据库操作对象和模型对象之间的交互等。,4实现阶段,实现阶段的主要工作是对应用进行程序设计，把设计阶段定义的结构和各种算法转化为程序代码。,5测试阶段,分为单元测试和整体测试。,单元测试，也称为单体测试，是对每一个程序模块所进行的功能测试。,整体测试，首先测试各模块（或子系统）间的联接，然后测试整个应用系统是否能满足用户的需求描述。,6维护阶段,维护阶段是整个软件周期中一个最为“漫长”的阶段。,维护阶段的主要工作包括：,对系统潜在的错误进行检测和改正；,注意
5、：每一次维护可能又是一个较小的应用开发过程。,不断地面对用户的新要求以及为适应新环境对系统进行改进与增强。,7关于“合适”系统的讨论,评价一个系统是否“合适”，有以下两条基本准则：,准则一、所实现的系统应能解决所给的问题，也即满足功能性的需求。,这不仅仅是设计与实现阶段的任务，而且更要仰仗需求描述的准确性以及分析阶段对问题域的建模等。,准则二、可用性达到使用户满意的程度。,可用性属于系统属性，是系统的非功能特性，包含一些非功能性需求，此类需求与问题域无关。,注意：,例如一个查询，尽管结果是正确的，但响应时间太长，用 户不满意就会产生不可用的感觉。,（1）一个系统只有同时满足功能性需求和非功能性
6、需求，它才是可用的。,（2）功能性需求可由领域知识和需求描述获得；非功能性需求由域用户与专家协商得到。,（3）交互能力强的模型或者原型系统都可以使用户及时体验未来的系统，从而能帮助系统开发人员更好地了解上述两种需求。,3.2 用况驱动的、迭代式的、增量的开发方法概述,软件开发过程（Software development process）：,是软件系统的创建、提交和维护等相关活动的组织方法。,UML没有定义一个标准的开发过程，UML的作者也承认健壮的建模语言和开发过程两者都很重要。,目前流行的开发过程（方法）：用况驱动的、迭代式的、增量的开发方法。它是对很普通的那些推荐的过程和模型（Recom
7、mended Process and Model， RPM ）所做的描述。,高层步骤,计划和细化（Plan and Elaborate） 制定计划、定义需求、创建原型等。,构造（Build） 进行系统（模型）的构建。包含：分析、设计、实现和测试等活动。,实施（Deploy） 最终实现系统并投入使用。,从高层上看，提交一个应用系统的过程应包括以下阶段：,2. 迭代开发方法概述,（1）方法的要点和优点,在经过一个初步的计划和细化阶段后，开发进入由一系列开发周期组成的系统构造阶段。所以迭代主要发生在构造阶段。,迭代开发的生命周期是基于对一个系统进行连续的扩充和精化，其要点如下：,软件开发过程要经历若
8、干个开发周期，每个周期都包含：分析、设计、实现和测试等活动。,要点,2. 迭代开发方法概述（续）,软件开发过程要经历若干个开发周期，每个周期都包含：分析、设计、实现和测试等活动。,2. 迭代开发方法概述（续）,在每个开发周期中，通过增加新的功能使系统得以扩充（增量）。,每个开发周期只针对比较小的一部分需求（一般是以用况为单位），它要经历分析、设计、实现和测试等活动。每个开发周期完成后，系统都获得一定程度的扩充。,开发周期一般是以用况为单位来组织的。,软件开发过程要经历若干个开发周期，每个周期都包含：分析、设计、实现和测试等活动。,2. 迭代开发方法概述（续）,优点,因为每个开发周期只针对比较小
9、的一部分需求，规模适中，所以就比较好地解决了因为一个开发过程太复杂而使开发人员无从下手的问题。,因为每个周期只快速实现系统的一小部分，所以在开发过程的早期就能够获得反馈信息。,3. 确定开发周期的时间盒,每个开发周期都采用一种实用的策略为该开发周期加上一个时间盒，也即给开发周期限定时间，开发周期中的所有工作都必须在这个时间内完成。,经验表明：一个比较合适的时间盒是二个星期到二个月。,如果时间短了，将很难完成任务；反之，难以处理开发周期中可能遇到的各种困难，并且得到反馈信息的时间将拖后。,4.用况和迭代开发周期,（1） 用况驱动,迭代开发周期是通过用况来组织的。一个开发周期的任务是实现一个或多个
10、用况，或用况的简化版本（当完整的用况复杂到一个开发周期处理不了时，这是普遍采用的方法）。,（2） 划分用况的层次,4.用况和迭代开发周期（续）,用况（use case）是对业务过程所包含的一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结果。用况是通过协作实现的。,划分用况的策略是，首先从问题域和高层服务中抽 取出那些对系统核心体系结构影响最大的用况以及那些具有高风险的关键用况，这些用况有的可以视为高层用况。,高层用况应当在较早的开发周期中得到处理。,5.计划和细化阶段概述,（1）计划和细化阶段的主要工作,一个项目的计划和细化阶段的主要工作包括：,初期概念的形成；
11、,为做出各种项目选择所进行的调查研究；,需求的规格化描述等。,（）计划和细化阶段的活动样例,（3）计划和细化阶段所创建的制品,计划 时间进度表、资源规划、预算等等。初步调查报告 目标、选择、业务需求。需求规格说明 关于需求的声明型陈述。术语表 术语字典（包括概念名）和相关信息，例如约束和规则。原型 所创建的原型系统，用于对问题、高风险因素和需求的辅助理解。用况图 展示所有的用况及用况之间的关系。概念模型草案 一个初期的初略的概念模型，用来帮助开发人员理解领域中的词汇，特别是与用况和需求说明有关的词汇。,（3）计划和细化阶段所创建的制品（续）,本阶段的制品可以按活动样例图所给的线性顺序创建，但某
12、些制品却是可以并行创建的，例如概念模型、术语表、用况及用况图等。,计划 时间进度表、资源规划、预算等等。初步调查报告 目标、选择、业务需求。需求规格说明 关于需求的声明型陈述。术语表 术语字典（包括概念名）和相关信息，例如约束和规则。原型 所创建的原型系统，用于对问题、高风险因素和需求的辅助理解。用况图 展示所有的用况及用况之间的关系。概念模型草案 一个初期的初略的概念模型，用来帮助开发人员理解领域中的词汇，特别是与用况和需求说明有关的词汇。,（4） 制品样例终端销售系统（POST）的用况和用况图,用况： 购买商品 参与者：顾客（发起者）、出纳员 类型： 主要的 描述： 顾客带着所购买的商品来
13、到付款处，出纳员记录商品信息并接受付款。付款后，顾客带着商品离开。,用况： 启动系统 参与者：管理员 类型： 主要的 描述： 管理员接通一个POST终端电源，为出纳员使用终端做准备。管理员检查时间和日期的正确性，检查完成后，系统处于就绪状态，以备出纳员使用。,POST的高层用况样例,POST系统的部分高层用况图,（5） 制品样例终端销售系统的初始概念模型,6. 构造阶段开发周期概述,（1） 构造阶段的主要工作和目标,一个项目的构造阶段包括一系列重复的开发周期，每一个开发周期的主要活动包括：精化计划、同步制品、分析、设计、实现、测试等。在这些开发周期中，系统得到了扩展和完善。,构造阶段的最终目标
14、是得到一个能正确符合需求的软件系统。,（2） 开发周期中分析活动的样例和主要制品,（3） 开发周期中设计活动的样例和主要制品,a.与交互图并行 b.顺序可变的,3.3 系统分析面临的主要问题,系统分析过程中，可能遇到的问题来自于方方面面，不胜枚举。,下面将要讨论的只是一些极具一般性的问题，例如：,（1）如何应对需求的不断变化,（2）应用的复杂性过载,（3）系统维护的艰巨性等等,（1）如何应对需求的不断变化 （2）应用的复杂性过载 （3）系统维护的艰巨性等等,3.3 系统分析面临的主要问题（续）,以上问题主要来源于以下几个方面：,其一、软件的应用环境和需求的多样化；,其二、开发人员对应用领域的理
15、解水平有限；,其三、开发人员和用户之间缺乏有效的交流手段和方法。,上述问题是无论采用何种分析方法都可能会遇到的，区别在于好的方法能更有效地解决这些问题。,经验告诉我们，面向对象方法在解决这些带有普遍性的问题上，技高一筹。,1. 问题域和系统责任的理解问题,1）问题域（problem domain）,问题域是指特定应用系统的应用领域，即在现实世界中由该系统进行处理的业务范围。,问题域由问题组成，问题是人们用概念表达出来的对信息系统的需求。,“概念就是一个想法、事物或者对象”。,问题域的确定是经历了由现实世界到观念世界的抽象，它是观念世界的三个组成部分之一，其它两部分是实体域和概念域。,系统分析通
16、常都是由问题陈述（用况驱动）开始的（依赖于问题陈述），面向对象分析方法通过问题陈述使得分析人员能够发现存在于系统中的各种原始对象，显然，正确地理解和确定问题域至关重要。,2）系统责任（system responsibilities）,系统责任是指系统应该具备的职能，也即系统能做什么。,尽管系统责任主要侧重于从功能（职能）方面加深对系统的理解，但它总是和系统中的具体的人、具体的事有关的，也即和系统中的具体对象有关，所以问题域和系统责任存在某些重叠。,3）理解问题域和系统责任的重要性,对问题域和系统责任的理解，给出问题域的准确、透彻的描述，这是能否成功地开发一个系统的首要前提和先决条件，同时也是系
17、统分析的最大难点之一，原因如下：,系统分析员多半不是领域专家，而领域专家多半不是计算机行家；,分析人员对问题域的理解比领域工作人员要更加深入和准确，也即需要较高层次上的抽象；,计算机应用系统并不是人工系统的简单模拟，因此，在日常运作上应该高出人工系统一筹；,应用环境和系统需求的多样化、复杂化、系统规模庞大等问题对分析阶段的压力超过系统开发的其他阶段。,3）理解问题域和系统责任的重要性（续）,2. 交流的问题,系统分析人员在进行系统分析时，需要经常进行人与人之间的各种交流。,通过交流可以获取领域知识、加深对需求的理解，同时也让领域人员理解和评价分析结果。,分析阶段的交流包括以下几种形式和内容：,
18、分析人员与用户及领域专家的交流和再交流；,（1）交流的意义,（2）交流的形式和内容,这种交流有助于分析人员了解用户需求和理解问题域中的每个问题，另一方面可以让用户和领域专家理解分析结果并对其进行检验和评价。,分析人员之间的交流,有助于统一认识、协调一致，整合分析结果。,与设计人员的交流,与管理人员的交流,这属于阶段转移的工作交接问题。,包括工作审核、认可、进度检查、计划调整等。,（3）影响交流顺畅的原因,交流问题是一个“面向人的”问题，存在着很多非技术因素，这是难点所在。,交流问题也有技术因素存在，这就是：有关人员需要一种共同的思维方法和一种便于交流的共同语言，该语言包括系统模型、术语、表示符
19、号、文档格式等（例如UML ）；,（4）采用面向对象分析方法可以比较好地解决交流问题,这是因为面向对象分析方法可以用直观的、可视化程度较高的模型来建立分析人员与用户及领域专家之间的桥梁，以利于交流的畅通无阻。,3需求的不断变化,1）需求的变化可能会发生在系统开发的各个阶段。,2）需求变化所带来的问题,无论需求变化发生在哪个阶段，都将引起一系列的修改，这势必加大工作量、延长开发周期、增加系统维护的复杂性；,导致系统的整体性、适应性、可靠性和健壮性都受到影响。,3）引起需求变化的主要因素,问题域本身在系统开发过程中发生变化，例如规模扩大、管理策略与模式处于逐步完善或改变过程中等等，这属于不可避免的
20、客观原因。,用户因素 ，这是最主要的因素；,由于用户在初期阶段的重视程度不够、本身对需求不甚明确、要求不完全、不适当，因而势必会在开发的各个阶段经常提出一些补充甚至更改早期提出的需求。,竞争因素；,技术支持，技术支持的改变可能会引起需求的调整。,经费的增减会引起系统规模的扩大或缩小。,经费因素；,比如说某些应用在技术支持不够强大的情况下，有些需求会受到压抑，一旦技术支持完善后，就必须重新考虑这种需求实现的可能性。,4）如何应对需求的不断变化,需求的变化在系统开发过程中是司空见惯的，问题是如何有效地应对这一不可避免的现象？,（1）冻结需求法,但这毕竟只是权宜之计而决非万全之策，因为将来还必须面对
21、新的变化。,传统的开发方法只能采用在某一特定时刻冻结需求变化的办法来对付它，以求得阶段性的稳定。,通过上述排序可以看出：对象是系统中最稳定的部分。,面向对象方法就是利用这一事实，以对象作为构成系统的基本单位，把容易变化的操作和属性封装在对象中，抽象和封装提高了对需求变化的弹性适应。,当需求发生变化时，系统中最容易变化的部分是功能部分，其次是与外部系统或设备的接口部分，再次是描述问题域事物的数据部分；最后才是对象。,（2）以系统中最稳定的部分作为系统的基本单位,4软件复用的要求,这里强调的是分析结果和设计结果的重用，它属于中粒度重用，比小粒度的代码重用更具有显著的效果。,重用并不能简单地产生的，
22、必须通过对即时应用之外的思考和进行更多的一般化设计的规划才能得到。,（1）设计重用模块会增加项目开发成本。,（2）紧张的项目开发周期（截止期限）可能意味着不能实现重用。,（3）缺乏商业上可利用的对象库。没有这种在实际项目中开发出来的类库和组件库，重用的好处就得不到充分的体现与发挥。,3.4 面向对象系统分析的任务和目的,1任务,面向对象系统分析的主要任务是：,对问题域和系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的认识；,找出与问题域及系统责任有关的类及对象 ；,定义这些类和对象的属性和操作，以及它们之间所形成的结构，静态联系和动态联系。,简而言之，确定系统中的对象，描述对象的
23、静态特征和动态特征，找出对象之间的各种关系以及对象的行为约束，是面向对象分析的主要任务。,2目的（目标）,建立一个符合用户需求并能够直接反映问题域和系统责任的系统模型和相关文档。,3. 面向对象分析的基本原则,面向对象系统分析过程中应遵循以下五个基本原则 ：,1）一般化和具体化相结合的原则,一般化方法的核心是抽象，抽象主要强调实体的本质和内在属性，忽略一些无关紧要的细节，使得我们可以在实现对象之前将重点放在理解对象是什么和做什么。也即确定对象的意义和行为。,抽象包括数据抽象和过程抽象：,数据抽象将数据对象及作用在其上的操作描述成具有封装特征的对象，是分析的核心，是建立系统结构的基础。,过程抽象
24、为对象的相互作用提供依据。,具体化是与一般化相反的分析过程，是指在问题的细化过程中，给对象逐步加入必要细节使特定对象的个性明朗化。,遵循一般化和具体化相结合的原则，为提高系统的通用性、稳定性，增强适应能力以及系统内部的重用提供了根本的保证。,2）构造和分解相结合的原则,构造是指用基本对象组装复杂对象的过程；,分解是指对大粒度对象进行精化从而完成系统模型的细化过程。,3）封装的原则,封装强调对象的独立性和不可分割性以及内部实现细节的隐蔽，它有助于最大限度地减少由于需求的改变而对整个系统所造成的影响。,4）相关的原则,相关是指系统中各个对象之间存在的各种关联以及部分和整体的关系 。,关联是对象协作
25、的基础（消息传递的渠道），反映对象之间的动态关系，通常带有消息的传递等；,部分到整体的关系是组元到组合的静态聚合过程，也称为静态结构关联。,5）行为约束的原则,行为约束包括静态行为约束和动态行为约束。它表明了对象的合法存在，给出对象操作的合法执行所应满足的约束条件。,对象的语义特征是通过行为约束来刻划的 。,行为约束有助于深刻地理解对象和系统。,4面向对象系统分析的工作内容,分析过程通常由以下八个主要活动构成：,（1）理解问题：借助需求描述去认识系统所涉及到的现实世界的问题域。,（2）识别类：找出与问题域中的各个问题有关的对象，并应用抽象手段将具有相同性质的对象抽象成类。,（3）定义类的性质：
26、对类的主要属性和主要行为的描述。,（4）识别类之间的关系，包括关联、聚集和泛化等。,（5）建立对象模型。,（6）描述系统事件集：分析系统运行过程中可能发生的各种事件，构成事件脚本。,（7）建立事件跟踪：分析事件与对象的关系，也即确定事件的发送者和接收者，接收对象对事件的反应等。,（8）研究系统中主要对象的主要活动和因外部事件引起的状态变化，在此基础上给出相应的状态图。,事件脚本、事件踪迹图以及各主要类的状态图是动态模型的主要组成部分。,3.5 常用的面向对象分析、设计方法简介,八十年代中后期，OOA和OOD成为一个研究热点，先后出现了不少研究成果和实用方法：,OMT方法,OOSE方法,VMT方
27、法,UML,1. OMT所涉及的概念,该方法是由Loomis Shan和Rumbaugh在1987年提出的，曾应用于关系数据库的设计，1991年正式应用于面向对象分析和设计领域。,OMT提出一组定义得很好的并且相互关联的、极具面向对象特征的概念，它们是：,对象、类、对象属性、对象操作、概括、继承、链和关联、链属性、聚合；,事件、事件脚本、场景、子系统、模块等。,3.5.1 OMT方法,OMT是Object Modeling Technique（对象建模技术）的缩写。,2. OMT方法概述,基本思想：围绕现实世界的客观实体（对象）与实体概念（问题域的问题）来构造系统模型，制定策略并逐步优化，直至
28、趋于完善。,实施策略可以概述为：,（1）分析阶段在问题陈述的基础上围绕实际对象构造出不考虑最终实现细节的，旨在反映系统概貌的三种分析模型对象模型、动态模型和功能模型。,（ 2）在设计阶段对分析模型加入设计策略和详情细节以完善模型，形成以应用域对象为框架的设计模型。,（ 3）用程序设计语言、数据库对设计模型加以实现。,1） 分析,注意：,（1）OMT方法覆盖了系统分析、设计和实现三个阶段，包含四个步骤，即系统分析、系统设计、对象设计和实现。,（2）三种模型贯穿三个阶段的每一个步骤，在各个阶段得到不断的完善，体现了模型的统一性。,分析的目的是建立易于理解的现实世界模型，其结果是对系统的一般性定义，
29、并由三种模型来进行抽象与表征，即对象模型、动态模型、功能模型。,2. OMT方法概述（续）,3） 实现,系统设计给出系统结构、划分子系统、并分配给处理器和任务；,对象设计的主要工作是描述系统中各个对象的细节，以及对分析阶段建立的三种模型进行精化和优化，把问题域映射到“解”（计算机）域。,实现阶段的成果是建立系统的目标环境。,2. OMT方法概述（续）,2） 设计,OMT的设计包括两个内容，即系统设计和对象设计。,3. OMT的三种模型简介,分别是对象模型、动态模型和功能模型。,1） 对象模型,用来描述系统中对象的静态结构（数据结构）及对象之间的关系（关联、概括（泛化）、聚集等）。,对象模型体现
30、出系统的静态的、结构化的“数据性质”。它是三种模型中最重要的一种。,对象模型的描述工具是类图和对象图。,ATM系统的初始对象模型,3. OMT的三种模型简介（续）,2） 动态模型,用来描述系统的控制结构以及与时间、操作次序有关的系统属性。,动态模型刻划出系统的瞬时的、行为化的“控制”性质。,动态模型的描述工具是事件脚本、事件跟踪图和主要对象的状态图。,例如触发事件、对象操作、对象状态转换等。,3. OMT的三种模型简介（续）,3. OMT的三种模型简介（续）,ATM系统的主要事件跟踪图。,3. OMT的三种模型简介（续）,ATM系统中几个主要对象的状态图。,联营对象的状态图,3. OMT的三种
31、模型简介（续）,银行对象的状态图,做:验证密码,ATM对象的状态图,3. OMT的三种模型简介（续）,3）功能模型,描述与数据值的变化有关的系统属性。,功能模型刻划的是“变化”的系统的“功能”性质。,功能模型的描述工具是数据流图（DFD）。,功能模型强调指明计算结果而不必指明计算的执行过程，并给出系统的计算结构。,例如：功能、映射、约束以及功能依赖条件等。,3.5.2 OOSE方法,OOSE方法的全称是面向对象软件工程（Object Oriented Software Engineering），是Jacobson在1992年提出的一种用况驱动的面向对象开发方法。,综上所述，分析模型是以应用域对
32、象为主体的，因此建模时应注意以下问题：,必须对对象的主要性质和行为作出准确的描述；,必须较详细地刻划出系统的三大性质，即数据性质、控制性质和功能性质。这是建模的基本要求。,1OOSE所涉及的概念,包括：类、对象、继承、相识、通信、激励、操作、属性、参与者、用况、子系统、服务包、块和对象模块等。,相识等价于对象间的关联和聚合这一类关系；,激励是通信传送的消息；,参与者是与系统交互的事物（与系统产生信息交换的外部事物），这些事物构成系统的语境；,用况是指当用户使用系统完成一个业务时所执行的一个行为相关的动作系列（对业务过程的动作序列描述），该系列在与系统的对话中完成。,2. OOSE方法的实施过程
33、,采用OOSE方法开发一个软件系统，其过程由分析、构造、测试三个阶段构成：,1）OOSE的分析过程,基于需求规范进行需求分析、建立需求模型，接着进行健壮性分析，得到分析模型。,2）OOSE的构造过程,在需求模型和分析模型的基础上进行系统设计，建立设计模型；在此基础上进行系统实现，最终得到实现模型，构造过程如下图所示：,3）OOSE的测试过程,结合分析阶段和设计阶段建立的三种模型进行系统级和对象级的测试，可采用的测试方法有黑盒测试法和白盒测试法，测试过程如下图所示：,3.5.3 VMT,VMT以OMT作为骨干技术，并结合了其它被证明是高效的对象技术，例如RDD技术，OOSE和CRC卡，形成一种高
34、效、实用的开发过程（开发技术）。,1. 以OMT作为骨干技术,采用OMT的建模概念、方法和符号,保留OMT的对象模型和动态模型。,2. 采用OOSE的用况驱动建模技术,针对OMT没有很好地覆盖需求阶段（没有提供需求阶段参与用户交互的技术）这一问题，VMT使用OOSE的用况来确定如下内容：,用户需求；,用户进行的活动；,系统必须为用户提供的服务。,这个方法可以使开发人员更好地理解用户和未来的系统之间的交互。,3. 引入RDD技术和CRC卡,（1） RDD（Responsibility- Driven Design），是一种责任驱动的设计方法，该方法强调对象行为（责任）与其它对象的关系（合作）。,
35、（2） 将 RDD引入到VMT中，是因为一旦识别出类和类之间的关系，必须确定责任在类中的分配。,（3） CRC卡（ 初始类责任合作卡），用来描述对象类的责任和合作。,例：客户类的CRC卡,在初始对象模型建立后， CRC卡是确定对象责任和合作者最有效的工具。,4. VMT建模过程概述,VMT是结合了可视化程序设计的高效应用开发过程，能被扩展到分布式的对象应用领域，其建模过程的高层表示如右图所示：,该图还展示了VMT建模过程与分析、设计及实现各个阶段的关系。,1）VMT的分析过程,主要任务：理解问题域，建立系统模型以及系统的应用实体、过程和规则。,主要步骤：,（1） 根据初始的需求文档，在用户参与
36、的情况下，定义参与者和用况，并用可视化编程工具建立GUI风格的系统原型。,（2） 利用问题陈述和用户模型建立初始的对象模型。,建模方法和模型结构与OMT基本相同。,（3） 初始对象模型、用况（模型）以及GUI原型一起表达了问题的需求模型。需求模型也定义了系统的边界和附加接口。,（4） 建立描述类的责任和合作的CRC卡。,从类的责任可以确定对象模型中各个类的服务和属性。通过类的责任的再分配，可以调整初始对象模型。,从合作方式，我们重定义和精化类及类间的关系，得到一个精化了的对象模型。,（5） 参照对象模型，通过用况和服务建立事件踪迹图和状态图来描述系统的动态特性。,VMT的动态模型结构与OMT大
37、致相同。,2）VMT的设计过程,VMT的设计包括：系统设计、对象设计与持久对象设计。（参见3.1.3）,3.5.4 UML简介,1. UML简史,1989到1994年之间，面向对象的方法从不足10种增加到50种以上。太多的方法，导致很多用户反而无从选择（很难找到一种完全满足他们要求的建模语言，于是就加剧了所谓的“方法战争”。,1994年由Grady Booth和Jim Rumbaugh及Ivar Jacobson将他们各自开创的方法Booch、OMT、OOSE进行合并所形成的，1997年作为一套建模语言和表示法的标准提交给对象管理组OMG，并得到采用，同时也得到了工业界的普遍认同。,2 . U
38、ML的主要特点,详述，UML是一种可用于详细描述的语言，详细的描述意味着所建立的系统模型是精确的、无歧义的和完整的。用于详述的元素是注释事物（注解）。,UML的中文全称是统一建模语言（Unified Modeling Language）,该语言对软件密集型系统的制品进行下述工作：可视化、详述、构造、文档化。,可视化，至少有两个含义，其一是通过建模来了解未来的软件系统，其二、采用图形符号来表示系统中的所有事物和关系以及事物的行为，极大地保证了模型的直观性、清晰性和易读性，便于交流。,构造，是指UML描述的模型可与各种编程语言直接相连，即可以把用UML描述的模型映射成编程语言（程序），甚至映射成关
39、系数据库的表或面向对象数据库的永久存储（持久对象）。映射可以是“正向工程”也可以是“逆向工程”。,文档化，通常组成文档的制品包括：需求描述、体系结构、设计、源代码、项目计划、测试、原型、发布。,UML适合于建立系统体系结构及其所有的细节文档；UML还提供了用于表达需求、用于测试的语言以及对项目计划和发布管理活动进行建模的语言。,3. UML表示法概述,UML表示法包括：事物、关系、图等三种建模元素，建模元素也称为构造块。,1）事物,（1）结构事物,结构事物是UML模型中的名词，它们通常是模型中的静态部分，描述客观世界的概念或物理元素。,UML模型中共有七种结构事物：,类,接口,协作,用况,主动
40、类,构件,节点,结构事物、行为事物、分组事物、注释事物,是对一组具有相同属性、相同操作、相同关系和相同语义的对象的描述（抽象）。一个类实现了一个或多个接口。,类（class）,在图形上，用矩形表示一个类，矩形内部标有类的名称、属性和操作。,接口很少单独存在，而是通常依附于实现接口的类或构件。,接口（interface）,接口是描述一个类或构件的一个（外部）服务的操作集。因此，接口描述元素的外部可见行为。,接口描述了一组操作的规格，而不是操作的实现。,图形上，用一个带有名称的圆表示接口：,协作定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构成的一个群体，这些协作行为大于所有元
41、素的各自行为的综合。因此协作有结构、行为和维度。,协作（collaboration）,图形上，用一个仅包含名称（协作名）的虚线椭圆表示协作：,Chain of responsibility,用况（use case）,用况是对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结果。,用况用于对系统语境和系统需求建模。,图形上，用一个包含名称的实线椭圆表示用况：,Validate user,*语境（context）：用于某一特定用途（如描述一个操作）的相关元素的集合。,主动类（active class）,主动类的对象至少拥有一个进程或线程，因此它能够自主执行（能够启动控
42、制活动）。,注意：主动类的对象所描述的元素的行为与其他元素的行为并发，这是它与一般类的唯一区别。,图形上，用一个含有名称、属性、操作的粗边矩形表示主动类：,构件（component）,构件是系统中物理的、可替代的部件，它遵循且提供一组接口的实现。,构件与前述的五种事物不同，前面的五种事物都是概念或逻辑事物，而构件是物理的、可替代的部件。,在一个系统中，会出现不同类型的部署构件，例如COM+的构件和Java Beans，以及在开发过程中所产生的制品构件，如源代码文件等。,图形上，用一个带有若干小方框的矩形表示构件：,节点（node）,节点也是物理的，是在系统运行时存在的物理元素，它表示了一种可计
43、算的资源，通常至少有一些记忆能力和处理能力。,一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。,图形上，用一个立方体表示构件：,Server,（2）行为事物,行为事物是UML模型的动态部分，它们对应于模型中的动词，描述跨越时间和空间的行为。,行为事物包括：,交互,状态机,交互（interaction）,交互是这样一种行为，它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。,一个对象群体的行为或单个操作的行为可以用一个交互来描述。,图形上，用一条标有操作名的有向直线表示交互：,状态机（state machine）,状态机描述了一个对象或一个交互在生命期内响应事件所经
44、历的状态序列。,单个类或一组类之间协作的行为可以用状态机来描述。,状态机涉及到状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。,图形上，用含有状态名和活动的圆边矩形表示状态，用状态图表示状态机：,接受密码 do input,（3）分组事物,分组事物是UML模型的组织部分，它们是一些由模型分解成的“盒子”。最主要的分组事物是包。,包（package）,包是把元素组织成组的机制，结构事物、行为事物甚至其他的分组事物都可以放进包内（嵌套）。,注意：包是非物理的，纯粹是概念上的，也即仅在开发阶段存在。,图形上，用一个左上角带有一个小矩形的大矩形表示包：,（4
45、）注释事物,注释事物是UML模型的解释部分，用来描述、说明和标注模型中的任何元素。,注解是主要的注释事物。,注解（note）,注解是一个依附于一个或一组元素之上，对其进行约束或解释的简单符号。,图形上，用一个右上角是折角的矩形表示注解：,2）关系,是指发生在组成系统的事物之间的关系。事物之间的主要关系有：依赖、关联、泛化和实现等。,（1）依赖,依赖是两个事物之间的一种语义关系，其中一个事物（独立事物）的改变会影响另一事物（依赖事物）的语义。,依赖的基本表示法：一条可能有方向的虚线：,（2）关联,关联是对象之间连接（链）的抽象，用来描述对象之间的相互作用。,（3）泛化,泛化是一种一般/特殊关系，
46、也即一般事物（一般类）和特殊事物（特殊类）之间的关系。,关联的基本表示法：在类之间画一条直线（可能有方向）：,泛化的基本表示法：在特殊类和一般类之间画一条 带空心箭头的实线：,3）图,图是一组UML元素（事物和关系）的图形表示，它可以包含系统任何事物及其关系的组合，也即系统或系统局部的投影符号。例如一张为简单协作建模的类图可能就包含了参与协作机制的类、接口、协作等事物以及这些事物之间的关系。有以下九种图：,类图、对象图、用况图、顺序图、协作图、 状态图、活动图、构件图、实施图,（1）类图,一种结构图，显示一组类、接口、协作以及它们的关系。,类图用来为词汇建模、为协作建模、为数据库模式建模。,（
47、2）对象图,一种结构图，显示一组对象以及它们之间的关系。,（3）用况图,一种行为图，显示一组用况、参与者以及它们之间的关系。,（4）顺序图,一种行为图，描述一个交互（事物之间的交互），强调消息的时间排序。,（5）协作图,一种行为图，描述一个交互，强调发送消息和接收消息的对象间的结构关系和结构组织。,（6）状态图,一种行为图，显示一个状态机，强调一个对象或交互的按事件排序行为（因事件引发，所产生的行为和状态的改变）。,（7）活动图,一种行为图，显示一个状态机，强调从活动到活动的流。,（8）构件图,一种结构图，显示一组构件以及它们之间的关系。,（9）实施图,一种结构图，显示一组节点以及它们之间的关
48、系。,4. UML规则,UML提供了一套语义规则，这些规则描述了一个结构良好的模型看起来应该象什么。,命名,范围,可见性,完整性,执行,UML提供的描述事物的语义规则如下：,换句话说，这些规则可以用来描述模型中三种构造块之间的语义联系，用以保证模型在语义上是前后一致的，并且与所有的相关模型协调一致。,命名（naming）：,为事物、关系和图起名。,例如：,Validate user,Validate user用况名,范围：,给一个名称以特定含义的语境。,例如，转帐（一个用况）的语境是：顾客、出纳员和 帐户，这些元素共同完成转帐操作。,可见性（visibility）：,表示元素的名称如何被其他元
49、素看到和使用。,例如关联的导航、关联的角色等。,完整性（integrity）：,事物之间的合理性和一致性。,保证事物正确、一致地相互联系。,执行（perform）：,运行或模拟动态模型的含义是什么。,5. UML中公共机制,UML提供的公共机制包括：,详述,修饰,通用划分,扩展机制,前三个机制（语法）用来建立具有公共特征的结构模式，以使UML变得简单些；扩展机制允许以受控方式对UML进行扩展（增加语法成分、提高描述能力和语义约束）。,详述和修饰以公共机制的形式增加了模型各元素的细节。从这个意义上讲，建模语言本身被简化了。,详述：,详述是对UML图形符号的补充，对图形表示法的每一部分（图形符号）都可以附上一个详述，该详述提供了对构造块的语法和语义的文字叙述。,例如：在一个类的图形符号背后就有一个有关该类的 详述，它对该类所拥有的属性、操作（包括完整的特 征标记）和行为进行全面的描述。,UML的图形表示法用来对系统进行可视化；UML的详述用来描述系统的细节，二者相辅相成。经验表明，相当多的详述工作必须在设计阶段方能完成。,修饰：,修饰是附加到元素的基本表示法上的文字或图形项，用于对元素规格说明的细节进行可视化。,例如：关联的基本表示法是两个类之间的一条线， 可以用各端的角色和多重性等细节来修饰关联。,
