Chapter 3

Models for Software Architecture

 Objectives

 Introduce concepts of the view models of

software architecture
 Discuss the UML notations as modeling
tools for software architecture specification
 Agenda
• Overview
• 4+1 View Model
• UML for Software Architecture
– Structural Diagrams
– Behavioral Diagrams
 Overview
• Software architecture
– a high-level of abstraction of a software system by
employing decomposition, composition, architectural
styles, and quality attributes.
– Describe the collection of
• Components
• Connections
• Interactions between these components.
– Also specify the deployment configuration of all
components and connections.
– Its design must conform to the functional and non-
functional requirements of the software project.
 Overview (cont)
• Many effective ways to describe a
software architecture
– formally
– informally.
• To Describe the business concepts and
processes:
– Box-and-line diagrams are often used.
• Descriptions of components and connectors
– Provide clarify understanding ( intuitive interpretation ).
 UML for Software Architecture
• With a software-intensive system, the Unified Modeling
Language (UML) is
– Is a graphical language for
• visualizing
• specifying
• constructing
• documenting the artifacts
– Offer a standard way to draw a system’s design ( system’s
blueprints ),
– Including conceptual notions such as
• Business processes
• System functions
• Concrete designs such as
– programming language statements,
– database schemas, and
– reusable software components.
 UML
• a typical OO analysis and design notational tool
– provides many useful diagrams
• used to map requirement specifications to architectural
designs
• UML diagram could be group into 2 major
categories:
– Structural (static)
• Class diagram, component diagram, deployment diagram,
etc.
– Behavioral (dynamic)
• sequence diagram, collaboration diagram, activity diagram, etc.
– With object collaboration, interaction, activity, and concurrency notation.
 Class Diagram
• Provides a static view of the system.
– Captures the vocabulary of the designed system.
• Is a foundation diagram and most frequently
used.
• Derived from
– Use case diagrams
– Text analysis on the given problem domain.
• System analysts and system designers will
created it and iteratively refined
 Class Diagram
• Describe each individual class with its type,
interface, properties, and methods.
• Also specify : the accessibility (visibility) of each
attribute and operation.
– Popular accessibility modifiers
• Private
• Public
• Protected
• Default
• A class interface ( method(s) )
– Provides the behaviors the class support.
• Relationships among classes:
– Inheritance
– Aggregation
– Association
• For each relationship, multiplicities between classes can
be denoted
– one to one
– one to many
– many to many mappings.
• In UML, multiplicity notations
– 1 = one instance
– 0 = no instance
– 0..1 -> zero or one instance
– 1..* -> at least one instance.
 Object Diagram
• Objects are the instances of classes.
• Describe a sample subset of objects in the system at a
point of time.
• Shows a snapshot of class instance connection and
interaction.
• Derived from the corresponding class diagram and is a
concrete example of the class diagram at runtime.
• Below behavioral diagrams can make references to the
object diagram.
– sequence diagram
– communication diagram
– interaction diagram
 Item line#1
#1234 order
customer #123 3
new

item line#2 book

3

gift
 Composite Structure Diagram
• Used to describe the composition of
– Interconnected elements
– The collaboration of runtime instances.
• Basic notations
– collaboration (represented using a dashed eclipse)
– structured class (represented using a rectangle box).
• Each structure class may have an annotation
– Indicates its “role” in the collaboration.
• Simple Composite Structure

Seller Buyer
Order
Processing OrderProcess Customer
System
 Component diagram
• A component
– a deployable reusable building block for software
design and development.
– Ex:
• a JavaBean component is deployed in jar file
• EJB component is deployed in ear file
• .NET component is deployed in .dll file.
• Has interface to
– Expose its services
– Hides its implementations.
• A lollipop shape of a component
– Represents an implemented interface.
• A cup shape
– Represents the required interface must be provided
by some other components.
• Some of the components may exist and be
available in house or on the market.
• Other components are designed and developed
by the designers and developers of the current
project.
 catalog

GUI Cart inventory

shipping

credit
check
 Package Diagram
• Is represented by a tabbed folder
– Indicates where all included classes and sub packages reside.
– Ex:
• namespace in .NET
• packages in Java
• Functionally related classes should be organized in the
same package
– So that, easy to access each other within a default accessibility
or visibility.
• Organize related packages in a same parent package to
build a class and package hierarchy Ex: .NET class
library and Java API.
 Package Diagram
• Shows the dependency relationship between
packages
– Due to this dependency, a change of one package
may result in changes of other package.
• Specify the contents of a package, i.e., the
classes which constitute a package and their
relationship.
• Use of it in represent system structure
– Help reduce the dependency complexity
– Simplify relationships between groups of classes.
 Package Diagram

Interface Checkout

Catalog Shopping cart

 Deployment Diagram
