topic 9summer 2003 1 ics 52: introduction to software engineering lecture notes for summer quarter,...

Topic 9 Summer 2003 1

ICS 52: Introduction to Software Engineering

Lecture Notes for Summer Quarter, 2003

Michele RousseauTopic 9

Partially based on lecture notes written by Sommerville, Frost, & Easterbrook. Duplication of course material for any commercial purpose without the written

permission of the lecturers is prohibited


Today’s Lecture

A brief introduction to Classes & Objects


Noun extraction for design• Complements design by information

hiding


Remember this?

issue ()sendReminder ()acceptPayment ()sendReceipt ()

invoice#dateamountcustomer

Invoice

invoice#dateamountcustomer#

Receipt

invoice#dateamountcustomer#

Payment

customer#nameaddresscredit period

Customer

• Invoice Processing System – Object Model

This system can: •Issue invoices to customers

•Receive payments•Issue receipts for payments •Issue reminders for unpaid invoicesThe dashed line means that one object

uses the attributes or services of another object


Choosing classes & objects

At the conceptual level: an object is a set of responsibilities, including responsibility for itself (encapsulates functions and data)

At the specification level: an object is a set of methods (its interface) , which can be invoked by itself or other objects

At the implementation level: an object is code (methods) and data (attributes)

Object Oriented approach attempts to manage complexity in real-world problems


Objects

Have Public and Private sides OOD –views the world as a system of

cooperating collaboration agents.


Some Terminology

Encapsulation – bundling operations and data that are conceptually linked (like putting them in a capsule)

Information Hiding – Making the capsule opaque

Method – an action Attribute – a variable/constant Object – primitive programming element Class – a generic specification for an

arbitrary number of similar objects – (abstract, template)


An OOD Process

Find the classes in your system Determine operations for each class Determine how objects will need to

collaborate with each other


Hints for Choosing Classes

How do I find classes, attributes and so on?• Look at the requirements

»classes often correspond to nouns»attributes often correspond to abstract

nouns»operations often correspond to verbs


Determining Classes

Model physical objects (employees, invoices, printers, etc..)

If more than 1 word is used for the same concept choose the one that is most meaningful.

Be wary of adjectives – does it describe new behavior?

Model known interfaces Model the values of attributes – but

don’t model attributes• e.g. Line and length – class or attribute


A class should ...

represent a coherent concept• Principle: Low Coupling, High Cohesion

have a small, well-defined set of responsibilities

be named with a singular noun that says what each each instance of the class is

have no more than 10-20 operations


An Example

FastData Inc. wants a subsystem to process office supply orders via the Web. The user will supply via a form their name, password, account number, and a list of supplies along with an indication of the quantities desired. The subsystem will validate the input, enter the order into a database, and generate a receipt with the order number, expected ship date, and the total cost of the order. If the validation step fails, the subsystem will generate an error message describing the cause of the failure


You may need to rewrite

Make it concise. “FastData, Inc. employees may order

office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.”


Formalize the Strategy

Identify the nouns of the description, which serve as the basis for identifying the subsystem’s classes.

Look for out-of-domain nouns (and throw them out!)

Look for abstract nouns (use these for attributes)

The remaining nouns are good candidates for classes!


Find the nouns

“FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.”


Nouns

– Employees– Office Supplies Item– Internal Web– Receipt – Order – User name– User password

– Account number

– Order number– Ship date– Total cost– Order database– Error message– List of supplies


Nouns

Out-of-Domain• Internal Web

Abstract• user name• user password• account number• order number• ship date• total cost• list of supplies

Good Candidates• employee• item (was office

supplies)• receipt• order• order database• error message

Notes• We have decided not

to worry about the Web in this design. Instead we focus on the inputs and outputs and defer the Web details until later.


Basic Classes

Employee

NamePasswordAccount #

Order NumberEmployeeItem

Error Message

Item

OrderShip DateTotal cost

Receipt

Order

Order Database

This gives us a starting place to refine and revise


Assigning Responsibilities

Responsibilities include 2 key items• The knowledge an object maintains• The actions an object can perform

An object is a client when it requests services from another object.

An object is a server when it fulfills a request from another object.

Where to look –• Requirements• Classes


Identifying Responsibilities

Look for the verbs • Which ones clearly represent actions

that some object must perform• Note where information is mentioned

» Information an object must maintain and manipulate

Look at they system as a whole (walkthrough)

Look at the classes


Assigning Responsibilities

