Summary points
and references
This page is published under the
terms of the licence summarized in the footnote.
If you like it, please share the web
site address via your favoured social media.
Contents
System
descriptions describe types of things that appear (are instantiated) in
reality, in operational systems.
The US
Department of Defence promote an architecture framework called DoDAF in which
every element is seen as either a type or an instance.
A
whole system description can be seen as a large and complex type that defines
the properties of a whole operational system.
This
paper discusses type-instance relations in general, also type-instance
relations in software engineering.
It
discusses 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 and
ambiguities and choices in how we speak of types and instances.
Conclusions
for EA
· System architects create coherent descriptive types from incoherent mental concepts.
· Architecture modelling standards divide architectural descriptions into models of structure and models of behaviour.
· 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.
· 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.
· A concrete real-world object can be a member of many dynamic sets, and an instance of many types.
· Two (possibly more) entirely different sets can be regarded as exemplifying one type.
· In some cases, the actor who creates an instance is the judge of whether an instance conforms to a type or not.
· It is tempting to align type-instance with description-reality, but can be misleading.
· An instance can be an abstract thing.
· A type can appear more concrete than its instances.
· A type is usually an abstraction by generalisation and/or idealisation from one or more instances
· Abstraction can be recursive.
· There are strict types and looser types.
· An Architecture Description is a loose complex type that is manifestable in zero, one or more operational systems.
· Striving for pedantic ontological correctness can make a text unintelligible to naive readers.
· 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.
· We usually model a system’s components and processes as they work in one system generation.
· Modelling a persistent component requires understanding the states it passes through.
· Modelling things over time can turn types into states.
· Modelling things over time can turn tight compositions into looser associations.
· Modelling at a fine-grained level can reveal more volatile instances.
In business systems, business processes are monitored and directed by information systems that contain descriptions of the things that are important within a business domain.
It is said that set theory is a basis of information system design – as in relational database design and object-oriented design.
But actually, this is a little misleading; this work compares and contrasts:
· Static sets in mathematics – compared with - dynamic sets of the kind recorded in information systems.
· Types in mathematics – compared with - softer types used in the specification of complex systems.
This set theory paper draws relationships between two kinds of division.
A set may be defined by extension (listing all members) and or intension (typifying a member).
Systems (after system theory) may divided between static and dynamic (changing over time) systems.
Conclusions for EA
· A thing is a type or an instance in relation to another thing.
· Any intensional definition of a set member (be it short or long) may be called a type.
· At the highest level of definition, a type is the label or name we use for a kind of thing.
· We use business information systems to tell us what things fit a type, belong to a dynamic set.
· A concrete real-world object can be a member of many dynamic sets, and an instance of many types.
· The notion of partial views (sometimes called “soft systems”) is an important tool in complex system specification and enterprise architecture.
· The notion of recursive, multi-level, description is an important tool in complex system specification and enterprise architecture.
· Agile methods encourage getting to user acceptance testing as fast as possible, with the risk that little or no definition is left behind for future intelligibility.
· Higher level specifications of software systems contain abstractions from intensional definitions in code.
· We depend on humans to interpret and follow vacuous and inaccurate intensional descriptions.
1. See “DoDAF terms and concepts” at avancier.co.uk.
2. “Classifying processes: an essay in applied ontology” Barry Smith
3. “The ancient Mesopotamian city” Marc de van Mieroop. Oxford University Press 1999
4. “Basic Formal Ontology v2.0” Barry Smith
5. Eddy Zemach, ‘Four Ontologies’, Journal of Philosophy 23 (1970), 231-247.
6. UML Superstructure Specification v2.4.1
7. Encyclopaedia Britannica has been used, especially http://www.britannica.com/EBchecked/topic/46221/axiom-of-extensionality
8. If you want to follow up Stanford Encyclopedia of Philosophy, then try this http://plato.stanford.edu/entries/logic-intensional
9. Wikipedia has been used in places, especially on “Intensional”
10. There is good discussion of botanical classification at http://theseedsite.co.uk/class.html
11. “Set theory as a semantic framework for Object-Oriented Modelling” by Professor B Cohen, City University London.
12. “Visualization of Object Oriented Modeling from the Perspective of Set theory” Poornima. U. S., Suma. V. Cornell University Library
13. “Data and reality” Kent, W. Amsterdam, North-Holland, 1978
14. Other quotes from Kent, W. as found at http://thid.thesa.com/thid-0513-0671-th-1508-6960
Copyright conditions
Creative Commons Attribution-No
Derivative Works Licence 2.0 16/12/2015 21:55
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