1

Lecture 11
UML architecture
Ayesha Kanwal
SEECS
 Software Architecture
2

 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.
 Design stable architecture
5

 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
 Developing an architectural model
6

 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
 Developing an architectural model
7

 Refine the architecture

 Identifythe 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
 Describing an architecture using
8 UML
 All UML diagrams can be useful to
describe aspects of
the architectural model
 Three UML diagrams are particularly
suitable for architecture modelling:
 Packagediagrams
 Component diagrams
 Deployment diagrams
 Package diagrams
9

 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;
 Decreasing coupling means
 decreasing the number of dependencies as much
as possible
 Package diagrams
10

 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
Package Diagram - Dependency
Notation

<<import>> - one package imports the functionality of other

package

<<access>> - one package requires help from functions of

other package.
 Component diagrams
1
1

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
UML Component diagrams are used in modeling the physical
aspects of object-oriented systems that are used for
visualizing, specifying, and documenting component-based
systems and also for constructing executable systems
through forward and reverse engineering

A component diagram breaks down the actual system under

development into various high levels of functionality. Each
component is responsible for one clear aim within the entire
system and only interacts with other essential elements on a
need-to-know basis.
 Deployment diagrams
12

 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
 Architecture vs. Design
13

 “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.
 Software Architecture Views
14

 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
 viewpointexists to describe the
architecture from the perspective of a
given set of stakeholders and their
concerns.
 Viewpoints/Representations
15

 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
 Viewpoints/Representations
16

Example: Building a house

Useful viewpoints:
 the architect’s viewpoint (plan

views, elevations, etc)

 the plumber’s viewpoint (routing

diagrams
for pipework, fittings layouts, etc)
 the electrician’s viewpoint (wiring

diagrams, etc)
 the buyer’s viewpoint (artist’s impression,

floorplans, etc)
etc…
4+1 View Model of
Architecture

End user Development Programmers

Logical view & software
view
managers

Use case

Process View Physical View

Integrator System Engineer

 Software Architecture Views
18

 Logical view
 Process view
 Physical view
 Development
view
 Use case view
19

 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
 Logical View
20

 This describes the architecturally significant

elements of
the architecture and the relationships between
them.
 The logical view essentially captures the
structure of the application.
 The logical view is concerned with the
functionality that
the system provides to end-users.
 UML Diagrams used to represent the logical
view include
 Class diagram,
 Communication diagram,
 Development View
2
1
 This captures the internal organization components,
typically as they are held environment.

 Forexample, the depiction of a nested package and class

hierarchy for a Java application would represent the
development view of an architecture.
 The development view 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
 Process View
22

 This focuses on describingthe 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.
 Physical View
23

 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