A type theory for EA

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

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



System architects design, define and describe things; they typify things.

They build models that typify human and computer elements of activity systems.

Architects might benefit from a more consistent understanding of what it means to describe a system in terms of types.

The US Department of Defence promote an architecture framework called DoDAF (ref. 1) in which every element is seen as either a type or an instance.


This paper discusses type-instance relations in general, and in system architecture and software engineering.

Not only what might be called hard type-instance relations, but also softer ones in the world of nature and verbal communications.

It is about:

·         using types to describe instances

·         relating instances to types

·         ambiguities and choices in how we speak of types and instances.


Much of my career has been spent reading and writing models of dynamic systems.

The models are descriptions that abstract from reality, abstract types from instances.

And what follows addresses types and instances in ways that I find more helpful than sources I have looked at.

Click here for how this came to be written, acknowledgements and comments, conclusions and references.


Ontological context 1

More about types. 3

Stricter and looser (polythetic) types. 5

Instances. 7

Types enshrined in documents. 9

Layers of abstraction. 10

Recursive idealisation (or conceptualisation) of system description. 12

Complex descriptive types. 14

Describing and phrasing relations. 15


Ontological context

Ontology is a branch of metaphysics concerned with the nature and relations of being.

Terms and concepts that appear in ontologies include these:

·         Things: individual objects, which may be instances of types

·         Types: kinds of thing.

·         Structural features: properties, attributes and relations

·         Behavioural features: events and processes or operations.

The theme of the type-instance relation has many variations; you may come across these word pairs:

·         Kind - Occurrence

·         Type - Token (after the philosopher Charles Pierce)

·         Set - Member (as in set theory).

·         Class - Object (as in software engineering).


Beware that different mathematicians and philosophers use the words above in different ways.

So you, reader, should not assume any of the above words are used below exactly as you might do already.


Perhaps most often, a class is a set in which an individual member can be recognized in one or both of two ways:

a) it is included in an extensional definition of the whole set (a list of set members)

b) it matches an intensional definition of one set member.

A type is an intensional definition; it is a description that is sufficiently generalized to fit every member of a set.


A set (e.g. of planets) is a collection - the set can have attributes of its own (e.g. average mass or density).

A type (e.g. planet) is not a collection - it is a description that fits each and every member of a set/collection.


Here are some definitions to be going on with:

·         A type specifies the rules for what constitutes an instance of the type.

·         A type specifies features shared by things that are instances of the type.

·         A type describes each value in the set of values known as instances of the type.

·         A type defines one or more characteristics shared by the members of the set whose members are instances of the type.

Our ontological context (leaning on the Unified Modelling Language v2.5)

The extensional definition of a set is an enumeration of the set’s members. E.g.

·          The planets: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus and Neptune.


An intensional definition of a set member is a type elaboration. E.g. A planet is:

·         an astronomical object orbiting a star or stellar remnant

·         massive enough to be rounded by its own gravity (has a radius)

·         not massive enough to cause thermonuclear fusion

·         has cleared its neighbouring region of “planetesimals”.


A type specifies features shared by things that are instances of the type.

·         It has one or more type names (e.g. planet, wandering star).

·         It has a type elaboration that itemises the features of an instance.


Features are divisible into:

·         structural features called properties (attributes and relations) and

·         behavioural features called operations, triggered by events.


Properties may themselves be typed.

E.g. the property “radius” is typed and constrained by the values represented by the type “number”.


A type may have subtypes, which define a smaller population of instances.

E.g. the planet type has two subtypes: large low-density gas giants, and smaller rocky terrestrials.


Though the term set is used above, the term collection might be more accurate according to the scheme set out below.

Collection type

Order of instances

Uniqueness of instances


Not ordered


Ordered set




Not ordered

Not unique



Not unique


A type defines each individual in a collection of instances.

The volatility of instances and types

Things change.

A named thing may be created and destroyed, and during its life it become an instance of a type and stop being an instance of a type.

Thus, instances of a type may be created or destroyed over time.

Type elaborations also change.

E.g. the IAU has changed the definition of "planet" so that Pluto no longer qualifies.

More about types

Just to get us started, here is an ontological square (after Aristotle, as shown in ref. 2).

