软件架构专题：http://www.51cmm.com/zt/architecture/index.htm
嘉宾简介：

　　温昱，架构设计师，技术咨询顾问，松耦合空间网站创办人，希赛顾问团高级顾问。

　　温昱擅长面向对象、架构和框架设计，对设计模式、UML、RUP和软件工程有深入研究。曾在金融、航空、多媒体、网络管理、中间件平台等领域负责和参与多个大型系统的设计和开发。

　　温昱发表了《拥抱变化：敏捷设计从理论到实践》、《随需而变的RUP》等文章数十篇，目前译著有《应用框架的设计与实现——.NET平台》一书。

    欢迎访问温昱的专栏http://sa.csai.cn/tszl/wenyu.asp

 聊天记录：

【希赛主持人】各位网友大家下午好，今天聊天的话题是“软件架构解读与架构师角色培养”，请到的嘉宾是希赛顾问团高级顾问温昱。进来的网友可以提前提问，聊天将于15:00开始。

 【希赛主持人】各位网友，大家好！让大家久等了，很高兴又和大家见面了，今天我们请到的是希赛顾问团高级顾问温昱，下面首先请我们的温顾问和大家打个招呼。

 【希赛嘉宾/温昱】大家好！我是温昱，很高兴一起讨论软件架构的话题。

 【希赛主持人】二十世纪六、七十年代随着“软件危机”的日益加剧，使得人们不得不重视软件工程的研究，同时人们也认识到软件架构的重要性。温顾问，软件架构一词最早是出现在什么时候？

 【希赛嘉宾/温昱】架构的思想萌芽自196x年Dijkstra的工作。架构设计出现的背景是：需要进行超越算法和数据结构一级的设计，以适应软件规模和复杂性的增长。

 【希赛主持人】“软件架构”是如何定义的呢？我看过一个网友是这样说的：“我没有写过什么程序，但是也想明白软件构架是什么，有什么作用。似乎每一本有关软件构架的书都对此有不同的解释，于是软件构架成为了迷一样的东西。”，你能说出你对软件架构的理解吗？软件架构真的和迷一样吗？

【希赛嘉宾/温昱】这位网友的说法很有代表性，此文：http://51cmm.csai.cn/ANALYZE/200702011428471882.htm就是针对此而写。
　　软件架构至今没有统一的定义。我推荐：将定义分类。毕竟，软件架构的定义太多太乱，但“推崇一个否定其它”会遗失精华，我们作为软件业界的实践者必须学会兼收并蓄。
　　下面和大家分享我的分类方式。“组成派”定义的核心是：架构=组件 交互。“决策派”定义的核心：架构=重要决策集。
　　（组件 交互）其实完整的架构实践是综合体现两者，我在《软件架构设计》中归纳为：所谓软件架构就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。

【希赛主持人】网友[nail.wu] 说: 软件架构具体做什么工作?输出的文档是什么?

【希赛嘉宾/温昱】架构师要深入理解需求，进行架构分析，设计架构，验证架构方案的可行性等。
输出文档：《软件架构设计文档》。同时，推荐的做法是还要提交可运行和测试的架构原型。

【希赛主持人】网友[zbstar] 说: 我看了网上一些资料，对架构有时称为“构架”，是一回事吗？

【希赛嘉宾/温昱】架构对应的英文词汇是“Architecture”，国内叫法有架构、构架、体系结构等。
　　现在最流行的叫法是架构。

【希赛主持人】温顾问，能举一些具体的例子来解释软件架构吗？为什么在开发时需对软件架构进行设计？

【希赛嘉宾/温昱】好的。架构的例子很多，比如编译器包含词法分析器、语法分析器、代码生成器等部分，并明确它们直接交互的方式和数据格式，就可以“分而治之”了。
　　至于为什么设计架构，简单说，架构设计的意义在于“一攻一守”。所谓守，是软件规模大了复杂性高了，不进行“超越算法和数据结构一级的架构设计”就没办法搞定了。所谓攻，指软件架构可以作为大规模团队开发的基础、提高软件质量的手段等。
　　Brooks的著名论断大家知道的：软件开发的本质问题在于软件本身的复杂性。

