CS 4321 Ch 9, Part 2 Architecting & Designing Software

yompmulligrubsInternet and Web Development

Oct 31, 2013 (3 years and 5 months ago)

64 views

1


CS
4321



Ch

9
, Part
2

Architecting & Designing Software


Sections

Pages

9
.
6
-
9.
7, 9.9

3
47
-
3
65, 366
-
367


***
Some

of these
notes
are

copied directly from the PP slides that accompany the text.


Section
9
.
6



Architectural Patterns


1.

The notion of patterns
can be applied to software architecture. These are called

architectural patterns

and
allow you to design flexible systems using components

which are
as independent of each other as possible.



Section 9.6


Layered System Architectural Pattern


1.

In a layered system, each layer communicates only with the layer immediately below it.




Each layer has a well
-
defined interface used by the layer immediately above.

o

The higher layer sees the lower layer as a set of
services
.



A complex system can be built

by superposing layers at increasing levels of abstraction.

o

It is important to have a separate layer for the UI.

o

Layers immediately below the UI layer provide the application functions determined by the use
-
cases.

o

Bottom layers provide general services.



e
.g. network communication, database access


2.

The three
-
tier architecture has the following tiers:


a.

Presentation tier


This
is the topmost level of the application. The presentation tier displays
information related to such services as browsing merchandise,

purchasing, and shopping cart contents.
It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the
network.

b.

Application tier (
business logic
, logic tier, data access tier, or middle tier)


Th
e logic tier is pulled out
from the presentation tier and, as its own layer, it controls an application’s functionality by

performing
detailed processing, process commands, makes logical de
cisions. It also moves and processes data
between the presentation tier and the data tier.

c.

Data tier


This
tier consists of database servers

and code to store and retrieve data. The information is
passed back to the application tier where some processing
may take place and then ultimately back to
the presentation tier.



3.

The middle tier is
frequently multi
-
tiered in which case the overall architecture is called
n
-
tier
.




2


4.

There have been growing concerns in recent years that many organizations are facing
an excessive number
of layers in their multi
-
layered architecture. These concerns stem from sprawling application architectures
that are not well designed or managed, in which development teams create an ever
-
growing number of
"wrapper" layers that comprom
ise maintainability. The resulting architecture resembles a

Rube Goldberg
Machine

that scares organizations from solving the root cause of the sprawling layers, r
esulting in the
creation of more layers.

Source:
http://en.wi ki pedi a.org/wi ki/Mul ti ti er_archi tecture


5.

Example of multi
-
layer systems






3


Section 9.6


Client
-
Server and other distributed

architectural patterns


1.

The Client
-
Server and other distributed architectural patterns




There is at least one component that has the role of
server
, waiting for and then handling connections
.



There is at least one component that has the role of
client
,
initiating connections in order to obtain
some service
.


2.

The internet is inherently client
-
server:




3.

Three
-
tiered client
-
server architecture:






4


4.

A further extension is the
Peer
-
to
-
Peer pattern


A
system composed of various software components that
are distributed over several hosts.

For instance, a file
-
sharing application:





Section 9.6


Broker architectural pattern


1.

The Broker architectural pattern allows you to t
ransparently distribute aspects of the software system to
different nodes




An
object can call methods of another object without knowing that this object is remotely located
.



Object
-
oriented properties should be preserved, even across system boundaries



Common Object Request Broker Architecture (
CORBA
)

is a well
-
known open standard that allows you to
build this kind of architecture.

Java provides support for CORBA.


2.

Servers register with the broker. Clients send service requests to servers via the broker. The Broker has the
responsibility for locating t
he proper server, forwarding the service request and transmitting results back to
the client.






5


Section 9.6


Transaction
-
Processing architectural pattern


1.

A process reads a series of inputs one by one.

Each input describes a
transaction



a command that typically
causes
some change to the data stored by the system


2.

In transaction processing, a unit
-
of
-
work (transaction) is typically several operations that must all succeed or
else if one operation fails, the other completed operations
must be undone. Transaction has the potential to
leave the data in a compromised state, thus the dispatcher needs the ability to roll
-
back changes in the
event of an operation failure.


3.

Transaction Processing is used in
order capture and order process

appl
ications.
Example:


The following are the transactional operations in this application:

a.

