"Magician Coder" View of Development

1
"Magician Coder" View of Development
Requirements
(Here a Miracle happens)
Code
2
A Professional View
Requirements
Architecture
Code
Plans, blueprints, detailed drawings,
instructions for specialists, time estimates,
material requirements estimates, permits, etc.
3
Architecture, in Software and Building

• Requirements user signs off on the big picture
  and some but, realistically, not all, details.
• Implementation plan time frame, number of
  workers, their skills and availability.
• Detailed cost estimate.
• Modularize divide task into smaller parts.
• Interface with existing buildings / neighborhood
  / related software systems.
• Important design decisions that are invisible to
  the user type of girders, type of algorithm,
  language, database system.

4
Design Fundamentals - Questions

• Software is multi-person
• How can each programmer work independently of the
  others?
• Software is multi-version
• How can software be designed so that it is easy
  to modify?
• Planned modifications
• Corrective maintenance (fix flaws)
• Adaptive maintenance (adjust to changing world)
• Perfective maintenance (add features)

5
Design Fundamentals - Answers

• Modularity, for three reasons
• decompose a complex system into less complex
  sub-systems divide and conquer
• (re-)use existing modules
• understand the system in pieces
• What makes a good module?
• High cohesion all internal parts are closely
  related.
• Low coupling modules rely on each other as
  little as possible
• Each module hides its internal structure.

6
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

7
Javas Vector ADT

• constructor Vector(int initialCapacity, int
  capacityIncrement) // good ADT?
• void addElement(Object obj)
• boolean contains(Object obj)
• Object elementAt(int index)
• int indexOf(Object obj)
• void insertElementAt(Object obj, int index)
• boolean isEmpty()
• void removeAllElements()
• void removeElementAt()
• void setElementAt(Object obj, int index)

8
Stack ADT

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

9
Possible Vector 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 Vector ADT

10
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)
• Abstract class
• Package
• Constant

11
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 doesnt know the secret? All other modules.

12
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
• Determine likely usage patterns and purposes
• Suppress unnecessary details of a design decision
  (secret)
• Given the interface, any consistent
  implementation is OK

13
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

14
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

15
A Good Design . . .

• is half the implementation effort!
• Desirable qualities and principles
• Rigor ensures all requirements are addressed
• Separation of concerns promotes modules that can
  be written and tested independently
• Anticipation of change allows new functionality
  to be absorbed with minimal impact
• Incrementality permits the software to be
  developed with intermediate working/testable
  results

16
A Bad Design . . .

• will never be implemented!
• Potential pitfalls
• Lack of rigor leads to missing functionality
• Lack of separation of concerns leads to
  programmers stepping on each others toes, or
  needing to meet and co-ordinate constantly
• Lack of anticipation of change leads to
  redesigns, reimplementations, and an expensive
  maintenance phase
• Lack of incrementality will result in a
  big-bang and a difficult integration phase

17
Module Design 101
Hide information, procedures, and decisions
likely to change.

• 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

18
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

19
Module Design 102
Use objects, entities, and components from the
application definition as modules.

• Select entities from the world model
• Nouns modules / classes
• Verbs methods
• Adjectives properties / attributes / member
  variables
• Expletives exceptions
• Apply recursively

20
Module Design 103
Design reusable modules.

• 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

21
Module Design 104
Design modules to support program families.

• 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

22
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)

23
The USES Relation

• USES is useful
• flexibility,
• reuse,
• incremental testability
• uses ! invokes / calls
• invocation can be transfer of control only
• shared memory
• events, listeners, interrupts

24
The USES Hierarchy

