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

Topic 8 Summer 2003 1

ICS 52: Introduction to Software Engineering

Lecture Notes for Summer Quarter, 2003

Michele RousseauTopic 8

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


Design Interaction

Architectural design(previous lecture)

Module design(this lecture)


From Architecture to Modules

Repeat the design process• Design the internal architecture of a component• Define the purpose of each module• Define the provided interface of each module• Define the required interface of each module

Do this over and over again• Until each module has…

» …a simple, well-defined internal architecture» …a simple, well-defined purpose» …a simple, well-defined provided interface» …a simple, well-defined required interface

Until all modules “hook up”


Module - Definitions

a software fragment of any size (including “subsystem”)

a collection of routines, data, objects a provider of computational resources

or services

Examples: •Abstract data type -- data structures with accessing and modifying functions

•Class (similar to an ADT)•Package


Abstract Data Type - a kind of module

Goal: Encapsulate the concrete representation of a data structure with functions that access the representation

Users see only the abstract characteristics of the structure

Access to the structure is only through the provided access functions•Abstract does not mean “vague”•Abstract does not mean highly mathematical•Abstract means conceived apart from a

particular implementation


Stack ADT

Class Stack •boolean empty()•Object peek()•Object pop()•Object push(Object obj)


Possible Implementations

Array that is enlarged and copied as necessary

Linked list Linked list of arrays Sorted tree

Does it matter?

Can change with no impact to users of Stack ADT


Module - Alternative Formulation

Something that hides a “secret,” such as•Algorithm (e.g. sorting)•File format•Sequence of processing•Character code (e.g. ASCII v. Unicode)•External interface (hardware and software)•Relation between modules

What is a secret? Any design decision. Who doesn’t know the secret? All other

modules.


Determining a Module's Interface

Interface: the set of services a module provides its clients.

Interface design principles•Design interface to be insensitive to change•Generalize•Interfaces abstract implementation details

»With respect to what is provided»With respect to what is required

Given the interface, any consistent implementation is OK


Module Interfaces

Module exports or provides •methods or information for use by other modules

•these other modules are its “clients”

Module imports or requires:•external functionality this module is going to utilize


Module to Module Interaction

A module hides implementation details (e.g. data structures) so that the rest of the system is insulated and protected from the details

Modules communicate only through well-defined interfaces (e.g. method calls)

Programming languages typically provide lots of ways to violate this!•global variables•public member variables•pointers•shared memory


Module Design 101

Design process:• Identify items likely to change•Confine these to modules•Design module interfaces to be insensitive to change

If internal details change, client units should need no changes themselves

“Information Hiding”

Hide information, procedures, and decisions likely to change.


Recursive Application of Information Hiding

For each module:•List the difficult decisions and decisions likely to change

•Design a (sub-) module specification to hide each such decision

•Recursively apply process to all new module specifications until all design decisions hidden


Module Design 102

Select entities from the world model•Nouns : modules / classes•Verbs: methods•Adjectives: properties / attributes / member variables

•Expletives: exceptions•Apply recursively

Use objects, entities, and components from the application definition as modules.


Module Design 103

Design for Reuse•Rationale: cost, competitiveness, reliability•Focus on developing modules for which you can imagine many different uses

•Risk: too complex, too generic, too hard to learn and use

Design reusable modules.


Module Design 104

Program Families•Different function sets for different markets

»By country, company size, hardware or software platform, price point

•Bug fixes•Feature sets•Flexibility is key

Design modules to support program families.


The USES relation - definition

M1 USES M2 if and only if correct execution of M2 is necessary for M1 to complete the task described in its specification.

M1 is called a client of M2. The USES relation is not based on flow of control during execution.

It is static. (see p. 275)


Example

Level 0

Level 1

Level 2

Level 2

Provided Interface

Big ComponentRequired Interface

Provided Interface

A ComponentRequired Interface

Provided Interface

Tiny ComponentRequired Interface

Provided Interface

Yet ComponentRequired Interface


The USES Hierarchy

Definition• Level 0 : modules not used by other modules

• Level i ( i > 0): modules used by at least one module on

level i -1 and by no modules at level i or greater. The USES relation is not necessarily a hierarchy A hierarchy (acyclic) is good

