CISC 323 Introduction to Software Engineering Week 3 OOP, UML, - - PowerPoint PPT Presentation

CISC 323 Introduction to Software Engineering

Week 3 OOP, UML, Software Process Lecture 1: Software Process

• ✁

• ☎

• ✓

• ☎

Software Process

• To manage complexity of software, require a

process that codifies the activities of software design, development and validation

• There are many processes. Which one is

correct depends on the desired quality attributes of the system under construction.

• Process model: describes process
• Reading: Bahrami Chapter 3

• ☎

• ✓

• ☎

Examples of Software Processes

• Waterfall process
• Incremental process

– Microsoft

• …There are many more!

• ✁

Ad Hoc Process

• analysis ---> code --> test --> code --> test

…

• may work for small program, one

programmer

• for larger systems, doomed to failure

• ✁

Waterfall Model

System Requirements Software Requirements Product Design Program Design Coding Testing Operations

• ✁

Waterfall Model

System Requirements Software Requirements Product Design Program Design Coding Testing Operations

• Description of complete system.
• Boundaries between hardware

and software components.

• Example: brakes in a car
• braking system includes
• foot pedal
• brake pads
• software to control brakes.

• ✁

Waterfall Model

System Requirements Software Requirements Product Design Program Design Coding Testing Operations

Includes: functional requirements E.g., depressing the brake slows the car down

• ✁

Waterfall Model

System Requirements Software Requirements Product Design Program Design Coding Testing Operations Includes: non-functional requirements

• E.g. performance: brakes must

respond within 100 ms of being activated

• E.g., availability: if software

fails, brakes must still function manually.

• ✁

Waterfall Model

System Requirements Software Requirements Product Design Program Design Coding Testing Operations

• Description of functions the

software must fulfill and associated quality attributes.

• Expressed from point of view of a

user of the system.

• Does not include implementation

decisions such as algorithms, data structures used to address these requirements.

• ✓

Waterfall Model

System Requirements Software Requirements Product Design Program Design Coding Testing Operations Example: for course marks program, functions are:

• Student can access system

from any CASLab machine

• Student can specify course in

which he/she is enrolled and request grades for that course

• Grades recorded for that

course will be presented to user in a readable format

• …etc.

• ✁

Waterfall Model

System Requirements Software Requirements External Design Internal Design Coding Testing Operations

• Describes software design meeting the

requirements specified above.

• Design is external, from point of view of a

user of the software.

• Shows how requirements are mapped to

system features.

• ✆

Waterfall Model

System Requirements Software Requirements External Design Internal Design Coding Testing Operations

• May include:
• detailed functional design
• screen mockups
• interaction design.
• Does not describe system implementation,

e.g., algorithms, data structures, etc.

• ☎

Waterfall Model

System Requirements Software Requirements External Design Internal Design Coding Testing Operations Describes implementation of software. Includes, e.g.,

• Deployment architecture
• Component architecture
• Component interfaces
• Data model
• Protocols (how components

communicate with each other.)

• ✁

Waterfall Model

System Requirements Software Requirements External Design Internal Design Coding Testing Operations Actual programming

• f software.

• ✁

Waterfall Model

System Requirements Software Requirements External Design Internal Design Coding Testing Operations Ensuring software performs to specification. Addresses both function and quality attributes.

• ✁

Waterfall Model

System Requirements Software Requirements External Design Internal Design Coding Testing Operations Once software has been delivered, revisions will be required to address

• errors
• new requirements

This is called software maintenance

• ✁

Waterfall Model

System Requirements Software Requirements Product Design Program Design Coding Testing Operations

• ✁

Bahrami's Simplification

What How Do It Test Use

• ✁

Premise of Waterfall Model

• Each step completed successfully provides strong

foundation for next step

• Forces developers to cope with data and control

flows, errors, problems earlier in development

• Each step should be performed by those skilled in

those steps

• Document everything: software requirements,

preliminary design, interface design, final design, test plan/test results, operating instructions

• ✁

• ✆

• ✓

• ✆

Relative Cost to Fix or Change Software Throughout Lifecycle

20 40 60 80 100 120 140 160 Req Code Accept Test Large Project Small Project

• ✂

• ✆

• ✓

• ✆

Waterfall Model

• Emphasis on catching problems early through

requirements, design stages

• ✁

• ✂

• Clear documentation created in each phase
• ✄

• ✞

• Works best for well-understood styles of software
• ✗

• ✂

• ✆

• ✓

• ✆

Strengths and Weaknesses of Waterfall Model (1)

• Primary function

– determine order of stages in software development – set transition requirements from one stage to another

• Waterfall Model

– document (or task) driven – better than ad-hoc process – most widely used process model in standards and industry

• ✔

