描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787111564720丛书名: 计算机科学丛书
内容简介
本书由IT专家亲笔撰写，详细讲解了情境驱动设计。全书共三部分，13章。第壹部分（第1-4章）引出了情境驱动设计及设计的体系，以及这种设计方式与现有的设计方法的异同；第二部分（第5-11章）详细讲解了应用程序的设计，如何设计需求，如何确保应用程序与其他程序及数据库协同动作，用户界面的设计与易用性，数据库设计，以及技术设计的原则与结构；第三部分（第12-13章）是本书的收尾部分，其中第12章讲解了程序设计中的安全问题，第13章总结了前面各章的重点，并展望了应用程序开发的趋势。
目 录
目 录
Designing the Requirements: Building Applications that the User Wants and Needs
出版者的话
译者序
前言
第1章 情境驱动设计入门1
1.1 对需求进行设计1
1.2 什么是设计7
1.2.1 专项的设计9
1.2.2 有计划的设计10
1.2.3 工程化的设计11
1.2.4 设计方法小结13
1.3 像工程学那样来开发IT应用程序14
1.4 重视IT架构14
1.5 小结15
第2章 设计体系16
2.1 为什么应该建立设计体系16
2.2 情境设计19
2.2.1 任务19
2.2.2 用户组21
2.2.3 数据表21
2.2.4 任务之间的消息21
2.2.5 任务之间的依赖关系22
2.2.6 把所有元素统合起来23
2.2.7 对情境设计做分析24
2.3 集成设计25
2.4 技术设计29
2.5 用户界面设计31
2.6 数据库设计32
2.7 实现33
2.8 这样做真的是工程化的设计吗34
2.9 小结37
第3章 复用现有的方法及做法38
3.1 敏捷38
3.1.1 个体与交互胜过流程与工具39
3.1.2 可行的软件胜过繁杂的文档40
3.1.3 客户协作胜过合同谈判41
3.1.4 响应变化胜过遵循计划42
3.1.5 小结43
3.2 逆向设计43
3.3 用例45
3.3.1 原子性45
3.3.2 设计层次不明确46
3.3.3 用例本身比较模糊47
3.3.4 大型的用例文档难以理解48
3.3.5 用例对工程化的设计起不到帮助作用48
3.3.6 小结49
3.4 成本估算问题49
3.5 BDUF为什么如此笨重52
3.6 迭代53
3.7 品质54
3.8 测试与检验55
3.9 把现有的做法运用到情境驱动设计之中56
3.10 学习型的组织57
3.11 小结58
第4章 大型应用程序所面临的问题60
4.1 应用程序的大小体现在多个维度上61
4.2 大型项目所面临的问题63
4.2.1 需求问题64
4.2.2 缺乏终端用户的支持65
4.2.3 技术设计有问题67
4.2.4 采购与外包69
4.3 能够避免大型的项目吗72
4.4 小结75
第5章 应用程序与业务的关系76
5.1 理解业务流程76
5.2 不能表示为流程的应该怎么办80
5.2.1 业务服务81
5.2.2 资源管理81
5.2.3 评审与监测82
5.3 用更广阔的视角来观察83
5.4 将商业策略运用到应用程序的开发中85
5.4.1 开发速度85
5.4.2 在成本、性能、可用性之间权衡86
5.4.3 试验性的商业计划86
5.4.4 利益要等多久才能变现86
5.4.5 安全需求86
5.4.6 针对现有的企业文化来做设计86
5.4.7 为公司所追求的文化气氛而做设计87
5.4.8 为计划的变更留出余地87
5.4.9 为打造学习型的组织提供支持88
5.4.10 非商务型的应用程序88
5.5 分析88
5.5.1 流程的格式是否正确88
5.5.2 对依赖关系进行分析89
5.5.3 目标分析91
5.6 小结92
第6章 应用程序与用户的关系93
6.1 添加详情93
6.1.1 任务细节94
6.1.2 任务片段97
6.1.3 共同目标组98
6.1.4 数据表98
6.1.5 消息99
6.1.6 非功能型的需求100
6.1.7 使用情境设计的人101
6.2 确定各类用户102
6.2.1 办理业务流程的用户103
6.2.2 对工作进行监控的管理型用户103
6.2.3 使用本程序数据的其他应用程序的用户106
6.2.4 执行数据分析的用户107
6.2.5 执行应用程序管理工作的用户108
6.3 对情境设计进行分析109
6.3.1 流程层面的分析109
6.3.2 任务细节分析110
6.3.3 数据表详情分析111
6.3.4 用户组详情分析112
6.3.5 消息详情分析112
6.4 对情境设计进行评审112
6.5 小结114
第7章 应用程序与其他IT项目的关系115
7.1 集成设计116
7.1.1 应用程序116
7.1.2 服务117
7.1.3 数据库119
7.2 服务接口设计122
7.2.1 定义服务接口123
7.2.2 设计可复用的服务127
7.3 现有的应用程序128
7.3.1 确定现有的应用程序128
7.3.2 替换现有的应用程序130
7.3.3 用现有的应用程序来制作服务133
7.4 回顾设计流程134
7.5 小结135
第8章 用户界面设计与易用性137
8.1 逻辑用户界面138
8.2 把任务描述转化为单击操作141
8.3 易用性145
8.3.1 功能146
8.3.2 信息147
8.3.3 导航147
8.3.4 文本148
8.3.5 帮助148
8.3.6 直观而亲切的应用程序149
8.3.7 针对易用性进行设计150
8.3.8 监测易用性152
8.4 事务与任务完整性152
8.5 用户界面设计与其他细节设计之间的关系155
8.6 小结155
第9章 数据库设计157
9.1 数据库设计157
9.2 数据库设计理论163
9.3 程序员与数据库设计者之间的关系170
9.4 数据访问服务172
9.5 NoSQL173
9.6 小结177
第10章 技术设计的原则178
10.1 单服务器环境下的高性能原则178
10.1.1 缓存179
10.1.2 多线程与多元处理181
10.2 多服务器环境下的高性能原则184
10.2.1 前端并行184
10.2.2 后端并行187
10.3 高弹性原则190
10.4 测试与性能评估的必要性192
10.5 技术设计的流程193
10.6 小结196
第11章 技术设计的结构197
11.1 程序结构197
11.2 什么是框架201
11.3 各种编程语言203
11.4 选择编程语言及框架207
11.4.1 选择与公司的技能组合
Designing the Requirements: Building Applications that the User Wants and Needs
出版者的话
译者序
前言
第1章 情境驱动设计入门1
1.1 对需求进行设计1
1.2 什么是设计7
1.2.1 专项的设计9
1.2.2 有计划的设计10
1.2.3 工程化的设计11
1.2.4 设计方法小结13
1.3 像工程学那样来开发IT应用程序14
1.4 重视IT架构14
1.5 小结15
第2章 设计体系16
2.1 为什么应该建立设计体系16
2.2 情境设计19
2.2.1 任务19
2.2.2 用户组21
2.2.3 数据表21
2.2.4 任务之间的消息21
2.2.5 任务之间的依赖关系22
2.2.6 把所有元素统合起来23
2.2.7 对情境设计做分析24
2.3 集成设计25
2.4 技术设计29
2.5 用户界面设计31
2.6 数据库设计32
2.7 实现33
2.8 这样做真的是工程化的设计吗34
2.9 小结37
第3章 复用现有的方法及做法38
3.1 敏捷38
3.1.1 个体与交互胜过流程与工具39
3.1.2 可行的软件胜过繁杂的文档40
3.1.3 客户协作胜过合同谈判41
3.1.4 响应变化胜过遵循计划42
3.1.5 小结43
3.2 逆向设计43
3.3 用例45
3.3.1 原子性45
3.3.2 设计层次不明确46
3.3.3 用例本身比较模糊47
3.3.4 大型的用例文档难以理解48
3.3.5 用例对工程化的设计起不到帮助作用48
3.3.6 小结49
3.4 成本估算问题49
3.5 BDUF为什么如此笨重52
3.6 迭代53
3.7 品质54
3.8 测试与检验55
3.9 把现有的做法运用到情境驱动设计之中56
3.10 学习型的组织57
3.11 小结58
第4章 大型应用程序所面临的问题60
4.1 应用程序的大小体现在多个维度上61
4.2 大型项目所面临的问题63
4.2.1 需求问题64
4.2.2 缺乏终端用户的支持65
4.2.3 技术设计有问题67
4.2.4 采购与外包69
4.3 能够避免大型的项目吗72
4.4 小结75
第5章 应用程序与业务的关系76
5.1 理解业务流程76
5.2 不能表示为流程的应该怎么办80
5.2.1 业务服务81
5.2.2 资源管理81
5.2.3 评审与监测82
5.3 用更广阔的视角来观察83
5.4 将商业策略运用到应用程序的开发中85
5.4.1 开发速度85
5.4.2 在成本、性能、可用性之间权衡86
5.4.3 试验性的商业计划86
5.4.4 利益要等多久才能变现86
5.4.5 安全需求86
5.4.6 针对现有的企业文化来做设计86
5.4.7 为公司所追求的文化气氛而做设计87
5.4.8 为计划的变更留出余地87
5.4.9 为打造学习型的组织提供支持88
5.4.10 非商务型的应用程序88
5.5 分析88
5.5.1 流程的格式是否正确88
5.5.2 对依赖关系进行分析89
5.5.3 目标分析91
5.6 小结92
第6章 应用程序与用户的关系93
6.1 添加详情93
6.1.1 任务细节94
6.1.2 任务片段97
6.1.3 共同目标组98
6.1.4 数据表98
6.1.5 消息99
6.1.6 非功能型的需求100
6.1.7 使用情境设计的人101
6.2 确定各类用户102
6.2.1 办理业务流程的用户103
6.2.2 对工作进行监控的管理型用户103
6.2.3 使用本程序数据的其他应用程序的用户106
6.2.4 执行数据分析的用户107
6.2.5 执行应用程序管理工作的用户108
6.3 对情境设计进行分析109
6.3.1 流程层面的分析109
6.3.2 任务细节分析110
6.3.3 数据表详情分析111
6.3.4 用户组详情分析112
6.3.5 消息详情分析112
6.4 对情境设计进行评审112
6.5 小结114
第7章 应用程序与其他IT项目的关系115
7.1 集成设计116
7.1.1 应用程序116
7.1.2 服务117
7.1.3 数据库119
7.2 服务接口设计122
7.2.1 定义服务接口123
7.2.2 设计可复用的服务127
7.3 现有的应用程序128
7.3.1 确定现有的应用程序128
7.3.2 替换现有的应用程序130
7.3.3 用现有的应用程序来制作服务133
7.4 回顾设计流程134
7.5 小结135
第8章 用户界面设计与易用性137
8.1 逻辑用户界面138
8.2 把任务描述转化为单击操作141
8.3 易用性145
8.3.1 功能146
8.3.2 信息147
8.3.3 导航147
8.3.4 文本148
8.3.5 帮助148
8.3.6 直观而亲切的应用程序149
8.3.7 针对易用性进行设计150
8.3.8 监测易用性152
8.4 事务与任务完整性152
8.5 用户界面设计与其他细节设计之间的关系155
8.6 小结155
第9章 数据库设计157
9.1 数据库设计157
9.2 数据库设计理论163
9.3 程序员与数据库设计者之间的关系170
9.4 数据访问服务172
9.5 NoSQL173
9.6 小结177
第10章 技术设计的原则178
10.1 单服务器环境下的高性能原则178
10.1.1 缓存179
10.1.2 多线程与多元处理181
10.2 多服务器环境下的高性能原则184
10.2.1 前端并行184
10.2.2 后端并行187
10.3 高弹性原则190
10.4 测试与性能评估的必要性192
10.5 技术设计的流程193
10.6 小结196
第11章 技术设计的结构197
11.1 程序结构197
11.2 什么是框架201
11.3 各种编程语言203
11.4 选择编程语言及框架207
11.4.1 选择与公司的技能组合
前 言
前 言Designing the Requirements: Building Applications that the User Wants and Needs在对IT应用程序开发思考了大约15年之后，我终于写出了这本书。20世纪90年代后期，我开始做IT架构，当时写了一本名叫《IT Architecture and Middleware: Strategies for Building Large, Scalable Systems》的书（那本书的第2版是与Peter Bye合写的，于2004年出版，现在还可以买到）。那本书讲的是构建集成应用程序（integrated application）所需的技术，以及怎样确保应用程序的可扩展性、高可用性以及安全性。那时还有其他一些人也持有类似想法，由于我们的基本思路是向开发者提供一些可复用的服务，使其能够通过集成技术来迅速拼装应用程序，因此，业界把Peter与我所提出的那种解决方案称为面向服务的架构（Service Oriented Architecture，SOA）。SOA显然有很多优势，但实际上并没有发挥太大作用，因为其中好像缺了点什么。我从一开始就怀疑，缺少的那个东西，应该是应用程序的开发。换句话说，我们没办法很好地回答“怎样开发SOA应用程序”这个问题。此问题也可以表述为：“有人向我提出了一些要求，我该怎样确保后得到的是一套SOA解决方案，而不是一个单独的应用程序呢？”接下来的几年里，我对于架构问题想得少了一些，而对应用程序的开发问题，则想得比较多。
我刚开始编写应用程序，是在20世纪70年代后期。从那以后，我主要是在系统与环境软件的领域中进行bug修复及设计工作，我花了很多时间去修整数据管理软件，偶尔也会修复几个编译器或操作系统的bug。在这个过程中，我对系统软件的设计与编程有所接触。其后，我开始从事数据库和资源库的设计工作（对于版本控制问题，我有很多话要讲，但奇怪的是，没几个人愿意听）。到2000年的时候，我对计算机技术的很多方面都已经有了一些经验，但由于自己并没有直接从事大量的应用程序设计与编程工作，因此我还无法坦然地走到应用程序开发者面前，指出他们的做法是彻底错误的。
那时的程序开发专家对架构并没有多少兴趣，而是在开发方法上面彼此较劲。有些人崇尚BDUF（big design up front，大设计先行），他们提倡根据UML（Unified Modeling Language，统一建模语言）来做设计，提倡要安排好设计的结构，要用良好的文档描述这套设计，并且要在质量控制流程的监督之下完成整个设计。还有一些人崇尚敏捷（agile），他们认为应该尽快交付软件，然后通过一系列短期的迭代来对软件进行完善，使其满足利益相关者的需求。这两派的关键分歧，在于开发者与利益相关者之间究竟是什么关系。BDUF派认为两者是契约关系，认为软件开发项目应该有一个正规的需求收集环节，而敏捷派则认为应该把软件的功能分成小块，只有在准备实现某个小块的时候，才需要去制定详细的需求，而且认为应该在当前这一小块完工之后，就尽快把可用的软件拿给利益相关者去看。他们希望能够从利益相关者那里不断地获得反馈意见，并据此对软件开发的走向持续进行微调，以便终实现出正确的产品。笔者试着把这种敏捷开发方法讲给IT领域之外的人听，那些人觉得这不太可靠，然而敏捷派对BDUF派的批评，则确实引起了共鸣。因为利益相关者在没有看到实际运行的软件之前，确实不太了解他们当时提出的那个程序到底会做成什么样。合约并没有一种神奇的能力，可以保证做出来的IT程序一定会讨人喜欢。
这两派都不能够让人了解SOA究竟为什么开发不出来。对于他们来说，这个问题似乎并不存在。
那么，应用程序的开发为什么会背离SOA呢？一个原因在于，很多IT项目无法在预算之内准时交工，而且也拿不出利益相关者想要的产品。这就给IT开发者造成了压力，而IT开发者在压力之下的一个反应，则是严格划定项目的范围。他们想要控制项目范围之内的所有事务，同时对范围之外的事情不闻不问。这种应用程序开发项目所实现出来的成果，是一个单独的应用程序。如果只做一个大项目，那就会得到一个大程序，如果分成很多小项目来做，那就会得到很多小程序。此外，由于大型IT项目特别容易失败，因此开发者总是愿意把大项目分成多个小项目，从而做出很多小的程序，而不是只做出一个大的程序。但是另一方面，IT架构师却总想劝说程序开发者不要去构建单独的应用程序，而是应该构建一些服务，并且构建必要的机制，使这些服务能够合起来满足项目的需求。架构师的这种想法，当时并没有实现。在21世纪初，笔者开始认真地观察应用程序的开发过程，这一观察我才发现，原来内向的开发项目会做到如此令人震惊的地步：就连程序员和数据库设计者之间的关系都相当紧张。程序员对当前项目的目标太过专注了，他们没心思去想这些数据应该如何在各种组织之间分享并管理。
于是，笔者打算对应用程序的开发做出个变革，我要找出一种对架构有利的方式，使得每个应用程序都能对整体的架构起到推进作用，而不是破坏作用。
如果项目变得内向，那么其中一个原因就是需求变得内向，换句话说，这是因为开发者只关注某
我刚开始编写应用程序，是在20世纪70年代后期。从那以后，我主要是在系统与环境软件的领域中进行bug修复及设计工作，我花了很多时间去修整数据管理软件，偶尔也会修复几个编译器或操作系统的bug。在这个过程中，我对系统软件的设计与编程有所接触。其后，我开始从事数据库和资源库的设计工作（对于版本控制问题，我有很多话要讲，但奇怪的是，没几个人愿意听）。到2000年的时候，我对计算机技术的很多方面都已经有了一些经验，但由于自己并没有直接从事大量的应用程序设计与编程工作，因此我还无法坦然地走到应用程序开发者面前，指出他们的做法是彻底错误的。
那时的程序开发专家对架构并没有多少兴趣，而是在开发方法上面彼此较劲。有些人崇尚BDUF（big design up front，大设计先行），他们提倡根据UML（Unified Modeling Language，统一建模语言）来做设计，提倡要安排好设计的结构，要用良好的文档描述这套设计，并且要在质量控制流程的监督之下完成整个设计。还有一些人崇尚敏捷（agile），他们认为应该尽快交付软件，然后通过一系列短期的迭代来对软件进行完善，使其满足利益相关者的需求。这两派的关键分歧，在于开发者与利益相关者之间究竟是什么关系。BDUF派认为两者是契约关系，认为软件开发项目应该有一个正规的需求收集环节，而敏捷派则认为应该把软件的功能分成小块，只有在准备实现某个小块的时候，才需要去制定详细的需求，而且认为应该在当前这一小块完工之后，就尽快把可用的软件拿给利益相关者去看。他们希望能够从利益相关者那里不断地获得反馈意见，并据此对软件开发的走向持续进行微调，以便终实现出正确的产品。笔者试着把这种敏捷开发方法讲给IT领域之外的人听，那些人觉得这不太可靠，然而敏捷派对BDUF派的批评，则确实引起了共鸣。因为利益相关者在没有看到实际运行的软件之前，确实不太了解他们当时提出的那个程序到底会做成什么样。合约并没有一种神奇的能力，可以保证做出来的IT程序一定会讨人喜欢。
这两派都不能够让人了解SOA究竟为什么开发不出来。对于他们来说，这个问题似乎并不存在。
那么，应用程序的开发为什么会背离SOA呢？一个原因在于，很多IT项目无法在预算之内准时交工，而且也拿不出利益相关者想要的产品。这就给IT开发者造成了压力，而IT开发者在压力之下的一个反应，则是严格划定项目的范围。他们想要控制项目范围之内的所有事务，同时对范围之外的事情不闻不问。这种应用程序开发项目所实现出来的成果，是一个单独的应用程序。如果只做一个大项目，那就会得到一个大程序，如果分成很多小项目来做，那就会得到很多小程序。此外，由于大型IT项目特别容易失败，因此开发者总是愿意把大项目分成多个小项目，从而做出很多小的程序，而不是只做出一个大的程序。但是另一方面，IT架构师却总想劝说程序开发者不要去构建单独的应用程序，而是应该构建一些服务，并且构建必要的机制，使这些服务能够合起来满足项目的需求。架构师的这种想法，当时并没有实现。在21世纪初，笔者开始认真地观察应用程序的开发过程，这一观察我才发现，原来内向的开发项目会做到如此令人震惊的地步：就连程序员和数据库设计者之间的关系都相当紧张。程序员对当前项目的目标太过专注了，他们没心思去想这些数据应该如何在各种组织之间分享并管理。
于是，笔者打算对应用程序的开发做出个变革，我要找出一种对架构有利的方式，使得每个应用程序都能对整体的架构起到推进作用，而不是破坏作用。
如果项目变得内向，那么其中一个原因就是需求变得内向，换句话说，这是因为开发者只关注某
评论
还没有评论。