面向对象分析与设计开发文档

目录
第一部分面向对象基础 (3)
1.面向对象编程的三大原则 (3)
2.对象世界协作模式----客户-提供者消息协作模式 (3)
3.类与类之间的关系及代码实现 (6)
4.面向对象程序设计的任务 (13)
5.面向对象系统分析与设计的过程与产出 (26)
第二部分需求分析 (26)
第三部分系统分析 (26)
1.系统需求说明 (27)
2.用例图： (28)
3.业务处理过程： (29)
4.活动图： (29)
（1）按客户陈述绘制活动图 (29)
（2）对活动图进行分块 (30)
5.基本用例叙述： (35)
6.系统时序图： (36)
7.系统操作约定： (37)
8.创建域模型： (38)
9.一个颠覆常规的域模型案例 (40)
10.对象消息序列图： (40)
第四部分系统设计方案1：控制台应用程序+无数据库 (40)
1.系统总体结构设计 (40)
（1）业务层设计----设计系统总体类图： (40)
2.详细设计: (44)
（1）业务层定义 (44)
<1>类声明： (44)
<2>确定类图： (49)
<3>Jackson图 (49)
<4>算法流程图 (49)
3.编码 (50)
4.测试 (50)
第五部分系统设计方案2：控制台应用程序+数据库系统 (50)
1.业务层设计 (50)
（1）每个数据访问对象直接与数据库打交道 (50)
（2）增加一个单例对象DBOperation (52)
（3）使用Hibernate框架 (52)
2.数据层设计 (54)
（1）E-R图： (54)
（2）关系模式设计 (56)
（3）物理模型设计 (56)
第六部分系统总体设计方案3：人机交互界面+业务处理+DBMS (57)
1.人机交互界面----表示层设计 (58)
（1）状态图： (58)
<1>状态图的概念 (58)
<2>订餐系统的状态图： (60)
<3>菜谱状态图： (60)
<4>顾客订单的状态图： (61)
<5>订单的状态图 (62)
（2）表示层设计: (62)
（3）表示层的实现： (64)
<1>基于窗体的表示层 (64)
<2>基于web页面的表示层 (64)
2.数据层设计 (64)
3.业务层设计 (64)
（1）单机模型： (64)
（2）分布式模型 (65)
<1>C/S模型 (65)
<2>B/S模型 (65)
<3>基于Web的三层系统体系结构 (65)
4.系统整体架构 (66)
（1）0人机交互界面+业务处理+DBMS具体实施方案： (66)
第七部分系统架构与框架技术 (66)
（1）系统体系结构 (66)
（2）技术框架Framework (66)
（3）系统体系结构的发展进程 (67)
<1>单机版 (67)
<2>基于C/S架构的系统体系结构 (67)
<3>基于Web的系统体系结构 (67)
<4>基于Web的三层系统体系结构 (67)
<5>基于Web的四层系统体系结构 (70)
第八部分详细设计 (71)
1.表示层详细设计: (71)
2.业务层详细设计: (71)
3.数据层详细设计: (71)
第九部分设计原则 (71)
1.拙劣设计的症状 (71)
（1）症状 (71)
（2）案例 (72)
（3）原因分析 (72)
（4）问题解决 (72)
2.设计原则 (72)
（1）单一职责原则 (72)
（2）开放-封闭原则 (72)
（3）Liskov替换原则 (72)
（4）依赖倒置原则 (72)
（5）接口分离原则 (72)
第十部分设计模式 (73)
1. 设计模式分类 (73)
（1） 创建型 (73)
<1> 简单工厂设计模式 (73)
<2> 工厂方法模式 (77)
（3）MFC 之工厂模式(C++ & java) (84)
<3> 抽象工厂模式 (85)
第十一部分 系统测试 (87)
1. 测试阶段划分................................................................................................ 87 2. 测试技术........................................................................................................ 87 3. 测试优先的益处.. (87)
这是面向对象的世界，客户向服务器提出请求是为服务器分配职责的唯一标准。

