在对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世纪初，笔者开始认真地观察应用程序的开发过程，这一观察我才发现，原来内向的开发项目会做到如此令人震惊的地步：就连程序员和数据库设计者之间的关系都相当紧张。程序员对当前项目的目标太过专注了，他们没心思去想这些数据应该如何在各种组织之间分享并管理。
于是，笔者打算对应用程序的开发做出第一个变革，我要找出一种对架构有利的方式，使得每个应用程序都能对整体的架构起到推进作用，而不是破坏作用。
如果项目变得内向，那么其中一个原因就是需求变得内向，换句话说，这是因为开发者只关注某个具体的问题，而没有把公司的需求当作一个整体来看待。笔者从事架构工作的时候，花了很大的精力去研究IT应用程序究竟如何对业务提供支持。其中重点是观察IT程序怎样支撑业务流程，以及怎样在多个数据库之间保证数据的一致性。对上述每一个方面来说，IT应用程序的集成都是极其重要的。那么，这个重要的事项为什么没有反映在需求之中呢？业务经理为什么不请IT程序的开发者创建集成的应用程序呢？其实笔者是知道答案的。我做过管理，也和销售人员、营销人员及财务人员共事过，我知道他们是怎么办事的。而且我还见过形形色色的销售流程和业务流程。简单地说，我知道他们的难处。笔者明白，经理通常都是聪明人，而且有时比较有“心机”，笔者也明白，经理通常不会赞同别人，他们不仅总是和同事有分歧，而且也和上司有分歧。在如此复杂的环境之中，天真的IT开发者却在兴高采烈地向大家宣布，自己将会构建一款能够改变生活的应用程序，他们想要经理把程序应该实现的功能告诉自己。这或许说明，IT开发者和业务管理者应该改变各自的作风了，然而除此之外，笔者觉得还有更为深层的根本问题需要解决。
IT程序和复印机或iPad不同，后两者虽然也可以促进业务，但本身却并不是完成业务所必需的设备。而IT程序，则对业务活动起到至关重要的作用，现在如果没有它，那就根本没办法做业务。因此，在实现应用程序之前，最好是能确保该程序所要支持的业务活动是正确的，而且还要把细节做好，以确保公司知道正在做的是什么程序，以及该程序要支持的究竟是什么业务活动。IT界都认为应用程序的需求是持续变化的，并且发明了需求波动（requirements churn）这个词来描述这种变化。一般认为，这种变化与业务环境的迅速改变有关。没错，业务环境确实在变，但笔者认为，迄今为止，导致需求波动的最常见原因，则是对业务活动本身所做的设计过于草率。为了强调这个问题，我们应该使IT程序的设计者和业务的管理者明白一个道理，那就是：仅仅收集需求是不够的。无论是否喜欢这个说法，实际上他们都是在参与设计工作，都想要设计出一套更好的由IT程序做支撑的业务解决方案。因此，笔者认为，应该把需求收集当成一种设计，而不是当作一份清单。这样做，能够促使业务管理者和IT程序设计者改用另外一种眼光来创建需求。
这就是笔者想要对应用程序开发所做的第二项变革，也就是要把需求的收集当作一个设计项目来做，从而改变我们与业务管理者之间的关系。
笔者在做IT架构时，经常会遇到一个问题：展示IT应用程序所用的图表无法令人满意。这可以分成两个问题来说，第一，为了描述系统，我们必须从多个角度去观察它，并且要创建多份视图。比如，可能需要创建下列视图：
业务组织视图（business organizational view）—根据组织图来分隔业务。
业务流程视图（business process view）—这些流程通常要跨越业务职能边界。
数据视图（data view）—展示系统之中都有哪些数据，以及这些数据所在的位置。
程序员视图（programmer''s view）—业务规则如何转化成代码。
硬件配置视图（hardware configuration view）—这些计算机应该如何连接起来。
除了上述几种之外，还有很多种视图[1]（参考资料列于本书末尾）。可是这些视图模型都有一个缺憾，那就是很难看出不同视图之间的依赖关系，对于带有复杂IT系统的大型组织来说，尤其如此。而且大型组织之中的IT系统，其复杂程度也确实令人震惊，经常会遇到那种有上千个应用程序和上百个数据库的系统。（笔者一直怀疑，软件的复杂度其实与编写软件的程序员数量成比例，而不是与待解问题的复杂度成比例，当然这是另外一个话题。）
架构图的第二个问题在于，很多视图都缺乏严格的层次感。这话听起来似乎有点奇怪，笔者有必要详细解释一下。对于任何一个视图来说，我们一开始要看的都是宏观的信息，然后我们会放大这张视图，以查看其细节信息。前者好比从10 000英尺的高空远观，而后者则相当于从100英尺的距离上近看。为了实现远观和近看，我们有两种方式可供选用，笔者将其分别称为地图（map）与工程图（engineering drawing）。对于看地图的人来说，他会在放大的过程中发现新东西。一开始，你看到的是地图上的大路，放大之后，可以看见小路。但这就会出现一个麻烦，也就是你无法完全保证自己能够找到两点之间的最佳路径，因为这两点之间或许还有另一条捷径，而当前这个层次的地图上，是看不出那条捷径来的。工程图与地图不同，它会用构成对象的各个组件来描述这个对象，并且会画出这些组件之间的拼合方式。此外，组件也有可能是由更小的子组件所构成的，于是，我们还可以再用一张图纸画出这些子组件之间的拼合方式。我们在沿着层级向下查看的过程中，并不会发现新的对象，而是会看到现有的对象是怎样逐步分解开的。这就体现出了它和地图之间的差别。例如，我们可以观察一辆汽车的工程图，然后问：“这车有多重？它的重心在哪？”只要根据工程图确定每个组件的重量和位置，就可以算出上述问题的答案，而不用担心在计算过程中又冒出来其他东西。问题在于，IT架构视图更像是一种地图，而不是工程图。比如，宏观的网络图上面，可能画有每一台主要的服务器和每一条主要的网络连线，而当我们放大这张图时，则会发现一些小的服务器、路由器及PC。与之类似，宏观的数据视图上面，可能只画有几个主要的数据表，而我们必须放大之后，才能看到其他几百个更为详细的数据表。
地图和工程图之间的区别为什么这么重要呢？因为我们一直都会感受到一种现象：IT应用程序并不像按照工程图制作出来的车辆与建筑物那样可靠。笔者发现有一段时间，软件工程师这个头衔特别流行，但后来就逐渐淡出了。我当时觉得编程这一行似乎与工程无缘，虽然这话可能有些难听，但我可以给出一个简单的理由，那就是：我们当时并没有一种相当于工程图的东西。大家读完第1章之后，自然会明白这个理由为什么能够说得通。笔者在想，有没有一种适用于IT应用程序的宏观工程视图呢？开始写作本书的时候，我其实已经找到了办法，只是这个办法从形式上来看，与传统的工程图有相当大的区别。
于是，这就引出了我想实行的第三项变革，也就是要把应用程序的设计工作做得更像工程学。
我在思考应用程序开发的时候想到了一些主意，我想告诉别人，但很少有人愿意听。我没有做案例研究，没有很大的名气，而且也不像某些人那样，天生就很会推销自己的观点。我写了一些文章，也做了一些演讲，每个人都在礼貌地听我说话，但他们没有任何反应。那正是BDUF派和敏捷派争论得最为激烈之时，因此我对自己所遭受的冷遇，似乎并不应该感到惊讶。这就好比你走进一间屋子，发现里面的人正分成两派互相斗嘴，他们此刻所关心的，只是你到底站在哪一边而已。
那是10年之前的情况。尽管BDUF派和敏捷派之间的争论后来稍稍停歇，但应用程序开发者依然无法在业务人员之中博得好名声。那时我又做回了程序员，我花了很多时间试图去开发绘图工具，想要画出现在本书里的这种图表，而且我也下了很多功夫去编写应用程序。虽说笔者的基本想法并没有发生太大变化，但我现在论证起这些观点来，会显得比原来更加充实。当年我写了一些零散的文章来表达我的意思，而现在，我可以把所有内容拼合起来，向大家更全面地展示应该怎样从头到尾开发应用程序。
我知道某些读者有强烈的个人见解，而且有人觉得自己已经解决了所有的应用开发问题，因此不需要听我在这里指点。其实，本书更多的是在分析问题，即便不赞同书中的解决方案，它们依然可以激发你去思考这些问题。笔者希望本书能够活跃大家的思路。
谈论应用程序设计的书籍、文章和网站相当多，它们都给出了很多好的建议，而且列出了大量的清单。有的能够告诉你应该如何迭代、应该如何把项目划分成多个阶段；有的能够教你如何明智地应对利益相关者、应该如何把项目展示给管理者看；有的能够提出一些原则，指导你进行开发，并且告诉你应该在什么时候开会、应该请哪些人参加会议、应该怎样安排会议，以及应该在会议上讨论什么样的内容。既然已经有了上述那些资料，那么笔者所写的这本书，还能给你带来什么好处呢？这么说吧，如果我们按照某些从业者所想的那样，把应用程序的开发比作一种信仰，那么前面那些资料告诉你的是怎样布道、怎样举办仪式，而本书告诉你的则是应该信仰哪些理念。
总之，笔者对应用程序设计的看法是：
我们并不应该单纯地收集IT应用程序的需求，而是要对这些需求进行设计。应用程序的设计工作，正是应该建立在这样一种观点之上。
应用程序的设计应该更像一门工程学，我们尤其应该在实现程序之前，先对设计进行分析，并寻找其中的瑕疵。
当前的应用程序应该和其他应用程序互动，以打造一套连贯的IT架构。
本书结构
本书大致分为三部分。前四章开场，中间七章详述设计，最后两章收尾。
开场部分的第1章将讨论笔者刚才列出的三个看法，并且告诉大家它们为什么很重要。这一章还会讨论设计的本质，我觉得这是个遭到很多人误解的概念，对于工程设计来说，更是如此。
工程设计的一个重要方面是设计体系，该体系涵盖了从需求到实现的各个层面。第2章要讨论的就是这个体系。第5～11章会详细描述体系之中的各种设计。
第3章有两个目标，第一是要指出笔者所讲的设计方式，与现有的设计方式之间的相对关系，第二是要指出笔者的做法，建立在现有的哪些设计实践与工程管理实践之上。
第4章要解释现有的设计办法为什么不能够应对大型的应用程序，而且要讨论如何缓解这个问题。
接下来的几章将详细讲解应用程序的设计。第5章和第6章讲的是如何对需求进行设计，换句话说，就是如何设计业务解决方案。IT应用程序必然位于业务解决方案之中，但它只是该方案的一个组成部分。
第7章讲述的是怎样确保当前开发的应用程序能够与其他程序及数据库协同运作。该章还会介绍IT应用程序服务，并讲解怎样把大量的开发工作分解成多个易于应对的小项目。
开发应用程序的时候，笔者所关心的一个大问题，就是程序用起来是否方便。我强烈主张易用性必须提前进行设计。这是第8章要讲的话题。
第9章正如其章名所说，讲的就是数据库的设计。本书并非数据库设计方面的专著，所以这一章是写给那些对此不太熟悉的读者看的，笔者要把数据库设计者所应考虑的事项告诉大家。
第10章和第11章讲的是技术设计。这两章并不会把技术设计的全部知识或大部分知识讲给你听，而是想要帮助非技术的设计者更好地与技术设计者沟通。谈论技术设计原则的那一章，主要讲的是制作易缩放性和弹性较高的应用程序时所遇到的困难，以及怎样克服这些困难（它至少能使你明白怎样从原则上应对这些困难）。谈论技术设计结构的那一章，讲的是软件框架为什么能够使程序员的工作更加轻松，以及为什么能够使项目进展得更加顺畅。
本书的收尾部分一共有两章。第12章专门谈安全问题。设计应用程序的时候，我们在每一个层面上都应该考虑安全问题。笔者本来可以把这些问题分散到其余各章之中，但我并没有那样做，而是把程序设计方面的安全问题全部集中到了这一章里，以免这些内容显得过于松散。从安全策略到编程实现的各种话题都会在这一章讲到。
第13章是本书最后一章，笔者会总结前面各章的重点，并展望应用程序开发的趋势。
书末有一份附录，列出了与情境设计有关的一些分析技术。在本书之中，情境设计可能是大家最感到陌生的一个话题。此外，还有一份参考资料列表。
本书的目标读者
本书是写给设计者与项目经理看的，同时笔者希望程序员也能够对其中的内容感兴趣，因为这可以拓宽他们的视野。
笔者想把这本书写成非技术型的书籍。我确实会提到一些IT技术和方法，但它们多半是为了举例而出现，并不是主要论证过程的一部分。之所以会提起某个产品或某项技术，只是想给知道这种产品的人提供一些建议，这并不意味着你也必须知道该产品。笔者发现，在看一本这样的书时，我总是禁不住用自己从前的经验去审视其内容。有时为了更加精确地表达我想要说的意思，笔者会提到某些技术与现有的某些设计方式。即便你不清楚这些内容，依然可以放心地读这本书。
规模较大且要求较高的IT应用程序，不太可能只由一位设计者负责设计，而是应该由整个设计团队来做，团队里面会有一些具备专门技能的成员，比如，有人懂技术设计，有人懂数据库设计，有人懂安全设计。本书的目标之一，是向设计团队之中的每位成员提供信息，使他们都能够理解团队里的其他人所做的工作。如果要用一句话概括本书的主旨，那就是：帮助设计团队携手创建出公司真正想要的设计方案。
致谢
本书得益于很多人的帮助，无论他们是否意识到，笔者都要在这里表示感谢。尤其要感谢Peter Bye、Alison Bye、Andy McIntyre、Graham Berrisford、Kevin Bodie、Robert Bogetti、Celso Gonzalez和David Janzen，而且也要感谢出版团队的成员Chris Guzikowski、Michelle Housley、Chris Zahn、Susan Zahn、Mary Kesel Wilson和Barbara Wood，他们帮我出版这本书，并在写作过程中给我以指导。当然还要感谢妻子Judy伴我写完这本书，我本来是应该用这些时间去清理花园和修补门窗的。
计算机\软件工程
[英]克里斯?布里顿（Chris Britton） 著：
Chris Britton IT专家，曾就职于Unisys公司，从事过系统软件设计、大型数据库系统修复、营销支持、IT架构及管理等多种事务，并撰写了《IT Architecture and Middleware: Strategies for Building Large, Scalable Systems》一书。他于2001年离开Unisys，在自己的公司里做咨询工作，并且开发软件应用程序。
爱飞翔 译：暂无简介
应用程序的开发方法（methodology）是IT界经常谈到的话题。要谈开发方法，就绕不开需求，各种开发方法都想保证开发出来的产品能够满足需求，本书作者Britton先生所提出的情境驱动设计（context-driven design）也不例外。与其他方法相比，该方法的特色在于它强调对需求进行设计，提倡通过各种角度来反复地理解、分析、验证并修改需求设计方案，使得最终实现出来的产品能够令用户满意。
为了概括这种开发方法，作者提出了六框设计模型（six-box model of design，参见图2-3），该模型分为四层。最高的一层是情境设计，它拟定了应用程序的使用情境，令我们能够全面了解任务、用户组、数据表，以及任务间的关系，其下一层是集成设计，用来阐明本程序与数据库之间以及其他程序之间的关系，确保开发出来的程序能够与整个组织的IT环境相协调。第三层是用户界面设计、技术设计与数据库设计，它们从三个方面深入地描述情境设计方案。有了上述三层的指导，程序员就可以准确地在第四层中把产品实现出来。
这套六框设计模型能够从多种角度审视应用程序的设计，使我们的眼光更加开阔，从而能够考虑本程序与周边程序之间的协调关系，以及与公司总体策略之间的契合程度，而不会过分局限在实现层面。这是一种从重视实现到重视设计的适度回归，它扭转了那种以编程来代替设计的思维倾向，使我们可以把设计与实现有机地融合起来。
值得注意的是，情境驱动设计并不完全等同于传统的瀑布式（waterfall）设计，它与当今流行的很多开发方法一样，也强调迭代式的（iterative）开发。然而不同之处在于，情境驱动设计会把迭代式的流程从代码实现环节扩展到需求设计上面。在情境驱动设计法的每一个设计环节中，我们都会收集需求，并根据自己对需求的理解提出设计猜想，然后对其进行细化及分析验证，并送交利益相关者进行评审。其后，我们会根据评审意见做出修改，并反复执行“理解—猜想—细化—分析”这一流程，以求不断地完善设计方案。
近年来兴起了一些以快速迭代及彻底测试为特征的开发方法，它们对于过度设计（over engineering）有很大的矫正作用，但有时也会矫枉过正，令我们忽视了产品的整体设计，使其只能满足一些孤立的功能点，而无法从整体上全面地满足客户的需求。作者所提出的情境驱动设计方法，正可以通过对设计的强调来弥补这个缺陷。大家可以在思考和实践之中评判这套开发方式，并探求设计与实现之间的平衡。
在翻译本书的过程中，我得到了机械工业出版社华章分社诸位编辑和工作人员的帮助，在此深表感谢。
由于译者水平有限，不足与疏漏之处，请大家发邮件至eastarstormlee@gmail.com，或访问github.com/jeffreybaoshenlee/dtr-errata/issues留言，给我以批评和指教。
爱飞翔
出版者的话
译者序
前言
第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 选择与公司的技能组合相匹配的语言207
11.4.2 选择可以满足应用程序性能目标的语言208
11.4.3 选择可以满足集成需求的语言208
11.4.4 如果需要进行小组合作，请选择有利于小组合作的语言208
11.4.5 在选择编程语言的同时，选择相应的版本控制软件及项目管理软件209
11.4.6 选择与自己的开发方法相协调的语言209
11.5 对框架进行扩展210
11.6 实现通用的功能212
11.7 小结213
第12章 安全设计215
12.1 IT应用程序的安全原则216
12.1.1 认证217
12.1.2 访问控制218
12.1.3 用户管理219
12.1.4 安全保护219
12.1.5 安全监控221
12.2 每一种设计之中的安全因素222
12.2.1 情境设计222
12.2.2 集成设计225
12.2.3 用户界面设计226
12.2.4 数据库设计226
12.2.5 技术设计227
12.3 安全编程228
12.4 小结231
第13章 应用程序开发展望234
13.1 情境驱动设计如何改变应用程序开发234
13.2 情境驱动设计的机遇235
13.2.1 新工具236
13.2.2 情境设计与驱动设计237
13.2.3 用户界面设计与数据库设计238
13.2.4 技术设计238
13.3 应用程序开发所面对的挑战240
13.3.1 灵活性240
13.3.2 运营242
13.3.3 正确性242
13.3.4 品质243
13.3.5 职业精神244
13.4 小结245
附录A 情境设计核对表246
参考资料251
