2B系统需求建模工具(下之类图)

时间:2021-6-12 作者:qvyue

在业务流程中会涉及许多业务实体,了解问题域有哪些业务实体、它们之间存在什么样的逻辑关系、数量关系、有什么结构规则,这些工作就是“领域建模”

业务实体分析设计两种可选的模型:类图和E/R图「实体关系图」,本篇以类图为主。

类图是UML中十分重要的图,用类和对象表示现实世界,用消息和方法模拟现实世界。

类的表示法

类是对一组具有相同属性、操作、关系和语义的对象的描述,一个类的关键特性是属性「成员变量」和操作「成员方法」,

2B系统需求建模工具(下之类图)

关系和语义则是在此基础上的表现。

2B系统需求建模工具(下之类图)

在初步发现类的过程中,可以先把需求描述中所涉及的所有名词或名词短语列出来,再过滤掉对系统来说无关紧要的、归纳名词概念较小的,同时也了解问题域的建立概要。

需求建模时,可以果断尝试用中文命名

类的关系

关联关系提供了两个类之间的通信路径,是所有关系中最通用、语义最弱的关系。一条实线来表示。

泛化关系描述一般事物与该事物中的特殊种类之间的关系,继承关系是泛化关系的反关系。是父类与子类的关系,也就是说子类是从父类中继承,父类则是子类的泛化。

聚合关系表示整体与部分的关系,“部分”是可以独立于“整体”而存在。

组合关系亦是整体与部分的关系,但“部分”类的存在完全依赖于“整体”类,没你不行的那种。

打个比方,平板电脑和键盘 vs 键盘和按键。

需要注意的是整体/部分是整合关系或者组合关系需要从业务规则的角度来思考!

2B系统需求建模工具(下之类图)

在UML模型中,20%的建模元素就能应对80%的应用场景,特别是对于需求建模而言。需求阶段的类建模应尽可能保持简单,避免引入过多的可能降低可读性的辅助建模元素。

遵循“拒绝实现细节、大类不拆分、小类不合并、同类不抽象、忠于问题域”的原则。

领域建模是自底向上的过程,先描绘出领域类的片段,再抽象、提炼、汇聚成全局领域模型。

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:qvyue@qq.com 进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。