需求分析与系统设计4.ppt

需求分析与系统设计 第4章 需求规格说明 需求需要用图形和其他形式化模型来说明。为了完整地说明一个系统，有必要采用多种模型。UML提供了许多集成化建模技术来辅助系统分析员完成这项工作。规格说明的过程是迭代增量式的。对成功的建模来说使用CASE工具是最基本的。 需求规格说明得出三种模型：状态模型、行为模型和状态变化模型。每种模型都由相应的建模技术来支持。本章主要解释并用实例说明UML的主要建模技术。 虽然我们将从状态模型开始，然后才是行为模型和状态变化模型，但这并不反映建模的次序。许多模型都是并行开发并且相互作用的，对类模型和用例模型这两个主要的模型来说尤其如此。 第4章 需求规格说明 4.1需求规格说明的原则 4.2状态规格说明 4.3行为规格说明 4.4状态变化规格说明 4.1需求规格说明的原则 需求规格说明与在需求确定期间定义的客户需求进行严格建模有关，只有系统中那些期望的服务（服务陈述）需要考虑。约束陈述在规格说明阶段不再进一步开发，虽然在一个正常的迭代周期中，约束可以被修改。 需求规格说明用客户的叙述性需求作为输入、用构造规格说明模型作为输出。这些模型为系统的各个方面（视图）提供了更为形式化的定义。主要考虑两类客户需求：功能需求和数据需求。 4.1需求规格说明的原则 规格说明阶段产生的结果是一个扩展的（“细化的”）需求文档。这个新文档经常被称为规格说明文档（或用术语来说是规格说明）。原始文档的结构没有变化，但在定义客户需求的章节中的内容明显地被扩展了。最后，为了设计和实现，规格说明文档将取代需求文档 （实际上，扩展后的文档很可能仍然被称为需求文档）。 4.1需求规格说明的原则 规格说明模型可以分成三组： 1.状态模型。 2.行为模型。 3.状态变化模型。 状态模型细化了数据需求，行为模型提供了功能需求的详细规格说明，状态变化模型横跨了这两种需求。它们解释了功能怎样引起数据的变化。 4.1需求规格说明的原则 这些模型用可视化建模语言（在本书中为UML）的图的形式给出。一般来说，一张图可实现三种建模目的中的一种，即状态、行为或状态变化。一个明显的例外是类图，它表达了所有这三个方面的内容，即状态和对象的行为以及非直接地表达了对象状态的变化。 每一种图强调系统的一个特定的方面（视图）。这些图虽然强调了某些方面而隐藏另一些方法，但合到一起就让开发者和用户从各个角度看到所提出的方案。没有一种图能单独给出系统完整的定义，只有从图的交集中去理解所刻画的系统。 4.1需求规格说明的原则 就像对完成模型过程的解释一样，图的构造过程也不是从一个图到另一个图的序列化过程。所有的图都是并行开发的，而且详细的描述也是逐步迭代式地增加的。除非对开发者规定一个严格的开发过程，选择哪个模型作为主导将完全取决于分析者个人的爱好。有两个最重要的模型，即用例图和类图，它们一般应该并行构造，互相补充。 4.1需求规格说明的原则 每经历一次迭代，规格说明的深度和详细程度都会增加。模型对象中的许多高级属性是由文字而不是图形表示的。一些属性定义了模型对象的设计而不是分析，另外一些属性则特别为某些CASE工具而设。 4.2状态规格说明 状态规格说明提供系统的静态视图（因此，状态建模经常被称为静态建模）。这里的主要任务是定义应用领域的类、它们的属性及与其他类的关系。类的操作在一开始一般不予考虑，它们将从行为规格说明中导出。 4.2状态规格说明 在通常情况下，我们首先识别实体类，即定义应用领域的类和将在系统数据库中永久存在的类。这样的类常常被称为“业务对象”。作为系统事件的类（控制类）和表示GUI的类（视图或边界类）要等到系统的行为特征已经知道时才建立。 4.2状态规格说明 4.2.1为类建模 4.2.2为关联建模 4.2.3为聚合和组合关系建模 4.2.4为泛化关系建模 4.2.5为对象建模 4.2.1为类建模 类模型是面向对象系统开发的基础。类建立了一个基础，在这个基础上，系统的状态和行为才是可观察的。但是，类很难找到而且类的属性也不是很明显。即使对同一个应用领域，任何两个分析员所得到的类以及它们的属性的集合都可能是不相同的。既使类模型不同，但最后的结果和用户满意度可以同样好（或同样差）。 4.2.1为类建模 为类建模并不是一个确定的过程。不存在如何找到