Unified event programming model

Details Unified event programming model Unified event programming model

2000-07-06

2003-09-23

Chaki, Kakali (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Programming language

C717S104000, C717S107000, C717S140000, C717S165000, C709S230000, C709S241000, C709S241000

Reexamination Certificate

active

06625804

ABSTRACT:

COPYRIGHT NOTICE/PERMISSION
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright© 2000, Microsoft Corporation, All Rights Reserved.
TECHNICAL FIELD
The present invention pertains to a unified event programming model that standardizes event programming for disparate eventing protocols. The unified event programming model includes standard event programming compiler constructs.
BACKGROUND OF THE INVENTION
To manage the complexity of long computer programs, computer programmers often adopt object-oriented programming techniques. With these techniques, a computer program is organized as multiple smaller modules called objects. Each object performs specified functions and interacts with other objects in pre-defined ways.
FIG. 1
shows several principles of object oriented programming with reference to an object
100
that interacts in pre-defined ways with a client
140
(which can also be an object)
The object
100
encapsulates data
110
, which represents the current state of the object
100
. The data
110
can be organized as data elements such as properties of the object
100
. The object
100
exposes member functions (alternatively called methods)
120
,
122
, and
124
that provide access to the data
110
or provide some other defined function or service. To access the data
110
, the client
140
of the object
100
calls a member function. In
FIG. 1
, the member functions
120
,
122
,
124
are grouped into an interface
126
.
FIG. 1
also includes an interface
130
(shown without member functions for simplicity).
The object
100
and the client
140
interact across the interfaces exposed by the object
100
. For example, for the client
140
to invoke the member function
120
, a function call in the client
140
identifies the member function
120
, provides any data to be processed (e.g., input parameters for arguments), and indicates any data to be returned (e.g., output parameters for arguments, return values). Similarly, for the client
140
to set a value for a property of the data
110
, the client
140
identifies the property and provides the value.
FIG. 1
shows a software object designed according to a particular object model. In fact, many different software object models exist, each establishing a set of conventions by which objects are designed and by which objects communicate. For example, an object model might specify how an interface is organized, how an object implements an interface, how an object exposes an interface to other objects, which methods are required, etc. Different object models provide different answers to these questions. A computer programmer can write code for a software object in any of numerous different programming languages.
Communication between objects can occur in two directions. For example, one object (an event receiver) can arrange with another object (an event source) to have that other object call back the first object when some event occurs. For example, suppose that the event receiver is for reacting to a mouse button clicked by a user and that the event source tracks the mouse button state. The event receiver can arrange with the event source to have the event source call back the event receiver when an event occurs. The event source calls back to the event receiver as the events happen, or asynchronously, rather than at a regular interval. A single event source can call back to multiple receivers registered for the event, in which case the callback is termed multicast.
Due to the effectiveness of events for object communication, many programming languages and software object models support events. Typically, each programming language and software object model has its own eventing protocol, and each of these eventing protocols has its own nuances and particular rules.
Different object models work best in different situations, so a programmer might need to know how to program for different kinds of objects. To use the eventing protocol for an object, however, a programmer must know the particular rules and nuances of that eventing protocol for that type of object. Unfortunately, no unified event programming model exists for programming an object to work with events according to different eventing protocols, independent of the actual eventing protocol used by the object for the events.
SUMMARY OF THE INVENTION
The present invention overcomes these problems through a unified event programming model [“UEPM”] that standardizes event programming for disparate eventing protocols. The UEPM provides a programmer with an easy to use and systematic way to program events for objects, regardless of which eventing protocol the objects actually use. This hides from the programmer the bulk of the eventing protocol-specific details relating to implementation of the objects.
The UEPM includes standard event programming compiler constructs. One construct allows a programmer to specify an eventing protocol for an object to use. For an event source object, a construct allows a programmer to indicate the event. For an event receiver object, constructs allow a programmer to indicate how to hook up the receiver to the source for the event, or later unhook the receiver. Using these constructs, a programmer can specify event relationships between an event source and an event receiver in a protocol-independent manner. From the constructs, the compiler generates a protocol-specific eventing implementation, which can be for any of several different eventing protocols. At compile time, the compiler can verify the existence of events and checks parameter types for receivers trying to hook to events. This type checking at compile time eliminates expensive run time type checking and simplifies debugging.
By allowing high-level specification of event relationships between objects, the UEPM also gives programmers a simple way to write objects of different object models that can interoperate for eventing.


REFERENCES:
patent: 5999728 (1999-12-01), Cable
patent: 6167564 (2000-12-01), Fontana et al.
patent: 6182024 (2001-01-01), Gangopadhyay et al.
patent: 6347342 (2002-02-01), Marcos et al.
patent: 6385769 (2002-05-01), Lewallen
patent: 6408342 (2002-06-01), Moore et al.
patent: 6510550 (2003-01-01), Hightower et al.
Silva et al., “User Interface Modelling with UML”.*
Grundy et al, “Towards a Unified Event-based Software Architecture”, ACM, SIGSOFT 96 Workshop, 1996, p 121-125.*
Needham et al., “ADAM: A Language-Independent, Object-Oriented, Design Environment for Modeling Inheritance and Relationship Variants in ADA 95, C++, and Effel”, ACM, 1996.*
“OMG Unified Modeling Language Specification”, Object Management Group, up to section 1.*
Quatrani, Terry; “Visual Modeling with Rational Rose and UML”; Addison Wesley Longman, Inc.; Apr. 1998.*
Kraig Brockschmidt,Inside OLE, Second Edition, “Chapter 4, Connectable Objects,” Microsoft Programming Series, Microsoft Press, pp. 187-218, 1995.
Kraig Brockschmidt,Inside OLE, Second Edition, “Chapter 24, An Introduction to OLE Controls,” Microsoft Programming Series, Microsoft Press, pp. 11/1-1144, 1995.
Jeff Prosise,Programming Windows with MFC, Second Edition, “Chapter 21, ActiveX Controls,” Microsoft Programming Series, Microsoft Press, pp. 1225-1291, 1999.
Laurence Vanhelsuwé,Mastering Java Beans, “Chapter 2, JavaBeans: An Overview,” Sybex Inc., pp. 40-66, 1997.
Laurence Vanhelsuwé,Mastering Java Beans, “Chapter 3, The Java 1.1 Delegation Event Model,” Sybex Inc., pp. 70-145, 1997.
Laurence Vanhelsuwé,Mastering Java Beans, “Chapter 4, Bean Properties,” Sybex Inc., pp. 148-209, 1997.
Laurence Vanhelsuwé,Mastering Java Beans, “Chapter 5, Bean Events,” Sybex Inc., pp. 2

Affiliated with

Also associated with

Rating

Unified event programming model does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Unified event programming model, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Unified event programming model will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3095671