OOD之UML

阅读更多

 

	UML支持
需求：用例模型	用例图、活动图、状态图
分析&设计：静态模型	类图
分析&设计：动态模型	序列图、协作图、状态图
分析&设计：物理架构	部署图、构件图
系统实现	引用所有模型及其图
系统测试	引用所有模型及其图

 

一、用例模型

用例是外部可见的一个系统功能单元,这些功能由系统单元所提供,并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例的用途是在不揭示系统内部构造的情况下定义连贯的行为。

 

要点：

• 围绕系统的一个工作过程，确认参与交互过程的参与者
  • 如：业务用户、外部客户、运维人员、外设、其他系统

• 用系列动作步骤描述交互过程
  • 参与者的动作、系统的执行步骤

• 要点
  • 忽略内部细节，仅考虑外部因素

二、静态模型
1、描述一个软件的静态结构，首先应将整个系统划分为若干子系统或几个组成部分，每个组成部分以一个包来表示。

2、接着，需要设计具体的类，并用各种关联符号表达出类间的关系，注意，每个类都必须归属于某一个包，这样才便于查找某个类。

-关联、聚集、继承、依赖

 

三、动态模型

3、序列图按照时间顺序, 跟踪对象之间事件的发生、传递过程。

要点：

• 时间顺序与发送关系
  • 自上而下
  • 事件连续性（必须从参与者开始）

• 响应关系
  • 对象提供方法来响应消息

• 对象的生存期
  • 创建、撤消

 

 

 

 

4、协作图：对象之间事件的传输关系，比较适合表达类之间的依赖关联

 

 

 

5、状态图：系统或对象内部的状态转移关系。当系统可以明显地划分为几个不同状态时，可以采用。

状态图用于描述类的行为，但它们也描述用例、协作和方法的动态行为

 

6、活动图：最适合表达出一种处理流程或执行过程.

活动图没有表示出计算处理过程中的全部细节内容。它们表示了活动进行的流程但没表示出执行活动的对象。活动图是设计工作的起点。为了完成设计，每个活动必须扩展细分成一个或多个操作，每个操作被指定到具体类。

 

 

四、物理模型

7、构件图

 

 

 

8、部署图

 

 

总结：
（1）所有图的最根本目的是要对系统运行过程中的各个对象之间的关系作出确定性的唯一性的描述，从而保证所有开发人员都能对系统有一个统一的认识。

（2）一般在确定了软件的静态结构之后才进行描述系统的动态特性

（3）在任何情况下，保证模型与实际代码的一致都是至关重要的！

（4）要根据实际情况选择一种合适的图来表达系统，不要强行要求用上所有类型的图，牢记：我们的目的是为了交流！

• OOD之UML.rar (79.4 KB)
• 下载次数: 5