软件体系结构4
软件体系结构
软件体系结构引言软件体系结构是指在软件系统中，对系统整体结构进行组织和设计的过程。
一个合理的软件体系结构能够帮助开发者降低系统的复杂度，提高系统的可维护性和可扩展性。
本文将介绍软件体系结构的基本概念和常用的体系结构模式，以及如何进行软件体系结构设计。
软件体系结构的基本概念软件体系结构是一个抽象的概念，用于描述软件系统中各个组件之间的关系和交互方式。
它主要由以下几个基本概念组成：1.组件（Component）：组件是软件系统中的一个独立的功能单元，可以由一个或多个模块（Module）组成，实现特定的功能。
2.接口（Interface）：接口定义了组件之间的通信方式和消息传递方式。
一个组件可以提供多个接口供其他组件使用。
3.关系（Relationship）：组件之间的关系可以是依赖关系（Dependency）、关联关系（Association）、聚合关系（Aggregation）和组合关系（Composition）等。
这些关系将多个组件链接起来，形成一个组织结构。
4.架构风格（Architectural Style）：架构风格定义了软件系统的整体结构的模式和约束。
常见的架构风格包括层次结构（Layered）、客户端-服务器（Client-Server）、发布-订阅（Publish-Subscribe）等。
常用的软件体系结构模式在进行软件体系结构设计时，可以借鉴一些常用的体系结构模式。
下面介绍几种常见的模式：1.层次结构（Layered）：层次结构将软件系统划分为若干层，每一层负责特定的功能。
上层的组件可以调用下层的组件，反之则不行。
这种模式可以降低系统的复杂度和耦合度，提高系统的可维护性。
2.客户端-服务器（Client-Server）：客户端-服务器模式将软件系统划分为客户端和服务器两个部分。
客户端负责与用户进行交互，而服务器负责处理客户端的请求并返回结果。
这种模式可以实现系统的分布式部署，提高系统的可伸缩性。
软件工程中的软件体系结构
软件工程中的软件体系结构在数字化时代，软件应用的范围越来越广泛，软件开发的规模和复杂度也在不断增加。
为了应对这些挑战，软件工程师们不断探索各种技术，其中之一就是软件体系结构。
软件体系结构是一个抽象的框架，描述了一个软件系统的组成部分，它们之间的关系和通信方式，以及系统的行为。
在本文中，我们将深入探讨软件体系结构的概念、类型、优缺点和设计原则等重要内容。
软件体系结构的概念软件体系结构是软件系统的架构，它是一个抽象的、高级别的视角，描述了系统的组成部分、相互关系和行为模式。
一般来说，软件体系结构由以下元素组成：1. 模块：代码的意义单位，通常包含一组相关的操作和数据结构。
2. 组件：带有接口的模块，可以与其他组件进行交互和通讯。
3. 连接器：支持组件之间通讯和合作的构建块。
4. 数据：系统中的各种信息，包括文本、图像、声音等。
5. 环境：软件系统运行所依赖的硬件、操作系统和其他外部条件等。
软件体系结构需要注意的重点包括：1. 模块细分：将系统拆分成若干个小模块，每个模块都有自己的职责和功能。
2. 接口设计：设计良好的接口可以提供高效、可靠的组件通讯。
3. 模块复用：通过复用现有组件和模块，可以降低开发成本和时间。
软件体系结构的类型软件体系结构可以分为多种类型，下面将介绍几种常见的。
1. 分层式结构分层式结构是将系统分为若干层次的结构，每个层次都具有特定的功能和职责。
分层式结构最大的特点是分离了应用程序逻辑和界面，将系统的不同部分独立起来，使得开发更容易和灵活。
2. 客户端/服务器结构客户端/服务器结构是一种典型的分布式系统结构，它将应用逻辑和数据存储划分为服务器端和客户端两个部分。
客户端通过网络连接到服务器获取或存储数据，并在本地计算机上运行应用逻辑。
3. MVC结构MVC（模型-视图-控制器）是一种用于用户界面设计的软件体系结构。
在MVC结构中，模型是应用程序的核心组成部分，处理数据和业务逻辑，视图负责渲染用户界面，控制器负责协调视图和模型之间的通讯。
软件架构之四种类型简介
软件架构之四种类型简介如果一个软件开发人员，不了解软件架构的演进，会制约技术的选型和开发人员的生存、晋升空间。
这里我列举了目前主要的四种软件架构以及他们的优缺点，希望能够帮助软件开发人员拓展知识面。
一、单体架构单体架构比较初级，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。
这是一种典型的Java Spring mvc或者Python Django框架的应用。
其架构图如下所示：单体架构单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。
然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。
慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
下面是单体架构应用的一些缺点：复杂性高：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。
可想而知整个项目非常复杂。
每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。
技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。
“不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。
已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。
部署频率低：随着代码的增多，构建和部署的时间也会增加。
而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。
全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。
而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。
可靠性差：某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃。
扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。
第四讲软件体系结构描述一教学课件
用例1
动作状态1
对象1 组件1
包1
<<子系统>> 子系统1
关联类1
* -结束1
* -结束2
关系
依赖 关联 一般化 实现
-结束3 *
-结束4 *
<<refines>>
扩展机制（1）
构造型（套用类型）
– 构造型用双尖括号内的文字字符串表示 – 构造型的信息内容和形式与已存在的基本模型元素相
同，但是含义和使用不同 – 如《元类》
DSiDcSaeigcan协regaanrmr作aaiomrsi图os
模型
DiDaSigtaSa组rgtataerm件atems图s
DSiDcSaeigcan状regaanrmr态aaiomrsi图os
活动图
Component DCiaogmrapmosnent
Di分agrational Rose MagicDraw PowerDesigner MS Visio ArgoUML StarUML
UML概要
模型元素 关系 扩展的机制 图表
模型元素
结构元素
– 类，接口，协作，用例，活 动类，构件
行为元素
– 交互, 状态机
组元素
– 包, 子系统
其它元素
– 符号
类1 接口1
用例图
设计视图 过程视图 实现视图 分布视图
逻辑应用体系结构
图形 用户 界面
Relational Database
图形 用户 界面
商业 对象 模型
关系 数据库
图形 用户 界面
商业 对象 模型
关系 数据库
大纲
标准建模语言UML 体系结构和UML 基于UML的B/S构架描述
软件体系结构4 1模型实例
第七部分设备管理1.功能描述：设备管理功能主要包括设备信息的编辑（增加、删除、修改）。
1.1.设备信息包括设备的位置信息、名称、状态。
1.2.设备信息的编辑：支持对设备信息的编辑（增加、删除、修改）。
2.内容概述：运用4+1视图模型，从5种视图角度，进行分析设计。
2.1场景视图（Use case）使用user case图设计系统的各个场景。
2.2逻辑（功能）视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
2.3开发（模块）视图（Development View），描述了在开发环境中软件的静态组织结构。
2.4物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
2.5过程视图（Process View），捕捉设计的并发和同步特征。
4+1视图综述：3.设计详情：3.1场景视图(Scenarios)：参与者与用例构成场景视图，对设备的设置从修改，删除，增加三方面驱动。
如图1：图1在设计场景视图时，对包含（include）和扩展(extend)的应用需要仔细琢磨，刚开始并不知道每种的应用范围，看了网上的例子，和以前软件工程的书，大概了解包含的概念是一些必然发生的用例，然而扩展是在特殊情况的时候才可能发生的非正常情况。
我觉得一个小小的箭头也许在现在的项目作业中并不重要，但是在今后的学习工作中它会从某种程度上决定项目的成败，并体现出个人对工作和生活的认真态度，所以，大学课程的好处就是允许我们在实践和失败中汲取教训，总结经验。
在这部分，有同学提出了质疑，认为需要具体细分一下，如图2：图2在这里，也是得到其他同学的启发，场景视图必须要具体细分，它注重功能的概念，细分的过程可以放在逻辑视图中，通过函数来具体实现。
在这部分，我还需要更深入的了解，在实际应用过程中不断摸索。
3.2逻辑视图（Logic View）：逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。
(2021年整理)设计模式-软件体系结构-实验4-中南大学-软件学院
设计模式-软件体系结构-实验4-中南大学-软件学院编辑整理：尊敬的读者朋友们：这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望（设计模式-软件体系结构-实验4-中南大学-软件学院）的内容能够给您的工作和学习带来便利。
同时也真诚的希望收到您的建议和反馈，这将是我们进步的源泉，前进的动力。
本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快业绩进步，以下为设计模式-软件体系结构-实验4-中南大学-软件学院的全部内容。
《软件体系结构》实验报告项目名称结构型设计模式实验专业班级学号姓名实验成绩:批阅教师:年月日实验4 结构型设计模式实验实验学时： 2每组人数： 1实验类型： 3 （1:基础性 2：综合性 3：设计性 4：研究性）实验要求: 1 （1：必修 2：选修 3：其它）实验类别： 3 (1:基础 2:专业基础 3：专业 4：其它）一、实验目的熟练使用PowerDesigner和任意一种面向对象编程语言实现几种常见的结构型设计模式,包括适配器模式、组合模式和外观模式，理解每一种设计模式的模式动机,掌握模式结构，学习如何使用代码实现这些模式。
二、实验内容1。
现有一个接口DataOperation定义了排序方法sort（int[］）和查找方法search（int[], int），已知类QuickSort的quickSort(int[])方法实现了快速排序算法,类BinarySearch 的binarySearch(int[］, int）方法实现了二分查找算法。
试使用适配器模式设计一个系统，在不修改源代码的情况下将类QuickSort和类BinarySearch的方法适配到DataOperation接口中。
绘制类图并编程实现。
（要求实现快速排序和二分查找，使用对象适配器实现）2. Windows Media Player和RealPlayer是两种常用的媒体播放器,它们的API结构和调用方法存在区别。
软件体系结构-4-软件体系结构的设计原理可编辑全文
耦合和内聚
§4.1体系结构的设计原理
充分性、完备性和原始性
– 充分性是指部件应该把握住与其进行有意义和高效交互抽象 的所有特性
– 完整性是指一个部件应该把握住所有与其抽象相关的特性 – 原始性是指部件应该完成的操作都可以容易地得到实现
以及代码调试和部件的临时集成给予支持
§4.2 软件的非功能特性
可重用性
– “通过已经存在的来获得想要的”的软件 设计和实现方法（有利于Cost、Time、 Quality）
用重用进行软件开发 为重用进行软件开发
§4.2 软件的非功能特性
非功能性可能产生冲突 虽然非功能性在软件体系结构中非常重
§4.2 软件的非功能特性
效率
– 软件运行过程中对资源的使用情况、以及 对系统的响应时间、存储消耗和I/O吞吐量 的影响
– 效率问题不仅仅是设计精良算法的问题， 而且是部件操作责任合理的分配、部件之 间的耦合关系等体系结构的问题
– 良好结构、丰富功能和高效率等方面需要 权衡利弊
§4.2 软件的非功能特性
要，但很难对他们的效果和作用进行衡 量 对软件体系结构满足非功能性的成都评 价，主要还是基于工程师的经验
§4.1体系结构的设计原理
接口和实现的分离
– 接口定义了部件所提供的功能并规范了功 能的使用方法
– 实现部分包括了部件所提供功能的实际代 码
– 强调一个客户只应该知道他需要知道的东 西
– 接口和实现的分离可以很好的支持可变性
§4.1体系结构的设计原理
分而治之 层次化
§4.2 软件的非功能特性
统和应用程序一起工作并共享信息的能力 – 将系统设计成具有互操作性的部件集合本身就自
软件体系结构
软件体系结构软件体系结构是指软件系统中各个组件之间的关系和结构的抽象描述。
它是构建软件系统的基础，对软件系统的设计和开发起着重要的指导作用。
本文将从软件体系结构的定义、目标和应用领域等方面对其进行详细的介绍。
一、软件体系结构的定义软件体系结构是指软件系统中各个组件之间的关系和结构的抽象描述，它包括软件系统的静态结构和动态行为。
静态结构是指软件系统中组件的组织方式和相互之间的关系，动态行为是指软件系统中组件的交互方式和相互之间的通信方式。
二、软件体系结构的目标软件体系结构的目标是实现软件系统的可重用性、可维护性、可扩展性和可伸缩性。
可重用性是指软件系统中的组件能够被多次使用，可维护性是指软件系统中的组件能够被轻松地修改和维护，可扩展性是指软件系统能够根据需求进行功能的扩展，可伸缩性是指软件系统能够根据需求进行性能的扩展。
三、软件体系结构的应用领域软件体系结构广泛应用于各个领域的软件系统开发，特别是大型跨平台和分布式系统的开发。
在金融领域，软件体系结构被应用于交易系统和风险管理系统的开发；在电子商务领域，软件体系结构被应用于在线购物系统和支付系统的开发；在物流领域，软件体系结构被应用于供应链管理系统和运输管理系统的开发。
四、软件体系结构的基本原则软件体系结构的设计应遵循以下基本原则：1. 模块化：将软件系统分为独立的模块，每个模块只负责特定的功能，通过接口进行通信和交互。
2. 松耦合：各个模块之间的依赖应尽量降低，避免模块之间的紧密耦合，以提高系统的灵活性和可维护性。
3. 高内聚：模块内部的各个元素之间应紧密关联，功能相关的元素应放在同一个模块中，以提高系统的内聚性。
4. 分层：将软件系统分为多个层次，每个层次负责不同的功能，上层层次通过接口调用下层层次的功能。
5. 可伸缩性：系统的设计应考虑未来的扩展需求，能够根据需求进行功能和性能的扩展。
六、软件体系结构的设计方法软件体系结构的设计方法有很多种，常用的有面向对象的体系结构设计方法、服务导向的体系结构设计方法和领域驱动设计方法。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4.4 典型软件体系结构描述语言
◇ Unicon
◎ Unicon描述连接约束:使连接件角色接受指定的构件 的端口。
ROLE output IS Source MAXCONNS(1) ACCEPT(Filter.StreamIn) END output
25
第四章 软件体系结构描述
4.4 典型软件体系结构描述语言
21
第四章 软件体系结构描述
4.3 软件体系结构描述语言
◇ ADL的构成元素
◎ 体系结构配臵：体系结构配臵或拓扑是描述体系结 构的构件与连接件的连接图；
体系结构配臵提供信息来确定构件是否正确连接、 接口是否匹配、连接件构成的通信是否正确，并说明实 现要求行为的组合语义。
22
第四章 软件体系结构描述
17
第四章 软件体系结构描述
4.3 软件体系结构描述语言
◇ 典型元素含义比较
18
第四章 软件体系结构描述
4.3 软件体系结构描述语言
◇ 常见的软件体系结构元素
19
第四章 软件体系结构描述
4.3 软件体系结构描述语言
◇ ADL的构成元素
◎ 构件：构件是一个计算单元或数据存储。可以包含 多种属性，如接口、类型、语义、约束、演化和非功能 属性等； 接口是构件与外部世界的一组交互点，ADL中的构 件接口说明了构件提供的那些服务。
23
第四章 软件体系结构描述
4.4 典型软件体系结构描述语言
◇ Unicon
◎ 描述构件：Unicon通过定义类型、属性列表 与用于和连接件相连的交互点来描述构件； ◎ 描述连接件 ：通过定义类型、属性列表与交 互点来描述连接件。
端口：构件的交互点称为端口。 角色：连接件的交互点称为角色。
24
第四章 软件体系结构描述
5
第四章 软件体系结构描述
4.2 软件体系结构描述框架标准
◇ IEEE P1471
◎ IEEE于1995年8月成立了体系结构工作组，负责 起草了体系结构描述框架标准，即IEEE P1471。 ◎ IEEE P1471于2000年9月通过IEEE-SA标准委员 会评审。 ◎ IEEE P1471适用于软件密集的系统，其目标在 于：便于体系结构的表达与交流，并通过体系结构 要素及其实践标准化，奠定质量与成本的基础。
20
第四章 软件体系结构描述
4.3 软件体系结构描述语言
◇ ADL的构成元素
◎ 连接件：是用来建立构件间的交互以及支配这些交 互规则的体系结构构造模块。与构件不同，连接件可以 不与实现系统中的编译单元对应。
连接件可以是共享变量、表入口、缓冲区、对连接 器的指令、动态数据结构等等；
连接件同样也有接口。连接件的接口由一组角色组 成，连接件的每一个角色定义了该连接件表示的交互参 与者，二元连接有两个角色，如消息传递连接件的角色 是发送者和接收者。
◇ Rational
◎ Rational起草了可重用的软件资产规格说明，专门讨论了 体系结构描述的规格说明，提出了一套易于重用的体系结构 描述规范。该建议草案已经提交OMG。 ◎ Rational建议基于RUP（Rational Unified Process）、 采用UML模型描述软件的体系结构，认为体系结构描述的关键 是定义视点、视图以及建模元素之间的映射关系。
15
第四章 软件体系结构描述
4.3 软件体系结构描述语言
◇ ADL与其他语言的比较(1)
◎ 构造能力：ADL能够使用较小的独立体系结构元素来 建造大型软件系统；
◎ 抽象能力：ADL使得软件体系结构中的构件和连接件 描述可以只关注它们的抽象特性，而不管其具体的实现 细节； ◎ 重用能力：ADL使得组成软件系统的构件、连接件甚 至是软件体系结构都成为软件系统开发和设计的可重用 部件；
10
第四章 软件体系结构描述
4.2 软件体系结构描述框架标准
◇ Rational
◎ 可以从四个视点出发描述体系结构，即需求视点、设计视 点、实现视点和测试视点。
◎ 在此基础上提出了7个体系结构视图：用例视图、域视图、 非功能需求视图、逻辑视图、实现视图、过程视图和部署视 图。 ◎ 并从系统建模的角度考虑多个视图之间的映射关系。
12
第四章 软件体系结构描述
4.3 软件体系结构描述语言
ADL是在底层语义模型的支持下，为软件系统的概念体系 结构建模提供了具体语法和概念框架。基于底层语义的工具 为体系结构的表示、分析、演化、细化、设计过程等提供支 持。其三个基本元素是：构件、连接件、体系结构配臵。
主要的体系结构描述语言有Aesop、MetaH、C2、Rapide、 SADL、Unicon和Wright等，尽管它们都描述软件体系结构， 却有不同的特点。
13
第四章 软件体系结构描述
4.3 软件体系结构描述语言
Aesop支持体系结构风格的应用; MetaH为设计者提供了关于实时电子控制系统软件的设计 指导; C2支持基于消息传递风格的用户界面系统的描述; Rapide支持体系结构设计的模拟,并提供了分析模拟结果 的工具; SADL提供了关于体系结构细化的形式化基础； Unicon支持异构的构件和连接类型，并提供了关于体系 结构的高层编译器； Wright支持体系结构之间交互的说明和分析。
(6) 体系结构原理。
7
概 念 框 架
8
第四章 软件体系结构描述
4.2 软件体系结构描述框架标准
◇ IEEE P1471
◎ IEEE P1471详细介绍了一套体系结构描述的概念框 架，并给出建立框架的思路。但如何描述以及具体的描 述技术等方面缺乏更进一步的指导。
9
第四章 软件体系结构描述
4.2 软件体系结构描述框架标准
11
第四章 软件体系结构描述
4.2 软件体系结构描述框架标准
◇ Rational
◎ Rational的建议标准覆盖了“4 + 1”体系结构模型中的4 个视图，并在原则上讨论了视图以及视图之间的映射表示问 题。 ◎该建议标准结合了业界已经广泛采用的建模语言和开发过 程，因而易于推广，可以有效实现在跨组织之间重用体系结 构描述结果。 ◎ 由于将体系结构的描述限于UML和RUP，具有一定描述
4.3 软件体系结构描述语言
◇ ADL与其他语言的比较(2)
◎ 组合能力：ADL使得其描述的每一系统元素都有其自 己的局部结构，这种描述局部结构的特点使得ADL支持软 件系统的动态变化组合； ◎ 异构能力：ADL允许多个不同的体系结构描述关联存 在；
◎ 分析和推理能力：ADL允许对其描述的体系结构进行 多种不同的性能和功能上的多种推理分析。
4.4 典型软件体系结构描述语言
◇ Unicon
◎ Unicon的主要目的在于支持对体系结构的描述，对 构件交互模式进行定位和编码，并对需要不同交互模式 的构件的打包加以区别。主要目的:
提供对大量构件和连接件的统一访问； 区分不同类型的构件和连接件，以便对体系结构配臵 进行检查； 支持不同的表示方式和不同开发人员的分析工具； 支持对现有构件的使用。
◎
◎ MIL方式对模块化的程序设计和分段编译等程序设计与开发 技术确实发挥了很大的作用。但是由于这些语言处理和描述的 软件设计开发层次过于依赖程序设计语言，因此限制了它们处 理和描述比程序设计语言元素更为抽象的高层次软件体系结构 元素的能力。 3
第四章 软件体系结构描述
4.1 软件体系结构描述方法
◇ 基于软构件的系统描述语言
◎ 基于软构件的系统描述语言将软件系统描述成一种是由许 多以特定形式相互作用的特殊软件实体构造组成的组织或系统。 ◎ 例如，一种多变配臵语言就可以用来在一个较高的抽象层 次上对系统的体系结构建模，Darwin最初用作设计和构造复杂 分布式系统的配臵说明语言，因具有动态特性，也可用来描述 动态体系结构。 ◎ 缺点：针对的系统元素仍然是一些层次较低的实体单元， 对软件体系结构的描述不太适合。
4
第四章 软件体系结构描述
4.1 软件体系结构描述方法
◇ 软件体系结构描述语言
◎ 软件体系结构的第四种描述和表达方法是参照传统程 序设计语言的设计和开发经验，重新设计、开发和使用针 对软件体系结构特点的专门的软件体系结构描述语言。 ◎ 由于ADL是在吸收了传统程序设计中的语义严格精确的 特点基础上，针对软件体系结构的整体性和抽象性特点， 定义和确定适合于软件体系结构表达与描述的有关抽象元 素，因此，ADL是当前软件开发和设计方法学中一种发展 很快的软件体系结构描述方法，目前，已经有几十种常见 的ADL。
27
第四章 软件体系结构描述
4.4 典型软件体系结构描述语言
◇ C2概述
◎ 构件之间的消息交换不能直接进行，而只能通过连接件来 完成。每个构件接口最多只能和一个连接件相连，而连接件 可以和任意数目的构件或连接件相连。
◎ 请求消息只能向上层传送而通知消息只能向下层传送。
◎ 通知消息的传递只对应于构件内部的操作，而和接收消息 的构件的需求无关。 ◎ C2对构件和连接件的实现语言、实现构件的线程控制、构 件的部署以及连接件使用的通讯协议等都不加限制。
◇ Unicon
◎ Unicon描述管道
USES p1 PROTOCOL Unix-pipe USES sorter INTERFACE Sort-filter CONNECT sorter.output TO p1.source USES p2 PROTOCOL Unix-pipe USES printer INTERFACE Print-filter CONNECT sorter.input TO p2.sink
14
第四章 软件体系结构描述
4.3 软件体系结构描述语言
这些ADL强调了体系结构不同的侧面，对体系结构的研 究和应用起到了重要的作用，但也有负面的影响。每一种 ADL都以独立的形式存在，描述语法不同且互不兼容，同时 又有许多共同的特征，这使设计人员很难选择一种合适的 ADL，若设计特定领域的软件体系结构又需要从头开始描述。