How things
instantiate types
This page is published under the terms of the licence
summarized in the footnote.
All
free-to-read materials on the http://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.
This paper explores how we describe things – past, present or future.
People talk of abstract types and concrete instances; this paper discusses curious things
such as concrete types and abstract instances.
People say the map is not the territory; this paper discusses when the map does become the territory!
Contents
How
do we know if a thing instantiates a type?
Descriptions
as type elaborations
More
about types and instances
Even
more about types and instances
When
a map becomes part of the territory
We do not naturally communicate using language that a logical positivist philosopher would approve.
But somehow, we do manage to describe things as instances of types well enough to be understood, most of the time.
The sentences we form are packed with descriptive types, both explicit and implicit.
“Last Friday, Jane Jones, a 33 year old woman doctor, gave birth to twins in the same hospital where she works.”
Particular things
include last Friday, Jane Jones and the hospital where she works.
General types (explicit
and implicit) include “date”, “named person”, “age”, “woman”, “doctor”, “mother”, “birth event” “location” and
“employment”.
Jane Jones embodies or exhibits several types at once; but
she lives outside this description, and is more than instances of these types.
This table illustrates how things instantiate types used to
describe them.
|
This type |
with this property type |
is instantiated by this thing |
with this property instance |
|
Human |
Height in metres |
John Smith |
2 |
|
Planet |
Colour |
Mar |
Red |
|
Customer |
Address |
Jane Jones |
80 London road |
|
Application |
Hours available each day |
CRM system |
24 |
Natural language is imprecise.
It is often
ambiguous because the names of properties (aka concepts or qualities) may be
interpreted as types and/or instances,
You might say Jane
Jones has the properties "name",
“age”, "employer" of the type “employee”.
Strictly, you
ought to say the person embodies the
property types of the named type.
A person embodies
property types in property instances such as the attribute values “Jane
Jones”, "33 years " and "Hospital X”.
Bear in mind there are behavioural types as well as structural ones
The dynamic systems of interest in this work comprise both structural elements and behavioural elements.
There are not only component types and instances, but also process types and instances.
A description conveys the properties of a thing
A description corresponds to a type elaboration, and anything so described may be called an instance of that type.
A type describes properties found in real or envisaged things
A type name is not enough, you need a type elaboration.
Why “type elaboration”? Because “type definition” is misleading.
A type elaboration defines not the type, it defines properties a thing needs to become an instance.
To describe or define the type itself, you need a more generic type.
|
This thing |
Is a instances of the type named |
Which is described in this type elaboration |
|
A person working for an employer |
Employee |
An employment of a person by an employer |
|
Bilbo or Frodo |
Hobbit |
A humanoid, smaller than and with bigger feet than a human |
|
A classical symphony score |
The classical symphony form |
A musical score in four movements of different styles |
|
Beethoven’s 9th symphony |
Beethoven symphony |
A classical symphony written by Beethoven |
|
A performance of Beethoven’s symphony |
Beethoven symphony performance |
A performance of a Beethoven symphony |
|
Performance |
Performance |
An execution of a behaviour or sequence of instructions |
A type elaboration defines an instance of the named type, with reference to other types.
A type elaboration is a description of a thing that may rightly be called an instance of the type (using the type name).
A type is a type, regardless of its form, be it in the mind, on paper, carved in stone, whatever.
A type becomes meaningful when it is exercised to classify something as an instance, or produce an instance.
Note that the classification or production
of an instance may be imperfect; there is fuzziness here.
In thought and discussion, I confuse instances and things, and I guess you do too.
We find it convenient to label an instance of the employee type using a person’s name.
A thing (a person) can embody a named type (employee), while being much more than that.
A thing instantiates a type named A when the thing embodies or exhibits all (or perhaps most) of the property types set out in the elaboration of A.
The rose bush in my garden instantiates the type named “rose” because it embodies and exhibits the property types (thorny, flowering, bush) of the type “rose”.
Mars instantiates the type named “planet” because it embodies and exhibits the property types (a massive body, over a defined size, orbits a sun) of type “planet”.
And we have two ways to determine whether a thing instantiates a type or not.
· ask a judge or jury to examine a thing or a description, and give us a verdict
· devise test cases with predicted results, and compare those predicted results against the results of running the tests.
It is important to understand that (outside of software engineering) the notion of instantiation can be fuzzy.
It helps to understand the reasons for fuzziness and how to resolve it.
There are two reasons for fuzziness
· A type may have optional properties (cake: a sweet food item, baked, and sometimes iced or decorated).
· A thing may not have all properties (my rose bush has only two thorns, fails to flower this year?)
So how to resolve fuzziness?
The psychologist's concept of a Just Noticeable Difference (JND) might be useful to a judge, jury or tester.
You may have to decide which stakeholders are most important to the decision, then understand which properties those stakeholders value most.
Fuzziness may be resolved in different directions at different times and for different stakeholders.
A reader asks:
Q) If, without
knowing your recipe, I bake a cake identical to ones your recipe yields,
is that cake an instance of the same type?
A) Yes. The cake type (a structural output type) and the recipe (a behavioural process type) are separable.
A baker who does not know the recipe can produce an instance of the same cake type.
The baker might do this either by accidentally following the same recipe, or by instantiating a somewhat (not entirely) different recipe.
To decide whether a slightly different cake is an instance of the same type, you have the two ways above.
Q) If I don’t follow
the recipe exactly, is my performance still an instantiation of the recipe
(process type)?
A) The truth is fuzzy; and the instantiations of a type are fuzzy.
You may conclude it best to say you followed the same recipe, or followed a different recipe.
The answer depends on how strictly you or your audience judges a thing against the type, using one of the two ways above.
To typify is to describe; to describe is to typify.
As soon as you have described one thing, other things of that type may be envisaged.
(Unless you name or otherwise identify one particular thing in time and space.)
A concrete thing can be seen as an instance. E.g. Mars can be seen as an instance of the type “planet”, “rocky body”, or “three-dimensional body”.
An abstract thing can be seen as an instance. E.g. a heroic act might be seen as an instance of the type “heroism”, or “medal winning act”.
Some things are not the products of actors (a rock, cloud, bush or tree), and cannot be regarded as types
Some things are descriptions produced by actors (a map, symphony score, dictionary definition or Java program,) and can be regarded as types.
You might possibly regard your genome as a type, but let us put that aside for now.
For our purposes here, types are the products of actors.
With no actors, there is no abstraction, no conceptualisation and no types.
Types are recorded in one or more models, be they mental, documented or some other form of model.
For our purposes here, if there is no type if there is no record of the type.
However, the same type can be newly conceived many times, especially if it is a widely useful type.
Simple types (number, word, person) have been conceived in countless minds.
Complex types (an algorithm) are often the product of one mind, or a small group of collaborators, and less likely to be reinvented.
The terms “model”, “type” and “description” can all be used with the much same meaning in two premises below.
A model is a model, regardless of its form, be it in the mind, on paper, carved in stone, whatever.
A model becomes meaningful when it is exercised by some kind of interpretation process.
It may appear perverse: not only do types exist, but instances can be abstract.
Instances can be
past, present, future or fictional
There is no rule that says an instance must be concrete; it may be imaginary.
E.g. instances of a building or system described by an architect but not yet built.
E.g. instances of Greek God (Zeus, Hera, Poseidon, Demeter, Ares, Athena, Apollo, Artemis…)
E.g. instances of the type Hobbit in book “Lord of the Rings”.
Instances can be
real, yet still abstract
There can be many instances of any behaviour, action or process type.
You can observe the effects of an instance, but cannot touch or hold the instance.
E.g. instances of a Beethoven symphony performance.
E.g. instance of the type “heroism”.
Things existed long before any types were created by living actors.
The thing now called Venus existed for millennia before somebody defined the type called “planet”.
The thing now called the solar system existed before anybody considered it to be an instance of the type named “system”.
A thing can exist without ever being typified or described.
But the moment a type is conceived, things (past, present, future or fictional) may be seen as instances of that type.
A thing can
instantiate a type
An instance is the instantiation of a type - by a thing that embodies the properties described by/in the type.
|
This instance |
embodies the type named |
|
Venus |
Planet |
|
A rose bush |
Rosea |
|
An employee |
Employee |
A thing can be more
than an instance of a type
A thing that embodies a type can have many more observable properties than listed in the type elaboration.
E.g. A person acting as an employee has many more observable properties than are associated with their employee role.
A thing can
instantiate several types
E.g. a person is an instance of employee, mother, footballer.
E.g. a wine bottle is an instance of container, glass object and labelled object.
Go ahead, try to imagine a thing that is an instance of one and only type!
E.g. Is a god in Greek mythology nothing but an instance of the type Greek God?
It is also an instance of other types (character in literature, object of study in a degree course at Oxford university).
Is an employee database record nothing more than instance of the employee database record type?
It is also an instance of other types (e.g. entry in cache of a data server X).
A thing can
instantiate one type several times over.
E.g. One person, playing the same role for different employers, can embody the employee type several times.
Type names are a
short hand for a more elaborate description
Venus is thing with several names. E.g. Venus, morning star and evening star.
Is Venus really a star? Surely it is better described as a planet?
A type name is not enough, you need a type elaboration.
Only when the type elaboration is agreed can you be sure the type name is used accurately.
(It is a problem that one type of number is defined in
different ways in the Java and C++ languages.)
There is a
many-to-many relation between things and descriptions
One type can have many instances; one thing can be several instances (of several types).
E.g. The one type called star has many instances.
E.g. The one thing called Venus is several instances
· an instance of the type called planet (aka star)
· an instance of a light source sometimes bright in the morning sky or evening sky
· an instance of other types: roundish thing, thing named after mythological figure etc.
No. A type is a concept that exists when it is conceived and/or recorded in a mental or documented model.
A type (e.g. “flying elephant”) can exist without ever being instantiated.
You can write a musical score that is never performed, or a program that is never executed.
Yes. A thing cannot be an instance of a type if there is no type that describes properties of the thing.
A thing cannot be the subject of a model if there is no model (mental, documented or other) that represents properties of the thing.
For a thing to be an instance, there must be a recorded or recoverable type that describes properties of the thing.
No simple answer to this. It depends what you mean by a “thing” and ”exist”.
Looking back in time, you might say a thing can exist before any actor observed it or described it
It seems reasonable to say
· biological entities existed before being typified (unless you say their genomes were their types).
· other natural things (e.g. the planets) existed before they were typified.
· a thing becomes an instance the moment an actor creates a type that satisfactorily describes it (though “satisfactorily” may be a human judgement).
A natural thing need not be an instance of
a type
A natural thing is a product of natural evolution (rather than a product of actors).
For example, a thing you call a rock, bush or tree is a side effect of the ever unfolding process that is the universe.
You perceive it to be an instance of a type whose name you know (rock, bush or tree).
But types are concepts invented, by actors, to classify things in terms of features they share.
If all mental and documented models were destroyed, then the things would still exist, but they could not called be instances of types.
A man-made thing is often an instance of a
type
We might make a thing directly, perhaps with some trial and error, with no predefined model.
But the manufacture of a designed thing usually follows the existence of the type
Especially the manufacture of a complex man-made product, such as a violin, a house or a motor car.
We probably start with a model (mental or documented) that typifies the features we expect to find in the built thing.
And once the thing is built, observers will naturally classify it as an instance of one or more types they have in mind.
It embodies the properties of the named type; its property instances conform to the property types in the type elaboration.
However, the thing can continue to exist if the descriptive type is destroyed, or even human kind became extinct.
Some man-made things must be an instance of a type
A designed activity system cannot repeat its behaviour without a descriptive type.
For a symphony to be performed, there must be a description that elaborates the properties of the symphony as a type.
For a software program to be performed, there must be source code or other record that elaborates the properties of the program as a type.
For a regular business process to be performed, it must be described in a mental or documented model of the process type.
These things are instances that exemplify or manifest types in predefined documented models.
Musical scores and source code define an instance’s features in excruciating detail - by itemising elementary performable process steps.
If the process steps of the type are never performed, then the type never realised as an instance.
Provided at least one record of a process type exists, then instances (performances) of the process are possible.
What if all records of the process type (all mental and documented models) were destroyed?
Then there can be no more performances of that symphony, executions of that program, continuance of the regular business operation.
Yes. Any description can be both an instance and a type.
E.g. A map’s key is a type: describes features observable in that map, and others of its type.
It is also an instance of “map key” as described in a cartography manual.
E.g. A musical score is a type: describes features observable in all performances (instances) of that music.
It is also an instance of the musical score type, as defined in a guide to writing music.
Of course there are; this table lists several examples
|
A thing of this type |
is an informational resource
that encodes in a |
all the instructions
actor(s) need to |
|
Cake recipe |
natural language |
bake a cake |
|
Symphony score |
music notation |
perform a symphony |
|
Business procedure |
natural language |
perform a business process |
|
Computer program |
programming language |
execute the algorithms of a program |
|
Genome |
DNA macromolecule |
assemble, maintain, and reproduce a living organism |
Note the thing is itself a type that defines an instance of behaviour (rather than a structure).
|
A thing of this type is itself a type |
that defines an instance of this behaviour |
by which actor(s) of this type |
produce a structure of this type |
|
Cake recipe |
Cooking |
Baker |
Cake |
|
Symphony score |
Performance of music |
Member of orchestra |
Memory of performance |
|
Business procedure |
Performance of business process |
Employee in organisation unit |
Business output or product |
|
Computer program |
Execution of algorithms |
Environment in computer |
Data structure |
|
Genome |
Life |
Cell in organ in body |
Body of living organism |
And surely there is a sense in which the resource (recipe,
score, program) defines not only an instance of behaviour, but also an instance
of the structure produced (memory, food item, data structure)?
Instances can be fuzzy
There are types – such as number and post code – to which we expect all instances will conform exactly.
However, it is possible that no circle is perfectly drawn and no music performance ever conforms exactly to a given musical score.
In other words a type can be loosely instantiated, and our notion of an instance is rather fuzzy.
Types can be fuzzy
A type may be modified (a musical score may be altered for a smaller orchestra) while we continue to use the same type name.
Which is to say, our notion of a type is also rather fuzzy.
Concreteness is an experience
Our mental models of the universe derive from observing and envisaging realities.
Observation gives us the false impression that the things we see are concrete and persistent.
Even the most concrete things are (at the atomic level) almost entirely empty space.
What we observe of them is behaviour; it is the forces/processes of physics at work.
All things pass
Thing come and go, and in the end, nothing persists
Apparently persistent things are only the transient side effects of the ever-unfolding process that is the universe.
Systems are transient islands of stability we carve out of that ever-unfolding process.
A system theory has to recognise that the definitions of any type in the system may change from one system generation to the next.
There is a
many-to-many relation between maps and territories
A map may describe an imaginary territory.
A map usually records, in a documented model, some properties that are observable in one real-world territory
A map may be generalised (e.g. a housing estate plan) to describe several real-world territories.
A territory on the earth’s surface may exist without a map (a thing may exist without any description of its properties).
A territory may be described by only one map.
A territory may be described by many different maps (each a view that shows different properties).
A territory can be mapped also in many mental models – which are usually less accurate and more fragile than documented models.
A description is a
thing in its own right
Any description can be both:
· a type (a map to which a territory conforms)
· an instance of a type (in the territory of map making).
A map is description, but also a concrete reality in the territory of cartography.
It is described in a legend or key, which lists properties shared by all instances of the same map type.
Also: e.g.
· A musical score is a type (to which a performance conforms) and an instance of the musical score type (in the territory of musicology).
· A software application is a type (to which its execution conforms) and an instance of the application type (in the territory of software development)
· An architecture definition document is a type (to which a system conforms) and an instance of a document type (in the territory of an architecture framework)
· A model is a type (to which a subject conforms), and an instance of a generic model kind (in the territory of a modelling language)
· A “view” is both a type (to which operational system elements conform) and an instance of what is described in a generic “viewpoint” (in the language of ISO 42010).
At composition-time, a musical score
includes both:
·
instructions
to be followed in a performance and
·
specifications of instruments and performers needed
for performance.
It is taken for
granted that the orchestra will have a platform and seats to sit on.
At composition-time, a deployable
software application includes both:
·
instructions
to be executed in processes and
·
specifications of services to be provided by
related application components.
·
specifications of “platform services” to be
provided by “infrastructure” technology components.
At run-time,
both operational systems above include
·
the instructions to be followed in processes,
·
performances of the specified processes and the
·
concrete resources need for performance, including
a platform of some kind.
And thus, the map
becomes part of the territory.
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 07/06/2016 16:49
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
Incoherent left overs
- for review and possible deletion in the future
The design-time map may be seen as part map and part territory
A purposeful man-made activity system exists in both design-time and run-time forms.
The design-time musical score describes musical activities and roles; it does not describe how to manufacture instruments or musicians.
But it does enable people to work out what “platform” components must be bought or hired and deployed to perform the music.
Similarly, the design-time source code of an application describes data processing activities and component roles; it does not describe how to make computing hardware and networks.
But the system description does specify services required of run-time “platform” components.
So, it enables people to work out what components must be bought or hired and deployed to perform the activities, to process the data.
One purpose of a higher-level system description is to specify required platform components, before the lower level design is complete.
What about a passive system - a collection of interrelated elements that do not perform activities?
Consider a passive structure like a Greek temple, the Dewey Decimal Classification system, or a map.
These structures are accessed and used by people (at run-time) to perform whatever they want to do.
Here however, the system describer’s job falls short of buying, hiring or deploying people to do anything with the system description.