您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 销售管理 > 领域模型(概念类图)
领域模型软件学院代飞2013·秋1、概念模型的简介2、建立概念模型的基本步骤内容领域模型:显示最重要的业务概念和它们之间的关系的类图。领域模型用:类表示业务概念,但类通常只包含重要属性,不包含操作关联和泛化显示了这些概念之间的关系。1、领域模型简介它是真实世界中各个事物的表示,而不是软件中各构件的表示。领域模型是现实世界的一个可视化抽象字典它可视化了领域中的单词或概念类,并为这些单词或概念类建立了关联领域模型是没有方法的类图的集合,并且在领域模型中不会出现软件工件SalesDatabaseSaledatetimePrint()storeregistersaleSaledatetime关键思想根据用例模型建立领域模型用例模型领域模型关闭ATM系统管理员启动ATM系统用户查询存钱取钱转账银行信息系统身份验证includeincludeincludeincludeATM管理员钥匙开关日志ATM机用户键盘显示器银行信息系统读卡器出钞口客户交互控制台打印机储蓄卡转账存钱取钱查询网络连接2、建立概念模型的基本步骤1、发现类和对象2、建立类之间的关联3、添加类的重要属性2.1发现类和对象识别概念的方法a、使用概念类分类列表来找出概念;b、根据名词性短语识别出概念类;领域模型中的概念类越多越好从用例中识别概念1、用例描述中出现了哪些实体?2、用例执行过程中会产生并存储哪些信息?3、用例要求与之关联的每个角色的输入是什么?输入可能是角色的属性,也有可能是单独的一个类。4、用例反馈与之关联的每个角色的输出是什么?首先确定该输出的责任实体,然后进一步确认输出是否需要识别为类。5、用例需要操作哪些设备?分类列表法人事物地点组织概念事件规则抽象名词交易项目角色设备组织结构概念类分类示例物理或具体对象注册飞机事务的设计、描述和规范产品说明飞机说明位置商店飞机场交易项目销售项人的角色收银员飞行员其他事务的容器商店箱柜容器包含的元素商品乘客在该系统之外的其他计算机或电子机械系统授权支付系统飞行事务控制系统抽象名词的概念购买欲恐高症……名词分析法识别问题域和用例描述中的名词和名词短语,然后将它们作为候选的概念类或属性超市收银台主要的成功场景:1.顾客携带购买的商品到达POS机收费口2.收银员开始一次新的销售3.收银员输入商品标识4.系统记录销售的商品项列表,并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算收银员重复3-4步,直到结束主要的成功场景(续):5.系统显示最后的总价6.收银员请顾客付款7.顾客支付,系统处理支付8.系统记录完整的销售信息,并将销售和付款信息发送到外部的记账系统(进行记账)和库存系统9.系统打印收据10.顾客带着商品和收据离开顾客,购买的商品,POS,收银员,新的销售,商品标识,商品项列表,描述,价格,累加值,总价,支付,销售信息,付款信息,记账系统,库存系统,收据确定对象:顾客,商品,POS,收银员,新的销售,商品项列表,支付,销售信息,付款信息,记账系统,库存系统,收据摒弃对象:商品标识,描述,价格,累计值,总价有时很难决定是应该将一个特殊的信息作为一个类还是作为一个属性包含在领域模型中。类:标识、状态和行为属性还是概念?2.2建立类之间的关联类之间有三种关系:-关联(包括聚合和组合)-继承(一般与特殊的关系)-依赖关联类之间的某种语义关系。这种语义关系体现了事物之间的联系。进一步说,联系又可以分为长久的、稳定的联系和短暂的、不稳定的联系。员工组织参与类关联类二元关联基数关联名参与**接待员顾客?顾客预订?识别关联的方法——关联列表A在物理上或逻辑上是B的一部分;A是对B的描述A是交易或项目B中的一项A为B所知/为B所记录/录入B中/为B所捕获A是B的一个成员A是B的一个组织子单元A使用或管理BA与B通信A与一个交易B有关A是一个与另一个交易B有关的事务A与B相邻A为B所拥有A是一个与B有关的事件关联的UML表示法用一条写着关联名称的线段来表示两个类之间的关联。关联自然具有双向性,这意味着从关联两端的任何一个类的实例出发在逻辑上都是可以达到另一端。关联的每一端都可以包含一个多重性的表达式,它表示两个类的实例之间的数量关系.•规定关联的重数,每个预定是由一个顾客进行的,这个人的姓名和电话由系统记录,但是每个顾客可以进行多个预定CustomerReservationMakes1*namephoneNumber顾客和预定建模导读箭头关联名多重性建立关联的原则1)注意力集中在那些需要将概念之间的关系信息记忆一段时间的关联上(“需要记住”型关联)。2)识别出概念类比识别出关联更为重要。3)关联太多不仅不能有效展示概念模型,反而会使概念模型变得混乱。4)要避免关联之间的信息冗余以及减少派生关联。花费在领域模型创建的大部分时间应该被用于识别概念类,而非关联建立关联的原则…5)概念模型概念间的关联是从纯分析角度声明有意义的概念间的联系,不需要考虑如何实现关联。6)分析阶段得到的关联可能在设计阶段发现是无用的;设计阶段有可能发现分析阶段遗漏了有些概念间的关联。关联的命名采用动词短语来为关联命名;关联的名称应该以大写字母开头。动词短语由几个单词组成时需用连字符“-”将单词连接在一起。基于类型名-动词短语-类型名的格式来为一个关联命名:Paid-byPaidBy商店-包含-收银台关联类关联类和其他类相似。只不过一般类描述的是实体,而关联类描述的是关系。当你见到多对多关联,则需要考虑使用关联类继承1.顾客携带购买的商品到达POS机收费口2.收银员开始一次新的销售3.收银员输入商品标识4.系统记录销售的商品项列表,并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算收银员重复3-4步,直到结束5.系统显示最后的总价6.收银员请顾客付款7.顾客支付,系统处理支付8.系统记录完整的销售信息,并将销售和付款信息发送到外部的记账系统(进行记账)和库存系统9.系统打印收据10.顾客带着商品和收据离开销售领域的候选概念类收银台商品商店一次销售支付产品目录产品规格说明书销售明细项收银员客户POS领域模型中的关联收银台记录销售顾客支付销售产品目录记录产品说明书系统记录销售商店存储商品系统记录销售的商品项列表顾客支付,系统处理支付系统记录单件商品,并显示该商品的描述、价格和累加值。并将销售和付款信息发送到外部的记账系统(进行记账)和库存系统系统记录完整的销售信息?RegisterItemStoreSaleCashPaymentSalesLineItemCashierCustomerProductCatalogProductDescriptionStocks*Houses1..*Used-by*Contains1..*Describes*Captured-onContained-in1..*Records-sale-of0..1Paid-byIs-forLogs-completed*Works-on11111..*11111110..111LedgerRecords-accounts-for11理解型关联1.需要记住型关联:概念之间的关联需要在数据库中保存一段时间,可以形成一个最小的信息模型;2.理解型关联:概念之间的关联不是必须的,但是加上之后可以更好的理解问题域关键概念。3、添加类的重要属性属性及其UML表示(1)定义:属性是某个对象的数据值。(2)在一个概念模型中包括如下属性:在需求说明(例如用例)中提示或暗示我们要记住的那些信息。(3)属性的UML表示SaleDatetime属性表示法属性的完整语法是:可见性属性名:类型多重性=默认值{特性表}SaleDatetime/total:MoneySale-DateTime:Date-/total:MoneyPerson-firstName-middleName:[0..1]-lastName属性的识别1)首先从类的语义完整性角度列举出类的候选属性;2)针对系统目标和类在系统中的作用以及问题域相关特性对类的候选属性进行一次筛选;属性的识别属性的识别要根据具体的问题域,同一实体在不同的系统中识别出来的属性会不一样图书馆系统:不关注头发颜色、眼睛颜色;公安局侦察管理系统:头发颜色、眼睛颜色、指纹等导出属性在属性名称前加以”/”符号SaleLineItemItemRecords-sale-of0..11SaleLineItemItemRecords-sale-of0..11..*SaleLineItem/quantityItemRecords-sale-of0..11..*SaleLineItem(销售明细项)的quantity信息可以从多重性的实际值导出从多重性值导出的属性选择有效的属性类型属性应该是简单的数据类型。复杂的问题域概念应该被识别为概念。收银员姓名收银台非“简单”属性收银员姓名收银台编号Uses11更好选择有效的属性类型…保持简单的数据类型属性常见的简单数据类型包括:布尔、日期、数字、字符串或文本、时间其他如:地址、颜色、几何元素、电话号码、身份证号、通用商品代码、邮政编码等选择有效的属性类型…保持简单的数据类型飞机目的地复杂概念较差较好飞机机场Flies-to11定义新的数据类型数据类型原始数据类型:数字、字符串、布尔、日期或时间——把它当作属性来看待非原始的数据类型:——把它表示成一个单独的概念类定义新的数据类型ProductSpecificationId:ItemIDStoreaddress:AddressProductSpecificationItemIDidmanufactureCodecountryCode11StoreAddressstreet1street2cityName11避免设计潜行:任何属性都不表示外健在领域模型里,不应该使用属性来联系概念类.这个原则最常见的反例是添加一种外键属性(foreignkeyattribute),这是关系数据库设计中为了连接两种类型的典型做法.CashiernamecurrentRegisterNumber这是一个“简单”属性,但它是被用作与另一个对象相关联的外健11CashiernameRegisternumberUses应该使用关联而不是属性来将类型关联起来POS的领域模型中的属性概念address,namedatetimeamountTendereditemID,description,pricequantitynameRegisteridItemStorenameaddressSaledateTime/totalCashPaymentamountTenderedSalesLineItemquantityCashieridCustomerProductCatalogProductDescriptionitemIDdescriptionpriceStocks*Houses1..*Used-by*Contains1..*Describes*Captured-onContained-in1..*Records-sale-of0..1Paid-byIs-forLogs-completed*Works-on11111..*11111110..111LedgerRecords-accounts-for11思考关闭ATM系统管理员启动ATM系统用户查询存钱取钱转账银行信息系统身份验证includeincludeincludeinclude出钞口显示器钥匙开关键盘读卡器ATM机日志储蓄卡交易查询取款存款转账银行信息系统打印机收据
本文标题:领域模型(概念类图)
链接地址:https://www.777doc.com/doc-5147113 .html