管 理 信 息 系 统 （ Management Information System ）

1. 管 理 信 息 系 统（Management Information System） 同济大学 经济与管理学院 《管理信息系统》精品课程课程组 网站：http://MIS.jpkc.tongji.edu.cn 时间：2006年3月

2. 第18章 面向对象的系统开发方法

3. 学习目的 • 了解面向对象的思想，掌握面向对象的基本概念 • 掌握面向对象方法的基本特征，即抽象性、封装性、继承性和多态性 • 掌握面向对象的系统开发方法的基本原理和步骤 • 了解UML的使用方法

4. 本讲内容 • 18.1 面向对象方法的形成 • 18.2 面向对象方法的基本概念 • 18.3 面向对象方法的基本特征 • 18.4 面向对象的系统开发方法 • 18.5 基于UML的系统分析与设计

5. 18.1面向对象方法的形成 • OO方法起源于OOPL。20世纪80年代大批OOPL的出现和效率的不断提高，标志着OO方法开始走向实用。但是，正如Marciniak在《软件工程百科全书》中所言：“编程并不是软件开发的主要根源。需求分析与设计问题更为普遍并且更值得解决。因此，OO方法的焦点不应该只对准编程，而应更全面地对准软件工程的其它阶段。OO方法的真正目标是它适合于解决分析与设计期间的复杂性并实现分析与设计的复用。”基于这一事实，人们对OO方法的研究重点，从面向对象的编程（Object-oriented Programming，OOP），转移到面向对象的分析（Object-oriented Analysis，OOA）和面向对象的设计（Object-oriented Design，OOD）。 • 自20世纪80年代以来，出现了一大批有代表性的OO方法，如Coad-Yourdon方法、Booch方法、Rumbaugh方法（OMT方法）和Jacobson方法（OOSE方法）。概括地说，OO方法的基本思想是，从现实世界的客观事物（即对象）出发来构造信息系统，并在系统构造中尽可能运用人类的自然思维方式。

6. 本讲内容 • 18.1 面向对象方法的形成 • 18.2 面向对象方法的基本概念 • 18.3 面向对象方法的基本特征 • 18.4 面向对象的系统开发方法 • 18.5 基于UML的系统分析与设计

7. 18.2面向对象方法的基本概念 • 18.2.1 对象与类的概念 • 对象（Object）的概念 • 在OO方法中，“对象”是一组属性和施加在这些属性上的一组操作构成的独立个体，可以用“对象=属性+作用于这些属性上的操作”这一公式来表达。对象是一个封闭体，它向外界提供一组接口界面，外界通过这些接口与对象进行交互，这样对象就具有较强的独立性、自治性和模块性，从而为软件的重用奠定了坚实的基础。 • 类（Class）的概念 • 在OO方法中，类的定义是：具有相同属性和操作的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其内部包括属性和操作两个主要部分。 • 类是对象的模版（Template），模板可以想象为浇铸毛坯用的模具，模具是固定的，当注入钢水，便出现一个具有模具形状的毛坯。在系统运行时，类作为模板可以建立若干个对象，而每个对象都是这个类的一个具体实例（Instance）。

8. 18.2面向对象方法的基本概念 • 18.2.2消息的概念 • 消息（Message）是指为了实现某一功能而要求某个对象执行其中某个功能操作的规格说明。 • 消息一般含有下述信息： • ①提供服务的对象标识； • ②服务标识； • ③输入信息； • ④响应信息。 • 对象接收消息，根据消息及消息参数调用自己的服务，处理并予以响应，从而实现系统功能。

