管理信息系统-MIS 5 面向对象方法学 5.1 面向对象方法学的产生及其发展 传统的开发方法存在的问题： 一般认为，传统的结构化方法学有三个主要缺陷： 问题空间与解空间不一致 长期以来，人们一直在设法寻求问题空间与求解空间在结构上的同构，即一致性，以便使我们分析、设计和实现系统的方法学原理与我们认识客观世界的过程尽可能一致。而这正是面向对象的方法学的出发点和所追求的基本原则。面向对象方法学的实质可以概括为：归纳——演绎的方法学，是一个从特殊到一般（归纳），由一般到特殊（演绎）的过程。面向对象方法学的产生的根本原因是为了解决“软件危机”，有些学者在研究、分析软件危机产生的原因时曾指出“用冯.诺依曼机所求解的问题的问题空间结构与冯.诺依曼机所用的求解问题方法的方法空间结构不一致”，这是导致软件危机产生的主要原因，这种不一致主要表现在以下几点：

管理信息系统-MIS 5 面向对象方法学 5.1 面向对象方法学的产生及其发展 1.问题空间和解空间不一致 1）语言的鸿沟： 指用来解决问题的求解语言即计算机语言与人类自然语言之间的语言的距离较远。 客观世界是由实体组成的，客观实体之间的多种多样的联系构成了五彩缤纷的客观世界，因此，人类认识客观世界首先是从概念以及概念之间的联系出发，概念反映了客观存在的实体，联系反映了实体间的依赖关系，是实体赖以生存的方式。 语言反映了人们解决问题的方式。传统的面向过程的语言是由一组数据和一组能动的过程即进程组成的，他所用的概念显然与人类认识客观世界所用的概念相去甚远，是一种难以理解的语言。而面向对象方法学由于在问题空间和求解空间上所采用的概念是完全一致的，因而他所采用的语言更接近于自然语言。

管理信息系统-MIS 2）冯.诺依曼机与问题域（用户）之间的鸿沟 有专家指出，传统的计算机虽然有各种各样的体系结构，但未从根本上改变冯.诺依曼机的基本特征。冯.诺依曼机的基本特征是顺序地执行指令，按地址访问线性的存储空间，数据和指令在机器内部采用统一的表示形式，以及数字计算。对用户来讲，这种机器（裸机）的功能是很有限和很不直观的。为了满足用户的需求，就在裸机上利用软件来构造不同层次的虚拟机，每一层虚拟机都可看成是一种语言的翻译器或解释器，用这种方法来填补用户和裸机之间的鸿沟。但虚拟机的层次越多，软件的开销就越大，可靠性和可维护性就越低。例如： 两个人对话交流，一个说英语，一个说汉语，如果中间必须经过很多翻译环节，如英语→法语→日语→德语→汉语，则在这个通信过程中由于各种语言并不完全对应，会产生理解上的差异，甚至不一致，环节（层次）越多，理解的不一致的可能就越大。因此，如果与不懂计算机技术的用户交流，最大的问题是能否有一种语言能使用户和计算机专业人员有一种共同理解的语言，面向对象的方法从根本上解决了这个问题，运用该方法更容易和用户沟通。由于面向对象的方法是从研究“做什么”和实体开始的方法，因而给设计人员和用户设置了一个共同的起点，使设计人员很容易和用户建立共同语言。

管理信息系统-MIS 5 面向对象方法学 5.1 面向对象方法学的产生 系统分析到系统设计的过渡困难 传统的结构化方法中，系统分析模型是为了解决系统分析员与用户之间的通信问题，而系统设计模型是为了解决系统分析员与程序员之间的语言问题，有分析向设计过渡是一件非常困难的事情。 3. 过程模型和数据模型能够分别建立，忽视了信息系统的行为特征 结构化方法学在建立系统模型时，是从功能和数据两个不同角度分别构造，这样产生的一个突出问题是所建立的过程模型和数据模型可能存在着不一致性，并且忽视了信息系统的行为特征（例如在Windows操作系统中，引进关于事件驱动的方法，实际上就是建立在行为这一概念的基础上的）。

管理信息系统-MIS 5 面向对象方法学 5.2 面向对象方法学的基本概念 面向对象的基本原理就是按照人类自己认识客观世界的一般方法和一般的思维方式去分析问题和解决问题。换言之，OO方法直接反映了人们对客观世界的认识模式。即从特殊到一般的归纳过程，从一般到特殊的演绎过程。 面向对象方法的特点 从应用设计到解决问题的方案更加抽象化，而且具有极强的对应性。 在设计中容易和用户沟通 把数据和操作作封装到对象里去 设计中产生各式各样的部件，然后由部件组成构架、以至到整个程序。 由OO设计出来的应用程序具有较好的重用性，易修改、易维护和扩充。

管理信息系统-MIS 5 面向对象方法学 5.3 几种面向对象方法的代表人物和推出时间 很多研究者对面向对象方法学作过比较深入的研究，并提出了许多实施该方法的框架。如： 1 J.Rumbaugh 等1991年提出的面向对象的建模技术（OMT） 2 Peter.Coad and E.Yourdon 1991年提出的面向对象的分析和设计 3 B.Henderson-Senlors and J.M.Edwards面向对象软件生命周期的“喷泉”模型 4 ESA(欧洲航天局) HOOD(Hierarchical Object_Oriented Design)1989推出 5 Booch 1991年提出OOD 6 Coad 于1995年在上述Coad/Yourdon 方法的基础上进一步完善OOA/OOD

管理信息系统-MIS 5.3 几种面向对象方法 六种面向对象的方法： 1. OOA/OOD（面向对象分析/设计） Cord/Yourdon 2. OOSE （面向对象软件工程） Jacobson 3.OOAD （面向对象分析设计） Mrtin/Odell 4.OMT （对象建模技术） Rumbaugh 5.OOSA （面向对象系统分析） Shlaer/Mellor 6.DOOS （面向对象设计软件） Wrifs-Brock

