"UMM Variablity and Automation of Variant ... - UniFrame - IUPUI

UML VARIABILITY AND AUTOMATION OF VARIANT MODELS
A Thesis
Submitted to the Faculty
of
Purdue University
by
Padmavathi Kambhampati
In Partial Fulfillment of the
Requirements for the Degree
of
Master of Science
December 2004

To Amma, Nannagaru, Tammudu, Sarma and Anish
ii

ACKNOWLEDGEMENTS
I would like to express my sincere gratitude to Dr. Rajeev R. Raje, my advisor,
for his extensive encouragement and support through the course of my project. He gave
me great flexibility, understanding my family needs and helped me a lot until the
completion of the project.
I would like to express my sincere and special thanks to Dr. Andrew Olson and
Dr. Xukai Zou for being on my advisory committee.
I would like to thank my beloved brother, Kamesh who helped me extensively in
model selection and development. His invaluable support at every stage of my thesis is
never forgetful.
I would like to thank my husband Sarma and my beloved son Anish for
supporting me during my stay at IUPUI.
This project was supported by the U.S. Department of Defense and the U.S.
Office of Naval Research under award number N00014-01-1-0746.
iii

TABLE OF CONTENTS
Page
LIST OF FIGURES ........................................................................................................... vi
ABSTRACT.....................................................................................................................viii
1. INTRODUCTION .......................................................................................................... 1
1.1. Problem Definition and Motivation......................................................................... 1
1.2 Objectives ................................................................................................................. 2
1.3 Contributions of the Thesis....................................................................................... 3
1.4 Thesis Organization .................................................................................................. 4
2. BACKGROUND AND RELATED WORK .................................................................. 5
2.1 Feature Model Extensions in UML........................................................................... 5
2.2 Variation Points and Variants ................................................................................... 7
2.3 Generic Modeling using UML Variability ............................................................... 9
2.4 Extending UML for Modeling Variability.............................................................. 12
2.5 UML Variability – Archetype Patterns................................................................... 15
2.6 How Archetype Patterns suit UML Variability ...................................................... 20
3. DESIGN TOOLS.......................................................................................................... 22
3.1 Generic Modeling Environment 4 (GME 4)........................................................... 22
3.2 Poseidon for UML .................................................................................................. 30
3.2.1 Poseidon for UML - Standard Edition 2.6 (E.Version) ................................... 36
3.3. ArcStyler and MDA............................................................................................... 41
3.3.1 Model Driven Architecture.............................................................................. 41
3.3.2 ArcStyler.......................................................................................................... 45
3.3.3 ArcStyler Community Architect Edition 4.0 ................................................... 46
4. EXPERIMENTAL VERIFICATION OF THE TOOLS FOR UML VARIABILITY.60
4.1 Case Study Introduction - Loan Origination System (LOS)................................... 60
4.2 Case Study Part I - Generic Modeling Environment (GME 4)............................... 64
4.3 Case Study Part II - Poseidon Standard Edition 2.6 ............................................... 65
4.4 Case Study Part III - ArcStyler Architect Edition 4.0 ............................................ 70
iv

Page
4.5 Case Study Part IV - Archetypal Model of LOS in ArcStyler................................ 74
5. FEASIBLE APPROACHES OF AUTOMATING VARIANTS ................................. 98
5.1 Algorithm Approach ............................................................................................... 98
5.2 Application Model for Developing Variant Models............................................. 103
6. CONCLUSIONS AND FUTURE WORK ................................................................. 116
6.1 Conclusions........................................................................................................... 116
6.2. Future Work......................................................................................................... 118
APPENDICES
A.1. GME 4 Features .................................................................................................. 120
A.2. Poseidon for UML Features................................................................................ 126
A.3. ArcStyler Features............................................................................................... 133
A.4. Source Code of the Interface for the Figure 5.1.................................................. 140
A.5. Source Code of the Generated XML File for the Figure 5.1 .............................. 155
A.6. XML File of the Variant Model-1 for the Figure 5.6.......................................... 160
A.7. XML File of the Variant Model-2 for the Figure 5.7.......................................... 162
A.8. XML File of the Variant Model-3 for the Figure 5.8.......................................... 164
A.9. Complete Listing of the XMI File for the Figure 4.1.......................................... 166
LIST OF REFERENCES……………………………………………………………….169
v

LIST OF FIGURES
Figure Page
Figure 2.1 Sample feature model using UML from Clauss [2] .......................................... 6
Figure 2.2 Sample usage of variation point and optional elements from Clauss [2].......... 8
Figure 2.3 Example of multiple variation points from Clauss [2] .................................... 10
Figure 2.4 Sample data model in UML with variability from Clauss [4]......................... 11
Figure 2.5 Developing system families with Domain Engineering [5] ............................ 13
Figure 2.6 Extensibility mechanisms in UML metamodel (OMG, 1999, pp. 2-67) [5] ... 14
Figure 2.7 Archetype pattern library and its archetype patterns....................................... 16
Figure 2.8 Archetype Variation ........................................................................................ 17
Figure 2.9 Archetype pattern variation ............................................................................. 18
Figure 2.10 Product and its pleomorphs ........................................................................... 19
Figure 3.1 GME feature metamodel ................................................................................. 26
Figure 3.2 GME 4 feature model with multiplicities using connections-1....................... 27
Figure 3.3 GME 4 feature model with multiplicities using connections-2....................... 27
Figure 3.4 Poseidon for UML in Community Edition 2.6 [11] ........................................ 30
Figure 3.5 Professional Edition 2.6 Class diagram in Poseidon for UML [12]................ 32
Figure 3.6 Professional Edition 2.6 Class properties in Poseidon for UML [12]............. 33
Figure 3.7 Professional Edition 2.6 Java code generation in Poseidon for UML [12]..... 34
Figure 3.8 Standard Panes in Poseidon for UML [13]...................................................... 37
Figure 3.9 Rapid buttons around a class in Poseidon for UML [13] ................................ 39
Figure 3.10 Autocritiquing in Poseidon for UML [13]..................................................... 39
Figure 3.11 Import mechanism in Poseidon for UML [13].............................................. 40
Figure 3.12 Model Driven Architecture Framework [14] ................................................ 43
Figure 3.13 Transformations in MDA [14]....................................................................... 44
Figure 3.14 ArcStyler Overview [16] ............................................................................... 48
Figure 3.15 Full Life Cycle support of Unified Process in ArcStyler [16]....................... 49
Figure 3.16 ArcStyler Architecture in detail [16]............................................................. 50
Figure 3.17 Sequence diagram in ArcStyler [18] ............................................................. 52
Figure 3.18 Modeling Operation Exceptions [18] ............................................................ 53
Figure 3.19 OCL Specification in ArcStyler [18]............................................................. 55
Figure 3.20 ArcStyler 4.0 Community Architect Edition................................................. 56
Figure 3.21 ArcStyler package specification dialog box.................................................. 57
Figure 3.22 ArcStyler package diagram using Class diagram toolbar.............................. 58
Figure 3.23 ArcStyler Class diagram................................................................................ 59
Figure 4.1 Incomplete top level diagram of LOS from Poseidon (with watermark)........ 68
Figure 4.2 Use-case Diagram of Loan Applicant ............................................................. 76
Figure 4.3 Use-case Diagram of Loan Originator ............................................................ 77
vi

Page
Figure 4.4 Activity Diagram of Loan Origination System ............................................... 78
Figure 4.5 Main package of Loan Origination System (LOS) from ArcStyler ................ 79
Figure 4.6 Top-level diagram of Loan Origination System.............................................. 80
Figure 4.7 Party, Loan Applicant, Loan originator and Company Archetype Patterns.... 81
Figure 4.8 Party Relationship Archetype Pattern ............................................................. 82
Figure 4.9 Party Relationship-Product Relationship Archetype Pattern .......................... 83
Figure 4.10 Product Archetype Pattern............................................................................. 84
Figure 4.11 Product:Loans and its Pleomorphs Archetype Patterns................................. 85
Figure 4.12 Order Archetype Pattern of LOS................................................................... 86
Figure 4.13 Customer Relationship Management (CRM) Archetype Pattern of LOS..... 87
Figure 4.14 CRM Archetype Pattern for a specific case of Auto Loan............................ 88
Figure 4.15 CRM Archetype Pattern for a specific case of Credit card Loan.................. 89
Figure 4.16 Instantiation of Archetype Patterns through parameterized collaboration.... 90
Figure 4.17 Instantiation of Archetype Patterns through parameterized collaboration.... 91
Figure 5.1 Custom Application Model for Developing Variants ................................... 108
Figure 5.2 Action of the CLEAR push button ................................................................ 109
Figure 5.3 PAGE RELOAD push button action............................................................. 110
Figure 5.5 Error Message display in the model .............................................................. 112
Figure 5.6 A variant model-1 of the application............................................................. 113
Figure 5.7 A variant model-2 of the application............................................................. 114
Figure 5.8 A variant model-3 of the application............................................................. 115
vii

ABSTRACT
Kambhampati, Padmavathi, M.S., Purdue University, December 2004. UML Variability
and Automation of Variant Models. Major Professor: Rajeev Raje.
Unified Modeling Language TM (UML TM ) [1] is the well-known language for designing
software systems. Although, UML has the capability of developing large scale product
domains, it lacks notation and semantics for the development of software families of
related product domains. In other words, describing variability in UML is very important
in developing product domains of related families but it is not well supported. It also
reduces time and cost of application development, and supports reusability. The current
Thesis deals with the concepts of variability in UML, followed by the comparison of the
modeling tools Generic Modeling Environment 4 (GME 4), Poseidon, and ArcStyler in
developing an archetypal model with variabilities and extracting variants. A case study
was done using ArcStyler, and a metamodel with variabilities is developed using
archetype patterns. The results indicate that, so far, no tools experimented with here
provide automation of variant models from the archetypal metamodel. So feasible
approaches were proposed to produce variants automatically from the variability model.
viii

1. INTRODUCTION
1.1. Problem Definition and Motivation
UML is the Object Management Group TM (OMG TM ) [1] standardized
specification language for the design of software systems. UML can be used for business
modeling to develop use-case diagrams, activity diagrams, and in the area of application
modeling to develop class diagrams, component diagrams, object diagrams and
deployment diagrams. UML helps us to specify, model, visualize, and develop problem
domains and provides documentation of the system.
Although it can be used to design software systems, the basic UML lacks proper
notation and semantics for developing families of related software systems. That point
motivated searching for concepts for expressing variability in UML. Variability is
essential in software design to develop large scale systems of the similar domains. As a
next step, automatically extracting variant models out of the domain model with
variations is also studied. So tools like GME 4, Poseidon for UML and ArcStyler are
experimented with to obtain a feasible solution to these two problems. None of these
tools is successful in giving the needed output for the second step. So, this Thesis
provides possible options of producing variants from the variability model automatically.
In the first place, building a model with variabilities is a difficult issue because
variability design is doing the design for related systems of the same family in a single
1

generic system. Although many approaches have been proposed, so far no approach was
suitable to fit into typical UML modeling. Since UML is standardized as the basic
language to be employed in design, expressing variability in UML design is important. A
UML variability model would include many models within itself, which can be used
according to the need and requirements. A variability model represents a generic model
from which other models of a similar kind can be derived. For example, if a variable
domain model of a loan system is built, it may contain loan models for credit cards,
mortgages, auto financing, student loans, etc. So, from the generic loan model, we could
at least derive four types of variant models. UML variability also has certain other
advantages. The design, development and implementation costs can be reduced, each
time the chance of producing an effective design increase, automatic updating of the
domain models, saves time and money, and variable domain model serves as a prototype
for building much more complex models with variability. What is also needed in tool
support is the ability to select variant models from the generic model.
In summary, the formal definition of the problem statement that this Thesis
considers is as follows: to find a notation mechanism to represent variability in UML and
tools for creating variable models and extracting variant models out of them.
The main objectives of this thesis are:
1.2 Objectives
Determine notation consistent with UML for representing variabilities.
Find and experiment with tools for constructing UML models with variabilities.
2

Find and experiment with tools for extracting variant models from models with
variabilities.
Decide which tool is effective enough from all aspects to develop a variable model.
Aspects checked in tools are:
• Feature availability
• GUI of the tool
• Tool speed
• Other advantages
Compare features of the tools experimented with and produce the results in tabular
format.
Finally, decide on the tools that successfully create a variation point model and
generate automatically its variant models.
If no tool is successful, then propose an approach to select a variant, given a set of
requirements, from the variation point model.
The contributions achieved in this thesis are:
1.3 Contributions of the Thesis
Discovered that archetype patterns are an effective way to represent variability in
UML and that they have tool support.
Worked with the tools GME 4, Poseidon for UML, and ArcStyler, and developed a
metamodel with variabilities using archetype patterns for a specific domain system
using ArcStyler.
3

Decided that the ArcStyler tool is effective enough from all aspects to develop a
variable model.
Aspects mentioned in the objectives are checked in the tools experimented with.
The results of the tools compared are produced in tabular format.
So, no tool considered provides the feature of automating variants from the variable
model. Finally, suggested possible approaches to select a variant, given a set of
requirements, from the archetypal model.
1.4 Thesis Organization
The current thesis report is organized into 6 chapters. The first chapter
introduction explains basically the problem definition and motivation, why the specified
problem is important, the Thesis objectives and the contributions of the thesis. Chapter 2
talks about the background and related work of the problem. Chapter 3 includes details
about the various tools compared. Chapter 4 discusses the application of the tools for a
case study. Chapter 5 describes the approaches for extracting variants from a variability
model. Finally Chapter 6 briefly talks about the conclusions and future work related to
the problem of the Thesis.
4

2. BACKGROUND AND RELATED WORK
In this chapter, background and related work with respect to the problem of UML
variability and developing models with variabilities is discussed.
2.1 Feature Model Extensions in UML
Variability in UML can be expressed by incorporating feature model extensions
in software design. According to Matthias Clauss [2], feature model extensions are a way
to include feature diagrams into UML. Four types of features with stereotypes
«mandatory», «optional», «alternative» and «external» are proposed. Relationships like
composition, generalization and dependency are included.
Exclusive and non-exclusive features are distinguished by the constraint {xor}.
Other constraints «requires», «mutex», and «extends» stereotypes are specified for
dependencies. However, a transformation mechanism from the feature model to build the
architecture of the system is not specified.
5

Figure 2.1 Sample feature model using UML from Clauss [2]
Figure 2.1 shows an example of an internet e-commerce domain and includes all
basic and primary feature model extensions like «mandatory», «optional», «alternative»
along with constraints imposed with dependencies like «requires», and «mutex». The
relationships composition, generalization and dependency with the {xor} tagged
constraint applied to non-exclusive features are shown.
These feature model extension concepts can be applied to small feature models,
but are not suitable for building complex feature metamodels [2]. There is no clear
notation and semantics for the specification of attributes and operations. There is no
proper straight UML tool that supports feature model extensions to show variability in
6

UML (if the representation of a feature is by a special UML feature icon). However, if we
want to enforce these feature extensions for small projects, it can be implemented with
UML Class diagrams, which allows us to create characteristic feature classes with class
objects as shown in Figure 2.1.
2.2 Variation Points and Variants
Another approach proposed by [2] to represent feature models includes the
concept of variation points and variants. Each variation point can have any number of
variants and the selection of the variant is determined by the parameters like binding time
(development, installation and runtime) and multiplicity. Variation points are created by
the stereotype «variationpoint» and its corresponding variants are created by the
stereotype «variant». Variation points and variants are necessary in developing software
systems because they distinguish one system from the other in a family of related
software domains. A variation point is connected to its variants by the dependency
constraints like «requires», «mutex», «evolution» replaces and «uses». Specification of
OCL constraints is not supported.
7

Figure 2.2 Sample usage of variation point and optional elements from Clauss [2]
Figure 2.2 shows how variation points and their corresponding variants are
connected. It also depicts the usage of optional elements along with «requires», «mutex»,
«evolution» replaces, and «uses» constraints among feature elements.
Clauss provides no explicit notation to represent other features in the feature
diagram. According to [2], the variation points and variants can be implemented by a
UML class diagram with out attributes and operations. He allows the representations:
generalization, composition or dependency to connect a variation point and a variant. An
«optional» stereotype is present to declare optional model elements in the feature
diagram.
The weakness of this notation includes the fact that the only possible constraints
that can be applied to variation points and variants are with the stereotypes «requires»,
«mutex», «evolution» replaces, and «uses» in the form of dependencies. There is no
8

support to specify constraints in OCL. There is no clear documentation available to
establish a relationship between a feature node and a variation point (if the relationship is
other than generalization, composition or dependency). If the relationship is not a
generalization or composition, then for everything, dependency should be used. This
concept causes confusion during the implementation of feature models. According to [2],
these concepts are not sufficient to support large feature models.
2.3 Generic Modeling using UML Variability
Generic models are similar to normal UML models except they exhibit the feature
of variability explicitly. Basically, generic models are used in the domain engineering
area to develop system families [3]. The concept of variation points has its roots in the
field of product family engineering [4].
Every variation point can have any number of variants, but every variant should
be connected to only one variation point. Variation point and variant are constructed
with the stereotypes «variationPoint» and «variant». Because of UML limitations,
«variationPoint» is applied to the model element that shows variability. Variation points
can be applied on classes, components, packages, collaborations and associations. The
«variationPoint» stereotype contains tagged values that determine binding time of the
variants and the multiplicity of its variants. The question of which «variant» should be
used is determined by the condition values specified in the variants.
Interactions between variants and other model elements are represented by
dependency constraints like «mutex» and «requires». Variation points and variants are
connected by either generalization or dependency. Generic models may contain more
9

than one variation point in their models. To distinguish one variation point from the
other, a unique name is assigned to each variation point. Usage of multiple variation
points and their variants are shown in the Figure 2.3.
Figure 2.3 Example of multiple variation points from Clauss [2]
In the Figure 2.3, sort is a template-based variation point with two variation
points. VariationPoint 0 deals with different types of sorting techniques, like bubble_sort,
quick_sort, and insert_sort, while the other variation point, variationPoint 1, deals with
different data type sorting techniques like IntegerSort and StringSort. All variants are
bound to the respective variation points through template bindings.
A real world UML example shown in Figure 2.4 implementing the concepts of
variation points, variants, optional elements and other model elements is taken from [5].
But these extension mechanisms need to be verified and some more research is to be
done according to [3]. The example is shown below.
10

