System Design

Mahesh Shirole
VJTI, Mumbai

Object Oriented Software Engineering: Using UML, Patterns and Java

Architectural Styles
• As the complexity of systems increases, the specification of system
decomposition is critical
• It is difficult to modify or correct weak decomposition once
development has started, as most subsystem interfaces would have
to change
• In recognition of the importance of this problem, the concept of
software architecture has emerged
• A software architecture includes system decomposition, global
control flow, handling of boundary conditions, and inter-subsystem
communication protocols [Shaw & Garlan, 1996].
Architectural Styles
1. Repository architectural style
2. Model/View/Controller (MVC) architectural style
3. Client/server architectural style
4. Peer-to-peer architectural style
5. Three-tier architectural style
6. Four-tier architectural style
7. Pipe and filter architectural style
1. Repository Architectural Style
• In the repository architectural style, subsystems access and modify a single data
structure called the central repository
• Subsystems are relatively independent and interact only through the repository
• Control flow can be dictated either by the central repository (e.g., triggers on the
data invoke peripheral systems) or by the subsystems (e.g., independent flow of
control and synchronization through locks in the repository)
• Repositories are typically used for database management systems, such as a
payroll system or a bank system
• The central location of the data makes it easier to deal with concurrency and
integrity issues between subsystems
 1. Repository Architectural Style
• Compilers and software development
environments also follow a repository
architectural style
• The different subsystems of a compiler access
and update a central parse tree and a symbol
table
• Debuggers and syntax editors access the
symbol table as well
• The repository subsystem can also be used for
implementing the global control flow
• In the compiler example, each individual tool
(e.g., the compiler, the debugger, and the
editor) is invoked by the user. The repository
only ensures that concurrent accesses are
serialized
1. Repository Architectural Style
• Repositories are well suited for applications with constantly
changing, complex dataprocessing tasks
• Once a central repository is well defined, we can easily add new
services in the form of additional subsystems
• The main disadvantage of repository systems is that the central
repository can quickly become a bottleneck, both from a performance
aspect and a modifiability aspect
• The coupling between each subsystem and the repository is high,
thus making it difficult to change the repository without having an
impact on all subsystems
 2. Model/View/Controller (MVC)
architectural style
• Figure displays two views of a file
system
• The bottom window lists the content
of the Comp-Based Software
Engineering folder, including the file
9DesignPatterns2.ppt
• The top window displays information
about this file
• The name of the file
9DesignPatterns2.ppt appears in three
places: in both windows and in the
title of the top window
• Assume now that we change the name
of the file to 9DesignPatterns.ppt
 2. Model/View/Controller (MVC)
architectural style
• Assume now that we change the name of the
file to 9DesignPatterns.ppt.
1. The InfoView and the FolderView both
subscribe for changes to the File models
they display (when they are created)
2. The user types the new name of the file
3. The Controller, the object responsible for
interacting with the user during file name
changes, sends a request to the Model
4. The Model changes the file name and
notifies all subscribers of the change
5. Both InfoView and FolderView are
updated, so the user sees a consistent
change
 2. Model/View/Controller (MVC) architectural
style
• The subscription and notification functionality associated
with this sequence of events is usually realized with an
Observer design pattern
• The Observer design pattern allows the Model and the
View objects to be further decoupled by removing direct
dependencies from the Model to the View
• The rationale between the separation of Model, View, and
Controller is that user interfaces, i.e., the View and the
Controller, are much more often subject to change than is
domain knowledge, i.e., the Model
• Moreover, by removing any dependency from the Model
on the View with the subscription/notification protocol,
changes in the views (user interfaces) do not have any
effect on the model subsystems
• MVC is well suited for interactive systems, especially when
multiple views of the same model are needed
• MVC can be used for maintaining consistency across
distributed data; however it introduces the same
performance bottleneck as for other repository styles
3. Client/Server Architectural Style
• In the client/server architectural style, a subsystem, the server, provides
services to instances of other subsystems called the clients, which are
responsible for interacting with the user
• The request for a service is usually done via a remote procedure call
mechanism or a common object broker (e.g., CORBA, Java RMI, or HTTP)
• Control flow in the clients and the servers is independent except for
synchronization to manage requests or to receive results
• The client/server architectural style is a specialization of the repository
architectural style
 3. Client/Server Architectural Style