Try to evenly distribute system intelligence

State responsibilities as generally as possible

Keep behavior with related information Keep information about 1 thing in 1

place Share responsibilities among related

objects


What Operations go with which Class?

Employee

NamePasswordAccount #

Order NumberEmployeeItemSendReceipt()SendErrorMsg()AddItem()

Error Message

Item

OrderShip DateTotal cost

Receipt

Order

Order Database


Final Notes

Refine, Revise Define relationships


Design Recap


Important concepts

Architectural styles Information hiding Noun extraction Uses diagram Comprises diagram


How do we decide if a design is the best possible design?

Ability to predict comes with experience Qualities to look for: Verifiability,

Maintainability, Repairability, Evolvability, Reusability, Portability, Understandability, Interoperability

Principles to maintain: Rigor & formality, Separation of concerns, Modularity, Abstraction, Anticipation of change, Generality


What is a Good Class?

…and what should not be a class? A class should be named with a noun

• Example: “class Book” A class should not represent a task or operation

• Don’t do this: “class FindABook”• Don’t have classes described as “performing” something

A class should contain several related operations• These correspond to the class’ responsibilities

A class should contain at least one attribute A class should represent a single abstraction


Is fan-in, fan-out relevant?

Yes, but it’s not as important as other indications of a good design

High cohesion and low coupling are the most important

For smaller systems, the uses diagram is the next most important

For larger systems, the comprises diagram is also important


How does high level architecture affect module interaction?

Architectural styles restrict the way in which components can be connected• Prescribe patterns of interaction• Promote fundamental principles

»Rigor, Separation of concerns, Modularity, Abstraction, Anticipation of change, Generality, Incrementality

»Low coupling, High cohesion


Do we have to code up the modules?

Yes, but later.


Why do we define levels in the uses diagram?

The process of doing so helps identify cycles (which are usually bad)

The levels are used in making an integration test plan


How many levels should we have in a uses diagram?

It depends. Small systems may only have 2 or 3 Larger systems may have many more,

or they may remain fairly “shallow”


Acceptance testing?

Acceptance testing is performed after implementation and integration testing is complete, before the product is given to the client

Acceptance test plans are made during the requirements phase

The acceptance test plan includes a high-level description of what is being tested, and specific test inputs, along with expected outputs.


Integration testing?

Integration testing is performed after implementation and module testing, before acceptance testing

The integration test plan is made during design

The integration test plan includes a plan of the order of integration and specific test cases.


Integration Testing


V-Model of Development and Testing

Develop Acceptance TestsAcceptance Test Review

Requirements ReviewDevelop Requirements Execute System Tests

Develop Integration TestsIntegration Tests Review

Design ReviewDesign Execute Integration Tests

Develop Unit TestsUnit Tests Review

Code ReviewCode Execute Unit Tests


Integration Test Plans

Goal (Why?)• Ensure modules make compatible assumptions about

each other. • Exercise interfaces between modules, as opposed to

functionality within modules Hard part:

• Identifying interactions that reveal agreement or disagreement on assumptions

Approach (How?)• Combine more and more modules• Use USES hierarchy

» Work up from lowest numbers Use test harnesses to test each group of modules

» Work down from highest numbers Use stubs as mockups to test each group of modules

Test execution can be done during implementation effort


Integration Test Example

Provided Interface

Main componentRequired Interface

Provided Interface

SubcomponentRequired Interface

Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface



Integration Testing Tools

Extra code you write for integration testing. Needed because not all modules are ready at the same time.

Harnesses or drivers•Call or invoke modules and pass parameters

to them

Stubs•Are called by modules, do minimal

processing, return reasonable values


Test Harnesses (bottom-up integration)

Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface

Test HarnessRequired Interface

Provided Interface

Test HarnessRequired Interface


Stubs(top-down integration)

Provided Interface


Provided Interface

StubRequired Interface

Provided Interface


Provided Interface



Stubs

Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface



Integration Testing Strategies

Integrate and test increasingly larger subsets of modules

Top-down integration testing•Can be done before units are fully coded•Requires stubs

Bottom-up integration testing•Requires test harnesses or drivers•Can thoroughly test lower modules but

postpones detection of major integration problems

Hybrid of both most common in practice

topic 9summer 2003 1 ics 52: introduction to software engineering lecture notes for summer quarter,...

Documents

summer quarter

classes objects

attribute slide

template slide

michele rousseau topic

nouns attributes

dont model attributes

requirements classes