下载掌阅APP，畅读海量书库
立即打开
在2004年至2013年的考试试题中，共有9道试题和系统分析有关，本节主要分析这9道试题。在本节的试题中，其考查范围如表2-1所示。
表2-1系统分析与建模试题分布表
续表
某软件公司拟开发一套基于局域网的分布式系统，该系统由分布于某企业各部门的多个子系统构成。在该企业的日常运作中，各子系统之间要经常基于企业局域网进行交互。
实现各子系统之间的交互可以采用如下两种方式。
（1）基于某种成熟的分布式软件体系结构（如EJB，CORBA，DCOM/COM+）来构建整个系统。现在主流的分布式软件体系结构都融合了面向对象技术，对分布式对象提供了很好的支持，可以利用这些体系结构支持分布式对象访问的通信机制（如RMI/IIOP，ORB，ORPC等）来实现各子系统之间的交互，其优点是实现相对简单且比较可靠。
（2）先分别实现各个子系统，然后利用底层通信协议（如TCP/IP）实现各子系统之间的交互，其优点是通信效率高且可控性好。
【问题1】
虽然不同的分布式软件体系结构采用的具体实现方式不尽相同，但它们都支持客户端透明地访问分布式对象，即客户端可以像访问本地对象一样访问分布式对象。请用200字以内文字，说明实现这种透明性的基本原理。
【问题2】
由于应用的具体需求千差万别，再好的分布式软件体系结构也不可能适应所有的应用系统，有时我们不得不放弃现有的分布式软件体系结构的支持，自己利用底层的通信协议来实现各子系统之间的交互。请用200字以内文字，简要说明用底层通信协议实现各子系统之间的交互时要解决的主要问题。
全球性网络使联机的所有设备和软件成为全球共享的浩瀚的资源，计算机环境也从集中式发展到分布式。开放式系统的发展使用户能够透明地应用由不同厂商制造的不同机型、不同平台所组成的异构型计算资源，因此，分布式处理和应用集成自然而然地成为人们的共同要求。
分布式系统的主要特点包括资源共享、开放性、并发性、可伸缩性、容错性，以及透明性。实现分布式系统的体系结构主要包括两种，一是客户-服务器体系结构，系统被看成是提供一组服务供客户机使用，服务器和客户机被区别对待；二是分布式对象体系结构，不区分服务器和客户机，将系统当成交互的一组对象，它们的位置是无关紧要的，服务提供者和消费者之间没有界限。
【问题1】
在分布式系统中，不同的构件可能用不同的程序语言来实现，且这些构件可能运行在不同类型的处理器上。数据模型、信息表示法，以及通信协议可能都不一样。因此，分布式系统就需要某种软件来管理这些不同的部分，确保它们能通信和交换数据。中间件就是这样一种软件，它位于系统的不同分布式构件之间。
中间件是一种通用软件，通常不是由应用开发人员编写的，而是买现成的。中间件的例子有负责数据库通信管理的软件、事务管理器、数据转换器和通信控制器等，最重要的一种中间件就是分布式系统框架。
在分布式系统的客户-服务器模型中，客户机必须知道服务器的存在，而且要知道它们能提供的服务，还要知道如何才能使用这些服务器上的服务。这个模型对许多类型的应用来说能工作得很好。然而，它对系统设计者是一个很大的限制，因为设计者必须决定服务在哪里提供，而且还得规划系统的伸缩性，当有较多的客户机增加到系统中时，就得考虑如何将服务器的负载分布开来。
而更通用的分布式系统的设计方法是去掉客户机与服务器之间的差别，用分布式对象体系结构来设计系统。在一个分布式对象体系结构中，其基本系统构件是对象，它能够提供一组服务，对外给出这些服务的接口。其他对象调用这些服务，对象之间并不存在客户机与服务器的界限，接受服务者即扮演客户机的角色，提供服务者就是服务器。
对象可能分布在网络的多台计算机上，它们通过中间件相互通信。就像硬件总线允许不同的卡插于其上以支持硬件设备之间的通信一样，这个中间件被看成软件总线。它提供一组服务，允许对象之间通信和在系统上添加和移走对象。这个中间件称为对象请求代理。它的作用是在对象之间提供一个无缝接口。
主要的分布式对象体系结构框架有：OMG定义的CORBA（通用对象请求代理体系结构）、Microsoft开发的DCOM（分布式构件对象模型）、Sun开发的EJB（企业级JavaBean）三种。它们在分布式对象处理方面的原理基本一样，只是具体实现上有所区别。
【问题2】
基于成熟的分布式软件体系结构来构建整个系统，可以利用这些体系结构支持分布式对象访问的通信机制来实现各子系统之间的交互，因为其通信机制、数据接口等已成标准，程序员只需直接使用就可以了，所以，这种方法的优点是实现相对简单且比较可靠。
如果利用底层通信协议实现各子系统之间的交互，则各子系统之间的通信机制、数据接口等都需要开发人员自己拟订和确定，这是该方法要解决的主要问题。
【问题1】
客户端和服务端不是直接进行交互，而是利用客户端存根和服务端框架来间接进行通信，这样客户程序和服务程序就不需考虑底层的通信细节问题。
由于客户端存根和服务端框架一般由平台自动生成，不需程序员手工编写，所以这种通信模型的最大好处是可以省去程序员自己写程序来处理底层通信的问题。
【问题2】
（1）异类系统间交互的兼容性，例如处理不同操作系统的字节顺序、数据长度、数据表示方式等。
（2）通信的可靠性问题，例如出错处理、重传机制等。
（3）通信的安全性问题。
（4）接口的可用性、易用性问题。
近年来Linux的迅速发展，改变了操作系统市场份额的格局，虽然Linux的市场份额在我国还不到10%，但已呈稳步上升的态势。针对这一情况，某大型企业（装机量大、信息化程度高）决定从战略层面上考虑Linux在本企业的发展定位，为此，需要对Linux及其典型产品进行测试和评估。假定由你担任这一评测工作的项目经理，你如何考虑以下问题。
【问题1】
请用100字以内文字，说明你向企业决策层提交的评估报告应包括哪些主要方面的内容。
【问题2】
采用Linux时，安全性问题是必须慎重考虑的一个方面，通过研究，项目组认为开放源码和BUG是Linux自身特有的影响安全性的两个最主要方面。请仅就开发源码对安全性的影响，用150字以内文字，说明你的观点。
【问题3】
请用400字以内文字，说明与目前广泛使用的Windows操作系统相比，采用Linux主要有什么优缺点？你如何看待目前基于Linux操作系统的应用软件相对较少这个问题。
虽然Windows操作系统在桌面操作系统市场占据着绝对的优势地位，但在服务器操作系统市场并不是一枝独秀。准确地说，针对UNIX操作系统而言，仅仅称得上“后起之秀”，但是由于UNIX系统标准不统一，各大计算机硬件厂商都有自己的UNIX系统，而且价格昂贵、维护成本高、对硬件要求较高，因此Windows服务器版操作系统一经问世之后，就成为UNIX系统的主要竞争对手。它们凭借着漂亮的图形界面、简单易用的用户界面、性能表现稳定等优势，在工作组级、部门级服务器市场成为新的霸主。
而自20个世纪90年代初Linux诞生以来，凭借着开源组织广大支持者的共同努力下，已经成为了一种适用于x86CPU平台上的，功能强大、性能稳定、价格低廉的类UNIX操作系统，在中小级应用、企业应用，以及部分大型应用上表现出了极高的性价比，成为服务器操作系统市场的又一有力竞争者。
【问题1】
在本题中，主要考查的要点并不是对Linux操作系统的理解，而是在于对信息系统支撑系统的选型及评估工作的理解。通常在企业信息化建设过程中，对支撑系统，特别是操作系统及相关的服务软件等系统软件的评估包括以下几个方面。
（1）基本评估。也就是对诸如Linux操作系统的特点、市场占用情况、各大软硬件厂商对于Linux操作系统的支持情况，Linux操作系统的发展前景等方面进行详细的评估，以供参考。
（2）功能评估。这是在整个评估工作中最优先的一个评估项目，应全面地考查待评估系统在功能上是否能够有效地满足信息系统的应用需求。包括功能是否能够实现，是否能够对各种所需的应用系统提供必要的支持等。如果功能上无法满足，那么其他的所有的问题都不再重要。
（3）性能评估。如果功能上能够有效地满足，那么接下来就必须对其各种性能指标是否满足需求进行进一步的评估，主要包括以下6个方面。
·可用性：用户界面是否良好？使用是否方便等？
·响应时间：响应速度是否能够满足要求？
·可扩展性：能否跟踪需求的变化，灵活地、方便地进行扩展，以满足新的需求？
·可维护性：维护是否方便？解决时间是否足够等？
·可靠性：系统的平均无故障时间是多少？平均修复时间是多少？
·应用软件的支持性：是否有足够的配套应用软件？是否提供开发接口？对第三方系统的支持如何？
（4）系统的总体拥有成本（TCO）评估。当功能上满足需求，性能上符合要求，那么接下来最重要的就是全面衡量系统的总体拥有成本。通常情况下，包括以下几个方面的内容。
·购置成本：也就是软件的直接成本，即购买许可证所需支付的成本，包括系统本身及相应的配套软件所需支付的成本总和。
·部署成本：包括软件对系统的要求是否高，其配套的硬件成本如何，以及对部署人员的技术水平的要求，也会相应地影响部署的人力成本。
·维护成本：包括维护人员的技术水平要求（这将直接影响到工资成本等），是否有完善的技术支持与培训体系，相应的开发、升级成本如何。
（5）适应性评估。也就是从企业的真实应用的角度进行综合的评估，对Linux操作系统在本企业应用的可行性进行综合的评估。
总而言之，整个评测是一个系统工程，需要全面地评测、分析、比较，才能够得出客观的结论。在评测时，可以考虑采用以下方法。
·全组共识：任命决策组成员，并委以最终评估和选择的重任。
·成本/效益分析：对建议的每个系统列出它的成本和效益，并用货币的形式进行综合性比较。
·基准测试：指在相同条件下对计算机系统的运行进行比较的检验。
·点值评估：成本效益分析的缺点之一是难以对所有效益确定其货币价值，而点值评估就是用权值代替货币价值的评估方法。
【问题2】
开放源代码是Linux操作系统的一大特色，Linux遵循的是CPL版权声明，也就是任何人都可以根据自己的需要对Linux的源代码进行修改，并且所有的修改都必须继续保持CPL版权声明。这种方式一改传统的源代码封闭的做法，为软件业的交流与财富继续提供了良好的基础，这种自由的共享精神也是对现代商业社会带来了一股新的气息。
由于就开放源代码对安全性而言，会带来一些正面的好处，但同时也隐藏着一些负面的不利影响。因此正确地认识和客观地评价是十分重要的。
（1）正面的好处。第一，开放源代码之后，由于系统对任何人都不再具有保密性，因此任何恶意地在代码中植入“恶意代码”的可能性都能够被有效地杜绝。这是因为，使用者可以通过查阅代码来发现这些问题，并采取有效的解决措施；第二，如果使用者在日常的应用中发现一些安全隐患，可以通过直接修改源代码的方式来进行修复，并无须等待某个特定的供应商来解决，能够提高安全防护的效率和透明度；第三，开放源代码使得个性化修改系统实现成为可能，这样也可以有效地提高系统的抗攻击性。
（2）负面的不利影响。开放源代码也是一个安全的双刃剑，它不但为使用者提供了便利，也为攻击者提供了方便。第一，攻击者可以通过直接阅读源代码，就可以更方便、容易地发现系统的潜在漏洞，以致发起更有威胁性的安全攻击；第二，攻击者可以通过发布植入恶意代码的升级软件，当用户下载升级时会不经意地将安全隐患带入系统，而由于并非每个用户都能够阅读代码，所以无法有效地进行甄别；第三，任何人都可以修改源码，使得统一的安全防范措施的开发与部署更加困难。
【问题3】
Linux是一个类似UNIX的操作系统，它追求稳定与性能；Windows则是一个用户界面十分友好的图形化操作系统，因为它在可用性与性能之间进行了很好的权衡与折中。因此它们是各有各的特色，各有各的优缺点。而在该问题中的答案构思中，还应该依托本题的讨论背景——企业应用展开。
Linux在作为企业应用方面，凸显的优势在于以下几个方面。
（1）Linux是一个类似UNIX的系统，它主要是针对服务器设计的操作系统，它能够运行在普通的PC服务器上，发挥出良好的服务性能。加上它没有图形化的开销，因此在相同配置的机器上，Linux的性能是优于Windows的。
（2）由于Linux是一个出生、发展于因特网的操作系统，因此各种网络服务的开发在Linux的发展史上是最活跃的篇章，而且其有效利用了诸如Apache、Sendmail、Bind等现有的UNIX资源，使其在网络服务能力上大大超过了Windows，成为在Internet上部署网络服务的最好选择之一。
（3）Linux是一个开放源码的操作系统，本身是免费提供下载的，而一些套装发行商（如RedHat、TubroLinux）也只是在包装、维护方面提供服务，收取少量的费用。因此总体来说，它的购买价格是远远小于Windows系列的。
（4）Linux继承的UNIX操作系统设计的优势，而且各种应用软件少，内存的消耗较少，因此通常情况下都会表现出比Windows操作系统更加可靠的特点。
当然，与界面友好的Windows系列操作系统相比，也存在许多不足之处。
（1）由于Linux承袭了UNIX一贯的风格，还是保持着文本为主的系统界面，因此操作性要比Windows差一些，用户界面也不够友好。
（2）Linux在安装、配置、维护等方面都比Windows困难，通常对安装维护人员的技术水平要求更高一些。
（3）Linux是由爱好者开发的，没有人会对其承担服务、培训的义务，而且对于系统出错的影响也是没人负责的，这也是限制企业应用大幅提高的瓶颈点。而RedHat、TubroLinux这样的公司都在努力对这方面进行加强。
（4）配套应用程序不多。Linux的很多应用系统都不够全面，这与Windows相比差距十分明显，这也是Linux在中国并没有占领很高的市场份额。
（5）第三方支持贫乏。经济社会的今天，缺少利益来源的Linux操作系统总体来说还是缺乏第三方支持，经常会遇到一些部署、维护上的困难。
由于Linux是一堆编程爱好者在Internet下协作开发，它本身的原型就是UNIX系统，也就是定位于网络服务器操作系统的，而且由于这些人大多数都是计算机高手，因此对图形界面化的应用软件需求量本身就不大。加上在Linux下的开发工具主要都是字符界面的，并没有良好的IDE环境，因此开发人员、软件供应商的数量也相对较少，在开发应用软件时会遇到很大的困难，再加上图形界面支持还远不如Windows平台。综合上述的这些原因，Linux下现在应用软件还相对比较缺乏的现象是必然的。
但是随着Linux应用的逐渐深入，支持的供应商逐渐增多，Java等跨平台的开发工具的出现，以及在嵌入式领域的机会，都会使得Linux下的应用软件会逐渐增多起来，而且成为桌面操作系统的有力竞争者也是可以期待的。
【问题1】
提交企业决策层的评估报告应该包括以下5个方面。
（1）基本评估：Linux的特点、市场、厂商支持和发展前景。
（2）功能评估：功能列表及横向对比表。
（3）性能评估：包括可用性、响应时间、可靠性、可扩展性等综合性能指标。
（4）总体拥有成本评估：包括购买成本、部署成本、维护成本等多个方面。
（5）适应性评估：本企业应用Linux的可行性。
【问题2】
（1）开放源码便于攻击者通过阅读源码发现安全隐患、发布“恶意代码”、并且更难以开发和部署统一的安全防护系统，从而降低了系统的安全性。
（2）开放源码引入更多的交流，代码质量往往较高，从而提高了安全性；开放源码的漏洞能在很短的时间内得到发现和修复，特别是修复的速度比封闭系统要快。
【问题3】
Linux和Windows相比，主要的优缺点体现在以下方面。
（1）优点：系统性能高、网络应用能力强、价格便宜、可靠性高。
（2）缺点：用户界面不友好、安装维护困难、售后服务和培训保障较差、配套应用程序少、第三方支持贫乏。
应根据Linux的发展趋势从以下5个方面来看待Linux环境下的应用软件相对较少的问题：
（1）各大软件公司对于Linux应用软件开发的重视和投入的增加。
（2）Linux的技术特点及发展前景。
（3）本企业的特点及对Linux应用软件的具体需求。
（4）国家对Linux产品的政策导向。
（5）Linux市场占有率的增加。
因此，Linux下应用软件少的现象是一种正常的现象，但随着Linux在嵌入式领域、桌面办公领域的进一步发展，加之支持Linux的供应商逐渐增多，这一局面必将得到改善。
软件架构是指大型、复杂软件的系统结构的设计、规格说明和实施。它以规范的形式装配若干结构元素，从而描述出系统的主要功能和性能要求，同时表述其他非功能性需求（如可靠性、可扩展性、可移植性和可用性等）。软件架构为软件系统提供了一个结构、行为和属性的高级抽象模式，可以使用一个公式来表达：软件架构={构成系统的元素，指导元素集成的形式，关系和约束}。
“4+1”视图模型用五个视图组成的模型来描述软件架构。该模型包含五个主要的视图。
（1）逻辑视图（Logical View），描述了设计的对象模型，支持系统的功能需求。
（2）进程视图（Process View），描述了设计的并发和同步特征，支持系统的运行特性。
（3）物理视图（Physical view），描述了软件到硬件的映射，反映了分布式特性，支持系统的拓扑、安装和通信需求。
（4）开发视图（Development view），描述了在开发环境中软件的静态组织结构，支持软件开发的内部需求。
（5）场景（Scenario），用来说明重要的系统活动，是其他四个视图在用例驱动下的综合。
【问题1】
软件架构在软件需求与设计之间架起一座桥梁，也是项目干系人进行交流的手段，允许不同的项目干系人找出他们所关心的软件架构问题。假设采用面向对象的设计方法，各个视图涉及的组件（元素）包括：任务、类、模块、节点、步骤等，项目干系人包括最终用户、系统设计师、程序员、经理、项目管理师等。请在表2-2中的（1）到（7）处填入恰当的内容（空白处不用填）。
表2-2需要填写的表格
【问题2】
对于大型项目，通常采用迭代的方法来进行架构设计。架构先被原型化、测试、评估分析，然后在一系列的迭代过程中被细化。这种方法能够使需求细化、成熟化，并能够被更好地理解。请用400字以内文字，简述软件架构基于场景驱动的迭代式设计过程。
【问题3】
开发视图是实现软件详细设计和编码的重要蓝图。请用300字以内文字，说明开发视图需要满足软件内部的哪些需求以及开发视图直接影响到项目管理的哪些方面。
本题主要考查软件架构（软件体系结构）“4＋1”视图的有关知识和实施方法。
设计软件架构的首要问题是如何表示软件架构，即如何对软件架构建模。根据建模的侧重点不同，可以将软件架构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。在这5种模型中，最常用的是结构模型和动态模型。
（1）结构模型：这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质等。研究结构模型的核心是架构描述语言。
（2）框架模型：框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
（3）动态模型：动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如，描述系统的重新配置或演化。动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程。这类系统常是激励型的。
（4）过程模型：过程模型研究构造系统的步骤和过程，因而结构是遵循某些过程脚本的结果。
（5）功能模型：该模型认为架构是由一组功能构件按层次组成，下层向上层提供服务。它可以看作是一种特殊的框架模型。
上述5种模型各有所长，将5种模型有机地统一在一起，形成一个完整的模型来刻画软件架构更合适。例如，Kruchten在1995年提出了一个“4+1”的视图模型。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。“4+1”视图模型如图2-1所示。
图2-1“4＋1”视图模型
逻辑视图 主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用做标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。
开发视图 也称模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。
开发视图通过系统输入/输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
进程视图 侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
进程视图可以描述成多层抽象，每个级别分别关注不同的方面。在最高层抽象中，进程结构可以看做是构成一个执行单元的一组任务。它可看成一系列独立的，通过逻辑网络相互通信的程序。它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。通过进程视图可以从进程测量一个目标系统最终执行情况。例如在以计算机网络作为运行环境的图书管理系统中，服务器需要对来自各个不同的客户机的进程进行管理，决定某个特定进程（如查询子进程、借还书子进程）的唤醒、启动、关闭等操作，从而控制整个网络协调有序地工作。
物理视图 主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。
大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一道，以多种形式出现，也可单独出现。
场景可以看做是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。项目干系人是最终用户和开发人员，组件元素是步骤。
从以上分析可知，逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。
【问题1】
（1）类 （2）任务 （3）节点 （4）模块
（5）步骤 （6）最终用户 （7）系统实施工程师
【问题2】
（1）开始阶段。基于风险和重要性为某次迭代选择一些场景。场景可以被归纳为对若干用户需求的抽象；场景进行“描述”，以识别主要的抽象（类、机制、过程、子系统）；将所有发现的架构元素分布到4个视图中；然后实施、测试、评估该架构，这个过程中可能检测到一些缺点或潜在的增强要求；捕获经验教训。
（2）循环阶段。重新评估风险，选择能减轻风险或提高结构覆盖的额外的少量场景，然后试着在原先的架构中描述这些场景，发现额外的架构元素，或找出适应这些场景所需要的架构变更，更新4个主要视图；根据变更修订现有的场景；升级实现工具（架构原型）以支持新的、扩展了的场景集合。
（3）测试。如果有可能（例如，在已有可重用的构件下快速实现系统），在实际的目标环境和负载下进行测试。
（4）评审这5个视图，检测架构在简洁性、可重用性和通用性方面可能存在的潜在的问题。
（5）更新设计准则和基本原理。
（6）捕获经验教训。
【问题3】
软件内部需求是指任何一个软件都要满足的一些非功能方面的要求，大部分情况下，开发视图架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制与约束。
开发视图是项目管理的基础，通过开发视图对系统功能、模块的层次性分解，能够预算开发工作量、安排开发任务，编制开发计划，进而控制进度，即开发视图是需求分解、任务管理、成本管理、进度管理等方面的基础。
某银行准备开发一个网上信用卡管理系统CCMS，该系统的基本功能如下。
（1）信用卡申请。非信用卡客户填写信用卡申请表，说明所要申请的信用卡类型及申请者的基本信息，提交CCMS登录。如果信用卡申请被银行接受，客户会收到银行的确认函，并告知用户信用卡的有效期及信贷限额；否则银行会发送一封拒绝函给该客户。客户收到确认函后，需再次登录CCMS，用信用卡号和密码激活该信用卡。激活操作结束后，CCMS将激活通知发送给客户，告知客户其信用卡是否被成功地激活。
（2）月报表生成。在每个月第一天的零点，CCMS为每个信用卡客户创建一份月报表，对该客户上月的信用卡交易情况及交易额进行统计。信用卡客户可以登录CCMS查看月报表，也可以要求CCMS提供打印出的月报表。
（3）信用卡客户信息管理。信用卡客户的个人信息可以在 CCMS中进行在线的管理。每个信用卡客户可以在线查询其个人信息。
（4）信用卡交易记录。信用卡客户使用信息卡进行的每一笔交易都会记录在CCMS中。
（5）交易信息查询。信用卡客户可以登录CCMS查询并核实其信用卡交易记录及交易额。
在系统的需求分析阶段，使用用例对系统需求建模。表2-3和表2-4给出了其中两个用例的概要描述。
表2-3用例“非信用卡客户申请信用卡”的描述
表2-4用例“激活信用卡”的描述
【问题1】
将表2-3和表2-4中的（1）～（10）填充完整。
【问题2】
除了表2-3和表2-4给出的用例外，从上述系统陈述中还可以获取哪些由信用卡客户发起的用例？（给出用例名称即可）
【问题3】
用400字以内文字，简要说明用例获取的基本步骤。
【问题4】
用例除了使用表2-3和表2-4所示的形式描述外，还可以使用UML的用例图来表示。分别用100字以内文字，解释UML用例图中扩展用例和抽象用例的内涵。
从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。用例方法是一种需求合成技术，首先采用需求获取方法获取需求，记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。在面向对象的分析方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。
用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。在用例图中，主要包括参与者、用例和通信关联三种元素，如图2-2所示。
图2-2用例图中的基本元素
（1）参与者。参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。
（2）用例。用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。也就是说，用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
（3）通信关联。通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者。如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在用例模型中，信息流不是由通信关联来表示的，该信息流是默认存在的，并且是双向的，它与箭头所指的方向没有关系。
参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。
（1）其他系统：当系统需要与其他系统交互时，其他系统就是一个参与者。例如，对某企业的在线教育平台系统而言，该企业的OA系统就是一个参与者。
（2）硬件设备：如果系统需要与硬件设备交互，硬件设备就是一个参与者。例如，在开发IC（Integrated Circuit，集成电路）卡门禁系统时，IC卡读写器就是一个参与者。
（3）时钟：当系统需要定时触发时，时钟就是一个参与者。例如，开发在线测试系统中的“定时交卷”功能时，就需要引入时钟作为参与者。
要注意的是，参与者一定在系统之外，不是系统的一部分。可以通过下列问题来帮助系统分析师发现系统的参与者：谁使用这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁关闭这个系统？哪些（其他的）系统使用这个系统？谁从这个系统获取信息？谁为这个系统提供信息？是否有事情自动在预计的时间发生？
执行系统某项功能的参与者可能有多个，但这多个参与者在使用系统时会有不同的职责划分，根据职责的重要程度不同，有主要参与者和次要参与者之分。主要参与者是从系统中直接获得可度量价值的参与者，次要参与者的需求驱动了用例所表示的行为或功能，在用例中起支持作用，帮助主要参与者完成他们的工作，次要参与者不能脱离主要参与者而存在。开发用例的重点是要找到主要参与者。
将参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。首先，要将获取到的需求分配给与其相关的参与者，以便可以针对每个参与者进行工作，而无遗漏；其次，进行合并操作。在合并之前，要明确为什么要合并，知道了合并的目的，才可能选择正确的合并操作。合并后，将产生用例。将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架，如图2-3所示。
图2-3用例图示例
在确定用例的过程中，需要注意以下问题。
（1）用例命名。用例的命名应该注意采用“动词（短语）+名词（短语）”的形式，例如，“开通课程”和“课程测试”等。而且，最好能够对用例进行编号，这也是实现需求跟踪管理的重要技巧，通过编号可以将用户的需求落实到特定的用例中去。
（2）不能混淆用例和用例所包含的步骤。例如，“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是是用例的子功能。
（3）注意区分业务用例和系统用例。当针对整个业务领域建模时，需要使用业务用例，其中会涉及大量的人工活动，例如，在线教育平台系统中有一项重要工作是“编写教材”，这就是业务用例，是信息系统无法完成的。信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，因此，只需要识别出系统用例，而不需考虑业务用例。
用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构，这时可以对用例进行分组。UML使用用例主题划分用例图，一组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。
用例的描述可以迭代完成，先对一些重要的用例编制相对细致的用例描述，对于一些不重要的用例，可以留待以后再补充完成。用例描述通常包括以下几个部分。
（1）用例名称。用例名称应该与用例图相符，并写上其相应的编号。
（2）简要说明。对用例为参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言。
（3）事件流。事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动，也就是用例所完成的工作步骤。在编写时应注意使用简单的语法，主语明确，语义易于理解；明确写出“谁控制球”，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；从俯视的角度来编写，指出参与者的动作，以及系统的响应；描述用户意图和系统职责，而不叙述具体的行为和技术细节，特别是有关用户界面的细节。
执行一个用例的事件流有多种可能的路线，其中主事件流（基本事件流）是指能够满足目标的典型的成功路径，主事件流通常不包括任何条件和分支，符合大多数人的期望，从而更容易理解和扩展；备选事件流（扩展事件流）也称为备选路径，是完成用例可能出现失败的情况、分支路径或扩展路径，为了不影响用例活动清晰的主线，将这些分支处理全部抽取出来作为备选事件流。例如，在“开通课程”用例执行的过程中，如果学员所交的费用多于所选修课程规定的费用，则需要把多余的费用转换为学习币；如果学员选修课程数量超出最大限额，则用例未达到期望目标而终止。在事件流的描述中，主事件流使用“确认”和“验证”等确定性语句，而不是“检查是否……”和“如果……，那么……，否则……”等条件语句，这些分支情况利用备选事件流来说明。
另外，事件流的编写过程也是可以分阶段迭代进行的，对于优先级高的用例花更多的时间，更加的细化；对优先级低的用例可以先简略地将主事件流描述清楚，备选事件流留待以后处理。对于一些事件流较为复杂的，可以在用例描述中引用顺序图、状态图和通信图等手段进行描述。
（4）非功能需求。因为用例所涉及的非功能需求通常很难在事件流中进行表达，因此单列为一小节进行描述。在非功能需求的描述方面，一定要注意使其可度量和可验证。否则，就容易流于形式，形同摆设。
（5）前置条件和后置条件。前置条件是执行用例之前必须存在的系统状态，如果前置条件不满足，则用例无法启动。例如，“开通课程”用例的前置条件是客服人员已正确登录到系统中；后置条件是用例执行完毕系统可能处于的一组状态。一旦用例成功执行，可能会导致系统内部某些状态的变化，例如，成功地“开通课程”会使该课程的选修人数增加，会使学员的权限发生变化等。而某些用例也可能没有前置条件或后置条件，例如，“学员联络”用例没有后置条件，因为该用例执行后不会改变系统状态。如果在当前阶段不容易确定前置条件或后置条件，则可以在以后再细化。
（6）扩展点。如果包括扩展（或包含）用例，则写出扩展（或包含）用例名，并说明在什么情况下使用。
（7）优先级。说明用户对该用例的期望值，为以后的开发工作确定先后顺序。可以采用满意度/不满意度指标进行说明，例如，设置为1～5的数值。
在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。
（1）包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。例如，图2-3中的“学习课程”和“课程测试”两个用例都需要检查学员的权限，为此，可以定义一个抽象用例“检查权限”。用例“学习课程”和“课程测试”与用例“检查权限”之间的关系就是包含关系，如图2-4所示。其中“<<include>>”是包含关系的构造型，箭头指向抽象用例。
图2-4包含关系的例子
当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中重复地描述这段事件流，也可以防止这段事件流在不同用例中的描述出现不一致。当需要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也可以将某一段事件流抽象成为一个被包含的用例。
（2）扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。例如，图2-3中的学员进行“课程测试”时，其测试的次数可能已超出系统规定的限额，这时就需要学员“充入学习币”。用例“课程测试”和“充入学习币”之间的关系就是扩展关系，如图2-5所示。其中“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
图2-5扩展关系的例子
（3）泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。例如，图2-3中学员进行课程注册时，假设既可以通过电话注册，也可以通过网上注册，则“注册课程”用例就是“电话注册”用例和“网上注册”用例的泛化，如图2-6所示。其中三角箭头指向父用例。
图2-6泛化关系的例子
从UML事物关系的本质上来看，包含关系和扩展关系都属于依赖关系。对包含关系而言，抽象用例中的事件流是一定插入到基本用例中去的，并且插入点只有一个。扩展用例的事件流往往可以抽象为基本用例的备选事件流，在扩展关系中，可以根据一定的条件来决定是否将扩展用例的事件流插入到基本用例的事件流中，并且插入点可以有多个。在实际应用中，很少使用泛化关系，子用例的特殊行为都可以作为父用例中的备选事件流而存在。
在实际工作中，系统分析师要谨慎选用这些关系。从上面的介绍可以看出，包含、扩展和泛化关系都会增加用例的个数，从而增加用例模型的复杂度。另外，一般都是在用例模型完成之后才对它进行调整，在用例模型建立之初不必急于抽象用例之间的关系。
【问题1】
（1）提交信用卡申请表 （2）信用卡类型及申请人的基本信息
（3）非信用卡客户 （4）确认函
（5）非信用卡客户 （6）拒绝函
（7）非信用卡客户 （8）信用卡激活请求
（9）激活通知 （10）信用卡客户
注：（4）和（6）可以互换
【问题2】
（1）查询个人信息 （2）管理个人信息
（3）查询交易信息 （4）查询月报表
（5）打印月报表 （6）登录CCMS系统
【问题3】
（1）定义该应用系统的边界。
（2）识别出该应用系统所有的角色。
（3）对于所识别的每一个角色，分别确定：
·该角色所参与的每一种业务活动。
·各种业务活动的完整的事件序列。
·激发上述每一个事件序列的角色。
（4）对（3）中确定的事件序列进行分析，去掉其中重复的事件序列。
（5）用结构化的自然语言来描述（4）中确定的每一个事件序列，得到初步确定的每一个用例。
（6）对（5）中初步确定的每一个用例进行分析和必要的重组，采用包含、扩展和概括关系来表示用例之间的关系，最终得到所有的用例。
【问题4】
扩展用例是一个由某个更复杂的用例提取出来的事件序列所构成的用例，以便简化原始用例并扩展其功能。
若几个用例执行了同样的功能步骤，可以把这些公共步骤提取成独立的抽象用例。抽象用例代表了某种形式的重用，可以降低用例之间的冗余。
某银行开通了网上银行业务，其网上贷款的业务流程如下。
（1）客户在网上填写姓名、电子邮件地址、贷款类型、贷款金额、身份证号、通讯地址等信息，提交贷款申请。
（2）在指定的时间内，客户会收到银行的电子邮件，通知贷款是否被批准。
（3）银行根据客户提交的信息，创建贷款申请任务，创建工作由运行在主机上的CICS（客户信息控制系统）完成，同时需要从第三方获得客户的信用审查信息。
（4）由信贷员对该项贷款申请业务进行审批，然后由风险检查系统评估该项贷款的风险程度，风险大的贷款申请被拒绝。
（5）无论批准或者拒绝，结果都会通过邮件系统递交给客户。对于拒绝的贷款申请，还要通知贷款申请任务进行有关操作。
（6）除了信贷员审批环节需要人机交互外，业务是自动进行的。
【问题1】
上述网上贷款业务采用SOA架构来实现。上述业务流程中涉及哪些功能单元？什么是SOA？本题中的案例采用SOA具有哪些优点？请用200字以内文字说明。
【问题2】
请在答题纸上将以下关于SOA的叙述填写完整。
SOA不是一个新鲜事物，但它却是传统的面向对象模型的替代模型。相比较而言，面向对象的模型是 （1） 耦合和 （2） 粒度的，而SOA是 （3） 耦合和 （4） 粒度的。SOA系统原型的一个典型例子是 （5） （CORBA），它已经出现很长时间了，其定义的概念与SOA相似。
随着Web Services的成熟，现在的SOA已经有所发展，这些进展是以 （6） 为基础的。在Web Services中，通过 （7） 来描述接口，与CORBA中的 （8） （接口描述语言）相比，它动态性更强、灵活度更高。
SOA还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的 （9） ，这远胜于以往管理单个应用的方式。通过分析 （10） 间的交互，SOA可以帮助企业了解何时以及什么业务逻辑被切实执行了，这使管理员能够有针对性地优化业务流程。
【问题3】
上述网上贷款系统能够实际应用的基本前提之一是满足金融领域的安全性需求。该系统必须要满足哪些安全方面的需求？请用200字以内的文字简要说明。
本题的试题背景为网上银行贷款业务，实际考查SOA的理论和应用，试题共3个小问题。
【问题1】
第一个问题要求考生回答系统有哪几个功能模块、SOA的定义和优点。
迄今为止，对于SOA还没有一个公认的定义。许多组织从不同的角度和不同的侧面对SOA进行了描述，较为典型的有以下三个。
（1）W3C的定义：SOA是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
（2）Service-architecture.com的定义：服务是精确定义、封装完善、独立于其它服务所处环境和状态的函数。SOA本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
（3）Gartner的定义：SOA是一种C/S架构的软件设计方法，应用由服务和服务使用者组成，SOA与大多数通用的C/S架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。
系统的功能模块可以根据试题描述中给出的流程直接得出。
（1）提交贷款申请：客户在网上填写姓名、电子邮件地址、贷款类型、贷款金额、身份证号、通讯地址等信息。
（2）信用审查：从第三方获得客户的信用审查信息。
（3）创建贷款申请任务：银行根据客户提交的信息，创建贷款申请任务。
（4）风险评估：由风险检查系统评估贷款的风险程度。
（5）审批贷款申请：由信贷员对该项贷款申请业务进行审批。
（6）客户通知：无论批准或者拒绝，结果都会通过邮件系统递交给客户。
【问题2】
第二个问题是对第一个问题的补充，是个填空题，进一步考查SOA的概念，以及与相关概念的比较。
SOA不是一个新鲜事物，但它却是传统的面向对象模型的替代模型。相比较而言，面向对象的模型是紧耦合和细粒度的，而SOA是松耦合和大粒度的。SOA系统原型的一个典型例子是通用对象请求代理结构（CORBA），它已经出现很长时间了，其定义的概念与SOA相似。
随着Web Services的成熟，现在的SOA已经有所发展，这些进展是以XML为基础的。在Web Services中，通过WSDL来描述接口，与CORBA中的IDL（接口描述语言）相比，它动态性更强、灵活度更高。
SOA还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。通过分析服务间的交互，SOA可以帮助企业了解何时以及什么业务逻辑被切实执行了，这使管理员能够有针对性地优化业务流程。
【问题3】
第三个问题是一个安全性试题，考生可以从网络安全、信息安全、交易安全等方面进行回答。具体的安全性问题，请读者阅读本书第6章的相关内容。
【问题1】
（1）该网上贷款业务至少涉及贷款申请、信用审查、信贷员审批、风险检查、电子邮件传送等功能单元。
（2）SOA即面向服务的体系结构是一个软件架构模型，它将业务的不同功能单元（称为服务）通过服务之间的接口（和契约）联系起来。接口独立于实现服务的硬件平台、操作系统和编程语言。
（3）复用银行的各种应用资源（如软件资产）；增强银行各个业务的集成性和灵活性；业务流程变更时便于快速构建应用系统。
【问题2】
（1）紧 （2）细（小）
（3）松 （4）大
（5）通用对象请求代理结构 （6）XML（可扩展标记语言）
（7）WSDL（Web服务描述语言） （8）IDL
（9）相同服务 （10）服务
【问题3】
（1）验证（系统有关角色的身份识别）。
（2）签名（创建及验证类似手写签名的电子签名）。
（3）授权（如信贷员是否具有审批权）。
（4）完整性（发送的数据与接收到的数据是否一致 ）。
（5）机密性（与业务无关的人员不能读取事务中的数据）。
（6）审查（把所有事务记录下来，以便事后验证）。
（7）不可否认性（能由第三方求证事务中发送及收到的是否是同一数据）。
（8）威胁预防（防止间谍程序登录、攻击系统）。
某软件公司接受希赛公司委托开发一个软件任务，该任务由张工负责。张工预计在4周内完成对系统的需求分析，并形成需求规格说明书。张工委派了项目组的小刘来负责需求信息的获取。
两周后，小刘向张工汇报了他进行需求分析的过程及结果。小刘采用问卷调查的方式向希赛公司的50名工作人员搜集信息。他首先准备了问卷的初稿，并请希赛公司的相关管理人员进行了测试和修正；然后将问卷分发给希赛公司的每位工作人员，并要求他们在一周内返还问卷。但到目前为止，小刘只收回了7份问卷。小刘认为自己是完全按照问卷调查的步骤和要求实施的，而问卷的返还率仍然很低。张工听完后，给小刘分析了失败的原因，并提出了一些能够提高问卷返还率的建议。
但是为了不耽误项目的进度，张工决定采用JRP（Joint Requirements Planning，联合需求计划）的方法再次进行需求调查，张工作为JRP的主持人。最终在第4周完成了需求规格说明书，并决定了系统后续阶段的开发计划，如图2-7所示。
图2-7系统开发计划示意图
该项目组除了张工之外，还有2名全职的开发人员，可以承担项目中的任何任务，并且承担同一任务的开发人员总是在一起工作。预计的开发时间中已经包含了编写文档的时间。张工决定采用迭代模型，在160天内完成这三个模块的设计、实现与测试。
【问题1】
用150字以内的文字，说明张工给小刘提出的提高问卷返还率的可能措施。
【问题2】
请用300字以内文字简要说明JRP的基本思想以及保证JRP顺利实施的基本原则。
【问题3】
假设：
（1）整个开发实施两轮迭代；
（2）每个任务都被划分为2个子任务（例如，实现可以划分为实现1和实现2），对应两轮迭代；
（3）完成每个子任务需要花费24人天；
（4）整个系统的集成测试、改正错误及验证需要花费48人天；
（5）第一轮迭代结束时，形成版本v0.5；第二轮迭代结束时，整个系统的开发任务全部完成，形成版本v1.0。
根据上述假设，给出采用迭代模型开发的各里程碑及其完成时间（标出在第几天完成）与交付产品。
本题主要考查需求获取的两种方法：问卷调查和联合需求计划。
收集系统需求的方法有很多种，问卷调查是其中使用得较多一种。用户访谈最大的难处在于很多关键人员时间有限，不容易安排过多的时间。而且，如果用户较多，不可能一一访谈。因此，就需要借助问卷调查，通过精心设计调查表，然后下发到相关的人员手中，让他们填写答案。这样，就可以有效地克服用户访谈方法中存在的问题。
问卷调查表使系统分析师可以从大量的项目干系人处收集信息，甚至当项目干系人在地理上分布很广时，他们仍然能通过问卷调查表来帮助获取需求。一张好的问卷调查表要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷调查表的格式三个重要活动。
（1）确定问题及其类型。与用户访谈一样，问卷调查表上使用的基本问题有开放式问题和封闭式问题。但不同的是，问卷调查表的问题必须非常清楚，组织顺序必须有说服力，必须能够预见用户可能的回答。
（2）编写问题。在具体问题的编写中，要注意使用“用户的语言”，不要使用含糊的词语，但也要避免过度明确的问题，保持问题的简短，避免措词上的偏向。
（3）设计问卷调查表的格式。一份精心设计的、恰当的问卷调查表，能帮助用户克服不愿意回答问题的情形。设计调查表的格式时，应该提供足够的空白空间让用户填写表格。对用户重要的问题放在最前面，内容相似的问题放在一起。
与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。问卷调查最大的不足就是缺乏灵活性，其他缺点还有如下。
（1）双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息，用户也没有机会立即澄清对问题有含糊或错误的回答。
（2）用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。
（3）调查表不利于对问题进行展开的回答，无法了解一些细节问题。
（4）回答者的数量往往比预期的要少，无法保证用户会回答问题或进一步说明所有问题。
因此，较好的做法是将用户访谈和问卷调查结合使用。具体来说，就是先设计问题，制作成为问卷调查表，下发填写完后，进行仔细的分组、整理和分析，以获得基础信息。然后，再针对分析的结果进行小范围的用户访谈，作为补充。
问卷调查的返还率通常比较低，系统分析师在采用问卷调查的方式获取需求时，除了设计适当的问题，选择合适的调查人群之外，一定要事先考虑到如何解决问卷返还率低的问题。
为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。JRP是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。JAD是以小组形式定义和建立系统的，它是由企业主管部门经理、会议主持人、用户、协调人员、IT人员、秘书等共同组成的专题讨论组。由这个专题讨论组来定义并详细说明系统的需求和可选的技术方案。JAD的过程大致如下。
（1）确定JAD项目，主要指确定系统的范围和规范。
（2）在JAD专题预备会上，会议主持人向参与者介绍项目和JAD专题讨论内容。
（3）准备JAD专题讨论材料。
（4）进行JAD专题讨论会，其目的是要达成对需求的一致意见，并对各种可选的技术方案加以讨论，从中研究出几套可供选择的方案。
JAD方法充分发挥了JAD专题讨论会的优势，以使更好地满足用户的需求。使用JAD法，比传统的收集需求的时间更快，可以加速系统开发周期。JAD方法充分发挥了管理人员和用户的积极性，增强了管理人员和用户的责任感，从而使系统开发工作做得更好。
JRP是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
在会议之前，应该将与讨论主题相关的材料提前分发给所有将要参加会议的人。在会议开始之后，按照以下步骤进行。
·首先，应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，针对所列举的问题进行逐项专题讨论。
·然后，对现有系统和类似系统的不足进行开放性交流。鼓励与会者在短时间内说出尽量多的想法，在这一过程中不对这些想法发表任何评论。
·第三步，大家在此基础上对新的解决方案进行一番设想，在这个过程中，需要把这些想法、问题、不足记录下来，形成一个要点清单。
·第四步，针对这个要点清单进行整理，明确优先级，并进行评审。
为了更好地进行以后可能碰到的类似JRP会议，JRP会议后一般会让与会者完成一个评价性的调查问卷。JRP会议最后有一个总结性的报告，主要内容是与会者达成一致的需求和未解决的问题。
JRP的主要意图是收集需求，而不是对需求进行分析和验证。JRP将会起到群策群力的效果，对于一些问题最有歧义的时候、对需求最不清晰的领域都是十分有用的一种方法。这种方法最大的难度是会议的组织和相关人员的能力，要做到言之有物，气氛开放。否则，将难以达到预想的效果。
【问题1】
为了提高问卷返还率，可采取以下措施：
（1）向所有的工作人员解释问卷的目的，以及如何使用这些信息；
（2）说明这份问卷是公司的每个工作人员都要回答的；
（3）拜托相关领导督促他所管辖的工作人员回答问卷，并及时返还；
（4）尽量参加一次这个公司的全体会议，在会议上解答工作人员们提出的问题，并解释这些信息的用处；
（5）更改问卷中的问题，尽量减少回答问卷所花费的时间；
（6）设置一些奖品或奖励，激励大家及时返还问卷。
【问题2】
JRP基本思想是通过召开一系列高度结构化的分组会议，快速地分析问题、定义需求。它是JAD（Joint Application Development）技术的一个子集。JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则。
（1）在JRP实施之前，应制定详细的议程，并严格遵照议程进行。
（2）按照既定的时间安排进行。
（3）尽量完整地记录会议期间的内容。
（4）在讨论期间尽量避免使用专业术语。
（5）充分运用解决冲突的技能。
（6）会议期间应设置充分的间歇时间。
（7）鼓励团队取得一致意见。
（8）保证参加JRP的所有人员能够遵守实现约定的规则。
【问题3】
第24天：完成用户界面的设计1、控制系统的设计1和控制系统的实现1。
第48天：完成硬件抽象层的设计1、用户界面的实现1和控制系统的测试1。
第72天：完成硬件抽象层的实现1、测试1和用户界面的测试1。
第一次迭代完成，交付产品：系统的v0.5。（所有构件的子任务1都完成）。
第96天：完成用户界面、控制系统、硬件抽象层的设计2。
第120天：完成控制系统、硬件抽象层的实现2；用户界面的测试2。
第144天：完成硬件抽象层的测试2、用户界面的实现2和用户界面的测试2。
交付产品：系统的α版（所有构件的子任务2都完成）。
第160天：完成集成测试、用户验证及改正错误。
第二轮迭代完成，交付产品：系统的v1.0。
电子政务是指政府机构利用信息化手段来实现政府职能。
某市房地产交易网站是市建设委员会实施电子政务的门户，网站包括以下栏目：项目公示、业务办理、信息发布、通知公告、政策法规、房地产经纪、在线答疑等，其中业务办理栏目中又包括申办预售许可、期房网上签约、申请预售登记、权属登记申请、现房网上签约、经纪机构管理、评估行业管理等项目，多数的业务办理项目需要管理部门多级审批。
【问题1】
一般而言，电子政务业务分为三个领域，如图2-8电子政务业务模型所示（箭头表示信息的流向）。请在图中（1）、（2）、（3）空中填写恰当的内容。
图2-8电子政务业务模型
【问题2】
电子政务根据其服务的对象不同，基本上可以分为四种模式，即G2G、G2B、G2C、G2E。请根据本题中房地产交易网站的栏目内容，说明该市建设委员会的电子政务系统包括了哪些模式？为什么？
【问题3】
本题中的电子政务项目在进行需求分析时，系统分析师需要有效地获取需求，进行需求建模。需求建模包括域建模、用例建模、组件和服务建模、性能建模等。请用300字以内文字分别简要叙述什么是用例建模、组件和服务建模、性能建模。
【问题4】
系统分析师必须能够与具有不同背景的利益相关者（如政府各个部门、房地产开发企业、购房者等等）进行沟通交流，以提取和细化需求，并向这些利益相关者描述系统的体系结构。请用50字以内文字简要叙述常用的沟通交流技巧。
电子政务是指政府机构利用信息化手段，实现各类政府职能。其核心是：应用信息技术，提高政府事务处理的信息流效率，改善政府组织和公共管理。
【问题1】
根据政府机构的业务形态来看，通常电子政务主要包括三个应用领域。
（1）政务信息查询：面向社会公众和企业组织，为其提供政策、法规、条例和流程的查询服务。
（2）公共政务办公：借助互联网实现政府机构的对外办公，如：申请、申报等，提高政府的运作效率，增加透明度。
（3）政府办公自动化：以信息化手段提高政府机构内部办公的效率，如：公文报送、信息通知和信息查询等。
其业务模型可以用图2-9表示。
图2-9电子政务业务模型
在图2-9中，社会公众和企业主要通过政务信息查询以及公共政务办公与电子政务平台建立沟通，相关事务处理请求通过办公自动化系统中转给政府工作人员，政府工作人员可以通过办公自动化系统进行政务处理及对政务信息查询系统的更新。通过对这一典型业务模型的分析，可以看出在电子政务系统中主要存在以下三种信息流。
（1）政务办公信息流：主要存在于政府机构内部办公的过程中。
（2）公共事务信息流：主要存在于政府机构对外办公的过程中。
（3）政务咨询信息流：主要存在于社会公众和企业查询相关信息的过程中。
【问题2】
第2个问题考查电子政务业务的分类。电子政务根据其服务的对象不同，基本上可以分为G2G、G2B、G2C和G2E四种模式。
（1）政府对政府（Government to Government，G2G）。G2G是指政府上下级之间、不同地区和不同职能部门之间实现的电子政务活动，包括国家和地方基础信息的采集、处理和利用，例如，人口信息、地理信息、资源信息等；政府之间各种业务流程所需要采集和处理的信息，例如，计划管理、经济管理、社会经济统计、公安、国防、国家安全等；政府之间的通信系统，包括各种紧急情况的通报、处理和通信系统。
（2）政府对企业（Government to Business，G2B）。G2B是政府向企业提供的各种公共服务，主要包括政府向企事业单位发布的各种方针、政策、法规和行政规定，即企事业单位从事合法业务活动的环境，包括产业政策、进出口、注册、纳税、工资、劳保、社保等各种规定；政府向企事业单位颁发的各种营业执照、许可证、合格证、质量认证等。
（3）政府对公众（Government to Citizen，G2C）。G2C实际上是政府面向公众所提供的服务。政府对公众的服务首先是信息服务，例如，让公众知道政府的规定是什么，办事程序是什么，主管部门在哪里，以及各种关于社区公安和水、火、天灾等与公共安全有关的信息等，还包括户口、各种证件的管理等政府提供的各种服务。
（4）政府对公务员（Government to Employee，G2E）。G2E是指政府与政府公务员即政府雇员之间的电子政务，也有学者把它称为内部效率效能电子政务模式。G2E是政府机构通过网络技术实现内部电子化管理（例如，OA系统等）的重要形式，也是G2G、G2B和G2C的基础。G2E主要是利用Intranet建立起有效的行政办公和员工管理体系，为提高政府工作效率和公务员管理水平服务。
【问题3】
第3个问题考查域建模、用例建模、组件和服务建模、性能建模的概念。
域建模是指为问题域创建相应的模型并且把它划分为若干个内聚组的过程。域模型是一种用于理解问题域的工具。要构造域模型，必须完成下列工作。
（1）标识并确定参与者（实体）及其操作（活动）的特征。
（2）标识管理操作（规则）的策略。
（3）收集有关实现这些操作、来自这些操作或者记录这些操作（构件/数据）的信息。
（4）将相关的要素划分为子域。
（5）确定结果域（核心的/通用的/外部的）以及它们之间交互的特征。
用例模型描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。
用例建模建立反映系统行为的动态模型，用例模型描述了各种参与者和要分析的系统之间的主要交互。
组件模型为子系统、模块和组件的层次结构分配需求和职责。服务模型将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。
性能建模是通过各种各样的方式来度量性能。必须考虑性能建模过程中如下几个方面。
（1）构建和部署应用程序的速度如何？
（2）构建、维护和运行需要多少花费？
（3）该应用程序能在多大程度上满足其需求？
（4）对于必须使用该应用程序的人来说，需要为其付出多大的开销？
（5）该应用程序会对其他应用程序和基础结构产生怎样的影响？
关于这些问题（和无数的其他问题，这取决于具体情况）的答案，对一个成功的应用程序来说是至关重要的，并且通常称其为应用程序在架构上的质量。对这些质量进行建模是很困难的，甚至比性能的标准质量更困难。
【问题4】
第4个问题考查获得需求的沟通与交流技巧，这是经常考查的一个内容。作为一名系统分析师，掌握各种不同的需求获取技术，并且熟练地在实践中运用它，是十分必要的。
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是一件看上去很简单，做起来却很难的事情。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，需求获取只有通过系统分析师与用户的有效合作才能成功。系统分析师必须建立一个对问题进行彻底探讨的环境，而这些问题与将要开发的系统有关。让用户明确了解，对于某些功能的讨论并不意味着即将在系统中实现它。
需求获取的方法主要有收集资料、开调查会、个别访问、书面调查、抽样调查、现场观摩、参加业务实践和阅读历史文档等。其他的方法还有通过原型进行演示，通过书面或电子邮件等手段与用户交流等。
【问题1】
（1）政府办公自动化（或办公自动化系统）
（2）政务信息查询（或政务信息发布系统）
（3）公共政务办公（或政务业务办理系统）
【问题2】
G2B，栏目中有申办预售许可、申请预售登记等，针对房地产开发商企业。
G2C，栏目中有权属登记申请等，主要是针对购房个人。
G2E，因为题目中指出多数业务办理项目需要政府主管部门多级审批，所以系统后台还包括了办公自动化系统。
【问题3】
用例建模描述各种参与者（人和其他系统）和系统之间的主要交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。
组件建模确定系统的子系统、模块和组件结构，为子系统、模块分配需求和职责，每个组件元素作为一个自包含的单元，用于开发、部署和执行。服务建模提供了通用的应用程序，并将应用程序定义为一组抽象服务接口。
性能建模是对系统的性能进行度量，为每个组件确定性能指标。包括执行时间、资源使用、开发复杂性、维护复杂性等质量属性。
【问题4】
调查、访谈、演示、组交互（会议）、书面交流（电子邮件）等。
希赛公司为网络音像制品销售公司W重新开发一套影音产品在线管理及销售系统，以改进原有系统AVMSS中存在的问题。在系统需求分析阶段，完成的工作包括如下。
1．系统分析师老王利用PIECES框架组织了系统需要获取的非功能性需求，如表2-5所示。
表2-5非功能性需求
2．项目组小赵从W公司客户代表处了解到现有系统中经常有会员拒绝履行订单，并将其作为问题记录了下来。老王指出了小赵并未发现系统真正的问题，并以会员拒绝履行订单为例，利用如图2-10所示的鱼骨图分析了系统中真正存在的问题。
图2-10鱼骨图
3．获取到相应的需求之后，将需求记录下来形成需求定义文档，同其他项目信息合并形成需求陈述，作为需求分析阶段最终的交付成果。
【问题1】
PIECES框架的主要作用是什么？请将以下需要获取的需求（1）～（8）根据PIECES框架进行分类并将序号填入表2-5对应的单元格内。
（1）系统能否采用新方法以降低使用资源的成本？
（2）系统可接受的吞吐率是多少？
（3）系统可接受的响应时间是多少？
（4）应该减少多少开支或增加多少收益？
（5）对用户隐私有什么要求？
（6）对系统的可靠性和可用性有什么要求？
（7）系统中需要包括哪些文档和培训材料？
（8）对外部系统的接口是什么？
【问题2】
请将下列问题按照不同的类型序号填入图2-10所示的鱼骨图（g）～（n）中。
（1）缺少强制履行合同的规定；
（2）合同相关信息没有通知到会员；
（3）没有催单提示客户；
（4）没有跟踪执行情况；
（5）设备成本太高造成价格不合理；
（6）合同的履行缺乏灵活性；
（7）账务问题或者隐瞒相关内容；
（8）价格太高并且无法修改。
【问题3】
一份需求定义文档应该包括哪些内容？对于与系统开发相关的人员：系统所有者、用户、系统分析人员、设计人员和构造人员、项目经理，需求定义文档各有什么作用？
软件需求分析是在项目初始研究的基础上进行的，是系统开发中最重要和技术性最强的工作，一般是由系统分析师实施完成的。需求分析的主要任务是分析系统功能、信息和外部接口及新的需求。需求分析是一个由实际业务流程到信息处理流程的抽象过程，最终建立所需信息系统的逻辑模型。在需求分析阶段，常需要借助很多图形工具使得分析过程可视化，便于分析和与用户交流。问题分析所采用的PIECES框架和因果分析方法中的鱼骨图是两种普遍使用的可视化分析技术，也是合格的系统分析师必须掌握的技能。
本题主要考查考生对系统分析方法和工具的掌握情况，特别是PIECES框架和鱼骨图两种技术。本题结合一个典型的实际项目案例，首先要求考生基于PIECES框架分析业务系统非功能性需求的类型，然后根据一个具体的实际问题，利用鱼骨图分析该问题产生的原因及其类别，最后结合需求分析的结果完成需求分析阶段的交付成果——需求定义文档。
【问题1】
PIECES框架是系统非功能性需求分类的技术，对各种类型的需求进行分类，使得类似的需求可以组织起来，达到汇报、跟踪和验证的目的，还可能帮助确定可能忽略的需求。PIECES框架能够完整、准确、快速地确定信息系统的需求，确认业务中存在的问题、机会和改进目标，包括：
·性能（Performance），表示提高系统的性能；
·信息（Information），表示提高信息的质量和改变信息的处理方式；
·经济（Economics），表示改善组织的成本、效益等经济状况；
·控制（Control），表示提高信息系统的安全和控制水平；
·效益（Efficiency），表示提高组织的人、财、物等使用效率；
·服务（Service），表示将要提高组织对客户、供应厂商、合作伙伴、顾客等的服务质量。
通过研究PIECES框架中类别或子类中的内容，可以发现系统中潜在的非功能性需求。PIECES框架的内容如表2-6所示。
表2-6PIECES框架的内容
续表
根据组织现有信息系统的当前情况，按照PIECES方法逐个回答问题。通过对这些回答进行分析，就找到了当前系统存在的问题、机会以及新系统应该达到的目标。
在本题中，要求考生熟悉PIECES框架中不同需求类型之间的差异，能够根据实际应用需求判断需求的类别。
（1）“降低使用资源的成本”是提高效益的方法。
（2）“吞吐率”属于系统性能指标。
（3）“响应时间”属于系统性能指标。
（4）“减少开支和增加收益”是系统经济性指标。
（5）“用户隐私”属于安全性控制的内容。
（6）“可靠性和可用性”是系统所提供服务的质量属性。
（7）“文档和培训材料”是为用户提供的服务。
（8）“外部系统的接口”说明系统与外界交互的信息需求。
【问题2】
因果图（石川馨图、鱼刺图、鱼骨图）是一种特殊的流程图，直观地显示出各项因素如何与各种潜在问题或结果联系起来。利用因果图可以将在产品后端发现的有关质量问题，一直追溯到负有责任的生产行为，从生产的源头找出质量原因，真正获得质量的改进和提高，如图2-11所示。
图2-11因果图的基本形式
因果图法是全球广泛采用的一项技术。该技术首先确定结果（质量问题），然后分析造成这种结果的原因。每个分支都代表着可能的差错原因，用于查明质量问题可能所在和设立相应检验点。它可以帮助项目班子事先估计可能会发生哪些质量问题，然后，帮助制定解决这些问题的途径和方法。
一般来说，造成质量问题的原因主要有人、设备、材料、方法和环境等5个方面，即4M1E因素，所以可以预先将这5个因素列入原因虚线的方框中，然后将各种原因，从大到小，从粗到细分解，直到能够采取措施消除这些原因为止。绘制因果图的6个步骤如下。
（1）确定问题。通常用其他统计过程控制工具，例如帕累托分析、直方图和控制图、头脑风暴法等，其结果可以对问题进行简洁、清晰的描述。
（2）选择各学科的头脑风暴班子。按照确定问题所需要的技术、分析和管理知识来选择不同学科的专家组成的头脑风暴班子。
（3）画问题框和主箭头。包括用于因果评价的问题说明，主箭头作为主要类别的分类基础。
（4）具体化的主要分类。确定问题框中所说问题的主要类别。问题主要原因的几个基本类别是4M1E，其他类别可以具体说明，根据情况而定。
（5）识别问题原因。当已经识别问题的主要原因时，可以确定与每一类主要因素相关的原因。这里可以用到随机方法、系统方法和过程分析方法。
（6）确定纠正措施。根据识别的原因，找到纠正问题的措施。
在本题中，要求考生熟悉鱼骨图中不同类型原因之间的差异，能够根据实际应用问题判断产生该问题的原因的类别。
（1）“缺少强制履行合同的规定”属于系统开发策略的范畴。
（2）“合同相关信息没有通知到会员”是相关人员工作没有完成。
（3）“没有催单警告用户”是所采用的方法不正确。
（4）“没有跟踪执行情况”是所采用的方法不正确。
（5）“设备成本太高造成价格不合理”是所购买材料价格高。
（6）“合同履行缺乏灵活性”是合同执行的问题。
（7）“财务问题或隐瞒相关内容”属于财务人员工作问题。
（8）“价格太高并且无法修改”是指合同中价格条款。
【问题3】
本题要求考生能够准确掌握需求定义文档的组成部分，和需求定义文档对不同的系统开发关联人员对其工作的具体作用。
软件需求规格说明书（Software Requirement Specification，SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。
在国家标准GB/T8567-2006中，提供了一个SRS的文档模板和编写指南，其中规定SRS应该包括以下几个部分内容。
（1）范围。本部分包括SRS适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号；简述SRS适用的系统和软件的用途，描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、承建方和支持机构；标识当前和计划的运行现场；列出其他有关的文档；概述SRS的用途和内容，并描述与其使用有关的保密性和私密性的要求；说明编写SRS所依据的基线。
（2）引用文件。列出SRS中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。
（3）需求。这一部分是SRS的主体部分，详细描述软件需求，可以分为以下项目：所需的状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求（包括硬件需求、硬件资源利用需求、软件需求和通信需求）、软件质量因素、设计和实现约束、数据、操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求，以及需求的优先次序和关键程度。
（4）合格性规定。这一部分定义一组合格性的方法，对于第（3）部分中的每个需求，指定所使用的方法，以确保需求得到满足。合格性方法包括演示、测试、分析、审查和特殊的合格性方法（例如，专用工具、技术、过程、设施和验收限制等）。
（5）需求可追踪性。这一部分包括从SRS中每个软件配置项的需求到其涉及的系统（或子系统）需求的双向可追踪性。
（6）尚未解决的问题。如果有必要，可以在这一部分说明软件需求中的尚未解决的遗留问题。
（7）注解。包含有助于理解SRS的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解SRS需要的术语和定义，所有缩略语和它们在SRS中的含义的字母序列表。
（8）附录。提供那些为便于维护SRS而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。
【问题1】
PIECES框架是系统非功能性需求分类的技术，对各种类型的需求进行分类使得类似的需求可以组织起来达到汇报、跟踪和验证的目的，还可能帮助确定可能忽略的需求。
（a）：（2）（3）
（b）：（8）
（c）：（4）
（d）：（5）
（e）：（1）
（f）：（6）（7）
【问题2】
（g）和（h）：（2）和（7）
（i）和（j）：（3）和（4）
（k）和（l）：（6）和（8）
（m）：（5）
（n）：（1）
【问题3】
一份需求定义文档可能是项目文档中被阅读和引用得最多的文档。应该包含以下内容：
·系统应该提供的功能和服务；
·非功能需求，包括系统的特征、特点和属性；
·限制系统开发或者系统运行必须遵守的约束条件；
·系统必须连接的其他系统的信息。
系统所有者和用户使用需求定义文档来确认需求以及任何可能产生的变化，并作为验收的依据；系统分析人员、设计人员和构造人员使用它来理解需要什么以及处理需求变更，开发用于验证系统的测试用例；项目经理使用它作为制定项目计划、处理变更及验收的依据。
某软件公司拟为物流企业开发一套库存管理系统，该系统的部分需求陈述如下。
（1）库存管理系统主要包括货物入库管理、货物出库管理、仓库管理、统计报表和系统管理等功能。
（2）库存管理系统的用户包括仓库管理员、仓库经理和系统管理员，用户必须在注册后才能使用系统功能；用户可以选择使用邮件注册或电话注册。
（3）仓库管理员在进行出入库操作前必须先登录；仓库经理可以通过系统查看统计报表，如果前一个月的报表未生成，则系统自动生成统计报表，否则直接显示。
（4）系统管理员可以在系统中设置仓库温度范围，当仓库内温度超过最高值或者低于最低值时，系统自动调用温控管理操作，连接温度调节系统进行制冷或加热。
（5）仓库管理功能要求每个月1日零点对前一个月货物入库和出库记录进行数据汇总操作。项目组决定构造用例模型以描述系统需求。
【问题1】
用例建模的首要任务是识别系统中的参与者。请根据题目中所描述的需求，识别出系统中有哪些参与者？
【问题2】
用例建模的主要工作是书写用例规约。用例规约通常包括哪几部分内容？
【问题3】
建立了用例模型后，可以利用用例之间的关系调整用例模型，用例之间的关系包括哪几种？对于每种关系，请根据题目中所描述的需求分别给出一组用例。
用例模型的参与者：用户、仓库管理员、仓库经理、系统管理员。
用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。下面以一个例题来说明用例之间的几种关系，例题的案例背景是希赛在线教育平台开发，其用例图如图2-12所示。
图2-12用例图
（1）包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。例如，图2-12中的“学习课程”和“课程测试”两个用例都需要检查学员的权限，为此，可以定义一个抽象用例“检查权限”。用例“学习课程”和“课程测试”与用例“检查权限”之间的关系就是包含关系，如图2-13所示。其中“<<include>>”是包含关系的构造型，箭头指向抽象用例。
图2-13包含关系的例子
当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中重复地描述这段事件流，也可以防止这段事件流在不同用例中的描述出现不一致。当需要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也可以将某一段事件流抽象成为一个被包含的用例。
（2）扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。例如，图2-12中的学员进行“课程测试”时，其测试的次数可能已超出系统规定的限额，这时就需要学员“充入学习币”。用例“课程测试”和“充入学习币”之间的关系就是扩展关系，如图2-14所示。其中“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
图2-14扩展关系的例子
（3）泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。例如，图2-12中学员进行课程注册时，假设既可以通过电话注册，也可以通过网上注册，则“注册课程”用例就是“电话注册”用例和“网上注册”用例的泛化，如图2-15所示。其中三角箭头指向父用例。
在本题中，“出入库操作”与“登录”属于包含关系；“查看统计报表”与“生成统计报表”属于扩展关系；“用户注册”与“邮件注册”和“电话注册”属于典型的泛化关系。
图2-15泛化关系的例子
【问题1】
用例模型的参与者：用户、仓库管理员、仓库经理、系统管理员。
【问题2】
用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
【问题3】
（1）用例之间的关系包括：包含关系、扩展关系、泛化关系。
（2）“出入库操作”与“登录”属于包含关系；“查看统计报表”与“生成统计报表”属于扩展关系；“用户注册”与“邮件注册”和“电话注册”属于典型的泛化关系。