第一部分 面向对象基础
1. 面向对象编程的三大原则
封装、继承、多态
2. 对象世界协作模式----客户-提供者消息协作模式
一、现实中的消息协作模式：
面向对象程序的运行，是对现实世界中对象与对象的协作方式的模拟。

在现实世界中，消息的发送方与消息的接收方，针对消息而言是地位平等的双方。

如下场景1：A 希望获知B 的姓名
现象1：现象3：现象2：
在这个场景中，针对于A 希望获知B 的姓名而互发的消息，可能会出现上述三种现象。

1. A 问，B 答
2. A 问，B 不答（问而不答型）
3. A 不问，B 主动告知。

（不问自答型）
再如下述场景2：A 希望B 去做饭。

现象1：现象3：现象2：同样存在场景1中存在的现象。

1. A 请求B 做事情，B 做事情
2. A 请求B 做事情，B 不做（叫做不做型）
3. A 不请求B 做事情，B 主动做事情。

（不请自做型）
在两个场景中的现象2和现象3都体现了A 、B 双方作为现实世界中的人的行为的自主性。

这些现象是现实中协作的普遍现象，A 、B 对象的协作，其中B 的自主动作掺杂了B 对A 的心理琢磨。

B 认为A 可能会问其什么，或认为A 可能会让其做某事，但B 这种基于猜测的行为可能使结果适得其反，使本不应该发生的麻烦事情发生，从而使事情处理流程变得更糟。

开发计算机软件系统的目的，是为了使事情的处理流程自动化，如果处理流程本身是个紊乱的话，那么计算机软件系统只能加速这种紊乱，因此，在面向对象程序模拟现实世界的消息协作时，采用消息发送方与消息接收方地位不平等的客户-提供者模式来完成协作。

二、客户-提供者消息协作模式
前提：B 拥有A 所问问题的知识；B 具有A 所请求事情的处理能力。

但是A 不问时，B 不主动回答；A 不请求B 做事情，B 不主动做事情。

也即，只有当A 作为客户，请求B 回答问题时，B 作为提供者，提供回答问题的服务；只有当A 作为客户，请求B 做事情时，B 作为提供者，提供解决这件事情的服务。

B 不允许主观去回答问题或主观地做事情。

这种屏蔽了B 的主观能动性的协作方式称为客户-提供者模式。

这样的处理方式，解决了A ，B 消息协作时自主处理事务的方式，从而使消息协作变得可控。

三、客户-提供者消息协作中的约束
（1）协作的前提
服务提供者B拥有客户A所问问题的知识；B具有A所请求事情的处理能力。

（2）对客户的约束
客户端对象，作为消息的发送者，作为服务的请求者，不应该发送无理的请求，无理的请求指：服务提供者不具备的行为能力。

客户端对象A只能向服务端对象B发出两种类型的消息：消息应该是一个问题，或者一个命令，不能两者都是。

（3）对服务提供者的约束
消息对应行为的执行者，即，服务提供者。

在面向对象程序中，服务提供者应该是谦恭的，当接收消息时，必须提供相应的服务，
四、实例：
1.顾客到面包店买面包的场景
方式1：现实中的场景反映：
可见，由于面包师的自动行为使得事情变得很糟。

现在，通过客户-提供者模式来实现这个场景：
方式2：
可见，客户-提供者模式有效地解决了因对象自主行为而导致的业务流程的紊乱过程，使得业务处理过程可控，因此，在面向对象程序模拟现实对象消息协作机制中，客户-提供者模式给我们提供了很好的消息协作模式，这种方式屏蔽了现实世界对象的自主行为，使得面向对象系统秩序稳定，和谐可控，构建了一个完美的软件系统。

3. 类与类之间的关系及代码实现1
解析UML中类与类之间的五种关系
类与类之间的关系，其实质就是类的对象与类的对象之间的关系。

对象与对象之间的关系就是提供服务与接受服务的关系。

根据对象与对象之间的服务关系存在时间的长短，可以确定类与类之间的关系。

