面向对象分析模型总结
第5讲 面向对象的分析-建立对象模型
在需求陈述中，找到一些名词词组 领域知识和常识 只需要重要的属性，不需要实现阶段的属性 不能把对象作为属性 不能把关联类的属性作为一般对象的属性 不能把限定当作属性，如分行代码是限定词，决定 总行拥有的哪一个分行 如果有毫不相关的属性，则可以考虑分解为两个类
识别继承关系
继承关系的识别,需要领域知识 自底向上,有共同属性泛化出父类 自顶向下,将父类细化成子类
1．面向对象分析过程
首先，系统分析员要对需求文档进行分析。发现和改正需求 文档中的歧义性、不一致性，剔除冗余的内容，挖掘潜在的 内容，弥补不足，从而使需求文档更完整、更准确。 然后，是需求建模。系统分析员根据提取的用户需求，即用 面向对象观点建立对象模型、动态模型和功能模型。
最后，是需求评审。通过用户、领域专家、系统分析员和系 统设计人员的评审，并进行反复修改后，确定需求规格说明。
完善
1 给关联定义含义明确的名字。“分行拥有柜员终 端” 2 为了适应不同的关联，分解前面析出的类 如事务分解为远程事务和柜员事务 3 补充。 当分解出柜员事务后，多出几个关联，如 柜员输入柜员事务，ATM上输入远程事务 4 标明重数。
ATM系统原始的类图
确定属性
确定类间关联
由需求陈述中的动词词组表示关联关系 确定隐含的关联
总行有多个分行构成 分行保管帐号 储户拥有现金兑换卡
根据问题域知识得到的关联
现金兑换卡访问帐号 分行雇佣柜员
筛选
1去掉前面已删除的对象引起的关联 2 去掉实现阶段考虑的关联 3 去掉瞬时事件（有更长期的联系存在） 4 将3元关联，变为两个2元的，或者限定的 5 去掉重复的关联。如总行拥有多台ATM, 事 实上是与（总台拥有中央计算机，中央计算 机与ATM通信）重复的
OOAD总结
第一章1、什么是分析与设计？1、分析强调对问题和需求的调查研究2、设计强调的是满足需求的概念上的解决方案2、什么是面向对象分析与设计？1、在面向对象分析过程中，强调的是在问题领域内发现和描述对象（或概念）2、在面对对象设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。
3、简单示例：1、定义用例（use case）需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。
2、定义领域模型（domain model）面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。
需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。
（也被称为概念领域模型—conceptual object model）3、定义交互图关注的是软件对象的定义—它们的职责和协作。
顺序图（sequence diagram）是描述协作的常见方法。
它展示对象之间的信息流，和由消息引起的方法调用。
4、定义设计类图除了在交互图中显示对象协作的动态视图外，还可以用设计类图（design class diagram）来有效的表示类定义的静态视图。
这样可以描述类的属性和方法。
与领域模型表示的是真实世界的类，设计类图表示的是软件类要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。
第二章1、什么是UML？统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。
UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构（Model Driven Architecture, MDA）CASE工具供应商具有影响。
开发者并不需要对其进行学习。
2、三种UML应用方式1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。
2、UML作为蓝图—相对详细的设计图。
用于：①逆向工程；②代码生成。
面向对象的数据建模方法介绍
面向对象的数据建模方法介绍面向对象的数据建模是一种在软件开发过程中广泛应用的方法，旨在通过将现实世界的事物抽象成对象，对事物之间的关系进行建模和描述。
本文将介绍面向对象的数据建模方法，包括实体关系模型(ERM)、统一建模语言(UML)和面向对象数据库。
一、实体关系模型(ERM)实体关系模型是一种常用的数据建模方法，用于表示现实世界中各个实体之间的关系。
在ERM中，实体用矩形框表示，属性用椭圆表示，关系用菱形表示。
通过定义实体、属性和关系之间的约束和限制，可以精确描述现实世界的结构和行为。
举例来说，假设我们要建立一个图书馆管理系统，可以使用ERM来描述图书、读者和借阅等实体之间的关系。
图书可以有属性如书名、作者和出版日期，读者可以有属性如姓名、年龄和性别，而借阅则将图书和读者关联起来，表示读者借阅了某本图书。
二、统一建模语言(UML)统一建模语言是一种广泛使用的面向对象建模语言，用于描述软件系统的结构和行为。
UML提供了一系列图表，包括类图、对象图、用例图和活动图等，可以方便地对系统进行建模和分析。
在UML中，类图是最常用的图表之一，用于表示系统中的类和类之间的关系。
每个类都有属性和方法，与ERM中的实体和属性类似。
通过类图可以清晰地展示系统的结构，帮助开发人员理解和设计软件系统。
三、面向对象数据库面向对象数据库是一种将面向对象思想应用于数据库管理系统的方法。
传统的关系型数据库以表格形式存储数据，而面向对象数据库则将数据存储为对象，更贴近面向对象的思维方式。
面向对象数据库支持复杂的数据结构和对象之间的继承关系，可以更方便地进行数据操作和查询。
使用面向对象数据库可以有效地解决关系型数据库中数据表之间的复杂关系和数据冗余的问题。
总结：面向对象的数据建模方法是一种有效的软件开发方法，可以帮助开发人员更好地理解和描述现实世界中的事物和关系。
通过实体关系模型、统一建模语言和面向对象数据库等方法，可以将复杂的现实世界映射为清晰的数据结构，并支持系统的设计和开发。
面向对象分析与设计UML校园二手交易平台课程报告
面向对象分析与设计（UML）课程学习报告题目：校园二手交易平台班级：姓名：学号：指导教师：日期：一、使用UML工具分析与设计软件的心得与实践总结首先，在我们一开始确定软件的功能与非功能需求的时候就出现了问题，因为我们做的是校园二手交易系统，所以我们必须确定要实现的功能需求有哪些，怎么样才能做出一个贴合实际的二手交易系统？通过小组成员间的讨论和思考，最终我们确定了软件的几个重要功能：会员注册登录、管理员登录、二手商品发布、商品分类搜索、发布商品求购信息和管理员的管理功能等，确定了软件的设计方向；其次是在用例模型构建和细化的时候，由于我们对用例图和时序图的理解不够深刻，导致我们画的用例图和时序图出现了一些常识性和逻辑性的问题，最终在老师的指导下我们改正了这些错误；最后出现的问题是在详细设计的时候，因为我们对DAO类认识不够，所以使得我们在画类图的时候出现了问题，但是经过和别的小组进行讨论，最终还是解决了这个问题。
其实，在设计过程中还出现了其他的一些问题，但是基本上可以通过自己的思考和成员间的讨论解决。
我想说的是通过这次UML工具分析与设计软件，让我懂得了只是会啃书本是远远不够的，还要通过实践，自己进行操作。
只有通过实践才能发现自己在知识掌握上的不足，从而使自己的学习有所提高，才能学到书本上学不到的知识。
最重要的是还能够加强自己的思维能力、动手能力和小组成员间的合作能力，这对我们以后的学习和工作是有很大帮助的。
同时也要感谢老师的悉心指导和大力帮助。
二、需求模型图以及软件的界面设计如右图所示，我们系统的功能需求是会员注册管理、会员发布商品、会员相互发送信息、会员发布求购信息、商品分类搜索、管理员登录、会员管理、商品管理和公告管理等。
因为我们做的是交易平台，所以必须要像淘宝一样拥有足够的安全保障。
因此系统必须要有会员注册和登录功能，来保障会员的权益。
二手交易平台，如名字那样，系统必须能够实现商品的发布和购买等交易功能，因此，我们给系统设计了会员发布求购信息、会员分类搜索和商品管理等功能。
9_面向对象的需求分析方法
9.1 面向对象技术概述9 面向对象的需求分析方法二者的本质区别• 面向过程的结构化系统 = 功能 + 数据 • 面向对象的系统 = 对象 + 消息9 面向对象的需求分析方法二者的本质区别银行账户对象 存款 取款 利息结算 账户 余额 存 款 账户 余额 利息结算 外部消息 取 款9 面向对象的需求分析方法面向对象方法的发展历史• 初始阶段• 1960’s：Simula编程语言 • 1970’s：Smalltalk编程语言• 发展阶段• 1980’s：理论基础，许多OO 编程语言(如C++, Objective-C等)• 成熟阶段• 1990’s：面向对象分析和设计方法(Booch, OMT等), Java • 1997：OMG 组织的统一建模语言(UML) • 逐渐替代了传统的结构化方法9 面向对象的需求分析方法面向对象的软件工程• 面向对象分析(Object Oriented Analysis, OOA)• 分析和理解问题域，找出描述问题域和系统责任所需的类及 对象，分析它们的内部构成和外部关系，建立OOA 模型。
• 面向对象设计(Object Oriented Design, OOD)• 将OOA 模型直接变成OOD 模型，并且补充与一些实现有关 的部分，如人机界面、数据存储、任务管理等。
• 面向对象编程(Object Oriented Programming, OOP)• 用一种面向对象的编程语言将OOD 模型中的各个成分编写成 程序，由于从OOA→OOD→OOP实现了无缝连接和平滑过 渡，因此提高了开发工作的效率和质量。
9 面向对象的需求分析方法面向对象的软件工程现实世界OOA结构化分析OOD结构化设计OOP结构化编程可执行软件系统9 面向对象的需求分析方法OO中的喷泉过程模型• 喷泉模型：• 在OO开发过程中，各阶段之间形 成频繁的迭代； • OO各阶段均采用统一的“对象”概 念，各阶段之间的区分变得不明 显，形成“无缝”连接，从而容易实 现多次反复迭代。
软件开发工程中的模型和方法论
软件开发工程中的模型和方法论一、引言在当今的信息化社会，软件开发工程正日益成为人们生产和生活中必不可少的一部分。
随着技术的不断更新，软件开发工程中的模型和方法论也在不断发展，以满足不同行业、不同领域的需求。
本文将从软件开发过程中的需求分析、设计、编码和测试四个阶段，介绍一些常用的模型和方法论。
二、需求分析阶段需求分析阶段是软件开发中最关键的阶段之一。
只有深入了解用户需求，并将其转化为软件需求，才能够开发出用户满意的软件。
在需求分析阶段，较为常用的方法论是面向对象分析和用例驱动方法。
1.面向对象分析面向对象分析（Object-Oriented Analysis，OOA）是一种用对象的概念描述用户需求的方法。
它着重于人们认为的实际对象，而不是过程或操作。
面向对象分析强调对象的属性、状态、行为和它们之间的相互作用。
面向对象分析是以面向对象编程（OOP）为基础的。
开发人员通过面向对象分析获得的对象模型，可以更好地设计和构建软件。
在面向对象分析中，需求分析师通常会使用一些UML（统一建模语言）工具，比如类图、用例图、状态图等，以支持对需求的分析和设计。
2.用例驱动方法用例驱动方法（Use Case Driven Methodology，UCD）是一种以用例为中心的开发方法，它能够有效地比较和交流用户需求。
用例是指从用户的角度描述软件应该如何工作的一种方式，是用来理解和规范用户需求的工具。
用例驱动方法认为，“不同的用户需求可能会聚集在同一个用例中。
”通过用例，我们可以把所有的需求聚集到一起，得到一份权威的需求列表。
在UCD中，需求分析师通常会使用用例图、分类图等工具，以支持需求的分析和设计。
三、设计阶段在完成需求分析之后，就进入了设计阶段。
在这个阶段中，我们需要根据需求分析的结果，设计出一份系统架构和详细的设计方案。
1.结构化设计结构化设计（Structured Design）是一种以数据流程图和结构图为基础的设计方法。
面向对象分析模型总结
2
主要原则
（1）抽象 什么叫抽象？ OO方法广泛地运用抽象原则，例如： ·系统中的对象是对现实世界中事物的抽象， ·类是对象的抽象， ·一般类是对特殊类的进一步抽象， ·属性是事物静态特征的抽象， ·操作是事物动态特征的抽象。 过程抽象 任何一个完成确定功能的操作序列，其使用者都 可把它看作一个单一的实体，尽管实际上它可能 是由一系列更低级的操作完成的。 数据抽象 根据施加于数据之上的操作来定义数据类型，并 限定数据的值只能由这些操作来修改和观察。
汽车
奖杯
钟表
操作员 职员
天平 楼房 飞机
起重机
23
如何发现参与者 ——考虑人员、设备、外系统
人员—— 系统的直接使用者 直接为系统服务的人员 设备—— 与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相连的设备 × 计算机设备 × 外系统—— 上级系统 子系统 其它系统
24
用况（use case）
7
基本模型——类图 面向对象的建模中最重要、最基本的模型图 集中而完整地体现了面向对象的概念 为面向对象的编程提供了直接、可靠的依据 可以从三个层次来看
对象层
需求模型——用况图 每个用况是一项系统功能使用情况的 说明，把每一类参与者对每一项系统 功能的使用情况确切地描述出来，便 全面地定义了系统的功能需求
数据接口部分设计
构件化与系统部署
向OOP输出OOD模型
12
OOA与OOD的关系
一致的概念与表示法 OOA和OOD采用一致的概念和表示法，从而不存在分析与 设计之间的鸿沟。 不同的内容、目标和抽象层次
OOA：研究问题域和用户需求，运用面向对象的观点发现 问题域中与系统责任有关的对象，以及对象的特征和相互 关系。目标是建立一个直接映射问题域，符合用户需求的 OOA模型。 OOD：在OOA模型基础上，针对选定的实现平台进行系统 设计，按照实现的要求进行具体的设计，目标是产生一个 能够在选定的软硬件平台上实现的OOD模型。 OOA模型：抽象层次较高，忽略了与实现有关的因素 OOD模型：抽象层次较低，包含了与实现平台有关的细节
实验四1、 面向对象分析建模
实验四面向对象分析建模（一）需求描述：王大夫在小镇上开了一家牙科诊所。
他有一个牙科助手、一个牙科保健员和一个接待员。
王大夫需要一个软件系统来管理预约。
当病人打电话预约时，接待员将查阅预约登记表，如果病人申请的就诊时间与已定下的预约时间冲突，则接待员建议一个就诊时间以安排病人尽早得到治疗。
如果病人同意建议的就诊时间，接待员将输入约定时间和病人名字。
系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。
在每次治疗或清洗后，助手或保健院将标记相应的预约诊治已经完成，如果必要的话会安排病人下一次再来。
系统能够按病人姓名和日期进行查询，能够显示记录的病人数据和预约信息。
接待员可以取消预约，可以打印出前两天预约尚未接诊的病人清单。
系统可以从病人记录中获知病人的电话号码。
接待员还可以打印出关于所有病人的每天和每周的工作安排。
（二）实验目的：（1）根据给出的需求描述进行面向对象分析建模；（2）建立系统的对象模型中的初始类图；建立系统功能模型中的用例图；（3）初始类图给出搜索类的过程；（4）熟练使用画图工具“visio”绘制图形，软件---UML模型。
（三）实验内容：用面向对象的分析方法建立系统的对象模型、功能模型。
（四）实验步骤：（1）根据需求描述搜索系统中可能成为类的名词或名词词组。
然后进行筛选获得系统初始的类对象。
（2）搜索需求描述中的动词或动词词组找出类对象之间可能存在的关系（关联、共享聚集、组合聚集、泛化、依赖等）。
（3）用“visio”完成初试类图、时序图的绘制。
五：试验结果：（1）.王大夫牙科诊所牙科助手牙科保健员接待员病人登记表软件系统（2）.开了一家牙科诊所需要一个软件系统来管理预约打电话预约查阅预约登记表申请的就诊时间预约时间安排病人尽早得到治疗同意建议输入约定时间和病人名字系统将核实提供记录的病人数据标记相应的预约诊治已经完成安排病人下一次再来查询显示记录取消预约打印清单获知病人的电话号码打印工作安排（3）.。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
建立基本模型 发现对象
定义对象 的特征
定义对象 间的关系
OOA 过程
建 立 模 型 规 约
建立辅助模型
建立 包图
建立 顺序图
建立 活动图
建立 其他图
11
OOD 过程
输入OOA模型 问题域部分设计
人机交互部分设计
控制驱动部分设计
数据接口部分设计
构件化与系统部署
向OOP输出OOD模型
12
OOA与OOD的关系
15
从MDA看OOA与OOD的关系
模型驱动的体系结构（model-driven architecture，MDA ） 是OMG的一个技术规范，是一种加强模型能力的系统开发途 径。
模型驱动（ model-driven ）：用模型来对系统的理解、设 计、构造、部署、操作、维护和更改进行指导。
体系结构（ architecture ）：是对系统的部件和连接件以及 这些部件通过连接件进行交互的规约。
参与者：在系统边
界以外，与系统进
对
行交互的事物—— 参与者(人员) 象
人员、设备、外系
统
对象 对象 对象
对象 对象
系统边界
参与者(设备)
参与者(外系统)
22
现实世界中的事物与系统之间的关系——分四种情况
（1）被抽象为系统中的对象 （2）只作为系统外部的参与者与系统交互 （3）既是系统中的对象，本身又作为参与者与系统交互 （4）与系统无关
强调严格的阶段 划分和前后次序
先做完OOA再进 行OOD
测试 维护
演化
集成(OOA)
瀑布模型
喷泉模型
14
OOA与OOD的分工——两种不同的观点
第二种观点
分析
设计
问题域与 系统责任
与实现有 关的因素
第 一
分做 什
种 析么
观
点
设怎
么
计做
关键问题：对象的特征细节（如属 性的数据类型和操作流程图），是 在分析时定义还是在设计时定义？
辅助模型——其他各种图 对类图起到辅助作用，提供更详细的建模信息，或者从不 同的视角来描述系统。例如包图、顺序图、活动图等
模型规约 对上述各种模型图及其模型元素的详细而确切的定义和 解释。
8
OOA模型框架
基本模型：类图
需求模型：
对象层
用况图
特征层
关系层
模型规约
辅助模型： 包图
顺序图 活动图
……
9
OOD模型框架
汽车
钟表
职员
起重机
飞机
奖杯 操作员
楼房
天平
23
如何发现参与者 ——考虑人员、设备、外系统
人员—— 系统的直接使用者 直接为系统服务的人员
设备—— 与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相连的设备 × 计算机设备 ×
外系统—— 上级系统 子系统 其它系统
24
用况（use case）
OOA模型：抽象层次较高，忽略了与实现有关的因素 OOD模型：抽象层次较低，包含了与实现平台有关的细节
13
在软件生存周期中的位置
——可适应不同的生存周期模型
分析 (OOA)
设计 (OOD)
编程 (OOP)
各个阶段之间没有 严格的界限，其活 动可以交叠和回溯
有些工作既可在 OOA中进行，也可 在OOD中进行 各阶段概念和表示 法的一致为采用这 种模型提供了条件
4
（8）粒度控制
人们在研究问题时既需要微观的思考，也需要宏观的思 考。因此需要控制自己的视野：考虑全局时，注重其大 的组成部分，暂时不详察每一部分的具体的细节；考虑 某部分的细节时则暂时撇开其余的部分。这就是粒度控 制原则。
引入包（package）的概念，把模型中的类按一定的规则 进行组合，形成一些包，使模型具有大小不同的粒度层 次，从而有利于人们对复杂性的控制。
·认识系统的并发行为 在分析阶段根据，根据系统的需求和事物的主动性 来认识系统的并发行为。在设计阶段，根据具体的 实现条件确定系统中需要设计哪些控制流。
6
模型及其规约
在分析阶段和设计阶段建立的系统模型分别称为OOA模型 和OOD模型 正规理解：一个系统模型，应包括建模过程中产生的图形 、文字等各种形式的文档。因为，所谓“模型”是指某一 级别上的系统抽象描述，构成这种描述的任何资料都是模 型的一部分。 习惯说法：目前大部分OOA/OOD著作谈到“模型”，一般 是指OOA或OOD过程中产生的图形文档。 一般习惯——将模型和模型规约分别讨论 OOA和OOD模型包括需求模型、基本模型和辅助模型，通 过模型规约 做详细说明
一致的概念与表示法 OOA和OOD采用一致的概念和表示法，从而不存在分析与 设计之间的鸿沟。
不同的内容、目标和抽象层次
OOA：研究问题域和用户需求，运用面向对象的观点发现 问题域中与系统责任有关的对象，以及对象的特征和相互 关系。目标是建立一个直接映射问题域，符合用户需求的 OOA模型。
OOD：在OOA模型基础上，针对选定的实现平台进行系统 设计，按照实现的要求进行具体的设计，目标是产生一个 能够在选定的软硬件平台上实现的OOD模型。
平台（platform）：是一组子系统和技术，它通过一些接口 和专用规则提供了一个连贯的功能集合，任何由该平台支持 的应用都可以使用平台所提供的功能而不必关心其实现细节。
平台无关模型（platform independence model，PIM）： 独立于任何一种平台特征的模型。
平台专用模型（platform specific model，PSM）：与特定 类型的平台特征有关的模型。
考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么 作用，描述其外部可见的行为。
系统是由一条 边界包围起来 的未知空间
系统边界以外 是与系统进行 交互的参与者
只通过有限 的几个接口 与外部交互
把内外交互情况描 述清楚，就确切地 定义了系统的需求
21
系统边界与参与者
系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。 系统：被开发的计算机软硬件系统，不是指现实系统。 系统成分：在OOA和OOD中定义并且在编程时加以实现的系统元素——对 象
OOA&D方法总结
1
主要概念
面向对象的概念包括以下两种情况： （1）用来构成系统模型的某种基本成分，称为建模元素 （2）在建模中需要遵守的某种原则，不代表任何模型成分
主要建模元素 对象、类（所有的对象都通过类来表示） 属性、操作（类属性和实例属性，被动操作和主动操作） 一般-特殊关系，一般-特殊结构 整体-部分关系，整体-部分结构 关联 （二元关联、多元关联） 消息 （控制流内部的消息，控制流之间的消息）
OOA：只针对问题域和系统责任，不涉及实现条件 因此可得到一个平台无关的OOA模型
OOD：在OOA模型基础上针对特定实现条件进行设计 转换成一个平台专用的OOD模型
好处：使整个OOA模型可以在针对不同的实现平台的设 计中得到复用
18
需求模型——用况图
需求分析和系统分析
需求分析的确切含义是对用户需求进行分析，旨在产生一份明确、规范的需求定 义。
26
收款
例
内容与书写格式 ：
输入开始本次收款的命令；
名称 行为陈述（分左右栏） 调用语句
3
（2）分类 分类就是把具有相同属性和操作的对象划分为一类， 用类作为这些对象的抽象描述。 不同程度的抽象可得到不同层次的类，形成一般-特殊 结构（又称分类结构）。 强调：在类的抽象层次上建模
（3）封装 （4）继承 （5）聚合 （6）关联
（7）消息通信 即要求对象之间只能通过消息进行通讯，而不允许在 对象之外直接地存取对象内部的属性。
2
主要原则
（1）抽象 什么叫抽象？ OO方法广泛地运用抽象原则，例如： ·系统中的对象是对现实世界中事物的抽象， ·类是对象的抽象， ·一般类是对特殊类的进一步抽象， ·属性是事物静态特征的抽象， ·操作是事物动态特征的抽象。 过程抽象 任何一个完成确定功能的操作序列，其使用者都 可把它看作一个单一的实体，尽管实际上它可能 是由一系列更低级的操作完成的。 数据抽象 根据施加于数据之上的操作来定义数据类型，并 限定数据的值只能由这些操作来修改和观察。
OOA的主要内容是研究问题域中与需求有关的事物，把它们抽象为系统中的对象， 建立类图。确切地讲，这些工作应该叫做系统分析，而不是严格意义上的需求分 析。
早期的OOA缺乏一个良好的基础——对需求的规范描述。
Jacobson方法（OOSE）提出用况（use case）概念，解决了对需求的描述 问题，其分析过程如下：
需求说明
分析过程 需求分析
健壮分析
需求模型
分析模型
19
OOA是将问题域中的事物抽象为系统中的对象 抽象的目标是系统责任——需求 用况的概念解决了对需求的描述问题
系统责任
（抽象的目标）
需求模型 （用况图）
OOA模型 （类图）
问题域 （抽象的来源）
20
基本思路
问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的系统？ 如何规范地定义用户需求？
第二种观点的理由：
（1）过分强调“分析不考虑怎么做”
将使某些必须在OOA考虑的问题得不到 完整的认识。 （2）把仅与问题域和系统责任有关的 对象的描述在分析阶段一次完成，避免 设计阶段重复地认识同一事物，减少了 工作量总和。 （3）对那些与问题域和系统责任紧密 相关的对象细节，分析人员比设计人员 更有发言权。 （4）由于OOA和OOD概念和表示法的一 致，不存在把细化工作留给设计人员的 必然理由。 （5）OOA阶段建立平台无关的模型 （PIM），OOD阶段针对不同的平台建立 平台专用模型（PSM）可在最大程度上 实现对OOA结果的复用。