可视化领域模型

可视化领域模型可视化领域模型

什么是领域模型概念类识别和提取概念类创建领域模型步骤几个问题命名概念类或属性?相似概念问题为非现实世界建模不同视角的模型什么是领域模型用例：用例是一个重要的需求分析工件，但它并不是面向对象的它们强调领域的过程视图领域模型OOA中创建的最重要的制品领域模型领域模型显示问题领域中对建模者有意义的概念类

OOA中创建的最重要的制品识别大量对象或概念类——面向对象分析的核心工作领域模型表达的是现实世界中的概念类，而不是软件构件（不是软件类或带有职责的软件对象）识别概念类是问题域调查的一部分UML中的类图可以显示领域模型领域模型领域模型是概念类或问题领域中实际对象的可视化表达，又称为：概念模型领域对象模型分析对象模型领域模型使用UML表示法，领域模型用一组不带操作的类图来表示，可显示：领域对象或概念类概念类之间的关联概念类的属性部分领域模型——一个可视化字典领域模型——抽象的一个可视化字典领域模型将领域中的单词、概念类可视化，并将其相互关联(比文字更容易阅读)领域模型显示了视图或抽象的一部分，而将建模者不感兴趣的细节忽略。创建领域模型同时有助于澄清领域中术语和词汇——可视化字典领域模型不是软件组件的模型领域模型是现实世界问题领域中事物的可视化，而不是软件构件的可视化不是软件制品——如窗口或数据库不带有职责和方法领域模型——显示现实世界的概念领域模型——避免软件制品或类概念类概念类是思想、事物或对象可以从以下几方面理解概念类：符号代表概念的单词或图像内涵概念的定义外延概念所应用于的例子的集合概念类一个概念模型有一个符号、内涵和外延概念类当我们建立一个概念模型时，通常，概念类的符号和内涵视图最具有实用价值。识别领域中的概念类Store,Register,Sale过度指定领域模型（带有大量细粒度的概念类）比不足好(越多越好）开始常会遗漏，在后面考虑属性、关联以及在设计阶段时，发现遗漏可随时补充不要仅仅因为这些简单的原因就排除掉一个概念类概念类没有属性需求中没有明显地要求保留一个概念类的信息识别领域中的概念类技巧用概念类种类列表识别名词短语使用分析模式概念类的分类列表概念类的分类列表识别名词和名词短语主要的成功场景（或基本流程）：1.顾客携带商品或购买服务到POS机前结账。2.收银员开始一项新的销售。3.收银员输入商品的标识。4.系统记录卖出的商品并出示商品的描述、价格和累加值。价格是依据一系列定价规则来计算的。收银员重复步骤3～4直到结束输入。5.系统提供计税后的总金额。识别名词和名词短语6.收银员告诉顾客应支付的总金额并要求顾客支付。7.顾客支付，系统处理支付。8.系统记录整个销售并且把销售和支付信息发送到外部的记账系统（为记账和提成）以及库存系统（用于更新库存）9.系统出示收据。10.顾客携带收据和商品（如果有的话）离开。识别名词和名词短语用例是通过名词短语识别领域概念的丰富源泉注意:不同的名词短语可能代表同一个概念类或属性，其中可能会有歧义自然语言的不精确性推荐词义分析的方法与概念类分类的技术一起使用识别名词和名词短语这些名词短语中的一些是候选的概念类一些可能是本次迭代忽略的概念类（例如，“记账”和“提成”）一些可能是概念类的属性销售领域的候选概念类Register ItemStoreSalePaymentProductCatalogProductSpecificationSalesLineItemCashierCustomerManager报表对象——模型包括收据吗？

收据是销售的报表。一般地，如果收据的所有信息都可以从其他信息源导出，那么在领域模型中表示收据就没有什么用处收据在业务规则中充当一个特殊的角色：收据持有者通常有权以收据为凭证退货。这是领域模型应该包括收据的一个理由。本次迭代未考虑退货，因而不包括Receipt，处理HandleReturns的迭代中再考虑怎样建立一个领域模型列出候选概念类在领域模型中画出候选概念类添加关系添加属性事物的命名以及建模：地图绘制员地图绘制员策略以地图绘制员策略建立领域模型:

使用地域中已有的地名排除不相关的特性(地形图，人口分布)

不添加不属于某个地方的事物原则也可以是已命名的“使用领域词汇”策略在识别概念类时的常见错误将应该作为概念类的当做属性----规则：若在现实世界中我们不把X当作数字或文本，则X可能是概念类而不是属性在识别概念类时的常见错误如果我们对此举棋不定的话，最好将这样的事物当做一个单独的概念类来处理。在领域模型里，属性相当少见。解决相似概念——Register和POST用于记录销售和支付的物品Register登记簿:用于记录销售和支付的工作簿收银机需要一个广泛的意义POST:销售终端POST代表销售终端。在计算机的术语里，终端表示系统中的任何端点设备，如客户机PC、无线网络的PDA等。解决相似概念——Register和POST解决相似概念——Register和POST作为一个规则，领域模型没有绝对正确或错误之分，只有可用性大小的区别，它是交流信息的工具。解决相似概念——Register和POST登记簿Register和POST功能一样Register更抽象，POST更面向实现根据绘图员原则，“POST”是领域中常见的术语——POST好，易于交流从模型的目的：抽象，实现独立——选用Register更好为非现实世界建模与电信交换机相关的一些候选概念类如下：消息（Message）、连接（Connection）、端口（Port）、对话（Dialog）、路由（Route）、协议（Protocol）规格说明或描述概念类在许多领域模型中，对概念类（如定义它一样）做规格说明的需求是相当普遍的规格说明或描述概念类商品ItemItem具有price,anditemID,没有在其他地方记录物理商品被卖出，软件实例即删除cup1,cup2,cup3,…全部售完，则没有了cup的记录，--Cup多少钱?—无法回答事务的规格说明或描述规格说明或描述概念类的需要ProductSpecification（或者ItemSpecification、ProductDescription，等等）概念类，用来记录有关商品的信息并不表示一件商品，它表示商品信息的描述在领域模型里，经常声明一个XSpecification来描述一个X规格说明概念类规则：使用Specification/description的场合当需要对Item或服务进行描述（独立于这些条目或服务当前存在的任何具体例子)时删除实例会导致有用信息丢失时（这些信息和被删除的东西不恰当地关联在一起了）要减少信息冗余另一个规格说明的示例航班失事，则取消所有航班(service)，所有Flight对象删除。则各个number的航班目的地信息全部丢失,应该把number部分提取出来其他事物的规格说明同一种图可用于不同视角的模型本质的或概念性的观点现实世界规范说明的观点独立于语言的软件世界实现的观点具体语言实现UML表示法被应用于不同的模型与类相关的术语概念类现实世界中的概念或者事物一个概念性或本质的观点UP领域模型包含概念类软件类一个用于表示软件组件的规范说明或者实现不考虑过程或者方法的观点的类设计类UP设计模型的一个成员它是软件类的同义词UP允许设计类是一个规范说明或者实现的观点，这符合建模者的期望与类相关的术语实现类用面向对象语言（如Java）已实现的一个类类一个通用术语表示一个现实世界的事物（一个概念类）或者软件事物（一个软件类）。缩小表示差距解决语义鸿沟-用相同的名称语义鸿沟POS系统领域模型领域模型和UP初始细化主要在此创建，当需要理解值得注意的概念，并映射到部分设计工作的类中熟练者每次迭代只需几小时来开发领域模型，若是用预定义的分析模式，还将更快UP业务对象模型和领域模型的比较

业务对象模型（BOM--BusinessObjectModel）[TheUPBOM]是业务员工和业务实体如何相互关联以及为了完成业务如何写作的抽象[RUP]BOM可以用多种不同的图（类图、活动图