UML系统分析与设计教程(第2版)第6章
UML 的图_UML系统分析与设计教程（第2版）_[共2页]
![UML 的图_UML系统分析与设计教程（第2版）_[共2页]](https://img.taocdn.com/s3/m/b216080c6f1aff00bed51ede.png)
68 图捕捉。
这5个视是彼此相关、交互作用的，运用这5个视，可对软件系统进行全方位的描述。
但并不是所有的软件系统建模都需要这5个视，譬如运行在单机上的软件系统就不需要部署视。
当然，也可以根据需要添加视，譬如，为安全性很关键的软件系统建模时，可以添加安全视来描述系统的安全性解决方案。
5.2 UML的图UML是用来对软件系统的产物进行可视化、规范定义、构造并为之建立文档的建模语言。
模型建立的可视化为设计人员、开发人员、用户和领域专家之间的交流提供了便利；规范定义意味着UML建立的模型是准确的、无歧义的、完整的；构造意味着可以将UML模型映射到代码实现；UML还可以为系统的体系结构以及系统的所有细节建立文档。
UML为软件系统建模提供了强大的支持，并提供了很大的自由度。
开发人员在迭代的递增式开发过程中，可以根据所开发系统的特点，在每次迭代的微过程（分析、设计、实现、测试和配置）中，灵活地选用UML所提供的各种图。
UML1.x定义了9种图为软件系统建模，而新版的UML2.0则定义了13种图，这些图从不同应用层次和不同角度为软件系统从系统分析、设计直到实现等阶段提供了有力支持。
而且，这些图为系统在不同的阶段建立不同的模型，建模的目的也各不相同。
UML的13种图如下（其中顺序图和通信图放在一起介绍）。
（1）类图（Class Diagram）。
类图描述了类、接口、协作以及它们之间的关系。
类图是在面向对象系统建模中最重要的常用图，它描述了系统的静态设计视和静态互动视。
（2）对象图（Object Diagram）。
对象图描述了对象以及对象间的关系。
如同类图一样，对象图从实例的角度描述了系统的静态设计视和静态互动视。
（3）组件图（Component Diagram）。
组件图描述了组成软件系统的组件间的相互关系、交互作用和组件的公共接口。
组件图描述了系统的静态实现视。
一般来说，软件组件就是一个实际文件，它可以是源代码文件、二进制代码文件、可执行文件、脚本、表等，并可以用来说明编译、链接或执行时组件之间的依赖关系。
第6章 用例图
3、构建用例模型
采 购 员 用 例 图
采购员能够通过该系统进行订货管理活动。采购员首先根据经营情 况统计所缺的生产资料，根据需要制定出订单。
UML统一建模语言
五、使用Rose创建用例图的步骤说明
3、构建用例模型
会 计 用 例 图
会计负责产品的统计分析 管理，它能够通过该系统 进行如下活动： （1）查询基本信息。会计 能够查询产品的基本信息， 根据产品的基本信息，制 定出相应的方案。 （2）查询销售信息。会计 根据销售情况汇总后交销 售部制定合理的销售方案。 （3）查询供应商信息。会 计能够查询供应商信息。 （4）查询缺货信息。会计 能够查询缺货信息。 （5）查询报损信息。会计 能够查询报损信息。
1、需求分析
“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息 统计订货的，并制作产品订单。最后根据订单进行采购活动。 （2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、 处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产 品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及 时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进 行出库处理。 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、 查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使 用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定 价计算出产品的总价，客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、 供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登 录到各自的管理系统中。
UML系统分析与设计教程第二版教学设计
UML系统分析与设计教程第二版教学设计介绍UML是一种被广泛使用的面向对象分析和设计（OOAD）工具，可以用来模拟软件开发中的流程。
本教程将提供UML系统分析与设计的教学设计，适用于学生、软件工程师或任何想了解UML的人。
教学目标通过学习本课程，学生应能掌握以下技能：•理解和运用UML的核心概念和通用建模技术•使用UML对软件进行系统建模和分析•对复杂系统进行建模和分析教学重点•UML的基本概念和原则•UML图形的使用方法和含义•对系统进行建模和分析的方法和流程教学大纲第一节：UML简介•UML的定义和用途•UML图形的分类与含义•UML的优点和局限性第二节：UML基础知识•UML核心概念和原则•类图、时序图和用例图的基本元素和使用方法第三节：UML高级应用•组合、聚合和泛化的区别•状态图和活动图的建模技术•UML建模规范的介绍和应用第四节：UML与软件开发•UML的集成开发环境•使用UML进行软件架构设计•对UML进行版本控制和文档管理教学方法该课程采用理论和实践相结合的教学方法。
学生将在课堂上学习UML的基础知识，然后使用软件进行实操操作。
通过实践，学生能够更好地理解UML的实际运用，掌握UML建模和分析的技能。
基本要求•学生需要具备基本的编程知识和计算机应用能力•学生需要了解面向对象编程（OOP）的概念和基本语法•学生需要有一台个人电脑，并安装适合的UML建模工具教学评估教师将在每节课程结束后进行小测验，以检查学生的理解情况。
此外，教师还将指导学生完成一个UML建模的小项目，并进行评估。
评估成绩将计入学生的课程成绩和期末考试成绩。
结语随着软件开发的不断发展，UML已成为了重要的建模和分析工具。
本教程将帮助学生了解和掌握UML的核心概念和基本技术，提高软件建模和分析的能力，为未来的工作奠定基础。
UML与系统分析设计第二版 第6章 交互图.ppt
在UML2.0中提供了对系统动态行为建模的四大类图形： Use Case图、交互图、状态机图和活动图。
交互图（Interaction Diagram）主要表现对象之间是如何进 行交互和通信的。
交互图主要用于对Use Case中的控制流的建模。一般情况下， 一个交互图表达单个Use Case的行为，它表示出该Use Case 中的若干个实例对象和对象之间所传递的消息。
命线表示为从对象图标向下延伸的一条虚线。 3．激活期 激活期（Activation）又称为控制焦点（Focus of control），表示对象执行一个动作的期间，也即对象激 活的时间段。 激活期由位于生命线上的一个窄矩形框表示。 当一个对象在激活期时，该对象处于激活状态，能够响 应或发送消息，执行动作或活动。当一个对象不在激活 期时，该对象处于休眠状态，什么事都不做，但它仍然 存在，等待新的消息来激活它。
Home
6.1.1 顺序图的组成
4．消息 消息（Message）表示对象之间的通信，对象之间的交互通过互发消
息来实现，消息将触发接受对象中的特定操作。 。 在顺序图中消息用对象角色之间的一条水平箭线表示。消息箭线从
源对象指向目标对象，其上标有消息内容标签。 消息内容标签的格式为：
序号 [保安条件] *[循环] 返回表：= 操作名（参数表） 序号为消息在整个交互中的顺序号。 保安条件（Guard Condition）是一个布尔条件表达式。只有当其保
6.1.3 同步消息与异步消息
同步消息（Synchronous massage）代表一个通过操作调 用的嵌套的控制流，该操作调用要求操作同步。
同步消息的发送者把控制传递给消息的接收者，然后暂 停活动，等待消息接收者放弃或返回控制。
习 题_UML系统分析与设计教程（第2版）_[共2页]
![习 题_UML系统分析与设计教程（第2版）_[共2页]](https://img.taocdn.com/s3/m/5c2b4c2e0242a8956bece4db.png)
同样的技术也可以用于为子系统的需求建模。
对于图6.7所示的公司管理系统，该用例图可视化地描述了公司管理系统的功能需求，为最终用户、领域专家和开发人员之间的交流提供了途径。
该系统的重要行为包括雇员可以选择得到报酬的方式（用例“Select Payment Method”），可以对雇员进行考勤（用例“Maintain Timecard”），雇员可以创建工作报告（用例“Create Employee Report”），考勤记录和工作报告要保存在数据库中（用例“Maintain Timecard”和“Create Employee Report”与参与者“Project Management DB”通信，将数据保存在数据库中），管理员可以创建、修改、删除系统中雇员的信息（用例“Maintain Employee Information”），每月的固定时间要通过银行系统给雇员发薪水（参与者“System Clock”与用例“Run Payroll”通信，说明发薪水的时间到了，触发用例的行为，用例“Run Payroll”与参与者“Bank System”通信，将薪水发给雇员），并通过打印机打印出工资单（用例“Run Payroll”与参与者“Printer”通信，调用打印机打印出工资单）。
小 结用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。
用例图（Use Case Diagram）是UML中用来对系统的动态方面进行建模的7种图之一。
用例图描述了用例、参与者以及它们之间的关系。
本章介绍了用例图的语义和功能，描述了如何识别参与者、用例，如何使用事件流描述用例；还介绍了用例和脚本的关系，举例说明了用例间的类属关系、包含关系和扩充关系的语义、功能和应用；最后举例说明了如何使用用例图为系统的上下文以及系统的需求建模。
习 题6.1 用例图的功能是什么？6.2 如何识别出参与者？如何识别出用例？6.3 用例间存在哪几种关系？6.4 分析下述课程管理系统的问题描述。
系统分析与设计——统一建模语言UML
北京理工珠海学院
6.1.2统一建模语言特点
（1）面向对象:支持面向对象技术的主要概念,提供 了一批基本的模型元素表示图形和方法,简明表 达面向对象的各种概念. （2）可视化:通过UML的模型图清晰表示系统的逻辑 模型和实现模型,还用于各种复杂系统的建模. （3）独立于过程:独立于开发过程. （4）独立于程序设计语言:建好的系统模型可用任何 面向对象的语言来实现. （5）易于掌握和使用:结构清晰,建模简明易于掌握
五类图
第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者 .
第二类是静态图 ，包括类图、对象图和包图 .
第三类是行为图,描述系统的动态模型和组成对象间的交互关系。行为图 包括：状态图、活动图、顺序图和协作图 第四类是交互图,描述对象间的交互关系。(顺序图显示对象之间的动态 合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互 ；合作图描述对象间的协作关系，显示对象间的动态合作关系和对象以 及它们之间的关系)。如果强调(时间和顺序，则使用顺序图)；如果强 调(上下级关系，则选择合作图)。这两种图合称为交互图. 第五类是实现图 ,其中构件图描述代码部件的物理结构及各部件之间的 依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个 可执行部件。它包含逻辑类或实现类的有关信息。构件图有助于分析和 理解部件之间的相互影响程度。
《include》 打印查询结果
(From Use Case View)
(From Use Case View)
北京理工珠海学院
案例：泛化、扩展关系
下面左图给出了一个扩展关系的例子，在还书的过程中， 只有在例外条件（读者遗失书籍）的情况下，才会执行赔 偿遗失书籍的分支流。 泛化关系：用例可以被特别列举为一个或多个子用例，这 被称做用例泛化。当父用例能够被使用时，任何子用例也 可以被使用。如在右图中，订票是电话订票和网上订票的 抽象。
UML系统分析与设计教程第二版教学设计 (3)
UML系统分析与设计教程第二版教学设计一、引言UML（Unified Modeling Language）是软件工程中广泛使用的一种建模语言，可以用于描述系统的结构、行为和交互。
UML系统分析与设计教程是一本经典的UML教材，在软件工程领域具有较高的知名度和影响力。
本文将介绍针对UML系统分析与设计教程第二版的教学设计，主要包括教学目标、教学策略、教学内容和教学评价等方面。
二、教学目标本次教学的主要目标是让学生掌握UML的基本概念、建模方法和应用技巧，具备使用UML进行软件系统设计和分析的能力，进一步提升学生的软件工程能力。
具体目标包括：1.理解UML的基本概念和历史背景；2.掌握UML的建模方法和图表符号的含义；3.能够使用UML进行系统需求分析和设计，并完成相应的UML图表；4.掌握UML的应用技巧，如设计模式和代码生成等。
三、教学策略1.教学以实践为主，通过实际的案例让学生熟悉UML的建模方法和应用技巧；2.强调理论与实践相结合，让学生在实际操作中巩固理论知识；3.强调团队合作，通过小组讨论和合作完成项目；4.强调自主学习和持续学习，让学生能够独立学习和掌握新技能。
四、教学内容本次教学的主要内容包括以下几个方面：1. UML基础1.1 UML的基本概念和历史背景； 1.2 UML的体系结构和核心组件； 1.3 UML 图表符号的含义和应用。
2. UML建模方法2.1 UML用例图； 2.2 UML类图； 2.3 UML时序图和活动图； 2.4 UML状态图。
3. UML应用技巧3.1 设计模式的应用； 3.2 代码生成和反向工程； 3.3 UML工具的使用。
五、教学评价本次教学的评价主要包括以下几个方面：1.学生的作业质量和完成度；2.学生对UML建模方法和应用技巧的掌握程度；3.学生对UML在软件系统设计中的应用理解程度；4.学生的课堂表现和团队合作能力。
六、总结通过本次教学，学生将深入学习和实践UML建模方法和应用技巧，为提高其软件工程综合能力奠定更坚实的基础。
系统设计与分析教程uml习题答案
系统设计与分析教程uml习题答案UML概述1. 请指出UML的三个主要的特性。
1）UML是⼀种语⾔2）UML是⽤来建模的3）UML是统⼀的标准2. 请指出三种以上现实⽣活中的常⽤模型，并说明它们分别在各⾃的领域中发挥了什么样的作⽤。
1）电路图：电⼦产品设计、⽣产、维修2）园区沙盘：直观、⽴体化地展⽰园区的景观、布局3）地图：导航、指路等3. 请简要说明建模的意义和建模的原则。
建议能够帮助我们按照实际情况或按我们需要的样式对系统进⾏可视化；提供⼀种详细说明系统的结构或⾏为的⽅法；给出⼀个指导系统构造的模板；对我们所做出的决策进⾏⽂档化在建模时应遵循以下原则：选择要创建什么模型对如何动⼿解决问题和如何形成解决⽅案有着意义深远的影响；每⼀种模型可以在不同的精度级别上表⽰；最好的模型是与现实相联系的；单个模型是不充分的。
对每个重要的系统最好⽤⼀组⼏乎独⽴的模型去处理4. 请说明蓝图和草图的区别，并简单描述其适⽤的场景。
蓝图⼀般是指采⽤C ASE⼯具绘制的、正式的、规范的UML模型；⽽草图则通常是指⼿⼯绘制的、规范度较低的在纸张的UML模型。
对于局部的、重要性不⾼的、共享范围较⼩的UML模型，直接将草图扫描到电脑存档即可；对于全局的、重要性⾼的、⾼度共享的，在草图的基础上⽤C ASE⼯具绘制成为正式的蓝图，并将其纳⼊统⼀的模型管理中5. 说明UML适⽤的建模领域，以及其作⽤和主要的参与⼈员。
业务建模，⽤来加强对业务领域的了解，以领域专家为主，需求分析⼈员是主⼒，系统分析员、架构师可参与。
需求模型，⽤来加强需求了解，便于技术决策，以需求分析⼈员为主，系统分析员是主⼒，领域专家提供指导，架构师和资深开发⼈员参与。
设计模型：包括⾼层设计模型和详细设计模型。
⾼层设计模型以架构师为主，系统分析员从需求⽅⾯提供⽀持，资深开发⼈员从技术实现⽅⾯提供⽀持。
详细设计模型则以资深开发⼈员为主，架构师提供指导。
实现模型：架构师、资深开发⼈员（设计⼈员）；以资深开发⼈员（设计⼈员）为主，架构师提供总体指导。
第6章 用例图1
4.部署模型：定义可计算节点系统的物理结构，并 验证运行在这些节点上的构件想法是否实现了 用例。（构件图、部署图） 5.测试模型：根据用例中所描述的功能来构建测试 模型。 采用用例技术的优点有： 一，用例表达了用户对软件的目标要求，用例是 系统向其用户提供的增值功能。 二，用例很直观，用户和客户根本无法了解复杂 符号，而用例这种简单、自然的表述法可以使 其易于阅读，并提出修改意见。
开发者与用户、客户进行交流，构建场景和用 例规格描述。一个场景就是描述用户与系统之 间的一系列交互活动，描述了系统一次具体执 行的行为路径，即，一次完整的事件流。
例：小刘通过银行柜员机(ATM系统)取款3000元的场景
场景名称
参与者
取款3000元
客户小刘
事件流 1 小刘将银行卡插入柜员机 2 ATM机要求客户输入卡密码 3 小刘输入卡密码，并确认密码 4 柜员机屏幕提示，请客户选择服务类型 5 小刘选择取款服务 6 柜员机提示：请客户输入取款数目 7 客户输入3000,并确认 8 柜员机出钱口输出30张一佰元的人民币 9 小刘取回30张一佰元的人民币 10 柜员机提示服务类型：确认，或继续，或退卡 11 小刘选择服务类型退卡，结束服务。
用户故事(user story) 特性(Feature)
用例驱动开发过程
•
•
知名的“用例驱动”的开发过程有两个，一个就是重型 的RUP，另一个则是“离地1000公尺”的ICONIX
•
在这些开发过程中，开发人员首先捕获客户的需求，并 以用例的形式组织成用例模型。然后分析并设计系统来 满足这些用例，因此在用例模型之后就是分析模型，接 着是设计模型和实施模型。在实现了整个系统之后，还 将根据用例模型设计出测试模型来对系统进行验证
第6章 面向对象与统一软件开发过程
图6-27确定了“账户管理”包包含几个由其他包中的类所Байду номын сангаас用的类，即“买 主账户管理”和“卖主账户管理”都使用“账户管理”包的“账户”类。
在分析阶段，从多个不同的分析类中抽取共享和公用的行为时应该使用泛 化。例如，“账单”和“订单”类有相似的职责。二者都是针对一般对象，如 “贸易”类的泛化，如图6-28所示。
下面给出了“取款”用况实现的事件流。 （1）银行储户选择“取款”并向“ATM接口”表明身份。 （2）“ATM接口”请求“事务管理”取款，“事务管理”负责将提取现金 的整个动作序列作为原子事务执行，以便从账户中扣除取款金额并将现金分发 给银行储户。 （3）“事务管理”请求“账户管理”取款，“账户管理”决定能否取出现 金。如果可以取款，则从账户中扣除取款的金额并返回应答； （4）“事务管理”授权“ATM接口”分发货币。 （5）“ATM接口”将现金分发给银行储户。
用况模型分析模型（概念性类元间的协作）设计模型（类元）
2．捕获用况
捕获用况是统一过程的第1个活动。 将功能性需求表示为用况模型中的用况，参与者在用况交互时使用系统， 系统的参与者和用况组成用况模型。
参与者可以是与系统发生交互的人活着其他系统活着外部硬件。参与者通 过执行用况与系统通信 用况规定了一个动作序列，系统执行用况并对特定参与者参数可见结果。
设计模型通过使用分析模型作为主要输入而被创建，其中要定义类元、类元 之间的关系及实现这些用况的动作，它相对于分析模型更加注重实际。分析模型 中的用况实现可跟踪到设计模型中的用况实现，图6-5给出了类的进一步细分。
图6-6给出了ATM基本的设计类图，该图比分析模型的类图展现了更多的细节。
图6-7给出了“取款”用况的部分顺序图。
第6章收集需求
2019/10/23
40
案例分析
第6章 收集需求
iCoot系统用例表
• U5：登录：会员使用会员号和当前 密码登录iCoot
• U6：查看会员信息：会员查看 iCoot存储的会员信息子集，例如 姓名、地址和信用卡信息
• U7：进行预约：会员在查看汽车型 号的细节时，预约一种汽车型号
• B2：会员预约汽车型号：当有该型 号的汽车时，会员应得到通知
• B3：非会员预约汽车型号：当有该 型号的汽车时，非会员交纳了押金， 就应得到通知
• B4：顾客取消预约：顾客通过电话 或亲自取消未结束的预约
2019/10/23
22
案例分析
第6章 收集需求
iCoot 业务用例表
• B5：顾客交还汽车：顾客交还所租 用的汽车
业务模型 [或领域模型]
补充需求
特征列表
2019/10/23
系统分析师 找出参与者和用例
第6章 收集需求
用例模型 [概况的] 项目词汇表
32
补充：小组成员分工
第6章 收集需求
系统分析师
设计师 用例阐释员 用户界面设计员
2019/10/23
找出参与者和用例
组织用例模型
优先排序用例
详细用例
原型化用户界面
U12: 注 销
U11: 取 消 预 约
U7: 进 行 预 约
助手
2019/10/23
43
用例调查
• 用例调查：说明一组用例如何 组合在一起
• 用例调查是开发人员与客户一 起研究用例图时生成的叙述
• 用例调查允许客户在没有开发 人员的帮助下，也能很好地理 解用例
6-状态模型
13
2）警戒条件（condition）
是指为了要让迁移发生而必须为真的布尔表达式。
例如：
当你早上出门的时候（事件），如果温度在零度以下（警戒条件）， 那你就要带手套（下一个状态）。
因此，警戒条件是在事件发生时被触发，检查一次条件，然后在条 件为真时，迁移才触发，进入下一个状态。
条件是一个由方括号围起的关系或逻辑表达式。
6.4活动图的基本概念与组成成分
活动图用来表示完成一个操作所需要的活动， 或是一个实例（场景）的活动。 活动图可以对多种不同类型的工作流建模。
活动图被设计用于简化描述一个过程或操作 的工作步骤。
例如，软件公司可以用活动图对一个软件的开 发过程建模；会计师事务所可以用活动图对任意 数目的财务往来进行建模；
2．活动状态
拥有一组不可中断的动作或操作，表达一个非原子的运 行。
2022/1/21
UML系第统29页建，模共4与8页分。析设计
29
3．动作流
表达不可中断的动作或操作的执行。
6-13 描述一个打印所有履约合同信息的活动图
2022/1/21
UML系第统30页建，模共4与8页分。析设计
30
4．泳道 泳道代表对象对活动的责任。
2022/1/21
UML第系2统2页建，模共与48页分。析设计
22
复杂状态图：状态的并发迁移与同步
2022/1/21
UML第系2统3页建，模共与48页分。析设计
23
状态的并发迁移与同步
6-7 采用同步并发迁移图符描述的并发子状态图
2022/1/21
UML系第统24页建，模共4与8页分。析设计
24
2022/1/21
UML系第统8页建，模共4与8页分。析设计
包_UML系统分析与设计教程（第2版）_[共2页]
![包_UML系统分析与设计教程（第2版）_[共2页]](https://img.taocdn.com/s3/m/02011a0684254b35eefd34e3.png)
54图4.21 接口与类之间的关系（二）4.9 包包（Package）是一个用来将模型元素分组的通用机制。
包可以用在任何一个UML图中，但一般多用于用例图和类图。
包就像文件夹一样，可以将模型元素分组隐藏，从而简化UML图，使得UML图更易理解。
有时候，甚至可以将一个系统看做一个单一的、高级的包。
包的UML符号如图4.22所示。
包可以有包名，以与其他包相区分。
在实践中，包的名字通常是从问题域的词汇表中抽取出的短名词或名词词组。
包可以含有类、接口、组件、节点、协作、用例、图或其他的包等元素，但每个元素只能被一个包所拥有。
包所含有的元素要在包中进行声明，如果包被破坏，包中的元素也会被破坏。
一个包界定了一个命名空间，这意味着在一个包中，同种元素必须有不同的名字。
例如，在同一个包中，不能有类名同为Number的两个类，但是可以在包Package1中有一个类名为Number 的类，并在包Package2中也有一个类名为Number的类。
而且，类Package1::Number 和类Package2::Number是可以用它们的路径名来区分的不同的类。
在一个包中，不同种元素可以有相同的名字。
例如，在一个包中，一个类和一个组件可以用相同的名字来命名，如将类和组件都命名为Number。
但是，在实践中，为了避免混乱，最好将同一个包中的不同元素命名为不同的名字。
包可以含有其他的包。
例如，在Java语言的类库中，类File在包io中，而包io又在包java 中，所以类的全名是java.io.File。
但是，在实践中，应避免过深的包嵌套，一般两到三层的嵌套比较适宜。
●可见性。
如同类属性和操作的可见性是可控制的一样，包中元素的可见性也是可控制的。
包中的元素图4.22 包的UML符号。
第6章 系统分析
并可以作为设计模型中的子系统。
第6章 系统分析
根据分析包的特征，可以把分析包分为专用包、
通用包和服务包三种类型。 1) 专用包 专用包为完成某种功能而设置，一般分析包都属 于专用包。 2) 通用包 能够被多个分析包所共享的分析包被称为通用包。 例如，在书店信息系统中，“书目”实体类会被多个
分析包所共享，我们设置一个“书目管理”分析包来
书”。
第6章 系统分析
“售书处理”的用例分析类图
书目
售书员
售书界面
产生待售图书
待售图书
开书单
打印进程
架存图书
出售图书
售出图书
图6.6 “售书处理”的用例分析类图
第6章 系统分析
3．用例分析协作图
用例分析协作图(UseCase Analysis Collaboration Diagram)描述为了实现用例的功能，参与者与信息系 统以及信息系统中的各概念类之间所交互的消息。通 过整个消息的传递来实现用例的功能。图6.7是对应于 图6.6的用例分析协作图。
专门管理图书书目，它就是一个通用包。
第6章 系统分析
3) 服务包
在信息系统中，某些包的作用是专门向信息系统 高层提供特定服务，这些分析包被称为服务包。例如， “文档预览包”、“文档打印包”、“远程调用包”、 “查询代理包”等都向信息系统高层提供通用服务， 因而它们都属于服务包。
第6章 系统分析
6.3 逻辑结构分析
入库
出库
盘库
报损
员工信息管理
工资管理
员工勤绩管理
日常事务管理
图6.9 书店信息系统初步逻辑结构
第6章 系统分析
2．分解和确定分析包
在逻辑结构中的不同位置，分析包具有不同的抽 象度。其逻辑系统是抽象度最高的一个分析包，越处 在逻辑结构的上层，其抽象度越高，越在下层，其抽 象度越低。确定逻辑结构的过程就是从顶层分析包开 始，逐层对分析包进行分解，直到分解到底层分析包 为止。
用例描述及模板_UML系统分析与设计教程（第2版）_[共2页]
![用例描述及模板_UML系统分析与设计教程（第2版）_[共2页]](https://img.taocdn.com/s3/m/58183ecc6bd97f192279e9ec.png)
意思是10个人干1年）的项目，有的人可能需要使用20个用例，另外一些人可能需要使用100多个用例。
而实际上，对一个10人年的项目来说，20个用例似乎太少，100多个用例又似乎太多，所以在建立模型时，要注意选取适中的用例粒度，以避免用例数目过多或过少。
确定用例的过程是对获取的用例进行提炼和归纳的过程。
为了构造一个好的用例，应该遵循的原则是：一个应该从头至尾地描述一个完整的功能，且要与参与者交互。
例如，在图6.3所示的教学系统中，学生首先必须选择课程，然后必须被注册到所选择的课程中，最后学生还必须为课程付费，这3个过程应该用3个用例还是1个来描述呢？由于这3个过程是1个完整行为的3个部分，独立存在是没有意义的，所以最好用一个用例——注册课程（Register for courses）来描述。
另外，如何绑定彼此密切相关但不同的功能呢？例如，注册人员可以添加课程、取消课程，还可以修改课程，这应该用3个用例还是1个用例来描述呢？最好使用1个用例——课程维护（Maintain Course Info），因为这3个过程都是由1个参与者（注册人员）进行的，并且只涉及了系统中的同一个实体（课程）。
该教学系统必须满足如下需求。
●学生（Student）需要使用系统注册课程。
●授课教师（Lecturer）需要使用系统选择所要教的课程，并通过系统获得关于该课程的学生花名册。
●注册人员（Registrar）负责学期课程目录的产生，维护系统所需的关于课程、学生和教师的信息。
基于以上需求，可以建立如下用例。
●课程登记（Register for Courses）。
●选择所教的课程（Select Course to Teach）。
●获取学生花名册（Request course roster）。
●维护课程信息（Maintain course info）。
●维护教师信息（Maintain teacher info）。
●维护学生信息（Maintian student info）。
用例间的关系_UML系统分析与设计教程（第2版）_[共2页]
![用例间的关系_UML系统分析与设计教程（第2版）_[共2页]](https://img.taocdn.com/s3/m/81d1b36cfd0a79563c1e72ec.png)
77 1.4.2 分支流S-1：添加所选课程系统提示含有课程名和课程代号的域，学生输入希望选修的课程名和课程代码（E-3），系统显示信息表示该课程可以选修（E-4），并建立该课程与该学生的连接（E-5）。
用例重新开始。
S-2：删除所选课程系统显示含有课程名和课程代号的域，学生输入希望取消的课程名字和课程代码，系统删除该课程与该学生的连接（E-6）。
用例重新开始。
S-3：查看所选课程系统检索（E-7）并显示出学生所选的所有课程的信息，包括课程名、课程代码、上课时间、上课地点、授课教师、课程助教、学生数量。
当学生表示查看完毕，用例重新开始。
S-4：打印所选课程系统打印出学生所选的课程信息（E-8）。
用例重新开始。
1.4.3 替代流（Alternative Flows ）E-1 如果输入的密码无效，用户可以重新输入密码或终止用例。
E-2 如果输入的学期无效，用户可以重新输入学期或终止用例。
E-3 如果输入的课程名或代码无效，用户可以重新输入有效的课程名和代码的组合或终止用例。
E-4 如果所要求的课程不可以选修，学生会得到信息提示该课程目前无法选修。
用例重新开始。
E-5 如果学生与课程间的连接不能建立，信息会被存储，系统会晚些时候再次建立连接。
用例继续。
E-6 如果学生与课程间的连接不能删除，系统会存储信息，并晚些时候删除该连接。
用例继续。
E-7 如果系统不能检索课程选修信息，那么用例重新开始。
E-8 如果系统不能打印课程选修信息，学生会得到信息表示该选项目前无法使用。
用例重新开始。
6.3.2 用例与脚本当细化对系统需求的理解时，需要用交互作用图来描述这些流，因为用一个顺序图来描述用例的所有信息是不可能的。
例如，在一个商场系统中，会有“付账”这个用例，这个用例可以有不同的变种，可以用现金付账，也可以用信用卡付账，甚至还可以用转账的方式付账（例如，当单位购买大量的货物时），每一种情况都可以用不同的顺序图来描述。
第6章 基于UML的系统分析-Java应用系统的设计与实现(第2版)-马素霞-清华大学出版社
Java应用系统的设计与实现（第2版）
8
Rational Rose
• Rational Rose（简称Rose）是美国IBM Rational软件公司在软件工程专家Grady Booch、Ivar Jacobson、Jim Rumbaugh等 人主持下研制的可视化软件开发工具；
Java应用系统的设计与实现（第2版）
7
建模工具
• Rational Rose：直接针对UML的建模工具，掌握 UML 的开发人员使用。不支持UML2.0。
• EA（Enterprise Architect）：基于UML的可视化建 模工具，经常更新，支持UML2.0及以上版本。
• Visio：最初为画图工具，VISIO2000以后开始引进软 件分析设计功能到代码生成的全部功能，代码生成仅支 持微软的产品。
及动作序列； ➢ 备选事件流则表示特殊情况或异常情况下的信息交互及
动作序列。
Java应用系统的设计与实现（第2版）
13
类图
类图表示类（及其接口）、类的内部结构以及与 其他类之间的关系。
➢ 类之间的关系有关联、聚合（组合）、泛化（继 承）、依赖关系；
➢ 接口之间的关系通常有继承、依赖关系； ➢ 类与接口的关系可以有实现关系。
Java应用系统的设计与实现（第2版）
3
6.1 统一建模语言UML
• UML的产生和发展
➢ 1996年，面向对象的三位大师Booch、 Rumbaugh和Jacobson提出了UML的概念。
➢ 将各自独立的面向对象分析（OOA）和面向对 象设计（OOD）方法中最优秀的特色组合成一 个统一的建模方法。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Include关系（包含关系）
Extend关系（扩充关系）
类属关系
Validate password
Validate user
Scan IDCard
作者：
《UML系统分析与设计教程》
11
Include关系
<<include>>
Log in
<<include>>
<<include>> Delete existing account
Modify account information
Create new account
作者：
《UML系统分析与设计教程》
12
Extend关系
Take exam Extension points fail
<<extend>>
Student
作者： 《UML系统分析与设计教程》 8
用例与脚本
脚本或场景（Scenario）是系统行为的一个特 定动作序列。 脚本与用例的关系就象实例与类的关系，即脚 本是用例的一个实例。
作者：
《UML系统分析与设计教程》
9
用例间的关系
类属关系
如同类间的类属关系。即，子用例继承父用例的行为和含义， 子用例可以添加新行为或覆盖父用例的行为。 用例间的包含关系表示在基用例的指定位置，基用例显式地 包含另一个用例的行为。 被包含的用例是不能独立存在的，只是包含它的更大用例的 一部分。 扩充关系用来说明可选的、只在特定条件下运行的行为。 扩充关系用衍型为<<extend>>的依赖关系表示，并在基用 例中列出基用例的扩充点，这些扩充点是出现在基用例的流 中的标记。
Part-time Full-time Employee Employee Login
Administrator
Maintain Employee Information
Bank System System Clock Run Payroll
Printer
作者： 《UML系统分析与设计教程》 15
M ake up exam
Finish homework Have lessons
作者：
《UML系统分析与设计教程》
13
用例图的应用
用例图的应用
为系统的上下文建模。 为系统的需求建模。
作者：
《UML系统分析与设计教程》
14
Select Payment Method
Maintain Timecard Employee Project Management DB Create Employee Report
2
用例图
三种主要建模元素：
用例（Use Case）。 参与者（Actor）。 依赖、类属和关联关系。 注释和约束。 包。 系统边界框。
作者： 《UML系统分析与设计教程》 3
可选元素：
用例图
作者：
《UML系统分析与设计教程》
4
参与者
参与者代表与系统接口的事物或人，它是具有某一种 特定功能的角色，因此参与者是虚拟的概念，它可以 是人，也可以是外部系统或设备。 同一个人可能对应多个参与者，因为一个人可能扮演 多个角色。 参与者不是系统的一部分，它们处于系统的外部。 如何识别出参与者？作ຫໍສະໝຸດ ：《UML系统分析与设计教程》
7
事件流文档模板
事件流文档模板：
X. 用例XX（用例名）的事件流 X.1 前置条件（Pre-Conditions） X.2 后置条件（Post-Conditions） X.3 扩充点（Extension Points） X.4 事件流 X.4.1 基流（Basic Flow） X.4.2 分支流（Subflows）（可选） X.4.3 替代流（Alternative Flows）
第6章 用例图
作者：
《UML系统分析与设计教程》
1
用例图
用例图（Use Case Diagrams）是UML中用来 对系统的动态方面进行建模的7种图之一（另 外6种图是活动图、状态机图、顺序图、通信 图、定时图和交互概览图）。 用例图描述了用例、参与者以及它们之间的关 系。
作者：
《UML系统分析与设计教程》
参与者代表角色。 参与者不是对职位进行建模。
作者：
《UML系统分析与设计教程》
5
作者：
《UML系统分析与设计教程》
6
用例
用例是对系统行为的动态描述，它可以增进设 计人员、开发人员与用户的沟通，理解正确的 需求；还可以划分系统与外部实体的界限，是 系统设计的起点，是类、对象、操作的来源， 而通过逻辑视图的设计，可以获得软件的静态 结构。 如何识别用例 ？