搜索
南开大学软件学院1第四章实例学习----一个餐馆系统的业务建模本章目标使用面向对象分析方法和UML完成一个业务建模 典型实例：餐馆系统南开大学软件学院2一、餐馆系统管理•当前系统使用手工方式完成用餐预定，预约单格式：当前主要完成的功能包括•预约信息记录在一张纸片上–联系人的姓名和电话号码–就餐人数:‘餐桌占用’•‘未预约就餐’也需要记录–只记录就餐人数•可以预定指定的餐桌•可取消预约信息–在预约单上划掉已有的预约记录用IT替代原系统：定义第一次迭代•第一次迭代应能实现一个昀简可用的系统•基本功能:–记录预约–更新预约单的信息•系统应能够替代手工制单操作二、用例建模创建用例模型的基本步骤： 1．定义系统 2．确定参与者 3．确定用例 4．描述用例 5．定义用例间的关系 6．确认模型•找出用例，找出参与者并描述他们都做什么，画出初始用例图：用例包括：•记录预约•取消预约•记录到达•调换餐桌参与者包括：•前台接待员•领班完成昀初的用例图三、描述用例•对于“记录预约”正常情况完成:1接待员输入要预约的日期2系统显示该日的预约3接待员输入具体细项4系统记录并显示新的预约“记录预约”基本事件流程描述用例---“记录预约”可选事件流程•在“记录预约”时若没有餐桌，可选流程:1接待员输入预约日期2系统显示该日的预约3没有可用餐桌:用例终止在“记录预约”时餐桌过小，例外流程1.接待员输入要求预约的日期；2.系统显示该日的预约；3.接待员输入输入预约人详细信息；4.发现用餐人数多于餐桌可容纳数，系统发出警告并询问是否继续预约；5.回答“no”预约终止6.回答“yes”预约将被记录，并附警告标志描述用例---“记录预约”可选事件流程用户界面原型•写用例时,需要给出一个用户界面的粗略构思，这对今后的设计是有用的。界面可只包含要显示的内容和方式，其他暂不考虑。找出共享功能•不同的用例可能有交融的部分•E.g.“记录到达”:–领班输入当前日期–系统显示当天预约–领班确认一个预约已到达–系统记录这些并更新显示•前两步与‘记录预约’是共享的（尽管属于不同的参与者）四、用例模型的调整与优化标识包含依赖关系•UML可表现出两个用例之间具有’依赖‘的这种包含关系，这时需要用规定的’依赖‘符号来标识:表示：”记录预约“用例中包含着”显示预约“用例。或称”记录预约“用例与”显示预约“用例有包含依赖关系。参与者泛化结合前面的用例图，可以将包含“显示预约”用例的用例图替换：这里有一个新的参与者是”员工“，他是已有参与者通过泛化产生的。用例扩展•用例扩展是表示用例间所具有的依赖关系。如‘记录未预约’顾客的基本事件流程为：1.领班执行”显示预约“用例2.领班输入时间、用餐人数和分配的餐桌3.系统记录并显示新预约•该用例与”记录到达”用例有太多重叠，能否用包含依赖性来描述呢？经分析后用扩展依赖比较合适•因为并不是每次执行’记录到达‘要执行的内容，但在某种情况下‘记录到达’用例可以被’记录未预约‘用例扩。因此有：注意：包含依赖和扩展依赖关系可以通过用例描述加以区别！“取消预约”用例基本事件流程：1.接待员选择要求取消的预约2.接待员取消该预约3.系统询问接待员是否确认取消4.回答“是”，记录取消并显示。“调换餐桌”用例基本事件流程：1.领班选择需调换餐桌预约2.领班改变该预约餐桌分配3.系统记录改变并更新显示五、完用例模型完成其他两个用例模型综合用例模型将以上各模型综合起来，完成整体用例图：六、关于用例模型的价值任何参与系统功能活动的人都需要用例模型：客户：因用例模型指明了系统的功能，描述了系统将如何使用。客户积极参与用例建模十分重要。开发者：用例模型可帮助他们理解系统要做什么，同时为以后的其它模型建模、结构设计、实现等提供依据。集成测试和系统测试人员：根据用例来测试系统，以验证系统是否完成了用例指定的功能。１．从使用层面看用例模型描述的是参与者(Actor)所理解的系统功能。描述了待开发系统的功能需求。 用例模型由用例图组成，用例图展示了执行者、用例以及它们之间的关系。 用例通常用正文和活动图描述。 一个用例模型可由若干幅用例图组成。一幅用例图包含的模型元素有系统、执行者、用例，以及表示它们间的不同关系，如关联、扩展、包含、泛化等。２．从实质层面看3.用例建模的优势•完全站在用户的角度描述系统–将被定义的系统看成黑匣子，不考虑内部实现问题．–定义了系统具有的参与者，他们都将与系统有交互．–描述了参与者的所有行为–用例图可展示被定义系统的整体情况•将需求与设计做了比较彻底的分离–用例模型主要用于表述系统的功能性需求（系统的设计主要由对象模型来表述）–每一个用例描述的是一个完整的系统服务，容易被用户理解，有利于设计者与用户间的沟通．七、用例建模中包含技术1.确定参与者(Actor)•参与者是指与系统交互的人或其它系统•参与者代表一种角色，而不是具体的某个人可通过回答下列问题确定执行者：谁使用系统的主要功能？谁需要系统对他们日常工作的支持？谁需要维护、管理和维持系统的日常运行？系统需要控制哪些硬件设备？系统需要与哪些其它系统交互？哪些人/系统对系统产生的结果感兴趣？2.确定用例针对每个参与者从以下问题入手：参与者为什么要使用该系统或需要系统提供哪些功能？参与者是否会在系统中创建、修改、删除、访问、存储数据？若是的话，参与者又是如何来完成这些操作的？参与者是否会将外部的某些事件通知给该系统？系统是否会将内部的某些事件通知该参与者？对同一个项目，不同的开发者选取的用例数可能不同。例如一个10人年规模的项目，有人选取了20个用例，有人选用了100个用例。似乎20个太少，而100个太多，因此需要在项目建模中找到一个昀好或较好的用例模型。会出现的情况3、调整与检查用例模型在用例模型中除了参与者和用例之间的关系外，还要描述参与者与参与者之间的泛化(generalization)、用例和用例之间的包含(include)、扩展(extend)和泛化(generalization)关系。通过调整把一些公共的信息抽取出来重用，使得用例模型更易于维护。但要注意模型调整通常都是在建模后期完成，为的是避免不必要的复杂化．对模型检查的重点•功能需求的完备性检查是否还有系统功能没有被记录在现有的用例模型中，抽象一些新的用例或是归纳到原有用例中•模型是否易于理解考察模型是否易于被不同的涉众所理解，可能需要修改用例的粒度、个数以及模型元素之间的关系复杂程度等内容•是否存在不一致性要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。•避免二义性语义好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。如何确定用例间的关系包含：提取公共交互，提高复用泛化：同一业务目的的不同实现技术扩展：“冻结”基用例以保持稳定包含(inclusion)：是指基础用例会用到的包含用例，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例──是多个用例的公共用例。泛化(generalization)：描述同一业务目标的不同实现。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。扩展(extend)： 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点 扩展用例的行为是否被执行要取决于主事件流中的判定点。将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。扩展用例举例：用例与扩展用例的区别①相对于基础用例，扩展用例是可选的，而包含用例则不是。②如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。③扩展用例的执行需要满足某种条件，而包含用例不需要。④扩展用例的执行会改变基础用例的行为，而包含用例不会。八、领域建模•领域建模是对业务领域描述，并用模型方式展示，重要的是用该领域的术语进行描述。•它是一个真实世界的模型–类似于实体关系模型（协助设计者理解）•该模型记录像是一个类图•便于‘Seamlessdevelopment’–对于分析和设计使用同一种注释–设计可以是从初始的领域模型中演化而来针对餐馆系统是：顾客和预定•该系统的基本商业内情是:顾客制造预定可建造他们初步模型：包含预定餐桌特性的领域模型考虑预定行为中需要记录的信息，以及餐桌分配和调换的因素要加上一个餐桌类形成：由于该限定无法用UML图形化表示，因此用非形式化给出约束。泛化的使用：考虑未预约客户管理需要•一个超类可以用来表示不同定单类型的特性共享，这就是“booking”，未预约是预约的一个泛化。领域词汇表建立领域词汇表可以对今后的描述进行规范。•预约单(Booking):针对一个餐桌的就餐预约•就餐人数(Covers):对于就餐预约中的人数说明•顾客（Customer):提出预约就餐的人•预约（Reservation）:预约的一次就餐•未预约（Walk-in）:没有提前预约的一次就餐•位子（Places):一个餐桌能够就坐的数量作业2对一个简化了的银行储蓄账户管理系统进行业务建模。该系统可完成在银行的柜台上对客户办理活期储蓄业务。系统的需求陈述如下： 一个客户可以在多个银行中开设账户，一个客户也可在同一银行中开设多个不同的账户。 客户可以通过银行职员进行开户、存款、取款、转账、注销账户等活动。其中转账指客户将自己的某个账户上的钱款转入同一银行的不同账户（称为银行内转账）或转入不同银行的账户（称为银行间转账）。 系统管理员负责系统的账户管理及业务报表的生成。完成：确定参与者，确定用例，画出用例模型图，给出开户和取款事件的基本流程描述。