...

6

...

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

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

...

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:

...

...

...

...

1. How much of the code can the tool generate?
2. How much will have to be hand-coded?

...

1. Look at the MBDS's history/track record.
2. Determine what, if any, analysis exists to verify the software produced by the MBDS.

...

...

...

1. Choose the right tool for the development environment.
2. Choose the right method for the problem to be solved.
3. Choose tools and methods that will work together.

...

1. Choose MBDS that allows focus to be on the model/design, which is the problem, not the code.
2. Choose MBDS in which the domain knowledge is made explicit for the development team, being captured in the modeling language and its tool support.

...

...

1. Consider importance to project of being able to use different input models.

...

1. Consider how much flexibility is needed to meet project requirements for generated code.
2. 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.
3. 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.

...

...

...

...

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:

...

...

...

1. 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.

...

1. 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.
2. 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.

...

...

...

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:

...

1. Including instrumentation, such as internal or intermediate check points, in production code is problematic as that code has the potential for inadvertent execution.
2. Including instrumentation and then removing it is also problematic as it changes the production code from the tested, verified code.

...

...

1. Invalid models should be rejected by the generator while correct models should be translated properly into code.
2. 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.

...

...

...

...

...

...

...

...

1. Use good modeling principles

   Swerefn
   refnum 250

   , including:
   
   1. Keep the model as simple as possible
   2. Keep the model semantically well-defined
   3. Keep the model organized and manageable
   4. Use a practical point of view: if you aren't going to use it, don't model it
2. Structure the model logically and make it architecturally consistent.
3. Include notations and comments in the model so the purpose of each element/module is clear.

...

1. Include system engineers and software engineers in joint reviews to identify misunderstood or unclear requirements.

...

1. Use separate folders/directories for generated code.
2. Include commentary at the beginning of generated code to clearly identify it as generated.

...

1. Code which is 100 percent generated should neither be changed nor checked into the repository.
2. Code which is 100 percent generated is a disposable good - the important artifacts are the models.
3. 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.

...

...

1. Generated code should satisfy the same quality requirements that apply to manually written code.
2. Generated code should follow applicable coding styles and use well-established design patterns.

...

...

1. 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.
2. A good practice is to maintain a controlled library of accepted, reusable model elements and limit developers to using only approved libraries.
3. A mechanism should exist for getting additional model elements into the approved library.
4. 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: