1-1

-1

Chapter Five
Basic concepts of architectural design

Compiled by: Alula T

2
REPOSITORY
❑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).

3
❑Repositories are well suited for applications with constantly
changing, complex data processing 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.

4
MODEL/VIEW/CONTROLLER
❑In the Model/View/Controller (MVC) architectural style
subsystems are classified into three different types:
✓model subsystems : maintain domain knowledge,
✓View subsystems :display it to the user, and
✓controller subsystems : manage the sequence of interactions with the
user.
❑The model subsystems are developed such that they do not
depend on any view or controller subsystem.
❑Changes in their state are propagated to the view subsystem
via a subscribe/notify protocol.
❑The MVC is a special case of the repository where Model
implements the central data structure and control objects
dictate the control flow.

5
6
❑An example of MVC architectural style.
❑The “model” is the filename 9DesignPAtterns2.ppt.
❑One “view” is a window titled CBSE, which displays the contents
of a folder containing the file 9DesignPatterns2.ppt.
❑The other “view” is window called 9DesignPatterns2.ppt Info,
which displays information related to the file. If the file name is
changed, both views are updated by the “controller.”

7
8
CLIENT/SERVER
❑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.

9
❑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.
❑Client/server architectural styles are well suited for distributed
systems that manage large amounts of data.

10
PEER-TO-PEER
❑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.

11
THREE-TIER
The three-tier architectural style organizes subsystems into three
layers:
• The interface layer includes all boundary objects that deal with
the user, including windows, forms, web pages, and so on.
• The application logic layer includes all control and entity objects,
realizing the processing, rule checking, and notification required by
the application.
• The storage layer realizes the storage, retrieval, and query of
persistent objects.

12
13
PIPE AND FILTER
❑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.

14
❑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.

15
PACKAGE DIAGRAM
Package diagrams are used to structure high level system elements.
Packages are used for organizing large system which contains
diagrams, documents and other key deliverables.
✓Package Diagram can be used to simplify complex class diagrams, it can
group classes into packages.
✓A package is a collection of logically related UML elements.
✓Packages are depicted as file folders and can be used on any of the UML
diagrams.

16
❑ Packages appear as rectangles with small tabs at the top.
❑ The package name is on the tab or inside the rectangle.
❑ The dotted arrows are dependencies.
❑ One package depends on another if changes in the other could
possibly force changes in the first.

17
18
❑Package Diagram Example - Import
<<import>> - one package imports the functionality of other
package

❑Package Diagram Example - Access

19
DEPLOYMENT DIAGRAM
They show the structure of the run-time system
They capture the hardware that will be used to implement the
system and the links between different items of hardware.
They model physical hardware elements and the communication
paths between them
They can be used to plan the architecture of a system.
They are also useful for Document the deployment of software
components or nodes

20
❑A deployment diagram is just a special kind of class diagram,
which focuses on a system's nodes. Graphically, a deployment
diagram is a collection of vertices and arcs. Deployment diagrams
commonly contain:
❑Nodes
 3-D box represents a node, either software or hardware
 HW node can be signified with <<stereotype>>
 Connections between nodes are represented with a line, with optional
<<stereotype>>
 Nodes can reside within a node
❑Other Notations
▪Dependency
▪Association relationships.
▪May also contain notes and constraints.

21
22