2

Chapter 3
Diagramming and
Software Engineering
3
Problem and solution domain
Need to understand the
problem before can
construct the solution

A software system can be
seen as a model solution to
a particular problem.

UML diagrams bridges the
gap between problem and
solution domain in software
development
Problem
domain
Solution
domain
Bridge
4
Object-Oriented Modeling
UML Package
Problem Domain Solution Domain
Application Domain Model System Model
Aircraft
TrafficController
FlightPlan
Airport
MapDisplay
FlightPlanDatabase
SummaryDisplay
TrafficControl
TrafficControl
5
Communicating with diagram
Why diagram?
A diagram is worth a thousand words
Unlike natural languages, diagram cant lie
Needs a thorough understanding of the problem in
order to express it graphically
E.g. Forth Railway Bridge in Scotland

6
The role of diagrams in software
development
To be effective diagrams
must follow certain
rules and must be clear
A diagram is not
supposed to act as
intellectual puzzle.
UML fits in all of these
roles.
Why use
diagrams
As a DESIGN
tool
As a
MAINTENANCE
tool
As a
DOCUMENTATION
tool
As a
COMMUNICATION
medium
7
Why model software?
Software is already an abstraction: why model software?

Software is getting larger, not smaller
NT 5.0 ~ 40 million lines of code
A single programmer cannot manage this amount of code in its entirety.
Code is often not directly understandable by developers who did not
participate in the development
We need simpler representations for complex systems
Modeling is a mean for dealing with complexity
8
OOAD
In this course, we will focus on the object oriented analysis
and design (OOAD) based on the Unified Modeling Language
(UML). At the same time, we will demonstrate code
generation to a C++ and Java programming language.

What is the OOAD ?
The system is viewed as a collection of interacting objects.
Objects are instances of class and communicate by exchanging
methods calls
Why OOAD ?
Easily map to real world concepts (i.e. objects/classes)
Most new generations language are object oriented .e.g. C++, Java, C#.
Hence, can manipulate the o-o language features (i.e. inheritance,
polymorphism etc), for example, to encourage reuse




9
What is UML ?
UML is a visual language for visualizing, specifying,
constructing, and documenting of software system
Widely used in the industry. E.g. backed by leading software
producers including Hewlett Packard, IBM, Microsoft, Oracle,
Digital etc. Supports the entire software development lifecycle
and can be used in diverse application areas
Based on experience and needs of the user community (i.e.
the unification of OMT technique, Use case technique, Booch
technique)
Support by many tools, and the implementation can be
programming language independent



10
UML CASE tools

Computer Aided Software Engineering (CASE)
is a software to support software
development and its evolution
Powerful toolset that can integrate all the
tools in a single working environment
Facilitate automation, guidance and enforcement of
software engineering practices
Increase the productivity and quality whilst facilitates
maintenance
11
UML case tools contd.
Many public domain/open source/ and commercial tools
Ranging from: simply UML drawing tools to supporting round
trip engineering.
May supports C++, Java, and C#
Common ones:
Rational Rose
Rhapsody
Argo/UML (free)
Borland Together
For more reference to UML case tools, visit
http://plg.uwaterloo.ca/~migod/uml.html

12
House



Architect
produce design
Builder
refer to the design
build
UML -
Architect vs Builder Analogy
13


Software Engineer
produce design using
UML
Programmer
refer to the design
UML -
Architect vs Builder Analogy

round trip code
generation using
UML case tools

We will learn about UML
thoroughout this course !
14
UML Diagrams
Nine types of diagrams:
Use Case Diagram
Sequence Diagram
Class Diagram
Object Diagram
Collaboration Diagram
State Chart Diagram
Component Diagram
Activity Diagram
Deployment Diagram


15
UML Concepts

The diagrams describe either the structural or the behavioral of the system
Use cases and actors display the boundary of a system and its major
functions
Sequence and collaboration diagrams illustrate specific case realizations
Object diagrams depict object interactions
Class diagrams represent the static structure of a system
State transition and activity diagrams represent the dynamic behavior of
objects
Component and deployment diagram reveal the physical
implementation architecture


We will go over each diagram as we go along !

16
UML and This Course
You can model 80% of most problems by
using about 20% UML

