Architecture Design
Lecture 9
1Chapter 6 Architectural design
Topics covered
 Architecture design
 UML Packages (Analysis)
 UML Component Diagram (Design)
 UML Deployment Diagram (Realisation)
2Chapter 6 Architectural design
Architecture Design
Lecture 9/Part 1
3Chapter 6 Architectural design
Topics covered
 Architectural views
 Architectural design decisions
 Architectural patterns
 Application architectures
4Chapter 6 Architectural design
Architectural abstraction
 Architecture in the small (analysis) is concerned with
the architecture of individual programs. At this level, we
are concerned with the way that an individual program is
decomposed into components.
 Architecture in the large (design) is concerned with
the architecture of complex enterprise systems that
include other systems, programs, and program
components. These enterprise systems are distributed
over different computers, which may be owned and
managed by different companies.
5Chapter 6 Architectural design
4 + 1 view model of software architecture
6Chapter 6 Architectural design
Logical view shows the key
abstractionsin the system as
objectsor object classes.
Physical view shows
systemhardware and
how software components
are distributed across system
processors.
Process view shows how, at
run-time, the system is
composedof interacting
processes.
Use cases and
scenarios view
Development view
showshow the software
is decomposed for
development.
Architectural design decisions
 Architectural design is a creative process so the process
differs depending on the type of system being
developed.
 However, a number of common decisions span all
design processes and these decisions affect the nonfunctional
characteristics of the system.
7Chapter 6 Architectural design
Architectural design decisions
 How will the system be decomposed into modules?
 What approach will be used to structure the system?
 What architectural styles are appropriate?
 What control strategy should be used?
 Is there a generic application architecture that can
be used?
 How should the architecture be documented?
 How will the system be distributed?
 How will the architectural design be evaluated?
8Chapter 6 Architectural design
Architecture and system characteristics
 Performance
 Localise critical operations and minimise communications.
Use large rather than fine-grain components.
 Security
 Use a layered architecture with critical assets in the inner layers.
 Safety
 Localise safety-critical features in a small number of
components.
 Reliability and Availability
 Include redundant components and mechanisms for fault
tolerance.
 Maintainability
 Use fine-grain, replaceable components.
9Chapter 6 Architectural design
Architectural patterns
 Patterns are a means of representing, sharing and
reusing knowledge.
 An architectural pattern is a stylized description of good
design practice, which has been tried and tested in
different environments.
 Patterns should include information about when they are
and when the are not useful.
 Patterns may be represented using tabular and graphical
descriptions.
10Chapter 6 Architectural design
The Model-View-Controller(MVC) pattern
11Chapter 6 Architectural design
 Separates presentation and interaction from the system
data.
The Model-View-Controller(MVC) pattern
Name MVC (Model-View-Controller)
Description Separates presentation and interaction from the system data. The
system is structured into three logical components that interact with each
other. The Model component manages the system data and associated
operations on that data. The View component defines and manages how the
data is presented to the user. The Controller component manages user
interaction (e.g., key presses, mouse clicks, etc.) and passes these
interactionsto the View and the Model.
Example Figure on the next slide shows the architecture of a web-based application
system organized using the MVCpattern.
When used Used when there are multiple ways to view and interact with data. Also
used when the future requirements for interaction and presentation of data
are unknown.
Advantages Allows the data to change independently of its representation and vice
versa. Supports presentation of the same data in different ways with
changesmade in one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when the data model
and interactionsare simple.
12Chapter 6 Architectural design
Web application architecture using MVC
13Chapter 6 Architectural design
The Layered architecture pattern
 Organises the system into a set of layers with interfaces
to other layers. Supports incremental development.
14Chapter 6 Architectural design
The Layered architecture pattern
Name Layered architecture
Description Organizes the system into layers with related functionality
associated with each layer. A layer provides services to the
layer above it so the lowest-level layers represent core services
thatare likely to be used throughout the system.
Example A layered model of a system for sharing copyright documents
held in different libraries.
When used Used when building new facilities on top of existing systems;
when the development is spread across several teams with
each team responsibility for a layer of functionality; when
there is a requirement formulti-levelsecurity.
Advantages Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the
system.
Disadvantages In practice,providing a clean separationbetween layers is
often difficult and a high-levellayermay have to interact
directly with lower-levellayers ratherthan through the layer
immediatelybelow it. Performance can be a problem because
of multiple levels of interpretation ofa service request as it is
processed ateach layer.
15Chapter 6 Architectural design
The architecture of the LIBSYS system
16Chapter 6 Architectural design
The Repository architecture pattern
 When large amounts of data are to be shared among
