UML Metamodeling for Enterprise Architecture

UML Metamodeling forEnterprise Architecture

by Terry Merriman, Senior Consultant,Cutter Consortium

Modeling your enterprise architecture in a consistent, concise, and

precise manner so that all of the stakeholders’ views are addressed

can be a formidable task. Making that architectural model readily

available and understandable to those who need it can be even more

challenging. This Executive Report discusses an approach to doing

so in a UML model that is guided by a metamodel refined for that

purpose.

Enterprise Architecture

Vol. 11, No. 6

THIS MONTH’S AUTHOR

Terry MerrimanSenior Consultant, Cutter Consortium

IN THIS ISSUE

3 Goals of the Metamodel

4 Architectural Views

18 Leveraging Your Profile

18 Conclusion

19 Endnotes

19 About the Author

1©2008 Cutter Consortium Vol. 11, No. 6 ENTERPRISE ARCHITECTURE

UML Metamodeling for Enterprise Architecture

Some of the hot topics being discussed today regardingenterprise architecture include business-IT alignment,agile development, and architectural conformance. Allof these, however, are impossible without the timelyavailability of knowledge. Ask yourself the followingquestions:

How can you determine whether the business andIT systems are aligned if you do not have a clearunderstanding of each?

How can you develop systems quickly if you do notknow what you already have on which to build?

How can the development effort conform to archi-tectural principles if those principles are not readilyavailable and easily applied?

No matter what architectural guidelines you apply orwhat development methodology you practice, withouta systematic, well-thought-out approach to capturingthe information needed about the business and IT sys-tems, you are doomed to, at best, unsatisfactory resultsand, at worst, failure. Unfortunately, it seems the oddsare stacked against you for numerous reasons.

There are several modeling tools in the architecturespace from which to choose. There are tools that are spe-cialized for business modeling, tools specialized for thecity planning approach to enterprise architecture, toolsspecialized for design and development, and some toolsthat do all three well. If using more than one tool, it isadvantageous for them to intercommunicate. If the dif-ferent tools do not interoperate well, it becomes difficultto see the connections among the different models. Thisleads to a disconnect right where a connection is neededmost. If one tool is used to model the business, a secondtool is used to model the enterprise architecture, and athird is used for project development, then there may beno way, other than through visual inspection, to ensurethat the business concepts are properly addressed by thearchitecture and that development teams are adhering tothe architectural principles.

For this reason, it is beneficial to find a tool that canprovide all of the different views that you require.

www.cutter.comEXECUTIVE REPORT 2

Sometimes this may not be possible for nontechnicalreasons, for example, when departments responsiblefor the different views select different tools. If usingone tool throughout your organization is not possible,it is important to make sure that the tools you do useconform to such modeling standards as the OMG’sXML Metadata Interchange (XMI) standard (see sidebar“Real-World Benefits of XMI”). This will permit theexchange of data between the different modeling tools.You may still have to do some “fix-up” work and main-tain information in more than one place, but it is stillbetter than having to redo all of the work manually.

Sometimes a tool may not do quite what you want it to.It may have a closed approach that constrains the wayyou can create your models and relate the informationwithin them. Some design tools forget that they aredrawing tools. They tend to force the placement of ele-ments and relocate them, seemingly at random. Lack ofa good user interface is a big reason that some designersgo back to something like Microsoft Visio. In doing so,they lose all of the benefits that a repository-basedmodeling tool provides, but their anger subsides whenthey do not have to redraw a diagram every time it isopened. Another hurdle, particularly for groups new toenterprise architecture and trying to sell it to manage-ment, is the high cost of some tools.

One question I’m often asked is whether or not UMLcan really be used to capture enterprise architecture.The reason, I think, that the question is even asked isbecause out-of-the-box UML provides such a diversityof diagrams, model element types, and approaches thatit may seem overwhelming, providing confusion ratherthan clarity. If you were to give a UML modeling tool tofive designers and ask them to provide a solution to the

same problem, I’m sure you would get five very differ-ent solutions. My original premise set forth above aboutthe need for the timely availability of knowledge cannotbe attained if there is no consistency in the capturedinformation. Rather than ending up with a beautiful,well-conducted symphony, all you will have is thesound of an orchestra tuning up.

Fortunately, the OMG built into the UML standard thecapability to extend the UML metamodel (the under-lying structure of UML). These extensions use profilesand tagged values to enable a more focused approachfor a given modeling domain. This Executive Report dis-cusses an approach for UML modeling that addressesthe different architectural views required to satisfy allof the stakeholders of an enterprise.1 It can be used tohelp ensure business and IT alignment, provide agility,and make the path to architectural conformance theeasy path for development teams, as well as other goalsthat you might set for architectural modeling.

In this Executive Report, I will demonstrate an organizedapproach for modeling enterprise architecture thatincludes a business architectural view, a set of ITarchitectural views, and the architectural principles,objectives, and guidelines necessary to ensure thatdevelopment efforts proceed down the path prescribedby company visionaries and practitioners. A key aspectof these guidelines includes a UML metamodel foryour specific approach to enterprise architecture thatis flexible, powerful, and yet easy to use for designers.

Many development shops these days already have aUML modeling tool. This report explains how to lever-age that tool to model your enterprise architecture usingmetamodeling to extend UML to make that effort moreefficient and consistent. The examples for this reportwere captured in a framework and reference modelbuilt on Sparx Systems’ Enterprise Architect (referred toas Sparx EA in this report) but can apply to most UMLmodeling tools that adhere to the UML 2.1 standard. Iuse the framework and reference model for training andmentoring purposes as well as to seed client efforts tomodel the enterprise.2 The reference model captures thearchitecture and project designs for a fictitious companythat provides sports club management services to onlineclients via a set of applications collectively called theSports Club Management System (SCMS). The frame-work consists of:

