umlUseCaseModeling.ppt

umlUseCaseModeling.ppt

《umlUseCaseModeling.ppt》由会员分享，可在线阅读，更多相关《umlUseCaseModeling.ppt（94页珍藏版）》请在冰豆网上搜索。

UML2面向对象分析与设计Object-OrientedAnalysis&DesignwithUML2,-2-,学习路线图,第04章用例建模,UseCaseModeling,-4-,内容安排,理解需求从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,-5-,内容安排,理解需求从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,-6-,需求建造“正确”的系统,需求：

客户可接受的、系统必须满足的条件或具备的能力RUP中的FURPS+软件质量准则功能性（Functionality）使用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）+,非功能性需求,需求工程的主要活动,定义需求理解用户的需要，建立用户可理解的系统需求模型（第四章）分析需求根据需求模型，建立开发者无二义性解释的分析模型（第五章）需求管理,-7-,-8-,需求难在何处：

石头问题,我要一块石头差不多，但我要小一点的很好，不过我要蓝色的啊，没有那么小咳，还是原来那个好了,小一点的蓝色大理石,难捕获，易变！

-9-,需求：

也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,编码和测试,验收,有价值的软件需求,分析和设计,-10-,需求问题：

对策,难捕获,易变,从用户视角看问题,合理的结构,用例,-11-,用例的昨天,UseCasesYesterday,TodayandTomorrow（IvarJacobson,TheRationalEdge,2003.3）萌芽期（1967-1986）IvarJacobson在爱立信，把各种不同类型的电话呼叫情况称为trafficcase，而完成所有呼叫则需要交换机具备相应的功能function或特征feature1986年，提出术语usecase1987年，OOPSLA86采用Jacobson论文，用例诞生成熟期（1987-1992）ObjectoryAB公司，以用例内容为核心的ObjectoryProcess（对象工厂过程）发展期（1992-）用例在面向对象方法中的应用，并成为UML的一部分,-12-,内容安排,理解需求从业务模型获取需求用例建模流程获取原始需求构建初始用例模型编写用例文档重构用例模型,-13-,从业务模型获取需求,有业务模型从业务用例模型中寻找系统改进点结合系统远景，获取系统用例来表达需求采用需求启发技术，从涉众获得,-14-,从业务模型获取需求,从业务用例模型中获取系统需求，来构建系统用例模型1.寻找业务改进点2.定义项目远景3.导出系统需求,-15-,1.业务改进点,业务模型描述业务现状，这些现状：

有些可能一直运转的很好，不需要改进，也就没有必要作为软件需求来由系统实现而另外可能更多的业务在运转过程中存在这样或那样的问题，这些问题就成为业务待改进的改进点，也就很可能作为软件需求而存在,-16-,寻找业务改进点,从业务流程中获取改进点的思路：

信息的自动流转演绎复杂业务逻辑访问和操作业务对象自动工作,-17-,2.远景（Vision）,系统改进点不等同于软件需求用户根据自身的工作特点和支付能力决定哪些应该改进，哪些不需要改进这就是用户的远景，它表明用户改进的目标，这也将成为项目的目标业务模型描述了“现实是什么”，远景则描述“希望的改进”远景表达了“为什么要开发这个系统”在业务现状（业务模型）下，开发系统是为了达到什么目标？

-18-,定义项目远景,远景包含了对待开发系统的目标和约束代表了项目涉及的所有人之间达成的第一个共识是项目核心需求的概览为更详细的技术需求提供了契约性的依据指导团队实现具体的业务目标远景的作用最初，根据项目的远景目标来决定项目是否值得继续在项目批准后，团队根据项目远景来指导后续的需求和设计,-19-,远景说明,远景可以作为一个单独的文档存在，而这其中最重要的部分就是关于远景目标的说明，它建立了一个项目涉及的所有人的共同目标远景说明应该是精确、清晰和激励性的描述，以便激励所有的团队成员为达成该远景而努力。

一个好的远景应该具有以下五个特点（SMART）：

具体的（Specific）可测量的（Measurable）可实现的（Achievable）相关的（Relevant）基于时间的（Time-based）,-20-,3.导出系统需求,从业务改进点入手，结合项目远景，导出系统需求：

对于每一个业务改进点，明确是否是为了达到远景目标的需要如果是则作为软件需求而存在，并把相应地模型作为系统模型如果不是则不作为需求而存在，可能作为一项潜在的需求考虑，也可能直接抛弃,-21-,实例分析：

旅店系统开发背景,随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间然而，随着预订的增多、预订周期的拉长，前台服务员工作压力也日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉带来不好的影响为此，旅店老板想到了计算机，希望能够通过计算机来自动管理这些预订业务，不过由于目前资金的问题，目前只开发一个单机版的系统，不提供网上业务；并且旅店方面的其它业务暂不考虑信息化问题旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合作事宜,-22-,远景：

旅店预订系统,A很荣幸地成为项目经理，并被要求在两个月之内发布该系统的第一个版本，同时还被要求要为后续的开发提供必备的接口结合现状和老板的要求，考虑到的项目可扩展的要求，A首先进行了简单的业务建模之后，A初步定义了项目的远景方便、快捷、准确地为旅客预订房间旅客可以方便的取消预订的房间旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息?

预留接口：

