Software Design: towards a meta-architecture to support decision making in the
definition of Software Architecture
Luis Roqu Fourcade*, Liliana Arakaki*, Daniel Riesco*, Germn Montejano *, Narayan Debnath
*
Departamento de Informtica - Universidad Nacional de San Luis
Ejrcito de Los Andes 950, San Luis, Argentina
{araroq, liliana.arakaki}@yahoo.com, {driesco, gmonte}@unsl.edu.ar
Computer Science Department - Winona State University
Winona, MN 55987, USA
[email protected]Abstract
The methods and techniques provided by Software
Engineering give wide support to the activity of specifying
practically all artifacts produced by the activity of Software
Design. In return, they provide little support to the core and
typical activity of the Software Design: synthesis and
evaluating of alternatives for decision making. This status
leaves this activity, paradoxically for an engineering
process, almost completely to chance to the developers
expertise level. This paper gives a proposal for a metaarchitecture based on a definition of Software Design
extended to consider the input of Software Design Patterns1
and within the framework of the Model Driven Architecture
(MDA) approach [1]. Such meta-architecture anticipates a
set of decisions and restricts the universe of evaluation for
many others supporting the activity of synthesizing and
evaluating alternatives for decision making, significantly
improving the engineering profile of Software Design
activity.
1. Introduction
From the early acknowledgements of the so-called
software crisis [2], there have been many efforts to
provide the software development process with a method
that turns it into an engineering process.
One of the directions towards which work is done
intensely attempts to reach an evolutionary status similar to
that of other better-developed engineering. These have
achieved a high degree of reusability with a wide range of
granularity from atomic components to finished products,
passing through components structured on other. This
direction constitutes a key aspect in the global process of
maturity of the Software Engineering, as it defines a
development philosophy and induces a common footprint to
the different current and future methods and techniques.
The great challenge consists of advancing in the acquisition
of knowledge on different domains (of application and
1
By Software Design Patterns, we refer to patterns that apply to the result
of the Design Software process, regardless of any classification or
category. Henceforth we use the term patterns to refer to this concept,
except in those cases where it is necessary to clarify explicitly.
technology) representing it in such a way that it can be
translated into atomic and/or structured components
susceptible of being reused in various processes of software
product development.
The advances incorporated by current methods and
techniques are really significant. In the area of
specifications, by means of languages and standards
supporting the specification of all software devices
involved in the development process. In the area of process,
through identification and consideration of the activities
required for building such specifications. However, in the
area of process, even more significant advances are
required in the short term. This is because such
specifications describe essentially static aspects of the
activities and lack support more connected to the execution
of the activity. This situation is reflected in multiple aspects
of current methods and techniques. For example, the
interpretation of the requirements for the system, design
and construction decision making of a software product
capable of fulfilling them are left almost completely to
chance to the developers expertise level. None formally
incorporates rules that support the activity of synthesizing
and evaluating alternatives for the decision making, which
is central and occurs in a repetitive way in the process of
Design of Software.
2. Objective
In the context of the problem area described, this paper
aims at presenting an approach that proposes a metaarchitecture as the formalism that allows abstracting
reusable knowledge anticipating decisions of design and
restricting the universe of evaluation required for the
unanticipated decision making.
This paper proposes proving that on the MDA approach
[1], it is possible to extend the suggested meta-architecture
with abstractions that allow for the dynamic formulation of
mechanisms that provide effective support to the activity of
synthesizing and evaluating alternatives for the decision
making
3. Background and state of the art
3.1. Software Design
Having a good definition of Software Design is key to the
proposed objective. Due to the fact that there is no current
consensus on a standard definition of Software Design, this
paper is based on the proposals formulated by Yair Wand
and Paul Ralph and by Frank Buschmann et al. described
below.
3.1.1. Proposal of Yair Wand and Paul Ralph
Yair Wand and Paul Ralph summarize conclusions based
on a very thorough investigation in the literature on design
and focus their proposal on the structure and organization
of the design process from an abstract point of view,
independent of the domain [3].
Design as an object (noun): specification of an object
(the design object), developed by an agent, intended to
fulfil objectives in the particular environment using a set
of primitive components, satisfying a set of
requirements, subject to restrictions .
Design as activity (verb): activity, developed in an
environment (in which the agent works), with the aim of
creating a design.
3.1.2. Proposal of Frank Buschmann et al.
In [4], the authors present a categorization and a system
of patterns in order that this system of patterns be the
essence of an orientation approach by patterns of Software
Architecture presented. Thus, the presented approach
requires knowledge of the design activity, at least to a level
of abstraction consistent with the architectural design.
Software Design is the activity performed by a software
developer resulting in software architecture of a system.
It addresses specifying the components of a software
system and the relationships between them within
functional and non-functional properties given.
Software Architecture is a description of the
subsystems of a software system and the relationships
between them. Subsystems and components are
typically specified in different views to show the
functional and non-functional relevant properties of a
software system. The software architecture of a system
is an artefact. It is the result of the design activity.
This definition, provided by Buschmann et al, is entirely
consistent with the proposal by Ralph and Wand and many
of their definitions can be considered as a specialization in
the domain of software engineering.
3.2. Software Design Patterns
The patterns approach represents a valuable contribution
in addressing the complexity associated with the activity of
Software Design. This is because, a pattern represents the
abstraction of a set of design decisions which is not any set
but one that guarantees certain properties (functional and
non-functional) in the resulting design specified by the
system requirements.
The patterns have properties that position the approach as
an ideal resource to assist the design activity. A pattern is
both an object that encapsulates knowledge of a particular
domain and a rule indicating when and how to use it [4].
For this reason, an pattern can act as a guide and / or
framework for the process of synthesizing and decision
making.
According to Alexander, a pattern describes a problem
that occurs once and again in our environment, and
describes the essence of the solution to such problem, so
that it can be used a million times without even doing it the
same way two times [5].
In the domain of Software Engineering Buschmann
specializes this definition as follows:
A Pattern for the Software Architecture describes a
particular and recurrent design problem that emerges in
specific design contexts, and presents a generic scheme
proven for its solution. The solution scheme is specified
though the description of its constitutive elements, its
relationships, responsibilities and ways to collaborate [4].
Therefore, we may consider a Software Design Pattern as
the abstraction of particular design cases specialized for a
particular Context and Problem providing a generic
Solution Scheme.
From a perspective more orientated to the activity, it
could be stated that the design activity is essentially a
decision making activity and, in this sense, the generic
Solution Scheme for this Context and Problem, acts as a
model which anticipates a set of design decisions and
restricts the universe of evaluation for another set of
decisions which are basically dependent of the application
domain for which the design activity is being executed.
From another perspective, Christopher Alexander,
affirms that a pattern is both the description of the object
and the description of the process that will produce such
object [6].
3.3. Model Driven Architecture (MDA)
The MDA approach [1], given by the Object
Management Group (OMG) [7] allows deriving the value
of models and architecture to support the complete life
cycle of physic, organizational and IT systems, with the
objective
of
helping
manage
complexity and
interdependence in complex systems.
3.3.1. Meta-modelling architecture based on MOF
The meta-modelling is a key concept in MDA. The
MDA approach defines, for this activity, an architecture
based on abstraction levels where each level defines a metamodelling level which is more specific that the higher level
and more abstract than the lower level.
o Platform Independent Models (PIM): oriented to the
logic modelling of the problem without including
decisions related to the platform.
o Platform dependent Models (PSM): oriented to the
design modelling of the solution in terms of the
platform
Implementation Models: By being linked to a
particular platform, they are often regarded as PSM.
However, some consider them in a specific category of
abstraction called Implementation Specific Models
(ISM).
Fig. 1. Meta-modelling Architecture of MDA
Fig. 1. Meta-modelling Architecture of MDA, shows the
abstraction levels called M0, M1, M2 and M3. The
structure, terms, notations, syntax, semantics and integrity
rules that are used to express a model (M1) are the
modelling language which, in its representation as a model,
is called metamodel (M2). Therefore, a model (M1) is
considered an instance of a metamodel (M2). Since a
metamodel (M2) is also a model it requires a language, a
"Meta-modelling language" which, in its representation as a
model, is called Meta-metamodel (M3). For this reason, a
metamodel (M2) is considered an instance of a Metametamodel (M3). At the other end, a model (M1) also
expresses a modelling language, in this case used to express
abstractions of reality called Object User (M0), which is
why an abstraction of reality is considered an instance of a
model (M1).
The language in M3 (Meta-metamodel) used to define
metamodels, such as the UML metamodel is MetaObject
Facility (MOF) [8], whose representation as a model is a
Meta-metamodel. Although it is possible to extend this
architecture with even more abstract levels, for OMG there
are no new meta-level above MOF. This means that, at this
point, OMG decided that the language used to define
constructs that specify the rules for creating occurrences in
MOF, is the MOF itself, which is defined as an extension of
UML Core metamodel [8].
3.3.2. Architecture of the development process
The strategy of the MDA approach relies on considering
artifacts resulting from the implementation of the activities
of the development process, as models and on ordering
these artifacts in one architecture (model-driven) based on
levels of abstraction.
First, the strategy categorizes models according to their
orientation in [9]:
Models of Business or Domain: historically known in
OMG as Computational Independent Model (CIM).
Models of logic systems:
3.3.3. Transformation of models in MDA
The MDA approach completes the model of the
development process integrating artifacts (models) and
development activities through the use of transformation.
These transformations are defined among metamodels to be
applied to the transformation of one or more models of
input into another of output regardless abstraction levels
defined for the architecture of the development process. A
transformation can be used to produce a representation
from another, or to cross levels of abstraction or
architectural layers.
Fig. 2. Example of Parameterized shows an example of a
transformation pattern, taken as the MDA Guide Version
2.0 [9].
Fig. 2. Example of Parameterized Transformation
3.4. Related works
Given the nature of the design process, reasoning or
rationale of the course of actions associated with the
activity of decision making has become the leitmotif of
much of the research on Software Architecture. Many of
these studies agree diagnosing the low engineering profile
that currently characterizes the Software Design process by
which a Software architecture is obtained. Jansen and
Bosch in [10] introduce the concept of 'evaporation of
knowledge' to refer to the act for which virtually all the
knowledge and information about the design decisions on
which the architecture is based, is implicitly embedded in
the architecture, and they lack a representation of first class
We observe these works from two approaches clearly
marked, focused on the identification and representation of
this knowledge and works also focused on their use to
support the process of Software Design.
In the first category we highlight the Jansen and Bosch
who in [10], in addition to introducing the concept of
"evaporation of knowledge", define software architecture as
a composition of architectural design decisions and then
define architectural design decision as a description of a set
of architectural additions, subtractions and modifications
[10]. In our work, we agree with this approach, however,
we do by using patterns as an abstraction of these concepts
and as a standard mechanism for the representation of this
knowledge. In addition, we focus on the use of this
knowledge to support the process of Software Design under
the MDA approach, by the input of this knowledge into
transformations.
In this category also, Jeff Tyree and Art Akerman in [11]
propose the use of a template for decision documentation
tables. Similarly, Neil B. Harrison and Paris Avgeriou in
[12], recognize the role of patterns to understand and
document the architectural decisions and make a proposal
for integration of architectural patterns linking them to
quality parameters of a software architecture.
In the second category, there is also a number of
interesting proposals. Among these, we highlight the one by
Zimmermann et al. in [13]. In this work, like Bosch and
Jansen [10] they define software architecture as a
composition of design decisions and propose their
representation by using templates. In addition, they propose
to use this knowledge to support the process of Software
Design using a common metamodel for the representation
and reinforcement of design decisions using a conceptual
modelling framework. In our case, for identification and
representation of decision making, we use patterns as a
standard resource and to support the activity we input this
knowledge in MDA transformations.
Another significant number of proposals address the
same topics in different ways. Soon- Kyeong Kim and
David Carrington in [14] propose a framework to develop
models considering rules of patterns and in an MDA
context. Wang Xue-Bin et al. in [15] propose a patternoriented model transformation approach and accompany
their proposal with a model transformation code template.
Kherraf, Lefebvre and Suryn in [16], in their proposal,
present an interesting experience of transformation of CIM
models (Computation-Independent Model) into PIM
(Platform-Independent Model) by using archetypes to
represent
typical
knowledge
of
specific
transformation domain.
activity of synthesis and evaluation of alternatives for
decision making.
Section Background and state of the art, among the
advances achieved, highlights the contribution of OMG
through the Model Driven Architecture (MDA), form
the particular architectural perspective. From this
perspective, two architectural models contributed by the
approach are described, which added to a model of
transformation of models, specify a generic framework that
provides structure and behaviour to different instances of
development processes defined from this approach, forming
this way a meta-architecture for the software development
process.
Why then can it be necessary to contribute a metaarchitecture that allows abstracting reusable knowledge that
anticipates and minimizes design decisions (Objective) if
we already have this meta-architecture? The metaarchitecture provided by the Model Driven Architecture
(MDA) is defined at an abstraction level that it provides a
fundamental contribution, but in that abstraction level
independent of the domain and, therefore, very far from
specific domains and decision making linked to solutions in
those domains.
The intention here is precisely that these supports can be
enriched, without compromising their generality, with
domain knowledge represented in a standard way so that
they become true participants in the design process.
4. Proposed Meta-architecture
In order to have a definition that considers knowledge
that is potentially reusable by support mechanisms for the
Software Design process, we need to continue with
specialization. The Software Design Patterns approach
provides that level of specialization abstracting the essence
of the activity of synthesis and evaluation of alternatives for
decision making (anticipates a set of decisions and limits
the potential universe of evaluation into another) in a
4.1. Introduction
The problem area addressed by the work is located in the
Software Design process and in particular in recurring
4.2. Definition of Software Design
4.2.1. Specialization from Proposals by Wand and
Ralph and by Buschmann et al.
As described in Software Design, each of the definitions
proposed by these authors represents a significant
contribution to the objectives of this work. For this reason,
in this section, we formulate a new definition as a
specialization, in the domain of Software Engineering as
follows:
Inheriting from the definition provided by Buschmann
et al. [4], concepts that specialize others defined by
Wand and Ralph [3],
Inheriting from the definition provided by Wand and
Ralph, concepts that are not explicitly redefined in the
definition proposed by Buschmann et al. [4].
4.2.2. Specialization
Patterns.
incorporating Software
Design
generic scheme which allows its realization in certain
contexts to solve a specific design problem.
Figures 3 and 4 below have been taken from the proposed
definition formulated by Wand and Ralph [3] and extended
to present the specialized version of Software Design
definition.
As seen in Fig. 3. Conceptual Model of software design ,
this original model proposed by Wand and Ralph has been
extended by adding the perspective of Software Design
Patterns and ideally assumes that each part of the software
architecture of an application can be obtained as an
instance of a pattern. While this is not the reality of the
current status, nor is it certain that it will be in a future
status, there is important evidence of its effectiveness in a
number of cases. The intention here precisely is to
distinguish the strong dependence (being instance of) of the
process of Software Design regarding Software Design
Patterns, compared to the rest of the dependences
Fig. 3. Conceptual Model of software design extended with
patterns
Another aspect to consider in the concept model, refers to
the association shown in the model among instances of the
Software Architecture class. This association represents the
capacity the Software Architectures have to compose
together in the system architecture. A noteworthy aspect is
the coincidence of this capacity with the equivalent
composition capacity among patterns.
Fig. 4. Conceptual model of contextual level of software ,
shows a contextual level of the Software Design process
extended with the perspective of Software Design Patterns.
This extension is reflected in the addition of a new input,
Software Design Patterns, and in the structuring of the
result through the association Composed by which allows
for the composition among Software Architectures induced
by the same type of composition in Software Design
Patterns. The influence of design pattern in the logic of the
design process is given by the rule of pattern, which
abstracts and simplifies the activity of synthesis and
evaluation of alternatives for decision making.
4.3. Extended Transformation Model
4.3.1. Introduction.
At this point, we already have a definition of Software
Design in line with the requirements for the objective.
Below is the effect of the definition of Software Design
extended on the candidate resource, the Transformation
resource , part of the development process model provided
by the MDA approach.
4.3.2. Proposed Extended Model.
Fig. 2. Example of Parameterized Transformation,
illustrates the concept of transformation for an hypothetical
case of PIM to PSM transformation. In our case, in order to
highlight the effect of specialization of the metaarchitecture, we present a model of transformation whose
origin and destination are on the same level of the
architectural model of the development process (PIM to
PIM or PSM to PSM ) proposed by the MDA approach.
That is, a model of transformation for obtaining another
representation of the same model, guiding the
transformation with knowledge obtained from rules
contained in the specification of a Software Design Pattern.
Fig. 5. shows a transformation model that extends the
one provided by the Model Driven Architecture (MDA)
with the knowledge of the new Software Design definition.
This knowledge is input and interpreted by the
transformation which uses it as a guide to build the output.
Fig. 4. Conceptual model of contextual level of software design
extended with patterns
Fig. 5. Extended Transformation Model
The model assimilates in the transformation logic the
ability to incorporate anticipated decisions by the Software
Design Pattern and guide decision making based on other
restrictions, also provided by the pattern on the potential
universe of evaluation. It also uses the capacity of
parameterization of the transformation model provided by
the MDA approach to collect domain information,
requirements (functional and non-functional), restrictions
and environment to support the activity of synthesis and
evaluation of alternatives for decision making in the
process of Software Design.
5. Conclusions
This work has allowed us to obtain important
conclusions. Firstly, we were able to prove the feasibility of
this type of supports based on a more specialized Software
Design definition. A very important conclusion in this
regard is that it resulted very natural to do it as an extension
of the meta-architecture provided by the Model Driven
Architecture (MDA) by OMG, which gives it the full
strength to become part of the standard.
As a result of experiments of specification and
application of concrete transformations built from the
extended model, the benefits of having this type of supports
during the execution of the Software Design process
became evident:
One typo of benefits observed, refers to the fact that the
resulting design has properties inherited from the
Software Design Patterns as they anticipate decisions
and restrict the potential universe of evaluation for other,
in order to guarantee a set of functional and nonfunctional properties directed by the pattern.
Another type of benefits that became evident, is that
related to the process engineering profile. Clearly, a vast
quantity of decisions is inherited directly from the
pattern. Another amount of decisions is guided by
restrictions, inherited from the pattern over the potential
universes of evaluation. In these cases, the decision
making is guided by these restrictions and the missing
information is received in the transformation of various
sources as parameters, consult other domain objects,
default values based on heuristic knowledge contained in
the pattern and direct contributions from the Designer.
Another important result of this work was that it clearly
defined paths to follow, among which are:
Definition of the metamodel for Software Design
Patterns.
Definition of XML Scheme for XMI representations of
Software Design Patterns metamodel instances.
Research of properties resulting from extrapolating the
instance relationship between Software Architecture and
Software Design Patterns to domains such as Object
Orientation, XML Scheme and Language Grammars
Experimentation with transformations based on different
Software Design Patterns.
6. References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
OMG, MDA - The Architecture of Choice for a
Changing World, http://www.omg.org/mda
W. W. Gibbs, Software's Chronic Crisis, Scientific
American, pp. 86-95, 1994.
P. Ralph y Y. Wand, A proposal for a formal
definition of the design concept, LNBIP, pp. 103-136,
2009.
F. Buschmann et al., Pattern-Oriented Software
Architecture - A System of Patterns, Wiley, 2001.
C. Alexander, S. Ishikawa y M. Silverstein, A Pattern
Language, New York: Oxford University Press, 1977.
C. Alexander, The Timeless Way of Building, New
York: Oxford University Press, 1979.
OMG, About the Object Management Group,
http://www.omg.org/gettingstarted/gettingstartedinde
x.htm.
OMG, OMG's MOF, http://www.omg.org/mof/.
OMG, OMG Document -- ormsc/14-06-01 (MDA
Guide revision 2.0), http://www.omg.org/cgibin/doc?ormsc/14-06-01.
A. Jansen y J. Bosch, Software Architecture as a Set
of Architectural Design Decisions, WICSA 2005.
J. Tyree y A. Akerman, Architecture decisions:
Demystifying architecture, IEEE Software, vol. 22, n
2, pp. 19-27, 2005.
N. B. Harrison y P. Avgeriou, Leveraging
Architecture Patterns to Satisfy Quality Attributes,
Software Architecture, Springer-Verlag, 2007, pp.
263-270.
O. Zimmermann et al., Reusable Architectural
Decision Models for Enterprise Application
Development, Software Architectures, Components,
and Applications, Medford, Springer-Verlag, 2007.
S.-K. Kim y D. Carrington, A Patternbased Model
Evolution Approach, APSEC'06, Kanpur, 2006.
W. Xue-Bin et al., Research and Implementation of
Design Pattern-Oriented Model Transformation,
ICCGI 2007.
S. Kherraf, . Lefebvre y W. Suryn, Transformation
From CIM to PIM Using Patterns and Archetypes,
ASWEC 2008), Perth, Australia, 2008.
