《威胁建模：设计和交付更安全的软件》——3.11　小结

https://yqfile.alicdn.com/6ec696e3acab5ead903c7f9a25ac9ef090aeb814.png" > 前 言Designing the Requirements: Building Applications that the User Wants and Needs在对IT应用程序开发思考了大约15年之后,我终于写出了这本书.20世纪90年代后期,我开始做IT架构,当时写了一本名叫<IT Architecture and Middlewa

3.9 把现有的做法运用到情境驱动设计之中 上面几节分别谈了迭代.品质以及测试和检验等,其实对于这些内容来说,有人比笔者谈得更为广博,也更为深入.我们可以用一句话来概括前几节的内容,那就是:"要采用最佳的做法."笔者首先拿实现阶段做例子,来讲述我们所应该采用的做法: 以用户界面的设计方案为指导,把工作分成多个单元,并计算每个单元含有多少个功能点.这些单元要尽量划分得小一些,使得每个单元能够在2-4周内完成. 程序员必须把能够运行的代码放在系统测试环境之中顺利演示出来,然后才算完成了这个

3.11 小结 大家可能会发现,笔者在讲述自己的这套IT设计方法时,有很多地方都没有谈到.笔者没有像其他设计方法的讲述者那样,对原则.做法.策略.会议以及任务版等内容进行讲解.之所以这样做,是因为情境驱动设计本身并不想发明一套最佳做法,而是想把其他设计方法之中已有的那些做法移用过来.例如,如果我想把设计阶段做得较为自由一些,那我就会采用类似于当前敏捷项目的做法来进行编程.即便采用设计先行的办法,也依然可以分成多个阶段来发布,依然可以把工作量拆成小块,以便渐进式地进行交付,并且依然可以把最新版本展

3.3 用例 在前面几节之中,笔者对敏捷开发做了批评.除了敏捷开发,目前还有一种比较流行的做法,那就是通过编写用例来捕获需求.这一节要讨论用例与情境设计之间的区别. 用例,本质上是用一系列带有序号的步骤,来对场景进行简单的文字描述,就此而言,我们可以在各种详略不同的层面上撰写用例.此外,还有一些用例图可以展示每位参与者所使用的用例,以及用例之间的扩展关系,这里所说的参与者(actor),与情境设计之中的用户组有些相似.笔者稍后会讨论什么叫做"扩展".用例图与笔者所说的情境图看起来很像,

2.8 这样做真的是工程化的设计吗 笔者提出的六框设计模型,与经典的工程组件分解图并不完全相同.因此,有人会问,这样做真的能像第1章所说的那样,实现工程化的设计吗?这个问题不能简单地用是或否来回答.在建筑学和机械工程学之中,宏观设计图与组件设计图的绘制方式是相同的,都需要确定一些形状及表面,而且所有的组件都有其尺寸及重量.此外,从顶层设计到底层设计之间的层数,是没有限制的,换句话说,可以把组件分成子组件,再把子组件分成更小的子组件,这种划分可以多次执行.然而,对IT软件开发所做的设计,却不是这样

2.3 集成设计 集成设计的主要目标是: 把任务划分到各个应用程序与服务之中. 决定数据表与数据库之间的指派关系. 以应用程序之间所传递的消息为视角,来定义集成方面的需求. 对于其他更为详细设计的来说,集成设计确定了这些设计的范围.用户界面设计可以针对每个应用程序或服务分别来做(对于服务来说,其用户指的是另一个程序),数据库设计可以针对每个数据库分别来做.尽管技术设计也可以针对每个应用程序或服务分别来做,但是在大多数的公司里面,我们都可以令多个应用程序与服务共用同一套技术设计.图2-5演示了如何

2.4 技术设计 集成设计之下的那一层,可以分为三个领域:技术设计.用户界面设计与数据库设计.本节讨论技术设计.技术设计有两大目标:1.设计出可以满足非功能型需求的解决方案.2.设计出可以尽量简化功能编程的解决方案.非功能型的需求,是指那种与业务工作并没有直接支持关系的需求.它们包括: 所应满足的吞吐量及响应时间. 可用性方面的目标. 灾难恢复方面的要求. 安全设计.你需要知道应用程序的安全漏洞.修复这些漏洞的办法,以及系统监控与系统管理工作的执行方式与执行地点. 系统操作和系统管理的易用性.

第1章 情境驱动设计入门 本书讲的是如何设计IT应用程序.笔者写这本书,是想建议大家采用与原来不同的办法去做设计,尤其是想进行下列三项变革: 要使人意识到自己并不是在收集IT应用程序的需求,而是在设计它们.对应用程序所做的设计工作,正是建立在这样一种认知之上. 要把程序的设计做得像工程学一样,特别是要在实现之前先对设计进行分析,并寻找其中的缺陷. 要确保当前所开发的应用程序能够与现有的或同时开发的其他应用程序协同运作,以创建出一套连贯的IT架构. 本书要谈论如何思考应用程序的设计,以及如何对设计

第2章 设 计 体 系 第1章说过,要想做工程化的设计,就必须有一套设计体系.那么本章我们就来看看能不能为IT软件的开发工作构建出一套具有工程学水准的设计体系,并且看看我们是否值得去构建这样的体系.本章分为三个部分.2.1节从下至上检视整个设计体系,以解释我们为什么应该建立该体系.接下来的2.2节-2.7节,用从上至下的方式来观察这套体系,使大家对设计之中的信息流动情况有所了解.把这套体系中的所有部件都展示出来之后,笔者会在2.8节之中回到本章开头所提出的那个问题上面.最后的2.9节是对本章所做

1.2 什么是设计 设计是个很常见的说法,没有几个人会深挖它的含义,但如果仔细想一想IT应用程序的设计与一般的设计的区别,你就会发现,IT应用程序其实是很特殊的.这种特殊性促使我们思考一个问题:应用程序的设计真有这么特殊吗?或者说,我们是不是将它看得太过特殊,以致忽视了一些最为基本的共性? 首先,我们来定义设计这个词.设计,是对想要构建的事物或系统所做的概念化处理.设计(design)既是名词,又是动词.刚才定义的是名词,现在我们给出动词的定义:(作为动词的)设计,就是指创建设计方案. 笔者故意