TOWARDS CUSTOMIZING UML TOOLS FOR ENTERPRISE ARCHITECTURE ...
TOWARDS CUSTOMIZING UML TOOLS FOR
ENTERPRISE ARCHITECTURE MODELING
Vytautas Magnus University, Faculty of Informatics, Department of Applied Informatics
Vileikos st. 8-409, LT-44404 Kaunas, Lithuania, email@example.com
Kaunas University of Technology, Department of Information Systems
Studentu st. 50-313a, LT-51368 Kaunas, Lithuania, firstname.lastname@example.org
The idea of the enterprise architecture (EA) has been active since 1980-ies. However, enterprises still lack a clear
approach and tools for implementing it in practice. In most cases, enterprise models are fragmental and use domain-
specific frameworks that do not have appropriate support in industrial tools. We introduce a novel approach to
customizing UML tools for domain-specific modeling needs. This approach was implemented in MagicDraw UML and
has already started to gain enthusiastic adoption in industry. The possibility to customize UML makes it more suitable as
a platform for EA. While simplifying complex UML language and focusing on domain modeling concepts, it enables
modelers to reuse the powerful features of UML tools – standard-based model data repository, diagramming features,
model elements relationships analysis and navigation, model comparison and merge, documentation engine. The
presented ideas are illustrated by custom EA model samples.
Enterprise architecture, UML, domain-specific modeling, customization, MagicDraw
Enterprise Architecture (EA) has been a hot topic for over 20 years – J.A. Zachman has published his famous
paper on a framework for information systems architecture back in 1987 (Zachman, J.A., 1987). However,
after 20 years have passed, a few companies managed to support this initiative in practice. On one hand, this
happened due to the lack of appropriate modeling skills, but on the other hand, we can blame the modeling
tools for not supporting this initiative with appropriate feature sets. Today UML is considered as de facto
standard in software development and is also used in multiple other domains ranging from business process
to scientific modeling. Since its first version, which was released in 1997, UML has grown quite large and
currently covers about 250 modeling meta-classes that are highly interrelated. This is obviously too
complicated for a typical modeler to learn and apply efficiently. Therefore many practitioners are jumping
into the recent trend of domain-specific languages (DSL) that usually provide a small set of domain-specific
modeling concepts focused on specialized problems. However, in the most typical case these DSL solutions
are not based on standards – they are vendor-specific and do not provide a basis for connecting to the models
covering other aspects of EA. Therefore, a typical DSL is not a suitable candidate for a part of EA
framework. Since UML is already considered as de facto standard in software industry, is supported by a
large number of vendors, has a rather successfully standardized format for storing and exchanging model
data, and provides simple but powerful mechanisms for extending the language using UML profiles, it is a
natural candidate for the basis of EA framework. There have been multiple attempts to apply UML for EA
modeling (Dalgarno, M. and Fowler, M., 2008), but many modelers found it too complicated and non-natural
for solving their domain-specific problems. Currently a lot of debates comparing UML to DSL are going on
(Armour, F. et al, 2003). We think that UML and DSL are not contradictory approaches – you can leverage
UML profiles for building DSL. We believe this is the most efficient way to go since UML modeling
environments have already reached a high maturity level and reusing their features is an obvious benefit. We
will focus on discussing how UML-based DSL solutions should support EA framework. We will also present
a new modeling approach how interrelated DSL can be defined and enabled, which was recently
implemented in one of the leading UML tools (MagicDraw UML, 2008).
The rest of the paper is structured the following way: we review the recent approaches to EA modeling,
then we present an innovative way to customize UML modeling environment, which makes it suitable for
efficient EA modeling, and illustrate the expressed ideas with a small case study presenting several
interrelated EA model artifacts created in MagicDraw UML environment.
2. APPROACHES TO ENTERPRISE ARCHITECTURE MODELING
The primary ideas about Enterprise Architecture were quite promising and seemed to be enthusiastically
adopted among researchers and practitioners. However, even to the recent date most of the books published
on Enterprise Architecture are just escalating the idea at conceptual level without giving a concrete advice
how to define, relate, and maintain consistent Enterprise Architecture models (McGovern, K. et al, 2003,
Carbone, J., 2004, Bernard, S. A., 2005). Some of the other books and papers, like (Lankhorst, M., 2005,
Jonkers, H. et al, 2004), are getting more concrete and introduce custom meta-models and modeling methods
for Enterprise Architecture. But they do not discuss the maintenance and tooling aspects, which are essential
for practical use. Some discussion about the strengths and weaknesses of the Enterprise Architecture
management tools can be found in (Ernst, A. et al, 2006). A big issue with the concrete approaches to
Enterprise Architecture is that in order to define it, you typically need to be domain-specific. While some
research towards having a single enterprise modeling language was done (Jonkers, H. et al, 2003), the current
situation in industry proves that it is not easy if not impossible – multiple EA frameworks are developed as
standards for different domains, e.g. Department of Defense Architecture Framework (DoDAF), Ministry of
Defense Architectural Framework (MODAF), The Open Group Architecture Framework (TOGAF), Federal
Enterprise Architecture Framework, and others. Most of these frameworks are coming from governmental
institutions and are not out-of-the-box suitable for modeling a typical enterprise. It is clear that one needs a
tool with possibilities to define a custom meta-model for covering domain-specific aspects of EA. One
possibility is to use industrial meta-modeling tools like MetaEdit+ for creating domain-specific languages
(Tolvanen, J. et al, 2007). There have been a number of research works focusing on building META Case
tools (Ebert, J. et al, 1997, Zhang, K. et al, 2001, de Lara, J. and Vangheluwe, H., 2002, Costagliola, G. et al,
2006). However, using this kind of approach in practice suffers from vendor-specific implementation locking
users into an environment, which is also not easy to extend or integrate with external tools mainly due to the
non-standardized data repository. The other approach is to use standardized modeling approaches defined by
Object Management Group (OMG) consortium. While OMG defined Meta Object Facility (MOF) (OMG,
2006) as a meta-language for defining modeling languages, there is little tooling support for applying it. The
other product from OMG – Unified Modeling Language (UML) (OMG, 2007a) – is widely used in practice
and is supported by numerous tools. Some of those tools have already been developed and used in industry
for more than 10 years and reached a rather high maturity level by providing a set of powerful utility features
for efficient modeling. UML is now considered to be a general-purpose visual modeling language, although it
was primarily designed to specify, visualize, construct, and document the artifacts of a software system.
UML provides the possibilities to extend the language by building profiles. A profile introduces a set of
stereotypes that define specializations of UML meta-model elements, which may include specifying new
properties (tags) and a custom graphical representation for stereotyped user model elements (Selic, B., 2007).
However, this approach is often criticized for only allowing extending the language, but not restricting it. In
addition to the overwhelming complexity of UML, domain experts often find the UML terminology not
suitable. Although this is reminding of a Babel tower lesson, it seems that it is easier to build new domain-
specific modeling languages (DSML) like Business Process Modeling Notation (BPMN) (OMG, 2008), and
System Modeling Language (SysML) (OMG, 2007b), than to make business analysts use term Action instead
of Task or system engineer to use Class instead of Block. If we choose UML for a basis of Enterprise
Architecture, the modeling environment may look complicated and even messy for modelers who haven’t got
an appropriate UML background. Therefore we need to solve the issues of hiding the complexity of UML
and customizing it to naturally reflect the modeling concepts of particular EA modeling framework cells. We
dedicate the next chapter for detailed explanation of the innovative approach to customizing UML modeling
environment and presenting the numerous benefits that EA modelers can get taking this approach. This
approach has been implemented in MagicDraw UML product (one of the authors of this paper is a member of
MagicDraw UML research and development team). However, the approach suggests fundamental ideas that
could be easily transferred to the other modeling tools based on UML.
3. CUSTOMIZING UML TOOLS FOR ENTERPRISE MODELING
In order to address the before mentioned issues with adopting UML for EA, we suggest adding a layer of
model customizations that define the restrictions for model elements, hide the specifics of UML and virtually
transform the stereotyped UML elements into first-class domain-specific modeling concepts using only the
properties and terminology natural for that domain. In model-centric spirit, we suggest to add these
customizations as model elements distributed in plug-able model libraries. This simple innovation nicely
solves the issues of hiding unnecessary UML complexity and transforming UML into a domain-specific
modeling language (DSML), see figure 1.
UML UML Profile into metamodel Customizations
Figure 1. DSML definition framework in the context of OMG meta-layer architecture
The implementation of customizations engine in the MagicDraw UML from the end-user’s view is as
simple as providing a stereotype Customization, which is applicable for Class elements and provides multiple
tags for configuring the appearance of the customized end user stereotype, see table 1. Additionally,
MagicDraw UML supports several stereotypes applicable to the properties of the Customization that can be
used for renaming reused standard UML properties or grouping properties of the customized element.
Table 1. The main tags of the Customization stereotype
CustomizationTarget Meta element that needs to be customized –
typically a stereotype, but may also be standard
HideMetatype Whether to hide UML meta-class and use
stereotype as a first-class modeling concept
RepresentationText Alternative representation text to be used instead
of stereotype name, which might be prefixed for
ensuring unique name in the global stereotype
PossibleOwners The meta elements that are allowed to contain the
SuggestedOwnedDiagrams Diagrams that make sense for modeling some
aspects of the customized element and therefore
should be suggested in repository browser’s
SuggestedOwnedTypes Types of model elements that should be
suggested for creating in the namespace of the
UsedUMLProperties Which standard UML properties should be used
in addition to the custom stereotype properties
AllowedRelationships What relationships should be allowed connecting
to the customized element
TypesForSource What are possible types to be used as source
elements for the customized relationship
TypesForTarget What are possible types to be used as targets
elements for the customized relationship
Each time some model is loaded, MagicDraw UML checks for customizations and configures the user
model element appearance according to the found customizations’ tag values. In addition to the
customization engine, the tool provides a simple wizard for setting up custom diagrams that would typically
use stereotyped and customized elements. The redundant UML diagrams and functionality can be easily
hidden through environment configuration options representing a specific user perspective.
While this customization hides the complexity of UML, it still leverages the full power of the modeling
environment, which is a necessary enabler for creating, analyzing and maintaining integrated models. Some
of the most useful features are:
Model data repository based on standard interchangeable format, which also enables using external tools
for processing model data;
Diagram editor providing features for fast and intuitive modeling, e.g. drag and drop, specifying model
element properties by typing on the diagram, type auto-completion, suggesting relationships available for
selected element, possibility to change level of model element details visible on a diagram;
Model element navigation allowing to quickly navigate between related elements through their properties;
Model element relationship analysis tools for finding out the elements associated to the analyzed model
element(s) by certain relationship type(s) and show this information in appropriate form, e.g. element
Model metrics for calculating various statistical information like a number of model elements or a
class/package instability ratio;
Model validation for ensuring that the model conforms to the defined correctness and completeness rules;
Model version comparison for finding out the changes to a baseline model;
Model version merge allowing to merge the changes of independently modified model versions;
Model refactoring allowing to quickly improve model structure by changing design or its representation,
e.g. converting task into sub-process, collecting a set of states into a sub state machine, etc.;
Modeling patterns enabling to automatically add the structure of a pre-defined template expressing a
reusable modeling pattern;
Model transformations enabling to transform models into different technologies or domains, e.g. object-
oriented information structure into relational database or XML schema;
Model teamwork capabilities enabling global model repository, which requires explicit locking of
elements for editing in order to avoid conflicts;
Model decomposition for improving performance and sharing parts of project between team of modelers
or as reusable libraries;
Open API for creating custom plugins for extending model environment functionality.
In the next chapter, we will present a small case study for illustrating how the customization of UML tool
can be used for modeling a specific cell of EA framework.
4. A CASE STUDY ON CUSTOMIZING UML FOR ENTERPRISE
The generic Zachman framework is a very abstract one, and multiple modelers have been suggesting various
interpretations leading to concrete model artifacts. In figure 2 we present our interpretation, which limits the
framework model to three levels of abstraction (business, system, and technology). We believe that UML is a
perfect solution for covering the system level, while both business and technology models should be created
using different UML-based DSL models.
Business Model System Model Technology Model
(UML-based DSL) (UML) (UML-based DSL)
What Concepts Classes, Objects Relational DB Schema,
(Data) XML Schema
How Business Processes Activities Algorithms,
(Function) GUI Navigation
Where Organization Units, Components, Technology-Specific
(Network) Projects Deployment Nodes Artifact Deployment
Who Employees, Actors Identity Management
(People) Job Roles
When Business Events Events User Actions,
(Time) System Events
Why Business Goals Use Cases -
Figure 2. An interpretation of abstract Enterprise Architecture framework for answering to the raised questions in
Business, System, and Technology models
Let us define a simple DSL for modeling the underlined cells: organization units, projects, employees and
job roles. The figure 3 presents stereotypes model representing UML extension elements necessary for
customizing the language for covering organization concepts. In figure 4 we present a customization element
(a class stereotyped by Customization), which on model loading time virtually transforms the stereotyped
user model elements into first-class modeling elements represented by a custom specification dialog intuitive
for the domain modeler. In figure 5 we present a screenshot of the customized modeling environment, which
shows both model repository and a custom diagram sample. While this doesn’t show the full picture of the
customized environment possibilities, it presents a sample showing the power of the presented customization
approach. Finally, we illustrate that the reusable UML modeling features like setting up an automatically
updated relationship matrix, showing employee associations to skills in figure 6, is still applicable to the
customized environment. It is also important to emphasize that the created organization structure model
elements can be linked to the elements in the models for the other framework cells, e.g. the job roles or
employees can be used as swimlane representations in business processes or system activities. Using UML as
a foundation for the EA model elements enables the integrity and consistency of the overall EA model. An
illustrative explanation of how to create a set of UML diagrams representing consistently related elements
from different abstraction levels is available in (Silingas, D. and Butleris, R., 2008).
<<stereotype>> <<stereotype>> requiredSkills <<stereotype>>
Employee skills Skill 1..* Role
[Class] 1..* [Class] [Actor]
first name : String team description : String instructions : String
last name : String
e-mail : String 1..*
phone : String
<<stereotype>> <<stereotype>> <<stereotype>> <<stereotype>>
OrganizationUnit Project project ProjectRole OrganizationRole
[Package] suppliers [Package] [Actor] [Actor]
title : String 1..* start : date
address : String clients end : date
description : String description : String
<<stereotype>> <<stereotype>> <<stereotype>>
Organization Supervise RoleAssignment
[Package] [Dependency] [Dependency]
id : Integer start : date start : date
VAT code : Integer end : date end : date
type : OrgType workload : float
Figure 3. UML profile for organization structure modeling
customizationTarget = Employee
hideMetatype = true
possibleOwners = OrganizationUnit
Figure 4. A customization element, a DSML model element, and the custom specification dialog
Figure 5. The repository of an organization structure model and a custom organization structure diagram for the
employees, their supervision, and organization role assignments
No Magic Europe
Figure 6. Sample of employee to skills association matrix, which can be set up as automatically updated artifacts in
MagicDraw UML modeling environment
We have reviewed the recent approaches to Enterprise Architecture (EA) modeling and identified the major
challenges – overwhelming complexity of UML-based solutions and fragmentation of DSL-based solutions.
We suggest combining these two major approaches by building DSL modeling environments based on UML
profiles that enable integrity of modeling artifacts and use customization settings for simplifying modeling by
making UML transparent and providing domain-specific look and feel for modelers. Using this approach
enables the modelers to reuse the powerful features of UML modeling environments like model element
relationship analysis, transformation-driven reports, collaborative modeling capabilities, model correctness
and completeness validation, model refactoring, modeling guidance, model version comparison and merge,
which all are enablers for practicing EA modeling. We have illustrated the presented ideas with customized
modeling samples for a couple of EA framework cells. This provides a proof of concept for adopting UML
tools for EA modeling and emphasizes the benefits of this approach. The presented approach should be
refined by further research focusing on improving the usability of the solution and the customization
possibilities allowing to make UML meta-model even more transparent to the end users.
The work is supported by Lithuanian State Science and Studies Foundation according to High Technology
Development Program Project "VeTIS" (Reg.No. B-07042).
1. Armour, F. et al, 2003. A UML-Driven Enterprise Architecture Case Study. Proceedings of the 36th Annual Hawaii
International Conference on System Sciences (HICSS’03), Publisher: IEEE Comput. Soc., USA, ISBN: 0-7695-1874-
5, CD-ROM, 10 pp.
2. Bernard, S. A., 2005. An Introduction To Enterprise Architecture, 2nd Edition. AuthorHouse.
3. Carbone, J., 2004. IT Architecture Toolkit. Prentice Hall PTR.
4. Costagliola, G. et al, 2006. Constructing Meta-CASE Workbenches by Exploiting Visual Language Generators. IEEE
Transaction of Software Engineering, vol. 32(3), pp. 156-175.
5. Dalgarno, M. and Fowler, M., 2008. UML vs. Domain-Specific Languages. Methods and Tools, vol. 16(2), pp.2-8.
6. Ebert, J., Suttenbach, R., and Uhe, I., 1997. Meta-CASE in Practice: A Case for KOGGE. In A. Olive, J. A. Pastor:
Advanced Information Systems Engineering, Proceedings of the 9th International Conference, CAiSE'97, Barcelona,
Catalonia, Spain, June 16-20, 1997. 1997. Berlin. LNCS. 1250. pp 203-216.
7. Ernst, A. et al, 2006. Tool Support for Enterprise Architecture Management - Strengths and Weaknesses.
Proceedings of the 10th International Enterprise Distributed Object Computing Conference, pp. 13-22.
8. Lankhorst, M., 2005. Enterprise Architecture at Work: Modelling, Communication and Analysis. Springer.
9. de Lara, J. and Vangheluwe, H., 2002. Using AtoM3 as a Meta-CASE Tool. Proceedings of the 4th International
Conference on Enterprise Information Systems (ICEIS'02), pp. 642-649.
10. No Magic, Inc. MagicDraw UML, 2008. http://www.magicdraw.com
11. Jonkers, H. et al, 2003. Towards a language for coherent enterprise architecture descriptions. Proceedings of the 7th
IEEE International Distributed Object Computing Conference, pp. 28-37.
12. Jonkers, H. et al, 2004. Concepts for Modelling Enterprise Architectures. International Journal of Cooperative
Information Systems, vol. 13(3), pp. 257-287.
13. McGovern, K. et al, 2003. A Practical Guide to Enterprise Architecture. Prentice Hall PTR.
14. OMG, 2006. Meta Object Facility (MOF) Core Specification, version 2.0. http://www.omg.org/docs/formal/06-01-
15. OMG, 2007a. Unified Modeling Language (UML), Superstructure, version 2.1.2.
16. OMG, 2007b. Systems Modeling Language (SysML), version 1.0. http://www.omg.org/cgi-bin/doc?formal/2007-09-
17. OMG, 2008. Business Process Modeling Notation (BPMN), version 1.1.
18. Selic, B., 2007. A Systematic Approach to Domain-Specific Language Design Using UML. Proceedings of the 10th
IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing, ISORC 07,
19. Silingas, D. and Butleris, R., 2008. UML-Intensive Framework for Modeling Software Requirements. Proceedings of
the 14th International Conference on Information and Software Technologies, IT 2008, Kaunas, pp. 334-342
20. Tolvanen, J. et al, 2007. Advanced Tooling for Domain-Specific Modeling: MetaEdit+. Proceedings of the 7th
OOPSLA Workshop on Domain-Specific Modeling, Finland, pp. 243-250.
21. Zachman, J.A., 1987. A Framework for Information Systems Architecture. IBM Systems Journal, vol. 26, no. 3, pp.
22. Zhang, K., Zhang, D.Q., and Cao, J., 2001. Design, Construction, and Application of a Generic Visual Language
Generation Environment. IEEE Transactions on Software Engineering, vol. 27(4), pp. 289-307.