Archive for the ‘UML’ Category

Unified Architecture Framework Profile (UAFP): Lost in Translation ?

July 2, 2017

Synopsis

The intent of Unified Architecture Framework Profile (UAFP) is to “provide a Domain Meta-model usable by non UML/SysML tool vendors who may wish to implement the UAF within their own tool and metalanguage.”

Detached Architecture (Víctor Enrich)

But a meta-model trying to federate (instead of bypassing) the languages of tools providers has to climb up the abstraction scale above any domain of concerns, in that case systems architectures. Without direct consideration of the domain, the missing semantic contents has to be reintroduced through stereotypes.

Problems with that scheme appear at two critical junctures:

  • Between languages and meta-models, and the way semantics are introduced.
  • Between environments and systems, and the way abstractions are defined.

Caminao’s modeling paradigm is used to illustrate the alternative strategy, namely the direct stereotyping of systems architectures semantics.

Languages vs Stereotypes

Meta-Models are models of models: just like artifacts of the latter represent sets of instances from targeted domains, artifacts of the former represent sets of symbolic artifacts from the latter. So while set higher on the abstraction scale, meta-models still reflect the domain of concerns.

Meta-models takes a higher view of domains, meta-languages don’t.

Things are more complex for languages because linguistic constructs ( syntax and semantics) and pragmatic are meant to be defined independently of domain of discourse. Taking a simple example from the model above, it contains two kinds of relationships:

  • Linguistic constructs:  represents, between actual items and their symbolic counterparts; and inherits, between symbolic descriptions.
  • Domain specific: played by, operates, and supervises.

While meta-models can take into account both categories, that’s not the case for languages which only consider linguistic constructs and mechanisms. Stereotypes often appear as a painless way to span the semantic fault between what meta-models have to do and what languages use to do; but that is misguided because mixing domain specific semantics with language constructs can only breed confusion.

Stereotypes & Semantics

If profiles and stereotypes are meant to refine semantics along domains specifics, trying to conciliate UML/SysML languages and non UML/SysML models puts UAFP in a lopsided position by looking the other way, i.e towards one-fits-all meta-language instead of systems architecture semantics. Its way out of this conundrum is to combine stereotypes with UML constraint, as can be illustrated with PropertySet:

UAFP for PropertySet (italics are for abstract)

Behind the mixing of meta-modeling levels (class, classifier, meta-class, stereotype, meta-constraint) and the jumble of joint modeling concerns (property, measurement, condition), the PropertySet description suggests the overlapping of two different kinds of semantics, one looking at objects and behaviors identified in environments (e.g asset, capability, resource); the other focused on systems components (property, condition, measurement). But using stereotypes indifferently for both kind of semantics has consequences.

Stereotypes, while being the basic UML extension mechanism, comes without much formalism and can be applied extensively. As a corollary, their semantics must be clearly defined in line with the context of their use, in particular for meta-languages topping different contexts.

PropertySet for example is defined as an abstract element equivalent to a data type, simple or structured, a straightforward semantic that can be applied consistently for contexts, domains or languages.

That’s not the case for ActualPropertySet which is defined as an InstanceSpecification for a “set or collection of actual properties”. But properties defined for domains (as opposed to languages) have no instances of their own and can only occur as concrete states of objects, behaviors, or expectations, or as abstract ranges in conditions or constraints. And semantics ambiguities are compounded when inheritance is indifferently applied between a motley of stereotypes.

Properties epitomize the problems brought about by confusing language and domain stereotypes and point to a solution.

To begin with syntax, stereotypes are redundant because properties can be described with well-known language constructs.

As for semantics, stereotyped properties should meet clearly defined purposes; as far as systems architectures are concerned, that would be the mapping to architecture capabilities:

Property must be stereotyped with regard to induced architecture capabilities.

  • Properties that can be directly and immediately processed, symbolic (literal) or not (binary objects).
  • Properties whose processing depends on external resource, symbolic (reference) or not (numeric values).

