Data processing: software development – installation – and managem – Software program development tool – Code generation
Reexamination Certificate
1999-03-10
2002-07-16
Morse, Gregory (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Code generation
Reexamination Certificate
active
06421821
ABSTRACT:
CROSS REFERENCE TO RELATED APPLICATIONS
Not applicable.
FIELD OF INVENTION
This invention relates to programming methods and procedures and more particularly to a system which aids in the creation or writing of an object-oriented program.
BACKGROUND OF THE INVENTION
As is common practice, software engineers utilize one of two approaches for developing computer software. The first approach is called a functional decomposition approach, sometimes called a procedural approach, and an object-oriented approach. The end result of the use of either of these two approaches is the same in that a piece of hardware or software is created to solve a particular problem, usually referred to as a domain problem.
The functional decomposition or procedural approach first breaks down the domain problem into functions. These functions are further decomposed in search of common software routines so that the solution may be efficiently implemented in software. The first functional approach to programming was invented by John Von Neumann in 1947 when flow charts were used to describe computer programming algorithms. Later in the 1950s and 1960s, flow charts were used to specify and describe complete computer programs. As higher level languages, like BASIC, COBOL and C were developed and as applications became more complex, such flow charts fell from favor. New software generating techniques called structured programming were developed and formalized in the 1970s. Structured programming allowed for more modular programs. In the early 1980s a procedural language based on flow charts and multitasking was developed by Ron Lavallee and Tom Peacock and is described in U.S. Pat. No 4,852,047, issued Jul. 25, 1989. In this patent, industrial processes are controlled by characterizing the industrial process with a flow chart and then executing directly from the flow chart, thereby eliminating the necessity for ladder diagram programming tools which were cumbersome at best.
By the mid-1980s, due to the ever increasing complexity of software and never ending changes, object-oriented software emerged. Languages such as Small Talk, C++ and ADA were developed.
By the early 1990s, a simplified object-oriented language called Java was added to the list of object-oriented languages. Due to the advent of the internet and Java, future software development is now tending towards the object-oriented approach. This is because object-oriented software is easier to maintain and promotes software reuse. Software is developed around real world entities and, hence, when a change to how an entity behaves is made, the program is only changed in one place. With a functional decomposition programmed system, a change to behavior usually requires changing the programming in many places.
Importantly, however, in object-oriented programming, the objects making up the program exist in no apparent order and are described by literal statements, making the programming difficult to visualize. Thus when objects are displayed, they are displayed on screen with no visual linkages as to the order of their execution. There is therefore a need for a programming aid which permits both programmers and those charged with solving a domain problem to be able to quickly visualize an object-oriented program from a macroscopic level so that direction can be given and changes can be made to the program.
By way of further background, the characteristics of object-oriented programs are as follows. Presently, object-oriented software programs represent objects and class entities with literal statements. Syntax-based languages such as Java and C++ represent an object such as Jim=new person as a literal statement. Here Jim is an object of the class person. Using the approach provided in the Universal Modeling Language or UML representation, an object would be represented as Jim: person where Jim again is an object of the class person. By definition in all object-oriented languages, objects have attributes, information used by an object and methods or behaviors carried out by an object. Further, all object-oriented systems have a means to describe relationships between objects such as creation or instantiation, messaging, association, dependency and more.
Graphical systems sometimes used to show relationships for clarity, are not needed by the literal systems. Most graphical systems are used for analysis for the particular problem, called the problem domain, and are thereafter converted via generating a program into a literal language such as object-oriented language, such as Java, C++, Small Talk and Effel for execution by a computer.
In the past, graphical systems have primarily used two types of diagrams to describe the domain problem. The two types of diagrams are interaction diagrams and state charts. Interaction diagrams show objects and the messaging between the objects, whereas state charts are used to show object behavior or methods and object life cycle state changes. However, none of these graphical systems constitute the program, which must be generated separately in literal terms.
For instance, as far as interaction diagrams are concerned, these diagrams can take the form of a collaboration type diagram in which individual blocks indicating objects have lines between them and arrows indicating messaging between the blocks. In terms of a sequence for interaction diagrams, a ladder diagram type arrangement is sometimes used in which timing of a sequence runs down the chart, with horizontal arrows indicating messages between the objects.
As to state charts, these charts indicate object behavior. For instance, if an object in the form of a human being is to jump, the state indicates a jump sequence in which an object is to extend the legs, fly the body and land.
The above charting techniques describe some attributes of objects, but not the underlying object-oriented program. These charting techniques can therefore hinder the programmer in explaining the program to the expert who has hired him/her, or even to collect the programmer's thoughts in a manner which will enable quick object-oriented programming.
Thus, in the end object-oriented programming has been performed by making a literal, written statement as to what the object and class is and what the object is supposed to do. Lists of statements are exceedingly hard to interpret to those who are not object-oriented programmers and especially hard for those who are requesting a problem to be solved to understand.
As to Domain Experts, it will be appreciated that object-oriented systems and structured systems focus on how the software is to be constructed, an important point. Thus, the person most able to assist at this point is the domain expert. With software playing an ever increasing role, software engineers must interface with domain experts more and more. Domain experts are, for instance, a banker specifying a banking system, a process engineer defining a manufacturing function or a mechanical designer designing an active suspension for a car.
It will be noted that the software engineer's first task is to capture the domain expert's knowledge. The only way that this is possible is through communication. Text based communication can be ambiguous and often makes it difficult to see what the system is actually doing.
Moreover, the application which the software is to run is typically broken down into use cases. A use case shows the interaction between the user and the system objects that perform a particular function. This is presented to the user in the form of text and ancillary interaction diagrams. However, this is not a natural or intuitive way for the domain expert to visualize the application or the object-oriented programming. The above-mentioned state charts are sometimes used to further define a use case object method, but again, the domain expert must be familiar with state charts to fully understand what knowledge the software engineer thinks he/she is capturing.
Another problem with the current object-oriented program techniques i
Chavis John Q.
Morse Gregory
Tendler Robert K.
LandOfFree
Flow chart-based programming method and system for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Flow chart-based programming method and system for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Flow chart-based programming method and system for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2880851