面向对象的需求分析方法
面向对象的需求分析方法
面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 20世纪 60年代中期的仿真程序设计语言Simula67。20世纪80年代初出现的Smalltalk 语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。20世纪90年代中后期诞生并迅速成熟的UML（Unified Modeling Language，统一建模语言）是面向对象技术发展的一个重要里程碑。UML 统一了面向对象建模的基本概念、术语和表示方法，不仅为面向对象的软件开发过程提供了丰富的表达手段，而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。在概述了UML的全貌之后，以“家庭保安系统”为实例，介绍与需求分析相关的部分 UML语言机制以及基于UML的面向对象的需求分析方法和过程。
第一节面向对象的概念与思想
一、面向对象的概念
关于“面向对象”，有许多不同的看法。Coad和 Yourdon给出了一个定义：“面向对象 = 对象 + 类 + 继承 + 消息通信”。如果一个软件系统是使用这样4个概念设计和实现的，则认为这个软件系统是面向对象的。一个面向对象的程序的每一成分应是对象，计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象（object）
一般意义来讲，对象是现实世界中存在的一个事物。可以是物理的，如一个家具或桌子，如图 5-1-1所示，可以是概念上的，如一个开发项目。对象是构成现实世界的一个独立的单位，具有自己的静态特征（用数据描述）和动态特征（行为或具有的功能）。例如：人的特征：姓名、性别、年龄等，行为：衣、食、住、行等。
图 5-1-1 对象的定义
（1）对象、属性、操作、消息定义
对象可以定义为系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，由一组属性和一组对属性进行操作的服务组成。
属性一般只能通过执行对象的操作来改变。
操作又称为方法或服务，在C ++中称为成员函数，它描述了对象执行的功能，若通过消息传递，还可以为其他对象使用。
而所谓的消息是一个对象与另一个对象的通信单元，是要求某个对象执行类中定义的某个操作的规格说明。发送给一个对象的消息定义了一个操作名和一个参数表（可能是空的），并指定某一个对象。由一个对象接收的消息则调用消息中指定的操作，并将传递过来的实际参数与参数表中相应的形式参数结合起来。接收对象对消息的处理可能会改变对象中的状态，即改变接收对象的属性，并发送一个消息给自己或另一个对象。可以认为，这种消息的传递大致等价于过程性范型中的函数调用。
（2）对象的分类
〃外部实体：与软件系统交换信息的外部设备、相关子系统、操作员或用户等。
〃信息结构：问题信息域中的概念实体，如信号、报表、显示信息等。
〃需要记忆的事件：在系统运行过程中可能产生并需要系统记忆的事件，如单击鼠标左键、击打键盘“?”键等。
〃角色：与软件系统交互的人员所扮演的角色，如经理、部长、技术支持等。
〃组织机构：有关机构，如单位、小组等。
〃位臵：作为系统环境或问题上下文的场所、位臵，如客户地址、收件人（机构）地址等。
〃操作规程：如操作菜单、某种数据输入过程等。
在标识对象时必需注意遵循“信息隐蔽”的原则：必需将对象的属性隐藏在对象的内部，使得从对象的外部看不到对象的信息是如何定义的，只能通过该对象界面上的操作来使用这些信息。对象的状态通过给对象赋予具体的属性值而得到。它只能通过该对象的操作来改变。
对象有两个视图，分别表现在分析设计和实现方面。从分析及设计方面来看，对象表示了一种概念，它们把有关的现实世界的实体模型化。从实现方面来看，一个对象表示了在应用程序中出现的实体的实际数据结构。之所以有两个视图，是为了把说明与实现分离，对数据结构和相关操作的实现进行封装。
2.类（class）和实例（instance）
把具有相同特征和行为的对象归在一起就形成了类。类成为某些对象的模板，抽象地描述了属于该类的全部对象的属性和操作。属于某个类的对象叫做该类的实例。对象的状态则包含在它的实例变量，即实例的属性中。如图 5-1-2所示。从“李杰”、“王辉”和“杨芳”等对象可得到类“学生”，而这些对象就称为该类的实例。
图 5-1-2 对象、类与实例
类定义了各个实例所共有的结构，类的每一个实例都可以使用类中定义的操作。实例的当前状态是由实例所执行的操作定义的。
面向对象程序设计语言，如C++和 smalltalk都定义了一个new操作，可建立一个类的新实例。C++ 还引入了构造函数，用它在声明一个对象时建立实例。此外，程序设计语言给出了不同的方法，来撤消（称为析构）实例，即当某些对象不再使用时把它们删去，把存储释放以备其他对象使用。C++给出了一个操作delete，可以释放一个对象所用的空间。C++还允许每个类定义自己的析构方法，在撤消一个对象时调用它。smalltalk 没有提供一个机制来撤消对象，但可以进行无用单元收集。
类常常可看做是一个抽象数据类型（ADT）的实现。但更重要的是把类看做是表示某种概念的一个模型。事实上，类是单个的语义单元，它可以很自然地管理系统中的对象，匹配数据定义与操作。类加进了操作，给通常的记录赋予了语义，可提供各种级别的可访问性。
3.继承（inheritance）
如果某几个类之间具有共性的东西（信息结构和行为），抽取出来放在一个一般类中，而将各个类的特有的东西放在特殊类中分别描述，则可建立起特殊类对一般类的继承，如图
5-1-3所示。各个特殊类可以从一般类中继承共性，这样避免了重复。
图 5-1-3 特殊类对一般类的继承关系
建立继承结构的好处：
〃易编程、易理解代码短, 结构清晰；
〃易修改：共同部分只要在一处修改即可；
〃易增加新类：只须描述不同部分。
4.多继承
如果一个类需要用到多个既存类的特征，可以从多个类中继承，称为多继承。例如退休教师是继承退休者和教师这两个类的某些特征或行为而得到的一个新类。
图 5-1-4 多继承
5.多态性和动态绑定
对象互相通信，即一个对象发消息给另一个对象，执行某些行为或又发消息给另外的对象，从而执行系统的功能。
发送消息的对象可能不知道另一个对象的类型是什么。如在 C程序中使用命令ClearInt （）时要严格区分该命令适合一个整数，还是一个整数数组。但在C++情形，ClearInt （）对两者都适用，它自己判断对象是哪一个。
这就是多态性。它意味着一个操作在不同类中可以有不同的实现方式。如清零操作ClearInt （）针对消息对象是 int array 还是int，其实现是不同的。在一个面向对象的多态性语言中，可能代替一个特定类型的类型的集合就是它的子类集合。
例如，图 5-1-5给出了 4个类的继承层次。使用这个继承结构，发送给多边形类的所有消息，它的所有子类都能够响应。又例如，想要在屏幕上画一系列多边形，多态性允许一个表的元素可以属于一组指定的类型而不仅仅是一个类型，可以认为这是一个类族。通过遍历这个表，发送给各个表元素以draw消息，画出所有的多边形。
图 5-1-5 4个类的继承层次
动态绑定把函数调用与目标代码块的连接延迟到运行时进行。这样，只有发送消息时才与接收消息实例的一个操作绑定。它与多态性可以使我们建立的系统更灵活，易于扩充。做为动态绑定的例子，考虑在多边形类中的方法contains ? （aPoint）。这个操作可以在类层次的各层重新实现，以有效利用各个子类的特殊的特征。例如，假定一个矩形有某些边与屏幕的边平行，这时，检查一个点是否包含在矩形内，比检查一个点是否在一个一般的四边形内的效率要高一些。
二、面向对象软件开发的分析模型
面向对象分析过程分为论域分析和应用分析。论域分析建立大致的系统实现环境，应用分析则根据特定应用的需求进行论域分析。
1.OOA分析的基本原则和任务
为建立分析模型，要运用如下的5个基本原则：①建立信息域模型；②描述功能；③表达行为；④划分功能、数据、行为模型，揭示更多的细节；⑤用早期的模型描述问题的实质，
用后期的模型给出实现的细节。这些原则形成OOA的基础。
OOA的目的是定义所有与待解决问题相关的类（包括类的操作和属性、类与类之间的关系以及它们表现出的行为）。为此，OOA需完成的任务是：
（1）软件工程师和用户必须充分沟通，以了解基本的用户需求；
（2）必须标识类（即定义其属性和操作）；
（3）必须定义类的层次；
（4）应当表达对象与对象之间的关系（即对象的连接）；
（5）必须模型化对象的行为；
（6）反复地做任务①～⑤，直到模型建成。
2.OOA概述
目前已经衍生许多种 OOA方法。每种方法都有各自的进行产品或系统分析的过程，有一组可描述过程演进的图形标识，以及能使得软件工程师以一致的方式建立模型的符号体系。现在广泛使用的OOA方法有以下几种：
（1） Booch 方法：Booch 方法包含“微开发过程”和“宏开发过程”。微开发过程定义了一组任务，并在宏开发过程的每一步骤中反复使用它们，以维持演进途径。Booch OOA 宏开发过程的任务包括标识类和对象、标识类和对象的语义、定义类与对象间的关系，以及进行一系列求精从而实现分析模型。
（2） Rumbaugh 方法：Rumbaugh 和他的同事提出的对象模型化技术（OMT）用于分析、系统设计和对象级设计。分析活动建立三个模型：对象模型（描述对象、类、层次和关系），动态模型（描述对象和系统的行为），功能模型（类似于高层的DFD，描述穿越系统的信息流）。
（3） Coad和Yourdon 方法：Coad和Yourdong方法常常被认为是最容易学习的OOA 方法。建模符号相当简单，而且开发分析模型的导引直接明了。其OOA过程概述如下：
〃使用“要找什么”准则标识对象；
〃定义对象之间的一般化∕特殊化结构；
〃定义对象之间的整体∕部分结构；
〃标识主题（系统构件的表示）；
〃定义属性及对象之间的实例连接；
〃定义服务及对象之间的消息连接。
（4） Jacobson方法：也称为OOSE（面向对象软件工程）。Jacobson方法与其他方法的不同之处在于他特别强调使用实例（use case）——用以描述用户与系统之间如何交互的场景。Jacobson方法概述如下：
〃标识系统的用户和它们的整体责任；
〃通过定义参与者及其职责、使用实例、对象和关系的初步视图，建立需求模型；
〃通过标识界面对象、建立界面对象的结构视图、表示对象行为、分离出每个对象的子系统和模型，建立分析模型。
（5） Wirfs―Brock 方法：Wirfs―Brock 方法不明确区分分析和设计任务。从评估客户规格说明到设计完成，是一个连续的过程。与Wirfs―Brock分析有关的任务概述如下：
〃评估客户规格说明；
〃使用语法分析从规格说明中提取候选类；
〃将类分组以表示超类；
〃定义每一个类的职责；
〃将职责赋予每个类；
〃标识类之间的关系；
〃基于职责定义类之间的协作；
〃建立类的层次表示；
〃构造系统的协作图。
（6）统一的OOA方法（UML）。统一的建模语言（UML）已经在企业中广泛使用，它把Booch、Rumbaugh和Jacobson 等各自独立的OOA和OOD方法中最优秀的特色组合成一个统一的方法。UML 允许软件工程师使用由一组语法的语义的实用的规则支配的符号来表示分析模型。
在UML中用5种不同的视图来表示一个系统，这些视图从不同的侧面描述系统。每一个视图由一组图形来定义。这些视图概述如下：
〃用户模型视图：这个视图从用户（在UML中叫做参与者）角度来表示系统。它用使用
实例（use case）来建立模型，并用它来描述来自终端用户方面的可用的场景。
〃结构模型视图：从系统内部来看数据和功能性。即对静态结构（类、对象和关系）模型化。
〃行为模型视图：这种视图表示了系统动态和行为。它还描述了在用户模型视图和结构模型视图中所描述的各种结构元素之间的交互和协作。
〃实现模型视图：将系统的结构和行为表达成为易于转换为实现的方式。
〃环境模型视图：表示系统实现环境的结构和行为。
通常，UML 分析建模的注意力放在系统的用户模型和结构模型视图，而UML设计建模则定位在行为模型、实现模型和环境模型。
第二节UML概述
一、UML的语言机制
在UML 诞生之前，面向对象领域已经涌现出了许多开发方法及相应的表示机制，它们各有千秋，却又有很多类似之处，往往让使用者无所适从。UML在这样的背景下应运而生。它主要以BOOCH 方法、OMT方法（71）和OOSE方法为基础，同时也吸收了其他面向对象建模方法的优点，形成一种概念清晰、表达能力丰富、适用范围广泛的面向对象的标准建模语言。
UML 通过图形化的表示机制从多个侧面对系统的分析和设计模型进行刻画。它共定义了10种视图，并将其分为如下4类：
（1）用例图（use case diagram）。从外部用户的角度描述系统的功能，并指出功能的执行者。
（2）静态图。包括类图（class diagram）、对象图（object diagram）和包图（pack diagram）。类图描述系统的静态结构，类图的节点表示系统中的类及其属性和操作，类图的边表示类之间的联系，包括继承、关联、依赖、聚合等。对象图是类图一个实例，它描述在某种状态下或在某一时间段，系统中活跃的对象及其关系。在对象图，一个类可以拥有多个活跃的对象实例。包图描述系统的分解结构，它表示包(package)以及包之间的关系。包由子包及类组成。包之间的关系包括继承、构成与依赖关系。
（3）行为图。包括交互图（interactive diagram）、状态图（statechar diagram）与活动图（activity diagram），它们从不同的侧面刻画系统的动态行为。交互图描述描述对象之间的消息传递，它又可分为顺序图（sequence diagram）与合作图（collaboration diagram）两种形式。顺序图强调对象之间消息发送的时间序。合作图更强调对象间的动态协作关系。合作图也可通过消息序号之间消息发送的时间序。只不过这种表示不如顺序图那样直观。状态图描述类的对象的动态行为，它包含对象所有可能的状态、在每个状态下能够响应的事件以
及事件发生时的状态迁移与响应动作。活动图描述系统为完成某项功能而执行的操作序例，这些操作序列可以并发和同步。活动图中包含控制和信息流。控制流表示一个操作完成后对其后操作的触发，信息流则刻画操作之间的信息交换。
（4）实现图（implementatin diagram）。包括构件图（component diagram）与部署图（deploymetn diagram），它们描述软件实现系统的组成和分布状况。构件图描述软件实现系统中各组成部件以及它们之间的信赖关系。一个部件可能是一个资源描述文件、一个二进制文件或一个可执行文件。构件图主要用于理解和分析软件各部分之间的相互影响程度。部署图描述作为软件系统运行环境的硬件及网络的物理体系结构，其节点表示实际的计算机和设备，边表示节点之间物理连接关系，也可显示连接的类型及节点之间的依赖性。在节点内部，可以放臵可执行部件和对象以显示节点与可执行软件单元之间的对应关系。部署图对于软件安装工程师有着重要的参考价值。
例如，图5-2-1表示某大学的课程注册管理系统包含3个用例：“课表维护”、“个人课程规划”和“选课学生花名册查询”。教务管理人员使用“课表维护”用例设臵或修改课程属性（课程的时间、地点、上课老师等）和增删课程；学生使用“个人课程规划”用例选课和修改自己的个人课表，收费管理系统根据每个学生的选课情况计算其应缴费用；老师使用“选课学生花名册查询”用例获取选定其所开课程的学生花名册。
图 5-2-1 课程注册管理系统的用例图
图 5-2-2表示前述的课程注册管理系统包含“教务管理人员”、“学生”、“老师”、“课程”、“课程设臵”、“课程注册表”、“课程注册管理器”和“课程管理器”8个类。前3个类为一般化的“用户”类的子类。一门“课程”可由一到多个“课程设臵”构成，例如，对于全校性的公共基础课，由于选修的学生太多，必须安排不同的老师、不同的教室和不同的时间段。“学生”、“老师”与“课程设臵”之间，“课程注册表”与“课程注册管理器”之间以及“课程注册管理器”与“课程”之间存在着关联关系。
图 5-2-2 课程注册管理系统的类图
图5-2-3通过UML顺序图刻画了“个人课程规划”用例中学生选课功能的实现过程。
图 5-2-3 用UML顺序图表示“个人课程规划”用例中的学生选课过程
图 5-2-4用UML协作图刻画学生选课过程，该图与图 5-2-3等价。
图 5-2-4 用UML协作图表示“个人课程规划”用例中的学生选课过程
图 5-2-5“课程设臵”对象的状态图。它表示每个“课程设臵”最多只能容纳50个选课学生。
图 5-2-5 UML状态图示例
本章的后继章节结合需求分析过程更具体地介绍UML的用例图、包图、类图和活动图，第八章将结合软件设计过程详细介绍顺序图、协作图、状态图和活动图。对其他UML 图形机制感兴趣的读者，以及希望进一步深入了解UML 及其软件开发方法的读者。
二、基于UML的软件开发过程
虽然UML是独立于软件开发过程的，即UML能够在几乎任何一种软件开发过程中使用，但是熟悉一种有代表性的面向对象的软件开发过程，并知悉UML 各语言要素在过程中不同阶段的应用，对于理解UML将大有裨益。
图 5-2-6表示一种迭代的渐进式软件开发过程，它包含4个阶段：初启、细化、构造和移交。
图 5-2-6 面向对象的迭代、渐进式软件开发过程
1.初启
在初启阶段，软件项目的发起人确定项目的主要目标和范围，并进行初步的可行性分析和经济效益分析。
2.细化
细化阶段的开始标志着项目的正式确立。软件项目组在此阶段需要完成以下工作：
（1）初步的需求分析。采用UML的用例描述目标软件系统所有比较重要、比较有风险的用例，利用用例图表示参与者与用例以及用例与用例之间的关系。采用UML 的类图表示目标软件系统所基于的应用领域中的概念之间的关系。这些相互关联的概念构成领域模型。领域模型一方面可以帮助软件项目组理解业务背景，与业务专家进行有效沟通；另一方面，随着软件开发阶段的不断推进，领域模型将成为软件结构的主要基础。如果领域中含有明显的流程处理成分，可以考虑利用 UML的活动图来刻画领域中的工作流，并标识业务流程中的并发、同步等特征。
（2）初步的高层设计。如果目标软件系统的规模比较庞大，那么经初步需求分析获得的用例和类将会非常多。此时，可以考虑根据用例、类在业务领域中的关系，或者根据业务领域中某种有意义的分类方法将整个软件系统划分为若干包，利用UML的包图刻画这些包及其间的关系。这样，用例、用例图、类、类图将依据包的划分方法分属于不同的包，从而得到整个目标软件系统的高层结构。
（3）部分的详细设计。对于系统中某些重要的或者比较高的用例，可以采用交互图进一步探讨其内部实现过程。同样，对于系统中的关键类，也可以详细研究其属性和操作，并在UML 类图中加以表现。因此，这里倡导的软件开发过程并不在时间轴上严格划分分析与设计、总体设计与详细设计，而是根据软件元素（用例、类等）的重要性和风险程度确立优先细化原则，建议软件项目组优先考虑重要的、比较有风险的用例和类，不能将风险的识别和解决延迟到细化阶段之后。
（4）部分的原型构造。在许多情形下，针对某些复杂的用例构造可实际运行的耐用消费品型是降低技术风险、让用户帮助软件项目组确认用户需求的最有效的方法。为了构造原型，需要针对用例生成详尽的交互图，对所有相关类给出明确的属性和操作定义。
综上所述，在细化阶段可能需要使用的UML 语言机制包括：描述用户需求的用例用用例图、表示领域概念模型的类图、表示业务流程处理的活动图、表示系统高层结构的包图和表示用例内部实现过程的交互图等。
细化阶段的结束条件是，所有主要的用户需求已通过用例和用例图得以描述；所有重要的风险已被标识，并对风险应对措施了如指掌；能够比较精确地估算实现每一用例的时间。
3.构造
在构造阶段，开发人员通过一系列的迭代完成对所有用例的软件实现工作，在每次迭代中实现一部分用例。以迭代方式实现所有用例的好处在于，用户可以及早参与对已实现用例的实际评价，并提出改进意见。这样可有效降低大型软件系统的开发风险。
在实际开始构造软件系统之前，有必要预先制定迭代计划。计划的制定需遵循如下两项原则：
（1）用户变为业务价值较大的用例应优先安排；
（2）开发人员评估后认为开发风险较高的用例应优先安排。
在迭代计划中，要确定迭代次数、每次迭代所需时间以及每次迭代中应完成（或部分完成）的用例。
每次迭代过程由针对用例的分析、设计、编码、测试和集成 5个子阶段构成。在集成之后，用户可以对用例的实现效果进行评价，并提出修改意见。这些修改意见可以在本次迭代过程中立即实现，也可以在下次迭代中再予以考虑。
构造过程中，需要使用UML 的交互图来设计用例的实现方法。为了与设计得出的交互图协调一致，需要修改或精化在细化阶段绘制的作为领域模型的类图，增加一些为软件实现所必需的类、类的属性或方法。
如果一个类有复杂的生命周期行为，或者类的对象在生命周期内需要对各种外部事件的刺激作出反应，应考虑用 UNL状态图来表述类的对象的行为。
UML的活动图可以在构造阶段用来表示复杂的算法过程和有多个对象参与的业务处理过程。活动图尤其适用于表示过程中的并发和同步。
在构造阶段的每次迭代过程中，可以对细化阶段绘出的懈图进行修改或精化，以便包图切实反映目标软件系统最顶层的结构划分状况。
综上所核对，在构造阶段可能需要使用的UML语言机制包括：
用例及用例图。它们是开发人员在构造阶段进行分析和设计的基础。
类图。在领域概念模型的基础上引进为软件实现所必需的类、属性和方法。
交互图。表示针对用例设计的软件实现方法。
状态图。表示类的对象的状态—事件—响应行为。
活动图。表示复杂的算法过程，尤其是过程中的并发和同步。
包图。表示目标软件系统的顶层结构。
构件图。
部署图。
4.移交
在移交阶段，开发人员将构造阶段获得的软件系统在用户实际工作环境（或接近实际的模拟环境）中试运行，根据用户的修改意见进行少量调整。
第三节基于UML的需求分析
在初步的业务需求描述已经形成的前提下，基于UML的需求分析大致可分为以下步骤：
（1）利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象；形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。
（2）利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。
上述两个步骤并没有时序关系，它们可以并行展开，如图5-3-1所示。
图 5-3-1 需求分析过程
本节将依次介绍上述步骤中涉及的UML语言机制，并结合“家庭保安系统”实例说明每步骤中基于UML的需求分析方法。
一、开发场景
场景是指从单个执行者的角度观察目标软件系统的功能和外部行为。这种功能通过系统与用户之间的交互来表征。因此也可以说，场景是用户与系统之间进行交互的一组具体的动作。相对于用例（见第五章第二节）而言，场景是用例的实例，而用例是某类场景的共同抽象。
对场景的完整描述应包含场景名称、执行者实例，前臵条件、事件流和后臵条件。
例如，“家庭保安系统”的初步需求描述：“家庭保安系统”的软件允许用户在安装时进行系统配臵，实施对传感器的监控并通过控制面板与用户进行信息交互。
配臵操作包括：
（1）指定每一传感器的种类和编号；
（2）设臵开、关机密码；
（3）指定报警电话电码；
（4）指定报警延迟和电话重拨延迟时间（以秒为单位）；
当软件系统收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。
开机后，软件系统负责显示当前工作状态，接收并处理用户指令。
根据以上描述，该系统具有“系统配臵”、“开机”、“关机”、“门窗监测”、“烟雾监测”和“复位”等场景。其中，门窗监测场景的具体描述如下：
场景名称：门窗监测。
参与执行者实例：警报器、报警电话、显示器和门窗监视器。
前臵条件：系统已开机。
事件流：
（1）门窗监视器发现门或窗户发生异动，向软件系统报告异常事件。
（2）软件系统启动警报器并拨报警电话号码。
（3）报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质（门窗异动）。
（4）系统在控制面板的显示器上显示报警时间及当前状态（报警：门窗异动）。
后臵条件：系统处于“报警”状态。
根据场景作用的不同，可以将其划分为以下类型：
（1）实际场景。对实际的业务处理流程或其优化流程的描述。实际场景是用户需求的重要组成部分。
（2）设想场景。分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。这种场景可视为一种纸面原型，主要用于帮助分析人员挖掘潜在的用户需求。
（3）评价场景。以确认需求或提出改进建议为主要目的的业务流程描述。评价场景可以在用例生成后用例进行实例化而形成，以便用户对用例进行评价或改进。
（4）培训场景。面向开发人员及用户解释系统的功能和外部行为的业务流程描述。
对以下问题的回答有助于分析人员获取场景：
（1）目标软件系统有哪些执行者？
（2）执行者希望系统执行哪些任务？
（3）执行者希望获得哪些信息？这些信息由谁生成？由谁修改？
（4）执行者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？
（5）系统将通告执行者哪些事件？
总之，确定执行者和场景的关键在于理解业务领域和初步需求描述文档。场景将促成开发人员和用户对业务处理流程和目标软件系统的功能范围的共同理解。在场景确定之后，通过对场景的汇总、分类归并和抽象即可形成用例。
二、生成用例
从外部用户的视角看，一个用例是执行者（actor）与目标软件系统之间的一次典型的交互作用。从软件系统内部的视角出发，一个用例代表系统执行的一系列动作，动作执行的结果能够被外部的执行者所察觉。执行者是指外部用户或外部实体在系统中扮演的角色。如果多个用户在使用目标软件系统时扮演同一角色，这些用户将由单一执行者表示。反之，如果一个用户扮演多种角色，则需要用多个执行者来表示同一用户。
对用例的完整描述包括用例名称、参与执行者、前臵条件、一个主事件流、零到多个辅事件流和后臵条件。主事件流表示正常情况下执行者与系统之间的信息交互及动作序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。显式地分隔主、辅事件流是为了使分析人员首先聚集于正常的业务处理流程，同时也便于用例的读者理解业务需求。
用例主要来源于分析人员对场景的分类和抽象，即将相似的场景进行归并，使一个用例可以通过实例化和参数调节而涵盖多个场景。例如，“家庭保安系统“中的“开机”、“关机”、“复位” 3个场景可以归并为“命令处理”，3 个场景之间的差异通过用户命令种类的不同而体现。类似地，“门窗监测”、“烟雾监测”两个场景也可归并为统一的“传感器监测”用例。其实，对于熟悉业务领域的分析师而言，也可以略过场景，直接从业务需求描述中获取用例。
在“家庭保安系统”中，执行者有“用户”、“传感器”、“报警电话”和“显示器”，用例有“系统配臵”、“命令响应”和“传感器监测”。下面以“传感器监测”为例说明用例的一般描述格式：
用例名称：传感器监测。
参与执行者：各类传感器、警报器、报警电话和显示器。
前臵条件：系统已开机。
主事件流：
（1）传感器向目标软件系统上报其监测数据，系统判别监测数据是否正常。
（2）如果不正常，系统启动警报器，拨报警电话号码。
（3）报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质。
（4）系统在控制面板的显示器上显示报警时间及当前状态（报警）。
辅事件流：
（1）如果报警电话无人接听，则按照重拨延迟反复拨号，直至电话接通，再转入主事件流的步骤（3）。
（2）如果重拨次数达到系统预设的最大次数，电话仍无人接听，则跳过主事件流的步骤（3），转入步骤（4）。
后臵条件：如果已发现异常监测数据，系统处于“报警“状态；否则，系统处于正常的监测状态。
三、用活动图表示用例
用例的描述既可采用自然语言，也可采用活动图。后一种表示法更为精确和直观。下面首先介绍活动图的语法机制，然后结合实例说明如何用活动图表示用例。
1.UML活动图
用例的事件流或操作均表示为一系列的活动，每个活动在活动图中被表示为一个节点。节点之间的有向边表示活动的执行顺序。在节点间的连接边上可以附加条件表达式，以表示在有向边的源节点执行完成后，如果条件成立，则开始执行有向边的目标节点所表示的活动；如果条件不成立，则目标节点的活动不被执行。条件表达式一般出现在以菱形为源节点的有向边上。菱形在活动图中属特殊节点，用来表示条件判断。例如，在图 5-3-2中，“密码验证”活动的有向边上。如果“（密码正确）”，则开始“开始选择功能”活动；否则，回到“输入密码“活动。
图 5-3-2 典型的活动图
活动图还可以表示处理过程的并发。活动图的同步条（水平或垂直粗线）可以将一条有向边分叉为多个并发执行的分支进程，或将多个有向边上的进程同步合并为一个进程。例如，在图 5-3-2中，当用户选择取款操作，输入取款金额，且系统验证其要求的金额小于等于余额之后，系统分叉为两个并发进程：点钞、出钞和扣减余额、打印交易信息。此后，再合并为一个进程，进行“选择功能”活动。
为了描述活动的责任对象，活动图引进了“泳道”的概念。泳道是由垂直长线分割出来的矩形区域，在泳道上方的对象负责该矩形区域内的所有活动。例如，在图 5-3-2中，类
“ Customer ”的对象负责“插入银行卡”、“输入密码”、“选择功能”和“输入金额” 4 项活动，其余活动由类“ATMsystem”的对象负责。
2.用例的活动图表示
针对前面所述的“传感器监测”用例，其活动图表示如图5-3-3所示。
图 5-3-3 “传感器监测”用例的活动图表示
四、生成用例图
执行者与用例之间的关系有两例种：触发执行与信息交换。执行者与用例之间可能兼具这两种关系，例如，“在家庭保安系统”中，执行者“用户”在触发用例“命令响应”的同时，还要向用例传送命令信息。
在 UML用例图中，从执行者指向用例的边表示触发执行和／或信息交换，从用例指向执行者的边则表示用例将其生成的信息传递给执行者。
UML的用例与用例之间存在如下两种关系：
（1）使用（use）关系。如果有一个公共的动作序列存在于多个用例中，为避免重复，并使需求模型更简洁，可以将公共动作序列抽出来构成新的独立用例。这样，原来的多个用例与新的用例之间便通过使用关系来连接。例如，在“家庭保安系统”中“系统配臵”和“命令响应”两个用例使用公共的“密码验证”子用例。
（2）扩展（extend）关系。如果一个用例的动作序列完全包含另一个用例的动作序列，且前者含有后者所不具备的一些特殊情况下的处理动作，则称前者扩展后者。例如，图 5-3-4的“传感器监测”用例仅包含正常的处理流程，而“报警电话未接通”用例除正常流程处还增加了“重复拨号”以及“重拨次数达到最大次数仍无人接听”这两种异常处理动作。
图 5-3-4 “家庭保安系统”的用例图
五、建立顶层架构
顶层架构的主要目的是为后续的分析和设计活动建立一种结构和分划，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推进，框架中的内容不断丰富、翔实，最终演进为完整的面向对象软件结构。
UML 包图是表示顶层架构的适当机制，因此，下面首先介绍包图的语法机制，然后探讨建立顶层架构的方法与原则。
1.UML包图
包是UML 对类进行分组的一种机制。可以从某种视角将具有比较密切的关联的一些类划分为一个包，分属于不同包的两个类之间的关联则比较松散。由此可见，对于大型软件系统而
c++面向对象课程设计报告
课程设计报告 课程名称面向对象程序设计 课题名称学生成绩管理系统 专业计算机科学与技术 班级计算机 1001 学号 01 姓名 指导教师李珍辉陈淑红李杰军 2011年 12 月 28 日
湖南工程学院 课程设计任务书 课程名称面向对象程序设计 课题学生成绩管理系统 专业班级计算机1001 学生姓名 学号 01 指导老师李珍辉陈淑红李杰军 审批 任务书下达日期 2011 年 11 月 15 日 任务完成日期 2011 年 12 月 28 日
一、设计内容与设计要求 1.课程设计目的： 面向对象程序设计课程设计是集中实践性环节之一，是学习完《面向对象程序设计》课程后进行的一次全面的综合练习。要求学生达到熟练掌握C++语言的基本知识和技能；基本掌握面向对象程序设计的思想和方法；能够利用所学的基本知识和技能，解决简单的面向对象程序设计问题，从而提高动手编程解决实际问题的能力。 2.课题题目 1）公司库存管理系统 2）高校学籍管理系统 3）高校工资管理系统 4）高校人事管理系统 5）通讯录程序设计 6）学生成绩管理系统 7) 图书管理系统 8）文本编辑器的设计与实现 9）学生考勤管理系统 10）公司人员管理系统 3．设计要求： ⑴设计课题题目：每位同学根据自己学号除以10所得的余数加1选择相 应题号的课题。随意换题者不记成绩。 ⑵根据自己对应的课题完成以下主要工作：①完成系统需求分析：包括 系统设计目的与意义；系统功能需求（系统流程图）；输入输出的要求。②完 成系统总体设计：包括系统功能分析；系统功能模块划分与设计（系统功能模 块图）。③完成系统详细设计：包括数据库需求分析；数据库概念结构设计（E －R图）；数据库逻辑结构设计；类层次图；界面设计与各功能模块实现。④系 统调试：调试出现的主要问题，编译语法错误及修改，重点是运行逻辑问题修 改和调整。⑤使用说明书及编程体会：说明如何使用你编写的程序，详细列出 每一步的操作步骤。⑥关键源程序（带注释）
银行计算机储蓄系统面向对象需求分析
面向对象需求分析【银行计算机储蓄系统】 学院：信息工程学院 班级：计科1202 学号：121404219 姓名：汤鑫 指导老师：田怀凤 （扬州大学2014－2015 学年第一学期）
目录 1．基本要求 (2) 1.1 功能要求 (2) 1.2 性能要求 (2) 1.3 接口要求 (2) 1.4 输入要求 (2) 1.5 输出要求 (2) 2.需求分析 (3) 2.1编写目的 (3) 2.2系统背景 (3) 2.3功能需求 (3) 2.4用例分析 (3) 2.5性能需求 (5) 2.5.1 数据精确度 (5) 2.5.2时间特性 (5) 2.5.3适应性 (5) 3.静态结构模型 (5) 3.1类与对象 (5) 3.2类图的建立 (5) 4.动态行为模型 (6) 4.1顺序图 (6) 4.2状态图 (9) 4.3活动图 (9) 5.建立功能模型 (10)
1．基本要求 1.1 功能要求 银行计算机储蓄系统的主要功能有两方面：储户填写存款单或取款单交给业务员键入系统。 如果是存款则系统记录存款人姓名、住址（或电话号码）、身份证号码、存款类型、存款日期，到期日期，利率以及密码（可选）等信息，并引出存款单给储户。 如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息，并印出利息清单给储户。 1.2 性能要求 为了满足储户的要求，系统必须要有高的运作速度，储户填写的表单输入到系统，系统必须能快速及时作出响应，迅速处理各项数据、信息，显示出所有必需信息并打印出各项清单，所以要求很高的信息量速度和大的主存容量；由于要存贮大量的数据和信息，也要有足够大的磁盘容量；另外，银行计算机储蓄系统必须有可靠的安全措施，以保证储户的存储安全。 1.3 接口要求 业务员键入储户的资料要全部一直显示在屏幕上；储户键入密码到系统以核对；计算机与打印机有高速传输的连接接口，最后以纸张的形式打印出清单给储户。 1.4 输入要求 业务员从存取款表单输入数据，要迅速精确，适当调整输入时间，不能让客户等太久，但也不能让业务员太过忙碌以免影响正确率，造成用户损失。 1.5 输出要求 要求快速准确地打印出存款或取款清单给客户。
面向对象_补充案例
案例3-1 定义学生类 一、案例描述 1、考核知识点 编号：00103002 名称：类和对象 2、练习目标 掌握类定义的方式 掌握如何在类中定义成员变量和成员方法 3、需求分析 在面向对象的思想中最核心就是对象，在程序中创建对象的前提是需要定义一个类。为了让初学者掌握类的定义方式，本案例将设计一个表示学生的类，该类具有表示姓名的属性name和表示年龄的属性age，同时还具有表示说话行为的方法speak()，用于输出学生的姓名和年龄。 4、设计思路（实现原理） 1）使用class关键字定义一个表示学生类型的类，类名为Student。 2）在Student类中定义两个成员变量name和age，分别用来表示姓名和年龄。其中，name的数据类型为String，变量age的数据类型为int。 3）在Student类中定义一个表示说话行为的speak()方法，用于输出学生的姓名和年龄。二、案例实现 class Student{ String name; int age; void speak() { "我的名字是 "+name+"，今年 "+age+"岁"); } } 三、案例总结 1、Java语言严格区分大小写，class和Class是不同的，在定义类时只能使用class关键字 2、在Student类中，成员变量name是String类型，String表示一个字符串，后面的章节会详细讲解 3、思考一下：自己定义一个手机(Phone)类，在类中定义品牌(brand)和价格(price)属性，定义打电话的call()方法，代码如下所示 public class Phone { String brand; double price; void call(){
需求分析报告模板
需求分析报告模板文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
需求分析报告模板 科技信息中心 二○一一年五月二十日
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。
1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ●正文风格； ●提示方式； ●重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ●领导层及管理人员； ●开发人员； ●项目经理； ●项目的最终用户； ●测试人员； ●文档编写人员。 ●其他经许可阅读此文档的人员 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
第3章面向对象(上)_补充案例
第三章补充案例 案例3-1 定义学生类 一、案例描述 1、考核知识点 编号：00103002 名称：类和对象 2、练习目标 掌握类定义的方式 掌握如何在类中定义成员变量和成员方法 3、需求分析 在面向对象的思想中最核心就是对象，在程序中创建对象的前提是需要定义一个类。为了让初学者掌握类的定义方式，本案例将设计一个表示学生的类，该类具有表示姓名的属性name和表示年龄的属性age，同时还具有表示说话行为的方法speak()，用于输出学生的姓名和年龄。 4、设计思路（实现原理） 1）使用class关键字定义一个表示学生类型的类，类名为Student。 2）在Student类中定义两个成员变量name和age，分别用来表示姓名和年龄。其中，name的数据类型为String，变量age的数据类型为int。 3）在Student类中定义一个表示说话行为的speak()方法，用于输出学生的姓名和年龄。二、案例实现 class Student{ String name; int age; void speak() { "我的名字是 "+name+"，今年 "+age+"岁"); } } 三、案例总结 1、Java语言严格区分大小写，class和Class是不同的，在定义类时只能使用class关键字 2、在Student类中，成员变量name是String类型，String表示一个字符串，后面的章节会详细讲解 3、思考一下：自己定义一个手机(Phone)类，在类中定义品牌(brand)和价格(price)属性，定义打电话的call()方法，代码如下所示
public class Phone { String brand; double price; void call(){ "hi,how are you doing"); } } 案例3-2 同一对象被多个变量引用 一、案例描述 1、考核知识点 编号：00103003 名称：对象创建与使用 2、练习目标 掌握如何创建类的对象 掌握如何使用两个或者多个变量引用同一个实例对象。 3、需求分析 在程序中，一个对象可能在多处使用，这样就可能需要有多个变量来引用这个对象。为了让初学者更好地掌握对象的创建和使用，本案例将基于案例3-1，创建三个学生对象，它们的引用变量分别是s1、s2和s3，首先分别使用s1和s2引用，为name和age赋值，然后调用speak()方法，最后将s2变量赋值给s3， s3也调用speak()方法。 4、设计思路（实现原理） 1）编写Example01类 2）在main()方法中，创建Student类的第一个对象，其引用变量为s1，使用s1调用name和age 变量分别为它们赋值为“张三”和“19”，然后调用speak()方法。 3）创建Student类的第二个对象，其引用变量为s2，使用s2分别为name和age赋值为“李四” 和“20”，然后调用speak()方法。 4）创建Student类的第三个对象，其引用变量为s3，将s2的值赋给s3，然后使用s3调用speak()方法。 二、案例实现 public class Example01 { public static void main(String [] args) { Student s1 = new Student(); ="张三"; =19; (); Student s2 = new Student();
第10章面向对象讲解
第10章面向对象分析 10.1面向对象分析的基本过程 不论采用哪种软件工程方法开发软件，需求分析的主要工作都是：理解需求、表达需求和验证需求，下面的图概括地表示了参照当前系统建立目标系统的过程。 图：参照当前系统建立目标系统 面向对象分析（Object-Oriented Analysis,简称OOA）的关键就是识别出对象与类，并分析它们之间的关系，最终建立对象模型、动态模型和功能模型。
10.1.1 概述 系统分析员要善于学习、勇于实践,更重要的是一切从实际出发。 [[注注]]“OOA 就是抽取和整理用户需求并建立问题域精精确确模模型型的过程。”（P231）——这在一开始能做到吗？——扯蛋 10.1.2 3个子模型与5个层次 面向对象建模需建立包含系统的三个要素：1）静态结构（对象模型）、2）交互次序（动态模型）、3）数据交换（功能模型）。 建立系统模型的过程是一个迭代（iterations ）式的自顶向下的求精过程。对于一个大型复杂系统来说对对象象模模型型一般由下述5个层次组成：
图10.2 复杂问题的对象模型的5个层次 其中主题层是指从一个更高（高于“类”）的抽象层次来描述对象模型（即从一个相当高的层次上描述总体模型），通过划分“主题”把一个复杂系统的对象模型分解成几个不同的概念范畴。 其实上述5个层次就是OOA中建立对象模型的5项主要工作：找出类和对象，识别结构（类或对象之间的关系），识别主题、定义属性、定义服务。我们知道动态模型和功能模型中都包含了对象模型中的操作，因此人们在定义每个类中的服务前，往往先建立起动态模型和功能模型，这样说来OOA大体上可按下列顺序进行： （1）确定类和对象 （2）确定关联 （3）划分主题 （4）定义属性 （5）确定继承关系 （6）建立动态模型
面向对象需求分析文档
项目名称Array（The English Name） 《面向对象需求分析课程文 档》 } { ` XXX项目小组
修订表
审批记录 …
目录 1.引言 ................................................................................................................................. 错误!未定义书签。 目的............................................................................................................................... 错误!未定义书签。 适用范围....................................................................................................................... 错误!未定义书签。 参考资料....................................................................................................................... 错误!未定义书签。 术语和缩略语............................................................................................................... 错误!未定义书签。 2.系统概述 ......................................................................................................................... 错误!未定义书签。 产品描述....................................................................................................................... 错误!未定义书签。 产品功能....................................................................................................................... 错误!未定义书签。 《 一般约束....................................................................................................................... 错误!未定义书签。 3.功能性需求分类 .............................................................................................................. 错误!未定义书签。 功能描述1 .................................................................................................................... 错误!未定义书签。 功能描述2 .................................................................................................................... 错误!未定义书签。 4.产品的非功能性需求 ...................................................................................................... 错误!未定义书签。 外部接口说明............................................................................................................... 错误!未定义书签。 用户接口................................................................................................................... 错误!未定义书签。 软件接口................................................................................................................... 错误!未定义书签。 性能需求....................................................................................................................... 错误!未定义书签。 硬件的限制............................................................................................................... 错误!未定义书签。 ^ 属性............................................................................................................................... 错误!未定义书签。 友好性....................................................................................................................... 错误!未定义书签。 安全性....................................................................................................................... 错误!未定义书签。 可维护性................................................................................................................... 错误!未定义书签。 可转移/换性 ............................................................................................................. 错误!未定义书签。 系统的运行环境 ....................................................................................................................... 错误!未定义书签。 其他需求....................................................................................................................... 错误!未定义书签。 用户操作需求........................................................................................................... 错误!未定义书签。附录A：需求确认................................................................................................................... 错误!未定义书签。 。
需求分析简单题
需求分析复习重点 考试简答题重点： 一、软件需求从层次上分哪三类？业务、用户、系统 业务需求：抽象层次最高的需求，是系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统； 用户需求：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。表达了用户对系统的期望。 系统需求：用户对系统行为的期望，一系列的系统需求联系在一起可以帮助用户完成任务，达成用户需求，进而满足业务需求；可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。 业务需求——目标（最高层次） 用户需求——具体任务 系统需求——系统行为 联系：业务需求可以明确系统的最终目标和努力方向，进而指导具体的需求获取活动，发现用户需求；用户需求经过明确和细化的处理，可以转化为系统需求。 二、软件需求分哪几种活动？ 包括需求开发和需求管理 需求开发4（获取、分析、规格说明，需求验证）+1（需求管理：版本管理，追踪，控制） 软件需求工程分为需求开发和需求管理两部分 1、需求开发的任务可进一步细分为4点 需求获取（是从人、文档或者环境当中获取需求的过程） 分析（建模来整合各种信息） 规格说明（获取的需求需要被编写成文档，在系统涉众之间交流需求信息） 验证（确保需求规格说明文档能正确、准确的反映用户的意图） 2、需求管理 保证需求作用在整个软件的产品生命周期中的连续、稳定和有效发挥 需求管理子活动有以下3点： 建立和维护需求基线集 建立需求跟踪信息 进行变更控制
三、需求获取有哪几种方法？（要举例）传统方法、集体获取方法、认知方法、采样… 1．传统方法 问卷调查、面谈、硬数据分析、文档检查、需求剥离等 2.集体获取方法 头脑风暴（Brainstorming）、专题讨论会（Workshop）、JAD等 3.认知方法 任务分析（Task Analysis）、协议分析（Protocol Analysis）等 4.采样 随机采样、分层采样 5.原型 书面描绘、幻灯片演示、程序代码 6.基于上下文的方法 观察、民族志（Ethnography）和话语分析（Conversation Analysis） 四、分析建模有哪几种常见的手段，分别举例（ppt有） 1、结构化需求分析建模 过程建模（过程建模以DFD为中心，结合使用微规格说明、数据字典、ERD、FDD、PDD等技术一起完成结构化分析的建模任务） 数据建模（模型建立：ERD） 2、面向对象需求分析建模：它以UML为基础，综合使用了多种不同的分析技术，主要有：对象模型、用例模型、行为模型、状态机模型、对象约束语言。CRC方法是面向对象分析在处理复杂问题时的手段，但是它需要了解很多的建模知识才足以进行 五、简述统一过程，画图UP，简述他的思想特点（重点）（p49） 统一过程（Unified Process，UP) 是风险驱动的、基于用例技术的、以架构为中心的、迭代的、可配置的软件开发流程。 (以用例驱动开发过程，以系统体系结构为中心，以质量控制和风险管理为目标，采用反复（迭代、循环）、渐增式的螺旋式开发过程)
面向对象分析方法
https://www.360docs.net/doc/5e16414016.html,面向对象分析方法1/2 面向对象分析方法（Object-Oriented Analysis，OOA），是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。 OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。分类结构就是所谓的一般与特殊的关系。组装结构则反映了对象之间的整体与部分的关系。 OOA在定义属性的同时，要识别实例连接。实例连接是一个实例与另一个实例的映射关系。 OOA在定义服务的同时要识别消息连接。当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。 OOA 中的5个层次和5个活动继续贯穿在OOD（画向对象的设计）过程中。OOD模型由4个部分组成。它们分别是设计问题域部分、设计人机交互部分、设计任务管理部分和设计数据管理部分。 一、OOA的主要原则。 (1)抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫作抽象。抽象是形成概念的必须手段。 抽象原则有两方面的意义：第一，尽管问题域中的事物是很复杂的，但是分析员并不需要了解和描述它们的一切，只需要分析研究其中与系统目标有关的事物及其本质性特征。第二，通过舍弃个体事物在细节上的差异，抽取其共同特征而得到一批事物的抽象概念。 抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。 过程抽象是指，任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操作完成的。 数据抽象是根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么，而不必知道它如何做。 (2)封装就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。 (3)继承：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。 在OOA中运用继承原则，就是在每个由一般类和特殊类形成的一般—特殊结构中，把一般类的对象实例和所有特殊类的对象实例都共同具有的属性和服务，一次性地在一般类中进行显式的定义。在特殊类中不再重复地定义一般类中已定义的东西，但是在语义上，特殊类却自动地、隐含地拥有它的一般类（以及所有更上层的一般类）中定义的全部属性和服务。继承原则的好处是：使系统模型比较简练也比较清晰。 (4)分类：就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述时的一种表现形式。 (5)聚合：又称组装，其原则是：把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。 (6)关联：是人类思考问题时经常运用的思想方法：通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。
面向对象分析与设计_期末复习_2017-2018-2
《面向对象分析与设计》期末复习 2017-2018学年-第2学期 1、题型介绍: 选择题20 * 1分= 20分 填空题5* 2分= 10分 简答题 4 * 7分= 28分 建模分析论述题4题（第1题10分，第2题8分，第3题8分，第4题16分，共42分）= 40分 2、选择题 1、（）不是对象具有的特性。 A.标识 B.继承 C.顺序 D.多态性 2、封装是把对象的（）结合在一起，组成一个独立的对象。 A.属性和操作 B.信息流 C.消息和事件 D.数据的集合 3、（）不是面向对象的典型方法。 A.Coad& Yourdon 方法 B.维也纳方法 C.OMT方法 D.Booch方法 4、UML中有4种关系，分别是依赖、泛化、关联和（） A.集成 B.合作 C.实现 D 抽象 5、下列关于状态图的说法中，正确的是（） A.状态图是UML中对系统的静态方面进行建模的5种图之一。 B.状态图是活动图的一个特例，状态图中的多数状态是活动状态。 C.状态图是对一个对象的生命周期进行建模，描述对象在其生存期间的动态行为。 D.状态图强调对有几个对象参与的活动过程建模，而活动图更强调对单个反应型对象建模。 6、UML的（）模型图由类图、对象图、包图、组件图、和部署图组成。 A.用例 B.静态 C.动态 D.系统。 7、UML的（）模型图活动图、顺序图、状态图、写协作图组成。 A.用例 B.静态 C.动态 D.系统。 8、UML的最终产物就是最后提交的可执行的软件系统和（） A.用户手册 B.类图 C.动态图 D.相应的软件文档资料
9、在UML的需求分析建模中，（）模型图必须与用户反复交流并加以确认。 A.配置 B.用例 C.包 D.动态 10、下面不是用例之间主要关系的是（） A.扩展 B.包含 C.依赖 D.泛化 11、对于一个电子商务网站而言，以下不适合作为用例的选项是（） A.登录 B.预定商品 C.购物车 D.结账 12、UML的客户需求分析模型包括（）模型、类图、对象图和活动图。 A.用例 B.静态 C.动态 D.系统 13、UML客户需求分析产生的用例模型描述了系统的（） A.状态 B.体系结构 C.静态模型 D.功能要求 14、在UML的需求分析模型中，用例建模必须与（）反复交流并加以确认。 A.软件生产商 B.用户 C.软件开发人员 D.问题领域的专家 15、在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（） A.活动图 B.状态图 C.配置图 D.组件图 16、类图应该画在Rational Rose的（）视图中。 A、Use Case View B、Login View C、Component View D、Deployment View 17、类通常可以分为实体类、（）和边界类。 A 、父类B、子类C、控制类D、祖先类 18、对象特征的要素是（）。 A、状态 B、行为 C、标识 D、属性 19、下列关于接口的关系说法不正确的是（）。 A、接口是一种特殊的类 B、所有接口都是有构造型<
面向对象建模案例
例：超市进销存系统的需求描述如下： （1）销售 ①售货员接收顾客订购，输入顾客购买的商品，计算总价； ②顾客付款并接收清单； ③售货员保存顾客购买商品的记录清单。 （2）库存 ①库存管理员每天进行盘点一次； ②库存管理员当发现库存商品有损坏时，及时到相关部门报损； ③在供应商的商品到货时，库存管理员首先检查商品是否合格，并将合格的商品入库处理；当商品进入卖场时，进行商品出库处理； ④经理、订货员根据需要进行库存商品的模糊查询或详细查询。 （3）订货 ①订货员用新商品供应商信息更新供应商数据库的信息； ②订货员统计库存商品是否低于库存下限，然后制作订货单。 （4）统计 ①经理能够使用系统的统计功能，了解商品销售情况、库存情况、供应商情况，以便进行合理的营销策略。 ②经理按市场情况适时变动商品价格。 试建立超市进销存系统的用例模型。 顾客 图1 销售子系统
商品出入库 图2 库存子系统 制作订货单图3 订货子系统用例模型
特殊商品查询 图4 统计子系统用例模型 思考？？在用例图中的用例通常只是简单地给出了系统应提供什么服务，并没有展示出如何提供服务，如服务的具体功能、处理流程、场景、出错情况以及异常情况等信息，如何能知道前述信息？ ！！！用例的描述常采用文字列表形式，也可采用UML图形描述，如交互图、活动图等。 3.试为以下各类建立UML类图及描述它们间的关系。 家用电器、电视机、液晶电视机、电视遥控器、DVD播放机、组合音响、音响功放、音箱、喇叭、低音泡、高音泡、厨具、电厨具、微波炉、电磁炉、电饭煲
销售管理子系统的部分用例描述：
面向对象报告
一、需求描述 该超市的系统组成主要由以下几个部分，其中各个部分有不同的参与者情况，每个部分主要针对一个或一系列功能设计： （1）收银管理系统。该部分的参与者主要是收银人员，同时该部分是与库存管理以及业务管理直接关联的。收银的业务操作直接対库存管理以及业务管理进行影响。其中的类比如收银单、条形码、商品细项等。收银部分中的一些实体类是与其他部分中的实体类共通的。每次收银操作，都会生成业务信息，影响营业额、订单数、收银人员工作记录等。 （2）线上订单系统。该部分的参与者主要是后台管理人员以及会员顾客。这个部分是一个自身功能较为完整，依赖性较小的部分，其中一些重要的类比如线上订单、购物车、商品细项。 可以明确的如线上订单和收银部分的收银单都可以是业务管理中业务记录这种抽象接口的具体实现实体类，也就是继承泛化，并拓展自己额外的属性。 线上订单系统的时序流程会比较复杂，类似课程教授的的购车用例。该部分是会员顾客与订单系统的交互，同时也会涉及对业务管理的、库存管理的变动，这种变动是对其底层实体类的具体存储参数的修改。通过订单系统种的功能函数实现。 （3）人员管理系统是另一个重要的系统组成。该部分的参与者主要是后台管理人员和顾客会员。这里要区分的是后台管理人员参与者以及后台管理人员类。后者是系统中的一项组成，用于实现数据记录和某些功能，而前者是角色。 人员管理中最重要的三个实体类分别是后台人员、收银人员以及顾客会员。这里暂时不考虑超市的其他员工，因为收银人员在收银系统中扮演重要地位，其收银记录，对业务管理的底层数据都有影响。 人员管理主要分为两种，一种是后台人员的编辑、添加、删除。这种管理适用于三个主要实体类。而顾客会员类存在注册函数，也就是说该部分的参与者是顾客会员自身，顾客会员类信息是需要自身编辑的。该系统主要是对系统中的角色类进行管理，对角色类进行实现增、删、查、改。同时也会附加权限的管理。 （4）库存管理系统主要是后台管理人员参与，细化的功能为商品入库、商品出库，库存紧缺提醒等，库存管理的部分依赖于商品管理部分，也就是说该部分主要是对商品细项类中的数量特性进行操作。库存操作将影响将直接影响到线上订单系统的界面类的商品展示情况，也会影响到超市的铺货情况，这里铺货的流程被省略，将货架铺货商品量与库存量合并，即线下顾客无法在收银系统中登记库存为0的商品，以此简化流程。库存管理中，比较重要的实体类应有商品库存、入库记录、出库记录等。 （5）商品管理系统主要是后台人员参与，该部分的重要实体类是商品细项类，这个类有这众多的特性，用来记录商品的各项属性。这个部分的主要功能即记录商品信息，不论库存管理、收银系统、线上订单系统皆与这个部分有直接联系，他们对商品的识别都需要查询商品管理部分的存储再数据库的商品细项类。而部
面向对象程序设计期末复习分析
一、单项选择题( 在每小题的四个备选答案中，选出一个正确答案，并将正确答案的序号填在题干的括号内。每小题1 分，共20 分) 3．下列不属于面向对象技术的基本特征的是（B）。 A. 封装性 B. 模块性 C. 多态性 D. 继承性 4. 面向对象程序设计将描述事物的数据与(C ) 封装在一起,作为一个相互依存、不可分割的整体来处理。 A. 信息 B. 数据隐藏 C. 对数据的操作 D. 数据抽象 5. 关于面向对象方法的优点，下列不正确的叙述是（C ）。 A. 与人类习惯的思维方法比较一致 B. 可重用性好 C. 以数据操作为中心 D.可维护性好 8. 下列不属于类的成员函数的是( C )。 A. 构造函数 B. 析构函数 C. 友元函数 D. 拷贝构造函数 9. 继承机制的作用是( C )。 A. 信息隐藏 B. 数据封装 C. 派生新类 D. 数据抽象 14. （D ）是从用户使用系统的角度描述系统功能的图形表达方法。 A. 类图 B. 对象图 C. 序列图 D. 用例图 15. (C ) 是表达系统类及其相互联系的图示,它是面向对象设计的核心，建立状态图、协作 图和其他图的基础。 A．对象图 B. 组件图 C. 类图 D. 配置图 16.（D ）描述了一组交互对象间的动态协作关系，它表示完成某项行为的对象和这些对 象之间传递消息的时间顺序。 A．对象图 B. 协作图 C. 状态图 D. 序列图 17.（D ）就是用于表示构成分布式系统的节点集和节点之间的联系的图示，它可以表示 系统中软件和硬件的物理架构。 A. 组件图 B. 协作图 C. 状态图 D. 配置图 18. 在用UML进行数据库的分析与设计过程中，( B ) 就是进行数据库的需求分析，使用用 例图、类图、顺序图、活动图等建立业务模型。 A. 逻辑数据模型设计 B 业务Use Case模型设计 C. 物理数据模型设计 D. 物理实现设计 19. 使用UML进行关系数据库的（B ）时，需要设计出表达持久数据的实体类及其联系，并把它们映射成为关系数据库表（Table)、视图(View)等。 A. 业务Use Case模型设计 B. 逻辑数据模型设计 C. 物理数据模型设计 C. 物理实现设计 20. UML的动态建模表示包含（C ）种图。 A. 9 B. 5 C. 4 D. 2 二、填空题( 每空1 分，共20 分) 1. 面向对象开发方法一改过去传统的以_功能分析，面向过程_为基础的_对象_的结 构化分析与设计方法，它模拟人们理解和处理客观世界的方式来分析问题，把系统视为
#图书馆信息系统面向对象分析实例
图书馆信息系统面向对象分析实例。 总体问题的陈述：本项目的目的是创建一个用于对图书馆的图书进行管理的图书管理系统。 该项目的用户：该项目的用户是一个某大学的图书馆，它负责对其顾客提供图书借阅服务。 该项目的目标：总体上来说，项目的目标是提高图书管理的自动化水平，为图书业务过程提供更快捷的、更好的和更准确的服务。具体来讲，系统的目标包括：为借书者提供快速借书的服务；进行快速准确的图书和借书者的信息维护；图书管理和查询的自动化。 该系统的功能：系统功能是系统应该做的事情，例如系统提供的预定功能。应该识别出这些功能并把它们列入到逻辑相关联的功能组中。 注意：要验证某一个描述是否真是一个系统的功能，如下的判断语句应该成立： 系统应该做某一个描述 例如，系统应该做图书的预定。 然而，系统的属性是系统的非功能性的特性，这些非功能性特性和系统功能经常被混淆。例如，“易于使用”就是一个非功能性的特性。它是不符合我们上述的验证语句：“系统应该做易于使用”。系统属性不应该是功能规格说明书中的一部分，而应该是一个单独的系统属性规格说明文档。 对于系统的功能，我们应该对其分类，以便区分开各类功能的优先次序和识别出哪些是理所当然应该具备的系统功能。功能的分类包括： 明显的：应该履行的功能，并且用户应该知道这个功能是否已经被履行。 隐藏的：应该履行的功能，但功能的履行对用户不可见。很多使用底层技术的服务确实符合这种情况，例如，将数据保存到一个持久化存储机构中。隐藏的功能经常在采集需求的过程中被遗漏。 修饰性的：可选的，增加这些功能不会对成本和其它系统造成重要影响。 为此，我们给出该系统的借书基本功能如下： F1.1记录借出的图书----借阅事件明显的 F1.2 查找书库中是否存在这种图书明显的 F1.3 从借书卡中读取借书者信息，并校验该信息明显的 F1.4 查找书库中这本书是否还有副本隐藏的 F1.5 当一次借阅完成后，削减该书的副本存书数量隐藏的 F1.6 管理员要使用系统，必须输入ID号和密码才行明显的 F1.7 查询显示借书信息明显的 F1.8 提供一个持久化存储机制隐藏的 F1.9 提供过程间的和系统间的通信机制隐藏的 系统属性：系统属性是系统的特性，它们并不是系统的功能，例如：易用、容错、响应时间、界面形式、平台等。系统属性具有一组可能的属性细节，这些属性细节往往是属性的一些离散的、表达模糊的符号值，例如： 响应时间=（生理上能够接受的时间段） 界面形式=（图形化的，基于表的，彩色比较平淡的） 在我们的案例中，要求借书查找时间小于1秒。 我们结合上面的图书馆管理系统的案例，来给出图书管理系统的问题域模型。我们首先看问题域中的图书、借阅、书目和借书者这四个类。 系统将通过计算机来处理图书、副本、借书者和借阅。借书者要求借书，给出要借图书的名称，出示借书证。系统查找所借的图书是否存在，若存在，同时还要查看该图书是否还有副本，如果有，再查询该借书者提供的借书证是否合法的注册用户，如果是，则办理借阅手续（登记借阅信息）。 图书是存放在图书馆中的一个书的名称，副本是一个图书的具体实例。一个图书可能有多
图书管理系统-(需求分析+总体设计)-(面向对象)
需求分析 1.确定用例 通过对系统需求的分析，可以确定系统有三个执行者：图书管理员行为者，读者行为者及系统管理员行为者。简要描述如下： 1)图书管理员行为者：管理员按系统授权维护和使用系统不同功能，可以 创建、修改、删除读者信息和图书信息即读者管理和图书管理，借阅、归还图书以及罚款等即借阅管理。 2)读者行为者：通过互联网或图书馆查询终端，查询图书信息和个人借阅 信息，还可以在符合续借的条件下自己办理续借图书。 3)系统管理员：可以对系统的数据进行维护，如增加、删除和更新书目， 增加、删除和更新借阅者帐户，增加和删除书籍。 读者
从图书管理系统的用例图可以看出有个六个用例：”读者用例，借阅用例，图书用例，借阅情况用例，续借用例，图书信息查询用例.”系统边界有个三个行为者，即图书管理员，读者，以及一个系统管理员。 从2-1图中我们还可以看出图中的每个用例之间的包含关系和扩展关系，读者用例包含关系是读者信息和读者类别；借阅包含关系是借书，还书，续借，借阅情况；而图中丢失和过期则是还书中的扩展；图书用例的包含关系是图书信息，图书类别，出版社信息及图书信息查询，其中意见反馈则是图书信息查询的扩展。 最高层用例图中展开读者借书的用例图如下图2-2所示: 读者借助此图书管理系统子系统,可以进行一下操作：
图2-2 读者借助此图书管理系统子系统,可以进行一下操作： 1.查询图书； 2.预留图书； 3.借书； 4.还书； 5.查阅借阅信息。 其中,在读者进行预留图书和查询借阅信息之前,读者必须先登录系统; 读者进行还书操作时,必须保证图书完整; 最高层用例图中展开图书馆管理员处理借书、还书等的用例图如下图2-3所示：图书管理员用例描述: