CHAPTER 3: PRINCIPLES OF SOFTWARE ARCHITECTURE

SESSION III: DESIGNING THE

ARCHITECTURE
Software Engineering Design: Theory and
Practice
by Carlos E. Otero For non-profit educational
use only
Slides copyright © 2012 by
Carlos E. Otero

May be reproduced only for student use when used in conjunction

with Software Engineering Design: Theory and Practice. Any
other reproduction or use is prohibited without the express written
permission of the author.

All copyright information must appear if these slides are posted on

a website for student use.

Software Engineering Design: 10/3/2012 1

Theory and Practice
 SESSION’S AGENDA

 Designing the Architecture with the 4+1view model

 Designing the logical architecture

 Example using a component diagram

 Designing the process architecture

 Example using a communication diagram

 Designing the development architecture

 Example using artifacts

 Designing the physical architecture

 Example using deployment diagrams

 What’s next..

Software Engineering Design: 10/3/2012 2

Theory and Practice
 DESIGNING THE
ARCHITECTURE
 As discussed before, designing architectures require the selection of particular
perspectives for design that are appropriate for describing the system to be
developed.
 To this end, several model have been created that suggest popular views that are useful
in the design of most systems.
 These models propose addressing the system’s architectural design from perspectives
that are common to most software systems.
 They provide a systematic and disciplined approach to architecture creation.
 Two popular models are the 4+1 view model and Siemens' 4 views model.

 The 4+1 View Model

 Concentrates on four main views:
 Logical, process, development, and physical
 To ensure consistency among all 4 views, the user’s perspective is captured through
several use cases, as part of the user view.
 4+1 is used as the basis for the popular rational unified process

Software Engineering Design: 10/3/2012 3

Theory and Practice
 DESIGNING THE LOGICAL
ARCHITECTURE
 The logical view is used to decompose systems into logical
components that represent the structural integrity that supports
functional and non- functional requirements. The logical view can be
modeled using:
 Component diagrams
 Class diagrams
 Box-and-line diagrams

 Using this view the static structure of the system, including components,
interfaces, and their associations are modeled. This view is appropriate
for:
 Designing for portability
 Designing maintainability (maintaining existing features)
 Designing for extensibility (adding new features)
 Designing for reusability
 Resource allocation, project structuring and planning
Software Engineering Design: 10/3/2012 4
Theory and Practice
 DESIGNING THE LOGICAL ARCHITECTURE

Video controller communicates with the No interface defined! Direct association suggests
actual
video collection hardware to these
that components are tightly f re
coupled, there it more difficult to o making
cmp Component Diagram Example
command it! ter
modify the system l on!
a
«subsystem»
ClientCollectionSystem

«delegate»

IVideoControl IVideoControl VideoController

S iteController
IEnviromentData IEnvironmentData c mmunicates
«delegate»
o the
with
«delegate»
ISensorControl ISensorControl
SensorsController SiteController world.
outside It
ISchedule «delegate» requires
a schedule
ISchedule
provides
and
IController collected
data
.
Sensor
communicates
controller with UserInterface
actual
the Sensor
hardware to
command it!

Important: Well-defined interface! This allows different

This process is recursive, i.e., user interfaces to be exchangeable easier,
each component can be further e.g., from console-to graphical user
decomposed! interface-based. on!

Software Engineering Design: 10/3/2012 5

Theory and Practice
 DESIGNING THE PROCESS ARCHITECTURE

 The process view is used to represent the dynamic or behavioral aspects

of software systems, where the main units of analysis are processes and
threads.
 With this view, the system is decomposed into processes and threads to address
design issues that deal with the dynamic flow of control between architectural
elements.

 The process view can be modeled with UML using:

 Sequence diagrams
 Communication diagrams

 This view is appropriate for evaluating important characteristics of the

system, such as concurrency, fault tolerance, and the system’s integrity.
Specific quality attributes that can be evaluated with this view
include:
 Performance
 Availability

Software Engineering Design: 10/3/2012 6

Theory and Practice
 DESIGNING THE PROCESS
ARCHITECTURE
Based on the received
message, the
SiteManager stops
data collection using
the video camara.
<<thread>>
Threads in the m3: VideoManager
The Communication
system using
Manager executes
asynchronous
under the
communication SiteManager’s context
4. stopCollection ()

