Tag: uml

The ArchiMate metamodel

This article introduces a complete, navigable and clickable representation of the ArchiMate metamodel standard (both the 2.1 and the 3.0.1). The model is created using UML. This is not because I wanted to translate ArchiMate into UML, but because UML should be well-suited to define a language such as ArchiMate in. And after all, also the standard itself defines its metamodel using something that looks like UML.

Metamodelling and ArchiMate

Any language needs a specification. What are the rules? What is the format (its syntax)?

ArchiMate is no different. Its specification is part of the standard, published in document format by the Open Group:

The language specification consists partly of what ArchiMate calls its metamodel. For language designers the use of this term in the context of ArchiMate is somewhat problematic, because what ArchiMate calls a metamodel should more properly be defined as a class model. Also the lack of a proper metamodel layer in ArchiMate is revealed by the fact that ArchiMate is not specified in itself, but in what should be regarded as a handicapped UML.

Many people, including myself, have argued for ArchiMate to be specified as a UML profile. Unfortunately this has not happened yet.

(Note: it seems that OMG is actually working on this, and the effort is well underway, even to the level of MOF definitions, which I was very happy to learn)

The reasons can only be speculated upon, since most of the tool vendors were forced to do exactly that anyway. Language users (i.e. architects) need a “proper” metamodel, but that is much more so for tool builders. In fact I would think that the language designers need this as well because I cannot for the life of me imagine how I would go about working on the next version of the standard without a proper metamodel, accessible through a repository-based representation such as the one introduced here. But anyway.

Probably as a result of this, the language specification is inconsistent, ambiguous and contains several errors. This has improved somewhat in the latest 3.0.1 version. This article and especially the models will show these problems because the effort of creating the UML models of the standard made these problems explicit.

The goal of this article is to represent the ArchiMate metamodel as published by the Open Group in a slightly improved format, using “correct” UML. Doing that enabled me to:

  1. create (better) UML profiles for use in tools (using an XMI version of the metamodel)
  2. create much more usable documentation of the standard itself:
    1. clickable ArchiMate concepts, linking to the specification of that concept. For an example, please visit the model, for example the Business Service concept)
    2. diagrams with all defined/allowed relations of a specific ArchiMate concept (for an example, please visit the model, for example the Artefact concept). The standard itself for example provides a table with all allowed relations, containing several errors which are hoped to be corrected soon.
  3. create a “one-pager” of the entire metamodel (something Gerben Wierda also did for his book Mastering ArchiMate, on the 2.1 and 3.0.1 version of ArchiMate) or those parts you want to focus on
  4. extend the metamodel for specific customers
  5. and of course, for this article, detect and document problems (errors, ambiguities or vagueness) in the standard as published 😇

In fact I realised when creating this model that for me as an architect this is an infinitely more usable version of the specification than a stupid thing like a book with pictures.

Note: if your browser does not show the models properly, please refresh your browser cache, since the model is regularly updated.

The metamodel can also be downloaded in XMI format, for you to use in your tool of choice:

About ArchiMate metamodels

The metamodel for the 2.1 and 3.0.1 version of the standard are exported in HTML format. To view the metamodel, please use these links:

As said earlier, the UML this article refers to should be “correct”. Please let me know if you notice issues. However, a few remarks should be kept in mind:

  1. The use of colours is in line with the use in the standard. In 2.1 colours were used, in the 3.0 standard shades of grey were used. We tried to comply to the colouring scheme in the standard.
  2. Attempts have been made to create diagrams that are in line (mainly the layout) with those in the standard as much as possible. The goal was not to improve ArchiMate, but to detect/repair some of its problems.
  3. Multiplicity will be added in the future. As ArchiMate 2.1 states (the 3.0.1 standard is ominously silent on this…), most of the relations are zero or more (* in UML parlance) except where explicitly stated differently. Note that when ArchiMate talks about cardinality, UML (on the class level) talks about multiplicity.
  4. The direction of a relation is still not clear. It is clear what it means in ArchiMate, and what it means in UML, but the semantics of direction in ArchiMate are different from those in UML. We stick to the ArchiMate semantics for now, but I think this disparity is one of the big problems in ArchiMate. In my view, direction is about dependencies, but that is not how ArchiMate sees it.
  5. In this article, stereotypes (for relations or classes) have not been used. Obviously, if you want to create a UML profile for ArchiMate, this must be done.

