Software Engineering (CPSC-4360),

Lesson 2

1/4/2012

CPSC-4360, Lesson 2

Overview of the Last Lecture

Overview of Software Engineering

Overview of Software Process

SE definitions
Quality of Good Software
Activities and associated stages

Overview of Software Engineering Method

1/4/2012

Structured Analysis
Object-Oriented Method

CPSC-4360, Lesson 2

Overview of This Lecture

Software Development Models

Waterfall Model
Evolutionary Models
Incremental Model
Spiral Model
Unified Process

Overview of UML

1/4/2012

History
4 + 1 View models
Using UML in UP
CPSC-4360, Lesson 2

Software Development Models

The high level software process is an abstract

representation of software development which has
four activities:

Specification.
Development.
Validation.
Evolution.

The theoretical framework is usually extended and

adapted from the real world applications.
Two Generic Models:

1/4/2012

Waterfall Model.
Evolutionary Model.
CPSC-4360, Lesson 2

Waterfall Model

The earliest software development model (Royce, 1970).

Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance

1/4/2012

CPSC-4360, Lesson 2

Waterfall Model
Defined a number of phases, e.g.,
requirement phase, design phase, etc.
The phases correspond to the four stages of
the fundamental software process activities
(lecture 1).
Assumption behind the model:

1/4/2012

a phase takes place in sequence to another;

each activity is completed before the next starts.

CPSC-4360, Lesson 2

Waterfall Model

In theory:

Each phase produces documents that are:

Each phase depends on the documents of the

previous stage to proceed.

Verified and validated;

Assumed to be complete.

It has to wait for the completion of previous stage.

In practice:

1/4/2012

The phases overlap and feedback to each other

(see the feedback arrow in the diagram).
CPSC-4360, Lesson 2

Waterfall Model: Advantages

Tangible products (the various documents) at
the end of every phases are very good to
measure progress.
Intuitive, sensible and general purpose:

1/4/2012

Emphasize planning before action;

Recommend a top-down perspective. See the big
picture before zooming down.

CPSC-4360, Lesson 2

Waterfall Model: Problems

Specification is frozen early, because:

Cannot adapt to changing or incorrect

specification:

It is costly and time consuming;

Later stages can be carried out.

Ignore or code around;

Does not meet user requirement.

Testing at the very end of development:

1/4/2012

Work or die situation.

CPSC-4360, Lesson 2

Waterfall Model: Observations

Process stages can be iterative.

Flexibility in coping with changing specification.
Early and frequent validation of software system.
The later models are designed in response to these
observations.

1/4/2012

CPSC-4360, Lesson 2

10

Evolutionary Model

Evolves an initial implementation with user feedback

multiple versions until the final version.
Concurr ent
activities

Outline
description

1/4/2012

Specification

Initial
version

Development

Intermediate
versions

Validation

Final
version

CPSC-4360, Lesson 2

11

Evolutionary Model

Two fundamental types:

Exploratory Development:

Explores the requirement and delivers a final system.

Starts with something that is understood and evolves by adding
new features proposed by customers.

Throwaway prototyping:

1/4/2012

Understands the requirement and develop a better requirement

definition.
Experimenting with poorly understood requirement.
Usually develops User Interface (UI) with minor or no functionality.

CPSC-4360, Lesson 2

12

Evolutionary Model: Advantages

Customer involvement in the process:

Early and frequent testing:

More likely to meet the user requirement.

More likely to identify problems.
Lower risk.

Suitable for small to medium sized system.

1/4/2012

CPSC-4360, Lesson 2

13

Evolutionary Model: Problems

The process is intangible:

The process is unpredictable:

Hard to manage, e.g., scheduling, workforce allocation, etc.

Systems are poorly structured:

No regular, well-defined deliverables.

Continual, unpredictable change tends to corrupt the

software structure.
Can cause major problems during software evolution.

Systems may not even converge to a final version.

1/4/2012

No strategy to gauge or solve this problem.

