Types and instances of system elements

with respect to ArchiMate’s generic structure and ideas

One of about 300 papers at http://avancier.website. Last updated 12/01/2017 15:55

The paper is mostly edited from my contributions to an email correspondence with Marc Lankhorst.

He doesn’t see everything the same way I do, but did say: “this is a fair representation of ArchiMate’s basic structure and ideas”

The paper contains an original section n types and instances.

Contents

System instances and descriptions. 1

Structural and behavioral elements. 2

External and internal elements. 3

Types and instances of elements. 5

Type-instance relationships between and within models. 7

Footnote 1: on locating system elements in space and time. 9

Footnote 2: on human actors. 10

System instances and descriptions

The solar system exists in two forms:

· Instantiation: a physical reality, several large bodies orbiting the sun.

· Type: any idealised descriptions of that reality.

A Beethoven symphony exists in two forms:

· Instantiation: performances, which instantiate the symphony in sound waves.

· Type: any musical score that describes a performance.

A social system exist in two forms:

· Instantiation: performances of activities by human actors

· Type: any description of the actors and activities in the system.

Generally, a business system features the following element types:

· actors/components (active structure) interact by

· playing roles in processes (behaviors) to meet goals by

· maintaining system state data (passive structure) and

· sending/receiving data to/from each other and to/from the external environment (across the I/O boundary)

All businesses rely on individual people performing ad hoc activities, not only in response to recognised events but also by way of innovation.

However, we can only model those activities are typical, that are observed or envisaged as repeated or repeatable.

Structural and behavioral elements

The structure-behavior duality of system elements can be expressed using many different word pairs.

Structural view What a system is made of	Behavioral view What a system does
Actors	Activities
Components	Co-operations
Entities	Events
Form	Functions
Items	Interactions
Objects	Operations
Performers	Processes
Roles	Rules
Stocks / Stores	Streams / Flows

The Unified Modelling Language (UML) is a standard published by The Object Management Group.

Its purpose is to provide system architects and others with tools for analysis, design, and implementation of software-based systems and businesses.

The UML diagrams are divided between those that model structural elements and those that model behavioral elements.

· Behavioral views of system show processes that consume inputs and transform them into outputs, using the resources of the system.

· Structural views organise components (subsystems) that cooperate in processes into structures.

In the quote below, structural elements are called parts and connectors, and behavioral elements are called rules for interactions.

“The architecture of a system is a specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors.”

(Model Driven Architecture: MDA Guide v1.0.1, The Object Management Group.)

ArchiMate also divides a system description into structural elements and behavioral elements.

“[Architecture descriptions are] organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution.”

(ArchiMate® 2.1 Specification, The Open Group.)

The primacy of behavior (a general system principle)

In natural systems, structures are created by behaviors.

In designed systems, the structure is created to perform the required behavior.

The roles and components are created in order to perform the required processes.

The Unified Modelling Language (UML) is for describing event-driven activity systems.

“Actions are the fundamental units of behavior in UML, used to define fine-grained behaviors.” UML 2.1

A man-made activity system is designed with purposes in mind

The effects of its behaviors may be divided into desired, neutral and harmful.

E.g. The effects of a haircut may be classified as:

· Desired effects - shorter hair and a credit to the barber’s bank account.

· Neutral effects - knowledge transfer regarding the customer’s holiday plans.

· Harmful effects - wear and tear on the barber’s scissors and chair, or worse, cutting a customer’s ear.

External and internal elements

Generally speaking a process can be encapsulated behind a discrete service contract.

And a component can be encapsulated behind an interface definition (confusingly also called service level agreement or contract).

So, the generic elements of system architecture descriptions can be drawn in generic meta model grid as below.

Generic grid

Behaviors

what the system does

Active Structures

what the system is made of

External view

requirements of

external entities

SERVICE

A discrete behavior triggered by an event or service request and producing a valued result, definable in a contract.

INTERFACE

A collection of services requestable by a client.

Internal view

the workings of

the system

PROCESS

