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

《需求分析与系统设计四.ppt》由会员分享，可在线阅读，更多相关《需求分析与系统设计四.ppt（220页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、需求分析与系统设计需求分析与系统设计 第第4章章 需求规格说明需求规格说明 需求需要用图形和其他形式化模型来说明。为了完整地说明一个系统，有必要采用多种模型。UML提供了许多集成化建模技术来辅助系统分析员完成这项工作。规格说明的过程是迭代增量式的。对成功的建模来说使用CASE工具是最基本的。需求规格说明得出三种模型：状态模型、行为模型和状态变化模型。每种模型都由相应的建模技术来支持。本章主要解释并用实例说明UML的主要建模技术。虽然我们将从状态模型开始，然后才是行为模型和状态变化模型，但这并不反映建模的次序。许多模型都是并行开发并且相互作用的，对类模型和用例模型这两个主要的模型来说尤其如此。第

2、第4章章 需求规格说明需求规格说明 l4.1需求规格说明的原则 l4.2状态规格说明 l4.3行为规格说明 l4.4状态变化规格说明 4.1需求规格说明的原则 需求规格说明与在需求确定期间定义的客户需求进行严格建模有关，只有系统中那些期望的服务（服务陈述）需要考虑。约束陈述在规格说明阶段不再进一步开发，虽然在一个正常的迭代周期中，约束可以被修改。需求规格说明用客户的叙述性需求作为输入、用构造规格说明模型作为输出。这些模型为系统的各个方面（视图）提供了更为形式化的定义。主要考虑两类客户需求：功能需求和数据需求。4.1需求规格说明的原则 规格说明阶段产生的结果是一个扩展的（“细化的”）需求文档。这

3、个新文档经常被称为规格说明文档（或用术语来说是规格说明）。原始文档的结构没有变化，但在定义客户需求的章节中的内容明显地被扩展了。最后，为了设计和实现，规格说明文档将取代需求文档 （实际上，扩展后的文档很可能仍然被称为需求文档）。4.1需求规格说明的原则 规格说明模型可以分成三组：l1.状态模型。l2.行为模型。l3.状态变化模型。状态模型细化了数据需求，行为模型提供了功能需求的详细规格说明，状态变化模型横跨了这两种需求。它们解释了功能怎样引起数据的变化。4.1需求规格说明的原则 这些模型用可视化建模语言（在本书中为UML）的图的形式给出。一般来说，一张图可实现三种建模目的中的一种，即状态、行为

4、或状态变化。一个明显的例外是类图，它表达了所有这三个方面的内容，即状态和对象的行为以及非直接地表达了对象状态的变化。每一种图强调系统的一个特定的方面（视图）。这些图虽然强调了某些方面而隐藏另一些方法，但合到一起就让开发者和用户从各个角度看到所提出的方案。没有一种图能单独给出系统完整的定义，只有从图的交集中去理解所刻画的系统。4.1需求规格说明的原则 就像对完成模型过程的解释一样，图的构造过程也不是从一个图到另一个图的序列化过程。所有的图都是并行开发的，而且详细的描述也是逐步迭代式地增加的。除非对开发者规定一个严格的开发过程，选择哪个模型作为主导将完全取决于分析者个人的爱好。有两个最重要的模型，

5、即用例图和类图，它们一般应该并行构造，互相补充。4.1需求规格说明的原则 每经历一次迭代，规格说明的深度和详细程度都会增加。模型对象中的许多高级属性是由文字而不是图形表示的。一些属性定义了模型对象的设计而不是分析，另外一些属性则特别为某些CASE工具而设。4.2状态规格说明 状态规格说明提供系统的静态视图（因此，状态建模经常被称为静态建模）。这里的主要任务是定义应用领域的类、它们的属性及与其他类的关系。类的操作在一开始一般不予考虑，它们将从行为规格说明中导出。4.2状态规格说明 在通常情况下，我们首先识别实体类，即定义应用领域的类和将在系统数据库中永久存在的类。这样的类常常被称为“业务对象”。

6、作为系统事件的类（控制类）和表示GUI的类（视图或边界类）要等到系统的行为特征已经知道时才建立。4.2状态规格说明 l4.2.1为类建模 l4.2.2为关联建模 l4.2.3为聚合和组合关系建模 l4.2.4为泛化关系建模 l4.2.5为对象建模 4.2.1为类建模 类模型是面向对象系统开发的基础。类建立了一个基础，在这个基础上，系统的状态和行为才是可观察的。但是，类很难找到而且类的属性也不是很明显。即使对同一个应用领域，任何两个分析员所得到的类以及它们的属性的集合都可能是不相同的。既使类模型不同，但最后的结果和用户满意度可以同样好（或同样差）。4.2.1为类建模 为类建模并不是一个确定的过程

