时序图 + 实现层面:类图 + 设计时序图"/>
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 类中
设计时序图(Design Sequential Diagram)
- 设计时序图其实对应的是设计类图,他们都属于 Design Model (diagram)。
- 在概念层面的静态图是 Domain 图,动态图是 System Sequential 图,在实现层面的静态图是 Design Class 图,动态图是 Design Sequential 图
构成要素
:类名
- 用 :类名表示系统中具体交互的对象的类型
一个激活系统的消息(a found message)
带参数的 message
控制焦点(表示对象执行动作的时间)
- 这个是 SSD 中没有的
系统时序图(SSD) 和 设计时序图(DSD)的联系和区别
- 系统时序图把整个系统看做一个黑箱子,只关注 actor 和 系统之间的交互
- DSD 则是专注于系统内部的行为,着重于不同 软件对象 之间的信息交互
NOTE:
设计时序图的时候也要按照 Responsibility-Driven 的原则去设计
实现层面设计总结
概念层面 -> 实现层面
概念层面:Domain 图 + system sequential 图
实现层面:Design 类图 + Design 时序图
更多推荐
SMD(software modelling and design)知识点总结——User Case 图 + 概念层面:Domain 图 / System 时序
发布评论