(完整版)面向对象的需求分析方法
面向对象的需求分析方法
面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 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）指定报警延迟和电话重拨延迟时间（以秒为单位）；
当软件系统收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。
开机后，软件系统负责显示当前工作状态，接收并处理用户指令。
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图）；数据库逻辑结构设计；类层次图；界面设计与各功能模块实现。④系 统调试：调试出现的主要问题，编译语法错误及修改，重点是运行逻辑问题修 改和调整。⑤使用说明书及编程体会：说明如何使用你编写的程序，详细列出 每一步的操作步骤。⑥关键源程序（带注释）
软件需求分析的详细流程
第一阶段：总体把握，了解概况 接手一个项目，不要着急去了解需求，这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。 该阶段的主要工作方法：客户访谈 输出成果：业务流程报告/调查报告（对客户方的组织业务概况和企业现状的一些总结） 第二阶段：详细了解业务，梳理业务流程 通过第一阶段的调研，了解客户业务概况的前提下，经过充分的业务调研准备，开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构，尽可能多的与相关基层人员进行诱导式的访谈，与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作，发现问题，提出改进的意见和建议。 该阶段的主要工作方法：访谈、业务分析、原型设计演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：需求细化和确认 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）
-需求分析方法论
需求分析方法论 原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
需求分析报告模板
需求分析报告模板文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
需求分析报告模板 科技信息中心 二○一一年五月二十日
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。
1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ●正文风格； ●提示方式； ●重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ●领导层及管理人员； ●开发人员； ●项目经理； ●项目的最终用户； ●测试人员； ●文档编写人员。 ●其他经许可阅读此文档的人员 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
软件需求分析重点-
软件需求分析重点 第1 章软件需求基础知识 返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是国需求错误引起的。（11） 在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14） 从产品的实际用户处收集需求这一过程是不可替代的。（18） 第2 章客户眼中的需求 某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需求）。（19） 要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。（20）不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。（22） 需求审阅是最有价值的保证软件质量的活动之一。（25） 需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。（25） 不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。（26） 第3 章需求工程的推荐方法 熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工作技术。（29）为每类用户选择代言人（31）
观察用户工作的过程（31） 跨项目重用需求（32） 过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。（37）38图表 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。（38） 第4 章需求分析员 相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。（42） 优秀的需求分析员应同时具备出色的交流、引导和人际交待能力，具备技术和业务领域的丰富知识，以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。（44） 需求分析员必须研究可能出错的情形。（44） 第5 章确定产品前景与项目范围 第6 章获取客户的需求 能否让开发人员更准确地了解用户需求，将决定软件需求工作能否取得成功，进而影响到软件开发的成功。（62） 项目伊始就应确定谁来担任问题的决策人。（72） 第7 章聆听客户的需求 需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。（75） 需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统。 要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早是制定设计的细节。 在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。（76）
面向对象需求分析文档
项目名称Array（The English Name） 《面向对象需求分析课程文 档》 } { ` XXX项目小组
修订表
审批记录 …
目录 1.引言 ................................................................................................................................. 错误!未定义书签。 目的............................................................................................................................... 错误!未定义书签。 适用范围....................................................................................................................... 错误!未定义书签。 参考资料....................................................................................................................... 错误!未定义书签。 术语和缩略语............................................................................................................... 错误!未定义书签。 2.系统概述 ......................................................................................................................... 错误!未定义书签。 产品描述....................................................................................................................... 错误!未定义书签。 产品功能....................................................................................................................... 错误!未定义书签。 《 一般约束....................................................................................................................... 错误!未定义书签。 3.功能性需求分类 .............................................................................................................. 错误!未定义书签。 功能描述1 .................................................................................................................... 错误!未定义书签。 功能描述2 .................................................................................................................... 错误!未定义书签。 4.产品的非功能性需求 ...................................................................................................... 错误!未定义书签。 外部接口说明............................................................................................................... 错误!未定义书签。 用户接口................................................................................................................... 错误!未定义书签。 软件接口................................................................................................................... 错误!未定义书签。 性能需求....................................................................................................................... 错误!未定义书签。 硬件的限制............................................................................................................... 错误!未定义书签。 ^ 属性............................................................................................................................... 错误!未定义书签。 友好性....................................................................................................................... 错误!未定义书签。 安全性....................................................................................................................... 错误!未定义书签。 可维护性................................................................................................................... 错误!未定义书签。 可转移/换性 ............................................................................................................. 错误!未定义书签。 系统的运行环境 ....................................................................................................................... 错误!未定义书签。 其他需求....................................................................................................................... 错误!未定义书签。 用户操作需求........................................................................................................... 错误!未定义书签。附录A：需求确认................................................................................................................... 错误!未定义书签。 。
软件需求分析方法
需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S＝｛D1，D2，D，…Dn｝ 问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di＝｛P1，P2，P3，…Pn｝ 问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj＝｛F1，F2，F3，…Fk｝ 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分 析此需求。 二需求分析方法论 第一阶段：“访谈式”
第一阶段是和具体用户方的领导层、业务层人员的访谈沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。 实现手段：诱导（拜访）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中）
银行计算机储蓄系统面向对象需求分析
面向对象需求分析【银行计算机储蓄系统】 学院：信息工程学院 班级：计科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 输出要求 要求快速准确地打印出存款或取款清单给客户。
需求分析主要流程
1.1主要流程 需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。1.1.1制定及修改需求开发计划 包括建立需求团队的组织并授权、对需求分析阶段的WBS进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。 1.1.2需求调查以及分析的过程 主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。1.1.3需求验证环节 主要通过原型（Prototype）、POC（ProofofConcept）、用例（UseCase）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。 （1）原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 （2）POC（ProofOfConcept）原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评价可能引起需求和设计的调整。一般来说，进行POC的条件：1.论证业务中涉及到的模型或者算法的可行性。2.论证技术模型实现的可行性、成本等。 （3）用例（UseCase）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场
需求分析方法主要步骤
1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。 在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。 此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。
遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。
面向对象分析与设计_期末复习_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）库存管理系统主要是后台管理人员参与，细化的功能为商品入库、商品出库，库存紧缺提醒等，库存管理的部分依赖于商品管理部分，也就是说该部分主要是对商品细项类中的数量特性进行操作。库存操作将影响将直接影响到线上订单系统的界面类的商品展示情况，也会影响到超市的铺货情况，这里铺货的流程被省略，将货架铺货商品量与库存量合并，即线下顾客无法在收银系统中登记库存为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. 面向对象开发方法一改过去传统的以_功能分析，面向过程_为基础的_对象_的结 构化分析与设计方法，它模拟人们理解和处理客观世界的方式来分析问题，把系统视为
如何进行软件需求分析
软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、… Dn表示，那么，我们可以用一个表达式描述为S={D1，D2，D3，…Dn} 但是，功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为 Di={P1，P2，P3，…Pm} 同样，功能Pj有若干个行为F1、F2、F3、… Fk，每个行为对应于软构件中的实现方法 Pj={F1，F2，F3，…Fk} 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标： 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需
图书管理系统-(需求分析+总体设计)-(面向对象)
需求分析 1.确定用例 通过对系统需求的分析，可以确定系统有三个执行者：图书管理员行为者，读者行为者及系统管理员行为者。简要描述如下： 1)图书管理员行为者：管理员按系统授权维护和使用系统不同功能，可以 创建、修改、删除读者信息和图书信息即读者管理和图书管理，借阅、归还图书以及罚款等即借阅管理。 2)读者行为者：通过互联网或图书馆查询终端，查询图书信息和个人借阅 信息，还可以在符合续借的条件下自己办理续借图书。 3)系统管理员：可以对系统的数据进行维护，如增加、删除和更新书目， 增加、删除和更新借阅者帐户，增加和删除书籍。 读者
从图书管理系统的用例图可以看出有个六个用例：”读者用例，借阅用例，图书用例，借阅情况用例，续借用例，图书信息查询用例.”系统边界有个三个行为者，即图书管理员，读者，以及一个系统管理员。 从2-1图中我们还可以看出图中的每个用例之间的包含关系和扩展关系，读者用例包含关系是读者信息和读者类别；借阅包含关系是借书，还书，续借，借阅情况；而图中丢失和过期则是还书中的扩展；图书用例的包含关系是图书信息，图书类别，出版社信息及图书信息查询，其中意见反馈则是图书信息查询的扩展。 最高层用例图中展开读者借书的用例图如下图2-2所示: 读者借助此图书管理系统子系统,可以进行一下操作：
图2-2 读者借助此图书管理系统子系统,可以进行一下操作： 1.查询图书； 2.预留图书； 3.借书； 4.还书； 5.查阅借阅信息。 其中,在读者进行预留图书和查询借阅信息之前,读者必须先登录系统; 读者进行还书操作时,必须保证图书完整; 最高层用例图中展开图书馆管理员处理借书、还书等的用例图如下图2-3所示：图书管理员用例描述:
需求分析(一)概念、方法、实践步骤
需求分析(一)概念、方法、实践步骤 1.概念、方法、实践步骤 需求分析阶段主要通过收集、分析、导出的方法，将客户、业务、用户的需求转换为对应的（软件）系统需求的过程。典型的工作产品：软件需求说明（Software Requirements Specifications，以下简称SRS）其主要包括系统基本概要、业务功能、系统功能（性能、安全性、信赖性、扩充性、移植性、多语言对应性等要求）、接口功能要求等内容。 1.1 需求分析阶段的主要活动 需求分析阶段的主要活动可以分为需求开发、需求管理2类： 需求开发通过对客户、业务、用户、原系统等调查获取原始的需求，经过需求分析逐步识别并使业务具体化，通过形成制作规格说明书（或SRS）使业务系统化，项目团队同客户、用户逐步达成共识对需求得以最终确认，其间可以通过系统建模、POC等方式评估需求的可实现性。 需求管理在需求开发过程中，通过需求范围认定、需求形式化记录、需求数据库建立、需求状态跟踪、需求变更分析和波动评估、需求评审控制等活动，通过使用需求管理工具等手段，实现对系统需求按基线进行控制和管理。其核心内容变更管理、版本管理以及需求跟踪。 1.2 需求开发的主要概念以及核心步骤 业务需求反映了企业或组织对（软件）系统的业务要求，通常也包含问题或机会的定义。问题是指企业或组织运作过程中遇到的问题，例如物资供应脱节、用户投诉量大、客户流失率较高等。机会是指抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行、基于即时通信的工作协同系统等。业务需求通常由管理人员提出，业务需
求的解决往往要结合制度、（人员）能力、系统功能等多方面综合解决。另外,业务需求也反映了企业或组织对（软件）系统的高层次目标要求，就是系统的建设的目的以及目标。 用户需求是指描述用户使用（软件）系统需要完成什么任务，怎么完成的需求，通常是在问题定义（业务需求）的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。解决如何使用（软件）系统完成具体工作。 软件系统需求是在业务需求的指导下，对用户需求进行整理、分析、提炼，从而指导开发的、更精确的、规格化的需求。一般来说，软件需求可以作为软件验收依据与合同契约。软件系统需求可以分为业务功能需求、系统功能需求、设计约束等方面的内容。 ?业务功能需求：（软件）系统必须完成的业务功能，即为了向它的用户提供有用的 功能，产品必须执行的动作。这部分工作将分散的用户零散的需求采用结构化的方 法去定义，以便支撑后续的设计、开发、测试。 ?系统功能需求：（软件）系统必须具备的功能、性能、属性。包括系统性能（功能 速度、响应时间、恢复时间等等）、可靠性、易用性、安全性、移植、部署等方面 的内容需求。 ?设计约束的需求：影响系统实现的各种设计约束，包括开发语言、数据完整性方针、 资源的限制、运行的环境的要求等等。 2.主要流程 需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。 1．制定及修改需求开发计划包括建立需求团队的组织并授权、对需求分析阶段的WBS 进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。 2．需求调查以及分析的过程，主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。 3．需求验证环节主要通过原型（Prototype）、POC（Proof of Concept）、用例（Use Case）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。 ?原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定 程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 ?POC（Proof Of Concept）原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评 价可能引起需求和设计的调整。一般来说，进行POC的条件：1. 论证业务中 涉及到的模型或者算法的可行性。2. 论证技术模型实现的可行性、成本等。 ?用例（Use Case）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说