by ivo krka in collaboration with doug bodner, nenad medvidovic, barry boehm, jo ann lane, bill...
TRANSCRIPT
ByIvo Krka
In Collaboration with Doug Bodner, Nenad Medvidovic, Barry Boehm, Jo Ann Lane, Bill Rouse, George Edwards, Nupul Kukreja, and Daniel Popescu
Annual Research ReviewCenter for Systems and Software Engineering
University of Southern CaliforniaMarch 7, 2012
Requirements and Architectures forSystem-of-Systems Integration
Problem Space
• Net-centric enterprises engage semi-autonomous business units, each with its own set of requirements
• These units often need to collaborate using their IT systems, involving integration or merging―Temporary vs. permanent integration―Horizontal vs. vertical integration―Data vs. control integration―Desired non-functional properties (e.g., scalability, reliability)
Desired Solution
• Decompose integration requirements into architectures
• Provide support for traceability
• Provide support for multiple stakeholders involved in net-centric integration
Candidate Netcentric
SoS Requirement
s
Candidate Netcentric
SoS Architectu
re
Decision Drivers:• Type• Orientation• Information access• Platforms and technology
Refinem
ent
Key Decisions:• Integration style• Buy/reuse/build• Adaptation and
extension mechanisms
Jail Information Management System
• Provides data consistency and availability at seven San Diego County detention centers
• Interoperates with multiple external systems (Regional Area Crisis Response SoS)
• Security, privacy, performance, reliability & availability requirements
• Reasons for selection―Availability of requirements and data―Diverse issues and challenges
(multiple systems, COTS, vertical and horizontal, transient and permanent integration, etc.)
Figure 6. JIMS Top Level System View (SV-1) – Internodal Node Interfaces.
San DiegoCentral Jail Node
Booking Jail SiteConfiguration
South Bay Detention Facility Node
Descanso Detention Facility Node
George Bailey Detention Facility Node
Las Colinas Detention Facility Node
Vista Detention Facility Node
Data Services Division (DSD) Node
Booking Jail SiteConfiguration
Booking Jail SiteConfiguration
Booking Jail SiteConfiguration
Non-Booking Jail Site Configuration
Non-Booking Jail Site Configuration
DSD SiteConfiguration EXTERNAL
CONNECTION
All internodal interfaces except the external connection are identical…
Figure 6. JIMS Top Level System View (SV-1) – Internodal Node Interfaces.
San DiegoCentral Jail Node
Booking Jail SiteConfiguration
South Bay Detention Facility Node
Descanso Detention Facility Node
George Bailey Detention Facility Node
Las Colinas Detention Facility Node
Vista Detention Facility Node
Data Services Division (DSD) Node
Booking Jail SiteConfiguration
Booking Jail SiteConfiguration
Booking Jail SiteConfiguration
Non-Booking Jail Site Configuration
Non-Booking Jail Site Configuration
DSD SiteConfiguration EXTERNAL
CONNECTION
All internodal interfaces except the external connection are identical…
Requirements to Architectures
• iCBSP―Proposed method for refining
integration requirements into an integration architecture
―Augmented version of CBSP method―Strong traceability from architecture
to requirements
• Process of use―Pre-step: filter requirements for
integration―Step 1: stakeholders rate importance
and feasibility―Step 2: architects rate architectural
relevance―Step 3: architects negotiate and
reconcile disagreements―Step 4: requirements rephrased and
traced to proto-architecture―Step 5: integration architectural
solution selected and applied to proto-architecture
• Effective requirements filtering
• Identified integration architecture elements―16 processing component elements―16 bus elements―11 data component elements
• Traceability from NL requirements to architectural elements―Over 100 traces in the final model
Experience With iCBSP
Deriving Architectures from Requirements using Social Networking
• iCBSP Characteristics―Human intensive with both non-
technical and technical stakeholder involvement
―Requirements filtered in each step and finally rewritten to be made more precise
―The stakeholders negotiate and reconcile their views of the importance/feasibility/architectural relevance of the individual requirements
• Winbook―Social networking tool originally
targeted for WinWin requirements negotiation
―Easy to use by different stakeholders―Filtering requirements based on
various criteria―Supports color-coding, tagging,
highlighting, commenting, etc.
iCBSP in Winbook
iCBSP in Winbook
Classifying and Selecting Integration Solutions With Integration Matrices
• A simple and straightforward knowledge capture method
• Alternative or recurring design decisions across the columns―Patterns, styles, data management solutions, COTS product combinations
• Desired system properties along the rows―Quality goals and NFPs, desired capabilities and features
• Cells capture compatibilities, conflicts, or other relationships―A concise symbol (+/-) or rank (1-10) with a link to a textual explanation
• Using an integration matrix―Quickly “drill down” on a small set of potentially beneficial design options―Identify potential issues and alternative solutions early in the process
Integration Styles and Properties
• Style guides the composition of elements into an architecture
• Multiple styles may be used in a system or SoS
• Different styles result in different system qualities
• Integration Style =o Connector Roles + Topology + Linkage
Mechanisms
―Connectorso Adaptor, arbitrator, distributor, etc.
―Topologieso Point-to-point, hub and spoke, shared
bus, etc.
―Linkageo Shared data, messaging, screen-
scraping, etc.
―Examples:o SOA = distributor, shared bus,
messagingo Federated DB = arbitrator, hub and
spoke, shared data
Integration Matrix
Integration styles vs. Properties
Topology Linkage Connector
Point-to-Point
Hub and Spoke
Shared Bus
Peer-to-Peer
Shared Data
Messaging Explicit invocation
Data Streaming
Adapter Translator Arbitrator Distributor
Interaction
Distributed o + + + o + + + o o + +Local o - + - + o + + o o o -Secure + - o +/- - o o o o o + -Data intensive + - - + + - o + o - + +Data formats incompatible
o + o - - + o o o + o o
Data consistency o + o - + o o - o o + oInteraction protocols incompatible
o + o - + o - o + o o o
Reliable + - + + - + + o o o + oReal time + - +/- - + - + + o o + oOne-to-many - + + + +/- + - + o o + +Many-to-one - + o +/- o + - o o o + +Always available + - o + - + o o o o + oPeriodically scheduled
+ o o - o o o o o o + o
System
Loose coupling - + + +/- - + - - + + + +Robustness - - + + - + +/- - o o + +Dynamically reconfigurable
- o + + o + + o + + + o
Scalable - - + + - + o o o o + +Caching - + + o + o - - o - + +Distributed transactions
- + + +/- + + + o o o + +
Obvious advantages and disadvantages
Hub becomes a bottleneckShared data
repositories are difficult to scale
Integration Matrix Application
Integration styles vs. Properties
Topology Linkage Connector
Point-to-Point
Hub and Spoke
Shared Bus Peer-to-Peer
Shared Data
Messaging Explicit invocation
Data Streaming
Adapter Translator Arbitrator Distributor
Distributed o + + + o + + + o o + +
Secure + - o +/- - o o o o o + -
Data intensive + - - + - - o + o - + +
Data consistency o + o - + o o - o o + o
Reliable + - + + - + + o o o + o
Real time + - +/- - + - + + o o + o
Robustness - - + + - + +/- - o o + +
Distributed transactions
- + + +/- + + + o o o + +
Positive (+) 4 3 4 4 3 4 4 3 0 0 8 4
Neutral (o) 2 0 2 0 1 2 3 3 8 7 0 3
Negative (-) 2 5 1 2 4 2 0 2 0 1 0 1
Positive / Negative (+/-)
0 0 1 2 0 0 1 0 0 0 0 0Integration-specific properties
of interest
Summary of outcomes
Decision Support Example
Integration styles vs. Properties
Topology Linkage Connector
Point-to-Point
Hub and Spoke
Shared Bus Peer-to-Peer
Shared Data
Messaging Explicit invocation
Data Streaming
Adapter Translator Arbitrator Distributor
Distributed o + + + o + + + o o + +
Secure + - o +/- - o o o o o + -
Data intensive + - - + - - o + o - + +
Data consistency o + o - + o o - o o + o
Reliable + - + + - + + o o o + o
Real time + - +/- - + - + + o o + o
Robustness - - + + - + +/- - o o + +
Distributed transactions
- + + +/- + + + o o o + +
Positive (+) 4 3 4 4 3 4 4 3 0 0 8 4
Neutral (o) 2 0 2 0 1 2 3 3 8 7 0 3
Negative (-) 2 5 1 2 4 2 0 2 0 1 0 1
Positive / Negative (+/-)
0 0 1 2 0 0 1 0 0 0 0 0Adapters and translators are not needed as the interfaces
are homogenous
Decision Support Example
Integration styles vs. Properties
Topology Linkage Connector
Point-to-Point
Hub and Spoke
Shared Bus Peer-to-Peer
Shared Data
Messaging Explicit invocation
Data Streaming
Adapter Translator Arbitrator Distributor
Distributed o + + + o + + + o o + +
Secure + - o +/- - o o o o o + -
Data intensive + - - + - - o + o - + +
Data consistency o + o - + o o - o o + o
Reliable + - + + - + + o o o + o
Real time + - +/- - + - + + o o + o
Robustness - - + + - + +/- - o o + +
Distributed transactions
- + + +/- + + + o o o + +
Positive (+) 4 3 4 4 3 4 4 3 0 0 8 4
Neutral (o) 2 0 2 0 1 2 3 3 8 7 0 3
Negative (-) 2 5 1 2 4 2 0 2 0 1 0 1
Positive / Negative (+/-)
0 0 1 2 0 0 1 0 0 0 0 0Peer-to-peer has pronounced data
consistency problems relevant for the given system
Combination of a peer-to-peer solution and a shared bus solution can circumvent
such issues
Proof-of-Concept Wiki Implementation
• Knowledge capture and management via wiki format (e.g., rationales)
• Platform for feedback on usefulness of proof-of-concept tool, plus relevance of row and column headings
Future Work
• Winbook-based multi-stakeholder requirements negotiation
• Devise configurability of integration matrix
• Further methodology enhancements―Buy/reuse/build―Incorporate technical restrictions and limitations when identifying
architectural solutions―Detection of possible mismatches with proposed guidelines for specific
adapters/translators―Solution ranking based on prioritization of the desired properties