作者	（英）杰克逊（Jackson,M.） 著，金芝 译
出版社
出版时间	2005-02-01

特色：

Problem Frames: Analyzing and Structuring Software DevelopmentProblems Michael Jackson本书特点： ·分析了许多现实世界中的实例问题，讲述了怎样在实际中识别和结构化问题。·结合各种大小问题，剥茧抽丝，展现了问题类的本质，并讨论了每个问题的不同方面。 ·问题框架独立于任何特定的开发方法，所以可以很容易地将其应用到具体环境中。本书有助于： ·将复杂问题分解为简单的子问题，并且讨论怎样组合这些子问题。 ·建立简单、清楚和易用的问题类的资料库，可以访问并重用它，得出与每个类相关的经验。 本书分析了许多现实世界中的实例问题，讲述了如何在实际中识别和结构化问题。既给出了大问题也给出了小问题，展现了问题类的层次性本质，并讨论了每个问题的不同方面。 本书适用于系统分析、系统规格说明以及软件和需求工程领域的教师、学生和从业者，以及对软件开发的概念和智能工具感兴趣的任何人。"理解和使用问题框架很可能成为所有软件系统设计人员的一个基本技巧，Jackson的书提供了进入该领域的一个极佳途径。" --David Garlan，卡内基-梅隆大学计算机科学系教授 "我认为Michael Jackson在本书中吸收了许多设计模式的精髓，并且构造了利用框架隐喻的一种更易掌握的技术。"--Warren Keuffel，《软件开发》杂志资深编辑 在处理软件开发问题时，人们往往草率地开始考虑其解决方案。但是，软件开发问题涉及的是计算机之外的世界(即系统发挥作用的现实环境)，因此必须考虑周边环境特征、关系和上下文。问题框架是分类、分析和结构化这类软件开发问题的一种工具。面向对象模式主要关注解决方案，而问题框架关注于问题本身，以便你能够清楚地、直接地理解和解决它。译者序 什么是需求?软件需求的真正含义是什么?我们为什么需要软件?需要软件来做什么?这些是研究需求工程的人们一直在试图回答的问题. 从一般教科书和许多研究论文上, 我们常常看到两种观点：一种观点认为, 需求是用来求解问题或实现目标的条件或能力, 这是站在用户角度上的观点, 另一种观点认为, 需求是系统或系统的成分所拥有的条件或能力, 以满足一个合同. 标准. 规格说明或其他形式的文档, 所有需求的集合形成系统或系统成分的后续开发的基础, 这是站在软件开发者角度上的观点. 应该说, 这两种观点都反映了某个层次上软件需求的特征. 但是, 对需求的认识仅仅停留在这个程度上就够了吗?我想大部分人会有否定的回答. 因为如果把它们作为需求的定义, 当我们面对现实世界, 准备去捕获需求. 捉取需求并描述需求的时候, 还是无所适从. 我们常常会问：现实世界中有如此多样的事情要做, 有各种各样的问题要解决, 哪些是软件所能解决的问题?哪些是在捕获软件需求的时候所必须关注的问题?换句话说, 软件需求的真正含义指的是什么? 强调对软件将要作用的环境进行刻画, 将需求的含义指称到环境的描述上, 是本书作者Michael Jackson一贯的观点, 这个观点的形成可以追溯到1997年他发表在Annals of SoftwareEngineering上的一篇文章中, 在这篇文章中, 他首次提出了软件要作用的环境. 软件需求和目标软件之间的关系, 即：环境, 软件需求 这个观点目前正在引起国际需求工程界越来越广泛的重视, 它以一个全新的视角来审视需求的内涵. 软件可以作用在什么样的环境上?软件作用到环境上能够使环境发生什么样的改变?作用的特征是什么?作者认为, 软件可以作用到的现实世界中的问题是软件需求的真正内涵, 对它们进行结构化分析, 是需求分析的根本出发点. 而对上述问题的回答将对软件需求的捕获和分析起到指导性作用. 本书正是试图给出在实际问题中如何去解决这些问题的. 它从关注并定位现实世界的问题出发, 按现实世界问题的分解. 问题框架的关注点和风格. 各种问题框架的变体和特殊关注点. 问题的组合和成长式软件开发过程等, 揭示了软件所能解决的基本的现实世界问题模式. 需要说明的是, 译者在开始翻译本书时也是**次接触这个全新的思想, 虽然在翻译过程中阅读了作者在过去几年中所撰写的许多其他相关材料, 也和作者就一些问题进行过深入讨论, 但限于对这个问题理解的深度, 加上时间仓促, 难免有翻译不当之处, 恳请读者指正. 2004年春于北京 Michael Jackson在软件开发界拥有40多年的从业经验, 他创建了系统开发的JSD方法和程序设计的JSP方法. 他因在这一领域的贡献获得了荣誉博士学位. Stevens奖. IEE成就奖. 英国计算机协会的Lovelace奖章和ACM SIGSOFT奖. 他经常受邀在国际会议上做关于该领域的报告, 并著有4本书. 现在他是一名独立咨询师和AT&T Research公司的兼职研究员.软件开发问题 软件开发问题中的中心目标, 是为具有某种现实用途的计算机系统创建软件. 本书讨论的就是如何分析和结构化此类问题. 这些问题可以在许多不同的上下文中, 以许多不同的形式出现. 如果正在进行软件开发, 你可能需要构建一个系统, 用作银行账号和借贷信息的资源库和存取机制. 你可能需要开发一个电话交换系统来转接当地的电话. 你可能需要创建一个工具, 来书写和编辑文本和图, 或者创建一个控制设备来维护汽车的行驶速度, 或者创建一个编译器将Java程序转换为字节码. 几乎人类社会和物理世界的任何部分都可以作为软件开发问题的原始材料和上下文. 因为计算机具有这么多用途, 并且在求解许多问题中发挥着中心作用, 所以软件开发的实践比已经成熟的工程学科更不严谨. 开发人员和开发项目存在着极大的不同, 因此我们通常应该以一种在其他工程学科中很少需要的方式, 从描述和结构化问题开始软件开发工作. 因为在其他工程学科中, 要解决的问题的变化要小得多. 设计跑车的汽车工程师不需要问汽车是否必须能够载15个人, 是否能够在水下开, 是否能够载重10吨, 或者是否能够以每小时100英里的速度向后退. "跑车"这个术语既明确了问题, 也明确了这些问题和其他许多问题可接受的解决方案. 但是作为一个软件开发者, 你很少会求解立即可识别的和容易理解的问题, 通常必须从提问开始：这是哪种问题?这个问题准确地说是什么?它的用途到底是什么?计算机为了这个用途必须具有什么行为和特性?常常, 软件开发看上去是从零开始的. 问题框架 当你分析问题的时候, 要看它是什么样的问题, 并且标识出要解决的关注点和困难, Java编译器中的关注点将完全不同于汽车制动系统中的关注点, 你要考虑不同的事情, 必须做出不同种类的描述, 并且组合起来成为各种不同形式的论点. 问题分析将使你从识别问题的层次迈向做出求解问题所需要的描述的层次. 但是大多数现实的问题只用像这样的两个层次来处理会太大. 太复杂, 还需要另一个层次：将问题结构化为相互作用的子问题的集合. 如果结构化成功, 子问题将比开始时的问题要小并且简单, 并且它们之间的交互将是清楚的和可理解的. 然后你能够独立地分析每个子问题(它们本身也是简单问题), 并且做出所需的描述. 本书的中心思想是在问题分析和结构化中使用问题框架. 它们将通过定义不同的简单问题类来帮助你. 当你结构化一个大的. 现实的问题时, 可以这样选择子问题, 使得每个子问题都是由某个问题框架定义的简单问题. 然后, 当你分析子问题的时候, 可以按照适合于它的问题框架来看它引出了什么关注点. 这个框架展现了要解决问题所必须做的事情. 问题框架通过捕获它所涉及的部分世界的特征和相互的连接, 以及可能出现的关注点和困难, 来定义问题. 所以, 问题框架帮助你聚焦于问题, 而不是陷入到设想解决方案上. 通过强调计算机以外的世界. 所需要的效果, 以及客户*终判定是否实现这些效果的现实世界中的事情和事件之间的关系, 问题框架做到了上面这一点. 问题框架吸取了设计模式中的许多精髓. 设计模式深入其中去考察计算机及其软件, 而问题框架则向外考察发现问题的世界. 但是它们都识别和描述了一些不断再现的情景, 提供了一个术语体系, 在这个体系中, 你所获得的经验和知识的每次增加, 都可以在一个更大的架构下找到合适的位置, 并且可以更有效地被共享和访问. 在面向对象设计中, 如果熟悉设计模式, 你可以说"我们这里需要修饰器模式的一个实例", 同样, 在问题分解中, 如果熟悉问题框架, 你可以说"这部分问题是一个工件问题". 如果能发现一个问题属于某个已知的问题框架, 就可以利用与这个框架相关的经验. 问题框架的思想首先是在我的Software Requirements & Specifications一书中发表的, 在该书中, 只在概要中把它列为几个相关主题之一进行了简要介绍. 本书在这个基础上进行了更新, 讨论和说明了许多基本和组合的问题框架, 以及许多风格和变体, 并且考察了它们引出的一些关注点. 另外, 还考察和说明了如何在将现实问题分解为子问题时使用问题框架. 关注的视角 一些人认为, 这种看待软件开发问题的角度太关注. 太狭窄了, 他们指出, 计算机系统以及软件开发本身几乎总是存在于一个复杂和可变的社会. 政治. 道德和经济环境中. 当你发现对一个系统的需求时, 很可能就被牵扯进冲突的项目相关人员群体的社会协商过程中, 当你做一个关于系统功能性的决定时, 可能会更偏向于某一方, 当你扩大系统的范围时, 常常就在给一个群体政治权利, 而让另一个群体付出代价, 当你分析系统的目的时, 就在探索它在经济和组织方面的结果. 所以, 从这个观点看, 软件开发的主要关注点是社会的和政治的. 组织的和经济的, 按照问题来考虑这些关注点并不合理. 这些关注点在许多开发中真的很重要, 只不过本书中将忽略它们, 我们不准备讨论怎样抽取需求, 怎样产生业务案例, 怎样管理项目. 召集会议或协商折中方案. 我们将忽略这些事情, 不是因为它们不重要, 而仅仅是因为它们不是本书的主题. 如果你想要理解某件事情, 就不应该试图去理解每件事情. 相反, 我们将试图理解在软件开发这个大背景中问题结构和分析中某些更关注的思想, 我们的主题是系统应该带给世界的具体的. 可观察的效果, 实现这些效果的计算机行为, 以及它们之间的联系. 简言之, 就是功能需求. 软件规格说明以及从功能需求到软件规格说明的途径. 关注于问题 关注于软件开发中的问题并不是很容易的事情. 原因之一在于, 问题的一些方面会很精确, 另一些方面则不那么精确, 而所有这些都会引起你的注意. 就像奥德修斯在从特洛伊回家的船上那样, 你的航行途中前有锡拉女妖, 后有大漩涡, 你必须试图从中间穿过. 有些人认为我们对问题的视点太形式化. 太狭窄, 如果受这种论点所影响, 你可能会偏离到右边, 进入纯人类问题的世界--社会学和人种学的非精确世界, 其中任何事情都不是完全确定的或完全准确的, 那是一个重要的世界, 但它忽略了软件和软件开发. 然而, 如果你认为问题本身不如开发它们的软件解决方案那样有吸引力, 你很可能会偏离到左边, 朝向更精确的程序设计世界--变量. 方法和对象类的世界, 其中, 布尔值或者是True或者是False, 而绝不会处于两者之间. 程序设计也很重要, 但如果没有分析问题并且归结出程序必须做什么, 则它将是没有用的. 在本书讨论的问题中, 有许多精确的和不精确的成分, 我们尽力平衡二者以理解和分析问题. 形式化性和非形式化性 如果你在锡拉女妖和大漩涡之间的正确航道上航行, 并且成功地关注于问题, 那么你的描述必须有时是相当形式化的, 而有时是相当非形式化的. 形式化当然很容易观察到. 一些软件开发者认为, 当按照某种规则而不是凭一时的想象画图的时候, 他们就是绝对形式化的. 一些人认为, 如果不依赖于严格的数学上的正确性证明, 则开发无疑是非形式化的. 软件开发问题是关于现实世界的, 系统必须在现实世界中起作用. 所以, 在问题分析中必须要做的大部分事情的形式化程度, 取决于要处理的现实世界问题的形式化程度. 能像问题允许的和任务要求的那样精确和形式化当然很好：在能够准确的时候为什么要模糊呢?但是物理世界的很多事情是不能被如实地甚至用纯形式的术语适当描述的, 认识到这一点也非常重要. 在Engineering and the Mind's Eye这本关于机械和结构工程的好书中, Eugene Ferguson抱怨, 许多工程灾难的发生, 正是因为现代工程师将太多的注意力放在结构的计算和形式化的分析上, 而很少注意到其结构也是物理现实世界的一部分. 他认为：工程教育的现实问题是隐含地接受了一个观点, 即高层次的分析课程优于鼓励学生发展对现实世界中工程实践的不可计算的复杂性的直觉. 或许, 作为实践性很强的软件开发人员, 我们不会为过多注意"高层次分析课程"而感到内疚, 但是我们确实花了很多注意力到本质上是语法的和概念的技术上. 这让我们就像其教育过程受到Ferguson批评的工程师那样, 花了太少的注意力在现实世界的不可计算的复杂性上. 问题和需求处于世界之中, 而不是处于计算机中. 必须直接关注于它们, 并且谨慎地描述它们. 真的有问题吗 有些人之所以不从问题出发来思考软件开发, 确实另有原因. 他们按共生的关系来看待每个系统及其环境, 相互间不断地进化和调整. 安装和使用一个系统(甚至提出要安装和使用一个系统)导致环境中的变化, 而这种变化反过来影响这个系统在其以后的版本中的进化. "问题"从它被提出的那一刻起就被连续地修改, 问题描述*好是问题在其将很快消失的某一刻的快照, 没有像"需求"那样的东西, 就是有的话, 也是没有用的. 这经常被用作支持增量式部署和进化式开发的一个很好的论据, 并且还可能是支持企图预计系统的效果. 计算它将带来的环境中的变化并在系统开发中考虑这些变化的一个很好的论据. 仅仅设计一座桥梁, 想要应付眼前和能预想到的交通需求是不够的, 必须能够处理这个桥梁本身引起的更多不确定的需求增加. 但是对于拒绝从问题和需求出发来思考而言, 这种观点绝不是什么站不住脚的论据. 当一个计算机系统(或者对一个系统增量的或者进化的改进)安装和运行时, 它将肯定有一些由软件所确定的特定的行为, 这种特定的行为将在问题世界中产生效果和影响, 而这些效果和影响可能是想要的或不想要的. 要捕获需求, 并且结构化和分析问题, 就是尽你所能决定什么结果是想要的, 并且创建将能带来这些结果的软件. 就是说明年所需要的不同结果和不同软件, 绝不能成为今年软件出现问题的理由. 对需求的不确定性和变化性的正确应对措施, 不是放弃这个任务, 而是要在更高的通用性层次上进行工作. 有一种技术是将一些功能性编码为机器在执行时要解释的显式描述, 然后用户可以通过修改这个描述来修改系统的行为. 这种增加通用性层次的技术能够归于本书中讨论的问题分析方法中：它使用拥有描述领域的变体框架. 这当然还可以归于设计模式的常用实践, 其中它是用带有诸如反射. 元数据或类型对象等名字的模式来表示的. 什么方法 问题框架的使用并不意味着一种特定的开发方法. 一个原因是, 不同的框架要求不同的方法, 并使用不同的概念和表示法. 想用一种灵丹妙药解决诸多软件开发困难的想法现在已经很少人相信了. 但可悲的是它仍然存在. 令人吃惊的是, 实际上是在宣称对每种问题都可用的灵丹妙药仍然有人在设计和销售, 并且似乎很流行. 如果一个方法对每种问题都能提供帮助, 那么不必期望它对某种特定的问题有太多的帮助. 问题框架并不提倡某一种特定的开发方法的另一个原因是, 大多数现在被广泛应用的方法都强烈地面向解决方案. 你需要面向解决方案的方法来帮助得出解决方案, 但是它们在结构化和分析问题中所能给予的帮助很少, 并且常常是一种纯粹的障碍. 问题框架以及相关的思想可以作为所有行动的前端, 或者为你怎样扩展或修改实践提供建议, 或者也许只是澄清它. 如果采用了这些思想, 就要循序渐进地去实践, 而不要一下子彻底改变. 你或许会发现其中的许多概念只是为已经有的思想和直觉起了一个名字, 而为它们取名会使你在需要时更有意识地想到和使用它们. 对于一些对你而言比较新的概念, 它们会为一些你曾经感到困难但一直没有弄清的地方带来一线曙光. 本书的结构 本书的关键思想是将复杂和现实的问题分解为适合已知问题框架的简单子问题所组成的结构, 因此其中混杂有大大小小的问题. 一些比较小的问题没有实际意义, 特别是用来示例*基本的问题框架的那些问题. 但不要轻视那些没有实际意义的问题, 它们以*直接的形式逐步地层现了问题类的本质, 这使得当这些问题在更大问题下出现时, 更容易被识别. 本书中的问题并不是按规模和复杂性的升序出现的, 那样虽然合理简洁, 但却会使本书不太好阅读. 较大的和较小的问题交织在一起, 并且每个问题的不同方面都在它们看起来相关并提供了当前论点的一个好的示例的地方被讨论. 一些主题(比如描述性语言和表示法)贯穿了全书, 而且, 这些主题的各个方面都在它们出现的时候被引入. 这种非形式化的结构由两个附录来补充, 一个附录总结了所使用的描述性语言和表示法, 另一个附录提供了术语表, 还有一个参考文献的统一列表. 本书适合你吗 希望本书对系统分析. 系统规格说明以及软件和需求工程领域的教师. 学生和从业者, 以及对软件开发的概念和智能工具感兴趣的任何人都有所裨益. 本书不是教科书, 但它可以用作一些软件开发课程的补充教材.