1 a-7e case study csse 477 software architecture steve chenoweth, rose-hulman institute wk 1, day 3

14
1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

Upload: rosaline-ross

Post on 14-Jan-2016

218 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

1

A-7E Case Study

CSSE 477 Software ArchitectureSteve Chenoweth, Rose-Hulman InstituteWk 1, Day 3

Page 2: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

2

Today

A case history – thisCh 3 in Bass, et al.

Time to work on Project 1 in class.

Page 3: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

3

A7E - Acknowledgements

Some of the material in these slides is taken from Software Architecture in Practice, 2nd edition by Bass, Clements, Kazman.

http://www.sei.cmu.edu/staff/ljb/, http://www.sei.cmu.edu/staff/clements/, http://www.sei.cmu.edu/staff/rkazman/.

Page 4: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

4

Outline

History of A-7E Project Decomposition Structure Uses Relation Process Structure

Page 5: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

5

Naval Research Laboratory

David Parnas

Paul Clements David WeissKathryn Britton

Page 6: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

6

A-7E History

Software Cost Reduction (SCR)Information hiding

A-7E Project (1977 - 1987)Requirements discoveryReference ArchitectureSoftware Architecture and DesignPartial implementation

Page 7: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

7

A-7E Avionics

Sensors air probe radar

Displays map heads-up

Input joystick keypad

Page 8: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

8

Module Guide

Provides decomposition structure of software architecture

Describes information hiding modules Purposes:

avoid duplication and gapsachieve separation of concernshelp maintainer find modules affected

by a change request

Page 9: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

9

Decomposition Goals

Each module should be simple enough to understand fully

Change in implementation of a module should not affect other modules

Ease of making change related to likelihood of need for change

Page 10: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

10

Decomposition Structure

Hardware-Hiding Module Behavior-Hiding Module Software Decision Module

Application Data Type ModuleData Banker ModuleFilter Behavior ModulePhysical Models ModuleSoftware Utility ModuleSystem Generation Module

Page 11: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

11

Uses Relation

Similar to "calls" relation Layers of what can call what:

• EC = Extended Computer at the bottom

• AT = Application Data Type Module

• DI = Device Interface Module

• FD = Function Driver Module

• SS = Shared Services Module

Allowed-to-use relation defined in advance to partition programming

Using procedure Used procedure

Extended Computer (none)

Device Interface EC.DATA, EC.PGM, ...

Air Data Computer Func. DB.DI.ADC, DI.ADC, ...

These two at the top

Page 12: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

12

Layers Implied by Uses Relation

Function Driver, Shared Services

Software Utilities Physical Models, Filter Behavior,

Data Banker

Application Data Type

Extended Computer

Page 13: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

13

Process Structure

Cooperating Sequential Processes synchronization via shared data

Types of processes: Function driver processes (for avionics):

• Periodic – run every 40 ms• Demand-driven – await a triggering event

Access procedure processes (less frequent):• Periodic – run every 100 ms – compute and store values• Procedures to get and use values when called

Offline scheduling – to run all this on single processor! Avoids scheduling decisions at runtime.

Page 14: 1 A-7E Case Study CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3

14

Process Consequences

The offline analysis possible from the process design let lots of scheduling be pre-determined (prior to runtime):Thread structure identifiedRe-entrant procedures identifiedMost-often invoked procedures identifiedMutual exclusion identified