ThinkingUML

新建工程

1、方法1

2、方法2：通过模型创建

StarUML制作类图

设计类

类

比如从用途的角度来看，汽车，轿车，自行车都可以抽象称为交通工具类

属性

属性是对象特征，一个类会有很多属性，只需要关心特定场景下的属性就可以了。

在为对象建立属性时需要考虑的一个指导原则是只有对象单独具有的特征才能建模为属性。否则，应该使用与类的关联关系或者聚合关系对其特征建模

方法

原则：一个对象的属性只能由它自己的方法来改变

创建类图

选择之后，ToolBox会产生相应的变化，生成对应的功能组件

创建实例

你可以通过单击或者双击工具箱来选取元素，至工作区单击左键，就可以创建一个class实例。

• 单机：只取一次
• 双击：锁定选取，知道Esc取消锁定
  
  各个功能按钮介绍
  
  功能介绍：

1. 用来标识Class的可见性（默认为public）
2. 用来添加note的，比如：类的说明
3. 增加类的属性
4. 增加类的操作方法。
5. 增加Reception
6. 增加子类
7. 增加父类
8. 添加已有的接口
9. 添加需要的接口
10. 添加关联
11. 添加聚合
12. 添加组合
13. 添加端口
14. 添加部件

例图的关系

https://segmentfault.com/a/1190000011556007
https://blog.csdn.net/tianhai110/article/details/6339565 【待研究】

泛化[继承]generalizetion

就是Java中的继承

例子：

实现realize

class具有interface的功能

关联association

备注：公说公有理，婆说婆有理

1、描述不同类之间的对象的结构关系，它在一段时间内将多个类的实例连接在一起。【依赖关系是两个实例之间的临时关系】

2、表示一个对象在一段时间内一直"知道另一个对象的存在"。例如A对象保存了B对象的ID。[单向关联]

还比如：参与者知道用例。[用例是不知道参与者的]

---

关联表现的则是两个对象之间一种很弱的联系。关联分为两种：带有方向的单向关联；不带方向的双向关联。

例如，一个学生可以有一个到多个老师，一个老师也可以有一个到多个学生。
或者，一名淘宝用户可以下零个或多个订单，而一个订单只能被一位用户拥有。

---

依赖dependency

1、一个对象的修改会导致另外一个对象的修改

依赖关系除了"知道"其他对象的存在，还会"使用"其他对象的属性和方法

---

类A的实现需要引用类B，这就是依赖，这种使用关系是具有偶然性的、临时性的、非常弱的，而B类的变化会影响到A，则A与B存在依赖关系，依赖关系是弱的关联关系。例如：人依赖计算机去做软件开发。

组合composition

是一种contains-a的关系，部分不能脱离整体存在。整体的生命周期即为组成部分的生命周期：B会随着A的创建而被创建，B也会随着A的消亡而消亡

比如人有心脏，大脑组成。

聚合aggregation

聚合是关联关系的一种特例，它体现的是整体与部分的关系，是has-a的关系，此时整体与部分之间是可分离的，即没有了整体，局部也可单独存在。就比如我们航母战斗群：驱逐舰，巡洋舰，护卫舰，航空母舰等。

还比如：一个部门由许多人员聚合而成，部分撤销之后，人员不会因此消失，它们依然存在。

StarUML制作用例图

用例图用来表达系统对外提供的服务或者功能，适合用来作为需求搜集阶段的工作。

选择之后，ToolBox会产生相应的变化，生成对应的功能组件

关系

实现realize

业务目标：交纳话费
实现图形：营业厅缴费，APP缴费，网页缴费。
这些用例实现都是同一个业务目标的不同实现过程，因此它们是实现关系

精化refine

精化：由基本对象分解为更加明确，精细的子对象，这些子对象没有增加，减少，改变基本对象的属性和行为。
泛化：基本关系被泛化为子对象之后，子对象继承了基本对象的所有特征，并且可以改变基本对象的行为和属性。
精化关系仅仅用于建模阶段，实现语言中没有精化这一概念

泛化generalization

不建议在用例之间使用泛化关系：用例带有原子特性，每个用例都应该是独一无二的。

参与者

如果要建模，就要先找一个抽象角度；如果要找抽象角度，先参与者，也就是是who来使用这个系统

定义：在系统之外与系统交互的人或者事务
参与者也叫做主角。

备注：系统边界有可能不会画出来

参与者一定位于边界之外

因此必须先明确系统边界。
两个问题确定参与者：

• 谁对系统有着明确的目标和要求并且主动发起动作
• 系统是为谁服务的

参与者可以不是人

需求：每天自动统计网页访问量，生成统计报表，并且发送到管理员信息。这个需求的参与者是谁。
分析：计时器，因为计时器每天会在某一个固定的时刻启动这个需求。