In this course, we teach you those 20%
17
UML First Pass
Use case diagrams
Describe the functional behavior of the system as seen by the user.
Class diagrams
Describe the static structure of the system: Objects, Attributes, and
Associations.
Sequence diagrams
Describe the dynamic behavior between actors and the system and
between objects of the system.
Statechart diagrams
Describe the dynamic behavior of an individual object as a finite state
machine.
Activity diagrams
Model the dynamic behavior of a system, in particular the workflow, i.e. a
flowchart.
18
UML First Pass: Use Case Diagrams
WatchUser WatchRepairPerson
ReadTime
SetTime
ChangeBattery
Actor
Use case
Package
SimpleWatch
Use case diagrams represent the functionality of the system
from users point of view
19
UML First Pass: Class Diagrams
Battery
load()
1
2
Time
now()
PushButton
state
push()
release()
1
1
1
1
1
2
blinkIdx
blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
referesh()
LCDDisplay
SimpleWatch
Class
Association
Multiplicity
Attributes
Operations
Class diagrams represent the structure of the system
20
UML First Pass: Sequence Diagram
Object
Message
Activation
Sequence diagrams represent the behavior as interactions
blinkHours()
blinkMinutes()
incrementMinutes()
refresh()
commitNewTime()
stopBlinking()
pressButton1()
pressButton2()
pressButtons1And2()
pressButton1()
:WatchUser
:Time :LCDDisplay :SimpleWatch
21
button1&2Pressed
button1&2Pressed
button1Pressed
button2Pressed
button2Pressed
button2Pressed
button1Pressed
button1&2Pressed
Increment
Minutes
Increment
Hours
Blink
Hours
Blink
Seconds
Blink
Minutes
Increment
Seconds
Stop
Blinking
UML First Pass: Statechart
Diagrams
State
Initial state
Final state
Transition
Event
22
Other UML Notations
UML provide other notations that we will be
introduced in subsequent lectures, as needed.

Implementation diagrams
Component diagrams
Deployment diagrams
23
UML Second Pass: Use Case
Diagrams
Used during requirements elicitation to
represent external behavior

Actors represent roles, that is, a type of user
of the system
Use cases represent a sequence of
interaction for a type of functionality
The use case model is the set of all use
cases. It is a complete description of the
functionality of the system and its
environment
Passenger
PurchaseTicket
24
Actors
An actor models an external entity which
communicates with the system:
User
External system
Physical environment
An actor has a unique name and an optional
description.
Examples:
Passenger: A person in the train
GPS satellite: Provides the system with GPS
coordinates
Passenger
25
Use Case
A use case represents a class of functionality
provided by the system as an event flow.

A use case consists of:
Unique name
Participating actors
Entry conditions
Flow of events
Exit conditions
Special requirements
PurchaseTicket
26
Use Case Example
Name: Purchase ticket

Participating actor: Passenger

Entry condition:
Passenger standing in front of
ticket distributor.
Passenger has sufficient
money to purchase ticket.

Exit condition:
Passenger has ticket.
Event flow:
1. Passenger selects the number
of zones to be traveled.
2. Distributor displays the amount
due.
3. Passenger inserts money, of at
least the amount due.
4. Distributor returns change.
5. Distributor issues ticket.


Anything missing?
Exceptional cases!
27
The <<extend>>
Relationship
<<extend>> relationships
represent exceptional or seldom
invoked cases.
The exceptional event flows are
factored out of the main event
flow for clarity.
Use cases representing
exceptional flows can extend
more than one use case.
The direction of a <<extend>>
relationship is to the extended
use case
Passenger
PurchaseTicket
TimeOut
<<extend>>
NoChange
<<extend>>
OutOfOrder
<<extend>>
Cancel
<<extend>>
28
Passenger
PurchaseSingleTicket
PurchaseMultiCard
NoChange
<<extend>>
Cancel
<<extend>>
<<include>>
CollectMoney
<<include>>
The <<include>> Relationship
An <<include>> relationship
represents behavior that is
factored out of the use case.
An <<include>> represents
behavior that is factored out for
reuse, not because it is an
exception.
The direction of a
<<include>> relationship is
to the using use case (unlike
<<extend>> relationships).
29
Class Diagrams
Class diagrams represent the structure of the system.
Class diagrams are used
during requirements analysis to model problem domain concepts
during system design to model subsystems and interfaces
during object design to model classes.