7、。不存在如何找到和定义好的类的秘诀。这个过程是高度选代增量式的。以下分析对类的成功设计是至关重要的：l1.为类建模的知识。l2.对应用领域的理解。l3.相似的和成功的设计经验。l4.超前思维和预测结果的能力。l5.精化模型以消除不完美的愿望等。4.2.1为类建模l4.2.1.1发现类 l4.2.1.2说明类 4.2.1.1发现类 对同一个应用，任何两个分析员都将可能得到不同的类模型，任何两个分析员在发现类的过程中都可能采用不同的思考过程。当前的文献中存在许多所谓的类发现方法，分析员在一开始遵循其中的一种方法，而接下去的迭代几乎都要涉及非传统的和可以说是任意的机制。4.2.1.1发现类 Bahr

8、ami（1999）仔细研究了四种最流行的识别类的方法：l1.名词短语方法。l2.公共类模式方法。l3.用例导出方法。l4.CRC（类一职责一协作）方法。Bahrami把每种方法归因于已经发表的论文。但是，按我们的观点，只有最后一种方法具有无可置疑的原创性。下面，我们总结这些方法，然后给出采用混合方法的例子。4.2.1.1发现类l4.2.1.1.1名词短语方法 l4.2.1.1.2公共类模式方法 l4.2.1.1.3用例驱动方法 l4.2.1.1.4 CRC方法 l4.2.1.1.5混合方法 l4.2.1.1.6用于发现类的指南 l4.2.1.1.7类发现的例子 4.2.1.1.1名词短语方法

9、名词短语方法要求分析员阅读需求文档中的语句，从中寻找名词短语。每一个名词短语被认为是一个候选类，然后，这些候选类被分成三组：l1.相关类。l2.模糊类。l3.无关类。4.2.1.1.1名词短语方法 无关类就是那些问题领域之外的类，我们无法陈述它们的目的。有经验的实践者在他们的候选类初始表中很可能不用包含无关类，这样，识别和消除无关类这个正式的步骤就没有必要了。相关类是那些明显属于问题领域的类，表示这些类的名字的名词经常出现在需求文档中。另外，我们能够从对应用领域的一般性知识中，从对相似的系统、教科书、文件以及专门软件包的研究中，确认这些类的显著性和目的。4.2.1.1.1名词短语方法 模糊类是

10、那些我们不能肯定地和无二义性地分类为相关类的类。它们是一个大的问题，我们需要对它们进行进一步的分析。要么将它们划归为相关类，要么将他们划归为无关类。这些类最后的分组结果将成为好的类模型和坏的类模型的区别所在。名词短语方法假设需求文档是完全的和正确的。事实上，这一点很难达到。甚至于即使真的是这样，在大量的文本中进行单调无味的搜索也不一定能产生完整的和精确的结果。4.2.1.1.2公共类模式方法 公共类模式方法从通用的对象分类理论中导出候选类。分类理论是研究将对象世界划分为有用的分组，以便更好地进行推理的理论的一部分。4.2.1.1.2公共类模式方法 Bahrami（1999）列出了下列一些用于发

11、现候选类的分组（模式）：l概念类。概念是大范围的人员社团共享和公认的一个表示。没有概念，人们就不能有效地交流，或者无法交流到任何满意的程度。例如，Reservation在飞机定座系统中就是一个概念类。l事件类。事件相对于我们的时间进度来说是不占任何时间的事情。例如，Arrival在飞机定座系统中是一个事件类。l组织类。组织是任何形式的、有目的性的团体，或者是事物的集合。例如，TravelAgency在飞机定座系统中是一个类。l人员类。“人员”在这里理解为系统中由人担任的角色，而不是实际的人。例如，Passenger在飞机定座系统中是一个类。l地点类。地点是与信息系统相关的物理位置。Trave1

12、Office就是飞机定座系统中这样的一个类。4.2.1.1.2公共类模式方法 Rumbaugh et al（1999）提出不同的划分方式：l物理类（如Airplane）。l业务类（如Reservation）。l逻辑类（如 FlightTimetable）。l应用类（如ReservationTransaction）。l计算机类（如Index）。l行为类（如ReservationCancellation）。4.2.1.1.2公共类模式方法 公共类模式方法为识别类提供了有用的指南，但它并不提供系统化的过程，使我们依照它就可以发现可靠和完整的类的集合。这个方法可以使我们很成功地确定类的初始集，或者用于

