Data processing: software development – installation – and managem – Software program development tool – Editing
Reexamination Certificate
1999-10-01
2003-05-13
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Editing
C717S102000, C717S104000, C717S105000, C717S109000, C717S110000, C717S115000, C717S116000, C717S125000
Reexamination Certificate
active
06564368
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to the field of computers and, more specifically, to a method and system of visually developing distributed applications without programming.
2. Description of the Related Art
Computers as in
FIG. 1
are comprised of digital processors that execute instructions to perform tasks. A collection of instructions, or machine code, is referred to as a computer program. Programs can be manifested in a variety of forms, such as but not limited to stand-alone Executables, Libraries, Dynamic Link Libraries, Drivers, Components, Objects, and Distributed Objects.
Programs are created from instructions of a programming language that are accumulated into the program's source code. The source code controls presentation, interfaces, and logic. A programmer authors source-code and compiles it into processor machine code utilizing a compiler compatible with both the source code's language and target processor.
Some programs have an interface that allows other external programs to interact with the program during run-time execution. The interface to Executables, Libraries, and Drivers is typically called an Application Programming Interface or API, while the interface to Components, Objects, and Distributed Objects is simply called an interface. Despite some functional differences, each provides a mechanism for a programmer to interact with a program.
Regardless of the program, its interface will be comprised of one or more of the following primitives: (1) Parameter or Property of a fundamental data type, or (2) Function or Method, which further has an optional list of fundamental data types.
Applications are constructed from one or more programs. Programmers write source code leveraging interfaces that enable disparate programs to interact with each other and provide greater utility.
The process of writing source-code, compiling the source code into machine code, and debugging programs is incredibly costly and difficult. There are very few programmers relative to the general population, and very few highly skilled programmers relative to all programmers. Furthermore, there is little consistency between interfaces of disparate programs causing programmers to face long learning curves when implementing third-party programs in their applications.
To eliminate many of the problems associated with programming, there has been long standing goal in the field of software development to achieve the same level of “componentized” development as in the field of electronic circuit design. In 1968, Doug McIlroy presented a paper on
Mass Produced Software Components.
The following is a quote from this paper: “Follow the lead of hardware design! It is not right that every new development should start from scratch. There should be catalogs of software modules, as there are catalogs of VLSI devices: when we build a new system, we should be ordering components from these catalogs and combining them, rather than reinventing the wheel every time.”
To assure interoperability between devices, electronic circuit design industry standards emerged in the form of “Logic Families” such as TTL or CMOS. A logic family defines strict operating parameters such as temperature, frequency, voltage-swing, power, or propagation time. These rules assure devices in the same logic family will work together when connected into a functional design. Standardization of logic families was facilitated in large part because of the limited number of market participants. Unlike in software, a high barrier of entry into the world of electronic device manufacture exists because the expense and expertise to create electronic devices is well beyond what any individual or small company can afford. The result is a few large and well-established companies dominate the market.
Electronic circuits, analogous to software applications, are constructed by connecting existing devices together in an order that provides a useful utility. The cost, efforts, and skill required to construct a circuit in this manner is many orders of magnitude less than that of constructing the actual devices, such as an Intel Pentium Processor™. By isolating the most complex job, such as the construction of a processor, into the domain of a very few highly skilled individuals, the industry is assured the rapid, high-quality construction of products that reuse the efforts of the most skilled engineers.
Unfortunately, there is a very low barrier to entry into the domain of creating computer programs, so no industry standardized logic family that would assure disparate programs could inter-operate without the need for programmers has been established. Thus, application development remains a slow inefficient process dominated by human error and competing standards.
Attempts have been made to solve these problems with the introduction of visually developed executable computers programs; however, many have failed to achieve the level of success as experienced in the electronic paradigm. Highly graphical development environments such as Microsoft's Visual-C++™ or Borland's Delphi™ have facilitated the creation of programs and applications, but at their heart remain programming environments requiring programmers to create and compile source code to do any but the most basic operations.
Visual connection paradigms have been developed to automate data flow between the properties of component frameworks that have metadata and support Run-Time-Type-Information (RTTI) and dynamic invocation, such as COM, or CORBA. A visual development environment may include an interface having a component inspector, component manager, component library, and one or more visual editors. A user can construct a program by selecting one or more components from the library, which displays components in a tabbed palette. Using a visual editor of the system, the user may drill-down into the internals of a component, for modifying its logic. Once the functionality of a component is completed, the user may proceed to connect together various components via the component “ports”, which allow access to properties of the component. Components of the system may be nested within other components to an arbitrary level.
Other visual approaches focus on creating named relations between classes in a dynamic object-oriented programming environment via mappers. The mapping objects dynamically bind to the class interfaces of the classes being related. These connections between classes are defined within a visual environment. The relationships can be programmatically attached by name to object instances during program execution. Because these relationships are stored in a resource and are dynamically bound by name to the objects, they can be created and modified without requiring the source code of the objects being associated to be changed. This eliminates hard coded dependencies between objects that impede reuse of the objects in other contexts. This type of program requires meta-data, full dynamic binding and probing support in the objects being connected with the invention.
By operating in a completely generic fashion, these approaches are limited strictly to modern component frameworks, and further are limited to the static metadata, such as Run-Time Type Information (RTTI), of components that cannot alter their behavior based on the run-time discovery of data; this relegates their usefulness to nothing but simple user interfaces. Most importantly, these solutions present numerous user steps to expose connections points between disparate programs and, though graphical and automated, are unable to access and operate dynamic data without programmer intervention.
SUMMARY OF THE INVENTION
The Visual Development System of the present invention offers a common Rapid Application Development environment with the addition of a Visual Data-Flow Model, the Connection Editor. The Connection Editor interacts with the interface manager of all programs in the system to render the real-time status of connecti
Beckett Becky
Beckett Stephen
Donnelly Ray
House Donald
Lamberti Santino
Call Center Technology, Inc.
Morse Gregory
Thomas Kayden Horstemeyer & Risley LLP
Vo Ted T.
LandOfFree
System and method for visual application development without... 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 and method for visual application development without..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for visual application development without... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3030366