Interface repository browser and editor

Details Interface repository browser and editor Interface repository browser and editor

2000-12-11

2003-03-11

Coby, Frantz (Department: 2171)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C707S793000, C345S076000, C345S156000

Reexamination Certificate

active

06532471

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the arts of object oriented programming, and to tools for browsing and editing interface repositories on local and remote object servers. This invention relates especially to graphical browsers of interface repositories for CORBA remote and local object containers.
2. Description of the Related Art
Traditionally, programming techniques utilize a flow of steps for a procedure or process. Processes and steps are carried out from one step to another until an entire procedure or task is completed. Decision points and branches further add flexibility and breadth to a traditional program. These types of traditional programs can be represented easily by flow charts.
However, computer programs have become much more complex in recent years, and often include coordinated operations and communications between processes that are running on independent computers which are Internet worked to each other. Processes executing on “client” computers may request invocation of processes on “server” computers on their behalf, to perform specific operations, gather or return data, or invoke other processes on still other computers.
This “distributed” nature of modem computing makes it very difficult if not impossible to represent in a flow chart form all possible combinations of steps, branches and decision points interrelating the processes which are executing at the same time on different computers. Further, the approach of using flow charts to describe the high level operation level of computer program is often times unwieldy to separate into individual design projects so that the computer program can be implemented by a large team of software engineers.
One approach employed to deal with these difficulties is to break large computer programs into relatively small, self-contained items referred to as “objects.” The process of decomposition of a large program into “objects” often reveals a logical structure of the problem which is to be solved by the large computer program. The formalized approach to decomposing software programs into such self-contained items or “objects” is known as Object Oriented Programming (“OOP”).
Objects are actually abstractions of physical entities or conceptual items. Objects have “states” and “identities” which are inherent to their existence, and they encapsulate “properties” or “attributes”, and “operations” which may change those properties or attributes. The state of an object is determined by the values of its attributes at any given time, and those attributes may be changed through its operations of the objects. Many object-oriented programming languages have been adopted and are in widespread use today, including C, C++, Smalltalk, ADA, COBOL, and JAVA. Further, the terminology used within a given object-oriented programming language may be slightly different from each other, but may still represent the same concepts and design techniques. For example, implementations of an object's operations are referred to as “methods” in JAVA and “member functions” in C++.
Through the use of object-oriented programming techniques and technologies, objects which were developed or objects which were developed in different programming languages may interoperate, invoke each other, and communicate to each other.
In developing object-oriented programs, several well-known modeling methods have been developed, such as the different modeling methods developed by Booch, Jacobson and Rumbaugh. These three eventually converged and merged their modeling methods into what is now known as Unified Modeling Language (“UML”). The consortium formed by the UML developers is now called the Object Management Group (“OMG”).
Although the older forms of object oriented programming modeling are still used by many engineers, UML has been adopted by many of the larger corporations involved in software development, as well as by various industry associations and consortiums.
When a designer is creating a new program or object using OOP techniques, he often relies on three main characteristics of the objects which he is including in his design. The first of those object characteristics is referred to as its “inheritance” characteristic. An object class describes a set of object end features, all of which share the same attributes and behaviors. A new class, called “subclass”, may be created to define or describe a set of object instances which inherit all of the attributes and behaviors of the “superclass”, or original class. As such, an object instance included in a subclass inherits all of these characteristics and functional capabilities of the members of the superclass, but it may “override” those behaviors and attributes by providing a new implementation for inherited characteristics. Inheritance is well understood in the art. Further, each object oriented programming modeling method provides for a visual format of representing object and their relationship to each other with respect to inheritance of attributes and behaviors.
A second characteristic necessary to be understood about an object or object class to be used during design of a new computer program is its “interface.” An interface is an abstraction of the way that other processes or objects may instantiate or invoke a particular object. An object's interface describes the attributes and behaviors available within an object, as well as the parameters which must be provided to the object in order for it to perform its function. The interface also describes the return information or arguments provided by the object at the conclusion of or during the operation of its function(s). Thus, for a first object or process to effectively instantiate or otherwise use another second object, the first object must be aware of and use the interface of the second object to be used.
A third characteristic of an object which is necessary to be understood by a designer when using an object is where it is “contained.” The object “container” holds a group of objects within it, and it may create and destroy “instances” of objects. But, containers do not create new objects. Thus, a container, which is a type of “collection manager”, may manage the creation of instances of objects within the container upon request by other objects, and may destroy those instances when the requesting object is finished using the object. For example, if an object requests an instance of another object within a container, the manager associated with that container would create a new instance of the requested object and place that under control or at the disposal of the requesting object. The concept of “containment” in containers is well understood in the art, and the OOP modeling techniques provide for methods of illustrating containment.
With the rapid spread of distributed network computing, especially over the Internet, object oriented programming readily lends itself to the inclusion of and inter-operation of objects which are physically located on servers and clients which are disparate. For example, a process running on a computer in a bank may wish to calculate the current value of an investment account. Under traditional techniques, it may do this by accessing a local or remote database of data related to investment values, and performing all of the calculations locally.
However, using distributed OOP techniques, the process on the bank computer may simply request the creation of an object which can calculate the current value of an investment portfolio. This second object, which does the calculation, may either be located on the same server or located on another server over a computer network such as the Internet.
FIG. 1
illustrates this type of client/server arrangement, wherein the bank computer of this example would be the “object client” computer (
1
), the “object server” (
5
) would execute the portfolio calculation methods at the request of the client computer (
1
), and communications of initial data and result data would be made over a computer network s

Affiliated with

Also associated with

Rating

Interface repository browser and editor does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Interface repository browser and editor, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interface repository browser and editor will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3012791