13、验证某些类（由别的方法导出的）是否应该存在或者有没有必要存在。当然，公共类模式方法与特定用户需求的联系太松散，不能提供完整的方案。4.2.1.1.2公共类模式方法 与公共类模式方法相关的一个危险与误解类的名字有关。例如，Arrival是什么意思？它是指到达跑道（着陆时间）、到达航站楼（到港时间）、到达行李提取处（行李放行时间）等等？同样，在北美印地安领地，Reservation这个字具有与我们在这里所理解的完全不相关的意思。4.2.1.1.3用例驱动方法 如果没有被特别地建议，UML（准确地说是UML统一过程）强调用例驱动方法。用例的图形式模型成为叙述性描述和序列形式或者个体用例的协作图（见2

14、.2节和本章后面部分）的补充形式。这些附加的描述和图示定义了每个用例出现所需的步骤（和对象）。从这些信息中，我们能够通过泛化来发现候选类。4.2.1.1.3用例驱动方法 用例驱动方法具有自底向上的特点，一旦已知了用例并且至少在序列图中部分地定义了系统的交互视图，则这些图中所使用的对象就导致了类的发现。实际上，这个方法与名词短语方法相似，其共同的基础在于用例说明了需求这个事实。两者都是通过研究需求文档中的陈述来发现候选类的，而这些陈述是叙述性的还是图形式的则是次要的。总之，在生命周期的这个阶段，大多数用例都只在文本中描述，而不带任何交互图。4.2.1.1.3用例驱动方法 用例驱动方法具有与名词短

15、语方法相同的缺陷。作为一种自底向上的方法，它本身的准确性依赖于用例模型的完整性和正确性。在迭代增量式软件开发中，它甚至会导致意想不到的不平衡。这里，用例模型不得不在类模型建立之前完成。对所有的方法和目的而言，这种形式产生了功能驱动的方法（OO主张者喜欢称它为问题驱动）。4.2.1.1.4 CRC方法 CRC方法不仅仅是一种类发现技术，它还是一种用来进行对象的解释、理解和教学的具有吸引力的方式。CRC方法涉及头脑风暴的内容，它通过使用一种特殊制作的卡片而变得容易进行。这种卡片包含三个分栏：类名书写在最上面的分栏中、类职责列在左边的分栏中而合作者列在右边的分栏中。职责是当前类为了满足其他类所准备执

16、行的服务（操作），许多要实现的职责需要其他类的合作，这些类被列为合作者。4.2.1.1.4 CRC方法 CRC方法是一个模拟开发者“处理这些卡片”的过程，开发者在执行一个处理实例（即一个用例实例）的同时将类名和赋予的职责和合作者填入卡片。每当需要的服务没有被存在的类所覆盖时就创建一个新类，并赋予适当的职责和合作者。如果一个类“太忙”了，它就要被分为几个较小的类。4.2.1.1.4 CRC方法 与其他方法不同的是，CRC方法从对象之间为了完成一个处理任务而在发生的消息传递中识别类。其重点在于系统智能的统一分布，而且一些类是通过技术上的需要而导出的，而不是作为“业务对象”而发现的。在这个意义上说，

17、CRC可能更适合对用其他方法发现的类进行验证。CRC在类特性（被类职责和合作者所隐含）的确定上也很有用。4.2.1.1.5混合方法 在实践中，类发现过程在不同的时刻可能采用不同的方法。经常是涉及到所有上述四种方法。分析者全面的知识、经验和直觉也起作用。这个过程既不是由顶向下的，也不是自底向上的，而是从中间出发的。我们称这样的类发现过程为混合方法。4.2.1.1.5混合方法 下面是一个可能的场景。用一般性知识和分析者的经验来发现类的初始集合。公共类模式进一步提供附加的指导，然后又通过对问题领域的高层描述，采用名词短语方法又增加了其他的类。如果有了用例图，用例驱动方法又能被用来加入新的类，并且验证

18、已有的类。最后，CRC方法对到现在发现的所有类进行评判和推理。4.2.1.1.6用于发现类的指南 下面列出分析员在选择候选类时应该遵循的一个不太完美的指南或经验。记住，我们这里所涉及的仅仅是实体类：l1.每个类必须在系统中有清晰的目的陈述。l2.每个类都是一组对象的框架描述。孤类，可以想像它是单个对象，它在“业务对象”中是不太可能的。l3.每个类（即实体类）必须拥有一组属性，通过确定标识属性（主码）来帮助我们推断类的序数（即类所希望的数据库中的对象数）是一个好主意。然而要记住，类不一定要有用户定义的主码。对象标识符（OID）可以标识类的对象。l4.每个类应该有区别于其他类的属性。一个概念是类还