Strengths and Weaknesses of Waterfall Model (2)

• weaknesses

– emphasis on fully elaborated documents before going

• nto next stage

– only works for well defined, mature, predictable types

• f software

– doesn’t work for highly interactive software, new technology, research – real projects rarely follow sequential flow of model

• ✂

• ✔

Strengths and Weaknesses of Waterfall Model (3)

• weaknesses

– difficult for customer to state all requirements explicitly at start of project – working version of program not available until very late in project life-span – major blunder may not be discovered until very late – sequential style leads to bottlenecks and doesn’t lend itself to parallel activities

• ✂

• ✔

Software Prototyping

traditional understanding of “prototype”: mock-up of a newly engineered product – prototype aircraft to test flying, check systems – make refinements before going into production – have to build nearly whole thing (airframe, engines, cockpit controls, hydraulics, landing gear, electronics, etc.) before test

• ✂

• ✔

Software Prototyping

• for software, prototype used to

– try out on customers

– try out possible trouble areas

• ✁

• ✆

• ✔

• ✆

Key considerations for using Prototypes

• bjectives for each prototype activity should be

clearly established

• define the prototype process ahead (prototyping does

NOT mean hacking)

• results from prototyping effort must be documented

and analyzed before decision on how to proceed

• complete one prototype and analyze results before

starting next iteration

• prototype results can be

• ✂

• ✆

• ✔

• ✆

Competing Philosophies on Prototyping (1)

• throw away prototype

• quick & dirty prototype

• ✆

• ✔

• ✆

Competing Philosophies on Prototyping (2)

• detailed design-driven prototype

• non-functioning mock-ups

• ❍❏■

• ❑

• ❑

• ❑

• ❑

• ❑

• ◆

• ❄

• ❄

• ❄

• ◆

• Weaknesses of Prototyping
• what do we do with prototype when it has served its

purpose?

• customers see what appears to be a working system

• developer has made implementation compromises

• ✁

• The Incremental Model
• combination of waterfall model and prototyping
• each sequence of the process

• first increment is often the core product

• evaluation with user
• plan for next increment
• repeat until full product delivered
• focus on delivery of operational product with each

increment

• Evolutionary Rapid Prototyping
• “an easily built, readily modifiable, ultimately extensible,

partially specified, working model of primary aspects of a proposed system”

• primary objective: “provide a cost-effective means of

discovering the true and complete set of system functional requirements that will optimally satisfy the legitimate business needs of the user”

• not throw-away: evolves into final system
• not quick-and-dirty: detailed analysis and design take

place

• not mock-up: uses real user data

• ✂

• Steps in Evolutionary Rapid

Prototyping (1)

• ***Prototype most important aspects of the system

first***

• ***Have a prototyping process/procedure defined

ahead***

• divide application into well defined pieces
• ✾

• decide order of prototyping different pieces
• ✰

• plan prototyping activities
• ✮

• ✮

• ✂

• Steps in Evolutionary Rapid

Prototyping (2)

• get prototype working
• evaluate your results
• ✦

• ✂

• make refinements
• update requirements documentation
• freeze portion of prototype that’s done
• move on to next piece to prototype
• build final product from prototype pieces
• ❄

• ❄

• ✂

• Evolutionary Rapid Prototyping

• ✂

• Weakness of Evolutionary Rapid

Prototyping

• can easily turn into “quick and dirty”
• non-functional issues such as performance left until

last

• some applications do not lend themselves to rapid

prototyping

CISC 323 Introduction to Software Engineering

Week 3 OOP, UML, Software Process Lecture 2: The Microsoft Process

• References
• MicroSoft Secrets; Cusumano, Selby, Simon &

Schuster Inc., 1995

• How Microsoft Builds Software; Cusumano

and Selby, Communications of the ACM, June 1997 (not required reading)

• ✂

• Philosophy
• Microsoft started as small group of "hackers"
• Old meaning of "hacker": "long-haired, unkempt

technical wizards" hacking away at coding. Creative, very good at getting code up and running quickly.

• As Microsoft grew, needed more structure without

stifling creativity and talent

• Waterfall model also too rigid when user

requirements constantly evolving

• "Synch-and-save" methodology: allows developers to

work in small groups, fairly independent

• Daily builds and constant testing keep groups from

diverging

• ✁

Interesting Numbers

• Windows 95 contains > 11 million lines of

code

• more than 200 programmers & testers

• ✂

The Microsoft Triangle

• Decision making focuses on three of the dimensions of

quality in the end product: – Functions supported – Time to Market – Implementation defects remaining

• rapid development, daily builds, testing buddies
• evolving requirements, work from vision statement
• heavy reliance on testing, multiple testing strategies
• well established plans and schedules

• ✝

