UML概念.pptx

UML基本元素类——版型（sterotype)版型或称类型、构造型，UML几乎每个元模型都有很多版型。如下各种类别里包含各种对应版型用例——业务用例、业务用例实例类——接口、边界类、实体类、控制类参与者参与者或角色，可以非人；参与了业务的人可叫业务工人。参与者可以是：计算机系统、计时器、传感器、JMS消息搞清参与者：在参与者即涉众中找出 直接对系统发出动作，或直接从系统中接收反馈的涉众，或客户的岗位设置；还搞不清可假定参与者与客户代表访谈并列举事情然后和其他客户代表访谈并列举事情，分析假定参与者在系统中做的事情找出共性与客户敲定。访谈可了解以下信息确定参与者：负责提供、使用或删除信息的人；将使用此功能的人；对某个特定功能感兴趣的人；在组织中什么地方使用系统；负责支持和维护系统的人；系统有的外部资源；其他将要与该系统交互的系统。例图见P45机票预定系统直接参与者可以是机票购买者、人工坐席、呼叫中心、如呼叫中心成了系统的子系统，则机票购买者还是业务主角，人工坐席变成业务工人。业务主角是与业务系统有交互的人事物，用以确定业务范围，业务主角是参与者的一个版型。从功能性需求来说系统范围是业务范围的一个子集，但如操作日志这样的系统功能则会超出业务范围，判定方式是业务范围中的业务有没有计算机系统参与都客观存在。要确定业务主角需知：业务主角在实际业务里能找到对应的岗位或人员，业务主角的名称是否是客户的业务术语，业务主角的职责是否在客户的岗位手册里有对应的定义，业务主角的业务用例是否都是客户的专业术语，客户是否对业务主角能顺利理解。业务工人搞清业务主角和业务工人：如下述三个问题的答案为否，则可判定是业务工人。1.他是主动向系统发出动作的吗？2.他有完整的业务目标吗？3.系统是为他服务的吗?涉众—参与者涉众：干系人。只要和系统有利益关系的都是涉众。不是所有涉众都是参与者。参与者是涉众代表，他们的要求是系统需求的来源。通过对系统提出要求获得他代表的涉众利益。用户—参与者用户。系统的使用者、操作人。用户是参与者的代表（代理），或是参与者的实例。不是所有参与者都是用户，但一个用户可以代理多个参与者。如：局长分正局长和副局长，实际只有副局长最终使用系统，则副局长就作为局长这一参与者的实例来使用系统。角色—参与者角色。从众多参与者职责中抽象出相同的那一部分，将其命名而形成一个角色，代表了系统中一类职责，可增加系统灵活性。如命名一个文件审批者角色来代表审批文件这一职责。一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，即可以被指定多个角色。 参与者通过代理给其他用户或将自身实例化成用户来使用系统，参与者的职责可以用角色来归纳，用户被指定扮演哪个或哪些角色因此来获得参与者的职责。参与者对系统的要求、表述完全决定了系统的功能性。 建立所有参与者检查点： 1.找到并说明所有用例可确定是否对系统环境中所有角色都进行了说明和建模。 2.每个参与者至少涉及一个用例，删除与用例无通信关系的所有参与者。 3.是否列出至少两名可疑作为特定参与者的人员，如不能，需检查参与者所建模的角色是否为另一角色的一部分，如有将该参与者与另一参与者合并。 4.有参与者担任与系统相关的相似角色将他们合并到一个主角中，通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。 5.有两个参与者担任和用例相关的同一角色，如果有该用参与者泛化关系来为他们的共享行为建立模型。 6.特定参与者如用几种方式使用系统或他涉及的用例是处于几种使用目的，应该多建几个参与者。 7.参与者是否有直观名称和描述性名称，并保证客户和用户理解，且务必要与角色相符。UML元素——用例用例除用例外其他元素都是封装、独立的。用例的来源是参与者对系统的期望。用例：它定义了一组用例实例，每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值；是与参与者(actor)交互的，并给参与者提供可观测的有意义有结果的一系列活动集合。即达成一件事情是由不同情况的集合构成的，在UML中一个用例的实例就是用例场景。完整的用例：参与者、前置条件、场景、后置条件构成用例作用：捕捉功能性需求，使参与者所有愿望都通过用例达到，则系统被确定。用例特征用例相互独立；用例的执行结构对参与者来说是可观测的和有意义的；用例不能自动启动，应由参与者发起；用例必然以动宾短语出现，如喝水、计算、统计、报表、输出、录入；单个用例即为需求单元、分析单元、设计、开发、测试、部署单元；用例粒度 用例分析阶段：用例粒度以每个用例能描述一个完整的事件流为宜，即一个用例描述一项完整业务中第一个步骤。但前提需归纳和抽象出业务用例中的关键概念模型并为之建模。如申请报装与申请迁移用例可归纳分解为提供申请资料、受理业务、现场安装等多个业务流程中都会使