管理信息系统-MIS 5.3 几种面向对象方法 1. OOA/OOD（面向对象分析/设计） Cord/Yourdon 定义对象 定义结构 泛化 整体 定义主题 标识属性 属性 实例连接 标识服务 定义对象状态 定义所需服务] 定义消息连接状态

管理信息系统-MIS 5.3 几种面向对象方法 2. OOSE （面向对象软件工程） Jacobson 需求分析—需求模型 用例模型（角色、用例） 描述用户接口 问题域对象模型（对象名、逻辑属性、静态实例连接、继承、动态实例连接、操作） 分析—分析模型 定义分析对象（接口对象、实体对象、控制对象） 对分析对象的操作 定义系统

管理信息系统-MIS 3.OOAD （面向对象分析设计） Mrtin/Odell 标识分析的中心 定义域 定义目标事件 阐明事件类型 判断事件类型并选择层次 统一事件类型 判断事件类型 标识操作条件 定义操作 判断是外部操作环视内部操作 标识控制条件 控制条件标准化 标识操作起因 标识触发事件类型 指明复杂的事件条件 使触发事件类型标准化 具体说明触发规则 精炼出循环结果 判断触发事件类型 具体说明目标事件类型 检查是否有重复事件

管理信息系统-MIS 4.OMT （对象建模技术） Rumbaugh 对象模型 标识对象和类 准备一个数据字典 在对象间标识关联（包括聚集） 标识对象和连接的属性 用继承组织并简化对象类 检查存取路径是否有疑问 提取模型 将类组成模块 动态模型 说明一组事件间主要的相互作用 在对象间标识事件 为每个说明准备一个事件轨迹 建状态图 在对象间进行事件匹配，以核实其一致性 功能模块 标识输入/输出值 建数据流程图来表明功能的依赖 描述功能 标识强制因素 指明良好准则

管理信息系统-MIS 5.OOSA （面向对象系统分析） Shlaer/Mellor 域分析 标识域 标识桥 定义子系统 构建信息模型 对象 属性 关系 子型和超型 构建状态模型 对象生命周期 关系生命周期 对象通信模型 构建过程模型 活动数据流程图 对型存取模型

6.DOOS （面向对象设计软件） Wrifs-Brock 探索阶段 读懂说明书 标识类 说明书中抽取名词型词组 寻找可能被隐藏的名词性词组 在名词性词组中标识后选类 标识后选抽象超类 用范畴来寻找可能丢失的类 为每个类的目的写一简短的模型语句 定义职能 寻找职能 为每个类分配职能 通过寻找类间的关系标识附加的合作 抛弃不参与任何合作的类 分析阶段 定义继承 构建继承图来说明继承关系 标识抽象的类和具体的类 画VENN图来表明各自的职能 构造类的继承 构造合同 定义子系统 为你的系统画一个完整的合作关系图 在你的设计中表明可能存在的子系统 简化子系统间或其内部的合作 定义协议 为每个类构造一个协议 为每个类写一设计说明书 为每个子系统写一设计说明书 为每个合同写一设计说明书

管理信息系统-MIS 5.3 面向对象方法学 1.OMT（Object Modeling Technique）方法 由James Rambought提出，是美国通用电气公司内部采用面向对象技术的实践总结。它用三种模型来描述软件系统，实际上是从三个不同角度去完整地描述系统： 对象模型：代表系统的静态结构，描述了系统中对象结构，即对象标识、对象属性及服务、对象间关系。他为动态模型和功能模型提供了主要框架。实际上，对象模型由许多术语组成，如商业软件系统，对象模型包括许多商业术语。在系统分析时，确定对象类，定义设计字典（有类、属性、关系描述）用类图表示。 动态模型：反映按时间顺序操作，描述对象的动态行为，描述软件系统中与时间有关的服务操作顺序，包括事件序列、事件序列上下文的状态以及时间和状态的主次。 功能模型：反映系统各对象内部状态值关系，它指出什么时候事件发生，要发生什么。它表示系统如何从输入值得到输出值，包括函数、映射、约束和功能的依赖关系。功能模型描述了系统做什么，但不描述如何做。它由许多数据流图组成。 三个模型都包括了相同的概念、数据、序列和服务操作，但它们描述了系统的不同方面，也互相引用。

管理信息系统-MIS 5.3 面向对象方法学 2.Booch 方法 2.Coad和 Yourdon 方法 该方法是在面向对象语言、信息模型化技术和知识库系统的基础上发展而来的。它由面向对象的分析和面向对象的设计两部分组成： 面向对象的分析（OOA）：完成对系统的问题进行形式化描述，确定系统的边界、环境、规则和约束；确定系统的功能、系统对象协同工作的规定。由5个分析层次组成：类与对象、属性、服务、结构、主题。 面向对象的设计（OOD）：在OOA的5个层次上进行设计，不同的是它用于系统设计模型的四个部分：问题域、用户界面、任务管理、数据管理。

管理信息系统-MIS 5.4 面向对象模型理论基础 面向对象模型（Object-Oriented Model OOM）将模型信息用标准化的图形元素直观地显示出来。这种模型可以在几个层次上显示系统的工作状况，是软件系统强有力的工具。面向对象建模的一个重要问题是用哪种图形标注方法标识系统的各个方面。目前常用的图形标注方法有Booch方法、对象建模技术（OMT），和统一建模语言（UML），其中UML是大多数公司采用的标准。 5.4.1 UML的基本知识 UML由三位面向对象方法领域著名的方法学家Grady Booch,James Runbaugh , Ivar Jacobson提出，并结合众多优秀软件开发的方法和思想，得到了世界许多知名公司的使用和支持，于1997年被世界OMG(Object Management Group)组织采纳，成为面向对象建模的标准语言。 1994年， Runbaugh加入到Rational软件公司工作，而Booch早已在那里工作。第二年Jacobson也加入了该公司。以后的事正如他们所说，是具有历史意义的。UML草案版在软件工业界流传开来，并根据大量的反馈信息做了大幅度的修改。由于许多公司认为UML能够适应这些公司的战略目标，因此一个UML联盟蓬勃发展起来。