CPSC-4360, Lesson 2

14

Incremental Model

Combine the advantages of Waterfall and

Evolutionary Models.
Requirements
Outline

Develop
Increment

Split into
increments

Validate
Increment

Design
System
Architecture

Integrate
Increment

Validate
System

Final
System
1/4/2012

CPSC-4360, Lesson 2

15

Incremental Model

Each increment is a mini-waterfall.

1/4/2012

CPSC-4360, Lesson 2

16

Incremental Model
Prioritizes the services to be provided by the
system.
Maps these requirements to Increment based
on priority.
Freezes requirement for the current Increment.

Requirements for the later increments can evolve

concurrently.

Each Increment release is a working system:

1/4/2012

Allows user to experiment.

Can be put into service right away.
CPSC-4360, Lesson 2

17

Incremental Model: Advantages

Early utilization:

the 1st increment satisfies the most critical

requirement.

Early increments can serves as prototypes.

Lower risk of overall project failure.
Most crucial and basic services are
implemented first.
This model includes multiple testing
throughout development.

1/4/2012

CPSC-4360, Lesson 2

18

Incremental Model: Problems

Hard to map requirement into small
increments (< 20,000 lines of code).
Hard to define the basic services that are
shared by all subsequent increments.
Popular variant:

AGILE method:

1/4/2012

eXtreme Programming (XP)

Not covered here.

CPSC-4360, Lesson 2

19

Spiral Model

Formalize the Evolutionary Model and avoid the

management shortcomings.

1/4/2012

CPSC-4360, Lesson 2

20

Spiral Model
This process is represented as a spiral rather
than as a sequence of activities with
backtracking.
Each loop = One Iteration = A process phase.
Each Loop passes through 4 quadrants (90):

Objective Setting.
Risk Assessment and Reduction.
Development and Validation.
Planning.

As loops move away from center, the Time

and Cost increase.

1/4/2012

CPSC-4360, Lesson 2

21

Spiral Model

Risk Driven:

Does not prescribe a fix process:

Explicitly identify risks for each iteration.

Address the highest perceived risk.
Project Manager chooses the appropriate activity
for each iteration based on progress and perceived
risk.

Flexible:

1/4/2012

May resemble other process models that depend

on needs.
CPSC-4360, Lesson 2

22

Unified Process

State of the art process, by learning from the history

of previous software development processes.

1/4/2012

CPSC-4360, Lesson 2

23

Unified Process

Integrating two seemingly contradicting insights:

A project is split into several phases:

Definitive activities and deliverables as in the

Waterfall Model.
Iterative and incremental processes.
Each phase is split into several iterations.
Each iteration consists of the traditional process
activities, known as workflow.

Each workflow places different emphasis on the

activities depending on the current iteration.

1/4/2012

CPSC-4360, Lesson 2

24

Unified Process: 4 Phases

Inception:

Elaboration:

Understand problem domain.

Design system architecture.
Plan development.

Construction:

Plan the project.

Evaluate risk.

Design, programming and test.

Transition:

1/4/2012

Moving system from developer to user environment.

Acceptance testing, release of full system.
CPSC-4360, Lesson 2

25

Other Process Models

Formal System Development:

Reuse-Oriented Development:

Transforms a mathematical based specification through

different representation executable program.
Program correctness is easy to demonstrate, as the
transformations preserve the correctness.
Concentrates on integrating new system with existing
components/systems.
Growing rapidly as development cost increase.

Aspect-Oriented Development.
Agent-Oriented Software Development.

1/4/2012

CPSC-4360, Lesson 2

26

Unified Modeling Language (UML)

A visual language to

Visualize, construct, and document software

systems.

Similar to all other languages, UML has:

Grammar: Rules to follow when drawing diagrams.

Semantics: The meaning behind each diagram.

Used with the Object-Oriented Method.

Separates the language from the software
process can be used with other software
development model.
Currently, this is an industry standard.

1/4/2012

CPSC-4360, Lesson 2

