Summary
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.
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).
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.
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.
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
Aspects can provide a “need to know” basis for use cases visibility on classes.
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.
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.
What Stephan posted above is what I posted earlier with one difference.
UseCase Descriptions (Dialog Messages to be more precise)should “know” at lease some of the “domain and design classes” but NEED NOT Show them in UseCase Dialogs.
At this stage of UseCase modeling, some aspects of domain and design classes emerge but they are not fully defined. They are hypothesized and iteratively consolidated.
See: http://www.slideshare.net/putchavn/systematic-identification-of-design-classes-with-live-objects
Cheers,
17JAN15
A core tenet of use cases is that they only communicate with actors.
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.
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”.
CHEERS
Still, I don’t understand what you mean by domain classes if not descriptions of representation of business objects as software representations.
I’m not sure about domain classes as descriptions of “emanations” from business objects … Looks like UFOs.
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.
Would you say that domain classes describe software components ? And if not, what do they describe ?
Remy:
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.
Continuing…
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.
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.