管理信息系统-MIS 5.4 面向对象模型理论基础 5.4.1 UML的基本知识 UML联盟的成员包括一些著名公司，如：Hewlett-Packard ,Intellicorp, Microsoft , Oracle , Texas Instrument , DEC , Rational等。1997年，应“对象管理组（Object Management Group, OMG）”向外界征求标准建模语言的建议，联盟制订了UML1.0版交给OMG。1997年UML1.1版被OMG采纳为标准。从此UML成为软件工业界事实标准。 UML是一种标准的图形化建模语言，它是面向对象分析和设计的标准表示。UML中包括：用例图、时序图、类图、对象图、状态图、协作图、活动图、组件图、展开图共九种。这种表示方法有效地促进了不同背景人们的交流，有效地促进了软件设计、开发和测试人员的相互理解。 UML提供这些图的目的是用多个视图来展示一个系统（这组视图被称为模型）。一个系统的UML模型有点像一个建筑物按比例缩小并经艺术家修饰后的建筑模型

管理信息系统-MIS 5.4 面向对象模型理论基础 在UML中，把可以在各种图形中使用的概念统称为模型元素或模型对象，简称对象。模型元素在图形中用其相应的符号表示，称为对象符号，或对象图形符号。对象符号可以存在于多个不同类型的图中，但是具体以什么的方式出现在图中要符合一定的规则。模型元素与模型元素之间的连接关系也是模型元素，常见的连接关系有关联（Association），概化（Generalization），依赖（Dependency），实现（Realization），聚合（Aggregation）. 1 用例图（use case diagram） 什么是用例图 用例图是系统的高级功能模型。是从用户的观点对系统行为的一个描述。该模型模拟了外部用户所认识的系统功能，这个外部用户称为角色（Actor）。用例图是OOM的一部分，它与类图和时序图共同构成OOM的主要部分。用例图显示了所描述系统中定义的对象符号，这些对象包括角色、用例以及它们之间的关系，它的主要目标是显示参与到每一个用例中的角色。通过用例图可以清楚地看到系统的功能。用例图中包含系统、角色、用例三种模型元素，如下图所示：

管理信息系统-MIS 5.4 面向对象模型理论基础 用例 用例是系统的一组使用场景。每个场景描述了一个事件序列，每个序列是由一个人、另一个系统、一个硬件设备或者某段时间的流逝所发起。这些发起事件的实体叫做参与者（actor）。事件序列的结果是由发起这个序列的参与者或者另一个参与者对系统某种形式的使用所引起的。 用例的重要性 用例是一个能促进系统可能的用户以他们自己的观点看待系统的一个优秀工具。用户并不总是容易清晰的阐明到底他们要怎样使用系统。因为传统的系统开发常常是一种缺少前端分析的偶然过程，因此当问及用户如何执行系统输入时，他们往往目登口呆。避免这种情况的基本思路是让用户参与前期的系统分析与设计。这样做可以使最终的系统尽可能地为用户所用，而不是仅仅是表现出了设计者的聪明才智而让用户无法理解和使用的一堆计算概念和业务模型。

管理信息系统-MIS 用例分析 买一台传真机场景。到了办公用品商店，面对众多的可选择的各式传真机，购买者不断问： 买传真机究竟干什么？ 传真机需具有哪些特征？ 传真机必须有哪些功能？ 需要复印功能？ 需要连接计算机？……….. 当我们慎重购物时，都会有这样的经历，这种经历就是某种形式的用例分析（use case analysis） ：我们反问自己究竟将如何使用产品或系统。了解这些需求是非常重要的。这个过程在系统开发阶段相当重要。用户对系统的使用方式决定了系统如何设计和构造。 用例是能够帮助分析员和用户确定系统使用情况的 UML组件。一组用例就是从用户的角度出发对如何使用系统的描述。

管理信息系统-MIS 举例：饮料自动销售机 假如现在你正在动手设计一台饮料自动销售机。饮料自动销售机的主要功能是允许一个顾客购买一罐饮料，很可能用户立即就能告诉你一些相关的场景（用例），可以给这组场景加个标题“买饮料”，这个用例的参与者是买饮料的顾客。当顾客将钱插入销售机触发了这个用例的场景被执行。接下来的场景如下： 用户将钱插入销售机（前置条件） 销售机自动弹出一罐饮料 用户得到一罐饮料（后置条件） 可以给这组场景加上一个标签“买饮料”，这个场景就是用例“买饮料”。

管理信息系统-MIS 用例“买饮料” 这个用例的参与者是买饮料的顾客。 顾客将钱插入销售机触发了这个用例场景。如果一切顺利，销售机至少有一罐被选中的饮料，则销售机会自动弹出一罐饮料给顾客。 这个用例的场景需要什么前置条件？——口渴 这个场景的执行步骤完成后需要什么后置条件？——顾客得到一罐饮料 除了上面的步骤序列，该场景其它方面也值得考虑。 显然，“买饮料”不是唯一场景，还有其它场景。如顾客要的饮料销售机中可能没有，顾客投入的钱数不是刚好，需要找钱。这就需要加入其它用例 其它场景 如果这时没有顾客需要的饮料，则给顾客一个提示信息 把顾客的钱退回 让顾客选择另一种饮料 如果顾客给的钱不是正好的，则找零 “买饮料”由上述一组场景构成

管理信息系统-MIS 其它用例包括 上面“买饮料”是从顾客的观点考察饮料机。出此之外，还有其他人加入： 供货人：负责为自动售货机提供饮料 收款人：负责定期收集售货机中的钱 考察“供货”用例：供货人发起这个用例是由于某个时间间隔到期所引起的。供货人打开销售机，拉出销售架，在架上补足各种饮料。 考察“收款”用例：收款人发起这个用例是因为隔段时间必须收钱，然后放些零钱，以便找零。收款人打开机箱，收取货款，放入零钱。然后锁好机箱。这样在饮料自动销售机中又加入了了个用例。“供货”和“取钱” 注意：当导出一个用例时，不必关心怎样实现它。在这个例子里，我们并不关心饮料机内部细节。我们也不关心机器内的制冷机如何工作。最终目标是导出一组用例供饮料机的设计者查看。用例详细的程度是要能正确反映顾客、收款人、供货人的需求，最后的结果是能根据这些需求制造出易于使用的饮料销售机。

