lect-8-design - 4/26/2011 Today 2 Very brief project #1...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
4/26/2011 1 CSE503: SOFTWARE ENGINEERING DESIGN David Notkin Spring 2011 Today Very brief project #1 descriptions Software design introduction 503 11sp © UW CSE • D. Notkin 2 503 11sp © UW CSE • D. Notkin 3 Functional decomposition Divide-and-conquer based on functions input; compute; output Then proceed to decompose compute This is stepwise refinement (Wirth, 1971) In essence, refining until implementable directly in a programming language (or on an architecture) There is an enormous body of work in this area, including many formal calculi to support the approach Closely related to proving programs correct More effective in the face of stable requirements 503 11sp © UW CSE • D. Notkin 4 Information hiding Information hiding is perhaps the most important intellectual tool developed to support software design [Parnas 1972] Makes the anticipation of change a centerpiece in decomposition into modules Provides the fundamental motivation for abstract data type (ADT) languages And thus a key idea in the OO world, too The conceptual basis is key
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
4/26/2011 2 503 11sp © UW CSE • D. Notkin 5 Basics of information hiding Modularize based on anticipated change Fundamentally different from Brooks’ approach in OS/360 (see old and new MMM) Separate interfaces from implementations Implementations capture decisions likely to change Interfaces capture decisions unlikely to change Clients know only interface, not implementation Implementations know only interface, not clients Modules are also work assignments 503 11sp © UW CSE • D. Notkin 6 Anticipated changes The most common anticipated change is “change of representation” Anticipating changing the representation of data and associated functions (or just functions) Again, a key notion behind abstract data types Ex: Cartesian vs. polar coordinates; stacks as linked lists vs. arrays; packed vs. unpacked strings Classic Parnas example: KWIC Key Word in Context Example input One flew over the cuckoo’s nest but it wasn’t me Example output but it wasn’t me cuckoo’s nest the flew over One it wasn’t me but me but it wasn’t nest the cuckoo’s One flew over over One flew the cuckoo’s nest wasn’t me but it 503 11sp © UW CSE • D. Notkin 7 Functional decomposition 503 11sp © UW CSE • D. Notkin 8 A traditional would decompose based on the four basic functions performed: input , shift , alphabetize , output , coordinated by main Data communication is through shared storage and can be an unconstrained read-write protocol because of main Parnas argues some serious drawbacks in terms of its ability to handle changes In particular, a change in data storage format will affect almost all of the modules. Similarly changes in algorithm and enhancements to system function are
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 8

lect-8-design - 4/26/2011 Today 2 Very brief project #1...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online