软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
当你去了解一个东东的时候,第一步要做的,就应该去知道这个东东的定义,对于软件架构也是如此,经过网上查询和书籍的帮助,我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业,如果退回15年,估计没几个人知道‘软件架构’是什么,在上个世纪80年代,随着软件开发的规模不断扩大,软件开发成为一个行业,初期,随之而来的是越来越多的软件项目的失败,造成项目失败的原因很多,但主要集中在开发过程,所以软件工程应运而生,CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候,软件开发还是以数据结构+算法的形式存在,进入20世纪最后10年,随着面向对象技术、设计模式等在开发过程中的成功应用,软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营,分别描述如下:
’组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互
。它有两个非常明显的特点:
关注架构实践的客体——软件,以软件本身作为描述对象。
分析了软件的组成,说明软件不是一个‘原子’意义上的整体,而是有不同的部分经过特定的接口进行连接组成的一个整体,这对软件开发来说很重要。
‘决策派’认为
软件架构包含了一系列的决策
,主要包括:
软件系统的组织
选择组成系统的结构元素和它们之间的接口,以及当这些元素相互协作时所体现的行为
用于指导这个系统组织的架构风格:这些元素以及它们的接口、协作和组合
软件架构并不仅仅关注软件本身的结构和行为,还注重其他特性:使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
‘决策派’有以下两个显著的特点:
关注软件架构中的实体——人,以人的决策为描述对象。
归纳了软件架构决策的类型,指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策,还包括关于众多非功能性需求的决策。
按照‘组成派’的观点,软件架构关注的是软件整体的分割和交互,之所以分割,是因为不同的部分在逻辑或物理上相对独立,通过‘分而治之’的原则进行分割可以更好的理解整个系统,把握用户的需求,但是虽然整个软件可以分割成多个模块或子系统,但是模块和子系统之间的通信和交互也是很重要的,我想按照这种观点,架构师的主要任务是将软件分割成不同的模块,并定义模块之间的接口。
按照‘决策派’的观点,软件是一个在很多限制下产生的产品,这些限制包括用户和技术两方面,用户方面包括功能需求、性能需求、硬件需求等,技术方面包括技术选择、可扩展性、可重用性、可维护性等。我想按照这中观点,架构师的主要任务就是作出上述个各种限制作出选择或决策。《软件架构设计》 温昱