3156-16 - COMS W3156: Software Engineering, Fall 2001...

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

View Full Document Right Arrow Icon
COMS W3156: Software Engineering, Fall 2001 Lecture #15: Integration I, Security/Crypto I Janak J Parekh janak@cs.columbia.edu
Background image of page 1

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

View Full DocumentRight Arrow Icon
Administrativia Design due now Requirements v1.2 posted Is your head hurting yet? Prototype: almost there and…
Background image of page 2
Next class Continue security/crypto Implementation-level security and cryptography Discuss various useful tools for implementation and integration (I&I II?)
Background image of page 3

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

View Full DocumentRight Arrow Icon
Today’s class Talk about integration issues Introduce security and cryptography concepts Theoretical-level
Background image of page 4
Integration? Not really separate from Implementation, but traditionally thought of as such Schach calls it the “Implementation and Integration phase” Why? (2 reasons)
Background image of page 5

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

View Full DocumentRight Arrow Icon
Implementation needs integration (I) Here, a calls b, c, and d You can’t test a until you attempt to integrate with b, c, and d Code stubs of b, c, and d For b: need driver for a, stub for e
Background image of page 6
Stubs and drivers Essentially empty modules Usually prints debugging info Stubs Get called upon Might return a canned answer Drivers Call others Also prints some debugging
Background image of page 7

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

View Full DocumentRight Arrow Icon
Implementation needs integration (II) Consider a really complex set of modules Each time you integrate, fault isolation becomes harder Additionally, possibility for faults increase Can’t work completely independently until the last day Even with OO Need to combine module and integration testing
Background image of page 8
Implement and integrate starting from the top Create stubs for subsidiary components Fill in the stubs later Good: major fundamental flaws shown early: better to test logic first
Background image of page 9

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

View Full DocumentRight Arrow Icon
Problems with top-down Difficult to test actual low-level functions (reusable components) The top-level gets tested n times Bottom-level gets tested once Defensive programming a liability? if (x >= 0) computeSquareRoot
Background image of page 10
Build drivers, fill them in later Design flaws not shown early, but low-level components very well tested Huge cost to redesign Conclusion: need to combine both
Background image of page 11

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

View Full DocumentRight Arrow Icon
Simple idea: work from both ends Tests logic, as well as reusable components Schach claims infinite upside from this model Reality: a bit more complex to organize Need both stubs and drivers
Background image of page 12
Needed to include in a “Object Oriented Software Engineering” book Basically, works the same as classical I&I
Background image of page 13

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

View Full DocumentRight Arrow Icon
What if the pieces don’t fit together? What do Phil and I do if server and client
Background image of page 14
Image of page 15
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 43

3156-16 - COMS W3156: Software Engineering, Fall 2001...

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

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