系统架构设计师复习精华_系统架构师复习资源-CSDN文库

系统架构设计师

架构师

2星需积分: 9 191 浏览量 2011-09-08 12:05:10 上传评论 1 收藏 157KB DOC 举报

资源推荐

资源详情

资源评论

系统架构:系统架构师是怎样炼成的

坦率的讲，除了少数对开发程序极其热爱并愿意为之奋斗终身的编程者来说，对于大多数开发人员，写代码

只是他们未来获得职业提升的一个必不可少的积累阶段，在做开发的时间里，他们会积极学习各种知识，经验，

培养自己的商业头脑，包括扩展自己各方面的资源，这些积累会为他们未来成为管理者或创业打下牢固的基础。

　　成为架构设计师是广大开发者职业发展道路之一，架构师究竟是个什么样的职业？需要具备什么基本能力？

如何才能成为一个优秀的架构设计师以及架构设计师需要关注哪些内容？针对有关问题，本期我们为您采访了(微

软认证专家，系统分析员，希赛顾问团顾问，中国计算机学会会员) 张友邦，他会就相关问题与大家分享他的看法。

　　“在我工作的六年多时间里，除了第一年是纯粹编码以外，其余时间都在做和架构设计有关的工作，当然也还

一直在写各种各样的代码。”张友邦认为架构设计可能看起来很神秘，新入门或没有架构设计经验的程序员刚开始

的时候会有种不知所措的感觉，但其实架构设计是件很容易的事，它只是软件系统开发中的一个环节而已，整个

软件系统的开发和维护以及变更还涉及到很多事情，包括技术、团队、沟通、市场、环境等等。

　　同时，张友邦表示，虽然架构设计是件容易的事情，但也不是大多数没有架构设计经验的程序员想象中的画

画框图那么简单。把几台服务器一摆，每一台服务器运行什么软件分配好，然后用网络连接起来，似乎每个企业

级应用都是如此简间单单的几步。但现实生活中的软件系统实实在在可以用复杂大系统来形容，从规划、开发、

维护和变更涉及到许许多多的人和事。架构设计就是要在规划阶段都把后面的事情尽量把握进来，要为稳定性努

力，还要为可维护性、扩扩展性以及诸多的性能指标而思前想后。除了技术上的考虑，还要考虑人的因素，包括

人员的组织、软件过程的组织、团队的协作和沟通等。

　　另外，架构设计还需要方法论的指导。张友邦强调，这些方法论的思路包括，至上而下的分析，关注点分离，

横向/纵向模块划分等。有时候觉得架构设计决策就像是浏览 Google Earth，实际上反映的是一种自上而下的决策

过程。对问题的分解是软件思维的基本素质，可以有横向分解、纵向分解以及两者的结合。能不能有效快速准确

的分解问题，是软件开发人员需要首先训练的项目。另外，架构设计中图形化的工具非常有用，它能把系统的结

构和运作机制以图形化的方式表达出来。也正因为这样才有了架构设计就是画框图的误会。再者，架构设计是一

个工程性质的工作，对当事人的实际从业经验要求较高。只有对市场上的各种技术有较全面的了解之后才有可能

设计出一个尽可能满足各种设计约束的架构。

　　在谈到架构师需要具备的能力上，张友邦认为架构师首先必须具有丰富的开发经验，是个技术主管。因为他

必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等

一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中

的问题并提出相应的改进(重构)方案(也就是通常说的反模式)。这些都需要长期的开发实践才能真正的体会到，单

从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。

　　在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信(对象

访问、函数调用、数据交换、线程同步等)以及进程外(包括跨计算机)的通信(如 RMI、DCOM、Web Service)。在

WEB 应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨

机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图;而进程内的通信是模块实现的骨架，它是基石的

基石。如果具体到一个基于.Net 企业级架构设计，首先需要的是语言级别的认识，包括.NET 的 CLR、继承特性、委

托和事件处理等。然后是常用解决方案的认识，包括 ASP.NET Web Service、.NET Remo$ng、企业服务组件等。总之，

丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。

　　其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥

抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。有经验的设计人员可能

都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留

下来的系统接口没能在需求变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后

还是不得不为变化的业务重新设计系统。这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实

用的、可以为架构扩展性服务的水平。

　　再次，张友邦提到，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人

员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶

水。大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没

有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。另外，对人

的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度

等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。

　　另外，张友邦认为架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发

语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开

