系统架构设计师复习资料

1、另外，架构设计还需要方法论的指导。张友系统架构师是怎样炼成的坦率的讲，除了少数对开发程序极其热爱并 愿意为之奋斗终身的编程者来说，对于大多数开 发人员，写代码只是他们未来获得职业提升的一 个必不可少的积累阶段，在做开发的时间里，他 们会积极学习各种知识，经验，培养自己的商业 头脑，包括扩展自己各方面的资源，这些积累会 为他们未来成为管理者或创业打下牢固的基础。成为架构设计师是广大开发者职业发展道路 之一，架构师究竟是个什么样的职业？需要具备 什么基本能力？如何才能成为一个优秀的架构设 计师以及架构设计师需要关注哪些内容？针对有 关问题，本期我们为您采访了（微软认证专家，系 统分析员，希赛顾问团顾问，中国计算机学会会 员） 张友邦，他会就相关问题与大家分享他的看 法。矚慫润厲钐瘗睞枥庑赖。“在我工作的六年多时间里，除了第一年是纯 粹编码以外，其余时间都在做和架构设计有关的 工作，当然也还一直在写各种各样的代码。”张友 邦认为架构设计可能看起来很神秘，新入门或没 有架构设计经验的程序员刚开始的时候会有种不 知所措的感觉，但其实架构设计是件很容易的 事，它只是软件系统开发中的一个环节而已，整

2、 个软件系统的开发和维护以及变更还涉及到很多 事情，包括技术、团队、沟通、市场、环境等同时，张友邦表示，虽然架构设计是件容易 的事情，但也不是大多数没有架构设计经验的程 序员想象中的画画框图那么简单。把几台服务器 一摆，每一台服务器运行什么软件分配好，然后 用网络连接起来，似乎每个企业级应用都是如此 简间单单的几步。但现实生活中的软件系统实实 在在可以用复杂大系统来形容，从规划、开发、 维护和变更涉及到许许多多的人和事。架构设计 就是要在规划阶段都把后面的事情尽量把握进 来，要为稳定性努力，还要为可维护性、扩扩展 性以及诸多的性能指标而思前想后。除了技术上 的考虑，还要考虑人的因素，包括人员的组织、 软件过程的组织、团队的协作和沟通等。 残骛楼 邦强调，这些方法论的思路包括，至上而下的分 析，关注点分离，横向/纵向模块划分等。有时候 觉得架构设计决策就像是浏览 Google Earth ，实际 上反映的是一种自上而下的决策过程。对问题的 分解是软件思维的基本素质，可以有横向分解、 纵向分解以及两者的结合。能不能有效快速准确 的分解问题，是软件开发人员需要首先训练的工 程。另外，架构设计

3、中图形化的工具非常有用， 它能把系统的结构和运作机制以图形化的方式表 达出来。也正因为这样才有了架构设计就是画框 图的误会。再者，架构设计是一个工程性质的工 作，对当事人的实际从业经验要求较高。只有对 市场上的各种技术有较全面的了解之后才有可能 设计出一个尽可能满足各种设计约束的架构。酽锕在谈到架构师需要具备的能力上，张友邦认 为架构师首先必须具有丰富的开发经验，是个技 术主管。因为他必须清楚什么是可以实现的，实 现的方式有哪些，相应的难度怎么样，实现出来 的系统面对需求变化的适应性等一系列指标。另 外，需要对面向过程、面向对象、面向服务等设 计理念有深刻的理解，可以快速的察觉出实现中 的问题并提出相应的改进 （重构）方案（也就是通常 说的反模式）。这些都需要长期的开发实践才能真 正的体会到，单从书本上很难领会到，就算当时 理解了也不一定能融会到实践中去。彈贸摄尔霁毙攬在技术能力上，软件架构师最重要也是最需 要掌握的知识是构件通信机制方面的知识，包括 进程内通信（对象访问、函数调用、数据交换、线 程同步等）以及进程外（包括跨计算机 ）的通信（如 RMI、DCOM、Web Service

