Architectural Blueprints

1
Architectural Blueprints The 41 View Model
of software Architecture from IEEE Software
(November 1995)

• By Philippe Kruchten
• Rational Software

2
General Concept of Software Architecture

• Software Architecture deals with
• design and
• implementation
• of the high level structure of software.
• Software Architecture is the result of
• assembling a number of architectural elements
• in some well chosen form
• to satisfy major functionality as well as
  non-functional requirements

From Perry Wolfe Software Architecture
Elements, Form, Rationale/Constraints
3
An Architectural Model

• Kruchten Proposes a Model composed of 5 Views
• Logical View
• Process View
• Physical View
• Development View

5. Scenario or Use Case
4
In Describing Each of the 5 Views, Kruchten uses
a Common Methodology

• The Notations that will be used for the view is
  defined
• Elements to express components, containers,
  connectors
• Form to express pattern that worked
• Rationale/Constraints to express some
  requirements to be satisfied
• For each view also show
• An example of blueprint, with the views
  notation
• The architectural styles that may be utilized for
  that view

5
Logical Architecture (View)

• Logical view primarily describes the services
  provided to the users. The system is decomposed
  into key abstractions (e.g. classes) that
  describe the functional requirements.
• May include the identification of common
  components across the system.
• Uses OO Approach Class Diagrams, which shows
• i) Classes and
• ii) the Relationships (inheritance, composition,
  usage, etc.) among Classes
• Alternative to OO, may use E-R diagrams for data
  driven systems

6
Logical Architecture (View)

• Notation used for the OO approach of Logical
  View is derived from Booch and include
• A) Components --- Class Class Utility
  Parameterized Class Class Category
• B) Connectors --- Association Containment
  Aggregation Usage Inheritance Instantiation
• Style
• Object Oriented Style
• A Logical Blueprint
• Some pictorial representation, using Booch
  Notation, of the logical view of a design.

class
usage
inheritance
7
Process Architecture (View)

• Process view primarily describes the
  non-functional aspects of the requirements and
  execution control such as the performance or
  integrity and addresses issues such as
  concurrency or distribution
• Describes the thread of control of an operation
  of how a process (i.e. set of tasks) is executed.
  
• Process is a set of tasks that form an executable
  unit which can be started, controlled,
  terminated, etc.)
• A task is a thread of control that can be
  individually scheduled on one processing node
• Tasks also communicate via some well defined
  mechanism
• Process i) loads and ii) flow of messages can be
  estimated via studying a blueprint of process
  view.

8
Process Architecture (View)

• Notation used for Process View is derived from
  Boochs proposal for Ada tasking and includes
• A) Components --- Process Simplified Process
  Periodic Process adornment
• B) Connectors ---- Unspecified Message
  (unidirectional and bidirectional) Remote
  Procedure Call Event Broadcast
• Style (several may be used)
• Pipe and filter, client server
• Process Blueprint
• Some diagram, using the defined notation, to
  depict the flow of messages from process to
  process.

message
message
process
simplified process
RPC
9
Development Architecture (View)

• Development view focuses on the software module
  organization as they are packaged into small
  units of subsystems or libraries that can be
  developed by a small unit of developers.
• Subsystems are organized in a hierarchy of layers
• The rules that govern the development
  architecture may include partitioning grouping
  visibility
• Takes into account of the internal requirements
  related to development, project management,
  re-use, toolset constraints, development platform
  and language constraints, etc.

10
Development Architecture (View)

• Notation used for development view is again
  derived from Booch
• Components ---- Module Subsystem Layer
• Connectors ---- References Compilation
  Dependency
• Style
• Layered (4 to 6 layers)
• Development Blueprint
• Some diagram depicting the layers of a software
  system that matches the logical view of the same
  system. Contained within each layer are several
  subsystems, which in turn may contain several
  modules.

layer
subsystem
module
reference
11
Physical Architecture (View)

• Physical view focuses on the non-functional
  requirements of the hardware system on top of
  which the software resides.
• The various elements identified are parts of the
  physical configuration needed to run the software
• These may include nodes, processors, devices,
  lines, etc.
• The configurations may be for development
  purpose, for testing purpose, deployment purpose,
  etc.

12
Physical Architecture (View)

• Notations used are pretty much box and line
• Components --- processors devices
• Connectors --- communication lines high
  bandwidth bus
• Style
• There is no specific style except possibly
  hierarchical
• Physical Blueprint
• Diagram depicting the process architecture mapped
  onto the physical architecture.

processor
comm. line
high bandwidth communications
device
13
My Comments

• It is good to realize that architectural design
  is a result of considering many different
  perspectives. Clearly, we need to somehow
  combine these differing views into one cohesive
  architecture ---- or do we?
• Also, do we always need the logical, process,
  development, and physical views?
• Do we need more? ---- how about Data View?
• Can we do with less?

14
Use Scenarios to Converge and Test the Views

• Come up with scenarios of most important or
  most frequently encountered use cases and run
  through the different views.
• Note that Logical views describes the
  components, and Process view describes the
  execution control and synchronization. So use
  the scenarios to converge (map) the Logical and
  Process Views together so that we can
• Discover if we defined all the needed
  components
• Discover if the components can interact in the
  expected manner

Thus the major scenarios form the 5th View or
the 41 Views!
15
Mapping the Views is Hard

• Do all the views have to be carried to the same
  level of depth before we can map them together?
• How do we map the views?
• Logical View to Process view
• Basically this is looking at the objects or
  components and asking how the execution path
  will look like.
• So we need to know the characteristics of these
  objects or components Autonomy Persistence
  Subordination Distribution
• We need to know the execution thread of control
  in the process view inside-out locus of control
  outside in locus of control
• Logical View to Development View
• Looking at implementing a class as a module and
  packaging modules together. Should the modules be
  implemented and packaged in a specific pattern
  such as layered?
• Process View to Physical View
• Looking at the processing or execution control,
  we may choose to deploy different processes on
  different hardware nodes.

16
Iterative Approach to Designing an Architecture

• The phases of (sketching, organizing, specifying,
  and Optimizing) architecting should not be a
  linear, single pass approach --- a more iterative
  scenario driven approach should be taken
• Start with a number of main scenarios and run
  them through the strawman architecture.
• The architectural elements discovered through
  this scenario driven approach is documented via
  logical, process, development, and physical
  views.
• Use more scenarios to iterate through the views
  and capture the architecture (including the
  rationale part) until satisfied ----

17
The Architecture must be Documented

• Architectural Document should include (my
  version)
• Architectural goals constraints
• Software Architectural Views
• Logical Views (representing user functionalities)
• Process views (representing system execution )
• Development Views (representing implementation
  breakdown )
• Physical Views (representing deployment/hardware
  assignments)
• Data view (representing the key files and tables)
• Scenarios
• Rationale
• Software Architecture (combined all the views and
  rationale) elements, forms, rationale

The author includes more such as change
history, scope, references, performance size,
quality, etc.
18
My Further Comments

• Addressing multiple Views make sense.
• Seems that Data view should be included as one of
  the required and Development View may be an
  option.
• The hardest part of moving forward with multiple
  views is how do you combine them
• The views must be at the same level of depth
• The views must not have any conflicting
  information
• The views must be clearly expressed in languages
  that allows combination into a software
  architectural representation language.