敏捷开发在敏捷开发中采用演进式架构设计.pdfVIP

敏捷开发:在敏捷开发中采用演进式架构设计 疯狂代码 / ĵ http://Programing/Article59992.html 　　在敏捷开发过程中我们还需要对系统架构进行设计吗？事实上Martin Fowler在Is Design Dead?文 中已经给出了答案那就是我们同样不能忽略对系统架构设计和计划性设计(Planned Design)区别我们需要演进 式设计(Evolutionary Design)在敏捷开发生命周期中我们通过每次迭代来丰富和更新我们设计方案以使其最大 限度地符合客户对系统需求这里所指需求包括功能性需求和非功能性需求 　　在Agile Journal 4月刊中IBMs Methods Group敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中架 构设计思路方法他提出了所谓“架构预测(Architectural Envisioning)”思路方法以应对敏捷开发中逐步演进架 构设计过程 　　Scott指出敏捷模型驱动开发(Agile Model Driven DevelopmentAMDD)明确地包括了需求分析和架构建 模这个过程发生在敏捷项目开发第0次迭代中所谓第0次迭代就相当于项目热身活动是项目得以启动基础在此迭 代期间团队(Team)需要充分地理解项目范围甄别可行地技术策略这个阶段所能够收集到信息将有助于你对整个 项目最初粗略估计以制定合适项目计划从而获得启动项目资金和足够支持 　　敏捷模型驱动开发生命周期如下图所示 　　根据图中所示在每次迭代初期制定迭代计划都应该包括建模工作在此期间可以召开建模头脑风暴会议讨论 系统功能特征并研究实现这些特征高层设计策略大多数敏捷团队(Team)都会通过测试驱动开发(TDD)确定需求 和设计细节 　　通过对架构预测可以在项目早期进行些高层次架构建模以助于团队(Team)和关键利益相关人商讨系统采 取技术策略这行为关键目标是识别出架构策略而不是撰写如山般堆积文档从而使得你能够快速完成架构建模其 中窍门就是尽量保持简单开发者不需要对大量细节进行建模而只需要足够即可如果你正在编写用例意味着你只 需要以标注形式列出用例要点就足够好了如果你正在对领域建模可以直接在白板上绘图或者使用CRC卡片你目 在于对信息共享和交流而不是编写细致文档 　　如果采用架构预测方式你需要对哪些内容进行建模呢？Scott在文中指出有如下 4部分内容需要建模 　　1. 技术图表例如UML部署图这些图表有助于开发者预测主要软件Software和硬件组件包括你需要访问旧系 统和数据库系统有可能会和它们进行交互 　　2. 用户交互流程图通过分析用户交互主要页面/外观和报告对系统UI进行架构设计如果在进行架构设计时候 不考虑用户交互界面就可能存在潜在危机那就是你构建系统不是利益相关人所希望看到请记住UI才是最终用户 使用系统 　　3. 领域图在最初架构建模中个重要组成部分是对领域高层建模模型可以非常微小只需要捕获主要业务实体 以及它们的间关系有人可能认为领域模型应该属于需求建模部分而不是架构建模但正如上图所示这两者在第0次 迭代中是并发进行 　　4. 变更情形就是在架构级需求中描述可能技术或业务变更而这些变更需要在未来能够提供支持变更情形要 求你考虑架构扩展能力但并不是过度构建你系统你只是要考虑由于变更所造成影响以确保你构建系统还能够正 常工作 　　架构建模是贯穿于整个项目周期因此这些图表就是在项目结束时形成整体文档基础由于你事先明确架构 是演进因此就不必承担架构设计在项目早期必须“正确无误”压力而只需要在当前形势下保证足够好就可以了 Scott建议使用白板和草稿纸等简便工具勾勒出这些模型版本当然如果团队(Team)成员具有熟练建模窍门技巧 也可以使用专门建模工具这建议足以体现架构设计敏捷性和长篇累牍传统架构设计方式迥然区别 　　对于这样种架构设计方式熟悉传统架构设计方式架构师普遍不以为然Scott对这看法给和了强有力反驳他将 架构设计场景分为 3种类型第种是架构师熟悉系统架构设计所必需技能和经验既然你已经熟悉了这些内容当然 就没有必要作出完整设计了你只需要在白板上体现你架构设计保证团队(Team)每个人都能够按照相同体系架构 进行实现就可以了 　　第 2种场景是架构师对相关窍门技巧和经验完全不知此时仍然只需要作少量建模即可你缺乏足够知识来完 成细致而又全面架构设计反而会了解不够而导致从而增加项目风险并且阻碍了项目进度