搜索
PauloMerson谈基于UML2.0的应用架构编档作者SriniPenchikala译者王丽娟发布于2008年12月13日社区架构主题分享|应用架构编档是软件开发过程中的一个重要组成部分。PauloMerson最近谈到了架构编档在参考架构（RefenenceArchitecture，RA）处理中所起到的作用。他在软件开发最佳实践技术大会上做了演讲，谈论了架构应该收集哪些信息，UML2.0、BPMN及其它建模符号和准则又该如何用于架构表述。应用架构编档这一任务有助于架构师和开发人员评估架构，并用它来指导实现（设计和编码）。架构可以使用视图（View，也称为Viewpoint或Perspective）进行描述，视图表达一套系统元素及其关联关系。视图限制了其中元素的类型和关系的类型。架构师可在以下基础上使用多视图架构来考虑系统：系统如何组织为一套代码单元（模块视图）系统如何组织为一套具备运行态的元素（运行时视图）工件在文件系统中如何组织，系统又如何部署到硬件上去（部署视图）数据仓库的结构（数据模型）模块视图：这种视图从实现单元（模块及其之间的关系）的角度表明系统结构。模块视图是代码的蓝图。它们可用于估算、任务分配和跟踪，还有可变更性和影响分析。它们同样利于培养新的开发人员。运行时视图：也被称为组件与连接器视图，它们表现系统执行时的结构。这种视图包括具备运行态的组件（比如进行、线程、EJBs、Servlets、DLLs、对象、ASP.NET组件）、数据存储和复杂的连接器（例如队列和管道）等元素。它们也表明了交互机制，这些交互机制以不同的技术为基础，但至少应该区分本地调用和远程调用、同步调用和异步调用。运行时视图表明了组件如何在运行时交互，哪些组件被复制，还有哪些组件访问数据存储。它们也可用于运行时属性的分析，比如性能、安全和可靠性。部署视图：这种视图通常用来描述生产环境的硬件基础设施和部署系统的目录、文件结构。部署视图有利于定义部署和操作过程（比如“自动更新”功能）、检查运行时错误、规划购买方案。数据模型：这表明了数据仓库的结构，数据仓库包括数据实体（持久化领域元素）及其关系。数据模型可用作物理数据库的蓝图，而且对数据访问代码的开发人员来说是很有用的参考。通过分析数据元素（比如索引和锁、SQL优化、可变更性影响分析、正常活动的输入），它们还可用于评估以数据为中心的系统的性能。Paulo还强调了系统行为编档的重要性。行为编档是对结构描述的补充。他提到了用于UML图的建模符号，例如时序图、交互图（以前在UML1.x中称为协作图）、活动图和状态机图（以前称为状态图）。诸如BPMN的一些其它符号也能用于记录系统的行为。他详述了编写软件架构视图的模板：基本介绍：用图形显示元素及其之间的关系。元素目录：说明基本介绍中描述的元素，该部分内容通常是一个带有元素名称和文字描述的表格。它也可能包含接口规范和行为编档。范围图示：显示系统的输入和输出（或是视图关注的系统部分）可变性简介：描述可变性机制，比如组件和连接器的复制，可选的组件和连接器包含物，不同的组件实现及参数值间的选择（构建时标志位、配置文件等）。在这一节中，变化多样的内容、变量及绑定时间（编译、构建、部署或运行时）的影响都应该进行记录。架构背景：该部分应该包括设计决策的基本原因（包括摒弃的相关替代方案）、分析结果、原型和实验、影响该视图的假设和约束，还有设计中使用的已知模式。相关视图：指向父视图或子视图。Paulo建议软件架构文档的大纲应该包括以下几个部分：文档路线图：路线图应该说明文档如何组织，应该包含对所用模板的引用，并包括文档的使用场景。系统概述：该部分应包含系统描述和系统目标。它可能指向存放于其它位置的整体系统文档中的系统概述。需求：这应该包括系统的需求。它可能指向一个单独的需求文档。架构相关的三种需求是：功能需求（可记录为用例或用户故事）、质量属性需求（性能、可用性等）和设计约束。视图：应该包括描述软件架构的所有视图。视图间的映射：该部分显示了针对选中的一对视图，一个视图中的元素如何映射到另一视图中的元素。架构分析及基本原因：跨视图设计决策的基本原因（包括摒弃的替代方案），架构评估的结果（比如ATAM报告）需求到架构的映射：说明每个需求如何由架构中的一或多个元素，或一种架构方案来满足。文档应该包括一个术语缩略表。Paulo展示了一些为Duke银行应用创建的模型图，还有来自真实系统的其它设计图。他在演讲总结时，讨论了应用架构编档的其它几个重要方面，比如利益相关方的需要、参考架构、产品线体系结构（PLA）中的文档变异性。Paulo还说道，对一个成功的架构来说，完善、重构架构等工作和软件开发、实现阶段的一些架构实施类型都是很重要的。InfoQ与Paulo讨论了一下软件架构编档的现状和未来发展方向。UML概要文件和衍型对进行软件架构编档有何帮助？UML最初创建是用于OO系统的建模。现在则可用于任何类型软件系统的建模。这意味着它的普遍性，因此必须要非常灵活。UML衍型（stereotypes）是UML的一种扩展机制，允许为UML符号指定特定的含义。衍型允许你创建更富于表现力的图。比如说，一幅图中有一个（一般UML）连接器。如果你知道该连接器实际上是一个JMS队列，你可以将连接器衍型化为JMSqueue。你可以在一个UML概要文件中设置一套有意义的衍型。UML规范有一个针对JavaEE的概要文件、一个针对.Net的概要文件，还有其它的一些，这些都作为UML规范的附件而存在。重用或创建自己的衍型和概要文件是个很不错的主意。随着现今一些软件开发团队使用敏捷方法，软件架构师要怎么做才能在应用架构编档时保持敏捷和务实呢？敏捷开发意味着没有任何文档，这是一个普遍存在的误解。事实上，正如一项调查显示，敏捷团队与传统团队比起来更有可能进行建模。敏捷架构师（或许是任何软件架构师）都应该记住以下事情：敏捷项目中设计/建模的关键方面不是避免设计，而是避免“预先的大设计”（BDUF）。一般来说，高级别的架构策略应该预先制定出来，但许多设计决策和设计细节则可以留待需要时再进行。只生成能满足利益相关方需求的设计文档。准备好开始编码了，就立即把设计工作停下来。等到下一个冲刺时，再按需展开/完善已有的设计，以获取下一个冲刺的功能所要求的设计决策。如果没有更新设计的价值，就把它扔掉。一些设计图是用来指导实现的，但有时候代码与图最终是有出入的。如果你没有时间更新图来反映实现，与其维护过期的图，使以后的读者感到困惑，还不如将这些图删除。很多时候，草图就能解决你的问题了。不要花太多的时间用最新、最丰富的可用符号来绘制最精细的图。如果你只需要一个绘图工具，就不要再花太多的金钱去购买复杂的建模工具。在很多敏捷项目中，特别是那些小型、同地协作的团队，设计图的真正价值在于绘制，这迫使你去全面地考虑问题；一旦这些问题解决了，图就失去了它们的价值。很多时候，设计都是白板或纸上的一个草图。如果草图可以成功地将设计传达给团队，那么草图就可以作为架构视图的图形，为什么不这样做呢？SOA系统的架构编档有什么特别之处吗？SOA通常涉及到很多设计决策（SOAP与REST、ESB还是直接点对点、服务粒度、是否使用目录、是否使用BPEL、SSL还是消息级安全等更多）。每个设计决策都有多种选择。因此，理解并记录你做出选择的理由就很重要。去年我们编写了“评估面向服务的体系架构”，其3.3节还包含其它的一些考虑因素。你认为软件架构编档的未来怎样？软件架构学科远未成熟。每天都有杰出的软件架构师在创建巧妙的解决方案，但他们以不同的方式工作，他们创建不同的工件、使用不同的图表符号。我希望以后架构师新手能在学校学习到这些技艺，而不是在实战的尝试与错误中成长。这一教育的其中一部分就是学会用适当的方式来表现软件架构，供其他人员消费。软件架构教育有一些重要的良好态势：GradyBooch围绕软件架构手册所做的工作，还有SEI开发的刊物和课程。在软件架构编档领域，你能给架构师介绍一些最佳实践和“陷阱”的吗？使用多个视图来编档架构。总是为图添加上符号标记。如果你使用的是设计/架构模式，让读者知道这一点。采用模板。只创建对一些利益相关方有用的文档。编档并不意味着文件或Word文档。以Wikis为例思考一下。记录重要设计决定的理由依据。评审你的作品。