Figure 2.4 Sample data model in UML with variability from Clauss [4]
In Figure 2.4, PaymentInfo class is declared with the stereotype «variationPoint»,
and its variants Billing_Data, CreditCard_Data and Delivery_Data are connected by
generalization. Optional element Contract has a «requires» dependency relationship from
PriceMethod «enumeration» class.
The explained variation points and variants in developing generic models in UML
concepts are supposed to integrate feature modeling with UML in practice from [3].
11

2.4 Extending UML for Modeling Variability
An approach was proposed in [6] to use light weight extension mechanisms in
UML metamodeling that essentially would not violate actual UML semantics.
Development of software system families involves two principal aspects of
engineering, Domain Engineering and Application Engineering. Domain Engineering
comprises domain analysis, domain design and domain implementation phases.
Application Engineering can be treated as the implementation of the first principal aspect,
Domain Engineering.
Domain Engineering deals with the development of system families for
reusability. Application Engineering basically makes use of the assets and results
obtained from Domain Engineering that enable one to produce systems with reusability.
Variability can be achieved in domain engineering during the domain analysis phase, in
which feature analysis methods like FODA [7] can be applied to target on the variable
and common features of the domain. The two aspects’ interconnections are shown in the
Figure 2.5.
12

Figure 2.5 Developing system families with Domain Engineering [5]
UML metamodeling extensions are proposed in [6] to exhibit variability in UML.
Lightweight extension mechanisms such as stereotypes, constraints and tagged values are
represented in the UML metamodel as the metamodel’s classes named Stereotype,
13

Constraint and TaggedValue. These extension mechanisms are given diagrammatically in
the Figure 2.6, taken from [6].
The Stereotype class applies to a variable and the TaggedValue class applies to a
feature. Every stereotype «variable» is associated with a TaggedValue «feature». This
approach leads to much complexity in model building, is quite difficult to understand,
and is hard to construct without sophisticated tool support [6].
Figure 2.6 Extensibility mechanisms in UML metamodel (OMG, 1999, pp. 2-67) [5]
14

Integration of feature modeling constructs into UML and introduction of a
separate UML profile to build system families is the next possible step in this area [6].
2.5 UML Variability – Archetype Patterns
According to [8], Archetype comes from the Greek word “archetypo”, which
means “original pattern”. The definition of archetype is as follows, “An archetype is a
primordial thing that occurs consistently and is thought to be a universal concept or
situation”. An archetype pattern is a collaboration between archetypes that occurs
consistently in business environments and software systems.
Archetype patterns are supported by a specific UML profile [8]. The most
interesting feature of archetype patterns is they explicitly address the problem of
variability. Class is modeled by a stereotype called «archetype», package is modeled by
the «archetype pattern» stereotype, «archetype pattern library» models collaboration
package, «o» is for modeling optional elements and relationships, and the «pleomorph»
stereotype for marking explicitly variation in the model.
15

Figure 2.7 Archetype pattern library and its archetype patterns
Archetypal concepts can be successfully implemented with the latest Model
Driven Architecture tools like ArcStyler [8]. Existing UML profiles for archetype pattern
modeling can be extended using ArcStyler. Likewise, archetype patterns can be
incorporated directly or can be varied to suit problem domains. An example of an
archetype pattern library and archetype patterns is given in Figure 2.7.
In the Figure 2.7, money-management-systems is an archetype pattern library that
is a collection of several archetype patterns, Banking, Education, Transport and
International aid (Intl.aid). Each of the archetype patterns possesses its own archetypes
inside it. Some of the archetypes are Insurance, Schools, Rail, Road, and Loans &
Investments. Archetype patterns exhibit three types of pattern variation. They are:
Archetype variation: Archetypes exhibit different features, like different attributes,
operations and constraints to fit themselves into different environments.
16

Archetype pattern variation: Optional features in archetype patterns can be omitted to
suit different business domains.
Pleomorphism: This is a special type of archetype pattern variation in which an
archetype pattern may take different structures to adapt itself in software
environments. The archetype pattern variation can be addition of new archetypes,
features, and relationships in the existing pattern.
Archetype variation deals with two issues: new features may be added in the
archetypes, optional features may be deleted. An example of archetype variation is given
in Figure 2.8.
Figure 2.8 Archetype Variation
In Figure 2.8, Ticket class is modeled with the stereotype called «archetype».
Issue-date, Name, Party-signature, Transferable, Price are all attributes, in which
Transferable and Price are optional attributes. Getdetails() and Getsignature() are
operations, and Getsignature() is an optional operation. So the user has the flexibility of
deleting optional features like optional attributes and optional methods when creating an
17

archetype of the same name in different business domains. We can also add new features
in the archetypes. Archetype variation can be implemented by the tools like ArcStyler.
A second type of variation exhibited by archetypes is archetype pattern variation.
Archetype pattern variation deals with variations in archetype patterns, like optional
features may be deleted from the pattern if not needed. Example: optional relationships.
An example of archetype pattern variation at the archetype pattern library level is
given in the Figure 2.9.
Figure 2.9 Archetype pattern variation
18

In the Figure 2.9 Management systems is an archetype pattern library and
Managemnentsystems-I, Managementsystems-II, Managementsystems-III, and
Managementsystems-IIII are variants of the archetype pattern library, Management
systems. In the archetype pattern library, a stereotype called «o» is included to explicitly
say that a particular archetype pattern is optional. So, they can be included or omitted
depending upon need.
In the example of Figure 2.9, different variants of the archetype pattern library,
Managementsystems are shown. insurance_mgt and transport_mgt are optional archetype
patterns while the others are mandatory by default.
Pleomorphism is a kind of archetype pattern variation in which archetype patterns
may change entirely according to the particular business context. Variants of the variation
point are connected by the UML realization relationship symbol with the stereotype
«pleomorph». Pleomorphism can be applied only to an archetype pattern, which is a
combination of archetypes.
Figure 2.10 Product and its pleomorphs
In the Figure 2.10, Product is an archetype pattern which is a variation point, and
its variants are Unique product and Identical product. Each variant is described by the
stereotype «pleomorph» and is connected by the arrow pointing towards its variation
19

point. Each variation point can possess any number of pleomorphs, i.e., any number of
child variants. In this example, Product’s pleomorphs, Identical product and Unique
product, are types of Product and may additionally possess new archetypes and features,
and optional features present in the original Product may not be present in its
pleomorphs, while mandatory ones exist anyway.
2.6 How Archetype Patterns suit UML Variability
Archetype patterns directly address the problem of UML variability through the
concept of pleomorphism. The variability is shown at the package level with the
«archetype pattern» stereotype applied to the package. Expressing variability through
archetype patterns is one of the possible ways of solving the Thesis problem. This
approach is adopted here, because the concept is extended with the appropriate tool
support. As the variability is expressed at a high level of abstraction, the user is not
thrown into unnecessary confusion. Since the meaning of archetype means generic, so the
generic model possesses variability from which several models of the same kind can be
derived. Advantages of archetypes for UML variability are as follows:
Archetypes are simple to use in the application models.
Archetype patterns directly address the problem of variability through pleomorphism.
The UML profile for archetypal models is easy to understand.
Archetypes are optional by default with in the archetype pattern context, which gives
the user much more flexibility in constructing variable models from the generic
model.
Archetype patterns for use in different domain applications are available.
20

UML variability is expressed at the package level of the model, unlike at class level,
which introduces much complexity.
Archetype models are generic models, from which other models can be derived
easily.
Disadvantages of the other suggested approaches, Feature model extensions, Variation
points and Generic Modeling include:
Feature model extensions notation is incomplete for developing domain models,
because it does not provide transformation mechanism to the system architecture.
Although variation point mechanism explains variability at the class level, the
constraint notation is not consistent with UML, for implementation.
Concepts are hard to understand and implement.
Integration of UML modeling and feature modeling for variability so far cannot be
achieved practically.
Other disadvantages of feature modeling are clearly explained in [20].
21

3. DESIGN TOOLS
This chapter gives a detailed description of the various design modeling tools like
GME 4, Poseidon, ArcStyler. These tools were used in searching for an effective and
feasible solution for constructing an archetypal model with variabilities.
3.1 Generic Modeling Environment 4 (GME 4)
The Generic Modeling Environment 4 (GME 4) is a configurable toolkit for
creating domain-specific modeling environments. The configuration is accomplished
through metamodels specifying the modeling paradigm (modeling language) of the
application domain. The modeling paradigm defines the family of models that can be
created using the resultant modeling environment [9]. Two concepts lie in the
background of GME 4, one is Model Integrated Computing (MIC) and the other is
Metamodeling.
Model Integrated Computing addresses the problem of designing, creating and
developing information systems by providing domain-specific environments including
domain model analysis and model-based program synthesis tools [10].
Model integrated computing (MIC) is an effective and efficient method for
developing, maintaining, and evolving large-scale, domain-specific software applications
for Computer-based systems (CBS). On a higher level, it is possible to use MIC to
22

develop, maintain, and evolve the meta-level tools (metamodeling environments)
themselves, by modeling the metamodeling environment (meta-metamodeling). The key
idea in the Model Integrated Computing (MIC) framework is the consistent application of
a meta-level architecture.
A metamodel is a formalized description of a particular modeling language, and is
used to synthesize the modeling environment itself. Metamodels are models of a
particular modeling environment. Metamodels contain descriptions of the entities,
attributes, and relationships that are available in the target modeling environment. A
metamodel specifies a domain modeling language which, in turn, is used to specify
models of artifacts in the particular domain. UML class diagrams do allow the
specification of some basic rules, for example, the multiplicity of associations. For more
complex semantic specifications, however, UML includes the Object Constraint
Language (OCL), a textual predicate logic language. MIC adopts OCL as well;
metamodels consist of UML class diagrams and OCL constraints.
The Generic Modeling Environment, GME 4 is a Windows-based, configurable,
domain-specific, model-integrated program synthesis tool. The GME is configurable,
which means it can be “programmed” to work with vastly different domains. Another
important feature is that GME’s are generated from formal modeling environment
specifications. This allows a particular GME to be efficiently designed and implemented,
and ensures that it can be quickly and safely evolved as modeling requirements change.
The GME includes several other relevant features:
23

It is used primarily for model-building. The models take the form of graphical, multi-
aspect, attributed entity-relationship diagrams. The semantics of a model is not the
concern of GME – that is determined later during the model interpretation process.
It supports various techniques for building large-scale, complex models including the
techniques like hierarchy, multiple aspects, sets, references, and explicit constraints.
It contains integrated model interpreters that perform translation and analysis of
models currently under development.
GME is an environment where model-integrated computing (MIC) is achieved
through model-integrated program synthesis (MIPS). A MIPS environment operates
according to a domain-specific set of requirements that describe how any system in the
domain can be modeled. A MIPS environment consists of three main components:
(1) A domain-aware model builder used to create and modify models of domain-specific
systems,
(2) The models themselves, and
(3) One or more model interpreters used to extract and translate semantic knowledge
from the models. GME implements Multigraph Architecture (MGA), a toolset for
creating domain-specific modeling environments like MIPS.
The process begins by formulating the domain’s modeling paradigm. The
modeling paradigm contains all the syntactic, semantic, and presentation information
regarding the domain - concepts used to construct models, what relationships may exist
among those concepts, how the concepts may be organized and viewed by the modeler,
and rules governing the construction of models. The modeling paradigm defines the
family of models that can be created using the resultant MIPS environment. Metamodels
24

are models of a particular modeling environment. Metamodels contain descriptions of the
entities, attributes, relationships that are available in the target modeling environment.
Once GME is associated with a particular application domain, the modeling
paradigm is determined and the tool environment is configured accordingly. Once a
metamodel has been created, it is used to automatically generate a domain-specific GME.
The GME is then made available to the users who use it to build domain-specific models.
Once the modeling paradigm is established, the GME allows consistent valid models to
be built, and then interpreter writing begins. Interpreters are model translators designed to
work with all models created using the domain-specific GME for which they were
designed. The purpose of the GME is to create and manipulate these models. GME
provides an interface (BON) for the users in writing interpreters.
The working environment of GME with metamodel and its model are given in the
form of snapshots below.
25

Figure 3.1 GME feature metamodel
26

Figure 3.2 GME 4 feature model with multiplicities using connections-1
Figure 3.3 GME 4 feature model with multiplicities using connections-2
27

A GME model typically has parts - other objects contained within the model.
Parts come in these varieties:
Atoms (or atomic parts) - do not have internal structure.
Other models- model containing other models, atoms, connections.
References (which can be thought of as pointers to other objects).
Sets (which can contain other parts like atoms, connections).
Connections (connecting any two parts in a model).
The GME interaction is through two user interfaces: Model Browser, and
Graphical Editor. Models are stored in a database and are organized into projects. A
project is a group of models created using a particular modeling paradigm. A project is
further organized into folders. GME also possess Part Browser, where user can drag and
place objects in the model browser and make changes to it, and Attribute Browser, the
user can specify the attributes and preferences for the objects placed in the model
browser.
In GME, annotations are created by clicking an empty area in the model editor
window. User-developed metamodel paradigms can be registered in the windows registry
without much difficulty. Projects can be loaded from any local database, or from an XML
DTD document into the model browser. The graphical editor has normal, add connection,
and delete connection, set, zoom and visualization modes.
GME 4 includes an integrated Constraint Manager (CM) component. The task of
the CM is to enforce the constraints that the given paradigm contains. All the constraints
are checked when the user initiates constraint checking through the File menu or the
toolbar. The Check item and the checkmark looking toolbar button checks all the
28

constraints that correspond to the current model. The Check All item makes the CM
check all the constraints for all the objects in the project. Each constraint has a priority
that controls the order of constraint evaluation. Higher priority constraints are checked
first. The constraint specification contains the constraint equation written in MCL, a
language based on the Object Constraint Language (OCL).
GME supports model libraries, an important mechanism for reusing design
artifacts. The metamodel is actually a diagram in GME, which contains atoms, models,
connections, sets, references etc. The above mentioned objects are collectively known as
first class objects (FCO) in GME. Aspect mapping is for the purpose of visualization in
GME, where the user can make hide/open the objects in a particular view of the model.
GME supports COM interfaces for enabling the users to write interpreters in any
language they prefer that support COM, like visual basic, java, c++, etc. The component
interface is implemented on the top of the COM interface. When the user initiates model
interpretation, the component interface creates the so-called Builder Object Network
(BON). The builder object network mirrors the structure of the models: each model,
atom, reference, connection, etc. has a corresponding builder object.
GME 4 is free software available for the users to develop metamodeling of large
computed-based systems. It is a research effort of the Institute for Software Integrated
Systems, Vanderbilt University. The latest version of this tool is GME version 4.0.
GME 4 provides no complete tool support for UML modeling. Detailed
discussion of its features is presented in the Chapter 4.
29

3.2 Poseidon for UML
Poseidon for UML is a full-fledged, platform-independent, easy to learn UML
CASE tool from Gentleware AG. Poseidon for UML, which has its roots from the open
source project called ArgoUML, evolved as one of the best feasible tools for feature-rich
large-scale UML modeling. Poseidon is available in multiple editions to suit the
requirements of wide range of software designers. Gentleware AG is one among the first
UML CASE tool suppliers to integrate UML 2.0 technology into the product line of
Poseidon for UML.
Figure 3.4 Poseidon for UML in Community Edition 2.6 [11]
30

The Community Edition 2.6, which is the base version, contains all UML
diagrams and all implemented diagram elements. The user can create, save, and load
projects and browse existing models. Java code generation and diagram export to various
formats is supported [11]. It is free to download, install and work for designing projects.
The Figure 3.4 reflects the environment of the Community Edition in Poseidon for UML.
The Standard Edition 2.6 is an extendable base version, relative to the Community
Edition. The features that are not available in the Community Edition are present in this
edition. Those features include zooming, printing, drag-and-drop, code preview and
editing, documentation generation, and diagram export [11]. It offers forward and reverse
engineering for Java, automatic documentation generation, and full undo/redo. The
export for the HTML documentation allows users to share the documentation with others
over the web or intranet. The export outcome includes all the information of a UML
model including the diagrams. Modularity through the plug-in mechanism and integration
interface allows plug-in selection and development [11]. The Standard Edition has two
versions: an evaluation version for which the user can get a temporary key to work with
the tool for a specific period of time, and a commercial version, which has the full
capabilities mentioned above. The Evaluation version is free but some options might not
work unless purchased.
The Professional Edition 2.6 is the high-end version of Poseidon for UML.
Designed professionally for software developers, it includes roundtrip engineering, JAR
and MDL import, and provides code generation for Java, C++, Delphi, C#, VB.Net,
CORBA, SQL, C#, and helps in template programming. Figures 3.5, 3.6 and 3.7 are the
snapshots of Professional Edition in Poseidon for UML version 2.6 taken from [12].
31

Figure 3.5 Professional Edition 2.6 Class diagram in Poseidon for UML [12]
32

Figure 3.6 Professional Edition 2.6 Class properties in Poseidon for UML [12]
33

Figure 3.7 Professional Edition 2.6 Java code generation in Poseidon for UML [12]
34

The Enterprise Edition extends the Professional Edition for use in highly
collaborative development environments, enables team support and real time
synchronization. With its client-server architecture, the Enterprise Edition allows for
collaborative modeling. The members of a development team can work on the same
project concurrently. The project itself is managed and stored on the server and replicated
on all clients. Modifications of the model on a client are deployed to all other clients
immediately.
In order to meet the needs for the development of embedded systems, the
Embedded Edition combines the features of the Professional Edition with optimized code
generation in ANSI C and C++.
Plug-ins can be added to Poseidon for developing complex and highly-customized
applications. They add support for code generation for a specific programming language,
add a new profile, gear generation frameworks specialized for platforms like EJB or .Net,
run automatic layouts for diagrams, simulate the execution of models, validity checking
of the model etc [11]. The plug-ins includes diagram layouting, code generators for EJB
and MDA, and profiles for Requirements Engineering [11]. The users can build plug-ins
using the open Application Programming Interfaces (API) in Professional Edition.
AndroMDA 2.0 plug-in provides integration of Poseidon and AndroMDA code
generation framework. The b+m EJB 1.0 plug-in provide code generation from the
current UML model by defining several profiles and settings in the UML model. The
GoVisual Autolayout 1.4 plug-in provides high quality layout of the diagrams in
Poseidon for UML. With Requirements Engineering 1.2 plug-in, additional requirements
can be added to the use-case diagrams and are stored in the UML model. Documentation
35