Notice how the instances give particular values to the features of the types.


Persistent entities



City, Planet, Customer, Order

Colour, Location, Weight, Throughput, Response time


London, Mars, Avancier Ltd, Order 999

Yellow, London, 1 ton, 100 transactions per second, 5 minutes


Aristotle favoured a structural view of the world in the sense that he placed persistent entities above transient events and processes.

In modelling dynamic systems, we often start with the events and processes – as discussed towards the end of this paper.


Here is a brief outline of type-instance relations:

·         1 instance (a tree) instantiates (realises, manifests or exemplifies) features defined in 1 or more types (tree, plant, ground shader, oxygen producer).

·         1 type (tree) is instantiated (realised, manifested or exemplified) in zero, 1 or more instances (many individual trees).

·         1 type (tree) defines the features of zero, one or more instances (many individual trees).

·         1 type (tree) need not define all the features of an instance (every individual tree has many unique features of its own).

·         1 type (tree) can be specialised into many subtypes (oak tree, ash tree, beech tree).

·         1 type (plant) can be realised in a variety of instances that extend the features defined in the type (individual grasses, bushes, trees).

·         1 loose type (city) can be realised in a variety of instances that omit or override one or more features of the type (London, Paris, Newport).

Types as abstractions

Abstraction is what intelligence actors do.

In every domain we study, we find things (individuals) of interest.

We commonly abstract a type from one or more things we are interested in.

E.g “City” is a general type – abstracted by historians from individual examples like ancient Athens and Rome.

regard the ancient Mesopotamian city as a type [in] comparison with [city types in] the Graeco-Roman world, which equally are abstractions.”  (Ref. 3)


We create a type by considering instances, looking at what they have in common, and abstracting the common features into a type.

The type gives us at least a partial idea, model or description of the thing we are interested in.

Often, the name of the type is enough for us to bring the features of the type to mind.

Types as mental models

Google’s first-offered definition of instantiation is: “a representation of an idea in the form of an instance of it."

Where does an idea come from? From evolution by natural selection and from intelligent thought.

Intelligence relies on abstraction; you typify things that you experience or imagine, largely unconsciously.

Where is an idea to be found? In a brain or memory of some kind.

In mysterious ways, your brain holds mental models or patterns that help you match an external thing to an internal type.

Your conceptual types surely overlap and conflict; so you have to choose the best fit, consciously or unconsciously.

Your conceptual types may be verbalised to some degree in your head, but there is no formal taxonomy or ontology.

Types as agreed mental  models

Your mental models are fuzzy, floaty and fragile.

Your idea of a rose, or a football match, might be different from mine, and it might change tomorrow.

Your mental model of a system to be architected might be different from mine, and it might change tomorrow.

If we are to build a system that repeatedly instantiates types, those types must be agreed by the community interested in the system.

Types as agreed descriptions of mental models

System describers are interested types that define instances by features they share.

Named types include, e.g., circle, number, rose, human, employee, customer, computer, football match, and murder.

You cannot reason about circle, number, rose etc. knowing only the type names.

The only thing you can reason about are the descriptions of circle, number, rose etc. in their type elaborations


To solidify and agree our concept of a rose, or a football match, or a system, we typify it in a shared description.

Such a descriptive type documents what we agree is true of an instance, by defining abstract features.

This instance

exemplifies or manifests

this descriptive type

A rose

the idea of

Rosa: a plant that is flowering, woody, thorny, and perennial


the idea of

A system that helps sales people manage customer relationships


Mental models assist the survival of individuals and species, but they are not coherent enough for system architects.

We need agreed types to be recorded in agreed descriptions.

A system architect may be well advised to gather a variety of possibly conflicting mental models of a system’s architecture from all stakeholders.

But in the end, builders need one coherent architecture description, one type that defines system features in the abstract, from which to build one or more instances of the system.

System architects create coherent descriptive types from incoherent mental models.

A type as a templates for instances

An instance cannot be called an instance unless it exemplifies or manifests the general idea of a type.

Conversely, a type is called a type because it constrains the structure and/or behaviour of instances.

Some types are used as a template to create an instance – giving particular values to the abstract features of a general type.