27

What UML is NOT

Not a programming language.

Not a software modeling tool.

Not executable.
However, there exist tools to translate into code
(skeleton), but the programmer still needs to do the
bulk of work.
However, there are tools that implement the UML
standard, e.g., ArgoUML, Visual Paradigm,
RationalRose.

Not a SE method or software development

process.

1/4/2012

CPSC-4360, Lesson 2

28

UML: Brief History

The Object Orient Modeling approach with different

strengths and weaknesses grows rapidly.
In 1995,

There were more than 50 named techniques in the industry.

The Object Management Group (OMG) calls for a common
modeling approach.

Rumbaugh, Booch, and Jacobson (The three amigos)

with input from others, formalized the UML standard
(UML 1.1) in 1997.
Revised in 2003 (UML 1.5): Currently most widely used.
Reorganized in 2005 (UML 2.0): A new standard.

1/4/2012

CPSC-4360, Lesson 2

29

UML: 4 + 1 View Models

A system can be viewed in different ways,
usually depends on the role of the viewer.
UML supports this by providing the 4 + 1 View
Models [Kruchten, 1995]:

System
Design
View

Implementation
View
Use Case
View
Deployment
Process
View
View
1/4/2012

CPSC-4360, Lesson 2

30

Use Case View

Audience:

System Analyst, End Users and Testers.

Usage:

1/4/2012

Describes the systems external behaviour.

Defines the requirements of the system, so it
constraints all the other views.
Has the central role in driving the development
process.

CPSC-4360, Lesson 2

31

Example of Use Case

Elevator System

Use case 1: Call Elevator is this possible written story:

Basic course of events: If the userOutside wants to call lift to

go up/down, then he/she presses UpButton/DownButton;
Exception 1: If the lift is at the ground floor, then there is no
DownButton;
Exception 2: If the lift is at the top floor, then there is no
UpButton;

Use case 2: Move From Inside is this written story:

1/4/2012

The userFromInside can select a floor number (from 1 to the

number of floors of the building), or can press Open,
Close.
CPSC-4360, Lesson 2

32

Design View

Audience:

System Analyst and Programmers.

Usage:

1/4/2012

Describes the logical structures that support the

functional requirements expressed in the use case
view.
Consists of definitions of program components
(classes, data), their behaviour and interactions.
Useful as basis for coding.

CPSC-4360, Lesson 2

33

Implementation View

Audience:

System Engineer and Tester.

Usage:

Describes the physical components out of which

the system is to be constructed:

1/4/2012

executable files,
libraries of code,
databases.

Useful for configuration management and system

integration.
CPSC-4360, Lesson 2

34

Process View

Audience:

Usage:

System Analyst, Programmer and Tester.

Non-Functional requirements.
Defines concurrency within the system.

Relatively undeveloped.

1/4/2012

CPSC-4360, Lesson 2

35

Deployment View

Audience:

System Integrator (setup the system at client side).

Usage:

Non-Functional.
Describes physical components that are deployed
in the physical environment:

Network of computers, connection protocol.

Computer specification.

Relatively Undeveloped.

1/4/2012

CPSC-4360, Lesson 2

36

UML Terminology

Model:

Model element:

Refers to the information in a single view, e.g., Use Case

Model. OR
Refers to all the information about the system, i.e., System
Model.
Independent graphical notation element, e.g., a box, an
arrow, etc, that has a well defined meaning.

Diagram:

1/4/2012

Graphical presentation of a collection of model elements.

CPSC-4360, Lesson 2

37

UML Diagrams by Views

1.
2.
3.
4.
5.
6.
7.
8.
9.

1/4/2012

Use case diagram (use case view)

Object diagram (use case and design views)
Sequence diagram (use case and design views)
Collaboration diagram (use case and design views)
Class diagram (design view)
Statechart diagram (design and process views)
Activity diagram (design and process views)
Component diagram (implementation view)
Deployment diagram (deployment view)

CPSC-4360, Lesson 2

