Topic 8Summer ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Topic 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

Topic 8Summer Design Interaction Architectural design (previous lecture) Module design (this lecture)

Topic 8Summer From Architecture to Modules l 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 l 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 l Until all modules “hook up”

Topic 8Summer Module - Definitions l a software fragment of any size (including “subsystem”) l a collection of routines, data, objects l a provider of computational resources or services l Examples: Abstract data type -- data structures with accessing and modifying functions Class (similar to an ADT) Package

Topic 8Summer Abstract Data Type - a kind of module l Goal: Encapsulate the concrete representation of a data structure with functions that access the representation l Users see only the abstract characteristics of the structure l 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

Topic 8Summer Stack ADT l Class Stack boolean empty() Object peek() Object pop() Object push(Object obj)

Topic 8Summer Possible Implementations l Array that is enlarged and copied as necessary l Linked list l Linked list of arrays l Sorted tree l Does it matter? l Can change with no impact to users of Stack ADT

Topic 8Summer Module - Alternative Formulation l 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 l What is a secret? Any design decision. l Who doesn’t know the secret? All other modules.

Topic 8Summer Determining a Module's Interface l Interface: the set of services a module provides its clients. l 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 l Given the interface, any consistent implementation is OK

Topic 8Summer Module Interfaces l Module exports or provides methods or information for use by other modules these other modules are its “clients” l Module imports or requires: external functionality this module is going to utilize

Topic 8Summer Module to Module Interaction l A module hides implementation details (e.g. data structures) so that the rest of the system is insulated and protected from the details l Modules communicate only through well- defined interfaces (e.g. method calls) l Programming languages typically provide lots of ways to violate this! global variables public member variables pointers shared memory

Topic 8Summer Module Design 101 l Design process: Identify items likely to change Confine these to modules Design module interfaces to be insensitive to change l If internal details change, client units should need no changes themselves l “Information Hiding” Hide information, procedures, and decisions likely to change.

Topic 8Summer Recursive Application of Information Hiding l 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

Topic 8Summer Module Design 102 l 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.

Topic 8Summer Module Design 103 l 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.

Topic 8Summer Module Design 104 l 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.

Topic 8Summer The USES relation - definition l M1 USES M2 if and only if correct execution of M2 is necessary for M1 to complete the task described in its specification. l M1 is called a client of M2. l The USES relation is not based on flow of control during execution. l It is static. (see p. 275)

Topic 8Summer Example Level 0 Level 1 Level 2 Provided Interface Big Component Required Interface Provided Interface A Component Required Interface Provided Interface Tiny Component Required Interface Provided Interface Yet Component Required Interface

Topic 8Summer The USES Hierarchy l 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. l The USES relation is not necessarily a hierarchy l A hierarchy (acyclic) is good Cycles generally are bad »Indication of high coupling »Indication of broken separation of concerns l 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.

Topic 8Summer Uses – Rules of thumb l Allow a to use b.. …if it makes a simpler …if b is not only used by a but also by other components

Topic 8Summer Observations l Some invocations are not USES Consider a transfer of control l Some USES do not involve invocations Consider interrupt handlers Consider global variables

Topic 8Summer Fan-in and Fan-out High fan-in Low fan-out Low fan-in High fan-out USUALLY GOOD! USUALLY BAD! Provided Interface Component Required Interface Provided Interface Component Required Interface

Topic 8Summer IS-COMPONENT-OF Relation l 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 l Use Determine hierarchical decomposition of a component in its subcomponents Abstract details

Topic 8Summer Example Compressor IS-COMPONENT-OF Audio Encoder Encoder IS-COMPONENT-OF Audio Encoder Reader IS-COMPONENT-OF Audio Encoder Compressor, Encoder, and Reader IMPLEMENT Audio Encoder Audio Encoder IS-COMPOSED-OF Compressor, Encoder, and Reader Provided Interface Audio Encoder Required Interface Compressor Provided Interface EncoderReader Required Interface

Topic 8Summer Comprises Diagram Provided Interface Yet Component Required Interface Provided Interface Tiny Component Required Interface Provided Interface B Component Required Interface Provided Interface Mr. Component Required Interface Provided Interface Required Interface Provided Interface Big Component Required Interface Provided Interface A Component Required Interface Provided Interface Required Interface Bla Component Duh Component Doh Component

Topic 8Summer USES Diagram – Step 1 Provided Interface Yet Component Required InterfaceProvided Interface Tiny Component Required Interface Provided Interface B Component Required Interface Provided Interface Mr. Component Required Interface Provided Interface Required Interface Provided Interface Big Component Required Interface Provided Interface A Component Required Interface Provided Interface Duh Component Doh Component

Topic 8Summer USES Diagram – Step 2 Provided Interface Yet Component Required Interface Provided Interface Tiny Component Required Interface Provided Interface B Component Required Interface Provided Interface Mr. Component Required Interface Provided Interface Big Component Required Interface Provided Interface A Component Required Interface

Topic 8Summer USES Diagram – Step 3 Provided Interface Yet Component Required Interface Provided Interface Tiny Component Required Interface Provided Interface B Component Required Interface Provided Interface Mr. Component Required Interface Provided Interface Big Component Required Interface Provided Interface A Component Required Interface

