资源描述
Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,第四章 餐馆系统业务模型,陈立岩,第1页,业务模型(,Business Modelling,),软件开发早期阶段,输入,:,非形式化规格说明,活动,:,创建用例模型(,use case model,),创建领域模型(,domain model,),创建词汇表(,glossary,),第2页,本章内容,4.1 建立用例模型,4.1.1 非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第3页,本章内容,4.1 建立用例模型,4.1.1 非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第4页,本章内容,4.1 建立用例模型,4.1.1 非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第5页,4.1.1,非正式需求,原有功效,采取手工预约单:,预约信息,姓名和电话号码,就餐者人数,调换餐桌,取消预约作注释,未预约用户(,Walk-in,),就餐人数,第6页,本章内容,4.1 建立用例模型,4.1.1非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第7页,4.1.2,用例建模,第一次迭代应该只交付足够使系统提供一些确实有商业价值关键功效。,定义基本功效,建立初始用例图,系统应取代手工预约单,第8页,用例建模步骤,1.识别,用例步骤,找出系统边界和范围,识别参加者,确定每个参加者所期望系统行为,找出用例,2.定义初始,用例图,第9页,识别用例第一步:,系统边界,考虑结构系统时,你所需要做第一件事情是确定系统边界在哪里,需要定义什么是系统组成部分(系统边界内)和什么是系统外部(系统边界外)。,系统边界是定义由谁或什么(参加者)使用系统,系统能够为哪些参加者提供什么特定利益(用例)。,系统边界绘制为方框,标有系统名称,参加者绘制在边界外部,用例绘制在边界内部。,第10页,识别用例第二步:识别参加者,谁或什么使用该系统?,谁对某个特定功效感兴趣?,谁负责支持和维护系统?,系统有哪些外部资源?其它还有哪些系统将需要与该系统进行交互?,第11页,参加者,-Actors,人与系统进行交互时能够担任不一样角色,eg:,接待员,Receptionist(makes bookings),领班,Head waiter(assigns tables etc),一个用户在不一样时间能够饰演一个或多个角色,用户不是参加者,第12页,识别用例第三步:,描述用例,建立一组用例,使系统用户能够使用系统完成不一样任务。,餐馆预约系统需完成主要任务,:,统计一个新预约信息,取消一个预约信息,统计一位用户到来,将一位用户餐桌从一张餐桌移到另一张餐桌(“调换餐桌”),第13页,建立初始用例图(,Use Case Diagrams,),以图解形式概括系统中不一样参加者和用例,并显示哪些参加者能够参加哪些用例。,第14页,本章内容,4.1 建立用例模型,4.1.1非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第15页,用例描述模板,见上章,用例描述没有统一标准模板,可采取与项目一致格式。,从实用上,应更重视编写完整和可了解,事件路径,,而不是按指定模板填写每个部分。,第16页,基本事件路径,正常交互情况下路径,不中止。,统计预约,接待员输入要预约日期,系统显示该日预约,有一张适当餐桌能够使用:接待员输入用户姓名、电话、预约时间、用餐人数和餐桌号,系统统计并显示新预约。,第17页,可选事件路径,统计预约,没有可用餐桌,:,接待员输入要求预约日期;,系统显示该日预约;,没有适当餐桌能够使用,用例终止,第18页,例外事件路径,统计预约,餐桌过小,接待员输入要求预约日期;,系统显示该日预约;,接待员输入用户姓名电话预约时间,用餐人数和餐桌号,用餐人数多于餐桌容纳人数,系统问询是否继续预约,假如回答“否,”,用例将不进行预约而终止,假如回答“是,”,预约将被输入,并附有一个警告标志。,第19页,用户界面原型(可选),When writing use cases,it is useful to have a rough idea of the planned user interface,第20页,本章内容,4.1 建立用例模型,4.1.1非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第21页,组织用例模型,统计抵达:基本事件路径,()领班输入当前日期,()系统显示当日预约,()领班确认一个选定预约已经抵达,()系统对此进行统计并更新显示器,将用户标识为已经抵达。,第22页,统计抵达没有提前预订:可选事件路径,()领班输入当前日期,(),系统显示当日预约,()系统中没有统计该用户预约,领班输入预约时间、人数和餐桌号,创建一个未预约登记;,()系统统计并显示新预约。,以上两个用例存在共享功效,第23页,Use Case,包含,把共享部分分离出来组成一个新用例,显示预约(,Display Bookings,),:,用户输入一个日期,系统显示当日预约,更改“,统计预约,”用例,能够这么写,:,接待员执行,显示预约,用例,接待员输入,系统统计和显示新预约,第24页,Use Case,包含,一个用例和它所包含其它用例之间关系,在用例图中用一个连接两个用例虚线箭头表示,称为,依赖,。,第25页,参加者泛化,普通参加者和特殊参加者之间泛化关系。,参加者泛化把两个或多个参加者公共行为分离出来成为父参加者。,接待员和领班都能够执行“显示预约”用例;,描述一个新参加者,员工(,staff,)表示泛化;,接待员和领班被看作“员工”特殊情况。,第26页,The extend Dependency,Use case extension is shown with a dependency,第27页,何时使用高级特征,仅在简化模型并使模型易于了解时才使用高级特征。,用例最好是简单。必须对于利益相关人和建模者都是可访问。,通常利益相关人仅需要一点培训和指导就能够轻易地了解参加者和用例。,利益相关人发觉掌握参加者泛化愈加困难。,太多include使得了解用例模型愈加困难。,利益相关人对entend了解相当困难。,很多建模者令人吃惊地错误了解extend语义。应该防止使用用例泛化,除非使用抽象父用例。,第28页,本章内容,4.1 建立用例模型,4.1.1非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第29页,Complete Use Case Diagram,第30页,本章内容,4.1 建立用例模型,4.1.1非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第31页,4.2 领域建模,在第四章中,UML表示法建立对象模型(学习建立类图画法和问题表示),本节关键思想:定义领域模型,提供建模方法或建模观点。,领域模型是,OO,分析中最主要和经典模型,领域模型(,Domain Model,),也称为概念模型、领域对象模型,我们在对项目进行分析时候,往往会创建对应领域模型。,寻找业务领域中名词,建立类图和对象图。,领域模型包含:概念、关联、属性,第32页,4.2.1 领域模型相关概念,1.概念:,概念类:表示在现实世界环境中含有意义实体或概念。,领域模型:是对,业务术语进行描述,,产生现实世界概念类一个表示。通常,,采取类图表示,以显示最主要业务概念和他们之间关系。,2.领域模型组成:,概念类,概念类之间关系,概念类属性(暂不包含操作,在以后考虑),第33页,为何需要领域模型?,了解关键概念和词汇,为进入设计阶段得到一些启示,现实世界与软件实现之间过渡,第34页,4.2.2 建立领域模型,包含以下四步:,概念类识别,在领域模型中描述这些概念类,建立类关联关系,添加必要属性,第35页,4.2.2 建立领域模型,包含以下四步:,概念类识别,在领域模型中描述这些概念类,建立类关联关系,添加必要属性,第36页,1.概念类识别,识别策略:,使用概念类分类列表,识别名词短语,第37页,策略1:概念类分类列表,(部分),物理或详细对象,事物实际、描述和规范,位置,交易,交易项目人角色,组织,事件,第38页,策略2:依据名词短语识别找出概念类,即:识别相关用例文本描述中名词和名词短语,将它们作为候选概念类或属性。,统计预约,接待员输入要,预约,日期,系统,显示该日预约,有一张适当,餐桌,能够使用:接待员输入,用户,姓名,、,电话,、预约,时间,、,用餐人数,和,餐桌号,系统统计并显示新预约。,第39页,4.2.2 建立领域模型,包含以下四步:,概念类识别,在领域模型中描述这些,概念类,建立类关联,关系,添加必要,属性,第40页,建立候选概念类:,用户、预定,用户和预定建模:,Customer,Reservation,name,phoneNumber,1,*,Make,建立候选概念类:,用户、预定,Customer,Reservation,name,phoneNumber,1,*,Make,covers,date,Time,places,第41页,Customer,Reservation,name,phoneNumber,1,*,Make,covers,date,time,table,places,*,1,Reservation for the same,Table must not overlap,WalkIn,covers,date,time,1,*,第42页,Booking,covers,date,time,table,places,WalkIn,Reservation,Customer,name,phoneNumber,*,1,Make,Reservation for the same,Table must not overlap,*,1,第43页,本章内容,4.1 建立用例模型,4.1.1非正式需求,4.1.2 用例建模,4.1.3 描述用例,(系统用例编写,基本事件路径),4.1.4 组织用例模型,(调整优化用例图),4.1.5 完成用例模型,(用例图第二次迭代),4.2 建立领域模型,4.3 建立词汇表,第44页,4.3 术语表,预约,(Booking):分配一张餐桌给用餐者进餐.,用餐人数,(Covers):预约未来用餐人数。,用户,(Customer):进行预定人,用餐者,(Diner):在餐馆用餐人,位子,(Places):在一张特定餐桌能够就座用餐人数。,预定,(Reservation):提前预约一个特定时间餐桌。,未预约,(Walk-in):没有提前进行预约。,第45页,Thank You!,第46页,
展开阅读全文