ch04_UML核心元素

第三章UML核心元素3.1版型3.2参与者3.3用例3.4边界3.5业务实体3.6包3.7分析类3.8设计类3.9关系3.10组件3.11节点版型(stereotype)有些书也称类型、构造型——对UML中元素基础定义的扩展UML中每一种元模型很多版型如，用例有“业务用例”、“业务用例实现”等类，“接口”、“边界类”、“实体类”NewInterfaceNewInterface2InterfaceNewInterface3NewClassNewClass2NewClass3NewClass4NewClass53.2参与者(actor)一幅用例图包含的模型元素有系统、参与者、用例及用例之间的关系。系统系统被看作是一个提供用例的黑盒子代表系统的方框的边线表示系统的边界，用于划定系统的功能范围，定义了系统所具有的功能描述该系统功能的用例置于方框内代表外部实体的行为者置于方框外用例图示例3.2.1基本概念参与者(actor)是系统的直接外部用户—直接与系统通信的一个对象或一组对象。每个参与者都表示以某种方式对系统起作用的那些对象。参与者可以是人、设备和其他系统—任何与系统直接交互的事物。参与者有一个明确的用途。建模参与者有助于定义系统，识别系统内部及其边界上的对象。注意：用例总是由行为者启动的。3.2.1.1参与者位于边界之外(I)场景：小王到银行去开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。谁是actor，小王、大厅经理、柜台职员？通过回答下面两个问题来确定：谁对系统有着明确的目标和要求并且主动发出动作？系统是为谁服务的？3.2.1.1参与者位于边界之外(II)小王是参与者(actor)，大厅经理和柜台职员是什么？他们可以被称为业务工人(businessworker)3.2.1.2参与者可以非人SaintPig如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。这里的Actor是小猪。思考：识别参与者？寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；在这个叙述里，谁是寻呼台系统的Actor？用户,气温,时间都是Actor3.2.2发现参与者在发现参与者的过程中，可以询问一下问题以帮助确定参与者：谁负责提供、使用或删除信息？谁将使用此功能？谁对某个特定功能感兴趣？在组织中的什么地方使用系统？谁负责支持和维护系统？系统有哪些外部资源？其他还有哪些系统将需要与系统进行交互？1、机票购买者通过登录网站购买机票，机票购买者就是actor2、机票购买者通过呼叫中心，由人工座席操作订票系统购买机票;人工座席是actor3、如果机票购买者通过呼叫中心的自动语音预订机票，那么呼叫中心就成了机票预订系统的一个actor4、如果扩大边界，让呼叫中心成为机票预订系统的一个子系统，机票购买者通过人工座席、自动语音及网站预订机票，那么机票购买者是actor，人工座席成了业务工人3.2.3业务主角(businessactor)业务主角是参与者的一个版型。业务主角是与业务系统有着交互的人和事物，他们来确定业务范围。业务主角针对的是业务人员。建立业务模型、查找业务用例都必须使用业务主角。识别业务主角的问题：业务主角的名称是否是客户的业务术语？业务主角的职责是否在客户的岗位手册里有对应的定义？业务主角的业务用例是否都是客户的业务术语？客户是否对业务主角能顺利理解？3.2.4业务工人(businessworker)有些人员参与了业务，但是被动参与的。应当被称为业务工人(businessworker)识别业务工人的问题：他是主动向系统发出动作的吗？他有完整的业务目标吗？系统是为他服务的吗？如果三个问题的答案是否定的，那一定是业务工人3.2.5参与者与涉众的关系涉众(stakeholder)，也称为干系人。涉众是与要建设的系统有利益相关的一切人和事，涉众的利益要求会影响到系统的建设。并不是所有的涉众都是系统的参与者参与者是涉众代表3.2.6参与者与用户的关系用户(user)是指系统的使用者。用户是参与者的代表、实例或代理。3.2.7参与者与角色的关系角色(role)是参与者的职责。一个用户可以代理多个参与者，一个用户可以拥有多个职责，即可以被指定多个角色。3.2.8参与者的核心地位参与者是涉众代表，他代表涉众对象对系统的利益要求，向系统提出建设要求；参与者通过代理给其他用户或将自身实例化成用户来实用系统；参与者的指责可以用角色来归纳。系统是以参与者的观点来决定的。3.2.9检查点是否已找到所有的参与者？每个参与者是否至少涉及一个用例？能否列出至少两名可以作为特定参与者的人员？是否有参与者与系统相关的相似角色？是否有两个参与者与用例相关的同一角色？特定的参与者是否将以几种方式实用系统？参与者是否有直观名称和描述性名称？3.3用例(Use-case)3.3.1基本概念用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。一个用例是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。一个场景是用例的实例。3.3.1基本概念完整的用例定义由参与者、前置条件、场景、后置条件构成。3.3.2用例的特征用例的特征：用例是相对独立的用例的执行结果对参与者来说是可观测的和有意义的用例由一个参与者发起一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。用例要点可观测→用例止于系统边界结果值→用例是有意义的目标系统执行→结果值由系统生成由参与者观测→业务语言、用户观点一组用例实例→用例的粒度要点：用例止于系统边界描述交互，而不是内在的系统活动要点：有意义的目标设定查询条件会员选择零件会员检索零件由参与者发起要点：业务语言而非技术语言用户词汇，而不是技术词汇如：发票，商品，洗衣机而不是：记录，字段，COM，C++等要点：用户观点而非系统观点订票旅客查看今日航班处理订票旅客显示今日航班用户观点系统观点用例VS.功能•呼叫某人•接听电话•发送短信•记住电话号码•……•传输/接收•电源/基站•输入输出（显示、键盘）•电话簿管理•……用户观点系统观点用例的命名执行者视角：（状语）动词+（定语+）宾语顾客购买商品信用卡支付extend3.3.3用例粒度用例的粒度以每个用例能够说明一件完整的事情为宜。要点：用例粒度-1用例要有路径，路径要有步骤；而这一切都是可观测的最常犯错误：粒度过细，陷入功能分解过细的粒度，一般都会导致技术语言的描述，而不再是业务语言用例粒度-2把步骤当用例把系统活动当用例会员输入用户名验证用户名和密码会员登录include查询订单建立数据库连接执行SQL语句includeinclude用例粒度-3“四轮马车”C(Create)R(Read)U(Update)D(Delete)所有业务最终对会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数据库的建模：“系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的删除用户修改用户增加用户管理员查询用户用例粒度-4如果确实是CRUD？如果CRUD不涉及复杂的交互，一个用例“管理××”即可不管是C、R、U、D，都是为了完成“管理”目标甚至很多种的基本数据管理都可以用一个用例表示管理员管理用户用例粒度-5灵活处理CRUD管理员管理用户增加用户extend可以把包含复杂交互的路径独立出去形成用例3.3.4用例的获得首先确定actor接下来，开始对actor即业务代表进行访谈您对系统有什么期望？您打算在这个系统里做些什么事情？您做这件事的目的是什么？您做完这件事希望有一个什么样的结果？3.3.4用例的获得--ATM客户代表说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以缴纳电话费、水费、电费等费用；为了安全起见，ATM上应该有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。3.3.4用例的获得--ATM支持跨行业务插入卡片输入密码选择服务取钱存钱挂失卡片交纳费用警示骗子三次错误吞没卡片×这是一个业务规则×这是一个过程步骤×这是一个过程步骤×这是一个过程步骤√这是一个有效的完整目标√这是一个有效的完整目标√这是一个有效的完整目标√这是一个有效的完整目标×超出有效的边界范围×这是一个业务规则3.3.5用例和功能的误区用例非常容易被误解和误用，最普遍的理解错误是认为用例就是功能的划分和描述。在描述事物时，我们可以从以下三个观点出发：这个事物是什么—结构性这个事物能做什么—功能性人们如何使用这个事物—使用者观点3.3.6目标和步骤的误区混淆目标和完成目标的步骤。一个用例是参与者对目标系统的一个愿望，一个完整的时间。以完整目标作为用例以步骤作为用例3.3.7用例粒度的误区另一个误区是在同一个需求阶段中的用例粒度大小不一。3.3.8业务用例业务用例(businessusecase)是用例版型中的一种，专门用于需求阶段的业务建模。既然业务用例是用于描述客户现有业务的，那么业务用例面对的问题域就是没有将来的计算机系统参与的、目前客观存在的业务领域。描述采用用户角度3.3.9业务用例实现业务用例实现(businessusecaserealization)，也称业务用例实例，是用例版型中的一种，专门用于需求阶段的业务建模。业务用例实现就是业务用例的一种实现方式。一个业务用例可以有多种实现方式。3.3.10概念用例作为概念模型中的核心元素，概念用例用来获取业务用力中的核心业务逻辑。3.3.11系统用例系统用例是用来定义系统范围、获取功能性需求的。3.3.12用例实现3.3.13用例关系includeextendExtendIncludeGeneralization通过关系整理文档Extend分离扩展路径Include提取公共步骤，便于复用Generalization同一业务目的的不同技术实现3.3.13.1包含关系(I)包含(include)关系将一个用例合并到另一个用例的行为序列中。被包含的用例就像是子程序—表示那些必须要重复描述的行为。包含关系UML的表示法从源(包含)用例指向目标用例(被包含)用例的一个带虚线的箭头，并用关键词《include》来注释箭头。3.3.13.1包含关系(II)也可以使用表示法includeuse-case-name将用例穿插到文本描述当中。不要用包含关系来组织行为的细节结构。用例建模的目的是确定系统的功能，以及参与者与系统之间通用的控制流。当片段可以表示重要的行为单元时，把用例分解成片段的做法是适宜的。包含关系某些步骤在多个用例重复出现，且单独形成价值用例步骤较多时，可用Include简化（慎用）下订单提供客户信息include包含关系误用填写注册信息验证注册信息充分生成用户名和密码保存注册信息潜在会员注册includeincludeincludeinclude3.3.13.2扩展关系(I)扩展(extend)关系给用例添加增量行为。从反方向来看，它很像是包含关系，扩展用例会把自己加入到基用例中，而不是基用例显式地合并扩展用例。它表示这样的常见的场合，首先定义某个初始功能，随后在模块化地增加特性。包含和扩展关系都给基用例添加行为。3.3.13.2扩展关系(II)扩展关系连接扩展用例和基用例。扩展用例经常也是片段--