A package layout for the architectural views andarchitectural guidelines

A user-modifiable metamodel that is used to buildthe UML profiles that provide the model elementsfor the views

REAL-WORLD BENEFITS OF XMI

I recently consulted with the application architecturedepartment of a large pharmaceutical company. Whilereaching out to one of the development teams, the teamasked me to incorporate some of the concepts I wasespousing into its development. The problem was I didn’thave access to the modeling tool the team was using. By thetime the team could have procured a licensed copy for me,its deadline would have passed. We solved the problem bymy using a design tool I did have and then exporting mywork using the XMI export capabilities. The team’s tool wasable to import XMI, so the department was immediately upand running with my designs.


Tagged values that capture information about themodel elements

Quick links that provide connections specific to themodel elements involved

Document-based and tabular-based reports to pro-vide a consolidated view of the information capturedin the model (the reporting part is very tool-specific)

Organizations considering enterprise architecture mod-eling tools, especially those already using a UML toolfor designing their project solutions, may want to con-sider this approach as a prototype to help them fullyunderstand their needs prior to selecting a high-costmodeling tool. You may even find that this approachfully satisfies your needs.

GOALS OF THE METAMODEL

Before we can talk about how to create a metamodel, weneed to determine a couple of things. For example, whatare the goals for modeling the enterprise architecture?Each organization may have a different reason for mod-eling. Some organizations, for the most part, purchasecommercial applications and provide the integrationbetween them. Such was the case with Subaru, withwhom I’ve worked in the past.3 For that company,some of the goals were to determine:

How many applications were performing the samebusiness functionality with the goal to eliminate asmany applications and required licenses as possible

How many applications were at risk due to lack ofsupport by the vendor or due to lack of support forrequired technology components; for example, oper-ating systems, so the company could address the riskbefore problems arose

What interdependencies existed among the applica-tions so the company could determine the impact ofreplacing one application with another

All of the interfaces that had been developed to com-municate with a key software system; for example,SAP, in order to consolidate them to simplify mainte-nance (in one case, the number was reduced from inthe hundreds to in the tens)

Other organizations build their own applications orpurchase commercial applications and then take overtheir maintenance in order to modify them accordingto their specific needs. These organizations will want toknow such things as:

The interfaces available for communicating acrossthe applications

What business services the applications makeavailable

What IT services are required and available tosupport the business applications

What components have already been deployedand can be reused for new projects

Even organizations that primarily build their applica-tions have a wide variation of needs when it comes toapplication architecture (more on this later). For exam-ple, a company that develops a suite of applications thatshould perform similarly and share common compo-nents on a single computer, such as the Microsoft Officesuite, will have a different application architecture thana company developing distributed systems that exist onservers throughout its intranet.

One of the key purposes for modeling the enterprisearchitecture for any organization is to fully satisfy theconcerns of the various stakeholders in the developmentprocess. For companies such as those in the finance andinsurance industries, and many others as well, we findthe following stakeholders:

Senior business managers who develop the companyvision that the IT systems are to support

Businesspeople who use the systems to conductdaily work

Auditing and compliance personnel responsible forensuring the systems obey all internal and externalmandates

Senior IT managers who have the vision of howthe technology can support the business needs

Senior architects responsible for realizing that visionand ensuring compliance to it

Development teams who need to know the architec-tural standards to which they should design theirsolutions

Information architects who need to know the struc-ture, constraints, and distribution needs of the data

Even organizations that primarily build their

applications have a wide variation of needs when

it comes to application architecture.


Database architects and infrastructure personnelwho need to determine capacity and throughputrequirements

Quality assurance personnel who need to ensurethe systems meet functional and nonfunctionalrequirements

Operations staff who need to monitor the deployedsystems and ensure they stay “up”

In order to satisfy all of these stakeholders’ needs, onemust take a divide-and-conquer approach by setting upvarious architectural views as prescribed by such stan-dards as The Open Group Architecture Framework(TOGAF), the Reference Model for Open DistributedProcessing (RM-ODP), the Rational Unified Process(RUP), and others. The UML framework we use is theresult of applying the concepts from these standards toreal work at client sites and helps to ensure consistencywithin and across the various views. The following sec-tion describes each of these views and shows some exam-ple diagrams4 to set the context for the metamodeling.

ARCHITECTURAL VIEWS

The concept of architectural views has been around fora while now. My first introduction to it was from theISO standard, RM-ODP. Each architectural standard hasits own variation of these views, but for the most part,they are quite similar. The architectural views that willbe mentioned in this report include seven major viewsalong with some minor views within those larger ones.The major views are business, application, information,integration (or service), technology, deployment, andoperational. A brief example of each is provided in thefollowing sections along with some representative dia-grams. These will help set the stage for how we willwant to set up our metamodeling.

Business Architecture

Business architecture is where it should all begin,although it often does not. An approach driven only byrequirements eliminates the possibility of confirmingwhether the IT solutions are really aligned with the cur-rent and future state of the business. Many of the thingsfound in the business architecture exist within corporatedocumentation, but finding them is another thing.Putting mission statements, business principles andobjectives, and the like into a common model that canbe exported to Web pages on the company’s intranetcan provide valuable insight into the direction in whicheveryone should be moving. For our purposes, businessarchitecture is composed of:

Business principles — which provide high-levelguidance in everything that is done by and in supportof the business. This is where business-IT alignmentbegins.

Business objectives — which provide the high-level business needs and are often categorized by asubdomain within the enterprise. The objectives arerefined into detailed requirements and use cases.

