对象建模方法与技术学习笔记（一）

1 面向对象

1.1 为什么要面向对象

面向对象的思想认为，在需求中人和物是相对稳定的，他们是事物的本质；而需求中的功能和行为是以人和物为主体的特征；人和物是相对稳定的，而功能和行为是易变的。因此，反映需求分析与软件框架设计的模型应该围绕需求中的人和物，而不是变化多端的功能，后者是需求实现的细节设计应该考虑的问题。建模是一种抽象思维，模型中的成分是实物的真实写照。这种实物映射方式将会给程序设计带来许多好处，同时也是传统的功能映射所缺乏的。

首先，它使得程序与需求更为接近，便于理解，便于进行程序维护。如果采用功能映射，随着功能的合并、分解以及相互交错，在维护过程中很难找到与实际工作对应的关系。

其次，虽然功能发生变化，但人和物没有变，变化的只是他们的特征。抓住了事物的本质就可以做到“万变不离其宗”。

再者，以人和物为对象进行建模，可以构造抽象和具体的继承结构。

1.2 面向对象方法与传统软件方法之间的区别

从上面的讨论可以看出，面向对象方法与传统的程序设计方法有很大的区别。传统的程序主要是面向功能，在概念上很难找到与需求中实际事物（尤其是实物）相对应的关系。实际上，传统的程序设计方法并不关心程序与实物的相对应，人们追求的是功能，即一切从功能出发，从而形成了程序与功能的映射关系。这点并不难理解，可以说是事物发展的必然过程。因此，计算机程序起初就是为了应付科学计算，需求就是计算功能的要求。从中很难找到事物的对应踪迹。而今天的计算机程序大多数是面向信息处理，其需求往往与日常工作和生活紧密联系。功能固然很重要，但功能是随着实际需要不断变化的，功能映射方式是极不稳定的方式，它随着需求的变化固然要发生变化。

面向对象的程序设计则是从功能映射到实物映射的思维方式的转变，然而，由于两种方式的差距很大，要想转变，并不容易。对于许多面向对象的设计，乍看起来，结构挺复杂。但仔细看不难发现，几乎每个对象都与现实生活中的事物项吻合，而且对象之间的关系也和我们的思维逻辑一致。

2 软件建模的基本理念

2.1 什么是模型

• 模型是对客观世界事物的一种抽象和简化。
• 它是从某个角度反映人对客观世界事物的一种认识。
• 它用于对事物的本质进行深入细致的研究。

2.2 常见的软件模型

• 业务模型：对业务过程、工作流、组织的建模
• 需求模型：对捕获的需求进行整理和分析的工具，辅助开发人员与用户进行沟通
• 设计模型：包含高层设计（架构模型）和详细设计模型，用于统一开发人员、沟通设计信息
• 实现模型：用来清理软件的组成、部署方案，为安装与维护人员的工作提供指导
• 数据库模型：设计数据库的结构、表结构以及与应用系统的交互

2.3 软件建模的目的与原则

• 帮助我们按照实际情况或按我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对我们所做出的决策进行文档化
• 仅当需要模型时，才构建它
• 选择要创建什么模型对如何动手解决问题和如何形成解决方案有着意义深远的影响；每一种模型可以在不同的精度级别上表示；最好的模型是与现实相联系的；单个模型是不充分的，对每个重要的系统最好用一组几乎独立的模型去处理

2.4 谁负责建立软件模型

• 业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与
• 需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与
• 设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导
• 实现模型：以资深开发人员（设计人员）为主，架构师提供总体指导
• 数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）予以配合

2.5 什么是UML

统一建模语言（UML）是一种面向对象的概念建模语言，它不仅仅是一种图形化标记方法，同时也有语法和语义，是当前国际公认的面向对象建模标准。

UML主要用于：

• 软件设计
• 沟通软件或业务过程
• 捕捉系统需求分析的细节
• 描述现有的系统、过程和组织机构

