From the semantics of programs to the semantics of models, views and design processes.
Concern-oriented modeling belongs to a broader line of my work devoted to making explicit the meaning of formal constructions. If, in the 1970s, the semantics of programs was linked to the description of the states and transformations of an abstract machine, the same problem later moved toward the semantics of models, design processes and conceptual structures through which a designer understands and builds a system.
In this perspective, a concern is not merely a “preoccupation” expressed in natural language. It becomes a semantic criterion for organizing the model: it selects certain aspects of the system, brings them to the foreground, connects them through its own relations and imposes constraints on the design solution.
My first systematic encounter with semantics was related to the Vienna Method and to the description of program execution as a controlled transformation of an abstract state. The meaning of a program was given by the way in which a syntactic construction modified a universe of values, environments, stores and composite structures.
In my later research on the design of program products, the emphasis shifted from program execution to the designer’s activity. Design could no longer be reduced to a mechanical sequence of steps; it had to be understood as a cognitive and intentional activity in which the designer works with models, intermediate forms and partial representations of the product.
The conceptual thread therefore remains the same: a formal or technical object has meaning only if we can describe its internal structures, its relevant states and the transformations it undergoes. In the case of programs, these transformations are state transitions of an abstract machine; in the case of design, they are successive refinements of the mental and documentary models of the product.
In the context of concern-oriented modeling, a concern is a need, interest, desire, constraint, worry or involvement of an agent or stakeholder with respect to a product, a service or a process. It expresses dissatisfaction with a current state or an expectation concerning a future state.
For the designer, the stakeholders’ concerns become problems to be solved. They are received, interpreted, mediated and transformed into design objectives. Sometimes concerns are compatible; in other cases they are divergent or even contradictory. This tension explains why design cannot be completely algorithmized: it involves decisions, compromises, justifications and returns to earlier stages.
In a medical system, for example, the physician may have concerns about the effectiveness of the treatment and its side effects, the patient may have economic or comfort-related concerns, while health organizations may have concerns related to costs, prescription rules and compliance with protocols. The concrete treatment results from the implicit negotiation of these perspectives.
The principle of separation of concerns starts from a fundamental difficulty: a complex system cannot be understood and designed from a single viewpoint. It must be decomposed into relatively coherent conceptual zones, each dominated by a particular concern.
This separation is not merely a practical technique for dividing work. It is a form of semantic modularization. A component, a view or a facet becomes intelligible because it is organized around a criterion of meaning: what problem it solves, what properties it pursues, what behaviours it must preserve and what constraints it must satisfy.
Separation of concerns also requires a complementary operation: recomposition. If each concern produces a partial view of the system, the final product must reunite these perspectives into a coherent structure. Otherwise, analysis becomes fragmentation and design loses the unity of the system.
To describe this design activity, I used the concepts of view, facet and interform.
A view groups information about the product from a particular perspective: informational, functional, social, technological, organizational or material. Within a view, a facet brings together the properties and behaviours of the product that are relevant to a specific concern.
The interform generalizes this idea. It is an intermediate form of the product in the designer’s mind and in the project documentation: a structure containing attributes, facets, relations and knowledge that is still incomplete, yet sufficiently organized to allow the continuation of the design process.
As the designer resolves concerns, the interform changes: new facets appear, existing facets are completed, consistency predicates are checked, and variants or versions are introduced. Design can thus be described as a succession of interforms connected by refinement relations.
Concern-oriented modeling relies on a praxeological interpretation of design. An agent acts because he or she pursues an objective; the objective expresses a desired state; intention activates a plan; and the plan organizes the actions and resources needed to reach the objective.
In design, this scheme takes a specific form: the designer starts from requirements, interprets them through his or her own knowledge and available models, identifies unresolved concerns and produces a new intermediate form of the product. Each step is an attempt to reduce the distance between the current model and the desired product.
From this point of view, the concern plays a role similar to a semantic difference detected between what the model currently is and what it should become. Resolving it is a controlled transformation of the model.
In the 2008 article I used a medical scenario to illustrate this problem. A medical visit, a clinical episode or the prescription of a treatment can be seen as goal-oriented processes, unfolding over time and depending on several stakeholders.
The physician, the patient, the outpatient clinic, the insurance fund and the healthcare system do not view the treatment from the same perspective. Each introduces its own concerns: cure, cost, risk, compliance with guidelines, availability of resources and continuity of care. Modeling the treatment must make these perspectives visible; otherwise, both medical and informatics decisions remain insufficiently explained.
This opens the connection with medical informatics: clinical protocols, selection criteria for clinical trials, the electronic health record and digital healthcare ecosystems require models capable of separating, but also integrating, clinical, organizational, economic and informational concerns.
This theme lies at the intersection of several directions of my work: the semantics of programming languages, design methods, software engineering, ontologies and medical informatics. It marks the transition from execution semantics to the semantics of modeling and design decision-making.
PDF links can be added after the final file names are established in
the /pdf/ directory or in the individual article pages.
Concern-oriented modeling can be read as a stage in the evolution of an older idea: the meaning of an informatics artefact is not found only in its final form, but also in the intermediate structures, transformations and decisions that make it intelligible. From the abstract machine of operational semantics to the interform of design, the same question remains: how can we rigorously describe what, in the designer’s mind, gives meaning to the construction of a system?