管理信息系统-MIS 包含用例 在“供货”和“取钱”用例中，也许你会注意到一些相同的步骤：两个用例都是以打开机箱为起始点，锁好机箱为终止点，能不能消除用例中的重复步骤？ 可以，方法是从各个步骤序列中抽取出公共步骤形成一个每个用例都要使用的附加用例： 用例 “打开销售机” 将“开机”和“拉出饮料架”合并为一个“打开销售机” 用例 “关闭销售机” 将“放回架子”和“锁机器”合并为一个“关闭销售机” 这样，“供货”和“收款”这两个用例都包含了新用例。这种用例重用技术被称为包含用例（include a use case ）

管理信息系统-MIS 扩展用 除了“包含”用例外，还有另一个重用用例的方式，即“扩展”用例。有时，我们可以通过对已有用例增加一些额外的步骤来建立新的用例。 再回到“供货”用例。在给机器补充饮料时，供货代表注意到有些品牌的饮料好销，有些不好销。在这种情况下，他不是简单的把所有饮料补充给机器，而是把好销的饮料补充进去，把不好不好销的取出。如果把上述步骤加入“供货”用例，我们将得到一个新的用例，“根据销售情况供货”。这个新用例是对原用例的扩展，这种技术叫作扩展用例（extend a use case ）。 开始用例分析 1.首先与用户交谈 这个过程可以让你对系统有个概貌认识，逐步熟悉将要使用的术语，可以为你与用户进一步交流打下基础。 2.其次要询问用户准备如何使用系统，根据回答就能得到一组侯选用例 3.要简洁准确的描述出这些用例，要导出一个参与者列表，这些参与者或者发起了侯选用列，或者从侯选用例中得益。 4.在与拥护的交流中不断发现新的用例

管理信息系统-MIS 饮料销售机模型 在饮料销售机例中，有3个用例： 买饮料（buy soda） 供货 ( restock) 收款（collect） 参与者有 顾客（customer） 供货代表 （supplier’s representative） 收款人（collector） 下面显示了饮料销售机中的一个UML用例模型：

用例模型的表示方法 Soda machine Buy soda customer customer restock Supplier’s representative Supplier’s representative collect collector collector

管理信息系统-MIS 跟踪场景中的步骤 每个用例是一个场景的集合，而每个场景又是一个步骤序列（但这些步骤在图中并未表现出来）。用例图通常是供客户和开发组参考的设计文档的一部分。每个用例都有其自身的页。每个用例中场景描述也至少占一页，在文档中要描述下列内容： 发起者和参与者 用例的前置条件 场景中的步骤 场景完成后的后置条件 从用例中获益的参与者 还可以列出场景的假设条件（例如，一次只能有一个顾客使用饮料销售机）和简短的一句话的场景描述。

管理信息系统-MIS 用例之间的可视化表示 用例之间的几种相互关联： 包含（including ）、扩展（extending）、泛化（generalization）、分组（grouping ），下面分别介绍： 包含（including ） ：在一个用例中包含新的用例。如“供货”和“收款”用例中都包含了“打开销售机”和“关闭销售机”用例，这就是用例的包含关系。用虚线加箭头 表示。 箭头指向被依赖的用例，在箭头上加《include 》。 扩展（extending）：供货用例可扩展为“根据销售情况供货”，即将原用例进行了扩展，他在原用例的基础上增加了新的步骤序列。原用例被称为基用例（base use case）扩展只能发生在基用例的序列中某个具体指定点上，这个点叫做扩展点。 <include> Restock Extension point Fill the compartments Expose the inside <include> <extend> (fill the compartment) unexpose the inside Restock according To sales

Soda machine Buy soda customer customer restock Supplier’s Expose the inside 《include》 restock 《include》 Unexpose the inside Supplier’s representative Supplier’s representative Expose the inside 《include》 collect Unexpose the inside 《include》 collector collector

管理信息系统-MIS 用例之间的可视化表示 泛化：类可以继承另一个类，用例也是如此，在用例继承中，子用例可以从父用例继承行为和含义，还可以增加自己的行为。在饮料销售机例中，你可以想象一个叫做“Buy a cup of soda”的用例，这个用例是从“Buy soda”继承来的，在子用例中增加了一些行为，诸如：“加冰”、“混合饮料的品牌”。其表示方法如下图所示。 注意：参与者之间也存在泛化关系。 Buy a cup Of soda Buy soda 分组：在一些用例图中，用例的数目可能非常多，这就需要组织这些用例。这种情况在一个系统包含很多个子系统时会出现，；另一种可能是，当你按顺序和用户会谈，收集系统需求时，每个需求必须用一个单独的用例来表达，这时就需要某种方式来分类这些需求。 最直接的办法是把相关用例防在一个“包”（ package）中组织起来。

管理信息系统-MIS 5.4 面向对象模型理论基础 2 时序图（Sequence Diagram） 时序图用来反映若干个对象之间的动态协作关系，以及随时间的推移，对象之间是如何交互的。时序图主要反映对象之间发送消息(Message)的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一具体位置将会有什么事情发生。在面向对象的编程中，两个对象之间的一种交互表现为一个对象发送一个消息给另一个对象。在UML中，消息是作为对象间的一种通信方式来表示的，消息用连接发送者和接收者的一条箭头线表示，箭头的类型表示消息的类型。如下图所示： 同步消息: 一个对象发送一个消息后需等待对方应答后才能继续操作 异步消息：不需要等待对方应答 简单消息：从一个对象到另一个对象的控制流的转移 同步且立即返回消息

