CMPT 275 Software Engineering

1
CMPT 275Software Engineering

• Introduction

2
Software Development Paradigms

• ParadigmThe generally accepted view or
  perspective held by a group or subject
  discipline.
• Software Development Paradigm
• Set of techniques used to guide the software
  development process.

3
Evolution of software paradigms

• Early computers could only solve small
  problems. Solutions were simple and were
  implemented with basic tools
• As computers evolved and became more powerful,
  larger and more complex problems became solvable
• As problems became more complex, software
  development paradigms evolved to manage the
  complexity

4
paradigm evolution

• Lets take a quick look at the evolution of
  software development paradigms
• Early programs were written in assembler and had
  minimal or no formal methods for design
• Higher level languages were invented to simplify
  programming, still no formal methods for design
• Higher level languages continued to evolve

5
Early Software Engineering - 1

• Structured Programming (late 60s, early 70s)
• Avoid gotos
• For more about goto's see
• www.acm.org/classics/oct95/
• www.cs.pdx.edu/apt/cs302_1999/lecture5/lecture5.h
  tml
• www.azillionmonkeys.com/qed/goto.html
• In Structured Programming, goto's are replaced by
  function calls and loops, hence structure and
  control flow is simplified
• This gives a cleaner and easier to understand
  implementation and improves the ease of
  maintenance

6
Example of go to

• 30 continue
• 40 if (k .ge. 23) then
• x 3y
• k k-1
• go to 30
• else
• x y
• endif

• while( k gt 23)
• x 3 y
• k - 1
• x y

BECOMES
7
Early Software Engineering - 2

• Functional Decomposition
• Help manage complexity of large software system
  by iteratively decomposing it into a series of
  increasingly detailed conceptualizations
• Uses a structure chart to represent these
  conceptualizations (modules) and their
  interrelations.
• Each module can be implemented using a function,
  process, or subroutine
• Objectives
• Understand the software system abstractly
• Use decomposition to produce well-structured
  software system
• Used in Process-Oriented Paradigm

8
Example Structure Chart
Book Tracking System
Check Out Books
Add new Book
Check in Book
Report Lost Book
Reshelve Books
Check for overdue Books
Update librarian work Information
Change Book Status
Update Patron Information
Update Reshelving list
9
What is missing

• What data are shared amongst the modules
• How modules interact with each other (we know
  which modules interact but not how)
• This information is not recorded even it was
  discovered during the conceptualization process

conceptualization
representation
implementation
10
Software Engineering - 3

• Structured Analysis and Design
• First methodology set of techniques that
  describe entire software development process .
• Recognition that problem analysis and design of
  the software solution are important steps in the
  software development process.
• Introduction of new modeling notation, data flow
  diagrams (DFD), which show
• The sub processes that are invoked
• The information that is transmitted between these
  sub processes (How they interact)
• Used in Process-Oriented Paradigm

11
Partial Dataflow Diagram
Write Patron record
Patron record
Patron ID
Update Patron Information
Check-inbooks
True/false
Patron record or null
Book ID, in
Patron ID
Book ID
Read Patronrecord
Change bookstatus
Read book record
Book record
Book record
Update Reshelving List
Book record
Write book record
12
Software Engineering - 4

• Data-Centered Paradigm
• Uses techniques developed in Structured
  Analysisbut extends it. First a central data
  depository (relational database) is designed
  using data modeling
• Data modeling occurs using entity relationship
  (ER) diagrams before functional modelling (and
  before other software are developed)
• After data modeling, applications using data from
  the central data repository can be developed
• Such applications can be designed using
  structured analysis and design (or other
  development paradigms)

13
ER Diagrams

• Original purpose was for the design of relational
  databases
• ER Diagrams use boxes to denote entities.
  Entities are the things (abstract objects) than
  comprise the system. Entities can have attributes
  that describe their properties (data associated
  with them)
• ER Diagrams use diamonds to denote relationships
  between entities.
• ER Diagrams show
• how entities are related to each other
• Cardinality how many instances of each kind of
  entities may join a relationship. (Notation
  differs)

14
Entity Relationship Diagram
LibraryPatron
1
M
Address
Has-a
1
1
1
Requested by
Checks out
Has-a
M
M
1
1
M
Book
Publisher
Has-a
Assume the library has no more than 1 copy of
each book
15
Example relationships

• Each library patron can request or check out many
  books (arrow points to the single patron)
  relation is one patron to many books
• Each book has one ISBN, each ISBN number
  corresponds to one book, relation is one ISBN
  to one book
• Each library patron has a single address, but
  there may be more than one library patron with
  the same address. Relation is many patrons to one
  address

16
Software Engineering Methods - 5

• Object-oriented Paradigm
• No longer segregates the modeling of functions
  and data
• Objects aggregate data with functions that
  operate on the data

17
Principles of the OO Paradigm

• Abstraction
• Modularity
• Modelling
• Data Abstraction
• Encapsulation
• Inheritance
• Polymorphism

Shared by other paradigms
18
CMPT 275Software Engineering