备注：任何需求都必须至少有一个启动者，如果找不到启动这，这个就不是一个功能性要求，而是系统可用性的一个土体要求。比如为了方便使用，系统页面上会有操作提示，这个提示找不到启动者。

谁是参与者

（1）参与者一定是直接并且主动的向系统发出动作并且获得反馈的。

（2）例子：
场景一：机票购买者通过登陆网站购买机票。
分析：参与者为机票购买者

场景二：机票购买者通过呼叫中心，由人工坐席操作订票系统购买机票
分析：参与者为人工坐席。人工座席是使用这个系统的人

场景三：机票购买者通过呼叫中心的自动语音购买机票
分析：呼叫中心与机票预订系统交互，呼叫中心是机票预订系统的参与者。

场景四：如果呼叫中心是机票预订系统的子系统，机票购买者可以通过登陆网站买票，也可以通过呼叫中心的自动语音或者人工买票。
分析：机票购买者是参与者

业务主角

业务主角是参与者的一个版型，与业务系统交互，用来确定业务范围。

业务范围与系统范围是不同的：业务范围值得是客户业务，这些业务在没有计算机系统就已经存在了；系统范围是为了辅助业务而要实现的软件系统功能
备注：有一些系统功能不是业务范围，比如系统日志。

业务工人

引出：有些人员参与了业务，但是是被动参与业务的，没有什么具体的目的，但是又做了事情，所以要不要为这些人建模。

答：不要为这样的人员建模。

例子，购买系统的人工座席：人工系统可以订票，但是他是系统边界的一部分，而且没有购买人要求，它是不会去订票的。如果把人工座席当作参与者建模，就会出现下面的情况：

因此，不要为这样的人建模，它们是业务功能而非参与者，视为业务主角服务的，它们的工作就是完成业务主角的业务目标。

备注：虽然业务共人不需要建立业务模型，但是它们是业务模型中非常重要的部分，经常出现的地方是领域模型和用例模型。缺少了它们业务模型就不完整，甚至不能运行。

参与者与涉众的关系

涉众是与建设的这个系统有利益相关的一切人与事，涉众的利益要求会影响系统的建设，只要和这个系统有利息关系的都是这个项目的涉众
参与者是涉众代表，参与者通过对系统提出要求要获取他所代表的涉众的利益。

参与者与用户的关系

用户是系统的使用者，用户是参与者的代表。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。

例子：办公自动化系统：局长是一个参与者，他向系统提供如果审批的要求，但是最终的使用者是他的秘书。

参与者与角色的关系

角色是参与者的职责，是抽象的，从众多参与者的职责抽象出相同的部分，将其命名成一个角色。一个角色代表系统中的一类职责。

例子：办公自动化系统：区长，局长都可以审批文件，审批文件这一职责可以用一个角色来代表，叫做审批者，但是审批者在现实生活中是没有这个角色的

参与者的核心地位

• 参与者是涉众的代表，他代表涉众对系统的利益要求，并向系统提出建设要求
• 参与者通过代理给其他用户或将自身实例化成用户来使用系统
• 参与者的职责可以用角色来归纳，用户被指定扮演哪个或者哪些角色因此来获取参与者的职责
• 系统是以参与者的观点来决定的。参与者对系统的要求，对系统的表述完全决定了系统的功能性
  

用例

在UML中，除了用例之外，其他所有的元素都是封装，独立的。用例使得这些独立的元素交互，没有用例，其他元素就不打交道

基本概念

• 用例就是一个个愿望。比如一个人想要做饭，做饭就是一个用例。 一个个愿望就构成了系统的功能
• 用例就是系统所执行的一个个操作：要完成一件事情，就要做一系列的活动；做一件事情有不同的方法，会遇到不同的情况，因此这件事情是由很多不同情况的集合组成的。这些不同情况就是一个个用例
• 要启动用例是有条件的：要做饭，就要有米，这是前置条件；用例执行完了，就会有一个结果，米变成了饭。这称为后置条件。

总结：用例= 参与者+前置条件+场景+后置条件

用例的特征

• 用例是相对独立的：它是参与者的愿望，不能完整达到参与者愿望的不是用例。

取钱是用例，但是填写取款单不是

• 用例的执行结果对参与者来说是有意义的，而且可以观测到。

参与者要删除数据，系统后台会在删除数据之前备份：删除数据是用例，备份不是用例，因为这是一个后台进行，参与者是看不见的，备份是系统需求的补充制约。

• 用例必须有一个参与者发起。不存在没有参与者的用例。

• 用例必然是动宾短语形式出现的。比如喝水。

一旦决定了用例，软件开发工作的其他活动均已这个用例为中心进行。

用例的粒度

不同需求阶段，用例的粒度不一样。但是用一个需求阶段，所有用例的粒度是一个量级的。

粒度选择的本质上还是因为边界认定不同而产生的。如果对选择粒度感到困难，或者出现了同一个阶段粒度大小不一的情况，先确定边界是否正确，并且检测自己是否越过了边界