The ArchiMate 2.1 metamodel

For the entire model, please visit ArchiMate 2.1 metamodel.

Generic Metamodel : Logical Diagram

This is the highest specification of the basic ArchiMate 2.1 concepts. It shows the three “columns”, but not the three layers (Business, Application and Technology) since these are not linked with generic ArchiMate concepts (i.e. there is no such thing as “Technology Layer Element” nor should there be one).

One diagram I added, because it is discussed in the text but not shown in any diagram. It is shown below:

Missing Core Elements : Logical Diagram

The ArchiMate 3.0.1 metamodel

For the entire model, please visit ArchiMate 3.0.1 metamodel.

Top-Level Hierarchy : Logical Diagram
Top-Level Hierarchy : Logical Diagram

The metamodel for ArchiMate 3.0.1, from a language specification perspective, is an improvement over its predecessor. All concepts have now been defined in the model. The above diagram shows the top-level concepts, the most generic ones, this time also including the relationships. It almost looks like a real metamodel!

Of course in the standard these are just pictures, so my hope is you will find these models useful. If you do, please do not hesitate to like this page using the LinkedIn and Twitter buttons in the top right!

List of detected issues

Below is a summary of the issues that I have stumbled on in making the models. The chapter in the standard is provided so that you can compare what the standard says with my proposed changes. The diagram in my repository is also hyperlinked for your convenience.

The elements hyperlinks do not always work correctly (sorry, this is due to the way the tool generated the HTML report, I am working on correcting this).

ArchiMate 2.1 issues

For an overview of the issues, please see the repository where all comments can be found. I have focussed for now on the new ArchiMate 3.0 standard, of which the issues are copied from the repository below.

ArchiMate 3.0.1 issues

“Core Element” and “Element”

There is talk of “Core Element”, but it seems equivalent to what is also referred to as “Element”.

4.1: Behavior and Structure Elements

Notes

  1. Diagram Behavior and Structure
  2. For completeness I added the Collaboration concept, which is also an abstract class.
  3. There is a problem in the standard with the abstract classes External Behavior Element and External Active Structure Element. These classes are nowhere explicitly specialised, for example a Business Service should be an External Behavior Element. I expect these diagrams to be added in the next revision of the standard.

4.2: Specializations of Structure and Behavior Elements

Notes

  1. Diagram Specialisations of Core Elements
  2. This diagram is not followed through with the specific subclasses of Process, Function and Interaction. Although it would potentially introduce multiple inheritance, these subclasses should be added, for example Business Process as a subclass of Process. Note that multiple inheritance in metamodels is not a problem, but should be avoided in “instance” models. The Business Process/Function/Interaction element is completely equivalent to Business Internal Behavior Element.

5: Relationships

Notes:

  1. Diagram Relationships
  2. The associations between Relationship and Element show the labels as UML. In the ArchiMate standard (p. 22) these are shown on the other end.
  3. ArchiMate does not specify the multiplicity on the other side (related from). We show that an Element can participate in zero or more relations.

8.2: Active Structure Elements

Notes

  1. Diagram Business Internal Active Structure Elements
  2. The standard does not explicitly specify a generalisation relation between Business Internal Active Structure Element and Internal Active Structure Element. That seems to be an error.

8.3: Behavior Elements

Notes

  1. Diagram Business Internal Behaviour Elements
  2. One expects this diagram to repeat in the Application and Technology layers. It does not.
  3. I have added the generalisation to Internal Behavior Element, which seems to be lacking from the standard.
  4. There is a consistency problem with Specialisations of Core Elements diagram. This problem needs to be resolved!