19、是属性依赖于它的应用领域。l5.每个类拥有一组操作。当然，在当前阶段，我们并不涉及操作的标识。类接口中的操作（类在系统中提供的服务）隐含在目的陈述中（第1点）。4.2.1.1.7类发现的例子 l例4.1（大学注册）l例4.2（音像商店）l例4.3（关系管理）例4.1（大学注册）考虑下述对大学注册系统的需求并识别候选类：1.每个大学学位都有若干必修课和若干选修课。2.每门课都处于一个给定的级别并且有一个学分值。3.同一门课程可以是若干学位的一个部分。4.每种学位都要给定完成学位所要求的总的最少学分值（例如，BS（计算和信息系统）包括必修课在内要求68学分）。5.学生可以组合所提供的课程形成他们的

20、学习程序，一方面适合他们个人需要，另一方面完成了这些课程他们就能得到他们所注册的学位。例4.1（大学注册）我们要通过分析这段需求来发现候选类。在第一段陈述中，相关的类为Degree和Course。这两个类符合了上述指南中的五条，我们还不肯定类Course是否或者如何能特例化为类CompulsoryCourse和ElectiveCourse。有一点很清楚，如一门课程针对一种学位来说要么是必修的要么是选修的。可以通过关联或者通过类的属性来区别必修或选修。因此，CompulsoryCourse和ElectiveCourse被认为是模糊类。例4.1（大学注册）第2段陈述只识别类Course的属性，即c

21、ourse_level和credit_point_value。第3段陈述刻画类Course和Degree之间的一个关联。第4段陈述引入min_total_credit_points作为类Degree的一个属性。例4.1（大学注册）最后一段陈述让我们发现了三个类：Student、CourseOffering和StudyProgram，前两个不容置疑地是相关类，但StudyProgram可以转化为Student和CourseOffering之间的一个关联。由于这个原因，StudyProgrm被归为模糊类。表4-1反映了上述的讨论。例4.1（大学注册）表表4-1候选类（大学注册）候选类（大学注册）相

22、关类模糊类CourseDegreeStudentCourseOffering CompulSoryCourseElectiveCourseStudyProgram 例4.2（音像商店）考虑下述对音像商店系统的需求，识别候选类：1.音像商店在货架上存放着题材广泛的当前流行的电影库。某个特定的电影可以存放在录像带或是光碟上。2.录像带要么是Beta格式要么是VHS格式。光碟为DVD格式。3.每个电影都有特定的租用期（用天表示），并带有在租用期内的租金。4.音像商店必须能够立即回答关于某个电影的库存和有多少供租用的带子或光碟（必须知道并记录每个带子或光碟的当前情况）。例4.2（音像商店）第1段陈述出

23、现了一些名词，但其中只有部分名词可以归为候选类。音像商店不是候选类，因为整个系统就是关于它的（在数据库中将只会有一个该类的对象所谓的孤类）。同样，货架和库作为类也太通用，至少在这个阶段是这样。相关类看来只有MovieTitle、VideoTape和VideoDisk。例4.2（音像商店）第2段陈述引入了关于录像带和光碟的其他规格说明，我们可以提出三个新的类：BetaTape，VHSTape和 DVDDISk。但是，由于只有一种光碟，在最终的模型中可能并不需要同时保留VideoDisk和 DVDDisk，保留哪一种将根据作用到录像带和光碟的规格说明的最终层次而定。注意，我们还不能肯定BetaTa

24、pe和VHSTape是否具有可以区分的属性（除了一个是Beta格式而另一个为VHS格式之外）。例4.2（音像商店）第3段陈述说明每一个电影片名关联一个租用条件。但是，还不清楚什么被认为是“电影”是电影片名还是电影介质（录像带或光碟）？我们还需要向客户澄清这个需求。同时，我们也许需要声明Renta1Conditions作为一个模糊类，而不是在电影片名或电影介质类中存储关于租用期限和租用费用的信息。例4.2（音像商店）最后一段陈述给我们肯定了BetaTape、VHSTape和DVDDisk是相关类。我们需要存储关于每个带子和光碟的当前条件的信息。但是，像video_condition或number

