架构设计 摘录

 

高新企业为了生存，因此他们所依靠的软件必须能提供其所需的功能；所需的高质量；所承诺的可用性，和可接受的价格。

架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

 

系统是为实现某个（些）特殊作用的组件的集合。专用系统包括个人应用，传统概念上的系统，子系统，系统中的系统，产品线，产品系列，整个企业和其他利益集团。一个系统是为了实现一个或多个任务而存在。[IEEE 1471]

A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. [IEEE 1471]

 

环境决定了开发，操作，策略和其他影响系统的设置和条件。[IEEE 1471]

The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. [IEEE 1471]

 

任务是指系统为了实现对对象设置的使用或操作。[IEEE 1471]

A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. [IEEE 1471]

 

涉众是对于系统有利益关系或关注的个人，团队或组织。[IEEE 1471]

A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471]

正如我们所见，“组件”贯穿于这些定义。正如有意留下一个模糊的概念来解释，大部分架构定义没有提到“组件”，IEEE 1471也不例外。组件也许是逻辑上的或物理存在的，技术上独立的或特定的，规模大的或规模小的。由于文章的原因，我使用了UML 2.0规范的组件定义；并且我相当宽松的使用这个概念来包含各种所遇到的架构成分，包括了对象，技术组件（例如Enterprise JavaBean），服务，程序模块，遗留系统，包应用程序等。这些是 UML 2.0中对“组件”的定义：

[组件]是包括内容的系统模型部分，且它的显示是可替换的。组件定义了所需接口的行为。例如，组件类似类型(type)，它与所需接口行为一致。（包括静态和动态语义）

[A component is] a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics).

架构是对软件系统组织、结构部分和系统包含接口的选择，集合部分的特定行为，较大子系统部分的构成和架构风格的重大决定的设置。

An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. [Kruchten]

大部分定义都指出一个架构关注于结构和行为，仅关注于重要决定，可以与架构风格一致，受涉众和环境的影响，体现基于原因的决定。

--架构定义结构

   许多架构的定义不但承认了他们自己的结构元素，而且还有结构元素的组成，关系（任何连接部分都需支持这样的关系），接口。

--架构定义行为

   与定义结构元素一样，架构定义了这些结构元素的相互作用。这些作用可以实现所期望的系统行为。

--架构关注于重要元素

   当一个架构定义了结构和行为，它不会在意所有的结构和行为的定义。它只在意那些被认为是重要的元素。重要的元素是那些有持久影响的，例如结构部分的主要部分，与核心行为相关的元素，和对诸如可靠性和可测量性等重要品质相关的元素。总的来说，架构不关心这些元素的细节。架构的重要性还可以以经济的重要性来表达，因为某些元素的主要驱动者是创建的成本和变更的成本。

--架构可以平衡涉众需求

   架构是为了实现涉众的需要而创造的。但是，一般来说不可能满足所有的需求。不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是构建进程的主要方面，且妥协是架构的重要属性。

--架构基于基本原理体现决策

   An important aspect of an architecture is not just the end result, the architecture itself, but the rationale for why it is the way it is. Thus, an important consideration is to ensure that you document the decisions that have led to this architecture and the rationale for those decisions.

--架构可以符合一个架构样式

   架构风格的例子包括分布式的风格，管道和过滤器风格，数据中心风格，基于规则的风格等。

[架构风格] 按照结构组织的模式定义了系统。更具体的，架构风格定义了组件和连接型的语法，和连接的方法。

[模式] 是对于普遍问题的普遍解决方案。

--架构被其环境所影响

   影响架构的环境的因素包含架构所支持的商务环境，系统涉众群，内部技术限制（例如需要符合组织标准），和外部技术限制（例如对外部系统的接口或遵守外部规则的标准）

--架构影响团队结构

--架构呈现在每一个系统中

--架构拥有一个特定的范围

   我们会遇到诸如企业架构，系统架构，组织架构，信息架构，硬件架构，应用架构，基础设施架构等。你会见到其他类型的，每种类型都定义了一个架构的具体范围

 

 参考： http://www.ibm.com/developerworks/cn/rational/rationaledge/content/mar06/eeles/index.html