Application Function/Process/Interaction

Notes

  1. Diagram Application Function/Process/Interaction
  2. This diagram has been added to model the not-really-existing Application Process/Function/Interaction concept properly. As was mentioned with the Business Internal Behavior concept, this concept should be named “Application Internal Behavior” for consistency.

10.1: Technology Layer Metamodel

Notes

  1. Diagram Technology
  2. As is noted with the concept, the Technology Process/Function/Interaction should be named “Technology Internal Behavior”.

Technology Internal Behavior

Notes

  1. Diagram Technology Internal Behaviour
  2. This diagram does not occur in the standard. Nowhere in the standard metamodel diagrams a Technology Function, Process or Interaction is shown, but its shared generalisation, incorrectly named Technology Process/Function/Interaction is.

11.1: Physical Elements Metamodel

Notes

  1. Diagram Physical
  2. In the standard (p. 91) the assignment between Equipment and Technology Process/Function/Interaction is shown explicitly. However since this relation is implied by the already existing one between Node and Technology Process/Function/Interaction in the Technology diagram and thus inherited by Equipment, it is omitted here.
  3. The accesses relation between Technology Process/Function/Interaction as shown in the standard (p. 91) is also omitted here, since it is inherited from the same relation between Technology Object and Technology Process/Function/Interaction in the diagram Technology.

12.1: Alignment of Business Layer and lower layers

Notes

Quite a few problems with this metamodel in the standard (p. 96).

  1. Diagrams Relationships between Business Layer and Application Layer Elements, and Relationships between Business Layer and Technology Layer Elements
  2. The Business Actor/Role element should be the Business Internal Active Structure Element since also a Business Collaboration can use an Application Service. We have put the correct element in this diagram.

13.1: Implementation and Migration Elements Metamodel

Notes

  1. Diagram Implementation and Migration
  2. The accesses relation between Implementation Event and Deliverable as shown in the standard (p. 99) is omitted here since it is inherited from the one between Event and Passive Structure Element as shown in this diagram.
  3. Same thing for all the trigger/flows between Event subclasses.

13.4: Cross-Aspect Dependencies

Notes

  1. Diagram Relationships of Motivation Elements with Implementation and Migration Elements
  2. Because of the realization relationship between Composite Element and Deliverable the same kind of relation is superfluous in the other diagram between Deliverable and Plateau.

 

UML for functional programming?

This question was asked on Stackoverflow and ModelingLanguages and prompted me to attempt to make some persistent preconceptions about UML clearer. First of all: UML is not about modelling object-oriented software.

Origin of object-orientation

But maybe we should go back to what object-orientation is. OO (shorthand for object-orientation) is invented around 1970. Xerox had a group called the Software Research Group which was part of a think tank created to do research into the possible threats of the modern computer for Xerox’s prime business: copying machines. This group invented in a short period of years almost everything around what we now call the modern computer: displays with bit-mapped overlapping windows, a keyboard with a mouse to manipulate the objects on the display, icons to represent various types of information, and even the network to link all those computers together called ethernet.

To create the complex software that was needed to run those personal computers, an object-oriented programming language, as well as by the way an object-oriented operating system, was deemed necessary. Alan Kay originally coined the term “object-orientation” although he later stressed that a better term would have been “message-oriented” since he envisioned a complex system of interacting elements creating complex behaviour by sending messages to each other.
Byte Magazine August 1983For more info on this original vision please read the august 1981 Byte magazine devoted to Smalltalk.

The assumption was that we needed a powerful new way of thinking about problems, to enable creating multiple orders of magnitude more complex software. But you see, this was not just about software. It was about a paradigm that helps in managing complexity. OO was just that, and it still is.

Origin of UML

When the UML effort started it only tried to merge a multitude of approaches that helped in visually representing those OO programs. So UML is not so different from OO. It is just a view on the same thing: a complex system.

