TOWARDS CUSTOMIZING UML TOOLS FOR ENTERPRISE ARCHITECTURE MODELING Darius Silingas Vytautas Magnus University, Faculty of Informatics, Department of Applied Informatics Vileikos st. 8-409, LT-44404 Kaunas, Lithuania,
[email protected]
Rimantas Butleris Kaunas University of Technology, Department of Information Systems Studentu st. 50-313a, LT-51368 Kaunas, Lithuania,
[email protected]
ABSTRACT 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 domainspecific 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. KEYWORDS
Enterprise architecture, UML, domain-specific modeling, customization, MagicDraw
1. INTRODUCTION 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 domainspecific 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. M3
MOF
DSML Definition defined using
M2
extends
UML
transforms into metamodel Customizations
restricts
defined using
M1
UML Profile
User Model reflects
M0
Real World
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
Tag CustomizationTarget
Purpose Meta element that needs to be customized – typically a stereotype, but may also be standard UML meta-class 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 namespace PossibleOwners The meta elements that are allowed to contain the customized element SuggestedOwnedDiagrams Diagrams that make sense for modeling some
SuggestedOwnedTypes
UsedUMLProperties AllowedRelationships TypesForSource TypesForTarget
aspects of the customized element and therefore should be suggested in repository browser’s contextual menu Types of model elements that should be suggested for creating in the namespace of the customized element Which standard UML properties should be used in addition to the custom stereotype properties What relationships should be allowed connecting to the customized element What are possible types to be used as source elements for the customized relationship 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 relationship matrix; 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. objectoriented 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 MODELING 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.
What (Data) How (Function) Where (Network) Who (People) When (Time) Why (Motivation)
Business Model (UML-based DSL) Concepts
System Model (UML) Classes, Objects
Business Processes
Activities
Organization Units, Projects Employees, Job Roles Business Events
Components, Deployment Nodes Actors
Business Goals
Use Cases
Events
Technology Model (UML-based DSL) Relational DB Schema, XML Schema Algorithms, GUI Navigation Technology-Specific Artifact Deployment Identity Management User Actions, System Events -
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).
Employee [Class]
skills 1..*
first name : String last name : String e-mail : String phone : String manager
team
Skill [Class]
Role [Actor]
requiredSkills 1..*
description : String
instructions : String
1..*
1
OrganizationUnit [Package]
suppliers
title : String address : String description : String 1
1..* clients
Project [Package]
project 1
ProjectRole [Actor]
OrganizationRole [Actor]
start : date end : date description : String
1..* department
Organization [Package]
Supervise [Dependency]
id : Integer VAT code : Integer type : OrgType
start : date end : date
RoleAssignment [Dependency] start : date end : date workload : float
Figure 3. UML profile for organization structure modeling
EmployeeCustomization allowedRelationships = RoleAssignment Supervise customizationTarget = Employee hideMetatype = true possibleOwners = OrganizationUnit
Darius Šilingas
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
UML 2
Technical Writing
Requirements Analysis
Presentation
openArchitectureWare
OCL 2
MDA
Java Programming
English
AndroMDA No Magic Europe Professional Services Training Andrius Armonas Darius Šilingas Ruslanas Vitiutinas Custom Development Sales MagicDraw Development Enabling Services Marketing
Figure 6. Sample of employee to skills association matrix, which can be set up as automatically updated artifacts in MagicDraw UML modeling environment
5. CONCLUSIONS 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.
ACKNOWLEDGEMENT The work is supported by Lithuanian State Science and Studies Foundation according to High Technology Development Program Project "VeTIS" (Reg.No. B-07042).
REFERENCES 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-18745, 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-0101.pdf 15. OMG, 2007a. Unified Modeling Language (UML), Superstructure, version 2.1.2. http://www.omg.org/spec/UML/2.1.2/Superstructure/pdf 16. OMG, 2007b. Systems Modeling Language (SysML), version 1.0. http://www.omg.org/cgi-bin/doc?formal/2007-0901 17. OMG, 2008. Business Process Modeling Notation (BPMN), version 1.1. http://www.bpmn.org/Documents/BPMN%201-1%20Specification.pdf 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, pp. 2-9. 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. 276-292. 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.
