OBJECT ORIENTED

SOFTWARE
DEVELOPMENT
Subash Manandhar

1
Chapter 4 – Software Architecture
4.1 Introduction to Software Architecture
• Software architecture is the process of converting software
characteristics such as flexibility, scalability, feasibility, reusability, and
security into a structured solution that meets the technical and the
business expectations.
• Software architecture is the process of designing the global organization
of a software system, including dividing software into subsystems,
deciding how these will interact, and determining their interfaces.
• The architecture is the core of the design, so all software engineers need
to understand it.
• The architectural model will often constrain the overall efficiency,
reusability and maintainability of the system.
• Poor decisions made while creating this model will constrain subsequent
design.

Subash Manandhar 2
Chapter 4 – Software Architecture
4.1 Introduction to Software Architecture
• Reasons needed to develop software architectural model
• To enable everyone to better understand the system
• A good architectural model allows people to understand how the system
as a whole works; it also defines the terms that people use when they
communicate with each other about lower-level details.
• To allow people to work on individual pieces of the system in isolation
• The architecture allows the planning and coordination of this distributed
work.
• The architecture should provide sufficient information so that the work
of the individual people or teams can later on be integrated to form the
final system.
• It is for that reason that the interfaces and dynamic interactions among
the subsystems are an important part of the architecture.

Subash Manandhar 3
Chapter 4 – Software Architecture
4.1 Introduction to Software Architecture
• Reasons needed to develop software architectural model
• To prepare for extension of the system
• With a complete architectural model, it becomes easier to plan the evolution of
the system.
• Subsystems that are envisioned to be part of a future release can be included in
the architecture, even though they are not to be developed immediately.
• It is then possible to see how the new elements will be integrated, and where
they will be connected to the system.
• To facilitate reuse and reusability
• The architectural model makes each system component visible.
• This is an important benefit since it encourages reuse.
• By analyzing the architecture, identify components that have high potential
reusability.
• Making the architecture as generic as possible is a key to ensuring reusability.

Subash Manandhar 4
Chapter 4 – Software Architecture
4.1 Introduction to Software Architecture
• Contents of good architectural model
• An important challenge in architectural modeling is to produce a relevant and
synthetic picture of a large and complex system.
• To ensure the maintainability and reliability of a system, an architectural model
must be designed to be stable.
• The architecture should be expressed clearly enough that it can be used to
communicate effectively with clients.
• A system’s architecture will often be expressed in terms of several different
views. These can include:
• The logical breakdown into subsystems
• The interfaces among the subsystems
• The dynamics of the interaction among components at run time
• The data that will be shared among the subsystems
• The components that will exist at run time, and the machines or devices on
which they will be located

Subash Manandhar 5
Chapter 4 – Software Architecture
4.1 Introduction to Software Architecture
• Developing an architectural model
• Start by sketching an outline of the architecture
• Based on the principal requirements and use cases
• Determine the main components that will be needed
• Choose among the various architectural patterns
• Suggestion: have several different teams independently develop a first draft of the
architecture and merge together the best ideas
• Refine the architecture
• Identify the main ways in which the components will interact and the interfaces
between them
• Decide how each piece of data and functionality will be distributed among the various
components
• Determine if you can re-use an existing framework, if you can build a framework
• Consider each use case and adjust the architecture to make it realizable
• Mature the architecture

Subash Manandhar 6
Chapter 4 – Software Architecture
4.2 Architecture Centric Process
• Aspects of an architecture include static elements, dynamic elements,
how those elements work together, and the overall architectural style
that guides the organization of the system.
• Architecture also addresses issues such as performance, scalability, reuse,
and economic and technological constraints.
• The Unified Process specifies that the architecture of the system being
built, as the fundamental foundation on which that system will rest, must
sit at the heart of project team’s efforts to shape the system.
• Need of architecture centric:
• Understanding the big picture
• Organizing development effort
• Facilitating the possibilities for reuse
• Guiding the use cases
• Evolving the system

Subash Manandhar 7
Chapter 4 – Software Architecture
4.2 Architecture Centric Process
• Describing an architecture using UML
• All UML diagrams can be useful to describe aspects of the architectural
model
• Four UML diagrams are particularly suitable for architecture modelling:
• Package diagrams
• Subsystem diagrams
• Component diagrams
• Deployment diagrams

Subash Manandhar 8
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• An architectural pattern is a general, reusable solution to a
commonly occurring problem in software architecture within a
given context.
• Architectural patterns are similar to software design pattern but
have a broader scope.
• Allows you to design flexible systems using components where the
components are as independent of each other as possible.

