Recently I’ve been creating many context/system diagrams but have needed to link them to use cases. This is due to the nature of the development process and the need to identify affected components from the starting point of a use case.
For example, given the diagram:
and the following Use Cases:
- Import trade data from the Trade Data System.
- Import counterparty data from the Reference Data System.
- Join the two sets of data together, enriching the trade data with information about the counterparty.
- For each counterparty, calculate the risk that the bank is exposed to.
- Generate a report that can be imported into Microsoft Excel containing the risk figures for all counterparties known by the bank.
- Distribute the report to the business users before the start of the next trading day (9am) in Singapore.
- Provide a way for a subset of the business users to configure and maintain the external parameters used by the risk calculations.
I overlay a box that captures the components involved in an interaction within the use case.
I’ll repeat for all the use cases - although this may look quite messy if you try to include all on the same diagram. Using different colours/lines for each use case can help here.
This allows me to:
- Quickly identify which components are used in a use case.
- Identify components affected by new use cases or changes to a current one.
- Identify high coupling and ‘god objects’ (items that are used by everything).
- Make sure all components are in a use case - otherwise they might not be necessary or there is a missing use case. (Important if you are driving development from uses cases/stories.)
- Helps indicate where diagrams (or systems) could be split into multiple, simpler ones.
Structurizr has the ability to tag components with use cases, which you can then filter on to achieve a similar effect:
I find this to be a simple way to help bridge the gap between static and dynamic views and break down complex systems.
Do any of you do anything similar or have a completely different way to map use cases to components?
About the author
Robert works in financial services and has spent many years creating and maintaining trading systems. He knows far more about low latency data systems and garbage collection than is good for anyone. He likes to think of himself as a pragmatist who loves technology but uses what's appropriate rather than what's cool.
When not pouring over data connections or tormenting interviewees with circular reference questions, Robert can be found locked in his shed with an impressive collection of woodworking tools.
E-mail : robert.annett at codingthearchitecture.com