A sequence of activities triggered by a discrete event or service request and leading to an interim or final result.

ROLE

A performer (actor or component) of required activities, encapsulatable by the services it provides to and requires of others

It is impossible to prescribe a human activity system as far as a computer activity system must be prescribed.

However, similar principles apply, and key system elements in a restaurant might be naively illustrated as below.

Restaurant

Behaviors

what the system does

Active Structures

what the system is made of

External view

requirements of

external entities

Place order, Pay for meal

A la carte menu, Table d’hote menu

Today’s specials

Internal view

the workings of

the system

Take order, Cook meal

Serve meal, Check

Waiter, Chef, Oven

Interfaces

Any role, organisation unit, application or technology can be encapsulated behind an interface declaring requestable services.

· An oven has an interface in the form of controls used to trigger its services: turn it on, up, down and off.

· A human role is describable in the form of an interface declaring requestable services.

· A waiter’s role is to present a menu declaring service requests that the waiter can accept and convey.

· A human actor has the general-purpose interface of their senses, through which they receive service requests specific to their role in a described activity system.

Hmm.. which is the interface - the menu or the waiter?

Some say an interface is a passive structure – like a menu - and the waiter is a façade component that presents the interface.

Others say an interface is an active component – like the waiter who presents the menu.

For now, let us say the generic grid is ambiguous on this point, and you can choose whichever interpretation you want.

The primacy of the external view (service-orientation)

Note that the internal structural elements in this grid are active structural elements - not passive ones.

In TOGAF, Functions and Roles are structural component types that specify activities performable by actors.

In UML, Components and Classes are structural component types that specify activities performable by active objects.

TOGAF considers “services” to be such fundamental features of a system that it calls them requirements.

It records services in its Architecture Requirements Specification – separate from its Architecture Definition Document.

Since the method is iterative, architects in practice interleave thinking about services, processes and components, alongside continual requirements management.

In these contexts, a service encapsulates a discrete event-triggered operation whose functional and non-functional qualities can be documented in a service contract.

A service contract (recording inputs, outputs, pre and post-conditions and other qualities) encapsulates internal activities and resources needed to realise the service.

“For the external users, only this external functionality, together with non-functional aspects such as the quality of service, costs etc., are relevant.” ArchiMate.

A service is accessible via a system interface, but is recursively decomposable inside the system boundary.

High level services are realised by high level processes, which invoke lower level services, which are realised by lower level processes, and so on down to atomic performable process steps.

Interfaces and components can also be recursively decomposed inside a system.

Services and contracts in other ontologies – terminology confusions

An architecture ontology attaches words to defined concepts (it is not a dictionary that attaches various meanings to a word).

It must select a term for the encapsulated event-triggered operation - and "service" has been selected in the sources above.

Unfortunately, DoDAF, UML and the Web Services Definition Language (WSDL) tend to use the terms “service” and “interface” interchangeably.

“Interfaces declare coherent services that are implemented by BehavioredClassifiers.” UML 2.5

So, what is named in the generic grid as an interface corresponds to what UML calls either interface or service and WSDL calls a Web Service.

And what is named as a service corresponds to an operation offered by a Web Service.

For some, an interface is a menu declaring services, for others it is a waiter (broker/façade) providing access to services.

In UML, a contract is a whole interface definition (cf. a service level agreement document) rather than one discrete service.

“An Interface specifies a contract; any instance of a Classifier that realizes the Interface shall fulfill that contract.

The obligations associated with an Interface are in the form of constraints (such as pre- and post conditions) or protocol specifications.” UML 2.5

But this last might mislead you, since pre-conditions, post conditions and protocols have to be associated with each discrete service/operation within an interface.

Types and instances of elements

Architects usually model types of things rather than individuals, but some architecture frameworks have terms for instances also.

The mappings between ArchiMate, DoDAF and UML below expose industry terminology confusions surrounding the terms "actor", "service" and "interface".

Types and instances in ArchiMate

Individual instances of architectural entity types can be placed in the extended the generic grid below.

	Instances	Types	Types	Instances