create order,

b.

update inventory,

c.

create shipping record, and

d.

update order status.




Source:
http://www.subbu.org/articles/nuts
-
and
-
bolts
-
of
-
transaction
-
processing



4.

Financial transactions like the stock market frequently utilize this pattern.


5.

There is a transact
ion
dispatcher

component that decides what to do with each transaction


6.

This dispatches a procedure call or message to one of a series of component
s

that will
handle

the
transaction






6


Section 9.6


Pipe
-
and
-
Filter

A
rchitectural
P
attern


1.

A stream of
data, in a relatively simple format, is passed through a series of processes




Each of which transforms it in some way.



Data is constantly fed into the pipeline.



The processes work concurrently.



The architecture is very flexible.

o

Almost all the components
could be removed
.

o

Components could be replaced.


o

New components could be inserted.


o

Certain components could be reordered.





2.

Another example is the processing/compiling of source code.



7


3.

Graphics:



8


Section 9.6


Model
-
View
-
Controller (MVC)

A
rchitectural
P
attern


A
n architectural pattern used to help separate the user interface layer from other parts of the system





The
model

contains the underlying classes whose instances are to be viewed and manipulated




The
view

contains objects used to render the appearance of the data from the model in the user
interface




The
controller

contains the objects that control and handle the user’s interaction with the view and the
model



The Observable design pattern is normally used
to separate the model from the view







9


Section 9.6


Service
-
Oriented A
rchitectural
P
attern


This architecture organizes an application as a collection of services that communicates using well
-
defined
interfaces




In the context of the Internet, the services are called
Web services




A web service is an application, accessible through the Internet, that can be integrated with other
services to form a complete system




The different components generally communicate wi
th each other using open standards such as XML.



10


Section 9.6


Message
-
Oriented A
rchitectural
P
attern


Under this architecture, the different sub
-
systems communicate and collaborate to accomplish some task only
by exchanging messages.




Also known as
Message
-
oriented Middleware (MOM)



The core of this architecture is an application
-
to
-
application messaging system



Senders and receivers need only to know what are the message formats



In addition, the communicating applications do not have to be available
at the same time (i.e. messages
can be made persistent)



The self
-
contained messages are sent by one component (the
publisher
) through virtual channels
(
topics
) to which other interested software components can subscribe (
subscribers
)




Section 9.
7



Writing a Good Design Document


Design documents as an aid to making better designs





They force you to be explicit and consider the important issues before starting implementation.



They allow a group of people to review the design and therefore to
improve it
.



Design documents as a means of communication.


o

To those who will be
implementing

the design.

o

To those who will need, in the future, to
modify

the design.

o

To those who need to create systems or subsystems that
interface

with the system being
des
igned
.




11


Section 9.
9



Difficulties and Risks in Design


1.

Like modelling, design is a skill that requires considerable experience




Individual software engineers should not attempt the design of large systems



Aspiring software architects should actively
study designs of other systems


2.

Poor designs can lead to expensive maintenance




Ensure you follow the principles discussed in this chapter



3.

It requires constant effort to ensure a software system’s design remains good throughout its life





Make the original design as flexible as possible so as to anticipate changes and extensions.



Ensure that the design documentation is usable and at the correct level of detail



Ensure that change is carefully managed


Chapter
9

Homework


1.

List the different
types of design.

2.

Explain how bottom
-
up design can be useful when trying to build reusable components.

3.

List 5 design principles.

4.

Define cohesion and coupling.



5.

Define functional cohesion.

6.

Describe layer cohesion.

7.

Define content coupling. Provide an ex
ample.

8.

Define control coupling and two methods for reducing it.

9.

Define stamp coupling.

10.

Define software architecture.

11.

List two or more UML diagrams that are useful for presenting a system architecture.

12.

Describe the Layered System Architecture and
provide a generalized component diagram of the typical
layers in an application program.

13.

Describe the Client
-
Server Architecture and provide a generalized component diagram.

14.

Describe the difference between a Broker Architecture and a Transaction Processing

Architecture.

15.

Describe how a search engine could utilize a pipe and filter architecture.

16.

List 5 architectural patterns.

17.

Describe the MVC architecture and how it works. Provide a component diagram.

18.


(omit) Discuss three ways to
Design for flexibility