Abii fbstracting Views of System Architecture · 2017-05-18 · Eli P i t fExploring Perspectives...

b i i fAbstracting Views of System ArchitectureE l i P ti f Exploring Perspectives of Software Intensive System Designg

Raymond JorgensenRockwell Collins

© Copyright 2011-2013 Rockwell Collins All right reserved.

1

Objectives

• Define system architecture• Describe traditional approach to develop systems

architecture• Discuss potential issues with traditional approachscuss po e a ssues ad o a app oac• Discuss alternative approaches to develop system

architecture• Define architectural views necessary to capture the • Define architectural views necessary to capture the

design of complex systems• Discuss layering of architectural views – software

viewsviews• Demonstrate how different layers of the

architecture are mapped to one another

© Copyright 2011-2013 Rockwell Collins, Inc. All rights reserved.

Slide 2

What is System Architecture?

• Wikipedia:– A system architecture or systems architecture is the conceptual

model that defines the structure, behavior, and more views of a system.

• IEEE:– The composite of the physical architectures for consumer products

and their life-cycle processes. (P1220)– The organizational structure of a system or component. (STD

610.12)610.12)– A logical or physical representation of a product which depicts its

structure, but, provides few or no implementation details. (P1220)

• DERA– The structure of levels and/or branches that partition a system into

its constituent parts or components.

• NASAHow functions are grouped together and interact with each other


Slide 3

– How functions are grouped together and interact with each other. (MDP92)

Definition of System Architecture

• The definition adopted by Rockwell Collins Architecture Standard (RC-ENG-S-101)– The fundamental organization of a system embodied in its

components, their relationships to each other and to the environment, and the principles guiding its design and evolution., p p g g g

ISO/IEC/IEEE 42010


Slide 4

Architecture in the Process

Capture Originating Requirements Support Solution

Define Operational Concepts

Define Requirements Verify Solution

Validate SolutionDevelop Validation Cases & Procedures

Develop Verification Cases & Procedures

Design Solution

Implement Solution

Integrate SolutionDevelop Acceptance Procedures

D fi L i l D fi Ph i l D fi P d tD fi P d tDevelop

Detailed Design

Define Logical Solution

Architecture(how does it all fit

together?)

Define Physical Solution

Architecture(what will the solution

look like?)

Define Product Internal Interface

(What is the interface structure?)

Define Product External Interface

(What is the interface structure?)


Slide 5

Perform product X analysis

Why is Architecture important?

• Clearly defines the components of the system and how they relate to one another– Both logical and physical components

• Identifies dependencies between system componentsAll f l l ll i f i l i • Allows for clearly allocating system non-functional requirements flow down to components

• Exposes interface points early and drives interface definition to improve independent development of componentsimprove independent development of components– As long as components conform to their interfaces, they can be

developed independently

• Helps provide a map for integration of system components• Aids in clearly communicating with all stakeholders• Facilitates reuse of system components by clearly defining their

boundaries, functions, and interactions


Slide 6

Top-Down Hierarchical System ArchitectureWhat potential problems

could be experienced ith “t d ” l

Systemwith “top-down” only

architecting??

Subsystem SubsystemWhere did this come from??

HardwareComponent

SoftwareComponent

SoftwareComponent

HardwareComponent

SoftwareS bcomponent

SoftwareS bcomponent

HardwareSubcomponent

HardwareSubcomponent


Slide 7

Subcomponent Subcomponent Subcomponent Subcomponent

Traditional Top-Down System Approach

• What is a “subsystem”?

• How does a “system” differ from a “subsystem”?

• Can a system share components with other systems within the same hierarchy?

• What happens when the “subsystem” does not have unique components?

H h “ l d l ” d “ d l it ” h d th • How has “plug and play” and “modularity” changed the way we engineer or manage our products?


Slide 8

• GPS Evolution

1995

1990

1985

19782003

19932010

1985


Integrated Modular Solution Architecture (IMSA)

bstrac

tion

Service

Support

System

Hierarc

Abs

Capability

ture

ntat

ion

ntat

ion

n Subsyste

m

chym

Arc

hite

c

al R

epre

sen

cal R

epre

se

nsta

ntia

tion S

Component

Sys

tem

Logi

ca

Phys

ic I Co

Views composing a


Slide 10

RealizationViews composing a complete picture of a system architecture

Integrated Modular Solution Architecture (IMSA)

Abstrac

tion

Service

Support

Mechanical System

Logical Function

System

Subsyste

m

Component

A

Capability

The System

MechanicalComponent

MechanicalComponent

