1. Topic 8Summer 2003 1 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

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

3. Topic 8Summer 2003 3 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”

4. Topic 8Summer 2003 4 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

5. Topic 8Summer 2003 5 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

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

7. Topic 8Summer 2003 7 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

8. Topic 8Summer 2003 8 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.

9. Topic 8Summer 2003 9 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

10. Topic 8Summer 2003 10 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

11. Topic 8Summer 2003 11 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

12. Topic 8Summer 2003 12 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.

13. Topic 8Summer 2003 13 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

14. Topic 8Summer 2003 14 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.

15. Topic 8Summer 2003 15 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.

16. Topic 8Summer 2003 16 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.

17. Topic 8Summer 2003 17 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)

18. Topic 8Summer 2003 18 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

19. Topic 8Summer 2003 19 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.

20. Topic 8Summer 2003 20 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

21. Topic 8Summer 2003 21 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

22. Topic 8Summer 2003 22 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

23. Topic 8Summer 2003 23 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

24. Topic 8Summer 2003 24 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

25. Topic 8Summer 2003 25 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

26. Topic 8Summer 2003 26 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

27. Topic 8Summer 2003 27 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

28. Topic 8Summer 2003 28 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

29. Topic 8Summer 2003 29 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 2 3 2 1 1 0

30. Topic 8Summer 2003 30 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

31. Topic 8Summer 2003 31 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”

32. Topic 8Summer 2003 32 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

33. Topic 8Summer 2003 33 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

34. Topic 8Summer 2003 34 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

35. Topic 8Summer 2003 35 KWIC Index Example l 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 l Output: an alphabetized, permuted index Chair, The Silver PR6023.E926 S5 1994 Christianity, MereBR123.L484 1952 Dawn Treader, Voyage of the PR6023.E926 V6 1952 Mere ChristianityBR123.L484 1952 Silver Chair, The PR6023.E926 S5 1994 The Silver Chair PR6023.E926 S5 1994 Treader, Voyage of the Dawn PR6023.E926 V6 1952 Voyage of the Dawn Treader PR6023.E926 V6 1952

36. Topic 8Summer 2003 36 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

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

38. Topic 8Summer 2003 38 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.

39. Topic 8Summer 2003 39 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.

40. Topic 8Summer 2003 40 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

41. Topic 8Summer 2003 41 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

42. Topic 8Summer 2003 42 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

43. Topic 8Summer 2003 43 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

44. Topic 8Summer 2003 44 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

45. Topic 8Summer 2003 45 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”

46. Topic 8Summer 2003 46 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

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

48. Topic 8Summer 2003 48 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

49. Topic 8Summer 2003 49 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

50. Topic 8Summer 2003 50 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

51. Topic 8Summer 2003 51 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.

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