Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2 - PowerPoint PPT Presentation

About This Presentation
Title:

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

Description:

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2 * CPSC-4360-01, CPSC-5360-01, Lecture 2 * * CPSC-4360-01, CPSC-5360-01, Lecture 2 * Implementation View ... – PowerPoint PPT presentation

Number of Views:210
Avg rating:3.0/5.0
Slides: 55
Provided by: NUS171
Learn more at: http://galaxy.lamar.edu
Category:

less

Transcript and Presenter's Notes

Title: 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?
Write a Comment
User Comments (0)
About PowerShow.com