subsystems, the repository model offers a solution.
17Chapter 6 Architectural design
The Repository architecture pattern
Name Repository
Description All data in a system is managed in a central repository that is
accessible to all system components. Components do not interact
directly,only through the repository.
Example Figure on the previous slide is an example of an IDE where the
components use a repository of system design information. Each
software tool generates information which is then available for use by
othertools.
When used You should use this pattern when you have a system in which large
volumes of information are generated that has to be stored for a
long time. You may also use it in data-driven systems where the
inclusion ofdata in the repositorytriggers an action or tool.
Advantages Components can be independent—they do not need to know of the
existence of other components. Changes made by one component can
be propagated to all components. All data can be managed
consistently (e.g., backups done at the same time) as it is all in one
place.
Disadvantages The repository is a single point of failure so problems in the
repository affect the whole system. May be inefficiencies in
organizing all communication through the repository. Distributing
the repository across several computers may be difficult.
18Chapter 6 Architectural design
The Client-server architecture pattern
 Distribution of data and processing across stand-alone
service-providing servers and clients calling the services.
19Chapter 6 Architectural design
The Client–server pattern
Name Client-server
Description In a client–server architecture, the functionality of the system is
organized into services, with each service delivered from a
separate server. Clients are users of these services and access
servers to make use of them.
Example Figure on the previous slide is an example of a film and video/DVD
library organized as a client–serversystem.
When used Used when data in a shared database has to be accessed from a
range of locations. Because servers can be replicated, may also
be used when the load on a system is variable.
Advantages The principal advantage of this model is that servers can be
distributed across a network. General functionality (e.g., a
printing service) can be available to all clients and does not need
to be implemented byall services.
Disadvantages Each service is a single point of failure so susceptible to denial of
service attacks or server failure. Performance may be
unpredictable because it depends on the network as well as the
system. May be management problems if servers are owned by
differentorganizations.
20Chapter 6 Architectural design
The Pipe and filter architecture pattern
 Functional transformations process their inputs to
produce outputs.
 Variants of this approach are very common. When
transformations are sequential, this is known as batch
sequential model used in data processing systems.
21Chapter 6 Architectural design
The Pipe and filter pattern
Name Pipe and filter
Description The processing of the data in a system is organized so that each
processing component (filter) is discrete and carries out one type of
data transformation. The data flows (as in a pipe) from one
component to anotherforprocessing.
Example Figure on the previous slide is an example of a pipe and filter system
used forprocessinginvoices.
When used Commonly used in data processing applications (both batch- and
transaction-based) where inputs are processed in separate stages to
generaterelated outputs.
Advantages Easy to understand and supports transformation reuse. Workflow style
matches the structure of many business processes. Evolution by
adding transformations is straightforward. Can be implemented as
eithera sequential orconcurrent system.
Disadvantages The format for data transfer has to be agreed upon between
communicating transformations. Each transformation must parse its
input and unparse its output to the agreed form. This increases
system overhead and may mean that it is impossible to reuse
functional transformationsthatuse incompatibledata structures.
22Chapter 6 Architectural design
Application architectures
 Application systems are designed to meet an
organisational need.
 As businesses have much in common, their
application systems also tend to have a common
architecture that reflects the application requirements.
 A generic application architecture is an architecture
for a type of software system that may be configured
and adapted to create a system that meets specific
requirements.
23Chapter 6 Architectural design
Examples of application types
 Data processing applications
 Data driven applications that process data in batches without
explicit user intervention during the processing.
 Transaction processing applications
 Data-centred applications that process user requests and update
information in a system database.
 Event processing systems
 Applications where system actions depend on interpreting
events from the system’s environment.
 Language processing systems
 Applications where the users’intentions are specified in a formal
language that is processed and interpreted by the system.
Chapter 6 Architectural design 24
The architecture of a transaction processing
application(ATM system) – a process view
25Chapter 6 Architectural design
What architectural view is this?
Layered architecture of a transaction
processing application (Information system)
26Chapter 6 Architectural design
What architectural view is this?
Pipe and filter architecture of a language
processing system (Compiler)
27Chapter 6 Architectural design
Repository architecture of a language
processing system
28Chapter 6 Architectural design
Key points
 A software architecture is a description of how a
software system is organized.
 Architectural design decisions include decisions on the
type of application, the distribution of the system, the
architectural styles to be used.
 Architectural patterns are a means of reusing
knowledge about generic system architectures. They
describe the architecture, explain when it may be used
and describe its advantages and disadvantages.
 Application systems architectures embody a common
architecture that the businesses have in common.
Chapter 6 Architectural design 29
© Clear View Training 2010 v2.6 30
UML Packages (Analysis)
Lecture 9/Part 2
© Clear View Training 2010 v2.6 31
Packages
 A package is a general purpose mechanism for