管理信息系统-MIS 5.4 面向对象模型理论基础 时序图描述了特定时间周期内UML对象的消息传递情况，同时还描述了UML对象之间的相互作用的行为，详细说明了类、接口以及它们可能使用的操作行为。时序图能够描述一次典型的交互，交互中涉及到类图中的类；也能够在需求分析期间规范用例的行为，简化用例的描述，因此通过时序图能够找到其他的UML对象。 时序图对于设计模型十分重要，因为它基于时间，按时序流阐明了UML对象的作用。建模通常从建立用例图开始，然后建立时序图。一个或多个时序图可以阐明UML对象的相互作用，一个相互作用代表一个用例。典型的时序图分为一个主流时序图和多个独立的用例子时序图。 在PowerDesigner中，产生时序图的方法与产生用例图的方法类似，即在新的OOM中产生时序图；在已存在的OOM中产生时序图；从弹出的菜单中产生时序图；在包中产生时序图。

管理信息系统-MIS 5.4 面向对象模型理论基础 以洗衣机为例来说明时序图。洗衣机的构件包括一个注水的进水管（Water Pipe）、一个用来装衣物的洗涤缸（Drum）、一个排水管（Drain）。当然，这些构件也是对象。当“洗衣服”这个用例被执行时，将会依次发生什么事情呢？假设你已经完成了“加衣物”、“加洗涤剂”、“开机”操作，那么洗衣步骤应按照如下顺序进行： 通过进水管向洗涤缸中注水 洗涤缸保持5分钟静止状态 水注满，停止注水 洗涤缸往返旋转15分钟 通过排水管排掉洗涤后的脏水 重新开始注水 洗涤缸继续往返旋转洗涤 停止向洗衣机中注水 通过排水管排掉漂洗衣物的水 洗涤缸加快旋转速度单方向旋转5分钟 洗涤缸停止旋转，洗衣过程结束。

管理信息系统-MIS 洗衣机洗衣时序图

管理信息系统-MIS 3 类图（Class Diagram） 类

Household Appliances :: WashingMachine 管理信息系统-MIS 3 类图（Class Diagram） 类的可视化表示 在UML中一个矩形表示一个类的图标。按照UML约定，类名的首字母大写，放在矩形的偏上部。如果类名是由两个单词组成，那么将这两个单词合并，第二个单词首字母大写（WashingMachine） 组件包用一个一边凸起的文件夹来表示，它的名字对类名有影响。Household Appliances（家用电器），如果WashingMachine 类是Household Appliances包的一部分，那么这个类的名字为： Household Appliances:: WashingMachine称为带路径名的类。图形表示如下 Household Appliances WashingMachine UML类图标 UML中的包 Household Appliances :: WashingMachine 带路径名的类

myWasher:WashingMachine 管理信息系统-MIS 属性 属性是类的一个特性，它描述了类的对象（即类的实例）所具有的一系列特性值。一个类可以具有零个到多个属性。UML约定,单字属性名小写，如果属性名包括了多个字，这些字要合并，并且除了第一个字外其余字首字母要大写。属性名列表放在类名之下，并且和类名之间用分隔线隔开。 类的属性在该类的每个对象中都有具体的值。对象名首字母小写，后跟冒号，冒号后面是该对象所属的类名，并且整个名字要带下划线。 myWasher:WashingMachine是一个命名实例(named instance)，也可以有诸如WashingMachine这样的匿名实例（anonymous instance） myWasher:WashingMachine brandName=“Laundatorium” modelName=“Washmeister” serialNumber=“GL57774” Capacity=16 WashingMachine brandName modelName serialNumber capacity 类和类的属性 类的属性在该类的对象中都有具体值

管理信息系统-MIS 操作（operatin） 操作是类能够做的事情，单字操作名小写。如果操作名包含了多个字，这些字要合并，并且除了第一个字外，其余字首字母要大写。操作名列表放在属性名列表之下，两者用分隔线隔开。可以为操作指定附加信息，在操作名后面的括号中可以说明操作所需要的参数和参数类型。有一种操作叫作函数（function），它在完成操作后要返回值。可以指明函数的返回值几返回值的类型。 WashingMachine brandName modelName serialNumber Capacity addClothes（） removeClothes（） addDetergent（） turnOn( ) WashingMachine brandName modelName serialNumber Capacity addClothes(C:String) removeClothes(C:String) addDetergent(D:Integer) turnOn():Boolean 类的操作示例 操作的型构 上述全部的操作信息被称为操作的型构（signature）。

在实践中，不一定要把类的属性和操作都表示出来 管理信息系统-MIS 属性、操作和可视化表达 对于同时表示多个类，有时没有必要总是显示这些类的所有属性和操作（可能会使图形表示比较混乱），相反，可以只给出类名，而将属性或操作区（或两者全部）空着。有时，只显示类的一部分属性和操作。为了说明你只表示出部分操作和属性，可以在列表的后面加上省略号，这种省略了一个或多个属性或操作的表示方法叫做类的省略表示法（eliding class） WashingMachine WashingMachine WashingMachine brandName … addClothes（） 在实践中，不一定要把类的属性和操作都表示出来 省略号说明还有没有列出来的属性或操作

管理信息系统-MIS 构造型 如果属性或操作列表太长，可以用构造型来组织属性或操作列表，以方便理解。构造型是UML提供的扩展机制，允许创建新的模型元素以解决具体问题。构造型用双尖角括号括住的名字来表示。它有多种不同的使用方式。 WashingMachine 《id info》 brandName modelName serialNumber 《machine info》 Capacity 《clothes-related》 addClothes(C:String) removeClothes(C:String) addDetergent(D:Integer) 《machine-related》 turnOn():Boolean 可以使用构造型来组织属性和操作列表