can be generated by UML-doc plug-in available in the tool. The Yworks Autolayout 1.3
plug-in enables automatic layouting of class diagrams in Poseidon for UML. Autolayout
and UML-doc plug-ins are obtained in Standard Edition Evaluation version.
3.2.1 Poseidon for UML - Standard Edition 2.6 (E.Version)
The work in this thesis regarding Poseidon for UML tool is implemented in the
Standard Edition 2.6 Evaluation Version of Poseidon for UML.
Poseidon for UML has its birth from ArgoUML, an open source UML CASE
tool. Initially Poseidon was developed using the source code of ArgoUML. Poseidon is
more mature, with additional features, and is more stable. The difference between
ArgoUML and Poseidon is, the former is intended much towards research, open source,
and extensibility while the latter is used in commercial and professional environments.
The Standard Edition is the extendable base tool for the professional Edition. This
edition comes with all features of the Community Edition plus other features like
printing, drag-and-drop to the Windows clipboard (copy diagrams to Word or
PowerPoint, not functional in evaluation version), and full zoom. Through a plug-in
mechanism you can pick and choose from a growing set of plug-ins that allows you to
further extend its functionality (not in evaluation version). In addition, e-mail support for
this edition from the vendor [13].
UMLdoc, the HTML documentation generator, enables users to export models to
HTML format and share it with others over the web or intranet. The documentation
includes all the information of a UML model including the diagrams. The Standard
Edition allows you to load (and unload) plug-ins at runtime (not in evaluation version).
36

Figure 3.8 Standard Panes in Poseidon for UML [13]
Poseidon for UML is written completely in Java and is platform-independent,
runs almost on any computer. Poseidon main working window has four panes, diagram
37

pane, navigation pane, overview pane, and display pane. Diagram pane displays the
various UML diagrams, and is the largest pane. Diagram pane has the grid by default.
The user can adjust the settings of the grid, or can entirely hide the grid layout.
Navigation pane displays models and model elements based on the selected view, and
also provide easy movement between its pane and diagram pane. Overview pane provides
another means of navigation and display control. It is the smallest pane; critiques
displayed here allow the user to build accurate models that produce code that can be
compiled. Details pane displays details of all the model elements as selected. The user
can add or modify properties of the models from this pane. A diagrammatic view of the
panes in Poseidon is shown in Figure 3.8.
All types of UML diagrams are supported by Poseidon. Inline text editing is
possible here; that is, users can rename the model element by double clicking on it in the
diagram pane. A search mechanism helps users to find an element given by its name,
which may be a class, an attribute or an operation.
Rapid buttons enable the user to quickly develop the design model without much
pain. When the user clicks on the package or any model element, several buttons appear
around the edges of the model element. With the help of one click and mouse release
action, an association, dependency, generalization etc can be created from the
corresponding element to the required element. Rapid buttons is a toggle switch. The
Figure 3.9 shows rapid buttons around a class.
38

Figure 3.9 Rapid buttons around a class in Poseidon for UML [13]
Project files are exported to xmi format, printing, page setup are not available in
this evaluation version. Zooming feature enable users to view the diagram more clearly
according to the selection part. Critiques helps to produce correct and efficient models by
walking through design issues, design goals according to the priority set by the system.
The user can also set his design goals and specify his design issues (not present in
evaluation version). Autocritiquing is a toggle switch, provides critiquing automatically.
Autocritiquing option in settings dialog box from view menu shown in Figure 3.10.
Figure 3.10 Autocritiquing in Poseidon for UML [13]
39

Code generation is only in Java in Standard Edition evaluation version.
Documentation is generated by UMLdoc tool in HTML format. Plug-ins cannot be added
and be worked in this version. Constraints can be done in plain English or any language
of user’s choice apart from OCL. All types of relationships can be drawn and comments
can be added for extra documentation about the model elements.
Import of java files can be done with the import option in Standard Edition.
Specify the class path of the java files and clicking on the Apply button will open
Poseidon working screen with the model in diagram pane and corresponding source code
in details pane. The Import window is shown in Figure 3.11. Poseidon commercial
version supports import of JAR files and model files developed using Rational Rose with
.MDL extension.
Figure 3.11 Import mechanism in Poseidon for UML [13]
40

Poseidon creates a project file with the extension .zuml, a .zip file containing a
.proj file having the project information and an .xmi file with model and diagram layout
information (adopts Diagram Interchange Standard 2.0). The Diagram interchange
Standard is still in the final phase of acceptance according to [19]. A diagram can be
exported in jpeg, gif, svg, wmf formats, whereas the project can be exported in XMI
format. The evaluation version of the tool can be obtained from the official website [12]
of Poseidon for UML.
3.3. ArcStyler and MDA
ArcStyler from Interactive Objects is a comprehensive, architecture-driven,
model-centric, platform-independent, Model Driven Architecture (MDA-compliant) tool.
ArcStyler transforms platform-independent models (UML models independent of
any platform) to platform-specific models like EJB, CORBA, C#, .NET, and generates
optimized code for all business processes and business applications. ArcStyler is
available in two editions, one is Architect Edition and the other is Enterprise Edition.
Detailed description of ArcStyler is continued after the explanation of Model Driven
Architecture (MDA), the underlying concept behind ArcStyler construction. In order to
understand ArcStyler thoroughly, the user has to have a basic knowledge about Model
Driven Architecture.
3.3.1 Model Driven Architecture
Model Driven Architecture TM (MDA TM ) [1] is a framework standardized by the
Object Management Group (OMG) to design and develop platform-independent models
for different types of applications.
41

