SMD（software modelling and design）知识点总结——User Case 图 + 概念层面：Domain 图 / System 时序图 + 实现层面：类图 + 设计时序图

编程入门行业动态更新时间:2024-10-24 14:27:33

SMD（software modelling and design）知识点总结——User Case 图 + 概念层面：Domain 图 / System <a href=https://www.elefans.com/category/jswz/34/1768946.html style= 时序图 + 实现层面：类图 + 设计时序图"/>

SMD（software modelling and design）知识点总结——User Case 图 + 概念层面：Domain 图 / System 时序图 + 实现层面：类图 + 设计时序图

文章目录

UserCase Diagram
- 构成要素
- - 参与者：
  - 用例：参与者能够感受到的系统服务或者系统的功能单元
  - 系统边界：系统边界区分了系统的内部功能和外部事物
  - 关联：
概念层面设计图
- 领域图（Domain Diagram）
- 系统时序图（System Sequential Diagram）
- - 构成要素
  - - 参与者
    - ：系统
    - 生命线
    - 循环
  - 用例图-> 系统时序图的举例
实现层面设计图
- 设计类图（Design Class Diagram）
- - 构成要素
  - - 类名
    - 关联关系
    - 类的属性，数据类型和方法
    - 接口和抽象类
  - 类图和领域图的异同
  - 责任驱动的设计理念（Responsibility-Driven Design）
- 设计时序图（Design Sequential Diagram）
- - 构成要素
  - - ：类名
    - 一个激活系统的消息（a found message）
    - 带参数的 message
    - 控制焦点（表示对象执行动作的时间）
  - 系统时序图（SSD）和设计时序图（DSD）的联系和区别
- 实现层面设计总结
概念层面 -> 实现层面
- 概念层面：Domain 图 + system sequential 图
- 实现层面：Design 类图 + Design 时序图

UserCase Diagram

构成要素

参与者：

- 系统的使用者
- 系统的维护者
- 其他的系统

用例：参与者能够感受到的系统服务或者系统的功能单元

系统边界：系统边界区分了系统的内部功能和外部事物

关联：

- 包含（include）：包含关系把一个用例的功能拆分成几个部分，包含用例是一个基本用例的组成部分，和基础用例一起执行。箭头通常是从基本用例指向扩展用例。

- 扩展（extend）：扩展关系顾名思义，就是将用例中加入新的行为，获得新的用例，相当于给基础用例添加了附加的新功能，如果缺少了扩展用例并不会影响基本用例的完整性。箭头一般是从扩展用例指向基本用例。
- 泛化（generalization）：泛化关系表示的是用例之间的“父子关系”，类似于继承。

概念层面设计图

领域图（Domain Diagram）

领域模型是领域内的概念类或现实世界中对象的可视化表示，又称为概念模型或分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
domain 图不涉及具体的类的实现，而是更多地停留在概念层面，关注的是整个系统中的不同角色之间的交互。
domain 模型关注的是：在问题领域（problem domain）中有价值的 “概念”，“属性”，“关联”
domain 图中没有方法的设计，只关注属性和不同角色之间的关联。
可以使用标注方向的尖头来表示不同角色之间关系的方向

系统时序图（System Sequential Diagram）

系统时序图把整个系统当做一个 black box，不管内部的具体实现，哪怕系统内部调用了很多方法，我们并不关心这些方法的具体调用情况。
每个 SSD 都是一个用例的特定场景

构成要素

参与者

：系统

生命线

循环

用例图-> 系统时序图的举例

首先用例图中的 Cashier 向系统请求了一个 Process Sale 的操作，这在用例图中非常直观
在系统顺序图中则是在这种特定的用例场景中将系统和 Cashier 的交互描述的很清楚

NOTE:
系统时序图和系统的 domain 图一样都是在整个系统层面的概念设计，不涉及到具体的类，只是把每个不同的系统之间的交互图演示清楚

实现层面设计图

设计类图（Design Class Diagram）

构成要素

类名

关联关系

类的属性，数据类型和方法

接口和抽象类

类图和领域图的异同

他们都使用UML 类图来表示
领域图注重的是“problem domain ”中的概念，属性和关联
设计模型关注的是实现方面的具体细节，某个类在系统中扮演的角色和做出的贡献
领域图只有一个类似 “类名” 的名称，以及相应的属性，没有方法
领域图没有 multiplicity 的关联关系，因此在表示两个部分有关联的时候，通常使用实线连接，而不是带箭头的实线

责任驱动的设计理念（Responsibility-Driven Design）

从 Domain 图进一步设计成 Design Class 图的时候，要进一步对不同部分的责任进行划分。责任分为两大类：
- Knowing Responsibility
- Doing Responsibility
  
  根据这两个原则：
从 Domain 转成 Class 图的时候，我们 Sale 有责任知道他的总数（knowing 责任），因此设计了 getTotal 方法
同样的，Sale 也应该有能力去 makeLineItem，因此也设计了这个方法放在 Sale 类中