Sound advice - blog

Tales from the homeworld

My current feeds

Sat, 2008-May-31

The Process View

This is part three in a series that checkpoints my evolving understanding of for architectural descriptions. I have already provided a description of the Logical View. This view captured End-user Functionality in a process based more deeply in Systems Engineering than in Software Engineering. Today I cover the Process View and its links into the Development View.

Let's revisit the set of views as a whole:

4+1 Views Diagram

We can see the Logical View tracing independently to the Process and Development views. Each of these views then traces independently to Deployment. I had a lot of trouble figuring out how to make this work for me, from a UML purist and a tooling perspective. I finally settled on a slightly different approach based on .

I have ended up including the final set of components in each of the "design" views. The same set of components appear in the Process, Development, and Deployment (Physical) Views. This achieves the goal of relating different design views together. It also fits with the ideas in the UML Superstructure specification:

The component concept addresses the area of component-based development and component-based system structuring, where a component is modeled throughout the development life cycle and successively refined into deployment and run-time.

The process view I came up with is based around a UML component diagrams, where components from the upcoming development view are show assembled into running processes. This suits the kinds of designs I am doing. It may need tweaking to suit your own needs.

Let's dive into an example with a quick review the logical view functions:

Logical View Functions

I have elaborated on the logical view functions based on the process decomposition as follows:

Process View Main

The logical functions of Sales, Inventory, Shares and Tax Reporting are still present. New are the Web Browser and General Ledger packages. These packages are the result of design decisions in implementing each function. Let's look at Sales:


This diagram captures the whole Sales function, a theme I will follow throughout this and subsequent views. The constant relationship to the Logical View helps establish the link between requirements and all aspects of design. The Sales Ledger Updates interface is still present from the Logical View. This is served by the Sales Manager component in the identically named process. A Web Browser is used as part of the HMI, and General Ledger is used as part of the Historical Sales Register.

The Sales Ledger Updates interface is confronting right up front. Am I not a advocate? Isn't defining an interface like this against the principles of REST? Well, no. I fully expect this to be a REST interface. However, I am approaching this design from the customer focused logical perspective. From this angle, the most important thing to know is what information is transferred. An Interface Control Document will be required to identify the set of URLs that Sales Manager provides, and specify exactly which REST operations are necessary for each URL.

On the other hand, we could easily make the design decision at this point that the interface will not be based on REST. It could be a less constrained SOA. It is for this reason that I feel I can talk about REST being a constrained subset of SOA, part of the SOA family, or "SOA done right". At this point in the design process SOA and REST are indistinguishable.

The General Ledger is the next thing that jumps out. That wasn't in the logical view. There was no requirement for a General Ledger. Instead, Sales was supposed to make data available to Tax Reporting for processing. Here I have used my design experience to say that we should have a General Ledger (a summary record of any type of financial transaction). There is no point requiring the processes of Sales, Inventory and Shares to appear as part of the Tax Reporting function. The General Ledger allows us to put these functions at arm's length from each other.

The Web Browser is fairly obvious, but looking at Sales Manager: Why haven't we decomposed it further?

The answer is that in this case I want to give the developer of this service maximum flexibility in how they implement it. If there were a library that is common to other functions it would need to appear (which begs the question of why there are no such libraries... have we missed something?). Internal structure of a process that has no need for Intellectual Property separation or for other forms of separation might as well stay part of the same component.


Inventory follows a similar pattern to Sales. However, we do have two distinct GUIs identified the logical view. It makes sense to keep these separate, because they have quite different usage profiles. I have decided to use a thick client approach, here, rather than a Web Browser. Part of the overall Inventory HMI is a scanner, and the thick client grants me better access to the scanner's feature set than the browser would afford.

The obvious design question arising from this diagram is how Stocktake and Inventory Scanning GUIs coexist within the same process without any apparent coordination whatsoever. Have we missed a navigation GUI that allows us to select one mode or another? Should they simply be in different processes? Do they need a common library of any kind to communicate with Inventory Manager or drive the scanner?


Here I show the interior detail of a process. The Portfolio Manager is constrained by this design to follow a Model-View-Controller approach internally. The Views are fed to a Web Browser, or to the General Ledger by export. The Model is updated by its HMI, or from the Stock Quote Client driven by Periodic Execution. All of this is coordinated through the Portfolio Manager.

Tax Reporting