•Cycles generally are bad»Indication of high coupling»Indication of broken separation of concerns

What do you do with cycles in the USES graph? • Group a and b as a single entity in the USES relation.• Split a and b apart.


Uses – Rules of thumb

Allow a to use b..• …if it makes a simpler• …if b is not only used by a but also by

other components


Observations

Some invocations are not USES• Consider a transfer of control

Some USES do not involve invocations• Consider interrupt handlers• Consider global variables


Fan-in and Fan-out

High fan-in

Low fan-out

Low fan-in

High fan-out

USUALLY GOOD! USUALLY BAD!

Provided Interface

ComponentRequired Interface

Provided Interface

ComponentRequired Interface


IS-COMPONENT-OF Relation

Definition• Module M2 IS-COMPONENT-OF module M1 if M1 is

realized by aggregating several modules, one of which is M2

• The combined set of all modules that exhibit the IS-COMPONENT-OF relation with respect to module M1 are said to implement module M1

Use• Determine hierarchical decomposition of a

component in its subcomponents• Abstract details


Example

Compressor IS-COMPONENT-OF Audio EncoderEncoder IS-COMPONENT-OF Audio EncoderReader IS-COMPONENT-OF Audio Encoder

Compressor, Encoder, and Reader IMPLEMENT Audio EncoderAudio Encoder IS-COMPOSED-OF Compressor, Encoder, and Reader

Provided Interface

Audio EncoderRequired Interface

Com

pre

ssor

Provided Interface

Enco

der

Reader

Required Interface


Comprises Diagram

Provided Interface


Provided Interface


Provided Interface

B ComponentRequired Interface

Provided Interface

Mr. ComponentRequired Interface

Provided Interface

Required Interface

Provided Interface


Provided Interface


Required Interface

Provided Interface

Provided Interface

Required Interface

Bla Component

Duh Component

Doh Component


USES Diagram – Step 1

Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface

Required Interface

Provided Interface


Provided Interface


Required Interface

Provided Interface

Duh Component

Doh Component



Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface




Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


Provided Interface


2

3

2

1

1

0


Observations

Why do we identify higher-level modules in the first place?• Understanding• Abstraction through composition

IS-COMPONENT-OF is not• is-attribute-of• is-inside-of-on-the-screen• is-subclass-of• is-accessed-through-the-menu-of


The Design Process (reviewed)

Repeat the design process• Design the internal architecture of a component• Define the purpose of each module• Define the provided interface of each module• Define the required interface of each module

Do this over and over again• Until each module has…

» …a simple, well-defined internal architecture» …a simple, well-defined purpose» …a simple, well-defined provided interface» …a simple, well-defined required interface

Until all modules “hook up”


Techniques to Use

Tools of the trade• Apply information hiding• Use requirements specification• Anticipate change• Design for generality/incrementality (reuse)• Design for program families• Determine usage patterns

Strive for• Low coupling/high cohesion• A clean IS-COMPOSED-OF structure• A clean USES structure• High fan-in, low fan-out


Design by Stepwise Refinement

The typical alternative to design by information hiding.

A top-down technique Preliminary design specification --> more

elementary levels•Divide and conquer: start with system function•Break into major sub-functions•Concurrently refine algorithms, data

structures, flow of control•Repeat until design is sufficiently detailed to

give to programmers


Problems with Stepwise Refinement

What is the basis for choosing the initial decision to make?

Once a representation decision is made, all successive design decisions in that sub-tree of refinements may be dependent on it.

Promotes development of a sequential design solution (as opposed to concurrent)

If the initial function is “huge” how do you start to decompose it?

No help in designing reusable software Not supportive of program families


KWIC Index Example

Input: a file of titles“Voyage of the Dawn Treader” PR6023.E926 V6 1952“The Silver Chair” PR6023.E926 S5 1994“Mere Christianity” BR123 .L484 1952

Output: an alphabetized, permuted indexChair, The Silver PR6023.E926 S5 1994Christianity, Mere BR123 .L484 1952Dawn Treader, Voyage of the PR6023.E926 V6 1952Mere Christianity BR123 .L484 1952Silver Chair, The PR6023.E926 S5 1994The Silver Chair PR6023.E926 S5 1994Treader, Voyage of the Dawn PR6023.E926 V6 1952Voyage of the Dawn Treader PR6023.E926 V6 1952


