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.
Abstract
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.
Stricter and
looser (polythetic) types
Recursive
idealisation (or conceptualisation) of system description
Describing
and phrasing relations
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 |
|
Set
|
Not
ordered |
Unique |
|
Ordered
set |
Ordered |
Unique |
|
Bag
|
Not
ordered |
Not
unique |
|
Sequence
|
Ordered |
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.
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 |
Features |
|
Types |
City, Planet, Customer,
Order |
Colour, Location, Weight,
Throughput, Response time |
|
Instances/values |
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.
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 |
|
Salesforce |
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.
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.
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.
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.
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).
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.
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.
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 |
|
Law |
Phrasing of |
Conviction |
|
Marriage law |
Conduct of |
Wedding |
|
Syllabus entry |
Setting of |
Examination
question |
|
Java class |
Instantiation of |
Java
object |
|
Flow chart notation |
Drawing of |
Flow
chart |
|
Process |
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.
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.
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.
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.
|
This |
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.
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.
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.
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 |
Objects |
thing with attributes and
relationships to other objects |
|
An event |
Occurrences |
happening that has some
consequence within the system |
|
A behaviour (process) |
Executions |
performance of an algorithm
according to a set of rules |
Architecture
modelling standards divide architectural descriptions into models of structure
and models of behaviour.
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 Type |
Operational system Run-time
element Instance |
|
Class |
Object
|
|
Event |
Occurrence |
|
Behaviour
(process) |
Execution |
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.
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.
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 |
|
Rosa |
a
list of botanic genera |
countless
roses |
|
Birth |
a
list of life event types |
countless
birth event instances |
|
Death |
a
list of life event types |
countless
death event instances |
|
Wedding |
a
list of life event types |
countless
wedding event instances |
|
Philosophy |
a
list of academic disciplines |
countless
philosophical treatises |
|
Logic |
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 |
|
Entity |
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
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.
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 template |
|
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 |
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.
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 |
|
Process |
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?
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.
An ontology may define relation
types for relations between types,
between instances, and between types and instances.
|
|
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 |
|
Examples |
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”.
|
|
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 |
|
Examples |
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.
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 |
instances |
|
An owner |
has |
one or more |
possessions |
|
A compound |
is made of |
several |
elements |
|
A document |
records |
one or more |
events |
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 |
instances |
|
A policy
holder |
is insured
by |
one or more |
policies |
|
A policy |
insures |
one |
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 |
instances |
|
An order |
is placed |
one |
customer |
|
A policy |
manifests |
one |
policy type |
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