发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。解决方案提供商永远都希望你能

使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。比

如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用

可以将许多业务逻辑用 script 的方式放入数据库中，但很少看到大型应用采用这样的做法。对于新东西需要以一种

比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新

入行的开发人员往往关心新技术动向而忽略了技术的历史，而从 DOS 时代一路杀过来的开发者就对现在的技术体

系有较全面的把握。

　　构架师不是通过理论学习可以搞出来的，不学习并且亲自实践相关知识肯定是不行的。就像前面说到的，架

构设计是一个工程性质的事情，只有在不断实践的基础上才能逐渐熟悉起来。实践的内容并不是去深挖各种语言

的特性，因为系统架构师是设计应用系统架构而不是设计语言(除非你是要实现 DSL)。更多的时候需要带着一种比

较的眼光去实践，把不同的实现方式下的优缺点做个总结，做到自己心里有数，等具体的上下文环境下才好判断

采用什么样的方式方法。把基础打牢的同时掌握一定的方法，架构设计不是想象中的那么难。

　　张友邦，男，微软认证专家，系统分析员，希赛顾问团顾问，中国计算机学会会员。1980 年生于四川宜宾，

2002 年获得国防科技大学宇航科学与工程系空间工程专业学士学位，2004 年初成立长沙石斑软件有限公司并担任

总经理，2006 年底出任广州快网信息技术有限公司技术总监，2007 年 10 月任湖南新邮信息技术有限公司软件中

心副经理。主要研究领域包括软件架构与设计、WEB RIA、流媒体与计算机图形图像。受国家自然科学基金资助，

于 2001 年发表国家级核心刊物学术论文一篇。

系统架构:小议软件架构设计要点

2009 年上半年计算机技术与软件专业技术资格（水平）考试日期：2009 年 5 月 23、24 日。另外，部分考试科

目从 2009 年上半年开始将采用新修编的考试大纲，具体见：

　　如何更好地进行软件架构设计，这是软件工程领域中一个永恒的重点话题。过去几十年来，国际软件工

程界在软件架构设计方面已经获得了长足发展，大量图书、文章和文献记载了这方面的成熟经验与成果。软件架

构设计往往是一件非常复杂的工作，涉及到很多细节和方方面面，可探讨的话题也非常之多。囿于篇幅限制，以

下只能根据笔者个人理解，遴选出软件架构设计的个别要点，结合当前流行的敏捷软件工程思想，与大家分享一

下自己在软件架构设计方面的心得和体会。

　　架构决定成败

　　软件架构是软件产品、软件系统设计当中的主体结构和主要矛盾。任何软件都有架构，哪怕一段短小的

HelloWorld 程序。软件架构设计的成败决定了软件产品和系统研发的成败。软件架构自身所具有的属性和特点，决

定了软件架构设计的复杂性和难度。

　　这几年流行一个说法（管理谚语）：“细节决定成败”，这句话其实只说对了一半。细节确实很重要，很多项目、

产品就输在细节的执行上。一方面，战术细节固然很重要，但另一方面，战略全局也同样重要，对应的我们可以

说：“战略决定成败”。战略性失败，就好比下一盘围棋，局部下得再漂亮、再凌厉，如果罔顾大盘，己方连空都不

够了，还有官子（细节）获胜的机会吗？必然是中盘告负。

　　类似地，正确的软件架构设计，应该既包括战略全局上的设计，也包括战术细节（关键路径）上的设计。有

一种错误的观点认为，软件架构设计只要分分层和包，画一个大体的轮廓草图，就完事了。这种“纸上谈兵”型的架

构师行为是非常有害的。事实上，既然软件架构是软件建筑的主体结构、隐蔽工程、承重墙和要害部位，那么软

件架构也必然要落实到实际的算法和代码，不但要有实现代码，还要包括对这部分架构进行测试的代码，以保证

获得高质量的、满足各种功能和非功能质量属性要求的架构。除了完成概念、模型设计外，软件架构师一定要参

与实际的编码、测试和调试，做一位真正的 hands-on prac$$oner，这已经成为了敏捷软件工程所倡导的主流文化。

　　两个架构

　　我们在日常的软件产品和系统开发中，实际上会遇到两种、两个部分的软件架构，即待开发的应用部分的软

件架构（简称“应用架构”），以及既有的基础平台部分的软件架构（简称“基础架构”）。这两部分架构之间是互为

依赖、相辅相成的关系，它们共同组成了整个软件产品和系统的架构。

