山东大学软件学院软件需求分析与设计复习题答案.doc

山东大学软件学院软件需求分析与设计复习题答案
以下内容是曲文博同学整理提供！在此深表感谢！

一、基本概念
1. OOA/OOD：
面向对象分析方法（Object-Oriented Analysis，OOA），是确定需求或者业务的角度，按照面向对象的思想来分析业务。是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。
面向对象设计（Object-Oriented Design，OOD）方法是OO方法中一个中间过渡环节。其主要作用是对OOA分析的结果作进一步的规范化整理，以便能够被OOP直接接受。是一种解决软件问题的设计范式（paradigm），一种抽象的范式。
2. 迭代开发：
是统一开发过程的关键实践
开发被组织成一系列固定的短期小项目
每次迭代都产生经过测试、集成并可执行的局部系统
每次迭代都具有各自的需求分析、设计、实现和测试
随着时间和一次次迭代，系统增量式完善
反馈和调整使规格说明和设计不断进化。
如果问到特征，就写下面的，没问就不用写。
迭代式开发特征：
1、在进行大规模的投资之前就解决了关键的风险分析。
2、使得早期的用户反馈在初始迭代中就能出现。
3、对各个目标里程碑提供了短期的焦点（阶段性的中心）。
4、对过程的测量是通过对实现的评定（而不仅仅是文档）来进行的。
可以对局部的实现进行部署。
3. UP：
UP（Unified Process） 是软件工程的过程，是一种指导软件开发活动的方法。提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。统一过程模型是一种“用例驱动，以体系结构为核心，迭代及增量”的软件过程框架，由UML方法和工具支持。
如果问到RUP，就写下面的，没问就不用写。
RUP（Rational Unified Process），是对统一过程的详细细化。
4. FURPS+：
是指功能（function）、易用性（usability）、可靠度（reliability）、性能（performance）、可支持性（supportability）以及辅助性和次要因素，它是一种识别软件质量属性的模型也可以说是需求的类型。
以下是详细的回答。
– 功能性（ Functional）:特性、功能、安全性
– 可用性（Usability）:人性化因素、帮助、文档
– 可靠性（Reliability）:故障频率、可恢复性、可预测性
– 性能（Performance）:响应时间、吞吐量、准确性、有效性、资源利用率
– 可支持性（Supportablity）:适应性、可维护性、国际化、可配置性
– ＋：辅助性和次要因素
– 实现（implementation）:资源限制、语言和工具、硬件等
– 接口（Interface）:强加于外部系统接口之上的约束
– 操作（operation):对其操作设置的系统管理
– 包装（Packaging）:物理包装盒
– 授权（Legal）:许可证或其他方式
5. 用例：
就是一组相关的成功和失败场景集合，用来描述参及者如何使用系统来实现目标。
6. 敏捷建模：
敏捷建模(Agile Modeling，AM)是一种基于实践的软件过程，它的范围包括描述如何建模以及以一种高效而敏捷的方式编写文档。理想情况下，AM的实践应该用来促进其它更完整的软件过程。
7. 领域模型：
是对领域内的概念类或现实世界中对象的可视化表示，也称概念模型、领域对象模型和分析对象模型，是领域概念的可视化，类似于领域实体的静态信息模型。在UP中，是对现实世界概念类的表示，而非软件对象的表示，该术语并不是指用来描述软件类、软件构架类领域层或有职责软件对象的一组图。UP领域模型是UP业务对象模型的特化， 专注于特定领域，领域模型主要是在特定群体中用于理解和沟通的工具。有效的领域模型捕获了当前需求语境下的本质抽象和理解领域所需要的信息，并且可以帮助人们理解领域的概念、术语和关系。
8. 设计模式：
模式是对问题和解决方案的已命名描述，它可以用于新的语境，为在变化环境中如何运用和权衡其解决方案给出建议，好的模式是成对的问题/解决方案，并且具有广为人知的名称。
9. GRASP
通用职责分配软件模式（General Responsibility Assignment Software Patterns.）是一种基于职责的设计，GRASP原则或模式包括：–、创建者（Creator）、控制器（Cotroller）、纯虚构（Pure Fabrication）、信息专家（Information Expert）、高内聚（High Cohesion）、间接性（Indirection）、低耦合（Low Coupling）、多态性（Polymorphism）、防止变异（Protected Variations）。
10. SAD文档
描述有关架构的总体想法，包含架构分析的关键决策，可以帮助开发人员理解系统的基本概念。
二、简答
（1）您如何看待面向对象的分析、设计和实现。
OO（ Object-Oriented -面向对象）方法基于的“世界观”，世界是由对象构成的,对象有其自己的属性和内部运动规律，对象之间的相互作用，构成了大千世界的各式各样的不同系统。面向对象方法的解决问题的思路是从现实世界中的客观对象（如人和事物）入手，尽量运用人类的自然思维方式来构造软件系统。
面向对象=对象(object)+分类(classfication)+继承(inheritance)+通过消息(message)的通信。
（2）说明迭代和进化式开发过程。
是一种及传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了定义、需求分析、设计、实现及测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。
（3）统一过程UP的阶段有哪些，每一阶段的工作和目标是什么。
统一过程UP有四个阶段：初始阶段、细化阶段、构造阶段、移交阶段。
初始：大体上的构想，业务案例，范围和模糊评估，主要目的是建立项目的范围和版本,确定项目目标的可行性和稳定性,制品包括需求和用例。
细化：已精化的构想，核心架构的迭代实现，高风险的解决，确定大多数需求的范围以及进行更为实际的评估，该阶段的目的是对问题域进行分析,精细化需求和开始架构设计,确定实现的可行性和稳定性,制品包括系统架构，问题领域、精化后的需求及设计等相关文档。
构造： 对遗留下来的风险较低和比较简单的元素进行迭代和实现，准备部署。制品包括精化的设计等相关文档。
移交：进行Beta测试和部署。
（4）说明统一过程UP中业务建模科目需要完成的工作，涉及的所有制品的名称和作用。
业务建模（business Modeling）,其用途是理解和沟通“将要部署系统的组织结构和动态特征”，通过敏捷建模和需求讨论会的实践，完成领域模型。
领域模型是对所关注的现实世界领域中事物的可视化，是领域概念的可视化，类似于领域实体的静态信息模型。领域模型的作用主要是在特定群体中用于理解和沟通的工具；捕获当前需求语境下的本质抽象和理解领域所需要的信息，并且可以帮助人们理解领域的概念、术语和关系；将那些及当前需求无关的概念类排除在问题域之外。
（5）说明统一过程UP中需求科目需要完成的工作，涉及的所有制品的名称和作用。
需求科目需要完成需求讨论会、设想包装练习、计点投票表决工作，产出用例模型、设想、补充性规格说明及词汇表等制品。
用例模型，用来描述功能需求。
补充性规格说明，捕获用例或词汇表难以描述的其他需求、信息和约束，如报表，文档、包装可支持性、许可授权。
设想, 概述了对项目的“设想”。即执行摘要。为项目主要思想提供简洁描述。
词汇表，捕获术语和定义，也可起到数据字典的作用。
（6）说明统一过程UP中设计科目需要完成的工作，涉及的所有制品的名称和作用。
敏捷建模科目需要通过完成敏捷建模、测试驱动开发来产出设计模型、软件架构文档、数据模型。
设计模型，描述逻辑设计的一组图，包括软件类图、对象交互图、包图等。
软件架构文档，学习辅助工具，概括关键架构问题及其在设计中的解决方案。该文档是对重要设计思想及其在系统中动机的概要。
数据模型，包括数据库方案，以及在对象和非对象表示之间的映射的策略。
（7）系统的用例模型包括哪些内容，如何确定系统的用例？用例之间的关系有哪几种？请说明用例编写的规则。
用例模型包括：
用例图(Use Case Diagram)、用例规约(Use Case Specification)两部分内容，主要由参及者(Actor)、用例(Use Case)、通讯关联(Communication Association)等模型元素构成。
用例确定：
选择系统边界，确定主要参及者，确定每个参及者的目标，定义满足用户目标的用例，根据其目标对用例进行命名。
用例之间的关系：
包含(include)、扩展(extend)和泛化(generalization)。
编写规则如下：
1. 以无用户界面约束的本质风格编写用例，以本质风格编写用例；剔除用户界面并且关注参及者的意图
2. 编写简洁的用例
3. 编写黑盒用例，不对系统内部工作、构件或设计进行描述，通过职责来描述系统，描述做什么，不描述如何做。
4. 采用参及者及参及者目标的视点，关注系统的用户或参及者来编写需求，询问其目标和典型情况并关注理解参及者所考虑的有价值结果
5. 寻找主要参及者和目标
6. 用例名称应使用动词开头
（8）什么是领域模型？为什么要创建领域模型？如何创建领域模型？举例说明其中每一步的做法。
“领域模型” 含义：
1.在UP及本课中， “领域模型”是现实世界中对象的概念透视图，而非软件透视图。
2.“软件对象的领域层”：
在表示层或UI层之下的软件对象层
是由领域对象（domain object）组成的——领域对象是表示问题空间事物的软件对象
及“业务逻辑”或“领域逻辑”方法相关。
领域模型的作用：
主要是在特定群体中用于理解和沟通的工具；捕获当前需求语境下的本质抽象和理解领域所需要的信息，并且可以帮助人们理解领域的概念、术语和关系；将那些及当前需求无关的概念类排除在问题域之外。
如何创建领域模型
– 寻找概念类
• 重用和修改现有的模型
• 使用分类列表
• 确定名词短语
– 将其绘制为UML类图中的类
– 添加关联和属性
（9） 什么是系统顺序图？说明为什么使用系统顺序图。系统顺序图和用例之间 的关系是什么？
系统顺序图SSD展示了直接及系统交互的外部参及者、系统（作为黑盒）以及由参及者发起的系统事件，时间顺序是自上而下的，并且事件的顺序应该遵循其在场景中的顺序。表示了对于用例的一个特定场景，外部参及者产生的事件，其顺序和系统之内的事件，它是用例模型的一部分——将用例场景中的交互可视化。是为阐述及所讨论系统相关的输入和输出事件而快速、简单地创建的制品。确定系统操作消息，它是合作对象交互图中的开始消息。
（10） 什么是逻辑架构和层，请说明使用层的好处。给出一个比较常见的软件分层逻辑结构。
逻辑架构是软件类的宏观组织结构，他将软件类组织为包（命名空间）、子系统和层，没有决定如何在不同的操作系统或网络层中物理的计算机上对这些元素进行部署。
层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责, 严格的分层，高层可以调用相邻较底层的服务。宽松的分层架构,较高层可以调用其下任何层的服务。
OO系统中通常包括的层有：
1. 用户界面
2. 应用逻辑和领域对象－表示领域概念的软件对象, （例如软件类Sale），这些对象实现了应用需求，例如计算销售总额；
3. 技术服务－提供支持技术服务的常用对象和子系统,例如数据库接口或错误日志。这些服务通常是独立于应用的，也可在多个系统中复用。
（11） 架构中的领域层和领域模型之间的关系是什么？
领域模型描述了软件架构的领域层软件领域对象的名称和属性。
“领域模型”：现实世界中对象的概念透视图。
“领域层”：在表示层或UI层之下的软件对象层。
有时间的话画下图：

