Please enable JavaScript.
Coggle requires JavaScript to display documents.
Hierarchical Architecture (Main/Subroutine Architecture (Summary (Benefits…
Hierarchical Architecture
Main/Subroutine Architecture
How Sub-routine Call is Supported
by High Level Language
Much more convenient
Much more tricky!
Parameter passing
by Assembly
Call the subroutine
Set parameters in register
Protect old register values by pushing to stack
Design
Objective: Map from DFD to Main/Subroutine Design
Usually Requirement Spec. Specified in Data Flow Diagram (DFD)
Idea
A “main” program calls sub-routines and accomplishes task
System decomposed into sub-routines
DFD
Mapping Process
Map each flow into a subroutine
Generally: a main process controls the overall flow
Identify transform and transaction flows
Two types of flow
Transaction Flow
depending on input data, take different control actions (branch)
Transform Flow
input data get processed and results in output data (sequential)
Purpose
Encourage re-use of modules
Summary
Benefits
Can still be used in sub-system of OO Design
Easy to decompose the system
Limitation
Tight coupling may cause ripple impacts as compared to OO design
Globally shared data are vulnerable
Probably the oldest and most widely used architecture
Master-Slave
In this architecture
The master selects a particular result among slaves by certain selection strategies.
The slaves provide replicated services to the master
Diagram
Class diagram
Block diagram
It supports Fault tolerance and system reliability
Characteristics
Parallel computing and accuracy of computation
A variant of main-subroutine architecture
Applicable domain Where reliability is crucial
Virtual machine
Applicable Design Domain
Sample applications such as interpreters of microprogramming, XML processing, script command language execution...
Suitable for solving a problem by simulation or translation
Benefits
Simplicity of the software development
Simulation for non-native and disaster working model
Portability and machine platform independency
Idea
i.e., Software/Components run on simulation layer
Provide a virtual interpretation layer that separates
Physical machine layer
Application
Limitations
Additional overhead due to the new layer
Slow execution of the interpreter
Variation of Layered Approach
Layered architecture
Applicable Design Domains
For applications which have classes that are close related each other
For systems that can be divided between portions providing generic services to the application of the system
Benefits
Enhanced independence of upper layer to lower layer
Enhanced reusability and interchangeability
Incremental software development
Component-based technology is a suitable
Promotion of portability
Physical Implementation
Some times deployed as services
Functions in one layer usually organized in one package
Idea
upper layer invokes func. in lower layer
functionality grouped into layers
Limitations
Many applications can not fit this architecture
Exception and error handling
Lower runtime performance