页面数据载入中……莱州博客网
日志搜索
用户公告
页面数据载入中……莱州博客网
用户登录
页面数据载入中……莱州博客网
时间记忆
页面数据载入中……莱州博客网
最新日志
页面数据载入中……莱州博客网
最新回复
页面数据载入中……莱州博客网
最新留言
页面数据载入中……莱州博客网
加入群组
页面数据载入中……莱州博客网
我的好友
页面数据载入中……莱州博客网
我的照片
站点信息
页面数据载入中……莱州博客网
友情链接
6月8日与温昱在线畅谈软件架构的方方面面
2007-6-8 16:33:00
嘉宾[温昱]:感谢主持人
[2007-6-8 16:16:00]
问：读者提问：可能是最后一个问题了,有没有插件式的架构设计方法?可以根据需求进行组合扩展.[2007-6-8 16:12:00]
嘉宾[温昱]: 好，我来回答最后一个问题。答案是没有通用的这种技术。 ★这是业界的理想，要想达到根据需求随意组合，一定要靠基于业务的组件，其实SOA的service就是这个思路。 ★另一个方向就是DSF + DSL。（Booch预研 2030年的主流技术是AOP和DSF，呵呵）
嘉宾[温昱]: 谢谢大家参与。
[2007-6-8 16:12:00]
问：读者提问：我也问一个UML的问题,UML是辅助自己理解重要,还是辅助交流重要?[2007-6-8 16:07:00]
嘉宾[温昱]: 辅助交流是目标，但用UML用的好你会发现它促进思维。
问：读者提问：温老师您好!我刚刚入行不久!一直想往架构师方向发展!那么我现在应该从哪些方面来培养我自己呢?都应该注意点什么?[2007-6-8 16:04:00]
嘉宾[温昱]: 关于个人职业规划，我有个理念：离目标近了，用自顶向下方法，倒推要做的事情。离目标还远，则要自底向上，多多掌握各种技术，特别是工作中涉及到的技术，或许比较现实。具体可以看看《软件架构设计》最后9章，包含思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。
问：框架技术的未来？[2007-6-8 16:01:00]
嘉宾[温昱]: 框架技术极为重要，有两个方向大家关注。 1. 和业务的结合。未来DSF（领域特定框架）很重要。 2. 框架直接的互操作。所谓meta framework技术。
问：读者提问：请问微软的framework这个框架，在构架上它有哪些优缺点，他适合构架什么类型的程序，不适合构架什么类型的程序？[2007-6-8 15:59:00]
嘉宾[温昱]: 哪个框架？
问：读者提问：怎么才能做好一个系统的需求分析？主要抓主哪些方面[2007-6-8 15:58:00]
嘉宾[温昱]: 需求分析是一个综合问题，除了很多管理方面的因素之外，一定要考虑“需求层次论”。一个系统的业务需求往往较少，以业务目标列表方式的话：三五条的样子。如果太多，其实往往意味着甲方要做的是多个系统，而不是一个系统。其次，用户需求。再次，行为需求。 要牢记业务需求，这样才能进行需求创新（即为用户提供很出彩的功能）。
问：软件架构最近有没有新的发展动向？比如最近网上谈论较多的SOA，软件架构与SOA是一个什么样的关系？SOA是否会对软件架构有影响或者说软件架构对SOA有哪些促进作用？[2007-6-8 15:54:00]
嘉宾[温昱]: 看来大家都关心SOA。 首先，所有实践者必须区分软件架构 和 企业架构（Enterprise Arch）。EA也满足architcture的概念，但它一定是既关系business又关系tech。 软件架构关注的是：软件。EA 关注的是：tech 与business 的匹配。我认为SOA 是企业架构模式，就像MVC 呀Layers 呀是软件架构模式一样。 所以并不是所有软件都能采用SOA架构的，SOA架构是解决企业软件中整合问题的一种方式。相信有人要争论，说我把SOA的作用局限在“整合”太不革命了，其实未来的业务创新绝大部分会发生在企业间的整合业务上，理解了这一点，就看出我也不是“很不革命”哈哈。 SOA 重视业务的敏捷性，没有合适的biz arch 其实施很难保证成功。其中的“服务”是一种大粒度的component，立足与现实世界而不是计算机世界。
问：通常，对不熟悉的人来说，谈到软件架构设计会给人以工程浩大之感，只有大企业才需要。对于目前我国众多中小型软件企业来说，软件架构设计有何意义？软件架构在现代软件产业中究竟扮演着什么样角色？[2007-6-8 15:50:00]
嘉宾[温昱]: 无论企业大小，包括往往出自一人之手的共享软件，都应该重视需求创新和架构设计。 孟岩等朋友都强调，中国软件产业应重视行业软件，非常赞同！这就必须贴近业务、需求创新、不断做细做深、并能及时根据行业趋势进行调整，而架构正是变化的关键。某红极一时的共享软件小不小？就是因为架构问题，在竞争中渐渐失败了。
问：读者问题：温老师能否对我们处于程序员行列的这类人给一些建议，如何规划做到软件架构这一阶段[2007-6-8 15:49:00]
嘉宾[温昱]: 多实践，多思考，每个项目都往两方面钻研： 1. 深。背后的技术原理，通了，才可以再次用到新工作中。 2.系统。比如http://www.vckbase.com/document/viewdoc/?id=487，呵呵。
问：6） 您能对刚从程序员升任为架构师的朋友说几句吗？有没有“头三个月秘笈”之类的建议呢？[2007-6-8 15:45:00]
嘉宾[温昱]: 建议有，秘笈称不上。 ★要掌握架构设计方法。比如功能需求如何影响架构、可扩展性等开发期质量需求如何影响架构、性能等运行期质量需求如何影响架构？其实约束性需求最危险，根本不是大多数朋友所理解的“直接遵守的需求”那么简单，其背后往往藏着许多功能和质量需求必须分析挖掘出来。 ★总的架构设计过程是：需求分析、领域建模、确定关键需求（含非功能需求）、概念性架构设计、实际架构设计、架构验证。 ★其次，要学会做减法，踌躇满志者常做的是加法。“需求决定架构”是不错，但时间有限、且需求变更变化频繁，所以架构师往往不可能深入分析所有需求，因此应采用“关键需求决定架构”的策略。
问：读者问题：初入架构设计行列，必须要掌握哪些工具和哪些方面的基本功呢？[2007-6-8 15:43:00]
嘉宾[温昱]: 最重要的工具是思维工具：比如非功能需求设计方法论、比如不同种类的需求对架构设计截然不同的影响、比如多视图架构设计方法（众多名著说其为归档方法是买椟还珠，多视图方法是很重要的架构思维方法）。 另：UML应掌握、设计模式、架构模式、OOD进阶等。
问：读者提问：我还是问关于敏捷的问题.敏捷提倡只考虑眼前的问题;而架构则需考虑到日后的维护,扩展性等.这不是冲突吗?[2007-6-8 15:40:00]
嘉宾[温昱]: 这也正是业界反对“某些agile方法”的重点。我喜欢敏捷中的重构，但架构设计应当被重视。另外XP里也不是完全没有架构设计，但太简单了，隐喻就是“概念性架构”设计。概念性架构很常见的，比如那个web server的三个角色的图……
问：读者提问：温老师的译作，.net平台的框架与实现 中谈的框架是不是就是软件的一种架构实现呢？[2007-6-8 15:37:00]
嘉宾[温昱]: 框架定义：可以通过某种回调机制进行扩展的软件系统或子系统的半成品。 框架分不同种类，一种分类是：系统框架and子系统框架。《应用框架的设计与实现》是系统框架，将一个B2B系统的架构设计方案框架化了。
问：读者提问：跟Martine fowler的《企业架构模式》比较起来，您认为您的书处于什么位置?[2007-6-8 15:35:00]
嘉宾[温昱]: Martin Fowler的模式，处于架构模式 与 设计模式 之间。 我的《软件架构设计》更重视讲“如何做”（比如如何将非功能需求细化至场景、从场景到设计决策）。 我的书重点有二：一是一种易于实践的架构设计系统化方法，而是希望给程序员提供一本向架构师过渡的参考书。
问：读者提问：架构设计的视图主要涉及哪些方面，哪些是必要的？[2007-6-8 15:30:00]
嘉宾[温昱]: ★建议从2架构视图开始：逻辑架构和物理架构相分离的设计方法在软件实践中比较常用。逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。 ★建议向5架构视图过渡（因为复杂时部署和并发应分离……）：逻辑架构视图、开发架构视图、运行架构视图、物理架构视图、数据架构视图。构成每个架构设计视图的元素不同，这些不同的元素撑起了不同的思维空间，从而使每个架构视图重点覆盖不同种类的需求。最终，所有架构设计视图所表达的语义综合在一起，就构成了软件架构设计方案。
问：许多程序员都搞不清楚架构（Architecture）和框架（Framework）是怎么回事，您能谈谈吗？[2007-6-8 15:27:00]
嘉宾[温昱]: 一句话，框架是软件，架构不是软件。软件架构不是软件，而是关于软件如何设计的重要决策，是超越算法与数据结构一级的设计。框架是一种特殊的软件，是可以通过某种回调机制进行扩展的软件系统或子系统的半成品。 ★框架的智慧在于：为了追求重用所带来的价值量最大化，将容易变化的部分封装成扩展点，并辅以回调机制将它们纳入框架的控制范围之内，从而在兼顾定制开销的同时使被重用的设计成果最多。 ★第一，现在的软件开发越来越倚重框架的使用，因此选择何种框架、每个框架在整个架构中处在什么位置，都成为软件架构设计的重要环节。 ★第二，当使用来自第三方的框架作为某一级系统或子系统的架构基础时，则应当仔细研究其结构——这是因为此时是使用它的结构、而不仅仅是服务。
问：读者提问：现在做系统的时候经常遇到多种数据库操作的问题，怎样处理多种数据库的问题？[2007-6-8 15:25:00]
嘉宾[温昱]: 首要原则，重用。如果是OLTP则借助ORM屏蔽数据库差异是一个选择。 另外，不同DB是同时使用还是非此既彼，以此决定要支持的变化是运行期还是开发期的。。。。
问：读者提问：一个现有的比较庞大的系统，各部分的设计和实现都不很统一，规范，如果重新考虑统一的架构实现，问现实吗，会存在哪些困难？[2007-6-8 15:22:00]
嘉宾[温昱]: 务实地谈：我感觉你说的这个系统是集成系统。此时，比较现实的是把各（子）系统之间的交互接口和交互机制重新统一设计。
问：读者问题：请问SOA架构的松耦合度底,那是不是意味者业务层全部使用接口+工厂实现[2007-6-8 15:20:00]
嘉宾[温昱]: SOA的架构中，service 和 event 是核心，它们都必须是业务概念。这才是经典的SOA架构。 现在SOA很热，但它是一种企业架构模式，不是软件架构模式，请大家当心误用。一定是做企业应用的朋友才考虑是否采用SOA架构。
问：读者提问：对一个大型的网站系统，子项目很多，如何考虑一个好的软件架构设计呢？[2007-6-8 15:17:00]
嘉宾[温昱]: 架构是分层次的：这个大型网站要进行统一的架构规划，比如互操作性必须在这里考虑；而不同子项目可以有自己的架构。
问：那么，程序员如何才能成长为架构师呢？[2007-6-8 15:15:00]
嘉宾[温昱]: 首当其冲的是思维突破。我常说“忘却是一种能力”，永远局限在OOP层面思考的方式必须突破。 然后是掌握更多新能力。足够的编程技能不能使程序员“自动”成为架构师，因为有太多编程之外的问题要考虑。比如如何确定对架构关键的需求子集，如何运用多视图方法设计架构，架构设计要进行到什么程度……。相应的很多新技能要求也有很多。（纯属广告：《软件架构设计》第三篇共9章都在讲程序员成长问题） 总结为：更系统的掌握技术、更高的把握大局的能力、更多的经验。
问：《程序员》技术主编孟岩在一篇文中谈到他认识的优秀架构师都具有多年实践开发经验，是不是架构师必须会编程呢？[2007-6-8 15:14:00]
嘉宾[温昱]: 两方面。 第一，架构师会编程才能将架构设计落到实处，不会在架构设计和详细设计之间留下“缝隙”。研究需求、设计架构、具体开发……这是太多人早已习惯了的思维模式，于是重视为需求而设计忽视为开发人员考虑。其实，相信大家都熟悉“架构为不同涉众考虑”的观点，每种基于多视图的架构设计方法中都不会忽略“开发实现视图”。 第二，也不是说，架构师必须是每个项目所用具体某种语言的高手。“编程功力”更关键，而且架构师必须有“忘却”的能力，突破编程层面过多的细节来思考。
问：项目经理如何履行项目架构职能,有没有一个可以循序渐进的路线呢?[2007-6-8 15:13:00]
嘉宾[温昱]: 你说的项目经理兼任了架构师角色是吗？我建议的总的架构设计过程是：需求分析、领域建模、确定关键需求（含非功能需求）、概念性架构设计、实际架构设计、架构验证。 需求分析架构师能曾与最好，而领域建模建议由架构师领导领域专家等完成，确定关键需求是“主动”应对需求变更的策略（而且架构设计往往没有太多时间），概念性架构设计是技术无关层面的设计，实际架构设计采用多视图架构设计方法。
问：软件架构师在整个软件开发环节中处于什么地位？其关键作用是什么？[2007-6-8 15:09:00]
嘉宾[温昱]: 架构师负责架构设计，并参与架构原型的实现，到开发全面铺开以后，还要指导开发、协调冲突。 可以回顾架构出现的背景：“需要进行超越算法和数据结构一级的设计，以适应软件规模和复杂性的增长。”因此，一股脑将复杂性统统展开，则软件开发将陷入混乱和无法控制之中。先进行架构设计、后进行详细设计和编码实现，运用了“基于问题深度分而治之”的理念，利于控制复杂性。。。
问：读者提问：就现有的系统，如果不重构，或者代价很少的情况下，怎么使之总体性能最优化[2007-6-8 15:08:00]
嘉宾[温昱]: 如果不进行架构级重构，可分析现有架构背后的“职责模型”，找出最耗时的职责，进行缓存、负载均衡、硬件提升（垂直可伸缩性）等考虑。
问：您的新作《软件架构设计》是国内第一本深入讨论架构设计问题的专著，我发现这本书非常强调非功能需求设计方法论，第7、10、13、15章都讨论了非功能需求的话题，那么为什么非功能需求对架构设计如此重要呢？[2007-6-8 15:06:00]
嘉宾[温昱]: 非功能需求是最重要的“架构决定因素”之一。反观业界，失败或推倒重写往往不是因为功能没实现而是非功能质量太差。 非功能需求大致分为质量属性和约束两大类。质量属性是软件系统的整体质量品质——所谓整体品质，就是它往往和大多数功能都有关，而不是仅仅表现在某个功能“内部”。 为了满足性能、持续可用性等运行期质量方面的要求，架构师必须深入研究软件系统运行期间的情况，合理划分系统不同部分的职责，权衡轻重缓急，并制定相应的并行、分时、排队、缓存、批处理等设计决策。而要满足可扩展性、可重用性等开发期质量方面的要求，则要求架构师深入研究软件系统开发期间的职责划分、变化隔离、框架使用、代码组织等情况，制定相应的设计决策。 架构师不能仅盯着功能需求，忽视非功能需求会导致架构设计失败。
问：需求变更有规律吗？[2007-6-8 15:05:00]
嘉宾[温昱]: 被动的对需求变更进行管理是不够的，需求变更有一定的规律，大家多实践总结，就会发现更多。我提几点：质量属性往往很稳定，比如银行系统多少年来强调持续可用性。易变的是功能需求！继续深入分析，“结息”作为银行系统的用户级需求，不会受到利息税率改变的影响……最终发现是行为需求（对应与用例规约）易变，而笼统的用户需求稳定，至于组织级的业务需求就更稳定些。
问：读者提问：做系统的时候经常会遇到需求改变的情况，你是怎么处理这个问题的？[2007-6-8 15:01:00]
嘉宾[温昱]: 关键需求决定架构。Len Bass指出：“功能、质量和商业需求的某个集合‘塑造’了构架。”
问：读者提问：我想问一下,构架如何与敏捷结合?[2007-6-8 14:59:00]
嘉宾[温昱]: 架构要满足不同方面的需求，功能需求、运行期质量属性、开发期质量属性、约束等。所谓系统的敏捷性，属于运行其质量属性，但它往往是一组其他属性的组合：可重用性、易理解性、可测试性、可扩展性（弹性）。 至于作为过程的agile，我比较重视领域建模。
问：读者提问：1.软件开发人员和构架师在职责上有什么主要区别？[2007-6-8 14:55:00]
嘉宾[温昱]: 更加情况不同，架构师要担负的职责可能包括：领导并负责架构设计；实际参与架构原型的开发实现；讲解架构，指导开发，协调冲突；支持项目经理，如技术可行性、任务划分、人员招聘；了解所在组织的业务目标，令架构更好地支持业务目标；评估新技术并提出采用建议。 而开发人员的职责，其实不是一刀切的：1. 有经验的架构师会让开发leader参与架构，这样他们后期对架构的认可度更高。2. 开发者应有能力负责相关详细设计。 3. 软件蓝领的说法很可笑。
问：读者提问：现在流行的主要有哪几种系统架构？[2007-6-8 14:50:00]
嘉宾[温昱]: 借此机会，我谈谈大家可能对C/S、三层C/S、以及B/S架构可能存在的误解。上述仅是架构设计的一部分，是部署架构视图。确定了这些之后，还有很多架构设计工作要做。 至于现在流行什么，SOA算比较热的。但是，所有实践者必须区分软件架构 和 企业架构（Enterprise Arch）。 软件架构关注的是：软件。EA 关注的是：tech 与business 的匹配。我认为SOA 是企业架构模式，就像MVC 呀Layers 呀是软件架构模式一样。 所以并不是所有软件都能采用SOA架构的，SOA架构是解决企业软件中整合问题的一种方式。相信有人要争论，说我把SOA的作用局限在“整合”太不革命了，其实未来的业务创新绝大部分会发生在企业间的整合业务上，理解了这一点，就看出我也不是“很不革命”哈哈。
问：读者问题：做系统的架构有什么好的辅助工具和规律？[2007-6-8 14:47:00]
嘉宾[温昱]: 关于工具，两句话：1. 架构设计不可能被工具代替。 2. 借助平台或工具，对架构有帮助，原因在于平台往往提供了“缺省的架构实现”，我们应根据具体项目来看平台推给我们的架构是否合适。 关于规律，我想说几点最佳实践：多视图的架构设计方法。要满足性能、持续可用性等方面的需求，架构师必须深入研究软件系统运行期间的情况、制定相应的设计决策，这些需求被称为软件的“运行期质量属性”。而要满足可扩展性、可重用性等方面的需求，则要求架构师深入研究软件系统开发期间的情况、制定相应的设计决策，这些需求被称为软件的“开发期质量属性”……基于多视图的架构设计方法恰好可以帮助软件架构师完成上述工作。
问：读者提问：请问该如何测试一个软件架构是否合理?[2007-6-8 14:43:00]
嘉宾[温昱]: 测试与评审并重。 通过开发架构原型，重点验证运行期质量属性（如性能）。通过评审确保功能需求能够被满足。如果不是团队熟悉的领域，通过评审确定运行期质量属性往往有太多“臆测”成分。
问：读者提问：做好一个系统架构要做到哪些方面？[2007-6-8 14:38:00]
嘉宾[温昱]: 足够的编程技能不能使程序员“自动”成为架构师，因为有太多编程之外的问题要考虑。比如如何确定对架构关键的需求子集，如何运用多视图方法设计架构，架构设计要进行到什么程度……。 当然，首当其冲的是思维突破。我常说“忘却是一种能力”，永远局限在OOP层面思考的方式必须突破。
问：tianjiahe172839的读者问:需要设计人员有怎样的基础才能够进行软件架构设计呢?[2007-6-8 14:37:00]
嘉宾[温昱]: 简单而言：更系统的掌握技术、更高的把握大局的能力、更多的经验。
嘉宾[温昱]: 国家的软考当中，有软件设计师，但对应于高级开发工程师。
[2007-6-8 14:36:00]
问：软件架构师主要工作是什么？软件架构应该处在开发的哪个阶段？[2007-6-8 14:34:00]
嘉宾[温昱]: 架构师负责架构设计，并参与架构原型的实现，到开发全面铺开以后，还要指导开发、协调冲突。设计早期分为：概要设计，模块设计。现在对应于：架构设计、详细设计。架构设计出于开发前期，是大规模团队开发的基础。
问：温老师，您的职业经历涉及金融、航空、电信、多媒体、中间件平台等众多领域，能结合您的体会谈谈什么是软件架构设计吗？[2007-6-8 14:31:00]
嘉宾[温昱]: 好。从面向业务的需求，到最终的面向技术的软件系统，要跨越很大的鸿沟。软件架构设计就是要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。
嘉宾[主持人]: 我们的聊天现在正式开始！
[2007-6-8 14:28:00]
嘉宾[温昱]: 大家好！我是温昱，很高兴一起讨论软件架构的话题。
[2007-6-8 14:27:00]
嘉宾[主持人]: 聊天马上就要开始了！各位网友下午好！我是大家的老朋友落落，本期活动的主持人。今天博文视点和CSDN有幸请到温昱老师，他是资深咨询顾问，CSAI特聘高级顾问，软件架构专家，软件架构思想的传播者和积极推动者
[2007-6-8 14:26:00]
嘉宾[主持人]: CSDN 博文视点名家讲坛第12期活动，温昱先生与您畅谈软件架构设计。活动时间是6月8日14：30~16：00。
[2007-6-8 9:44:00]
问：温老师，您好！您现在在上海吗？[2007-6-8 9:35:00]
嘉宾[温昱]: 是啊。您好。
[2007-6-8 16:16:00]
问：读者提问：可能是最后一个问题了,有没有插件式的架构设计方法?可以根据需求进行组合扩展.[2007-6-8 16:12:00]
嘉宾[温昱]: 好，我来回答最后一个问题。答案是没有通用的这种技术。 ★这是业界的理想，要想达到根据需求随意组合，一定要靠基于业务的组件，其实SOA的service就是这个思路。 ★另一个方向就是DSF + DSL。（Booch预研 2030年的主流技术是AOP和DSF，呵呵）
嘉宾[温昱]: 谢谢大家参与。
[2007-6-8 16:12:00]
问：读者提问：我也问一个UML的问题,UML是辅助自己理解重要,还是辅助交流重要?[2007-6-8 16:07:00]
嘉宾[温昱]: 辅助交流是目标，但用UML用的好你会发现它促进思维。
问：读者提问：温老师您好!我刚刚入行不久!一直想往架构师方向发展!那么我现在应该从哪些方面来培养我自己呢?都应该注意点什么?[2007-6-8 16:04:00]
嘉宾[温昱]: 关于个人职业规划，我有个理念：离目标近了，用自顶向下方法，倒推要做的事情。离目标还远，则要自底向上，多多掌握各种技术，特别是工作中涉及到的技术，或许比较现实。具体可以看看《软件架构设计》最后9章，包含思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。
问：框架技术的未来？[2007-6-8 16:01:00]
嘉宾[温昱]: 框架技术极为重要，有两个方向大家关注。 1. 和业务的结合。未来DSF（领域特定框架）很重要。 2. 框架直接的互操作。所谓meta framework技术。
问：读者提问：请问微软的framework这个框架，在构架上它有哪些优缺点，他适合构架什么类型的程序，不适合构架什么类型的程序？[2007-6-8 15:59:00]
嘉宾[温昱]: 哪个框架？
问：读者提问：怎么才能做好一个系统的需求分析？主要抓主哪些方面[2007-6-8 15:58:00]
嘉宾[温昱]: 需求分析是一个综合问题，除了很多管理方面的因素之外，一定要考虑“需求层次论”。一个系统的业务需求往往较少，以业务目标列表方式的话：三五条的样子。如果太多，其实往往意味着甲方要做的是多个系统，而不是一个系统。其次，用户需求。再次，行为需求。 要牢记业务需求，这样才能进行需求创新（即为用户提供很出彩的功能）。
问：软件架构最近有没有新的发展动向？比如最近网上谈论较多的SOA，软件架构与SOA是一个什么样的关系？SOA是否会对软件架构有影响或者说软件架构对SOA有哪些促进作用？[2007-6-8 15:54:00]
嘉宾[温昱]: 看来大家都关心SOA。 首先，所有实践者必须区分软件架构 和 企业架构（Enterprise Arch）。EA也满足architcture的概念，但它一定是既关系business又关系tech。 软件架构关注的是：软件。EA 关注的是：tech 与business 的匹配。我认为SOA 是企业架构模式，就像MVC 呀Layers 呀是软件架构模式一样。 所以并不是所有软件都能采用SOA架构的，SOA架构是解决企业软件中整合问题的一种方式。相信有人要争论，说我把SOA的作用局限在“整合”太不革命了，其实未来的业务创新绝大部分会发生在企业间的整合业务上，理解了这一点，就看出我也不是“很不革命”哈哈。 SOA 重视业务的敏捷性，没有合适的biz arch 其实施很难保证成功。其中的“服务”是一种大粒度的component，立足与现实世界而不是计算机世界。
问：通常，对不熟悉的人来说，谈到软件架构设计会给人以工程浩大之感，只有大企业才需要。对于目前我国众多中小型软件企业来说，软件架构设计有何意义？软件架构在现代软件产业中究竟扮演着什么样角色？[2007-6-8 15:50:00]
嘉宾[温昱]: 无论企业大小，包括往往出自一人之手的共享软件，都应该重视需求创新和架构设计。 孟岩等朋友都强调，中国软件产业应重视行业软件，非常赞同！这就必须贴近业务、需求创新、不断做细做深、并能及时根据行业趋势进行调整，而架构正是变化的关键。某红极一时的共享软件小不小？就是因为架构问题，在竞争中渐渐失败了。
问：读者问题：温老师能否对我们处于程序员行列的这类人给一些建议，如何规划做到软件架构这一阶段[2007-6-8 15:49:00]
嘉宾[温昱]: 多实践，多思考，每个项目都往两方面钻研： 1. 深。背后的技术原理，通了，才可以再次用到新工作中。 2.系统。比如http://www.vckbase.com/document/viewdoc/?id=487，呵呵。
问：6） 您能对刚从程序员升任为架构师的朋友说几句吗？有没有“头三个月秘笈”之类的建议呢？[2007-6-8 15:45:00]
嘉宾[温昱]: 建议有，秘笈称不上。 ★要掌握架构设计方法。比如功能需求如何影响架构、可扩展性等开发期质量需求如何影响架构、性能等运行期质量需求如何影响架构？其实约束性需求最危险，根本不是大多数朋友所理解的“直接遵守的需求”那么简单，其背后往往藏着许多功能和质量需求必须分析挖掘出来。 ★总的架构设计过程是：需求分析、领域建模、确定关键需求（含非功能需求）、概念性架构设计、实际架构设计、架构验证。 ★其次，要学会做减法，踌躇满志者常做的是加法。“需求决定架构”是不错，但时间有限、且需求变更变化频繁，所以架构师往往不可能深入分析所有需求，因此应采用“关键需求决定架构”的策略。
问：读者问题：初入架构设计行列，必须要掌握哪些工具和哪些方面的基本功呢？[2007-6-8 15:43:00]
嘉宾[温昱]: 最重要的工具是思维工具：比如非功能需求设计方法论、比如不同种类的需求对架构设计截然不同的影响、比如多视图架构设计方法（众多名著说其为归档方法是买椟还珠，多视图方法是很重要的架构思维方法）。 另：UML应掌握、设计模式、架构模式、OOD进阶等。
问：读者提问：我还是问关于敏捷的问题.敏捷提倡只考虑眼前的问题;而架构则需考虑到日后的维护,扩展性等.这不是冲突吗?[2007-6-8 15:40:00]
嘉宾[温昱]: 这也正是业界反对“某些agile方法”的重点。我喜欢敏捷中的重构，但架构设计应当被重视。另外XP里也不是完全没有架构设计，但太简单了，隐喻就是“概念性架构”设计。概念性架构很常见的，比如那个web server的三个角色的图……
问：读者提问：温老师的译作，.net平台的框架与实现 中谈的框架是不是就是软件的一种架构实现呢？[2007-6-8 15:37:00]
嘉宾[温昱]: 框架定义：可以通过某种回调机制进行扩展的软件系统或子系统的半成品。 框架分不同种类，一种分类是：系统框架and子系统框架。《应用框架的设计与实现》是系统框架，将一个B2B系统的架构设计方案框架化了。
问：读者提问：跟Martine fowler的《企业架构模式》比较起来，您认为您的书处于什么位置?[2007-6-8 15:35:00]
嘉宾[温昱]: Martin Fowler的模式，处于架构模式 与 设计模式 之间。 我的《软件架构设计》更重视讲“如何做”（比如如何将非功能需求细化至场景、从场景到设计决策）。 我的书重点有二：一是一种易于实践的架构设计系统化方法，而是希望给程序员提供一本向架构师过渡的参考书。
问：读者提问：架构设计的视图主要涉及哪些方面，哪些是必要的？[2007-6-8 15:30:00]
嘉宾[温昱]: ★建议从2架构视图开始：逻辑架构和物理架构相分离的设计方法在软件实践中比较常用。逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。 ★建议向5架构视图过渡（因为复杂时部署和并发应分离……）：逻辑架构视图、开发架构视图、运行架构视图、物理架构视图、数据架构视图。构成每个架构设计视图的元素不同，这些不同的元素撑起了不同的思维空间，从而使每个架构视图重点覆盖不同种类的需求。最终，所有架构设计视图所表达的语义综合在一起，就构成了软件架构设计方案。
问：许多程序员都搞不清楚架构（Architecture）和框架（Framework）是怎么回事，您能谈谈吗？[2007-6-8 15:27:00]
嘉宾[温昱]: 一句话，框架是软件，架构不是软件。软件架构不是软件，而是关于软件如何设计的重要决策，是超越算法与数据结构一级的设计。框架是一种特殊的软件，是可以通过某种回调机制进行扩展的软件系统或子系统的半成品。 ★框架的智慧在于：为了追求重用所带来的价值量最大化，将容易变化的部分封装成扩展点，并辅以回调机制将它们纳入框架的控制范围之内，从而在兼顾定制开销的同时使被重用的设计成果最多。 ★第一，现在的软件开发越来越倚重框架的使用，因此选择何种框架、每个框架在整个架构中处在什么位置，都成为软件架构设计的重要环节。 ★第二，当使用来自第三方的框架作为某一级系统或子系统的架构基础时，则应当仔细研究其结构——这是因为此时是使用它的结构、而不仅仅是服务。
问：读者提问：现在做系统的时候经常遇到多种数据库操作的问题，怎样处理多种数据库的问题？[2007-6-8 15:25:00]
嘉宾[温昱]: 首要原则，重用。如果是OLTP则借助ORM屏蔽数据库差异是一个选择。 另外，不同DB是同时使用还是非此既彼，以此决定要支持的变化是运行期还是开发期的。。。。
问：读者提问：一个现有的比较庞大的系统，各部分的设计和实现都不很统一，规范，如果重新考虑统一的架构实现，问现实吗，会存在哪些困难？[2007-6-8 15:22:00]
嘉宾[温昱]: 务实地谈：我感觉你说的这个系统是集成系统。此时，比较现实的是把各（子）系统之间的交互接口和交互机制重新统一设计。
问：读者问题：请问SOA架构的松耦合度底,那是不是意味者业务层全部使用接口+工厂实现[2007-6-8 15:20:00]
嘉宾[温昱]: SOA的架构中，service 和 event 是核心，它们都必须是业务概念。这才是经典的SOA架构。 现在SOA很热，但它是一种企业架构模式，不是软件架构模式，请大家当心误用。一定是做企业应用的朋友才考虑是否采用SOA架构。
问：读者提问：对一个大型的网站系统，子项目很多，如何考虑一个好的软件架构设计呢？[2007-6-8 15:17:00]
嘉宾[温昱]: 架构是分层次的：这个大型网站要进行统一的架构规划，比如互操作性必须在这里考虑；而不同子项目可以有自己的架构。
问：那么，程序员如何才能成长为架构师呢？[2007-6-8 15:15:00]
嘉宾[温昱]: 首当其冲的是思维突破。我常说“忘却是一种能力”，永远局限在OOP层面思考的方式必须突破。 然后是掌握更多新能力。足够的编程技能不能使程序员“自动”成为架构师，因为有太多编程之外的问题要考虑。比如如何确定对架构关键的需求子集，如何运用多视图方法设计架构，架构设计要进行到什么程度……。相应的很多新技能要求也有很多。（纯属广告：《软件架构设计》第三篇共9章都在讲程序员成长问题） 总结为：更系统的掌握技术、更高的把握大局的能力、更多的经验。
问：《程序员》技术主编孟岩在一篇文中谈到他认识的优秀架构师都具有多年实践开发经验，是不是架构师必须会编程呢？[2007-6-8 15:14:00]
嘉宾[温昱]: 两方面。 第一，架构师会编程才能将架构设计落到实处，不会在架构设计和详细设计之间留下“缝隙”。研究需求、设计架构、具体开发……这是太多人早已习惯了的思维模式，于是重视为需求而设计忽视为开发人员考虑。其实，相信大家都熟悉“架构为不同涉众考虑”的观点，每种基于多视图的架构设计方法中都不会忽略“开发实现视图”。 第二，也不是说，架构师必须是每个项目所用具体某种语言的高手。“编程功力”更关键，而且架构师必须有“忘却”的能力，突破编程层面过多的细节来思考。
问：项目经理如何履行项目架构职能,有没有一个可以循序渐进的路线呢?[2007-6-8 15:13:00]
嘉宾[温昱]: 你说的项目经理兼任了架构师角色是吗？我建议的总的架构设计过程是：需求分析、领域建模、确定关键需求（含非功能需求）、概念性架构设计、实际架构设计、架构验证。 需求分析架构师能曾与最好，而领域建模建议由架构师领导领域专家等完成，确定关键需求是“主动”应对需求变更的策略（而且架构设计往往没有太多时间），概念性架构设计是技术无关层面的设计，实际架构设计采用多视图架构设计方法。
问：软件架构师在整个软件开发环节中处于什么地位？其关键作用是什么？[2007-6-8 15:09:00]
嘉宾[温昱]: 架构师负责架构设计，并参与架构原型的实现，到开发全面铺开以后，还要指导开发、协调冲突。 可以回顾架构出现的背景：“需要进行超越算法和数据结构一级的设计，以适应软件规模和复杂性的增长。”因此，一股脑将复杂性统统展开，则软件开发将陷入混乱和无法控制之中。先进行架构设计、后进行详细设计和编码实现，运用了“基于问题深度分而治之”的理念，利于控制复杂性。。。
问：读者提问：就现有的系统，如果不重构，或者代价很少的情况下，怎么使之总体性能最优化[2007-6-8 15:08:00]
嘉宾[温昱]: 如果不进行架构级重构，可分析现有架构背后的“职责模型”，找出最耗时的职责，进行缓存、负载均衡、硬件提升（垂直可伸缩性）等考虑。
问：您的新作《软件架构设计》是国内第一本深入讨论架构设计问题的专著，我发现这本书非常强调非功能需求设计方法论，第7、10、13、15章都讨论了非功能需求的话题，那么为什么非功能需求对架构设计如此重要呢？[2007-6-8 15:06:00]
嘉宾[温昱]: 非功能需求是最重要的“架构决定因素”之一。反观业界，失败或推倒重写往往不是因为功能没实现而是非功能质量太差。 非功能需求大致分为质量属性和约束两大类。质量属性是软件系统的整体质量品质——所谓整体品质，就是它往往和大多数功能都有关，而不是仅仅表现在某个功能“内部”。 为了满足性能、持续可用性等运行期质量方面的要求，架构师必须深入研究软件系统运行期间的情况，合理划分系统不同部分的职责，权衡轻重缓急，并制定相应的并行、分时、排队、缓存、批处理等设计决策。而要满足可扩展性、可重用性等开发期质量方面的要求，则要求架构师深入研究软件系统开发期间的职责划分、变化隔离、框架使用、代码组织等情况，制定相应的设计决策。 架构师不能仅盯着功能需求，忽视非功能需求会导致架构设计失败。
问：需求变更有规律吗？[2007-6-8 15:05:00]
嘉宾[温昱]: 被动的对需求变更进行管理是不够的，需求变更有一定的规律，大家多实践总结，就会发现更多。我提几点：质量属性往往很稳定，比如银行系统多少年来强调持续可用性。易变的是功能需求！继续深入分析，“结息”作为银行系统的用户级需求，不会受到利息税率改变的影响……最终发现是行为需求（对应与用例规约）易变，而笼统的用户需求稳定，至于组织级的业务需求就更稳定些。
问：读者提问：做系统的时候经常会遇到需求改变的情况，你是怎么处理这个问题的？[2007-6-8 15:01:00]
嘉宾[温昱]: 关键需求决定架构。Len Bass指出：“功能、质量和商业需求的某个集合‘塑造’了构架。”
问：读者提问：我想问一下,构架如何与敏捷结合?[2007-6-8 14:59:00]
嘉宾[温昱]: 架构要满足不同方面的需求，功能需求、运行期质量属性、开发期质量属性、约束等。所谓系统的敏捷性，属于运行其质量属性，但它往往是一组其他属性的组合：可重用性、易理解性、可测试性、可扩展性（弹性）。 至于作为过程的agile，我比较重视领域建模。
问：读者提问：1.软件开发人员和构架师在职责上有什么主要区别？[2007-6-8 14:55:00]
嘉宾[温昱]: 更加情况不同，架构师要担负的职责可能包括：领导并负责架构设计；实际参与架构原型的开发实现；讲解架构，指导开发，协调冲突；支持项目经理，如技术可行性、任务划分、人员招聘；了解所在组织的业务目标，令架构更好地支持业务目标；评估新技术并提出采用建议。 而开发人员的职责，其实不是一刀切的：1. 有经验的架构师会让开发leader参与架构，这样他们后期对架构的认可度更高。2. 开发者应有能力负责相关详细设计。 3. 软件蓝领的说法很可笑。
问：读者提问：现在流行的主要有哪几种系统架构？[2007-6-8 14:50:00]
嘉宾[温昱]: 借此机会，我谈谈大家可能对C/S、三层C/S、以及B/S架构可能存在的误解。上述仅是架构设计的一部分，是部署架构视图。确定了这些之后，还有很多架构设计工作要做。 至于现在流行什么，SOA算比较热的。但是，所有实践者必须区分软件架构 和 企业架构（Enterprise Arch）。 软件架构关注的是：软件。EA 关注的是：tech 与business 的匹配。我认为SOA 是企业架构模式，就像MVC 呀Layers 呀是软件架构模式一样。 所以并不是所有软件都能采用SOA架构的，SOA架构是解决企业软件中整合问题的一种方式。相信有人要争论，说我把SOA的作用局限在“整合”太不革命了，其实未来的业务创新绝大部分会发生在企业间的整合业务上，理解了这一点，就看出我也不是“很不革命”哈哈。
问：读者问题：做系统的架构有什么好的辅助工具和规律？[2007-6-8 14:47:00]
嘉宾[温昱]: 关于工具，两句话：1. 架构设计不可能被工具代替。 2. 借助平台或工具，对架构有帮助，原因在于平台往往提供了“缺省的架构实现”，我们应根据具体项目来看平台推给我们的架构是否合适。 关于规律，我想说几点最佳实践：多视图的架构设计方法。要满足性能、持续可用性等方面的需求，架构师必须深入研究软件系统运行期间的情况、制定相应的设计决策，这些需求被称为软件的“运行期质量属性”。而要满足可扩展性、可重用性等方面的需求，则要求架构师深入研究软件系统开发期间的情况、制定相应的设计决策，这些需求被称为软件的“开发期质量属性”……基于多视图的架构设计方法恰好可以帮助软件架构师完成上述工作。
问：读者提问：请问该如何测试一个软件架构是否合理?[2007-6-8 14:43:00]
嘉宾[温昱]: 测试与评审并重。 通过开发架构原型，重点验证运行期质量属性（如性能）。通过评审确保功能需求能够被满足。如果不是团队熟悉的领域，通过评审确定运行期质量属性往往有太多“臆测”成分。
问：读者提问：做好一个系统架构要做到哪些方面？[2007-6-8 14:38:00]
嘉宾[温昱]: 足够的编程技能不能使程序员“自动”成为架构师，因为有太多编程之外的问题要考虑。比如如何确定对架构关键的需求子集，如何运用多视图方法设计架构，架构设计要进行到什么程度……。 当然，首当其冲的是思维突破。我常说“忘却是一种能力”，永远局限在OOP层面思考的方式必须突破。
问：tianjiahe172839的读者问:需要设计人员有怎样的基础才能够进行软件架构设计呢?[2007-6-8 14:37:00]
嘉宾[温昱]: 简单而言：更系统的掌握技术、更高的把握大局的能力、更多的经验。
嘉宾[温昱]: 国家的软考当中，有软件设计师，但对应于高级开发工程师。
[2007-6-8 14:36:00]
问：软件架构师主要工作是什么？软件架构应该处在开发的哪个阶段？[2007-6-8 14:34:00]
嘉宾[温昱]: 架构师负责架构设计，并参与架构原型的实现，到开发全面铺开以后，还要指导开发、协调冲突。设计早期分为：概要设计，模块设计。现在对应于：架构设计、详细设计。架构设计出于开发前期，是大规模团队开发的基础。
问：温老师，您的职业经历涉及金融、航空、电信、多媒体、中间件平台等众多领域，能结合您的体会谈谈什么是软件架构设计吗？[2007-6-8 14:31:00]
嘉宾[温昱]: 好。从面向业务的需求，到最终的面向技术的软件系统，要跨越很大的鸿沟。软件架构设计就是要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。
嘉宾[主持人]: 我们的聊天现在正式开始！
[2007-6-8 14:28:00]
嘉宾[温昱]: 大家好！我是温昱，很高兴一起讨论软件架构的话题。
[2007-6-8 14:27:00]
嘉宾[主持人]: 聊天马上就要开始了！各位网友下午好！我是大家的老朋友落落，本期活动的主持人。今天博文视点和CSDN有幸请到温昱老师，他是资深咨询顾问，CSAI特聘高级顾问，软件架构专家，软件架构思想的传播者和积极推动者
[2007-6-8 14:26:00]
嘉宾[主持人]: CSDN 博文视点名家讲坛第12期活动，温昱先生与您畅谈软件架构设计。活动时间是6月8日14：30~16：00。
[2007-6-8 9:44:00]
问：温老师，您好！您现在在上海吗？[2007-6-8 9:35:00]
嘉宾[温昱]: 是啊。您好。
- 上一篇：外星人与NB(N为自然数，B暂时无定义)
- 下一篇：当婊子也要立个好牌坊
