AbstractSoftware architectures are meant to represent complex systems often composed by many components interrelated by different communication facilities and deployed on complex infrastructures. Architecture models depict systems at different levels of detail and must take into account multiple requirements and constraints. Without an appropriate documentation, retrieving the links between a model and its concerns may be troublesome. By loosing the design rationale, part of the architectural knowledge is lost, but recording such knowledge and the links to architectural parts is highly time consuming, even if its utility is vastly recognized.
With the multiplicity of deployment constraints, in terms of computational architectures or storage resources for example, the amount of explored alternatives also increases. Likewise, those alternatives are meaningful piece of information and are an important part of the architectural knowledge.
Many versions of a system may also co-exist and the delta between each model is sometimes arduous to identify. The traceability of evolutions between subsequent versions of a model may be useful to isolate reusable architectural patterns. The other way around, injected patterns may be scattered all over a model so that they are not recognizable anymore.
In the present thesis, we propose an architectural framework that closely relates software architectures to their requirements with their rationale, mainly in terms of design decisions. The framework relies on specific languages for component-based modeling, requirement listings and model transformations. We propose a transformation-wise approach where architectural changes are applied and documented by stepwise model transformations. These transformations play the role of traceable model evolutions that may be extracted and reproducible in different contexts, under some conditions.
Meanwhile, architecturally-significant requirements are recorded in particular listings where software engineers may refine their definitions or explore design alternative solutions. All these requirements with their decisions may be further documented with their rationale to explain the reasons why the decision has been taken, its strengths, weaknesses, hypotheses or constraints under which they have been evaluated.
|Date of Award||2 Mar 2015|
|Supervisor||Vincent Englebert (Supervisor), Naji Habra (President), Patrick Heymans (Jury), Laurence Duchien (Jury) & Antoine Beugnard (Jury)|
- architecture framework
- software architecture
- model transformations
- design rationale
- design decisions
- design method