E.g. This individual sentence was written with reference to the general idea of an English language sentence.

A type is instantiated (realised, manifested or exemplified) in zero, one or more instances

A type does not have to be instantiated. It may be a fiction that is never realised

It may be instantiated only once, especially where the type has been “reverse-engineered from one instance.

It may be instantiated many times in different instances.

A type need not define all the features of an instance

A type is usually conceived to define features one thing can or does share with other things.

A concrete real-world thing usually has many more features than any one abstract descriptive type it is an instance of.

So one type can be realised in a variety of instances that extend the features defined in the type.

And a loose type can be realised in a variety of instances that omit or override one or more features of the type.

A type can be specialised into many subtypes

The type passenger vehicle might be specialised into car, train, plane, and perhaps flying car.

The type defines individuals in a wider set; a subtype defines individuals in a narrower set.

Stricter and looser (polythetic) types

It seems that mathematics, logic, philosophy, linguistics and sociology have similar notions of type and instance in so far as:

·         Instances can be said to exemplify or manifest the features defined by a type.

·         Types can be used to govern the enumeration or creation of instances.


However, across the spectrum from maths to sociology, types range from strict to loose.

Remember “city” is a general type – abstracted by historians from individual examples like ancient Athens and Rome.

But it turns out that “city” is a very loose type; the label is well known and widely used, but there are many different definitions.

Humans create both loose types and strict types.

Strict types, with elaborate and precise definitions, are the essence of software engineering.

Loose types are the essence of high-level design documents.

A polythetic type defines characteristics that occur commonly in instances, but are not essential in any instance.

Strict types

In mathematics, a type usually declares the necessary and sufficient conditions for being an instance.

E.g. the definition of a prime number is 'an integer divisible only by 1 and itself'.

·         It is a necessary condition: a prime number must have the defined features.

·         It is also a sufficient condition: any number with the features is a prime number.


Such strict types can be found also in sociology.

E.g. the definition of a bachelor instance is 'an unmarried man'.

·         It is a necessary condition: a bachelor must be an unmarried man.

·         It is also a sufficient condition: any unmarried man is a bachelor.


If a type’s features are necessary, then instances must match the features of the type.

"A monothetic class has properties both necessary and sufficient to identify members of that class.
This is also termed the Aristotelian definition of a class.” Edited from http://www.iva.dk/bh/lifeboat_ko/CONCEPTS/monothetic.htm.

Looser (polythetic) types

It seems the softer the science, the less strictly instances conform to types.

The notion of ideal type is associated with the sociologist Max Weber.

The term ideal does not mean perfect, it means only an abstraction of features to be found in things of interest.

An ideal type is abstracted from one or more things, but does not have to correspond to all features of any one thing.


The same idea appears in software engineering.

The UML standard says “Models of objects can be incomplete, imprecise, and abstract according to their purpose in the model.”


There are several ways that an instance may not meet the ideal described by its type.


An instance may omit some features of its type.

An individual employee may not have a value for every attribute type of the general employee type.

In databases and in programming, not all objects of a class need have values for every attribute of the class.

(Perversely, this might be said to mean the instance abstracts from its type.)


An instance might extend the features of its type.

Every individual rose has its own peculiar features, in addition to those of its general type.


An instance might override some features of its type.

A particular rose might have a smooth rather than a thorny stem.

Max Weber allows instances of a type to deviate somewhat from that type.
A polythetic class has a broad set of properties that are neither necessary nor sufficient.
Each member must possess a minimal number, but none has to be found in each member.
This is associated with Wittgenstein's concept of "family resemblances." Ibid.


Finally, an instance may less effective or efficient in operation than the hope or aim associated with its type.


So, there are strict types and looser types.


Not everything in the world is an instance of a known type; and not every known type is realised as an instance.

Read other papers for discussion of when things become instances.

In short, a thing is not a type or an instance on its own – it is only a type or an instance in relation to another thing (real or envisaged).

Detecting a type-instance relation

Here are two general questions to expose a type-instance relation between two entities, A and B.

1.       Does A define a feature that is exemplified or manifested in B?

2.       Does B exemplify or manifest a feature set out in or by A?


