Thinking in uml

                   第一部分 准备篇-需要了解

第一章  为什么需要UML

第二章 建模基础

2.1 建模

  怎样建模

 

                 抽象角度

 

  什么是建模

 

 

2.2 用例驱动

 

    进程视图，部署视图，实施视图，

 

2.3 抽象层次

          越抽象，信息越少，有助于理解

   抽象方法，自顶而下，适合分析设计
                   自下而上，适合改进

 

 抽象层次跟用例粒度关系
抽象层次跟边界选择的关系

 

2.4 视图

 

视角和视图概念
给哪些软件信息展示视图
给什么干系人展示哪些视图

 

2.5 对象分析方法

 

 

 

 

第二部分 基础篇   在学习中思考

3 UML核心元素

3.1 版型

 

3.2 参与者

 

UML建模也是以人为本

 3.2.1 基本概念

actor位于系统之外与系统交互的某人或者事物

 

如何确定系统之内与系统之外呢？

 

通过回答下面两个问题来确定

 

谁对系统有明确的目标与要求并且主动发起动作

系统是为谁服务的

参与者可以是非人

 

 

3.2.2 发现参与者

 

 涉众与客户岗位的设置

 

参与者直接发出动作并获得反馈

 

3.2.3 业务主角

3.2.4 业务工人

3.2.5 参与者与涉众的关系

 

参与者是涉众的代表

 

3.2.6 参与者与用户的关系

用户是系统的使用者

 

3.2.7参与者与角色的关系

 

角色是参与者的职责

 

3.2.8 参与者的核心地位

 

3.2.9 检查点

3.3 用例

3.3.1 基本概念

一个用例就是与参与者交互，并且给参与者返回有价值有意义的结果的一系列活动的集合

所谓用例就是一件事情，要完成一系列的事情就需要一系列的活动，而做事情有很多方法和步骤，这种事情有很多情况的集合，每种

就是用例场景，一个用例场景就是一个用例实例

 

3.3.2 用例的特征

•  用例是独立的
•  

3.3.3 用例的粒度

•      划分用例依据看该 用例是否完成参与者的完整目标
•      用例看是否处在一个层次，一个量级
•     粒度选择不同本质可能是边界认可不同

        

3.3.4.用例的获得

 

3.3.5 用例和功能区别

• 功能是脱离使用者而存在的
• 功能是独立的，
• 用例是有一系列功能组合而成，先有场景后有功能的

3.3.6 目标与步骤的区别

 

3.3.7 用例粒度的误区

3.4 边界

3.5   业务实体

 

3.6 包

 

3.7 分析类

分析类是介于需求与设计之间

优点

• 高于设计
• 高于语言
• 高于实现方式

抽象层次比较高，比较稳定

 

 

 

 

 

 

 

3.8 设计类

3.9 关系 

      关联

      包含

      扩展

      泛化

      继承

      组合

      精化

 

3.10 组件

 

3.11 节点

 

 

 

 

 

 

 

 

 

 

 

4 UML核心视图

4.1 静态视图

 

4.1.1 用例图

 

业务用例视图

 

系统用例视图