用例的获得

前置条件：确定参与者与系统边界

• 参与者是位于系统之外的
• 参与者对系统有着明确的期望和明确的回报要求
• 主角的期望和回报在系统边界之内
  

第二部：访谈业务代表：【注意不是问业务流程】

• 您对系统有什么期望
• 您打算在系统里做些什么事情
• 您做这件事的目的是什么？
• 你做完这些事希望有什么结果。
  
  

用例VS功能

• 功能是一个物品的固有属性，是脱离使用者的愿望存在的，用例是描述使用者的愿望，从使用者的角度出发，说明使用者将在系统中做山脉
• 功能是孤立的，给一个输入，通过计算就会有一个固定的输出—比如说案件开关等酒量。用例是系统性的，描述谁什么情况下通过什么方式开灯结果是什么。
• 用例可以解释为一系列完成一个特定目标的功能的组和，在不同的应用场景中，这些功能有不同的组合方式。先有了场景，然后才有了功能

例子：从功能角度：电视的描述是能开关，显示，调频道，调声音，这几个是独立的。
从用例的角度：电视的描述是一个人要看电视，为了完成这个用例，先打开电视，然后跳到一个频道，如果有必要的话，调节声音。

目标VS步骤

一个用例是参与者对目标系统的一个愿望，为了完成这个事件需要很多步骤，但是这些步骤不是参与者的愿望，不能作为用例。
例子：一个人到邮局寄信。寄信是目标，所以是用例

如果要寄信，可能会有以下步骤

此时步骤不是用例，用例不可能是：一个人到邮局付钱.

但是步骤可以作为用例：在概念建模阶段，由于需求已经捕获，在对需求进行分析的时候，实际上我们已经进入了用例的内部，进入用例的内部意味边界改变了，边界改变了必然导致参与者也会改变。通常，参与者就变成了业务工人，自然，参与者的完整目的也就改变了。此时参与者的所有活动在原来用例的上下文环境内。

寄信和收钱，两个用例大小不同，参与者也不同，就不应该同时出现在一个视图里面，如果出现，就产生了用例粒度的错误

用例粒度的误区

之所以产生用例粒度错误，是因为分不清目标和步骤。
第二个原因是因为：边界没有分清，导致参与者混乱，进而导致粒度不易。边界还决定了哪些信息应该暴露哪些不应该暴露。

边界

业务实体

用于在业务建模阶段建立领域模型

一个好的业务实体不包含关于使用主体和使用方法的信息

• 业务实体在现实生活中有相对应的事物，可能是实物，也可能是概念，

比如：机场中的机票；心理治疗的场景下，患者的情绪

• 业务实体必须至少被一个业务用例使用或者创建，对业务用例场景没有贡献的事务，即使它是客观存在的，也不应该为他建模。

如果去商店购买衣服的场景中，衣架不是业务实体，因为它没有对购买衣服产生贡献。

• 业务实体是类的一个版型，具有对象的所有性质，包括属性和方法，具有对象的独立性，即业务实体只应当包含它本身固有的属性，不能包含外界是如何使用它的信息。

业务实体的属性

• 业务实体可能有很多属性，但是我们只需要关心它与这个场景直接关联的属性抽象视角

比如钱币，在交易的场景下，只需要关心面额，像材质之类的就不需要关心了。

• 属性可能是一个复杂的业务对象：

比如一个银行账户业务实体，它的属性包括定期和活期，定期又包括年限，利率等，那么定期到底是一个属性还是一个作为一个业务实体建模？
一般来说，如果只有一个对象可以直接使用这个属性，或者只能通过对象才能访问到在这个属性，它就应该作为一个属性存在，否则应该当作业务实体单独建模

业务实体的方法

方法规定了外部怎么使用这个业务实体。

在特定的场景下，我们只需要关心哪些与这个场景有直接关系的那些方法

获取业务实体

• 构建业务用例场景：业务用例场景就是参与者实现其业务目标的过程描述
• 从业务用例场景中一个个分析动词后面的名称，它们是业务实体的备选对象：根据对象对业务目标是否有贡献从这些备选中挑出符合的对象
• 分析业务实体之间的关系，并且决定哪些应该单独建模，哪些应该作为属性

参与者是人，用例是事，业务实体就是物

分析类

边界类

两个对象之间交互

控制类

对用例场景中行为的定义【动词】，比如购买衣服：购买就是控制类，业务是业务实体

实体类

实体类是用于必须存储的信息和相关行为建模的类。实体对象用于保存和更新一些现象的有关信息。实体类通常是永久性的，主要位于数据持久层

参见：https://blog.csdn.net/luansha0/article/details/82260678
https://blog.csdn.net/RD_moon/article/details/82895367
https://blog.csdn.net/River_Continent/article/details/79422438