Architectural Blueprints - The "4+1" View

It is unfortunate this paper was written by a single person. He could have really used an editor to proofread his paper and look for missing or misspelled words. There were multiple I had to break the flow of reading in order go back and figure out what point he was attempting to express.

The author presents the theory of not being able to clearly and efficiently present all necessary information about a system in a single diagram. Duh! Unless the "system" has two classes and less than 500 SLOC, you might be referring to a script in this case.

In order to describe a software architecture, a model composed of views or perspectives is presented:

• logical view, object model of the design
  
• process view, captures the concurrency and synchronization aspects of the design
  
• physical view, describes mapping(s) of software onto hardware and distributed aspect
  
• development view, describes organization of the software in the development environment
  
• scenarios (use cases)

Not all views are required for every architecture. For example, it may not make sense to create a physical view if there is only one processor. Maybe you do not need a development view if you created a single class with over 50 methods and 10 KSLOC. (You have other problems.)

Perhaps it is the case of SEI-CMM and DODAF being spoon fed to me over the last 10+ years, but I see nothing overly exciting about the author's presentation of creating views to describe the architecture. Any right-minded development program should have at least some documentation laying out decisions that have been regarding the system development and design. Even agile development produces some amount of design documentation.

Since this paper was written by an associate of Rational, I am not sure if the intended audience included your 2-man development teams running out a garage. A little upfront design should be done by all.