通常把类与类之间的关系分为如下五种关系，分别是：泛化关系、依赖关系、关联关系、聚合关系和组合关系。

本讲将通过男人、女人、丈夫、妻子、一夜情人、情人、房子、家和孩子这样一个完整的例子来说明这五种关系。

一、泛化关系
1.泛化关系的理解
泛化关系常与继承关系相提并论，继承关系指子类继承父类的属性和行为；泛化关系则是指将子类的共同属性和行为提取出来，形成更一般的概念，子类相对于一般化概念来讲就是特殊概念。

特殊与一般之间的关系就是泛化关系。

反过来，由一般到特殊的关系就是继承关系。

所以，也讲泛化关系表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。

一般化的关系，即，泛化关系是从子类指向父类，与继承或实现的方法相反。

泛化关系是一种存在于一般概念与特殊概念之间的分类关系，它只使用在类型上，而不是实例上。

2.泛化关系的UML表示方法
泛化关系中对应于一般概念的类被称为超类或父类，而特殊概念的类被称为子类。

在UML中，泛化关系用一条从子类指向父类的空心三角形箭头来表示。

下图表示了丈夫与男人之间的泛化关系，以及一夜情人、情人和妻人与女人之间的泛化关系。

1类与类之间的关系及代码表现/view/53fdfa75a417866fb84a8ed4.html
3.泛化关系的代码实现
泛化关系可以通过类的继承的方法来实现，如上图例子对应的代码：
Class NanRen
{
doThing( );
}
Class ZhangFu extends NanRen{}
Class NvRen
{
doThingAtTheSameTime();
}
Class YiYeQingRen extends NvRen{}
Class QingRen extends NvRen{}
Class QiZi extends NvRen{}
二、 依赖关系
1.依赖关系的理解
对于两个相互独立的对象，当客户端对象负责构建了服务器端对象的实例时，或者客户端为了完成某些职责而需要向服务器端对象发送消息请求服务端对象提供服务时，这时，客户端对象的职责的完成依赖于服务器端对象的服务时，两个对象之间表现为依赖关系。

在依赖关系中，客户端对象与服务器端对象关系非常弱，仅在提供服务时发生关系。

在依赖关系中，客户端对象称为依赖方，服务器端对象称为被依赖方。

2.依赖关系的UML 表示方法
在UML 中，依赖关系用带箭头的虚线来表示，从依赖方指向被依赖方，也即，从客户端对象指向服务器端对象，如下图表示丈夫与一夜情人之间的依赖关系。

3.依赖关系的代码实现
依赖关系在代码实现上，把服务器端对象作为客户端对象的方法的参数，客户端职责的完成通过对服务器端静态方法的调用来实现。

上图示例的代码如下
代码实现如下所示：
Class zhangfu
{
doThing(YiYeQingRen aYiYeQingRen )//该对象作为方法的输入参数，该对象
的作用域为整个程序
{
aYiYeQingRen.doThingAtTheSameTime();
}
}
主程序：
Public Class Test
{
Main()
{
ZhangFu aZhangFu= new ZhangFu(“LMB”,”30”);
ZhangFu bZhangFu=new ZhangFu(“DF”,”30”);
YiYeQingRen aYiYeQingRen = new YiYeQingRen(“DZX”,”28”); //该对象的作用域为整个程序
YiYeQingRen bYiYeQingRen = new YiYeQingRen(“DZXM”,”28”);
aZhangFu.doThing(aYiYeQingRen);
aZhangFu.doThing(bYiYeQingRen);
bZhangFu.doThing(aYiYeQingRen);
}
}
三、关联关系
1.关联关系的理解
对于两个相对独立的对象，当一个对象的实例与另一个对象的特定实例存在固定的对应关系时，这两个对象之间为关联关系。

与依赖关系相比，关联双方由于存在比较固定的服务与被服务关系，因此，关联关系是一种较依赖关系更强的关系。

2.关联关系的UML表示方法
在UML中，关联关系用直线来表示，直线连接关联的双方。