　　基础架构的例子包括：.NET 和 J2EE 等主流的基础平台和各种公共应用框架，由基础库 API、对象模型、事件模

型、各种开发和应用的扩展规则等内容组成。我们只有熟悉基础架构的构造细节、应用机理，才能有效地开发出

高质量、高性能的上层应用。然而，开发一个面向最终用户的软件应用系统和产品，仅仅掌握一般的计算机高级

编程语言知识和基础平台架构、API 的使用知识显然是不够的，我们还需要根据客户应用的类型和特点，在基础架

构之上，设计出符合用户要求的高质量应用软件。

　　熟悉 OOA、OOD 抽象建模技术、设计原则以及架构模式和设计模式等等方法技术，不但有助于我们更好地理

解和利用基础平台架构，也有助于我们设计开发出更高质量的应用软件架构。

　　风险驱动、敏捷迭代的架构设计与开发

　　软件架构将随着软件产品和系统的生命周期而演化，其生命期往往超过了一个项目、一次发布，甚至有可能

长达数年之久，因而软件架构无论对于客户还是开发商来说都是一项极其重要的资产。

　　软件架构的设计应该遵循什么样的开发过程？或者说，有没有更好的、成熟的软件架构设计和开发过程？回

答是，21 世纪的软件架构设计应该优先采用敏捷迭代的开发方式和方法。与传统做法不同，敏捷迭代开发主张软

件架构采用演进式设计（evolu$onary design），一个软件产品或系统的架构是通过多次迭代，乃至多次发布，在

开发生命周期中逐步建立和完善起来的。

　　好的软件架构不是一蹴而就的。在架构设计开发过程中，我们应该尽量避免瀑布式思维，通过一个“架构设计

阶段”来完成系统的架构设计乃至详细设计，然后再根据架构图纸和模型，在“编码实现阶段”按图索骥进行架构的

编码与实现。这种传统做法的错误在于认为软件架构就是图纸上的模型，而不是真正可以高质量执行的源代码。

几十年的软件工程实践表明，没有经过代码实现、测试、用户确认过的架构设计，往往会存在着不可靠的臆想、

猜测和过度设计、过度工程，极易造成浪费和返工，导致较高的失败率。

　　风险是任何可能阻碍和导致软件产品/系统研发失败的潜在因素和问题。软件架构是软件产品和系统研发的主

要矛盾和主要技术风险，软件架构的质量决定了整个软件系统和产品的质量。不确定性往往是软件架构设计当中

一种最大的潜在风险。因此，软件架构的设计与开发应该遵循风险驱动的原则，在整个开发生命周期内至始至终

维护一张风险问题清单，随着迭代的前进，根据风险的实时动态变化，首先化解和处理最主要的架构风险，再依

次化解和处理次要的架构风险。

　　架构设计的可视化建模

　　软件架构设计的难度源于软件设计问题本身的复杂性，一个复杂的软件系统往往存在大量复杂的、难于被人

类所理解的细节和不确定因素。抽象与建模是人类自诞生以来就已掌握的理解复杂事物的方法，因而人类所从事

的软件设计工作本质上也是一个不断建模的过程。我们可以通过各种抽象的模型和视图，从各个不同层次、宏观

和微观的角度来理解复杂的软件架构，以保证作出正确和有效的设计。

　　有人认为：“软件架构就是源代码（source codes）”以及“源代码就是设计”。这种说法其实是片面的。什么是真

正的软件？我们知道，最终可以在电脑上执行的真正的软件其实是二进制代码 0 和 1，借助编译器我们把高级编程

语言翻译成底层的汇编语言、机器语言等，没有人能直接、完整地看到二进制程序在 CPU 上的实际运行状况

（run$me），人们大多只能通过各种调试工具、窗口视图等方式来间接地动态观察这些真正的软件的运行片段。

因此，Java、C#、C++ 等等设计时（design $me）源代码在本质上也是一种模型，虽然是一种经处理后可执行的静

态模型，但显然它们并不是真实软件和软件架构的全部。可见，源代码模型（有时也叫实现模型）与 UML 模型其

实都是软件架构的一种模型（逻辑反映），差别就在于抽象层次的不同。完整的软件架构（建筑）不仅仅包括源

代码（实现模型），还包括了需求模型、分析模型、设计模型、实现模型和测试模型等等许多模型，软件架构本

身就是一组模型的集合。

