02领域模型.ppt

1、领域模型,话题,复习 用例需求 详述细节过程 领域模型 简介与定义 如何生成领域模型 领域模型的精解,复习,起始阶段问自己的几个问题 不同类型的需求 场景&用例 如何书写用例 用例图 用例之间的include关系,迭代1基础需求,POS应用系统的第一次迭代需求： 实现处理销售用例中基本和关键的场景：输入商品，收取现金 实现用于支持迭代初始化需求的启动用例 不处理任何特殊和复杂的部分，针对场景的简单理想路径进行设计和实现 不参与外部服务的写作 不应用复杂的定价规则,迭代1基础需求,Monopoly在第一次迭代中应完成处理的需求： 实现基本和关键场景：游戏者围绕棋盘四周的方格移动 实现用于支持迭代

2、初始化需求的启动用例 支持28个游戏者 游戏通过一系列回合制进行。掷骰子，并且根据骰子得到的点数和移动相应格,游戏20回合 掷骰子，显示骰子点数和游戏者名，游戏者移动，并占据方格，显示游戏者名字和方格名字 迭代1中，不考虑金钱，输赢，买地，租金，和其他特殊方格 每个方格都有对应的名字，刚开始的时候，游戏这都在名为go的方格上。方格的名称依次为“go”，“方格1”，“方格2”，“方格39”,增量开发,在若干个迭代内，对同一用例的各场景进行开发，逐步扩展系统，直到最终完成所有需求的功能性模块。,过程：初始,初始阶段： 持续不超过1周 命名大部分的参与者，参与者的目标和用例的名称 使用摘要格式完成大

3、部分的用例；10到20的用例使用详述格式完成 明确需要购买、开发、重用的功能块，留在细化阶段精化 为了揭示特殊需求的技术可行性，完成简单的技术验证原型 对高层架构提出建议，在细化阶段精华 对第一次迭代提出计划 ,过程：精化,精化过程： 对核心，高风险的软件架构进行编程和测试 发现并稳定需求的主体部分 规避主要风险 精化用一句话来概括： 建立核心架构，解决高风险元素，定义大部分需求，预计总体进度和资源,过程：精化,精化过程中最好的实践： 实行短时间定量、风险驱动迭代 及早开始编程 对构架的核心和风险部分进行适应性设计、实践和测试 尽早，频繁，实际的测试 给予来自测试，用户，开发者的反馈进行调整

4、通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。,领域模型,对领域内的概念类或现实世界中对象的可视化表示 使用UML中没有定义操作的类图表示 Input： 问题描述，用例 Output： 一套类图,领域模型的例子,确认概念类，是OOA的核心,什么是领域模型,对现实世界中概念类的表示，而不是对软件中对对象的表示,领域模型被称为可视化词典,领域模型提供了概念透视图，显示了概念类的抽象 领域对象或概念类 概念类之间的关联 概念类的属性 描述信息可以是纯文本。,领域模型不是软件的对象,领域模型关注的是显示世界领域中的事物的可视化 左侧的元素，不适用于领域模型,真实世界的可视化，不

5、表示软件,软件制品,软件类,概念类,概念类，是思想，事物，或对象 概念类，可以从符号，内涵和外延来考虑 P102,领域模型不是数据模型,数据模型：表达的是存储在某处的持久性数据 领域模型： 临时的对象 没有属性的对象,建造领域模型的动机,帮助理解业务领域与问题领域的一些关键问题 降低OO建模之间的差异,Payment在领域模型中是一个概念。 但是在设计模型中，Payment是一个软件类。领域模型对设计模型有启发作用 减少了表示差异,在利益攸关方眼中的看法,创建领域模型,步骤： 找到概念类 以UML类图绘制概念类 添加关联和属性,找到概念类,3种寻找概念类的方法 重用、修改已有的模型 许多领域都

6、有已经发布的，精细的领域模型和数据模型。 比如：分析模式 使用分类列表 寻找名词,使用分类列表,使用概念类的候选列表 P104P105,通过识别名词,语言分析是有效的手段 分析文本描述的领域 分辨名词和名词短语 找到候选类或者候选属性 注意点： 自动映射是不可能的 文字描述有时候是不准确的（不同的语言可能指向的是同一个类,举例：事件流,顾客进入一个商店，准备为3岁大的孩子爱丽丝购买一件玩具 一分钟内必须能得到导购帮助 店主给顾客一些建议。这些建议是根据孩子大小和玩具的属性来给出的 顾客选择的是一种不适合3岁小孩玩的具有一定危险性的玩具 店主建议找一件柔软的娃娃,描述部分对应的对象模型映射,举例

7、：找到并且画出概念类,Pos的领域 输入： 完整的详述用例模型 迭代1： 处理销售主成功场景用例 策略：分类列表法 没有标准答案，只有建模者认为重要的抽象事务和领域词汇,初始的POS领域模型,初始的大富翁模拟游戏的领域模型,敏捷建模风格,在早期的领域模型设计中，漏掉一些概念类，是很正常的事情。在设计和编程阶段，需要完善 我们可以使用各种工具画出需要操作的模型 长生命期的OO分析领域模型，不会增加价值,包括报告对象,单据是在一个POS领域中会被关注的对象 单据可以被看作是复制购买和支付信息的容器 设计报告对象的准则： 一般人看来，在领域模型中显示这样的报告对象是没有用处的，因为单据反映的都是其他

