Software Architecture Document

Software Architecture Document Version: <1.0> Date: < yyyy-mm-dd >

[参考：ADMEMS方法推荐使用序列图，建议少用、甚至杜绝使用协作图。下图为一个序列图的示例。]

Page 9 of 18

Software Architecture Document Version: <1.0> Date: < yyyy-mm-dd >

5.3

重要设计包

[内容：对重要子系统的设计进行“灰盒”级描述。]

[意义：“每个子系统在架构设计中都应保持黑盒子”的观点，过于理想化了。对于业务层、通用协作机制而言，经常需要在架构设计期间就引入“灰盒”级描述。] [参考：类图和灰盒包图，在本节中较多出现。下图为一灰盒包图示例。]

Page 10 of 18

Software Architecture Document Version: <1.0> Date: < yyyy-mm-dd >

6. 开发架构视图

[关注点：此架构设计视图的关注点是程序单元组织。]

[注意：此架构设计视图是必须的、不应“剪裁”掉的。但实际情况却是，很多架构师不关注开发架构视图，导致很多程序开发人员抱怨“架构师就知道高来高去，架构对编程工作没什么指导性”。]

6.1 Project划分

[内容：本节说明整个系统将划分成哪几个Project来开发，其中，Project指开发环境所感知到的“工程”。]

[意义：基本好处是，有利于开发的组织；而对一些大型的集成系统而言，由于同时涉及了Web应用、桌面应用、嵌入式应用等软件形态，所以此时Project划分其实是不得不做的；最后，我们推荐核心代码应主动地切分到单独的Project以进行独立的软件配置管理（SCM），以降低核心代码外泄的风险。]

[参考：Project划分必然是属于“架构设计”的工作，严格来讲仅靠“需求分析”划分的业务域（Business Area）直接映射到Project经常意味着工作内容的遗漏。其实，业界不少有见地的专家已经认识到WBS（工作分解结构）做得太早太草率危害很大，就与“Project划分不到位”不无关系。]

6.2

Project 1

[内容：对Project划分后的每个Project进行目录结构、程序单元组织、框架与应用关系的说明。]

Page 11 of 18

Software Architecture Document 6.2.1 Project目录结构指导

Version: <1.0> Date: < yyyy-mm-dd > [内容：关于该Project一级目录、二级目录等基本目录结构的约定。]

[意义：为团队并行开发提供必要基础，让不同程序小组看到自己应该负责的程序目录。] [参考：不要把所有程序目录的约定都定义得太细，否则这份《架构文档》就要天天更新了。]

6.2.2

程序单元组织

[内容：源码、程序库、框架、目标码等类型程序单元之间的编译依赖关系。]

[意义：或许有人认为这没什么技术含量，但架构设计本来就不是只关心技术含量最高问题的。君不见，很多软件工程师跳槽到新的企业之后，竟然连一个能正常编译源码的开发环境都建不起来——其实，他们“不知道Project所依赖的Library有哪些”是其中重要原因——这本应在《架构文档》中给出明确描述的。]

6.2.3

框架与应用之间的关系（可选）

[内容：框架（Framework）。]

[意义：既然不适用Framework的开发越来越少了，既然程序员犯的很多错误都和对

Framework理解不到位有关，架构师就有责任明确说明Framework和待开发系统之间的关系。]

[参考：下图描述了JGraph框架和待开发应用的关系。]

[参考：下图描述了Struts框架和待开发应用的关系。]

Page 12 of 18