Scribd
Upload
3 views

Chapter_7_(new)

Chapter 7 discusses hierarchical software architecture, including main-subroutine, master-slave, and layered architectures, along with their characteristics, benefits, and limitations. It emphasizes the modular decomposition of systems and the importance of encapsulation and service provision across different levels. The chapter also covers the application domains and implications of using virtual machines in software development.

Uploaded by

hieubvhe172009
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
3 views

Chapter_7_(new)

Chapter 7 discusses hierarchical software architecture, including main-subroutine, master-slave, and layered architectures, along with their characteristics, benefits, and limitations. It emphasizes the modular decomposition of systems and the importance of encapsulation and service provision across different levels. The chapter also covers the application domains and implications of using virtual machines in software development.

Uploaded by

hieubvhe172009
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 33

Chapter 7

HIERARCHICAL ARCHITECTURE
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
Agenda
• Hierarchical Architecture
– Overview
– Characteristics
• Main-Subroutine Architecture
• Master-Slave Architecture
• Layered Architecture
• Virtual Machine
Overview
• Viewing the whole system as a hierarchy
structure.
• The system is decomposed into logical
modules (sub-systems) at different levels
in the hierarchy.
• A lower level module provides services to
its adjacent upper level modules
Main-Subroutine Architecture
• The purpose is to reuse the subroutines
– individual subroutines developed
independently.
• Data location
– 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.
Main-Subroutine Characteristic
Main-Subroutine Characteristic
• Using this style, a software system is
decomposed into subroutines hierarchically
• The hierarchy will be refined according to the
desired functionality of the system.
• Refinements are conducted vertically until
– The decomposed subroutine is simple enough to
have its sole independent responsibility
– Whose functionality may be reused and shared by
multiple callers.
Main-Subroutine Characteristic
• Data is passed as parameters to
subroutines from callers.
• There are 2 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.
Main-Subroutine Characteristic
• A Data Flow Diagram (DFD) is often used to
model the software requirement
• During the mapping from DFD to the Main-Subroutine architecture e
need to find
– Transform flows
• incoming flow feeds data in an external format which is transformed
into another format, and then the outgoing flow carries the data out.
– Transaction flows.
• evaluates incoming data and decides to follow one of many action
paths.
• Then separate the incoming path and all action paths, and classify
each action path as transform or transaction flows.
Main-Subroutine Characteristic
• A transform flow is mapped by a
controlling module for incoming, transform
and outgoing information processing.
• A transaction center is located at the fork
origin of action paths.
A B C
6

Action path

purchase

3
record validate return

7
Customer 1 2 Action path

Customer 8
4
Info
Main-Subroutine Characteristic
• Benefits:
– Easy to decompose
• the system based on the definition of the tasks in a
top-down refinement manner.
– This architecture can still be used in a sub-
system of OO Design.
• Limitations:
– Globally shared data in classical main-
subroutines introduces vulnerabilities.
– Tight coupling may cause more ripple effects
of changes
Master-Slave Architecture
• Is a variant of the main-subroutine architecture
style supports
– fault tolerance
– system reliability.
• The master selects a particular service result
among slaves by certain selection strategy.
• The slaves may perform
– the same functional task by
• different algorithms
• different methods
– totally different functionality.
Master-Slave Architecture

Master

Slave ……….. Slave


Master-Slave Architecture
Master-Slave Architecture
• Applicable Design Domains :
– Used for the software system where the
reliability is critical.
• due to the replication (redundancy) of servers.
– Also use the term master-slave or parent-child
relationship in database schema design
• to specify the dependency of one entity on
another.
• If the master node is deleted then the slave node
does not have any reason to stay.
Layered Architecture
• The system is decomposed into a number
of higher and lower layers in a hierarchy
– Each layer consists of a group of related
classes
• are encapsulated
– in package,
– in a deployed component
– or as a group of subroutines in the format of method
library or header file.
– Each layer has its own sole responsibility
Layered Architecture
• The interface of each layer encapsulates
– all detailed service implementations in
• the current layer and
• the interfaces of the layers below.
• A request from higher layer to the layer
below is made via
– method invocation
• the response goes back up via
– method return.
Layered Architecture
Layered Architecture
• A simple software system may consist of two layers:
– Interaction Layer
– Processing Layer:
• The Interaction layer provides
– User Interfaces to clients
– Takes requests
– Validates and Forwards request to processing layer for
processing
– Responds to clients
• The Processing layer
– Gets the forwarded requests
– Performs business logic process
– Accesses database
– Returns the results to its upper layer
– Lets upper layer respond to clients
Layered Architecture
• Applicable Design Domains
– Any system that can be divided
• Application specific portions
• Platform specific portions which provide generic services
to the application of the system.
– Applications that have clean divisions between
• Core services
• Critical services
• User interface services, etc.
– Applications that have a number of classes that are
closely related to each other
• can be grouped together into a package to provide the
services to others.
Layered Architecture
Benefits:
– Incremental software development
• based on increasing levels of abstraction.
– Enhanced independence of upper layer to lower layer
• since there will be no impact from the changes of lower layer services
as long as their interfaces remain unchanged.
– Enhanced flexibility
• interchangeability and reusability are enhanced due to the separation of
the standard interface and its implementation.
– Component-based technology is a suitable technology to implement
the layered architecture
• this makes the system much easier to allow for plug-and-play of new
components.
– Promotion of portability
• Each layer can be an abstract machine deployed independently.
Layered Architecture
Limitations:
– Lower runtime performance: since
• a client’s request or a response to client must go through
potentially several layers.
• overhead on the data organizing and buffering by each
layer.
– Conflict of interlayer communication may cause
deadlocks
– “bridging” may cause tight coupling.
• Ex : layer-i bridge to layer i+2,…
– Exceptions and error handling is an issue
• Since faults in one layer must propagate upwards to all
calling layers.
Virtual machine
• A virtual machine
– Is built up on an existing system
– Provides a virtual abstraction
• a set of attributes, and operations.
• In most cases,
– A virtual machine separates a programming language
or application environment from a execution platform.
• a virtual machine looks like emulation software.
Virtual machine
Applicable Domain:
– Suitable for solving a problem by simulation or
translation if there is no direct solution.
– Sample applications include
• Interpreters of microprogramming
• XML processing
• Script command language execution
• Rule-based system execution
• Smalltalk and Java interpreter typed programming
language.
Virtual machine
Benefits:
– Portability and machine platform independency.
– Simplicity of software development.
– Simulation for disaster working model.

Limitations:
– Slow execution of the interpreter due to the interpreter
nature.
– Additional overhead due to the new layer.

You might also like