管理信息系统-MIS 职责和约束 1.职责（responsibility） 类图标中还可以指明另一种类信息。在操作框下面的区域，可以用来说明类的职责。描它述了类做什么—即类的属性和操作能完成什么任务。比如，一台洗衣机的职责是将脏衣服作为输入，输出洗干净的衣服。其表示方法如下： WashingMachine 《id info》 brandName modelName serialNumber 《machine info》 Capacity 《clothes-related》 addClothes(C:String) removeClothes(C:String) addDetergent(D:Integer) 《machine-related》 turnOn():Boolean Responsibility: Take dirty clothes as input and produce clean clothes as output 在类图标中，操作列表区域的下面区域可以写类的职责,说明类的职责是消除类的二异义的一种非形式化的方法

管理信息系统-MIS 职责和约束 2.约束（constraint） 更形式化的消除类的二义性的方式是约束，它是用一个花括号括起来的自由格式的文本来指定该类所要满足的一个或多个规则。例如，指定WashingMachine类的洗衣机容量只能是16、18、20磅（即对WashingMachine类的capacity属性施加约束）。如下图所示： WashingMachine brandName modelName serialNumber Capacity addClothes（） removeClothes（） addDetergent（） turnOn( ) {capacity = 16 or18 or 20lb} UML中提供了另一种方式（也是非 形式化）来施加约束，以使模型元素的语义定义更加明确。她实际上也是一个完整的语言，被称为对象的约束语言（Object Constraint Language OCL）。OCL是UML的一个高级的但是更有用的工具，有自己的规则、术语、操作符。 用花括号括起来的规则表达式限制了洗衣机的容量值只能三者选一

管理信息系统-MIS 附加注释 在UML中可以对类附加注释信息，以便给类填加更多的信息。如，可以给洗衣机属性serialNumber（序列号）引用国家标准，那么，根据这个标准可以参考相关标准以查阅相关信息。表示方法如下： 序列号的生成参考美国政府 标准EV5-2241 WashingMachine brandName modelName serialNumber Capacity addClothes（） removeClothes（） addDetergent（） turnOn( ) 附加的注释可以提供有关类的更多信息

管理信息系统-MIS 类—应该做什么？如何识别它们？ 类代表的是领域知识中的词汇。同用户交谈，分析他们的领域知识，设计用来解决领域中的问题的计算机系统，同时也就是在学习这些领域词汇，并用UML中的类建立这些领域词汇的类型模型。在与用户的交谈中，要注意用户用来描述业务实体的名词术语，名词：它可以作为领域模型中的类。动词：可以构成这些类中的操作。当得到一组核心列表后，应当向用户询问在业务过程中每个类的作用，他们的回答将告诉设计者这些类的职责。见以下例：

管理信息系统-MIS 例：建立篮球比赛模型 概述：篮球比赛的目标是将篮球投入蓝框，并尽可能地多投进蓝框。每个篮球队由5名队员组成：后卫2名、前锋2名、中锋1名，每个队要将球推进到蓝框附近，目的是将球投入蓝框。可以通过运球和传球将球推进，每次某一队必须在规定的进攻时间内投篮，否则违例，将球权交给对方。规定的进攻时间是在某方获得控球权后开始计算。控球计时：美国职业篮球比赛是24秒、国际篮球比赛是30秒、美国大学篮球比赛是35秒。比赛得分：按如下方式计算：三分线之内投中得2分、三分线之外投中得3分、一次罚球得1分。职责：一般后卫队员通常主要任务是运球和传球，前锋队员通常是投球和抢蓝板球，中锋通常离蓝框比较近，所以由他完成蓝下进攻和防守。所有队员都应具备运球、传球、投球、抢蓝板球等技能。篮球场大小尺寸如下：场地：国际比赛场地为28米长、15米宽，蓝框离地面高度为3.05米。比赛时间：在美国职业篮球比赛中，一场比赛为48分钟，分为4节，每节12分钟。在美国大学和国际比赛中，一场比赛40分钟，分为上下两个20分钟的半场，有专门的比赛时钟记录比赛还剩余多少时间。通过分析上面的陈述可发现 名词：篮球（Ball）、蓝框（Basket）、篮球队（Team）、队员（Player）、后卫（Guard）、前锋（Forward）、中锋（Center）、投篮（Shot）、进攻时间时钟（Shot Clock）、三分球（Three-Point Line）、罚球（Free Throw）、犯规（Foul）、罚球线（Free-Throw Line）、球场（Court）、比赛时钟（Game Clock）。 动词：投蓝（shoot）、推进（advance）、运球（dribble）、传球（pass）、犯规（foul）、抢蓝板（rebound）。

Player name Height weight dribbleBall() shootBall() passBall() rebound() foulOpponent() Guard Does most of the dribbing and passing Forward Does most of the intermediate range shooting and rebounding Center Stays near basket, shoots from close range Ball diameter Volume dribble() Shoot() Pass() Advance() Team Basket Foul Shot Court ThreePointLine FreeThrow FreeThrowLine { pro = 24 sec College = 35 sec Int’t = 30 sec } ShotClock GameClock { pro = 4 12-minute quarters College and Int’t = 2 20-minute halves } Duration { pro = 48 minute College and Int’t=40-minutes }

管理信息系统-MIS 关系 Player Team 在上面完成的关于篮球比赛模型中，只有一些代表篮球运动词汇的类，尽管这幅图是进一步研究篮球比赛的基础，但很显然还缺少了一些东西。这些东西就是类之间的连接方式，即图中并没有说明队员和篮球之间有什么关系、队员是如何组成球队的、一场比赛是如何进行的。 关联（association） 当类之间在概念上有连接关系时，类之间的连接叫关联。如：篮球比赛的初步模型中我们可以研究其中一个关联：队员和球队之间的关联，可以用短语“队员为篮球队效力（Plays on）”来刻划这个关联； Plays on Player Team 注：关联的方向很重要

管理信息系统-MIS 关系 Player Team 关联（association） 当一个类和另一个类发生关联时，每个类通常在关联中都扮演着某种角色。在队员和球队的关联中，如果球队是职业篮球队，那么它就是队员的顾主，队员就是球队的雇员。 Player Team Plays on Employee Employer 说明：参与关联的每个类通常都扮演着某种角色，可以在图中表明这些角色