Tax Reporting extracts data from the General Ledger using a Reports Engine, and again uses the Web Browser for final display. The Tax Reports give me the opportunity to show a software component that is really simple configuration data. It is clearly separate from the Reports Engine, and uses a dependency relationship on the engine. The dependency direction could be viewed in either direction, however it is easier to trace requirements to a lower level with the arrow as stated. This diagram says that the Tax Reports use the Reports Engine to do their job, as opposed to the other way around. That means that we can talk about the Tax Reports as having to achieve certain GAAP requirements while leaving the Reports Engine itself with fairly generic requirements such as "must be able to query SQL".

General Ledger Web Browser

The final images are fairly boring, just to show that the packages we discovered in our journey through the Process View will generally get their own diagrams and description. You could show the processes of components they connect to, but that information should already be present elsewhere. These non-functional packages will be flowed through the Development and Deployment (Physical) Views in due course.

You could argue that the inclusion of components the in above Process View means that there is really no design left for the other views. You would be right. The main objectives of this architectural description are met: To define the set of components and interfaces in the architecture. The subsequent views are relatively boring, compared to the exciting leap from systems-based logical to software-based process views. However, they each bring their own charm and provide useful checkpoints to discover flaws in your architecture.

I suppose another question-mark at this point is the detail of the internal interfaces between software components. I have identified links, but not tried to establish a functional baseline for these links. For this we would likely need to go through a round of requirements allocation and decomposition and follow the process of the logical view again. I defer the specific work on functional interfaces to the next level of design document down.



Thu, 2008-May-22

4+1 Logical View

I want to make clear at the outset that I am not an expert in 4+1. I have spent the last few months working with systems engineers on an Australian rail project, and this is the sum total of my systems engineering experience. I am reasonably happy with my understanding of both concepts as they apply to my specific situation, but this approach my not apply to your problem domain. I am using StarUML for my modelling, and this pushes the solution space in certain directions.

2008-09-08: So that was then, and this is now. What would I change after having a months to reflect? Well, I think it depends on what you are trying to get out of your modelling. The approach I initially outlined is probably OK if you are trying to cover all bases and get a lot of detail. However, now we might step back into the product space for a while. What we want to do is get away from the detail. We want to simply communicate the high level concepts clearly.


The first view of the for architectural descriptions is the Logical View. A classical computer science or software engineering background may not be a good preparation for work on this view. It has its roots more in a systems engineering approach. The purpose of this view is to elaborate on the set of requirements in a ways that encourages clear identification of logical functions, and also identifies interfaces to other systems or subsystems.

The general approach that I have been using for this view is a combination of and diagrams. The elements in these diagramming techniques are similar, but both are constrained in my approach to serve separate specific purposes. Robustness diagrams are drawn by working through an input requirements specification. Out of this process "functions" are discovered and added to a functional data flow diagram. Finally, a context diagram is constructed as an extraction from and elaboration on the function data flow diagram with external systems identified.

Interfaces are identified at every stage through this process, including Human-Machine Interfaces. The structure of robustness diagrams make it relatively simple to identify missing interfaces and other gaps in the analysis. The interfaces identified are reflected in the following Process View.

The first thing I would change here is that I would split the concept of a 4+1 Logical View and the systems engineering -style functions diagram. The second thing I have been doing has been to try and limit my content to a single diagram. I'm trying to contain the urge to reach for crinkly goodness in favour of saying "just enough".

Context and Function Data Flow Diagrams

Data Flow Diagrams are very simple beasts, made simpler by the constraints I apply. For the purpose of identifying functions we use only circles for functions, and directed associations for data flows. Other features such as data sets or identified interfaces are banned in the function and context data flow diagrams. Data flows are labelled with the kind of data being transferred, and functions or systems are named.

Some guidelines for the definition of functions:

The set of functions should describe the system as the user sees it, rather than how it is built. The data flow diagrams describe relationships between systems or functions, not between software or hardware components. As additional constraints on these data flow diagrams I do not allow the expression of data stores at this level. They are described in the Robustness diagrams where necessary. This level is purely about flows of data between units of behaviour. The flows do not discriminate between REST-style, database-style, API-style, or any other style of interface. How the interface itself is expressed is a design decision.

Unfortunately, I was on crack when I wrote some of this. In particular, I have the concept of functions almost completely backwards. What I ended up calling functions are more like subsystems and... well.. you get it. I have since been corrected in a number of areas.

Here is how I would draw the robustness diagram today:

Updated Context Diagram

The context diagram remains the same, and I would continue to include it. I have started to prefer describing interfaces in terms of the information they communicate rather than trying to preemptively name and collate them based on other factors.