Business context — which shows the external rela-tionships between the enterprise and its customers,trading partners, vendors, and so on. We place theexternal entities into context by having a human/organizational group and a system group. This helpsus understand which external entities we may workwith but to whom we do not connect versus thosewith which we will have electronic communication.

Business organization — which shows the internaldepartmental structure of people, departments, androles within the enterprise. The responsibilities ofeach actor/role within the organization can be mod-eled using a feature of Sparx EA that allows you tocapture the requirements of various model elements,in this case, actors. We use this to provide context forthe actor and to informally map these responsibilitiesto the use cases that represent the automation of theseresponsibilities. If a requirement feature is not avail-able within the UML tool, you may use operations orattributes to capture the responsibilities.

Business functions — which are decomposed by subdomain down to the activities that can be strungtogether to create business processes.

Business processes — which perform the activities ofthe business and affect the business information (seeFigure 1). Model elements that have an infinity-likesymbol at the bottom right represent composite ele-ments that have diagrams and components withinthem. This provides a drill-down capability. You willnotice several model elements called policies. Theycontain the business rules that govern the actionstaken within the processes. I will more fully explainthe policies in the business policy section below.

Business information — which describes the ele-ments (entities such as customer; and artifacts suchas forms) that the business users deal with on a dailybasis and the relationships among these elements(see Figure 2). Just as business policies govern theactions within the business processes, business poli-cies can also govern the state of the business entitiesand their relationships.


Business policies (sets of related rules) — which gov-ern the business information, their relationships, andthe processing that affects the information. This veryimportant piece of the business architecture is oftenmissing. I have found that, by capturing policies in thebusiness model and dealing with them as indepen-dent model elements throughout the IT architecturemodel and project designs, they can be handled moreeffectively and traced from business statement to ITimplementation to ensure their compliance. Figure 3shows the League Eligibility Policy with its variousrules governing whether a player is eligible. The rulescome in three flavors (as prescribed by RM-ODP): per-missions, which indicate when something is allowed;obligations, which indicate that something is required;and restrictions, which indicate when something isnot allowed. As mentioned previously, tagged valuesare a UML extension capability that lets you captureadditional information about a model element. For

business rules, we are concerned with how volatilethey are. Therefore, we have added a “volatility”tagged value that can have a value of high, medium,or low. Rules with low volatility seldom change andcan be handled differently than those that have a highor medium volatility.

You should note that the League Eligibility Policy thatis shown here is also shown in the earlier figures. Thisshows very explicitly what that policy governs and inwhat processes the rules of the policy must be enforced.

Of course, it may not be realistic to capture all of yourbusiness rules in a UML model. This is a good reasonfor organizing them into policies and using the policiesin the model.

Business Requirements

There are three types of requirements in this view: func-tional requirements, nonfunctional requirements, and

Figure 1 — Top-level business processes.


use cases. Capturing the nonfunctional requirementspermits associating them visibly with the processes orentities the requirements affect. Showing that a certainbusiness process must be accomplished within a setamount of time makes that nonfunctional requirementeasily available to any projects that may work onthat process. (See sidebar “Setting the Context forRequirements.”)

Understanding the Big Picture

The top-level diagrams from each of these businessarchitecture subviews, along with their textual docu-mentation, should be sufficient to understand what thenature of the company’s business is all about. Theyshould be mandatory reading for anyone joining thecompany, regardless of whether they are in the businessor IT side of the house.

Application Architecture

The application architecture view is a bit different fromthe others in that it is the main focus of development

Figure 2 — Top-level business domain model.

Figure 3 — League Eligibility Policy.


and integration efforts and is usually the most volatileof the views. It is also the view that is most dependenton the other views.

For larger enterprises, we normally break down theapplication architecture by subdomain. The applicationsand use case realizations, which we include in the appli-cation architecture, are categorized by the subdomainsthey support. The models of the applications show whatis available to be used by the realizations. The realiza-tions, in turn, show how the application components areused, in conjunction with other application componentsand IT services, to satisfy the business processingdescribed by the use cases.

Depending on the need, we then break down theapplication and realization models into several differentsubviews that show the mapping from the applicationarchitecture to the other views. You will want to refer tothe descriptions and diagrams of the other architecturalviews that follow this section.

Application Architecture: Functional View

This subview deals with applications as black boxes thatsupport business functions and processes and dependon other applications via well-defined interfaces. Wecapture the logical interactions among the applicationsto determine their dependencies. This helps ensurethings don’t get broken when upgrading or replacinga given application.

Mapping the applications to the business functions theyserve helps us to identify what application duplicationsexist, which leads to the possible reduction of the appli-cation count, development effort, and/or license fees.The functional view shown in Figure 4 comes from theSubaru case study.

Application Architecture: Component View

This lower level of abstraction deals with the com-ponents of the applications and their interfaces. Thecomponents are shown deployed into the logical

The importance of having the business architecture to pro-vide context for requirements is something I often see duringrequirements capture. I once joined a project that had startedabout two months earlier. The project team faced numerouschallenges. The company was still going through the throes ofa merger with the two companies based in separate states. Notonly was there a physical distance gap, but there was a gap inthe way their products fit into the marketplace. The team hadbeen holding almost daily sessions for two months with about20 people in a teleconference room in one state and 20 in theother. The participants included line-level business managers,front-line business users, project management, business analysts,the lead architect (me), and some of the senior developmentstaff. Unfortunately, in the two months time that preceded myarrival, the team had not been able to accomplish very much.The team members had finally determined they needed to betterunderstand the end-to-end business process before they couldtry to address the requirements of the project.

