《信息系统分析与设计》第10章：面向对象分析与设计

2,第10章 面向对象分析与设计,【学习目标】 通过本章学习，你将能够： 理解面向对象方法的基本概念 定义UML及其各种模型图 开发用例图、顺序图 探讨对象和类以及它们之间的关系 开发设计类图 理解建立模型应遵循的原则,3,10.1 引 言,在这一章，我们将介绍一种完全不同的系统开发方法面向对象的系统分析与设计方法。与传统开发方法不同的是，面向对象方法的分析与设计两阶段工作的界限并不明显，系统设计阶段要做的大多数工作是对分析阶段的成果进行改进和扩展。 在设计阶段，需要修改和精炼面向应用的分析模型，以适合目标实现环境。然后进入实现阶段，用编程语言和数据库管理系统实现设计。众多面向对象的技术和表示方法结合成了一种标准的面向对象语言，称为统一建模语言(Unified Modeling Language，UML)。,4,10.2 UML,UML(统一建模语言)是一种为面向对象开发系统的产品进行说明、可视化和编制文档的一种标准语言，是非专利的第三代建模和规约语言。UML使用面向对象设计的观念，但是独立于任何具体的程序设计语言。它作为一种模型语言，能使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。因此，UML可以用来描述企业过程和需求。IBM的Rational Rose和微软的Visio都是UML工具。,5,10.2.1 UML的出现,公认的面向对象建模语言出现于20世纪70年代中期。 20世纪90年代中期，一批新方法出现了，其中最引人注目的是Booch 1993、OMT-2和OOSE等。 1991年，他将以前面向Ada的工作扩展到整个面向对象设计领域。Booch 1993比较适合于系统的设计和构造。 Ivar Jacobson于1994年提出了OOSE(面向对象软件工程)方法，其最大特点是面向用例(Use-Case)，并在用例的描述中引入了外部角色的概念。 1994年10月，Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch 1993和OMT-2 统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM 0.8(Unitied Method)。,6,10.2.1 UML的出现,1996年6月和10月分别发布了两个新的版本，即UML 0.9和UML 0.91，并将UM重新命名为UML。 1996年，一些机构将UML作为其商业策略已日趋明显。 在美国，截至1996年10月，UML获得了工业界、科技界和应用界的广泛支持，已有700多个公司表示支持采用UML作为建模语言。 1997年11月17日，OMG(对象管理组)采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值。,7,10.2.2 UML的内容,UML的重要内容可以由下列五类图来定义。 用例图 类图 行为图 交互图 实现图,8,10.2.3 基于UML的系统开发思路,从应用的角度看，当采用面向对象技术设计系统时，第一步是描述需求；第二步是根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。 标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。 在需求分析阶段，可以用用例来捕获用户需求。 在用UML建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。 UML模型也可作为测试阶段的依据。,9,10.3 用 例 分 析,10.3.1 用例、参与者及用例图 用例(Use Case)是一种描述系统需求的方法，是系统必须要进行的活动，使用用例的方法来描述系统需求的过程就是用例建模。 参与者(Actor)是指存在于被定义系统外部并与该系统发生交互的人或其他系统，它们代表的是系统的使用者或使用环境。 用例用一个标有名称的椭圆所代表，参与者与用例之间的连线表示了有哪些参与者参与哪种用例，如图10-1所示。,10,10.3.2 确定参与者,所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义的系统的使用者。 寻找参与者可以从以下问题入手。 系统开发完成之后，有哪些人会使用这个系统？ 系统需要从哪些人或其他系统中获得数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统相关联？ 系统是由谁来维护和管理的？,11,ATM也需要与后台服务器进行通信以获得有关用户账号的相关信息，如图10-3所示。 1. 系统边界决定了参与者 2. 特殊的参与者系统时钟,12,10.3.3 确定用例,寻找用例可以从以下问题入手(针对每一个参与者)。 参与者为什么要使用该系统？ 参与者是否在系统中创建、修改、删除、访问、存储数据？ 如果是的话，参与者又是如何来完成这些操作的？ 参与者是否将外部的某些事件通知给该系统？ 系统是否将内部的某些事件通知该参与者？,13,10.3.4 用例详细描述,一般来说，每一个用例的用例规约都应该包含以下内容。 简要说明：简要介绍该用例的作用和目的。 事件流：包括基本流和备选流，事件流应该表示出所有的场景。 用例场景：包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。 前置条件：执行用例之前系统必须所处的状态。 后置条件：用例执行完毕后系统可能处于的一组状态。,14,10.3.4 用例详细描述,1. 基本流 2. 备选流 3. 用例场景 4. 前置条件和后置条件,15,10.3.5 用活动图描述用例,活动图可以较灵活地表达现实的业务活动。活动图既可以用于分析阶段，也可以用于设计阶段。 活动图是一种描述工作流的方式，它用来描述采取何种动作、做什么(对象状态改变)、何时发生(动作序列)以及在何处发生(泳道)。活动图可以用作下述目的。 描述一个操作执行过程中所完成的工作(动作)，这是活动图最常见的用途。 描述对象内部的工作。 显示如何执行一组相关的动作以及这些动作如何影响它们周围的对象。 显示用例的实例是如何执行动作以及如何改变对象状态。 说明一次商务活动中的人(角色)工作流组织和对象是如何工作的。,16,10.3.6 检查用例模型,用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要从以下几个方面来进行检查。 1. 功能需求的完备性 2. 模型是否易于理解 3. 是否存在不一致性 4. 避免二义性语义,17,10.4 类 图 分 析,类图提供了对系统组成部分的定义。而在本章学到的其他图(如用例图和顺序图)的重点则集中于系统所完成的活动上。 类图由类和类之间的关系组成。在面向对象技术中，类是一个比较宽泛的概念。它可以表示程序设计中的一个类型，也可以表示现实世界中的一类事物或一个概念。在系统开发的不同阶段，类图的作用也不相同。在分析阶段，类图主要用于一些概念类的描述；在设计阶段，类图主要用于描述类的外部特性；在实现阶段，类图主要用于描述类的内部实现。,18,10.4.1 类,类是具有相同特性(属性)和相同行为(方法)的对象的集合。在UML中类使用一个矩形图符来表示，如图10-8所示。类的图符分为上、中、下三个部分，分别用来标识类的名称、属性和方法。,19,10.4.1 类,1. 名称 2. 属性 3. 方法 4. 消息 5. 对象,20,10.4.2 初步类图,UML有两个重心，其一是用例图，其二是类图。 在UML中，类有不同的种类，包括界面类、控制类和实体类。 图10-10是根据图7-13所示的E-R(实体-关系)图而画出的类图。,21,10.5 输入输出分析顺序图,顺序图(也称序列图)是一种交互图(Interaction Diagram)用于描述执行系统功能的各个角色之间相互传递消息的顺序关系，显示跨越多个对象的系统控制流程，强调的是时间和消息的次序，用来说明系统的动态情况。顺序图由参与者、对象、对象生命线和消息组成。一个顺序图显示了一系列的对象(通常是类的实例，也可以代表其他事物的实例，例如协作、组件和节点)和在这些对象之间发送和接收的消息。,22,10.5.1 顺序图的符号,我们首先给出图10-11所示的顺序图片段。,23,10.5.1 顺序图的符号,图10-11中所使用的符号如下所述。 参与者 系统 生命线 活动条 输入消息 输出消息 注释 另外，顺序图还有一些其他的符号。,24,10.5.2 开发顺序图,顺序图一般用于确认和丰富一个用例场景的逻辑。 一般来说，我们可以遵循以下思路来开发顺序图。 (1) 确定你要描述用例的哪个场景。 (2) 绘制一个矩形表示一个整体的系统，并在其下面延伸生命线。 (3) 确定和系统直接交互的角色，并在角色下延伸生命线。 (4) 检查用例场景，找出系统的输入和输出。 (5) 添加框架以表示一些判断或循环结构。 (6) 自顶向下验证消息是否按照正确顺序显示。,25,10.6 设 计 类 图,设计阶段的主要工作就是对分析阶段的分析成果进一步细化的过程。在一个单纯面向对象环境中，每一段代码都存在于某个对象内部所有的用户界面、所有的程序逻辑，等等。应用程序通过让类发送消息并从其他类接收消息而工作。那么。设计阶段就需要进一步说明系统的对象和消息。,26,10.6.1 基本的概念,1. 设计类符号 2. 封装和信息隐藏 3. 导航的可见性 4. 内聚与耦合,27,10.6.2 开发设计类图的初步,1. 确定属性和初步的导航可见性 2. 确定基本的对象职责和对应的方法,28,10.6.3 用交互图来完善类图,在用交互图来完善类图时有两种选择： 顺序图或协作图。 1. 控制器的使用 2. 分层细化顺序图 3. 对设计类图的细化和更新,29,10.6.4 用状态图来描述对象的生命周期,状态图主要用来描述一个对象的生命周期。它描述了对象具有不同的状态，引起对象状态改变的事件，以及决定对象在状态间转换的规则。 通常遵循以下步骤来创建对象的状态图。 确定初始状态和最终状态。(对象如何创建和销毁？) 确定对象在生命周期中可能具有的各种状态。 确定引起对象离开某个特定状态的触发器(事件)。 确定状态转换路径。(当对象状态改变时，对象将进入的下一个状态是什么？),30,10.6.4 用状态图来描述对象的生命周期,图10-25是order对象的简化状态图。它从一个初始状态(实心圆)开始，在不同状态(圆角矩形)之间转换，最后进入结束状态(内部空心的实心圆)。每个箭头上的方法是触发order对象从一个状态转换到另一个状态的事件。,31,10.7 使用包图来组织系统元素,UML包图提供了组织元素的方式。包图是一个高层次的图，可以形象地理解为将相关部分打包并标识包之间的关系。 如果包内部显示了其成员，则在标签上标识包名；否则，可以在包体内标识包名称。 如图10-26所示，可视层和域层都依赖于数据访问层。,32,10.8 小 结,在每个迭代中，仍然是遵循传统的分析设计实施的步骤。 统一建模语言(UML)是一种标准的面向对象语言，它利用一些标准的表达工具来表述设计思想。这些工具包括：类图、用例图、交互图、活动图和状态图、包图等。其中的类图描述了系统的静态结构；用例图