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 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 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.
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.
Mapping Processes to Services (through Users’ Stories)
Depending on targeted architectures, those features may or may not be implemented by services.
Data mining explores business opportunities and competitive advantage, requirements analysis considers supporting applications. Both use models, the former’s are predictive and ephemeral, the latter’s descriptive (or prescriptive) and perennial.
Data mining: sorting business wheat from world chaff (Andreas Gursky)
As the generalization of digitized environment calls for more integration of business and software engineering processes, understanding the relationship between data mining and requirements analysis could significantly improve processes maturity and agility.
Data vs Requirements Analysis
Nowadays the success of a wide range of enterprises critically depends on two achievements:
Mapping business models to changing environments by sorting through facts, capturing the relevant data, and processing the whole into meaningful and up to date information. That can be achieved through analysis models mapping business expectations to supporting systems.
Putting that information into effective use through business processes and supporting systems. That is done through systems architecture and design models meant to prescribe how to build software artifacts.
Those challenges are converging: under the pressure of markets forces and technological advances most of traditional fences between business channels and IT systems are crumbling, putting the focus on the functional integration between data mining and production systems. That’s where predictive models can help by anchoring descriptive models to moving markets and by cross-feeding analysis and operations. How that can be achieved has been the bread and butter of good corporate governance for some time, but there has been less interest for the third branch, namely how data analysis (predictive models) could “inform” business requirements (descriptive models).
Facts are not given but must be captured through a symbolic description of actual observations. That entails some observer set on task using a mix of conceptual and technical apparatus. Data mining and requirements analysis are practical realizations of that process:
Data mining relies on analytic tools to extract revealing information that could be used to chart opportunities along business models.
Requirements analysis relies on business processes and users’ practice to extract symbolic descriptions that will be used to build models of supporting applications.
If both walk the path from data to information, their objectives are different: the former’s is to improve business decisions by making sense of actual observations; the latter’s is to build system surrogates from the symbolic descriptions of actual business objects and activities.
Anchors & Structures: Plasticity of Business Entities
Perhaps paradoxically, business agility calls for terra firma because nimble trades must be rooted in corporate identity and business continuity. As a consequence, the first step of requirements analysis should be to associate individuals business objects or activities with stable and consistent identification mechanisms, and to group them with regard to that mechanism:
External entities with natural (person) or designed identity (car).
Symbolic entities for roles (customer) or commitments (maintenance contract).
Actual activities (promotion campaign) and events (sale) or business logic (promotion).
Anchors
Conversely, as the aim of data analysis is to explore every business angle, individual observations are supposed to be moved across groups; yet, since the units identified by data analysis will have to be aligned with the ones described by requirements analysis, moves must also keep track of identities. That dilemma between continuity of identified structures on one side, plasticity of functional aspects on the other side, can be illustrated by banks which, in response to marketing requirements, had to shift from account (internal identification) to customer (external identification) based systems.
It’s easier to market insurance from customer centered systems (right) than from account centered ones (left)
That challenge can be overcome by linking the identification of symbolic entities to external anchors.
Profiles & Features: Versatility of Business Opportunities
As noted above, requirements and data analysis are set on the same road but driven by different forces: the former tries to group individuals with regard to identification mechanisms before fleshing them out with relevant features; the latter tries to group individuals with given identities according to features and opportunity profiles. Yet, what could appear as collision courses may become a meeting of minds if both courses are charted with regard to variants analysis.
From the requirements perspective the primary concern is to distinguish between structural and functional variants:
Structural variants are bound to identities, i.e set up-front for the respective life-cycle of individual business objects or transactions. As a consequence they cannot be changed without undermining business continuity. Moreover, being part and parcel of descriptors (e.g types and use cases) their change will affect engineering processes.
Functional variants may vary during the respective life-cycle of individual business objects or transactions. As a consequence they can be changed without undermining business continuity, and changes in descriptors (e.g partitions and scenarii) can be managed without affecting engineering processes.
From the data mining perspective the objective is to improve the benefits of information systems for decision-making processes:
Static: how to classify individuals as to reduce the uncertainty of predictions
Dynamic: how to classify business options as to reduce the uncertainty of decisions.
Since those objectives are set for individuals, constraints on continuity and consistency can be dealt with independently of the description of symbolic surrogates.
Identified individuals with profiles for customers (a), their behaviors (b), and promotional gestures (c)
It ensues that perspectives can be adjusted by factoring out the constraints of continuity and consistency for business objects (e.g cars), agents (e.g customer) and processes (e.g repair). Profiles for agents (a), behaviors (b), and business options (c) could then be freely explored and tailored with regard to changes in business environment and objectives.
Applying Data Analysis to Requirements
Not surprisingly data analysis techniques can be used to adjust perspectives. For that purpose a sample of individuals (business objects and operations) representing the population targeted by requirements would have to be submitted to basic mining routines. Borrowing a catalog from F. Provost & T. Fawcett:
Classification: estimates the probability for each individual (objects or operations) to belong to a set of classes; can be used to assess the closeness of the variants (respectively power-types or execution paths) identified by requirements analysis.
Regression: reverse classification; estimates how much of individual features valuations can be explained by the proposed classifications.
Similarity: a shallow version of classification; can be used to assess the distance between variants and consolidate the proposed classifications.
Clustering: a deep version of classification; can be used to distinguish between shallow and natural classifications.
Co-occurrence: deals with behavioral variants; can be used to distinguish between functional and structural classifications.
Profiling: reverse of co-occurrence; can be used to consolidate functional and structural classifications.
Links prediction: can be used to define relationships.
Data reduction: eliminate redundant individuals; can be used to consolidate requirements and refine tests scenarii.
Causal modeling: brings together business logic (events and rules) and users decisions; should provide the backbone of tests scenarii.
Besides the direct benefits for requirements, such procedures may help to bridge the span between data and requirements analysis and significantly improve processes’ capability and maturity level.
Data mining being first and foremost about competitive edge, it relies on a timely and effective coupling between enterprises capabilities and business opportunities. But the dilemma between continuity and plasticity described above for business objects and processes reappears at enterprise level: how to conciliate architecture, by nature perennial, with the agility needed to make the best of changing and competitive environments ?
As architectural big bang is arguably a last resort option, answers to that question must be progressive and local: if changes are to be swift and pertinent they must be both circumscribed and leveraged to the relevant parts of architecture. Taking an (amended) leaf of the Zachman framework, its sixth column (“Why” ) could be reset as a line for business and operational objectives that would cross the original five columns instead of the architecture layers. Using a pentagonal representation of enterprise architecture, that line would be set as circling the outer range.
Enterprise Architecture and the loci of change
It is worth to note that setting objectives on a line crossing the columns of capabilities instead of a column crossing the lines of layers means that objectives are set at enterprise level and their cascading impact traced and managed through layers.
Conceptual Models & Business Contexts
But even that updated framework doesn’t take into account the fundamental changes in business environments. Once secure behind organizational and technical fences, enterprises must now navigate through open digitized business environments and markets. For business processes it means a seamless integration with supporting applications; for corporate governance it means keeping track of heterogeneous and changing business contexts and concerns while assessing the capability of organizations and systems to cope, adjust, and improve.
As long as environments were a hotchpotch of actual and symbolic artifacts the pros and cons of integration could be balanced. But the generalization of digital flows and transactions has upended the balance: there is no more room or time for latency and enterprises must bring all symbolic representations (business, organization, and systems) under a common conceptual roof:
Conceptual models as bridges between business processes, and systems.
A canonical approach would be to introduce a conceptual indexing scheme open to extensions but with its footprint defined by business processes and systems functionalities. That would ensure a better integration of processes and supporting engineering but will do nothing for the modeling gap between enterprise architecture and external contexts. That could be achieved with ontologies.
Conceptual Loop: Ontologies & Business Intelligence
As far as data mining is concerned, three kinds of operations are to be considered:
Data understanding gives form and semantics to raw material.
Business understanding charts business contexts and concerns in terms of objects and processes descriptions.
Modeling consolidate data and business understanding into descriptive, predictive, and operational models.
The aim of data mining is to refine raw data into meaningful information
While traditional approaches fall short when tasked with iterative modeling of unstructured data, ontologies may fare better because their explicit aim is only to describe what could exist in a domain of discourse:
They are made of categories of things, beings, or phenomena; as such they may range from simple catalogs to philosophical doctrines.
They are driven by cognitive (i.e non empirical) purposes, namely the validity and consistency of symbolic representations.
They are meant to be directed at specific domains of concerns, whatever they can be: politics, religion, business, astrology, etc.
With regard to models, only the second point puts ontologies apart: contrary to models, ontologies are about understanding and are not supposed to be driven by empirical purposes. It ensues that ontologies can be understood as conceptual (aka canonical) models, used as such for business analysis and extended with purposes for systems analysis and design.
In addition to the integration with enterprise architectures, ontologies benefits for business intelligence would be twofold.
On one side, and whatever their use, ontologies could be aligned with the nature of contexts and their impact on business and enterprise governance e.g:
Institutional: mandatory semantics sanctioned by regulatory authority, steady, changes subject to established procedures.
Professional: agreed upon semantics between parties, steady, changes subject to established procedures.
Corporate: enterprise defined semantics, changes subject to internal decision-making.
Social: definedpragmatic semantics, no authority, volatile, continuous and informal changes.
Personal: customary semantics defined by named individuals.
Ontologies, capabilities (Who,What,How, Where, When), and architectures (enterprise, systems, platforms).
On the other side ontologies could be defined according to the nature of targeted items, namely terms, documents, symbolic representations, or actual objects and phenomena. That would outline four basic concerns that may or may not be combined:
Thesaurus: ontologies covering terms and concepts.
Document Management: ontologies covering documents with regard to topics.
Organization and Business: ontologies pertaining to enterprise organization, objects and activities.
Engineering: ontologies pertaining to the symbolic representation of products and services.
Ontologies: Purposes & Targets
On a broader perspective, ontologies could be influential in spanning the gap between explicit and implicit knowledge. In a few years’ time practically unlimited access to raw data and the exponential growth in computing power have opened the door to massive sources of unexplored knowledge which is paradoxically both directly relevant yet devoid of immediate meaning:
Relevance: mined raw data is supposed to reflect the geology and dynamics of targeted markets.
Meaning: the main value of that knowledge rests on its implicit nature; applying existing semantics would add little to existing knowledge.
Assuming that deep learning can transmute raw base metals into knowledge gold, ontologies would be decisive in framing the understanding, assessment, and improvement of the processes.
Operational Loop: Business Intelligence & Decision-making
Once carried out separately and periodically, decision-making is to be carried out iteratively at operational, tactical, and strategic level; while each level is to be set along its own time-frames, all are to rely on data-mining, with cycles following the same pattern:
Observation: understanding of changes in business opportunities.
Orientation: assessment of the reliability and shelf-life of pertaining information with regard to current positions and operations.
Decision: weighting of options with regard to enterprise capabilities and broader objectives.
Action: carrying out of decisions within the relevant time-frame.
Given business new playground, decision-making processes have to weave together material and digitized flows, actual contexts (aka territories) and symbolic descriptions (maps), and overlapping time-frames (operational tactical, strategic). That operational loop could then be coupled with the broader one of business intelligence:
Integration of operational analytics, business intelligence, and decision-making.
Despite being a recurring topic of discussions, a comprehensive and formalized approach to requirements should not hold back newcomers: given that requirements are the necessary genesis of any project nothing can be assumed about their emergence; as a consequence they are better dealt with as they come.
The Genesis of Meanings (Quiché Maya’s view of creation)
For that purpose, and whatever the preferred approach, requirements analysis can be neatly described as an iterative process built from three basic increments: identified individuals, associated features, and classifications.
Individuals
When entering unknown territory, the first thing to do is to set apart recognizable items. Regarding requirements that would be individuals whose identities has to be managed. Such individuals would then further be divided between:
Objects (persistent identities) and activities (transient identities).
Activities (managed duration) and events (no managed duration).
Agents (physical identities) and roles (social identities).
Actual (physical identities) and symbolic (social identities) objects.
It must be noted that, except for new standalone applications, most of individuals may have been already defined by existing functional architectures.
Features
Contrary to individuals, features have no identity of their own. As a corollary, they can only be considered as possible attachments to individuals. On that basis, analysts have to answer three basic questions:
Can a feature be shared or transferred (functional), or is it bound to the same individual (structural).
Does it reflect a state of affairs (attribute) or represent a capability (operation).
Is there some overlapping with already known features.
The last question brings about the core of requirements analysis, i.e how to deal with variants, consolidate applications, and manage changes.
Classifications
Categories and rules are the dual facets of requirements purpose, namely how to classify objects and operations and deal with variants.
Categories take a declarative approach that relies on static classifications to describe variants. Starting with partitions, analysts will have to distinguish between structural variants (associated with specific features) and functional ones (associated with the state of the same set of features).
Rules take a procedural approach with the equivalent of dynamic classifications to deal with variants. As for categories, analysts will have to decide between the equivalent of structural variants (rules to be enforced for the whole of execution paths) and functional ones (rules to be evaluated along execution paths).
Whereas each option may have its benefits depending on the nature of variants, the primary factor when selecting a scheme should be its consistency with regard to existing applications on one hand, between the description of new objects and activities on the other hand.
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.
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 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)
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
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.
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:
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.
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.
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
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.
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, 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.
Depending on devotees or dissenters, the Agile development model is all too often presented as dead-end or end-of-story. Some of that unfortunate situation can be explained, and hopefully pacified, by comparing users’ stories to plants, with their roots, trunks, and branches. Assuming that agility calls for sound footings and good springboards, it may be argued that many problems arise with stories barking at the wrong tree (application level) or getting lost in the woods (architecture level).
How to Mind/Mend a True/Tree Story
Application level: Trees, Bushes and Hedges
As Aristotle first stated, good stories have to follow the three unities: one course of action, located in a single space, run along continuous time.
That rule is clearly satisfied by stories that can be developed like plants growing from clearly identified roots.
Yet, stories like bushes may grow too many offshoots to be accounted for by a single action narrative; in that case it may be possible to single out a primary trunk and a set of forking branches along which different scenarii could be developed.
More serious difficulties may appear with thickets mixing offshoots from different bushes sharing the same space. That situation will first require some ground work in order to single out individual roots, and then use them to extricate each bush separately. When, like offshoots that actually mingle, story-lines cross and share actions, the description of such actions (aka features) is to be factored out and separated from the contexts of their enactment in the different story-lines.
Finally, like bushes in hedges, stories may chronicle repeated activities serving some collective purpose. That configuration is both easy to recognize and dealt with effectively by introducing a stereotyped story feature for collections and loops management.
Architecture level: Groves, Woods and Plantations
Contrary to hedges which are built on the similarity of their constituents, groves are based on their functional differences, and that can also be seen as a critical distinction between containers and architectures.
In agile parlance, that is best compared to the difference between stories and epics, the former telling what happens between users and applications, the latter taking a bird’s view of the relationships between business processes and systems.
In most of the cases the question will arise for sizable stories deemed too large for development purposes. When dealing with that situation the first step should be to look for thickets and bushes, respectively to be set apart as individual bushes or refined as scenarii. When still confronted with multiple roots, the question would be to decide between hedges and groves, that is between repeated activities and collaboration. And that decision would be critical because collaborations call for a different kind of story (aka epics or themes) set at a higher level, namely architecture.
Scaling Ups and Downs
Assuming the three-units rule cannot be met, two alternative approaches are possible, depending on whether the story has to be broken down or upgraded to an epic, and the undoing of the rule can be used to make a decision:
When the course of actions, once started, is to be contingent on subsequent business (aka external) events the story should be upgraded to an epic, as it will often refer to a part or whole of a business process.
Otherwise: when activities are set along different periods of time (i.e contingent on time-events) the story can be broken down depending on size, functional architecture, or development constraints.
Otherwise: when activities are distributed across locations it may be necessary to factor out architecture-dependent features dealing with shared address spaces and synchronization mechanisms
Applying those guidelines to stories will put the whole development processes on rails and help to align requirements with their architectural footprint: business logic, system functionalities, or platform technologies.
Empathy is commonly defined as the ability to directly share another person’s state of mind: feelings, emotions, understandings, etc. Such concrete aptitude would clearly help business analysts trying to capture users’ requirements; and on a broader perspective it could even contribute to enterprise capability to foretell trends from actual changes in business environment.
Perceptions and Abstractions (Picasso)
Analysis goes in the opposite direction as it extracts abstract descriptions from concrete requirements, singling out a subset of features to be shared while foregoing the rest. The same process of abstraction being carried out for enterprise business and organisation on one hand, systems and software architectures on the other hand.
That dual perspective can be used to define alignment with regard to the level under consideration: users, systems, or enterprise.
Requirements & Architectures
Requirements capture can be seen as a transition from spoken to written language, its objective being to write down what users tell about what they are doing or what they want to do. For that purpose analysts are presented with two basic policies: they can anchor requirements around already known business objects or processes, or they can stick to users’ stories, identify new structuring entities, and organize requirements alongside. In any case, and except for standalone applications, the engineering process is to be carried out along two paths:
One concrete for the development of applications, the objective being to meet users’ requirements with regard to business logic and quality of service.
The other abstract for requirements analysis, the objective being to identify new business functions and features and consolidate them with those already supporting current business processes.
Those paths are set in orthogonal dimensions as concrete paths connect users’ activities to applications, and abstractions can only be defined between requirements levels.
Concrete (brown) and Abstract (blue) paths of requirements engineering
As business analysts stand at the crossroad, they have to combine empathy when listening to users concerns and expectations, and abstraction when mapping users requirements to systems functionalities and enterprise business processes.
Architectures & Alignments
As it happens, the same reasoning can be extended to the whole of engineering process, with analysis carried out to navigate between abstraction levels of architectures and requirements, and design used for the realization of each requirements level into its corresponding architecture level:
Users’ stories (or more precisely corresponding uses cases) are realized by applications.
Business functions and features are realized by services (assuming a service oriented architecture), which are meant to be an abstraction of applications.
Business processes are realized by enterprise capabilities, which can be seen as an abstraction of services.
How requirements are realized by design at each architecture level
That matrix can be used to define three types of alignment:
At users level the objective is to ensure that applications are consistent with business logic and provide the expected quality of service. That is what requirements traceability is meant to achieve.
At system level the objective is to ensure that business functions and features can be directly mapped to systems functionalities. That is what services oriented architectures (SOA) are meant to achieve.
At enterprise level the objective is to ensure that the enterprise capabilities are congruent with its business objectives, i.e that they support its business processes through an effective use of assets. That is what maturity and capability models are meant to achieve.
That makes alignment a concrete endeavor whatever the architecture layer, i.e not only for users and applications, but also for functions and capabilities.
Enterprise Fourth Dimension
Enterprise Architectures can be fully described as a cross between layers (platforms, systems, organization) and processes (business, engineering, operations). But the validity and usefulness of such outlook is contingent on homogeneous and stable semantics:
Homogeneous: some conceptual consensus can be sustained across business units.
Stable: some continuity and consistency can be achieved for the mapping between business objectives and targeted environments.
Meeting those conditions may become problematic with the growing part played by services and the crumbling of fences between enterprises and their business environment. In that case alignment will have to rely on a fourth conceptual dimension.
The emergence of Enterprise Architecture as a discipline of its own has put the light on the necessary distinction between actual (aka business) and software (aka system) realms. Yet, despite a profusion of definitions for layers, tiers, levels, views, and other modeling perspectives, what should be a constitutive premise of system engineering remains largely ignored, namely: business and systems concerns are worlds apart and bridging the gap is the main challenge of architects and analysts, whatever their preserve.
(Alignment with Dummies (J. Baldessari)
The consequences of that neglect appear clearly when enterprise architects consider the alignment of systems architectures and capabilities on one hand, with enterprise organization and business processes on the other hand. Looking into the grey zone in between, some approaches will line up models according to their structure, assuming the same semantics on both sides of the divide; others will climb up the abstraction ladder until everything will look alike. Not surprisingly, with the core interrogation (i.e “what is to be aligned ?”) removed from the equation, models will be turned into dummies enabling alignment to be carried out by simple pattern matching.
Models & Views
The abundance of definitions for layers, tiers or levels often masks two different understandings of models:
When models are understood as symbolic descriptions of sets of instances, each layer targets a different context with a different concern. That’s the basis of the Model Driven Architecture (MDA) and its distinction between Computation Independent Models (CIMs), Platform Independent Models (PIMs), and Platform Specific Models (PSMs)
When models are understood as symbolic descriptions built from different perspectives, all layers targets the same context, each with a different concern. Along that understanding each view is associated to a specific aspect or level of abstraction: processes view, functional view, conceptual view, technical view, etc.
As it happens, many alignment schemes use, implicitly or explicitly, the second understanding without clarifying the underlying assumptions regarding the backbone of artifacts. That neglect is unfortunate because, to be of any significance, views will have to be aligned with regard to those artifacts.
What is to be aligned
From a general perspective, and beyond lexical controversies, alignment has to be managed with regard to two basic scales:
Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
From a practical point of view, alignment is meant to deal with two main problems: how business processes are supported by systems functionalities, and how those functionalities are to be implemented. Given that the latter can be fully dealt with at system level, the focus can be put on the alignment of business processes and functional architectures.
A naive solution could be to assume services on both processes and systems sides. Yet, the apparent symmetry covers a tautology: while aiming for services oriented architectures on the systems side would be legitimate, if not necessarily realistic, taking for granted that business processes also tally with services would presume some prior alignment, in other words that the problem has already been solved.
The pragmatic and logically correct approach is therefore to map business processes to system functionalities using whatever option is available, models (CIMs vs PIMs), or views (processes vs functions). And that is where the distinction between business and software semantics is critical: assuming the divide can be overlooked, some “shallow” alignment could be carried out directly providing the models can be translated into some generic language; but if the divide is acknowledged a “deep” alignment will have to be supported by a semantics bridge built across.
Shallow Alignment
Just like models are meant to describe sets of instances, meta-models are meant to describe instances of models independently of their respective semantics. Assuming a semantic continuity between business and systems models, meta-models like OMG’s KDM (Knowledge Discovery Meta-model) appear to provide a very practical solution to the alignment problem.
From a practical point of view, one may assume that no model of functional architecture is available because otherwise it would be aligned “by design” and there would be no problem. So something has to be “extracted” from existing software components:
Software (aka design) models are translated into functional architectures.
Models of business processes are made compatible with the generic language used for system models.
Associations are made based on patterns identified on each side.
While the contents of the first and third steps are well defined and understood, that’s not the case for the second step which take for granted the availability of some agreed upon modeling semantics to be applied to both functional architecture and business processes. Unfortunately that assumption is both factually and logically inconsistent:
Factually inconsistent: it is denied by the plethora of candidates claiming for the role, often with partial, overlapping, ambiguous, or conflicting semantics.
Logically inconsistent: it simply dodges the question (what’s the meaning of alignment between business processes and supporting systems) either by lumping together the semantics of the respective contexts and concerns, or by climbing up the ladder of abstraction until all semantic discrepancies are smoothed out.
Alignments built on that basis are necessarily shallow as they deal with artifacts disregarding of their contents, like dummies in test plans. As a matter of fact the outcome will add nothing to traceability, which may be enough for trivial or standalone processes and applications, but is to be meaningless when applied at architecture level.
Deep Alignment
Compared to the shallow one, deep alignment, instead of assuming a wide but shallow commonwealth, tries to identify the minimal set of architectural concepts needed to describe alignment’s stake. Moreover, and contrary to the meta-modelling approach, the objective is not to find some higher level of abstraction encompassing the whole of models, but more reasonably to isolate the core of architecture concepts and constructs with shared and unambiguous meanings to be used by both business and system analysts.
That approach can be directly set along the MDA framework:
Deep alignment makes a distinction between what is at stake at architecture level (blue), from the specifics of process or domain (green), and design (brown).
Contexts descriptions (UML, DSL, BPM, etc) are not meant to distinguish between architectural constructs and specific ones.
Computation independent models (CIMs) describe business objects and processes combining core architectural constructs (using a generic language like UML), with specific business ones. The former can be mapped to functional architecture, the latter (e.g rules) directly transformed into design artifacts.
Platform independent models (PIMs) describe functional architectures using core constructs and framework stereotypes, possibly enriched with specific artifacts managed separately.
Platform specific models (PSMs) can be obtained through transformation from PIMs, generated using specific languages, or refactored from legacy code.
Alignment can so focus on enterprise and systems architectural stakes leaving the specific concerns dealt with separately, making the best of existing languages.
Alignment & Traceability
As mentioned above, comparing alignment with traceability may help to better understand its meaning and purpose.
Traceability is meant to deal with links between development artifacts from requirements to software components. Its main objective is to manage changes in software architecture and support decision-making with regard to maintenance and evolution.
Alignment is meant to deal with enterprise objectives and systems capabilities. Its main objective is to manage changes in enterprise architecture and support decision-making with regard to organization and systems architecture.
As a concluding remark, reducing alignment to traceability may counteract its very purpose and make it pointless as a tool for enterprise governance.
When interacting with systems, users do things they aren’t supposed to do and walk along irrelevant, even unthinkable, paths that can put tests designers at a loss. This apparent chink between users’ conscious self and their fingertips can be explained by the way humans assess situations and make decisions. Curtailing it is the aim of ergonomics.
Anatomy of Errors: from brain to fingers (Rembrandt)
Taking a leaf from A. Tversky and D. Kahneman (who received the 2002 Nobel Prize in Economics), decision-making relies on two cognitive mechanisms:
The first one “operates automatically and quickly, with little or no effort and no sense of voluntary control”. It’s put in use when actual situations must be assessed and decisions taken rapidly if not instantly.
The second one “allocates attention to the effortful mental activities that demand it, including complex computations”. It’s put in use when situations can be assessed with regard to past experience in order to support informed decisions making.
That distinction can be directly applied to users’ behaviors interacting with systems:
Intuitive behavior: decisions are taken on the basis of the visual context and options as presented by users interfaces before taking into account underlying business contents and logic.
Rational behavior: decisions are taken on the basis of business contents and logic disregarding supporting systems interfaces.
Set in context, that distinction can be put in parallel (but not confused) with the one between domain and functional requirements, the former dealing rationally with business objects and logic, the latter putting the former to use through interactions with supporting systems.
Functional requirements describe the part played by supporting systems
Assuming that business logic should not be contingent on supporting systems interfaces, the best option would be to test its implementation independently of users interactions; moreover, tests targeting intuitive behaviors (i.e not directly based on domain specific contents), could then be generated automatically.
Looking for Errors
Given that testing is meant to find flaws in deliverables, tests are certainly more effective when designers know what they are looking for.
For that purpose phased approaches rely on sequences of differentiated tests dealing successively with programming (unit tests), functional requirements (integration tests), and business requirements (acceptance tests). The unfortunate downside of those policies is that the most wide-ranging flaws are the last to be looked for, with the risk of being found after cascading and costly consequences for functionalities and programs.
Phased and Iterative approaches to tests
Conversely, agile approaches follow iterative policies, with each development cycle combining the definition, programming, and tests of software products. When properly implemented those policies significantly improve the early detection and correction of errors whatever their origin. Yet, since there is no explicit management of intermediate outcomes, it’s difficult to differentiate the tests according the kind of errors to look for, e.g faulty business rules implementation or flawed user interface.
Architecture driven approaches may provide an answer, with requirements unambiguously sorted out depending on their architectural footprint: business contents or system functionalities. As a corollary, tests could also be designed along the same lines, targeting business rationale or human behavior.
Errors in Mirrors
Acceptance tests being performed with regard to requirements, they should be designed along requirements taxonomy, respectively for business logic, users’ interactions, quality of services, and components implementation. Being aligned on requirements, those tests can be neatly defined with regard to closed sets of specifications, functional or otherwise.
Functional tests have to expect the unexpected
But that’s not the case for users’ interactions because people behaviors are not fully predictable; hence, while tests can be systematically designed with regard to the set of users’ actions framed by business and functional requirements, there is no way to comprehensively and unambiguously check for all and every possible behavioral contingencies. That will make for three levels of functional tests:
Implementation of business logic: tests should be designed directly from business requirements, independently of interactions with users.
Implementation of scenarii: while interactions are defined in reference to business logic, their validation should focus on the presentation of contents and dialog control.
Users exceptions: in addition to inputs validity, already checked with business logic, and users’ actions, supposedly secured by interaction scenarii, it is necessary to check that unexpected behaviors have been properly considered .
How to check that unexpected behaviors have been properly considered ?
In other words, functional tests will have to look simultaneously for errors in software (defined with regard to a finite set of requirements), and for users’ mistakes (set in an open range of behaviors). As if tests designers were to mirror users errors in order to look for software ones. So, assuming that errors in business logic and interactions have been considered, what should still be checked, and how ?
Fingertips Errors
When faced with choices, users bank on mental maps combining graphical and business layers, with the implicit assumption that maps’ contexts and concerns are kept up to date. Those maps combine three communication mechanisms:
Languages, natural or specific, use syntax and semantics to define business contents, logic, and operations.
Icons use similarity for the visual representation of business operations or functional primitives (e.g create, delete, etc).
Signals use proximity to draw users’ attention to predefined events (e.g sounds for operations completion or incoming emails).
While language-based interactions are supposedly fully covered by business and functional tests, icons and signals make room for “fingertips” reactions which cannot be directly framed within business logic or functional scenarii, and therefore cannot be comprehensively checked for erroneous behaviors.
Icons and signal based communication can trigger unexpected behaviors.
Yet, if instinctive reactions preclude rational considerations, decisions may be swayed by analogies and associations before being informed by the relevant business contents. To prevent that risk, test scenarii built on business logic and functional interactions should be extended in order to take into account the intuitive aspects of users’ behaviors.
Mental Maps & Automated Tests
As noted above, mental maps are built on three layers, one deep (language semantics) and two shallow (icons and signals). While the shallow layers are supposed to reference the deep one, icons and signals may induce instinctive behaviors independently of the referenced business logic. Those behaviors can be triggered by two kinds of mechanisms:
Analogy: users will look for similarities and familiar configurations.
Proximity: users will look for continuity with regard to scope and operations.
Clearly, lapses in such behaviors will normally escape tests designed for business and functional requirements; yet, by being driven by self-contained mechanisms, intuitive behaviors can be checked independently of references to business contents. And that may open the door to automated tests generation.
With regard to similarities, tests should look for possible confusion between:
Objects with common representation but specific features (inheritance).
Operations with shared semantics but different scope (polymorphism).
Sequences with shared operations but different timing .
With regard to proximity, tests should look for possible confusion between:
Objects and their parts, or between their parts (structural proximity).
Operations usually associated into the same activity (functional proximity).
Operations usually executed successively (chronological proximity).
Scripts for such tests could be generated through pattern-matching and run by wizard applications.