Such stereotypes could be safely used at language level due to the homogeneity of property semantics. That’s not the case for objects and behaviors.

Languages Abstractions & Symbolic Representations

The confusion between language and domain semantics mirrors the one between enterprise and systems, as can be illustrated by UAFP’s understanding of abstraction.

In the context of programming languages, isAbstract applies to descriptions that are not meant to be instantiated: for UAFP “PhysicalResource” isAbstract because it cannot occur except as “NaturalResource” or “ResourceArtifact”, none of them isAbstract.

“isAbstract” has no bearing on horses and carts, only on the meaning of the class PhysicalResource.

Despite the appearances, it must be reminded that such semantics have nothing to do with the nature of resources, only with what can be said about it. In any case the distinction is irrelevant as long as the only semantics considered are confined to specification languages, which is the purpose of the UAFP.

As that’s not true for enterprise architects, confusion is to arise when the modeling Paradigm is extended as to include environments and their association with systems. Then, not only that two kinds of instances (and therefore abstractions) are to be described, but that the relationship between external and internal instances is to determine systems architectures capabilities. Extending the simple example above:

  • Overlooking the distinction between active and passive physical resources prevents a clear and reliable mapping to architecture technical capabilities.
  • Organizational resource lumps together collective (organization), individual and physical (person), individual and organizational (role), symbolic (responsibility), resources. But these distinctions have a direct consequences for architecture functional capabilities.

Abstraction & Symbolic representation

Hence the importance of the distinction between domain and language semantics, the former for the capabilities of the systems under consideration, the latter for the capabilities of the specification languages.

Systems Never Walk Alone

Profiles are supposed to be handy, reliable, and effective guides for the management of specific domains, in that case the modeling of enterprise architectures. As it happens, the UAF profile seems to set out the other way, forsaking architects’ concerns for tools providers’ ones; that can be seen as a lose-lose venture because:

  • There isn’t much for enterprise architects along that path.
  • Tools interoperability would be better served by a parser focused on languages semantics independently of domain specifics.

Hopefully, new thinking about architecture frameworks (e.g DoDAF) tends to restyle them as EA profiles, which may help to reinstate basic requirements:

  • Explicit modeling of environment, enterprise, and systems.
  • Clear distinction between domain (enterprise and systems architecture) and languages.
  • Unambiguous stereotypes with clear purposes

A simple profile for enterprise architecture

On a broader perspective such a profile would help with the alignment of purposes (enterprise architects vs tools providers), scope (enterprise vs systems), and languages (modeling vs programming).

Further Reading

Models
Architectures
Enterprise Architecture
UML#

External Links

Advertisements

Views, Models, & Architectures

May 27, 2017

Preamble

Views can take different meanings, from windows opening on specific data contexts (e.g DB relational theory), to assortments of diagrams dedicated to particular concerns (e.g UML).

Fortunato Depero tunnels

Deconstructing the Universe along Contexts and Concerns (Depero Fortunato)

Models for their part have also been understood as views, on DB contents as well as systems’ architecture and components, the difference being on the focus put on engineering. Due to their association with phased processes, models has been relegated to a back-burner by agile approaches; yet it may resurface in terms of granularity with model-based engineering frameworks.

Views & Architectures

As far as systems engineering is concerned, understandings of views usually refer to Philippe Kruchten’s “4+1” View Model of Software Architecture” :

  • Logical view: design of software artifacts.
  • Process view: captures the concurrency and synchronization aspects.
  • Physical view: describes the mapping(s) of software artifacts onto hardware.
  • Development view: describes the static organization of software artifacts in development environments.

A fifth is added for use cases describing the interactions between systems and business environments.

Whereas these views have been originally defined with regard to UML diagrams, they may stand on their own meanings and merits, and be assessed or amended as such.

Apart from labeling differences, there isn’t much to argue about use cases (for requirements), process (for operations), and physical (for deployment) views; each can be directly associated to well identified parts of systems engineering that are to be carried out independently of organizations, architectures or methods.

