模型驱动软件工程的利弊与经验教训
需积分: 5 198 浏览量
更新于2024-09-02
收藏 977KB PDF 举报
"基于模型的软件工程——经验与教训"
基于模型的软件工程（MBSE）是一种利用模型来定义、分析、设计和实现软件系统的开发方法。这种方法在航天工业中得到了广泛应用，尤其是在复杂软件系统的创建中。本论文深入探讨了MBSE的优势、挑战以及实际应用中的经验教训。
优势：
1. **提高效率**：MBSE通过自动化代码生成（AGC）可以显著提高开发效率，减少手动编码的时间和错误。
2. **降低风险**：模型提供了对系统行为的可视化表示，有助于早期发现潜在问题，降低系统风险。
3. **增强可维护性**：模型的抽象性和形式化特性使得软件更容易理解和维护。
4. **提高质量**：使用MBSE和AGC，可以通过严格的验证和验证过程确保软件质量，减少bug的发生。
挑战：
1. **学习曲线**：MBSE技术的学习曲线较陡，需要专门的培训和熟练掌握建模语言。
2. **工具成熟度**：虽然有多种MBSE工具，但它们的成熟度和互操作性仍有待提高。
3. **集成问题**：将模型驱动的组件与传统代码集成可能遇到困难，需要协调不同开发方法。
4. **变更管理**：模型的变更可能影响整个系统，变更管理成为关键且复杂的问题。
经验教训：
1. **需求清晰**：MBSE成功的关键在于清晰、完整的需求定义，否则模型可能无法准确反映系统需求。
2. **团队协作**：MBSE强调跨学科合作，需要所有团队成员理解并参与到模型构建中。
3. **验证与验证**：必须有有效的独立验证和验证（IV&V）策略，以确保模型正确无误。
4. **持续改进**：MBSE实践应随着项目进展不断优化，适应新出现的问题和挑战。
论文通过深入的定性研究和对NASA某任务软件bug报告的定量分析，揭示了MBSE在实际应用中的具体效果。该任务的飞行软件是手工编写代码和AGC的结合，使用两种不同的基于状态图的MBSE方法。研究发现，尽管MBSE和AGC带来了效率提升，但在某些情况下，仍然存在bug，表明即使使用先进的方法，软件质量保障仍然是一个持续的过程。
MBSE提供了一种强大的方法来处理复杂的软件开发问题，尤其是在航天等高风险领域。然而，成功实施MBSE需要克服技术和组织层面的挑战，并不断学习和适应新的最佳实践。
3) MBSwE approach 2: auto-generated code based on
input from specification dictionaries.
The process of auto-generating code from statechart mod-
els is presented in Figure 1. MagicDraw files (.mdxml)
contained statechart models and were used as input to
an in-house developed autocoder running in the Quantum
Framework to generate C code, referred to as AGC-M in this
paper. The parts that were auto-generated using statechart
models were typically the logic portions of that module.
The process used to auto-generate code from specification
dictionaries is shown in Figure 2. The dictionaries, which
contain command and telemetry data, were exported to
an XML format (.xml files), and then passed to two in-
house developed autocoders, which produced C source code
files, referred to as AGC-D in this paper. Code developed
using MBSwE approach 2 was mainly structural, with no
behavioral details. The upper part of Figure 2 (from right to
left) shows a Verification and Validation (V&V) approach
used by the mission. Using an automated event extractor,
XML files (AG-XML) with the command and telemetry
data were auto-generated from the handwritten code and
compared with the dictionary .xml files. If there was a
problem, changes were made and the process was repeated.
Out of 67 modules, only two were fully auto-generated:
one was 100% AGC-M and the other was 100% AGC-D.
The remaining modules with AGC contained handwritten
code. Additionally, some modules contained both AGC-M
and AGC-D. At module level these modules were classified
as AGC-M because, in most cases, they had more AGC-
M than AGC-D code. Each individual file was either 100%
handwritten, 100% AGC-M, or 100% AGC-D. The mission
used a consistent file naming convention, which allowed
us to accurately classify the files based on the specific
development method used.
Note that the three autocoders were developed in-house
with the same rigorousness as the flight software. We are
not aware of any faults found in AGC-M or AGC-D flight
software files that were due to faults in the autocoders.
The developers were allowed to choose whether to hand-
write the code or use the MBSwE approach 1. A total
of seven modules included AGC-M. In general, developers
felt that some specifics of the flight software could not be
accounted for by the used MBSwE tools. Several challenges
were related to the development and use of models. First,
extra effort was needed to develop the models, which
may be overlooked or underestimated. Further, it was an
open question when to stop including details in the model.
Developers also noted that models tend to obscure the lower
level details present in the AGC-M.
As expected, there were challenges related to the readabil-
ity of AGC-M because it is not intuitive and lacks comments.
Developers experience showed that the readability of AGC-
M improved once they acquired knowledge and understood
the patterns used by MagicDraw.
Model
MagicDraw
Statechart file
(.mdxml)
Statechart
Autocoder
Auto-
Generated
Source Code
(AGC-M)
AGC-M
running in
Quantum
Framework
Figure 1: MBSwE approach 1: Auto-code generation using
statechart models (AGC-M)
Dictionaries
XML
specification
files (.xml)
Autocoders
Auto-
Generated
Source Code
(AGC-D)
Autogenerated
XML Files
(AG-XML)
Automated
Event Extractor
Handwritten
Code
Figure 2: MBSwE approach 2: Auto-code generation using
dictionaries (AGC-D)
The software assurance practices of MBSwE based on
statechart models are described next. The developers con-
ducted design reviews using less detailed state charts, but did
not find testing statechart models to be very useful. The fact
that off-nominal cases were not available in the modeling
phase was a drawback. (They were incorporated into the
models later in the lifecycle.) Based on the experience
with previous missions, both models and AGC-M were
committed in the version control system; once committed,
AGC-M was not changed manually. Furthermore, the models
and AGC-M were always kept in-sync and AGC-M was
tested using the same process as handwritten code.
Mission developers experienced several challenges related
to the maintenance of the AGC-M. One challenge was due
to the fact that the mission’s flight software is a combination
of handwritten and auto-generated code. In addition, AGC-
M may be hard to maintain onboard because the modeling
suite, and thus the models, are not available on the onboard
computer console.
For the MBSwE approach 2, which resulted in AGC-D,
the dictionaries were used as requirements documents and
the code auto-generation ensured that the requirements were
in-sync with the code. In general, the development team
found the approach based on dictionaries much more useful
than MBSwE approach 1.
Development of the mission’s flight software took ad-
vantage of modules developed for previous missions, as
well as modules developed as part of a NASA generalized
framework. Specifically, a module was considered reused
剩余10页未读，继续阅读
点击了解资源详情
点击了解资源详情
点击了解资源详情
2024-09-03 上传
2021-09-15 上传
2022-03-04 上传
2022-03-04 上传
2022-01-11 上传
678 浏览量
