软件体系结构(01)

(个人复习自用)

绪论

软件危机

原因:用户需求不明确;缺乏正确的理论指导;软件规模越来越大;软件复杂度越来越高

软件体系结构

  • 概念:由一定形式的结构化元素组成(是构件的集合,包括处理构件、数据构件和连接构件)

处理构件负责加工数据,数据构件代表被加工的信息,连接构件负责组合连接不同的构件

  • 研究内容:项目规划、需求分析、软件设计、软件实现、测试与评审、维护与升级
  • 设计原理:抽象-封装、模块化-注意点分离、耦合和内聚、接口与实现分离、分而治之、层次化

软件体系结构建模

建模原因
对系统进行可视化,规约系统的结构或行为用于指导构建系统的模版,将设计决策等形成文档

软件体系结构建模种类

结构模型
核心是体系结构描述语言。
这种方法用体系结构的构建、连接件和其他概念来刻画结构,通过结构来反应系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质等。

框架模型
类似于结构模型,相较于描述结构的细节,更侧重于整体的结构。
主要以一些特殊问题为目标,建立只针对和适应该问题的结构。
动态模型
是对结构或框架模型的补充,研究系统的“大颗粒”的行为性质。例如,描述系统的重新配置或演化。
动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程。
过程模型
研究构造系统鹅步骤和过程。
结构是遵循某些过程脚本的结果。
功能模型
认为体系结构是由一组功能构件按层次组成,下层向上层提供服务。
可以看做是一种特殊的框架模型。

基于视图的体系结构建模

视图,一组架构元素及其关联关系的表示,由系统相关者编写和读取,但并非涵盖了所有架构元素(架构元素:软件或硬件中存在的一组实际元素)

分解视图
显示与“关联的子模块”相关联的模块
使用视图
显示与“使用”关系相关联的模块
分层视图
显示被划分为相关和连贯功能的模块组,每个组代表整体结构中的一个层
类/泛化视图
类的模块,通过关系的“继承”或“实例”关联
进程视图
显示通过通信、同步和排除操作连接的进程或线程
并发视图
显示组件和连接器,其中连接器代表“逻辑线程”
共享数据(存储库)视图
显示创建、存储和访问持久数据的组件和连接器
客户–服务端视图
显示协作的客户端和服务器以及它们之间的连接器
部署视图
显示软件元素及其对硬件和通信元素的分配
实施视图
显示开发、集成和配置控制环境中的软件元素及其到文件结构的映射
工作分配视图
显示模块及其如何分配给负责实施和集成它们的开发团队

4+1视图模型

包括逻辑视图、进程视图、物理视图、开发视图和场景视图

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

在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题
领域。这种分解不但可以用来进行功能分析,而且可用作标识在整个系
统的各个不同部分的通用机制和设计元素。
在面向对象技术中,通过抽象、封装和继承,可以用对象模型来代表逻
辑视图,用类图来描述逻辑视图。
逻辑视图
逻辑视图中使用的风格为面向对象的风格,逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

开发视图
也称模块视图,侧重于软件模块的组织和管理。

开发视图要考虑软件内部的需求,如软件开发的容易性、软件的重用和
软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。
开发视图通过系统输入输出关系的模型图和子系统图来描述。
开发视图
在开发视图中,最好采用4-6层子系统,而且每个子系统仅仅能与同层或
更低层的子系统通讯,这样可以使每个层次的接口既完备又精练,避免了
各个模块之间很复杂的依赖关系。
设计时要充分考虑,对于各个层次,层次越低,通用性越强,这样,可
以保证应用程序的需求发生改变时,所做的改动最小。开发视图所用的风
格通常是层次结构风格。

进程视图
侧重于系统的运行特性,关注一些非功能性的需求。

进程视图强调并发性、分布性、系统集成性和容错能力,以及从逻辑视
图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作
具体是在哪一个线程中被执行的。
进程视图可以描述成多层抽象,每个级别分别关注不同的方面。在最高
层抽象中,进程结构可以看作是构成一个执行单元的一组任务。它可看成
一系列独立的,通过逻辑网络相互通信的程序。它们是分布的,通过总线
或局域网、广域网等硬件资源连接起来。
进程视图