When I first got there, the first question I received was whetherthey should in fact do business process modeling. I heartilyendorsed the approach and joined in the meetings. As theytried as a group to walk through the flows, there was constantdisagreement about what should be done, and little progresswas made. Finally, by the end of my first week, I was startingto see what the problem was. They were talking process buthadn’t defined any of the information objects to which they

kept referring. The term “product” was used over and over again,but there seemed to be a lot of contention over its use.

I got together with the development team, who had more domainknowledge than I did at that time, and worked with the membersto create an initial business domain model that not only definedthe different terms (business entities) the larger group wasbantering about, but also defined the relationships among thoseterms and some rules that governed those relationships. To addeven more context for the businesspeople, we created a diagramthat showed the major entities and the actors responsible forworking on those entities. We referred to this as an enhancedglossary. In doing this, we confirmed that different people hada different definition for product. Group “A” thought that prod-uct meant a category of offerings that had the same basiccharacteristics. Group “B” thought it was a specific offering thatincluded all of the allowable options from which a customer couldselect. Group “C” thought it was a configured offering with all ofthe selections made by the customer. Group “D” thought it wasthe specific offering that a customer configured for its members inone locale versus another. Group “E” thought it was all that plusthe state mandates that dictated the availability of certain offeringsalong with their options. All in all, it was a confusing mess withlittle wonder why progress was not being made.

We presented our model to the businesspeople with the resultthat they looked at each other and made comments like, “Oh,that’s why you said what you did!”

SETTING THE CONTEXT FOR REQUIREMENTS


Figure 4 — Application architecture: functional view.

Figure 5 — Application architecture: component view.


distributed environment along with their interface inter-actions (see Figure 5). It incorporates elements from theinformation, service, and integration architectural viewsto show how the components interact via the architec-tural styles and patterns adopted by the enterprise. Theblack box logical connections from the functional viewmay actually be rather indirect in a distributed environ-ment. The component view shows how the componentsof different applications may communicate, for exam-ple, through an Enterprise Service Bus. The dependen-cies among applications are lost at the component level,which is the real purpose of middleware. However,the direct connections of the functional view are stillnecessary to show the dependencies among applica-tions. Even though the component view is at a lowerlevel of abstraction than the functional view, it is still ata logical level. Its components get mapped to the tech-nology that realizes them in the technology subview.

Application Architecture: Behavioral View

The behavioral view uses activity and/or sequencediagrams to show the behavioral interaction of the com-ponents (from the component view) of a use case real-ization. Activity diagrams are helpful if there is a lot ofdecision logic to be portrayed. Sequence diagrams arebetter when you want to depict the actual messages thatpass between the components or to define the interfaces.

Application Architecture: Information View

This is a subset of the full information architecture andincludes only those items that are germane to the appli-cation or use case realization. It includes any dataand/or data structures that are used to communicateamong the application and IT components.

Application Architecture: Technology View

This view maps the applications and components totheir technology requirements, which allows us tounderstand the impact of upgrading or replacing oldertechnologies. Knowing which applications are unsup-ported or which applications are using unsupportedtechnologies helps us to understand their level of risk.

Application Architecture: Deployment View

This view shows where the application components aredeployed. Unless the application or realization is usingnew components, new technology, or a new techniquethat we want to highlight, we often defer to the dia-grams in the deployment architecture.

Application Architecture: Operational View

This view describes what is necessary to installthe application, its components, and data (or themodifications/updates to these) into the data center.It should include what must be done to back themout should problems arise.

Information Architecture

Information architecture depicts the various databasesrequired to support the applications, their underlyingtable structures at the logical and physical level, theassociations among the tables, and the policies thatgovern the attributes and associations of the tables,which can often be implemented as stored procedures,putting them close to the data source.

Integration or Service Architecture

The service architecture depicts the business servicesavailable to the applications as well as IT services suchas logging, security, and distribution (see Figure 6).These are used in the application architecture’s compo-nent view. The IT view of the service architecture is anexpansion of what we previously called the integrationarchitecture, incorporating all of the types of IT servicesrequired for an open distributed processing environ-ment, including coordination, integration, management,repository, and security services. We use the same sub-views in the application architecture for any servicesthat we develop inhouse.

Technology Architecture

Technology architecture shows all of the technology com-ponents required to support the business applications.They are first categorized into hardware versus software,with each broken down into subcategories. Among thehardware components are nodes and devices such asPCs, workstations, servers, switches, firewalls, and diskarrays. The software components include operating sys-tems, integration and middleware software, app servers,DBMSs, and programming languages. These are linkedto the applications that require their presence to operate.

Deployment Architecture

This view shows the physical nature of the enterprise(see Figure 7). Within it, we depict:

The sites where the enterprise has hardware located

The technology partners that are used to supportthe extra-Internet aspect of dealing with customers,trading partners, and other external entities


Figure 6 — IT service architecture: Enterprise Service Bus.

Figure 7 — Server deployment.


The deployment of applications, application compo-nents, business and IT services on PCs, servers, andmainframe computers

The network topology that connects the nodestogether, including PCs, servers, firewalls, switches,load balancers, and other network devices

Operational Architecture

This view depicts the applications and components thatare used to keep the data center running. It includesnetwork and heartbeat monitoring, as well as failoverservices.

Architectural Guidelines

One of the things I push hard for is having the archi-tectural principles and guidelines readily available todevelopment teams. The four categories of things wecapture in the architectural guidelines are:

1. Architectural principles — which discuss how cer-tain aspects of system design should be handled. Anexample would be that the distribution transparen-cies expounded in RM-ODP should be considered forany system designs: namely, access, failure, location,

migration, persistence, relocation, replication, andtransaction transparencies.