Logical and development views raise more questions because they imply a distinction between design and implementation. That implicit assumption induces two kinds of limitations:

  • They introduce a strong bias toward phased approaches, in contrast to agile development models that combine requirements, development and acceptance into iterations.
  • They classify development processes with regard to predefined activities, overlooking a more critical taxonomy based on objectives, architectures and life-cycles: user driven and short-term (applications ) vs data-based and long-term (business functions).

These flaws can be corrected if logical and development views are redefined respectively as functional and application views, the former targeting business objects and functions, the latter business logic and users’ interfaces.

Architecture based views

Architecture based views

That make views congruent with architecture levels and consequently with engineering workshops. More importantly, since workshops make possible the alignment of products with work units, they are a much better fit to model-based engineering and a shift from procedural to declarative paradigm.

Model-based Systems Engineering & Granularity

At least in theory, model-based systems engineering (MBSE) should free developers from one-fits-all procedural schemes and support iterative as well as declarative approaches. In practice that would require matching tasks with outcomes, which could be done if responsibilities on the former can be aligned with models granularity of the latter.

With coarse-grained phased schemes like MDA’s CIM/PIM/PSM (a), dependencies between tasks would have to be managed with regard to a significantly finer artifacts’ granularity.

Managing changes at architecture (a) or application (b) level.

Managing changes at architecture (a) or application (b) level.

For agile schemes, assuming conditions on shared ownership and continuous deliveries are met, projects would put locks on “models” at both ends (users’ stories and deliveries) of development cycles (b), with backlogs items defining engineering granularity.

Backlogs mechanism can be used to manage customized granularity and hierarchical dependencies across model layers

Along that reasoning it would be possible to unify the management of changes in engineered artifacts at the appropriate level of granularity: static and explicit using milestones (phased), dynamic and implicit using backlogs (agile).

Cycles_DeclarIntervs

Fine grained model based frameworks could support phased as well as agile development solutions

Such a declarative repository would greatly enhance exchanges and integration across projects  and help to align heterogeneous processes independently of the methodologies used.

Further Reading

External Links

Focus: Business Cases for Use Cases

February 27, 2017

Preamble

As originally defined by Ivar Jacobson, uses cases (UCs) are focused on the interactions between users and systems. The question is how to associate UC requirements, by nature local, concrete, and changing, with broader business objectives set along different time-frames.

Sigmar-Polke-Hope-Clouds

Cases, Kites, and Clouds (Sigmar Polke)

Backing Use Cases

On the system side UCs can be neatly traced through the other UML diagrams for classes, activities, sequence, and states. The task is more challenging on the business side due to the diversity of concerns to be defined with other languages like Business Process Modeling Notation (BPMN).

Use cases at the hub of UML diagrams

Use Cases contexts

Broadly speaking, tracing use cases to their business environments have been undertaken with two approaches:

  • Differentiated use cases, as epitomized by Alister Cockburn’s seminal book (Readings).
  • Business use cases, to be introduced beside standard (often renamed as “system”) use cases.

As it appears, whereas Cockburn stays with UCs as defined by Jacobson but refines them to deal specifically with generalization, scaling, and extension, the second approach introduces a somewhat ill-defined concept without setting apart the different concerns.

Differentiated Use Cases

Being neatly defined by purposes (aka goals), Cockburn’s levels provide a good starting point:

  • Users: sea level (blue).
  • Summary: sky, cloud and kite (white).
  • Functions: underwater, fish and clam (indigo).

As such they can be associated with specific concerns:

Cockburn’s differentiated use cases

  • Blue level UCs are concrete; that’s where interactions are identified with regard to actual agents, place, and time.
  • White level UCs are abstract and cannot be instanciated; cloud ones are shared across business processes, kite ones are specific.
  • Indigo level UCs are concrete but not necessarily the primary source of instanciation; fish ones may or may not be associated with business functions supported by systems (grey), e.g services , clam ones are supposed to be directly implemented by system operations.

As illustrated by the example below, use cases set at enterprise or business unit level can also be concrete:

