54204_PP07_Chap07PPT_Modified

54204_PP07_Chap07PPT_Modified - Chapter 7 HIERARCHICAL...

Info iconThis preview shows pages 1–9. Sign up to view the full content.

View Full Document Right Arrow Icon
Chapter 7 HIERARCHICAL ARCHITECTURE
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Objectives Introduce the concepts of hierarchical software architecture Describe the main-subroutine, master-slave, and layered architectures Discuss the application domains of hierarchical software architecture Discuss the benefits and limitations of hierarchical software architecture Demonstrate the hierarchical software architecture in OS scripts and Java
Background image of page 2
Overview The hierarchical software architecture is characterized by viewing the whole system as a hierarchy structure . The software system is decomposed into logical modules (sub-systems) at different levels in the hierarchy. Modules at different levels are connected by explicit or implicit method invocations . A lower level module provides services to its adjacent upper level modules , which invokes the methods or procedures in lower level.
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Main-Subroutine The mai n-subroutine design architecture has dominated the software design methodologies for a very long time. The purpose of this architectural style is to reuse the subroutines and have individual subroutines developed independently. In the classical procedural paradigm , typically data are shared by related subroutines at the same level. With object orientation , the data is encapsulated in each individual object so that the information is protected.
Background image of page 4
People often refer to the main-subroutine style as a traditional style rather than OO style . Using this style, a software system is decomposed into subroutines hierarchically refined according to the desired functionality of the system. Refinements are conducted vertically until the decomposed subroutine is simple enough to have its sol e independent responsibility , and whose functionality may be reused and shared by multiple callers above.
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Data is passed as parameters to subroutines from callers. There are many different ways to pass on parameter data: Passed by reference where the subroutine may change the value of data referenced by the parameter. Passed by value where the subroutine only uses the passed data but cannot change it.
Background image of page 6
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
In what follows we describe how to map a requirement specification to the Main-Subroutine design style. A Data Flow Diagram (DFD)
Background image of page 8
Image of page 9
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 09/14/2010 for the course SAD 333 taught by Professor Luis during the Summer '10 term at St. Louis CC.

Page1 / 33

54204_PP07_Chap07PPT_Modified - Chapter 7 HIERARCHICAL...

This preview shows document pages 1 - 9. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online