If yes, you may reasonably consider B to be an instance of the type set out in or by A.

An instance as exemplifying or manifesting a type

Remember Google’s first-offered definition of instantiation: “a representation of an idea in the form of an instance of it."

Its first-offered definition for manifestation also contrasts an instance and the idea of it.

Manifestation: “an event, action, or object that clearly shows or embodies something, esp. a theory or an abstract idea.”


These examples express type-instance relations as manifestations.

This instance

exemplifies or manifests

this type

A rose

the features of

a plant genus (Rosa)

A map

the symbols of

a map legend/key

A sentence

the form of

a grammatical construction

An object

the state and behaviours declared in

a class


Natural language can be unclear and confusing.

Saying an object is an instance of a class does not mean an object is a class.

It means an object manifests or gives values to the features of a class.

“Objects of a class must contain values for each attribute of that class, in accordance with the characteristics [type] of the attribute.” (ref. 6)


An instance exemplifies or manifests a more general structure or behaviour described in a type.

Beware that different schools give subtly different meanings to terms like instantiate, manifest, embody, represent, realise, implement, and make concrete.

Governance of an instance to a type

The notion of a type as an "ideal" doesn’t mean there must be purposes or requirements for instances.

Roses naturally grow to exhibit the features of their type - Rose.

However, artificial types do often describe the requirements or rules for the creation of instances.

The idea being that manifestation of instances will be governed according to the properties or rules of their type.


In mathematics, the definition of a prime number enables instances of prime numbers to be generated by a computer.

In the human world, human actors may interpret the rules of a type to generate instances.


An instance of this type

has rules used by actors to govern the

instances of this type


Phrasing of


Marriage law

Conduct of


Syllabus entry

Setting of

Examination question

Java class

Instantiation of

Java object

Flow chart notation

Drawing of

Flow chart


Execution of

Process executions

Interface specification

Implementation of

Service offered component

Service level agreement

Provision of

Service provided by a supplier


When an actor creates an instance of a type, the actor gives values, in the instances, to the general features of the type.

In some cases, the actor who creates an instance is the judge of whether an instance conforms to a type or not.

Parallel types for one instance (multiple inheritance)

Any thing can instantiate (realise, manifest or exemplify) features defined in zero, one or more types.

E.g. you exemplify the type “mammal with heart” and the type “mammal with lungs”.

E.g. a murder conviction is an instance of the murder conviction type enshrined in the law of murder, and an instance of the wider legal judgment type.

So, a concrete real-world thing can be a member of many dynamic sets, and an instance of many types.

Parallel sets for one type

The features of one type might be exemplified or made manifest not only in several instances, but in different sets of instances.

For example, the law of murder might be exemplified or made manifest in the world as:

·         A murder conviction – an artefact stored in an information system - and

·         A murder incident – a process that occurs in the human world


For example, a flow chart might be exemplified or made manifest in the world as:

·         A program written in a programming language – an artefact stored in a configuration management system

·         A program execution – a process that occurs in a computer.


Both examples show the features of a type might be exemplified or made manifest in both

·         A set of structures – artefacts documented in an information system

·         A set of behaviours – process executions in the real world.


This paper (to the discomfort of some) allows that both – in their different ways - may be considered to be instances of the type.

So, two (possibly more) entirely different sets can be regarded as exemplifying one type.

Types enshrined in documents

Remember Google’s first-offered definition of instantiation: “a representation of an idea in the form of an instance of it."

Where is the idea to be found? A type is commonly set out as a template or formula in a document.



is an instance of

this documented type

A performance of Hamlet

the words and actions in

the play Hamlet

A murder conviction

the judgement form enshrined in

a law of murder

A football match

the rules enshrined in

the laws of football

An operational system

the structures and behaviours defined in

an architecture description


A criminal conviction is an instance of “conviction type”.

Where are conviction types to be found? In documented laws.

A law is a type; it is used by a judge to express a conviction by giving particular values to the features of that law.


E.g. A murder conviction is an instance of the murder conviction type, which is documented in the law of murder.

The type document declares the general form of a murder conviction – one human being was killed by another of sound mind and body.

