Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 :)

share|improve this question
Architecture Astronauting at its finest. No wonder they call it Space-Based Archtecture. – Robert Harvey May 24 '13 at 15:17
up vote 1 down vote accepted

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).

Conceptual Level Component/Block diagram

Design Level Component/Block diagram

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.

share|improve this answer
Good answer. Specially the 2nd paragraph (about entity relationship diagram) – BЈовић May 27 '13 at 7:18

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.

share|improve this answer
"it can sometimes be challenging to diagram architecture-level concepts using notations designed for object-oriented design." Works nicely, we do that in nearly every of our software products using a slimmed down version of UML. – Andreas Huppert May 24 '13 at 22:41
@AndreasHuppert, I didn't say impossible. But it can be difficult and depending on what views you plan to depict, unnatural. With so many diagrams to choose from using a slimmed down version as you mention is a very good idea. The second half of George Fairbanks' book "Just Enough Software Architecture" gives UML for software architecture a fair and thorough treatment. – Michael May 29 '13 at 2:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.