不知道你看的什么书，我发表点看法。
首先就architecture的定义存在很多种，当然大概的内涵都相通，但是并不相同。其中就环境是不是存在就是一个分歧。也就是有些学说认为环境本身就该被构架划分为一种概念化的组件，也就是说构架是组件及其之间关系的设计约束和结构约束。我更喜欢这种方式。
系统是使用构架为指导，应用组件组合而成体系。注意我确定不应该使用集合这词汇，这是因为集合意味着其内容均为被构架定义了的组件和其关联，而显然很多时候系统中还会存在某些其他东西。
环境如果也被构架定义为组件，或者至少被定义为组件的接口，那么系统的操作、设置、构建、作用将更加体系化。而同时我们也应可以得出结论，这个系统的操作、设置、构建则更加以我们的意图为主导，并且在理想条件下，其作用也就是我们的意图。而若不考虑意图，则此系统将无意义。
系统的任务，就是系统的需要完成的意图的解释。虽然构架很多情况下是面向对象的，但是确实存在非面向对象的构架，例如很多嵌入系统和大型关键应用的构架就是非面向对象系统的。而系统的任务简单的说，就是对组件以及其他构成进行的操作。
涉众这个概念非常复杂，其意义不仅仅在于利益相关人。实际上利益也存在构想中的利益和现实的利益。而关注系统并非是一个很明确的指标，比如我纯粹是为了某种学术理由关注某个系统，这个时候我是否需要被确定到涉众里面去就很需要我们去权衡。
实际上类似的问题在IEEE以提出构架这个概念，就已经被各个方面所争论了。而争论最核心的一些内容在于对组件的概念和看法。
首先组件是不是可以仅仅是逻辑存在就会产生巨大的设计思想的差别。强调组件必须是物理的一方认为，如果仅仅是一种模式，应该更加被认为是一种类似风格和设计思路的成分，也就是说组件和设计组件的思路应该区别看待。特别是存在多系统合作以及遗留系统的整合的时候，组件更加应该物理化，而其他系统和遗留系统则将被采取风格和设计思想进行包装为组件。这个时候风格和设计思想可以外化在构架之外，并且有单独的生命历程。而近一步的问题是，接口是否应该存在语义。如果存在语义，那么组件就可以被类型化，也就是存在元组件从而衍生实体化的业务组件。而若不存在语义，则业务组件是有元组件进行组合产生，继承性行为是被厌恶的。这点实际上是面向对象基础思想斗争的体现，可以算是信仰的斗争，但是其影响和意义是现实而明确的。
而进一步存在的问题是构架应该关注于结构和行为的多少。显而易见的关注结构越多，行为越少，则适应范围越宽。大家很容易理解JAVA和DOTNET本身就是一个构架，而使用同样的结构组件（比如流行的spring，MVC， Hibernate）可以构成多种面向不同领域应用的不同构架，并且就结构来说其相似性很大，但是就功能来说相似性很小。这一点在构架产生的初期就应该被明确，并且随着应用的进行不断的被修正。
而组织的构成成分等外在的非技术因素也是构架受到影响的要素。比如销售和市场人员的能力，就会影响组织构架的底层元素——喜欢B/S系统的人和C/S系统的人有很大的不同等等类似问题经常存在，特别是在国内销售人员往往会是决定性的。而同时成本的核算也是时时刻刻存在的，显然绝大多数的技术决策都能带来成本的影响，而市场竞争的结果的复杂性更加会造成重大的差异（我们不止一次的见到，低成本的形式不被某些人接受）。同时还存在法律和标准的约束问题。

实际上就Architecture这个词汇来说，存在众多不同的说法。我认为最重要的是要明确的选择自己的一套概念系统，使其更加适应自己所处的环境和个人爱好。而就目前的情况来说，这一点是必要和必须的。特别是在目前相关的理论和说法满天飞，如果你看的东西太多，而不去研究它们背后的定义和意图，就会迷失在一个词汇的酱缸里面。

架构设计的概念搞得自以为再明白，对你实际的设计也没有什么意义，大部人对架构的理解只是对目前已经存在的某种技术实体作合理化解释而已。

所谓名不正，言不顺。就目前来说搞清楚概念意义重大，因为你在实际中会发现，因为存在理解的差异性，交流的时候就会产生很多偏差。另外现在某些人喜欢故弄玄虚的玩文字游戏，使情况更加恶化。所以这个问题，要么不谈，要谈就要明确你自己究竟在说的是什么。

非常赞同，很多次关于结构设计的讨论，最终都演变成了互相询问：
"你说的架构是不是指这些............................."
"差不多，其实我的重点是这些....................."

看了你的这篇《科普工作的重要》http://ozzzzzz.javaeye.com/blog/61202，感觉确实如此，我们缺乏对概念的确切理解，但是在看您上楼发的那篇超长帖的时候，硬着头皮细细读也还是有些地方根本无法理解。
您做的项目很多吧应该，概念也是要在项目中去一点点体会的，等我们作的项目也和您一样多了，我们也一定会对那些概念顺手拈来吧。而现在苛求我们去充分理解那些概念，充其量也只能理解其表面而无法触及深处。

其实理解概念并非很容易的，但是也并非是非常困难的。其实我关心的为什么你会在这个时间这个环境下忽然关心起architecture这个东西来。我想这里肯定有现在这个词已经充斥各个技术社区，如果自己不了解点觉得不合适。另外是忽然发现构架设计师是个好发展方向，希望向此目标发展。这样的想法是现在的普遍状况。
但是我却希望分析一下这些概念背后的东西。第一就是我不管有多少种定义，我只关心构架师在企业中究竟在做些什么工作。第二如果我周围没有构架师，那么我心目中构架师的工作究竟是什么样子的。第三，做构架师究竟需要什么能力。第四，构架这个东西在自己的企业经营中究竟存在不存在，如果存在这个东西是咋产生的。如果不存在，又说明了什么问题。我觉得这些问题才是比较务实的。单纯的去读书，不如来联系一下实际。
其次我觉得现在有很多人在炒作构架这个概念，而且仅仅是单纯的炒作。他们给你一个列表，告诉你看什么什么书，做什么什么事情，暗示你只要做了就可以如何如何。其实你可以先看看这些人自己究竟在做什么，他们自己究竟是不是构架师，他们设计了几个构架。