（12） 系统顺序图、系统操作和三层架构中的层之间的联系是什么？
a) 系统顺序图（SSD）中确定系统操作，它描述了系统操作。
b) 系统顺序图（SSD）展示了系统事件，系统操作用于处理输入的系统事件。
c) 捕获这些系统操作请求的对象通常是系统UI层的对象
d) UI层对象将从UI层向领域层转发（或委派）请求以进行处理
e) 从UI层发送到领域层的消息将是系统顺序图（SSD）中所描述的消息，例如enterItem.
（13） 说明模型—视图分离原则。为什么将模型及视图进行分离？
原则：
– 不要将非UI对象直接及UI对象连接或耦合
UI对象及某个应用相关，而（理想情况下）非UI对象可以在新应用中重用或附加到新界面。
– 不要在UI对象方法中加入应用逻辑
UI对象应该只初始化UI元素、接收UI事件、将应用逻辑的请求委派到非UI对象
– MVC中模型对象不应直接及视图对象连接
– 观察者模式
领域对象只能通过propertylistener的接口向视图的UI对象发送消息
动机：
– 支持内聚的模型定义，这些定义只关注领域过程，而不是用户界面
– 允许对模型和用户界面层分别进行开发
– 使界面的需求变更对领域层的影响最小化
– 允许新视图能够方便地连接到现有的领域层之上，而不会对领域层产生影响
– 允许对同一模型对象同时使用多个视图
– 允许模型层的运行不依赖于用户界面
– 允许模型层能够简单地移植到另一用户界面
（14） 在对象设计中如何理解软件对象的职责，职责驱动设计的基本思想是什么。
软件对象的职责:
由于软件领域中对象根据不同场景可以扮演不同角色，对象的方法可以看成这些角色不同职责的表现。
职责驱动方式:
• 把软件对象想象成为具有某种职责的人，它要及其他人协作以完成职责
• 职责定义为“类元”的契约和责任
• 职责主要分为两种类型：
– 行为职责
• 自身执行一些行为，如创建对象或计算
• 初始化其他对象中的动作
• 控制和协调其他对象中的活动
– 认知职责
• 对私有封装数据的认识
• 对相关对象的认知
• 对其能够导出或计算的事物的认知
• 在对象设计中，职责是被分配给对象类的.
– 例如“一个负责产生一个SalesLineItem类”(一个行为型职责);又如,“一个Sale类知道sale对象的total”（一个认知型职责）.
• 准则：对于软件领域对象来说，由于描述了领域对象的属性和关联。因此其通常能够从领域模型中产生及认知型相关的职责。
-例：如果领域模型中的Sale类具有time属性，由此可知道软件的Sale类应该知道其产生的时间。
（15） 谈谈您对架构的理解，SAD文档的结构。
• 架构的理解
架构是一组重要决策，涉及软件系统的组织，对结构元素及其组成系统所用接口的选择，从这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。共同主题涉及动机、约束、模式、职责和系统连接。
• 软件架构文档SAD文档的结构：
架构表示
（概括介绍文档中如何描述架构，例如：使用技术备忘录和架构视图，对于技术备忘录或视图不熟悉的人有用，注意并非所有视图都是必要的）
架构因素
（参考补充性规格说明）
架构决策
（概括决策的一组技术备忘录）
逻辑视图
（主要元素的UML包图和类图，对主要构件的大尺度结构和功能的解说）
部署视图
（UML部署图显示了节点以及进程和构件的分配。有关网络的注解）
进程视图
（解释系统进程和线程的UML类图和交互图，基于交互的线程和进程对此进行组织，有关进程间的通讯如何工作的解释）
用例视图
（简要概括了构架上最重要的用例，某些构架上重要的用例实现或场景的UML交互图，以及在图中解释如何描述主要构架元素的注释）
其他视图
…
（16） 请谈谈架构设计中一般要考虑的架构因素以及架构设计文档主要内容。
架构因素：
组织因素、过程因素及参及开发人员因素、技术因素。（来自互联网的答案，没找到ppt中提到的参见33.6节补充规格说明书中重要架构需求的因素表）
架构设计文档主要内容：
描述有关架构的总体想法、架构分析的关键决策及系统的基本概念。
基于N+1视图模型创建
• N+1（4＋1）视图模型
– 逻辑
– 进程
– 部署
– 数据
（“＋1”）用例视图
包括以下结构：
架构表示
（概括介绍文档中如何描述架构，例如：使用技术备忘录和架构视图，对于技术备忘录或视图不熟悉的人有用，注意并非所有视图都是必要的）
架构因素
（参考补充性规格说明）
架构决策
（概括决策的一组技术备忘录）
逻辑视图
（主要元素的UML包图和类图，对主要构件的大尺度结构和功能的解说）
部署视图
（UML部署图显示了节点以及进程和构件的分配。有关网络的注解）
进程视图
（解释系统进程和线程的UML类图和交互图，基于交互的线程和进程对此进行组织，有关进程间的通讯如何工作的解释）
用例视图
（简要概括了构架上最重要的用例，某些构架上重要的用例实现或场景的UML交互图，以及在图中解释如何描述主要构架元素的注释）
其他视图
…

