Thread: Use Cases

Preamble

As introduced by Ivar Jacobson Use cases (UCs) are meant to describe how users interact with systems.

That entails a twofold objective:

• Capture and elicit requirements from the business processes viewpoint.
• Build a clear, consistent, and consolidated description of expected system functionalities.

In that context use cases can be seen as a Swiss-army knife that combines simple and unambiguous concepts, textual specifications, and formal modeling extensions, to be applied to a wide range of development models.

Use Cases & UML

Use cases are at the same time the UML flagship, its main innovative component, and the glue that consolidates its other (preexisting) methods. That success, which largely outdoes UML’s favor, 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 that are supported by systems) and realization (UCs are implemented by software applications).
• Simplicity: while UCs may be extended as to include formal (e.g pre- and post-conditions) and graphical (e.g activity diagrams) specifications, they can be fully defined and neatly circumscribed with stick actors (for the roles played by users or any other system) and ellipses (for the targeted system’s behaviors).

Yet, when not standing on their own, UCs provide a reasoned bridge between requirements analysis and UML based development:

• A use case can be represented by a simple binary sequence diagram for primary actor and system, with the latter to be further decomposed through requirements analysis.
• Business objects referenced in context can be associated with their system representation through class diagrams.
• Business logic and scenarii can be detailed using activity diagrams.
• Business states of objects, activities, and expectations can be described with state diagrams.

That being said, there is no symmetry between business processes and supporting applications: if the latter must be driven by the former, use cases are to be identified by actors and triggering events.

Actors & Events

Actors are the cornerstone of use case modeling because they stand simultaneously for (1) the roles of agents into the organization and (2) the way they are to be identified and authorized by the applications under consideration. Since that duality (actor and role are the two faces of the same artifact) guarantees the alignment of systems and organization, ignoring it may severely undermine system access, confidentiality, and security requirements.

Events are arguably the conceptual chink in UC armor as their definitions vary from tautologies (e.g “notable occurrence at a particular point in time”) to programming (e.g “subclass of packageable element”). Yet, as far as UCs are concerned, events are to be understood as the manifestation of changes in the state of objects, activities, or expectations.

Variants & Complexity

Actors and events are the primary artifacts of UC modeling, the former for the alignment of systems with organizational context, the latter for the coupling of systems with actual context. Once both are properly defined, use cases can be fleshed out in order to deal with business and functional complexity:

• Business complexity depends on business logic which should be defined independently of system functionalities.
• Functional complexity depends on business complexity and access to supporting systems.

Whereas systems functionalities are supposed to support business processes, the solutions are not necessarily congruent and the respective complexities should therefore be explored on a “divide & conquer” basis. With UCs that can be done with scenarii (for business logic) and operators <> and <> (for functional complexity). Being more general, the <> operator can be seen as the default option as its relevancy can be decided independently of what will happen during UC execution; <> is more specific as it is bound to execution paths and comes with a selector (aka extension point).

Generalization and specialization may be introduced as an alternative to <<include>> and <<extend>> operators, providing there is no confusion between the semantics of inheritance and abstraction for classes (applied to features) and use cases (applied to interactions).

Scope: Requirements Taxonomy

Use cases being first and foremost a tool for requirements capture and analysis, their scope must be clearly identified with regard to owners, stakeholders, and users:

• Functional requirements are meant to deal with contents, business logic and supporting systems contribution. As such they are supposed to originate from well identified business units and their granularity can always be adjusted as to coincide with clearly identified use cases.
• Non Functional Requirements  are not defined by contents but by context (e.g quality of service) or engineering (technical requirements). While quality of service is usually specified at user level, it is seldom limited to specific organizational units, and therefore circumscribed to single use cases.

Functional requirements are therefore the typical scope of use cases. Business and quality of service requirements are to be validated by users of different use cases, and technical requirements are not supposed to be validated by users.

Scope: Stories & Use Cases

As already noted, business requirements are a recurring component of use cases but are better managed independently. That can be done with use cases due to their clear and compact formalism that can be understood by business as well as systems analysts dealing with:

1. Requirements capture and elicitation: when written documentation is needed as a communication medium between business and system analysts.
2. Requirements analysis: when different use cases have to be conciliated, arbitrated or consolidated into system functional requirements.

Depending on (1) the specificity of languages for business domains and (2) the gamut of concerns behind them, the path from business to functional requirements may be covered in a single step or will have to mark separate steps. In any case, the bearings of use cases with regard to business and systems are best understood when set against users’ stories:

