Title: Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2
1Software Engineering, CPSC-4360-01,
CPSC-5360-01,Lecture 2
2Overview of the Last Lecture
- Overview of Software Engineering
- SE definitions
- Quality of Good Software
- Overview of Software Process
- Activities and associated stages
- Overview of Software Engineering Method
- Structured Analysis
- Object-Oriented Method
3Overview of This Lecture
- Software Development Models
- Waterfall Model
- Evolutionary Models
- Incremental Model
- Spiral Model
- Unified Process
- Overview of UML
- History
- 4 1 View models
- Using UML in UP
4Software 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
- Waterfall Model.
- Evolutionary Model.
5Waterfall Model
- The earliest software development model (Royce,
1970).
6Waterfall 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
- a phase takes place in sequence to another.
- each activity is completed before the next starts.
7Waterfall 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
- The phases overlap and feedback to each other
(see the feedback arrow in the diagram).
8Waterfall Model Advantages
- Tangible products (the various documents) at the
end of every phases ? good to measure progress. - Intuitive, sensible and general purpose
- Emphasize planning before action.
- Recommend a top-down perspective. See the big
picture before zooming down.
9Waterfall Model Problems
- Specification is frozen early, because
- It is costly and time consuming.
- Later stages can be carried out.
- Cannot adapt to changing or incorrect
specification - Ignore or code around.
- Does not meet user requirement.
- Testing at the very end of development
- Work or die situation.
10Waterfall 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.
11Evolutionary Model
- Evolves an initial implementation with user
feedback ? multiple versions until the final
version.
12Evolutionary 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
- Understands the requirement and develop a better
requirement definition. - Experimenting with poorly understood requirement.
- Usually develops User Interface (UI) with minor
or no functionality.
13Evolutionary Model Advantages
- Customer involvement in the process
- More likely to meet the user requirement.
- Early and frequent testing
- More likely to identify problems.
- Lower risk.
- Suitable for small to medium sized system.
14Evolutionary Model Problems
- The process is intangible
- No regular, well-defined deliverables.
- The process is unpredictable
- Hard to manage, e.g., scheduling, workforce
allocation, etc. - Systems are poorly structured
- 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.
- No strategy to gauge or solve this problem.
15Incremental Model
- Combine the advantages of Waterfall and
Evolutionary Model.
Final System
16Incremental Model
- Each increment is a mini-waterfall.
17Incremental 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
- Allows user to experiment.
- Can be put into service right away.
18Incremental 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.
19Incremental Model Problems
- Hard to map requirement into small increments (lt
20,000 lines of code). - Hard to define the basic services that are shared
by all subsequent increments. - Popular variant
- AGILE method
- eXtreme Programming (XP)
- Not covered here.
20Spiral Model
- Formalize the Evolutionary Model and avoid the
management shortcomings.
21Spiral 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.
22Spiral Model
- Risk Driven
- Explicitly identify risks for each iteration.
- Address the highest perceived risk.
- Does not prescribe a fix process
- Project Manager chooses the appropriate activity
for each iteration base on progress and perceived
risk. - Flexible
- May resemble other process model depends on needs.
23Unified Process
- State of the art process, by learning from the
history of previous software development
processes.
24Unified Process
- Integrating two seemingly contradicting insights
- Definitive activities and deliverables as in the
Waterfall Model. - Iterative and incremental processes.
- A project is split into several phases
- 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.
25Unified Process 4 Phases
- Inception
- Plan the project.
- Evaluate risk.
- Elaboration
- Understand problem domain.
- Design system architecture.
- Plan development.
- Construction
- Design, programming and test.
- Transition
- Moving system from developer to user environment.
- Acceptance testing, release of full system.
26Other Process Models
- Formal System Development
- Transforms a mathematical based specification
through different representation ? executable
program. - Program correctness is easy to demonstrate, as
the transformations preserve the correctness. - Reuse-Oriented Development
- Concentrates on integrating new system with
existing components/systems. - Growing rapidly as development cost increase.
- Aspect-Oriented Development.
- Agent-Oriented Software Development.
27Unified Modeling Language (UML)
- A visual language to
- Visualize, construct, document software system.
- 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.
28What UML is NOT
- Not a programming language.
- Not executable.
- Exist tools to translate into code (skeleton),
but the programmer still need to do the bulk of
work. - Not a software modeling tool.
- There are tools that implement the UML standard,
e.g., ArgoUML, Visual Paradigm, RationalRose. - Not a SE method or software development process.
29UML 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.
30UML 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 View
Process View
31Use Case View
- Audience
- System Analyst, End Users and Testers.
- Usage
- 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.
32Example 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 - The userFromInside can select a floor number
(from 1 to the number of floors of the building),
or can press Open, Close.
33Design View
- Audience
- System Analyst and Programmers.
- Usage
- 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.
34Implementation View
- Audience
- System Engineer and Tester.
- Usage
- Describes the physical components out of which
the system is to be constructed - executable files,
- libraries of code,
- databases.
- Useful for configuration management and system
integration.
35Process View
- Audience
- System Analyst, Programmer and Tester.
- Usage
- Non-Functional requirements.
- Defines concurrency within the system.
- Relatively undeveloped.
36Deployment 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.
37UML Terminology
- Model
- 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. - Model element
- Independent graphical notation element, e.g., a
box, an arrow, etc, that has a well defined
meaning. - Diagram
- Graphical presentation of a collection of model
elements.
38UML Diagrams by Views
- 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)
39UML 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.
40UML Diagrams by Characteristic
- Static
- Use case diagram
- Class diagram
- Dynamic
- Object diagram
- State diagram
- Activity diagram
- Sequence diagram
- Collaboration diagram
- Implementation
- Component diagram
- Deployment diagram
41Design Model and Code
- Models present an abstract view of system.
- Implementation adds enough detail to make these
models executable.
specifies
Object structures
UML model
UML
Abstract view of
Abstract view of
Java
specifies
Run time
Compile time
42UML 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.
43Unified 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.
44UP Requirement and Analysis
- UP starts with use cases describing how users
interact with the system - A domain model records facts about real world
entities. - UML use case and class diagrams document these.
45UP Analysis and Design
- Analysis and Design usually overlap in UP as the
same diagrams are used. - Proceed by Realization and Refinement.
46UP 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.
47UP Specifying Behavior
- UML provides State Chart to document the behavior
of classes.
48Summary (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 - Use of prototyping.
- Requirements evolve with users feedback.
49Summary (2)
- Incremental Process Model in response to
incremental nature of development - Delivery in increments.
- Allows prioritizing risks in development.
- Allows different process models for different
increments.
50Summary (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
- Incorporates best industry practices.
- Extensive use of UML models.
- Allows iteration of workflows.
51Summary
- Software Development Models
- Waterfall Model
- Evolutionary Models
- Incremental Model
- Spiral Model
- Unified Process
- Overview of UML
- History
- 4 1 View models
- Using UML in UP
52Reading Suggestions
- Wadhwa, Andrei, Soo 2007, Chapter 2
- Sommerville 2008, Chapters 1 and 4
- Priestley 2004, Chapter 3
53Coming up next
- Use Case Modeling, Domain Modeling
- Wadhwa, Andrei, Soo 2007, Chapters 2 and 3
- Priestley 2004, Chapter 4
54Thank you for your attention!Questions?