Common Principles

• ✁✄✂

• ❇❍

• ✁

Approach

• “Fix” project resources

• Set intended ship date
• Define milestones backwards from target ship date
• No separate maintenance group

• Three phases

• ✂

Microsoft Process

Planning (3-12 months) Stabilization (3-8 months) Development (6-12 months) Stabilization (3-8 months) Milestone 0 Subproject 1 Subproject 2 Subproject 3 Feature Complete Visual Freeze Release Code Complete

• ✂

Microsoft Process

Release Planning (3-12 months) Stabilization (3-8 months) Development (6-12 months) Stabilization (3-8 months) Milestone 0 Subproject 1 Subproject 2 Subproject 3 Code, test,

• ptimize, stabilize

(6-10 weeks) Integration test, debug (2-5 weeks) Buffer time (2-5 weeks)

• ✂

Planning Phase (3-12 months)

• Marketing, vision statement, design goals
• Initial specification

• Project managers do extensive prototyping

Development Phase (6-12 months)

• ✁

Stabilization Phase (3-8 months)

• 1/3 of total time in project
• Extensive testing & debugging
• No new features
• “Zero bug release”

– no more high-severity bugs have been found – decision to postpone fixing all remaining bugs until next release

• ✁

Daily Build Process (1)

• Check Out

• Implement Feature

• Build Private Release

• Test Private Release

• ✁

Daily Build Process (2)

• Synch Code Changes

• Merge Code Changes

• Build Private Release

• Test Private Release

• ✂

Daily Build Process (3)

• Execute Quick Test

• Check in

• ✁

Daily Build Process (4)

• Generate Daily Build

– after check in deadline – build master generates complete build of product from master version

• ✽

• ✁

Role of Program Managers

• Typical structure:

– managers make all design decisions: structure of code and how to divide tasks – developers follow instructions & turn design into code

• Microsoft:

– developers involved in design – manager organizes, keeps records, makes sure decisions get made – success depends on personalities

Testing (1)

• quick tests on daily build
• developers create debug versions

• use assertions “if then” tests

• instrumentation for user testing

• ✁

Testing (2)

• usability testing

– lab with “people off the street” – user interfaces tested

• weekly test releases

– to testing group for thorough testing – use highly structured scripts – “guerrilla” testing

• ✁

Testing (3)

• testing buddies

– work side by side with developers – developer shares private release with his testing buddy – do private release testing before code goes to daily build

• ther kinds

– performance testing – internal usage – beta testing

• ✁

Observations From Book (1)

• little architectural documentation

– source code is one main document – try to keep code as simple as possible – compartmentalize code

• very little code comments

– uses “Hungarian” rules for variable naming

– half life of source code is as little as 18 months

• ✁

Observations From Book (2)

• Cusumano & Selby recommend:

– more use of metrics

• do use bug counts

– design and code reviews

• intensive code inspections
• detect and fix problems before incorporated into product
• refine product architecture
• educate junior developers

• ✂

Observations From Book (3)

• "Synch and save" makes it simpler to react to

customer feedback through development

• Works well for some kinds of applications (Word,

Excel)

• Operating systems (Windows) & applications such as

interactive video are more "tightly coupled"

• These programs would benefit from more up-front

planning

CISC 323 Introduction to Software Engineering

Week 3 OOP, UML, Software Process Lecture 3: Last Details, Review

• ✁

recall abstract classes can contain

• attributes
• concrete methods
• abstract methods

mixture of abstract and concrete

Topic 1: Interfaces

an interface is like an abstract class but contains

• nly abstract methods – no attributes, no concrete methods

completely abstract an interface is a skeleton or template for a class specifies functionality the class must provide nothing about implementation

• ✝

public interface Comparable { public int compareTo(Object o); }

Example From the API

Note: all methods in an interface are abstract. Don't need keyword abstract in declaration Terminology: you extend an abstract class you implement an interface

• ✆

String & Comparable

Many API classes implement Comparable Example: String implements Comparable

• - it has a compareTo method

