Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2

1
Software Engineering, CPSC-4360-01,
CPSC-5360-01,Lecture 2 
2
Overview 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

3
Overview 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

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
• Waterfall Model.
• Evolutionary Model.

5
Waterfall Model

• The earliest software development model (Royce,
  1970).

6
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
• a phase takes place in sequence to another.
• each activity is completed before the next starts.

7
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
• The phases overlap and feedback to each other
  (see the feedback arrow in the diagram).

8
Waterfall 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.

9
Waterfall 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.

10
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.

11
Evolutionary Model

• Evolves an initial implementation with user
  feedback ? multiple versions until the final
  version.

12
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
• Understands the requirement and develop a better
  requirement definition.
• Experimenting with poorly understood requirement.
• Usually develops User Interface (UI) with minor
  or no functionality.

13
Evolutionary 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.

14
Evolutionary 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.

15
Incremental Model

• Combine the advantages of Waterfall and
  Evolutionary Model.

Final System
16
Incremental Model

• Each increment is a mini-waterfall.

17
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
• Allows user to experiment.
• Can be put into service right away.

18
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.

19
Incremental 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.

20
Spiral Model

• Formalize the Evolutionary Model and avoid the
  management shortcomings.

21
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.

22
Spiral 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.

23
Unified Process

• State of the art process, by learning from the
  history of previous software development
  processes.

24
Unified 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.

25
Unified 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.

26
Other 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.

27
Unified 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.

28
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.
• 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.

29
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.

30
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 View
Process View
31
Use 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.

32
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
• The userFromInside can select a floor number
  (from 1 to the number of floors of the building),
  or can press Open, Close.

33
Design 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.

34
Implementation 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.

35
Process View

• Audience
• System Analyst, Programmer and Tester.
• Usage
• Non-Functional requirements.
• Defines concurrency within the system.
• Relatively undeveloped.

36
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.

37
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.
• 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.

38
UML 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)

39
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.

40
UML 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

41
Design 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
42
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.

43
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.

44
UP 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.

45
UP Analysis and Design

• Analysis and Design usually overlap in UP as the
  same diagrams are used.
• Proceed by Realization and Refinement.

46
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.

47
UP Specifying Behavior

• UML provides State Chart to document the behavior
  of classes.

48
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
• Use of prototyping.
• Requirements evolve with users feedback.

49
Summary (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.

50
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
• Incorporates best industry practices.
• Extensive use of UML models.
• Allows iteration of workflows.

51
Summary

• 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

52
Reading Suggestions

• Wadhwa, Andrei, Soo 2007, Chapter 2
• Sommerville 2008, Chapters 1 and 4
• Priestley 2004, Chapter 3

53
Coming up next

• Use Case Modeling, Domain Modeling
• Wadhwa, Andrei, Soo 2007, Chapters 2 and 3
• Priestley 2004, Chapter 4

54
Thank you for your attention!Questions?