可以为以后的网络版，以及其它业务系统的开发提供支持,-23-,结合远景，获取系统需求,-24-,业务模型映射到系统模型思路,从业务改进点入手，结合系统远景，可以帮助获取系统模型可能的对应关系（并非一一对应）业务用例系统（子系统）业务参与者系统参与者业务工人系统参与者业务工人的操作（活动）系统用例业务实体实体类,-25-,内容安排,理解需求从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,-26-,1.需求从何而来,需求只能来自涉众（stakeholders）最终用户、客户政府、法律、文化开发人员、管理人员竞争对手但并不是直接从涉众中来你们的需求是什么？

-27-,涉众无法直接提供需求,涉众无法陈述自己的需要涉众说的是解决方案而不是需求涉众难以构想新的工作方法涉众的利益矛盾涉众抵制变更“最好也要有”过度的要求需求引发需求,-28-,需求启发技术,需求工程师利用需求启发技术，从涉众中发掘需求收集资料现场观察访谈开会原型问卷调查,-29-,2识别参与者（Actor）,识别参与者关键词：

边界参与者：

在系统之外，透过系统边界与系统进行有意义交互的任何事物,-30-,参与者要点分析,系统外参与者不是系统的一部分，处于系统的外部系统边界参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定系统角色参与者与使用系统的物理人和职务没有关系需要从参与系统的角色（作用）来寻找参与者与系统进行信息交互系统需要关注其交互过程，即系统职责任何事物人、外系统、外部因素、时间,-31-,要点：

与系统进行信息交互,-32-,要点：

任何事物,-33-,任何事物：

小人与圣小猪-1,-34-,小人与圣小猪-2,众所周知，用例图中的参与者用一个小人表示。

但是这个小人具有一定的误导性，往往让初学者（包括客户）理解为一个真实的人。

大多数UML学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。

那么为什么不干脆用其它的符号来表示参与者呢？

如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。

显然，这里的参与者是小猪。

那么在用例图里用小猪代替原来的小人不是更易于交流吗？

-35-,思考：

参与者与系统边界？

某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分,-36-,识别参与者的思路,可以从以下要点来识别参与者系统在哪些部门使用谁向系统提供信息、使用和删除信息。

谁与系统的需求有关联谁使用系统的功能（用例）谁对系统进行维护与外部系统是否有关联时间参与者：

一种习惯用法，用于激活那些系统定期的、自动执行的用例,-37-,参与者的命名,对参与者赋予能更好地表达其角色（作用）的名称不好的参与者命名的例子：

用职务名称和个人姓名来命名例如，张三、老李、校长、科长若使用系统的人（职务名称）变化的话，就不是参与者了好的参与者命名的例子：

用能知道其角色的名称来命名例如，学生、订单管理员、维护部门即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的。

-38-,参与者之间的关系：

泛化,参与者可以通过泛化关系来定义，在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的参与者所共享如系统中经理可以参加雇员的所有用例,-39-,参与者地位,识别用例之前重要有助于识别用例，宁多勿少开始书写用例文档以后不重要涉及的参与者太多测试和部署阶段重要需要从参与者的角度考虑,-40-,3识别用例,关键词：

价值定义用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例（场景）简洁：

参与者使用系统达到某个目标,-41-,用例要点,可观测用例止于系统边界结果值用例是有意义的目标系统执行结果值由系统生成由参与者观测业务语言、用户观点一组用例实例用例的粒度,-42-,要点：

有意义的目标,-43-,要点：

结果值由系统生成,系统需要处理的，由系统生成,-44-,要点：

用户观点而非系统观点,用户观点,系统观点,-45-,用例的命名,参与者视角：

（状语）动词+（定语+）宾语,-46-,要点：

用例粒度-1,用例是一组用例实例的抽象；其内部要有路径，路径要有步骤最常犯错误：

粒度过细，陷入功能分解通过执行用例，参与者完成想做的事情（最终的目的），并为参与者产生价值过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,-47-,用例粒度-2,把步骤当用例把系统活动当用例,-48-,用例粒度-3,“四轮马车”C（Create）R（Read）U（Update）D（Delete）所有业务最终对会成为CRUD？

CRUD能为Actor提供价值？

CRUD掩盖业务，锐变成关系数据库的建模：

“系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的,-49-,用例粒度-4,如果确实是CRUD？

如果CRUD不涉及复杂的交互，一个用例“管理”即可不管是C、R、U、D，都是为了完成“管理”目标甚至很多种的基本数据管理都可以用一个用例表示,-50-,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,-51-,找出用例的思路,用例要考虑如下要点来寻找。

参与者的工作是什么参与者的角色（作用）是什么参与者是否生成、参照、删除系统信息参与者是否需要把外部变更通知给系统系统是否需要把内部事情通知给参与者是否存在进行系统维护的用例用例数量的参考基准1个系统中存在十几个用例（或更少）1个用例中有多个用例实例（场景）,-52-,4构建用例图,用例图：

表达参与者与用例关系图形,-53-,实例分析：

旅游业务申请系统,阅读“旅游业务申请系统”问题陈述识别系统参与者识别系统用例构建用例图,获取系统参与者,-54-,从参与者的角度获取用例,-55-,旅游业务申请系统参考用例图,-56-,-57-,内容安排,从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,-58-,撰写用例文档,用例文档：

更进一步的精度需求规格说明书的核心，而用例图作为用例文档的索引图进