What is to be Represented

“There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy”

William Shakespeare

Objective

As Plato would have said, wherever we look, all we can see are mental representations, latent or overt. If we take a step further and try to think about it, they develop into symbolic placeholders ready for what would come to our mind.

Yet, when confronted with the challenging complexity of our endeavors, we have to lump together the core symbolic representations of relevant aspects and drop whatever unduly catches our attention. That’s called modeling. As it happens, that is not the end of it and there is a specification tail to the descriptive head, sometimes even a continuum of models, from subjective representations bound by imagination, to engineering blue-prints, driven by technology. Along that line engineering models are clearly circumscribed, from requirements to system design, yet among them system modeling brings in specific challenges.

Compared to software engineering, whose descriptive and specification models can be managed separately, system engineering is often entwined with contexts in such a way that models have to target their own changing scope and confines, i.e descriptive and specifications models may overlap. While available, formal theories of symbolic representation are rarely, if
ever, applied to those challenges which are usually dealt with at practical level. That runs counter to the more principled approaches used latter on the engineering process, for design or programming, and the objective is to bridge that gap with a modeling framework.

A few words about Reality and Abstractions

The term of abstraction being much too vague to be of any use, reality is to be examined through three distinctions:

• Actual (natural phenomena) vs symbolic (models).
• Artifact (table or chair) vs natural (electrons and nuclei):  the former are built (explicitly or not) from their symbolic representation, the latter (objects or phenomena) must be “discovered”.
• Live or inanimate: the former come as individuals, the latter (other than artifacts) have no identities of their own.

It must be added that, as far as science is concerned, the perception of natural phenomena usually requires a symbolic apparatus. But engineering is not science and models are built with well defined purposes, namely to describe what is expected and prescribe how to achieve it.

Systems, Models, and Programs

Systems combine software components with agents and devices. Models describe all systems components while programs can only deal with software ones.

Given that models are abstractions, and abstractions are meaningless without context and purpose, it may help to distinguish between perspectives and abstraction levels.
Assuming that the context is the enterprise and the purpose is information systems, there are three basic perspectives: business and enterprise, system functionalities, and platform technologies.
Perspectives can be combined with formal abstraction levels as defined by modeling language capabilities:

• Extensional and partial: the model describes selected features of actual occurrences (e.g organization chart)
• Intensional and partial: the model describes selected features of types (e.g functional architecture or business strategy)
• Extensional and complete: the model describes all features of actual occurrences (e.g business process or system configuration).
• Intensional and complete: the model describes all features of types (e.g programs or authorizations)

Business Concerns & Symbolic Representations

Information systems are built to support business activities whatever they are, trading futures or controlling water canals. To be of any use systems must keep some record of their environment, and keep it separate, i.e as symbolic representations. The scope of required representations defines the footprint of applications; access and coupling constraints will define the functional architecture of the supporting system.

Symbolic representations are system objects standing for actual business objects or processes:

• Persistent representations record the state of business objects independently of activities.
• Transient representations record the state of objects while activities are performed.

Persistent and transient representations do not necessarily coincide while processes are running, but they must be reconciled at completion.

Systems & Representations

Systems are designed to process symbolic objects which may or may not represent something (object or activity) in their context. When they do represent something, symbolic representations may have to be kept in sync with their context counterpart. Depending on requirements and technical capabilities,  synchronization may have to be supported instantly or some discrepancies are deemed to be accepted.

Hence, if synchronization requirements are to be properly defined, models must keep a distinction between contexts and system objects. That may be illustrated by two classical examples, users and parties:

• Users are agents interacting with systems. They may appear in models as roles in activities (actor in UML parlance), actual persons in organizations, and entities in system records. If authorizations are to be managed independently those three artifacts must be modeled separately.
• Set on its own, accounting parties are often modeled as a generalization of Person and Organization. The unfortunate consequence is to merge “actual” entities with their accounting representation; in other words persons and organizations would not exist without being simultaneously a party, and that party would have to be uniquely defined by some specific system.

That confusion between the representation of business and system objects goes a long way to explain misgivings between business and system analysts.