Objects and Representations
Representations are objects on their own and the objective of system modelling is to design useful and effective symbolic objects that will stand for their business counterparts.
If they are to be processed, those symbolic representations of objects and activities must be physically implemented. The specific aim of architecture driven modelling is to identify the constraints to be supported whatever the technology used to store the representations, clay tablets, codices, optical discs, or holograms.
Models: Description vs Specification
A flat world populated with standalone objects could be represented by successive snapshots; but that’s not the case: variants and complexity rule over representations of individual objects and activities. Something is needed to mediate in-between if actual objects or processes are to be consistently mapped into their symbolic counterparts.
At first, models are introduced as descriptions of objects and behaviors, something like reference manuals or user’s guides to be shared and understood by all concerned. Those description models may subsequently be used to develop supporting systems, but such development will be achieved through another kind of models, namely specification ones. In any case, with or without specification models, descriptive ones are meant to stand by themselves and their validity should not depend on their subsequent use for system development.
The main challenge of Architecture Driven System Modelling is to extract upfront the core subset of features that will have to be supported by the functional architecture. For that purpose requirements should be mapped into six stereotypes of Computation Independent Model artifacts:
- Physical objects, active or passive, agents being defined as active objects with organizational capability.
- Documental (aka customary) objects, possibly but not necessarily associated to physical ones.
- Roles, representing objects as they appear within activities.
- Events, representing relevant changes from a business perspective.
- Activities, describing processing rules and flows.
- Processes, describing the actual execution of activities.
This dual description of systems, as actual objects and processes on one hand, symbolic representations on the other hand, is the backbone of architectural driven modelling. Whereas it is based on well accepted modeling concepts, their use come with significant shift in paradigm: they no longer appear within cascading models but as complementary descriptions of simultaneous facets.
Those artifacts will have to be translated into standard types for Platform Independent Models:
- Symbolic representation of boundaries, persistency, control, flows and interfaces.
- Symbolic description of processes in terms of events, actions and states.
Further Reading
- Modeling Paradigm
- Modeling Languages: Differences Matter
- Languages and Models
- Objects & Aspects
- Event Oriented Analysis & Object Oriented Design
- iStar & the Requirements Conundrum
External Links
- J. Sowa, “Signs and Reality”, · December 2015