软件架构-什么是软件架构

什么是软件架构

软件应用架构是定义结构化解决方案的过程,它满足所有技术和操作需求,也满足通用的质量属性,如性能\安全\可管理。它包含一系列的决定,涉及广泛的方面,每个决定对质量、性能、可维护性和应用程序的成功都有重要的影响。

 

程序或者计算系统的软件架构是系统的结构,它由软件元素、元素的可见属性和它们之间的关系组成。架构关心公开的接口部分,元素的具体实现细节不是架构,至少不是架构主要关心的内容。

 

架构为什么重要

和其它许多复杂的结构一样,软件必须建立在坚实的基础上。没有考虑到关键场景,没有设计好对共性问题的处理,或者没有考虑到关键决定的长期影响,会使你的应用程序处于风险中。现代工具和平台会帮助你简化构建应用程序,但是不能代替你来设计某个具体场景和需求的应用程序。烂的架构会使应用不稳定、不能满足现在和将来的商业需求,也很难部署到生产环境中。

 

系统应该考虑到用户、IT基础设施、商业目标。对于这些方面,你应该列出关键场景、标识重要的质量属性以及关键的满意点和不满意点。如果可能的话,对这些方面设计度量指标。

 

用户,业务和系统目标

必须在用户,业务和系统上做权衡。总的用户体验通常也是业务和系统(IT基础设施)的功能,改变其中任何一个也会影响用户体验。改变用户体验需求,也会影响业务和系统需求。

 

架构关注程序内部的主要元素和组件。数据结构、算法、元素的实现细节是设计需要考虑的。架构和设计也经常会有重叠。

 

当考虑软件架构时考虑如下抽象问题:

l  用户如何使用应用程序?

l  应用如何被部署到生产环境并被管理?

l  应用的重要属性需求是什么,如安全、性能、并发、国际化、配置?

l  应用程序是如何被设计得更加灵活和可维护?

l  现在或者部署之后影响到应用程序的架构趋势?

 

架构的目标

架构通过use cases寻求构建商业需求和技术需求之间的桥梁,然后找到方法来实现这些use cases。架构的目标是标识影响程序架构的需求。架构必须考虑设计决定的总体影响,必须权衡用户、商业、系统。

 

Keep in mind that the architecture should:

l  展示系统的结构,隐藏实现细节

l  领悟所有的用例和场景

l  努力实现不同利益相关者的需求

l  处理功能和质量需求

 

架构蓝图

理解那些影响架构决定的关键力量非常重要,这些力量将影响架构如何做出决定。

考虑如下关键趋势:

l  User empowerment支持user empowerment的设计是灵活的、可配置的,关注于用户体验的。设计程序时,考虑一定程度的用户个性化和选项。允许用户定义如何与你的程序交互,但是也不要过度使用一些不必要的选项和设置。理解关键场景,越简单越好。使得很容易找到信息并且使用你的程序。

l  Market maturity充分利用市场成熟产品,如已经存在的平台和技术。使用模式来解决共性问题。

l  Flexible design灵活设计利用松散耦合来提高重用性和可维护性。插件设计及soa、restful等。

l  Future trends构建架构时,考虑到将来可能影响你设计的趋势。例如,考虑未来富UI和多媒体,增加网络带宽等。

 

架构设计准则

一般来说,设计是会延续的,因为你无法一次性了解到所有东西及未来的趋势。当你了解得越多,以及外面需求的变化,你的架构会不断的演化。在头脑中树立这种意识,架构不是一次完成的。

 

当你创建架构设计时,考虑如下问题:

l  架构的最基本部分是什么,当系统出现问题时,它们是最大的风险

l  最容易改变的部分是什么,哪些设计你可以延迟

l  最关键的假设是什么,如何测试它们

l  什么情况下需要重构你的设计

 

不要设计过头了,也不要做你不能确认的假设,保持开放的态度,接受改变。

 

关键架构准则

l  Build to change instead of building to last.考虑到程序是要随着需求而改变的,设计灵活性以支持这些变化

l  Model to analyze and reduce risk使用设计工具,uml或者其它工具来帮助你捕获需求并作出架构决定,并且分析它们的影响。但是,不要把model扩展为正式的程序,它会压制你迭代和调整设计的能力。

l  Use models and visualizations as a communication and collaborationtool高效的设计交互,对你做决定,即将对设计做出的变化,对好的架构来说非常重要。使用模型、视图等与所有利益相关方进行沟通,分享你的设计,能够对架构带来很大改善。

l  Identity key engineering decisions标识错误最可能发生的区域。如果在第一次就把这些标识清楚,设计将会更加灵活,也会很少因为变化而崩溃。

 

考虑使用增量和迭代来改善你的架构。测试你的架构时考虑如下方面:

l  当前架构你做出了哪些假设

l  架构满足的显式及隐性的需求

l  关键风险点

l  如何减轻关键风险

l  在基线或者最新架构方案的基础上,架构如何演进

 

 

参考:http://msdn.microsoft.com/en-us/library/ee658098.aspx

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值