Updated Functions

Here is a functions diagram, where I have collected the functions back down into a single figure. The key interfaces are still present, and I have two basic sets of data in the system. I have the ledger data, which is based on pure accounting principles. The other data is the historic share prices.

The share prices are acquired and stored based on live stock quotes. This information is combined with ledger-based accounts data for the shares investments in order to generate appropriate reports.

Other sources of data for accounts include the daily sales ledger acquired from the Point of Sale system, internal movement of warehouse stock, and input from stocktake operations.

Per-function Robustness Diagrams

Robustness diagrams consist of boundaries, entities and controls. Boundaries are interfaces to your system, including Human-Machine Interfaces. These are functional interfaces, so typically identify broadly the kind of information required or the kind of control exerted through the boundary. The set of boundaries may be refined over subsequent iterations of the logical view, but do not be concerned if they do not line up exactly with the set you expected. Multiple functional HMI boundaries may be combined into one user interface to provide the best user experience. Multiple software or protocol interface boundaries may be described in a single Interface Control Document.

The process of building up the functions involves reading through requirements one at a time. Look for vocabulary in the requirements that suggest a system boundary or entity. A single requirement may appear as an entity in your diagram, or many requirements may map to a single entity. Only a poorly-written requirement should require multiple controls to be associated with it. Entities are identified when one requirement talks about producing some kind of data to be used by another. An entity is a set of data, such as a database. We are not trying to build an Entity-Relationship model (I draw entity relationships outside of the main 4+1 views). Once the data set is identified it is not elaborated further in this view. An entity may be temporary or permanent data.

Some guidelines for the Robustness Diagram

This is where I would really start to split from my original description of the Logical View, and move closer to what Phillipe originally suggested. That is, an object-oriented approach. We design a set of classes that we would implement if we didn't have to worry about any of the details. We wouldn't worry about redundancy. We wouldn't worry about performance. We wouldn't worry about client/server separations that might be present in the real system. This is an idealised software-centric view of the solution.


The example I am using is of a very simple accounting system. I haven't written up formal requirements, but let us assume that the following model is based on a reasonable set. I will work though this example top-down, generally the opposite direction to the direction the model would have been constructed. The source model can be found here (gunzip before opening in StarUML).

Context Diagram

The context diagram shows the Accounts system in context with an adjacent Point Of Sale System to acquire a daily sales ledger, and a broker system to provide live stock quotes. If I were presenting this in a formal document I would re-draw it in visio. Packages would be drawn as "function" circles, and interfaces would be removed (leaving only data flows). Since we are all friends, however, I'll leave it in the model form for the purpose of this entry.

Already we can see potential gaps. We get live stock quotes from the broker's system, but no buy or sell orders. Is this intentional, and the buy/sell orders are handled entirely within the Broker System or have we missed it from our analysis?

Functions Diagram

The set of identified functions tracks these external interfaces down to a lower level. The stock quotes from that broker system are being fed into a shares investing function. Sales receives the daily sales ledgers. Inventory is a self-contained function within the system. Tax Reporting uses data from all of these functions.

It is possible that a general ledger function could appear at this level, but so far in this analysis we have not determined the need for it. The system is used for shares investing, sales and inventory tracking. Any general ledger containing the combined records of all of these activities is a design decision at this stage. Tax reporting requires that we bring the data together in some form, but whether we mine it directly or convert for easy access remains unconstrained by this logical systems engineering process.

Sales Function Robustness Diagram

The Sales function has two main controls: To import the daily sales ledger from the POS System, and to generate reports. A historical sales ledger entity naturally appears out of this interplay, and becomes the boundary between this function and the Tax Reporting function. We discover a HMI is required to request report generation. Does this HMI need to do anything else? Is printing required? If so, do we need to be able to cancel print jobs? Are these functions of the system?

Inventory Function Robustness Diagram

The Inventory Function has four controls. Two are relating to scanning stock in and out of stores. Another two are related to stock-take. Stock is re-scanned and compared against Inventory. Once all stock is scanned, the Stocktake HMI accounts for any shrinkage. Both the Inventory Scanning and Stocktake HMIs can take a number of forms. There might be keyboard and VDU entry. With any luck there will be a bar code or rfid scanner in the mix. The same scanner might be used as part of both HMIs, and both HMIs may be combined into the one end user HMI.

Shares Investing Function Robustness Diagram

