软件工程-原文链接：http://tech.it168.com/a2009/0902/672/000000672853.shtml
此文章详细给出了软件设计的基本概念和用途，文章链接：http://www.searchsoa.com.cn/showcontent_32604.htm
前言：
历史悠久的建筑科学具有成熟的工程方法论，可以给软件行业发展和软件工程学大量的借鉴。建筑设计(Architectural Design )是指建筑物在建造之前，设计者按照建设任务，把施工过程和使用过程中所存在的或可能发生的问题，事先作好通盘的设想，拟定好解决这些问题的办法、方案，用图纸和文件表达出来。Architecture一词（维基百科：Architecture）在软件工程学领域可译为软件体系结构，与此对应的还有FrameWork-软件框架。
Architecture最主要的Design Force就是处理变更。其次，所有可能的问题都是要在Architecture中考虑：复杂性、功能、性能、技术、所有非功能需要等等，FrameWork给出软件的主框架设计，服从体系结构的必然要求。
关于软件工程方面的论述有一些修改，如有疑问，请访问原作者.
一：区分度：
1、软件体系结构和框架的定义
软件体系结构的英文单词是“architecture”. Architecture的基本词义是建筑、建筑学、建筑风格。
软件体系结构虽然根植于软件工程，但还处于一个研究发展的阶段，迄今为止还没有一个为大家所公认的定义。
《设计模式》中对框架的定义是框架就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计。
软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架的作用在于：由于提取了特定领域软件的共性部分，因此在此领域内新项目的开发过程中代码不需要从头编写，只需要在框架的基础上进行一些开发和调整便可满足要求；对于开发过程而言，这样做会提高软件的质量，降低成本，缩短开发时间，使开发越做越轻松，效益越做越好，形成一种良性循环。
框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。框架不是“平台”，平台概念比较模糊可以是一种操作系统，一种应用服务器，一种数据库软件，一种通讯中间件等地那个，因此平台在应用平台主要指提供特定服务的系统软件，而框架更侧重了设计，开发过程，或者可以说，框架通过调用平台提供的服务而起的作用。
框架不是工具包或者类库，调用API并不就是在使用框架开发，紧紧使用API是，开发者完成系统的主题部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，二次开发人员只是像做填空一样，根据具体业务，完成特定应用系统中与众不同的特殊部分。
2、框架与架构之间的关系
框架不是构架（即软件体系机构）。体系结构确定了系统整体结构、层次划分，不同部分之间的协作等设计考虑。框架比架构更具体。更偏重于技术涉嫌。确定框架后，软件体系结构也随之确定，而对于同一软件体系结构（比如Web开发中的MVC），可以通过多种框架来实现。
3、框架与设计模式之间的关系
设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。
框架和设计模式存在着显著的区别，主要表现在二者提供的内容和致力应用的领域。
1)、从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。
2)、从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现；而框架则是设计和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。
3)、以第二条为基础，可以得出设计模式比框架更容易移植：框架一旦设计成形，虽然还没有构成完整的一个应用，但是以其为基础进行应用的开发显然要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用。
总之，框架是软件，而设计模式是软件的知识体，提升框架的设计水平。
二：框架的选择问题：
通用框架与应用框架：
如果要对框架进行进一步分类，则可以根据框架针对的领域是否具有通用性而将它们分为通用框架（General Framework）和应用框架（Application Framework）。通用框架可以在不同类型的应用中使用，而应用框架只被使用于某一特定类型的应用中。
比如，ORM框架NHibernate就是一个通用框架，该框架可以用于所有需要解决O/R映射的各种类型的应用中。而某个金融框架则是一个应用框架，它仅仅被用于金融类型的应用中。
可以这么说，通用框架所解决的是所有类型的应用都关心的“普遍”问题，而应用框架解决的是某一特定类型的应用关心的问题。所以，如果我们需要将某种类型的应用的核心业务逻辑流程提升到一个框架中，所得到的这个框架就是一个应用框架。与通用框架相比，应用框架需要了解更多目标业务领域内的领域知识。
在实现具体的应用程序时，可以采用一个应用框架与多个通用框架相结合的方式，这样有利于快速、高质量的应用程序开发。比如，某个金融领域的一个应用，可以采用金融框架作为应用框架来解决与金融业务逻辑相关的问题，采用Nhibernate解决数据访问，采用ESFramework解决应用中各分布式系统之间的通信。
下图描述了类库、框架和应用之间的层次关系。
艹！图呢？？？
当然，一个应用也可以完全不采用任何框架，而是直接从最基础的底层API（如.NET Framework）开始构建。对于微型的系统，这种方式或许可行。但对于复杂大型的应用，困难度就可想而知了。
（这便涉及了设计的方式问题，是由顶向下还是从底向上，如果是大型系统，最好是采用由顶向下的设计方法）
1 框架之于应用
当一个应用系统选定了框架之后，我们需要做的就是在框架提供扩展点的地方添加应用的具体逻辑，也就是使用“血”和“肉”来填充这个骨架从而得到一个“有机体”。
由于框架通常都是在实践中经过反复使用和检验的，所以质量有一定的保证，这使得我们用更少的时间、更少的编码来实现一个更稳定的系统成为可能。当然，框架也不是“银弹”，它不能解决软件复杂性的根本问题，但是我们却通过它向这个终极的理想目标又迈进了一步。
有一点需要注意，框架使得我们的系统在有所支撑的同时，它也给出了限制。因为通常当我们确定采用了某一个框架之后，我们就必须在这个框架限制的“框框”之内来构建我们的应用。大多数时候，这不是一个问题，但是如果因为框架的限制而严重影响了我们系统目标的实现的时候，我们就需要考虑是否应该放弃这个框架，或者换一个其它的同类型的框架。
但总的来说，框架的使用还是带给程序构建者很大的方便。
2 框架设计
框架使得我们开发应用的速度更快、质量更高、成本更低，这些好处是不言而喻的。然而，面对万千变化日趋复杂的软件需求，设计和实现一个高度灵活可复用的框架又谈何容易！
框架源于应用，却又高于应用。
框架往往是这样产生的：我们拥有了开发某种类型应用的大量经验，我们总结这种类型的应用中共性的东西，将其提炼到一个高的层次中，以备复用。这个“高层次”的东西便是框架的原型。随着我们经验的不断积累，框架也会不断地完善、发展。
框架是一个实践的产物，而不是在实验室中理论研究出来的。所以设计一个框架最好的方法就是从一个具体的应用开始，以提供同一类型应用的通用解决方案为目标，不断地从具体应用中提炼、萃取框架！然后在应用中使用这个框架，并在使用的过程中不断地修正和完善。
有一点需要特别注意，正如所有的软件架构设计的要点在于权衡（在这方面有点像艺术），框架的设计也不例外，正如前面提到，框架在为应用提供了一个骨架的同时，也给我们的应用圈定了一个框框，我们只能在这个有限的天地内来发挥。所以，一个好的框架设计应当采用了一个非常恰当的权衡决策，以使框架在为我们应用提供强大支持的同时，而又对我们的应用作更少的限制。权衡，从来就不是一件简单的事情，但是有很多框架设计的经验可以供我们参考。
2.1 框架设计经验、原则
（1）框架不要为应用做过多的假设！
关于框架为应用做过多的假设，一个非常具体的现象就是，框架越俎代庖，把本来是应用要做的事情揽过来自己做。这是一种典型的吃力不讨好的做法。框架越俎代庖，也许会使得某一个具体应用的开发变得简单，却会给其它更多想使用该框架的应用增加了本没有必要的束缚和负担。
（2）使用接口，保证框架提供的所有重要实现都是可以被替换的。
框架终究不是应用，所以框架无法考虑所有应用的具体情况，保证所有重要的组件的实现都是可以被替换的，这一点非常重要，它使得应用可以根据当前的实际情况来替换掉框架提供的部分组件的默认实现。使用接口来定义框架中各个组件及组件间的联系，将提高框架的可复用性。
（3）框架应当简洁、一致、且目标集中。
框架应当简洁，不要包含那些对框架目标来说无关紧要的东西，保证框架中的每个组件的存在都是为了支持框架目标的实现。包含过多无谓的元素（类、接口、枚举等），会使框架变得难以理解，尝试将这些对于框架核心目标不太重要的元素转移到类库中，可以使得框架更清晰、目标更集中。
（4）提供一个常用的骨架，但是不要固定骨架的结构，使骨架也是可以组装的。
比如说，如果是针对某种业务处理的框架，那么框架不应该只提供一套不可变更的业务处理流程，而是应该将处理流程“单步”化，使得各个步骤是可以重新组装的，如此一来，应用便可以根据实际情况来改变框架默认的处理流程。这种框架的可定制化能力可以极大地提高框架的可复用性。
（5）不断地重构框架。
如果说设计和实现一个高质量的框架有什么秘诀？答案只有一个，重构、不断地重构。重构框架的实现代码、甚至重构框架的设计。重构的驱动力源于几个方面，比如对要解决的本质问题有了更清晰准备的认识，在使用框架的时候发现某些组件职责不明确、难以使用，框架的层次结构不够清晰等。
2.2 如何称得上一个优秀的框架？
一个优秀框架的最主要的特点是：简单。这种简单性不是轻而易举就可以获得的，正如优秀的框架不是一蹴而就的，达到这种简单性需要对框架不断地抽丝、不断地提炼和完善。简单的真正原因在于它抓住了要解决的问题的本质。一个优秀的框架通常都具有如下特点：
（1）清晰的、简洁的、一致的。
“清晰”指的是框架的结构是清晰的、框架的层次是清晰明朗的、框架中各个类和组件的职责是清晰明确的。
“简洁”指的是框架中没有无关紧要多余的元素，而且各个类和组件的职责目标是非常集中的，这正是“高内聚、低耦合”设计原则的体现。
“一致”通常会带来这样的好处，框架的使用者在熟悉了框架的一部分后，会非常容易地理解框架的另一部分。“一致”通常体现在命名的规则一致、命名的含义一致、组件的装配方式和使用方式一致等。
（2）易于使用的
只有易于使用的框架才会走得更远。
正是因为易于使用，框架使用者们才有可能试用这个框架，在试用满意后才有可能决定采用这个框架。一个框架功能即使再强大，如果难以使用，那么框架使用者们很可能根本就不会有试用这个框架的念头。
框架的生命力源于框架一直在不断地完善和发展，如果没有人使用这个框架，这个框架便没有了发展和完善的源动力。正如友好的用户界面是优秀应用程序不可或缺的重要部分，易于使用也是优秀框架的一个重要特性。
（3）高度可扩展的、灵活的
框架通过高度可扩展性来应对应用程序的万千变化。
没有任何一个框架可以预料所有应用的需求，万能的框架是不存在的。企图设计、实现一个万能框架的想法是荒诞的。框架必须具有“以不变应万变”的能力，框架可以通过为应用预留恰当的、足够的扩展点来做到这一点。
框架的灵活体现在框架可以根据不同的应用进行不同的组装和配置，就像框架是专门为当前的应用所订制的一样。
（4）轻量的
“轻量”，说的通俗点，就是只为自己需要使用的服务付费，而不需要为自己不需要的服务买单。一个重量级的框架有一个很明显的特征就是，如果你需要一套完整的套餐服务，那是没有问题的，框架可以很好的满足你；但是，如果你只需要这份套餐中的一小块点心，对不起，框架仍然会强加一个完整的套餐给你，你必须付一整份套餐的费用。
优秀的框架应当支持使用者“按需所取”的原则，框架使用者可以随意“点菜”进行组装来满足自己的需求。
（5）弱侵入性的
所谓“弱侵入性”，采用了框架的应用程序可以尽可能的以普通的方式来编写应用逻辑，而不必为了适应框架不得不使用一些特殊的手法。
这可能有点难以理解，我们可以举个例子来简单说明。在.NET中，实现AOP（面向方面编程）机制的两种主要方式是使用Proxy和动态代理。使用Proxy实现的AOP框架通常要求那些需要使用AOP截获功能的类必须继承自ContexBoundObject；而采用动态代理实现的AOP框架则没有任何如此侵入性的要求，我们仍可以以最普通的方式来编写应用逻辑类，这类框架会在运行时根据配置动态地生成目标对象的代理对象来实现AOP截获。所以我们可以说，采用动态代理方式实现的AOP框架相比采用Proxy实现的AOP框架，具有更弱的侵入性。
弱侵入性意味着框架对应用逻辑的干扰更少，由于应用逻辑类都是普通的类，这非常方便应用逻辑在另外一个程序中复用，而另外的程序可能采用了一个完全不同的框架。
三：UML工程组织：http://www.uml.org.cn/rjzl/20044643.htm
软件质量之路（4）：建立核心框架
四：知识构架.学习系统
知识学习系统与软件构架有很大的相似性。如何有效的构建一个完整的学习框架是一个教育学者日夜探讨的问题，如果能发现其中的方法，或许能开始最有效率的学习，解决知识传承的困难。
知识的爆发性增长使其数量看似接近人的学习系统所能承受的极限。专家获得相当知识水平所需要的年限愈来愈长，而看似没有更好的方法来解决知识学习的速度问题。只能学习——构建完备系统——出现新问题——重构系统——再完备......如此循环，无穷无尽。