I am a little confused at how best to visually model a space-based architecture (SBA) for presenting the system/software architecture design to a client.
The goal of this modelling is to show:
- The major components of the system (e.g.: databases, server exposed API, client, server workers, client exposed API)
- Interactions between these major components
- Primary end-to-end workflows
Currently I am thinking to use BPMN2 notation with swimlanes; and sequence & use-case diagrams in UML2 notation.
Not sure if this approach is best, would be great to get some feedback 🙂
1
Agree with the previous answer. As mentioned there, the model types mentioned in the question will not help you alone.
In case of a non-trivial data model or business domain, I recommend to start with an entity relationship diagram. It is easy to understand, the few symbols are quickly explained.
Include proper definitions of the entities. This will make sure everyone has the same understanding of the domain. The relations with the cardinalities will also sort out many misunderstandings in advance.
A block diagram is usually the main diagram to show the runtime composition of the architecture. Indicate protocol and system boundaries. Choose an abstraction level which fits the purpose, and then be as specific as you can with the elements you show. E.g. in a communication channel, indicate who initiates the request, the data flow direction, and the protocol used. Describe the purpose of each component and connection in additional text below the model in case it is not trivial or obvious.
SAP uses a slimmed down UML version for architecture (as described here).
You might use the other diagram types if required.
Don’t forget that there might be a design time view of an architecture which is different from the runtime view. E.g. you might have layers in the design time which are collapsed by a compiler for the runtime.
1
With any architectural modelling and representation you have to consider your audience and what notations will most easily and accurately communicate the designed structures as well as rationale for those decisions.
Two good things —
- Using a documented and “standard” architectural style (SBA) helps with communication by way of pattern recognition. If someone knows the style, knowing that you are using it will help that person understand more easily.
- Using a documented and “standard” notation for diagramming will assist with readability in that individuals who know the notation will be able to infer structures and meaning more easily.
The caveat, of course, is that you cannot assume that everyone will already know the styles and notation conventions so you must still use standard diagramming best practices (e.g. legends, clear labels, not mixing perspectives, multiple views and viewpoints, etc.)
The only other catch regarding UML notations for architecture representation is that it can sometimes be challenging to diagram architecture-level concepts using notations designed for object-oriented design. I don’t see how either of the notations you’ve mentioned will help you model the architecture. Use cases aren’t just pictures. And business process modelling has nothing to do with structures — dynamic, static, or physical.
2