一、 不同的分析与设计方法
1.功能分解法（function decomposition）
以系统需要提供的功能为中心来组织系统。
首先定义各种功能，然后把功能分解为子功能，对较大的子功能进一步分解，直到可给出明确的定义
设计功能/子功能所需要的数据结构
定义功能/子功能之间的接口。
（作为一种早期的建模方法，没有明确地区分分析与设计）
建模过程：层层进行功能分解
功能分解法得到的系统模型（由模块及其接口构成）
优点与缺点：
直接地反映用户的需求，所以工作很容易开始；
不能直接地映射问题域，很难检验结果的正确性；
对需求变化的适应能力很差；
局部的错误和修改很容易产生全局性的影响。
2.结构化方法：
结构化分析（structured analysis，SA）
结构化设计（structured design。SD）
结构化分析又称数据流法，其基本策略是跟踪数据流，即研究问题域中数据如何流动，以及在各个环节上进行何种处理，从而发现数据流和加工。得到的分析模型是数据流图（DFD），主要模型元素是数据流、加工、文件及端点，外加处理说明和数据字典。
数据流图
结构化设计与功能分解法基本相同，基于模块的概念建立设计模型，分为概要设计和详细设计。
概要设计：确定系统中包含哪些模块以及模块之间的调用关系，得到模块结构图（MSD）。
详细设计：描述每个模块内部的数据结构和操作流程。
结构化方法的优缺点：
优点：
强调研究问题域，并且有严格的法则。
缺点：
仍然是间接映射问题域；分析与设计的概念不一致，从分析到设计的过渡比较困难；数据流和加工的数量太多，引起分析文档的膨胀。
3.信息建模法（information modeling）
由实体-关系法（E-R方法）发展而来。
核心概念是实体和关系。实体描述问题域中的事物，关系描述事物之间在数据方面的联系，都可以带有属性。
发展之后的方法也把实体称作对象，并使用了类型和子类型的概念，作为实体（对象）的抽象描述。
E-R图：
信息模型：
信息建模法已经很接近面向对象方法，因此有的文献也把它称为一种面向对象方法，但有以下差别：
1) 强调的重点是信息建模和状态建模，而不是对象建模
2) 实体中只有属性没有操作
3) 只有属性的继承，不正常操作的继承
4) 没有采用信息通讯
4.面向对象方法
面向对象的分析（OOA）
面向对象的设计（OOD）
运用对象、类、继承、封装、聚合、关联、消息、多态性等概念来构造系统。
把问题域中的事物抽象为对象，作为系统的基本构成单位，其属性和操作刻画了事物的静态特征和动态特征——完整地刻画了问题域中事物。
用类作为对象的抽象描述，建立它们之间的继承、聚合、关联、消息等关系——如实地表达了问题域中事物之间的各种关系。
封装、继承、聚合、关联、消息通讯等原则符合人类的日常思维——使系统的复杂性得到控制。
不同的建模方法 体现于
从不同的概念出发认识问题域
用不同的概念进行系统构造
系统对现实世界的映射方式不同
不同的方法对同一应用实例（电话安装业务系统）的不同效果
结构化分析——数据流和加工
问题：
不是直接映射问题域，与事物相关的数据和操作不是围绕这些事物来组织的，而是分散在数据流和加工中；经常发生信息膨胀——模型中的多个数据里，实现中其实只是一项数据；分析模型难以与设计模型及源程序对应。
面向对象方法——对象及其关系
什么是OOA
顾名思义，面向对象的分析（OOA），就是运用面向对象方法进行系统分析。
首先，OOA是分析，是软件生存周期的一个阶段，具有一般分析方法共同具有的内容、目标及策略；
但是，它强调运用面向对象方法进行分析，用面向对象的概念和表示法表达分析结果。
基本任务：运用面向对象的概念对问题域进行分析，将问题域中与系统责任有关的事物抽象为系统中的对象，定义这些对象的属性与操作，以及它们之间的各种关系。
最终目标：简历一个满足用户需求、直接映射问题域的OOA模型。
什么是OOD
不同时期有不同内容及特点
早期（80年代末期之前）OOD的特点：
1) 不是基于OOA的
大多基于结构化分析结果（数据流图）
2) 是OO编程方法的延伸
多数方法与编程语言无关，特别受Ada影响很大
3) 不是纯OO的
对某些OO概念（如继承）缺少支持，掺杂一些非OO概念（如数据流、包、模块等）
4) 不是只针对软件生存周期的设计阶段
OOD中的“D”——指的是Design或Development，多少涉及分析问题（如识别问题域的对象），但很不彻底
——早期的OOD可看作现今OOA&D方法的雏形
现今（90年代以后）OOD的特点：
i. 以面向对象的分析为基础，一般不依赖结构化分析。
ii. 与OOA方法共同构成一种OOA&D方法体系。OOA和OOD采用一致的概念与原则，但属于软件生存周期的不同阶段，有不同的目标及策略。
iii. 较全面地体现面向对象方法的概念与原则。
iv. 大多数方法独立于编程语言，通过面向对象的分析与设计所得到的系统模型可以由不同的编程语言实现。
定义：
面向对象的设计（OOD）就在是OOA模型基础上运用面向对象方法进行系统设计，目标是产生一个符合具体实现条件的OOD模型。
OO方法的主要优点
软件建模面临的挑战
a) 问题域和系统责任复杂性日益增长
问题域（problem domain）：被开发系统的应用领域，即在现实世界中由这个系统进行处理的业务范围。
系统责任（system responsibilities）：所开发的系统应该具备的职能。
随着硬件性能的提高和价格的下降，软件系统所面临的问题域和系统责任越来越复杂，因此系统也越来越庞大。
b) 交流问题
软件系统的开发需要各类人员之频繁交流。领域的多样性使软件工程中的交流问题比与其他工程更为突出。
有效的交流需要一种彼此都能理解的共同语言，否则将彼此的思维难以沟通，很容易隐藏下许多错误。
c) 需求的不断变化
用户因素，竞争因素，经费因素……
d) 软件复用的要求
复用级别提高——分析与设计结果复用
要求分析与设计模型的基本成分可以在多个系统中复用
面向对象方法的优势
i. 对问题域和系统责任的复杂性具有较强的处理能力
从问题域中的实际事物出发来构造系统模型，使系统模型能直接地映射问题域；继承、封装、聚合等概念使系统的复杂性得到有效的控制。
ii. 提供了便于各类相关人员交流共同语言
使用与问题域一致的概念及术语，体现人类的日常思维方式，为改进各类人员之间的交流提供了最基本的条件。
iii. 对需求的变化具有较强的适应性
按封装原则把系统中最容易变化的因素隔离起来，系统的各个单元成分之间接口很少，把需求变化所引起的影响局部化。
iv. 为实现分析与设计级别的软件复用提供了有力支持
OO方法的封装、继承、聚合等原则，对象的完整性、独立性以及与问题域的良好对应，使之有利于软件复用。
v. 贯穿软件生存周期全过程的一致性
从OOA开始使用与问题域一致的概念、词汇、原则及表示法，这种一致性保持到设计、编程、测试、维护等各个阶段，对于整个软件生存周期的开发、维护及管理活动都具有重要的意义。
几种典型的OO方法
方法的异同体现于：
概念、表示法、系统模型、开发过程、可用性、技术支持等方面
Booch方法
过程：
特点：
思维活跃，开拓与创新，可操作性不够强，类图与对象图并存
Coad/Yourdon方法
特点：
概念简练，过程清晰，强调概念的一致性，过程指导不够具体
Jacobson方法（OOSE）
特点：
通过用况描述用户需求，用交互图描述对象之间的交互，用况驱动的观点言之有过。
Rumbaugh方法（OMT）
特点：
概念严谨，阐述清楚，过程具体，可操作性强，包含了许多非OO的内容，提出若干扩充概念，偏于复杂。
二、 统一建模语言UML
1. UML的背景和发展历史
l 诞生背景
ü 面向对象方法种类繁多（1989年约10种，1994年达到50种以上）
ü 概念、表示法、过程策略及文档组织等方面存在很多差异（用户在选择建模方法和工具时无所适从，不利于技术交流）
ü 迫切需要OO概念及表示法走向统一和标准化（统一建模语言UML应运而生）
l 发展历史
n 第一阶段：OO方法学家的联合行动
1995.10： G.Booch 与J.Rumbaugh联合（推出Unified Method 0.8）
1996.6：I.Jacobson加入（推出UML0.9[Unified Modeling Language]）--各家主要的面向对象方法家将其各自的方法统一为UML，但不称统一建模方法，而称统一建模语言，最根本的原因在于UML只是统一的概念与表示法，没有统一过程。
n 第二阶段：公司的联合行动
1996：成立了UML伙伴组织，12家公司加入。
1997.1：推出UML1.0，另外5家公司加盟。
1997.9：形成UML1.1，提交OMG作为建模语言规范提案。
1997.11：UML1.1被OMG正式采纳。
n 第三阶段：OMG主持下的修订
1997~2002：OMG成立UML修订任务组主持UML的修订，先后产生UML1.2、UML1.3、UML1.4、UML1.5等版本。
n 第四阶段：UML的重大修订——UML2
1999：开始酝酿，旨在产生比UML1有显著改进的新版本。
2000~2001：由OMG陆续发不了4个提案需求（RFP）[征集提案，择优采纳]。
2002年之后先后形成4个UML2.0规范，在OMG的组织下进行修订，产生了UML2.1~2.4一系列版本。
n 第五阶段：提交到ISO申请成为国际标准
2005年以后UML2的4个规范陆续进入ISO的标准化日程，目前UML基础结构、UML上层结构、OCL已被ISO正式采纳，成为建模语言国际标准。
UML是什么不是什么
“统一建模语言（UML）是一种用来对软件密集型系统制品进行可视化、详述、构造和建档的图形语言，也可用于业务建模以及其它非软件系统。”
是一种建模语言，不是一种建模方法（“Rational统一过程”不是UML的一部分）
用于建立系统的分析模型和设计模型。而不是用于编程
是一种已被OMG采纳的建模语言规范（spceification）（UML2系列中被ISO采纳的部分才可称为标准（standard））
部分地采用了形式化语言的定义方式，但并不严格（不是一种形式化语言，不能编执行或解析执行
2. UML 1概况
UML1规范的主要构成部分
i. UML概要（UML Summary）：
对UML做概括介绍，包括起构成、动机、目标、范围、特点、历史、现状以及对未来演化的建议。
ii. UML语义（UML Semantics）：
定义UML的语法和语义，是定义UML语言的基本文件
iii. UML表示法指南（UML Notation Guide）：
定义UML的各种模型图，给出各种图中建模元素的可视化表示法
iv. UML外廓范例（UML Example Profiles）：
用于软件开发过程的UML外廓；用于业务建模的UML外廓
v. UML模型转换（UML Model Interchange）：
规定了建模工具在实现各种UML模型时需要共同遵守deep语言约定，使来自不同厂商的建模工具能够彼此交换和处理各自开发的系统模型。
vi. 对象约束语言OCL（Object Constraint Language）：
定义了一种对象约束语言，用来描述模型中关于对象的附加约束，是一种形式化的语言。
OMG的四层元模型体系结构
抽象元类和具体元类
UML1的9种模型图
静态结构图（Static Structure Diagram）
类图（Class Diagram）
对象图（Object Diagram）
用况图（Use Case Diagram）
交互图（Interaction Diagram）
顺序图（Sequence Diagram）
协作图（Collaboration Diagram）
状态图（State chart Diagrams）
活动图（Activity Diagrams）
实现图（Implementation Diagrams）
构件图（Component Diagram）
部署图（Deployment Diagram）
九种图支持用户从不同的视角进行系统建模
扩展机制：附加到其他模型元素之上，将原有的模型元素特化成一种语义叫特殊的新变种，或者表示出它们的某些细节。
约束（constraint）：用于说明某些必须保持为真的命题。
注释（comment）：对模型元素的细节所进行的解释。
标记值（Tagged Value）：表示模型元素的附加的特征。
衍型（stereotype）：附加到其他模型元素之上，从而将原有的模型元素特化成一种语义叫特殊的新变种。
3. UML 2概况
从UML1 到UML2
1999：开始酝酿对UML的重大修订
2000~2001：发布提案需求，征集提案，择优采纳
2002年之后先后形成4个UML2.0规范：UML基础结构、UML上层结构、对象约束语言（OCL）、UML图交换
在OMG的组织下继续进行修订：产生UML2.1~2.x一系列版本
UML2 的四个规范
UML2 的13种模型图
UML与UML2 的各种图的对照
UML的贡献和存在的问题
贡献：结束了面向对象建模领域在概念和表示法方面不统一的局面，使之走向规范化和标准化的轨道，成为一种被学术界和产业界广泛认可的统一建模语言。已被软件开发和业务建模等各个领域广泛采用，在正式成为国际标准之前，已经成为事实上的工业标准。
问题：规模庞大，概念过于复杂，模型图种类繁多
UML1.5——736页，9种模型图
UMl2.2——1284页260多个元类，13种模型图
收罗了很多不必要的复杂概念，存在一些在理论上不严格、难以自圆其说的缺陷。
例：
元模型中的实例级概念引起体系结构层次的混乱
来源：oschina
链接：https://my.oschina.net/u/1052754/blog/207682