• Like users’ stories, use cases are set from specific viewpoints within organization; for UCs that is to be materialized by primary actors.
• Like stories, use cases must focus on a single activity whose various contents can be detailed progressively; for UCs that is to be materialized by goals and triggering events.
• Like stories, use cases must be justified by business objectives set at enterprise level.

Along that understanding the difference is to be found in scope: use cases deal with the subset of stories’ activities meant to be supported by systems.

Contrary to roles (Who) and goals (Why) set at users’ stories level, use cases’ activities are to be redefined when supporting systems are taken into account and restrictions introduced with regard to objects (What), actions (How), places (Where) and timing (When). For that purpose one may use Aristotle’s three unities for drama:

1. Unity of action: units must have one main thread of action introduced at the beginning. Subplots, if any, must return to the main plot after completion.
2. Unity of place: units must be located into a single physical space where all operations can be carried out without depending on resources or activities located elsewhere.
3. Unity of time: units must be run within a single time-frame, with all operations controlled by the same clock.

Applying those criteria will clearly entail different outcomes depending on the constraints associated with supporting systems.

Boundaries: Processes & Use Cases

Business processes can be seen as a set of operations executed by agents (people, devices or systems) subject to organizational, functional or synchronization constraints; based on that understanding use cases describe the segments involving systems, namely how they are addressed (messages) and what they are supposed to do (business logic).

Whereas the distinction between messages and business logic may sometimes be ignored, it will clearly enhance the plasticity and versatility of functional architectures: as illustrated by Web applications, the same business logic can be used by different business processes and applied in very different functional ones. Hence the benefit of documenting use cases on two levels:

• A header dealing with the communication between actors and systems. It is focused on conditions, expectations and commitments and is bound to functional context.
• Contents, documented by scenarii and business logic, best described independently by text or models, e.g with BPM or activity diagrams.

Factoring out UCs’ headers put the focus on action semantics, in particular on the nature of the coupling between environment, process, and system:

• How changes in business context are to be taken into account by the system.
• What kind of support, if any, the process is expecting from the system.

While that taxonomy of use cases’ headers cannot pretend to cover the whole of requirements, it documents critical functional constraints that can be directly mapped to architectures.

Patterns: Business Perspective

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

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

Compared to business use cases, Cockburn stays with UCs as defined by Jacobson but refines them with clear purposes for users, summary, and functions:

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

UC standard connectors can be used to refine the semantics.

Patterns: Functional Perspective

Mapping functional requirements to object oriented designs has been a recurring question of software engineering. If clear solutions can be developed for standalone applications, problems are more challenging when business requirements are to be consolidated into functional architectures. In that case the problem is to map use cases to system components without forcing the former into objects or the latter into applications; that can be done by introducing a level of indirection between business and technical concerns.

Beyond differences in names, there is a broad consensus about the nature of the layer, generally known as functional, and associated stereotypes (boundary, control, entity, service). Use cases functional patterns can be defined with regard to these stereotypes:

Next, UC functional patterns could be refined along action semantics using UML modeling templates:

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

Implemented with use case slices (introduced by UC 2.0), such a principled mapping to functional architectures may significantly improve traceability and transparency of systems engineering.

Development Perspective: Iterations

Contrary to some narrow-minded understandings, use cases are not necessarily associated with upfront phased development models and can be easily tailored to the iterative exploration of project scope. Once triggering conditions (context, actor and event) clearly identified, development cycles can be defined with regard to:

• Use case invariants: primary actor, triggering event, pre-conditions, and goal.
• Scenarii: execution paths sequenced by extension points representing actor choices or variants in initial conditions.
• Backlog units: activities to be performed (once or more) along execution paths.
• Exit conditions: validation of sequences of activities along execution paths.

Depending on project organization (e.g agile or phased), deliverables will be managed around activities or scenarii.

Use Cases & Systems Governance

On one hand use cases are driven by concrete, partial, and specific business needs with short term lifespans set by business environments. On the other hand functional and technical architectures are assets with life-cycles set by organizational, financial, and engineering time-frames. How the former can be aligned with the latter is the main challenge of systems governance.

That is where use cases may be especially useful when alternatives and priorities are to be considered, balancing short term users’ value and long term business objectives with functional assets, engineering outlays, and operational costs.

Further Reading

• Use Cases
• How to Mind a Tree Story
• From Stories to Models
• Spaces, Paths, Paces (part 1)
• Use Cases Patterns
• Use Cases shouldn’t know about Classes
• Business Processes & Use Cases
• Focus: Business Processes & Abstraction
• Focus: Business Cases for Use Cases
• Use Cases & Action Semantics
• Making the rules
• Modeling Paradigm

External Links

• Ivar Jacobson International: Use Case 2.0
• Scaled Agile Framework