软件架构设计

  软件架构概述

  软件架构是具有一定形式的结构化元素,即构件的集合,包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把架构的不同部分连接起来。软件架构是软件设计过程的一个层次,这一层次超越计算过程中的算法设计和数据库设计。架构问题包括总体组织和全局控制、通信协议、同步、数据存取,给设计元素分配特定功能,设计元素的组织,规模和性能,在各设计方案间进行选择等。软件架构处理算法与数据结构之上关于整个系统结构设计和描述方面的一些问题,如全局组织和全局控制结构、关于通信、同步与数据存取的协议,设计构件功能定义,物理分布于合成,设计方案的选择、评估与实现等。

  软件架构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中,“软件外部的可见性”是指软件构件提供的服务、性能、特性、错误处理、共享资源等。对于复杂系统和大型系统的开发而言,设计好软件架构是保证软件质量的根本措施。具体来说,软件架构具有以下作用:

  (1)软件架构是项目干系人进行交流的手段。

  (2)软件架构是早期设计决策的体现。

  (3)软件架构是可以传递和可复用的模型。

  软件架构建模

  设计软件架构的首要问题是如何表示软件架构,即如何对软件架构建模。根据建模的侧重点不同,可以将软件架构的模型分为5种,分别是结构模型、框架模型、动态模型、过程模型和功能模型。

  (1)结构模型:这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件(connector)和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质等。研究结构模型的核心是架构描述语言。

  (2)框架模型:框架模型与结构模型类似,但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。

  (3)动态模型:动态模型是对结构模型和框架模型的补充,研究系统的“大颗粒”的行为性质。例如,描述系统的重新配置或演化。动态可以指系统总体结构额配置、建立或拆除通信通道或计算的过程。这类系统是激励型的。

  (4)功能模型:该模型认为架构是由一组功能构件按层次组成,下层向上层提供服务。他可以看作是一种特殊的框架模型。

  Kruchten在1995年提出了一个“4+1”的视图模型。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每个视图只关心系统的一个侧面,5个视图结合在一起才能反映系统的软件架构的全部内容。

  (1)逻辑视图(logic view):主要支持系统的功能需求,即系统提供给最终用户的服务。

  (2)开发视图(development view):也称为模块视图(module view),主要侧重于软件模块的开发和管理。

  (3)进程视图(process view):侧重于系统的运行特性,主要关注一些非功能性的需求,例如系统的性能和可用性。

  (4)物理视图(physical view):主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。

  (5)场景(scenarios):可以看作是那些重要活动的抽象,它使四个视图有机联系起来,从某种意义上说场景是最重要的需求抽象。

  软件架构风格

  软件架构设计的一个核心问题是能否使用重复的架构模式,即能否达到架构级的软件重用。也就是说,能否在不同的软件系统中,使用同一架构。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式(idiomatic paradigm)。架构风格定义了一个系统家族,即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解,软件架构风格定义了用于描述系统的术语和一组指导构件系统的原则。

  通用架构风格分类如下:

  (1)数据流风格:批处理序列,管道/过滤器。

  (2)调用/返回风格:主程序/子程序,面向对象风格,层次结构。

  (3)独立构件风格:进程通信,事件系统。

  (4)虚拟机风格:解释器,基于规则的系统。

  (5)仓库风格:数据库系统,超文本系统,黑板系统。

时间: 2024-10-10 05:55:02

软件架构设计的相关文章

SoC嵌入式软件架构设计之四 :内存空间规划分配

本文继续阐述基于低端控制器CPU的SoC固件架构设计.第一节 SoC嵌入式软件架构设计之一:系统内存需求评估 讲述了系统内存需求的评估.这一节讲述内存空间的具体规划分配.CPU有两种体系结构:哈佛结构和冯诺依曼结构.哈佛结构是一种将程序指令存储和数据存储分开的存储器结构,如80251,代码空间与数据空间完全分开,独立编址:冯诺依曼结构是一种将程序指令存储器和数据存储器合并在一起的存储器结构,如MIPS,ARM等,其代码和数据空间是统一编址.这里就以冯诺依曼体系结构为例. 一.嵌入式系统软件分层

软件架构设计的目的

软件架构设计的目的简单说就是在保持软件内在联系的前提下,分解软件系统,降低软件系统开发的复杂性,而分解软件系统的基本方法无外乎分层和分割.但是在保持软件内在联系的前提下,如何分层分割系统,分层分割到什么样的粒度,并不是一件容易的事,这方面有各种各样的分解方法,比如:关注点分离,面向方面,面向对象,面向接口,面向服务,依赖注入,以及各种各样的设计原则等, 耦合可以分为以下几种,它们之间的耦合度由高到低排列如下: (1) 内容耦合:一个模块直接访问另一模块的内容,则称这两个模块为内容耦合. 若在程序