【希赛主持人】网友[jlinux] 说: 架构大家谈概念的多，实际应用到具体软件开发中的少。请问，如何把架构的思想及实践经验推广到大家的项目中去？

【希赛嘉宾/温昱】是的，为理论而理论没有意义，反而搞的开发人员和架构师“合不来”。
　　至于如何运用架构思想，我谈谈我的经验。
　　真正成功的架构设计，必须关注四个现实问题：是否遗漏了至关重要的非功能需求，能否驯服数量巨大且频繁变化的需求， 能否从容设计软件架构的不同方面（因为架构也很复杂），是否及早验证架构方案并做出了调整。
所以我推荐，要在“架构设计过程”一级真正贯穿一些根本原则。我推荐的软件架构设计流程为“六步法”（在即将出版的《软件架构设计》一书中有系统论述）：需求分析，领域建模，确定关键需求，概念性架构设计，细化架构设计，架构验证。
　　很多人都在设计架构，但结果有的成功有的失败，为什么？四个策略很关键。
　　1. 全面认识需求
　　2. 关键需求决定架构（以应对需求变更）
　　3. 多视图探寻架构
　　4. 尽早验证架构

【希赛主持人】网友[gelinbo] 说: 请问一个软件公司，在人手不是很多的情况下，组织结构怎么样最好 怎么样才能让需求、设计、研发、测试等很好的配合起来？

【希赛嘉宾/温昱】人手少的情况下，采用“动态团队”模式比较好。请这位朋友参考我的老博文 http://gocom.primeton.com/blog/index.php?op=ViewArticle&articleId=38&blogId=23

【希赛主持人】网友[meisong] 说: 作为需求和设计间过度的架构设计人员,如何解决业务领域、计算机领域，不可逾越的“鸿沟”？如何有效融合？

【希赛嘉宾/温昱】鸿沟就是机会，能别人所不能方显风骨（田俊国说：禁忌之处显风骨）。跨越这个鸿沟，我的经验是：成为真正的软件需求专家（不等同于领域专家和需求采集角色）。
　　比如如何通过领域模型来捕获业务领域功能背后的结构，对跨越鸿沟非常关键。再比如吃透需求变更的规律，我在《软件架构设计》一书里有论述。

【希赛主持人】网友[jlinux] 说: 四个策略和Zachman框架的理念很像啊，有什么更加切实可行的规范化方法？比如RUP或者XP之类的？

【希赛嘉宾/温昱】非也。Zachman框架很重，而且是 企业架构的东东。而我的架构设计的四个策略是我10年经验的总结，实践效果很好。我都将之写入《软件架构设计》一书了。
　　顺便提醒大家：区分软件架构 和 企业架构 对新手非常重要。
　　另外：XP根本没有架构设计，它的隐喻是“概念性架构”，是很薄的、和技术无关的架构。
　　至于RUP，的确值得深入研究。不过用例驱动 对 架构设计来说牵强了，驱动项目管理等可以。

【希赛主持人】[zbstar] 说: 架构和框架是不是仅在概念的大小上有区别，即架构是个大概念，而框架具体一点，是个小概念？

【希赛嘉宾/温昱】框架是软件系统或子系统的半成品，必有代码。架构是超越算法和程序代码一级的更高层次的抽象。熟悉UML建模的朋友：框架是“复杂软件单元”的子类，而架构和“复杂软件单元”是“关联”关系。（图：http://51cmm.csai.cn/ANALYZE/200702011439371852.htm）
框架和架构没有大小之别，有些“名著”中有误导。例如，一个子系统，可以有架构设计，而整个应用系统也可以有应用框架（app framework）来支撑。

【希赛主持人】网友[jlinux] 说: 设计架构纯粹靠经验，还是有类似于RUP这样的方法学框架可遵循？

