Squared Outline: States

States are used to describe relevant aspects in contexts and how the changes are to affect systems representations and behaviors.

On that account, events and states are complementary: the former are to notify relevant changes, the latter are to represent the partitions (²) that makes these changes relevant. Transitions are used to map the causes and effects of changes.

  1. State of physical objects.
  2. State of processes’ execution.
  3. State of actors’ expectations.
  4. State of symbolic representations.

Beside alignment with events, defining states consistently across objects, processes, and actors is to significantly enhance the traceability and transparency of architectures designs.


Squared Outline: Events

In line with the Symbolic Systems paradigm, events are best understood in terms of interactions between systems (or enterprises) and the environment they represent (or live off).

Events with regard to nature and coupling

On that account events are to be associated with four kinds of notifications:

  1. Actual (aka non symbolic) changes in the state of objects.
  2. Actual (aka non symbolic) changes in the state of activities.
  3. Changes in the state of expectations (e.g requests/acknowledgments).
  4. Neutral changes in symbolic representations (e.g messages).

That classification is of particular importance for the definition of time which, taking a leaf from Einstein, is the only reason so that events don’t happen at once.


UML’s Semantic Master Key, Lost & Found


When its first version was published twenty years ago the prognosis for OMG’s UML (Unified Modeling Language) was of rapid and wide expansion. It didn’t happen, and notwithstanding a noteworthy usage, UML has not become  “the” unified modeling language. Beyond the diverse agendas of methods and tools providers, this falling short may have something to do with a lack of robust semantics, as illustrated by UML 2.5’s halfhearted attempt to define individuals.

Actual & Digital Identities (Jonathan Monk)

UML 2.5 Aborted Attempt with Individual 

UML 2.5 has often been presented as an attempt to redress the wayward and increasingly convoluted paths taken by the previous versions. Yet, beside some useful (and long needed) clarifications and adjustments, its governing group failed to agree on some compact and unambiguous semantics and had to content itself with perfunctory guidelines introduced as an afterthought.

As a matter of fact the OMG committee may have tried to get its semantics in order, as suggested by the chapter “On semantics” making the point right away with a distinction between the things to be described and the categories to be applied:

“A UML model consists of three major categories of model elements [classifiers, events, and behaviors], each of which may be used to make statements about different kinds of individual things within the system being modeled (termed simply “individuals”in the following)”.

That straightforward understanding (UML is meant to describe individual objects, events, or behaviors) could have provided the semantic cornerstone of a sound approach. Surprisingly, and for obscure reasons, it is soon smudged by syntactical overlapping and semantic ambiguity, the term “individual” being used indifferently as adjective and noun, and then appears to be restricted to classifiers only. That leaves UML with a dearth of clear semantics regarding its scope.

Individual as a Semantic Master Key

The early dismiss of individual as a constitutive concept is unfortunate because, taking a leaf from Archimedes, it could have been the fulcrum on which to place the UML lever.

To begin with, no modeling language, especially one supposed to be unified, can do without some convincing semantics about what it is supposed to describe:

  • Analysis (aka extensional) models are descriptive as they deal with external individuals, things or behaviors, capturing their relevant aspects.
  • Design (aka prescriptive) models are prescriptive as they describe how to build software components and execute processes.
A rigorous identification mechanism must ensure a persistent and consistent mapping of individuals

As analysis and design models serve different purposes they clearly differ. Nonetheless, since UML is meant to straddles the divide between business and systems realms, some rigorous mechanism must ensure a persistent and consistent mapping of individuals.

That could have been neatly achieved with a comprehensive and unified interpretation of individuals, combined with a clear taxonomy of the aspects to be modeled:

  • Individuals are whatever occurrences (in business or systems contexts) with identities of their own.
  • These individuals (objects, events, or behaviors) can be specified with regard to their structure and relationships.

The logical primacy of this approach is reinforced by its immediate, practical, and conclusive benefits for business processes modeling on one side, model based engineering processes on the other side.