2. Applied architectural patterns — which show whatpatterns have been selected to guide development.IBM has done a great job of identifying a hierarchy ofe-business patterns that provide architectural stylesthat help implement different business approaches.It has provided a complete treatise on this on itsRedbooks Web site.5 We have taken those patternsand, in some cases, extended them downward tothe architecture and design patterns found in DesignPatterns6 and the Pattern-Oriented Software Architectureseries.7 Figure 8 shows which of the IBM patterns areto be used for SCMS as guidance for development.Drilling down into the decomposition pattern yieldsFigure 9, which shows an example of one of the e-business application patterns. Figure 9 shows howmodel elements can be “dressed up” to create Visio-like diagrams that many people like. The classes aredisplayed using an alternate image, and the responsi-bilities are simply each class’s requirements that werecaptured in their properties dialog box.

3. Architectural transitional goals — which lay out thesteps necessary to get to a future state, for example,

Figure 8 — Applied e-business patterns.


introducing new technologies. These steps shouldinclude the staged projects that may incrementallyimplement the technology and share the cost ofdoing so.

4. Architecture resources — which includes designpatterns that can be applied to the modeling effortand the metamodel used to create the profiles foreach architectural view.

Now that we have taken a look at the various architec-tural views, let’s look at what is necessary to create themodeling tools to help us capture the views in a consis-tent, easy manner.

The Mechanics of Metamodeling

Before we get into a discussion of how to build meta-models, perhaps a quick look at the end state will helpcrystallize why we do this. Figure 10 shows a partialscreenshot of three of the frames in Sparx EA.

On the right is the standard UML toolbox for thedeployment view. As you can see, the available modelelements are very generic. In the middle is the UML

resource frame that includes the UML profiles we havedeveloped with the technology architecture profileexpanded. As you can see, the model elements in theprofile are very specific to the kinds of technologywe want to model. You can also see the additional infor-mation we want to capture about the servers as taggedvalues shown within the server box on the left. We havefull control over all of the types of model elements wewant and the additional information we want to captureabout them by extending the UML metamodel.

Demystifying Metamodels

As fancy as the term may sound, a metamodel is simplya model. Models capture the problem or solution for agiven domain. The domain for a metamodel is model-ing. Models with which you may be familiar may dis-cuss such things as customers, orders, and products. A(meta) model of UML discusses such things as classes,components, activities, dependencies, associations, andaggregations. These, in turn, become the types of modelelements used to capture customers, orders, products,and such. Figure 11 shows a simplified extract from theUML metamodel.

Figure 9 — Decomposition application pattern structure.


In it, you can see a number of classes; namely, Classifier,Relationship, Association, StructuralFeature, Class, andOperation. Note that Class is captured as a class modelelement. The UML metamodel is often self-describing asshown here. You can also see that a Class may have zeroor more StructuralFeatures, which are its attributes.Furthermore, a Class may have zero or more Operations.What may seem more confusing at first is that Asso-ciation, which is a Relationship, that is, a connectorbetween two elements, is also captured as a class. Thesame goes for Dependency, Aggregation, and other con-nectors. In fact, all of the things you use in a UML model— Activity, Actor, Comment, Event, Generalization,Attribute, and Operation — are metamodeled as a class.

UML allows you to extend its underlying metamodelto make it more focused on a given domain. However,before getting into full-blown metamodeling, let’s firstreview a lighter version of extending UML via ad hocstereotypes and tagged values.

Stereotypes and Tagged Values

Stereotypes provide a mechanism to refine the meaningor context of a given model element. They are notated byputting guillemets around the name of the stereotype; for Figure 10 — UML toolbox versus UML profile.

Figure 11 — UML extract.


example, <<entity>>. UML defines three analysis stereo-types that help provide additional meaning to classes:A class with an <<entity>> stereotype is something thatis concerned more about data and the control of thatdata than it is about process. A class stereotyped as<<control>> is more concerned about process. A<<boundary>> class represents something at the edgeof the system being modeled, which interacts with thingsexternal to the system.

The designer can also create stereotypes. The concept ofa control mentioned above is pretty abstract. To refine itfor an open distributed processing environment usingan n-tier approach, the following stereotypes can beintroduced to indicate the type of interaction providedby the control object:

<<Service>> — a control that does not maintain thestate of the interaction beyond a single invocation

<<Session>> — a control that maintains the state ofthe interaction through multiple invocations with theinitiation and termination of the session controlled bythe client

To place a control into the proper tier in a platform-independent context, the previous stereotypes can befurther refined to:

<<Presentation Session>> — a session that controlsthe interaction with the user

<<Work Session>> — a session that controls thesequencing of actions required to perform the workof a use case realization; a Work Session can interactwith Presentation Sessions, Business Services, ITServices, and other addressable components withinits deployment space

<<Business Service>> — a service that providesaccess to and control over reusable data andprocesses by interacting with enterprise resourcessuch as databases and back-end applications aswell as extended enterprise resources, for example,connections to trading partners

<<IT Service>> — a service that provides aspectfunctionality, such as logging, security, service discovery, and transaction control

Now, instead of simply seeing a class with a name,you can get the full context of what type of processingthe class should do as well as its location within thedistribution tiers. Furthermore, you can decide whatinteractions among the stereotyped classes will be per-mitted. You may not want a <<Presentation Session>>to directly invoke a <<Business Service>> but ratherhave the <<Work Session>> make that call. Ultimately,these platform-independent stereotypes can be mappedto components stereotyped for the platform-specificmodel to be created. A particular <<Work Session>>may be mapped to a <<JSP>> for one platform or to an<<ASP>> on another. Pattern-generated transforma-tions can automate this process to a large degree. Infact, there are a number of UML profiles that are avail-able for different domains, for instance, for EJBs, forbusiness process modeling, and so on.

