业务领域建模

Posted 2020-11-22 ustc314

一、业务领域建模的要求

1.收集应用领域信息

-关注功能需求-也考虑其他需求和文档

2.头脑风暴

-列出重要的应用领域概念-列出它们的属性/属性-列出它们之间的关系

3.将业务领域概念分类

-类-属性/属性值-关系

4.关联、继承、聚合

阐述了UML类图对结果的文档化

二、领域建模的十大方法

1.关注现实世界（问题领域）对象。

创建领域模型时，请确保将问题领域与实际对象集中在一起。 尝试着围绕现实世界来组织软件架构。 现实世界往往比软件需求变化要小。下图显示了两种不同类型的类符号。在完整的详细类图上，将使用左侧的版本，其属性和操作。然而，在初始领域建模过程中，分配类的这些部分为时尚早。最好使用右边所示的简单符号。此版本仅显示领域类的名称。

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

随着时间的推移，会使用新的领域类别来识别领域模型。会注意到他们之间的联系（或关联） - 例如，书评属于书，采购订单（purchase order）和信用卡（credit card）是两种，因为它们都是付款类型。
第一个关系（书评属于一本书）被称为聚合（has-a，因为一本书都会有一书评）。第二个关系（采购订单和信用卡都是付款类型）被称为泛化（is-a，因为采购订单是付款类型）。图2-3显示了这些概念的说明。

这些所谓的一般关系是领域模型中最重要的关系。可以使用聚合和泛化关系建模模型的类关系中的百分之九十五。尽可能不要使用“关联”，使领域模型从左到右和从上到下阅读，就像普通文本一样。 这将提高图表的可读性。

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

一开始做的领域建模可能是在项目上花费的最重要的两个小时！ 在这两小时的头脑爆发期间，可能会发现80％的域名类。如果可以将80％的领域名词汇消除歧义，那么花费两个小时。

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

绕在领域问题中的的”关键抽象“ 组织类通常是一个很好的做法。请记住，领域模型是一个先进的类图，成为软件架构的基础。这使得模型面对变化更有弹性。围绕现实世界的抽象组织架构使得模型在面对不断变化的需求方面更有弹性，因为需求通常会比现实世界更频繁地变化。

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

即使这些图可能相似，但请记住，数据模型的良好做法在类图上可能不是良好的做法（反之亦然）。 类很小，表比较大。关系数据库中的表通常涉及许多事情。相反，如果它是一个相对较小的数据和行为（方法）包，则用类去设计会更好。

在类图中，可能会有一个管理数据库表的类，可能会显示一些聚合常规域类的TableManager类。这TableManager类型类的目的是从代码库的其余部分隐藏数据库管理系统（DBMS）的详细信息。

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

一个对象代表一个单一的东西。数据库表表示事物的集合。您不必像企业JavaBeans（EJB）世界中的文字一样，实体bean通常表示表中的单个行。领域类是相似的。如果你调用一个领域类图书，那么并不意味着书表（数据库里面没），而是是一本书。数据库表中的列通常映射到类上的属性。
但是，数据库表通常包含比包含属性更多的列（表通常具有外键作为一个示例），因此表行和对象之间可能没有直接的1：1映射。

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

如果模糊的要求（二义性）成为了你的敌人，那么领域模式就是第一道防线。“项目领域主题专家”对名称的二义性命名和使用是非常普遍但却是非常有害的（对同一个词汇有不同的叫法）。领域模型应作为项目词汇表，有助于在描述问题空间时确保术语的一致使用。使用领域模型作为项目词汇表是消除模型歧义的第一步。在Doug教授的每一个Jumpstart教学中，他发现至少有两到三个领域名类，其中学生使用不明确的名称（例如“购物车shopping cart,””，“购物篮shopping basket”或“购物车shopping trolley”）。

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

由于使用域模型来消除问题领域的抽象，因此使用不明确的术语编写用例来描述域类是很愚蠢的。因此，在编写用例之前，请花两个小时在领域模型上工作。编写没有域模型的用例将所有内容绑定在一起存储很多问题以供以后使用

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

随着设计的进行，类图将比域模型更加详细；域名模式故意保持相当简单。在设计（使用序列图）时，详细的设计构造（如GUI帮助器，工厂类和基础架构类）将添加到类图中，领域模型图几乎可以分解成几个详细的类图。然而，仍然可以将大多数类追溯到等效的领域类。

1.不要在域模型上放置屏幕（screens）和其他GUI特定的类。

这样做会打开潘多拉的盒子，并导致一个拥挤的领域模型，其中包含许多实现特定的细节。性能优化类，助手类等也应该保留在域模型之外。领域模型应该只关注问题领域。

三、我的工程实践最终建模图

工程实践描述：在输入视频流中使用3D建模软件进行头部建模，实施捕捉头部的动作和表情变化，并将视频流中的数据进行实时的动画重定向，使得可以呈现出虚拟人偶的形象