4、）。在 WEB 应用大行 其道的今天，开发者往往对服务器间的通信关注 的比较多，而对进程内的通信较少关注。进程外 跨机器通信是构建分布式应用的基石，它是架构 设计中的鸟瞰视图。而进程内的通信是模块实现 的骨架，它是基石的基石。如果具体到一个基 于.Net企业级架构设计，首先需要的是语言级别 的认识，包括.NET的CLR、继承特性、委托和事 件处理等。然后是常用解决方案的认识，包括 ASP.NET Web Service、.NET Remoting、企业服务 组件等。总之，丰富的开发实践经验有助于避免 架构师纸上谈兵式的高来高去，给代码编写人员 带来实实在在的可行性。謀荞抟箧飆鐸怼类蒋薔。其次，具有足够的行业业务知识和商业头脑 也是很重要的。行业业务知识的足够把握可以给 架构师更多的拥抱变化的能力，可以在系统设计 的时候留出一些扩展的余地来适应可能来临的需 求变化。有经验的设计人员可能都碰到过这样的 事，一厢情愿的保留接口在需求变化中的命中率 非常低。也就是说，在系统设计之初为扩展性留 下来的系统接口没能在需求变化的洪流中发挥真 正的作用，因为需求的变化并没有按照预想的方 向进行，到最后

5、还是不得不为变化的业务重新设 计系统。这就是因为对业务知识的理解和对市场 或者商业的判断没有达到一个实用的、可以为架 构扩展性服务的水平。厦礴恳蹒骈時盡继價骚。再次，张友邦提到，架构设计师对人的关注 必须提升到架构设计之初来纳入考虑的范围，包 括沟通以及对人员素质的判断。软件过程是团队 协作共同构建系统的过程，沟通能力是将整个过 程中多条开发线粘合在一起的胶水。大家都应该 碰到过事后说“原来是这样啊，我不知道啊 ”或者 某个开发人员突然高声呼喊“为什么这里的数据没 有了”之类的。沟通的目的就是尽量避免多条开发 线的混乱，让系统构建过程可以有条理的高效进 行。另外，对人的关注还表现在对团队成员的素 质判断上，比如哪些开发人员对哪些技术更熟 悉，或者哪些开发人员容易拖进度等。只有合理 的使用人力资源，让合适的人做合适的事情才能 让整个软件过程更加高效。茕桢广鳓鯡选块网羈泪。另外，张友邦认为架构师应时刻注意新软件 设计和开发方面的发展情况，并不断探索更有效 的新方法、开发语言、设计模式和开发平台不断 很快地升级，软件架构师需要吸收这些新技术新 知识，并将它们用于软件系统开发工作中。但对 新技

6、术的探索应该在一个理性的范围内进行，不 能盲目的跟风。解决方案提供商永远都希望你能 使用它提供的最新技术，而且它们在推广自己的 解决方案的时候往往是以自己的产品为中心，容 易给人错觉。比如数据库，往往让人觉得它什么 都能做，只要有了它其它什么都不重要了。但事 实上并不是如此，对于小型应用可以将许多业务 逻辑用script的方式放入数据库中，但很少看到大 型应用采用这样的做法。对于新东西需要以一种 比较的观点来判断，包括横向的比较和纵向的比 较，最后得出一些性能、可移植性以及可升级等 指标。另外，新入行的开发人员往往关心新技术 动向而忽略了技术的历史，而从DOS时代一路杀 过来的开发者就对现在的技术体系有较全面的把 握。鹅娅尽損鹌惨歷茏鴛賴。构架师不是通过理论学习可以搞出来的，不 学习并且亲自实践相关知识肯定是不行的。就像 前面说到的，架构设计是一个工程性质的事情， 只有在不断实践的基础上才能逐渐熟悉起来。实 践的内容并不是去深挖各种语言的特性，因为系 统架构师是设计应用系统架构而不是设计语言 （除 非你是要实现DSL）。更多的时候需要带着一种比 较的眼光去实践，把不同的实现方式下的优缺

7、点 做个总结，做到自己心里有数，等具体的上下文 环境下才好判断采用什么样的方式方法。把基础 打牢的同时掌握一定的方法，架构设计不是想象 中的那么难。籟丛妈羥为贍偾蛏练淨。张友邦，男，微软认证专家，系统分析员， 希赛顾问团顾问，中国计算机学会会员。 1980 年 生于四川宜宾， 2002 年获得国防科技大学宇航科 学与工程系空间工程专业学士学位， 2004 年初成 立长沙石斑软件有限公司并担任总经理， 2006 年 底出任广州快网信息技术有限公司技术总监， 2007年 10月任湖南新邮信息技术有限公司软件中 心副经理。主要研究领域包括软件架构与设计、 WEB RIA、流媒体与计算机图形图像。受国家自 然科学基金资助，于 2001 年发表国家级核心刊物 学术论文一篇。預頌圣鉉儐歲龈讶骅籴。系统架构:小议软件架构设计要点2009 年上半年计算机技术与软件专业技术资 格（水平）考试日期：2009年 5月 23、 24日。另 外，部分考试科目从 2009 年上半年开始将采用新 修编的考试大纲，具体见： 渗釤呛俨匀谔鱉调硯錦。如何更好地进行软件架构设计，这是软 件工程领域中一个永恒的重点话题。过去

