《软件架构设计》温昱 电子工业出版社
1
第4章 软件架构视图
王建民 mcswjm@mail.sysu.edu.cn 2010年1月20日
本章将讨论"软件架构视图"这一主题:
2
首先,说明在没有软件架构视图概念的情况下, 实践中所面临的一些问题; 之后,讨论软件架构师到底为谁而设计的话题, 说明软件架构师必须充分考虑来自用户,客户, 开发人员和管理人员的需求和限制; 然后,阐述软件架构视图的概念,并讨论逻辑架 构和物理架构——这是最为常见的两种软件架构 视图; 最后,通过一个实际案例说明逻辑架构和物理架 构师如何知道架构设计的.
4.1 呼吁软件架构视图
3
在现代的软件开发中,软件架构是进行团队开 发的基础,因此兼顾不同角色视角的多重架构 视图方法是必不可少的.
4.1.1 办公室里的争论
4
办公室里,关于什么是软件架构,争论正酣. 程序员说,软件架构就是要决定需要编写哪些类,使用哪些现成框架. 程序经理说,软件架构就是模块的划分和接口的定义. 系统分析员说,软件架构就是为业务领域对象的关系建模. 配置管理员说,软件架构就是开发出来的以及编译过后的软件到底是个 啥结构. 数据库工程师说,软件架构规定了持久化数据的结构,其他一切只不过 是对数据的操作而已. 部署工程师说,软件架构规定了软件部署到硬件的策略. 用户说,软件架构就是决定一个个功能子系统如何划分. 大家想了想说,这些架构视图好像我们都需要啊,软件架构师哭了. …… 上述争论可以总结为一句话:不同涉众看待软件架构的视角是不同的.
4.1.2 呼吁软件架构视图
5
由于软件架构概念是高度抽象的,所以在软件架 构概念与实践之间,似乎存在某种"鸿沟"——即 缺失某种概念,而这种概念可以"连接"软件架构 的概念和实际的开发实践的需要,为不同涉众理 解和交流架构提供更专一的视角. 这个概念就是本章要讲的主题:软件架构视图.
4.2 软件架构为谁而设计
6
为用户而设计; 为客户而设计; 为开发人员而设计; 为管理人员而设计;
4.2.1 为用户而设计
7
每套软件都会提供这样或那样的功能,正是这些 功能帮助用户实现他们在工作或生活中的特定目 标.用户所需的功能和系统本身的结构一定是相 互影响的,这正是软件架构师要特别关注的.
图4-1
生活中的例子:功能与结构相互影响
4.2.1 为用户而设计
8
用户要功能,用户也要质量; 用户所需的功能和系统本身的结构一定是相互影响的; 对软件系统而言,用户需求是千差万别的,所采用的软件架构必须和所 要提供的功能相适应; 诸如性能,易用性等软件质量属性,并不像上述的软件功能那样直接 帮助用户达到特定目标,但并不意味着软件质量属性不是必需的—恰 恰相反,质量属性差的软件系统大多都不会成功; 用户在使用软件系统的过程中,其关心的质量属性可能包括易用性, 性能,可伸缩性,持续可用性和鲁棒性等
架构为用户而设计,不仅满足用户要求的功能,也要达到 用户期望的质量.
4.2.2 为客户设计
9
有时,客户不一定是最终用户.例如,对超市销售系统而 言,客户是,某家连锁超市(的老板),而用户则是超市 收银员和上货员. 架构师必须为客户而设计:充分考虑客户的业务目标,上 线时间的要求,预算限制,以及集成需要等,还要特别关 注客户所在领域的业务规则和业务限制. 架构师应当直接或(通过系统分析员)间接地了解和掌握 上述需求及约束,并深刻理它们对架构的影响,只有这样 才能设计出合适的软件架构.合适的才是最好的.
4.2.3 为开发人员而设计
10
软件的可扩展性,可重用性,可移植性,易理 解性和易测试性等非功能需求,都属于"软件开 发期质量属性"之列,它们都将深刻影响开发人 员的工作,使开发更顺畅抑或更艰难. 瀑布模型习惯模式造成软件开发的负面影响 因此,软件架构师必须牢记:关注"软件运行期 质量属性",为开发人员而设计.
4.2.4 为管理人员而设计
11
软件变得越来越复杂,单兵作战不再是普遍的 软件开发方式,取而代之的是团队开发; 团队开发反过来使软件开发更加复杂,因为这 样不仅仅要面临技术复杂性,还有管理复杂性 问题; 要理清并管理不同开发人员之间的协同工作关 系,就应该搞清楚开发人员各自负责的软件模 块之间的关系—而后者正是软件架构的使命, 这使得软件架构自然而然成为开发管理的基 础;

下一页