我
第
篇文章描述是什么是软件Software架构 第 2篇文章 讲述软件Software架构师这个角色特征
第 3部分是建立在以前讨论基础的上而且所考虑主题或者特征都是在软件Software架构过程这个框架下 软件Software架构活动:定义及范围根据IEEE标准
软件Software架构活动代表了这样
系列活动:定义、记录、维持、改进个软件Software构架并确保其正确执行软件Software架构
范围相当宽泛图1展示模型详细地介绍说明了软件Software架构过程各个方面这个模型来自IEEE标准1471架构师所关注软件Software架构各个方面都可以此模型作为参考
图1:软件Software架构相关术语
模型 图1中阴影框里
元素直接来自于IEEE标准1471它们的间相互关系阐明是个系统及其构架诸多特征:个系统有个构架 个系统完成项任务 个系统存于个环境中并受这个环境影响 个系统有个或多个涉众 个构架对应条构架描述 条构架描述识别个或多个涉众 条构架描述识别条或多条关联 条构架描述提供理由 个涉众有条或多条关联条关联对个或多个涉众都很重要图1中另外那些不是来自IEEE标准1471
元素和相互关系显示在非阴影框中可描述如下:个团队(Team)组负责个开发项目 个开发项目遵循个开发流程 个开发项目交付给个系统 开发流程包括软件Software架构
项目组里包含
个架构师 架构师负责软件Software架构
架构师是涉众中
种 架构最终得出
个软件Software构架 架构师创造出软件Software构架
软件Software架构是
门科学 虽然软件Software构架是
门新生事物但它已被公认为门学科而随的而来是将重点放在使软件Software架构过程日趋成熟技术、思路方法和资源上推进这趋势思路方法的就是利用现有知识体系概括地说就是架构师们在开发个新构架时寻求已经通过检验解决方案而不是重蹈覆辙将以往软件Software构架、构架设计模型以及其他些可再度使用元素中可以借鉴经验汇集成册尽管如此
软件Software架构过程要想在任何地方都和土木工程架构过程样成熟仍有段路要走这种成熟可以体现在很多层面上包括标准运用对最佳实行方案、技术以及思路方法理解上因此基于这点个架构师经验对于个项目成功有很大影响软件Software架构是
门艺术尽管软件Software架构被认为是
门科学但有些时候具备定创造力是十分必要在处理些从未见过奇特系统时这点就尤为重要在这种情况下可能没有成形经验可以借鉴就如同个画家在面对张空白画板时需要灵感样架构师们有时会视他们工作为门艺术而不是门科学当然在很大程度上软件Software架构艺术层面是很小即使是面对个极为新奇系统通常做法也是借鉴别处解决办法处理的后使其适应用这个系统随着软件Software架构过程日渐成为主流
它极有可能不再被认为是只有“被挑出极少数人”可以理解系列神秘实战行为而是系列被广泛接受、建立在科学基础的上、定义明确并通过检验实战行为软件Software架构跨越很多学科
在软件Software开发过程中架构师需要涉及许多学科
架构师涉及最多学科是软件Software设计尽管如此架构师也很关注其他些学科例如在需求分析里架构师要确保对于利害关系需求条件尤为了解同时也懂得区分这些需求优先次序架构师参和实现工作他们详细地介绍说明用来组织源代码以及可执行工作产品实现结构架构师们还参和测试工作确保架构结构具有可测性并能通过测试架构师负责开发环境中些特定元素特别是建立些特定指针架构师们还帮助制定配置管理策略
配置管理结构(用来支持版本管理)经常影响已经定义好软件Software架构架构师和项目管理(project management)人紧密合作正如这个文章系列中第 2部分所提到架构师已经成为项目计划中员当谈及软件Software架构
范围时我需要提到架构和设计关系尽管架构师尤为重视设计学但并非所有设计都可以认为是软件Software架构个架构只是关注那些十分重要元素而并不是所有设计元素都对架构有重要意义例如用户界面屏幕详细设计通常认为对架构没有任何意义最好是留给用户界面设计者来完成这种思路同样应用于其他系统元素例如那些支持业务逻辑或数据逻辑元素架构师只在必要时加以限制而许多设计方面决策都是留给设计者们来完成架构是时刻进行
行为经验表明
软件Software架构并不是在项目初期蹴而就事情而是贯穿整个项目始终在整个项目里通过交付给可执行软件Software系列迭代递增
软件Software架构也日趋成熟在每次交付过程中软件Software构架都会变得更加稳定完善这就很好地解释了什么是架构师贯穿项目始终重点成功
软件Software架构行为是以结果为导向因此架构师重点会因预期结果随时间变化而变化这点如图2所示图2由Bran Selic绘制
图2:随时间变化
工程重点 图2表明
在工程早期架构师着眼于发现重点是理解系统所涉及范围并识别其主要特征及所有相关风险——所有要素对软件Software构架都有显著影响然后重点转向创造主要是开发个可以为整个实现过程提供牢固基础稳定构架最终重点放在了实现上面这个时候大部分发现和创造开始起作用应该注意到
发现、创造和实现并不是严格按顺序来例如随着架构模型建立在项目早期会有些实现过程而随着过程深入理解和实现架构中某些元素区别策略提出在项目后期将会有些发现请记住
直到系统交付架构过程才被完成因此架构师必须直关注软件Software构架直至项目结束旦个项目软件Software构架稳定下来人们总是希望架构师离开这个项目将这珍贵资源用于其他项目然而直到项目后期仍有些架构方面决策需要制定实际上还有介于两者的间情况旦影响软件Software架构重大决策制定出来架构师就成为项目组中名兼职人员不管怎样架构师不应该完全脱离这个项目当然还有种更加灵活情况那就是由个团队(Team)来履行架构师这个角色这个团队(Team)里些成员可能去参予其他项目而另外些则留下来继续确保这个系统架构完整性软件Software架构受涉众所驱动
正如在早期
章节里所描述个构架满足许多涉众需求因此架构过程必须适应所有这些涉众以确保他们关系——特别是那些极有可能对软件Software构架产生影响——能够被了解被阐明能够得到协调及有效处理也有必要将相关涉众融入到对这些关系处理每次复审的中在架构过程中不应低估适应所有涉众所付出
努力涉众影响着架构过程许多方面包括集中需求条件方式构架文档记录样式以及构架评估思路方法软件Software架构经常需要做出折衷
假定给出影响软件Software构架
诸多原因很显然软件Software架构过程需要做出折衷通常情况是在需求中做出权衡同时也要考虑涉众来帮助做出正确折衷个折衷例子就是性能价格比:添加更多问题处理能力会增加性能但是要以成本为代价这可能代表个需求冲突假设架构师已经努力地找到所有可解决方案这就是个要由有需求冲突涉众来解决问题另
种折衷体现在解决方案上:例如用种技术代替另种技术或是用第 3方部分代替另方或者甚至用组模式来取代另外组作出折衷无法避免也不应避免构架师项工作就是考虑可选择方案并在它们的间作出折衷软件Software架构受益于过去
经验架构师们很少“白手起家”
正如前面提到他们积极地寻找已经汇集成册经验包括架构模式、设计模式以及已经成形部分等等换句话说架构师努力获取那些可再度利用资源只有那些最无知架构师才放弃考虑过去经验当问题重复发生时
可重复使用资源就是解决方案；可重复使用资源就是种在重复使用时已经在脑海中得到提炼资源 3个软件Software构架中元素可以在当前系统前后关系里再度使用和此同时个架构师可能也已经将其构架或者其中些元素作为可再度使用资源用于当前系统的外软件Software架构既是自上而下也是自下而上
许多软件Software构架是按照自上而下方式来设计
:1)在定义构架的前掌握涉众需求并加以研究；2)设计架构元素；3)实现这些元素尽管如此个软件Software构架很少完全按照这个自上而下方式进行架构普遍情况是采取相反方式从已经创造出来实现软件Software中汲取教训比如说概念论证在某种程度上软件Software构架按照自下而上方式是由于指定设计或实现方案约束在这种情况下这些元素是给定软件Software构架必须适应它们例如约束可能是设计将在现在系统上使用关系数据库或者接口成功
架构师们承认架构思路方法是必要并且他们软件Software架构是按照自上而下和自下而上两种方式创建这可以被认为是“中间”架构解决思路方法结束语
这篇文章重点介绍说明
是软件Software构造过程主要特征下个月文章是软件Software架构系列文章最后篇其重点放在将软件Software构架作为IT基础资源益处上致谢
这篇文章
内容来源于本即将出版新书暂时叫做“软件Software架构建立过程”最后我衷心感谢对内容提出宝贵意见人们他们是Grady BoochDave BrainesAlan BrownMark DicksonHolger HeussKelli HoustonLuan Doan-MinhPhilippe KruchtenNick RozanskiDave Williams和Eoin Woods注解
1IEEE Computer Society
强软件Software系统架构描述IEEE推荐实战:IEEE 标准 147200020002 Bran告诉我
他为Philippe Kruchten将这张图画在了餐巾纸上3 取自“Reusable As
Spec
ication” 对象管理组织文档号 04-06-062004年 6月
最新评论