• Definition
• Level 0 modules not used by other modules
• Level i ( i gt 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
• 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.

25
COMPRISES

• Enables description of big modules composed of
  little modules
• If M1 comprises M2 and M3, then M2 and M3
  implement M1. M1 is not itself programmed up
• Why M1? For descriptive / planning purposes.
• Comprises Is Composed Of
• Not the same as
• is-attribute-of
• is-inside-of-on-the-screen, is positioned on top
  of
• is-subclass-of
• the Java keyword implements

26
The Design Process

• List the difficult decisions and decisions likely
  to change
• Prioritize based on importance and overall
  impact.
• Design a module / class specification to hide
  each one
• Make decisions that apply to the whole family
  first
• Design the USES hierarchy as you do this
• Consider reuse possibilities
• To the extent that the above steps do not
  adequately yield a design, develop module
  specifications based on concepts in the world
  model of the specification
• As necessary, design a control module to oversee
  the actions of all the modules now designed

27
Design by Stepwise Refinement

• The typical alternative to design by information
  hiding.
• A top-down technique
• Preliminary design specification --gt 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

28
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

29
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 index
• Chair, The Silver PR6023.E926
  S5 1994
• Christianity, Mere BR123 .L484 1952
• Dawn Treader, Voyage of the PR6023.E926 V6 1952
• Mere Christianity BR123 .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

30
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

31
KWIC Design
Input Titles
Make Circular Shifts
Alphabetize
KWIC List
Print
32
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.
33
Design, with Data Structures
Input Titles
Stored titles
Make Circular Shifts
Index of circular shifts
Index of alphabetized circular shifts
Alphabetize
Arrows go from processing steps to data
structures, and from data structures
to processing steps.
KWIC List
Print
34
Master Control Procedure
Input Titles
Stored titles
Make Circular Shifts
Index of circular shifts
calls
Index of alphabetized circular shifts
Alphabetize
main()
KWIC List
Print
35
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

36
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

37
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

38
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

39
Modules and Invokes
TitleCollection. getData( )
ShiftCollection. record( )
Uninteresting TokenSet. isUninteresting( )
Uninteresting TokenSet. add( )
TitleCollection .getTitle( ) .getCallno( )
ShiftCollections enumeration
System.out.println
KWIC2.main( )
means invokes or calls
40
Whats Hidden?

• 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
• ShiftCollection hides
• internal data representations (used Enumeration)
• when sorting is performed
• sort algorithm

41
UninterestingTokenSet

• Why does it hold the delimiters?

42
Differences between schemes

• How modules divide work to be done
• Module interfaces
• Maintainability
• Whats involved in using a Vector for
  TitleCollection.title?
• How about a linked list?
• Independent Development
• Comprehensibility
• Separation of Concerns
• Amount of source code

43
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

44
Comments on Design

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

45
KWIC2s COMPRISES Diagram
Titles
Title Information
Book Information
Call Numbers
Shift
Shift Information
Shift Collection
KWIC2
Token Information
Words to skip
Delimiters
Note ovals for composite modules, rectangles for
elementary (leaf) modules.
Sorting Algorithm
Output List
46
KWIC2s USES Diagram
Output List
0
2
Titles
Shift Collection
Call Numbers
1
2
Shift
2
Words to skip
2
Sorting Algorithm
2
Delimiters
2
47
Address Processing System

• Reads, stores, writes addresses (like a rolodex)
• random and sequential access
• Addresses
• title (e.g. Mr. Mrs. Ms. Dr.)
• last or family name
• given names
• organization
• email address
• street address or P.O. Box
• city, state, zip, country

48
APS - Design

• Identify 3 assumptions you might need to make
• Identify 3 design decisions
• Identify 2 modules that are ADTs, and list part
  of each interface
• Identify 2 modules that are not ADTs
• Design a (partial) COMPRISES diagram with one
  parent
• Design a (partial) USES diagram with three levels

49
Integration Test Plans

• Purpose 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
• Method Combine more and more modules, testing
  each group. Employ USES hierarchy -- work from
  highest level up, or from level 0 down.

50
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

51
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

52
Architectural Styles

• Architectural styles restrict the way in which
  components can be connected
• Prescribe patterns of interaction
• Promote fundamental principles
• Rigor, separation of concerns, anticipation of
  change, generality, incrementality
• Low coupling, High cohesion
• Architectural styles are based on success stories
• Almost all compilers are build as
  pipe-and-filter
• Almost all network protocols are build as layers

53
Style 1 Hierarchy
Connections are function or method calls
54
Style 2 Client-Server
Connections are remote procedure calls or remote
method invocations
55
Style 3 Blackboard
Connections are encapsulated global variables
(the blackboard!)
56
Style 4 Peer-to-Peer
Connections are remote procedure calls or remote
method invocations
57
Style 5 Pipe-and-Filter
Connections are pipes (also called data flows)
58
Style 6 Implicit Invocation
Connections are events on the software bus
59
Style 7 Layers
Connections are function or method calls
something in between"
60
Model - View - Controller (MVC)
Model - application data and its behavior
User
Sees
Uses
Controller - user input
View
Controller
View - display of model
Updates
Manipulates
One model can be associated with multiple views.
Model