MyException - 我的异常网
当前位置:我的异常网» 软件架构设计 » 一线架构师实践指南(1)

一线架构师实践指南(1)

www.MyException.Cn  网友分享于:2013-09-10  浏览:3次
一线架构师实践指南(一)

绪论

       从本质上,架构设计是需求驱动的,而不是模型驱动的。但当很清楚需求却依然设计不出架构时,就说明“需求驱动的架构设计”的总结还“缺点什么”。架构设计是一门艺术,不可能把“一桶需求”倒进某台神奇的机器,然后等着架构设计自己被“加工生成”完毕,因此“需求驱动的架构设计”的总结给架构师的启发不够。那缺点儿什么呢?答案是“人的因素”、“架构师的因素”。

       质疑意识,是架构师最宝贵的意识之一。通过“质疑”引入更多的“质量属性”,以及“特殊功能场景”来驱动后续架构设计工作的开展。

       架构设计方法的阶段:

       阶段1:把握需求特点,确定架构确定力

       阶段2:根据重大需求,确定概念架构

       阶段3:细化架构设计,关注不同视图

       先做后做——叫做阶段,齐头并进——叫做视图。任何好的方法(不限于软件领域),都必须以时间轴来组织,因为这样才最利于指导实践。

       3个阶段,1个贯穿

       Pre-architecture阶段(PA阶段):最大误区:架构师是技术人员不必懂需求。

       Conceptual Architecture 阶段(CA阶段):最大误区:概念架构=理想设计。

       Refined Architecture 阶段(RA阶段):最大误区:架构=模块+接口

       对非功能目标的考虑贯穿整个架构设计阶段。

子系统划分的4大原则:

l   职责分离原则

l   通用专用分离原则

l   技能分离原则

l   工作量均衡原则

 

Pre-architecture阶段

       作为架构师,首先要面对的风险就是需求。既要关注功能需求,又要平衡相互矛盾的质量属性需求,还不能遗漏各方的约束性需求。架构师不仅要考虑支持功能、满足质量要求,还要重视各种约束性需求。

        相互矛盾的质量属性:高性能和灵活扩展这两个质量属性之间存在矛盾关系,性能和安全性,与其他许多质量属性都是矛盾的。

在架构设计之初,就全盘考虑架构设计要重点支持的关键质量目标。在第一时间就判断这些“关键质量”之间有没有冲突关系,并制定权衡取舍策略。

架构师不必是需求捕获专家,也不必是编写《软件需求规格说明书》的专家;但他一定应在需求分类、需求折中和需求变更的研究方面是专家。

架构设计对系统成败非常关键。功能需求、质量属性及约束共同决定了架构,对这3类需求的把握是否到位、设计决策是否对路,是架构设计成败的关键所在。

四步法:

1、          需求结构化

2、          分析约束影响

3、          确定关键质量

4、          确定关键功能

 

Pre-architecture就是架构设计的最前期阶段,其工作目标包括:理解需求、建立需求大局观、确定架构设计方向等。该阶段虽然是铺垫性质的阶段,但对架构实际而言意义重大。

       重大需求塑造概念架构。如果对需求的理解缺乏大局观,那将如何识别重大需求、特色需求、高风险需求?Pre-architecture阶段能够帮助架构师建立理解需求的大局观。任何需求都可定位于业务级需求、用户级需求、开发级需求这3个需求层次的某一层,同时也必属于功能、质量、约束这3类需求的某一类。

       对需求理解不透、遗漏需求往往是架构设计失败的重要原因。

尽早开始架构设计

l   让架构师参与需求分析工作,让架构师相对自由地“全程”参与需求分析工作。

l   不能被动地等待完善的《软件需求规格说明书》出现的那一刻才开始架构设计。满足下列3个条件就可以尽早开始架构设计工作:

1、          有了明确的业务需求

2、          了解全面的用户需求

3、          有了典型的行为需求

 

明确架构设计的“驱动力”

l   分析业务需求和约束背后的衍生需求

l   发现遗漏需求

l   确定关键功能

l   确定关键质量

l   权衡质量属性之间的矛盾关系

 

架构设计的目标必然随领域不同、规模不同、条件不同而变化。为重用、简单、可扩展都加了“最”(而不是权衡折中),不符合架构设计的实现、更何况“灵活”和“简单”之间常常存在矛盾。

任何一项功能都是由一条特定的“职责协作链”完成的。作为完整的软件系统,它在支持每一个具体功能时,都必然涉及软件不同“部分”之间的相互配合。质量是完善架构设计的驱动力,不考虑质量的系统是无法走出实验室的。至于约束,则有不同的具体方式影响着架构设计。把多而杂的架构影响因素梳理清楚、建立全面有序的理解。分别针对约束、质量、功能这3类需求开展相应工作。分析约束影响,识别隐含需求;确定关键质量,明确关键质量之间的优先级;确定关键功能,便于更有针对性地分配有限的架构设计时间。

 

