Overview of This Lecture
Introduction to Process Development
each activity is completed before the next starts.
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
3/20/2013 5 the fundamental software process activities.
Assumption behind the model: a phase takes place in sequence to another.
Waterfall Model
3/20/2013 4 Implementation
In theory:
Each phase produces documents that are: Verified and validated.
Assumed to be complete.
Each phase depends on the documents of the 3/20/2013 6
Each phase depends on the documents of the previous stage to proceed
→ it has to wait for the completion of previous stage.
In practice:
and unit testing Integration and system testing Operation and maintenance
Requirements definition System and software design
Oleh 3/20/2013 1 I Gede Made Karma
Source : CPSC-4360-01, CPSC-5360-01, Lecture 2
Overview of This Lecture
Software Development Models
Waterfall Model
Evolutionary Models
Incremental Model
Spiral Model 3/20/2013 2 p
Unified Process
Overview of UML
The earliest software development model (Royce, 1970).
History
4 + 1 View models Using UML in UP
Software Development Models
High level, abstract representation of software development (software process): Specification. Development. Validation.
E l ti
3/20/2013 3 Evolution.
Theoretical framework that is usually extended and adapted in real world application. Two Generic Models:
Waterfall Model. Evolutionary Model.
Waterfall Model
The phases overlap and feedback to each other (see the feedback arrow in the diagram). Waterfall Model: Advantages
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.
Th t t i
3/20/2013 11
Throwaway prototyping:
Understands the requirement and develop a better requirement definition.
Initial version Outline description
Experimenting with poorly understood requirement. Usually develops User Interface (UI) with minor or no functionality.
Evolutionary Model: Advantages
Customer involvement in the process: More likely to meet the user requirement.
Early and frequent testing:
More likely to identify problems 3/20/2013 12 More likely to identify problems.
Lower risk.
Evolutionary Model
Final version Development Intermediate versions Specification
Tangible products (the various documents) at the end of every phases → good to measure progress.
Cannot adapt to changing or incorrect 3/20/2013 8
Intuitive sensible and general purpose:
3/20/2013 7
Intuitive, sensible and general purpose: Emphasize planning before action.
Recommend a top-down perspective. See the big picture before zooming down.
Waterfall Model: Problems
Specification is frozen early, because: It is costly and time consuming. Later stages can be carried out.
specification: Ignore or code around.
3/20/2013 10 Validation
Does not meet user requirement.
Testing at the very end of development: Work or die situation.
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 3/20/2013 9 g p observations.
Evolutionary Model
Evolves an initial implementation with user feedback → multiple versions until the final version.
Specification Initial Concurrent activities
Suitable for small to medium sized system. Evolutionary Model: Problems
The process is intangible: No regular, well-defined deliverables.
3/20/2013 17 Early increments can serves as prototypes.
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.
Incremental Model: Advantages
Early utilization:
the 1 st increment satisfies the most critical requirement.
Early increments can serves as prototypes.
Lower risk of overall project failure.
3/20/2013 16
Most crucial and basic services are implemented first → receives multiple testing throughout development.
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
3/20/2013 18 shared by all subsequent increments.
AGILE method: eXtreme Programming (XP) Not covered here.
q
Freezes requirement for the current Increment.
The process is unpredictable: Hard to manage, e.g., scheduling, workforce allocation, etc.
Requirements Split into i t
Systems are poorly structured: 3/20/2013 13
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.
Incremental Model
Combine the advantages of Waterfall and Evolutionary Model.
Design S t
3/20/2013 14 Outline increments System
Architecture Develop
Increment Validate
Increment Integrate
Increment Validate System
Final System Incremental Model Each increment is a mini-waterfall.
3/20/2013 15 Incremental Model Prioritizes the services to be provided by the system.
Maps these requirements to Increment based on priority.
Popular variant:
Spiral Model
Definitive activities and deliverables as in the Waterfall Model.
Iterative and incremental processes.
A project is split into several phases:
3/20/2013 23
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.
State of the art process, by learning from the history of previous software development processes.
Unified Process: 4 Phases
Inception: Plan the project. Evaluate risk.
Elaboration: Understand problem domain.
Design system architecture
3/20/2013 24 Design system architecture.
Plan development.
Construction: Design, programming and test.
3/20/2013 22 Unified Process Integrating two seemingly contradicting insights:
Unified Process
Formalize the Evolutionary Model and avoid the management shortcomings.
Spiral Model
3/20/2013 19 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°):
Obj ti S tti 3/20/2013 20
Objective Setting. Risk Assessment and Reduction. Development and Validation. Planning.
As loops move away from center → Time and Cost increase.
May resemble other process model depends on needs.
Risk Driven:
Explicitly identify risks for each iteration. Address the highest perceived risk.
Does not prescribe a fix process:
P j t M h th i t ti it 3/20/2013 21
Project Manager chooses the appropriate activity for each iteration base on progress and perceived risk.
Flexible:
Transition: Moving system from developer to user environment. Acceptance testing, release of full system. Other Process Models
Formal System Development:
A system can be viewed in different ways, usually depends on the role of the viewer.
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 d li h
3/20/2013 28 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.
UML: 4 + 1 View Models
UML supports this by providing the 4 + 1 View
Not a SE method or software development process.
Models [Kruchten, 1995]:
3/20/2013 29 System
Design View Implementation View Deployment View Process View Use Case View Use Case View
Audience: System Analyst, End Users and Testers.
Usage:
Describes the system’s external behaviour 3/20/2013 30 Describes the system s external behaviour.
Defines the requirements of the system, so it constraints all the other views.
UML: Brief History
Transforms a mathematical based specification through different representation → executable program.
Visualize, construct, document software system.
Program correctness is easy to demonstrate, as the transformations preserve the correctness.
Reuse Oriented Development: 3/20/2013 25
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.
Unified Modeling Language (UML)
A visual language to
Similar to all other languages, UML has: Grammar: Rules to follow when drawing diagrams.
There are tools that implement the UML standard, e.g., ArgoUML, Visual Paradigm, RationalRose.
Semantics: The meaning behind each diagram 3/20/2013 26 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.
What 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.
N t ft d li t l
3/20/2013 27 Not a software modeling tool.
Has the central role in driving the development process. Example of Use Case
D ib h i l t th t d l d 3/20/2013 35
Audience: System Analyst, Programmer and Tester.
Usage: Non-Functional requirements.
3/20/2013 34 Defines concurrency within the system.
Relatively undeveloped.
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.
Useful for configuration management and system integration.
Computer specification.
Relatively Undeveloped.
UML 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.
3/20/2013 36 Model element:
Independent graphical notation element, e.g., a box, an arrow, etc, that has a well defined meaning.
Process View
Describes the physical components out of which 3/20/2013 33 the system is to be constructed: executable files, libraries of code, databases.
Elevator System
Use case 2: ‘Move From Inside’ is this written story:
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;
3/20/2013 31 DownButton; Exception 2: If the lift is at the top floor, then there is no
UpButton;
The userFromInside can select a floor number (from 1 to the
Usage:
number of floors of the building), or can press “Open”, “Close”.
Design View
Audience: System Analyst and Programmers.
Usage:
Describes the logical structures that support the 3/20/2013 32 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.
Implementation View
Audience: System Engineer and Tester.
Diagram: Graphical presentation of a collection of model elements. UML Diagrams by Views
1. Use case diagram (use case view)
Compile time Run time
Sequence diagram
Collaboration diagram
Implementation:
Component diagram
Deployment diagram Design Model and Code
Models present an abstract view of system.
Implementation adds enough detail to make these models executable.
UML model Object structures
UML specifies 3/20/2013 40 Source code Executing program
Java Abstract view of Abstract view of specifies
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
3/20/2013 41 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.
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
3/20/2013 42 Analysis and Design activities in the UP workflow.
Activity diagram
State diagram
2. Object diagram (use case and design views)
Static: Logical Structure, e.g., relationship between classes, attributes of a class, etc. Dynamic: Behavior of the system, e.g., how to
3. Sequence diagram (use case and design views)
4. Collaboration diagram (use case and design views) Cl di (d i i )
3/20/2013 37
5. Class diagram (design view)
6. Statechart diagram (design and process views)
7. Activity diagram (design and process views)
8. Component diagram (implementation view)
9. Deployment diagram (deployment view)
UML Diagrams by Characteristic
Software system exhibits two characteristics:
3/20/2013 38
3/20/2013 39
y y g
respond to a certain event, how to initiate an action, etc.
In addition, knowledge about setting up and running the system: Implementation.
UML Diagrams by Characteristic
Static:
Use case diagram
Class diagram
Dynamic: Object diagram
State diagram
Because of their history, there is a close fit between UML and the UP. UP: Requirement and Analysis UP: Analysis and Design
Analysis and Design usually overlap in UP as the same diagrams are used. UP starts with
use Proceed by Realization and Refinement. cases describing how users interact with the system:
A domain model records facts about real world entities.
UML use case and class
diagrams document 3/20/2013 these. 43 3/20/2013 44 UP: Realization and Refinement UP: Specifying Behavior
UML provides State Chart to document the
Use case
realizations indicate how the behavior of classes. 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 3/20/2013 diagram. 45 3/20/2013 46 Summary (1) Summary (2)
Waterfall Process Model:
Incremental Process Model in response to
Development activities in a linear fashion.
incremental nature of development:
Requirements to freeze very early in Delivery in increments. development.
Allows prioritizing risks in development. Allows prioritizing risks in development. T Testing very late in the process. ti l t i th
Allows different process models for different
Evolutionary Process Model in response to increments. iterative nature of development: Use of prototyping. 3/20/2013 Requirements evolve with users’ feedback. 47 3/20/2013 48 Summary (3)
Spiral Model:
Unified Process
[Priestley; 2004], Chapter 4
[Wadhwa, Andrei, Soo; 2007], Chapters 2 and 3
3/20/2013 51 Coming up next Use Case Modeling, Domain Modeling:
[Wadhwa, Andrei, Soo; 2007], Chapter 2 [Sommerville; 2008], Chapters 1 and 4 [Priestley; 2004], Chapter 3
Reading Suggestions
4 + 1 View models Using UML in UP
History
Overview of UML
Spiral Model 3/20/2013 50 p
Addresses incremental and iterative nature of development.
Incremental Model
Evolutionary Models
Waterfall Model
Software Development Models
Summary
Unified Process: Incorporates best industry practices. Extensive use of UML models. Allows iteration of workflows.
Allows use of multiple process models.
3/20/2013 49 p p
Allows risk evaluation at every phase. Expensive process.
3/20/2013 52 Thank you for your attention! 3/20/2013 53 Questions?