（17） 看懂给定的类图和顺序图，解释其中表达的含义。
三、请给出下列设计模式的含义，包括名称、问题和解决方案，并举例说明在什么情况下可以使用该模式
（1）信息专家
名称
信息专家（Information Expert）
问题
给对象分配职责基本原则是什么
解决方案
把职责分配给具有完成该职责所需信息的那个类
举例
NextGen POS应用系统中，某个类需要知道一次销售的总额。
（2）适配器
名称
适配器（Adapter）
问题
如何解决不相容的接口问题，或者如何为具有不同接口的类似构件提供稳定的接口
解决方案
通过中介适配器对象，将构件的原有接口转换为其他接口
增加一层间接性对象，通过这些对象将不同的外部接口调整为在应用程序内使用的一致接口
举例
NextGen POS应用系统中的SOAP over HTTP远程访问SAPSystem时用到适配器模式。
（3）外观
名称
外观（Facade）
问题
对一组完全不同的实现或接口需要公共、统一的接口。可能会及子系统内部的大量事物产生耦合，或者子系统的实现可能会改变。怎么办
解决方案
对子系统定义唯一的接触点－使用外观对象封装子系统。该外观对象提供了唯一和统一的接口，并负责及子系统构件进行协作
相关模式
外观通常通过单实例类模式进行访问
举例
我们把一个文件，放在了第二抽屉里，而第二个抽屉的钥匙放在了第一个抽屉里，我们要想取出这个文件，第一步肯定要拿到第一个抽屉的钥匙，然后打开它再拿出第二个抽屉的钥匙，最后打开第二个抽屉取出文件。（两个抽屉还好说，但如果是n个呢？）所以对于客户来说，这些取钥匙的过程不需要知道，他们只需要按一个按钮，然后文件就自动取出来。

