1 / 26

Object Oriented Design

Object Oriented Design. Goals. Reuse, objects, and components Discuss ComponentWare article. Software Reuse. Software reuse is the process of creating software systems by using existing functionality or by combining predefined software components.

galvin
Download Presentation

Object Oriented Design

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. Object Oriented Design

  2. Goals • Reuse, objects, and components • Discuss ComponentWare article

  3. Software Reuse • Software reuse is the process of creating software systems by using existing functionality or by combining predefined software components

  4. Programming for reuse and programming with reuse • Two perspectives of software reuse • Creation: creating reusable resources in a systematic way (programming for reuse) • Use: reusing resources as building blocks for creating new systems (programming with reuse)

  5. Levels of Reuse • A reusable component may be code • Most prevalent: what most programmers relate with reuse • But benefits result from a broader and higher-level view of what can be reused: • Software Requirements • Designs • Data • Test cases • Documentation

  6. Types of Code Reuse • White box reuse • Reuse of code when code itself is available. Usually requires some kind of modification or adaptation • Black box reuse • Reuse in the form of combining existing code by providing some “glue”, but without having to change the code itself - usually because you do not have access to the code

  7. Phases of Reuse • Location • Finding and retrieving relevant code in a library or repository • Evaluation • Understanding the located code and assessing usefulness in the current usage context • Adaptation • Customizing the code to fit the current usage context (in the case of white-box reuse) or wrapping the component as necessary and glue it with other components in the current context (in the case of black-box reuse)

  8. The Reuse Process • Reuse is a process of analysis and synthesis of information • Analysis: when locating relevant resources and evaluating their appropriateness for use in the current context, the re-user is analyzing the information in the repository of reusable resources • Synthesis: when the relevant resource is being adapted to the current context or recombined with other resources in a new way, the re-user is synthesizing information.

  9. Why reuse? “The drive to create reusable rather than transitory artifacts has aesthetic and intellectual as well as economic motivations and is part of man’s desire for immortality. It distinguishes man from other creatures and civilized from primitive societies” (Wegner, 1989).

  10. Why reuse? • Reuse is cost-effective • Increases software productivity by shortening software production cycle time (software developed faster and with fewer people) • Does not waste resources to needlessly "reinvent-the-wheel" • Reduces cost in maintenance (better quality, more reliable and efficient software can be produced) • Reuse produces reliable software • Reusing functionality that has been around for a while and is debugged is a foundation for building on stable subsystems • Reuse yields standardization • Reuse of GUI libraries produces common look-and-feel in applications

  11. Reuse Methods • Libraries • Source Code Repositories • Copy & paste • Object Oriented Programming Languages • Techniques such as information hiding, abstraction, inheritance, and generics have a lot of reuse potential • Software Components • Software modules with standard interfaces that enable interaction with each other • Design Patterns • Successful solutions to a set of problems that arise when building software • Higher level than source code or object-oriented design models that focus on individual objects and classes • Frameworks • Similar to design patterns, but whereas patterns are described in a language-independent manner, frameworks are generally implemented in a particular language

  12. Reuse with Object-Orientation • One of the biggest selling points of object-oriented programming was the promise to achieve widespread software reuse • Support for reuse is built-in in the actual programming language

  13. How does object-orientation achieve reuse? • Abstraction, information hiding, and inheritance • An object-oriented design using these techniques creates modular components with standard interfaces, organized by the specificity of the functionality provided • Inheritance • Reuse by definition: subclass reuses the functionality of superclass • Polymorphism • Sending the same message to instances of different classes with different effects • Code including such polymorphic messages can be reused in new situations by manipulating the class of the object receiving the message (Rosson & Carroll, 1996) • Generics • Generic methods allow the definition of clear interfaces to the functionality provided by a given class hierarchy

  14. If reuse is so great, why is it not practiced more? • Having an OO programming language that lends itself to the production of modular components does not guarantee the creation of reusable classes • The skills required to develop, deploy, and support reusable software have traditionally been a “black art,” locked in the heads of expert developers. • Reuse is hard! • Even programmers predisposed to reuse code may need help in recognizing good opportunities for reuse • Reusable code libraries are usually big => need information retrieval technologies to identify candidates for reuse • Once a promising class has been identified, programmers may need help to analyze how to reuse a class, determining whether to incorporate it as-is or specialize it

  15. The Reuse Paradox 90 + 10 = 100 • If a programmer has a component to be reused and 90% of the component is useful and the remaining 10% needs to be changed but it cannot, then the component is 100% unusable (Repenning, Ioannidou and Phillips, 1999) 10 + 100 = 100 • The reuse paradox is that while reusing an existing component is supposed to save time, effort and creative cycles, customizing the component in a new usage context very often ends up taking more time and effort than implementing things from scratch. Even if the 10% of a reusable component in the above scenario is changeable, but changing it takes 100% (or more!) of the time it would take to create the desired component from scratch, then the component is still 100% unusable.

  16. Other factors responsible for the lack of widespread reuse • Organizational factors • E.g. the effort required to catalog, archive, and retrieve reusable components • Economic factors • E.g. the lack of adequate chargeback schemes and monetary incentives in many development organizations • Political factors • E.g. not wanting to share components with rival groups • Psychological factors • E.g. perceived threat to job security and the ubiquitous “not invented here” syndrome. (Schmidt, 1996)

  17. Has object-orientation fulfilled its promise? • Sophisticated frameworks of reusable components are now available in many OO languages running on many OS platforms • BUT: • Success is limited to certain domains, such as graphical user-interfaces • Reuse is often limited to third-party libraries and tools, rather than being an integral part of the software development processes in most organizations. (Schmidt, 1996) • OO has yet to deliver widespread improvements in the quality and quantity of reuse

  18. Objects are dead, long live components (?)

  19. What are Components? • There is no generally accepted definition of components. • Some definitions: • A module • A deliverable object or framework: a unit of deployment • A binary that can create instances (of multiple classes). • A set of interfaces with offers and requires constraints. • A binary unit of independent production, acquisition and deployment • A unit of composition with contractually specified interfaces and explicit context dependencies • A unit of executable deployment that plays a part in a composition (http://uml.tutorials.trireme.com/uml_tutorial_7.htm)

  20. Component-Based Development • Development involves selecting or designing an application architecture, defining services, and mechanisms that become part of the framework and defining and implementing standard interfaces that enable components to interact with each other

  21. The Component Vision Conceptualize software as interconnectable and interoperable components, use and reuse them, plugging them together the same way that hardware components are plugged together in Integrated Circuits (Cox & Novobilski, 1991)

  22. Why Components? • Componentizing software introduces greater customizability • Components enable plug-and-play • Include their own metadata and be assembled without programming • => Not always: Scripting is an increasingly popular way of gluing components together

  23. Have components achieved reuse? • While components can be highly reusable units of software functionality, the software ICs vision is still unrealized • Unlike their hardware counterparts, software components are still not well-defined enough to be able to be plugged seamlessly together • General-purpose software components may never achieve that level • Evidence suggests that successful reuse of software components can happen in narrow domains that are well-understood and domain knowledge changes slowly, and more importantly when inter-component standards exist (Tracz, 1995)

  24. Objects versus Components • Components were needed initially because OOPLs were restricted to one address space. Objects compiled by different compilers (even in the same language) could not communicate with each other (http://uml.tutorials.trireme.com/uml_tutorial_7.htm) • In OO, both development and assembly are very technical • Objects are rarely shaped to support “plug-and-play” • In CBD, construction is technical, but assembly must be open to a wider user base • “Object orientation has failed but component software is succeeding” (Udell, 1994)

  25. Discussion: Reuse, objects, and components • Do you reuse? • Why or why not? In what cases? • What? • How? • What is hard about it? • What would make it easier? • Do you develop code with reuse in mind? • Why or why not? • How? • On the article: • Do you agree with the basic premise of the article that objects are out (in terms of reuse) and components are the way to go? • Has OO failed to fulfill reuse promise? • Do components fulfill the reuse promise? • Why or why not? • Some of the technologies presented are obsolete. Are there any new technologies that have been introduced since the article was written have moved in the right direction for reuse?

  26. Homework 4 Reminder • Choose a name for your team. • Design the project AS A TEAM. Use any design methods/diagrams you find useful as a means to organize your work and communicate as a team. • Implement the project in AgentSheets AS A TEAM. You are responsible for finding meaningful ways to divide workload within your team. • ONE member of your team should turn in (via email): • Team name and members • Design diagrams • AgentSheets Project folder (zipped or stuffed): Please follow naming conventions (use your team's name) • Description of your project including directions on how to use it. Please include any insights on pragmatic web applications, accessing data, utilizing it in a simulation, and presenting it to the user. • Due: Oct. 1

More Related