Please enable JavaScript.
Coggle requires JavaScript to display documents.
Hierarchical Architecture - Coggle Diagram
Hierarchical Architecture
Overview
System SWs are typically – hierarchical architecture
Examples
Microsoft .NET
Unix operating system
TCP/IP
Key Idea: services layered
Why? system too complex
Upper layer consumes service from lower layer
General Rules
Services at lower level provides more specific functionality down to fundamental utility services such as
I/O services, transaction, scheduling, security services, etc.
Middle layers provide more domain dependent functions such as
Business logic, core processing, etc.
Upper layers provide more abstract functionality in the form of user interfaces such as
Command line interpreter, GUI, Shell programming
Plus Point:
Any changes to a specific layer may affect only its adjacent upper layers.
So, no ripple effects of change
Main/Subroutine Architecture
Probably the oldest and most widely used architecture.
Purpose:
Encourage re-use of modules
Idea
System decomposed into sub-routines
A “main” program calls sub-routines and accomplishes task
How Sub-routine Call is Supported
Function Call Supported by Assembly
Protect old register values by pushing to stack
Set parameters in register
Call the subroutine
Jump, Long Jump, Call instruction
Software Interrupt
Function Call Supported by High Level Language
Much more convenient
Much more tricky!
Parameter passing
Pass by value
Pass by reference
data flow diagram (DFD)
Two types of flow
Transform Flow: input data get processed and results in output data (sequential)
Transaction Flow: depending on input data, take different control actions (branch)
Mapping Process
Identify transform and transaction flows
Map each flow into a subroutine
Generally: a main process controls the overall flow
Main/subroutine: Summary
Benefits
Easy to decompose the system
Can still be used in sub-system of OO Design.
Limitation
Tight coupling may cause ripple impacts as compared to OO design
Globally shared data are vulnerable
Master-Slave
It supports
Fault tolerance and system reliability
In this architecture:
The slaves provide replicated services to the master
The master selects a particular result among slaves by certain selection strategies.
Slaves may perform the same functional task by different algorithms and methods or a totally different functionality.
A variant of main-subroutine architecture
Block diagram for master-slave architecture
Class diagram for master-slave architecture
Applicable domain:
Where reliability is crucial
Characteristics:
Parallel computing and accuracy of computation
Layered
Physical Implementation
Functions in one layer usually organized in one package
Some times deployed as services
Summary - Layered
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
Incremental software development
Enhanced independence of upper layer to lower layer
Enhanced reusability and interchangeability
Component-based technology is a suitable
Promotion of portability
Limitations
Lower runtime performance
Many applications can not fit this architecture
Exception and error handling
Virtual Machine
Variation of Layered Approach
Idea
Provide a virtual interpretation layer that separates
Application
Physical machine layer
i.e., Software/Components run on simulation layer
Applicable Design Domain:
Suitable for solving a problem by simulation or translation
Sample applications such as interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Smalltalk and Java interpreter typed programming language
Benefits
Portability and machine platform independency
Simplicity of the software development
Simulation for non-native and disaster working model
Limitations
Slow execution of the interpreter
Additional overhead due to the new layer