Executable code is not a safe measure of saving the application for long periods of
time. One issue is, it is hard to understand the code as we make changes in the application
in course of time, and the other issues like loss of existing data, corruption to the source
code can occur because of mishandling and misinterpretation. So, there is a need to store
applications in some design format. An answer turned out to be as Unified Modeling
Language (UML). Model-driven approach is developing the application from the model
of the application. A necessity was brought up to produce code generation out of the
project model directly from the modeling tool in order to integrate model and code. This
model-to-code driven approach reduces cost of the application development, also makes
manual intervention less in writing the code for the entire application. Any changes in the
model are automatically updated in the corresponding code without complexity. Even
though the code was generated at platform-independent level, there is a need for the
developer to produce the platform-specific code (in Java, C++, VB.NET, C#, etc.). Then
a transformation was introduced in modeling tools to generate language-dependent code
like Java, C#, apart from the platform-independent formats like XMI/XML, a standard
incorporated by OMG.
In order to reduce the gap between the model development and the application
implementation, that is producing a platform-specific model from the platform-
independent model, and to achieve interoperability among different environments, the
OMG has introduced a framework called Model Driven Architecture in 2002. Ever since,
design technology is leaning towards MDA. Some of the examples of MDA-based tools
are ArcStyler from Interactive Objects, OptimalJ from Compuware, and EMF from IBM.
42

MDA framework is a combination of UML, XMI, Common Warehouse Model
(CWM), a standard adopted in developing warehouse models, and Meta Object Facility
(MOF). The MOF is a repository-based standard of specifying metamodels, models and
transformation rules for converting the platform-independent models (PIMs) to the
platform-specific models (PSMs), and PSMs to code. But most of the times,
transformation of the PIM to the PSM is not seen explicitly.
Figure 3.12 Model Driven Architecture Framework [14]
MDA is only standards-based (UML, XMI, CWM), repository-based (MOF) and
includes model transformation patterns [14]. MDA framework is shown in Figure 3.12.
43

MDA development consists of three steps. First step of the MDA process is the
construction of PIM-expressed in UML (please note, sometimes UML models are also
platform-dependent), with constraints independent of implementation technology,
possess high level of abstraction, mostly business-oriented. Second step is automatic
transformation of PIM to PSM. This step is achieved through the usage of transformation
rules and patterns, aim at one or two implementation platforms (like EJB, web-based,
.Net), intermediate to PIM and executable code. Final step is automatic transformation of
PSM to code, which is accomplished through the usage of transformation rules and
patterns. Code generation can be in Java, SQL scripts for DBMS, VB.NET for .Net
platforms etc. In the second step, PIM and PSM are synchronized and in the third step,
both PSM and code are always synchronized. Transformations in models are shown
diagrammatically in Figure 3.13.
Figure 3.13 Transformations in MDA [14]
44

Ultimately, MDA’s greatness lies in platform-independency, interoperability, and
formal mapping rules to many platform infrastructures like J2EE, .Net, SOAP, XMI and
CORBA.
There are also some drawbacks for MDA. The entire framework of MDA (UML,
CWM, XML, MOF) is only standards-based, no proper solution for implementing the
goals of MDA (interoperability, platform-independency), much of the APIs are yet to be
developed (through which interoperability is facilitated) and one of the core ideas of
MDA, interoperability is not realized in practice, example., platform-independent models
generated by ArcStyler and EMF are not interoperable among themselves.
3.3.2 ArcStyler
ArcStyler, the tool from Interactive Objects, is a full-fledged, model-centric,
platform-independent (works on any version of windows platform), MDA-based UML
modeling tool. It supports complete development of the project from design stage to code
generation for different infrastructures like .Net, J2EE, and CORBA. ArcStyler has all
MDA-cartridges for J2EE application servers, BEA WebLogic server, EJB, CORBA,
.NET, and C#. ArcStyler fully implemented in Java enables design, modeling, code
generation, deployment for any size of applications and infrastructures. ArcStyler is
available in multiple editions. Latest version of ArcStyler is 4.0. The ArcStyler Enterprise
Edition has MDA-Cartridges for the development of four-tier applications like J2EE
application servers, .NET, C# and BEA WebLogic Server [15].
The ArcStyler Architect Edition is the high-end version of ArcStyler. It enhances
the Enterprise Edition with powerful extensibility tools enabling flexible extension,
45

customization and exchange of MDA support within a well-defined, comprehensive
Architectural IDE. With the ArcStyler Architect Edition and its MDA-Cartridge IDE, an
organization can visually develop, test, and deploy MDA support to meet its specific
requirements, whether these are extensions to existing MDA support or for completely
new types of infrastructures and architectures. Appropriately, the MDA extensibility
features of the ArcStyler also leverage the powerful benefits of MDA themselves [15].
ArcStyler Architect Edition includes three types of variant editions. Community
Architect Edition, which is available free for trial, Personal Architect Edition, and full
Architect Edition. Users can download ArcStyler Community Architect Edition for their
own specific platform from ArcStyler’s official website [15]. The related work regarding
ArcStyler in this thesis report is implemented by Community Architect Edition
Evaluation version 4.0. ArcStyler Web Edition is also available for WebServices.
3.3.3 ArcStyler Community Architect Edition 4.0
ArcStyler is way beyond a typical programming Integrated Development
Environment (IDE) which maintains architectural integrity. ArcStyler can be viewed as a
platform for standard design, development and deployment of applications through
MDA-cartridges IDE provided by Interactive Objects and its business partners.
Advantages of architecture-centric over code-centric platforms are:
Quality and effectiveness of the application can be improved because the tool
produces optimized code that can be tested with less coding. Effectiveness is
achieved as the developer feels that all requirements are precise.
46

Cost of application development and time can be reduced because most of the work is
done by the modeling tool itself, from design to code.
Reduced risk as per the model changes, because code is automatically updated, results
are predictable with designs, the skill set requirement for the design models remains
more or less constant, not requiring relearning each time.
More flexibility can be achieved in the project. The developer can include as many
requirements as possible, which ever way he wants.
Performance of the application is improved as the tool generates optimized code
automatically, and the final output is much less prone to errors.
Models can be saved as assets for the future to reuse and produce much more
complex models because they are separate from implementation platforms. Making
them interoperable will not be a major problem. Also models unlike code are less
subject to corruption, loss of data and unexpected errors.
An overview of ArcStyler is given in Figure 3.14. The MDA-cartridges which are
present in the Community Architect version are called MDA Horizontal cartridges. Some
of them are J2EE, .Net, and C#, etc. MDA-cartridges like eGovt and Telecom are called
Vertical MDA-cartridges. MDA-cartridges for COBOL, CORBA, Mainframe, and
Database are called custom cartridges. The underlying architecture of ArcStyler is
Cartridge Architecture, shortly abbreviated as CARAT. ArcStyler fully automates the
complete life cycle of the software development process, which is System Analysis,
Design, Development and Implementation-Verification, Test and Deployment as defined
by the Unified Process by default [16]. A diagrammatic view of the above point is shown
in Figure 3.15. The complete architecture of ArcStyler is given in Figure 3.16.
47

Figure 3.14 ArcStyler Overview [16]
48

Figure 3.15 Full Life Cycle support of Unified Process in ArcStyler [16]
49

Figure 3.16 ArcStyler Architecture in detail [16]
50

MDA-cartridge contains *.tpr files-Technical Projection Configuration File which
takes care of template directory, reference to contents etc, *.cap files-Technical
Capabilities File which cares about the issues like inheritance, associations, other
primitives and transaction modes etc, *.tpl-Interpreted Template File, *.inc-Include Files,
*.py-Python Script Files, and Verifier rules are written in Java/JPython. In each cartridge,
ArcStyler possess C-GEN, a configurable MDA-Transform Engine that does automation
of the model to code, also each MDA-cartridge consists of ~1700 classes with multiple
rules and ~6700 rule connections according to [17]. The system infrastructure, including
the profiles is generated automatically using the configured ArcStyler MDA-Cartridge.
Each pluggable MDA-Cartridge provides an optimized MDA transformation profile and
automated model quality verifiers. Based on the UML model, an MDA-Cartridge
generates the system, test and build infrastructure for a particular environment (e.g.
J2EE/EJB container, .NET system or Java runtime environment) [18].
Packages are created just like a UML package in ArcStyler. The user can restrict
the model elements to be ignored in the code generation process. The following are the
MDA-Cartridges that are provided by default in ArcStyler: Java2, Ejb11, Ejb20, WLS8,
CSharp, Accessors (presentation layer), WebAccessors (Web front ends) and CARAT
(CARtridge ArchiTecture Cartridge). Customized MDA-Cartridges may be generated
using the ArcStyler’s CARAT Cartridge IDE.
All types of UML diagrams are fully supported by ArcStyler. Declarative tags can
be pre-defined or user-defined and can be applied to model elements like packages,
classes, attributes, operations, interfaces etc. The Figure 3.17 is a snapshot of a sequence
diagram that shows flow of messages in ArcStyler.
51

Figure 3.17 Sequence diagram in ArcStyler [18]
Exceptions can be created by declaring a class with the stereotype «exception».
We can model exceptions thrown by the operation. To indicate that an operation may
throw a certain exception, draw a dependency with the stereotype from
the operation to the exception. The exception must be a regular exception type of the
user’s UML model. This setting will be disregarded by the CSharp MDA-Cartridge,
because the CSharp programming language does not support declaration of exceptions in
operation signatures [18]. The modeling of operation exception is shown
diagrammatically in the Figure 3.18.
52

Attributes can be manipulated or not as controlled by the property called
changeability. Getter and Setter methods are automatically generated for classes by
ArcStyler tool itself.
Figure 3.18 Modeling Operation Exceptions [18]
Operations can be declared as synchronized, native or sequential in ArcStyler.
Finite state machines can be modeled and implemented using MDA-Cartridges Java2 or
CSharp. UML extensions for finite state machines like fork, join, composite state, synch
state, junction, choice, initial, shallow history, deep history, and final states are
incorporated in ArcStyler UML State diagrams and activity diagrams. Finite state
machines are constructed basing on the four modeling elements package, class, usecase
and operation.
Dependencies are generated in the code depending upon the cartridge used. In
Java, it is with the “import” syntax, and in C#, it is with the “using” syntax. Associations
could not be seen in generated code. Web services can be developed in ArcStyler with
Java/EJB or C#/.Net MDA-Cartridges. A web service is a service which is implemented
by SOAP (Simple Object Access Protocol). For a Java implementation, the main artifacts
that are generated are a WSDL document (WebService Description Language) describing
the service, an Apache SOAP-specific deployment descriptor, a client-side wrapper class
for calling the service from a client application and a server-side wrapper class that
53

accepts the SOAP call from the client wrapper and delegates it to the real service of the
Java class or the EJB. For a .NET implementation, the generated artifacts are the Web
service directive (.asmx), a configuration file, and a client-side wrapper class for calling
the service from a client application [18]. ArcStyler provides EJB modeling with its EJB
1.0 and EJB 2.0 MDA-Cartridge. ArcStyler supports modeling of deployable components
like J2EE Enterprise Archive (EAR) files, J2EE/EJB JAR files, Java JAR files or Web
Application WAR files. The goal in modeling deployable components is to provide
implementation-independent deployment structure [18]. J2EE application development is
provided through EJB MDA-Cartridge in ArcStyler.
ArcStyler fully supports Object Constraint Language (OCL) [1], a language to
formally express constraints [18]. OCL supports three types of constraint stereotypes,
Invariants which are applied to classifiers only, holds good for all instances of it,
Preconditions and Postconditions are applied to operations only. ArcStyler Constraint
specification is shown in Figure 3.19.
54

Figure 3.19 OCL Specification in ArcStyler [18]
OCL code generation can be controlled manually by disabling OCL support
during runtime with unselecting “NO” option in enable OCL++ support parameter in
MDA-Configuration dialog. Build support is provided by ArcStyler ANT tool.
Harvesting is the technique employed in ArcStyler to import Java files and EJB files and
transform into their UML models. Some snapshots of the work environment of ArcStyler
are presented from Figure 3.20 through Figure 3.23. The Figure 3.20 shows the opening
screen of ArcStyler Community Architect Edition with default MDA-Cartridges.
55

Figure 3.20 ArcStyler 4.0 Community Architect Edition
56

Figure 3.21 ArcStyler package specification dialog box
From the Figure 3.21, it can be seen that the package specification dialog box
contains some tabs with in it. One is the General tab, which lists package name, whether
it is a root element, leaf element, or an abstract type. The Inner Elements tab contains the
list of objects in the package like classes, and packages. The Relations include
dependencies, realizations, compositions, associations, notes and generalizations etc. The
Stereotypes lists package stereotype, if it has to be created, this tab enables one to create a
57

customized stereotype. Tagged values are just to add a little more documentation to the
package. The Constraints tab is for specifying constraints in OCL. The MDA-marks tab
is for specifying some properties like not to include the package in code generation
process etc.
Figure 3.22 ArcStyler package diagram using Class diagram toolbar
58

From the Figure 3.22, archetype patterns Party, Company, and Loan Applicant,
are shown at the package level. Pleomorphs (variants) are connected by realizations to
their variation points. For example, from the Figure 3.22, Loan Applicant is a variant of
variation point Party. A Zoom bar is also seen on the left side of the diagram pane. The
Figure 3.23 shows a typical ArcStyler class diagram with relationships.
Figure 3.23 ArcStyler Class diagram
59

4. EXPERIMENTAL VERIFICATION OF THE TOOLS FOR UML VARIABILITY
This chapter discusses various tools like GME 4, Poseidon for UML and
ArcStyler in developing an archetypal model applying variabilities. It also explains the
features present in each tool. The chapter also specifies whether the tool is successful in
achieving the problem specified in this Thesis, after experimenting with the tools
practically. An archetypal model for one case study is presented and finally comparison
of three tools is tabulated for complete and clear listing of features. However, some
features which are observed as nonworking should not be applied to ArcStyler in general
because the tool versions applied in the Thesis are evaluation versions.
4.1 Case Study Introduction - Loan Origination System (LOS)
A case study was conducted in developing an archetypal domain model with
variabilities and suggesting possible approaches of automation of variants from the
variation point model. Tools involved in this case study are GME 4, Poseidon for UML
and ArcStyler. In this section, a brief explanation of the selected domain is presented.
The name of the domain to be constructed is “Loan Origination System”.
Loan Origination System (LOS) is a system involved in the business of issuing
different types of loans to the people. Different types of loans include credit-card loan,
home loan, auto loan, student loan, consumer products loan, etc. For this report, only first
60

four loans are considered. From the above, it can be understood that loan is a variation
point and all other types of loans are its variants. Our main issue is to construct a model
with variabilities using each tool and see how the tool provides automation of its variants
from the variation point model.
The Loan Origination System involves two parties, one is loan applicant, who
requests a loan, and the other is loan originator, who issues the loan. In this case, the two
parties are two persons. In some cases, a Company which is a variant of Party, can apply
for a loan. This latter case involves two parties one of which is a Company. In the first
case, it is a personal loan, and in the second case, it is a company loan. Ultimately, the
transaction will be dealt only between two persons, either of them may be a person
representing himself or representing a company. All types of these loans are special cases
of the main product, called Loans.
Loan Origination System actually is implemented by thorough communication
between the two parties. So Party Relationship plays an important role in better
understanding each other, thus facilitating smooth going of loan process. A major issue in
maintaining a good Party Relationship is only through the channel of communication.
Once the two parties agree on terms, they both sign an order making a deal. Finally the
formal procedures take place, like saving documents, underwriting, agreement signing
and the loan is sanctioned to the loan applicant from the loan originator. Product also
possesses a relationship with the Party through Party-Product (Relationship) to decide
whether the criteria are met in order to issue the Product for the loan applicant.
In the background and related work chapter, previous work done by some
researchers in the area of variability is explained. Their ideas are much restricted to
61

theory, rather than proper implementation and tool support. The researchers’ idea of
integrating feature modeling in UML is not possible for implementation.
Archetypes, known from their Greek meaning, as “general” came to explicitly
show variability in UML. A collection of archetypes form an “archetype pattern”. A
collaboration of archetype patterns forms an “archetype pattern library”. After OMG
standardized MDA, one of the tools fully supporting the implementation of variability in
UML with archetype patterns is ArcStyler. The unique feature of archetype patterns is
direct representation of variability in UML modeling.
ArcStyler is MDA-based and supports the core concepts of MDA. Poseidon for
UML is a UML-based CASE tool and domain model with archetypes can also be built
with this tool. However, because of the drawback of not allowing realizations among
packages to show variability in Poseidon according to archetype patterns theory,
ArcStyler is used in finishing the domain model. For comparison purposes, the top-level
diagram of the model is constructed using both the tools. GME 4 is not feasible to use,
because it lacks full UML Class diagram support. It is a good metamodeling tool, which
can be used for research purposes, but fails commercially. The reason is its concepts like
Model, Atom, and Aspect etc are not suitable to build the application models, which the
user is habituated to in an industry type application with classes, interfaces and
components etc. So altogether all the features of the three tools are compared, complete
archetypal model is developed with ArcStyler, and possible approaches of creating
variants is proposed as no tool provided automatic extraction of variant models.
Archetype Patterns Party, Party Relationship and Product used in this Thesis are
instantiations of the original archetype patterns Party, Party Relationship and Product [8].
62

To explain the party relationship with the product, Party-Product (Relationship), a custom
archetype pattern is introduced. Customer Relationship Management (CRM) archetype
pattern is instantiated to use in this model because loan process will be done only through
communication. The customer relationship actually shows the flow of activity between
loan applicant and loan originator. Once they come to an agreement, they sign a deal.
There comes the Order archetype pattern, which formally goes through the formal
procedure of loan process like signing a deal, making payment, talks about a purchase
receipt, placing a sales receipt from the side of loan originator, underwriting process,
verifying documents and enclosing all statements pertaining to the loan etc. Order
archetype pattern applied in this Thesis is also specialized pattern. The CRM and Order
patterns are also taken from [8]. Use-case and activity diagrams of the domain model are
also shown in this report. The XML file generated for the model is not presented because
of space constraints.
Because GME 4 is unable to build an archetype model, as it lacks complete UML
modeling support, Poseidon and ArcStyler are used. However, the Poseidon is also
restricted to top level diagram because it hangs more, and the working environment is
slower compared to ArcStyler. A complete model can be developed using ArcStyler,
unlike Poseidon, because the latter does not support variability. ArcStyler has many
features compared to Poseidon, it provides integration with major development platforms
like .NET, CORBA, Web Services, EJB, etc, Test suites can be generated; and it supports
variability in UML modeling. The tools used in this case study are GME 4, from
Vanderbilt University, Poseidon for UML Standard Edition 2.6 Evaluation version from
Gentleware Inc, and ArcStyler Community Architect Edition 4.0 Evaluation version from
63

Interactive Objects Software. Because of the version problems, some of the features
unlike full registered commercial version will not work properly.
GME 4 is experimented to see its support for UML variability and extraction of
variants from the variability model in the next section, 4.2.
4.2 Case Study Part I - Generic Modeling Environment (GME 4)
Generic Modeling Environment (GME) 4 is an extensible and easily configurable
toolkit for metamodeling purposes. Metamodel is a model that represents a model. This
product is obtained from the research of Institute for Software Integrated Systems,
Vanderbilt University.
GME 4 metamodeling is based on a modeling paradigm like MetaGME, UML
etc. Metamodeling language is based on the UML class diagram and OCL. Once the
metamodel is constructed, the paradigm is registered with the operating system registry
and can be applied for developing models using that metamodel paradigm. The users can
create their own customized paradigms in GME 4. However, UML paradigm does not
provide complete UML class diagram tool support. Only supported features are class,
inheritance, association class and composition. These tools are absolutely not sufficient to
develop a full-fledged class diagram in UML. So for this reason, GME 4 is not used in
developing archetypal model of LOS.
GME 4 possesses modular architecture built with COM interfaces written in C++.
It also supports customized interfaces written in Visual Basic, C#, Python etc. It also has
a built-in OCL manager that checks automatically constraint violation. On the whole, it is
not a commercial tool that can be used for model development. Very limited capabilities
64

are present when compared to regular UML modeling tools. No code generation concept
exists in GME 4. This tool helps for research-oriented aspects, not for the thorough
modeling of domains. Detailed description of the tool is given in section 3.1. The concise
feature listing is tabulated in Table 4.1. The comprehensive feature listing is presented in
the section A.1.
Apart from these, many fixes exist, like GME tool will not work if accidentally an
empty xml file is imported, it simply crashes. OCL manager does not check incorrect
OCL syntax specified in the model. Also the attribute dialog needs to be redesigned,
since the features are sometimes wrongly assigned in the class diagram. Copy, paste to
other applications as picture models in jpeg, gif formats is not supported, which causes
extreme inconvenience if the user wants to look at the model on any machine. Sometimes
the BON interpreter interface is not compatible with latest version of Visual C++ for use
in writing a custom interpreter for the user-owned metamodels for interpreting models
based on the metamodels. So after analyzing and experimentally verifying with GME 4, a
conclusion was formed that developing a full-fledged UML domain model is not possible
with the tool. The Thesis problem is not solved by the GME 4 tool.
4.3 Case Study Part II - Poseidon Standard Edition 2.6
Poseidon for UML is a complete tool with support to all types of UML diagrams.
There are multiple editions available for this tool from the official website of Poseidon.
The Community Edition is free for download, while Standard Edition can be obtained as
an evaluation version and can be worked with the environment for a specific period of
time. Poseidon is a professional tool UML CASE tool that includes many features such as
65

code generation, documentation generation, reverse engineering, and export models as
XMI, import XMI models, and export diagrams as .jpg, .gif, .ps, and .svg formats. The
tool version experimented in this Thesis is Standard Edition 2.6 Evaluation Version. So
the list of features described for this version may not be applicable for commercial or
professional versions of Poseidon.
Poseidon has its roots taken from ArgoUML, an open source UML design project
which is currently being developed by large open source international community, called
Tigris. Later Hamburg-based Company Gentleware produced a re-worked version of
ArgoUML called Poseidon for UML Community Edition 1.0. In the course of time, the
company introduced many features into Poseidon and developed various versions of the
same tool to suit all kinds of business users.
Poseidon is very platform-independent. It runs on major operating systems like
Windows, LINUX, and Mac-OS etc. Poseidon can also be worked online without
installing the software on the user’s machine through JavaWebStart. The summarized
feature listing of the tool is tabulated in Table 4.1. The comprehensive feature listing is
presented in the section A.2.
Poseidon tool itself has some bugs and needs to be fixed. Frequent hanging
problems, restarting the tool for simple reasons like accidental issue of an wrong
association relationship, incorrect use of rapid buttons etc, slowness in loading, saving
the model even on a relatively faster computer, hanging while inline editing, copy, cut,
paste not working within the tool environment, no auto-sizing feature for the model
elements are some noticed problems.
66

The development of the domain model of LOS with Poseidon is restricted to only
a top level diagram because in the evaluation version: the number of classes should not
exceed 20. If the user tries to exceed this, the model will not be saved. So, in this Thesis
only a top level diagram is constructed and analyzed. Unfortunately, the top level
diagram is only partially completed because the tool does not allow realizations among
packages, which is the primary technique for exhibiting variability according to the
archetype patterns concept. So UML variability applying archetype patterns could not be
achieved using Poseidon, just like GME 4. However, the incomplete top level diagram is
presented in Figure 4.1.
67

Figure 4.1 Incomplete top level diagram of LOS from Poseidon (with watermark)
68

Although complete LOS top level model with variabilities could not be constructed with
Poseidon, the contents of its generated XMI file will be discussed. Some of the main
features of the XMI file are as follows:
The XMI file possesses information about the diagram in addition to the model
information.
The only difference between the models generated with diagram data and without
diagram data is that by double clicking the XMI file, the tool will be started and
model can be seen in the model window in the former case, whereas the tool will be
started but no model is seen in the model window in the latter case.
XMI file generation even for a small diagram like Figure 4.1 is around 48 pages, with
model information, which is quite large when compared to three pages of code
without diagram information generated from the same tool for the same model.
Although a DTD file is available, to understand the contents of XMI file generated
from Poseidon, it is about 104 pages of XML to walk through, which is hard for the
user to go through the DTD file in the first hand.
The project file of Poseidon top level diagram (with .zuml extension) is 6 KB, a
backup file is with size 6 KB, the XMI file with diagram information is 126 KB and
XMI file without diagram information is 8 KB.
The XMI file can be viewed in Internet Explorer, and in any text editor like Notepad,
Word pad and Microsoft Word.
The XMI file without diagram information is very simple and easy to understand and
is very self-explanatory. So, the details of the contents are discussed shortly. First, it
contains a creation timestamp. Then, it contains information about each model
69

element, such as a unique identifier and other properties like abstract, root etc. After
describing all model elements, it includes information about relationships, like
dependencies, etc. and comments. It also assigns a unique identifier to each different
stereotype. Here only «archetype pattern» stereotype is applied. The XMI file
contains an identifier assigned to this stereotype, and this identifier is included in
every model element description in this file because all elements have the same
stereotype. The complete listing of the XMI file without diagram data for Figure 4.1
is presented in the Appendix A.9 of this Thesis.
The XMI file with diagram data contains information about the model along with
its geometry, size and miscellaneous properties. This type of XMI file would be
beneficial if we want to export to other users who have Poseidon on their systems.
Otherwise, it is not advisable to export this file. The feature of exporting XMI file with
diagram data or without diagram data is a good one, because the user can decide
according to the need. On the whole, it was concluded that Poseidon is not a suitable tool
to construct a variability model.
4.4 Case Study Part III - ArcStyler Architect Edition 4.0
ArcStyler is one of the professional modeling tools available in the industry. Out
of many editions available, the edition presented in this Thesis can be obtained as an
evaluation version from the ArcStyler website. ArcStyler is an excellent tool in
supporting UML variability through the implementation of archetype patterns. The
complete listing of the features in ArcStyler is presented in the section A.3. The concise
feature listing of the tool compared with the other two tools is presented in the Table 4.1.
70

The version of ArcStyler with which Thesis experimented is the Community Architect
Evaluation Edition. So, some of the observations mentioned here may not be true in the
full Enterprise Edition. The latest version of ArcStyler is 4.0 for all editions. Because
ArcStyler supports variability in its design, it is chosen to construct a variable model of
LOS. The table 4.1 summarizes features of the three tools briefly. The comprehensive
listings of the features of the three tools are given in the Appendices A.1, A.2 and A.3
respectively of this Thesis report.
Feature GME Poseidon for UML ArcStyler
Editions Single Multiple Multiple
Edition name GME Standard Community
Architect
Tool type Metamodeling UML CASE MDA-based
Version worked Direct Evaluation Evaluation
Version number 4.0 2.6 4.0
Integrated Platform No No Yes
Model-centric Yes Yes Yes
Tool configurability No No No
Tool extensibility Yes No No
Working style Paradigm-based Plug-in based Cartridge-based
Structural
correctness
No Yes Yes
Rapid buttons No Yes No
Code generation Not Applicable Yes Reported errors
Report generation No No Reported errors
Diagram assignment No No Yes
Code generation
during development
Not Applicable Yes No
Tool Speed Faster than the other Slower than the Relatively faster
two tools other two tools than Poseidon
Tool hanging Very rare Occurs on and off Very rare
Forward
engineering in Java
Not Applicable Yes Reported errors
Reverse engineering
in Java
Not Applicable Partially yes Reported errors
Test case generation No No Yes
Model interpretation Yes No No
Model execution No No Yes
71

Feature GME Poseidon for UML ArcStyler
Autocritiquing No Yes No
Diagram export Only emf .gif, .ps, .wmf, .svg .gif,. jpg,. wmf
Diagram export to
pdf
No Yes No
Printing Yes No No
Copy, cut, paste to
various applications
No No Yes
External plug-in
support
Yes No No
Association classes Yes Yes No
Complete UML
support
No Yes Yes
UML Variability No No Yes
Integration with
.Net
No No* Yes
Integration with
CORBA
No No* No*
Integration with
Web Services
No No No*
Integration with
BEA WebLogic
No No No*
Integration with
EJB
No No No*
Drawing tools No Yes No
Project file export XME/XML XMI XMI
Platformindependent
file
format
XML XMI XML
Unisys support No No Yes
Backup file creation Yes Yes Yes
Multiple stereotypes No Yes Yes
Tool platform- Only Windows Windows, Linux, Windows, Linux,
independency
Mac-OS Solaris, Mac-OS
Internationalization No Yes Yes
Inline text editing No Yes Yes
Zoom factor No Yes Yes
Direct saving of the
model in XML
No No Yes
OCL syntax autochecking
Yes No Yes
Import feature Own XME/XML Own XMI Own XML ZIP
Directed
Association
Yes Yes No
72

Feature GME Poseidon for UML ArcStyler
Tool size 55 MB 43 MB 342 MB
Self-associations Yes Yes No
Search mechanism Yes Yes Yes
DTD availability No Yes No
Auto-save feature Yes No No
Metamodel-tomodel
transformation
Yes No No
Auto-sizing No No Yes
Documentation No Yes (Comments) Yes (notes)
Model-to-model
No Yes (if code is also No*
transformation
thought as a model)
Diagram
interchange
standard 2.0
No Yes No
XML file has
diagram data
Yes Optional Yes
HTML
Documentation
No Yes No
Tool MS-COM interfaces Java Java
implementation written in C++
Source code editing Not Applicable No* No
Diagram code Not Applicable Class diagram with Same as Poseidon
generation
classes, classifier, and commercial
packages, and version supports
relationships in the activity diagram
class diagram code generation
Tool placement Research-oriented Commercial Commercial
Cost effectiveness Free Expensive Very Expensive
No* - This feature might be fully supported in the commercial version of the tool
Table 4.1 Feature list comparison of GME 4, Poseidon for UML, and ArcStyler
73

4.5 Case Study Part IV - Archetypal Model of LOS in ArcStyler
The first part of the Thesis is to construct a domain model in UML with
variabilities. The other two tools GME 4 and Poseidon did not provide complete support
to achieve this task. ArcStyler enables the users to build variable models through the
concept of archetype patterns. The definition of archetypal model is: A generic model
from which every model of the similar kind is derived. An archetype pattern is a
combination of archetypes, which are optional by default with in the archetype pattern
context. An interesting feature of archetype patterns is they explicitly exhibit variability.
So, an ArcStyler UML variable model with existing archetype patterns customized for
the current domain of Loan Origination System (LOS) is implemented.
LOS contains two parties, Loan Applicant and Loan Originator. Sometimes a
Company can also play the role of a Party, instead of Loan Applicant, that is a Person. So
variation is shown for the parties. Also, there can be different types of loan transactions
that take place between the two parties. This shows a variation also exists for the loan. In
this case, the primary focus is on Loan Applicant and Loan Originator. The relationship
between Loan Applicant and Loan originator is explained by the Party Relationship
Archetype Pattern. The party relationship with the Product, Loans, is described by a
Party-Product (Relationship) Archetype Pattern, which has a pattern structure similar to
Party Relationship. How the loan process flows, and the actions and outcomes of the two
parties are explained by the Customer Relationship Archetype, and Order Archetype
Patterns. Finally, the Product:Loans Archetype Pattern with its variations are depicted.
74

All existing archetype patterns given in [8] are instantiated through parameterized
collaborations to use in the domain model of LOS.
Initially, the main domain model of the LOS application is created using standard
requirements engineering practices. Use-cases are constructed, Figure 4.2, and Figure 4.3.
Then behavioral diagrams, such as activity diagram are depicted in Figure 4.4. Next the
high-level object models, such as package diagram is constructed in Figure 4.5. Then the
details of the system model with variabilities are fleshed out, employing standard
archetype patterns where possible. For example, the top level diagram of the domain with
variabilities is built using the archetype patterns, Party (with its pleomorphs, Loan
Applicant, Loan originator and Company), Party Relationship, Party-Product
(Relationship), and finally Product:Loans (with its pleomorphs Credit card-Auto Loan,
Student Loan, Home Loan etc.). The top level diagram is shown in the Figure 4.6. The
next stage of development is the detail level of design for each archetype pattern shown
in the top level diagram from Figure 4.7 to Figure 4.17. The final models Figure 4.16 and
Figure 4.17 are the collaboration models of the customized archetype patterns. The
domain model development begins from Figure 4.2 and lasts through 4.17.
75

Figure 4.2 Use-case Diagram of Loan Applicant
76
76

Figure 4.3 Use-case Diagram of Loan Originator
77
77

Figure 4.4 Activity Diagram of Loan Origination System
78

Figure 4.5 Main package of Loan Origination System (LOS) from ArcStyler
79

Figure 4.6 Top-level diagram of Loan Origination System
80

Figure 4.7 Party, Loan Applicant, Loan originator and Company Archetype Patterns
81

Figure 4.8 Party Relationship Archetype Pattern
82

Figure 4.9 Party Relationship-Product Relationship Archetype Pattern
83

Figure 4.10 Product Archetype Pattern
84

Figure 4.11 Product:Loans and its Pleomorphs Archetype Patterns
85

Figure 4.12 Order Archetype Pattern of LOS
86

Figure 4.13 Customer Relationship Management (CRM) Archetype Pattern of LOS
87

Figure 4.14 CRM Archetype Pattern for a specific case of Auto Loan
88

Figure 4.15 CRM Archetype Pattern for a specific case of Credit card Loan 89

Figure 4.16 Instantiation of Archetype Patterns through parameterized collaboration
90

Figure 4.17 Instantiation of Archetype Patterns through parameterized collaboration
91

The Figure 4.2 and Figure 4.3 show the use-case diagrams of the two parties of
the loan origination system according to the requirements. Loan Applicant requirements
are submitting loan application, providing asset and liability statements correctly, paying
fees to the originator for credit checking, attorney fees, monthly payment with interest
etc. Loan Originator requirements are to verify loan applicant application, do credit
checking on the applicant, verify documents produced by the applicant, informing about
payments etc. The Figure 4.4 depicts the entire loan process of the domain through
activity diagram. The activity diagrams show the flow of activity from the stage of
application submission to final loan issue process briefly. The Figure 4.5 shows the main
package of loan origination system with its sub-packages. So, the stereotype of the
package is named as archetype pattern library. The «archetype pattern library» is a
collaboration of archetype patterns, and they will appear as packages inside the library.
The inner packages are declared with the stereotype «archetype pattern». Some of the
inner packages are Party, Party Relationship, Product and Loan Applicant, etc.
Figure 4.6 is the domain model of LOS shown at the very abstract level. That is
the reason, the diagram is named as the top level diagram. Variation is expressed through
«pleomorph» stereotype. From the Figure 4.6, it is clear that Product:Loans is a variation
point and its variants are Credit card-Auto Loan, Auto Loan, Home Loan, etc. Also,
another variation exists at Party, with Loan Applicant, Loan Originator and Company as
its pleomorphs. The connection between a variation point and its variant is described by a
UML realization relationship with the stereotype «pleomorph». Variability is expressed
at the package level with archetypes.
92

Figure 4.7 reflects the Party, Loan Applicant, Loan Originator and Company
archetype patterns. The Party archetype pattern is instantiated and combined with the
Loan Applicant archetype to form a Loan Applicant archetype pattern. Similarly, Loan
Originator instantiates Party pattern and includes Loan Originator archetype to form a
Loan Originator archetype pattern. In the same way, Company instantiates Party pattern
and includes Company archetype to form Company archetype pattern. If the user wants to
use an existing archetype pattern in his domain model, he has to instantiate the archetype
pattern. The instantiation of archetype patterns is allowed through the process of
parameterized collaborations. So, the archetype pattern with its archetypes is enclosed in
a dotted oval, a collaboration icon and the archetypes enclosed in the archetype pattern
are specified as parameters on the collaboration circle. That means, the archetype pattern
can be used again in the user’s new archetype pattern. The user can add more archetypes
and more features to the instantiated archetypes in the new pattern, which is derived from
the existing pattern. In this way, the users can instantiate existing archetype patterns to
use them for their own domains.
Figure 4.8 describes the Party Relationship archetype pattern of LOS. The pattern
explains the party relationship between the two parties, loan applicant and loan originator
with the relationship type, party role, constraints, responsibility archetypes. The domain
developer supplies the two responsibility archetypes, the method definition that describes
the nature of the roles of the two parties. Figure 4.9 is the description of Party-Product
(Relationship) archetype pattern, which explains the relationship between the two parties
and a product, a loan in this case. This archetype pattern is quite similar to the Figure 4.8
in structure.
93

Figure 4.10 is the Product Archetype Pattern from which a Product:Loans
archetype pattern is derived with its related archetypes. Because of the space constraints,
its pleomorph patterns, Credit card loan, Auto loan, etc. are constructed and shown in a
separate diagram as Figure 4.11.
Figure 4.12 Order Archetype Pattern depicts types of business process flow that
take place after the deal is signed between the loan applicant and loan originator. This
pattern exists in the Customer Relationship Management (CRM) Archetype Pattern as a
sub-pattern. The Order pattern has many events that take place according to the situation
and need. Different types of activities that occur in the loan process are pictured as events
like Payment, Cancel, Open, Close events, etc. The next model shows how the actual
process of communication, party actions and outcomes in the form of a CRM Pattern in
Figure 4.13. This pattern is essential in the model of LOS because loan process works
efficiently through the channel of communication, which means a good customer
relationship should exist. Figure 4.14 and Figure 4.15 are the special cases of CRM
pattern for the special cases of Product:Loans, like Credit card loan and Auto Loan,
which are presented for the sake of describing variants of the main CRM pattern of
Figure 4.13. Figure 4.16 and Figure 4.17 are the instantiations of the original archetype
patterns given in [8] modified to suit the domain model of LOS. The patterns are all
placed in collaboration circles with the necessary archetypes mentioned as parameters for
the other archetype patterns to use them in their pattern along with their own archetypes.
Once the model is constructed, as a next step the tool generates an XML file,
which is platform-independent. For the LOS example, the project file with .asprj
extension is of 11 KB, the XML file and its backup file created with .bak extension are
94

each 1.12 MB, the compressed UML model with the extension .xml.zip is 60 KB, the
.xml.zip.bak is of 63 KB, the Unisys XMI file is of 1.88 MB, the .guifg (GUI
configuration file) is of 20 KB. Because of the version, the project file could not include
the CRM archetype pattern, Order archetype pattern, CRM-cases, Use-case diagrams and
Activity diagram. They are obtained from separate uses of ArcStyler. The XML file
generated for the project is exactly 600 pages of code, or more if opened in any text
editor. Hence it is clear that parsing through the XML file is not feasible. So, to analyze
the XML file generated by ArcStyler, only the top level diagram of the same domain was
constructed as another model. The project file (.asprj) came to be 20 KB, the .guifg is 20
KB, and the UML model .xml.zip is 6 KB, .xml.zip.bak is 6 KB, XML version is 183
KB, Unisys XMI file is 1.12 MB. The XML file for this model is around 96 pages of
code if opened in any text editor. So, it is still hard to walk through to understand the
contents of the file.
given below:
Some of the main points noted about the XML file generated by ArcStyler are
The file is with an XML extension filled with XMI tags.
The tool uses, built-in Magic Draw UML 7.0 facility to export in XML and XMI
formats. It uses Magic Draw UML 7.0 tool XMI extensions in XML file.
A unique identifier is assigned to each model object, such as package, class,
relationship, stereotype and interface.
It contains profile loaded information, and expresses many properties of the model
elements, many of which are not useful to the user in understanding the model.
95

The XML file also possesses information about the diagram in addition to the model.
Unfortunately, double clicking on the XML file, will not open ArcStyler.
It describes information about the author, comments, created date and title of the
project etc.
It contains stereotypes; data types, extension mechanisms, like from which base class
its features are extended, MDA profile ID, and element ownership.
Even though the user does not set the feature property, it displays the feature property
as false for that feature in the XML file for every attribute, package, stereotype,
dependency, and class, etc. That contributes to the unimaginably large XML
documentation, even for very small models.
The first part of the file is about model management, like profiles, extension
mechanisms, and assigning identifiers to each item in the model.
The second part tells us about the diagrammatic information, like what font and fill
color is used for the objects, the reference id attached to that property, geometry
coordinates at which these model elements are placed, and properties of the class
objects, which are owned and set by the author.
The last section is about optional features that are related to model elements (which
are set and which are not set).
So, to express the analysis of the XML file briefly, the user usually don’t need that
extensive information in the first part, (it just gives an abstract information about the
model view, its geometry, size, fill color properties, etc), the second part tells about
the model elements in the diagrams, their stereotype, root, abstract, model element
96

identifier, relationships involved with each model element, and any notes attached to
the model elements. The third part or the last section is not required.
The XML file of ArcStyler even for the top level diagram is not included in the
Appendix of this report because of space problems. Also, code generation and report
generation facility in ArcStyler are not successful because of the restricted version.
The first part of constructing a model with UML variability is achieved by
ArcStyler, which could not be done by either GME 4 or Poseidon. So, first part of the
Thesis problem is solved. The next part is automating the creation of variants from the
UML variability model. So far, none of the tools possess tool support for creating variant
models with the help of a variation point model. So, feasible approaches are proposed in
the next section 5.1.
97

5. FEASIBLE APPROACHES OF AUTOMATING VARIANTS
If there is variability in the domain model, the user should possess the ability to
choose variant models according to his need and requirements. Since so far, no tool
experimented with in this study provided support for the automatic extraction of variants,
possible approaches are suggested in this section to accomplish the task. This is the
second part of the Thesis problem.
5.1 Algorithm Approach
This approach suggests an algorithm to parse through the XMI/XML file of the
variability model by preparing a requirements set document initially. The user is
supposed to walk through the file according to the algorithm, and wherever requirements
are met, move the block of XML code from the parsing XML file into a separate XML
file that eventually becomes a variant model in XML format. However, the approach
makes some assumptions, like the XMI/XML file generated for the variability model is
not excessively large, (less than 10 pages of code), does not contain diagram data, and
does not possess optional features and properties that are set to false by the tool and
properties that do not provide important information about the model to the user.
Although, in this case variant models are not automatically created, they are
developed with partial automation. The main issue to be understood in this case, is that
98

the user is trying to create a model that meets the requirements from the available
metamodel with variabilities. The models for which variability is expressed at the
package level are only considered, because the concept of variability implemented in this
Thesis is through archetype patterns. Initially, the required archetype patterns from the
metamodel which are selected by the user in order to extract a model variant are framed
into a set called the requirements set. The requirements set is prepared from the graphical
representation of the metamodel showing the variabilities. The reason is parsing through
the XMI/XML file of the metamodel costs time and unnecessary confusion to the user to
frame the requirements set. So, at the beginning the set is prepared by selecting package
nodes from the variability model image. Secondly, the algorithm will be applied in
creating the variant models out of it by using the XMI/XML file of the variability model
as the input and requirements set as the parameters to build the model. Before the
algorithm is presented, here are certain assumptions the algorithm makes.
Each model package that is to be placed in the variant model is treated as a
NodeString object.
The package names from the requirements set are taken to construct a NodeString
array.
The requirement set has followed a preorder traversal pattern for framing the
requirements from the graphical representation of the original model with
variabilities. The NodeString array is constructed with the proper ordering of the
NodeStrings taken from the above set.
Now, repeat the procedure explained in this paragraph for all the blocks of code in the
parsing XML file. Consider the first NodeString from the array and see if the first
99

lock of code in the XML file matches, if it doesn’t, ignore the block of code ignored
and proceed to the next block of code in the XML file. But if does match and there
are no inner blocks, move the block of code from the parsing XML file into the new
XML file, and proceed with the second NodeString taking from the requirements set,
incrementing the counter of the NodeString array. If the block of code matches and
has any inner blocks, increment the counter of the NodeString array to check if the
inner block matches with the current NodeString. If the NodeString matches with the
inner block of code, move the block of code into the new XML file; otherwise delete
that inner block of code from the parsing XML file and repeat the procedure for all
inner blocks of the same level. Now move the outer block of code without losing its
structural and semantic integrity. In this way, parse the XML file for all the
NodeStrings in the requirements set. The user should take care in preparing the
requirements set; otherwise it will lead to loss of data from the original XML file, and
he will not be getting the model correctly that he wanted from the variability model.
The algorithm also follows preorder traversal, which is one of the reasons to prepare
the variant model requirements set in the preorder traversal pattern. The reason for
choosing the preorder traversal for building the requirements set of the variant model
and parsing the XML file in the same way is that the XML/XMI file structure
generated by typical UML modeling tools will be similar to preorder traversal pattern.
Copy the original XML file of the variability model into a temporary file. Move the
data from this file into the new XML file while applying the algorithm, so that the
original file will not incur any loss of data because of this transfer mechanism.
100

The block of code nesting level in the parsing XML file is not considered to be more
than two to avoid complexity in the algorithm.
The formal algorithm is described in two procedures for better clarity. In the
algorithm, variable k acts as a counter for tracking the current NodeString array
element. Variable keys contain the number of elements in NodeString array.
Algorithm-part I:
---------------------
Algorithm develop-model ()
// Here the node string array is constructed from the requirements set
NodeString req-nodes [] = new NodeString [1...n]
// req-nodes[1] = req1, req-nodes[2] = req2…..req-nodes[n] = reqn
// Each NodeString is the package element taken from the image of the metamodel
Int keys = n, k = 1 // k =1 is the current requirement
File newXMLfile = new File []
// newXMLfile is the new file of the model variant to be developed
File tempfile // tempfile is the parsing XML file
Open file (newXMLfile)
Open file (tempfile) // tempfile is the temporary file of the original version
While (k

Close (newXMLfile)
Displayfile (newXMLfile)
// newXMLfile consists of the blocks of code for the NodeString array elements
// and it represents a variant model of the original XML file model.
Algorithm develop-model End
Algorithm-part II:
---------------------
Algorithm Process-model (NodeString req-nodes[k], k)
For each block of code, i in the tempfile
102
If the i block of code with name req-nodes[k] matches req-nodes[k] but contains
no inner blocks
Move the i block of code from the tempfile into the newXMLfile
k= k + 1
Process-model (req-nodes[k], k)
Elseif the i block of code with name req-nodes[k] matches req-nodes[k] and if
there are inner blocks of i
For each inner block of code, w of i
If (req-nodes[k+1] matches w)
Move the block of code w of i from the tempfile into
the newXMLfile and let k = k+ 1
Else delete the block of code w of i from the tempfile
End if

End For
End for
Move the rest of the i block of code from the tempfile without losing
structural and semantic integrity of i into the newXMLfile
Process-model (req-nodes[k], k)
Else Do Nothing
End if
Algorithm Process-model End
103
Limitations of the Algorithm:
-----------------------------------
This algorithm may be applied for the UML variability models expressed in terms of
packages.
This algorithm can be used if the corresponding XMI/XML file does not possess any
diagrammatic data and the file is not too long to process.
This algorithm can be used where the XML file does not contain nesting level more
than two. This feature is set to avoid complexity in the algorithm.
5.2 Application Model for Developing Variant Models
A customized application model was built using ASP.Net, VB.Net and Internet
Information Server (IIS). In this approach, the model with variabilities is expressed in the
form of built-in drop-down list boxes. All packages, classes and relationships for a
typical archetype pattern are described in each list box. The application model shows
only four list boxes for simplicity. The user can extend this model to suit his or her own

equirements. Each list box component possesses six text boxes that display the items
selected from the list box. Variants are declared by the package name pleomorph. The
user can follow his or her own naming conventions. As this is a basic diagram to show
generation of variants, no specific measures were taken in naming model objects.
104
The user interface is very simple in look and feel. Three push buttons are placed
at the end of the model, for “Page Reload”, “Clear” and “Generate XML file”. The “Page
Reload” button has the purpose of loading explicitly needed items into the model. The
user can modify this feature in the source code of the interface to declare some
mandatory items and see that they appear automatically when the user presses this button.
The Clear button refreshes the screen with empty textboxes and with the first item in the
list box selected. The button, Generate XML file, generates an XML file out of the user
specified requirements displayed in the text boxes.
After every list box, there are push buttons, called SELECT and
INFORMATION. The SELECT push button helps the user in selecting the items in the
list box and displaying them in the text boxes. The INFORMATION push button helps
the user to know what exactly the model element does and its importance in the text box
placed beside it. The user’s own customized documentation can appear in the text box if
the user modifies the code by writing his own documentation for each selected list box
item of the INFORMATION button. Holding the CTRL key on the keyboard, the user
can select multiple list box items and clicking on the SELECT button, the selected items
in the list box are placed in the corresponding text boxes. The users are not allowed to
enter their own text into the text boxes. This feature is restricted so that the application
model stays consistent in all situations. For this application, most generic naming set

packagename, classname, relationshipname and pleomorph are used. The pleomorph is a
variant of the packagename. This application is very simple, cannot be applied for large
and complex models, and for simplicity everything is made optional in this archetypal
model.
105
The visual interface was built using ASP.Net and code generation application for
XML was written in VB.Net. The application model interface with the model elements is
treated as the metamodel with variabilities and automatic selection of variants from the
metamodel is facilitated. The number of items in the list boxes and text boxes is restricted
to avoid complexity. Each list box reflects the elements of the model at package level.
The number of list boxes is also limited to avoid complexity and space problems in the
interface. Each list box possess a package name as the first item, with its typical
contained elements such as classes, package pleomorphs are placed after the class names
in the list box and the relationships among packages are included at the end of the list.
The user has the flexibility to extend the code and customize it. This application helps the
user in case of no tool support on his or her machine to generate a simple XML file with
understandable model information without diagram data and confusing tags. The XML
file generated from this application can be viewed in any browser just like any normal
XML file. This application model is also helpful in developing simple variants from the
variability model interface with much ease. The following example is a generalized,
(applicable to all kinds of simple domains) and customizable (the user can modify and
extend the application source code) version of the application.
The Figure 5.1 shows the main page of the application model. Only three items in
each list box are selected to be displayed. The picture also shows PAGE RELOAD,

Generate XML File, and CLEAR push buttons at the end. In this application, PAGE
RELOAD button displays all items of each list box in the appropriate textboxes by
default. The user can customize the functionality of the push buttons accordingly.
106
The Figure 5.2 shows the result of pressing the CLEAR button. The package
name is selected by default. The Figure 5.3 shows the result of pressing the PAGE
RELOAD button. It displays all the list boxes items in the available text boxes. Figure
5.4 depicts the result of pressing the INFORMATION button. When the user selects an
item in the list box and presses INFORMATION button, documentation of the selected
item will be displayed in the text box placed after the INFORMATION button. The
application model is built in the context of archetype patterns. That way, the user can
build a variety of models from the same application. This is the most generalized form,
but the user can customize the application to obtain specific variant models of the domain
model by modifying the existing source code of the interface.
The Figure 5.5 shows the error message obtained when third package elements
are selected without second package elements. If the user does not select the previous
package elements and proceeds to the next one, an error message is displayed for the
user. The error message will not go off until he selects some elements in the previous
package. This picture is to show that error handling is included in the model. The user
can modify the code and include his own error processing code in the application.
Some special cases or the variant models of the application are shown as images
from Figure 5.6 through Figure 5.8. The user can select different choices of elements
from the packages, each time leading to a different model variant from the application.
Variability is shown with the element name pleomorph. The pleomorphs are the variation

forms of the respective package placed in the same list box. The user can construct the
specific domain model according to this concept. Relationships included are the various
connections between packages, and are all optional by default. A relationship can be any
type, so the user can place relationships depending on need. The complete source code of
the application interface and the code written for the Generate XML File push button to
obtain XML file from the model are given in the sections A.4 and A.5. Also the XML file
generated for each variant model shown in Figures 5.6 to 5.8 is also saved in the
Appendices A.6 to A.8.
107

Figure 5.1 Custom Application Model for Developing Variants
108

Figure 5.2 Action of the CLEAR push button
109

Figure 5.3 PAGE RELOAD push button action
110

Figure 5.4 INFORMATION button action
111

Figure 5.5 Error Message display in the model
112

Figure 5.6 A variant model-1 of the application
113

Figure 5.7 A variant model-2 of the application
114

Figure 5.8 A variant model-3 of the application
115

6. CONCLUSIONS AND FUTURE WORK
116
The current Thesis explores different tools to pursue the problem of expressing
variability using UML models and automating the creation of model variants out of the
variation point model. Three tools were experimented with, and so far, no tool was
successful in achieving the task of automatic generation of model variants, although
variability models could be constructed by ArcStyler. So, feasible approaches are
presented in the chapter 5 for creating variants through different techniques. Each of the
approaches has its own advantages and disadvantages. The solution of the first problem
of the Thesis is partially accomplished through the implementation of archetype patterns
in this report.
6.1 Conclusions
The conclusions that are drawn from the experimental results presented from the chapter
4 are as follows:
GME 4 does not provide complete UML modeling support.
GME 4 and Poseidon are not feasible in fulfilling the task of developing variable
models because they lack UML support for the concept of pleomorphism.
ArcStyler, an MDA-based tool, provides support for UML modeling with variability
through archetype patterns.

None of the tools experimented with were useful in creating model variants from the
main model with variability.
Some of the features of the tools are not fully functional in the free versions.
The possible approaches suggested for automatically generating model variants are
very much restricted, and are not feasible for reasonably large-sized domain
modeling.
The contributions to this Thesis are:
Experimental verification of tool features in developing a UML variability model.
Complete listing of the features of tools provides adequate information for selecting
the tool for later projects.
Design of a complete archetypal model with UML variability for a specific domain
called the Loan Origination System (LOS).
Any further extensions of the LOS domain can be done easily with ArcStyler, such as
including additional pleomorphs for the Product, Loans in this case, additional
archetype features in the packages, etc.
Checked whether any Document Type Definition File (DTD) file is available for any
of these tools to understand XMI/XML models and parse through them.
Possible approaches for selecting model variants are proposed because no tool
support exists for this feature yet.
The proposed approaches could be useful in some areas where no tool support exists.
With little manual intervention, model variants could be obtained by parsing through
the XML file of the model with the algorithmic approach.
117

6.2. Future Work
118
Possible future work includes extending the extraction of variants from their
variation point models automatically. The developed customized application model
discussed in section 5.2 could be extended with more functionality, such as describing
optional elements and optional relationships explicitly, and including specification of
constraints and notes. Manual approaches are always limited to some extent, so with the
help of tool support, much more complex variant models can be built. So a tool extension
facility for ArcStyler is presented in this section.
In the current Thesis, it is found that, so far, no tool supports automatic extraction
of variant models from a domain model with variation points. However, ArcStyler does
provide variability support. So, in the future, if ArcStyler is to possess the feature of
extracting variants from the variability model, there are two possible ways of
implementing it.
Directly from the project file (.asprj file): The project file with package diagrams
showing variabilities is loaded into the tool. There will need to be a plug-in that
supports the specification of requirements that must be present in the variant model
by selecting them from the generic model. The user then selects appropriate
components and closes the plug-in interface. Then another package diagram with the
user-specified requirements would be created as a separate model diagram and a
XML file for that variant model should be generated.
Import of UML models (.xml.zip file): ArcStyler supports saving created UML
models in .xml.zip file format. It contains the UML model in the form of an XML
compressed file. The tool supports importing .xml.zip files developed from other

versions of ArcStyler in addition to its current version. So, once the file is imported
into the tool, the model can be seen in the diagram window. From there, the above
described procedure of a plug-in to develop variants can be applied here.
119
The above suggested approaches are not planned to be implemented in the tool;
however they can be taken as a possible measure for automatic selection of variants in
ArcStyler.
In conclusion, the present Thesis identifies the need for expressing UML
variability by developing an archetypal model with variabilities, suggests which tools
provide support in achieving the task, and studies the automation of model variants from
the tools. Because no tool, so far, facilitates automatic variant generation from the main
model, approaches are proposed that can be applied feasibly to smaller domains with
restrictions. Finally the Thesis concludes that automatic extraction of variants from the
variability model is also equally important as producing an archetype model with
variabilities in the current environment of business modeling.

• Editions
A.1. GME 4 Features
Available edition is GME 4 version 4.0
• GME 4 does not support UML 2.0 Diagram Interchange standard.
Diagram Interchange Standard detail is given in the A.2 section.
• No rapid buttons in GME 4 to speed up development like in Poseidon.
Rapid buttons are short-hand buttons in Poseidon that appear around an
object like class, interface, package when the option is turned on. Rapid
buttons are different types of tools with relationships like generalization,
120
association, dependency, comment, creating a class etc. There are no rapid
buttons in GME 4.
• Not an integrated platform, but model-centric with configurable paradigms.
GME 4 does not provide integration with development platforms like
.NET, CORBA, Visual Studio, Rational Rose etc directly. It is
metamodel-centric rather than model-centric. Existing paradigms
cannot be modified. GME 4 supports tool configurability.
• No usage of multiple platform-specific model paradigms at a time for developing
various applications.
• Constraints specified in OCL can be checked with check command.
Check command option in the File menu of GME 4 enables users to verify
their OCL constraints for the constrained object, Check All command
checks constraints issued for all the model objects.

• No assignment of class diagrams or any other diagrams to packages.
In ArcStyler, we can assign one diagram to package. Double clicking on
that package will directly lead to assigned diagram. This option is absent
in GME 4.
• Generates no code during development of the model.
There is no concept of code generation with this tool.
• Working with the environment is relatively fast compared to other two tools.
Because the features are limited in GME 4 unlike ArcStyler and Poseidon.
• Loading, saving takes less time than the other two tools, and it hangs much less.
• No documentation can be generated in this tool.
• No concept of forward engineering, since there is no concept of code generation.
• No test-cases can be generated for the model created in GME 4, unlike ArcStyler.
• Created models are interpreted.
121
The metamodels and models are interpreted through interpreters present in
the Builder Object Network module, a high-level C++ interpreter
interface.
• Copy, cut, paste work within tool, but not between applications.
Copy, cut, paste commands are fine within the tool environment, but
cannot be extended to other applications like Microsoft Word, Photo
Editor Etc.
• Diagrams can be exported only as emf format. (Enhanced metafile).
• Printing is supported directly from the tool.

• External plug-ins (GMEclipse, Autolayout, Generative Modeling Framework,
122
MOF environment) and other utilities are free and can be installed in this version
from [8].
• Association classes between two atoms can be created using connector
relationship.
• General drawing tools like textbox, circle, polygon, and rectangle are not present.
• The XML file contains diagram information along with model; double clicking
will not open GME 4, but the XML file can be viewed in the browser.
• Project files are saved with .mga extension; double clicking will open GME 4.
• Project files can be exported as .XME, .XML (XML version 1.x).
• A backup file with .bak extension is created for every project.
• Undo and redo action works.
• Multiple stereotypes cannot be applied to elements.
• Fully implemented with COM interfaces written in C++, platform dependent.
• GME 4 works only on Windows platforms, no version exists for others.
• Internationalization (only English)-no other language support exists.
• Inline text editing is not possible in GME 4.
Double clicking on the name of the operation, class, attribute will allow
the user to rename it. This is called inline text editing, which is not present
in GME 4.
• The Help menu worked in GME 4, offline tool support is available.
• A Zoom feature to see the model more clearly is not available.

• No ANT tool support included in GME 4.
ANT is a Java-based build tool extended with Java classes, used to
compile, assemble and run Java-based applications. Since it is written in
Java, it can be applied cross-platform. Since code generation is not
possible in GME 4, ANT concept cannot be applied here.
• No direct saving of project file to XML format.
• Constraints are specified only in OCL, and GME 4 checks OCL syntax.
• Import feature works only for its own .XML, .XME files.
• No support for importing XML/XMI files generated by other tools.
• Directed association can be drawn in GME 4 using connectors.
The user can make the connector relationship directed by giving
appropriate source and destination model objects.
• The GME 4 tool size is around 55MB, more than Poseidon and less than
ArcStyler.
• When mouse is moved over an object, no documentation is visible for that object.
If we add any documentation to any object in Poseidon, it will appear
when mouse is moved over the object. This feature is absent in GME 4.
• Associations, self-associations can be drawn with connectors.
• No dependencies, realizations, interfaces can be drawn, except inheritance and
compositions.
• No other UML diagrams can be drawn except class diagrams in GME 4.
• The Search mechanism in GME 4 allows searching for an object in the model.
123

• No DTD file available to parse through the XML file created by GME 4.
A Document Type Definition File to understand the contents of XML file
is not available.
• Auto save feature is available for GME 4.
• Metamodel-to-model transformation is possible in GME 4.
Once the metamodel is constructed and registered by a new paradigm
name in the registry, it can be used to build models basing on that
paradigm. So metamodel paradigm is used to transform a metamodel to a
model.
• Auto sizing of the model elements is not present in GME 4.
• Annotations can be added for the model element in GME 4 by clicking on a
empty area in the model browser.
• Reverse engineering concept cannot be applied to GME 4.
• Interfaces cannot be constructed in GME 4.
• No Autocritiquing or suggesting model improvements feature exists in GME 4.
• GME 4 is model-centric but not UML CASE specific.
GME 4 targets at developing the model and generating a platform-
independent file, but does not support all UML diagrams, although there
exists UML paradigm which contains very few icons for the UML Class
diagram.
• GME 4 tool working architectural style is Paradigm-based.
124

In GME 4, every project starts with applying an existing paradigm or
creating a new paradigm and registering in the registry to apply for later
projects. Examples of existing paradigms are MetaGME, and UML.
• No structural correctness feature for the model is provided in GME 4.
125

• Editions
A.2. Poseidon for UML Features
Available editions are Community Edition, Standard Edition, Professional
Edition, Enterprise Edition, Embedded Edition, and Embedded Enterprise
Edition. All these editions are available for version 2.6.
• Poseidon for UML supports UML 2.0 Diagram Interchange standard.
Diagram Interchange Standard, an adopted standard [17] suggests that the
XMI/XML file generated by the UML modeling tool should also store
diagram information. Poseidon supports this standard, so double clicking
on the XMI file of Poseidon will open the model in Poseidon; also XMI
file is browser-viewable.
• Rapid buttons in Poseidon for UML exists to speed up development.
A rapid buttons explanation is given the A.1 section. The picture of
rapid buttons is shown in the Figure 3.9.
• Not an integrated platform, with configurable plug-ins (atleast this version).
126
Standard Evaluation Edition of Poseidon does not provide integration with
development platforms like .NET, CORBA, Visual Studio, Rational Rose
etc. It is not possible to install plug-ins or write user-defined plug-ins.
• No usage of multiple profiles at a time for developing various applications.
(model-to-model transformations) in this version.
In Standard Edition, there won’t exist other profiles except for Java.
• Structural correctness is checked with Autocritiquing.

Built-in auditor, called critique which critiques design issues, provides
127
suggestions to improve design. Autocritiquing is not selected by default; it
tells the user how to improve the model, errors that might lead to
uncompiled source code. The user can make that feature turned off, by
unchecking the checkbox “perform automatic critiquing”. Autocritiquing
provides enough support to make the model structurally and
semantically correct. Autocritiquing is shown in the Figure 3.10.
• No assignment of class diagrams or any other diagrams to package.
• Generates Java code during development of the model.
The source code generated can be seen in the Source Code tab which is
present below the diagram pane.
• Working with the environment is relatively very slow compared to ArcStyler.
The user can feel slowness working with the model development in
Poseidon. Sometimes, rapid buttons are the source of confusion. Even if
the user switches off rapid buttons, faster design could not be achieved.
The reasons can be attributed to bugs in the tool development itself, like
text editing makes the tool hang or needs restarting. Hanging problem is a
bit frequent in Poseidon.
• Loading, saving takes more time compared to ArcStyler.
On a computer with relatively high specifications, the tool takes some
what less time; otherwise sometimes the user needs to restart the machine.
• HTML documentation is available in this tool.

UMLdoc, a built-in HTML documentation generator produces a report
version of the model that can be viewed in any browser. Poseidon
generates extensive documentation with the diagram along with the
relations and stereotypes.
• Forward engineering exists in all versions of Poseidon.
Generation of source code in Java is available in this version.
• No test suites can be created for the model in Poseidon, Unlike ArcStyler.
• Created models can be neither interpreted nor executed but critiqued.
• Copy, cut, paste did not work within the tool, which is a disappointing feature.
• Diagrams can be exported as .jpg, .gif, .ps, .svg, and .pdf formats.
• Printing is not supported in this version of Poseidon.
• Association classes can be created in Poseidon using UML association class
toolbar.
• General drawing tools like textbox, circle, polygon, and rectangle are present in
Poseidon.
• Project files are saved with .zuml extension; they are zip files containing a .proj
file with project information, .xmi file with the model and layout information.
• Project files cannot be exported as Unisys XMI format.
• A backup file with .bak extension is created for every project.
• Undo and redo action works.
• Multiple stereotypes can be applied to elements.
Also custom stereotypes can be created and applied to all objects.
128

• Fully implemented with Java classes and Poseidon is platform-independent. Zip
file version of the installation is also available to install on any platform.
• Internationalization, in addition to English, it supports German, Spanish, Chinese
and French versions of Poseidon.
• Inline text editing is possible in Poseidon, like ArcStyler.
• The Help menu worked in Poseidon Standard Evaluation Edition.
• A Zoom feature to see the model more clearly is available.
• Other documentation written for a specific object will appear in the source code
of that object in this version.
• ANT tool support is included in Poseidon.
ANT tool description is given the section A.1. Code generation in
Poseidon is only in Java in this version, so ANT tool helps in building the
Java applications and ANT comes as a built-in in Poseidon.
• No direct saving of project file to XMI format.
Project cannot be saved in XMI format directly, only exporting to XMI is
allowed (version 1.0 and 1.1). However, the project file of Poseidon
consists of XMI file in zip format. The XMI file can be produced with or
without diagram data.
• Constraints can be specified in plain English, in addition to OCL, but Poseidon
does not check OCL syntax.
• Import feature works only for its own .XMI files, but this feature did not work
here.
129

• Poseidon for UML tool size is around 43 MB, less than the size of the other two
tools.
• When mouse is moved over an object, documentation of the object is seen.
If the user adds any documentation to the object’s documentation tab in
Poseidon, it will appear when mouse is moved over the object.
• Directed associations, associations, self-associations can be drawn in Poseidon
using the UML class diagram toolbar.
• The relationships like dependencies, realizations, inheritance, composition and
aggregations can be drawn in Poseidon.
• All nine types of UML diagrams are supported in Poseidon.
• The Search mechanism in Poseidon allows user to search for an object in the
model.
• A DTD file is available to parse through the XMI file created by Poseidon.
A Document Type Definition File to understand the contents of XMI file
generated by Poseidon is available from its official website [10].
• Auto save feature is not available in Poseidon, unlike GME 4.
• Metamodel-to-model transformation is not present in Poseidon, unlike GME 4.
• Comments are available to connect to a model element just like a note in
ArcStyler.
Comment is present in the Class diagram toolbar to specify user-defined
extra documentation for the model element. The user can connect the
130

Comment to its element through a link associated with the comment from
the toolbar. But Comments cannot be written in multiple lines for better
presentation.
• Auto sizing of the elements is not available in Poseidon.
• Reverse Engineering in Java is supported in this version of Poseidon.
Reverse Engineering is the process of generating its UML model from the
Java source code of the model. However associations might not be
displayed.
• Editing of the source code in the tool itself is not possible in this version of
Poseidon.
• Code generation in Java is based on Velocity in Poseidon.
Velocity is a Java-based template tool that provides velocity template
engine with Java plug-in built in it.
• Interfaces cannot be made remote in Poseidon unlike ArcStyler for creating RMI
components and interfaces should not possess attributes.
• The user cannot restrict the model element from appearing in the generated source
code.
• Declarative tags in .NET, EJB and CORBA, and C# to any model element is not
supported in this version of Poseidon.
• Attributes manipulation is controlled by the property called changeability.
• Merging of current working project into existing project is possible in Poseidon.
• No creation of realizations and associations among packages in Poseidon.
131

• Source code generation in Poseidon is only for classes and classifiers.
• Poseidon tool working architectural style is profile and plug-ins based.
Only Java registered profile is available in this version of Poseidon. But
full commercial version of the tool possess plug-ins for Autolayout,
Requirements plug-in etc and more registered profiles for VB.Net, EJB,
and C# etc. Users are also allowed to create their own plug-ins and extend
existing ones in the commercial version of Poseidon.
132

• Editions
A.3. ArcStyler Features
Available editions are Architect Edition, and Enterprise Editions. The
Community Architect Edition is available for evaluation purposes. In
some areas on the Internet, specification of the editions of ArcStyler
shows the presence of another edition called the Web Edition.
• ArcStyler does not support UML 2.0 Diagram Interchange standard.
133
A detail of the standard is given in the section A.2. The XML file contains
diagram information along with model, but double clicking will not open
ArcStyler, but it is opened in the browser.
• Rapid buttons are not present in ArcStyler to speed up development.
A Rapid buttons description is given in the section A.1.
• A highly integrated platform, with no configurable cartridges.
ArcStyler has many cartridges that are used to build very complex
applications related to various platforms like .NET, CORBA, EJB, C#,
Web Services, etc. Although this current version does not support some
platforms like CORBA, and legacy platforms, it provides integration with
other development platforms. The user can build his/her own customized
cartridges in commercial version. No external cartridges are supported in
this version.
• Usage of multiple cartridges at a time for developing various applications.
(model-to-model transformations) is possible.

The user can load multiple cartridges at a time to develop applications
related to different infrastructures. If a user builds a model using the
Java2 personal edition cartridge, he/she can add the C# cartridge to
transform the existing model into a C# model, if the code is also
considered as a model. This concept is known as model-to-model
transformation and ArcStyler supports it.
• No Autocritiquing feature exists in ArcStyler.
Autocritiquing is explained in the Appendix: A2.
• Structural correctness of the model can be verified by Verify command.
In ArcStyler, structural correctness can be checked by a Cartridge verify
command from the Tools menu of the tool. The Verify command checks
whether the model is structurally correct according to the loaded profile in
order to generate code. Any errors will appear in the output window
beside the Log tool.
• User can assign any type of one UML diagram to a package.
In ArcStyler, one can assign any one diagram to a package. Double
clicking on that package will directly lead to the assigned diagram.
Sometimes this feature helps in fast viewing of diagrams when several
diagrams are in the model.
• ArcStyler generates no Java code during development of the model.
• Working with the environment is relatively fast compared to Poseidon.
The user experiences working rapidly with the tool because of the simple
134

easons: the environment looks very pleasant; cut, copy and paste work
within the tool and between applications; auto sizing of the model
element; no need to change each element property; once the user declares
a profile for a model element, it remains the same until the user changes it
again. Hanging problems occur much less often than with Poseidon.
• Loading takes a bit more time than in Poseidon, whereas saving takes less time.
On a computer with relatively high specifications, the tool loads fast, but
not faster than Poseidon because ArcStyler has to load many things at
startup, like icons for diagrams like EJB Accessor diagram, Web
Component diagram, etc. The saving time is less than 20 seconds in
ArcStyler while Poseidon takes 25-35 seconds for the project shown in
Figure 4.1.
• Report generation facility did not work and reported errors in ArcStyler.
No other form of documentation facility exists in the tool.
• Forward engineering is possible in any language in ArcStyler, but reported errors
with this version.
• Test cases can be generated to test the model.
• Created models are executed with the help of appropriate cartridge, any errors are
135
displayed in the output window, otherwise generates the code to the specified
output directory and output directory path is specified in the output window.
• Copy, cut, paste work within the tool, but not between applications; however
models can be copied as images in .jpg format and pasted to windows applications

136
like photo editor, Microsoft Word, and Word pad. Diagrams can be exported as
.jpg, .wmf, .emf, .svg, and .png formats.
• Printing is not supported in this version of ArcStyler.
• External cartridges and plug-ins cannot be installed in this version of ArcStyler.
Customized cartridges are also not allowed in this version.
• Association classes cannot be created in ArcStyler, unlike Poseidon.
• General drawing tools like circle, polygon, and rectangle are not present in
ArcStyler.
• Export format to Unisys XMI is supported in ArcStyler (XMI 1.0 and 1.1
versions).
• Project files are saved with .asprj extension, for each project, ArcStyler creates a
.guifg file, a GUI configuration file. UML models are saved with .xml.zip, which
are packed XML files. .guifg files are xml files and can be viewed in a browser.
ArcStyler works only with the project file extension of .asprj or supports the
import of .xml.zip files.
• A backup file with .bak extension is created for every project.
• Undo and redo action works.
• Multiple stereotypes can be applied to elements.
• Also custom stereotypes can be created and applied to all objects.
• Fully implemented with Java and JPython classes. ArcStyler is platform-
independent (works on all major platforms of Windows).
• Internationalization, apart from English, it supports German and Spanish.

• Inline text editing is possible in ArcStyler, like Poseidon.
• The Help menu worked in ArcStyler Community Architect Evaluation Edition.
• A Zoom feature to see the model more clearly is available.
• Other documentation written for a specific object will not appear in the source
code of that object in this version.
• ANT tool support is included in ArcStyler.
137
ANT tool description is given in the feature listing of GME 4. ANT comes
as a built-in in ArcStyler.
• Direct saving of UML model to .xml.zip, packed XML format.
• Project UML model can be saved in XML (.xml.zip) format directly. There is no
option for generating XML file without diagram information in ArcStyler.
• Constraints can be specified in plain English, in addition to OCL, and ArcStyler
checks OCL syntax with its built-in OCL syntax checking facility.
• The Import feature works only for its .xml.zip files, but this feature did not work
here.
• The ArcStyler tool size is around 343 MB, more than six times the size of the
other two tools, GME 4 and Poseidon. The reason is its architecture filled with
cartridges.
• When mouse is moved over an object, no documentation associated with the
object is visible.
• Directed associations, and self-associations cannot be drawn in ArcStyler.

• Relationships like dependencies, realizations, inheritance, composition and
aggregations including associations can be drawn in ArcStyler.
• All nine types of UML diagrams are supported in ArcStyler.
• The Search mechanism in ArcStyler allows user to search for an object in the
model.
• A DTD file is not available to parse through the XML file created by ArcStyler.
• Auto save feature is not available in ArcStyler, unlike GME 4.
• No concept of metamodel-to-model transformation in ArcStyler, unlike GME 4.
• Notes are available to connect to model elements just like a Comment in
Poseidon.
Note is present in the Class diagram toolbar to specify some user-defined
extra documentation for the model element. The user can connect the note
to its element through a link associated with the note from the toolbar.
Also notes can be written in multiple lines for better presentation.
• Auto sizing of the elements is available in ArcStyler.
• Reverse Engineering in Java is supported in this version of ArcStyler through a
technique called harvesting.
• Editing of the source code in the tool itself is not possible in ArcStyler.
• Code generation is based on appropriate MDA-cartridges present in ArcStyler.
• Interfaces can be made remote in ArcStyler for creating RMI components and
interfaces can possess attributes.
138

• The user can restrict the model element from appearing in the generated source
code by using the Ignore property of the model element.
• Declarative tags in .NET, EJB and CORBA, and C# to any model element is
supported in ArcStyler.
• Attributes manipulation is controlled by the property called changeability.
• Merging of current working project into existing project is not possible in
ArcStyler.
• Creation of realizations and associations are present among packages in
ArcStyler.
• Source code generation in ArcStyler is only for classes in this version.
• ArcStyler tool working architectural style-plug-ins based through cartridges.
But full commercial version of the tool supports creation of customized
cartridges and integration with databases and development platforms like
Rose.
139

A.4. Source Code of the Interface for the Figure 5.1
sub page_reload(sender as object, e as eventargs)
' ****PAGE RELOAD PUSH BUTTON SUBROUTINE STARTS HERE****
tbselect1.text=""
tbpackage1.text="packagename1"
tbpackage2.text="packagename2"
tbpackage3.text="packagename3"
tbpackage4.text="packagename4"
tbselect2.text=""
tbclass1.text="classname1"
tbclass2.text="classname2"
tbclass3.text="classname3"
tbclass4.text="classname4"
tbclass5.text="classname5"
tbclass6.text="classname6"
tbclass7.text="classname7"
tbclass8.text="classname8"
tbclass9.text="classname9"
tbclass10.text="classname10"
tbpleo1.text="pleomorph1"
tbpleo2.text="pleomorph2"
tbpleo3.text="pleomorph3"
tbpleo4.text="pleomorph4"
tbselect3.text=""
tbrel1.text="relationname1"
tbrel2.text="relationname2"
tbrel3.text="relationname3"
tbrel4.text="relationname4"
tbrel5.text="relationname5"
tbrel6.text="relationname6"
tbrel7.text="relationname7"
tbrel8.text="relationname8"
tbrel9.text="relationname9"
tbrel10.text="relationname10"
tbselect4.text=""
lbselect1.selectedindex=0
lbselect2.selectedindex=0
lbselect3.selectedindex=0
lbselect4.selectedindex=0
140

' ****PAGE RELOAD PUSH BUTTON SUBROUTINE ENDS****
end sub
sub clear(sender as object, e as eventargs)
' ****CLEAR PUSH BUTTON SUBROUTINE STARTS HERE****
tbselect1.text=""
tbpackage1.text=""
tbpackage2.text=""
tbpackage3.text=""
tbpackage4.text=""
tbselect2.text=""
tbclass1.text=""
tbclass2.text=""
tbclass3.text=""
tbclass4.text=""
tbclass5.text=""
tbclass6.text=""
tbclass7.text=""
tbclass8.text=""
tbclass9.text=""
tbclass10.text=""
tbpleo1.text=""
tbpleo2.text=""
tbpleo3.text=""
tbpleo4.text=""
tbselect3.text=""
tbrel1.text=""
tbrel2.text=""
tbrel3.text=""
tbrel4.text=""
tbrel5.text=""
tbrel6.text=""
tbrel7.text=""
tbrel8.text=""
tbrel9.text=""
tbrel10.text=""
tbselect4.text=""
lbselect1.selectedindex=0
lbselect2.selectedindex=0
lbselect3.selectedindex=0
lbselect4.selectedindex=0
' ****CLEAR PUSH BUTTON SUBROUTINE ENDS****
end sub
sub getselection1(sender as object, e as eventargs)
141

' ****FIRST SELECT PUSH BUTTON SUBROUTINE STARTS HERE****
dim item as listitem
tbpackage1.text=""
tbclass1.text=""
tbclass2.text=""
tbrel1.text=""
tbrel2.text=""
tbrel3.text=""
for each item in lbselect1.items
if item.selected=true then
if item.text="packagename1" then
tbpackage1.text = item.text
elseif item.text="classname1" then
tbclass1.text=item.text
elseif item.text="classname2" then
tbclass2.text=item.text
elseif item.text="relationname1" then
tbrel1.text=item.text
elseif item.text="relationname2" then
tbrel2.text=item.text
elseif item.text="relationname3" then
tbrel3.text=item.text
else
tbpackage1.text=""
tbclass1.text=""
tbclass2.text=""
tbrel1.text=""
tbrel2.text=""
tbrel3.text=""
end if
end if
next
' ****FIRST SELECT PUSH BUTTON SUBROUTINE ENDS****
end sub
142

sub getinfo1(sender as object, e as eventargs)
' ****FIRST INFORMATION PUSH BUTTON SUBROUTINE STARTS HERE****
dim item as listitem
tbselect1.text=""
for each item in lbselect1.items
if item.selected=true then
if item.text="packagename1" then
tbselect1.text = "A package component is needed for it contains all other components."
elseif item.text="classname1" then
tbselect1.text="A class is essential."
elseif item.text="classname2" then
tbselect1.text="A class is essential."
elseif item.text="relationname1" then
tbselect1.text="The relationship is required in the domain."
elseif item.text="relationname2" then
tbselect1.text="The relationship is required in the domain."
elseif item.text="relationname3" then
tbselect1.text="The relationship is required in the domain."
else tbselect1.text=""
end if
end if
next
' ****FIRST INFORMATION PUSH BUTTON SUBROUTINE ENDS****
end sub
sub getselection2(sender as object, e as eventargs)
' ****SECOND SELECT PUSH BUTTON SUBROUTINE STARTS HERE****
dim item as listitem
tbpackage2.text=""
tbclass3.text=""
tbclass4.text=""
tbrel4.text=""
143

tbrel5.text=""
tbpleo1.text=""
if (tbpackage1.text="" and tbclass1.text="" and tbclass2.text="") then
lblerrmsg.text="ERROR MSG 101:Please select previous list box components to proceed further"
tbpackage2.enabled=not(tbpackage2.enabled)
tbrel4.enabled=not(tbrel4.enabled)
tbrel5.enabled=not(tbrel5.enabled)
tbclass3.enabled=not(tbclass3.enabled)
tbclass4.enabled=not(tbclass4.enabled)
tbpleo1.enabled=not(tbpleo1.enabled)
else
lblerrmsg.text=""
for each item in lbselect2.items
if item.selected=true then
if item.text="packagename2" then
tbpackage2.text = item.text
elseif item.text="classname3" then
tbclass3.text=item.text
elseif item.text="classname4" then
tbclass4.text=item.text
elseif item.text="pleomorph1" then
tbpleo1.text=item.text
elseif item.text="relationname4" then
tbrel4.text=item.text
elseif item.text="relationname5" then
tbrel5.text=item.text
else
tbpackage2.text=""
tbclass3.text=""
tbclass4.text=""
tbrel4.text=""
tbrel5.text=""
tbpleo1.text=""
end if
end if
144

next
end if
' ****SECOND SELECT PUSH BUTTON SUBROUTINE ENDS****
end sub
sub getinfo2(sender as object, e as eventargs)
' ****SECOND INFORMATION PUSH BUTTON SUBROUTINE STARTS HERE****
dim item as listitem
tbselect2.text=""
for each item in lbselect2.items
if item.selected=true then
if item.text="packagename2" then
tbselect2.text = "A package component is needed for it contains all other components."
elseif item.text="classname3" then
tbselect2.text="A class is essential."
elseif item.text="classname4" then
tbselect2.text="A class is essential."
elseif item.text="pleomorph1" then
tbselect2.text="The pleomorph is required in the domain."
elseif item.text="relationname4" then
tbselect2.text="The relationship is required in the domain."
elseif item.text="relationname5" then
tbselect2.text="The relationship is required in the domain."
else tbselect2.text=""
end if
end if
next
' ****SECOND INFORMATION PUSH BUTTON SUBROUTINE ENDS****
end sub
sub getselection3(sender as object, e as eventargs)
145

' ****THRID SELECT PUSH BUTTON SUBROUTINE STARTS HERE****
dim item as listitem
tbpackage3.text=""
tbclass5.text=""
tbclass6.text=""
tbpleo2.text=""
tbrel6.text=""
tbrel7.text=""
tbrel8.text=""
if (tbpackage2.text="" and tbclass3.text="" and tbclass4.text="") then
lblerrmsg.text="ERROR MSG 102:Please select previous list box components to proceed further"
tbpackage3.enabled=not(tbpackage3.enabled)
tbrel6.enabled=not(tbrel6.enabled)
tbrel7.enabled=not(tbrel7.enabled)
tbrel8.enabled=not(tbrel8.enabled)
tbclass5.enabled=not(tbclass5.enabled)
tbclass6.enabled=not(tbclass6.enabled)
tbpleo2.enabled=not(tbpleo2.enabled)
else
lblerrmsg.text=""
for each item in lbselect3.items
if item.selected=true then
if item.text="packagename3" then
tbpackage3.text = item.text
elseif item.text="classname5" then
tbclass5.text=item.text
elseif item.text="classname6" then
tbclass6.text=item.text
elseif item.text="pleomorph2" then
tbpleo2.text = item.text
elseif item.text="relationname6" then
tbrel6.text=item.text
elseif item.text="relationname7" then
tbrel7.text=item.text
elseif item.text="relationname8" then
tbrel8.text=item.text
146

else
tbpackage3.text=""
tbclass5.text=""
tbclass6.text=""
tbrel6.text=""
tbrel7.text=""
tbrel8.text=""
tbpleo2.text=""
end if
end if
next
end if
' ****THIRD SELECT PUSH BUTTON SUBROUTINE ENDS****
end sub
sub getinfo3(sender as object, e as eventargs)
' ****THIRD INFORMATION PUSH BUTTON SUBROUTINE STARTS HERE****
dim item as listitem
tbselect3.text=""
for each item in lbselect3.items
if item.selected=true then
if item.text="packagename3" then
tbselect3.text = "A package component is needed for it contains all other components."
elseif item.text="classname5" then
tbselect3.text="A class is essential."
elseif item.text="classname6" then
tbselect3.text="A class is essential."
elseif item.text="pleomorph2" then
tbselect3.text="The pleomorph is required in the domain."
elseif item.text="relationname6" then
tbselect3.text="The relationship is required in the domain."
elseif item.text="relationname7" then
tbselect3.text="The relationship is required in the domain."
elseif item.text="relationname8" then
147

tbselect3.text="The relationship is required in the domain."
else tbselect3.text=""
end if
end if
next
' ****THIRD INFORMATION PUSH BUTTON SUBROUTINE ENDS****
end sub
sub getselection4(sender as object, e as eventargs)
' ****FOURTH SELECT PUSH BUTTON SUBROUTINE STARTS HERE****
dim item as listitem
tbpackage4.text=""
tbclass7.text=""
tbclass8.text=""
tbclass9.text=""
tbclass10.text=""
tbpleo3.text=""
tbpleo4.text=""
tbrel9.text=""
tbrel10.text=""
if (tbpackage3.text="" and tbclass5.text="" and tbclass6.text="") then
lblerrmsg.text="ERROR MSG 103:Please select previous list box components to proceed further"
tbpackage4.enabled=not(tbpackage4.enabled)
tbrel9.enabled=not(tbrel9.enabled)
tbrel10.enabled=not(tbrel10.enabled)
tbclass7.enabled=not(tbclass7.enabled)
tbclass8.enabled=not(tbclass8.enabled)
tbclass9.enabled=not(tbclass9.enabled)
tbclass10.enabled=not(tbclass10.enabled)
tbpleo3.enabled=not(tbpleo3.enabled)
tbpleo4.enabled=not(tbpleo4.enabled)
else
lblerrmsg.text=""
for each item in lbselect4.items
if item.selected=true then
148

if item.text="packagename4" then
tbpackage4.text = item.text
elseif item.text="classname7" then
tbclass7.text=item.text
elseif item.text="classname8" then
tbclass8.text = item.text
elseif item.text="classname9" then
tbclass9.text = item.text
elseif item.text="classname10" then
tbclass10.text = item.text
elseif item.text="pleomorph3" then
tbpleo3.text = item.text
elseif item.text="pleomorph4" then
tbpleo4.text = item.text
elseif item.text="relationname9" then
tbrel9.text = item.text
elseif item.text="relationname10" then
tbrel10.text = item.text
else item.selected=false
end if
end if
next
end if
' ****FOURTH SELECT PUSH BUTTON SUBROUTINE ENDS****
end sub
sub getinfo4(sender as object, e as eventargs)
' ****FOURTH INFORMATION PUSH BUTTON SUBROUTINE STARTS
HERE****
dim item as listitem
tbselect4.text=""
for each item in lbselect4.items
149

if item.selected=true then
if item.text="packagename4" then
tbselect4.text = "A package component is needed for it contains all other components."
elseif item.text="classname7" then
tbselect4.text="A class is essential."
elseif item.text="classname8" then
tbselect4.text="A class is essential."
elseif item.text="classname9" then
tbselect4.text="A class is essential."
elseif item.text="classname10" then
tbselect4.text="A class is essential."
elseif item.text="pleomorph3" then
tbselect4.text="The pleomorph is required in the domain."
elseif item.text="pleomorph4" then
tbselect4.text="The pleomorph is required in the domain."
elseif item.text="relationname9" then
tbselect4.text="The relationship is required in the domain."
elseif item.text="relationname10" then
tbselect4.text="The relationship is required in the domain."
else tbselect4.text=""
end if
end if
next
' ****FOURTH INFORMATION PUSH BUTTON SUBROUTINE ENDS****
end sub

forecolor="white" font-bold="true" font-size="13pt"
text="APPLICATION MODEL FOR DEVELOPING VARIANTS">
151
packagename1
classname1
classname2
relationname1
relationname2
relationname3
   
  
  
  
  

  
152
packagename2
classname3
classname4
pleomorph1
relationname4
relationname5
   
  
  
  
  
  
packagename3
classname5
classname6
pleomorph2
relationname6
relationname7
relationname8
   

153
 
 
 
 
 
 
packagename4
classname7
classname8
classname9
classname10
pleomorph3

154

A.5. Source Code of the Generated XML File for the Figure 5.1
Imports System
Imports System.Xml
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls
Public Class sample
Inherits System.Web.UI.Page
' ****GENERATE XML FILE PUSH BUTTON SUBROUTINE STARTS HERE****
public tbpackage1 as textbox
public tbpackage2 as textbox
public tbpackage3 as textbox
public tbpackage4 as textbox
public tbclass1 as textbox
public tbclass2 as textbox
public tbclass3 as textbox
public tbclass4 as textbox
public tbclass5 as textbox
public tbclass6 as textbox
public tbclass7 as textbox
public tbclass8 as textbox
public tbclass9 as textbox
public tbclass10 as textbox
public tbpleo1 as textbox
public tbpleo2 as textbox
public tbpleo3 as textbox
public tbpleo4 as textbox
public tbrel1 as textbox
public tbrel2 as textbox
public tbrel3 as textbox
public tbrel4 as textbox
public tbrel5 as textbox
public tbrel6 as textbox
public tbrel7 as textbox
public tbrel8 as textbox
public tbrel9 as textbox
public tbrel10 as textbox
public lbselect1 as list box
public lbselect2 as list box
public lbselect3 as list box
public lbselect4 as list box
public lblmsgerr as label
dim str as string=" "
155

sub createxmlfile(sender as object, e as eventargs)
' ****CREATEXMLFILE SUBROUTINE STARTS HERE****
dim currentContext As System.Web.HttpContext = System.Web.HttpContext.Current
dim writer as XmlTextWriter
if (tbpackage4.text="" and tbclass7.text="" and tbclass8.text="" and tbclass9.text="" and
tbclass10.text="" and tbpleo3.text="" and tbpleo4.text="" and tbrel9.text="" and tbrel10.text="")
then
currentContext.response.Redirect("error.xml")
else
try
writer = new XmlTextWriter(currentContext.Server.MapPath("result.xml"), nothing)
writer.writestartdocument
writer.formatting = formatting.indented
writer.indentation=3
writer.writestartelement("packagelibrary")
' ****FIRST PACKAGE CODE BEGINS****
writer.writestartelement("package")
if tbpackage1.text"" then
writer.writeelementstring("archetype-pattern", tbpackage1.text)
end if
writer.writestartelement("class")
if tbclass1.text"" then
writer.writeelementstring("archetype", tbclass1.text)
end if
writer.writeendelement()
writer.writestartelement("class")
if tbclass2.text"" then
writer.writeelementstring("archetype", tbclass2.text)
end if
writer.writeendelement()
writer.writestartelement("Relationships")
if tbrel1.text"" then
writer.writeelementstring("relationshiptype", tbrel1.text)
end if
if tbrel2.text"" then
writer.writeelementstring("relationshiptype", tbrel2.text)
156

end if
if tbrel3.text"" then
writer.writeelementstring("relationshiptype", tbrel3.text)
end if
writer.writeendelement()
writer.writeendelement()
' ****END OF FIRST PACKAGE CODE****
' ****SECOND PACKAGE CODE BEGINS****
writer.writestartelement("package")
if tbpackage2.text"" then
writer.writeelementstring("archetype-pattern", tbpackage2.text)
end if
writer.writestartelement("class")
if tbclass3.text"" then
writer.writeelementstring("archetype", tbclass3.text)
end if
writer.writeendelement()
writer.writestartelement("class")
if tbclass4.text"" then
writer.writeelementstring("archetype", tbclass4.text)
end if
writer.writestartelement("pleomorph")
if tbpleo1.text"" then
writer.writeelementstring("pleomorph", tbpleo1.text)
end if
writer.writeendelement()
writer.writeendelement()
writer.writestartelement("Relationships")
if tbrel4.text"" then
writer.writeelementstring("relationshiptype", tbrel4.text)
end if
if tbrel5.text"" then
writer.writeelementstring("relationshiptype", tbrel5.text)
end if
writer.writeendelement()
writer.writeendelement()
' ****END OF SECOND PACKAGE CODE****
' ****THIRD PACKAGE CODE BEGINS****
writer.writestartelement("package")
if tbpackage3.text"" then
157

writer.writeelementstring("archetype-pattern", tbpackage3.text)
end if
writer.writestartelement("class")
if tbclass5.text"" then
writer.writeelementstring("archetype", tbclass5.text)
end if
writer.writeendelement()
writer.writestartelement("class")
if tbclass6.text"" then
writer.writeelementstring("archetype", tbclass6.text)
end if
writer.writeendelement()
writer.writestartelement("pleomorph")
if tbpleo2.text"" then
writer.writeelementstring("pleomorph", tbpleo2.text)
end if
writer.writeendelement()
writer.writestartelement("Relationships")
if tbrel6.text"" then
writer.writeelementstring("relationshiptype", tbrel6.text)
end if
if tbrel7.text"" then
writer.writeelementstring("relationshiptype", tbrel7.text)
end if
if tbrel8.text"" then
writer.writeelementstring("relationshiptype", tbrel8.text)
end if
writer.writeendelement()
writer.writeendelement()
' ****END OF THIRD PACKAGE CODE****
' ****FOURTH PACKAGE CODE BEGINS****
writer.writestartelement("package")
if tbpackage4.text"" then
writer.writeelementstring("archetype-pattern", tbpackage4.text)
end if
writer.writestartelement("class")
if tbclass7.text"" then
writer.writeelementstring("archetype", tbclass7.text)
end if
writer.writeendelement()
writer.writestartelement("class")
if tbclass8.text"" then
writer.writeelementstring("archetype", tbclass8.text)
end if
158

writer.writeendelement()
writer.writestartelement("class")
if tbclass9.text"" then
writer.writeelementstring("archetype", tbclass9.text)
end if
writer.writeendelement()
writer.writestartelement("class")
if tbclass10.text"" then
writer.writeelementstring("archetype", tbclass10.text)
end if
writer.writeendelement()
writer.writestartelement("pleomorph")
if tbpleo3.text"" then
writer.writeelementstring("pleomorph", tbpleo3.text)
end if
writer.writeendelement()
writer.writestartelement("pleomorph")
if tbpleo4.text"" then
writer.writeelementstring("pleomorph", tbpleo4.text)
end if
writer.writeendelement()
writer.writestartelement("Relationships")
if tbrel9.text"" then
writer.writeelementstring("relationshiptype", tbrel9.text)
end if
if tbrel10.text"" then
writer.writeelementstring("relationshiptype", tbrel10.text)
end if
writer.writeendelement()
writer.writeendelement()
' ****END OF FOURTH PACKAGE CODE****
writer.writeendelement()
catch ex as exception
str="error accessing XML file"
finally
writer.close()
currentContext.response.Redirect("result.xml")
end try
end if
' ****CREATEXMLFILE SUBROUTINE ENDS****
end sub
' ****GENERATE XML FILE PUSH BUTTON SUBROUTINE ENDS****
End Class
159

A.6. XML File of the Variant Model-1 for the Figure 5.6
-
-
packagename1
-
classname1
-
relationname2
-
packagename2
-
classname3
-
classname4
-
pleomorph1
-
relationname5
-
packagename3
-
classname5
-
classname6
-
relationname7
relationname8
-
packagename4
-
classname7
160

-
classname8
-
classname10
-
pleomorph4
-
relationname10
161

A.7. XML File of the Variant Model-2 for the Figure 5.7
-
-
-
classname2
-
relationname2
relationname3
-
-
classname3
-
classname4
-
pleomorph1
-
relationname5
-
packagename3
-
relationname6
relationname8
-
-
classname7
-
classname8
-
162

pleomorph3
-
relationname9
relationname10
163

A.8. XML File of the Variant Model-3 for the Figure 5.8
-
-
packagename1
-
classname1
-
classname2
-
relationname3
-
packagename2
-
classname4
-
relationname4
relationname5
-
-
classname5
-
pleomorph2
-
relationname6
relationname7
relationname8
-
-
classname7
164

-
classname10
-
pleomorph4
-
relationname9
165

A.9. Complete Listing of the XMI File for the Figure 4.1
166
Netbeans XMI Writer
1.0
Package

167
visibility = 'public' isSpecification = 'false' isRoot = 'false' isLeaf = 'false'
isAbstract = 'false'>

168
isAbstract = 'false'>

LIST OF REFERENCES
[1] “Object Management Group”. Last referenced: November 12, 2004.
http://www.omg.org/
[2] Clauss, M., “Modeling Variability with UML”, Intershop Research, Software
Engineering Group, Dresden University of Technology, June 29, 2001.
Last referenced: November 12, 2004.
http://www.netobjectdays.org/pdf/01/papers/ws-gcse/matthias_clauss_gcse.pdf
169
[3] Clauss, M., “Generic Modeling using UML Extensions for Variability”, Intershop
Research, Software Engineering Group, Dresden University of Technology, September
14, 2001. Last referenced: November 12, 2004.
http://www.isis.vanderbilt.edu/oopsla2k1/Papers/Clauss.pdf
[4] Jacobson, I., Griss, M.L., and Jonnson, P., “Software Reuse - Architecture - Process
and Organization for Business Success”, Addison-Wesley Longman, 1997.
[5] Clauss, M., “Untersuchung der Modellierung von Variabilität in UML”, diploma
thesis, August 2001. Last referenced: November 12, 2004.
http://www-st.inf.tu-dresden.de/home/html/de/diplomarbeiten/DAClauss.pdf
[6] Robak, S., Franczyk, B., and Politowicz, K., “Extending the UML for Modeling
Variability in System Families”, Intl. Journal Appl. Math. Computer Science, 2002,
Vol.12, No.2, pp. 285-298. Last referenced: November 12, 2004.
http://matwbn.icm.edu.pl/ksiazki/amc/amc12/amc1227.pdf
[7] Varghese, C., “Examining, Documenting and Modeling the Problem Space of a
Variable Domain”. M.S. Project, TR-CIS-0612-02, Department of Computer &
Information Science, Indiana University Purdue University Indianapolis, June 14, 2002.
Last referenced: November 16, 2004.
http://www.cs.iupui.edu/UniFrame/pubs-openaccess/tinaProjectFinal.pdf
[8] Arlow, J., and Neustadt, I., “Enterprise Patterns And MDA, Building Better Software
With Archetype Patterns And UML”, Addison-Wesley, 2003.
[9] “The Generic Modeling Environment”. Last referenced: November 12, 2004.
http://www.isis.vanderbilt.edu/Projects/gme/
[10] “Model Integrated Computing”. Last referenced: November 12, 2004.
http://www.isis.vanderbilt.edu/

[11] “Poseidon for UML”. Last referenced: November 12, 2004.
http://www.gentleware.com/company/CompanyProductOverview.pdf
[12] “Screenshots of Poseidon for UML”. Last referenced: November 12, 2004.
http://www.gentleware.com/products/screenshots/
[13] “Poseidon for UML User’s Guide”. Last referenced: November 12, 2004.
http://www.gentleware.com/products/documentation/PoseidonUsersGuide.pdf
170
[14] Grotens, R., “MDA-based Development in Practice Uniting Model and Code So
That They Can‘t Drift Apart”, Technical Overview, Compuware. Last referenced:
November 12, 2004.
http://www.java.no/web/moter/javazone03/presentations/RuudGrotens/Scandinavia.pdf
[15] “Leading the Way in Model Driven Architecture”.
Last referenced: November 12, 2004.
http://www.ArcStyler.com
[16] “The Architecture IDE for MDA”. Last referenced: November 12, 2004.
http://www.ArcStyler.com/as_support/factsheets/iO_ArcStyler_Overview.pdf
[17] “ArcStyler®/MDA Details”. Last referenced: November 12, 2004.
http://www.ArcStyler.com/as_support/factsheets/iO_ArcStyler_MDA_Details.pdf
[18] “ArcStyler’s Modeling style and User’s Guide for ArcStyler 4.0”.
Last referenced: November 12, 2004.
http://www.ArcStyler.com/
[19] “Poseidon Diagram Interchange Standard 2.0”. Last referenced: November 12, 2004.
http://www.gentleware.com/knowledge/dinterchange.php4
[20] Sochos, P., Philippow, I., and Riebisch, M., “Feature-oriented Development of
Software Product Lines: Mapping Feature Models to the Architecture”, Technical
University Ilmenau, Ilmenau, Germany. Last referenced: November 16, 2004.
http://www.theoinf.tu-ilmenau.de/~pld

Other Bibliographic Material
Booch, G., Rumbaugh, J., and Jacobson, I., “The Unified Modeling Language User’s
Guide”, Addison-Wesley, 1999.
Pashov, I., and Riebisch, M., “Using Feature Modeling for Program Comprehension and
Software Architecture Recovery”, Technical University, Ilmenau, Germany.
Last referenced: November 12, 2004.
http://www.theoinf.tu-ilmenau.de/~riebisch/publ/ecbs03-fosar.pdf
Soley, R., and OMG Staff Strategy Group, “Model Driven Architecture”, Object
Management Group, White Paper, Draft 3.2, November 27, 2000.
Last referenced: November 12, 2004.
http://www.catalysis.org/publications/papers/2001-mda-Overview-00-11-05.pdf
“ArcStyler MDA-Business Transformer Tutorial for ArcStyler Version 3.x”.
Last referenced: November 12, 2004.
http://www.io-software.com/as_support/docu/BTA_Modeling_Style_Guide.pdf
Garcia, A.B., Mansell, J., and Sellier, D., “From Customer Requirements to PIM:
Necessity and Reality”, European Software Institute, Bizkaia, Spain.
Last referenced: November 12, 2004.
http://www.metamodel.com/wisme-2002/papers/belenGarcia.pdf
Riebisch, M., Bollert, K., Streitferdt, D., and Philippow, I., “Extending Feature Diagrams
with UML Multiplicities”, Integrated Design and Process Technology, IDPT-2002.
Last referenced: November 12, 2004.
http://www.theoinf.tu-ilmenau.de/~streitdf/TheHome/own/data/IDPT2002-paper.pdf
Neighbors, J., “Domain Analysis and Generative Implementation”, Bayfront
Technologies, Newport Beach, CA. Last referenced: November 12, 2004.
http://www.bayfronttechnologies.com/icsr5dp.pdf
171
Poole, J., “Model Driven Architecture: Vision, Standards And Emerging Technologies”,
Position Paper submitted to ECOOP 2001, Hyperion Solutions Corporation, April 2001.
Last referenced: November 12, 2004
http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf
Iyengar, S., “Model Driven Web Services Development using UML, XML, WSDL &
BPEL4WS”, Object Management Group Architecture Board, SI-SE 2004.
Last referenced: November 12, 2004.
http://www.ifi.unizh.ch/si-se/sise2004/Tutorial_Iyengar.pdf

Guy, C., and Sourrouille, L., “Model Mapping in MDA”, INSA, France. Last referenced:
November 12, 2004.
http://www.metamodel.com/wisme-2002/papers/caplat.pdf
172
Sprinkle, J., Karsai, G., Ledeczi, A., Nordstrom, G., Bakay, A., Garrett, J., Thomason, C.,
and Volgyesi, P., “The Generic Modeling Environment,” ISIS, Vanderbilt University,
Nashville, TN.
Last referenced: November 12, 2004.
http://www.isis.vanderbilt.edu/publications/archive/Ledeczi_A_5_17_2001_The_Generi.
pdf
Ziadi, T., Jezequel, J., and Fondement, F., “Product Line Derivation with UML”, IRISA,
Campus Universitaire de Beaulieu, France. Last referenced: November 19, 2004.
http://lgl.epfl.ch/members/fondement/docs/papers/Ziadi03b.pdf
Dykman, N., “SAGE: Generating Applications with UML and Components”, M.S.
Thesis, Department of Computer Science, University of Utah, August 1999.
Last referenced: November 23, 2004.
http://www.cs.utah.edu/~ndykman/Draft.pdf