软件体系结构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，向上层提供数据库的访问功能。
- 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