业务模型；UML类图；数据模型；概念模型；面向对象模型

因为欣赏所以转载，原文地址 http://blog.csdn.net/sunleap/article/details/4976993

开发的流程有以下几步：

               对象图

• 组织视图：组织结构的静态模型。包括：层次组织结构的人员(people not human)资源，生产资源(比如，设备，运输等)以及计算机、通信网络结构等。 
• 数据视图：业务信息的静态模型。包括：数据模型，知识结构，信息载体，技术术语和数据库模型等。 
• 功能视图：业务流程任务的静态模型。包括：功能层次，业务对象，支持系统和应用软件等。 
• 控制（业务）视图：动态模型，展示流程运转情况，并能够将业务流程与流程相关的资源、数据以及功能等联系起来。包括：事件驱动过程链、信息流、物流、通信图、产品定义、价值增值图等。
业务模型的画法可以用任何编辑工具如Visio、word完成，当然目前PowerDesigner、Erwin等专业工具也支持业务模型。
数据模型是对企业或信息系统种的数据特征的抽象，随着数据库技术的大量使用，主要指数据库模型。
　　数据模型所描述的内容包括三个部分：数据结构、作用于数据上的操作、数据约束。
　　1）数据结构:数据模型中的数据结构主要描述数据的类型、内容、性质以及数据间的联系等。数据结构是数据模型的基础，数据操作和约束都建立在数据结构上。不同的数据结构具有不同的操作和约束。
　　2）数据操作:数据模型中数据操作主要描述在相应的数据结构上的操作类型和操作方式。
　　3）数据约束：数据模型中的数据约束主要描述数据结构内数据间的语法、词义联系、他们之间的制约和依存关系，以及数据动态变化的规则，以保证数据的正确、有效和相容。
　　数据模型按不同的应用层次分成三种类型：分别是概念数据模型、逻辑数据模型、物理数据模型。
　　1）概念数据模型（Conceptual Data Model）：简称概念模型，主要用来描述世界的概念化结构，与具体的数据库系统无关。概念数据模型必须换成逻辑或物理数据模型，才能在数据库系统中实现。概念数据模型中最常用的是E-R模型。
　　2）逻辑数据模型（Logical Data Model）：简称数据模型，这是从数据库所看到的模型，是具体的数据库管理系统所支持的数据模型，如网状数据模型(Network Data Model)、层次数据模型(Hierarchical Data Model)等等。此模型既要面向用户，又要面向系统。
　　3）物理数据模型（Physical Data Model）：简称物理模型，是面向计算机物理表示的模型，描述了数据在储存介质上的组织结构。物理数据模型的设计要考虑数据管理的性能问题，它不但与具体的数据库系统有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有起对应的物理数据模型。
可以利用PowerDesigner、Erwin、Oracle Data builder、Infosphere Data Architect、Rose等建模工具建立数据模型。
这个应该是软件开发者喜欢的模型，使用面向对象分析（OOA）和面向对象设计（OOD）过程中所建立模型，包括类图、对象图、状态图以及与之相关的活动图、顺序图、组件图等，可以利用UML建模工具，如Rose、Infosphere DataArchitect等工具以及软件
集成开发工具（Eclipse、Netbeans）建立面向对象模型。当然有些数据建模工具也支持面向对象模型。
数据挖掘模型的概念虽然重要，但没有比较权威的解释，我说一下自己的理解，使用数据挖掘算法建立的，描述数据之间的关系模型就叫数据挖掘模型。
数据挖掘模型的表现形式多种多样，跟数据挖掘算法有关，也跟我们要进行的后续操作有关。比如表现学生身高体重关系的函数（可以是直线、曲线、二次函数、多项式函数）是一个数据挖掘模型；表现超市商品关联关系的关联规则集合也是一个数据挖掘模型；表现银行客户分类情况的决策树也是一个数据挖掘模型。
 

各个阶段的UML图

（1）需求阶段是：用例图

（2）分析阶段是：类图、序列图

（3）设计阶段：类图、序列图与平台结合

业务建模工作步骤：

（1）选定业务单元

（2）识别业务执行者

（3）识别业务用例

（4）详述业务用例

（5）建立业务对象模型

    类图(Class Diagram)应该是使用的最多的一种UML图。其语法并不复杂，可能只需要几天时间就能掌握，但是其背后的面向对象(OO)思想却是需要日积月累才能深刻理解。

 

1、OOA(Object-Oriented Analysis 面向对象分析)

2、OOD(Object-Oriented Design 面向对象设计)

3、OOP(Object-Oriented Programming 面向对象编程)

4、OOT(Object-Oriented Technology 面向对象技术)

 

