简介 我们都见过许多书籍和文章，其中的一张图试图捕捉系统架构的要点。但仔细查看这些图上显示的一组框和箭头，就会发现它们的作者已经努力在一个蓝图上表示比它实际能够表达的更多内容。这些框代表正在运行的程序吗？还是源代码块？还是物理计算机？还是仅仅是功能的逻辑分组？这些箭头代表编译依赖关系吗？还是控制流？还是数据流？通常它包含所有内容。架构是否需要单一的架构风格？有时，软件架构会因为系统设计过早地对软件进行分区，或者过分强调软件开发的某个方面而受到损害：数据工程、运行时效率、开发策略和团队组织。通常，架构也无法解决所有“客户”（或南加州大学称之为“利益相关者”）的顾虑。这个问题已被多位作者指出：Garlan & Shaw 1 、CMU 的 Abowd & Allen、SEI 的 Clements。作为一种补救措施，我们建议使用多个并发视图来组织软件架构的描述，每个视图解决一组特定的顾虑。