A Key to Business Processes Modeling

As far as business processes are concerned, modeling the part played by supporting systems turns around few critical issues, and these issues can be dealt more clearly and consistently when set in reference to individuals taxonomy (objects, behaviors, events) e.g:

  • Functional or non functional requirements ? The former can be associated with individuals, the latter cannot.
  • Architecture or application ? The former affect the specification of interactions between individuals, the latter affect only their local features.
  • Synchronous or asynchronous ? Specifications can only be made with regard to life-cycles and time-frames: system (objects), process (behaviors), or instant (event).
  • Structures or Relationships ? The former are bound to individuals’ identity, the latter are used between different individuals.
  • Inheritance or Delegation ? The former is used for the specification of structural or functional features, the latter for individuals’ behaviors.

More generally that understanding of individuals should greatly enhance the alignment of systems functional architectures with business processes.

A Key to Model Based Systems Engineering

As should be expected from a lack of semantic foundations, one of the main characteristics of the UML community is its fragmented practices, regrouped around diagrams (e.g Use case or Class) or task (e.g requirements analysis or code generation).

The challenge can be directly observed for model based system engineering and software development: with the exception of Statecharts for RT modeling, Class diagrams are the only ones used all along engineering processes; the others, when used, are reduced to documentation purposes. That bottleneck in development flows can be seen as the direct consequence of UML restricted semantics: since behaviors are not identified as individuals in their own right, their description cannot be directly translated into software artifacts, but have to be understood as part of active objects descriptions before being translated into class diagrams. Hence the apparent redundancy of corresponding diagrams.

As a corollary, reinstating a unified semantics of individual for both classifiers and behaviors could be the key to a seamless integration of the main UML diagrams. Most important, that would bear out the cross benefits of combining UML and MBSE.

A Key to Enterprise Architecture

Enterprise architecture can be defined in terms of territories and maps, the former materialized by the realities of enterprise organization and business operations, the latter by the assortment of charts, blueprints, or models used to describe enterprise organization, business processes, IT systems, and software applications. Along that understanding the whole endeavor depends on the ability to manage the continuity and consistency of charting; and that cannot be done without a unified and persistent identification mechanism of objects and processes across business, enterprise, and systems.

Further Readings

Use Cases & Action Semantics


Use cases are meant to describe dialogues between users and systems, yet they usually don’t stand in isolation. On one hand they stem from business processes, on the other hand they must be realized by system functionalities, some already supported, others to be newly developed. As bringing the three facets within a shared modeling paradigm may seem a long shot, some practical options may be at hand.

Use cases should leave no room for interpretations (Jonathan Monk)

To begin with, a typical option would be to use the OMG’s Meta-Object Facility (MOF) to translate the relevant subset of BPM models into UML ones. But then if, as previously suggested, use cases can be matched with such a subset, a more limited and pragmatic approach would be to introduce some modeling primitives targeting UML artifacts.

From BPM to UML: Meta-model vs Use cases.
From BPM to UML: Meta-model vs Use cases.

For that purpose it will be necessary to clarify the action semantics associated with the communication between processes and systems.

Meta-models drawbacks

Contrary to models, which deal with instances of business objects and activities, meta-models are supposedly blind to business contents as they are meant to describe modeling artifacts independently of what they stand for in business contexts. To take an example, Customer is a modeling type, UML Actor is a meta-modeling one.

To stress the point, meta-languages have nothing to say about the semantics of targeted domains: they only know the language constructs used to describe domains contents and the mapping rules between those constructs.

As a consequence, whereas meta-languages are at their best when applied to clear and compact modeling languages, they scale poorly because of the exponential complexity of rules and the need to deal with all and every language idiosyncrasies. Moreover, performances degrade critically with ambiguities because even limited semantics uncertainties often pollute the meaning of trustworthy neighbors generating cascades of doubtful translations (see Knowledge-based model transformation).

