Process View in architectural design

The complexity of software solution nowadays implies to the software engineers and specialists to follow certain golden rules. The majority of these rules are mentioned in what is called the software engineering field that focus on approaches and methods used by software engineers to design, develop, deploy and maintain software.
One of the important aspects that should be considered and applied at different level of the software life cycle and any system development in general is to draw and present ideas, components, flows or processes as graphs.

We’ve all used this approach in any phase of project without really putting an exact attention to the process itself. I personally remember different situation where I used graphs to model or represent different tasks of my work as:

– Brainstorming ideas during meetings with end users.
– Representing the different layers of a software solution.
– Designing the data flow in different functions from the initial user’s inputs to the generation of the result.
– Representing by a model how a user might interact with a solution…etc.

All theses approaches of modeling and representing process and flows are known as architectural models, they are used mainly to document a design for better implementation and future evolution. (Sommerville, 2011)
Different graphs and models can be used depending on the context and situation; In fact, there is the conceptual view, logical view, process view, development view …etc.

Focusing on process view, it shows the interacting processes of the system, this representation can be useful to determine the functional system characteristics such performances and availability (Sommerville, 2011).

Brooks defined the process view as Analyze & Design discipline, it illustrate the process decomposition including the mapping of classes and subsystems (Brooks,1995).

From UML point of view, Booch stated “With UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view – i.e. class diagrams, interaction diagrams, activity diagrams and statechart diagrams, but with a focus on the active classes that represent these threads and processes.” (Boochm,1998).

Here is an example of a process view representation

Figure 1: A sample representation of a process view (Brooks, 1995).

The process view present many advantages as:
– Simplicity of modeling
– Easy read and interpretation of the view
– Easily maintainable
– Give an overview of the solution
– The flow might also be represented with arrow from a state to another …etc.

However, we can notice a weakness in the details level, as it shows only the general view and it is very difficult to integrate in the same view (graph) additional technical details.

References:
Ian Sommerville (2011). Software Engineering, 9th edition, Pearson edition, ISBN: 978-0-13-703515-1

Frederick P.Brooks, (1995). The mythical Man-Month-Essays on Software Engineering 2nd Edition. Addison Wisely Longman.

G. Booch, J. Rumbaugh, and I. Jacobson, 1998. UML User Guide. Addison-Wesley Longman