Yong-Yi Fanjiang
1Nien-Lin Hsueh
2Jonathan Lee
3Recently, the growing popularity of model driven frameworks and methodologies, as well as the Model Driven Architecture (MDA) initiated by Object Management Group (OMG) has implied an increasing focus on model transformation. Meanwhile, the impact of design patterns on software quality has attracted a gradual attention since design patterns encapsulate valuable knowledge to resolve design problems and improve design quality. As an attempt towards the investigation of applying goals and design patterns to realize the model transformation, we proposed, in this paper, a goal-driven model transformation by applying design patterns to transform an analysis model into its corresponding design model with an emphasis on the non-functional requirements. The use of goals makes it easier to transform the functional and non-functional requirements into the software models, and derives the candidate design patterns to help satisfy nonfunctional requirements for resolving the design problems and improving software quality.
Keywords:
Design patterns, model Transformation, goal-driven approach, design quality.
the Second Taiwan Conference on Software Engineering (TCSE06)
Towards a Pattern- based Model
Transformation
Approach for Design Quality Enhancement
1 Department of Computer Science and Information Engineering, Fu Jen Catholic University
2 Department of Information Engineering and Computer Science, Feng Chia University
3 Department of Computer Science and Information Engineering, National Central University
1. Introduction
Recently, the growing popularity of model driven framework and methodologies, as well as the Model Driven Architecture (MDA) [10] initiated by Object Management Group (OMG) has implied an increasing focus on model transformation. Model transformation takes a set of model fragments, which conform to the source metamodel, as input and applies a set of rules to them, resulting in a set of models, which conform to the target metamodel [21]. Meanwhile, the software quality has long been recognized as an important topic since the early days of software engineering. In the past, researchers and practitioners alike have examined how systems can meet specific software quality requirements.
Therefore, a growing number of practitioners have shown great interests in using design patterns towards high-quality software, since design patterns represent high-level abstractions that reflect the experiences of no other than skilled practitioners themselves. Design patterns have become a popular means to encapsulate object-oriented design knowledge. They capture successful solutions to recurring problems that arise when building software systems.
Generally, a transformational approach has two major steps. First, a formal specification is derived from user requirements. Then, a set of transformations is applied to these formal specifications to obtain an implementation system. In this paper, we adopt our pervious work on the goal-driven use case (GDUC) [19] and fuzzy object-oriented modeling (FOOM)
[20] served as the formal specifications to capture and specify imprecise requirements, and provide a set of pattern-based transformation rules to deal with the software quality issues. As an attempt towards the investigation of applying goals, design patterns, and model transformation approach, a goal-driven model transformation by applying design patterns approach has been proposed (see Fig. 1 for an overview). In Fig. 1, the designer constructs the goals hierarchy based on goals analysis and goals interaction. Before applying the design pattern transformation rules, the designer selects a suitable design pattern from the candidate design patterns through matching the non- functional goals and intents of design patterns, and then transforms the analysis model into design model by applying the transformation rules incrementally.
Our proposed approach has the following features:
Goal-driven use cases and goals hierarchy
are built according to the goals and use cases analyzed. The analysis model is constructed based on the goals hierarchy by using the FOOM notations and semantics to specify various alternative models.
Design patterns serve as a supporting design
knowledge base to help the development of a system. A goal-driven method is provided to facilitating the selection of candidate design patterns from the analysis model, and the design pattern transformation rules are used to help the enhancement of non-functional requirements and improve the software quality.
Fig. 1 An overview of our proposed approach
The organization of this paper is as follow. We first briefly describe the background knowledge about model transformation and applying design patterns to model transformation in the next section.
The relationship between design patterns and nonfunctional issues is depicted in section 3, and the section 4 provides the transformation rules. A meeting scheduling application is provided as an example to illustrate our approach in section 5, and some concluding remarks are given in section 6.
2. Background
A n u m b e r o f r e s e a r c h e s i n t h e a r e a o f model transformation and pattern based model transformation have made their marks on our goal- driven pattern-based model transformation method.
2.1. Goal-based approach
In recent years, goal-based requirements analysis methods have attracted an increasing attention in the area of requirements engineering, as goals information are valuable in identifying, organizing and justifying software requirements [6, 18, 21, 22, 23]. The tenet of goal-based approaches is focusing on why systems are constructed, which provides the motivation and rationale to justify software requirements. Other benefits include: (1) helping to acquire requirements by elaborating what requirements are needed to support the goals; (2) making easy the justification and explanation of the presence of requirements in a progressive way by starting from system-level and organizational objectives from which such lower level descriptions are progressively derived [6]; and (3) providing the information for detecting and resolving conflicts that arise from multiple viewpoints among agents [6, 18].
Subsequently, a number of researchers have reported progress toward the improvement of goal-based techniques [6, 21, 1]. In particular, Dardenne et al. [6] have advocated a goal-directed approach to models acquisition. Mylopoulos et al.
[21] have proposed a framework for representing nonfunctional requirements in terms of goals, which can be evaluated in order to determine the degree to which a nonfunctional requirement is supported by a particular design. Moreover, they advocated that object-oriented modeling approach can then be used to model functional requirements to compensate
the goal-oriented approach [22]. Meanwhile, Anton [1] has proposed a goal-based requirement analysis method to identify, elaborate and refine goals for requirements specifications.
To p r o v id e a s y s tematic w ay to h an d le non¬functional requirement, and model the interactions between requirements, our previous work on GDUC [19] proposes an approach to extending use case models with goals to guide the derivation of use cases, and analyzing the interactions among non- functional requirements on the basis of interactions between goals and use cases.
2.2. Goal Driven Use Case (GDUC)
An important advantage of use case driven analysis is that it helps to manage complexity, as it focuses on one specific aspect of usage at a time.
Use cases focus the expression of requirements on users, starting from the very simple viewpoint that a system is built first and foremost for its users.
The organization of the approach is performed with respect to the interaction of a single category of users at a time; this participating of the set of requirements considerably reduces the complexity of requirements determination. However, the current use case approaches are somewhat limited in supporting a formalization of use cases, and in structuring and managing large use case models.
Our previous work on goal-driven use cases (GDUC) [19] extends use cases with goals to alleviate the above problems:
goals are used to structure use case models and to
derive use cases;
soft goals are differentiated from the rigid ones
to handle non-functional requirements that are imprecise in nature; and
goals information are embedded in the use
cases, and relationships between requirements are analyzed by investigating the interactions between goals and use cases.
After constructing the use cases model, the interaction between goals are evaluated and the goals hierarchy is constructed for software modeling. To better characterize the relationships between use cases and goals, we adopted predicates proposed by Mylopoulos et al [21]: satisfied, denied, satisfiable,
and deniable for the relationships between goals and use cases called the goals interaction in the use cases level. Then, the relationships between goals in the system level are analyzed based on the use case models and relationships between goals interaction in the use case level.
Instead of putting heavy efforts on resolving conflicts at the beginning of system design which may overload analysts, we start with constructing a model to meet a set of conflict-free requirements.
To this end, we organize the goals into several alternatives based on the interactions analyzed such that each alternative contains a set of goals that are not conflicting with each other. In other words, no conflict is allowed in an alternative. The designer can choose the most important alternative as stable kernel for software modeling first, and composes the other alternatives incrementally by applying predefined conflict resolution mechanism. More detailed method about GDUC please refers [19].
2.3. Fuzzy Object Oriented Modeling (FOOM) Fuzzy Object Oriented Modeling (FOOM) [20]
is a modeling approach to analyzing imprecise requirements which extends the traditional OOM along several dimensions: (1) to extend a class to a fuzzy class which classifies objects with similar properties, (2) to encapsulate fuzzy rules in a class to describe the relationship between attributes, (3) to evaluate fuzzy class memberships by considering both static and dynamic properties, and (4) to model uncertain fuzzy associations between classes.
Several kinds of fuzziness that are required to model imprecise requirements are identified:
classes with imprecise boundary to describe a
group of objects with similar attributes, similar operations and similar relationships;
rules with linguistic terms that are encapsulated
in a class to describe the relationships between attributes;
ranges of an attribute with linguistic values
or typical values in a class to define the set of allowed values that instances of that class may take for the attribute;
the membership degree (i.e. ISA degree) between
an object and a class, and between a subclass and its super class (i.e. AKO degree) can be mapped
to the interval [0,1]; and
associations between classes that an object
instance may participate to some extent.
FOOM uses fuzzy inclusion technique to compute the compatibility degree between a class and an object, and the class membership between a class and its subclass (i.e. perceptual fuzziness). Instead of using fuzzy inclusion technique to clustering data, the focus is to determine the compatibility between objects based on their properties (i.e. attribute, operation, and association).
2.4. Model transformation approaches
Graph transformation. Varró et al [26] describe a system for model transformation based on Graph Transformations. This style of transformation is based on the application of an ordered set of rules.
Operators available include transitive closure, and repeated application. Rules identify sub-graphs which define before and after states, and may refer to source andtarget model elements and introduce associations between the before and after states.
Relational transformation. The basic idea is to state the source and target element type of a relation and specify it using constraints. In its pure form, such specification is non-executable. However, declarative constraints can be given executable semantic, suchlike in the case of logic programming.
In fact, logic programming with its unification-based matching, search, and backtracking seems a natural choice to implement the relational approach, where predicates can be used to describe the relations.
Gerber et al. [13] explore the application of logic programming to implement transformations.
Model transformation through high-level programming language. Implementing a model transformation can be carried out by using a general programming language with a specific API. Indeed, nowadays, repositories such as dMOF [5] can be used to save models and metamodels that are MOF compliant. These tools allow an API to be generated and its basic implementation for each contained metamodels. Thereafter, programmers can use these APIs to create, manipulate and modify models that conform to a metamodel contained by the repository.
Model transformation based on transformation metamodel. Engineers build models to better
understand the systems that are being developed.
In a similar way, to understand existing models we may provide models of these as well. This activity is called meta-modeling. K. Duddy et al. [7] defined a transformation metamodel of which instances will be input parameters of a generator, which transforms a model into a program that implements the transformation process described by this model.
These generated programs are based on the dMOF repository.
2.5. Pattern-based model transformation approaches
Work in a number of fields has made their marks on the pattern-based approach. These researches are organized into following categories: automatic application of design patterns, quality improvement
by design patterns, pattern-based development methodology, and others.
Table 1 makes a comparison of these researches from the perspectives of their objectives, engineering direction, pattern selection, pattern application and pattern usage. The first category of researches [2, 9, 16] focuses on automatic pattern application and ignores the usage of design patterns. The second category of researches [4, 15, 17, 25] focuses on how to restructure a legacy system to be more qualified for the assistance of pattern-based transformation
skills. The third category [3, 12] attempts to provide a methodology to serve as a bridge between user’s requirements and design pattern technology. They put efforts on analysis of user needs rather than automation of pattern application.
Table 1 A Summary Of The Benchmark Programs objective Enginee-
ring Pattern selection
Pattern application
Pattern usage
Abstraction level Budinsky et al.
1996 [2] auto. Pattern
application forward
eng. n/a script
language n/a coding level Eden et al.
1997 [9]
auto. pattern
application forward
eng. n/a meta-
programming n/a coding level Jeon et al.
2002 [16] auto. pattern
selection forward eng.
structure- based (hot-
spot)
rule-based
transformation n/a coding level O’Cinneide
and Nixon 2000 [4]
re-restructure legacy system to provide
flexibility re-eng. evolution based (precursor)
layered transformation
improve
flexibility coding level Tahvildari and
Kontogiannis 2002 [25]
re-restructure legacy system to improve
quality re-eng. requirement based layered transformation
improve
quality coding level Khriss et al.
2000 [17]
provide traceability
by using patterns forward
eng. n/a layered
transformation
refine
model design level Huston 2001
[15]
examine the compatibility between design patterns and metrics
n/a n/a n/a improve
quality n/a
Gross and E.
Yu 2000 [12]
provide a development methodology
forward
eng. requirement
based n/a deal with
nonfunctional reqt.
requirement and design
level
Chung et al.
2003 [3]
provide a methodology for developing adaptable system
forward
eng. requirement
based n/a Improve
adaptability
architecture level
3. Design patterns and non-functional requirements
Non-functional requirements are not easy to handle because they are subjective (they can be interpreted differently by different people), relative (their importance is depending on the system being considered) and interacting (their achievement may impair or help that of others) [8, 21]. Design patterns [11] provide a possible way to deal with non¬functional requirements since they provide solutions to satisfy functional requirements as well as better solutions to meet non-functional requirements.
In particular, besides providing a basic, functional solution to a problem, a design pattern offers a qualified, non-functional improvement to that solution. For example, considering the original intent described in Observer design pattern:
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
By elaborating the intent, we can understand the design pattern is designed to resolve the communication between a subject objects and its related observer objects. Viewing from the functional aspect, it requires the subject to notify all observers when the subject changes its state. Viewing from the non-functional aspect, it requires the notification should work automatically without knowing types of observers. In other words, Observer design pattern has a FR-intent (functional requirement intent) to
address functional problems and an NFR-intent (nonfunctional requirement intent) to improve non- functional quality requirements. We thus transform a design pattern's intent into functional-intent (FR- intent) and non¬functional intent (NFR-intent) to highlight the quality contribution of the pattern [14].
The FR-intent describes what does the pattern do, and the NFR-intent concentrates on the extension to the FR-intent to describe what quality attribute the pattern can achieve, such as reusability, maintenance, or extensibility.
3.1. FR- and NFR-structure of design pattern The structure distributes the object model to achieve the goal described in the intent property.
With respective to the FR-intent and NFR-intent, FR-structure and NFR-structure are developed respectively. The major difference of NFR-structure to FR-structure is it applies object techniques to resolve problems. These techniques, such as polymorphism, abstraction, encapsulation, delegation, dynamic binding and inheritance are keys to make object-oriented system more reusable, extensible and maintainable. Figure 2 illustrates the NFR-structure and its corresponding FR-structure of Abstract factory design pattern. Essentially, NFR-structure is an extension of FR-structure to satisfy the associated NFR-intent. In our approach, the extension plays an important guideline to help us transfer a basic model to an extension model that is compatible with the NFR-structure.
Fig. 2 The FR-structure and NFR-structure of Abstract Factory design pattern.
4. Transformation rule schema
Each refinement process is based on the application of a design pattern. A transformation is described graphically by a schema called transformation rule schema. A transformation rule schema is parameterized by model elements to be specified by the designer, and is composed of two compartments.
The first compartment describes the source model of the design while the second compartment shows its corresponding target model after application of a design pattern. Fig. 3 shows the transformation rule schema that we have defined for the Observer pattern.
The procedure of applying design patterns to transform the analysis model into design model through transformation rules is depicted in Fig. 4.
After establishing the goals hierarchy for obtaining alternative models and constructing stable kernel and alternatives, the designer must specify the analysis model based on the goals hierarchy in an incremental fashion. Initially a goal in goals hierarchy is chosen that will serve as a start point for the design pattern transformation for applying under our proposed approach. According to the functional and non- functional aspects of the chosen goal, we can match one or more design patterns to deal with this goal's non-functional requirement. Designer can choose one of these design patterns suitable to match the non- functional requirement, and apply transformation rules defined with this design pattern to satisfy the non- functional goal.
5. Meeting Scheduling System
In this section, we use an example -meeting scheduling system to demonstrate the idea of our approach. Goals are identified based on the proposed verb-based classification scheme. In this example, we have identified five goals and formed a goal-driven use case model (see Fig. 5).
Schedule: [initiator, meeting date and location,
initiator, participants, ϕ, rigid]
Handle: [system, plan meetings, initiator,
ϕ, in
distributed, rigid]
Support: [initiator, meeting date and location,
initiator, participants, reusable schedule, soft]
Support: [system, meeting date, initiator,
participants, support flexible and consistent date format , soft]
Provide: [system, performance,
ϕ, ϕ, an
appropriate level, soft]
A goal in our approach is formulated as following:
Action:[Actor, Target, Source, Destination, Condition, Competence]
Action is the verb from requirement documents that a goal intends to achieve. Actor refers to people who use this system or system itself that performs the action. Target are entities affected by the goal.
Source, destination, and condition are optional. There are two types of directions: source and destination, to identify respectively the initial and final location Fig. 3 Transformation rule schema of Observer
pattern
Fig. 4 Procedure of applying design patterns
Fig. 5 Goal-driven use case model for the meeting scheduling system
Fig. 6 Interaction between goals in the system level and goals hierarchy
of objects to be communicated. Condition describes the situation prior to performing an action, which can also be used to describe the invariant that the system must keep before and after performing the action.
Competence can be either rigid or soft to identify whether the goal must be satisfied utterly or to some extent.
The goal driven use cases model is shown in Fig.
5. In this model, each goals identified above will be achieved, or optimized by a use case. For example, in order to deal with the goal Support Reusable Schedule, we need perform a use case “Support reusable schedule” to achieve it. After the use case model is constructed, the analyses between the goals interaction in use case level and in system level are evaluated. According to the GDUC method, the goals interaction in the system level is built as well as the goals hierarchy based on the interaction is constructed shown in Fig 6(a) and Fig 6(b), respectively. Notices that, the goal Support Various Data Format (GSFC) and the goal Appropriate Performance (GAP) is conflicting in the system level, since the flexible data format provided will decrease the performance. In this goals hierarchy, two alternatives are identify (Fig. 6(c)) and
the initial analysis model is obtained from the goals hierarchy and the construction of the design model is proceeded based on stable kernel in an incremental fashion from GMS to GSFC.
According to the pattern matched procedure (Fig. 4), the goal GMS is choice in the stable kernel for constructing the initial analysis model shown in Fig. 7 by FOOM notations. In this model, the Meet Scheduler class provides the central role for performing the scheduling function. Because the degree that a person belongs to the class Important Participant depends on his status and his role (i.e., student, staff, or faculty) in the meeting he attends, the Important Participant class is specified as a fuzzy entity class and inherited from the Participant class.
Additional fuzzy rules attached in the Registration class to describe the rules for fuzzy membership function.
Since the GMHID represents the system can be scheduled and handled in distributed manner, a new class “Remote Object” is added to provide this requirement (Fig. 8). After browsing the design patterns, the designer chooses the remote proxy pattern to support the distributed management and Fig. 7 Goals considered: {GMS}
Fig. 8 Goals considered: {GMS, GMHID} before applying Proxy pattern
Fig. 9 Goals considered: {GMS, GMHID} after applying Proxy pattern
apply the transformation rule to refactoring the initial mode into Fig. 9. The dotted elliptic notation named “proxy” is an UML extension means that applying the proxy pattern and the dotted lines connected the corresponding classes generated from the transformation rules. In this figure, the stereotype depicts the relationships between the model and the used name in design pattern for understanding the mapping relation. For example, the <<RealSubject>>
means that the MeetingScheduler class plays the role
“real subject” in the remote proxy pattern as well as the Meeting Scheduler Proxy class is mapping to the proxy in the same pattern.
By considering the GSRS and GSFC to realize the goal Support Reusable Schedule and the goal Support Various Data Format by applying the abstract factory and the observer patterns are shown in Fig. 10 and Fig. 11, respectively. Fig. 10 illustrates the resulting model after applying Abstract Factory pattern in the meeting scheduler system to enhance Reusable Schedule defined by GSRS. Instead of creating the product objects directly, the Scheduler uses Meeting Scheduler Factory for creating the product objects of Participant Preference, Meeting Date and Meeting Loc. The scheduling strategy can be simply reused in
a course scheduling system in the way of designing a Course Scheduler Factory which creates objects of Teacher Preference, Class Date and Class Loc.
The GSFC represents the meeting schedule system could support various data format and keep consistence between different data views, i.e., a change on one data view must make the same change on the others. To resolve the inconsistency problem, the Observer design pattern is recommended and used in Fig. 11. Observer pattern is used to resolve the inconsistency problem between a set of objects (said observers) which have a common interest on subject. By requiring the observers to register on the subject before operating, observers can be notified for keeping consistency whenever the subject changes its status.
6. Conclusion
In this paper, we propose an approach to providing a goal-driven method to transform the analysis model into design model for dealing with the software quality issues based on design patterns. With the aid of design patterns, in our approach, a goal can be achieved by a well-specified transformation rules, recovered by a proven solution, Fig. 10 Goals considered: {GMS, GMHID, GSRS } after applying Abstract Factory pattern
and enhanced by a known skill. Our approach offers two benefits: (1) deriving candidate design patterns from analysis model based on the goals hierarchy; and (2) transforming analysis model into design model incrementally based on the design pattern transformation rules for dealing with the non¬functional requirements.
References
[1] A.I. Anton. Goal-based requirements analysis.
In Proceedings of the International Conference on Requirements Engineering, pages 136–144, 1996.
[2] F. Budinsky, M.Finie, J.Vlisdes, and P.Yu.
Automatic code genration from design patterns.
Object Technology, 35(2):172-191, 1996.
[3] L. Chung, K. Cooper, and A. Yi. Developing adaptable software architectures using design patterns: an NFR approach. Computer Standards and Interfaces, 23:253-260, 2003.
[4] M.O. Cinneide. Automated refactoring to
introduce design patterns. In Proceedings of the International Conference on Software Engineering, 2000.
[5] dMOF user guide (1.1 release). Distributed Systems Technology Center (DSTC), Australia, July 2000.
[6] A. Dardenne, A.van Lamsweerde, and S. Fickas.
Goal-directed requirements acquistion. Science of Computer Programming, 20:3–50, 1993.
[7] K. Duddy, A. Gerber, M. Lawley, K. Raymond, and J. Steel. Declarative transformation for object-oriented models. Transformation of Knowledge, Information and Data: Theory and Application, Idea Group, 2004.
[8] C. Ebert. Putting requirement management into praxis: dealing with nonfunctional requirements.
Information and Software Technology , 40:175¬185, 1998.
[9] A. Eden, J. Gil, and A. Yehudai. Precise specification and automatic application of design patterns. In proceedings of the 12th IEEE Fig. 11 Goals considered: {GMS, GMHID, GSRS, GSFC} after applying Observer pattern
International Automated Software Engineering Conference (ASE 1997), November 1997.
[10] D. S. Frankel. Model Driven Architecture:
Applying MDA to Enterprise Computing. John Wiley & Sons, 2003.
[11] E. Gamma, R. Helm, R. Johnson, and J.
Vlissides. Design Patterns: Elements of reusable object-oriented software, Reading, MA: Addison-Wesley, 1994.
[12] E. Gross and E. Yu. From non-functional requirements to design through patterns.
Requirements Engineering, 6:18-36, 2001.
[13] A. Gerber, M. Lawley, K. Raymond, J. Steel, A. Wood. Transformation: The Missing Link of MDA, In A. Corradini, H. Ehrig, H.-J. Kreowski, G. Rozenberg (Eds.): Graph Transformation: First International Conference (ICGT 2002), 2002.
[14] N.-L. Hsueh and W.-H. Shen. Handling Nonfunctional and Conflicting Requirements with Design Patterns. In the proceedings of the 11th Asia-Pacific Software Engineering Conference, Page(s):608 – 615, 2004.
[15] B. Huston. The efforts of design pattern application on metric scores. The Journal of Systems and Software, 58:261-269, 2001.
[16] S. Jeon, J. Lee, and D. Bae. An automated refactoring approach to design pattern-based program transformations in Java programs.
In the proceedings of the Ninth Asia Pacific Conference of Software Engineering , pages
337-345, 2002.
[17] L. Khriss, R.K. Keller, and I. Hamid. Pattern- based refinement schemas for design knowledge transfer. Knowledge-Based Systems, 13:403- 415, 2000.
[18] A. van Lamsweerde, R. Darimont, and E. Leitier.
Managing conflicts in goal-driven requirements engineering. IEEE Transactions on Software Engineering, 24(11):908–926, November 1998.
[19] J. Lee and N.L Xue. July/August 1999.
Analyzing user requirements by use cases:
A goal-driven approach. IEEE Software, 16 (4):92-101.
[20] J. Lee, N.L. Xue, K.H. Hsu and S.J.H. Yang.
1999. Modeling imprecise requirements with fuzzy objects. Information Sciences, 118:101- 119.
[21] J. Mylopulos, L. Chung, and B. Nixon.
Representing and using nonfunctional requirements: A process-oriented approach.
IEEE Transactions on Software Engineering, 18(6):483¬497, 1992.
[22] J. Mylopoulos, L. Chung, and E. Yu. From object-oriented to goal-oriented requirements analysis. Communications of the ACM , 42(1):31–37, January 1999.
[23] C. Rolland, C. Souveyet, and C.B. Achour.
Guiding goal modeling using scenarios.
IEEE Transactions on Software Engineering, 24(12):1055–1071, December 1998.
[24] S. Sendall. Source element selection in model transformation. In UML’03 workshop in Software Model Engineering (WiSME), 2003.
[25] L. Tahvildari and K. Kontogiannis. A software transformation framework for quality-driven object-oriented re-engineering. In Proceedings of the International Conference on Software Maintenance (ICSM02), 2002.
[26] D.V.G. Varró and A. Pataricza. Designing the automatic transformation of visual languages.
Journal of Science and Computer Programming, 44: 205-227, 2002.