Factoring a core with trustworthy semantics (b) will prevent questionable ones from tainting the whole translation (a).

Yet, scalability and ambiguity problems can be overcame by applying a core of unambiguous modeling constructs to a specific subset, and that can be achieved with use cases.

Use Cases & UML diagrams

As it happened, the Use Case can be seen as the native UML construct, the original backbone around which preexisting modeling artifacts have been consolidated, becoming a central and versatile hub of UML-based development processes:

  • Sequence diagrams describe collaborations between system components but can also describe interactions between actors and systems (i.e use cases).
  • Activity diagrams describe the business logic to be applied by use cases.
  • Class diagrams can be used for the design of software components but also for the analysis of business objects referenced by use cases.
  • State diagrams can be used for the behavior of software components but also for the states of business objects or processes along execution paths of use cases.

Use cases at the hub of UML diagrams
Use case as Root Sequence

Apart of being a cornerstone of UML modeling, use cases are also its doorway as they can be represented by a simple sequence diagram describing interactions between users and systems, i.e between business processes and applications. So the next step should be to boil down the semantics of those interactions.

Use Cases & Action Semantics

When use cases are understood as gateways between business users and supporting systems, it should be possible to characterize the basic action semantics of messages in terms of expectations with regard to changes and activity:

  • Change: what process expects from system with regard to the representation of business context.
  • Activity: what process expects from system with regard to its supporting role.

Basic action semantics for interactions between users (BPM) and systems (UML)
Basic action semantics for interactions between users (BPM) and systems (UML)

Crossing the two criteria gives four basic situations for users-to-system action semantics:

  • Reading: no relevant change in the environment has to be registered, and no activity has to be supported.
  • Monitoring: no relevant change in the environment has to be registered, but the system is supposed to keep track on some activity.
  • Achievement: the system is supposed to keep track on some specific change in the environment without carrying out any specific activity.
  • Accomplishment: the system is supposed to keep track on some specific change in the environment and support associated activity.

These action primitives have to be wrapped into interaction ones relating to changing expectations of users and systems.

State machine can fully support action semantics

When use cases are positioned at the center of UML diagrams, those situations can be neatly modeled with state machines for actors’ expectations, business objects, and execution.

UC specified with State machine.

Use Cases & Modeling Patterns

If use cases describe what business processes expect from supporting systems, they can be used to map action semantics to UML diagrams:

  • Reading: class diagrams with relevant queries.
  • Monitoring: activity diagrams with reference to class diagrams.
  • Achievement:  class diagrams with associated state diagrams.
  • Accomplishment:  activity diagrams with associated state diagrams and reference to class diagrams.

From use cases action semantics to UML diagrams
From use cases action semantics to UML diagrams

While that catalog cannot pretend to fully support requirements, the part it does support comes with two critical benefits:

  1. It fully and consistently describes the interactions at architecture level.
  2. It can be unambiguously translated from BPM to UML.

On that basis, use cases provide a compact and unambiguous kernel of modeling constructs bridging the gap between BPM and UML.

Further Reading

Business Processes & Use Cases


As can be understood from their theoretical basis (Pi-Calculus, Petri Nets, or State Machines), processes are meant to describe the concurrent execution of activities. Assuming that large enterprises have to keep a level of indirection between operations and business logic, it ensues that activities and business logic should be defined independently of the way they are executed by business processes.

Communication Semantics vs Contexts & Contents (G. Winogrand)

For that purpose two basic modeling approaches are available:  BPM (Business Process Modeling) takes the business perspective, UML (Unified Modeling Language) takes the engineering one. Yet, each falls short with regard to a pivotal conceptual distinctions: BPM lumps together process execution and business logic, and UML makes no difference between business and software process execution. One way out of the difficulty would be to single out communications between agents (humans or systems), and specify interactions independently of their contents and channels.

Business Process: Communication + Business Logic

