Use Cases

Preamble

Use cases are meant to describe what happens between system and environment.

Use Cases and UML diagrams

Use cases were first introduced by Ivar Jacobson before becoming part of standard UML. Their aim is to describe how systems under consideration are expected to support the execution of specific business scenarii.

Due to their simplicity and versatility, use cases are widely used to express system requirements.

• “Actors” are placeholders for agents performing their role in the scenario considered.
• Ovals  stand for the activities supported by systems.
• Interactions are figured by arrows meant to support communication of events or data.

Properly documented use cases will eventually include:

• Triggering conditions: Use cases are triggered by a single event possibly qualified by prerequisite state of business objects. As a corollary, there is a distinction between primary roles, source of triggering events, and secondary ones which can be prompted for participation.
• Extension points mark alternatives along execution paths. They are associated with rules.
• Post-conditions on the state of business objects after normal completion.

Pre- and post-conditions are described by rules.

Use cases may also be documented with other UML diagrams focusing on activities, transient objects and messages, participants and collaboration, and dialog states.

Since use cases are often employed well beyond requirements,  it must be reminded that they must remain “black-boxes” and what will happen within the system is off-limits. That may be easier said than done, especially when architectures are not finalized or systems are distributed. That difficulty may be overcome with use case patterns designed along a model driven engineering perspective.

Use Cases & Language

When specifying the details of use cases it may be tempting to bridge the gap towards analysis and introduce system oriented formalisms like sequence or class diagrams. That should be avoided as it would blur the semantics as well as the responsibilities. Nonetheless, some common language has to be found if artifacts further down the development path are to be traced back to requirements.  That can be achieved if a clear-cut distinction is made between functional units and detailed specifications.

• Functional units identify business objects and processes on one hand, their symbolic representation as system objects on the other hand.
• Detailed specifications are expressed using the specific languages of business domains under consideration.

From User Stories to Use Cases

Agile methods often prefer user stories to use cases as the tool of choice for requirements capture. Whereas respective outcomes are similar, processes do differ as use cases focus at once on interactions between agents and systems while user stories introduce them along the course of refinements. As a corollary, the former approach is at its best when new functionalities are to be added to existing systems, the latter more suited to standalone applications.

Yet, user stories may also be helpful to single out the main success scenario of use cases.

Shared & Optional Use Cases

Use cases can seldom be defined individually as shared functionalities are factored out and optional ones set apart. Standard UML provides <<include>> and <<extend>> relationships respectively for shared and optional use cases.

Yet, it must be reminded that all execution paths are meant to be triggered by a single event. As a consequence, whereas included or extension use cases can initiate interactions with specific roles,  they cannot be triggered by them.

Apparently, the same shared and optional activities could be expressed using generalization, with base use cases obtained by factoring out activities to be included by all execution paths. Yet, since the constraint about unicity of triggering event remains, primary roles of sub-cases, if any, must also be sub-roles of the base primary role. In other words users cannot communicate across abstraction levels but must collaborate directly. Given the lack of consensus about use case generalization, <> and <> relationships should be used whenever possible.

When collaboration involves use cases supported by other systems, they may be represented by services (see below).

Use Cases Perimeter

Use cases are meant to describe system interactions from user’s point of view. Hence, if black-box principle is to be maintained, whatever is triggered beyond the system under consideration must be kept hidden. As a corollary, semantics and controls must be defined within the limits set by the corresponding physical and symbolic containers:

• Interaction flows are defined within a single application domain, under a single authority. Objects from different business domains must be associated with explicit symbolic descriptions.
• Use cases execution must be controlled within a single location, namely, under a single clock and with all symbolic objects available without delay.
• Use cases can include distributed entry points providing no shared processing is involved and platform specifics are kept separate.

Whereas business and application domains can be set independently of platforms, that is not the case with entry points. The difficulty is therefore to specify use cases without implicit assumptions regarding technical environments.

Use Cases & Model Layers

As a first understanding, use cases describe interactions between users and systems, which would involve some implicit entry point. Since the nature of entry points is not necessarily known at requirements stage, and according to MDE guidelines, the definition of interactions should distinguish between pure functional flows and platform specific ones. As noted above, that could be achieved with abstract use cases or extension points:

• Platform independent use cases could be obtained by trimming off all specifications depending on platform. Such use cases would be limited to functional interactions and could not be instantiated.
• The alternative solution would be to define concrete use cases specific to platforms, which would include a single concrete functional use case. Ideally the latter would be described as a service.

It’s worth to be noted that none of those solutions neatly fit into the MDA framework of CIMs, PIMs, and PSMs. As part of requirements use cases appear before models could be properly layered, with parts clearly belonging to CIMs while others often platform dependent. This apparent mismatch illustrates the basic modeling alternative between abstraction and delegation.

• When aligned with architectural tiers (presentation, application, persistency), use cases can be described with <<include>> and <<extend>> connectors.
• Alternatively, if use cases are aligned with model layers (CIMs, PIMs, PSMs), they are best described with generalization and inheritance.

It must be noted that the choice of a modeling perspective will shape the description of variants: business driven (along model layers), or platform driven (along architectural tiers).