软件架构设计系列总结

架构引用维基百科:软件体系结构是构建计算机软件实践的基础.与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础.从和目的.主题.材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟.一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计.软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作.逻辑和流程.软件

SoC嵌入式软件架构设计之三:代码分块(Bank)设计原则

上一节讲述了在没有MMU的CPU(如80251.MIPS M控制器系列.ARM cortex m系列)上实现虚拟内存管理的集成硬件设计方法,新设计的内存管理管理单元要实现虚拟内存管理还需要操作系统.代码分块(Bank)的支持,详见SoC嵌入式软件架构设计之二:没有MMU的CPU实现虚拟内存管理的设计方法.这里要阐述Bank设计的一些原则. Bank设计是为了实现不同时刻运行的Bank(代码块)运行在同一块内存上,所以在运行之前操作系统需要将已存在内存的代码/数据进行缓存处理,并加载将要运行的Ba

软件架构设计箴言理解

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 今天和师弟聊天聊到他们项目开发,有些同事总是提前考虑性能优化,需求变更又是一大堆的重写,让我想起了Donald Knuth 提到的:对软件的过早地优化是万恶的根源.这里就简单的说几条重要的软件名人哲学. 1:软件中唯一不变的就是变化. 在软件开发过程中需求是不停的变化,随着客户对系统的认识,和现有开发功能和软件的认识,也许以开始他提出的需求就是背离的.记得网上有一句笑话,师说需求变化的: 程

软件架构设计学习总结

软件架构设计就是软件系统的'布局谋篇',是软件抽象发展到一定阶段的产物.软件设计人员学习软件架构知识,旨在站在较高的层面上,整体的解决好软件的设计,复用,质量和维护等方面的实际问题.本文以图形的方式进行总结归纳,从软件架构的描述,设计,风格,评价,形成方法进行阐述. 软件架构设计总述: 软件架构的概念 软件架构的意义 软件架构的风格 分层架构 面向服务的架构(SOA) 特定领域的架构(DSSA) 软件产品线 基于架构的软件开发(ABSD) 软件架构与质量属性 软件架构评估 -----------

敏捷开发下的软件架构设计与持续优化

过往的软件开发, 往往都是由架构师将他对产品的理解,利用 UML 来体现软件的架构设计. 这种方式的问题是:因缺乏使用者与团队成员间的互动参与,使得对外并未能完整的将使用者需求,映射到软件架构中; 而对内所提供的软件架构设计文档, 对实际开发的工作, 指导意义并不大(因为,厚重的架构设计文档,便如老太婆的裹脚布般:又臭又长).更严重的问题是,由于架构设计耗费太长的时间,如此再加上开发.测试的时间,团队往往会太晚才会发现软件架构上的重大缺陷.而由于太晚才发现软件架构上的缺陷,所以,软件架构上若需做

(转)软件架构设计

[一]-软件架构设计过程 软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考: 1.业务分析:针对目标行业的业务战略.蓝图.业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.他是一个系统组,同时明确各系统间的支撑关系. 3.系统功能设计:明确信息化系统功能列表及功能层次(层次,例如经验决策层工,管理层功能,业务操作功能等)

详细介绍软件架构设计的三个维度

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 架构设计是一个非常大的话题,不管写几篇文章,接触到的始终只是冰山一角,更多的是实践中去体会.这篇文章主要介绍面向对象OO.面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用. 架构设计有三个维度,或者说是我们在考虑架构时需要思考三个方向. 这三个维度分别为面向对象.面向方面.面向服务. 这三个维度可以看作是正交的,但不同维度会互相印证,互相支撑,整个架构的示意图如图所示. 面向

SoC嵌入式软件架构设计之七:嵌入式文件系统设计

嵌入式的系统区(system disk,SD)包括操作系统.驱动.中间件.应用和字库.UI资源等文件,本文讲述SD区的文件系统设计.文件系统最主要的目标是为了实现单个文件的定位和读写.因为一般代码都是不可自修改的,即量产之后不会有写操作,嵌入式系统的SD文件系统就是为了能够简单.高效地定位某个文件和读取文件中的数据.设计原则和要点有以下几方面: 1. 逻辑连续存储单个文件,以扇区对齐. SD区的单个代码和资源文件一般都不大,所以不必要像fat32文件系统那样用fat表把文件簇串起来,直接逻辑连续