25、_currently_ available这样的属性可以一般性地在一个高层抽象类（可以称它为VideoMedium）中声明，并已由具体子类（如 VHSTape）继承。这些讨论反映在表 4-2中。例4.2（音像商店）表表4-2候选类（候选类（音像商店）相关类模糊类MovieTitleVideoMediumVideoTapeVideoDisk（或DVDDisk）BetaTapeVHSTape RentalConditions 例4.3（关系管理）考虑下述对关系管理系统的需求，并识别候选类：1.系统支持与当前和未来客户“保持联系”的功能，以便能够响应他们的需要并争取我们产品的新的合同。2.系统存储组

26、织以及组织中联系人的名字、电话号码、邮寄和传递地址。3.系统让我们的员工能够安排需要进行的与相关联系人有关的任务和事件。员工为其他员工或为他们自己安排任务和事件。4.任务是为了实现某个结果而进行的一组事件。结果可以是将一个未来客户转变为当前客户、组织一次产品发送或解决一个客户问题。典型的事件类型为：打电话、访问、发送传真、安排培训等。例4.3（关系管理）第1段陈述包含客户、关系和产品的表示。一般性的知识和经验告诉我们这些都是典型的类。但是，关系和产品不是关系管理系统范围之内的概念，因而应该抛弃。Customer是一个相关类，但是考虑到不是所有的联系人都是当前的客户，我们偏向于称它为Contac

27、t。当前和未来客户的区别也许表明或干脆并不表明要引入类：CurrentCustomer和ProspectiveCustomer。由于我们现在还不能肯定，我们声明它们为模糊类。例4.3（关系管理）第2段陈述阐明了上述讨论的新的观点。需要区别联系的组织和联系的人员。Customer看来不是一个好的类名字。总之，Customer只隐含了当前客户，而它又可以同时表示组织和联系人。一个新的提议是命名类：Organization、Contact（意思是联系人），CurrentOrg（即作为当前客户的组织）和ProspectiveOrg（即作为未来客户的组织）。例4.3（关系管理）在第2段陈述中，提到了类的

28、一些属性。但是，邮寄和传递地址是组合属性，它们同时适用于类Organization和 Contact。所以，PostalAddress和 CourierAddress是正当的模糊类。第3段陈述引入三个相关类：Employee、Task和Event。这段话解释了安排的活动。最后一段话进一步澄清了这个意思以及类之间的关系，但它没有隐含任何新的类。例4.3（关系管理）表表4-3候选类（关系管理）候选类（关系管理）相关类模糊类OrganizationContactEmployeeTaskEvent CurrentOrgProspectiveOrgPostalAddressCourierAddress

29、4.2.1.2说明类 一旦知道了一组候选类，就将它们插入类图中的适当地方进行进一步的说明并定义类的属性。有些属性可以加入并显示在类图中表示该类的图标上，而类规格说明中的其他属性则只有文本表示形式。为了加入或修改这些信息，CASE工具采用带列表的页面或采用与之类似的技术的对话框来提供方便的编辑能力。就像在本章开始解释的那样，我们在一个特定的抽象级别上说明类。4.2.1.2说明类 l4.2.1.2.1为类命名 l4.2.1.2.2发现和说明类的属性 l4.2.1.2.3类规格说明示例 4.2.1.2.1为类命名 每个类都要起个名字。在有些CASE工具中，可能给类赋一个可能与名字不同的代码。这个代码

30、遵守目标程序语言或数据库系统所要求的命名约定。这个代码不是名宇，但可以用来从设计模型到软件代码的生成。4.2.1.2.1为类命名 我们已经为类名采用了一个特定的约定，即类名以大写字母开头，对组合名字，每个字的第一个字母为大写字母（而不是用下横线或连字符分开）。这只是一种推荐的约定，但有理由让开发者遵循。（建议给每个类加上一个单字母字头以标识该类所属的软件层次）。4.2.1.2.1为类命名 只要可能，类的名字就应该是一个单数名词（如，Course）或一个形容词加一个单数名词（如 CompulsoryCourse）。很清楚，类本来就是一个多个对象的模板，使用复数名词并不增加任何新的信息。有时，单数

31、名词并没有表达类的真正内涵，在这种情况下，用复数名词也是可以的。4.2.1.2.1为类命名 类名应该是有意义的，它应该刻画类的真实本质。它应该从用户的词汇中（而不是从开发者的术语中）导出。最好使用稍微长一点的名字，而且不要让它太隐晦。但是我们相信一个多于30个字母的名宇肯定太麻烦了（并且即使CASE工具可以用这种名字而不是用代码的话，一些程序设计环境也不允许）。除了类名和代码之外，还可以有更长一些的描述性名字。4.2.1.2.2发现和说明类的属性 表示类的图标包含三个部分（类名、属性、操作。对类属性的说明属于状态说明的范围，它将在这里讨论。属性是在发现类的同时被发现的。属性识别是确定类的一个副