• Describe the physical configuration of the
software system
– deployed on hardware server nodes and the network
between the nodes (defined as protocols).
• Is Generated in the later phase of software
development life cycle.
• Component diagrams are the basis for the
deployment diagram.
• Is widely used to model and design distributed
software systems.
HTTP online TCP/IP JDBC
shopping cart

web server application server db server

credit company inventory manufacture

 Use Case Diagram
• Describe user requirements in terms of
system functionality (use cases)
• Consists
– Actors
– Use cases
– Links.
 Browse include shopping
catalog cart

include

Shopping
cart
credit
extend include check

Check include
shipping
out include

invoice

Order extend
confirmation exception
• An actor
– is an external “user;”
• a human end user
• an application
• an external device
• or another system.
• An use case
– Is a meaningful operational work scenario.
– Present a sequence of working steps to be carried out
by classes
• in order to provide the required system functionality.
– Specified in a separate note including the pre and
post conditions of the action in the sequence.
• The (simple) connection link
– Shows the direction of actors using the use
case.
• An <<include>> link from one use case to
another
– Is a dashed line with an arrow pointing to the
reused use case.
– Indicates that the first use case reuses or
includes the latter use case
• An <<extend>> link
– shows a newly created optional use case from
an existing use case.
– Covers alternative cases that may or may not
necessarily take place.
– is also a dashed directed line with an arrow
towards the extended use case.
 Activity Diagram
• Used to describe complex business processes
• Involve
– Complex workflow,
– Decision making
– Concurrent executions
– Exception handling
– Process termination, etc.
• Is a workflow-oriented diagram describing steps
on a single process.
 Activity Diagram
Get order

check credit check line item

cancel cancel

in stock

update inventory

S / H
Activity Diagram
 State Machine Diagram
• Are widely used for
– embedded systems and device software analysis and design.
• Is an event-oriented diagram
– Where the software elements in the system change their states
in response to external or internal stimuli (such as time events or
other system events).
• Ideal for specifying the internal behavior of objects.
• A state is a situation in which an object
– meets conditions,
– takes actions,
– and waits for new event.
Fig State Machine Diagram
wait for
login

Accept id reject

Reason
Name, passwordi

submit key [Not valid]

message

validation confirm

Status Record

validate send message

 Interaction Overview Diagram
• Describes the control flow of the interactions.
• Is a variant of the Activity Diagram.
• The nodes in a Interaction Overview Diagram
– represent either interactions reference to
• some existing diagrams (ref)
• interaction basic element (activity diagram (ad) or sequence
diagram (sd)).
• Is a high level abstraction of interaction overview
description.
 RequestItem

ref
Browse catalog
work with shopping cart

check out

ref

Financial check

ref
no
Notification

yes

ad

shipping service inventory service

issue invoice
 Sequence Diagram
• Is one of the most important and most
widely used UML diagrams for software
system analysis and design.
• Is a time-oriented interaction diagram
– showing the chronological sequence of
messages between objects.
• Usually, one sequence diagram
corresponds to one use case.
cart checkcart inventory shipping

browse

calc
 Communication or Collaboration
Diagram
• Is a message-oriented diagram describes
– Message passing sequence, flow control, object
coordination, etc.
• summarizes how objects in the system receive
and send messages from/to other objects.
• Is an extension of the static object diagram
– where the links between objects represent the
association relationships.
• Is equivalent to a sequence diagram
– i.e., a communication diagram can be converted to an
equivalent sequence diagram and vice versa.
 2. add or remove item
catalog shopping cart
4. provide
1.browse account

3. check out

account validation

5. 3 Confirmation and invoice

5. 1 Invoice
ship bill
5. 2 Invoice

communication diagram
 Timing Diagram
• Is a new diagram in UML 2.0.
• Combines the state diagram and time
sequences
– to show the dynamic view of state change
caused by external events over time.
• Is often used in time-critical systems
– such as real time operating system,
embedded system design, etc.
 Ticket sale

Jan Feb Mar April May June July Aug Sept Oct Nov Dec
 Architecture View Models
• A model is
– a complete,
– simplified description of a system from a particular perspective
or viewpoint.
• There is no single view that can present all aspects of
complex software to stakeholders.
• Specific views models provide partial representations of
the software architecture to a specific stakeholder such
as
– system users
– the analyst/designer
– the developer/programmer
– the system integrator
– the system engineer, etc.
• The 4+1 view model was originally introduced by
Philippe Kruchten in 1995.
• The model provides four essential views:
– the logical view
• Describe objects and their interactions;
– the process view
• System activities, their concurrency and synchronization
– the physical view
• The mapping of the software onto the hardware, server, and
network configuration
– the development view
• Describes the software's static structure within a given
development environment.
• There is another view called the scenario view;
– describes the scenarios that capture the most important
aspects of the functional requirements and that drive the
system design and system validation.

• The 4+1 view model is a multiple-view model that

