领域模型(概念类图).pptVIP

1.顾客携带购买的商品到达POS机收费口 2.收银员开始一次新的销售 3.收银员输入商品标识 4.系统记录销售的商品项列表，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算 收银员重复3-4步，直到结束 5.系统显示最后的总价 6.收银员请顾客付款 7.顾客支付，系统处理支付 8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记账系统（进行记账）和库存系统 9.系统打印收据 10.顾客带着商品和收据离开 销售领域的候选概念类 收银台 商品 商店 一次销售 支付 产品目录 产品规格说明书 销售明细项 收银员 客户 POS领域模型中的关联 收银台 记录 销售 顾客支付 销售 产品目录 记录 产品说明书 系统 记录 销售 商店 存储 商品 系统记录销售的商品项列表 顾客支付，系统处理支付 系统记录单件商品，并显示该商品的描述、价格和累加值。 并将销售和付款信息发送到外部的记账系统（进行记账）和库存系统 系统记录完整的销售信息？ 理解型关联 1. 需要记住型关联：概念之间的关联需要在数据库中保存一段时间，可以形成一个最小的信息模型； 2. 理解型关联：概念之间的关联不是必须的，但是加上之后可以更好的理解问题域关键概念。 3、添加类的重要属性 属性及其UML表示 （1）定义：属性是某个对象的数据值。 （2）在一个概念模型中包括如下属性： 在需求说明（例如用例）中提示或暗示我们要记住的那些信息。 （3）属性的UML表示 Sale Date time 属性表示法 属性的完整语法是： 可见性 属性名:类型 多重性=默认值{特性表} Sale Datetime /total:Money Sale -DateTime:Date -/total:Money Person -firstName -middleName:[0..1] -lastName 属性的识别 1）首先从类的语义完整性角度列举出类的候选属性； 2）针对系统目标和类在系统中的作用以及问题域相关特性对类的候选属性进行一次筛选； 属性的识别 属性的识别要根据具体的问题域，同一实体在不同的系统中识别出来的属性会不一样 图书馆系统：不关注头发颜色、眼睛颜色； 公安局侦察管理系统：头发颜色、眼睛颜色、指纹等 导出属性 在属性名称前加以”/”符号 SaleLineItem Item Records-sale-of 0..1 1 SaleLineItem Item Records-sale-of 0..1 1..* SaleLineItem /quantity Item Records-sale-of 0..1 1..* SaleLineItem（销售明细项）的quantity信息可以 从多重性的实际值导出 从多重性值 导出的属性 选择有效的属性类型 属性应该是简单的数据类型。复杂的问题域概念应该被识别为概念。 收银员 姓名 收银台 非“简单”属性 收银员 姓名 收银台 编号 Uses 1 1 更好 选择有效的属性类型… 保持简单的数据类型 属性常见的简单数据类型包括：布尔、日期、数字、字符串或文本、时间 其他如：地址、颜色、几何元素、电话号码、身份证号、通用商品代码、邮政编码等 选择有效的属性类型… 保持简单的数据类型 飞机 目的地 复杂概念 较差 较好 飞机 机场 Flies-to 1 1 定义新的数据类型 数据类型 原始数据类型：数字、字符串、布尔、日期或时间 ——把它当作属性来看待 非原始的数据类型: ——把它表示成一个单独的概念类 定义新的数据类型 Product Specification Id：ItemID Store address:Address Product Specification ItemID id manufactureCode countryCode 1 1 Store Address street1 street2 cityName 1 1 避免设计潜行：任何属性都不表示外健 在领域模型里,不应该使用属性来联系概念类.这个原则最常见的反例是添加一种外键属性(foreign key attribute),这是关系数据库设计中为了连接两种类型的典型做法. Cashier name currentRegisterNumber 这是一个“简单”属性，但它是被用作与另一个对象相关联的外健 1 1 Cashier name Register number Uses 应该使用关联而不是属性来将类型关联起来 POS的领域模型中