管理信息系统-MIS 关系 Player Team Team 关联（association） 关联还可以从另一个方向发生：篮球队雇佣队员，可以把这两个方向上的关联表示在一个图中： Plays on Player Team Employs 关联还可以连接好几个类，如下图表示： Plays on Guard Team Plays on Forward Plays on Center 多各类可以和同一个类关联

管理信息系统-MIS 关系 关联上的约束 有时，两个类之间的一个关联随后就有一个规则。可以通过关联加约束来说明这个规则。例如：一个银行出纳员为一个顾客服务，但是服务的顺序要按照顾客排队的次序进行，表示如下： Bank Teller Customer Server {ordered} Employee Employer 另一种类的约束是或“Or”关系，如下图表示： Chooses HighSchoolStudent Academic {or} Chooses Commercial 说明：参与关联的每个类通常都扮演着某种角色，可以在图中表明这些角色

管理信息系统-MIS 继承和泛化 面向对象的一个特点就是它能够反映日常生活：如果你知道某物所属的种类，你自然就会知道同类的其它事物也具有该事物的一些特征。当知道某物是动物，那么它自然具有吃饭、睡觉、繁殖、迁徒以及应具有的其它一些立即能够列出的属性和操作，这种关系被称作继承（inheritance）,UML中称之为泛化（generalization）,一个类（子类）可以继承另一个类（父类）属性和操作（继承层次并不只有两层，可以有多层）见下图： Animal Amphibian Mammal Reptile Mammal 动物王国的继承关系

管理信息系统-MIS 找出继承关系 需求调查时，在与用户交谈过程中，系统分析员可以发现类之间的继承关系，作为后选的类有可能和他的父类、子类在谈话中被发现。例如：在篮球比赛中，Player、Guard 、Forward、 Center等类， Player类通常有名字、身高、体重、奔跑速度、垂直起跳高度等属性，同时有dribble()、pass() 、 rebound()、shoot()等操作， Guard 、Forward、 Center继承运球、传球、抢蓝板等属性和操作，同时，增加了他们自己的一些属性和操作，Gurad可能具有操作runOffense()和BringBallUp；Center可能具有操作slamDunk()（扣蓝），根据教练员介绍的篮球队员的相对高度，系统分析员可能要对这些队员施加相应的约束。 此外，系统分析员应注意到两个或多个类可能具有相同的属性和操作数。篮球比赛模型中有一个GameClock类（它负责记录距比赛结束还剩多少时间），另一个类ShotClock类（它记录某方得到控制权后还剩多长时间必须投篮），两者都是用来记录时间的，意识到这点，系统分析员就能设计出Clock类，它具有trackTime()操作（计时操作），GameClock类和ShotClock类都继承了这个操作。图示见下例：

管理信息系统-MIS 类的继承示例 Player name Height weight dribbleBall() shootBall() passBall() rebound() Clock trackYime() ShotClock GameClock Guard runOffense() bringBallUp() Forward Does most of the intermediate range shooting and rebounding Center slamDunk() Stays near basket, shoots from close range 类的继承示例

管理信息系统-MIS 依赖 一个类使用类另一个类，这种关系叫依赖关系（dependency)，最常的依赖关系是一个类操作的型构中用到了另一个类的定义。假设要设计一个能显示公司全体成员的制表系统，公司的员工可以填写这个系统中的电子表格，员工要选择菜单来填写表格。设计时有一个System类和一个Form类，System类的操作中有一个操作，DisplayForm(f：Form)，系统所要显示的表格取决于用户选择的表格。依赖关系如下图所示： System DisplayForm() Form 依赖关系用带箭头的虚线表示

管理信息系统-MIS 聚集（aggregation） 一个类由几个部分类组成，这种特殊类型关系叫作聚集。部分类和由它们组成的类之间是一种整体—部分关联。例如：计算机是一个聚集，它由主机箱、键盘、鼠标、显示器、CD-ROM、硬盘…..等，则家用计算机聚集关联表示如下： HomeComputer 1 2 1 1 1 1 Speaker CPUBox KeyBoard Monitor Mouse 2 1 1..* * 1 1 1 1..3 1 DisketteDrive HardDisk RAM CD-ROM GraphicsCard SoundCard Button MouseBall 1 is connected to 聚集（整体-部分）关联表示法

管理信息系统-MIS 5.5 在系统开发中运用UML 开发过程中必须做什么 早期简单的应用系统开发，分析问题、设计解决方案、编制程序代码一般都是 由一个人完成，现在，为了开发各种复杂、大型的系统，需要一个开发团体协 同进行，因为知识越来越专业化，一个人不可能知道一个企业的所有方面。那 么就需要一整套方法来指导和协调应用系统的开发，所以一个方法学必须能够 做到： 保证开发团体对所要解决的问题有个坚实的理解 要考虑到开发团体是由不同角色组成（各种工作产品要能适应各类角色 ） 能够在团体的不同角色成员之间建立良好的通信关系 充分考虑跨越阶段的开发过程中的反馈信息 开发出能够向用户反映开发进度的各种工作产品（避免产生过多的书面 材料）

管理信息系统-MIS 5.5 在系统开发中运用UML GRAPPLE 快速应用工程指导原则（Guidelines for Rapid Application Engineering）是一组 可自适应的，灵活的应用系统开发思想，可以把它看成是开发过程的简要骨架。 GRAPPLE由5个段（segment）组成，注意：不用阶段为的是说明不是通常意义 上一个阶段完成后才能开始下一个阶段工作。GRAPPLE主要适用于面向对象系 统，因此每个段的动作主要是生产面向对象的工作产品，5个段工作如下： 需求收集 分析 设计 开发 部署 这5个段组成的过程简称为RADDD或RAD3