从关联双方的提供服务与被提供服务的关系来讲，关联双方也存在客户端对象与服务器端对象，提出服务请求的一方为客户端，提供服务的一方为服务器端。

下图表示男人与其情人之间存在的关联关系。

其UML如下图所示：
3.关联关系的代码实现
关联关系在代码实现上，关联双方中的服务器端对象表现为客户端对象的方法的局部参数，客户端职责的完成通过对服务器端静态方法的调用来实现。

Class zhangfu
{
doThing()
{
QingRen aQingRen=new QingRen();//该对象的作用域只在这个方法中
aQingRen.doThingAtTheSameTime();
}
}
主程序：
Public Class Test
{
ZhangFu aZhangFu= new ZhangFu(“LMB”,”30”); //由构造函数决定
aZhangFu.doThing(“DZX” ,”28”);
}
四、聚合关系
1.聚合关系的理解
当对象A被加入到对象B中，成为对象B的组成部分时，对象B和对象A之间为聚合关系，聚合是关联关系的一种，是一种较强的关联关系，强调的是整体与部分的关系。

2.聚合关系的UML表示方法
在UML中，聚合关系用带空心菱形的直线来表示，空心菱形端指向表示整体概念的类，另一端连接的是部分概念的类。

西方社会讲究，妻子是丈夫的组成部分，可以用下图来表示。

再如，房子与家的关系，房子是家的一个部分，因此，房子与家之间也存在部分与整体关系，可以用下图来表示。

家与房子之间的聚合关系
3.聚合关系的代码实现
聚合关系是通过实例变量来实现这种关系的。

Class ZhangFu
{
Private QiZi aQiZi;//该对象的作用域是整个类
doThing()
{
aQiZi.doThingAtTheSameTime();
}
doOthingThing()
{
aQiZi.doOthingThingAtTheSameTime();
}
}
主程序：
Public Class Test
{
Main()
{
ZhangFu aZhangFu= new ZhangFu(“LMB”,”30”,”DZX”,”28”);//由构造函数决定aZhangFu.doThing();
aZhangFu.doOtherThing();
}
}
五、组合关系
1.组合关系的理解
当对象A被加入到对象B中，成为对象B的组成部分时，则对象B和对象A之间为整体与部分的关系，B与A之间是聚合关系。

如果要求整体生成之前，部分必须已经产生，整体销亡之前，部分必须先销亡，这时对象B与对象A之间的关系就转化为了组合关系。

2.组合关系的UML表示方法
在UML中，组合关系用带实心菱形的直线来表示，实心菱形端指向表示整体概念的类，另一端连接的是部分概念的类。

丈夫、妻子与家之间的组合关系可以用下图来表示。

丈夫、妻子与家之间的组合关系
3.组合与聚合在语义上的区别
组合是一种更强的聚合关系。

不仅强调了整体与部分的关系，而且体现了部分的生存周期依赖于整体的生存期。

这一点也正是聚合关系与组合关系的区分点，如果整体销亡了，部分还有存在的意义，则整体与部分之间是聚合关系，如果家与房子之间，家不存在了，房子仍然有价值，那么家与房子之间就是聚合关系。

如果整体销亡了，部分存在没有意义，则整体与部分之间就是组合关系，如家与丈夫和妻子之间的关系，家不存在了，则丈夫和妻子无从谈起，因此，丈夫和妻子对于家来讲是组合关系。

4.组合关系的代码实现
与关联关系一样，组合关系也是通过实例变量来实现这种关系的。

Class Jia
{
Private ZhangFu aZhangFu;//作用域为整个类
Private QiZi aQiZi;//作用域为整个类
}
主程序：
Public Class Test
{
Main()
{
Jia aJia= new Jia(“LMB”,”30”,”DZX”,”28”);
}
}
5.聚合与组合在代码实现上的不同
组合关系是一种比聚合关系更强的整体-部分关系，在代码实现上都体现为服务器端的对象作为客户端对象的成员变量，但组合关系更强调部分在整体产生前产生，在整体销亡前销亡，这一点主要体现在垃圾回收机制上。