Example with actors for users and legacy systems (bold arrows for primary interactions)

UC abstraction connectors can then be used to define higher business objectives.

Business “Use” Cases

Compared to Cockburn’s efficient (no new concept) and clear (qualitative distinctions) scheme, the business use case alternative adds to the complexity with a fuzzy new concept based on quantitative distinctions like abstraction levels (lower for use cases, higher for business use cases) or granularity (respectively fine- and coarse-grained).

At first sight, using scales instead of concepts may allow a seamless modeling with the same notations and tools; but arguing for unified modeling goes against the introduction of a new concept. More critically, that seamless approach seems to overlook the semantic gap between business and system modeling languages. Instead of three-lane blacktops set along differentiated use cases, the alignment of business and system concerns is meant to be achieved through a medley of stereotypes, templates, and profiles supporting the transformation of BPMN models into UML ones.

But as far as business use cases are concerned, transformation schemes would come with serious drawbacks because the objective would not be to generate use cases from their business parent but to dynamically maintain and align business and users concerns. That brings back the question of the purpose of business use cases:

  • Are BUCs targeting business logic ? that would be redundant because mapping business rules with applications can already be achieved through UML or BPMN diagrams.
  • Are BUCs targeting business objectives ? but without a conceptual definition of “high levels” BUCs are to remain nondescript practices. As for the “lower levels” of business objectives, users’ stories already offer a better defined and accepted solution.

If that makes the concept of BUC irrelevant as well as confusing, the underlying issue of anchoring UCs to broader business objectives still remains.

Conclusion: Business Case for Use Cases

With the purposes clearly identified, the debate about BUC appears as a diversion: the key issue is to set apart stable long-term business objectives from short-term opportunistic users’ stories or use cases. So, instead of blurring the semantics of interactions by adding a business qualifier to the concept of use case, “business cases” would be better documented with the standard UC constructs for abstraction. Taking Cockburn’s example:

Abstract use cases: no actor (19), no trigger (20), no execution (21)

Different levels of abstraction can be combined, e.g:

  • Business rules at enterprise level: “Handle Claim” (19) is focused on claims independently of actual use cases.
  • Interactions at process level: “Handle Claim” (21) is focused on interactions with Customer independently of claims’ details.

Broader enterprise and business considerations can then be documented depending on scope.

Further Reading

External Links

Focus: MDA & UML

November 9, 2016

Preamble

UML (Unified Modeling Language) and MDA (Model Driven Architecture) epitomize the lack of focus and consistency of the OMG’s strategy. As it’s safe to assume that there can be no architectures without models, MDA and UML arguably bring sensible (if not perfect) schemes without significant competition.

MarcelBroodthaers-2Pipes

Unified language for Business and System Modeling (Marcel Broodthaers)

 

Unfortunately, not much has been made to play on their obvious complementarity and to exploit their synergies.

MDA & the Nature of Models

Model driven architecture (MDA) can be seen as the main (only ?) documented example of model based systems engineering. Its taxonomy organizes models within three layers:

  • Computation independent models (CIMs) describe organization and business processes independently of the role played by supporting systems.
  • Platform independent models (PIMs) describe the functionalities supported by systems independently of their implementation.
  • Platform specific models (PSMs) describe systems components depending on implementation platforms.

Engineering can then be managed along architecture layers (a), or carried out as a whole for each application (b).

mapsterrits_landingschar

Managing changes at architecture (a) or application (b) level.

It’s important to note that the MDA framework is completely neutral with regard to methods: engineering processes can be organized as phased activities (procedural), iterations (agile), or artifacts transformation (declarative).

Logic & The Matter of Models

Whatever the idiosyncrasies and fuzziness of business concerns and contexts, at the end of the day requirements will have to be coerced into the strict logic of computer systems. That may be a challenging task to be carried out directly, but less so if upheld by models.