物理视图
物理视图主要考虑如何把软件映射到硬件上,它通常要考虑到系统性能、
规模、可靠性等。解决系统拓扑结构、系统安装、通讯等问题。

当软件运行于不同的节点上时,各视图中的构件都直接或间接地对应于
系统的不同节点上。因此,从软件到节点的映射要有较高的灵活性,当环
境改变时,对系统其他视图的影响最小
物理视图

场景视图
场景可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来,
从某种意义上说场景是最重要的需求抽象。在开发体系结构时,它可以帮
助设计者找到体系结构的构件和它们之间的作用关系。同时,也可以用场
景来分析一个特定的视图,或描述不同视图构件间是如何相互作用的。
场景可以用文本表示,也可以用图形表示。

体系结构的核心模型
在这里插入图片描述
体系结构的生命周期模型
在这里插入图片描述

软件体系结构描述方法

统一建模语言UML

支持模型化和软件系统开发的图形化语言,为软件开发有阶段提供模型化和可视
化支持,包括由需求分析到规格,到构造和配置,侧重于面向对象。

优点:采用面向对象方法,更能反映软件体系结构的本质特征。提供多个视图直
观地反映体系结构元素所具有的功能和特征、可以通过类图、包图反映体系结构
的静态特征、协作图序列图反映体系结构的动态特征。
缺点:缺少形式化的描述方法,造成设计人员由于对软件认识的角度方法不同,
生成的体系结构描述也不同,理解上存在二义性。

特点:
UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点,从而有效的消除了各种建模语言之间不必要的差异。
UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发,而且对并行、分布式系统的建模尤为适宜。
UML是一种建模语言,而不是一个开发过程。
用途:
需求分析、面向对象类设计、行为设计和分析、代码自动生成。

UML结构

构造块

事物

结构化元素
•类、接口、协作、用例、组件、节点
行为元素
•交互、状态机
分组元素
•包、子系统
其他元素
•注释

关系

•依赖
•关联
•泛化
•实现

事物与关系
在这里插入图片描述
类的属性

  1. 属性的含义
    属性(attribute): 描述类所表示事物的静态性质。
    2.属性的格式
    [可见性]属性名[:类型][=初始值][{特性}]

用例之间的关系
在这里插入图片描述
状态机
在这里插入图片描述
带接口的构件
在这里插入图片描述

部署图中的节点
在这里插入图片描述
包和包间的关系
在这里插入图片描述
关联表示法
在这里插入图片描述
泛化表示法
在这里插入图片描述
实现关系
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
公共机制

说明(Specification):规定了对于每一个UML图形的文字说明的语法和语义。
修饰(Adornment):对UML元素加上各种修饰,说明该元素最重要特征之外的其他方面的细节特征。
通用划分(Common Division):UML的模型元素有两种划分,即型-实例、接口-实现。
◦ 型-实例:是一个通用描述符与单个元素项之间的对应关系,如类与对象的划分、数据类型与数据值的划分;
◦ 接口-实现:接口声明了一个约定,而实现则负责执行接口的全部语义。
扩展机制(Extensibility):允许UML的使用人员根据需要在不用改变基本建模语言的情况下自定义一些
构造型语言成分。
◦ 约束(constraint)扩展了UML构造元素的语义,它是用文字表达式表示的语义限制。
◦ 标记值(tagged value)扩展了UML构造元素的特性,它是附加到任何模型元素上的命名的信息块。
◦ 构造型(stereotype)扩展了UML的语汇,它是在一个已定义的模型元素的基础上构造的一种新的模型元素。

语义规则

语义规则(Rules):用于建立语义一致、与其他模型协调的良好模型。
◦ 命名(Name):为事物、关系和图起名;
◦ 范围(Scope):给一个名称以特定含义的语境;
◦ 可见性(Visibility):如何使一个名字被外部识别和使用,它包括public(公
共)、protected(保护)、private(私有)三种可见性;
◦ 完整性(Integrity):事物如何正确地、一致地相互联系;
◦ 可执行性(Execution):运行或模拟动态模型的含义是什么。

模块内连接语言MIL

MIL是将一种或多种传统程序设计语言模块连接起来描述软件体系结构的方法。
模块可能需要导入/导出各种资源
MIL的编译器通过进行模块间的类型检查来保证系统的完整性
特点:语义比较丰富,但局限于实现级别,层次较低、语义精确、极少形式化基础。

