In the post Grouping Components by Use Case, Robert Annet discusses a strategy he uses when making context diagrams. After determining the use cases of his program, the components involved in each of the seven use cases are divided into groups within the diagram with different colored barriers. Structurizr, the web application Annet used for his diagrams, allowed him to filter the diagrams by the use cases. This makes observing which components are involved even easier visually.
The benefits of using this strategy of dividing your context diagrams into use cases is clear if you are working with a program that is complex enough to warrant it. A complex program in this case being one with a lot of different components which all are involved in several different interactions. If you have to make changes to a certain interaction withing your program, you can look at the components involved in the use cases and identify what you have to change to make the desired effect. Since your program has a lot of different and interlaced interactions and components, using these use cases and filtering your diagram into smaller parts makes it easier to understand the interactions and whats happening with the involved components without being overwhelmed by a ton of different components that don’t have any involvement. In my opinion, it is much clearer when you only have to see two or three components when you want to change an interaction in the program.
Using this strategy can also help you find other issues or reliances in your program. For instance, you may find that most or all of your use cases use the same component. Since this component is so integral to the interactions in your program, it is likely not one you are going to want to change much. This strategy also can help you find components that are not being used in your program, and thus may be unnecessary or you may need to reassess your use cases.
Overall, I thought Robert Annet’s idea of dividing programs into different use cases is very interesting and obviously useful as a concept, so I’m sure I’ll use in the future. Whenever you are dealing with a large enough system, you should consider looking at the diagram from this angle to see if you can identify any problems or vulnerabilities.