前言
简单整理一下领域模型。
正文
领域模型是对领域内的概念类或现实中的对象的可视化表示
领域模型也称概念模型、领域对象模型和分析对象模型
领域模型是可以在业务建模科目中创建的制品之一
领域模型是up业务对象模型的特化。
领域模型在软件设计图的关系:
一开始是梳理需求，写出用例文本，建立用例模型。
然后领域模型是业务模型的一环，领域模型通过用例模型抽取出概念类、术语、概念、属性、关联。
当在业务模型中建立了领域模型之后，反过来丰富了用例模型，多了些操作契约。多了契约操作的话，那么可以以此来编写顺序图。
在uml中，领域模型被描述为一组没有定义操作的类图。
值得注意的是领域模型不是在设计阶段，不要带软件中的设计或者数据库设计。
现实中的思想，事务或者对象。关注现实世界，而非软件对象。
领域模型创建的步骤:
- 寻找概念类
- 绘制UML类图
- 加关联属性
如果寻找概念类?
- 重用修改现在的模型
- 常见分类列表
- 名词短语(从详述用例)
什么是概念类:
概念类是思想、事物或对象。更正正式地讲，概念类可以从其符号、内涵和外延来考虑。
举个例子:
领域模型和数据模型是一回事吗？
- 领域模型不是数据模型(持续化数据)
- 在领域模型中不会排除没有明确要求记录其相关信息的类，也不会排除没有属性的概念类
- 在领域内充当纯行为角色，而不是信息角色的概念类也是有效的
动机: 降低与oo建模之间的表示差异
例如:
面向对象开发者在创建类时收到真实世界领域的启发
因此，涉众所设想的领域与其在在在软件的表示之间的表示差异被降低。
准则： 像地图绘制者一样思考：使用领域术语
- 使用地域中现有的名称。在图书馆模型中，将顾客命名为”借书者”、”赞助者”等，这是图书管理员使用的术语
- 排除无关或超出范围的特性
- 不要凭空增加事物
准则： 如何对非现实世界建模
- 有些软件系统的领域与自然领域或业务领域几乎没有类似指出，例如：电信软件
- 此时需要高度的抽象，对常见的非00设计进行回顾，并认真汲取领域专家所使用的核心词汇和概念
- 例如，电信软件的候选概念类：消息、连接、端口、会话、路由、协议
准则： 属性与类的常见错误
常见错误： 把应该是概念类的事务表示属性
判别准则： 如果我们认为某概念X不是现实中的数字或者文本，那么x可能是概念类而不是属性。
准则： 何时使用”描述”类建模
描述包含描述事物的信息：如productDescription 记录Item的价格、图片和文字描述。
命名方式：项目-描述符
- 描述有关商品或服务的描述，独立于任何商务或服务现有实例
- 删除所描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误低于所删除的事务关联起来
- 减少冗余或重复信息
关联:
关联是类之间的关系，表示有意义和值得关注的连接。
在uml中，关联被定义为”两个或多个类之间的语义联系”，涉及这些类元实例之间的连接。
观点：关联是否在软件中实现
- 在领域建模中，关联不是关于数据流、数据库外键的联系、实例变量或软件方案的对象连接语句；
关联声明是针对现实领域从纯概念角度看有意义的关系 - 这些关系的大部分作为导航(设计模型和数据模型中的)和可见性路径再软件中加以实现。
结
下一节顺序图
原文地址：http://www.cnblogs.com/aoximin/p/16930400.html
