代码改变世界

业务领域建模Domain Modeling

2019-11-24 11:46  cgr  阅读(332)  评论(0编辑  收藏  举报

1领域建模Domain Modeling:

    业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 

2、进行业务领域建模原因: 

  一般说来,我们做一个软件项目基本上都是从需求调研后就到需求建模和需求分析了,没怎么去想业务建模。而大家有没有想过,我们对需求的处理比较表象,如界面、功能和数据,对业务处理过程缺少规范的说明,而这正是开发必须的。你有没有觉得你以前很多开发没有准确反应需求,是否有一个原因,不是需求不清,而是对需求的实现过程不清,即没有了解好业务,从RUP的角度来说,也就是缺少了业务建模这一关键环节。我曾经思索过业务建模最主要解决什么问题,我的看法就是业务建模就是创建业务处理模型,是进行需求分析的依据。而需求分析的结果,将要确定一个开发规范,正确的实现业务处理过程应当是它的一个重要内容,而我们在需求调研时,往往忽视了这一点。 那么,在需求调研中,需求建模与业务建模谁先谁后呢?个人认为,业务是本来就存在的,不管有没有这个软件或项目,它都存在,它都在按一定的模式运作,因此业务建模与需求调研、需求建模是无关的,立项之前业务模型就可以存在. 或是立项以前,业务建模就可以完成的。 然而,实际并非如此,用户只知道如何处理业务,却很少有一个完整的业务模型,当立项时,就需求承建方邦助客户创建它。因为承建方不了解客户的业务过程是不能建模的, 又必须了解客户的业务。   

  对于软件开发过程,从软件工程的角度来说大多数人都清楚从需求调研,到需求建模,需求分析,系统分析,系统结构设计,系统代码设计,系统测试,系统维护这一过程,我参与过的项目,让我感到,有些项目失败或是非常难做,不在于以上这些环节没做好,而在于少了业务的环节。 

3、模型通常由2部分组成: 

      1)元素 
      2)元素间的关系

4、领域建模(Domain Modeling)/业务分析的主要就是: 
    1)寻找业务对象
       2)恰当建立这些对象间的关系 

5、如何进行领域建模  

  1.关注现实世界(问题领域)对象。

  2.使用泛化(is-a)和聚合(has-a)关系来显示对象如何相互关联。

  3将您的初始域建模工作限制在几个小时。

  4围绕问题领域的“关键抽象”来组织您的类。

  5不要将您的领域模型误认为数据模型。

  6.不要将一个对象(代表单个实例)与数据库表(其中包含事物的集合)混淆。

  7.使用领域模型作为项目词汇表。

  8在您编写用例之前,先做一些初始域模型,以避免使用名称歧义。

  9.不要指望您的最终类图精确匹配您的领域模型,但他们之间应该有一些相似之处。

  10.不要在您的域模型上放置屏幕(screens)和其他GUI特定的类。

6、我的工程实践为物联网网关智能分析引擎,本项目通过爬取现有物联网网关供应商的数据或采用现场调研的方式,运用数据挖掘方法对这些数据进行分析,为开发新型物联网设备提供参考与依据。数据分析结果可以包括物联网设备间协议、物联网上传协议、物联网设备的应用场景、设备发展现状与趋势等。类图:

  

 

 7最终画出业务类图,并说明业务类图中每一个类、属性、方法的来源,对于有关联类Association Class的情况要进一步给出关系数据库的模型。