在业务流程中会涉及许多业务实体，了解问题域有哪些业务实体、它们之间存在什么样的逻辑关系、数量关系、有什么结构规则，这些工作就是“领域建模”。
业务实体分析设计两种可选的模型：类图和E/R图「实体关系图」，本篇以类图为主。
类图是UML中十分重要的图，用类和对象表示现实世界，用消息和方法模拟现实世界。
类的表示法
类是对一组具有相同属性、操作、关系和语义的对象的描述，一个类的关键特性是属性「成员变量」和操作「成员方法」，
关系和语义则是在此基础上的表现。
在初步发现类的过程中，可以先把需求描述中所涉及的所有名词或名词短语列出来，再过滤掉对系统来说无关紧要的、归纳名词概念较小的，同时也了解问题域的建立概要。
需求建模时，可以果断尝试用中文命名。
类的关系
关联关系提供了两个类之间的通信路径，是所有关系中最通用、语义最弱的关系。一条实线来表示。
泛化关系描述一般事物与该事物中的特殊种类之间的关系，继承关系是泛化关系的反关系。是父类与子类的关系，也就是说子类是从父类中继承，父类则是子类的泛化。
聚合关系表示整体与部分的关系，“部分”是可以独立于“整体”而存在。
组合关系亦是整体与部分的关系，但“部分”类的存在完全依赖于“整体”类，没你不行的那种。
打个比方，平板电脑和键盘 vs 键盘和按键。
需要注意的是整体/部分是整合关系或者组合关系需要从业务规则的角度来思考！
在UML模型中，20%的建模元素就能应对80%的应用场景，特别是对于需求建模而言。需求阶段的类建模应尽可能保持简单，避免引入过多的可能降低可读性的辅助建模元素。
遵循“拒绝实现细节、大类不拆分、小类不合并、同类不抽象、忠于问题域”的原则。
领域建模是自底向上的过程，先描绘出领域类的片段，再抽象、提炼、汇聚成全局领域模型。
网友评论