Logical Function

Logical Function

Realization

ElectricalSystem

Component

SoftwareSystem

Component

Electrical Section

SoftwareComponent

SoftwareComponent

Electrical Section


Slide 11

SectionComponent Component Section

Characteristics of IMSA

• Independent software architectures – Software architecture can exist independently from underlying

physical hardware architecture!• Two projects with identical software architecture could have very

different hardware configurations.

– Software applications/ programs can reside anywhere in overall physical hardware architecture

• Application software design abstracts out hardware interface so that it is Application software design abstracts out hardware interface so that it is not tied to a single box

– Software architecture defined independently from the hardwareAllocation of application software to specific processors requires analysis • Allocation of application software to specific processors requires analysis to assess resource usage

• Concerns – latency, throughput, and processor loading – can the underlying architecture handle resource usage?


underlying architecture handle resource usage?

Slide 12

Solution Architecture Views

• No one “picture” shows the full architecture of the solution– How is the architecture captured and managed?– Is a hierarchy view enough?

A hit t t i • Architecture contains – Components with structure and composition– Behavior showing inputs, processing, and outputs– Relationships showing interconnectivity of the solutionRelationships showing interconnectivity of the solution

• Multiple perspectives result in multiple views of the architecture– Software, Hardware, Behavioral, etc.Software, Hardware, Behavioral, etc.

• Interdependencies between views must also be captured– Interfaces and relationships


p

Slide 13

“Your House for Example”

System

bsyste

m

Abstrac

tion

Capability

Service

Support

Subsy

Component

RealizationRealization


Slide 14

Realization Views

• Progression from left to right proceeds from

epre

sent

atio

n

Rep

rese

ntat

ion

ntia

tion

System

Subsyste

monen

t

Hierarchy

Abstrac

tion

abstract, notional concepts to tangible assets to realized components

Logi

cal R

e

Phys

ical

R

Inst

a

Compon


Slide 15

System

Hierarchy

Abstrac

tion

Logi

cal R

epre

sent

atio

n

Phys

ical

Rep

rese

ntat

ion

Inst

antia

tion Subsy

stem

Component

y

Realization Views


Slide 16

System

Hierarchy

Abstrac

tion

Logical Representations Summary

Logi

cal R

epre

sent

atio

n

Phys

ical

Rep

rese

ntat

ion

Inst

antia

tion Subsy

stem

Component

y

«Exception»Fail to Access Order

HistoryDataManager

«CSCI»eChef::RecipeMgr

«RC_Activity»Create list of

proteins

«RC_Activity»Display search target options

«satisfies»

«satisfies»

Cas

e Vi

ew

vior

al V

iew

cena

rios)

tiona

l Vie

w«Main_Course»Generate Report

Inventory Supplier

«System »eChef

«extend»

«extend»

«extend»

«prim ary»«RC_Activity»

Manage Inventory

«RC_Activity»Manage Recipes

«RC_Activity»Manage Kitchen

«RC_Activity»Create Inventory

«RC_Activity»Manage

«RC_Activity»Display search filter

options

«satisfies»

Use

C

Beh