• An information system with a central database is an example of a client/server
architectural style
• The clients are responsible for receiving inputs from the user, performing range
checks, and initiating database transactions when all necessary data are collected
• The server is then responsible for performing the transaction and guaranteeing the
integrity of the data
• Client/server systems, however, are not restricted to a single server
• On the World Wide Web, a single client can easily access data from thousands of
different servers
4. Peer-to-Peer Architectural Style
• A peer-to-peer architectural style is a generalization of the client/ server
architectural style in which subsystems can act both as client or as servers,
in the sense that each subsystem can request and provide services
• The control flow within each subsystem is independent from the others
except for synchronizations on requests
• An example of a peer-to-peer architectural style is a database that both
accepts requests from the application and notifies to the application
whenever certain data are changed
• Peer-to-peer systems are more difficult to design than client/server
systems because they introduce the possibility of deadlocks and
complicate the control flow
4. Peer-to-Peer Architectural Style
• Callbacks are operations that are temporary and customized for a specific purpose
• For example, a DBUser peer in can tell the DBMS peer which operation to invoke upon a
change notification
• The DBUser then uses the callback operation specified by each DBUser for notification
when a change occurs
• Peer-to-peer systems in which a “server” peer invokes “client” peers only through
callbacks are often referred to as client/server systems, even though this is inaccurate
since the “server” can also initiate the control flow
• The database server can both process requests from and send notifications to applications
 5. Three-tier Architectural
Style
• The three-tier architectural style organizes
subsystems into three layers
1. The interface layer includes all boundary objects that deal with the user, including windows, forms,
web pages, and so on.
2. The application logic layer includes all control and entity objects, realizing the processing, rule
checking, and notification required by the application.
3. The storage layer realizes the storage, retrieval, and query of persistent objects.
• The three-tier architectural style was initially described in the 1970s for information
systems
• Objects are organized into three layers realizing the user interface, the processing, and the
storage
• The separation between the interface layer and the application logic layer enables the
development or modification of different user interfaces for the same application logic
 6. Four-tier Architectural Style
• The four-tier architectural style is a three-tier architecture
in which the Interface layer is decomposed into a
Presentation Client layer and a Presentation Server layer
• The Presentation Client layer is located on the user
machines, whereas the Presentation Server layer can be
located on one or more servers
• The four-tier architecture enables a wide range of different
presentation clients in the application, while reusing some
of the presentation objects across clients
• For example, a banking information system can include a
host of different clients, such as a Web browser interface
for home users, an Automated Teller Machine, and an
application client for bank employees
• Forms shared by all three clients can then be defined and
processed in the Presentation Server layer, thus removing
redundancy across clients
 7. Pipe and Filter Architectural Style
• In the pipe and filter architectural style, subsystems process data received from a set of
inputs and send results to other subsystems via a set of outputs
• The subsystems are called “filters,” and the associations between the subsystems are
called “pipes.”
• Each filter knows only the content and the format of the data received on the input pipes,
not the filters that produced them
• Each filter is executed concurrently, and synchronization is accomplished via the pipes
• The pipe and filter architectural style is modifiable: filters can be substituted for others or
reconfigured to achieve a different purpose
• A Filter can have many inputs and outputs
• A Pipe connects one of the outputs of a Filter to one of the inputs of another Filter
 7. Pipe and Filter Architectural Style
• The best known example of a pipe and filter architectural style is the Unix shell [Ritchie &
Thompson, 1974]
• Most filters are written such that they read their input and write their results on standard
pipes
• This enables a Unix user to combine them in many different ways
• Figure shows an example made of four filters
• The output of ps (process status) is fed into grep (search for a pattern) to remove all the
processes that are not owned by a specific user
• The output of grep (i.e., the processes owned by the user) is then sorted by sort and sent to
more, which is a filter that displays its input to a terminal, one screen at a time
7. Pipe and Filter Architectural Style

• Pipe and filter styles are suited for systems that apply
transformations to streams of data without intervention by users
• They are not suited for systems that require more complex
interactions between components, such as an information
management system or an interactive system