• Life Cycle

19
Software Life Cycle

• Sequence of processes completed as a software
  project moves from inception to retirement
• At beginning of project development, choose
• Software development paradigm
• Software development process model
• Define the order/manner in which software life
  cycle processes are performed
• Then you are ready to start software
  specification, design, implementation, validation

20
Development Processes

• Next we will discuss a list of processes that
  need to occur some time during the lifetime of a
  project.
• The exact order of the processes and the number
  of times the processes are done will vary
  according to the process model developed
• Some processes can be considered to happen
  before, during or after development
• Other process occur at any time during development

21
Processes

• For each process we consider we will
  decide/indicate when the process will most likely
  occur, give a name for the process, and give a
  list (partial?) of activities that comprise the
  process
• WHEN before, during, after development
• Name of process
• List of activities

22
Development Processes - 1

• WHEN before development
• Concept Exploration
• Identifying idea and need for a product
• Formulate possible approaches to solution (high
  level only)
• Determining feasibility, identifying and
  mitigating risks
• promotion concept and setting up funding/support

23
Development Processes - 2

• WHEN before development
• System allocation
• Estimating, planning and identifying staffing
  needs for each phase
• Determine system architecture

24
Development Processes - 3

• WHEN during development
• Requirements Analysis
• gathering, specifying and analyzing the
  requirements.
• Defining functionality and scope (limits on
  functionality)
• Define interface requirements
• Prioritize requirements
• Validate and Verify requirements

25
Development Processes - 4

• WHEN during development
• System and Software Design
• Design how software will be structured internally
• Establish system architecture
• Select or develop algorithms (if needed)
• Describe software system abstractions and
  relationships
• Analysis of the design and verification that the
  design meets the requirements

26
Development Processes - 5

• WHEN during development
• Implementation
• Programming (and building)
• Verification that implemented software meets all
  requirements
• Plan unit implementation and integration
  (implementation/test)
• Create user manual (operating instructions)

27
Development Processes - 6

• WHEN during development
• Testing (verification of implementation phase)
• Testing modules (unit test)
• Testing combinations of modules (integration
  test)
• Testing the whole system (system test)

28
Development Processes - 7

• WHEN post development
• Installation
• Installation at user site (plan test accept)
• User testing, verifying user needs are met
  (includes user acceptance test or UAT)
• Errors corrected, bugs fixed

29
Development Processes - 8

• WHEN post development
• Operation and Support (maintenance)
• Software enhanced (new features, new
  requirements)
• Errors corrected, bugs fixed
• Evolution to newer platforms (newer OS,
  hardware)
• Retirement post development

30
Integral Processes

• Integral processes take place during all phases
  of development
• Verification and Validation
• Software Configuration and Management
• Configuration Control, Revision management
• Tracking and control of changes
• Documentation development / distribution
• Training
• Plan, Develop, Validate, Implement training
  program

31
Life cycle models

• Combine the development processes and activities
  in different ways (different order, once or
  repeated ) to model the life cycle of a project
• By making models of the life cycle of successful
  software projects can help us design better
  approaches to plan the life cycle of future
  projects
• There are several generic life cycle models
  that are often used or used as a basis for design
  of custom life cycle models

32
Generic Life Cycle models

• Sequential (activity centered) Perspective
• The waterfall method
• V model
• Iterative (activity centered) development
• Evolutionary
• Spiral

33
Types of Generic Process Models - 2

• Component Based Perspective
• Focus on applying reusable components (most
  already exist)
• Rational Unified Process
• Combines aspects of all three perspectives
• Useful for large systems

34
Waterfall Process Model
Project Initiation
Concept Exploration
System Allocation
Requirements
Design
Implementation
Verification Validation
Installation
Operation Support
35
Waterfall Process Model
Project Planning
RequirementAnalysis
Design
Implementation Testing
Maintenance
36
V Model
System Requirements Allocation
Operation
Client Acceptance
Requirements Elicitation
System Integration/test
Requirements Analysis
Component Integration/test
Preliminary Design
Unit Test
Detailed Design
Implementation
37
Why a Waterfall Process Model?

• Phases (processes) are performed once
• Makes the process easy to follow
• One phase should not be started until the
  previous one is complete
• Makes the process easy to manage
• Documents need only be produced and approved once
  (this is a costly process)
• Parallels other engineering process models
• The waterfall method should only be used if the
  requirements are well understood

38
Why not ?

• Impractical to fully complete any one of
  thephases before starting the next one
• difficult to capture all requirements before
  proceeding to design
• Users dont get to see the results until the end
• problems may emerge only at the end when user
  realizes the product is not what was needed

39
Fixing the problems

• How can we modify these sequential life cycle
  model to address these problems
• Prototypes
• can be useful to show to the user to catch
  problems before implementation
• can also be misleading as the client must
  understand that the system is not almost ready
• Allow for return to earlier processes to update
  models to include changes to fix deficiencies
  found in later processes incorporate iteration
• Allow for an incremental approach of developing a
  basic solution, then adding additional
  functionality