Enumeration getZones()
Price getPrice(Zone)
TariffSchedule
*
*
Trip
zone:Zone
price:Price
30
Classes
A class represent a concept.
A class encapsulates state (attributes) and behavior (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information.
zone2price
getZones()
getPrice()
TariffSchedule
Table zone2price
Enumeration getZones()
Price getPrice(Zone)
TariffSchedule
Name
Attributes
Operations
Signature
TariffSchedule
31
Instances
An instance represents a phenomenon.
The name of an instance is underlined and can
contain the class of the instance.
The attributes are represented with their
values.
zone2price = {
{1, .20},
{2, .40},
{3, .60}}
tariff_1974:TarifSchedule
32
Actor vs. Instances
What is the difference between an actor and a class and an instance?
Actor:
An entity outside the system to be modeled, interacting with the
system (Pilot)
Class:
An abstraction modeling an entity in the problem domain, inside the
system to be modeled (Cockpit)
Object:
A specific instance of a class (Joe, the inspector).
33
Associations
Associations denote relationships between classes.
The multiplicity of an association end denotes how many objects the
source object can legitimately reference.

Enumeration getZones()
Price getPrice(Zone)
TarifSchedule
*
price
zone
TripLeg
*
34
1-to-1 and 1-to-Many Associations
1-to-1 association
1-to-many association
*
draw()
Polygon
x:Integer
y:Integer
Point
1
Has-capital
name:String
Country
name:String
City
1 1
35
Aggregation
An aggregation is a special case of association denoting a consists of
hierarchy.
The aggregate is the parent class, the components are the children class.
1
Exhaust System
Muffler Tailpipe
0..2
36
Composition
A solid diamond denote composition, a strong
form of aggregation where components
cannot exist without the aggregate.
3
TicketMachine
ZoneButton
37
Generalization
Generalization relationships denote inheritance between classes.
The children classes inherit the attributes and operations of the parent
class.
Generalization simplifies the model by eliminating redundancy.

Button
ZoneButton CancelButton
38
From Problem Statement to Code
Problem Statement
A stock exchange lists many companies. Each company is
identified by a ticker symbol
Class Diagram
Java Code
public class StockExchange {
public Vector m_Company = new Vector();
};
public class Company {
public int m_tickerSymbol;
public Vector m_StockExchange = new Vector();
};
*
StockExchange
tickerSymbol
Company
*
lists
39
UML Sequence Diagrams
Used during requirements analysis
To refine use case descriptions
to find additional objects
(participating objects)
Used during system design
to refine subsystem interfaces
Classes are represented by columns
Messages are represented by arrows
Activations are represented by
narrow rectangles
Lifelines are represented by dashed
lines
selectZone()
pickupChange()
pickUpTicket()
insertCoins()
Passenger
TicketMachine
40
UML Sequence Diagrams: Nested
Messages
The source of an arrow indicates the
activation which sent the message
An activation is as long as all nested
activations
selectZone()
Passenger
ZoneButton TarifSchedule Display
lookupPrice(selection)
displayPrice(price)
price
Dataflow
to be continued...
41
Sequence Diagram Observations
UML sequence diagram represent behavior in
terms of interactions.
Complement the class diagrams which
represent structure.
Useful to find participating objects.
Time consuming to build but worth the
investment.

42
Activity Diagrams
An activity diagram shows flow control within a system

An activity diagram is a special case of a state chart diagram in which states are activities (functions)
Two types of states:
Action state:
Cannot be decomposed any further
Happens instantaneously with respect to the level of abstraction used in the model
Activity state:
Can be decomposed further
The activity is modeled by another activity diagram


H a n d l e
I n c i d e n t
D o c u m e n t
I n c i d e n t
A r c h i v e
I n c i d e n t
43
Activity Diagram: Modeling
Decisions
O p e n
I n c i d e n t
N o t i f y
P o l i c e C h i e f
N o t i f y
F i r e C h i e f
A l l o c a t e
R e s o u r c e s
[ f i r e & h i g h P r i o r i t y ]
[ n o t f i r e & h i g h P r i o r i t y ]
[ l o w P r i o r i t y ]
44
Activity Diagrams: Modeling
Concurrency
Synchronization of multiple activities
Splitting the flow of control into multiple
threads
Synchronization
Splitting
Archive
Incident
Open
Incident
Document
Incident
Allocate
Resources
Coordinate
Resources
45
Activity Diagrams: Swimlanes
Actions may be grouped into swimlanes to
denote the object or subsystem that
implements the actions.

Archive
Incident
Dispatcher
FieldOfficer
Open
Incident
Document
Incident
Allocate
Resources
Coordinate
Resources
46
Component Diagram
Show dependencies among components, including source
code components, binary code components, and executable
components
OrderOptions
OrderOptions
OrderDetail
OrderDetail
47
Deployment Diagram
Displays the configuration of run-time processing elements
and the software component processes, and objects that live
on them
Application
Server
OrderServerExe
Database
Server
Client
Workstation #1
OrderCl i entExe
Client
Workstation #2
OrderCl i entExe
Printer
48
Process vs Design Notation
Remember, UML is merely design notation
and not a process per se.
Software development using UML (possible
route)
Use case->sequence diagram -> collaboration diagram -
> class diagram -> object diagram.
Use case->object diagram->class diagram -> sequence
diagram.
.. etc.. and UML does not dictate any sequence ..

49
Possible UML Development Process
Use case
Flow of Events
prioritize
Sequence diagram
Collaboration diagram
(optional)
Class diagram
State chart
(optional)
Deployment diagram
(optional)
CODE
Activity diagram
(optional)
Object diagram
(optional)
Component diagram
SPECIFICATION
DESIGN
IMPLEMENTATION
50
Software Engineering
Activities A Review
51
Software engineering
activities Review
Requirement analysis and specification
Design
Coding
Testing
Operation and maintenance
Here, the development model are irrelevant !
52
High Level View?
Customers &
Stakeholders
Independent
V&V Teams
Known Failure
Empirical Data
interact
interact
produce
solicit
REQUIREMENT
ELICITATION
PHASE
Software
Design
Software
Implementation
IMPLEMENTATION
PHASE
refer
Software
Specification
Software
Engineers &
Programmers
refer
design
develop
Test
Cases
develop
Test case execution
Software
Release
VALIDATION
PHASE
analyze for
conformance
S
O
F
T
W
A
R
E

E
N
G
I
N
E
E
R
I
N
G

P
R
O
D
U
C
T

L
I
F
E
C
Y
C
L
E
Requirement
Engineers
53
Requirement analysis and specification
Determine the requirements and feasibility of
the solution
A clear understanding between the user and developer
Acceptability of possible tradeoffs based on the
objectives and constraints of the project
Project plan includes the schedule, budget, outputs at
the end of each phase
54
Specification
What the solution look like
What inputs the system is going to process
What functions it will perform for each input
What are the corresponding output
Whether the specified system meets the user
requirements, conforms to the project plan or the
project plan needs to be altered
55
Design
How the solution will be implemented
Structures the system into its logically and functionally
cohesive parts or modules
Select the proper data structures and algorithms for
the implementation of the input and output data and
the system functions
Identify the major subsystems/modules and how they
interrelate
Identify the functionality of each module
Design test cases

56
Coding
Translating the solution into actual codes
Write the program as being described in the design
The coding phase is complete when all codes have
been written, compiled and documented
Rereading test code inspection, walkthrough
Software test description how and when to test what
part of the code

57
Testing
Testing the program
Based on the test plan
Unit test
Integration test
Acceptance test
System test

58
Operation and maintenance
Keeping the system operational
Corrective maintenance
Adaptive maintenance
Produce multiple versions of software product


In next section to come, we will see how UML supports all these
activities.

59
Topic 4
Requirements and
Design
60
The importance of requirement
I know you believe you
understood what you
think I said, but I am not
sure you realize that
what you heard is not
what I meant
61
The importance of requirements
contd.
Try to develop anything
without them
They may be a legal
contract
They are the basis for
later testing
Poor requirements are
the common reason for
project failure (see the
next slide)
62
The requirement traceability
Must be prepared to be able to trace down/up from
specification to design and tests
Essential for maintenance and evolution.
Module
Req.
Module 1 Module 2 Module k
..
Req. 1
Req. 2
Req. y
X X
X
X
X
X
X
X
X
X
63
Requirement Specification
Often a two step process
i. High level requirements document For
management level/marketing people
ii. Specification with all the details filled in For
client/developers

OR
i. System level specification with all components For
management level/marketing people
ii. Detailed requirements for each components For
client/developers

64
Non functional requirements
Often not set by the customers
Define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
Sometimes, non-functional requirements may be
more critical than functional requirements.
Typically:
Reliability, Security, Availability, Maintainability, Portability,
Performance

65
Who needs to be involved ?
Everyoneas the stakeholders here is why:
Customers as they are the users
Marketing people as they are probably promoting its development
Documentation people as they use requirements to write
documentation
Testers as they will test codes against the requirements
Technical support as they will have to support the system
Developers as they will have to design/write codes based on the
requirement
Customer Training as they need to develop course training material if
needed
And many more..



66
Common problems
Long meetings involving many people. Hence, a lot of conflicts (e.g.
political etc)
Different users have different requirements and priorities.
System end-users and organisations who pay for the system have different
requirements
Natural language problems vague !
The system should be easy to use by experienced controllers and
should be organised in such a way that user errors are minimised.
The error rate should be quantified
Experienced controllers should be able to use all the system
functions after a total of two hours training. After this training, the
average number of errors made by experienced users should not
exceed two per day.

Hence, prototyping often required to clarify requirements



67
How are requirements elicited?
Interviews
Gives best information
Expensive
Questionnaires
Good if many people involved especially if dispersed
Tend to have poor responses
Observation
Accurate if done well
Expensive
Searching
Limited information
Tends not to reveal potential problems