【希赛嘉宾/温昱】架构设计严重依赖与经验，但是，架构设计方法也很必要。架构是一门既是艺术又是科学又是工程的学科。RUP在软件架构方法方面做出了应有的贡献，但至今没有一统江湖的架构设计方法学，RUP也有不尽人意之处。
RUP太重了，使用RUP的第一原则就是：要剪裁。

【希赛主持人】网友[davada] 说: 温顾问下午好，我想请问，现有C/S模式和B/S模式基础上，出现了一种智能客户端的开发模式，其特点是0客户端，但是是C/S的模式，能自动检测版本，同时自动下载高级版本，请问是怎样实现版本检测，工作原理是是怎样的啊？

【希赛嘉宾/温昱】我说原理：随着系统规模扩大，特别是互联网应用的发展，近几年出现了一个趋势，就是元数据的应用越来越普遍了。对版本的描述信息，以元数据的形式保持……。哈，原理如此。

【希赛主持人】网友[tianchengzhi] 说: 如何剪裁？

【希赛嘉宾/温昱】RUP的剪裁我在 中国软件工程大会 上曾有专门演讲，基本原理是，把软件过程也当成“开发出来”的东西，重新评估自己团队的情况和需求，以RUP为蓝本定制自己的过程。
此处有我几篇RUP剪裁的文章 http://sa.csai.cn/tszl/wenyu.asp

【希赛主持人】网友[jlinux] 说: 可以认为普元公司推的产品是架构设计的辅助性工具么？VS.net2005也针对架构师提供了工具。请问，如何行之有效的利用这些工具来帮助进行架构设计？或者换一个问题，嘉宾的书中阐述的思想，如何结合这些工具，来让更多的初涉架构的学习者进入架构的世界？

【希赛嘉宾/温昱】先回答你的本质问题：如何结合工具来让更多的初涉架构的学习者进入架构的世界。我的回答分为两方面。一方面，没有工具能代替架构设计。另一方面，平台级产品有一定作用。下面深究：不少平台级产品，实现的是产品线工程的社会化，是企业架构（EA）的概念。
　　我在扩开一下：MDA时代真的到来了会怎样？其关键质量属性（如性能可扩展性等）还是由“终端用户”看不到的软件的架构决定的。

【希赛主持人】网友[jlinux] 说: gelinbo的发言有一定代表性，能不能有人把多年在架构方面的经验总结并升华为一定的方法论并结合工具来为帮助大家呢？呵呵，虽然说架构方面的东西有些只可意会不可言传，但是随着业界的进步，早晚有一天会有类似的东西出现吧。温顾问会不会作为第一个吃螃蟹的人呢？

【希赛嘉宾/温昱】呵呵，一方面，我已将经验写入《软件架构设计》一书。另一方面，我个人预见架构设计方法论在未来5到10年会更成熟化。但是，架构设计在可预见的未来必定还是 艺术 科学，“可复制”的科学成分终究不是全部，艺术还要靠人的经验等。
　　大家品味一下软件业界的发展，我认为架构模式和架构策略会在目前更多地“帮助”我们。

【希赛主持人】网友[hnthb] 说: 我的几个问题：
第一：SOA架构设计过程与传统方式有何不用，其特别要考虑的东西有哪些？
第二：SOA中设计的核心理念是什么？
第三：除了SOA还有一些什么新的架构设计方案?

【希赛嘉宾/温昱】回答问题之前，我还是要罗嗦一点，太重要了：不要把软件架构和企业架构（Enterprise Arch）等同。软件架构关注的是：软件。EA关注的是：tech与business的匹配。我认为SOA是企业架构模式，就像MVC呀Layers呀是软件架构模式一样。
　　答一：SOA重视业务的敏捷性，没有合适的biz arch其实施很难保证成功。
　　答二：服务。是一种大粒度的component，立足与现实世界而不是计算机世界。
　　SOA好像“哗”一下就出现了，其实不然。商业的蓬勃发展，使得各类服务都有大批的服务商，于是重用“服务”的效益有望超过生产和推销它的成本。原因二，商业竞争的加剧使得众多商家不得不进行“差异化服务”，这种业务趋同背景之下的业务个性化要求，为服务的个性化组装提出了要求。上述两个原因相辅相成、缺一不可。

