虚拟研讨会：件架构文档.doc

软件架构文档是企业应用开发过程中的重要一环，理解一个项目中的架构文档的关键是理解它在项目生命周期中所扮演的角色。一个项目产生架构文档的根本原因是为了交流、分析、记录和保存（比如，跟踪决策过程使之不会随着时间而流失）。一个项目产生的架构文档的数量和类型应当反映该项目为了创造产品所需的交流及分析。 架构文档在 有多少需要更多的文档用来交流管理。 架构文档的交流部分包括与管理层，开发者们沟通和在软件生命周期中的交流。分析需求可能来自为了决定产品的质量（包括性能，安全，可靠性等）的内部原因或来自如兼容某些规则或标准的需求。 在InfoQ希望能从 回答我 Len Bass，SEI的高，《Software Architecture in Practice》和即将面世的《Documenting Software Architectures: Views and Beyond》的第二版 的作者之一。 Grady Booch，IBMHandbook of Software Architecture》的作者。 Paulo Merson，SEI的高，《Documenting Software Architectures: Views and Beyond》的作者之一。 Eoin Woods， Barclays Global InvestorsSoftware Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives》作者之一。 在使用敏捷和精益SCRUM，极限 Len：架构文档的作用并不因 文档并不是唯一的交流方法，在敏捷中如SCRUM或XP面理 在敏捷方法中，所减少的文档是面 Grady： Paulo： 架构文档捕捉BDUF）。更深 敏捷的。 因此 多一些 设计只要足够编程即可 图表中多使参考已有的架构（或设计模式的应用方式）。具有相似特性或流程的设计可以用很少的文档，因为解决方案能够从参考的设计那里推断出来 使用概 设计图被划掉而不是更新，这样好过保留过时的设计。如下图是我经常使用的一个可视化标记 Eoin：可能听起来很明 一个架构描述，如同任何可交付的 我个人来什……也 一个好的 还有一点值得提到的是架构描述会有很多种形式，在敏捷团队中厚厚的文档常常是有效性最低的那个。重要的是在wiki，模型，数据 当基于DSL（ Eoin：我DSL，但是我不而且 Len：如果DSL语言，概要文件和原型，额外的建模语言以及元模型等定义了符号（有的有，有的没有），那么他们会有助于使文档更加简明。如果读者和作者都理解这些额外符号的话就能够减少成本。 Grady：不是的，任何描述 Paulo：架构文档包括多个体的 用DSL并不影响 部署DSL使得架构中的模(或者叫代)视图更明显，这个视图显示了实现单元，它们如何在模块和子模块中组织的，以及它们之间不同的关联和依赖。在任何一个视图中，标识出描述各种元素的类型很重要。DSL规定了良好定义的的一组元素类型和关系。特别是当DSL和其他也 DSL经常和自动化工具，类库或代码生成器一同出现。因此明确实现的范围及哪些是由工具实现的也很重要。上下文结构图会有所帮助。当使用代码生成器的时候，要确保生成了哪一类的运行元素以及它们的属性。找出是否单进程/线程，使用何种通信协议，使用什么数据存储机制以及访问质量相关方面，比如安全，性能和互操作性等。我曾经参加用Microsoft Visual Studio定DSL模型的演示 ，很DSL你也可以用一个通用的建模UML来UML概要文件UML符号衍生来的定 新的Java模(比如OSGi)的哪些方面符合 Paulo：行Servlet，DLL等其它 JMS，SOAP，http，本地或 现在让我来解释清楚你的问题。如果你在架构一个OSGi应用程序，你应该理解在OSGi运行OSGi经验是开发一个Eclipse插件，它有点OSGi框架的意思，你只需要manifest）文件。 但OSGi应用程序架构师们一些问题： 你的架构文档体java包/ 在运行 对于以上任何一种方式，你的文档都列明了这些线程吗？ 每一次服务调用都创建一个新的线程实例吗，类似于每一个http请求同一个servlet的多 如果我想要部署一个被多个包jar文件，文档里能知道我 OSGi的-订阅机制发送的事件是同步的还是异步的？ 你的运行http） 文档体 第一部分的答案是 第二部分的答案是是一些 替 组件复制 组件可选的包含（插件和附件） 构建 类似于OSGi的框架 架构文档OSGi可能是运行 Eoin：任何--参OSGi并且看起来它解决了OSGi这样的模块技术只是帮助展示了架构结构的一种，而在实践中，还