SOFTWARE ARCHITECTURE

1
LEARNING OBJECTIVES

 Learn Software architectures for high-level design

 Learn Software architectural pattern or styles

2
SOFTWARE ARCHITECTURE

 Software architecture is process of designing the global

organization of a software system, including:
 Dividing software into subsystems.
 Deciding how these will interact.
 Determining their interfaces.
 The architecture is the core of the design, so all software engineers need to
understand it.
 The architecture will often constrain the overall efficiency, reusability and
maintainability of the system.

3
THE IMPORTANCE OF SOFTWARE
ARCHITECTURE

 Why you need to develop an architectural model:

 To enable everyone to better understand the system
 To allow people to work on individual pieces of the system in
isolation
 To prepare for extension of the system
 To facilitate reuse and reusability

4
 CONTENTS OF A GOOD ARCHITECTURAL
MODEL

 A system’s architecture will often be expressed in terms of

several different views
 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

5
DESIGN STABLE ARCHITECTURE

 To ensure the maintainability and reliability of a system, an

architectural model must be designed to be stable.
 Being stable means that the new features can be easily added with
only small changes to the architecture

6
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
 Discussed next

 Suggestion: have several different teams independently develop a first

draft of the architecture and merge together the best ideas

7
DEVELOPING AN ARCHITECTURAL MODEL
 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
8
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

9
 PACKAGE DIAGRAMS
 In UML, a package is a
 collection of modeling elements that are grouped together because they are logically related.
 A package in UML is shown as a box, with a smaller box attached above its top left
corner

 Apply the principles of cohesion and coupling

 Increasing cohesion means
 ensuring that a package only has related classes;
10
 Decreasing coupling means
 decreasing the number of dependencies as much as possible
PACKAGE DIAGRAMS

 You show dependencies between packages using a dashed

arrow
 A package that depends on many others will be difficult to
reuse, since using it will also necessitate importing its
dependent packages.
 Finally, making the interface of a package as simple as
possible greatly simplifies its use and testing

11
COMPONENT DIAGRAMS

 The package diagrams show logical groupings of design elements, whereas

component diagrams show relationships among types of physical
components such as files, executables.
 The UML symbol for a component is a box with a little ‘plug’ symbol in the
top-right corner

 To show a component using an interface provided by another, you use a

semi-circle at the end of a line
12
DEPLOYMENT DIAGRAMS

 A deployment diagram describes the hardware where various instances

of components reside at run time.

 A node in a deployment diagram represents a computational unit such as

a computer, a processing card, a sensor or a device.
 It appears as a three-dimensional box.
 The links between nodes show how communication takes place

13
ARCHITECTURE VS. DESIGN

 “All architecture is design, not all design is architecture”.

 Architectural design is outward looking
 Focus on stakeholders, not technology

 Architecture more fluid than design

 Context, scope, success criteria all unclear

 Architecture doesn't describe the complete characteristics of

components – Design does.
 It is hard to refactor architectural decision
14
SOFTWARE ARCHITECTURE VIEWS

 Software architecture is commonly organized in views,

which are analogous to the different types of blueprints made
in building architecture.

 Views are instances of viewpoints, where a

 viewpoint exists to describe the architecture from the perspective of a
given set of stakeholders and their concerns.

15
VIEWPOINTS/REPRESENTATIONS

 Viewpoints help in creating abstractions

 A viewpoint tells you which details you can ignore
when forming an abstraction
 It defines which details are relevant and which are not
 Viewpoints can overlap
 Some aspects of a design are common to several viewpoints

16
VIEWPOINTS/REPRESENTATIONS

Example: Building a house

Useful viewpoints:
 Architect’s viewpoint (plan views, elevations, etc)
 Plumber’s viewpoint (routing diagrams for pipework, fittings
layouts, etc)
 Electrician’s viewpoint (wiring diagrams, etc)
 Buyer’s viewpoint (artist’s impression, floorplans, etc)
etc…
18
4+1 VIEW MODEL OF ARCHITECTURE

End user Development Programmers

Logical view & software
view
managers

Use case

Process View Physical View

Integrator System Engineer

19
SOFTWARE ARCHITECTURE VIEWS

 Logical view
 Process view
 Physical (devep) view
 Development (imp +design) view

20
USE CASE VIEW

 Use-case view:
 Describes functionality of the system, its external
interfaces, and its principal users.
 This view is mandatory when using the 4+1 Views,
because all elements of the architecture should be derived
from requirements

21
 LOGICAL VIEW

 Describes architecturally significant elements of the architecture

and the relationships between them.
 Essentially captures the structure of the application.
 Concerned with the functionality that the system provides to
end-users.
 UML Diagrams used to represent the logical view include
 Class diagram,
 Communication diagram,
 Sequence diagram.
22
 DEVELOPMENT VIEW
 This captures the internal organization of the software
components, typically as they are held in a development
environment
 For example, the depiction of a nested package and class hierarchy for a
Java application would represent the development view of an architecture
 Illustrates a system from a programmer's perspective
 This view is also known as the implementation view
 It uses the UML Component diagram to describe system
components
 UML Diagrams used to represent the development view include
23

the Package diagram

PROCESS VIEW

 This focuses on describing the concurrency and

communications elements of an architecture.
 The process view deals with the dynamic aspects of the
system,
 explains the system processes and how they communicate, and
focuses on the runtime behavior of the system
 UML Diagrams to represent process view include the Activity
diagram.

24
 PHYSICAL VIEW

 This depicts how the major processes and components are mapped on to
the applications hardware.
 The physical view depicts the system from a system engineer's point-of-
view
 It might show, for example, how the database and web servers for an application
are distributed across a number of server machines.
 It is concerned with the physical connections between these components.
 This view is also known as the deployment view.
 UML Diagrams used to represent physical view include the Deployment
diagram.
25
REFERENCE

 Object-Oriented Software Engineering: Practical Software Development using

UML and Java by Timothy C. Lethbridge and Robert Laganière, 2004.

26