SYSTEM MODELING
  • Model <-> Abstraction (levels of detail)
  • Modeling Levels (levels of meta)
  • e.g. modeling reality: physics
  • e.g. modeling reality: what the system is about
  • Abstractions
  • System Modeling: the paradigms
  • e.g. programs - descriptions of computation
  • e.g. models of computation
  • system properties: state
  • system properties: architecture
  • system models (dynamics graphs)
  • information models: spatial
  • associative networks
    		•  

      Model <-> Abstraction (levels of meta)

      Location http://www.cs.mun.ca/~ulf/mod/rel.html.
    Written 300404 by Ulf Schünemann.
    Copyright (C) 2004 Ulf Schünemann.

    back to: relations

    Abstraction and model-building are two related, important techniques for understanding complex domains of interest.
    «Abstraction is an essential part of model building where some aspect or part of the real world is extracted and simplified.» [xrefer Oxford Dictionary of Geography]
    We can concretize this wrt. the definition of model below: If we take 'isomorphism' as the mathematical formalization of abstraction then, obviously, any abstraction A1, A' of X is also a model of it, and the abstraction relation is in a sense a core for the model relation, on which all model relationships are based (directly or indirectly).
       
    Abstraction Model
    Abstraction(s) enable us to understand (analyze) complex domains of concern, like programs, software systems, and their application domains, which contain a plethora of detail.
    The word is used for three things:     		A model is «[a] representation of some phenomenon of the real world made in order to facilitate an understanding of its workings. A model is a simplified and generalized version of real events, from which the incidental detail, or 'noise' has been removed» [x].
    X:
    b1---a---c3
    / | \
    /   |   \
    b2  c1  c2
    /|\
    |
    abstraction-from
    |
    		 1. A process of separating essentials from details, and focusing on the former while ignoring, "abstracting away", the latter.
    «A putative psychological process for the acquisition of a concept x either by attending to the features common to all and only xs or by disregarding just the spatio-temporal locations of xs.» [xrefer Oxford Dictionary of Philosophy]

    2. The relation between objects with more and less properties.

    3. The concepts aka. abstract objects reached (some say: created) by abstracting.
    «Concepts are created by abstraction, focusing on similar properties of phenomena and discarding differences.» [WOMB]

    -> the three functions of abstraction

    		 
    X1:
 b1---a---c3
     /|\
    / | \
  b2  c1 c2
    |
    homomorphism
    |
    \|/

    model
    <---------->

    		 
    X2:
    x1  x2
   /  \/  \
  /   /\   \