2.6 UML的三位缔造者

• Booch Method by Grady Booch
  
  • Booch是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概念
  • 最先使用类图，类分类图，类模板和对象图来描述OOD的人
  • 他是Rational公司的首席科学家，对象建模工具Rational Rose的创始人
• Object Modeling Technique （OMT） by James Rumbaugh
  
  • OMT采用了面向对象的概念，并引入各种独立于语言的表示符
  • OMT是上世纪九十年代最有代表性的学院派OO方法
  • 使用3种模型来描述一个系统：对象模型，描述系统中对象的静态结构；动态模型，描述系统状态随时间变化的情况；功能模型，描述系统中各个数据值的转变。对象图，状态转换图和数据流图分别被用于描述这3个模型
• Objectory by Ivar Jacobson
  
  • 提出了一种非常实用的面向对象软件工程方法（OOSE），即基于用例（UseCase）的需求开发法

3 Rose技术

Rational ROSE是进行软件系统面向对象分析和设计强大的可视化工具，可以用来先建模系统再编写代码，从而一开始就保证系统结构的合理。同时，利用模型可以更方便地捕获设计缺陷，从而以较低的成本修正这些缺陷。所谓建模就是人类对客观世界和抽象事物之间联系的具体描述。

ROSE模型是用图形符号对系统的需求和设计进行形式化描述。描述语言是统一建模语言（UML），它包括各种UML框图（Diagram）、角色、用例、对象、类、组件和部署节点，用于详细描述系统的内容和工作方法，开发人员可以用模型作为所建系统的蓝图。

3.1 类图

类图包含了一组类、接口和协作以及它们之间的关系。它提供了系统组件及其相互关系的静态图形。类图是其他一些相关图的基础。类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型，同样重要的是通过正向和逆向工程建立执行系统。

类图的相关知识见：http://blog.csdn.net/louislee92/article/details/45102629

3.2 用例图

用例图是用例（User Case）分析手段和工具。用例分析（也称用例法）是捕获应用需求的有效手段，也是UML中进行功能需求分析的主要方法。它用角色和用例定义所建系统的功能需求和范围。

用例图相关知识见：http://blog.csdn.net/louislee92/article/details/45932499

3.3 活动框图

用例中的情景描述除了用文本形式来表示外，还经常用活动框图来表示。为什么有了文本形式以后还要开发这种框图形式呢？这是因为利用文本形式虽然很有用，但是如果事件流逻辑复杂，则文本形式比较难阅读和理解，利用框图将比文本形式来得更加有效。

3.4 时序图

时序图（Sequence Diagram）是交互图的一种，交互图主要是用来建模系统对象之间的交互。还有一种交互图是协作图（Collaboration Diagram）。这两种交互图都可以用来显示参与用例流程的对象和对象之间发送的消息。他们都是情景描述的一种手段，区别在于组织的方式不同，时序图按照时间来排序，而协作图按对象本身来组织。交互图显示用例一步一步的流程。包括流中需要什么对象；对象之间如何发生消息；什么角色启动流；消息按什么顺序发送。也就是说交互图包含了事件流中的许多相同细节，但交互图把这些消息表示成对开发人员更有用的方式。

3.5 协作图

与时序图一样，协作图也用来表示用例中特定情形的流程。不同的是时序图按时间排序，而协作图则着重于对象之间的关系。

3.6 状态图

状态图包括了对象存在的不同状态信息、对象如何从一个状态过渡到另一种状态，以及对象在不同状态中的不同行为。

状态图显示了一个对象从创建到删除的生命周期。这些框图可以建模类的动态行为。在一般项目中，不对每个类都创建状态框图。事实上，很多项目根本不用状态框图。

3.7 包图、组件与部署视图

包图、组件与部署视图相关知识见：http://blog.csdn.net/louislee92/article/details/45250603

下篇接：《对象建模方法与技术学习笔记（二）》