External view	Service occurrences	Service contract	Interface definition	Interface deployments	External view
Internal view	Performances	Process	Role	Assignments	Internal view
	Behavioral view		Structural view

Note the grid’s instantiation of a role is an assignment rather than an actor (who may be assigned also to other roles).

For discussion of assigments read Organisations, roles and actors in EA (and other) repositories.

Remember it is impossible to prescribe a human activity system as far as a computer activity system must be prescribed.

Humans are expected to act creatively and usefully to the benefit of their employer, far outside any role description.

However, the core concepts of a restaurant activity system might be illustrated as below.

	Instances	Types	Types	Instances
External view	Servings of >	Menu item	Master menu	Menu copies	External view
Internal view	Performances of >	Order, Cook, Serve, Pay	Waiter, Cook, Oven (Roles)	Waiters, Cooks, Ovens (Assignments)	Internal view
	Behavioral view		Structural view

Strictly speaking, the grid should show waiter assignments rather than a waiters (people) who may perform multiple roles.

The “master menu” above is the interface that defines those menu items the restaurant owner is willing and able to sell.

A menu copy is an instantiation of the master menu - a deployment of the interface definition, a structure found in a location.

Types and instances in the Department of Defence Architecture Framework (DoDAF)

DoDAF has an unusual meta model, in which instances of types are named using the preface “individual”.

The grid can be edited to show some core DoDAF terms and concepts as below.

	Instances	Types	Types	Instances
External view	Individual Desired Effects	Desired Effect	Service	?	External view
Internal view	Individual Activities Projects	Activity Project Type	Performer Person Type, System	Individual Performers Organisations	Internal view
	Behavioral view		Structural view

Note the positioning of “performer” for role or component type, “service” for interface, and “desired effect” for service.

Strictly speaking, the grid should show performer assignment rather than individual performer.

Types and instances in The Unified Modelling Language (UML 2.5)

“A UML model consists of three major categories of model elements, each of which may be used to make statements about different kinds of individual things within the system being modelled

· A classifier describes a set of objects [each] an individual with a state and relationships to other objects.

· An event describes a set of possible occurrences [each] something that happens that has some consequence with regard to the system.

· A behavior describes a set of possible executions [each] a performance of a set of actions (potentially over some period of time). Executions may generate and respond to occurrences of events, including accessing and changing the state of objects.”

By the way, “describes a set…” might be better “describes each member in a set…”.

UML speaks of interfaces being realised by classifiers (classes or components) rather than being instantiated on their own.

The grid can be edited to show the major UML terms and concepts, and some others, as below.

	Instances	Types	Types	Instances
External view	Occurrences	Events / Operations	Interfaces	“Interfaces may not be instantiated”	External view
Internal view	Executions	Behaviors / Methods	Components / Classes	Objects	Internal view
	Behavioral view		Structural view

UML 2.5 occupies 786 pages; it is so rich and complex that mapping its elements to the generic grid is not simple.

Classifier is too broad a concept for the internal structural element in the grid; a better fit is UML’s component (a subtype of class which is a subtype of classifier).

“Class: the concrete realization of EncapsulatedClassifier and BehavioredClassifier - specify the Features that characterize the structure and behavior of [classified] objects.”

“Component: a construct that can be used to define software systems of arbitrary size and complexity.

· represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

· a self-contained unit that encapsulates the state and behavior of a number of Classifiers.

· specifies a formal contract of the services that it provides [and] requires in terms of its provided and required Interfaces.

· a substitutable unit that can be replaced at design time or run-time by a Component that offers equivalent functionality based on compatibility of its Interfaces.”

UML says a component may be instantiated as an addressable object, or else be a design-time-only component (so instantiated through objects that instantiate its realizing Classifiers or parts).

Type-instance relationships between and within models

Yes, I know this section is academic, and you may be tempted to skip it, but give it a try.

Type-instance relations between models

Given a real-world domain of interest, you can describe it, then recursively abstract ever-more idealised descriptions by successive idealisation.

