UML面向对象需求分析重点提要(前6章)
UML面向对象需求分析与建模教程基于uml标准
2
2.2 面向对象方法基本概念与特征
3
2.3 面向对象方法学开发过程
4
2.4下一步发展方向
2.1 了解面向对象产生的原因史
• •
俗话说： “天下大势，分久必合，合久必分。”
Grady Booch
Ivar Jacobson
Rumbaugh
•
ቤተ መጻሕፍቲ ባይዱ
起初软件是手工作坊的生产方式，没 有标准化的过程、工具和技术，从而导致 了大量软件错误。之后计算机专家们提出 了各种语言和方法，但还是不能避免错误 的发生。 • 小型的软件（5000行代码以下的软件） 基本能正确的生产出来，但大中型软件 （50000行代码以上的软件是大型软件，其 间的为中型软件）项目就很难保证。
• Coad和Yourdon将面向对象概念概括为以下方程： 面向对象 = 对象 + 类 + 继承 + 通信 即：面向对象就是既使用对象又使用类和继承等机制，而且 对象之间仅能通过传递消息实现彼此通信。
• 封装性：封装是一种信息隐蔽技术，它体现于类的说明， 使数据更安全.是对象的重要特性。封装使数据和加工该数 据的方法（函数）封装为一个整体，以实现独立性很强的 模块，使得用户只能见到对象的外部特性（对象能接受哪 些消息，具有那些处理能力），而对象的内部特性（保存 内部状态的私有数据和实现加工能力的算法）对用户是隐 蔽的。
2.3 面向对象方法学开发过程
• 现实世界中存在现实对象，然后人们根据 自己的观察角度和要求将现实对象抽象成 现实类，然后软件设计人员基于现实类模 拟出软件类，最后在程序中将软件类实例 化成软件对象，最终的程序就是软件对象 的活动和交互。
学生类 学生实例
面向对象的需求分析
第六章 面向对象的需求分析
2. 用例建模
定义
识别 确
定建
立书
写
系统边界 确 定 用 例 用例间关系 完整用例图 用例描述文档
参与者
举例： 对于大家都非常熟悉的自动取款机（ATM）系统来说，它 的主要参与者有哪些呢？
首先 银行卡用户要通过ATM取款、查询、转账
其次 银行营业部金融系统要和ATM系统交互使 ATM能够获得有关帐户信息并进行账目数 据操作
二是分割了各项系统功能的应用环境，从各项功能项入手 很难了解这些功能如何相互关联实现一个系统服务。
CHENLI
4
回目录
第六章 面向对象的需求分析
2. 用例建模
用例建模——使用用例的方法来描述系统需求的过程。 ❖ 使用 用例图 给出系统的总体功能需求 ❖ 使用 用例描述 说明每个用例的业务规则、用户系统交换序列 ❖ 最终成果是完整准确的系统用例图和详细的用例描述文档
确定系统边界，即定义系统的范围，哪些功能是系统应该实现的，
哪些不是系统应该做的，明确系统目标范围。例如，对于银联网络
的自动取款机网络系统来说，其系统边界范围就是和自动取款机相
关的功能，如用户通过自动取款机取款、查询帐系统户、转账等，以及
银联网络中各个银行之间的帐务结算，而对于各个用银例1的注行释 内部的各营 用例1
❖ 完整的、与用户真正需求一致的用户需求描述，说明用户使用 该系统完成的任务
❖ 用户对系统非功能性需求要列举清楚，例如系统界面要求，性
能要求及系统可靠性要求等CHENLI
3
第六章 面向对象的需求分析
1. 需求分析简介
建议采用 用例(Use Case) 描述系统需求
通过描述用户使用系统的过程，体现系
UML面向对象分析和设计复习
UML面向对象分析和设计复习UML 面向对象分析和设计第1 章UML 简介1、UML中视图有哪些，哪些属于静态视图( 或结构元素)、哪些属于动态视图（或行为元素）视图有：类图、对象图、用例图、状态图、顺序图、活动图、协作图、构件图、部署图、静态视图：用例图、部署图、类图、对象图、构件图动态视图：活动图、协作图、2、结合下面各章节，掌握各视图的作用类图：对象图：3、UML 的英文全称怎么写Unified Modeling Language4、建模的重要性建模是为了能够更好地理解正在开发的系统5、UML的特点它能让系统构造者用标准的、易于理解的方式建立起能够表达出他们想象力的系统蓝图，并且提供一种机制，以便于不同的人之间有效的共享和交流设计结果。
6、在系统模型中为什么要使用多种UML图UML是一种面向对象的建模语言。
它的主要作用是帮助用户对软件进行面向对象的描述和建模，它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。
UML 提供了各种图形，比如用例图、类图、时序图、协作图和状态图等，来把这些模型元素及其关系可视化，让人们可以清楚容易地理解模型，可以从多个视角来考察模型，从而更加全面地了解模型第2 章理解面向对象1、类、对象、属性、操作、抽象、继承、多态性、封装、消息传递、关联、多重性、聚集等各名词的含义类是对象的一个建模。
对象是类的一个实例。
属性是描述对象静态特征的一个数据项。
抽象是过滤掉对象的一部分特性和操作直到只剩下你锁需要的属性和操作。
继承是有共同的属性和行为多态性是不同的类具有相同的操作。
封装是一个对象执行自己的操作时，它对外界隐藏了操作的细节。
消息传递是一个对象发送一个操作消息给另一个对象，接收消息的对象就执行这个操作关联是对象之间通常以某种方式发生联系多重性是对象之间的关系。
聚集是由部分对象组成2、上述几个概念中第3 章运用面向对象1、类图的表示，可以表示出哪些信息类图用矩形表示2、对象图的表示3、包的含义第4 章关系1、什么是关联，关联上的约束当类之间在概念上有连接关系时，类之间的连接叫关联Or约束，在两条关联线之间连一条虚线，虚线之上标注or来表示这样约束。
UML学习重点汇总
第一章OOM&软件建模概述UML（Unified Modeling Language）通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。
标准建模语言UML适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。
特点：统一标准，面向对象，可视化、表达能力强，独立于过程，UML很适合于以体系结构中心的、用例驱动的、迭代式和渐增式的软件开发过程第二章UML构成1. UML的“4+1视图”从某个角度观察系统构成系统的一个视图，每个视图都是系统描述的一个投影，说明了系统某个侧面的特征。
（1）用例视图（2）逻辑视图（3）组件视图（4）进程视图（并发视图）（5）配置视图（部署视图）2. UML的模型图：模型图是一组UML模型元素构成的有向图表示，它通常由一组节点（UML基本模型元素）, 及节点之间的连线（关系）组成。
(1) 用例视图：用例图(2) 静态模型：类图、对象图、包图、构件图和配置图(3) 动态模型：活动图、顺序图、状态图和协作图3. 用例图.用例图是表达用例和参与者及其关系的载体。
关系包括：关联关系，依赖关系实现关系：3. 用例图(续)——用例之间关系1（包含与扩展）.3. 用例图(续)——用例之间关系2（泛化）.3. 用例图(续)——用例与参与者用例Use Case：一组用例的实例（场景），其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值。
描述了从参与者角度看系统做了什么用例模型本身不是面向对象建模技术。
参与者Actor: 是指在系统外部与系统交互的人或其他系统，以某种方式参与了系统内用例的执行。
4. 交互式视图图(顺序图、协作图)1）协作图：采用图的形式展示对象间的交互2）顺序图：采用栅栏格式展示对象间的交互顺序图与协作图的优缺点：顺序图（优点）强调消息的时间顺序及对象生命线（优点）大量详细表示法选项（缺点）强制在右侧增加新对象，消耗空间大协作图（优点）强调结构组织，复杂交互表达更容易（优点）空间利用率高，和方便添加新对象（缺点）不宜查询消息的顺序，表示法选项少5 活动图活动图用于表示完成一个操作所需要的活动，或者是一个用例实例（场景）的活动。
第6章-面向对象需求分析
8.1.4需求验证
• 在设计之前验证需求的正确性及其质量， 能大大减少项目的后期返工现象。
• 需求验证的任务是保证需求符合完整性、 正确性、灵活性、必要性、无二义性、 一致性、可跟踪性及可验证性这些良好 特征。 • 最后双方签字。
会谈：包括正式会谈和非正式会谈
• 一般先进行非正式会谈，提出一些可自由回答 的问题鼓励会谈人员表达自己的想法。询问客 户对目前系统为什么不满意，了解问题的性质、 需要解决的方案，所需的人数和能力，客户的 目标和收益。 • 正式会谈提出实现准备好的议题，需要准备一 份会谈概要的书面材料，最好每人一份，一遍 陈述及发现忽略的项目。 • 对大型系统，通常有不同类型的用户，可形成 多种视点，这时需要进行面向多视点的需求分 析。
类图
class diagrams
顺序图
sequence` diagrams
对象图
object diagrams
协作图
collaboration diagrams
构件图
component diagrams
状态图
statechart diagrams
部署图
deployment diagrams
活动图
activity diagrams
– 参与者、类、类元角色、构件、数据类型、接口、节点、 信号、子系统、用例
– 接口（interface）和实现
• 实例：一类事物的特定实例；如my bank account • 接口：说明事物行为的契约（做什么） • 实现：事物是如何工作的特殊细节（如何做）
UML各章知识点小结
UML各章知识点小结第一章面向对象分析和设计在OO开发中，至关重要的能力是什么？为软件对象分配职责什么是分析?▪强调的是对问题和需求的调查研究，而不是解决方案▪澄清两个概念：需求分析：对需求的调查研究面向对象分析：对领域对象的调查研究什么是设计？▪强调的是满足需求的概念上的解决方案（在软件方面和硬件方面），而不是其实现。
面向对象分析（做正确地事）▪强调的是在问题领域内发现和描述对象（或概念）面向对象设计（正确地做事）▪强调的是定义软件对象以及它们如何协作以实现需求。
OOAD 最关心流程与元件1. 描述流程(剧情) ---- 分析2. 安排主/配角(元件)演出---- 设计OOAD 最主要的工具UML (Unified Modeling Language)第一章思维导图第二章迭代、进化和敏捷动机:迭代和进化式瀑布生命周期▪在编程之前就预先完成需求和设计步骤▪软件项目的高失效率迭代和进化式开发▪及早地引入编程和测试,并重复这一循环▪会在还没有详细定义所有需求的情况下假设开发开始▪使用反馈来明确和改进演化中的规格说明▪依赖于短时快速的开发步骤、反馈和改写来不断明确需求和设计▪软件项目的较高成功率什么是迭代和进化式开发如何在迭代项目中处理变更抱以接受变更和改写的态度，是迭代和进化式开发真正本质的驱动力！！迭代反馈和进化向预期系统的方向发展。
需求和设计的不稳定性随着时间逐步下降迭代开发的优点⏹减少项目失败可能性,提高生产率、降低缺陷率⏹在早期缓解高风险⏹早期可见的进展⏹早期反馈、用户参与和调整,会产生更接近涉众真实需求的精华系统⏹可控复杂性⏹一次迭代中的经验可以被系统地用于改进开发过程本身UP的阶段第三章案例研究案例研究中涵盖的内容☐一个应用程序通常包括：✓UI元素✓核心应用逻辑✓数据库访问✓与外部软硬件的协作用户界面应用逻辑层其它层或构件较少关注讨论如何与其它层连接案例研究主要关注讨论如何设计对象次要关注UP 思维导图敏捷开发 思维导图第四章初始不是需求阶段初始阶段是建立项目共同愿景和基本范围的比较简短的起始步骤它包括：▪10％的用例进行分析▪关键的非功能需求的分析▪业务案例创建▪开发环境的准备▪初始阶段需解决的问题：本项目的愿景（vision）和业务案例（business case）?可行性（Feasible）?购买/开发（Buy and/or build）?粗略估计成本（cost）: 1万-10万，还是百万?项目是进行下去还是停止?什么是初始阶段用一句话来概括初始阶段：预见项目的范围、愿景和业务案例用一句话来概括初始阶段要解决的主要问题：涉众是否就项目愿景基本达成一致，项目是否值得继续进行认真研究。
《UML2面向对象分析与设计 第2版 》读书笔记思维导图
设计
5
9.5 练习题
第10章 从模型到代码
10.1 正向工程 10.2 逆向工程
10.3 模型驱动架 构
10.4 练习题
参考文献
图书资源支持
关于本书
谢谢观看
04
7.4 职责 分配模式
06
7.6 练习 题
05
7.5 其他 问题
第8章 架构设计
8.1 过渡到设计
8.2 架构设计基 础
8.3 确定设计元 素
8.4 引入设计机 制
8.6 描述系统部 署
8.5 定义运行时 架构
8.7 练习题
第9章 构件设计
9.1 用例设 1
计
9.2 子系统 2
设计
3
9.3 类设计
3.7 练习题
第4章 用例建模
4.1 理解需求
4.2 从业务模型 获取需求
4.3 建立用例模 型
4.4 编写用例文 档
4.6 其他问题
4.5 重构用例模 型
4.7 练习题
第5章 用例分析
01
5.1 理解 分析
025.2 从用 例开始分析035.3 架构 分析
04
5.4 构造 用例实现
06
5.6 练习 题
05
5.5 定义 分析类
第6章 面向对象的设计原则
6.1 设计需要原 则
6.2 Liskov替换 原则
6.3 开放—封闭 原则
6.4 单一职责原 则
6.6 依赖倒置原 则
6.5 接口隔离原 则
6.7 练习题
第7章 面向对象的设计模式
01
7.1 模式 与设计模式
02
7.2 GoF模 式
第六章 面向对象的需求分析
2、通过角色的动作，绘出系统的用例图。
角色需要从系统获得哪种功能？需要角色做什么？ 角色需要读取、产生、删除、修改或存储系统中的某种信息么？ 系统中发生的事件需要通知角色么？角色需要通知系统某事件么？这些事件能干什么？ 系统需要输入/输出的是什么？这些输入/输入的信息从哪儿来？到哪儿去？ 系统当前的实现要解决的问题是什么？
6.2.1静态建模 1用例模型(use case)
用例模型作用：
确定系统应具备的功能 为系统的功能提供清晰一致的描述 为系统的验证工作打下基础
2、用例模型对语境建模
① ② ③
④
识别系统外部的参与者。 将类似参与者组织成泛化的结构层次。 在需要加深理解的地方，为每个参与者提供一个构 造型。 将参与者放入到用例图中，并说明参与者与用例之 间的通信路径。
如何抽取对象和类
1、从系统中抽取部分名词或名词短语 可以得到候选对象 2、参考用例图，考察候选对象的特征， 确定正式对象 3、确定对象的属性，操作，并抽象类， 用类/对象图表示
3.2.2、定义类的结构和层次
常见的类的层次： 一般-特殊 整体-部分
例：一般-特殊结构
例：整体-部分结构
3.2.3、定义主题或子系统
第六章 面向对象的需求分析
1、面向对象的概念与思想 2、面向对象分析的描述工具 3、面向对象分析方法 4、基于UML的建模方法
1 面向对象的概念与思想
•什么是面向对象 •对象 •类 •消息 •继承 •面向对象方法的开发过程 •复用 •概念的封装和实现的隐蔽
2、面向对象分析的描述工具
1、用例图：显示用例（表示系统功能）与角色 （表示提供或者接收系统信息的人或系统）之间 的交互
面向对象的需求分析
第六章 面向对象的需求分析
学习目的： ① 学习用例建模方法 ② 掌握用例图的使用
1. 1. 需求分析简介 需求分析简介 2. 用例建模 3. 用例建模实例
回目录
第六章 面向对象的需求分析
学习目的： ① 学习用例建模方法 ② 掌握用例图的使用
需求分析简介 1. 1. 需求分析简介 2. 用例建模 3. 用例建模实例
第六章 面向对象的需求分析
2. 用例建模
定 义 系统边界 确 定 参与者
识别 用例
确 定 用例间关系
建 立 完整用例图
书 写 用例描述文档
识别用例最佳方法是从分析 参与者 开始，将每类参与者代表和需 求分析人员召集到一块进行讨论，每个参与者考虑自己是如何使用 系统的，提出自己的需求，然后大家再一块讨论确定。 使用这种头脑风暴的策略，在讨论的过程中还有可能会发现新的参 与者，这对完善整个系统的需求建模是有很大帮助的。 用例建模的过程是一个不断迭代和逐步完善的过程，系统分析人员 首先确定系统的用例图，从整体上对系统的需求进行定义，然后再 添加用例的详细描述信息，用于对参与者使用系统用例和系统的具 体交互序列的定义 ：
第六章 面向对象的需求分析
2. 用例建模
用例建模——使用用例的方法来描述系统需求的过程。 使用 用例图 给出系统的总体功能需求 使用 用例描述 说明每个用例的业务规则、用户系统交换序列 最终成果是完整准确的系统用例图和详细的用例描述文档
第6章 面向对象的需求分析
第6章面向对象的需求分析本章主要讲述面向对象软件开发方法所涉及到的基本概念，以及用UML如何表示面向对象方法所用到的概念。
具体包括面向对象的概念与特征；统一建模语言（UML）；基于UML的需求分析等。
6.1 基本内容6.1.1 面向对象的概念与特征1．面向对象方法概述面向对象的基本思想是将一个实际问题看成是一个对象或几个对象的集合。
面向对象分析过程是在系统所要求解的问题中找出对象（属性和行为）以及它所属的类，并定义对象与类；面向对象设计是把系统所要求解的问题分解为一些对象及对象间传递消息的过程；面向对象实现是把数据和处理数据的过程结合为一个对象。
对象既可以像数据一样被处理，又可以像过程一样被描述处理的流程和细节。
总之，面向对象分析到面向对象设计再到面向对象实现（即OOA→OOD→OOI）不用转换。
面向对象分析与设计的实质是一种系统建模的技术，它不是从功能或算法上考虑整个系统，而是从系统的组成上进行分解，利用类及对象作为软件的基本构造单元，以更接近人类思维的方式建立模型，从而使设计出的系统尽可能直接地描述现实世界，构造出模块化、可重用、易维护的软件。
2．面向对象的基本概念(1) 对象对象是一个封装了数据和操作的实体。
对象的结构特征由属性表示，数据描述了对象的状态，操作可操纵私有数据（把数据称为“私有”的，是因为数据是封装在对象内部，是属于对象的。
）改变对象的状态。
对“对象”概念的理解，应该把握：从广义上讲，面向对象中的对象就是我们实际生活中可以感触或意识到的人或物的真实写照，而系统分析和程序设计中的对象(即对象模型)是这些实际人和物的数学抽象。
也就是说，我们把客观世界的实体称之为问题（问题域）的对象。
对象也可以是一种概念实体，我们并不能直接感触到这些实体，但可以意识到其存在。
比如，打印队列在生活中并不存在，但是在程序员的思维中可以意识到这个实体的存在，而且起到一定的作用，它完全可以作为系统中的对象。
UML--面向对象分析与设计 第一部分 基础知识
面向对象方法的优点
按照人类的自然思维方式，面对客观世界建立软件系 统模型。有利于对问题域和系统责任的理解，有利于 人员交流。
对需求变化的适应性。把最稳定的部分，即对象作为 构筑系统的基本单位，而把容易发生变化的部分，既 属性与服务，封装在对象之内，对象之间通过接口联 系，使得需求变化的影响尽可能地限制在对象内部。
可维护性好。
支持软件重用。对象所具有的封装性和信息屏蔽等特 性，使它容易实现软件重用。对象类可以派生出新类， 类可以产生实例对象，这些就实现了对象类的数据结 构和操作代码的软构件重用。
面向对象的软件开发语言与工具
1981推出的Smalltalk-80 面向对象的C/C++、Basic、Pascal、Fortran、
开发的目标、开发方法、开发过程、软件文档、质量标准等都给 出了明确的规定。
软件开发管理模型—瀑布模型(Waterfall Model)
瀑布模型的优点
使早期的手工作坊式的软件开发转变为软件工程 消除非结构化软件、降低软件复杂度 有一套严格的计划、步骤、规格、方法，保证软件产
品达到预期的质量要求 20世纪70年代以来得到广泛的传播
类是对象的抽象，它给出了属于该类的全部对象的抽 象定义。（从对象产生类）
– 问题域：类是一组具有相同特性和行为的对象的集合 – 系统： 共同的特性通过属性表现出来 (数据)
共同的行为通过操作表现出来 (功能)
类是对象的模板，用它可以产生多个对象，一个具体 的对象只是类的一个实例。（从类产生对象）
一个好的软件开发方法和技术要能有效的应付 系统需求的变化。
4、软件重用：
面向对象的需求分析.pptx
1）结构化分析的实体关系图 ，关注实体的属性和相互间的 关系；而面向对象的分析，除 此之外还有非常主要的一点， 就是关注实体的行为。 2）结构化分析的数据流图， 将数据和加工处理分开；而面 向对象的分析是将数据实体和 他们的处理动作视为不可分割 的整体来考虑的。 3）结构化分析建造系统的元 素是基于过程的功能，或者加
多态性的表示有静态类型和动态类型。动态类型（虚函数） 可以在程序执行期间在实例之间进行变化。静态类型（函数 重载）是在程序上下文中由实体说明决定的。
虚基类 （纯）虚函数
class vehicle appearance
moving()
类/对象之间的关系——一般与特殊
一般－特殊：是由一组具有一般－特殊关系的类所组成的 结构。它是一个以类为结点，以继承关系为边的连通有向 图。如果由一些存在单继承关系的类形成的结构又称作层 次结构或树型结构，如果由一些存在多继承关系的类形成 的结构又称作网状结构。
认识世界解决问题的方法与过程，这样更好的把客观世界的问
题空间映射到软件的解空间 仿真语言 simula 67 20世纪80年代初期：smalltalk语言是面向对象技术发展的重 要里程碑
它是一种新兴的程序设计方法，其基本思想是使用对象、类、 继承、封装、消息等基本概念来进行程序设计。
现在面向对象方法已深入到计算机领域的几乎所有分支，远
信息的接受者是提供服务的对象。在设计时，它对外提供的 每个服务都应该规定消息的格式，这种规定称做消息协议。
发送者对象 属性：
接收者对象 属性：
▪ 面向对象基本特征——封装性
（Encapsulation）
对象是进行处理的主体，必须发消息请求执行它的某个操作 ，处理它的私有数据，同时不能从外界直接对它的私有数据进行 操作。也就是说，一切局部于该对象的私有信息，都被封装在该 对象类的定义中，在对象的外部是不可见的，即不能直接使用， 这就是“封装性”。
6需求分析-面向对象
确定参与者
• 普通读者 • 图书管理员 • 注册用户
注册用户
小型图书管理系统
普通读者
图书管理员
确定用例
• 普通读者 —预订图书 —取消预订 • 图书管理员 —管理用户 —管理图书资料 —管理书目 —登记借书 —登记还书 • 注册用户 —登录 —查询图书
“小型图书管理系统”中 存在的关系？
绘制用例图
返回
边界类
• 类型 用户界面、系统接口和设备接口 • UML的表示
返回
控制类
• 概述 —负责协调边界类和实体类 —一般来说，一个用例表示一个控制类 • UML的表示
返回
实体类
• 概述 —通常指用例中的参与对象，对应现实世界的“事物” —例如：人员、组织、物品、设备、事件或者表格 • UML的表示
返回
MiniLibrary——识别边界类
边界类 ManageBorrowerForm ManageBookForm ManageBookitemForm LendForm ReturnForm 描述 管理普通读者的界面 管理书籍资料的界面 管理书目的界面 登记借书的界面 登记还书的界面
返回
MiniLibrary——识别控制类
为了方便旅客，某航空公司拟开发一个机票预定系统。 为了方便旅客，某航空公司拟开发一个机票预定系统。 旅行社把游客信息录入到系统中， 旅行社把游客信息录入到系统中，系统为旅客安排航 打印取票通知单， 班，打印取票通知单，旅客在起飞前一天凭取票通知 单交款取票，系统校对无误后打印机票给旅客。 单交款取票，系统校对无误后打印机票给旅客。若旅 客中途因故不能旅行，旅行社可取消预定。 客中途因故不能旅行，旅行社可取消预定。
:BItemInfo
UML面向对象的分析
第一章面向对象的软件工程简介一、传统软件工程方法存在的问题软件工程提出至今，并没有从根本上解决软件开发问题，软件危机现象依然存在。
就其原因：主要是随着软件应用范围的扩大，软件问题越来越复杂，但也有传统软件工程本身存在的问题，表现在：1、预定义需求的假设是不现实的：需求是模糊的、变化的；需求的沟通是困难的。
2、结构化分析和设计方法存在的问题：需求以功能为基础，分析和设计以过程为基础。
3、思维方式（认识、分析问题的思想方法）与人们平常的习惯不一致。
为了解决这一问题，软件工程有了新的发展：快速原型法和面向对象法。
下面只介绍面向对象的软件工程方法。
二、面向对象的软件工程方法简介1、基本思想：使软件开发的过程、方法和思想与现实问题的结构以及人类认识和解决问题的方法相一致。
要点：●认为客观世界是由各种对象组成的●所有对象都划分成各种对象类●自然界中的所有类组成类的层次结构●对象之间通过消息相互联系面向对象= 对象+ 类+ 继承+ 通讯软件开发的优点：●与人类习惯的思维方式一致●稳定性好：传统方法基于功能的分析和分解，功能的变化常常会引起软件系统结构的变化。
而在OO方法中，功能的变化往往采用从已有类派生出新的子类的方法以实现功能的扩充和修改。
●可重用性好：对象和类都是可重用的软件“预制件”，通过参数化和实例化增加重用性。
●可维护性好：独立性好，稳定、易于修改、修改造成的影响小、易于理解。
2、基本概念：●对象：是现实中任何可以明确界定和区别的事物或其抽象的实体和概念。
Object = < ID，MS，DS，MI >其中：ID：标识；MS：操作集合；DS：数据结构；MI：消息集合●类：一组对象共同属性（数据和操作）的抽象。
●实例：一个具体的个体。
●消息：对象操作的具体调用说明。
●方法：操作的具体算法。
●属性：描述对象特性的数据。
●继承：子类自动共享父类中定义的数据和方法的机制。
●对象之间的关系：ISA（抽象），PART – OF（聚合），关联（除此之外）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第一章1、面向过程和面向对象首先是一个认识论，其次是方法论。
认识论决定方法论。
2、软件开发分成5个阶段：需求分析阶段，系统分析与设计阶段、系统实现阶段、测试阶段，维护阶段。
3、分析模型和设计模型最早在Jacobson的OOSE中就提出来了，不是RUP中首先提出的。
这两个模型的本质差别在于：1.分析模型是对问题域的描述，而独立于实现技术的。
2.设计模型是使用具体的实现技术实现分析模型，是依赖于实现技术的4、面向对象分析的主要活动包括：理解用例模型、识别分析类、定义交互行为、建立分析类图以及评审分析模型等面向对象分析应该建立：功能模型、分析对象模型和动态模型等三种类型。
其中功能模型由用例和场景表示，分析对象模型由类图和对象图表示，动态模型由状态图和顺序图表示。
4、面向对象中那些图代替了面向过程中的图？系统结构图——————用例图IPO图——————时序图或协作图数据流图——————带有实现类的活动图(带泳道)E-R ——————类图和对象图第二章1、UML不是系统设计的方法，只是一种表示法。
UML（Unified Modeling Language 统一建模语言）是一种定义良好、易于表达、功能强大且普遍适用的建模语言（更不是编程语言）。
UML是一个标准的图形表示法，它不是面向对象的分析和设计，也不是一种方法，它仅仅是一组符号而已。
2、在理解用户需求方面UML提供了有用例图、时序图、活动图、状态图。
在描述系统的静态结构方面，UML提供了类图、对象图、包图、用例图。
在描述系统的动态结构方面，UML提供了活动图、时序图、状态图、协作图。
系统设计，系统分析，用户需求都要用到的图：时序图。
3、UML的作用（why）?答：1.为软件系统建立可视化模型2.为软件系统建立构件3.为软件系统建立文档4.UML比任何一种程序语言的语义都丰富。
5.UML的类图是E-R图的超集4、UML由基本词汇和语法两个部分构成，包括了UML语义和UML表示法两个部分。
一般情况下，状态图被作为是对类图的具体补充。
5、补充类图是用例图的细化，所有图都是用例图的细化。
状态图和活动图在语义上是等价的，时序图与协作图也是。
如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。
两者之间可以相互转换。
6、行为图包括有状态图、活动图。
交互图包括有时序图和协作图。
实现图包括有构件图和部署图。
第三章1、Why：为什么软件企业要采用行之有效的软件过程？答：行之有效的软件过程可以提高软件企业的开发效率：首先，通过理解软件开发的基本原则有助于对软件开发过程中重要的问题作出明智的决定；其次，可以促进开发工作的标准化、促进项目小组之间的可重用性和一致性；第三，它提供了一个可以使软件企业引进行业内先进实践技术的机会，这些技术包括代码检测、配置管理、变更控制和体系结构建模等2、RUP是由Rational软件公司开发的一种预定义好的软件过程框架。
软件项目真正的灵魂是软件过程3、RUP有三个突出的特点：（1）用例驱动；（2）以架构为中心；（3）采用迭代和增量模型4、RUP过程框架模型每个循环包括四个阶段：初始、细化、构建和产品化。
每个阶段的主要工作是：初始化阶段的主要工作是：业务建模、需求分析，次要工作是分析设计、项目管理。
里程碑：命周期目标里程碑；细化阶段的主要工作是：需求、分析设计、实施。
里程碑：周期结构里程碑；构建阶段的主要工作是：实施，配置与变更管理，部署。
里程碑：功能里程碑；产品化阶段的主要工作是：配置与变更管理，部署。
里程碑：发布里程碑；5、RUP可用4个基本元素来表达：1.角色（Workers, the "who" ）2.活动（Activities, the "how" ）3.产出品（Artifacts, the "what" ）4.工作流（Workflows, the "when" ）一个工作流可以被表述为一个序列图（sequence diagram ）, 一个协同图（collaboration diagram ）, 或者一个活动图（an activity diagram ）。
7、RUP核心工作流：业务建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在业务用例模型和业务对象模型中定义组织的过程，角色和责任在需求捕获阶段、分析设计阶段和测试阶段，都使用相同的use-case 模型。
设计模型是代码如何编写的蓝图。
整个系统是通过构件的实现而实现的测试的执行是沿着三个质量维度进行的：可靠性，功能、性能。
8、补充：角色并不代表个人，而是说明个人在业务中应该如何表现以及他们在业务活动中应该承担的责任9、Why: 投入那么多成本来实施统一过程值得吗？1.采用统一过程可以提髙软件成熟度。
2.采用统一过程可以提髙软件技术水平和质量的需要。
3.统一过程适于开发稳定的架构，它通过不断的演进来逐步推进软件产品，这一特点使得它特别适合于长期战略的软件产品。
10、适用场合：对于大型公司和大型项目来说，RUP却非常适合。
Relations: RUP和XP也不是非此即彼的关系，比如对整体项目来说，用RUP是适合的，具体到细部倒是可以应用XP。
第五章1、为什么会有衍生型？答：在建模的不同阶段，为了区分同一视图在不同阶段的区别，会用不同的图来表示2、使用者有三大类：系统用户、与所构建的系统交互的其它系统和一些可以运行的进程（对第三类使用者的说明：当经过一定的时间触发系统中的某个事件时，时间就成了使用者）。
3、How：如何确定使用者？答：①从系统边界内外的角度，通过回答问题确定使用者：谁对系统有着明确的目标和要求并且主动发出动作？系统是为谁服务的？谁对系统产生的结果感兴趣②从涉众和岗位设置的角度回答问题以确定使用者。
③从外部系统的角度回答问题以确定使用者。
④从系统内进程或定时做某项工作的角度。
4、业务范围和系统范围是不同的？业务范围指项目所涉及的所有客户业务，这些业务有没有软件系统都客观存在。
系统范围则是指软件实现的那些对应于业务功能的系统功能。
从功能性需求来说系统范围是业务范围的一个子集5、（Why）建立业务模型、查找业务用例都必须使用业务主角。
（How）如何使用业务主角？答：(1). 在查找业务主角时必须抛开计算机。
这是因为在初始需求阶段，需要获得的是客户的业务模型，根据业务模型才能建立计算机系统模型。
(2). 业务主角必须在实际业务里能找到对应的岗位或人员。
6、业务工人：图书馆管理员是业务工人，借阅者是使用者。
在建模时，有些人员是被动参与业务的，而且是在系统之内，被称为“业务工人”。
不需要为他们建立业务模型。
（How）如何区分使用者和业务工人呢？最直接的办法是判断是在边界之外还是边界之内。
如果边界尚不清楚，可以通过下面的三个问题确定边界：◆他是主动向系统发出动作的吗？◆他有完整的业务目标吗？◆系统是为他服务的吗？7、Relations：使用者与涉众、操作者及角色的关系？⑴.使用者与涉众的关系◆并不是所有的涉众都是系统的使用者。
◆使用者是涉众的代表。
使用者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源。
使用者通过对系统提出要求来获得他所代表的涉众的利益。
⑵.使用者与操作者的关系1) 操作者是使用者的实例或代理。
一个操作者可以代理多个使用者。
2) 并非所有的使用者都是操作者⑶.使用者与角色的关系1)一个角色代表了系统中的一类职责。
例如办公自动化系统中。
2)由于一个用户可以代理多个使用者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。
角色一般适合用在概念阶段的模型里，以表达业务的逻辑理解。
处于核心地位的是使用者通信关联关系和用例说明表明使用者和系统是如何相互关联关系的。
是否有两个使用者担任与用例相关的同一角色？如果有，应该利用使用者泛化关系来为他们的共享行为建立模型。
其他的动作都是合并8、用例一是由使用者启动，用例不能没有启动者；二是结果对使用者要可观测；三是结果对使用者要有意义；四是多种可能活动场景集合成一个用例。
一个完整的用例定义由使用者、前置条件、场景、后置条件构成。
业务模型是系统模型的最重要输入。
1、业务用例实现是实现对象追溯到需求的一个重要环节。
在后续的建模过程中，根据业务用例实现将得出关键业务对象，再从业务对象转化到设计对象，生成代码。
2、业务用例与系统用例的区别体现在：业务用例可以理解为使用者的行为，是客户能提出的需求。
系统用例可理解为系统的行为，来支持/协助使用者完成其行为，是对需求的另一方面的阐述。
业务用例是客户业务视角，而系统用例则是系统视角。
3、业务用例模型与系统用例模型之间的关系⑴.业务用例模型与系统用例模型图的相似之处◆两者都有参与者。
在业务用例图中，将一个参与者原型化为<<BusinessActor>>。
两者都有用例。
在业务用例模型中，将一个用例原型化为<<Business用例>>◆在参与者与用例之间两者都有一个通信关联。
◆业务用例和系统用例都能够包含、扩展，以及一般化关联。
⑵．不同之处在于设计范围：业务用例着重于业务操作，系统用例着重于要设计的软件系统。
白盒测试与黑盒测试：业务用例常常是以白盒形式编写的，系统用例以黑盒形式编写的业务操作者：在系统用例图中，只让参与者与用例进行交互。
但在业务用例图中，可以让业务参与者和业务角色与业务用例进行交互。
4、UML 业务模型包括两个模型:用例视图（Use-Case View）中的业务用例模型(用例图)和逻辑视图（Logical View）中的业务分析模型（类图，时序图、通信图）用例视图（Use-Case View）中的业务用例模型和逻辑视图（Logical View）中的业务分析模型5、用例的特征：a 完备性：用例在“功能”上是完备的b. 可观测和有意义性：用例的执行结果对使用者来说是可观测的和有意义的。
c用例总是由一个使用者发起的，使用者的愿望是这个用例存在的原因。
不存在没有使用者的用例，用例不应该自动启动，也不应该主动启动另一个用例。
d．用例必然是以动宾短语形式出现的6、评判有效用例的三种测试的方法：老板测试、EBP测试、规模测试。
看看就是了：EBP测试用一种更加精确的方式量化了用例的有效性。
它除了要求进行有价值的业务操作以外，还必须产生有价值的、持续保留的数据。
同时，它还要求了完成这个任务的时效性，即必须在一个会话中完成。
持续数日或跨越多个会话的用例都不能通过这个测试。
不能通过规模测试的一个典型错误，就是将系统的一个步骤中作为用例。
7、发现用例的前提条件是发现使用者；而确定使用者的同时就确定了系统边界。