As it happens, a fact all too often ignored, models come with sound logical foundations that can be used to formalize the mapping of requirements into specifications; schematically, models are to be set in two formal categories:

  • Descriptive (aka extensional) ones try to classify actual objects, events, and processes into categories.
  • Prescriptive (aka intensional) ones specify what is expected of systems components and how to develop them.
The logical basis of models

The logical basis of models

Interestingly, that distinction provides a formal justification to the one between analysis and design models, the former for the consolidation of requirements across business domains and enterprise organization, the latter for systems and software designs. Such logical foundations could help to manage the mapping of business processes and systems architectures.

UML & the Anatomy of Models

Except scientific computation, there is no reason to assume a-priori congruence between the description of business objects and processes and the specification of the software components. As a corollary, their respective structures and features are better to be dealt with separately.

But that’s not the case at architecture level, where domains and identities have to be managed continuously and consistency on the two sides of the business/system divide. At this level (aka enterprise architecture), responsibilities and identification and communication mechanisms must be defined uniformly.

Compared to MDA set at architecture level, UML describes the corresponding artifacts for business, systems, and platform layers. Regardless of the confusing terminology (layers or levels), that puts MDA and UML along orthogonal dimensions: the former (layers) deals with the nature of contents, the latter (levels) with their structures and features.

MDA is only concerned with architectures, UML describe the structure of architecture components.

MDA is only concerned with architectures, UML describe the structure of architecture components.

Using the same unified modeling language across business, systems, and platform layers is to clearly and directly enhance transparency and traceability; but the full extent of MDA/UML cross-benefits is to appear when models logic is taken into account.

Models & Systems Evolution

As illustrated by the increasing number of systemic crashes, systems obsolescence is no longer a matter of long-term planning but of operational continuity: change has become the rule and as far as complex and perennial systems are concerned, architectures are to evolve while supporting their functional duties seamlessly. If that is to be achieved, modularity and a degree of consistency are necessary between the nature of changes and their engineering. That’s where MDA is to help.

As pointed to above, modularity is best achieved with regard to level (architecture, element) and models contents (business, systems, platforms).

At architecture level, changes in domains, identification, and categories must be aligned between descriptive (enterprise) and prescriptive (systems) models. That will be best achieved with UML models across all MDA layers.

Using UML and MDA helps to align descriptive and prescriptive models at architecture level.

Using UML and MDA helps to align descriptive and prescriptive models at architecture level.

The constraints of continuity and consistency can be somewhat eased at element level: if descriptive (business) and prescriptive (systems) models of structures and features are to be consistent, they are not necessarily congruent. On component (prescriptive/design) side, UML and object-oriented design (OOD) are to keep them encapsulated. As for the business (descriptive/analysis) side, since structures and features can be modeled separately (and OOD not necessarily the best option), any language (UML, BPMN, DSL,etc.) can be used. In between, the structure (aka signature) of messages passed at architecture level is to be specified depending on communication framework.

Considering the new challenges brought about by the comprehensive interoperability of heterogeneous systems, the OMG should reassess the full range of latent possibilities to be found in its engineering portfolio.

Further Reading

Focus: Business Processes & Abstraction

July 16, 2016

Preamble

Abstractions, and corollary inheritance, are primarily understood with objects. Yet, since business processes are meant to focus on activities, semantics may have to be refined when abstraction and inheritance are directly used for behaviors.

enrique_gimenez-velilla

How to apply abstraction to processes ?  (E. Gimenez Velilla)

Considering that the primary purpose of abstractions is to tackle business variants with regard to supporting systems, their representation with use cases provides a good starting point.

Business Variants: Use case’s <extend> & <include>