（4）高内聚
名称
高内聚（High Cohesion）
问题
怎样使对象保持内聚，可理解和可管理，同时具有支持低耦合的附加作用
解决方案
职责分配应保持高内聚，以此来评估备选方案
内聚性较低的类要做许多互不相关的工作或需要完成大量的工作，导致的问题
• 难以理解
• 难以复用
• 难以维护
• 脆弱，经常会受到变化的影响
举例
一个名为RDBInterface的类，它只负责及关系数据库的交互的部分。它及许多访问数据库的其它类进行交互来检索或存储对象。

（5）创建者
名称
创建者（Creator）
问题
谁创建了A
解决方案
如果下列条件之一为真时（越多越好），将创建类A实例的职责分配给类B:
• B”包含”或组成聚集了A
• B记录A
• B紧密地使用A
• B具有A的初始化数据，并且在创建A时会将这些数据传递A，对A的创建而言，B是专家
如果有一个以上的选项适用，通常首选聚集或者包含A的类B
举例
在NextGen POS应用中，Sale负责创建SalesLineItem的实例

四、请给出小型超市POS系统的详细的需求分析，要求收银员能完成最基本的销售任务，包括所售商品的输入，总额的计算，以及现金支付等功能。
（1）业务建模：请给出相应的概念类和概念类之间的关系描述。

（2）用例场景描述：请给出销售主场景的描述。

主成功场景
1、顾客携带所购商品或服务到POS机付款处进行购买交易
2、收银员开始一次新的销售交易
3、收银员输入商品标识
4、系统逐条记录出售的商品，并显示该商品项目的描述、价格和累计额。价格通过一组价格规则来计算
收银员重复3－4步，直到结束
5、系统显示总额和所计算的税金
6、收银员告知顾客总额，并提请付款
7、顾客支付，系统处理支付
8、系统记录完整的销售信息，并将销售和支付信息发送到外部的帐务系统（进行帐务处理和提成）和库存系统（更新库存）
9、系统打印票据
10、顾客携带商品和票据（如果有）离开
扩展
…
7a. 现金支付
1、收银员输入收取的现金额
2、系统显示找零金额，并弹出现金抽屉
3、收银员放入收取的现金，并给顾客找零
4、系统记录该次现金支付

（3）系统顺序图：请给出实现销售用例的系统顺序图。

9 / 9