1. (c) 2010 University of California, Irvine – André van der Hoek1February 21, 2010 – 18:05:18 Informatics 122 Software Design II Lecture 9 Nick Lopez Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

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

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

4. (c) 2010 University of California, Irvine – André van der Hoek4February 21, 2010 – 18:05:18 A Critical Design Tradeoff: Benefits build (and thus design) buy or get for free (and thus fit into a design) full control full understanding flexibility competitive advantage can be instantaneous external support quality standardization

5. (c) 2010 University of California, Irvine – André van der Hoek5February 21, 2010 – 18:05:18 A Critical Design Tradeoff: Drawbacks build (and thus design) buy or get for free (and thus fit into a design) time cost maintenance standards Learning/licensing lack of customizability obsolescence urgent bugs evaluation cost

6. (c) 2010 University of California, Irvine – André van der Hoek6February 21, 2010 – 18:05:18 A Critical Design Tradeoff build (and thus design) buy or get for free (and thus fit into a design) time cost maintenance standards licensing lack of customizability obsolescence urgent bugs evaluation cost full control full understanding flexibility competitive advantage can be instantaneous external support quality

7. (c) 2010 University of California, Irvine – André van der Hoek7February 21, 2010 – 18:05:18 Our Focus Today build (and thus design) buy or get for free (and thus fit into a design) time cost maintenance standards licensing lack of customizability obsolescence urgent bugs evaluation cost full control full understanding flexibility competitive advantage can be instantaneous external support quality

8. (c) 2010 University of California, Irvine – André van der Hoek8February 21, 2010 – 18:05:18 A New Kind of Design Decision Less fine control More learning and using and applying Similar to recovery No one builds everything from scratch! The question is not if we will reuse, but what we will reuse

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

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

11. (c) 2010 University of California, Irvine – André van der Hoek11February 21, 2010 – 18:05:18 Component Reuse Process identify preliminary architecture identify potential places for reuse establish selection criteria (per place) search for applicable components evaluate components select component update architecture

12. (c) 2010 University of California, Irvine – André van der Hoek12February 21, 2010 – 18:05:18 Identify Preliminary Architecture Largely as if there was no reuse Familiarity with certain reusable components /frameworks may influence the architectural choices being made

13. (c) 2010 University of California, Irvine – André van der Hoek13February 21, 2010 – 18:05:18 Identify Potential Places for Reuse There are components / open source code 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 look at your design in terms of where reusable components may fit in

14. (c) 2010 University of California, Irvine – André van der Hoek14February 21, 2010 – 18:05:18 Establish Selection Criteria (Per Place) What is the granularity of what we need? Code snippets / classes / packages / APIs / frameworks A full framework provides many things but also restricts How is the component to fit with the rest of the architecture? Some adaptation can be accommodated Investment –cost –future cost - technical debt! Reputation –component provider –component itself …

15. (c) 2010 University of California, Irvine – André van der Hoek15February 21, 2010 – 18:05:18 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

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

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

18. (c) 2010 University of California, Irvine – André van der Hoek18February 21, 2010 – 18:05:19 Evaluate Components Apply selection criteria to each of the components found –beware of the platform, deployment needs, licensing terms –matrix of criteria versus components –recommendations from peers are relevant! Additional approaches –trial / evaluation licenses –reading component code –examine sample programs using the component ( always run the hello world before making a decision! ) –writing code using the component Examine the component’s documentation Analyze architectural impact of the component Perhaps even prototype the integration of the component

19. (c) 2010 University of California, Irvine – André van der Hoek19February 21, 2010 – 18:05:19 Select Component Choose the optimum component –understand tradeoffs –be prepared to not choose a component and restart the process

20. (c) 2010 University of California, Irvine – André van der Hoek20February 21, 2010 – 18:05:19 Update Architecture Design any adapters necessary to fit the component Many types of adaptation may be required: invocation, data, processing, cross dependencies… Redesign other components as needed Restructure architecture as needed Consider developers –How will they understand the implementation design of the external components? –special role for documentation

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

