系统分析与设计——Domain Models II

L10. Domain Models II

Topics

• Domain Model
• How to Create a Domain Model
• Associations
• Attributes
• Iterative and Evolutionary Domain Modeling

---

A conceptual class has a symbol, intension,and extension

Associations

• 类之间的（实例）联结的关系，指示一些有趣且有意义的连接
  
• 在域模型中包括“需要记住”的关联
  • 关联意味着对某种关系的知识需要保留一段时间。
  • 在“大富翁”中，每个棋子在哪里，哪个玩家拥有哪个令牌
  • 无需记住骰子上的数字
• 避免过多； 这增加了通信路径和复杂性

Will the associations be implemented in software? 关联将在软件中实现吗？

• 在域建模期间，从纯概念上看，关联关系在实际域中是有意义的。
• 这些关系中的许多关系将在软件中作为导航和可见性的路径（在设计模型和数据模型中）实现。
• 但是关联不是关于软件解决方案中的数据流，数据库外键关系，实例变量或对象连接的声明；
• 添加了关联以突出我们对值得注意的关系的粗略理解，而不是文档对象或数据结构。

The UML notation for associations 关联的UML表示法

• 关联表示为类之间的一条线。
• 名称具有ClassName-VerbPhrase-ClassName格式。
• 关联的每个末端都称为角色。 角色可以选择具有多重性表示，名称，可导航性。
• 关联本质上是双向的（逻辑遍历）
• 可选的“读取方向箭头”指示读取关联名称的方向
  

Multiplicity on an association 关联的多重性

• 多重性：可以将多少个类A实例与一个类B实例关联。
  • 例如 Store的实例可以与许多（零个或多个）项目相关联
• 这是在特定时刻，而不是随着时间的推移
  

Multiplicity values 多重值

• 多样性值传达了可以在特定时刻而不是在一段时间内将多少个实例有效地与另一个实例关联。
• 一个人在任何特定时刻都只能与另一个人结婚，即使在一段时间内，该人可能已与许多人结婚。
  

Multiplicity is context dependent 多重性取决于上下文

Multiple Associations 多个协会

• 飞向和飞离关联是截然不同的关系，应分别显示
  

Common Associations List

• 使用常见关联列表查找关联

Monopoly partial domain model with Associations 具有关联的垄断部分域模型

Attributes

• 属性是对象的逻辑数据值
• 完整语法：
  能见度名称：类型multiplicity =默认{property string}
• • pi：真实= 3.14159（只读）
• UML中的属性符号
  

When to Show Attributes? 领域模型中何时需要引入属性？

• 包括需求（例如用例）建议或暗示需要记住信息的属性。
• Process Sale用例中的收据（报告销售信息）通常包括日期和时间，商店名称和地址以及收银员ID等。
  • 销售需要dateTime属性。
  • 商店需要名称和地址。
  • 收银员需要一个ID。

Where to Record Attribute Requirements? 在哪里记录属性要求？

• 注意，巧妙地，middleName：[0…1]是一个需求或领域规则，嵌入在域模型中。
• 尽管这只是概念上的领域模型，但它可能暗示软件角度应允许UI，对象和数据库中的MiddleName缺少值。
• 我建议将所有这些属性要求放在UP词汇表中，该词汇表用作数据字典。
• 另一个选择是使用将UML模型与数据字典集成在一起的工具； 然后所有属性将自动显示为字典元素。

Derived Attributes 派生属性

• 您可以在名称前用/表示派生属性
  

Attribute Types 属性类型

• 通常是原始数据类型，以及诸如Color，DateTime，Zip代码等之类的数据。
• 通常不应该是课程，例如Sale或Airport
• 用关联而不是属性来关联概念类。 没有代表外键的属性
• 代码中的属性可以
  

When to Define New Data Type Classes? 什么时候Attributes可以是类

• 尽管看起来像ItemID或ClaimNumber之类的东西并不总是简单的数据类型
• 它可以是自己的类：
  • 如果属性包含可分离的片段。
    例如，“索赔编号”中已编码了州，年份和日期
  • 是否具有与其关联的操作
  • 是否具有其他属性，例如售价
  • 如果有单位，例如货币
  • 如果是具有这些属性的一种或多种类型的抽象

Where to Illustrate These Data Type Classes? 在哪里说明这些数据类型类？

• 是否应该在域模型中将ItemID类显示为单独的类？ 这取决于您要在图中强调什么。
• 两种方法来指示对象的数据类型属性。
  

No Attributes Representing Foreign Keys 没有代表外键的属性

• 属性不应用于在领域模型中关联概念类。
• 最常见的违反此原理的方法是添加一种外键属性，以关联两种类型，这在关系数据库设计中通常如此。
• 使用关联而不是属性来关联类型。
  

Quantities with Units 有单位的量

• 大多数数字量不应以纯数字表示。
• 用与之相关联的单元代表不同的类
• 显示数量专长。 货币是一种数量单位为货币的数量。 重量是指以千克或磅为单位的数量
  

Monopoly partial domain model 垄断部分域模型

Is the Domain Model Correct? 域模型正确吗？

• 不，但这是一个很好的近似值
• 每次迭代都会变得更好； 不要试图一次全部获得
• 领域模型通常在阐述阶段完成

Iterative and Evolutionary Domain Modeling 迭代和进化领域建模

Inceoption 起始时间

• 领域模型在开始时并没有强烈的动机，因为开始的目的不是进行认真的调查，而是确定项目是否值得在精化阶段进行更深入的研究。

Elaboration 细化

• 域模型主要是在精心设计的迭代过程中创建的，这时最需要了解值得注意的概念并将一些概念映射到设计工作中的软件类。

Iterative and Evolutionary Domain Modeling 迭代和进化领域建模

• 在迭代开发中，我们通过多次迭代来逐步扩展域模型。
• 在每个迭代中，领域模型都限于所考虑的先前和当前场景，
  • 与其扩展到“大爆炸”瀑布式模型，而是尽早尝试捕获所有可能的概念性类和关系。

迭代和进化领域建模

UP中的领域模型