需求结构化

       有经验的架构师懂得运用需求的结构。他们能够将复杂的需求集合梳理得井井有条,为进一步分析不同需求之间的联系(作为权衡折中的依据)、识别遗漏的重要需求打下坚实基础。Pre-architecture 阶段要求进行需求结构化。全面理解需求的各个层次、各个方面,更为分析需求之间关系、识别遗漏需求、发现延伸需求奠定基础。绝不能认为《软件需求规格说明书》就是需求的全部。首先,需求文档常常不够全面,所有有经验的架构师都重视需求文档,但不应该“唯需求文档是瞻”。其次,需求变更经常发生,“依赖且仅依赖需求文档”不够聪明,使架构设计工作非常被动。所以,架构师要通过需求结构化真正全面地“鸟瞰”需求大局,就必须超越《软件需求规格说明书》。还有一个重大的意义在于,只有摆脱对《软件需求规格说明书》提交时间、文档质量、内容变更的“呆板依赖”,才有可能尽早开始架构设计。

       需求是分层次的。业务级需求:包含客户或出资者要达到的业务目标、预期投资、工期要求,以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。用户级需求:用户使用系统来辅助完成哪些工作?对质量有何要求?用户群及所处的使用环境方面有何特殊要求?开发级需求:开发人员需要实现什么?开发期间、维护期间有何质量考虑?开发团队的哪些情况会反过来影响架构?需求的三个层次,是站在“不同层次的涉众提出需求所站的立场不同”的角度,将需求划分为三种类型。其次,需求还必须从不同方面进行考虑。实践一再表明,忽视质量属性和约束性需求,常常导致架构设计最终失败。于是,从“需求定义了直接目标还是间接限制”的角度,把需求划分为3种类型,这就是需求的3个方面:

       功能需求:更多体现各级直接目标要求。

       质量属性:运行期质量+开发期质量。

       约束需求:业务环境因素+使用环境因素+构建环境因素+技术环境因素。

       一句话,需求是有结构的。而且,需求的结构绝对不是“List”,而应该是“二维数组”。结构化是控制复杂性的好办法。进行需求结构化之后,复杂性得到了控制。

 

为什么必须分析约束影响

       风险有一个恼人的特点:一旦你忘记了它,它就会找上门来制造麻烦。对于架构设计而言,来自方方面面的约束性需求中潜藏了大量风险因素。Pre-architecture阶段明确要求必须分析约束影响。分析约束影响的要义:尽早识别风险。业务环境、使用环境、构建环境应分别考虑客户、用户、开发方这3类涉众,而技术环境则和3类涉众都有关。

第一,来自客户或出资方的约束性需求。架构师必须充分考虑客户对上线时间的要求、预算限制,以及集成需要等非功能需求。

第二,来自用户的约束性需求。软件提供给何阶层用户?用户的年龄段?使用偏好?用户是否遍及多个国家?使用期间的环境有电磁干扰、车船移动等因素吗?

第三,来自开发人员和升级维护人员的约束性需求。如果开发团队的技术水平有限、磨合程度不高、分布在不同城市,会有何影响?开发管理方面、源代码保密方面,是否须要顾及?

第四,也不能遗忘,业界当前技术环境本身也是约束性需求。技术平台、中间件、编程语言等的流行度、认同度、有缺点等。技术发展的趋势如何?

架构是应当直接或间接地了解和掌握上述需求和约束,并深刻理解它们对架构的影响,只有这样才能设计出合适的软件架构。

       约束是架构设计的上下文。没有全局观念就不可能成为架构师,“约束是架构设计要解决的问题的上下文”是一个犀利的理解,揭示了“软件需求=功能需求+质量属性+约束”背后更深层次的规律。从本质上讲,分析约束影响就是分析各个需求项之间的关系,并发现被遗漏的需求。

 

确定关键质量

       如何确定关键质量呢?遵守和运用5 大原则:

n   分类合适+必要扩充。

n   考虑多方涉众。

n   检查性思维。

n   识别矛盾+划定优先级。

n   严格程度符合领域与规模特点。