UML introduced something new, however, and that was the meta model. Mainly for the tool developers, this meta model helps in designing the power of the OO modelling paradigm itself. It defines classes and metaclasses, properties and associations (as access paths for message passing).

The metamodel of UML is extensible. You can extend the metamodel with Profiles, effectively creating a specific set of language elements with a tightly defined semantics for a specific problem domain. This should not be confused with Domain Specific Languages (DSL’s), because a DSL specifies a set of elements or building blocks in the domain, for example the financial domain. A UML Profile contains the semantic definitions of the syntax used to describe those domains. For example you might create a Profile for Entity Relationship modelling. And you might define a Profile for functional languages.


Royal Eise Eisinga PlanetariumObject-oriented mathematics

One of my first endeavours when I learned object-oriented programming was to create a planetarium. This has been a hobby of mine all my life. To simulate the movements of bodies in the solar system a mathematical model is used. The orbit of, say, the moon can be described with an equation with a lot of variables (to approximate the orbit, since there is no analytical solution of the many body problem in physics, that is until recently). My first thought was, well this is mathematics, I probably will have a hard time moulding the mathematical equations into objects and methods and messages. But to my delight I found this was not the case at all. Once I realised that my problem domain was mathematics, and specifically equations, the follow-up was easy and everything fell into place perfectly. I had Equation objects, CelestialBody objects using those to tell their location, and time nicely proceeding helping the celestial bodies to move.

To summarise: object orientation, and UML as a domain-independent language, can be used to describe any problem domain efficiently, and help with the complexities in those domains. And you are free to implement your solution in an object-oriented language like Smalltalk, or a functional language like Haskell. OO is domain-agnostic, and implementation-agnostic.

What is wrong with UML?

We find it so hard to cope with complexity in IT, that every time an evolving standard, like UML, is becoming too complex, we tend to drop it in favour of something new. The new being, because it is new, simple and understandable. While it lasts …

We see this with the rising popularity of Ruby. Developers are flocking to this new thing as if mesmerized, disillusioned by the complexity of delivering value with the Java frameworks.

Now there are two reasons something can be complex. In fact I propose there are two classes of complexity.

  1. Flawed complexity. It is handicapped by nature, and all the add-ons that make it complex are added in a vain and ever more frantic attempt to make it manageable.
  2. Living complexity. It is growing in a natural way, and complexity is a derived attribute of its growth, but the essence in the local structures remains simple and effective.

UML is, I would like to propose, simple in its essence, being of the second class. The basis axioms remain easy to understand. Java EE on the other hand (to name a rather random other standard) is not simple, not in its building blocks, and not in the way it has to be used. It belongs to the first class of complexity.

Naturally complex solutions still remain complex, and require mastership in using them. It is counterintuitive in some aspects, one being that it is useless to attempt to understand it in its entire structure. Human beings, especially engineers I am afraid, have this urge to get an overview, to understand the global picture. With any class of complexity this is useless. However the second class of complexity offers help in the essential characteristic of being simple in its local structures. When you zoom in into the complex weave, any place you find yourself in is easy to understand, easy to do things in. When you zoom out, the structure quickly becomes unintelligible. With the first class of complexity zooming in will never offer solace, every local structure is still so intertwined with transitive dependencies that changing any local aspect can break something several degrees of separation apart.

The fact that UML in the essential building blocks is so simple, is as far as I am concerned, the reason it should not be thrown away just because the standard as a whole is becoming so complex. The attribute of local simplicity is what we should judge standards with, not the attribute of global complexity.

Solutions we create are complex by nature. This is not something to avoid, but instead something we should deal with. Making a distinction between these two kinds of complexity can help.

Why use UML for Business Modeling

What we generally see when we look at tools for business modelling is an attempt to visualise the flow of activities in an organisation. I once heard a consultant from a workflow tool vendor proudly say that:

“Now finally the managing director understood what was really happening in his organisation!”

