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

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