Reflections on Abstractions: The Use Case trade-off

Loosely collecting examples of abstractions on finite relational structures:

Relational World

relational abstractionIn the posting Adjacent Rooms we had an abstraction as in figure (abstraction by ‘is related’), a mapping with the structural unsatisfactory property to be non-unique on the model-side, e.g. the ‘2’ in the original is mapped to 2 different nodes in the model. However, we also saw an example where this sort of abstraction fits quite well, and thus speaks in favour of the relevance of this kind of abstractional mapping.

Real World

request processinguse cases request processingAnother such example is the abstraction of functionality by Use Cases. Figure (Request Processing) shows a simple process for handling customer requests, that can be of various kinds, like placing an order, a request for product information, or a change of the billing address. Think of the activities as nodes of a graph as above.

Now, the basic idea of a Use Case is to lump together activities such that they form an emergent behaviour (easy to comprehend). In figure (Use Cases) we have three of these. Obviously the Use Cases are overlapping, since e.g. the ‘Dispatch request’ activity is contained in all Use Cases, as well as ‘Send reply’ appears in ‘Update Static data’ as well as in ‘Request Information’ (indicated by the edges among the Use Cases). Thus we get better understandable (emergent) units of functionality, however usually for the price of a non-unique mapping.

Based on the elementary terms of relational structures, this shows the basic trade-off of Use Cases: emergence vs redundancy.


  1. The ‘extend’ or ‘include’ relationship in UML are typical elements to address this redundancy issue.
  2. Compare the kind of knowledge gained out of such a formal analysis as above to that you get from common text books on Use Cases. Moreover, seems that some very popular books, don’t address this trade-off at all (!?)

So long

About modelpractice

Modeling Theory and Abstraction Awareness in strive for scientific rigour and relevance to information systems engineering.
This entry was posted in Mathematics, Reflections on Abstractions, Requirements, Software_Engineering and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.

1 Response to Reflections on Abstractions: The Use Case trade-off

  1. Pingback: What can Software Modellers learn from Innovation Methodologies? | modelpractice

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s