业务建模及用例建模

面向对象分析与设计Object-OrientedAnalysis&Design-2-学习路线图OOUMLOOPDP…Case-Study…学习路线图::……………………12345678910核心过程-3-业务建模BusinessModeling-5-开发过程解析•业务建模：用软件建模方法描述业务流程；其目标是认识业务本质，该业务本质是后续用例建模的基础•用例建模：采用UML用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入•用例分析：采用UML用例分析技术分析软件需求，建立软件系统的分析模型•架构设计：在系统的全局范围内，以分析模型为基础，设计系统的架构•构件设计：根据架构设计的成果，将分析模型细化，设计系统构件的实现细节•代码实现：将系统构件映射到目标语言上-6-业务•业务是指某个组织或者组织单元•业务可以看作一种包含了人、机器、资源的“系统”•利用软件思想(用例思想、对象思想)描述业务的过程，就是业务建模–业务建模只是辅助环节–不是所有项目都需要–也不一定和软件开发相关-7-业务建模•业务建模的目的•理解将要实施的系统的组织结构和动态特性–理解当前在目标组织中的问题，并明确改进的潜力–确保客户、最终用户和开发人员对目标组织有统一的理解–获取用于支持目标组织的系统需求•业务建模关注–机构的核心价值–机构的边界–机构的参与者–机构中的工作流及如何优化-8-业务建模方法•研究对象–软件要改进的业务单元•研究目标–定义业务本质•研究方法–用例观点：把业务看成对外提供价值的价值流-9-业务建模工件•业务用例模型(BusinessUse-CaseModel)–业务用户表示为业务参与者(BusinessActor)–业务过程表示为业务用例(BusinessUse-Case)和业务用例实现•业务对象模型(BusinessObjectModel)–人们在组织中扮演的角色表示为业务工人(BusinessWorker)–组织管理或制造的“东西”表示为业务实体(BusinessEntity)-10-业务建模流程•0.建立业务用例模型–1.识别业务参与者–2.识别业务用例–3.详述业务用例•4.建立业务对象模型-11-业务建模流程•0.建立业务用例模型–1.识别业务参与者–2.识别业务用例–3.详述业务用例•1.建立业务对象模型-12-1.业务参与者(BusinessActor)•识别业务参与者–在业务之外，与业务进行交互的人或组织-13-区分业务工人(BusinessWorker)•业务参与者在业务外面•业务工人在业务里面储户营业员-14-区分业务实体(BusinessEntity)营业员经理帐户取款机点钞机储户-15-识别业务参与者思路•客户•供应商•合作伙伴•潜在客户•政府•组织中未建模部分•……-16-2.业务用例(BusinessUseCase)•识别业务用例–业务为业务参与者提供的价值–体现企业业务本质，是有意义的目标看清楚了，我就是业务用例-17-业务用例与业务参与者取款存款储户转帐企业贷款食客吃饭-18-识别业务用例的方法•直接获得：从业务参与者的角度，从外部推导出来•拼装：从里面往外面看，内部业务流程的目标是什么业务工人业务工人活动活动直接获得拼装-19-从业务流程拼装业务用例•业务流程–1.收款人在支票背后签名，写上身份证件号码，把支票和身份证件交给营业员–2.营业员核对印章正确且证件有效–3.营业员操作营业受理系统，办理支票兑现手续–4.营业员把现金和证件交给交款人收款人兑现支票-20-识别业务用例-支持性事件•不要遗漏支撑性业务流程背后的业务用例•支持性事件–人员的发展与维护–业务内部IT的开发与维护–办公室的设立与维护–安全性–法律活动•例：公司为什么要举行足球比赛？董事会提高员工士气-21-3.详述业务用例•业务用例是对业务流程的封装，在业务建模过程中需要逐一描述其内部细节，即详述业务用例•目的–详细说明业务用例的工作流程–说明业务用例的工作流程，以便于客户、用户和涉众理解-22-三种可选技术文字活动图顺序图-23-选择合适的技术•只有文字–不生动，不便于和客户交流•只有活动图–难以表达所有细节•业务用例文档中插入活动图•活动图中插入文字(+注释+基本路径)•顺序图(需要涉及到业务对象模型)-24-细说活动图-25-细说活动图(1)•起点、终点–活动的一种特殊形式，各自只有一个–起点：只有离开的转移–终点：只有进入的转移–存在从起点出发，到达终点的路径•活动和动作–有进有出–动宾结构–可以简单，可以复杂•分区–定义活动的负责者-26-细说活动图(2)•控制流–向外转移的条件之和必须是完备集–向外转移的条件之间不能重叠•决策点–注意和流程图的区别–误把活动当决策•图中判断“技术可行性”需要单独的活动来完成[无空位][有空位]-27-细说活动图(3)•并发(concurrent)•同步条(synchronizationbar)的分叉(fork)与合并(join)–有分必有合–有分必有进–有合必有出–并发≠同时-28-活动图中的对象流•指定活动操作的数据(对象)以及数据的流向(对象流)–业务对象(businessobjects)、对象流(objectflows)–指出对某些业务实体的操作，类似结构化中的数据流图–UML2中对象流由原来的虚线改为实线-29-活动图的分层•活动可以简单可以复杂，复杂的活动可以进一步细化：分层–顶层有起点终点，下层可以没有–出入平衡-30-4.业务对象模型•业务对象模型(BusinessObjectModel)–勾勒出实现业务关系中的人、事物、设备、资源以及它们之间的关系；即业务工人和业务实体之间的静态关系–从另一个视角描述现实–使用UML类图描述–不要和待开发系统中的分析设计类相混淆-31-餐馆的业务对象模型厨师菜肴1..*111..*负责服务员领位员雇员-32-业务建模实践：建模指南•业务模型不是UML标准直接支持的，但是通过UML的扩展机制可以很方便的建立业务模型•主要构造型(stereotype)–业务用例模型•参与者的构造型：业务参与者(BusinessActor)•用例的构造型：业务用例(BusinessUseCase)–业务对象模型•类的构造型：业务工人(BusinessWorker)、业务实体(BusinessEntity)-33-建模指南：模型的组织•利用“包”组织模型•用例视图中–“业务用例模型”–每个业务用例的”状态/活动模型”•逻辑视图中–“业务对象模型”-34-建模指南：使用构造型•业务用例模型是在UML的用例模型(用例图)基础上添加构造型来实现的•业务对象模型是在UML的对象模型(类图)基础上添加构造型来实现的–利用已有元素添加构造型–Rose直接支持这些构造型-35-业务建模实践：实例分析•研究对象：某旅店•业务现状：–某旅店可对外开放50个双人间和20个单人间，房间费用视情况按季节调整，但周一到周五提供半价（周末全价）折扣–旅客可以直接入住房间(如果有空房)，也可提前预订；入住和预订都需要登记个人信息–旅客提前预订房间时，需提交一定的订金；入住时间24小时之外的旅客可以取消预订，并退回所有订金，24小时以内则不退还订金–退房时缴纳全部的住宿费用–服务员每月为经理提供房间的预订情况和入住情况的详细信息-36-实例分析：业务用例模型旅店的本质就是为旅客提供住宿服务，其它的只是为达到这个目标而采用的手段(用例观点：把业务看成对外提供价值的价值流)-37-实例分析：旅客住宿业务流程-38-实例分析：检查业务用例模型•该业务用例模型体现了整个旅店的业务需求吗？•如何考虑这项业务：服务员每月为经理提供房间的预订情况和入住情况的详细信息？–经理是什么，如何体现在业务建模过程中？–是业务参与者还是业务工人？体现怎样的业务本质的差异？-39-实例分析：业务对象模型-40-从业务模型到系统模型•对于软件开发而言，业务建模只是辅助环节，并不是最终目标–软件工程师最终目标是要构造软件系统–业务建模则是一种定义系统模型的辅助手段•从业务模型到系统模型–业务模型描述了目前的业务现状–系统模型才是软件开发的最终工件-41-业务模型为系统模型提供素材•为用例视图和逻辑视图提供输入–对于每个将被系统实现的业务用例，在用例视图中确定一个系统用例或用例包（或单独的子系统）来实现该业务–为需要支持自动化业务确定相应的用例–对于业务对象模型中的业务实体，可以在系统模型中定义对应的实体类•为系统构架提供一些重要的构架机制–在软件构架中定义专用层来实现复杂的业务逻辑-42-业务模型映射到系统模型•从业务改进点入手，结合系统远景，可以帮助获取系统模型•可能的对应关系(并非一一对应)–业务用例系统(子系统)–业务参与者系统参与者–业务工人系统参与者–业务工人的操作(活动)系统用例–业务实体实体类用例建模UseCaseModeling-44-内容安排•理解需求•从业务模型获取需求•建立用例模型•编写用例文档•重构用例模型•其它问题-45-内容安排•理解需求•从业务模型获取需求•建立用例模型•编写用例文档•重构用例模型•其它问题-46-需求—建造“正确”的系统•需求：客户可接受的、系统必须满足的条件或具备的能力•RUP中的FURPS+软件质量准则–功能性（Functionality）–使用性（Usability）–可靠性（Reliability）–性能（Performance）–可支持性（Supportability）–+非功能性需求需求工程的主要活动•定义需求–理解用户的需要，建立用户可理解的系统需求模型分析需求–根据需求模型，建立开发者无二义性解释的分析模型–需求管理-47--48-需求难在何处：石头问题•我要一块石头…•差不多，但我要小一点的…•很好，不过我要蓝色的…•啊，没有那么小…•咳，还是原来那个好了…小一点的蓝色大理石难捕获，易变！-49-需求：也需要开发客户/用户的要求/想法/期望软件设计软件产品开发编码和测试验收有价值的软件需求分析和设计-50-需求问题：对策难捕获易变从用户视角看问题合理的结构用例-51-内容安排•理解需求•从业务模型获取需求•用例建模流程–获取原始需求–构建初始用例模型–编写用例文档–重构用例模型-52-从业务模型获取需求•有业务模型–从业务用例模型中寻找系统改进点–结合系统远景，获取系统用例来表达需求•采用需求启发技术，从涉众获得-53-从业务模型获取需求•从业务用例模型中获取系统需求，来构建系统用例模型–1.寻找业务改进点–2.定义项目远景–3.导出系统需求-54-1.业务改进点•业务模型描述业务现状，这些现状：–有些可能一直运转的很好，不需要改进，也就没有必要作为软件需求来由系统实现–而另外可能更多的业务在运转过程中存在这样或那样的问题，这些问题就成为业务待改进的改进点，也就很可能作为软件需求而存在-55-寻找业务改进点•从业务流程中获取改进点的思路：–信息的自动流转–演绎复杂业务逻辑–访问和操作业务对象–自动工作–……-56-2.远景(Vision)•系统改进点不等同于软件需求–用户根据自身的工作特点和支付能力决定哪些应该改进，哪些不需要改进–这就是用户的远景，它表明用户改进的目标，这也将成为项目的目标•业务模型描述了“现实是什么”，远景则描述“希望的改进”–远景表达了“为什么要开发这个系统”–在业务现状(业务模型)下，开发系统是为了达到什么目标？-57-定义项目远景•远景包含了对待开发系统的目标和约束–代表了项目涉及的所有人之间达成的第一个共识–是项目核心需求的概览–为更详细的技术需求提供了契约性的依据–指导团队实现具体的业务目标•远景的作用–最初，根据项目的远景目标来决定项目是否值得继续–在项目批准后，团队根据项目远景来指导后续的需求和设计-58-远景说明•远景可以作为一个单独的文档存在，而这其中最重要的部分就是关于远景目标的说明，它建立了一个项目涉及的所有人的共同目标•远景说明应该是精确、清晰和激励性的描述，以便激励所有的团队成员为