无标题文档

UML & ROSE & CMM 技术汇集

制作日期: 2003.6.20

制作单位: 阿蒙工作室

Harry Meng

EMAIL : harry@vchome.net
WWW : http://www.vchome.net


Test Your UML Knowledge

Number: 1
Category: General
Question: Object-Oriented Technologies have the following benefits:

Answer1: Increased encapsulation
Answer2: Decreased coupling between modules
Answer3: Increased cohesion of code
Answer4: High level of abstraction
Answer5: All of the above

Number: 2
Category: General
Question: In Object-oriented Technology the word "UML" means

Answer1: Unified Module Language
Answer2: Unified Modeling Language
Answer3: Universal Module Leveling
Answer4: Universal Module Language

Number: 3
Category: General
Question: Which of the following statements is true?

Answer1: Structured analysis was developed from Object-oriented Technology.
Answer2: UML is a collaboration of the main stream Object-Oriented Methodologies.
Answer3: Object-Oriented Technology is the culmination of High level Programming languages such as Java and C++.
Answer4: Only object-oriented programming languages can be used to implement object-oriented designs.

Number: 4
Category: General
Question: What is true about Object-oriented Analysis?

Answer1: It is a method of modeling requirements of the system
Answer2: It is a technique for analyzing the design of the system
Answer3: Code can be written directly from the Analysis
Answer4: It comes after object-oriented design in the product life cycle.

Number: 5
Category: Classes
Question: A object has

Answer1: Behavior
Answer2: State
Answer3: Identity
Answer4: Attributes
Answer5: All of the Above

Number: 6
Category: Classes
Question: Which of the following is true?

Answer1: An object is an instance of a class
Answer2: A class is an abstract definition for a set of objects
Answer3: An object can be in more than one class
Answer4: An object has a life span.
Answer5: All of the above

Number: 7
Category: Classes
Question: An object's state is determined by,

Answer1: The value of all of its attributes
Answer2: Its relationships with other objects
Answer3: Its history at any given point in time
Answer4: The operations that it can perform
Answer5: Answers 2 and 4
Answer6: Answers 1 and 2
Answer7: Answers 1, 3, and 4
Answer8: Answers 1, 2, and 3

Number: 8
Category: Classes
Question: A class's structure is

Answer1: Represented in code
Answer2: Represented by attributes and relationships
Answer3: Represented by operations.
Answer4: Represented by object interactions.
Answer5: Answers 1 and 2
Answer6: Answers 2 and 3

Number: 9
Category: Classes
Question: A class's behavior is

Answer1: Determined by a set of operations
Answer2: Determined by its attributes
Answer3: Is unique for each object of the class
Answer4: Determined by its parent class.
Answer5: Answers 1 and 2
Answer6: Answers 2 and 3

Number: 10
Category: Classes
Question: Which of the following statements is true?

Answer1: Class cardinality determines the number of objects that can exist of the specific class.
Answer2: An abstract class contains only private operations.
Answer3: A utility class only contains operations.
Answer4: A parameterized class can only contain one formal parameter.

Number: 11
Category: Classes
Question: Which of the following statements are true about method visibility?

Answer1: A class's methods are visible to all other objects of the same class independent of its visibility.
Answer2: Other objects can access operations of a class if the visibility of the operation is public.
Answer3: An object can access all of its methods regardless of the visibility of the operation's visibility.
Answer4: A child class can access all of its parents operations regardless of visibility.
Answer5: Answer 1 and 2
Answer6: Answer 2 and 3
Answer7: None of the above

Number: 12
Category: Classes
Question: Which of the following is false about cardinality mapping?

Answer1: "1" - exactly one and only one
Answer2: "0..n" - any real number including zero
Answer3: "0..1" - zero or one
Answer4: "3..7" - 3 or 7
Answer5: "3,7" - 3 or 7

Number: 13
Category: Classes
Question: What is the type of visibility required for a child class to see the operations of a parent class in an inheritance relationship?

Answer1: Public
Answer2: Protected
Answer3: Private
Answer4: Implementation
Answer5: All of the above
Answer6: Answers 1 and 3
Answer7: Answers 2 and 3
Answer8: Answers 1 and 2

Number: 14
Category: Classes
Question: Polymorphism is

Answer1: When an operation in a child class has the same name and operation signature as the parent class.
Answer2: When an object changes the class that it belongs.
Answer3: When an operation in the same class has the same name and a different signature.
Answer4: When an attribute in a child class has the same, name and type, of the parent class.

Number: 15
Category: Classes
Question: The term "overriding" refers to

Answer1: An operation in a child class has the same name and operation signature as the parent class.
Answer2: An object changes the class that it belongs.
Answer3: When an operation in the same class has the same name and a different signature.
Answer4: When an attribute in a child class has the same, name and type, of the parent class.

Number: 16
Category: Classes
Question: Attributes of children classes in an inheritance relationship can have the same name as attributes in the parent class.

Answer1: This is called attribute overriding.
Answer2: This is called attribute polymorphism.
Answer3: This statement is not a valid in Object-oriented technology.
Answer4: This is called attribute redefinition.

Number: 17
Category: Classes
Question: What visibilities can attributes can have?

Answer1: Public
Answer2: Protected
Answer3: Private
Answer4: Implementation
Answer5: All of the above
Answer6: Answers 1 and 4
Answer7: None of the above

Number: 18
Category: Classes
Question: A utility class refers to

Answer1: A class that creates and destroys other classes
Answer2: A class that has 1 as the cardinality
Answer3: A group of common operations grouped together in a class
Answer4: A class that controls the behavior of other classes.

Number: 19
Category: Relationships
Question: What statement best describes an inheritance relationship?

Answer1: "HAS A" relationship.
Answer2: "IS A" relationship
Answer3: "IMPLEMENTS" relationship
Answer4: "USES" relationship
Answer5: "IS A MEMBER" relationship

Number: 20
Category: Relationships
Question: What statement best describes a realize relationship?

Answer1: "HAS A" relationship.
Answer2: "IS A" relationship
Answer3: "IMPLEMENTS" relationship
Answer4: "USES" relationship
Answer5: "IS PART OF" relationship

Number: 21
Category: Relationships
Question: What statement best describes an aggregation relationship?

Answer1: "HAS A" relationship.
Answer2: "IS A" relationship
Answer3: "IMPLEMENTS" relationship
Answer4: "USES" relationship
Answer5: "IS PART OF" relationship

Number: 22
Category: Relationships
Question: What statement best describes a dependency relationship?

Answer1: "HAS A" relationship.
Answer2: "IS A" relationship
Answer3: "IMPLEMENTS" relationship
Answer4: "USES" relationship
Answer5: "IS PART OF" relationship

Number: 23
Category: Relationships
Question: What statement best describes an association relationship?

Answer1: "HAS A" relationship.
Answer2: "IS A" relationship
Answer3: "IMPLEMENTS" relationship
Answer4: "USES" relationship
Answer5: "IS PART OF" relationship

Number: 24
Category: Relationships
Question: The class foo has many of the same attributes as class bar, but it behaves slightly differently from bar. It can be said that foo is a specialization of bar. What is the relationship between foo and bar?

Answer1: Association
Answer2: Aggregation
Answer3: Inheritance
Answer4: Realization
Answer5: Dependency
Answer6: None of the Above

Number: 25
Category: Relationships
Question: The class foo represents an interface to a library. The class bar contains all of the operations of the foo class and is the actual class that is used at runtime of the library. What is the relationship between foo and bar?

Answer1: Association
Answer2: Aggregation
Answer3: Inheritance
Answer4: Realization
Answer5: Dependency
Answer6: None of the above

Number: 26
Category: Relationships
Question: An operation in class foo calls an operation in class bar. There are no other relationships between the two classes. What type of relationship is this one?

Answer1: Association
Answer2: Aggregation
Answer3: Inheritance
Answer4: Realization
Answer5: Dependency

Number: 27
Category: Relationships
Question: A car has four wheels. The class car and the class wheel have what type of relationship?

Answer1: Association
Answer2: Aggregation
Answer3: Inheritance
Answer4: Realization
Answer5: Dependency

Number: 28
Category: Relationships
Question: The student attends several classrooms. The classroom can hold several students. What is the relationship between the student and the classroom?

Answer1: Association
Answer2: Aggregation
Answer3: Inheritance
Answer4: Realization
Answer5: Dependency

Number: 29
Category: Relationships
Question: What is true about tertiary relationships?

Answer1: It is a relationship that relates one class to three other classes.
Answer2: It is a single relationship that relates three classes together.
Answer3: It is a resulting relationship from a primary and secondary relationship.
Answer4: It is not a valid term in object-oriented technologies.

Number: 30
Category: Relationships
Question: What kinds of items are related in realization relationships?

Answer1: An interface and its implementation class
Answer2: A Parameterized class and an instantiated class
Answer3: An operation and a class
Answer4: An attribute and a class
Answer5: A package and a class
Answer6: All of the above
Answer7: Answers 1 and 2
Answer8: Answers 1 and 3
Answer9: Answers 2 and 3

Number: 31
Category: Relationships
Question: Select the relationships that can have cardinality, other than "1".

Answer1: Association
Answer2: Aggregation
Answer3: Inheritance
Answer4: Realization
Answer5: Dependency
Answer6: All of the above
Answer7: Answers 1, 3, and 4
Answer8: Answers 1 and 2
Answer9: Answers 3,4, and 5

Number: 32
Category: Relationships
Question: Which of the following statements are false?

Answer1: A class can have a relationship to itself.
Answer2: An object can have a relationship to other objects of the same class.
Answer3: A class can have only one relationship to another class.
Answer4: A relationship can exist with a cardinality of zero.
Answer5: A class can exist without any relationships to other objects.

Number: 33
Category: Relationships
Question: What types of relationships can a class have to itself?

Answer1: Association
Answer2: Aggregation
Answer3: Inheritance
Answer4: Realization
Answer5: Dependency
Answer6: Answers 1 and 2
Answer7: Answers 3 and 5
Answer8: Answers 4 and 5
Answer9: None of the above

Number: 34
Category: Use Cases
Question: What is an actor in use case analysis?

Answer1: Anything that interacts with the system.
Answer2: A term for business objects that reside in the system.
Answer3: Anything that reacts to outside forces of the system.
Answer4: This is not a term in use case analysis.

Number: 35
Category: Use Cases
Question: What of the following is true about use case analysis?

Answer1: The actors of the system determine the boundary of the system.
Answer2: The set of all actors delimits the system.
Answer3: Use Cases describe the responses of the system to stimuli from its actors.
Answer4: Use Cases can send stimuli to actors of the system.
Answer5: All of the above

Number: 36
Category: Use Cases
Question: A Use Case represents

Answer1: A class hierarchy of business objects.
Answer2: A set of uses relationships in the model.
Answer3: A sequence of transitions that are performed by the system.
Answer4: A state machine for the complete system.
Answer5: None of the above

Number: 37
Category: Use Cases
Question: Which of the following is false about Use Case Analysis?

Answer1: An Actor must be directly associated with at least one use case in the system.
Answer2: A use case must be directly related to at least one actor of the system
Answer3: A use case can be related to actors and other use cases.
Answer4: Actors can be people, machines, or other systems.
Answer5: All of the above are true

Number: 38
Category: Scenarios
Question: What is true about scenarios?

Answer1: It is an instance of a Use Case.
Answer2: It represents one flow of events in the system.
Answer3: It contains objects of the system and the interaction between the objects.
Answer4: It is a good place to find objects that can be classified into classes.
Answer5: All of the above
Answer6: None of the above

Number: 39
Category: Scenarios
Question: A software designer wants to show a scenario that has a time critical flow of control between multiple objects. What diagramming technique should they use?

Answer1: Sequence Diagram
Answer2: Collaboration Diagram
Answer3: State Diagram
Answer4: Class Diagram

Number: 40
Category: Scenarios
Question: A Sequence diagram contains

Answer1: Objects
Answer2: Messages
Answer3: Object Visibility
Answer4: Timing constraints
Answer5: Focus of control
Answer6: All of the above
Answer7: All of the above except 3
Answer8: All of the above except 5
Answer9: All of the above except 1

Number: 41
Category: Scenarios
Question: Collaboration diagrams contain

Answer1: Objects
Answer2: Messages
Answer3: Object Visibility
Answer4: Timing constraints
Answer5: Focus of control
Answer6: All of the above
Answer7: All of the above except 3
Answer8: All of the above except 5
Answer9: All of the above except 1

Number: 42
Category: Scenarios
Question: What is true about messages in scenarios?

Answer1: The operation of the calling object
Answer2: The operation of the called object
Answer3: It is sent by the actor to the system
Answer4: It is sent by the system to the actor
Answer5: None of the above

Number: 43
Category: State Machines
Question: A State Machine contains

Answer1: States of a class
Answer2: Transitions between states
Answer3: Actions performed by the class
Answer4: Events that trigger actions in the class
Answer5: All of the above

Number: 44
Category: State Machines
Question: A state machine can have only one

Answer1: Termination State
Answer2: Initial State
Answer3: Action per state
Answer4: Transition from a state
Answer5: All of the above

Number: 45
Category: State Machines
Question: A non-deterministic State Machines is

Answer1: When a state has multiple non-qualified outgoing transitions.
Answer2: When a state has one non-qualified outgoing transition.
Answer3: When a transition does not go to a state.
Answer4: When a transition does not have a guard condition.

Number: 46
Category: State Machines
Question: A transition with out a guard condition or a trigger event is called

Answer1: Non-deterministic transition
Answer2: Automatic transition
Answer3: Under-defined transition
Answer4: Illegal transition

Number: 47
Category: State Machines
Question: Which of the following statements is false?

Answer1: An object can be in more than one state at a time
Answer2: A state machine can have multiple termination states
Answer3: A state can remember which sub state was the last state
Answer4: A transition can fire conditionally.

Number: 48
Category: Design Patterns
Question: What is false about design patterns?

Answer1: A design pattern can decrease time to market and increase quality.
Answer2: A design pattern is a map from object-oriented design to specific language implementation.
Answer3: A design pattern contains well-defined constructs for specific types of problems.
Answer4: Design patterns can be applied to software problems, and organizational problems.

Number: 49
Category: Design Patterns
Question: What type of pattern is a factory pattern?

Answer1: A behavioral pattern
Answer2: A creation pattern
Answer3: A structural pattern
Answer4: An organizational pattern

Number: 50
Category: Design Patterns
Question: An engineer needs to design a system for multiple customers that are accessing the same database. Each customer has unique ways they want to look at the information from the database. They will need to see changes to the data in a real-time fashion. What design pattern will be most useful?

Answer1: Abstract Factory
Answer2: Blackboard
Answer3: Model View Controller
Answer4: Reflection
Answer5: Part-Whole
Answer6: None of the above

Answer


第一章 UML模型的基本概念

1 UML的建筑块

组成UML有三种基本的建筑块：
1、事物（Things）
2、关系（Relationships）
3、图（Diagrams）
事物是UML中重要的组成部分。关系把事物紧密联系在一起。图是很多有相互相关的事物的组。

1.1 UML的事物

UML中有始终类型的事物：

1、结构事物（Structural things）
2、动作事物（Behavioral things）
3、分组事物（Grouping things）
4、注释事物（Annotational things）
这些事物是UML模型中最基本的面向对象的建筑块。它们在模型中属于最静态的部分，代表概念上等或物理上的元素。

1.1.1结构事物。

总共有七种结构化事物。首先是类（class），类是描述具有相同属性、方法、关系和语义的对象的集合。一个类实现一个或多个接口。在UML 中类被画为一个矩型，通常包括它的名字、属性和方法。

Window

Origin Size

Open()
Close()
Move()
Display()

图1-1 类

第二种是接口（interface），接口是指类或组件提供特定服务的一组操作的集合。因此，一个接口描述了类或组件的对外的可见的动作。一个接口可以实现类或组件的全部动作，也可以只实现一部分。接口在UML 中被画成一个圆和它的名字。

图1-2 接口

第三种是协作（collaboration），协作定义了交互的操作，是一些角色和其它元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。因此，协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成部分。这些协作代表构成系统的模式的实现。协作在UML 中用一个虚线画的椭圆和它的名字来表示。

图1-3 协作

第四种是use case，use case是描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的值。在模型中use case通常用来组织动作事物。Use case是通过协作来实现的。在UML 中，use case画为一个实线椭圆，通常还有它的名字。

图1-4 use case
第五种是活动类（active class），活动类是这种类，它的对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的。在UML 中活动类的画法和类相同，只是边框用粗线条。

EventManager

Suspend()
Flush()

图1-5 活动类

第六种是组件（component），组件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，你可能会遇到不同种类的组件，例如COM+ 或JAVA BEANS。组件在UML中用如下的图表示：

图1-6 组件 第七种是结点（node），结点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个结点，但有可能从一个结点转到另一个结点。结点通常用如下的图形表示：
图1-7结点

类、接口、协作、use case、活动类、组件和结点这七个元素是在UML 模型中使用的最基本的结构化事物。系统中还有这七种基本元素的变化体，如角色、信号（某种类），进程和线程（某种活动类），应用程序、文档、文件、库、表（组件的一种）。

1.1.2 动作事物

动态事物是UML 模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。总共有两种主要的动作事物。
第一种是ineraction，interaction是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作。 interaction中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作），连接（对象之间的连接）。在UML 中消息画成带箭头的直线，通常加上操作的名字。

图1-8 消息
第二种是状态机（state machine），状态机由一系列对象的状态组成。在UML 中状态表示为下图：

图案1-9 状态

interaction和状态机是UML 模型中最基本的两个动态事物元素，它们通常和其他的结构元素、主要的类、对象连接在一起。

1.1.3 分组事物

分组事物是UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中被分解。总共只有一种分组事物，称为包（package）。
包是一种将有组织的元素分组的机制。结构事物、动作事物甚至其他的分组事物都有可能放在一个包中。与组件（存在于运行时）不同的是包纯粹是一种概念上的东西，只存在于开发阶段。在UML 中用如下图表示包：

图 1-10 包

1.1.4 注释事物

注释事物是UML模型的解释部分。UML中用如下图表示：

图　1-11 注释

1.1.5 UML中的关系

UML中有四种关系：
1. 依赖（Dependencies）
（图1-12 依赖）

2. 关联（Association）
（图　1-13 关联）

3. 一般化（generalization）
（图1-14 一般化）
4. 实现(realuzation)
（图　1-15 实现）

1.1.6 UML中的图

1、类图（class diagram）
2、对象图（class diagram）
3、Use case diagram
4、Sequence diagram
5、Collaboration diagram
6、Statechart diagram
7、Activity diagram
8、Compomnent diagram
9、Deployment diagram
关于这些图的详细介绍将在今后的章节中讲解。

联系本文作者：21newtimes@163.net
如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。

第二章 Hello World

记得在学习C语言的时候，教科书上的第一个程序就是叫Hello world，一个在屏幕上简单地打印出“Hello world!”语句的例子。在系统的学习UML语言之前我们来看一个简单的例子，让大家有一个系统的认识。

在java中一个在浏览器中显示“Hello World!”的Applet代码如下：
import java.awt.Graphics;
class HelloWorld extends java.applet.Applet{
public void paint( Graphics g ){
g.drawString("Hello World!", 10,10 );
}
}
代码的第一行：
import java.awt.Graphics;
使得程序可以使用Graphics类。前缀 java.awt指出了类Graphics所在的包。
第二行代码：
class HelloWorld extends java.applet.Applet{
从Applet类派生出新的类HelloWorld，Applet类在java.applet包中。
接下来的三行代码：
public void paint( Graphics g ){
g.drawString("Hello World!", 10,10 );
}
声明了类HelloWorld的方法paint，在他的实现中调用了另一个方法drawString来输出“Hello World!”。
我们可以很直接地为这个程序用UML建立模型。如图2-1。

图 2-1 HelloWorld

图2-1表达了最基本的HelloWorld模型，但它还有很多东西没有表示出来。在我们的程序中Applet类和Graphics类的使用是不相同的。Applet用作HelloWorld类的父类，而Graphics类用在方法paint的实现中。在UML模型中可以将这些关系表示为图2-2:

图2-2 HelloWorld的类图

在图2-2的类关系图中，我们用简单的矩行图标表示类Applet和Graphics类，没有将它们的属性和方法显露出来是为了简化。图中的空心箭头表示HelloWorld类是Applet类的子类，代表一般化。HelloWorld和Graphics之间的虚线箭头表示依赖关系，表示HelloWorld类使用了Graphics类。
到这里或许你认为已结束了，其实不然，如果认真研究java库中的Applet类和Graphics类会发现他们都是一个庞大的继承关系中的一部分。追踪Applet的实现可以得到另外一个类图，如图2-3所示：

图2-3 HelloWorld继承图

联系本文作者：21newtimes@163.net
如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。

第三章 类

类是具有相同属性、操作、关系的对象集合的总称。通常在UML中类被画成矩形。

名称

每个类都必须有一个名字，用来区分其它的类。类名是一个字符串，称为简单名字。路径名字是在类名前加包含类的包名为前缀。例如Wall、java::awt::Wall都是合法的类名。

属性

属性是指类的命名的特性，常常代表一类取值。类可以有任意多个属性，也可以没有属性。在类图中属性只要写上名字就可以了。如下图

也可以在属性名后跟上类型甚至缺省取值，如下图：

操作

操作是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。操作在类图中如下图描述：

组织属性和方法

在画类图的时候没有必要将全部的属性和操作都画出来。实际上，在大部分情况下你也不可能在一个图中将类的属性和操作都画出来。在画类图时可以只将感兴趣的属性和操作画出来就可以了。可以用”...”表示还有属性或方法没有画出来。为了更好地组织属性或方法，可以在一组功能相同的属性或方法前加上一个描述的前缀（<<>>中的文字），如下图：

职责

职责指的是类所担任的任务，类的设计要完成什么样的功能，要存担的义务。一个类可以有多种职责，设计得好的类一般至少有一种职责，在定义类的时候，将类的职责分解成为类的属性和方法。

通常在UML中在类图的最下方用单独的部分列出类的职责。

类的职责其实只是一段或多段文本描述。

通用建模技术

1. 为系统的词汇建立模型

l 标识出用户或解决问题时用来描述问题的东西，使用CRC卡片和基于USE－CASE的分析来找出这些抽象。

l 对每一个抽象，标识出它的职责集合。确定明确地定义了每一个类，在为所有类确定的职责中取得了很好的平衡。

l 为类提供实现类的职责所需要的属性和方法。

2. 为系统的职责分配建立模型

l 标识出行为相类似的对类

l 找出这些类的职责

l 把这些类作为整体看待，把职责多的类分为几个小类

l 考虑这些类如何协作，重新进行类的职责分配已满足协作中没有类太多职责或太少职责

3. 为非软件的事务建立模型

l 为抽象成类的事务建立模型

l 如果你建模的是硬件本身包含有软件，建模时考虑为一种NODE，这样可以对它进一步的分解。

4. 为原始类型建模

l 为类型或枚举建立模型

l 如果要对这种类型取值范围进行说明，使用约束。

联系本文作者：21newtimes@163.net
如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。

第四章 关系

依赖关系（Dependency）

依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用依赖关系。

通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。在UML中你可以在其它的事物之间使用依赖关系，特别是包和节点之间。

图 4-1 依赖关系

一般化（Generalization）

一般化是继承关系，是叫做“is-a-kind-of”的关系。在UML中你可以在包之间建立一般化关系。

图 4-2 一般化

关联（Association）

关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象。关联有两元关系和多元关系。两元关系是指一种一对一的关系，多元关系是一对多或多对一的关系。一般用实线连接有关联的同一个类或不同的两个类。当你想要表示结构化关系时使用关联。

有一些修饰可以应用于关联。

1. 名字：可以给关系取名字

2. 角色：关系的两端代表不同的两种角色

3. 重数：表示有多少对象通过一个关系的实例相连接

联系本文作者：21newtimes@163.net
如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。

第五章 通用机制

UML中的四种机制使地它简单和更易于使用，你可以在UML语言的任何时候用同样的方法来使用，这四种机制是：

l specifications

l adornments

l common divisions

l extensibility

本章讨论adornments和extensibility这两种机制。

注释是最重要的一种修饰。一个注释在UML中是一个图形符号，描述了和它相关联的元素或一组元素的限制或注释语。

上图就是一个使用注释的例子，图中右边的为注释符号。

UML的扩充性机制允许你在控制的方式下扩充UML语言。这一类的机制包括：stereotype，标记值、约束。Stereotype扩充了UML的词汇表，允许你创建新的建筑块，这些建筑块从已有的继承而来，但特别针对你的问题。标记值扩充了UML的建筑块的属性，允许你在元素的规格中创建新的信息。约束扩充了UML建筑块的语义，允许你添加新的规则或修改已有的。你将使用这些机制来让UML满足你的领域和开发的特别需要。

上面是一个使用扩充机制的例子。<<subsystem>>是stereotype，{version = 3.2}是标记值

术语和概念

注释是一种图形符号用来限制或给一个元素或一组元素加上注解。注释画成一个带折角的矩形，在矩形中加上文字或图形的注解，

stereotype 是UML词汇的扩充，允许你创建新的UML建筑块，这些新的建筑块和原有的类似，但特别针对你自己的问题。通常stereotype画成用<<和>>包围起来的一个名字，通常放在另一个元素的名字之上。作为可选，stereotype可以画成加一个图标。

标记值是UML元素特性的扩充，允许你创建元素规格的新的信息。在UML中标记值画成{}内的字符串，跟在元素名后面。

限制是UML元素语义的扩充，允许你对一个UML元素添加新规则或修改存在的规则。限制通常画成{}内的字符串，放在关系附近。当然，你也可以把限制用注释来表示。

通用建模技术

1. 建模注解

使用注释的目的是为了让模型更清晰，下面是使用注释的一些技巧：

l 将注释放在你要注解的元素边上，写下注解的文字。用依赖关系的线将注释和被注释的元素连起来会让人更明白。

l 记住，你可以隐藏元素或使隐藏的元素可见。这就意味着你可以将注释不隐藏起来，而她注释的元素是可见的，这样会使你的模型图简洁，在必要的地方让注释可见。

l 如果你的注释很长或不仅仅是普通文本，你可以将你的注解放到一个独立的外部文件中（如WORD文档）然后链接或嵌入到你的模型中。

下面是一个使用注解的例子：

建立新的建筑块

UML的建筑块如：类、接口、合作、组件、注释、关系等等，都在为具体问题建模的时候基本上是够用了。然而，如果你想扩展你的模型的词汇，如用来表示你的特定的问题领域，你需要stereotypes。

建立新的建筑块有如下的技巧：

l 确定没有现成的基本的UML方法可以表达你的需要。如果你碰到一个普通的建模问题，很有可能已经有某种标准的stereotype是你想要的。

l 如果你确信没有现成的东西可以表达这些语义，首先找到一个UML中的最接近你要建立的模型的元素（例如：类、接口、组件、注释、关系等等）然后为她定义一个stereotype。值得一提的是你可以定义stereotypes的层次从而得到一般的stereotypes和为它定义的特别的特性。这种方法尽量少用。

l 通过对普通的stereotype定义一组标记值和对stereotype进行限制可以实现普通stereotype不能实现的功能。

l 如果你希望这些stereotype具有不同的视觉效果，为他们定义一个特别的图标。

上面是一个例子。假如你用活动图来为一个涉及到教练工作流和队员工作流的体育活动建模。在这里，区别教练和运动员以及与其他的本领域的对象是有意义的。上面的图中有两个事物是很突出的，教练对象和队员对象。这里不仅仅是普通的类，更确切地说，他们现在是两个新的建筑块。因为定义了教练和队员stereotype，并且运用到了UML的类上。在这个图上，被标记为:Coach和:Team的匿名实例，后者显示了不同的状态。

建模新属性

UML建筑块的基本属性如：类的属性和操作，包的内容等等，都足够描述清楚你要建立的模型。然而，如果你想扩展这些基本建筑块（或者用stereotype建立的新的建筑块）的属性，你就需要使用标记值。

下面是一些技巧：

l 首先要确定的是你的需要无法用基本的UML表达。如果你碰到一个普通的建模问题，很有可能已经有某种标准的标记值是你想要的

l 如果你确定没有其他的方法可以表达你需要的语义，添加新的属性到一个单独的元素或一个stereotype。继承的规则是适用的，也就是说对父亲定义的标记值对儿子也具有。

建立新的语义

当你用UML建立模型的时候，你总是使用UML定义的规则，这实在是件好事，因为别的懂得如何读UML的人可以毫无偏差地读懂你想要表达的东西。然而，如果你发现你需要表达的语义是UML无法表达的或你想要修改UML的规则，这时你就需要使用限制了。下面是使用限制的一些技巧：

l 首先要确定的是你的需要无法用基本的UML表达。如果你碰到一个普通的建模问题，很有可能已经有某种标准的限制是你想要的。

l 如果你确定没有其他的方法可以表达你需要的语义，用文本的形式在限制中写下你的新语义，并且将他放在他涉及的元素附近。你可以使用依赖关系来明确地表示限制和他涉及的元素之间的关联。

l 如果你需要详细说明你的语义，你可以用使用OCL把它写下来。

下面的图是一个公司人力资源系统的一小部分：

这副图显示了每个Person可能是0个或多个Department的成员。每个Department至少要有一个Person成员。这副图进一步说明每个Department严格地有一个Person作为管理者，每个Person可以是0个或多个Department的被管理人员。所有的这些语义可以被简单的UML表达。然而，为了指出一个管理者必须也是Department的成员是多员关系所忽略的，也是简单的UML无法表达的。为了表达这种关系，你必须写下一个限制指出管理者是Department成员的一个子集。从子集到超集用依赖关系将两个关系联系起来。

联系本文作者：21newtimes@163.net
如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。

第六章 图

前言

建模实际上是对真实世界进行简化，从而可以更好地理解你要开发的系统。使用UML中基本的建筑块如：类、接口、关系、协作、组件、依赖、继承等，可以建立你想要的模型。还可以利用第五章介绍的机制扩充UML来表达问题领域独特的东西。

图是你组织这些建筑块的方式。图代表着一系列的元素，这些元素常常被画成用点（事物）和弧（关系）相连的图。利用图来从不同的视角来观察系统。由于没有一个复杂的系统可以从一个透视图弄明白，UML定义了一些图使得我们可以独立地从几个不同的视角来了解系统。

好的图使得你要开发的系统是易于理解和可以接近的。选择好的图对系统建模让你找到系统中真正要问的问题，帮助你阐述清楚你的系统。

术语和概念

系统是组织起来完成特定目标的一组子系统。系统可以用一组模型，可能来自不同的视角，进行描述。子系统是一组元素，其中一些通过包含的另外的元素组成特定的行为。模型是对系统进行语义上的抽象，它是整个真实系统的简化，为了更好地理解系统而创建的。图是一系列的元素，这些元素常常被画成用点（事物）和弧（关系）相连的图。利用图来从不同的视角来观察系统。

系统代表着你要开发的事物，通过不同的模型从不同的透视图来观察系统，这些透视图以图的形式表达。

在对真实世界进行建模的时候，你可以发现不管你的问题处于什么样的领域，你都会创建相同的图，因为他们代表着通用的模型的通用的视。通常，你利用下面的图来观察系统的静态部分：

1. 类图(Class Diagram)

2. 对象图(Object Diagram)

3. 组件图(Compoment Diagram)

4. 分布图(Deployment Diagram)

使用下面的五种额外的图来观察系统动态的方面：

1. Usecase图

2. 序列图(Sequence Diagram)

3. 协作图(Collaboration Diagram)

4. 状态图(Statechart Diagram)

5. 活动图(Activity Diagram)

UML定义了这五种图。

结构化图（Structural Diagrams）

1. 类图(Class Diagram) 类、接口和协作

2. 对象图(Object Diagram) 对象

3. 组件图(Compoment Diagram) 组件

4. 分布图(Deployment Diagram) 节点（Notes）

类图 类图显示了一组类、接口和协作以及它们之间的关系。类图在面向对象的建模设计中是很常用的。利用类图阐明系统的静态的设计。包含活动类（active classes）的类图通常用来说明看到的系统静态过程。

对象图 对象图显示了一组对象和他们之间的关系。使用对象图来说明数据结构，类图中的类或组件等的实例的静态快照。对象图和类图一样反映系统的静态过程，但它是从实际的或原型化的情景来表达的。

组件图 组件图显示了一些组件和它们之间的关系。使用组件图来说明系统的静态实现。组件图和类图是有联系的，通常一个组件可以映射成一个或多个类，接口或协作。

分布图 分布图显示了一些节点和它们之间的关系。使用分布图来说明系统的静态结构。分布图和组件图是有联系的，通常一个节点封装了一个或多个组件。

动作图（Behavioral Diagrams）

UML中定义的动作图包括：

1. Usecase图

2. 序列图(Sequence Diagram)

3. 协作图(Collaboration Diagram)

4. 状态图(Statechart Diagram)

5. 活动图(Activity Diagram)

Usecase图 Usecase图显示了一些Usecase和角色（特殊的类）和他们的关系。使用usecase图来描述系统静态的功能场景。Usecase图对于组织和模型化系统的动作是很重要的。

序列图 序列图是一种交互图（interaction diagram），强调的是时间和消息的次序。一个序列图显示了一系列的对象和在这些对象之间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用序列图来说明系统的动态情况。

协作图 协作图是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。

注意：序列图和协作图是同构的，它们相互之间可以转化而不损失信息。

状态图 状态图显示了一个状态机，由状态、转换、事件和活动组成。使用状态图说明系统动态情况。状态图对于建模接口的动作、类的动作或协作的动作是重要的。状态图强调的是事件驱动的对象的动作，这在对反应式系统的建模是相当重要的。

活动图：活动图显示了系统中从一个活动到另一个活动的流程。活动图显示了一些活动，他们很象传统的流程图有序列或分支。活动图对于给系统的功能建模是很重要的。活动图强调的是对象之间的流程控制。

通用建模技巧

1. 对系统的不同视进行建模

l 决定采用哪个视才能最好地表达系统的结构，以及暴露出项目的技术风险。前面讨论的五种图是很好的开始点。

l 对每一种视图决定要画那些图，通常一个视图会对应多个图

l 作为你的过程计划的一部分，决定那些图是要作为项目文档保存。

l 不要认为一次能够将图画好，最好准备一个装废纸的房间。

例如，如果你为一个简单的应用建模。你可能只需要其中一部分视图。

Usecase 视图 | usecase图
设计(Design)视图 | 类图
 | 交互图
处理（Process）视图 | 不需要
展开视图 | 不需要
实现视图 | 不需要

如果你是一个反应式的系统或系统的重点在处理流程上，你可能想包括状态图和活动图来建立系统的动作模型。

同样的，如果你是一个Client/Server系统，你可能想用组件图和分布图来为你的系统的物理细节进行建模。

最后，如果你是要对一个复杂的、分布式的系统建模，你需要使用所有的UML的图来表达系统的结构和项目的技术风险，如下所示：

Usecase视图 | Usecase图
 | 活动图
设计视图 | 类图（结构化建模）
 | 交互图（动作建模）
 | 状态图（动作建模）
过程视图 | 类图（结构化建模）
 | 交互图（动作建模）
实现视图 | 组件图
展开视图 | 分布图

2. 不同抽象层次建模

你不仅要从不同的视角观察系统，还要系统进行不同层次的抽象，因为参加项目开发的人可能对同一个系统的视图需要不同的抽象层次。对于程序员来说，他希望看到的是类的属性、方法，而对于一个系统分析员使用usecase场景来说只要看到存在这么个类就可以了，这里程序员要求的抽象层次较底层。可以通过隐藏或显示不同层次的细节来实现不同抽象层次的模型，或者创建不同层次抽象的图。

l 考虑你的读者的需要，从一个给定的模型开始

l 如果你的读者使用模型是构造一个实现，他需要的是较低层的抽象，也就是说他需要更多的细节。如果他利用概念模型只是为了和最终用户交流，他需要的是高层次的抽象，不需要细节的东西。

3. 复杂视图建模

l 首先确信没有更好的方法可以利用高层次的抽象表达要表达的信息，即便是删除一部分图或保留细节到另外一部分。

l 如果你隐藏了你所能隐藏的细节而你的图还是很复杂，考虑将一部分元素分组放到包里或放到较高层次的协作中，然后在你的图中只画这些包和协作。

l 如果你的图还是很复杂，使用注释或颜色来钩出你的重点好引起读者的注意

l 如果你的图依然很复杂，哈哈，打印出来，贴到墙上，将读者叫来亲自讲解给他听吧。希望他能明白……其实你可以自己慢慢研究，最后发现简化还是可以的。

第七章 类图

前言

类图是在面向对象的系统模型中使用得最普遍的图。类图包含了一组类、接口和协作以及他们之间的关系。

你使用类图来为系统的静态视图建模。通常这包括模型化系统的词汇（从系统的词汇表中发现类），模型化协作，或则模型化模式。类图还是一些相关的图的基础，包括组件图、分布图。

类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型，同样重要的是构建通过正向和反向工程建立执行系统。

术语和概念

类图：类图是一组类、接口和协作以及他们之间的关系构成的。

类图通常包含如下的内容：

l 类

l 接口

l 协作

l 依赖关系、继承关系、关联关系

同其他的图一样，类图也可以包含注解和限制。

类图中也可以包含包和子系统，这两者用来将元素分组。有时后你也可以将类的实例放到类图中。

注：组件图和分布图和类图类似，虽然他们不包含类而是分别包含组件和节点。

你通常通过下面三种方式使用类图：

1，为系统词汇建模型

为系统的词汇建模实际上是从词汇表中发现类，发现它的责任。

2，模型化简单的协作

协作是指一些类、接口和其他的元素一起工作提供一些合作的行为，这些行为不是简单地将元素加能得到的。例如：当你为一个分布式的系统中的事务处理过程建模型时，你不可能只通过一个类来明白事务是怎样进行的，事实上这个过程的执行涉及到一系列的类的协同工作。使用类图来可视化这些类和他们的关系。

3，模型化一个逻辑数据库模式

想象模式是概念上设计数据库的蓝图。在很多领域，你将想保存持久性数据到关系数据库活面向对象的数据库。你可以用类图为这些数据库模式建立模型。

通用建模技术

没有类是单独存在的，他们通常和别的类协作，创造比单独工作更大的语义。因此，除了捕获系统的词汇以外，还要将注意力集中到这些类是如何在一起工作的。使用类图来表达这种协作。

l 确定你建模的机制。机制代表了部分你建模的系统的一些功能和行为，这些功能和行为是一组类、接口和其他事物相互作用的结果。

l 对于每个机制，确定类、接口和其他的参与这个协作的协作。同时确定这些事物之间的关系。

l 用场景来预排这些事物，沿着这条路你将发现模型中忽略的部分和定义错误的部分。

l 确定用这些事物的内容来填充它们。对于类，开始于获得一个责任（类的职责），然后，将它转化为具体的属性和方法。

图 7-1 模型化简单的协作

图7-1是一个自治机器人的类图。这张的图焦点聚集那些让机器人在路上行走的机制对应的类上。你可以发现一个虚类Motor和两个从它派生出来的类：SteeringMotor和MainMotor。这两个类都从它的父亲Motor继承了五个方法。这两个类又是另一个类Driver的一部分。类PathAgent和Driver有一个1对1的关系，和CollisionSensor有1对n的关系。

在这个系统中其实还有很多其他的类，但这张图的重点是放在那些将机器人移动的类上的。在其他的图中你可能也会看到这些类。通过将焦点放在不通的功能上，可以获得从不通的角度对整个系统的认识，最终达到认识整个系统。

很多系统都是有持久性数据的，也就是说要将这些数据保存到数据库中以便下一次使用。通常你会使用关系型数据库或面向对象的数据库，或其它类型的数据库来保存数据。UML很适合为逻辑数据库模式建模。

UML的类图是E-R图（为逻辑数据库建模的通用工具）的超集，尽管E-R图的重点是数据，类图的扩展允许模型化行为。在物理数据库中这些逻辑操作一半转化为触发器或存储过程。

l 确定那些状态比其生命周期要长的类。

l 创建一张包含这些类的图，标记它们为持久性的。

l 详细定义它们的属性。

l 对于使得物理数据库设计复杂的模式如：循环关系、1对1关系、N元关系，考虑创建中间抽象来使得逻辑结构复杂。

l 详细定义这些类的操作，特别是那些访问数据和涉及数据完整性的方法。

l 如果可能的话使用工具来将你的逻辑设计转化为物理设计。

图7-2 模式建模

建模是重要的，但要记住的是对于开发组来说软件才是主要的产品，而不是图。当然，画图的主要目的是为了更好地理解系统，预测什么时候可以提供什么样的软件来满足用户的需要。基于这个理由，让你画的图对开发有指导意义是很重要的。

某些时候，使用UML。你的模型并不能直接映射成为代码。例如，如果你在使用活动图为一个商业过程建模，很多活动实际上涉及人而不是计算机。

很多时候，你创建的图形可以被映射成为代码。UML并不是专门为面向对象的语言设计的，它支持多种语言，但使用面向对象的语言会更直观些，特别是类图的映射，它的内容可以直接映射成为面向对象语言的内容。如：C＋＋，SMALLTALK、ADA、ObjectPascal、Eiffel和Forte。UML还支持如Visual Basic这样的面向对象的语言。

正向工程：是从图到代码的过程。通过对某中特定语言的映射可以从UML的图得到该语言的代码。正向工程会丢失信息，这是因为UML比任何一种程序语言的语义都丰富。这也正是为什么你需要UML模型的原因。结构特性、协作、交互等可以通过UML直观地表达出来，使用代码就不是那么明显了。

对类图的正向工程：

l 选择将图形映射到哪一种程序语言。

l 根据你选择的语言的语义，你可能要对使用某写UML的特性加以限制。例如：UML允许你使用多重继承，而SmallTalk只允许一重继承。

l 使用标记值来指定比的目的语言。你可以在类级进行也可以在协作或包的层次上进行。

l 使用工具来对你的模型进行正向工程。

反向工程：反向工程是从代码到模型的过程。

进行反向工程：

l 确定将你的程序语言的代码反向成模型的规则。

l 使用工具（Rose C++ Analyzer）进行反向工程。

提示和技巧

一个结构化好的类图：

l 焦点放在系统静态设计视图的一个方面

l 只包含为了理解该方面而应该存在的元素

l 提供足够的信息来理解该图

l 不让读者产生错误的信息

当你画类图的时候：

l 给它起一个名字，这个名字能表达类图的用途

用最少的交叉线来组织它的元素。

联系本文作者：21newtimes@163.net
如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。


一、标准建模语言UML概述

面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。

它不仅统一了Booch、Rumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终统一为大众所接受的标准建模语言。

1. 标准建模语言UML的出现公认的面向对象建模语言出现于70年代中期。从1989年到1994年,其数量从不到十种增加到了五十多种。

在众多的建模语言中,语言的创造者努力推崇自己的产品,并在实践中不断完善。

但是,OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异,因而很难根据应用特点选择合适的建模语言,于是爆发了一场"方法大战"。

90年代中,一批新方法出现了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。Booch是面向对象方法最早的倡导者之一,他提出了面向对象软件工程的概念。

1991年,他将以前面向Ada的工作扩展到整个面向对象设计领域。Booch 1993比较适合于系统的设计和构造。Rumbaugh等人提出了面向对象的建模技术(OMT)方法,采用了面向对象的概念,并引入各种独立于语言的表示符。

这种方法用对象模型、动态模型、功能模型和用例模型,共同完成对整个系统的建模,所定义的概念和符号可用于软件开发的分析、设计和实现的全过程,软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。

OMT-2特别适用于分析和描述以数据为中心的信息系统。

Jacobson于1994年提出了OOSE方法,其最大特点是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。

用例的概念是精确描述需求的重要武器,但用例贯穿于整个开发过程,包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。

此外,还有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向对象的分析和设计方法之一。

该方法简单、易学,适合于面向对象技术的初学者使用,但由于该方法在处理能力方面的局限,目前已很少使用。概括起来,首先,面对众多的建模语言,用户由于没有能力区别不同语言之间的差别,因此很难找到一种比较适合其应用特点的语言;其次,众多的建模语言实际上各有千秋;

第三,虽然不同的建模语言大多类同,但仍存在某些细微的差别,极大地妨碍了用户之间的交流。因此在客观上,极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上,组织联合设计小组,根据应用需求,取其精华,去其糟粕,求同存异,统一建模语言。

1994年10月,Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch93和OMT-2 统一起来,并于1995年10月发布了第一个公开版本,称之为统一方法UM 0.8(Unitied Method)。

1995年秋,OOSE 的创始人Ivar Jacobson加盟到这一工作。

经过Booch、Rumbaugh和Jacobson三人的共同努力,于1996年6月和10月分别发布了两个新的版本,即UML 0.9和UML 0.91,并将UM重新命名为UML(Unified Modeling Language)。

1996年,一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应,并倡议成立了UML成员协会,以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。

这一机构对UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定义和发布起了重要的促进作用。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。

它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

11.jpg (34869 bytes)

面向对象技术和UML的发展过程可用上图来表示,标准建模语言的出现是其重要成果。

在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。

1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML

1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。

2. 标准建模语言UML的内容首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且这些基本概念与其他面向对象技术中的基本概念大多相同,因而,UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言;其次,UML不仅仅是上述方法的简单汇合,而是在这些方法的基础上广泛征求意见,集众家之长,几经修改而完成的,UML扩展了现有方法的应用范围;第三,UML是标准的建模语言,而不是标准的开发过程。

尽管UML的应用必然以系统的开发过程为背景,但由于不同的组织和不同的应用领域,需要采取不同的开发过程。作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。

(1) UML语义　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。

(2) UML表示法　定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:

·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。

·第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。

不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。

一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。

包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。

·第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。

其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。

在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。

·第四类是交互图(Interactive diagram),描述对象间的交互关系。

其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。

除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。

·第五类是实现图( Implementation diagram )。

其中构件图描述代码部件的物理结构及各部件之间的依赖关系。

一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。

配置图定义系统中软硬件的物理体系结构。

它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。

在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。

其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。

其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。

因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

3. 标准建模语言UML的主要特点标准建模语言UML的主要特点可以归结为三点:

(1) UML统一了Booch、OMT和OOSE等方法中的基本概念。

(2) UML还吸取了面向对象技术领域中其他流派的长处,其中也包括非OO方法的影响。

UML符号表示考虑了各种方法的图形表示,删掉了大量易引起混乱的、多余的和极少使用的符号,也添加了一些新符号。因此,在UML中汇入了面向对象领域中很多人的思想。

这些思想并不是UML的开发者们发明的,而是开发者们依据最优秀的OO方法和丰富的计算机科学实践经验综合提炼而成的。

(3) UML在演变过程中还提出了一些新的概念。在UML标准中新加了模板(Stereotypes)、职责(Responsibilities)、扩展机制(Extensibility mechanisms)、线程(Threads)、过程(Processes)、分布式(Distribution)、并发(Concurrency)、模式(Patterns)、合作(Collaborations)、活动图(Activity diagram)等新概念,并清晰地区分类型(Type)、类(Class)和实例(Instance)、细化(Refinement)、接口(Interfaces)和组件(Components)等概念。

因此可以认为,UML是一种先进实用的标准建模语言,但其中某些概念尚待实践来验证,UML也必然存在一个进化过程。

4. 标准建模语言UML的应用领域UML的目标是以面向对象图的方式来描述任何类型的系统,具有很宽的应用领域。其中最常用的是建立软件系统的模型,但它同样可以用于描述非软件领域的系统,如机械系统、企业机构或业务过程,以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。

总之,UML是一个通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。此外,UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。在需求分析阶段,可以用用例来捕获用户需求。

通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。分析阶段主要关心问题域中的主要概念(如抽象、类和对象等)和机制,需要识别这些类以及它们相互间的关系,并用UML类图来描述。为实现用例,类之间需要协作,这可以用UML动态模型来描述。

在分析阶段,只对问题域的对象(现实世界的概念)建模,而不考虑定义软件系统中技术细节的类(如处理用户接口、数据库、通讯和并行性等问题的类)。这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更详细的规格说明。

编程(构造)是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时,应尽量避免考虑把模型转换成某种特定的编程语言。

因为在早期阶段,模型仅仅是理解和分析系统结构的工具,过早考虑编码问题十分不利于建立简单正确的模型。

UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。

不同的测试小组使用不同的UML图作为测试依据:单元测试使用类图和类规格说明;集成测试使用部件图和合作图;系统测试使用用例图来验证系统的行为;验收测试由用户进行,以验证系统测试的结果是否满足在分析阶段确定的需求。

总之,标准建模语言UML适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。

二、标准建模语言UML的静态建模机制

任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。

UML的静态建模 机制包括用例图(Use case diagram)、类图(Class diagram)、对象图(Object diagram )、包(Package)、构件图(Component diagram)和配置图(Deployment diagram)。

1. 用例图

(1) 用例模型(Use case model) 长期以来,在面向对象开发和传统的软件开发中,人们根据典型的使用情景来了解需 求。

但是,这些使用情景是非正式的,虽然经常使用,却难以建立正式文挡。用例模型由I var Jacobson在开发AXE系统中首先使用,并加入由他所倡导的OOSE和Objectory方法中。

用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后,面向 对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。

用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶 段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成 的共识。

首先,它描述了待开发系统的功能需求;

其次,它将系统看作黑盒,从外部执行者 的角度来理解系统;

第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保 证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的 各个阶段和 UML 的各个模型。

在UML中,一个用例模型由若干个用例图描述,用例图主要 元素是用例和执行者。

(2) 用例(use case) 从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。

以字处理软件为例 ,"将某些正文置为黑体"和"创建一个索引"便是两个典型的用例。在UML中,用例被定义成 系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。 21.jpg (39844 bytes)

在UML中,用例表示为一个椭圆。

图1显示了一个金融贸易系统的用例图。其中,"风险 分析","交易估价","进行交易","设置边界","超越边界的交易","评价贸易","更新帐目 "等都是用例的实例。

概括地说,用例有以下特点:

·用例捕获某些用户可见的需求,实现一个具体的用户目标。

·用例由执行者激活,并提供确切的值给执行者。

·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。

(3) 执行者(Actor) 执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。

图1中有四个 执行者:贸易经理、营销人员、售货员和记帐系统。在某些组织中很可能有许多营销人员 ,但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个执行者表示。

一个用户也可以扮演多种角色(执行者)。例如,一个高级营销人员既可以是贸易经理,也 可以是普通的营销人员;一个营销人员也可以是售货员。在处理执行者时,应考虑其作用 ,而不是人或工作名称,这一点是很重要的。

图1中,不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为 通信联系。执行者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反 过来,一个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:他 们可以从用例中取值,也可以参与到用例中。

需要注意的是,尽管执行者在用例图中是用类似人的图形来表示的,但执行者未必是 人。例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与 当前系统有进行交互。在图1中,我们可以看到,记帐系统是一个外界系统,它需要更新帐 目。

通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例 清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的用例,问题就 会变得容易很多。

(4) 使用和扩展(Use and Extend) 图1中除了包含执行者与用例之间的连接外,还有另外两种类型的连接,用以表示用例 之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。 当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。

例如图 1中,基本的用例是"进行交易"。 交易中可能一切都进行得很顺利,但也可能存在扰乱顺 利进行交易的因素。

其中之一便是超出某些边界值的情况。例如,贸易组织会对某个特定 客户规定最大贸易量,这时不能执行给定用例提供的常规动作,而要做些改动。我们可在 "进行交易"用例中做改动。但是,这将把该用例与一大堆特殊的判断和逻辑混杂在一起, 使正常的流程晦涩不堪。

图1中将常规的动作放在"进行交易"用例中,而将非常规的动作 放置于"超越边界的交易" 用例中,这便是扩展关系的实质。 当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用 关系。

例如,现实中风险分析和交易估价都需要评价贸易,为此可单独定义一个用例,即" 评价贸易",而"风险分析"和"交易估价"用例将使用它。 请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那 些公共的行为并放入一个单独用例中,而这个用例被其他几个用例使用或扩展。

但使用和 扩展的目的是不同的。

(5) 用例模型的获取 几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。

用例的获取 是需求分析阶段的主要任务之一,而且是首先要做的工作。大部分用例将在项目的需求分 析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集 中。

用例集中的每个用例都是一个潜在的需求。

a. 获取执行者 获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行 者。

以下问题可供参考:

·谁使用系统的主要功能(主要使用者)。

·谁需要系统支持他们的日常工作。

·谁来维护、管理使系统正常工作(辅助使用者)。

·系统需要操纵哪些硬件。

·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。

·对系统产生的结果感兴趣的人或事物。

b. 获取用例 一旦获取了执行者,就可以对每个执行者提出问题以获取用例。以下问题可供参考:

·执行者要求系统提供哪些功能(执行者需要做什么)?

·执行者需要读、产生、删除、修改或存储的信息有哪些类型。

·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样 把这些事件表示成用例中的功能?

·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现? 还有一些不针对具体执行者问题(即针对整个系统的问题):

·系统需要何种输入输出?输入从何处来?输出到何处?

·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?

需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知 道执行者是什么。

一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用 例的利用程度也不同。例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例 。

而在一个相同规模的项目中,Martin Fowler则用了一百多个用例。我们认为:任何合适 的用例都可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年 的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。

2. 类图、对象图和包 数千年以前,人类就已经开始采用分类的方法有效地简化复杂问题,帮助人们了解客 观世界。

在面向对象建模技术中,我们使用同样的方法将客观世界的实体映射为对象,并 归纳成一个个类。类(Class)、对象(Object)和它们之间的关联是面向对象技术中最基本 的元素。

对于一个想要描述的系统,其类模型和对象模型揭示了系统的结构。在UML中,类 和对象模型分别由类图和对象图表示。

类图技术是OO方法的核心。图1显示了一个金融保 险系统的类图。

31.jpg (35011 bytes)

(1) 类图 类图(Class Diagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了 信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。

在类图的基础上,状 态图、合作图等进一步描述了系统其他方面的特性。

(2) 类和对象 对象(Object)与我们对客观世界的理解相关。我们通常用对象描述客观世界中某个 具体的实体。

所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例( Instance)。建立类模型时,我们应尽量与应用领域的概念保持一致,以使模型更符合客观 事实,易修改、易理解和易交流。

类描述一类对象的属性(Attribute)和行为(Behavior)。在UML中,类的可视化表示为 一个划分成三个格子的长方形(下面两个格子可省略)。

图1中,"客户"就是一个典型的类 。 类的获取和命名　最顶部的格子包含类的名字。

类的命名应尽量用应用领域中的术 语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。

类的获取是一个依 赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析,抽象出领域中的概 念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。一般而言,类的 名字是名词。 类的属性　中间的格子包含类的属性,用以描述该类对象的共同特点。

该项可省略。

图1中"客户"类有"客户名"、"地址"等特性。属性的选取应考虑以下因素: *原则上来说,类的属性应能描述并区分每个特定的对象;

*只有系统感兴趣的特征才包含在类的属性中; *系统建模的目的也会影响到属性的选取。 根据图的详细程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约 束特性。

UML规定类的属性的语法为: 可见性　属性名 :　类型 = 缺省值　{约束特性} 图1"客户"类中,"客户名"属性描述为"- 客户名 : 字符串 = 缺省客户名"。

可见性 "-"表示它是私有数据成员,其属性名为"客户名",类型为"字符串"类型,缺省值为"缺省客 户名",此处没有约束特性。

不同属性具有不同可见性。常用的可见性有Public、Private和Protected三种,在U ML中分别表示为"+"、"-"和"#"。

类型表示该属性的种类。它可以是基本数据类型,例如整数、实数、布尔型等,也可 以是用户自定义的类型。一般它由所涉及的程序设计语言确定。

约束特性则是用户对该属性性质一个约束的说明。例如"{只读}"说明该属性是只读 属性。 类的操作(Operation)　该项可省略。操作用于修改、检索类的属性或执行某些动作 。

操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。操作 名、返回类型和参数表组成操作界面。

UML规定操作的语法为: 可见性 操作名 (参数表) : 返回类型 {约束特性} 在图1中,"客户"类中有"取客户地址"操作,其中" +"表示该操作是公有操作,调用时 需要参数"客户名",参数类型为字符串,返回类型也为字符串。 类图描述了类和类之间的静态关系。定义了类之后,就可以定义类之间的各种关系了 。

(3) 关联关系 关联(Association)表示两个类之间存在某种语义上的联系。例如,一个人为一家公 司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义 上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建 立关联关系。

在图1中最上部存在一个"属于"/"签定"关联:每个"保险单"属于一个"客户",而"客户 "可以签定多个"保险单"。除了这个关联外,图1中还有另外两个关联,分别表示每个"保险 单"包含若干个"保险单上的项目",而每个"保险单上的项目"涉及单一的"保险类别"。 关联的方向　关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向 ,在UML中称为导航(Navigability)。我们将只在一个方向上存在导航表示的关联,称作单 向关联 ( Uni-directional Association ),在两个方向上都有导航表示的关联,称作双 向关联 ( Bi-directional Association )。

图1中,"保险单"到"保险单上的项目"是单向 关联。UML规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选 择,因此,在图中应明确使用其中的一种选择。 关联的命名　既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字 ,这样的关联有两个名字,可以用小黑三角表示名字的方向(见图1中最上部的"属于"/"签 定"关联)。为关联命名有几种方法,其原则是该命名是否有助于理解该模型。 角色　关联两头的类以某种角色参与关联。

例如图2中,"公司"以"雇主"的角色,"人 "以"雇员"的角色参与的"工作合同"关联。"雇主"和"雇员"称为角色名。如果在关联上没 有标出角色名,则隐含地用类的名称作为角色名。角色还具有多重性(Multiplicity),表 示可以有多少个对象参与该关联。在图2中,雇主(公司)可以雇佣(签工作合同)多个雇员 ,表示为"*"; 雇员只能与一家雇主签定工作合同,表示为"1"。

多重性表示参与对象的数 目的上下界限制。"*"代表0～∞,即一个客户可以没有保险单,也可以有任意多的保险单 。

"1"是1..1的简写,即任何一个保险单仅来自于一个客户,可以用一个单个数字表示,也 可以用范围或者是数字和范围不连续的组合表示。 32.jpg (12355 bytes) 关联类　一个关联可能要记录一些信息,可以引入一个关联类来记录。

图3是在图2的 基础上引入了关联类。

关联类通过一根虚线与关联连接。

图4是实现上述目标的另外一种 方法,就是使雇用关系成为一个正式的类。 33.jpg (10497 bytes) 34.jpg (11499 bytes)

聚集和组成　聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是 整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是 聚集的一个例子。在需求分析中,"包含"、"组成"、"分为……部分"等经常设计成聚集关 系。聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。

例如,课题组包含许 多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之 为共享聚集。

另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会 随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和 显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为 实心菱形。

需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象 方法与UML中所定义的聚集的差别。

(4) 继承关系 人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。

例如,动 物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基 类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素 和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。如图1中, 将客户进一步分类成个体客户和团体客户,使用的就是继承关系。 在UML定义中对继承有三个要求:

*特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也 都隐含性地具有; *特殊元素还应包含额外信息;

*允许使用一般元素实例的地方,也应能使用特殊元素。

(5) 依赖关系 有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则 称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类 发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类 的界面改变,它发出的任何消息可能不再合法。

(6) 类图的抽象层次和细化(Refinement)关系 需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次 的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接 口;而在实现阶段,类图描述软件系统中类的实现。按照Steve Cook和John Dianiels的观 点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图 中显得更为突出。

概念层　概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这 些概念中得出,但两者并没有直接的映射关系。

事实上,一个概念模型应独立于实现它的 软件和程序设计语言。 说明层　说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分 。

面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这 一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受 到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现 。

实现层　只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部 分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的 相互理解和交流。 理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一 个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的 层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图 ,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部 分,但是它们对于建模或者评价模型非常有用。

尽管迄今为止人们似乎更强调实现层类图 ,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用。 下面介绍细化概念。细化是UML中的术语,表示对事物更详细一层的描述。

两个元素 A、B描述同一件事物,它们的区别是抽象层次不同,若元素B是在元素A的基础上的更详细 的描述,则称元素B细化了元素A,或称元素A细化成元素B。细化的图形表示为由元素B指向 元素A的、一头为空心三角的虚线(千万不要把方向颠倒了!)。细化主要用于模型之间的 合作,表示开发各阶段不同层次抽象模型的相关性,常用于跟踪模型的演变。

(7) 约束 在UML中,可以用约束(Constraint)表示规则。约束是放在括号"{ }"中的一个表达式 ,表示一个永真的逻辑陈述。在程序设计语言中,约束可以由断言(Assertion)来实现。

(8) 对象图、对象和链 UML中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象 是类的实例;对象之间的链(Link)是类之间的关联的实例。对象与类的图形表示相似,均 为划分成两个格子的长方形(下面的格子可省略)。上面的格子是对象名,对象名下有下划 线;下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂的类图的 一个实例。

(9) 包 一个最古老的软件方法问题是:怎样将大系统拆分成小系统。解决这个问题的一个思 路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。这个思 路被松散地应用到许多对象技术中。UML中这种分组机制叫包(Package)(见图5)。 35.jpg (15497 bytes)

不仅是类,任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组 ,分组方法就是任意的。

在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要 显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系 。

包的内容　在图5中,"系统内部"包由"保险单"包和"客户"包组成。这里称"保险单" 包和"客户"包为"系统内部"包的内容。当不需要显示包的内容时,包的名字放入主方框内 ,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列 表,也可以是另一个包图,还可以是一个类图。

包的依赖和继承　图5中"保险单填写界面"包依赖于"保险单"包;整个"系统内部"包 依赖于"数据库界面"包。

可以使用继承中通用和特例的概念来说明通用包和专用包之间 的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。通过"数据库界面"包 ,"系统内部"包既能够使用Oracle的界面也可使用Sybase的界面。通用包可标记为 {abs tract},表示该包只是定义了一个界面,具体实现则由专用包来完成。

(10) 其他模型元素和表示机制 类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。

主要还有以下模型符号和概念:类别模板(Stereotype)、界面(Interface)、参数化类(P arameterized Class)也称模板类(Template)、限定关联(Qualified Association)、多 维关联(N-ary Association)、多维链(N-ary Link)、派生(Derived)、类型(Type)和注 释(Note)等。

(11) 使用类图的几个建议 类图几乎是所有OO方法的支柱。采用标准建模语言UML进行建模时,必须对UML类图引 入的各种要素有清晰的理解。以下对使用类图进行建模提出几点建议:

*不要试图使用所有的符号。从简单的开始,例如,类、关联、属性和继承等概念。在 UML中,有些符号仅用于特殊的场合和方法中,只有当需要时才去使用。

*根据项目开发的不同阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层 类图;当开始着手软件设计时,应画说明层类图;当考察某个特定的实现技术时,则应画实 现层类图。

*不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关 键的图,经常使用并不断更新修改。 使用类图的最大危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概 念层和说明层。如果已经遇到了一些麻烦,可以从以下几个方面来反思你的模型。

*模型是否真实地反映了研究领域的实际。 *模型和模型中的元素是否有清楚的目的和职责(在面向对象方法中,系统功能最终是 分配到每个类的操作上实现的,这个机制叫职责分配)。

*模型和模型元素的大小是否适中。过于复杂的模型和模型元素是很难生存的,应将 其分解成几个相互合作的部分。

(12) 术语比较 下表列出了最常用的四种UML术语,并与其他方法学中相对应的术语进行比较,以帮助 读者了解UML与其他建模语言的异同。 3b1.jpg (38203 bytes)

41.jpg (23538 bytes)

3. 构件图和配置图 构件图(Component diagram)和配置图(Deployment diagram)显示系统实现时的一些 特性,包括源代码的静态结构和运行时刻的实现结构。构件图显示代码本身的结构,配置 图显示系统运行时刻的结构。

(1) 构件图 构件图显示软件构件之间的依赖关系。一般来说,软件构件就是一个实 际文件,可以是源代码文件、二进制代码文件和可执行文件等。可以用来显示编译、链接 或执行时构件之间的依赖关系。

(2) 配置图 配置图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。配置 图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含的 逻辑单元(对象、类)等。配置图常常用于帮助理解分布式系统。

(3) 结点和连接　结点(Node)代表一个物理设备以及其上运行的软件系统,如一台U nix主机、一个PC终端、一台打印机、一个传感器等。如图1所示,"客户端PC"和"保险后 台服务器"就是两个结点。结点表示为一个立方体,结点名放在左上角。 结点之间的连线表示系统之间进行交互的通信路径,在UML中被称为连接(Connectio n)。通信类型则放在连接旁边的"《》"之间,表示所用的通信协议或网络类型。

(4) 构件和界面　在配置图中,构件代表可执行的物理代码模块,如一个可执行程序 。逻辑上它可以与类图中的包或类对应。因此,配置图中显示运行时各个包或类在结点中 的分布情况。如在图1中,"保险后台服务器" 结点中包含"保险系统"、"保险对象数据库 "和"保险系统配置"3个构件。 在面向对象方法中,类和构件等元素并不是所有的属性和操作都对外可见。

它们对外 提供了可见操作和属性,称之为类和构件的界面。界面可以表示为一头是小园圈的直线。

图1中,"保险系统"构件提供了一个"配置"界面。配置图中还显示了构件之间的依赖关系 ,"保险系统配置"构件依赖于这个"配置"界面。

(5) 对象(Object)　一个面向对象软件系统中可以运行很多对象。由于构件可以看 作与包或类对应的物理代码模块,因此,构件中应包含一些运行的对象。配置图中的对象 与对象图中的对象表示法一样。

图1中,"保险系统配置"构件包含"配置保险政策"和"配置 用户"两个对象。

标准建模语言UML的静态建模机制是采用UML进行建模的基础。我们认为,熟练掌握基 本概念、区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的基本原则。

三、标准建模语言UML的动态建模机制

1. 消息 在面向对象技术中,对象间的交互是通过对象间消息的传递来完成的。

在UML的四个 动态模型中均用到消息这个概念。通常,当一个对象调用另一个对象中的操作时,即完成 了一次消息传递。

当操作执行后,控制便返回到调用者。

对象通过相互间的通信(消息传 递)进行合作,并在其生命周期中根据通信的结果不断改变自身的状态。

在UML中,消息的图形表示是用带有箭头的线段将消息的发送者和接收者联系起来,箭 头的类型表示消息的类型,如图2所示。

42.jpg (6565 bytes)

UML定义的消息类型有三种:

简单消息(Simple Message) 表示简单的控制流。用于描述控制如何在对象间进行传 递,而不考虑通信的细节。

同步消息(Synchronous Message) 表示嵌套的控制流。

操作的调用是一种典型的同 步消息。

调用者发出消息后必须等待消息返回,只有当处理消息的操作执行完毕后,调用 者才可继续执行自己的操作。

异步消息(Asynchronous Message) 表示异步控制流。

当调用者发出消息后不用等待 消息的返回即可继续执行自己的操作。

异步消息主要用于描述实时系统中的并发行为。

2. 状态图 状态图(State Diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的 事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。一个状态 图包括一系列的状态以及状态之间的转移。

(1) 状态　所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件 发生后,对象的状态将发生变化。

状态图中定义的状态有:初态、终态、中间状态、复合 状态。其中,初态是状态图的起始点,而终态则是状态图的终点。一个状态图只能有一个 初态,而终态则可以有多个。

中间状态包括两个区域:名字域和内部转移域,如图3所示。图中内部转移域是可选的 ,其中所列的动作将在对象处于该状态时执行,且该动作的执行并不改变对象的状态。 43.jpg (14490 bytes)

一个状态可以进一步地细化为多个子状态,我们将可以进一步细化的状态称作复合状 态。子状态之间有"或关系"和"与关系"两种关系。

或关系(如 图4)说明在某一时刻仅可 到达一个子状态。

例如,一个处于行驶状态的汽车,在"行驶"这个复合状态中有向前和向 后两个不同的子状态,在某一时刻汽车要么向前,要么向后。与关系( 如图5)说明复合状 态中在某一时刻可同时到达多个子状态(称为并发子状态)。具有并发子状态的状态图称 为并发状态图。

44.jpg (10880 bytes)

45.jpg (14108 bytes)

(2) 转移　状态图中状态之间带箭头的连线被称为转移。状态的变迁通常是由事件 触发的,此时应在转移上标出触发转移的事件表达式。如果转移上未标明事件,则表示在 源状态的内部活动执行完毕后自动触发转移。

3. 顺序图 顺序图(Sequence Diagram)用来描述对象之间动态的交互关系,着重体现对象间消息 传递的时间顺序。

顺序图存在两个轴:水平轴表示不同的对象,垂直轴表示时间。

顺序图 中的对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名。垂直虚线是对象的生 命线,用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息 来表示。消息的箭头指明消息的类型。

顺序图中的消息可以是信号(Signal)、操作调用或类似于C++中的RPC(RemoteProce dure Calls)和Java中的RMI(Remote Method Invocation)。当收到消息时,接收对象立即 开始执行活动,即对象被激活了。

通过在对象生命线上显示一个细长矩形框来表示激活。 消息可以用消息名及参数来标识。

消息也可带有顺序号,但较少使用。消息还可带有 条件表达式,表示分支或决定是否发送消息。如果用于表示分支,则每个分支是相互排斥 的,即在某一时刻仅可发送分支中的一个消息。

在顺序图的左边可以有说明信息,用于说明消息发送的时刻、描述动作的执行情况以 及约束信息等。一个典型的例子就是用于说明一个消息是重复发送的。

另外,可以定义两 个消息间的时间限制。

一个对象可以通过发送消息来创建另一个对象,当一个对象被删除或自我删除时,该 对象用"X"标识。

另外,在很多算法中,递归是一种很重要的技术。当一个操作直接或间接调用自身时 ,即发生了递归。

产生递归的消息总是同步消息,返回消息应是一个简单消息。

4. 合作图 合作图(Collaboration Diagram)用于描述相互合作的对象间的交互关系和链接关系 。

虽然顺序图和合作图都用来描述对象间的交互关系,但侧重点不一样。顺序图着重体现 交互的时间顺序,合作图则着重体现交互对象间的静态链接关系。

合作图中对象的外观与顺序图中的一样。如果一个对象在消息的交互中被创建,则可 在对象名称之后标以{new}。

类似地,如果一个对象在交互期间被删除,则可在对象名称之 后标以{destroy}。对象间的链接关系类似于类图中的联系(但无多重性标志)。通过在对 象间的链接上标志带有消息串的消息(简单、异步或同步消息)来表达对象间的消息传递 。

(1) 链接　链接用于表示对象间的各种关系,包括组成关系的链接(Composition Li nk)、聚集关系的链接(Aggregation Link)、限定关系的链接(Qualified Link)以及导航 链接(Navigation Link)。

各种链接关系与类图中的定义相同,在链接的端点位置可以显 示对象的角色名和模板信息。

(2) 消息流　在合作图的链接线上,可以用带有消息串的消息来描述对象间的交互。 消息的箭头指明消息的流动方向。

消息串说明要发送的消息、消息的参数、消息的返回 值以及消息的序列号等信息。

完


标准建模语言UML及其支持环境 (一)

编者按:
软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。其中最重要的、具有划时代重大意义的成果之一就是统一建模语言(UML:Unified Modeling Language)的出现。在世界范围内,至少在近10年内,UML将是面向对象技术领域内占主导地位的标准建模语言。采用UML作为我国统一的建模语言是完全必要的:首先,过去数十种面向对象的建模语言都是相互独立的,而UML可以消除一些潜在的不必要的差异,以免用户混淆;其次,通过统一语义和符号表示,能够稳定我国的面向对象技术市场,使项目根植于一个成熟的标准建模语言,从而可以大大拓宽所研制与开发的软件系统的适用范围,并大大提高其灵活程度。为使读者对UML语言及其支持环境有更深入、细致的了解,我们特邀北京航空航天大学软件工程研究所的专家撰文介绍,本文共分五个部分:
一、标准建模语言UML的概念 作者 张莉 周伯庄
二、标准建模语言UML的静态建模机制 作者 葛科杨顺祥
三、标准建模语言UML的动态建模机制 作者 王云葛科
四、标准建模语言UML支持环境 作者 周伯生 张莉
五、标准建模语言UML的应用实例 作者杨顺祥　王云
我们将以连载的形式分7次对上述内容进行介绍。

一、标准建模语言UML概述

面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终统一为大众所接受的标准建模语言。

1. 标准建模语言UML的出现
公认的面向对象建模语言出现于70年代中期。从1989年到1994年,其数量从不到十种增加到了五十多种。在众多的建模语言中,语言的创造者努力推崇自己的产品,并在实践中不断完善。但是,OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异,因而很难根据应用特点选择合适的建模语言,于是爆发了一场"方法大战"。90年代中,一批新方法出现了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。

Booch是面向对象方法最早的倡导者之一,他提出了面向对象软件工程的概念。1991 年,他将以前面向Ada的工作扩展到整个面向对象设计领域。Booch 1993比较适合于系统的设计和构造。Rumbaugh等人提出了面向对象的建模技术(OMT)方法,采用了面向对象的概念,并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型,共同完成对整个系统的建模,所定义的概念和符号可用于软件开发的分析、设计和实现的全过程,软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。OMT-2特别适用于分析和描述以数据为中心的信息系统。Jacobson于1994年提出了OOSE方法,其最大特点是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器,但用例贯穿于整个开发过程,包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。此外,还有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向对象的分析和设计方法之一。该方法简单、易学,适合于面向对象技术的初学者使用,但由于该方法在处理能力方面的局限,目前已很少使用。

概括起来,首先,面对众多的建模语言,用户由于没有能力区别不同语言之间的差别,因此很难找到一种比较适合其应用特点的语言;其次,众多的建模语言实际上各有千秋;第三,虽然不同的建模语言大多类同,但仍存在某些细微的差别,极大地妨碍了用户之间的交流。因此在客观上,极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上,组织联合设计小组,根据应用需求,取其精华,去其糟粕,求同存异,统一建模语言。

1994年10月,Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch9 3和OMT-2 统一起来,并于1995年10月发布了第一个公开版本,称之为统一方法UM 0.8(Un itied Method)。1995年秋,OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力,于1996年6月和10月分别发布了两个新的版本,即UML 0.9和UML 0.91,并将UM重新命名为UML(Unified Modeling Language)。1996年,一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应,并倡议成立了UML成员协会,以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Micr osoft、Oracle、Rational Software、TI以及Unisys。这一机构对UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定义和发布起了重要的促进作用。

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

图1 UML的发展历程

面向对象技术和UML的发展过程可用上图来表示,标准建模语言的出现是其重要成果。在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。

2. 标准建模语言UML的内容

首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且这些基本概念与其他面向对象技术中的基本概念大多相同,因而,UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言;其次,UML不仅仅是上述方法的简单汇合,而是在这些方法的基础上广泛征求意见,集众家之长,几经修改而完成的,UML扩展了现有方法的应用范围;第三,UML是标准的建模语言,而不是标准的开发过程。尽管UML的应用必然以系统的开发过程为背景,但由于不同的组织和不同的应用领域,需要采取不同的开发过程。
作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分
。
(1) UML语义　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
(2) UML表示法　定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。
标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:

·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
·第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。
·第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
·第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。
·第五类是实现图( Implementation diagram )。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

3. 标准建模语言UML的主要特点
标准建模语言UML的主要特点可以归结为三点:
(1) UML统一了Booch、OMT和OOSE等方法中的基本概念。
(2) UML还吸取了面向对象技术领域中其他流派的长处,其中也包括非OO方法的影响。UML符号表示考虑了各种方法的图形表示,删掉了大量易引起混乱的、多余的和极少使用的符号,也添加了一些新符号。因此,在UML中汇入了面向对象领域中很多人的思想。这些思想并不是UML的开发者们发明的,而是开发者们依据最优秀的OO方法和丰富的计算机科学实践经验综合提炼而成的。
(3) UML在演变过程中还提出了一些新的概念。在UML标准中新加了模板(Stereotyp es)、职责(Responsibilities)、扩展机制(Extensibility mechanisms)、线程(Thread s)、过程(Processes)、分布式(Distribution)、并发(Concurrency)、模式(Patterns) 、合作(Collaborations)、活动图(Activity diagram)等新概念,并清晰地区分类型(Ty pe)、类(Class)和实例(Instance)、细化(Refinement)、接口(Interfaces)和组件(Com ponents)等概念。

因此可以认为,UML是一种先进实用的标准建模语言,但其中某些概念尚待实践来验证,UML也必然存在一个进化过程(未完待续)。

标准建模语言UML及其支持环境(三)

4. 标准建模语言UML的应用领域

UML的目标是以面向对象图的方式来描述任何类型的系统,具有很宽的应用领域。其中最常用的是建立软件系统的模型,但它同样可以用于描述非软件领域的系统,如机械系统、企业机构或业务过程,以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之,UML是一个通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。此外,UML适用于系统开发过程中从需求规格描述到系统完成后测
试的不同阶段。在需求分析阶段,可以用用例来捕获用户需求。通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。分析阶段主要关心问题域中的主要概念(如抽象、类和对象等)和机制,需要识别这些类以及它们相互间的关系,并用UML类图来描述。为实现用例,类之间需要协作,这可以用UML动态模型来描述。在分析阶段,只对问题域的对象(现实世界的概念)建模,而不考虑定义软件系统中技术细节的类(如处理用户接口、数据库、通讯和并行性等问题的类)。这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更详细的规格说明。

编程(构造)是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时,应尽量避免考虑把模型转换成某种特定的编程语言。因为在早期阶段,模型仅仅是理解和分析系统结构的工具,过早考虑编码问题十分不利于建立简单正确的模型。

UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据:单元测试使用类图和类规格说明;集成测试使用部件图和合作图;系统测试使用用例图来验证系统的行为;验收测试由用户进行,以验证系统测试的结果是否满足在分析阶段确定的需求。

总之,标准建模语言UML适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。

二、标准建模语言UML的静态建模机制

任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。UML的静态建模机制包括用例图(Use case diagram)、类图(Class diagram)、对象图(Object diagram )、包(Package)、构件图(Component diagram)和配置图(Deployment diagram)。

1. 用例图

(1) 用例模型(Use case model)
长期以来,在面向对象开发和传统的软件开发中,人们根据典型的使用情景来了解需求。但是,这些使用情景是非正式的,虽然经常使用,却难以建立正式文挡。用例模型由Ivar Jacobson在开发AXE系统中首先使用,并加入由他所倡导的OOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。
用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。在UML中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。

(2) 用例(use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。以字处理软件为例,"将某些正文置为黑体"和"创建一个索引"便是两个典型的用例。在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。

图1 用例图

在UML中,用例表示为一个椭圆。图1显示了一个金融贸易系统的用例图。其中,"风险分析","交易估价","进行交易","设置边界","超越边界的交易","评价贸易","更新帐目"等都是用例的实例。概括地说,用例有以下特点:
·用例捕获某些用户可见的需求,实现一个具体的用户目标。
·用例由执行者激活,并提供确切的值给执行者。
·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。

(3) 执行者(Actor)
执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。图1中有四个执行者:贸易经理、营销人员、售货员和记帐系统。在某些组织中很可能有许多营销人员,但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个执行者表示。一个用户也可以扮演多种角色(执行者)。例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。在处理执行者时,应考虑其作用,而不是人或工作名称,这一点是很重要的。

图1中,不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。

需要注意的是执行者在用例图中是用类似人的图形来表示,尽管执行的,但执行者未必是人。例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。在图1中,我们可以看到,记帐系统是一个外界系统,它需要更新帐目。

通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。

(4) 使用和扩展(Use and Extend)
图1中除了包含执行者与用例之间的连接外,还有另外两种类型的连接,用以表示用例之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。例如图1中,基本的用例是"进行交易"。交易中可能一切都进行得很顺利,但也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。例如,贸易组织会对某个特定客户规定最大贸易量,这时不能执行给定用例提供的常规动作,而要做些改动。我们可在"进行交易"用例中做改动。但是,这将把该用例与一大堆特殊的判断和逻辑混杂在一起,使正常的流程晦涩不堪。图1中将常规的动作放在"进行交易"用例中,而将非常规的动作放置于"超越边界的交易" 用例中,这便是扩展关系的实质。当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用关系。例如,现实中风险分析和交易估价都需要评价贸易,为此可单独定义一个用例,即"评价贸易",而"风险分析"和"交易估价"用例将使用它。
请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中,而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。

(5) 用例模型的获取
几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。

a. 获取执行者
获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考:
·谁使用系统的主要功能(主要使用者)。
·谁需要系统支持他们的日常工作。
·谁来维护、管理使系统正常工作(辅助使用者)。
·系统需要操纵哪些硬件。
·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。
·对系统产生的结果感兴趣的人或事物。

b. 获取用例
一旦获取了执行者,就可以对每个执行者提出问题以获取用例。
以下问题可供参考:
·执行者要求系统提供哪些功能(执行者需要做什么)?
·执行者需要读、产生、删除、修改或存储的信息有哪些类型。
·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样把这些事件表示成用例中的功能?
·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现?
还有一些不针对具体执行者问题(即针对整个系统的问题):
·系统需要何种输入输出?输入从何处来?输出到何处?
·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?
需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的利用程度也不同。例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。而在一个相同规模的项目中,Martin Fowler则用了一百多个用例。我们认为:任何合适的用例都可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。

标准建模语言UML及其支持环境(三)

北京航空航天大学软件工程研究所

(接上期)
前两期所述主要内容如下:
一、标准建模语言UML概述
二、标准建模语言UML的静态建模机制
1. 用例图
2. 类图、对象图和包
数千年以前,人类就已经开始采用分类的方法有效地简化复杂问题,帮助人们了解客观世界。在面向对象建模技术中,我们使用同样的方法将客观世界的实体映射为对象,并归纳成一个个类。类(Class)、对象(Object)和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统,其类模型和对象模型揭示了系统的结构。在UML中,类和对象模型分别由类图和对象图表示。类图技术是OO方法的核心。图1显示了一个金融保险系统的类图。

(1) 类图
类图(Class Diagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上,状态图、合作图等进一步描述了系统其他方面的特性。
(2) 类和对象
对象(Object)与我们对客观世界的理解相关。我们通常用对象描述客观世界中某个具体的实体。所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例(Instance)。建立类模型时,我们应尽量与应用领域的概念保持一致,以使模型更符合客观事实,易修改、易理解和易交流。

类描述一类对象的属性(Attribute)和行为(Behavior)。在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。图1中,"客户"就是一个典型的类。

类的获取和命名　最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析,抽象出领域中的概念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。一般而言,类的名字是名词。

类的属性　中间的格子包含类的属性,用以描述该类对象的共同特点。该项可省略。图1中"客户"类有"客户名"、"地址"等特性。属性的选取应考虑以下因素:
*原则上来说,类的属性应能描述并区分每个特定的对象;
*只有系统感兴趣的特征才包含在类的属性中;
*系统建模的目的也会影响到属性的选取。
根据图的详细程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为:
可见性　属性名 :　类型 = 缺省值　{约束特性}
图1"客户"类中,"客户名"属性描述为"- 客户名 : 字符串 = 缺省客户名"。 可见性"-"表示它是私有数据成员,其属性名为"客户名",类型为"字符串"类型,缺省值为"缺省客户名",此处没有约束特性。
不同属性具有不同可见性。常用的可见性有Public、Private和Protected三种,在UML中分别表示为"+"、"-"和"#"。
类型表示该属性的种类。它可以是基本数据类型,例如整数、实数、布尔型等,也可以是用户自定义的类型。一般它由所涉及的程序设计语言确定。
约束特性则是用户对该属性性质一个约束的说明。例如"{只读}"说明该属性是只读属性。
类的操作(Operation)　该项可省略。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。UML规定操作的语法为:
可见性 操作名 (参数表) : 返回类型 {约束特性}
在图1中,"客户"类中有"取客户地址"操作,其中" +"表示该操作是公有操作,调用时需要参数"客户名",参数类型为字符串,返回类型也为字符串。
类图描述了类和类之间的静态关系。定义了类之后,就可以定义类之间的各种关系了。

(3) 关联关系
关联(Association)表示两个类之间存在某种语义上的联系。例如,一个人为一家公司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建立关联关系。
在图1中最上部存在一个"属于"/"签定"关联:每个"保险单"属于一个"客户",而"客户"可以签定多个"保险单"。除了这个关联外,图1中还有另外两个关联,分别表示每个"保险单"包含若干个"保险单上的项目",而每个"保险单上的项目"涉及单一的"保险类别"。

关联的方向　关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向,在UML中称为导航(Navigability)。我们将只在一个方向上存在导航表示的关联,称作单向关联 ( Uni-directional Association ),在两个方向上都有导航表示的关联,称作双向关联 ( Bi-directional Association )。图1中,"保险单"到"保险单上的项目"是单向关联。UML规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选择,因此,在图中应明确使用其中的一种选择。

关联的命名　既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字,这样的关联有两个名字,可以用小黑三角表示名字的方向(见图1中最上部的"属于"/"签定"关联)。为关联命名有几种方法,其原则是该命名是否有助于理解该模型。

角色　关联两头的类以某种角色参与关联。例如图2中,"公司"以"雇主"的角色,"人"以"雇员"的角色参与的"工作合同"关联。"雇主"和"雇员"称为角色名。如果在关联上没有标出角色名,则隐含地用类的名称作为角色名。角色还具有多重性(Multiplicity),表示可以有多少个对象参与该关联。在图2中,雇主(公司)可以雇佣(签工作合同)多个雇员,表示为"*"; 雇员只能与一家雇主签定工作合同,表示为"1"。多重性表示参与对象的数目的上下界限制。"*"代表0～∞,即一个客户可以没有保险单,也可以有任意多的保险单。"1"是1..1的简写,即任何一个保险单仅来自于一个客户,可以用一个单个数字表示,也可以用范围或者是数字和范围不连续的组合表示。

关联类　一个关联可能要记录一些信息,可以引入一个关联类来记录。图3是在图2的基础上引入了关联类。关联类通过一根虚线与关联连接。图4是实现上述目标的另外一种方法,就是使雇用关系成为一个正式的类。

聚集和组成　聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。在需求分析中,"包含"、"组成"、"分为……部分"等经常设计成聚集关系。聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之为共享聚集。另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为实心菱形。需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象方法与UML中所定义的聚集的差别。

(4) 继承关系
人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。例如,动物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。
如图1中,将客户进一步分类成个体客户和团体客户,使用的就是继承关系。
在UML定义中对继承有三个要求:
*特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也都隐含性地具有;

*特殊元素还应包含额外信息;
*允许使用一般元素实例的地方,也应能使用特殊元素。

(5) 依赖关系
有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类的界面改变,它发出的任何消息可能不再合法。

(6) 类图的抽象层次和细化(Refinement)关系
需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;而在实现阶段,类图描述软件系统中类的实现。按照Steve Cook和John Dianiels的观点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出。
概念层　概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系。事实上,一个概念模型应独立于实现它的软件和程序设计语言。
说明层　说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现。
实现层　只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。

理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部分,但是它们对于建模或者评价模型非常有用。尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用。

下面介绍细化概念。细化是UML中的术语,表示对事物更详细一层的描述。两个元素A、B描述同一件事物,它们的区别是抽象层次不同,若元素B是在元素A的基础上的更详细的描述,则称元素B细化了元素A,或称元素A细化成元素B。细化的图形表示为由元素B指向元素A的、一头为空心三角的虚线(千万不要把方向颠倒了!)。细化主要用于模型之间的合作,表示开发各阶段不同层次抽象模型的相关性,常用于跟踪模型的演变。

(7) 约束
在UML中,可以用约束(Constraint)表示规则。约束是放在括号"{}"中的一个表达式,表示一个永真的逻辑陈述。在程序设计语言中,约束可以由断言(Assertion)来实现。

(8) 对象图、对象和链
UML中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类的实例;对象之间的链(Link)是类之间的关联的实例。对象与类的图形表示相似,均为划分成两个格子的长方形(下面的格子可省略)。上面的格子是对象名,对象名下有下划线;下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂的类图的一个实例。

(9) 包
一个最古老的软件方法问题是:怎样将大系统拆分成小系统。解决这个问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。这个思路被松散地应用到许多对象技术中。UML中这种分组机制叫包(Package)(见图5)。

不仅是类,任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。
包的内容　在图5中,"系统内部"包由"保险单"包和"客户"包组成。这里称"保险单"包和"客户"包为"系统内部"包的内容。当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。
包的依赖和继承　图5中"保险单填写界面"包依赖于"保险单"包;整个"系统内部"包依赖于"数据库界面"包。可以使用继承中通用和特例的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。通过"数据库界面"包,"系统内部"包既能够使用Oracle的界面也可使用Sybase的界面。通用包可标记为{abs tract},表示该包只是定义了一个界面,具体实现则由专用包来完成。

(10) 其他模型元素和表示机制
类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。主要还有以下模型符号和概念:类别模板(Stereotype)、界面(Interface)、参数化类(P arameterized Class)也称模板类(Template)、限定关联(Qualified Association)、多维关联(N-ary Association)、多维链(N-ary Link)、派生(Derived)、类型(Type)和注释(Note)等。

(11) 使用类图的几个建议
类图几乎是所有OO方法的支柱。采用标准建模语言UML进行建模时,必须对UML类图引入的各种要素有清晰的理解。以下对使用类图进行建模提出几点建议:
*不要试图使用所有的符号。从简单的开始,例如,类、关联、属性和继承等概念。在UML中,有些符号仅用于特殊的场合和方法中,只有当需要时才去使用。
*根据项目开发的不同阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层类图;当开始着手软件设计时,应画说明层类图;当考察某个特定的实现技术时,则应画实现层类图。
*不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关键的图,经常使用并不断更新修改。使用类图的最大危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概念层和说明层。如果已经遇到了一些麻烦,可以从以下几个方面来反思你的模型。
*模型是否真实地反映了研究领域的实际。
*模型和模型中的元素是否有清楚的目的和职责(在面向对象方法中,系统功能最终是分配到每个类的操作上实现的,这个机制叫职责分配)。
*模型和模型元素的大小是否适中。过于复杂的模型和模型元素是很难生存的,应将其分解成几个相互合作的部分。

(12) 术语比较
下表列出了最常用的四种UML术语,并与其他方法学中相对应的术语进行比较,以帮助读者了解UML与其他建模语言的异同。(未完待续)

标准建模语言UML及其支持环境(四)

前三期所述主要内容如下:
一、标准建模语言UML概述
二、标准建模语言UML的静态建模机制
1. 用例图
2. 类图、对象图和包

3. 构件图和配置图
构件图(Component diagram)和配置图(Deployment diagram)显示系统实现时的一些特性,包括源代码的静态结构和运行时刻的实现结构。构件图显示代码本身的结构,配置图显示系统运行时刻的结构。

(1) 构件图构件图显示软件构件之间的依赖关系。一般来说,软件构件就是一个实际文件,可以是源代码文件、二进制代码文件和可执行文件等。可以用来显示编译、链接或执行时构件之间的依赖关系。
(2) 配置图配置图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。配置图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含的逻辑单元(对象、类)等。配置图常常用于帮助理解分布式系统。
(3) 结点和连接　结点(Node)代表一个物理设备以及其上运行的软件系统,如一台Unix主机、一个PC终端、一台打印机、一个传感器等。如图1所示,"客户端PC"和"保险后台服务器"就是两个结点。结点表示为一个立方体,结点名放在左上角。
结点之间的连线表示系统之间进行交互的通信路径,在UML中被称为连接(Connectio n)。通信类型则放在连接旁边的"《》"之间,表示所用的通信协议或网络类型。
(4) 构件和界面　在配置图中,构件代表可执行的物理代码模块,如一个可执行程序。逻辑上它可以与类图中的包或类对应。因此,配置图中显示运行时各个包或类在结点中的分布情况。如在图1中,"保险后台服务器" 结点中包含"保险系统"、"保险对象数据库"和"保险系统配置"3个构件。在面向对象方法中,类和构件等元素并不是所有的属性和操作都对外可见。它们对外提供了可见操作和属性,称之为类和构件的界面。界面可以表示为一头是小园圈的直线。图1中,"保险系统"构件提供了一个"配置"界面。配置图中还显示了构件之间的依赖关系,"保险系统配置"构件依赖于这个"配置"界面。
(5) 对象(Object)　一个面向对象软件系统中可以运行很多对象。由于构件可以看作与包或类对应的物理代码模块,因此,构件中应包含一些运行的对象。配置图中的对象与对象图中的对象表示法一样。图1中,"保险系统配置"构件包含"配置保险政策"和"配置用户"两个对象。

标准建模语言UML的静态建模机制是采用UML进行建模的基础。我们认为,熟练掌握基本概念、区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的基本原则。

三、标准建模语言UML的动态建模机制

1. 消息

在面向对象技术中,对象间的交互是通过对象间消息的传递来完成的。在UML的四个动态模型中均用到消息这个概念。通常,当一个对象调用另一个对象中的操作时,即完成了一次消息传递。当操作执行后,控制便返回到调用者。对象通过相互间的通信(消息传递)进行合作,并在其生命周期中根据通信的结果不断改变自身的状态。

在UML中,消息的图形表示是用带有箭头的线段将消息的发送者和接收者联系起来,箭头的类型表示消息的类型,如图2所示。

UML定义的消息类型有三种:

简单消息(Simple Message) 表示简单的控制流。用于描述控制如何在对象间进行传递,而不考虑通信的细节。
同步消息(Synchronous Message) 表示嵌套的控制流。操作的调用是一种典型的同步消息。调用者发出消息后必须等待消息返回,只有当处理消息的操作执行完毕后,调用者才可继续执行自己的操作。

异步消息(Asynchronous Message) 表示异步控制流。当调用者发出消息后不用等待消息的返回即可继续执行自己的操作。异步消息主要用于描述实时系统中的并发行为。

2. 状态图
状态图(State Diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。一个状态图包括一系列的状态以及状态之间的转移。

(1) 状态　所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。状态图中定义的状态有:初态、终态、中间状态、复合状态。其中,初态是状态图的起始点,而终态则是状态图的终点。一个状态图只能有一个初态,而终态则可以有多个。

中间状态包括两个区域:名字域和内部转移域,如图3所示。图中内部转移域是可选的,其中所列的动作将在对象处于该状态时执行,且该动作的执行并不改变对象的状态。

一个状态可以进一步地细化为多个子状态,我们将可以进一步细化的状态称作复合状态。子状态之间有"或关系"和"与关系"两种关系。或关系(如图4)说明在某一时刻仅可到达一个子状态。例如,一个处于行驶状态的汽车,在"行驶"这个复合状态中有向前和向后两个不同的子状态,在某一时刻汽车要么向前,要么向后。与关系( 如图5)说明复合状态中在某一时刻可同时到达多个子状态(称为并发子状态)。具有并发子状态的状态图称为并发状态图。

(2) 转移　状态图中状态之间带箭头的连线被称为转移。状态的变迁通常是由事件触发的,此时应在转移上标出触发转移的事件表达式。如果转移上未标明事件,则表示在源状态的内部活动执行完毕后自动触发转移。

3. 顺序图

顺序图(Sequence Diagram)用来描述对象之间动态的交互关系,着重体现对象间消息传递的时间顺序。顺序图存在两个轴:水平轴表示不同的对象,垂直轴表示时间。顺序图中的对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名。垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息来表示。消息的箭头指明消息的类型。

顺序图中的消息可以是信号(Signal)、操作调用或类似于C++中的RPC(RemoteProce dure Calls)和Java中的RMI(Remote Method Invocation)。当收到消息时,接收对象立即开始执行活动,即对象被激活了。通过在对象生命线上显示一个细长矩形框来表示激活。

消息可以用消息名及参数来标识。消息也可带有顺序号,但较少使用。消息还可带有条件表达式,表示分支或决定是否发送消息。如果用于表示分支,则每个分支是相互排斥的,即在某一时刻仅可发送分支中的一个消息。

在顺序图的左边可以有说明信息,用于说明消息发送的时刻、描述动作的执行情况以及约束信息等。一个典型的例子就是用于说明一个消息是重复发送的。另外,可以定义两个消息间的时间限制。

一个对象可以通过发送消息来创建另一个对象,当一个对象被删除或自我删除时,该对象用"X"标识。

另外,在很多算法中,递归是一种很重要的技术。当一个操作直接或间接调用自身时,即发生了递归。产生递归的消息总是同步消息,返回消息应是一个简单消息。

4. 合作图

合作图(Collaboration Diagram)用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和合作图都用来描述对象间的交互关系,但侧重点不一样。顺序图着重体现交互的时间顺序,合作图则着重体现交互对象间的静态链接关系。

合作图中对象的外观与顺序图中的一样。如果一个对象在消息的交互中被创建,则可在对象名称之后标以{new}。类似地,如果一个对象在交互期间被删除,则可在对象名称之后标以{destroy}。对象间的链接关系类似于类图中的联系(但无多重性标志)。通过在对象间的链接上标志带有消息串的消息(简单、异步或同步消息)来表达对象间的消息传递。

(1) 链接　链接用于表示对象间的各种关系,包括组成关系的链接(Composition Li nk)、聚集关系的链接(Aggregation Link)、限定关系的链接(Qualified Link)以及导航链接(Navigation Link)。各种链接关系与类图中的定义相同,在链接的端点位置可以显示对象的角色名和模板信息。

(2) 消息流　在合作图的链接线上,可以用带有消息串的消息来描述对象间的交互。消息的箭头指明消息的流动方向。消息串说明要发送的消息、消息的参数、消息的返回值以及消息的序列号等信息(未完待续)。

标准建模语言UML及其支持环境(五)

前4期的主要内容包括:
一、标准建模语言UML概述
二、标准建模语言UML的静态建模机制
三、标准建模语言UML的动态建模机制
1. 消息
2. 状态图
3. 顺序图
4. 合作图
(接上期)
5. 活动图(Activity Diagram)

活动图的应用非常广泛,它既可用来描述操作(类的方法)的行为,也可以描述用例和对象内部的工作过程。活动图是由状态图变化而来的,它们各自用于不同的目的。活动图依据对象状态的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。图1给出了一个活动图的例子。

活动和转移

一项操作可以描述为一系列相关的活动。活动仅有一个起始点,但可以有多个结束点。活动间的转移允许带有guard-condition、send-clause和action-expression,其语法与状态图中定义的相同。一个活动可以顺序地跟在另一个活动之后,这是简单的顺序关系。如果在活动图中使用一个菱形的判断标志,则可以表达条件关系(见图1),判断标志可以有多个输入和输出转移,但在活动的运作中仅触发其中的一个输出转移。

活动图对表示并发行为也很有用。在活动图中,使用一个称为同步条的水平粗线可以将一条转移分为多个并发执行的分支,或将多个转移合为一条转移。此时,只有输入的转移全部有效,同步条才会触发转移,进而执行后面的活动,如图2所示。

泳道
活动图告诉你发生了什么,但没有告诉你该项活动由谁来完成。在程序设计中,这意味着活动图没有描述出各个活动由哪个类来完成。泳道解决了这一问题。它将活动图的逻辑描述与顺序图、合作图的责任描述结合起来。如图2所示,泳道用矩形框来表示,属于某个泳道的活动放在该矩形框内,将对象名放在矩形框的顶部,表示泳道中的活动由该对象负责。
对象
在活动图中可以出现对象。对象可以作为活动的输入或输出,对象与活动间的输入/输出关系由虚线箭头来表示。如果仅表示对象受到某一活动的影响,则可用不带箭头的虚线来连接对象与活动,如图2所示。
信号
如图3所示,在活动图中可以表示信号的发送与接收,分别用发送和接收标志来表示。发送和接收标志也可与对象相连,用于表示消息的发送者和接收者。

6. 四种图的运用
上面对UML中用于描述系统动态行为的四个图(状态图、顺序图、合作图和活动图)做了简单地介绍。这四个图均可用于系统的动态建模,但它们各自的侧重点不同,分别用于不同的目的。下面对如何正确使用这几个图做一简单的总结,在实际的建模过程中要根据具体情况灵活运用这些建议。

首先,不要对系统中的每个类都画状态图。尽管这样做很完美,但太浪费精力,其实你可能只关心某些类的行为。正确的做法是:为帮助理解类而画它的状态图。状态图描述跨越多个用例的单个对象的行为,而不适合描述多个对象间的行为合作。为此,常将状态图与其它技术(如顺序图、合作图和活动图)组合使用。

顺序图和合作图适合描述单个用例中几个对象的行为。其中顺序图突出对象间交互的顺序,而合作图的布局方法能更清楚地表示出对象之间静态的连接关系。当行为较为简单时,顺序图和合作图是最好的选择。但当行为比变复杂时,这两个图将失去其清晰度。因此,如果想显示跨越多用例或多线程的复杂行为,可考虑使用活动图。另外,顺序图和合作图仅适合描述对象之间的合作关系,而不适合对行为进行精确定义,如果想描述跨越多个用例的单个对象的行为,应当使用状态图。

四、标准建模语言UML支持环境

标准建模语言UML定义良好、易于表达、功能强大,不仅支持面向对象的分析与设计,而且支持从需求分析开始的软件开发的全过程。但如何恰当地将这种可视化图形建模技术用于解决软件开发所面临的问题,如何研制和开发支持UML的建模过程及其支持环境,仍是目前该领域的热点问题。

目前,在基于UML的开发方法和环境方面,国际上已经进行了一些研究和实际开发工作。Rational 公司正致力于它称之为Objectory过程的研究,并试图将其原有支持OMT的工具作进一步扩充,以期支持UML建模。国内对UML支持环境的研制开发工作尚处于起步阶段。

这里从当前对软件开发过程的需求及其动向出发,提出了UML柔性软件开发过程的概念,并设计了相应的UML集成化支持环境的组成框架。
1. 过程工程的基本要点
任何语言的支持环境都是为了更好地开发计算机应用系统,而任何计算机应用系统又都是为一定的企事业的目标服务的。因此计算机应用系统及其支持环境的研制与开发,必须在企事业过程工程理论的指导下进行。下面根据我们近十年来从事过程工程理论研究与正反两方面的实际经验,扼要介绍过程工程理论和过程工程环境的基本要点。
(1) 任何企事业都可以也都应该从过程、资源、机构、行为和信息等五方面来描述。其中过程是指该企事业所进行的活动及其活动间的关系,它有一个包含规划、设计、建造和应用等四个阶段呈螺旋特征的生命周期。刻划一个企事业模型,首先必须研究这五个方面模型的定量描述技术及其相互关系的约束理论,并研究其描述技术及约束理论在四个不同阶段中的演变情况,建立系统动力学模型,为采用模拟技术解决上述五个方面模型的综合集成与整体优化奠定理论基础。
(2) 任何企事业中的过程都可划分为纵向过程与横向过程两类。纵向过程是以产品工程技术为核心的逐步发展的硬技术群,横向过程是以产品和过程的管理技术为主体的服务于纵向过程的软技术群。因此要刻划一个企事业过程,还必须研究纵向过程与横向过程的定性模型与定量度量技术,研究这两类过程的相互关系,以建立产品开发和管理过程相结合的集成化综合模型,为采用模拟技术研究硬技术群与软技术群的相互之间的量化关系奠定理论基础。
(3) 在瞬息万变的信息化社会中,由于客观环境(系统的外部参数)和主观实体(系统的内部结构及状态)均具有动态的性质,系统模型的结构、状态及其计算机支持环境也应随之而变化。为此,要研究面向对象技术在过程工程中的应用技术,把软件工程、过程工程和企事业工程结合起来,为建立自适应的过程工程支持环境奠定理论基础。我们不妨把软件工程、过程工程、企事业工程三者结合起来进行综合考察的工程技术称之为聚合工程,把自适应的计算机支持环境称之为柔性信息系统。
(4) 过程的规模可大可小,过程的持续时间可长可短。因此要研究既能支持过程的横向划块(将过程规模较大的系统划分成若干个规模较小的子系统)、又能支持过程的纵向分段(将持续时间较长的过程划分成几个持续时间较短的子过程)的分割与综合技术,研究资源的动态调度技术以及模型的局部实例化与局部模拟技术,为采用模拟技术研究大范围、长周期的复杂动力学系统奠定技术基础。

由以上理论可知,任何语言的支持环境必须满足这些基本的技术设施,这就是我们研制与开发标准建模语言UML支持环境的基本出发点。在这些基本点中,特别值得注意的是前三条,即聚合工程和柔性信息系统的概念。

2. UML柔性软件开发过程及其支持环境
(1) UML柔性软件开发过程
软件系统的规模越来越大,复杂程度不断提高,传统的软件开发模式越来越难以满足需求。新的产品开发周期已不再是从需求定义、软件设计、实现和交付的一次性过程,迭代式增量开发方式已得到了广泛采用。除了传统概念上的时间、质量和花费三个主要要求外,产品支持系统的"柔性"成为更加重要的核心需求。因此我们将新的软件开发模式归结为图4所示的迭代式开发和图5所示的柔性软件开发模型。

所谓柔性软件开发是指软件开发过程应在需求工程的牵引下,首先建立系统的顶层模型,并对其进行模拟、分析和调整。次之,将顶层模型自顶向下地进行分解,建立该系统各个子系统的模型,对这些子模型进行模拟、分析和调整。然后将子模型的模拟结果,逐次代入上层,再对该上层模型进一步进行模拟、分析和调整,如有不适,则进行修改。因此整个建模过程是一个"自顶向下建模,由底向上修改"的反复迭代的过程。简言之,柔性软件开发过程是一个在需求牵引下,自顶向下分层细化地建模,然后按照"T型技术",通过对模型的虚拟执行,由底向上地逐层上移修改,直至各层的模拟结果都满足需求为止。

代码的生成建立在模型正确性的基础上,同时考虑到对需求修改的灵活性和快速响应能力,实施能够反馈修改的"闭环开发"。即不仅能支持从模型到代码的自动生成,将新的模型转换为代码,还能支持从代码到模型的逆向变换,将原有的代码转化成模型,进行再次分析、修改和调整以及新一轮的开发,从而为增量式开发提供支持。这样不仅能做到分阶段提交产品,也提高了对用户需求变化的响应速度和应变能力,以满足用户不断变化的新的需求。

(2) UML支持环境的基本需求
根据上述理论以及我们十五年来研制与开发集成化软件工程环境正反两方面的经验,一个完善的集成化过程工程环境在功能上应满足以下基本需求:
·应能支持开发完备的过程模型(即应能从过程、资源、机构、行为和信息等五个侧面来描述企事业过程)与系统模型(即应能从过程、行为、信息和结构等四个侧面来描述一个系统)。
·在这个环境支持下建立的模型应是一个可执行的过程(系统)模型,即应能支持模型的虚拟执行(模拟)和实际运作,从而可在不同的层次上对模型进行分析和优化。
·过程(系统)模型应采用可视化的图符与正文描述相结合的表达方式,其可视化模型图的结构应能客观、自然地反映出企事业各部门间的通信和同步关系。
·应能支持建模人员或管理人员按照企事业(系统)内外部的约束条件对模型的执行进行灵活的控制,从而实现开发过程与管理过程的交叉。
·应能支持从模型自动生成可在Internet上运行且支持多平台共享与多数据库存取的应用系统,从而实现对第三代过程工程自动化的有力支持。
·还应能支持对各类构件库的灵活管理,支持基于构件的程序设计方法,实现过程构件、需求描述、系统结构与软件构件的复用和组装。

UML集成化支持环境应对集成化过程工程环境和集成化系统工程环境提供强有力的技术支持。一方面在功能与接口上三者必须无缝连接,另一方面在风格上三者必须协调一致。在分工上,过程工程环境的目标是优化过程,系统工程环境的目标是自动产生优化了的计算机应用系统,UML支持环境的目标是为建成柔性的计算机应用系统提供技术支持。(未完待续)

标准建模语言UML及其支持环境(六)

前五期所述主要内容如下:
一、标准建模语言UML概述
二、标准建模语言UML的静态建模机制
三、标准建模语言UML的动态建模机制
四、标准建模语言UML的支持环境
1. 过程工程的基本要点
2. UML柔性软件开发过程及其支持环境

(接上期)
3. UML集成化支持环境
UML集成化支持环境是在需求牵引下支持建造柔性信息系统的系统开发环境,其组成应包括UML可视化建模系统、模拟系统、代码生成系统、逆向变换系统、质量控制系统及其支持软件等。这些环境均应基于UML的语法规则和语义定义,如图1所示。由此可知,这个支持环境是一个能支持系统建模、系统模拟和系统生成的"闭环式开发"的集成化支持环境。

(1) UML可视化建模系统的框架
UML可视化建模系统支持从系统需求、系统分析到系统设计的整个建模过程,提供UM L图形的编辑和美化工具,保证得到语法正确、语义完整的UML图形模型,并提供包括文档管理和图形打印等辅助支持。
支持环境的建模机制
由于UML不仅支持对系统的对象建模,还支持对需求和系统体系结构的建模,不仅支持建立系统的静态模型,还支持描述系统的动态模型,因此,模型建造系统应支持以下模型的创建和编辑:
需求模型　包括静态模型和动态模型。静态模型即功能模型,在UML中通过用例图描述系统功能和各功能的潜在用户及它们之间的关系。动态模型通过活动图支持对业务过程或事务处理过程的描述。
系统对象模型　包括静态模型和动态模型。通过包图、类图和对象图定义系统对象及对象间的静态关系;通过顺序图、合作图和状态图描述对象间的交互关系、对象的生命周期以及生命周期中对象可能存在的状态和状态间的转换约束。
系统体系结构模型　通过组件图和配置图支持软件体系结构和硬件体系结构以及通信机制的定义。同时,还应进一步支持软硬件系统之间的合作关系的可视化表示。

建模系统的检测机制
UML语法正确性检测机制　为保证所得到的UML图形模型符合其语法定义,应提供语法正确性检测机制。一个较好的方法是提供语法制导的UML可视化建模工具,在模型的建造过程中提供动态的语法制导和语法检测功能。这样,既可方便用户学习和使用,也可保证所建造的模型在语法结构上的正确性。
UML模型的一致性检查机制　由于UML支持从需求分析到系统设计整个建模过程,并且支持用户从不同的角度描述系统,而大型软件项目各模型间的协作和约束关系错综复杂,显然不应由用户独自承担对它们的管理和维护工作。作为建模支持系统,应提供模型间的一致性检查机制。

首先,该机制应根据以上对基于UML软件开发模型的讨论,在软件开发阶段时间轴上确定引入模型的时间;其次,明确同一种模型的细化分层机制,以及怎样用其他模型描述主模型的细节;第三,在软件开发阶段时间轴上,一个模型存在自顶向下分解的层次结构,在各时间阶段产生的层次结构中,各种UML模型相互约束、协作又产生复杂的网状关系,需要建立不同阶段、不同功能的同一种模型与不同种模型约束和协作的数学模型;最后,在该数学模型的基础上,研究将约束和协作关系有机地加入软件开发各个阶段的模型一致性检查机制。此外,由于允许从不同的角度描述同一模型,如交互图包括顺序图和合作图,这两者之间允许存在冗余信息,因此,不仅应保证两者间信息的一致性,还可考虑支持模型间的一致性转换。

UML模型的完备性检查机制　完备性检查机制须在UML语义定义的基础上,首先定义UML图形模型的完备性准则,以保证UML图形模型的完备性。UML图形模型的完备性可分三个层次来考虑,即:各个图形的完备性;各个子模型的完备性,也就是相关图形的组合完备性;系统模型的整体完备性。区分这三种完备性的意义在于:在不同阶段可以进行语义完备性和语义正确性检查。
文档生成和管理工具　文档生成工具是指文档自动生成机制。作为一个建模支持系统,应支持包括需求描述、面向对象分析和设计、系统体系结构等文档资料的自动生成。文档管理工具是指文档资料的版本管理等辅助管理工作。

(2) UML模拟系统

系统模拟机制支持对UML模型的功能模拟和性能模拟,它包括以下三个部分:

动态模型的模拟　主要包括对活动模型、交互模型(顺序图和合作图)以及状态图的模拟。根据预先定义的语义,模拟各个模型对系统在时间特性上的描述是否真实地反映了客观现实和用户需求,并应提供相应的跟踪调试机制。
系统功能(需求)和用户界面的模拟　借助于代码自动生成工具和用户界面自动生成工具的支持,产生系统原型,并尽早提供给用户,以确保建模的有效性。
系统性能的模拟　作为一个良好的建模和开发支持工具,以支持对系统体系结构的建模,即在不同系统配置和功能分配的情况下,对系统性能进行模拟,以便得到优化的系统设计方案和合理的系统配置。

(3) UML代码生成系统

UML集成化支持环境应能支持可视化对象和行为的代码生成。UML代码生成系统也称之为UML支持环境的正向变换系统。众所周知,软件开发的最终目的是产生可执行代码。在大多数软件开发环境中,建模和编码过程缺少有机的统一,这是有其历史原因的。其中最重要的原因是缺少功能强大、简单清楚、标准统一的建模语言。UML的出现以及被OMG接受为标准,为消除这个障碍提供了一个很好的起点。

在UML语言的代码生成机制方面,国际上一些大公司做了有益的研究和开发工作,比较有代表性的是Rational公司和Advanced Software Technologies Inc.。但这些研究和实现大多限于UML静态模型中的类图,其他有关模型代码自动生成机制的研究资料则非常罕见。

我们认为,代码自动生成机制应根据UML语言多种模型动态协作、关系复杂的特点,首先界定UML的语义和面向对象编程语言(首先是Java)的语义,研究专用语义机制描述面向对象模型和语言中动态与静态机制,建立两者的语义模型。然后,再在该语义模型下建立两者的映射模型,并研究代码自动生成实现技术和独立于UML语言本身的编程语言的特殊机制。代码自动生成机制在研究与实现时,还应考虑后面逆向转换机制的需求。

(4) UML软件质量控制

软件系统的质量往往是大型、复杂系统成败的关键。软件系统质量难以保证的主要原因首先是软件系统固有的复杂性。但人们往往对这一点尚未有足够的认识,而把软件系统的复杂程度看得过低。另外一个原因是由于软件系统及其管理工作固有的不可见性。采用定量软件工程有利于改善可见性,但是还不可能做到完全透明。因此,在当代软件技术水平的前提下,建造软件质量控制环境势在必行。学术界与工业界对软件质量工程的看法主要划分为两个流派,一个叫"产品足够优质"(Good-Enough),另一个叫"无差错软件"( Error-Free)。
在建造软件质量控制环境时,除了应建造通用软件过程管理环境(包括软件项目管理、软件配置管理和软件质量管理)、软件过程支持环境(以支持软件开发单位成熟度模型CMM、个体软件过程PSP和支持群组软件过程TSP的实现)外,还应包含相互联系但可分别独立使用的三个子环境:

集成化软件测试环境　这个环境应包括软件需求覆盖测试工具、源程序覆盖测试工具、软件回归测试工具、软件测试管理工具和内存负载检测工具等。
集成化软件质量度量环境　度量有关软件质量的原始数据,并据此来计算ISO软件度量标准中所需要的管理度量元。
软件产品质量综合评测系统　从上述诸方面因素对软件产品的质量进行综合考虑,把所得到的数据进行加权综合。只有满足整体要求的软件才被认为是一个合格的软件产品。

(5) UML逆向变换系统
当用户对生成的代码进行修改后,逆向转换机制将用户的修改转换到模型上。否则,将造成模型和代码间的不一致性,使系统的扩充、增删和维护难以进行。
我们认为,如果一个支持环境既有正向变换机制,又有逆向变换机制,就能保持模型和代码的一致性。动态模型的逆向转换机制是研究难点,一般可由建模、析取和抽象三个步骤组成。我们将在正向转换的基础上,建立起模型到代码的映射关系,尝试建立一套约束机制,实现自动的或人工导引的逆向转换机制。目前,国际上对这方面的研究尚不成熟。

五、标准建模语言UML的应用实例

UML是一种建模语言而不是方法,这是因为UML中没有过程的概念,而过程正是方法的一个重要组成部分。UML本身独立于过程,这意味着用户在使用UML进行建模时,可以选用任何适合的过程。过程的选用与软件开发过程的不同因素有关,诸如所开发软件的种类(如实时系统、信息系统和桌面产品)、开发组织的规模(如单人开发、小组开发和团队开发)等。用户将根据不同的需要选用不同的过程。然而,使用UML建模仍然有着大致统一的过程框架,该框架包含了UML建模过程中的共同要素,同时又为用户选用与其所开发的工程相适合的建模技术提供了很大的自由度。

1. UML建模过程高层视图

图2是UML建模过程的一个高层视图。这是一个迭代递增的开发过程。使用此方法,不是在项目结束时一次性提交软件,而是分块逐次开发和提交。构造阶段由多次迭代组成,每一次迭代都包含编码、测试和集成,所得产品应满足项目需求的某一子集,或提交给用户,或纯粹是内部提交。每次迭代都包含了软件生命周期的所有阶段。同时,每次迭代都要增加一些新的功能,解决一些新的问题。

因此,首先要做的工作是:选择一些功能点,然后完成这些功能;之后再选择别的功能点,如此循环往复。前两个阶段是初始( Inception)和细化 ( Elaboration) 阶段。在初始阶段,需要考虑项目的效益,并确定项目的范围。这一阶段需要与项目出资方进行讨论。在细化阶段,需要收集更为详细的需求,进行高层分析和设计,并为构造阶段制定计划。运用这种迭代开发过程时,还有一些工作(如β测试、性能调试和用户培训等)要放到最后的移交阶段(Transition)中进行。

事实上,涉及实际建模工作的微过程存在于上述的每次迭代中。迭代式开发是项目成功的重要保证。

2. UML实际建模过程

每次迭代都分为以下几个阶段:
分析阶段　建模的目的是捕捉系统的功能需求,分析、提取所开发系统的"客观世界"领域的类以及描述它们的合作概貌。
设计阶段　建模的目的是通过考虑实现环境,将分析阶段的模型扩展和转化为可行的技术实现方案。
实现阶段　具体工作就是进行编码,同时对已构造的模型作相应的修正。
配置阶段　通过模型描述所开发系统的软硬件配置情况。
测试阶段　使用前几个阶段所构造的模型来指导和协助测试工作。

在系统开发的不同阶段,使用UML为系统建模,可以通过建立不同的模型,从不同的视角,以不同的详略程度对系统进行描述。下面以一个商业管理信息系统的开发过程为例,具体介绍UML建模的实际过程:
(1) 需求
最初版本商业MIS的正文需求规格说明应当由代表系统最终用户的人员提供,内容包括系统基本功能需求和对计算机系统的要求。大致描述如下:
· 它是一个商业支持系统;
· 采购员采购所需的商品;
· 保管员将采购的商品登记入库;
· 调拨员将库存商品调拨到相应的销售部门;
· 销售部门销售商品;
· 统计部门核算商场经营状况;
· 系统能运行于通用的技术环境(如Unix、Windows等)中,具有
良好的图形用户界面
· 系统容易维护,便于功能扩充 。
由于基于UML的系统开发采取增量和迭代方式,商业MIS的初始版本仅需要完成系统的最基本功能(基本业务),而其他功能的实现(如商品移管、电子订货、电子支付、网络销售等)则在以后的版本中完成。

(2) 分析
分析的任务是找出系统的所有需求并加以描述,同时建立模型,以定义系统中的关键领域类,应由系统用户和开发人员合作完成。这一阶段不要拘泥于设计细节和技术方案。

需求分析
分析的第一步是定义用例,以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明,此时需要与系统的潜在用户进行讨论。用例模型的主要构件是用例、角色和系统边界。用例用于描述每个功能需求,系统边界用于界定系统功能范围,而角色用于描述与系统功能有关的外部实体,它可以是用户,也可以是外部系统。
在本实例中,通过分析,先确认商业MIS中的角色有销售人员、库存人员、采购人员、辅助人员和分析人员。在此基础上,确认用例。商业MIS的用例有订货采购、库存管理、商品销售、统计分析、系统维护(包括增加商品、取消商品、制作标签、价格变更、取消或更新标签)。如图3所示。

除了用用例图描述系统需求外,还可以用文字(或活动图)对每个用例进行需求说明,更具体地描述该用例与角色的交互。例如我们可以描述订货采购用例的需求说明如下:
· 如果是新商品:
a. 新商品登记;
b. 采购进货;
c. 登记入库 。
· 如果商品库存不足:
a. 采购进货;
b. 登记入库。
订货采购需求可以用活动图来描述,如图4所示。由于用例的需求说明直接影响到后续设计阶段对类的操作的定位,因此,用例的需求说明应当尽量全面、准确。

值得说明的是,绝大多数用例可以在系统需求分析阶段确定,但随着系统的进展,可能会发现更多的用例,甚至会发现前面定义的用例存在不够确切或错误的地方,需要重新修改。因此,在整个系统开发过程中,都应当时刻关注用例。

特定领域分析
分析阶段的另一项工作是特定领域分析,以列出系统中的特定领域类。我们可以通过阅读规格说明、用例以及寻找系统处理的"概念"来进行特定领域分析,也可以通过用户和领域专家的讨论,以识别出要处理的所有关键类及它们的相互关系。这里的特定领域是指具体的商业领域,而不是整个系统领域。
在本实例中,可以确定商业MIS中的特定领域类为商品、保质商品、非保质商品、物品、销售、订货、库存、厂商,并使用类图来描述系统领域类及其关系。
需要强调的是,这一阶段对特定领域类的描述具有一定的素描性质,也就是说特定领域类的操作和属性不一定与最终实现时的定义一致。因为此时还没有涉及到系统功能的具体实现,不可能准确、完整地定义它们。有一些操作需要在设计阶段细化时才能确定。
此外,为了描述领域类的动态行为,可以使用UML中的任何一种动态图(如顺序图、活动图、合作图、状态图)。本阶段的各动态图都具有素描性质,主要是为了协助对领域类及其相互关系的分析,为下一阶段的具体设计打下基础。
UML建模是很灵活的过程,使用者不必面面俱到地画出各种图。对于每一幅图,只有在必要时(比如能帮助分析、设计、指导编码、加深理解、促进交流等)才需要画出,这样的图对建模才有意义,否则会浪费精力而事倍功半。(未完待续)

标准建模语言UML及其支持环境(七)

前几期的主要内容包括:
一、标准建模语言UML概述
二、标准建模语言UML的静态建模机制
三、标准建模语言UML的动态建模机制
四、标准建模语言UML支持环境
五、标准建模语言UML的应用实例
1. UML建模过程高层视图
2. UML实际建模过程
(1) 需求
(2) 分析

(接上期)
(3) 设计
设计阶段的任务是通过综合考虑所有的技术限制,以扩展和细化分析阶段的模型。设计的目的是指明一种易转化成代码的工作方案,是对分析工作的细化,即进一步细化分析阶段所提取的类(包括其操作和属性),并且增加新类以处理诸如数据库、用户接口、通信、设备等技术领域的问题。
设计阶段可以分为两个部分:结构设计是高层设计,其任务是定义包(子系统),包括包间的依赖性和主要通信机制。我们希望得到尽可能简单和清晰的结构,各部分之间的依赖尽可能的少,并尽可能的减少双向的依赖关系。
第二部分是详细设计,细化包的内容,使编程人员得到所有类的一个足够清晰的描述。同时使用UML中的动态模型,描述特定情况下这些类的实例之间的行为。
· 结构设计
一个设计良好的系统结构是系统可扩充和可变更的基础。包实际上是一些类的集合。类图中包括有助于用户从技术逻辑中分离出应用逻辑(领域类),从而减少它们之间的依赖性。这就是软件结构设计强调的模块间的高聚合、低偶合的原则。在商业MIS中,存在以下包(或子系统):
用户接口包:用户接口类允许用户访问系统数据和加入新数据。在商业对象中,用户接口包跟商业对象包合作,调用商业对象的操作,实施数据的检索和插入。
商业对象包:包括来自分析阶段的特定领域类。在设计阶段,详细设计这些类,以完整定义他们的操作,支持对数据库的存取。所以,所有商业对象类必须继承数据库包中的类。
数据库包:为商业对象包中的类提供服务,便于永久存储。
实用包:包含系统其他包要使用的服务。它们之间的内在关系如图1所示。

· 详细设计
详细设计的目的是通过创建新的类图、状态图和动态图,描述新的技术类,并扩展和细化分析阶段"素描"的商业对象类。这些图在分析阶段也曾用过,不过在详细设计阶段,它们是从技术层次上对系统进行更详尽的描述。如分析阶段的用例描述用来验证它们是否在设计阶段都得到处理,而顺序图用来展示系统中每个用例在技术上如何实现,等等。
数据库包:MIS的实现必须有永久存储对象即数据库的支持,因此系统中必须增加数据库层,提供这种服务。目前,市面上有许多商用数据库,有的是真正的面向对象数据库如工程数据库,有的是传统的关系数据库。由于我们只讨论设计方法,不涉及具体的环境,因此,可以抽象一个永久存储类来实现对数据库的通用操作,如存储、更新、删除、查询等。永久类类似于MFC中的基类。
商业对象包:设计阶段的商业对象包即是分析阶段的领域类,需要从实现角度对这些类进行细化,包括如何实现他们之间的关联和行为。所有这些对象类必须从数据库包的永久类中继承而来。分析阶段描述的类的操作,在设计模型中可能被分解成几个操作或者改变名称。因为分析是构造每个类的框架,而设计是对系统的详细说明,因此设计模型中所有类的操作必须定义符号和返回值。图2是经过细化后的商业类图(局部)

在设计阶段,也可细化分析阶段的状态图,更详细的显示状态的变换细节(如图3)。使用状态图可以揭示单个对象在整个系统中的变化细节,对了解和实现关键类有较大的帮助。
此外,还可以使用其他图在实现层上从不同侧面对分析阶段建立的模型进行细化。
用户接口包:用户接口包在其他包的"顶层"。在系统中,它为用户提供信息和支持。由于所有与用户的交互都是通过用户接口实现的,因此UML的动态模型非常适合对GUI包的描述。图4用顺序图描述系统增加新商品用例的动态模型。另一种表示顺序的图是合作图(如图5)。

建立用户接口是设计阶段的一项特殊活动。在商业MIS中,用户接口可以分为功能(系统中的主功能窗口,如采购、库存、销售、统计分析等)、信息(显示系统信息的窗口以及(维护系统的窗口)等三部分。
目前,由于可视化技术的迅速发展,用户界面的设计相对比较简单。一般情况下,应用系统的用户界面由带有菜单条和相应图形的主窗口组成。
(4) 实现
构造或实现阶段是对类进行编程的过程。可以选择某种面向对象对象编程语言(如Java)作为实现系统的软件环境。Java很容易实现从逻辑视图到代码部件的映射,因为类到Java代码文件之间是一一映射关系。图6是设计模型的部件图,显示逻辑视图到部件视图的一个简单映射。逻辑视图中的包也映射到相应的部件视图中。

在实现阶段中,可以选取下列图的说明来辅助编程:
· 类的规格说明:每个类的规格说明详细显示了必要的属性和操作。
· 类图:显示类的静态结构和类之间的关系。
· 状态图:显示类的对象可能的状态、所需处理的转移以及触发这些转移的操作。
· 包含某个类的对象的动态图(顺序图、合作图、活动图):显示该类的某个方法的实现或别的对象是如何使用该类的对象的。
· 用例图和规格说明:显示系统需求和结果。
编码期间也可能会发现设计模型的缺陷。这时需要开发者修改设计模型。修改设计模型时一定要保持设计模型与编码的一致性,以便将来易于维护。
(5) 测试和配置
完成系统编码后,需要对系统进行测试,它通常包括:单元测试、集成测试、系统测试和验收测试。在单元测试中使用类图和类的规格说明,对单独的类或一组类进行测试;在集成测试中,使用组件图和合作图,对各组件的合作情况进行测试;在系统测试中,使用用例图,以检验所开发的系统是否满足例图所描述的需求。
系统的配置是实际的交付系统,包括文档和组成模型等。对商业MIS而言,它是一个典型的客户/服务器系统。可以用配置图显示系统的物理结构,如图7所示。从表面上看,配置图能显示系统设备之间的关系以及显示节点跟可执行软件单元的对应关系。然而一旦某个节点内部的对象或可执行部件过多(超过5个),就很难完全用配置图清楚描述这种关系。

(6) 小结

本文所举的商业MIS系统的UML建模过程可以用图8来描述。其中首先要把握的是如何使用用例技术正确描述系统需求。UML中的类图描述的是系统中类的静态关系,对象图有助于对复杂类的理解。在系统开发过程中,类图可应用于分析、设计和实现阶段。类的包化有助于进行系统结构设计。商业MIS的包分为用户接口包、商业对象包、数据库包,他们之间的关系是前者依赖后者。

UML的动态模型包括状态图、顺序图、合作图以及活动图。在商业MIS中,顺序图对描述商业对象的交互非常有用,是商业MIS分析、设计和实现阶段最重要的支持手段之一。

总之,UML提供的九种视图从不同应用层次和不同角度为系统从系统分析、设计直到实现的提供有力支持。在不同的阶段建立不同的模型,建模的目的也各不相同。

UML为用户建模提供了强大的支持,并提供了很大的自由度。用户在遵循增量迭代开发的原则下,完全可以根据自己所开发系统的特点,在每次迭代的微过程(分析、设计、实现、测试和配置)中,灵活的选用UML所提供的各种图。

在UML应用过程中,选择合适的工具也很重要,对于简单的应用, Visio、MSWord等工具就可以支持各种所需图形的生成。但它们都是静态的图形,都不能支持系统的建模与优化。北航软件工程研究所正在研制与开发的UML集成化支持系统,就是为填补我国软件产业的空白而设计和开发的。

我们认为,未来的软件开发范式将具有以下三个特点:首先,软件开发自动化的程度将越来越高;其次,在所开发的软件中隐藏的差错将越来越少;第三,在新型软件工程环境的支持下,将有能力开发出自适应的软件系统。标准建模语言UML及其集成化支持环境,将为走向这个新范式铺平道路(全文完)。


UML三大硬伤

撰文/高展
程序员杂志2002年第5期

本文从UML建模连贯性方面存在的问题，以管理软件开发为例，针对与UML模型衔接的上游、下游、模型内部关系三个方面，分析了采用UML建模造成的三大隔阂，希望与众多建模爱好者共同探讨。
在国内的公开报道中，几乎众口一致地充斥着对统一建模语言UML（Unified Modeling Language）的褒奖，即便有公开抱怨也只是怪自己无法理解三位UML创始人的深不可测，怪自己的水平不够，没有料到UML本身存在着种种问题。本文作者只在北京大学计算机系的同行那里发现了他们撰文对UML的有效性提出了质疑。与公开报道相左，业界私下流行观点形象地说明了UML存在问题为软件开发设置的障碍，那就是“上不着天、下不着地、一盘散沙”：
（1）“上不着天”这种隔阂使建模结果无法与用户沟通确认所谓的需求，埋下了软件危机的祸根；
（2）“下不着地”这种隔阂使千辛万苦得到的建模结果无法指挥程序员编码，最后得到的软件与用户期望的结果很远，返工、误工、烦恼无穷；
（3）“一盘散沙”这种隔阂让建模图形之间的关系凌乱不堪，建模过程千辛万苦，建模结果很难自圆其说。
这三大隔阂造成的建模硬伤使UML辜负了人们的殷切期望，“高不成、低不就”说明了UML建模在软件生命周期中步履蹒跚，“一盘散沙”说明了UML在建模内容中并未实现Unified的原旨，图 1是UML存在问题的可视化表达。

图 1 采用UML描述的建模结果“分崩离析”

诚然，掌握UML很容易谋到一份很好的系统分析员工作，但用它却很难做好系统分析员的分内工作，使用UML肯定可以100%蒙住用户，因为用户对满篇的建模图表只有招架之功，绝无理解反驳之力，使用UML也几乎可以100%蒙住软件公司老板，因为老板不是系统分析员，不知道使用UML进行建模的千辛万苦，系统分析员无法向老板反映UML存在的问题，因为这样很容易招致水平不高的责难。

一、UML上不着天——与用户/领域专家无法沟通获得真正的需求
 所谓“上不着天”是指使用UML建模后很难与处于软件开发上游的企业用户沟通，因为UML的表达方式与上游用户的行业知识相差甚远，用户一看见满篇的软件工程术语与符号就发怵，根本无法理解使用UML所描述的业务流程，也难以真正理解UML所陈述的需求，与业务专家交流无工而返，导致软件大厦一开始就建立在沙子上，需求不清不楚，没完没了的胡子工程就此落下病根，这种情况造成了软件开中的第一个隔阂，是UML的第一大硬伤。

对企业用户来讲，他们关心的是如何在其组织结构、业务流程、业务信息的描述基础上，定位企业的宏观管理水平的需求和微观管理操作的需求。

1 UML难以完整全面地描述企业的分工结构

图 2是采用全程建模方法组成结构树描述的企业分工组成，它以直观、彻底、一目了然的方式将一个企业按层次地展现为部门、岗位、职责、步骤、直至原子步骤，如“核对数量、核对规格、签字、填写入库日期”等。

图 2 采用全程建模方法描述的分工组成结构可以

细化到原子级工作步骤

图 3是采用UML的Use Case 图来描述组织结构，它只能描述到岗位职责，对岗位职责中的工作步骤无法描述。对业务的描述粗枝大叶，结果需求也是粗枝大叶，但用户往往不知道需要特别重视这一点，更不知道这种粗枝大叶会给项目带来灾难。这是纠缠不清的胡子工程问题点之一。

图 3 采用UML描述的分工组成结构至多只能描述到职责级

2 UML难以从宏观把控业务流程的完整与准确
 图 4是用全程建模方法顺序图描述的业务协作流程——“采购”，它将业务事件序列与业务活动有机地集成在一个图形中，用户可以直观地判断软件开发人员描述的业务流程是否正确、完整。

图 4 采用全程建模方法的顺序图描述业务协作流程

图 5与图 6分别用UML顺序图和活动图描述的业务协作流程——“采购”，问题其一是用户需要左一眼、右一眼、上一眼、下一眼地对照两张图，费时费力，检查两种图时在所难免地会出现遗漏、不一致；问题其二是UML顺序图缺少条件分支的表达方法，表达内容不完整；问题其三是UML顺序图和活动图从形式上到内容上不存在等价关系。
使用UML描述业务流程很难让人放心，因为描述业务流程时产生的遗漏、不一致、不完整，同样会给项目带来灾难。这是纠缠不清的胡子工程问题点之二。

3 UML无法从微观把控业务信息的操作过程
 图 7从微观上用全程建模方法PAD图描述了职责细化流程——库管员如何“入库”，它不仅描述了岗位职责展开的具体逻辑步骤，同时也描述了如何对业务信息进行操作，如对“入库单”的 “实际入库数量、入库日期”等栏目进行填写操作，对“入库单”的 “商品规格、采购数量”等栏目及“采购计划”的等“商品规格、计划采购数量”等栏目进行读取操作。

图 7 采用全程建模方法的PAD图描述的职责细化流程

UML根本无法从微观上描述业务信息的操作过程，只能等到编程时再由有经验、责任心强的程序员去了解，这无疑于边盖楼边考虑在哪里开窗户，最后各种问题盘根错节，摁倒葫芦起了瓢。软件公司练就了不少救火高手，但不容否认的是充满了救火队员项目常常意味着灭顶之灾。这是纠缠不清的胡子工程问题点之三。

4 UML无法彻底全面描述用户的需求
图 8是采用全程建模方法组成结构树进行功能定义，它可以细致到原子工作步骤级，比如“签字入库”仍然需要手工进行。

图 8 采用全程建模方法组成结构树进行功能定义

采用UML无法对这种功能需求直观地定位，结果是开发人员好心好意地实现了电子签名，而客户却毫不领情，应为中国用户不相信计算机的签名，去掉这个功能也是一件麻烦事。
另外常常发生的情况是开发软件遗漏了大量用户需要的功能，如用户需要计算机自动核对“采购计划”中的“计划采购数量”与“入库单”中的“计划采购数量”，如果需求定位没有细致到这种程度，程序员如果没有经验或责任心不强，自然会忘记这些，那么在测试阶段或者系统上线运行后用户肯定会发现要求修改，改来改去的麻烦又会特别多，反反复复修改的工作量极大地加大了软件公司的开发成本。这是纠缠不清的胡子工程问题点之三。

5 UML是造成信息不对称的“功臣”
可以说UML为用户（甲方）与开发方（乙方）的信息不对称提供了“有力的手段”，双方都互占“便宜”，因为这种信息不对称不但表现在有关信息产品和信息技术的知识上，还表现在乙方对甲方的业务理解上。由于乙方对甲方的业务术语理解不一定全面和准确，有可能在乙方看来含义非常简单的一个业务功能在甲方的经典著作或国家标准中含义非常丰富，需要做大量的工作。这样在使用UML的情况下，乙方按照自己的理解与甲方签了协议，但真正实施时却必须按甲方的国家标准去实施，这种扯皮的事在项目实施过程中大量存在。在信息项目的对策模型中，很难说乙方就一定能在合同中处于优势。
由于信息化热潮的影响，许多公司纷纷进入IT项目建设市场，这些公司中难免有不少是属于鱼目混珠一类的，他们可以在报价中拚命地压低价格赢得标书，但在实际建设中却以各种手段欺骗用户，使用户蒙受巨大损失。还有一些很有名气的院校和公司承接IT项目建设业务之后，由于各种业务量太大，对其中一些中小项目投入精力不够，雇请一些新手作项目，囫囵吞枣，出了问题要么说用户当时没有说清楚，要么说用户水平太低不会用。
即使乙方很勤奋，将方案做得很先进、很完美，充分考虑各模块的设置，也重视信息安全等问题，在使用UML的情况下，因为UML存在的种种问题，仍有可能因为乙方对甲方业务信息的理解能力不够，而使得乙方的方案和产品偏离甲方的真实需求。

二、UML下不着地——无法提供直接到位的素材指导程序员编程
所谓“下不着地”是指费尽心力地使用UML建模后，很难让处于软件开发下游的程序员直接接受去编程，因为UML的表达方式不直接支持详细设计，程序员还得费尽周折地琢磨如何把建模结果转换成程序代码，这种情况造成了软件开中的第二个隔阂，是UML的第二大硬伤。
与现代编译器对接的是结构化程序设计，如伪代码、PAD（问题分析图），前者为80%的美国公司使用，后者为80%的日本公司使用。伪代码的优点是从语法结构上与通常的高级语言非常接近，PAD由于可视化的特点十分便于人的理解，在图 9中，全程建模方法建立了这两种详细设计的联系，可以轻松地将PAD转换成伪代码。

图 9 采用全程建模方法PAD图描述的模块级流程与伪代码

另外，UML没有对系统级、模块级接口的考虑，这在大型复杂系统开发重视不可想象的，图 10采用全程建模方法中数据汇总图自动描述的系统之间的接口。

图 10 采用全程建模方法中数据汇总图描述的系统之间的接口

三、UML一盘散沙——没有在细微之处建立建模图形之间的联系
UML建模图形之间的内部联系十分松散，这种隔阂造成了UML的第三大硬伤，由于篇幅的关系，这种硬伤造成的潜在危害不再讨论，本文只是将“散沙”“罗列”如下：
1 状态转移图中，事件与外部Actor、Class、Package等无关；
2无法从语法上建立状态转移图与顺序图的联系；
3 无法从语法上活动图应与顺序图在流程描述关系；
4 协作图和顺序图中与Message相伴的参数与类图无关。

虽然UML有这样那样的问题，不过UML也是从版本0.9发展到现在的1.4版，我们期待UML的升级，但在将要发布的2.0版中却没有“改过”的迹象。
本文对UML攻击颇多，实际上全程建模方法从UML及其前身OMT（Object Modeling Technique）获益匪浅，作者也是经过对OMT、OOSE、UML以及OOA/OOD的深入剖析，取长补短而建立了全程建模方法，所以理所应当向相关的面向对象大师们表示敬意。
本文在写作过程中得到了战复东先生的热情帮助，在此表示感谢。

=======================================================以下为很多的评论：

tata1 (2002-6-17 16:40:37)

感想： 高展先生的文章已引起不小的风波，有人认同，有人迟疑，有人反对。我认为，我们每个人都应该感想高先生，是他与作为“软件开发标准技术”的UML唱了反调，他敢于挑起一场风波，而这场风波早应该发生了。 软件开发是一个技术研究与应用实践紧密结合的过程，程序员必需具备科学的研究精神，辩证的思考问题而不是沉迷于某项新技术，新思想的玩弄，或迷信于某个理论的说法。如果伽利略不敢否认亚里士多得，如果爱因斯坦不敢否认牛顿，那么今天会是怎么样呢？ 我敢肯定，即使那些拥护UML的人对UML也不全是很精通的。为什么所谓标准就无澥可击了，聘什么认为老外做的东西就是好的？中国软件应该发起一场革命，铲除那些形而上学，教条主义的思想，建立统一的正确的认识。用哲学的发展，全面，辩证的思想来认识问题，认识软件工程。

tata1 (2002-6-12 16:10:18)

UML手册已经说明UML是一个建模符号体系，不适合完成全过程的设计应用。所以，高先生说UML“上不着天，下不着地，一盘散沙”有点偏激了。 我认为，UML确实存在使用，普及困难的问题。UML加上RUP后，内容太多，还要学习面向对象技术，确实使软件开发难度很大。一个设计思想或设计工具的运用主要是为了缩短开发周期，提高代码的利用率，可维护性等方面。所以我非常同意高先生的全程建模思想，我最近也产生了一些类似的构想。我希望理想的设计工具如下：一：归纳各软件开发阶段的问题，和解决问题的方法和技巧，指导性地分析设计。二：有层次，有联系的表达各阶段，各模块，各对象等元素的构成。三：和代码保持同步。即设计到代码的正反向功能。 ... 我的Mail:kmbaojun@msn.com 欢迎讨论

zy422 (2002-6-11 10:15:19)

我是一个有个编程经验多年的人，我也用 ROSE 来设计个一些东西，但我感觉到 ROSE 在给程序员一个交代时做得很不够，应为程序员最关心的是这个函数要做什么事、怎么在这个函数里做，函数里到底要使用到设计的那些类和函数，这 ROSE 实在是做得不好，所以现在我们公司里的程序员一般都不看 ROSE 图，靠和设计人员直接交流来完成对设计要求的认识。我希望 ROSE 在以后的版本中能做一些好的，能和程序员交流的工具或表达视图。 UML 还有很长的一段路要走，我真正用好了的只有类设计，其他的我实在是用不好了。 我个人的观点，实用的就是好的，管它是面向对象还是面向过程，关键是要大家都用，都能够用好,多能方便的使用。对于 UML 我认为它站得太高了，现在很多人都还不能用好。

gale (2002-6-7 14:38:57)

3boy说的不错，但离题了，希望不是枪手，更不要顾左右而言它让我们重新看一下问题,作者说的是：UML的三大硬伤抛开工具，考虑一下思路这个UML三大硬伤的认识是错误的，理由我在前面的贴子已经描述过了我希望大家能就这“三大硬伤”提出意见，而不要偏离主旨 1,再驳“上不着天” 有什么形式化的方法能对问题域进行信息无损的描述？？？理论上还没有，目前走在业界前面的，是国际标准的，就是UML了 XX建模方法我不熟悉，没有发言权，但....这个不是国际标准 2，再驳“下不着地” XX建模方法有类和对象级的表达语法吗？反正在这篇文章里没有看到哎，我也不行，做不出自己的建模方法来，我“五十步笑百步” 3，再驳“一盘散沙” 昨日在《程序员》上拜读了高先生的《XX建模方法》不用我说，各位明眼的人就能看的出哪种方法的形式化推导关系更严密了

3boy (2002-6-7 9:31:32)

我觉的以上的言论太过偏激了，火药味太过于浓厚了，软件分析的目的是为了让大家都弄明白一个目的，那就是 “你该做什么？你要做什么？或则你要其别人做什么？”，而所谓的Rational产品，以及高先生的Playcase包括其它的一些建模工具都充其量和word差不多，只不过使用方便一些而已，“人”的因数还是最重要的，这就是对系统分析设计人员的素质要求。我觉的我们不能“神话”建模工具，而忽略了人，即使我们没有好的“画图”工具只要有人在，我们甚至可以“手绘”全部工作流，以上的争论好像就在讨论“画图板”的优劣，而不是在探讨软件工程真正的要旨，我觉的应该讨论的是“如何让大家都明白，你要做什么，我能为你做什么，你有些什么可以为我而提供的，你是这样的吗？。。。。。” 软件工程是一个不确定标准的学科，不确定的原由是，每个人都有自己的主张，不管主张的好坏，至少要知道你在为谁分析，你的对象是如何的，如果你画的东西别人都不理解，或者他们要花费很大的代价去理解，我认为那就是失败的方法，那么我们就必须寻求其他的途径去让人理解。 “我的三大忠告” 1、“条条大路通罗马” 2、“能解决问题的方法才是好方法” 3、“好的画家，即使没有丰富的颜料，和优良的画笔，依旧可以做出优秀的传世之作”

3boy (2002-6-7 9:26:54)

我觉的以上的言论太过偏激了，火药味太过于浓厚了，软件分析的目的是为了让大家都弄明白一个目的，那就是 “你该做什么？你要做什么？或则你要其别人做什么？”，而所谓的Rational产品，以及高先生的Playcase包括其它的一些建模工具都充其量和word差不多，只不过使用方便一些而已，“人”的因数还是最重要的，这就是对系统分析设计人员的素质要求。我觉的我们不能“神话”建模工具，而忽略了人，即使我们没有好的“画图”工具只要有人在，我们甚至可以“手绘”全部工作流，以上的争论好像就在讨论“画图板”的优劣，而不是在探讨软件工程真正的要旨，我觉的应该讨论的是“如何让大家都明白，你要做什么，我能为你做什么，你有些什么可以为我而提供的，你是这样的吗？。。。。。” 软件工程是一个不确定标准的学科，不确定的原由是，每个人都有自己的主张，不管主张的好坏，至少要知道你在为谁分析，你的对象是如何的，如果你画的东西别人都不理解，或者他们要花费很大的代价去理解，我认为那就是失败的方法，那么我们就必须寻求其他的途径去让人理解。 “我的三大忠告” 1、“条条大路通罗马” 2、“能解决问题的方法才是好方法” 3、“好的画家，即使没有丰富的颜料，和优良的画笔，依旧可以做出优秀的传世之作”

gale (2002-6-3 11:07:14)

1，技术是不分国界的，你用手在白板上画UML图是无需支付任何费用给US的 2，不要动不动就把技术问题上升到政治和民族主义 3，“拿来主义”，英美都能虚心拿去中国的火药制造枪炮来打中国，你难道不能学美国的 UML来打败US的软件产业？？！！ 4，作为中科院的人物，讲话是要负很大责任的，因为你的错误讲影响千千万万的人如果你错了并且是个权威，你将造就“十年浩劫”！！

chinakid (2002-6-3 10:06:48)

我想不通！为什么高展先生一说UML不好，就有人跳出来大骂，为什么，为什么？难到美国人的东西就不能批评吗？难倒中国人的智慧就比美国人差吗？中国人，不要轻易低下你高贵的头！

gale (2002-6-1 0:38:51)

1，“上不着天” 错，UML中的 Business Use Case Model 和 Business Object Model就是干这个的。最少现在还没有比UML描述业务更通用，更清楚的 2，“下不着地” 又错，Rose可以生成代码，再加上 XDE与Visual Studio.NET的集成 3，“一盘散沙" 还是错，Business UC Model--》Business UC Realizations--》Business Object Model Business Worker --》; Actor --》 Use Case --》Use Case Realization --》Analysis Model --》 Design Model --》Imp model 都是有严密的推导关系的什么“专家”？？！！纯粹是误人子弟！！补充：好像牛顿先生说：“我之所以伟大是因为站在巨人的肩膀上” 软件开发领域里“巨人的肩膀”就是前人工作的结果和经验 US的软件比中国强原因之一是国人（我也是）都喜欢重新发明轮子 UML是一个标准，不是R$的产品，你要是真有水平应该提交UML2.0给OMG，而不是自己闭门造车弄个什么XX建模方法出来。 建议高先生好好看看UML+RUP+UCM这整个的思想体系，真正研究上一年再发表点有趣的文字。

gale (2002-6-1 0:22:04)

1，“上不着天” 错，UML中的 Business Use Case Model 和 Business Object Model就是干这个的。最少现在还没有比UML描述业务更通用，更清楚的 2，“下不着地” 又错，Rose可以生成代码，再加上 XDE与Visual Studio.NET的集成 3，“一盘散沙" 还是错，Business UC Model-->Business UC Realizations-->Business Object Model Business Worker --> Actor --> Use Case -->Use Case Realization -->Analysis Model --> Design Model -->Imp model 都是有严密的推导关系的什么“专家”？？！！纯粹是误人子弟！！PlayCase版权费的驱动＋浅薄＋无耻

kjxia (2002-5-29 15:15:13)

我想csdn给我们提供的是一个技术论坛，作用是大家可以在这里进行交流和讨论，通过交流可以解决一些实际问题，或是达到开阔视野、增长知识的目的，有不同的观点自然可以提出，但目的是为了探讨，有些用户把对别人观点的不认同转化为了莫名的人身攻击，这是很令人痛心的。

ysmstoneman (2002-5-25 16:10:43)

呵呵,我懂得中国的软件为什么比不上国外的了。建议那些搞人身攻击的“同志”们，或持反对观点比较强烈的“专家”们都去看看《谁动了我的奶酪》这本书。记着，“我们都在害怕变化”。 UML强大，难道它就真的没有缺点了吗？是啊！如果我精通Delphi，我真希望其他的开发工具都她吗的消失。但它们消失了吗？没有，C#出来了，什么.net出来了，据说什么以色列的魔术师之类的东东也出来了，………………不知道以后还有什么东东…… 我知道原来我错了，是我没有适应那么快的变化，IT这行确实变得太快，永远都有新东西出现，那应该是好事，要不，这世界上的技术怎么会发展的那么快呢？长期以来，分析工具一直是我国的空白，高展先生好不容易弄出了PLAYCASE（也许不是他一个人的功劳，但怎么说中国也出了这么个东东了），就因为这篇文章，用得着把人家骂成那样吗？

hostoop (2002-5-22 17:45:10)

不管是UML还是其它的什么，它都只是个工具，是用得好还是用得差，靠的是用工具的人。每个工具在不同的领域有不同的作用，我不会用VB来写硬件驱动程序，也不会用汇编语言写财务软件。我现在在Linux环境下用C语言写邮件服务器程序，如果按照高先生的思路，我是不是该出来写写”VB的三大硬伤“、”Windows的X大硬伤“？

2001sky (2002-5-21 13:28:50)

真正成功的软件是不依靠什么UML和PLAYCASE的系统分析的作用就是把客户的意思传达到程序员那里系统分析就是一个调制解调的过程如果你行，用WORD就可以了如果你要蒙人，用什么都不行什么样的人可以做系统分析？没有做出过成功软件（客户满意，代码稳定）的人永远没资格做系统分析，博士也不行请不要攻击任何工具，他不是万能的，只是一个助手

asp_boy (2002-5-21 8:57:20)

不知道分析员是不是都是高高在上的，还是在CSDN中的特产。只要提出一个不能被多数人接受的观点，就会被骂得狗血淋头。 争论是一定会有的。但如果指人，这与市井流氓有什么区别？有人说“PLAYCASE那玩意纯熟垃圾”，想必他能设计一个比PLAYCASE更好的玩意，如果设计不出，也应该指出PLAYCASE的不足。空口说白话，谁不会说啊。 最后一点， PLAYCASE是免费的，却有人说“鄙人初次接触PlayCase, 就发现PlayCase有许多优点......高展先生，您的PlayCase卖了几套了？”。 可见，很多人都是推崇自己正在使用的工具。 存在偏见的人不会是好的分析员。

shhao (2002-5-20 15:50:44)

我认为主要问题是作者未理解（当然更谈不上掌握）面向对象的思想和方法。

zhaott (2002-5-20 13:15:12)

工具不是主要的，主要的是人，是规格

telescope (2002-5-20 13:06:05)

一个老农拿鞭子敲敲拖拉机骂道，这东西没他妈我的驴好使，不懂人话，就算费点劲把它开起来，还不得把我的地压硬喽？驴一拉就走，这东西他妈不要说让我拉，就是驴也拉不动，然后还得花油钱，这是拖拉机的硬伤啊。

telescope (2002-5-20 13:04:30)

一个老农拿鞭子敲敲拖拉机骂道，这东西没他妈我的驴好使，不懂人话，就算费点劲把它开起来，还不得把我的地压硬喽？驴一拉就走，这东西他妈不要说让我拉，就是驴也拉不动，然后还得花油钱，这是拖拉机的硬伤啊。

blacktigers (2002-5-20 12:07:57)

推荐一篇文章：转载自企业工程论坛 http://www.ee-forum.org/ 标题：复杂系统的层级原理与模型驱动软件体系结构　 作者：余彤鹰 2002-5-17 -------------------------------------------------------------------------------- 写在前面　　最近看到模型驱动在国内渐渐被更多的人注意，前几天又看到一些关于UML优劣和应用方面的争论。作为繁忙工作中的一种休息，从过往的研究笔记中整理一点东西放在这里，与大家交流。 层级理论是构建复杂软件体系的基本原则　　诺贝尔奖获得者赫伯特 A. 西蒙曾论述到：“要构造一门关于复杂系统的比较正规的理论，有一条路就是求助于层级理论……我们可以期望，在一个复杂性必然是从简单性进化而来的世界中，复杂系统是层级结构的”。对于软件这样复杂的人造事务，发现层级和运用层级，是分析和构建的基本原则。 软件的体系结构是层级的　　粗略地观察一下软件表述方式（语言）的发展：从穿孔纸带（机器的语言）开始，首先是汇编语言，然后是高级语言，再往后有面向对象语言和所谓第四代语言（FGL）出现……应当留意：每一代的语言并不是在“取代”前一代语言，而是用上一代语言来“写”下一代语言。在这个自然的进化过程中，西蒙所论述的复杂体系的层级特征清晰地出现了。 　　进一步看，在由简单到复杂的进化道路上，软件的体系结构、软件开发的体系结构、软件开发工具的体系结构等等，都呈现出层级的特征。“好”的软件体系具有更加清晰的层级。 一维语言之后是模型　　这里不想展开讨论这个问题，只是提出一些思考的结果。与自然语言类似，现有的“程序设计语言”是单维的，它的基本语法是以前后顺序为基础的。当系统的复杂程度提高时，用这样的语言精确描述复杂系统变得越发困难，更遑论有效地修改维护；可视化开发平台、代码管理工具（甚至某种意义上共享组件也可包括在内）等的出现对此是一种补充，但仍然不是最终的解决方法。软件描述体系进化到这里，面临着一次突变，将有新的物种出现，这个新物种可能就是模型。笔者认为，模型与程序语言主要的区别不在于图形化，也不在于抽象的程度，而在于表达方式突破了“单一顺序”的限制，最简单的例子就是二维表。模型可以更容易和直接地表达复杂的结构。 模型和语言都是对系统的描述　　传统的编程语言和模型都是一种表述的体系，前者适合表述顺序过程，后者适合表述复杂结构。模型的必要性可以通过下面这个例子看出来： 　　为了精确地复现，你可以用语言精确地叙述一个立方体，甚至10个立方体组合的形状，但你不会试图用语言描述一栋房子，适当的方式是用工程图纸。 　　建立企业应用系统的情形可以从以上例子得到启发，企业系统要表述的，主要是复杂的结构，过程占的比重很小，因此，模型就变得更加重要乃至必要了。 OMG组织的MDA战略　　OMG最新的战略，是建立模型驱动体系架构（Model Driven Architecture, MDA），它的意义不是三言两语可以说清楚的，但从软件进化的角度来说，可能带有一种必然性，从上面的讨论，至少可以引申出两个理由： 更有效地描述复杂系统的需要； 系统复杂化带来的层级区分的需要。 关于模型的几个分析要素　　笔者认为，以下特征对软件体系中模型的运用是十分重要，或者有特殊意义的： 模型的时效性（time-effectiveness of model）：关于这一点最重要的区分在于，是“运行期模型”（Run-Time Model），还是开发期模型？这个区别，有点类似于解释的语言和编译的语言间的区别，但其意义却非同一般，笔者认为，“运行期模型”，揭示了模型驱动的本质。 模型的可进化性（evolutionableness of model）：是否可以在系统的应用过程中，持续地适应应用环境与需求的变化，不断地由应用者或自适应地对模型进行改进？这是对模型“性能”的一种度量。 模型的层级性（hierarchy of model）：正如语言有多个层次一样，没有理由认为模型只有一个层次，当系统足够复杂时，模型的层次划分将会是必要的。 UML和企业模型　　运用上面的要素分析一下，可以发现： 　　UML是“紧贴”高级软件语言（例如C++）的模型体系，其时效是在软件生命周期的开发期间，而不是运行期间，其描述的层级是在软件的组件、对象一级，典型要素是软件中的对象，软件上一个操作的动作等。 　　企业模型（比如ARIS, CIM-OSA, GERAM），典型的要素是组织，产品，过程等，它们是从企业的业务对象着眼的。二者在层级上有差距，而且企业模型追求的最终结果，是从“开发期模型”到达“运行期模型”，并且，笔者认为它最终应当是一种可进化的模型，这与UML的设计目标并不符合。 　　它们两者间并不相互排斥，而应当考虑它们的“层接”。按照笔者的理解，OMG的MDA即使全面实现，也仍然不能做为或替代企业模型，但有可能成为企业模型的基础，这不是模型好坏或能力的问题，而是层级定位的问题。 写在后面　　面向对象（Object Oriented, OO）作为软件体系结构方面的一种演进而出现，也曾经被一些人误解为对过程化语言（或面向过程的体系结构）的取代。笔者认为，尽管OO反应了一种世界观，是一种思维的方式，但并不代表一切；且从层级和进化的观点上，也不应当将它看作是对既有东西的一种简单的取代。模型或模型驱动同样如此，它可能是继面向对象之后，软件体系结构的又一个重大的进化，但不是用来取代面向对象或结构化设计。笔者在1998年撰写《迈向21世纪的企业信息技术应用》一文时，对于模型的地位和作用并没有今天这样的认识，现在我坚信，对于企业信息系统这样复杂的系统，要想做到有效、可控制地规划与构建乃至具有“柔性”、可在运行期间不断地调整，“模型”是必须的，而且，表达与构建复杂企业系统时所需的模型，可能是多层次的，所谓“通用企业平台上的专用执行系统”，就应当是一个由运行期模型驱动的系统。 --------------------------------------------------------------------------------

chinakid (2002-5-20 9:41:02)

偶尔路过看到这些评论，我很气愤。一帮美国的走狗！ UML，CMM都是人家美国人定下的标准，可笑的是软件公司象哈巴狗一样，跟在美国人后面摇尾巴。高展的playcase我没有用过，但我知道一点：中国人从来不输给别人！！！！！政府能扶助制造自己的CPU，自己的操作系统，自己的Office软件，也可以再扶助一个建模软件！这样我们就不用再仰视别人的鼻息！！！美国人的一套Rose多少钱？赚去了中国人多少血汗钱？而高展的playcase是免费下载的！！！为国家安全和产业利益，政府都应该对自主开发的软件进行扶持！起来，挑战UML霸权！

bigbat (2002-5-19 21:25:25)

"UML 没有排斥任何特殊的软件开发方法或过程；它只不过标准化了标记法的格式。"Granville Miller 语不是UML的问题。是开发者对面向对象的方法掌握的问题。高先生的方法是可能是一种好方法。但你应弄清楚你只是其中的一种。不要弄不清楚问题的实质就大贬一通。我觉得你说的三个发面都不对！ 1“上不着天”这种隔阂使建模结果无法与用户沟通确认所谓的需求，埋下了软件危机的祸根； USE CASE 图是一种很好的用来表达用户需求的工具。何以“上不着天”？ 2“下不着地”这种隔阂使千辛万苦得到的建模结果无法指挥程序员编码，最后得到的软件与用户期望的结果很远，返工、误工、烦恼无穷； CLASS 图是程序编写的图纸。看着它就可以来写代码。coder 们不需要了解设计的全部就可以施工。何以“下不着地”？ 3“一盘散沙”这种隔阂让建模图形之间的关系凌乱不堪，建模过程千辛万苦，建模结果很难自圆其说。目前在 UML 规范中有九种图。重不同的视角反映需求。你的设计“一盘散沙”。UML有何罪之有？ 高先生你认真对待你的“惊世”高论。您是一位学者！！！！！！！

elkel (2002-5-19 19:31:36)

真好笑，作者根本不懂UML，拿着Rose胡画，还对UML妄加评论。恶心... 本人忍受胃痉挛的痛苦，读完此文。力图修正作者使用UML的错误，提醒初学者不要象他一样胡画。（其实我也是初学者:)）对于Playcase，我没用过，不敢妄加评论，以免犯与作者一样的错误。但我可以确定我今生今世都不会用它。 西门吹雪忽然道：“你学剑?” 叶孤城道：“我就是剑。” 西门吹雪道：“你知不知道剑的精义何在?” 叶孤城道：“你说。” 西门吹雪道：“在于诚。 叶孤城道：“诚?” 西门吹雪道：“唯有诚心正义，才能到达剑术的颠峰，不诚的人，根本不足论剑。” 好，现在开始切入正题 1. 图3，作者应该画的是用例图吧。首先，用例图不能用来描述企业的组织结构。其次，作者用包来表示企业和部门是胡画，包在C++和java中分别映射为namespace和package。另外，作者用用例表示职责，算沾了一点边，但是这仍然是错误的，用例应该代表业务过程中角色的行为。作者所提的“不能直观地将职责展开为步骤”，应该用协作图表示。以作者的观点看来，建模是以企业组织结构为中心，而UML的观点是以业务为中心。以企业组织结构为中心，就要根据企业组织结构建立业务流，以业务为中心，企业组织结构要适应业务流程。哪个合理，很明显。（扯的太远了） 2. 图5，作者的目的是描述业务流程吗？那么请用协作图吧，虽然顺序图和协作图可以互相转换，但它们是有区别的，顺序图是针对开发人员的，协作图才是针对领域专家的。 3. 图6，作者画了泳道吧？胡画！！角色的职责应该在这里表现，每一个泳道应属于一个角色，泳道内的活动就是角色的职责。这是活动图吗？起始和结束点在哪呢？ 作者提出的UML三大硬伤，更本不能成立，作者根本不懂UML。

grantguo (2002-5-19 14:59:52)

还是那句话：没有银弹。。。。软件开发过程中没有银弹 啊。

kendy_yin (2002-5-19 11:24:16)

其实你未必要去评论uml的好坏，就象linux的爱好者去说windows的坏话一样。如果你的产品真的好地话，时间可以证明一切的。觉得还是多花点心事集他人之长，补己之短吧。希望能见到你更好的产品。其实我都不知道作者是写什么的，从上面评论看，你是不是playcase的作者呀？

maxsuy (2002-5-18 19:17:38)

作者的人品确实存在问题。 PLAYCASE我用过，我承认国内的公司能弄出这么一个东西确实不容易，可是你也犯不着这么咒骂UML吧。 PLAYCASE那玩意纯熟垃圾。做出设计来到最后呢，还是没有用。放厕所里都嫌PLAYCASE臭。

pattern (2002-5-18 19:07:48)

作为一个又搞分析，又编码的软件工程师（存在于大多数有中国特色的软件公司）。有一条经验应该铭记在心：不要指望可以完全掌握用户的需求，大多情况下，业务领域专家也无法给你一个细化到原子级的需求。所以，才有object-oriented 软件工程的出现，才有增量开发方法，才有敏捷建模，这些都是告诉我们要顺应人的思维习惯，渐进开发，逐步挖掘需求，层次建模。软件工程与建筑工程有很多共通点，但他们有一个根本的不同就是：软件最终是可以被修改的，但你不会为一个不很合理的自动扶梯设计而修改造好的大楼，只能将就着用。所以建筑工程的需求可以被认为是确定的，而软件则是相反。

whack (2002-5-17 23:53:21)

呵呵，弄了半天才是一个软件的作者在说自己的软件比别人的好，怪不得口气和论述都是说得那么具有商业的味道。那我们也不妨来看看文中的几个技术的例子： 1。面向对象开发中和用户交流的关键描述工具是use case图。所以一个工具在这个阶段对用户最重要的就是构造use case描述（必要地时候也需要对一些重要的类或者包，以及相关的一些交互细节做某种程度的描述），通常component的构造细节在和用户交流过程中通常用到得很少。 那么use case图作者会怎么描述呢？从文章中的对一个需求的建模结果看，也是类似的一系列图形和符号描述方式，但是不同的是在作者的表达方式和uml有所不同，更重要的是作者列举自己的建模图例和uml的图例的时候，设计的程度是不一样的，作者的建模图例其实是uml中的“静态图（类，包等）+ 一些usecase + 一些时序图（或者顺序图）”，也就是说作者的图形里面其实是夹杂了uml中的好几种图形（当然是把uml的描述方式有所简化和变化），但是在列举uml的设计图形的时候，却缺少了类的动态成分的表达（也就是方法及其顺序），但是在uml中有很多的图可以更进一步细化类或者包的设计（序列图，交互图，conponent图等）。 这反映了作者对于面向对象系统描述的理解不同，uml之所以把几种图形分别描述，一是当需求比较复杂的时候，几种图加在一起的方式可能会变得无法描述，因为一张图形可能变得已经画不下来了。二是uml的方式认为系统具有一系列的特性，不同的特性需要有专门的方式来分别描述。图形多看不过来，但是混合在一起，如果描述同样的细节程度，恐怕还是很长。 2。对于微观设计，那就要看是系统分析阶段还是系统开发了。系统分析的时候做很多细节，有必要吗？本来系统开发就是有很多细节要到系统实现阶段来进行的。而且同样的，对于任何一个小模块，同样地画出component 图，序列图，交互图（只不过粒度不同），想不出来这时候为什么不可以编码？所谓的伪代码不就是一种这些图形的文字描述方式吗？在描述留成的时候，其本质上是同构的（只不过伪代码是结构化的流程图方式来描述类或者方法的关系）。 3。实在弄不懂作者遗漏用户需求的意思，遗漏了用户功能是系统分析没做完的问题，和怎么描述实在联系不上。作者在某个流程上加了个注解，这是解决方法啊？ 4。作者认为uml中间的好几种图形和某些元素无关，或者不能转化为逻辑语句。这就是对uml的语法的理解问题了。这些图形用系统工具现在都可以直接生成c++或者java代码，那么语法转化还需要什么。 5。uml的描述方法里面还存在着某些复杂性或者戎余，包括rose工具对于某些图形的构造方法也存在着需要改进的部分，这些不用多讨论了，只要是软件或者标准，都是在不断进行版本修订中。 看了一下原文我怎么有点儿怀疑作者到底用uml做了多少项目，如果是为了宣传产品，没有必要做那些并不特别的例子，有些例子就只有一个自己的分析结果，就来了个结论。要知道很多在编码过程中好像很“好看”的东西，构造成一个产品后，就成了一堆不能维护的零件了。大家都用自己“喜欢”的，结果却往往是不能用的。

andy2ray (2002-5-17 21:44:20)

UML三位大师开宗明义，UML是一种语言，而不是方法，因此他本身不提供软件开发的过程指导。如果你不清楚或想获得在软件开发上的过程指导，可以参考RUP。这点不知高先生是否注意到？

111222 (2002-5-17 15:41:31)

写的很好，UML本来就是垃圾！

enlightenment (2002-5-17 15:22:06)

有句话是对的：尽信XX则不如无XX！

wuhan_wanhui (2002-5-17 14:14:50)

UML”三大硬伤”之我见 2002年第5期高展先生的文章《UML“三大硬伤“》以管理软件为实例，阐述了UML的三大硬伤，叙述的十分精彩。软件开发过程中的一些问题都被高先生提出，使我受益匪浅。但是高先生的许多观点，我不敢苟同。 UML是一种建模语言，语言是来供人们来交流，也就是供不同领域的人来交流的一个标准，就好像世界语。因此UML不是一种方法，UML建模和软件开发过程是两个不同的概念。UML适用于很多重软件开发过程。因此高先生有把用UML建模的软件开发过程和UML混淆的嫌疑，把软件开发过程中出现的硬伤归于UML，实属误解。 “上不着天”论。文中说，“建模结果无法于用户沟通确认所谓的需求”，“用户专家无法理解UML所描述的业务流程”。实际上业务流程是很细致的，以前我们用系统流程图直接处理这些业务流程，用户专家能得到很好的沟通。而现在用UML来描述业务流程，是不是有点赶时髦的嫌疑？软件开发过程中的问题并不是UML建模都能解决的，可以这么说用UML来描述业务流程曲解了建模的本义。三位大师的著作《UML参考手册》中说道，“模型从某一个建模观点出发，抓住事物最重要的方面而简化或忽略其他方面”，“ U M L是一个建模型语言，不是对开发过程的细节进行描述的工具”。可见建模是要抓关键和重要的东西，高展先生文中说到，“UML难以从宏观把控业务流程的完整与准确”，并举了UML不能描述到原子级工作步骤，这与建模的思想是相违背的，建模需要的只是到关键的一定层次（如文中所述的职责级），而不是详细的细枝末节。可以说这正是UML的精华之处，只关注重要和关键而不关心细节。详细的细节问题属于软件开发过程中的问题。 “下不着地”论。建模只是建立了一个模型，至于具体的详细设计、编码当然需要程序员去理解和思想。试想，模型和详细设计之间不存在这个隔阂的话，从事详细设计的软件蓝领都不要下岗了？UML存在的意义在于作为一种通用的建模语言，提供了一种建模者之间交流的标准，这当然也适用于上游的分析员和下游程序员之间的交流。UML其实也向下着地，着于这种相互之间的交流上。从模型转换到程序代码属于case工具的范畴，并不能说是UML的硬伤。再说现在Rational Rose对于模型到代码的转换工作已经取得令人惊喜的效果。

dearmite (2002-5-17 11:31:19)

看了这么多，想写点什么，其实我这两种工具都没用过，ROSE只是听说，不过，没下过鸡蛋，总还见过，别人用的时候，唉，我总是很羡慕！为什么？不是UML多么高、多么好，也不是他那东西真的能转换多少价值， 因为他开的钱比我多！我们学这些、那些建模做什么，不是做事业，我们是为了钱！ 从文章的受益度讲，从文章的深度讲，我想这一点，高先生一定是最高分！ 但是问题是为什么IBM的OS/2没有比过MICROSOFT的Windows呢，因为市场！如果是我，boss让我又做建模，又做程序，那我一定不用UML，用高先生的东西没错！因为一切为了实用嘛， 但是问题是，建模的人不写代码，写代码的人不建模，建模的人把关系搞好就能弄到钱，你的程序多好，你的公司通过cmm,但是你卖的程序真的用了CMM了么，不是！，都是为了多挣一点钱罢了，所以我只能以心灵上赞助高先生，如果我要学，我还是要学UML，因为这就是钱！全程建模大家一看就懂，那还了得，客户还能买单？他不懂就对了，这就是UML的最最高明之处！

SouthPole (2002-5-17 11:10:11)

我想很多读者(包括我自己)对这篇文章非常不满，主要是因为： 1 作者对UML及其产品缺乏足够了解和实际使用经验，所指的所谓“硬伤”，很多并不是UML的问题，而是对基于UML产品的错误理解。例如：“采用UML的Use Case 图来描述组织结构，它只能描述到岗位职责，对岗位职责中的工作步骤无法描述” UML本身主要是用于REQUIREMENT和HIGH-LEVEL DESIGN，如你希望描述工作步骤，使用UP中USE CASE TEMPLATE即可 2 作者对UML的许多评价偏激，“上不着天、下不着地、一盘散沙“，近于全盘否定，就是当年批判GOTO时恐怕也没到这种地步

twinsant124 (2002-5-17 10:28:23)

1、文章的论点：关于UML，我可没有啥敢维护的，我是UML的初学者^_^，犯不着一上来就维护这么一个只不过是工具的东西；关于什么全程建模，咋更不敢放什么厥词了，偶可没有高老师对自己都不熟悉的东西大加批判，点人家死穴的勇气和魄力。 2、作者写技术论文的作风：作为国内很有名的软件过程专家，请注意自己的言行可能造成初学者的迷茫和彷徨，三思而行，文章之道也。

waterusage (2002-5-17 9:25:11)

很多人不是在驳斥高展的论点，而是在批评他的PLAYCASE，批评他的为人了。 本来还是一个技术上的争论，现在就成了闹剧。 该收场了吧？吵完以后，谁也得不到好处。 但是，肯定也有人旁观了这场争论后，再使用UML时，多留了一个心眼。

rayking (2002-5-17 8:58:14)

从高先生以前写的文章看，所用的手段都是比较传统的。UML其实比较年轻，正是为了弥补数据流图（所谓的“地”）和业务流程图（所谓的“天”）等的不足而产生的。UML当然有缺点，这些缺点在几乎所有UML书籍里都有提及。希望高先生自己先用一下UML，相信会喜欢上她的。

softdance (2002-5-16 23:08:54)

高先生批评UML本着学术自由的原则没错，高先生的PlayCase我用过在也还算不错，而且我也相信大部分的同志也绝对不是攻击PlayCase这种工具本身，那高先生错在何处啊，何以招致如此多人群起而攻之。在这我只想说一句话：你可以批评大象皮糙肉厚，身体笨重，行走缓慢不如你的骡子外观漂亮，身轻体健，奔跑如飞，我保证没人说你什么，但是如果你批评大象不如你的骡子鼻子长牙俏,我同样可以保证保险公司都不敢保你。点穴要点死穴才能要人命，希望高先生下一次能准一点。

softdance (2002-5-16 22:56:59)

高先生批评UML本着学术自由的原则没错，高先生的PlayCase我用过在也还算不错，而且我也相信大部分的同志也绝对不是攻击PlayCase这种工具本身，那高先生错在何处啊，何以招致如此多人群起而攻之。在这我只想说一句话：你可以批评大象皮糙肉厚，身体笨重，行走缓慢不如你的骡子外观漂亮，身轻体健，奔跑如飞，我保证没人说你什么，但是如果你批评大象不如你的骡子鼻子长牙俏,我同样可以保证保险公司都不敢保你。点穴要点死穴才能要人命，希望高先生下一次能准一点。

washine (2002-5-16 20:39:35)

什么是好的建模工具？我认为其本身有多精辟或有多深奥并不重要，重要的是是否简单易懂。 为什么要建模呢？就是要越来越生动，便于理解，说得难听点，最好让傻瓜也一看就懂。 建模是给谁看的呢？并不是给软件设计者和项目经理看的，它是连接开发人员和客户的桥梁。 成功的建模应该具备极强的沟通能力及连贯性，条理清晰且容易接受。在这一点上UML明显先天不足（说老实话有很多程序员都看不懂更别说客户了）。从某种意义上说UML过于专业，熟悉面向对象的软件设计师或许能体会它的精妙，但从一般的客户及普通程序员来讲，他们需要的是一个生动的模型，而这个模型或许并不是UML。 国人有能力有魄力推出有价值的东西，我们为何不站出来给予支持呢？哪怕它仅有一个优点，也胜过一味地跟随。全程建模有他的可取之处，肯定也有许多不足之处（比如不够面向对象），但一般人（包括不懂设计的程序员）却更容易看懂它。我们要讨论的不是要用谁，摒弃谁，而是哪种方法更适合项目开发，给出更佳的效率。对任何事物都不要一棍子打死，难道就不能让它们共存么？

wangqiyy (2002-5-16 17:17:45)

各打50大板！ 1、人无完人，金无足赤。每一种软件工程方法都有其独到的特点和所要解决的问题，UML的方法着重业务模型的建立，而I2DEF的全程建模的思想确实不错，对于工具Rose和Playcase我都接触过。我认为UML主要在描述做什么，逐步逐步提升到怎么做，最后到内部的类，最后编程实现；而I2DEF的感觉就像是岗位责任书，每个角色各司其职，所有的责任和角色组成整个业务。如果单单使用某一表示方法，我还没有听说哪家公司成功过，例如Rational自己，它就有一系列产品（像什么Request之类的工具）支持，只有把这些都用上了，才有可能是解决软件工程问题的方法，而单独使用都是有缺陷的，Rose内部也是建议使用大量的文档嵌入来描述其细节和关系的。老实说，如果全部使用符合UML的工具来分析实现系统，我认为首先要解决的问题是成本（资金、时间），其次是思想的普及，只有深刻理解了UML的思想，才可能真正正确的是用它表示业务。 2、顺应潮流，如果和外界交流，用UML吧！英语比起我们的汉语，那算什么啊！原始的垃圾！但是老外都说，没办法，学呗！ 3、UML是发展的，它的存在是合理的。 4、与其在此争执孰是孰非，不如静下心，学习吧！

youyuan (2002-5-16 16:17:35)

看到此君的文章不禁想起了冯小刚电影《大腕》中那个搜狗网的c*o,他说要想网站要想火就要雇一帮写手，谁火啐谁，谁火灭谁，它就像这种写手，哈哈哈，我看他是想造个轰动效果，借以让自己成名，无聊的很，我想uml的用况在诞生时就已经说得很清楚: Use Cases are a critical technique in developing an application. Within the UML Use Cases are used primarily to capture the high level user-functional requirements of a system. This long winded description is important because Use Cases cannot usefully be used to capture non-functional requirements. Nor can they usefully be used to capture "internal" functional requirements. Attempting either or both is a sure path to disaster for two reasons. Firstly because Use Cases are an informal and imprecise modelling technique. But then they were never intended to be anything else. Secondly because the other use that we make of Use Cases is to define the fundamental structure of our application. The Use Case is not only important as a unit of requirement definition but also as our unit of estimation and our unit of work.

softdance (2002-5-16 12:20:58)

C++三大死穴 看了高先生的三大硬伤犹如提壶灌顶，真是顿觉自己愚笨。我的PlayC++ 已经诞生五年有余了，但一直是皇上老婆没人要，让我沮丧不已。但与PlayC++相比，C++是伤痕累累啊，经我以及清华的一些同事对C++的深入研究发现它的三大死穴。 一. 运行效率无与轮比的差。C++虽然编译速度挺快，但是运行效率却是太差，据我反复测试在同样的操作环境中比PlayC++慢了3-5倍。 二. 语言表达不够简练，丰富。别的且不说，就说程序的开始,C++ 用的是Begin.... end 格式，而且变量的声明以及函数的格式都太死板一点不灵活，根本无法满足我们多变的编程风格。反观我的PlayC++用花括号：{}代表开始结束，变量可以随用随叫，多么简洁。 三. 不支持面向过程编程。尽管目前是面向对象的天下，但是还是有很多场合要用面向过程的方法进行开发，例如最近非常火爆的CASE工具PlayCase就是一款优秀的过程工具。但是C++这一点做的太差，彻底抛弃了他们，采用了纯面向对象的方式，据我深入研究，C++的任何类型都是类结构，这对于广大的面向过程爱好者是及不公平的。不过不用担心，现在PlayC++可以让你为所欲为，它支持面向对象同样也没有忘记面向过程，这样你就可以用面向对象的语言来开发面向过程的设计，你以前的方法都可以保留。 当然C++也不是一无是处，例如它的垃圾回收功能，数组的上下界自动检测。但这些功能的实现是要付出代价的。 本文对C++攻击颇多，实际上PlayC++从C++获益匪浅，鄙人也是经过对C++非常深入的剖析，取长补短而建立了PlayC++，能有今天的成就理所应当向相关的面向对象大师们表示敬意。

wildhorseli (2002-5-16 9:40:03)

首先声明，本人不会写程序，本人用过高先生的东东（只是一个工具）；本人以为，UML只是一种符号，表达一种思想，正如高先生的东东一样，只是为了大家方便，清晰；以OO为思想，目的是代码的复用，可读，效率，适应外界的变化（这是重点）；本人认为UML的表达确实不错，本人不会写代码，但从用例上来看，清晰的很，业务清晰的很，一切看起来很自然，最起码你能感觉到是面向对象；由此可见，UML不在UML，在OO的功底，但从另一方面UML完全适应OO并且很适应，PlayCase或其他，我觉得大家完全可以用word，当然高先生可以用wps（国产的），甚或用草纸一样做出大家都能理解的UML；

zergcom (2002-5-15 18:22:49)

什么样的人可以评论UML： 1。真正了解和熟悉UML的人，而不是仇视UML的人。 2。用UML真正做过应用的人，而不是纸上谈兵的人。 3。能提出更好方案的人，而不是吹毛求疵的人。 4。不是井底之蛙的人。

hamzsy (2002-5-15 16:44:57)

高先生的PLAYCASE早就开始用了，除非不得已，用户有要求，否则我是不会用UML的，可能是我没有很好的理解UML的缘故。高先生的观点我很容易接受，所以PLAYCASE也用的很顺畅。 UML确实很好，由于其是面向对象的，在分析时整体把握还可以，遇到一些细节时就有点力不从心了，而往往这些细节是项目成败的关键。——很少有软件整体把握出错的！高先生的话或许有些偏激，但您有没有具体的思考过是不是真象他说的那样“糟糕”。希望大家不要象许多老百姓那样给人“害怕新事物”的感觉。也难怪，国产软件在程序员中的地位确实比较低啊！但PLAYCASE绝对是国产中的精品，虽然她还没有长大！大家还是来多关心关心他吧，不要老是躺在别人的床上高枕无忧！

lwd2k (2002-5-15 13:20:56)

原来作者是playcase的作者，在此表示敬意。我学习使用playcase，觉的简单易用，生成代码很好，所以一直有一个版本保存。但出于商业和拓展市场的需要，用户要求的文档应符合UML标准，其实Visio功能比Rose多，但由于介绍Rose的书多，所以就用了Rose. 对于分析工具来说，做为用户，分析员，程序员之间的交流工具，只要说清楚了问题，不必看是用了什么方法。但目前来说，本人非常相信UML，所以一直想弄好它.

mach (2002-5-15 13:06:43)

使用UML可以清楚的描述业务流程，但不是用序列图，而是活动图，对于高先生的全程建模我还不太理解，粗浅的认为大概就是标准的RUP过程加上其中作为选项的业务建模吧。至于用活动图描述业务流程，这是肯定可以的，而且很方便，用活动图可以非常清楚地定义工作流，不仅可以在业务层次上抽象，包括在其后的系统分析、设计过程中，可以继续细该活动图得到业务过程的具体实现方式。从高先生文章中的论述，和其对用例图、序列图的使用方法来看，可以断定，高先生对UML还不是太了解。至于Playcase，我只是下载过，不是很理解其中应用的方法论，因此没有资格对其进行评价。

jnwen (2002-5-15 11:28:07)

我觉得关键是语言还没有对信息流很好的支持,什么面向对象的建模方法都不好,面向过程的方法最自然.

JohnYale (2002-5-15 10:40:32)

平心而论，高先生的PlayCase是比较少见的优秀产品（至少在国内），肯定花费了高先生很大的心血，但不被市场认可，我们应该考虑这是什么原因？如果说国内公司不相信国内公司的产品尚可解释的话，可是世界上那么多大公司，为什么鲜有发现PlayCase的？PlayCase使用的IDEF(具体拼法已记不清了)，在国内只发现一本书予以介绍，与连篇累牍的介绍UML的书籍形成巨大反差，难道真的是整个IT业都错了？真理往往掌握在少数人手里？

HYhuyan (2002-5-15 9:30:13)

众人皆醒我独醉 1.任何技术上的争论我们都应该支持； 2.任何带有利己目的的攻击我们都应该鄙视。

fltwt (2002-5-15 9:13:07)

只是觉得原作者还没有很好的理解UML。也没有真正的用过UML。从这篇文章中，看得出作者很推崇结构化，看不出面向对象。 UML的核心应该是建立在面向对象上的吧。用UML进行面向过程的系统设计开发，好象牛头不对马嘴。

mis98zb (2002-5-15 8:28:54)

不过RUP几大核心工作流之间的衔接、UML几大视图的演化，以及业务模型到实现模型的转化，确实很少有讲解的资料，这也使得现实中ROSE建模缺乏连贯性。

JohnYale (2002-5-14 23:47:36)

众人皆醉我独醒。高展先生为了推广 全程建模方法，几年来一直极力攻击UML, 其执着比麦克尼利有过之而无不及，在如今建模方面尚无完美方案的情况下，全程建模方法 无疑是当今世上绝无仅有的、至高至上的、无可匹敌的解决方案，是中国软件的代表，高展先生万岁万岁万万岁！！！ 2年（？）前，鄙人初次接触PlayCase, 就发现PlayCase有许多优点，但由于本人愚鲁，未能成功说服公司采用PlayCase（老板是蠢材？），致使公司现在一直使用Rose建模（边用边摸索），真是罪该万死。没有办法，市场决定一切。高展先生，您的PlayCase卖了几套了？

//www.csdn.net/develop/Article/13/13680.shtm CSDN是技术交流与传播的平台，我们鼓励技术的讨论与争论。 我们不会因为不同意别人的观点而删除任何文章，只会删除人身攻击和粗言秽语等有污视听的帖子。

ripper (2002-5-14 21:27:48)

使用UML描述业务流程很难让人放心，因为描述业务流程时产生的遗漏、不一致、不完整，同样会给项目带来灾难。这是纠缠不清的胡子工程问题点之二 看看这句话，再看看下面对比用的图，高展这老小子连顺序图是做什么的都没有搞明白就信口开河

讨论文章见：UML 谁的硬伤 http://www.csdn.net/develop/Article/13/13680.shtm


UML的现状及未来发展

山东大学研究生网站 leeke

--------------------------------------------------------------------------------

    UML是在多种面向对象建模方法的基础上发展起来的建模语言，主要用于软件密集型系统的建模。它的演化，可以按其性质划分为以下几个阶段：最初的阶段是专家的联合行动，由三位OO（面向对象）方法学家将他们各自的方法结合在一起，形成UML 0.9。第二阶段是公司的联合行动，由十几家公司组成的“UML伙伴组织”将各自的意见加入UML，形成UML 1.0和1.1，并作为向OMG申请成为建模语言规范的提案。第三阶段是在OMG控制下的修订与改进，OMG于1997年11月正式采纳UML 1.1作为建模语言规范，然后成立任务组进行不断的修订，并产生了UML 1.2、1.3和1.4版本，其中UML 1.3是较为重要的修订版。目前正处于UML的重大修订阶段，目标是推出UML 2.0，作为向ISO提交的标准提案。
    在多种面向对象建模方法流派并存和相互竞争的局面中，UML树起了统一的旗帜，使不同厂商开发的系统模型能够基于共同的概念，使用相同的表示法，呈现彼此一致的模型风格。而且它从多种方法中吸收了大量有用（或者对一部分用户可能有用）的建模概念，使它的概念和表示法在规模上超过了以往任何一种方法，并且提供了允许用户对语言做进一步扩展的机制。
    UML在语法和语义的定义方面也做了大量的工作。以往各种关于面向对象方法的著作通常是以比较简单的方式定义其建模概念，而以主要篇幅给出过程指导，论述如何运用这些概念来进行开发。UML则以一种建模语言的姿态出现，使用语言学中的一些技术来定义。尽管真正从语言学的角度看它还有许多缺陷，但它在这方面所做的努力却是以往的各种建模方法无法比拟的。
    从UML的早期版本开始，便受到了计算机产业界的重视，OMG的采纳和大公司的支持把它推上了实际上的工业标准的地位，使它拥有越来越多的用户。它被广泛地用于应用领域和多种类型的系统建模，如管理信息系统、通信与控制系统、嵌入式实时系统、分布式系统、系统软件等。近几年还被运用于软件再工程、质量管理、过程管理、配置管理等方面。而且它的应用不仅仅限于计算机软件，还可用于非软件系统，例如硬件设计、业务处理流程、企业或事业单位的结构与行为建模。
    不过UML在取得巨大成功的同时，也不断地受到批评。来自工业界的批评主要是，它过于庞大和复杂，用户很难全面、熟练地掌握它，大多数用户实际上只使用它一少部分的概念；它的许多概念含义不清，使用户感到困惑。来自学术界的批评则主要针对它在理论上的缺陷和错误，包括语言体系结构、语法、语义等方面的问题。
    目前国内也有不少软件企业在学习并尝试使用UML。从总体上看，我国计算机界对UML的了解还相当初步，但是对它的崇拜程度却远远超过了西方发达国家。人们在学习和使用UML遇到和国外用户相同的疑难和困惑时，却不太敢怀疑UML有什么问题。所以国内几乎没有批评的声音，偶尔有一点，也会立即被捍卫的声音淹没，即使对UML一些最明显的缺点和错误也是如此。
    相比之下，国际上对UML的讨论和评价则要客观得多。无论是Internet上的意见交流，或是每年一次的UML研讨会，还是学术期刊上发表的文章，都是既肯定其成绩，又指出其缺点和错误，并且以积极的态度提出建设性意见。在酝酿UML下一次的重大发布和筹划UML 2.0作为ISO标准提案的最近两年内，围绕UML的讨论更为活跃和热烈。

    为了使我国计算机界对UML目前的状况有较为客观的了解，我们从大量的文献资料中选择了三篇最具权威性的文章，介绍给我国读者。从这组文章中，我们可以得到关于UML现状及未来发展的重要信息：
    ● UML已经取得重要成功，它已成为在软件工业中占支配地位的建模语言，并在许多领域的软件开发中得到应用。
    ● UML还存在许多问题，自它产生之日起就从未离开过批评：用户和教师抱怨它内容庞大、难学难教而且太过复杂;学者认为它缺少一个精练的核心和定义良好的外围，有些语义定义得不够精确而且带有二义性;建模实践者认为它缺少支持自己领域建模要求的机制;工具开发商则因为规范本身的不确定性而产生理解上的偏差，它们对UML的自行诠释有可能误导用户。
    ● UML的关键问题是过于庞大和复杂，以及在语言体系结构、语义等方面存在理论缺陷。产生这些问题的一个重要原因是，在形成规范的过程中不得不照顾多种方法流派的观点和多家公司的利益。

为了UML的下一次重大发布，UML 2.0修订的主持者正在广泛收集各方面的意见。各界都给予了很高的关注，提出的意见涉及UML的各个方面。其中一个关键问题是UML是否需要简化，以及如何使之更精练，最终大部分意见是提供一个精练的核心，而把不常用的内容放到定义良好的外围或扩展机制中。此外，UML 2.0还将对UML的底层结构、上层结构和对象约束语言（OCL）做重大改进。

(附注：我在网上搜寻了，但没有找到文中所提的三篇文章

Blueski）


支持UML的CASE工具概览

// Blueski 制作
// 2001/02/20

CASE是Computer-Aided Software Engineering的缩写。国外已经有大量的CASE工具，在不同层次上提供对UML的支持。国内的CASE工具比较有名的我只听说过青鸟系统。支持UML的系统应该包括创建和管理UML图、各种语言的代码生成，以及将源代码通过反向工程加入到UML中，等等。

以下是一部分主要的CASE工具的列表，点击相应的连接可以访问各提供商的站点并查看详细介绍。

产品 | 公司
Argo/UML (Free) | Tigris
Rational Rose 2000 | Rational Software
GDPro | Advanced Software Technologies
SELECT Enterprise | Princeton Softech
Together | TogetherSoft
With Class | MicroGold
System Architect 2001 | Popkin Software
Platinum Paradigm Plus | Computer Associates
Software through Pictures/UML | Aonix
Visio 2000 | Microsoft
MagicDraw UML | No Magic
Visual UML | Visual Object Modelers
UMLStudio | PragSoft
JVISION | Object Insight
SoftModeler | Softera
UML Studio | Stingray (Rogue Wave)
Objecteering/UML | SOFTEAM
MetaEdit+ | MetaCase Consulting

以上只是一个导航，这里无法提供更多的比较。众所周知的是Rational的统一过程方法占据占据主导地位。一般认为，UML CASE工具应该有一些共同的特性：

· 方便地制图及纠错

· 管理模型的信息，修改具有关联性

· 在模型元素之间易于导航

· 支持多用户协同工作

· 支持代码框架生成

· 支持逆向转换，即由代码生成模型

· 支持更多的开发环境

· 其它

目前的CASE工具可能并不相互兼容。由此也产生了模型互换的概念，就是某个工具产生的模型要能够应用到其它工具中去。各种工具一般都是用自己的数据库来保存模型信息，而实现模型互换的前提是将这样的存储模型的格式标准化，标准化的益处是显而易见的，但是目前还没有相应的标准。

应该说UML还在不断完善与发展之中。UML 1.3 于1999/11被Object Management Group (OMG) 采纳， UML 1.4于2000年下半年完成, 并可能于近期被接纳。UML 2.0 RFP早已经被广泛讨论，并可能在2001的某些时候完成。而以上工具也将随着UML的发展而发展了。


UML建模风格之状态图

LinuxAid.com.cn axing译
2002-06-20

UML状态图描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的：

研究类、角色、子系统、或组件的复杂行为。
建模实时系统。

指南∶

概要

当行为的改变和状态有关时才创建状态图。

把初始状态放置在左上角。

把最终状态放置在右下角。

状态指南

状态名称要简单但应具有描述性。

避免"黑洞"状态。

避免"奇迹"状态。

子状态建模指南

为复杂的目标建模子状态。

把通用的子状态变换放在一起

为复杂的实体创建一个分层的状态图

最高阶的状态图总有初始态和最终态

变换和动作

用实现语言的命名规则命名软件动作

用叙述性文字命名角色动作

只有对所有的入口变换都合适时才注明入口动作

只有对所有的出口变换适合时才注明出口动作

只有当你想终止并再进入该状态时才建模递归变换

用过去式命名转换事件

把转换标记放在接近源状态的地方

以转换方向为基础放置变换标记

警界点

警戒点不应该重叠

为可视化的定位警戒点而引入接合点。

警戒点不必配套

一致的命名警戒点

通用准则

当行为的改变和状态有关时才创建状态图。

敏捷建模( AM) ( Ambler 2002)的原则－－最大化项目干系人的投资－－建议你只有当模型能够提供正面价值的时候才创建模型。 如果一个实体，比如一个类或组件，表示的行为的顺序和当前的状态无关，那么画一个UML状态图可能是没有什么用处的。例如一个SurfaceAddress类就很简单，表示了那些你将会在系统中显示和操作的数据，因此一个UML状态图就没有任何相关之处。而一个Seminar对象就非常的复杂，学生注册这样一个事件将会根据它的当前状态有不同的反应，就像你在图１中看到的。

图⒈班级注册的一个UML状态图。

把初始状态放置在左上角。

如你在图１所见的，初始状态被建模成一个实心圈，把初始状态放在左上角反映西方人的阅读文化的习惯。

把最终状态放置在右下角。

如你在图１所见，最终状态被建模为一个带边界的实心圆。把最终状态放右下角反映了西方的文化的从左到右，从上到下的阅读习惯。

状态指南

状态是一个实体的行为模式的某个阶段。 状态的表示是通过实体的属性值。 例如，在图１中，当seminar被标记为open，并且存在空位的时候，seminar就处于Open For Enrollment的状态。

状态名称要简单但应具有描述性。

象Open For Enrollment和Proposed这种的状态名称很容易理解，从而提高了图⒈的沟通价值。理论上状态名称应该是现在时，但是用过去式写成的诸如Proposed的名称要比用现在时写成的诸如Is Proposed的名称好的多。

避免"黑洞"状态。

黑洞状态是那种只有变换进来但没有任何变换发出的状态，这种情况要么由于该状态是一个最终状态，要么就是你已经错过了一个或多个变换变换。

避免"奇迹"状态。

奇迹状态是那种只有变换发出但没有任何变换进来的状态，这种情况要么由于该状态是一个起点，要么就是你已经错过了一个或多个变换变换。

子状态建模指南

为复杂的目标建模子状态。

图１中展示的UML状态图是不完整的，因为它没有建模Seminar的post - enrollment（注册后）状态。 图２建模了一个Seminar的完整的生命周期，把图１描述为一个新的包括子状态集合的Enrollment的复合状态，也称作超状态。 注意按理说你会像图１的模型那样处理标记，但为了简化起见在原先变换上的标记都没有包括在内。当一个现有状态表现出复杂的行为时，建模子状态就是有意义的，从而促使你来研究它的子状态。 当几个现有状态共用一个通用的入口条件或出口条件( Douglass 1999)时，引入超状态是有意义的，在图１中你可以看到所有的状态共用一个通用的closed变换，以到达最终状态。

图⒉Seminar的完整生命周期

把通用的子状态变换放在一起

和图１中每一个子状态都拥有一个cancelled变换不同，在图２中你可以看到cancelled变换仅用于描述Enrollment超状态，这使图形得到简化。 如果子状态都共享一个入口变换或出口变换，都可以使用一个同样的方法。 变换上的警戒点和动作（如果有）也应该使相等的。

为复杂的实体创建一个分层的状态图

虽然这种表现子状态的方法是很好使的，但是最终的图可能变得相当复杂－－我们只要设想一下如果Being Taught状态也有子状态的话，图２会变成什么样就知道了。 一个替代的方法是创建一个分层的UML状态图。 例如，图３表示高阶视图，而图１描述了一个细节视图。这种方法的好处是如果需要的话，马上就可以建立一张详图来研究Being Taught状态。

图⒊Seminar的高阶状态图。

最高阶的状态图总有初始态和最终态

一个高阶的UML状态图，例如图2描述的这样，应该表示实体的完整的生命周期，包括"出生"和最后的"死亡"。 低阶的图未必包含初始状态和最终状态，特别是那些建模一个实体的生命周期的"中间状态"的图。

变换和动作

变换是从一种状态到另一种状态的序列，它可能是通过一个事件触发的。简而言之就是被建模的实体的内部或外部的行为。 对一个类来说，变换一般是将会导致状态的重要改变的操作调用的结果，因此我们需要了解一点，并不是所有的方法调用都会导致变换产生的，这一点非常重要。 一个动作就是某个东西，对类来说就是一个操作，被建模的实体所调用的操作。

用实现语言的命名规则命名软件动作

图１中的动作遵循Java操作的命名规则( Vermeulen et. 2000)，因为系统使用Java做为实现语言，如果我们的目标是两外一种语言，那么我们也需要遵循适当的命名规则。

用叙述性文字命名角色动作

UML状态图可用于建模非软件实体的生命周期，特别是UML图上的角色。 例如学生角色就可能有诸如Accepted、Full Time、Part Time、Graduated、Masters、Doctoral、和Post - Doctoral等状态，以显示各人的不同行为。 当你在建模现实世界的角色时，与软件中Student类不同的是，状态间的变换最好是使用叙述性文字来描述，例如drop seminar和pay fees，而不是dropSeminar ()和payFees ()，因为现实生活中的人是做事情，而不是执行操作。

只有对所有的入口变换都合适时才注明入口动作

在图１中你可以看到Closed To Enrollment状态的入口中操作notifyInstructor ()都是经由entry/动作标记来调用的。 这暗示着每次进入状态时都需要调用该操作，如果你不希望每次都发生，那么就把动作关联到特定的入口变换。 例如，addStudent ()动作是在student enrolled变换到Open For Enrollment变换发生，而在到opened变换则不会发生，这是因为每次你在进入该状态并不需要增加一个学生。

只有对所有的出口变换适合时才注明出口动作

出口动作，用exit/标记来表示，工作方式类似于入口动作。

只有当你想终止并再进入该状态时才建模递归变换

一个递归的变换是那些两个端点都拥有相同状态的变换。 一个重要的暗示是实体从状态出来，又回到原有的状态，因此，那些由于entry/或exit/动作标记而被调用的任何一种操作都可能被自动调用。 图１的Open For Enrollment状态就是这种递归变换的例子，因此当前班级大小就在入口处被记录下来。

用过去式命名转换事件

图１中的转换事件，例如seminar split和cancelled，是使用过去式命名的，反映了这样一个事实：变换是事件的结果－－因为事件发生在变换之前，因此应该用过去式命名。

把转换标记放在接近源状态的地方

虽然图１比较复杂，变换标记尽可能放在靠近来源的地方，例如seminar split和student enrolled。 Furthermore, the labels were justified (left and right respectively) to help visually place them close to the source state.

以转换方向为基础放置变换标记

为了更易于判断哪个标记和变换是一起的，按照如下的规则来放置变换标记：

在变换线条上的从左到右。
在变换线条下的从右到左。
变换线条右边的往下。
变换线条左边的往上。

警戒点

一个警戒点是为了穿过一个转换而必须为真的一个条件。

警戒点不应该重叠

离开状态的相似变换上的警戒点必须彼此一致。 举例来说，x <0, x = 0,以及x > 0的警戒点是一致的，而x < = 0和x > = 0的警戒点就不是一致的，因为他们重叠了，它并没有明确的指出当x为0时将发生什么。在图1中，你可以看到警界点的一致性，从填写注册表活动出发的该学生划线变换上的警戒点没有重叠，决策点上的警戒点也一样。

为可视化的定位警戒点而引入接合点。

在图２中你可以看到从Being Taught触发student dropped事件存在两个变换，而图３中仅有一个，变换被合并了，因此我们需要一个接合点（填满的圆）。 这种方法的好处是现在图上的两个警戒点更彼此接近了，更容易看出警戒点是否重叠。

警戒点不必配套

一个状态的变换警戒点有可能是不完整的。例如，一个bank account对象可能从Open状态变换到Needs Authorization状态，这时需要一个大额存款"large deposit"的警戒点。可是，一个带有"small deposit"的警戒点的deposit变换可能并不需要建模，它是被隐含的，我们遵循了AM的实践－－简单的描述模型和仅仅包括相关的信息。

一致的命名警戒点

图１包含了诸如seat available和no seat available的警戒点，两个警戒点的描述是一致的。 然而，诸如seats left、no seat left、no seats left、no seats available、seat unavailable之类的描述就是不一致，而且难于理解的。


UML学习笔记(1)

UML学习笔记

1.建模

1.1 为什么要建模

建立大厦和建立狗窝的区别是建设狗窝不需要设计。要生产合格的软件就要有一套关于体系结构、过程和工具的规范。

建模的定义：建模是对现实的简化。

建模的目标：
1）模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。
2）模型允许我们详细说明系统的结构和行为。
3）模型给出一个知道我们构造系统的模板。
4）模型对我们的决策进行文档化。

建模就是把复杂的系统变成小的系统，采用“各个击破”的原则逐一解决。

1.2 建模原理

1）选择创建什么模型很重要，模型要反映你难于处理的开发问题。
2）模型要在不同的精度级别上来表示。你可以根据观察的角色和观察的原因来选择精度。
3）建造模型要和现实相连。
4）重要的系统需要用一组独立的模型去处理。在面向对象的软件体系中，为了理解系统的体系结构，你需要几个互补和连锁的视图：用例图、设计视图、进程视图、实现视图和实施视图。

1.3 面向对象的建模

面向算法的建模在需求发生变化或者系统增长后就变得难以维护。

面向对象的建模把对象和类作为其主要构造块。例如，在三层结构中，我们可以在用户接口层、中间层和数据库层中找到你想要的对象。

2 UML介绍

2.1 概述
UML可以对软件密集型系统的制品进行可视化、详述、构造和文档化。最好把它用于以用况（用例）为驱动、以体系结构为中心、跌代及增量的过程中。

UML是一种语言，它是一种可视化的语言，它是一组图形符号。它可用于详细描述。它又是一种构造语言，可以直接生成代码。用Rational XDE就可以实现从UML到C#，或者从C#到UML的双向工程。

2.2 UML的概念模型
学习建模的三个要素：UML的基本构造块、这些构造块放在一起的规则、一些运用于整个UML的公共机制。

UML中由一些四种事物
1）结构事物 －－－ 类、接口、协作（它是一个交互，它是由一组共同工作以提供某协作行为的角色和其它元素构成的一个群体。）、用例、主动类（至少拥有一个进程或者线程，其元素的行为可以和其它元素的行为并发）、构件（如COM+和Java Bean）、节点。
2）行为事物 －－－ 交互、状态机（描述了一个对象或者一个交互在生命期内响应事件所经历的状态序列）。
3）分组事物 －－－ 包
4）注释事物 －－－ 注解

UML中的四种关系
1）依赖 －－－ 两个事物间的语义关系
2）关联 －－－ 是一种结构关系，如聚合
3）泛化 －－－ 一般/特殊关系
4）实现 －－－ 用在两种地方：接口和实现他们之间的类和构件之间；用例和实现他们的协作之间。

UML中的图
1）类图 －－－ 系统的静态状态图，包含主动类的类图给除系统的静态进程视图。
2）对象图
3）用例图
4）顺序图
5）协作图
6）状态图
7）活动图 －－－ 强调对象间的控制流程
8）构件图
9）实施图

2.3 体系结构

我们用5个互联的视图来描述软件密集型系统的体系结构：

1）系统的用例图
2）系统的设计视图 －－－ 静态方面由类图和对象图描述，动态方面由交互图、状态图和活动图描述。
3）系统的进程视图 －－－ 包含了形成系统并发和同步机制的线程和进程。
4）系统的实现视图 －－－ 主要针对系统发布的配置管理。
5）系统的实施视图

2.4 软件开发生命周期

用况驱动
以体系结构为中心
跌代过程 －－－ 涉及到一连串可执行发布的管理。

软件开发生命周期的四个阶段：
初始
细化
构造
移交

3 Hello World

4 类

4.3.1 对系统的词汇建模

需要做如下工作：
1）识别用户用于描述问题或解决问题的事物。
2）对于每个抽象，识别一个职责集。
3）提供为实现每个类的职责所需的属性和操作。

4.3.2 对系统中职责的分布建模

抽象出来的类要适中，不要过大过小。

需要如下工作：
1） 识别一组为了完成某些行为而紧密协同工作的类。
2） 对上面的每一个类识别出一组职责。
3） 从整体上观察这些类，过大的分解，过小的合并。
4） 考虑相映的协作方式，重新分配职责。

5 关系

面向对象建模中三种最重要的关系：

依赖 －－－ 使用关系
泛化 －－－ 一般/特殊关系
关联 －－－ 结构关系

当你开始建模是，特别是解决这些对象的动态协作时，你还会遇到两种其它的关系：链（可能发送消息的对象间的实例）和转换（状态机中不同状态的连接）

对简单依赖建模 －－－(如一个类作为另一个类的参数) 依赖从操作的类指向当作参数的类。
对单继承建模
对结构关系建模

6 公共机制

四个公共机制可以使UML简化:详述、修饰、公共划分和扩展

构造型、标记值和约束使UML提供的用以增加新的构造块、创建新的特性以及描述新的语义的机制。

7 图

有5种最重要的互补视图：用例视图、设计视图、进程视图、实现视图和实施视图

每一种视图包含结构建模（静态）和行为建模（动态）

建图的两种方法：正向工程和逆向工程

一些术语：
系统:由子系统组成； 子系统:由元素组成； 模型:对现实的简化； 视图:对系统模型的组织和结构的投影，注重于系统的一个方面。

结构图：类图、对象图、构件图、实施图。
行为图: 用况图、顺序图、协作图、状态图、活动图。

顺序图和协作图统称交互图。顺序图强调消息的时间次序，协作图强调收发消息的对象的结构组织。

活动图强调对象之间的控制流。

如何选择视图来建模？
1）视图能够表达系统的体系结构，能够暴露项目的技术风险。
2）决定用哪些制品来捕获视图的基本细节。
3）作为你的过程策略的一部分，决定把那种视图至于某种形式或者半形式的控制之下。
4）保留废弃的视图。

两种系统建模的方法：
1）针对同一模型，用不同层次上的细节描述图。
2）在不同的抽象层次上，从一个模型跟踪到另一个模型的方法建模。

8 类图

类图包括如下内容：

类
接口
协作
依赖、泛化和关联关系。

对系统的静态设计视图建模时使用类图的3种方式：
1）对系统的词汇建模
2）对简单协作建模 －－－ 协作提供的一些合作行为强于其所有元素行为之和。
3）对逻辑数据库模式建模

9 高级类

在UML中更一般的构造块是类元，类元包括：类、接口、数据类型、信号、构件、节点、用况和子系统。他是描述结构特性和行为特性的机制。


UML要点与应用

● 王立福 (CCW站点)

--------------------------------------------------------------------------------

---- UML(Unified Modeling Language)伙伴组织于1996年由Rational公司创立。对象管理组织（OMG）于1997年11月采纳了它。此后，UML继续改进，目前最新的版本是UML1.3。 UML是多种方法相互借鉴、相互融合、趋于一致、走向标准化的产物。这样的统一建模语言将为软件开发商及其用户带来诸多便利。美国等计算机技术发达国家已有大量的软件开发组织开始用UML进行系统建模，学习和使用UML已经成为一种潮流。我国软件界对UML 也相当关注，许多研究人员和技术人员已在几年前就开始了对UML的学习和研究。

----现在有更多的人想学习UML，但由于UML的复杂性，仅通过UML的标准文献和国内目前的关于UML的资料来掌握使用它不是一件轻松的事。对它的使用，关键是要用它简明准确地建立模型。这样，人们就可以从全局把握复杂系统的全貌及其组成间的联系。为了达到这样的目的，本文要阐明UML的要点，并对UML所推荐的软件建模过程RUP（Rational Unified Process）做一简介，以作为一种应用UML的过程指导。

----UML的定义有两个主要组成部分：语义和表示法。UML 的语义用自然语言描述，表示法定义了UML的可视化标准表示符号，这决定了UML是一种可视化的建模语言。这些图形符号和文字用于建立应用级的模型，在语义上，模型是元模型的实例。此外UML的定义还给出了语法结构的精确规约。对于一般建模者，应重点掌握基本的概念与表示法，并熟练运用它们，建立元模型则是研究方法学的人的研究重点。

----要点：对系统的组织

----UML是一种可视化的建模语言，对其各建模元素可进行详细说明，并能生成所建模型的文档。使用UML时，要从不同的角度观察系统，为此定义了一个概念“视图”。视图是对系统的模型在某方面的投影，注重于系统的某个方面。每个视图是图的协作，UML定义了9种图。下表是UML中的5种视图，各视图在静态和动态方面表示了系统的模型。

----用况视图由用况图组成，描述可被最终用户、分析人员和测试者看到的系统行为；设计视图包含类图、对象图、交互图、状态图和活动图，主要反映系统的功能需求；进程视图包含类图、对象图、交互图、状态图和活动图，主要描述形成系统并发与同步机制的线程和进程；实现视图包含构件图、交互图、状态图和活动图，反映用于装配与发布物理系统的构件和文件，主要针对系统发布的配置管理，可以用各种方法装配它们。部署视图包含部署图、交互图、状态图和活动图，主要描述对组成物理系统的部件的分布、交付和安装。根据实际需要，可以组合使用这些视图。

----由视图可以定义模型，模型在语义上是闭合的，它从特定的角度（系统的规约或者设计）在一定抽象层次上描述目标系统。可以把视图组织成模型，开发人员可从各视角观察使用模型。

----用以描述系统的模型可以是结构性的，强调系统的组织；也可以是行为性的，强调系统的动态方面。例如，RUP有9种模型，分别是业务模型、领域模型、用况模型（也称需求模型）、分析模型、设计模型、过程模型、部署模型、实现模型和测试模型，用于从不同的角度表示系统。

----系统是一组反映不同侧面的子系统的集合，为了完成特定的目的要对这些子系统进行组织（在逻辑、功能和物理位置上是高内聚、低耦合的）。

----子系统是一组元素的聚集，其中的元素还可以是子系统。它由一组模型从不同的角度进行描述。子系统本身几乎应是独立的，有自己应用的环境，相互间不重叠，它们之间用接口联系。

UML的概念模型
----为了理解UML，需要掌握UML的概念模型，这要求学习三个要素：UML的基本构造块、支配这些构造块如何放在一起的规则和一些运用于整个UML的机制，下面逐一予以介绍。
----1. 基本构造块

----UML中有三种基本构造块，分别是事物、关系和图。

----事物分结构事物（包括类、接口、协作、用况、主动类、构件和节点）、行为事物（包括交互和状态机）、分组事物（包）和注释事物（注解）。

----UML中有四种关系，分别是依赖、关联、泛化和实现关系。

----对于上述两种构造块，通过研读相应的书籍，绝大多数不难掌握，这里就不再赘述。下面对UML中的图的要点进行阐述。

----类图 类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图——专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和操作。

----对象图 对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。

----用况图 用况图展现了一组用况、参与者以及它们间的关系。可以用用况图描述系统的静态使用情况。在对系统行为组织和建模方面，用况图的是相当重要的。

----交互图 交互图展现了按一定的目的进行的一种交互，它由在一个上下文中的一组对象及它们间交互的信息组成。交互图也可用于描述一个用况的行为。顺序图和协作图都是交互图，顺序图和协作图可以相互转换。

----顺序图　展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。用顺序图说明系统的动态视图。

----协作图　展现了一组对象，这组对象间的连接以及这组对象收发的消息。它强调收发消息的对象的结构组织，按组织结构对控制流建模。

----状态图　展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用况实例的生命周期。

----活动图　活动图是一种特殊的状态图，描述需要做的活动、执行这些活动的顺序（多为并行的）以及工作流（完成工作所需要的步骤）。它对于系统的功能建模特别重要，强调对象间的控制流程。

----高层活动图用于表示需要完成的一些任务，即用于分析用况，理解涉及多个用况的工作流、多线程及并行，显示相互联系的行为整体，还可用于对企业过程建模，对系统的功能建模。低层活动图用于表示类的方法。但活动图不适用于描述动作与对象间的关系，显示对象间的合作以及显示对象在生命周期内的运转情况。

----构件图　构件图展现了一组构件之间的组织和依赖，用于对原代码、可执行的发布、物理数据库和可调整的系统建模。

----部署图　部署图展现了对运行时处理节点以及其中构件的配署。它描述系统硬件的物理拓扑结构(包括网络布局和构件在网络上的位置)，以及在此结构上执行的软件（即运行时软构件在节点中的分布情况）。用部署图说明系统结构的静态部署视图，即说明分布、交付和安装的物理系统。

----2. 运用构造块的规则

----UML用于描述事物的语义规则分别是：为事物、关系和图命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。另外， UML还允许在一定的阶段隐藏模型的某些元素、遗漏某些元素以及不保证模型的完整性，但模型逐步地要达到完整和一致。

----3. 机制

----有四种在整个语言中一致应用的机制，使得该语言变得较为简单。这四种机制是详细说明、修饰、通用划分和扩展机制。

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

----UML表示法中的每一个元素都有一个基本符号，这些图形符号对元素的最重要的方面提供了可视化表示，对元素的描述还包含其他细节。例如，一个类是否是抽象类，或它的属性和操作是否可见。要把这样的修饰细节加到基本符号上。

----在对面向对象的系统建模中，至少有两种通用的划分世界的方法：对类和对象的划分；对接口和实现的划分。UML中的构造块几乎都存在着这样的两分法。

----UML是开放的，可用一种受限的方法扩展它。UML的扩展机制包括构造型、标记值和约束。

----UML的应用

----UML是一种建模语言，不是一种方法，它独立于过程。利于它建模时，可遵循任何类型的建模过程。该建模语言的作者们给出了一种推荐性的建模过程指导，即RUP。本部分阐述RUP如何支持UML的应用。

----RUP是以用况为驱动、体系结构为中心、迭代和增量的过程。RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流（包括5个活动），请参见下图。

----用况驱动旨在为到最终产品为止的每个阶段都可以回溯到用户的真正需求。以体系结构为中心是指关注体系结构模式的开发，以引导后续系统，保证系统的平滑演进。每一次迭代包括迭代计划、迭代评价和一些具体活动。关于核心工作流中的五个活动：需求、分析、设计、实现和测试较好理解，这里不再赘述。下面对RUP的四个阶段要做的工作做一阐述。

----1. 初始阶段

----本阶段确定所设立的项目是否可行，具体要做如下工作：

对需求有一个大概的了解，确定系统中的大多数角色和用况，但此时的用况是简要的。对给出的系统体系结构的概貌，细化到主要子系统即可。
识别影响项目可行性的风险。
考虑时间、经费、技术、项目规模和效益等因素。
关注业务情况，制订出开发计划。
----2. 细化阶段

识别出剩余的大多数用况。对当前迭代的每个用况进行细化，分析用况的处理流程、状态细节以及可能发生的状态改变。细化流程时，可以使用程序框图和合作图，还可以使用活动图、类图分析用况。
对风险的处理。
----需求风险 考虑项目的目标是否偏离了用户的需求。为解决需求风险要充分了解用户需求以及各需求的优先度，还应尽量列出所有的用况，至少列出重要的用况，并要建立领域的概念模型。

----技术风险 考察所选的技术方案是否可行。建立原型是解决技术风险的一种有效方法。

----技能风险 考虑实施项目的人员素质能否胜任项目的要求。

----政策风险 考虑政策性的因素对项目的影响。

----● 进行高层分析和设计，并作出结构性决策。

----所产生的基线体系结构包括用况列表、领域概念模型和技术平台等。以后的阶段对细化阶段建立的体系结构不能进行过大的变动。

----● 为构造阶段制订计划。

----细化阶段完成，意味着已经完成了如下的任务：用况完全细化并被用户接受；完成概念验证；完成类图；开发人员能给出项目估算（可分为精确、人月和无法估算）；基于用况考虑了所有风险（可分为高风险、可能的风险和不可能的风险），并制订了相应的对策和计划；对用况标出优先级（可分为必须先实现、短期内实现和长期实现）。

----3. 构造阶段

----识别出剩余的用况。每一次迭代开发都针对用况进行分析、设计、编码（如类声明、属性声明、范围声明、函数原型声明和继承的声明等）、测试和集成过程，所得到产品满足项目需求的一个子集。由于细化阶段的软件设计已经完成，这样各项目组可以并发开发。

----在代码完成后，要保证其符合标准和设计规则，并要进行质量检查。对于新出现的变化，要通过逆向工具把代码转换为模型，对模型进行修改，再重新产生代码，以保证软件与模型同步。

----此阶段要建立类图、交互图和配置图；如一个类具有复杂的生命周期，可绘制状态图；如算法特别复杂，可绘制活动图。

----4. 移交阶段

----这一阶段完成最后的软件产品和最后的验收测试，并完成用户文档编制以及用户培训等工作。

结束语
----可以说，UML对系统模型的表达能力超出了以往任何一种面向对象的分析和设计方法。随之出现的问题是，它的复杂性也超出了以往任何一种方法。由于UML的复杂性，对它的掌握和使用确实不是一件轻松的事。建议对UML掌握和使用本着由简至难的原则，即熟练掌握基本的概念与表示法后，再学习使用UML的更深入部分。UML的三位创始人所著述的《The Unified Modeling language》也是这样组织内容的。关于UML的作者所推荐的过程指导，请阅读他们著述的《The Unified Software Development Process》。此外北京大学也推出了一套青鸟面向对象软件开发规范，其中包括有一套很完整的过程指导。


编写用例文档

--文档中应包括哪些部分，为什么要包括这些部分

Scott W. Ambler
Ronin International 总裁
2000 年 10 月 5 日
本文来自IBM DM站点

Scott Ambler 阐明了基本用例和系统用例之间的区别，并针对如何编写这两类用例的文档提出了一些建议（主要讨论系统用例）。本文由《The Object Primer 2nd Edition》的第三章改编而来。
当记录基于组件的系统的行为需求时，用例是最常用的技术之一。开发人员常问的一个问题是，“用例文档应该包括哪些信息？”尽管我在此提到的一些部分是可选的，但在我看来，将这些部分包括在用例文档中不失为一个好主意。当编写基本用例的文档时（另请参阅前一篇技巧 Modelling essential use cases），我倾向于略去可选部分（因为基本用例关注的是是什么，而不是为什么，因此不必像系统用例那样复杂）。当编写系统用例时，我通常将所有部分都包括在内。回顾一下，基本用例和系统用例之间的主要区别是，系统用例包括了高级实现决策，而基本用例是要以与技术和实现无关的方式捕捉用户的意图。

参与者 (actor) 和被包含的用例这两个部分实际上只看用例图即可确定。但是，按我的经验，各个用例最好相互独立 — 换句话说，用例应该包含理解它们所需的全部关键信息以及它们所在的上下文。这使您的主题问题专家 (SME) 能够分别充实各个用例。（他们可能上午以小组为单位协同工作，下午则各自独立地以最快的速度充实所分配的用例，从而提高了整个小组的生产效率。）

用例的各个组成部分

名称。名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。

标识符 [可选]。唯一标识符，如 "UC1701"，在项目的其他元素（如类模型）中可用它来引用这个用例。说明。概述用例的几句话。

参与者 [可选]。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解。

状态 [可选]。指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。

频率。参与者访问此用例的频率。这是一个自由式问题，如用户每次录访问一次或每月一次。

前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。

后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。

被扩展的用例 [可选]。此用例所扩展的用例（如果存在）。扩展关联是一种广义关系，其中扩展用例接续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有 <<extend>> 的用例关联来建模的。

被包含的用例 [可选]。此用例所包含用例的列表。包含关联是一种广义关系，它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是使用带有 <<include>> 的用例关联来建模的。也称为使用或具有 (has-a) 关系。

假设 [可选]。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设，或者将它们变为决策的一部分（请参阅下文），或者将它们添加到操作的基本流程或可选流程中。

基本操作流程。参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作方式，所以通常称其为适当路径 (happy path) 或主路径 (main path) 。

可选操作流程。用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。

修改历史记录 [可选]。关于用例的修改时间、修改原因和修改人的详细信息。

问题 [可选]。如果存在，则为与此用例的开发相关的问题或操作项目的列表。

决策。关键决策的列表，这些决策通常由您的 SME 作出，并属于用例的内容。将这些决策记录下来对于维护团体记忆库 (group memory) 是相当重要的。

为了让用例建模工作变得轻松一点，我制作了一个模板，它反映了本技巧说明的内容，可通过以下链接下载这个模板：Ronin International Reusable Templates。此模板是以 Microsoft Word（和纯文本）格式提供的，我希望此模板以及该网页上的其他模板对您能有所用处。

编写用例文档
文档中应包括哪些部分，为什么要包括这些部分

Scott W. Ambler
总裁，Ronin International
2000年10月5日
本文来自 http://www.ibm.com/developerworks/cn

Scott Ambler 阐明了基本用例和系统用例之间的区别，并针对如何编写这两类用例的文档提出了一些建议（主要讨论系统用例）。本文由《The Object Primer 2nd Edition》的第三章改编而来。

当记录基于组件的系统的行为需求时，用例是最常用的技术之一。开发人员常问的一个问题是，“用例文档应该包括哪些信息？”尽管我在此提到的一些部分是可选的，但在我看来，将这些部分包括在用例文档中不失为一个好主意。当编写基本用例的文档时（另请参阅前一篇技巧 Modelling essential use cases），我倾向于略去可选部分（因为基本用例关注的是是什么，而不是为什么，因此不必像系统用例那样复杂）。当编写系统用例时，我通常将所有部分都包括在内。回顾一下，基本用例和系统用例之间的主要区别是，系统用例包括了高级实现决策，而基本用例是要以与技术和实现无关的方式捕捉用户的意图。

参与者 (actor) 和被包含的用例这两个部分实际上只看用例图即可确定。但是，按我的经验，各个用例最好相互独立 — 换句话说，用例应该包含理解它们所需的全部关键信息以及它们所在的上下文。这使您的主题问题专家 (SME) 能够分别充实各个用例。（他们可能上午以小组为单位协同工作，下午则各自独立地以最快的速度充实所分配的用例，从而提高了整个小组的生产效率。）

用例的各个组成部分

· 名称。名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。

· 标识符 [可选]。唯一标识符，如 "UC1701"，在项目的其他元素（如类模型）中可用它来引用这个用例。

· 说明。概述用例的几句话。

· 参与者 [可选]。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解。

· 状态 [可选]。指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。

· 频率。参与者访问此用例的频率。这是一个自由式问题，如用户每次录访问一次或每月一次。

· 前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。

· 后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。

· 被扩展的用例 [可选]。此用例所扩展的用例（如果存在）。扩展关联是一种广义关系，其中扩展用例接续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有 <<extend>> 的用例关联来建模的。

· 被包含的用例 [可选]。此用例所包含用例的列表。包含关联是一种广义关系，它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是使用带有 <<include>> 的用例关联来建模的。也称为使用或具有 (has-a) 关系。

· 假设 [可选]。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设，或者将它们变为决策的一部分（请参阅下文），或者将它们添加到操作的基本流程或可选流程中。

· 基本操作流程。参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作方式，所以通常称其为适当路径 (happy path) 或主路径 (main path) 。

· 可选操作流程。用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。

· 修改历史记录 [可选]。关于用例的修改时间、修改原因和修改人的详细信息。

· 问题 [可选]。如果存在，则为与此用例的开发相关的问题或操作项目的列表。

· 决策。关键决策的列表，这些决策通常由您的 SME 作出，并属于用例的内容。将这些决策记录下来对于维护团体记忆库 (group memory) 是相当重要的。

为了让用例建模工作变得轻松一点，我制作了一个模板，它反映了本技巧说明的内容，可通过以下链接下载这个模板：Ronin International Reusable Templates。此模板是以 Microsoft Word（和纯文本）格式提供的，我希望此模板以及该网页上的其他模板对您能有所用处。

参考资源
有关用例的详细信息，请参阅：

· 以前的技巧："Modeling essential use cases"

· 《Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology》，Scott W. Ambler 著。纽约：Cambridge University 出版社，1998 年。

· 《Process Patterns -- Building Large-Scale Systems Using Object Technology》，Scott Ambler 著。纽约：Cambridge University 出版社，1998 年。

· 《The Object Primer 2nd Edition》，Scott W. Ambler 著。纽约：Cambridge University 出版社，2000 年。

· 《Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design》，Larry L. Constantine 和 Lucy A.D. Lockwood 著

· 《Use Case Driven Object Modeling with UML: A Practical Approach》，Doug Rosenberg 和 Kendall Scott 著

· 《The Unified Modeling Language Reference Manual》，James Rumbaugh、Grady Booch 和 Ivar Jacobson 著。Reading，MA：Addison-Wesley Longman 公司，1999 年。

· 《Applying Use Cases: A Practical Guide》，G. Schneider 和 J.P. Winters 著


绘制整洁的UML图 明晰才能被人采纳

Scott W. Ambler
总裁，Ronin International
2000 年 11 月 27 日
本文来自 http://www.ibm.com/developerworks/cn

不管您喜欢与否，诸如“统一建模语言 (UML)”类模型和用例模型这样的软件图往往是根据它们的外观来判定其好坏的。看上去“整洁”的图比看上去杂乱的图更容易受到读者 -- 常常是您的用户或高级经理 -- 的青睐。本文源自 Building Object Applications That Work 的第 3 章。

我很愿意描述几个重要的经验法则，这些法则将使您比其他建模同仁做得更好。这些虽然简单但很关键的建议主要集中在如何安排组成软件图（包括 UML 类模型、用例模型，甚至持久模型）的那些框和线条，并因此适用于所有种类的图。

要绘制一个外观整洁的图，您应该避免：

· 大小不一的框

· 对角线

· 交叉线

· 曲线

· 混乱的图

· 不必要的细节

让我们从一个示例开始。在图 1 和 2 中，您可以看到两个用两种不同风格绘制的图。第一个复杂，没有章法，而第二个简单，组织良好（虽然有些乏味）。您认为哪个设计更好呢？大多数人都会赞成第二个看上去更好一些，因为虽然这两种设计在功能上是相等的，但第二个的安排更整洁。

图 1. “杂乱”的图
杂乱的图

图 2. “整洁”的图

整洁的图

避免大小不一的框
如何对图 1 加以改进呢？首先，确保所有框的大小都一样。大框看上去比小框更重要一些，如果这是您尝试表达的，那么这样做没错 -- 但如果让我选的话，我宁愿将所有框保持相同的大小。这种方法最适合于“UML 用例”图，因为其中的所有用例框和参与者符号可以很方便地统一成一样，此外还适用于“UML 协作图”、“UML 序列图”和“UML 用户界面流程图”。对于框中包含的信息量不同的图，例如“UML 类图”（其中个别类有数量不等的属性和操作），或者“UML 状态图表图”和“持久”（数据）模型，那就有一些困难了。

避免对角线
图 2 与图 1 的另一个不同之处在于它没有任何对角线。我是通过重新安排框来消除对角线的，就好象它们在一个网格上，使互连的框或者在垂直方向上分离，或者在水平方向上分离。从视觉上说，大多数人对直线更感兴趣。

避免交叉线
在图 1 中，有两条线相互交叉，我的一个常规经验法则是应该尽量减少图中交叉线的数量。通过将一些框移到旁边，我在短时间内就可以避免使两条线交叉。可惜，不是总能这样幸运 -- 您无法总能避免交叉线。在图 3 中，我想将 5 个框全部连接起来，但如果不使至少两条线相交就无法做到这一点。您可以看到，我没有其它方法将框 3 和 5 连接起来。在不得不交叉线时，我会用适用于电路图的标准来标记：一条线“跳过”另一条，如图 4 所示。跳过的好处是它很清楚地表明线只是在图上交叉，而不以任何方式连接。

图 3. 如何在不交叉线的情况下连接 3 和 5？

如果在不交叉线的情况下连接 3 和 5？

图 4. 一条线“跳”过另一条
一条线跳过另一条

避免曲线
您可以在图 5 中看出，我对图 4 做了更进一步的改进：除去了曲线。人们喜欢看到垂直或水平的直线。这次我又假装是在网格上绘制图（实际上这是许多计算机辅助系统工程 (CASE) 工具的内置特性），然后只需要象在网格上那样绘制出框和线条。

图 5. 图 4 的更整洁版本

避免混乱或复杂的图
显示太多细节或者外观很混乱的图

看上去不太好。最好能够有几张显示各种程度的细节的图，而非一张显示所有事物的复杂的图。这就是为什么 UML 拥有几种图的原因之一：一个软件是如此复杂，以至于我们无法在单一图上对其所有方面建模。而且，UML 允许将包添加到图中（下星期的技巧主题）。

另一个相关的注意事项是对屏幕或页面区域的使用。在我看来，一张占据几页的图比将所有内容蜷缩在一起，使它能在一页上打印出的图要好得多。您应该给图留出足够的空间，使它易于理解。

避免在图的美化上浪费太多时间
尽管这些经验法则非常有效，但无休止地调整图的外观总是会增加额外的建模时间。解决这个问题的一个方法是尝试使图的外观保持在大致良好的水平上 -- 您在使用图时，不需要它非常完美。一旦确信图按照您所需的方式对应用程序建模，就可以开始移动框以避免交叉线，增进其可理解性。

您的主要目标是对系统建模，而不是绘制漂亮的图。有必要指出这些重要的经验法则也可以被用来美化低劣的设计。例如，我可以从图 2 开始，将它重排成图 1，以使设计看上去比实际的更为复杂 -- 可能使得高级管理人员相信我需要更多时间或资源才能完成工作，或者引导他们避开我不是特别喜欢的备选设计。假设您的动机随情形而改变，我希望您所处的情形是健康的，您所考虑的最重要的问题是使了不起的设计看上去更引人入胜，而不是在办公室权术中求生存。

参考资料

· Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology，由 Scott W. Ambler 著。New York: Cambridge University Press, 1998。

· Process Patterns -- Building Large-Scale Systems Using Object Technology ，由 Scott Ambler 著。New York: Cambridge University Press, 1998。

· The Object Primer 2nd Edition，由 Scott W. Ambler 著。New York: Cambridge University Press, 2000。


建模的误区——
走出一般性的设计误区，迈向成功之途

作者：Scott Ambler
翻译：luckygao

文章来源：http://www.sdmagazine.com/documents/s=844/sdm0108k/0108k.htm

译注：本文翻译未征得作者同意，仅作练习。

==============================================================================

无论你遵从的是重量级的方法,比如Enterprise Unified Process(EUP)，还是轻量级的开发过程，如Extreme Programming(XP)，建模在软件开发中都是不可或缺的。但不幸的是其中充斥着各种谬误与迷思。
这来自于各个方面，有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的市场宣传以及象Object Management Group (OMG)和IEEE这类组织的标准。这个月，我要揭示建模中 的误区，指出其相应的事实真相。

误区一：建模就等于是写文档

这很可能是其中最具破坏力的一条，因为开发人员可以此为借口而完全放弃建模。许多优秀的软件开发人员 会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中，制造着一些脆弱而劣质的系统。
另外，甚至于许多尽责的开发人员现在也认为建模是一件讨厌的事，而不愿去学习相应的建模技术。

事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的—你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型，而不论是被画在餐巾纸的背面，或写在一块白板上，或在Class Responsibility Collaboration(CRC)卡片中，还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档，但他们却都是有价值的模型。

建模很象是作计划：作计划的价值在于计划编制的过程中，而非计划本身；价值体现在建模的活动中，而非 模型本身。实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常完美。

误区二：从开始阶段你可以考虑到所有的一切

这种说法流行于二十世纪七十年代到八十年代早期，现今的许多经理都是在那个时候学习的软件开发。对这 一点的迷信会导致在前期投入可观的时间去对所有的一切建模以期把所有一切都弄正确，试图在编码开始前就“冻结”所有的需求（见误区四），以致于患上“分析期麻痹症” – 要等到模型非常完美之后才敢向前进。基于这个观点，项目组开发了大量的文档，而不是他们真正想要得到的—开发满足需要的软件。

事实分析：怎么才能走出这个误区呢？首先，你必须认识到你不能考虑到所有的细枝末节。第二，认识到编码员可能会对建模者的工作不以为然（这是可能的，事实上建模者所作的工作在实际价值中只占很少的部分），他们或许会说模型没有反应出真实的情况。第三，认识到不管你的最初所作的规格说明书有多好，但 注定代码会很快地与之失去同步，即便是你自己建模自己编码。一个基本的道理就是代码永远只会和代码保 持一致。第四，认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过程（如EUP），以及轻量级（如XP)的基本原理。

误区三：建模意味着需要一个重量级的软件开发过程

走入这个误区（经常与误区一有联系）的项目组常常是连建模都彻底地放弃了，应为这样的软件开发过程对 他们来说太复杂太沉重了。这不亚于一场天灾。

事实分析：你可以用一种轻灵的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM)。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行建模（比如，从办 公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地建模。

误区四：必须“冻结”需求

这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发 周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上 所需要的（不全或错误的需求，译者）。

事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。 与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。

误区五：设计是不可更改的

如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实 际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。

事实分析：事实上，设计会经常根据开发人员和数据库管理员的反馈进行修改，因为他们是最接近实际应用 的人，通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实：人无完人，他们所作的工 作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如 果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确 的态度是：只要你的代码还在改动，涉及就没完。

误区六：必须使用CASE工具

建模常常被认为是一项复杂的工作，因此需要大量地使用CASE工具辅助进行。

事实分析：是的，建模可以是很复杂的。但你完全可以建立一个有效而简单的模型表述其中关键的信息，而 不是将一些无关紧要的细节包括进来。

比如，我经常使用UML建立模型来表示类、它们的属性及一些关键的业务操作，但并不画出属性的存取操作 (get和set)，以及维护与其它类关系的框架代码，或者其他一些琐碎的实现细节。我通过建模寻找解决问题的方法，让我和我的同事能继续前进去实现这个模型。以这样灵活的方式，大多数情况下我并不需要一个 CASE工具来支持建模工作，一块白板，或者一台数字相机足以。这样，我就不用花时间去评估CASE工具，不 用去和工具供应商讨论许可证的问题，也免去了人员培训开销。CASE工具只有当它能体现最佳性价比时（相 对你自己的情况而言），才值得购买。大多数情况下，我都能不用它而达到目的（完成建模）。我经常使用 的工具有Together/J(http://www.togethersoft.com/) – 因为它能产生数目可观的Java框架代码；还有ERWin（http://www.cai.com/） -- 因为它能规划数据库。这两个工具真正地帮助我实现了软件开发的目的 – 制造满足用户要求的软件。但我绝大多数得建模工作仍然使用的是简单的工具，而不是CASE工具。

误区七：建模是在浪费时间

许多新手都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。

事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的 理解，涉及到该项目中的每个成员也可得到对该项目有一个从分的了解。

误区八：数据模型(Data Model)就是一切

许多组织基于数据模型就蹒跚启动新的开发工作，也许正如你所在的组织：IT部门对于数据有非常严格的规 定，控制着你的开发项目；或者你以前的数据库是一团糟，别无选择。

事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。（参见 “Extreme Modeling”，Thinking Objectively，Nov.2000）。这即使在象数据仓库这类面向数据的项目中 也如此。如果没有很好的理解用户是如何使用该数据仓库的（在数据模型中没有表示出来），这些项目经常 是以可悲的失败而告终。你可以使用的模型有很多 – 使用案例（use cases），业务规则（business rules），activity diagrams，类图（class diagrams），component diagrams，用户界面流程图（user interface flow diagrams）和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该
正确地使用。

误区九：所有的开发人员都知道如何建模

我们现在面临照这样一个严重的问题：许多不是开发人员的人，包括高级经理和用户，不知道软件是如何建 成的。其结果，他们不能够区分开熟练的开发者和一般的程序员（当然也分不清高级程序员和一般程序 员），他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。

事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，毕竟他们终究只是程序员。正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发这应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短，建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。我个人认为所有的人，包括我自己，都是新手。

Agile Modeling

通过理解和避开建模的误区，你能够是得你自己、你的项目组和你的组织更加有效地进行软件开发。在揭示 这些普遍存在误区的过程中，我已经表述了Agile Modeling(AM)的许多原则。Agile Modeling 以前叫做 Extreme Modeling(XM)。我希望我所给于你的是精神上的食粮。

在此我要感谢Blueprint Technologies（http://www.blueprinttech.com）的Doug Smith，Evanetics （http://www.evanetics.com）的Gary Evans，以及在Agile Modeling邮件列表（可访问 http://www.agilemodeling.com加入）中对本文做出贡献的人们。我同样要感谢Martin Fowler，Ron Jeffries和其他一些XP社区中成员，因为我想我已经融入了一些他们的观点。

建模十条原则

仅有数据模型对于现代软件是不够的。
接收变化，并且允许你的模型能够随着时间进行改进。 你不能冻结它们，然后就期待着成功。
模型并不一定就是文档，文档也不一定就是模型。
大多数的模型可能也应该被丢弃。
只有代码才能与代码保持真正的同步。
一些简单的工具，比如白板，就完全足以应付大多数建模工作。
思考，然后再编码。
你总能从别人身上学到东西。
建模可以用一种轻盈的方式。
设计直到代码发布以后才算完成。


如何绘制 UML 活动图(Activity Diagram)
记录您所作的一切

Scott W. Ambler
总裁，Ronin International
2000年9月7日
本文来自 http://www.ibm.com/developerworks/cn

UML 活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。要创建一个 UML 活动图，您需要反复执行下列步骤，修改自《对象入门》(The Object Primer)第二版的第六章。

第一步，定义活动图的范围
首先应该定义您要对什么建模。单个用户案例力？一个用户案例的一部分？一个包含多个用户案例的商务流程？一个类的单个方法？一旦您定义了您所作图的范围，您应该在其顶部，用一个标注添加标签，指明该图的标题和唯一的标示符。您有可能也想要包括该图的时间甚至作者名。

第二步，添加起始和结束点
每个活动图有一个起始点和结束点，因此您也要马上添加它们。在 《UML 精粹》(UML Distilled) (参见参考资料)，Fowler 和 Scott 认为结束点是可选的。有时候一个活动只是一个简单的结束，如果是这种情况，指明其唯一的转变是到一个结束点也是无害的。这样，当其他人阅读您的图时，他或她知道您已经考虑了如何退出这些活动。

第三步，添加活动
如果您正对一个用户案例建模，对每个角色(actor)所发出的主要步骤引入一个活动(该活动可能包括起始步骤，加上对起始步骤系统响应的任何步骤)。如果您正对一个高层的商务流程建模，对每个主要流程引入一个活动，通常为一个用户案例或用户案例包。最后，如果您正对一个方法建模，那么对此引入一个活动是很常见的。

第四步，添加活动间的转变
我的风格总是应该退出一个活动，即使它是转变到一个结束点。一旦一个活动有多个转变时，您必需对每个转变加以相应标示。

第五步，添加决策点
有时候，您所建模的逻辑需要做出一个决策。有可能是需要检查某些事务或比较某些事务。要注意的是，使用决策点是可选的。例如，在图 1 中，我可以只是简单地将“接受”和“拒绝”两个转变直接接到“在大学报名(Enroll in University)”活动。"

第六步，找出可并行活动之处
当两个活动间没有直接的联系，而且它们都必需在第三个活动开始前结束，那它们是可以并行运行的。在图 1 中，您看到是有可能“参加简要介绍(attend overview)”和“报名研讨班(enroll in seminars)”可以按任意次序进行，但是它们都得在您结束整个流程前完成。

图 1. 一个在学校首次报名的 UML 活动图

参考资料
关于 UML 活动图的更多信息，参见：

· Scott W. Ambler 编写的 Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology。纽约：剑桥大学出版社(Cambridge University Press) 1998年出版。

· Scott W. Ambler 编写的 《对象入门》(The Object Primer)第二版。纽约: 剑桥大学出版社(Cambridge University Press) 2000年出版。

· Martin Fowler, Ivar Jacobson 和 Kendall Scott 合著的 UML 精粹(UML Distilled): Applying the Standard Object Modeling Language 。Reading, MA: Addison-Wesley Longman, Inc, 1997年出版。

· James Rumbaugh, Grady Booch 和 Ivar Jacobson 合著的 The Unified Modeling Language Reference Manual。Reading, MA: Addison-Wesley Longman, Inc., 1999年出版。


使用 UML 为 Web 应用程序构架建模

作者：Jim Conallen，Rational Software
1999 年 6 月
这份材料发表在 1999 年 10 月（第 42 卷，第 10 期）的 Communications of the ACM 上。

摘要

Web 应用程序正变得越来越复杂，越来越重要。为了帮助管理这种复杂性，需要为 Web 应用程序建模。UML 是软件密集型系统的标准建模语言。在尝试用 UML 为 Web 应用程序建模时，很明显它的一些构件不能与标准的 UML 建模元素一一对应。为了让整个系统（Web 构件，以及传统的中间层构件）使用同一种建模表示法，必须扩展 UML。本文介绍 UML 的一种扩展方式（使用正式的扩展机制）。进行扩展是为了让 Web 特有的构件能与系统模型的其余部分集成，向 Web 应用程序的设计员、实施员以及构架设计师展示适当的抽象和明细级别。

近年来，IT 词汇表中出现了一条新的术语，它就是“Web 应用程序”。参与业务软件系统的所有人似乎都有构建 Web 应用程序的计划，而在与业务不相关的软件方面也有很多人对此感兴趣。对于很早前就采用这种构架的许多人来说，Web 应用程序这个词象系统本身一样，已经从成功的小型 Web 站点插件发展成了强壮的 n 层应用程序。Web 应用程序可以同时为分布在世界各地的、成千上万的用户提供服务，这种情况早已司空见惯。构建 Web 应用程序是一件严肃的事情。

在实际应用中，Web 应用程序这个词对不同的人而言含义略有不同。一些人认为凡是用到 Java 的都是 Web 应用程序，而另一些人则认为凡是使用 Web 服务器的都是 Web 应用程序。多数人的意见介于这两者之间。站在本文的角度，我们将 Web 应用程序大体定义为 Web 系统（Web 服务器、网络、HTTP、浏览器），在这个系统中，用户的输入（导航和数据输入）会影响到业务状态。该定义试图将 Web 应用程序确立为一个具有业务状态的软件系统，并且它的“前端”基本上是通过 Web 系统传递的。

Web 应用程序的总体构架是一个客户机服务器系统，但二者有几点显著的区别。Web 应用程序最重要的优点之一在于它的部署。部署 Web 应用程序通常指的是建立网络的服务器端构件。客户端不需要特别的软件或配置。两者的另一个重大差异在于客户机和服务器通信的本质。Web 应用程序的基本通信协议是 HTTP，这是一个无连接协议，它不是为最大的通信吞吐量设计的，而是为强壮性和容错而设计的。在 Web 应用程序中，客户机和服务器的通信通常围绕 Web 页导航进行，而不是在服务器端和客户端对象之间直接通信。在一定的抽象程度上，Web 应用程序中所有的信息传递都可描述为 Web 页实体的请求和接收。通常所说的 Web 应用程序构架与动态 Web 站点的构架并无太大区别。

Web 应用程序与 Web 站点，甚至是与动态 Web 站点的区别都要涉及到使用。Web 应用程序实现的是业务逻辑，它的使用改变了业务的状态（其状态为系统捕获）。这是很重要的，因为它确定了建模工作的重点。Web 应用程序执行业务逻辑，因此大多数重要的系统模型都侧重于业务逻辑和业务状态，而不是表示细节。表示很重要（否则系统将毫无用处），不过应尽量将业务和表示所关注的问题区分开。如果表示问题是重要的，甚至是复杂的，那么也需要对它们建模，但不必将它们作为业务逻辑模型的构成部分。此外，用于表示的资源更注重外观设计，而与实施业务规则关系不大。

关系管理方法 (RMM) 是与 Web 系统开发有关的一种方法/表示法。RMM 是一种用于设计、构建和维护 Intranet 及 Internet Web 系统的方法。它的根本目标是降低动态数据库驱动的 Web 站点的维护成本。它提倡系统进行形象化表示，以便展开设计上的讨论。它是一个迭代式过程，包括 Web 页可视元素的分解，及这些元素与数据库实体的关联关系。RMM 是一种用于动态 Web 站点创建和维护的“完整详尽”的方案。

不过，在构建 Web 应用程序方面 RMM 就显得无能为力了。Web 应用程序以业务逻辑为中心，它包括了许多实施业务逻辑的技术机制，而这些内容在 RMM 表示法中并未充分说明。客户端脚本编写、Applet 和 ActiveX 控件等技术为促进系统业务规则的执行发挥了重大作用。另外，Web 应用程序还可用作分布式对象系统的交付机制。Applet 和 ActiveX 控件可以包含那些独立于 Web 服务器，通过 RMI 或者 DCOM 与服务器端构件异步交互的构件。复杂应用程序还可利用多个浏览器实例和客户机上的框架，建立并维护自己的通信机制。

既然所有这些机制都对系统的业务逻辑有促进作用，因此同样也需要为它们建模。而且，由于它们只表示部分业务逻辑，它们需要与其余的系统模型集成。在很多情况下，大部分业务逻辑在 Web 服务器后、服务器端的某一层执行。建模语言和表示法的选择通常要按照这一端的应用程序的需要来决定。随着 UML 作为一种正式的对象建模语言被 OMG 所接受，越来越多的系统开始用 UML 表示。许多人选择 UML 作为软件密集型系统的建模语言。于是 Web 应用程序建模的主要问题变成了：“如何在应用程序的其余部分表示在特定 Web 构件中执行的业务逻辑？”答案取决于我们用 UML 在那些特定的 Web 元素和技术中表示系统业务逻辑执行的能力。

本文旨在简要介绍 Web 应用程序建模存在的问题和可能的解决方案。其中着重讲述在构架上对 Web 应用程序有重要意义的构件，以及如何使用 UML 对它们进行建模。本文假定读者熟悉 UML、面向对象技术的原理和 Web 应用程序开发。文中描述的工作基于一些无偏向性的假设。

· Web 应用程序是日益复杂的软件密集型系统，它们在关键的任务中发挥着越来越重大的作用。

· 管理软件系统复杂性的一种方法是对它们进行抽象和建模。

· 软件系统一般有多个模型，每一个模型代表一个不同的观点、不同的抽象和详细级别。

· 哪个抽象和详细级别是合适的，这取决于开发流程中的工件和角色活动。

· 软件密集型系统的标准建模语言是统一建模语言 (UML)。

本文介绍的概念和思想在今年年底即将由 Addison Wesley Longman 出版的“Object Technology Series”中的“Building Web Applications with UML”一书中有更为充分的论述。

建模

通过简化一些细节，模型可以帮助我们理解系统。如何选择建模对象对理解问题和提供解决方案有重大影响。Web 应用程序与其他软件密集型系统一样，通常由用例模型、实施模型、部署模型、安全模型等一组模型来表示。Web 系统还另有一个专用模型，即站点图。站点图是对贯穿整个系统的 Web 页和导航路线的抽象。

目前采用的大部分建模方法都适用于各种 Web 应用程序模型的开发，因而无需对它们进行进一步的讨论。不过，有一个非常重要的模型，分析/设计模型 (ADM)，在尝试将 Web 页、与其相关的可执行代码和其他元素纳入模型时，确实出现了一些困难。

在决定如何建模时，确定正确的抽象和详细级别对于是否能让模型用户享受到建模带来的好处至关重要。一般而言，最好对系统的工件建模。工件就是那些为生成最终产品而构建和操纵的真实生活中的实体。对 Web 服务器的内部构件建模，或者对 Web 浏览器的具体构成部分建模，这对于 Web 应用程序的设计员和构架设计师并没有什么帮助。页、页之间的链接、构成页的所有动态内容，以及在客户机上出现过的页的动态内容，对这些建模才是重要的，而且是非常重要的。设计员设计的、实施员实施的正是这些工件。页、超链接、客户机和服务器上的动态内容正是需要建模的对象。

下一步是将这些工件映射到建模元素。例如，超链接自然映射到模型中的关联关系元素。超链接代表了从某一页到另一页的导航路径。将这种思路进行扩展，页就可以映射到模型逻辑视图中的类。如果 Web 页是模型的一个类，那么页的脚本自然就映射为这个类的操作。脚本中的所有页范围 (内的) 变量映射为类属性。Web 页可能包括一套在服务器上执行的脚本（准备页的动态内容），以及另一套完全不同的只在客户机上执行的脚本（如 JavaScript），考虑到这一点时，一个问题就出现了。在这种情况下，当我们查看模型中的 Web 页类时，我们搞不清楚在准备页的过程中哪些操作、属性甚至关系在服务器上处于活动状态，而当用户与页交互时哪些在客户机上处于活动状态。另外，Web 应用程序中传递的 Web 页最好是作为系统构件建模。简单地将 Web 页映射到 UML 类不会对我们理解系统有所帮助。

UML 的创始人意识到总会存在这样的情况：初始的 UML 不足以获取一个特定领域或构架的相关语义。为了解决这个问题，他们确定了一种正式扩展机制，允许实践者扩展 UML 的语义。该机制允许定义可应用到模型元素的构造型、标注值和约束。

构造型是一种修饰，允许我们为建模元素定义新的语义。标注值是可以与建模元素相关联的键值对，允许我们在建模元素上“标注”任何值。约束是定义模型外形的规则。它们可表示为任何形式的文本，或者用更正式的对象约束语言 (OCL) 表示。

本文讨论的工作引入了为 Web 应用程序所作的一种 UML 扩展。这种扩展从整体上看超出了本文的范围，然而这里还是讨论了其中大部分的概念和解释。

关于建模最后还要注意一点，一定要明确区分业务逻辑和表示逻辑。对于典型的业务应用程序而言，只有业务逻辑才应成为 ADM 的一部分。表示细节，如动画按钮、浮动帮助和其他 UI 增强方式通常不属于 ADM。如果为应用程序单独构建一个 UI 模型，则可在其中纳入表示细节。ADM 需要始终将重点放在业务问题和解决方案的表达上。在今天这个 Web 设计师的时代，对 Web 页外观的设计和实现最好由专业人员（技术绘图师）取代传统的开发人员来完成。

Web 应用程序构架

Web 应用程序的基本构架包括浏览器、一个网络和一个 Web 服务器。浏览器向服务器请求“Web 页”。每一页都是内容和以 HTML 表达的格式指令的组合。一些页包括客户端脚本，它们由浏览器解释。这些脚本为显示的页定义了其他动态行为，而且它们经常与浏览器、页内容和页中包含的其他控件（Applet、ActiveX 控件和插件）交互。用户查看页中的内容，并与其交互。有时，用户在页的字段元素中输入信息，并提交给服务器处理。用户还可以通过超链接导航到系统的其他页，与系统进行交互。无论是哪种情况，用户都在向系统提供输入，这样就可能改变系统的“业务状态”。

从客户端来看，Web 页总是一个采用 HTML 格式的文档。然而在服务器端，“Web 页”可表现为多种形式。在最早的 Web 应用程序中，动态 Web 页用公共网关接口 (CGI) 构建。CGI 定义了一个供脚本和已编译模块使用的接口，它们通过该接口访问与页请求一起传递的信息。在基于 CGI 的系统中，通常在 Web 服务器上配置一个特殊的目录，以便针对页请求来执行脚本。在请求 CGI 脚本时，服务器会用解译器（通常是一个 PERL shell）处理或执行相应的文件，以流的形式将输出返回给发出请求的客户机，而不仅仅是返回文件内容（就像处理 HTML 格式的文件时一样）。处理的最终结果是 HTML 格式的流，它会被返回给发出请求的客户机。业务逻辑在处理文件的同时在系统中执行。在这段时间内，它能够与服务器端资源（如数据库和中间层构件）交互。

目前的 Web 服务器已经在这个基本设计上有所改进。它们现在已非常注重安全性，而且包含了一些特性：如在服务器端的客户机状态管理、事务处理集成、远程管理、资源共享等，这里只列举了其中的几种。总的来说，最新一代 Web 服务器处理的都是那些对构架设计师来说非常重要的问题，它们关系到任务至上、可缩放和强壮的应用程序。

根据 CGI 脚本的作用，可以将现今的 Web 服务器分为三大类：脚本页、编译页，以及两者的混合体。在第一类中，客户机浏览器能请求的每一个 Web 页在 Web 服务器的文件系统中都用一个脚本文件来表示。这个文件一般是 HTML 和其他一些脚本语言的混合。对页发出请求后，Web 服务器委派一个可识别该页的引擎对其进行处理，最终结果以格式为 HTML 的流的形式返回给发出请求的客户机。Microsoft 的 Active Server Pages、Java Server Pages 和 Cold Fusion 都属于这一类。

在第二类中，Web 服务器加载并执行一个二进制构件。这个构件和脚本页一样，有权访问与页请求一起发送的所有信息（表单字段值和参数）。经过编译的代码利用请求的详细信息，并通常要访问服务器端的资源，以生成 HTML 流并返回给客户机。编译页包含的功能往往比脚本页大，尽管并未明确这一规律。通过向编译页请求传递不同的参数，可获得不同的功能。任何一个编译构件实际都可以包含整个目录脚本页的所有功能。Microsoft 的 ISAPI 和 Netscape 的 NSAPI 就是表示这种构架类型的技术。

第三类指的是那些一旦发出请求即进行编译的脚本页，以后的所有请求都使用编译过的页。只有最初页的内容改变了，该页才会进行另一次编译。这类页介于灵活的脚本页和高效的编译页之间。

Web 页建模

Web 页，不管是脚本页还是编译页，都一对一地映射到 UML 中的构件。构件是系统的“物理”可更换部件。模型的实施视图（构件视图）描述了系统的构件及它们之间的关系。在 Web 应用程序中，这个视图描述了系统的所有 Web 页及它们彼此之间的关系（如超链接）。在一定程度上，Web 系统的构件图就相当于站点图。

由于构件仅仅代表了接口的物理打包方式，它们并不适用于对页内部的协作关系建模。这一抽象级别仍需要成为模型的组成部分，而且对设计员和实施员而言极其重要。为引入正题，我们可以说每个 Web 页在模型的设计视图（逻辑视图）中都是一个 UML 类，它与其他页的关系（关联关系）即代表了超链接。但如果考虑到任何 Web 页都可能既代表一组只存在于服务器上的功能和协作，同时又代表只存在于客户机上的一组完全不同的功能和协作，那么这种抽象就不成立了。举例来说，使用动态 HTML（客户端脚本）作为部分输出的所有服务器 Web 脚本页都是这样的页。对这个问题的直接反应可能就是为类中的每个属性或操作设计原型，指明它是在服务器端还是在客户端有效。至此，运用模型倒让问题变得复杂了，而我们的初衷是要简化问题。

一个更好的解决方案是“分别考虑”。从逻辑上讲，服务器端的 Web 页行为与客户端是完全不同的。在服务器上执行时，页有权访问服务器端资源（中间层构件、数据库、文件系统等），即与这些资源具有某些关系。同一页（或者是该页的 HTML 流输出）在客户端有完全不同的行为和关系集。在客户端，脚本页与浏览器本身（通过文档对象模型，即 DOM），以及该页指定的所有 Java Applet、ActiveX 控件或插件相关。对于认真的设计员而言，页还可能与客户机上在另一个 HTML 框架或浏览器实例出现的其他“活动”页相关。

通过分别考虑，我们就可以用一个类为 Web 页的服务器端建模，用另一个类为客户端建模。我们采用 UML 扩展机制为两者分别定义构造型和图标：«server page» 和 «client page»，以此来区分两者。UML 中的构造型允许我们为建模元素定义新的语义。已指定构造型的类在 UML 图中可用定制图标表示，或者仅仅用 («») 之间的构造型名称说明。图标对概述图很有用，在概述图中，最好使用简单的标记对显示出的类属性和操作进行标注。

对于 Web 页，构造型指出了类是客户机或服务器上 Web 页逻辑行为的抽象。两种抽象通过两者之间的定向关系相互关联关系。这种关联关系的构造型为：«build»，因为可以说服务器页构建了客户机页（图 1）。每个动态 Web 页（即页内容在运行时才能决定的页）都用一个服务器页构建。每个客户机页至多只能用一个服务器页构建，而一个服务器页可以构建多个客户机页。

Web 页之间通过超链接建立公共关系。Web 应用程序中的超链接代表系统的一条导航路径。这种关系在模型中用一个构造型为 «link» 的关联关系表示。关联关系总是从客户机页出发，指向另一个客户机页或服务器页。

超链接作为 Web 页请求在系统中实施，Web 页作为实施视图中的构件来建模。指向客户机页的链接关联关系大体等同于指向构建该客户机页的服务器页的链接关联关系。这是因为链接实际是一个页请求，不是上述两种类抽象。由于 Web 页构件同时实现两种页抽象，因此指向由该页构件实现的任何类的链接都是等同的。

标注值用于定义随链接请求一起传递的参数。«link» 关联关系标注值“Parameters”是一个参数名（和可选值）的列表，处理请求的服务器页要用到它。在图 2 中，SearchResults 页包含数目可变的指向 GetProduct 服务器页的超链接 (0..*),每一个链接都有一个不同的 productId 参数值。GetProduct 页用于构建 productId 参数所指定产品的 ProductDetail 页。

图 1. 服务器页构建客户机页。

图 2. 使用超链接参数。

使用这些构造型简化了对页脚本和关系的建模。«server page» 类的操作变为页服务器端脚本的函数，它的属性变为页范围变量（页函数可对其进行全局访问）。«client page» 类的操作和属性也同样变为在客户机上可见的函数和变量。将服务器端页和客户端页作为不同的类考虑，其最大好处在于明确页与系统的其他类之间的关系。客户机页根据它们与客户端资源的关系进行建模。客户端资源有：DOM、Java Applet、 ActiveX 控件和插件（图 3）。服务器页根据它们与服务器端资源的关系进行建模。服务器端资源有：中间层构件、数据库存取构件、服务器操作系统等(图 4)。

图 3. 客户机协作

图 4. 服务器协作

用类构造型对 Web 页的逻辑行为建模的最大优势在于：页与服务器端构件的协作可以基本上用其他任意服务器端协作所使用的方式来表示。«server page» 仅仅是参与系统业务逻辑的另一个类。上升到概念的层次来讲，服务器页一般扮演控制者的角色，协调必要的业务对象活动，以满足浏览器页请求所提出的业务目标。

客户端的协作更复杂一些。部分原因可归咎于可用技术的多样性。即使是最简单的客户机页，至少也是一个既包含内容又包含表示信息的 HTML 文档。浏览器利用页的格式指令提供 HTML 页，有时还带有单独的样式表。在逻辑模型中，这一关系可用客户机页对构造型为 «Style Sheet» 的类的依赖关系来表示。样式表基本上是一个表示问题，通常不包含在 ADM 内。

表单

Web 页的基本数据输入机制是表单。表单在 HTML 文档中用 <form> 标记来定义。每个表单都会指明它自身要提交到哪一页。表单包括许多输入元素，它们全用 HTML 标记表示。最常用的标记是 <input>、<select> 和 <textarea>。输入标记多种多样，它可以是一个文本字段、复选框、单选按钮、按钮、图像、隐藏字段，还有其他一些不太常见的类型。对表单建模要使用另一个类构造型：«Form»。«Form» 没有操作，这是因为可能在 <form> 标记中定义的所有操作实际上都为客户机页所有。表单的输入元素都是 «Form» 类的建有构造型的属性。«Form» 可以与作为输入控件的 Applet 或者 ActiveX 控件有关系。表单还与服务器页有关系，服务器页即是处理表单提交内容的页。这种关系的构造型为 «submit»。由于表单完全包含在 HTML 文档内，所以它们在 UML 图中用一种强聚合关系形式表示。图 5 是一个简单的购物车页，它定义了一个表单，显示了与要处理表单的服务器页的提交关系。

图 5. 表单提交给服务器页。

在图 5 中，以 «JavaScript» 为构造型的类是一个代表购物车中的商品项的对象。对于可有多种输入可能的字段，它们的表单属性说明中使用了数组语法。在这个例子中，这意味着购物车可以有零到多个项，每个项都有一个 Qty、AllowSubs、Cost 和 Total <input> 元素。

由于客户机页内的所有活动都用 JavaScript 执行，而 JavaScript 是一种无类型的语言，所以为这些属性指定的数据类型只是为了便于实施员辨认。在 JavaScript 中执行或作为 HTML 输入标记执行时，该类型将被忽略。这对函数参数也成立，函数参数是模型的一部分，尽管本图并未明确显示。

框架

HTML 框架从刚被引入 Web 站点和 Web 应用程序时就引发了极大的争论，且意见呈两极分化。框架允许在某一时刻有多个页激活，并对用户可见。目前最常用的浏览器还具备一组最新的特性，允许用户机器上同时打开多个浏览器实例。使用动态 HTML 脚本，这些页中的构件可以彼此交互。客户端复杂交互的潜力非常大，使得对此建模的需要变得更大。

是否在应用程序中采用框架或多个浏览器实例，这要由构架设计师决定。如果决定采用，客户端行为的模型就需要在 ADM 中表示出来，原因如上所述。要对框架的使用进行建模，我们又定义了两种类构造型：«frameset» 和关联关系构造型 «targeted link»。框架集类代表一个容器对象，直接映射到 HTML<frameset> 标记。它包含客户机页和目标。目标类是一个被其他客户机页引用的指定框架或浏览器实例。目标链接关联关系是指向另一个页的超链接，但它要在特定目标中才能提供。在图 6 的示例中，浏览器显示了一个使用两个框架的常用大纲视图。一个框架根据目标命名为 Content，另一个框架只包含一个客户机页。这一客户机页框架包含书的目录 (TOC)。该页的超链接是有目标的，因此超链接指向的内容在 Content 框架中显示。得到的效果就是页左侧的一个静态目录，以及页右侧的书中每一章的内容。

图 6. 框架示例

实际表示的很多细节在框架集和关联关系中用标注值注明。框架集与目标或客户机页之间的聚合关系上有两个标注值，它们指定目标或页所属的框架集行列。目标链接关联关系上的标注值“Target”用于确定显示页的 «target»。

若目标不与框架集聚合关系，则意味着用一个独立的浏览器实例来显示页。务必要记住这种表示方法用于表示客户机的单个实例。假定多个独立的目标全部在同一台机器上运行，这里的图用来表示一个客户机实例的客户端行为。其他所有部署配置都需要在模型中详细记录，以便于理解。

结论

对于利用 UML 对 Web 应用程序特定元素进行建模所存在的问题和已提出的解决方案，本文讨论的观念和概念只进行了初步介绍。本文的目的在于提出一种一致且全面的方法，将 Web 特定元素建模与应用程序的其余部分集成起来，以便提供对 Web 应用程序设计员、实施员和构架设计师合适的详细和抽象级别。为 Web 应用程序开发的第一个 UML 正式扩展版本已接近尾声。该扩展版本将为构架设计师和设计员提供一种常用方法，借助 UML 表示 Web 应用程序的整体设计。

关于该扩展版本的最新信息可通过 Internet 在 Rational Software Web 站点的 Rose 和 UML 相关部分中找到。


使用Visio 2000逆向工程将代码转换为UML图表

Visimation, Inc.
Microsoft 认证合作伙伴

2001年4月

适用于：
Microsoft Visio 2000 Enterprise Edition
Microsoft Visio 2000 Professional Edition

摘要：Microsoft Visio 2000 Professional Edition 和 Enterprise Edition 包含通过逆向工程将 Microsoft Visual C++、Microsoft Visual Basic 和 Microsoft Visual J++ 代码转换为统一建模语言 (UML) 类图表模型的技术。本文将讨论从每种语言实施逆向工程的步骤。

目录

简介
概述
步骤 1：自定义开发环境
步骤 2：打开代码项目以实施逆向工程
步骤 3：选择“逆向工程”(Reverse Engineer) 按钮
步骤 4：在 Visio UML 模型图表解决方案中创建您的 UML 图表

简介

Microsoft® Visio® 2000 Enterprise Edition 和 Professional Edition 都包含通过逆向工程将代码转换为 UML 静态结构图表的解决方案。该解决方案支持三种语言：Microsoft® Visual C++® 6.0、Microsoft® Visual Basic® 6.0 和 Microsoft® Visual J++® 6.0。Visio UML 模型图表解决方案所采用的 UML 标准为 1.2 版。

每种语言使用的逆向工程技术各不相同。对于 J++ 和 Visual Basic，该解决方案使用开发环境的对象模型来收集静态结构信息。对于 C++，该解决方案将浏览信息文件 (.BSC) 用作结构信息的来源。虽然 Visual Basic 和 J++ 逆向工程都使用开发环境的对象模型，但 J++ 对象模型提供了更完整的信息，因此可得到更完整的逆向工程 UML 模型。C++ 中的浏览信息文件包含最少的信息；因此，它所生成的 UML 模型不如 J++ 和 Visual Basic 逆向工程得到的 UML 模型那么完整。

本文将介绍通过逆向工程转换到 Visio UML 模型图表解决方案所需的步骤。

注意：Visio UML 模型图表解决方案只支持 Microsoft Visual C++ 6.0、Microsoft Visual J++ 6.0 和 Microsoft Visual Basic 6.0 的逆向工程。要使用 Visio UML 外接程序，必须安装 Service Pack 3.0 for Microsoft® Visual Studio®。

概述

要通过逆向工程将您的代码转换到 Visio UML 模型图表解决方案，应执行以下主要步骤：

  1. 自定义 Visual Studio 开发环境
  2. 在 Visual Studio 中打开项目以实施逆向工程
  3. 从“Visio UML 外接程序”(Visio UML Add-In) 工具栏中选择“逆向工程”(Reverse Engineer) 按钮
  4. 在 Visio UML 模型图表解决方案中创建 UML 类图表

本文的其余部分提供了每个步骤的详细指导，并包括特定于编程语言的信息。例如，在自定义开发环境部分，Visual C++、Visual Basic 和 Visual J++ 都有其相应的章节。

步骤 1：自定义开发环境

为了实施逆向工程，第一步应通过添加“Visio UML 外接程序”(Visio UML Add-In) 工具栏来自定义开发环境。以下指导显示了如何将该工具栏添加到 Visual C++、Visual Basic 和 Visual J++ 的不同环境中。

自定义 Microsoft Visual C++ 6.0

  1. 在 Visual C++ 中，选择 Tools 菜单上的 Customize。

  2. 在 Customize 对话框中，选择 Add-ins and Macro Files 选项卡。
  3. 在 Add-ins and Macro Files 列表中，选择外接程序和宏文件列表中的 Visio UML Add-in。确保旁边的复选框被选中，然后单击 Close。

  4. 出现浮动的 Visio UML Add-in 工具栏，其中包含五个按钮。

提示：如果希望该工具栏在每次打开 Microsoft Visual Studio 时都可用，可通过拖动将该工具栏靠接到工具栏区。

自定义 Microsoft Visual Basic 6.0

  1. 在 Visual Basic 中，从“外接程序”菜单中选择“外接程序管理器”。

  2. 在“外接程序管理器”对话框中，选择“可用的外接程序”列表中的“Visio UML Add-in”。对于“加载行为”，选择“加载/卸载”和“在启动中加载”，然后单击“确定”。

  3. 出现带有四个按钮的“Visio UML 外接程序”工具栏。

提示：Visio UML 外接程序在创建工具栏时，还会向“工具”菜单中添加命令。您可以通过从“Visio UML 解决方案”中选择“工具”来找到这些命令。

自定义 Microsoft Visual J++ 6.0

  1. 在 Visual J++ 中，选择 Tools 菜单上的 Add-In Manager。

  2. 在 Add-In Manager 对话框中，选择 Available Add-Ins 列表中的 Visio UML Solution。对于 Load Behavior，选中 Loaded/Unloaded 和 Load On Startup，然后单击 OK。

  3. 出现带有四个按钮的 Visio UML Add-in 工具栏。

提示：Visio UML Add-in 在创建工具栏时，还会向 Tools 菜单中添加命令。您可以通过从 Tools 菜单选择 Visio UML Solution 来找到这些命令。

步骤 2：打开代码项目以实施逆向工程

逆向工程过程从所有这三种语言的开发环境中开始。当通过添加“Visio UML 外接程序”(Visio UML Add-in) 自定义环境后，下一步是打开要实施逆向工程的项目。

Visual C++ 6.0 的附加步骤

对于 Visual C++，在开始逆向工程之前，还必须执行几个附加步骤。第一步是生成项目的浏览信息文件 (.BSC)。以下提供了生成浏览文件的指导。第二步是确定逆向工程中要包含的代码库。设置这些选项的指导将在浏览文件指导之后提供。最后，应在实施逆向工程之前构建项目。

生成 Visual C++ 6.0 的浏览信息文件

  1. 在 Visual C++ 中，选择 Project 菜单上的 Settings。

  2. 在 Project Settings 对话框中选择所需构建配置的类型，单击 C/C++ 选项卡，然后选中 Generate browse info。

  3. 单击 Browse Info 选项卡，指定浏览信息文件的名称和位置，选中 Build browse info file，然后单击 OK。

选择 Visual C++ 6.0 逆向工程所包含的库

  1. 单击 UML Add-in 工具栏上的 Visio UML Options 按钮，设置 Visual C++ 逆向工程所包含的库。

  2. 此时显示 Visio UML Options 屏幕。如果希望在逆向工程中包含 MFC Classes、ATL Classes 或 Standard Include Files 的信息，只需选中所需选项旁边的复选框，然后单击 OK。

步骤 3：从“Visio UML 外接程序”(Visio UML Add-In) 工具栏选择“逆向工程”(Reverse Engineer) 按钮

逆向工程的下一步是从“UML 外接程序”(Visio UML Add-In) 工具栏选择“逆向工程”(Reverse Engineer) 按钮。

对于 Visual Basic 和 Visual J++，此操作将在 Visio 2000 中打开 UML 模型图表解决方案，其中会显示通过逆向工程转换为模型的信息。此时 UML 模型图表解决方案打开，并在“UML 导航器”中显示一个空白的静态结构图表和一个树视图，其中包含从项目中收集的模型信息。

对于 Visual C++，在 Visio 2000 打开并显示通过逆向工程转换到 UML 模型图表解决方案的项目信息之前，可能会显示另外两个屏幕。如果 Visual C++ 工作区中存在多个项目，可在 Select Project 对话框中选择要实施逆向工程的项目，然后单击 OK。

如果项目层次结构中显示了多个浏览文件，可在“选择浏览文件”(Select Browse File) 对话框中选择一个浏览文件，然后单击“确定”(OK)。

步骤 4：在 Visio UML 模型图表解决方案中创建您的 UML 图表

现在，Visio 2000 应该显示您的项目信息。要创建 UML 类图表，请将模型元素从“UML 导航器”(UML Navigator) 拖放到“静态结构”(Static Structure) 图表上。类关系（泛化、实现、绑定）将会自动显示。利用 Visio UML 模型图表解决方案，您可以生成其他 UML 工件，以指定、构造软件项目并使软件项目形象化和文档化。

更多信息

也可访问 Visimation（英文）网站。

Visimation 专门从事 Visio 咨询、定制开发、培训和服务。


使用模式集成UML视图

Alexander Egyed 著，davidqql 译

摘要

模式在系统组合（合成）期间对养成重用可重复设计和体系结构配置的习惯很重要。本论文研究关于模式的知识，它也可用于系统分析检验系统模型的完整性。

为了支持自动分析过程，该工作引入一个视图集成框架。自从每个视图（例如，框图）增加一个额外针对模型的软件系统观点，来自一个视图的信息可能用于验证其它视图的完整性。这种形式的集成要求对视图表明什么以及它们可以共享（或约束）什么信息有更深的理解。因此关于模式在结构和行为上的知识，也是一个用于视图集成自动化的有价值的来源。

介绍

为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(UML)。然而，通常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不仅仅是大多数通用模型所能提供的内容。体系构造是关于：

1) 对实际问题充分建模

2) 解决模型问题并

3) 在现实世界中解释模型方案

这样做的主要重点被置于体系结构的视图（例如框图）内和之间不匹配的鉴别与调和上。我们经常发现这方面的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重点的。我们构造体系不仅仅是因为我们想建立（创作），而且因为我们要理解。这样，体系构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。

已完全成为事实上OO软件开发标准的UML的出现，在这个问题上也没有任何例外。本工作阐述在UML视图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更自动化的方式应用于识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动——映射（Mapping）、变换(Transformation)和分化(Differentiation)。

本论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样有助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模式用作系统分析，而不是将模式用作构建材料作为系统成分。

视图和模型

在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的集合或者视图可以看作模型的一个方面（或视点）。IEEE标准（草案）1471[AT&T1993]将视图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系”。对于利益关联者，我们定义为分享系统注意或兴趣个体或组（例如，开发者，用户，消费者等等）。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关联信息。在UML中，视图本质上是图形的，且往往通过框图来实现。视图（例如类或序列图）服务于下列意图：

l 抽象并简化模型

l 使得不同的利益关联者协调工作

l 为不同解释进行补充（不同观众/利益相关者）

l 提取关于特定关联的相关信息

因此，将会用到什么类型的视图以及什么时候用到它们是强烈依赖于哪个人正在使用和需要完成的相关任务。然而，视图并不是软件开发的银弹，因为它们具体表达基本问题；它们内部及它们之间表现出对等数量的建模元素冗余。

要给出一个简单例子，考虑我们有个设计（例如按照UML类图的形式）的软件开发案例和产品实现（例如，C++代码）。类图和代码表述不同的视图，用不同的方法表达相同或类似的信息。虽然，代码可以从设计中自动产生，这种逼近是有限的，还必须多次加入一些信息。更糟糕的是，现在这些冗余的信息片断必须保持一致——后者大多是手工活动。这样，无论什么时候设计变更了，代码就会变得不一致（反之亦然），我们要应用一些视图调和活动找到产生的不一致并一再保证模型概念的完整性。

视图不匹配和冗余

既然视图是我们处理复杂性唯一有效手段，我们不能指望用某些较少冗余的事物来替代它们。我们需要视图在任何给定的时间对软件开发者不得不处理的信息总数进行分解。“这不是带来复杂性的细节数量本身，而是我们不得不同时了解的细节的数量。”[Siegfried 1996]

然而，冗余性是一个必需的不幸。这暗示我们需要某种鉴别和解决视图之间不匹配的自动化活动的方法。这样，我们所需要就是一些集成和分析视图的框架形体。有趣的是，视图不匹配问题可能的逼近方法是基于它特有的问题——冗余性。我们利用一套视图之间的冗余性意味着一个视图包含关于其它视图并可用作约束该视图的信息。这样，我们使用冗余信息来检验视图之间的一致性和完整性。

例如，如果我们使用一些体系结构模式的形态来构造系统（例如，分层风格），那么设计必须反映体系结构对立的约束。这意味着如果体系结构定义了三层结构，那么体系结构隐含地定义了处理中第一层不使用第二层而与第三层直接对话是不允许的。如果后来系统使用UML设计（例如，使用类和序列图），那么设计元素之内的调用依赖要求与上述的体系结构约束一致。我们将在后面说明一个例子。

UML视图描述 vs 集成

启用视图集成来确定和调和视图要求两个层次的集成——符号集成和语义集成。对于符号集成，意思是模型需要完整表达视图的能力。语义集成通过定义什么信息可以交换以及怎样交换作更进一步精炼。只有在什么和怎样在确立之后，不一致性才可以确定。

统一建模语言（UML），像其他通用软件系统开发模型一样，只是不能很满足上述语义集成。UML提供一个模型用于表达不同框图的视图来处理类、对象、活动、状态、包及其它（参看图 1 ）。然而，UML 不擅长集成他们。在UML视图之间的关联和依赖关系很少被捕获。如果后者没有完成，模型仅仅是松散耦合的或完全无关联的视图集。虽然UML及其元模型在细节上定义了单个视图的符号和语义特征，视图内关联的获取仍然是不够的（在视图之间只存在一些微弱形式的依赖关系，例如类和对象）。

图 1 也表明问题的另一个方面——那就是扩展UML以表达新的和外部概念（例如，风格和模式）。例如，怎样才能在UML中使用更高级的模式例如分层的体系结构模式【[1] [1]】或代理设计模式？在UML中，我们需要再次区分仅仅表述模式和完整集成它们。

图 1 UML中表示法 vs. 集成

视图集成框架

视图集成的主要的障碍是缺乏完好定义的（工程的）模型基础。视图经常使用迥然不同的表示信息方法，而这使得确定它们在哪里和怎样出现重叠非常困难。这样，组合和比较视图的任务经常是手工的而且潜伏着错误的。集成框架的目标是要补偿鉴别和解决体系结构不匹配自动化辅助手段的不足。

如前面简短的叙述，这样做的时候，我们的框架需要处理什么信息和怎样进行交换。我们在那里写到什么信息可被交换以及它怎么能交换的判断需求。在我们的视图集成框架中，我们提到映射和变换这两个活动。我们也说只有在这些活动定义之后，才能够尝试鉴别不一致性。后者我们称之为分化（参看图 2 ）。

图 2 在高层次式样上描写我们的视图集成框架。在那里，系统模型用于表达软件系统的知识基础。软件开发者使用视图增加新的数据到系统模型并且复审现有数据（视图综合）。对于UML，系统模型可能被看作通过UML设计工具（例如Rational Rose）完成的UML模型和视图综合。

系统模型和视图综合两者交互影响就是视图分析。一旦加入新的信息，它就可以针对系统模型进行验证以保证其概念完整性。图 2 表示视图分析可以怎样进一步细分为其上述三个主要活动：

图 2 视图集成活动

l 映射：通过使用命名字典、跟踪和跟踪仿真（例如相同物理类和方法的使用）以及某种关联/模式形式（例如公共接口）来确定相关的信息片。

l 变换：在视图中操作模型元素以便它们（或它们的片段）可以在其他视图中共享（或在系统模型自身中表述）。例如，我们可以使用抽象技术泛化一个详细的框图，我们可使用视图转化在不同类型的视图之间交换信息，或者我们可以按不同的风格重新排列模型元素（或片段）产生新的视角（例如拼结和分割）。

l 分化：详细研究系统模型鉴别系统模型中（潜在的）不匹配。（潜在的）不匹配按规则和约束的形式讨论。此外，不匹配解决规则可与将要怎样解决它们可选方法的不匹配标识规则相关联。分化是强依赖于变换和映射的。

然而，必须注明的是，那些活动不是相互正交的。显然地，我们只有在知道模型元素的正确映射时才能做出有用的变换。这种依赖关系反之也是成立的。通过视图变换导出的信息可以澄清许多映射中的二义性。这样，一个视图可以用于澄清其它视图中的二义性。

此外，如图 2 所示，视图集成不只局限于模式，然而，模式对视图集成构成了非常重要的基础。我们将在后续章节中讨论这种面向模式的视图集成方向。其他非模式相关的视图集成方向在[Egyed1999a]和[Egyed1999b]中论述。上述框架通常在UML之外也适用。

产品订货系统案例

我们将使用一个简单的产品订货系统贯穿全文进行指导，该系统被分成两个主要的子系统——订单获取子系统和订单处理子系统。第一个子系统通过销售代表从消费者获取订单和付款信息。后一个子系统获取仓库管理员对产品订单队列的处理。产品订货系统合成两个COTS（Commercial off the Shelf，已下架的商品化）产品：存货系统处理产品存货，而订单仓库作为数据库（后者既用于产品订货系统又用于存货系统）。

表格 1 表示我们的系统体系结构使用分层模式（或分层风格）进行设计。该体系结构模式将在后面由设计模式和其他设计特征补足。

表格 1 讨论产品订货系统的分层体系结构模式

产品订货系统

- 用户界面（订单获取界面，订单处理用户界面，存货用户界面）

- 订单框架（消费者，付款，订单，订单行，记录器）

- 存货系统

- 网络（LAN）

- 订单仓库

模式怎样有助于视图集成？

在文章展开论述时，我们将揭示关于产品订货系统更多的细节。虽然，由于篇幅的限制，我们既不能在此表述整个系统，也不能阐述所有的集成技术。相反，如前面提到的，我们将集中于视图集成时模式承担的角色上。对应于图 2 中简述的三个集成活动，模式支持如下活动（下节将说明例子）：

映射

模式支持不同抽象层次的视图之间的映射（交叉引用）。例如，一个高层框图指出使用一个已知后来在低层次框图中实现的模式。这样，这类模式存在于低层次框图的知识以及该模式粗略了解（如在[Gamma et al. 1994]和[Buschman et al 1996]中定义）的知识有助于在低层框图中自动鉴别。

模式也支持不同类型视图的映射。例如，模式描述经常指定其结构和它们的动态行为。那么，可以在我们的模型中使用这些知识来交叉引用结构化的和动态的信息。

变换

模式应用于变换的方法与它们在映射中的用途类似。对于变换，我们可以把它们用作抽象和转化。对于抽象，我们意指简化视图的处理。例如，如果我们想知道高层视图和低层视图是否一致，那么我们需要精炼高层视图或者抽象低层视图以使直接比较成为可能。前者不能自动进行，而后者可以。为了抽象视图，需要确定相关的片段，然后，它们被更加简单的事物替换。对此，模式是完美的原始资料，因为它们提供哪些片段属于一起的知识。我们可以使用模式知识抽象低层模式到高层模式（或者对等的单个部件）。

模式也可以如我们在映射中讨论的那样用于静态与动态结构之间的转化。既然模式经常用两种式样描述，我们可以通过结构推导行为（反之亦然）。这样，利用模式我们也可以转化视图。

分化

如图 2 中简述，分化强依赖于映射和变换。这意味着要在视图中找出不一致性，我们需要确定其建模元素的关系，并且需要找出从一个视图到另一个视图变换信息的方法。没有前一个步骤我们不能知道要比较什么信息，没有后一步，我们不知道怎样比较。一旦上述步骤完成，我们可以使用两个主要技术比较视图：

l （图形）比较：依靠变换的视图和原始视图的对比进行比较。该技术暗示：一个视图可以保留充分完整的风格变换为另一个视图。

l 约束和规则检查：我们频繁地发现视图不能广泛的变换为另一个视图，但它的少部分和片段可以。在这种情况下，我们可以使用规则和约束来论述和分析这些片段。

对于分化，设计模式并非直接有用，然而，我们通过映射和变换收集到的有关视图的信息却可以。我们已经简短地讨论模式怎样有助于映射和变换视图。在这些例子中，比较视图是直接的，因为映射和变换启用直接（图形）比较。无论如何，模式在约束和规则检查中也非常有用。例如，我们在表格 1 中介绍的分层模式定义了自然的约束：用户界面只允许与订单框架对话，订单框架依次只能与存货系统对话等等。该体系结构的模式影响了设计的结构和它的行为。

在产品订货系统中使用模式

本节通过说明模式可以怎样在我们的产品订货系统语境中应用于集成活动的例子补充上述论述。

分化

图 3 使用UML包说明我们系统的高层设计视图。该图显示主要订单系统部件（或子系统）的交互。关于分层体系结构的知识现在可以帮助我们在表格 1 中的体系结构和图 3 的设计之间自动确定不匹配。表格 2 总结两个视图对立的约束。

体系结构视图约束从表格 1 导出。它们定义我们系统层次之间的调用依赖关系（例如，用户界面依赖于订单框架）。图 3 是设计视图约束的基础。该图说明一个含有一套包以及它们之间调用依赖的UML包图（包和依赖的语义在[Booch-Jacobson-Rambaugh 1997]中定义）。

表格 2 体系结构上和设计视图对立的约束

体系结构的视图约束

体系结构[用户界面取决于订单框架]；

体系结构[订单框架取决于存货系统]；

体系结构[存货系统取决于网络]；

体系结构[网络取决于订单仓库]；

设计视图约束

设计[订单获取UI取决于订单框架]；

设计[订单处理UI取决于订单框架]；

设计[存货UI取决于存货系统]；

设计[订单框架取决于存货系统]；

设计[订单框架取决于网络]；

设计[存货系统取决于网络]；

设计[网络取决于订单仓库]；

映射

设计[订单获取UI] 映射到 体系结构[用户界面]

设计[订单处理UI] 映射到 体系结构[用户界面]

设计[存货UI] 映射到 体系结构[用户界面]

设计[订单框架] 映射到 体系结构[订单框架]

设计[存货系统] 映射到 体系结构[存货系统]

设计[网络] 映射到 体系结构[网络]

设计[订单仓库] 映射到 体系结构[订单仓库]

完整性规则

对于所有体系结构的视图约束存在设计视图约束；

例如：

体系结构[用户界面取决于订单框架] =>

存在：设计[订单获取UI取决于订单框架] 或者

设计[订单处理UI取决于订单框架] 或者

设计[存货UI取决于订单框架]

一致性规则

对于所以设计视图约束存在体系结构约束；

例子：

设计[订单处理UI取决于订单框架] =>

存在：体系结构[用户界面取决于订单框架]；

表格 3 描述产品订货系统的分层体系结构模式

产品订货系统

用户界面（订单获取UI,订单处理UI,存货UI）

订单框架

存货系统

网络（LAN）

订单仓库

建立这些约束是变换的责任，并且在这种情形下能够自动完成。例如，利用我们在表格 1 中的分层模式的知识我们可以自动导出层间的调用依赖关系。优点是模式的语义只需要定义一次并且可以在以后重用。视图的语义和符号也可以看作模式。这样，图 3 的包图带有一套预定义的相关约束。一旦定义，就可以对包图的不同实例导出设计约束。

表格 2 的映射部分定义了体系结构视图（表格 1 ）和设计视图（图 3 ）部件之间的关系。在这个例子中，用于映射的模式使用不是那么明显。我们将在后面讨论它们对于映射的使用。

表格 2 中最后两个部分是部分的分化活动。在那里，定义了两类规则，一个用于一致性，另一个用于完整性。如果体系结构定义的一些部件或连接器没有反映在设计中，就可能显示潜在的不完整。在另一方面，如果设计与体系结构抵触，那么这可能指出潜在的不一致性。另外，对于每套我们比较的视图，规则只需要定义一次；那些规则然后可以重用。在体系结构和设计实现之间确定不匹配现在是评估规则和约束的事情。这样揭示了没有完整性方面的不匹配情况，然而，有些不一致性方面的不匹配：

1) 存货UI部件对于存货系统的依赖与分层体系冲突，用户界面不允许不经过订单框架直接与存货系统进行交流。

2) 类似地，订单系统要求使用存货系统访问网络。

图 3 UML中的高层设计（包图和依赖）

确定这些不匹配并没有对他们的起因给出任何反馈。例如，是体系结构还是设计错误？表格 3 说明通过提升存货系统到订单框架同一个级别来解决上述所有不匹配而不会引入新的不匹配的可能方法。我们不相信实际的不匹配解决方法将彻底地自动完成。这种方法与先前的自我纠错源代码编译器的尝试相同，这种努力最后因为所包含的社会和技术的复杂性而失败了。可是，我们相信提供给设计者不仅仅使用（潜在的）不匹配，而且用关于怎样在处理不匹配以及理解它们这两者高度有利的情况下解决它们。此外，它可能对发现处理具有更好选择情形的技术非常有好处。我们将在[Egyed 1996]中更详细地讨论这种情形。

映射

图 4 表明我们系统的另一个视图，图 3 的一个精炼。另外，该视图可以对修订的体系结构和高层设计都能进行校验，然而，并没有发现不匹配。该视图用另外的设计模式例如模板【 [2] [2]】（Template）模式（通过<<Template>>构造型指定）和代理【[3] [3]】（Proxy）模式（通过《Proxy》构造型指定）。我们将使用它们进一步探究模式在视图集成中的价值。

订单处理UI

订单获取UI

图 4 高层设计视图使用UML类和包的精炼

图 5 低层设计视图使用UML类图

图 5 描写了对应的低层实现，它不只是解决用于图 4 中的模式，而且也精炼其它的一些建模元素。顶部三个类对应用户界面层，存货系统可以通过存货代理来访问，仓库可以类似地通过仓库代理来访问。要找出该视图是否和先前的视图一致，我们可以运用几个集成技术。

首先，我们需要找出哪些模型元素互相对应（映射）。这有几种技术可以应用，例如名字的相似性等等。可是，在该例子中模式的广泛使用使我们能够开发关于它们用于映射的知识。通过图4中的高层设计我们明白几个事实：

l 模板模式用于订单行（OrderLine）

l 代理模式用于桥接订单行（OrderLine）（产品）与存货系统

l 代理模式用于使用Oracle 数据库桥接订单框架子系统

l 接口特征（例如，消费者类与订单、付款、和消费者UI接口）

访问点

访问点

代理模式结构

模板模式结构

图 6 结构化模式知识（改编自[Buschman et al. 1996]）

虽然从技术上讲，最后一项并不是一个清楚定义的模式，然而它构成类配置的知识——这样，接口特征可以看作模式，即使它们大部分只是领域模式。关于领域的模式知识如同预定义的模式（参看图 6 ）一样使我们现在可以推论建模信息的关系。映射图 4 和图 5 的任务被精简为使用如图 6 所论述的预定义结构化模式知识来确定上述模式和（接口）特征的位置。

用图 6 作为指导，我们可以容易地确定模板模式（产品，队列，以及产品队列对应于订单行（OrderLine））的对应。虽然，它也可以容易找到代理模式，怎样能够区分它们却不够清楚。注意到目标是使得计算机自动鉴别它们。要在后来做到这一点，我们可以使用上面讨论的接口特征（模式）。想法是，至少存在一些映射或者能够通过名称相似性来建立。使用该额外信息它可能自动从Oracle模式区分存货（Inventory）模式。

不幸的是，通过模式的映射仍然比上述例子可说明的要更困难一些。我们作了简化的假定，就是模式的结构和行为是静态的。虽然，通常模式不是那些精确定义的，并且我们需要它们更一般的描述。图 5 表明这样一个例子，仓库代理模式看上去不象定义的那样。然而，既然网络是部分代理类，它就可以合并到代理类中，并且代理类继承它所有的依赖关系（下一节的Rose/Architect将表达一个模型来这样做）。

该映射技术的另一个问题是模式，在识别的时候，有时可能只是粗糙地指出它们的位置。例如，对应于队列，产品，和产品队列，订单行队列（OrderLine Queue）可以在低层框图中找到。虽然这也是正确的，但是它丢失了同时在低层框图中表示的组成订单行（OrderLine）。

变换

模式和抽象

单独的介于图 4 中的高层视图以及图 5 的低层视图之间的映射不足以确定不匹配。例如，在图 4 可以看到付款是消费者的一部分，然而在图 5 中这种关系更加复杂。为校验两个图是按相同的方法讨论关系，我们可以使用Rose/Architect概念。

Rose/Architect [Egyed-Kruchten 1999]认为模式分组为三类，并且使用及物关系替换为更简单的模式。在类图中，及物关系论述那些不直接连结的类之间的关系。然而一个关系可以通过其他类（例如helper类）存在，它在它们之间形成了一个桥（例如，假设上述例子中付款和消费者并不直接相连，但是它仍然通过helper（帮助者）类事务（transaction）和账目（account）类给出关系）。这样，如果发现某些公式，它们可以按有效精度导出及物关系，那么，可以按工具形式提供简化和抽象类图方面的自动支持。这将允许设计者通过删除“帮助者类”从现有的、更细节化的模型中抽象出重要的类，这样将使得它们更进一步描写和分析类之间中间关系，即使这些类分散在整个模型的不同位置（例如，不同的框图，或者在不同的包和名字空间中）。

RA提供这种机制而[Egyed-Kruchten 1999]详细地讨论了这种技术。当前，RA模型由大概80条抽象规则组成。例如规则4，论述了一个类被第二个类泛化（继承的反义词）并且父类是第三个类的聚集（部分）（参看图 7 ）的情形。这种三类模式现在可以删除中间类来简化并创建一个从第一个类到第三个类的及物关系（在该例子中的一个聚集）。下面的RA模型讨论这些规则以及必须怎样应用它们来产出有效的结果。

图 7 表明我们的低层设计视图（图 5 ）中的付款给消费者关系案例的RA精炼步骤。在应用两个规则（分别是规则4和规则17）之后我们得到一个具有两个类以及它们之间依赖关系的简化模式。如果这也可以对其他类以及在映射小节中讨论的模式【[4] [4]】进行处理，我们就可以自动产生更高层次的类图（图 8 ）。产生的这个抽象视图现在就可以与我们在图 4 中描写的原始的更高层次类图直接进行比较了。这样，通过模式的使用我们可以转换视图以便它以非常类似其它视图的方式表达信息。比较视图现在可以简单地使用一些图形比较算法（也可参看上面所说的分化）的形式来完成。图 8 也显示了可能的不一致性。例如，从付款到订单的聚集丢失了，存货系统对Oracle数据库的调用没有使用网络部件，以及一些链接是不同的（例如，使用关联链接而不是依赖链接）。在变换（抽象）之后，这些不匹配可以容易地识别。

必须注意的是抽象没有彻底地自动完成。虽然，模式有助于在某些建模信息之间确定映射和变换，它们不能完全自动化该过程。因此，需要一些手工辅助来导出图 8 。而且，RA工具当前只能对付如图 7 讨论的简单的三类模式而不能处理图 6 中讨论的更加高级的设计模式。这样，由于该作业的缘故，抽象设计模式（例如代理）由手工完成。然而，一旦更加复杂的设计模式概念体现到RA中，这种抽象可以是自动的。对此，设计模式需要按照它们的输入（源）和目的以及它们的访问点进行讨论。

使用规则17

使用规则4

图 7 通过Rose/Architect的模式抽象

当前，另外一个RA缺点是它只能用于抽象类图信息。虽然该技术也可以扩展到抽象其它类型的视图，但是当我们想要比较不同类型视图的建模元素时它仍然对我们没有帮助。下一小节将论述这种情况。

模式和转化

鉴于抽象处理简化视图的情形，转化处理在不同类型视图之间共享建模信息的情况。例如，上述讨论中，我们广泛使用类和类图，它们按结构化形式表达信息。既然结构视图在表示系统行为通常是不足的，那么行为视图例如序列图就要用来填补这个缺口。

例如，再考虑表格 1 中体系结构分层模式的约束（与高层设计视图的约束一起）。在那里体系结构的约束决没有覆盖全部分层体系结构的行为。一个分层的体系结构不只是限制哪些层允许互相对话，它也限制交互的方向。虽然结构框图比如类图可以描写某些方向性的依赖，但是它可能忽略其它的方面。

图 8 使用Rose/Architect和设计模式抽象的类图

图 9 关于新订单创建的序列图（对应于低层次框图）

图 9 显示了一个更加复杂的行为案例。一个UML序列图在这里用于描述创建一个新的消费者订单的可能场景。在某些用户输入被校验之后，它检验消费者是否存在。如果不存在，新的消费者被创建，在此之后，建立新的订单。该场景描写低层次设计视图（图 5 ）某些行为方面。照此我们可以使用图 5 自动检验类（或对象）之间的调用依赖，在这种情况下没有揭示不匹配情况。该序列图也符合我们的体系结构，因为所有的层次约束都观察到了（两者都可以自动检验）。既然按照组件的行为结构视图具有高度二义性，我们可以再次利用我们的模式知识精炼行为的信息。

图 9 利用订单仓库代理，网络，和Oracle数据库以及在映射中我们发现的那些对应代理设计模式的类。如在[Buschman et al 1996]中所发现的那样，图 10 显示代理模式结构的和行为的定义。效应上，行为定义是结构的一个转化。这样，我们可以使用该知识来检验图 9 的正确性。

因为在图 10 中的代理定义和图 9 中代理实例化之间的抽象级别并不相同，我们需要先抽象图 9 。基本上，我们可以使用Rose/Architect概念通过合并网络到订单仓库代理中来抽象网络（这是有效的，因为网络是代理的一部分）。此后，定义和实例化之间的直接比较是可能的。在该案例中没有发现不匹配。

图 10 代理模式的结构和行为

由于篇幅的限制，我们不可能进一步讨论这个过程更多的细节。请参考[Egyed 1999a]和[Egyed 1999b]得到更多信息。

相关的工作

视图集成的缺乏并不是新发现。相反，很多模型描述都谈论到保持视图一致的需求。有时，处理模型提供有关什么任务可以提升体系结构概念完整性的附加方针。例如，一个关于使用WinWin Spiral Model(螺旋模型)[Boehm et al 1998]的案例研究建议在LCO(life-cycle objectives, 生命周期目标)和LCA(life-cycle architecture，生命周期体系结构)阶段之后使用体系结构复审板（Architecture Review Boards）[AT&T 1993]来检验和证实分析和设计的完整性。类似的观点可以在其他多不胜数的研究工作中看到：

l [Sage-Lynch 1998]讨论集成（企业范围）的不同方面。他们一再地强调“体系结构在系统集成中承担重要的角色。”他们针对三个主要的视图表达需求：企业视图，系统过程和管理视图以及技术实现视图——并且他们强调在这些视图之间保证一致性。

l [Rechtin 1991]非常强烈地要求和接口定义同等地强调需求的有效性和一致性。他进一步促成问题检测和诊断的需要。

l [IEEE 1998]体系结构评估演说。“评估的意图就是要确定一个体系结构的描述质量，以及通过它评定关联的体系结构的质量”。他们进一步陈述了确定哪种体系结构可以进行校验的评价准则需求。

l [Nuseibeh 1995]写到“不一致性是一个复杂的、增量软件开发过程不可避免的部分”，还有“增量软件系统开发包括不一致性的检测和处理”。

l [Perry0Wolf 1992]早就了解到软件体系结构的重要性，并且他们将它陈述为体系结构四个主要好处之一，它们是“用于依赖性和一致性分析的基础”。

l [Shaw-Garlan 1996] 非常激奋地讨论体系结构，作为“系统设计的实质上的民间传说，很少具有一致性和精确性”。他进一步陈述“软件体系结构在框图和通俗散文中找到它的根基。不幸的是，框图和描述是高度二义性的。”

这些以及更多的参考文献，谈论到集成的需要（或缺失）。然而，他们通常不详细地讨论包含的活动（也有些例外）。有时这些工作并不是出于对集成逼近特别的喜爱。在另一方面，有时提议的技术经常只是打算让人们能够互相交流。例如，体系结构复审板[AT&T 1993]或者检查过程（Inspection Process）[NASA 1993]主要地应用于使大多数有能力的人们在一起工作，以便他们能够共享信息。这些技术可能遵循已定义好的过程（例如，检查单）并且可能出产有效的结果，但是实际上，确定和解决瑕疵的活动仍要手工完成，没有多少自动协助。

结论

本工作讨论了在UML视图中体系结构不匹配的原因以及说明了集成技术可以怎样按更自动化的方式应用于鉴别和解决它们。我们用统一建模语言(UML)的语境及其视图（框图）来表述本工作，并使用一个例子来引导视图集成的主要阶段。在本论文中表达的视图集成框架并不限制于UML。它也可以应用于其它模型和视图（例如体系结构描述语言）。

本工作进一步介绍了在分析软件系统模型概念完整性中的模式使用。既然模式是完好描述和文档化的，在结构和行为两方面，我们可以频繁地使用这些知识用于视图分析。照此，我们说明了关于模式的知识可以用于映射视图（相关建模信息的交叉引用），也可以从一个视图到另一个变换信息。后来我们说明了抽象（Rose/Architect）和变换技术。

虽然视图集成框架创建的意图是支持自动的视图分析，手工介入经常还是有必要的。既然本文只是集中于模式，其他集成技术也就没有讨论（也可参看[Egyed 1999b]）。我们将发表的内容为：

l 发现（或开发）覆盖更加广泛视图范围的集成技术

l 处理可量化性

l 增加更多的精确性到UML中澄清二义性。

l 论述自动化支持的不匹配解决的情况（而不仅仅是不匹配的自动确定）

不管这些问题，我们已经取得在该领域广泛的进步并且我们感觉到使用集成技术的好处，例如在本文中所讨论的，是无限的。我们已经表明不匹配鉴别的任务自动化是可能的（至少部分可以），既然计算机在比较视图无疑更加有效率，这就意味着本质上节省了人工劳动。我们近似的另一个好处是不匹配可以在它们创建的时候就确定。每逢新的数据加入到模型中，工具就可以验证它们。

参考文献

Ø AT&T (1993) “最佳趋势实践：软件体系结构确认,” AT&T, Murray Hill, NJ.

Ø Egyed, A. (1999a) “UML中体系结构视图集成,” 提交给 ESEC/FSE’99, http://sunset.usc.edu/TechRpts/Papers/usccse99-511/usccse99-511.pdf.

Ø Egyed, A. (1999b) “在UML中集成体系结构视图,” 资格报告, 技术报告,软件工程中心, 南加州大学, USC-CSE-99-514, http://sunset.usc.edu/TechRpts/Papers/usccse99-514/usccse99-514.pdf.

Ø Egyed, A. and Kruchten, P. (1999) “Rose/ 设计师：可视化软件体系工具”, 第三十二届系统科学会议年报议题

Ø Booch, G., Jacobson, I., 和 Rumbaugh, J. (1997) “用于面向对象开发的统一建模语言,” 文集, 版本 1.0, 瑞理软件公司

Ø Buschman, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996) “模式系统：面向模式的软件体系,” Wiley.

Ø Boehm, B., Egyed, A., Kwan, J., and Madachy, R. (1998), “使用 WinWin 螺旋模型：案例研究,” IEEE 计算机, July, pp. 33-44.

Ø Gamma, E., Helm, R., Johnson,R., Vlissides, J. (1994) “设计模式：可重用面向对象软件元素:,” Addison-Wesley.

Ø NASA (1993) “正式软件检验过程标准,” NASA-STD-2202-93.

Ø Nuseibeh, B. (1995) “软件开发中的计算机辅助非一致性管理,” 技术报告 DoC 95/4, 计算系, 帝国大学, 伦敦 SW7 2BZ.

Ø Rechtin, E. (1991) “系统体系，创建和建立复杂系统,” Prentice Hall, Englewood Cliffs, NJ.

Ø Perry, D. E. and Wolf, A. L. (1992) “软件体系结构研究基础,” ACM SIGSOFT 软件工程笔记, 十月号.

Ø Sage, Andrew P., Lynch, Charles L. (1998) “系统集成和体系构造：原理概述，实践和远景,” 系统工程, 国际系统工程会议期刊, Wiley Publishers, 卷 1, 第 3, 176-226页。

Ø Shaw, M. and Garlan, D. (1996) “软件体系结构：形成原理的透视,” Prentice Hall.

Ø Siegfried, S. (1996) “理解面向对象软件工程,” IEEE Press.

[1] [1] 注意我们如[Bushman et al 1996]所作，可互换地使用术语模式和风格。

[2] [2] 对共同使用的模板隐藏源模板和类元

[3] [3] 为其他对象提供一个代理限制对它的访问[Gamma et al 1994]

[4] [4] 注意：我们可以用高层代理简化较低层次设计模式


选择一种UML建模工具

信息仓储支持 | 双向工程
HTML文档化 | 完全UML1.3支持
选择列表 | 数据建模
版本控制 | 模型导航
打印支持 | 图表视图
图表输出 | 脚本
健壮性 | 平台
升级 | 未来...

以下标准用于评估一种UML工具。当然，除了已被列出的以外，可以用这些标准来评估的产品还很多，但如果你想选择最好的，请花时间按照清单对产品作测试。如果你特别重视某项标准而在清单中没有列出， 请告诉我们。

信息仓储支持

Top

对于一个大项目，信息仓储(Repository)对在开发人员之间共享组件设计是必要的。两个以上的开发人员可以共享同一模型的的组件，甚至可以通过在适当级别上定义所有权和共享权来合作进行单一组件的开发。

信息仓储通常用提供数据共享和并发控制等特性的数据库来实现。 通过提供锁定和只读访问，信息仓储允许一个开发人员拥有整个模型而其他人对该模型及其组件只读访问，或者将这些组件结合到自己的设计中。重要的是： 这种工具应该允许你从另一个模型只引入你所需要的组件而不必引入整个模型。

构造信息仓储的另一个令人感兴趣的方法是利用项目的源代码，使用源码控制系统来提供并发控制。这种方法的好处是在源码和模型之间有更高级别的同步，另一个好处是更除去了另一个数据源--别忘了，如果你为信息仓储使用了数据库，你必须对各种存储数据分别备份并完成在模型、信息仓储和源代码之间的三方同步，而不止是在代码和模型之间的两方同步。

有了建模工具对信息仓储的支持，对任何组件的修改将被自动传播到所有引入该组件的设计。

双向工程

Top

对源代码(Java, C++, CORBA IDL)的正向和逆向工程的能力是一项复杂的需求，不同厂商在不同程度上成功地支持这一点。对正向和逆向工程这两方面的成功结合，定义为双向工程。

正向工程在第一次从模型产生代码时非常有用，这将为你节省许多用于编写类、属性、方法代码的琐碎工作的时间。

在以前没有模型存在的情况下，将代码转换成模型；或者在迭代结束，重新同步模型和代码时，逆向工程非常有用。

在一个迭代开发周期中，一旦一个模型作为迭代的一部分被修改，另一轮的正向工程应允许所有加入该模型的新的类、方法、属性的代码被更新。这个步骤通常不被开发者采用，因为许多工具在这个过程中没有办法管理源代码，问题在于源代码中不只包含与模型有关的信息。工具必须精于对在新一轮正向工程之前已有的源代码进行重新构造。

至少，建模工具应成功支持一开始的正向工程和全过程的逆向工程。同样，建模工具对纯Java语言的逆向工程的支持应该毫无问题。一定要针对你自己的源代码确认这一点，因为我们见到过优秀的工具在对Java的一些特性如内联类(inner classes)等进行逆向工程时失败了，每一次进行逆向工程时，你不得不把讨厌的代码注释掉----确实非常痛苦。

HTML文档化

Top

对象建模工具应能为对象模型及其组件无缝地产生HTML文档。HTML文档提供对象模型的静态视图，以便开发者通过浏览器迅速查询而不需要加载建模工具本身。另外，通过产生HTML文档，所需建模工具的许可证(licenses)会因减去那些对模型只需要有只读权限的人而减少。

HTML文档应包括模型中每个图形的一张位图，并允许通过超链接浏览整个模型。产生HTML文档所需的时间应是合理的。现在许多产品在不同程度上成功支持这一点。再说一遍，你必须亲自测试这个特性，在特征表上有打勾并不能保证成功支持。

完全UML1.3支持

Top

虽然许多工具声称完全支持UML1.3，实际上，这是一项复杂的需求，一些工具并不能做到广告所声称的完全支持。至少应支持的图表有：用例图(Use Case diagrams)，类图(Class diagrams)，协作图(Collaboration diagrams)，顺序图(Sequence diagrams)，包图(Package diagrams)，状态图(State diagrams)。

类和方法的选择列表

Top

建模工具应在一些关键界面上提供选择列表:

协作图(Collaboration Diagrams)和顺序图(Sequence Diagrams) --工具应允许从模型的类列表中选择一个类，把一个对象分配给它，并允许对象间传送的消息能够从接收消息对象(类)的有效方法列表中选取。

类图(Class Diagram) --工具应允许从别的包或模型的类列表中选择并引入类 。

选择列表特性在直观上对建模工具至关重要，可以看作是必备特性。能够迅速从列表中选择一个对象到另一个对象的消息，给开发顺序图和协作图带来很大的方便。

数据建模集成

Top

对象建模工具应允许集成数据建模工具。有许多方法可以提供这种功能。一种方法是UML工具提供将对象模型转换成DDL(数据定义语言，用于为类创建表的SQL)。另一种方法是UML工具输出元数据到能够输入这些元数据的数据建模工具，并将其作为数据模型的基础。一套先进、完整的工具应允许数据模型和对象模型之间在每次设计的迭代之后同步。

版本控制

Top

建模工具应允许储存各种版本，以便后续迭代开始时，以前的版本仍然可以得到，并用于重建或保持基于该版本的已有代码。

模型导航

Top

建模工具应提供强的导航支持以允许开发者全盘浏览模型中的所有图表和类。一种方法是提供一个按名字排序的类目录或选择列表，以便设计人员随意跳到图表中想去的类。

对于大的图表，工具应使得在缩放和平移时，能够轻松实现浏览。

工具也应允许在使用双向工程时，对类的源代码轻松浏览。

打印支持

Top

建模工具应允许一张大图表能够准确地用多个页面打印出来，并提供打印预览和缩放功能，轻松地使图表能够在所需页数内放置。允许将一张图表放置在单页中的能力在清单中是高要求。不幸的是，我们发现许多工具很难用无缝的方式完成这项重要的任务。

图表视图

Top

建模工具应能方便定制类及其细节的视图。例如，它应有可能从图表中排除所有的get/set方法，因为它们会对阐明一个图表造成混乱。方法的全部信息应允许容易地根据不同级别细节的需要显示或隐藏。属性和方法的可见性(private, protected, public)是用于选择什么该显示，什么该隐藏的另一个尺度。

输出图表

Top

一个经常被忽略的关键特性是用某种格式输出图表，以便引入到文字处理文档或Web页面中。用于输出的最流行图像格式是GIF、PNG和JPEG。输出时，工具应允许你定义所产生图形的首选分辨率和尺寸。这个功能需求来自那些野心勃勃，需要写一本包括图表的UML书籍的作者，或者希望将他们的工作展示在网站上的人。

脚本

Top

用脚本编程是建模工具应该支持的另一个强大的特性。有了脚本功能，高级用户可以创建能在建模工具内直接访问对象模型的脚本来添加其它功能，例如：为当前开发的项目做的项目管理表格，定制文档，定制代码，报表和度量。一个定制代码的例子是集合类和用于访问集合类的get/set方法。

为了方便使用脚本，建模工具应公开访问自身对象模型的接口，以便在开发时能提供对对象模型组件的访问。(如果这一句听起来有点绕口，请再读一遍。)例如，脚本编写者应能在整个迭代周期中访问类图中类的集合，从而能够通过类对象的accessor方法来访问类的属性。当然，脚本语言自身应该是面向对象的；一个明显的选择就是Java语言本身，另一种选择就是Python脚本语言。

健壮性(Robustness)

Top

你的UML工具需要象岩石般坚固可靠，以防止设计期间工具崩溃而使用户的时间和生产率在不知不觉中损失，或者在模型没有备份的情况下崩溃。我们曾亲眼见过许多领先的工具因为崩溃或文件损坏而引起数小时的工作成果丢失。如果你是一位开发人员，你知道那种因“生产率高的软件”反而比粗糙的代码工具生产率要低而产生的蔑视感觉。如果你是一位经理，你会看到被要求使用一种不可靠的工具时开发人员的愤恨。

今天，健壮性常被发现于用Java实现的应用程序(JVM运行时保护)或开放源码的项目(在web范围内并行调试)。发现某种特定的UML工具是否健壮的最快方法是在comp.object等新闻组四处询问，你一定会听到许多抱怨的！

可用于此处的另一个策略可以借鉴有效率的办公应用程序，我们也推荐工具开发商采用这种策略。该策略就是让UML工具每隔一定时间间隔就在背后自动保存模型。

平台

Top

为了使你在建模工具上的投资得到最大回报，请慎重地考虑工具将运行在哪种平台上。你需要为Windows还是Unix开发软件？还是二者都要？将在哪种平台上开发？

最近的各种事件一起推翻了这个神话：一流的跨平台图形用户界面还不能实现或者拥有一个"最少共同支配者"的视感。很长时间以来,这是不可能的(除了基于HTML的应用程序之外)，直到最近Java的Swing用户界面的出现。但是，跨平台工具需要在Linux等常用平台得到支持，以大规模地被程序员们采用。

Sun最初几乎没有做什么事情来促进Java在Linux上的应用。但最近工业界元老们，主要是IBM，IBM保证在他们所有的硬件平台上为Linux提供无限广泛的支持，并支持Apache/Jakarta项目, IBM现正快速地在Linux上推广Java。也许因为IBM已经开始为主要的Linux厂商发放它的JDK 1.1.8版本，Sun被迫支持在Linux上的 全功能JDK 1.2 （带Swing的Java2）的发放。通过Blackdown小组的努力，这个Linux上的Java端口大部分已被完成。

迄今为止我们已经测试了一种Linux平台上基于Swing的领先Linux工具，结果优秀。但要告诫的是：128M内存是必需的。

版本更新

Top

你需要选择一种将会不断通过修正错误、改进性能、添加新特性来进行改进的建模工具，毕竟你在时间和金钱上进行了一项大的投资，而且改换到另一种建模工具并不容易。

小心那些已经被大公司拥有的产品。在兑现所有期权之后，最初的开发者常常会离开公司，寻找下一次大的机会。寻找有才能的、能读懂和维护最初并非由其编码的软件复杂模块的程序员并不容易。这种场景也会出现在开放源码项目上。

如何能知道一种产品是否在改进？向销售代表询问下一版本发放的详细时间表以及该产品将来的蓝图。密切观察产品改进和添加新特性的速度。产品计划什么时候支持UML 1.3？图形界面是否支持最新的流行样式？你也可以看看该公司的网站：如果产品发布和外界评论是旧的，就是可疑的。

未来...

Top

现在我们来看看对未来有什么希望。建模工具的当前成熟程度表明，工具厂商准备通过添加高级特性来使产品达到新的高度。我们希望在下一代产品中看到以下特性的出现。

集成编辑器

Top

在模型的迭代开发过程中，将UML图表和相邻窗口的源代码匹配，是非常有效率的。支持这种视图协调的产品可以给模型设计者的工具箱添加一个额外的功能选项，以直接给建模工具添加强大的源代码编辑特性。当建模工具不必作为设计者的首选编辑器时，能够在代码里直接更改方法的名字或原型，并立即反映到模型中。

最想要的特性是类似emacs等流行编辑器的键盘仿真，另一个热门特性是通过改变颜色来突出语言关键字，注释等等，提高了代码的易读性。一个重要特性是在类图中选择一个类、属性或方法时跳转到匹配代码行的能力。 最重要的是, 编辑器应该是快速易用的。

作为变通的方法，另一种解决方案是允许建模工具和开发者喜爱的编辑器通信。例如，通过一个热键，允许建模工具从当前活动窗口跳转到伴随编辑器的匹配代码行。

自动生成

Top

我们真正想在不久的将来看到的一个特性是，建模工具帮助产生交互图和状态图的能力。

工作方式是：在一个已有的程序的执行过程中，建模工具应容易生成一个追踪文件，目的是获取对象间互相传递信息时的交互。产生追踪文件后，建模工具将被用于分析该追踪文件，以发现对象交互的模式。建模工具应允许用户从一组类中选择一个来分析，然后展示被追踪文件记录的每个类唯一的一套交互，允许用户为模型选择交互。最后，工具应能够产生一张基于真实记录对象交互的顺序或协作图。

很酷吗？它并不象听起来的那样太过前卫。因为追踪技术已经十分成功地应用在帮助开发人员追捕他们的程序中性能瓶颈的工具中。这类产品一个很好的例子就是KL Group的JProbe，用于分析Java程序的性能。

使用同样的技术自动产生状态图也是可能的。对以前描述过的顺序的修改将允许用户为状态机里的状态指定基类的名称。建模工具将追踪基类的衍生类之间的交互。从这种追踪，建模工具能够通过描绘每次被记录的状态迁移来创建状态图。

管理工具

Top

如果你是项目经理中的一员，你最有可能想要能够估量你的O-O项目进展如何。一个应被集成到建模工具中的很好的特性是能够输出模型信息到允许你追踪项目设计和实现进程的工具中。由于它的通用性和可塑性，电子表格是实施这个解决方案的理想工具。项目管理工具也是理想的候选。

这个特性如何工作呢？在高层次，通常你想追踪的是模型中的类和负责在这些类上工作的的人。 你想知道什么时候有人开始在该类上工作，完成任务到了哪种水平。在下一层次的细节上，你想要知道每个类的方法。在这一层次，你可能想要知道哪种方法已经包括在交互图中，或在实施阶段，每种方法完成了多少代码量。

要使这个特性起作用，你需要“敏捷”地更新你的项目管理信息。不象报表工具那样总是从头产生一个新报表，你只需要在第一次输出所有东西。产生初始报表后，你的建模工具应该只被要求用新信息来修改你的管理工具。根据用户需要控制的级别，建模工具能在输出之前展现给用户一个修改的清单。

建立一个项目管理链接的一个美妙的好处是，提供把分析和设计阶段的完成日期作为目标的能力。具体方法是通过计算进展速度，并基于完成模型所需的剩余的工作，使用这个速度来计算预期的完成日期。

度量(Metrics)

Top

当你的项目开始成熟时，你可能需要知道你的模型的度量。度量能在一个特殊的模型的生存质量上给面向对象分析员一些即时的反馈。一些感兴趣的度量包括：类层次中的超类数量，每个类中方法的数量，每个类中属性的数量，get/set的数量，方法重载的数量，每个方法的代码行数，public、private和protected方法的百分比，每个类的耦合度（该类知道另外的类的数量），以及被注释方法的百分数。

度量可以通过一个报表界面提供，或者，更好的是，通过一个到电子表格的链接，类似于前面描述的项目管理链接。

SVG: 矢量图形

Top

为达到真正的、标准化的矢量图形输出/输入功能，UML工具厂商即将有一种选择。W3C的可缩放矢量图形(Scalable Vector Graphics, SVG)建议是可格式化图形的一种XML语法，成熟的1.0版本规范已经进展到“最后预览”阶段(3/3/2000)。一旦被完全认可，你可以留意HTML浏览器厂商什么时候在他们的下一代浏览器中提供支持。

为什么是SVG？因为一套用这种矢量图形格式输出的UML图表可以被链接到网页上。“over the web”的UML设计文档的读者将能够使用这种图形浏览技术，如在浏览器内缩放和平移，来更轻松地浏览一张大的UML图表。还有，和GIF格式图形相比，这种格式将戏剧性地提高通过web加载大图形的速度。请看今天Macromedia Flash的展示在浏览器中加载是如何之快，就可以证明这一点！

为了强调GIF图形和可缩放图形在出版环境中的强烈差别，我们准备了一个模拟，通过创建包括两个类图实例的Adobe PDF文件，其中一张是输入的GIF图形，另一张是矢量图形。你可以下载这个PDF文档并在Adobe Acrobat中观看。尝试放大到很高的水平如800%或1600%，然后比较GIF图形和矢量图形的结果。这个实验并非不切实际：你可能需要准备一张被缩放到一个可读性提高的水平的演示图。

下载GIF和矢量图形对比的PDF例子文件.

为了展望UML和SVG的未来，我们也准备了一个使用SVG在浏览器中显示类图的演示。为了观看这个演示，你必须首先为你的浏览器下载一个SVG察看器。我们推荐来自优秀的Adobe SVG站点的插件。这样你就可以观看用SVG显示的图形模型演示。

XMI: 把所有东西捆绑在一起

Top

对UML开发团体来说，对象管理组织(OMG)的XMI标准是最近最令人振奋的进展。XMI是一种有潜力最终允许在领先的开发工具之间无缝共享模型的交换格式。例如，与其在UML建模工具中书写脚本来创建报表，不如让用户简单地在开发时使用XMI输出该模型，然后引入到一种特定的报表书写工具中。事实上，这个范例将平等地、很好地应用到前面讨论过的特性：O-O度量追踪和项目管理。此外，自从XMI使用XML来表示模型信息，一批XML解决方案很快会出笼，例如为基于浏览器表示提供的XSL格式表和为搜索兼容性提供的 XQL查询工具。

XMI标准是复杂的，在被广泛使用之前，它将需要时间来适应许多不可避免的兼容性问题(谁说标准经不起解释？)。但是，既然XMI是由IBM和Unisys等领先的工业巨头开发的，可以预期产品很快会出现。一直到用户团体不断要求厂商来驱动在UML工具中的XMI支持的需求。关于XMI的进一步信息，请看优秀的IBM网页。

作为XMI如何投入使用的例子，请看我们的项目， 转换XMI到HTML. 这个项目展示了XSL格式表如何能被用来产生UML模型的HTML翻译。

读者建议

如果您对在清单中未列出的UML建模工具新特性有什么想法， 我们将很乐意听到。

谢谢曾经把他们的UML工具评价标准Email给我们的读者。他们的原始建议在这儿。

2001-3-20
原文来自objectsbydesign.com）


养成良好的绘制 UML 序列图的习惯
序列图绘制技巧

Scott W. Ambler
总裁，Ronin International
2001 年 2 月 1 日

本文来自 http://www.ibm.com/developerworks/cn

请尝试本文所介绍的技巧来创建有效的 UML 序列图。本文改编自 The Object Primer 2nd Edition 的第 6 章。

有一些方法可以帮助您提高 UML 序列图的质量和效力。它们包括：

和主题问题专家一起验证决策

使解决方案尽量简单

为绘制消息和返回值选择一种一致而有效的风格

将序列图分层

遵循一致的逻辑风格

牢记序列图是动态的

验证决策
在开发图 1 序列图的过程中，我做了一些对其它模型可能有潜在影响的决策。例如，在对第 10 步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家 (SME) 进行验证。您应该和 SME（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。

保持简单
在对第 2 和第 3 步建模时，我忽然意识到学生可能应该使用口令进入系统。在向 SME 提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与 SME 一起检验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。

绘制消息和返回值
我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在序列图用于设计而不是分析目的时。（我希望我的分析图尽量简单，而设计图尽量全面。）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节，如图 1 中的注释提醒我对 "qualifications()" 消息执行的任务。

将序列图分层
我喜欢将序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类（在今后的建模技巧中将对此做更多介绍）。

遵循一致的逻辑风格
请注意，在图 1 序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑 -- 而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。

牢记序列图是动态的
您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。

动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制 UML 活动图”）以及 UML 协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久／数据模型一样，都是静态建模的主要产物。

因此实际上没有什么好争论的 -- 要想恰如其分地说明面向对象系统，同时需要动态和静态建模技术。

参考资料

The Object Primer 2nd Edition，由 Scott W. Ambler 著。New York: Cambridge University Press, 2001。

The Unified Process Inception Phase，由 Scott W. Ambler 和 Larry L. Constantine 合著。Gilroy, CA: R&D Books, 2000。

The Unified Modeling Language Reference Manual，由 James Rumbaugh、Grady Booch 和 Ivar Jacobson 合著。Reading, MA: Addison-Wesley Longman, Inc., 1999。


业务过程重建如何使用UML

丁峰、邓勇、沈钧毅

(摘自《中国计算机报》2001/1）

    电子商务的出现为企业的发展带来新的机遇和挑战，在新的环境下需要对企业的业务过程进行重建。业务过程重建是为了取得突破性改变而对业务过程进行根本性改变的研究与实现过程。它包括四个工程级：业务工程、系统体系结构工程、业务对象组件工程和应用工程。它们分别对应于系统开发中的四个主要活动：业务建模、系统建模、业务对象建模和实现。

    面向对象业务过程的体系结构

    业务过程重建不同于传统的对工作内容和形式的改进，后者是对已有的东西进行调整并始于此，而业务过程重建不是一个自底向上的连续变化过程。进行业务过程重建时，着眼于未来逆向进行工作，并不受已有方法、人员和组织结构的约束。这一工作往往开始于这样看似不切实际的问题：“如果新建一家公司或机构，我们将如何运作，结果会怎样？”

    业务过程重建是一系列工作的集合，一般大型机构进行业务过程重建时要作的努力包括以下工作：重新定义工作岗位、建立新的认知体系、人员培训、修改财务体系、处理生产、订货和供货方式等等。

    BOOSTER*PROCESS是用于面向对象业务系统开发和业务过程重建的参考模型。该模型给出的系统开发的基本原则是当今普遍使用的面向对象软件技术和UML设计者推荐的——用例驱动的原则、迭代和增量的方法，以及业务对象系统开发的多层方法。多层方法包括四个主要活动，即业务建模、系统建模、业务对象建模和实现，分别对应BOOSTER*PROCESS多级体系结构中的各级：业务工程、系统体系结构工程、业务对象组件工程和应用工程，如图所示。

    业务工程

    系统开发生命周期始于业务工程，包括对业务目标、规律、结构、资源、行为和工作流等建模，即进行业务建模。业务建模覆盖了业务需求和目标、业务组织、业务过程、领域方式等。业务工程的核心是对快速发展或已经发生变化的业务需求（包括业务目标、范围、策略等）进行建模以改造已有的业务过程，满足新的业务需求。业务建模可分为四个子活动：分析和需求建模、组织建模、业务过程建模和企业分布式建模。

    系统体系结构工程

    业务工程之后是系统体系结构工程。体系结构建模的目的是定义强壮、稳定的主框架，在其中可以开发、重用并操作应用和业务对象组件。系统体系结构建模涉及逻辑系统体系结构的设计及用户接口、服务和信息模型的设计。它一般包括系统体系结构建模、用户接口建模、服务建模和信息建模。

    业务对象组件工程

    业务对象组件工程活动过程中可能会伴随一些应用工程活动。但这二者不一定总是同时出现，有时也会根据需求用业务对象设施（BOF）单独产生组件。BOF的核心是创建能直接表达业务语义的业务对象作为高级结构，这些结构就是BOCA组件，BOCA组件的种类有业务对象、子系统、从属性和设备。它可以用来表达业务和业务系统需求，也可以表示业务对象互操作性主框架的基本功能。在这一阶段，应提交公共的或专用领域的或企业专用的组件，提交活动应是迭代的和增量的。为了使组件适宜于重用，应对其建立文档，增强可读性，使之易于被重用者所理解并使用；组件定义语言（Component Definition Language）是此建档的专用工具。此外，为了提高可重用性，该阶段产生的规格说明应与业务工程阶段产生的业务概念相匹配，包括对业务对象组件的外部设计。

    应用工程

    在应用工程阶段中，实现各个具体的业务应用，这也是整个业务过程重建的实现阶段。它通过支持业务过程直接服务于业务。该阶段的活动包括面向对象技术中的实现和测试等典型活动，并且往往也是迭代地执行。

    如何用UML为业务过程建模

    由于UML对系统的静态结构、动态行为和系统内部的交互关系都有较强的表达力，可以使用UML为业务过程重新建模。在不同的四个工程级，可以使用不同的UML图及其内置的扩展机制以及用于业务建模的UML标准旁集（UML Standard Profile）。

    在业务工程中使用UML图

    由于业务工程的主要目的是捕获业务需求和目标、业务组织、业务过程以及领域方式等，其核心是对业务需求建模，因此，可使用的UML图有用例图、活动图、类图以及合作图。

    用例图往往用来捕获业务需求。获得用例的通常方法是与有经验的用户交谈，从而了解他们希望系统具备的功能和提供的服务，用例的集合，即是对整个系统的需求。不要一开始就陷入细节问题，而影响形成系统的整体观念和综合看法。在用例图中，用例和执行者之间的连线表示二者间的某种关联，如“通信”、“使用”、“提供”、“变为”等。为了描述这些关联，可以使用类别模板，当UML预定义的四十多个类别模板不够时，可以对其进行扩展，自定义合适的类别模板来进行表达。用例之间也有关联如使用、依赖、扩展等。为了表达清楚并提高用例图的可读性和可重用性，应将已明确的关联用文字标注清楚。

    类图用于捕获信息和业务对象，在描述系统中的类及其相互关系时，它还反映系统中各种对象的类型以及对象间的静态关系，主要有关联、子类型。在这个层次使用类图，描述的应是应用域中的概念，这些概念与实现它们的类通常没有直接的映射关系，这时对接口的描述也应与实现区分开来。在描述关联时，可以为每个关联起个恰当的名字来表明其含义并对它进行标注。由于每个关联有两个角色，角色是由对象扮演的，为了明确对象在关联中的角色，也可以为角色命名。此外，还可以在需要附加说明的关联上添加注释。在描述类时，还应该对已明确的属性进行命名和定义，在业务工程级，对属性的描述不必过细，标明其所属类、名称、类型和存在的约束特征即可。

    由于用例图在描述事件的并行性和先后关系上难以提供足够的信息，还可以借用活动图。任何一个企业的业务需求都会涉及到在业务过程中应先执行什么、后执行什么，哪几件事件可以同时发生、并行执行，哪些事件的前提条件是什么等。活动图正好在描述工作流和并行过程方面具有强大的表现力。抽象级较高时，活动图只列出那些需要做的事情以及那些必须遵守的工作顺序。它的并行表达能力对企事业过程中业务活动的建模非常重要，可以方便地表示业务活动中常见的并行过程。这时不必过早地考虑用计算机实现时的细节。在模型中保留对并行行为的描述，对于在实现阶段充分发现那些可以并行的工作非常有利，以便大大提高业务过程中的办事效率。为了进一步描述用例，还可以使用活动图。

    在系统体系结构工程中使用UML图

    系统体系结构工程的核心活动是为系统的体系结构建模。该建模活动涉及逻辑系统结构的建模、用户接口建模以及工具的识别等，可使用的UML图有组件图、类图、配置图。

    在对业务进行建模时，UML的类图适合描述类的聚集、组成、接口。聚集是一种关联，反映部分与整体之间的关系。组成是一种由聚集演变而来的关联，表示一个部分对象只属于一个总体，且通常与总体共存亡。在表示聚集和组成时，可分别在连接两个类的关联旁添加注释作为辅助说明，并将已知的约束条件给出，有助于更好地描述系统的体系结构。为了描述接口，可以为接口起名或用文字描述它的逻辑功能。

    为了更清晰地描述系统体系结构中各部分的依赖关系，还可以借助于组件图和配置图的表达能力。组件图说明各种组件间的依赖关系，它可以反映某个组件的改变对其它构件的逻辑影响。借助组件图，可以描绘出在业务工程阶段和这个阶段分别得到的各部分之间的关系，如依赖、调用、返回等。在组件图中，可用不同线型的箭头表示不同的关系，或者为关系添加注释，作为对关系的辅助说明；在描述调用、返回等关系时，还可以把已明确的调用/返回条件添加为约束给出。配置图除了可以描述系统软硬件的配置情况外，还可以描述系统体系结构和逻辑配置。通过配置图，可以清晰地对软硬件关系和系统的分布性进行建模。

    在业务对象组件工程中使用UML图

    在业务对象组件工程阶段几乎可以使用所有的UML图。用例图可以表示业务对象组件在用例中的情况。用类图描述各类业务对象组件的构成、属性、操作、业务对象组件间的接口和关联。用状态图描述跨越多个用例的业务对象组件的行为，尤其是并发行为。在高抽象级，用活动图描述业务对象组件在业务过程中的执行顺序；在较低的抽象级，则对业务对象组件内部的活动进行建模。此外，为了更好地描述业务对象组件的内部结构和关系，还可使用组件图和配置图，它们可以描述组件之间以及组件与外部之间的关系。用顺序图可以着重体现消息传递的时间顺序和组件间的消息传递的时间顺序。顺序图与合作图往往配合使用。

    在应用工程中使用UML图

    由于UML适用于系统开发的不同阶段，从需求规格描述到系统完成后的测试，应用工程的主要目的是把前面各工程活动中建立的模型转化为可用的软件模型。几乎所有的UML图都可用于应用工程。在编程构造阶段，如何把分析和设计阶段提出的模型转化为实际代码，就是根据前面得到的UML图。在测试阶段，不同的测试以不同的UML图作为依据，如单元测试时使用类图和类规格说明，集成测试时使用组件图和合作图，系统测试时使用用例图。

    随着越来越多的企业面临着业务过程重建，在业务过程重建的过程中，可以把面向对象技术结合到其中。UML是面向对象的可视化建模语言，其强大丰富的表现力可以应用于对业务过程重建建模，但具体使用如何，还需要具体情况具体对待。


用UML进行有效业务建模(编译)

－－描述业务用例及其实现

本文来自CSDN

大多数软件开发实践者都知道，UML在对真实世界的现象进行建模时非常优秀。这一特性可以有效帮助分析员和客户进行沟通。

一些希望使用业务建模的团队常常有一些经验性的问题，例如：

１、什么时候真正需要业务模型？什么时候用例模型独立存在？

２、我在进行精确的业务建模时我能用哪些UML图形？我如何知道是否用顺序图或者交互图。有例子吗？

３、业务模型如何涉及到其他模型（如领域模型，用例模型等等）呢？我如何有机地组织这些模型？

很不幸，本文的焦点集中于应用UML进行业务建模的问题，而很少把业务建模和系统建模进行比较。这将使用户和分析员对使用UML进行业务建模的感到灰心。

本文主要通过一个例子讲述它们的关系。这个例子主要用来改进某企业的流程，主要涉及到IT部门、法律顾问、企业架构师、项目经理。

1. 业务用例模型概览

在这个简单的例子中的第一步是完成业务用例模型概览。如图所示，有两个业务主角和两个业务用例。

我们总结业务用例如下：

Prepare Tender: 准备系统说明书的流程。

Select Vendor: 选择卖方的流程。

我们总结业务主角如下：

End User Manager: 公司内的需要自动控制系统的部门。

Vendor Manager: 卖方的管理者。

在这个例子中，得到一个新系统的核心业务目标被精化为两个子目标：

· 详细说明想得到的系统。

· 选择并评估候选人。

1. 业务用例规约

在这一部分，我们来看看如何描述业务用例，虽然RUP中对业务用例规约有很详细的模版，但我们主要把精力放在基本流和扩展流上。

Prepare Tender的基本流：

用例的目标是确定招标文件，同时可以将招标文件发布给候选卖主。

１、 指定用户代表。

２、 用户代表准备系统规约。

３、 IT部门复审系统规约，并改进它，形成招标文件。

４、 用户代表批准招标文件。

扩展流：

１、 系统规约无效。当IT部门发现需求太含糊，最终用户的管理者必须重新制作需求。那么这个用例从第二步从新开始，如果最终用户管理者不想继续，也可以终止。

２、 系统已存在。如果IT部门发现这个需要的系统和其它部门存在的系统很类似，IT部门就提交给最终用户管理者。如果最终用户管理者希望继续寻找新系统，他必须写出该系统的特色，并重新提交该说明书，回到第二步，如果最终用户管理者不想继续，也可以终止。

３、 招标文件和需求规约冲突。在第四步，最终用户管理者发现招标文件有问题，它将被拒绝，IT部门必须重新做它，用例在第三步继续。

2. 业务用例实现

在这部分，我们从几个方面去实现业务用例。

n 以工作流为中心

n 以流程自动化为中心

n 以信息处理为中心

焦点集中在工作流

我们要精力集中在业务角色的职责上，如图所示，Prepare Tender 有三个业务角色：

下面的顺序图描述了Prepare Tender的基本流。

上图中的消息可以映射到每个业务角色的职责（如下图所示）。这个技术非常类似于用例分析。由此可见RUP业务建模的技术是很强大的：相同的技术可用于业务建模和系统建模。

焦点集中在流程自动化

现在我们准备去探索业务主角和业务角色职责，明确什么时候使用业务系统以及如何使用业务系统。在我们的例子中，我们有两个业务系统，如下图所示。

TMS是准备招标和选择卖主的系统。这是一个新系统。

CMS是跟踪合同的系统，已存在。

在RUP中，业务对象建模的指导方针建议可以对“业务系统”定义一个新的泛型图标，在这篇文章中我们将使用“业务角色”图标来表示“业务系统”。将有一个新的图标在新的UML业务建模规范中。

下面的顺序图描述了Prepare Tender基本流的实现，包含了需求的业务系统。

上图中的消息可以映射到业务角色的职责。如下图所示：

从上图中可以得到系统用例，如下图：

焦点集中在信息处理

现在让我们看看业务用例在信息处理上的实现，这就是说，有多少业务实体。经过分析，我们将得到四个业务实体，如下图：

下图是实现Prepare Tender的交互图（侧重于信息处理）。

上面两张图的消息可以映射到每上业务实体的职责，如下图：

下图是上图的一个简化。

4 结论

软件系统开发出来是为了达到业务目标，可是，用户，分析员，和开发人员常常生活在不同的世界；他们有不同的看法和用不同的行话。小组间的通讯障碍导致在解释各种系统需求时发生很多激烈的争论。具有代表性的一点是，他们的改变不是因为用户改变了想法，而是因为最初的需求需要净化。

原文地址：

http://www.therationaledge.com/content/nov_02/t_businessModelingUML_pn.jsp


用UML模型实现大型实时监控应用软件

作者：姬孟洛 彭利文（北京跟踪与通信技术研究所·100094） 出处不详

1、概述

实时监控应用软件（CTS）开发过去采用的是结构化方法，采用的编程语言也是汇编语言、FortranAda等结构化编程语言。也曾有过分析和设计阶段采用结构化方法，编程实现采用面向对象语言的尝试。

采用面向对象方法（UML）完整的实现监控实时应用软件是首次尝试，收到了较好的成效。

UML（统一建模语言）是美国Rational公司创造的面向对象开发中一种通用的、统一的图形化模型语言。

它于1997年11月被美国OMG小组批准成为面向对象开发的行业标准语言。UML标准的树立统一了面向对象的建模方法，消除了对象建模差别。Rational公司的旗舰产品之一Rational Rose提供了对这一行业标准语言的充分支持。

Rose是一个面向对象的软件分析设计建模工具，可以创建基于UML标准的模型，图形化地对软件系统结构加以描述和定义，并且通过建立的模型直接生成代码框架。

同时，还可以从开发者编的应用系统中直接逆向生成模型。下面将就实时监控应用软件的分析设计是如何使用Rational Rose来实现的作一简要介绍：

2、UML模型 CTS是监控系统的中心，它主要用来控制测量设备实时跟踪和测量飞行目标，实时处理测量结果，并兼有显示、打印、记录等功能。它和测量设备的关系如图1所示。 wpe7.jpg (14509 bytes)

实时应用软件通过数据包和测量设备交换信息。软件实时性要求较高，在每个采样周期内，必须完成该周期的数据处理工作，也要有一定的人工干预能力。 实时应用软件模型用来描述软件各层次的各个方面，它包括Use Case图、类图、序列图、状态图、分布图和组件图。

2.1 Use Case图Use Case 也称为用例、使用情况，它是系统分析人员从用户使用的观点来看系统功能、功能之间的关系以及用户与功能之间的关系。它是系统功能以及用户与功能之间的关联，利用 Use Case系统分析人员对系统的功能和行为加以描述。CTS的Use Case图如图2所示。 wpe7.jpg (14509 bytes) CCP为前端通信处理机，Operator为操作员，Interrupt为操作台命令产生的中断。Simulation 模拟状态，用于软件调试和操作员训练。 Task：实战状态，用于实战任务。 Abnomity ：异常处理，应急状态。 SimpleServer：打印、记盘等服务。CommuniciateProcess：从CCP接收测量设备传来的数据包之后解包，然后按要求将多帧数据重新组织成一帧转发到CCPDataProcess：将CommuniciateProcess接收的数据依据处理要求进行挑点处理，利用 CommuniciateProcess解包后的数据计算轨道、平滑外推和预报等。DisplayProcess：将挑点后的数据按指定的要求在不同的显示服务器上以文字、数字或图象形式显示。将 DataProcess的处理结果在指定的显示服务器显示。所有Use Case的工作都必须在指定的时间周期内完成。2.2 类图

类图是系统的逻辑结构，是模型的核心部分。它描述了系统中的类及类之间的关系，类图描述系统的静态结构。类包是子系统中相关类的集合，包类似于 Peter/Coord 方法中的主题词（ subject ）。图 3 描述了 CTS 的类包。

wpe8.jpg (14024 bytes)

类包 DisplayProcess 、 DataProcess 、 CAbnormity 和 CommunicateProcess 是我们自己开发的，是系统的核心，其余的类包是由 Microsoft 提供的。 DisplayProcess 类包包含了显示所需要的所有和 MFC 有关的类， DisplayProcess 类包中的类都是从 MFC 派生的，一般都增加了 CTS 系统所需要的特性。 DisplayProcess 类包中的类及类之间的关系如图 4 所示。

wpe9.jpg (14907 bytes)

  图4 DisplayProcess 类包中的类及类之间的关系

CommunicateProcess 类包包含了通信处理所需要的类及类之间的关系，如图 5 所示。图中 CFrameFormat 类为数据帧格式类是所有帧格式类的父类，它有两个子类： CRecvFrameFormat 和 CSendFrameFormat 。 CRecvFrame- Format 类（从 CCP 接收的帧格式）是 CRecvHead 类（接收帧头）和 CDevice- Format 类（设备数据格式）的聚集。 CSendFrameFormat 类（向 CCP 发送的帧格式）的数据区包括 Device1 ～ Device3 帧格式中的内容。 CReceive 类为接收类， CSendTo 类为向 CCP 发送数据类。

wpeA.jpg (17083 bytes)

图5 CommunicateProcess类包中的类及类之间的关系

DataProcess 类包是 CTS 类包中的核心部分包括了数据处理所需的所有类，这个类包较复杂这里只给出部分类图，如图 6 所示。 CGdFeature 类是数据处理部分的类它有两个最主要的操作：轨道积分和坐标转换， CTheoryGd （理论轨道）， CPracticeGd （实际轨道）， CCoordinatePoint （轨道坐标）， CRate （目标速度）。

wpeB.jpg (15115 bytes)

6 DataProcess类包中的部分类及其关系，CAbnormity类包包含异常处理以及操作台应急处理所需要的类，类图略。

2.3 序列图

CTS 的动态特性用序列图表示，序列图用来描述一个软件的运作顺序（场景），一个 Use Case 包含多个软件的运作场景。序列图用来刻画 Use Case 图，一个 Use Case 可以有多个序列图，每个场景用一个序列图刻画。合作图与序列图等价，可以由序列图转化得到，两者各有优缺点。序列图对于实时系统的时间要求刻画的很好，但结构不明显；合作图的对象间关系明显但它用消息顺序号表示时间，时间表示不清楚，不太适用于实时系统。 CommuniciateProcess 的序列图如图 7 所示。

wpeC.jpg (15689 bytes)

图 7 CommuniciateProcess 的序列图

2.4 状态图

CTS 的动态结构主要用来描述活类的动态特性，使用 Rational Rose 的状态图 StateDiagram 来描述。行为导致了状态的迁移，状态图用来显示一个给定类、给定事件的状态。每个状态图都与一个类或一个 Use Case 相关联。状态图刻画软件系统的行为视点，它基于有穷状态自动机的图示机制。一个状态图包括一个类在生命周期内的状态转换和描述。限于篇幅只给出 CTS 的 CGdFeature 类的状态图，如图 8 所示。

图8 CGdFeature类状态图

2.5 组件图

逻辑模型表示了系统的逻辑结构，每个逻辑模型都应有一个或多个到物理实现－组件图的映射。组件图显示了物理上组件（主程序、包和任务）之间的依赖关系以及和逻辑模型之间的映射关系。组件的设计和系统的运行环境以及逻辑模型的结构有关。如果是分阶段开发的话，组件设计应属于详细设计。

2.6 软件分布图

软件系统需要和硬件环境一起工作，软件分布图也表示了硬件设备和它们的界面，以及硬、软件的协同工作。 CTS 的软件分布图表示了执行程序、计算机节点以及设备的布局。 CTS 的分布图如图 9 所示。图中 Main 和 Backup 分别表示主用和备用计算机，只有主用计算机向 CCP 输出，但主备机均接收 CCP 来的数据。

图 9 CTS 软件分布图

3 实现

在系统的逻辑设计（模型）和组件设计（模型）完成之后，便可以进入编程。 CTS 的编程实现采用 Microsoft 的 VC++ 语言， Rational Rose C++ 对 VC++ 有专门的支持。编程实现主要是利用 Rose 的生成和反向生成工具根据系统的设计模型来完成的。它包括三大步骤，每个步骤又包括多个过程。

3.1 系统设置

系统设置主要用来设置 Rose 的特性和目录，它包括四步，这里就不详述了。

3.2 开始一个新的VC++项目

在开始 VC++ 编程时，首先创建 VC++ 应用程序，此时应遵循以下步骤：

使用VC++ 的Application Wizards 为应用生成框架

· 创建Rose 分析器Analyzer 下的项目，加入VC++ 创建的文件

· 定位头文件，关闭不含类也不能由分析器生成和反向重新生成的文件的Regenerate 属性，并向Rose 输出初始模型。

在 Rose 下打开 .red 文件

· 反向生成的模型不带特性，选rosevcpp.pty 文件作为新的特性文件，最后把模型保存为 .mdl 文件。

3.3 增加类、数据成员和成员函数

把 Rose 模型中的类增加到 VC++ 应用程序中可分为两种情况：一种是不使用 VC++ 的 Class Wizard 支持机制的类（如信息映射），一种是使用此机制的类。

前一种情况比较简单，它正是在 Rose 中生成代码，然后把这些文件加入 VC++ 项目中即可。对于后一种情况，其步骤大致如下：

在 VC++ 中创建新类，然后将新类的文件加入 Rose 的 Analyzer 对应 的项目中。

· 在分析器Analyzer 中进行特性设置以反映项目当前的变化。

· 在分析器Analyzer 中输出文件。 向已经存在的文件中添加数据成员和成员函数的方法与添加类的方法相同。

· 4、结束语 从应用的结果看，总的来说，使用 UML 进行监控实时应用软件开发取得了比较好的效果，与以前使用的结构法方法相比有明显的优势。我们体会，这主要表现在以下几个方面：

· 1.Use Case 是系统分析人员从用户的视角出发、从功能边界描述目标软件系统，这从模型上规范了对需求的描述，也能够和后面的设计较好地衔接，比以前纯粹的文字描述要好一些。用

· 2. 逻辑设计代替功能模块设计和实体－关系设计，解决了以前的功能和数据分离的问题，以及模块中数据的组织问题。

· 3. 用状态图在较高的层次上描述了系统的动态结构。

· 4. 由于同时使用了文档生成工具，使得系统设计和文档、程序代码保持一致，较好的解决了极易造成的文档和实现不一致的现象。这一点非常重要。


用Use Cases捕获需求

Pete McBreen，译：UMLChina.苏康胜（cancan28@163.net）

概述

开发者们经常通过一些典型的情节去理解系统并知晓系统如何工作，不幸的是他们虽然努力地去做了这些工作却很少以一种有效的方式去说明，Use Cases正是一种形式化捕获这些情节的技术。

仅管Use Cases在一本对象方面的书《Object Oriented Software Engineering》中有过定义，是跟那些对象结合在一起的，但这项技术实际上是独立于面向对象的，Use Cases是既能捕获商业处理流程又能捕获系统需求的有效方法，并且它本身比较简单和容易掌握。

使需求有利于回顾

以正规形式捕获这些情节的原因是有利于用户和开发者进行回顾，这里有2点关于一些实用需求符号的明确标准要遵循：

1） 它必须让情节的发起者和回顾者都很容易理解

2） 它不需包括一些关于系统样式和内容的决策

实用的需求是评估设计和最终实现系统的客观需求。

对于这些需求来说，必须要做的是以一种可实现的并不受约束的方式去捕获风险承担者的需要和期望。

Use Cases使需求有利于回顾

Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：

1 Use Cases把系统当作一个黑盒

2 Use Case 使在需求中看到实现的决定变得更加容易

最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了“提交改变到定单数据库”、“显示结果到Web页面”等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。

为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。

Use Cases的工业接受

Use Cases第一次被正式的描述是在6年前（1992年），从那以后它就被最主要的面向对象的方法采用，同时作为描述现在和将来的操作模式的有用技术被商业再生工程团体（Business Process ReEngineering Community）采用。

Use Cases最近它们自己取得在UML（Unified Modeling Language）中有效的地位和位置而得到了突出的进步。UML已经被OMG（对象管理组织）计划做为对象系统的标准语言。

什么是Use Cases？

Use Cases本身是用户或其它系统与正在设计的系统的一个交互，是为了达到一个目标。术语Actor（行为者）是用来描述有这个目标的人或系统，这个术语是用来强调有这个目标的任何人或系统。目标的本身是用行为动词开始的短语表达的，如：“Customer : place order”、“Clerk : reorder stock”等。

情节的角色

在Use Cases中不同的情节显示了目标怎样成功或失败，成功的情节是目标达到了，失败的情节是目标没有达到。这个的好处是因为目标总结了系统的各种使用的意图，用户能看到被设想怎样地使用这个系统，并且不必等到出现第一个原型或是比较糟糕的等到系统被开发出来才发现什么时候系统并不全面地支持他们的目标。

Use Cases将做成多大？

试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的情节不容许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。

对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。

Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。

给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。

看看System Use Case的例子，“从数据库中查询低库存的”它太小了，容易跟需求的实现细节混淆。对比一下，作为System Use Case，“仓库管理”就太大了，它不能实现作为没有大的分支的行为的单一线索的原则，并且从系统的观点来说，它很难说明成功的目标，但它可以做为一个好的Business Use Case，对于配件部门来说，它可以定义“仓库管理”这一成功的目标（可能是根据库存调整、配件验收、成本操作等）。

这些Business Use Case的好处是它们能用于区分其它的Use Cases，就如：“仓库管理”可用于组织这些用于实际管理仓库的Use Cases。

Use Cases的正式定义

Use Case：特殊行为者（Actor）的价值的量化结果的提交

正如前面所说的，Actors可以是人也可以是正在设计的系统与之交互的外部系统，一个Use Case要求有一个量化的结果，从单个线索的需要提交。做为量化结果的组成，目标要么成功要么失败，没有其它的情况。

达到主要Actor的目标定义为成功，结果没有迎合主要Actor的目标定义为失败，不同的情节显示了成功或失败的途径。

Use Cases的说明

Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。

不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。

下面是客户对Use Case“下定单”的粗略概略：

“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”

  结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对的顺序。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：

Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。

处理目标失败-----延伸部分

下面要做的是确定以上的每一步中可能会发生的失败，对于这种情况那些可能造成失败的条件做为延伸部分来捕获。这些扩展是通过在失败条件下直到可以重新入轨或失败的情节来处理的。

失败条件的分离使情节变得可读了，一般情况都是以最简单的途径通过Use Cases的，它的每一步，行为者（Actor）的目标都是成功的。分开列出所有可能造成失败的条件给予了更好的品质保证。回顾者可以很容易的检查是否所有造成失败的条件都被指定及哪些潜在的条件被忽略。失败的情节要么可以恢复要么不可以恢复，可恢复的情节最终取得成功，不可恢复的情节直接失败。

失败中的失败

当失败情节下还有其它失败发生，需特别的标示出来，也就是说，在延伸部分中用更长的前缀标记更深一层的失败情节，如：1a1b、客户是个不讲信用的，它的恢复通过1a1b1。

为什么使用结构化叙述格式

结构化叙述的价值在于它是可驳倒的描述，所谓可驳倒的描述是它足够明确，以至可以给人去争辩和提出异议。

“流程不是那样的”

“为什么开单之前不检查是否有用呢？”

“你少了好几步哦”

对比之下，那种用非正规叙述形式描述的粗略概略是很难去驳倒的，但它有利于早期对问题域的理解。

可驳倒的描述方式的价值的另一种描绘是，当你说明Use Cases时期望从用户和开发者处获得关于Use Cases品质的反馈。自想在开发过程的中及早的得到修正，它是非常有价值的。用户典型的反馈是不同顺序的问题，可能是平行的或是缺少的步骤。开发者典型的反馈是关系到特殊失败条件的意思和如何检测到它是否清晰的要求。

Use Cases的图形符号

这里是Use Cases的图形符号描述，UML中一个单一的“Stick-Man”符号标示行为者（Actor），用椭圆标示Use Cases，如图一所示。这些图对于你想看到Use Cases之间如何关联的“大图”和获得系统上下文的大体描述来说是非常重要的。

Use Cases图没有显示不同的情节，它们的意图是显示行为者和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的情节，这些常规的图形有交互图、活动图、顺序图、状态图等。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。对于这些图的协定的参考请见《UML Distilled》，作者Martin Fowler。

需求重用取得

按行为者：目标（Actor：Goal）的格式来描述Use Case的作用是它容许公共的功能性分解出来做为独立的Use Case。当执行公共部分的时候是指用于主要Use Case的。比如：Use Case下定单中的“确定客户”这一步骤可以用于其他Use Cases。

Use Cases之间的另一关系是“延伸部分”，如果Use Case有一个失败恢复的步骤是复杂的，通常有三、四步，说是一个Use Case去扩展另一个Use Case。比如：当没有可用库存时，“Issue Raincheck”可能扩展Use Case“下定单”。

Use Cases应用当中的复杂性和危险

主要行为者（Actor）和Use Case之间没有连结

一些情况下，从Use Case中取值的行为者（Actor）和积极参与这个Use Case的行为者（Actor）之间没有清晰的连结。如：财务主管能成为“发票确认”的行为者（Actor），但他未必是创建发票的人。这不是什么问题，这个Use Case仍然是正确的，它正说明行为者取值和设计的系统的范围外的Use Case发生的初始化之间的关系。主要行为者是有用的，因为这个人扮演的角色是当你说明Use Case时需要跟他说的人。

情节步骤不需要连续

情节中步骤顺序的情况是没问题的，这里有一些机制去突出可能的并行步骤。在UML中活动图是首选的机制，通过非正式地看Use Case的情节你可以注意到可能的平行步骤；可以看Use Case内一些邻近的步骤；也可以有相同的行为者（Actor）对步骤负责。之前我们举过的例子里，确认数量和确认信用额可能是平行的。有时候在Use Case的说明文档中标记这些可能的平行步骤是有用的。

Use Cases的大小

当开始做Use Cases的时候有个很显然的危险就是它要么有很多步骤要么就很少步骤。如果在Use Case中有超过15个步骤，它可能包含一些实现明细。如果它只有非常少的步骤则检查它的目标是否是达到一个没有很多分支的活动的单一线索。

较少的人类行为者（Actor）

如果Use Case有较少的人类行为者，而大多数行为者是其它系统，通常的做法是修改这个Use Case。寻找系统必须做出反映或公认的事件胜过会见这些行为者。

需求捕获和系统复杂性

总而言之，这些情节捕获到系统复杂度的同时行为者：目标语句对容许大的系统以相对压缩的格式说明。Use Case的格式的作用是用户和开发者能标志出行为者，然后确认这些行为者工作职责对应（或不对应）的目标，代替一个大的很难读的功能规格说明书。

仅仅这样，用户和开发者就有足够的兴趣进而研究那些情节的细节。

系统不仅仅有应得的功能性需求

一些Use Cases并没有捕获所有的客观需求，仅仅是捕获了系统怎么用的那些功能性需求。然而还有许多方面的需求需要去捕获的。其中有的非功能性需求使用关联以至于也能隶属于个别的Use Case，如性能需求和系统容量的需求。另外的一些不是关联的而是要单独地去捕获，它们是以下的需求：

l 系统范围

l 系统用户的目标

l 用户界面原型

l 一般规则

l 约束

l 算法

运行时期和建立时期的需求比较

一个重要的因数要记住，就是系统的赞助者是大过用户团体的。系统中有许多的风险承担者，Use Cases仅仅捕获其中一些风险承担者的需要，具体说，Use Cases仅仅捕获系统运行时期的需求而忽略做为系统开发组织的风险承担者的需求，开发组织最有兴趣的是对建立时期需求的描述。

运行时期需求包括：系统范围、用户组织对产品的期望和目标、Use Cases、其它非功能性需求。

建立时期需求包括：减少开发成本、较少的变更处理、现存组件的重用。

建立时期的需求可以部分的由Use Cases把握。但许多方面是需要由开发组织的处理的。

l 项目范围和目标：项目必须提交什么。（和系统范围的区别是它提交的是所有项目的东西）

l 增长性和变更请求：这些可以在捕获为常规Use Cases格式中的“Change Cases”

l 开发负责人的约束：包括标准、习惯、工具、品质度量标准、品质保证原则、及品质保证的习惯。

Use Cases的适用性

Use Cases首先用于需要响应客观事件的系统。它们能用于提供了一个有很容易理解的目标的清楚的行为者的环境。当结果不可定义或不清晰时不能用Use Cases。意思是如果目标成功或目标失败不能有一个明确的定义，那么Use Cases不能用来捕获需求。

然而说到这，现在大部分对象方法都使用Use Cases。因为Use Cases被证明是捕获需求的非常有效的机制。

总结

Use Cases以一种可读的、可驳倒的格式捕获需求。Use Cases是系统客观必需机能的可驳倒的描述。

可驳倒的意思是当你说明Use Cases时期望从用户和开发者处获得关于Use Cases品质的反馈。

Use Cases并没有从一开始就就明确的定义，它主要的开发顺序如下：

1、 指出行为者（Actor）

2、 指出行为者的目标

3、 指出每一行为者：目标语句对的成功或失败的意思

4、 指出每一Use Case的主要的成功的情节

5、 在细化阶段，指出失败的条件及可恢复/不可恢复的情节

只有做到了第四步才能决定哪一些的东西在Use Case中逐步开发出来。

总而言之，Use Cases是非常有效的需求捕获技术，它能使需求变得容易回顾，并且避免在需求中有实现细节的偏好出现。

对照表：

英文 | 中文
Scenario | 情节
Internal structure | 内部结构
Measurable | 量化
Thread | 线索


用可行性研究论证您的项目

Scott W. Ambler
总裁，Ronin International
2000 年8 月24 日
本文来自 http://www.ibm.com/developerworks/cn

在任何项目的开始阶段，项目组都要为项目的总体工作做一些准备工作。在 Rational Unified Process（RUP）和面向对象的软件过程（OOSP）中，这个阶段称为启动阶段。本周，我们考虑如何确定一个项目是否值得启动。本文由《Process Patterns》的第五章改编而来。

启动项目的一个重要环节就是对项目进行论证；也就是说，确定是否应该立项。遗憾的是，论证经常是完成得最差的一项任务。85% 以上的大型项目以失败告终（请参阅参考资源中的《Patterns of Software Systems Failure and Success》一书），这一事实表明大多数项目在论证阶段就应该中止，而不是在为其作了大量投资（并造成损失）之后。论证阶段的主要目标是，确定项目的最佳实施方案，如果存在这样的方案，还要论证它为什么是最佳的。

图1描绘了针对论证阶段的过程模型的解决方案。论证项目时需要完成几项工作，论证项目的主要结果便是可行性研究。为了进行可行性研究，您将重复下列步骤：

· 确定可选的实施方案

· 评估每项可选方案的经济可行性

· 评估每项可选方案的技术可行性

· 评估每项可选方案的运行可行性

· 选择一项可选方案

· 确定潜在的风险

图 1. 论证阶段的过程模型

确定可选的实施方案

可行性研究的第一阶段是确定项目潜在的可选实施方案。与流行的观点正好相反，实现应用时总有多种选择，包括什么都不做、使用多种技术实现它、购买一种类似的系统或者将开发工作外包。重要的是，为您的项目确定几个可行的可选实施方案，以便您进行评估和比较，从而最终为自己的公司选择最佳的实施方案。

评估经济可行性
在评估一项可选实施方案的经济可行性时，要回答的基本问题是，“该应用何时能收回成本？”您可以通过进行成本/收益分析来回答这个问题。顾名思义，成本/收益分析就是将应用的全部实际成本与其全部实际财务收益相比较。在《The Squandered Computer》一书中（请参阅参考资源），Strassmann 指出，应该根据可选方案对净现金流量 — 即收益超过成本的总金额 — 的贡献来评价各个方案，因为所有投资的首要目标就是提高公司的整体业绩。

评估技术可行性
除了经济可行性之外，您还必须确定每项可选实施方案的技术可行性。此时需要回答的基本问题是，“是否能够创建该应用？”首先，您必须调研该项目要使用的各项技术。技术方面的问题在于，每项技术在行销演示中都能完美地完成工作，而一旦将它购买回来，往往又是另一种情况。因此，您应该鉴定每一种可供选择的技术。请注意，为了进行合理的评估，您可能需要实现一个微型项目，并且创建一个概念验证 (proof-of-concept) 原型来检验这些技术是否能协同工作。这是 RUP 的描述阶段的基本任务，它可能持续几周或者几个月，但是只有在检验出您选择的技术能否协同工作时才会体现出它的价值。

评估运行可行性
一个应用不应该在经济和技术上行得通，它还必须在运行上行得通。此时要回答的问题的，“应用一旦成为产品，是否能够对该应用提供维护和支持？”创建一个应用与运行一个应用完全是两码事；因此，您必须确定是否能够有效地运行和支持它。

选择一项可选方案
一旦完成对每项可选实施方案的经济、技术和运行可行性评估，就应该从中选择一种实施方案。请记住 — 可行性研究的目标是，比较和对比各项可选实施方案，并提出一个最佳的实施方案。执行该项任务的第一步是，排除任何在经济上、技术上或者运行上不可行的方案。这意味着您可能没有剩下任何可选方案。但是什么都不做可能也是不可行的，它意味着您必须从头再来，鉴定更多的可选方案。如果只剩下一个可选方案，则很容易做出决策；如果最后剩下多个可选方案，则必须选择一个最适合您的公司的实施方案。您还可以只确定可行的可选方案，而将决策权留给上级主管部门。

确定潜在的风险
项目论证工作包括定义潜在的风险，特别是那些与项目的技术和运行可行性相关的潜在风险。关键的一点是应该将它们加入您的风险评估文档，以便在项目实施过程中能够妥善处理它们，这也是今后的技巧要讨论的主题。

参考资源
关于过程模型和 Rational Unified Process 的详细信息，请参阅：

· 《Process Patterns — Building Large-Scale Systems Using Object Technology》，Scott W. Ambler 著。Cambridge University 出版社，纽约，1998 年。

· 《More Process Patterns — Delivering Large-Scale Systems Using Object Technology》，Scott W. Ambler 著。Cambridge University 出版社，纽约，1999 年。

· 《The Object Primer 2nd Edition》，Scott W. Ambler 著。Cambridge University 出版社，纽约，2000 年。

· 《The Unified Process Inception Phase》，Scott W. Ambler 和 Larry L. Constantine 著。R&D Books，CA，Gilroy，2000 年。

· 《The Unified Process Elaboration Phase》，Scott W. Ambler 和 Larry L. Constantine 著。R&D Books，CA，Gilroy，2000 年。

· 《Patterns of Software Systems Failure and Success》，Capers Jones 著。International Thomson Computer 出版社，MA，Boston，1996 年。

· 《The Rational Unified Process: An Introduction》，第二版，Philippe Kruchten 著。Reading, MA: Addison-Wesley Longman, Inc.，MA，Reading，2000 年。

· 《The Squandered Computer: Evaluating the Business Alignment of Information Technologies》，Paul Strassmann 著。New Canaan，CT：Information Economics 出版社，CT，New Canaan，1997 年。

· 《The Process Patterns Resource Page》，Scott Ambler 著

· Scott Ambler 的在线文章


用例建模技巧 适合于更好的 UML 用例模型的技术

Scott W. Ambler
总裁，Ronin International
2001 年 1 月 4 日
本文来自 http://www.ibm.com/developerworks/cn

本文介绍了一些提高系统用例模型质量的技巧和技术。本文改编自 The Object Primer 2nd Edition 的第 6 章。

从参与者的角度并以主动语态编写用例。
应该以主动语态：“学生表明参加研习班意向”，而不是被动语态“研习班意向被学生表明”来编写用例。而且，应该从参与者的角度来编写用例。毕竟，用例的目的是理解用户如何对系统进行操作。

编写方案文本，而非功能需求。
用例描述的是对参与者来说有价值的一系列行动，而不是特性集。例如，“招收研习班的学生”用例描述的是学生如何与系统交互来参加研习班。它没有描述用户界面看上去是什么样子，或者它是如何工作的。有一些其它的模型来描述这些重要的信息，例如用户界面模型和增补规范。面向对象分析非常复杂，因此需要对它使用几种模型，并且应该适当地应用每一种模型。

用例只记载行为需求。
用例既不是类规范，也不是数据规范。这是应该由概念性模型捕捉的一种信息，在对象世界中，它是通过 UML 类模型建模的。您往往会引用概念性模型中描述的类，例如，“参加研习班”用例包括了“研习班”和“学生”等概念，它们都将由概念性模型描述。

不要忘记用户界面。
系统用例经常引用主用户界面 (UI) 元素，这些元素常常称为“边界”或“用户界面”项，例如 HTML 页面和报表。用例有时也引用一些次要的 UI 元素，例如按钮或数据输入字段，但这种级别的细节并不太常见。

创建用例模板。
用例包含了相当数量的信息，这些信息可以轻易地以常见格式记载。您应该考虑开发自己的模板（请参阅技巧“记载用例”）。

始终如一地组织用例图。
一般的做法是垂直地绘制继承 (inheritance) 和扩展 (extend) 关联，在父／基本用例下面绘制继承／扩展用例。同样，通常水平绘制包含 (include) 关联。请注意，这些是简单的经验法则 -- 只要始终遵循这些法则，产生的图将很容易理解。

不要忘记系统对参与者行动的响应。
用例既应该描述参与者是如何与系统交互的，也应该描述系统如何响应这些交互。例如，在“参加研习班”用例中，如果系统在学生表明他们希望参加研习班时没有做出响应，学生就会很沮丧地离开。

备选行动过程非常重要。
如果一切顺利，使用的将是基本行动过程 -- 但也不要忘记备选过程。引入备选过程是为了描述潜在的使用错误以及商业逻辑错误和异常。这些重要的信息对于驱动系统的设计来说很有必要，因此不要忘记在用例中对它们建模。

不要被 <<include>> 和 <<extend>> 关联所困扰。
我不是很确定到底发生了什么事，但我总是在想包含 (include) 和扩展 (extend) 关联，以及旧版本 UML 中使用 (uses) 和扩展 (extends) 关联的正确使用从来没有得到很好的描述。结果，用例建模小组往往在这些关联的正确应用上争论不休，在整个建模技术中一些有趣但次要的部分上浪费了惊人的时间。我曾在一个组织中工作，这家组织居然取缔了 <<include>> 和 <<extend>> 原型的使用，几个星期后，当意识到公司仍然需要这些概念时不得不撤消了这种极端的解决方案，而这时该组织对它们的正确使用还没有达成共识。

让用例带动用户文档。
用户文档的目的是描述如何使用系统。每个用例都描述了参与者通过使用系统所采取的一系列动作。简而言之，用例包含从中开始编写问党用户稳当的信息。例如，可以使用“参加研习班”用例作为基础来编写系统用户文档的“如何参加研习班”一节。

让用例带动演示。
软件开发过程中的一部分是向项目资金管理者通报工作成果，因此有时需要提供演示。因为用例是从用户的角度编写的，它们包含了演示中对资金管理者可能希望听到的事物的有价值的深刻见解。换句话说，用例通常包含制定演示稿所需的逻辑。

参考资料

<The Object Primer 2nd Edition，由 Scott W. Ambler 著。New York: Cambridge University Press, 2001。

The Unified Process Inception Phase，由 Scott W. Ambler 和 Larry L. Constantine 合著。Gilroy, CA: R&D Books, 2000。

Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design，由 Larry L. Constantine and Lucy A.D. Lockwood 合著。

The Unified Modeling Language Reference Manual，由 James Rumbaugh、Grady Booch 和 Ivar Jacobson 合著。Reading, MA: Addison-Wesley Longman, Inc., 1999。


怎样成为优秀的软件模型设计者

我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？

将下列原则应用到你的软件工程中，你会获得立杆见影的成果。

1. 人远比技术重要

你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。

2. 理解你要实现的东西

好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。

3. 谦虚是必须的品格

你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。

4. 需求就是需求

如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。

5. 需求其实很少改变，改变的是你对需求的理解

Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。

如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。

你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。

你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。

如果你觉得公司不让你与用户充分接触，那只能说明公司的管理层并不是真正支持你的项目。

你可以抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么做的。

你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念，但是为什么你没先想到呢？

需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。

6. 经常阅读

在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。

每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。

7. 降低软件模块间的耦合度

高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。

耦合度低的软件可以很容易被重用、维护和扩充。

8. 提高软件的内聚性

如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。

只有高内聚性的模块才可能被重用。

9. 考虑软件的移植性

移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write once run many ? 译者注）。

即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。

记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。

好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。

10. 接受变化

这是一句老话了：唯一不变的只有变化。

你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现（参见“Architecting for Change”，Thinking Objectively, May 1999）

通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。

11. 不要低估对软件规模的需求

Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。

今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。

在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。

在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。

12. 性能仅仅是很多设计因素之一

关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。

但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。

13. 管理接口

“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段的早期就定义软件模块之间的接口。

这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现就不是很重要了。

从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。

14. 走近路需要更长的时间

在软件开发中没有捷径可以走。

缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。

在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。

你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。

避免走捷径，只做一次但要做对（do it once by doing it right）。

15. 别信赖任何人

产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。

大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。

大部分的顾问和承包商只关心你的钱并不是你的工程（停止向他们付款，看一看他们会在周围呆多长时间）。

大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。

只有良好的沟通才能解决这些问题。

要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。

16. 证明你的设计在实践中可行

在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。

你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。

17. 应用已知的模式

目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。

一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。
http://www.ambysoft.com/processPatternsPage.html 收藏了许多开发模式的信息。

18. 研究每个模型的长处和弱点

目前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。

19. 在现有任务中应用多个模型

当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。

当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。

程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。

20. 教育你的听众

你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。

教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。

另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候（比如UML-译者注），你的团队才能实现真正的合作。

21. 带工具的傻瓜还是傻瓜

你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。

使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。

22. 理解完整的过程

好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。

软件开发是一个很复杂的过程，还记得《object-oriented software process》第36页的内容吗？除了编程、建模、测试等你擅长工作外，还有很多工作要做。

好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。

23. 常做测试，早做测试

如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。

建立一个技术原型供技术评审使用，以检验你的软件模型。

在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。

24. 把你的工作归档

不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。 给每个模型一些概要描述以使别人很快明白模型所表达的内容。

25. 技术会变，基本原理不会

如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。

软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始，完善你们自己的软件开发经验。

以鸡汤开始，加入自己的蔬菜。然后，开始享受你自己的丰盛晚餐吧。


UML建模风格之顺序图

LinuxAid.com.cn axing译
2002-06-20

和合作图、活动图一样，UML顺序图( Rumbaugh、Jacobson、和booch, 1999)是一种动态建模方法。 UML顺序图一般用于：

确认和丰富一个使用情境的逻辑。 一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。 一个使用情境的逻辑可能是一个用例的一部分，或是一条备选线路；一个贯穿单个用例的完整流程，例如动作基本过程的逻辑描述，或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。或是包含在几个用例中的流程，例如一个学生注册入学之后，立即就要在三个班级注册。
研究你的设计，因为它们为你提供了一种方式，你可以使用这种方式来可视化的调用类定义的操作。
检测面向对象的设计中的瓶颈。 通过观察什么消息被发送给一个对象，以及通过概略的观察运行被调用的方法需要花费多长时间，你很快就能了解那里的设计需要变化，以达到在系统内部平衡负荷的目的。 实际上某些CASE工具甚至能够让你模拟软件这些特征。
使你能够感觉到你的应用程序的那个类将会变得复杂的，这是个信号，意味着你需要为那些类画状态图了。

指南∶
通用准则

尽力保持消息的顺序从左到右排列。

将分类器分层

用和你的用例图一致的名称命名角色。

用和你的类图一致的名称命名类。

一个角色的名称可以和类的名称相同。

包含一个逻辑的叙述性描述。

在图的最左边放置初始的角色。

在图的最左边放置人和组织角色。

在图的最右边放置系统角色。

只在合适的时候才建模对象的Destruction。

类的原则

当你在消息上引用对象时要命名他们。

当存在部分相同的类型时需要命名对象。

一致地应用文本版型。

少量地应用可视化的版型。

集中在关键的交互。

消息的原则

把消息名放在箭头旁边。

直接创建对象

为软件消息使用操作符号。

为涉及人和组织角色的消息使用叙述性文字。

推荐使用参数名称，而不是参数类型

为参数占位符注明类型

类的消息实现为静态操作

为用例调用使用<<include>>版型

返回值的原则

当返回值非常明显时就不要对返回值建模。

只有当你需要在别处引用返回值时才对返回值建模。

在箭头旁边调整返回值。

返回值建模为方法调用的一部分。

为返回值占位符注明类型

明确的为简单值标明实际值

通用准则

尽力保持消息的顺序是从左到右排列的。

一个顺序图的消息流开始于左上方，消息乙的位置比消息甲低，这意味着消息乙的顺序比消息乙要迟。因为西方的阅读习惯是从左到右，你应该尽量按照和描述消息流一样的方式，从左至右排列分类器（角色、类、对象，和用例）。 在图１中你可以看到分类器已经按照这种方式排列好了，如果Seminar对象在controller的左边，那排列方式就不是标准的了。 注意有时候消息流从左到右的排列是不可能的，例如一对对象彼此调用操作的情形。

将分类器分层

分层是一个通用的面向对象设计的方法，系统通常来说，总是组织成user interface、process/controller、business、persistence、和system层( Ambler 2001)。 当系统是以这种方式设计的时候，通常会加强同属于一层的分类器合作，而降低不同层的分类器的耦合度。 因此按类似的方式对你的顺序图进行分层是有意义的。 就这个使用情境的例子来说，一种分层的方法就是先注明人类角色，然后是表示情境的逻辑的controller类，然后是user interface类，接着是business类，最后是相关的技术类，它封装了对数据库和系统资源的访问。 以这种方式对你的顺序图分层，会使得顺序图更容易阅读，也更容易发现分层的逻辑问题。 图１就采取这种方法。

图⒈一次学生的注册。

用和你的用例图一致的名称命名角色。

当你在对一个使用情境建模时，你的顺序图一般会涉及一个或多个角色。 为了保持一致性，显示在顺序图中的角色的名称应该和用例图上的相同。

用和你的类图一致的名称命名类。

顺序图中的类和类图中的类是相同的，因此它们应该有相同的名称。

一个角色的名称可以和类的名称相同。

在图１你可以看到一个命名为学生的角色和一个命名为学生的类。 这样做是合理的，因为这两个分类器表示两个不同的概念，角色表示在现实中的学生，而类则表示你正在构建的商业应用程序中的学生。

包含一个逻辑的叙述性描述。

图１可以很难理解－－特别是对于不熟悉阅读顺序图人来说－－因为它是很接近于实际的源程序。 在你模型中包含一个业务逻辑的描述是很常见的，特别当该顺序图描述一个使用情境时，就像在在图⒉的左边看到的，这可以增加图的可理解性，并且Rosenberg和Scott（1999）指出，这也为跟踪用例和顺序图间的信息提供了重要的信息。

图⒉在线定单付款。

在图的最左边放置人和组织角色。

对业务应用软件来说，在大多数的中，主要的角色是一个人或一个组织。这些角色经常是该情境的发起人，同时也是顺序图的阅读焦点，因此它们应该放在模型的"可看见的开始之处"。

在图的最右边放置反应系统角色。

反应系统角色是那些你与之交互的系统，应该放在图的最右边。因为在许多的业务应用软件中，这些角色经常被当做" backend entities "，也就是那些你的系统通过存取技术交互的系统，例如C APIs、CORBA IDL、消息队列、或web service。 换句话说，把后端的系统放在图最后的位置。

在图的最左边放置系统角色。

先导系统角色是那些与你的系统交互的系统，根据力争从左到右排列消息和分类器层的原则，应该放在图的最左边。

避免建模对象Destruction

虽然内存管理是很重要的的问题，特别是对象在适当的时候的销毁，许多建模者不愿意在顺序图上建模对象的销毁操作，而是在activation条（就是表示对象生命周期的那个竖条）的底部使用一个"Ｘ"符号，或使用一个带<<destroy>>版型的消息。 比较图１和图２，注意图1中引入了对象的销毁，没带来明显的好处，却弄乱了图的布局。而图２则没有注明对象销毁。 记住遵循敏捷建模( AM)的实践简单的描述模型。

这项指南的意义在于两个理由∶ 首先，很多种语言都拥有称作垃圾收集的技术，实现自动的内存管理，例如Java和Smalltalk。 其次，在那些你需要明确的管理内存的语言中，例如C++，你的程序员一般地都能够了解该怎么做，并不需要模型中的这些附加信息。

注意在实时系统中，内存管理通常是一个关键性问题，你可能需要建模对象的销毁操作。

分类器的原则

注意∶分类器命名规则的在别处描述。 其中，类和接口的命名规则在UML类图的风格指南中描述，用例的命名规则在UML用例图的风格指南中描述，而组件的命名规则在UML组件图的风格指南中描述。

当你在消息上引用对象时要命名他们。

顺序图上的对象应使用标准的UML格式" name: ClassName "来标记，其中" name "可选的（拥有一个名称的对象称作已命名的对象，而那些没有名称的对象则被称作匿名对象）。在图１中，Student的实例以theStudent来命名，因为它是一条消息已引用返回值，然而SecurityLogon类的实例则不需要名称，因为图的其它地方并没有应用它，因此它可以使匿名的。

当存在部分相同的类型时需要命名对象。

当一个顺序图包含几个同样类型的对象时，例如图３存在两个Account类的实例，你应该为该类型的所有对象命名，以避免图的意义含糊不清。

图⒊在账户间转帐。

一致地应用文本版型。

表1总结了一些通用版型，你可以在顺序图的分类器上应用它们。 不要花过多的时间来争论应该使用哪个版型，例如<<JSP>>和<<Java Server Page>>都是不错的版型，只要随便选择一个并保证一致性就好了。

表⒈通用的版型．

版型 用法

<<ASP>> 在设计期间表示微软的Active Server Page。

<<component>> 在设计期间用于注明一个组件。

<<controller>> 用来注明一个控制器类，实现了和使用情境有关的业务逻辑，或包括几个业务类的逻辑。

<<GUI>> 设计期间表示一个图形用户界面屏幕。

<<HTML>> 设计期间表示一个超文本页。

<<interface>> 设计期间表示一个Java接口

<<JSP>> 设计期间表示一个Java Server Page。

<<report>> 设计期间表示一个打印的或电子的报告。

<<system>> 表示系统角色。

<<user interface>> 一个一般的用户界面类。 一般使用在分析级的图上，此时你尚未决定使用何种的实现平台。

少量地应用可视化的版型。

在你的顺序图上应用可视化的版型时完全正确的，就如同你在图２和图３所见的，但它并非一个十分通用的惯例，因此它可能会减少图的可理解性。 在图２中，顾客是一个角色（使用与用例图相同的符号），OrderCheckout是一个控制器类，CheckoutPage是一个用户界面类，而Order是一个业务实体类。

注意，那些需要开发稳定性较高的图的团队会使用可视化的版型Rosenberg & Scott 1999; Ambler 2002)，就像在图２描绘的可视化的版型一样，因此对项目中的所有人都必须熟悉这些符号。

集中在关键的交互。

AM的实践－－创建简单内容建议，当创建一个模型时，你应当集中于系统的关键性特征，而不要包含无关的细节。 因此，如果顺序图是探究业务逻辑的，你就不要包含对象和数据库的具体交互，诸如save ()和delete ()的操作就已经足够了，你可以简单地假定持久性已经能够处理，而不需要去理会细节。 例如，在图２中，你看不到从数据库或对象缓存中读取orders和order items的任何逻辑，只是他们会在适当点发生而已。 你也看不到CreditCardPayment类连接到payment处理器的逻辑，但这个逻辑是必定会发生的。 只把注意力集中在和你正在建模的东西相关的关键性交互上，你可以在尽可能的保持图的简单的同时达到目的，不但提高了建模者的生产力，也增加了图的可读性。

消息的原则

注意∶操作符号的命名规则，和消息、参数、返回值的命名有关的原则都在UML类图的风格指南中描述。
把消息名放在箭头旁边。

大多数的建模者都会调整消息名，例如图２中的calculateTotal ()，因此消息名总是靠近箭头的。 一般我们认为消息的接受者将会实现相应的操作，因此把消息名放在离分类器接近的位置是有意义的。

注意，图３并没有遵循这些原则，所有的消息名都排列在接近发送者的地方。 这种方法的优点在于它很容易看出欲建模的情境的逻辑，而且，如果你使用了清楚的消息和参数名称，那你也许可以不用遵循包含逻辑的叙述性描述的原则。而这种方法的缺点是很难判断哪个操作是被图右方的分类器所调用的。 象往常一样，选择一种方法并一致的应用它。

直接创建对象

在一个顺序图上注明对象的创建通常有两种方法。 首先，你可以用<<create>>版型来发送一个消息，如同图２如...中所示OrderCheckout所示的那样。 其次，你可以通过把图中分类器位置下移，在其侧面调用一个消息的方式直接的显示创建，如你在图１所见的theStudent和图⒉的CreditCardPayment。直接方法的最主要的好处是它可以形象的表示出对象从无到有的逻辑。

为软件消息使用操作符号。

当一个消息被发给一个软件实现的分类器时，例如类、接口、或组件。通用的准则是使用实现语言的语法来描述消息名。 例如，在图３中，消息commit ( transactionID)被发送给source account对象，它使用了类似于Java、C++、和C_#语言的语法。

为涉及人和组织角色的消息使用叙述性文字。

当一条消息的来源或目标人或组织的角色时，需要使用简短的叙述性文字来描述传达的信息、来标记消息。 例如，在图１中，被student角色发送出的消息是provides name和provides student number，它们描述了这个人在做什么。

推荐使用参数名称，而不是参数类型

注意在图３中，大多数的消息都使用参数名称来注明参数，而不是使用类型。唯一的例外是start ()消息中传递的UserID参数。 这可以使你正确地判定该消息传递了什么值，有时候类型信息是不够的。 例如，消息addDeposit ( amount, target, transactionID)传达的信息要比addDeposit ( Currency, Account, int)多。

为参数占位符注明类型

有时参数传递的信息和你正在建模的信息并没有什么关系，虽然这些信息对你而言非常的重要。 在这种情况下就需要注明参数的类型，如图３中的start ( UserID)。

类的消息实现为静态操作

当一条消息被发给一个类时（类使用ClassName的格式标记），我们需要在类的定义中增加一条相应的静态操作。 例如，图１描述了被发送给Seminar类的消息getAvailableSeminars ()，因此该类的定义中应该有一条静态操作。 如果这条消息被发给Seminar一个实例，那就应该有一个相应的实例操作。 这是顺序图和类图间的一项非常重要的一致性检验，某些CASE工具可以自动化实现。

为用例调用使用<<include>>版型

图３显示了一个用例在顺序图中是如何经由一个用<<include>>版型标记的消息被调用的，当你在建模一个包含一个被直接调用的用例的使用情境时，就可以使用这个小技巧。

返回值的原则

当返回值非常明显时就不要对返回值建模。

返回值的显示是使用带返回值标记的虚线箭头，返回值是可选的。 例如，图１中返回值theStudent表示了对SecurityLogon类调用的消息的返回值，然而图２中对order发送getTotal ()消息就没有返回值。 在第一个例子中，创建一个security logon对象会产生一个student对象，这是不明显的，然而向order要求一个小计的返回值是很明显的。

只有当你需要在别处引用返回值时才对返回值建模。

如果你需要在顺序图的另一处（一般是作为参数传递给另一个消息）引用返回值，那就需要在图中著名返回值，这样就能清楚的表明它的出处。

在箭头旁边调整返回值。

大多数的建模者都会把返回值放在靠近箭头地方，例如图２中的theStudent。 一般我们认为返回值的接受者将会使用返回值，因此把返回值放在靠近分类器的位置是有意义的。

返回值建模为方法调用的一部分。

不要使用虚线来弄乱顺序图，考虑在消息名上注明返回值来替代虚线。使用符号message ( parameters) : returnValue，图２就使用了这种符号：reserve () : AuthorizationCode。用这个方法，你只会有单条消息路线，而不会有一条消息路线和一条返回值路线。

为返回值占位符注明类型

有时返回值传递的信息和你的模型并没有什么关系，尽管这些信息对你而言非常的重要。 在这种情况下就需要注明参数的类型，如图2中的reserve () : AuthorizationCode。

明确的为简单值标明实际值

图１中isValid () message返回了值yes，这就清楚的表明了该学生的名称和编号是合法的。如果返回值命名为Boolean，就只是注明回应的类型，如果命名为eligibilityIndicator，就只是注明了返回值的名称，这样就不够明确了。


使用UML设计数据库应用
作者：Michael Blaha 著，张启鹏 译 本文选自：UMLCHINA 2002年04月08日

这篇文章陈述如何用关系型数据库实现UML模型。假设我们熟悉UML对象建模表示法和关系型数据库。

1. 介绍

许多人认为面向对象概念和关系型数据库相互不一致，并且不能结合。事实上完全相反！经过灵活的使用，一个关系型数据库能够为面向对象（OO）模型提供一套优秀的实现。同样的模型能够用来开发编程代码和建立关系型数据库结构。

关系型数据库技术是意义深远的、强大的，但它比许多开发商使你相信的要难得多。单个表是简单易懂的、直观的，但是要彻底了解由数以百计的表组成（这是常见的）的应用是相当困难的。这正是OO模型有用之处。

OO模型使你深入地、连贯地思考问题。OO模型提供一种问题的超结构（superstructure）的思考方式，然后该方式能够用关系型数据库的更低层的组成块来实现。

本文章综合地讨论了关系型数据库技术，而不是集中于特定的产品上。我们将不讨论物理设计细节（例如存储分配和物理聚集），因为它们是依赖于产品的。

用关系型数据库实现UML模型有两个方面：映射结构（第2节）和映射功能（第3节）。第4节注解了面向对象到关系型数据库的扩展。第5节总结本文章。

2. 结构映射到表

UML对象模型在本质上只是一个扩展的实体-关系（ER）模型[ii]。用来设计数据库的ER模型的方式受到普遍接受，而我们将讲述一种近似的但更强大的方式－使用UML对象模型。OO模型的主要优势在于编程和数据库使用相同的模型工作。而且，作为考虑功能性的一种方式（第3节），我们强调OO模型的导航。这一节显示如何实现UML对象模型的主要构造。

2.1 标识（identity）

实现对象模型的第一步是处理标识。我们从定义几个术语开始。

  • 候选键（candidate key）是一个或多个属性的组合，它唯一地确定某个表里的记录。一个候选键里的属性集必须是最小化的；除非破坏唯一性，否则属性不能从候选键删除。候选键里的属性不能为空。
  • 主键（primary key）是一个特定选定的候选键，用来优先地参考记录。
  • 外键（foreign key）是一个候选键的参考。外键必须包括每个要素属性的一个值，或者它必须全部为空。外键用来实现关联和泛化。

正常地你应该为每个表定义一个主键，尽管偶尔有例外。我们强烈建议所有的外键都只指向主键而不是其它的候选键。

定义主键有两种基本的方法：

  • 基于存在的标识。你应该为每个类表加一个对象标识符属性，并将它设为主键。每个关联表的主键包括一个或更多的相关类的标识符。基于存在的标识符有作为单独属性的优势，占位小且大小相同。只要你的关系型数据库管理系统（RDBMS）支持，基于存在的标识符就没有性能的劣势。（多数RDBMS提供有效的基于存在的标识符的分配顺序号码。）唯一的劣势是基于存在的标识符在维护时内没有固有的意义。
  • 基于值的标识。一些真实世界的属性的组合确定了每个对象。基于值的标识有不同的优势。主键对于用户有固有的意义，容易进行调试和数据库维护。在另一面，基于值的主键很难改变。一个主键的改变需要传播到许多外键。而一些对象没有自然的真实世界里的标识符。

我们推荐你在超过30个类的RDBMS应用里使用基于存在的标识。基于存在和基于值的标识都是所有RDBMS应用的可行选项。

2.2 域（属性类型）

属性类型是UML术语，对应于数据库著作里的域的术语。比起直接用数据类型，域提升到更一致的设计，并便利了应用的定位。

简单域很容易实现。你仅仅要定义相应的数据类型和大小。并且每个用了域的属性，你都必须为每个域约束加入一条SQL检查子句。简单域的一些例子是：名字（name），长字符（longString）和电话号码（phone-Number）。

一个枚举域把一个属性限制在一系列的值里。枚举域比简单域实现起来更复杂，图1显示了四个方法。

图1 枚举的实现方法。

实现方法 | 优势 | 劣势 | 建议
枚举字符。定义一条SQL检查约束，把该枚举限制在允许的值里。 | 简单。受控的方便搜索的词汇表。 | 大的枚举难以使用检查。约束难以编码。 | 我们正常地选择。
每个枚举值一个标记。为每个枚举的值定义一个布尔型属性。 | 回避命名的难处。 | 冗长 － 每个值一个属性。 | 当枚举值不是互相排斥的并且多个值可能同时地应用时使用。
枚举表。把枚举定义存储到一个表里。不是每个枚举一个表，也不是所有的枚举一个表。 | 高效地处理大的枚举。不用改变应用的代码就可以定义新的枚举值 | 偶尔使用时很麻烦。必须编写通用的软件来阅读枚举表和加强值。 | 适合大的枚举和没有结尾（open-ended）的枚举。
枚举编码。把枚举值编码作为有序的数字。 | 节省磁盘空间。有助于用多种语言处理。 | 大大地复杂化了维护和调试。 | 避免使用，除非你要用多种语言处理。

2.3 类

正常情况下，我们把每个类映射为一个表，每个属性映射为一个列。你可能因一个已产生的标识符（基于存在的标识符）、隐藏的关联（第2.4节）和通用鉴别器（第2.5节）需要一些另外的列。

2.4 关联

现在我们讨论关联的实现。我们已经把我们的陈述分为建议的映射（我们正常使用的映射），可选的映射（我们偶尔使用的映射）和不鼓励的映射（我们遇到的应该避免的错误）。我们所有的例子都采用基于存在的标识。

2.4.1 建议的映射

  • 多对多关联。用一个单独的表（图2）来实现一个多对多关联。关联的主键是每个类的主键的合并。那些省略号（...）表示在模型里没有显示出来的属性。主键用黑体字体显示。
  • 一对多关联。把一个外键隐藏在“多”表（图3）。角色名字成为外键属性名字的一部分。
  • 零或一对一关联。把外键隐藏在“零或一”表（图4）。
  • 其它一对一关联。把外键隐藏在任一表里。

图2 建议的实现：单独的多对多关联表。

图3 建议的实现：隐藏的一对多关联。

图4 建议的实现：隐藏的零或一对一关联。

2.4.2 可选的映射

正常情况下我们使用建议的映射。但有些偶尔的情况，可选的映射更合适。

  • 单独的表。你也可以用单独的表（图5）来实现一对多和一对一关联。单独的表给了你更统一的设计和更大的扩展性。无论如何，单独的关联表打碎了数据库，并增加了表的数量。此外，单独的关联表不能强迫一个更低的多重性限度为“一”。

2.4.3 不鼓励的映射

我们已经注意到有些开发者选择有缺陷的映射。我们要注意避免这些映射。

  • 合并。不要合并多个类，不要把关联强制成为一个单独的表（图6）。这样减少了表的数量，但会干扰第三范式。
  • 两次隐藏一对一关联。不要把一个一对一关联隐藏两次，每次隐藏在一个类里（图7）。这是多余的，无助于性能。
  • 相同的属性。不要用相同的属性来实现多个关联角色（图8）。相同的属性使编程复杂，降低了扩展性。

图5 可选的实现：单独的一对x关联表。

图6 不鼓励的实现：类的合并。

图7 不鼓励的实现：两次隐藏的一对一鼓励。

图8 不鼓励的实现：相同的属性。

2.5 泛化

现在我们讨论泛化。我们这里只论述单个继承。

2.5.1 建议的映射

最简单的方法是只映射超类和每个子类为一个表。所有的表共享一个共同的主键。应用必须执行子类的划分，因为RDBMS并不能执行。（关于后者的详尽的描述，请参阅第4节。）

  • 单独的表。映射超类和每个子类为一个表（图9）。所有的表共享一个共同的主键。鉴别器指出每个子类记录的适当的超类表。

图9 建议的实现：分开的超类和子类表。

2.5.2 可选的映射

泛化有几个可选的映射。

  • 消除。你可以优化除去那些除了主键外没有别的属性的类（图10）。这样减少了表的数量，但提供更少的正规实现。
  • 减少超类属性。你可以除去超类表并把超类属性复制到每个子类（图11）。这样可以有描述每个对象为一个表的优势。无论如何，它将引起数据库结构的冗余，你查找一个对象时可能需要搜索多个子类表。
  • 增加子类属性。作为第三个可选项，你可以除去子类表并存储所有的子类属性到超类表里（图12）。这样用一个表描述每个对象，但干扰了第二范式。

图10 可选的实现：消除不必要的子类表

图11 可选的实现：减少超类属性。

图12 可选的实现：增加子类属性。

2.6 参考完整性

一旦你已经建立了表，你就应该定义参考完整性动作来明确对象模型的意义。（不要使用SQL触发器来实现参考完整性！）如果你使用基于存在的标识，你将不需要传播更新的结果。我们建议以下对删除的参考完整性方针：

  • 泛化。级联从泛化实现中产生的外键的删除。
  • 隐藏的关联，最小多重性为零。正常地把外键设为空，但有时候你可能要禁止删除。
  • 隐藏的关联，最小多重性为空。你可以级联一个删除的结果或者禁止该删除。
  • 关联表。正常地我们对关联表里的记录进行级联删除。可是，有时候我们禁止一个删除。

我们已经简要地论及参考完整性，因为它是个高级话题。参考文献[iii]有更多的解释和例子。

2.7 索引

实现数据库结构的最后的一步是加入索引来调整数据库性能。正常地，你应该为每个主键和候选键定义一个唯一的索引。（多数RDBMS作为SQL主键和候选键约束的副作用来建立唯一的索引。）你也应该为每个被主键或候选键所约束的外键建立一个索引。

我们强调索引的重要性。外键和主键的索引使在对象模型里能快速地遍历是不容怀疑的。你必须包括这些索引，否则你将使用户感到灰心。你应该在你的数据库开始设计阶段里加入索引，因为它们很容易加入并且也没有什么好理由推迟加入。

数据库管理员（DBA）可能为经常请求的查询定义了额外的索引。DBA也可能采用产品相关的调整性能的机制。

2.8 范式

范式是关系型数据库设计的提高数据一致性的有效方法。我们的书3讨论了范式，但我们关于这个问题却说错了。我们将利用这篇文章的机会来澄清我们的观点。如果你不熟悉范式你可以跳过这节。我们的说明是针对关系型设计人员，他们正在尝试用面向对象适应他们原有的技能。

范式是正确设计关系型数据库的精确的原则。同样地，它们与使用了什么开发技术是无关的 － 基于属性的设计、基于实体的设计、面向对象设计或其它什么。

过去使用基于属性设计的方法，开发人员不得不非常注意范式；范式提供了分组数据的根据。相反地，范式对于基于面向对象（或基于实体）的开发不是很重要。如果你采用OO方法并且你的模型经过很好的构思，那你就正在把数据组织成为有意义的单位，也在本质上满足了范式的规定。如果你愿意，你仍能够检查范式，但这样的检查是不必要的。

2.9 摘要

图13总结了我们已经陈述的映射规则。这些映射规则的完整例子，包括一个UML对象模型，能够在这篇完整的扩展版本里找到（Adobe Acrobat PDF文件）。

概念 | 对象模型构造 | 推荐的RDBMS映射
域 | 简单域 | 映射为一个数据类型和大小
 | 标识符 | 用RDBMS顺序号
 | 枚举 | 通常储存为一个字符串
类 | 类 | 映射每个类为一个表
关联 | 多对多关联 | 单独的表
 | 一对多关联 | 隐藏的外键
 | 一对一关联
泛化 |  | 分开超类表和子类表

图13 推荐的映射规则的摘要。

3. 把功能映射到SQL命令

对象模型为数据库应用提供三种主要的用途。

  • 结构。对象模型指明数据库结构。我们已经在第二节探讨了这个方面。
  • 约束。对象模型也指明了能存储的数据上的重要的约束。相匹配的实现必须为迎合这些约束而努力。我们的映射规则的处理方法以及第二节里的参考完整性指出了许多约束。（本文没有论及的另外的UML构造，能获取更多的约束。）
  • 潜在估算。一个对象模型指明潜在估算；它是关于引起哪些查询和如何公式化的蓝图。第三节将简要地阐明第三个目的。

对象模型不仅仅是被动的数据结构，相反它们能够帮助你思考一个应用的功能。你可以根据遍历一个对象模型说出它的许多功能。例如，根据我们对一个模型检查用例时的遍历，我们进行思索。这强调对象模型的估算能力对于RDBMS应用是特别重要的，因为遍历表达式可以直接映射到SQL代码。

UML对象约束语言（Object Constraint Language，OCL）有助于表达遍历。点符号导航从对象到对象和对象到属性，方括号表示对象集合的过滤器。我们加入冒号（：）操作符来表示泛化的遍历；因为我们正常地用多个表来实现一个泛化继承，清楚的遍历很有用。

图14里的遍历表达式例子是基于我们创建的UML对象模型上的（请参阅本文的扩展版本（Adobe Acrobat PDF文件）），我们把它们映射为SQL代码。我们用冒号开始SQL编程变量。

遍历表达式 | 含义 | SQL代码
anAirline.Emploee | 给定的一条航线，找出相应的员工。 | SELECT employeeID FROM Employee WHERE arilineID = :anAirline;
anAirline.Employee.name | 给定的一条航线，找出相应的员工的名字。 | SELECT name FROM Employee WHERE airlineID = :anAirline;
anAirline.Flight [getMonth(date)==aMonth].pilot | 找出在某个给定的月份里为一条航行飞行的机师。 | SELECT pilotID FROM Flight WHERE airlineID = :anAirline AND GetMonth(date) = :aMonth;
anAirline.Flight [getMonth(date)==aMonth].pilot[flightRating==aFlightRating] | 找出在某个给定的月份里为一条航线飞行的在一个给定的飞行等级里的机师。 | SELECT P.pilotID FROM Flight F, Pilot P WHERE F.airlineID = :anAirline AND getMonth(F.date) = :aMonth AND F.pilotID = P.pilotID AND P.flightRating = :aFlightRating;
aFlight.copilot:Employee.name | 为一次飞行找出副机师的名字。 | SELECT E.name FROM Flight F, Pilot P, Employee E WHERE F.flightID = :aFlight AND F.copilotID = P.pilotID AND P.pilotID = E.employeeID;

图14 对象模型遍历和SQL代码的例子。

4. RDBMS的OO扩展

数据库团体对RDBMS的OO扩展有兴趣。产品和SQL标准正尝试加入到OO扩展里。我们将简要地陈述一下这个技术的方向。

  • 抽象数据类型（ADT）。这是个好主意，扩展RDBMS的能力。开发商为这个技术使用了许多名字，例如Oracle cartridge和Informix data blades。ADT的缺点是它们把你紧紧绑在特定的一个开发商上；ADT的范畴超越了SQL标准。因此，你应该只在ADT的好处很明显的时候才使用。
    在关于ADT如何适合数据库开发的著作里有一些混乱。如果你使用OMT开发过程，你能够用属性实现简单域，用ADT实现复杂域。你仍应该用表实现类。
  • SQL3指针。最新的SQL标准的版本，SQL3，加入了作为一种数据类型的指针符号。显然，其意图是支持导航和面向对象。我们对于SQL3指针最友善的评语是，它们是嫁接的，是可以忽略的。更深入的批评是，指针在理论上是荒谬的，增加了复杂性，又没有扩展SQL的表达能力。CJ Date在上次的九月对象/关系型会议上雄辩地讨论了这一点[iv]。
    好了，那么我们冷淡地对待抽象数据类型和SQL指针的指责。但我们相当喜欢面向对象技术和关系型数据库。有两个为RDBMS的扩展可以使它们更容易用于OO技术。我们将很乐意看到RDBMS开发商把这些能力加入到他们的产品中。
  • 扩展的参考完整性动作来支持泛化。当前的参考完整性机制是单向的。为了完全支持泛化，我们需要一个双向的机制。这样，一条超类记录就可以依赖一条子类记录。并且，一条子类记录就可以依赖一条超类记录。我们通过例子可以最好地解释这点。

图15摘录于我们的在参考文献3的财务案例学习。我们用资产超类来统一某些没有显示在摘录里的通用的数据和功能。一项资产可以是一支股票或股票期权。一支股票可以有许多它的股票期权。例如，IBM股票可以有许多写明达到价格和过期日期的期权。

图15 参考完整性和泛化的例子。

我们推荐的泛化实现是单独的表 － 映射该超类和每个子类为一个表。然后，我们就可以使用参考完整性使股票期权和股票的记录依赖于资产。一个资产记录的删除级联到相应的子类记录、股票期权或股票的删除上。我们也能够定义一个参考完整性动作，这样一个股票的删除就级联到关联的股票期权记录的删除。

现在问题如下：如果我们删除的一项资产是一支股票，资产记录的删除级联到引起股票记录的删除。随后，股票记录的删除级联引起所有股票期权记录的删除。但现在参考完整性使我们失败了：一条股票期权记录的删除并不引起一项资产记录的删除。删除级联只能从超类走到子类。为了完全的行为，级联应该双向地走下去。

当前有用的参考完整性的工作是做更多的编程（也即做更多的工作和承担更多的故障风险）。在我们的案例学习的实现里，用户随时要删除一项是股票的资产，我们不得不书写额外的代码来首先检查关联股票期权的存在性，然后删除它们。

  • 支持交叉表的记录划分。单继承（泛化的最常见方式）的含义是一个超类的每个实例都是用最多一个子类来例示。现在的RDBMS不能容易地加强这个约束。例如，没有什么防止下面的情形。一支股票可以用ID18加入到资产表，用ID18加入到股票表，并且也可以用ID18加入到股票期权表。再一次地，我们为了确信行为的完整，不得不作额外的编程，而不是写一个简单的声明约束。

5. 结论

本文陈述了用关系型数据库实现UML模型的快速的概观。我们希望本文向你演示的技术是十分适用的。一个训练有素的开发人员能够用关系型数据库准备一套优秀的OO模型的实现。如果你要关于实现机制的更多的细节，参考3有另外的信息，并且也覆盖了我们没有在这里讨论的一些高级模型建模结构。

关于作者

Michael Blana是纽约Schenectady的通用电气研发部的毕业生（译者按：这是作者幽默的说法，意思是他已经跳槽了）。在过去的五年里，他已经成为面向对象技术、建模、数据库设计和逆向工程领域的独立的产业顾问。Blaha博士是多篇论文、五个专利和两本书的作者。可以通过www.omtassociates.com或blaha@acm.org和他联系。

William Premerlani从1975年开始就在通用电气研发部供职。他的主要研究兴趣在软件工程、元建模（metamodeling）、数据库技术和复杂工程应用等领域。Premerlani博士是许多论文、二十五个专利和两本书的作者。通过premerlani@acm.org和他联系。

参考资料

[i]Michael Blaha and William Premerlani. Object-Oriented Design of Database Applications. Rose Architect 1,2 (Winter, 1999).

[ii] PPS Chen. The Entity-Relationship model - toward a unified view of data. ACM Transactions on Database Systems1, 1 (March 1976).

[iii] Michael Blaha and William Premerlani. Object-Oriented Modeling and Design for Database Applications, Prentice Hall, Englewood Cliffs, New Jersey, 1998.

[iv] CJ Date. Don't mix pointers and relations! Presentation at Third Annual Object/Relational Summit sponsored by Miller Freeman, Washington D.C., September 16-19, 1998.

『引自 UMLCHINA』


为基本用例建模

英文原文

内容：

基本建模

用例

比较

示例 1

示例 2

参考资料

关于作者

从何处来，到何处去

Scott W. Ambler
总裁，Ronin International
2000 年 7 月 20 日

基本建模是以使用为核心的设计的基本方面。本周 Scott Ambler 介绍有关开发基本用例模型的一些背景知识和建议。

需求建模中的重要目的是要理解系统将处理的业务问题，以理解它的行为需求。至于面向对象的开发，您应该开发以对行为需求建模的基本构件是用例模型。用例图表是标准的“统一建模语言 (UML)”构件之一。用例模型有两种基本风格：基本用例模型和系统用例模型。

  • 基本用例模型，通常称为商业或抽象用例模型，对行为需求的与技术无关的视图建模。
  • 系统用例模型，也称为具体用例模型或详细用例模型，为行为需求的分析建模，详细描述用户将如何使用系统，同时它还提及系统用户接口方面的问题。

什么是基本建模？
基本建模是以使用为核心的设计的基本方面——它是一种软件开发方法，Software for Use 一书（请阅读参考资料）详细描述了该方法。基本模型旨在通过与技术无关、理想化和抽象的描述来表示问题本质。产生的设计模型更加灵活，它使更多选项公开并且在技术方面更容易进行更改。基本模型比具体表示法更加强健，这是因为在需要更改需求和更改实现技术时，它们更易保持有效。用法的基本模型强调目的，即用户试图实现什么任务以及他们这样做的原因。简而言之，基本模型是表示系统需求的理想构件。

什么是用例？
用例是向参与者提供重要价值的操作序列。认识它的另一种途径是：用例描述实际参与者与系统交互的方式。基本用例是一种简化、抽象且通用的用例，它以独立于技术和实现的方式描述用户的意图。基本用例是一种结构化的叙述，用应用程序领域和用户的语言来表达，它包含对任务或交互的简化、通用、抽象、与技术无关且独立于实现的描述。从担当某个（或某些）系统角色的用户的观点来看，基本用例是完整而有意义的，并且设计得很好，这就体现了交互背后的目的或意图。

比较系统用例和基本用例
请仔细查看示例 1 和示例 2 提供的两种版本的用例“参加研习班”，前者显示了简化的系统用例（也称作传统或具体用例），后者将它表示为基本用例。经过观察，我们会发现以下一些有趣事项：

1. 系统用例嵌入了很多实现细节。例如，登记员的概念消失并且被术语系统取代，这表示已经决定自动处理许多有关参加的琐碎事件。系统用例的作者分析和描述了由混有关于将使用什么样的用户界面的隐含决策的问题所引发的需求；而基本用例的作者不这样做。

2. 系统用例提及屏幕和报告，如“UI23 安全性登录屏幕”和“UI89 登记摘要报告”。 基本用例不引用它们。这再一次反映了实现的详细信息；某人已经决定系统将作为屏幕（或许与 HTML 页面相反）和打印的报告实现。然而，基本用例也可以只简单地引用主要的用户界面元素（即，屏幕和报告的基本版本），并且告诉您，这是我推荐的作法。 我没有在示例 2 中引用 UI 元素， 以便为您提供没有执行这些任务的示例。

3. 因为商业规则反映系统必须实现的域的基本特征，所以两种版本都引用商业规则定义，如“BR129 确定参加资格”。

4. 系统用例的步骤比基本用例的步骤多。实际上，这反映了我编写用例的风格；我相信每个用例步骤应该只反映一个步骤。这种方法有几个优点：用例更容易测试，因为每条语句都更加容易理解和验证；备用课程更加容易编写，因为当语句只做一件事时更容易从语句中分支。

5. 用例步骤以主动语态、而不是以被动语态编写。语句“登记员通知学生有关收费情况”比语句“学生被登记员通知有关收费情况”更加简洁。

6. 两个版本都以类似“用例结束”或“在某些情况下用例结束”的步骤结束，以表示已经完全定义了操作过程的逻辑。

通常，传统或系统用例本身对有关基本技术实现和有待设计的用户界面方面所作的假设太多，通常是隐藏的或暗示的。在分析和设计期间，这是一个较好的特性，但对于您的需求实现来讲，并不理想。另一方面，基本用例基于用户的目的或意图，而不是基于实现目的或意图可能依据的具体步骤或机制。编写基本用例作为所需的构思工作的一部分，然后在分析和设计期间，将它们发展成系统用例。

示例 1：“参加研习班”系统用例

名称： 参加研习班

描述：
允许有资格的学生参加研习班。

前提：
是在校注册学生。

结果：
在学生有资格且有空位的条件下，允许学生参加他们想参加的课程。

基本行动过程：

1. 学生想参加研习班。

2. 该学生从“UI23 安全登录屏幕”将他的姓名和学号输入系统。

3. 系统根据“BR129 确定参加资格”商业规则来验证该学生是否有资格参加学校里的研习班。

4. 系统显示指出可用研习班列表“UI32 研习班选择屏幕”。

5. 学生指定他想参加的研习班。

6. 系统根据“BR130 确定学生参加研习班的资格”商业规则来确认该学生是否有资格参加研习班。

7. 系统根据“BR143 验证学生研习班课程表”商业规则来验证研习班是否适合该学生的现有课程表。

8. 系统根据课程分类表中公布的费用、相应的学生费用和相应的税来计算研习班的费用。使用“BR 180 计算学生费用”和“BR45 计算研习班税款”商业规则。

9. 系统通过“UI33 显示研习班费用屏幕”显示费用。

10. 系统询问该学生是否仍然想参加本次研习班。

11. 该学生表示他想参加研习班。

12. 系统允许该学生参加研习班。

13. 系统通过“UI88 研习班注册摘要屏幕”通知该学生注册成功。

14. 系统根据商业规则“R100 为学生开具研习班帐单”给该学生开出参加本次研习班的费用帐单。

15. 系统询问该生是否想打印注册报告书。

16. 学生表明他想打印报告书。

17. 系统打印注册报告书 -“UI89 注册摘要报告书”。

18. 当学生拿到打印的说明后，用例结束。

示例 2：“参加研习班”基本用例

名称： 参加研习班

描述：
允许有资格的学生参加研习班。

前提：
是在校注册学生。

结果：
在学生有资格且有空位的条件下，允许学生参加他们想参加的课程。

基本行动过程：

1. 学生想参加研习班。

2. 学生将他的姓名和学号提交给登记员。

3. 登记员根据“BR129 确定参加资格”商业规则来验证该学生是否有资格参加学校里的研习班。

4. 学生从可用的研习班清单中指定他想要参加的研习班。

5. 登记员根据“BR130 确定学生参加研习班的资格”商业规则来确认该学生是否有资格参加研习班。

6. 登记员根据“BR143 验证学生研习班课程表”商业规则来验证研习班是否适合该学生的现有课程表。

7. 登记员根据课程分类表中公布的费用、相应的学生费用和相应的税来计算研习班的费用。使用“BR 180 计算学生费用”和“BR45 计算研习班税款”商业规则。

8. 登记员通知学生有关费用情况。

9. 登记员验证学生是否仍想参加研习班。

10. 该学生表示他想参加研习班。

11. 登记员允许该学生参加研习班。

12. 登记员根据商务规则“BR100 为学生开具研习班帐单”将适当的费用添加到学生的帐单中。

13. 登记员向学生提供他已进行的确认。

14. 用例结束。

参考资料
有关用例建模的详细信息，请参阅：

  • Applying Use Cases: A Practical Guide，G. Schneider 和 J.P. Winters 合著
  • Use Case Driven Object Modeling with UML: A Practical Approach，Doug. Rosenberg 和 Kendall Scott 合著
  • The Object Primer 2nd Edition，Scott W. Ambler 著
  • The Unified Modeling Language Reference Manual，James Rumbaugh、Grady Booch 和 Ivar Jacobson 合著
  • Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design，Larry L. Constantine 和 Lucy A.D.Lockwood 合著。
  • Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology，Scott W. Ambler 著
  • Software Requirements，Karl Wiegers 著

关于作者
Scott W. Ambler 是 Ronin International 的总裁，该公司是一家专门提供面向对象软件过程指导、体系结构建模和 Enterprise JavaBean (EJB) 开发的咨询企业。他自己著作了或者与其他人合著了几本有关面向对象开发的书籍，包括最近出版的 The Object Primer 2nd Edition，该书详细介绍了本文所概述的主题。可以通过 scott.ambler@ronin-intl.com 和他的网站 www.ambysoft.com 与他联系。


系统分析及软件建模

来源： 网络项目管理学会 作者： 九点

如果眼光仅仅放在满足客户眼下的需求，当问题不断出现时再不断修补，头痛医头，脚痛医脚，甚至系统构架需要不断调整或重新设计，那么，很快就会陷入代码泥潭或坠入系统重复开发的无底深渊，当初项目完成时的成就感将被无止境的沮丧所代替。系统分析决定系统开发的成败，软件建模使系统开发走向成熟。

本章包括以下内容：
一：系统分析在网站项目管理中的地位
二：系统分析所要做的工作
三：系统分析的难点和技能要求
四：软件建模使系统开发迈向成熟
五：总结

一：系统分析在网站项目管理中的地位

在进行了需求分析和业务流程分析并得到客户的认可之后，对项目进行系统分析是极其重要的。系统分析是能体现整个系统的灵魂的文档，将客户的需求从具体到抽象的一个过程，并制定编码人员可实施的规范和标准。
由于Web应用技术发展的历史相对与软件的历史短得多，在开发网络应用系统尤其是网站制作的系统设计中设计人员往往对系统分析重视的不够，特别是设计一些初期比较简单的或交互及功能较少的网站时，主要原因通常为：
 客户初期的需求比较简单，忽略了客户潜在的巨大需求；
 项目实施周期短，初期阶段采用最快的而不是最合理的实现手段；
 经费有限，难以支付高质量的人力费用；
 Web编程技术手段多样，容易上手，设计人员参差不齐；
从现实中来看，网站项目的开发与管理和实施远不如软件工程规范，在编程语言、数据库、通信协议、应用服务器等相关环境都在不断快速发展和完善的情况下，的确很难期望每一个设计师都能网站项目进行系统的合理的分析，从而制定一套跨平台、健壮的、易扩展和升级的系统方案。
但是，这并不能成为系统分析员逃避或懈怠的借口，如果把一个系统比做一部汽车，系统分析的工作相当于设计发动机，也许很容易就想像的出用125cc的摩托车发动机去牵引10吨重载卡车会是一个什么样的后果。
在系统分析的过程中需要对需求分析进行进一步的深化和分析，通常客户及业务人员在需求分析和流程分析的过程中比较注重功能上的表现和定义，即使是做出正规的用户界面原型，对系统的需求也是不完整的，处于非技术人员的缘故，很难苛求能提出完整清晰专业的性能需求，但不意味着这需求不存在，而且这隐藏的需求对编码人员来说是极其重要的。
因此，客户的需求能否在系统中得到真正的体现和实施，系统分析是至关重要的。

二：系统分析所要做的工作：

把系统分析和详细设计阶段分开，针对不同项目的具体情况再决定采用什么方式进行开发。
那么在系统分析过程中重点要做的是：
 对客户的需求分析进一步完善和补充，尤其是性能需求：让客户更加清楚这是一个什么样的系统，所要达到的功能和性能指标是什么，系统的扩展性和适应性如何，如何为客户今后的升级或维护提供最有效的方法。
 系统运行所需要的的环境：系统能正常运行所需要的硬件、软件、网络环境；
 系统的资源说明：系统所需要的各种成本。包括人员、时间、工作环境、一次性投入资金、持续性投入资金等所有资源。
 系统可行性分析；
对于系统分析员比较苦恼的是大多客户在系统的要求上提不出独立的或成熟的意见，而将烫山芋交给了系统分析员的手上，为了避免在系统论证方面难以把握的失控和无从下手，设计几种不同类型的方案供客户选择不失为一个好的方法：
“比如通常至少应该考虑下述几类可能的方案：
    1：低成本的解决方案
    系统只能完成最必要的工作，不能多做一点额外的工作。
    2：中等成本的解决方案
    这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。
    3：高成本的"十全十美"的系统
    这样的系统具有用户可能希望有的所有功能和特点。系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系统（最佳方案），并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。”（引用《如何写系统分析书》一文）
经过系统分析的阶段，我们就比较容易和客户在系统如何部署、采用的数据库类型、设计模型和分析模型等方面达成一致的认识，如果能顺利地将客户的需求业务逻辑分析转化为程序逻辑，把原先用户可视化的界面原型和业务流程图映射成编码人员理解的模型和规范时，那么恭喜你，项目已经成功了一半。

三：系统分析的难点和技能要求

网络应用的开发技术在日新月异地进步，从而使网站应用系统的开发模式具有多种选择性，达到同样的目标可以采用很多不同的方式，现代的应用系统越来越成为一个庞大的集成方案，需要考虑不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等，无疑对系统分析员来说是个严峻的考验，任何人都不可能精通甚至说掌握全部的技术，简单例子：现在有Windows，Unix，Linux等各种服务器操作平台，有SQL Server，Oracle，DB2，Sybase，MySQL等数据库，有JAVA，PHP，ASP，CGI，JSP，C++，VB，Delphi等等工具，谁能全部精通呢？如果不能，那么如何确定是Windows+SQL Server+ASP好还是Unix+Oracle+JAVA合适？况且各种软件和语言还在不断发展进步之中，超越窄带的互联网，今后还可以涉及到宽带所带来的变动，或者增加与无线移动的接口，因此系统分析员能否出色的胜任工作很大程度上决定了系统开发的成败。
系统分析的主要难点在于：
 对客户隐藏的性能需求的分析：由于客户对尚未实施的系统无法预见，对今后的业务发展也无法预知，对性能需求的分析和定义更需要系统分析员协助客户去确定和挖掘；
 确定项目设计方法：根据项目需求和资源的配置选择最合适的设计方式。
 对系统模块的划分和代码复用的设计：模块最大化，代码复用度最高，是一个成熟的系统不断致力追求的，将大型复杂的应用系统分解成相对独立，具有高度复用的模块，各个模块之间采用规范的参数接口，将大大提高系统的开发效率和维护升级的方便性。即使在网站的模版设计或交互设计上，也尽可能采用嵌套可复用的模版或调用统一的样式表、JS文件等。
 项目整体评估：系统分析员绝不应成为孤立的完美主义者，而需要根据项目的大局出发，比如公司的资源配置、人力状况、客户要求等因素评估项目整体和各个模块的工作量、进度和分配资源，制定出最合理的可行的实施方案。
系统分析员不但需要具备良好的沟通协调能力，更需要具备业务和技术领域两方面的专业技能，在项目小组中是非常关键的角色之一。

四：软件建模使系统开发迈向成熟

Web应用系统往往随着客户的需求增长，开发不断深入，最终变得非常复杂，而且以Web为核心的网站系统通常都具有高度的动态扩展和交互，要在不完整和不断改变的需求情况下，在有限的时间内完成一套容易修改和维护的健壮的系统，在UML（统一建模语言）出现之前是极其困难的。
大多的Web设计师或程序开发员为了让客户尽快看到可运行的应用系统，经过界面设计或简单的系统分析后直接进入编码阶段，甚至各个模块分头开发，服务器段代码随意编写、数据库任意添加、参数定义没有规范，整个应用系统处于一种无序混乱的状态，当我们采用建模及按照软件工程的方式进行管理的时候，情况马上就会好的多。

什么是建模？

 建模是使你逐层深入解决问题的办法；
 确认应用系统的功能需求并为事务处理原则建模；
 对抽象的对象映射需求，辨认和提供设计模版并创建惯用的模版；
 分辨和设计对象或划分三层模型的服务；
 对软件的组成部分映射成对象并设计组件在网络上如何分布；

UML（Unified Modeling Language，统一建模语言）是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，同样，在网站设计或以网站为表现形式的各种网络应用项目中，UML也表现出强大的作用。UML能够描述系统的静态结构和动态行为：静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系；动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML不是一种程序设计语言，但我们可以用代码生成器将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML模型。
我们可以看的出，建模并不等同于程序编码，利用同样的UML模型可以生成不同语言的框架代码，而且可以通过反向生成，在编写代码过程中及时更新UML模型，这对系统分析员和项目管理人员来说是梦寐以求的。只要能够仔细地把握客户的需求，不断改进UML模型，那么采用什么样的语言开发已经成了次要，大量的需求积累和分析工作能在客户需求变化时得到高度的复用，即使系统采用新的语言重新开发，需要的也仅仅是编码部分的工作。
虽然软件建模可以在开发的任何阶段进入，但是在设计初期，应该将精力更加集中在系统功能及性能分析、系统运行环境、选择编程语言等，而不是考虑考虑程序的细节，如在屏幕上的什么位置放置按钮等。在项目开发的中期引入建模是非常有意义的，通过建模把握程序开发的方向，准确完成需求分析中所要求的任务。
在高展先生的《全程建模》一文中阐述的“全程镜像一体化建模方式“，整个建模过程依靠业务驱动，在模型设计中利用盒子的上下两部分分别代表业务组织结构和软件逻辑结构，将客户可视的具体的需求与系统抽象的逻辑流程一一对应，这对缺乏技术背景的客户代表和经验不足的系统分析员之间的沟通具有明显有效的作用。

五：总结

系统分析是项目开发中最艰巨的工作，本阶段需要特别注意的工作重点在于：
 补充完善上一阶段可能欠缺的系统的性能需求；
 系统分析员需要站在全局出发，设计合理可行的设计方案；
 在需求不明的情况下设计多种解决方案供客户选择，
 将系统分解模块，最大限度地设计代码复用；
 使用UML建模方式，将客户变化的需求映射到模型中，大大提高系统的扩展性和开发效率


建模工具Rose的学习（1）

51CMM.COM原创 作者：天雨

    在随着面向对象的程序设计的广泛应用，可视化编程遍地开花的今天，编程工作人员的地位一再被动摇，早以不再作为开发中的主流，而软件工程的应用以作为软件开发的质量和效率的重要见证已越来越被重视，针对早期的结构化建模工具的明显不足，ROSE吸取众多建模工具的优点，排除其不足，采用面向对象的成熟技术和双向工程的技巧，为提高软件开发的效率，保证软件开发的质量和可维护性作出了巨大的贡献。
软件工程概述
    软件开发是一套关于软件开发各阶段的定义、任务、作用的建立在理论上的一门工程学科。它为解决软件危机，指导人们利用科学、有效的方法来开发软件，提高及保证软件开发的效率和质量取到了一定的作用。 软件开发过程：需求分析（开始阶段）--概要设计（静态结构）--详细设计（动态结构） --编码-测试-维护
结构化模型设计方法
A．E-R图（实体关系图）
    实体：客观存在并可区分的事物。
    属性：实体所具有的某种特性，一个实体可以有多个属性。
    关系：实体之间的对应关系，可分为1：1联系、1：n联系、m：n联系

B．数据流图

C．功能模块图

结构化模型的不足
    传统的结构化模型的设计所建立的模型不能反应源代码，与程序设计脱节。模型与代码几乎没什么关系。这样的模型不能生成代码，代码更不能生成模型，模型大多是画给领导看或拿出作掩盖。所以不能保证软件的质量，更不易软件的维护，没什么约束力也没有检测的标准，它的弊端是显于易见的。
面向对象的模型设计方法
    定义：利用面向对象方法，把应用程序分成许多小块（对象），这些对象是独立的，然后组合这些对象，建立程序。
    特点：包装、继承、多态。
    常用的建模工具：PlayCase, Rational ROSE, Computer Association BPWin , Computer Association ERWin, Oracle Designer/2000, Sybase PowerDesigner
UML语言概述
    定义：一种面向对象的统一建模语言。
    作用：帮助我们对软件系统进行面向对象的和建模。
    核心：类，类之间的关系。
    建模：通过将用户的业务震需求映射为代码，保证代码满足这些需求，代码能方便地回溯需求，这个过程叫建模。
ROSE建模工具
    定义：是一种分析和设计面向对象的建模工具。
    作用：利用ROSE这个工具，我们可以建立用UML的软件系统的模型，面目可以自动生成和维护C++、JAVA、VB、PB、ORACLE等语言和系统的代码。
    核心：七大框图
    1. Use-Case Diagrams（用例框图）
    2. sequence diagram （顺序框图）
    3. Collaboration diagram （协作框图）
    4. Class diagram （类框图）
    5. State Transition diagram （状态框图）
    6. Component diagram （组件框图）
    7. Deployment diagram （扩展框图）
    下面结合软件工程知识、利用ROSE建模工具，本人在开发电力部们的"110KV标准设计图文管理系统"中所用到的ROSE模型及对ROSE在开发实践中的剖析
一、 需求分析阶段
    任务：建立用户需求和功能模块，确定系统中的角色和使用案例。利用ROSE，生成角色，使用案例和生成用例图
所用到的框图：
    1.Use-Case Diagrams：显示使用案例（表示系统功能）与角色（人或系统）间的交互。如下图：

    Use Case（用例）：在不展现一个系统或系统内部结构的情况下，对系统或系统的连贯的功能单元的定义和描述。
角色：使用软件的人或外部系统本身。
2. sequence diagram
    按时间先后顺序，从上到下分析使用案例，确定案例的处理流程。如下图：

3 Collaboration diagram ：
    确定对象之间的关系的处理过程的分析流程。如下图：

二、 概要设计阶段
    任务：通过分析Use-Case Diagrams ，得到所用到的类，分析这些类的属性、操作和它们之间的关系。
    所用到的框图：
1.Class Diagrams.
    显示系统中类与类之间的交互。

2.包：具有一些共性的类组合在一起的图。

三、 详细设计阶段
    任务：细化和个性Use-Case的描述 ，如类的操作和对象之间的消息相对应，填充参数及复杂的类的设计。
    所用到的框图：
1.Class Diagrams
2.State Diagrams:显示一个对象从生成到删除的生命周期。
四、 编码和测试阶段
    任务：进行软件的开发和测试，生成组件框图。
    组件：表示代码的物理模块。
    组件框图：表示系统中的组件及相互依赖性。
    Delpoyment Diagrams:显示网络中的物理布局和各种组件的位置。

双向工程
    1.生成代码：根据选择开发应用程序的语言生成对应的程序的代码。
    步骤：检查模型-生成组件-将类映射组件-设置代码生成属性-选择类、组件和包-生成代码
    2.逆向转出工程：根据选择开发应用程序的语言生成对应的程序的代码。
    步骤：检查模型-生成组件-将类映射组件-设置代码生成属性-选择类、组件和包-生成代码


Rational Rose介绍材料

提起建模,每一位软件开发人员都不会陌生,但我们还是要给它一个明确的定义:建模是人类对客观世界和抽象事物之间联系的具体描述.在过去的软件开发中,程序员利用手工建模,既耗费了大量的时间和精力又无法对整个复杂系统全面准确的描述,以至于直接影响应用系统的开发质量和速度.而今,我们不再为建模苦恼.

Rational公司曾以Ada语言享誉世界,今天以面向对象的可视化建模工具Rational ROSE博得了业界一片好评.正如美国《应用程序开发战略》Yourdou教授所评价的：“Rational Rose 将对面向对象应用程序开发技术产生巨大影响；使大型开发项目的分析，建模、设计规范化了，——rational公司已成为OO CASE界的Microsoft。”

Rational ROSE包括了一体化建模语言（UML），OOSE及OMT。其中一体化建模语言（UML）由Rational 公司三位世界级面向对象技术专家Grady Booch,Ivar Jacobson和Jim Rumbaugh通过对早期面向对象研究的设计方法的进一步扩展而得来的，为可视化建模软件奠定了坚实的理论基础。

< ----

今天，Rational Rose 作为Rational公司的又一个旗舰产品，由太平洋软件（中国）有限公司和美国Rational Software公司连手引入中国，通过共同建立的Rational（中国）有限公司向中国广大用户推荐，我们希望它能为提高中国计算机应用水平作出应有的贡献！---- >

1。可视化：设计的关键所在

计算机技术的飞速发展创造了人类历史上新的奇迹，但是，随着现代软件工程的复杂程度不断提高，项目失败的可能性也相应的境加了。信息系统的专家们发现当他们面对越来越多的源代码的时候，脑海中系统模型及其内部的联系也越发混沌和模糊了。面对现代社会庞大而繁杂的信息事务，专家们渴望使信息变得简单易懂。

无论何种复杂程度的工程项目，设计者都是从建模开始的，设计者通过创建模型和设计蓝图来描述系统的结构。比如说，电子工程设计人员使用惯用标记和示意图进行复杂的系统的最初设计，会计总是在表格上规划公司的财务蓝图，而行政管理人员则常使用组织流图这种可视化的方式来描述所管理的部门。

正是因为感到无法对整个复杂的系统全面地把握，所以我需要建模。人对复杂性的认识是有局限性的，对程序员来说，仅仅几行源代码是不能对整个开发项目提供一个全面认识的，而模型则可以使设计者从全局上把握系统及其内部的联系，而不至于陷入每个模块的细节之中。

建模的意义重大，“分而治之”，这是一个古老而有效的概念。可以想象，当我们把特别复杂而困难的问题细化分解之后，一次只是设法解决其中一个的时候，事情就容易解决多了。模型的作用就是便复杂的信息关联简单易懂得，它使我们容易洞察复杂堆砌而成的原始数据背后的规律，并能有效地使我们将系统需求映射到软件结构上去。

1.1设计的三层结构

Rose支持三层结构方案。

客户机/服务器体系结构的广泛使用预示了系统复杂化的发展趋势，为了解决这一问题，与之相应的三层结构方案（three-tiered)越来越得到了广泛的应用。

传统的两层结构不是“胖客户机”就是“胖服务器”，胖客户机结构将事务处理原则在用户端处理，胖服务器则将之集成在数据库中，大量的数据流动为维护和编程带来了极大的困难，而且，其中包含的事务处理原则不能与其它应用共享。

三层结构方案是指由用户接口层、事务处理原则层和数据层的应用模型。与传统的两层结构相比，它有着更多的优点：

对应用结构任意一层做出修改时，只对其它层产生极小的影响。
固有的可塑性，三层既可共存于单机之中，也可根据需要相互分开。
公用代码数据库使事务处理规则在系统中共享。

1.2 新的挑战

新的解决方案也相应带来了新的挑战：

开发者必须采用新的思维方式划分和实现应用系统。
可重用的对象必须能被辩识和精炼。
必须决定如何把对象分配给组件和组件在网络（包括Internet)上如何分布。
应用程序必须不断地跟上业务需求的变化。
开发团体必须紧密配合开发应用程序。
基于组件的开发方式正在改变着应用项目的特性。
随着应用系统的开发变得不断复杂，即便是小的应用系统也包括多个分系统和多种组件，如何处理好复杂性的问题是关系到是否能够正确建立系统的关键。

好的软件结构和流程能够帮助开发者正确地解决这一问题，一个完好的结构可使开发过程飒爽流畅，并方便地随着需求的变化而改变。

2.什么是建模？

建模是使你逐层深入解决问题的方法：

确认应用系统的功能需求并为事务处理原则建模
对抽象的对象映射需求，辩认和提供设计模版并创建惯用的模版
分辨和设计对象或划分三层模型的服务
对软件的组成部分映射成对象并设计组件在网络上如何分布
以上工作写入白版文档，建模允许处理发生变化，通过建立抽象概念，设计者就可以有效地处理大型工程和复杂结构。建模建立起应用程序的客户和编程人员之间生动的联系。

3. 用Ratioal ROSE 实现建模

创建模型是帮助设计者实现任何复杂的工程项目的有力工具，在软件工程中，它能够把模型与实际应用紧密地联系起来。通过模型与代码之间的映射，可以直接为不同的程序开发环境生成系统结构的框架，通过建立模型和代码间的映射，可以确保代码改进时模型也随之更新了，而且通过模型与代码间自动连接，建模工具可以确保良好的设计实施。

3.1 何时需要建模

在应用开发的任何阶段进入建模工作都是有意义的，无可否认的是，在设计最初阶段，应将精力主要用于处理有关应用系统用途、为实现用途应采用何种编程环境，而不是考虑程序的细节，如在屏幕上的什么位置放置按钮等。

在项目开发的中期引入建模也是非常有意义的，Ratioal Rose既支持正向建模，同时也支持反向建模。Rose通过建立模型使开发人员把握程序开发的方向，准确完成需求分析中所要求的任务。

3.2 Rational ROSE的解决方案

Ratioal Rose产品为大型软件工程提供了可塑性和柔韧性极强的解决方案：

强有力的浏览器，用于查看模型和查找可重用的组件
可定制的目标库或编码指南的代码生成机制
既支持目标语言中的标准类型又支持用户自定义的数据类型
保证模型与代码之间转化的一致性
通过OLE连接，Ratioal Rose图表可动态连接到Microsoft Word中
能够与Rational Visual Test,SQA Suite和SoDA文档工具无缝集成，完成软件生命周期中的全部辅助软件工程工作
强有力的正/反向建模工作
缩短开发周期
降低维护成本

3.3 一体化建模语言

如果没有一个被普遍认可的国际标准，事情就会陷入混乱之中。Rational Rose提供对工业标准标记的独家支持，其中包括一体化建模（UML），这一即将在工业界成为标准的面向对象建模语言。一体化建模语言（UML）是早期面向对象研究和设计方法的进一步扩展，由世界级面向对象技术知名专家Grady Booch,Ivar Jacobson和Jim Rumbaugh对Booch,OOSE和OMT理论的研究基础上提出的，为可视化建模软件奠定了坚实的理论基础。一体化建模语言对建模语言提供了以下支持

使用事件模型
类和对象模型
组件模型
分布处理模型
Rational Rose产品在支持UML的同时，也支持OOSE及OMT。

3.4 Rationa Rose 对大型复杂项目的支持

Rational Rose支持绝大多数软件工程常见的个人/公共工作平台。直到所编制软件共享之前，软件工程师都可以在个人工作平台修改自己的源代码和已建立的模型。

在公共平台，通过在配置管理和版本控制系统（CMVC），模型改变可以共享，换句话说，其他开发可以观察和利用这些改变。

Rational ROSE能够与主要的CMVC工具集成。

Rational Rose也可支持企业级数据库。

4. Rational Rose系列产品

Rational Rose可视化开发工具与多种开发环境无缝集成，目前所支持的开发语言包括：Visual Basic,Java,PowerBuilder,C++,Ada,Smalltalk,Fort等。

Rational Rose的所有产品支持关系型数据库逻辑模型的生成，包括：Oracle 7,Sybase,SQL Server,Watcom SQL和ANSI SQL，其结果可用于数据库建模工具生成逻辑模型和概念模型，如：LogicWorks Erwin 和Powersoft和S-Designor。

Rational Rose系列产品可以支持：

工业级的功用分析
存储库和个人工作平台
CORBA-2/IDL的正向工程
用户自由选择Booch 93,OMT和UML标记
扩充的接口允许Rational Rose既充当OLE服务器又充当OLE控制器
ROSE脚本是一种与VBA兼容的脚本语言并且兼容Rose API,允许你创建GUI，功能单元和全定制的报告以及控制其他应用。
支持的平台
Windows 9X,NT ,Alpha NT, SGI,Solaris,AIX,Digital UNIX和HP-UX


ROSE技术白皮书

一、前 言

提起建模，每一位软件开发人员都不会陌生，但我们还是要给它一个明确的定义：建模是人类对客观世界和抽象事物之间联系的具体描述。在过去的软件开发中，程序员利用手工建模，既耗费了大量的时间和精力又无法对整个复杂系统全面准确的描述,以至于直接影响应用系统的开发质量和速度。而今，我们不再为建模苦恼。

    Rational公司曾以Ada语言享誉世界，今天又以面向对象的可视化建模工具Rational ROSE博得了业界一片好评。正如美国《应用程序开发战略》Yourdou教授所评价的：“Rational Rose将对面向对象应用程序开发技术产生巨大影响；使大型开发项目的分析，建模、设计规范化了，……Rational公司已成为OO CASE（面向对象）界的Microsoft。”

    Rational ROSE包括了一体化建模语言（UML），OOSE及OMT。其中一体化建模语言（UML）由Rational公司三位世界级面向对象技术专家Grady Booch，Ivar Jacobson和Jim Rumbaugh通过对早期面向对象研究和设计方法的进一步扩展而得来的，为可视化建模软件奠定了坚实的理论基础。

二、可视化：设计的关键所在

计算机技术的飞速发展创造了人类历史上新的奇迹，但是，随着现代软件工程的复杂程度不断提高，项目失败的可能性也相应的增加了。信息系统的专家们发现当他们面对越来越多的源代码的时候，脑海中系统模型及其内部的联系也越发混沌和模糊了。面对现代社会庞大而繁杂的信息事务，专家们渴望使信息变得简单易懂。

无论何种复杂程度的工程项目，设计都是从建模开始的，设计者通过创建模型和设计蓝图来描述系统的结构。比如说，电子工程设计人员使用惯用标记和示意图进行复杂的系统的最初设计，会计总是在表格上规划公司的财务蓝图，而行政管理人员则常使用组织流图这种可视化的方式来描述所管理的部门。

正是因为感到无法对整个复杂的系统全面地把握，所以我们需要建模。人对复杂性的认识是有局限性的，对程序员来说，仅仅几行源代码是不能对整个开发项目提供一个全面认识的，而模型则可以使设计者从全局上把握系统及其内部的联系，而不至于陷入每个模块的细节之中。

建模的意义重大，“分而治之”，这是一个古老而有效的概念。可以想象，当我们把特别复杂而困难的问题细化分解之后，一次只是设法解决其中一个的时候，事情就容易解决多了。模型的作用就是使复杂的信息关联简单易懂，它使我们容易洞察复杂堆砌而成的原始数据背后的规律，并能有效地使我们将系统需求映射到软件结构上去。

二、可视化：设计的关键所在

1、设计的三层结构

客户机/服务器体系结构的广泛使用预示了系统复杂化的发展趋势，为了解决这一问题，与之相应的三层结构方案(three-tiered)越来越得到了广泛的应用。

传统的两层结构不是“胖客户机”就是“胖服务器”，胖客户机结构将事务处理原则在用户端处理，胖服务器则将之与集成在数据库中，大量的数据流动为维护和编程带来了极大的困难，而且，其中包含的事务处理原则不能与其它应用共享。

三层结构方案是指由用户接口层、事务处理原则层和数据层的应用模型。与传统的两层结构相比，它有着更多的优点：

对应用结构任意一层做出修改时，只对其它层产生极小的影响。

固有的可塑性，三层既可共存于单机之中，也可根据需要相互分开。

公用代码数据库使事务处理规则在系统中共享。

2、新的挑战

新的解决方案也相应带来了新的挑战：

开发者必须采用新的思维方式划分和实现应用系统。

可重用的对象必须能被辨识和精炼。

必须决定如何把对象分配给组件和组件在网络(包括Internet)上如何分布。

应用程序必须不断地跟上业务需求的变化。

开发团体必须紧密配合开发应用程序。

基于组件的开发方式正在改变着应用项目的特性。

随着应用系统的开发变得不断复杂，即便是小的应用系统也包括多个分系统和多种组件，如何处理好复杂性的问题是关系到是否能够正确建立系统的关键。

好的软件结构和流程能够帮助开发者正确地解决这一问题，一个完好的结构可使开发过程飒爽流畅，并方便地随着需求的变化而改变。

三、什么是建模？

建模是使你逐层深入解决问题的方法：

确认应用系统的功能需求并为事务处理原则建模

对抽象的对象映射需求，辨认和提供设计模版并创建惯用的模版

分辨和设计对象或划分三层模型的服务

对软件的组成部分映射成对象并设计组件在网络上如何分布

以上工作写入白版文档，建模允许处理发生变化，通过建立抽象概念，设计者就可以有效地处理大型工程和复杂结构。建模建立起应用程序的客户和编程人员之间生动的联系。

四、用Rational ROSE实现建模

创建模型是帮助设计者实现任何复杂的工程项目的有力工具，在软件工程中，它能够把模型与实际应用紧密地联系起来。通过模型与代码之间的映射，可以直接为不同的程序开发环境生成系统结构的框架，通过建立模型和代码间的映射，可以确保代码改进时模型也随之更新了，而且通过模型与代码间的自动连接，建模工具可以确保良好的设计实施。

1、何时需要建模？

在应用开发的任何阶段进入建模工作都是有意义的，无可否认的是，在设计最初阶段，应将精力主要用于处理有关应用系统用途、为实现用途应采用何种编程环境，而不是考虑程序的细节，如在屏幕上的什么位置放置按钮等。

在项目开发的中期引入建模也是非常有意义的，Rational Rose既支持正向建模，同时也支持反向建模。Rose通过建立模型使开发人员把握程序开发的方向，准确完成需求分析中所要求的任务。

2、Rational ROSE的解决方案

Rational Rose产品为大型软件工程提供了可塑性和柔韧性极强的解决方案：

强有力的浏览器，用于查看模型和查找可重用的组件；

可定制的目标库或编码指南的代码生成机制；

既支持目标语言中的标准类型又支持用户自定义的数据类型；

保证模型与代码之间转化的一致性；

通过OLE连接，Rational Rose图表可动态连接到Microsoft Word中；

能够与Rational Visual Test、SQA Suite和SoDA文档工具无缝集成，完成软件生命周期中的全部辅助软件工程工作；

强有力的正/反向建模工作；

缩短开发周期；

降低维护成本

3、一体化建模语言

如果没有一个被普遍认可的国际标准，事情就会陷入混乱之中。Rational ROSE提供对工业标准标记的独家支持，其中包括一体化建模语言（UML），这一即将在工业界成为标准的面向对象建模语言。一体化建模语言（UML）正是为了适应企业级复杂开发中对重用、结构和扩展能力的严格要求而设计的建模语言。

一体化建模语言（UML）是早期面对对象研究和设计方法的进一步扩展，由世界级面向对象技术知名专家Grady Booch,Ivar Jacobson和Jim Rumbaugh对Booch标记、OOSE标记和OMT标记理论的研究基础上提出的，为可视化建模软件奠定了坚实的理论基础。一体化建模语言对建模语言提供了以下支持：

使用事件模型

类和对象模型

组件模型

分布处理模型

Rational Rose产品在支持UML的同时，也支持OOSE及OMT。

4、Raional ROSE对大型复杂项目的支持

Rational Rose支持绝大多数软件工程师常见的个人/公共工作平台。直至所编制软件共享之前，软件工程师都可以在个人工作平台修改自己的源代码和已建立的模型。

在公共平台，通过在配置管理和版本控制系统（CMVC），模型改变可以共享，换句话说，其他开发者可以观察和利用这些改变。

Rational ROSE能够与主要的CMVC工具集成，包括Rational Summit/CM,Microsoft SourceSafe,PVCS,ClearCase,SCCS以及CVS/RCS.

Rational ROSE也可以支持企业级数据库，同时支持Unisys的通用的存储库（UREP）和Microsoft的存储库。

Rational ROSE在支持框架结构的同时，还支持可重用类组件部分，将可重用基类放入公控单元整个团队或其他工作组就可以使用它们了。

五、一体化建模语言（UML）

一体化建模语言（Unified Modeling Language）是Rational软件公司世界级知名专家Grady Booch、Ivar Jacobson和Jim 　　Rumbaugh三人联合开发成功的。开发过程中，得到了其他一些学术领先的方法论学者、软件厂商及众多用户的帮助和支持。在Booch标记法、OMT标记法及OOSE/Jacobson标记法得到广泛应用的基础上，UML将面向对象的分析设计技术又向前推进了一大步。

UML为应用程序建模语言提供了以下支持：

使用事件模型

使用事件模型已成为工业领域首选的分析技术。使用事件确定了商业运行过程中的商业规则和任务，特别是解释了这些任务是怎样由一个应用程序系统来支持的。

使用事件技术满足了系统的功能要求,使用户能够将这些要求映射到对象模型中。

使用对象技术有效的架起了系统分析人员、用户及应用程序开发人员之间交流沟通的桥梁。

类和对象模型类和对象模型

商业对象确定了应用程序的结构基础，用户可以在应用领域里重复使用商业对象，也可以将商业对象从使用事件或应用领域中直接识别并提取出来。

UML既支持基类和对象模型，也支持高级的类和对象模型。通过一体化建模语言，用户可以用类模型来确定商业对象和应用程序结构，可以建立对象，作为类的实例来显示类是怎样活跃地交互作用并提供使用事件和应用行为的。对象模型确定各种各样的类所要求的行为，以确保使用事件和商业规则能得到正确的支持。

类模型确定商业对象和应用对象的结构细节，类奠定了代码生成和数据库定义生成的基础。

类的定义及其相互关系被集中在程序包中，以确定应用程序的结构。程序可能是成套的，其相互间的关系决定了应用程序的独立性及程序结构的易变性。

组件模型

组件模型是源代码的实际单元，也就是组成应用程序的可执行单元。类被分配到组件中，以提供可重复使用的应用程序结构部件。这些组件将为即插即用的应用程序结构奠定基础。

一体化建模语言中的重复使用在前期编译阶段和后期编译阶段都的到支持。前期的支持有可重复使用的类或架构，后期则有组件装配。

分布处理模型

处理模型可以模拟演示应用程序是如何被映射到一个分布处理结构中的。

各种网络拓扑结构都可以模拟出来，包括客户/服务器、三层结构、Internet/Intranet以及广域交流网络中拓扑结构的节点，以及这些节点是怎样相互连接、应用程序在网络中是怎样分布的。


基于ROSE的Web Service建模

曹伟（来自软件工程专家网中国系统分析员协会（CSAI）
2003年01月02日

第一部分 使用UML为Web Service架构建模

作者注：

    此部分根据RUP的资料进行整理，作者将此部分为序言，逐步分析以UML建模的实现Web Service架构，以下的将采用以WebLogic提供服务，基于Java实现为例说明。此部分作者直接引用资料或相关图片知识产权属于RUP提供商。

    近年来，IT 词汇表中出现了一条新的术语，它就是"Web 应用程序"。参与业务软件系统的所有人似乎都有构建 Web 应用程序的计划，而在与业务不相关的软件方面也有很多人对此感兴趣。对于很早前就采用这种构架的许多人来说，Web 应用程序这个词象系统本身一样，已经从成功的小型 Web 站点插件发展成了强壮的 n 层应用程序。Web 应用程序可以同时为分布在世界各地的、成千上万的用户提供服务，这种情况早已司空见惯。构建 Web 应用程序是一件严肃的事情。

    在实际应用中，Web 应用程序这个词对不同的人而言含义略有不同。一些人认为凡是用到 Java 的都是 Web 应用程序，而另一些人则认为凡是使用 Web 服务器的都是 Web 应用程序。多数人的意见介于这两者之间。站在本文的角度，我们将 Web 应用程序大体定义为 Web 系统（Web 服务器、网络、HTTP、浏览器），在这个系统中，用户的输入（导航和数据输入）会影响到业务状态。该定义试图将 Web 应用程序确立为一个具有业务状态的软件系统，并且它的"前端"基本上是通过 Web 系统传递的。

    Web 应用程序的总体构架是一个客户机服务器系统，但二者有几点显著的区别。Web 应用程序最重要的优点之一在于它的部署。部署 Web 应用程序通常指的是建立网络的服务器端构件。客户端不需要特别的软件或配置。两者的另一个重大差异在于客户机和服务器通信的本质。Web 应用程序的基本通信协议是 HTTP，这是一个无连接协议，它不是为最大的通信吞吐量设计的，而是为强壮性和容错而设计的。在 Web 应用程序中，客户机和服务器的通信通常围绕 Web 页导航进行，而不是在服务器端和客户端对象之间直接通信。在一定的抽象程度上，Web 应用程序中所有的信息传递都可描述为 Web 页实体的请求和接收。通常所说的 Web 应用程序构架与动态 Web 站点的构架并无太大区别。
Web 应用程序与 Web 站点，甚至是与动态 Web 站点的区别都要涉及到使用。Web 应用程序实现的是业务逻辑，它的使用改变了业务的状态（其状态为系统捕获）。这是很重要的，因为它确定了建模工作的重点。Web 应用程序执行业务逻辑，因此大多数重要的系统模型都侧重于业务逻辑和业务状态，而不是表示细节。表示很重要（否则系统将毫无用处），不过应尽量将业务和表示所关注的问题区分开。如果表示问题是重要的，甚至是复杂的，那么也需要对它们建模，但不必将它们作为业务逻辑模型的构成部分。此外，用于表示的资源更注重外观设计，而与实施业务规则关系不大。

    关系管理方法 (RMM) 是与 Web 系统开发有关的一种方法/表示法。RMM 是一种用于设计、构建和维护 Intranet 及 Internet Web 系统的方法。它的根本目标是降低动态数据库驱动的 Web 站点的维护成本。它提倡系统进行形象化表示，以便展开设计上的讨论。它是一个迭代式过程，包括 Web 页可视元素的分解，及这些元素与数据库实体的关联关系。RMM 是一种用于动态 Web 站点创建和维护的"完整详尽"的方案。

    不过，在构建 Web 应用程序方面 RMM 就显得无能为力了。Web 应用程序以业务逻辑为中心，它包括了许多实施业务逻辑的技术机制，而这些内容在 RMM 表示法中并未充分说明。客户端脚本编写、Applet 和 ActiveX 控件等技术为促进系统业务规则的执行发挥了重大作用。另外，Web 应用程序还可用作分布式对象系统的交付机制。Applet 和 ActiveX 控件可以包含那些独立于 Web 服务器，通过 RMI 或者 DCOM 与服务器端构件异步交互的构件。复杂应用程序还可利用多个浏览器实例和客户机上的框架，建立并维护自己的通信机制。

    既然所有这些机制都对系统的业务逻辑有促进作用，因此同样也需要为它们建模。而且，由于它们只表示部分业务逻辑，它们需要与其余的系统模型集成。在很多情况下，大部分业务逻辑在 Web 服务器后、服务器端的某一层执行。建模语言和表示法的选择通常要按照这一端的应用程序的需要来决定。随着 UML 作为一种正式的对象建模语言被 OMG 所接受，越来越多的系统开始用 UML 表示。许多人选择 UML 作为软件密集型系统的建模语言。于是 Web 应用程序建模的主要问题变成了："如何在应用程序的其余部分表示在特定 Web 构件中执行的业务逻辑？"答案取决于我们用 UML 在那些特定的 Web 元素和技术中表示系统业务逻辑执行的能力。

    本文旨在简要介绍 Web 应用程序建模存在的问题和可能的解决方案。其中着重讲述在构架上对 Web 应用程序有重要意义的构件，以及如何使用 UML 对它们进行建模。本文假定读者熟悉 UML、面向对象技术的原理和 Web 应用程序开发。文中描述的工作基于一些无偏向性的假设。

    · Web 应用程序是日益复杂的软件密集型系统，它们在关键的任务中发挥着越来越重大的作用。

    · 管理软件系统复杂性的一种方法是对它们进行抽象和建模。

    · 软件系统一般有多个模型，每一个模型代表一个不同的观点、不同的抽象和详细级别。

    · 哪个抽象和详细级别是合适的，这取决于开发流程中的工件和角色活动。

    · 软件密集型系统的标准建模语言是统一建模语言 (UML)。

建模

    通过简化一些细节，模型可以帮助我们理解系统。如何选择建模对象对理解问题和提供解决方案有重大影响。Web 应用程序与其他软件密集型系统一样，通常由用例模型、实施模型、部署模型、安全模型等一组模型来表示。Web 系统还另有一个专用模型，即站点图。站点图是对贯穿整个系统的 Web 页和导航路线的抽象。

    目前采用的大部分建模方法都适用于各种 Web 应用程序模型的开发，因而无需对它们进行进一步的讨论。不过，有一个非常重要的模型，分析/设计模型 (ADM)，在尝试将 Web 页、与其相关的可执行代码和其他元素纳入模型时，确实出现了一些困难。

    在决定如何建模时，确定正确的抽象和详细级别对于是否能让模型用户享受到建模带来的好处至关重要。一般而言，最好对系统的工件建模。工件就是那些为生成最终产品而构建和操纵的真实生活中的实体。对 Web 服务器的内部构件建模，或者对 Web 浏览器的具体构成部分建模，这对于 Web 应用程序的设计员和构架设计师并没有什么帮助。页、页之间的链接、构成页的所有动态内容，以及在客户机上出现过的页的动态内容，对这些建模才是重要的，而且是非常重要的。设计员设计的、实施员实施的正是这些工件。页、超链接、客户机和服务器上的动态内容正是需要建模的对象。

    下一步是将这些工件映射到建模元素。例如，超链接自然映射到模型中的关联关系元素。超链接代表了从某一页到另一页的导航路径。将这种思路进行扩展，页就可以映射到模型逻辑视图中的类。如果 Web 页是模型的一个类，那么页的脚本自然就映射为这个类的操作。脚本中的所有页范围 (内的) 变量映射为类属性。Web 页可能包括一套在服务器上执行的脚本（准备页的动态内容），以及另一套完全不同的只在客户机上执行的脚本（如 JavaScript），考虑到这一点时，一个问题就出现了。在这种情况下，当我们查看模型中的 Web 页类时，我们搞不清楚在准备页的过程中哪些操作、属性甚至关系在服务器上处于活动状态，而当用户与页交互时哪些在客户机上处于活动状态。另外，Web 应用程序中传递的 Web 页最好是作为系统构件建模。简单地将 Web 页映射到 UML 类不会对我们理解系统有所帮助。
UML 的创始人意识到总会存在这样的情况：初始的 UML 不足以获取一个特定领域或构架的相关语义。为了解决这个问题，他们确定了一种正式扩展机制，允许实践者扩展 UML 的语义。该机制允许定义可应用到模型元素的构造型、标注值和约束。

    构造型是一种修饰，允许我们为建模元素定义新的语义。标注值是可以与建模元素相关联的键值对，允许我们在建模元素?quot;标注"任何值。约束是定义模型外形的规则。它们可表示为任何形式的文本，或者用更正式的对象约束语言 (OCL) 表示。

    本文讨论的工作引入了为 Web 应用程序所作的一种 UML 扩展。这种扩展从整体上看超出了本文的范围，然而这里还是讨论了其中大部分的概念和解释。

    关于建模最后还要注意一点，一定要明确区分业务逻辑和表示逻辑。对于典型的业务应用程序而言，只有业务逻辑才应成为 ADM 的一部分。表示细节，如动画按钮、浮动帮助和其他 UI 增强方式通常不属于 ADM。如果为应用程序单独构建一个 UI 模型，则可在其中纳入表示细节。ADM 需要始终将重点放在业务问题和解决方案的表达上。在今天这个 Web 设计师的时代，对 Web 页外观的设计和实现最好由专业人员（技术绘图师）取代传统的开发人员来完成。

Web 应用程序构架

    Web 应用程序的基本构架包括浏览器、一个网络和一个 Web 服务器。浏览器向服务器请求"Web 页"。每一页都是内容和以 HTML 表达的格式指令的组合。一些页包括客户端脚本，它们由浏览器解释。这些脚本为显示的页定义了其他动态行为，而且它们经常与浏览器、页内容和页中包含的其他控件（Applet、ActiveX 控件和插件）交互。用户查看页中的内容，并与其交互。有时，用户在页的字段元素中输入信息，并提交给服务器处理。用户还可以通过超链接导航到系统的其他页，与系统进行交互。无论是哪种情况，用户都在向系统提供输入，这样就可能改变系统?quot;业务状态"。

    从客户端来看，Web 页总是一个采用 HTML 格式的文档。然而在服务器端，"Web 页"可表现为多种形式。在最早的 Web 应用程序中，动态 Web 页用公共网关接口 (CGI) 构建。CGI 定义了一个供脚本和已编译模块使用的接口，它们通过该接口访问与页请求一起传递的信息。在基于 CGI 的系统中，通常在 Web 服务器上配置一个特殊的目录，以便针对页请求来执行脚本。在请求 CGI 脚本时，服务器会用解译器（通常是一个 PERL shell）处理或执行相应的文件，以流的形式将输出返回给发出请求的客户机，而不仅仅是返回文件内容（就像处理 HTML 格式的文件时一样）。处理的最终结果是 HTML 格式的流，它会被返回给发出请求的客户机。业务逻辑在处理文件的同时在系统中执行。在这段时间内，它能够与服务器端资源（如数据库和中间层构件）交互。

    目前的 Web 服务器已经在这个基本设计上有所改进。它们现在已非常注重安全性，而且包含了一些特性：如在服务器端的客户机状态管理、事务处理集成、远程管理、资源共享等，这里只列举了其中的几种。总的来说，最新一代 Web 服务器处理的都是那些对构架设计师来说非常重要的问题，它们关系到任务至上、可缩放和强壮的应用程序。
根据 CGI 脚本的作用，可以将现今的 Web 服务器分为三大类：脚本页、编译页，以及两者的混合体。在第一类中，客户机浏览器能请求的每一个 Web 页在 Web 服务器的文件系统中都用一个脚本文件来表示。这个文件一般是 HTML 和其他一些脚本语言的混合。对页发出请求后，Web 服务器委派一个可识别该页的引擎对其进行处理，最终结果以格式为 HTML 的流的形式返回给发出请求的客户机。Microsoft 的 Active Server Pages、Java Server Pages 和 Cold Fusion 都属于这一类。

    在第二类中，Web 服务器加载并执行一个二进制构件。这个构件和脚本页一样，有权访问与页请求一起发送的所有信息（表单字段值和参数）。经过编译的代码利用请求的详细信息，并通常要访问服务器端的资源，以生成 HTML 流并返回给客户机。编译页包含的功能往往比脚本页大，尽管并未明确这一规律。通过向编译页请求传递不同的参数，可获得不同的功能。任何一个编译构件实际都可以包含整个目录脚本页的所有功能。Microsoft 的 ISAPI 和 Netscape 的 NSAPI 就是表示这种构架类型的技术。

    第三类指的是那些一旦发出请求即进行编译的脚本页，以后的所有请求都使用编译过的页。只有最初页的内容谋淞耍靡巢呕峤辛硪淮伪嘁搿Ｕ饫嘁辰橛诹榛畹慕疟疽澈透咝У谋嘁胍持洹?

Web 页建模

    Web 页，不管是脚本页还是编译页，都一对一地映射到 UML 中的构件。构件是系统的"物理"可更换部件。模型的实施视图（构件视图）描述了系统的构件及它们之间的关系。在 Web 应用程序中，这个视图描述了系统的所有 Web 页及它们彼此之间的关系（如超链接）。在一定程度上，Web 系统的构件图就相当于站点图。

    由于构件仅仅代表了接口的物理打包方式，它们并不适用于对页内部的协作关系建模。这一抽象级别仍需要成为模型的组成部分，而且对设计员和实施员而言极其重要。为引入正题，我们可以说每个 Web 页在模型的设计视图（逻辑视图）中都是一个 UML 类，它与其他页的关系（关联关系）即代表了超链接。但如果考虑到任何 Web 页都可能既代表一组只存在于服务器上的功能和协作，同时又代表只存在于客户机上的一组完全不同的功能和协作，那么这种抽象就不成立了。举例来说，使用动态 HTML（客户端脚本）作为部分输出的所有服务器 Web 脚本页都是这样的页。对这个问题的直接反应可能就是为类中的每个属性或操作设计原型，指明它是在服务器端还是在客户端有效。至此，运用模型倒让问题变得复杂了，而我们的初衷是要简化问题。

    一个更好的解决方案是"分别考虑"。从逻辑上讲，服务器端的 Web 页行为与客户端是完全不同的。在服务器上执行时，页有权访问服务器端资源（中间层构件、数据库、文件系统等），即与这些资源具有某些关系。同一页（或者是该页的 HTML 流输出）在客户端有完全不同的行为和关系集。在客户端，脚本页与浏览器本身（通过文档对象模型，即 DOM），以及该页指定的所有 Java Applet、ActiveX 控件或插件相关。对于认真的设计员而言，页还可能与客户机上在另一个 HTML 框架或浏览器实例出现的其他"活动"页相关。

    通过分别考虑，我们就可以用一个类为 Web 页的服务器端建模，用另一个类为客户端建模。我们采用 UML 扩展机制为两者分别定义构造型和图标?quot;server page" 和 "client page"，以此来区分两者。UML 中的构造型允许我们为建模元素定义新的语义。已指定构造型的类在 UML 图中可用定制图标表示，或者仅仅用 ("") 之间的构造型名称说明。图标对概述图很有用，在概述图中，最好使用简单的标记对显示出的类属性和操作进行标注。

    对于 Web 页，构造型指出了类是客户机或服务器上 Web 页逻辑行为的抽象。两种抽象通过两者之间的定向关系相互关联关系。这种关联关系的构造型为："build"，因为可以说服务器页构建了客户机页（图 1）。每个动态 Web 页（即页内容在运行时才能决定的页）都用一个服务器页构建。每个客户机页至多只能用一个服务器页构建，而一个服务器页可以构建多个客户机页。

    Web 页之间通过超链接建立公共关系。Web 应用程序中的超链接代表系统的一条导航路径。这种关系在模型中用一个构造型为 "link" 的关联关系表示。关联关系总是从客户机页出发，指向另一个客户机页或服务器页。

    超链接作为 Web 页请求在系统中实施，Web 页作为实施视图中的构件来建模。指向客户机页的链接关联关系大体等同于指向构建该客户机页的服务器页的链接关联关系。这是因为链接实际是一个页请求，不是上述两种类抽象。由于 Web 页构件同时实现两种页抽象，因此指向由该页构件实现的任何类的链接都是等同的。

    标注值用于定义随链接请求一起传递的参数。"link" 关联关系标注值"Parameters"是一个参数名（和可选值）的列表，处理请求的服务器页要用到它。在图 2 中，SearchResults 页包含数目可变的指向 GetProduct 服务器页的超链接 (0..*),每一个链接都有一个不同的 productId 参数值。GetProduct 页用于构建 productId 参数所指定产品的 ProductDetail 页。

图 1. 服务器页构建客户机页

图 2. 使用超链接参数

    使用这些构造型简化了对页脚本和关系的建模。"server page" 类的操作变为页服务器端脚本的函数，它的属性变为页范围变量（页函数可对其进行全局访问）。"client page" 类的操作和属性也同样变为在客户机上可见的函数和变量。将服务器端页和客户端页作为不同的类考虑，其最大好处在于明确页与系统的其他类之间的关系。客户机页根据它们与客户端资源的关系进行建模。客户端资源有：DOM、Java Applet、 ActiveX 控件和插件（图 3）。服务器页根据它们与服务器端资源的关系进行建模。服务器端资源有：中间层构件、数据库存取构件、服务器操作系统等(图 4)。

图 3. 客户机协作

图 4. 服务器协作

    用类构造型对 Web 页的逻辑行为建模的最大优势在于：页与服务器端构件的协作可以基本上用其他任意服务器端协作所使用的方式来表示。"server page" 仅仅是参与系统业务逻辑的另一个类。上升到概念的层次来讲，服务器页一般扮演控制者的角色，协调必要的业务对象活动，以满足浏览器页请求所提出的业务目标。

    客户端的协作更复杂一些。部分原因可归咎于可用技术的多样性。即使是最简单的客户机页，至少也是一个既包含内容又包含表示信息的 HTML 文档。浏览器利用页的格式指令提供 HTML 页，有时还带有单独的样式表。在逻辑模型中，这一关系可用客户机页对构造型为 "Style Sheet" 的类的依赖关系来表示。样式表基本上是一个表示问题，通常不包含在 ADM 内。

表单

    Web 页的基本数据输入机制是表单。表单在 HTML 文档中用 <form> 标记来定义。每个表单都会指明它自身要提交到哪一页。表单包括许多输入元素，它们全用 HTML 标记表示。最常用的标记是 <input>、<select> 和 <textarea>。输入标记多种多样，它可以是一个文本字段、复选框、单选按钮、按钮、图像、隐藏字段，还有其他一些不太常见的类型。对表单建模要使用另一个类构造型："Form"。"Form" 没有操作，这是因为可能在 <form> 标记中定义的所有操作实际上都为客户机页所有。表单的输入元素都是 "Form" 类的建有构造型的属性。"Form" 可以与作为输入控件的 Applet 或者 ActiveX 控件有关系。表单还与服务器页有关系，服务器页即是处理表单提交内容的页。这种关系的构造型为 "submit"。由于表单完全包含在 HTML 文档内，所以它们在 UML 图中用一种强聚合关系形式表示。图 5 是一个简单的购物车页，它定义了一个表单，显示了与要处理表单的服务器页的提交关系。

图 5. 表单提交给服务器页

    在图 5 中，以 "JavaScript" 为构造型的类是一个代表购物车中的商品项的对象。对于可有多种输入可能的字段，它们的表单属性说明中使用了数组语法。在这个例子中，这意味着购物车可以有零到多个项，每个项都有一个 Qty、AllowSubs、Cost 和 Total <input> 元素。

    由于客户机页内的所有活动都用 JavaScript 执行，而 JavaScript 是一种无类型的语言，所以为这些属性指定的数据类型只是为了便于实施员辨认。在 JavaScript 中执行或作为 HTML 输入标记执行时，该类型将被忽略。这对函数参数也成立，函数参数是模型的一部分，尽管本图并未明确显示。

框架

    HTML 框架从刚被引入 Web 站点和 Web 应用程序时就引发了极大的争论，且意见呈两极分化。框架允许在某一时刻有多个页激活，并对用户可见。目前最常用的浏览器还具备一组最新的特性，允许用户机器上同时打开多个浏览器实例。使用动态 HTML 脚本，这些页中的构件可以彼此交互。客户端复杂交互的潜力非常大，使得对此建模的需要变得更大。

    是否在应用程序中采用框架或多个浏览器实例，这要由构架设计师决定。如果决定采用，客户端行为的模型就需要在 ADM 中表示出来，原因如上所述。要对框架的使用进行建模，我们又定义了两种类构造型："frameset" 和关联关系构造型 "targeted link"。框架集类代表一个容器对象，直接映射到 HTML<frameset> 标记。它包含客户机页和目标。目标类是一个被其他客户机页引用的指定框架或浏览器实例。目标链接关联关系是指向另一个页的超链接，但它要在特定目标中才能提供。在图 6 的示例中，浏览器显示了一个使用两个框架的常用大纲视图。一个框架根据目标命名为 Content，另一个框架只包含一个客户机页。这一客户机页框架包含书的目录 (TOC)。该页的超链接是有目标的，因此超链接指向的内容在 Content 框架中显示。得到的效果就是页左侧的一个静态目录，以及页右侧的书中每一章的内容。


Rational Rose技术交流

一、 Rational Rose是什么... 2

二、 Rationla Rose有什么用... 3

三、 Rose的核心——统一建模语言UML. 4

（1）、 UML的发展历程... 4

（2）、 UML(Unified Modeling Language) 的具体内容... 4

1、 用例图... 5

2、 类图... 8

3、 包图... 9

4、 序列图... 9

5、 协作图... 10

6、 状态图... 11

7、 活动图... 11

8、 构件图... 12

9、 部署图... 13

四、 使用Rational Rose进行数据库建模... 15

五、 Rational Rose的一些使用技巧... 16

1、 Units Control 16

2、 Import，Export 17

3、 Add-in Manager 17

4、 Workspace. 19

5、 常用快捷键... 20

6、 Autosize All 20

7、 Options的设置... 21

六、 进一步学习... 22

阐明Rose在Rational产品系列中所处的位置和在整个开发流程中所起的作用，介绍Rose的核心——统一建模语言UML以及从Rose使用的角度进行交流。

一、 Rational Rose是什么

Rational Rose是Rational公司出品的基于UML的可视化建模工具。

当前市场上基于UML可视化建模的工具很多，例如有Microsoft的Visio2002，Oracle的Designer2000，还有PlayCase 、CA BPWin、CA ERWin、Sybase PowerDesigner等等。

为什么要选择Rational Rose呢？这就不能不提到UML的三位创始人了，面向对象领域的大师级人物：Booch、Rumbaugh和Jacobson。而这三位大师目前都在Rational公司担任首席工程师，既然UML是业界标准的可视化建模语言，那么选择Rational Rose的原因就不言而喻了。

而且Rose与Rational其他一系列的软件工程方面的产品的紧密集成使得Rose的可用性和扩展性更好。

需求 | 构架（分析/设计） | 建造（编码） | 测试
需求管理 - 收集、管理及传达变更的软件需求和系统需求。 Rational RequisitePro | 可视化建模 - 生成一个反映软件应用程序、其构件、接口和之间关系的图形化的设计图，便于理解和交流。 Rational Rose、Rational Rose RealTime | 编程环境 - Rational Apex、Rational Summit/TM、Rational TestMate、 Rational Ada Analyzer | 软件质量和测试自动化 - 提供集成化编程和测试工具来简化构件的创建，并代替昂贵、冗长且容易出错的手工测试，从而在较短的时间内、在风险已降低的情况下生成更高质量的应用程序。 Rational Suite TestStudio、 Rational Suite PerformanceStudio
配置管理
软件配置与变更管理 - 在创建、修改、构建和交付软件的过程中，控制团队的日常开发。 Rational ClearCase、Rational ClearCase MultiSite、Rational ClearQuest、Rational ClearDDTS
软件流程
软件流程自动化 - 为软件经理和开发人员就如何开发有商业竞争力的软件资产提供指导。 Rational Unified Process、Rational SoDA

上面从左至右是软件生命周期的四个典型环节，下面的配置管理和软件流程是贯穿整个软件生命周期的活动。

目前Rational Rose在中国的市场占有率大约是4成（CSDN的调查统计），在国外的占有率应该会更高。

二、 Rationla Rose有什么用

前面已经说过了，Rational Rose是基于UML的可视化建模工具，那首先要看看UML有什么用了。UML全称叫Unfied Modeling Language，顾名思义，UML是一种语言，一种表示法，就是一种交流沟通的工具，特别适用于软件密集型系统的表示。

UML的统一性（Unified）表现为以下几点：

（1）、 UML是人类思想和计算机代码的一个连接桥梁

大家都知道，计算机能直接识别的语言就是二进制的CPU指令，早期工程师门都是直接写这些指令输入给计算机直接执行的，非常痛苦;

后来就出现了更好理解的汇编语言，之后就出现了各种各样更加容易理解和编写，更加接近人类语言的计算机高级语言，什么VB啊、DELPHI、JAVA等等。

所以从一个角度来看，其实计算机软件的发展史，可以算是一个解决计算机语言和人类语句差异性问题的历史，就是说如何让开发语言更加接近人类语言。

看看下面的一个图：

人类思想

UML

VB、DELPHI、JAVA等等。。

二进制代码

这图可以看出UML是人类思想和计算机代码的一个连接桥梁。

（2）、 UML所定义的概念和符号可用于软件开发的分析、设计和实现的全过程，软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。

（3）、 UML所用的语言元素基本都是图形化的，便于理解和沟通，不但开发人员之间可以用来交流，客户和开发人员之间也可以用它作为交流的工具。

目前版本的Rational Rose可以用来做以下一些工作：

1、对业务进行建模（工作流）；

2、建立对象模型（表达信息系统内有哪些对象，它们之间是如何协作完成系统功能的）；

3、对数据库进行建模，并可以在对象模型和数据模型之间进行正、逆向工程，相互同步；

4、建立构件模型（表达信息系统的物理组成，如有什么文件、进程、线程、分布如何等等）

5、生成目标语言的框架代码，VB、JAVA、DELPHI


用Rational Rose全景追踪

本教程的目在于给出步进式的使用指导，并且提供一个使用Rational Rose UML CASE 工具创建完整的UML模型的范例。本教程是为那些想高效地使用和评估Rational Rose工具（而不是其他UML CASE 工具）的新用户准备的。作为一个新用户，我们建议做下面的工作：

首先：创建使用Rational Rose CASE 工具（www.rational.com）的图表和报告，如下所示。

第二：使用Rational Rose—— UML CASE 工具在你的问题领域创建一个类似的实例，如一个订单系统、产品系统，客户系统，等等。

第三（如果需要），使用其他 UML CASE 工具创建这些实例，以充分比较不同工具的性能。

我们的目标是创建一个系统的正确、可靠、可理解、可扩展、可复用、完整的UML模型。该模型应该混合了可复用的类、组件和模式。这里提供一个经简化的银行存款模型。

从Rational Rose开始

启动 Rose： 选择菜单File—New，选择File—SaveAs，将文件另存为BusinessModel.然后选择File—New—SaveAs，另存为Requirements-AnalysisModel；注意，当Requirements-Analysis（需求分析）完成后要另存为Design-ImplementationModel（设计－实现模型）；选择View（视图）选中Status Bar,Browser, Documentation, As Unified；选择Tools—Options—Diagram 选中Stereotype Display（构造型显示）标签并选中Show/Display 的所有项目（Three-Tier Diagram除外）；可以在文档窗口（Documentation Window）为每个浏览器元素（Browser element）键入“文档信息”；可以在图上增加文本框（text boxes）“ABC”(译注：ABC 是文本框符号的标志)；可以在图上增加注释；也可以通过“File—Delete”（译注：似乎应是Edit—Delete）从模型中删除不正确的元素。Check Model后，选择Window—Log查看日志文件；可以选择Report—Documentation Report；选择Help,查看Rational Rose Help Topics（帮助主题）。

创建Rose 用例图：在浏览器窗口，选择Use Case View（用例视图），将“Main”重命名为“Use Case Diagram”，在Use Case View双击可以显示用例图，在图上放置参与者（ACTOR）和用例，选择一种关系连接各元素。

user use case

创建Rose 类图：在浏览器窗口选择Logical View（逻辑视图） ，将“Main”重命名为“class diagram”；在Class Diagram上双击以显示类图；在图上放置“类”；选择一个“类”然后按鼠标右键，选择New Attribute键入属性；选择“类”然后按鼠标右键，再选择：“New Operation”键入操作；从工具条中选择“泛化”（Generalization）关系箭头，从子类到超类拖曳，放置一个泛化关系；从工具条中选择实现（Realize）箭头，由实现类向接口拖曳，放置一个实现关系；从工具条中选择关联（Association）箭头从较大/上级类向较小/从属类拖曳，放置一个关联关系；在离较小/从属类最近的关联线上单击鼠标右键，键入角色名及角色多重性；，从工具条中选择菱形的聚合符号，然后从较大/整体类向较小/部分类拖曳，放置一个聚合/组成关系；在到部分类最近的关联线上单击鼠标右键，键入角色名称及角色多重性；从工具条中选择依赖箭头，从源/客户类（source/client class）向目标/供应端（destination/supplier class）拖曳，放置一个依赖（dependency）关系；选择Tools—Check Model；选择Report - Show Usage/Show Instances/Show Access Violations；选择 File - Save.

创建Rose 顺序图：在浏览器窗口选择Logical View；选择Browse—Interaction Diagram—Logical View—<View>；选择Sequence Diagram；键入图名；在图上放置对象（object）以表示类的对象；双击对象并且选择从下拉列表中选择类名；选择Rose 对象消息（Object Message）符并在两个对象间拖曳；双击消息，选择操作。选择Tools - Check Model；选择Report - Show Unresolved Objects/Show Unresolved Messages；选择 File - Save.

使用统一过程生命周期阶段

本教程使用了“统一软件开发过程”。参见《The Unified Software Development Process》（Ivar Jacobson,Grady Booch, James Rumbaugh 著）、《The Rational Unified Process An Introduction Second Edition》（Krutchen著）。统一过程生命周期阶段图示如下：

系统/子系统/组件 | 包/类/对象
Ⅰ－需求 | Ⅱ－分析
需求描述/产品性能 | 类图
所有用例的用例图 | 包图
每个用例场景(scenario)的顺序图 | 顺序图 和/或 协作图
每个用例所有场景的活动图 | 活动图和状态图
Ⅳ－实现 | Ⅲ－设计
过程环境硬件&软件 组件图&部署图 | 过程环境硬件（HW）&软件(SW) 更新的类/包/顺序/协作/活动/状态图

———Ⅴ&Ⅵ 构建/测试

下表中总结了在统一过程中不同的模型：

 | 业务模型 | 需求模型 | 分析模型 | 设计模型 | 实现模型 | 测试模型
关键UML元素 | 业务过程（用例），业务域对象 | 系统，参与者，用例，交互 | 业务包，类，对象，消息 | 硬件&软件配置，包，类，对象，消息 | 组件，节点，编码 | 测试计划和测试实例
主要关注点 | 模型 业务 | 黑盒模型系统 | 问题领域模型的业务元素（不含实现细节） | 更新特定实现的分析图/规约，例如硬件&软件配置 | 分布式环境模型物理元素；对应所有需求的编码 | 单元（类/操作）测试，集成，整个系统测试
目标：元素间弱耦合－强内聚 | 充分的业务/企业信息 | 所有用例/场景的充分信息，所有计划过的增量/迭代。 | 满足需要的最简业务/问题领域模型 | 生成最大量代码或手动编码需要的足够的信息 | 界面友好、最适当的组件架构－网络；满足所有需求的代码 | 编码可满足所有需求的充分测试
静态/结构性图 | 业务领域对象 | 显示参与者的块图和用例图 | 包/类图 | 包/类图 | 组件和部署图；逆向类图 | －
动态的/基于时间的图 | 业务过程（用例） | 每个用例场景的用例图、顺序图，每个用例的活动图 | 每个用例场景的顺序图，基于状态的类的状态图，复杂操作的活动图 | 每个用例场景的顺序图，基于状态的类的状态图，复杂操作的活动图 | 可选地，显示分布式信息的更新顺序图 | －
关键团队成员 | 业务分析员 | 业务分析员 | 业务分析员 | 开发人员 | 架构师，开发人员 | 开发人员/测试人员
模型签认 | 项目经理，架构师，客户 | 项目经理，架构师，客户 | 项目经理，架构师，客户 | 项目经理，架构师 | 项目经理，架构师 | 项目经理，架构师，客户（验收）

建议的任务/练习：基于统一过程创建一个UML模型。

0- 业务建模－企业级

评审业务模型：前景文档，组织结构图，业务事件和过程（用例），业务参与者，工作人员（worker），实体（域模型），业务规则目录,业务接口（操作集），业务模式，业务系统体系结构－组件图，术语表。参见《The Rational Unified Process An Introduction Second Edition》（Krutchen著）及《Business Modeling with UML》（Eriksson 和Penker 著）。

Ⅰ－需求－系统/子系统/组件级（与语言无关的）

1- 需求－对需求描述、系统图（System Drawing）,系统块图(客户提供)进行评审。创建系统协作图[环境图(Context Diagram)]以说明对象/数据的输入输出、设定系统的边界（可选）。创建需求可追踪性表，列出需求名、需求号、引用、用例、UML元素、测试实例、描述、职责，等等（可选）。评审管理计划、时间表、风险、命名/编码标准、方法设计－UML 过程/构造型/特征/约束（可选）。

2- 所有用例－创建用例图说明所有用例。说明用例关系（包含，扩展、泛化）和/或分级用例（从高级到细节）（可选）。确定用例的增量和迭代。

3- 每个用例－为每个用例创建用例规约描述：用例名、触发、输入、输出、前置条件/异常、后置条件/异常，基本的和替代性可选场景【从乐观到悲观（optimistic to pessimistic）】、业务规则。为每个用例场景创建顺序图（可选）。为每个用例创建输入/输出表和测试实例（可选）。

4- 每个用例所有的场景－为每个用例创建活动图说明所有的用例场景（乐观到悲观）。用文本、流程图或其他图说明每个用例的场景/路径（可选）。

5- 信息——创建产品性能（Product Capabilities）列出非功能性的需求：可用性（可靠性、性能、安全、人员因素），一般性（generality）、可移动性、兼容性，时间，空间，存储等等。创建一个语义数据模型（高级类/包图）（可选）。

Ⅱ－分析－类和对象级（与语言无关的）

6- 类和包－创建候选类清单,CRC 卡,类图和包图。创建对象图显示属性值（可选）。

7- 对象和消息－为每个用例－乐观场景创建顺序图。为所有其他用例场景创建顺序图（可选）。或者，为每个用例创建协作图。

8- 状态和转移－为每个基于状态的类创建状态图，说明状态、事件、条件、动作。

9-操作－为每个复杂的操作创建一个操作规约，说明前置条件、转换，后置条件，以及异常。为每个复杂操作创建活动图，说明活动的顺序、状态、条件和动作（可选）。

III –设计-类和对象级（特定的过程环境下的）

10－过程环境－创建由已计划的“实现硬件和软件配置清单”组成的goig过程环境：操作系统，语言，类库，组件，GUI,分布——对象请求代理，永久数据存储，等等。可列出潜在的模式，组件标准（(Active X, Java Bean, CORBA)，命名约定，编码标准，代码生成脚本，工具（CASE, 编译器，配置管理，测试等等）（可选）。

11 –更新的分析图及规约－更新所有图表和说明，为过程环境增加细节，包括数据类型，参数/返回值，支持类，操作细节（前置条件/异常）转换，后置条件/异常），等等。提供了实现模式，例如多态操作，异常（异常的超类/子类），线程，数据访问，事务，安全，消息队列等等。目标是：图和规约为手工编码或代码生成提供正确的信息（可选）。

Ⅳ 实现－系统/子系统/组件级（特定过程环境下的）

12－实施过程环境，组件标准和组件模式－更新过程环境，显示已提供的组件（GUI，数据访问，事务，分布，消息队列，安全等）、组件标准（ActiveX, Enterprise Java Bean,CORBA）、组件到组件模式，例如小的单个操作组件、基于组件的类、每一用户－实体组件，基于组件的包，大的多包组件。

13 –实施组件－创建组件图显示所有需要的带有依赖关系的组件和文件，例如.EXE, DLL, .OCX, .LIB, .TXT, .HLP等等。显示接口（棒棒糖）、创建接口图显示公有操作（exposed operation）（可选）。显示IDL 代码（Interface Definition Language,接口定义语言）例如 CORBA IDL, Microsoft IDL, Java（可选）。

14 – 实施节点（处理器和设备）- 创建部署图，显示所有需要的处理器、设备和其他器材，例如客户网络计算机（NC），Windows PC, NT Server，事务服务器，WEB 服务器，邮件服务器，传真,打印机，网络等。

V -构建

15-编码标准和代码生成脚本－更新编码标准和代码生成脚本.编码标准为所有主要UML元素编码列出了样本代码、关系以及继承策略、接口、异常、线程等。

16 -每个组件的编码、图表逆向工程

VI - 测试

17 –测试计划－更新测试计划，列出测试实例（名称，输入，输出，条件），测试步骤（每一个测试用例的每一步用法），测试组件【驱动器（driver），测试装置（harnesses），脚本】

18 -测试－引导测试(conduct tests),例如类/操作测试（单元测试），个体组件测试（基于用例的），全范围系统-多组件测试（基于用例的集成/验收测试）。

VII - 模型和构建其他需要的组件

19 –图形用户接口/用户/外部接口组件－可选的－创建GUI 组件（窗口，菜单，对话框，面板）

20 –永久存储组件的－可选的－数据存储表/存储过程/触发器。

UML CASE 学习——BankApp (使用Rational Rose)

0－预备－业务企业模型

业务前景，目标，组织－分别提供

业务事件[UML信号事件-指定的激励表格或文档]和过程(UML 用例)

过程名 | 参与者 | 事件/输入 | 转换 | 事件/输出 | 约束 | 描述 | 引用 | 联系点
WithdrawFromAccount | Customer,Teller,BankDB | WithdrawRequest | Update Account | WithdrawRecord |  |  |  |

[译注：Customer：客户；Teller：出纳员；withdraw：取款；account：账户；BankDB：银行数据库]

Business Actors, Business Workers,业务实体（问题域实体）

业务参与者(UML 参与者) | 业务员（UML 参与者） | 业务实体（UML 类）
Customer | Teller | Account,SavingsAccount,CheckingAccount

[译注：saving：储蓄；checking：支票]

业务规则目录

规则标识符 | 参与者，实体，过程 | 描述：If 条件.. then 动作 | 区域 | 引用 | 联系点（Point of Contact）
ValidAccount | Account | If AccountNum 有效,then Acccount 有效 |  |  |

业务接口（指定操作集）－由架构师提供

业务模式目录－参见《Business Modeling with UML》（Eriksson 和Penker 著）。

业务术语－待完备

业务系统体系结构－由架构师提供

Ⅰ－需求模型

1 -需求：BankApp应该管理支票和存款账户的存款和取款。将来（还要提供）查询，转账，透支，等等从TellerGUI 到BankApp的输入/输出： sAcctNum, nDeposit, nWithdraw,sText。从BankApp 到BankDB的输入/输出： sAcctNum, nDeposit, nWithdraw.

1 -需求可追踪性表：需求号，名称，引用，用例名，UML元素，测试用例，描述，职责。

需求可追踪性表（部分）

需求编号 | 需求名 | 引用 | 用例名 | UML 元素 | 测试实例 | 描述 | 职责
1.1 | DepositToSavingsAccount |  | DepositToSavingsAccount | BankPkg |  |  |
1.2 | DepositToCheckingAccount |  | DepositToCheckingAccount | BankPkg |  |  |
1.3 | WithdrawFromSavingAccount |  | WithdrawFromSavingAccount | BankPkg |  |  |
1.4 | WithdrawFromCheckingAccount |  | WithdrawFromCheckingAccount | BankPkg |  |  |

2-需求－用例图－所有用例

Rose 用例图：在浏览器窗口，选择Use Case View；Main Use CaseDiagram；在图上放置参与者，用例，关系[Rose单向关联（Unidirectional Association）],泛化；选择每一个参与者－单击鼠标右键键入参与者的操作；选择Tools-Check Model；选择File-Save.

2-需求－高级别协作图[环境图（Context Diagram）]：

Rose高级别协作图：在浏览器窗口，选择Use Case View；选择Browse-Interaction Diagram（交互图）-Use Case View-<New>；选择Collaboration Diagram；键入图名；在图上放置对象表示参与者；双击每个对象，然后从下拉列表中选择参与者名；在图的中央放置一个对象以表示系统；双击对象，键入系统名；选择Rose Object Link (对象连接符)并且在参与者和系统之间拖曳；选择Rose 文本框TextBox“ABC” ,键入传递的对象/数据；选择Tools-Check Model；选择File-Save .

2-需求－用例增量

增量1：支票和储蓄账户的存款和取款

增量2：查询和转账

增量3：透支

每个增量内进行迭代：乐观的，正常的，悲观的

3-需求用例规约：名称，触发器，输入参数，输出返回值，出现的前置条件/异常，出现的（raised）后置条件/异常，基本的/乐观场景，替代性可选的/悲观的场景，业务规则，测试实例。

WithdrawFromCheckingAccount用例的用例规约

用例名：WithdrawFromCheckingAccount

触发器： WithdrawFromCheckingAccount

输入参数： sAcctNum, nWithdraw

输出返回值： sText

前置条件： ValidAccount = true and nWithdraw <= nCurrentBalance

出现的前置条件异常： 待定的

描述/转换： nCurrentBalance = nCurrentBalance - nWithdraw

后置条件： nCurrentBalance < nOldBalance

后置条件异常：无

相关用例： Generalization, Includes, Extends/Extension Point： 无

基本场景/乐观场景： Text(文本) – 待定；Diagram（图） -见 WithdrawFromCheckingAccount – Optimistic Scenario

顺序图

替代性可选场景/被动场景：Text -待定；Diagram -见WithdrawFromCheckingAccount 活动图

业务规则： ValidAccountRule, AdequateBalanceRule

测试实例：1 – 乐观的：输入： sAcctNum - BGates001, nWithdraw - 100, nCurrentBalance - 1000 Conditions： None, 输出：

"BGates001 withdraw $100 OK and recorded"；2 ...待定的

输入/输出表单：见下

WithdrawFromCheckingAccount用例的输入/输出表单

Withdraw Request Form（取款需求表单）

Customer Account Number（客户账号）__________

Withdraw Amount（取款数量） ________

Button-Submit（提交按钮） Button-Clear（清除按钮）

Withdraw Response Form（取款响应窗体）

Customer Account Number __________

Withdraw Amount __________

Status （状态） ________________________

Button-OK（OK 按钮）

3 – 需求－顺序图WithdrawFromCheckingAccount – 乐观场景

注：getApp的第一笔事务需要达到应用程序的最高级别

Rose 顺序图：在浏览器窗口，选择Use Case View；选择 Use Case Diagram；选择一个用例；选择Browse-Interaction Diagram-Use Case View-<New>；选择Sequence Diagram；键入图名,例如WithdrawFromCheckingAccount－OptiminticScenario；在图上放置对象以表示参与者；双击每个对象，然后从下拉列表中选择参与者名；

在图的中央放置一个对象以表示系统；双击对象，从下拉列表中键入系统名；选择Rose Object Link (对象连接符)，在参与者和系统之间拖曳；选择Tools-Check Model；选择File-Save .

4-WithdrawFromCheckingAccount用例－所有场景的需求活动图

注：getApp的第一笔事务需要达到应用程序的最高级别

Rose 状态－活动图： 在浏览器窗口，选择Use Case View；选择Use Case Diagram 显示图；选择一个用例；选择Browse - State Diagram；如果"State Diagram" 是灰色，则返回到用例图并重新选择一个用例；在图上放置活动状态（activity states）；通过在两个状态之间拖曳，放置转移；选择Tools-Check Model；选择File-Save .

5 –需求－产品性能：高可靠性，10个并发的用户，2秒响应时间。

5 – 需求/分析－高阶概念模型（HOCM--High Order Concept Model） 外部参与者：TellerGUI,BankDB.内部实体（Internal Entities）： BankApp, Account, CheckingAccount, SavingsAccount

Rose高级别概念模型图： 推荐使用铅笔和纸做HOCM。作为替代，创建不含属性和操作的Rose 类图。

Ⅱ－分析模型－草图

6 – 分析类图 - 最简结构

Rose 类图： 见〈使用Rational Rose〉

6- 分析包图

Rose 包图：在浏览器窗口选择Logical View；选择Browse－Class Diagram－Logical View－<New>。输入包图名；在图上放置包；从工具条中选择依赖箭头然后从源包到目的包拖曳，放置依赖关系。在浏览器中，拖动每个类到适当的包；选择Tools-Check Model；选择File-Save。

7- 分析 WithdrawFromCheckingAccount顺序图－乐观场景

注：getApp的第一笔事务需要达到应用程序的最高级别

Rose 顺序图：见〈使用Rational Rose〉

8- 分析Account类的状态图

Rose 状态－活动图：在浏览器窗口，选择Use Case View；选择Use Case Diagram 显示；选择一个用例；选择Browse - State Diagram；如果 "State Diagram" 是灰色，则返回到用例图并重新选择一个用例；在图上放置活动状态（activity states）；通过在两个状态之间拖曳，放置转移；选择Tools-Check Model；选择File-Save .

9-分析－复杂操作：待定的－每一个操作的活动图 和/或操作规约：名称，输入，前置条件/异常，转换，后置条件/异常，业务规则，描述。

Rose 规约： 显示类图；选择一个类；按鼠标右键显示Specification Dialog Box；选择一个标签，例如Operations；双击一个操作；填写操作信息；选择 Tools - Check Model；选择File - Save.

III – 设计模型 - 编码的基础

10 – 设计过程环境：Linux 6.2版, GNU C++ 6.2版, C++ 标准库,CORBA 3.

10 -设计潜在模式

企业级：基于分布式CORBA，具有公共接口的组件

系统（组件到组件）：分层，会话－实体（Session – Entity），回调（Callbacks），发行者—订阅者（Publisher – Subscriber）

组件：应用－文档，控制器－实体－边界，虚包（Facade）

类设计：UML, Factory（工厂），事务

JAVA 语言：Java Bean, Enterprise Java Bean, Servlet, RMI

11－设计包图

11-设计类图 说明类型和参数-目标是完成编码

注：CheckingAccount和SavingsAccount 提供多态操作的实现。

11-设计顺序图WithdrawFromCheckingAccount – 乐观场景

注：getApp的第一笔事务需要达到应用程序的最高级别

11-设计协作图WithdrawFromCheckingAccount – 乐观场景

在Rational Rose中打开顺序图，按F5 自动创建协作图。

11 – 设计CheckingAccount类withdraw()操作的操作规约

用例名： withdraw

触发：withdraw

输入参数： nWithdraw ： int

输出返回值： boolean

前置条件： nWithdraw <= nCurrentBalance

出现的前置条件/异常： exInsuffientFunds

描述/转换： nCurrentBalance = nCurrentBalance - nWithdraw

后置条件： nCurrentBalance < priorCurrentBalance

后置条件异常： exIncorrectBalance

基本/乐观场景 ：见WithdrawFromCheckingAccount 顺序图

替代性场景/悲观场景：见WithdrawFromCheckingAccount 活动图

业务规则：ValidAccountRule, AdequateBalanceRule

11-设计异常类（exception classes）异常超类(操作：Exception()/Exception(string)；异常子类：exInsufiicientFunds [操作 ：exInsufiicientFunds（）、exInsufiicientFunds（string）]；exIncorrectBalance[操作：exIncorrectBalance()、exIncorrectBalance(string)]。

11-设计 CheckingAccount 类的状态图

Ⅳ 实施模型(Implementation Models)

12-设计过程环境

13－ 实施组件图

实施文件（Implementation Files）： TellerGUI.exe, BankApp.exe, BankDB.exe

组件接口选择：

1) BankApp具有单接口 IbankApp，其所有操作都是公有的（exposed）

2) BankApp暴露（exposes） IBankApp, ICheckingAccount, & ISavingAccount 接口

3) BankApp暴露（exposes） IBankApp, IWithdraw, IDeposit, ICheckingAccount, & ISavingAccount 接口

CORBA IDL/C++ 需要对接口进行描述

Rose 组件图：在浏览器窗口，选择Component View；，将“Main”重命名为“Component View”；双击图名显示该图；在图上放置组件和依赖关系（从client组件到supplier组件拖曳）；在浏览器中把每个类拖到相应的组件中；选择Tools-Check Model；选择File-Save.

14-实施部署图

Rose 部署图：在浏览器窗口选择Deployment View；双击以显示该图；在图上放置节点和关系；选择Tools-Check Model；选择File-Save.

//使用CORBA的 BankApp系统的接口

//Sample IDL Interface Code（IDL 接口代码样本）

module BankApp {

interface IBankApp {

exception exInsuffientFunds;

IBankApp getApp();

boolean depositToCheckingAccount (in string sAcctNum, in int nDeposit) ;

boolean depositToSavingAccount (in string sAcctNum, in int nDeposit) ;

boolean withdrawFromCheckingAccount (in string sAcctNum, in int nWithdraw)raises

(exInsuffientFunds);

boolean withdrawFromSavingAccount (in string sAcctNum, in int nWithdraw) raises

(exInsuffientFunds);

};};

//Sample Java Interface Code Using Remote Method Invocation

//(使用RMI 的Java接口样本)

import java.rmi.*;

package BankApp;

public interface IBankApp extends java.rmi.Remote {

boolean depositToCheckingAccount (String sAcctNum, int nDeposit) throws java.rmi.RemoteException ;

boolean depositToSavingAccount (String sAcctNum, int nDeposit) throws java.rmi.RemoteException ;

boolean withdrawFromCheckingAccount (String sAcctNum, int nWithdraw) throws

java.rmi.RemoteException;

boolean withdrawFromSavingAccount (String sAcctNum, int nWithdraw) throws

java.rmi.RemoteException;

}

//Sample Microsoft IDL Interface Code for COM – Simplified

//（Microsoft IDL 的COM接口编码样本－简化版）

library BankAppLib {

dispinterface IBankApp {

IBankApp getApp();

boolean depositToCheckingAccount (BSTR sAcctNum, int nDeposit) ;

boolean depositToSavingAccount (BSTR sAcctNum, int nDeposit) ;

boolean withdrawFromCheckingAccount (BSTR sAcctNum, int nWithdraw);

boolean withdrawFromSavingAccount (BSTR sAcctNum, int nWithdraw);

};

coclass BankApp {

dispinterface IBankApp;

}; };

//Sample SOAP (Simple Object Access Protocol) SDL (Service Description Language) with XML -Incomplete

//包含XML 的SOAP SDL样本－不完全

<?xml version='1.0'?>

<serviceDescription name='BankApp'

xmlns='urn：schemas-xmlsoap-org：sdl.2000-01-25'

xmlns：dt='http：//www.w3.org/1999/XMLSchema'

xmlns：IBankApp='IBankApp'>

<import namespace='IBankApp' location='#IBankApp'/>

<soap xmlns='urn：schemas-xmlsoap-org：soap-sdl-2000-01-25'>

<interface name='IBankApp'>

<requestResponse name='WithdrawFromCheckingAccount'>

<request ref='IBankApp：WithdrawFromCheckingAccount'/>

<response ref='IBankApp：WithdrawFromCheckingAccountResponse'/>

</requestResponse>

</interface>

<service>

<addresses>

<address uri='http：//myserver/IBankApp.asp'/>

</addresses>

<implements name='IBankApp'/>

</service>

</soap>

<IBankApp：schema id='IBankApp' targetNamespace='IBankApp'

xmlns='http：//www.w3.org/1999/XMLSchema'>

<element name='WithdrawFromCheckingAccount'>

</element>

<element name='WithdrawFromCheckingAccountResponse'>

<type>

<element name='return' type='dt：boolean'/>

</type>

</element>

</IBankApp：schema>

</serviceDescription>

V – 构建

编码/命名标准；接口代码—CORBA IDL；C++代码；CASE 工具脚本（CASE Tool Scripts）/定制报告的VBA /代码生成

Rose代码生成-需要Rose 专业版或企业版. 见Help Topic Code Generation（帮助主题－Code Generation）。

步骤：

1 – 检查模型；

2 – 创建组件；

3 – 映射/分配类到组件；

4 – 设定代码生成特性；

5 – 选择一个类、组件或包

6 – 生成代码；

7 – 检查生成的代码。

Rose 逆工程-需要Rose 专业版或企业版. 见Help Topic－ Reverse Engineering. 使用模型更新工具（Model Update Tool）。

VI – 测试

整个系统/集成测试－所有组件/子系统；组件测试－每个组件；单元测试－每个类。测试实例规约：

测试实例名（Test Use Case Name）：

用例名（Use Case Name）：

用例场景名（Use Case Scenario Name）：

触发器（Trigger）：

输入参数（Input Parameters）：

输出返回值（Output Return）：

前置条件（Precondition）：

出现的前置条件异常（Precondition Exception Raised）：

描述/转换（Description/Transformation）：

后置条件（Postcondition）：

后置条件异常（Postcondition Exception）：

注释（Comments）：

VII – 建模和构造其他组件

TellerGUI Forms（表单）；BankDB Tables（表）： tblWithdraw, tblDeposit, tblSavingAccount, tblCheckingAccount

翻译说明：

1. CASE ：计算机辅助软件工程，以下直接使用英文缩写。

2. test case ：在软件工程中一般翻译为“测试用例”，为了跟use case（用例）相区别，本译文用“测试实例”替换

3.UP：统一过程，Unified Process

4. harness: 在《面向对象系统的测试》（Robert V.Binder 著 华庆一等著）中译为“测试装置”，是指由测试驱动器和其他支持测试执行的工具组成的系统（如桩、测试实例、测试驱动器等）

参考：

1.《UML参考手册》 James Rumbaugh,Ivar Jacobson,Grady Booch 著，姚淑珍，唐发根等译）

2.《统一软件开发过程》 Ivar Jacobson，Grady Booch ，James Rumbaugh 著，周伯生、冯学民、樊东平译。


包括以下内容:

软件组织开发能力的评估程序和管理规范研究 [2003/03/13]

基于CMMI的集成化过程改进策略 [2003/03/12]

基于CMM的软件项目合同范围定义的扩充 [2003/03/10]

全球通过CMM4和CMM5的最新组织名单（2001-10）

中小型软件企业切入点：两步“跳”入CMM

CMM体系设计三步曲

CMM2级实施技术问题分析

CMM认证 爱你不容易

CMM—软件产业发展的必由之路

给CMM打造一个成长的园地

基于CMM实施软件过程改进的成功策略

中国如何引进CMM评估，促进软件产业发展

在中国开展CMM评估的几点建议

CMM评估中存在的若干问题

国内软件企业实施CMM的四大障碍

CMM给我们带来了什么

关于ＣＭＭ在项目中的实施

CMM工具帮助

软件企业如何实施CMM

如何成为CBA IPI主任评估师

在中国开展CMM评估的几点建议

CMM中KPA及KP的分布统计

联想冲刺CMM3透明报道（1）

联想冲刺CMM3透明报道（2）

联想冲刺CMM3透明报道（3）

联想冲刺CMM3透明报道（4）

联想冲刺CMM3透明报道（5）

冷眼看CMM

全面质量管理在软件业的应用

软件缺陷管理

CMM与传统企业文化

国内软件业对CMM认识的阶段性

实施CMM时必须解决的认识问题

CMM实施中的四个常见问题

如何在短期内达到CMM2级目标？

SQA到底是什么?

CMM认证谁受益

独立与客观—CMM中的软件质量保证实施准则

团队精神在CMM中体现

CMM是解决软件出口壁垒的有效途径

软件业发展的新方向——外包

CMM与软件外包管理

软件企业需要什么样的CMM服务？

循序渐进—CMM实施工程案例

CMM的宜与不宜

实施CMM是一条没有终点的路

高能力成熟度软件企业中软件质量工程师的职责

软件组织开发能力的评估程序和管理规范研究

51CMM原创 作者：李兴兵 [2003/03/13]

1. 开展软件开发能力评估的必要性
国际学术界和工业界一致公认，软件产业的发展将经历三个不同的阶段。第一阶段是70年代中期至90年代中期的软件结构化生产阶段，该阶段是以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。从80年代中期开始，软件生产开始进入以过程为中心的第二阶段，以个体软件过程PSP(Personal Software Process)、过程成熟度模型CMM和群组软件过程TSP(Team Software Process)为标志，这个阶段预计在2005年前后结束。而从1995年开始，国际上已经逐步进入以软件过程、面向对象和构件重用等三项技术为基础的软件工业化生产的第三阶段。我国一些先进的软件公司也已经开始从第二阶段过渡到第三阶段。
我国的软件开发行业目前还处于软件结构化生产阶段，刚刚开始向以过程为中心的第二阶段过渡，这也就是说，我国的大部分软件开发组织的过程能力成熟度还有待于进一步提高和改进，这主要表现在：
第一、 相当多的软件开发单位对软件开发的过程管理不规范，所生产的软件系统质量达不到客户方要求，容易产生因质量问题所引起的软件危机，软件开发中还存在比较大的潜在风险。
第二、 软件开发单位的开发过程混乱而无序，只重视先进技术在软件开发中的作用，忽视了软件开发过程对于软件质量的影响。开发过程的不标准性既不利于组织本身软件过程能力的提高，同时也妨碍了软件开发组织与国际先进开发管理规范的接轨。
第三、 各软件开发单位对软件产品的开发中不遵循软件工程的要求，其软件开发过程能力的不成熟，不利于软件项目采办中做出正确的决策。并且，客户方对软件开发组织的开发过程也不能进行很好地监控。
基于以上几点原因，要想加快我国软件行业的发展，提高软件开发水平和质量，促使软件开发单位严格按照软件工程的要求开发软件，则必须对软件开发单位的开发能力和过程能力进行客观公正的评估，督促各开发单位从根本上提高自身的软件开发过程能力，从而保证软件项目的高质量和低风险。
2. 国内外软件开发组织进行软件开发能力评估的现状
20世纪80年代，美国工业界和政府部门开始认识到，软件过程能力的不断改进才是增进软件开发组织的开发能力和提高软件质量的第一要素。在这种背景下，由美国卡内基-梅隆大学软件工程研究所（SEI）研制并推出了软件能力成熟度模型SW-CMM，随着软件产业界对软件过程能力改进的不断研究，CMM逐渐成为了评估软件开发过程的管理以及工程能力的标准。
CMM评估在软件产业界的开展，极大地推动了软件开发组织的过程能力成熟度的提高，并且将软件开发和生产从原来的结构化生产阶段推进到了以过程为中心的生产阶段。美国、印度等软件大国率先接受并实施了基于CMM的评估和改进，并取得了明显的效益。自1987年到2000年6月，向SEI报告的CMM软件过程评估多达1654次，被评估组织1269个，受评估的项目6784个。其中从1996年到2000年6月，就有901个软件组织接受了评估，被评估的项目为4174个。
我国软件组织对于CMM评估的实施起步较晚，目前仍然处于起步阶段，具体现状可以概括如下：
第一、 我国正在由结构化生产方式向以过程为中心的生产方式和工业化生产方式前进。许多软件企业已经认识到利用CMM改进软件过程，实施科学化、系统化管理以提高软件组织的过程能力成熟度的重要性，因而具备了开展CMM评估的强大动力。
第二、 目前实施CMM评估还存在一定的困难。这主要表现在许多软件组织不熟悉CMM的概念，缺乏软件工程理论和实践方面的经验，组织内的成员、特别是高层领导对CMM评估的重视程度不够，使得评估的具体工作得不到有效实施。
第三、 软件开发过程很不规范，缺少必要的文档化的过程描述，特别是缺少工作文档、工作量统计文档和风险管理文档。缺乏对软件过程和产品的测量，没有足够的软件过程历史数据，很难基于历史数据对软件开发的工作量和进度进行估计。
尽管如此，到目前为止，我国也已经有数家软件企业成功开展了CMM评估，并分别通过了CMM各个级别的认证。在评估过程中，不仅积累了丰富的经验，而且还培训了大量具有初步经验的评估人员，有的软件公司甚至已经培养出了自己的主任评估师。
我国的软件开发行业要想从根本上提高自身的软件过程能力，保证所开发软件的质量，缩短开发周期和减少费用，就必须紧跟国际和国内先进企业的步伐，尽快在软件开发过程中实施CMM评估和改进，有能力的软件开发企业应该率先申请进行CMM认证，形成适合于自身的软件开发管理规范。
3. 软件开发能力评估程序
当然，CMM作为一个较好的软件改善框架，只是给出做什么，并没有给出如何做。因此要想在软件行业中成功实施CMM，还必须认真研究如何遵循CMM模型进行具体操作的问题。
1) 实施软件开发能力评估的战略考虑
在软件开发企业中实施CMM评估，不能够照本宣科、生搬硬套国外软件公司的实施评估的方法，而要考虑软件组织自身的现状和评估所需要的人力财力物力等因素。对于我国大部分的软件开发组织来讲，基于CMM对软件开发过程进行评估和改进是一个全新的课题，实施CMM评估不仅需要大量的时间和资金投入，而且还会从根本上影响到软件组织的企业文化，并要求组织成员的软件开发理念也相应发生根本性改变。因此，对软件开发能力进行CMM评估不可能一步到位，而应该分阶段、分层次进行实施。
具体来说，软件开发组织中实施CMM评估应该按照以下两个阶段进行：
第一阶段：申请评估的软件开发组织首先应该自己组织CMM培训，强化组织成员的CMM理念，在整个组织中树立起过程管理和质量管理意识，并着重培养一批具有初步经验的CMM实施管理人员。在此基础上，选取一些合适规模的中小型项目进行试点，初步积累一些实施CMM的经验，为进行正式的CMM评估打下基础。
第二阶段：在第一阶段取得收获的基础上，聘请有实施CMM成功经验的单位作为咨询顾问，在组织内全面实施CMM。并且在咨询专家的指导下提出评估申请，并着手准备组织预评估和正式评估。
2) 基于CMM评估的具体实施过程
根据评估中的侧重点，软件开发能力的评估也可以有多种方法。在基于CMM模型的评估中所采用的方法是SEI所发布的CBA IPI方法。当然，根据被评估单位的具体情况，评估方法和程序也可以有所改变，但其基本的过程仍然是遵循CBA IPI方法的。CBA IPI方法以CMM为参考模型，以CMM评估框架CAF（CMM Appraisal Framework）为设计要求，由一组专业评估团队对组织的软件过程进行评估，找出组织当前软件过程的强项和弱点并依据CMM中关键过程域KPA（Key Process Area）的目标要求对组织的软件过程进行评级，从而提出最终评估报告的评估方法。
基于CMM的评估程序一般由三个步骤组成：
第一、 计划准备阶段。这一阶段的主要任务是在接到软件组织的评估申请后进行受理和实地考察，完成具体评估前的准备工作，制定出评估的具体计划。这一阶段的主要工作包括以下几项：1、界定评估范围，确定评估目标。2、制定调查问卷，选择组织参与者。3、制定评估计划，组织和培训评估团队。4、宣传评估的意义、目标、基本方法和过程。5、进行问卷调查并分析汇总，进行文档的前期查阅以确定准备内容的完整性。
第二、 评估执行阶段。这一阶段的主要任务是在组织中选取软件项目进行审查，对组织的软件开发能力成熟度进行定量、定性和综合评估，确定组织的资质等级并颁发资质证书等。其中具体工作包括：1、召开动员会，明确目标，取得组织参与者的支持。2、与组织参与者进行深度交谈、文档查阅及必要的演示说明。3、对收集到的信息进行确认、归类和汇总。4、分析、总结与归纳通过评估发现的组织过程的强项和弱点。5、将初步发现的组织强项和弱点向组织参与者报告说明并征求反馈意见。6、根据反馈意见作进一步验证评估和必要的修正、补充。7、确认评估内容的完整性后进行CMM等级评定。
第三、 评估报告阶段。这一阶段的主要任务是将评估结果报告给受评估的组织，并给出相应的反馈改进意见。具体工作有：1、向组织参与者报告说明评估结果并取得共识。2、向组织管理层报告说明评估结果取得认同以及对进一步的软件过程改进（SPI）计划的支持。
4. 关键过程域的管理规范
以上所述的评估程序是参考CMM模型而建立的，其评估过程中所依据的是CMM模型等级中所规定关键过程域的目标要求。因此，要保证软件开发组织中实施CMM评估的有效性，就必须在开展CMM评估的同时，研究、建立和完善CMM中所给出的软件需求管理、软件项目策划、软件跟踪和监督、软件（子）合同管理、软件过程文档管理、软件标准化、软件质量保证、软件配置管理、软件维护、集成软件管理、软件产品工程化、组织协调、同行专家评审、预防缺陷、技术变更管理、过程变更管理、组织过程管理和培训过程管理等18个关键过程域的管理规范。在制定这些管理规范的工作中需要注意以下几点：
第一、 要以CMM模型中所规定关键过程域为参考，所制定的各关键过程域的管理规范应尽量接近国际标准，做到与国际接轨，以树立起权威性。
第二、 在每一个关键过程域中，不能照搬照抄CMM中所规定的关键实践，而应该根据软件组织的具体情况进行合理的裁剪和解释。
第三、 在实现各关键过程域的过程中，CMM模型各级别之间的关键过程域的划分并不是一层不变的，可以根据具体情况进行灵活变更。比如，对于某些特定领域的应用软件来说，有些开发组织虽然不一定能够完全达到CMM5级水平的能力成熟度，但在实施评估时仍然可以将CMM5中的缺陷预防这一关键过程域的目标要求纳入到评估的指标体系中来，以符合软件对于软件质量的高要求。
5. 软件开发能力评估中可能会遇到的问题
前面说过，CMM评估对大多数软件开发组织来说是个新事物，组织中的绝大部分成员对其并不是很了解，因此，在实施评估中不可避免地会遇到这样那样的问题。根据我国软件开发组织中的实际情况，在实施CMM评估是大概会出现以下几方面的情况：
首先，实施CMM评估将会改变开发组织的企业文化和员工的开发理念，因而在执行中可能会有很大阻力。以前的软件开发组织在对软件开发过程进行管理时，往往只注重项目进度，而很少考虑到软件的质量保障和过程管理等问题。对于一个项目负责人来说，可能只是关心每天、每周的软件开发进度，而不注重由于过程管理不规范而带来的质量隐患；对于软件开发人员来说，往往习惯于按照自己喜欢的方式完成眼前的开发任务，排斥使用既耗时又费力的各种开发规范，也懒得填写开发过程中的各种文档，通常的做法是完成软件开发之后再回过头来写文档，不能真正发挥规范文档的作用；而对于软件开发组织的高层领导来说，可能只会着眼于组织近期所产生的效益，对于近期内作用并不明显、却又需要投入大量资金和时间的CMM评估往往并不能给以真正的支持。
其次，在实施CMM评估过程中只注重CMM认证的广告效应，为评估而评估，而忽略了进行CMM评估的真正目的。CMM评估只是一种手段，其最终目的是实现软件开发组织过程能力的不断提高。如果在评估过程中，被评估单位本末倒置，只是为了追求短期的经济效益，却不根据评估结果和反馈意见对软件开发过程管理进行有效的改进，CMM评估的实施往往就会流于形式，而不能从根本上改进软件组织的开发过程能力。
第三，目前在软件开发组织中实施CMM评估，还存在一定的技术阻力。这主要表现在两方面：一方面，由于对CMM标准的要求不熟悉，在管理过程中所编写的过程文档质量较差；另一方面，项目经理对文档要求不理解，或者操作方法不熟练，从而导致执行的结果与要求相差甚远。
第四，在实践方面，没有实施CMM评估的具体经验，缺乏有经验的评估人员。
根据以上几点考虑，要想在软件开发组织中成功实施CMM评估，需要做好以下几方面工作：
第一、 在整个组织内宣传CMM软件开发过程理念，从思想上引起对CMM评估的重视，尤其是要得到组织高层领导的支持和组织的政策扶持。
第二、 对组织内的相关人员进行CMM培训和软件工程相关知识的培训，提高组织成员实施CMM的技能。
第三、 加强与同行之间的交流，借鉴国内外软件组织进行CMM评估的成功经验，并根据自身实际情况灵活运用。
第四、 评估程序和管理规范力争做到与国际接轨，树立起行业权威性，在软件的开发过程管理中形成共识。
第五、 将开展CMM评估的出发点放在改善软件开发组织的过程能力成熟度上，制定合理的过程管理规章制度，严格执行，避免流于形式。
6. 结束语
目前我国软件产业方兴未艾，实施CMM可以从根本上改变我国的软件工程文化，改善软件人员素质，这对于提高软件企业素质、增强软件企业的国际竞争力以及软件的出口创汇都有着很重要的作用。这种行业环境为软件开发过程能力评估的开展创造了有利的外部条件。同时，当今国外软件开发组织对于我国软件行业的冲击对于软件组织所造成的压力，形成了在软件开发组织中开展CMM评估的内在要求。并且，鉴于信息产业在国家建设中的重要地位，在软件开发组织中开展CMM评估得到了政策方面的倾斜和资金上的支持，这一点为在软件开发组织内开展CMM评估创造了外部条件。因此，尽管在实施中存在不少困难，但这并不能阻止软件开发能力评估的开展。尽快进行这方面的研究工作，不仅具有重要的理论意义，而且还会产生巨大的应用价值。

基于CMMI的集成化过程改进策略

51CMM原创 作者：李兴兵 [2003/03/12]

摘要：本文论述了在工程组织中进行基于CMMI的集成化过程改进的总体策略。文章首先简要介绍了CMMI产品集，然后分别论述了利用CMMI进行集成化过程改进时如何选择合适的规范、模型表示法的选择以及在改进过程中评估的作用及开展。这几方面的问题构成了基于CMMI进行集成化过程改进的主要方面。
关键词：CMMI 集成化过程改进 评估
Abstract: This article expounds the tactic of CMMI-based integrated process improvement in an engineering organization. Firstly, the article introduces the CMMI products. Then, the article expounds how to select the appropriate criterion, how to select the representation of the model, and the function and operation of the appraisal in the improvement. All of the three subjects make up of the major aspects of CMMI-based integrated process improvement.
Key Words: CMMI, integrated process improvement, appraisal
一、引言
在工程领域，组织的质量和生产率依赖于三个主要的因素：过程、人员和技术。在一些大型系统的开发领域，随着技术的不断进步和人们素质的提高，过程因素逐渐成为制约产品质量和生产效率的瓶颈。因此，在开发组织中进行过程改进，进而增强其过程能力成为了开发组织必须要做的一项工作。
由美国卡迈基-梅隆大学的软件工程研究所（SEI）所推出的能力成熟度模型（CMM）的成功，导致了各种模型的衍生，并且每一种模型都探讨了某一特定领域中的过程改进问题。但是，随着系统复杂性的不断增长，工程实践的执行越来越多地依赖于交叉学科群组、并行工程以及其他一些高度自动化的过程。面向不同学科领域的过程改进模型已经不能很好地支持并行工程这种混合式的开发环境。在这种情况下，产生了基于CMMI的集成化过程改进。
二、CMMI简介
CMMI的全称是Capability Maturity Model Integration，即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。现在业界使用的CMMI最新模型是2002年发布的1.1版本系列，如CMMI-SE/SW/IPPD/SS，CMMI-SE/SW/IPPD，CMMI-SE/SW，CMMI-SW等。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或者多个单一学科的模型实现一个组织的集成化过程改进。在CMMI的初步研制中集成了三个特殊的过程改进模型：软件（SW-CMM）、系统工程（EIA/IS 731）以及集成化产品和过程开发（IPD CMM）；从长期考虑，CMMI产品开发群组建立了一个自动的、可扩充的框架，以便于以后将其他一些学科的过程改进模型也逐步添加到CMMI产品集中。
CMMI模型中，最基本的概念是“过程域”。与以前的一些过程改进模型一样，CMMI模型也只是选择对过程改进最重要的一些题目，并将其编组到“域”中。在CMMI以前所推出的每一种单一学科过程改进模型中，都包含了一定数量的过程域（或者其他类似名称，如焦点域）。随着各种学科之间的交叉，过程改进人员发现这些不同模型的过程域之间存在很多重复，在涉及多学科的过程改进中带来一些额外工作量，因此产生了将各种过程改进模型进行集成以减少过程域数量的想法。这种想法的最早实现就是CMMI项目首先在软件和系统工程之间实现了较高的集成性，产生了一个公共的过程域集合。随着研究的深入，过程域在不同学科之间的这种公共性越来越明显，因而在CMMI也就渐渐形成了这样一些非常具有通用性的工程过程域。事实上，过程管理和项目管理可以应用于任何学科，因此，CMMI中的这些工程过程域在对不同学科应用时具有不同的实现。总的来说，集成达到了两个目的：一是提炼出了多学科之间的一些公共过程域，另一方面就是减少了过程域的总数量。下面的表1列出了CMMI及其源模型的过程域数目。
表1：CMMI模型及其源模型中的过程域数量
模型 过程域数量
SW-CMM版本2（c） 19
EIA/IS731 19
IPD-CMM版本0.98 23
CMMI-SE/SW/IPPD版本1.1 25
每一种CMMI模型是一个多达数百页的文档，文档中包含了不同类型的资料，也就是模型构件。CMMI的模型构件主要有三类：需要的（required），期望的（expected），以及提供信息的构件。
需要的构件只有一种，那就是“目标”。目标表示某个过程域想要达到的最终状态，其实现则表示项目和过程控制已经达到了某种规定程度。针对单一过程域的目标，称之为特定目标；可适用于所有过程域的目标则称为共性目标。
期望的构件也只有一种，就是“实践”。实践代表了达到目标所“期望的”手段。CMMI模型中每个实践都恰好映射到一个目标。当然，只要能够实现模型中规定的目标，组织可以采用其他一些经过认证的手段作为“替代的”实践，而不一定非要采用模型中规定的实践。因此，实践只是模型中期望的构件，而不是需要的构件。同样，针对单一过程域的实践，称之为特定实践；可是用于所有过程域的实践则称为共性实践。
提供信息的构件有10种，分别是目的、介绍性说明、引用、名字、实践与目标关系表、注释、典型工作产品、子实践、学科扩充以及共性实践的详尽描述。这些构件为需要构件和期望构件提供了有益的补充。
三、规范的选择
如同上面所说，CMMI是一套产品集合。针对不同的学科有不同的规范和标准。并且，每增加一种CMMI学科规范，组织在改进和评估中就要考虑更多的过程需求。比如，原来的SW-CMM模型中描述了300多个实践或活动，而现在的CMMI-SW/SE版本1.1中却描述了400多个实践或活动，用这两种模型进行过程改进或评估所需要的工作量显然是不同的。因此，一个组织要想利用CMMI进行过程改进，首先必须根据自身的主要业务类型，以及改进的目标等因素，在CMMI产品集合中选择适合于自身组织的规范。
组织在选择适合自身需要的CMMI产品规范时，主要应该考虑一下几方面因素的影响：
组织的核心业务类型
这一点对于规范的选择尤其重要。虽然在一些大型项目中总会涉及到多学科、多领域的问题，但是对于组织中的核心业务来说，总是有一门或几门学科是特别重要的。为了减少过程改进中的工作量，避免在改进中引入一些不必要的过程域，组织应该选择对业务成功至关重要的学科规范。
对于开发产品或服务的组织来说，其业务类型大致包括如下三种：
1、 组织独立承担对某项新产品的全程开发和维护，开发过程不受外部因素影响。
以软件开发为例。如果软件开发组织需要开发的是一个面向某一领域的软件系统，并且是独立开发，则首先考虑的规范就应该是CMMI-SW。该规范中对于软件开发过程中需求的建立、项目计划的制定和实施，以及对软件的测试等过程都有详尽的描述。不过，考虑到软件工程与系统工程两个学科之间的大量重复性，以及两者在全程质量管理上的统一性，一般推荐使用CMMI-SW/SE规范，因为CMMI项目在软件与系统工程之间已经进行了比较完美的集成，对于进行独立开发的软件组织来说，采用CMMI-SW/SE规范进行集成化过程改进，是在集成性和工作量二者之间进行折衷的最佳平衡点。
2、 组织在开发产品或服务中需要集成他人创建的产品，或对产品的开发过程受到某些工程的影响。
实际上，随着系统复杂性的增长，组织所承接的大部分项目都是属于这种业务类型，这就涉及到开发过程中多学科的交叉以及并行工程等问题。CMMI产品集中的CMMI-SE/SW/IPPD对这种类型的项目开发过程进行了详细描述。一般来说，如果组织在项目开发中需要使用交叉学科群组，需要解决对项目群组的使用、计划和组织，需要解决学科或组之间的沟通以及与集成化产品和过程开发相关的一些问题，则可以考虑选择CMMI-SE/SW/IPPD版本1.1规范。
3、 组织在开发过程中需要获取或转包某些关键构件。
这种业务类型主要涉及到对产品的获取和转包，也就是与产品供应商相关的一些问题。CMMI-SE/SW/IPPD/SS版本1.1中对于供应商的选择和监督、集成化供应商管理以及供应商定量管理等方面给出了详尽描述，可以比较成功地解决这些问题。
组织开展项目的业务环境
组织开展项目的业务环境也是影响规范选择的一个重要因素。在为过程改进选择规范时，主要应该考虑以下两种业务环境。
1、 项目开发周期的时间长短及项目的稳定性。
如果组织所承接的是一个长期项目，具有稳定的工作环境和压力，那么可以考虑选择集成了多学科的过程改进规范。因为，当组织面对一个长期、稳定的项目环境时，一般能够支持在一系列业务活动之上的集成化过程改进工作。并且，由于项目的长期性为过程改进提供了充裕的时间，因而组织可以严格贯彻规范中所描述的过程域中的各项实践和活动，同时还可以从数据和经验积累中感觉到过程改进所带来的益处。
如果组织所面对的是一个快速发展的环境，所承接的项目是短期的、按进度驱动的工程，那么可以考虑只集中于一个特定的学科进行过程改进，甚至可以只选择某一学科规范中的少数过程域进行改进，这样可以在不影响项目进度的前提下，尽快得到过程改进投资的效益回报。当然，从组织的长远发展来说，这种做法并不可取。但是当一个组织在面对项目进度的压力时，也只能采取这种折衷的做法。
2、 项目面对的客户基础。
在选择过程改进规范时，组织所面对的客户也是一个不容忽视的因素。如果组织承接的是对复杂系统有一些关键需求的大型项目，例如国防、航天等项目，则客户往往就会要求组织采用有把握的学科规范来匹配系统开发过程。
集成化过程改进的范围和目的
在选择合适的规范之前，首先应该了解所需改善的过程种类和过程改进的目的。如果组织的目的完全是为了进行内部过程改进，那么在选择规范方面可以有很大的余地。针对组织中涉及的项目种类和业务类型，只要有助于组织开发过程的定义、改进的学科规范都可以选择。但是，如果组织进行过程改进是为了认证或定级，以扩大组织的商业影响力，那么就应该有针对性地选择某一特定学科的规范，在过程改进过程中也就要注意对规范实施的严格性和全面性。
四、 选择合适的表示法
每一种CMMI模型都有两种表示法：阶段式和连续式。这是因为在CMMI的三个源模型中，CMM是“阶段式”模型，系统工程能力模型是“连续式”模型，而集成产品开发（IPD）CMM是一个混合模型，组合了阶段式和连续式两者的特点。两种表示法在以前的使用中各有优势，都有很多支持者，因此，CMMI产品开发群组在集成这三种模型时，为了避免由于淘汰其中任何一种表示法而失去对CMMI支持的风险，并没有选择单一的结构表示法，而是为每一个CMMI都推出了两种不同表示法的版本。
不同表示法的模型具有不同的结构。连续式表示法强调的是单个过程域的能力，从过程域的角度考察基线和度量结果的改善，其关键术语是“能力”；而阶段式表示法强调的是组织的成熟度，从过程域集合的角度考察整个组织的过程成熟度阶段，其关键术语是“成熟度”。
尽管两种表示法的模型在结构上有所不同，但CMMI产品开发群组仍然尽最大努力确保了两者在逻辑上的一致性，二者的需要构件和期望部件基本上都是一样的。过程域、目标在两种表法中都一样，特定实践和共性实践在两种表示法中也不存在根本区别。因此，模型的两种表示法并不存在本质上的不同。组织在进行集成化过程改进时，可以从实用角度出发选择某一种偏爱的表示法，而不必从哲学角度考虑两种表法之间的差异。
从实用角度讲，两种表示法各有优点。
阶段式表示法
软件CMM是一种阶段式模型，该模型经过多年的成功使用已经被证明是有效的，这为选择阶段式表示法模型提供了最强有力的证据。考虑从不成熟组织向成熟组织的发展过程，阶段式表示法具有如下两方面优势：
1、 阶段式模型为支持组织的过程改进提供了一个过程平台。
对于着眼于改善过程成熟度的组织来说，阶段式模型提供了一种明确的、行之有效的跨越式发展途径。阶段式模型中所描述的组织的5个成熟度等级中，每实现一次等级间的跨越，组织就致力于解决某一方面的问题。例如，组织从成熟度等级1到成熟度等级2，主要致力于有助于改善项目管理的过程域；从成熟度等级2到成熟度等级3，提供了广泛的组织过程定义；从成熟度等级3到成熟度等级4，致力于对过程定量管理的过程域；从等级4到等级5，致力于过程的改进和优化。通过这种方式，阶段式模型确定了组织进行过程改进的最佳次序，如图1。

图1：模型的阶段式表示法
2、 阶段式模型可以为组织定义一个过程成熟度等级，便于进行跨组织的比较。
在阶段式模型中，每一个过程域都被指定归属到一个成熟度等级中，因此，基于阶段式模型为组织所定义的成熟度等级中，过程域的预期范围和应用将变得非常清晰。这样，在对不同的组织进行比较时，只要对比组织所达到的不同的成熟度等级，即可知道不同组织在执行过程域方面所存在的差别。
连续式表示法
相比之下，连续式模型不如阶段式模型常用，但也不乏支持者，特别是在系统工程师中。采用连续式模型主要有如下两方面的优势：
首先，连续式模型为用户进行过程改进提供了比较大的自由度。如同上面所说，阶段式模型确定了组织进行过程改进的最佳次序，但同时也限定了用户在进行过程改进时必须遵循单一的改善路径。而连续式模型则允许用户根据组织的业务目的来选择过程改进活动的次序。在连续式模型中，用户可以选择定义组织的成熟度等级，同时还可以选择定义更适合于自身业务环境的过程域的次序。组织可以在一个自己选择的次序中使过程域达到给定的能力等级，而不必遵循单一的阶段式模型的原则。
其次，基于连续式模型对组织的过程进行的评估，其评估结果具有更好的可见性。在连续式模型中，可以为每个过程域定义多个能力等级，从而可以增强对过程改进中强项和弱点的认识。由于连续式模型是对每个个别的过程域进行单独的评定，并给出个别过程域的能力等级特征图，这显然要比只一个单一的成熟度等级图能提供对过程的更仔细的观察。
五、 CMMI评估的作用及开展
在过程改进中，评估是非常重要的一个环节。对于组织内部来说，开展对过程的评估是为了找出组织目前所处的位置，诊断组织过程中存在的缺陷。这一点对于过程改进的成功开展是必不可少的。因此，在一个组织中进行集成化过程改进之前，首先要对评估的作用及开展有一个清晰的认识。
1、正确认识评估的作用
目前，我国的软件行业中对开展CMMI评估日益重视，很多公司都已经开始实施CMMI评估，并取得了一定的成果。但是，在开展评估中也暴露出了一些问题。其中最主要的问题是对于评估产生的误解。很多组织仅仅是为了评估而评估，只盯住评估的商业目标，急于求成，在评估过程中弄虚作假；评估结束后，只注重认证结果，对评估结果没有好好利用，不能够真正贯彻评估中所给出的建议，从而也不能真正起到过程改进的目的。
在组织的过程改进中，评估的主要作用就是评定组织当前的所处的位置，即评定过程域的能力等级或组织的成熟度等级，并且找出组织的各个过程域中的强项和弱点，为下一步的过程改进提供建议和支持。同时，考虑到组织的商业目标，在组织中开展评估和认证可以扩大组织的市场影响力，从而带来相应的经济效益。在过程改进中，一定要摆正评估的位置。评估是手段，而过程改进才是组织所要达到的最终目的。
2、评估的开展
根据CMM标准中所提出的IDEAL模型，过程改进的开展可以分为五个阶段：⑴初始化：为成功进行过程改进打下基础；⑵诊断：相对预期目标找出组织当前所处的位置；⑶建立计划：计划如何达到目标；⑷行动：按照计划展开行动；⑸学习和扩充：学习以往的过程改进经验，扩充在将来采用新技术的能力。在组织进行过程改进的过程中，这五个阶段需要多次重复进行，逐步改善组织的过程能力。因此，作为诊断阶段中的一项重要活动，评估也不是一次性的行为，同样也需要循环往复进行。
CMMI产品集中的CMMI Appraisal Requirement 版本1.1给出了基于CMMI的评估中40多条需求，提供了一个综合需求集和评估方法的设计限制。根据这些需求集和设计限制可以开发出相应的基于CMMI的评估方法。
CMMI产品集中还给出了过程改进的标准方法CMMI评估方法SCAMPI，这一方法是由CMMI产品开发群组开发的，满足全部的CMMI Appraisal Requirement 版本1.1需求。组织在进行过程改进的时候可以参考该方法进行具体实施。
但是，对于一个具体的组织来说，仅仅根据CMMI产品中对评估的相应描述来照本宣科是远远不够的。特别是对于一些在过程管理方面还很不成熟的组织，在开展CMMI评估的时候更要发挥自身的创造性，灵活运用CMMI产品集中所提供的评估方法。根据CMMI Appraisal Requirement 版本1.1中的描述，评估可分为三类：
A类评估：全面综合的评估方法，要求在评估中全面覆盖评估中所使用的模型，并且在评估结果中提供对组织的成熟度等级的评定结果。
B类评估：较少综合，花费也较少。在开始时作部分自我评估，并集中于需要关注的过程域。不评定组织的成熟度等级。
C类评估：也称为快估。主要是检查特定的风险域，找出过程中的问题所在。该类评估花费很少，需要的培训工作也不多。
对于一个准备全面实施SCAMPI的组织来说，可以将过程改进分成几个层次进行，在不同层次间逐渐引入较高水平的评估：先通过几次C类评估找出过程缺陷，改进之后再导向B类评估；同样，B类评估也可以执行多次，慢慢导向进行全面的SCAMPI基准评估。如图2所示。

图2：评估的时间层次性
3、对评估模型的剪裁
模型是评估中的一个重要因素。在进行具体的评估之前，需要对选定的模型进行剪裁。这样做一方面可以减少评估的工作量，更主要的是建立起适合组织具体情况的具体模型，将标准模型中的角色、活动等部件映射到组织结构中。
对CMMI模型的剪裁可以从两个不同的角度进行：一是将剪裁模型用于过程改进；另一方面，也可以将剪裁模型用于建立评估基线。
对于内部过程改进方面的模型剪裁，主要是限制或扩展组织或项目的过程改进范围，是别出支持组织的商业目标和需求的过程域和实践，去掉对组织的业务目标“不适用”的过程域、目标以及实践。当然，由于模型中各组件之间的相互联系，如果将多个过程域、过程域中的多个目标或实践声明为“不适用”，将不可避免地带来评估中的一系列风险，从而削弱了评估的作用。因此，当怀疑某个过程域或目标以及实践不适用时，不应该匆忙做出决定。
将剪裁模型用于建立评估基线，主要是为了能够通过评估报告在同行业中或者在几个潜在的供应商中比较评估结果。因此，在这种情况下进行模型的剪裁，必须保证在多次评估中参照剪裁模型所得出的定级结果的一致性。从这种角度出发的模型剪裁受到更多的限制。CMMI-SE/SW/IPPD版本1.1中对其具体剪裁方法给出了详尽的描述，组织在通过剪裁定制自己的CMMI模型时可以作为参考。
组织在进行过程剪裁时，应该综合考虑自身的业务目标、业务模型以及过程改进的资源约束等因素，全面衡量剪裁在减少评估工作量与其所带来的风险之间的利害关系，紧密结合组织本身的核心业务过程，参照CMMI产品集中给出的规范和标准，建立起自身评估中可用的CMMI模型。
六、 结束语
自从CMMI项目启动以来，基于CMMI的集成化过程改进策略已经在很多知名的大型组织中取得了比较成功的实施。这些组织在进行集成化过程改进中，既取得了巨大的效益，也积累了丰富的经验。本文根据这些组织的实施经验，总结了基于CMMI的集成化过程改进中需要注意的几个关键问题。具体实施中的许多关键技术，如组织标准过程的建立，对模型的剪裁技术，评估的开展中的一些重要技术等，都还有待于进一步的研究。
参考文献
1、CMMI Product Development Team. Standard CMMI? Appraisal Method for Process Improvement (SCAMPISM), Version 1.1: Method Definition Document. CMU/SEI-2001-HB-001.
2、CMMI Product Development Team. Appraisal Requirements for CMMISM, Version 1.1: Technical Report. CMU/SEI-2001-TR-034.
3、CMMI Product Development Team. CMMISM for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version 1.1,Staged Representation (CMMI-SE/SW/IPPD/SS,V1.1,Staged). CMU/SEI-2002-TR-012.
4、CMMI Product Development Team. CMMISM for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version 1.1,Continous Representation (CMMI-SE/SW/IPPD/SS,V1.1,Continous)CMU/SEI-2002-TR-011.
5、周伯生，吴超英，任爱华译著。《CMMI精粹——集成化过程改进实用导论》，机械工业出版社，2002，8。
6、胡春哲，张洁译著。《CMM实践应用——Infosys公司的软件项目执行过程》，电子工业出版社，2002，8。

基于CMM的软件项目合同范围定义的扩充

51CMM原创 作者：唐云岚 [2003/03/10]

摘要：本文从分析CMM的关键过程区域的基础上，结合软件项目合同的特点，对软件项目合同范围的定义进行了扩充，这对于降低项目开发的风险，提高软件开发方的过程能力成熟度，对于软件项目合同的签定双方都具有较大的借鉴意义。
关键词：软件项目合同 CMM 合同条款
软件项目合同作为保证软件项目开发方、客户方既可享受合同所规定的权利，又必须全面履行合同所规定的义务的法律约束，对软件项目开发的成败至关重要。经验表明，软件项目合同范围定义不当而导致管理失控是项目成本超支和时间延迟以及质量低劣的主要原因，有时由于不能或者没有清楚地定义软件项目合同的范围，以致在项目实施过程中不得不经常改变作为项目灵魂的项目实施计划，相应的变更也就不可避免地发生，从而造成项目执行过程的被动，所以强调对项目合同范围的定义和管理，无论对项目涉及的任何一方来说，都是必不可少和非常重要的。
有关合同范围的普遍性定义和管理，我们在这里就不再赘述，本文主要针对软件项目开发过程的特点，结合CMM的相关知识，试图给出一个软件项目合同特有的范围定义，并以合同条款的形式予以表现。
我们在对CMM的研究中发现，作为CMM的重要组成部分——关键过程区域（Key Practivice Area简称KPA），具有类似于合同条款的功能。每个KPA识别出一串相关活动，当这些活动全部完成时，能达到一组对增强过程能力至关重要的目标。这与合同中列出相应条款，指出项目要达到的目标相吻合。所不同的，KPA的直接目的是增强软件过程能力，合同条款的直接目的是实现项目目标，但两者的最终目标都是确保软件项目的成功。从这个意义上说，二者是一致的。为此，我们认为，采用KPA来界定合同范围是可取的。所要注意的是，CMM中的KPA共有18个，我们不能完全照般，而必须结合合同自身的特点以及软件项目的实际，予以取舍，并作恰当的变通。从目前我国的软件开发实际情况看，要提高软件过程能力成熟度，应该从CMM 2级做起。为此，本文主要结合CMM 2级的六个KPA，谈谈如何扩充软件项目合同的范围定义，以此来促进项目过程的改善。
1.需求管理
需求管理的目的是在客户和软件项目开发方之间建立对客户需求的共同理解。它包括和客户一起建立和维护有关软件项目需求的协议。因此，合同具有如下条款：
a.在整个项目开发过程中，开发方应明确保证对系统需求及其分配进行管理，并建立文档；
b.项目双方协商制定影响软件项目活动的非技术性需求(协议、条件和附加合同条款)，主要包括交付产品的形式、交付日期、项目里程碑等，并建立文档；
c.项目双方协商制定影响软件项目活动的技术性需求，主要包括对软件的性能要求、界面要求、设计约束、最终用户的要求以及选用何种编程语言；
d. 项目双方协商制定确认软件产品满足客户需求的验收准则，包括采用何种方法、何种工具进行验收；
e. 项目双方协商制定对客户进行软件操作方面的培训准则，以及其他相关服务的说明。
2.软件项目策划
软件项目策划的目的是为了完成软件项目开发而制定合理的计划。它包括以下步骤：估计软件工作产品规模以所需的资源，制定时间表，鉴别和评估软件风险和协商约定。因此，合同具有如下条款：
a.开发方应在合同中指定负责协商约定和制定软件项目开发计划的项目经理；
b.开发方应确保在项目经理和软件开发人员、其他工程组相关人员之间达成软件项目的约定，并建立文档；
c. 项目双方应对软件项目的规模、工作量、成本、进度等做出科学的估计；
d.项目双方(以开发方为主)共同建立高级管理者评审方法，对所有的软件项目约定和计划进行评审，并使其保持在监控状态下；
e. 项目双方(以开发方为主)共同明确开发工作的范围、技术目标和对象、最终用户的识别、成本和进度的约束及目标、项目伙伴；
f.开发方应确保能够为策划软件项目提供足够的资源和投资，必要时应采取的应对措施；
g. 项目双方(以开发方为主)共同对与项目成本资源、进度和技术方面相联系的软件风险进行鉴别、评估和建立文档。
3.软件项目跟踪和监督
软件项目跟踪和监督的目的是建立对实际进展的适当的可视性，使项目经理能在软件项目性能明显偏离软件计划时采取有效措施。它包括对照已文档化的估计、约定和计划，评审和跟踪软件完成情况和结果，基于实际的完成情况和结果调整这些计划。因此，合同具有如下条款：
a.开发方能够采用并维护一个已文档化的软件开发计划作为跟踪软件项目的基础，随时向项目经理报告软件项目的状态和问题；
b. 开发方应确保能够为跟踪软件项目提供足够的资源和投资，必要时应采取的应对措施；
c.在管理软件的技术和人员方面，软件经理受到培训，使其能熟练地管理技术项目，跟踪和监督软件规模、工作量、成本以及进度，管理职员；
d. 开发方应确保一线软件开发人员在软件项目的技术方面受到定向培训，包括项目的软件工程标准和规程、项目的应用领域；
e.跟踪软件工作产品的规模，跟踪项目的软件工作量和成本，跟踪项目的关键计算机资源，跟踪项目的软件进度，必要时能采取应对措施；
f.软件开发方应进行定期的内部评审以便对照软件开发计划跟踪技术进展、计划、性能和问题，并在里程碑处进行正式评审。
4.软件质量保证
软件质量保证的目的是向项目经理提供适当的对软件项目正使用的过程和正构造产品的可视性。它包括评审和审计软件产品和活动以验证它们符合适用的规程和标准，给项目和其他有关的经理提供这些评审和审计的结果。因此，合同具有如下条款：
a. 项目双方(以开发方为主)共同制定软件产品和活动遵循适用的标准、规程和需求的情况并得到客观的验证；
b.开发方能保证受影响的组和个人接到软件质量保证活动和结果的通知；
c.开发方存在负责协调和实施项目的SQA的组，SQA组有一个向高级管理者报告的渠道，使其处理在软件项目内部不能解决的不符合问题；
d. 开发方应确保能够为SQA活动提供足够的资源和投资，必要时应采取的应对措施；
e. SQA组的成员受到培训以完成他们的SQA活动，培训的内容包括软件工程技巧和实践、相关部门的岗位任务和职责、用于软件项目的标准、规程及方法、软件项目的应用领域等；
f.软件项目的成员接受有关SQA组的任务、职责、权力和价值等的定向培训。
5.软件配置管理
软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整性。它包括标识在给定时间点上软件的配置，系统地控制对配置的更改、并维护在整个软件生存周期中配置的完整性和可跟踪性。因此，合同具有如下条款：
a.开发方能按照已文档化的规程对软件项目准备一份软件配置管理(SCM)计划，明确指派每个项目的SCM职责，并保证其在整个软件开发过程中实行；
b.开发方能确保项目建立或利用一个仓库(软件基线库)，用来存储配置项/单元和相关联的SCM记录；
c.开发方存在或建立一个有权力管理项目软件基线的委员会(即软件配置控制委员会——SCCB)以及负责协调和实施项目的SCM的组，并建立制度定期审计软件基线和SCM活动；
d. 开发方应确保能够为SCM活动提供足够的资源和投资，必要时应采取的应对措施；
e. SCM组的成员在有关进行其SCM活动的对象、规程和方法方面受到培训，包括SCM标准、规程和方法，以及SCM工具等；
f.软件工程组和其他软件有关组的成员受到培训以便完成其SCM活动。
至于软件子合同管理KPA，其目的与本文的主旨相符，我们就不将其单独列出来了。综上所述，我们已经对CMM 2级中的各个KPA进行了研究，并将其中比较重要、需要控制管理的内容以合同条款的形式予以表现。我们认为，从软件项目管理的发展趋势来看，以合同的模式来推行CMM，对于降低项目开发的风险，提高软件开发方的过程能力成熟度，对于软件项目合同的签定双方都具有较大的借鉴意义。本文仅对CMM 2级中的KPA进行了研究，随着软件过程能力成熟度的提高，软件项目合同双方可根据自身的实际情况，逐步加入CMM 3级、4级乃至5级的内容。
参考文献:
[1]. SW-CMM v1.1, 卡内基-梅隆大学软件工程研究所（SEI）
[2]. 中华人民共和国合同法
[3].郑人杰,殷人昆,陶永雷：实用软件工程.第二版, 清华大学出版社
作者小传：
唐云岚,国防科技大学管理科学与工程专业的研究生，目前正从事项目管理方面的毕业课题研究。

全球通过CMM4和CMM5的最新组织名单（2001-10）

51CMM整理

    截止2001年10月底，全世界共有139个组织通过了CMM4和CMM5的评估，其中73家组织通过了CMM4级，66家组织通过了CMM5级。这139家组织中，其中美国占59家，印度占72家，其他国家占8家。在全球的分布如下表所示。

国家名称 | CMM4 | CMM5
中国 | 0 | 2
澳大利亚 | 2 | 0
法国 | 1 | 0
印度 | 29 | 43
以色列 | 1 | 0
俄国 | 0 | 1
新加坡 | 1 | 0

附录：详细名单（来自CMU/SEI）

中小型软件企业切入点：两步“跳”入CMM

隋振贵（转载自计算机世界）

    导入CMM，软件企业应该根据自己的企业现状和需要量力而行，选择一个合适的切入点，才能真正改进软件开发管理过程，避免形式主义和教条主义。
    软件企业导入CMM在时间、精力、资金等方面的投入都是非同寻常的。从准备阶段开始，咨询、预评估和评估及接待费用，CMM知识和软件工程技术培训费用，规程、规范、指南、管理办法等标准文件编制费用等一系列过程改进的费用很大，对中小型企业是一个不小的负担。因此，根据我公司具体情况，我们把导入CMM过程分成两个阶段。
    第一阶段是企业自己组织CMM培训，结合项目开发的需要和自身能力，分期分批地将CMM 2 级的6个KPA在项目组中试点，取得经验后再在其他项目组全面贯彻实施。这样以较少的花费提高了管理人员和开发人员的过程管理意识，初步积累了实施CMM的经验。
    在第一阶段取得收获基础上，我们在第二阶段聘请北京航空航天大学软件工程研究所和北京赛柏科技有限责任公司为咨询顾问，开始全面实施CMM，并在咨询专家的指导下准备组织预评估和正式评估。企业采用这种模式导入CMM有助于培养企业自己的过程管理人员，为CMM向更高的等级发展奠定良好的基础。
    组织机构是过程改进的保证，软件企业要导入CMM首先要对原有的组织机构进行重组，这需要得到公司高层领导的绝对支持。我们重组了公司的管理体系，按照CMM的管理框架建立了SEPG、SQA、SCM等管理监督机构，协调好他们与软件工程组和测试组之间的关系，即相互配合，又保证其独立行使各自的职责。
    在软件过程改进进程中，要首先深入分析企业的现状，找出困扰软件开发的主要因素，有针对性地逐步整改。要充分认识到，企业内部一些不合理的开发模式是多年来形成的痼疾，不可能靠发布一些规范就能轻松解决，在实施CMM规程时要根据企业的具体情况，由易到难，由粗到细，由松到严。在选择引入CMM管理的试点项目时，要考虑到开始时软件人员对过程管理的不适应可能对项目开发造成的影响，要选择开发时间相对充裕的项目进行试点实施，以避免由于工程进度的压力而放弃管理规范，使得CMM的过程管理流于形式。 　　中小型软件企业在导入CMM之前，开发过程的管理水平都很薄弱，各层管理人员大都是技术骨干出身，经过若干年的开发实践形成了自己的一套管理方法和思路，要改变原有的工作习惯是一个艰难的过程。在实施CMM管理体系时要首先统一全体开发人员的思想，组织开发人员逐步深入地进行CMM的系统培训和讨论，使他们真正理解CMM管理过程的每个关键实践的含义，不光要知道做什么，还要领会为什么这样做，否则会产生哪些不良后果。切忌简单地以行政命令强制推行CMM管理，招致开发人员的反感和抵触情绪，这只能导致CMM实施的失败。在导入CMM的过程中，公司高层领导和项目经理的支持是成功的关键。只有得到公司高层领导和业务骨干的有力支持，才具备开展CMM的资源和条件。有了这两类人员的支持，CMM的实施就有了保障。

CMM体系设计三步曲

雅行（转载自计算机世界报）

    许多软件企业在实施CMM时，过多地采用“拿来主义”，实施工具要“拿来”（照搬国外的工具），体系“设计”也要“拿来”（用别人的成套模板改改来用）。这种做法不一定适合软件企业的实际，会使软件过程改进（SPI）失去意义，那么体系设计有没有方法？这里提出CMM体系设计的三步曲，就是CMM体系设计中应依次采取三种不同设计方法：概要设计、详细设计和度量设计。 　　通过软件过程改进，得以构建一套系统的工程化管理体系（以下简称SEMP），该体系是以文档形式来体现的，这些文档分三类，其关系如图1。
    体系设计的三种方法分别输出三类文档：总体文档、过程文档和支持文档。总体文档描述系统总体，指出系统设计依据、总体目标、方针、策略和系统概貌描述，在ISO9000中称为质量手册；过程文件描述具体的活动、谁、什么时候、做什么事，这是系统的主体部门；支持文档的种类非常多，提供具体的方法、规范、模板和工具，比如Java编码规范、配置管理工具使用指南、项目开发计划模板。
概要设计
    体系的概要设计要完成如下任务：总体方案概述——简述实施方案；总体策略——自底向上还是自顶向下，一步走还是分步到达；远景目标——在比较长的一个期限内，比如1～2年，达到什么样的状态；阶段目标——分段实施，每阶段的目标; 流程概述——设计哪些流程？各流程完成什么活动的简要叙述，各流程的相互关系；生命周期——流程相对与项目生命周期的关系；度量系统——度量需要达到的总体目标，源数据的获取、处理、报告、周期和角色；文档图例——体系特别是过程文件的图例说明；责任矩阵——体系的面向角色的职责分解; 体系文件清单——体系各层次文件的名录汇总。
    总体文档不仅仅明确了系统设计的总体，而且它还可以极大方便使用者快速把握系统概貌。需要特别提到的是责任矩阵，过程文件通常是以过程为中心描述的，各角色的职责分散在不同的过程文件中，这样难以获得具体角色在体系中究竟何时何地做何事的信息。在总体文档中设置责任矩阵，此问题将迎刃而解。
    在此阶段，将选择和裁减有关知识域构成体系设计的理论依据。
    可利用的知识域: CMM——能力成熟度模型，由美国卡内基梅隆大学软件工程研究所提出； ISO9000——国际标准，不只适用于软件企业；SEBOK——软件工程知识体系；PMBOK——项目管理知识体系，美国项目管理协会提出；PSP——个体软件过程；TSP——小组软件过程；P-CMM——人力资源能力成熟度模型; Best Practice——介于理论和实践之间的结合层，经验性的知识，散布于各种著作和报道中。
    上述知识域多数自成完整系统，要想不拘泥于上述体系，希望获得更灵活设计，需要设计者对上述体系都有深入的掌握。尤其要对CMM、ISO9000、项目管理知识体系的相互关系进行透彻解析。
    设计需要考虑的三个关键要素是：诊断识别出的组织的实际需求、组织的资源能力、管理基础和成熟度。 　　大多数情况下，以下要素是企业优先需要重视的：配置管理、项目计划、项目跟踪和监控、项目启动和项目收尾（见图2）。
    在实际情况中，存在很多复杂情况，缺乏基本软件工程的企业可能需要在实施配置管理的同时实施基本软件工程甚至软件技术，避免配置管理的“垃圾进垃圾出问题”。不少软件企业的部门一级没有足够权利，造成对SPI的推进乏力，可能需要先解决责权这个基本问题。
详细设计
    体系的详细设计阶段需要实现概设中裁定的一系列过程。过程定义有着非常标准的模板：目的——定义本过程的目的; 角色——本过程中涉及的角色及其职责; 入口准则——什么条件会触发本过程的启动; 输入——文档、资源和数据; 过程步骤——本过程有关的处理步骤；输出——文档、资源和数据; 出口准则——什么条件会触发本过程的结束。 　　根据需要还可以增加如下的条款: 度量、过程监控方法、工具技术和方法、差距分析、过程改进历史和相关过程。
    过程步骤的描述可以采用任何的形式，但是使用图形可以极大的方便阅读（见图3）。
    一些良好验证过的方法和实践，不妨列入“工具技术方法”中，会对使用者提供不少方便。
度量设计
    度量设计常采用所谓GQM(Goal-Question-Measurement目标问题度量)法，Goal同样是从诊断得出的需求而来，通常需要优先采集的度量数据包括：代码缺陷、进度跟踪数据、开销跟踪数据。
    以下两例显示GQM的使用方法： 样例一：有关缺陷的度量设计 　　G：能否有重点的消除缺陷; 　　Q：缺陷数据是否被记录， 　　缺陷数据是否被分析; 　　M：文档——评审报告; 　　代码：问题报告单。
样例二：对产品缺陷的度量设计输出（见图4） [image] 　　度量设计的输出将体现在各类工作表单、过程数据库中，而度量总体的描述可以纳入总体文档中，方便阅读者全局把握。

CMM2级实施技术问题分析

于小葆

    对大多数国内软件企业来说，CMM的实施还处于起步阶段，准备实施CMM2级的企业占绝大多数，因此，分析CMM2级实施过程中的问题，将有助于这些企业尽快找到适合本企业的实施方式。
    一些正在实施CMM2级的企业发现有大量的重复性工作要做，原因何在？没有做好需求开发是产生这一问题的主要原因！
1 需求管理与需求工程
    需求开发和需求管理是需求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出现重复性的工作。导致需求开发欠佳的主要原因有以下几点：
◆ 缺乏良好的需求规格说明编写模板
    分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。
◆ 较严重地忽略了非功能性需求
    目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐成熟，软件客户对软件的非功能性需求也会越来越高，这就对软件开发商提出了更高的要求。不做好非功能性需求的规格说明编写工作，同样会陷入大量重复工作的包围之中。
    如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中期才被发现，这将导致大量的文档和产品需要更改，由此带来严重的工程和管理难题。改进的方法之一是调用有相当软件调试和维护背景的资深人员参与需求规格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面存在的不足。
◆ 缺乏对需求文档的配置管理
    采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看，一份留给软件开发小组内部使用，前者的目标是让客户较容易理解，后者则更加专业化。在这种情况下，两个需求规格说明都应纳入配置管理的范畴以便从管理的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前者到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能严谨的规则将大大缩小转化过程中人为自由发挥的空间。需要注意的是，这套规则的建立应从一个项目开始，从基础做起，逐渐完善。例如，首先确定项目的基本名词和动词集合，并规定语句书写规则。
◆ 需求规格说明缺乏可测性
    在需求说明应具备的几个特性里，为什么单单挑出可测性呢？在需求说明编写阶段，主观性对其他特性的影响较大，而一个独立且有经验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的。从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视的问题。
◆ 缺乏较好的需求规格说明转化规范
    需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的中间形式，这一转化过程也被称为“软件建模”。一般来说，建模可以使需求说明的某些方面更形式化一些，并使设计更加清晰地保持需求继承。通常，不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求说明丢失，从而增加后续管理工作的难度。
    需求管理的根本目的是为其后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性，因此需求工程完成得好坏对需求管理实施的工作量有很大影响。
2 配置管理与工作产品的转化
    软件配置管理的目的是保证项目生成的产品在软件生命周期中的完整性，它需要一个较好的工具，当找不到较好的商用软件工具覆盖该关键域的实践时，许多国外软件企业会自行开发一些工具来弥补不足，并且取得了很好的效果。国内软件企业在实施该关键域时也会使用一些工具，但存在的典型问题是：有太多的SCCB（软件配置控制委员会）活动。
    配置管理是在软件生命周期中建立和标识软件工作产品并控制基线的更改，这将保证软件工作产品的完整性和一致性。但是，作为配置项/单元标识的软件工作产品通常为典型的软件生命周期中的工作产品，这些产品具有一个共同特点：一个产品通常是由另一个产品转化而来。从一些企业配置管理下的工作产品来看，存在的主要问题是缺乏较好的可转化性。在这里，“较好的可转化性”是指把一个产品转化为另一个产品时有较规范的转化规则可循，其目的是最大程度地保证一种工作产品能被忠实地转化为另一种工作产品形式，从而最大限度地降低最初的软件需求在转化过程中出现遗漏和被错误解释的可能性。企业在实施这个关键过程域时，应由SCCB记录工作产品的更改以及引发这些更改的原因，这些数据能很好地帮助企业找出问题的症结。一般来说，引发类似问题的原因主要有以下3点：
    需求规格说明书编写不好或不全；
    工作产品模板定义不好；
    工作产品之间转化缺乏规范定义。
3 项目计划与数据收集和分析
    项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域，它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前，项目计划的实践总是处于需要改动的状态。
    一般来说，期望在CMM实施之初就有一个可靠的项目计划是不现实的，因为这需要经历若干项目的实施才能获得有效数据并据此制定未来项目的计划。我们知道，配置管理可以保证项目生成的产品在软件生命周期中的完整性，因此，为了更好地实施项目计划，我们可以把用于项目计划的大部分数据放在对应的工作产品配置管理之下，必要时，还可将工作产品进一步细化，以保证对应的项目计划数据的准确性。项目完成后，我们还应该对项目计划的数据进行收集和分析，在此基础上制定下一个项目计划时，准确性就能大大提高。通过对若干项目进行同样的实践，项目经理就有了比较可靠的数据用于制定未来的项目计划。通常，项目跟踪和监督实施不好的原因很大程度上是由于项目计划的频繁更动，同时缺乏良好的项目跟踪工具，使项目管理人员逐渐失去跟踪项目的兴趣。
4 质量保证与实践反馈
    实践反馈是质量保证体系得以有效运作的驱动力，企业应该为所有项目建立一条从SQA到项目经理以及更高层经理的反馈渠道。实践反馈是SQA组与高层经理相互沟通的过程，SQA组定期向高层经理汇报SQA的活动，并及时与项目组沟通，使项目组能尽早改进工作；当沟通不畅、发现项目组运作不力或发现组间协调困难时，应及时报告高层经理，通过高层经理的协调及时进行修正。
    有些项目经理认为自己心里有一套计划，只要按计划进行就可以按时保质完成项目，但事实并非如此，在项目组之间的协调问题上，高层经理的作用是非常明显的。如果仅仅为满足CMM的要求而虚设高层经理，这种做法是不可取的，因为如此一来，实践反馈是不完全的。
    SQA组在CMM实践中犹如一个司法机构，但这还不够，它还应该为改进过程管理提供资源。SQA组不一定完全由专职人员组成，也可调配一些擅长软件开发方法和软件过程管理的人员参与主要的SQA活动。
5 同行评审
    从理论上讲，同行评审这个关键域的实施并不难，但实际上大多数企业都掌握得不够好，主要表现在以下方面：
◆ 评审时组间争论过多或过少
    这一问题在不同企业的表现也不同。调查表明，争论较多的情况是工作产品的输入/输出不清楚，组间缺乏沟通的公共平台，因此组间只有通过较多的讨论甚至争论才能弄清其他组的需求。遗憾的是，事后大家并没有坐下来认真讨论如何改进原工作产品的模板形式或表现形式，因而也就无法从根本上解决问题。另一种较极端的情况是，评审一个组的工作产品时，其他组很少发表意见，尽管有些问题是十分明显的。通过调研发现，这实际上是企业文化的问题。一种普遍的想法是“等我们实际做的时侯自然就清楚了”，但实际情况往往事与愿违，这使企业的工作效率大打折扣，但又不易被管理层意识到。无论是哪种情况，最终的原因是：“项目甚至企业缺乏持续改进过程管理的意识。”
◆ 缺乏心理训练
    做好同行评审的最大挑战是克服心理障碍。简单地说，同行评审就是被别人挑错或挑别人的错。因此，评审会就像是答辩会，必须做好充分的准备。当角色互换，自己成了挑错方时，则应该把被评审的工作产品看成是自己在较早前完成的，现在再做一次修改，且修改完成后，自己要拿它去参加评审答辩。经历几次这种心理角色换位，就会逐渐适应。如果大家都这么做，同行评审就会形成良好的氛围，这对形成健康的企业文化将起促进作用。
◆ 竞争与合作意识不充分
    从另一个角度看，同行评审又是竞争与合作的最佳表现场所和形式，凡在这种场合讲话有理且意见中肯的人逐渐会成为团队的核心人物。在这种竞争的环境中，合作是基础，同行评审的目的就是在合作的前提下尽早且有效地排除工作产品中的缺陷。把握好竞争与合作的尺度，将有益于企业文化的发展，否则有可能出现恶性循环。如何把握呢？从大量的案例看，多数消化少数是较好的方法，因为文化是不可创造的。
◆ 考虑不全面
    同行评审存在的另一个问题是评审时仅注意工作产品内容本身，大家面对面地弄清内容后，却忽略了如何改进工作产品的表现形式，使新表现形式下的工作产品可更好地用书面形式表示，进而可减少面对面沟通的需求。当然，面对面的沟通并不是不好，但如果一个工作产品需要太多的口头表达才能被理解，则原因只有两个：书写不清楚或模板定义不好，如果是后者则情况更糟。
6 缺陷预防与度量
    缺陷预防的目的是为了识别产生缺陷的原因并防止其再次发生。一些实施低级别CMM的企业通常都采用一些度量（metrics）来预防缺陷，包括软件大小、软件设计错误、编码错误、测试错误、设计评审覆盖、编码评审覆盖、产生测试覆盖、与过程原因相关的缺陷、与项目原因相关的缺陷等。
    个别企业选用了一些难度更大的度量。大多数情况下，这些企业并非要达到更高级别的CMM，而是从产品需求的特性出发，对工作产品进行缺陷分析和预防。其过程通常是：获取数据、数据整理、度量、发现原因并确定过程的改进措施，其典型例子包括设计复杂性与测试覆盖及测试深度、模块复杂性与测试覆盖及测试深度等。这类企业的软件产品一般具有以下特点：软件产品规模较大，通常在软件产品交付给用户后，通过相当长时间的不断维护，稳定性才能达到满意程度。如果在早期对可能产生较多错误的软件模块进行识别，加强对这些模块的早期关注和测试，就可较早地使系统达到稳定。这种方法常常用在大型软件开发中，但真正用好的并不多，主要原因有以下几点：
◆ 忽略了使用度量的环境
    大多数工作产品的度量都是为某一种特定的设计方法或编程语言设计的，忽略了这个因素，度量就容易失去准确性。此外，软件产品不同的行业特性往往也是造成度量产生偏差的原因。
◆ 忽略了对度量参数的修改
    一些度量参数是在原来的实践环境下确定的，当在新环境下使用时，其中的参数很可能需要进行修改，才能使度量的准确性得到保证。
◆ 忽略了对相关性的研究
    使用的度量与缺陷在本地的相关性越高，度量的价值就越大。获取这种相关性的方法一般是对本地的历史数据进行相关性研究，企业只有在确认满意的相关性后才可将度量用于缺陷预防。

CMM认证 爱你不容易

    在CMM认证被京沪两地政府和软件企业当作进入国际软件市场必打之牌时，国内其他区域市场的软件企业又是如何看待它？
CMM考验软件能力成熟度
    CMM提供了一个评估软件开发过程的管理以及工程能力的标准，是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度评估标准。CMM标准共分为五个级别：初始级、可重复级、定义级、管理级和优化级，从低到高，标志着软件生产的计划度越来越高、生产周期越来越短、成本也越来越低。其一个重要思想是帮助一个组织通过基于模型的软件过程改进而达到使其软件过程向更高的能力成熟度等级迈进的目标。业内人士认为：“CMM既是软件企业迈向国际市场的通行证，也是用来衡量类似期房软件质量的保证书。”
    现在，我国正在大力发展软件产业，软件产品国际化是其中一项长远的发展目标。在这个过程中，类似软件出口国际护照的CMM认证也火起来。在国家相关政策鼓励之下，各地方的政府和企业也积极行动起来。现在，国内的华为、东软、联想、用友、方正等一批先进企业已经通过了不同层次的CMM认证，正在向着更高的层次前进。
    CMM是一个复杂的认证体系，对于企业而言，不仅存在时间和资金的问题，更有对于企业本土文化的冲击。据了解，现在国内的软件企业规模一般是以小型软件企业为主的金字塔形结构（如下图），而大多数中小型的软件企业中的开发人员通常都是从“单打独斗”开始的，开发过程缺乏文档、缺乏团队协作经验和方法是一个较为普遍的现象。而在CMM认证中，包括有开发人员的管理、文档的管理，以及对开发人员素质的评估。它将团队协作精神的强调隐含在模型的字里行间。所以软件企业中的人也成为CMM实施中的一个重要因素。
    看来，CMM虽是好东西，但是软件企业要和CMM谈情说爱还真不容易。
他们的认识
    为了解各区域软件企业对于CMM的态度，我们设计了几个简单的问题：
    你详细了解过CMM吗？
    你的企业在近期有通过CMM认证的计划吗？
    如果有：
    ——你是怎样看待CMM认证和企业发展之间的关系？
    ——你通过CMM认证的计划内容有哪些？
    ——在实施CMM的过程中，最大的困难是什么？
    采访的对象是在当地有一定自主开发实力的软件企业、SI或是ISV。通过各地方记者的走访，我们有了下面不同观点的碰撞：
    四川银海软件公司是四川省重点软件企业，专门从事社保、电信和电力等行业领域内的自有知识产权应用软件的研发、生产和销售以及行业系统计算机系统集成。银海的总经理陈晖告诉记者，早在1999年公司就通过了ISO9001认证。2002年公司将把开发中心和通讯产品部做为试点，以CMM标准来执行，目标是2003年通过CMM3级。
    陈晖认为，软件企业不拿CMM照样能活下去，但是要国际化，要把日子越过越红火，就应该拿到CMM认证。同时陈晖也坦言，在银海实施CMM的过程中，困难基本来自两个方面。一是人才，懂CMM的人不少，但真正能根据企业自身特色来执行这一套标准的人不多，特别是在内地。所以银海正着手引进优秀专业的顾问公司作为指导，同时银海也在加强对内部人才的培养。二是银海的特殊性，因为公司是做行业应用软件的，执行CMM后可能会有部分客户对此不认可，会在一定程度上影响销售。所以目前银海也在积极培养行业专家，这部分员工不仅仅是CMM专家，同时也对某一行业很熟悉，银海希望通过行业专家来引导客户对CMM的认知度。
    昆软信息产业集团是云南的软件业大户，也是引进了CMM认证体系并进入实质性操作阶段的企业之一。昆软信息产业集团董事长环遵祥表示，昆软计划用1年的时间，即到今年9－10月通过CMM2认证。为此，昆软已经投入了相当的人力和财力，并聘请了有关的咨询机构，现已进入评估的第二个阶段，即文档化阶段。
    环遵祥说，CMM认证是一个系统工程，目的是为了提高软件企业的综合竞争能力，但CMM不能一拥而上，也不可能一蹴而就，否则也会像ERP一样死掉一大片。一家软件公司真正想具备CMM能力，首先需要积累，没有3－5年的时间是不可能的。他认为对于大多数方向不明的中小软件企业来说，没有必要一哄而上，如果做成四不象，那就更要命，真要做就不能半途而废。
    环遵祥还认为，要上CMM，首先就要考虑它究竟能给公司带来什么样的核心价值。只有将CMM规范的管理思想沉淀到企业中去，从软件开发、服务营销、品牌推广等各个方面层层推进，实施CMM的效率才能达到最高。因此，企业在投入CMM之初，就必须做好准备，比如在市场体系上如何建立终端，外围客户如何开发推进以及如何建立软件出口基地等等，只有明白了市场和客户以后再去做CMM，才可以真正取到倍增效应。
    福州顶点软件公司是大型证券交易系统软件开发与服务商，是福建省中等规模的软件企业。公司副总经理赵伟告诉记者，从去年企业就开始选派一些专业人员参加了CMM认证的培训。并且已经提出了CMM认证请求。
    谈到认证与其企业之间的关系，赵伟认为CMM认证与ISO9000最大的区别在于CMM本身是一个持续改进的过程，目的是软件质量过程的改进。对于外包软件开发和软件出口，CMM是必备的。在实施CMM的过程中，资金的压力和一线开发人员的认知、开发程度、项目实施的效率与时间进度的矛盾是一个必须要跨越的门槛。
    武汉开目信息公司是湖北的大型软件企业，拥有包含开目系列软件等具有独立自主版权的制造企业信息化软件集成产品线。公司市场部主任段庚秋表示，CMM是当今企业从事规模化软件生产不可缺少的一项内容。公司已经准备在一年时间内通过CMM3认证。段庚秋认为，在实施CMM过程中，最大的障碍一方面是，要改变中国软件企业在长期发展过程中形成的固有的观念和不良习惯还很难；另一方面是，企业要通过CMM认证，投入的时间、精力、资金都非常大。
    陕西环宇易信软件公司是主营软件、网络系统集成、企业信息化、教育网络化产品的软件企业。公司总经理助理王保保表示，公司已经成立了专门的CMM研究小组，并且于今年上半年展开CMM认证工作，计划在明年通过CMM2和CMM3认证。而且公司现在也已经和印度的一些公司建立了良好合作关系。
    王保保把CMM的实施比喻为整理家务。只有把一个还较为杂乱的家收拾得有条理，才好开门迎宾。公司也是这样。通过CMM认证促使企业规范化、制度化。而企业一旦走上了这条路，就会有更大的发展空间，从而进入国际市场参与竞争。谈到在实施CMM过程中的困难，王保保认为可分两方面：从外部来看，担心项目费用投入后却通不过CMM认证；从企业内部看，技术力量还不是很强，技术人员对CMM理念的理解也还不够。在人才方面，企业也采用高薪政策引进，希望利用集体的力量通过CMM认证，并推动企业不断发展。
    南京北极星软件公司的定位是以VoIP技术为核心，开发基于IP技术的融合通讯软件产品。在区域采访中，他是一家近期没有实施CMM计划的公司。其副总经理杨泽萍女士告诉记者，公司虽然暂时还没有要通过CMM认证的计划，但是也曾选派质量控制人员参加过CMM的相关培训。
    杨女士认为，企业在CMM推动的初期是很有阻力的，因为增加了很多工作量和约束，任何代码和文档的改动都需要项目经理的统一管理，在开始的时候招致了很多抱怨，效率也有所下降。但CMM的管理思想是推动整个公司软件质量的一个必经过程。杨女士告诉记者，虽然没有通过CMM的计划，但是从1999年开始，北极星就制定了一系列软件开发的流程，通过一些成熟的软件来实现软件版本控制，缺陷管理。
CMM需要一步一步走
    从各地方反馈的情况看来，CMM认证正受到越来越多的软件企业的认同和重视。据了解，2001年要求CMM评估的企业比2000年增加了很多。认证的企业主要集中在北京、上海、广州、深圳等大中城市。内地软件企业对CMM的了解还很少，可以说市场尚未觉醒。另外，对CMM评估比较积极的软件企业一般是规模在中等以上的。那些处于中间规模的软件公司对CMM评估大多还在观望中。
    有一定规模的大企业需要用CMM的方法来管理企业，以求进一步发展。而中小规模的公司资金比较紧张，同时又觉得现状也过得去，所以不愿花大力气去改变。主要也是因为有着“内忧外患”。
    资金的瓶颈：企业要通过CMM认证，资金是一个很现实的问题。5万美元的评估费用只是评估中最少的部分，企业需要请咨询公司进行咨询与培训，而如企业用于改变管理的费用、员工学习CMM花掉的时间以及开发员为编写文档而花费的精力等才是企业最大的一笔投资。
    据了解，如果请外国评估师做一次CMM评估，花费大约是七八十万元，而且语言问题还会在一定程度上影响到评估效果。如果是中国评估师评估，企业的花费大概是四五十万元。据有关报道，通过了CMM3的东软所有无形与有形的投入加起来超过了1000万元。这对一些小企业来说不啻是一个天文数字。再加上这张证书并非终身有效，每过一年半就得重新接受评估。所以企业在决定通过CMM之前都必须慎之又慎，如果没有足够的能力来承担这笔费用，最坏的结果就是因此将企业拖垮。于是，对于很多地方上资金少、规模小、没有通过把握的企业来说，最好是应该先听一些项目管理、软件工程、测试等方面的课程，并且在先期建立起CMM的理念，当有改变的需求以及能力的时候，再去实施CMM认证。
    再换一个角度去看，对于很多将产品定位在国内市场的中小型软件企业而言，是不是也应该有一种比CMM更加经济实用的软件工程标准出现。这是一个值得整个软件行业思考的问题。
    人文的阻力：任何过程的实施都离不开人的因素，CMM也一样。绝大多数企业在实施规范化研发管理的过程中都会遇到来自员工的强大阻力，大多半途而废。其实这对于中国那些习惯了以自我个性为中心、不愿文档化、缺乏团队协作精神的软件行业文化来讲是很自然的现象。
    记得曾经在相关报道上看到，华为技术公司研究管理部副总裁陈青谈到华为的企业文化遭遇异质的印度文化的事。他说，中国员工在中国特有的文化环境中养成了某些“不良”习惯。CMM4要求工程师每天记录开发进度、工作量，并将相关数据填入报表，以便准确统计一个项目所需的工作量。印度员工是“真把填报表当回儿事，天天下班前都会填。”而中国员工要是一忙，就在一周工作结束后随意填一下。这种长期的文化积淀具有强大的腐蚀力，时间一长就会形成工程实施中无形的阻力。 　　其实CMM模型对于做事能力的重视不亚于具体的工程实施，无论项目经理还是各项目成员，完成其角色工作的进入准则之一是能力。实施CMM的过程也就是将研发人员点石成金的过程。
    大环境的不成熟：虽然近两年来，CMM在我国获得了各界越来越多的关注，但是总体上讲，国内对软件过程的实践还处在初级阶段。而整个软件业对CMM的认识和了解也还很不深入。
    印度是世界上公认的软件强国，国内已有超过6家企业通过了CMM 顶级认证（5级）。同样也是记得陈青在考察印度软件的优势后对媒体谈到，印度有世界上最好的CMM环境，而这种环境中国现在逐渐才开始成熟，但两年前是没有的。例如，国内书店里有很多软件编程语言方面的书，而有关软件管理、软件工程方面的书籍可谓凤毛麟角；然而在印度的书店里情况正好相反，软件管理方面的书籍比编程语言的书要多，各种各样的CMM著作很醒目。
    CMM是一种先进的管理理念，但在一些国内企业中却以一种非常落后的形式实现，使用不正规的工具进行管理；也反映出中国软件企业在工具使用方面还相当落后。另外，落后的又一个重要原因是，我国的CMM评估师太少。目前，全世界获得CMM主任评估师资格的应该有355人，而我国仅有两人。国内企业也少有能力可以培养自己的评估师。这也使得CMM认证市场的发展受到限制。
    以上等等国内软件业大环境发展中存在的不规范与不成熟，在很大程度上导致了国内软件企业对CMM认识和实施的不足。
    2000年6月，国务院颁发了《鼓励软件产业和集成电路产业发展若干政策》，对中国软件企业申请CMM认证给予了积极的支持，起到了极大的推动作用。文件第17条中明确规定鼓励软件出口型企业通过CMM认证，其费用通过中央外贸发展基金适当予以支持。随后，各地方的政府也积极出台了相关的鼓励政策推动企业CMM迈进的步伐。从这一趋势看，中国的软件企业已经开始走上规范化、标准化、国际化的发展道路。但愿在不久的将来，企业面对CMM，将不会再发出“想说爱你不容易”的感叹！

CMM—软件产业发展的必由之路

北京市海淀区质量技术监督局

    发展中国的软件产业，提高我国信息产业特别是软件产业的标准化程度，一直是人们关注的一个问题。为此，无论是领导还是专家学者，对此问题大家都已经发表了许多很好的意见。但是我们觉得仍有一个问题尚未引起大家的足够重视，那就是如何提高软件生产过程的能力，及如何使软件生产过程本身标准化。过去我们往往只重视产品本身的标准化问题，却忽视了产品生产过程的标准化问题。
一、CMM成为发展软件产业的核心
    软件生产能力成熟模型，即CMM（后更名为SW-CMM）模型就是目前国际上最流行也是最实用的一种软件生产过程标准，现已经得到了众多国家软件产业界的认可，成为当今从事规模型软件生产不可缺少的一项内容。
    众所周知，如今我们正处在一个全球性竞争空前激烈的时代，其中信息系统对于各个企业以至企业集团的生存与发展都具有举足轻重的意义。这样一来，就对企业信息系统的开发提出了更加严格和苛刻的要求。例如要求所开发的信息系统更能满足企业战略决策的需要，其中包括缩短开发周期，提高开发效率，扩大实现发展战略的要素等。随之而来的是信息系统的多样化、复杂化，其中包括必须面对需求的多样化和复杂化，以及信息技术的迅速进步。所有这些都对信息系统的开发与管理提出了更高的要求。如何解决这些日益复杂的课题，结论只有一个，就是要实行软件开发生产组织的变革，实现软件开发的标准化，提高软件的生产效率，真正实现软件的工业化。所以，研究、讨论和实践CMM模型及其实现方法既十分必要，又合乎当今信息产业的发展潮流。
    自70年代出现软件危机以来，学术界和企业界对软件工程环境、工具和技术的研究都倾注了大量的人力、财力和物力，多年来也取得了许多成果。但是不可否认的一个事实是软件开发与生产的效果却始终未如人意。以我国为例，近年来我国引进和自行开发的各种软件工具、开发环境等种类繁多，数量浩大，花费达到几十亿元。但由于各种原因，我国的软件开发特别是真正的生产能力依然很差，这显然是一个不争的事实。究其原因，一个不同于以往的概念逐渐被接受：一个企业的软件能力更取决于该企业的过程能力，特别是在软件开发和生产中的成熟度。一个业过程能力越是成熟，该企业的软件生产能力就越有保证。实际上技术或工具并不是第一位的。
二、CMM的核心内容
    在CMM模型及其实践中，企业的过程能力被作为一项关键因素予以考虑。所谓过程能力，是指把企业从事软件开发和生产的过程本身透明化、规范化和运行的强制化。这样一来，就可以把软件开发及生产过程中成功或失败的经验教训变成今后可以借鉴和吸取的营养，大大加快软件生产的成熟程度提高。
    为了加快软件企业成熟程度的提高，必须尽量利用已有的软件工程成果。在软件开发过程中，根据几十年软件工程的发展，一些关键的过程域(KPA)可以被识别出来，成为某些CMM模型方法中的衡量基准。利用过去软件工程发展的成果，侧重这些关键过程域的实施，将会有效地建立一个过程，加快软件企业成熟度的提升。
    为了充分利用已往的软件工程成果，SW-CMM提供了一个基于过去所有软件工程成果的过程改善的框架。这个框架与软件生存周期无关，也与所采用的开发技术无关，根据这个框架开发企业内部具体的软件过程，可极大程度地提高企业按计划的时间和成本提交有质量保证的软件产品的能力。
三、CMM的使用
    在软件开发与生产的过程中，是否采用CMM模型是一件至关重要的核心问题。一般而言，CMM模型根据过程能力逐渐成熟的概念，将CMM的实施分为了五级。从第二级起，每一级包含了不同的KPA,每个KPA都有明确的实施目标，并按公共属性类别定义相应的关键实施活动。以下是对这五个阶段的简要介绍：
    (1)在企业中软件开发基本上处于早期的个人手工开发阶段，这个级别是起始级，没有什么特别要求，仅是一个进化起始点。
    (2)初步形成软件开发与生产的规模化，按软件工程方式进行开发，并通过项目管理使部分结果成为可以重复使用的模块。
    (3)在软件企业中，初步形成部门级的标准，并在部门内部进行培训。
    (4)在软件企业中，把部门标准作为定量化管理的基础。
    (5)在上述步骤的基础上，实现整个软件企业管理的最优化。第五级是进化的最高级。
    从效果而言，在上述不同阶段，软件开发与生产的成熟程度给软件企业带来了完全不同的效果。从第一阶段到第五个阶段，软件开发与生产的计划精度越来越高，每单位工程的生产周期越来越短，每单位工程的成本越来越低。以Raytheon公司为例，该公司现有近400名软件开发人员。公司用了近五年的时间，将其成熟度从第一级提升到第三级，已经收到了明显的效果。为了提升到较高的级别，公司所花费的投资与五年来因成本降低所收到的效益之比为1∶8，直接生产效率提高了大约14倍。该公司所开发的产品在成熟度提升前每千条指令出错率约为0.31条，提升后仅为0.03条。
    提高软件开发与生产的成熟度，可以使新技术的应用收到更好与更快的效果。这主要是因为基于CMM模型的软件成熟度实践要求尽量采用更加规范的开发标准和方法，使用更加科学和精确的度量方法，选择便于管理和使用的开发工具。所有这些，都造成了整个工程的可重构性、可分解性和最优化，从而进一步明确了整个项目中必要和不必要的工作，明确了整个项目的风险，以及各个阶段进行评估的指标与应急措施。此外CMM也不仅仅应用于软件开发组织内，它也可作为认证机构的认证工具和用户评测一个企业是否达到所要求的能力的依据。
四、CMM为我国发展软件产业提供一个机遇
    根据美国卡内基·梅隆大学进行的调查研究报告，即使在美国真正达到后两个级别的软件企业也为数不多，所占比例不足5％，十分重视标准化的日本企业也不足10％。由此可见推行CMM任重而道远。另外，在这一具体问题上，目前我们与发达国家的差距还不算太大。这为我们在这一领域尽快赶上发达国家，并居于世界前列创造了一个机遇，为解决我国软件企业开发生产效率不高的老问题，进一步加快我国软件产业的发展找到了一个突破口。
    由美国卡内基·梅隆大学软件工程研究所最先提出并取得研究成果的CMM模型理论及其应用，是从80年代中期开始的，90年代初正式发表了研究成果。目前这一成果已在北美、欧洲和日本等国家及地区得到了广泛应用，并成为事实上的软件过程改进的工业标准。 　　以我们的近邻日本和韩国为例,他们的若干大型信息技术骨干企业纷纷采纳了CMM模型及其相关标准。日本富士通公司已经根据CMM模型及其相关标准，自行发展了SDEM（Software Development Engineering Methodology）-90标准。根据ISO有关专家实际评测，该标准不仅完全符合ISO9000,而且不少方面还超过了有关国际标准。更重要的是，像SDEM--90之类的企业标准已经成为提高软件生产效率，组织形成大规模的专业化生产的捷径和必由之路。
    据悉，一些印度公司也已通过SW-CMM5级认证，由此也可看出中国和印度软件产业的差距。笔者之所以向大家介绍有关CMM的概念和实践，主要是寄希望于我国的软件企业。我们由衷地希望我国的软件企业在国家的进一步扶植下，走规模化、标准化之路，抓住机遇，迎接挑战，尽早成为我国国民经济一个新的增长点，为我国信息产业的全面腾飞作出更大的贡献。

给CMM打造一个成长的园地
――访软件工程专家网张友生博士

计算机世界记者　　刘佰忠

前言
         这个夏天无疑成了CMM在湖南、也是在中国的发芽季节，软件行业的人们一直在为这个全新的名词感动和期盼。因为，中国软件产品要走向世界，国内软件企业要与国际软件大鳄同台竞争，发展CMM认证的必然之路也就随着这颗幼芽的萌发而众所皆知。湖南的软件企业素有观念前卫的称道，处于行业外部环境的政府和媒体都积极的着软件产业的发展，倡企事业在CMM认证面前，却让人出乎意料。说好的不少，有自己宏图大略的也不少，而真正动起来的太少了。是什么使他们顾虑？又是什么才能真正解开在目前CMM认证上只喊中号、不见耕耘的结呢？本着探究CMM认证在湖南软件企业的发展真谛，记者走访了圈地网络来培育CMM的，国内首家CMM网校（软件工程专家网）发起人之一张友生博士。
把握CMM实质
    大家都在说CMM认证，但是真正说的又很少知道CMM认证是怎么一回事，只知道大家说好，就跟着跳起来说好；大家说难办，费用太大，就喊一圈口号了事，而企业真正需要解决的问题还是连边都没沾上，这就是为数众多的软件企业在CMM认证上目前的表现。放眼全国，在CMM认证上确定起步的就二十多家企业，而号称软件产业底子不薄的湖南也仅创智一家有了动静。由致力于推动软件企业朝CMM认证发展的张博士道来，CMM在中国，目前还处于一个需要培育的阶段，一个从实际意义上让国内软件企业了解的阶段。
    CMM认证进入中国的时间并不久，但是作为国际上衡量软件企业产品质量和生产水平的一项标准、并对改变当前国内软件企业散、小作坊生产等足以起到很大作用和几乎决定软件产品能否超出国门的一剂猛药。
    首先应该怎么看到CMM认证不能与ISO认证同等而论，更不能说过了ISO认证就没有必要进行CMM认证了。ISO认证以生产企业为基础的，CMM认证却是对软件企业的专业认证模式，它的主要意义不在于认证的结果，而在企业达到CMM的认证各级的要求，进而做到规范软件生产流程、提高生产效率和产品质量、迎接中国加入WTO后国外软件产品涌入和国际市场竞争的挑战。
    其次就是应该调整对CMM的看法，认为CMM高不可攀，于是喊几句就了事，也就不能让CMM在企业起到相应的作用。的确，进行一番CMM认证是要花大力气的，动辄数百万，更为拒人于门外的是――最好是500人以上的企业，这在湖南、乃至全国的软件企业当中，都是一个不小的难题，因为大家都规模小啊，用得上吗？对自己来说实际吗？软件企业双大都是民营性质，接一单做一个企业，做完了单还不知企业明天的发展方向在哪，当然也不敢在此作大投入。不妨认为是对CMM认证的恐惧和不了解在起作用。
    最后就是一个放到各行业都有例可循的特色，企业对通过几级的CMM认证特别在乎，甚至暗箱进行操作，在产品质量和生产流程的控制上却玩的是花样功夫。这与CMM实施的初衷是背道而驰的。
给CMM造个园子
    在此，张博士告诉记者，软件工程专家网(www.51cmm.com)的成立仅有两个多月，但是发展的速度相当快。目前已有注册会员21000多人，而且都是国内软件企业中渴望专业知识的群体组合而成，其中最为重要一块CMM网校也有学员800多人，其中以青岛、北京、深圳的人数最多，这应该与当地软件产业发展水平和软件人才整体素质具有很大的联系，而在湖南这一块仅有10多人参加，CMM认证的深入推广和发展的空间都还比较大。
    建立CMM网校，用张博士的话来说，就是给CMM造个园子，让它在里面好好成长。利用他们在这方面的理解和掌握，使国内软件人才对CMM认证的了解更深入了解，同样也只有让大家了解了CMM认证才会来利用其价值，才能有效地应用开来。
培育CMM
    目前国内软件企业进行CMM认证存在几种层面的问题，那么，要推广CMM认证，或者说要应用CMM体系该从何入入手呢？张博士认为，首先，应用CMM认证体系，离不开一个良好的心态，如果纯粹是为了炒炒流行，那就怎么样做都是假的，也不可能做好效果出来，更不能从较深的层面去认识和了解CMM认证，出现ISO等同的思想就不以为怪了。
    其次，CMM认证的本质是应用，不是一纸证书，所以更重要是实施，而不是认证，这对国内大多数从规模和能力上都有待发展的软件企业来说，更需要适时把握，而不能因为CMM评论的要求过高而放弃或等待自己成长起来再说。CMM说穿了就是一个标准，而要达到这个标准的操作流程，而实施到企业的软件生产当中去，实现了生产规范化、产品标准经的市场要求，CMM的价值就能体现出来。籍此，张博士在成立CMM网校的基础上，也在试图在省信息产业厅等政府部门的引导和组织下成立湖南的CMM预审机构，为湖南软件企业的CMM认证起步架好楼梯。
    再次，CMM认证应该回归学校，从大学开始推进。国防科技大学计算机系就已通过ISO9000认证，湖南大学，中南大学，以及国内在软件人才培训较为出色的院校，对CMM认证的了解不能停留在书面和理论上，这对学生走向操作CMM体系也是一大障碍。
    说到最后，要实施CMM体系并不如一些人认为那般可怕，那般不切实际。企业了解和懂得了CMM的操作过程，再用以来约束和规范自己的生产，提高管理能力，就是很好的开始。

基于CMM实施软件过程改进的成功策略

51CMM原创 作者：任甲林

    基于CMM的软件过程改进已经被越来越多中国的软件企业所接受，目前，在中国已经掀起了一个CMM评估的小高潮， 但是，通过评估不是企业的最终目的，对软件企业而言其根本的利益是通过实施软件过程改进，提高企业的管理水平。CMM作为美国军方评价软件过程能力的一个模型，他是在研究了美国的一些较大的管理基础较好的软件企业提出来，针对中国软件企业的实际需要灵活裁剪，而且，在CMM中也没有告诉企业如何按照此标准进行企业的过程改善。笔者从98起开始主持一个企业的软件过程改善项目，在这3年的时间里，积累了大量的经验教训，现概括出6条策略，供正在或准备实施CMM的软件企业参考。
策略一：自低向上，主动改进
    在进行软件过程改善的时候，通常有两种做法，我称之为自顶下与自低向上。在自顶向下的做法中，企业成立一个推进小组，一般称为SEPG（软件工程过程组），他们是企业里"开发大法"制定的组织者。SEPG组织一些开发人员成立各种任务小组，由这些任务小组根据进行过程改善参照的标准编写各种各样的企业的标准与规范，经过一系列的评审、培训，然后让开发人员去执行。在执行过程中最常见的阻力是来自于开发人员，他们往往会抱怨制定的企业开发规范不符合企业的实际情况，标准太高，无法达到。 这一种做法，费时费力不讨好，大家的意见都比较大，标准定的比较完美，而且在评审时还要大家表面上都要认可，制定标准的人花费了很大的精力，对标准的评审浪费了大家的很多的时间，执行时还难以贯彻下去。这种方式98年、99年上半年我在企业里采用过，收效甚微。后来我们降低了要求，抛弃了各种标准与规范，采用了一种简单易行的策略，自低向上的办法，即由SEPG找开发人员、项目经理让他们自我发现问题：你有什么缺点？你将如何改进？好，在开发人员、项目管理人员讲自己的改进措施后，让他们确保能做到。在这种办法中，不需要管理人员花费太多的精力进行标准的制定，改进的推动，这些工作都是由开发人员自己去做的，管理人员仅仅是起到了监督的作用，只要开发人员自己说到做到就可以了。再做下一个项目时，管理人员同样会问这2个问题：你有什么缺点？你将如何改进？然后管理人员监督开发人员说到做到。在这个过程中逐步完善形成标准与规范。
    在上面的两中方法中，我们可以从几个方面进行比较：
    当然采用第2种方法时，你一定要目标明确，你是要改进过程，而不是为了在短时间内通过评估。
策略二：循序渐进，由易到难，由粗到细，由松到严
    CMM的一个核心思想是分级改进，在CMM模型中将软件企业的过程能力分成了5级，有很多企业很可能违背了分级改进的思想，搞了一场革命，期望短时间内提高管理水平，那显然是不现实的，我们要需要的是改良而不是革命。分级改进实际上就是要循序渐进，你能一步做到2级吗？不可能的，对于2级的每个KPA，可能你先实现了每个KPA的一部分活动，稳定了，再实施另外一部分活动，如果你现在1级，想一下子将2级的所有的KPA的所有活动都满足是不现实的。在实施CMM的过程中一定要根据企业的实际情况量力而行，千万不要期望值太高，要一步一步来。先定出最基本的改进方案，然后逐步提高，要把握分级改进的思想。
    要做到循序渐进，首先要对企业现状有一个明确清醒的认识，在分析现状时，下面的四个问题是必须要解答的：
    当前我们存在哪些问题（当然，问题可能很多）？
    哪些问题是我们迫切需要解决的？
    哪些问题是我们目前能够解决的？
    哪些问题是我们当前无法解决，需要打好基础后才可以解决的？
    接下来要对照标准，提出解决方案。按照"力所能及，有所提?quot;的原则对问题排出优先级。
    以SPP、SPTO这2个KPA来说，你可能可以采取5次循环达到CMM2级的要求：
第一次循环：从无到有，使项目组成员熟悉做计划的过程，熟悉项目计划跟踪的重要性。
    第一步：要求每个项目组都要用PROJECT 2000做项目计划，该项目计划要满足一定的条件，如：
    任务的颗粒度不能太大；
    任务负载要均衡；
    任务尽可能并行；
    等等。
    第二步：对每个项目组，按计划进度进行跟踪，在计划执行过程中及时发现问题，解决问题。
    第三步：总结本次循环执行过程中存在的问题，如：
    项目计划中任务识别不全；
    计划的任务工作量估算不准；
    在项目进行过程中，发现问题后采取措施不及时等等。
第二次循环：增加完整的生命周期模型定义
    生命周期模型是项目管理的管理的主线，定义一个好的生命周期是推行CMM2级的一个最关键的基础工作。
    第一步：要求每个项目组首先要定义出自己的生命周期模型，做出项目计划模版
    第二步：要求每个项目组按照项目计划模版进行做项目计划
    第三步：进行项目计划跟踪
第三次循环：增加规模、工作量等的度量
    第一步：要对项目的规模、工作量进行正式的估计
    第二步：按计划摸版做项目计划
    第三步：进行项目计划跟踪
第四次循环：增加风险分析
    项目的风险管理对于国内的软件公司而言，一般都是一个难点，可能风险很多，风险可以预见，但是没有很好的规避措施。所以建议将风险管理放在较后的循环中来改进。
第五次循环：体系化，制度化
    开始时要求不要太严，对文档的要求要粗一些，要把握住实质而不是皮毛。
策略三：教育与培训并重
    任何一种标准的推广总会将培训放在一个很高的位置上，我不太喜欢用培训这个词，我更喜欢用教育这个词，我们的一个关键目的不是告诉他技能，而是要改变他们的思想，因此，首先要做的工作是教育。要让各个方面的人都能够接受这些先进的思想，以便于主观上认可，客观上配合。进行教育有各种方式，需要配合起来使用：
    观摩学习：看看别的做的好的企业是如何做的？和别的企业的管理人员多沟通交流。尤其是对企业的高层管理人员这点很关键。
    请外面的专家来讲：俗语讲的好"外来的和尚好念经"，这句话屡试不爽，企业内的人说多遍可能效果甚微，外面的专家讲一句，一下就点透了，接受了。
    自我反省：开发人员进行自我分析找出自己的不足，并提出改进意见，大家互相沟通交流这些经验教训，自己教育自己。
    补上"教"：我们的很多软件工程师、项目经理的经验并不是很充分，也可能比较固执，不撞南墙不回头，没关系，允许他犯错误，但是要有人帮他记录他的错误，提醒他认识自己的不足，加深他的印象。
    培训：培训可以分成多种：技术型培训与管理型培训，这是最基本的工作，思想工作做通了，培训起来效果就会比较好。 　　SPI不能仅仅定义为开发部门的工作，需要整个企业的所有人员的参与和重视，因此教育与培训的对象比较多，不要有遗漏，如：
    高层管理人员：为什么要进行SPI？在过程中会出现什么问题？对公司有哪些正面与负面的影响？需要领导配合做哪些工作？要认识到工作的艰巨性。
    开发管理人员：技术与管理知识
    开发人员：技术与管理知识
    市场人员：要认识到SPI的重要性，对市场的影响，在此过程中如何配合？
    客户：对于一个项目而言，需要提出合理的进度、质量与投入的要求，并把握好需求的范围。
策略四：测试先行
    尽管测试在CMM中没有作为一个单独的KPA存在，但是，加强测试却是我们实施CMM的一个很好的策略。在管理基础薄弱的软件企业里面，通过加强软件测试，可以直观地发现很多问题，从而使大家认识到质量的重要性，认识到进行过程改进的重要性，事实胜于雄辩；另一方面也减少了用户发现错误的概率。在很多软件企业里面并没有专职的测试人员，测试一般是有项目组自己进行，而且往往也是在项目结束时才进行测试，在项目进行过程中很少进行测试，这就是现状。
    设立专职的测试，让他们在开发过程中参与测试，可以发现项目开发过程中的很多问题，如：
    项目组提交给测试人员的文档太简单，测试人员无法看懂；
    项目组提交的文档与实际做出来的软件不一致，测试人员无法测试；
    项目修改了需求与设计，没有及时通知相关人员，测试人员按旧的设计测试，有的开发人员按新设计开发，有的开发人员按旧的设计开发；
    不同的模块界面风格差别很大，没有统一的界面标准；
    测试人员测试的版本与开发人员开发的版本不统一；
    项目组成员的分工不合理。有的开发人员任务重，而他开发的软件缺陷特别多，有的模块缺陷就特别多，可能设计人员的能力比较弱；
    项目组没有按计划提交测试，项目拖期；
    软件运行速度很慢，怀疑系统的设计有问题；
    ……… 　　通过对错误原因的分析，可以发现大量的管理问题、需求的问题、与设计的问题没，这些实在的统计数字对我们找出最关键的改进点、说服反对派、教育软件工程师、加快SPI的推进是一个有力的武器。
策略五："因材施教，各个击破"
    在一个企业内可能有个开发项目组或者开发部门，不同的组与部门原来就有不同的管理水平，在我们推行CMM时，不要一刀切，不要希望每个队伍同时达到CMM2级或更高的级别，应该区分对待。比如说做产品的部门，经常进行大大小小的各种各样的升级，产品的版本比较多，他们对版本管理的工作认识的很深刻，在工作中积累了一套行之有效的版本管理的方法，版本管理比较正规，对于这样的部门可以实施配置管理KPA的要求，进一步提高管理水平，而对于其他做系统集成的部门这方面的工作可能就差一些，没有很好的版本管理的基础。因此，如果一刀切，要求大家都在3个月内达到CMM2级的要求，这个目标对系统集成的部门讲，就定的太高了。当然通过一场运动来提高管理水平是可以尝试的，但往往是不能持久的。
    所以在进行改进时应针对不同的项目组、不同的部门定出不同的改进计划，如可以采用下表的方式来定义不同项目组、不同KPA的阶段计划：

策略六：充分利用管理工具
    管理工具可以做为思想、方法的载体，他可以将管理有形化、客观化，降低劳动强度，解决手工无法解决的问题，易于为开发人员、管理人员所接受。充分利用管理工具来推行SPI的一个很好的策略。
    很早我们就引进了MKS SI配置管理工具，Poject 98计划工具，SQA 测试工具以及QA monitor等其他的一些管理工具。开始引入的时候是有些难度，毕竟是对工作方法产生了改变，一旦熟练了，就习惯了，目前它们已经成了大家在工作中必不可少的工具。
    对工具的选择与购买需要把握好"够用既可"的原则。软件开发管理工具一般比较昂贵，如果一次性投资购买了比较昂贵的软件，可能软件的80%的功能用不上，等企业的管理提高到工具软件可以支持的较高的管理水平，已经是2年以后的事情了，而2年以后的版本也需要升级更新了，所以，没有必要为用不到的80%的功能提前投资。

中国如何引进CMM评估，促进软件产业发展

北京软件行业协会

一、CMM的含义及作用
    CMM（软件能力成熟度模型：Capability Maturity Model For Software）是由美国卡内基梅 隆大学的软件工程研究所（SEI：Software Engineering Institute）受美国国防部委托研究制定 并在美国，随后在全世界推广实施的一种软件评估标准，主要用于软件开发过程和软件开发能力 的评估和改进。
    CMM软件评估标准是从1930年开始的近代质量管理理论与实践基础上发展起来的。1986年美国 卡内基梅隆大学由联邦政府赞助成立了软件工程研究所（SEI），1991年SEI采访了100多家软件公 司，开发出了CMM 1.0版本，1993年又推出了1.1版本。CMM把软件开发过程的成熟度由低到高分为 五级，即初始级、可重复级、已定义级、已管理级和优化级。随着CMM等级的提高，逐步降低了软 件开发风险，缩短了开发时间，降低了软件开发的人力物力成本，降低了灾难性的错误发生率， 提高了质量。CMM评估等级的提升会大幅度提高软件开发能力，有助于客户特别是大公司对该软件 企业建立信心，并向该软件企业下订单采购软件产品。
    我国软件要大幅度提高开发能力，走向世界，必须向国际上公认的软件评估标准靠拢。目前 北京的软件出口约占全国软件出口的三分之二，而美国的软件市场约占世界软件市场的三分之 二，这两个三分之二如何对接？即北京的软件产业如何能够开拓美国市场，关键之一就是要获得 CMM认证的通行证。印度软件企业因通过CMM认证而大量出口软件到美国为我们提供了先例。
二、美国、欧洲和印度的经验表明：CMM确能促进软件产业发展
1．CMM在美国
    现在美国10-15%的软件客户都是大公司，如波音公司、洛克希德公司等，他们一般都要求软 件供应商通过较高级别的CMM评估。
2．CMM在欧洲
    欧洲许多国家除独立研究与实践有关软件成熟度的软件工程理论和方法外，也引进了CMM评 估。英国著名的路透集团就是其中之一，该集团于1998年通过了CMM 2级评估，计划于今年通过3 级评估。在CMM评估中，对包括经理在内的所有员工都进行了培训，目前已有64名从事CMM评估的 全职人员。
3．CMM在印度
    印度的Infosys是拥有约4500名员工的大软件公司，已于1999年通过CMM 5级评估。1991年前 该公司软件开发没有执行标准，软件开发水平仅取决于开发人员个人的努力和高级主管对未来的 预测。随着软件开发领域的扩大，公司决策人意识到在公司中必须实施软件规范，1992年起按ISO 9001标准去做，1993年通过了ISO 9001论证。从1993年起又开始CMM评估，由1级一直提升到5级。 大幅度提高了软件开发能力，保证了向美国和欧洲软件出口的高增长，现在为《财富》杂志排名 前500家企业中的许多家提供应用软件。Infosys公司的CMM专家K.Dinesh先生在论坛上介绍了以上 情况后着重谈了个人的体会：CMM是一个很好的软件标准，可以给软件企业带来好处，但CMM能否 实施成功，取决于人的努力。在实施CMM中，职工要改变原来的习惯，每个人都要制定自己的目 标。软件质量由人 + 技术 + 过程决定。三个因素如同一张桌子的三条腿，每条腿都重要。
    印度的QAI公司是从事服务和软件开发的公司，积极参加CMM评估，现在是印度唯一专门从事 CMM评估的公司，也是亚洲第一个具有CMM评估资质机构。QAI的商务经理V. Manghani先生在论坛 上介绍了通过CMM评估提高印度软件产业整体水平的情况。印度的软件产值从10年前的5000万美元 增长到1998-1999年度的40亿美元，保持了50%以上的年增长率。目前印度有约1000家软件企业， 28万软件人员，仅次于美国。
    《财富》杂志中排名前500家企业中有200多家都是印度软件企业的 客户。印度在软件领域中取得好成绩的原因有：软件开发成本低、英语能力好、技术水平高、教育制度保证有顶尖人才参加软件开发、软件人员待遇高、员工对公司忠诚度好、采用好的质量管 理方法等。印度很多软件公司10年来一直进行软件过程改进，他们认识到只采用一种框架不能提 供很好的产品，因应采用混合性标准，主要有：ISO9001、CMM、P-CMM（个人软件开发成熟度模 型）、总体质量管理等。现印度有100多家软件企业通过了ISO9001论证，越来越多的企业认识到 应逐步采用CMM评估标准。
三、我国如何根据国情引进CMM评估
1． CMM是一种过程较复杂、费用较昂贵的评估
    CMM评估包括5个等级，共计18个关键过程域，52个目标，300多个关键实践。每一个CMM等级 评估周期（从准备到完成）约需12-30个月。每一级别的评估由美国卡内基梅隆大学的软件工程研 究所授权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。评估过程包括员工 培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导 讨论和撰写评估报告等。评估结束由主任评估师签字生效。 　　要取得主任评估师的资格比较困难，首先要有10年以上的软件开发经验；其次要在美国卡内 基梅隆大学的软件工程研究所接受培训，培训费用每人约需数万美元，非美国人加倍；第三要经 过两次以上CMM评估的全过程实习；第四要得到已有主任评估师资格的人推荐。主任评估师的资格 并非终身制，如要继续保持，每年至少要参加两次CMM评估。目前全世界一共只有313个主任评估 师，大部分在美国，而我国大陆还没有一个主任评估师。
    由于我国在CMM评估中要聘请外籍主任评估师，所以费用较高。据估计，要通过一个级别的 CMM评估，费用是通过ISO9001认证的十多倍。
2． ISO9001与CMM的关系
    国际标准化组织ISO9000系列质量保证体系用于制造业的是ISO9001（在软件行业的实施指南 为ISO9000－3），与CMM均可作为软件企业的过程改善框架，前者面向合同环境，站在用户立场对 质量要素进行控制，而后者是对软件组织内部过程能力的逐步改善。
    ISO9001与CMM是强相关的，ISO9001不覆盖CMM，CMM也不完全覆盖ISO9000。一般言，通过ISO 9001认证的企业可达到CMM 2级或略高的程度，通过CMM 3级的企业只要稍做补充，就可较容易地 通过ISO 9001认证。粗略地说，ISO 9001近似于CMM “2.5级”。
    ISO 9001约有80%的文件可以用于CMM 2级评估。
3． CMM与工具
    CMM评估只定义了要做什么，但没有定义如何做。一般说，CMM评估主要考虑的是达到各个级 别的要求，至于工具通常就是利用现有的数据库软件和办公软件（如Microsoft公司的Excel）， 专门的工具很少。
    北京鼎新信息系统开发有限公司在CMM评估实践的基础上，开发了一个基于Lotus Domino / Notes的软件开发过程管理工具：项目助手2000。
4．CMM评估的文化背景
    在CMM讨论会上，有人问已通过CMM 5级评估的印度Infosys公司的K.Dinesh先生，已通过了5 级，是否已万事大吉？回答是：“通过CMM 5级，只是万里长征的第一步。为了保持市场份额，还 要做许多工作”。显然，印度既看重CMM评估，但更看重市场，通过CMM评估只是更好地进行市场竞 争的手段，在市场竞争中任何时候都不能掉以轻心的。
    国外CMM等级评估生效，只需要主任评估师的签字，既没有某主管单位的批准，也没有盖上公 章的证书。显然，国外更看重主任评估师及公司的信誉。
5．我国的软件企业应根据自己的实际情况引进CMM评估方法
    在引进CMM中，要根据软件企业的实际情况，大致可分为两类：
    有软件出口的企业，应逐步通过CMM等级评估，以提高在国际市场上的竞争力。
    一般软件企业可以借鉴CMM的方法，改进软件企业的管理，提高软件开发水平。
    当前国内比较容易着手做的工作是：进行CMM的普及性培训，请已通过CMM某级别的软件企业 代表介绍经验等。

在中国开展CMM评估的几点建议

周伯生

    从美国的软件产业发展可以看到，软件产业有结构化生产方式（1975年－1995年）、以过程为中心的生产方式（1985年－2005年）和工业化生产方式（1995－今）等三个发展阶段。
    我国软件组织在软件过程的现状可以概括为以下三个方面：第一，我国正在由结构化生产方式向以过程为中心的生产方式和工业化生产方式前进。目前已有很多企业（不论是国营或者民营公司）认识到要按CMM改进软件过程，实施科学化、系统化的管理，以提高组织的软件能力成熟度，这表明具备了改善自我的强大动力。第二，目前在前进的道路上仍然有一些困难，如一些组织想通过ISO9000和CMM提高能力成熟度，但是他们不熟悉CMM的概念，也不知道CMM和ISO9000之间究竟有哪些区别。大部分软件组织在软件工程理论和实践两方面都比较薄弱，虽建立了软件过程，但过程阶段不明显，软件生产无序，对进度，预算，质量的预测和控制不得力，常常在遇到问题时就放弃原定计划，重视编程与测试，忽略需求分析和构架设计。高层管理对软件管理尚未引起足够的重视，没有配备足够的资源或合格的人员承担过程改善工作。第三，缺少文档化的过程描述，特别是缺少工作文档（如过程中的变更请求报告）、工作量统计文档（如时间和工作量统计表，周状态报告）和风险管理文档（如风险估计报告、风险评测报告）。缺乏对过程和产品进行测量，软件过程的历史数据很少，因此很难基于历史数据对工作量和进度进行合理的估计。各个软件组织应该基于对目前状态的了解，按照CMM标准找出存在的差距。差距就是不够成熟的地方，也正是应该加强改善软件过程管理的地方。
    软件过程改进是一种含有大量管理成分的工作技术，它主要包括以下三个关键步骤：对比目前的状态和期望达到的状态，找出存在的差距；确定要改变哪一些差距，要改变到什么程度；制定相应的具体实施计划，其中的“具体”是指：要有明确的，可以检验的目标；要定出检验成功与否的标准；要有具体的实施办法；指定具体执行计划的人，并明确具体的职责与任务；要明确执行计划的主要领导或协调者，以负责解决在计划执行中出现的问题；要列出“实施计划”所应用的新技术与新工具以及如何获得这些新技术与新工具。
    我国软件产业方兴未艾，实施CMM可以在起跑线上改变我国的软件工程文化，改善软件人员的素质，不仅对我国的经济具有重要意义，也是提高软件企业素质，增强软件企业的国际竞争力的必要前提，而且还为软件的出口创汇创造了条件。CMM是一个较好的软件改善框架，但CMM只给出做什么，并没有给出如何做。因此要认真研究如何遵循CMM模型进行具体操作的问题。
    为了更好地理解CMM，提高软件组织的过程管理能力，顺利通过CMM评估，基于我们对 CMM的研究与评估实践，给出如下建议：高层管理应该把更多的注意力放在过程改善上，设立过程改善的专职队伍。这一方面是因为过程改善是思想观念和工作方式的改变，是企业文化的转变，它涉及到企业中绝大部分工作人员。另一方面是因为以过程为中心是软件工业化生产的三大支柱之一，只有高度重视，加强研究，学习和实践，才能真正使软件生产向产业化方向迈进。
    在软件过程改善上应配备必要的资源，要建立一支有相当规模的改进队伍，在投资上应达到足够的力度。在组织内部，首先要建立软件工程过程组（称为SEPG），负责软件过程改进任务，并挑选合格的人员担任全职的SEPG组长。根据国外经验，一般需要占该软件组织中开发资源的5％～10％，根据世界上近1800个组织的评估实践证明，进行CMM评估的效益是投入的4倍～8倍。
    建立合适的组织结构，研究软件工程理论和软件过程改进方法，负责制定和实施过程改进计划，他们是实现企业评估活动的具体组织者。在执行计划的过程中，注意检查它的遵从性，如遇偏离，应研究原因，并采取相应的纠正行动，他们是企业进行定期过程诊断的内部评估师和企业过程改进活动的监控者。
    要加强培训工作，开展能力成熟度评估既要有高素质的主任评估师，也要有相当的过程评估队伍，更要有庞大的过程改善队伍。要认识到只有高素质的人员，执行成熟的良好过程，才能生产出好的产品，应普遍开展CMM及软件工程基础的培训，使每个岗位的人员都具备过程改进的意识，并掌握所必要的过程改进知识和技能。
    测量数据是进行过程改进的基础，要重视过程与产品的测量过程。在项目的整个开发过程中，特别是在里程碑处，要收集过程的执行数据，记录活动状态，既为当前项目的测量和分析提供数据，又可作为历史数据保留下来为今后的项目参考。这些数据主要包括：软件规模、工作量、成本和进度的估计数据和实际数据，产品质量测量数据，需求变化情况以及风险分析数据等。
    应重视软件配置管理及配置管理工具的开发。配置管理最主要的目的是在项目的整个软件生命周期中建立和维护软件项目产品的完整性，系统地控制对配置项的改变，并管理组织的软件工程资产。配置管理的内容繁多，权限管理复杂，开发或采购合适的配置管理工具是非常必要的。
    在我国开发CMM评估，既要注意智力引进，聘请国外的主任评估师为我国进行过程评估，更要着力培养我国自己称职的主任评估师。这不仅还是因为中国是一个潜在的IT 大国，而且还因为CMM实施与一个国家的文化密切相关。此外，改善软件过程本身也是一个过程，需要长期地得到有资格的主任评估师的帮助。各行各业的主管部门都要扶持和支持培养我国自己的主任评估师，把培养主任评估师看作是转变观念和创新知识的新产品。要充分认识到过程改善工作的长期性与艰巨性。过程成熟度升级本身就是一个过程，而且有一个生命周期。因此，过程改善工作必然具有一切过程所具有的固有特征，不能急功近利。
    在CMM评估工作中，要提倡将能力成熟度模型CMM与个体软件过程PSP以及群组软件过程ISP有机地结合起来，同时密切注意过程改进的新动向。各地应在软件产业主管部门的支持和协调下，统筹社会各界的力量，加大软件过程改进的研究、评估和实施的力度，把我国的软件产业推向前进。首先要在企业内部建立庞大的过程改进队伍，积极研究、实践和推动过程改进工作。认真建立CMM主任评估师队伍，认真建立各门有关课程的合格的教员队伍。还要通过市场竞争机制，扶植和建立过程改进的咨询机构和中介机构。

CMM评估中存在的若干问题

来自：www.csdn.net

本文欢迎转载，欢迎大家来信交流讨论。
联系方式：高巍（网名DrCMM）， w-gao@263.net，13851926012 。
转载时请保留本声明，谢谢。 前言：本文部分内容参考了2000年2月IEEE杂志上的一篇文章。该文作者从采购方和软件企业方分析了SCE中存在的若干问题，最后发问：“CMM评估还可信吗？” 中国软件企业的CMM评估，一开始就充满了浮躁、做秀和功利的气息。整个CMM评估的过程，我们看到的是好大喜功的政府行业主管部门、一贯爱凑热闹的新闻媒体、有赚白不赚的中介机构、证书随身带的主任评估师和愿意花钱买吆喝的软件企业。CMM评估的这种浓厚的功利性，使得“Gaming the Assessment”成为软件企业上上下下的共识和“不宣之秘”。希望本文对国内软件业界正确对待CMM起到应有作用，不要像某些软件企业一样找个“证书随身带”、“一手交钱，一手交证”的主任评估师。毕竟，提高企业的核心竞争力是最重要的。
1 评估人员的资质
SEI对主任评估师的资质要求比较严格，但是评估是由一个评估小组来进行的。
问题1：评估组员的资质很难满足。
通常，评估组员很难达到SEI所要求的软件工程的技术和管理背景。
问题2：评估人员多是管理人员，技术素质普遍较弱。
这个问题也包括主任评估师，由于多年脱离软件开发实践工作，主任评估师甚至在提问时有意回避技术问题，而是反复询问管理问题。因为评估人员的技术素质普遍较弱，因此对于CMM中涉及工程部分的关键实践解释能力很差。甚至在对企业员工面试时，当员工提到技术方面问题时，评估人员会将话题岔开，又转到管理问题上。
2 评估的时间压力
一般评估的时间都在一周左右，要执行的工作相当多，时间压力很大。原来的评估方法中要求单个面试的方式，后来迫于时间压力，新版本中增加了“Group Interview”（团体面试）。
问题3：团体面试本来是为了节省时间，实际上往往掩盖了问题，不能发现真实情况。
联想测试部门的面试，就是团体面试的方式。
对于评估小组而言，由于时间紧张，他们往往不愿意运用自己的洞察力和专业判断力，而是满足于在检查清单上一项一项划勾，也就是俗称的“Checklist强迫症”。
问题4：“Checklist强迫症”也给了软件企业一个钻空子的机会。
软件企业可以努力使文档做得更加“方便评估小组的工作”。
3 CMM问卷
在CMM评估中，用到的是同一套问卷。连美国人都批评到，“不可想像对于医生、建筑师或者律师采用同一套试卷来考察，而对于软件企业的评估使用的确实一套不变的问卷。想想看，这些软件企业可能是在为我们的国防系统进行开发！”
问题5：同一套成熟度问卷。
CMM评估允许企业在评估前对员工作出培训，而这个培训的作用往往被扭曲了。很多软件企业甚至“教唆”员工在成熟度问卷上如何回答的“更成熟”一点。
4 文档
因为CMM评估要求文档应该有在线版本（这样才可以被配置管理软件所管理和控制），所以企业在将文档转换为在线版本时，就可以对文档作出修饰。因为知道评估小组的时间很紧张，软件企业可以把文档弄得故意非常复杂，评估小组有时候看到复杂得文档，会不愿意去深究，认为既然写了这么多，看在页数得份上，也应该满足要求。
问题6：过分依赖文档。
5 项目的选择
选择什么项目给评估小组看，这里大有学问。软件企业可以把自己最“成熟”的项目、最优秀的员工组成一个“Goldern Project”来供评估小组检查。那么，这样的评估可信性就大打折扣。比如，国内某软件企业明明是自己一个20多人的“中央研究院”过了CMM某个级别，在媒体宣传时却故意混淆视听，有意无意造成整个企业通过某个级别的错觉。
问题7：选择什么项目，选择什么部门，这其中太多猫腻。
6 事先“培训”员工
甚至有这样的现象，员工在接受面试之前，塞给他一本企业的CMM指导手册，甚至要求他故意在手册上作点笔记、把手册弄得脏一点，以显得认真阅读过了。
问题8：“培训”员工作假。
这里最严重的问题，实际上是主任评估师的技术素质。计算机技术领域日新月异的发展，很多主任评估师是只知道“管理”，对于技术的理解可能仅仅限于5－10年前的技术。IEEE杂志文章的作者建议，在评估时应该同时“Conduct on-site technical evaluations”，观察企业的开发人员实际完成技术工作的方式。作者特别举了一个企业的例子，纸面上的同行评审与实际中的同行评审的天渊之别。
Paul在给联想评估时，竟然没有向测试部门提问，这个事实太令我失望了。其他领域不论，我真的不信对于测试领域竟然无话可问！

国内软件企业实施CMM的四大障碍

雅行

    近来，CMM获得了各界越来越多的关注，motorala（中国）过了五级，鼎新过了二级，其他不少企业如华为、浪潮国强、联想、东大阿尔派、天大天财、创智、亚信等一批企业都在进行研究 、试验或者实施预评估。国家发布的关于促进IT业发展的18号文件，以及软件企业资格认证等有关文件中，都鼓励企业实施CMM，珠海开发区规定了通过二级一次性奖励50万元的政策。预计未来2、3年内，国内将出现软件业实施CMM的高潮。但是，根据笔者对于ISO9000标准的实践和对于CMM体系的比较研究，认为，未来在中国企业实施CMM的过程中，存在着如下的障碍：
一、制度化理念与既有企业文化的冲突
    体系实施是遇到的诸多问题，包括领导重视程度不够，开发人员、项目经理抵触情绪，质保人员和软件工程人员得不到应有的尊重和权威等等，归根结底是文化冲突。ISO9000和CMM体系都是基于法治的体系，而国人普遍习惯于人治的氛围，大到整个国家小到一个企业莫不如此，这种冲突正是很多问题的根源。
    以CMM的组织结构为例，它推荐在最高领导之下设立SEPG（软件工程过程组）、SQA（质量保证组）、SEG（软件工程组）,这三个组构成是立法、监督和执法的制衡体系，体现的是西方文化的法治观念。而我们在整体企业管理上推行制度化都困难重重，何况是质量管理。这种冲突体现在两个层面上，一是社会的文化环境与少数企业制度化要求的冲突，二是企业基础管理的不完全制度化和质量管理的制度化特质的冲突。 最近，由于媒体的不断炒作， CMM概念大行其道，软件业似乎找到了新的救命稻草。殊不知，CMM和ISO9000并无本质区别，实施ISO9000遇到的困惑，在CMM中也一定会遇到，他们的基本要求不外乎：
－形成文档化的制度、规范和模板
－严格按照制度办事
－按照要求形成必要的记录
－检查和监督和持续改善
    而以上这些正是我们不喜欢的东西，但是抛弃这些，制度化管理还能剩下什么呢？看来，想要花点钱，造个省心的简便的办法是不可能行的通的，不管什么样的体系，都得踏踏实实去做，该面对的困难迟早还是要面对的。
二、ISO9000咨询中的问题对市场的抑制作用
    以往企业做ISO9000过程中发生的种种问题，造成了社会上对类似质量管理体系的怀疑态度，也会成为企业实施CMM的障碍。特别是，CMM的实施不是在短时间内可以看到显著成效的，它强调“逐步改进”，而非突变。每升一个级别可能会花费1－2年。这样的情况下，如果企业管理者没有一个坚定的支持态度，很难保证实施不被半途而废。而这样的失败又成了新的打击人们信心的案例，造成恶性循环。 我们常说，“企业实施ISO9000，最高领导的支持是关键“，其实这句话还应改为“企业实施ISO9000，最高领导的亲身参与是关键”更好。因为，每个企业实施ISO9000,肯定都获得了领导的支持，但是当实施过程中碰到一次又一次的抵触和碰撞时，试问，又有多少领导还能保持十足信心？再加上市场上的一些负面言论，体系实施往往从这时候开始被一步步遗忘掉。。。所以，领导不仅是支持，应该有高层领导亲身参与，不是表面上的，而是抱着一个坚定的信心，执着的投入到里面去。对于为此会付出多少辛苦、时间精力、资源都应该有充分的心里准备。把推行质量管理当作企业推行全面制度化的一个手段和阶梯。 高层领导亲身参与的头一个好处是，由于不断地研究，他会成为此中专家，所以能够保持其自信，而不被市场和现实的噪音所影响；第二个好处是可以有效的触动原体制下的深层次缺陷，有些潜在问题是质量管理经理推不动或或没有能力看到的。
    从整个企业的层面来看，通过实施质量体系，事实上改造了原有企业文化，使制度化的观念深入人心，为企业引入西方先进的管理思想、推行全面的制度化管理奠定了思想和文化基础。
三、企业人员的质量和质量管理意识有待提高
    任何体系的实施都离不开其主体－人。企业实施质量体系过程中各层次人员进行不同的定向培训。对于开发人员来说加强软件工程的培训和实践应从学校教育就开始，进入企业后再进行有针对性的再教育。有些规模比较大的国外企业入职再教育的时间可能长达1－2个月。国内企业却常常抱怨没有时间和不愿意为此投入资金，造成体系的贯彻没有基础。
    不仅是对于开发人员，对于项目管理人员的管理培训，对体系的实施起着至关重要的作用。因为项目管理人员处在承上启下的关键位置，体系的落实、组内配置管理、组内质量数据的收集等都离不开这一层管理人员的配合。而实际情况是，项目管理人员往往都是从技术出身，管理意识不足是普遍存在地问题。这层管理人员进行强化的质量意识培训和项目管理培训是非常迫切的。如果通过培训能使大家明白怎样做一个合格“科研管理人员”，真正增强其管理的意识，会发现项目经理会主动配合质量管理工作，因为他们认识到，质量管理其实是项目管理职能中非常重要的部分。
四、顾问公司水平和服务亟待改善
    ISO9000和CMM都只提要求，没有告诉怎么做，具体的实施和应用需要由顾问公司协同企业来做。当前，顾问公司所提供的服务是浅层次咨询，只是把标准的知识引进来，怎么使用基本是企业来琢磨，最后顾问公司再验证要素的覆盖程度。顾问公司不对体系的效率负责，只管要素覆盖，是因为要素覆盖是与拿证书相关的。强调在原模式的基础上建立ISO9000体系，而不能进行流程重组。这其实反映了顾问公司的非专业化，只对质量管理熟悉，对其它管理不了解，对细分的行业特征不了解。这个观念我觉得要转变，一个好的顾问公司应该协同顾客研究其流程，提出重组的建议，流程的建立不仅要考虑要素覆盖还要兼顾流程效率。实施参与深度不够是一方面，参与时间也偏短，我们一般一个咨询周期6－8月，而国外1－2年的周期是很多的。6个月的时间往往只是体系的初步建立，还很粗糙，要运行和完善为一个比较可行的的体系，还需要大量的时间，这个过程仍然不能没有咨询公司的参与和指导。
    以上所列问题，是企业实施CMM时应该有心里准备并准备付出努力的方面，也是各企业管理人员、顾问公司应该着力研究的方面，我相信，只有这些问题能够很好的解决，CMM的实施才会真正获得成功，企业告别作坊式管理的愿望才能真正实现

CMM给我们带来了什么

（转载自软件世界）

    软件生产一般包括“需求管理”、“流程设计管理”、“开发管理”、“测试管理”等主要过程。那么，软件的质量管理是从哪一个环节开始的呢？不是从设计阶段，更不是开发阶段，而是从软件需求阶段就开始了。在软件生产过程中，“软件需求”的调查报告是一个生产过程的开始，软件质量的管理之路也就随之开始了。
为什么要管理软件需求
    简单讲，软件开发团队的成功就是满足软件项目的需求。当今世界对软件的依赖程度急剧增长，面对质量和交付周期的固有矛盾以及各种动态因素的综合作用，软件需求日益复杂，软件开发成为一项跨越技能、职责范围和时间阶段的综合团队活动，协调统一是成功的必要条件。软件需求是统一的核心线索，需求管理正是协调的必由之路。
    严格意义上，需求是系统或软件必须达到的目标和能力；需求管理是一种系统方法，用来获取、组织和记录需求，建立并维护客户、用户和开发机构之间针对需求变化的协议。
    众多的实践证明，良好的需求管理对于降低开发成本和保障项目成功至关重要。根据权威机构的统计，在全世界范围，仅有1/4的软件开发项目能在规定的时间和预算内达到客户的目标。纵观这些项目各自总结出的十项首要成功经验，我们总能找到三个要素: 有效的用户参与，明确的业务目标和稳定的基本需求。这三个要素的核心内容是软件需求，其核心活动是需求管理。
CMM2对软件需求管理的指导
    针对如何提高软件质量和开发效率，CMM为我们提供了一套的综合见解和完整的框架，CMM对软件开发机构投入产出比(ROI)的卓著贡献已经得到业界的广泛认可。
    需求管理是CMM2级的首要关键过程领域(KPA)，是软件开发活动中不可或缺的组成部分。需求管理的目的是在客户和开发机构之间建立一个共识，形成软件工程所必须的管理基线，从而对需求实施有效的控制。在软件开发活动中，所有的活动计划，日程安排，交付工件都要直接或间接地和需求保持一致，这是贯穿于CMM体系中的一个重要理念和准则。只有基于这种准则，软件开发组织才有可能进入浑然一体的境界：软件的技术需求，项目计划以及各项相关活动协调一致，井井有序。为了实现这一目标，开发组织需要付出的努力是多方面的。
    最基本地，经过相关涉众（涉众：会受到作为结果的目标软件系统实质性影响的个人。）审阅的软件需求必须形成"文档"。对"文档"的理解不应仅局限于平面化的文字文档，文档的存在形式可以是多种多样的，关键是文档所记录的内容能够为不同工种提供可用的信息依据。软件需求规约(SRS)作为项目的核心文档，用以全面详实地定义软件需求的要素。另外，面向客户和最终用户的通用词汇，描述软件产?quot;做什么和为什么做"的高层次规约也很重要。
    为了达到有效管理软件需求的目标，开发机构必须投入必要的人力、资金和管理层支持。软件工程团队的成员和不同工种的团队成员应当接受必要的培训，以便完成与角色相应的需求管理任务。培训的内容要覆盖过程方法，标准以及针对应用领域的一些特殊问题。
    软件需求的变更应当作为项目计划的有机组成部分被审阅。需求变更所牵涉的人员能够通过有效的机制来磋商和评估由于变更导致的影响。针对磋商和评估活动中的权衡和分析工作，CMM建议我们至少要掌握三个方面信息: 软件需求的状态，软件需求的变更内容和累计变更次数，待决定的、被建议的、被批准的以及被融入基线的软件需求变更的个数统计信息。
CMM3对软件需求管理的指导
    根据CMM的建议，不应将需求管理当作瀑布式的简单文档化流程。CMM的一个显著的特征是将软件需求作为一个活跃的实体贯穿于整个开发过程之中，实施有效的需求管理事实上渗透在CMM的不同层次(Level)和众多关键过程领域之中。
    对于那些准备通过CMM3级评测的开发机构而言，基于一种被定义和文档化的标准实践流程从事软件开发活动是工作的重点，该级别涉及到七个关键过程领域。其?quot;软件产品工程"一项旨在有机整合各项活动，目标是快速有效地生产高质量的软件产品。该关键过程领域中明确指出: "软件需求的获取、维护、归档和校验有赖于系统化的分析，这种分析要以项目所定义的软件开发流程为根据。"该分析过程的目的是保证软件需求自身的有效性。
    关键过程领域"软件产品工程"中还明确指出: "一致性的维护要贯穿软件开发过程中的各种类型的工件（工件：由软件开发流程所生成或使用的一组信息。），包括软件开发计划，过程描述，需求信息，软件设计，编码，测试计划，以及测试流程。"根据CMM的指导，各种有价值的软件工件都需要归档和维护以确保其可用。
    根据CMM的建议，软件需求的变更被接受为软件开发活动中的一个必然组成部分。“冻结需求规约"的做法显然已经不能适应当今的商业环境和技术环境。取而代之的做法是建立相对稳定的软件需求基线，并将其融合到系统化的开发活动当中，以确保对需求变更的控制能够跨越不同工种和覆盖整个生命周期。
    CMM给出了几点针对性的指导建议: 变更需要经过提请，分析并且在合适的条件下被整合；需求的变更得到批准并加以整和之后，相应的工件和活动才能变更；在变更发生之前确定该变更所带来的影响，团队之间要针对变更进行必要的沟通和协商；所有的变更从始至终被跟踪。在以需求为核心线索的开发过程中，确保所有的需求变更从始至终被跟踪是掌握开发活动来龙去脉的基本保证。需求的修订要被一组具有代表性和权威性的涉众代表审阅并认可后方可得到批准，这样能够确保在修订的需求中体现出不同背景和立场的影响力。涉众包括客户，最终用户，项目管理人员以及软件测试人员等。
    根据CMM的要求，所有被批准的变更都要被从始至终地记录在案，用作记录相关信息的文档也要接受控制和管理。此外，我们还需要掌握用以确定软件产品功能、质量及开发活动状态的信息。 总 结
    作为一种广泛的和具有影响力的软件过程控制和评估框架，CMM只有映射到一个具体的系统化软件流程中才能体现出其真正的价值。换言之，准备通过CMM评估的开发机构应该以现有的流程和方法作为改进和优化其流程的基本出发点。
    在软件需求管理方面，对于准备通过CMM2级评测的开发机构，团队应将注意力放在以下几个方面:
    * 软件需求必须形成文档；
    * 软件需求必须能被控制，进而建立工程和管理的基线；
    * 成员必须接受需求管理培训；
    * 建立衡量需求状态的信息。
    对于准备通过CMM3级评测的开发机构，应将注意力放在以下几个方面:
    * 对需求进行系统化分析，确保软件需求完整性，一致性和可测试性；
    * 软件需求、设计、编码和测试用例都能够回溯到相应的源头，在需求发生实质变更之前能够判别该变更所带来的潜在影响；
    * 需求的修订应遵从统一的流程，需求的变更应从始至终被跟踪，软件需求文档应当通过配置和变更管理工具进行管理。
    最后要强调的是，过程成熟度水平是衡量机构开发流程成熟度的标准，不应该被当作开发流程改进的奋斗目标。开发机构切忌本末倒置，应该以现有流程为基础，实事求是地改进、优化各项具体工作，参照过程成熟度模型全面提升开发机构的需求管理能力。

关于ＣＭＭ在项目中的实施

51CMM原创 作者：丰力

    随着CMM理念的引入，国内软件公司激起了实施CMM的热潮。虽然CMM的主要思想很清楚，标准的条例也很明确，但如何达到这种标准的可操作性比较差。在缺乏基础和经验的情况下，许多企业在实施CMM的过程中，往往感到迷茫，不知从何处下手。而CMM实施的难点在项目的具体实施。本文将结合我公司CMM3实施经验，简单论述如何在项目中实施CMM。 　　首先看看CMM标准中相关的定义：
★ 机构
    公司或其他实体中的一个单位，它从整体上管理许多项目。机构内的所有项目由一个共同的顶层负责人管理，并采用共同的策略。
★ 机构标准软件过程
    可在机构内使用的基本过程定义，用它来引导建立项目的一般软件过程。它描述每个软件项目打算并入自己的项目定义的软件过程中的基本软件过程要素，还描述这些软件过程要素之间的关系（如排序和接口）。
★ 项目定义的软件过程
    由某项目使用的软件过程的操作定义。利用软件标准、规程、工具和方法对项目定义的软件过程进行恰当的表征和描述，使其易于理解。项目定义的软件过程是根据项目特点通过剪裁机构标准软件过程而获得的。
★ 剪裁
    修改一个过程、标准或规程，以更好地匹配过程或产品需求。
★ SEPG(Software Engineering Process Group)
    协组对机构使用的软件过程进行定义、维护和改进的一个专家组。在关键实践中，这个小组通常称为“负责机构的软件过程活动的小组”。
    项目实施CMM一般包括三个部分：定义项目软件过程、制定软件开发计划、软件开发及管理。
1. 定义项目软件过程
    项目经理在SQA人员（软件质量保证人员）、SEPG成员的帮助下，针对项目的实际情况，选择或剪裁机构标准软件过程，形成项目定义的软件过程。
    CMM实施初期，机构标准软件过程不完善的情况下，需要对机构标准软件过程进行剪裁，以适应项目的实际需要。机构标准软件过程较完善时，一般只需要从机构标准软件过程中选择模板、方法等形成项目软件过程，建议不再采用剪裁的方式。
    项目软件过程的内容为：项目采用的软件生命周期模型（如：瀑布模型、V模型等）；项目软件开发及管理（如：软件开发计划、需求分析、概要设计、详细设计、编码、测试、发布、项目跟踪等）应遵循的方法与模板。
项目软件过程由一到多个文档构成。至少应有一个文档详细描述项目的软件生命周期模型、软件开发及管理应遵循的标准、项目软件过程与机构标准软件过程的偏差（即进行了剪裁的内容）。如果进行了剪裁，还将存在项目定义的方法和模板文档。
    项目软件过程定义完成后，需要经过SQA人员、SEPG成员的评审，并得到上级主管领导的批准认可。主要是评审项目软件过程与机构标准软件过程的偏差，看看发生的偏差是否符合机构的标准，并满足CMM标准的要求。
2. 制定软件开发计划
    项目经理参照项目软件过程中的生命周期模型、方法与模板，结合客户需求制定软件开发计划。软件开发计划是软件开发活动的依据，也是软件开发管理的基础。
    软件开发计划的内容有：软件规模估计、工作量估计、成本估计、制定工作进度、识别风险、风险管理计划、跟踪管理、配置管理等。其中软件估计、风险识别与管理、制定工作进度是软件开发计划的重点与难点。
    软件估计主要为规模估计、工作量估计、成本估计。软件规模估计是工作量估计的基础，而工作量估计的结果是成本估计的基础。软件规模估计的方法有很多，最常用的功能点估计、代码行估计、界面数估计。各种估计方法有其优缺点，需要根据公司或项目的实际情况来选择估计方法。软件规模估计选定估计方法后，还必须结合以往项目的开发经验或收集的历史数据。开发经验或历史数据的丰富程度，决定了规模估计结果与实际情况的接近程度。软件工作量除了依赖软件规模的估计，同时与公司的软件开发生产率密切相关（什么是软件开发生产率？以界面数估计方法为例。3个界面，需要花费的工作量为1人月。那么软件开发生产率为3界面/人月）。因此规模相同的软件，不同公司开发软件所花费的工作量不同。估计了工作量以后，软件成本的估计就相对比较容易。我们一般将软件成本简单分为：软件开发成本、其他成本。软件开发成本等于工作量与人员平均花费之积。其他成本包括管理成本、差旅费等各种费用。这些需要根据公司的实际情况来确定。
    软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。我们需要关注以下的问题：什么样的风险会导致软件项目的彻底失败？用户需求、开发技术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产生什么影响？对于采用什么方法和工具，需要多少人员参与工作的问题，我们如何选择和决策？对软件质量要达到什么程度才是“足够的”？
    风险识别与管理的目的，就是识别出软件开发过程中可能产生的问题，制定预防问题的措施，及问题发生时的解决方法。公司内不同项目的风险不同，不同公司开发相同软件的风险不同。识别风险需要采用科学的风险识别方法，同时也需要经验与历史数据的积累。根据风险发生的可能性与发生时产生的影响，可以对风险进行分级。在风险识别的基础上，制定详细的预防措施和解决方法。用以避免风险的发生，当风险发生时将损失减小到最低程度。随着软件开发活动的进行，风险在不断的变化。计划时预测的部分风险可能消失，同时可能产生一些新的风险。因此在制定预防和解决的方法同时，还需要制定风险监控计划。在风险监控点上，监控风险的变化情况，并制定新的措施和方法。
工作进度的制定主要基于工作量估计的结果、采用的软件生命周期模型。制定工作进度主要需要详细描述，“什么人？什么时候？做什么事情？产生什么软件工作产品？”。制定工作进度使用的工具可以根据个人习惯来选择，比较好的有MS Project。制定工作进度的过程中需要综合考虑软件开发过程中可能遇到的困难，必须将时间安排得比较合理。时间太紧，将造成计划不能按时完成，不能起到指导软件开发的作用。而太松，又将降低工作效率。工作进度的时间把握存在很大的难度，和软件规模估计一样，需要经验和历史数据的积累。
    软件开发计划制定完成后，需要得到项目组成员的认可，并获得承诺。最后需要项目上级主管领导的签字批准。
3. 软件开发及管理
    软件开发将按软件开发计划进行，所有开发活动必须遵从项目定义的软件过程。软件开发过程中，SQA人员将按照SQA计划（软件质量保证计划）对软件开发活动和产生的软件工作产品进行审核。以保证软件开发活动和产生的软件工作产品符合项目软件过程定义的标准。
    软件开发是一个复杂的过程，其间存在着各种不确定因素。软件计划无法做到与实际情况完全吻合，好的计划也只能尽量接近实际情况。因此，软件开发过程需要进行管理，以保证软件开发能按客户的要求按时按质完成。软件开发的管理主要包括：跟踪软件开发活动、测量花费的工作量、实时调整计划。
    跟踪软件开发活动，主要是跟踪软件规模、工作量、成本、进度、风险等。跟踪的方式很多，主要分为定期与非定期。定期方式常见的有：周例会、里程碑会议。项目组每周或里程碑处召开会议，以便项目经理、项目上级主管领导能够实时地掌握项目的进展与存在的问题。非定期一般为，项目出现问题时，项目经理、项目上级主管领导对产生的问题进行了解分析，并帮助解决问题。
    测量花费的工作量，是测量前一阶段软件开发活动实际所花费的工作量。并将实际的工作量与计划估计的工作量进行对比分析，为后一阶段计划的改进提供依据。
    在跟踪、测量的基础上，看看是否有必要调整计划。对计划的调整表现为：重新估计规模、工作量、成本，重新识别风险并管理风险，调整工作进度的时间人员安排等。 CMM在项目中的实施还有很多工作要做，以上只是描述了其中的一部分。从印度软件成功的经验，让我们认识到实施CMM将提高我们的软件产品质量，帮助我们打开国际市场，振兴我国的软件产业。但CMM的实施也存在很大的难度，特别在CMM实施初期，我们将遇到很多困难。例如：增加了软件开发的工作量，降低了软件开发效率等。克服这些困难，通过实施CMM持续地改进软件开发过程，我们一定能从中受益。

如何成为CBA IPI主任评估师

吴超英（转载自中国计算机报）

    要想成为一个授权的CBA IPI Lead Assessor（主任评估师）,申请者必须满足一定的条件:
    1. 确认在两年内已作为评估组成员参加了至少两个CBA IPI 评估
    2. 在软件开发或维护的适当技术领域至少有10年的软件工程经验。如软件设计、软件质量保证、需求分析、配置管理和测试等
    3. 至少2年软件开发管理经验
    4. 在相应的技术领域的硕士学位
    5. 成功地完成了卡内基梅隆大学软件研究所的 Introduction to the CMM（CMM导引）课程
    建议申请者还应具有:
    1. 良好的口头和书面沟通技巧
    2. 与管理层和技术组成员相互配合的能力
    3. 良好的软件过程知识和判别能力
    4. 良好的技术和指导性讲解培训技巧
    5. 在小组环境中有效工作的能力以及协调和建立小组的能力
    6. 全面质量管理的知识和质量改进的技术
    一旦这些先决条件满足后，申请者必须提交一份详细的简历和向SEI申请接受CBA IPI Lead Assessor 培训的注册表。在成功地完成了培训和所有要求的考试后， 申请者才被授予为一个候选主任评估师（candidate Lead Assessor）。
    在成功地完成了培训后的12个月内，一个候选主任评估师必须在一个有资格的主任评估师的观察下领导一个 CBA IPI 评估。 一个候选主任评估师必须接受来自主任评估师的一个满意的观察报告和推荐，才成为完全的授权的主任评估师。
    授权期
    作为一个CBA IPI 主任评估师，其授权是需每两年确认一次。授权必须每两年重新申请并重新续费。重新申请不是自动的，主任评估师在两年的授权期内，必须令人满意地行使他们的责任来取得在后面两年间的授权。
    在重新申请过程中应考虑如下因素：
    1． 授权期间的审计报告
    2． 在授权期，评估客户返回到SEI的报告
    3． 评审实际的评估数据来决定是否已遵循了规定的过程

在中国开展CMM评估的几点建议

周伯生

    从美国的软件产业发展可以看到，软件产业有结构化生产方式（1975年－1995年）、以过程为中心的生产方式（1985年－2005年）和工业化生产方式（1995－今）等三个发展阶段。
    我国软件组织在软件过程的现状可以概括为以下三个方面：第一，我国正在由结构化生产方式向以过程为中心的生产方式和工业化生产方式前进。目前已有很多企业（不论是国营或者民营公司）认识到要按CMM改进软件过程，实施科学化、系统化的管理，以提高组织的软件能力成熟度，这表明具备了改善自我的强大动力。第二，目前在前进的道路上仍然有一些困难，如一些组织想通过ISO9000和CMM提高能力成熟度，但是他们不熟悉CMM的概念，也不知道CMM和ISO9000之间究竟有哪些区别。大部分软件组织在软件工程理论和实践两方面都比较薄弱，虽建立了软件过程，但过程阶段不明显，软件生产无序，对进度，预算，质量的预测和控制不得力，常常在遇到问题时就放弃原定计划，重视编程与测试，忽略需求分析和构架设计。高层管理对软件管理尚未引起足够的重视，没有配备足够的资源或合格的人员承担过程改善工作。第三，缺少文档化的过程描述，特别是缺少工作文档（如过程中的变更请求报告）、工作量统计文档（如时间和工作量统计表，周状态报告）和风险管理文档（如风险估计报告、风险评测报告）。缺乏对过程和产品进行测量，软件过程的历史数据很少，因此很难基于历史数据对工作量和进度进行合理的估计。各个软件组织应该基于对目前状态的了解，按照CMM标准找出存在的差距。差距就是不够成熟的地方，也正是应该加强改善软件过程管理的地方。
    软件过程改进是一种含有大量管理成分的工作技术，它主要包括以下三个关键步骤：对比目前的状态和期望达到的状态，找出存在的差距；确定要改变哪一些差距，要改变到什么程度；制定相应的具体实施计划，其中的“具体”是指：要有明确的，可以检验的目标；要定出检验成功与否的标准；要有具体的实施办法；指定具体执行计划的人，并明确具体的职责与任务；要明确执行计划的主要领导或协调者，以负责解决在计划执行中出现的问题；要列出“实施计划”所应用的新技术与新工具以及如何获得这些新技术与新工具。
    我国软件产业方兴未艾，实施CMM可以在起跑线上改变我国的软件工程文化，改善软件人员的素质，不仅对我国的经济具有重要意义，也是提高软件企业素质，增强软件企业的国际竞争力的必要前提，而且还为软件的出口创汇创造了条件。CMM是一个较好的软件改善框架，但CMM只给出做什么，并没有给出如何做。因此要认真研究如何遵循CMM模型进行具体操作的问题。
    为了更好地理解CMM，提高软件组织的过程管理能力，顺利通过CMM评估，基于我们对 CMM的研究与评估实践，给出如下建议：高层管理应该把更多的注意力放在过程改善上，设立过程改善的专职队伍。这一方面是因为过程改善是思想观念和工作方式的改变，是企业文化的转变，它涉及到企业中绝大部分工作人员。另一方面是因为以过程为中心是软件工业化生产的三大支柱之一，只有高度重视，加强研究，学习和实践，才能真正使软件生产向产业化方向迈进。
    在软件过程改善上应配备必要的资源，要建立一支有相当规模的改进队伍，在投资上应达到足够的力度。在组织内部，首先要建立软件工程过程组（称为SEPG），负责软件过程改进任务，并挑选合格的人员担任全职的SEPG组长。根据国外经验，一般需要占该软件组织中开发资源的5％～10％，根据世界上近1800个组织的评估实践证明，进行CMM评估的效益是投入的4倍～8倍。
    建立合适的组织结构，研究软件工程理论和软件过程改进方法，负责制定和实施过程改进计划，他们是实现企业评估活动的具体组织者。在执行计划的过程中，注意检查它的遵从性，如遇偏离，应研究原因，并采取相应的纠正行动，他们是企业进行定期过程诊断的内部评估师和企业过程改进活动的监控者。
    要加强培训工作，开展能力成熟度评估既要有高素质的主任评估师，也要有相当的过程评估队伍，更要有庞大的过程改善队伍。要认识到只有高素质的人员，执行成熟的良好过程，才能生产出好的产品，应普遍开展CMM及软件工程基础的培训，使每个岗位的人员都具备过程改进的意识，并掌握所必要的过程改进知识和技能。
    测量数据是进行过程改进的基础，要重视过程与产品的测量过程。在项目的整个开发过程中，特别是在里程碑处，要收集过程的执行数据，记录活动状态，既为当前项目的测量和分析提供数据，又可作为历史数据保留下来为今后的项目参考。这些数据主要包括：软件规模、工作量、成本和进度的估计数据和实际数据，产品质量测量数据，需求变化情况以及风险分析数据等。
    应重视软件配置管理及配置管理工具的开发。配置管理最主要的目的是在项目的整个软件生命周期中建立和维护软件项目产品的完整性，系统地控制对配置项的改变，并管理组织的软件工程资产。配置管理的内容繁多，权限管理复杂，开发或采购合适的配置管理工具是非常必要的。
    在我国开发CMM评估，既要注意智力引进，聘请国外的主任评估师为我国进行过程评估，更要着力培养我国自己称职的主任评估师。这不仅还是因为中国是一个潜在的IT 大国，而且还因为CMM实施与一个国家的文化密切相关。此外，改善软件过程本身也是一个过程，需要长期地得到有资格的主任评估师的帮助。各行各业的主管部门都要扶持和支持培养我国自己的主任评估师，把培养主任评估师看作是转变观念和创新知识的新产品。要充分认识到过程改善工作的长期性与艰巨性。过程成熟度升级本身就是一个过程，而且有一个生命周期。因此，过程改善工作必然具有一切过程所具有的固有特征，不能急功近利。
    在CMM评估工作中，要提倡将能力成熟度模型CMM与个体软件过程PSP以及群组软件过程ISP有机地结合起来，同时密切注意过程改进的新动向。各地应在软件产业主管部门的支持和协调下，统筹社会各界的力量，加大软件过程改进的研究、评估和实施的力度，把我国的软件产业推向前进。首先要在企业内部建立庞大的过程改进队伍，积极研究、实践和推动过程改进工作。认真建立CMM主任评估师队伍，认真建立各门有关课程的合格的教员队伍。还要通过市场竞争机制，扶植和建立过程改进的咨询机构和中介机构。

CMM中KPA及KP的分布统计

梁松

    CMM共有五个级别，即初始级、可重复级、可定义级、可管理级、优化级，每个级别由不同的关键过程域（Key Practivice Area简称KPA）组成，共有关键过程域18个；每个关键过程域由关键实践（简称KP）组成，18个KPA中包含KP共316个。分别见表一、表二、表三、表四、表五，其中表一是CMM五个级别中对应的KPA、KP统计总表，表二、表三、表四、表五分别是可重复级、可定义级、可管理理级、优化级中的KPA、KP统计表。

联想冲刺CMM3透明报道（1）

肖文秀

     编者注：联想软件事业部在2001年1月通过CMM二级评估，一年以后的今天，他们又在冲刺CMM三级。这是中国民族软件产业的一件大事，因为虽然东大阿尔派已经过了三级、华为印度所已经通过四级、摩托罗拉已经通过五级，但这些公司是否能称为民族软件产业，本身就是一件争论不休的事情… 　　在联想的冲刺过程中，51cmm将进行全程跟踪报道。
    CMM认证对于联想软件来说是一个持续渐进的过程，也是规范和衡量软件企业技术管理水平的标准。2001年1月20日，联想电脑公司软件事业部顺利通过了CMM Level 2认证，成为国内第一家通过此认证的民族软件企业，这对于一个硬件起家的企业来说的确来之不易，也是值得骄傲的事情。时至今日，在短短不到一年的时间里，联想软件又开始了新的征程和挑战：努力跨越CMM Level 3的门槛。联想软件CMM3的评估从2002年1月7号开始，到11号结束，共有说长也长，说短也短的5天时间。为了让读者了解联想软件在CMM评估中的苦与乐，我们特别以天为单位，记录了评估期间发生的系列喜闻乐见故事，以飨读者。
第一天
    时间：2002年1月7日，一个经过了昨日狂风洗礼后日子，天气微寒。
    地点：联想先锋大厦
    人物：主任评估师：Paul，英国路透集团伦敦公司的CTO
    Sponsor：联想电脑公司助理总裁、 软件设计中心总经理韩振江
    项目经理： 王海青、传奇数字校园项目经理
上午8：35
    联想电脑公司助理总裁、软件设计中心总经理韩振江早早地就出现在办公区域，静静地等待着英国路透集团伦敦主任评估师PAUL的出现。韩振江先生三十出头，按照习惯，联想软件上上下下的员工都亲切地称呼他为"老韩"，从老韩笑容可掬的脸上，我们可以看出他今天心情相当不错。在他心里，PAUL已经是一个老朋友了，只不过是一年没有见面了。
上午9：35
    一身西装革履，带着英国特有的绅士风度的PAUL翩翩而来，他是今天早上刚到北京的，还没来得及感受一下北京的风，就从机场直接来到了联想。"HELLO"后，PAUL和老韩两人用拥抱代替了握手，彼此的热情融化了时间和距离。
下午16：00
    "今年十一没有加班，项目封盘前只熬过一个通宵，这也算是CMM给我带来的好处吧。"
    我们面前的这位是王海青先生，他是第一天第一个被主任评估师面视的项目经理，也是第一次带领自己的团队参加CMM的 TEAM LEARD，对CMM3的感触颇深，因此也就侃侃而谈，
    "其实执行任何规范的困难都在于如何化解规范与执行人过去的做事方法、习惯的冲突。比如说软件开发人员可能会认为文档与规范会削弱他们的创造力，对规范的推行可能会有抵触情绪，要解决这个问题，除了通过培训和沟通使他们对规范的科学性、必要性有更好的了解外，最有效的方式就是通过在项目过程中实施严格的过程控制并记录下各种数据，在项目进行中和结束后用数据来说明科学的管理带来的变化。
    在CMM的实施过程中，还有一个困难就是由于目前中国软件产业高素质的项目管理人才极度缺乏，他们一般在公司内都忙于项目，虽然有较丰富的实践经验，但软件工程理论水平不足（这与我国高等教育体制有一定关系，我作为国内一知名高校计算机软件专业的毕业生，在校时也学习了不少软件工程的知识，可工作后发现实用性很差，而前几天我看到了Humphrey写的一本介绍PSP的书，惊讶地发现我在做了两年多的开发、一年的项目经理后所理解的一些内容，在这本书中已经有了比较清晰的描述，而这本书是美国某大学计算机专业一年级的课本），而公司内实施质量管理、制订规范的员工又缺乏项目经验，上述两点降低了过程改进的效率（我想其他多数国内软件公司也会遇到同样的问题），不过在这里我想强调的是，我们过程改进处的员工是非常敬业和诚恳的，正是通过多次热烈而愉快的讨论，使我对项目管理有了更深的认识，也使我们的规范不断完善。在传奇数字校园的开发过程中，我们对需求分析、设计和各阶段的同行评审都投入了大量的人力，使产品质量（尤其是满足用户需求的质量）有了明显的提高。
    CMM3带给我们项目的最大收获，我想应该是产品质量的提高，在开发的过程可以积累大量有价值的文档和历史数据，同时又培养了开发人员良好的软件工程习惯。而这些都是在规范仍在不断改进，开发人员仍需要逐步适应的情况下取得的。
项目背景：
    传奇数字校园是联想软件设计中心为广大中、小学校实现校园信息化而开发的校园信息交流、管理平台，它主要包括教务管理、总务管理、信息点播、图书管理、内部交流、在线考试、电子教室、Internet仿真教学等模块，学校可以根据需要，任意组合。同时考虑到现在多数学校的应用和维护水平，程序采用B/S结构，使系统的维护和使用都非常方便。
    项目人数：约30人，
    代码规模：近50万行，
    使用工具：
    设计：Rose、Visio
    编码：Visual C++, Visual InterDev, Delphi, Install Shield
    测试：BoundsChecker, BIM
    SCM：SourceSafe

联想冲刺CMM3透明报道（2）

肖文秀

     编者注：联想软件事业部在2001年1月通过CMM二级评估，一年以后的今天，他们又在冲刺CMM三级。这是中国民族软件产业的一件大事，因为虽然东大阿尔派已经过了三级、华为印度所已经通过四级、摩托罗拉已经通过五级，但这些公司是否能称为民族软件产业，本身就是一件争论不休的事情… 　　在联想的冲刺过程中，51cmm将进行全程跟踪报道。
    关于这次透明报道，韩总觉得：这是种自信心体现，而非炒作。联想在扎实地一步一脚印地从2级到3级，正因为对3级的通过充满十足的信心，才启动这次跟踪报道。这也是个向业界展示联想软件的机会，也让更多向CMM认证迈进的企业提供了解认证评估细节的契机，对广大专业媒体也是种学习的机会。
时间：2002年1月8日
地点：联想先锋大厦
人物：主任评估师：
Sponsor：联想电脑集团有限公司助理总裁、软件设计中心总经理韩振江
2002/1/8，下午4:15
    刚从评估会场出来的韩总幽默的说，我是刚刚过堂出来的。话虽如此，但言语间却透着一股轻松，一股自信。
对比CMM2与CMM3
    老韩回忆起去年准备CMM2的情景时，感慨的说，过CMM2的时候，联想软件上下都是非常紧张。那个时候，国内对CMM还并不熟悉，也还没有认可这种陌生的理念。外界各方面都很关注联想的举动，压力很大，整个联想软件都是紧绷着的。此外，CMM2是重复级，完全是从无到有的建设，也不太熟悉CMM评估的要求，甚至对来自英国的评估师风格也都很不了解。CMM2评估时，韩总是第一天第一个面试，韩总自己回忆起来说，当时自己回答问题时都非常紧张，更别提属下的员工。尽管这样，由于联想软件的实力和充足的准备工作，联想软件还是顺利地成为了第一个通过CMM2认证的国内企业。
    今年则完全两样，联想通过CMM2后，对CMM有了清楚的了解，对自己的实力也有了充分的信心，尽管还是进行了大量的准备工作，但联想软件上上下下都对这次通过CMM3充满了信心。尽管CMM3比CMM2的内容增加不少，但CMM3是定义级，联想软件一直持续CMM这一过程，虽然这个历程也不容易，但联想软件人员通过采用CMM2后，不仅软件研发标准规范了，而且大家对CMM标准也都已经认可。通过CMM3，对联想软件整个团队而言已经没有困难。
被911打断的评估进程
    此次韩总的面试原定是一个小时，但是他45分钟就通过了，因为评估师觉得已经没有任何问题可问了。韩总笑称，尽管还有两天才能完成评估，但对这次通过CMM3已经没有任何担心。说到这里，韩总还颇有些遗憾，联想软件本来是完全有能力在9、10月间就通过CMM3，却被“9、11”恐怖袭击耽误了。“9、11”恐怖袭击后，英国路透集团停止了一切员工外派计划，原定的主任评估师PAUL当然也无法前来，所以评估一直拖到了1月份。但是联想软件在9月份，由同样受“9、11”所累，到杭洲出差不能及时返回伦敦的SETVE担任主任评估师进行了预评估，在这次预评估中联想软件获得了8分的好成绩，STEVE告诉韩总，如果是在进行正式评估，那么联想就已经通过了CMM3。由此，联想软件对自己通过CMM3的实力已经很有信心。按惯例，资格证书应该在通过评估后，由评估师向总部申请才能拿到，但据说，这次PAUL却已经将证书同机带来。尽管这并未获得证实，但评估师对联想实力的信心却可见一斑。
最令我感动的是员工
    谈到从CMM2到CMM3这段历程时，韩总动情的说，最令他感动的是联想软件的员工们。整个CMM3的推进工作的核心压到了新成立的过程改进处的组员肩上，去年年初韩总制定了通过CMM3的目标后，过程改进处就提交了具体的工作计划，然后踏踏实实地按照计划一步一步地推进CMM3的建设，不仅要设计各种软件开发流程和大量的文档，还要对软件开发人员进行培训，在过去的一年里，他们几乎没有休息时间，为了联想通过CMM3，他们付出了很多，牺牲了很多。韩总也问过他们觉不觉得太辛苦时，员工们都回答，这项工作不仅能够提高联想软件的整体实力，对联想软件的每个员工的素质都会有很大的提高，这是一项很有意义的工作，他们对这个工作都非常感兴趣，也很有成就感，尽管累一些，但心里很乐意。同时软件开发人员，也做出了大量的配合，他们需要改变过去的工作习惯，在开发过程中填写大量的文档，尽管最后习惯了CMM的标准后，这些工作会带来工作的高效率。但是，在标准推行之初，软件开发人员却是克服了很大的困难，不仅要完成繁重的开发工作，还要增加额外的工作量。可以说，现在联想通过CMM3是联想软件自上而下，同心协力奋斗的结果，每一个员工都付出了巨大的努力。
    在主任评估师询问韩总，联想软件的最大优势在什么地方时。韩总不无风趣地答到：首先是联想软件这个团队中的员工们，他们的敬业精神、强烈的责任感和良好的团队合作精神是联想软件无价的财富。还有就是联想软件有他这样的很好的领导。
从督导者到支持者
    韩总的话虽然风趣，但说得却是事实。对于CMM标准，联想软件员工有个共识，CMM标准必须首先在决策层得到认可，必须是自上而下的推动，而不可能是自下而上的推动。韩总谈到这一点时说到，人总是有惰性的，不能希望员工自发地认识到，我们需要一份标准、规范的工作模式，因为这样会改变他们以前的工作方式，会增加他们的工作量。所以，韩总是以一种很坚决的态度去推进CMM的建设的，不仅是制定目标和策略，而且频频参加各种会议，对员工进行鼓动工作，同时，在推进过程中严格督导。在通过CMM2后，员工已经充分认可了CMM标准，尽管推进过程仍需督导，但是，韩总认为，这个阶段，除了制定目标、策略外，他更多的是在起到一个支持者的角色，为下属提供各种各样的资源支持。
眺望CMM4
    CMM3这个台阶联想软件马上就要轻松地迈过。联想软件已经开始准备冲击被称为“中国企业难以跨越的门槛”的CMM4了。韩总说，希望能用一年半的时间来跨越这个门槛。韩总并没有盲目乐观，他谈到，CMM4最大的困难在于量化上，从软件开发开始到结束，都需要大量的数据来说明。本次评估中，主任评估师也提醒到，CMM4要求在各个方面都要用数据说话。但是韩总也很有信心，因为，从今年开始，联想软件成为联想的大平台，会有很多机会拿到很多大型项目，这就给了联想软件大量的实践机会，只要联想软件注意数据的收集，达到CMM4的要求也并不困难。现在的关键问题是，国内的自动化工具还是个空白，而要进行大量数据的搜集，自动化工具是个很好的帮手，作为国内CMM的领跑者，联想软件也希望以后能够开发适合国内企业使用的自动化工具，为其他企业冲击CMM提供帮助。韩总介绍到，只要通过了CMM4，软件的开发可以说一切都在可控状态，可以精确地对软件的开发进行预期估计和过程监控。实际上，联想在准备CMM3的过程中已经开始有意识地进行数据搜集工作，为CMM4进行准备。此次联想四个参加评估的项目中，有的就已经达到cmm4流程规范。
不断探求软件开发的规律
    韩总介绍到，实际上在联想软件事业部成立之初，探求工作规范化的氛围就好，大家也认识到了必须抓住软件开发的规律，不能再采取很随意的作坊式开发方式。联想软件也做了大量的尝试，先是去学微软，然后尝试用ISO标准，后来又自己尝试制定符合联想特色的标准，经过一系列的探索，最终联想选择了CMM标准，回头看来，这个选择非常正确，CMM标准使得联想软件工作的规范化和标准化有了很大的提高，对员工的工作素质和士气都有了很大的提高，给联想软件的发展提供了强有力的后劲。目前，联想正在开始制定实实在在的规划，已经将CMM5圈在了联想软件的发展规划蓝图中。在今后通过CMM4、CMM5后，联想还会继续沿用适合自己的管理方法，为大型应用软件、大型项目提供非常好的实施保障。

联想冲刺CMM3透明报道（3）

肖文秀

     编者注：联想软件事业部在2001年1月通过CMM二级评估，一年以后的今天，他们又在冲刺CMM三级。这是中国民族软件产业的一件大事，因为虽然东大阿尔派已经过了三级、华为印度所已经通过四级、摩托罗拉已经通过五级，但这些公司是否能称为民族软件产业，本身就是一件争论不休的事情… 　　在联想的冲刺过程中，51cmm将进行全程跟踪报道。
时间：2002年1月9日
地点：联想先锋大厦
人物：主任评估师：Paul，英国路透集团伦敦公司的CTO
Sponsor：联想电脑公司助理总裁、 软件设计中心总经理韩振江
项目经理：
    于辰涛：高性能机顶盒项目
    和立波：华山幸福之家项目项目经理
    张磊：B1扬天幸福办公项目项目经理
华山幸福之家项目组
    华山幸福之家项目组是轻松地笑着走出评估现场的。作为联想软件成立之初的19个老员工之一，项目经理和立波去年也参与了CMM2的推动与实施。和立波笑着说，与去年通过CMM2不一样，现在经过一年时间的准备，项目组在面试前就已经胸有成竹，所以通过面试后也并没有太多的感慨，感觉这是顺理成章的事情。面试也很简单，只是把项目开发从开始到开发进程一直到结束，对整体过程做一个汇报，评估师根据这些情况来判断是否符合CMM3的标准。
    CMM2的通过和过去一年CMM3的推进，使得华山幸福之家项目组深切感受到了标准化、程序化工作的益处。和立波介绍到，华山项目时间非常紧迫，又涉及到许多新技术。通过实施CMM2级规范积累的经验，使得华山项目做到井井有条，忙而不乱。而cmm3对于软件过程的控制要比cmm2细得多。它通过明确的定义组织级和项目级的软件开发活动，使得一个项目组的开发过程对于整个部门都是可见的。当然这要求项目组成员完成更多而且质量更高的文档，同时为了及时跟踪项目的进展情况，在项目跟踪与监控方面也做得更加完善，这使得项目经理可以用具体的数据来预测项目未来的进展情况，而不是仅仅凭经验。刚开始做cmm3时，的确觉得这些标准化的约束增加了很多工作量，很麻烦，但是在实际过程中才发现这样的过程确实是项目管理必需的，每两周所有的人员可以看到项目的某个子任务的进展情况、是否在控制之内等等信息。CMM作为一套科学的项目管理规范，通过计划监控等手段有效地将项目风险降至最低。此次，华山项目仅比计划时间延期2天，可以说是CMM有效的规范管理发挥了重要的作用。
    项目组总的感觉是，联想软件通过cmm3评估确实使得整个软件管理水平达到了一个新的高度。谈到下步冲击CMM4，和立波认为，CMM4的难度更大，CMM4更趋向于正规化管理和工厂化开发。实际上，CMM4所要求的KPA(关键过程域(Key Process Areas))增加并不多，更多的要求是积累，是CMM3执行过程中大量数据、项目的积累。这就需要通过大量的项目积累完成。
项目背景
    华山幸福之家项目是由消费电脑事业部委托软件事业部为华山新品电脑开发的随机软件项目。本项目主要目的是为了充分体现华山电脑的系统理念-数字生活DIY，满足用户个性化的应用需求。个性化，模块化是整个项目的主要特色。本项目提供“幸福之家”核心模块(包括调度，事务处理，上网平台等功能)和扩展软件功能包。
高性能机顶盒项目组
    从评估现场出来的高性能机顶盒项目组成员看上去还略微有些紧张。当被问到是否紧张时，项目经理于辰涛略带着些许程序员所特有的拘谨但很有底气地答到，心里有底，今年实际上并不紧张。于辰涛去年也参加了CMM2的评估，不过那时他的身份是项目组组员。他介绍到，实际上去年通过CMM2是最紧张的，那时候，大家都刚刚接触CMM，对这套标准非常不熟悉。连怎么做是对的，怎么做是错的都心里没底。而现在，经过一年的推进，大致对自己的实力和CMM的标准都心里有数，所以实际上并不紧张，知道按现在的实力通过没有任何问题。
    于辰涛也感慨的说，评估师不好糊弄，评估师对项目的把握很清楚，问的问题也很有针对性，哪怕面试中拿错了一份文挡都会被发现。要想混过去是很困难的，能够通过的确靠的是实力的提升。
    刚开始在项目组推进CMM时，的确遇到了一些困难，一位组员笑着说，刚开始时，项目组内的spto人员被要求填写大量文档时，他们就抱怨到，这么复杂的表也太难填了，有用吗？。可以说，当时是“被迫”接受CMM标准的约束。可是，随着对标准化工作的适应，项目组越来越感觉到了CMM所带来的益处。
    于辰涛说道，以前项目组遇见的最大的困难就是怎样抢“时间”。开发时间非常紧，再加上硬件产商和服务提供商在实现方式上具有相当的可变性，使得整个项目的风险相当大。这样就经常导致产品开发延期和最终产品难于符合用户需求等问题。而且特别从项目管理的角度，这样的产品的最终发布日期是不确定的，导致整个研发管理比较混乱。
    但是在对项目进行了cmm3方式的管理之后，项目首先选择了一种合适的软件开发周期，定义了适和的软件开发过程，对于相关项目组采用了较强的组间协调的管理方式，对于项目组成员安排了定期的有针对性的培训，同时还加强了同行评审以提高整个工作产品的质量，这使得项目开发从需求分析到设计到编码一步步有条不紊的展开，一直处在可控的范围之内。软件质量有了一定的提高，延期发布的现象也少多了。
    在体会到这些益处后，现在项目组再也不抱怨研发过程中填写大量的文档，进行大量的同行评议以及接受CMM的其他约束了，因为他们发现，的确是磨刀不误砍柴工，现在的规范化、标准化的工作使工作效率、质量都有了很大的提高。
    于辰涛还提到了CMM的一个别的益处，这种标准化的工作使得每做一个项目都能把这个项目开发过程中的经验沉积下来，以机顶盒项目为例，做完了这个项目后，以后再做后续项目就可以查找很多这个项目的资料，对于后续研发的进度能够有个很好的控制。
    于辰涛还很感慨的说，联想推行CMM的成功，的确很大程度上源于决策层的正确决策和坚决推动。象CMM这种标准化的工作，只能是自上而下的推行，而不可能自下而上的进行。原因很简单，很多程序员都有自己的工作方式，他们一般也不会主动地去用一个标准化的框子框住自己。
项目背景
    高性能机顶盒项目，主要是为联想公司的新产品-高性能机顶盒提供软件平台。这个项目是基于Windows CE 4.0平台和Venus 2.0开发环境的，主要工作是提供稳定的机顶盒软件运行平台，裁减windows ce操作系统，移植硬件驱动程序，定制机顶盒操作界面等。这个项目涉及到硬件设备oem提供商、视频服务提供商、软件平台、驱动程序、操作环境等诸多部门。
B1扬天幸福办公项目组
    B1扬天幸福办公项目项目经理张磊是联想软件的元老之一，做消费软件的他，对编程可谓再熟悉不过。但是他对CMM的感受却与另外几位项目经理不太一样相同。
    他认为施行CMM实际上给项目开发带来了一些困难。首先，按照规范和流程实施项目管理会增加项目工作量和周期，这与及时满足客户需求、迅速相应客户需要存在一定的矛盾。其次是规范与项目实际工作情况还存在一定差距，现在尚未根据实际能力和组织特点找到最有改进之处，换句话说：也许改进项目管理能力的关键就在那么几点上，但现在还没有找到，劲没有使到点子上，而是全面铺开，这样就很容易导致降低效率。
    在项目开发的过程中，张磊及项目组成员感到按照CMM规范做项目是很不容易的事情。张磊认为，项目开发要求项目经理全身心地投入，最好不要有其它事情干扰。由于客户需求要变化和时间非常紧迫，项目经理实际上要承受非常巨大的压力，现在施行规范化实际上是给了项目经理更大的压力。
    张磊认为，设计中心应该更多地考虑项目开发实际情况，具体分析哪些是最首要的问题。哪些是最致命的问题，应该指定专项改进计划，比如从需求到设计，这样就能使过程改进和项目成员都能够把有限的精力用到最需要的地方。应该让规范更符合我们实际，现在看有些脱离。目前设计中心对项目经理的培养和重视(激励)程度还不够。
    虽然看上去张磊对CMM并没有达到完全地认可，但是张磊也觉得CMM的确对软件产品地质量和进程都有了很好的监控作用。张磊认为，不管是选择了什么样的标准，最关键的使产品的质量，不是为了过CMM而过CMM，而应该真正使得CMM能够推进整个软件开发管理工作的标准化、规范化，提高软件开发的水平。
项目背景
    B1扬天满意办公项目是由商用电脑事业部委托软件事业部为扬天新品电脑开发的随机软件项目。《满意办公》秉承联想多年软件应用及用户经验，一切从用户的需求出发，致力于向中国广大用户提供易用、易维护、功能丰富和领先的技术应用平台。《满意办公》在办公、网络、安全、休闲和服务五大方面提供了丰富的功能软件，满足用户基本的商务办公需求，体现更加实用的设计理念。

联想冲刺CMM3透明报道（4）

肖文秀

     编者注：联想软件事业部在2001年1月通过CMM二级评估，一年以后的今天，他们又在冲刺CMM三级。这是中国民族软件产业的一件大事，因为虽然东大阿尔派已经过了三级、华为印度所已经通过四级、摩托罗拉已经通过五级，但这些公司是否能称为民族软件产业，本身就是一件争论不休的事情… 　　在联想的冲刺过程中，51cmm将进行全程跟踪报道。 测试小组
    测试小组的七名参加评估的组员平静地围坐在会议桌旁，他们代表测试中心20多名测试人员参加了今天的CMM3评估，由于是组织评估，要求有一定的覆盖率，因此测试中心参加评估的人数比前两天要多。
    被问及参加评估的感觉时，小组成员笑嘻嘻地开玩笑说到，不过被提审了一回。去年通过CMM2后，小组对CMM评估的理念和程序都有了比较清楚的了解，通过一年的准备，已经有了十足的把握。所以，总体上感觉很平常，只是将自己平时的工作介绍了一下，并没有什么太特别的感觉，如果不是还坐着PAUL，感觉与平日的工作汇报并没有两样。
今天面试的考官除了PAUL外，按照规定还有联想软件过程改进处的leader。小组成员介绍到，实际上，今天问问题最多的是这位联想的自己人，不仅问的多，而且问得针对性非常强，也非常严格。这也难怪，因为他很了解情况。结果，主任评估师PAUL听了这些非常到位的问题和小组成员的圆满的回答后，非常满意，自己也感到没有别的什么问题好问。小组成员笑称，今天是大水冲了龙王庙，如果说有困难的话，那么整个面试最大的困难就来自于这位联想的自己人。
    谈到CMM的推进，测试小组的成员普遍感觉从工作量上来看，的确是增大了，尤其是在推行之初，大量文档的填写费了不少功夫。但经过一段时间的运行后，的确能够提高工作的效率和质量。小组成员最大的感受就是，做事情有章可循，有法可依。以前，每个项目都或多或少会存在开发与测试之间的工作冲突。开发人员有开发人员的想法，测试人员有测试人员的立场，有的时候也很难说谁是对的谁是错的。但是现在有了CMM标准，这个规范就能保证一个一致性，整个流程中哪些部分是开发部门的责任，哪些是测试的权限，做什么是对的，做什么是不正确的，这些都规定的很清楚。CMM标准推行了以来，这种工作上的冲突少多了，大家都知道了自己该做什么。
    他们开玩笑道，这下就给软件开发部门那些野马套上了笼子，CMM标准在测试中心得到了比在软件开发人员那里更大的欢迎。CMM标准使得软件人员必须填写大量的文档，对每一步工作都有很清楚的规划和记录，这就给测试工作提供了很多便利，实际上是给测试工作提供了保障。
    一位在联想已经呆了三四年的老员工感慨道，在实行CMM标准前，整个软件开发工作存在很多不规范的地方，经常需要救火队员似的行动，很多时候依赖于软件开发人员的个人英雄行为，而现在推行CMM标准后，更多地是依靠整个团队的合作，实现了资源共享，调度有序，过程可监控。使得整个软件开发工作在一种有序、可控的情况下进行。
谈到冲击CMM4，小组成员都非常有信心，在过去的一年里，他们在准备CMM3的过程中就已经设立了数据搜集小组，进行数据搜集工作，开始了CMM4的准备。小组成员谈到，四级的最大难度在于量化，在于用大量的数据说话，这与中国的文化传统包括传统企业中的人治传统是有冲突的。但是，测试工作做的就是用数字说话，所以说，从这个意义上来说，测试工作是非常适合也非常欢迎这种标准的推行的。
    最后，测试小组成员还非常认真的说到，他们认为联想软件绝不是为了过CMM而去做这些工作，其本质是要从根本上提高联想员工的能力，提高整个软件开发工作的管理的规范化、标准化，从而提高软件产品的质量和联想的整体实力。
背景
    测试中心是联想软件一个独立的专门从事软件测试工作的部门，负责软件设计中心全部产品的测试工作。现有20多名测试人员，按产品方向分为桌面产品测试小组，教育产品测试小组，企业系统测试小组。测试工程师在项目开始后加入TEAM进行测试工作，受项目LEADER的领导。测试人员的工作目标是保证产品质量。工作职责是进行软件产品测试，包括编写测试计划，测试说明，测试用例，搭建测试环境，执行测试，提交测试报告等。

联想冲刺CMM3透明报道（5）

肖文秀

     编者注：联想软件事业部在2001年1月通过CMM二级评估，一年以后的今天，他们又在冲刺CMM三级。这是中国民族软件产业的一件大事，因为虽然东大阿尔派已经过了三级、华为印度所已经通过四级、摩托罗拉已经通过五级，但这些公司是否能称为民族软件产业，本身就是一件争论不休的事情… 　　在联想的冲刺过程中，51cmm将进行全程跟踪报道。
为CMM3干杯！
    2001年1月11日下午，3瓶胜利的香槟在科委主任范泊元、信息产业部副司长陈冲、联想集团副总裁贺志强、联想集团助理总裁白慧敏、联想集团助理总裁软件设计中心总经理韩振江、路透集团主任评估师PAUL的手中一同开启，"联想软件通过CMM3认证庆祝会"被推至高潮。
    庆祝会上，英国路透集团伦敦公司的主任评估师Paul郑重地宣布联想参加CMM3认证的结果，尽管这早已在大家的意料之中，但在场的联想员工还是用如雷的欢声表达了他们的喜悦之情。Paul带着嘉许的微笑将SW-CMM3级国际认证证书递给联想集团副总裁贺志强。这标志着联想软件经过英国路透集团为期5天的严格评估，已经正式通过了SW-CMM3级国际认证评估。联想软件在进军国际化的目标上又迈进了坚实的一步。
    联想集团助理总裁、软件设计中心总经理韩振江怀着激动的心情发表了演讲，他回顾了联想软件推动CMM以来的风风雨雨，向为了CMM标准的推行作出了巨大贡献的联想软件的员工们表示了自己的感谢之情。韩振江还阐述了未来联想冲击CMM更高级别的发展规划，韩振江表示联想软件有信心以CMM标准为推动力，全面提升软件开发工作的规范化和标准化，最终大幅度提高软件产品的质量，更好地问客户服务，以面对中国入世后国际软件企业的各种挑战。
    很多政府官员也参加了联想软件CMM3庆祝会，他们是北京市科学技术委员会主任范伯元，信息产业部电子信息产品管理司副司长陈冲，北京市科委信息技术处处长陈力工，中国软件行业协会秘书长胡崑山，北京市软件行业协会常务副会长兼秘书长殷志鹤等。其中范伯元主任、陈冲副司长、胡崑山秘书长和殷志鹤秘书长分别致辞，向联想软件表示了祝贺，也希望联想作为中国冲击CMM的领跑者能够更多地带动国内其他软件企业实现工作的规范化和标准化，从整体上提升中国软件产业面对国际市场竞争的核心竞争力。
    联想软件过程处经理李建奇也代表在推行CMM标准中功不可没的联想软件全体员工做了发言。李建奇表示，联想软件全体员工在推行CMM标准的过程中，已经深切感受到了标准化、规范化的要求给工作带来了高效率和更高的质量，全体员工将在公司领导的引导和支持下，继续以冲击CMM更高级别为契机，全面提高自身的素质，为客户提供质量更高的软件产品和更好的服务。

冷眼看CMM

     2001年6月26日，沈阳东软软件股份有限公司（原沈阳东大阿尔派软件股份有限公司）正式通过了CMM3级认证，成为中国首家通过CMM3级的软件企业，同时也为现在软件业中炒得沸沸扬扬的CMM又添上了一道风景。
    事实上，CMM最初是悄然进入中国的，1999年7月6日当北京鼎新信息系统开发有限公司成为中国首家通过CMM2级评估的企业时，并没有几个人听说过这个新名词，更别说明白它意味着什么了。
    CMM真正火爆起来还是由于2000年6月国务院颁发了《鼓励软件产业和集成电路产业发展的若干政策》（业内人士称之为“18号文件”），该文件的第五章第十七条明确提出“鼓励软件出口型企业通过GB/T19000－ISO9000系列质量保证体系认证和CMM（能力成熟度模型）认证。其认证费用通过中央外贸发展基金适当予以支持。”伴随着 2001年上半年国内的几家大公司先后通过CMM2级认证及其后掀起的强大宣传攻势，CMM成为目前软件业最时髦的词汇。各地政府和科委对企业通过CMM认证也明确表示大力支持，并且对通过的企业予以不菲的奖励。但也有一些人对这种火热的态势表示了担忧。
    在日前举行的第四十二届“中关村IT沙龙”上，北京市软件行业协会秘书长殷志鹤先生就表示：CMM有助于中国软件业的发展，但推行不能过头。
CMM是必修课吗？
    其实企业要不要通过CMM，关键要看这会为企业带来什么好处。简单地看，CMM是一种资质认证，它可以证明一个软件企业对整个软件开发过程的控制能力。目前国际上在挑选软件工程的外包伙伴时一般都要看CMM认证。印度之所以有那么多的企业通过CMM认证，就是因为它们是以软件承包为主。东软当初决定通过CMM认证的一个很重要的原因就在于公司决定扩大国际业务，向欧美市场拓展，而在同欧美客户的接触中发现，只有通过CMM认证才有可能在欧美市场接到订单。所以毫无疑问，想要承接国外软件外包工程的企业就应该通过CMM认证。
    CMM(软件能力成熟度模型：Capability Maturity Model For Software)是由美国卡内基梅隆大学的软件工程研究所(SEI：Software Engineering Institute)受美国国防部委托研究制定并在美国，随后在全世界推广实施的一种软件评估标准，主要用于软件开发过程和软件开发能力的评估和改进。CMM标准共分五个等级，由低到高分别为: 初始级、可重复级、定义级、管理级和优化级。
    那么如果只是开发自主产品、不做外包的软件公司需要通过CMM认证吗？要想回答这个问题，需要从两个方面进行分析，一是是否需要在企业内部实施CMM; 二是是否需要通过认证。
    众所周知，软件生产不同于汽车、纺织等制造行业的生产，它完全是由人进行创造的，外界无法观察，也很难进行监控，同时软件也不像制造业的产品那样可以方便地进行检测评估，这就给软件的管理和控制造成了很大的麻烦。国内的软件企业正是由于缺乏一套完善的管理办法，致使经常出现不能按时发布、产品质量低劣、项目组中个人作用过于放大等问题。因此，中国的软件业要想成为产业，就必须改变整个软件业管理的方式方法。而管理正是CMM的强项，它提出的过程监控以及文档先行，让企业在软件生产的每个步骤都留下翔实的文档，从而实现软件生产的标准化控制，让企业有效地控制软件生产各方面的问题。所以每一个软件公司，无论是做内销还是出口，只要是真正想成功、想持续发展、让企业具备竞争力，就应该学习CMM所倡导的工作方式，在工作管理当中贯彻CMM的思想。 　　而企业是否必须通过认证，则需从两方面来看。不可否认的是，按照CMM的思想进行管理与通过CMM认证并不能划等号。其实在软件业最发达的美国，很多企业包括软件业的巨头Microsoft都没有通过CMM认证。这并不是说，这些企业不重视质量管理，事实上，这些企业多年来已经形成了一套自己的管理方式，而且这套方式同CMM在本质上是一致的（CMM本来就是SEI从美国的工业界中总结出来的）。但中国则是另一种情形，国内的软件企业多年来已经形成了很多不好的习惯。据帮助东软通过CMM认证的Soft Tech公司副总裁李颖女士介绍，CMM认证并不仅仅是在评估软件企业的生产能力，整个评估过程同时还在帮助企业完善已经按照CMM建立的科学工作流程，发现企业在软件质量、生产进度以及成本控制等方面可能存在的问题，并且及时予以纠正。所以中国的软件企业在条件许可的情况下最好还是通过CMM认证，借助强制性的外力来纠正自己的错误。
    但另一方面，企业要通过CMM认证，投入的时间、精力、资金都非同寻常。仅以资金为例，5万美元的评估费用只是最少的部分，另外还要请咨询公司进行咨询与培训，而无形的投入（企业用于改变管理的费用、员工为了学习CMM而花费掉的时间以及为编写文档而花费的精力等）才是最大的一笔投资。还是以东软为例，据估计，所有无形与有形的投入加起来超过了1000万。这对一些小企业来说不啻是一个天文数字，而且这张证书并非终身有效，每过一年半就得重新接受评估。所以企业在决定通过CMM之前必须要想清楚，是否有足够的能力来承担这笔费用，否则弄不好会因此将企业拖垮。其实对于很多资金少、规模小、没有通过把握的企业来说，应该先听一些项目管理、软件工程、测试等方面的课程，并且在头脑中建立起CMM的思想，找到自己的问题，当有改变的欲望以及能力的时候，再去通过CMM认证。
    第一， CMM是帮助企业正规化的一种非常好的方式，真正想做软件，不论是在国内做还是在国外做，都应该达到这个水平。
    第二， 认证的过程是纠正企业偏差的过程，而这是企业花钱都买不到的。
    第三， 一定不能把CMM认证当作一种考试、一种文凭，而是要看成一项有利于企业今后发展的投资，借此来改变中国软件业长久以来形成的积弊。 ——Soft Tech公司副总裁李颖 “18号文件”出台之后，CMM一下子炙手可热，热得已经露出了失控的苗头。正如我们以上所阐述的，CMM确实很重要，但像现在这样大肆炒作，似乎已经偏离了它应该的轨道。主要表现在，现在的炒作集中在企业是否获得了CMM的证书，而非企业在实施后真正发生了哪些质的变化，越来越多的企业把目光集中在了通过CMM认证后的广告效应上。
热潮中的反思
    “通行证”、“质量保证书”等类似的字眼成了陪同CMM一起在媒体上出现频率最高的词汇。很多人错误地认为企业只要通过了CMM认证，就可以获得国外的订单，就会生产出质量优异的软件。事实上CMM只能证明企业具备了按照某种标准进行生产的能力，别人也许会因此把你列入考虑范围之内。但一切都是“可能”，而并非“肯定”，也就是说， CMM只是一个必要条件，并不是充分条件。其实，承接外包的软件企业就像一个软件施工队，你想接到活，没有CMM证书是不行的，但有了CMM证书别人也不一定会选你; CMM证书只能证明你能够按照要求去干活，至于最终你能不能把活干好，与前期制定的标准以及具体操作中的很多其他因素相关。
    最近我们看到很多企业纷纷立下军令状，声称要在一个很短的时间内通过CMM的某级认证，而有些咨询公司也迎合企业的这种不合理要求。很多媒体则喜欢追问:
    “你们什么时候过3级？”看上去所有的人都急于让中国软件业通过CMM的企业数目在短期内可以向印度看齐，变成一个软件大国。从某种意义来讲，设立通过的时间表是件很愚蠢的事，因为企业通过CMM认证是因为企业内部确实发生了质变，而有些改变需要有一定时间的积累，并不是说企业想什么时候完成就可以完成的。而且CMM通过的时间都有国际惯例，经过很多企业的验证，短时间是达不到标准的。企业之所以表现得如此急功近利，根本原因在于他们根本就没有想明白自己要的究竟是什么，而将一纸文书看成了最重要的东西，完全是本末倒置。企业通过CMM的最终目的是让软件企业的管理规范化，使软件开发的过程具备可控性。正如上所言，虽然CMM证书本身对中国的企业是很有好处的，但认证的过程可以让企业得到更大的好处。
    企业急于通过CMM还会产生另外一个问题，即在认证的过程中弄虚作假。原本美国对外包伙伴一般只要求通过3级，但从2000年起这个要求变成了4级，根本原因就在于印度在CMM认证过程中产生了“放水”现象。我们又怎么能相信国内的企业在通过CMM认证时都会规规矩矩呢？很多东西进入中国后都会改变，CMM也没有理由例外。这绝不是杞人忧天，其实ISO9000就是前车之鉴。中国是亚太地区通过ISO9000企业最多的国家，但仍然没有成为公认的产品质量强国。这其中固然因为有一部分企业通过之后反而放松了对自己的要求，但不可否认还有一部分企业的认证是以不正当手段取得的。现在ISO9000在中国已经泛滥成灾，失去了应有的权威性。我们不愿同样的事发生在CMM身上，如果真的到了某一天，国外将软件外包的标准都提高到4级或5级（而这是很多中国软件企业根本就通过不了的），实际上就是自己害自己，堵死了自己的路。
    企业通过CMM不是为了满足其他公司的要求，而是为了让企业更好地发展，为企业进一步扩大规模打下坚实的基础。如果企业只是为了获得一纸证书而通过CMM，那么就已经本末倒置了，对企业的长久发展反而有害。试想如果企业的态度不够端正，即使通过CMM认证，企业又怎么能够保证它在以后的操作过程当中继续坚持CMM规范呢？CMM只是一个让企业更好发展的规范，不应该成为企业炒作自己的工具，企业需要的是优化自己的管理、提高产品的质量，而非一张CMM证书。

全面质量管理在软件业的应用

赵云志（选自软件世界）

    早在20世纪60年代中期，人们就发现软件的生产出现了“问题”，主要表现在生产过程不规范，缺乏管理。后来，人们在软件工程方法学中引入了工程的概念、原理、技术和方法，这种思想在一定程度上解决了软件生产过程中遇到的问题。但是直至80年代还是没有提出一套管理软件开发的通用原则，软件管理不善的问题依旧在大范围内存在。随着软件开发的深入、各种技术的不断创新以及软件产业的形成，人们越来越意识到软件过程管理的重要性，因此管理学的思想逐渐融入软件开发过程中，由美国软件工程研究所（SEI）提出的软件能力成熟度模型（简称SW-CMM）便是软件过程管理思想不断发展的集中体现。
CMM的管理思想背景
    SW-CMM不仅是一个模型，一个工具，它更代表了一种管理哲学在软件工业中的应用。SW-CMM的管理思想来源于已有60多年历史的产品质量管理。1930年，Walter Sheward 率先提出了一整套基于统计学原理的质量控制方法，这些方法后来经过W. Ewards Deming和Joseph Juran的发展和实践得到了广泛的应用。Philip Crosby在《质量是免费的》一书中率先提出将质量管理形成成熟度框架的概念，描述了进行质管实践的5个阶段，表达了质量管理的全部运作。
    Deming、Juran以及Crosby等人的做法后来被称为全面质量管理（TQM）理论。在IBM公司，Watts Humphrey和Ron Radice将这种全面质量管理的思想应用于软件工程过程，收到了很大的成效。SEI的软件能力成熟度模型就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。软件能力成熟度模型中融合了全面质量管理的思想，以5个不断进化的层次反映了软件过程定量控制中项目管理和项目工程的基本原则。SW-CMM所依据的想法是只要不断地对软件企业的软件工程过程的基础结构和实践进行管理和改进，就可以克服软件生产中的困难，增强开发制造能力，从而能按时地、不超预算地制造出高质量的软件。
全面质量管理的含义和特点
含义
    全面质量管理（Total Quality Management，简称TQM）是一个组织以质量为中心，以全员参与为基础，目的在于通过让顾客满意和本组织所有成员及社会受益而达到长期成功的管理途径。
    早期的质量管理仅限于质量检验，仅能对产品的质量实行事后把关，但质量并不是检验出来的，所以，质量检验并不能提高产品质量，只能剔除次品和废品。1924年提出休哈特理论，质量控制从检验阶段发展到统计过程控制阶段。休哈特认为，产品质量不是检验出来的，而是生产制造出来的，质量控制的重点应放在制造阶段，从而将质量控制从事后把关提前到制造阶段。1961年费根堡姆提出全面质量管理理论（TQM），将质量控制扩展到产品寿命循环的全过程，强调全体员工都参与质量控制。70年代，田口玄一博士提出田口质量理论，他认为，产品质量首先是设计出来的，其次才是制造出来的。因此，质量控制的重点应放在设计阶段，从而将质量控制从制造阶段进一步提前到设计阶段。
特点
    全面质量管理即为全员、全过程、全方位的质量管理，力求全面提高经济效益。包括以下基本特点:
    （1） 全员参加:意味着质量控制由少数质量管理人员扩展到企业的所有人员。
    （2） 全过程:将质量控制从质量检验和统计质量控制扩展到整个产品寿命周期。
    （3） 全面运用一切有效方法:是指应用一切可以运用的方法，而不仅仅是数理统计法。
    （4） 全面控制质量因素:意味着把影响质量的人、机器设备、材料、工艺、检测手段、环境等全部予以控制，以确保质量。
    大多数经营管理者认为，全面质量管理的核心是强调一致性，克服随意性，消除差错，使顾客得到全面的满足，它强调为了取得真正的经济效益，管理必须始于识别顾客的质量要求，终于顾客对他手中的产品感到满意。全面质量管理就是为了实现这一目标而指导人、机器、信息的协调活动。因此，全面质量管理可以归纳为两大基本原则:
    首先是以满足顾客需求为导向，不断改善，最终达到顾客的全面满足；其次是以全员参与为基础，进行全过程的质量控制。
CMM对全面质量管理的体现
    在软件业，软件质量得不到提高主要原因在于质量观念的缺乏，而将全面质量管理的思想运用于软件业，是提高软件产品质量、获取竞争优势的有效手段。CMM不但对于指导过程改进是一项很好的工具，而且把全面质量管理概念应用到软件上，实现从需求管理到项目计划、项目控制、软件获取、质量保证、配置管理的软件过程全面质量管理。CMM的思想是一切从顾客需求出发，从全组织层面上实施过程质量管理，正符合了TQM的基本原则。因此，它的意义不仅仅是对软件开发的过程进程控制，最关键的它还是一种高效的管理方法，有助于企业最大程度的降低成本，提高质量和用户满意度。
CMM2——软件需求管理体现TQM的核心思想
    CMM的一个显著的特征是将软件需求作为一个活跃的实体贯穿于整个开发过程之中，实施有效的需求管理事实上渗透在CMM的不同层次（Level）和众多关键过程域之中。软件需求是软件项目成功的关键，软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”。美国质量管理协会（ASQC）将“质量”解释为“产品或服务内在特性和外部特性的总和，以此构成其满足给定需求的能力”，Crosby对于质量的定义也是“同需求保持统一”，从这个意义上说，只有满足用户需求的软件产品才谈得上有好的质量，反之，需求管理也正是从质量出发以确定需求。CMM四级的“软件质量管理”过程域中也明确要求，组织、顾客和最终用户的软件质量需求及其优先级可以追踪到分配给软件的系统需求及软件质量目标。因此，CMM的需求管理正是从全面质量管理的主导思想—“以满足顾客需求为导向”出发的，软件开发则应以需求工程作为核心过程（需求过程与其他过程的关系见图1）。

图1 需求过程与其他过程的关系
    需求工程无疑是当前软件工程中的关键问题，但又是软件工程中最复杂的过程之一。完整的软件需求工程过程包括需求开发和需求管理两个部分，需求开发的一般过程分为需求获取、需求分析、编写需求规格说明书（SRS）、需求验证四个阶段，需求管理则主要包括需求基线的建立、需求变更控制以及需求跟踪等活动。需求获取是通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求 ；需求分析是为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述;由需求模型构件生成精确的形式化的描述，即需求规格说明书，它将作为用户和开发者之间的一致协议;需求分析的结果应该通过评审、测试等手段验证它的正确性、完整性和一致性，这就是需求验证。贯穿于整个过程中，需求管理中最基本的任务则是明确需求，并使所有相关人员达成共识 ；建立需求跟踪能力联系链，确保所有用户需求被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
    需求工程需要各类人员的参与，如领域专家、最终用户、系统投资人、需求分析员、系统开发人员等等，以不同的着眼点和不同的知识背景，获得对软件需求的全面理解。需求工程最大的难度就体现在全方位需求的获取以及非功能性需求与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性，而非功能性需求往往又决定了对软件产品的质量要求。因此，非功能性需求和质量特性的分析模型有待深层次的研究。
CMM3——软件产品工程体现TQM的过程控制
    从CMM三级开始,软件生命周期的各个阶段被严格地划分出来，其目的是保持软件工程活动和软件工作产品的一致性。目前还有很多软件企业的软件开发工作仅限于编码，软件工程方法学中的各种方法和技术得不到真正的应用，因此单纯的软件工程技术并不能有效的解决“软件危机”，改善软件产品的质量;而单纯的测试也只是一种事后检测的方法。只有通过软件过程管理，将需求、设计过程从编码中分离出来，才能对软件质量进行产品生命周期全过程、全方位的控制。
    TQM的核心就在于防患于未然，做到事先控制，确信“下一道工序就是用户”，层层把好质量关，决不让不合格的半成品流入下道工序，一切为下道工序着想。软件开发生命周期一般分为需求分析、概要设计、详细设计、编码、单元测试、集成测试、确认测试、系统测试几个阶段，常用的生命周期模型有瀑布模型、V模型、增量模型、演化模型和螺旋模型，实际的软件过程往往是几种模型的结合。其中，V模型的运用越来越广泛，它强调了各个测试阶段与开发前期各阶段的对应，更明确表示了个各种工作产品间的关系，也易于用户在软件开发中的参与和评价（见图2）。

图2 V模型
    在软件的整个生命周期中，软件产品的质量首先取决于它的设计，因为质量、成本、效益的80%是在设计阶段就确定了的。设计质量控制在TQM中也是非常重要的一个环节，事实证明:产品投产后设计指标修改得越少，产品的质量水平也将越好。要保证顾客对质量满意，就必须从产品开发研制阶段开始做起，需将用户对软件产品的质量要求转化成设计质量标准和开发过程中各个环节的技术要求。
    因此，CMM要求每个阶段的软件工作产品必须文档化，并分别由上下游角色对其进行同行评审，置于严格的配置管理之下，以保证各角色在一致的基础上工作。同行评审的目的则是在过程中及早地消除缺陷，减少后续阶段的返工，避免上一个阶段引入的缺陷遗留到下一个阶段，造成质量成本的成倍增加。

图3 软件生命周期中的缺陷分布
    从图3可以看出，缺陷是在开发过程的前期引入，但越到后期缺陷修复的成本越高，随着CMM级别的提高，缺陷的消除将从后期逐步转移到前期，遗留到用户手中的缺陷也相应减少，这必将大大缩短开发周期，降低不必要的成本。
    因此，CMM的思想就是以过程为基础进行质量控制，把质量控制从事后检测转变为事前预防，能够尽量减少大的设计更改。需求管理、全面质量管理以及TQM中常用的质量功能展开技术（QFD）也都是这种思想的反映。
CMM4——软件质量管理体现TQM的运行机制
    软件质量管理是CMM四级中一个独立的KPA，其目的是使项目的软件质量管理活动是有计划的、软件产品的质量目标是量化的和受到管理的。它遵循了全面质量管理活动的科学程序—PDCA（Plan、Do、Check、Action），即四个阶段:
    （1） 计划:即确定质量目标以及实现这个目标需要采取的措施。制定质量计划是整个质量管理活动的基础。国家标准对质量下的定义为: 质量是产品或服务满足明确或隐含需要能力的特征和特性的总和。
    对于软件来说，软件质量则体现在质量特性上，ISO/IEC9126中规定了6个质量特性，即功能性、可靠性、易用性、效率、可维护性和可一致性，每个特性包含若干子特性。设定质量目标就是要找到用户的质量需求与这些质量特性的相关性，并将其转化为开发过程中可度量的技术指标或能力指标，作为质量控制的依据。
    上述的六大特性属于软件的外部属性，与用户满意度直接相关，可以根据组织的目标和项目的特点建立质量模型，并采用一定的方法，如QFD（Quality Function Deployment）、GQM（Goal Question Metrics）等确定量化的质量目标，但这在实际工作中往往是相当复杂和难以获得的。因此，更常用的做法是以过程能力目标反映产品质量目标，一个典型的能力指标就是缺陷密度（即每单位规模工作产品中存在的缺陷数）和相应的阶段缺陷排错率，可以根据历史数据估计产品的规模和目标缺陷密度，从而对每个阶段发现的缺陷数量进行控制。
    （2） 实施 ：即按预定计划、目标措施及其分工实际执行。为了在过程中控制软件的质量，需采取相应的手段在预定的阶段点或里程碑上进行软件工作产品质量的测量，常用的方法有 同行评审、原型评价、测试等。这些方法主要从两方面对软件的质量进行度量，一是内部属性，即过程和活动自身可以度量的属性，例如工作产品的缺陷密度 ；二是外部属性，即与用户环境相关的属性，这些属性在过程中往往难以度量，只有通过在项目的早期引入用户测试来予以评价，而让用户参与开发过程，大大有利于产品质量的提高。
    （3） 检查 ：即把实施的结果和计划的要求对比，检查计划的执行情况和实施的效果，是否达到预期的目标，并找出原因。在对质量度量的结果进行分析时，往往会用到一些统计工具和方法，如检查表、直方图、控制图、Pareto图、散布图、因果图、运行图等。这些工具可以帮助确定问题、评估现状、发现原因甚至形成下一步措施。
    （4） 处理 ：即总结经验教训，将未解决的问题作为下一阶段制定计划的依据。CMM要求对软件质量测量的结果分析后，应“采取合适的与软件质量计划相一致的措施，以便使得产品的质量测量结果与软件质量目标相符合”。

软件缺陷管理

51CMM原创 作者：刘寅

关键词
    能力成熟度模型 (Capability Maturity Modela, CMMa),
    统计过程控制 (Statistical Process Control, SPC),
    软件开发 (Software Development)
    持续性改进 (Continuous Improvement)
1. 背景介绍
    软件中的缺陷（Defect或Bug）是软件开发过程中的"副产品"。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。
    每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。
    本文从CMM的视角阐述了不同成熟度的软件组织如何管理自己软件中的缺陷。希望软件组织可以结合自己的实践，找到适合自己的缺陷管理过程。
2. 个体行为
    处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。
    所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。
3. 项目行为
    在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：
    （1）提交缺陷
    （2）分析和定位缺陷
    （3）提请修改相应的软件
    （4）修改相应的软件
    （5）验证修改
    项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。
4. 组织行为
    CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。
    从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。
5. 量化管理
    CMM第四级（或称为已管理级）的软件组织会根据已收集的缺陷数据，采用SPC的方法建立软件过程能力基线（Process Capability Baseline）。对于缺陷管理，可以缺陷密度为例，过程能力基线通常包括期望（Mean），能力上限（Upper Control Limit，UCL），能力下限（Low Control Limit，LCL）。其中，"期望"描述了未来项目的缺陷密度的预期值，而UCL和LCL描述了未来项目的缺陷密度的合理变化范围。
    这样的过程能力基线可以用来：(1)帮助未来的项目设立量化的项目质量目标；(2)理解和控制未来项目的实际结果。

    以上图为例，在项目开始时，项目可以根据过程能力基线并结合本项目的实际情况来设立缺陷密度目标；而在项目的生命周期里，可以使用这样的过程行为图（Process Behaviour Chart）来理解和控制项目的实际的缺陷密度。当项目的实际缺陷密度在UCL和LCL之间波动时，可以理解为项目的开发过程处于受控状态。换言之，当项目的实际缺陷密度超越了UCL或LCL时，可认为某异常的原因（Special Cause）导致了这一现象，必须进行分析并实施某种行动来防止该异常的原因再次发生，从而确保开发过程始终处于受控状态。
6. 持续优化
    与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。
    就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。
    缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。
    当实施了缺陷预防，缺陷密度的过程行为图将可表现为下图的形式。
7. 小结
    软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。不同成熟度的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷，并跟踪缺陷纠正过程。高成熟度的软件组织，还会充分利用缺陷提供的信息，建立组织过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的持续性优化。
参考资料
    [1] Capability Maturity Model for Software, Version 1.1, Mark C. Paulk, Bill Curtis, Mary B. Chrissis, Feb 1993.
    [2] Understanding Variation--The Key to Managing Chaos，Second Edition，Ronald J. Wheeler, SPC Press

CMM与传统企业文化

康健（转载自计算机世界网）

    近来，国内软件企业掀起了一股CMM的热潮，一些大的企业，如华为、东软、联想、用友、托普等，通过CMM的认证实施，明显改善了以往软件企业最难控制的进度、成本和质量，加上政府的政策推动和媒体的炒作，软件企业纷纷把实施CMM作为企业的一项战略决策，投入巨资，来推行CMM。一时，CMM成了IT行业的一匹"黑马"。
    但是，正如当时的ISO9000热一样，推行的效果并不尽人意，在一些企业内部遭到了很大的阻力。主要表现在以下2个方面：
    一是企业高层内部的思想不统一。由于CMM主要以提供了一种软件工程的方法，它并不像做市场一样，在短时间内就能看到投资收益。以CMM的实施起步级L2为例，一般至少要花费1年左右的时间，以后向上难度将逐渐加大，每上一个级别，至少又要1-2年的时间，而且，在上了一个台阶之后，还要定期进行自我评估，一不小心，又会降到以前的级别甚至更低。当企业投入数以百万元的资金和人力不能看到明显成效时，就如同当初风险投资商投资网站而迟迟看不到收益时，试问，又有多少领导还能保持十足信心？
    二是来自直接项目管理者的阻力。在软件开发中，软件的质量、开发进度与开发成本之间存在着矛盾，在软件行业竞争趋于白热化的大环境下，产品发布时间直接关系到企业的生存。项目经理将一边面临着来自客户的压力，一边面临着来自高层管理者的压力，在对CMM到底会对软件开发起到多大作用尚不可预见的前提下，让项目经理额外花费大量的时间和精力来进行各种计划、总结、会议、评审等CMM要求的工作，试问，项目经理又有几个愿意让自己成为"第一个吃螃蟹的人"？
    国内第一家通过CMM 5级认证的是Motorola中国电子有限公司，是一家著名的跨国公司。国内大约在1995年，就有企业开始涉足CMM，至今已有6年的历史，但国内大大小小数以万计的软件企业，目前通过CMM 2级认证的不足20家，而我们的紧邻印度，通过CMM 5级认证的软件企业就有20多家，为什么西方的企业，实行CMM比我们顺利的多，这里面虽然有一定的企业资金、技术实力方面的因数，但究其深层次的原因，实质上是体现了一种东西方文化观念上的差异。
一、 人治观念和法制观念的差异
    我们先来看一下什么是CMM。CMM（Capability Maturity Model For Software，软件能力成熟度模型）是美国卡内基梅隆大学软件工程研究所，应美国联邦政府的要求开发的一种用于评价软件承包商能力并帮助其改善质量的方法，它提供了一个评估软件开发过程的管理以及工程能力的标准，是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度认证标准。CMM标准共分为五个级别：初始级、可重复级、定义级、管理级和优化级，从低到高，标志着软件生产的计划度越来越高、生产周期越来越短、成本也越来越低。
    CMM的本质是通过对软件开发过程中一些关键区域的精确定义，来使软件开发从一个不确定的"黑箱"操作过程，变成各环节的可视、可对偏差随时控制的"透明"操作过程。它主要通过以下4个方面来进行：
    1、精确定义各种角色和职责，以减少个人、组织间职责的模糊区域；
    2、精确定义软件生命周期中各环节的所有开发流程，以减少操作中的随意性；
    3、精确定义各种文档，以保证产品和技术的可重复性和一致性；
    4、通过评审、检查、监督来达到不断纠偏和持续改善的目的；
    所以，CMM体现了西方管理科学中精确化管理的一种理念，以科学的方法来解决复杂的管理问题，这是西方法制社会文化的一种体现。如CMM中SEPG(软件工程过程组)、SQA（软件质量保证组）和SEG（软件工程组），在软件工程领域体现了西方立法、监督和执法的制衡体系，体现的是西方文化的法治观念。如果我们不理解其中的精髓，以为化钱请个咨询公司，就能脱胎换骨，一步从"作坊式生产"迈入"工业化生产"，实际上只能是一种良好的愿望。所以，CMM对于国内的企业来说，实际上将面临的是一场痛苦的管理和文化变革，其产生的冲突是从人治阶段走向法制阶段的一种必然。
二、 家族文化观念和开放文化观念的差异
    家族文化是国内许多企业的普遍现象。在组织和个人上，表现在各个组织领导者的职权"领地"内的不可侵犯性。在组织中，领导者具有绝对的权威，组织的文化完全取决于领导者的个人风格，领导者的利益与组织的利益合为一体，希望组织大而全，不愿把技术和经验开放与人共享，合作性很差。在这种封闭式的文化氛围下，产品开发的所有工作往往被包容在一个项目组内或几个人进行，CMM所要求的SQA、评审、测试等涉及第三方的工作就很难开展，产品开发完全依赖于其中几个杰出人才，产品的质量、开发进度和开发成本完全失控，项目风险极大。
    而CMM倡导的是一种相互协作的开放式的文化，在严格的制度下，它希望企业能同时提供一个宽松的人际环境，鼓励员工之间、同行之间尽可能多的交流，通过培训、同行评审、组间协调等一系列人与人之间的沟通行为和活动，来保证技术和产品在可重用基础上的不断提高。最终通过提升整个组织的能力，达到提高产品质量，降低开发成本，加快开发进度的目的。
    所以，国内企业在决定实施CMM时，必须把它作为一项企业的管理变革来实施，领导首先应该转变观念，接受西方科学的管理方法和文化理念。通过实施CMM，改造了传统企业文化，使我们的软件企业能尽快走向国际化的轨道。

国内软件业对CMM认识的阶段性

51CMM原创 作者：雅行

    初识CMM，恐怕很多人都会被其陌生的理论结构、枯涩艰奥的文字搞的一头雾水。CMM能否成为医治中国软件业顽疾的灵丹妙药？CMM适合中国国情吗？CMM适合小型软件企业吗？CMM与我们熟悉的ISO9000有何不同？这些问题大多困扰过前期的CMM关注者。 　　不同的思考，透露着不同的心态：怀疑、担心、观望……
    这时需要“打破神秘，从头学起”。
    大凡我们引入西方的新的理论，总是要经历一个神秘期，“众说纷纭，找不着北”。原因在于，这个阶段大家的研究都有限，实施经验更是缺乏，谁都不能说服谁。但过分空谈会误事。尽快冲破迷雾，仔细学习、研究和使用。不管是想实施还是想批驳，都要先把人家的东西弄明白，所以要：“打破神秘，从头学起”。
    随着对CMM的学习和认识的深入，眼前的神秘感渐渐散去。“就是订制度么，我们其实并不需要知道为什么，只需要有人告诉我们怎么做”、“跟ISO 9000没有本质差异”...... 。是不是感觉：可以用很短的话，把CMM的精神概括出来？
    批判的学习不是坏事，只是不能走极端。失去神秘感，CMM便由重变轻。可CMM本来就声明自己是common sense。
    CMM的价值本来没有变化，只是我们的认识在变化罢了。
    国内软件业的最缺正是管理，CMM恰好可以补上我们的不足。在质量三角形中，技术当然是非常重要的，技术和人这两个因素是影响产品的先决的条件。而过程是影响产品的第三个重要因素，而且随着产品规模和团队规模的增大，以及技术的成熟化，过程瓶颈越来越突出。有人说，“缺乏规范的过程正是国内软件企业的软肋”。
    CMM的一个重要价值在于它把众多的common sense整合成完整的知识体系，CMM中贯穿着抓主要矛盾的哲学思想，它的分级思想是与ISO9000的一大不同，就是承认资源总是相对不足的，问题不可能一下子全解决，要分几步（等级）走，每一步要抓一些关键的因素（KPA）。再比如他的先做管理后做工程的思想，用Humphrey的原话来解释："看起来，定义和实施一个工程过程似乎要比定义和实施管理过程容易（特别是在技术人员的眼中），但是如果没有管理过程的规定，工程过程很可能会成为进度和成本等压力的牺牲品"。所以在L2里面全部是项目管理的过程，而产品工程（SPE）则放到了L3。我认为，CMM作为SEI许多专家多年研究的结晶，其中的丰富内涵有待于我们学习和实践的过程中不断认识。它一定会不断的给以我们启示的。
    CMM是金矿，乍一看就是一堆砂，但其中蕴藏着金子。要想得到它，需要付出很大的努力！
    CMM不是个别人的事，组织中每个人都应不同程度的参与。每个人都要想想我应该尽到什么职责，要“调整心态，从我做起”。
    对于高层经理来说，需要正确认识CMM实施带来的额外工作量，配备必要的资源，CMM实施最直接的后果就是带来了很多的事务性管理工作，这要求设立一些专职的角色，如SQA、SCM，或者配备适当的工具，把相应的工作量从项目经理的身上分离出来。否则一旦技术和管理展开竞争，牺牲的肯定是管理；高层管理有必要改变自己的管理习惯，原来很多事都口头裁决，现在需要先看有没有规范，如果有，就尊重规范，规范就是文档化的组织意志。最后，实施体系就是打破旧平衡，建立新平衡，这个过程中体系会相对混乱，对正在运行的项目会产生一定的影响，甚至于在个别企业中，出现技术人员由于适应不了新的工作方式而离职的例子，这些情况，高层管理者都应该心理上有所准备，对CMM抱有坚定的信心。
    对于项目经理来说，要改变技术本位主义，国内的项目管理，大多是技术出身，没有接受过系统的管理知识，心态多是技术带头人而已。CMM本质就是解决管理问题，所以对项目经理来说，做CMM就是，从技术上分出一部分时间来做管理，管理者需要主动调整心态以适应新的情况。
    项目经理的从我做起还包括，他们是沟通项目层和管理层的桥梁，对于CMM的贯彻起着承上启下的作用。贯彻CMM不可能奢望全体人员一致拥护，但是项目经理的积极参与却是必要的。CMM实施的内部驱动有两个：高层经理和项目经理。高层经理通过资源和政策驱动，项目经理以实际问题驱动。项目经理要做过程改进的“明白人”，认识到过程改进工作正是为项目服务的,而不单单是被动的服从高层经理的安排和质量经理的规划等等。
    对于质量管理人员来说，要增强服务意识，质量部门是主要的制度制定者，但这并不意味着质量管理人员就应该高高在上。一线开发者是为用户服务的，而职能管理部门又是为一线服务。服务意识的增强体现在深入了解项目经理对过程改进的需求，根据实际需要驱动质量工作重点，争取在局部先有所突破。质量宣传要密切接触一线人员，采取多种灵活方式，多了解反馈，这可能比会议形式的宣贯更有效。过程改进需要不断地成功来推动后续的改进。这样，SPI项目要求进行很好的策划。问自己：何时何种方法向大家证明改进已显现效果？
    开发测试人员的“从我做起”包括改变以自我习惯为中心的做事方式，适应遵循过程规范的工作习惯。只有大家关注过程规范，它才有可能得到不断优化和成熟。避免“两张皮”。开发人员还需要通过自身努力，借鉴PSP的方法提升个体软件能力，这是个自我工程，须以个人的上进心为动力等等。
    总之，对于CMM，前期“打破神秘，从头学起”后期“调整心态，从我做起”，前期重在学，深入学有利于打破神秘，尽快结束争论和观望；后期鼓励做，要调整心态，改变习惯，从自身开始，方可获得成功。
    CMM在中国是个新事物，需要辩论、需要研究、更需要脚踏实地的去做。
    我相信只要实事求是的去做，总会有所裨益的。

实施CMM时必须解决的认识问题

51CMM原创 作者：任甲林

    在基于CMM实施软件过程改善时，有些根本的思想认识问题解决不了，往往会使实施的周期比较长，效果不好，甚至导致过程改善的失败或中止。软件企业的高层领导、企业的过程改善主管、销售人员、项目经理及一般的开发人员都需要对这些问题统一认识，在此基础上才能消除各方面的阻力，把握好过程改善的方向，控制好过程改善的进度。笔者在总结了3年的实施CMM的经验教训后，归纳了如下几个思想认识问题，供拟准备进行过程改善或正在进行过程改善的软件企业同行参考： CMM不是万能的，只有CMM是不行的，还要技术(开发方法、工具)人员二个要素一起改善
    在软件工程发展的历史进程中，人们为了解决软件危机，尝试了采用诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案，但是效果并不那么显著，CMU SEI提出了软件过程能力成熟度模型（CMM）基于过程的角度来解决软件危机。那么是否实施了CMM，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，才能保证带来经济效益，因为人员、技术和过程是支撑软件开发平台的三条腿，少了那一条都不行。大家也都知道木桶原理，一个木桶可存槠水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。
    在开始实施CMM时，最容易犯的一个错误就是"唯管理论"或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、也采用ROSE等开发工具，但是仅仅是形似，没有做到真正的OO方法，没有得到OO方法的精髓，这种问题仅仅依靠过程改善是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMM无法解决的。
管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心
    在实施CMM时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显著，上面我们谈到了，效果显著与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。
任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备，要有耐心。
坚持活学活用，以我为主
    机械照搬CMM的条文是在实施CMM时常犯的错误。在国内的软件企业中，都是从作坊式的软件组织逐步发展过来的，也没有经过软件工程化阶段，甚至也没有什么标准、规范。真正超过10年软件工程经验的人员更是比较少的，加上大家不愿从事管理，因而有的企业所组建SEPG的人员中可能在工程经验方面是有欠缺的，又没有真正的有实践经验的专家进行指导，所以对CMM的理解就不可能一下就很深刻，不敢裁剪CMM，容易机械照搬CMM条文，其实这恰恰违背了CMM的精神，CMM是软件工程经验的集大成，是从实践中总结出来，用以指导实践的，CMM本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结，有些内容是CMM中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。
    在推行CMM时，所以遇到的阻力，很大程度上是由于照搬CMM的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁有发言权。所以在制定CMM规程标准时，尤其是在制定大家要执行的操作规程、模板和记录表样时，一定要得到执行者的认同，否则就容易造成执行和沟通的障碍，你硬要推，表面上看来似乎大伙也照规程做了，其实是表面文章，对改善没有实际帮助，以导致SPI工作受阻。
要改良式不要革命式
    以革命的方式来实施CMM，期望通过一场运动来解决过程能力的问题，一种可能是不懂CMM，不晓得管理的改进是循序渐进的，一种可能是明知故犯，期望在短期内通过CMM评估，单纯追求市场上的轰动效应。有的企业在短时间内虽通过了CMM几级评估，我想恐怕由于没有实效而得不到大家的认同而难以将这种"水平"持续下去。一个企业引入CMM之后会从本质上影响企业的文化，改变大家的思想与做事方法。有人曾形象得将过程改进比喻为减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复到原来，我认为这个比喻是十分形象的。
    革命的方式与改良的方式我都曾经尝试过，效果差异很大。所以我总结一条就是让大家在"小步快跑"中接受变革，这样风险最小，效果最好。
CMM与企业的创新文化是不矛盾的
    软件企业的有些管理人员，也包括一些开发人员往往抱怨或认为严格的管理会束缚他们的创新，他们认为在CMM中提倡的一种按部就班，什么活动都要做计划、按规程标准来做，对企业的创新文化会起负面作用。在我遇到的开发人员中，越是技术钻研越深的人持这种观点的越多。我想形成这种观点主要有二个原因：一是企业在推行CMM时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。比如说在分析与设计阶段，需要开发人员能够发挥创意的成分更大一些，如果你要求他们一定就要按统一的文档标准来写文档，甚至字号大小、缩进格式一点也不能差，这的确很难做到，可能你需要在项目组配备文档支持人员，有他们来做这些完善工作，降低分析与设计人员的这些工作量。二是这类人员缺少真正的软件工程经验，做的大项目太少，经历的失败太少。关于这一点是不要争论的，CMM是软件工程经验与教训的集大成，我们无需再去重复那些失败。
    软件企业必须形成创新的文化，事实CMM本身也一种软件工程管理的创新，而技术创新是必须进行管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。
要勇于实践，也要允许犯错误
    CMM就是软件工程经验与教训的总结。在实施CMM的过程中，肯定会走些弯路，甚至于要犯错误，由此许多人会议论纷纷，一直会反映到高层经理处，这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，现在大家都是"摸着石头过河"，不下水，是没有办法过河的，临渊慕鱼不如退而结网。要少说不，少说难，勇于实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、SEPG等人员有偏见，要提倡这种文化。
管理过程改进是组织内所有人的事情，而并非仅仅是SEPG的事情
    按照CMM专家的建议，在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%，根据这一建议，我们企业内一开始就配备专职的软件工程过程组（SEPG），这些员工专职负责企业的软件过程改善工作，另外我们根据需要组织一些技术任务组（TWG），他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题：
    SEPG成了最忙的人，TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由SEPG的成员替代TWG做工作；
    企业的非开发人员对管理过程改进的效果一下没有明确地感受到，甚至看到由于加了些新的活动可能使项目拖期可能会更严重，于是他们可能就会将这些抱怨反馈到企业的高层经理，在推行过程中经常会听到：我这个项目时间太紧，当前不适合使用CMM；
    高层经理迫于市场的压力，甚至可能会提出不合实际的项目工期等等。
    推行CMM不仅仅是管理人员的事情，每个人都要积极参与。要改变原来的一些做法：即SEPG是在使劲的推进CMM的工作，而不是大家自觉自愿的来实施CMM。从SEPG的角度来看，要做好培训的工作，首先要解决的大家的思想认识问题，这还是比较难的，有些人的思想还是比较顽固的。
    以上是我对前几年推行CMM的过程遇到的思想认识问题的总结，不一定准确，希望各位同行指正。当然管理首先要解决的是思想认识上的问题，不但在主观上要解决，在客观上也要有措施，光说不练是不行的，光练不说也是要否定的。我曾经遇到过类似的问题，有的开发人员或者项目经理在口头上是可以接受变革的，会配合工作的，但是在具体操作，很可能又会遇到事实上的否定，这时作为CMM的推广人员要尽快提出实施的具体措施，尽快落实。任何变革都要涉及到企业内的权利的再分配，不要忽视企业政治，这是客观存在的，所以一定要预防那些光说不练者。

CMM实施中的四个常见问题

沈辉（转载自计算机世界网）

    许多软件企业在实施CMM过程中，都投入大量的人力、物力，公司领导更是亲自督阵，制定了各种奖惩制度，按理说，CMM实施应该是很顺利的，但在实际实施过程中还会出现各种问题。下面是结合公司CMM实施过程中的情况总结出的几个常见问题。
缺乏经验，存在技术阻力
    这里的技术不是软件开发技术，而是与CMM实施有关的技术。阻力表现在两方面：一方面，由于对标准的要求不熟悉，所以编写过程文档质量较差；另一方面，由于项目经理对文档要求不理解，或对操作方法不熟练，导致执行的结果与要求相差甚远。
    由于CMM标准要求的内容较多，大家又都是初次接触，对标准的要求很难真正理解，更不用说熟练掌握了。因此，我们在编写公司的过程文档时，对于有些意见总是不能达成一致，需要反复讨论、甚至请教咨询方才能解决，文档编写速度很慢；有些文档主要是参考模板改编而成，改编人对原来的模板就不理解，改完后仍然不知所云。虽然用词晦涩、语义含糊、前后重复或矛盾，但为了赶时间，这些质量不高的过程文档略经评审就投入使用了。
    由于过程文档用词晦涩、语义含糊，项目经理在使用时不能理解文档的要求是什么。比如，在项目计划模板中，前后出现了两处工作产品介绍，项目经理就不能理解为什么，而文档编写人员也忘了自己原来的意图。后来，经咨询方解释才知道，原来前面应该是最终的软件产品，后面才是软件工作产品。
    如何把握实施力度，既保证过程质量，又不会对进度造成重大影响？由于经验不足，过程改进人员和项目经理对此总是不能取得共识。我们有一个项目计划，前后写了4版，差不多用了20天才通过评审。当然，这一方面是因为项目经理写作能力不强，文档确实存在较多问题；另一方面，也是因为SQA(软件质量保证)人员经验不足，要求太严，列出问题太多，导致项目经理无所适从。后来，还是咨询方及时纠正了这个问题，他们说：如果计划没有大的问题，能够用于指导下一阶段的工作就可以先评审通过，这样项目组工作才有据可依; 当然，问题还是要改，只要在以后的版本中予以更正即可。
进度与质量难以兼顾
    软件开发过程中，最常见的问题之一就是：项目进度要求与软件质量保证之间的矛盾。
    在没有开发规范以前，软件开发随意性较大，通常为了赶进度而牺牲管理工作的时间。项目经理往往是项目开发主要人员，管理工作量很小。现在就不同了。项目经理不仅要关注软件开发，还要加强过程管理，并且有了SQA工程师进行监督。这时，项目经理要拿出相当多的时间去做管理。由于经验不足，上述工作花费的时间远远超过了计划时间。
    由于实施CMM占用较多的时间，高级经理、项目经理就难免会有看法，认为实施CMM严重影响了项目进展，而短期内又难以看出质量保证的效果。而一旦他们认为质量保证对项目进度产生了负面影响，再要他们按照要求开展工作就有点困难了。
    从理论上讲，按照好的过程来管理开发工作，不仅可以提高开发质量，也可以加快开发进度。但实际上，由于经验不足，在实施初期，不仅看不到质量改善的效果，反而会降低开发速度，难怪有些人不愿意去做。这就需要公司决策层进行长远考虑，采取激励措施、提供资源保证，确保体系执行，进行持续改善。
目标和需求变化多，难控制
    这也是软件开发中的一个常见问题。
  瘀再分配，不要忽这是客观存在的，所以一定要预防那些光说不练者。 　有一个软件产品研发项目，原来定义的客户目标群是中小银行，研发立项也得到了公司有关部门的批准，项目做到了详细设计阶段。但后来，销售部门提出目前中小银行对该产品的市场需求不大，应该调整客户目标为某大银行。为了适应客户目标和提交时间的改变，项目经理不得不改变软件系统的实现方法，改变体系结构，重新进行需求分析、调整概要设计。虽然这些因素本身与CMM无关，但是当时项目经理刚刚完成项目估计、项目计划以及文档评审工作，而现在，一切又要重新开始了。
    有时，虽然项目总体目标没有大的变化，但是客户需求频频变更。按照要求，对变更请求需要评审，还要修改从需求开始的所有文档以保持一致性。这样的事情如果频频发生，项目经理的很多工作成果都会被白白浪费，项目经理容易产生挫折感，严重影响实施CMM的积极性。
    在发生这种问题时，高级经理有责任做好项目经理的思想工作，告诉项目经理这不是他的错，他做得很好，并鼓励他继续做下去。这样，在一定程度上，能激励项目经理的信心和热情。
不同角色面临不同问题
    CMM毕竟是个新事物，绝大多数人对它不是很了解，因此在执行中问题很多。而由于资源有限，很多问题不能得到及时、有效的解决，影响了实施效果；在看不到明显效果的情况下，要求项目经理严格执行，又有很大的难度。这可能就是我们目前碰到的最大问题。
    从项目经理来讲，他们面临着两方面的压力：高级经理对他们进度的要求，远远高于CMM实施方面的要求；SQA人员要求他们按照CMM标准实施，但是在具体操作方法上又没有很好的经验可以提供，需要摸索着执行，很多时候都在做无用功。
    对于SQA人员来讲，一方面他们需要去做高级经理的工作，取得他们的理解和支持；另一方面，他们也要不断深入了解CMM的实施要点和操作方法，但是由于没有CMM专家的支持，经常会走弯路，导致项目经理颇有怨言。
从高级经理的角度来讲，公司给他们的资源也是有限的，客户要求的期限又是固定的，当进度与质量保证发生冲突时，如何去平衡？也确实是一个比较头疼的问题。
    从上面可以看出，CMM实施过程中，不同的角色面临着不同的问题，需要在实践中不断摸索，协商解决，寻找适当的方法去解决问题或减少问题。
    从目前情况看，CMM实施困难很多，但是，从发展趋势来看，CMM实施的前途是光明的。越来越多的企业认识到实施CMM的必要性，加大了实施投入来保证实施力度。而且，随着CMM实施人员的增多，大家不断总结、交流经验，问题也越来越容易解决。

如何在短期内达到CMM2级目标？

广州亚远景科技有限公司 候亚文

    当前许多组织在实施CMM?模型时所面临的挑战是如何进行快速实施，他们最关心的问题是怎样在最短的时间内达到CMM2级水平。许多企业发出了这们的疑问：我们公司能在一年或更短的时间内完成CMM实施吗？答案是绝对、肯定--或许？其实，唯一能够有效测试你的组织水平方法是使用CMM模型与组织现状进行比较，使用以下所列方法能帮助你了解你的组织成熟度级别及离你的最终目标还有多远。我们以下提供的解决方案或许能帮你加快实现你的目标。
    -组织士气 你的组织是否已明确CMM目标并制定相应实施计划？管理层是否知道实施CMM会给企业带来什么样的利益和困难？是否各个部门都支持实施CMM？是否有足够信心支持整个实施过程？
    -文档 你有文件和程序去执行和定义CMM二级吗？在实施的过程中有足够的证据确保实施的可从复性吗？你有为每个新的小组成员提供足够的指导并确切地告诉他（她）们需要做些什么？你有清晰地定义了每个阶段的负责人吗？每个阶段都规定了相应的时间和秩序了吗？在实施CMM过程到达到2级成熟度模型的整个周期中，文件起到至关重要的作用。并且每份文件必须是完整的。
    -培训 是否每个相关人员都受过CMM?培训并了解实施CMM?是公司利益所驱使？他们是否都按照文档的步骤执行各自职责？2级的关键过程培训，参与人员必须包括项目经理、软件配置管理人员、软件质量保证经理和软件分包合同经理。企业必须认识到在实施CMM过程中，每个参与人员都将根据自己能力扮演某个特定角色。切记我们要确保项每个项目负责管理人员都要受过有关CMM相关培训并明确各自职责。
    -资源 当你的企业在执行需求管理、项目管理和软件配置管理时，你有相应的资源去定义CMM?过程的可执行性吗？你有指派专业人员审核备案文档及文档编写步骤吗？为避免项目小组的误导，其他参与人员是否有正确的报告指导？如果你负责软件开发的分包合同，你有指定专门的软件分包合同负责人吗？在实施CMM相应的软件开发计划和相关程序时，必须提供充足资源以确保实施顺利进行。
    -时间制度化 在实施最终测试时一旦碰到以上问题，你的小组成员是否根据程序规定作出相应的解决方案？你将要求被证明至少有三至五个项目是根据CMM2级程序来执行的。计划评估的时间必须与项目进度表相符合。并提供证据说明你的项目进度是朝着有利CMM实施方向前进的。
解决方案：
    以下为一系统列有关软件过程改进（SPI）不同领域的专业操作程序，你可以适当选择作为你实施CMM2级的步骤。
    初始诊断- 初始诊断有助于明确定义组织软件改进现状和主要缺陷及优势。帮助你理解CMM?含义。然后由工方专家根据诊断工具（SPI'n Action)评审你的项目和过程文档驻识别组织缺陷。与其他咨询评估机构不同，我们会通过此次活动的结果计算你组织的软件改进的最佳路径和时间。
    软件过程改进咨询- 我们的专家们在定义软件开发各生命周期阶段有着丰富的专业经验和已成形的案例库支持，我们值得骄傲和信赖的是在组织原有ISO9001平台文件上转化CMM文件。这将大大缩短改进进程，提高工作效率。
    过程评估- 定期进行过程评估能使组织了解如何快速进行缺陷修复，使组织更容易了解如何达到CMM? 2级目标。同时，使软件能力评估实施更有价值。
    软件能力评估- 为了实施一个符合CMM? 现状能力改进评估，SEI授权的主任评估师和其他SEI授权的专家将开展一个官方的软件能力评估研讨会。
    以上信息适用于某些想在短期内取得成效的组织。这些组织的基础结构必需是很稳定的并清晰定义CMM? 目标；很强的管理支持；每个过程和程序符合CMM2级各个关键过程域；每个受训人员能有效执行各自职责；适应各个文档程序要求，在这些条件具备的情况下，ESI的专家们能帮助此组织在短期内获得成功。

SQA到底是什么?

何晓源 王慧文（转载自计算机世界报）

     SQA(软件质量保证)是CMM2级中的一个重要关键过程区域,它是贯穿于整个软件过程的第三方独立审查活动,在CMM的过程中充当重要角色。
    SQA的目的是向管理者提供对软件过程进行全面监控的手段,包括评审和审计软件产品和活动,验证它们是否符合相应的规程和标准,同时给项目管理者提供这些评审和审计的结果。因此,满足SQA是达到CMM2级要求的重要步骤之一。
背景
    对任何制造业企业来说,质量保证活动都是必不可少的。第一个正式的质量保证和控制职能部门于1916年在贝尔实验室出现,此后迅速风靡整个制造业。软件的质量标准首先出现在20世纪70年代军方的软件开发合同中,此后得到了广泛的应用。在软件越来越普及的今天,"软件质量保证"更成为软件开发企业和最终用户所关心的问题。
    实践证明,软件质量保证活动在提高软件质量方面卓有成效。IBM360/370系统软件的开发经验证明了这一点,IBM的有关报告指出,在8年的时间里,软件质量提高了3～5倍,而SQA是其质量体系中的一个重要组成部分。
目标
    SQA组织并不负责生产高质量的软件产品和制定质量计划,这些都是软件开发人员的工作。SQA组织的责任是审计软件经理和软件工程组的质量活动并鉴别活动中出现的偏差。
    软件质量保证的目标是以独立审查的方式监控软件生产任务的执行,给开发人员和管理层提供反映产品质量的信息和数据,辅助软件工程组得到高质量的软件产品,其主要工作包括以下三个方面:
    ● 通过监控软件的开发过程来保证产品的质量;
    ● 保证生产出的软件和软件开发过程符合相应的标准与规程;
    ● 保证软件产品、软件过程中存在的不符合问题得到处理,必要时将问题反映给高级管理者。
    从软件质量保证的目标中可以看出,SQA人员的工作与软件开发工作是紧密结合的,需要与项目人员沟通。因此SQA人员与项目人员的合作态度是完成软件质量保证目标的关键,如果合作态度是敌意的或者是挑剔的,则软件质量保证的目标就难以顺利实现。
任务
    软件质量保证的主要作用是给管理者提供实现软件过程的保证,因此SQA组织要保证如下内容的实现:
    ● 选定的开发方法被采用;
    ● 选定的标准和规程得到采用和遵循;
    ● 进行独立的审查;
    ● 偏离标准和规程的问题得到及时的反映和处理;
    ● 项目定义的每个软件任务得到实际的执行。
    相应地,软件质量保证的主要任务有以下方面:
● SQA审计与评审
    其中,SQA审计包括对软件工作产品、软件工具和设备的审计,评价这几项内容是否符合组织规定的标准。SQA评审的主要任务是保证软件工程组的活动与预定义的软件过程一致,确保软件过程在软件产品的生产中得到遵循。
● SQA报告
    SQA人员应记录工作的结果,并写入到报告之中,发布给相关的人员。SQA报告的发布应遵循3条基本原则:SQA和高级管理者之间应有直接沟通的渠道、SQA报告必须发布给软件工程组但不必发布给项目管理人员、在可能的情况下向关心软件质量的人发布SQA报告。
● 处理不符合问题
    这是SQA的一个重要的任务,SQA人员要对工作过程中发现的不符合问题进行处理,及时向有关人员及高级管理者反映。在处理问题的过程中要遵循两个原则:其一,对符合标准过程的活动,SQA人员应该积极地报告活动的进展情况以及这些活动在符合标准方面的效果;其二,对不符合标准过程的活动,SQA要报告其不符合性以及它对产品的影响,同时提出改进建议。
实施
    软件质量保证任务的实现需要考虑几方面的问题。首先,要考虑SQA人员的素质。SQA人员的责任是审查软件设计、开发人员的活动,验证他们是否将选定的标准、方法和规程应用到活动中去,因此,SQA工作的有效执行需要SQA人员掌握专业的技术,例如质量控制知识、统计学知识等。其次,SQA人员的经验对任务的实现同样重要。应该选择那些经验丰富的人来做SQA,同时为SQA人员进行专门的培训,以使他们能够胜任这项工作。第三,组织应当建立文档化的开发标准和规程,使SQA人员在工作时有一个依据、判断的标准,如果没有这些标准,SQA人员就无法准确地判断开发活动中的问题,容易引发不必要的争论。第四,高级管理者必须重视软件质量保证活动。在一些组织的软件生产过程中,高级管理者不重视软件质量保证活动,对SQA人员发现的问题不及时处理。如此一来,软件质量保证就流于形式,很难发挥它应有的作用。第五,SQA人员在工作过程中一定要抓住问题的重点与本质,不要陷入对细节的争论之中。SQA人员应集中审查定义的软件过程是否得到了实现,及时纠正那些疏漏或执行得不完全的步骤,以此来保证软件产品的质量。
    此外,做好软件质量保证工作还应该有一个计划,用以规定软件质量保证活动的目标,执行审查所参照的标准和处理的方式。对于一般性项目,可采用通用的软件质量保证计划,而对于那些有着特殊质量要求的项目,则必须根据项目自身的特点制定专门的计划。
    总之,软件质量保证是软件过程中的独立审查活动,它从一个侧面反映了现行软件过程能力的成熟度水平。软件质量保证活动是贯穿整个软件过程的,那种到编码之后才开始关心质量的做法是极其错误的。

CMM认证谁受益

张本丰

CMM是什么，对一个组织有什么用？
    CMM是能力成熟度模型（Capability Maturity Model）的缩写，是由CMU/SEI（美国卡内基梅隆大学软件工程研究所）1987年开发成功的，现在普遍使用的是V1.1版本。CMM模型从1~5分为不同的等级，按照软件过程能力将一个组织定位于不同的成熟度等级。其一个重要思想是帮助一个组织通过基于模型的软件过程改进而达到使其软件过程向更高的能力成熟度等级迈进的目标。在这个过程中一个组织必须建立自己的软件过程，并依据CMM模型要求对此过程进行评估，针对评估结果来进一步改进自己的软件过程，再次评估自己的软件过程以期达到更高的成熟度等级或防止自己的过程能力退化。如此循环最终使一个组织的软件过程能力趋于高度的成熟。这样客户在选择其项目的承包商时可以依据一个组织达到CMM的某个等级来判断该组织的软件过程能力以及其是否有能力达到自己对于此项目的时间进度，资金控制，质量标准等方面对承包商的要求，从而决定是否会放心的将自己的项目交给某一个组织去做。也就是说，通过CMM认证的级别越高，其越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。
CMM在中国的发展
    CMM在中国的发展可以用一句话来形容：忽如一夜春风来。事实上，CMM最初是1999年7月通过一家通过CMM2级评估的合资企业悄然进入中国的，当时国内对CMM的研究与使用寥若晨星。CMM真正火爆起来还是由于2000年6月国务院颁发了《鼓励软件产业和集成电路产业发展的若干政策》（业内人士称之为“18号文件”），该文件的第五章第十七条明确提出“鼓励软件出口型企业通过GB/T19000－ISO9000系列质量保证体系认证和CMM（能力成熟度模型）认证。其认证费用通过中央外贸发展基金适当予以支持。”加上2001年初联想软件率先通过CMM2认证并得到北京市科委的30万奖金，各软件企业围绕CMM的研究、讨论、跃跃欲试、实施等活动紧锣密鼓，开始进入蜜月期。
2 中国需要CMM么？引入CMM认证对国家的好处
    据了解，目前中国大陆的软件企业经CMM评估达到三级的只有2家，达到二级的有５家。而在软件出口居于世界首位的印度，达CMM四级、五级的软件企业已占世界总量的50%至60%。同时，据IDC统计在全球软件市场中，美国占据了2/3。美国和印度软件业为何如此发达？很重要的一个原因就是：无论规模大小，绝大多数企业都按照规范化的方法管理软件研发过程，始终把客户放在首位，把通过某种标准的评估认证放在很重要的位置上。 　　实际上，对于我国软件企业而言，长期以来存在的“小、散、软”的缺陷一直没有得到根本解决。不少软件企业的老总本人就是程序员出身，能够写出漂亮的程序，但是往往个人英雄主义严重，企业整体则缺乏团队精神。与国外相比，中国软件企业的规模偏小，开发能力不足，资金缺乏，人才流失严重对企业造成的影响很大。事实上根据CMM模型的思想，软件产品的质量是靠人才、技术、软件研发过程3个方面共同保障的，其中人才和技术对中国的软件企业来讲往往不是什么大问题，而短板恰恰总是出现在软件研发过程上。这一切都极大地影响了中国软件企业的国际竞争能力。
    随着中国加入WTO，中国软件行业将面临更加激烈的竞争。入世后的中国软件企业要想走出国门，在世界软件业占有一席之地，就必须积极建立完善而标准的研发过程规范并同国际接轨。CMM认证对中国软件企业而言，已经不仅仅是获得一种证书，而成为关系到软件企业能否从此上正规化发展道路、提高国际形象和竞争力、走出国门去国外接单的关键。
    同时，随着国民经济的发展，随着国家各行业信息化工作的推进，尤其是国家重点行业对于软件企业能否按时、保质的提供符合其需求的软件产品和解决方案越来越重视。中国软件企业的研发过程能力的迅速提高，迅速规模化、国际化也是国家能否健康发展，保持长治久安，有效保证国家信息安全的关键。
引入CMM认证能给企业带来什么？
    中国软件企业一个普遍存在的现象是一个技术骨干一走，技术往往就被带走了（尤其是对小企业而言，影响更为明显）。小至项目无法延续，大至企业从此垮台。因此研发过程的规范化、文档化管理成了首要问题。
    实施了CMM是否能够规避此类风险呢？回答是肯定的。CMM的实施将保证一个组织的项目软件研发真正能够做到铁打的营盘流水的兵。同时CMM的实施还有其他妙处。印度的一家软件企业的老总说，在实施CMM后其软件的可靠性提高了20%，成本降低了20%。联想软件在谈实施完CMM2时的收获是讲：收益颇丰。首先是产品质量得到了提高，千行代码错误率减少了，返工次数减少了，研发管理流程得到了梳理和优化，项目管理力度得以加强，软件项目的可视性提高了，预算得到了控制，中高层经理获得了对项目进展情况的更好的了解；客户感受最深的是交货期明显缩短，合作日渐愉快。联想软件面对企业的效益至少增加20%-30%的回报，最终有种找到真正适合软件企业的管理模式的欣喜。
    某著名企业CTO就认为：CMM的意义不仅仅是对软件开发的过程进程管理，最关键的它还是一种高效的管理方法，有助于企业最大程度的降低成本，提高质量和用户满意度，而这正是中国软件业与美国、印度软件业最大的差距之处。
    总之，实施CMM模型（尤其是CMM3级以上的企业）的一般意义为1、软件研发过程文档化，软件工作产品保证了一致性和可追溯性；2、企业内部过程改进制度化，产品开发周期控制能力，质量、成本控制能力，风险控制能力能力，生产效率等明显提高；3、市场竞争透明化、简单化，规范了市场竞争；4、企业国际化能力得到质的提升；
CMM认证实施的难度，同时给实践者会带来什么好处？
    任何过程的实施都离不开人的因素，CMM的实施、认证也一样。绝大多数企业在实施规范化研发过程管理的过程中都会遇到来自员工的强大阻力，大多中途夭折。其实这对于中国那些习惯了自己为中心、不愿文档化、缺乏团队协作精神的软件行业文化来讲是很自然的现象。看来企业文化的特点对CMM的实施的影响还真不容忽视。
    CMM的引入恰如一阵春风，从另一方面来看它对于团队协作精神的强调隐含在模型的字里行间。好的企业文化将使CMM实施事半功倍，而希望塑造团队协作企业文化的企业，CMM的实施将会起到强有力的推动作用。
    CMM模型对于做事能力的重视不亚于具体的工程实施，无论项目经理还是项目成员各角色，完成其角色工作的进入准则之一就是ability。在实施基于CMM模型的过程改进过程中，将提供给员工定制的众多的培训课程，有的是针对性很强的专业课，有的是需要了解的基础课，在此过程中员工的软件工程素质得到了极大的提升，软件工程意识的提升作用于其技术上的积累将产生出更高质的软件精品，这样的企业研发出的产品将给整个团队带来极大的成就感，而个人素质、精神面貌与自信也将不断改善。实施CMM的过程也正是将研发人员点石成金的过程。无疑有过基于CMM的研发规范实践经验的员工将成为组织的骨干，在未来无疑将最受软件企业的青睐。
结束语
    看来不可否认CMM是个好东西，CMM在世界软件行业研发过程标准中也享有很高的评价，而中国在这方面做的还远远不够。尤其在加入WTO全球经济一体化的趋势下，采用CMM标准认证工作作的好坏大有关系到中国软件企业在国际竞争中生死存亡的架势（当然我们在强调认证的同时不会忘记强调实施这个前提）。拿到高等级CMM证书的企业将毋庸置疑会在国际竞争中占据有利地位，这就象给企业的长远发展插上了不折的翅膀。而在此过程中一定要注意员工“人”的作用，加强和致力建设良好的企业文化也是很重要的，同时也需要向员工宣传实施CMM对其个人的益处，化阻力为动力。这样看来 CMM的实施和认证是一件多赢的事情，无论从国家、企业还是个人的角度，都是关系到更好生存和长远发展的大计。

独立与客观—CMM中的软件质量保证实施准则

崔秉正

     软件企业必须通过CMM认证标准的锤炼，这是软件企业逐渐达成的共识。国内众多的软件企业正在围绕CMM进行研究、讨论和实施，可谓跃跃欲试、紧锣密鼓。截止到目前，已经有几家国内软件企业通过了CMM3认证。
    目前，我国大多数软件企业都是中小规模，其软件开发团队通常由几人至数十人组成。在这样的企业如何做好软件质量保证工作，笔者根据自己在联想软件的工作经验谈一些看法。
确立工作目标
    SQA(Software Quality Assurance，软件质量保证)是CMM的一个关键过程域，CMM的每个关键过程域几乎都涉及软件质量的验证，它在软件开发过程中起着非常重要的作用。在CMM中，软件质量保证的目标是为管理者提供当前软件项目进行过程与最终产品的可视性。它的主要工作包括:评审软件工程活动、审计软件产品、将结果通知项目组成员及相关经理。从CMM的框架结构来看，软件质量保证人员的主要工作目标是保证软件过程质量。软件最终产品的质量则是项目经理与质量工程师关心的问题，而不是由软件质量保证人员负责。
    软件质量保证的价值依赖于一些前提，其中最重要的是以下两个：
    首先，软件项目开发过程遵循明确定义好的既定规则，由此所获得的利益远大于为它所付出的代价。先有稳定、明确的用户需求再进行开发，虽然进度可能有所延迟，但与开发后发现不是用户所需要的产品相比，这个代价要小得多。
    其次，在没有独立评价系统的情况下，人们有时候会偏离既定的规则。软件开发人员由于各种各样的原因，总是自觉或不自觉地忽视过程，这时就需要软件质量保证人员来发现问题。
确保人员的独立性
    好的过程质量并不等于好的产品质量，但是糟糕的过程很难带来好的产品质量。如果一个项目按照既定的过程完成开发工作，没有偏离，说明软件质量保证人员尽到了他的职责。
    为了较好地开展软件质量保证工作，软件质量保证人员应该是独立的，与项目经理没有任何行政隶属关系，对他的考核与评价也不应由项目经理做出，同时他也不能承担本项目中除软件质量保证外的其他任何工作，以确保其独立性。
    建议在企业中将软件质量保证机构设立成专门的独立机构。如果企业规模较小，可以由测试人员兼任。在某些企业中，测试人员从属于项目组，此时，软件质量保证人员应该由其他项目组的测试人员担任。
标准的客观性
    软件质量保证的目的是给管理者提供可视性。如果存在主观因素，管理者看到的就不是软件开发过程的真实情况，这一点对软件质量保证工作至关重要。例如，联想公司的软件产品是通过“质量保证检查表”来实现的。针对每个软件工程活动与软件工作产品，都有一个软件质量保证检查表。软件质量保证人员可以根据检查表来判断当前的软件工程活动是否存在偏离以及软件工作产品是否符合要求。软件工程活动是否有所偏离，主要看软件工程活动的进入准则是否达到、输入是否正确、执行任务是否符合要求、结束时是否符合完成准则以及是否具有合乎要求的输出。在审计软件工作产品时，软件质量保证人员主要审计软件产品是否符合规程、标准等要求，一般不考虑技术问题。
    所有软件开发人员都应当接受软件质量保证方面的定向培训，了解软件质量保证的目的、工作方式以及其他相关内容。只有所有的人都认识到软件质量保证工作的意义，这项工作才能很好地开展起来。
几个误区
误区之一：软件质量保证人员对软件产品质量负责。
    软件质量保证人员一般只对软件过程质量负责，如果一个项目按照既定的过程完成了开发工作，没有发生偏离，软件质量保证人员就算尽到了职责，他的价值主要体现在过程质量上而不是最终的软件产品质量上。
误区之二：软件质量保证人员对软件工作产品的审计包括发现其中的技术问题。
    软件质量保证人员对软件工作产品的审计主要是针对过程，例如是否采用过程所规定的模板，所有必要的内容是否都具备等，而不是关注技术问题。
误区之三：软件质量保证人员要负责解决所发现的质量问题。
    软件质量保证的最大作用是发现问题，提供可视性，而不是解决问题。软件质量保证人员发现问题后，必须提交到相关责任人那里，由相关责任人给出解决方法并予以解决。软件质量保证人员只是跟踪问题直至得到解决。如果在相关责任人处无法得到解决，则将问题提交给项目经理。如果仍然无法解决，则提交给高层经理。这样一层层提交，直到问题有了结论。至于最终的结论是解决问题还是暂时搁置问题，由做出决策的人员对此负责。如果要求软件质量保证人员负责解决质量问题，他就可能陷入其中，失去了软件质量保证人员最为宝贵的独立性与客观性。
误区之四：软件质量保证人员是专门监督项目组成员的。
    软件质量保证人员不是监督项目组成员的，他只是从第三方、客观的角度将项目组的情况反映给管理者，让管理者了解项目与规定过程之间存在的偏差。如果软件质量保证人员将自己放到项目组的对立面，专门去找项目组的毛病，那么项目组成员就可能将真实问题隐藏起来，使问题无法得到解决。软件质量保证人员对项目组是有帮助作用的，他要帮助项目组提高开发和管理活动的规范化、标准化，发现问题时，要首先在项目组内解决。 　　总之，要在企业内开展软件质量保证工作，最重要的是让所有员工都认识到，质量不是依赖于某个或某几个高手，而是依赖于整个过程。好的过程是好产品的必备条件，这一点要成为企业文化的一部分，深深扎根于每个员工的心中。

团队精神在CMM中体现

     CMM将管理的方法和技术手段相结合，强调团队精神，强调分工后的协作和过程的相互制约。强调团队精神依靠集体的力量的背后是：共同承担责任、共同分担危险。在CMM实施的同时也创建了一种企业文化--团队精神。
1. 协同作用的的重要性
    企业的战略一般由四个要素组成，即经营范围、资源配置、竞争优势以及协同合作，其中经营范围是指企业从事经营活动的领域；资源配置是指企业过去和目前资源以及技能配置的水平和模式；竞争优势是指在市场上所形成的与竞争对手不同的竞争地位；而协同合作是指企业通过共同的努力达到分力之和大于简单相加的结果。CMM重视集体的力量，利用公共软件的过程和共享开发工具、共享信息、共享硬件等资源使实施CMM的企业能享受合力大于分力之和的协同作用，依靠集体的力量提高开发的质量，共同分担着开发失败的风险。
2. CMM重视企业的开发能力和发展潜力
    也许某个企业在一个不规范的开民方式下也能生产出蜇时性能良好的产品，然而这种产品是非常脆弱的，一旦外界环境稍有变化或发生人员流动，组织将可能无法正常运转。
    CMM的模型是透明的，它将复杂的系统分解成相互独立的模块，每个成员都知道自己的工作范围、工作标准以及工作的标准和发展目标，每个成员在规定的范围内发挥着他的创造力并为企业的成功做出自己的贡献，企业充满了活力。CMM强调在总目标下共同分担风险和责任。规范工作使软件的开发不再那么神秘，而是依靠团队精神以评价模型为依据，脚踏实地走着规范化和整体开发的道路。
3. 需求定义中重视团队精神
    在需求管理的活动标准中规定需求管理是由系统工程组负责。系统工程组是由经理和技术人员组成，他们需要在硬件软件环境以及输入输出要求方面确定需求的内容、建立文档，并对需求定义的质量负责。在系统正式实施过程以前，该需求定义还要经过软件工程组的评审和修改，他们共同发挥作用保证了需求定义具有较高的质量。
4. 测试工作中依靠团队的力量
    软件质量保证组和专家定期进行评审活动共同把握软件的测试质量。软件质量保证组不是一次性地对软件进行测试。在项目开发初期，该小组就要参加计划标准的制定过程，这样有利于以后的验证工作。小组的测试工作不是一次性的短期行为，而应是每隔一段时间周期性地持久地进行评审工作，该小组的负责人要向软件工程组汇报情况，高级管理人员和经理也要定期地参加评审活动。此外，软件质量保证组的工作也要受到独立于该小组的专家的监督。
    综上所述，在软件业寻求可持续发展的道路上，CMM以其重视整体能力和团队精神必将发挥重要的作用，并将产生积极和深远的影响。

CMM是解决软件出口壁垒的有效途径

    加入WTO，将意味着中国经济迈向国际化的进程加快。中国软件业要提升国际竞争力，在世界上占一席之地，解决与国际接轨的问题变得越来越紧迫。而CMM认证无疑是当今国际上最流行的软件企业认证标准，被誉为软件企业参与国际竞争的通行证，中国软件企业必须加紧实施CMM认证，走规范化发展的道路。同时，CMM认证能加速我国软件产业的发展，有助于实施软件产品开发工程、软件园建设工程、软件出口工程和软件人才培养工程这四大工程，有助于软件企业增强实力，提升水平，形成规模。软件工程的改进及进入国际市场都需要长期的努力，运用CMM模型虽不是惟一的解决方案，但不可否认它肯定是中国软件与国际标准和先进水平接轨的快捷之路，是进入国际市场的一座桥梁。
    为顺应国际大趋势，国务院在2000年发布的《鼓励软件产业和集成电路产业发展的若干政策》中，在第17条有“对软件出口型企业CMM认证费用予以适当支持”的内容。
    很显然，小作坊式的生产带给我国软件业一系列“连锁反应”：大量重复制作一些定制的小软件严重浪费资源；大量小规模软件公司的存在使软件业处于一个低层次的运作而陷入恶性循环等。目前，国产软件产品主要集中在中文环境支持系统和应用软件领域，而在操作系统、数据库等利润最丰厚也最需技术实力的软件上却无人问津。因为这些技术复杂度相当高的支撑软件需要大量投入，而国内软件企业大都热衷“二次开发”获取短期利润。
    基于上述原因，我国要实现民族软件产业真正的升级，软件产业必须在产品、市场、资本运作尤其是企业管理方面与国际接轨。
    首先，在产品方面推行软件工业化生产技术和模式十分必要。随着计算机应用领域的不断扩大，信息系统日趋复杂，软件日益显示出其群体特性，要高质高效地开发出大型复杂软件系统已不再是个体或小作坊软件企业所能完成的工作。
    其次，改革传统的计算机教育体系，以适应软件开发新形势。当前中国高等院校计算机专业课程的设计中，要普及并开设软件管理工程这样的课程。
    第三，引入国际通行的ＣＭＭ认证，同时对现有国内软件资源进行大规模的整合尤为必要。作为目前国际上最实用的软件生产过程标准和软件企业成熟度等级认证标准，ＣＭＭ能帮助软件企业改进和优化管理，实现软件生产工程化。
    目前中国的软件开发能力正在走向成熟，但是和美国、印度相比仍然存在着较大的差距。美国、印度等有自己的一套质量管理控制体系，很规范，很严格，我们的软件企业应借鉴微软公司独特的质量管理控制体系的开发经验，发展壮大我们的民族软件产业。
    2000年，中国软件产业总额为71.7亿美元（其中软件出口额为4亿美元），与国外软件业相比还有一定的差距，见表1所示。
     国外软件业发达，很重要的一个原因就是：无论规模大小，绝大多数企业都按照规范化的工作方法管理软件循环过程，始终把最终用户放在软件产品供应优化和质量控制的中心，把达到认证标准放在很重要的位置上。
    尝试进入国际软件市场的中国企业，越来越深刻地认识到SW-CMM(软件生产能力成熟度模型：Capability Maturity Model for Software)对于开拓海外市场的重要作用，但目前的事实是：很多企业虽然知道CMM认证，但对于如何基于CMM快速实施软件过程改进，还存在很多疑虑。而这一点正是困惑软件企业的决策者、领导者、实施者，阻碍中国软件企业进入国际市场的一个瓶颈。因此，由于CMM是国际公认的软件产业评估标准，通过CMM的认证对于面向软件出口的软件开发机构尤其重要。通过CMM二级或三级认证的软件开发机构，在软件产业界将拥有较高的知名度，与其他软件开发机构的竞争中在产品宣传、软件订单取得方面将拥有较大的优势。
    CMM一共有5级，18个关键过程域（KPA），52个目标，300多个关键实践。据美国卡内基.梅隆大学软件工程研究所（SEI：Software Engineering Institute）统计，至2001年6月底，CMM的认证情况如表2所示。
     在通过CMM 4级和5级的企业中，除澳大利亚和以色列各拥有一家4级企业、中国1家5级企业外，其余都是美国和印度的企业。摩托罗拉中国软件中心成为第39家通过5级认证的企业。
    在全球的软件开发市场中，印度软件的出口规模、质量和成本三项综合指数均居世界首位。据印度软件行业协会统计，1990年印度印度软件出口只有5000万美元，1995年达到2亿美元，1997年达到18.13亿美元，1998年达到27.5亿美元，1999年达到39亿美元，2000年达到60亿美元，已占印度全部出口总额的10.5%。
    严格和完善的项目管理和质量保障体系的建立，使印度软件产业的按时、按质和按价交货能力有了大幅度的提高，大大增强了印度软件产业的国际市场竞争力。印度自开始发掘软件产业潜力、开拓国际市场以来，就一直把软件产品和软件服务的质量看成是企业的生命线。
    仅仅以产值作为衡量软件业是否发展良好是不全面的，软件企业的内功是否过硬、软件品质是否得到保证、软件企业是否确立了工业化意识而具有持续竞争力，更应成为评价我国软件产业发展的标准，也是解决我国软件出口壁垒的有效途径。

软件业发展的新方向——外包

李华辉

     中国软件的新出路是什么？这个问题曾经有很多人问过我，经过多年在软件开发界的打滚，加上我的切身体会，我认为当务之急是要在国际上开拓自己的生存发展空间，软件外包出口正是这样的一条路。
    如同其它的所有商品一样，出口是一条必经之路。如果我们的软件公司或者工程队可以取得外国的软件项目并出色完成，那么我们就可以大大的扩大我们的软件在外国的知名度。更重要的是这代表着我们的软件水平已经达到了一个新的台阶，我们的整体的软件开发水平也必然大大提高，并进一步带动中国整个IT行业的发展，同时也会促进传统产业的发展和提高我们国家的整体科学技术水平。另外一个很重要的利益就是可以提高我们出口产品的科技含量和利润率，增加我国的外汇收入。当然不可否认的是仅仅依靠海外的中国软件外包还是不足够的，不过其作用却是不容忽视的，因为它可以起到一个带头作用，从整体上推动我国软件水平。所以我们可以相信软件外包在我国软件产业里面的作用会越来越明显。
    虽然我国软件市场在近些年来的确扩大了不少，不过整体上来说我国的国内市场还是比较狭窄的。这主要是因为我们的科学技术水平现在来说还是比较低。虽然我国有很多企业，可是真正需要软件的企业却不多，除了一些在发达地区的一些高科技含量或者是一些管理先进的企业，还有我国的一些关系国计民生的重要企业例如邮电、银行、能源等企业，别的企业使用电脑的数量还是很少，尤其是很多亏本的国有企业，至于落后地区的企业就更加不用说了。这个现状不是一朝一夕就可以改变的，起码在短期内不会改变。而最近几年来我国的软件公司却像雨后春笋一样涌现出来。如果我们不向海外发展的话，仅仅靠国内的市场是远远满足不了的。另外从经济学原理来说，扩大出口对国家经济的发展是可以起到重大的推动作用的。就拿二战后的日本和德国来说，其可以从二战后完全崩溃的经济废墟里面崛起和这两个国家重视对外贸易是不可分的。
    那么海外的市场有多大呢？根据一份有权威的报导，在1999年这一年里面，仅仅是美国就提供了约400亿美元的软件外包业务，而且这个市场的的增长率是十分惊人的。估计在2000年，美国可以提供大约600亿的软件外包。另外，我们也可以通过亚洲的软件大国印度的软件创汇额上来说明这个市场有多大。有消息表明，印度印度软件业收益2001年3月将达到86亿美元，而软件出口预期也可达到63亿美元；而且印度政府预计在2005年前后软件出口有可能会超过1000亿美元；另外，软件外包预计到2008年将会为印度人提供220万个新的工作机会，而吸引投资规模将会达到50亿美元。另外，根据另外一份权威报导，即使我们只承包美国每一年每年软件国外外包业务中的2～3%时，我们国家队就可以使自己跻身软件出口大国的行列了。
    另外，软件向外包发展并不是只有经济效益的。这样做的其中一个很重要的原因是可以培养出一大批出色的人才。这些人才是素质全面的人才，包括经营管理、财务管理、市场调查、项目研究和具有优秀外语水平的公关人员。这些人才是完全可以对外沟通的，通过这些人才，我们可以和外国最先进的软件公司接触，随时随地地向这些优秀的世界领先的软件公司学习。而且通过和国外的公司的合作，这些人才也可以积累开发公司和项目管理经验，并具备和客户协调谈判的能力。
    软件外包当然比较适合一些大型的软件公司，例如中软只是实施了一个“面向国际市场发展，走出去，拿回来，产品出口与劳务出口并举、借船出海”的策略，扩大软件出口，这样就给自己赚得了巨大的利润。再说东大阿尔派之起家的原因不就是给日本人搞了一个GIS系统吗？现在已经是混得有声有色啦，有哪一个软件界人士不知道。不过，外包也不仅仅只是这些大型企业的专利，其实现在也有很多的小型软件企业在做外包。这些小型企业的地域范围相对来说比较窄，只是限于一些沿海开放城市和另外一些软件业比较发达的地区，而且这些公司都有一个特点，就是他们的管理层一般都有曾经在外留学的人士。而且这些公司一般在海外都有分部，海外分部一般都负责在国外接生意，而因为在我国现在的软件人员资源相对廉价，所以他们比较愿意把开发基地设立在我国。只要他们一旦在国外接到订单，他们就马上在国内开始工作。
    另外，软件业现在最重要的一个因素就是人，人才一向都是不容忽视的。这些发展外包的软件企业的一个比较有特色的特点就是有相当数量的海外留学生。例如说易得国际软件公司公司的创始人孙伟就是美国佛罗里达一所大学的教授。在外包这个商业过程中，不可否认的是海外留学生起到了举足轻重的作用。随着网络的一直降温，软件行业这个有发展前景的行业可能还会吸引更多的留学生投入到软件外包这个行业中来。因为软件外包行业是一个对外贸要求很高的，必须具备很好的外语水平，只有这样才可以和国外企业做到好的沟通，而也只有这样才可以收到海外的软件订单。而现在从事软件行业的人员的外语水平有限却是一个限制他们进一步发展的主要因素。而印度在这方面就比较有优势，他们软件业人员的水平都相对比较高，而且他们在国外主修程序的留学生的数量也不少。所以我们要发展外包，现在来说留学生就成为举足轻重的了。
    现在还有一个比较严重的问题是中国的软件业现在还没有和国际接轨，例如中国软件企业通过CMM体系认证的还很少。而且我想企业经营者还不知道CMM是怎么回事的还为数不少。软件外包业务上的CMM（能力成熟度模型）体系认证已经把众多试图走向国际市场的国内软件企业挡在了门外，因为美国通常不发包给CMM3级以下的企业。
    现在还有一个问题就是软件业人员对软件业的发展了解奇差。他们的目光相对狭窄，很多人根本连软件外包为何物都没有听说过，就更不用说软件外包的运作过程了。这也有很多原因，例如是一些软件从业员不注意了解国外软件业的发展情况。还有就是因为他们把所有的时间都用在开发国内市场上面了，不过问题是现在国内市场也不是那么景气，所以如果他们还不想别的方法，可能就很快在激烈的竞争中被淘汰了。也许有些人觉得这样只是即所谓为别人打工。而且这只是一条让人自豪不起来的漫漫长路，起初只是赚个苦力钱，品牌和核心技术更谈不上。不过只要细心一想，就觉得这种想法未免有点儿太幼稚了，以前我们的经济特区不也只是从“三来一补”开始做起，看现在的广东的那些城市都已经成为经济大市了，例如前几年的深圳东莞只是给国外企业加工一些非常简单的硬件而已，而现在仅仅在东莞，除了主板和CPU之外，别的所有的硬件都可以在当地生产了，这不可以说不是其“三来一补”所带来的。而印度开始的时候也只是给人家做一些简单的东西，主要是按照别人的设计编写程序。而现在他们已经不仅仅是这么简单了，他们已经可以做整个系统软件的开发了，有些甚至还包括给客户分析需求。现在看来，却发现印度的软件外包已经今非昔比了。
    实际上，软件外包也可以促进软件企业的管理，而不仅仅是给他们赠钱那么简单。因为在做一个软件外包的时候，仅仅依靠开发上的技术是远远不够的，因为软件外包不光是关系到编程，它还需要一个争取客户、市场调查、管理方面等的配合。所以要发展外包，公司就需要很多例如市场调查、财务和管理方面的人才。
    总的上来说，搞软件出口软件外包不仅仅只是赠钱那么简单，更重要的是通过其来学习国外先进的管理经验。只有通过不断的和国外交流，不断地向他们学习先进的技术，这样我们才可以追得上国际趁势。企业通过软件外包，不但会提高企业总的竞争力，而且也可以培养出一大批优秀的人才，跟上软件的国际发展潮流。只有这样，我们的软件产业才可以跃上一个新的台阶，使我国成为21世纪的软件大国。

CMM与软件外包管理

杨涛

    “任何企业中仅做后台支持而不创造营业额的工作都应该外包出去，任何不提供向高级发展机会的活动与业务也应该采取外包形式。企业的最终目的不外乎是最优化地利用已有的生产、管理与财务资源。”
这是管理学大师彼得·德鲁克的预言，同时也反映了现代企业运作的一条金科玉律——“利润最大化，成本最小化”。 软件业是一个高速变化、新技术层出不穷的行业，同时又是人力资源、人力成本相对较高的行业，更需要采用外包服务形式来合理地配置资源，最大限度地从分工合作、资源共享中获益。综观软件产业的现状，发达国家的软件外包已经成为软件企业发展的必要手段，国际间的软件外包与转包业已经日渐成熟。因此，中国软件产业要发展，就必须大力发展软件外包服务，做到专业分工明确、协作配合良好，形成一个完整的软件产业链。
软件外包在CMM中的体现
    CMM2中的“软件子合同管理”KPA涉及了软件外包管理问题，它规定了企业应如何管理软件开发业务和软件开发子合同。但是，软件外包管理实际上涵盖了软件生命周期中的各个过程，任何一个软件外包过程都会涉及到需求管理、软件计划、质量管理、项目追踪、配置管理等内容，因此，不能孤立地看待CMM的软件子合同管理，而应该将其视为能将其他软件开发过程从公司内部部分或全部延伸到公司外部的管理规范与管理技术。通过软件子合同管理过程的实施，软件开发机构能够有效地管理与控制他们的业务分包过程。
    实际上，SEI还开发了另一个模型——SA-CMM（Software Acquisition Capability Maturity Model，软件采办能力成熟度模型），它是为需要采购或分包软件系统的公司或组织设计的能力成熟度模型，用来评估、改善或控制软件系统的获取过程。软件采办能力成熟度模型也分为5级：初始级、可重复级、已定义级、定量管理级、优化级。与CMM 不同的是，SA-CMM关注的是软件购买者的软件能力成熟度;而CMM关注的是软件系统承包者或开发商的软件能力成熟度。软件采办能力成熟度模型适用于软件生命周期的各个阶段，包括维护过程。
    因此，在CMM模型体系中，SA-CMM是作为管理软件的外包或分包过程的模型，需要评估或改善软件采办或分包过程的公司或组织可以按照SA-CMM模型去调整自己的组织管理能力和操作过程。由于软件采办能力成熟度模型是1996年才公布的，其影响还很有限，真正成功地实施了SA-CMM的公司或组织也比较少，因此，国内企业要想按照SA-CMM模型改善软件外包管理过程会遇到一定程度的困难。
实施软件外包管理
    从CMM的“软件子合同管理”KPA开始实施软件外包管理是比较好的办法。CMM模型定义了软件子合同管理要达到的目标、实施时必须履行的承诺和需要具备的能力，定义了进行软件子合同管理应该进行的活动。但是，就像SEI对软件能力成熟度模型其他KPA的描述一样，只是给出了“应该做什么”，而对“如何做”这一关键问题并没有给出相应的指导，很多想实施软件外包管理的企业和组织都感到无从下手。我们参考了一些国外的资料，结合具体的实践经验，提出了一个框架性的描述，它包括以下13个方面的具体活动：
    ◆ 按照文档化的规范定义和规划子合同；
    ◆ 按照文档化的规范，根据承包商完成工作的能力选择承包商；
    ◆ 把与承包商签署的协议作为管理子合同的基础;
    ◆ 评审和批准文档化的承包商软件开发计划;
    ◆ 以软件开发计划为标准,跟踪软件开发过程;
    ◆ 按照文档化的规范，对承包商的工作陈述、子合同条款、条件以及其他约定进行更改；
    ◆ 双方的管理者一起执行定期的状态或协调评审;
    ◆ 承包商参与定期技术评审和交流；
    ◆ 按照文档化的规范在所选择的里程碑处进行正式评审，评价承包商的软件工程完成情况与结果；
    ◆ 软件质量保证组按照文档化的规范监控承包商的软件质量保证活动；
    ◆ 按照文档化的规范进行验收测试，定期评价承包商的能力。
    企业按照这些步骤，就可以初步开展软件外包管理活动。

软件企业需要什么样的CMM服务？

北京软件过程改进网SPIN

     CMM的应用已经从知识导入期进入研究和实施期，为了深入了解企业的实际状况和真实需求，由北京软件过程改进网（北京SPIN）组织了这次“CMM用户市场状况调查”，调查以网上发布调查表的方式进行，调查过程得到了软件工程专家网（www.51cmm.com）的大力协助。
    本次调查，主要收集和统计了实施中遇到的主要问题，特别是对于工具的使用做了较为全面的了解。 样本情况介绍 　　本次调查历时25天，收到反馈210份，有效样本数203份。调查涉及全国各地的软件企业。被调查者中：企业高层主管、项目经理、职能经理等管理人员占51.4%，软件工程师占35.7%，企业过程改进人员占12.9%。

  被调查者所在的企业有45.3%通过了ISO9000认证，在通过ISO9000的企业中，打算进一步实施CMM的占58.3%。有44.7%的企业正在自我研究的基础上部分的使用CMM，打算进行正式引进和实施的则高达57.1%。
    应该注意的是，这个数字与前面提到的"通过ISO9000仍然要实施CMM的企业"比例数非常接近，表明ISO9000没有能够很好满足软件企业对于管理的需求，也表明ISO9000的效果没有能够打击企业以及过程改进人员对于其它制度化体系的渴求。
    以下的统计分析中，"制度化体系"指ISO9000、CMM等制度化管理体系。
实施制度化体系存在的问题
    对于实施制度化遇到的问题的调查反映出，以下七个方面当前最为突出：
  在上图中，横轴表示上述问题的编号
    1）体系文件的制定没有结合企业的实际情况，没有解决实际问题
    2）体系实施带来大量的额外烦琐的管理工作量，又缺乏合适的管理工具
    3）领导支持的力度不够
    4）实施体系时，没有注意改造企业文化中与制度化不兼容的部分，结果发生文化冲突
    5）基本软件工程不到位，包括由于软件人才匮乏，人才结构不合理造成的种种问题
    6）人员素质，各级管理人员普遍缺乏管理知识，不知道怎么管理
    7）由于ISO9000在中国软件业的实施有许多不成功，打击了人们对CMM的信心 　　调查表明，"与实际情况的结合"、"事务性管理工作量"、"文化冲突"、"基本软件工程"、"基本管理素质"是七个问题中尤为突出的五项。"基本管理素质"和"基本软件工程"两项以接近60%的被选率居于前列。
对上述七个问题的分析如下：
问题一：理论与实际的有效结合
    CMM的作者之一Judy Bamberger指出："这组指南仅仅是--指南--而不是要求，或是一份"必须做"的行动的清单；这个指南是准备好了应被解释、被裁剪和根据每一特定企业的文化与环境被加以利用的。"
    实践一再的证明，西方理论体系应用于中国实践，照抄照搬往往导致失败。特别是底层实践和实施方法论有着强烈的本土文化取向。对症下药还是生搬硬套这其实反映的是顾问公司的服务水平和服务意识？在图一中，实施过制度化的企业样本中，选择问题一的高达58%，高于总体样本的40%，这表明企业对既往的制度化实施的满意度还很低，企业从中得到的提高还很不够。
    要结合就首先必须了解企业，这一点对顾问师的背景和素质提出了要求；其次，要重诊断，轻评估，本文后面有数据显示，不同企业"痛处"不同，这要求体系的实施要有重点，有针对性。
问题二：事务性管理工作量
    各类制度化体系大抵都要求按照预定流程做事，多做记录，收集和分析数据，这些工作必然增加工作量，这是些高级人员不愿意做，低级人员还做不了的事务性管理工作。事实上，一些企业不自觉的采取了各种各样的解决办法，比如清华紫光下属某公司设立了项目经理助理职位，帮助项目经理分担计划监控以及计划维护、数据统计等工作，联想神州数码的某研发部门设立了CMS（配置管理秘书）的职位分担变更管理、配置审计、数据统计等工作。当然，个别企业在使用自我研发工具。良好工具成为影响着CMM能不能做深入，CMM能不能坚持的重要因素。
问题三：领导真正支持
    以前实施ISO9000的顾问公司就总是强调这一点，"实施ISO9000是一把手工程"。为什么总是强调这一点呢，就是因为制度化实施并不是看起来那么简单，表面上就是一堆文档，其实更多的工作在文档以外，难度也在文档以外。文档之类的东西只是制度化实施的技术的、硬性的方面，还有软性的因素。很多的事情最后落实的"人"这个因素上：观念的转变、习惯的改变、利益的纠葛。这些离开高层领导的支持、推动是行不通的。
领导支持不是喊喊口号，出点钱的事。需要尽可能的亲身参与、深入学习和研究乃至以身作则。
问题四：文化冲突
    调查数据显示，文化冲突也是一个很突出的问题。1995年SEI发表的一份技术报告（CMU/SEI-95-TR-009）指出："企业文化是否认识到过程改进的必要性，是持欢迎的态度还是抗拒的态度，是开展过程改进的先决条件"。可见，文化的冲突是中外普遍存在的问题。
    令人奇怪的是，虽然这个问题被频繁的提及，但是国内很少有人去研究和实践这个问题。这似乎显示着国内顾问公司的业务成熟度处在比较低的层级上，还是忙于解决实施的技术问题，而无暇顾及实施方法论等软性因素。
    组织文化并不是一个新的话题，在许多领域都存在着不同程度的组织文化学术研究和实践。比如，跨国公司管理、跨文化管理、变革管理、购并与重组等。虽然还存在着争论，但是大多数学者同意组织文化是可以改变的。所以，研究和借鉴其它领域的成功经验似乎是一个捷径。 　　ISO9000在传统行业的应用（比如电子制造业）应该说是比较成功的。制度化体系在外企（里面可能全是中国人）的普遍成功应用也提供了大量文化可塑的案例，这些都证明通过努力，制度化与我们的本土文化是可以兼容的。
问题五：基本软件工程缺乏
    刊登在《PMT评论》总第二期上的一篇短文写到：“SW-CMM将软件企业的能力成熟度分为5级，即初始级、再现级、已定义级、受管理级和持续优化级。一般理解，只要企业从事软件开发和维护业务，企业就处于第一级，即初始级。因此，CMM2级就自然而然成为软件企业第一步的奋斗目标”，“而事实上，很多软件企业连最基本的软件工程活动都不健全，软件开发就是编写代码。这样的软件企业可能距离CMM1级还有距离，姑且称为CMM Level 0。对于处于CMM1级的企业来说，首要的问题是生产活动的管理问题，而CMM0级的企业，首要的问题是学会如何生产，也就是有哪些必要的工程活动和工序。打个比方，CMM1级的企业已经有了汽车生产线，而CMM0级的企业连完整的生产线还没有。CMM0级的企业要跨出的第一步，是将需求分析、系统设计和测试这三项工程活动从coding中分离出来，然后要填补其他的工程活动，比如构建（build）、集成（integration）、验证（V&V）和发布（release）等等。，调查的结果显示，基本软件工程的缺乏的问题位居七大问题中之首。”
    而笔者认为，搭建基本软件工程首先要解决的是人力资源问题。我们的软件人力资源市场问题有两个，一是总量供应不足，二是结构失衡。最缺的是两头，高端的系统分析师、低端的编码人员。尤其缺少大量低端编码人员。只有大批软件蓝领的出现，才可能解放"全程程序员"，使得他们有机会向高端发展。软件工程化框架或者说软件生产线基本因素是两个，工程化理论和工程化载体（人），当人力资源市场能够以合理的结构大量提供软件技术人才时，软件开发的工程化框架才有可能搭建。
    当然人力资源问题已经得到有识之士的共识，状况正在好转。媒体报道，北京年内要建三所软件学院，其中北工大软件工程学院首批软件蓝领已经毕业。此外，北大青鸟、天大天财等企业都在与有关的印度公司合作开展IT人才职业教育方面的业务。高端人才方面，教育部高等学校计算机科学与技术教学指导委员会主任李未教授透露，今年开始，教育部将建立30所软件应用技术学院，每年增加培养1.5万名软件方面的硕士生。
问题六：基础管理的缺乏
    基础管理特别是项目管理的缺乏，造成了CMM的承载过重的情况，指望在CMM的引入中解决所有的不足，无疑给CMM实施大大增加了压力。因为，CMM L2虽然讲的是项目管理，但是它终究不是项目管理。比如，PMBOK架构下的人力资源管理、成本管理、项目评估、项目后评价等在CMM中的体现都很弱。项目管理本身也是一套成系统的知识体系。
在当前这种现状下，结合实施，从而弥补组织在项目管理方面的欠缺，可能是一种可行的办法。 问题七：ISO9000的影响
    ISO9000的影响虽然已经不是主要问题，但是他也确实存在着。它的危害主要是会影响人们的信心，尤其是遇到困难和挫折时。这要求实施者在规划CMM项目时，就开始规划CMM项目的效果验证。注意收集实施前、中、后的过程性能数据。尽可能找出过程性能改善的证据，以增强人们持续改进的信心。
开发过程不规范的原因
    软件开发管理的不足只是因为没有实施这样那样的体系吗？通过分别统计实施过制度化体系和没实施过制度化体系的样本，可以发现对下列两个选项的选择率存在极大差异。
    数据说明，没有实施过制度化体系的企业往往把希望寄托于引入这样那样的体系，以为此体系与彼体系有什么优劣不同。而实施过某种体系的企业就认识到，解决开发过程管理的问题，不在于引入什么样的制度化体系，而是如何有效实施制度化体系。他们认识到最重要的是体系实施的"有效性"。
工具使用状况
    对工具的使用率统计如下：
  使用率最高的四种工具排序：MS Project 、Visual Source Safe、Rose、 ClearCase
    从工具类型看最高使用率的四类工具排序：配置管理类、项目管理、产品工程、变更管理。其中，MS Project 和Visual Source Safe两种被绝大部分的企业选用的原因，与其简便易用不无关系。国内软件企业97%属于中小企业，功能齐全、价格高昂的高端工具可能不是他们的理想选择。
哪些关键过程域最需要使用工具
    横轴编号如下：
    1需求管理 2项目计划 3项目跟踪和监控 4配置管理 5软件质量保证 6同行评审 7培训 8软件产品工程 9 其它 　　如图可见，需求管理、计划管理和产品工程被列入第一需求的比例最高，但是三者之的统计差距不明显，表明不同企业之间的差异较大，统计后趋向平均。列入第二需求比例最高的是计划跟踪和监控。列入第三需求比例最高的是质量保证。总体次序是：需求管理、项目计划、产品工程、项目跟踪和监控、质量保证、配置管理、培训、同行评审
工具的价格和购买意向
    在问及用户对基于CMM L2的工具的可接受的价位时，有如下结果： 　　可见，这样的一个工具的心理价位应该低于20万元。
    在问到近期有无购买此类工具的意向时，有32.5%的企业给予了肯定的回答。
过程改进从业人员对交流的渴求
    当问到是否希望加入软件过程改进网（SPIN）这样的组织，被调查者无一例外给予了肯定的回答。表明从业人员对于交流的强烈需求。据不完全调查，美国有大约50个SPIN组织，印度有11个SPIN组织。相形之下，我们的民间性质的、非赢利性、学术性的的交流组织还很不够。
小 结
    本次调查的结论如下：
    1． 软件企业对于CMM的需求相当旺盛。有44.7%的企业目前正在局部引进和使用CMM，57.1%的企业有正规实施CMM的意向（但不一定是评估）。
    2． 当前制度化体系实施碰到的共性问题有七个，依次排序为：基本软件工程缺乏问题、基础管理的缺乏问题、理论与实际的有效结合问题、事务性管理工作量、文化冲突问题、领导支持问题、ISO9000的影响问题。
    3． 既往制度化体系，特别是ISO9000的实施，没有能够满足企业对于基础管理的需要，体系实施的有效性有待提高。
    4． 企业的工具使用率偏低，受欢迎的是一些简便易用、价格适宜的工具。
    5． 企业认为最需要工具进行管理的方面依次排序是：需求管理、项目计划、产品工程、项目跟踪和监控、质量保证、配置管理、培训、同行评审。基于CMML2的工具的心理价位是不高于20万元。
    6． 过程改进相关人员对于交流的需求是异常迫切的， 软件过程改进网（SPIN）这样的民间组织受到大家的普遍欢迎。

循序渐进—CMM实施工程案例

于小葆

    CMM实施从何处着手？SEI的IDEAL（初始化、诊断、确定、行动、推进）被认为是一个较好的方法，但国内企业在采用IDEAL方法的过程中还存在很多问题。
差距与不足
    目前，国内企业实施CMM激励条件的外部因素大于内部因素，企业的起步目标就是CMM2级，一旦进入IDEAL模型，却发现企业面临巨大的工作量，加上缺乏这方面的专门人才和非常薄弱的过程管理基础，使企业面临进退两难的境地。而国外一些企业注重过程管理的改进已经有10年、20年的历史了，其CMM激励条件的内部因素较大，企业通常是根据自己的实际需求不断地改进过程管理。
    当然，一开始就把目标定为CMM2级并没有什么错误，但面临一种文化改变时，应该从何做起？与国外企业相比，国内软件企业在基本软件工程上存在一定的差距，通过CMM实施可以不断改进，但也势必会使CMM实施的工作量成倍增加。那么，国内企业基本软件工程的差距何在？如果仔细分析，我们不难发现，国内软件企业的基本软件工程存在的问题主要体现在以下方面：
    缺乏较好的文档编制规范和模板定义；
    缺乏较好的设计和编程规范以及较好的模板定义；
    缺乏较好的基线控制；
    缺乏较好的工作产品转化规范；
    缺乏较好的版本管理。
    以上工作除工作产品模板定义和工作产品转化具有较强的技术特性之外，其他都属于基本软件工程范畴。工作产品模板定义和工作产品转化的好坏是影响CMM2级实施工作量的主要因素，而工作量的大小将在很大程度上影响企业在实施过程中的信心。
实施样本
    根据国内企业的实际情况，CMM实施可以考虑从基本的软件配置管理着手，以便在CMM实施过程的早期完善基本软件工程、工作产品模板定义和工作产品转化的规范。具体实施时可采用以下步骤：
    选择一个较小的项目，仅把软件生命周期中的主要工作产品置于配置管理之下；
    各工作产品开发小组尽可能采用背靠背方式完成该项目；
    SCCB详细记录所有更改；
    项目结束后，由项目经理主持，认真分析产生更改的根原因。
    一般来说，主要的原因有以下几条：
    需求规格说明书写得不好或不全；
    工作产品模板定义得不好；
    缺乏规范的工作产品转化定义。
    改进的方法之一是采取如下步骤：首先研究编程语言的表示方式，然后确定上一级工作产品的表示方式（模板定义），同时研究并确定从这级工作产品到编程语言的转化规范，最后采用同样的方法一直倒推到需求规格说明书。
    该项目的SCCB记录应该对以上改进提供大量较客观的原因供相关人员分析并确定需要改进的内容。项目完成后，企业应该在软件配置管理这个关键过程域方面建立了基础，同时需求管理也有了一个较好的基础。在此基础上开展项目计划、跟踪和质量保证工作将会使企业感到工作更为实在，同时，它也将提高实施人员的兴趣和信心。采用这种方法是为达到如下目的打基础：
    为CMM的实施打下较好的工程基础；
    减少CMM实施的工作量；
    缩短实施CMM 2级的周期；
    进一步提高软件产品的质量；
    CMM实施是循序渐进的；
    避免遭遇文化改变的明显冲突；
    树立企业人员实施CMM的信心；
    让企业看到每个阶段的成果；
    CMM实施最终真正改进企业的过程管理。
    如果这个项目实施得好，达到前4个目的是毫无问题的。第5个目标所讲的循序渐进并非指一个一个关键过程域的实施，事实上也做不到。
    以较好地确定工作产品模板定义和完成工作产品转化规范为目的的软件配置管理事实上也涉及到CMM2级的其他关键过程域。在项目开始时，首先要制定项目计划，项目实施过程中还要进行项目跟踪、监督和质量保证工作。项目结束后，对需求规格说明书模板进行改进，为需求管理打下基础。就这个项目，不应该对这些关键过程域按CMM进行全面地管理，否则过程的改进不仅将失去阶段重点，而且也消化不了。第6个目的是避免遭遇文化改变的冲突，如果把工作限制在一个小范围进行，而且又不明显改变原来的做事方式，就可避免文化明显改变的冲突。当项目结束后，通过总结分析，大家认可改进的内容，就可以使做事方式和文化的改变进行得比较自然。通过成功地实施该项目，企业里的两部分人将对实施CMM树立信心：其一是参与该项目的人员；其二是管理层人员。
    曾经有多位国内软件企业负责人问我：“你如何能在最短的时间里让我们拿到CMM 2级证书？”对此我是无言以对。其实，单纯追求通过CMM评估不应该是企业的终极目标，改进企业的软件过程管理才是企业真正应该追求的。

CMM的宜与不宜

（转载自计算机世界网）

    郑人杰教授是国内CMM领域的权威专家，他近日在赛柏公司举办的有关CMM研讨会上，针对目前软件企业的CMM热，提醒企业实施CMM不要一窝风，一定要根据自己的实际情况，从解决软件过程问题的需求出发。他同时指出，并不是任何企业都有必要实施CMM。 什么企业适合全面实施CMM？
    1．外向型的，特别是向北美市场出口的企业。这些企业都是市场导向明显的企业，应该全面实施CMM。
    2．为解决问题而实施CMM。企业在自己的业务实践中，确确实实感觉到需要改进自己的过程，而且自己有一些教训，这些教训很深刻。在这种情况下，企业领导者要下决心，实施CMM，从根本上解决存在的问题。
    3．企业需要有一定的实力。实施CMM的企业少的要花费几十万元，多的要花近百万元，而且需要企业下大工夫，从这个角度上看实施CMM是昂贵的。有些企业如果处于初创时期，资金还不雄厚，还有许多火烧眉毛的事情，最好不要着急全面实施CMM，可以自己先按CMM实施，不要马上请人评估。
什么企业不适合实施CMM？
    1．初创的小企业。一个企业还没建立多久，经济效益还不理想，当前的主要问题还是怎么样立足，怎么样扭亏。这样的情况下，企业不要着急做CMM，此时的CMM对这样的企业来说可能是奢侈品。
    2．企业的管理还处于一个十分薄弱的环节。实施CMM需要一定的管理基础，如果企业的内部管理混乱，连规章制度都不健全，质量管理还无从谈起，经常发生内战，这样的企业如果头脑一热盲目实施CMM，那肯定会是一场灾难。
    3．ISO9000认证没有真正成功的企业。如果企业ISO9000认证没有成功，就不要着急实施CMM，可以先做好ISO9000。现在许多企业很看重CMM，似乎ISO9000已经不重要。其实，ISO9000还是不错的，只是被一些“歪嘴的和尚念歪了经”，现在ISO9000出了2000版，改得比较好，总结得比较精炼。如果企业认认真真严格进行ISO9000认证的话，肯定会在质量管理上有大的收获的。
    4．准备不充分的企业。如果一个企业没有真正解决为什么要做CMM的问题，企业领导者还没有真正下决心，企业还没有做好充分的思想准备，这样的企业不要急于实施CMM。

实施CMM是一条没有终点的路

杨小薇/(IT经理世界)

    在大多数软件企业看来，CMM只是一张通往海外的通行证，或是一张让客户放心购买软件期货产品的质量保证书。但实际上，开始实施CMM只是踏上不断优化自己、修正自己的一个起点；起点延伸处是一条没有终点的路；路上充满了引领企业“更上一层楼”的路标。
    胡大庆是摩托罗拉中国公司大中华区网络方案部研究开发中心的经理，每当他面试前来应聘的人，都会问对方：“为什么想来我们研发中心？”近来，有一个回答，他经常听到――“因为你们CMM做得好，我希望能在这儿得到这方面的学习空间。”胡大庆所在的研发中心已于2000年12月通过了CMM5级的认证。据介绍，在我国境内目前只有两家企业通过了CMM5级认证，另外一家是摩托罗拉中国公司的软件中心。这样的稀缺资源难怪让想了解、学习CMM的人趋之若鹜。
    CMM软件工业化的大纲CMM(Capability Maturity Model For Software，软件能力成熟度模型)是美国卡内基梅隆大学软件工程研究所(CMU SEI)应美国联邦政府的要求开发的一种用于评价软件承包商能力并帮助其改善质量的方法。1991年，CMM1.0版本面世，1992年，他们又推出了CMM 1.1版本。CMM提供了一个评估软件开发过程的管理以及工程能力的标准，是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度认证标准。CMM标准共分为五个级别：初始级、可重复级、定义级、管理级和优化级，从低到高，标志着软件生产的计划度越来越高、生产周期越来越短、成本也越来越低。业内人士认为，“CMM既是软件企业走向国际市场的通行证，也是用来衡量类似期房的软件质量的保证书。”
    除此之外，CMM还是一个软件生产工业化的产物与检验标准，是软件工程化的核心环节。“CMM为软件企业进入工业时代制定了一个大纲。”于是，一些以往就专注于提供软件工程开发解决方案的软件公司就以这个“大纲”为标准，帮助软件企业克服提升质量过程中的各种矛盾。瑞理(Rational,Nasdaq的100个指标股之一)软件就是这样一家提供软件工程化工具的公司，摩托罗拉网络研发中心从CMM4就开始使用它的软件。
    在瑞理耳濡目染了许多软件工程化的理论，使瑞理中国公司的技术总监吴穹对CMM有着更深一步的认识。“它告诉企业怎么做软件工程，有哪些要求，如何检验，每个阶段的重点是什么、应该做什么。这个框架为软件工程化提供了一个循序渐进的模式，并不是将这个过程简化为一步――从0到1。”吴穹说。
    软件企业实施CMM基本上都是从2级，即可重复级起步的。吴穹说：“二级已经不简单了。对一个软件企业来说，达到二级的要求就基本上进入了规模开发，开始跳出作坊式的开发模式，能把一个项目的经验或好的方法重现在下一个项目中，基本具备了一个现代化软件企业的基本架构和方法，具备了承接外包项目的能力。”从二级一直往上走，是不间断的改进过程。“效率不断在提高，时间控制更严格，品质更有保证，管理更有序。可以逐渐具备承接跨地区、跨部门的大型项目的实力。”根据SEI的统计，软件企业在引入CMM后劳动生产率平均增长了35%；错误比率平均减少39%；平均成本回报率为5：1。
CMM重构企业
    在胡大庆的时间表上，1995年底才成立的摩托罗拉中国公司的网络研发中心，在实施CMM上三年内完成了三级跳：1998年内部评审，取得了等同CMM3级的水准；1999年底达到了第4级；2000年的12月通过了5级。
    “但我们是从成立之日起就开始着手准备实施CMM的，算起来也有5年半的时间了。当初积极准备实施CMM是因为摩托罗拉的高层质量管理委员会在90年代中期制定了一个政策，明确规定所有从事软件研发与测试的部门都必须采用CMM，并在规定年限内达到三级或是更高的级别。这是一个研发政策。”摩托罗拉的这个全球研发政策无疑是其中国网络研发中心与软件中心达到CMM5的最大推动力。在实施CMM的整个过程中，胡大庆很重视研发中心步入CMM的起点――1998年做的内部评估。这次评估“让拿着地图的我们不但明确知道目的地是什么地方，而且还找到了自己究竟在什么位置。”在吴穹的眼中，侧重于软件生产过程的CMM的实施，被提升到软件企业重构的地位。摩托罗拉中国网络研发中心5年多来的CMM之路正佐证了他的这种看法。
    胡大庆在清点5年多来的收获时，可谓颇丰。
    “最根本的收获是每一个具体参与其中的员工，无论是项目经理，还是工程师，甚至一些高层管理人的做事方法逐渐变得标准化、规范化了。”以往，软件企业某些关键的开发人员离开后，往往会给企业造成很大的损失，甚至使一个项目前功尽弃。而在CMM框架中，运用2级中的一个基本软件工程(KPA)就可以使员工自觉而规范地管理软件生产过程中所有的资源、阶段性产品、产品源代码、文件以及最终生成的产品。“严格遵循这套管理方法，程序员写完一段代码，经过一定测试之后，一旦提交到某个公共地方时，这个东西就不是你的了，已经成为项目小组或者是整个企业的了。如果你想对它进行任何修改，都要按照规范的程序把它从公共区域提取出来。”规范的过程控制，将软件企业由于人员流动带来的风险降到了最低，同时还促使他们养成良好的职业素养。
    受益者还有摩托罗拉研发中心的项目经理们。CMM可以有效地缩短项目组中新参加人员进入状态的时间。“过去，给新到项目组工作的同事解释流程、规矩很费劲。要是新加入的员工经过CMM的基本培训的话，进来以后，只要稍微澄清一下，他就能知道怎样按定义好的文件与流程来做事情。”项目经理还可以从CMM中获得一整套完整的体系，保证项目良性运转。在项目开始的时候，“他如果不知道项目该怎么做，我们参照CMM框架定义好的文件会规定他应该做什么。比如，有一些样本模式告诉他项目计划书怎么写，如何召开例行会议等。他只要按照定义文件执行就可以很快上手了。”这个体系无疑加速了资深工程师转向项目经理的速度。
  在传统模式下，项目开发的某个阶段，尤其到最后阶段，项目经理会经常发现“成本控制不住了，或是时间来不及了。”这种情形下，项目经理就需要做危机管理，动用“救火队”，或是让客户宽限一些时间，或是游说客户加一些钱，否则就只好牺牲软件产品的质量了。“对于采纳了CMM的项目经理或者说比较成熟的企业来讲，这样的事情也会发生，但是它会是一种可控或者能预见到的。在做项目计划的阶段就事先把突发事件可能发生的情况，一旦发生时必须采取的措施都列出来。于是，传统的危机管理质变为可控的风险管理。”尽管项目经理从CMM实施中获益良多，但当初，“最大的阻力也来自于第一线的项目经理。”因为，实施CMM需要在一线打拼的项目经理放弃几年甚至是十几年形成的那套非常熟悉的套路，要完全按照一种新的规律做一些不熟悉的事情，不愿意肯定是当然的。“一方面要求我提高质量，另一方面又要求我做一些没做过的事，同时谁也没答应我可以延长工期，只有加大工作量了”。但一旦度过艰难的改变阶段，不断的获益使项目经理由CMM实施的阻力变成了推力。
    最大的获益者无疑是摩托罗拉中国的网络研发中心。通过实施CMM，他们的企业文化发生了明显的变化。胡大庆说：“CMM整个实施过程也是一种积累，为我们积累了很多有形和无形的资产。”这种积累甚至小到一个会议该如何开。“以前，我们经常会有一些清谈清议的会。大家没什么准备就来开会，说了半天，有些人不关心；即使发表了不少意见，也没有形成任何结论。”现在，他们的会议是这样开的：会议之前要做充分的准备，让参与会议的人知道要谈的议题，每个相关的人甚至要看到发言的主要内容。如果对议题或发言有什么意见可能在会前就有所反馈。同时，会议一定要有人做记录，所有议论和结论都要记下来。会议在结束之前一定要明确这个会议的决议是什么，有哪几项工作必须做，由谁来做，在什么时候做完。会后要将记录发给大家，还有人专门进行检查；下一次会上的第一个议程，就是总结上一次会议决议的执行情况。
    胡大庆认为“这种一点一点积累起来的习惯性的概念、做事方法非常重要。”没有最好只有更好国内有一个刚刚通过CMM2的软件企业为之花费了400万元人民币。面对这样一个数字，胡大庆说：“我们没有一个具体的数字，但我们所投入的费用肯定比400万元要多。”无法确切统计投入，是因为CMM的实施是一个没有终点与止境的过程，即使通过认证，仍需要长年将CMM体系的实践与软件开发融为一体。由于CMM只提供一个持续改善软件生产质量与过程的框架，并没有制定出具体的方法，因此，就要求实施CMM的企业要在实践中不断发现问题，定义文件与流程，在否定自我中持续优化自身。CMM并没有为实施者界定一个最好的境界，它将不断地追求更好定义为常态。
    CMM认证不是终身的，“按照官方的说法它的有效期一般是两年。”在摩托罗拉公司内就有在通过较高的级别后，重新再做评估时掉到了较低级别的先例。“CMM5级是优化级，之所以称之为优化级不是因为它比4级更高，它强调的是一个持续不断的优化过程。如果你在某一个阶段停顿下来，那么不进则退，你就有可能会掉下去。”摩托罗拉曾有一位资深人士告诫胡大庆：“你们现在面临的困难不是说能够在什么时候拿到CMM4级或5级，而是怎么来保持。”
    为了保持在CMM5上，摩托罗拉中国网络研发中心以年度来规划，每年都会对上一年的CMM做一次评估。“评估结果会告诉我们哪些地方做得好，哪些做得还不够。根据这个结果，我们再制定下一年度改善的规划。这个规划要做得非常具体，包括今年的大目标是什么；在这个目标下要做10件或20件事；这些事由谁负责，什么时候做完。规划制定完以后，就由我们的软件工程定义组(SEPG)来推进，并通过会议制度定期检查这些事情究竟做得怎么样。”胡大庆认为，在不断优化自身的过程中，“建立一套机制很关键。”机制保障之一来自他们内部的CMM推进核心组织――SEPG，它的成员包括研发中心的主要负责人、中层项目经理、骨干工程师以及专门从事质量确保定义工作的员工。这个组有10个人(整个研发中心一共有300名员工)，他们的职责不是从事一般的软件编程，而是专门来负责定义文件，进一步改善日常工作。
    培训是另一个保障机制。“CMM要求全员参加培训。目前员工的培训率达到90%以上。包括秘书在内都要参加CMM的培训。”此外，胡大庆觉得，好工具的引入可以“避免人工犯错的机会”。这样的工具大多是控制软件生命周期的软件。“到了CMM4或更高阶段，很多东西都基于统计分析的结果。比如，每个项目经理在分配一个月的工程量的时候，就不能拍脑袋凭经验安排。他需要借助专门的软件工具，登记员工每天的工作量，最终通过统计报表直接产生出科学的工作量安排。”
    吴穹称，自己从这些软件工具中获益匪浅。“在我读研究生的时候，我曾经用瑞理开发的面向对象分析设计工具做过一个项目。在开始编码前，我们用它搭建出了项目的整体架构，尽管前期用于做分析、设计的时间有4个月，但用在编码上的时间仅有两周。这个工具改变了我以前边想边干的编程方法，让我在施工前就有了一张完整的施工图。施工时，什么样的砖码在什么地方很清楚。”超越认证的制约经常可以在CMM前看到“通过”、“认证”等动词。瑞理中国区销售总监左允京认为冠在CMM身上的这些动词都不准确。在他看来，应给CMM这样一个限定――“实施软件工程，达到CMM标准。”他说：“单纯强调CMM认证，如果没有积累的话，大概两三年之后，就有可能软件企业墙上到处都贴着CMM的认证证书，而CMM却像前几年的ISO9000一样有名无实。那样就是CMM的悲哀了。”要想避免这种局面出现，就要超越为了认证而认证。
    摆脱认证的制约，成为胡大庆总结成功经验中最重要的一点。“在实施CMM前，软件企业一定要讨论清楚是不是要采用CMM。讨论的基础就是，要将CMM与企业的最终利益、发展目标统一起来。如果把追求通过认证作为第一目标，那么，CMM对企业的改善是不可持续的。而在实施中首先要想企业最大的问题在哪，如果CMM可以帮我解决问题，然后再决定实施CMM。”第二个便是企业领导层的认识和决心。“我们之所以成功，就是因为我们历任的总监都非常重视CMM的持续实施。”这样的认识与决心，在CMM的实施影响到了企业暂时利益的时候尤其重要。通常，新工具的实施都是一个趋势：会在初始阶段出现负效果。这个时候要是没有充分的信心坚持下去，那就会半途而废或者新工具被折中为“四不像”。
    摩托罗拉中国公司网络研发中心在由CMM3向CMM4提升的时候就出现过负增长。“在那一个阶段投入大了，因为4级要求强化管理，这非常难做，需要开发很多工具，要求大家在质量上花更多的时间，对一个软件企业而言，时间就是成本。”在“反复”面前，摩托罗拉研发中心的领导层表现出了很强的“抗冲击力”。
    今年4月刚刚通过CMM2认证的西安博通公司的总经理李台元觉得，CMM带来最大的改变就是把隐性管理变为了显性管理。这将CMM背后强大管理需求推到了前台。在实施CMM过程中简化管理是许多企业的软肋。其中，最突出的就是缺少技术管理人员。“好的项目经理太少了。”我国大多数技术管理人员走的是一条“技术优则仕”的道路。在编码面前得心应手的程序员未必能成为优秀的管理人员。管理人才的匮乏，成为走在CMM这条没有终点的路上的软件企业难以逾越的路障。

高能力成熟度软件企业中软件质量工程师的职责

Frank

    随着科学技术的不断发展进步，企业之间的竞争越来越激烈。软件企业要想在竞争中发展生存，提高软件产品质量已成为必要条件。在一些高能力成熟度软件企业中，专门成立了质量保证和控制职能部门，起着提高项目管理透明性和确保软件产品质量的双重作用。
    软件质量工程师是隶属于质量监控部门的工程师，他们独立于项目对质量保证经理负责，以独立审查的方式监控软件生产任务的执行，给开发人员和管理层提供反映产品质量的信息和数据，辅助软件工程组得到高质量的软件产品。每位软件质量工程师可以同时介入多个项目。
    软件质量工程师的工作原则是"用过程质量确保产品质量"。 软件质量工程师在软件生存期的各个阶段起着不同的作用，是软件项目开发过程中不可或缺的重要成员。
    软件质量工程师的职责分为组织相关的职责和项目相关的职责。
1.组织相关的职责
·与客户及时沟通，确保客户满意
    软件质量工程师应当担当"客户代表"的角色，及时与客户进行沟通，了解客户对产品质量、开发进度、开发费用等方面的需求。定期进行客户满意度调查，对客户反馈信息进行分析，为项目管理提供分析结果，及时根据客户需求协助项目经理调整项目开发计划。 ·内部评审
    软件质量工程师参与项目的内部评审活动，其职责包括确定评审员，为评审组织确定评审内容，确保评审按既定的过程执行，并向管理团队通报评审结果。
·审计
    软件质量工程师参与改进并跟踪现有审计制度以适应项目和产品解决方案发展的需要。软件质量工程师相互协作以确保不断地改进现有的审计内容和审计制度，提高管理的透明性。
·度量
    其职责主要是进行量化过程管理，包括完善和执行统计过程控制，贯彻执行度量标准，通过数据采集和分析完善度量基准。
2.项目相关的职责
·为相关项目提供过程管理和质量保证咨询
    软件质量工程师参加项目启动会议，为制定项目开发计划提供相关历史数据。为项目开发人员提供质量保证相关知识的咨询。
·帮助项目建立切实可行的质量保证目标，选择适当的质量保证基准
    软件质量工程师根据客户需求、企业内部质量审查标准、行业标准，按照项目类别建立项目质量保证目标，与项目成员一起讨论并进行必要的修改。明确度量标准和数据收集方法，在项目实施过程中根据建立的目标对项目进行实时监控。
·制定项目质量保证计划
    软件质量工程师根据项目类别、质量保证目标、项目开发进度制定相应的质量保证计划。
·项目审查
    软件质量工程师应当参与必要的项目审查。审查内容包括：
    - 产品需求说明书
    - 软件项目开发计划
    - 测试计划
    - 测试总结报告
·数据收集和分析
    软件质量工程师负责按软件质量保证计划收集与项目相关的数据，通过对数据进行分析，及时将与质量相关的反馈和建议汇报给项目负责人和高级主管。项目负责人根据反馈数据调整项目开发计划。
·项目审计
    软件质量工程师负责鉴别项目开发中与项目质量保证计划中规定的标准和过程不相符的内容，当这些内容与计划偏离比较多，以至于可能影响到项目的及时高质量完成时，可以考虑召开项目审计会议。
    软件质量工程师负责会议的计划、主持，确保审计所有偏离内容，并汇报审计结果。
·系统测试
    软件质量工程师可以介入系统测试，确保软件产品符合质量要求，满足客户需求。软件质量工程师帮助系统测试工程师收集数据，将数据分析结果反馈给项目负责人、系统测试工程师和项目组其他成员。
·错误预防
软件质量工程师负责提供历史和当前数据，帮助项目了解项目所处状态、进度和存在的弱点。所有的错误预防工作都应由项目负责人计划并跟踪，软件质量工程师负责监督。