Static, Runtime, Physical

For the spring 2008 semester I function as a distance education instructor for the Principles of Software Architectures course offered by the School of Computer Science at the Carnegie Mellon University through the Institute for Software Research International. As I reviewed the course I fondly remembered the lectures by Prof. David Garlan and Tony Lattanze while pursuing my Masters in Software Engineering (IT) degree some years ago. At the same time I reflected on the architecture representation practices employed on some of the recent projects I’ve reviewed and sadly the state of affairs is looking pretty grim.

It is still common to see software architecture designs mix incongruent design elements together, such as combining message flow process with a class diagram. As a gentle reminder, architecture of a software system is represented through a number of views that describe some angle of a system. There are many different views that can be chosen by an architect to represent some aspect of the system (e.g. process view, deployment view, decomposition view, etc.). No matter what view an architect chooses to document some aspect of architecture it’s critical to understand that most views can be classified into static, runtime, and physical. It is absolutely critical to maintain conceptual integrity of a given view; otherwise you may be comparing apples to oranges. If this is new to you read a copy of Software Architecture in Practice, Second Edition, take this course from Carnegie Mellon, or take a class from the Software Engineering Institute.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Comments

The Architect said…
I couldn't agree with you more! Although there are the 4+1 views etc, I have found that the static, dynamic/runtime and physical views typically communicate what I need to. I typically also include a conceptual data model just to translate business requirements and ensure that all parties agree on the very high level relationships across the system. I found that it goes a long way in establishing a baseline and also sparks ideas in customers minds.

Popular posts from this blog

Why we do agile

Quality Attribute Refinement