说实际的，构架这个东西是和产品线，软件企业核心资产，组件，元组织，元组件等众多概念伴生的。如果你仅仅去看构架，那么你肯定无法真正的理解这个概念。而问题在于如何把这一系列的新概念，新问题都了解清楚，而且还要考虑你了解清楚了对自己究竟是有啥工作上的用途。当然我觉得如果就是单纯的求知，研究研究是很好的，中国缺乏这样的精神。问题在于很多人的出发点就是利益驱动的，而这些人大多数有太急于兑现。而既然利益驱动，那么就需要核算理解和学习这个系统需要化的代价。当然很多人其实就是为了显示自己多么知识渊博，多么紧跟潮流，多么现今。其实要是以这个为目标，你大可不必下功夫学习，自己搞点逻辑游戏会更加有效。

其实核心的问题，还是你是否已经有了一个比较完整的世界观和方法论。很多人都讨厌讨论哲学问题，更讨厌信仰。但是当在实际中，你就会发现其实信仰的力量和完整世界观的强大。只有在你已经有了这些系统的情况下，才可能不被别人带入一个逻辑的游戏，从而成为盲目的粉丝。当然教主总是会有，少你一个粉丝对他们影响不大。

学习这个的动机是因为要为项目写架构设计文档，看了很多资料，把好的并且理解起来很困难的东西作个笔记照抄下来。

项目是面向一个橡胶厂的基于web的ERP系统，没有商业的ERP那么多功能，只实现一些基本的。小组内我是领导者。

按照生命周期的说法，需求分析后应该做架构设计，很多小的项目一般不作架构设计，但是我们感觉架构设计里有很多可取的东西，所以也就写了。

但是到现在架构还是没有完全弄明白，网上谈论架构方面的资料不算多，很多都是在谈论架构师如何如何，但是生命周期中的架构设计和架构师的职责区别还是蛮大的。

请ozz*指教：
架构设计除了分工，订计划，声明规范----也就是创建一个真的Team,还要干什么？其他的事情能不能分到概要设计还有前面的需求分析中？

还有，我周围确实没有架构设计师，我们也只能照猫画虎到网上学习，还有跟大牛学。

还有你说的“其实理解概念并非很容易的，但是也并非是非常困难的。”后句话隐藏的什么意思？

你要做的是框架设计，而不是构架设计。可以这么简单理解，构架是框架设计的约束和思路。很少有为了一个项目而构建一个构架的情况，除非这个项目规模足够大，并且周期很长。其实如果你自己多思考一下，就会发现很多说的Architecture其实是在说Framework。
另外一个问题是，所谓的软件生命周期。其实这个本身不是啥问题，你之所以会有疑惑，我想可能是你才担任组织的领导工作不久，或者你才开始构建你的开发流程。实际上软件的生命周期描述，也存在多种模型，不同的方法论一般这个模型都是不同的，或者即使相同侧重点也不一样。你真正应该考虑的是选择一个比较容易理解（毕竟你理解了，才可能去要求其他成员理解，才可能让客户和管理者也理解），比较容易操作，适合你们自身情况的方法论。
而当你选择了一个方法论之后就会发现，这个方法论还不可能完全适合你们的情况，你还需要对它做补充或者裁剪。但是至少一个大的核心流程是已经建立的。在这个时候就需要建立起一种大家共同相信并且愿意遵守的原则，你可以把这些东西算做你们的软件开发信仰。
随后你就可以按照这个方法论的定义，划分角色，分配人员扮演不同的角色。然后将这些人划分到不同的工作流中间去。
然后就是设定跟踪和反馈，以及回放和回滚。制度化一些纪律。对管理和交流等事务性工作，做个安排。比如站立会议，周总结，计划研讨会等等。
这样按部就班下来，你就有了一个比较结构化的步骤流程了。

我想你也看出来了，我很多发言都是话里有话的。没有办法，我现在已经比较温和了，或者说我已经不会明火执仗的去骂人了。但是有些事情我确实心理难受，所以就只能假借给你的回答，自言自语的骂一些我看着讨厌的现象和人。你看不明白，这是因为我本身就不是骂你。哈哈，不必对这些东西太在意。

但是我想您没有看出来，我问你这个是想请您说说他们怎么很容易地理解的，传授我一点学习心得。

还有，如果是Framework的话，这一步也完全可以省略，因为我们做的时候完全可以用现成的。是吧

还有，ozz*的亲和力