A Formal Model Driven Approach to Dependable Software Evolution
Feng Chen, Hongji Yang and Bing Qiao
Software Technology Research Laboratory
De Montfort University, Leicester, UK
fengchen, hyang, bqiao @dmu.ac.uk
William Cheng-Chung Chu
Software Engineering and Technology Center
TungHai University, Taiwan
[email protected]
Abstract
legacy source code will then facilitate the migration of
legacy systems in the subsequent forward engineering
steps. A recent research trend in reengineering area carries
the idea further and moves into model driven perspective
which is in the context of model transformation and
abstraction. In this way, software can be evolved at the
model level without regard for technological aspects and
software reengineering can then be achieved effectively
from more abstract level.
Dependability in the face of software evolution is
currently a grand challenge. The dependability of systems
is defined as the reliance that can justifiably be placed on
the service the system delivers. To build trustworthy
systems from legacy systems is urging dependability
concerns to be considered at the architectural level. One of
the most exciting outcomes of those efforts is OMG’s
Model Driven Architecture (MDA) which aims at a
unified model based framework for software evolution
[16]. Current work on instantiating an architectural model
into an executing platform is being carried out that relates
dependability concerns from the early to late stages of
software engineering by following the principles of MDA
[8].
Formal methods aim to provide mathematical
foundation for the design and verification of software
systems, which can prevent the introduction of fault.
However, formal methods are too limited to effectively
handle large and complex system development. In [9], it is
suggested that people can more effectively use formal
methods by putting more emphasis on formal models and
on domain-specific formal methods. A formal model
definition ensures a consistent interpretation of the legacy
system and provides a solid theoretical foundation for the
dependable software evolution. This paper will focus on
formal model transformation technology to extract
different level of models from legacy source code. In
Section 2, background and some current researches are
reviewed. In Section 3, formal model transformation
approach to software reengineering is presented. In
Section 4, a prototype CASE tool, Maintainer Integration
Platform (MIP), is introduced which supports the
proposed approach. In Section 5, a case study is used to
test the proposed approach and the prototype tool, and
finally, in Section 6, the paper is concluded and further
research directions are also discussed.
The paper proposes a unified formal model driven
approach to software evolution based on both program
transformation and model transformation of legacy
systems. A formal model definition ensures a consistent
interpretation of the legacy system and provides a
theoretical foundation for dependable software evolution.
The theoretical foundation is based on the construction of
a wide spectrum language for reengineering, known as
WSL, which enjoys a sound formal semantics. The
architecture and working flow of the approach are
proposed, and the mappings between WSL and PSL in
MDA provide an engaging combination of traditional
program
transformation
and
modern
model
transformation, which shows that the proposed approach
is feasible and promising in its domain. A prototype tool is
developed to test the approach and a case study is used
for experiments with the proposed approach and the
prototype tool. Conclusion is drawn based on analysis
and further research directions are also discussed.
Keywords: Software Evolution, Software Reengineering,
Formal Method, Model Transformation, Wide Spectrum
Language (WSL), Model Driven Architecture (MDA)
1. Introduction
Constant innovation of information technology and
ever-changing market requirements reduce more and more
existing software to legacy status. Generating software
through reusing legacy systems has been a primary
solution and software reengineering has the potential to
improve software productivity and quality across the
entire software life cycle. The purpose of software
reengineering is both to utilise existing software to take
advantage of new technologies and to enable new
development efforts to take advantage of reusing existing
software.
Software reengineering consists of mainly two parts,
reverse engineering and forward engineering [1, 10]. The
classical reengineering technology starts at the level of
program source code which is the most or only reliable
information on a legacy system. The program
transformation and specification abstractions derived from
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
2. Background
2.1 Software Model
The term “model” is used in many contexts and often
has different meanings. Generally, a model can mean an
abstraction and representation of the important factors of a
complex reality, which is different from the thing it
models, yet has the same main characteristics as the
original. With a model, people can build up an
understanding to the point where it is natural to answer a
question by modelling it into some simpler context,
answering the question with the model, and then
interpreting the answer [14]. Models help people by
letting them work at a higher level of abstraction. A model
may hide or mask details and bring out the big picture.
A model plays the analogous role in software
development. Creating a model of a system is a useful
way to understand a system. Software modelling is an
essential part of large complex software projects. Software
modelling assumes that abstract models convey
information more effectively than source code. People
should use abstract models to enhance their understanding
of a system and to provide a common base for others to
discuss it [21]. A model is always written in a language.
To enable automatic transformation of a model, the
language should be well defined, which has a well-defined
form (syntax) and meaning (semantics) that can be
interpreted automatically by a computer [6].
tools, some sorts of common model exchange format are
needed. XMI is an XML standard for exchanging UML
models.
2.3 Model Driven Architecture
OMG’s Model Driven Architecture (MDA) intends to
achieve language, vendor and middleware neutral
software development. MDA focuses on various models
existing in different phases of software development. A
model could be a Computation Independent Model (CIM)
or a Computational Model (CM). Both of them describe a
system in a logic way. The former, also known as
requirement model, does not involve technical factors,
while the latter does. The computational model in MDA
presents its most distinguishing features which exist in
two forms: Platform Independent Model (PIM) or
Platform Specific Model (PSM). PIM and PSM could be
written in any formal languages that make them
understandable by both human and machines. A series of
PIM and PSM models construct a hierarchy of abstract
levels. MDA models at different abstract levels can be
transformed automatically to each other according to
transformation rules.
Define PIM Meta Model
Define PSM Meta Model
Define Transformation Rules
PIM
2.2 UML, MOF and XMI
PIM2PSM Rules
Design Business Logic
Unified Modelling Language (UML) has become the
worldwide de facto standard for the visualisation and the
modelling of complex object-oriented and component
based systems. It has significant tool support and a wide
spread acceptance to developers, software architects and
engineers. Rumbaugh et al [17] identifies three viewpoints
necessary for understanding a software system: the objects
manipulated by the computation (the data model), the
manipulations themselves (functional model), and how the
manipulations are organised and synchronised (the
dynamic model). UML, through its various UML
diagrams, encompasses all of Rumbaugh’s views.
According to the UML Specification, the UML is
actually an instance of the MOF (Meta Object Facility)
meta-metamodel. The MOF defines a set of interfaces,
which can be used to define different interoperable
metamodels (including the UML metamodel). A
metamodel is in fact an abstract language for some kinds
of metadata.
In order to enable the developers to achieve the same
understanding and interpretation of the model when this
model is exchanged among different technologies and
PSM
Map onto Implementation Technology
Produce Final System
PSM2Code Rules
Code
Figure 1. MDA process
Figure 1 shows the process of applying MDA.
Transformation is carried out by automatic tools that take
a PIM as input and produce a specific PSM as output.
Nowadays MDA is supported by many tools. The
Arcstyler is a MDA tool [5] which supports the whole
application life cycle of software development. Arcstyler
can import existing models that are compliant to XMI or
create models from existing Java code. Arcstyler used the
term MDA-Cartridges for the model transformation.
Arcstyler provides the predefined cartridges for a number
of technologies and platforms, such as Java, J2EE
and .NET. Using the cartridge concept one could define
the transformation rules for a new technology or platform
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
like CORBA, VB, VC etc. Nevertheless, all the existing
MDA tools mainly focus on the forward software
engineering.
3. Model Driven Approach for Software
Reengineering
system from constructs, modules up to the system
architecture composed of interconnected components.
Written in a formalised platform independent language,
the extracted architecture description is a Platform
Independent Model (PIM) and can be forward engineered
within MDA environment to produce new PIMs that can
be later transformed into any PSMs automatically.
3.1 Reengineering within MDA
Current Model Driven Development (MDD) is an
extension to the MDA and is mainly focusing on the
forward engineering part of software reengineering.
Model Reverse Engineering is to produce descriptive
model from existing systems that was previously
produced somehow. In fact modelling and reverse
engineering both refer to the activity of creating
descriptive models which describe an existing system [4].
Although MDA provides a framework for automatic
transformations between models at different levels of
abstraction, few researches have been done in respect of
the reverse transformations between PIM, PSM and Code
Models, which requires that “a transformation can be
applied not only from source to target, but also back from
target to source”.
Bidirectional transformations can be achieved in two
ways [6]. The first is that both transformations are
performed according to one transformation definition. The
second is that transformation definitions are specified
such that they are each other's inverse. Transformation
from low level to higher level models means loss of
specific information which may not have their
counterparts at all. To achieve complete bidirectional
transformations between models is only possible if the
semantic gap between the different models can be filled
with knowledge.
There is often no need to transform an MDA compliant
system reversely, for it conforms to the requirements of an
evolvable system and could be understandable and
maintainable as long as all the PIM documents are
available. The application of bidirectional transformations
is actually in situations where the system was not
developed in MDA environment and is now required to be
transformed into an evolvable system that conforms to the
standards of MDA. To achieve this goal, reverse
engineering techniques have to be used to understand the
legacy system.
Figure 2 shows a possible process of software
reengineering within MDA environment [15]. Initial
components are firstly identified in a system through
system decomposition techniques. The decomposed
system is then translated equivalently into a Platform
Specific Model (PSM) written in a Platform Specific
Language (PSL). After restructuring the PSL code,
abstraction rules are applied to get abstractions of the
Parse Code
Produce Platform Specific Model
Y
N
Reverse Engineer Legacy System
If the legacy
system was
built on MDA?
Propose Legacy Concept Model
Produce Architecture Description
Produce Platform Independent Model
Figure 2. Reengineering within MDA
3.2 Wide Spectrum Language (WSL)
If a software specification is written in a formallydefined mathematical language, it is possible to prove that
a given program is a correct implementation of a given
specification and if a language includes both mathematical
specifications and low-level programming constructs, then
this language can be termed as the Wide Spectrum
Language (WSL) [23, 18, 19]. WSL was adopted because,
among many reasons, its ability for proven
transformations and the ability to represent high and low
levels of abstraction which make it well suited for reverse
engineering purposes. By translating a legacy system’s
source code to WSL as an intermediate language, it’s
therefore possible to support multiple languages
translation. The use of intermediate representations allows
the reengineering effort to be divided up into smaller steps
rather than as a monolithic source to target domain
reengineering effort [11]. WSL is built on formal methods
and supports both object oriented and structural elements
of software systems.
z
WSL Kernel Language
The WSL language is built up in a series of layers from
a small mathematically tractable “kernel language”. This
kernel language consists of the following primitive
statements [18, 19]:
Assertion {P} - if formula P is true, the statement
terminates; otherwise, it aborts or never terminates
Guard [Q] – restricts previous non-determinism to
statements whose condition for execution requires Q
Add variables: add (X) adds the variables in X to the
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
state space
Remove variables: remove(X) removes the variables in
X from the state space
Sequence (S1:S2) executes S1 followed by S2
Non-deterministic choice: chooses one of S1 or S2 for
execution, the choice being made non-deterministically
Recursion – a statement, S1, may contain occurrences
of X as one or more of its component statements. These
statements represent recursive calls to the procedure
whose body is S1.
z
Extensions of WSL Kernel Language
By building on the basic constructs of the WSL
language, extensions to the WSL language include simple
assignment, deterministic iteration (do-while loops) and
deterministic choice (if-then) statements along with blocks
of statements within procedure calls.
In order to support Object Oriented Technology, the
WSL kernel language was extended to include such
constructs as class structure which contains both variables
(attributes) and procedures (methods or operations).
1. Class Definition
Class T
Var
Ti : xi; /* Attributes of Class */
Proc
mj(In pinjk:Tk, Out poutjl:T_l)
/* Methods of Class */
Begin
Aj; /* WSL statements */
End.
End
This statement is the class building declaration. It
defines a class named T, which has data fields xi of type
Ti and methods mj. pinjk stands for the input parameters
of method mj, and poutjl stands for the output parameters
of method mj.
2. Class Hierarchy
T extends T’
This statement is used to build the object hierarchy. It
declares that class T is a subclass of class T’. Therefore, T
inherits the properties of T’.
3. Field Reference
x.d
This is object field reference. x is an object, and d is a
field of x.
4. Method Invocation
x.m (In ek, Out yl)
This invokes the method m in object x.
5. Object Declaration
T:x
This statement defines x as a variable of type T. If T is
a class, x will be an object of class T.
There are some other extensions of WSL for domain
specific purpose, e.g. real time applications, which can be
found in [23, 10].
z
Program Transformation
A program transformation can be defined as a process
that modifies a program into a different form yet the
program retains its original external behaviour. The
purpose of the WSL transformations is to transform a
program, using mathematically-proven transformations,
into a more refined or simplified program. By doing so,
the program’s complexity is reduced with the program’s
original functionality preserved.
Martin Ward has utilised program transformations in
WSL to derive efficient algorithms from abstract
specifications [18, 19]. One of the focuses of Ward’s work
is to develop transformations that refine a program’s
specification, expressed in terms of first order logic and
set theory, into an efficient algorithm. Transformations are
used in reverse engineering partially in order to derive of
concise specifications from program source code [19].
Once a source program has been translated into WSL,
the WSL representation may then be input to such tools as
FermaT transformation system [19] that has the capability
for program transformations, code reductions, etc of this
WSL representation. FermaT is an industrial-strength
reengineering tool, which allows transformations and code
simplification to be carried out automatically.
3.3 Formal Model Transformation
Model transformation is the equivalent of program
transformation, but applied to models instead of programs.
Many of the techniques that are used for program
transformation can also be applied in the context of model
transformation [22]. This part explains the technique for
organising and maintaining legacy system models. It
shows how to produce several views of a legacy system
for reduction in model complexity through abstraction.
From the reverse engineering point of view,
transformation is a way of abstraction through changing
the abstract level of a processed model, providing multiple
levels of abstraction for every type of components. Model
transformation focuses on high level modelling
components while program transformation can still be
used for low level source code transformation.
Put in the MDA context, reverse engineering technique
is designed for PSLs, not numerous programming
languages. All kinds of software systems for reverse
engineering will be translated into one PSL and be tackled
by one set of reverse engineering techniques as long as
these systems are implemented on a same platform. As the
number of platform technologies is much less than that of
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
programming languages, this will significantly reduce the
complexity of designing reverse engineering techniques.
In addition to the PSL itself, all kinds of specification
extraction rules (translation, abstraction or transformation
rules) are defined in OCL [20]. A translation rule is used
between a programming language and a Platform Specific
Language (PSL), an abstraction rule is used between two
PSL models at different abstract levels and a
transformation rule is used between a final Platform
Specific Model and a PIM.
that there is an abstraction rule from the source code to the
target code abstracting the left-hand side operand to the
right-hand side operand at a higher level of abstraction.
The symbol => is used as a binary operator with two
operands, which means that there is a transformation rule
from the source code to the target code transforming the
left-hand side operand to the right-hand side operand with
platform specific information left out.
z
The principle of abstraction is that, through the
abstraction process, the high-level views of a system can
be achieved without being interested in all low-level
details. The following rules are defined based on the
program abstraction theory [10], where the “Entity” is
defined for a group of statements in PSL with independent
functionality, and the “Abstraction” represents the type of
all the abstraction rules in PSL.
— Transitive Abstraction Rule denotes that a set of
abstraction rules can be concatenated to make up a
new rule. The source of the new rule is that of the
first abstraction rule in the set, and the target of the
new rule is that of the last abstraction rule in the set.
Figure 4 shows a transitive abstraction rule.
Notations for Specification Extraction Rules
There is a set of OCL notations for Specification
Extraction rules. Figure 3 shows the corresponding
grammar rules [15]:
<ruleType> := “Translation” | “Abstraction” | “Transformation”
<paramsList> := <varName>: <varType> = <expression>;
| <paramsList> <paramsList>
<params> := params <paramsList>
<sourcesList> := <varName>: <modelType>::<modelElement>;
| <sourcesList> <sourcesList>
<sources> := sources <sourcesList>
<targetsList> := <varName>: <modelType>::<modelElement>;
| <targetsList> <targetsList>
<targets> := targets <targetsList>
<sourceInvariant> := source invariant <booleanExpression>;
<targetInvairiant> := target invariant <booleanExpression>;
<mappingRulesListForTranslation> := <operand> <=> <operand>:<ruleName>;
| <operand> <=> <operand>
| <mappingRulesListForTranslation> <mappingRulesListForTranslation>
<mappingRulesListForAbstraction> := <operand> ~> <operand>:<ruleName>;
| <operand> -> <operand>
| <mappingRulesListForAbstraction> <mappingRulesListForAbstraction>
<mappingRulesListForTransformation> := <operand> => <operand>:<ruleName>;
| <operand> => <operand>
| <mappingRulesListForTransformation> <mappingRulesListForTransformation>
<mappingRules> := mappings <mappingRulesListForTranslation>
| <mappingRulesListForAbstraction>
| <mappingRulesListForTransformation
<specificationExtractionRule> := <ruleType> <ruleName> (<sourceRef>, <targetRef>) {
<params>
<sources>
<targets>
<sourceInvariant>
<targetInvariant>
<mappingRules>
| <sources>
<targets>
<sourceInvariant>
<targetInvariant>
<mappingRules>
}
z
Abstraction Transitive (PSL, PSL) {
params
a1: PSL::Abstraction;
a2: PSL::Abstraction;
sources
p1: PSL::Entity;
p2: PSL::Entity;
targets
p3: PSL::Entity;
source invariant
p1 ~> p2: (a1) and p2 ~> p3: (a2);
target invariant
ture;
mappings
p1 ~> p3: (a1, a2);
}
Figure 4. Transitive abstraction rule
—
Figure 3. Notations for specification extraction
rules
Every Specification Extraction rule begins with one of
the
keywords:
“Translation”,
“Abstraction”
or
“Transformation” and a name. All mapping rules come
after the keyword “mappings”. The symbol <=> is used as
a binary operator with two operands, which means that
there is a translation rule from the source code to the
target code translating the left-hand side operand to the
right-hand side operand equivalently. The symbol ~> is
used as a binary operator with two operands, which means
Model Abstraction Rules
—
—
—
Abstraction Reflexive Rule denotes that any entity
is the abstraction of itself.
Monotonic Abstraction Rule denotes that if entity
p1 and p3 can be abstracted by abstraction rules a1
and a2 respectively to produce entity p2 and p4, the
result of functional transformation f1, with p1 and p3
as arguments, can be abstracted by the combination
of a1 and a2 to the result of functional transformation
f1, with p2 and p4 as arguments.
Weakening Abstraction Rule is used to eliminate
inessential information
Attribute Abstraction Rule eliminates “set” and
“get” operations and abstracts into PSL attribute with
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
—
appropriate visibility.
Sequence Folding Abstraction Rule shows that if
no contradiction is caused when substituting the
sequential relation between two entities to
conjunction relation, then the sequence of entities
can be folded through conjunction.
The following abstraction rules are used to simplify
relationships. Interconnections between procedures,
modules/objects and components that are judged as
irrelevant will be abstracted or hidden in the model
representation.
— Primitive Component Rule: Initial component is
defined as primitive component, which can be source
file, program module and subsystem.
— Component Composition Rule:
Component
composition is to combine two components when
they have direct connectors, such as procedure call or
shared variable, may be combined into one
component.
— Trivial Component Rule:
If a part of the
system’s functionality is considered too “trivial” to
be kept in high level abstraction, the components
related to this part of functionality are identified as
“trivial components”, which should be abstracted
away in architecture abstraction.
— Primitive Relationship
Rule:
Initial
connector is defined as direct connector which can
be shared resources, function or procedure call, interprocess call, etc.
— Relationship Composition Rule:
to combine
two connectors connecting the same component set
into one connector.
— Trivial Relationship Rule: If all the components
connecting to a connector are trivial components,
this connector is considered trivial connector and
should be abstracted away in architecture abstraction.
z
Translation between WSL and PSL
Ideally, a PSL should be the same language used to
write a Specification Extraction rule. This could improve
the consistency of modelling and facilitate the
implementation of automatic tools. However, OCL itself
is not a programming language, but a declarative language,
which states what actions to perform, instead of how. A
language consisting of programming constructs is still
required for PSL. WSL is a suitable choice which can be
used as part of PSL.
Mapping from WSL to PSL and from PSL to WSL
needs translation rules: (1) the translation between WSL
constructs and PSL defined in OCL; (2) the translation of
primitives and operators between WSL and PSL, or (3)
the translation between WSL compound statements and
PSL.
context PSL::Class
def:
attributes() = feature->select(isTypeOf(Attribute));
operations() = feature->select(isTypeOf(Operation));
Translation Class2Class (WSL, PSL) {
sources
c1: WSL::Class;
targets
c2: PSL::Class;
source invariant true;
target invariant true;
mappings
c1.attributes()<=> c2.attributes();
c1.operations()<=> c2.operations();
}
Figure 5. Translation between WSL class and
PSL class
Figure 5 shows a translation between WSL Class and
PSL Class. A translation rule is defined to translate WSL
class into PSL class, which denotes that:
— A PSL class consists of attributes and operations.
— Every WSL class is translated into a PSL class.
— Every operation in the WSL class is translated into
an operation in PSL class.
— Every attribute (private, protected, or public) of the
WSL class is translated into an attribute in the PSL
class with the identical visibility.
In this way, PSL is used to define the counterparts of
other WSL constructs, such as “interface” and “exception”,
and the corresponding translation rules.
z
Mathematical Model
When the PSL is translated into WSL file, we have an
optional way to establish a mathematical model instance.
A mathematical model M [3] is a quadruple (T, C, F, A)
where T is a finite universe of objects, C is a constants
chosen from T, F is a finite set of functions and A is some
constraints in equations. An important advantage of
mathematical model is to have a standardised way of
checking out answers to questions like [14]:
—
—
—
—
TYPE: What kind of objects is involved?
CONSTANTS: What special values are important?
FUNCTIONS: How are objects of each kind created
and used?
ASSERTIONS: What facts can I really count on?
General rules are needed. This is the hardest part.
In [10], WSL, together with the abstraction and object
extraction rules were defined in Interval Temporal Logic
(ITL) [12], which can be interpreted in M.
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
4. Maintainer Integration Platform (MIP)
From the above analysis, an integrated platform
support is very important to successful automation of the
proposed approach. The Maintainer Integration Platform
(MIP) is an extensible platform for software reengineering,
which provides a plug-in mechanism. A plug-in is the
smallest unit of MIP function that can be developed and
delivered separately. Usually a small tool is written as a
single plug-in, whereas a complex tool has its
functionality split across several plug-ins. Except for a
small kernel known as the Platform Runtime, all of the
MIP functionalities are located in plug-ins.
Other Software Application
M-MA
Kernel
Runtime
Application Plug-ins
M-UML
…
Core System
Transforma
tion Engine
M-DOC
Repository
Access
Repository
DB
…
XML
…
Figure 6. MIP architecture
tool are some examples of application plug-ins. MIP UML
(M-UML) is being developed for supporting the principles
of MDA.
5. Case Study
Model-driven development claims to offer the
improvements even to assembly program [6, 13]. The case
study performed for this research tried in the same way to
reengineer a small assembly language project with 11
modules.
The M-UML tool collects information from different
sources and uses the Transformation Engine to generate
WSL files from the assembler files. The assembler
modules are broken down into little pieces and each piece
is put into an action (a little procedure without
parameters). In the current version, two diagrams are
extracted, UML Class Diagram and UML Activity
Diagram. The static view of the class diagram represents
actually a mixture of call graphs, data catalogues and
function catalogues. The dynamic view of the activity
diagram on the other hand shows the interaction among
the legacy system components/modules. After the
extraction of the Class Diagram and the Activity Diagram,
transformation rules are applied to group and abstract the
related elements. To handle large quantities of classes, the
M-UML presentation tool supports expand/collapse of
packages and classes. Figure 7 shows an example of
different models and views for a slice of code in
assembler and WSL. The M-UML presentation tool shows
a transformation result in Figure 8.
Figure 6 shows the architecture of MIP, which
illustrates the preliminary vision for integration points
between the MIP components as well as the interactions
between these systems. The system can be expressed in
three Layers:
—
—
—
Repository (Database + XML files)
Core System
Application Plug-ins
Information in different transformed models and in
multiple abstract views at various levels of detail is stored
in a repository.
A small Core System provides essential functionalities,
including: (1) Kernel Runtime, which provides the plug-in
management and communication functionalities; (2)
Transformation Engine, which is the extension of FermaT
Transformation Engine and provides the program and
model transformation functionalities; and (3) Repository
Access functionalities. Based on this core system, more
plug-ins provide furthermore functionalities.
Application Plug-ins are a set of tools for the end-users
and maintainers, including visualisation and analysis
modules. MIP UML (M-UML) tool, MIP Maintainer
Assistant (M-MA) tool and MIP Documentation (M-DOC)
Figure 7. Different models and views for a slice of
code
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
[3]
[4]
[5]
[6]
[7]
[8]
Figure 8. A transformation result by M-UML tool
6. Conclusions and Future Work
[9]
[10]
[11]
To conclude this study, a general framework and
methodology handling model driven software evolution is
proposed. It provides a unified solution to facilitating
legacy system reengineering. The traditional program
transformation and modern model transformation
technologies are amalgamated harmoniously and formally
based on the WSL. The prototype tool and the case study
show that the proposed approach is workable and
dependable for a real legacy system even written in
assembly language.
This approach has been applied on small to medium
examples. The obtained results reveal that:
(1) The abstracted entities are hard to be named.
(2) Since the transformation will change the software
structure, the traceability of transformation is another big
issue. Feature modelling in our previous work [2, 7] is a
promising solution.
7. Acknowledgment
The authors would like to thank Matthias Ladkau,
Stefan Natelberg, Peer Bartels and Shaoyun Li, for the
development of prototype tool on the topics presented in
this paper.
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
References
[1]
[2]
E. Chikofsky and J. Cross, "Reverse Engineering and
Design Recovery: a Taxonomy", IEEE Software, 7(1), Jan.
1990, pp.13-17.
F. Chen, S. Li, H. Yang, C. Wang and W. Chu, “Feature
Analysis for Service-Oriented Reengineering”, IEEE 12th
ASIA-PACIFIC Software Engineering Conference (APSEC
2005), Taipei, Taiwan, Dec. 2005.
[20]
[21]
[22]
[23]
D. Embley, Object-Oriented Systems Analysis: a ModelDriven Approach, Prentice Hall, 1992.
J. Favre, “Foundations of Model (Driven) (Reverse)
Engineering: Models”, Int. workshop Dagsthul, 2004.
IO-Software: Homepage, http://www.io-software.com.
A. Kleppe, J. Warmer and W. Bast, MDA Explained: The
Model Driven Architecture: Practice and Promise,
Addison Wesley, Boston, USA, 2003.
S. Li, F. Chen, Z. Liang and H. Yang, “Using FeatureOriented Analysis to Recover Legacy Software Design for
Software Evolution”, International Conference on
Software Engineering and Knowledge Engineering
(SEKE'05), Taipei, Taiwan, July 2005.
R. Lemos, C. Gacek and A. Romanovsky, “Software
Architectures for Dependable Evolving Systems”, Grand
Challenge on Dependable System Evolution (GC6), Grand
Challenges in Computing, 2004.
Luqi and J. Goguen, "Formal Methods: Promises and
Problems", IEEE Software, Jan./Feb. 1997, pp.73-85.
X. Liu “Abstraction: A Notation for Reverse Engineering”,
Ph.D. Thesis, De Montfort University, England, 1999.
D. Millicev, “Domain Mapping Using Extended UML
Object Diagrams”, IEEE Software, IEEE Press, New York,
USA, pp. 90-97.
B. Moszkowski, Executing Temporal Logic Programs,
Cambridge University Press, Cambridge, UK, 1986.
A. MacDonald, D. Russell and B. Atchison, “Model-driven
Development within a Legacy System: An Industry
Experience Report”, In Proceedings of the 2005 Australian
Software Engineering Conference (ASWEC’05), 2005, pp.
14-22.
T. Myers, Equations, Models, and Programs: a
Mathematical Introduction to Computer, Prentice Hall,
1988.
B. Qiao, “Evolution of WEB-based Systems in Model
Driven Architecture”, Ph.D. Thesis, De Montfort
University, England, 2005.
B. Qiao, H. Yang, W. Chu and B. Xu, “Bridging Legacy
Systems to Model Driven Architecture”, In Proceedings of
the 27th Annual International Conference on Computer
Software and Applications, IEEE Computer Society,
Washington, DC, 2003, pp.304-309.
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W.
Lorensen, Object-Oriented Modelling and Design,
Prentice-Hall, Upper Saddle, NJ, USA, 1991.
M. Ward, “Program Analysis by Formal Transformation”,
Computer Journal, Vol.39, No.7, 1996, pp.596-618.
M. Ward, “The FermaT Assembler Re-engineering
Workbench”, In Proceedings of the 17th. IEEE
International Conference on Software Maintenance
(ICSM'01), 2001, pp.659-662.
J. Warmer, The Object Constraint Language: Getting Your
Models Ready for MDA, Addison-Wesley, 2003.
I. Warren, The Renaissance of Legacy Systems: Method
Support for Software-system Evoluion, Springer-Verlag,
1999.
Wiki:
Homepage,
http://www.programtransformation.org/Transform/ModelTransformation.
H. Yang and M. Ward, Successful Evolution of Software
Systems, Artech House, Norwood, MA, USA, 2003.
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006