Abstraction & Modeling Strategies

“Abstraction” refers both to a modeling activity (singling out a subset of features) and to its outcome (a partial description of which there can be no actual instance). More formally (see abstraction layers), abstract artifacts are descriptions without extension, contrary to concrete ones, for which actual occurrences can be identified.

Yet, use cases are not to be confused with the classes which realize them; they don’t describe objects but phenomena, more precisely execution paths segmented by extension points. Accordingly, abstract use cases are activity descriptions which can’t be executed on their own. In other words abstract use cases have no path to be fully instantiated, i.e from start to completion. As a corollary, inheritance cannot be used for flows, only for activities.

At this point it would help to make a distinction between instantiation and realization:

• Instantiation is a matter of organization. It applies to the specification of execution paths, namely the full description of what may happen between use case triggering and completion. With that understanding, abstract use cases don’t have fully specified paths.
• Realization is a matter of system functionalities. It applies to the allocation of activities, namely how system functional components will support use case execution. With that understanding, abstract use cases left some activities without support.

Whereas both interpretations may eventually coincide, they must be mapped with the two modeling strategies mentioned above.

Roles & Realization

While roles (aka “actors” in UML parlance) are initially defined by business organization, they can also be associated with system entry points as soon as use cases realization is considered. If platform specifics are to be kept separate, roles must be defined solely by organization, independently of actual contexts.

Along that line of reasoning, roles can be structured just like use cases:

• <<include>> would target roles associated with cross responsibilities set in different business contexts.
• <<extend>> would target specific responsibilities.
• Generalization could provide an alternative formalism with the same semantics.

It must be reminded that, since roles are meant to describe parts played by agents interacting with systems, they cannot stand for organizational units or any collective agents. Yet, they may stand for systems representing organizational units, e.g messenger service.

Use Cases & Partitions

Partitions are the simplest way to identify variants and as such should be a primary choice when use case variants are considered. Extension points should therefore be associated to persistent or transient partitions:

• Structure partitions target persistency units. If execution units are properly defined, object status can be evaluated upfront.
• Control partitions target execution units and their status is meant to change along execution paths.

Use Cases & Activities

Whereas there is significant overlap, use case and activity diagrams are not to be confounded:

• Use cases deal with interactions between system and users, activities deal with processing rules. They belong to requirements, are specific, and are tailored for development purposes.
• Activity diagrams belong to business process, are introduced for management purposes, and not bound to specific applications.

As a consequence, their lifespan and stakeholder are different, activity diagrams being less volatile and managed independently of IT solutions. Nonetheless, since use cases will eventually be filled in with activities, some guidelines are required:

• Use cases see systems as black-boxes: they may pick activity descriptions from business processes but should not define them anew based upon interaction constraints.
• Execution units should be defined independently of platform specificities, and consequently of technical constraints on interactions, ie use cases.
• Since activity diagrams deal with logical flows and use case diagrams with execution paths, they overlap but don’t coincide. In other words, the rationale of end users applications (as defined by use cases diagrams) is not necessarily based on business rules (as set by activity diagrams).

It’s worth to note that those guidelines will greatly help to map use cases into model layers as set by model driven engineering.

From Use Cases to Aspects

Since use cases see systems as black boxes one should assume that they cannot make direct reference to persistency units. Yet, activities may do that from a business perspective, ie independently of supporting systems. The rationale behind such apparent double standard takes into account a second box, namely the business one, which makes for a three players games: business and system boxes plus use cases:

• Use cases describe interactions in terms of roles, events, and flows between systems and contexts.
• System functional components are off-limits, to be introduced at the next stage when use cases realization is considered.
• Functionalities already supported by existing systems (aka services) are modeled as actors.
• They may refer to activities as defined by business rules.
• Whereas they cannot shortcut activities by directly referencing persistency units, symbolic objects (persistent or transient) may be attached to flows with actors.

Criss-crossings between use cases and persistency units may be taken one step further using the aspect-oriented paradigm, which introduces a level of indirection representing objects as accessed by activities. Whereas aspects (aka facets) may be very similar to views, that could be misleading since aspects are dual descriptions built from use cases as well as objects perspective. When combined with object oriented paradigm, aspects can be detailed by use cases before being consolidated into functional architecture over the course of system analysis.

What’s Next: Use Case Realization

Since use cases see systems as black boxes, looking through white boxes should be the next step, namely the responsibilities for and sequencing of selected activities:

• Looking through system veils one should identify the symbolic objects that will take charge.
• Then describe how they will collaborate to fulfill user requests.

That’s where requirements should be mapped to (functional) architecture:

• Boundaries are standalone (not shared) active components realizing interactions with actual objects.
• Controls are shared active components realizing transient symbolic objects.
• Entities are shared passive components realizing persistent symbolic objects.
• Services are shared active components realizing the roles of external symbolic systems.

Further Reading

• Use Case Patterns
• From Stories to Models
• Requirements Metrics Matter

External Links

• Use Case Examples — Effective Samples and Tips
• Putcha V. Narasimham’s blog