第5章面向对象分析 现实世界是由各种对象组成的，如建筑物、车、动物、植物等，所以面向对象的分析方法与传统的结构化分析方法相比，更符合人类对问题的思考习惯。传统方法是面向过程的，把数据和过程作为相互独立的部分，忽略了数据和操作之间的内在联系； 面向对象方法的基本原理是使用现实世界的概念抽象地思考问题从而自然地解决问题，它强调模拟现实世界中的概念而不强调算法，鼓励开发者在软件开发的绝大部分过程中都用应用领域的概念去思考。 本章首先简单介绍面向对象的基本概念和面向对象的统一建模语言（Unified Modeling Language,UML），然后介绍面向对象的分析方法和步骤，最后重点介绍每种分析模型的建立方法和过程，并以航空公司机票预订系统为例进行各种模型的建模。 课程思政 5.1面向对象方法介绍 面向对象的分析是采用面向对象方法进行软件开发的第一步，在介绍其具体分析过程之前，首先简要介绍面向对象的基本概念和面向对象开发方法中使用的统一建模语言。 视频讲解 5.1.1面向对象的基本概念 1. 对象 对象是要研究的任何事物。从一本书到一家图书馆，从单个整数到庞大的数据库，甚至极其复杂的自动化工厂、航天飞机都可看作对象。它不仅能表示有形的实体，如学生、职工、商品、仓库等； 也能表示无形的规则、计划或事件，如选课、购买、比赛、法律条文等。对象由数据(描述事物的属性)和作用于数据的操作(体现事物的行为)构成一个独立整体。从程序设计者来看，对象是一个程序模块； 从用户来看，对象为他们提供所希望的行为，对内的操作通常称为方法。 2. 类 类是对象的模板，即类是对一组有相同数据和相同操作的对象的定义，一个类所包含的数据和方法描述一组对象的共同属性和行为。类是在对象之上的抽象，对象则是类的具体化，是类的实例。类可有其子类，形成类层次结构。 3. 继承性 继承性是子类自动共享父类中数据和方法的机制，它由类的派生功能体现。一个类直接继承其父类的全部描述，同时可修改和扩充。 4. 封装性 封装性是对象的重要特性。封装是一种信息隐蔽技术，它体现于类的说明，使数据更安全。封装使数据和加工该数据的方法封装为一个整体，以实现独立性很强的模块，使用户只能见到对象的外特性(对象能接收哪些消息，具有哪些处理能力)，而对象的内特性(保存内部状态的私有数据和实现加工能力的算法)对用户是隐蔽的。封装的目的在于把对象的设计者和对象的使用者分开，使用者不必知晓行为实现的细节，只需用设计者提供的消息来访问该对象。 5. 多态性 多态性是指相同的操作可作用于多种类型的对象上并获得不同的结果。不同的对象收到同一消息可以产生不同的结果，这种现象称为多态性。用户利用多态性可发送一个通用的消息，而将所有的实现细节都留给接收消息的对象自行决定，这样，同一消息即可调用不同的方法，增强了软件的灵活性和重用性。 6. 面向对象 所谓面向对象(ObjectOriented，OO )就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。 7. OO方法 面向对象的方法是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，是建立在“对象”概念基础上的方法，简称OO方法。在OO方法中，对象和传递消息分别表现事物及事物间相互联系的概念，类和继承是适应人们一般思维方式的描述范式，方法是允许作用于该类对象上的各种操作。这种对象、类、消息和方法的程序设计范式的基本点在于对象的封装性和类的继承性，通过封装能将对象的定义和对象的实现分开，通过继承能体现类与类之间的关系，由此可以实现动态联编和实体的多态性，从而以抽象性、继承性、封装性和多态性构成了面向对象的基本特征。OO方法作为一种新型的独具优越性的方法被誉为“研究高技术的好方法”，更是当前计算机界关心的重点，强烈地影响、推动和促进了一系列高技术的发展和多学科的综合。 目前，OO方法已发展应用到整个信息系统领域和一些新兴的工业领域，包括用户界面(特别是图形用户界面，GUI)、应用集成平台、面向对象数据库(OODB)、分布式系统、网络管理结构、人工智能、并发工程、综合集成工程等。 8. 面向对象的分析 遵照面向对象方法学思想进行软件系统开发时，首先要进行面向对象的分析(Object Oriented Analysis，OOA)，其任务是了解问题域所涉及的对象、对象间的关系和操作，然后构造问题的对象模型，力争该模型能真实地反映出所要解决的“实质问题”。在这一过程中，抽象是最本质、最重要的方法，针对不同的问题性质选择不同的抽象层次，过简或过繁都会影响到对问题的本质属性的了解和解决。 9. 面向对象的设计 遵照面向对象方法学思想进行软件系统开发的下一步骤是进行面向对象的设计(Object Oriented Design，OOD)，即设计软件的对象模型。根据所应用的面向对象软件开发环境的功能强弱不等，在对问题的对象模型的分析基础上，可能要对它进行一定的改造，但应以最少改变原问题域的对象模型为原则。然后在软件系统内设计各个对象、对象间的关系(如层次关系、继承关系)、对象间的通信方式(如消息模式)等。总之，面向对象的设计就是设计各个对象“应做些什么”。 10. 面向对象的实现 遵照面向对象方法学思想进行软件系统开发的最后阶段是面向对象的实现(Object Oriented Implementation，OOI)，即软件功能的编码实现。它包括每个对象的内部功能的实现，确立对象哪些处理能力应在哪些类中进行描述，确定并实现系统的界面、输出的形式及其他控制机理等。总之，面向对象的实现就是实现在OOD阶段所规定的各个对象所应完成的任务。 视频讲解 5.1.2统一建模语言 统一建模语言始于1997年的一个OMG(Object Management Group)标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括需求分析、规格、构造和配置。UML因其简单、统一且能表达软件设计中的动态和静态信息的特点，目前已成为可视化建模语言的工业标准。 1. UML的产生 20世纪90年代，面向对象的软件分析与设计方法发展迅猛，出现了几十种流行开发方法，其中最著名的3种是Booch方法、Rumbaugh方法和Jacobson方法。 Booch方法是早期面向对象的软件开发方法的一种。Booch认为软件开发是一个螺旋上升的过程，每个周期包括4个步骤，分别是标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现。Booch方法的开发模型包括静态模型(类图、对象图、模块图、进程图)和动态模型(状态图和时序图)。 Rumbaugh和他的同事提出的对象建模技术(OMT)用于系统分析、系统设计和对象级设计。Rumbaugh方法的开发过程包括4个阶段，分别是分析、系统设计、对象设计和实现，用对象模型、动态模型、功能模型和用例模型共同完成对整个系统的建模。 Jacobson方法也称为OOSE方法，它与其他方法的不同之处在于特别强调用例(Use Case)，并在用例的描述中引入了外部角色的概念。用例用于描述用户与系统之间的交互场景，它是精确描述需求的重要武器，它贯穿于整个开发过程，包括对系统的测试和验证。 1996年，Booch、Rumbaugh和Jacobson三位著名的软件工程专家提出了UML。1997年，OMG组织正式宣布UML作为面向对象软件开发方法的标准建模语言。 UML不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其做了进一步的发展，UML表示法集中了不同的图形表示方法，剔除了其中容易引起的混淆、冗余或很少使用的符号，同时添加了一些新的符号，并最终统一为大众所接受的标准建模语言。计算机辅助软件工程(CASE)产品的供应商也支持UML，并且它基本上已经被所有的软件开发产品制造商所认可，其中包括IBM和微软。 2. UML的特点 (1) UML支持面向对象技术的主要概念，提供了一批基本的模型元素的表示图形和方法，能简洁明了地表达面向对象的各种概念，而且容易掌握和使用。 (2) UML统一了各种方法对不同类型系统、不同开发阶段和不同内部概念的不同观点，从而有效地消除了各种建模语言之间不必要的差异。它实际上是一种通用的建模语言，可以为许多面向对象建模方法的用户广泛使用。 (3) UML建模能力比其他面向对象建模方法更强。通过UML的模型图能清晰地表示系统的逻辑模型和实现模型，它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。 (4) UML是一种建模语言，而不是一个开发过程。 (5) 用UML建立的软件系统模型可以用Java、VC++、Delphi等任何一种面向对象的程序设计语言来实现。 3. UML的基本组成 UML由3个要素构成： UML的基本构造块、支配这些构造块如何放置在一起的规则和运用于整个语言的公用机制。 1) UML基本构造块 UML基本构造块有3种： 事物、关系和图。 事物是对模型中最具有代表性的成分的抽象，包括结构事物，如类(Class)、接口(Interface)、协作(Collaboration)、用例(Use Case)、主动类(Active Class)、组件(Component)和节点(Node)； 行为事物，如交互(Interaction)、态机(Statemachine)； 分组事物，如包(Package)； 注释事物，如注解(Note)。 关系用来把事物结合在一起，包括依赖关系、关联关系、泛化关系和实现关系。 UML从考虑系统的不同角度出发，定义了用例图、类图、包图、对象图、状态图、活动图、顺序图、协作图、构件图和部署图等10种图，这些图从不同的侧面对系统进行描述。系统模型将这些不同的侧面综合成一致的整体，便于系统的分析和构造。对UML图说明如下。 (1) 用例图： 用例图从用户角度描述系统功能，并指明各功能的操作者。它展示了一个外部用户能够观察到的系统功能模型图，帮助开发团队以一种可视化的方式理解系统的功能需求。 (2) 类图： 类图描述类及类与类之间的静态关系，属于一种静态模型。类图是构建其他图的基础，也是表示系统各方面特性的基础。类图显示了类(及其接口)、类的内部结构及与其他类的联系。 (3) 包图： 包图是一种分组机制，由包和类组成。它表示包与包之间的关系，描述系统的分层结构。 (4) 对象图： 对象图是类图的实例，显示了一组对象及它们之间的关系。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。 (5) 状态图： 状态图由状态、转换、事件和活动组成，描述类的对象所有可能的状态和事件发生时的转移条件。通常状态图是对类图的补充，仅需为那些有多个状态的、行为随外界环境而改变的类画状态图。 (6) 活动图： 活动图是一种特殊的状态图，展现了系统内一个活动到另一个活动的流程。它是另一种描述交互的方式，它描述采取何种动作，动作的结果是什么，何时发生，以及在何处发生。 (7) 顺序图： 顺序图描述对象之间的动态交互关系，着重表现对象间消息传递的时间顺序。 (8) 协作图： 协作图是顺序图的一种变化形式，用于描述相互协作的对象间的交互关系和连接关系。 (9) 构件图： 构件图描述软件构件及构件之间的依赖关系，显示代码的静态结构。一般情况下，构件是开发环境中的实现文件。 (10) 部署图： 部署图描述处理器、设备和连接，显示系统硬件的物理拓扑结构及在此结构上执行的软件。 2) UML规则 不能简单地把UML的构造块随机地放在一起，像其他任何语言一样，UML有一套规则，这些规则描述了一个结构良好的模型看起来应该像什么。对UML规则说明如下。 (1) 命名(naming)： 为事物、关系和图起名。 (2) 范围(scope)： 使名称具有特定含义的语境。 (3) 可见性(visibility)： 怎样让其他人使用或看见名称。 (4) 完整性(integrity)： 事物如何正确、一致地相互联系。 (5) 执行(excuse)： 运行或模拟动态模型的含义是什么。 3) UML公共机制 UML有4种贯穿整个语言且一致应用的公共机制。 (1) 规格说明(specification) UML不只是一种图形语言，其实在它的图形表示法的每部分背后都有一个规格说明，这个规格说明提供了对构造块的语法和语义的文字描述。也就是说，UML的图用来对系统进行可视化，而UML的规格说明用来描述系统的细节。 UML的规格说明提供了一个语义底板，它包含了一个系统的各模型的所有部分，各部分相互联系且保持一致。因此，UML图只不过是对语义底板的简单视觉投影，每一个图展现了系统的一个特定的方面。 (2) 修饰(adornment) UML表示法中的每个元素都有一个基本符号，可以把各种修饰细节加到这个符号上。例如，+代表public、—代表private、#代表protect等。 (3) 通用划分(general division) 类/对象二分法： 类是一个抽象，对象是这种抽象的一个具体形式。几乎每一个UML的构造块都存在像类/对象这样的二分法。例如，用例和用例实例(场景)，构件和构件实例，节点和节点实例等。 接口/实现二分法： 接口声明为一个契约，而实现则表示了对该契约的具体实施，它负责如实地实现接口的完整语义。几乎每一个UML的构造块都有像接口/实现这样的二分法。例如，用例和实现它们的协作，操作和实现它们的方法。 (4) 扩展机制(extension mechanism) 对UML图示符号的扩展，包括构造型、标注值和约束。 视频讲解 5.2面向对象分析概述 面向对象分析就是抽取和整理用户需求并建立问题域精确模型的过程。需求分析阶段的任务与结构化需求分析方法完全相同，第一阶段需求获取的方法和过程在2.3.2节已进行了详细介绍，接下来就是分析获取的需求、建立面向对象分析模型及规格说明文档。 用自然语言书写的软件需求通常是有二义性的，内容也往往不够完整，而分析模型应该成为对问题的精确而又简洁的表示，面向对象分析就是指利用面向对象的概念和方法为软件需求建立模型。 面向对象的分析模型一般有3大类： 用例模型、对象模型和交互模型。建立模型的关键是识别出问题域的对象，在分析出它们之间的相互关系之后建立起问题域的简洁、精确和可理解的模型。 在面向对象的三类分析模型中，用例模型是通过用例和场景表示的功能模型，对象模型是用类和对象表示的静态模型，交互模型是由状态图、顺序图和活动图表示的动态模型。三种模型能够表示出系统的功能、数据和行为三方面的基本特征，代表的是系统的数据交换、静态结构和交互次序三个要素。也就是说，任何一个软件的开发，在进行面向对象分析时，都需要建立用例模型来表示功能，建立对象模型来表示软件要处理的数据，建立动态模型来表示交互作用和时序。当然，不同软件因为解决的问题不同，三方面的侧重点有所不同，也可以根据问题域的实际情况选择其中的模型。 5.3建立用例模型 用例图从用户的观点描述系统的功能，它由一组用例(Use Case)、参与者(Actor)以及它们之间的关系所组成。参与者是与系统交互的外部实体，它既可以是使用该系统的用户，也可以是与系统交互的其他外部系统、硬件设备或组织机构。用例从用户角度描述系统的行为，它将系统的一个功能描述成一系列事件，这些事件最终对参与者产生有价值的可观测结果。 视频讲解 5.3.1建立用例模型的过程 建立用例模型一般按以下3个步骤进行。 (1) 确定业务参与者，即标识出目标系统将支持的不同类型的用户。 (2) 确定业务需求用例，即给出参与者需要系统提供的所有功能。 (3) 创建用例模型并画出用例图，即标识出参与者与用例之间以及用例与用例之间的关系。 1. 确定业务参与者 通过关注系统的业务参与者，可以将重点放在如何使用系统，有助于进一步明确系统的范围和边界。而且当系统比较复杂时，要搞清楚系统的需求往往比较困难，如果针对参与者确定系统需求，可以将系统的需求分析得更全面、更完整。 系统的业务参与者可以是人、组织机构、外部系统或硬件设备等。 1) 使用系统的人或组织机构 所谓使用系统的人或组织机构必须是系统的直接使用者，不包括间接使用者，这样的人员应包括系统信息的提供者、维护者及从系统获取信息的人员。比如，高校教务管理系统主要完成学生信息、教师信息、课程信息、教室信息、学生选课、学生成绩等信息的管理，其中使用系统的人和组织机构包括教务处、学生处、院系管理员、教师、学生等。 2) 与本系统有交互的外部系统 所谓与本系统有交互的外部系统就是与本系统具有信息交互的其他软件系统。比如，本系统的某一子功能需要通过一个已有的系统A来完成，那么系统A即为本系统的一个外部系统； 一个已有系统B的某个功能需要本系统协助完成，同样系统B也为本系统的一个外部系统； 高校人事处的学籍档案管理系统在进行学生成绩归档时需要通过教务管理系统协助完成，则学籍档案管理系统即为教务管理系统的外部系统。 3) 与本系统有交互的硬件设备 所谓与本系统有交互的硬件设备就是为本系统提供信息的硬件设备或本系统向其提供信息的硬件设备。例如，需要读取和写入银行系统中信息的POS机、需要读取地图管理系统中信息的车载导航设备等硬件设备，都属于系统业务的参与者。 系统参与者的确定过程与结构化需求分析的功能建模相似，首先画出系统的环境图，然后确定系统的参与者。这里的环境图也包含三部分： 目标系统、输入/输出数据流和系统参与者。另外，确定系统的参与者还可以参考以下内容： 如果存在正在使用的旧系统，其文档和用户手册； 系统需求获取阶段项目会议和研讨会的记录、需求文档和工作手册等。参与者一般用名词或名词性词组来命名，如学生、教师、学籍档案管理系统、POS机等。 面向对象分析阶段环境图的典型样式如图51所示。 图51面向对象的环境图 2. 确定业务需求用例 环境图是分析参与者和发现潜在用例的极好来源，通过环境图可以确定系统的主要输入/输出，通过提交和接收输入/输出的各方确定潜在的用例。 首先从参与者的角度进行分析，从每个参与者与系统交互的过程中发现问题，确定用例。需要分析的内容包括： 每个参与者的特定任务，每个参与者从系统读取什么信息，每个参与者向系统提供什么信息，哪些参与者更新系统哪些信息，引起参与者与系统交互的事件，突发性的或外部的信息是否改变任何参与者等。 然后从系统的功能进行分析，每个用例应该是系统的一个功能，如果功能很大则需要将其分解为几个独立的功能。需要分析的内容包括： 每个参与者的特定任务需要通过什么功能来实现； 系统对每个参与者的信息输入/输出如何反应，如何进行处理； 给出的用例是否包括了所有需求获取时的功能需求； 一个用例中如果包含不同时间段或不同用户执行的内容，是否需要将各部分分离出来形成单独的用例。 最后，如果还不能给出完全、清楚的用例描述，可进行实地调查分析，即功能建模人员去用户的工作场地观察用户的工作，从用户的实际工作流程中发现用户完成的具体功能，然后将每个功能抽象为一个用例。不同用户也可能完成的是相同的功能，对此可抽象为同一个用例。 用例的命名一般采用动词加名词的形式，如维护学生信息、提交成绩等。对每个用例都应该给出完整的描述，即用例的规格说明，包括用例名、参与者、前置条件、后置条件、一个主事件流和零到多个备选事件流等。其中，主事件流是参与者与系统之间正常情况下进行交互的动作序列，备选事件流是参与者与系统之间特殊或异常情况下进行交互的动作序列。 3. 创建用例模型 创建用例模型就是将前面分析得到的系统业务参与者和系统用例及它们之间的关系画成图形，即用例图。用例图是围绕参与者创建的，对于系统的每个参与者可创建一个分用例图，所有分用例图组合在一起形成总体用例图。如果一个系统合成一个总体用例图的图形太复杂，也可以把同一方面的几个分用例图组合成一个用例图，最后组合成多个用例图。 在使用UML建模的用例图中，基本图形符号如图52所示。其中，参与者的图形符号为人形符号，用例的图形符号为椭圆。 图52用例图的基本图形符号 参与者和用例之间通过无方向的直线相连，并通过《communicate》关系进行通信。不同的参与者可以访问相同的用例，一般来说，它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的； 如果两种交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。 用例和用例之间可能存在包含关系，表示一个用例所执行的功能中总是包括被包含用例的功能，通过有向直线将具有包含关系的两个用例相连，箭头指向被包含用例，并在直线上标明《include》关系。一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。一个用例的功能太多时，可以用包含关系建立多个小用例； 如果几个用例有大量一致的功能，则可以将这个功能分解到一个新的用例中，新用例可以和这几个用例建立包含关系。 用例和用例之间还可能存在扩展关系，表示一个用例的执行可能需要有其他用例的功能来扩展，但基本用例的功能并不依赖于扩展用例，通过有向直线将具有扩展关系的两用例相连，箭头指向基本用例，并在直线上标明《extend》关系。事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。一般情况下，基础用例的执行不会涉及扩展用例，只有特定的条件发生，扩展用例才被执行。扩展关系为处理异常或构建灵活的系统框架提供了一种有效的方法。 参与者和参与者以及用例和用例之间可能存在泛化关系(也称为继承关系)，泛化关系用带空心箭头的直线表示，箭头指向被继承方。参与者之间的泛化关系意味着一个参与者可以继承另一个参与者的角色，即后代继承了祖先的所有用例。当然后代也会具有一个或多个特定于该角色的用例。 存在泛化关系的用例中，子用例和父用例相似，但表现出更特殊的行为： 子用例将继承父用例的所有结构、行为和关系； 子用例可以使用父用例的一段行为，也可以重载它； 父用例通常是抽象的，而子用例则会更加具体。在实际应用中很少使用用例间的泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。 视频讲解 5.3.2建立用例模型的实例 以高校图书借阅系统为例创建用例模型，即功能建模。 1. 确定业务参与者 首先，画出图书借阅系统的环境图，如图53所示。 参与者包括图书管理员和读者两类用户。 2. 确定业务需求用例 通过环境图53可以从参与者的角度分析出以下用例。 (1) 图书管理员的用例： 读者信息维护、图书信息维护、图书管理员的查询事务。 (2) 读者的用例： 修改个人密码、借书、续借、还书、读者的查询事务。 用例图分成3个，图书管理员的用例图如图54所示，读者修改个人密码和信息查询用例图如图55所示，读者的借书、续借、还书用例图如图56所示。 图53图书借阅系统的环境图 图54图书管理员的用例图 图55读者修改个人密码和信息查询用例图 严格来讲，应该对每个用例都要进行完整的描述，即给出每个用例的规格说明。鉴于篇幅，这里给出“借书”用例的规格说明，如表51所示。 表51借书用例的规格说明 用例名： 借书参与者： 读者 1. 前置条件： 图书和读者信息已存在系统的数据库中。 2. 后置条件： 如果此用例执行成功，则借阅列表中增加了此读者的一条借阅信息。如果执行不成功，则系统不发生任何变化。 3. 主事件流 (1) 当读者单击借书按钮时，此用例开始。 (2) 读者扫描校园卡。 (3) 系统检查此读者是否有超期未还图书。 (4) 如果没有超期未还图书，则系统检查此读者的借书量上限是否已满。 (5) 如果借书量上限未满，则系统提示读者扫描图书条形码。 (6) 读者扫描图书条形码。 (7) 系统生成借阅信息写入数据库，包括借书日期(默认为当前日期时间)、还书日期(空值)、是否归还(默认为否)、续借日期(空值)、罚款金额(空值)、是否交罚款(默认为否)。 (8) 系统修改此图书的状态为已借出。 (9) 系统显示借阅信息。 (10) 读者选择继续借阅或退出。 4. 备选事件流 （1） 如果读者扫描校园卡后，系统检查有超期未还图书，则显示超期信息，此用例结束。 （2） 如果系统检查此读者借书上限已满，则提示“借书量已满无法再借阅！”，此用例结束。 （3） 如果系统不能成功更新数据库，则提示“系统操作失败，请稍候再试！”，此用例结束。 图56读者的借书、续借、还书用例图 5.4建立对象模型 对象模型是模型的静态结构，用于表示软件要处理的数据，在UML中表示为类图。类图中包括类、类的内部结构及类与类之间的关系。 5.4.1建立对象模型的过程 建立对象模型一般分为5个步骤，包括划分主题、确定类和对象、确定类与类之间的关系(包括泛化、关联、聚合等)、确定类和关联的属性及确定类和关联的操作。 视频讲解 1. 划分主题 对于小型系统来说，可以跳过此步骤直接开始确定系统的类和对象。而对于稍大型的系统，为了简化对象模型的创建过程，避免因系统的复杂性和繁琐性带来建模的混乱、差错和缺陷，可以将一个大问题划分为若干主题，再针对各个主题逐步确定类和对象及类之间的关系，最后再将这些主题合并为一个整体。 划分主题一般应遵循下列原则。 (1) 每个主题的规模应当适中，以含有6个左右的类为宜。 (2) 每个主题的应用功能应具有独立性和完整性，与其他主题的应用有最少的联系。 2. 确定类和对象 类和对象是问题域中客观存在的，系统分析员的主要任务是根据获取的需求和用例模型分析出这些类和对象。首先找出候选的类和对象，然后从中筛选出正确的类和对象。 1) 找出候选的类和对象 类和对象是对问题域中有意义的事物的抽象，它们既可能是可见的物理实体，也可能是抽象的概念。 首先，可以参照几类常见事物，将客观事物进行划分，找出当前问题域中的候选类和对象。比如，可感知的物理实体，如教室、仓库、零件等； 人或组织的角色，如学生、学院、职工、部门等； 应该记忆的事件，如演出、比赛、交通事故等； 两个或多个对象的相互作用，通常带有交易或接触的性质，如选课、购买、进货、出库等； 需要说明的概念，如保险法、政策等。 另外，还有一种更简单的非正式分析方法。这种方法是以自然语言书写的需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。例如，在工厂数据库应用系统中，可以初步确定仓库、保管员、零件、供应商、库存情况、库存总量统计、供应(进货)情况、销售(出货)情况等类和对象。 2) 筛选出正确的类和对象 通过以上方法找出候选的类和对象后，接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的类和对象，仅保留确实应该记录其信息或需要其提供服务的那些类和对象。 筛选时应遵循以下原则进行类和对象的删除。 （1） 冗余： 如果两个类表达了同样的信息，保留一个。 （2） 无关： 仅需要把与本问题密切相关的类和对象保留。 （3） 笼统： 需求陈述中笼统、泛指的名词不能设置为类和对象，应该使用更明确、具体的名词对应其暗示的事物，并设置为类和对象名。如果已将这些笼统、泛指的名词设置为类和对象，则将其删除。 （4） 属性： 每个类都应具有多个有意义的属性，如果某个类只有一个属性，则应将其设置为其他类的属性。 （5） 操作： 需求陈述中有些词既可作为名词也可作为动词，应该根据其含义正确筛选，决定它们应该作为类还是作为类定义中的操作。 （6） 实现： 去掉仅与实现有关的类和对象，因为需求分析阶段不应考虑目标系统如何实现。 例如，在工厂数据库应用系统中，“库存总量统计”类是不需要的，单独存储此信息浪费空间，完全可以在软件实现中完成其计算功能。 视频讲解 3. 确定类与类之间的关系 类与类之间的静态关系包括关联关系、聚合关系和泛化关系。 关联关系是指两个或多个类之间的连接关系，是类之间最常见的关系。关联关系的真实含义是这些类的实例之间的联系具有多重性，即指一个类的多个实例与另一个类的多个实例相关，包括一对一、一对多和多对多三类，应该在关联的每一端将其类型标识出来。其中，一对一可以表示为1对1或1对0..1，一对多可以表示为1对0..n或1对1..n，多对多可以表示为0..n对0..n、0..n对1..n或1..n对1..n。 聚合关系表示类和类之间具有明显的组成关系，即两个类之间的对象具有整体和部分的关系，也就是一个类的实例包含另一类的实例，它是关联关系的一种特殊形式。 泛化关系又称继承关系，表示一般与特殊的关系，它指的是子类继承父类的所有属性和行为，子类也可以具有自己独有的属性和行为。例如，老虎是动物的一种，既有老虎的特性也有动物的共性，所以动物是父类，老虎是子类。由于泛化关系表示的是类之间的关系，不是实例间的关系，所以没有多重性。 在使用UML建模的类图中，每个类表示为一个矩形，矩形的上部为类名，中间为类的所有属性，下部为类的所有操作，除类名外，其他部分可以省略。类之间的关联关系用一条无向直线表示，直线两端分别与一个类相连，并在两端标注关联的对象数量； 类之间的聚合关系在表示关联关系的直线整体类一端画一个空心菱形，它表示一对多联系，类图中整体端关联的对象数量为1，不必标出； 类之间的泛化关系在表示关联关系的直线一般类一端画一个空心三角形。 1) 确定关联关系 类之间的关系绝大部分都是关联关系，表示类中具体对象之间的联系，具有多重性。在分析类之间的关联关系时，不必过多地考虑类之间的聚合，不必花太多的精力去区分关联和聚合，因为聚合只不过是关联关系的一个特殊形式。 关联关系可以通过下列活动进行确定。 （1) 识别对象之间的静态关系 首先从问题域考虑各类的对象之间是否存在某种静态联系，然后按系统功能考虑这个联系是否需要表示出来。例如，教务管理系统中学生和课程之间存在选课关系，学生和班级之间存在属于关系，教师和课程之间存在任课关系，教师和学生之间存在教授关系，这些关系在教务管理系统的对象模型中是否都表示出来，就要考虑每个联系是否都与系统的功能具有很大的相关性，如果相关性很小就不需要将其表示出来。教学管理系统中，教师和学生之间存在的教授关系一般与系统的功能相关性很小，所以此关联关系不需要表示出来。 （2) 分析关联的多重性 对于每一个关联，都应考虑其两端类中对象与对方的对应数量，并在两端分别进行标注，如学生和课程之间的选课关系为多对多关联关系。 （3) 识别关联的属性和操作 对于每个已在模型中表示出来的关联，接着要考虑的是它是否还具有某些属性和操作，即该关联是否还具有两个类之间发生关联关系时产生的属性和操作。比如，学生和课程之间的选课关系在学生选课后应产生成绩等属性，而这种多对多联系产生的属性无法存储在两端的任何一个类中，所以成绩等属性就应设置为选课关联的属性，对成绩等属性的操作则应设置为选课关联的操作，像这样的关联可以被看作一种特殊的称为关联类的类。 2) 确定聚合关系 聚合关系即类与类中对象之间的组合关系，如果发现一个类中的对象都是由另一个类中的多个对象组合而成的，那么这两个类就具有聚合关系。比如，组织机构的上下级关系，如大学和学院、学院和系都是聚合关系； 物理上的整体事物与组成部分，如设备与零部件之间也是聚合关系； 抽象的整体事物与部分，如课程与课表之间也是聚合关系等。 3) 确定泛化关系 可以参考当前应用领域的分类学知识或按照自己的常识，从各种角度考虑事物的分类，发现泛化关系。另外，可以考察类的属性和操作，发现类之间的泛化关系。 （1） 从一般类发现特殊类 检查一个类的所有属性和操作是否适合这个类的全部对象，如果某些属性和操作只适合该类中一部分对象，说明该类中可以划分出一部分特殊类，建立泛化关系。例如，假设图书借阅系统中的“借阅记录”类中有“借书日期”“应还日期”“还书日期”“罚款”四个属性，通过审查发现，“借书日期”和“应还日期”两个属性只需要借书时记录，而“还书日期”和“罚款”两个属性只需要还书时记录。这种情况下，可以在“借阅记录”类下建立“借书”和“还书”两个特殊类，并把“借书日期”和“应还日期”及“还书日期”和“罚款”分别放在这两个特殊类中，如图57所示。 图57从一般类发现特殊类 （2） 从特殊类抽出一般类 检查是否有两个或多个类具有某些共同的属性和操作，如果存在，则可以考虑将这些属性和操作抽出形成一般类。例如，假如教务系统中包含“本科生”和“研究生”两个类，它们存在共同的属性“学号”“姓名”“性别”“出生日期”“学院”，那么可以抽出这些属性形成一个 “学生”类，与“本科生”和“研究生”两个类建立泛化关系，如图58所示。 图58从特殊类抽出一般类 视频讲解 4. 确定类和关联的属性 属性表示类中对象的性质，它既与问题域有关，又与系统要完成的功能有关。如何分析和选择属性，可以参考下列方法。 每个类的对象至少要包含一个“id”性质的属性，如学生的学号、商品的编号、订单的编号等； 属性的设置应适合类中所有对象，包括在泛化关系当中对象所继承的属性； 系统中所有要存储的数据都必须定义为属性； 导出属性即可通过其他属性计算出来的属性应当略去。另外，还有一些错误或不确定的属性应该删除，如误把对象或关联当作属性、过于细化的属性、不一致的属性等。 每个属性的数据类型可在此确定，也可以在面向对象的设计阶段确定。 5. 确定类和关联的操作 类和关联中的对象收到消息后所能执行的操作即为类和关联的操作，确定好的每个对象中必须封装的操作有以下两种。 (1) 简单的操作。简单操作是每个对象都应具备的操作，包括建立和初始化一个新对象，建立或切断对象之间的关联，存取对象的属性值，释放或删除一个对象。这些操作在分析时是隐含的，在类图中不必标出，但实现(编码)类和对象时要有定义。 (2) 复杂的操作。复杂操作分为两种： 计算操作，即利用对象的属性值计算，以实现某种功能； 监控操作，它处理的是外部系统的输入输出、对外部设备的控制和数据的存取。 以下是一个简单的教务管理系统的类图，其中包含类之间的关联和聚合，以及类和某些关联的属性与操作，如图59所示。 图59简单的教务管理系统的类图 视频讲解 5.4.2建立对象模型的实例 以高校图书借阅系统为例创建对象模型，即类图。 分析问题的规模，此系统不需要划分主题。根据问题域和5.3.2节的用例模型，分析得到图书借阅系统的类和对象包括图书、单本图书、读者、读者类别、图书存放区域、图书管理员，它们之间的关系为每种图书有多本，即包含多个单本图书的对象； 每个图书都只能规定一个存放区域； 每个图书管理员只管理一个区域的图书，每个区域有多名管理员； 每个读者都可以对每个单本图书进行借阅； 每个读者都只属于一个读者类别。根据问题域和系统功能分析各类中对象的属性，如表52所示。 表52 图书借阅系统各类中对象的属性 类与对象 属性 图书 书号，书名，作者，单价，类别，出版社，出版日期 单本图书 条码号，图书状态 读者 读者号，密码，姓名，性别，电话，身份证号 读者类别 类别号，类别名，最大借书天数，最大续借天数，最大借书数量 存放区域 区域名，最大存放数量 图书管理员 编号，姓名，密码，电话 借阅 读者号，图书条码号，借书日期，还书日期，是否归还，续借日期，罚款金额，是否交罚款 各类与对象的操作同样可以根据问题域和5.3.2节的用例模型加以确定，如表53所示。 表53图书借阅系统各类中对象的操作 类与对象 操作 读者 修改密码，查询读者信息，查询个人借阅信息 图书 查询图书信息，统计各类别图书借阅情况 单本图书 修改图书状态 借阅 增加读者借阅信息，修改还书日期、是否归还、续借日期、罚款金额、是否交罚款，查询借阅信息，查询超期未还信息 读者类别 查询各类别读者借书量上限、最长借书天数等 图书管理员 修改密码 画出图书借阅系统的对象模型，即类图，如图510所示，其中初步确定了每个属性的数据类型。 图510图书借阅系统的类图 5.5建立交互模型 交互模型一般是由顺序图、状态图和活动图表示的动态模型，在交互式系统的开发中，交互模型非常重要，它是从需求分析向设计过渡的重要环节。 视频讲解 5.5.1顺序图 前面介绍的用例图中，用例从用户角度描述系统的行为，它将系统的一个功能描述成一系列事件，用户与用例的交互过程通过事件流进行描述，这是一个文本性质的场景描述。顺序图可以通过图形的形式描绘这种场景，其中既具有交互的时间顺序，又包含了参与交互的类的对象及完成功能细节时对象之间要交互的信息。另外，这些类的对象还包含用户的某些操作界面，其实例为表单对象(Form)和系统服务器对象(Server)。所以顺序图对参与者与每个用例的交互过程的描述更加流畅并更具直观性，既易于用户的理解和交流，又有利于开发者从需求向设计的过渡。 在顺序图中，纵轴从上到下为交互的时间顺序，横轴从左到右为参与交互的参与者对象、处理用例功能的服务类对象、对象模型中某些类的对象及一些操作界面的表单对象和系统服务器对象，关系密切的对象应安排在相邻位置。每个对象下面有一条竖直的虚线，为该对象的生命线； 生命线中有一到多个细长的矩形，表示该对象的生存活跃期； 虚线部分为休眠期。对象之间通过一个有向实线进行消息发送，通过有向虚线返回消息，有向实线和虚线上均标明消息的名称。顺序图的基本符号如图511所示。 图511顺序图的基本符号 顺序图中对象之间发送的消息可分为以下几类。 （1） 消息(普通)。它连接到两个不同对象生命线的连接点。在图511中，消息1是个普通消息例子。此类消息表示一个动作，与接收对象(箭头所指的对象)的方法或操作相关，即接收消息的对象执行这个请求上的动作。消息可包含传给要执行方法的参数。 （2） 消息(调用)。消息调用的流程类型是过程调用，即消息调用是过程调用的一部分。尽管如此，消息调用的行为类似于普通消息。图511的消息2是消息调用。 （3） 消息(返回)。返回消息是将信息返给对象的消息，一般发生在执行动作之后。返回信息不执行动作，仅返回信息，与普通消息的方法或操作无关。在图511中，消息3是返回消息。 （4） 消息(异步)。异步调用是流程类型被设置为异步的消息。这意味着，发送对象将消息发送给接收对象，并不等待接收对象的响应。发送对象可继续其他操作，同时接收对象执行发送消息的动作请求。在图511中，消息4是异步消息。 以高校图书借阅系统为例给出其借书用例的顺序图，如图512所示。 图512借书用例的顺序图 图中所有对象的名称和对象中传递的信息都采用了中文，目的是使读者阅读方便，在后续的分析过程中应改为英文，对象名称与对象模型中类与对象的名称要对应，消息应与类中定义的方法一致。 还书用例的顺序图如图513所示。 图513还书用例的顺序图 其他用例相对比较简单，顺序图不再一一给出。 5.5.2状态图 状态图由对象的各个状态和连接这些状态的转换组成。在结构化分析方法中，状态图通过描绘系统的状态及引起系统状态转换的事件 视频讲解 来表示系统的行为； 而在面向对象的分析方法中，状态图描述的是各类对象的动态行为。但面向对象的分析方法中状态图的画法与结构化分析方法中的画法基本相同。 状态图描绘的是事件与对象状态的关系，当对象接收到一个事件后，其状态会发生改变。如果一个事件并不引起对象的状态变化，则状态图中应忽略此事件。 通常用一张状态图描绘一类对象的行为，它确定了由事件序列引出的对象的状态序列。但也不是任何一个类都需要有一张状态图描绘它的行为，只针对具有明显的状态特征并且具有比较复杂的状态、事件、响应行为的类，才需要画状态图。 在高校图书借阅系统中，图书借阅类的对象具有比较明显的状态特征，其状态有： （1）未归还、未续借、未超期； （2）未归还、已续借、未超期； （3）未归还、未续借、已超期、未交罚款； （4）未归还、已续借、已超期、未交罚款； （5）已归还、未超期； （6）已归还、已超期、已交罚款。借阅类对象的状态图如图514所示。 图514借阅对象的状态图 单本图书对象的状态有未借出、已借出、不可借和已下架四种状态，状态图如图515所示。 图515单本图书对象的状态图 视频讲解 5.5.3活动图 活动图用来捕捉用例的活动，使用框图的方式显示动作及其结果。活动图是一个流图，描述了从活动到活动的流。它是另一种描述交互的方式，它描述采取何种动作，动作的结果是什么(动作状态改变)，何时发生(动作序列)，以及在何处发生(泳道)。活动图是状态图的一种特殊形式，其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发。 一个活动图可能包括起点、终点、动作、转移、决策、同步棒和泳道等元素，如图516所示。 图516活动图中的元素 其中，动作用圆角矩形表示，代表在工作流程中执行某个活动或步骤； 转移用带箭头的实线表示，代表各种动作的先后顺序，这种转移可称为完成转移，它不同于一般的转移，因为它不需要明显的触发器事件，而是通过完成动作来触发； 决策用菱形表示，为其定义了一组警戒条件，这些警戒条件决定在活动完成后将执行一组备选转移中的哪个转移，决策和警戒条件使活动图能够显示出业务用例的工作流程中的备选线程； 实心矩形条表示同步棒，用于显示平行分支流，同步棒使活动图能够显示出业务用例的工作流程中的并行线程。 可以使用垂直实线将活动图划分为多条泳道，每条泳道代表整个工作流程的某活动图各部分的职责，该职责可以由组织单元 或业务对象模型中的一组类来实施。每个动作都指派了一条泳道，而转移则可能跨越数条泳道。 在图书借阅系统中，借书和还书用例比较复杂，给出活动图更容易进行后面的软件设计。 借书用例的活动图如图517所示。 还书用例的活动图如图518所示。 图517借书用例的活动图 图518还书用例的活动图 5.6机票预订系统面向对象分析项目实践 视频讲解 5.6.1建立机票预订系统的用例模型 以航空公司机票预订系统为例创建用例模型。 1. 确定业务参与者 首先，画出航空公司机票预订系统的环境图，如图519所示。 图519机票预订系统的环境图 参与者包括航空公司操作员和旅客两类用户及时钟。 2. 确定业务需求用例 通过环境图519可以从参与者的角度分析出以下用例。 (1) 航空公司操作员的用例： 航班信息维护、注销旅客信息、操作员的查询事务。 (2) 旅客的用例： 旅客信息维护、订票、退票、取票、旅客的查询事务。 另外，航空公司操作员在旅客已取票情况下，可以在期限范围内为旅客完成退票，操作流程与旅客退票流程相同。 用例图分成3个，航空公司操作员的用例图如图520所示，旅客的个人信息维护和信息查询用例图如图521所示，旅客的订票、取票和退票用例图如图522所示。 严格来讲，我们应该对每个用例都要进行完整的描述，即给出每个用例的规格说明。这里只给出了“订票”和“退票”用例的规格说明，如表54和表55所示。其中，“退票”用例的参与者是旅客或航空公司操作员，但表55是从旅客的角度进行的规格说明。 图520航空公司操作员的用例图 图521旅客的个人信息维护和信息查询用例图 图522旅客的订票、取票和退票用例图 表54订票用例的规格说明 用例名： 订票参与者： 旅客 1. 前置条件： 航班和票务信息已存在系统的数据库中。 2. 后置条件： 如果此用例执行成功，则订单列表中增加了此旅客的一个订单，机票列表中增加了此旅客的一张机票，航班余票减少1。如果执行不成功，则系统不发生任何变化。 3. 主事件流 (1) 当旅客单击某日期、某舱位航班的“订票”按钮时，此用例开始。 (2) 系统生成订单，此时订单状态为未付款，系统修改航班余票减1并提醒旅客进行付款。 (3) 旅客单击“付款”按钮，开始付款。 (4) 付款完成后，系统修改订单状态为已付款，并生成机票。 (5) 系统提示订票成功并向旅客发送订票成功通知。 4. 备选事件流 （1） 如果系统生成订单后旅客未马上付款，则订单状态为未付款，此用例暂时结束。 （2） 如果系统生成订单后旅客未马上付款，再次进入系统后选择“取消订单”按钮或超出期限用户仍未付款，则订单状态改为已取消，修改航班余票增加1，此用例结束。 （3） 如果旅客在进行付款时付款失败，则提示“系统操作失败，请稍候再试！”，此用例结束。 （4） 如果系统不能成功更新数据库，则提示“系统操作失败，请稍候再试！”，此用例结束。 表55退票用例的规格说明 用例名： 退票参与者： 旅客或航空公司操作员 1. 前置条件： 旅客订单和机票信息已存在系统的数据库中。 2. 后置条件： 如果此用例执行成功，则订单的状态变成已退款，机票的状态变成已退票，航班余票增加1。如果执行不成功，则系统不发生任何变化。 3. 主事件流 (1) 当旅客选择自己的某个订票信息申请退票时，此用例开始。 (2) 系统进行退票审核，如果距离航班起飞已经在一天之内或购票金额为5折及更低的折扣，则不能退票。 (3) 系统根据距离航班起飞的天数和购票时的折扣计算退款金额。 (4) 系统显示退款金额，并询问旅客是否确定要退票。 (5) 旅客单击“确定”后，系统联系第三方进行退款，并通知旅客到账期限。 (6) 系统修改订单状态为已退款、机票状态为已退票，航班余票增加1。 (7) 系统提示退票成功并向旅客发送退票成功通知。 4. 备选事件流 （1） 如果系统退票审核失败，则无法退票，此用例结束。 （2） 如果系统显示退款金额后旅客取消退票，则此用例结束。 （3） 如果系统联系第三方进行退款失败，则提示“系统操作失败，请稍候再试！”，此用例结束。 （4） 如果系统不能成功更新数据库，则提示“系统操作失败，请稍候再试！”，此用例结束。 视频讲解 5.6.2建立机票预订系统的对象模型 为航空公司机票预订系统创建对象模型，即类图。 分析问题的规模，此系统不需要划分主题。根据问题域和前面的用例模型，分析得到航空公司机票预订系统的类和对象包括旅客、航班、航班票务、订单和机票，它们之间的关系为每一个航班具有多种不同舱位的机票，即包含多个航班票务的对象； 每个旅客都可以对每种航班票务下订单进行预订； 每个订单会产生一张机票。根据问题域和系统功能分析各类中对象的属性，如表56所示，其中旅客需要用身份证号进行注册，航班票务中每个航班不同舱位、不同日期的票价可能有所区别，订单包括未付款、已付款、已取消、已退款和已完成5种状态，机票包括未取票、已取票和已退票3种状态。 表56航空公司机票预订系统各类中对象的属性 类 与 对 象 属性 旅客 身份证号，密码，姓名，电话 航班 航班号，起飞站，起飞时间，到达站，到达时间，登机时间，登机口 航班票务 航班号，舱位，日期，票价，余票 订单 订单号，折扣，订票时间，订单状态 机票 订单号，座位，机票状态 各类与对象的操作同样可以根据问题域和前面的用例模型加以确定，如表57所示。 表57航空公司机票预订系统各类中对象的操作 类 与 对 象 操作 旅客 注册，个人信息维护，注销 航班 查询航班信息 航班票务 按航班日期查询票务信息，统计航班预订情况 订单 生成订单，改变订单状态，统计订单情况，计算退款金额 机票 生成机票，改变机票状态，统计机票信息 画出航空公司机票预订系统的对象模型，即类图，如图523所示，其中初步确定了每个属性的数据类型。 图523航空公司机票预订系统的类图 5.6.3建立机票预订系统的交互模型 1. 顺序图 视频讲解 航空公司机票预订系统的订票、取票和退票功能比较复杂，其他功能相对简单，所以这里只给出这三个用例的顺序图，订票用例的顺序图如图524所示。 图524订票用例的顺序图 图中所有对象的名称和对象中传递的信息都采用了中文，目的是使读者阅读方便，在后续的分析过程中应改为英文，对象名称与对象模型中类与对象的名称要对应，消息应与类中定义的方法一致。 取票用例的顺序图如图525所示。 在退票用例的顺序图中，参与者只画出了旅客，没有画出航空公司操作员，如图526所示。 视频讲解 2. 状态图 在航空公司机票预订系统中，订单类的对象具有比较明显的状态特征，其状态有未付款、已付款、已取消、已退款和已完成5种。订单类对象的状态图如图527所示。 机票对象的状态有未取票、已取票、已退票3种状态，其状态图如图528所示。 视频讲解 3. 活动图 在航空公司机票预订系统中，订票、取票和退票用例比较复杂，给出活动图更容易进行后面的软件设计。 订票用例的活动图如图529所示。 图525取票用例的顺序图 图526退票用例的顺序图 图527订单对象的状态图 图528机票对象的状态图 图529订票用例的活动图 取票用例的活动图如图530所示。 图530取票用例的活动图 退票用例的活动图如图531所示。 图531退票用例的活动图 5.7小结 本章主要介绍了面向对象的需求分析方法，详细介绍了功能建模(用例图)、对象模型(类图)和动态模型(顺序图、状态图和活动图)的创建方法，并给出了相应的“高校图书借阅系统”的面向对象需求分析实例，最后用一个“航空公司机票预订系统”的项目案例完整地实现了面向对象需求分析的全过程。 面向对象的需求分析方法与结构化需求分析方法相比，其分析方式更接近于人的思维，所建立的用例图、类图、顺序图 、状态图和活动图更具直观性，特别是针对于人机交互较强的系统，采用面向对象的需求分析方法更具优势。 另外，在进行了面向对象需求分析的部分模型的建模后，就可以开始进行软件设计建模，不必等到需求分析完全结束才进入设计阶段。这样，软件的开发会更具连贯性和迭代性，更容易发现开发过程中出现的一些失误、冗余或遗漏。 面向对象的需求分析阶段也需要编写需求规格说明文档，供后期各阶段参考，也供开发者之间及开发者和用户之间进行交流和讨论。 习题5 1. 名词解释： 对象、类、继承性、封装性、多态性、面向对象、UML。 2. 简述UML的特点。 3. 简述UML的基本组成。 4. 面向对象的分析模型一般包括哪3大类？ 5. 什么是用例图？ 6. 简述用例图中的《communicate》关系、《include》关系、《extend》关系和泛化关系。 7. 什么是对象模型？ 8. 什么是聚合关系？什么是关联关系？ 9. 简单解释交互模型中的顺序图、状态图和活动图。 10. 某学生选课系统的功能要求： 教师提出开课计划，系统批准并写入开课表后给教师下发开课通知； 学生可通过系统查询开课信息并提出选课申请，系统批准并写入选课表后给学生下发选课申请结果通知； 课程结束后，教师可以录入学生成绩，同时把成绩单发送给学生。根据以上功能要求画出参与者学生和教师的用例图。 11. 分别画出第10题教师开课申请、学生选课申请用例的顺序图和活动图。 12. 高校学生一卡通管理系统可以完成充值、消费、挂失、注销等功能，其中校园卡对象的属性包括学号、密码、姓名、手机号、学院、班级、余额和卡状态(正常、挂失冻结、注销)，交易记录对象的属性包括交易号、交易时间、消费金额、充值金额。试画出此系统的类图。 13. 画出第12题校园卡对象的状态图。 14. 画出习题2第17题仓库库存管理系统的用例图、类图及主要用例的顺序图、活动图。