架构设计学习心得
 

2009-10-22 作者:David Wu 来源:mindward.com

 

在软件和软件密集型的系统工程领域,架构设计(Architecture Design)是最近才浮现的一个技术领域。虽然建筑行业中,建筑师(Architect)作为受到普遍认可的一个专业角色,已经存在了几百年了。可是在软件领域,架构师(Architect)的角色还总是存在模糊和不确定性,多数人并没有一个清楚的概念,架构是什么?架构师应该具备什么样的技能?架构设计的工作流程和工作内容是什么?成果如何表达?架构设计都应该满足那些标准?这些也都是我本身存在疑惑或不清晰的问题,经过大量的阅读和搜索,这些问题的答案逐步浮现在我的大脑中,形成了一幅思维地图(mindmap),虽然目前还没有上升到能够整理架构设计知识体系的高度,但是在架构设计的众多研究成果中理出一些头绪还是有能力的。下面就给出一个建议的学习过程。

架构的定义

首先,想了解什么是架构,可以研究一下ANSI/IEEE1471-2000 Recommended Practice for Architectural Desccription of Software-Intensive Systems. 标准,其中给出了一些基本概念的元模型(请参考下图)和这些概念的定义。

Class_Diagram__IEEE_1471-2000__IEEE1471.jpg

A system is a collection of components organized to accomplish a specific function or set fo functions.

系统是为完成特定的功能或功能集合而组织起来的组件的集合。

The architecture of a system is the system's fundamental organization, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.

系统的架构是系统组件的基本组织形式,它们之间的以及和环境之间的关系,以及指导其设计和演化的原则。

An architecture description is a collection of artifacts that document an architecture.

架构描述是为用文档描述架构而得到的一组工作成果的集合。

Stakeholders are people who have key roles in, or concerns about, the sytem: for example, as users, developers, or managers. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals,teams, or organizations (or classes thereof).

利益相关人是那些具备关键角色,或关心系统的人,例如:用户,开发人员,或管理者。在系统中,具备不同的角色的不同利益相关人会有不同的关注点。利益相关人可以是个人,团队或组织(或一类组织)。

Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system's functioning, development, or operation, including considerations such is performance, reliability, security, distribution, and evolvability.

关注点是在系统中对利益相关人重要的兴趣点,并且决定系统的可接受性。关注点可能会涉及到系统的任何方面,功能性,可开发性,或可操作性,包括确认如性能,可靠性,安全性,分布式特性,和可发展性等。

A view is a representation of a whole system from the perspective of a related set of concerns.

视图是从相关的一组关注点投射的整个系统的一个表示。

In capturing or representing the design of a system architecture, the architect will typically create one or more architecture models, possibly using different tools. A view will comprise selected parts of one or more models, chosen so as to demonstrate to a particular stakeholder or group of stakeholders that their concerns are being adequately addressed in the design of the system architecture.

为了捕获或表示系统架构的设计,架构设计师一般会创建一个或多个架构模型,可能用不同的工具。视图由这其中选择出来的一个或多个模型组成,选择这些模型是为了展示个一个或一组利益相关人,以便他们的关注点在设计系统架构的过程中获得了主够的关注。

A viewpoint defines the perspective from which a view is taken. More specifically, a viewpoint defines: how to construct and use a view(by means of an appropriate schema or template); the information that should appear in the view; the modelling techniques for expressing and analysing the information; and rationale for these choices(e.g., by describing the purpose and intended audience of the view).

视点定义了获得视图的角度。更精确的说法是,视点定义了:如何构造和使用视图(通过指定模式或模板);那些信息应该在视图中出现;表达和分析信息的建模技术;这样选择的理由(比如描述视图的目的和目标客户。)
 

 

学习架构设计的阅读建议

其次,想了解架构的分类和设计方法学,可以研读一下TOGAF(The Open Group Architecture Framework)。其所推崇的架构设计方法学ADM(Architecture Development Method)对于了解架构如何落实到实现是很好的指南。同时,该文档也对多种架构设计框架(Architecture Framework),模式(Patterns),标准(Standard)等相关知识给出了很好的应用指南。以此为索引,就可以有针对性的学习和了解感兴趣的专题了。

学习架构设计,需要注意把架构分成三个层面,分别是:业务层面(Business Layer),更多的关注企业环境,使命等宏观决策,有其特定的方法和框架,比如:Zachman Framework, E2AF,RM-ODP等;应用层面(Application/Appliance Layer), 更多的关注一个具体的项目或产品的设计,比如:Siemans 4 Views, SEI View and Beyond, Rational 4+1 Views等方法和框架就更适用;技术层面(Technology Layer), 更多的关注技术实现方面。关注的层面不同,就有不同的称呼。这方面的内容在TOGAF和RM-ODP中都给出了很好的参考模型。多数技术出生的人会更容易关注技术架构方面的内容,而实际上,需要学习和理解的,更应该是企业架构和应用架构方面的内容。具体的论文请参考《Concepts for Modelling Enterprise Architectures》,该文章对架构的分层表述给出了有益的探讨。

应用架构或软件架构方面,国内已经有一些出版物,包括:《实用软件体系结构 Applied Software Architecture》 - Christine Hofmeister, Rober Nord, Dilip Soni 著,从西门子的工业实践中总结架构设计的经验,值得研读。《软件架构编档 Documenting Software Architecture: Views and Beyond》- Paul Clements, Felix Bachmann, Len Bass 等著,体现了SEI对大型复杂系统的设计经验总结,并给出了例子,可惜国内翻译的实在是不好,中文水平实在一般,比如中文标题,我以为翻译成《编写软件架构文档:视图及其他》会更适合一点。内文的翻译质量就更对不起读者了,犯了国内技术书籍的通病,只见中文,不见原来的术语,实在不知道某个概念的精确定义是什么,建议有能力的,还是读原文好了。对于喜欢穷根究底的人,可以研读一下《A Survey of Software Architecture Viewpoint Models》,对架构框架之间的比较就可以略知一二了。

总结

对指导实践来说,目前较完整的框架还是RUP,具备完善的模板,网上已经有大量的资源,这里就不赘述了。熟悉RUP的基本概念和流程,应该是架构设计最基本的要求了。如果对上面提到的概念有疑惑的地方,请善用google。

更新:架构设计的知识索引图和多种方法论整合的元模型

在学习架构设计的过程中,为了方便理解不同方法论和标准化文档中的基本概念和这些概念之间的联系,曾经用UML为建模工具,为这些概念建立了元模型(请参考附件中的Magic UML格式的元模型点击下载文件),碰巧有朋友表示对这个模型有兴趣,就从中摘录一些图片,帮助大家对模型的内容有所了解,以便判断是否有必要下载。

KnowledgeMap

KnowledgeMap.jpg

MethodologyModel

methodology_metamodel.jpg

MethodologyModel with SPEM and Project Concept

methodology-concepts.jpg

大家在参考模型的时候需要注意,这个模型仅仅反映了我个人学习的经历,供大家在学习的时候有一个借鉴,但是并不保证严谨和正确,“模型是对现实世界的简化,所有的模型都是错的,但是,有些模型是有用的。”

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。

资源网站: UML软件工程组织