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

标签: 架构师 | 发表时间:2013-09-08 22:19 | 作者:shenzhen_liubin
分享到:
出处:http://blog.csdn.net

绪论

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

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

       架构设计方法的阶段:

       阶段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.       独特功能

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

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

作者:shenzhen_liubin 发表于2013-9-8 22:19:09 原文链接
阅读:95 评论:0 查看评论

相关 [架构师] 推荐:

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从“架构师书单”讲开去

- 黄立 - aimingoo的专栏
琉璃要我推荐一下给工程师们的各阶段的书单,这件事被我压在手边好些天了已经. 然后呢就看见了公司内网中孙坚的一份推荐. 其实那份书单的一些信息也是有出处的(或者说有类似介绍的地方),是江南白衣的另一份架构师书单,目前已经“翻新”到2009年版和第3版了:. 看来白衣兄的确是要把这份书单做到穷极. 但事实上我在看到他的最初版的书单时,就提出过反对意见:.

迷你书: 架构师(8月刊)

- 去北方-Jack - InfoQ中文站
InfoQ中文站的电子杂志《架构师》(2011年8月刊)出炉了. 本期的主编是InfoQ中文站总编辑霍泰稳. 本期《架构师》月刊专题为云计算的安全风险. 安全风险”作为云计算中重要的一环,一直备受关注,本期的专题我们和IEEE合作就这一话题进行深入讨论,并借助一个调查看看当前已经实施云计算的企业是如何看待云计算和安全的.

软件架构师的沟通修炼

- - 博客 - 伯乐在线
在架构师的角色中,沟通是要求有效果的必备技能与工具. 换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段. 架构师通常没有对为其项目工作的他人的直接管理权. 他们的项目往往是跨部门的,也可能会跨好多个行业单位. 由于不能直接管理他人,所以架构师指示别人或群体完成特定行动的能力就受到限制.

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

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

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

- - CSDN博客架构设计推荐文章
Conceptual Architecture阶段.        有经验的架构师不会一上来就关注如何定义“接口”,他们在大型系统架构设计的早期比较注重识别重大需求、特色需求、高风险需求,据此来设计概念架构. 概念架构是对系统设计最初构想,就是把最关键的设计要素和交互机制确定下来,然后考虑具体技术的运用,设计出实际架构.

系统架构师笔记(二)

- - CSDN博客Web前端推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 七、架构权衡分析法:ATTM(Architecture Tradeoff Analysis Method). 评价软件架构的一种综合全面的方法. 这种方法不仅可以揭示出构架满足特定质量目标的情况,而且(因为它认识到了构架决策会影响多个质量属性)可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标.

系统架构师笔记(一)

- - CSDN博客架构设计推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 1、性能:系统的响应能力,即要经过多长时间才能对某个事件作出响应或者在某段时间内系统所能处理事件的个数. 架构设计策略:增加计算资源、改善资源需求(减少计算复杂度等)、资源管理(并发、数据复制等)和资源调度(先进先出队列、优先级队列等).

软件架构师的职责

- - 研发管理 - ITeye博客
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调.     在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可. 架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求.