Every murder conviction gives particular values to those features – Joe Soap was killed by John Brown whose particular mind and body are sound.

Complex types as aggregates of simpler types

A type may be a substantial and complex aggregate of simpler types.

E.g. the laws of football were written to define the type for every football match instance.

These laws aggregate the simpler types of ball, player, match duration, start, restart, ball out of play, goal, offside, fouls, free kicks etc.

The many simpler types add up to the complex type that all particular football matches should conform to.


Curiously, the term “football match” does not appear in the laws of football, but the idea of it does

And though the document contains superfluous information (e.g. “welcome to the laws”), the document is primarily a type elaboration.

Types as documented in software engineering

In software engineering, a class (a type document) is a template for creating instances (objects).

At run time, software creates objects in strict accord with the features of the class.

And each object (e.g. one customer) gives particular values to the general features of its class (customer).

The document name = the type name, though the type document contains additional information, not needed for instantiation.

Types as models of structure and behaviour

Enterprise, solution and software architects are asked to architect human and computer activity systems.

These systems monitor, support or direct individual entities or events of interest to a business.

Architecture descriptions are primarily verbal – but we use modelling languages in which the graphical symbols are surrogates for words.

For modelling such systems, there are standards such as ArchiMate (v2) and Unified Modelling Language (UML).

Both standards divide an architectural description into models of structure and of behaviour.


The UML standard divides model elements between structural (classes) and behavioural (events and behaviours).

A model element describes individuals in a system being modelled (an operational system).

Each model element (each class, event or process) is a type that defines members in a set of similar individuals.

Each type of this kind

describes instance of this kind

where each instance is an individual

A class


thing with attributes and relationships to other objects

An event


happening that has some consequence within the system

A behaviour (process)


performance of an algorithm according to a set of rules


Architecture modelling standards divide architectural descriptions into models of structure and models of behaviour.

Layers of abstraction

Types in system descriptions - instances in operational systems

Systems exist at two levels – in system descriptions (models) and operational systems (run-time).

Accordingly, system elements can be divided into types (in description) and instances (in an operational system)

UML does this using the terms below.

System description

Model element


Operational system

Run-time element






Behaviour (process)


One person’s description is another person’s real world

The run-time system, the domain of the model, is sometimes called the real world or real machine.

But is an object in an operational software system any more real than a class in a model?

Is an event occurrence in a software system any more real than an event type in a model?

Is a murder conviction any more real than the law of murder?


Remember that one type may be exemplified or manifest in two parallel run-time systems.

·         a tangible system of things, machines and living entities (in which murder incidents happen)

·         an information system (in which murder convictions are recorded).


The second system monitors and directs entities and events in the first system (and sometimes overtakes it).

Software engineers usually model the second system directly, and the first system only indirectly.

This paper does not dictate that a type has to be exemplified in either kind of system.


Also, descriptions are themselves the products of a higher level run time system.

At a higher level, there are the human systems that build models and determine the laws of the land.

There are higher level models (like TOGAF, ISO 42010 and government procedures) for how those higher level modelling systems behave.

This paper does not say instances occur only at the bottom level of recursive run-time systems

Here, type-instance relations can and do exist within descriptions, and between descriptions at different levels of abstraction.

A murder conviction (a description) gives more specific values to more general types recorded in a law (another description).

So, it is tempting to align type-instance with description-reality, but can be misleading.

Abstract instances and concrete types

Of course, our interests do include hard, tangible, concrete machines and living entities.

But our interests also include intangible roles, events, processes and information.

Our kind of architect works with abstract concepts and descriptions of these things.

And methodologists define even more abstract types, which describe the abstractions that architects work with.


To identify something as an instance, you can be misled by asking questions like: Does it exist? Is it visible? Is it concrete?

You might assume instances are concrete.

UML says objects, event occurrences and behaviour executions are always complete, precise, and concrete.

But what does concrete mean here? Event occurrences and process executions are not tangible or visible.

And outside of OO programming, here two more abstract instances:

·         A thought is an instance of the type “thought”.

·         A name is an instance of the type “name”.

So, an instance can be an abstract thing.


To identify something as a type, you can be misled by asking questions like: Is it a concept? Is it invisible? Is it abstract?

