1 / 10

CSE350 Software Design and Engineering

CSE350 Software Design and Engineering. University of Pennsylvania http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 February 12 th , 2002. Software Reuse. What is software reuse? Can software be “reused”? What effect does it have on lifecycle?

corgan
Download Presentation

CSE350 Software Design and Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE350 Software Design and Engineering University of Pennsylvania http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 February 12th, 2002

  2. Software Reuse • What is software reuse? • Can software be “reused”? • What effect does it have on lifecycle? • Are there examples of its success? • Libraries • UNIX filters + pipes • What can we learn from these examples?

  3. What is software reuse? • Once software is written & debugged, it is a “building block” that can be used in future systems • Attractive idea: write-once, reuse many • Not necessarily systems, usually components are reused • Composability is a requirement

  4. Can software be reused? • If it can be composed with other existing software it can be reused • If building block for other software, it can be reused (and it eases the writing of the other software) • Not always possible: new contexts • Informal habit of experienced programmers: save all your code!

  5. Lifecycle issues • Less code - less design and testing • Shared maintenance costs (remember, these are large) • Sunk investment • Costs amortized over more uses of software • Shortens learning curve - familiarity

  6. Successes: Libraries • A library, e.g. the util.c file in examples, contains routines that prove useful in many programs. They are tested and robust. E.g., emalloc(), strsave(), etc. • Libraries normally raise the level of abstraction for programmers • cc -l{libname}, e.g., cc -lm for math stuff

  7. Successes: OSes • Operating Systems began as I/O control systems (IOCCs). • They provide shared services that change the level of abstraction - read()/write() rather than device manipulation • Good software, written once, used by most programs

  8. Successes: Pipe + Filter • Composable executables • Glued together with cmd interpreter (shell) • Read from stdin, write to stdout • Interoperability layer is bytestream • Raises level of abstraction

  9. Polymorphism • #define PRODUCT(_a,_b) (_a)*(_b) • Reusable because abstract • Object type defines behavior • Supported in some modern programming languages such as ML.

  10. Lessons from examples? • Work is saved by working at higher level of abstraction (C vs. shell) • Reusable routines are general, to encourage many uses. • Need to have support for composition - note that successful examples used elements such as procedures and executable modules

More Related