Demystifying Software Coupling in Embedded Systems PDF Print E-mail
Article Index
Demystifying Software Coupling in Embedded Systems
Annex A
Annex B
All Pages

By José Andrés Thuel, Software Engineer, Avionyx.

The purpose of this paper is to help clarify some common misunderstandings about software coupling for embedded software development projects. It explains the concepts of software coupling, and the importance of taking software coupling into consideration during the software life cycle. Finally it provides guidelines on how to improve the project’s standards and coding practices to reduce the impact that software coupling has on the project’s complexity and delivery time.

This paper was written to provide a better understanding of the requirements in DO-178B standard related to software coupling; however, it is also applicable to other software fields.

What is Software Coupling?

Software coupling is defined as the degree to which a software module relies or depends on other modules. Generally speaking, it is desirable that the coupling between software modules is “low” or “weak”. [1] This concept will be explained in the next section.

By lowering the level of coupling, the structure of the software is enhanced, becoming more readable and maintainable. [2] Annex A describes the different levels of coupling and how they affect a program’s structure.

So, why is Software Coupling a Problem?

When a system has a “high” degree of software coupling, changes in one module affect other modules (ripple effect), and, therefore, reusability of the code is reduced. This can certainly become a headache for the programmer. Each time that a bug is fixed, new issues can arise due to the complexity of the relationships between modules. Adding and removing functionality can also be an arduous task and partitioning can be nearly impossible.

When modules are highly coupled, each one becomes harder to understand and more difficult to test. This will undoubtedly affect the verification process negatively, potentially resulting in impact to both schedule and budget.

Determining whether or not the software structure was completely covered by the testing process is a fundamental part of the software verification effort. This is usually accomplished by performing reviews and analysis of the software architecture and source code, and properly implementing a requirement-based testing approach. [3] However, if control and data flow of the program are not clearly defined and relationships between modules have not been properly documented, the verification effort will grow. Likewise, without clearly defining which modules can modify or initialize global data, problems will arise.

When to Worry about Software Coupling

Based on the DO-178B guidelines, software coupling should be taken into consideration, at a minimum, during the following activities: [4]

  • Partitioning
  • Code Reviews
  • Structural Coverage Analysis
  • Modification of Previously Developed Software

However, to facilitate the transition between life cycle phases and to help identify and reduce the impact of software coupling issues, it is best to take software coupling into consideration in all life cycle phases.

How to Identify Software Coupling Issues

The following recommendations are the result of many lessons learned over more than 20 years and hundreds of embedded software projects. These recommendations should help to avoid software coupling issues in your future software engineering projects:

1. Planning: The plans and standards are the first place where software coupling has to be addressed. The software design standard, software verification plan and coding standard should all consider software coupling and describe the activities to be performed in order to identify software coupling issues.

2. Requirements phase: It is important to define the necessary dependency requirements for all the interfaces between the system’s components. The data that will be shared, as well as the arguments and return values, need to be properly documented. The correctness of these software coupling relationships should be reviewed before advancing to the design phase of the project.

3. Design phase: Developers should include a clear description of the data and control flow of the system. The Data Dictionary is used to document all the data structures in the code. Proper description for each individual function is also needed, as well as a specification of the data that they access, and their return values (if any), input data, calling trees and prototypes.

The design needs to encourage a high level of cohesion and structure in which the functions or methods are created to perform specific tasks. Functions should not exceed a certain size, and they should not receive parameters that significantly affect the function execution. It is also recommended that the allocation of memory be established, global variables are minimized and global data is properly initialized before being used.

Another way to control the level of software coupling is to assign a quantifiable value to the degree of coupling that a module can have (see Annex B), and then set a maximum value for this measurement in the corresponding standard. This has the advantage of being flexible since it allows some level of software coupling but also provides limits.

A design standard should provide all these guidelines, which are necessary to ensure that the design documents are clear enough regarding the software coupling between modules.

4. Coding phase: In this phase it is crucial that the coding standard properly references the subject of software coupling. The coding standard should include the acceptable forms of software coupling to be used, as well as the rules that the programmers should consider when implementing them.

One solution that will help to limit the degree of software coupling is to prohibit some of the levels of software coupling from being used. For example: “the use of content coupling is strictly forbidden” (content coupling is explained in Annex A).

Additionally, code reviews should ensure that the intended software coupling characteristics between the software components were exercised according to the design documentation specifications. Static code analysis tools can be used to simplify this task. However, if used for credit, the tools will have to be qualified for DO-178B certification.

5. Integration phase: In this phase, link analysis is done to ensure that there are no missing or additional functions in the executable code. This will guarantee that all the desired components are present and that all the software coupling dependencies defined in the requirements and design phases are implemented in the software.

6. Verification phase: Testers should ensure that not only are they properly testing the requirements, but that they are also exercising the system’s documented software coupling relationships.  Test cases should be reviewed to ensure that they cover all software coupling scenarios. This is meant to provide definitive proof that the degree of software coupling is not causing unexpected or erratic behavior.

Depending on the complexity of the system, a software coupling analysis may also be required if the level of coupling is very high.

The structural coverage analysis should confirm that the coupling relationships were properly tested. Otherwise, it is necessary to develop more tests to guarantee that the dependencies in the system are functioning appropriately.

Conclusions and Further Activities

If software coupling is not considered seriously during the planning, development and verification process of a software engineering project, there is a higher risk of producing weak and unsafe software. The result of this is increased maintenance and verification costs and delays in delivery time.

The approach proposed here spreads the effort through the entire software life cycle, reducing the associated risks mentioned above. This approach facilitates the quick identification of problems and makes their solution easier to implement.

The advantages obtained by reducing the degree of software coupling during development include:

  • Avoiding the ripple effect due to module updates
  • Identifying bugs that may not have been identified through other verification methods
  • Reducing development and maintenance time and cost
  • Increasing code reutilization

Reducing the degree of software coupling also makes the following verification activities easier:

  • Understanding of the code
  • Code reviews
  • Test case development
  • Structural coverage analysis
  • Analyzing technical issues

Software Coupling should also be incorporated into training materials for your engineering staff to ensure that personnel are qualified to deal with this topic. A metrics system to determine a module’s degree of software coupling can be useful as well. This was hinted as a suitable approach in section 3, but it is not covered in detail on this paper. A brief example of a method to measure the degree of software coupling is given in Annex B.

[1] Constantine Larry and Yourdon Ed. Structured Design. Englewood Cliffs, N.J.: Prentice-Hall, 1979.

[2] Certification Authorities Software Team. Position Paper CAST-19: Clarification of Structural Coverage Analyses of Data Coupling and Control Coupling, revision 2, January 2004.

[3]: RTCA, Inc. DO-178B: Software Considerations in Airborne Systems and Equipment Certification. Section 6.4.4.

[4]: RTCA, Inc. DO-178B: Software Considerations in Airborne Systems and Equipment Certification. Sections 2.3.1, 6.3.4, 6.4.4 and 12.1.1

AddThis Social Bookmark Button