I suppose it is fair to say a type is more abstract than an instance; and yet.

UML defines concrete classifiers, concrete classes and concrete subclasses.

Java distinguishes:

·         A concrete class: a type that is associated at run-time with a dynamic set of objects.

·         An abstract class: a type only, of which no objects can be created.

To a programmer, Java's abstract classes are more tangible and visible than instantiated Java objects!

So, a type can appear more concrete than its instances.

Recursive abstraction

Remember: a thing is not a type or an instance on its own – it is only a type or an instance in relation to something else.

Type and instance are roles played by one entity in relation to another entity.

So, one entity can play both instance and type roles in relation to other entities.

Here are the examples promised earlier.

This entity

is both an instance in

and a type that characterises


a list of botanic genera

countless roses


a list of life event types

countless birth event instances


a list of life event types

countless death event instances


a list of life event types

countless wedding event instances


a list of academic disciplines

countless philosophical treatises


a list of philosophy branches

countless logical arguments

Two-year logic course

our university's course portfolio

two course instances run in parallel each year

Glossary entry

a glossary

features common to all instances it describes

Java class

a class library

the state variables and behavioural operations of each object in a set of objects


a data model

the attributes and relations of each entity instance in a set of entities


A description is itself a thing, which can be described.

·         E.g. A flow chart (a description) is an instance of a flowchart notation (a meta description).


There are types of types of types.

·         E.g. A rose is a woody perennial, of the genus Rosa, of the family Rosaceae, of the order Rosales, of the Kingdom Plantae.


You can have descriptions of descriptions of descriptions.

·         E.g. This map of Paris is an instance of map, which is a kind of chart, which is a kind of description, which is a kind of abstraction.


There are many flavours of abstraction, including: omission, composition, generalisation and idealisation (discussed elsewhere at avancier.co.uk).

A type is usually an abstraction by generalisation and/or idealisation from one or more instances, and the abstraction can be recursive.

Recursive idealisation (or conceptualisation) of system description

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

(Classifier & Instance, Component & Process) instantiated in models below

MOF standard

ArchiMate/BCS grid




M2 Language for models

Universally-recognised system description types, instantiated in models below

Model kinds in UML, ArchiMate  and TOGAF.

Programming language elements (e.g. class)

Data definition language elements (e.g. systable)

Flowchart symbols

Role description


M1 Design time domain-specific model

Domain-specific system description types, instantiated in models below

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 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.


There are also type-instance relations between behavioural features in higher-level models and lower level realisations of them.

This model

has features used to govern

each implementation of the model as

UML standard

 the manifestation by drawing of

a sequence diagram

A sequence diagram

the manifestation by performance of

a process execution

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


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.

Complex descriptive types

In software engineering, a complex type is an aggregate of primitive types.

E.g. date is a complex type, a compound of three simpler types, day, month and year.

There are many examples in information system design and software engineering of complex types.

An instance of this type

has features used to govern

instances of this type

Database table definition

the manifestation by insertion of

Row in the table

Regular expression grammar notation

the manifestation by drawing of

Data flow structure


the manifestation by progression of

Process execution


In softer sciences, and in this paper, a type can be looser and more verbal.

E.g. A shopping list is a complex type, an aggregate of the simpler types that should be made manifest in delivered items.


A type may be a complex aggregate of simpler types, and the document containing it may be substantial.

E.g. The laws of football define the complex type “football match”, the rules that all particular football matches should follow.


If every type is a descriptive specification, then, is every descriptive specification a type?

System descriptions as complex types

A narrative system specification can be seen as a complex type.

It describes the structures and behaviours of all possible operational systems than meet the specification (even if we never build a system).

Each potentially-built system is an instance that should conform to the specification.


What some call an architecture description is one kind of system specification, which is a kind of complex type.

The expectation is that one or more system/solution instances will conform to the features set out in the architecture description.

The description is a complex type composed of more primitive finer-grained types, definitions to be exemplified or manifested in building system elements.


In airplane engineering, you may expect an airplane to perfectly match its architecture description.

In business systems and software engineering, we don’t expect it or demand it a perfect match.

