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
01/12/14
Structured Analysis
Object-Oriented Method
CPSC-4360-01, CPSC-5360-01, Lecture 2
2
3. Overview of This Lecture
Software Development Models
Waterfall Model
Evolutionary Models
Incremental Model
Spiral Model
Unified Process
Overview of UML
01/12/14
History
4 + 1 View models
Using UML in UP
CPSC-4360-01, CPSC-5360-01, Lecture 2
3
4. Software Development Models
High level, abstract representation of software
development (software process):
Specification.
Development.
Validation.
Evolution.
Theoretical framework that is usually extended and
adapted in real world application.
Two Generic Models:
01/12/14
Waterfall Model.
Evolutionary Model.
CPSC-4360-01, CPSC-5360-01, Lecture 2
4
5. Waterfall Model
The earliest software development model (Royce, 1970).
Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
5
7. 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:
01/12/14
a phase takes place in sequence to another.
each activity is completed before the next starts.
CPSC-4360-01, CPSC-5360-01, Lecture 2
7
8. Waterfall Model
In theory:
Each phase produces documents that are:
Verified and validated.
Assumed to be complete.
Each phase depends on the documents of the
previous stage to proceed → it has to wait for the
completion of previous stage.
In practice:
01/12/14
The phases overlap and feedback to each other
(see the feedback arrow in the diagram).
CPSC-4360-01, CPSC-5360-01, Lecture 2
8
9. Waterfall Model: Advantages
Tangible products (the various documents) at
the end of every phases → good to measure
progress.
Intuitive, sensible and general purpose:
01/12/14
Emphasize planning before action.
Recommend a top-down perspective. See the big
picture before zooming down.
CPSC-4360-01, CPSC-5360-01, Lecture 2
9
10. 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:
01/12/14
Work or die situation.
CPSC-4360-01, CPSC-5360-01, Lecture 2
10
11. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
11
12. Evolutionary Model
Evolves an initial implementation with user feedback
→ multiple versions until the final version.
Concurren
t
activities
Specification
01/12/14
Development
Intermediate
versions
Validation
Outline
description
Initial
version
Final
version
CPSC-4360-01, CPSC-5360-01, Lecture 2
12
13. 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:
01/12/14
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-01, CPSC-5360-01, Lecture 2
13
14. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
14
15. 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.
01/12/14
No strategy to gauge or solve this problem.
CPSC-4360-01, CPSC-5360-01, Lecture 2
15
16. Incremental Model
Combine the advantages of Waterfall and
Evolutionary Model.
Requirements
Outline
Develop
Increment
Split into
increments
Validate
Increment
Design
System
Architecture
Integrate
Increment
Validate
System
Final
System
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
16
18. 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:
01/12/14
Allows user to experiment.
Can be put into service right away.
CPSC-4360-01, CPSC-5360-01, Lecture 2
18
19. 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 → receives multiple testing
throughout development.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
19
20. 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:
01/12/14
eXtreme Programming (XP)
Not covered here.
CPSC-4360-01, CPSC-5360-01, Lecture 2
20
21. Spiral Model
Formalize the Evolutionary Model and avoid the
management shortcomings.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
21
22. Spiral Model
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 → Time and
Cost increase.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
22
23. 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 base on progress and perceived
risk.
Flexible:
01/12/14
May resemble other process model depends on
needs.
CPSC-4360-01, CPSC-5360-01, Lecture 2
23
24. Unified Process
State of the art process, by learning from the history
of previous software development processes.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
24
25. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
25
26. 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:
01/12/14
Moving system from developer to user environment.
Acceptance testing, release of full system.
CPSC-4360-01, CPSC-5360-01, Lecture 2
26
27. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
27
28. Unified Modeling Language (UML)
A visual language to
Similar to all other languages, UML has:
Visualize, construct, document software system.
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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
28
29. What UML is NOT
Not a programming language.
Not a software modeling tool.
Not executable.
Exist tools to translate into code (skeleton), but the
programmer still need to do the bulk of work.
There are tools that implement the UML standard,
e.g., ArgoUML, Visual Paradigm, RationalRose.
Not a SE method or software development
process.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
29
30. UML: Brief History
OO 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
30
31. 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
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
31
32. Use Case View
Audience:
System Analyst, End Users and Testers.
Usage:
01/12/14
Describes the system’s 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-01, CPSC-5360-01, Lecture 2
32
33. 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:
01/12/14
The userFromInside can select a floor number (from 1 to the
number of floors of the building), or can press “Open”,
“Close”.
CPSC-4360-01, CPSC-5360-01, Lecture 2
33
34. Design View
Audience:
System Analyst and Programmers.
Usage:
01/12/14
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-01, CPSC-5360-01, Lecture 2
34
35. Implementation View
Audience:
System Engineer and Tester.
Usage:
Describes the physical components out of which
the system is to be constructed:
01/12/14
executable files,
libraries of code,
databases.
Useful for configuration management and system
integration.
CPSC-4360-01, CPSC-5360-01, Lecture 2
35
37. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
37
38. 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:
01/12/14
Graphical presentation of a collection of model elements.
CPSC-4360-01, CPSC-5360-01, Lecture 2
38
39. UML Diagrams by Views
1.
2.
3.
4.
5.
6.
7.
8.
9.
01/12/14
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-01, CPSC-5360-01, Lecture 2
39
40. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
40
41. UML Diagrams by Characteristic
Static:
Dynamic:
Use case diagram
Class diagram
Object diagram
State diagram
Activity diagram
Sequence diagram
Collaboration diagram
Implementation:
01/12/14
Component diagram
Deployment diagram
CPSC-4360-01, CPSC-5360-01, Lecture 2
41
42. Design Model and Code
Models present an abstract view of system.
Implementation adds enough detail to make these
models executable.
UML
UML model
specifies
Object structures
Abstract view of
Abstract view of
Java
Source code
specifies
Executing program
Compile time
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
Run time
42
43. 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 computer’s 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
43
44. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
44
45. UP: Requirement and Analysis
UP starts with use
cases describing how
users interact with the
system:
01/12/14
A domain model records
facts about real world
entities.
UML use case and class
diagrams document
these.
CPSC-4360-01, CPSC-5360-01, Lecture 2
45
46. UP: Analysis and Design
Analysis and Design usually overlap in UP as the
same diagrams are used.
Proceed by Realization and Refinement.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
46
47. 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.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
47
48. UP: Specifying Behavior
UML provides State Chart to document the
behavior of classes.
01/12/14
CPSC-4360-01, CPSC-5360-01, Lecture 2
48
49. Summary (1)
Waterfall Process Model:
Development activities in a linear fashion.
Requirements to freeze very early in
development.
Testing very late in the process.
Evolutionary Process Model in response to
iterative nature of development:
01/12/14
Use of prototyping.
Requirements evolve with users’ feedback.
CPSC-4360-01, CPSC-5360-01, Lecture 2
49
50. Summary (2)
Incremental Process Model in response to
incremental nature of development:
01/12/14
Delivery in increments.
Allows prioritizing risks in development.
Allows different process models for different
increments.
CPSC-4360-01, CPSC-5360-01, Lecture 2
50
51. Summary (3)
Spiral Model:
Addresses incremental and iterative nature of
development.
Allows risk evaluation at every phase.
Expensive process.
Allows use of multiple process models.
Unified Process:
01/12/14
Incorporates best industry practices.
Extensive use of UML models.
Allows iteration of workflows.
CPSC-4360-01, CPSC-5360-01, Lecture 2
51
52. Summary
Software Development Models
Waterfall Model
Evolutionary Models
Incremental Model
Spiral Model
Unified Process
Overview of UML
01/12/14
History
4 + 1 View models
Using UML in UP
CPSC-4360-01, CPSC-5360-01, Lecture 2
52