1 / 14

A-7E Case Study

A-7E Case Study. CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Wk 1, Day 3. Today. A case history – this Ch 3 in Bass, et al. Time to work on Project 1 in class. A7E - Acknowledgements.

jolanda
Download Presentation

A-7E Case Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A-7E Case Study CSSE 477 Software ArchitectureSteve Chenoweth, Rose-Hulman InstituteWk 1, Day 3

  2. Today • A case history – this • Ch 3 in Bass, et al. • Time to work on Project 1 in class.

  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/.

  4. Outline • History of A-7E Project • Decomposition Structure • Uses Relation • Process Structure

  5. David Parnas David Weiss Paul Clements Kathryn Britton Naval Research Laboratory

  6. A-7E History • Software Cost Reduction (SCR) • Information hiding • A-7E Project (1977 - 1987) • Requirements discovery • Reference Architecture • Software Architecture and Design • Partial implementation

  7. A-7E Avionics • Sensors • air probe • radar • Displays • map • heads-up • Input • joystick • keypad

  8. Module Guide • Provides decomposition structure of software architecture • Describes information hiding modules • Purposes: • avoid duplication and gaps • achieve separation of concerns • help maintainer find modules affected by a change request

  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

  10. Decomposition Structure • Hardware-Hiding Module • Behavior-Hiding Module • Software Decision Module • Application Data Type Module • Data Banker Module • Filter Behavior Module • Physical Models Module • Software Utility Module • System Generation Module

  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 These two at the top

  12. Layers Implied by Uses Relation

  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.

  14. Process Consequences The offline analysis possible from the process design let lots of scheduling be pre-determined (prior to runtime): • Thread structure identified • Re-entrant procedures identified • Most-often invoked procedures identified • Mutual exclusion identified

More Related