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

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)

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

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

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)

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.

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).

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

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

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

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

How does object-orientation achieve reuse?

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

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.

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)

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

Objects are dead, long live components

(?)

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)

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

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)

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

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)

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)

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?

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