本书的主要目标是使开发团队用最小的预算获得最大的帮助，开发出最佳的软件。本书向你推荐了一种轻量级、灵活的软件开发过程：刚刚够用的过程，刚刚够用的形式，以及刚刚够用的文档。本书全篇贯穿了四大主题：只维护一个单源模型；最小元模型；扰乱改变模型；持续的质量测量，主要讲述的是如何使用Together这一软件开发平台帮助您在更短的时间内交付同样质量或更高质量的软件，即快速开发最佳软件。
本书适合于软件开发团队、团队领导和项目经理，尤其是将Java或类似的面向对象语言作为程序设计语言的软件开发团队使用，也适于教师、学生、培训人员及顾问做参考手册。
第1章 Together——与众不同之处
1.1 现在需要Together
1.2 本书所蕴含的原则
1.3 为什么说Together是一种令人激动的技术
1.3.1 维护单源模型（Live Source技术）
1.3.2 通过配置管理控制协作
1.3.3 烦琐事务的自动化
1.3.4 使用模式传播专家经验
1.3.5 持续的质量监控和反馈
1.4 过程. 过程, 自始自终
1.4.1 只构造所需要的
1.4.2 要素
1.4.3 非线性生命周期总是处于过程之中
1.4.4 最小元模型
1.5 下章内容
第2章 最后的步骤：部署和运行
2.1 轿车服务（CarServ）系统
2.1.1 Cloudscape（云图数据库）
2.2 演化的系统
2.3 检查单个模型
2.4 改变和重新部署
2.5 文档生成
2.6 下章内容
第3章 第1步：对领域建模
3.1 说明书的元素
3.2 领域建模
3.2.1 着色建模
3.3 类型和类
3.4 把类型建模成类
3.4.1 建模属性
3.4.2 无导航的关联
3.4.3 建模操作
3.5 下章内容
第4章 受益者步骤：说明需求
4.1 业务流程
4.1.1 UML图
4.1.2 业务用例与系统用例
4.1.3 CarServ的业务用例
4.1.4 判定点和对象流
4.2 系统功能
4.2.1 什么（What）. 怎样（How）. 为什么（Why）
4.2.2 CarServ系统用例
4.2.3 脚本（Scenarios）
4.3 建模用户：参与者
4.3.1 参与者与人物（persona）
4.3.2 参与者作为安全角色
4.3.3 批处理
4.4 使用状态图明确需求
4.5 非功能性需求
4.6 配置管理
4.7 下章内容
第5章 控制步骤：以特征为中心的管理
5.1 使一切都在控制中
5.2 为什么以特征为中心
5.3 为什么要用时间段（Timeboxes）
5.3.1 一定规模内的自相似
5.3.2 贯穿于生命周期的自相似
5.4 为什么是适应的
5.5 估算实现特征的代价
5.5.1 三点估算法
5.5.2 项目速率
5.6 用例与特征
5.6.1 在Together中的用例和特征
5.6.2 重构的代价和体系结构
5.6.3 配置管理
5.7 下章内容
第6章 持续的步骤：测量质量
6.1 如何测量质量
6.1.1 黑盒测量和白盒测量
6.2 测试
6.2.1 功能测试
6.2.2 非功能测试
6.2.3 单元测试
6.2.4 Together的测试框架
6.2.5 多少单元测试才是充分的
6.3 度量
6.4 审核
6.4.1 定制审核
6.4.2 编译模型
6.4.3 其他观点
6.5 生成文档
6.5.1 超链接
6.5.2 设计模式
6.5.3 Together的文档生成
6.5.4 检查与审查
6.6 下章内容
第7章 微观步骤：设计和实现
7.1 一个已实现的例子
7.1.1 把一个新需求加到构造中
7.1.2 定义测试
7.1.3 设计用户交互
7.1.4 设计对象交互
7.1.5 设计持久性数据
7.2 有效的交互设计
7.2.1 此前和此后
7.2.2 选择设计
7.2.3 指定维护关联的责任（哪个对象维护关联）
7.2.4 改变视角
7.2.5 在交互图中避免细节
7.2.6 异步交互
7.3 有效类图
7.3.1 保存领域模型视图
7.3.2 包类图与类图
7.3.3 阐明设计时易忽略的角落
7.3.4 类符号分隔栏
7.3.5 双向关联
7.3.6 限定的关联
7.4 使用模式
7.5 使用Together重构
7.6 定制Together
7.7 下章内容
第8章 宏观步骤：体系结构
8.1 什么是体系结构, 为什么它很重要
8.2 框架优先还是功能优先
8.3 体系结构的职责
8.4 给出关于体系结构约束的文档
8.5 对依赖关系的管理
8.5.1 包间依赖
8.5.2 依赖倒置原则
8.5.3 强制依赖
8.6 层间的交互
8.6.1 从表示到应用
8.6.2 从应用到领域
8.6.3 领域和数据管理
8.7 版本和配置的管理
8.7.1 版本控制下的模型元素的移动和重命名
8.8 下章内容
第9章 J2EE体系结构
9.1 利用Together轻松使用J2EE
9.1.1 开发
9.1.2 与Tomcat绑定在一起交付
9.1.3 部署到外部应用服务器
9.1.4 其他的J2EE支持
9.1.5 测试
9.1.6 总结
9.2 J2EE并不那么容易
9.2.1 层次的体系结构
9.2.2 表示层的问题
9.2.3 持久层的问题
9.2.4 状态
9.2.5 总结
第10章 结束语
10.1 我们需要你再做一次
10.2 简单总结一下
10.2.1 一个单源模型
10.2.2 最小元模型
10.2.3 扰乱改变模型
10.2.4 持续的质量测量
10.3 现在结束了
附录A 安装案例研究软件
A.1 开始之前
A.2 Together的下载和安装
A.2.1 环境变量
A.3 案例研究
A.3.1 Cloudscape数据库
A.3.2 案例研究源码
A.3.3 建立数据库
A.4 快速测试
附录B JUnit和JUnitX
B.1 动机
B.2 开始
B.3 使用Together的测试框架创建测试用例和测试包
B.3.1 创建测试用例
B.3.2 创建测试代理
B.3.3 创建测试包
B.3.4 运行测试
B.4 场景背后
B.4.1 框架类
B.5 扩展
B.6 在实践中写测试
B.6.1 tearDown
B.6.2 改变System.out
B.6.3 （使用TestProxy）测试隐含功能
B.6.4 测试代理的意外异常
B.6.5 线程化
附录C 使用.config文件定制Together
C.1 动机
C.2 技巧和诀窍
C.2.1 文件名
C.2.2 加入而不是覆盖
C.3 Bean的特性
C.4 文档化模式实例
C.5 着色注释
C.6 对照对象图
C.7 文档化包依赖
附录D 定制Together模板
D.1 动机
D.2 幕后
D.3 汇集API模板
D.4 模板
附录E 定制Together的检查器
E.1 动机
E.2 检查器特性生成器
E.3 使用基于配置的检查器
E.4 开放的API
E.5 检查器框架
E.6 结论
附录F RwiSupport框架
F.1 动机
F.2 框架类
F.3 可能的增强
附录G CarServ用例研究
参考文献
Andy Carmichael：在软件工程领域工作了20年, 专门研究软件开发方法和工具. 在担任TogetherSoft公司的专业服务主管及欧洲和英国的技术服务主管期间, 与Dan Haywood合作编写了《快速开发最佳软件》. 他还编写了其他两本书：《对象开发方法》和《开发业务对象》. 他是“Application Development Advisor”杂志的技术编辑.
Dam Haywood：作为一名独立的顾问和Sybase专业服务顾问, 在大大小小的软件开发项目中工作超过12年.
◣ 编写本书的目的是什么
强迫你改变工作方式的产品和激发你以不同方式工作的产品存在着巨大的区别. 被迫以“别人的”方式工作很不舒服, 并且效率低下, 自由地发现较好的工作方式令人愉快, 并且能够将新的思想注入别的方法以完成工作.
我们编写本书的缘由是称为Together ControlCentre的产品, 以及它所支持的不同的工作方式. 我们不只是为Together的用户编写此书, 也希望, 与其竞争的开发平台或没有使用开发平台的用户也能够从中获益. 但是, 我们承认, 本书的灵感来自Together.
你并不是经常能碰到“鼓舞人心的”产品, 对于大多数用户而言, Together似乎正是这样的产品. 相比较于先前的. 具有代表性的建模和代码生成工具, Together无疑是革命性的. 对于我们而言, Together ControlCentre使我们重新考虑开发团队如何协同工作. 因此, 本书的目的之一就是Together如何帮助你在更短的时间内交付同样质量或更高质量的软件——简而言之, 即如何快速开发最佳软件.
◣ 本书的读者是谁
本书是为软件开发团队. 团队领导, 以及他们的经理人员而编写的——尤其是将Java或类似的面向对象语言作为其程序设计语言的小团队.
小团队, 其开发人员的人数多于两个, 少于12个. 小的团队没有必要为了管理的需要进一步细分. 它的日常性管理开支最小, 且组成人员彼此之间非常熟悉——至少在项目开始的几个月之后是这样. 相对于大规模团队, 尽管他们的资源较少, 但这些特点给他们带来了很大的优势. 项目失败的可能性会随着开发团队规模的扩大而显著增加*. 这就是为什么大量的商业软件（如果不是大多数）是由小的团队开发而成的.
小团队没有必要使用著名的软件开发过程. 本丛书的其他书用于帮助各种各样著名过程的实践者, 诸如FDD（Palmer & Felsing 2002）, XP（Astels, Miller, & Novak 2001）, 以及UP（Norman & Kranz, 正在发行）成功地应用它们. 但是, 本书更多地推荐使用最简单的方式完成任务, 同时, 又从很多更为正式的过程中, 汲取最好的思想和建议. 我们的目标是使开发团队用最小的预算获得最大的帮助.
本书主要是为用Java实现软件的那些人员而编写的. 我们希望这不会阻止那些使用C++. C#和VB.NET的人员从本书中寻求知识. 但是, 在这里我要向他们道歉, 本书通篇使用了Java的例子, 我们所提供的可供下载的用例研究也是用Java编写的, 并且, 分布式系统和持久性的讨论专门使用了Java环境, 尤其是J2EE体系结构.
当然, 我们希望很多其他的人对本书感兴趣：大规模团队中的人员或使用其他语言的人员. 这些人包括业务分析人员. 用户. 测试人员, 甚至是学生. 教师. 培训人员. 顾问. 但是, 本书是为技术（软件开发）人员, 而不是非技术人员而编写的. 最好的项目往往是这样的：对于在给定的时间内能完成哪些功能, 在业务和技术人员中存在一种信任. 根据我们的经验, 当业务代表和用户真正对开发过程感兴趣, 甚至在某些情况下作为项目成员加入到开发团队的时候, 能够最好地建立起这种信任. 我们确实讨论了在开发过程的某些阶段, 业务代表和用户主动进行参与, 尤其是在建模问题领域. 需求说明及排出需求优先顺序的时候. 在这些地方及其他方面, 我们希望本书能够为增进技术团队和非技术团队之间的相互理解做出贡献. 因此, 如果你认为你是非技术人员, 那么, 我们希望你了解一些Together能做什么, 以及通过使用它如何更有效地开发软件.
◣ 本书是如何组织的
第1章“Together —— 与众不同之处”, 讲述了Together为什么是一个令人激动的技术. 在这里, 我们并不对市场包装感兴趣. 与其他平台相比, Together的确与众不同, 并且展示了新的潜在的价值. 我们想深入了解它到底是什么, 以及为什么使团队表现得如此不同凡响. 在第1章中, 我们也介绍了贯穿全书大部分章节的四个重要的主题：
■ 只维护一个单源模型
■ 最小元模型
■ 扰乱改变模型
■ 持续的质量测量
只维护一个单源模型是基于这样一种思想：尽管以多种形式查看和修改, 系统的信息应该仅在一个地方保存而且只维护一次.
最小元模型是任何开发过程中需要定义和有效交叉引用的最基本元素的一个视图, 这些开发过程包括需求. 测试. 设计和实现.
扰乱改变模型是指在一个小的迭代步骤中, 按照从一个有效的构造转移到下一个有效的构造, 考虑开发过程的一种方法. 这并不是一个不同的开发过程, 而是考虑大多迭代演化开发过程的一种方法.
持续的质量测量是迭代演化生命周期不可或缺的部分. 与瀑布生命周期相比, 不同的是, 它强调开发的活动和工具环境.
做完这些介绍之后, 本书剩下部分的结构是什么？很多书是以从需求到部署这样的开发过程的每一个步骤进行组织, 或者以依次介绍每个UML图的类型来组织. 但这么做会有一些障碍. 首先, 很难把图的类型和一个软件开发过程联系起来——在软件开发过程的各个阶段会涉及许多图, 并且分别强调不同的方面. 其次, 这样的方法是人造的. Together让你以一个有机的和演化的方法来开发软件, 并且我们想写一本让你以同样的方式阅读和探索的书. 我们坚决反对以不同图的类型组织书的另一个原因是：这样做会很无趣——无论是对读者阅读还是对作者写作来说.
接下来, 提出了一个有趣的问题：为了交付和使用软件至少需要做什么？然而, 如果已经有一些软件（一般都会有）, 答案就是只要交付和使用软件就行了. 在那之前, 你可能还要做其他的工作, 特别当想要不同的或附加的功能或质量, 但又必须使用这个软件的时候. 此外, 在考虑为小团队的开发过程寻找通用的方法时, 最后一步也是第一步, 因为在你把功能加到系统前, 你必须确定系统当前的功能可以运行.
因此, 我们决定第2章应该从最“后”一步开始. 这章命名为“最后的步骤：部署和运行”. 借此机会, 将介绍书中大多例子要用到的一个领域模型. 在系统实际运行时, 探索Together的各种能力, 这是一种好的学习方法. 阅读这一章的最好方法是让电脑使用在本书相应的网站上讨论的软件. 如果现在上网, 检查一下看能否上www.bettersoftwarefaster.com. 从这里开始, 我们可以确保, 你所阅读的内容和使用的软件是从一个有效的起点开始——这个起点就是已有的代码和所选的开发环境能够正确地运行, 并且通过所有定义的测试.
第3章“第1步：对领域建模”中, 我们考虑了对于新团队而言的一个重要的起点. 尽管这也是讨论类图要素的好机会, 但是这章的重点仍然是怎样构造一个使业务专家和软件开发团队之间进行有效交互的模型, 这些业务专家知道业务的本质和新系统是什么样的, 软件开发团队必须实现这样的系统. 因为模型定义了需求和实现类的词汇, 并且也与持久数据和用户交互的定义相关. 这一章使用Peter Coad和其他人一起定义的着色法**建模的对象, 这有助于实现分析模式和领域中立的模型, 并且提高类型的可读性（Coad, Lefebvre,e De Luca 1999）.
小团队在时间紧迫的项目中有时会忽视获取良好的需求理解, 但这是一个潜在的项目致命的错误. 第4章“受益者步骤：说明需求”讨论了使用UML, 特别是用例图和活动图来获取需求说明. 这些图很容易理解, 这种特性对于使这些图有效也是重要的. 但是, 建立有效的需求绝非简单, 我们讨论要牢记在心的关键问题, 特别是那些在小团队所需要的灵活的. 迭代的过程中, 使需求简单和服从管理的策略.
第5章“控制步骤：以特征为中心的管理”说明了我们向团队推荐的计划. 估计和项目控制的过程. 这一章中, 我们的兴趣是使计划和管理尽可能简单和透明. 此外, 前面提出的问题也是相关的：为了交付软件至少需要做什么？——这就是我们的目标. 一个用来改善迭代生命周期管理的关键的简化是合并计划和需求的单元, 不管这些单元是用例还是特征. 把做这个简化的开发过程称为“以特征为中心的”——这也是以它为本章标题的原因.
有人可能会这样理解追求最小化的目标：如同最小化所暗示的一样, 我们在寻找最省力的方法, 因此不可避免地会损害软件的质量. 尽管这也可能会是一个危险, 但这肯定不是我们的意思, 也不是我们的目的. 第6章“持续的步骤：测量质量”考虑怎样在开发过程中确保质量. 本书称为《快速开发最佳软件》, 很自然的一个问题是“比什么好？”这一章考虑持续测量质量的技术, 因此可以把任何一次软件构造的质量和其他任何构造进行比较, 由此, 客观地评价它是不是更好. 相比较而言, 很多项目只用功能测试来测量质量, 并且只在项目的后期才去执行测试. 这是一个严重的错误. 我们提出了许多建立构造质量的状况的方法, 包括测试. 自动化度量. 自动化审计. 文档生成和检查.
第7章“微观步骤：设计和实现”是对软件开发中每天工作的阐述. 这一章考虑了获取一个或多个需求并且在当前构造中实现这些功能. 我们也阐述了Together ControlCenter所使用的, 用来设计功能测试. 用户交互. 对象交互. 持久性数据, 以及文档化代码和到需求的链接的技术. 同时也提到了Together的交互开发环境（IDE）的元素, 如它的编辑器. GUI-构造器. 调试器和源码的格式化.
第8章“宏观步骤：体系结构”, 从不同程度和视角考虑系统. 用到了很多不同的软件体系结构的定义, 这些定义由F.P.Brooks首先提出并命名. 对我们来说, 体系结构就是用来分割软件的原则和扩展软件的策略和模式. 尽管, 我们认为体系结构太重要, 不能不单独考虑. 但是, 在小团队中, 体系结构不是一个小组单独的工作, 正因为如此, 有些团队只是简单地让它自我发展. 这一章中阐述了怎样从非功能或者“服务层”需求中导出体系结构的需求. 这一章同时给我们一个机会来考虑使用Together的依赖性分析, 包类图是怎样成为体系结构技术中的一个关键的武器的, 以及构件图和部署图是如何辅助它的.
第9章“J2EE体系结构”, 阐述了基于Sun的J2EE标准的体系结构的细节及Together ControlCenter怎样提供支持. 同时也简要地讨论了我们喜爱的把对象映射到数据库的技术.
最后, 第10章“结束语”从整体上简要回顾了本书, 以及本书的局限性.
通过本书, 无论你已经采用了哪种正式的过程（或者没有）, 我们将向你展示怎样使用Together的大部分功能. 例如, 我们将探究如何使用Together开放的API来开发模块, 以使开发和文档管理更加容易. Together开放的API是一个可扩展的基于Java的API, 组成了Together的综合的插件程序的体系结构. 希望这能鼓励你去使用Together ControlCenter这个强大而灵活的工具. 毕竟, Together是一个开发平台而不是一个开发工具. 当团队发现, 他们需要特定的工具. 模式. 审计及集成的时候, 显而易见的方法是采用开放API.
以上就是本书的内容. 我们热衷于Together, 并且希望它能够被广泛使用. 如果看完了本书并已使用了这个软件后, 你同样热衷于它的话, 我们将感到十分高兴. 如果这本书让你从不同的角度来考虑怎样以效率和质量为中心的方法构造软件, 那么本书的目的也就达到了.
◣ Together的版本
本书所参考的Together的版本是Together ControlCenter版本6. 在一些案例中, 使用了以前发布的版本, 因此, 功能或者用户界面可能会与你正在使用的版本有所不同. 每个Together ControlCenter的版本都说明了用户界面的改进和提高, 所以我们避免对它的界面导航做太过详细的说明, 以免这些说明在这一产品将来的版本中变得过旧.
第二书店&China-pub战略联盟提供专业服务
第二书店联系方式 010-64348411 webmaster@dearbook.com