addresses different aspects and concerns of the
system.
• The 4+1 view model standardizes the software
design documents and makes it easy to
understand by all stakeholders.
• The user interface (UI) view is an
extend view.
– For end users of the software system,
– Describes the graphical interface to verify
and validate the user interface
requirements; these have significant
impact on the system usability and other
quality attributes.
• The following diagram shows the extended
4 + 1 view model extended with our fifth
view, the user interface view.
• The scenario view is coherent with other four
views, whereas the user interface view
complies with the scenario view and is
supported by the other four views.
 User Interface View

Logical Development
view View

Scenario

Process Physical
View view
 4+1 view Model
• The “4+1” view model
– Another way
• to show different views of the functional and non-functional requirements
• There are 5 views in the model
– the logical view
• Identify software modules and their boundaries, interfaces, external
environment, usage scenarios, etc.
– the process view
• Addresses non-functional requirements such as module communication
styles and performance issues at runtime.
– the development view
• Organizes the software units according to the actual file or directory structure
– the physical view
• Specify the deployment infrastructure in terms of software, hardware, and
networking configurations, installation, and deployment for delivery purposes
– the user interface view
 The scenario view
• Describes the functionality of the system,
– i.e., how user will use the system and how the system
provides services to the users.
• A foundation for other 4 views and lets them
work together seamlessly and coherently.
• Helps designers discover architectural elements
during design
• Helps to validate the architectural design
afterward.
• Helps to make the software architecture
consistent and validated against functional and
non-functional requirements.
 The Logical or Conceptual View
• Based on
– Application domain entities necessary to
implement the functional requirements.
• Focuses on
– Functional requirements
– The main building blocks
– Key abstractions decomposing of the system.
• An abstraction of the system's functional
requirements.
• Typically used for object-oriented modeling
– Emerges the static and dynamic system structures.
• Specifies system decomposition into
– Conceptual entities (such as objects)
– Connection between them (such as associations).
• Helps to understand the interactions between
entities in the problem space domain.
• Supported by
– UML static diagrams:
• class/object diagram
– UML dynamic diagrams:
• interaction overall diagram
• sequence diagram
• communication diagram
• state diagram
• activity diagram
• The stakeholders of the logical view
– the end-user
– analysts
– designers.
The Development or Module View
• Describes the software static organization
of the system modules.
• Derived from the logical view.
• Addresses the sub-system decomposition
and organizational issue.
• In this view, the software is packaged and
partitioned into small units
– program libraries
– sub-systems.
• UML diagrams support this view:
– Package diagrams
– Component diagrams
• The stakeholders of this view
– Programmers
– Software project manager.
Figure shows a simple development view by a package diagram.

customer cart

shipping item

payment cart update

display
Show
shopping
confirmation
cart

catalog

Item inventory

Catalog update
 The Process View
• Focuses on the dynamic aspects of the system,
– i.e., its execution time behavior.
• Also derived from logical view.
• An abstraction of processes or threads dealing
with process synchronization and concurrency.
• The stakeholders of this view are
– The developers
– Integrators.
• a coordination view of the system's processes and the
communications between them.
• Maps functions, activities, and interactions onto runtime
implementation
– with a focus on non-functional requirements as well as the
implementation of the functional requirements.
• The quality attributes are addressed here:
– Performance
– Scalability
– Concurrency
– Synchronization
– Distribution
– System throughput.
• The UML support this view are :
– Activity diagrams
– Interaction overview diagram.
 Activity Diagram in the Process View
order processing

check credit

declined

make shipping make billing Notification

order invoice

type

Post ups

save record
 The Physical View
• Describes installation, configuration, and deployment of
the software application.
• Concerns with how to deliver the deployable system.
• Shows the mapping of software onto hardware.
• It is particularly of interest in
– Distributed systems
– Parallel systems
• The stakeholders of this view are
– System installers
– System administrators
– System engineers
– Operators.
• Also takes into account the system's
nonfunctional requirements
– System availability
– Reliability (fault-tolerance)
– Throughput performance
– Scalability performance
– and Security.
• Ex: software can be delivered in different
hardware and networking layouts
– will result in significant differences in terms of these
quality attributes.
 Tables

Shopping Cart
Catalog

JDBC
Catalog Inventory

customer ship,pay,confirmation Customers

JSP, servlet container, Java Bean Database mode

Web Server ( TOMCAT ) Database server

This deployment diagram shows that the order processing system is

deployed on two servers.
 The User Interface View
• An extended view from scenarios view
• Give user-computer clear interface view
while hiding implementation details.
• May be provided as a series of screen
snapshots or a dynamic, interactive
prototype demo.
• Any modification on this view will have
direct impact on the scenarios view.
 4+1 View Summary

• The view is an architecture verification technique for

studying and documenting software architectural design.
• Each view provides a window for the different aspects of
the system.
• It covers all aspects of a software architecture for all
stakeholders.
• The views are interconnected; thus, based on the
scenarios view, we can start with logical view, and then
move to development or process view and, finally go to
physical view.
• The user interface view is also established during this
process.