Using a System and Software Architecture Framework, Views, and Patterns

1
Using a System and Software Architecture
Framework, Views, and Patterns

• Robert Dean
• 4/27/2007
• Spring 07 CS 577b
• rdean_at_usc.edu
• robert.s.dean_at_boeing.com

2
Overview

• IEEE 1471
• Dimensions of Concerns
• SW Patterns Systems Heuristics Related
• Model Space Transformations
• Frameworks and Trajectories of Decomposition
• Department of Defense Architecture Framework
  (DODAF)
• DODAF Trajectories
• Zachman Framework
• Kruchten 41
• Decomposition Trajectory through the SE Pyramid

3
IEEE 1471 Conceptual Framework

• System Boundary SV-1 Context Diagram
• System Supports one or more missions
• Need to Trade Off One or More Instances of an
  Architecture
• See Architecture Trade Off Analysis Method (ATAM)
  Ref 2
• Stakeholders have Concerns
• Low Dimensional Concerns
• E.g. Classes and Relationships
• Entity Attribute Relationship (EAR) diagrams,
• N2 Diagrams (Normal Form Used to find the
  minimal spanning set of Interfaces, both
  functional flow data flow forms)
• High Dimensional Concerns
• E.g. Security

• Source Ref. 1

4
Example Atomic Dimensions of Concerns

• Key Steps to determine the correct views in a
  framework
• Determine the dimensions of your stakeholders
  concerns the opposing design forces in tension
• Choose the Correct Diagram or Language that can
  be used to describe the concerns. e.g.
  Association, Activity, etc.
• For Each Level of System Decomposition, Choose a
  minimal spanning set of views that allows
  application of design patterns to resolve the
  design forces
• Looking for the Eigenvectors that can be used to
  form a Basis to easily solve your problem space

5
SW Patterns Systems Heuristics Related
Good Designs have High Pattern Density, Frank
Buschman, OOPLSA 2002 i.e. Overlay Patterns
until All Design Forces Resolved SW Architecture
Style High Level Pattern e.g. Broker Pattern
exists in the OO SW Architecture Style Broker
Pattern not required in a SW message bus style.
E.g. HPs Softbench uses message bus
style Continue to Add/Overlay Patterns until
all design forces are resolved.
Concerns from IEEE 1471
UML Drawing Based on a Synthesis of Ref. 6,7,8,9
6
Model Space Transformations

• Operational (O), Logical (L), and Physical (P)
  viewspaces (for view spaces, See Ref. 2)
• OFo() ? LFl() ? PFp()
• OFo() ? PFp()
• Operational Functions are Missions, Tasks and
  Subtasks
• Operational Structures are Organizations and
  Individuals
• Technology Independent Model (TIM)
• Logical Functions are Conceptual System Functions
  not allocated to any physical hardware and
  software elements
• Logical Structures are Logical System interfaces
  (typically become realized in S/W APIs in a
  layered SW architecture in the physical structure
  if the physical and logical partitions line up)
• Technology Specific Model (TSM)
• Physical functions are Physical System Functions
  allocated to measurable hardware and software
  elements.
• Physical Structures are the physical interfaces
  between components at where physical functions
  are measured.

7
Department of Defense Architecture Framework
(DODAF)

• Originally Called Command, Control, Computers,
  communications, Intelligence, surveillance,
  Reconnaissance (C4ISR)Architecture Framework
• Mainly Supported Interoperability
• Views
• All View (AV)
• Operational View (OV)
• Systems View (SV)
• Technical Standards View (TV)
• Ref. 3

8
Zachman Architecture Framework Ref. 5.
Note Can Be Mapped to DODAF Views, Zachman
covers more viewspace than DODAF
Items (what)
Behavior (how)
Network (where)
WMI (who)
Performance (when how well)
Context (why)
Concept of Operations
Operational Arch OO
OV
System Engineering
You Architect in a Medium Architecting
Business Logic only Logical Architectures Do not
obey the laws of physics
System Designer
SV (Logical)
SV (Physical)
Architecting Hardware and Software with Physical
Constraints
System Implementor
System Integator
Info, Software, Network Engineering
Operational User
9
The Zachman Frame Also has Depth for Levels of
Decomposition

• High Level Coarse to Fine Grained Detailed
• Operations
• Logic
• Physical Implementation

• High Level Coarse to Fine Grained Detailed
• Organizations
• Logical Components
• HW and SW Components

Conceptual
Key Question for Your Project What is your
Trajectory of Decomposition
Operational
Logical System
Platforms
Level 1
Platform SubSystems
Level 2
Level 3
Level 4
Platform SubSubSystems
Level 5
Physical Levels
10
The Krutchten Four Plus One Ref. 4with
Requirements Trajectory
Logical Requirements Virtual Stimulus Response
in High Level Spec Verified by Simulation and
Analysis of Rolled Up Physical Data
Note Flavors of Use Cases Org X Org UC If the
swimlanes are people and organization it is how
one organization uses another Org X Sys UC How a
person uses the System. Primary System Functions
at the System Boundary (Context Diagram) Sys X
Sys UC How the system uses it self, e.g. N2
and Association Diagrams
Logical View
Implementation View
Use Case View
Process View
Deployment View
Measurable Physical Stimulus / Response
11
The Trajectory through the SE Pyramid
Logical Requirements
41 Can Occur at Each Level of Decomposition
Logical System Level Virtual Stimulus Response
in High Level Spec Verified by Simulation and
Analysis of Rolled Up Physical Data
System Level
Spec Management Only Parse Logical into Physical
as required to expose measurement points at each
level
Segment Level
Sub-System Level
Physical / Measurable Requirements
Engineering Level
12
Summary

• IEEE 1471
• Dimensions of Concerns
• SW Patterns Systems Heuristics Related
• Model Space Transformations
• Frameworks and Trajectories of Decomposition
• Department of Defense Architecture Framework
  (DODAF)
• DODAF Trajectories
• Zachman Framework
• Kruchten 41
• Decomposition Trajectory through the SE Pyramid

13
References

• IEEE-Std-1471-2000 Recommended Practice for
  Architectural Description of Software-Intensive
  Systems, Rich Hilliard, Nov, 2000,
  http//www.enterprise-architecture.info/Images/Doc
  uments/IEEE201471-2000.pdf
• Evaluating Software Architectures Methods and
  Case Studies, Paul Clements, et. al., Addison
  Wesley Professional, 2002
• http//en.wikipedia.org/wiki/DODAF
• Architectural Blueprints - the 41 View Model of
  Software Architecture, Philippe Kruchten,
  Rational Software Corp, http//www3.software.ibm.c
  om/ibmdl/pub/software/rational/web/whitepapers/200
  3/Pbk4p1.pdf
• Zachman Framework http//www.zifa.com
• The Art of Systems Architecting, Mark W. Maier
  and Eberhardt Rechtin, CRC Press, 2002.
• Systems Architecting Creating and Building
  Complex Systems, Eberhardt Rechtin,
  Prentice-Hall, 1991.
• Pattern-Oriented Software Architecture (POSA
  I), Frank Buschmann et. al., John Wiley Sons,
  1996.
• Pattern-Oriented Software Architecture, Vol. 2,
  Patterns for Concurrent and Networked Objects,
  Doug Schmidt et al, 2000