32、产品，这并不是说属性发现是一个直接的活动，恰恰相反，它是一个需要的并且高度迭代的过程。4.2.1.2.2发现和说明类的属性 在这个最初的规格说明模型中，我们仅仅定义对理解该类的对象能够处于的状态来说是重要的那些属性。其他属性可以暂时忽略（但分析员必须保证忽略信息的存在性不能因为没有记录下来而丢失）。不可能所有的类属性都在需求文档中提到，但重要的是，不要引入需求中没有隐含的属性。更多的属性可以在后续的选代中加入。我们建议的对属性名字约定是用小写字母，复合名字中的单词用下划线连接。4.2.1.2.3类规格说明示例 l例4.4（大学注册）l例4.5（音像商店）l例4.6（关系管理）l例4.7（电话销

33、售）例4.4（大学注册）参照例4.1，考虑下述来自需求文档的附加需求：1.学生对课程的选择受时间表的冲突以及注册当前提供的课程的学生人数限制的约束。2.学生提出的学习计划要输入到在线注册系统中，系统要检查学习程序的一致性并且报告其中存在的任何问题。问题需要在学术指导的帮助下解决，最终的学习程序必须经过系领导代理人的批准，并且要通报给主管注册的人。例4.4（大学注册）第1段陈述提到时间表冲突，但我们不敢肯定如何为它建模。可能我们在这里只是在谈论一个用例，它从程序上确定了时间表的冲突。同一段陈述的第2部分可以通过在类CourseOffering中增加属性enrolment_quota来建模。Cou

34、rseOffering应该有属性year和semester，这一点现在就很清楚了。例4.4（大学注册）第2段陈述强化了对类StudyProgram的需要，我们可以看到StudyProgram组合了当前提供的许多课程。因此，StudyProgram也应该有属性year和semester。对模糊类CompulsoryCourse和 ElectiveCourse更深入的分析导致一个观测结果，就是一门课程是必修还是选修与学位相关，同一门课程相对于某个学位是必修的，而相对于另一个学位就是选修的，还可能对其他学位是不允许的。如果这样的话，根据它们自己的特性，CompulsoryCourse和 Electi

35、veCourse就不是类。例4.4（大学注册）图4-1是符合到目前为止的讨论结果的一个类模型。另外，还用了符号（构造型）和分别表示主码和候选码（8.4.1.2节）。这是所涉及的类的对象的惟一标识。对属性的数据类型也进行了说明。类 StudyProgram和CourseOffering没有用于标识的属性，它们将在发现类之间的关联时增加进去。例4.4（大学注册）例4.5（音像商店）参照例4.2，假设现在已经弄清了关于租用条件的需求3。增加如下需求：1.租金根据录像带的介质：录像带或光碟的不同而不同（但对两种录像带，Beta和VHS，是相同的）。2.虽然目前DVD光碟是目前店中唯一的一种录像光碟，用

36、户希望系统将来能容易扩展为包括其他光碟格式。3.音像商店的雇员想要记住最流行的电影的代码，他们经常用电影代码来标识电影，而不是用电影片名。这是一个非常有用的惯例，因为同一个电影片名可能由于不同的导演而有不同的版本。例4.5（音像商店）第1段陈述解释了相同电影的 VideoTape和 VideoDisk有不同的租用条件。因此，让RentalConditions作为独立的类就有意义了（与VideoTape和VideoDisk相关联）。第2段陈述隐含了需要VideoDisk类和 DVDDisk类同时存在，以VideoMedium为根的泛化层次就变得相当明显了，但我们把关于泛化关系的讨论留到4.2.4

37、节。第3段陈述在类MovieTitle中增加了属性movie_code（作为码属性）和 director，其他属性已在例4.2中讨论了。例4.5（音像商店）图4-2展示了根据例4.2和例4.5中的讨论得出的关于音像商店的类模型。VideoMedium.number_currently_available是类范围属性（静态的），MovieTitle.is_ in_stock是导出属性，即它可以通过查找当前的VideoMedium.number_currently_ available的值而计算出来。例4.5（音像商店）例4.6（关系管理）参照例4.3并考虑如下新增需求：1.客户是指当前客户，如果

