1 / 26

(c) 2009 University of California, Irvine – André van der Hoek

Informatics 122 Software Design II. Lecture 10 André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. February 21, 2009 – 18:05:18.

helen
Download Presentation

(c) 2009 University of California, Irvine – André van der Hoek

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. Informatics 122Software Design II Lecture 10 André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 1

  2. Today’s Lecture • Component reuse • Assignment 5 February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 2

  3. build(and thus design) buy or get for free(and thus fit into a design) A Critical Design Tradeoff February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 3

  4. build(and thus design) buy or get for free(and thus fit into a design) A Critical Design Tradeoff: Benefits full control full understandingflexibilitycompetitive advantage can be instantaneousexternal support quality February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 4

  5. build(and thus design) buy or get for free(and thus fit into a design) A Critical Design Tradeoff: Drawbacks timecost maintenancestandards licensinglack of customizabilityobsolescenceurgent bugs evaluation cost February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 5

  6. build(and thus design) buy or get for free(and thus fit into a design) A Critical Design Tradeoff can be instantaneousexternal support quality full control full understandingflexibilitycompetitive advantage timecost maintenancestandards licensinglack of customizabilityobsolescenceurgent bugsevaluation cost February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 6

  7. build(and thus design) buy or get for free(and thus fit into a design) Our Focus Today can be instantaneousexternal support quality full control full understandingflexibilitycompetitive advantage timecost maintenancestandards licensinglack of customizabilityobsolescenceurgent bugsevaluation cost February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 7

  8. A New Kind of Design Decision • Less fine control • More learning and using and applying • Similar to recovery February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 8

  9. Architectural Mismatch • Architectural mismatch stems from mismatched assumptions a reusable component makes about the system structure of which it is to be part • Components • functionality • interfaces • behavior • control model • Connectors • protocols • data model • System topology • Construction • dependencies • initialization Difficult to predict a-priori February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 9

  10. Architectural Mismatch • Architectural mismatch stems from mismatched assumptions a reusable component makes about the system structure of which it is to be part • Components • functionality • interfaces • behavior • control model • Connectors • protocols • data model • System topology • Construction • dependencies • initialization How much adaptation is too much adaptation? February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 10

  11. identifypreliminaryarchitecture identifypotentialplaces forreuse establishselectioncriteria (perplace) Component Reuse Process updatearchitecture selectcomponent evaluatecomponents search forapplicablecomponents February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 11

  12. Identify Preliminary Architecture • Largely as usual • Familiarity with certain reusable components may influence the architectural choices being made February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 12

  13. Identify Potential Places for Reuse • There are components for just about anything • graph layout • database access • regular expression handling • numerical computing • protein visualization • speech recognition • e-mail handling • index and search • maps • geocoding • … • Judiciously mark the architecture in terms of where reusable components may fit in February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 13

  14. Establish Selection Criteria (Per Place) • What kind of component does the architecture really need? • functionality • absolutely necessary versus desired functionality • software qualities • How is the component to fit with the rest of the architecture? • some adaptation can be accommodated • Investment • cost • future cost • Reputation • component provider • component itself • … February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 14

  15. Search for Applicable Components • Google is a wonderful thing • www.google.com • code.google.com • Component repositories • rich in available components • many junk • some decent • occasional gems • Research and professional development literature • Too many is no good • Too few is no good either • although one perfect component would solve the problem February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 15

  16. sourceforge.net February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 16

  17. apache.org February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 17

  18. Evaluate Components • Apply selection criteria to each of the components found • beware of the platform, deployment needs, licensing terms • matrix of criteria versus components • Additional approaches • trial / evaluation licenses • reading component code • examine sample programs using the component • writing code using the component • Examine the component’s documentation • Analyze architectural impact of the component • Perhaps even “mini integrate” the component February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 18

  19. Select Component • Choose the optimum component • understand tradeoffs • be prepared to not choose a component February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 19

  20. Update Architecture • Design any adapters necessary to fit the component • Redesign other components as needed • Restructure architecture as needed • Consider implementers • special role for documentation February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 20

  21. A Quick Sample Among the Graduate Students • Xalan • Xerces • Lucene • Jung • Kaffe • Bcel • Equip • JLoox • Schematron • GraphViz • Jython • Scriptalicious • … • Xacml • SWT • JOAL • Jetty • Batik • JmDNS • Darwin Streaming Server • Spook • Mplayer • MySQL • live.com RTP/RTSP • gaim im client • … February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 21

  22. Assignment 5 • Research available components that provide a particular kind of functionality for Palantír, set up selection criteria, make a choice of the component that you believe is best, and detail how you would go about integrating the component • Specifically, research components for the following situations • code clones – we want to augment the functionality of Palantír with awareness of clones (code that is very similar or even identical across multiple files), we need a component that helps us detect such clones • graphics – we want to augment the Eclipse visualization with an external visualization that annotates UML diagrams of the code with awareness information of changes, clones, etc., we need a component that displays UML diagrams and allow us to easily make various kinds of annotations • events – we want to replace Siena with another event delivery system (publish-subscribe system), because Siena has some bugs, we want a reliable component that is as backwards compatible as possible February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 22

  23. Assignment 5 • Additional constraint • we have $1250 in funds to spend on this project, but we want to save money for user studies and other assorted expenses, so cost should be minimized • if truly warranted, management can be requested to fund one “big ticket” component, up to possibly $10,000 February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 23

  24. Assignment 5 • Create a 10 minute presentation that describes for one of the three categories (specific assignments of which category by which team on slide 26) • your search process • candidate components you considered • strengths • weaknesses • your selection criteria • the component you deem best (and why) • Create a document that describes, at the design and code level, the impact of incorporating the chosen components • from this document, someone should be able to make these changes “effortlessly” February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 24

  25. Assignment 5 • Presentation in class Monday, March 2nd • Document due at the beginning of class Monday, March 2nd • Graded on breadth and depth of component evaluation, as well as the thoroughness and insightfulness of the document • Each person also needs to submit a team evaluation (new forms available on class webpage) February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 25

  26. Team Assignments • Team 1 (clones) • Lance Cacho • Jeffrey Gaskill • Derek Lee • Ben Kahn • Jordan Sinclair Team 2 (clones) • Scott Roeder • Robert Jolly • Daniel Morgan • James Rose • David Schramm Team 3 (graphics) • Leslie Liu • Alexander Doan • Aylwin Villanueva • Scott Ditch • James Milewski • Team 4 (graphics) • Tomas Ruiz-Lopez • Alton Chislom • Chad Curtis • Jay Bacuetes • Matt Shigekawa Team 5 (events) • Matt Fritz • Alex Kaiser • Robert Duncan • Rakesh Rajput • Joshua Villamarzo • Lance Zepeda February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 26

More Related