软件体系结构描述语言ADL

architecture description language, ADL
参照传统程序设计语言的设计和开发经验,重新设计、开发和使用针对软件体系结构特点的专门的软件体系结构描述语言。

由于ADL是在吸收了传统程序设计中的语义严格精确的特点基础上,针对软件体系结构的整体性和抽象性特点,定义和确定适合于软件体系结构表达与描述的有关抽象元素,因此,ADL是当前软件开发
和设计方法学中一种发展很快的软件体系结构描述方法.

其三个基本元素是:构件、连接件、体系结构配置

Components
◦ Primitive building blocks
Connectors
◦ Mechanisms of combining components
Abstraction
◦ Rules for referring to the combination of components and connectors

软件体系结构风格

describes a class of architectures(描述一类体系结构)
independent on the problems(独立于实际问题,强调软件系统中通用的组织结构)
found repeatedly in practice(在实践中被多次应用)
a package of design decisions(是若干设计思想的综合)
has known properties that permit reuse(具有已经被熟知的特性,并且可以复用)

经典体系结构风格

构件和连接件的类型是什么?
可容许的结构模式是什么?
基本的计算模型是什么?
风格的基本不变性是什么?
其使用的常见例子是什么?
使用此风格的优缺点是什么?
其常见的特例是什么?

在这里插入图片描述
在这里插入图片描述

数据流风格 Data flow

Components: data processing components(基本构件:数据处理)
Interfaces are input ports and output ports(构件接口:输入端口和
输出端口),Input ports read data; output ports write data
Computational model: read data from input ports, compute, write
data to output ports (计算模型:从输入端口读数,经过计算/处理,
然后写到输出端口)

Connectors: data flow (stream) ( 连接件:数据流)
Unidirectional, usually asynchronous, buffered (单向、通常是异步、有
缓冲)
Interfaces are reader and writer roles (接口角色: reader 和 writer)
Computational model (计算模型 : 把数据从一个处理的输出端口
传送到另一个处理的输入端口)

batch sequential (批处理)

  • sequential processing steps, run to completion
    pipe & filter (管道-过滤器)
  • incremental transformation of streams
    process control(过程控制)
  • looping structure to control environment variables
    Components (processing steps) are independent programs
    基本构件:独立的应用程序
    Connectors are some type of media traditionally tape
    连接件:某种类型的媒质
    Topology: Connectors define data flow graph
    连接件定义了相应的数据流图,表达拓扑结构

调用/返回风格
主程序/子程序Main Program and Subroutine
面向对象风格Object Oriented

封装:限制对某些信息的访问
•Interaction: Via procedure calls or similar protocol
交互:通过过程调用或类似的协议
•Polymorphism: Choose the method at run-time
多态:在运行时选择具体的操作
•Inheritance: Shared definitions of functionality
继承:对共享的功能保持唯一的接口
•Reuse and maintenance: Exploit encapsulation and locality to increase productivity
复用和维护:利用封装和聚合提高生产力

层次结构Layered

  • 两层 C/S 结构
  • 三层 C/S 结构
     B/S 结构(浏览器 服务器风格)
  • 正交软件体系结构

独立构件风格
进程通讯 communicating-processes
事件系统 event system
在这里插入图片描述

虚拟机风格
解释器 Interpreters
基于规则的系统 Rule based systems

数据为中心风格

异构风格

各种系统构建模式之间不仅有联系,而且在很多情况下它们往往是配合使用的。
即面对一个实际系统,很难判断它究竟是A型,还是B型,亦或者是C型,单纯的把它归到任何一型都是很勉强的。
这样的系统可以称为复合型系统,这样的系统风格就称为异构风格。

异构架构是几种风格的组合,组合方式 可能有如下几种:
(1)使用层次结构。一个系统构件被组织 成某种架构风格,但它的内部结构可能是 另一种完全不同的风格。
(2)允许单一构件使用复合的连接件。

优点:
选择异构架构风格,可以实现遗留代码的重用。
在某一单位中,规定了共享软件包和某些标准,但仍会存在解释和表示习惯上 的不同。选择异构架构风格,可以解决这 一问题。
缺点:
不同风格之间的兼容问题有时很难解决

  • 23
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值