细说UML核心元素
文章目录
基本知识
功能性需求、非功能性需求
功能性需求：一定有参与者(主角)
非功能性需求：找不到参与者涉众、参与者、用户
涉众：与要建设的这个系统有利益相关的一切人和事。
参与者是涉众的代表，用户是参与者的代表；
角色：
参与者的职责，从众多参与者职责中抽象出相同的那部分，将其命名。
用例
特征：
相对独立，即不需要与其他用例交互而独自完成参与者的目的； 执行结果对参与者来说有意义，可观测。Eg：登陆系统<->填写密码; 参与者发起； 动宾短语； 一个用例就是一个需求单、分析单元、设计单元、开发单元、测试单元、部署单元。【用例驱动】粒度：
业务建模阶段：可以说明一件完整的 事情 为宜； 用例分析阶段(概念建模阶段)：可以描述一个完整的 事件流 为宜。 简言之，可以描述一个完整业务中的一个 步骤； 系统建模阶段：因视角是针对计算机的，故能够描述操作者与计算机的一次交互为宜； 简言之，一个操作界面或一个页面流。用例和功能区别：
用例：从人的角度；面向对象 功能：从计算机角度；面向过程；其描述缺乏上下文环境，一些功能根本没有人会用到； 对于不存在的事物，我们无法从结构和功能上描述，只能用使用者的观点来描述；总结：
功能是脱离使用者愿望而存在的； 功能是孤立的，给一个输入，通过计算就有一固定的输出；用例是系统性的工作，即谁在什么情况下通过什么方式做什么， 结果(愿望)是什么； 用例可以看成是 一系列功能组合来完成一个特定的目标，针对不同场景，组合方式不同。 Eg：电视 功能：能开关，能显示，能调频道，调声音； 用例：我要看电视节目，要完成这个愿望： 1、开电视； 2、调频道； 3、声音不合适，可以调声音；
业务用例：
概念用例：
- 概念用例用来获取业务用例中的核心业务逻辑。
- 概念用例是业务用例到系统用例（即我们天天挂在嘴边的用例）过渡时非常重要的指导。
[系统]用例：
- 即我们天天挂在嘴边的用例;
- 用来定义系统范围，获取功能需求的；
- 简言之，软件系统开发的全部范围，我们得到的最终需求。(系统视角)
[系统]用例实现：
- 参照上面“业务用例实现”
- 连接起用例模型和系统实现之间的桥梁。
业务实体
- 来自现实世界的；
- 业务用例场景中使用的事物；
- 类的版型，具有对象所有性质。
业务实体属性：
面向对象方法中抽象视角的体现
业务实体方法：
面向对象方法中抽象视角的体现，
简言之，属性，方法很多，我们只关心特殊场景(用例)下与这个场景直接关联的属性和方法。
简言之，参与者代表人，用例代表事，业务实例代表物；
包
- 一种容器，如文件夹，将信息分类，形成逻辑单元。
- 可以容纳任何UML元素；
Eg:用例、业务实体、类图、子包； 分包的好(高内聚低耦合)坏(双向依赖和循环依赖)评判标准是包之间的依赖关系；
包之间的关系也只有依赖关系；
领域包
分类业务领域内的业务单元，每个包代表一个领域
子系统
分类系统内逻辑对象并形成子系统
组织结构
分类业务领域中组织结构
层
分类软件中的层次
分析类(架构角度)
- 分析类代表系统中主要“职责簇”。简言之，是从功能性需求向计算机实现转化过程中的“第一个关口“
- 可以产生系统的设计类和子系统。简言之，系统可以通过某种途径“产生出来”，不是拍脑袋拍出来的。
- 简言之，跨越需求阶段到设计实现的桥梁。
特点：
- 高于设计实现：
不理会复杂的设计要求，Eg:设计模式、框架； - 高于语言实现：
不理会编程语言； - 高于实现方式：
不理会具体实现方式，Eg:安全认证，实现方式有：LDAP,CA,JAAC等。
边界类
用于展现层(架构角度)
控制类
用于业务逻辑层(架构角度)
实体类
用于持久层(架构角度)
设计类
对应的对象取决于编程语言；
简言之，就是编程语言中具体的类；
关系
关联
- 静态关系，由“常识”、“规则”、“法律”等因素决定
- A————————B，双方都知道对方的存在
- 特别的，用例模型中，参与者——>用例
- 体现在代码里：实例变量(成员变量)
依赖
- 临时，动态关系
- A- - - - ->B (A依赖于B)
- 体现在代码里：类构造方法、类方法等的传入参数；
扩展
<<extend>>
- A– – – – – – – - ->B ( A扩展出B)
- 用于在用例中项目基本用例中的某个扩展点插入扩展用例；
- 可选；
- 特定条件下发生；
包含
<<include>>
- A– – — – – – – ->B ( A包含B)
- 分解出两个或更多个用例共有的行为。
扩展，包含区别：
* 扩展“可选”，包含“必须”；
* 没有扩展用例，基本用例完整；
* 没有包含用例，基本用例不完整；
* 没有基本用例，扩展用例和包含用例均不能单独存在；
实现
- A– – – – – –▷B (A实现B)
- 用例和用例实现间用这种关系；
精化
<<refine>>
- A– – – – – – – –>B ( A精化了B)
- 设计类精化了分析类
- 基本用例可以分解出许多更小的关键精化用例，这些精化用例更细致展现了基本用例的核心业务；
泛化
- A————————▷B ( A继承了B)
- 建模过程中任意阶段均可使用；
精化、泛化区别：
* 精化表示由基本对象可以分解为更精确、精细的对象，这些子对象没有增加、减少、改变基本对象的行为和属性，只是更加细致和
明确了；
* 泛化表示由基本对象泛化的子对象继承了基本对象的所有特征，且可以增加、改变基本对象的行为和属性；
聚合
- A————————♢B ( A聚合到B,B由A组成)
- 用于类图，特别表示实体对象间关系；
- 表达整体由部分构成
组合
- A————————♦B ( A组合成B，B由A构成)
- 用于类图，特别表示实体对象间关系；
- 表达整体拥有部分
- 特别强调：Rose中用 <——————◇ 表示；
聚合、组合区别：
* 聚合：整体部分 “弱依赖”，整体不存在了，部分仍然存在；Eg:部门撤销后，人员依然存在；
* 组合，整体部分 “强依赖”，整体不存在了，部分将消亡 ；Eg:母公司解体，子公司也破产；
组件
- 组件是系统中实际存在可更换的部分，它实现特定的功能，符合一套接口标准并实现一组接口;
- 代表系统中一部分物理实施，包括软件代码(源代码、二进制代码)或其等价物(脚本或命令文件);
特征
完备性
包含的一些类和接口，一个组件能独立完成一项特定的业务目标；
从调用者观点出发：不需调用多个组件来完成一个业务请求；独立性
组件间是松耦合的；
逻辑性
从软件构件设计的观点来定义的，并非从需求中可直接导出；
透明性
组件的修改应当涉及组件的定义以及组件中包含类的重新指定，而不应该导致类的修改；
节点
- 至少有一个处理器、内存以及可能还带有其他设备的处理元素；
- 实际生活中，服务器、工作站、客户机都可以作为节点；
- 应用于部署视图
- 应用：分布式应用环境、多设备应用环境
参考资料：《Thinking in UML》(大象书)