Investment Tracking involves recording of purchase and sales of stocks. We can run reports based on the book value of these stocks (ie, how much we paid for them), or based on their current market value. In order to do the latter we need to keep a historical record of stock prices. Maintenance of this record has a clear entity boundary at Historical Stock Prices that makes it a candidate for separation into a new function. We still might do that if this function becomes unruly. I have placed a kind of stub interface in here for periodic execution of stock quote updates. However, this obviously needs more thought. Where is the HMI to control how often these updates occur? Can they be triggered manually?

Tax Reporting Function Robustness Diagram

I foreshadowed that the entities from other functions are referred to directly in the Tax Reporting robustness diagram, and here it is so. This does not directly imply that the Tax Reporting function has access to the databases of the other functions. It simply means that the set of information (or relevant parts of that set) is transferred to the tax reporting function at appropriate times. This could be by direct database access, by an ETL into the tax reporting function's own database, by a RESTful data exchange, or by some other means.

And this is how I would do it, now. This is a very basic diagram, but you can see that it is software centric in that it balances data with functionality, and views the world as a set of classes and objects. I would generally start with an entity-relationship or a class diagram relating to domain-specific vocabulary from the requirements specification, and work from there.

Updated Logical Diagram

To some extent I find this diagramming technique freeing. I don't have to worry about the borderline between software and systems engineering. I don't have to worry about components. I can just draw as I might have in my youth. It will feel familiar to software developers, and a software developer should be able to judge whether or not it works to convey the appropriate information.


The Logical View is somewhat airy-fairy, and the temptation is always there to introduce elements of the design. Resist this temptation and you should end up with a description that clearly separates constraints on your design and design decisions you have made. The set of interfaces your system has with other systems is a real constraint, so all of these interfaces appear here in some form and behaviour required of those interfaces is identified. You may need to round trip with the process view (and other views) in order to fully finalise this view.

It is likely that the Logical View (especially its robustness diagrams) will identify some inconsistency in vocabulary in your source requirements. It is worth putting at least a draft of the design together before finalising requirements for any development cycle.

I think that the context and function diagrams are quite useful in helping flesh out the scope of a system as part of a software architecture. The Object-Oriented nature of the real Logical View is a help to software developers, and the description of the problem domain vocabulary in this context should help stakeholders get a feel for how the system will address their problems.



Fri, 2008-May-02

4+1 View Architectural Descriptions

I have been working lately on a number of , and have been using the as part of these descriptions. This has been an interesting experience for me, because I have previously worked more in the technical sphere. These descriptions remain quite abstract, to the point that they end up exposing a level of (or perhaps just component-orientation) but do not reveal that is the architectural style used for implementation.

The 4+1 style was originally proposed by Philippe Kruchten of Rational (and later IBM) fame. 4+1 is consistent with IEEE 1471's advice that architectural descriptions be broken up into multiple views. The principle is that it is impractical and confusing to use one diagramming technique or one style of description in summarising an architecture. Multiple views are required to meet the needs of different stakeholders.

Philippe's 4+1 main views are:


These views all typically describe static arrangements of elements. The +1 view is Scenarios, allowing for the demonstration of example modes or uses of the architecture in a more dynamic view. The Logical View is all about requirements analysis. This is the view for exploring and expanding on this design's requirements baseline. The other views provide a narrative that relates this requirements analysis to the final design, and views that design from a number of different perspectives.

The main goal of my architectural descriptions has been to come up with a well-formed list of components and interfaces for further expansion in other documents. In my case components are either configuration data, libraries, or application software. Interfaces could be internal, external, or human/machine. To this end, I have defined a set of components across the design views to show how they appear in terms of their runtime, build-time, and deployment-time relationships. I have used the functional decomposition of the Logical View to guide and partition the design through the other views.

The Logical View covers the functional requirements of the system, and is closely related to the approach of Systems Engineers to the problem of design. The Process View is intended to show how threading and multiplicity work to achieve non-functional requirements. I use this view as the "main" design, showing run-time relationships. Build-time relationships appear in the development view, and essentially model the Configuration Management environment in which the software is developed. I have used the final Deployment View to plan how components are packaged up for deployment onto particular classes of machine. This view can also be used to show a final (but abstract) view of how target hardware is connected together in service.

There isn't a great deal of information on 4+1 out there on the Web, so I plan to produce a series of articles covering the different views and diagramming techniques I have personally been employing. I have adapted 4+1 slightly to my own needs, and where I have knowingly done this I will attempt to distinguish between the "real" 4+1 and my own tweaks.