An architecture description is a partial and flawed abstraction from any real system; it might be called a polythetic type (see above).

We need system testers to judge whether a system conforms adequately to its architecture description or not.


We are leaving the domain of mathematics and entering the domain of ambiguity.

If a substantial narrative system specification is a complex type, how to decide what counts as an instance that realises the specification?

We may call on systems testers, or the members of a jury, to decide. We may use some kind fuzzy logic.


An Architecture Description as both an instance of the type “system description” and the type that describes an operational system.

An Architecture Description is a loose complex type that is manifestable in zero, one or more operational systems.

Describing and phrasing relations

An ontology may define relation types for relations between types, between instances, and between types and instances.

Type-instance relations


Sets (collections)

Types (descriptions)

Type – instance relations

A set is a collection of objects

An object is a member of a set

A type is exemplified by an object

An object is an instance of a type


An object is a member of a set

A unicycle is a member of the unicycle set.

A bicycle is a member of the cycle set.

A flowchart is a member of a flowchart set.

An object is an instance of a type

A unicycle is an instance of the unicycle type.

A bicycle is an instance of the cycle type.

A flowchart is an instance of a flowchart type.


This paper is not proposing to use these phrases in a controlled vocabulary.

It is exploring the concepts of type, instance and subtype, and how ambiguities arise.


Certainly, in natural language, people do not use such relation phrases consistently.

E.g. they might say “this wall is a kind of boundary”, when they might more accurately say:

·        this wall is an instance of the type “boundary”.

·        this wall is similar to (but not the same as) an instance of the type “boundary”.

Type-type relations in dynamic systems


Sets (collections)

Types (descriptions)

Type – type relations

A set contains a subset

A subset is part of a larger set

Supertype embraces subtype

Subtype is a kind of supertype


A subset is part of a larger set

The unicycle set is part of the cycle set.

The bicycle set is part of the vehicle set.

The flowchart set is a part of the diagram set.

The human population is a part of the ape population.

Subtype is a kind of wider type

Unicycle is a kind of cycle.

Bicycle is a kind of cycle, which is a kind vehicle.

Flowchart is a kind of diagram.

Human is a kind of ape


You might try to use these relation phrases in all definitions, but to use them slavishly is difficult and might prove unwise.

Striving for pedantic ontological correctness can make a text unintelligible to naive readers.

Instance-instance relations in dynamic systems

All relations in a data model or UML class diagram can be looked it in two ways:

There are 1- to-1 type-to-type relations in the diagram.

There are more varied instance-to-instance relations in the world that diagram represents.

The annotation and cardinality on a relation describe the instance-to-instance relations.

This instance

relates to

this number of


An owner


one or more


A compound

is made of



A document


one or more



The traditional advice is to annotate a relation between two entities in both directions.

Verb Phrase: from the perspective of the parent. Inverse Verb Phrase: from the perspective of the child.

This instance

relates to

this number of


A policy holder

is insured by

one or more


A policy



policy holder


Data models and class diagrams were invented to describe a dynamic system, whose state evolves in response to events.

Entities and relationships are updated by events. Objects are created, updated and deleted.

So, often, the verb phrase on a relation refers to a process that occurs as the system state evolves.

A many-to-one relationship often represents a process during which events attach items, one at a time, to an owner.

This instance

relates to

this number of


An order

is placed



A policy



policy type

Instance-instance relations in static structures

The ISO 42010 standard defines rules for a completed Architecture Description – a static structure.

It defines several entities (stakeholder, concern, model, model kind etc.) and defines how they relate to each other.


Architecting is a dynamic system

An Architecture Description does not spring into life fully-formed; it is the end product of an architecting process.

So, a relationship line could be annotated with a verb phrase that reflects this on-going process.

E.g. one model kind <is used to govern the drawing of> zero, one or more models.


An Architecture Description is a static system, a passive structure, in one particular state

The class diagram of an architecture description document, in the state when it has been completed, ought to say.

E.g. one model kind <has been used to govern the drawing of> one or more models. (Its use was in the past.)

Modelling a static system, a passive structure, in a particular state, may affect the definition of relations - both the tense of the verb and the cardinality.



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0             09/01/2016 19:13

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org