在C++编程语言中没有垃圾回收机制，整体销亡后，要求编码将部分销亡，也即释放掉部分占用的存储空间，在Java语言、C#语言中增加了垃圾回收机制，整体销亡后，没有意义的部分对应的对象，由系统提供的垃圾回收机制自动回收，也即，系统释放这
些没有意义的对象对应的内存空间。

因此，在Java和C#中，聚合关系和组合关系，在代码体现上区分就不明显了，因此，有的文章中，对于聚合关系与组合关系就不再进行细化，而是统一称为聚集关系，也就是把类与类之间的关系分为了四类：泛化、依赖、关联和聚集。

六、一个小Baby的问题
当一个男人与一个女人发生关系，就有可能有一个小baby产生，这个关系反映在面向对象的类与类的关系中，就是客户端对象负责构建服务器端的对象的实例，这种关系也是一种依赖关系，在代码实现上也表现为客户端的方法的参数。

与依赖的另一种情况：客户端对象职责的完成依赖于服务器端提供的服务的依赖关系，不同之处在于，这种情况下的依赖关系，服务器端对象作为客户端对象的方法的返回值的参数出现。

丈夫、一夜情人与小baby之间的依赖关系如下：
代码实现：
Baby的类模板
Class Baby
{
Private xb ;
}
丈夫的类模板
Class Zhangfu
{
Public void doThing(YiYeQingRen aYiYeQingRen)//同时体现了方法的多态
性
{
aYiYeQingRen.doThingAtTheSameTime();
}
Public Baby doThing(YiYeQingRen aYiYeQingRen) //产生的新对象的作用域是整个程序
{
aYiYeQingRen.doThingAtTheSameTime();
Baby aBaby =new Baby(xb);
Return aBaby;
}
}
主程序：
Public Class Test
{
ZhangFu aZhangFu= new Zhangfu(“LMB”,”30”);
YiYeQingRen aYiYeQingRen = new YiYeQingRen(“DZX”,”28”);
Baby aBaby;
aBaby= aZhangFu.doThing(aYiYeQingRen, ‘n’);//一个小Baby产生了，这个小东西的作用域是整个程序。

}
由上分析，可以得到如下对象与对象之间关系的整体结构图。

男人、女人、情人、丈夫、妻子、房子和家之间的关系
小结：
从上分析，可以看出，类与类之间的五种关系，可以分为三类：其中泛化关系为一类，强调由特殊到一般的关系，依赖关系与关联关系为一类，强调服务器端对象为客户端对象提供服务的关系，关联关系强于依赖关系，关联关系中，服务器端对象为客户端对象提供服务的关系更加固定。

聚合关系和组合关系为一类，强调的是部分与整体的关系。

这些关系表现为面向对象程序实现时代码的不同，因此，发现对象，确定对象与对象之间的关系，即类与类之间的关系，是有必要而且非常重要的。

4. 面向对象程序设计的任务
本文在介绍面向对象程序运行基础上，介绍了面向对象程序设计的任务及过程，并通过案例进行讲解。

几个概念：
对象
对象的属性
1.从实例出发说明：面向对象程序运行的原理，由静到动，调用服务服务器端的方法。

（1）给一个程序，演示，说明，有几个类，各自有什么方法。

对象之间的消息传递。

（2）从代码的角度解释，程序中有几个类，各自有什么方法。

对象之间的消息传递就是对服务器端方法的调用。

2.从现实角度出发，解释面向对象设计的任务，由动到静，完成为类分配职责的任务。

（1）现实的图片，分析图片中的对象的不同类，并说明各类对象具有的相同属性。

（2）抽象类模型，类名，类的属性（此时类只具有静态属性）
（3）对象之间互发消息，得到客服消息表，得到对象消息交互图，从而转换为服务器端类的方法。

完成设计。

知识点介绍
一．面向对象程序运行原理
1．相关概念
2．运行原理：由静到动，协同工作。

二．面向对象程序设计任务。