1. receiveMsg(msg)
<<thread>> <<thread>> comm: CommMgr
m2: SensorMgr m1: SiteManager

2. sendMsg(ACK)
4. startCollection ()

3. update(msg)

uiManager : Observer

The SiteManager uses the CommMgr to receive a

Based on the received
message. After receipt, the SiteManager
message, the
SiteManager initiates sends an immediate ACK response, to
data collection using indicate that the message is received.. After
the sensors. that, it updates the user interface to display the
receipt of the message.

Software Engineering Design: 10/3/2012 7

Theory and Practice
 DESIGNING THE DEVELOPMENT
ARCHITECTURE
 The development view of software systems represents the
software development configuration aspects of the software
system.
 The main units of decomposition are actual physical files and
directories.

 This view can be used to analyze the system from the perspective of
how logical components map to physical files and directories.
 These analyses can be employed to address concerns that deal with:
 Ease of development
 Reusability
 Compile-time dependencies of the system
 Configuration management
 Allocation of work to teams
 Cost evaluation and planning
 Project monitoring
 Portability
Software Engineering Design: 10/3/2012 8
Theory and Practice
 DESIGNING THE DEVELOPMENT
ARCHITECTURE
Notice how versions
Version change with the Version
1.0 addition of new 2.0
functionality!

Version 1 of
the
SiteManager
Version 2 of
the
SiteManager
Version 2.0 is used by a specific
Version 1.0 is used by a specific customer that requires video
customer that does not require video capture capabilities.
capture capabilities.

Software Engineering Design: 10/3/2012 9

Theory and Practice
 DESIGNING THE PHYSICAL
ARCHITECTURE

 The physical view represents the deployment aspects of

software systems.
 The main elements of analysis are nodes, connections between
nodes, and the mapping of artifacts to these nodes.
 This view can be used to model the run-time dependencies of the
system.

 The physical view can be modeled in UML using:

 Deployment diagrams

 The physical view is appropriate to evaluate the system’s:

 Availability
 For example, specifying the need for redundant nodes to increase the
system’s availability
 Performance
 For example, required processor speed, bandwidth, etc. to meet
performance requirements.
Software Engineering Design: 10/3/2012 10

Theory and Practice
Scalability
 DESIGNING THE PHYSICAL ARCHITECTURE

Software Engineering Design: Theory and

10/3/2012 11
Practice
 EXAMPLE OF PARTIAL ARCHITECTURE OF
CLIENT COLLECTION SYSTEM
Logical View Development View

User View

Process View Physical View

Software Engineering Design: 10/3/2012 12

Theory and Practice
 ONE LAST NOTE…

 Do NOT make the assumption that a particular UML classifier belongs exclusively to a
particular view of the 4+1 model!!
 Although some classifiers are certainly “the main characters” in particular views, they can
serve as “supporting characters in other views.”
 For example, components are used mostly in the logical view, BUT,
 They can also be used in the physical view to model how they are manifested by artifacts!

 UML Artifacts are tricky, because they can be used as the dominant design unit (i.e.,
“main character”) in both development and physical view:
 In the physical view, they model deployment artifacts.
 These are artifacts necessary to form an executable system (e.g., .dll, .jar, .class, .ini file,
etc.)
 These are essential to model the run-time dependencies of the system (e.g., .NET 4.1)
 In the development view, they model work product artifacts
 These are artifacts used to create deployment artifacts, i.e., they are necessary to build
the software (e.g., source code files [.h, .cpp, .java], data files])
 These artifacts do not directly exist in the physically deployed system; they are the
work products of development used to build the system.
 These are essential to model the compile-time dependencies to build the system as well
as versioning and configuration management of the system.

 Keep in mind that when using UML artifacts, modeling occurs in the physical dimension,
which can be addressed in both development and physical views of the 4+1 model. Artifacts do
not exist in the logical dimension, as opposed to other UML classifiers, such as components.

Software Engineering Design: 10/3/2012 13

Theory and Practice
 WHAT’S NEXT…
 In this session, we presented the 4+1 view model for designing
software architectures, which includes
 Logical view
 Development View
 Process View
 Physical View
 User View

 In the next module, we’ll delve deep into popular patterns and styles
used to model logical architectures; these are presented for the following
types of systems:
 Data-centered
 Data flow
 Distributed
 Interactive
 Hierarchical

Software Engineering Design: 10/3/2012 14

Theory and Practice