9. 18.2面向对象方法的基本概念 • 18.2.3面向对象与面向过程 • 面向过程的方法把相互依赖的数据和对数据的操作相互分离，这种实质上的依赖与形式上的分离，使得大型系统难于编写、调试。在多人合作中，程序员之间很难读懂对方的代码，更谈不上代码的重用。 • OOP技术是一种以对象为基础，以事件或消息来驱动对象执行处理的程序设计技术。它以数据为中心而不是以功能为中心来描述系统，数据相对于功能而言具有更强的稳定性。它将数据和对数据的操作封装在一起，作为一个整体来处理，采用数据抽象和信息隐蔽技术，将这个整体抽象成一种新的数据类型 —— 类，并且考虑不同类之间的联系和类的重用性。另一方面，面向对象的系统中的一切操作都是通过向对象发送消息来实现的，对象接到消息后，启动消息处理函数完成相应的操作。因此，面向对象系统的控制流程是由运行时各种事件的实际发生来触发，而不再由预定顺序来决定，更符合实际。

10. 本讲内容 • 18.1 面向对象方法的形成 • 18.2 面向对象方法的基本概念 • 18.3 面向对象方法的基本特征 • 18.4 面向对象的系统开发方法 • 18.5 基于UML的系统分析与设计

11. 18.3 面向对象方法的基本特征 • 18.3.1 抽象性（Abstraction） • 18.3.2 封装性（Encapsulation） • 18.3.3 继承性（Inheritance） • 18.3.4 多态性（Polymorphism）

12. 本讲内容 • 18.1 面向对象方法的形成 • 18.2 面向对象方法的基本概念 • 18.3 面向对象方法的基本特征 • 18.4 面向对象的系统开发方法 • 18.5 基于UML的系统分析与设计

13. 18.4 面向对象的系统开发方法 • 18.4.1 面向对象的系统分析 • 问题域分析 • 问题域（Problem Domain）是指被开发的应用系统所考虑的整个业务范围。 • 问题域分析过程是抽取和整理用户需求并建立问题域精确模型的过程。主要任务是充分理解专业领域的业务问题和投资者及用户的需求，提出高层次的问题解决方案。 • 应用分析 • 获取用户基本需求 • 识别类（对象） • 标识对象的属性 • 识别对象的行为 • 识别对象之间的关系 • 定义主题词

14. 18.4 面向对象的系统开发方法 • 18.4.2 面向对象的系统设计

15. 18.4 面向对象的系统开发方法 • 18.4.2 面向对象的系统设计 • 主体部件是整个设计的主体，它包括完成目标系统主要功能的所有对象； • 用户界面部件给出实现人机交互需要的对象； • 任务管理部件提供协调和管理目标系统各个任务的对象； • 数据管理部件定义专用对象，将目标系统中依赖于开发平台的数据存取操作与其他功能分开，以提高对象独立性。

16. 18.4 面向对象的系统开发方法 • 18.4.3 面向对象的系统实施 • 这一阶段主要是将OOD中得到的模型利用程序设计实现。具体操作包括：选择程序设计语言编程、调试、试运行等。OOA与OOD两阶段得到的对象及其关系最终必须由程序语言、数据库等技术实现，但由于在OOD阶段对此有所侧重考虑，故系统实现不会受具体语言的制约，因而本阶段占整个开发周期的比重较小。 • 程序设计语言有多种类型：有过程型语言，如C、Pascal、FORTRAN、COBOL；有基于对象的语言，如Ada；还有面向对象的语言，如C++、Smalltalk、Actor、Objective-C、Eiffel。一般地，所有类型的语言都可以完成面向对象实现，但某些语言能够提供更丰富的语法，能够显式地描绘在OOA和OOD过程中所使用的表示法，直接支持过程抽象、数据抽象、封装、继承、以及对象与属性、类与成员关系。一般建议应尽可能采用面向对象的程序设计语言，一方面由于面向对象技术日趋成熟，支持这种技术的语言已成为程序设计语言的主流；另一方面，选用面向对象语言能够更容易、安全和有效地利用面向对象机制，更好地实现OOD阶段所选的模型。

17. 本讲内容 • 18.1 面向对象方法的形成 • 18.2 面向对象方法的基本概念 • 18.3 面向对象方法的基本特征 • 18.4 面向对象的系统开发方法 • 18.5 基于UML的系统分析与设计