22. (c) 2010 University of California, Irvine – André van der Hoek22February 21, 2010 – 18:05:19 Assignment 5 The CodeOrb is a new visualization plug-in that we want to implement to extend the Eclipse platform to provide hints about code volatility Code volatility refers to indicators for different metrics related to the code that can show the developer a level of warning associated to each line of code How buggy has the code been in the past? How often has it changed? How good is the test coverage? How many developers have changed it? There are many components and frameworks out there that can help us figure out simple

23. (c) 2010 University of California, Irvine – André van der Hoek23February 21, 2010 – 18:05:19 Assignment 5 The CodeOrb is a new visualization plug-in that we want to implement to extend the Eclipse platform to provide hints about code volatility Code volatility refers to indicators for different metrics related to the code that can show the developer a level of warning associated to each line of code How buggy has the code been in the past? How often has it changed? How good is the test coverage? How many developers have changed it? There are many components and frameworks out there that can help us figure out simple

24. What you have been given A prototype implementation of the CodeOrb A research paper explaining the philosophy of the CodeOrb How it supports coding Some sample warning indicators pointers to some possible components that can be integrated A high level conceptual architecture © 2007 University of California, Irvine – André van der HoekFebruary 21, 2010 – 18:05:18

25. Code Orb - examples IndicatorWarning # of bugs implicated Relative code churn Relative ownership Relative test coverage 0many lowhigh low highlow

26. The CodeOrb © 2007 University of California, Irvine – André van der HoekFebruary 21, 2010 – 18:05:18

27. CodeOrb: prototype A prototype is available which shows the basic functionality We do not expect to reuse much of what is there © 2007 University of California, Irvine – André van der HoekFebruary 21, 2010 – 18:05:18

28. CodeOrb: desired architecture © 2007 University of California, Irvine – André van der HoekFebruary 21, 2010 – 18:05:18 Outputs Info Sources Issue TrackersVersioning SystemsOther support systemsStatic AnalysisDynamic AnalysisAwareness info Transforming outputs Updating info Updating info Eclipse IDE Code Orb Core Storing info Code Editors Code Editors Views Distributing info Distributing info

29. (c) 2010 University of California, Irvine – André van der Hoek29February 21, 2010 – 18:05:19 Assignment 5 Find components that can support the development of the CodeOrb, 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 parts of the architecture –Data Collection – we want to leverage existing components that find LOC level metrics / quality metrics / awareness info, etc… –Data Transformation – we want to leverage existing standards/technologies and components to transform outputs from info sources into an appropriate format –Volatility Visualization – We want to explore types of views we can integrate with in Eclipse and frameworks for creating graphs and visualizations –Info Distribution/Update– we would like to use a data distribution mechanism with an actual real protocol and middleware that is lightweight, fast, and can handle long distance

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

31. (c) 2010 University of California, Irvine – André van der Hoek31February 21, 2010 – 18:05:19 Assignment 5 Create a 10 minute presentation that describes for the first two categories and one of the other two 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 continue the development to integrate “effortlessly”

32. (c) 2010 University of California, Irvine – André van der Hoek32February 21, 2010 – 18:05:19 Assignment 5 Presentation in class Monday, February 28 th Document due at the beginning of class Monday, February 28 th 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)

33. (c) 2010 University of California, Irvine – André van der Hoek33February 21, 2010 – 18:05:19 Team Assignments Team 1 (Collection+Transformation + Visualization) Andrew Ryan-waldo Danielle Song Kevin Sar Michael Cupino Lucas Kam Team 2 (Collection+Transformation + Distribution/Update) Evan White Danielle Yu Melody Budiono Christopher Lang Stephan Chilingaryan Team 3 (Collection+Transformation + Visualization) Ryan Cadavona Duncan Tsai Ramakrishnan Murthy Vatsal Shah Norik Davtian Team 4 (Collection +Transformation + Distribution/Update) Edward Gim Mariann Conner Kevin Huynh Jarrett Baugh Martina Mickos Team 5 (Collection+Transformation + Visualization) Mark Capil Masis Nguyen Aaron Donk Jordan Speer Jonathan Fuentes Candace Chen

34. CodeOrb prototype © 2007 University of California, Irvine – André van der HoekFebruary 21, 2010 – 18:05:18

35. CodeOrb prototype © 2007 University of California, Irvine – André van der HoekFebruary 21, 2010 – 18:05:18

36. © 2007 University of California, Irvine – André van der HoekFebruary 21, 2010 – 18:05:18