“The limits of my language mean the limits of my world.”
Ludwig Wittgenstein
Objectives
Models are first and foremost communication media; as far as system engineering is concerned, they are meant to support understanding between participants, from requirements to deployment.
Models are built with well-formed constructs (syntax) associated with agreed meanings (semantics). While correct syntax can be easily checked, that’s not the case for semantics as interpretations can easily flourish depending on methods, businesses, or engineering concerns.
Spoken vs Written Languages
Written languages are meant to overcome the specificities of spoken ones as to support continuity and consistency of human organizations and endeavors. For that purpose spoken words must be associated with signs, either at sound or at sense level.
- European languages born in the middle east started with sense but soon took the sound turn, breaking sayings into phonemes and using twenty-two basic alphabetical glyphs to record them.
- Oriental languages walked the meaning path all along, making sense of sayings and writing them down as logographic glyphs and graphemes.
By not being set from phonemes, logographic expressions are not bound to spoken ones; as a corollary, illustrated by Kanji, a single written language can support different spoken ones.
The way discourses are recorded and recalled clearly affects how meanings will take shape: with alphabetical writings they are built sequentially following the reading of words; with logographic ones they emerge wholly from ideograms.
As it happens, whereas models could be seen as epitomizing the oriental path, they are nonetheless grounded in the occidental rational thinking, and that discrepancy comes out when business requirements are to be translated into models.
Formal vs Natural Languages
Requirements are usually expressed with natural languages, possibly with parts written more formally with domain specific languages. Since the aim of engineering is to transform requirements into unambiguous specifications, it may help to clarify the differences between natural and formal languages:
- Scope: Natural languages can be applied to every topic, formal ones have specific targets.
- Terms: Both natural and formal languages make use of a finite set of lexical items, extensive for the former, circumscribed for the latter.
- Syntax: Natural languages combine terms according to their own syntactic rules, formal languages follow the rules of symbolic logic.
- Semantics: With natural languages, meanings of non syntactic terms are unstructured and may change; the meanings of formal languages are hierarchized, with a core set by fiat and a periphery derived by formal reasoning and therefore non subject to change.
Languages & Model Life-cycle
Stakeholders would prefer that systems be pliable to their needs as soon as those needs can be put into words. Since they pay the band, they should speak first. Unfortunately there is only so much of what they say which can be directly translated into a system’s agenda.
- At the source of the engineering process, business descriptions can only be achieved with natural or domain specific languages. Assuming otherwise, ie that full business requirements can be readily expressed in some model or system parlance, would be putting the cart before the horse and ignoring the engineering problem altogether.
Requirements are not meant to turn up as models lest they confuse contexts and symbolic representations
- At the specification end of the engineering process, some coding language is introduced as befits the technology used to implement symbolic objects.
Clearly, the main problem lies in between, where the symbolic representations of business contents have to be defined in such a way as to provide for traceability. And for that purpose more must be said about modelling languages and their intensional and extensional capabilities.
Languages and Representations
Models should be classified about their purpose, namely what they represent (instances or types) and their footprint on target (partial or complete):
- Extensional and partial: the model describes selected features of actual occurrences (e.g organization chart, IT service management).
- intensional and partial: the model describes selected features of types (e.g functional architecture, business strategy).
- Extensional and complete: the model describes all features of actual occurrences (e.g business process, system configuration).
- intensional and complete: the model describes all features of types (e.g business rules, sw design).
That can be applied to the basic models of system engineering:
- Business requirements need extensional (denotative) languages, i.e ones which can explicitly name and describe objects and behaviors. These languages cannot be formal since they must condone partial or ambiguous statements (business is often said to bloom on discrepancies).
- Analysis models describe the semantics and constraints of symbolic representations. As such they will need languages with intensional (connotative) capabilities. Yet, through their mapping to requirements, those (modelling) languages will also have implicit extensional meanings. But the rationale for analysis models is to provide a formal symbolic description to be shared by requirements and design; it must be noted that neither has to be complete since analysis models don’t have to cover every details of requirements or design (cf traceability).
- Regarding design, modelling languages have no use for extensional capabilities since the relevant physical objects, ie extensions, are system components directly derived from system specifications. However, they must support complete and formal descriptions of component features.
Mapping context and system extensions through analysis models.
This approach can be supported by the OMG’s Unified Modeling Language; it revisits OMG’s MDA distinction between Computation Independent Models (CIM), Platform Independent Models (PIM), and Platform Specific Models (PSM) with a shift in paradigm:
- Business models (or CIM) are never seen as conceptual models but only as the expression of specific concerns.
- Model transformation is redefined in order to distinguish between extensions (CIM/PIM, using analysis patterns) and intentions (PIM/PSM, using design patterns).
That brings significant consequences for traceability and validation.
Languages & System Architecture
A dual dimension is to be added to model life-cycle in order to distinguish between intrinsic complexity (the problem) and its formulation (the model).
The question is to what extent the formulation facilitates or hinders the understanding and management of intrinsic complexity and that clearly depends upon the origin and nature of complexity. As far as software is concerned, complexity can originate from three basic tiers:
- The first one is the domain itself, i.e the complexity of data and algorithms.
- The second one is the application, i.e if the domain is accessed and modified by a single user (standalone) or by many simultaneously.
- The third one is the system: is the application to be executed under a single control, or should the execution be synchronized across distributed systems.
Whatever the argument (transparency, traceability, testability, modularity, etc.) all concur to a clear distinction between tiers of complexity. Since those tiers coincide with architectural constraints, they can be easily combined with MDA model layers and provide a principled basis for model engineering.
- The persistency tier set units, actual or symbolic, whose identity and consistency must be maintained independently of business activities. Actual units are active and passive objects with communication channels. Symbolic units (CIMs) can be associated to actual units or stand for documental objects. Their features are described by attributes whose semantics are defined independently by functional domains. Functional units (PIMs) provide a consolidated description of persistency units, and design units describe their implementation.
- The second tier deal with shared transient units, actual or symbolic: their identity and consistency has only to be maintained within the context of business activities, possibly in collaboration. Actual units describe the execution states and transitions of business processes. Symbolic ones (CIMs) define the processing rules and can be associated to execution states or describe computations independently of their actual execution. Contrary to the persistency tier, the format and semantics of messages and operations are defined locally. Functional units (PIMs) provide a consolidated description of execution and control units, with messages and operations properly accounted for. Design units describe their implementation, including the resources and mechanisms supporting collaborations.
- The third tier deal with transient units whose consistency can be checked locally and therefore has no impact on architectural constraints. That include external events (actual units) and roles played by active objects (symbolic units). It must be noted that external events may be associated to persistent (record) or transient (message) symbolic representations. Functional units (PIMs) provide a consolidated description of user interfaces, and design units describe their implementation.
On that account, modeling languages are to be assessed with regard to the help they provide for the alignment of actual business objects and behaviors on one hand, with architecture functional layers on the other hand.
Further Readings
- Modeling Paradigm
- Models, Architectures, Perspectives (MAPs)
- From stories to Models
- On Pies and Skies: Abstraction in Models
- Modeling Languages: Differences Matter
- Alignment for Dummies
- Alignment: from Entropy to Abstraction
External Links
- J. Sowa, “Signs and Reality”, · December 2015
Very interesting article. It looks like you have incorrectly associated ‘Intentional (connotative)’ and ‘Extensional (denotative)’ I thought Intentional and denotative refer to the dictionary definition. Extensional and connotative refer to examples or concepts suggested by the term. Is that correct?
My understanding is that denotative references directly point to objects or phenomena while connotative ones do that through semantic constructs.
The Caminao approach deals with systems, and the objective is to develop their software components. But initial requirements must describe the behavior of all functional components because decisions about their implementation (human, device, software) is still undecided.
As illustrated by Standford University, which put Computer Science as a part of Symbolic Systems, the purpose of intermediate language is to translate specific (or natural) ones into symbolic representations executable by computers.
Remy:
Very good article.
Some questions:
Is this theory and explanation applicable only to software or any requirements and implementations?
If people used only natural language to describe their needs, it is still possible to make things to meet the needs (with some trials). That being so, what purpose do the intermediate languages serve?