UML Actors (aka Roles) are meant to provide a twofold description of interactions between systems and their environment: organization and business process on one hand, system and applications on the other hand.
That can only be achieved by maintaining a conceptual distinction between actual agents, able to physically interact with systems, and actors (aka roles), which are their symbolic avatars as perceived by applications.
As far as the purpose is to describe interactions, actors should be primary characterized by the nature of language (symbolic or not), and identification coupling (biological or managed):
Symbolic communication, no biological identification (systems)
Analog communication, no biological identification (active devices or equipments)
Analog communication, biological identification (live organisms)
While there has been some confusion between actors (or roles) and agents, a clear-cut distinction is now a necessity due to the centrality of privacy issues, whether it is from business or regulatory perspective.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Depending on targeted architectures, those features may or may not be implemented by services.
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.
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.
For that purpose it will be necessary to clarify the action semantics associated with the communication between processes and systems.
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).
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.
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.
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.
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.
While that catalog cannot pretend to fully support requirements, the part it does support comes with two critical benefits:
It fully and consistently describes the interactions at architecture level.
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.
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.
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.
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:
Dock process interactions (aka sessions) to their business context: references to agents, business objects and time-frames.
Specify interactions: references to context, roles, events, messages, and time related constraints.
Specify information: structures, features, and rules.
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.
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).
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.
One step further, the distinction between communication semantics and business contents could be used to align models respectively to systems and software architectures:
Communication semantic constructs could be mapped to systems architectures, ideally to services oriented ones.