Topic 8Summer USES Diagram – Step 4 Provided Interface Yet Component Required Interface Provided Interface Tiny Component Required Interface Provided Interface B Component Required Interface Provided Interface Mr. Component Required Interface Provided Interface Big Component Required Interface Provided Interface A Component Required Interface

Topic 8Summer Observations l Why do we identify higher-level modules in the first place? Understanding Abstraction through composition l IS-COMPONENT-OF is not is-attribute-of is-inside-of-on-the-screen is-subclass-of is-accessed-through-the-menu-of

Topic 8Summer The Design Process (reviewed) l 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 l 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 l Until all modules “hook up”

Topic 8Summer Techniques to Use l Tools of the trade Apply information hiding Use requirements specification Anticipate change Design for generality/incrementality (reuse) Design for program families Determine usage patterns l Strive for Low coupling/high cohesion A clean IS-COMPOSED-OF structure A clean USES structure High fan-in, low fan-out

Topic 8Summer Design by Stepwise Refinement l The typical alternative to design by information hiding. l A top-down technique l 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

Topic 8Summer Problems with Stepwise Refinement l What is the basis for choosing the initial decision to make? l Once a representation decision is made, all successive design decisions in that sub-tree of refinements may be dependent on it. l Promotes development of a sequential design solution (as opposed to concurrent) l If the initial function is “huge” how do you start to decompose it? l No help in designing reusable software l Not supportive of program families

Topic 8Summer KWIC Index Example l Input: a file of titles “Voyage of the Dawn Treader”PR6023.E926 V “The Silver Chair”PR6023.E926 S “Mere Christianity”BR123.L l Output: an alphabetized, permuted index Chair, The Silver PR6023.E926 S Christianity, MereBR123.L Dawn Treader, Voyage of the PR6023.E926 V Mere ChristianityBR123.L Silver Chair, The PR6023.E926 S The Silver Chair PR6023.E926 S Treader, Voyage of the Dawn PR6023.E926 V Voyage of the Dawn Treader PR6023.E926 V6 1952

Topic 8Summer Scheme 1: Stepwise Refinement Level 1:Print KWIC List Level 2:a. Input all titles b. Generate and save all interesting circular shifts c. Alphabetize shifts d. Print out Level 3-b:For each line in input file begin generate and save all interesting circular shifts for this line end

Topic 8Summer KWIC Design Input Titles Make Circular Shifts Alphabetize Print KWIC List

Topic 8Summer Data Structures l Array of titles l Array of call numbers l 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.

Topic 8Summer Design, with Data Structures Input Titles Make Circular Shifts Alphabetize Print KWIC List Stored titles Index of circular shifts Index of alphabetized circular shifts Arrows go from processing steps to data structures, and from data structures to processing steps.

Topic 8Summer Master Control Procedure Input Titles Make Circular Shifts Alphabetize Print KWIC List Stored titles Index of circular shifts Index of alphabetized circular shifts main() calls

Topic 8Summer Design Decisions Made in Scheme 1 l All shifts will be stored l All circular shifts will be generated before alphabetization begins l Alphabetical orderings will be completed before printing begins l All shifts of one line developed before any shifts of another line l “Uninteresting” shifts eliminated at the time the shifts are generated

Topic 8Summer Design Decisions, Revisited (1) l All shifts will be stored As opposed to computed on demand Assumes you have enough memory to store everything l Circular shifts will be generated before alphabetization Precluding use of an insertion sort running concurrently or as a co-routine with the shift generator l 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

Topic 8Summer Design Decisions, Revisited (2) l 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... l “Uninteresting” shifts eliminated at the time the shifts are generated Details of this policy are buried within the shift generator

Topic 8Summer Scheme 2: Information Hiding l 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

Topic 8Summer Modules and “Invokes” TitleCollection. getData( ) ShiftCollection’s enumeration System.out.println KWIC2.main( ) ShiftCollection. record( ) Uninteresting TokenSet. isUninteresting( ) Uninteresting TokenSet. add( ) TitleCollection.getTitle( ).getCallno( ) means “invokes” or “calls”

Topic 8Summer What’s Hidden? l TitleCollection hides how titles are stored, when shifts are created. Interface: String getTitle(int i) // returns title number i String getCallno(int i) // returns callno of title number i l ShiftCollection hides internal data representations (used Enumeration) when sorting is performed sort algorithm

Topic 8Summer UninterestingTokenSet l Why does it hold the delimiters?

Topic 8Summer Differences between schemes l How modules divide work to be done l Module interfaces l Maintainability What’s involved in using a Vector for TitleCollection.title? How about a linked list ? l Independent Development l Comprehensibility l Separation of Concerns l Amount of source code

Topic 8Summer Design Criteria l Scheme 1: each major step in processing is a module l 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

Topic 8Summer Comments on Design l Scheme 2’s implementation is similar to Scheme 1’s same arrays same sort routine same CircularShift utility class similar shiftedTitle method

Topic 8Summer KWIC2’s COMPRISES Diagram KWIC2 Book Information Token Information Sorting Algorithm Titles Call Numbers Shift Information Words to skip Delimiters Shift Shift Collection Title Information Output List Note: ovals for composite modules, rectangles for elementary (leaf) modules.

Topic 8Summer KWIC2’s USES Diagram Sorting Algorithm Titles Call Numbers Words to skip Delimiters Shift Shift Collection Output List 0