av(S

c

Func

t

«Exception»Fail to Retrieve Order

History

«Exception»Fail to Print Report

Initial

:Household Chef :VideoProcessing :FoodEncyclopedia:RecipeMgr

«RC_Activity»Request video «RC_Activity»

«RC_Activity»Order Inventory

«RC_Activity»Manage Supplier

Inventory

List

«RC_Activity»Edit Inventory

List

«RC_Activity»Delete Inventory

List

Suppliers

«RC_Activity»Find Recipe

«RC_Activity»Create Recipe

«RC_Activity»Edit Recipe

«RC_Activity»Delete Recipe

«RC_Activity»Manage Orders


Inventory List


Customers

qrecording

«RC_Activity»Configure video

recording

«RC_Activity»Initiate video

recording

«RC_Activity»

Display recording options

«RC_Activity»Display ready to

record

«RC_Activity»Send record

request

«RC_Activity»Begin recording

«RC_Activity»Store video

«RC_Activity»Create video file

«RC_Activity»Configure recording

Current Inventory :InventoryList

Inventory Manager

Updated Item :InventoryItem

Inventory Shortages :

Selected Suppliers :

Hierarchical Perspective

Sequential

Final

Complete video recording

«RC_Activity»View video

«RC_Activity»Stop recording

«RC_Activity»Send stop request

«RC_Activity»Play video

«RC_Activity»Playback video

«RC_Activity»Play recording

«RC_Activity»Play video

«System »eChef

«RC_Activi...Manage Inventory

y

Inventory Delivered :InventoryOrder

y gInventoryItem

ppSupplier_InfoSequential

Perspective

Transactional Perspective


Slide 17

«RC_Activity»Manage Supplier

Inventory

Inventory Order :InventoryOrder

Order Ack :InventoryOrderAckAllocation

Perspective

System

Hierarchy

Abstrac

tion

Logi

cal R

epre

sent

atio

n

Phys

ical

Rep

rese

ntat

ion

Inst

antia

tion Subsy

stem

Component

y

sent

atio

n

Logical Allocation into Physical Views

Phys

ical

Rep

res


Slide 18

Physical Representation Views

ion

Logi

cal R

epre

sent

atio

n

Phys

ical

Rep

rese

ntat

ion

Inst

antia

tion

System

Subsyste

m

Component

Hierarchy

Abstrac

tio• Software View• Electrical View (Network)• Mechanical View (Hardware)

cal R

epre

sent

atio

n

( )• Infrastructure View • Human Resource View

Phys

ic


Slide 19

System

Hierarchy

Abstrac

tion

Logi

cal R

epre

sent

atio

n

Phys

ical

Rep

rese

ntat

ion

Inst

antia

tion Subsy

stem

Component

y

enta

tion

Physical Representation – Software View

• Software Views

Phys

ical

Rep

rese

Hierarchical Perspective

Sequential Perspective

Transactional Perspective (Messaging)

Allocation Perspective (from logical)


Slide 20

Software View – Hierarchical Perspective

Explicit Hierarchy“a part of”a part of -aggregation

«Software_System»eChef

«CSCI»


«CSCI»encyclopedia :

FoodEncyclopedia

«CSCI»recipeBox :RecipeMgr

CSC CSC

«CSCI»eChef::

InventoryOrderMgr

eChef::FoodEncyclopedia

«references-a»

«references-a»«references-a»

«references-a»«CSCI»pantry :

InventoryMgr

«CSCI»grocer :

InventoryOrderMgr


«CSCI»eChef::InventoryMgr

«is-a»«is-a»

«is-a»

Implicit Hierarchysuperimposed

«CSCI»DataManager

«is a»

Explicit Hierarchy“is a” - generalization


Slide 21

g

Software View – Transactional Perspective

eChef

«CSCI»recipeBox :RecipeMgr

«CSCI»pantry :

Inv entoryMgr

«CSCI»grocer :

Inv entoryOrderMgr


FoodEncyclopedia

«flowPort» encycl

«flowPort» inventory

«flowPort» recipe

«flowPort» inventoryOrder

«flowPort» foodInfo

y

«flowPort» supplier Ports and Flows –where the data words

flow

«flowPort»inventorySupplierImplicit Hierarchy


Slide 22

- Showing with superposition

Software View Allocation PerspectiveSoftware View – Allocation PerspectiveLogical Elements to Software Partitions

Initial

:Executiv e Chef :Recipe Prov ider :Inv entoryMgr:RecipeMgr

«RC_Activ ity»Initiate recipe

search

«RC_Activ ity»Specify search

«RC_Activ ity»Display search

filter optionsSearch Filter Opts :Search_Filter_Type

Specify search filter

RC Activ ity

«RC_Activ ity»Validate search

filter

«RC_Activ ity»Display search target options

Search Filter :SearchFilter

Search Target Options :

SearchTarget

«ctrl»

«RC_Activ ity»Specify search

target«RC_Activ ity»

Validate search targets

g

Selected Targets :SearchTarget

«RC_Activ ity»RC A ti it

_ yGet list of inv entory

«RC_Activ ity»Prov ide inv entoryInv entory :

Inv entoryList«RC_Activ ity»Create list of

proteinsImplicit allocation of function to software


Slide 23

component

Functional View - Allocation PerspectivesActivity in

Partition/SwimlaneActivity Overlay on Physical Element

:RecipeMgr

«RC Activity»

DataManager


RC_ActivityDisplay recording

options«RC_Activity»Create list of

proteins


«RC_Activity»Configure recording

«RC_Activity»Display ready to

record


options

Implicit allocation of


Slide 24

Implicit allocation of function to physical

component

Functional View - Allocation Perspectives

Realization relationship between logical and physical elements


DataManager



target options

«satisfies»

eChef::RecipeMgrCreate list of proteins

«RC Activity»

«satisfies»

«satisfies»«RC_Activity»

Display search filter options Explicit allocation of

function to physical component


Slide 25

component

Software View Allocation PerspectiveSoftware View – Allocation PerspectiveLogical Elements to Software Elements

«RC_Activ ity»Display search

filter optionsp


filter

«RC Activ ity»

DataManager

«CSCI»DataManager

CSCI

«satisfies»

«satisfies»

Implicit allocation of function to software

component«RC_Activ ity»

Display search target options


targets

«RC_Activ ity»Prov ide inv entory

eChef::RecipeMgr «CSCI»eChef::Inv entoryMgr

«satisfies»

«satisfies»

«satisfies»

«satisfies»

«satisfies»

«RC_Activ ity»Get list of inv entory

«RC_Activ ity»Create list of

«satisfies»

E li it ll ti f

DataManager


proteins Explicit allocation of function to software

component


proteins



Slide 26


options

System

Hierarchy

Abstrac

tion

Logi

cal R

epre

sent

atio

n

Phys

ical

Rep

rese

ntat

ion

Inst

antia

tion Subsy

stem

Component

y

enta

tion

Software Allocation to Electrical

• Software View

Phys

ical

Rep

rese

Allocation (or Deployment) Perspective (to Electrical)


Slide 27

Software View –Software View –Allocation (or Deployment) Perspective

DataManager

«CSCI»Software Architecture::eChef::

DataManager


RecipeMgr Inv entoryMgr

DataManager

«CSCI»S ft A hit t Ch f


FoodEncyclopedia«satisfies» «satisfies»

«Electrical_Section»Electrical Architecture::eChef::

GeneralProcessing

Software Architecture::eChef::InventoryOrderMgr«satisfies»

«satisfies»

«Electrical_Section»GPPU1 :GeneralProcessingGPPU1 :GeneralProcessing


FoodEncyclopedia

«CSCI»recipeBox :RecipeMgrExplicit allocation/

deployment of software components

«Electrical_Secti...GPPU2 :

GeneralProcessing

«CSCI»pantry :

Inv entoryMgr

«Electrical_Section»GPPU3 :GeneralProcessing

«CSCI»grocer :

software components onto processor.

Implicit allocation/ deployment of

software components


Slide 28

Inv entoryMgrgrocer :Inv entoryOrderMgr

software components onto processor.

Abstraction Views - Capability


D t M«CSCI»

DataManager

«CSCI»eChef::

Inv entoryOrderMgr

FoodEncyclopedia«references-a»

«references-a»«references-a»

«references-a»

DataManager


DataManager

«CSCI»eChef::Inv entoryMgr «Mechanical_System»

eChef

«LRU»eChef::MealPlanner

«references-a»

«references-a»

«references-a»

«LRU»eChef::

SupplierServ er

«LRU»eChef::Inv entory

Serv er


Slide 29

Abstraction Views – Service

«CSCI»eChef::

M i MMessagingMgr

«references-a»

«Mechanical_System»eChef


«LRU»

«references-a»

«CSCI»

«references-a»

«LRU»eChef::Network

Switch

«CSCI»eChef::HealthMgr


Slide 30

Abstraction Views - Support

«TPIP CSCI»eChef::

OperatingSystem


«TPIP CSCI»eChef::HardwareDriv er

«references-a»

eChef::HardwareDriv er

«references-a»


Slide 31

Summary

• Define system architecture• Differentiate architectural design from detailed

design• Describe traditional approach to develop systems

hit tarchitecture• Discuss potential issues with traditional approach• Discuss alternative approaches to develop system

architecturearchitecture• Define architectural views necessary to capture the

design of complex systems• Discuss layering of architectural views – software • Discuss layering of architectural views – software

views• Demonstrate how different layers of the

architecture are mapped to one another


Slide 32

pp

Conclusions

• Today’s integrated modular solution architectures preclude a “top-down” only, traditional decomposition view

• The “software system” is a unique view that our complex systems must address

The inte actions bet een soft a e components has become one of – The interactions between software components has become one of the most complex facets of today’s systems

• Four primary relationships to explore between objects– Hierarchical – composition, “kind of”e a c ca co pos o , d o– Transactional – information and object/material flows– Chronological – sequential/parallel timing– Allocation – aka deployment


Slide 33

Presenter Information

Raymond JorgensenRockwell Collins, Inc400 Collins Rd NE, MS 188-400Cedar Rapids, IA [email protected]


Slide 34

Abii fbstracting Views of System Architecture · 2017-05-18 · Eli P i t fExploring Perspectives...

Documents

Transcript of Abii fbstracting Views of System Architecture · 2017-05-18 · Eli P i t fExploring Perspectives...