y1  y2  z1  z2
    |
    homomorphism
    |
    \|/
    		 «A model can be understood as an image, however with the speciality that in it the original is represented only in part, while on the other hand it goes beyond the original. ... Model = a system that is related to another one in a way such that a homomorphism of one system is isomorphic to an homomorphism of the other one» [SuB 48, my translation].
    Where 'homomorphism' ('isomorphism') is a mapping of the system's elements (which are related with each other) into an intermediate domain of related elements in a way such that elements related (and unrelated, for isomorphisms) in the system are mapping to elements that are also related (and unrelated, respectively).
    A:
    a
    /   \
       b     c   
    /|\
    |
    abstraction-from
    |
    A1:
    a
    /   \
       b     c   
    /|\         
    |          
    abstraction-from
    |_____

    isomorphic
    <---------->
    A2:
    x
    /   \
       y     z   
             /|\
              |
    abstraction-from
    _____|
    A':
    o
    /   \
       o     o   
    		  
    A':
    o
    /   \
       o     o   
    		 
    The top-down development method
    initial
    C0
    \ /
    ||
    \||/
    requirement
    C1 C2
    \ /
    ||
    \||/
    design
    C3 C4 C5 C6
    \ /
    ||
    \||/
    implementation
    C7 ... C12
    \ /
    ||
    \||/
    execution
    ...
    		The process inverse to abstraction: concretization or refinement, is the main activity in requirements-driven top-down software development: We refine an initial, unspecific model by filling-in the initially unknown details of what precisely is required (problem analysis), of how to solve the requirements in the abstract (design decisions), and of how to make a computer system carry out that solution for us (implementation decisions). This way a sequence of abstractions from the desired computation is produced which becomes more and more detailed, specifying the desired computation at lower and lower levels of detail/abstraction, until it is detailed enough for the computer to perform the actual computation.

    (-) The problem: In the process, we will sooner or later have amassed too much detail in the specification at that level of detail to remain comprehendable. (For complex systems, already the requirements have too many aspects.)

    => Conceptual modeling
    «While abstraction allows us to cope with complexity by ignoring non-essentail details, we may generally find more abstractions than we are able to comprehend. Conceptual modeling helps us in this situation by ordering abstractions based on certain relationships between them.» «Conceptual modeling is the process by which we order our knowledge of a domain of discourse in hierarchial rankings or orderings of abstraction, in order to obtain a better understanding of the domain of concern.» [VOOP 14ff]
    Here different kinds of abstraction are disinguished ^
    See also associative networks     		conceptual model
    of implementation:
    C7 ... C12
    :        :        :        :
    |        |        |        |
    C3 C4 C5 C6
    \  |        |  /
    \|        |/
    abstracted-from
    |        |
    C1 C2
    \   /
    abstracted-from
    |
    C0
     
    Ordered.
  • The object A at the abstraction end of the relation has less detail than the object X of which it is an abstraction. Hence abstraction is antisymmetric. And it is transitive: Abstraction A' of abstraction A of X is also an abstraction of X. Therefore it is possible to [say that we] understand X "at different levels of detail/abstraction"
  • While X can be a concrete or an abstract object, A is always an abstract object, an abstraction, a concept, since it misses some properties.
    cubic
    objects     		<--a-- cube
    [math obj]     		       equilateral
    triangle     		<--a-- triangle

    «Does it not require some pains and skill to form the general idea of a triangle, ... for it must be neither Oblique, nor Rectangle, neither Equilateral, Equicural, nor Scalenon; but all and none of these at once. In effect it is something imperfect, that cannot exist; an Idea wherein some parts of several different and inconsistent Ideas are put together» - John Locke (1632-1704)

    		• Logical symmetry, broken pragmatically.
  • Relational symmetry. Obviously from this definition, the model relation is symmetric (and reflexive). (Moreover, A2 and A1 are also models of X1 and X2.) But a model X3 of a model X2 of X1 is not necessarily a model of X1 (no transitivity).
  • Domain symmetry. There is also nothing intrinsically model-ish about a model. There is no a domain of modeled things on one hand and a domain of models on the other hand. Like the modeled, the model is an object, and either can be concrete or abstract.
    molecule <--m-- ball-&-stick
    model     		       cubic
    objects     		<--m-- cube
    [math obj]
    ({True,False},
    or, and)     		<--m-- (N0,+,×)        unicorn <--m-- statue
  • Pragmatic asymmetry. So, how does it come that we usually seem to know intuitively which object is the model and which one is the modeled? «The logical symmetry of [the model relation] is broken at the pragmatic level in as far as one of the systems - namely the "model" - is on technical grounds better to access, overview, or realize for the system observer» [SuB 49, my translation].
    • Not unique.
  • For non-trivial X, ie., for objects with more than one property, different abstractions A, B, ... exist, each abstracting from different of X's properties.
  • An abstraction A is abstraction not just of one object X, but also of other objects Y, ... which are different from X in those properties which A ignores.

    An abstraction A thus defines (specifies) an entire class of objects, the class of objects of which it is an abstraction.

    		• Not unique.
  • Obviously, there are normally several different objects available for use as model of a given object.
  • But also in the other direction the modeling relationship is not intrinsically unique: Although M may be intended as model of only one object X (pragamtic level), it will objectively be at the same also a model of certain other objects because it is "simplified and generalized." For example, a paper model of the Golden Gate might at the same time also be useable as model for other suspension bridges, like the Bosporus bridge in Istambul, Turkey.

    That is, an object M can not only be used as as model of one particular object X but of an entire class of objects (eg. the class of SuspensionBridges). This way, even a concrete object can be used as a representative or prototype to define (specify) a class of objects.