Comment:
Migration of unmigrated content due to installation of a new plugin
Set Data
hidden
true
name
reftab
6
Tabsetup
1. Intro
1. Intro
1
2. Determining the need for MBDS
2
3. Choosing MBDS
3
4. Issues and Pitfalls, Practices to Avoid
4
5. Recommended Practices
5
6. Resources
Div
id
tabs-1
1. Introduction
Model-based software development uses a model as the centerpiece of the development process. Software engineers create a model of the system behavior that can then be translated into different languages such as C or Ada by the appropriate code generator. The model is continually refined throughout the development process and can even be executable. For maximum benefit, the generated code should not be modified by software engineers; when changes are desired, the model is revised and code is generated from the revised model.
Both the modeling tool and the code generation tool are part of a toolset that makes up the model-based development system, referred to in this guidance as MBDS.
Efficiency is a key benefit of using MBDS, but there are many considerations to be reviewed when deciding whether MBDS is the right choice for a project. For a list of pros and cons, see the
Tablink
1
Determining the Need for MBDS
tab
2
linktext
Determining the need for MBDS
section of this guidance.
1.2 Purpose
This document addresses guidance for projects that desire to use MBDS. This guidance addresses:
Identifying the need for MBDS.
Choosing an appropriate MBDS.
Practices to avoid.
Recommended practices.
1.3 Roles
Role
Responsibility
Project Manager
Approves MBDS acquisition
Software Project Lead
MBDS analysis and selection, project procedure development
Software Engineers
Carrying out recommended practices
V&V Personnel
Receive, verify and validate MBDS tools, auto-generated code
Div
id
tabs-2
2. Determining the need for MBDS
Before automatically assuming that MBDS is the right choice, it should be determined whether this type of system is appropriate for the project. The following questions should be addressed when making this determination:
Why does the project want to use MBDS? What is the benefit to the project?
What is the team's experience with software development using MBDS?
What are the pros and cons of using MBDS? Are there specific pros and cons to be weighed for this project?
General pros:
Shifts the focus from implementation to design
Swerefn
refnum
244
allowing the focus to be on the problem being solved.
Can improve productivity, quality and complexity hiding.
Swerefn
refnum
244
Can provide consistent products and lower error rates.
Swerefn
refnum
244
Can create optimized efficient implementations.
Swerefn
refnum
226
Helps avoid programmer errors such as typos, pointer problems, etc.
Swerefn
refnum
226
Can enforce programming practices.
Swerefn
refnum
226
Can provide for shared resource protection, memory management, code and data optimization, process and data distribution, bug avoidance, less testing, and reuse.
Swerefn
refnum
226
Can adapt quickly to changes in requirements.
Swerefn
refnum
226
Increases productivity by maximizing compatibility between systems, simplifying the process of design, promoting communication between individuals and teams working on the system.
Swerefn
refnum
253
Helps recognize problems early on and reduce risk.
Reduces iterations in the development cycle, reducing development time and cost.
General cons:
MBDSs are typically not qualified; therefore, there is no guarantee that their output is correct.
Swerefn
refnum
193
"Code reviews are still necessary for mission-critical applications, but the generated code is often difficult to understand..."
Swerefn
refnum
193
"Common modeling and programming languages do not allow important requirements to be represented explicitly (e.g., units, coordinate frames, quaternion handedness); consequently, such requirements are generally expressed informally and the generated code is not traced back to these requirements."
Swerefn
refnum
193
"Writing documentation is tedious and therefore often not completed or kept up to date."
Swerefn
refnum
193
"Limited code generation possibilities force developers to start manual programming after design. This kills the idea of full code generation and minimizes the productivity benefits."
Swerefn
refnum
244
Flaws in parsers or generators can have wide effects downstream.
Swerefn
refnum
226
Will the amount of code the project will be developing warrant/justify the use of MBDS?
Does the project or Center already have MBDS that can be used or will the project need to purchase, rent, or develop MBDS? What are the pros and cons of each option?
How will using MBDS affect the maintenance of the developed code?
Div
id
tabs-3
3. Choosing MBDS
Once the decision has been made that MBDS is appropriate for a project, the actual system needs to be selected. When choosing a system, the following considerations should be included in the decision-making process:
Ensure each MBDS is verified to provide confidence in the products produced.*
Swerefn
refnum
226
When project needs require creation of in-house MBDSs, create them in compliance with NPR 7150.2.
Swerefn
refnum
226
Consider the suitability of the modeling language for representing the problem.
Swerefn
refnum
276
Consider the sufficiency of modeling constructs for generating code by answering the following questions:
Swerefn
refnum
276
How much of the code can the tool generate?
How much will have to be hand-coded?
Consider the maturity of MBDSs for generating quality code.
Swerefn
refnum
369
Look at the MBDS's history/track record.
Determine what, if any, analysis exists to verify the software produced by the MBDS.
Consider the MBDS's integration with other project tools, such as debuggers or static analysis tools.
Swerefn
refnum
276
Consider methodologies used by the MBDS for translating design into code.
Swerefn
refnum
276
Select MBDS appropriate to the current application.
Swerefn
refnum
276
Choose the right tool for the development environment.
Choose the right method for the problem to be solved.
Choose tools and methods that will work together.
Consider whether the project team has sufficient understanding of the MBDS to be able to use it efficiently.
Consider the domain-relevance of the MBDS.
Swerefn
refnum
244
Choose MBDS that allows focus to be on the model/design, which is the problem, not the code.
Choose MBDS in which the domain knowledge is made explicit for the development team, being captured in the modeling language and its tool support.
Consider the language in which the MBDS generates the source code.
Swerefn
refnum
276
Consider input models required for translators.
Swerefn
refnum
369
Consider importance to project of being able to use different input models.
Consider project needs of generated output.
Swerefn
refnum
369
Consider how much flexibility is needed to meet project requirements for generated code.
If each mission can impose its own coding standards for the code being generated, then the flexibility of the output of the generator is important.
Consider whether the project has a need for generating multiple forms of code from the same input, such as 1) C/C++ code, 2) a model representation that can be run through a model-checking tool and 3) a model that can be executed in simulation.
Consider project needs for coordinated use of the MBDS by development team members, including members in various locations and members responsible for various parts of the model.
Swerefn
refnum
245
Consider potential for reuse of the MBDS on future projects.
Swerefn
refnum
226
Consider whether the project will need to maintain a specific version of the MBDS for as long as the code is in use.
Consider whether the company that produced the MBDS will support the system if it is used over the long term.
Tablink
1
See also Recommended Practices section.
tab
5
linktext
also see Recommended Practices
Div
id
tabs-4
4. Issues and Pitfalls, Practices to Avoid
As with any development methodology, there are issues associated with MBDS and practices that can result in unintended consequences. To ensure the best outcome for a project using MBDS, the following recommendations should be part of the process of developing associated procedures:
Use a model to generate the code and do not simply develop a model in parallel with the code.
Swerefn
refnum
226
Don't generate algorithms as part of the design without a requirement to which they can be traced and verified.
Swerefn
refnum
226
Beware of customized versions of "reused" MBDS.
Swerefn
refnum
226
MBDS which are maintained internally (e.g., project or center) can have customizations and/or bug fixes that may not be documented or that may have side effects.
Testing of the model should not replace thorough system testing.
Swerefn
refnum
369
One advantage of MBDS is moving some of the testing activities earlier in the life cycle. If major problems are found, they can be resolved with less impact on the budget or schedule of the project.
Disadvantages include a reliance on the automatically generated source code (which may not be generated correctly) and the difficulty of knowing how well the model conforms to reality. Interactions between parts of the system may not be evident until the system is operational.
Avoid including too much detail in a single state chart model (may obscure overall functionality).
Swerefn
refnum
369
Avoid including too little detail in a single state chart model (may render the state chart content-less).
Swerefn
refnum
369
Don't forget to consider the costs of additional training for developers who have never used this type of tool. These costs result in a first time start up cost from a schedule perspective.
Don't forget that all developers need to understand the model, not just the resulting code.
Don't forget to maintain the MBDS throughout the life of the code's use.
Don't forget to consider support costs when choosing MBDS. The company may not support the tool if the use planned is very long. This is similar to COTS pitfalls
Don't forget to consider that inefficient code generated by MBDS may not run sufficiently fast or may use greater resources than hand-developed code.
Div
id
tabs-5
5. Recommended Practices
The following practices, collected from a variety of sources, are recommended practices when using MBDS in a project. These practices should be considered when developing project or center procedures for the use of MBDS:
Evaluate OTS MBDSs for best project fit and to ensure produced code is closest to production code as possible (no residual code, dead code, instrumentation, etc.).
Swerefn
refnum
226
Including instrumentation, such as internal or intermediate check points, in production code is problematic as that code has the potential for inadvertent execution.
Including instrumentation and then removing it is also problematic as it changes the production code from the tested, verified code.
Test the MBDS using a reference model
Swerefn
refnum
133
, a graphical test model which allows the functionality of the generator to be confirmed as operating correctly.
Swerefn
refnum
160
Invalid models should be rejected by the generator while correct models should be translated properly into code.
Correct functioning of the generator can be ensured if the test model and the generated code behave the same when subjected to the same stimulus/test data.
Verify the correct translation from design to code for safety-critical software.
Swerefn
refnum
226
Consider running tests against parsers, generators, and configuration data as early as possible; finding bugs early avoids potential problems downstream.
Swerefn
refnum
226
Conduct evaluation/verification/qualification for every version of the MBDS.
Swerefn
refnum
193
Conduct evaluation/verification/qualification for each project that uses the MBDS.
Swerefn
refnum
193
Repeat evaluation/verification/qualification if MBDS is updated during the project.
Swerefn
refnum
193
Once the MBDS has been thoroughly reviewed and the resulting code validated, review efforts for that project can focus on the designs rather than the implementations.
Swerefn
refnum
369
If marketing to others that developed code is model-based, ensure a model is used to generate the code and not simply developed in parallel with the code.
Swerefn
refnum
226
Ensure the model is the best, clearest it can be since the model is the root / basis of the generated code.
Swerefn
refnum
226
Use good modeling principles
Swerefn
refnum
250
, including:
Keep the model as simple as possible
Keep the model semantically well-defined
Keep the model organized and manageable
Use a practical point of view: if you aren't going to use it, don't model it
Structure the model logically and make it architecturally consistent.
Include notations and comments in the model so the purpose of each element/module is clear.
Subject the model to the same level of scrutiny and review as source code.
Swerefn
refnum
369
Include system engineers and software engineers in joint reviews to identify misunderstood or unclear requirements.
Separate generated and manual code.
Swerefn
refnum
133
Use separate folders/directories for generated code.
Include commentary at the beginning of generated code to clearly identify it as generated.
Don't check in generated code.
Swerefn
refnum
133
Code which is 100 percent generated should neither be changed nor checked into the repository.
Code which is 100 percent generated is a disposable good - the important artifacts are the models.
The only time it can make sense to check-in generated code is when, for some reason, it is impossible to integrate the generator run into the build process.
Integrate the generator portion of the MBDS into the build process.
Swerefn
refnum
133
Generate clean code.
Swerefn
refnum
133
Generated code should satisfy the same quality requirements that apply to manually written code.
Generated code should follow applicable coding styles and use well-established design patterns.
When the code is safety-critical, or resides in an unprotected partition with safety-critical code, the automatically generated code should be subjected to the same rigorous inspection, analysis, and test as hand-generated code.
Swerefn
refnum
276
One of the primary means by which MBDS gain programming efficiency is through the use/reuse of libraries that raise the level of abstraction. This is not unique to MBDS, but seems to be more prevalent.
Make an effort to understand what details are being abstracted and make a conscious choice as to whether the team will be comfortable with the level of abstraction provided.
A good practice is to maintain a controlled library of accepted, reusable model elements and limit developers to using only approved libraries.
A mechanism should exist for getting additional model elements into the approved library.
Each project may need to review the library set for suitability for that application. For example, a model element that is acceptable for processing data on the ground may not be acceptable on a real-time flight control system.
Additional guidance related to auto-generated code may be found in the following related requirement in this Handbook: