Transcript System Requirements Review (SRR) Agenda - a\|EA-DC

Applicability of Patterns to
Architecting Complex Systems
Rob Cloutier, Ph.D.
March 14, 2007
7/20/2015
©Robert Cloutier, 2007
1
Abstract
The best software programmers have used
patterns for over a decade. Have you thought
about mining your enterprise architecture for
patterns that can be used? Here is an
approach to capturing and using system
architecture patterns in complex systems.
7/20/2015
©Robert Cloutier, 2007
2
What Constitutes a
Pattern?
Some patterns seem self evident,
but have actually matured out of
experience…
Simple at first…
They are the result of
trial and error, but
survive the test of time.
And maybe they
become more complex
Patterns are Reusable Successes
7/20/2015
©Robert Cloutier, 2007
3
The pattern
concept is
simple,
…the effect
is Powerful
7/20/2015
©Robert Cloutier, 2007
4
Patterns In Use by Multiple
Disciplines
Requirements Engineering
Control Systems Engineering
http://g.oswego.edu/dl/acs/acs/acs.html
IBM e-Business Pattern Hierarchy
7/20/2015
©Robert Cloutier, 2007
5
The Value of Patterns for Systems
Architects
Some Considerations
•
•
Knowledge Management
–
Architectural patterns may help control the complexity of an architecture by
standardizing it on a well known and practiced pattern
Common Understanding
–
•
Enable reuse of good concepts and implementations, and to preserve them for future
projects
Control Complexity
–
•
of their business… Why? We can trace availability and fault tolerance to patterns, and
we have extracted those patterns from the minds of long-standing experts.” [Cop97]
Capture Good Architecture Concepts
–
•
“… mining the patterns of classic embedded systems to capture the core competencies
Describe parts of the designs and implementations in the context of known and
understood patterns may foster a common understanding of the architecture
Mitigate Risks
–
7/20/2015
Using and applying known patterns in architecture and design introduce less risk than a
new architecture design
©Robert Cloutier, 2007
6
Architecture Patterns Definition
System architecture patterns constitute high-level
structures, appropriate to the design of the major
components of a system. They express the relation
between the context, a problem, and a solution,
documenting attributes and usage guidance. They are
time-proven in solving problems similar in nature to
the problem under consideration.
7/20/2015
©Robert Cloutier, 2007
7
A Systems Engineering Pattern Form
Pattern Name
Aliases
Keywords
Problem Context
Problem Description
Forces
Pattern Solution
Sketch
Interfaces
Resulting Context
Example
Pattern Rationale
Known Uses
Related Patterns
References
Authors
7/20/2015
The name of the pattern should be descriptive to enable the pattern user to understand the usage
Other names by which the pattern may be known
Keywords which assist in locating appropriate patterns when needed
Brief discussion of the constraints the pattern may impose
What is the problem this pattern can be used to solve
Challenges that exist in the problem being addressed by the pattern, and the problems in applying
the pattern
Discussion on how the pattern solves the problem being addressed
This can be one or more diagrams necessary to represent the pattern
Discussion of the critical interfaces or information flows necessary in implementing the pattern
What are the unaddressed issues remaining when the pattern is applied/used
An example of how the pattern may be applied
Why the pattern works
Where else is the pattern being used in other places or applications
Other patterns what may work in conjunction or in association with this pattern
Other information that may be useful in understanding or applying the pattern
Who documented the pattern
©Robert Cloutier, 2007
8
Documenting the Perform C2 Pattern Using the SE Pattern Form
Pattern Name:
Perform C2, Perform Command and Control
Aliases:
None known
Keywords:
Command and control, Plan, Detect, Control, Act, C2.
Problem Context:
Does not address “Prepare” precondition (though one might argue that prepare and plan go
together) nor “Assess” post condition
Problem Description:
In command and control (C2), the situation is typically managed in identifiable phases. And, the
situation may move back and forth between the stages. Those stages are
Plan/Detect/Control/Act
Forces:
Terminology may vary from one domain to the next, and should be adapted in the application of
the pattern
Pattern Solution:
This pattern provides the basis for developing the command and control (C2) interfaces and
information that moves through the stages of C2. It provides the A0 Context and the first
level of decomposition using IDEF0.
Model:
See next page
Interfaces:
Information flows between the stages of this pattern, as well as feedback loops. Some information
is generated only in a particular stage and then output in the form of reports. Names of
information can be modified as required by specific domain application.
Resulting Context:
Further work is required to define the tasks to be performed within each stage, and the allocation
of tasks to systems, hardware, software or people.
Example:
This pattern may be used in the modeling of a C2 system for military or paramilitary operations
system (such as police or homeland defense) where there would be a planning phase, a
detection of an situation or “bad guy”, an identification and controlling or managing of the
information, and a required action to perform the mission. May even be extended to motor
vehicle fleet operations.
Known Uses:
Command and Control applications
Related patterns:
OODA (Observe, Orient, Decide, Act)
References:
MCDP 6 Marine Corps Command and Control Handbook
Pattern Rationale:
This is a time tested doctrine used by the military, that may be applicable to other domains
7/20/2015
Author(s):
Cloutier, 2007
Harry Johnson Ph.D., Ken ©Robert
Hartnett,
Satya Moorthy, Robert Cloutier, 2006.
9
Perform C2 A-0 Diagram
Doctrine
External Guidance
Strategy
0
A ssessment (BDA )
C oordination Data
Mission A ssessment
Mission Status
Mission Support Requests
O rders
Plans
Raw Intel
Reports
Req for Information
Resource A ssignments
Sensor Data
Situational Data
Task ing
Tracks/Targets of Interest
External Data
Perform C 2 (Pattern)
Environmental Data
Resources
Date:
A uthor:
Tuesday , January 17, 2006
Number:
7/20/2015
0
©Robert Cloutier, 2007
Name:
Robert J. C loutier
Perform C 2 (Pattern)
10
Doctrine
External Guidance
Strategy
1
Planning Reports
Reports
Req for Information
Raw Intel
Environmental Data
A nalysis
Intel Products
Mission Requirements
Task ing
O rders
Plans
Resource A ssignments
External Data
Plan
(O perations)
Task ing
O rders
Plans
Resource A ssignments
1
2
Sensor Data
S&D Reports
Detect
(Surveillance &
Tracking)
Tracks/Targets of Interest
Tracks/Targets of Interest
Sensor Av ailability
Situational Data
Situational Data
2
3
Perform
C2 A0
Diagram
C 2 Reports
C oordination Data
C ontrol
(Classification
& Identification)
C oordination Data
Immediate Tasking
Situational Data
C 2 Resource A v ailability
Mission Support Requests
Mission Support Requests
3
4
Engagement Report
A ct
(Execute/
Prosecute
Mission)
Mission Status
A ...
Mission A ssessment
Mission A ssessment
Mission Support Requests
4
7/20/2015
©Robert Cloutier, 2007
11
Resources
Conclusions That May be Drawn
from Perform C2 Pattern
• The Plan/Detect/Control/Engage workflow for command and
control (C2) can be documented as a pattern
• Sufficient detail can be captured in the pattern to enable an
architect less familiar with the process to begin architecting a
solution to a new instance of the C2 problem
• As one “drills down” in documenting a complex pattern, a level of
detail is reached whereupon the necessary detail begins to
obfuscate the value of pattern abstraction.
– This is the point in which no further data should be added to the
pattern
• Some systems architecture patterns may actually be a pattern
language
7/20/2015
©Robert Cloutier, 2007
12
Pattern Topology
Zachman Framework
Views
Scope
(Contextual)
Pattern Types
Organization Patterns
Structural
Enterprise Model
(Conceptual)
Mission Patterns
SystemArch Patterns
Structural
SysEngRoles
SystemAnalysisPatterns
System Model
(Logical)
Business Patterns
SW Arch Patterns
SystemRqmnt
SEActivity
SystemDesignPatterns
SW Analysis Patterns
SystemProcess
SystemTestPatterns
HW Rqmnt Patterns
Operational Patterns
HW Design Patterns
SW Rqmnt Patterns
SW Design Patterns
SW Test Patterns
Technology Model
(Physical)
Creational Patterns
Detailed
Representations
7/20/2015
Structural Patterns
Behavioral Patterns
Implementation
©Robert Cloutier, 2007
13
Potential Portfolio for Future Research on
Systems Architecture Patterns
1. Is there a way to parameterize the parts of
an architecture pattern to help at the
interfaces?
2. Can architecture patterns assist in the
transition from logical design to physical
design
3. Are there domain specific patterns, or are
they generic?
4. Are reference architectures a type of
systems pattern?
5. Can patterns help manage or reduce risk
while architecting or designing a system?
6. Is there one phase in the product
development lifecycle in which patterns
offer the greatest payback in terms of
risk?
7. Can the Empirical Assessment of
Completeness Metrics be extended to
more accurately predict systems
architecture quality (and the value of
patterns to systems architecture quality)?
7/20/2015
8. Does an architect working for a company
that develops large, complex system of
systems projects like national air traffic
control systems or weapons systems find
it more natural to use patterns than an
architect developing smaller systems?
9. Is it possible for an automated tool to
truly assess characteristics like
maintainability or understandability in
terms of the intellectual complexity of the
concept?
10. Do biological patterns offer any insights
to architectural the use of patterns in
complex systems architecting?
11. Can agent based technologies be
improved upon with the use of systems
pattern?
12. Is there a combination of indicators that
can be assessed to conclusively
demonstrate the value of pattern usage in
systems architecture?
13. Does a complex system represented in
UML has the same quality attributes as a
software intensive system?
©Robert Cloutier, 2007
14
Robert Cloutier is an Associate Research Professor
at Stevens Institute of Technology, in the Systems
Engineering and Engineering Management
department. Prior to that, he was a Systems
Architect/ Principal Systems Engineer with the
Lockheed Martin Corporation. With over years
experience in systems engineering, software
engineering, information technology, and project
management in both commercial and defense
industries, he brings unique perspectives to the
engineering field.
Rob also has an M.B.A. from Eastern College,
and a B.S. from the United States Naval Academy.
He is a member of the International Council on
Systems Engineering (INCOSE) and active in the
Delaware Valley Chapter, an active member of the
Association of Enterprise Architects, and is a
member of IEEE. Rob also chairs the Rowan
University Electrical and Computer Engineering
Department Industry Advisory Board.
7/20/2015
©Robert Cloutier, 2007
15