UML复习——领域模型

第三部分 细化迭代1——基础

【小结】细化阶段的制品（不包含初始阶段开始构建的制品）：

①领域模型——领域概念的可视化~~没有方法的类图，不是软件类

②设计模型——描述逻辑设计的一组图，包括软件类图、对象交互图、包图

③数据模型、软件架构文档……

第九章 领域模型（domain model）

目标：确定概念类->创建初始的领域模型->建立属性和关联

【小结】领域模型是图形——使用没有操作的UML类图来表示，不是文本。

在每个迭代中，领域模型都会先定于之前和当前要考虑的场景。领域模型通常开始和完成于细化阶段。

一、一些基础理解

1.定义：领域模型（也称为概念模型、领域对象模型、分析对象模型）是对领域内的概念类或现实世界中对象的可视化表示。

【注】领域模型指的是对现实世界概念类的表示，而非软件对象的表示。

2.领域模型提供了概念透视图，展示了：领域对象或概念类、概念类之间的关联、概念类的属性。

（3）概念类（conceptual class）

通俗地讲是思想、事物或对象。正式的讲可以从其符号、内涵和外延来考虑：

符号：表示概念类的词语或图形

内涵：概念类的定义

外延：概念类所适用的一组示例

3.为什么要创建领域模型？

降低与OO建模之间的表示差异~OO的关键思想：领域层软件类的名称要源于领域模型中的名称。

二、如何创建领域模型

（一）找概念类

法一：重用和修改现有的模型

法二：使用分类列表

通过制作概念类候选列表来开始创建领域模型，并在分析时建立一些优先级。

法三：通过识别名词短语寻找概念类

1.语言分析（linguistic analysis）——在对领域的文本性描述中识别名词和名词短语，将其作为候选的概念类或属性。

~~语言分析适用于详述形式用例中的描述

2.注：不可能存在名词到类的映射机制，并且自然语言中的词语具有二义性——不同名词短语可能表示统一概念类或属性，或者具有歧义。

3. 【注】如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。

e.g.商店在现实世界不会被认为成数字或文本，所以Store应该是概念类

   目的地机场在现实世界不会被认为成数字或文本，所以Airport应该是概念类

（二）描绘概念类

1.使用敏捷建模的思想——绘制类图的草图（让类框的底部和右侧开放状态，如右图）

2.报表对象——模型中是否要包括“票据”？

（1）排除：在领域模型中显示其他信息的报表并没有意义，因为其所有信息都是源于或复制于其他信息源，e.g.收银员何时查看了某件商品的价格。

（2）保留：通常持有票据的人有退货的权利。

3.使用领域术语

（三）描述类description class

1.描述类包含描述其他事物的信息~~项目-描述符（item-descriptor）模式

2.为什么需要描述类？

假设Item表示商店里的实际商品，拥有一个序列号、描述、价格和ID，且假设这些内容不会在任何其他地方记录。同是假设每售出一件实际的商品，响应的Item软件实例就会从“软件领域”删除。比如汉堡店中汉堡全卖完了，那么对应的所有Item实例都会被删除，那如果此时有人问汉堡多少钱，会因为没有Item实例而无法回答汉堡多少钱。

3.故对于上述问题，我们需要ProductionDescription类来记录商品的信息。ProductionDescription并不代表Item，而是表示有关商品的描述信息。

4.何时需要描述类？

（1）需要有关商品或服务的描述，独立于任何商品或服务的现有实例

（2）删除其所描述事物的实例后，导致信息丢失

（3）减少冗余或重复的信息

——————————三、关联association———————

（一）相关概念

1.定义：关联是类（更准确的说，是类的实例）之间的关系，表示有意义和值得关注的连接。在UML中，关联被定义为：两个或多个类元之间的语义联系，涉及这些类元实例之间的连接

2.由于领域模型是从概念角度出发的，所以是否需要记录关联，要基于现实世界的需要，而不是基于软件的需要。

~~如果存在需要保持一段时间的关系 ，则将这种语义表示为关联

3.避免加入大量的关联

4.【注】（1）在领域建模过程中，关联不是关于数据流、数据库外键联系、实例变量或软件方案中的对象连接的语句；关联声明的是针对现实领域从纯概念角度看有意义的关系。

（2）领域模型不是数据模型，添加关联是为了突出我们对重要关系的大致理解，而非记录对象或数据的结构。

（二）关联表示法

1.关联表示为类之间的连线，并冠以首字母大写的关联名称：（一般左->右，从上->下读）

~~关联命名：“类名-动词短语-类名”，动词短语：e.g.has、use。

2.关联的末端可以包含多重性表达式，用于指明类的实例之间的数量关系。

~~多重性（multiplicity）①定义了类A有多少实例可以和类B的一个实例关联。

②多重性的值表示在特定时刻（而不是在某个时间跨度内）有效关联的实例数量（多重性的值见右图）

③多重性的值和建模者和软件开发者的关注角度有关，因为它表达了将要（或可能）在软件中反应的领域约束，即多重性和语境有关。