8、信息的复制信息 但是在业务流程看来，单据却非常重要。 总的说来，在领域模型中应该包含单据,像画地图一样的思考,使用领域内已有的名称 排除无关的或者超出范围的特定 不凭空添加领事物,类或者属性？,类或者属性？ 某东西，不是现实世界中的文本或数字，那该东西更多可能是一个概念类，而非属性,描述类,包含描述其他事物信息的类,描述类,什么时候使用描述类 需要有关商品或服务的描述，却又独立于任何商品或服务的现有实例 删除其所描述的事物的实例后，会导致信息丢失。而这些信息是需要维护的，却错误的同被删除的信息关联起来 减少冗余和重复信息,描述类,关联,关联： 类与类之间的有意义的，值得关注的连接 UML中，两

9、个或多个类之间的语义联系，涉及这些类实例间的连接,何时表达关联,关联表达的是需要持续一段事件的联系 在POS系统中 SaleLineItem与Sale实例之间的关联 Casher可以查看ProductDescription，但是我们不必知道哪个收银员查看了哪个商品的描述信息 在大富翁中 棋子与格子的关联 棋子根据骰子的点数，移动到某个格子里。 尽量避免出现过多的关联,关联与实现,关联与实现（implement）没有必然的直接关系 关联所表达的也不是实现结构 一些关联在软件结构中，可以得到不同的实现,关联的符号,阅读方向箭头 表达阅读关联标记的方向 可以省略,关联名称,多重性,命名关联,遵循“类

10、名动词短语类名”的格式 为了增强对领域的理解，避免使用： 有，使用，拥有,UML应用：多重性,多重性，表达的是一个类A与另一个类B之间有多少个实例关联,多重性的值,多重性表达的是在某个特定时刻的有效关联的实例数量，而不是一个时间段内的关联实例数量,两个类的多重关联,关联列表中寻找关联,P115,POS的部分领域模型,大富翁的部分领域模型,属性,属性是对象的逻辑数据值 展示属性： 需求建议或暗示需要记住信息的时候,UML符号,在类框图的第二格中表示,可见性为私有,可见性为公共，只读，具有初始值，3.14,取值范围,合适的属性类型,大部分属性类型应该为简单数据类型 通过关联，而非属性来确认概念类之

11、间的联系,不是数据类型属性,目的地是复杂的,数据类型作为属性,可以使用数字和字符串重新定义数据类型,采用何种描述方法，取决于想要表达的事物，以及领域中概念的重要性,属性不是外键,在实现过程中，有很多方式来表达对象间的联系。使用外键是一种方法。但是只有到了设计阶段，才能应该去决定是否使用外键,简单属性，但是用作外键与其他对象关联,对数量建模,无用,在属性范围中适合现实纯数据值,变体：货币单位的变化导致Money特异化,比较好的设计中，会考虑到单位的换算，以满足软件的通用性,迭代增量领域模型,领域模型标准 没有标准的领域模型 领域模型在迭代中不断完善 在每次迭代中，领域模型只应该考虑当前和以前的场

12、景,精化领域模型,泛化 寻找领域中的概念成员，定义父类（一般性的概念）和子类（特殊的概念）在领域模型中的关系,概念类，而非软件类,父类：一般性概念,子类：特异性概念,概念上的父类与子类,100规则 概念父类中的定义，应该100适用与子类。同时，子类应该100的遵守父类的属性与关联约束 IS-A规则 所有子类的实例，都应该是父类的实例,精化领域模型,精化领域模型，定义概念子类的时刻： 当子类有需要关注的附加属性的时候 当子类与其他类有需要关注的附加关联的时候 当子类概念，区别于父类或其他子类，被进行操作，处理，反应，操纵的时候。 当子类概念，表达的是可以具有区别于父类或其他子类的行为能力的事物的

13、时候,正确的子类划分，不一定有用,举例：子类划分,精化领域模型,精化领域模型，定义概念父类的时刻： 潜在的概念子类，表达大量的相同概念 潜在的概念子类，满足100和IS-A规则 潜在的概念子类，具有父类可以表达的大量相同的属性 潜在的概念子类，与其他类具有相同关联的时候,Payment概念类,父类：具有相同的属性和与其他概念类关联,子类：每个Payment子类都有不同的处理方式,Payment授权服务,父类有相同属性和与其他类的关联,子类有不同的关联,完成领域模型,某影碟店，拥有11个连锁店。为了提高整体的信息化优势，店主决定要开发一个新的电影租赁系统。 每个商店，都有一个出租库，用来存放影碟。系统需要知道每一部电影的标题，存放目录（经典，动画，武打）出租类别（新到出租，打折出租）。为了记录每一部电影的出租情况，系统需要记录每一张碟片的出租日期和出租情况