PS：无论是开发人员还是分析人员，这几种思想是必须要掌握的，作为开发人员来说，OO的思想，其深度和延伸内容可谓博大精深，值得花时间去学习。

 

    类可以视作一现实事物抽象出的统一的、相似的模型。

 

    对象可以看做是类的具体化，就像模具导出的产品一样。

 

    类图就是描述类与类之间关系的图。

案例：

1、识别出类。

2、识别出类的主要属性。

3、画出类之间的关系。

4、对各类进行分析、抽象、整理。

    两个类之间有关系，但又不确定是什么关系，可以用关联关系表达。

PS：关联关系如果出现数量上的对应可以写上数字表示数量，可以用角色关系表示两类分别处于什么角色，单向关联关系表示关联是单向的，只能由关联方找到被关联方。在写代码时，可以将其视作关联类包含了被关联类的一个引用。

    包含关系表示一个类包含另一个类。

PS：包含关系分为两种，一种是弱包含关系，叫做聚合，为空心菱形，一种是强包含关系，叫做组合，为实心菱形。一开始可以将所有包含关系视作弱包含，当发现某些关系可以用强包含表示时，才转为强包含关系。

    当一个类是另一个类的子类时，可以使用泛化关系。

PS：泛化关系通常也被称作继承关系，根据类的发现先后关系，如果是由父类导出子类，这样就可以说子类继承父类，如果是由子类导出父类，这样就可以说父类泛化子类。

 

    当一个类可以实现某个抽象类时，可以使用实现关系。

PS：标识接口与类之间的关系用的比较多。

 

    当一个类需要另一个类协助时，可以用依赖关系表示。

    当某类使用或者包含自己时，可以使用递归关系。

    当发现两个类之间的关系不能用一般关系来表示，这时候可以用关联类来表示关系，这也就是三角关系。

PS：可以通过思考属性是否恰当来识别出关联类关系，列出两类的关键属性之后，思考这些属性的属性值是不是由该类本身就可以确定，如果不能两类之间就可能有关联类关系。

 

    如果说类图代表了一类事物，那么对象图就代表着某个具体的事物。

现实世界被业务模型映射并且记录下来，但 这只是原始需求信息，距离可执行的代码还很遥远，必须把这些内容再换成一种可以指导开发的表达方式。UML 通过称之为概念化的过程（ Conceptual）来 建立适合计算机理解和实现的模型，这 个模型称为分析模型（ Analysis Model）。分析模型介于原始需求和计算机实现之间，是一种过渡模型。分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求；同时，分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。

事实上分析模型在整个分析设计过程中承担了很大的职责，起到了非常重要的作用。绘制分析模型最主要的元模型有：

边界类（boundary） 。边界是面向对象分析的一个非常重要的观点。从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。从广义上说，任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。只要是两个不同职责的簇之间的交互都需要有一个边界，换句话说，边界决定了外面能对里面做什么“事”。 在后续的章节中，读者会感受到边界的重要性，边界能够决定整个分析设计的结果。

实体类（entity） 。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML 采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。

控制类（control） 。边界和实体都是静态的，本身并不会动作。UML 采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML 的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。考虑一下，实际上在现实世界中，动作和物体也是分开描述的。

读者或许在小时候都玩过一个游戏，每个同学发四张小纸条，在第一张纸条上写上XXX 的名字，在 第二张纸条上写上在什么地方，在 第三张纸条上写上一个动作，在 第四张纸条上写一个物体，然后将这些字条分开放在四个箱子里，再随意地从这四个箱子里各取一张纸条，就能组成很多非常搞笑的句子，例如张XX 在公园里跳圆规之类的奇怪语句，一个班的同学常常笑得前仰后合。

游戏虽然是游戏，但说明了一个道理，只要有人、事、物和规则（定语），就能构成一个有意义的结果，无非是是否合理而已。分析类也是应用这个道理来把业务模型概念化的。由于所有的操作都通过边界类来进行，能做什么不能做什么由边界决定，所以边界类实际上代表了原始需求中的“事”； 实体类则由业务模型中的领域模型转化而来，它代表了现实世界中的“物”； 控制类则体现了现实世界中的“ 规则”， 也 就是定语；再 加上由参与者转化而来的系统的“ 用户”， 这 样一来，“ 人”也有了。有了人、事、物、规则，我们就可以像那个游戏一样把它们组合成各种各样的语句，只不过不是为了搞笑，所以不能随意组合，而是要依据业务模型中已经描绘出来的用例场景来组合这些元素，让它们表达特定的业务含义。

（1）业务模型：也称企业模型，它为企业提供一个框架结构，以确保企业的应用系统与企业经常改进的业务流程紧密匹配。可以说，也就是说业务建模主要是从业务的角度而非技术角度对企业进行建模。典型的建模方法包括Zachman框架、ARIS HOUSE模型等，业务模型一般包括下面一些视图：

（2）数据模型

（3）面向对象模型

（4）数据挖掘模型