38、存在一个与该客户的关于提供某种产品和服务的合同的话。合同的管理不在本系统范围之内。2.系统要根据邮寄和传送地址生成关于客户关系的各种报表（如通过邮政编码找到客户）。3.记录任务建的日期和时间。期望的任务完成的“钱数”也要存储下来。4.对雇员要进行的事件要用类似于日历表的页面显示在雇员的屏幕上（每天一页），每个事件的优先级（低、中、高）要能在屏幕上区分。5.不是所有的事件都带有完成时间有些是无期限的（可以在它被安排那天中的任意时间内完成）。6.事件的创建时间不能改变，但完成日期和时间可以改变。7.当事件完成了，完成日期和时间要记录下来。8.系统还要存储创建任务和事件的雇员的标识符、被安排完成事件

39、的雇员的标识符以及完成事件的雇员的标识符。例4.6（关系管理）对第1段陈述的分析结果告诉我们，当前客户是从Organization和Contract之间的关联中得到的。这个关联是动态的，因此，类CurrentOrg和ProspectiveOrg没有必要。而且，系统并不涉及合同管理，不负责维护Contract类。建立这个方案的最好方式是引出属性Organization.is_current供关系管理子系统在必要的时候进行修改。例4.6（关系管理）第2段陈述提供了有两个地址类PostalAddress和CourierAddress的原因。其余的陈述提供关于类属性内容的其他信息，还有一些关于关联关系

40、和完整性约束的提示（以后讨论）。关系管理的类规格说明如图4-3所示。还没有对关系建模，因此，如联系任务和事件的第8段陈述在该模型中没有反映出来。关系管理 例4.7（电话销售）考虑如下新增需求：1.一次活动有一个题目一般在提到该活动时使用。活动还有一个惟一编码作为内部索引，每次活动都在一个固定的时间段内进行，当活动结束时进行抽奖，并且报告获奖者。2.一次活动中的票号是惟一的。一次活动中票的总数、到目前为止卖出票的数量和每张票的当前状态（如未卖出、被预定、交了钱、抽奖赢家）是已知的。3.为了确定协会电话销售人员的效能，记录打电话的持续时间和成功的电话的结果（即产生了被预定的票）。4.维护关于支持者

41、的扩展信息。除了正常联系的详细信息外（地址、电话号码等），还包括像支持者第一次和最近一次参加活动的日期以及他们参加活动的次数等这种历史信息。任何已经知道的支持者的优先权和限制（如不接电话的时间或者通常用来购买票的信用卡）也要保留。例4.7（电话销售）5.电话销售的呼叫过程要进行优化排序，没有回答或用应答机回答的电话以后需要安排再试。当试图再一次呼叫时换一个时间很重要。6.我们可以一次又一次地打电话，直到达到某个限度，这个限度对不同的打电话的类型可以不一样，例如，正常的“恳求”式电话与提醒一个突出的支持者的电话可以有不同的限度。7.打电话可能的结果要由电话销售人员进行分类以辅助数据录入，典型的结

42、果是：成功（即票被预定）、不成功、以后再打电话、没有回答、忙、应答机、传真机、错号、联系不上。例4.7（电话销售）从第1段陈述中，我们可以导出类Campaign的一些属性。Campaign包含compaign_code（主码）、campaign_title、date_start 和date_closed。陈述1的最后一句话涉及活动的奖品。更深入的分析使我们相信，Prize就它自己来说是一个类，它要被抽出来，它有赢家，而且必定有其他还没有明确声明的属性，如描述、奖金额度以及在其他活动奖金中的一个排序。例4.7（电话销售）我们在类模型中增加 Prize以及它的属性 prize_discr、priz

43、e_value和prize_ranking，我们发现在一次活动中抽奖日期对所有的奖项来说是一样的。我们在类 Campaign中增加属性 date_drawn。获奖者也是一个支持者。我们以后将在 Prize和 Campaign的关联中表示这个事实。例4.7（电话销售）陈述2说每张票有一个编号，但编号对所有的票来说不是惟一的（它只在同一次活动中唯一）。我们增加属性 ticket_number，但我们不能让它作为CampaiqnTicket中的主码。CampaignTicket中的两个另外的属性是ticket_value和ticket_status。票的总数和卖出票的总数是Campaign的属性mu

