Documenting variability in design artefacts

Abstract

The architect has to provide a reference architecture that is flexible enough to cope with the required variability in the design. The variability model allows documenting variability in the development view, the process view, and the code view of the architecture: • Development view: This view deals with the decomposition of a system into layers, subsystems, and components. Variability in the configuration of layers and subsystems is documented in the UML 2 package diagram. Variability in the internal structure of a subsystem, i.e. in the configuration of components, is documented in the component diagram. In both cases, variation points and/or variants of the variability model are associated with variable elements of development view diagrams. • Process view: This view deals (among other things) with the decomposition of system behaviour into processes and threads. Variability in the configuration of processes and threads can be documented in a process table by associating the variability model with process table entries. • Code view: This view deals with the decomposition of a system into files and their assignment to processing units. Variability in the code view is documented in the UML 2 deployment diagram. Component frameworks are created and used to restrict the design choices in a product line and to cope with variability. Plug-in components are essential constituents of a flexible design. However, all other components may have variability as well. Subsystems, components, and interfaces at a low level of abstraction provide internal variability to support the external variability provided by the higher abstraction levels. At these higher abstraction levels variability is mainly influenced by requirements variability. © 2005 Springer-Verlag Berlin Heidelberg.