系列研究 | NASA软件架构描述

NASA软件架构评审委员会建议使用卡内基梅隆大学（CMU）软件工程研究所（SEI）提供的软件架构相关材料为基础进行架构的描述。CMU是软件工程领域绝对的领导者，其中的教授和研究员在长期的工作中积累了大量软件经验和最佳实践的素材，这些可以提供给NASA各中心软件设计和开发人员学习和参考。

关于软件架构描述，SEI网站提供了编写模板、编写指南，以及在线咨询服务等。NASA的软件工程手册也提供了其他的一些模板供参考，包括CMU的testGen和JPL的SMAP。

架构描述术语

关于使用术语，NASA建议使用ISO/ICE/IEEE 42010标准的定义，即“系统与软件工程-架构描述”。如下图是该标准中对相关概念关系的描述： 

任务描述

任何软件架构都是为了满足一个任务的需求，包括飞行系统或地面系统，所以软件架构描述的第一个任务是介绍来自上层的需求，如问题背景或系统概述等。

架构框图

软件架构是关于一个软件系统的，架构框图是描述软件系统与外部世界，以及系统内部各个组成单元的交互关系，包括模块之间的数据流动。软件架构框图应该描述软件与上层系统的边界，并明确说明上层系统的哪些功能使用软件进行实现。

设计约束

架构设计描述应当明确说明设计约束，这些挑战可能来自于功能需求，质量需求，资源限制，以及其他约束等。这里需要明确区分用户需求和设计需求，后者是形成架构设计的主要因素。

关键资源与余量

识别关键资源及余量并在架构描述文档中列出，典型内容包括：非易失性存储、功耗、总线带宽和延迟、上行与下行速率、内存速度等。

相关人员与关注点

列出所有相关人员名单及其关注的内容，如项目负责人关注新技术的风险，系统工程师关注飞行计算机与载荷的交互，测试人员关心可测性，运行人员关注遥测数据的组织形式等。

质量分析

包括对可用性、可修改性、性能、安全性、保密性、可测性、易用性等的考虑，这些必须列入软件架构设计的考虑因素中。NASA软件架构评审委员会提供了质量分析的完整检查单供参考。

性能度量

NASA标准NRP7123.1，即系统工程过程与需求，建议项目建立性能度量，即实际性能与模型期望性能的监视。在软件架构设计时，需要考虑这些性能需求。

设计决策依据

架构描述中应当介绍对问题的理解，评估可行方法以及最终做出决策的过程，这对架构评审以及以后架构复用提供了参考依据。

架构选择

列出所有可选的架构以及选择的理由；如果设计了原型验证系统，需要说明其结果。

多视角视图

不同的相关人员有不同的关注点，而这些关注点需要使用不同的架构描述视角进行介绍，例如组成结构、运行行为、部署方法、操作流程等。下图示出DoDAF的多视角描述示例。

图表描述

使用UML或SysML图帮助说明设计。

复用分析

如果复用了已有的软件，需要描述与前者的差异，成本与风险等。NASA地球科学数据系统软件重用工作组列出了9条关于软件复用的考虑事项可供参考。

假设与限制

为了将来软件复用，应当明确架构设计基于的假设和限制。

设计模式

对于采用的设计模式，如设计原则，模式，不变量，或者采用的规则，进行文档描述，可以有效降低后期开发人员的错误理解比例。

故障管理

描述故障管理与正常系统的关系，以及出现故障时的处理策略。

END

 

点击阅读原文了解更多