第2章软件开发方法与技术( 功能模型—用例图)
软件工程之用例模型总结
软件工程之用例模型总结一、用例模型1.用例概念用例：使用系统时发现的功能性需求，不应过于复杂，简单的来说就是你希望系统能够有什么功能，能够增加系统的价值。
用例模型包括用例描述和用例图，我们主要把中心放在用例描述上。
用例模型包含参与者和场景，场景包括成功场景和失败场景。
因此用例模型中有多个场景；每个场景是一个用例。
用例必须注重为用户提供可观察的返回值，就是系统触发了一个用例之后能够给用户带来什么。
一般用例都是黑盒用例，即不考虑如何实现。
e Case Description每个用例都有一个描述。
怎样确定用例？(1)确定一个功能；(2)写一个用例；(1)主要参与者：调用系统服务完成目标的人。
(2)次要参与者：为系统提供服务的人。
(3)写出每个项目相关人员的理想需求，从中分析功能。
(4)PreCondition:执行到这个用例之前必须为真的情况，比如必须已成功登录或通过验证。
(5)PostCondition:成功执行完此用例后的情况，比如登录用例的后置条件是成功登录（不考虑其他失败情况）。
(6)main flow：将最理想的步骤列出。
一般main flow步骤如下：(1)参与者发生动作。
(2)系统验证。
(3)返回结果。
(7)extension flow：扩展步骤,通常格式为：(1)系统检测到**有问题;在main flow中的第一步扩展，则用1a,1b,1c;3.如何确保正确的用例EBP原则:一般用例都需要遵守这个规则，即确定主要用例。
用例中的主要用例是一些重复做但是有意义的事，比如收银员收钱，重复多次是有意义的，因为钱收得多了；但是像登录系统，这种做100次却没有意义的用例，不能被称为主要用例；(1)EBP（基本业务过程）原则的用例写入；(2)如果要写编辑A，删除A，添加A，可以合并成“管理A”；4.用例图每个用例描述都是一个用例，左边是主要参与者（希望系统为他提供服务）和次要参与者（提供给系统服务的人）；在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据库的；关系：(1)泛化关系，在参与者和用例中都能泛化。
软件开发模型PPT课件
适合的项目类型： ➢ 采用快速度从小到大变化的项目，例如重整企业的信息系统。
第25页/共67页
软件生命周期与软件开发模型
3、增量模型 增量模型也称为渐增模型。 使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、
➢这个模型中最终用户是很重要的角色，从图2.5 可以看出，系统构造的实践比传统其他模型要少 很多，模型中更多的任务是规划和设计，而不是 编码和测试。
➢因为在开发中采用很多的工具，例如利用代码生 成器等生成需要的系统，这样会很快构造一个系 统。采用这种方法可以不断完善地构造出一个用 户需要的系统。
➢这个系统中的构造包括详细设计、编码、测试等， 所以，快速应用开发（RAD）模型相当于将设计、 构建、测试等压缩为一系列的短的迭代式的循环。
修正前面阶段的产品之
综合测试
后再回来继续完成后面
阶段的任务。
图2.2 实际瀑布模型
维护
第9页/共67页
软件生命周期与软件开发模型
瀑布模型有许多优点：
➢ 可强迫开发人员采用规范的方法（例如，结构化技 术）；
➢ 严格地规定了每个阶段必须提交的文档； ➢ 要求每个阶段交出的所有产品必须经过质量保证小
组的仔细验证。
第27页/共67页
软件生命周期与软件开发模型
3、增量模型 ➢ 使用增量模型时，把软件产品分解成增量构件时，应该使构件的规模适中， 规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而 异。 ➢ 分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形 成的产品必须是可测试的。 ➢ 第一个增量构件往往实现软件的基本需求，提供最核心的功能。
➢ 原型的用途是获知用户的真正需求，一旦需求确定了，原型将 被抛弃。
高级软件工程(第二章)软件开发过程与开发方法 (2017课件)
ቤተ መጻሕፍቲ ባይዱ
⑸ 支持阶段
主要目标：在系统初始安装后的几年里保持系统 有效的运行。
主要活动： 维护系统； 加强系统； 支持用户。
11
1. 迭代
迭代意味着任务做了一次，接着又一次，然后 又一次(任务是不断重复的)。 随着每一次迭代，结果得到了修正，并且越来 越接近目标。 假设：不可能在第一次就得到正确的结果。
17
模型的概念
模型(MODLE)是对某个实体或事物的抽象和简 化。其目的是在构建这个事物之前先来理解它。 模型忽略了非本质的细节，抽象出了问题本质， 使问题更容易理解，有助于对复杂问题进行分 层，从而更好地解决问题。
18
面向过程方法
面向过程的方法认为我们的世界是由一个个相互关 联的小系统组成。 每个小系统都有明确的开始和明确的结束 ,开始和结 束之间有着严谨的因果关系。 如果用计算机模拟它，首先的工作就是将这个过程 描绘出来，定义因果关系，细化，用编程语言实现。 过程中每一步都会产生、修改或读取一部分数据。 将世界视为过程的这个方法本身蕴涵着一个前提假 设，即这个过程是稳定的，这样我们才有分析的基础， 所用的工作成果都依赖于这个过程的步步分析。
19
面向对象方法
面向对象方法将世界看作一个个相互独立的对象， 相互之间并无因果关系。只有在某个外部力量的驱 动下，对象之间才会依据某种规律相互传递信息。 这些交互构成了这个生动世界的一个“过程”。 在没有外力的情况下，对象保持“静止”的状态。
20
面向过程，还是面向对象？
如果你的分析习惯是在调研需求时最先弄清楚有多 少业务流程，先画出业务流程图，然后顺藤摸瓜， 找出业务流程中每一步骤的参与部门或岗位，弄清 楚在这一步参与者所做的事情和填写表单的结果， 并关心用户是如何把这份表单传给到下一个环节的。 面向过程。 如果你的分析习惯是在调研需求时最先弄清楚有多 少部门，多少岗位，然后找到每一个岗位的业务代 表，问他们类似的问题：你平时都做什么？这件事 是谁交办的？做完了你需要通知或传达给谁吗？做 这件事情你都需要填写些什么表吗？.... OO
第1章 软件开发方法与技术(UML概述)
说明: 采用面向对象技术开发软件时： 第 1步：基于问题域，建立系统的描述需求模型“用例图” 且给出系统需求的文字陈述，包括： ⑴ 功能性需求：描述系统的功能（做什么） ⑵ 非功能性需求：描述系统的功能实现更好的方面： 性能、安全性和可靠性等 ⑶ 可用性需求：描述系统的应用程度 其中：功能性需求是必不可少的，另两个是辅助的
OMT 其他方法
UM0.8
Booch UML0.9 UML1.0
OOSE
§1.2 UML的特点 UML的主要特点可归纳以下几点： 1．UML统一了Booch、OMT、OOSE和其他面向对象方法 的基本思想、概念和符号。 2．UML是支持面向对象软件开发的建模语言。 3．UML可视化、表达能力强大。 4．UML是一种建模语言而不是一种方法。 其中：方法包括表示符号和开发过程的指导原则，而 UML仅提供了建模使用的表示符号及其应用规 则，不依赖于特定的软件开发过程。这也是它 能够被大众接受的一个原因。 例如：RUP（Retional Unified Process） Retional公司统一制定的开发过程，同UML （Retional Rose）配套使用 5．UML仍然在不断的完善和发展。
活动类是这种类，它的对象有一个或多个进程或线程，其外观 和普通类没有什么区别。
说明：在类的属性中按如下步骤设置： ” Detial Concurrency Active” 细节标签 并发性选项
⑥ 构件（component）
Component
构件是定义了良好接口的独立的软件实现实体（单元），它是 系统中物理的、可替代的部件。
逻辑视图 类图 对象图
并发视图：体现了系统的动态或行为特征 也称为：进程视图（Process View）
并发视图 时序图 协作图 状态图 活动图
第二章-软件开发方法概述-PPT课件
31
抽象化
软件系统进行模块设计时，可有不 同的抽象层次。 在最高的抽象层次上，可以使用问 题所处环境的语言概括地描述问题 的解法。 在较低的抽象层次上，则采用过程 化的方法。
16
实用性：确认该设计对于需求的解 决方案是否实用 技术清晰度：确认该设计是否以一 种易于翻译成代码的形式表达 可维护性：确认该设计是否考虑了 方便未来的维护 质量：确认该设计是否表现出良好 的质量特征
17
各种选择方案：看是否考虑过其 它方案，比较各种选择方案的标 准是什么 限制：评估对该软件的限制是否 现实，是否与需求一致 其它具体问题：对于文档、可测 试性、设计过程..等进行评估
49
公共耦合的复杂程度随耦合模块的个 数增加而显著增加。若只是两模块间 有公共数据环境，则公共耦合有两种 情况。松散公共耦合和紧密公共耦合。
50
内容耦合 (Content Coupling)
如果发生下列情形，两个模块之间 就发生了内一个模块不通过正常入口转 到另一模块内部;
28
④ 在模块A的箭头尾部标以一个菱 形符号，表示模块A有条件地调用 另一个模块B。当一个在调用箭头 尾部标以一个弧形符号，表示模块 A反复调用模块C和模块D。
29
程序的系统结构图
30
模块化
软件系统的模块化是指整个软件被 划分成若干单独命名和可编址的部 分，称之为模块。这些模块可以被 组装起来以满足整个问题的需求。
外部耦合（External Coupling）
一组模块都访问同一全局简单变量而 不是同一全局数据结构，而且不是通 过参数表传递该全局变量的信息，则 称之为外部耦合。
第二章 软件开发模型
2.2 瀑布模型（Waterfall Model） 瀑布模型（ ）
2.2.1 瀑布模型的概念： 瀑布模型的概念：
需求分析
（需求说明书） 需求说明书） （系统设计书） 系统设计书） （程序设计书） 程序设计书） （程序清单） 程序清单）
系统设计
程序设计
编码 测试
（测试报告） 测试报告） （维护报告， 维护报告， 改进的系统 ）
分析定义 系统需求 生成 原型 原型化
运 行 和维护
含原型化的 软件生存期
测试 编码
系统 设计
程序 设计
2.3.3 原型模型的特点
优点： 优点： 开发者与用户充分交流，可以澄清模糊需求， 开发者与用户充分交流，可以澄清模糊需求，需求定义 比其他模型好得多 为用户需求的改变提供了充分的余地 缺点： 缺点： 开发者为了使一个原型快速运行起来， 开发者为了使一个原型快速运行起来，往往在实现过程 中采用折衷的手段。软件系统的组成部分可能会打折扣； 中采用折衷的手段。软件系统的组成部分可能会打折扣； 资源规划和管理较为困难，随时更新文档也带来麻烦。 资源规划和管理较为困难，随时更新文档也带来麻烦。 一般使用场合： 一般使用场合： 开发者在不了解的应用领域开发 客户不清楚其所开发软件项目的最终目标
第二章 软件开发模型
软件开发模型与软件工程 瀑布式模型 原型模型 增量模型 螺旋模型 XP开发模型 XP开发模型 面向对象的开发模型 构件集成模型
2.1 软件开发模型与软件工程
软件开发模型： 软件开发模型： 软件开发模型是软件开发的全部过程、活动、 软件开发模型是软件开发的全部过程、活动、任务和管理 结构框架。 的结构框架。 软件开发模型能清晰、直观地表达软件开发全过程， 明确 软件开发模型能清晰、直观地表达软件开发全过程， 规定了要完成的主要活动和任务， 规定了要完成的主要活动和任务，用来作为软件项目工作 的基础。 的基础。 选择合适的开发模型是十分重要的
第2章 软件开发工具
2.1.3 Visio 2013建模示例
图2-9 Visio绘制系统架构图
2.1.3 Visio 2013建模示例
在项目前期的粗略设计阶段，系统架构图体现软件部件之 间的联系和部件的布局。 Visio也没有提供专门模型来支持系统架构图的绘制，此时 可以借助Visio“基本框图”、“基本流程图”中的部分元 素，进行系统结构图的描述。
2.1.3 Visio 2013建模示例
图2-12 Visio绘制数据流图
2.1.3 Visio 2013建模示例
在需求分析阶段，数据流图是结构化方法下需求模型的主 要构成部分。通常绘制数据流图逐步细化、逐步精化的一 个过程。 Visio提供了专门的“数据流图表”样式，支持系统数据流 图的的描述。
2.2.2 StarUML基本操作
图2-16 StarUML软件界面
2.2.2 StarUML基本操作
图2-17 添加新工程
2.2.2 StarUML基本操作
图2-17 工程选择
2.2.2 StarUML基本操作
图2-18 模型添加
2.2.2 StarUML基本操作
图2-19 通过菜单添加图
2.2.1 StarUML简介
根据图的特点，StarUML把所有的UML图分为五类，包括 用例视、分析视、设计视、实现视和发布视。StarUML只 支持图内部的语法检查，并不支持模型验证和一致性检查， 这表明在各种图内部，工具能够很好地保证模型元素的合 法使用，但不能保证图与图之间的联系是否合法正确。 StarUML的缺陷在于不支持业务建模，当进行管理信息系 统等事务处理软件的时候，可以借助Rational rose进行业 务分析和建模工作。
2.1.1 Visio简介
第2章 UML通用知识点概述
2、图
序 列 图
序列图显示了一个具体用例或者用例的一部分的一个详细流程。它几 乎是自描述的，序列图不仅可以显示了流程中不同对象之间的调用关系， 还可以很详细地显示对不同对象的不同调用。 序列图有两个维度：垂直维度，也称时间维度，以发生的时间顺序显 示消息或调用的序列；水平维度显示消息被发送到的对象实例。
UML统一建模语言
二、常用的UML元素分析
1、视图
活 动 视 图
活动视图是一种特殊形式的状态机视图，是状态机的一个变体，用 来描述执行算法的工作流程中涉及的活动。 通常活动视图用于对计算流程和工作流程建模。活动视图中的状态 表示计算过程中所处的各种状态。 活动视图是在假定整个计算处理的过程中没有外部事件引起的中断 的条件下进行描述的，否则普通的状态机更加适合于描述这种情况。
UML统一建模语言
二、常用的UML元素分析
2、图
用 例 图
用例图描述了系统提供的一 个功能单元。用例图的主要目的 是帮助开发团队以一种可视化的 方式理解系统的功能需求，包括 基于基本流程的“角色”关系， 以及系统内用例之间的关系。 使用用例图可以表示出用例 的组织关系，这种组织关系包括 整个系统的全部用例或者是完成 相关功能的一组用例。 在用例图中画出某个用例方 式是在用例图中绘制一个椭圆， 然后将用例的名称放在椭圆的中 心或椭圆下面的中间位置。
三、UML的通用机制
2、修饰
在UML的图形表示中，每一个模型元素都有一个基本符号，这个基本 符号可视化地表达了模型元素最重要的信息。 用户也可以把各种修饰细节加到这个符号上以扩展其含义。这种添加 修饰细节的做法可以为图中的模型元素在一些视觉上的效果上发生一些 变化。
UML统一建模语言
三、UML的通用机制
软件工程用例图 ppt课件
ppt课件
12
用例之间的关系
1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所 包含的用例行为作为自身行为的一部分。在UML中，包含关系是 通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用 例(Base)指向被包含用例(Inclusion)。
ppt课件
13
用例之间的关系
ppt课件
24
练习题
网络的普及带给了人们更多的学习途径，随之用来管理远程网络 教学的“远程网络教学系统”也诞生了。
“远程网络教学系统”的功能需求包括： (1)学生登录网站后，可以浏览课件、查找课件、下载课件、观看教
学视频。 (2)教师登录网站后，可以上传课件、上传教学视频、发布教学心得、
查看教学心得、修改教学心得。 (3)系统管理员负责对网站页面的维护，审核不法课件和不法教学信
不管什么系统，基本都会有比较专业的人员来负责管理系统，本 系统也不例外。系统管理员除了负责维护系统的日常运行，还要 进行录入学生基本信息、维护选课信息等工作。
ppt课件
20
使用Rose创建用例的步骤说明
3. 构建用例模型
系统管理员直接参与 的用例为登录、找回 密码、查看班级基本 信息、删除班级基本 信息、修改班级基本 信息和录入班级基本 信息。校领导直接参 与用例登录、找回密 码和查看班级基本信 息。当登录过程中发 生忘记密码的情况， 就需要使用找回密码 的功能来找回密码， 而在正常情况下用不 到找回密码这个功能 所以用例找回密码” 和用例登录之间是扩 展关系。
息，批准用户注册。
ppt课件
25
练习题
（1）学生需要登录“远程网络教学系统”后才能正常使用该系统所有功能。 如果忘记密码，可以通过“找回密码”功能找回密码。登录后学生可以 浏览课件、查找课件、下载课件、观看教学视频，请画出学生参与者的 用例图。
UML功能模型（用例图）
UML功能模型（⽤例图）在UML系统开发中有三个主要的模型：功能模型（从⽤户⾓度展⽰系统的功能，包括⽤例图）、对象模型（采⽤对象，属性，操作关联等概念展⽰系统的结构和基础，包括类图、对象图、包图）、动态模型（展⽰系统的内部⾏为，包括序列图，活动图，状态图）。
下⾯就说⼀说功能模型——⽤例图。
⽤例图是UML建模的⼀部分，也是UML⾥⾯最基础的部分，最主要的功能就是⽤来表达系统的功能性需求或⾏为。
⽤例图是由软件需求分析到最终实现的第⼀步，它描述⼈们如何使⽤⼀个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了⼀些参与者和⼀些⽤例，以及它们之间的关系，主要⽤于对系统、⼦系统或类的功能⾏为进⾏建模，⽤画图的⽅法来完成。
⽤例图展⽰了⽤例之间以及⽤例与参与者之间是怎样相互联系的。
⽤例图包含留个元素：参与者、⽤例、关联关系、包含关系、扩展关系、泛化关系。
参与者（Actor）：系统外部的⼀个实体，参与⽤例执⾏过程，通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏。
参与者的种类概括为三种：系统⽤户、与所建造的系统交互的其他系统以及⼀些可以运⾏的进程。
注意：参与者表⽰⼈和事物与系统发⽣交互时所扮演的⾓⾊，⽽不是特定的⼈或特定的事物；每个参与者需要⼀个具有业务⼀样的名字；⼀个⼈或事物在与系统交互时，可以同时或不同时扮演多个⾓⾊。
⽤例（Use Case）：⽤例是对⼀个活动者使⽤系统的⼀项功能是所进⾏的交互过程的⼀个⽂字描述序列，是系统、⼦系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。
⽤例是岱庙系统各种各个项⽬相关⼈员之间就系统的⾏为所达成的契约，软件开发过程是⽤例驱动的。
⽤例粒度（规模⼤⼩）。
关联关系（Association）：表⽰参与者⽤例之间进⾏通信包含关系（Include）：客户⽤例可以简单地包含提供者⽤例具有的⾏为，并把他所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。
调⽤⽤例执⾏到包含点，然后执⾏传递给被调⽤⽤例，当被调⽤⽤例完成时，控制在次返回调⽤⽤例。
第2章 信息系统建模
第2章 信息系统建模 UML采用一组图形符号来描述软件模型，这些图 形符号具有简单、直观、规范的特点。因而UML的特 点是：开发人员学习和掌握起来比较简单；所描述的 软件模型可以直观地理解和阅读；由于具有规范性， 所以能够保证模型的准确、一致。 2. UML的基本内容 作为一种对客观系统的建模语言，UML提供了描 述事物实体、性质、结构、功能、行为、状态、关系 的建模元素，并通过一组图来描述由建模元素所构成 的多种模型。UML的建模元素包括基本建模元素、关 系元素和图三大类，见图2.10。
测试
建立测试模型
细化 迭代1 迭代2
…
…
…
…
…
迭代n -1 迭代n
图2.9 信息系统建模过程
第2章 信息系统建模 2.1.4 信息系统建模语言 信息系统建模语言是描述信息系统模型的规则符号集。 信息系统建模语言与信息系统开发方法和开发过程有关，不 同的开发过程规定了不同的开发步骤和开发工作，不同的开 发方法规定了不同的建模语言。像结构化方法就采用数据流
第2章 信息系统建模
模型分析
需求理解
现实系统
建立模型
模型
图2.1 建模过程
第2章 信息系统建模 2. 信息系统模型 信息系统属于智能性系统，在信息系统中蕴藏着大量的 信息、知识、方法和技术。信息系统无论是在开发过程中， 还是在开发成功之后，都不具备其它简单物质系统的形态外 显性。信息系统这种深刻的包藏性，给信息系统的开发带来 了极大的困难，使得在整个信息系统开发过程中，人们对它 难以把握和描述。为了工程化、有效地开发信息系统，人们 除了寻求有效的开发方法，严密地组织工程过程之外，还需 要在开发的各个阶段，以某种有效的形式把信息系统描述和 表现出来，这样开发人员才能够有针对性地进行交流和讨论。 我们把通过确定的形式，对信息系统本质特性的描述称为信 息系统建模，而所描述的结果称为信息系统模型。
UML建模工具软件StarUML从入门到精通——软件系统需求分析中的UML用例图及其组成部件
（3）所应该注意的问题
1）用例确定的只是与用户交流的目的，而不是交流的手 段。 因为，客户并不需要了解执行者、用例这些概念。用例能 告诉软件系统的开发团队“去向客户了解什么”（目的），不 能告诉软件系统的开发团队如何向客户去了解（手段）； 2）获得用例的手段可以有很多种 文档研究、问卷调查、访谈、观察、研究竞争对手、开会、 原型、场景演示…，使用用例思维来指导这些交流手段，会使 交流更有目的，更加高效。
2）泛化关联包括用例之间及活动着之间的关联关系。例如， 修改员工资料和修改开发部员工资料就是用例的泛化关联。 3）泛化关联用空心三角箭头的实线表示：其方向从特殊指向 一般。
（4）用例的横向方面的包含关联 1）包含关联主要是指一个基本用例的行为包含了另一个用例 的行为，这种关联是一种依赖关系，被包含的用例不能独 立存在，只能作为包含它的用例的一部分。
11、UML用例模型的主要作用
（1）表示系统的需求 可以应用UML用例模型来开发一个精确的模型来表示软件系 统的需求，然后以这些用例为基础来推动软件系统开发的其它方 面。 （2）连接用户与软件系统需求 用例的作用就好象是项链上的一条线，它将所有的珍珠绑定 在一起。 用例在最终的用户和软件系统需求之间建立起一座桥梁。它 们可用来在功能需求和软件系统实现之间进行回溯。
3）时间 时间作为参与者时，经过一定时间触发系统的某个事件。 例如，ATM机可能每天午夜运行一些协调处理。 由于事件不在本系统的控制之内，因此也是本软件系统的参 与者。
3、某个“网上书店”和“在线网校”项目中的各个参与者 示例说明
（1）在“网上书店”项目中的参与者主要有用户和系统统管理 员，而管理员使用控制面板对系统和用户管理，也就是进行系统 设置，管理用户、用户组、权限，查看系统访问日志及用户使用 情况等的统计信息。 （2）在“在线网校”项目中的学校课程管理子系统中则有三个 参与者在不同的应用中互动。
UML复习资料(完整)
2011UML复习题纲一、选择、判断、填空第一章UML与面向对象1、UML(Unified Modeling Language,统一建模语言)是软件和系统开发的标准建模语言，它主要以图形的方式对系统进行分析、设计。
2、UML是在多种面向对象分析与设计方法相互融合的基础上形成的，是一种专用于系统建模的语言。
它为开发人员与客户之间，以及开发人员之间的沟通与理解架起了“桥梁”。
3、UML不是开发工具，只是建模语言。
4、OOA三种基本模型：功能模型、对象模型、动态模型。
5、软件是程序、数据和相关文档的完整集合。
6、软件开发过程分为如下几个阶段：需求分析、总体设计、详细设计、编程与测试、维护。
7、面向对象的软件工程方法包括面向对易用的分析（OOA）、面向对象的设计（OOD）、面向对象的编程（OOP）。
8、软件方法学包含3个要素：方法、工具和过程。
9、对象是现实世界中一个实际存在的事物，它可以是看得见摸得着的东西。
10、类是一组具有相同属性的操作的对象集合，它为所有属于该类的对象提供了统一的描述。
11、封装是指将对象属性和操作结合在一起，构成一个独立的对象。
封装使得对象属性和操作紧密结合在一起，这反映了事物的状态特性与动作是事物不可分割的特征。
12、继承是指子类可以拥有父类的全部属性和操作，继承是OO方法的一个重要的概念，并且是OO技术可以提高软件开发效率的一个重要原因。
13、多态性是指在父类中定义的属性和操作被子类继承后，可以具有不同的数据类型或表现出不同的行为。
14、OO开发中的三层设计：问题域类、GUI类和数据访问类。
15、面向对象设计准则：模块化、抽象、信息隐藏、低耦合、高内聚。
16、UML的构成：元元模型层、元模型层、模型层、用户模型层。
17、UML的核心是由视图、图、模型元素、通用机制组成。
18、UML中的视图细分：（1）用例视图（用例视图强调从系统的外部参与者角度需要的功能，描述系统应该具有的功能）；（2）逻辑视图（逻辑视图的使用者主要是设计人员和开发人员，描述用例视图提出的系统功能的实现）；（3）并发视图（并发视图的使用者主要是开发人员和系统集成人员，它主要考虑资源的有效利用、代码的并行执行以及系统环境中异步事件的处理）；（4）组件视图（组件是不同类型的代码模块，它是构造应用的软件单元。
第2章用例图
ReturnBook
Maintenance
用例的泛化
分层泛化
Management System
ReturnBook BorrowBook Maintenance
Maintenance BorrowerInfo
Maintenance BookInfo
2.1.4 用例与参与者的关系 用例与参与者之间的关系(通信)是双向的
2.5.2
确定系统的参与者
首先分析系统所涉及的问题领域和系统运行 的主要任务： ① 分析使用该系统主要功能部分的是哪些人。 ② 谁将需要该系统的支持以完成其工作。 ③ 系统的管理者与维护者。
2.5.2
确定系统的参与者
详细需求列表 系统可以完成学生借书和还书请求 系统允许学生浏览借阅信息 如果学生超期未还，系统生成一个超期罚款信息 图书信息需要维护 学生信息需要维护 图书管理员信息需要维护 系统需要维护
2.4.2 扩展关系
扩展用例的启用机制：扩展点 扩展点：基用例中的一个或多个位置，在该位 置会衡量某个条件以决定是否启用扩展用例 图2-21
泛化、包含与扩展关系的区别
泛化与包含用例属于无条件发生的用例，而扩展属 于有条件发生的用例。 泛化侧重表示子用例间的互斥性、用例间的继承性； 当两个或者多用例在行为，结构和目的方面存在共 性时，就可以使用泛化关系 包含侧重表示被包含用例提供服务的复用性； 扩展侧重表示扩展用例的触发不定性（可选性）；
用例图的组成 理解泛化 理解用例之间的关系 对用例进行描述 绘制用例图
3
2.1
用例图的构成
用例图用于定义系统的功能需求，它描述了系统的参与者 与系统提供的用例之间的连接关系。这里的参与者可以人， 也可以另一个系统。用例图仅从参与者使用系统的角度描 述系统中的信息。下图描述了一个学生成绩管理系统的用 例图。
软件开发方法与模型
软件开发方法与模型随着计算机技术的快速发展和软件在各个领域的广泛应用，软件开发成为了当代最重要的技术之一。
为了提高软件开发的效率和质量，人们提出了各种各样的软件开发方法和模型。
本文将介绍几种常见的软件开发方法与模型，并分析它们的优缺点。
1. 瀑布模型瀑布模型是一种经典的软件开发方法，它将软件开发过程划分为需求分析、设计、编码、测试和维护五个阶段，每个阶段都要按照严格的顺序进行。
这种方法适合开发规模较小、需求比较稳定的软件项目。
它的优点是结构清晰、易于管理，但缺点是开发周期长，难以适应需求变化。
2. 增量模型增量模型采用逐步增加功能的方式进行软件开发，每个增量都可以独立进行开发、测试和部署。
这种方法适合需求不太明确或需求经常变化的项目。
它的优点是开发周期短，可以快速响应需求变化，但缺点是每个增量都需要进行全面测试，测试工作量较大。
3. 原型模型原型模型是一种通过快速构建原型来获取用户反馈、明确需求的方法。
在软件开发开始之前，开发团队会制作一个简单的原型，让用户参与并提出改进意见。
根据用户反馈，团队不断迭代改进原型，直到满足用户需求。
这种方法的优点是能够及时了解用户需求，但缺点是对团队成员的能力要求较高，需要灵活的沟通和协作。
4. 敏捷开发敏捷开发是一种迭代、增量、自适应的软件开发方法。
它强调团队成员的协作和交流，通过小规模、短期的迭代来不断交付软件产品。
敏捷开发方法包括Scrum、XP等，适合需求频繁变化、开发周期紧张的项目。
它的优点是能够快速响应需求变化，但缺点是对团队的组织和管理要求较高。
在选择软件开发方法和模型时，需要根据具体项目的需求和特点做出合理的选择。
对于需求稳定、规模较小的项目，可以选择瀑布模型；对于需求不太明确、较大规模的项目，增量模型和原型模型更适合；而对于需求频繁变化、开发周期紧张的项目，敏捷开发方法是一个不错的选择。
总之，软件开发方法与模型的选择应根据项目的实际情况来决定，没有一种方法能够适用于所有的项目。
面向对象系统分析与设计——超星试题及答案
1・1传统开发方法及存在的问,第一章面向对象方法概论1【单选题】下面关于功能分解法的优点描述错误的是（）A、以系统需要提供的功能为中心组织系统B、与模块化编程结合使用后，使开发效率有很大提高C、删除了GoTo语句，使软件能得到有效维护D、具有较强的应对需求变化的能力我的答案：D2【单选题】下面的开发方法能够兼顾功能和数据的是（）A、功能分解法B、结构化方法C、信息建模法D、面向对象方法我的答案：D3【填空题】 _____ 开发方法强调对数据的组织，忽略系统功能。
我的答案：第一空：信息建模法4【填空题】功能分解法是以系统需要提供的__________ 中心组织系统。
我的答案：第一空：功能5【判断题】结构化方法采用数据流、加工进行建模，需求变化极易引起两者的变动，进而引起其他数据流和加工的变化。
我的答案：V6【判断题】功能分解法以功能作为系统的构造块，数据组织能力强。
我的答案：X1 【单选题】面向对象方法学的出发点和基本原则是尽可能模拟人类习惯的思维方式，分析、 设计和实现一个软件系统的方法和过程，尽可能接近于人类认识世界解决问题的方法和过 程。
因此面向对象方法有许多特征，如软件系统是由对象组成的；（）；对象彼此之间仅能 通过传递消息互相联系；层次结构的继承。
A 、 开发过程基于功能分析和功能分解B 、 强调需求分析重要性C 、 把对彖划分成类，每个对象类都定义一组数据和方法D 、对既存类进行调整我的答案：C2【单选题】一个设计良好的信息系统应具有（）的特征A 、 低内聚、低耦合B 、 高内聚、低耦合C 、 高内聚、高耦合D 、低内聚、高耦合我的答案：B3［填空题］面向对象方法通过 ________ 关系表达类之间的静态关系。
我的答案：第一空：关联4【填空题】对象的 _______ 与操作结为一体，成为一个独立不可分的实体，对外屏蔽其内部 细节。
我的答案：第一空：属性5【判断题】面向对象方法比以往的方法更接近人类的日常思维方式，强调运用人类在日常 的逻辑思维中经常采用的思想方法与原则。
第二章使用uml建模教案
大理学院课程教案（理论教学）课程名称：软件工程课程类型：（ 2 ）1、必修；2、选修；3、其它授课对象：计算机科学与技术专业（本、专科） 2011 级1,2班授课时间： 2013 至 2014 学年第 3 学期计划学时： 64 学时（其中：理论 48 ，实验： 16 ）任课教师：杜英国所属学院：数学与计算机学院课程管理部门（教研室）：软件教研室大理学院教务处制课程名称：软件工程教材：面向对象软件工程－使用UML、模式与Java（第2版）清华大学出版社出版，Bernd Bruegge 编著，2006 年第2 版讲授人：杜英国专业技术职务：讲师学历：研究生学位：硕士讲授题目：第二章使用UML建模所属章节：第二章计划学时：4学时教学目的和要求：掌握：用例图、类图、交互图、状态图、活动图、类、抽象类和对象、事件类、事件和消息熟悉：系统、模型和视图、面向对象的建模过程了解：数据类型、抽象数据类型和实例教学重点：用例图、类图、交互图、状态图、活动图、类、抽象类和对象、事件类、事件和消息教学难点：教学方法：多媒体教学，系统讲授，实践教学使用教具：多媒体教学系统思考题：参考资料：1．《UML实践教程—面向.NET开发人员》（美）Martin L. Shoemaker著清华大学出版社2．《UML和模式应用》（美）Craig Larman著李洋郑龚译机械工业出版社3．《SOFTWAREENGINEERING》A PRACTITIONER’S APPROACH ROGER S. PRESSMAN 清华大学出版社第二章使用UML建模图2－4借书处理活动图。
第2章 用例图
构建用例图的过程
步骤 2. 确定参与者及其目标
寻呼台系统。用户如果预订了天气预报，系统每天 定时给他发送天气消息；如果当天气温高于35度， 还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor？用户？气温？ 还是时间？ 回答：时间，或者是一个外部消息发送系统；时间 启动该用例功能，温度是启动之后的一个条件， 所以温度不应算为一个参与者。
用例的必要性
有助于理解系统需求 有助于正确设计系统功能 有助于正确建立需求与功能间的关系
构建用例图
问题详述
系统边界框
用例
用例
参与者
开发典型用例
用例之间的关系
用例之间的关系是可以结构化的。以下是三 种常见的用例关系 包含关系 扩展关系 泛化关系 对于简单的应用，独立用例就足够了。但是， 对于大型应用，组织用例的结构是会有帮助的。 复杂的用例可以用包含、扩展和泛化关系自小 型用例的基础之上构建起来。
修改历史记录* 关于用例的修改时间、原因和修改人信息等
问题*
决策* 频率*
与此用例开发相关的问题列表
关键决策列表 参与者访问该用例的频率
构建用例图的过程
步骤 1. 识别系统边界 步骤 2. 确定参与者及其目标 步骤 3. 确定用例 步骤 4. 确定参与者和用例之间的关系 用例模型的一些准则，书P108 每个用例必须给用户提供价值 用例的描述是非形式化的，但用例的关系 可以形式化
用例图的元素
参与者
一个参与者也可以由多个人来担任
这是错的
这是对的
用例图的元素
参与者
•我们建立的是
系统模型，而非 业务模型，所以 要站在系统的角 度对业务对象进 行有效的分类
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 问题域：指被开发系统的应用领域，即在现实世界中这个系统所 涉及的业务范围。
• 系统责任：指被开发系统应该具备的职能。即在计算机世界中这 个系统所涉及的业务范围。
3.它是由软件需求到最终实现的第一步，它驱动了需求分析之后 的各阶段的开发工作；
其参与者和用例图形元素为：
§2．4 用例与事件流
用例的事件流：指对一个用例的具体细节的描述文档 事件流通常包括： 1.简要说明：简要描述该用例的作用和目标（用例要
达到的结果） 2.前置条件：列出用例之前必须满足的条件（如：前
驱用例或运行权限） 注意：并不是所有用例都有前置条件。 3.主事件流和其他事件流：描述用例的工作流程的事 件流。 包括：用例是怎样开始的； 用例是怎样结束的； 用例如何与参与者交互； 用例的主流程； 用例的非正常流程（其他事件流）； 用例所需要的数据；
例2：
为系统的需求建模
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
<<include>>
IssueFind (交纳罚金)
BorrowBook (借书)
CheckUserInfo (检 查 用 户 合 法 性 )
<<include>>
Borrower (读者)
<<include>>
⑵ 某一个用例的功能过多、事件流过于复杂时可以把某一段事件 流抽象成为一个被包含的用例（提供者），以达到简化描述的 目的。 例如：
Query (查询)
<<include>>
<<include>>
QueryBorrows (查询借阅情况)
QueryBooks (查询图书)
4．扩展关系（Extend） 是把可选的、只在特定条件下运行的行为插入到已有用
4. 后置条件：是用例执行完毕后必须满足的条件（如，使一个标 记为‘真’）
注意：并不是所有用例都有后置条件 说明:事件流的“描述”位置可以放在用例的Specification (规格
说明/属性)对话框General(综合) 页面的Documentation (文档)处
§2．5 用例间的关系
1.关联关系（Association relationship） 是一种结构+语义（动态行为）关系，表示一个事物的
控制之外。 (2)参与者直接同系统交互，这可以帮助定义系统边界 (3)参与者表示人和事物与系统发生交互时所扮演的角
色，而不是特定的人或特定的事物。 (4) 一个人或事物在与系统发生交互时，可以同时或不
同时扮演多个角色。 (5) 每一个参与者需要有一个具有业务一样的名字。 (6) 每个参与者必须有简短的描述，从业务角度描述参
例的方法。 其中：前者被称为“扩展”用例 后者被称为“基础”用例 扩展关系用原型为<<extend>>的依赖关系来表示，其
图形表示如下：
<<extend>>
Extension point OverdueBook
基础用例
扩展用例
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
如图：
Relationship
Actor
UseCase
6.用例图中也可以有注释和约束，还可以有包(Package)
§2. 2 参与者（Actor） 参与者 (Actor) 是指系统以外的，需要使用系统或与 系
统交互的实体（如：人、设备、外部系统等） UML中参与者的表示形式：
ActorName
说明： 1.在构造用例图时，为获取“用例”，首先要确定系统的
成为一个用例，然后让其他用例来包含这个用例。 例如：
客户
Librarian (工作人员)
CreateAccount <<include>> (建立账户)
<<include>>
提供者
ModifyAccount
QueryAccount
(修改账户)
( 查询账户)
<<include>>
DeleteAccount (删除账户)
例1：
Librarian (工作人员)
Borrower (读者)
Teacher Student (教师) (学生)
为系统的上下文建模
|—— Lib—ra—ry—inf—or—ma—tio—n—sy—ste—m——|
|
|
|
|
|
|
|
ReturnBook
|
|
(还书)
|
|
|
|
|
|
|
| | |
BorrowBook (借书)
统中的信息吗? (3) 什么用例会创建、存储、改变、删除、或读取这个
信息？ (4) 参与者需要通知系统外部的突然变化吗? (5) 需要通知参与者系统中正在发生的事情吗? (6) 什么用例将支持和维护系统?
例：某图书馆开发一个图书管理系统，该系统要求实现下列功能： (1) 读者查询（直接通过外部终端进行） 读者查询图书，通过书的种类、出版社、书名、作者等方式查询；
(3) 读者还书（通过工作人员） 根据图书证号、图书号，从“借阅图书文件”中读出该图书相关 的记录（判断是否超期，如果超期则按相应标准收取罚金），登记 还书信息（日期等）, 且将所还书的所有信息存入“借阅历史档案” 中，然后从“借阅图书文件”中注销该图书借阅信息 (4) 管理维护系统（系统管理员通过后台终端），包括：增、减或 更新图书数据；增、减或更新读者账户信息。
把它所包含的行为作为自身行为的一部分。 其中：包含用例称为“客户”用例 被包含用例称为“提供者”用例
包含关系用原型为<<include>>的依赖关系来表示。
其图形表示如下：
<<include> >
如：
<<include>>
客户
提供者
说明：主要有两种情况需要用到包含关系 ⑴ 多个用例用到同一段行为，则可以把这段共同的行为单独抽象
参与者（Actor），可以根据以下问题来寻找系统的 参与者：
(1) 谁是系统的主要用户？ (4) 谁管理、维护系统？ (2) 谁从该系统获得信息？ (5) 与该系统交互的是什么系统？ (3) 谁向系统提供信息？ (6) 系统从那里获得信息？
2.在确定“参与者”过程中，记住以下要点。 (1)参与者对于系统而言总是外部的，因此它们在你的
Login (登录)
SQeuaerrcyh
(查询询))
CheckBorrowInfo (检 查 借 阅 权 限 )
RegisterBorrower
(注册读者)
<<include>>
UpdateBorrower (更新读者)
MaintainBorrower (维护读者)
<<include>>
Administrator (管理员)
对象与另一个事物的对象间的特定的联系（链接）。 例如：教师和学生：存在“老师教学生”关联 员工和公司：存在“员工受聘于公司”关联 用户和软件：存在“用户使用软件”关联
工作人员和读者：存在“业务员为读者办理业务”关 联
注意：参与者（Actor）同用例（Use case）之间的 关系是关联关系（主要体现在“行为”上）。
关联包括双向关联和单向关联，其图形表示分别如下：
例如：
Librarian (工作人员)
Borrower (读者)
LendBook (借书)
ReturnBook (还书)
Search (查询)
2.泛化关系（Generalization） 是一种结构关系，描述一般到特殊之间的关系（继承
关系） 例如：学生和研究生、本科生 泛化关系，其图形表示如下：
读者查询借阅图书情况，通过姓名和图书证号等方式查询。 (2) 读者借书（通过工作人员） 读者凭图书证(书卡)借书。系统首先检查该读者(图书证号)是否有
效，若无效，则拒绝借书；否则进一步检查该读者所借图书是否达 到限额数，若达到限额数，则拒绝借书，否则读者可以借书.把图书 证号、图书号、借书日期和还书日期等登记在借阅图书文件中
4.它是描述系统的动态模型，即是5个UML动态视图之一; 其中,5个UML动态视图是: “用例图”、“状态图”、“活动图”、“时序图”、“协作图”
5．它描述了一组用例、参与者以及它们之间的关系，因此用例图 包括以下3方面内容： (1) 用例（Use case） (2) 参与者（Actor） (3) 关系（Relationship ） •关联关系（Association ） •泛化关系（Generalization ） •依赖关系（Dependence ）
第2章 用例图
§2.1 用例图（Use-Case Diagram）
用例图是参与者（Actor）所能观察到的描述系统功能视图，它 通过用例（Use-Case）来捕获系统的需求。 其中：
1.用例图描述了待开发系统的功能需求，是软件产品外部特性描 述的视图；
2.用例图是从用户的角度而不是从开发者的角度描述软件产品的 需求，分析产品所需的功能和动态行为；
在为系统的需求建模时应考虑： （1）确定系统外部的参与者，从而建立系统的上下文 （2）考虑每个参与者所期望的或要求系统提供的行为 （3）把公共行为命名为用例 （4）确定被其他用例使用的用例或用来扩展其他用例