Architecture. Architecture is a high level description of a solution to a problem Recall architecture (high level design ) includes: Main Components Functionalities and properties of components Major Relations Components collaborating among the components. Architectural Style.
Architectural Style is a High Level Design Pattern
A software design pattern is a model for a class of solutions to a software design problem. At high level we call these patterns architectural styles.
My personal thoughts:
Design Patterns come in different levels:
1. - the high level architecture is not detailed enough and should
only serve as a guideline pattern for further refinement
2. - the middle level ones is where the current work is focused on
and may be domain dependent
3. - low level ones (e.g. data structures and algorithms) have been
employed relatively successfully via provided libraries
1. If any layer only uses the layer directly below
it, then it is a Strict Layered Style.
2. If a layer may useany of the layers below it,
then it is a Relaxed Layer Style
Problems that seem to fit this architecture include tele-comm and op-sys
Mail processing to establish which delivery plane/truck to distribute the US Postal mail
The sequence is from top layer to the lower layer.
This same scheme is often used in communications protocol architecture
Data Link layer
Information I/o Layer
cust info I/O
ord. info I/O
prod info I/O
. . .
Information validation Layer
Add, Delete, and Update
Info Processing Layer
Viewing from internal structure
and form; then designing with
“commonality” in mind
Ending up with layered architecture
Viewing and designing directly from
Discuss - - Pros and Cons in class: modularity; coupling; cohesion
Utilities (editors, sys commands,
access, libraries, etc.)
Resource (I/O, page,
network, file, etc.)
kernel (Device & memory
Process (classification &
How many of the layers would we need to worry about
---- for the currently popular “security” issue ?
I beg to differ
read input file
This architecture style focuses
on the dynamic (interaction)
rather than the structural
- the output from the command to the left of the symbol, l, is to be sent as input to the command to the right of the pipe;
- this mechanism got rid of specifying a file as std output of a command and then specifying that same file as the std input to another command, including possibly removing this intermediate fileafterwards
Example ( UNIX commands) :
$ cat my.txt
I live in
$ cat my.txt I sed “s/i/o/g”
I love on
Assume that in the file called my.txt is
I live in
Note the pipe
First cat command outputs my.txt to screen. The second cat command reads my.txt and
sends it to sed command which “search” for “i’ and “globally” replace it with “o.”
How may this be extended to the way e-mail with file attachment work?
Problems that require batch file processing seem to fit this architecture: e. g. payroll and compilers
Splitting the good time
cards from the bad ones
Card and Cut Check
Do the data streams
need to be synchronized
here for report?
Problems that fit this style such as patient processing, tax processingsystem, inventory control system; etc. have the following properties:
1. All the functionalities work off a single data-store.
2, Any change to the data-store may affect all or some of the functions
3. All the functionalities need the information from the data-store
1) A trigger may be thought as a monitor of the database for changes to the
database that matches the event specification (e.g. debit of bank cust. accnt)
2) Then the condition is checked to see if it is true (e.g. debited cust account
results in negative bank accnt amount).
3) If the debited account has a negative accnt amount, then kick off a procedure to
send error message out and delay the execution of cust account debiting.
Problems that fit this architecture includes real-time systems such as: airplane control;
medical equipment monitor; home monitor; embedded device controller; game; etc.
- - - try a commercial flight control system - - -
<< app and db>>
<< user interface >>
<< user interface>>
<< app and db>>
Problems that fit this architecture includes most of the inter-active web-applications.
--Discuss how this can be “adapted” to be shared data, event-driven or layered architecture--
We have introduced 5 different software architectural style which described
- the layout of the major components
- the interaction among the components
How do you decide on what should be your major components and the layout?
Who provides the mechanisms for the component interactions?
This is a relatively new field and these definitions are still under study
. . .
. . .
The component framework and the arrows
in this diagram represent the functionalities
of software connectors.
Examples: DCOM (Microsoft), CORBA (OMG),
.NET (Microsoft), etc.