That could be achieved if communication semantics were defined independently of domain-specific languages (for information contents) and technical architecture (for communication channels). As it happens, and not by chance, the outcome would neatly coincide with use cases.

Linguistics & Computers Parlance

Business and functional requirements (see Requirements taxonomy) can be expressed with formal or natural languages. Requirements expressed with formal languages, domain-specific or generic, can be directly translated into some executable specifications. But when natural languages are used to describe what business expects from systems, requirements often require some elicitation.

When that challenge is put into a linguistic perspective, two school of thought can be considered, computational or functional.

The former approach is epitomized by Chomsky’s Generative Grammar and its claim that all languages, natural or otherwise, share an innate universal grammar (UG) supporting syntactic processing independently of their meanings. Nowadays, and notwithstanding its initial favor, that “computer friendly” paradigm hasn’t kept much track in general linguistics.

Alternatively, the functionalist school of thought considers linguistics as a general cognitive capability deprived of any autonomy. Along that reasoning there is no way to separate domain-specific semantics from linguistic constructs, which means that requirements complexities, linguistic or business specific, have to be dealt with as a lump, with or without the help of knowledgeable machines.

In between, a third approach has emerged that considers language as a functional system uniquely dedicated to communication and the mapping of meanings to symbolic representations. On that basis it should be possible to separate the communication apparatus (functional semantics) from the complexities of business (knowledge representation).

Processes Execution & Action Languages

Assuming the primary objective of business processes is to manage the concurrent execution of activities, their modeling should be driven by events and their consequences for interactions between business and systems. Unfortunately, that approach is not explicitly supported by BPM or UML.

Contrary to the “simplex” mapping of business information into corresponding data models (e.g using Relational Theory), models of business and systems processes (e.g Petri Nets or State Machines) have to be set in a “duplex” configuration as they are meant to operate simultaneously. Neither BPM nor UML are well equipped to deal with the task:

  • The BPM perspective is governed by business logic independently of interactions with systems.
  • Executable UML approaches are centered on software processes execution, and their extensions to action semantics deal essentially on class instances, features value, and objects states.

Such shortcomings are of no serious consequences for stand-alone applications, i.e when what happens at architecture level can be ignored; but overlooking the distinction between the respective semantics of business and software processes execution may critically hamper the usefulness, and even the validity, of models pertaining to represent distributed interactions between users and systems. Communication semantics may help to deal with the difficulty by providing relevant stereotypes and patterns.

Business Process Models

While business process models can (and should) also be used to feed software engineering processes, their primary purpose is to define how concurrent business operations are to be executed. As far as systems engineering is concerned, that will tally with three basic steps:

  1. Dock process interactions (aka sessions) to their business context: references to agents, business objects and time-frames.
  2. Specify interactions: references to context, roles, events, messages, and time related constraints.
  3. Specify information: structures, features, and rules.

Communication with systems: dock to context (1), interactions (2), information (3).
Communication with systems: dock to context (1), interactions (2), information (3).

Although modeling languages and tools usually support those tasks, the distinctions remain implicit, leaving users with the choice of semantics. In the absence of explicit guidelines confusion may ensue, e.g between business rules and their use by applications (BPM), or between business and system events (UML). Hence the benefits of introducing functional primitives dedicated to the description of interactions.

Such functional semantics can be illustrated by the well known CRUD primitives for the creation, reading, updating and deletion of objects, a similar approach being also applied to the design of domain specific patterns or primitives supported by functional frameworks. While thick on the ground, most of the corresponding communication frameworks deal with specific domains or technical protocols without factoring out what pertains to communication semantics independently of information contents or technical channels.

Communication semantics should be independent of business specific contents and systems architectures.
Communication semantics should be independent of business specific contents and systems architectures.

But that distinction could be especially productive when applied to business processes as it would be possible to fully separate the semantics of communications between agents and supporting systems on one hand, and the business logic used to process business flows on the other hand.

 Communication vs Action Semantics