【希赛主持人】网友[fzxugang] 说: 温昱顾问好，主持人好,我想请教一下松耦合与复用的关系?

【希赛嘉宾/温昱】职责的合理划分是OO的精髓。合理划分松耦合，才利于复用。

【希赛主持人】网友[jlinux] 说: 那么要想架构师如何去学习？一方面是架构的基本理论，另一方面是大量的项目经验。但是大多数架构师或者想成为架构师的都是多年自己总结，才慢慢升华的。艺术设计者一方面靠天分，另一方面社会也有大量的教育、培训或者其他机会让（刺激）更多的人走上艺术设计的道路。我觉得现在的软件界这种“刺激”的机会不是很多，并没有什么社会团体力量在推动这方面的发展。少数人的“奢侈品”？请问嘉宾怎么看，怎么把这层神秘的面纱给大家揭开。

【希赛嘉宾/温昱】两方面。一是从我们自身找问题（呵呵鲁迅呀“自我解剖”），国外的经验之谈到了国内常被评为“理论呀”。二是气氛的确不太好，我赞同这位朋友所说。
　　至于架构师如何学习……想成为架构师，其职业规划应紧扣几个重点：更深更系统的掌握技术、更多的经验、更强的系统思维能力。一定要参加大项目。

【希赛主持人】网友[tianchengzhi] 说: 那么在架构师角色培养上，具体有哪些途径方法？

【希赛嘉宾/温昱】张博士（张友生）的 http://51cmm.csai.cn/ExpertEyes/200607050819581137.htm 可以参考。架构师是实践出来的。

【希赛主持人】网友[fzxugang] 说: 有一个问题一直困扰我，就是松耦合与复用的关系，如果大批量的复用，那就是违反松耦合 的原则，而不复用，那很多东西需要重新开发，不知道这个关系要怎么说？

【希赛嘉宾/温昱】先发散说：大批量复用是个角度，大粒度复用也值得考虑，framework方式的复用呢，能不能解决你的问题？
　　再说说耦合。松耦合要放在上下文中说，用OO的说法叫：协作。用高频度的协作来指导你的松耦合，而不是不可能出现的场景也成为松耦合的标杆。
　　再给fzxugang朋友说几句：什么叫好的数据结构还记得吗？一个数据结构到达如何设计，要看它的典型操作。要不到底是数组好还是链表好就没个标准了。用，就是标准。

【希赛主持人】网友[jlinux] 说: 架构思想在整个业界的发展应用状况如何？并没有接触那么多架构师，所以“世间”隐藏多少高手不得而知。温先生应该经常和高手“华山论剑”吧！能不能说说国内和国外在架构方面的现状及未来发展方向？

【希赛嘉宾/温昱】哈，好问题，我说说个人看法。国内的软件产业结构决定了没有国外（指美国）的齐全，所以国内和国外情况差异很大。
　　说几个具体的点吧。
　　国外compiler是个造就了多少富翁的产业……
　　欧洲的研究也很贴近业界，他们的OO再工程模式就是一个例子，实践意义很大……
　　国内呢，以应用系统为主的产业结构，造就了实践中framework在某种程度上代替arch的错觉……

【希赛主持人】网友[zhqliang] 说: 你好!请问软件架构师的市场需求及发展方向如何?

【希赛嘉宾/温昱】架构的重要性早已被普遍认同。我认为软件人才应该是菱形需求，钻的深的（真正的技术高手）和站的高的（架构师）在两端。

【希赛主持人】由于时间的关系，今天的嘉宾聊天就到这里，部分网友的提问嘉宾未来得及回答的，可进入希赛社区进行讨论，谢谢大家的参加，也谢谢我们的温顾问能为我们大家解答问题。
　　各位网友，下次嘉宾聊天见。

分类： 系统架构 设计模式