First you typify the things that you observe or envisage, then define higher-level types of those types, and so on.

The Meta Object Facility (MOF) of the Object Management Group (OMG) is based on four levels of abstraction.

This provides a management framework for the development and interoperability of models, and for the OMG’s Model Driven Architecture (MDA).

Level of model Composed of	Generic modelling concepts	Computer processes	Computer databases	Human processes	Human resources
M3 Universal concepts The most generic description elements instantiated in M2 models	MOF standard (Classifier & Instance) Generic grid (Component & Process)
M2 Language for models Universally-recognised system description types, instantiated in M1 models	Model kinds in UML, ArchiMate and TOGAF.	Programming language elements (e.g. class)	Data definition language elements (e.g. systable)	Flowchart symbols	Role description template
M1 Design time domain-specific model Domain-specific system description types, instantiated in M0 models	Models drawn using UML, ArchiMate and TOGAF artefact types	Class diagram for a program	Tables / relations in a database schema	Business process flowcharts	Role definitions
M0 Run time domain-specific model Memories of instances (below) of M1 types (above)		Object states in memory	Rows / tuples in a database table	Case records	Assignment records
Real world operational system	Individual entity instances (humans and computers) performing activities in response to events, as directed and recorded above

The M1 level is where human and computer activity systems are described in domain-specific models.

Such a design-time model shows entity and event types or templates.

It does not directly represent particular entity and event instances in the real world.

The templates are used at run-time to instantiate objects (e.g. rows in a database table) in an M0-level information system.

The M0-level model directly records real world entity and event instances, in state data.

Entity and event instances can be remembered digital records, paper records and human mental models.

In practice, businesses rely on employees remembering individual business entity and event instances in their mental models.

Type-instance relations within a model

M1-level models of information systems often include type-instance relations. E.g.

A model of this system	contains this type – instance relation
Product management system	Product type – is manifested by - Products
Customer relationship management system	Customer type - is manifested by - Customers
Project management system	Role - is manifested by - Assignments

A box in an M1-level diagram represents a type of thing.

And each line in an M1-level diagram connects 1 type to 1 other type.

But those lines describe how M0-level instances relate.

E.g. 1 role defines features shared by many assignment instances.

So, the role-to-assignment relation can be seen as a 1-to-1 at the M1-level and 1-to-many at the M0 level.

Footnote 1: on locating system elements in space and time

At first sight, the generic grid appears to reflect a distinction between things in space and things in time.

You may well assume that structural elements occupy a location in space, and behavioral elements occupy a period of time.

But the truth is far more complex.

Some components and processes can be located space, others cannot:

· a component instance/actor may sit in one place, but a component type/role is located in the system description

· an elementary component may sit in one place, but a larger component may be subdivided and its parts distributed

· an elementary process step may be performed in one place, but the steps of longer process may distributed.

All components and processes have a limited life cycle:

· a process instance occupies a period of time, but a process type lasts as long as its description lasts

· a component instance occupies a period of time between its creation and destruction, but a component type lasts as long as its description lasts.

A structural component’s life cycle can span several system generations.

In each system generation, components from the previous generation may be changed or survive unchanged

Migration planning is based on identifying which components exist (in which version) in each system generation.

Footnote 2: on human actors

Architecture frameworks assume an enterprise architecture repository will be maintained.

This architecture repository might be structured according to the TOGAF or ArchiMate meta model.

Architects are expected to record abstract roles and types of service, process, component etc.

And they are concerned with systems in which particular humans and computers act in described roles.

Of course, a human actor can do more than any role they are asked to play.

Obviously, a human being is much, much more than a performer of described activities in described roles.

But architects do not document what an individual human might do unsystematically or unpredictably - in addition to or in conflict with role definitions.

And a human’s out-of-role feelings and needs, and undescribed activities, are mostly beyond the architect’s reach.

They are the concern of that human, his/her line manager, the HR department, the facilities management department and others.

And wherever architectural change affects them, architects usually turn for help and guidance to those other functions and/or a business change team.

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.