38

UML Diagrams by Characteristic

Software system exhibits two characteristics:

Static: Logical Structure, e.g., relationship

between classes, attributes of a class, etc.
Dynamic: Behavior of the system, e.g., how to
respond to a certain event, how to initiate an
action, etc.

In addition, knowledge about setting up and

running the system: Implementation.

1/4/2012

CPSC-4360, Lesson 2

39

UML Diagrams by Characteristic

Static:

Dynamic:

Use case diagram

Class diagram
Object diagram
State diagram
Activity diagram
Sequence diagram
Collaboration diagram

Implementation:

1/4/2012

Component diagram
Deployment diagram
CPSC-4360, Lesson 2

40

Design Model and Code

Models present an abstract view of system.

Implementation adds enough detail to make these
models executable.

UML

UML model

specifies

Abstract view of
Java

Source code

specifies

Abstract view of

Executing program
Run time

Compile time
1/4/2012

Object structures

CPSC-4360, Lesson 2

41

UML Models
Both documentation (UML model) and Source code can
be described as compile-time artifacts.
Object structures: Programmers in object-oriented
languages (e.g., Java, C++) tend to use abstract models of
program execution which talk in terms of objects being
created and destroyed as a program runs.
Executing program: describes the effect the program has
on computers processor and memory when the program is
running.
The upper and below parts refer to design and
programming.
The left and right parts refer to compile-time and run-time.

1/4/2012

CPSC-4360, Lesson 2

42

Unified Process and UML

UP is Use Case Driven:

A systematic utilization of Use Case.

UML diagrams are used in the Requirement,

Analysis and Design activities in the UP
workflow.
Because of their history, there is a close fit
between UML and the UP.

1/4/2012

CPSC-4360, Lesson 2

43

UP: Requirement and Analysis

UP starts with use

cases describing how
users interact with the
system:

1/4/2012

A domain model records

facts about real world
entities.
UML use case and class
diagrams document
these.

CPSC-4360, Lesson 2

44

UP: Analysis and Design

Analysis and Design usually overlap in UP as the

same diagrams are used.
Proceed by Realization and Refinement.

1/4/2012

CPSC-4360, Lesson 2

45

UP: Realization and Refinement

Use case realizations indicate how the

functionality will be supported by the system.

Documented in UML interaction diagrams, e.g.,

Sequence Diagram, Collaboration Diagram.

This causes the domain model to be refined

into a more implementation-oriented class
diagram.

1/4/2012

CPSC-4360, Lesson 2

46

UP: Specifying Behavior

UML provides State Chart to document the

behavior of classes.

1/4/2012

CPSC-4360, Lesson 2

47

The most important software testing

phases
1.

2.

3.

4.

unit testing, that is, testing of a particular unit - a

logically and physically meaningful chunk of code;
integration testing, that is, units are put together in
subsystems and these integrated pieces of code(s) are
tested to expose defects in the interfaces and
interaction between integrated components (modules);
system testing, that is, it tests the system for its nonfunctional requirements, and
acceptance testing, that is, the system gets tested in
the users environment.

1/4/2012

CPSC-4360, Lesson 2

48

Summary

Software Development Models

Waterfall Model
Evolutionary Models
Incremental Model
Spiral Model
Unified Process

Overview of UML

1/4/2012

History
4 + 1 View models
Using UML in UP
CPSC-4360, Lesson 2

49

Reading Suggestions

[Priestley; 2004], Chapter 3

[Wadhwa, Andrei, Soo; 2007], Chapter 2
[Sommerville; 2011], Chapters 1 and 4

1/4/2012

CPSC-4360, Lesson 2

50

Coming up next

Use Case and Domain Modeling:

1/4/2012

[Priestley; 2004], Chapter 4

[Wadhwa, Andrei, Soo; 2007], Chapters 2 and 3

CPSC-4360, Lesson 2

51

Thank you for your attention!

Questions?

1/4/2012

CPSC-4360, Lesson 2

52