本文探讨了UML中的包和类的概念，包括包的类型、原则及其在系统设计中的应用，同时介绍了分析类的性质与类型，如边界类、控制类和实体类等。
之前的文章
包
- 概念：包像文件夹将信息分类形成逻辑单元
-
原则：
- 被分入同一个包的元素相互联系紧密，不可分割，也就是说它具有高内聚性
- 包的理想状态的修改ABC包中的一个包，另外的包不受到影响，也就是ABC三个包之间没有依赖/耦合关系，他们之间可以保持通信。
- 包之间的依赖关系应是单向的，避免双向依赖和循环依赖
-
双向依赖：
A依赖于B，B依赖于A这种情况就是双向依赖 -
循环依赖
A依赖B ,B依赖C,C依赖A这种情况就是循环依赖。
简单描述就是他们的依赖能够成为一个闭环，就像三角恋一样（在本个例子中） -
依赖传递
依赖传递，A=B,B=C则A=C，这种情况下就是传递依赖。
自我理解类似于等价互换，但是如果有一个例子说A认识B，B认识C，那么说明A认识C，这个例子是不对的，因为A并不一定认识C，所以这种不能说明依赖传递。
-
-
包的版型
-
领域包
- 用于分类业务领域内的业务单元，每个包代表业务的一个领域
- 可用于展示业务领域的高层次关系–XX业务领域
-
子系统
- 用于分类系统内的逻辑对象
- 用于展示系统的高层次逻辑结构系统–XX子系统
-
组织结构
- 用于分类业务领域中的组织结构
- 直接表达企业的组织结构–例如XX部门
-
层
- 展示软件的架构信息
-
-
分析类
-
性质
- 分析类代表系统中主要的职责簇了，分析类是从功能需求像计算机实现转变的第一个关口
- 分析类可以产生系统的设计类和子系统
-
分析类抽象层次的特点
- 高于设计实现
- 考虑系统实现可以不理会复杂的设计要求，先做到需求实现
- 高于语言实现
- 在为需求考虑系统实现的时候可以不理会使用哪种语言编写
- 高于实现方式
- 在为需求考虑系统的实现，可以先不考虑采用哪一种具体实现的方式
总结：先实现，排除一些条条框框，先实现
- 类型
-
边界类
-
概念
用于对系统外部环境与其内部运作之间的交互进行建模的类。 -
应用场景
- 参与者和用例之间应建立
- 用例与用例交互
- 用例与系统边界之外的非人对象交互–第三方系统
- 相关联的业务对象由明显的独立性要求
-
特点
- 边界类应该有助于提高系统的可用性
- 边界类应该尽可能保持在较高的层次
- 边界类应该据合理封装，介于系统与主角之间的交互
- 主角如果改变系统/主角提供的输入方式，那么只需要改变边界类即可
- 边界类必须知道其他对象类型的需要，一遍他们能够得以实施，并相对于系统内部元素保持其可用性和有效性
-
-
控制类
-
概念
用于对一个或几个用例所特有的控制行为进行建模。 -
来源
来源于对用例场景中动词的分析和定义，包括限制动词的描述
例子：像送一个明信片给朋友我们需要做什么呢？首先我们需要购买明信片，写上祝福，将明信片封装好，送出明信片。那么在这个过程中。购买，写，封装，送出都可以作为控制类的来源。
-
- 高于设计实现
-
实体类
-
实体对象
概念
实体类是用于对必须存储的信息和相关行为建模的类。 -
实体对象
实体对象用于保存和更新一些现象的有关信息
实体类通常是永久性的
-
设计类
-
概念
- 在系统实施中一个或多个对象的抽象
- 设计类对应的对象取决于实施语言
- 设计类由类型、属性、方法构成 -
类
-
来源
用例实现对系统所需对象的需求 -
类做啥子
- 说明了对象是什么同时也决定了对象拥有什么属性，具体的方法
- 类是对象某一方面特征的归纳和抽象，对象则是类实例化的结果
例子：公交车、越野车、跑车从用途可以归结为交通工具，那么公交车、越野车、跑车是交通工具的一个实例。
-
属性
- 属性是对象的特征，表示了对象的唯一性
-
方法
- 访问对象或影响其他对象的属性/关系的唯一途径就是方法
- 方法的作用就是访问和改变对象的属性
- 一个对象的属性只应该由它自己的方法来改变
-
可见性
-
公有
- 除类本身，属性和方法对其他模型也可见
-
私有
- 属性和方法只对类本身和类的友元可视
-
保护
- 属性和方法只对类本身、它的子类、友元可视
-
实施
- 属性和方法只在类本身的内部是可视的
-
-
关系
- 用处
- 抽象了与对象的关系
- 类型
- 关联关系
- 依赖关系
- 扩展关系
- 实现关系
- 精化关系
- 泛化关系
- 聚合关系
- 组合关系
扫一扫
490
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
