业务领域建模Domain Modeling

标签：实现   code   class   系统设计   div   识别   情况   其它   pts   

1. Concepts

1.1 领域模型概念

领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。

业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

软件开发过程：业务建模、需求、分析、设计

1.2 领域模型作用

• 分析如何满足系统功能性需求。
• 指导项目后续的系统设计。

1.3 如何领域建模

领域模型如此重要,很多同学可能会认为领域建模很复杂,需要很高的技巧。事实上领域建模非常简单,概括一下就是“找名词”! 

一个关键的问题还没有说明:从哪里找? 如果你还记得领域模型是“需求到面向对象的桥梁”,那么你肯定一下子就能想到:从需求模型中找,具 体来说就是从用例中找。 

归纳一下域建模的方法就是“从用例中找名词”。 当然,找到名词后,为了能够更加符合面向对象的要求和特点,我们还需要对这些名词进一步完善,这就 是接下来的步骤:加属性,连关系! 

最后我们总结出领域建模的三字经方法:找名词、加属性、连关系。 

A. 发现类和对象：尽可能多的找出概念类（识别方法：概念类分类列表、名词性短语）

a.概念分类列表：人、事物、地点、组织、概念、事件、规则、抽象名词、交易项目、角色、设备、组织结构（对用例进行识别：实体、过程中的信息、角色的输入输出、操作设备等）

b.名词分析法：识别问题域和用例描述中的名词和名词性短语作为候选的概念类和属性，从候选项中，摒弃多余的名词，确定最终的对象（注意是作为类还是属性，类可以是一种标识、状态和行为）

B. 建立类之间的关联（关联、继承、依赖）

关联：类之间的某种语义关系包括聚合，组合

继承：一般到特殊

依赖：表明一个元素（源元素）的定义或实现依赖另一个元素（被依赖元素）的定义或实现

C. 添加类的重要属性（类的语义完整性、类的作用、问题域相关特性等）

a.语法：可见性 属性名：类型 多重性=默认值{特性表}  

       /  [可见性] 属性名 [：类型] [=初始值]

b.属性类型是简单的数据类型为佳，如果是复杂概念，考虑是否单独作为一个概念类

c.任何属性都不表示外键，即不应该用属性来联系概念类，区别于数据库设计中的外键

2. important concepts in domain modeling

2.1 界限上下文

界限上下文是一个显式边界.在边界内,通用语言中的所有术语和词组都有特定的含义,而模型需要准确地反映通用语言.

2.2 聚合根

  对领域概念做静态建模的时候，有一类概念被视为聚合根(root)。它有自己的生灭过程，数据和行为聚合于其上，有一个唯一的ID可以表征自己并且可以索引到自己的数据。聚合根表征的是一个实体，但并非所有的实体都应该抽象成聚合根(有些可能应该抽象为注入的数据或者一条待处理的消息)。聚合根可以多种类型，且之间可以构成层级关系(或其它关系，如网状或别的什么情况，层级关系自然最简单)。

 

3 UML图表

业务领域建模Domain Modeling

标签：实现   code   class   系统设计   div   识别   情况   其它   pts   

原文地址：https://www.cnblogs.com/zhanxyu/p/11922441.html