Stereotypes can be used for model elements otherthan classes. For example, you can add a stereotype toa dependency connection. In the application architec-ture, functional view, we have classes stereotyped as<<Application>> interacting with each other. Theseinteractions demonstrate dependencies between theapplications. We further refine the interactions (thedependencies) based on the conceptual type of inter-action; namely, <<Data Flow>>, <<Shared DB>>,<<Sync Request>>, or <<Async Request>>. These toocan be transformed into the underlying technologystructures of a platform-specific model.

Defining the different types of things you want tomodel, capturing them as stereotypes, and defining the“rules of engagement” among these model elements isthe first big step to creating your metamodel. The nextstep is deciding what information you want to captureabout these stereotyped classes. This is done usingtagged values.

Tagged values allow you to capture information abouta model element that UML does not provide. You maywant to know the beginning and termination servicedates for a given <<Application>>. You may wantto capture the various service-level requirements fora <<Business Service>>, for example, average andmaximum execution times. Tagged values come ina name/value pair. You provide the name of the tagand then the value.

UML allows you to add stereotypes and tagged valuesto a model element in a very ad hoc manner. This canlead to inconsistency and confusion across designteams. The clarity stereotypes can add to a model isquickly lost when those stereotypes are obtuse andundefined. A well-defined, well-documented set of

Stereotypes can be used for model elements

other than classes. For example, you can add a

stereotype to a dependency connection.


stereotypes and their tagged values should be providedto all teams. Better yet, they should be used to create ametamodel that can be controlled by the modeling tool,with rights to manage the metamodel given to thoseresponsible for it. With such a metamodel in place, themodeling tool can now provide guidance on the model-ing standards embodied in the metamodel and makeconforming to those standards easier than not doing so.

Background on Metamodels

For many of you, the term metadata may be more famil-iar than the term metamodel. Metadata is data aboutdata. This concept has been used for a long time. Forexample, some data transmissions include informationdescribing the content of the data. When transmitting acomma-separated list of data elements, the first line tobe transmitted may have the names of the fields. XMLextends this concept by allowing you to describe thedata in further detail. Just as metadata is data aboutdata, a metamodel is a model of a model or, in otherwords, a model of how you model a particular solutionspace. The UML metamodel describes UML, providingthe different model elements within UML and the con-straints regarding how they can be used.

Modeling Levels

A metamodel represents one level of abstraction abovethe “normal” modeling that designers are used to. Infact, there are actually four levels of models that havebeen developed by the OMG for its modeling standards.Levels 0 and 1 are the familiar ones. Level 1 representsthe templates for the things you wish to model, whileLevel 0 represents the actual instances. Database model-ing provides a good example. When designing a rela-tional database, you decide the names of the tables itwill contain and the columns that each table will have.A database may contain a Customer table with columnsfor FirstName and LastName that can contain charactersand a Years integer column for how long the individualhas been a customer. This represents Level 1. The actualdata that goes into the Customer table — for example,“John," “Smith," and “1” — represents Level 0.

Level 2 is where metamodeling comes into play. Thisrepresents information that describes the Level 1 arti-facts. In our database example, Level 2 would model aTable and a Column as well as the association betweenthem indicating a Table can have one or more Columns.The relationship between Levels 2 and 1 is the same asthe relationship between Levels 1 and 0. The higherlevel is the template and the lower level contains theinstances. Level 2 has the templates for Table and

Column, and Level 1 contains the instances of Level 2,for example, the Customer table and its FirstName,LastName, and Year columns. At the same time, Level1 is the template for Level 0. Level 1 indicates whatcolumns a Customer has, and Level 0 contains theinstances as shown above. Level 3 is a metametamodelcalled the MetaObject Facility (MOF). MOF is used tomodel numerous approaches to modeling, providinga consistent approach so that information from thevarious models can be shared. Fortunately, the MOFis self-describing so we do not need a Level 4!

As mentioned previously, all of the model elements thatyou use in Level 1 are modeled as classes in Level 2.Actually, they are referred to as metaclasses and aregiven a <<metaclass>> stereotype as shown in Figure 12(we will refer to Figure 12 repeatedly in the followingdiscussion). The metaclasses are colored darker to helpthem stand out.

Building the Metamodel

Once you have decided what stereotypes you need andwhat tagged values you want for each, you are readyto extend the UML metamodel for your needs. For pur-poses of illustration, we will use the following scenario:

We want to capture our business applications alongwith their lifecycles. We also want to know whetherthey are currently supported by the vendor.

We want to capture the logical dependencies betweenthe applications that are manifested as data transfersbetween them, data in shared databases, and synchro-nous or asynchronous requests from one to the other.

We want to capture the technology components, forexample, operating systems and application servers,that the business applications require and what thesupport status is of these components.

With this information, we will be able to determinewhether an application is at risk, either because it isno longer supported by the vendor or because sometechnology component it requires is no longer sup-ported. We will know what other applications a givenapplication depends on in case we need to change anyof the applications. We will know what applications

Once you have decided what stereotypes you need

and what tagged values you want for each, you are

ready to extend the UML metamodel for your needs.


will be affected if we upgrade something in our tech-nology base.

In order to pull all this together, we first model ourenterprise architectural needs (in our case, the scenariopresented above) by modeling the stereotypes weneed and adding the required tagged values. Then wedecide from which metaclass each stereotype should beextended. Finally, for anything but a trivial effort, wedivide the extended stereotypes into UML profiles thatfit specific needs within our enterprise architecture.Figure 12 shows a refined model of the scenariodescribed above.