Subash Manandhar 9
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.1 Multi-Layer architectural pattern
• In layered systems each layer communicates only with the layers below it .
• Each layer has a well-defined API, defining the services it provides.
• A complex system can be built by superimposing layers at increasing levels
of abstraction.
• The Multi-Layer architectural pattern makes it possible to replace a layer by
an improved version, or one with a different set of capabilities.
• It is important to have a separate layer for the UI.
• Layers immediately below the UI layer provide the application functions
determined by the use-cases.
• Bottom layers provide general services.

Subash Manandhar 10
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.1 Multi-Layer architectural pattern
• The most commonly found 4 layers of a general information system are as
follows.
• Presentation layer (also known as UI layer)
• Application layer (also known as service layer)
• Business logic layer (also known as domain layer)
• Data access layer (also known as persistence layer)
• Usage:
• General desktop applications.
• E commerce web applications.

Subash Manandhar 11
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.1 Multi-Layer architectural pattern
• The Multi-Layer architectural pattern and design principles:
• 1. Divide and conquer: The layers can be independently designed.
• 2. Increase cohesion: Well-designed layers have layer cohesion.
• 3. Reduce coupling: Well-designed lower layers do not know about the
higher layers and the only connection between layers is through the API.
• 4. Increase abstraction: you do not need to know the details of how the
lower layers are implemented.
• 5. Increase reusability: The lower layers can often be designed generically.
• 6. Increase reuse: You can often reuse layers built by others that provide
the services you need.

Subash Manandhar 12
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.1 Multi-Layer architectural pattern
• The Multi-Layer architectural pattern and design principles:
• 7. Increase flexibility: you can add new facilities built on lower-level
services, or replace higher-level layers.
• 8. Anticipate obsolescence: By isolating components in separate layers, the
system becomes more resistant to obsolescence.
• 9. Design for portability: All the dependent facilities can be isolated in one
of the lower layers.
• 10. Design for testability: Layers can be tested independently.
• 11. Design defensively: The APIs of layers are natural places to build in
rigorous assertion-checking.

Subash Manandhar 13
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.1 Multi-Layer architectural pattern

Subash Manandhar 14
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.2 The Client/Server and other distributed architectural patterns
• This pattern consists of two parties; a server and multiple clients.
• The server component will provide services to multiple client components.
• Clients request services from the server and the server provides relevant
services to those clients.
• Furthermore, the server continues to listen to client requests.
• 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.
• A further extension is the Peer-to-Peer pattern.
• A system composed of various software components that are distributed over
several hosts.

Subash Manandhar 15
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.2 The Client/Server and other distributed architectural patterns
• Usage
• Online applications such as email, document sharing and banking.
• The Distributed architecture and design principles
• 1. Divide and conquer: Dividing the system into client and server processes
is a strong way to divide the system.
• Each can be separately developed.
• 2. Increase cohesion: The server can provide a cohesive service to clients.
• 3. Reduce coupling: There is usually only one communication channel
exchanging simple messages.
• 4. Increase abstraction: Separate distributed components are often good
abstractions.

Subash Manandhar 16
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.2 The Client/Server and other distributed architectural patterns
• The Distributed architecture and design principles
• 6. Increase reuse: It is often possible to find suitable frameworks on which
to build good distributed systems
• However, client-server systems are often very application specific.
• 7. Design for flexibility: Distributed systems can often be easily
reconfigured by adding extra servers or clients.
• 9. Design for portability: You can write clients for new platforms without
having to port the server.
• 10. Design for testability: You can test clients and servers independently.
• 11. Design defensively: You can put rigorous checks in the message
handling code.

Subash Manandhar 17
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.2 The Client/Server and other distributed architectural patterns

Subash Manandhar 18
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.3 The Model View Controller Architectural Patterns
• This pattern, also known as MVC pattern, divides an interactive application
in to 3 parts as,
• model — contains the core functionality and data, contains the underlying classes
whose instances are to be viewed and manipulated.
• view — displays the information to the user (more than one view may be
defined), contains objects used to render the appearance of the data from the
model in the user interface.
• controller — handles the input from the user, contains the objects that control
and handle the user’s interaction with the view and the model.
• This is done to separate internal representations of information from the
ways information is presented to, and accepted from, the user. It
decouples components and allows efficient code reuse.
• Usage
• Architecture for World Wide Web applications in major programming languages.
• Web frameworks such as Django and Rails.

Subash Manandhar 19
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.3 The Model View Controller Architectural Patterns
• The MVC architecture and design principles
• 1. Divide and conquer: The three components can be somewhat
independently designed.
• 2. Increase cohesion: The components have stronger layer cohesion than if
the view and controller were together in a single UI layer.
• 3. Reduce coupling: The communication channels between the three
components are minimal.
• 6. Increase reuse: The view and controller normally make extensive use of
reusable components for various kinds of UI controls.
• 7. Design for flexibility: It is usually quite easy to change the UI by changing
the view, the controller, or both.
• 10. Design for testability: You can test the application separately from the UI.
Subash Manandhar 20
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.3 The Model View Controller Architectural Patterns