Languages have developed to serve two different purposes: first as a means to communicate (a capability shared between humans and many primates), and then as a means to represent and process information (a capability specific to humans). Taking a leaf from functional approaches to linguistics, it may be possible to characterize messages with regard to action semantics, more precisely associated activity and attendant changes:

  • No change: messages relating to passive (objects) or active  (performed activity) states.
  • Change: messages relating to achievement (no activity) or accomplishment (attendant on performed activity).

Basic action semantics for interactions between users (BPM) and systems (UML)

Communication semantics can then be fully rounded off by adding changes in agents’ expectations to the ones in the states of objects and activities, all neatly modeled with state machines.

Communication semantics: changes in expectations, objects, and activities.

It must also be noted that factoring out the modeling of agents’ expectations with regard to communications is in line with the principles of service oriented architectures (SOA).

Additionally, transitions would have to be characterized by:

  • Time-frame: single or different.
  • Address space : single or different.
  • Mode: information, request for information, or request for action.

Organizing business processes along those principles, would enable the alignment of BPMs with their UML counterpart.

Use Cases as Bridges between BPM & UML

Use cases can be seen as the default entry point for UML modeling, and as such they should provide a bridge from business process models. That can be achieved by if use cases are understood as a combination of interactions and activities, the former obtained from communications as defined above, the latter from business logic.

Use Cases are best understood as a combination of interactions and business logic
Use Cases are best understood as a combination of interactions and business logic

One step further, the distinction between communication semantics and business contents could be used to align models respectively to systems and software architectures:

Last but not least, the consolidation of models contents at architecture level would be congruent with modeling languages, BPM and UML.

Further Reading

External Links

Use Cases Shouldn’t Know About Classes


Uses cases are meant to describe how users interact with systems, classes are meant to describe software components, including those executing use cases. It ensues that classes are introduced with the realization of use cases but are not supposed to appear as such in their definition.

Users are not supposed to know about surrogates

The Case for Use Cases

Use cases (UCs) are the brain child of Ivar Jacobson and often considered as the main innovation introduced by UML. Their success, which largely outdoes UML’s footprint, can be explained by their focus and simplicity:

  • Focus: UCs are meant to describe what happens between users and systems. As such they are neatly bounded with regard to their purpose (UCs are the detailed parts of business processes supported by systems) and realization (UCs are implemented by software applications).
  • Simplicity: while UCs may eventually include formal (e.g pre- and post-conditions) and graphical (e.g activity diagrams) specifications, they can be fully defined and neatly circumscribed using stick actors (for the roles played by users or any other system) and ellipses (for system behaviors).

Use Cases & UML diagrams

As it often happens to successful innovations, use cases have been widely interpreted and extended; nonetheless, the original concepts introduced by Ivar Jacobson remain basically unaltered.

The Point of Use Cases

Whereas focus and simplicity are clearly helpful, the primary success factor is that UCs have a point, namely they provide a conceptual bridge between business and system perspectives. That appears clearly when UCs are compared to main alternatives like users’ stories or functional requirements:

  • Users’ stories are set from business perspective and lack explicit constructs for the parts supported by systems. As a consequence they may flounder to identify and describe business functions meant to be shared across business processes.
  • Conversely, functional requirements are set from system perspective and have no built-in constructs linking business contexts and concerns to their system counterparts. As a consequence they may fall short if business requirements cannot be set upfront or are meant to change with business opportunities.

Along that understanding, nothing should be done to UCs that could compromise their mediating role between business value and system capabilities, the former driven by changes in business environment and enterprise ability to seize opportunities, the latter by the continuity of operations and the effective use of technical or informational assets.

Business Objects vs Software Components

Users’ requirements are driven by concrete, partial, and specific business expectations, and it’s up to architects to weld those diverse and changing views into the consistent and stable functional abstractions that will be implemented by software components.