Scheme 1: Stepwise Refinement

Level 1: Print KWIC List

Level 2: a. Input all titlesb. Generate and save all interesting circular

shiftsc. Alphabetize shiftsd. Print out

Level 3-b: For each line in input file begin generate and save all interesting circular

shiftsfor this line

end


KWIC Design

Input Titles

Make CircularShifts

Alphabetize

Print

KWICList


Data Structures

Array of titles Array of call numbers Array of circular shifts

•a pointer to a title (an array index)•a pointer to a character in the title (shift index)

•avoids repeating title text for each shift

This is one approach -- others are certainly possible.


Design, with Data Structures

Input Titles

Make CircularShifts

Alphabetize

Print

KWICList

Stored titles

Index of circularshifts

Index of alphabetizedcircular shifts

Arrows go from processing steps to data structures, and from data structures toprocessing steps.


Master Control Procedure

Input Titles

Make CircularShifts

Alphabetize

Print

KWICList

Stored titles

Index of circularshifts

Index of alphabetizedcircular shifts

main()

calls


Design Decisions Made in Scheme 1

All shifts will be stored All circular shifts will be generated

before alphabetization begins Alphabetical orderings will be

completed before printing begins All shifts of one line developed before

any shifts of another line “Uninteresting” shifts eliminated at the

time the shifts are generated


Design Decisions, Revisited (1)

All shifts will be stored • As opposed to computed on demand• Assumes you have enough memory to store everything

Circular shifts will be generated before alphabetization• Precluding use of an insertion sort running

concurrently or as a co-routine with the shift generator Alphabetical orderings will be completed before

printing

• Precluding concurrency and demanding additional storage

• e.g. once the first half were printed, their storage could be reused


Design Decisions, Revisited (2)

All shifts of one line developed before any shifts of another line•Perhaps it would be faster to do all the first shifts first, then alphabetization of them, then second shifts...

“Uninteresting” shifts eliminated at the time the shifts are generated•Details of this policy are buried within the shift generator


Scheme 2: Information Hiding

Design Decisions to Hide:•Internal representation of data to be

processed•Representation of circular shifts•Time at which circular shifts are computed•Method of alphabetization (sorting)•Time at which alphabetization is carried out•Input formats•Output formats


Modules and “Invokes”

TitleCollection.getData( )

ShiftCollection’senumeration

System.out.println

KWIC2.main( )

ShiftCollection.record( )

UninterestingTokenSet.

isUninteresting( )

UninterestingTokenSet.

add( )

TitleCollection.getTitle( )

.getCallno( )

means “invokes” or “calls”


What’s Hidden?

TitleCollection hides how titles are stored, when shifts are created. Interface:

String getTitle(int i) // returns title number iString getCallno(int i) // returns callno of title

number i

ShiftCollection hides

internal data representations (used Enumeration)when sorting is performed

sort algorithm


UninterestingTokenSet

Why does it hold the delimiters?


Differences between schemes

How modules divide work to be done Module interfaces Maintainability

•What’s involved in using a Vector for TitleCollection.title?

•How about a linked list? Independent Development Comprehensibility Separation of Concerns Amount of source code


Design Criteria

Scheme 1: each major step in processing is a module

Scheme 2: information hiding; modules need not correspond to processing steps• e.g. alphabetization may or may not correspond to a

processing phase• Every module in Scheme 2 hides a design decision

from the others»Start decomposition with a list of design decisions!

• Scheme 2 interfaces reveal as little as necessary about internal module workings

• Scheme 1 has important design decisions visible in interfaces


Comments on Design

Scheme 2’s implementation is similar to Scheme 1’s•same arrays•same sort routine•same CircularShift utility class•similar shiftedTitle method


KWIC2’s COMPRISES Diagram

KWIC2

Book Information

Token Information

Sorting Algorithm

Titles

Call Numbers

Shift Information

Words to skip

Delimiters

Shift

Shift Collection

TitleInformation

Output List

Note: ovals for composite modules,rectangles for elementary (leaf)modules.


KWIC2’s USES Diagram

Sorting Algorithm

Titles

Call Numbers

Words to skip

Delimiters

Shift

Shift Collection1

2

2

2

2

22

Output List

0

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

Documents