1．面向对象程序设计任务：为类分配职责
2．面向对象程序设计过程：由动到静，完成设计任务。

3．案例
一．面向对象程序运行原理
体会：
1.对象的概念
2.由对象抽象类
3.对象的属性与行为与类的属性与方法
对象的行为：对象具有的能力，会做的事情。

体会软件系统中类模板与类的对象的关系
体会：
（1）.由类创建对象
属性值的不同产生了不同的对象。

（2）.对象具有行为能力，但现在处于静止状态。

（3）.类的不同对象具有相同的方法，可以共享方法的实现算法。

体会软件系统中类模板与类的对象的关系
之一：类的抽取
之二：发送消息
体会：
（1）.向服务器端发消息，就是向服务器端提出服务请求，调用服务器端对象的方法
（2）.对象调用所属类的方法，即产生了对象的行为。

之三：发向自已的消息
体会：
（1）向服务器端发消息，就是向服务器端提出服务请求，调用服务器端对象的方法
（2）对象调用所属类的方法，即产生了对象的行为。

之四：行为的协作
相互协作，共同推动系统的运行。

因此，得到了面向对象程序运行原理：
（静）对象（类）各司其职
（动）互发消息各尽其能
（效果）协同完成任务
在介绍面向对象程序设计之前，先介绍几组概念，如下表1所示：
对象在现实中是一个非常普遍的概念，现实中的一切都是对象，现实中的对象各司其责，通过互发消息，各尽其能，协同完成工作。

对象的组成
对象名
对象的属性
对象的行为
对具有相同属性集和相同行为集的对象进行抽象，就得到了这些对象所属的类。

类的不同对象之间其属性值可以不同，但各个对象的行为算法一样，因此，同一个类的所有对象可以共享算法代码，这些属性和行为可以被看作是新建类的对象的模板，类与对象的关系如同模具与产品之间的关系，类可以创建属于它的新对象。

2在面向对象软件开发中，类创建的对象也叫类的实例或者叫做类的对象简称对象。

对象的行为即是对象负责的职责，即抽象为类的方法，对象的行为实现即是类的方法的实现。

消息是一个对象要求另一个对象执行其负责的职责的请求，消息的发送方可以被看作是客户端对象，消息的接收方可以被看作服务器端对象。

消息从客户端对象发向服务器端对象，即是客户端请求服务器端执行其负责的职责，即是对服务器端对象方法的调用。

因此，发送消息，应指明：
对象名，消息接收方服务器端对象的标识
消息名，即是服务器端对象被请求执行的行为职责名。

消息的参数，即，执行相应职责行为所需的数据。

在消息中，并没有过多体现客户端的信息。

行为的协作就是通过消息的传递来实现的。

一类比较特殊的情况：自已发向自己的消息，自身既是客户端对象又是服务器端对象。

二．面向对象程序设计任务(为类分配职责,由动到静)
（1）.对象与对象之间消息传递(动)
（2）.转化为服务器端对象的方法(静)
2Robert V.Stumpf, Lavette C.Teague著，梁金昆译. 面向对象的系统分析与设计（UML版）清华大学出版社，P205-206
面向对象程序设计的任务----为类分配职责
1．什么是职责？
一个对象对另一个对象应尽的义务，或者讲，是一个对象应向其他对象提供的服务。

2．如何分配职责？
由面向对象程序运行原理可以知道，当客户端向服务器端发送消息时，即，客户端请求服务器端提供服务时，客户端所发送的消息，必须是服务器端能提供的服务，也即对服务器端的方法的调用。

反过来，如果客户端向服务器端所发送的消息请求是合乎依据的请求，那么就应该是服务器端应提供的服务，也即，服务器端应具有的方法，由此，可以通过将客户端向服务器端发送的消息请求，转换为服务器端的方法，这就完成了为类分配职责的任务。

3．如何确定客户端向服务器端提出的消息请求。

为类分配职责的事情被转化为寻找向服务器端发送的合乎情理、合乎工作逻辑的消息，根据什么来确定向服务器端发送的这些消息呢？即，根据与用户交流后形成的用例叙述来确定。

