Object-Oriented Software Design and Software Processes Hans - - PowerPoint PPT Presentation

▶
object oriented software design and software processes
SMART_READER_LITE
LIVE PREVIEW

Object-Oriented Software Design and Software Processes Hans - - PowerPoint PPT Presentation

Apr 15, 2023 356 likes •787 views

Object-Oriented Software Design (COMP 304) Object-Oriented Software Design and Software Processes Hans Vangheluwe Modelling, Simulation and Design Lab (MSDL) School of Computer Science, McGill University, Montr eal, Canada Hans Vangheluwe

slide-1
SLIDE 1

Object-Oriented Software Design (COMP 304)

Object-Oriented Software Design and Software Processes

Hans Vangheluwe

Modelling, Simulation and Design Lab (MSDL) School of Computer Science, McGill University, Montr´ eal, Canada

Hans Vangheluwe hv@cs.mcgill.ca 1

slide-2
SLIDE 2

Overview

  • 1. (Software) Process: definition
  • 2. Various Software Processes
  • 3. The Process Influences Productivity:

Dynamic Process Modelling using Forrester System Dynamics

Hans Vangheluwe hv@cs.mcgill.ca 2

slide-3
SLIDE 3

Process: A Queueing System

Physical View Queue Cashier Departure Arrival Departure Queue Abstract View Cashier [ST distribution] [IAT distribution] Arrival

Hans Vangheluwe hv@cs.mcgill.ca 3

slide-4
SLIDE 4

Event/Activity/Process

Cust2 Process Cust1 Activity

Cust2 Arrival Cust2 Start Queueing Cust2 End pay cashier Cust2 Leave

t

Cust2 End Queueing Cust2 Start pay cashier

Cust2 Activity Event

Cust1 Arrival Cust1 Start pay cashier Cust1 End pay cashier Cust1 Leave

Cust1 Process Cust2 Activity queue pay cashier pay cashier

Hans Vangheluwe hv@cs.mcgill.ca 4

slide-5
SLIDE 5

Software Processes

“The Software Engineering process is the total set of Software Engineering activities needed to transform requirements into software”.

Watts S. Humphrey. Software Engineering Institute, CMU. (portal.acm.org/citation.cfm?id=75122)

Hans Vangheluwe hv@cs.mcgill.ca 5

slide-6
SLIDE 6

Software Processes

  • Waterfall (Royce)
  • V Model (German Ministry of Defense)
  • Prototyping
  • Operational Specification (Zave)
  • Transformational (automated software synthesis) (Balzer)
  • Phased Development: Increment and Iteration
  • Spiral Model (Boehm)
  • Rational Unified Process (RUP)
  • Extreme Programming (XP)
  • System Dynamics (Dynamic Process Model)

(see Process ∼ Productivity)

Hans Vangheluwe hv@cs.mcgill.ca 6

slide-7
SLIDE 7

Shari Lawrence Pfleeger. Software Engineering: Theory and Practice (Second Edition). Prentice Hall. 2001. Chapter 2: Modelling the Process and Life Cycle.

Hans Vangheluwe hv@cs.mcgill.ca 7

slide-8
SLIDE 8

Waterfall Process (Royce)

Hans Vangheluwe hv@cs.mcgill.ca 8

slide-9
SLIDE 9

Waterfall Process in Reality

Hans Vangheluwe hv@cs.mcgill.ca 9

slide-10
SLIDE 10

Waterfall Process with Prototyping

Hans Vangheluwe hv@cs.mcgill.ca 10

slide-11
SLIDE 11

V Model (German Ministry of Defense)

Hans Vangheluwe hv@cs.mcgill.ca 11

slide-12
SLIDE 12

Prototyping Process

Hans Vangheluwe hv@cs.mcgill.ca 12

slide-13
SLIDE 13

Operational Specification Process (Zave)

Hans Vangheluwe hv@cs.mcgill.ca 13

slide-14
SLIDE 14

Transformational Process

Hans Vangheluwe hv@cs.mcgill.ca 14

slide-15
SLIDE 15

Phased Development Process

Hans Vangheluwe hv@cs.mcgill.ca 15

slide-16
SLIDE 16

Phased Development: Incremental vs. Iterative

Hans Vangheluwe hv@cs.mcgill.ca 16

slide-17
SLIDE 17

Spiral Model (Boehm)

Hans Vangheluwe hv@cs.mcgill.ca 17

slide-18
SLIDE 18

The Rational Unified Process (RUP): Activity Workload as Function of Time

Hans Vangheluwe hv@cs.mcgill.ca 18

slide-19
SLIDE 19

The (Rational) Unified Process ((R)UP): Empirical Observations

  • 1. Waterfall-like sequence of

Requirements, Design, Implementation, Testing.

  • 2. Not pure waterfall:
  • Phased Development (iterative)
  • Overlap (concurrency) between activities
  • 3. Testing:
  • Regression (test not only newly developed,

but also previously developed code)

  • Testing starts before design and coding

(Extreme Programming)

Hans Vangheluwe hv@cs.mcgill.ca 19

slide-20
SLIDE 20

RUP: Phased Development

Use:

  • descriptive
  • prescriptive
  • proscriptive

Hans Vangheluwe hv@cs.mcgill.ca 20

slide-21
SLIDE 21

Extreme Programming (XP)

(www.extremeprogramming.org)

Hans Vangheluwe hv@cs.mcgill.ca 21

slide-22
SLIDE 22

