Introduction

You cannot consistently build a set of models without there being an underlying classification model that describes the models you want to produce and clearly defines the relationships between those models, an ontology! TOGAF® defines its language, types and outputs (models) over two levels. Level 1 is the meta-model and level 0 is the content framework (the levels are something I have introduced to aide the discussion).

Collateral

Let's do some UML

The presentation is a talk we gave at the South African Open Group conference regarding language and its importance.  The presentation clearly outlines the relationship between the different models that can be produced in UML.  It shows that changes in any structural model have a direct impact on the behavioural models and vice versa.

The above model can be expressed in terms of the model itself

Following on from this we can see that (the model is the viewpoint)

And if we introduce objects (used to represent the view) into the model we now see

In UML speak, objects only ever communicate (execute messages) through links, not associations.  Associations are used to define what may be executed over the link but it is not where the execution takes place.  A link is an instance of an association, and an object is an instance of a class.  Objects are connected to one another via links, not associations.  Classes a connected to one another via associations.

Now we are ready to use this model to connect a behavioural model such as a sequence diagram to a class diagram

If you understand the rules of sequence diagrams, you will know they never have classes on them, but objects.  You cannot have an object without a class.  Messages execute over links but are defined over associations. You cannot have a link without an association.  Therefore, from a sequence diagram, it is possible to derive a class diagram

What you have seen me do is construct a meta-model to govern the relationship between two UML models.

Understanding the TOGAF® Content Framework and Meta-model

TOGAF® defines the outputs from its framework as

• Deliverables: a document of some kind that is contractually binding (or gets one or two signatures on it) - an ADD (Architecture Definition Document), a SAD (Solution Architecture Document), an AC (Architecture Contract), PID (Project Initiation Document), PC (Project Charter) etc.
• Artefacts: the elements and their supported commentaries that make up the Deliverable (catalogs/catalogues, matrices and diagrams) - list of roles in an organisation would be a catalog, a RACI chart would be a matrice and use case diagram would be a diagram
• Building Blocks: anything with a well-defined boundary, has an interface and encapsulates a concept - any artefact may be a building block

A Deliverable is comprised of building blocks and their supporting text.