Note that each class that we want to introduce into themetamodel has a stereotype of <<stereotype>>. Thismeans that they will become the stereotypes that willbe available in our models that use the profile we will

create and will appear in the UML profile resourceframe. Also note that several of the classes are listed as{abstract}. This allows them to participate in the modelwithout being realized as stereotypes in our profile.

As you can see, we have done some refactoring to makethe model more efficient. While modeling this, we havedecided that we want to know installation and retire-ment dates not just for the business and IT software, butfor hardware components as well. Therefore, we haveused a generalization tree with ConfigurationItem, towhich we have added the dates and the supportStatus.These attributes become tagged values for the childtypes of ConfigurationItem, for example, Application,Operating System, DBMS, Server, PC, and so on, thatwe model. The third attribute, supportStatus, is oftype SupportStatusKind. This is an enumeration that

Figure 12 — Building a metamodel.


provides four possible values: VENDOR, INTERNAL,UNSUPPORTED, and UNKNOWN, with the defaultbeing UNKNOWN. Using an enumeration here will pro-vide a drop-down list when selecting the value, control-ling what gets entered for the supportStatus. The defaultvalue will be used when first creating a subtype ofConfigurationItem. Sparx EA provides another powerfulway of adding tagged values to your model. This isshown by the relationship between <<stereotype>>Software and <<stereotype>> Operating System. Both ofthese will become stereotypes in our model, but addingthe <<taggedValue>> relationship between them meansthat any model element with one of the child stereotypesof our Software stereotype will have a tagged valuecalled Operating System with a drop-down list of all theclasses in your model with a stereotype of <<OperatingSystem>>. This means that you can define the valuesa tagged value may have simply by populating yourmodel. Note that the first method using enumerationsputs control of the pick list in the hands of the metamod-eler, whereas the second method of adding tagged valueclasses puts the control in the hands of the designer.Which method to use may be a serious consideration.

You see in Figure 12 we have three stereotype special-izations of BusinessSoftware. This allows us to decideon what terminology we wish to use. I will talk aboutthis more in a little bit, but first note the compositionsbetween Software System and Application as well asApplication and Application Module. These composi-tions do not have any bearing on the profile that wegenerate from this diagram. However, they do providecontext and allow the metamodel to be a learning toolfor those that use its profiles. In this case, it shows thata Software System can be composed of two or moreApplications, and that an Application, if it belongsto a Software System, can belong to only one. Likewise,an Application can have zero or more ApplicationModules, and an Application Module must belongto one Application.

There is a second class hierarchy starting withLogicalCommunication. Under this, we define the varioustypes of logical communications that occur among theapplications.

The next step, extending the stereotypes from theunderlying metaclasses is also shown in Figure 12. Theextensions indicate what type of UML metaclass eachstereotype will be refining (extending). As you can see,we have decided that Software System will be realizedas Package, Application and Application Module asComponent, ITSoftware as Class, Hardware as Node,and LogicalCommunication as Dependency. The choice

of using Component for Application and ApplicationModule (deployable business software) and ITSoftwareas Class is arbitrary. We have found that using thisscheme makes the business software visually andtherefore readily distinguishable from the IT software.However, one may argue that elements like applicationservers should really be considered components. That’sthe beauty of the metamodeling approach. You caneasily change this by deciding what metaclass to extendfor any given stereotype.

Now that we have our diagram complete (for thisexample!), we need to create a UML profile from it.This process is tool-specific. With Sparx EA, it’s a sim-ple matter of choosing to create the profile from thediagram. Once the profile is created, it is imported intoeach model that will use it. As mentioned previously,we create a profile for each architectural view.

Modeling Your Modeling Process

Now that you have a little background on what meta-models are all about, let’s turn back to the issue of whatyou need to capture in your metamodel. As you can see,the flexibility with this approach is endless. This meansthat you can define model elements that fit with yourown jargon. I can’t tell you how many definitions of“application” and how many synonyms for it I’ve comeacross. Perhaps you use “program” or “module” orsome other term. The openness of metamodeling allowsthe tool to conform to your specific needs rather thanthe other way around. Organizing the different termsfor business software in this manner allows us to decideon terminology to use without affecting developedreports about the business software.

While being extremely beneficial, this flexibility can alsocreate chaos. Therefore, it is vital that you determineexactly what your purpose is in creating the metamodel.In other words, creating a metamodel is just like anyother project. You need to determine the requirementsbefore you can provide a solution. An integration shopwill have different needs than will a development shop.Modeling the architecture for strategic planning canlead to a different metamodel than one designed to cap-ture all of the design elements to make them availableto upcoming projects. Creating a metamodel that will

As you can see, the flexibility with this approach

is endless. This means that you can define model

elements that fit with your own jargon.


combine both strategic and tactical needs will providethe best long-term benefit, but of course will require thegreatest effort.

The following list shows just a few of the model ele-ments we use to extend the UML metamodel for thedifferent architectural views of an open distributedprocessing environment:

Business architecture — Business Function, BusinessEntity, Business Policy and its rule types Obligation,Permission, Prohibition; Governs, a relationship thatconnects Business Policies and Business Rules to theelements they govern, for example, Business Entities,Business Processes, and Business Services

Application architecture, functional view —Business Software, including Software System,Application, Application Module; LogicalCommunications, that is, Data Flow, Shared DB,SyncRequest, AsyncRequest

Application architecture, component view —Distributed component types, namely, BusinessService, IT Service, Presentation Session, WorkSession; Program, which represents internal code;protocol communications, such as FTP, S-FTP, ETL,HTTP, HTTPS, RPC, SOAP

Information architecture — Database, Table, Entity,Pick List

