EA in bOwls: Use Cases (1)

Use Cases define how systems are meant to support users

Preamble

Set in the EA perspective, use cases can support black-box as well as white-box approaches, the former focused on business and organization, the latter on systems architecture and engineering.

As black-boxes, use cases can be aligned with business concerns and organizational units through triggering events and roles (or actors in UML parlance).

Figure 01 Use cases, Business, Organization

As white-boxes, use cases can support functional decomposition and serve as milestones for EA model-based engineering.

Figure 02 Use cases, Architecture, Engineering

The role of enterprise architects is to ensure that roles (or actors), domains, and events as defined by use cases remain consistently aligned with enterprises’ organization and systems.

Scope & Time frames

While it’s not for enterprise architects to delve into the specifics of use cases, they should make sure that their definition matches EA capabilities. To that effect enterprise architects can set requisite for the definition of use cases’ scope and time frame.

Scope: Domains

Enterprise architects should establish a distinction between anchored use cases, whose footprint can be circumscribed to single identified domains, and others, whose footprint cannot be neatly circumscribed upfront. That can be achieved with reference and execution connectors:

  • Reference connectors indicate read only accesses, possibly with locks (#)
  • Execution connectors indicate the possibility of changes, limited to the update of aspects, or also with create and delete operations (#)
Figure 03 Use cases Footprint

For example:

  • Articles in inventories are created by DinerUC_Inventories (connectExe#_) and updated by DinerUC_Supplies (connectExe#_)
  • DinerUC_Menus can lock articles in inventories through DinerUC_Pantry (connectRef#_)
  • DinerUC_Menus can perform all operation on menus (connectExe#_)
Figure 04 Use cases & Domains

Time frames

For enterprises operating across distributed locations, use cases should be explicit about synchronization constraints. That can be achieved with connectors and time frames:

  • Reference connectors to time frames deal with passive (or push, or data-driven) control, i.e., the coupling between sessions and representations: asynchronous or synchronous (#) updates
  • Execution connectors to time frames do the same for active (or pull, or event-driven) control, i.e., asynchronous or synchronous execution of use cases
Figure 05 Time frame coupling

Regarding referenced time frames, use cases usually come with a default time frame, typically the Gregorian calendar and Coordinated Universal Time. That enables the synchronization of representations at the enterprise level, e.g., inventories, purchases, and menus.

Figure 05 Time frame references

Whereas major database providers support temporal dimensions at the programming level, there is no consensus about their representation at the modeling level. With ontologies it’s possible to introduce explicit dimensions not only for temporality, but more generally for the modalities of actual or virtual realization (previsions, simulations, planification, …), arguably a significant capability for enterprise governance.

The symbolic representation of time frames can be especially helpful when push and pull inventory controls are mixed, i.e., when the synchronization of objects is combined with the synchronization of activities depending on the nature and shelf-life of products.

Taking a simple example, the execution of use cases for local purchases and deliveries is governed asynchronously by Purchase Planning; by contrast, the execution of deliveries is synchronized through DeliveriesPlanning. Both are calendar subsets, with the latter constrained by the former.

Figure 06 Time frame execution

Organization & Access Rights

Mirroring their relation to domains and the alignment of responsibilities for business objects with organizational units, use cases can do the same with regard to roles and authorizations.

To begin with, ontologies can help to clarify the meaning of roles, as defined by organizations, and actors, defined by UML as roles interacting with use cases. Putting aside semantic arguments, the distinction can be aligned with the one between enterprise and systems architectures, and thus can help with the management of access rights.

Assuming that roles are defined by organizations at the enterprise level, authorizations should be first aligned with domains, organizational units, and position; for example:

  • Templates (≈) are introduced supporting identity principles for employee (internal) and person (external)
  • Employees are sorted by organizational unit and position (powertypes)
  • Access rights (e.g., CRUD) are defined for objects or operations (powertype)
  • Access rights are authorized according to units and positions.
Figure 07 Authorizations

Use cases can then be tasked with checking the access rights for static as well as dynamic conditions:

  1. Static conditions are meant to be checked when use cases are triggered: access rights of roles (employees or parties) with regard to events and business objects
  2. Dynamic conditions are meant to be checked during execution; they apply to operations

That distinction is necessary to set apart what pertains to enterprise architecture from the specificities of business domains, which should be masked in applications.

Taking reservations for example:

  • Three basic accesses are defined for users, staff members, and branch managers
  • Branch managers are defined as a subset of staff members, i.e., they share the same identification mechanism; that’s not the case for users
  • DinerUC_Reservations as well as included DinerUC_ReservInit and DinerUC_ReservConfirm can be accessed by staff members and branch managers (as a subset)
  • DinerUC_ReservInit can be directly accessed by users
  • Since DinerUC_ReservUpgrade is an extension, it is subject to specific access rights, in that case for branch managers only
Figure 08 Roles

Accesses rights can thus be defined and managed along three axes:

  • Identity principle: rights defined in relation with the basis for authentication, biological, social, organizational
  • Business domains: rights defined for roles (positions in organization) and objects
  • Business functions: rights defined for actors (interaction with systems) and operations

Use Cases & Abstraction

Compared to models, one of the primary benefits of ontologies is to support different semantics of abstraction, and more specifically inheritance. Applied to use cases, three options can be considered: conceptual hierarchy, functional decomposition, objectives and realizations.

Conceptual Hierarchy

Conceptual hierarchies deal only with the meaning of terms, independently of their materialization. That corresponds to the default is-a semantics of OWL subclasses (yellow color) and can also be used to organize entries in thesauruses; their specific modeling semantics should be left to ontologies editors.

Figure 09 OWL hierarchies are neutral

That principle is applied uniformly to objects and activities, including use cases.

Functional Decomposition & Threads

Abstraction and specialization of use cases have been intermittently mentioned by successive versions of UML without being clearly defined. Part of the difficulty comes from a confusion between structures and behaviors, and more generally between object oriented (OO) design and functional decomposition.

Along OO principles, abstract use cases would be defined as activities that cannot to be executed (or instantiated) on their own, due to partial specifications (methods) or undefined triggering conditions (identification). But that interpretation introduces a confusion between inheritance of structures and of behaviors. Moreover, defining partially specified activities as abstract would directly interfere with the semantics of <<extend>> connectors.

In line with ontological neutrality, the alternative is to keep to a functional understanding of use case connectors:

  • Include connectors, with use cases whose execution (thread) is subordinate; that’s the equivalent of structural composition
  • Extend connectors, with use cases whose execution (thread) can be set independently; that’s the equivalent of functional aggregation.

Specializations and generalizations can thus be consistently expressed either in terms of functional decomposition (extend connectors), or in terms of threads, applying subset connectors between sets and subsets of execution paths.

Figure 10 Alternative representation of UC Specialization/Generalization

It must be noted that,

It must be noted that, when applied to use cases, the subset connector borrows its semantics from both include (a single triggering event) and extend (the subset could also be triggered in a different use case) connectors.

Details of sets and subsets of UC execution spaces and paths can then be integrated into business process models.

Objectives & Realizations

Finally, use cases generalization can also be understood in terms of broader business concepts and objectives. The former can be achieved through thesauruses, the latter through business cases.

For exemple:

  • dinerBCi:Complaints (business case) defines CRM objectives regarding complaints, in relation with the concept of Customer Experience
  • dinerObjective:CustomerExperience (objective) defines the assessment of customer experience
  • DinerUC_ManageComplaints is meant to realize a broader objective as well as a specific one
Figure 11 Business cases
Since business cases are not meant to be executed, they can be directly represented by instances.

References to objectives and business cases could thus be used to integrate use cases within strategies.

Further Reading