Documentation instrument for software architectures.
Synonyms: Context Boundary, Context Diagram
Purpose, Goals, Content:
A system context completely displays all participating users and external systems with which the system to be described interacts, thus visualizing the environment of the system. This can be done from a technical as well as a technical point of view.
With the help of the system context, responsibilities are clarified: what does the system do and what does it not do? Where is the system boundary? Which external systems have to be integrated?
In the middle of the presentation, the system to be described is placed, around which are the participating users and third-party systems connected to the system by a direct line; if necessary, the lines contain further information.
A brief description is to be written for each displayed user or external system.
Tips for the Creation
- Represent the system to be described with the same model element that you also use to represent the system in your architectural model – e.g. UML Component with a stereotype “System” (or “SuC” for system-under-construction).
- If you model the connections as a UML Association, always from the users involved and external systems to the system, then it is easier for you to create information flows according to the motto “Who delivers which data?” display.
- Subject contextual view:
- Since the users interacting with the system and third-party systems are generally referred to as actors, the same model elements should be used as in your use case model – i.e. UML Actors:
- Users of the system in the standard representation as stick figures with the stereotype «SystemUser»
- Foreign systems in the alternative rectangle representation with the stereotype «ForeignSystem».
- Be sparing with the additional information on the links – the target audience is rarely interested in technical details such as communication types or protocols.
- Since the users interacting with the system and third-party systems are generally referred to as actors, the same model elements should be used as in your use case model – i.e. UML Actors:
- Technical contextual view:
- For the most part, this view is also the highest level – “How does the system embed itself in the environment?” Therefore, the following model elements are available for users interacting with the system and third-party systems:
- To represent third-party systems, either UML Components (modeling at the interface level) or UML Nodes (modeling without interaction points – that is, neither ports nor interfaces) – each have a stereotype «ForeignSystem» – can be used.
- Users of the system should not be portrayed as actors, but rather those systems should be presented that allow users to interact with the system – again (as before) as third-party systems.
- For the most part, this view is also the highest level – “How does the system embed itself in the environment?” Therefore, the following model elements are available for users interacting with the system and third-party systems:
- Always create both views: a technical one that fundamentally differentiates the system design and a technical one that serves as an introduction to the description of the architectural design.
Check List:
- Who is the target audience? Is a technical or technical contextual view necessary?
- Are all users and external systems exclusively and directly connected to the system to be described – but not to each other or indirectly via other users/external systems?
- Does a legend explain what each symbol means?
- If the number of displayed users and external systems is greater than 10, then it should be checked whether they can be abstracted by merging.
- Are there history descriptions for all users and external systems? And does it make it clear which roles they play for the system or why they even interact with the system?
Additional Information:
- [Zörner2015] , [Starke2015] , [Rupp2014] , [Oestereich2013]
- arc42 Reference: Chapter 3, “Context and Scope”