![软件开发问题框架：现实世界问题的结构化分析[图书]](http://images.china-pub.com/ebook20001-25000/23970/zcover.jpg)
基本信息
- 原书名：Problem Frames: Analyzing and Structuring Software Development Problems
- 原出版社： Addison Wesley/Pearson
- 作者： （英）Michael Jackson
- 译者： 金芝等
- 丛书名： 软件工程技术丛书/分析系列
- 出版社：机械工业出版社
- ISBN：9787111157052
- 上架时间：2005-3-11
- 出版日期：2005 年2月
- 开本：16开
- 页码：304
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 综合
内容简介
书籍
计算机书籍
<p><font color="#FF6600">本书特点：</font>
·分析了许多现实世界中的实例问题，讲述了怎样在实际中识别和结构化问题。
·结合各种大小问题，剥茧抽丝，展现了问题类的本质，并讨论了每个问题的不同方面。
·问题框架独立于任何特定的开发方法，所以可以很容易地将其应用到具体环境中。
本书有助于：
·将复杂问题分解为简单的子问题，并且讨论怎样组合这些子问题。
·建立简单、清楚和易用的问题类的资料库，可以访问并重用它，得出与每个类相关的经验。
本书分析了许多现实世界中的实例问题，讲述了如何在实际中识别和结构化问题。既给出了大问题也给出了小问题，展现了问题类的层次性本质，并讨论了每个问题的不同方面。
本书适用于系统分析、系统规格说明以及软件和需求工程领域的教师、学生和从业者，以及对软件开发的概念和智能工具感兴趣的任何人。
“理解和使用问题框架很可能成为所有软件系统设计人员的一个基本技巧，Jackson的书提供了进入该领域的一个极佳途径。”
计算机书籍
<p><font color="#FF6600">本书特点：</font>
·分析了许多现实世界中的实例问题，讲述了怎样在实际中识别和结构化问题。
·结合各种大小问题，剥茧抽丝，展现了问题类的本质，并讨论了每个问题的不同方面。
·问题框架独立于任何特定的开发方法，所以可以很容易地将其应用到具体环境中。
本书有助于：
·将复杂问题分解为简单的子问题，并且讨论怎样组合这些子问题。
·建立简单、清楚和易用的问题类的资料库，可以访问并重用它，得出与每个类相关的经验。
本书分析了许多现实世界中的实例问题，讲述了如何在实际中识别和结构化问题。既给出了大问题也给出了小问题，展现了问题类的层次性本质，并讨论了每个问题的不同方面。
本书适用于系统分析、系统规格说明以及软件和需求工程领域的教师、学生和从业者，以及对软件开发的概念和智能工具感兴趣的任何人。
“理解和使用问题框架很可能成为所有软件系统设计人员的一个基本技巧，Jackson的书提供了进入该领域的一个极佳途径。”
作译者
Michael Jackson在软件开发界拥有40多年的从业经验，他创建了系统开发的JSD方法和程序设计的JSP方法。他因在这一领域的贡献获得了荣誉博士学位、Stevens奖、IEE成就奖、英国计算机协会的Lovelace奖章和ACM SIGSOFT奖。他经常受邀在国际会议上做关于该领域的报告，并著有4本书。现在他是一名独立咨询师和AT&T Research公司的兼职研究员。
目录
译者序
前言
致谢
第1章 关注于问题
1．1 解决方案之前的问题
1．2 计算机和世界
1．3 初始的问题焦点
1．4 问题不在接口上
1．5 描述外部世界的挑战
1．5．1 计算机的魅力
1．5．2 "系统"的两个含义
1．5．3 "模型"的两个含义
1．6 无缝开发
1．7 一些解决方案
1．8 本书的范围
第2章 定位问题并确定问题的边界
2．1 上下文图
2．1．1 物理领域
2．1．2 共享现象的接口
2．2 上下文图确定问题的边界
前言
致谢
第1章 关注于问题
1．1 解决方案之前的问题
1．2 计算机和世界
1．3 初始的问题焦点
1．4 问题不在接口上
1．5 描述外部世界的挑战
1．5．1 计算机的魅力
1．5．2 "系统"的两个含义
1．5．3 "模型"的两个含义
1．6 无缝开发
1．7 一些解决方案
1．8 本书的范围
第2章 定位问题并确定问题的边界
2．1 上下文图
2．1．1 物理领域
2．1．2 共享现象的接口
2．2 上下文图确定问题的边界
译者序
什么是需求?软件需求的真正含义是什么?我们为什么需要软件?需要软件来做什么?这些是研究需求工程的人们一直在试图回答的问题。从一般教科书和许多研究论文上，我们常常看到两种观点：一种观点认为，需求是用来求解问题或实现目标的条件或能力，这是站在用户角度上的观点；另一种观点认为，需求是系统或系统的成分所拥有的条件或能力，以满足一个合同、标准、规格说明或其他形式的文档，所有需求的集合形成系统或系统成分的后续开发的基础，这是站在软件开发者角度上的观点。应该说，这两种观点都反映了某个层次上软件需求的特征。
但是，对需求的认识仅仅停留在这个程度上就够了吗?我想大部分人会有否定的回答。因为如果把它们作为需求的定义，当我们面对现实世界，准备去捕获需求、捉取需求并描述需求的时候，还是无所适从。我们常常会问：现实世界中有如此多样的事情要做，有各种各样的问题要解决，哪些是软件所能解决的问题?哪些是在捕获软件需求的时候所必须关注的问题?换句话说，软件需求的真正含义指的是什么?
强调对软件将要作用的环境进行刻画，将需求的含义指称到环境的描述上，是本书作者Michael Jackson一贯的观点，这个观点的形成可以追溯到1997年他发表在Annals of SoftwareEngineering上的一篇文章中，在这篇文章中，他首次提出了软件要作用的环境、软件需求和目标软件之间的关系，即：环境，软件需求
这个观点目前正在引起国际需求工程界越来越广泛的重视，它以一个全新的视角来审视需求的内涵。软件可以作用在什么样的环境上?软件作用到环境上能够使环境发生什么样的改变?作用的特征是什么?作者认为，软件可以作用到的现实世界中的问题是软件需求的真正内涵，对它们进行结构化分析，是需求分析的根本出发点。而对上述问题的回答将对软件需求的捕获和分析起到指导性作用。本书正是试图给出在实际问题中如何去解决这些问题的。它从关注并定位现实世界的问题出发，按现实世界问题的分解、问题框架的关注点和风格、各种问题框架的变体和特殊关注点、问题的组合和成长式软件开发过程等，揭示了软件所能解决的基本的现实世界问题模式。
需要说明的是，译者在开始翻译本书时也是第一次接触这个全新的思想，虽然在翻译过程中阅读了作者在过去几年中所撰写的许多其他相关材料，也和作者就一些问题进行过深入讨论，但限于对这个问题理解的深度，加上时间仓促，难免有翻译不当之处，恳请读者指正。
2004年春于北京
但是，对需求的认识仅仅停留在这个程度上就够了吗?我想大部分人会有否定的回答。因为如果把它们作为需求的定义，当我们面对现实世界，准备去捕获需求、捉取需求并描述需求的时候，还是无所适从。我们常常会问：现实世界中有如此多样的事情要做，有各种各样的问题要解决，哪些是软件所能解决的问题?哪些是在捕获软件需求的时候所必须关注的问题?换句话说，软件需求的真正含义指的是什么?
强调对软件将要作用的环境进行刻画，将需求的含义指称到环境的描述上，是本书作者Michael Jackson一贯的观点，这个观点的形成可以追溯到1997年他发表在Annals of SoftwareEngineering上的一篇文章中，在这篇文章中，他首次提出了软件要作用的环境、软件需求和目标软件之间的关系，即：环境，软件需求
这个观点目前正在引起国际需求工程界越来越广泛的重视，它以一个全新的视角来审视需求的内涵。软件可以作用在什么样的环境上?软件作用到环境上能够使环境发生什么样的改变?作用的特征是什么?作者认为，软件可以作用到的现实世界中的问题是软件需求的真正内涵，对它们进行结构化分析，是需求分析的根本出发点。而对上述问题的回答将对软件需求的捕获和分析起到指导性作用。本书正是试图给出在实际问题中如何去解决这些问题的。它从关注并定位现实世界的问题出发，按现实世界问题的分解、问题框架的关注点和风格、各种问题框架的变体和特殊关注点、问题的组合和成长式软件开发过程等，揭示了软件所能解决的基本的现实世界问题模式。
需要说明的是，译者在开始翻译本书时也是第一次接触这个全新的思想，虽然在翻译过程中阅读了作者在过去几年中所撰写的许多其他相关材料，也和作者就一些问题进行过深入讨论，但限于对这个问题理解的深度，加上时间仓促，难免有翻译不当之处，恳请读者指正。
2004年春于北京
前言
软件开发问题
软件开发问题中的中心目标，是为具有某种现实用途的计算机系统创建软件。本书讨论的就是如何分析和结构化此类问题。
这些问题可以在许多不同的上下文中，以许多不同的形式出现。如果正在进行软件开发，你可能需要构建一个系统，用作银行账号和借贷信息的资源库和存取机制。你可能需要开发一个电话交换系统来转接当地的电话。你可能需要创建一个工具，来书写和编辑文本和图；或者创建一个控制设备来维护汽车的行驶速度；或者创建一个编译器将Java程序转换为字节码。几乎人类社会和物理世界的任何部分都可以作为软件开发问题的原始材料和上下文。
因为计算机具有这么多用途，并且在求解许多问题中发挥着中心作用，所以软件开发的实践比已经成熟的工程学科更不严谨。开发人员和开发项目存在着极大的不同，因此我们通常应该以一种在其他工程学科中很少需要的方式，从描述和结构化问题开始软件开发工作。因为在其他工程学科中，要解决的问题的变化要小得多。设计跑车的汽车工程师不需要问汽车是否必须能够载15个人，是否能够在水下开，是否能够载重10吨，或者是否能够以每小时100英里的速度向后退。"跑车"这个术语既明确了问题，也明确了这些问题和其他许多问题可接受的解决方案。
但是作为一个软件开发者，你很少会求解立即可识别的和容易理解的问题，通常必须从提问开始：这是哪种问题?这个问题准确地说是什么?它的用途到底是什么?计算机为了这个用途必须具有什么行为和特性?常常，软件开发看上去是从零开始的。
问题框架
当你分析问题的时候，要看它是什么样的问题，并且标识出要解决的关注点和困难，Java编译器中的关注点将完全不同于汽车制动系统中的关注点，你要考虑不同的事情，必须做出不同种类的描述，并且组合起来成为各种不同形式的论点。问题分析将使你从识别问题的层次迈向做出求解问题所需要的描述的层次。
但是大多数现实的问题只用像这样的两个层次来处理会太大、太复杂，还需要另一个层次：将问题结构化为相互作用的子问题的集合。如果结构化成功，子问题将比开始时的问题要小并且简单，并且它们之间的交互将是清楚的和可理解的。然后你能够独立地分析每个子问题(它们本身也是简单问题)，并且做出所需的描述。
本书的中心思想是在问题分析和结构化中使用问题框架。它们将通过定义不同的简单问题类来帮助你。当你结构化一个大的、现实的问题时，可以这样选择子问题，使得每个子问题都是由某个问题框架定义的简单问题。然后，当你分析子问题的时候，可以按照适合于它的问题框架来看它引出了什么关注点。这个框架展现了要解决问题所必须做的事情。
问题框架通过捕获它所涉及的部分世界的特征和相互的连接，以及可能出现的关注点和困难，来定义问题。所以，问题框架帮助你聚焦于问题，而不是陷入到设想解决方案上。通过强调计算机以外的世界、所需要的效果，以及客户最终判定是否实现这些效果的现实世界中的事情和事件之间的关系，问题框架做到了上面这一点。
问题框架吸取了设计模式中的许多精髓。设计模式深入其中去考察计算机及其软件，而问题框架则向外考察发现问题的世界。但是它们都识别和描述了一些不断再现的情景，提供了一个术语体系，在这个体系中，你所获得的经验和知识的每次增加，都可以在一个更大的架构下找到合适的位置，并且可以更有效地被共享和访问。在面向对象设计中，如果熟悉设计模式，你可以说"我们这里需要修饰器模式的一个实例"；同样，在问题分解中，如果熟悉问题框架，你可以说"这部分问题是一个工件问题"。如果能发现一个问题属于某个已知的问题框架，就可以利用与这个框架相关的经验。
问题框架的思想首先是在我的Software Requirements & Specifications一书中发表的，在该书中，只在概要中把它列为几个相关主题之一进行了简要介绍。本书在这个基础上进行了更新，讨论和说明了许多基本和组合的问题框架，以及许多风格和变体，并且考察了它们引出的一些关注点。另外，还考察和说明了如何在将现实问题分解为子问题时使用问题框架。
关注的视角
一些人认为，这种看待软件开发问题的角度太关注、太狭窄了，他们指出，计算机系统以及软件开发本身几乎总是存在于一个复杂和可变的社会、政治、道德和经济环境中。当你发现对一个系统的需求时，很可能就被牵扯进冲突的项目相关人员群体的社会协商过程中；当你做一个关于系统功能性的决定时，可能会更偏向于某一方；当你扩大系统的范围时，常常就在给一个群体政治权利，而让另一个群体付出代价；当你分析系统的目的时，就在探索它在经济和组织方面的结果。
所以，从这个观点看，软件开发的主要关注点是社会的和政治的、组织的和经济的，按照问题来考虑这些关注点并不合理。这些关注点在许多开发中真的很重要，只不过本书中将忽略它们，我们不准备讨论怎样抽取需求，怎样产生业务案例，怎样管理项目、召集会议或协商折中方案。我们将忽略这些事情，不是因为它们不重要，而仅仅是因为它们不是本书的主题。如果你想要理解某件事情，就不应该试图去理解每件事情。
相反，我们将试图理解在软件开发这个大背景中问题结构和分析中某些更关注的思想，我们的主题是系统应该带给世界的具体的、可观察的效果，实现这些效果的计算机行为，以及它们之间的联系。简言之，就是功能需求、软件规格说明以及从功能需求到软件规格说明的途径。
关注于问题
关注于软件开发中的问题并不是很容易的事情。原因之一在于，问题的一些方面会很精确，另一些方面则不那么精确，而所有这些都会引起你的注意。就像奥德修斯在从特洛伊回家的船上那样，你的航行途中前有锡拉女妖，后有大漩涡，你必须试图从中间穿过。
有些人认为我们对问题的视点太形式化、太狭窄，如果受这种论点所影响，你可能会偏离到右边，进入纯人类问题的世界--社会学和人种学的非精确世界，其中任何事情都不是完全确定的或完全准确的，那是一个重要的世界，但它忽略了软件和软件开发。
然而，如果你认为问题本身不如开发它们的软件解决方案那样有吸引力，你很可能会偏离到左边，朝向更精确的程序设计世界--变量、方法和对象类的世界，其中，布尔值或者是True或者是False，而绝不会处于两者之间。程序设计也很重要，但如果没有分析问题并且归结出程序必须做什么，则它将是没有用的。
软件开发问题中的中心目标，是为具有某种现实用途的计算机系统创建软件。本书讨论的就是如何分析和结构化此类问题。
这些问题可以在许多不同的上下文中，以许多不同的形式出现。如果正在进行软件开发，你可能需要构建一个系统，用作银行账号和借贷信息的资源库和存取机制。你可能需要开发一个电话交换系统来转接当地的电话。你可能需要创建一个工具，来书写和编辑文本和图；或者创建一个控制设备来维护汽车的行驶速度；或者创建一个编译器将Java程序转换为字节码。几乎人类社会和物理世界的任何部分都可以作为软件开发问题的原始材料和上下文。
因为计算机具有这么多用途，并且在求解许多问题中发挥着中心作用，所以软件开发的实践比已经成熟的工程学科更不严谨。开发人员和开发项目存在着极大的不同，因此我们通常应该以一种在其他工程学科中很少需要的方式，从描述和结构化问题开始软件开发工作。因为在其他工程学科中，要解决的问题的变化要小得多。设计跑车的汽车工程师不需要问汽车是否必须能够载15个人，是否能够在水下开，是否能够载重10吨，或者是否能够以每小时100英里的速度向后退。"跑车"这个术语既明确了问题，也明确了这些问题和其他许多问题可接受的解决方案。
但是作为一个软件开发者，你很少会求解立即可识别的和容易理解的问题，通常必须从提问开始：这是哪种问题?这个问题准确地说是什么?它的用途到底是什么?计算机为了这个用途必须具有什么行为和特性?常常，软件开发看上去是从零开始的。
问题框架
当你分析问题的时候，要看它是什么样的问题，并且标识出要解决的关注点和困难，Java编译器中的关注点将完全不同于汽车制动系统中的关注点，你要考虑不同的事情，必须做出不同种类的描述，并且组合起来成为各种不同形式的论点。问题分析将使你从识别问题的层次迈向做出求解问题所需要的描述的层次。
但是大多数现实的问题只用像这样的两个层次来处理会太大、太复杂，还需要另一个层次：将问题结构化为相互作用的子问题的集合。如果结构化成功，子问题将比开始时的问题要小并且简单，并且它们之间的交互将是清楚的和可理解的。然后你能够独立地分析每个子问题(它们本身也是简单问题)，并且做出所需的描述。
本书的中心思想是在问题分析和结构化中使用问题框架。它们将通过定义不同的简单问题类来帮助你。当你结构化一个大的、现实的问题时，可以这样选择子问题，使得每个子问题都是由某个问题框架定义的简单问题。然后，当你分析子问题的时候，可以按照适合于它的问题框架来看它引出了什么关注点。这个框架展现了要解决问题所必须做的事情。
问题框架通过捕获它所涉及的部分世界的特征和相互的连接，以及可能出现的关注点和困难，来定义问题。所以，问题框架帮助你聚焦于问题，而不是陷入到设想解决方案上。通过强调计算机以外的世界、所需要的效果，以及客户最终判定是否实现这些效果的现实世界中的事情和事件之间的关系，问题框架做到了上面这一点。
问题框架吸取了设计模式中的许多精髓。设计模式深入其中去考察计算机及其软件，而问题框架则向外考察发现问题的世界。但是它们都识别和描述了一些不断再现的情景，提供了一个术语体系，在这个体系中，你所获得的经验和知识的每次增加，都可以在一个更大的架构下找到合适的位置，并且可以更有效地被共享和访问。在面向对象设计中，如果熟悉设计模式，你可以说"我们这里需要修饰器模式的一个实例"；同样，在问题分解中，如果熟悉问题框架，你可以说"这部分问题是一个工件问题"。如果能发现一个问题属于某个已知的问题框架，就可以利用与这个框架相关的经验。
问题框架的思想首先是在我的Software Requirements & Specifications一书中发表的，在该书中，只在概要中把它列为几个相关主题之一进行了简要介绍。本书在这个基础上进行了更新，讨论和说明了许多基本和组合的问题框架，以及许多风格和变体，并且考察了它们引出的一些关注点。另外，还考察和说明了如何在将现实问题分解为子问题时使用问题框架。
关注的视角
一些人认为，这种看待软件开发问题的角度太关注、太狭窄了，他们指出，计算机系统以及软件开发本身几乎总是存在于一个复杂和可变的社会、政治、道德和经济环境中。当你发现对一个系统的需求时，很可能就被牵扯进冲突的项目相关人员群体的社会协商过程中；当你做一个关于系统功能性的决定时，可能会更偏向于某一方；当你扩大系统的范围时，常常就在给一个群体政治权利，而让另一个群体付出代价；当你分析系统的目的时，就在探索它在经济和组织方面的结果。
所以，从这个观点看，软件开发的主要关注点是社会的和政治的、组织的和经济的，按照问题来考虑这些关注点并不合理。这些关注点在许多开发中真的很重要，只不过本书中将忽略它们，我们不准备讨论怎样抽取需求，怎样产生业务案例，怎样管理项目、召集会议或协商折中方案。我们将忽略这些事情，不是因为它们不重要，而仅仅是因为它们不是本书的主题。如果你想要理解某件事情，就不应该试图去理解每件事情。
相反，我们将试图理解在软件开发这个大背景中问题结构和分析中某些更关注的思想，我们的主题是系统应该带给世界的具体的、可观察的效果，实现这些效果的计算机行为，以及它们之间的联系。简言之，就是功能需求、软件规格说明以及从功能需求到软件规格说明的途径。
关注于问题
关注于软件开发中的问题并不是很容易的事情。原因之一在于，问题的一些方面会很精确，另一些方面则不那么精确，而所有这些都会引起你的注意。就像奥德修斯在从特洛伊回家的船上那样，你的航行途中前有锡拉女妖，后有大漩涡，你必须试图从中间穿过。
有些人认为我们对问题的视点太形式化、太狭窄，如果受这种论点所影响，你可能会偏离到右边，进入纯人类问题的世界--社会学和人种学的非精确世界，其中任何事情都不是完全确定的或完全准确的，那是一个重要的世界，但它忽略了软件和软件开发。
然而，如果你认为问题本身不如开发它们的软件解决方案那样有吸引力，你很可能会偏离到左边，朝向更精确的程序设计世界--变量、方法和对象类的世界，其中，布尔值或者是True或者是False，而绝不会处于两者之间。程序设计也很重要，但如果没有分析问题并且归结出程序必须做什么，则它将是没有用的。
