您的位置:首页 > 其它

UML核心元素--读书笔记

2011-11-08 15:30 190 查看
1. 参与者:系统之外与系统交互,发起动作且为之服务。

业务主角 —— 参与者的一个版型,特别用于定义业务的参与者,在需求阶段使用。
业务工人 —— 系统之内
用户 —— 参与者的代表
角色 —— 参与者的职责

2. 用例:与参与者交互,并给参与者者提供可预测的有意义的结果的一系列活动的集合。注意三个建模阶段用例的粒度。

业务用例 —— 用例的一个版型,专门用于需求阶段,不能把计算机引用进来。
业务用例实现 —— 业务用例的一种实现方式,可以有多个实现方式。
概念用例 —— 少被采用,但推荐使用,用来获取业务用例中的核心业务逻辑。
系统用例 —— 通常说的用例,用来定义系统范围,获取功能性需求的。
用例实现 —— 代表用例的一种实现方式。

3. 边界

4. 业务实体 —— 类的一种版型。注意分析哪些作为业务实体的属性,哪些应单独建模。

5. 包 —— 高内聚低耦合。

6. 分析类 —— 从业务需求向系统设计转化过程中最为主要的元素,在高层次抽象出系统实现业务需求的原型。

边界类 —— 用于对系统外部环境与其内部运作之间的交互进行建模的类。
控制类 —— 源于对用例场景中行为的定义,建议在边界类与边界类、边界类与实体类、实体类与实体类之间默认加入控制类。
实体类 —— 源于业务模型中的业务实体。主要位于数据持久层。

7. 设计类 —— 系统实施中一个或多个对象的抽象,编程语言密切相关。

8. 关系

关联 —— 一个对象在一段时间“知道”另一个对象。如A保存了B的ID。
依赖 —— 一个对象的修改会导致另一个对象的修改。如A使用了B的属性或方法,B的修改会导致A的修改。
扩展 —— 表示 一个场景中的“支流”。如保持通话用例。
包含 —— 与扩展用例不同,它表示的是“必需”,而非“可选”
实现 —— 用不同方式实现基本用例的业务功能。
精化 —— 一个基本用例可以分解出更小的关键精化用例。
泛化 —— 两个对象之间有继承关系。
聚合 —— 表达整体与部分之间的关系,不是强依赖。
组合 —— 表达整体与部分之间的关系,是强依赖。

9. 组件

使用组件的情形:分布式运用,应用集成,第三方系统,SOA服务

10. 节点

至少带一个处理器、内存以及其它处理设备的处理单元。

使用情形:分布式应用环境、多设备应用环境

总结:主谓宾
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: