1. Software models - Software Architecture Design Patterns
IMPORTANT NOTICE TO STUDENTS:
These slides are NOT to be used as a replacement for student notes.
These slides are sometimes vague and incomplete on purpose to spark class discussions.
Software models - Software Architecture Design Patterns
CS 360
Lecture 11

2. Architectural Styles Outline
An architectural style is a system architecture that recurs in many different applications.
Examples:
Pipe-and-Filter
Layered
Client/Server and P2P
Repository
Model/View/Controller
Buffering

3. System architecture
Conceptual model that defines structure, behavior, and views of a system.
Computers and networks (monolithic, distributed)
Interfaces and protocols (http, IEEE 802.3, )
Databases (relational, NoSQL)
Security (authentication, encryption)
Operations (backup, archiving, replication)
At this stage of the project, you should also be selecting:
Software environments (languages, database systems, APIs)
Test cases

4. Architectural Style: Pipe-and-filter
Overview:
Separate programs (filters) are executed, potentially concurrently.
The output of one program is the input of another.

5. Architectural Style: Pipe-and-filter
Example: A three-pass compiler
Output from one subsystem is the input of the next subsystem.

6. Architectural Style: Pipe-and-filter
Example: Linux text processing
Output from one subsystem is the input of the next subsystem.
$ cat *.log | grep “Failure” >> /home/logs/failures.log | java parseFailures

7. Architectural Style: Pipe-and-filter
Advantages:
Simple: new combinations can be easily constructed
Reusable: filters are independent
Distributable: Byte streams can be sent across networks
Evolvable: Changing architectures/filter patterns is trivial
Disadvantages:
Data structures to be exchanged should be simple
Generally text
No interaction between filters

8. Architectural Style: Layered
Overview:
Each layer exposes an interface (API) to be used by the layer above/below.
Each layer acts as a
Server: service provider to layer “above”.
Client: service consumer of the layer “below”.

9. Architectural Style: Layered
Strict Layering
Non-strict Layering

10. Architectural Style: Layered
Example: Java
Processor
Operating
System
Java
Virtual Machine
Application
Java Virtual Machine

11. Architectural Style: Layered
Example: OSI Protocol Stack
Application
Transport
Network
Data Link
Physical
Application
Transport
Network
Data Link
Physical
Network
Data Link
Physical
Network
Data Link
Physical

12. Architectural Style: Layered
Advantages:
Decomposable: Effective separation of concerns
Maintainable: Changes that don’t affect layer interfaces are easier to make
Evolvable: Potential for adding new layers
Adaptable: Replace layers with new version as long as the
interface remains the same
Disadvantages:
Performance may degrade with too many layers
Can be difficult to cleanly assign functionality to the right layer

13. Architectural Style: Client/server
Overview:
Format for developing a distributed application that partitions tasks by:
Servers: provides access/interface to resources
Clients: requests access to specific resources
Typically, clients and servers communicate over a network and reside on separate hardware.

14. Architectural Style: Client/server
Example: system
Communication between client/server follows specific protocols.
HTTP, Sockets, etc.
In a peer-to-peer architecture, components can act as both client and server.

15. Architectural Style: Client/server
Example:

16. Architectural Style: Client/server
Advantages:
Centralized: Access to resources are controlled by the dedicated
server.
Scalable: Capacity of clients and servers can be increases
separately.
Maintainable: Distributed servers across multiple physical
machines allows for maintenance without
affecting customers.
Disadvantages:
Over utilization: large number of simultaneous clients requesting
similar resources.
Classic Client/Server architecture has low robustness. If the server (process or physical machine) is down, client requests can’t be met.

17. Architectural Style: Repository
Overview:
All data is managed in a central location that is accessible to all system components.
Components don’t interact directly, only through the repository.
The repository specifies the API for accessing and manipulating its data.

18. Architectural Style: Repository
Example:

19. Architectural Style: Repository
Advantages:
Modular: Components that access the repository don’t need to
know about other components.
Updateable: Changes to the repository made by one component
can be seen by all other components.
Manageable: All data can be maintained consistently since it’s
all in one place.
Disadvantages:
Single point of failure: problems with the repository affect the entire system.
Possible inefficiencies with organizing all system communication through the repository.
Possible difficulty with distributing the repository across several physical machines.

20. Architectural Style: Model/view/controller
Overview:
MVC – Architectural pattern to help separate the user interface from other parts of the system.
Goal: To reduce coupling between UI and the system.
Model:
Contains the underlying classes whose instances are to be viewed/manipulated.
View:
Renders the appearance of the data from the model in the UI.
Controller:
Contains the procedures that control and handle the user’s interaction with the view and the model.

21. Architectural Style: Model/view/controller
Example:
UI: displays states from the Model,
makes change requests to Controller
Resources provided by
The system.
Middleware between View and Model

22. Architectural Style: Model/view/controller
Advantages:
Different views/controllers can be used to provide multiple interfaces for the same model.
All views simultaneously reflect the current state of the model.
Easier to test core system components, as they have low coupling with the UI.
Disadvantages:
Possible increased complexity since other components of the system may use different architectural patterns.
View/Controller generally closely coupled. Modifying one affects the other.
Changes to the Model interface requires changes to the Controller and View.

23. Architectural Style: Buffering
Overview:
An application wants a continuous stream of data from a source that delivers data in bursts.
Software reads the bursts of data into a buffer
Application then reads data from the buffer

24. Architectural style: Buffering
EX: TCP
Flow and congestion control windows
(buffers) determine transmission rate.
TCP’s sliding window protocol
Uses a circular buffer that can grow/shrink dynamically.

25. Architectural style: Buffering
EX: Job Scheduling
Job requests from the UI are placed in a ready queue.
Jobs are processed in order as they are received by the ready queue.
FIFO
Priority queues

26. Architectural style: Buffering
Advantages:
Allows asynchronous requests from source applications for server resources.
Allows dynamic bandwidth allocation for moving data over a network.
Disadvantages:
Potential performance loss if a buffer size is static.
Buffer size too large: consumes unused resources, affects
performance of other software running on the
same physical machine.
Buffer size too small: affects performance of the software using the
buffer.