Authors:
Fabian Gilson
and
Vincent Englebert
Affiliation:
University of Namur, Belgium
Keyword(s):
Software Architecture, Design Method, Design Rationale, Traceability, Model Transformation.
Related
Ontology
Subjects/Areas/Topics:
Domain-Specific Modeling and Domain-Specific Languages
;
Frameworks for Model-Driven Development
;
Languages, Tools and Architectures
;
Methodologies, Processes and Platforms
;
Model Transformation
;
Model-Driven Software Development
;
Models
;
Paradigm Trends
;
Software Engineering
Abstract:
Stakeholders have to face requirements in increasing number and complexity. Their translations to system
functionalities are often diluted into the overall architecture so that it becomes tricky to undertake future
changes. Since information systems are intended to evolve in terms of functionalities and underlying technologies,
the link between requirements and design artifacts is primordial. Agile design methods and documentation
techniques have emerged in the past years in order to deal with the amount of requirements and to
trace the decision process and the rationale sustaining a software model. Also, it is not unusual that numerous
technologies with similar purpose are confronted to each other during the design phase. In the present work,
we propose an integrated framework combining system requirement definitions, a component-based modeling
language and model transformations. Architecturally-significant requirements are explicitly linked to software
architecture elements and ite
ratively refined or implemented by model transformations. Any transformation
must be documented, even briefly, and the framework retains the transformations tree. This way, the iterative
decision and design processes are completely documented for future reference or modification, i.e, designers
can (i) see the mapping between a system requirement and its implementation in the architecture model, (ii)
explore design alternatives or apply structural modifications without losing previous versions of the model,
and finally (iii), depending on the level of documentation, at least understand partially the reasons why the
model is how it is.
(More)