We don’t want to argue that this consultant was entirely wrong. In fact, workflow modelling has helped many organisations to finally get a grip on their processes, and took important steps toward a more controlled and repeatable process. Especially for QA and CMM this has had a positive effect. But I beg to question whether the managing director “really” had a better understanding.

In the 80’s an important contribution to management science came from the publication of Hammer & Champy’s book on business engineering: Reengineering the Corporation: A Manifesto for Business Revolution (Collins Business Essentials). Organisations felt that only radical measures would enable them to continue competing on an increasingly global market.

This had a profound impact on the need for organisations to “know what was really happening”, in other words: modelling.

The interesting observation could be made that there were really not many tools to model organisations. Generally not more than an organisation chart was available. There arose a need for tools, and what happened was interesting from a sociological point of view: the tools were borrowed from the leading scientific metaphor of the day (see my article on The Importance of Metaphors): information theory, a term first coined by Claude Shannon.

The fact that information technology was itself having grave problems coping with the complexity of its work did not impede people from the almost as immature scientific community of management science to adopt many of the IT metaphors in vogue at the time. IT was sexy, it was cool. The exponents of the new community of automation experts were seen almost as supernatural beings.

The most important IT metaphor was dataflow modelling. Based on data modelling it tried to capture the many ways in which this data could be manipulated, moved and changed. So the intriguing observation could be made that management sessions to decide upon strategic issues were facilitated using IT techniques such as dataflow modelling!

Of course this was only whispered behind the back of executives.

For some reason or another this approach to business modelling is the approach taken by almost every company that provides services in this area. The terms used are “business processes”, “workflow management”, “use case driven”, etc. If we look at tools like Arena or Aris they basically offer facilities to model processes and flows. This is now re-emerging in all kinds of approaches like BPMN, BPEL etc.

In most cases these approaches are anything but object-oriented, and therefore they suffer from the same shortcomings as traditional modelling techniques in software engineering: models become too complex to manage, they are difficult to adapt to changing requirements, they are hard to communicate about with users and customers, etc.

My most important criticism is that these models are so badly suited for “active systems” that is systems that are able to reason about themselves, take initiative, are self-healing and can be delegated responsibilities to. This is amazing in itself, because these problems in software engineering were detected many years ago!

What’s even more amazing is that the proponents of these approaches use the very same problems to “sell” their approach and say that it in fact is “more flexible, business people understand it better” etc.! It is understandable however; the problem is not that the approach is “wrong”, but the problem, and one that is a bit hard to understand at first sight, is that it does not scale.

This makes it hard to see at first sight, because the examples you use to introduce the subject, cannot but be simple. And in simple models the process approach is simpler to understand than the object-oriented approach.
In fact object-orientation is not new: the first object-oriented software ran on an object-oriented operating system (something we still haven’t seen in the commercial field?) in the year 1972. This was the first Smalltalk system, in Xerox PARC. For an excellent article on the design principles behind this system, read http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

OK, so maybe we want to model businesses the object-oriented way. Fine. The question remains: why are so few doing this? We have seen many companies offering support for modelling, be it software modelling or other kinds of modelling, and mentioning object-orientation in some way or another. Of course it may be that they try to harvest from the hype surrounding object-orientation, although that is slowing down a bit recently, but I think that is not the only reason. Another reason may well be the fact that object-orientation is much more difficult than most people thought. In fact I have always said that OO is easy, that is aligns better with our “natural way of thinking”. However in the course of the past ten years I slowly had to accept the fact that people using OO in practice had many problems doing so in a successful manner.

I have coached development teams and given courses in OO to many hundreds of people, and have had to reluctantly admit to myself that only a small percentage of these students really grasped what I always considered to be the simple essence of OO and modelling. This “essence of OO” is an important enough subject on its own, so I will reserve an article for the subject. Here I will only summarise two of the most important aspects of “good” OO modelling, that is: (1) the active/passive rule, and (2) demand-chain processes.