Users' requirements are driven by concrete, partial, and specific concerns
Users’ requirements are driven by concrete, partial, changing and specific concerns, but supported by stable and fully designed software abstractions.

Given that double discrepancy of objectives and time-scales, business analysts should not try to align their requirements with software designs, and system analysts should not try to second-guess their business counterparts with regard to future business objects. As a consequence, respective outcomes would be best achieved through a clear separation of concerns:

  • Use cases deal with the business value of applications, mapping views on business objects to aspects of classes.
  • Functional architectures deal with assets, in particular the continuous and consistent representation of business objects by software components as described by classes.

How to get best value from assets

As it happens, that double classification with regard to scope and purpose should also be used to choose a development model: agile when scope and purpose can be united, phased approach otherwise.

Further Reading


UML & Users’ Concerns


Whereas UML has been brought to existence by very wise men under very propitious skies, the initial enthusiasm and first successes have never been transformed into wider acceptance and customary usage; subsequent updates and extensions didn’t help and may even have triggered some anticlimax. More than fifteen years after its launch, the utilization of UML remains limited, both in breadth (projects developed) and depth (features effectively used).  Moreover, the UML house is deeply divided and there isn’t much consensus among the few that use it comprehensively and consistently, principally to support domain specific languages (DSL).

The Divided House of UML (Anne Desmet)

Certainly, there must have been a wrong turn somewhere, possibly at the UML2 crossing when the OMG committee lost sight of users modeling needs and took the road to meta-models. Considering UML’s shrinking stamp and dwindling relevancy, that road appears more and more like a dead-end; but it may be still possible to get back on track and retrieve the Us of the UML: unified semantics for all and sundry users.

Where to Look

Whether on driving or back seats, respectively for model driven or agile methods, models are widely accepted as a necessary constituent of development processes. Nonetheless, and despite being the only official standard, UML standing appears to falter, up to be already seen as a cold case. As suggested by Ivar Jacobson (“The road ahead for UML“), one of its main drawback would be its lack of modularity with regard of users needs. If that flaw is to be fixed, the question is where to look: directly at language level, or at supporting mechanisms.

Given the broad consensus that surrounded the initial project, one should at first look for a sound and stable subset to be used as a backbone and fleshed out according specific contexts, purposes or users. As a matter of fact that is what stereotypes and profiles are meant to do, except that without a well-defined backbone of unambiguous constructs, the only possible outcomes are domain specific languages. So, one should first consider how the separation of concerns  could be better supported by language constructs.

Language Constructs, Model, and Separation of Concerns

Separation of Concerns

Despite its roots in the Object Oriented paradigm, UML has demonstrated its adaptability to all and every method or domain. Unfortunately, being a Jack of all trades often means a master to none, and the use of UML is clearly frustrated by its versatility; that translates either into shallow usage of ambiguous semantics, or into extensions targeting specific domains or technologies.

On the ground, three mechanisms can be used to make for the lack of focus: stereotypes, views, and customization.

  • UML stereotyping mechanism support predefined constructs for problem (business objects and processes) or solution (system architecture and object design) spaces. Stereotypes can be grouped into profiles, e.g for specific business domains or technical architectures.
  • Views (or perspectives) organize access to models according contents: logical, physical, conceptual, pragmatic, etc
  • Tool customization  organizes access to models according users purposes and skills: analyst, architect, designer, developer, etc.

While those approaches have their benefits, they are set independently of languages constructs, either as UML extensions (stereotypes and profiles), or defined from outside by development methodologies (views) or projects organization (customization). As a consequence, they have little or no effect on the simplicity or efficiency of UML; they may even add to confusion and complexity when overlapping stereotypes are introduced to support multiple taxonomies, e.g technical architectures and business domains.

Language Constructs (a), Stereotyped Model (b), Combined Views or Profiles (c)

