Apparatus and method for visual construction simplification

Details Apparatus and method for visual construction simplification Apparatus and method for visual construction simplification

1998-07-15

2002-08-13

Morse, Gregory (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Code generation

C717S136000

Reexamination Certificate

active

06434740

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to object-oriented programming. More specifically, this invention relates to reducing the complexity of object interfaces.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Modern computer systems vary in their design and architecture, with many different models available to achieve the desired combination of speed, power and efficiency for any given computing environment.
Computer systems typically include operating system software that controls the basic functions of the computer, and one or more software applications that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the software applications designed for high performance computer systems have become extremely powerful.
Object-oriented programming, based on an object model, is a new way of creating computer programs that has become very popular over the past several years. The goal of using object-oriented programming is to create small, reusable sections of program code known as objects that can be quickly and easily combined and re-used to create new programs. By creating and re-using a group of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Objects help program designers create better software faster because objects are reusable, have defined interfaces, and are already tested. In addition, some of an object's interface (where other objects are allowed access to some of the internals of the particular object) and much of the internal workings of the object can be changed without changing the objects that use the particular object. In other words, if Object A uses Object B to perform a certain function, the way that Object B actually performs that function can be changed without any changes to Object A or without changes to Object B's interface. Because the inner workings of objects are “hidden,” objects can be changed to a great degree without causing changes to outside objects. Another benefit of having the inner workings hidden is that the program designer does not need an understanding of how the object works; instead, the program designer only needs to know what the object does. In this way, the program designer can merely use the object without spending an inordinate amount of time either programming another function to perform the object's function or examining the object to see how it works.
Because of the tremendous improvement in programming simplicity and reuse provided by objects, object-oriented programming has become extremely popular. Many software companies have attempted to make objects even easier to use. For instance, to help program designers who are designing object-oriented programs, computer software manufacturers have designed certain tools to make object-oriented programming easier. One such tool is a visual compiler that shows program designers how the various objects are connected and what their interfaces are. Using these tools, program designers can simply “drag and drop” pre-made objects from a “palette” onto a “canvas” and then connect the objects together. The visual nature of these development tools makes it relatively easy, at least for small programs, to see how the program is designed.
In addition to visual tools, software companies have begun to “package” objects. This packaging of objects can take several forms. One such form, allowed by most visual compilers, is embodied in the idea of components. Components are pre-built objects that perform various functions. The programmer who actually programs the component is called the “component creator,” “component builder,” “component architect,” or “developer.” Both the computer scientist who programs the component and the programmer who uses the component are actually “developers”; however, to clearly demarcate who is actually creating the component, only the component builder will be called a “developer.” The programmer actually using the component is called the “assembler” or “program designer.” Assemblers or program designers choose the pre-designed component that meets their needs, and drop or add the component from the palette to the canvas. Assemblers can also modify the component, if necessary, to perform the assembler's desired function. In addition, assemblers can make their own components that they can then reuse at a later time. Assemblers can combine their own components or other pre-made components into a program by placing each component onto the canvas and connecting all components together.
The second form of the packaging of objects is simply using pre-made components from a software vendor. The software vendor, as the component builder, creates generic components that are applicable to many tasks and then licenses these components to software program designers. Both parties benefit from this arrangement because the assemblers get a well-defined, tested infrastructure upon which to base their applications, and the software vendors receive an influx of money from licensing fees.
Even though visual development systems and components are tremendously useful development tools in simple environments, they suffer from connectivity problems when employed in more complex situations. When an assembler adds an object or component from the assembler's palette onto the assembler's canvas, the assembler must then connect this new object to the old objects that will be interfacing with (or to) the new object. Connections are made to provide paths for data flow between components. The paths for data flow are generally method calls, wherein one component is calling another component's method and sending and/or receiving data at the same time. The connection symbol between objects is visually represented by a line. The connectivity problem in complex environments occurs for at least two reasons. First, the number of lines on the canvas quickly becomes so large as to partially or completely obscure the objects and components. Second, the complexity of even small designs becomes quickly overwhelming with each added component. This occurs because each component may have many connections to multiple components. Even with a relatively small number of components on a canvas, the number of interconnections between the components will be so large that the structure of the program becomes lost in the extreme number of interconnections. The program designer can no longer ascertain what the structure of the program is. The benefit of having a visual design tool that quickly shows the structure of the project is lost in the morass of connection symbols.
For instance, if the assembler is designing a car, the car component will be connected to many other components (or sub-components) such as an engine, doors, a suspension system, a stereo system, etc. Furthermore, many of the sub-components will have sub-sub-components, e.g.—the engine might have a cylinder component to indicate the number, size, and other features and functions of the cylinders. Each of the sub-sub-components will be connected to the appropriate sub-component that, in turn, will be connected to the car component. Finally, many or all of the sub-components and sub-sub-components will have some property that can be modified by the assembler or user of the system being designed. The assembler or user changes these properties through some type of user interface (UI). The UI will generally be performed by a UI component that has been specifically adapted to the particular data that needs to be entered. As an

Affiliated with

Also associated with

Rating

Apparatus and method for visual construction simplification does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Apparatus and method for visual construction simplification, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for visual construction simplification will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2965838