Taking use cases as a modeling nexus between business and systems realms, <extend> and <include> appear as the default candidates for the initial description of behaviors’ specialization and generalization.

  • <include>: to be compared to composition semantics, with the included behaviors performed  by instances identified (#) by the owner UC (a).
  • <extend>: to be compared to aggregation semantics, with the extending behaviors performed  by separate instances with reference to the owner ones (b).
Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Abstract use cases and generalization have also been mentioned by UML before being curiously overlooked in following versions. Since none has been explicitly discarded, some confusion remains about hypothetical semantics. Notionally, abstract UCs would represent behaviors never to be performed on their own (c). Compared to inclusion, used for variants of operations along execution paths, abstract use cases would describe the generic mechanisms to be applied to triggering events at UC inception independently of actual business operations carried out along execution paths.

Nonetheless, and more importantly, the mix-up surrounding the generalization of use cases points to a critical fault-line running under UML concepts: since both use cases and classes are defined as qualifiers, they are supposed to be similarly subject to generalization and specialization. That is misguided because use cases describe the business behaviors to be supported by systems, not to be confused with the software components that will do the job. The mapping between the former and the latter is to be set by design, and there is no reason to assume a full and direct correspondence between functional requirements and functional architecture.

Use Cases Distilled

As far as use cases are considered, mapping business behaviors to supporting systems functionalities can be carried out at two levels:

  • Objects: UCs being identified by triggering agents, events, and goals, they are to be matched with corresponding users interfaces and controllers, the former for the description of I/O flows, the latter for the continuity and integrity of interactions.
  • Methods: As it’s safe to assume that use cases are underpinned by shared business functions and system features, a significant part of their operations are to be realized by methods of shared business entities or services.
vv

Setting apart UIs and controllers, no direct mapping should be assumed between use cases and functional qualifiers.

The business variants distilled into objects’ or services’ methods can be generalized and specialized according to OOD principles; and the same principles can be applied to specific users’ interfaces. But since purely behavioral aspects of UCs can neither be distilled into objects’ methods, nor directly translated into controller objects, their abstraction semantics have to be reconsidered.

Inheritance Semantics: Structural vs Functional

As far as software artifacts are concerned, abstraction semantics are set by programming languages, and while they may differ, the object-oriented (OO) paradigm provides some good enough consolidation. Along that perspective, inheritance emerges as a critical issue due to its direct impact on the validity of programs.

Generally speaking, inheritance describes how structural or behavioral traits are passed from ancestors to descendants, either at individual or type level. OO design is more specific and puts the focus on the intrinsic features (attributes and operations) supported by types or classes, which ensues that behaviors are not considered as such but through the objects’ methods that realize them:

  • Structural inheritance deals with attributes and operations set for the whole life-cycle of instances. As a consequence corresponding inheritance is bound to identities (#) and multiple ascendants (i.e identities) are ruled out.
  • Functional inheritance deal with objects behaviors which may or may not be frozen to whole life-cycles. Features can therefore be inherited from multiple ascendants.

That structural vs functional distinction matches the one between composition and aggregation used to characterize the links between objects and parts which, as noted above, can also be applied to uses cases.

Use Cases & Abstraction

Assuming that the structural/functional distinction defined for objects can also be applied to behaviors, use cases provide a modeling path from variants in business processes to OOD of controllers:

  • Behaviors included by UCs (a) are to be set along the execution paths triggered by UC primary events (#). Inheritance is structural, from UCs base controllers to corresponding (local) ones, and covers features (e.g views on business objects) and associated states (e.g authorizations) defined by use case triggering circumstances.
  • Behaviors extending UCs (b) are triggered by secondary events generated along execution paths. Inheritance is functional, from extending UCs (e.g text messaging) to UCs primary controllers.

Yet this dual scheme may not be fully satisfactory as it suffers from two limitations:

  • It only considers the relationships between UCs, not with the characteristics of the use cases themselves.
  • It ignores the critical difference between the variants of business logic and the variants of triggering conditions.

Both flaws can be patched up if abstract use cases are specifically introduced to factor out triggering circumstances (c):

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

  • Undefined triggering circumstances is the only way to characterize abstraction independently of what happens along execution paths.
  • Abstract use cases can then be used to specify inception mechanisms to be inherited by concrete use cases.

That understanding of abstract use cases comes with clear benefits with regard to security and confidentiality.

What is at Stake

Abstraction can significantly reinforce the bridging role of use cases between business and UML models.

On one side specialized use cases can be associated to operations and functions directly implemented, e.g  by factoring out authentication and authorization:

  • Concrete schemes with included UC will give access to all registered users with the particulars of managers or customers checked later (a).
  • Alternatively, abstract schemes will use inheritance of inception mechanisms in order to explicitly prevent separate access (c).
  • Applying <include> with abstract UC should be ruled out because it would make room for the execution of operations with undefined triggering circumstances.
Interactions can only be triggered by concrete actors.

Interactions can only be triggered by concrete actors.

On the other side generalization can be employed to associate local and opportunistic objectives to broader business cases.

Al in all, that will greatly help to align business cases, business opportunities, and functional architectures.

Further Reading

 

Focus: UML Reenacted

June 26, 2016

Overview

After a promising inception twenty years ago by the OMG (Object Management Group), UML (Unified Modeling Language) seems to have lost part of its steam and fallen short of initial expectations.

(Marta Minujin)

UML library: too many books, too specific languages (Marta Minujin)

On a general perspective that may be due to the primacy given to the agendas of tools providers, at the expense of users concerns. More specifically, UML practices have been hamstrung by two opposed misconceptions: on one side UML has been associated to OO methods and as a result demoted by non-devotees; on the other side it has been taken as a substitute for programming languages, and so confined to class diagrams and code generation. Hopefully, two major advances in methods and development frameworks, respectively agile and MBSE, could correct those biases and renew UML appeal.

UML Core Artifacts

UML diagrams target five primary artifacts:

  • Use cases, events, and actors describe what happens between systems and active agents in their environments.
  • Activities describe what systems are supposed to do when use cases are triggered.
  • Classes describe systems components.
  • Sequences describe how systems components collaborate to perform activities.
  • States and transitions describe the behaviors and synchronization of systems components.
ccc

UML Backbone

While those diagrams cover the whole of enterprise systems, UML is all too often limited to the description of software components.

UML and Enterprise Systems

As noted above, the lack of clear users guidelines can be seen as a main cause of UML piecemeal and biased adoption. That can be illustrated by the use of activity and class diagrams:

  • Whereas activity and state diagrams could have been tailored to fully and consistently describe business processes, an alternative notation (BPMN) with arguable benefits is often preferred by business analysts.
  • Whereas UML is meant to deal with the whole of systems, successful implementations like domain specific languages (DSL) focus on class diagrams and code generation.
Targets and Modeling Languages

UML in Context

But both negative trends could be reversed if changes in methodological or technical environments could put UML users on sounder grounds and give them clearer guidelines.

Methods: Use Cases & Agile

As it happened, use cases have been the main UML innovation, other artifacts having been already introduced by modeling languages. And more to the point, they were meant to be the cornerstone of the “unified” construction, a modeling bridge between business processes and supporting systems. That clearly didn’t happen with traditional (and failed) methods like waterfall, but agile could be more welcoming.

Use cases at the hub of UML diagrams

Use cases as a modeling bridge between business processes and supporting systems.

Agile principles put the focus on collaboration and iterative code development, with only sparse mentions of models or processes. But as requirements don’t always come as clear-cut short stories told by well identified business units, use cases may help agile teams to deal with organizational or architectural dependencies:

  • Open minded and Versatile: use cases are not limited to users because actors (aka roles) are meant to hide the actual agents involved: people, devices, or other systems. As a consequence, the scope of UCs is not limited to dialog with users but may also includes batch (as one-step interactions) and real-time transactions.
  • Modular and inter-operable: given their simplicity and clarity of purpose, use cases can be easily processed by a wide array of modeling tools on both sides of the business/engineering divide, e.g BPM and UML.
  • Iterative: given their modularity, use cases can be easily tailored to the iterative paradigm. Once a context is set by business process or user’s story, development iterations can be defined with regard to invariants (use case), iterations (extension points and scenarii), backlog units (activities), and exit condition.
  • Scalable: use cases provide a sound and pragmatic transition between domain specific stories and architectural features.

That could be the basis of an open relationship between agile development models and UML.

Frameworks: Classes & MBSE

Beyond the various labels (based/driven, system/software, development/engineering), all model based approaches to systems engineering and software development try to replace procedural approaches by declarative ones, and to redefine processes in terms of artifacts transformation.

Model Based Engineering Processes are governed by the status of artifacts

UML could be used to define and manage engineered artifacts.

The benefits of that approach have already been demonstrated at design level through the use of domain specific languages (DSLs). Since effective DSLs usually rely on class diagrams, UML could be used to leverage their success beyond code generation and across the whole of the engineering process.

With artifacts seamlessly and consistently defined and managed within a single engineering framework, procedural schemes could be replaced by declarative ones reusing, editing, or transforming artifacts depending on constraints.

Further Reading

 

UML’s Semantic Master Key, Lost & Found

April 25, 2016

Preamble

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.

(Jonathan Monk)

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 are Agile Tools

November 26, 2015

Preamble

Use cases are often associated with the whole of UML diagrams, and consequently with cumbersome procedures, and excessive overheads. But like cats, use cases can be focused, agile and versatile.

Use cases are agile tools with side view

Use Case: agile, simple-minded, with a side view (P. Picasso)

Simple minded, Robust, Easy going

As initially defined by Ivar Jacobson, the aim of use cases is to describe what happens between users and systems. Strictly speaking, it means a primary actor (possibly seconded) and a triggering event (possibly qualified); that may (e.g transaction) or may not (e.g batch) be followed by some exchange of messages . That header may (will) not be the full story, but it provides a clear, simple and robust basis:

  • Clear and simple: while conditions can be added and interactions detailed, they are not necessary parts of the core definition and can be left aside without impairing it.
  • Robust: the validity of the core definition is not contingent on further conditions and refinements. It ensues that simple and solid use cases can be defined and endorsed very soon, independently of their further extension.

As a side benefit, use cases come with a smooth learning curve that enable analysts to become rapidly skilled without being necessarily expert.

Open minded and Versatile

Contrary to a somewhat short-sighted perspective, use cases are not limited to users because actors (aka roles) are meant to hide the actual agents involved: people, devices, or other systems. As a consequence, the scope of UCs is not limited to dialog with users but may also includes batch (as one-step interactions) and real-time transactions.

Modular and Inter-operable

Given their simplicity and clarity of purpose, use cases can be easily processed by a wide array of modeling tools on both sides of the business/engineering divide, e.g BPM and UML. That brings significant benefits for modularity.

At functional level use cases can be used to factor out homogeneous modules to be developed by different tools according to their nature. As an example, shared business functions may have to be set apart from business specific scenarii.

Use cases at the hub of UML diagrams

Use cases can be easily combined with a wide range of modeling tools

At technical level, interoperability problems brought about by updates synchronization are to be significantly reduced simply because modules’ core specifications (set by use cases) can be managed independently.

Iterative

Given their modularity, use cases can be easily tailored to the iterative paradigm. Once a context is set by business process or user’s story, development iterations can be defined with regard to:

  • Invariants (use case): primary actor and triggering event.
  • Iterations (scenarii): alternative execution paths identified by sequences of extension points representing the choices of actors or variants within the limits set by initial conditions.
  • Backlog units: activities associated to segments of execution paths delimited by extension points.
  • Exit condition: validation of execution path.
cccc

Execution paths & Development cycles

Scalable

Last but not least, use cases provide a sound and pragmatic transition between domain specific stories and architectural features. Taking a leaf from the Scaled Agile Framework, business functions can be factored out as functional features represented by shared use cases whose actors stand for systems and not final users.

BP2SOA_4

Mapping Processes to Services (through Users’ Stories)

Depending on targeted architectures, those features may or may not be implemented by services.

Further Reading

External Links

Use Cases & Action Semantics

June 8, 2015

Synopsis

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 (Tetsumi Kudo)

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).

ccc

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.

BPM_UML_UC

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

March 19, 2015

Summary

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. Winograd)

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.

vvv

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