2

Having read about the 4+1 Kruchten, I am required to document a system architecture using this concept. Instead of the notations proposed by Philippe Kruchten, we decided to go with UML instead. I am particularly interested in the process view, as I don't understand how to map this to my processes. I know I can use sequence diagrams or activity diagrams as suggested by Wikipedia and a paper by Sparx Systems. But they do not provide examples or details about the diagrams themselves. I have identified 8 processes in the application I am developing an architecture for. Does this imply that I would need to develop 8 sequence or activity diagrams? I don't feel it would be logical to compress all those different processes into just one of those diagrams.

Example of some of the processes:

  • Account registration
  • Account authentication
  • Account lookup
  • Chatting

How should the implementation of the Process View be performed, using either of the two diagrams proposed? Are the identified processes sensible, or are they too abstract? Is it sensible and clear to make, for example, 8 separate diagrams, or one diagram covering all the processes?

2

Answering the questions an order that makes sense to me:

Are the identified processes sensible, or are they too abstract?

The items on your process list are rather brief and looks to me more like scenario heading names than processes. As I read it, in 4+1 processes are essentially running programs.

... At the highest level, the process architecture can be viewed as a set of independently executing logical networks of communicating programs (called “processes”) ... 4+1view-architecture.pdf

The process view is a decomposition of the interactions between programs (presumably in accomplishing a scenario). It may take several diagrams of the same type and of different types.

So, you're going to want to identify individual processes (e.g. programs) that are interacting to complete the scenarios.

Does this imply that I would need to develop 8 sequence or activity diagrams? Is it sensible and clear to make , for example, 8 separate diagrams, or one diagram covering all the processes?

Not necessarily. You will most likely need more than one diagram; however, you many not need exactly 8. After identifying the programs that are interacting (for each of the scenarios) you may find that several of them collaborate across two or more scenarios. For example, you may find you can show account lookup and authentication together on a single process view diagram (the interaction between client program, and several server programs).

Let's take a simplest possible example: you have two processes (programs) A and B. To show their interaction, you would use a single process view diagram (perhaps a sequence diagrams, but you might use communication or other as well). So, two processes that interact results in one diagram, if you will.

How should the implementation of the Process View be performed, using either of the two diagrams proposed?

First, as already mentioned, the key is to identify the processes (programs) that are interacting, and then create the process view(s) using diagrams to show those that interact (for a given scenario). I would suggest starting with communication diagrams, as these allow for showing interactions between components in an easy to read manner. If you need to show ordering of the individual interactions, then use a sequence diagram. The activity diagram should be held for subsequent detail. For one, activity diagrams don't indicate the "who" part of the interaction of the various steps of business logic (decisions, etc..), and in the process view you are trying to show, at least at the higher levels, the "who" of the interactions.

... Communication diagrams show which elements each one interacts with better, but sequence diagrams show the order in which the interactions take place more clearly. ... Communication diagrams, Wikipedia


As you identify the interacting components, keep in mind who is responsible or authoritative for what information. There does not appear to be lot of moral support in 4+1 for the information model, which I feel is a critical component of the architectural description of a system, that can be understood at a high level as who is authoritative and responsible for what content (and at a lower level can be elaborated in a more or less relational manner). For example, in an order system, the responsible component for accepting the orders is the same one that issues order id numbers, stores orders for later retrieval, the latter of which go to the information model and information responsibility aspect of the system.

Personally, I like Domain Driven Design, plus I add a higher level description of roles in the ecosystem. (Though I have also (had to) use TOGAF, which I feel is not the best but at least more modern than 4+1, IMHO).

  • Firstly, I would like to thank you for an elaborate and well-structured answer! However, as it currently stands, the application will retrieve other user's profiles from a storage, possibly through a web API and such. The hard part for me, and in your answer, is the "programs". From the description I would call the client a running program, the back-end would be a running program and possibly the storage. However, that feels a bit weird; not a lot of detail. I feel like calling "Account Authorisation and Authentication" a program, but I'm not architecting that to e.g. be a standalone program. – Zimano Jun 25 '16 at 16:34
  • The description of processes by Kruchten makes me confused about this even more, as my process names seem acceptable by following this definition. But I understand why you would classify them as scenario names. This is the description: " A process is a group of tasks that form an executable unit. Processes represent the level at which the process view can be tactically controlled (started, recovered, reconfigured, shut down, and so on). In addition, processes can be replicated to distribute processing load or improve system availability." – Zimano Jun 25 '16 at 16:57
  • You have to realize that this 4+1 architectural stuff comes from the '90's. When they're talking about tasks, they mean practically mean threads, when they say executable unit, they mean practically mean binary executable program. It is a process that can be externally terminated and restarted (because they are programs). Showing the processes communicating with each other is the point of the process view; whereas the method by which the tasks communicate is more internal to an individual process. – Erik Eidt Jun 25 '16 at 17:23
  • None the less, we can choose to interpret the text(s) more abstractly, and use a more general notion of communicating components (over communicating processes), e.g. as you suggest, client, server, storage. So, identify the components, and show their communication in comm diagrams and/or sequence diagrams. – Erik Eidt Jun 25 '16 at 17:25
  • "The software is partitioned into a set of independent tasks. A task is a separate thread of control, that can be scheduled individually on one processing node.". So, one can show the individual tasks and how they coordinate within and between processes, but the high level process view should communicate how processes interact abstracted of their internal subdivision into tasks. Fundamentally, we need to identify what the top-level components are and show them interacting. Of course, for more detail, we can engage in recursive decomposition of those components. – Erik Eidt Jun 25 '16 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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