软件体系结构5a ATC案例分析
软件体系结构案例
软件体系结构案例分析案例一:学生管理系统功能如下面业务分解图所示,将一个开发的软件——学生管理系统分成五个子系统,学生档案管理:学生的一般情况,及奖励,处分情况;学生成绩管理:学习成绩,补考成绩;学籍处理:学生留降级处理,休复学处理,退学处理;日常教务管理:日常报表,如通知书,补考通知书等,学生学成绩的各种分类统计;毕业生学籍处理:结业处理,毕业处理,授位处理,学籍卡片等。
3、信息采集与各部门的使用权限每学期考试完毕由各系录入成绩,然后由教务科收集。
为了信息的安全和数据的权威性,对于网上信息的使用权限和责任规定如下:数据收集前的系统权限学生档案学生奖惩学生成绩学籍处理补考成绩教学计划管理各种等级考试学生工作处0 ?0 ??????各系??0 ?????教务科???0 ?0 ??0 ?师资科?????0 ??院长办公室???????注:0、登录,修改,处理权。
?、查询权性能1、网络环境下的多用户系统在上述已有的硬件环境下,信息由各用户在规定的权限下在各自的工作站上录入,信息上网后各用户可查询,调用,达到信息共享。
2、数据的完整性,准确性a、录入数据采用表格方式,限制录入数据类型及取值范围以保证数据的完整性及准确性。
b、系统具有部分反悔修改功能,系统备有的修改功能均可反悔3、数据完成的时间性,如成绩的录入,仅当师资科录入教学进程,教务科分发教师教学任务安排之后,各系方可录入成绩。
4、数据安全性本系统采用二级安全保障第一级:依赖于网络本身对用户使用权限的规定。
第二级:在程序模块中通过使用密码控制功能对用户使用权限加以限制。
如上表5、成绩自动统计分析及学籍的自动处理本系统按学籍管理条例设计了若干个软件处理模块:1、按某学生某学期,学年考试及补考成绩,自动生成该学生是否升留降级,退学。
2、可按某学生在校期间累计补考科目门数和成绩自动生成该学生是否结业,毕业,授位。
3、可按某学生因非成绩原因所引起的学籍变更作自动处理。
软件体系结构设计案例分析
对原型系统的分析
请求都由“中心”服务器做出响应,一旦它出现了故障, 无法提供服务,则存储在系统中的科学数据就无法向外界 提供共享服务。
对有保密性要求的数据实施安全控制; 提供系统运行日志监控信息,供管理员了解系统的运行和 安全状态;
2005年中期完成系统,年底前投入正式使用; 能够利用现有系统的可利用资源; 初期总共投资2000万,分别用于系统的集成建设和开发、 共享数据标准的制定。
科学数据共享网的体系结构?
科学数据共享网的体系结构
提供的接口负责将收集的科学数据先暂存在平台数据库中;然后 供工作人员对数据进行有效性检查和加工,并将合法数据转移到 发布数据库中;最后管理发布数据库中数据的接口提供数据的访 问服务。 平台管理承担了管理用户信息、管理用户和数据的安全信息,以 及生成平台运行日志的任务。
是否合适?
对原型系统的分析
非功能性需求
质量属性
可用性/可靠性
可维护性 性能
安全性
商业属性
针对质量属性的需求
系统应能长期稳定地提供服务,近似7 × 24小时工作强度; 在负载过重或是系统崩溃的情况下,能保证用户的请求不 丢失; 当系统出现故障或崩溃时,恢复时间不超过两小时;
修改某个子系统或服务时,不影响其他子系统或服务;
高峰时系统的平均响应时间控制在20秒以内; 系统能够满足100个并发的用户查询请求; 系统至少能够支持2000个用户的在线服务;
遵循面向服务的体系结构思想,为了实现数据的共享服 务,各个中心将服务内容封装成Web Service,作为其他 中心访问本中心数据的入口,并通过Internet传输数据。
软件体系结构设计方法ppt课件
模式驱动的体系结构设计方法从模式导出体系结构 抽象。软件设计模式的目的在于编制一套可重用的 基本原则,用于开发高质量的应用系统。体系结构 模式类似于设计模式,但它关心更粗粒度的系统结 构及其交互。
15
客户 需求规格说明书
通用知识 2:实现
体系结构模式 描述 意图
上下文
问题
解决方案
体系结构描述Biblioteka 4:组合3:应用 体系结构模式
图4 模式驱动的体系结构设计的概念模型
16
3. 系统的管理端业务处理模块
3.1 总的网络拓补结构
系统管理员
数据库 和
Web程序 都在这上
导师
导师
导师
17
3. 系统的管理端业务处理模块
在该系统中采用面向对
象分析作为主要的系统
建模方法,用不同的设
计角度描述角色(管理
有所不同。
3
客户
领域知识
捕捉需求 需求规格 说明书
提取解决方 案的结构
领域知识 工作
解决方案抽象
体系结构 规格说明
领域知识
体系结构
图1 体系结构设计方法的元模型 4
2.软件体系结构设计方法的分析
为了获取对体系结构设计的抽象,人们已经提出 了许多方法。
2.1 体系结构设计方法的分类
(1)工件驱动(Artifact-Driven)的方法 (2)用例驱动(Use-Case-Driven)的方法 (3)模式驱动(Pattern-Driven)的方法 (4)领域驱动(Domain-Driven)的方法
*
者)与系统的其它的 管理员
构件是如何联系的。管
管理端子系统 *
理端的主用例图如右图:
软件体系结构_第二章软件体系结构的风格与模式
软件体系结构_第二章软件体系结构的风格与模式软件体系结构是指软件系统在运行时所表现出来的组成部分之间的关系。
在软件设计和开发过程中,选择适合的体系结构风格与模式对于实现系统的可扩展性、可维护性和可靠性等方面的要求非常重要。
本章将介绍一些常见的软件体系结构风格与模式。
1. 分层体系结构(Layered architecture)分层体系结构是一种自顶向下的体系结构风格,它将软件系统划分为多个分层,每个分层只与其相邻的分层进行通信,并且每个分层都具有一定的功能和责任。
分层体系结构能够有效地提高系统的模块化程度,降低系统的复杂性。
2. 客户/服务器体系结构(Client/Server architecture)客户/服务器体系结构是基于分布式计算的一种体系结构风格,其中客户端和服务器端是相对的角色。
客户端负责用户界面和用户交互,而服务器端负责数据存储和业务逻辑。
客户/服务器体系结构能够提高系统的可扩展性和性能。
3. 事件驱动体系结构(Event-Driven architecture)事件驱动体系结构是一种基于事件和消息的体系结构风格,其中组件之间通过事件和消息进行通信和协作。
事件驱动体系结构能够实现松耦合,提高系统的灵活性和可扩展性。
4. MVC模式(Model-View-Controller pattern)MVC模式是一种软件设计模式,用于将用户界面、数据处理和业务逻辑相分离,使每个部分可以独立变化。
模型(Model)表示应用程序的数据和业务逻辑,视图(View)表示用户界面,控制器(Controller)负责接收和处理用户的输入。
MVC模式能够提高系统的可维护性和可重用性。
5. 微服务架构(Microservices architecture)微服务架构是一种将系统划分为多个小型、自治的服务的体系结构风格。
每个服务都可以独立地开发、部署和扩展,并且通过轻量级的协议进行通信。
微服务架构能够提高系统的灵活性和可扩展性。
开放式数控系统软件体系结构分析
第二层:
控制装置在明确固定的拓扑结构下允许替换、增加NC核心 中的特定模块以满足用户的特殊要求 第三层:
拓扑结构完全可变的“全开放”的控制装置
车间网络服务器
操作员
物料小车
操作员
操作员
车间网络服务器
管理者
? ?
? ? ?
? ? ?
局域网
局域网
远端培训人员
远端制造客户
远期工作目标
开放式数控系统
(跨平台、全模块化)
基于DSP的运动控制
--运动控制算法及对象建模
简单控制与复杂控制 几种运动控制系统实现方法 业界最具竞争力的数字电动机控制 芯片—TMS320x24x 伺服算法
针对不同的电动机建立控制模型。
运动控制的种类
简单控制
对电动机进行启动、制动、正反转控制和顺序 控制。可以通过继电器、可编程控制器和开关 元件实现。 对电动机的转速、转角、转矩、电压、电流、 功率等物理量进行控制。
基于实时多任务Linux数控系统参考体系结构
用于数控实时多任务Linux系统体系结构
实时内核 + Linux常规核心
支持占先式优先级
通用Linux核心功能: 进程管理 内存管理 文件系统管理 TCP/IP网络功能 。。。
基于实时多任务Linux数控系统参考体系结构
数控系统非实时应用程序 操作系统API 级本库和扩展库支持(C语言、图形、网络) 数控系统实时任务 实时调试 监视器 实时 API 实时设备 驱动程序
基于实时多任务Linux数控系 统参考体系结构 CNC软件特点
数控软件体系结构分析
传统数控装置组成
程序编制 输入装置 数控装置CNC
软件体系结构分析和评估综述
所有的风险承担 者
所有的风险承担 者和体系结构设 计师
可维护性
设计过程
场景(不同于用例场景,它描述 的是与系统相关的可能发生的活 动或活动的序列,而一个变化场 景描述了系统的某个维护任务)
仅仅设计师
三种典型的评估方法比较
上表显示了基于场景的体系结构分析方法(SAAM),体系结构权 衡分析方法(ATAM),体系结构级别上的软件维护预测(ALPSM)。
1 发展现状
人们逐步认识到软件体系结构的分析评估对保证软件质 量的重要性,在软件体系结构分析与评估这个新领域,许多 研究组织在各种杂志与会议上提出了许多新颖的结构化的评 估方法,并且对这些软件体系结构分析与评估的新方法的验 证与实现在不断的进行着。
2 概念描述
2 概念描述
在软件设计领域一般认为: 软件体系结构的分析评估,就是通过成本相对较低的活
软件体系结构分析与评估综述
Team#12 杨广 杨英达 曹海涛 李良 袁柱 王喆
研究背景
× 随着对软件体系结构的研究不断深化,诞生了软件体系结 构形式化描述、风格、规范、建模等一系列的概念,并且形 成了一个新的研究领域。 × 对于软件系统来说,软件质量变得更重要,大规模的复杂 软件系统更是如此。 × 高质量的软件在维护和测试阶段的开销较低,复用的潜力 大。
比较因素 评估方法
SAAM ATAM
ALPSM
4 关键方法的比较
考查的 质量属性
使用阶段
使用的 评估技术
风险承担 者的参与
可修改性
多个质量属性 (侧重可修改 性、安全性、 性能和可用性 )
SA的最终版 本
SA的最终版 本或设计的 重复改进过 程
ቤተ መጻሕፍቲ ባይዱ
软件系统分析与设计5结构分析设计
提高组件的可重用性,减少重复开发。
基于框架的分析设计方法
01
框架选择
根据项目需求选择合适的开发框架。
框架特性利用
利用框架提供的特性来简化开发过 程。
03
02
架构设计
基于框架进行系统的架构设计,包 括模块划分、模块间通信等。
性能优化
基于框架进行性能优化,提高系统 运行效率。
04
04 结构分析设计实践
界面设计
根据用户需求和用户体验,设计系统的用户界面和交 互流程。
系统实现与测试
编码实现
根据系统设计文档,编写代码实现各个功能模块。
单元测试
对每个模块进行单元测试,确保模块功能的正确 性。
系统集成测试
将各个模块集成在一起进行测试,确保系统整体 功能的稳定性和可靠性。
05 结构分析设计案例
CHAPTER
案例一:电子商务网站的结需要满足用户浏览商品、下订单、支付等需求,同时需要
保证商品信息的实时更新和维护。
02 03
系统结构
电子商务网站通常采用三层架构,包括表示层、业务逻辑层和数据访问 层。表示层负责用户交互,业务逻辑层处理业务逻辑和数据验证,数据 访问层负责数据库操作。
软件系统分析与设计5:结构分 析设计
目录
CONTENTS
• 软件系统概述 • 结构分析设计基础 • 结构分析设计方法 • 结构分析设计实践 • 结构分析设计案例
01 软件系统概述
CHAPTER
软件系统的定义与分类
软件系统是指由计算机程序、数据、相关文档以 及支持软件运行的硬件组成的集合体。
根据用途,软件系统可分为系统软件、应用软件 和中间件。
类与类关系
软件架构设计中的五层体系结构
软件架构设计中的五层体系结构随着计算机技术的不断发展,软件系统的规模越来越大,复杂度也越来越高,因此在软件系统的开发过程中,软件架构的设计显得尤为重要。
软件架构定义了软件系统的组织结构,包括软件系统的组件、模块、接口、数据流等等,是指导软件系统设计和开发的基石。
软件架构设计中的五层体系结构是一种基于分层思想的软件架构设计模式,被广泛应用于大型软件系统。
该体系结构分为五个层次,每个层次负责处理不同的任务和功能,各层之间协同工作,形成一个完整的软件系统。
下面将详细解释五个层次及其功能。
第一层:用户界面层用户界面层是软件系统与用户之间的接口,负责接收用户的输入请求,并向用户展示软件系统的输出信息。
用户界面层通常包括下面两个部分:1.1 用户界面管理器用户界面管理器是负责响应用户界面的请求,生成和显示用户界面的用户界面组件,如按钮、文本框等。
用户界面管理器还可以帮助用户进行数据输入验证,保证数据的完整性和正确性。
1.2 应用程序编程接口应用程序编程接口(API)是用户界面层与下一层——业务逻辑层之间的桥梁,将用户界面的请求传递给业务逻辑层。
API还可以将业务逻辑层返回的数据展示给用户界面层。
第二层:业务逻辑层业务逻辑层是软件系统的核心,负责处理软件系统的业务逻辑,即实现软件系统的功能。
业务逻辑层通常包括下面两个部分:2.1 业务逻辑模型业务逻辑模型是软件系统中实现业务逻辑的代码和算法集合,是业务逻辑层的核心。
业务逻辑模型需要和其他模块进行交互,因此需要和数据库模型进行配合。
2.2 数据访问模型数据访问模型负责与数据库进行通信,将业务逻辑层操作的数据存储到数据库中,并从数据库中读取数据。
数据访问模型还需要对数据库进行管理和维护,保证数据库的稳定性和安全性。
第三层:数据访问层数据访问层是负责管理和维护数据库的模块,其功能是通过数据访问接口向上层提供一定的数据访问功能,同时向下层提供对数据库的操作。
数据访问层通常包括下面两个部分:3.1 数据库访问接口数据库访问接口提供对外的数据访问API,向上层提供数据库的访问功能。
[软件体系结构]第3章_软件体系结构风格解析
第3章 软件体系结构风格 ◇ 分层系统的优点
3.2 经典软件体系结构风格
◎ 利于问题的分解
•支持逐级抽象的方式进行系统设计,使设计者可 以把一个复杂系统按递增的步骤进行分解。
◎ 可修改性强
•每一层至多和相邻的上下层交互,因此功能的改 变最多影响相邻的上下层;
第3章 软件体系结构风格 ◇ 经典的体系结构风格
3.1 软件体系结构风格概述
◎ 数据流风格:批处理序列;管道/过滤器。 ◎ 调用/返回风格:主程序/子程序;面向对象风格;层
次结构。
◎ 独立构件风格:进程通讯;事件系统。 ◎ 虚拟机风格:解释器;基于规则的系统。 ◎ 仓库风格:数据库系统;超文本系统;黑板系统。
这种风格建立在数据抽象和面向对象的基础上, 数据的表示方法和它们的相应操作封装在一个 抽象数据类型或对象中。 构件就是对象,或者说是抽象数据类型的实例 连接件就是过程(方法)调用
第3章 软件体系结构风格 3.2 经典软件体系结构风格
◇ 数据抽象和面向对象组织
面向对象典型特性:
封装
私有 — 实现信息隐藏 公有 — 对外接口,易于维护和修改
第3章 软件体系结构风格 3.2 经典软件体系结构风格
◇ 数据共享风格(仓库与黑板)
黑板系统风格的系统由3部分组成:
知识源:与特定应用相关的独立的知识包(parcel),是 中央数据单元的信息来源。它们不直接交互,是通过中 央数据单元的协调来完成相互之间的交互。
中央数据单元(黑板):系统的核心组成部分,包含系 统要处理的数据以及求解问题的状态数据。按照某些数 据结构方式来组织,可以根据知识源信息的变化被修改。
◎ 整体效率降低
高级软件工程(第九章)-软件体系结构()PPT课件
管道/过滤器结构
Ø 每个过滤器都是一个独立的个体元素,各个过滤器的状态互不 相关,非邻近过滤器不共享任何信息;
9 Ø 运行结果的正确性与各个过滤器运行的先后顺序无关。
管道/过滤器体系结构风格
➢管道/过滤器风格具有以下优点: ✓ 简单性,允许将系统的输入和输出看作是各个
过滤器行为的简单组合,独立的过滤器能够减 小构件之间的耦合程度; ✓ 系统具有可扩展性和可进化性,各个过滤器是 相互独立的,因此可以很容易地将新过滤器添 加到现有的系统之中,以扩展系统的业务处理 能力,原有过滤器可以很方便地被改进的过滤 器所替代;
➢软件体系结构表示系统的框架结构,用于从较高 的层次上来描述各部分之间的关系和接口,主要 包括:构件、构件性质和构件之间的关系。
➢不同系统的设计方案存在着许多共性问题,把这 些共性部分抽取出来,就形成了具有代表性的和 可广泛接受的体系结构风格。
4
几种典型的软件体系结构风格
➢软件体系结构风格也称为软件体系结构惯用模 式,是指不同系统所拥有的共同组织结构和语 义特征。
软件密集型系统的总体结构的语言,说明系统众
多构件之间的结构关系。
➢代表性的体系结构描述语言包括:
➢ Wright
➢ ACME
➢ Rapide
➢ ABC/ADL
➢ Darwin
➢ XYZ/ADL
➢ Unicon
➢ XADL
➢ 大部分结构描述语言都有构件、连接子、配置
等概念。
3
几种典型的软件体系结构风格
➢软件体系结构风格定义了用于系统描述的术语 表和一组用于指导系统构建的规则。
5
几种典型的软件体系结构风格
➢管道/过滤器风格 ➢数据共享风格 ➢客户机/服务器风格 ➢浏览器/服务器风格 ➢MVC体系结构风格
软件体系结构案例分析
系统的结构视图如下:
打印机
PWR OK WIC0 ACT/CH0 WIC0 ACT/CH0 ETH ACT COL ACT/CH1 ACT/CH1
其他公用设备 数据库服务器
Print Server
Power/TX Link/Rx LPT1 LPT2 COM
细化用例后,还需对用例进行详细描述,直到所有涉众都 认可描述的内容已经能够正确表达出他们的需求为止。下面以 用例“提交入库记录”为例细化描述。
要素 用例名称 简要描述 事件流 提交入库记录 库存管理员根据药品采购具体情况、记录选购药品,形成 入库单,提交给系统处理。 基本事件流 (1)库存管理员在待入库的药品名称栏中输入待入库的 药品名称; (2)系统根据用户输入,以列表的形式罗列当前系统中 存储的符合库存管理员要求的药品种类的详细信息; 说明
“提交入库记录”为例细化描述(续)
要素 备选事件流 说明 库存管理员在输入待入库的药品种类名称时,系统不能查 询到相关信息时,则按一下步骤进行: (1)在系统未查询到库存管理员所需的相关药品种类信 息时,提示库存管理员是否需要添加新的药品种类信息; (2)其次,撤销此次入库记录的提交。 系统要保证入库信息的一致性和完整性,不允许伪造数据。 界面操作要合理,要考虑到库存管理员操作顺序等问题。
2 需求分析
需求分析的主要任务通过对客户的当前业务的分析,我们 得到当前业务的基本需求。包括功能需求和非功能需求。非功 能需求又包括质量属性和各种约定。
2 需求分析
功能需求
功能 用户管理 药品管理 发货单位管理 收补单位管理 入库批次管理 说明 用户的创建、登录、删除和维护 药品种类的添加、删除和维护 发货单位的添加、删除和维护 收补单位的添加、删除和维护 添加入库药品、打印入库单、签字、入库等
软件体系结构的分析与评估报告PPT(62张)
评估所关注的质量属性
可靠性(reliability)(2)
容错:在错误发生时确保系统正确的行为, 并进行内部修复。如在一个分布式软件系统 中失去了一个与远程构件的连接,接着恢复 了连接,在修复这样的错误后,系统可以重 新或重复执行进程间的操作。
健壮性:保护应用程序不受错误使用和错误 输入的影响,在遇到意外错误事件时确保应 用系统处于已经定义好的状态。
评估所关注的质量属性
性能(performance)
性能是指系统的响应能力,即要经过多长时 间才能对某个事件做出响应,或者在某段事 件内系统所能处理的事件的个数。
经常用单位事件内所处理事务的数量或系统 完成某个事务处理所需的时间来对性能进行 定量的表示。
性能测试经常要使用基准测试程序(用以测 量性能指标的特定事务集或工作量环境)。
评估所关注的质量属性
可靠性(reliability)(1)
可靠性是软件系统在应用或系统错误面前, 在意外或错误使用的情况下维持软件系统的 功能特性的基本能力。
可靠性通常用平均失效等待时间(MTTF) 和平均失效间隔时间(MTBF)来衡量。在 失效率为常数和修复时间很短的情况下, MTTF和MTBF几乎相等。
响应是指系统是如何通过体系结构对刺激作 出反应的。例如,用户所要求的功能是否得 到满足?维护人员的修改是否成功?测试人 员的测试是否成功等。
体系结构评估的结果
一份报告,提供若干信息:
该体系结构是否与所要开发的系统相适应?
针对所要开发的系统,在备选的两个或多个体系 结构中,哪一个是最合适的?
基本概念
场景(1)
在进行体系结构评估时,一般首先要精确地 得出具体的质量目标,并以之作为判定该体 系结构优劣的标准。我们把为得出这些目标 而采用的机制叫做场景。
演示文档软件体系结构第二章软件体系结构风格精品PPT课件
4.定义可以对基于这种风格建立的系统进行的分 析。如:Client/Server结构风格的实时处理过程的可调度性。
基本的软件体系结构风格
Garlan和Shaw对通用体系结构风格的分类:
•数据流风格:批处理序列;管道/过滤器; •过程/调用风格:主程序/子过程;面向对象;分层系统; •独立组件风格:进程通讯;基于事件驱动的系统(显式调用\隐式调用) •虚拟机风格:表格驱动的解释器(类似CPU);基于规则的系统(类似工业
件。系统中其它组件的过程在一个或多个事件中注册,当一个事件 被触发,系统自动调用在这个事件中注册的所有过程。这样,事件 的触发就可以隐式调用模块中的过程。
管道-过滤器
数据中心式
中央数据库:常见的数据库 应用系统
超文本系统: WWW 黑板
独立部件式
互通信进程:UNIX系统 事件系统(隐式调
用):Windows
显式调用
虚拟机式
解释器: JAVA虚拟机 基于规则的系统: 过程控
制系统
基本的软件体系结构风格
出发点:侧重于软件体系结构的结构模型,即观察软件部件、连
基本的软件体系结构风格
----管道/过滤器(pipes and filters)
计算过滤器
管道
计算过滤器
过滤器:对输入数据进行局部变换,并采用渐进式计算方法, 在未处理完所有输入数据以前,就可以产生部分计算结果, 并将其送到输出端口。
管道:各过滤器之间的连接器将一个过滤器的输出传到下一 过滤器的输入端。
Interpreter
Rule-based System
From Chapter 5, Software Architecture in Practice, p. 95
软件体系结构风格例
管道过滤模式实例本小节将引导读者跳出自己所熟悉的计算机领域,走入另一个和计算机技术息息相关的领域——数字通信领域。
以一个典型的数字通信系统为例,详细地介绍如何用管道过滤模式组织系统中的各个部件。
由此也不难看出,软件体系结构是系统分析、创建和管理技术发展到一定程度的产物,是多学科共同努力的结果,并不局限于计算机软件或其它某个具体的领域,具有很强的普遍实用性。
通信的目的是传递消息。
消息具有不同的形式,例如:符号、文字、语音、音乐、数据、图片、图像等等。
所以,根据所传递消息的不同,目前通信业务可以分为电报、电话、传真、数据传输及可视电话等。
如果从广义的角度看,广播、电视、雷达、导航、遥测遥控等也可以列入通信的范畴。
实际上,基本的点对点通信,均是把发送端的消息传递到接收端。
所以,这种通信系统可由图2.5中的模型加以概括。
下图中有4个过滤器和相互之间联系所需要的管道。
信息源的作用是把各种可能信息转换成原始电信号;发送设备对原始电信号完成某种变化,便于原始信号在倩道中传输;然后再送入信道;信道是指信号传输的通道,它既可以看成是管道(因为它的目的并不是为了实现某种功能,仅仅是为了信号的传输),也可以从某种意义上看做是过滤器(因为信号经过信道后会产生一些变化,比如,加入噪声的影响,从而改变了发送设备发出的信号)。
在接收端,接收设备的功能与发送设备的相反,它能从接收信号中恢复出相应的原始信号;而受信者(也称为信息宿或收终端)是将复原的原始信号转换成相应的消息。
图2.5中的噪声源是信道中的噪声以及分散在逼信系统其它各处的噪声的集中体现,它使原信号受到了于扰,产生畸变。
以上的4个过滤器仅是对通信系统的粗略表示,其中的某些过滤器在实际实现中,又可以根据具体应用的不同分解成多个子过滤器和子管道。
图2.5 数字通信系统粗略模型按照信道中传输的是模拟信号还是数宇信号,可以相应的把通信系统分成两类;模拟通信系统和数字通信系统,本书仅以数字通信系统为例详细说明。
软件体系结构及应用课件
– 如果任务的产生者与接收者之间不能预先绑定在一起,使用基于事件的风格 – 如果任务分为生产者与消费者,考虑C/S风格
• 如果追求客户端的计算效率,考虑胖客户端的C/S风格 • 如果客户端频繁发生变化,考虑瘦客户端的C/S风格(或B/S风格) • 如果服务器端的计算压力过大,考虑使用服务器的集群风格 • 如果无须中央服务器,使用点对点(P2P)风格
软件体系结构及应用
体系结构风格选择方 法
体系结构风格的选择
目前最常见的体系结构: 分层 +OO
我们已经学习过了十余种体系结构风格;
简单的判断某一个具体的应用应该采取何种体系结构是非常困难的, 需要借助于丰富的经验。
从目前的趋势来看:
– 管道-过滤器风格、批处理风格已经非常少见; – 过程控制风格、黑板结构、虚拟机风格往往针对具体的应用领域; – OO的思想已经融合在几乎所有的体系结构之中,而事件风格、层次化的思
4 构件-连接件划 分
SA风格选择需考虑的因素
体系结构风格的选择
技术因素:
性能因素:
– (1) 何种构件、连接件
– (2) 在运行时,构件之间的控制机制是如 何 被共享、分配和转移
– (3) 数据如何通讯
– (4) 数据与控制如何交互
–可修改性
• 算法的变化 • 数据表示方式的变 化 • 系统功能的可扩展 性
KWIC use case
体系结构风格的选择
Use
Use
r
r
Provides Input 提供输入
<uses>
Generate Circular Shift 产生循环移 位
计算机软件体系结构5a ATC案例分析
Common quality requirements for availability, reliability …
So ISSS was influenced by requirements for all of AAS
History
ISSS real system, designed, most of code developed
计算机软件体系结构 5a ATC案例分析
Flight Monitoring
Flight from Key West to DC
Key west ground control (to taxi to runway) Key West Tower (take off till leaving airport airspace ZMA enroute zone center ZJX enroute zone center ZTL enroute zone center ZDC enroute zone center DC Tower (arrival airport) ground-control (to taxi again)
FAA Controllers (end users) – could reject this
system if it was not to their liking even if it met all functional requirements Usability attribute? Actually handled by taking great care with requirements and design (thus slowing the process)
软件体系结构:软件框架构造技术及案例分析
– 解空间的变化来自于系统设计、实现技术、系统运行环境的变化
• 实现机制:怎样实现功能?
变化性分类(续)
• 变化性模式
– 必须的(Mandatory)需求:所有现有系统都具有这类需求 – 可选的(Optional)需求:部分现有系统具有这类需求,并非全部系
统都具有 – 多选一的(Alternative):只能从多个变化项选择其中一个满足需求,
• 框架与变化性控制
– 框架体现了领域共性 – 通过扩展点支持变化性
相关概念
应用程序
领域不 变部分
框架 构件
构件
构件 构件
构件
构件 构件 可变部分
内容
1. 软件框架概念 2. 软件框架构造技术 3. 实例研究——San Francisco商业开发平台
软件框架构造技术
• 软件框架的开发过程模型 • 开发过程中的相关技术研究
– 框架本身是可复用资产,也有助于实现扩展部分的复用
相关概念
• 框架和设计模式
– 从粒度上看,设计模式要小于框架,一个框架可以包括多个设计 模式,但是设计模式不可能包括框架
– 框架要比设计模式更加特化,框架总是与特定的应用领域相关, 而通常设计模式更加普通,可以应用任何的应用领域
– 框架的设计、实现以及描述利用了设计模式
相关概念
• 框架和软件开发过程
– 框架在整个软件开发过程中属于资产库建设的范畴,是领域设计 和领域实现的重要制品之一
– 基于框架的软件开发活动可以分为
• 框架的设计和开发——框架开发阶段 • 基于框架定制应用系统——框架使用阶段 • 框架演化和维护阶段
– 设计和开发一个框架成本高,但是通过复用带来的效益也更加显 著
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
11
ISSS Design
ISSS requires flexibility in number of control stations per sector (1 to 4) At least two controllers per sector: 1. Radar controller
Monitors radar Communicates with aircraft Responsible for maintaining separation of aircraft
14
ISSS Architecture
Views 1. Physical View 2. Module decomposition view 3. Process View 4. Client-Server View 5. Code View 6. Layered View 7. Fault Tolerance View
5
ISSS Influences
ISSS was only one part of AAS Notes on Design of ISSS
Many components in common
Interfaces to: radio systems, flight-plan DB, each other
15
Physical View
16
Physical View Notes
HCS A – Host computer System A (primary)
Processes radar and flight-plan info. Output to consoles (radar) and flight-strip printers (flightplans)
High performance
Handle up to 2440 aircrafts effectively and efficiently
8
Other Requirements and Quality Attributes
Openness- meaning the system needs to be able to incorporate commercially developed components Ability to field subsets of the system Modifiability – modifications to functionality and to handle upgrades in hardware and software Interoperability – the ability to operate with and interface a wide range of external systems
2. Data controller
Retrieves flight plans etc. Supplies radar controller with “intentions” of aircraft
12
ISSS Implementation Metrics
The system contains about 1 million lines of Ada code Designed to support up to 210 consoles per en route center. Each console was a workstation with IBM RS/6000 processor Requirements to handle from 400 to 2440 aircraft simultaneously There may be from 16 to 40 radar units to support a single facility A center may have from 60 to 90 control positions in each center
2
Flying from point A to point B in the U.S. air traffic control system
3
En route centers in the United States
4
Flight Monitoring
Flight from Key West to DC
9
Stakeholders
FAA Controllers (end users) – could reject this system if it was not to their liking even if it met all functional requirements Usability attribute? Actually handled by taking great care with requirements and design (thus slowing the process)
Advanced Automation System (AAS) Components
Ground Control Airport Tower En Route Centers – Initial Sector Suite System (ISSS)
This study will focus on ISSS only.
13
ISSS Functionality Sቤተ መጻሕፍቲ ባይዱmmary
Acquire radar targets reports from existing ATC system, the Host Computer System (henceforth “Host”) Convert radar reports for display and broadcast to all consoles (consoles can switch areas that are displayed) Handle conflict alerts (potential collisions) Interface with Host for input and to retrieve flight plans Provide extensive monitoring of the system itself to allow dynamic reconfiguration Provide recording capability for later playback Provide nice GUI Provide reduced backup capability in the event of the failure of the Host, the primary network, the primary radar sensors
案例分析:Air Traffic Control
张平健 华南理工大学软件学院
1
Air Traffic Control (ATC)
The problem is to control a very large number of aircraft from take-off to landing. Problem features: Hard real time – no tolerance for missing deadlines Ultra High availability Safety critical Highly distributed
Key west ground control (to taxi to runway) Key West Tower (take off till leaving airport airspace ZMA enroute zone center ZJX enroute zone center ZTL enroute zone center ZDC enroute zone center DC Tower (arrival airport) ground-control (to taxi again)
Could be done physically Could be done to balance the load
Less densely traveled sectors could be made larger
Planes are passed off from
Departure airport -> en route zone center ->…-> arrival airport Also within zone: sector -> sector -> …-> sector before passing to the next center
6
ABC of the Air Traffic Control System
7
Requirements and Quality Attributes
ATC system is highly visible with enormous commercial, governmental and public interest Great potential for loss of life and costly property. Thus the two most important quality attributes were: Ultrahigh availability