3.关联本质上是双向的，其每一端称为角色（具有可选项：多重性表达式、名称、导航）。

~~两个类之间可能有多重关联。

4.常见关联列表：

A是与交易B相关的交易；e.g.现金支付­—销售

A是交易B中的一个项目；  

A是交易（或项目）B的产品或服务；

A是与交易B相关的角色；e.g.顾客—支付、收银员—票据

A是B的物理或逻辑部分；e.g.方格—棋盘；座位—飞机

A被逻辑或物理地包含在B中；方格—棋盘；寄存器—商店

A是B的描述；产品描述—商品

A在B中被感知/记日志/记录/生成报表/捕获；e.g销售—寄存器

A是B的成员；e.g.收银员—商店；玩家—游戏

A是B的组织化子单元；e.g.分店—商店

A使用/管理/拥有B；e.g.收银员—寄存器；飞行员—飞机

A与B相邻；e.g.方格—方格；城市—城市

5.例：领域模型中的关联

下图是NectGen POS中的部分领域模型：

—————————四、属性attribution————————

 

（一）定义：属性是对象的逻辑数据值，能够满足当前所开发场景的信息需求。

e.g.在处理销售用例中的票据通常含有日期和时间、店名和地址以及收银员ID等：

Sale需要dateTime属性；Store需要name和address属性；Cashier需要ID属性。

（二）表示

2.导出属性derived property

（1）导出属性指定是可以由其他信息导出的属性。

（2）表示：在属性名称前加一个“/

e.g.收银员收到6包豆腐，那么可以输入一次itemID，然后输入数量6->一个SaleLineItem可以和商品的多个实例关联。收银员输入的数量可以被记录为SaleLineItem的属性，也可以从关联的多重性的实际值计算出来（如下图）

 

（三）数据类型属性与数据类型类

1.大部分属性类型应该是“简单”数据类型，即属性的类型不应该是复杂的领域概念。

~~数据类型（data type）：

①定义：数据类型指的是一组值，这组值的表示本身不具有任何含义（在我们的模型或系统的语境下）。

②对数据类型的等价性检验基于值，而非标识，即如果来年各个数据类型的值相同，那就认为这两个实例是一个个体。

~在Java中，对值的等价性检验用equals方法，对标识符的等价性检验通过“==”。

③e.g.Boolean、Date（或DateTime）、Number、Character、String(Text)、Time；Address、Color、Geometrics(Point、Rectangle)、Phone Number、Social Security Number、Universal Product Code(UPC)、SKU、ZIP或邮政编码、枚举类型。

【注】在领域模型中建议类型主要为数据类型，并不意味着在编程语言中的属性只能是简单的基本数据类型。（因为领域模型是概念透视图，不是软件透视图。）在设计模型中，属性可以是任何类型。

2.应通过关联而不是属性来表示概念类之间的关系。

e.g.（见下图）Cashier类中的currentRegister属性是不合适的，因为currentRegister的类型是Register，并不是简单数据类型（Number或String）。所以应该使用关联而不是属性。

3.何时定义新的数据类型类？

【注】数据类型类不一定被单独画成一个类。

（1）下述情况中，把最初认为是数字或字符串的数据类型表示为新的数据类型类：

①由不同的小节组成，e.g.电话号码、人名；

②具有与之相关的操作，如解析或校验，e.g.社会安全号；

③具有其他属性，e.g.促销价格（可能有开始日期和结束日期）；

④单位的数量，e.g.支付总额具有货币单位；price和amount属性的数据类型应该是Money类（∵它们是货币单位的数量）

⑤具有以上性质的一个或多个类型的抽象，e.g.销售领域的商品标识符是诸如UPS和EAN这样的类型的泛化。

e.g. NectGen POS系统需要itemID属性，可以作为Item或ProductDescription的属性。注：itemID看起来只是数字或字符串，但实际上，商品项目标识符具有子域，应该在领域模型中加入类itemID（或者itemIdentifier），并将这个类作为itemID属性的类型。

（2）到底是在类框中表示数据类型类还是单独画出这个类再与其他类相关联？

 

①e.g.ItemID是数据类型,当它的实例的唯一标识不用于等价性检验时，就可以旨在类框的属性部分中提到这个数据类型类：

②如果ItemID具有属性和关联，那就需要将它表示为单独的概念类：

4.任何属性不表示外键——就是说一个类的属性不应该直接出现在其他类的属性框中，而是应该通过关联表示。

~~外键属性（foreign key attribute）——不能使用

5.对数量和单位建模

（引言）大部分用数字表示的数量不应该表示为纯数字，而应该给这些数量加上单位 ，并且通常还需要知道单位之间的转换关系。

一般，可以把纯数据值表示为Quantity类，并关联到Unit类；Money是一种单位为货币的数量类；Weight是单位为kg或磅的数量类（如下图）

【说明】其中的Money和Quatity和Weight类可以不用单拎出来说明。

 

整理不易，亲亲点个赞呗~~