organising model elements into groups
 Group semantically related elements
 Define a “semantic boundary” in the model
 Provide units for parallel working and configuration management
 In UML 2 a package is a purely logical grouping
mechanism
 Use components for physical grouping
 Analysis packages contain:
 Analysis classes, analysis packages, use cases, use case
realizations.
© Clear View Training 2010 v2.6 32
Package syntax
Membership
+ClubMembership
+Benefits
+MembershipRules
+MemberDetails:Member
-JoiningRules
Membership
Membership:MemberDetails
Membership
ClubMembership
MembershipRules
BenefitsJoiningRules
MemberDetails
Member
«access»
public
(exported)
elements
private
element
qualified
package
name
accessed from
another package
• Use stereotypes to distinguish different package purposes.
© Clear View Training 2010 v2.6 33
Nested packages
 Each package defines an
encapsulatednamespace i.e.
all names must be unique
within the package
 If an element is visible within
a package then it is visible
within all nested packages
 e.g. Benefits is visible
within MemberDetails
 Show containment using
nesting or the containment
relationship
 Use «access» or «import» to
mergethe namespace of
nested packages with the
parent namespace
Membership
ClubMembership
MembershipRules
Benefits
JoiningRules
MemberDetails
Member
«import»
containmentrelationship
anchoricon
Membership
ClubMembership
MembershipRules
BenefitsJoiningRules
MemberDetails
Member
«import»
© Clear View Training 2010 v2.6 34
Package dependencies
Supplier «use» Client
Supplier «import» Client
Supplier «access» Client
Public elements of the supplier namespace are added as private
elements to the client namespace. Not transitive.
Public elements of the supplier namespace are added as public
elements to the client namespace. Transitive.
An element in the client uses an element in the supplier in
some way. The client depends on the supplier. Transitive.
«trace» usually represents a historical development of one
element into another more refined version. It is an extra-model
relationship. Transitive.
Analysis
Model
«trace» Design
Model
dependency semantics
C B A
transitivity - if dependencies x and y are transitive,
there is an implicit dependency between A and C
y x
© Clear View Training 2010 v2.6 35
Package generalisation
 The more specialised child
packages inherit the public and
protected elements in their parent
package
 Child packages may override
elements in the parent package.
Both Hotels and CarHire
packages override Product::Item
 Child packages may add new
elements. Hotels adds Hotel and
RoomType, CarHire adds Car
+Price
+Market
+Item
-MicroMarket
Product
+Product::Price
+Product::Market
+Item
+Hotel
+RoomType
Hotels
+Product::Price
+Product::Market
+Item
+Car
CarHire
children
parent
© Clear View Training 2010 v2.6 36
Architectural analysis
 This involves organising the analysis classes into a set
of cohesive packages
 The architecture should be partitioned to separate concerns,
such as to specific and application general layers
 Coupling between packages should be minimised
Products
Inventory
Management
Sales
Account
Management
application
specific layer
application
general layer
partitions
© Clear View Training 2010 v2.6 37
Finding analysis packages
 A cohesive group of closely related classes or a class hierarchy
 4 to 10 classes per package
 Minimise dependencies between packages
 Localise business processes in packages where possible
 Minimise nesting of packages
 Don’t worry about dependency stereotypes and package generalisation
 Refine package structure as analysis progresses
 Avoid cyclic dependencies!
A merge splitA B A B
C
© Clear View Training 2010 v2.6 38
Key points
 Packages are the UML way of grouping modeling
elements
 There are dependency and generalisation relationships
between packages
 The package structure of the analysis model defines the
logical system architecture
© Clear View Training 2010 v2.6 39
UML Component Diagram (Design)
Lecture 9/Part 3
© Clear View Training 2010 v2.6 40
Example of a (layered) architecture
«subsystem»
GUI
«subsystem»
Customer
«subsystem»
Order
«subsystem»
Product
«subsystem»
Accounts
«subsystem»
java.sql
«subsystem»
{global}
java.util
«subsystem»
javax.swing
Customer
Manager
Product
Manager
OrderManager
Account
Manager
presentation
business
logic
utility
© Clear View Training 2010 v2.6 41
What is a component?
 The UML 2.0 specification states that, "A component
represents a modular part of a system that
encapsulates its contents and whose manifestation is
replaceable within its environment"
 A black-box whose external behaviour is completely defined by
its provided and required interfaces
 May be substituted for by other components provided they all
support the same protocol
 Components can be:
 Physical – can be directly instantiated at run-time e.g. an
Enterprise JavaBean (EJB)
 Logical – a purely logical construct e.g. a subsystem
© Clear View Training 2010 v2.6 42
«delegate»
Component syntax
 Components may have provided and required interfaces,
ports, internal structure
 Provided and required interfaces usually delegate to internal parts
 You can show the parts nested inside the component icon or