质量的分类方式是基础,架构师对质量毫无研究绝对不行。任何时候,只要关键属性多于一个,都要考虑它们之间是否有矛盾关系,在第一时间做出权衡取舍,确定不同的优先级。

       持续可用性包括了可靠性。若是分布式系统,安全性差会随时造成系统瘫痪,持续可用性将大受影响,所以持续可用性也包括安全性高的隐含要求。可维护性和可管理性也深刻影响着持续可用性。性能=速度+吞吐量+持续高速性。效率=CPU、内存、硬盘和网络的利用率。

       为什么会遗漏重要的质量属性呢?因为架构师没有全面考虑多方涉众的利益。用户在使用软件系统的过程中,其关心的质量属性可能包括易用性、性能、可伸缩性、持续可用性、鲁棒性等。架构师也应为开发人员而设计。软件的可扩展性、可重用性、可移植性、易理解性、易测试性等也类似,它们都深刻影响着开发人员的工作,使开发更顺畅,抑或更艰难。

       检查性思维这条原则颇为简单。这是一种意识,意识到“在架构设计之初”像“过一遍Checklist”一样,看看每一项质量属性是否确实算不上“关键质量”,从而防止遗漏关键需求。

       架构师应确定关键质量的优先级,并在《架构文档》中明确记录此要求。

       质量严格程度受到系统所处领域及系统规模的影响。首先,不同领域对软件系统的质量要求不同。其次,规模不同,对同一领域的软件而言,产品的要求常常也比项目高,平台的要求常常比产品高。

 

确定关键功能的4条规则

1.       核心功能

2.       必做功能

3.       高风险功能

4.       独特功能

识别“核心功能”的标志是业务层的接口要放映这些功能。

关键功能子集”的确定并不存在“标准答案”。只要较好地覆盖组成架构的不同职责模块,并体现职责模块之间协作关系的特点,那么“关键功能子集”的价值也就体现了。

1楼FansUnion1小时前
很强大。读了1遍,理解很模糊。

文章评论

每天工作4小时的程序员
每天工作4小时的程序员
一个程序员的时间管理
一个程序员的时间管理
老美怎么看待阿里赴美上市
老美怎么看待阿里赴美上市
“肮脏的”IT工作排行榜
“肮脏的”IT工作排行榜
 程序员的样子
程序员的样子
程序员都该阅读的书
程序员都该阅读的书
什么才是优秀的用户界面设计
什么才是优秀的用户界面设计
那些争议最大的编程观点
那些争议最大的编程观点
如何成为一名黑客
如何成为一名黑客
写给自己也写给你 自己到底该何去何从
写给自己也写给你 自己到底该何去何从
10个调试和排错的小建议
10个调试和排错的小建议
中美印日四国程序员比较
中美印日四国程序员比较
Java程序员必看电影
Java程序员必看电影
程序员的一天:一寸光阴一寸金
程序员的一天:一寸光阴一寸金
程序员眼里IE浏览器是什么样的
程序员眼里IE浏览器是什么样的
程序猿的崛起——Growth Hacker
程序猿的崛起——Growth Hacker
聊聊HTTPS和SSL/TLS协议
聊聊HTTPS和SSL/TLS协议
旅行,写作,编程
旅行,写作,编程
总结2014中国互联网十大段子
总结2014中国互联网十大段子
程序员的鄙视链
程序员的鄙视链
程序员应该关注的一些事儿
程序员应该关注的一些事儿
我的丈夫是个程序员
我的丈夫是个程序员
程序员和编码员之间的区别
程序员和编码员之间的区别
团队中“技术大拿”并非越多越好
团队中“技术大拿”并非越多越好
Web开发者需具备的8个好习惯
Web开发者需具备的8个好习惯
做程序猿的老婆应该注意的一些事情
做程序猿的老婆应该注意的一些事情
我跳槽是因为他们的显示器更大
我跳槽是因为他们的显示器更大
代码女神横空出世
代码女神横空出世
60个开发者不容错过的免费资源库
60个开发者不容错过的免费资源库
要嫁就嫁程序猿—钱多话少死的早
要嫁就嫁程序猿—钱多话少死的早
初级 vs 高级开发者 哪个性价比更高?
初级 vs 高级开发者 哪个性价比更高?
10个帮程序员减压放松的网站
10个帮程序员减压放松的网站
Web开发人员为什么越来越懒了?
Web开发人员为什么越来越懒了?
我是如何打败拖延症的
我是如何打败拖延症的
Java 与 .NET 的平台发展之争
Java 与 .NET 的平台发展之争
科技史上最臭名昭著的13大罪犯
科技史上最臭名昭著的13大罪犯
程序员最害怕的5件事 你中招了吗?
程序员最害怕的5件事 你中招了吗?
“懒”出效率是程序员的美德
“懒”出效率是程序员的美德
程序员周末都喜欢做什么?
程序员周末都喜欢做什么?
5款最佳正则表达式编辑调试器
5款最佳正则表达式编辑调试器
为啥Android手机总会越用越慢?
为啥Android手机总会越用越慢?
亲爱的项目经理,我恨你
亲爱的项目经理,我恨你
为什么程序员都是夜猫子
为什么程序员都是夜猫子
当下全球最炙手可热的八位少年创业者
当下全球最炙手可热的八位少年创业者
编程语言是女人
编程语言是女人
软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有