面向对象课程设计uml中建立需求模型.pptVIP

第4章 建立需求模型 目 录 4.1 需求分析和系统分析 4.2 基于用况的需求分析基本思路 4.3 系统边界与参与者 4.4 用况 4.5 用况图 4.6 需求模型的开发过程 另课件：《UML与Rational Rose建模简介》 另课件：《图书馆：第1章 建立需求模型》 4.1 需求分析和系统分析 需求分析(requirements analysis)是软件工程学中的经典术语之一，其确切含义应该是对用户需求进行分析，旨在产生一份明确、规范的需求定义。 然而，在20世纪90年代以前的各种分析方法（包括结构化分析和面向对象分析）中，真正属于需求分析的内容并不太多。 各种方法的主要内容是给出一种系统建模方法，包括一种表示法和相应的建模过程指导，告诉分析员如何建立一个能够满足用户需求的系统模型。 分析员大量的工作是对系统的应用领域进行调查研究并抽象地表示这个系统。 无论是结构化方法中的数据流图还是面向对象方法中的类图，都不是直接描述用户需求的，而是描述一个满足用户需求的系统应该由哪些成分来构成。 确切地讲，这些工作应该叫做系统分析(system analysis)，而不是严格意义上的需求分析。 但是人们在说到“分析”这个术语时却常常把它理解为“需求分析”的简称，这常常造成对某些问题的见解莫衷一是。 面向对象的系统分析主要特点是把问题域中的事物抽象为系统中的对象，最终建立一个用面向对象概念表达的系统模型。 抽象必须有一个目标，对分析而言，这个目标就是要满足用户需求。 因此，分析用户需求，建立对需求的准确认识，形成对需求的规范化描述，这是开展面向对象系统分析的基础。 需求分析和系统分析之间的区别和相互关系是——需求分析旨在建立系统的需求模型，通过用况图给出可视化表示；系统分析的主要工作是建立系统的基本模型，即类图，必要时可用其他几种图作为辅助模型。 需求分析是系统分析的基础，通常要在系统分析之前进行。 4.2 基于用况的需求分析基本思路 在进行一个系统的需求分析时，人们对这个待开发的系统的内部构成情况尚处于一无所知的状态。 分析员只知道用户要求开发一个系统，它能提供这样那样的功能。至于系统中包含哪些对象，这些对象的特征以及相互之间的关系，这一切都需要在对需求有了明确的认识之后才能确定。 此时的系统对开发者而言是个未知的空间，但是人们可以预测，这个系统在开发完成之后应该对外界发挥什么作用。 此时对这个系统的认识如同观察一座神秘的城堡，人们只能在其城墙之外看到每一座城门进进出出的是些什么东西。这道城墙就是系统与外界的分界线，即系统边界(system border)。 对一个信息系统而言，它对外界所起到的作用无非是通过它与外界的几个接口进行内外信息的交互。 系统对外提供的每一项功能都体现在通过某个接口所进行的信息交互中。 在系统边界之外，与系统进行信息交互的人或者其他事物称为参与者(actor)。这些参与者使用系统的任何一项功能，都是一个与系统进行交互的过程---参与者给系统输入某些信息，系统进行某些处理，向外输出某些信息，索取进一步的输入，然后继续进行处理和输出，直到这项功能的完成。 把每一类参与者对每一项系统功能的使用情况都用一个用况描述出来，就完整而详细地定义了系统的功能需求。 分析员进行这些工作，是从系统边界之外来观察和描述系统对外呈现的行为，这就是他们在需求分析阶段所能做的工作。 当他们能够进入系统内部去分析系统中应该设立哪些对象以及各类对象的特征和相互关系时，那就是系统分析了。 基于用况概念的需求分析的基本思路是：首先确定系统边界；进而找出在系统边界以外直接与系统进行交互的各类参与者；然后，针对所期望的系统应该对外提供的每一项功能定义一个用况，每一个用况是以参与者与系统进行对话的方式描述对一项系统功能的使用情况；对系统边界、参与者、用况等模型元素进行可视化表示，形成需求模型，即用况图。 4.3 系统边界与参与者 4.3.1 什么是系统边界 系统边界是指系统内部的所有成分与系统以外各种事物之间的分界线。 在这条分界线以内，是系统本身所包含的全部对象； 在系统边界以外，是与系统进行信息交换的各种事物，即人员、设备和外系统等各种参与者。如图所示。 这条分界线划在哪里，是由“系统成分”这一概念的外延所决定的。 为了确定系统边界，首先要澄清以下几个问题： （1）这里所说的系统是指被开发的计算机软硬件系统，而不是泛指问题域的全部事物所构成的现实系统。 问题域的某些事物（例如使用系统的人员）将被看成是位于系统边界之外并与系统进行交互的参与者。 （2）系统成分是指那些在OOA和OOD中定义并且在编程时加以实现的系统元素。 在面向对象的开发中，这些元素就是在OOA和OOD的类图中定义，并且在编程时实现的那些类。 某些与分析工