系统架构设计师高级复习精华绝对精品.docx
- 文档编号:7447738
- 上传时间:2023-01-24
- 格式:DOCX
- 页数:30
- 大小:166.76KB
系统架构设计师高级复习精华绝对精品.docx
《系统架构设计师高级复习精华绝对精品.docx》由会员分享,可在线阅读,更多相关《系统架构设计师高级复习精华绝对精品.docx(30页珍藏版)》请在冰豆网上搜索。
系统架构设计师高级复习精华绝对精品
2017系统架构:
系统架构师是怎样炼成的
坦率的讲,除了少数对开发程序极其热爱并愿意为之奋斗终身的编程者来说,对于大多数开发人员,写代码只是他们未来获得职业提升的一个必不可少的积累阶段,在做开发的时间里,他们会积极学习各种知识,经验,培养自己的商业头脑,包括扩展自己各方面的资源,这些积累会为他们未来成为管理者或创业打下牢固的基础。
成为架构设计师是广大开发者职业发展道路之一,架构师究竟是个什么样的职业?
需要具备什么基本能力?
如何才能成为一个优秀的架构设计师以及架构设计师需要关注哪些容?
针对有关问题,本期我们为您采访了(微软认证专家,系统分析员,希赛顾问团顾问,中国计算机学会会员)友邦,他会就相关问题与大家分享他的看法。
“在我工作的六年多时间里,除了第一年是纯粹编码以外,其余时间都在做和架构设计有关的工作,当然也还一直在写各种各样的代码。
”友邦认为架构设计可能看起来很神秘,新入门或没有架构设计经验的程序员刚开始的时候会有种不知所措的感觉,但其实架构设计是件很容易的事,它只是软件系统开发中的一个环节而已,整个软件系统的开发和维护以及变更还涉及到很多事情,包括技术、团队、沟通、市场、环境等等。
同时,友邦表示,虽然架构设计是件容易的事情,但也不是大多数没有架构设计经验的程序员想象中的画画框图那么简单。
把几台服务器一摆,每一台服务器运行什么软件分配好,然后用网络连接起来,似乎每个企业级应用都是如此简间单单的几步。
但现实生活中的软件系统实实在在可以用复杂大系统来形容,从规划、开发、维护和变更涉及到许许多多的人和事。
架构设计就是要在规划阶段都把后面的事情尽量把握进来,要为稳定性努力,还要为可维护性、扩扩展性以及诸多的性能指标而思前想后。
除了技术上的考虑,还要考虑人的因素,包括人员的组织、软件过程的组织、团队的协作和沟通等。
另外,架构设计还需要方法论的指导。
友邦强调,这些方法论的思路包括,至上而下的分析,关注点分离,横向/纵向模块划分等。
有时候觉得架构设计决策就像是浏览GoogleEarth,实际上反映的是一种自上而下的决策过程。
对问题的分解是软件思维的基本素质,可以有横向分解、纵向分解以及两者的结合。
能不能有效快速准确的分解问题,是软件开发人员需要首先训练的项目。
另外,架构设计中图形化的工具非常有用,它能把系统的结构和运作机制以图形化的方式表达出来。
也正因为这样才有了架构设计就是画框图的误会。
再者,架构设计是一个工程性质的工作,对当事人的实际从业经验要求较高。
只有对市场上的各种技术有较全面的了解之后才有可能设计出一个尽可能满足各种设计约束的架构。
在谈到架构师需要具备的能力上,友邦认为架构师首先必须具有丰富的开发经验,是个技术主管。
因为他必须清楚什么是可以实现的,实现的方式有哪些,相应的难度怎么样,实现出来的系统面对需求变化的适应性等一系列指标。
另外,需要对面向过程、面向对象、面向服务等设计理念有深刻的理解,可以快速的察觉出实现中的问题并提出相应的改进(重构)
方案(也就是通常说的反模式)。
这些都需要长期的开发实践才能真正的体会到,单从书本
上很难领会到,就算当时理解了也不一定能融会到实践中去。
在技术能力上,软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识,包括进程通信(对象访问、函数调用、数据交换、线程同步等)以及进程外(包括跨计算机)的通信(如RM、DCOMWebService)。
在WEB应用大行其道的今天,开发者往往对服务器间的通信关注的比较多,而对进程的通信较少关注。
进程外跨机器通信是构建分布式应用的基石,它是架构设计中的鸟瞰视图;而进程的通信是模块实现的骨架,它是基石的基石。
如果具体到一个基于.Net企业级架构设计,首先需要的是语言级别的认识,包括.NET的CLR、
继承特性、委托和事件处理等。
然后是常用解决方案的认识,包括ASP.NETWebService、.NETRemoting、企业服务组件等。
总之,丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去,给代码编写人员带来实实在在的可行性。
其次,具有足够的行业业务知识和商业头脑也是很重要的。
行业业务知识的足够把握可以给架构师更多的拥抱变化的能力,可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。
有经验的设计人员可能都碰到过这样的事,一厢情愿的保留接口在需求变
化中的命中率非常低。
也就是说,在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用,因为需求的变化并没有按照预想的方向进行,到最后还是不得不为变化的业务重新设计系统。
这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。
再次,友邦提到,架构设计师对人的关注必须提升到架构设计之初来纳入考虑的围,包
括沟通以及对人员素质的判断。
软件过程是团队协作共同构建系统的过程,沟通能力是将整个过程中多条开发线粘合在一起的胶水。
大家都应该碰到过事后说“原来是这样啊,我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。
沟通的目的就是尽量避免多条开发线的混乱,让系统构建过程可以有条理的高效进行。
另外,对人的关注还表现在对团队成员的素质判断上,比如哪些开发人员对哪些技术更熟悉,或者哪些开发人员容易拖进度等。
只有合理的使用人力资源,让合适的人做合适的事情才能让整个软件过程更加高效。
另外,友邦认为架构师应时刻注意新软件设计和开发方面的发展情况,并不断探索更有
效的新方法、开发语言、设计模式和开发平台不断很快地升级,软件架构师需要吸收这些新技术新知识,并将它们用于软件系统开发工作中。
但对新技术的探索应该在一个理性的围进行,不能盲目的跟风。
解决方案提供商永远都希望你能使用它提供的最新技术,而且它们在
推广自己的解决方案的时候往往是以自己的产品为中心,容易给人错觉。
比如数据库,往往
让人觉得它什么都能做,只要有了它其它什么都不重要了。
但事实上并不是如此,对于小型应用可以将许多业务逻辑用script的方式放入数据库中,但很少看到大型应用采用这样的做法。
对于新东西需要以一种比较的观点来判断,包括横向的比较和纵向的比较,最后得出一些性能、可移植性以及可升级等指标。
另外,新入行的开发人员往往关心新技术动向而忽略了技术的历史,而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把
握。
构架师不是通过理论学习可以搞出来的,不学习并且亲自实践相关知识肯定是不行的。
就像前面说到的,架构设计是一个工程性质的事情,只有在不断实践的基础上才能逐渐熟悉起来。
实践的容并不是去深挖各种语言的特性,因为系统架构师是设计应用系统架构而不是设计语言(除非你是要实现DSL)。
更多的时候需要带着一种比较的眼光去实践,把不同的实现方式下的优缺点做个总结,做到自己心里有数,等具体的上下文环境下才好判断采用什么样的方式方法。
把基础打牢的同时掌握一定的方法,架构设计不是想象中的那么难。
友邦,男,微软认证专家,系统分析员,希赛顾问团顾问,中国计算机学会会员。
1980
年生于,2002年获得国防科技大学宇航科学与工程系空间工程专业学士学位,2004年初成立石斑软件并担任总经理,2006年底出任快网信息技术技术总监,2007年10月任新邮信息技术软件中心副经理。
主要研究领域包括软件架构与设计、WEBRIA、流媒体与计算机图形
图像。
受国家自然科学基金资助,于2001年发表国家级核心刊物学术论文一篇。
系统架构:
小议软件架构设计要点
2009年上半年计算机技术与软件专业技术资格(水平)考试日期:
2009年5月23、24日。
另外,部分考试科目从2009年上半年开始将采用新修编的考试大纲,具体见:
如何更好地进行软件架构设计,这是软件工程领域中一个永恒的重点话题。
过去几十年来,国际软件工程界在软件架构设计方面已经获得了长足发展,大量图书、文章和文献记载
了这方面的成熟经验与成果。
软件架构设计往往是一件非常复杂的工作,涉及到很多细节和方方面面,可探讨的话题也非常之多。
囿于篇幅限制,以下只能根据笔者个人理解,遴选出软件架构设计的个别要点,结合当前流行的敏捷软件工程思想,与大家分享一下自己在软件架构设计方面的心得和体会。
架构决定成败
软件架构是软件产品、软件系统设计当中的主体结构和主要矛盾。
任何软件都有架构,哪怕一段短小的HelloWorld程序。
软件架构设计的成败决定了软件产品和系统研发的成败。
软件架构自身所具有的属性和特点,决定了软件架构设计的复杂性和难度。
这几年流行一个说法(管理谚语):
“细节决定成败”,这句话其实只说对了一半。
细节确实很重要,很多项目、产品就输在细节的执行上。
一方面,战术细节固然很重要,但另一方面,战略全局也同样重要,对应的我们可以说:
“战略决定成败”。
战略性失败,就好比下一盘围棋,局部下得再漂亮、再凌厉,如果罔顾大盘,己方连空都不够了,还有官子(细节)获胜的机会吗?
必然是中盘告负。
类似地,正确的软件架构设计,应该既包括战略全局上的设计,也包括战术细节(关键路径)上的设计。
有一种错误的观点认为,软件架构设计只要分分层和包,画一个大体的轮
廓草图,就完事了。
这种“纸上谈兵”型的架构师行为是非常有害的。
事实上,既然软件架构是软件建筑的主体结构、隐蔽工程、承重墙和要害部位,那么软件架构也必然要落实到实际的算法和代码,不但要有实现代码,还要包括对这部分架构进行测试的代码,以保证获得高质量的、满足各种功能和非功能质量属性要求的架构。
除了完成概念、模型设计外,软件架构师一定要参与实际的编码、测试和调试,做一位真正的hands-onpractitioner,这已
经成为了敏捷软件工程所倡导的主流文化。
两个架构
我们在日常的软件产品和系统开发中,实际上会遇到两种、两个部分的软件架构,即待开发的应用部分的软件架构(简称“应用架构”),以及既有的基础平台部分的软件架构(简称“基础架构”)。
这两部分架构之间是互为依赖、相辅相成的关系,它们共同组成了整个软件产品和系统的架构。
基础架构的例子包括:
.NET和J2EE等主流的基础平台和各种公共应用框架,由基础库
API、对象模型、事件模型、各种开发和应用的扩展规则等容组成。
我们只有熟悉基础架构的构造细节、应用机理,才能有效地开发出高质量、高性能的上层应用。
然而,开发一个面向最终用户的软件应用系统和产品,仅仅掌握一般的计算机高级编程语言知识和基础平台架构、API的使用知识显然是不够的,我们还需要根据客户应用的类型和特点,在基础架构之上,设计出符合用户要求的高质量应用软件。
熟悉OOA00D抽象建模技术、设计原则以及架构模式和设计模式等等方法技术,不但有助于我们更好地理解和利用基础平台架构,也有助于我们设计开发出更高质量的应用软件架构。
风险驱动、敏捷迭代的架构设计与开发软件架构将随着软件产品和系统的生命周期而演化,其生命期往往超过了一个项目、一次发布,甚至有可能长达数年之久,因而软件架构无论对于客户还是开发商来说都是一项极其重要的资产。
软件架构的设计应该遵循什么样的开发过程?
或者说,有没有更好的、成熟的软件架构设计和开发过程?
回答是,21世纪的软件架构设计应该优先采用敏捷迭代的开发方式和方法。
与传统做法不同,敏捷迭代开发主软件架构采用演进式设计(evolutionarydesign),一个软件产品或系统的架构是通过多次迭代,乃至多次发布,在开发生命周期中逐步建立和完善起来的。
好的软件架构不是一蹴而就的。
在架构设计开发过程中,我们应该尽量避免瀑布式思维,通过一个“架构设计阶段”来完成系统的架构设计乃至详细设计,然后再根据架构图纸
和模型,在“编码实现阶段”按图索骥进行架构的编码与实现。
这种传统做法的错误在于认为软件架构就是图纸上的模型,而不是真正可以高质量执行的源代码。
几十年的软件工程实
践表明,没有经过代码实现、测试、用户确认过的架构设计,往往会存在着不可靠的臆想、猜测和过度设计、过度工程,极易造成浪费和返工,导致较高的失败率。
风险是任何可能阻碍和导致软件产品/系统研发失败的潜在因素和问题。
软件架构是软件产品和系统研发的主要矛盾和主要技术风险,软件架构的质量决定了整个软件系统和产品的质量。
不确定性往往是软件架构设计当中一种最大的潜在风险。
因此,软件架构的设计
与开发应该遵循风险驱动的原则,在整个开发生命周期至始至终维护一风险问题清单,随着迭代的前进,根据风险的实时动态变化,首先化解和处理最主要的架构风险,再依次化解和处理次要的架构风险。
架构设计的可视化建模
软件架构设计的难度源于软件设计问题本身的复杂性,一个复杂的软件系统往往存在大量复杂的、难于被人类所理解的细节和不确定因素。
抽象与建模是人类自诞生以来就已掌握的理解复杂事物的方法,因而人类所从事的软件设计工作本质上也是一个不断建模的过程。
我们可以通过各种抽象的模型和视图,从各个不同层次、宏观和微观的角度来理解复杂的软件架构,以保证作出正确和有效的设计。
有人认为:
“软件架构就是源代码(sourcecodes)”以及“源代码就是设计”。
这种说法其实是片面的。
什么是真正的软件?
我们知道,最终可以在电脑上执行的真正的软件其实是二进制代码0和1,借助编译器我们把高级编程语言翻译成底层的汇编语言、机器语言等,没有人能直接、完整地看到二进制程序在CPU上的实际运行状况(runtime),人们
大多只能通过各种调试工具、窗口视图等方式来间接地动态观察这些真正的软件的运行片段。
因此,Java、C#、C++等等设计时(designtime)源代码在本质上也是一种模型,虽然是一种经处理后可执行的静态模型,但显然它们并不是真实软件和软件架构的全部。
可见,源代码模型(有时也叫实现模型)与UML莫型其实都是软件架构的一种模型(逻辑反映),
差别就在于抽象层次的不同。
完整的软件架构(建筑)不仅仅包括源代码(实现模型),还包括了需求模型、分析模型、设计模型、实现模型和测试模型等等许多模型,软件架构本身就是一组模型的集合。
UMLSysML是当前国际上流行的软件/系统架构可视化建模语言。
在编写实际的代码之前,利用包图、类图、活动图、交互图、状态图等等各种标准图形符号对软件架构进行建模,探讨和交流各种可行的设计方案,发现潜在的设计问题,保证具体编码实现之前抽象设计的正确性,被实践证明是一种非常有效和高效、敏捷的工作方式。
架构设计的重用
重用(Reuse)是在软件工程实践中获得高效率、高质量产品和系统开发的一种基本手段和主要途径,通过有组织的、系统和有效的重用,我们往往可以获得10倍率以上的效
率提升。
而一个优秀的、有长久生命力的软件架构(比方主流的一些框架软件),其本身或其组件被重用的次数越多,其体现的价值也就越大。
软件重用有各种不同的围、层次、粒度和类型,从函数重用、类重用、构件/组件重用、
库(API)重用,至U框架重用、架构重用、模式重用,再到软件设计知识、思想的重用等等,重用的效能和效果各有不同。
软件工程经过几十年的发展,已经积累了大量的软件架构模式和设计模式,它们记载、蕴藏了大量成熟、已经验证的软件设计知识、思想和经验。
我们平时对各种基础平台、主流框架和API的应用和调用,本身就是一种最为普遍的重用形式。
而一个优秀、成熟的软件研发组织,必然会在日常开发中注意收集各种软件设计知识和经验,建立和维护基于架构模式
和设计模式等容的软件重用知识库,积极主动和频繁地运用各种软件模式来解决实际工程问题。
系统架构设计师:
hibernate配置
24.2hibernate配置
Hibernate同时支持xml格式的配置文件,以及传统的properties文件配置方式,一般我们采用xml型配置文件。
xml配置文件提供了更易读的结构和更强的配置能力,可以
直接对映射文件加以配置.
24.3Hibernate的使用问题24.3.1标示
符l)Increment2)Identity3)Sequence4)Assign
5)Hilo
24.3.2注意的问题
l)
3)Outer-join
Lazy2)Inverse
4)大数据量删除更新
24.4技术经理和高级程序员如何利用Spring整合
hibernate
l)SessionFactory
2}HibernateDaoSupport3)HibernateTemplate
系统架构设计师:
处理图像
处理图像如果您的应用程序显示大量图像文件(例如,.jpg和.gif文件),则您可以通过以位图格式预先呈现图像来显著改善显示性能。
要使用该技术,请首先从文件中加载图像,然后使用PARGB格式将其呈现为位图。
下面的代码示例从磁盘中加载文件,然后使用该
类将图像呈现为预乘的、Alpha混合RGB格式。
例如:
[C#]
系统架构设计师:
管理可用资源
管理可用资源公共语言运行库(CLR)使用垃圾回收器来管理对象生存期和存使用。
这意味着无法再访问的对象将被垃圾回收器自动回收,并且自动回收存。
由于多种原因无法再访问对象。
例如,可能没有对该对象的任何引用,或者对该对象的所有引用可能来自其他可作为当前回收周期的一部分进行回收的对象。
尽管自动垃圾回收使您的代码不必负责管理对象删除,但这意味着您的代码不再对对象的确切删除时间具有显式控制。
请考虑下列原则,以确保您能够有效地管理可用资源:
1)确保在被调用方对象提供Dispose方法时该方法得到调用。
如果您的代码调用了支持Dispose方法的对象,则您应该确保在使用完该对象之后立即调用此方法。
调用Dispose方法可以确保抢先释放非托管资源,而不是等到发生垃圾回收。
除了提供Dispose方法以外,某些对象还提供其他管理资源的方法,例如,Close方法。
在这些情况下,您应该参考文档资料以了解如何使用其他方法。
例如,对于SqlConnection对象而言,调用Close或Dispose都足可以抢先将数据库连接释放回连接池中。
一种可以确保您在对象使用完毕之后立即调用Dispose的方法是使用VisualC#.NET中的using语句或VisualBasic.NET中的Try/Finally块。
下面的代码片段演示了Dispose的用法。
C#中的using语句示例:
using(StreamReadermyFile=newStreamReader("C:
\\ReadMe.Txt")){
stringcontents=myFile.ReadToEnd();//...usethecontentsof
thefile
}//disposeiscalledandtheStreamReader'
sresourcesreleased
VisualBasic.NET
中的Try/Finally块示
例:
DimmyFile
AsStreamReader
myFile
=NewStreamReader("C:
\\ReadMe.Txt")
Try
String
contents
=myFile.ReadToEnd()
'...usethecontents
of
thefileFinallymyFile.Close()
EndTry
注:
在C#和
C++中,Finalize
方法是作为析构函数实现的。
在
Visual
Basic.NET中,
Finalize
方法
是作为Object基
类
上
的
Finalize
子例程的重写实现的。
2)如果
您在客户端调
用过程
中占据
非托管资源,则
请
提
供
Finalize
和Dispose方法。
如果您在公共或受保护的方法调用中创建访问非托管
资源的对象,则应用程序需要控制非托管资源的生存期。
在图8.1中,第一种情况是对非托管资源的调用,在此将打开、获取和关闭资源。
在此情况下,您的对象无须提供Finalize和Dispose方法。
在第二种情况下,在方法调用过程中占据非托管资源;因此,您的对象应该提供Finalize和Dispose方法,以便客户端在使用完该对象后可以立即显式释放资源。
系统架构设计师:
规
8.2.5规您可以使用许多工具和技术来帮助您对应用程序进行规,并且生成度量应用程序性能所需的信息。
这些工具和技术包括:
1)EventTracingforWindows(ETW)。
该ETW子系统提供了一种系统开销较低(与性能日志和警报相比)的手段,用以监控具有负载的系统的性能。
这主要用于必须频
繁记录事件、错误、警告或审核的服务器应用程序。
2)EnterpriseInstrumentationFramework(EIF)°EIF是一种可扩展且可配置的
框架,您可以使用它来对智能客户端应用程序进行规划。
它提供了一种可扩展的事件架构和统一的API-它使用Windows中置的现有事件、日志记录和跟踪机制,包括WindowsManagementInstrumentation(WMI)、
WindowsEventLog和WindowsEventTracing。
它大大简化了发布应用程序事件所需的编码。
如果您计划使用EIF,则需要通过使用EIF.msi在客户计算机上安
装EIF。
如果您要在智能客户端应用程序中使用EIF,则需要在决定应用程序的部署方式
时考虑这一要求。
3)WindowsManagementInstrumentation(WMI)。
WMI组件是Windows操作系
统的一部分,并且提供了用于访问企业中的管理信息和控件的编程接口。
系统管理员常用它
来自动完成管理任务(通过使用调用WMI组件的脚本)。
4)调试和跟踪类。
.NETFramework在System.Diagnosis下提供了Debug和Trace类来对代码进行规。
Debug类主要用于打印调试信息以及检查是否有断言。
Trace类使您可以对发布版本进行规,以便在运行时监控应用程序的完好状况。
在VisualStudio.NET中,默认情况下启用跟踪。
在使用命令行版
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 架构 设计师 高级 复习 精华 绝对 精品