externally, connected to it by dependency relationships
«component»
AI1 I2
provided
interface
required
interface
component
«component»
A
B C
I1
I2
I2
part
«delegate»
black box notation white box notation
I1
© Clear View Training 2010 v2.6 43
Provided interface syntax
 A provided interface indicates that a classifier
implements the services defined in an interface
CDBook
Borrow
«interface»
Borrow
borrow()
return()
isOverdue()
CDBook
“Lollipop” style notation
(note: you can’t show interface operations
or attributes with this notation)
“Class” style notation
interface
realization
relationship
© Clear View Training 2010 v2.6 44
Required interface syntax
 A required interface indicates that a classifier uses the
services defined by the interface
Borrow
Library
required interface
Borrow
Library
«interface»
Borrow
Library
class style notation lollipop style notation
© Clear View Training 2010 v2.6 45
Assembly connectors
 You can connect provided and required interfaces using
an assembly connector
Borrow
Book CD
Library
1 1
0..* 0..*
assembly
connector
© Clear View Training 2010 v2.6 46
Ports for organizing interfaces
 A port specifies an interaction point between a classifier
and its environment
 A port may have a name and is typed by its provided and
required interfaces:
 It is a semantically cohesive set of provided and required
interfaces
DisplayMedium
Print, Display
Book
presentation
port
Viewer
Book
presentation
© Clear View Training 2010 v2.6 47
Using interfaces
 Advantages:
 When we design with classes, we are designing to specific
implementations
 When we design with interfaces, we are instead designing to
contracts which may be realised by many different implementations
(classes)
 Designing to contracts frees our model from implementation
dependencies and thereby increases its flexibility and extensibility
 Disadvantages:
 Flexibility may lead to complexity
 Too many interfaces can make a system too flexible!
 Too many interfaces can make a system hard to understand
© Clear View Training 2010 v2.6 48
Key points
 Interfaces specify a named set of public features:
 They define a contract that classes and subsystems may realise
 Programming to interfaces rather than to classes reduces
dependencies between the classes and subsystems in our
model
 Programming to interfaces increases flexibility and extensibility
 Design subsystems and interfaces allow us to:
 Componentize our system
 Define an architecture
© Clear View Training 2010 v2.6 49
UML Deployment Diagram (Realisation)
Lecture 9/Part 4
© Clear View Training 2010 v2.6 50
Deployment model
 The deployment model models system’s physical architecture and
the mapping of the software architecture to the physical nodes
 Each node is a type of computational resource
 Nodes have relationships that represent methods of communication
 Artifacts represent physical software e.g. a JAR file or .exe file
«device»
WindowsPC
«execution environment»
IE6
«device»
LinuxPC
«execution environment»
Apache
0..* 0..*«http»
node
association
Descriptor
form model
© Clear View Training 2010 v2.6 51
Instance form model
 A node instance represents
an actual physical resource
 e.g. JimsPC:WindowsPC - node
instances have underlined names
«device»
JimsPC:WindowsPC
«execution environment»
:IE6
«device»
WebServer1:LinuxPC
«execution environment»
:Apache
node instance
«device»
IlasPC:WindowsPC
«execution environment»
:IE6
«http»
Instance
form model
© Clear View Training 2010 v2.6 52
1 1
Artifacts and components
 Artifacts and components
represent the software
deployed on physical nodes
 An artifacts represents a
concrete deployed real-world
thing, such as a file
 Artifacts = Physical level
 Artifacts provide the physical
manifestation for one or more
components
 Components = Logical level
«component»
Library
«component»
Book
«artifact»
librarySystem.jar
«manifest» «manifest»
«component»
Ticket
«manifest»
BookImpl
ISBN
1
LibraryImpl
TicketImpl
TicketID
1
Book Library Ticket
«artifact»
jdom.jar
depends
© Clear View Training 2010 v2.6 53
Example
 Artifacts are deployed on nodes, artifact instances are deployed on
node instances
deployment descriptor
artifact instance
«device»
client:WindowsPC
«device»
server:WindowsPC
«execution environment»
:J2EE Server
«RMI»
«JAR»
:ConverterApp.ear
«JAR»
:ConverterClient.jar
«deploymentspec»
converterDeploymentSpecification
EnterpriseBeanClass: ConverterBean
EnterpriseBeanName: ConverterBean
EnterpriseBeanType: StatelessSession
© Clear View Training 2010 v2.6 54
Key points
 The descriptor form deployment diagram
 Allows you to show how functionality represented by artifacts is
distributed across nodes
 Nodes represent types of physical hardware or execution
environments
 The instance form deployment diagram
 Allows you to show how functionality represented by artifact
instances is distributed across node instances
 Node instances represent actual physical hardware or execution
environments