Technology architecture — App Server, DBMS, O/S,Web Server, CSU/DSU, PC, Firewall, Load Balancer,Router, Server, Server Frame, Switch

Deployment architecture — Ethernet, Fractional T3,T1, Network Adapter, TCP/IP

Many of these have tagged values to capture additionalinformation. As you can see, the model elements thatappear in each view are much more natural than usingthe base UML elements, such as class, component, anddependency. Another nice feature provided by Sparx EAis the ability to create specific quick links. A quick linklets you click on a model element, drag the quick linkarrow to a related element, and then select from anappropriate list of connectors. Using the metamodelingapproach, you can define what types of connectors are

permitted between two elements types. That includeslimiting the selection to the connectors you have definedin your metamodel. This helps ensure consistency.

LEVERAGING YOUR PROFILE

One of the strengths of Sparx EA is that it is built on anSQL repository. In fact, you can choose from numerousRDBMSs on which to deploy your enterprise model. Wetake advantage of this by using the flexibility of SQL toshow complicated relationships among the model ele-ments. By having consistent stereotypes, we can easilycreate reports that address how all of the various modelelements fit together. For example, we have createdreports that show all of the business and IT softwarethat is deployed on the various servers. We have cre-ated reports that show the dependencies between thevarious applications. By logical extension, when one ofmy clients moved from one data center to another, wewere able to create a migration strategy by seeing whatservers logically depend on each other due to the soft-ware deployed on them.

We have gone a step further to incorporate the elementsof the metamodel to the structure of these reports. Bymodifying our metamodel, we can modify the output ofour reports. For example, in Figure 12, you can see thatwe have Software System, Application, and ApplicationModule as specializations of BusinessSoftware. Anyreport that extracts BusinessSoftware uses this fact.Should we decide we also want to capture Programsas BusinessSoftware, we would simply need to adda new specialization of BusinessSoftware, namely,Program, regenerate our Application Architecture pro-file to include Program in our list of model elements forApplication Architecture view (extending it from theClass metaclass), and then any Programs we add toour model will appear in the BusinessSoftware reports.

CONCLUSION

UML is a very powerful and flexible standard. Oncetamed, it can provide a focused, consistent view of thevarious stakeholders’ needs. By incorporating all ofthese views, along with the supporting principles andguidelines, into one enterprise architecture model, thefull enterprise model can be deployed in a read-onlymanner for all to see; for example, as Web pages.Project teams can be given read-only access to many ofthe areas in the model while having full access to theirown project designs. Since all of the architecture designsare in the same tool the designers use, the designs are

Another nice feature provided by Sparx EA is

the ability to create specific quick links.


immediately available for projects. Having a well-thought-out metamodel not only provides guidanceand eases the modeling task, it also helps in extractinginformation from the repository.

ENDNOTES1This report builds on and extends concepts that were previouslydiscussed in the following Cutter Consortium publications:Merriman, Terry. “MDA in Action: An Anatomy of a Platform-Independent Model.” Cutter Consortium EnterpriseArchitecture Executive Report, Vol. 6, No. 1, January 2003;Rosen, Michael, and Terry Merriman. “An Application-CentricApproach to Understanding Architectures.” Cutter ConsortiumEnterprise Architecture Executive Report, Vol. 6, No. 12,December 2003; Merriman, Terry, Viktor Ohnjec, and BrianSimmermon. “Simplifying Subaru: An EA Case Study.”Cutter IT Journal, Vol. 19, No. 3, March 2006.

2The framework is used to seed the projects because clientsalways take advantage of the capability to modify it to theirspecific needs.

3”Simplifying Subaru: An EA Case Study.” See 1.4Figures 1-12 are copyrighted by OAD Consulting, Inc. In addi-tion, some supplemental diagrams for this report are also view-able at www.oadconsulting.com/UMLMetamodeling.html.

5IBM Redbooks (www.redbooks.ibm.com/abstracts/sg246356.html).

6Gamma, Erich, Richard Helm, Ralph Johnson, and John M.Vlissides. Design Patterns: Elements of Reusable Object-OrientedSoftware. Addison-Wesley Professional Computing Series, 2004.

7Buschmann, Frank et al. Pattern-Oriented Software ArchitectureVolume 1: A System of Patterns. Wiley, 1996; Schmidt, Douglaset al. Pattern-Oriented Software Architecture Volume 2: Patternsfor Concurrent and Networked Objects. Wiley, 2000; Kircher,Michael, and Prashant Jain. Pattern-Oriented SoftwareArchitecture Volume 3: Patterns for Resource Management.Wiley 2004; Buschmann, Frank, Kevlin Henney, and DouglasC. Schmidt. Pattern-Oriented Software Architecture Volume 4:A Pattern Language for Distributed Computing. Wiley, 2007.

ABOUT THE AUTHOR

Terry Merriman is a Senior Consultant with Cutter Consortium’sEnterprise Architecture practice. He has worked in IT devel-opment for 30 years as a developer, designer, developmentmanager, and architect. He has consulted with Fortune 500companies in the insurance, finance, automobile distribution,and pharmaceutical sectors, leading crucial production projectsand setting strategic architectural direction.

Mr. Merriman is President of OAD Consulting, Inc., which, forthe last eight years, has concentrated on helping Fortune 500companies define their approach to enterprise architecture. Hehas developed frameworks that extend the capabilities of UMLmodeling tools to provide guidance to design teams, ensureconsistency across their models, and make conforming to archi-tectural principles easier than not doing so. He can be reachedat [email protected].

UML Metamodeling for Enterprise Architecture

Documents

Transcript of UML Metamodeling for Enterprise Architecture