　　UML、SysML 是当前国际上流行的软件/系统架构可视化建模语言。在编写实际的代码之前，利用包图、类图、

活动图、交互图、状态图等等各种标准图形符号对软件架构进行建模，探讨和交流各种可行的设计方案，发现潜

在的设计问题，保证具体编码实现之前抽象设计的正确性，被实践证明是一种非常有效和高效、敏捷的工作方式。

　　架构设计的重用

　　重用（Reuse）是在软件工程实践中获得高效率、高质量产品和系统开发的一种基本手段和主要途径，通过有

组织的、系统和有效的重用，我们往往可以获得 10 倍率以上的效率提升。而一个优秀的、有长久生命力的软件架

构（比方主流的一些框架软件），其本身或其组件被重用的次数越多，其体现的价值也就越大。

　　软件重用有各种不同的范围、层次、粒度和类型，从函数重用、类重用、构件/组件重用、库（API）重用，到

框架重用、架构重用、模式重用，再到软件设计知识、思想的重用等等，重用的效能和效果各有不同。

　　软件工程经过几十年的发展，已经积累了大量的软件架构模式和设计模式，它们记载、蕴藏了大量成熟、已

经验证的软件设计知识、思想和经验。我们平时对各种基础平台、主流框架和 API 的应用和调用，本身就是一种最

为普遍的重用形式。而一个优秀、成熟的软件研发组织，必然会在日常开发中注意收集各种软件设计知识和经验，

建立和维护基于架构模式和设计模式等内容的软件重用知识库，积极主动和频繁地运用各种软件模式来解决实际

工程问题。

　　框架（Framework）是一类具有高可重用度的软件，针对某一类应用或领域，它们具有非常灵活的、高度可扩

展的软件架构。那么，如何才能设计出可重用的软件架构或其组件？借助于 OOA、OOD 等抽象分析和设计技术是

一种重要的方法。人们在实践中发现，往往越抽象的东西，其适应面也就越广，可重用度也就越高；相反，越具

体的东西，其适应面也就越窄，可重用度也就越低。重用，意味着充分利用现成、既有的东西、成果来解决新问

题或重复的问题，以“不变”应“ 万变”。在软件架构设计中，应该主动地区分软件架构中的“不变”与“可变”之处，系

统地管理好这些稳定点和变化点以适应未来的变化，这也是提高软件架构重用度、获得高质量框架设计的一种重

要方法。

　　架构设计的权衡

　　与其它所有工程行业一样，软件工程本质上也是一门讲究权衡的科学和艺术。软件架构设计的最难之处往往

剩余25页未读，继续阅读

评论收藏

内容反馈

jolsnow

2014-10-27

我觉得不好，写的东西别人看不懂，应该多加点说明什么的。毕竟分享的东西要给别人看明白。
cczdp

2012-07-04

学习心得，还好，但是还要学习其他书籍。

zgmws2007

粉丝: 2
资源: 25

系统架构设计师复习精华

系统架构师复习笔记

系统架构师复习资料_如何备考

系统架构设计师 复习精华

系统架构设计师复习笔记

系统架构设计师(高级)复习精华

系统架构设计师(高级)复习精华【绝对精品】.doc

系统架构设计师(高级)复习精华[绝对精品].doc

软考中级软件设计师历年真题

2018-2022年软考中级软件设计师真题汇总（PDF）

A4横线稿纸模板(可直接打印).doc

2023软考软件设计师全套资料（教材+大纲+真题解析+笔记+考试经验）看完一个月必过！！！

系统架构设计师教程第二版

软考 2024系统规划与管理师考试官方教材

STK基础教程以及编程基础

2021年下半年软件设计师下午真题及答案解析.pdf

计算机二级office题库（免费版）

计算机专业基础知识点pdf

2023信息系统项目管理师软考高级职称（第四版高项）多套视频教程

信息系统项目管理师考试32小时通关

系统架构设计师考试全程指导.pdf

2014-2020年软考网络工程师历年真题合集.zip

2021年下半年系统架构设计师下午真题及答案解析.pdf

2016-2020年信息系统项目管理师(高项)历年真题.zip

软考系统分析师思维导图及论文资料

软考高级系统架构师论文范文50篇（带目录）.pdf

2020年下半年信息安全工程师上午真题及答案解析.pdf

系统集成项目管理工程师教程（第2版）目录完整版.pdf.zip

最新资源

系统架构设计师复习精华