软件工程讲义_第07章 构建分析模型
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
分析的结果必须是高度可维护的，尤其是 要将此结果应用于目标文档。 必须使用一种有效的分割方法解决规模问 题。 尽可能使用图形符号。 考虑问题必须区分逻辑的和物理的。
需求分析
需求分析产生软件操作特征的规格说明， 指明软件和其他系统元素的接口，建立软 件必须满足的约束。需求分析让软件工程 师细化在前期需求工程工作中建立的基础 需求，并建立模型描述用户场景、功能活 动、问题类和类之间的关系、系统和类行 为以及数据流。
现代软件工程
第7章 构建分析模型
主要内容
需求分析 分析建模的方法 数据建模概念 面向对象的分析 基于场景建模 面向流的建模 基于类的建模 生成行为模型 小结
分析模型
文字记录是极好的交流工具，但并不必然 是表达计算机软件需求的最好方式。分析 建模使用文字和图表的综合形式，以相对 容易理解的方式描绘需求的数据、功能和 行为，更重要的是，可以更直接地评审它 们的正确性、完整性和一致性。 软件工程师使用从客户那里提取的需求构 建模型。
为数据对象的实例命名； 描述这个实例； 建立对另一个表中的另一个实例的引用。
另外，必然把一个或多个属性定义为标识 符（主键）。 通过对问题环境的理解可以恰当地确定特 定数据对象的一组属性。
数据对象和OO类
数据对象定义了一个复合的数据项，也就 是说合并一组独立的数据项(属性)并为数 据项集合取个名字(数据对象名)。一个OO 类封装了数据属性但也合并了对这些属性 所定义数据进行处理的操作。另外，类的 定义暗示了一个作为面向对象软件工程方 法一部分的全面的基础设施。类之间通过 消息通信，它可以按层次关系组织并为类 的实例——对象——提供继承属性。
分析模型在系统描述和设计模型之间建立桥梁
图7-1分析模型在系统描述和设计模型之间建立桥梁
分析的经验原则[ARL02]
模型应关注在问题域或业务域内可见的需求， 抽象的级别应该相对高一些。 分析模型的每个元素都应能增加对软件需求的 整体理解，并提供对信息域、功能和系统行为的 深入理解。 关于基础结构和其他非功能的模型应推延到设 计阶段再考虑。 最小化整个系统内的关联。 确认分析模型为所有共利益者都带来价值。 尽可能保持模型简洁。
基于场景建模
如果软件工程师了解最终用户（和其他参 与者）希望如何与系统交互，软件团队将 能够更好地、更准确地刻画系统特征，完 成更有针对性的分析和设计模型。使用 UML分析建模，将从开发用例、活动图和 泳道图形式的场景开始。
编写用例
用例捕获信息的产生者、使用者和系统本 身之间发生的交互。 用例从某个特定参与者的角度用简单易懂 的语言说明一个特定的使用场景。但是我 们应该知道：(1)编写什么？(2)写多少？ (3)编写说明应该多详细？(4)如何组织说 明？
SafeHome系统ACS-DCV功能的活动图
图7-7 ACS-DCV功能的活动图
泳道图
UML泳道图是活动图的一种有用的变形， 可让建模人员表示用例所描述的活动流， 同时指示哪个参与者或分析类对活动矩形 所描述的活动负责。职责由纵向分割图的 并列条形部分表示，就像游泳池中的泳道。 ACS-DCV功能的泳道图如图7-8所示。
SafeHome实例[14]
编写用例
这个连续的陈述没有考虑其他可能的交互。这种 类型的用例有时被称作主场景。 要完整地理解所描述的功能，必需说明可能的交 互。主场景中的每个步骤将通过如下提问得到评 估：
在这一点，参与者能进行一些其他活动吗？ 在这一点，参与者有没有可能遇到一些错误的情况？ 在这一点，参与者有没有可能遇到一些其他的行为？ 如果有，是什么？
域分析的输入和输出
图7-2 域分析的输入和输出
分析建模的方法
一种考虑数据和处理的分析建模方法被称 作结构化分析，其中数据作为独立实体转 换。数据对象建模定义了对象的属性和关 系，操作数据对象的处理建模应表明当数 据对象在系统内流动时处理如何转换数据。 分析建模的第二种方法称作面向对象的分 析，这种方法关注于定义类和影响客户需 求的类之间的协作方式。UML和统一过程 主要是面向对象的。
关系
数据对象可以以多种不同的方式互相连接。 可以用一组“对象/关系对”来定义有关的 关系。图7-5b以图形方式说明了这些对象 /关系对，并提供了关于关联方向的重要信 息，这一方向信息通常可以减少不确定性 或误解。
数据对象之间的关系
图7-5 数据对象之间的关系
基数和形态
数据建模的基本元素——数据对象、属性 和关系——为理解问题的信息域提供了基 础。然而，还必须理解与这些基本元素相 关的其他元素。 就软件工程的目的而言，简单地说对象 X 与对象Y相关并没有提供足够的信息。我们 必须理解对象X的多少次出现和对象Y的多 少次出现相关，这引出了被称为基数的数 据建模概念。
编写用例
两个首要的需求工程工作——起始和导 出——提供了开始编写用例所需要的信息。 运用需求收集会议、QFD和其他需求工程 机制确定共利益者，定义问题的范围，说 明整体的操作目标，概述所有已知的功能 需求，描述系统将处理的信息（对象）。 要开始开发用例，应列出特定参与者执行 的功能或活动。这些可以从所需系统功能 的列表中获得，或通过与客户或最终用户 交流获得，或通过评估活动图获得。
SafeHome系统ACS-DCV功能的泳道图
图7-8 ACS-DCV功能的泳道图
面向流的建模
面向流的数据建模至今仍是最广泛使用的分析表 达法之一。尽管数据流图及相关的图和信息不是 UML的正式组成部分，但是它们可以补充UML图 并提供对系统需求和流的补充认识。 DFD采取了系统的输入-处理-输出观点。流入软 件的数据对象，经由处理元素转换，最后以结果 数据对象的形式流出软件。数据对象由带标记的 箭头表示，转换由圆圈（也称作泡泡）表示。 DFD使用分层的方式表示，即第一个数据流模型 从整体上表现系统，随后的数据流图改进环境图， 提供每个后续层增加的细节。
分析建模的方法
软件团队往往选择一种方法并排斥另一种 方法中的所有表示手段。问题不是哪一种 方法最好，而是怎么组合这些表示手段才 能够为共利益者提供最好的软件需求模型 和过渡到软件设计的最有效方法。 分析模型将生成如图7-3所示的每个建模 元素的派生类。然而，不同项目之间，每 个元素的特定内容可能因项目而异。软件 团队必须想办法保持模型的简单性。只有 那些为模型增加价值的建模元素才能使用。
面向对象的分析
面向对象的分析(OOA)，其目的是定义与 即将解决的问题相关的所有类(以及与其相 关的关系和行为)。为实现这一点，必须完 成如下一些工作：
1、在客户和软件工程师之间必须对基本的用户需求进 行交流。 2、必须确定类（即定义属性和方法）。 3、定义类的层次结构。 4、表现对象与对象的关系（对象连接）。 5、必须为对象行为建模。 6、上述1-5的工作步骤重复迭代直至模型完成。
域分析
分析模型通常在特定业务领域内的很多应 用中重复发生。如果用一种方式对这些模 式加以定义和分类，让软件工程师或分析 师识别并复用这些模式，将促进分析模型 的创建。更重要的是，应用可复用的设计 模式和可执行的软件构件的可能性将显著 增加。
域分析
软件域分析是识别、分析和详细说明来自 某个特定应用领域的公共需求，特别是那 些在该应用领域内被多个项目重复使用 的……“面向对象的域分析”是在某个特 定应用领域内，根据通用的对象、类、部 件和框架、识别、分析和详细说明公共的、 可复用的能力。 域分析的目标很简单，就是：查找或创建 那些分析类和（或）能够广泛应用的、共 有的功能和特点，这样就可以复用。
分析模型在系统级描述和软件设计的差距之间 建立桥梁。 重要的是要注意到在系统描述中给出分析模型 的某些元素，并且需求工程的工作实际上是作为 系统工程的一部分开始的。此外，分析模型的所 有元素都可以直接跟踪到设计模型。通常难以区 分这两个重要的建模活动之间的设计和分析工作， 有些设计总是作为分析的一部分进行，而有些分 析将在设计中进行。
面向对象的概念
属性——说明一个类的数值集合。 类——封装数据和过程的抽象，这些是说明某些 真实世界中的实体的内容和行为所必需的。即类 是一组相似对象的概括说明。 对象——某个特定类的实例。对象具有类的属性 和操作。 操作——也称为方法和服务，表现类的某个行为。 子类——超类的特化，子类可以从超类继承属性 和操作。 超类——也称作基类，是一组相关类的泛化。
SafeHome系统的初步用例图
图7-6 SafeHome系统的初步用例图
开发活动图
UML活动图通过提供特定场景内交互流的 图形化表示来补充用例。活动图使用圆角 矩形表示一个特定的系统功能，箭头表示 通过系统的流，判定菱形表示判定分支， 水平线意味着并行发生的活动。ACS-DCV 功能的活动图如图7-7所示。
分析模型
可以使用很多不同格式的图表为信息、功 能和行为需求建模。基于场景的建模从用 户的角度表现系统；面向流的建模在说明 数据对象如何通过处理函数进行转换方面 提供了指示；基于类的建模定义了对象、 属性和关系；行为建模描述了系统状态、 类和事件在这些类上的影响。一旦创建了 模型的雏形，就将不断改进，并分析评估 其清晰性、完整性和一致性。最终的分析 模型将由所有的共利益者确认。
基数和形态
数据模型必须能够表示在一个给定的关系 中对象出现的次数。 基数是关于一个（对象）的出现次数可以 与另一个（对象）的出现次数相关联的规 格说明。 对于关系的出现，如果没有明确的必要性 或关系是可选的，那么关系的形态是0；如 果关系必须出现一次，那么形态是1。
数据建模
数据建模工具为软件工程师提供表现数据 对象、数据对象的特点和数据对象的关系 的能力。主要用于大型数据库应用系统和 其他信息系统项目，数据建模工具以自动 化的方式创建全面的实体—关系图、数据 对象字典以及相关模型。
分析模型
必须评审分析建模工作产品的正确性、 完整性和一致性，必须反映所有共利益者 的要求并建立一个可以从中导出设计的基 础。
分析模型
在技术层面上，软件工程开始于一系列的 建模工作，最终生成待开发软件的需求规 格说明和全面的设计表示。分析模型实际 上是一组模型，是系统的第一个技术表示。
分析阶段的目标[DEM79]
数据对象
数据对象只封装数据——在数据对象内没 有对作用于数据的操作的引用。数据可以 表示为如图7-4所示的一张表，表头反映 了对象的属性。表体表示了数据对象的特 定实例。
数据对象的表格表示
图7-4 数据对象的表格表示
数据属性
数据属性定源自文库了数据对象的性质，可以具 有三种不同的特性之一。它们可以用来：
这些问题的答案导致创建一组次场景，次场景属 于原始用例的一部分，但是表现了可供选择的行 为。
SafeHome实例[15]
编写用例
在很多情况下，不需要创建使用场景的图 形化表示。但是图形化表示可以促进理解， 尤其是当场景比较复杂时。UML为用例提 供了图形化表现的能力。图7-6为 SafeHome系统的初步用例图。
分析模型的元素
图7-3 分析模型的元素
数据建模概念
分析建模通常开始于数据建模。软件工程 师或分析师需要定义在系统内处理的所有 数据对象、数据对象之间的关系以及其他 与这些关系相关的信息。
数据对象
数据对象是几乎任何必须被软件理解的复 合信息的表示。复合信息是指具有若干不 同的特征或属性的事物。 数据对象可能是外部实体、事物、发生或 事件、角色、组织单位、地点或结构。 “数据对象描述”包括了数据对象及其所 有属性。
SafeHome实例[12]
编写用例
随着和共利益者更多地交谈，需求收集团 队为每个标记的功能开发用例。通常，用 例首先用非正式的描述性风格编写。如果 需要更正式一些，可以使用类似前一章中 提出的某个结构化的形式重新编写同样的 用例。
SafeHome实例[13]
编写用例
描述性用例的一种变形是通过用户活动的 顺序序列表现交互，每个活动由声明性的 语句表示。
需求分析
在整个分析建模过程中，软件工程师的主 要关注点集中在“做什么”而不是“怎么 做”方面。包括：系统处理什么对象？系 统必须执行什么功能？系统显示什么行为？ 定义什么接口？有什么约束？
整体目标和原理
分析模型必须实现三个主要目标：
描述客户需要什么； 为软件设计奠定基础； 定义在软件完成后可以被确认的一组需求。
需求分析
需求分析产生软件操作特征的规格说明， 指明软件和其他系统元素的接口，建立软 件必须满足的约束。需求分析让软件工程 师细化在前期需求工程工作中建立的基础 需求，并建立模型描述用户场景、功能活 动、问题类和类之间的关系、系统和类行 为以及数据流。
现代软件工程
第7章 构建分析模型
主要内容
需求分析 分析建模的方法 数据建模概念 面向对象的分析 基于场景建模 面向流的建模 基于类的建模 生成行为模型 小结
分析模型
文字记录是极好的交流工具，但并不必然 是表达计算机软件需求的最好方式。分析 建模使用文字和图表的综合形式，以相对 容易理解的方式描绘需求的数据、功能和 行为，更重要的是，可以更直接地评审它 们的正确性、完整性和一致性。 软件工程师使用从客户那里提取的需求构 建模型。
为数据对象的实例命名； 描述这个实例； 建立对另一个表中的另一个实例的引用。
另外，必然把一个或多个属性定义为标识 符（主键）。 通过对问题环境的理解可以恰当地确定特 定数据对象的一组属性。
数据对象和OO类
数据对象定义了一个复合的数据项，也就 是说合并一组独立的数据项(属性)并为数 据项集合取个名字(数据对象名)。一个OO 类封装了数据属性但也合并了对这些属性 所定义数据进行处理的操作。另外，类的 定义暗示了一个作为面向对象软件工程方 法一部分的全面的基础设施。类之间通过 消息通信，它可以按层次关系组织并为类 的实例——对象——提供继承属性。
分析模型在系统描述和设计模型之间建立桥梁
图7-1分析模型在系统描述和设计模型之间建立桥梁
分析的经验原则[ARL02]
模型应关注在问题域或业务域内可见的需求， 抽象的级别应该相对高一些。 分析模型的每个元素都应能增加对软件需求的 整体理解，并提供对信息域、功能和系统行为的 深入理解。 关于基础结构和其他非功能的模型应推延到设 计阶段再考虑。 最小化整个系统内的关联。 确认分析模型为所有共利益者都带来价值。 尽可能保持模型简洁。
基于场景建模
如果软件工程师了解最终用户（和其他参 与者）希望如何与系统交互，软件团队将 能够更好地、更准确地刻画系统特征，完 成更有针对性的分析和设计模型。使用 UML分析建模，将从开发用例、活动图和 泳道图形式的场景开始。
编写用例
用例捕获信息的产生者、使用者和系统本 身之间发生的交互。 用例从某个特定参与者的角度用简单易懂 的语言说明一个特定的使用场景。但是我 们应该知道：(1)编写什么？(2)写多少？ (3)编写说明应该多详细？(4)如何组织说 明？
SafeHome系统ACS-DCV功能的活动图
图7-7 ACS-DCV功能的活动图
泳道图
UML泳道图是活动图的一种有用的变形， 可让建模人员表示用例所描述的活动流， 同时指示哪个参与者或分析类对活动矩形 所描述的活动负责。职责由纵向分割图的 并列条形部分表示，就像游泳池中的泳道。 ACS-DCV功能的泳道图如图7-8所示。
SafeHome实例[14]
编写用例
这个连续的陈述没有考虑其他可能的交互。这种 类型的用例有时被称作主场景。 要完整地理解所描述的功能，必需说明可能的交 互。主场景中的每个步骤将通过如下提问得到评 估：
在这一点，参与者能进行一些其他活动吗？ 在这一点，参与者有没有可能遇到一些错误的情况？ 在这一点，参与者有没有可能遇到一些其他的行为？ 如果有，是什么？
域分析的输入和输出
图7-2 域分析的输入和输出
分析建模的方法
一种考虑数据和处理的分析建模方法被称 作结构化分析，其中数据作为独立实体转 换。数据对象建模定义了对象的属性和关 系，操作数据对象的处理建模应表明当数 据对象在系统内流动时处理如何转换数据。 分析建模的第二种方法称作面向对象的分 析，这种方法关注于定义类和影响客户需 求的类之间的协作方式。UML和统一过程 主要是面向对象的。
关系
数据对象可以以多种不同的方式互相连接。 可以用一组“对象/关系对”来定义有关的 关系。图7-5b以图形方式说明了这些对象 /关系对，并提供了关于关联方向的重要信 息，这一方向信息通常可以减少不确定性 或误解。
数据对象之间的关系
图7-5 数据对象之间的关系
基数和形态
数据建模的基本元素——数据对象、属性 和关系——为理解问题的信息域提供了基 础。然而，还必须理解与这些基本元素相 关的其他元素。 就软件工程的目的而言，简单地说对象 X 与对象Y相关并没有提供足够的信息。我们 必须理解对象X的多少次出现和对象Y的多 少次出现相关，这引出了被称为基数的数 据建模概念。
编写用例
两个首要的需求工程工作——起始和导 出——提供了开始编写用例所需要的信息。 运用需求收集会议、QFD和其他需求工程 机制确定共利益者，定义问题的范围，说 明整体的操作目标，概述所有已知的功能 需求，描述系统将处理的信息（对象）。 要开始开发用例，应列出特定参与者执行 的功能或活动。这些可以从所需系统功能 的列表中获得，或通过与客户或最终用户 交流获得，或通过评估活动图获得。
SafeHome系统ACS-DCV功能的泳道图
图7-8 ACS-DCV功能的泳道图
面向流的建模
面向流的数据建模至今仍是最广泛使用的分析表 达法之一。尽管数据流图及相关的图和信息不是 UML的正式组成部分，但是它们可以补充UML图 并提供对系统需求和流的补充认识。 DFD采取了系统的输入-处理-输出观点。流入软 件的数据对象，经由处理元素转换，最后以结果 数据对象的形式流出软件。数据对象由带标记的 箭头表示，转换由圆圈（也称作泡泡）表示。 DFD使用分层的方式表示，即第一个数据流模型 从整体上表现系统，随后的数据流图改进环境图， 提供每个后续层增加的细节。
分析建模的方法
软件团队往往选择一种方法并排斥另一种 方法中的所有表示手段。问题不是哪一种 方法最好，而是怎么组合这些表示手段才 能够为共利益者提供最好的软件需求模型 和过渡到软件设计的最有效方法。 分析模型将生成如图7-3所示的每个建模 元素的派生类。然而，不同项目之间，每 个元素的特定内容可能因项目而异。软件 团队必须想办法保持模型的简单性。只有 那些为模型增加价值的建模元素才能使用。
面向对象的分析
面向对象的分析(OOA)，其目的是定义与 即将解决的问题相关的所有类(以及与其相 关的关系和行为)。为实现这一点，必须完 成如下一些工作：
1、在客户和软件工程师之间必须对基本的用户需求进 行交流。 2、必须确定类（即定义属性和方法）。 3、定义类的层次结构。 4、表现对象与对象的关系（对象连接）。 5、必须为对象行为建模。 6、上述1-5的工作步骤重复迭代直至模型完成。
域分析
分析模型通常在特定业务领域内的很多应 用中重复发生。如果用一种方式对这些模 式加以定义和分类，让软件工程师或分析 师识别并复用这些模式，将促进分析模型 的创建。更重要的是，应用可复用的设计 模式和可执行的软件构件的可能性将显著 增加。
域分析
软件域分析是识别、分析和详细说明来自 某个特定应用领域的公共需求，特别是那 些在该应用领域内被多个项目重复使用 的……“面向对象的域分析”是在某个特 定应用领域内，根据通用的对象、类、部 件和框架、识别、分析和详细说明公共的、 可复用的能力。 域分析的目标很简单，就是：查找或创建 那些分析类和（或）能够广泛应用的、共 有的功能和特点，这样就可以复用。
分析模型在系统级描述和软件设计的差距之间 建立桥梁。 重要的是要注意到在系统描述中给出分析模型 的某些元素，并且需求工程的工作实际上是作为 系统工程的一部分开始的。此外，分析模型的所 有元素都可以直接跟踪到设计模型。通常难以区 分这两个重要的建模活动之间的设计和分析工作， 有些设计总是作为分析的一部分进行，而有些分 析将在设计中进行。
面向对象的概念
属性——说明一个类的数值集合。 类——封装数据和过程的抽象，这些是说明某些 真实世界中的实体的内容和行为所必需的。即类 是一组相似对象的概括说明。 对象——某个特定类的实例。对象具有类的属性 和操作。 操作——也称为方法和服务，表现类的某个行为。 子类——超类的特化，子类可以从超类继承属性 和操作。 超类——也称作基类，是一组相关类的泛化。
SafeHome系统的初步用例图
图7-6 SafeHome系统的初步用例图
开发活动图
UML活动图通过提供特定场景内交互流的 图形化表示来补充用例。活动图使用圆角 矩形表示一个特定的系统功能，箭头表示 通过系统的流，判定菱形表示判定分支， 水平线意味着并行发生的活动。ACS-DCV 功能的活动图如图7-7所示。
分析模型
可以使用很多不同格式的图表为信息、功 能和行为需求建模。基于场景的建模从用 户的角度表现系统；面向流的建模在说明 数据对象如何通过处理函数进行转换方面 提供了指示；基于类的建模定义了对象、 属性和关系；行为建模描述了系统状态、 类和事件在这些类上的影响。一旦创建了 模型的雏形，就将不断改进，并分析评估 其清晰性、完整性和一致性。最终的分析 模型将由所有的共利益者确认。
基数和形态
数据模型必须能够表示在一个给定的关系 中对象出现的次数。 基数是关于一个（对象）的出现次数可以 与另一个（对象）的出现次数相关联的规 格说明。 对于关系的出现，如果没有明确的必要性 或关系是可选的，那么关系的形态是0；如 果关系必须出现一次，那么形态是1。
数据建模
数据建模工具为软件工程师提供表现数据 对象、数据对象的特点和数据对象的关系 的能力。主要用于大型数据库应用系统和 其他信息系统项目，数据建模工具以自动 化的方式创建全面的实体—关系图、数据 对象字典以及相关模型。
分析模型
必须评审分析建模工作产品的正确性、 完整性和一致性，必须反映所有共利益者 的要求并建立一个可以从中导出设计的基 础。
分析模型
在技术层面上，软件工程开始于一系列的 建模工作，最终生成待开发软件的需求规 格说明和全面的设计表示。分析模型实际 上是一组模型，是系统的第一个技术表示。
分析阶段的目标[DEM79]
数据对象
数据对象只封装数据——在数据对象内没 有对作用于数据的操作的引用。数据可以 表示为如图7-4所示的一张表，表头反映 了对象的属性。表体表示了数据对象的特 定实例。
数据对象的表格表示
图7-4 数据对象的表格表示
数据属性
数据属性定源自文库了数据对象的性质，可以具 有三种不同的特性之一。它们可以用来：
这些问题的答案导致创建一组次场景，次场景属 于原始用例的一部分，但是表现了可供选择的行 为。
SafeHome实例[15]
编写用例
在很多情况下，不需要创建使用场景的图 形化表示。但是图形化表示可以促进理解， 尤其是当场景比较复杂时。UML为用例提 供了图形化表现的能力。图7-6为 SafeHome系统的初步用例图。
分析模型的元素
图7-3 分析模型的元素
数据建模概念
分析建模通常开始于数据建模。软件工程 师或分析师需要定义在系统内处理的所有 数据对象、数据对象之间的关系以及其他 与这些关系相关的信息。
数据对象
数据对象是几乎任何必须被软件理解的复 合信息的表示。复合信息是指具有若干不 同的特征或属性的事物。 数据对象可能是外部实体、事物、发生或 事件、角色、组织单位、地点或结构。 “数据对象描述”包括了数据对象及其所 有属性。
SafeHome实例[12]
编写用例
随着和共利益者更多地交谈，需求收集团 队为每个标记的功能开发用例。通常，用 例首先用非正式的描述性风格编写。如果 需要更正式一些，可以使用类似前一章中 提出的某个结构化的形式重新编写同样的 用例。
SafeHome实例[13]
编写用例
描述性用例的一种变形是通过用户活动的 顺序序列表现交互，每个活动由声明性的 语句表示。
需求分析
在整个分析建模过程中，软件工程师的主 要关注点集中在“做什么”而不是“怎么 做”方面。包括：系统处理什么对象？系 统必须执行什么功能？系统显示什么行为？ 定义什么接口？有什么约束？
整体目标和原理
分析模型必须实现三个主要目标：
描述客户需要什么； 为软件设计奠定基础； 定义在软件完成后可以被确认的一组需求。