18. 18.5 基于UML的系统分析与设计 • 18.5.1 UML视图

19. 18.5 基于UML的系统分析与设计 • 18.5.2 静态视图 • 静态视图对应用领域中的概念以及与系统实现有关的内部概念建模。这种视图之所以被称之为是静态的是因为它不描述与时间有关的系统行为，此种行为在其他视图中进行描述。 • 静态视图主要是由类及类间相互关系构成，这些相互关系包括：关联、泛化和各种依赖关系（如使用和实现关系）。一个类是应用领域或应用解决方案中概念的描述。 • 类图（Class Diagram）是以类为中心来组织的，类图中的其他元素或属于某个类或与类相关联。静态视图用类图来实现，正因为它以类为中心，所以称其为类图。

20. 18.5 基于UML的系统分析与设计 • 18.5.2 静态视图

21. 18.5 基于UML的系统分析与设计 • 18.5.2 静态视图

22. 18.5 基于UML的系统分析与设计 • 18.5.3 用例视图 • 用例图描述系统的功能。显示若干角色以及这些角色和系统提供的用例之间的连接关系。用例是系统对外提供的功能的描述，是角色和系统在一次交互过程中执行的相关事务的序列。 • 用例视图是外部用户（又称为参与者）所能观察到的系统功能的模型图。在UML中，用例图（Use Case Diagram）是用例视图的重要组成部分，由系统、用例和参与者（Actor）三种元素组成，其中，参与者是指与系统、子系统或类交互的外部人员、进程或事物。用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。用例图的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。

23. 18.5 基于UML的系统分析与设计 • 18.5.3 用例视图

24. 18.5 基于UML的系统分析与设计 • 18.5.3 用例视图

25. 18.5 基于UML的系统分析与设计 • 18.5.4 交互视图 • 交互视图描述了执行系统功能的各个角色之间相互传递消息的顺序关系。交互视图显示了跨越多个对象的系统控制流程。 • 交互视图可用两种图来表示, 它们各有不同的侧重点。 • 顺序图 • 协作图

26. 18.5 基于UML的系统分析与设计 • 18.5.4 交互视图 • 顺序图 • 序列图反映若干个对象之间的动态协作关系，即随着时间的流逝，消息是如何在对象之间发送和接收的。序列图表现为二维的形式，其中的纵坐标轴显示时间，横坐标轴显示对象。序列图中重点反映对象之间发送消息的先后次序。 • 在顺序图中，横坐标轴为参与交互的对象，每一个对象下面都有一条线，称作“生命线”。当对象存在时，生命线用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

27. 18.5 基于UML的系统分析与设计 • 18.5.4 交互视图 • 顺序图

28. 18.5 基于UML的系统分析与设计 • 18.5.4 交互视图 • 协作图 • 协作图（Collaboration Diagram）主要描述协作对象之间的交互和链接。协作图和顺序图都表示出了对象间的交互作用，但是它们侧重点不同。顺序图清楚地表示了交互作用中的时间顺序，但没有明确表示对象间的关系。协作图清楚地表示了对象间的关系，但时间顺序必须从顺序号获得。顺序图通常用于表示方案，而协作图用于过程的详细设计。

29. 18.5 基于UML的系统分析与设计 • 18.5.4 交互视图 • 协作图

30. 18.5 基于UML的系统分析与设计 • 18.5.5 状态机视图 • 状态机视图是一个对象可能经历的所有历程的模型图。状态机由对象的各个状态和连接这些状态的转换组成。每个状态对一个对象在其生命期中满足某种条件的一个时间段建模。当一个事件发生时，它会触发状态间的转换，导致对象从一种状态转化到另一新的状态。与转换相关的活动执行时，转换也同时发生。状态机视图采用状态图来表达。 • 状态图（Statechart Diagram）由状态、转换、事件和动作组成。通过状态图可以了解一个对象可能具有的所有状态、导致对象状态改变的事件、以及状态转移引发的动作。状态是对象操作的前一次活动的结果，通常由对象的属性值来决定。事件指的是发生的且引起某些动作执行的事情。状态的变化称作转移，与转移相连的动作指明状态转移时应该做的事情。

