The “4+1” View Model of Software Architecture

I definitely took away some useful things from this paper. There was no spot where I had a eureka moment or found something brilliant. Rather, I found it wonderful how the paper was able to take what are easy to understand ideas and get them into an algorithm to follow. There have been many times on my projects that a component or process in the system has seemed so obvious that explicit analysis or documentation was not required. However, more often than not, these simple things will lead to complications down the road when new people work on the component and/or as the application grows in complexity.

Another obvious idea that benefits from explicit analysis breaking architecture down to components, containers, & connectors and also, later in the paper, partitioning, grouping, & visibility. All are very simple concepts everyone understands, but if you take a moment to sketch or analyze the system from those perspectives, as well as the 4+1, it can help bring obvious design flaws to light.

The paper mentioned that the logical architecture should be used to work with business stakeholders to analyze functional requirements. However, I feel that the diagrams presented here, where the fine-grain detail only goes down to the class level, may not be enough to help verify that all functionality has been implemented. The public API of each class should be listed, or each method should have a summary phrase. That would help the discussion with business stakeholders when you need to explain what each component/class is responsible for.

I liked the "+1" idea of walking through various use case-like scenarios to check the consistency & validity of the four other views. Another obvious yet great thing to explicitly do.

I will definitely be keeping this paper in mind on future projects, though, as the paper mentions, not all projects need all 4+1 views.