管理信息系统-MIS 需求收集(requirements collectin)：了解业务领域，理解用户需求 发现业务过程：获得对用户业务过程的理解，特别是获得对要使用的目标 系统的用户的理解，方法：得到一套用户业务领域的词汇，工作产品：一 个或一组能够捕获业务过程中的步骤和判定点的活动图 领域分析：获得尽可能深刻地理解用户的领域，理解领域中的主要实体， 方法：对象建模人员听取名词，然后为名词建立一个类（识别类）；听取 动词以发现类的操作。工作产品：一个高层类图和会谈记录 识别协作系统：找出新建系统要依赖哪些老系统，哪些老系统要依赖新建 的系统，为准备新建系统建立部署图 发现系统需求：对系统前期工作（发现业务过程、领域分析）总结。方法 ：开第一次联合应用开发会议（Joint Application Development session, JAD session），工作产品：得到一个包图（每个包代表了一个系统的高层 领域，包括了一组用例） 将结果提交用户：在完成了上述需求活动后，项目经理就要将活动结果提 交用户，有些结果需要用户的认可后才能进入下一段工作，有些结果可能 要对其估算成本。

管理信息系统-MIS 分析（analysis）：深入分析需求段的结果，增进对问题的理解 理解系统的用法：这是一个高层用例分析，找出发起每个用例的参与者及从这些用例 中获益的参与者，方法：与用户一起对前期的用例图进行分析，并试图开发出新的用 例。工作产品：一组用例图（图中说明了用例和用例的参与者，以及带构造型的用例 之间的依赖关系《extends》和《include》） 充实用例：分析出每个用例中的步骤序列。工作产品：对每个用例步骤的文本描述 细化类图：在JAD session 期间，对象建模者听取所有讨论，继续细化类图，对象建模 者应当在类图中加入关联名、抽象类、多重性、泛化、聚集，工作产品：细化的类图 分析对象状态变化：对象建模者对模型进一步细化，要展示出对象状态的变化。工作 产品：状态图 定义对象之间的交互：开发组根据一组用例图和细化的类图，定义对象之间如何交互 ，对象建模者开发一组时序图和协作图来描述来描绘对象间的交互。工作产品：一组 时序图和状态图 分析与协作系统的集成：系统工程师要找出与协作系统集成的具体细节（何种类型的 通信？何种网络体系结构？如果要访问数据库，那么数据库分析员要决定数据库的逻 辑和物理结构）。工作产品：系统部署图（如果必要的话还有数据模型）

管理信息系统-MIS 设计(design)：使用分析段的结果来设计系统的解决方案 开发和细化对象图：程序员根据类图产生一些必要的对象图，检查每个操作并开发对 应的活动图去充实对象图。方法：与用户一起对前期的用例图进行分析，并试图开发 出新的用例。活动图将是开发段中编码的基础。工作产品：上述的对象图和活动图 开发构件图：程序员将可视化的描绘出构件与构件之间的关系。工作产品：构件图 制定部署计划：当构件图完成后，系统工程师开始编制系统的部署，以及系统与其它 协作系统集成的计划，系统工程师要绘制系统的部署图。工作产品：部署图 设计和开发用户界面原型：GUI分析员与用户一起开发纸面上的用户界面构件原型（ 按钮、复选框、下拉列表框、菜单），用户对界面满意后，开发人员就开发显示器上 的用户界面原型。工作产品：屏幕界面原型快照 测试设计：用例是进行测试设计的依据，目标是评价所开发的的应用系统是否能够满 足用户的需要（即能够实现用例描述的事情），较好的方法是请另外的测试专家编制 测试脚本。工作产品：测试脚本 开始编制文档：系统最终用户和系统管理员使用的文档不要过早编制。编制文档的专 业人员与开发人员一起共同编制文档，制定出每个文档的高层结构。工作产品：文档 的结构

管理信息系统-MIS 开发(coding)：根据分析和设计段的结果，编制应用代码 编制代码：根据掌握的类图、对象图、活动图和构件图，程序员编制 实现系统的代码。工作产品：应用系统代码 测试代码：测试员（有经验的测试员而不是开发人员）运行测试脚本 、评价代码是否实现了预期的功能、检查代码的缺陷(bug)，这个工 作产生的信息要反馈到前面的工作中，直到代码通过了所有层次的测 试。工作产品：测试结果 构建用户界面和用户界面到代码的连接及测试：GUI专家构建用户界 面并将界面连接到代码，要进一步的测试，确保用户界面的正确。工 作产品：带有用户界面的功能系统 完成文档：编制文档的专职人员与程序员并行工作，确保文档及时完 成和交付。工作产品：文档

管理信息系统-MIS 部署(deployment)：开发完成后，将系统部署到计算机上 编制备份和恢复计划：由系统工程师编制计划，以防系统崩溃。计划 中要详细说明如何备份系统以及系统崩溃后如何恢复。工作产品：系 统备份和恢复计划 在硬件上安装最终系统：系统工程师在必要的开发人员的协助下，将 最终开发好的系统部署到合适的计算机上运行。工作产品：完全布置 好的计算机系统 测试安装后的系统：最后开发组还要对安装好的系统进行测试。他是 否能达到预期的一同目标？备份和恢复机制能否起作用？测试的结果 将决定系统是否需要进一步精化。工作产品：测试结果 庆祝：开发组庆祝一个新系统的诞生。工作产品：新系统

管理信息系统-MIS GRAPPLE总结 GRAAPLE中的运作方式是从一般到具体—从不精确到精确。他开始于 一个对领域的概念理解，然后是系统的高层功能，接着继续深入每个用 例、细化模型，最后设计、开发、部署系统。应当注意，在分析和设计 段中的动作比开发段多，也就是强调对系统的分析和设计，基本思想是 尽可能多地花时间在前端的分析和设计上，为的是使编码平稳进行。 GRAPPLE只是一个简单的开发过程骨架，有些重要问题的细节并未涉 及，例如，测试层次、中间产品的存放、如何处理配置管理问题，没有 讨论这些是因为它与UML不直接相关。 关于工作产品的存放：工作产品(已经完成或正在进行中的)可以被存放 位于组织局域网的一个数据仓库中，一种可选的方案是安装一个集中控 制的数据仓库软件包来控制各个用户对每个工作产品的写入和读出，着 也是配置管理问题的基本解决方案