8、几十年 来，国际软件工程界在软件架构设计方面已经获 得了长足发展，大量图书、文章和文献记载了这 方面的成熟经验与成果。软件架构设计往往是一 件非常复杂的工作，涉及到很多细节和方方面 面，可探讨的话题也非常之多。囿于篇幅限制， 以下只能根据笔者个人理解，遴选出软件架构设 计的个别要点，结合当前流行的敏捷软件工程思 想，与大家分享一下自己在软件架构设计方面的 心得和体会。铙誅卧泻噦圣骋贶頂廡。架构决定成败软件架构是软件产品、软件系统设计当中的 主体结构和主要矛盾。任何软件都有架构，哪怕 一段短小的 HelloWorld 程序。软件架构设计的成 败决定了软件产品和系统研发的成败。软件架构 自身所具有的属性和特点，决定了软件架构设计 的复杂性和难度。擁締凤袜备訊顎轮烂蔷。这几年流行一个说法（管理谚语）：“细节决 定成败”，这句话其实只说对了一半。细节确实很 重要，很多工程、产品就输在细节的执行上。一 方面，战术细节固然很重要，但另一方面，战略 全局也同样重要，对应的我们可以说：“战略决定 成败”。战略性失败，就好比下一盘围棋，局部下 得再漂亮、再凌厉，如果罔顾大盘，己方连空都 不够了，还有官子

9、（细节）获胜的机会吗？必然 是中盘告负。贓熱俣阃歲匱阊邺镓騷。类似地，正确的软件架构设计，应该既包括 战略全局上的设计，也包括战术细节（关键路 径）上的设计。有一种错误的观点认为，软件架 构设计只要分分层和包，画一个大体的轮廓草 图，就完事了。这种 “纸上谈兵”型的架构师行为 是非常有害的。事实上，既然软件架构是软件建 筑的主体结构、隐蔽工程、承重墙和要害部位， 那么软件架构也必然要落实到实际的算法和代 码，不但要有实现代码，还要包括对这部分架构 进行测试的代码，以保证获得高质量的、满足各 种功能和非功能质量属性要求的架构。除了完成 概念、模型设计外，软件架构师一定要参与实际 的编码、测试和调试，做一位真正的 hands-on practitioner,这已经成为了敏捷软件工程所倡导的 主流文化。坛摶乡囂忏蒌鍥铃氈淚。两个架构我们在日常的软件产品和系统开发中，实际 上会遇到两种、两个部分的软件架构，即待开发 的应用部分的软件架构（简称 “应用架构 ”），以 及既有的基础平台部分的软件架构（简称“基础架 构”）。这两部分架构之间是互为依赖、相辅相成 的关系，它们共同组成了整个软件产品和系统的 架构。蜡變黲癟報伥铉锚鈰赘。基础架构的例子包括：.NET和J2EE等主流 的 基础平台和 各种公共应用框架， 由基础库 API、对象模型、事件模型、各种开发和应用的扩 展规则等内容组成。我们只有熟悉基础架构的构 造细节、应用机理，才能有效地开发出高质量、 高性能的上层应用。然而，开发一个面向最终用 户的软件应用系统和产品，仅仅掌握一般的计算 机高级编程语言知识和基础平台架构、 API 的使 用知识显然是不够的，我们还需要根据客户应用 的类型和特点，在基础架构之上，设计出符合用 户要求的高质量应用软件。買鲷鴯譖昙膚遙闫撷凄。熟悉 OOA、 OOD 抽象建模技术、设计原则 以及架构模式和设计模式等等方法技术，不但有 助于我们更好地理解和利用基础平台架构，也有 助于我们设计开发出更高质量的应用软件架构。风险驱动、 敏捷迭代的 架构设计与开发 软件架构将随着软件产品和系统的生命周期 而演化，其生命期往往超过了一个工程、一次发 布，甚至有可能长达数年之久，因而软件架构无 论对于客户还是开

《系统架构设计师复习资料》由会员工****分享，可在线阅读，更多相关《系统架构设计师复习资料》请在金锄头文库上搜索。