Extreme Programming (XP) highlights

User Stories are written by the customers as things that the system needs to do for them (requirements). They drive the creation of acceptance tests.

Hans Vangheluwe hv@cs.mcgill.ca 22

slide-23
SLIDE 23

Extreme Programming (XP) Process

The project is divided into Iterations. The “inner loop” is a daily cycle!

Hans Vangheluwe hv@cs.mcgill.ca 23

slide-24
SLIDE 24

Extreme Programming (XP) highlights

Use Class, Responsibilities, and Collaboration (CRC) Cards to design the system.

Hans Vangheluwe hv@cs.mcgill.ca 24

slide-25
SLIDE 25

Extreme Programming (XP) highlights

  • Code the Unit Test first (from requirements/user stories).
  • All code must have Unit Tests; All code must pass all unit tests

before it can be released.

Hans Vangheluwe hv@cs.mcgill.ca 25

slide-26
SLIDE 26

Extreme Programming (XP) highlights

Refactor whenever and wherever possible.

  • for readability (∼ maintanability)
  • for re-use
  • for optimization
  • . . .

Refactoring code or design. Catalog of Refactoring Patterns (rules): http://www.refactoring.com/catalog/

Hans Vangheluwe hv@cs.mcgill.ca 26

slide-27
SLIDE 27

Refactoring Pattern: Reverse Conditional

  • Motivation: increase clarity.
  • Mechanics: (1) remove negative from conditional; (2) Switch

clauses.

  • Example:

if ( !isSummer( date ): charge = winterCharge( quantity ) else: charge = summerCharge( quantity ) ⇒ if ( isSummer( date ) ): charge = summerCharge( quantity ) else: charge = winterCharge( quantity )

Hans Vangheluwe hv@cs.mcgill.ca 27

slide-28
SLIDE 28

Refactoring Pattern: Consolidate Duplicate Conditional Fragments

  • Motivation: increase clarity, performance optimization.
  • Mechanics: lift commonality out of conditional.
  • Example:

if (isSpecialDeal()): total = price * 0.95 send() else: total = price * 0.98 send() ⇒ if (isSpecialDeal()): total = price * 0.95 else: total = price * 0.98 send()

Hans Vangheluwe hv@cs.mcgill.ca 28

slide-29
SLIDE 29

Refactoring Pattern: Split Loop

  • Motivation: increase clarity (not performance optimization (yet)).
  • Mechanics: lift commonality out of conditional.
  • Example:

def printValues: averageAge = 0 totalSalary = 0 for person in people: averageAge += person.age totalSalary += person.salary averageAge = averageAge / people.length print averageAge print totalSalary ⇒

Hans Vangheluwe hv@cs.mcgill.ca 29

slide-30
SLIDE 30

def printValues: averageAge = 0 for person in people: averageAge += person.age averageAge = averageAge / people.length print averageAge totalSalary = 0 for person in people: totalSalary += person.salary print totalSalary

Hans Vangheluwe hv@cs.mcgill.ca 30

slide-31
SLIDE 31

Refactoring Pattern: Pull Up Method

  • Motivation: re-use.
  • Mechanics: pull up identical (type-wise) methods from (all)

sub-classes.

  • Example:

Hans Vangheluwe hv@cs.mcgill.ca 31

slide-32
SLIDE 32

Extreme Programming (XP) highlights

Pair Programming

(www.charm.net/∼jriley/pairall.html)

Hans Vangheluwe hv@cs.mcgill.ca 32

slide-33
SLIDE 33

Advantages:

  • Higher Quality
  • Collective Ownership of code/design
  • Productivity Increase (“flow”) thanks to programmer/backseat

pair

  • Learning/Training
  • . . .

Hans Vangheluwe hv@cs.mcgill.ca 33

slide-34
SLIDE 34

Extreme Programming (XP) Process

Hans Vangheluwe hv@cs.mcgill.ca 34

slide-35
SLIDE 35

The Process influences Productivity

“Adding manpower to a late software project makes it later”

Fred Brooks. The Mythical Man-Month. (www.ercb.com/feature/feature.0001.html)

Hans Vangheluwe hv@cs.mcgill.ca 35

slide-36
SLIDE 36

Why Brooks’ Law ? Team Size.

Model in Forrester System Dynamics using Vensim PLE (www.vensim.com)

development rate = nominal_productivity* (1-C_overhead*(N*(N-1)))*N

Hans Vangheluwe hv@cs.mcgill.ca 36

slide-37
SLIDE 37

Team Size N = 5

Hans Vangheluwe hv@cs.mcgill.ca 37

slide-38
SLIDE 38

Team Size N = 3 . . . 9

Optimal Team Size between 7 and 8

Hans Vangheluwe hv@cs.mcgill.ca 38

slide-39
SLIDE 39

The Effect of Adding New Personnel (FSD model)

development rate = nominal_productivity* (1-C_overhead*(N*(N-1)))* (1.2*num_exp_working + 0.8*num_new)

Hans Vangheluwe hv@cs.mcgill.ca 39

slide-40
SLIDE 40

5 New Programmers after 100 days

Hans Vangheluwe hv@cs.mcgill.ca 40

slide-41
SLIDE 41

5 New Programmers after 100 days

Hans Vangheluwe hv@cs.mcgill.ca 41

slide-42
SLIDE 42

0 . . . 6 New Programmers after 100 days

Hans Vangheluwe hv@cs.mcgill.ca 42