目录

1、语法和语义规则

2、UML中的公共机制

（1）规约

（2）修饰

（3）通用划分

（4）扩展机制

衍型/版型/类型（stereotype）

标记值 （tagged value）

约束（constraint）

3、系统的体系结构建模

用例视图 （use case view）

设计视图 （design view）

交互视图 （interaction view）

实现视图 （implementation view）

部署视图 （deployment view）

4、软件开发的生命周期

4.1、初始 （inception）

4.2、细化 （elaboration）

4.3、构造 （construction）

4.4、移交 （transition）

---

1、语法和语义规则

命名——为事物、关系和图起的名字；

范围——使名字具有特定含义的语境；

可见性——这些名字如何让其他成分看见和使用；

完整性——事物如何正确、一致地相互联系；

执行——运行或模拟一个动态模型意味着什么。

2、UML中的公共机制

（1）规约

UML 不仅仅是一种图形语言。实际上，在它的图形表示法的每部分背后都有一个规约，这个规约提供了对构造块的语法和语义的文字叙述。
 

（2）修饰

UML中的大多数元素都有唯一而直接的图形表示符号，这些图形符号对元素的最重要的方面提供了可视化表示。

图中表明这个类是一个抽象类，

有两个公共操作、一个受保护操作和一个私有操作。

（3）通用划分

第一种方式是对类和对象的划分。类是一种抽象，对象是这种抽象的一个具体表现。

在图形上，UML是这样区分对象的：采用与类同样的图形符号来表示对象，并且在对象名的下面画一道线

有一个名称为Customer的类，它有3个对象，分别为

Jan（它被明确地标记为Customer的对象）

:Customer（匿名的Customer对象）

Elyse（它在规约中被说明为一种Customer对象，尽管在这里没有明确地表示出来）。

第二种方式是接口和实现的分离。接口声明了一个合约，而实现则表示了对该合约的具体实施，它负责如实地实现接口的完整语义。

在这个图中，有一个名称为SpellingWizard.dll的构件，

它实现了接口IUnknown和接口ISpelling，

并且还需要使用一个由其他构件提供的名为IDictionary的接口。

第三种方式是类型和角色的分离。类型声明了实体的种类（如对象、属性或参数），角色描述了实体在语境中的含义（如类、构件或协作等）。

任何作为其他实体结构中的一部分的实体（例如属性）都具有两个特性：

从它固有的类型派生出一些含义

从它在语境中的角色派生出一些含义

（4）扩展机制

衍型/版型/类型（stereotype）

扩展了UML的词汇，可以用来创造新的构造块，这个新构造块既是从现有的构造块派生的，但是针对专门的问题。

例如，假设正在使用一种编程语言，如Java或C++，经常要对“异常事件”建模。在这些语言里，“异常事件”就是类，只是用很特殊的方法进行了处理。通常可能只想允许抛出和捕捉异常事件，没有其他要求。

此时可以让异常事件在模型中成为“一等公民”——可以像对待基本构造块一样对待它们，只要用一个适当的衍型来标记它们即可。

标记值 （tagged value）

扩展了UML衍型的特性，可以用来创建衍型规约的新信息。

例如，如果在制作以盒装形式销售的产品，随着时间的推移，它经过了多次发行，那么经常会想要跟踪产品的版本和对产品做关键摘要的作者。

版本和作者不是UML的基本概念，通过引入新的标记值，可以把它们加到像类那样的任何构造块中去。例如，在图中，在类EventQueue上明确标记了版本和作者，这样就对该类进行了扩展。

约束（constraint）

扩展了UML构造块的语义，可以用来增加新的规则或修改现有的规则。例如，可能想约束类 EventQueue，以使所有的增加都按序排列。如上图，对操作 add增加了一个约束，即{ordered}，以明确标示这一规则。
 

3、系统的体系结构建模

不同人员关注各自的问题

用况：用例

用例视图 （use case view）

由描述可被最终用户、分析人员和测试人员看到的系统行为的用例组成。用例视图实际上没有描述软件系统的组织，而是描述了形成系统体系结构的动力。

在UML中，该视图的静态方面由用例图表现；动态方面由交互图、状态图和活动图表现

设计视图 （design view）

包含了类、接口和协作，它们形成了问题及其解决方案的词汇。这种视图主要支持系统的功能需求，即系统应该提供给最终用户的服务。

在UML中，该视图的静态方面由类图和对象图表现；动态方面由交互图、状态图和活动图表现。类的内部结构图特别有用。

交互视图 （interaction view）

展示了系统的不同部分之间的控制流，包括可能的并发和同步机制。该视图主要针对性能、可伸缩性和系统的吞吐量。

在UML中，对该视图的静态方面和动态方面的表现与设计视图相同，但着重于控制系统的主动类和在它们之间流动的消息

实现视图 （implementation view）

包含了用于装配与发布物理系统的制品。这种视图主要针对系统发布的配置管理，它由一些独立的文件组成；这些文件可以用各种方法装配，以产生运行系统。它也关注从逻辑的类和构件到物理制品的映射。

在UML中，该视图的静态方面由构件图表现，动态方面由交互图、状态图和活动图表现。

部署视图 （deployment view）

包含了形成系统硬件拓扑结构的结点（系统在其上运行）。这种视图主要描述组成物理系统的部件的分布、交付和安装。

在UML中，该视图的静态方面由部署图表现，动态方面由交互图、状态图和活动图表现。

4、软件开发的生命周期

1）用例驱动

把用例作为一种基本的制品，用于建立所要求的系统行为、验证和确认系统的体系结构、测试以及在项目组成员间进行交流。

2）以体系结构为中心

以系统的体系结构作为一种基本制品，对被开发的系统进行概念化、构造、管理和演化。

3）迭代的和增量

迭代：涉及到对一连串可执行的发布的管理。

增量：涉及到系统体系结构的持续集成，以产生各种发布，每个新发布都比上一个发布有所改善

总的来讲，迭代和增量的过程是风险驱动的（risk-driven），每个新的发布都致力于处理和降低对于项目成功影响最为显著的风险。

RUP四个阶段，即软件开发生命周期

4.1、初始 （inception）

在此阶段，萌发的开发想法经过培育要达到这样一个目标：至少要在内部奠定足够的基础，以保证能够进入到细化阶段。

4.2、细化 （elaboration）

在此阶段定义产品需求和体系结构。在这个阶段，将明确系统需求，按其重要性排序并划定基线。可以按一般的描述，也可以按精确的评价准则来排列系统的需求，每个需求都说明了特定的功能或非功能的行为，并为测试提供了基础。

4.3、构造 （construction）

在此阶段软件从可执行的体系结构基线发展到准备移交给用户。针对项目的商业需要，这里也要不断地对系统的需求，特别是对系统的评价准则进行检查，并要适当地分配资源，以主动地降低项目的风险。

4.4、移交 （transition）

在此阶段把软件交付给用户。在这个阶段，软件开发过程很少能结束，还要继续改善系统，根除错误，增加早期发布未能实现的特性。