Subash Manandhar 21
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.3 The Model View Controller Architectural Patterns
• Example of MVC in web architecture
• The View component generates the HTML code to be displayed by the
browser.
• The Controller is the component that interprets ‘HTTP post’ transmissions
coming back from the browser.
• The Model is the underlying system that manages the information.

Subash Manandhar 22
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Service Oriented Architectural Patterns
• This architecture organizes an application as a collection of services that
communicate with each other through 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, which can
be integrated with other services to form a complete system
• The different components generally communicate with each other using
open standards such as XML.
• Web services can perform a wide range of tasks.
• Some may handle simple requests for information while others can
perform more complex business processing.
• Enterprises can use Web services to automate and improve their
operations.

Subash Manandhar 23
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Service Oriented Architectural Patterns
• For example, an electronic commerce application can make use of web
services to:
• access the product databases of several suppliers;
• process credit cards using a Web service offered by a bank;
• arrange for delivery using a Web service offered by a shipping company.
• The toughest challenge facing the developer of a Web service is security.
• Other important considerations are reliability, availability and scalability of
the Web service.

Subash Manandhar 24
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Service Oriented Architectural Patterns
• The Service Oriented Architecture and design principles
• 1. Divide and conquer: The application is made of independently designed
services.
• 2. Increase cohesion: The Web services are structured as layers and
generally have good functional cohesion.
• 3. Reduce coupling: Web-based applications are loosely coupled built by
binding together distributed components.
• 5. Increase reusability: A Web service is a highly reusable component.

Subash Manandhar 25
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Service Oriented Architectural Patterns
• The Service Oriented Architecture and design principles
• 6. Increase reuse: Web-based applications are built by reusing existing
Web services.
• 8. Anticipate obsolescence: Obsolete services can be replaced by new
implementation without impacting the applications that use them.
• 9. Design for portability: A service can be implemented on any platform
that supports the required standards.
• 10. Design for testability: Each service can be tested independently.
• 11. Design defensively: Web services enforce defensive design since
different applications can access the service.

Subash Manandhar 26
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Service Oriented Architectural Patterns

Subash Manandhar 27
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Message Oriented Architectural Patterns
• Also known as Message-oriented Middleware (MOM).
• This architecture is based on the idea that since humans can communicate and
collaborate to accomplish some task by exchanging emails or instant
messages, then software applications should also be able to operate in a
similar manner i.e. the different sub-systems communicate and collaborate to
accomplish some task only by exchanging messages.
• 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)

Subash Manandhar 28
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Message Oriented Architectural Patterns
• The application can choose to ignore a received message or react to it by,
for instance, sending a reply containing requested information.
• The exchange of these messages is governed by two important principles.
• First, message delivery is completely asynchronous; that means the exact
moment at which a given message is delivered to a given subscribing
application is unknown.
• Secondly, reliability mechanisms are in place such that the messaging
system can offer the guarantee that a given message is delivered once and
only once.
• Text messaging using cellular phones can be seen as a simple message
oriented application, but more complex systems can also adopt this
architecture.

Subash Manandhar 29
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Message Oriented Architectural Patterns
• Clearly, the effectiveness of system depends on the messaging system that
is used to deliver the messages.
• Two approaches can be taken when designing such a system.
• The first is to use a centralized architecture where all messages transit
through a message server that is responsible for delivering messages to
the subscribers.
• This is the simpler model, but all functionality then relies on the server.
• The alternative is to use a decentralized architecture where message
routing is delegated to the network layer and where some of the server
functionality is distributed among all message clients.

Subash Manandhar 30
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Message Oriented Architectural Patterns
• The Message Oriented Architecture and design principles
• 1. Divide and conquer: The application is made of isolated software
components.
• 3. Reduce coupling: The components are loosely coupled since they share
only data format.
• 4. Increase abstraction: The prescribed formats of the messages are
generally simple to manipulate, all the application details being hidden
behind the messaging system.
• 5. Increase reusability: A component will be reusable is the message
formats are flexible enough.

Subash Manandhar 31
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.4 The Message Oriented Architectural Patterns
• The Message Oriented Architecture and design principles
• 6. Increase reuse: The components can be reused as long as the new
system adheres to the proposed message formats.
• 7. Design for flexibility: The functionality of a message-oriented system
can be easily updated or enhanced by adding or replacing components in
the system.
• 10. Design for testability: Each component can be tested independently.
• 11. Design defensively: Defensive design consists simply of validating all
received messages before processing them.

Subash Manandhar 32
Chapter 4 – Software Architecture
4.3 Architectural Patterns
• 4.3.5 The Message Oriented Architectural Patterns

Subash Manandhar 33