Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-01-31
2002-12-17
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C717S107000
Reexamination Certificate
active
06496870
ABSTRACT:
COPYRIGHT NOTIFICATION
Portions of this patent application include materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document itself, or of the patent application, as it appears in the files of the United States Patent and Trademark Office, but otherwise reserves all copyright rights whatsoever in such included copyrighted materials.
FIELD OF THE INVENTION
This invention generally relates to improvements in computer systems and, more particularly, to an improved system development tool and functions thereof for manipulating and facilitating the development of object oriented based applications and applets, particularly with respect to achieving collaboration among designated elements of the system development tool or applets and applications it creates.
BACKGROUND OF THE INVENTION
Object oriented based programming (OOP) is probably the most arresting, stimulating and intriguing aspect of programming in today's software world. Although it has been available for some time in languages such as Simula and SmallTalk and recently in C++ and Java, OOP has only recently taken hold as the hoped for solution to closing the gap between the theoretical capability of hardware and the general performance of software while simultaneously solving problems left over from prior software development approaches.
In the past, programming development which began with a single procedure approach, evolved to modular programming, went from there to structured programming and then branched off into computer aided software engineering (CASE) and program generators. All of these methodologies, while solving some or many of the difficulties inherent in prior approaches, introduced their own limitations and inefficiencies. Program bloat, data corruption and “spaghetti” code were but a few of the problems that were caused or left unsolved by the aforementioned software development approaches.
In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.
The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still “sits on top of” the system.
Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.
Into to this breach, entered Object-Oriented Programming (OOP) techniques which involve the definition, creation, use and destruction of “objects.” Objects are self-sufficient software entities comprising data elements and routines, or functions, sometimes called methods, which are used to manipulate the data elements. The object's data and related functions are treated by the software as an entity and they can be created, used and deleted as if they were a unitary item. Together, the data and functions enable objects to model virtually any real-world entity in terms of its characteristics, which can be represented by the data elements, and its behavior, which can be represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs.
Objects are defined by creating “classes” which are not per se objects themselves, but which act as templates that instruct a compiler how to construct an actual object. A class may, for example, specify the number and type of data variables and the steps involved in the functions which manipulate the data. An object is actually created in the program by means of a special function called a constructor which uses the corresponding class definition and additional information, such as arguments provided during object creation, to construct and initialize the object and its data members. Likewise objects are destroyed by a special function called a destructor. Objects are employed by using their data and invoking their functions to accomplish a task.
The concept of an object is predicated on and the benefits of object-oriented programming techniques arise from the use of three basic principles; those of encapsulation, polymorphism and inheritance. These principles work in conjunction with objects as described below. It is noteworthy to distinguish between an object and a class of objects. A class is a type definition or template used to create objects in programs. The objects so created are then merely each a single instance of the class of objects, which is often just called a class. A class has no memory or behavior of its own except to serve as the blueprint from which objects can be created.
An object is a self-sufficient component that includes both data and function. An object is of the same type as the class from which it has been derived. Objects are said to be instantations of their class and use memory for their data and functions, unlike the class template itself which does not.
Objects can be designed to hide, or encapsulate, all, or a portion of, their internal data structure and internal functions. OOP also allows a programmer to create an object that is a part of another object and thereby define assemblies and sub-assemblies, as may be required by a program or the situation or item it is modeling.
More particularly, during program design, a program developer can define objects in which all or some of the data variables and all or some of the related functions are considered “private” or made available for use only by the object itself. Other data or functions can be declared “public” or available for use by other objects or programs.
Further, access to private variables by other objects or programs can be controlled by defining public functions for an object which access the object's private data. The public functions form a controlled and consistent interface between the private data and the “outside” world. Any attempt to write program code which directly accesses the private variables causes the compiler to generate an error during program compilation which error stops the compilation process and prevents the program from being run.
Polymorphism is capability to conceal the different implementations behind a common interface. This means that separate objects of
Beyer Weaver & Thomas LLP
Sun Microsystems Inc.
LandOfFree
System, method and article of manufacture for collaboration... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System, method and article of manufacture for collaboration..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System, method and article of manufacture for collaboration... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2973521