|
Layering decomposes a complex system and extracts a structural architectural description (cf. the ‘layers’ pattern [1,2]). This allows to dissect hierarchically organised system designs into a stack of dependent layers in order to not only tackle system complexity, but also in order to prioritise particular system characteristics in the design process. Hierarchy in general relates to the level of functional granularity encapsulated by software components involved, i.e. high-level or functionally more granular components head the structural hierarchy, while low-level or functionally finer granular components are to be found at the bottom of the stack. The overall goal of this structural form is to vertically decouple along intended system characteristics.
The overall intention of viewpoints in modeling is the construction of a set of partial models of an information system and its requirements from the isolated perspective of single stakeholders. Views and viewpoints are selected deliberately according to their ability to convey the essential information about an architecture (see [3]).
Intended qualities of a system are discussed as non-functional requirements, also known as quality attributes of architectures and information systems. On the one hand side it is difficult to transpose quality attributes into operative, formal, and structured design guidelines. On the other hand they often intrinsically conflict with each other (calling for design trade-offs). Nevertheless, the codification of linkages between intended quality attributes and the chosen architectural design are vitally important. Quality attributes include, for example, particular performance, security, usability, adaptability, awareness, or seamlessness goals.
A simple definition of the pattern concept is, that it is an “especially clever and insightful way of solving a particular class of problems” [4]. The flexible and tested solution of a problem is turned into an abstraction and put into the form of a design pattern. This formalized representation holds information on surrounding forces — the context, the problem, and the solution, i.e. finding an equilibrium between forces [5].
– Stefan Sobernig, Fridolin Wild
[1] Shaw, M. (1996). Some Patterns for Software Architectures. In John Vlissides, James Coplien, and Norman Kerth (Ed.), Pattern Languages of Program Design (pp. 255-269). Addison-Wesley.
[2] Avgeriou, P., Zdun, U. (2005): Architectural Patterns revisited – A Pattern Language. Proceedings of 10th European Conference on Pattern Languages of Programs (EuroPlop 2005), pp. 1-39.
[3] Clements, Paul, Rick Kazman, Mark Klein (2002). Evaluating Software Architectures – Methods and Case Studies. Addison & Wesley.
[4] Bergin, J, Eckstein, J., Manns, M.L., Sharp H. (2002): Patterns for Active Learning; http://csis.pace.edu/~bergin/patterns/ActiveLearningV24.html
[5] Coplien, J.; Software Patterns; SIGS Publications; 1996.
|
iCamp feed