44、m_tickets和num_tickets_sold）。例4.7（电话销售）陈述3提出了一些具有挑战性的问题。我们需要什么数据结构来计算电话销售人员的效能？首先，我们需要解决一些度量单位，效能可以通过它们来表示。一种可能是我们计算平均每小时打电话的次数和每小时成功的电话次数，然后用成功次数除以总次数来计算效能指示器。在类Telemarketer中增加属性average_per_hour和success_per_hour。例4.7（电话销售）为了计算电话销售人员的效能指示器，我们存储每次电话的持续时间，这个信息的存放地点是类CallOutcome。增加属性start_time和end_time到

45、这个类。假设每次电话的结果将用一个关联链接到一个电话销售人员。例4.7（电话销售）陈述4产生包括在类Supporter中的属性。这些属性是supporter_id（主码）。supporter_ name、phone_number、mailing_address、date_first、date_last、campaign_count、preferred_hours、credit_card_ttributes。其中有些属性（mailing_address、preferred_hours）非常复杂，以至于在以后的开发过程中它们将被转换成另外的类。我们目前仍把它们当作属性来存储。例4.7（电话销售）陈

46、述5涉及类CallScheduled，我们加进属性phone_number、priority和attempt_number。我们还不敢肯定如何支持在一天的不同时刻进行连续的呼叫的需求。这明显是调度算法的职责，但是数据结构的支持是需要的。幸运的是，下一个语句提供了关于这个问题的一些线索。例4.7（电话销售）陈述6产生新类CallType。这个类包含属性type_descr、call_attempt_limit和alternate_ hours。最后一项为复杂数据结构，就像Supporter中的preferred_hours一样，它将最终以一个独立类的身份结束。例4.7（电话销售）最后一段陈述对电

47、话结果进行了分类。这直接说明了需要类OutcomeType。可能的结果类型存储在属性outcome_type_descr中。不清楚什么其他属性还包含在OutcomeType中，但是我们相信它们将在详细的需求研究过程中出现。一个这样的属性可以是follow_up_action来保存每个结果类型的下一个典型步骤的信息。图4-4为总结上述讨论的一个类模型。在业务类模型（图3-5）中已经建立的关联仍然保留下来，没有增加新的关联。例4.7（电话销售）4.2.2为关联建模 关联连接系统中的对象。它们辅助对象的合作。没有关联，对象在运行时就只能当共享同样的属性或已知其他对象的对象标识值（用其他方式，如作为全

48、局变量）时才相关起来。关联在模型中，特别在永久“业务对象”模型中。是最基本的关系。关联支持用例的执行，因此可以说它们将状态和行为规格说明绑在一起。4.2.2为关联建模l4.2.2.1发现关联 l4.2.2.2说明关联 l4.2.2.3关联规格说明的示例 4.2.2.1发现关联 找到主要关联实际上是发现类的过程的一个副产品。当定义类时，分析员决定类的属性，某些这样的属性就成为与其他类的关联。属性可以有原始数据类型，或者它们以其他类作为类，因此建立与其他类的关系。在本质上，任何一个带非原始数据类型的属性应该被建模为与一个类的关联（或聚合），来表示这个数据类型。4.2.2.1发现关联 用例的“空弹演

49、习”过程可以发现其余的关联。类之间的合作途径、用例执行的必要性都可以确定下来。关联一般应该支持这些合作途径。每个三元关联都应该用一个二元关联的回路来代替。三元关联有引入语义误解的危险。4.2.2.1发现关联 偶尔，不一定非要一个关联的回路（封闭的）来完全表达其基本的语义。也就是说，这个回路中至少有一个关联是可以被导出的。这样的一个关联在语义的意义上是冗余的，应该被消除（好的语义模型应该是不冗余的）。然而多个导出关联包含在设计模型中（例如为了效率的原因）是可能的，并且实际上是很可能的。4.2.2.2说明关联 关联的规格说明涉及：l1.命名关联。l2.命名关联的角色。l3.确定关联的多重性。4.2

50、.2.2说明关联 命名规则应该遵循属性名命名的常规，用小写字母，用下横线进行字与字的分隔。如果任意两个类之间都只有一个关联连接，这些类之间的关联名和关联角色名的说明就是可有可无的。CASE工具通过系统提供的标识符名在内部区分每个关联。4.2.2.2说明关联 角色名可以用来解释更复杂的关联，特别是自身关联（联系同一个类的对象的递归关联）。如果有角色名的话，角色名应该按照这样的理解来选择，即在设计模型中，它们将成为关联相反端的类的一个属性。多重性在关联的两端（角色）都应该加以说明。如果目前还不清楚的话，在这个阶段多重性的上下界可以省略。4.2.2.3关联规格说明的示例 例4.8（关系管理）参照例4