The development of systems consisting of hardware and software is a challenging task for the system architect. On the one hand, he has to consider an increasing number of system requirements, including the dependencies between them for designing the system architecture; on the other hand, he has to deal with a shortened time-to-market period and requirements changes of the customers up to the implementation phase. This chapter presents a process that enables the architect to validate the system architecture against the architecture-relevant requirements. The process is part of the system design phase and can be integrated in the iterative design of the system architecture. In order to keep track of all requirements, including their dependencies, the architect clusters the requirements according to architecture-specific aspects, the so-called validation targets. For each target he defines examinations processes and check criteria to define the validation status. If all targets are valid, i.e., all check criteria are met by the result of the examination processes, the system architecture itself is valid. Instead of formal validation techniques like model checking, the approach prefers simulations for the examination processes. The approach uses model-based documentation based on the Unified Modeling Language (UML). All data required for the simulations is part of an UML model and extracted to configure and run the simulations. Therefore, changes in the model affect the validation result directly. The process supports the architect in building a system architecture that fulfills the architecture-relevant requirements, and it supports the architect in analyzing the impacts after requirements or architecture changes. A tool facilitates the work effort of the architect by partly automating the major process steps.
TopMotivation
One major challenge in developing products consisting of hardware and software components is to create an architecture, which is consistent with the requirements. Such products or systems are specified by a continually growing amount of requirements, which are additionally linked to one another. This creates an increasing system complexity that the system architect has to deal with. The markets demand the system’s customer to react flexible on changing conditions. As a consequence, the customer wants to influence the system development not only up to the system analysis but also up to implementation. These continually changing requirements make it difficult for the system architect to create and maintain the system architecture.
Although the architecture is the foundation of the system and changing it in a later development phase causes much effort and therefore money, architecture validation, i.e. checking if all architecture-relevant requirements are met, is often part of the system development in name only. According to our experiences, if anything, the validation is performed only once and almost at the end of the design phase. One reason might be that it is a time- and work-consuming task for the architect that has to be repeated each time requirements change. Another reason might be the often applied informal techniques, e.g. reviews, which are tedious and rely on human interpretation and subjectivity. These techniques do not generate reproducible validation results or provide automation possibilities. Therefore, they are not suitable for a system development with ever-changing requirements. Formal techniques like model checking are more suited for this task. Nevertheless, despite of their capability, the acceptance and usage in industry is very low (Woodcock, Larsen, Bicarregui, & Fitzgerald, 2009).
To support the architect in validating the system architecture under the conditions described above, we developed a validation process for system architectures using dynamic validation techniques like simulations (Debabbi, Hassaine, Jarraya, Soeanu, & Alawneh, 2010) based on the Unified Modeling Language (UML). It can be integrated into the iterative process of creating system architectures and is therefore part of the system design phase. Figure 1 shows the validation process in the context of the first system development phase’s system analysis and system design. The results of the system analysis are input for the system design whereas the results of the design phase are also input for the system analysis. Both phases and the architecture validation process need the system requirements. The architect creates a system architecture using the results of the system analysis and the requirements. It is validated by using the architecture-relevant requirements and validation-specific information. The validation process provides the architect an architecture-specific view on the requirements enabling him to handle the amount of requirements including their interconnections. This view is created by identifying validation targets which describe an architecture-specific aspect. A target is linked to all aspect-specific requirements reducing the amount of elements which have to be taken into account by the architect for the architecture validation. The architecture in its entirety is valid if all targets are valid. The validation statuses of the targets are checked by examination processes which use the information modeled in UML for their configuration. If the system architecture is invalid, the process provides the requirements which are not fulfilled and detailed information about the examination processes for problem analysis. After modifications of the architecture or requirements the architect reruns the validation process. The process provides automation possibilities to minimize the effort which can be done by machine.
Figure 1. Validation process in the context of system analysis and design