That may point to a clear direction: given the potency of the stereotyping mechanism and its pivotal role in UML utilization, significant benefits could be achieved through a better integration into core language constructs, even if that entails some constraints or limitations. Two straight modifications should be considered:

  • Model layers: language constructs should be re-organized along architectural concerns for enterprise (business processes), system (functionalities), and platforms (components).
  • Stereotypes visibility: language constructs should support the distinction between local taxonomies and “unified” ones, the former set with limited scope and visibility, the latter meant to be applies across layers.

While both modifications can be carried out on their own, their benefits would be boosted if they were set within the broader MDA framework and supported by specific language constructs.

Modular Language Constructs

Given the growing intricacy, ubiquity and diversity of systems, UML complexity and versatility should clearly be in demand, and the problem is to harness those capabilities according the needs and skills of the different kinds of users.

That’s arguably a critical flaw of UML, which lumps together essential with secondary constructs, as well as definite with ambivalent semantics. That brings weighty consequences, both for users and models:

  • Steep or even abrupt learning curve: confronted to a wall of mixed constructs users have to master the whole upfront, whatever their needs and skills.
  • Blurred concerns: describing various specific contents with the same ambivalent constructs will either distort language semantics, or blur concerns specificities.
  • Corrupted transformation: whatever the modeling tools, the bad apples of inputs will usually corrupt the whole of outputs. In other words any advance in model driven development requires a sound backbone of unambiguous language constructs.

As noted above, language constructs can be regrouped along two perspectives, one directly associated with users architectural concerns, the other  reflecting the scope and visibility of targeted artifacts. While there is no particular reason to match complexity levels with architectural concerns, mapping them to granularity has a clear rationale. Such a “born again” UML would distinguish between two levels of language constructs:

  1. Those pertaining to objects and activities identified by architectures, whatever their nature: enterprise, systems or platforms.
  2. Those used to describe internals of objects and activities independently of their aspects and behaviors at architecture level.

Model Transformation: lumped (b) vs differentiated (a) language constructs.

That re-configuration would bring modularity to the language, enabling a smooth learning curve. More importantly, a clear-cut separation of concerns will enable some kind of Just-In-Time model transformation:  instead of cumulative noises (b), one will get separate transformations for models architectural backbone on one hand, contingent specificities on the other hand (a). And that could be a real game-changer for lean and fit models.

While that could be achieved by different means, a simple solution would be to use the stereotyping mechanism to describe supporting structures of enterprise, functional, and technical architectures.

Transformation vs Portability

Model transformation is about changing contents within the same environment, portability is about moving the same contents across different environments; and despite apparent similarities, they deal with different concerns, set by users for the former, by tools vendors for the latter.

Transformation is normally performed under a single corporate roof according agreed semantics; as a corollary, it is meant to cover the full contents of models. That’s not the case for portability, whose primary objective is the exchange of consolidated contents between heterogeneous environments; while sources and targets may have to share the whole of their models, a sound policy should make room for selective portability of specific or confidential contents.

The Meta-Object Facility (MOF) is the solution of choice for portability. As a meta-language it is used to describe language constructs at source and target environments; mapping rules can then be defined and bridges built between environments. As it is, those bridges usually scale very poorly due to the exponential complexity of rules having to cover all and every model idiosyncrasies; and that’s unfortunate for portability which, instead of focused targets, has to deal with overweight models cluttered with useless contents (b).

Portability between modeling environments: Lumped (b) vs Differentiated (a) constructs.

That situation would be greatly improved (a) if the wheat of consolidated constituents could be separated from the chaff of ambiguous or irrelevant contents. On a broader perspective that will open the way leaner and fitter models.

One step back may put UML back on track

There is something of a consensus among the software engineering community regarding (1) the benefits of models and (2) the failures of UML. As should be expected, that consensus translates into fragmented modeling practices and, more generally, software engineering methodologies. Obviously there isn’t much of a future for UML along that path, but the case is still open and the trend can be reversed by putting users needs back on UML driving seat.

Further Reading

External Links