4．消息的类型、职责的类型
通过把向服务器端发送的消息转化为服务器端的职责、方法来完成为类分配职责，那么消息的类型就决定了职责的类型。

客户端向服务器端发送的消息，可以分为如下两类：获知类消息和执行类消息。

举例：
5. 面向对象系统分析与设计的过程与产出
过程中需要一些图形进行交流，但不能滥用图形，不能夸大图形的地位
面向对象系统分析与设计的产出只有源代码清单。

何时使用图形，要将产生图形与产生代码的成本进行比较，如果产生代码的成本较小，则产生图形的工作可以忽略。

第二部分需求分析
第三部分系统分析
系统分析图解如下：
（1）系统需求说明书→用例图
系统需求说明书：用于描述系统基本功能要求及性能要求→用例图：用于描述从用户角度来看，用户参与了系统的哪些基本功能，或者说，用户使用了系统的哪些功能。

对于性能没有体现。

（2）用例图中每个用例对应的业务处理过程描述→每个用例的活动图
活动图以用例为单位，对每个用例的业务处理过程描述是绘制活动图的依据。

活动图的绘制可以用于检验用例对应的业务处理过程的正确性、完整性。

活动图一方面要求体现为了完成一项用例活动所需做的动作流的组合，另一方面也要求体现在完成这项活动时是否有新的对象产生了。

第二部分常常为人们使用活动图模型时所忽略，从而导致大家认为活动图不重要的一个重要原因。

事实上，活动图的正确性将直接影响到面向对象系统分析与设计时的对象的寻找类的抽象方法的抽象等重要环节。

这些环节是一些软件工程理论知识如：模块独立性原则、模块内聚性、模块间耦合性的体现，甚至包括面向对象程序设计的方法的设计原则都会在活动图中找到其影子。

因此，活动图是一个非常非常重要的模型。

（3）活动图的模块划分→基本用例叙述
基本用例叙述也是面向对象系统分析与设计过程中非常重要的一个模型。

基本用例叙述是将系统需求由面向过程叙述转化为面向对象思维的一个重要环节。

基本用例叙述奠定了整个系统分析与设计的思维方式，采用面向对象的客户---服务器消息请求思维模式。

基本用例叙述打开了采用面向对象思维模式对整个系统进行分析与设计的第一步。

（4）基本用例叙述→系统时序图（不完整的消息序列图）
如果说基本用例叙述不能够十分清晰地让你看清你所使用的分析设计思维模式，系统时序图所表现出来了参与者与系统的消息通信，应该当你看到了面向对象的思维方式。

系统时序图只反映了系统的参与者或者说是系统的使用者与系统之间的消息通信。

客观世界是一个丰富多样的世界，面向对象的系统也不甘是一个对象贫瘠的世界。

（5）基本用例叙述→系统操作约定
（6）系统操作约定→域模型
（7）基本用例叙述、系统操作约定→对象消息序列图
系统所对应的现实的对象及其通信关系到此分析结束
（8）对象消息序列图、域模型→业务类图
1. 系统需求说明
系统需求说明书：
某企业为了方便员工用餐，为餐厅开发了一个订餐系统（COS：Cafeteria Ordering System），企业员工可通过企业内联网使用该系统。

企业的任何员工都可以查看菜单和今日特价。

系统的顾客是注册到系统的员工，可以订餐（如果未登录，需先登录）、注册工资支付、预约规律的订餐，在特殊情况下可以覆盖预订。

餐厅员工是特殊顾客，可以进行备餐、生成付费请求和请求送餐，其中对于注册工资支付的顾客生成付费请求并发送给工资系统。

菜单管理员是餐厅特定员工，可以管理菜单。

送餐员可以打印送餐说明，记录送餐信息（如送餐时间）以及记录收费（对于没有注册工资支付的顾客，由送餐员收取现金后记录）。

顾客订餐过程如下：
1. 顾客请求查看菜单；
2. 系统显示菜单和今日特价；
3. 顾客选菜；。