public class String implements Comparable { .... // body of class includes a concrete // compareTo method }

• ✂

Suppose we want to be able to compare 2 employees

• n the basis of the amount of pay owed to them

Add a compareTo method to Employee and add implements Comparable to the class header

Employee & Comparable

• ✂

Employee & Comparable

public class Employee implements Comparable { public int compareTo(Object obj) { if (obj instanceof Employee) { Employee other = (Employee) obj; if (payOwed == other.payOwed) return 0; else if (payOwed < other.payOwed) return -1; else return 1; } else { return 1; // arbitrary value } // end if } // end compareTo .. rest of Employee class

• ✂

recall: a class can extend only one other class

Multiple Inheritance Revisited

but a class can implement many interfaces distinction between abstract classes & interfaces is Java's answer to multiple inheritance gives most of functionality of multiple inheritance without the implementation headaches

• ✂

Multiple Inheritance Revisited

String implements 2 interfaces: Comparable Serializable (related to I/O) Syntax:

public class String implements Comparable, Serializable {

A class can extend another class and implement interfaces:

public class Executive extends Employee implements Comparable {

• ✂

UML For Interfaces

One way to show interface in Java: class box as before, with <<Interface>> stereotype note: no attributes compartment

<<interface>> Comparable compareTo(Object o): int

Showing "implements"

Use a dashed generalization arrow from a class to an interface it implements

<<interface>> Comparable compareTo(Object o): int Employee

• ✔

Another Way to Show Interfaces

Interface is represented by a small circle with name of interface Solid line between interface and implementing class

Employee

Comparable

• ✂

Generic Code

Interfaces are very useful for writing generic (general-purpose) code Example: sorting Method to sort array of Employees useful

• nly for one purpose

Another kind of object: must write a new sorting method Much better: general method for sorting Objects

• ✝

Generic Sorting

void sort(Object arr[])

problem: need to know how to compare pairs of objects no general answer solution: we will only sort arrays of objects that have a compareTo method – i.e. objects that implement Comparable now signature is void sort(Comparable arr[]) inside method, we can say

if (arr[i].compareTo(arr[j]) < 0) ....

• ✆

API class Arrays provides useful static methods for arrays (search, sort, fill with value, etc.)

API Sorting Method

• ne of the methods:

static void sort(Comparable[] a) This class is in the API package java.util.

• ✂

Using Arrays.sort

Employee company[] = new Employee[SIZE]; // code to fill company array Arrays.sort(company);

This is legal because the Employee class implements Comparable Sorts the array according to compareTo method in Employee So person owed the least money comes first, person owed the most money comes last

• ✂

Recall Java's rules about constructors. Rule 1: If your class has no constructors at all, Java creates default: no parameters, does nothing. All fields left at 0 or null.

Topic 2: Details About Constructors

Rule 2: You can define your own constructor, or lots of overloaded constructors with different numbers & types of parameters. Rule 3: If you define any constructors, you don't get the default. If you want a no-parameter constructor in addition to others, you must write it yourself.

• ✂

public class C { int x; ... // no constructors in this class } ... C obj = new C(); // legal, obj.x = 0

Example

public class C { int x; public C (int val) { x = val; } .... } ... C obj1 = new C(13); // legal, obj1.x = 13 C obj2 = new C(); // illegal!

• ✂

You've seen that you may call the constructor of parent class using keyword super.

Calling "super" constructor

public Salesperson(String empName, String empTitle, double empWage, double empRate) { super(empName, empTitle, empWage); // Employee constructor rate = empRate; } // end constructor

In fact, Java requires a call to a parent constructor. If you don't make one as first line of child class' constructor, Java adds call to super().

• ✂

What if parent class doesn't have a no-parameter constructor?

Potential Problem

public Salesperson(String empName, String empTitle, double empWage, double empRate) { name = empName; title = empTitle; wage = empWage; rate = empRate; } // end constructor

compiler inserts call to super().

super();

But parent class (Employee) has only 1 constructor and it takes 3 parameters! Result: weird error message.

• ✁

You must either:

• give the parent class a no-parameter constructor OR
• make sure all child class constructors call super()

as first statement

Moral

Review For Midterm

Topics: – OOP (some review, some new) – UML – Software Process Logistics: – Monday in section where you are registered – will be 2 different versions – may bring a "cheat sheet" (8.5x11", both sides) – we will be strict about noise & movement – policy: we will not review papers with

• eraser smudges
• white-out

• ✂

UML "Cheat Sheet" (1)

Employee name: String wage: double pay(hours: double) amountToPay(): double

class diagram

Mary: Executive name = "Mary" wage = 35

• bject diagram

Employee Office

• ccupant

workplace

worksIn

association with name, roles, quantifiers

1..* 1

• ✝

UML "Cheat Sheet" (2)

Arrows:

• ✎

• ✎

• ✓

• ✎

• ✣

• ✡

• ✟

• ✟

• ✒✔✓
• ✡

UML "Cheat Sheet" (3)

Abstract Classes & Methods: use italics or write "abstract" Interface: use <<interface>> stereotype or represent by small circle (no methods shown)

CD Song * 1..*

track number

qualifier Resource Skill * * Experience

association class

• ✂

Use Case Diagram

circles are "use cases" stick figures are "actors" non-human actor: box with <<actor>>

• ✁

Sequence Diagram

Customer Cashier Cook

Place order Give money Send food Announce price Give food Request food Ask for more money [until enough money]