31. 18.5 基于UML的系统分析与设计 • 18.5.5 状态机视图

32. 18.5 基于UML的系统分析与设计 • 18.5.6 活动视图 • 活动图是状态机的一个变体，用来描述执行算法的工作流程中涉及的活动。活动状态代表了一个活动：一个工作流步骤或一个操作的执行。活动图描述了一组顺序的或并发的活动。活动视图用活动图来体现。活动图（Activity Diagram）显示了系统中从一个活动到另一个活动的流程，描述了一组顺序的或并发的活动，这与传统的流程图有序列或分支非常类似。活动图强调的是对象之间的流程控制。

33. 18.5 基于UML的系统分析与设计 • 18.5.6 活动视图

34. 18.5 基于UML的系统分析与设计 • 18.5.7 物理视图 • 物理视图就是对应用自身的实现结构建模，例如系统的构件组织和建立在运行节点上的配置。这类视图提供了将系统中的类映射成物理构件和节点的机制。 • 物理视图有两种：实现视图和部署视图。

35. 18.5 基于UML的系统分析与设计 • 18.5.7 物理视图 • 实现视图 • 实现视图为系统的构件建立模型（构件即构造应用的软件单元），还包括各构件之间的依赖关系，以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响。 • 实现视图用构件图（Component Diagram）来表现。构件图用来反映代码的物理结构。构件可以是源代码、二进制文件或可执行文件，包含逻辑类的实现信息。

36. 18.5 基于UML的系统分析与设计 • 18.5.7 物理视图 • 实现视图

37. 18.5 基于UML的系统分析与设计 • 18.5.7 物理视图 • 部署视图 • 部署视图描述位于节点实例上的运行构件实例的安排。节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配。部署视图采用部署图来表达。 • 部署图（Deployment Diagram）用来显示系统软硬件的物理体系结构，包含处理器、设备、进程和处理器之间的连接。一般，每个系统只有一个配置图。部署图中通常显示实际的计算机和设备及它们之间的关系。

38. 18.5 基于UML的系统分析与设计 • 18.5.7 物理视图 • 部署视图

39. 18.5 基于UML的系统分析与设计 • 18.5.8 模型管理视图 • 模型管理视图是对模型自身组织的建模，通过包图（Package Diagram）来表现。包图一般由类和包组成。它是一种拆分系统的方法，将模型分解成包的结构组件，以便于软件小组将大的系统分解成易于处理的块结构，并理解和控制各个包之间的依赖关系，在复杂的开发环境中管理模块单元。子系统是另一种特殊的包。它代表了系统的一个部分，它有清晰的接口，这个接口可作为一个单独的构件来实现。 • 随着对问题域的理解的深化，概念模型将愈加复杂，并可能达到无法控制的程度。此时可使用包将模型划分为较小的、更易管理的子集。可将整个系统设想为一个大包，其中包含所有其他包、图表和元素。在整个开发过程中都可以使用包对相关元素进行分组。

40. 18.5 基于UML的系统分析与设计 • 18.5.8 模型管理视图 • 包图（Package Diagram）

41. 18.5 基于UML的系统分析与设计 • 18.5.9 扩展组件 • 为了使建模人员根据需要对基本建模语言进行一定的扩展，UML提供了约束（Constrains）、构造型（Stereotype）和标记值等扩展机制。 • 约束是用某种形式化语言或自然语言表达的语义关系的文字说明。构造型是指在已有的模型元素基础上建立一种新的模型元素。构造型比现有元素多一些特别的语义，其使用场所和产生构造型的原始元素相同。构造型的存在避免了UML语言过于复杂化，同时也使UML能够适应各种需求。标记值是附加到任何模型元素上的命名的信息块。

42. 今天你提高了吗?