5.3 Software Architectural Design
The software architectural design activity requires the manufacturer to define the major structural components of the software, their externally visible properties, and the relationships between them. Any software component behavior that can affect other components should be described in the software architecture, such that all software requirements can be implemented by the specified software items. This is generally verified by technical evaluation.
Since the software architecture is based on the requirements, developing the architecture means defining the interfaces between the software items that will implement the requirements. Many of these software elements will be created by the project, but some may be brought in from other projects even in the form of third-party libraries. Such code must be shown to comply with the project’s functional and performance requirements.
In addition, some architectural elements may need to be segregated for risk management purposes, such that their connections to the other elements then become part of the overall architecture. Tools can help in many elements of the architectural design process, including requirements specification, design model traceability, and verification.
If a model-based approach is taken to software architectural design — for example, using MathWorks® Simulink®, IBM Rational Rhapsody®, or ANSYS® SCADE — then a tool suite that is integrated with the chosen modelling tools will make the analysis of generate code and traceability to the models far more seamless.8–10
5.4 Software Detailed Design
Once requirements and architecture are defined and verified, detailed design can be built on this foundation. Detailed design specifies algorithms, data representations, and interfaces between different software units and data structures. Because implementation depends on detailed design, it is necessary to verify the detailed design before the activity is complete, generally by means of a technical evaluation of the detailed design as a whole, and verification of each software unit and its interfaces.
Fig. 4 Diagrammatic representations of control and data flow generated from source code by the LDRA tool suite aid verification of software architectural and detailed design.
Later in the development cycle, a tool suite can help by generating graphical artifacts suited to the review of the implemented design by means of walkthroughs or inspections. One approach is to prototype the software architecture in an appropriate programming language, which can also help to find any anomalies in the design. Graphical artifacts like call graphs and flow graphs, are well suited for use in the review of the implemented design by visual inspection (see Figure 4).
Part 2 of this article will look at the second part of the project life cycle involving the implementation of the now-established design in the form of source code. It will consider how static analysis can help to ensure that coding rules are adhered to, helping to minimize errors in the developed application. It will discuss how dynamic analysis in the form of system and unit tests show that the design has been implemented correctly and completely, and that the software has been properly exercised during test and prior to release. Finally, it will outline how the influence of IEC 62304 extends to the maintenance and modification of the product once out in the field.
This article was written by Mark Pitchford, Technical Specialist for LDRA (Wirral, UK).