Use Cases Shouldn’t Know About Classes


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, and specific concerns

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.

Further Reading



14 Responses to “Use Cases Shouldn’t Know About Classes”

  1. putchavn Says:

    Your statement: classes are meant to describe software components, including those executing use cases. applies to some of “design classes” but not all classes.

    Classes include Domain Classes which belong to business.

  2. putchavn Says:


    Use Cases do use data and information of domain classes and thus cannot be “ignorant of classes (not knowing classes)”

    UseCases may not know design classes but do send / receive data and information to them collectively.

  3. caminao Says:

    Would you say that domain classes describe software components ? And if not, what do they describe ?

    • putchavn Says:


      No, domain classes which describe / represent business objects exist separately and independent of software objects / components.
      Software components are created to read and process data and information emanating from business objects / domain classes and deliver processed data.

      Data and Information of the domain classes are sent / received by the Actors using / working with them. The data / information are acted upon by the “design classes” or generated by them. sensors / interfaces are used to extract / convert data. At times Actors (human or machines or devices) create / convert data and information.

      Within the System only data / information are transmitted / processed.

      This is valid for many applications.

  4. caminao Says:

    I’m not sure about domain classes as descriptions of “emanations” from business objects … Looks like UFOs.

    • putchavn Says:

      Don’t hand on the word “emanation” literally. Domain objects have data and information which are either transmitted or read or picked up from them. through devices or Actors. At times Actors observe business objects / processes / phenomena and key-in data / information.

      No need to bring in UFO into this discussion.

  5. caminao Says:

    Still, I don’t understand what you mean by domain classes if not descriptions of representation of business objects as software representations.

  6. putchavn Says:

    Ultimately what ever is represented within computer software is software representation but OOAD UML makes a distinction between sub-classes of classes, namely domain classes and design classes.

    UseCases which are representations created by a BA or RE or software developer who “needs to know or be aware of” the relation between domain classes and their data / information and UseCases much before any software is created. At this stage UseCases are mere representations and as such cannot “know” anything but when realized as software, UseCase realizations (which are different from UseCase Descriptions) need to be “able to exchange data / information with Actors external to the SuC (System under Consideration) and representations of domain objects and design objects within the SuC.

    My comments related to the “necessity” of UseCases to be “able to communicate with” (which I take you call “know”) objects of domain classes and design classes, notionally in the modelling stage and operationally after implementation.

    Thus, I disagree with you claim that “UseCases should not know about the classes” with the interpretation that “know” is “the ability to communicate with”.


  7. caminao Says:

    A core tenet of use cases is that they only communicate with actors.

    • putchavn Says:

      UseCases do not communicate but one set of messages (dialog) between an Actor and SuC leading to a defined goal is a UseCase.

      This is the essence of UML UseCase though the UML definition is NOT so specific and clear.

  8. Says:

    I agree that what is shown in a Use Case Diagram (UCD) should typically not include the functions/classes/packages performing each use cases sequence of actions (i.e., its definition). The reason is simple – a UCD only identifies use cases (by only showing their name) and their associations. The functions/classes/packages performing a use case’s sequence of actions should be shown in another diagram/form – a diagram/form that actually defines the use case (e.g., Activity Diagram, Sequence Diagram, Cockburn format of basic/alternate/exception flows).

    If this discussion was titled “Use Case Diagrams Shouldn’t know About Classes” I would agree that UCDs should not. However, a fully defined use case must provide a sequence of actions (i.e., a basic flow) that identify the behaviors/functions performed by the system/component being used. Because of this, a Use Case Should (eventually) “Know” about the functions/classes/packages that are needed for the desired use.

  9. caminao Says:

    Aspects can provide a “need to know” basis for use cases visibility on classes.

    • putchavn Says:

      OK Remy, how does it relate to System Sequence Diagrams and iterative emergence of design classes? If “aspects” reduce the iterations to define design classes they would be valuable. I will take a look.

      So, some agreements and understanding is emerging. Welcome.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: