REGISTER  |  SIGN IN
United States Patent6681383
Pastor , ; et al.January 20, 2004
Title
Automatic software production system
Abstract
An automated software production system is provided, in which system requirements are captured, converted into a formal specification, and validated for correctness and completeness. In addition, a translator is provided to automatically generate a complete, robust software application based on the validated formal specification, including user-interface code and error handling code.
Inventors:Pastor; Oscar (Valencia, ES), Iborra; Jose  (Denia Alicante, ES)
Assignee:Sosy, Inc. (Boston, MA)
Appl. No.:543085
Filed:April 4, 2000
Current U.S. Class:717/126 
Current International Class:G06F 9/44 (20060101)
Field of Search:717/1,5,7,126 703/13,20 705/7 345/326,113
U.S. Patent Documents
4734854March 1988Afshar
4841441June 1989Nixon et al.
5185867February 1993Ito
5371895December 1994Bristol
5459866October 1995Akiba et al.
5485601January 1996Ching
5561802October 1996Orimo et al.
5581670December 1996Bier et al.
5586329December 1996Knudsen et al.
5603018February 1997Terada et al.
5617114April 1997Bier et al.
5640576June 1997Kobayashi et al.
5742754April 1998Tse
5742827April 1998Ohkubo et al.
5758160May 1998McInerney et al.
5798752August 1998Buxton et al.
5805891September 1998Bizuneh et al.
5842205November 1998Brann
5878262March 1999Shoumura et al.
5956725September 1999Burroughs et al.
5960200September 1999Eager et al.
5966534October 1999Cooke et al.
6058493May 2000Talley
6385765May 2002Cleaveland et al.
Other References
www.google.com search listings.
Primary Examiner: Ingberg; Todd
Attorney, Agent or Firm:Ronald Craig Fish Ronald Craig Fish, A Law Corporation
Claims

What is claimed is:
1. An automated software production tool, comprising: a CASE tool for controlling a computer to provide a user interface that provides tools which a user can invoke to create a conceptual model comprised of an object model, a dynamic model, a functional model and a presentation model, said conceptual model being an abstract graphical representation of a solution to a problem wherein said conceptual model will be automatically translated into a computer program which will be able to control a computer to provide said solution of said problem said user is trying to solve, said object model being a graphical model of the objects to be employed in said computer program and defining classes of said objects, said dynamic model specifying valid object life cycles for each objects defined in said object model and inter-object communications between objects in response to services, triggers and global transactions, said functional model specifying valuations of objects which means how every event changes an object's state depending upon the arguments of the involved event and the object's current state, and said presentation model being built using tools or icons representing basic patterns in user interfaces and defining a desired user interface behavior for said computer program, and said CASE tool for automatically converting said conceptual model into a formal language specification written in an unambiguous, object-oriented, formal language having predetermined precise rules of grammar, syntax and semantics which are such that said formal specification can be validated to ensure that said formal language specification is an unambiguous, correct and complete statement of said solution of said problem said user is trying to solve; a computer-readable medium for storing said formal specification; a validator for validating said formal language specification to ensure that said formal language specification is complete and correct, "complete" meaning all the required properties of said conceptual model are defined and have a value, and "correct" meaning the information introduced in the conceptual model by the user complies with said rules of syntax of said formal language and is semantically consistent and not ambiguous, said validator outputting a validated formal language specification of said solution to said problem prior to automatic translation of said validated formal language specification into computer program code; and a translator for automatically generating computer program code that can either control a computer to solve said problem or which can be compiled into an executable form which can control a computer to solve said problem, said computer program code being a complete, automatically generated computer program implementation in a predetermined, user chosen computer program language of said validated formal language specification, and wherein said computer program code includes instructions for handling said user interface in accordance with said patterns specified in said presentation model.

2. The tool according to claim 1, wherein said CASE tool presents a graphical user interface to allow a user to input requirements for said desired computer program and generating said formal language specification based on said user inputs.

3. The tool according to claim 2, wherein said CASE tool is further configured to provide user interface tools for accepting user input specifying one or more valuations each of which indicates how an event changes the value of a variable attribute for which said valuation is defined.

4. The tool according to claim 3, wherein said valuation is selected from a set consisting essentially of push-pop, state-independent, and discrete-domain.

5. The tool according to claim 1, wherein said formal language specification includes requirements for error checking and error handling so as to cause said software program to have robust behavior, and wherein said translator is configured for automatically generating computer code for said software program which implements said error checking and error handling requirements by including computer instructions for error checking and handling in the automatically generated computer code of said software program.

6. The tool according to claim 5, wherein said translator is configured for generating instructions in said automatically generated computer code of said software program for checking and handling internal errors by checking said formal specification for every point where an internal error might occur and generating instructions to notify the user of the error's occurrence if such an internal error occurs, where said internal errors correspond to properties that must hold at a given instant according to said conceptual model.

7. The tool according to claim 5, wherein said translator is configured for generating instructions for checking and handling external errors corresponding to errors foreign to the conceptual model such as hard disk failure, database failure and other such errors, said error handling instructions generated by anticipating every point in the automatically generated computer instructions where an external error might occur and generating instructions to notify the user of the error's occurrence if such an external error occurs.

8. The tool according to claim 1, further comprising a documentation generator for producing documentation for said automatically generated computer program based on said formal language specification.

9. An automated software production tool, comprising: CASE tool for presenting a graphical user interface to allow a user to input formal requirements for a computer program to be generated by said automated software production tool and generating a formal language specification for said computer program based on said formal requirements written in a formal language such that every formal requirement input by said user is recorded as one or more elements of said formal language specification each of which has predetermined rules of syntax and semantics; a validator for semantically and syntactically validating said formal language specification to ensure said formal language specification is complete, correct and non ambiguous so as to generate a validated formal language specification; and a translator for automatically generating computer code for said computer program based on said validated formal language specification.

10. The tool according to claim 9, wherein: said CASE tool displays tools, menu choices, icons, or any other mechanisms of a graphical user interface which can be invoked by a user of said CASE tool to specify said formal requirements to include patterns for a desired user interface to be presented to a user of said computer program to be generated by said automated software production tool; and wherein said translator is constructed so as to use said patterns specifying said desired user interface to generate in said final computer program instructions to control a computer executing said computer program to implement said desired user interface in accordance with said patterns.

11. The tool according to claim 9, wherein: said formal requirements entered by said user define a conceptual model of said computer program; and said translator includes a system logic translator structured to identify every point in said conceptual model where an internal error might occur, where internal errors correspond to properties of said conceptual model which must be true at a given instant, and wherein said translator is structured to generate instructions in said computer program to control a computer executing said computer program to detect if an internal error has occurred and to notify a user of said computer program of said error's occurrence, and wherein said translator is further structured to anticipate every point in the automatically generated computer instructions of said computer program generated by said translator where an external error might occur and generate instructions to notify the user of the external error's occurrence if such an external error occurs, where external errors correspond to errors foreign to such conceptual model such as hard disk failure, database failure and other such errors.

12. The tool according to claim 9, wherein said CASE tool is further configured to control a computer to present graphical user interface mechanisms by which a user can specify for any object specified by said computer program to be written one or more valuations that control how the occurrence of one or more events will change the state of said object, where the state of said object is defined as the current value of all its attributes.

13. The tool according to claim 12, wherein said valuation(s) are selected from a set consisting essentially of push-pop, state-independent, and discrete-domain.

14. An automated software production tool, comprising: a computer-readable medium for storing a specification written in any formal language having predetermined rules of syntax and semantics said formal language specification specifying a Conceptual Model that includes user supplied requirements for a computer program to be generated automatically by said automated software production tool and which is robust in that it includes instructions to detect and notify a user of both internal and external errors when they occur, where internal errors occur when a property of said Conceptual Model required to be true at a given instant is not satisfied, and where external errors correspond to errors foreign to such Conceptual Model such as hard disk failure or a database failure; a validator for validating syntax and semantics of statements in said formal language specification to determine that said Conceptual Model is correct, complete, and unambiguous so as to generate a validated formal language specification; and a translator for automatically generating computer code of said computer program from said validated formal specification, wherein said computer program includes instructions for detection of internal and external errors and notification of a user of said computer program of the occurrence of said errors.

15. The tool according to claim 14, further comprising a CASE tool for presenting a graphical user interface to present at least diagrams and interactive dialog boxes that allow a user to input unambiguous formal requirements for said computer program and automatically generating said formal language specification based on said formal requirements input for said computer program.

16. The tool according to claim 15, wherein said CASE tool is further configured to control a computer to display a graphical user interface to allow a user to enter input specifying for each variable attribute of each object one or more valuations that indicates how an event changes the value of said attribute.

17. The tool according to claim 16, wherein said graphical user interface of said CASE tool further allows specification of user interface patterns and population of said patterns with data which will create a presentation model of a desired user interface for said computer program, and wherein said CASE tool automatically converts said presentation model into statements in said formal language of said formal language specification which define said desired user interface, and wherein said validator is structured to validate said statements in said formal specification which define said user interface, and wherein said translator is structured to use said statements in said formal language specification which define said user interface to add computer code to said computer program which controls a computer executing said computer program to implement the user interface having said patterns defined by said presentation model.

18. A method for automatically generating a computer program, comprising: accessing a formal language specification written in a formal language which has predetermined precise rules of syntax and semantics such that said formal language specification is guaranteed to be non ambiguous and can be validated to be complete and correct using said rules of syntax and semantics, said formal language specification being created from a Conceptual Model created by a user who specifies requirements for a computer program to be automatically generated, said Conceptual Model including a Presentation Model which specifies through the use of predetermined patterns a desired user interface for said computer program to be automatically generated; validating said formal language specification using rules of validation based upon said rules of syntax and semantics of said formal language to ensure said formal specification is complete and correct and unambiguous to generate a validated formal language specification; and automatically generating said computer program in a computer language that can be immediately executed by a computer or compiled into an executable form from said validated formal language specification, and wherein said automatic generation step includes, based upon portions of said formal language specification which define said desired user interface, inserting computer instructions which control a computer executing said computer program to have a desired user interface in accordance with said patterns specified in said Presentation Model.

19. The method according to claim 18, further comprising the steps of: using a CASE tool to control a computer to present a graphic user interface to provide tools a user can invoke to construct said Conceptual Model, said tools including tools which represent patterns of user interface methodologies which can be specified to define said Presentation Model which defines said desired user interface;
and wherein: said requirements are entered by said user using said tools presented by said CASE tool, and include requirements for error detection and handling to detect the occurrence of internal and external errors and notify a user of said computer program regarding the occurrence of said errors so as to create a robust computer program; and said translation step includes steps to determine where in said Conceptual Model internal and external errors are likely to occur and to add instructions for error checking and handling to said computer program to detect the occurrence of said errors and notify a user of said computer program.

20. The method according to claim 19, wherein said CASE tool controls a computer executing said CASE tool so as to provide tools for invocation by an analyst building said Conceptual Model to allow said analyst to enter input specifying for selected ones of each variable attribute in selected ones of each class in said Conceptual Model one or more valuation formulas, each valuation formula defining how an event changes the value of a variable attribute.

21. The method according to claim 20, wherein each said valuation is selected from a set consisting essentially of push-pop, state-independent, and discrete-domain.

22. The method according to claim 18, further comprising the step of producing documentation for said computer program based on said formal language specification.

23. A method for automatically generating a computer program, comprising: controlling a computer with an editor program so as to present a graphical user interface to provide tools which can be invoked by a user to input requirements for a computer program to be written automatically to implement said requirements, said requirements defining a Conceptual Model which defines the desired computer program's functionality and at least parts of said Conceptual Model being displayed graphically on said computer executing said editor program; automatically generating a formal language specification for said computer program based on said conceptual model, said formal language specification being written in a formal language with precise rules of syntax and semantics; validating said formal language specification using said rules of syntax and semantics to ensure that said formal language specification is complete and correct and not ambiguous to generate a validated formal language specification; and automatically generating said computer program based on said validated formal language specification.

24. The method according to claim 23, wherein said step of controlling a computer with an editor program includes controlling said computer to display a graphical user interface that provides tools which can be invoked to specify a desired user interface for said computer program in terms of patterns, with the patterns specified by said user comprising a Presentation Model; and wherein said step of automatically generating said computer program includes the steps of adding to said computer program instructions for controlling a computer executing said computer program to provide a user interface in accordance with said patterns specified in said Presentation Model.

25. The method of claim 23, wherein said step of automatically generating said computer program includes the steps of determining every point in said Conceptual Model where an internal error might occur and adding computer instructions to said computer program to detect the occurrence of such an internal error and to notify a user of said computer program that said error occurred, where an internal error occurs when a property required by said Conceptual Model to be true at a particular instant is not satisfied.

26. The method according to claim 25, wherein said step of automatically generating said computer program further comprises the steps of identifying every point where an external error might occur and adding instructions to said computer program which detect the occurrence of an external error and notify a user of said computer program of the occurrence of said error.

27. The method according to claim 23 wherein said validating step includes the steps of verifying the completeness of said formal language specification by determining whether there is any missing information therein meaning that all required properties of said Conceptual Model are defined and have a value, and verifying the correctness of said formal language specification by verifying that all the information entered during construction of said Conceptual Model using said editor is syntactically and semantically consistent and not ambiguous and that all properties defined in said Conceptual Model have valid values.

28. The method according to claim 27 wherein said Conceptual Model includes formulas and where said step of validating further comprises the steps of verifying the syntax and semantics of all said formulas in said Conceptual Model.

29. The method according to claim 23 wherein said Conceptual Model includes formulas, and wherein said step of validating includes steps of verifying that the properties of every element in said formal language specification exist and have valid values and that all said formulas in said formal language specification are syntactically and semantically correct where every type of formula has a predefined process and grammar to verify the correctness of said formula.

30. A method for automatically generating a computer program, comprising: controlling a computer with an editor program to present a user interface which provides tools which can be invoked by an analyst to create a graphical representation of a Conceptual Model of a computer program to be automatically generated using said Conceptual Model, said Conceptual Model including information that defines classes of objects and the attributes and services of each object in a class, as well as the relationships between classes, a state transition diagram which defines the permissible state transitions of each object including information that defines the creation and deletion of an object and formulas that control transitions between states, an object interaction diagram that defines how objects communicate with each other, and formulas which define how events change the values of variable attributes of said objects, and information defining patterns of a desired user interface, said editor program controlling said computer to automatically convert said Conceptual Model to a formal language specification written in a formal language with rules of syntax and semantics and to provide notification to said analyst when a mistake of syntax or semantics results in generation of said formal language specification resulting from information defining said Conceptual Model entered by said analyst and providing information which assists said analyst in correcting the entered information to correct said mistake; accessing said formal language specification from a computer readable medium upon which said formal language specification is stored by said editor program; validating said formal language specification to determine that said Conceptual Model is correct meaning that the information entered to define said Conceptual Model is syntactically and semantically consistent according to a grammar of said formal language used to write said specification, and not ambiguous, and complete meaning that there is no information in said Conceptual Model required by the rules of syntax or semantics which is missing in said formal language specification such that all properties required by said Conceptual Model are defined and have a valid value; and automatically generating said computer program using said formal language specification so as to implement all the structure and behavior, properties and services and said user interface defined in said Conceptual Model.

31. The method according to claim 30, further comprising the steps of determining all the points in said Conceptual Model where an internal error might occur and adding instructions to said computer program to detect the occurrence of an internal error and control said computer to notify a user of said computer program of the occurrence of said error, and anticipating every point in said automatically generated computer program where an external error might occur and generating instructions in said computer program to detect the occurrence of such an external error and notify a user of its occurrence.

32. A computer-readable medium bearing instructions for controlling a computer to automatically generate a computer program from a formal language specification, said instructions being arranged to cause one or more processors upon execution thereby to perform the steps of: accessing a formal language specification written in a formal language which has predetermined precise rules of syntax and semantics such that said specification is guaranteed to be non ambiguous and can be validated to be complete and correct using said rules of syntax and semantics, said formal language specification being created from a Conceptual Model created by a user that specifies requirements for a computer program to be automatically generated, said Conceptual Model including a Presentation Model which specifies through the use of predetermined patterns a desired user interface for said computer program to be automatically generated; validating said formal language specification using said rules of syntax and semantics to ensure said formal specification is complete and correct and unambiguous to generate a validated formal language specification; and automatically generating said computer program in a computer language that can be immediately executed by a computer or compiled into an executable form from said validated formal language specification, and wherein said automatic generation step includes, based upon portions of said formal language specification which define said desired user interface, inserting computer instructions which control a computer executing said computer program to have a desired user interface in accordance with said patterns specified in said Presentation Model.

33. The computer-readable medium according to claim 32, wherein said computer readable medium bears instructions to control a computer to locate all points in said Conceptual Model where an internal error might occur and add instructions to said automatically generated computer program to detect the occurrence of an internal error and notify a user of said computer program of the occurrence of said error, and further bearing instructions to control a computer to anticipate during said process of automatically generating said computer program all points in said generated program where an external error might occur and add instructions to said computer program to detect the occurrence of said external error and notify a user of said computer program of the occurrence of said external error.

34. The computer-readable medium according to claim 32, further bearing instructions for controlling a computer with an editor program to present a graphical user interface which includes tools which an analyst can invoke to build a graphical representation of said Conceptual Model, said Conceptual Model defining classes of objects, attributes of said classes, services and behavior and interactions of said objects, valuation formulas that change the values of variable attributes of said objects upon the occurrence of events, and patterns of a desired user interface for said computer program and instructions to automatically convert said Conceptual Model to said formal language specification written in a formal language.

35. The computer-readable medium according to claim 32 wherein said computer-readable medium further bears instructions for automatically producing documentation for said computer program based on said formal language specification.

36. A computer-readable medium bearing instructions for controlling a computer to present tools for an analyst to specify the requirements for a computer program to be written and to automatically generate said computer program, said instructions being arranged to cause one or more processors upon execution thereby to perform the steps of: controlling a computer with an editor program to present a user interface which provides tools which can be invoked by an analyst to create a graphical representation of a Conceptual Model of a solution to a problem that a computer program to be automatically generated using said Conceptual Model will solve, said Conceptual Model defining classes of objects, and attributes and services for each class as well as relationships between classes, a state transition diagram which defines the permissible state transitions of each object including information that defines the creation and deletion of an object and control condition formulas that control transitions between states, an object interaction diagram that defines how objects communicate with each other, and valuation formulas which define how events change the values of variable attributes of said objects, and information defining patterns of a desired user interface, said editor program controlling said computer to automatically convert said Conceptual Model to a formal language specification written in a formal language with rules of syntax and semantics and to provide notification to said analyst when a mistake of syntax or semantics has occurred in information defining said Conceptual Model entered by said analyst; accessing said formal language specification from a computer readable medium upon which said formal language specification is stored by said editor program; validating said formal language specification to determine that said Conceptual Model is correct meaning that the information entered to define said Conceptual Model is syntactically and semantically consistent according to a grammar of said formal language used to write said specification, and not ambiguous, and complete meaning that there is no missing information required by said Conceptual Model and the rules of syntax or semantics of said formal language such that all properties required by said Conceptual Model are defined and have a valid value; and automatically generating said computer program using said formal language specification so as to implement all the structure and behavior, properties and services and said user interface defined in said Conceptual Model.

37. The computer-readable medium according to claim 36, wherein said computer readable medium further bears instructions to control said computer to impose integrity constraints on said classes and implement derivation expressions for derived attributes of classes.

38. The computer-readable medium of claim 36, wherein said computer readable medium further includes instructions to control a computer to identify the points in said Conceptual Model where an internal error might occur and to add instructions to said automatically generated computer program to control a computer executing said computer program to detect the occurrence of one or more of said error(s) and notify a user of said computer program of the occurrence of said error(s).

39. The computer-readable medium according to claim 38, further bearing instructions for generating instructions for checking and handling external errors.

40. The computer-readable medium according to claim 38, wherein said computer-readable medium further bears instructions for controlling a computer using said editor program to automatically generate said formal language specification in a formal language have strict rules of syntax and semantics.

41. The computer-readable medium according to claim 36 further bearing instructions to control a computer to validate said formal language specification for correctness by verifying that every element of said formal language specification has a set of properties that both exist and have valid values before automatic generation of said computer program but which, for ease of use during reception of data to define said Conceptual Model, allows some properties to have incomplete or invalid values temporarily.

42. The computer-readable medium according to claim 36 further bearing instructions to control a computer to validate said formal language specification for completeness by verifying that all formulas entered in said Conceptual Model are syntactically and semantically correct according to predetermined rules of grammar of said formal languages.

43. A computer-readable medium bearing instructions for controlling a computer to provide tools to define a Conceptual Model of a computer program to be written and to automatically generate said computer program, said instructions being arranged to cause one or more processors upon execution thereby to perform the steps of: using a CASE tool to control a computer to present a graphical user interface mechanism to provide tools a user can invoke to construct a Conceptual Model which defines the structure and behavior of a computer program to be automatically written by a computer, said tools including tools which represent patterns of user interface methodologies which can be specified to define a Presentation Model which defines a desired user interface for said computer program to be automatically written, said CASE tool for automatically converting said Conceptual Model into a formal language specification written in a mathematically based formal language having strict, predefined rules of syntax and semantics which together comprise a grammar and for notifying said user whenever any error of semantics or syntax results from information entered by said user in defining said Conceptual Model; accessing said formal language specification; validating said formal language specification using rules of validation based upon said rules of syntax and semantics of said formal language to ensure said formal language specification is complete and correct and unambiguous so as to generate a validated formal language specification; and automatically generating said computer program in a computer language that can be immediately executed by a computer or compiled into an executable form, said automatic generation step accomplished using said validated formal language specification, and wherein said automatic generation step includes, based upon portions of said formal language specification which define said desired user interface, inserting computer instructions which control a computer executing said computer program to have a desired user interface in accordance with said patterns specified in said Presentation Model.
Description
FIELD OF THE INVENTION

The present invention relates to computer systems and more particularly to an automatic software production system and methodology suitable for stand-alone systems and on the Internet.

BACKGROUND OF THE INVENTION

Software engineering is the application of a systematic and disciplined approach to the development and maintenance of computer programs, applications, and other software systems. Due to the increasing computerization of the world's economy, the need for effective software engineering methodologies is more important than ever.

The traditional software development process involves a number of phases. First, the requirements of the program are specified, typically in the form of a written specification document based on customer needs. Then, a software developer writes source code to implement the requirements, for example, by designing data structures and coding the system logic. Finally, the software developer undergoes an extensive testing and debugging phase in which mistakes and ambiguities in the requirements are identified and errors in the software code are fixed. Having to refine the system requirements is one of the most serious problems that might occur, because any modification to the requirements necessitates a redevelopment of the source code, starting the process all over again. Thus, the testing and debugging phase is the longest phase in the software engineering process and the most difficult to estimate completion times.

For the past forty years, there have been many attempts to improve isolated portions of the software engineering process. For example, the creation of first higher-level languages such as FORTRAN and then of structured programming languages such as ALGOL has helped ease the burden of implementing the system logic. As another example, the introduction of object-oriented methodologies has helped in the design and implementation of the data structures. These improvements in the software engineering process have lessened the mismatch between the problem space, which is the Conceptual Model for the application, and the solution space, which is the actual software code. Nevertheless, some mismatch between the problem space and the solution space remains, which gives rise to an opportunity for programming errors. Because of the programming errors, it is necessary to undergo an extensive testing and debugging phase to isolate and fix the software faults.

Lately, there has been some interest in the use of "requirements analysis" and Computer Aided Software Engineering (CASE) to facilitate the first phase of the software engineering process, which is the identification and specification of the requirements. In particular, these approaches attempt to allow for software engineers to formally specify the requirements and build a prototype to validate and test the requirements. After the requirements are tested, the prototype is discarded and the software engineer develops the complete software application based on the requirements.

One example is known as "OMTROLL", whose objective is to assist software designers by means of an Object Modeling Technique (OMT)-compliant graphical notation to build the formal specification of the system. This specification is based on the TROLL specification language and has to be refined to a complete system specification. In addition, OMTROLL has a CASE support called TrollWorkbench, which provides a prototyping function by generating an independently executable prototype from a graphical conceptual specification. The prototype generated is a C++ program that includes the static/dynamic aspects of the system and uses an Ingress database as a repository of the specification.

OBLOG is another object-oriented approach for software development that falls within the scope of the European ESPRIT project IS-CORE (Information Systems-Correctness and Reusability). The OBLOG semantics is formalized in the context of the theory of categories. OBLOG also employs a CASE tool for introducing the specifications, and enables a developer to build a prototype by supplying rewrite rules to convert the specifications into code for the prototype. The rewrite rules must be written using a specific language provided by OBLOG.

Another approach that focuses more on levels of formalism is the Object System Analysis model (OSA). The aim of OSA is to develop a method that enables system designers to work with different levels of formalism, ranging from informal to mathematically rigorous. In this context, this kind of tunable formalism encourages both theoreticians and practitioners to work with the same model allowing them to explore the difficulties encountered in making model and languages equivalent and resolve these difficulties in the context of OSA for a particular language. OSA also has a CASE support tool called IPOST, which can generate a prototype from an OSA model to validate the requirements.

A different approach has been proposed by SOFL (Structured-Object-based-Formal Language), whose aim is to address the integration of formal methods into established industrial software processes using an integration of formal methods, structured analysis and specifications, and an object-based method. SOFL facilitates the transformation from requirements specifications in a structured style to a design in an object-based style and facilitates the transformation from designs to programs in the appropriate style. In accordance with the previous arguments, the SOFL proposal attempts to overcome the fact that formal methods have not been largely used in industry, by finding mechanisms to link object-oriented methodology and structured techniques with formal methods, e.g. VDM (Vienna Development Method) style semantics for its specification modules. Combining structured and objected-oriented techniques in a single method, however, makes it difficult to clarify the method semantics; thus, effective tool support is necessary for checking consistency.

Still another approach is known as TRADE (Toolkit for Requirements and Design Engineering), whose conceptual framework distinguishes external system interactions from internal components. TRADE contains techniques from structured and object-oriented specification and design methods. A graphical editor called TCM (Toolkit for Conceptual Modeling) is provided to support the TRADE framework.

Although these approaches are of some help for the first phase, i.e. in refining the requirements before the computer application is coded, they do not address the main source for the lack of productivity during later phases of the software engineering process, namely the programming and testing/debugging phases. For example, once the requirements are identified, the software engineer typically discards the prototype generated by most of these approaches and then designs and implements the requirements in a standard programming language such as C++. The newly developed code, due to the mismatch between the problem space and the solution space, will commonly contain coding errors and will need to be extensively tested and debugged.

Even if the prototype is not discarded and used as skeleton for the final application, the software developer must still develop additional code, especially to implement the user interface and error processing. In this case, there still remains the need for testing and debugging the code the programmer has written. The rule-rewriting approach of OBLOG, moreover, fails to address this need, because the difficulties associated with programming are merely shifted one level back, to the development of the rewriting rules in an unfamiliar, proprietary language.

Other approaches include those of Rational and Sterling, but these are not based on a formal language.

Therefore, there exists a long-felt need for improving the software engineering process, especially for reducing the amount of time spent in the programming and testing phases. In addition, a need exists for a way to reducing programming errors during the course of developing a robust software application. Furthermore, there is also a need for facilitating the maintenance of software applications when their requirements have changed.

SUMMARY OF THE INVENTION

These and other needs are addressed by the present invention, in which system requirements are captured (e.g. through a graphical user interface), converted into a formal language specification hereafter all references to formal specification in this summary and the detailed description of the invention are references to this formal language specification), and validated for correctness and completeness. In addition, a translator is provided to automatically generate a complete, robust software application based on the validated formal specification. By generating the application code from the validated formal specification, error-free source code strategies can be employed, freeing the developer from having to manually produce the source code or extend an incomplete prototype. Therefore, the error-prone, manual programming phase of the traditional software engineering process is eliminated, and the testing and debugging time is greatly reduced. In one example, the software development time of an application was reduced to 27% of the original time. Software maintenance is also reduced, because the traditional coding, testing, and revalidation cycles is eliminated.

One aspect of the present invention springs from the insight that ambiguity is a major source of programming errors associated with conventional object-oriented and higher-order programming languages such as C++. Accordingly, an automated software production tool, software, and methodology are provided, in which a graphical user interface is presented to allow a user to input unambiguous formal requirements for the software application. Based on the formal requirements input for the software application, a formal specification for the software application is produced and validated, from which the software application is generated. By generating the software application directly from an unambiguous, validated formal specification, the software developer can avoid the programming errors associated with conventional programming languages, and instead work directly in the problem space. In one embodiment, error-handling instructions are also produced when the software application is generated so as to create a robust, final software application.

Another aspect of the present invention stems from the realization that a major source of inadequacy of conventional prototyping techniques is that these techniques lack the capability to specify the user interface aspects. Thus, such conventional prototypes have primitive user interfaces that are unacceptable for final, customer-ready software application. Accordingly, this aspect of the invention relates to an automated software production tool, software, and methodology that include a formal specification of a Conceptual Model that specifies requirements for a software application. The Conceptual Model includes a Presentation Model that specifies patterns for a user interface of the software application. The formal specification, which also specifies the Presentation Model, is validated; and the software application is then generated based on the validated formal specification. As a result, the generated software application includes instructions for handling the user interface in accordance with the patterns specified in the Presentation Model. In fact, the code generated for the software application is very well suited for deployment on the Internet because the code supports high-volume, transactional, scalable, and reliable system logic functions, and the Presentation Model enables creative designers not to be concerned about details of coding the user interface.

Still other objects and advantages of the present invention will become readily apparent from the following detailed description, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawing and description are to be regarded as illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 depicts a computer system that can be used to implement an embodiment of the present invention.

FIG. 2 is a schematic block diagram illustrating the high-level architecture and data flows of an automatic software production system in accordance with one embodiment of the present invention.

FIG. 3 illustrates an example of an object model for a library system with readers, books, and loans.

FIG. 4A illustrates an exemplary state transition diagram in accordance with one embodiment of the present invention.

FIG. 4B illustrates an exemplary object interaction diagram in accordance with one embodiment of the present invention.

FIG. 5 illustrates an exemplary dialog for receiving input for the functional model.

FIG. 6 is a flow diagram illustrating the high level view of the operation of translating a formal specification into a full application by following what it is referred to as an "Execution Model".

DESCRIPTION OF THE PREFERRED EMBODIMENT

An automatic software production system is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

HARDWARE OVERVIEW

FIG. 1 is a block diagram that illustrates a computer system 100 upon which an embodiment of the invention may be implemented. Computer system 100 includes a bus 102 or other communication mechanism for communicating information, and a processor
104 coupled with bus 102 for processing information. Computer system 100 also includes a main memory 106, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 102 for storing information and instructions to be executed by processor 104. Main memory 106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 104. Computer system 100 further includes a read only memory (ROM) 108 or other static storage device coupled to bus 102 for storing static information and instructions for processor 104. A storage device 110, such as a magnetic disk or optical disk, is provided and coupled to bus 102 for storing information and instructions.

Computer system 100 may be coupled via bus 102 to a display 112, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 114, including alphanumeric and other keys, is coupled to bus 102 for communicating information and command selections to processor 104. Another type of user input device is cursor control 116, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on display 112. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

The invention is related to the use of computer system 100 for automatic software production. According to one embodiment of the invention, automatic software production is provided by computer system 100 in response to processor 104 executing one or more sequences of one or more instructions contained in main memory 106. Such instructions may be read into main memory 106 from another computer-readable medium, such as storage device 110. Execution of the sequences of instructions contained in main memory 106 causes processor 104 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 106. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 104 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 110. Volatile media include dynamic memory, such as main memory 106. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise bus 102. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 104 for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer. The emote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 100 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus 102 can receive the data carried in the infrared signal and place the data on bus 102. Bus 102 carries the data to main memory 106, from which processor 104 retrieves and executes the instructions. The instructions received by main memory 106 may optionally be stored on storage device 110 either before or after execution by processor 104.

Computer system 100 also includes a communication interface 118 coupled to bus 102. Communication interface 118 provides a two-way data communication coupling to a network link 120 that is connected to a local network 122. For example, communication interface 118 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 118 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 118 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 120 typically provides data communication through one or more networks to other data devices. For example, network link 120 may provide a connection through local network 122 to a host computer 124 or to data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn provides data communication services through the worldwide packet data communication network, now commonly referred to as the "Internet" 128. Local network 122 and Internet 128 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the digital data to and from computer system 100, are exemplary forms of carrier waves transporting the information.

Computer system 100 can send messages and receive data, including program code, through the network(s), network link 120, and communication interface 118. In the Internet example, a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118. In accordance with the invention, one such downloaded application provides for automatic software production as described herein. The received code may be executed by processor 104 as it is received, and/or stored in storage device 110, or other non-volatile storage for later execution. In this manner, computer system 100 may obtain application code in the form of a carrier wave.

CONCEPTUAL OVERVIEW

FIG. 2 is a schematic block diagram illustrating the high-level architecture and data flows of an automatic software production system 202 in accordance with one embodiment of the present invention. The automatic software production system 202
is configured to accept requirements 200 as input, and produce a complete, robust application 204 (including both system logic and user-interface code), a database schema 206, and documentation 208. In one implementation, the automatic software production system 202 includes a Computer Aided Software Engineering (CASE) tool 210 front end to allow a user to input the requirements, a validator 220 for validating the input requirements 200, and several translators to convert the validated input requirements 200 into a complete, robust application 204. These translators may include a system logic translator 232, a user-interface. translator 234, a database generator 236, and a documentation generator 238.

During operation of one embodiment, requirements 200 specifying a Conceptual Model for the application are gathered using diagrams and textual interactive dialogs presented by the CASE tool 210. Preferably, the CASE tool 210 employs object-oriented modeling techniques to avoid the complexity typically associated with the use of purely textual formal methods. In one implementation, the Conceptual Model is subdivided into four complementary models: an object model, a dynamic model, a functional model and a Presentation Model. These models are described in greater detail hereinafter. After gathering the requirements 200, the CASE tool 210 stores the input requirements as a formal specification 215 in accordance with a formal specification language for example, the OASIS language, which is an object-oriented language for information systems developed at the Valencia University of Technology in Spain. Using extended grammar defined by the formal language, the validator 220
syntactically and semantically validates the formal specification 215 to be correct and complete. If the formal specification 215 does not pass validation, no application is allowed to be generated; therefore, only correct and complete applications are allowed be generated.

If, on the other hand, the formal specification 215 does indeed pass validation, automatic software production processes, some of wich are referred to as "translators" (system logic and user interface ones), are employed to implement a precise execution model that corresponds to the validated formal specification 215. In particular, translators 232 and 234 produce application source code 204 in a high-order language such as C++, Visual Basic or JAVA for the application's system-logic and user-interface, respectively. In one implementation, a database generator 236 also produces instructions in, for example, a Structure Query Language (SQL) scripting language to create the data model for the application in an industry-standard ANSI-92
SQL Relational Database Management System (RDBMS).

In addition, one implementation also employs a document generator 238 to automatically generate serviceable system documentation from the information introduced in the Conceptual Model.

CASE MODELER

As mentioned herein above, the CASE tool 210 preferably employs object-oriented modeling techniques to avoid the complexity typically associated with the use of purely textual formal methods. Rather, four complementary models, that of the object model, the dynamic model, the functional model and the Presentation Model, are employed to allow a designer to specify the system requirements. In contrast with conventional techniques, however, the CASE tool 210 actually captures a formal specification of the designer's system "on the fly" according to a formal specification language, while the designer is specifying the system with the CASE tool 210.

This feature enables the introduction of well-defined expressions in the specification, which is often lacking in the conventional methodologies. In particular, the CASE tool 210 enforces the restriction that only the information relevant for filling a class definition in the formal specification language can be introduced. The use of a formal specification, input by means of the CASE tool 210, therefore provides the environment to validate and verify the system in the solution space, thereby obtaining a software product that is functionally equivalent to the specification as explained hereinafter. Nevertheless this is always done preserving this external view, which is compliant with the most extended modeling techniques, as stated before. In this way, the arid formalism characteristic of many conventional approaches is hidden from the designer, who is made to feel comfortable using a graphical modeling notation.

With respect to the notation, conceptual modeling in one embodiment employs diagrams that are compliant with the Unified Modeling Language (UML); thus, system designers need not learn another graphical notation in order to model an information system. In accordance with a widely accepted object oriented conceptual modeling principles, the Conceptual Model is subdivided into an object model, a dynamic model, and a functional model. These three models, however, are insufficient by themselves to specify a complete application, because a complete application also requires a user interface. Therefore, the CASE tool 210 also collects information about user-interface patterns, in a fourth model referred to as "Presentation Model", which will be translated into the code for the application. In one embodiment, the CASE tool 210 collects information organized around projects that correspond to different applications. Each project built by the CASE tool 210 can include information about classes, relationships between classes, global transactions, global functions, and views.

Each class contains attributes, services, derivations, constraints, transaction formulas, triggers, display sets, filters, population selection patterns, a state transition diagram and formal interfaces. In addition to the information in these lists, a class can also store a name, alias and a default population selection interface pattern. Extra information is stored as remarks that the designer can input information about why a class does exist in a model.

Each attribute can have the following characteristics: name, formal data type (e.g. constant, variable, derived), data type (real, string . . . ), default value, whether the attribute is an identifier for distinguishing the objects of the class, length, whether the attribute is required when the object is created, Whether the attribute can be assigned a NULL value, and a field to introduce some remarks about why the attribute has been created. Each attribute can also include information about valuations, which are formulas that declare how the object's state is changed by means of events. Valuation formulas are structured in the following parts: a condition (that must be satisfied to apply the effect), an event and an effect of the event to the particular attribute. An attribute may also include user interface patterns belonging to the Presentation Model to be applied in the corresponding services arguments related to the attribute.

Services can be of two types: events and transactions. Events are atomic operations, while transactions are composed of services which can be in turn events or transactions. Every service can have the following characteristics: name, type of service (event or transaction), service alias, remarks and a help message. Events can be of three types: new, destroy, or none of them. Events can also be shared by several classes of the project. Shared events belong to all classes sharing them. Transactions have a formula that expresses the composition of services. In addition to this information, services store a list of arguments whose characteristics are: name, data type, whether nulls are allowed as a valid value, whether the argument represents a set of objects (collection), default value, alias and remarks. Additionally, for each argument, user-interface patterns related to arguments are: introduction pattern, population selection pattern, defined selection pattern and dependency pattern. The class can also store information about derivations, and constraints. Each derivation specifies a list of pairs condition-formula, specifying which formula will be applied under every condition. Each constraint is a well formed formula plus the error message that will be displayed when the constraint was violated. For the dynamic constraints, the formula will be internally translated into a graph which constitutes the guide for its evaluation.

A class can also store triggers. Each trigger may be composed of trigger target specified in terms of self, class or object, trigger condition, triggered action (service plus a list of possible agents) to be activated and a list of default values associated with the arguments of the related service. A class can also have display sets, filters and population selection patterns as user-interface patterns of the Presentation Model affecting the class. Each display set can store elements of visualization (attributes to be displayed to the user). Each filter is composed of a well formed formula and a list of auxiliary variables that are useful to define the formula. The population selection pattern is related to a display set and a filter. Classes also have a State Transition Diagram that is a set of states and transitions between them. Each state transition is related to an action (service plus list of possible agents) that can change the state of the object. Actions may have preconditions and the corresponding error message (to be displayed if the precondition does not hold). Preconditions are formulas that need to be satisfied in order to execute the corresponding action. In case of non-deterministic transitions, determinism is achieved by means of labelling each transition with a control condition. A control condition is a formula that specifies which state transition will take effect. Finally, a class can store a list of interfaces. Each interface stores the list of services that an actor can execute (agents) and the list of attributes that can be observed.

The model also maintains information on relationships between classes, which can be of two types: aggregation ("has a" or "part of") and inheritance ("is a"). Each aggregation relationship indicates composition of objects and captures the information about cardinalities (numbers of minimum and maximum participants in the aggregation relationship, whether the aggregation is static or dynamic, whether the aggregation is inclusive or referential, whether the aggregation has an identification dependence, and a grouping clause when the aggregation is multi-valued. Each inheritance relationship indicates specialization of objects and stores the name of the parent class, the name of the child class and whether the specialization is temporary or permanent. Finally, if the specialization is permanent it stores a well-formed formula on constant attributes as specialization condition. If the specialization is temporary it stores either condition or the list of events that activate/deactivate the child role.

Finally, the project can also capture a list of global transactions in which the relevant characteristics to be stored include the name of the global interaction, the formula, and the list of arguments. A list of global functions can also be captured, in which each function stores a name, a data type of the returned value, a set of arguments (similar to services), and comments about the function.

A project may have a set of views, wich constitute the particular vision that a set of selected agent classes has of the system. That is, the set of formal interfaces (attributes and services) allowed per agent class. Each agent class has a list of interfaces.

OBJECT MODEL

The object model is a graphical model that allows the system designer to specify the entities employed in the application in an object-oriented manner, in particular, by defining classes for the entities. Thus, the class definitions include, for example, attributes, services and class relationships (aggregation and inheritance). Additionally, agent relationships are specified to state that services that objects of a class are allowed to activate.

FIG. 3 illustrates an example of an object model 300 for a library system with readers, books, and loans. Classes, in the object model 300, are represented as rectangles with three areas: the class name, the attributes and the services. In the example, the object model 300 includes a loan class 310 with attributes to indicate a load code 312 and a loan date 314 for when the loan was made. The loan class 300 also includes two services (methods) including one for loaning a book 316 and another for returning the book 318.

The object model 300 also includes a book class 320 having attributes that specify the author 322 of the book, a book code 324, and a state 326 (e.g. reserved, in circulation, checked out, etc.) and services such as new_book 328 for creating a new book. Another class is a librarian class 330, whose name 332 is specified by an attribute and whose creation is done by a new_librarian service 334.

Each reader belonging to the library is described with the reader class 340, whose attributes include the age 342, the number of books 344 checked out by the reader, and the name 346 of the reader. Readers may be created with a new_reader service 348. An unreliable reader class 350 is also part of the object model to indicate for those readers 340 who cannot be trusted (e.g. due to unpaid fees for overdue books). An unreliable reader 350 may be forgiven 352 by a librarian 330.

In an object model 300, inheritance relationships are represented by using arrows to link classes. For example, the unreliable reader class 350 is connected to the reader claim 340 with an arrow; thus, the unreliable reader class 350 is specified to inherit from, or in other terms is a subclass of, the reader claim 340. The arrow linking the subclass and the base class can be leveled with a specialization condition or an event that activates or cancels the child role. In the exemplary object model 300, the arrow between the unreliable reader class 350 and the reader class 340 is labeled with a reader punish/forgive" service. Thus, if a reader 340 is punished, that person becomes an unreliable reader 350. Conversely, if an unreliable reader 350 is forgiven 352, that person becomes a normal reader 340.

Aggregation relationships are represented in the object model 300 by using a line with a diamond from a given component class to its composite class with the diamond on the composite side. The aggregation determines how many components can be attached to a given container and how many containers a component class can be associated with. In the example, a book 320 and a reader 340 are aggregated in a loan 310, because a loan 310 involves lending a book 320 to a reader 340 of the library. The representation of aggregation also includes its cardinalities in both directions (i.e. minimum and maximum numbers), role names, and relationship name. In the example, the cardinality of the loan:book relationship from loan to book is 1:1 because exactly one book is the subject of exactly one loan in this Conceptual Model, and from book to loan is 0:1 because a book may or may not be lent at any moment."

Furthermore, agent relationships are represented by dotted lines that connect the associated client class and services of the server class. In the example, a librarian 330 is an agent of a forgive service 352 of the unreliable reader class 350; thus, there is a dotted line between the forgive service 352 and the librarian class 330. This means that a librarian can forgive unreliable readers. As another example, readers 340 are agents of the loan book 316 and return book 318 services.

Finally, shared events are represented by solid lines that connect the associated events between two classes. In the example, the loan_book event is a shared event due to the solid line connecting said events in the book class 320 and the reader class 340. A shared event affects more than object, in which each object may change its state in accordance with its local specification. In the example, the loan_book event causes the state of the book 320 to be changed to "not available", the number of books of the reader 340 to be incremented, and create an instance of the loan class 310, aggregations of the book 320 and the reader 340. Since the loan_book event creates an instance of loan class 310, it is a "new" event for that aggregated class.

Additional information in the object model is specified to complete the formal description of the class. Specifically, for every class in the object model, the following information is captured as shown in TABLE 1.

TABLE 1 ITEM DESCRIPTION Attributes All the aforementioned properties and/or characteristics Services All the aforementioned properties and/or characteristics Derivations Derivation expressions for the derived attributes (those whose value is dependent on other attributes) Constraints Well-formed formulas stating conditions that objects of a class must satisfy Complex specific information associated with aggregation and Relationships inheritance hierarchies Agents Services that can be activated by this class

Additional information associated with aggregation and inheritance is also collected. For aggregated classes, the additional information can specify if the aggregation is an association or a composition in accordance with the UML characterization, or if the aggregation is static or dynamic. For inheritance hierarchies, the additional information can specify if a specialization produced by the inheritance is permanent or temporal. If the specialization is permanent, then the corresponding conditions on the constant attributes must characterize the specialization relationship. On the other hand, if the specialization is temporary, then the condition based on variable attributes or the events that activate/deactivate the child role must be specified.

Some applications may require a large number of classes to fully specify. In this case, classes may be gathered into clusters. Clusters make it easier for the designer or system analyst to understand the application, one cluster at a time. Thus, clusters help reduce the complexity of the view of the object model.

DYNAMIC MODEL

The system class architecture is specified with the object model. Additional features, however, such as which object life cycles can be considered valid, and which inter-object communication can be established, also have to be input in the system specification. For this purpose, a dynamic model is provided.

The dynamic model specifies the behavior of an object in response to services, triggers and global transactions. In one embodiment, the dynamic model is represented by two diagrams, a state transition diagram and an object interaction diagram.

The state transition diagram (STD) is used to describe correct behavior by establishing valid object life cycles for every class. A valid life refers to an appropriate sequence of states that characterizes the correct behavior of the objects that belong to a specific class. Transitions represent valid changes of state. A transition has an action and, optionally, a control condition or guard. An action is composed of a service plus a subset of its valid agents defined in the Object Model. If all the agents are selected, the transition is labeled with an asterisk (*). Control conditions are well formed formulas defined on object attributes and/or service arguments to avoid the possible non-determinism for a given action. Actions might have one precondition that must be satisfied in order to accept its execution. A circle with an imbedded circle represents the state previous to existence of the object. Transitions that have this state as source must be composed of creation actions. Similarly, a bull's eye represent the state after destruction of the object. Transitions having this state as destination must be composed of destruction actions. Intermediate states are represented by circles labeled with an state name. Accordingly, the state transition diagram shows a graphical representation of the various states of an object and transitions between the states. FIG. 4A illustrates an exemplary state transition diagram 400 in accordance with one embodiment of the present invention. States are depicted in the exemplary state transition diagram 400 by means of a circle labeled with the state name. Referring to FIG. 4A, the "book0" state 404 is indicated by a circle with the name "book0." Before an object comes into existence, a blank circle 402 is used to represent this "state" of nonexistence, which is the source of the initial transition 410 labeled by a corresponding creation action. A bull's eye 406 is used to represent the state after which an object has been destroyed, as by a transition 416 occasioned by the [*]: destroy_book action.

Transitions are represented by solid arrows from a source state to a destination state. The middle of the transition arrow is labeled with a text displaying the action, precondition and guards (if proceeds). In the example, transition 412 is labeled with a loan_book action associated with the transition 412 and a precondition `if state="available". Thus, the system will only accept the execution of the action if the state attribute of the book is "available." In other words, the Conceptual Model requires that a book can only be loaned if the book is available. "As another example, transition 414 is labeled with a return_book action associated with the transition 414" and a precondition `if state="lent"`. In other words, the Conceptual Model requires that a book can only be returned if the book has been lent.

The object interaction diagram specifies inter-object communication. Two basic interactions are defined: triggers, which are object services that are automatically activated when a pre-specified condition is satisfied, and global transactions, which are themselves services involving services of different objects and or other global transactions. There is one state transition diagram for every class, but only one object interaction diagram for the whole Conceptual Model, where the previous interactions will be graphically specified.

In one embodiment, boxes labeled with an underlined name represent class objects. Trigger specifications follow this syntax: destination::action if trigger-condition. The first component of the trigger is the destination, i.e., the object(s) to which the triggered service is addressed. The trigger destination can be the same object where the condition is satisfied (i.e. self), a specific object, or an entire class population if broadcasting the service. Finally, the triggered service and its corresponding triggering relationship are declared. Global Transactions are graphically specified by connecting the actions involved in the declared interaction. These actions are represented as solid lines linking the objects (boxes) that provide them.

Accordingly, communication between objects and activity rules are described in the object interaction diagram, which presents graphical boxes, graphical triggers, and graphical interactions. FIG. 4B illustrates an exemplary object interaction diagram 420 in accordance with one embodiment of the present invention.

In the object interaction diagram 420, the graphical interactions are represented by lines for the components of a graphical interaction. Graphical boxes, such as reader box 422, are declared, in this case, as special boxes that can reference objects (particular or generic) such as a reader. Graphical triggers are depicted using solid lines that have a text displaying the service to execute and the triggering condition. Components of graphical interactions also use solid lines. Each one has a text displaying a number of the interaction, and the action that will be executed. In the example, trigger 424 indicates that the reader punish action is to be invoke when the number of books that a reader is currently borrowing reaches 10.

FUNCTIONAL MODEL

Many conventional systems take a shortcut when providing a functional model, which limits the correctness of a functional specification. Sometimes, the model used breaks the homogeneity of the object-oriented models, as happened with the initial versions of OMT, which proposed using the structured DFDs as a functional model. The use of DFD techniques in an object modeling context has been criticized for being imprecise, mainly because it offers a perspective of the system (the functional perspective), which differs from the other models (the object perspective). Other methods leave the free-specification of the system operations in the hands of the designer, which leads to inconsistencies.

One embodiment of the present invention, however, employs a functional model that is quite different with respect to these conventional approaches. In this functional model, the semantics associated with any change of an object state is captured as a consequence of an event occurrence. To do this, the following information is declaratively specified: how every event changes the object state depending on the arguments of the involved event, and the object's current state. This is called "valuation."

In particular, the functional model employs the concept of the categorization of valuations. Three types of valuations are defined: push-pop, state-independent and discrete-domain based. Each type fixes the pattern of information required to define its functionality.

Push-pop valuations are those whose relevant events increase or decrease the value of the attribute by a given quantity, or reset the attribute to a certain value.

State-independent valuations give a new value to the attribute involved independently of the previous attribute's value.

Discrete-domain valuations give a value to the attributes from a limited domain based on the attribute's previous value. The different values of this domain model the valid situations that are possible for the attribute.

To illustrate these features, TABLE 2 shows a functional model for a "book number" attribute 344 of the reader class 340, in a Conceptual Model representing a typical library.

TABLE 2 CLASS: Reader ATTRIBUTE: book_number CATEGORY: push-pop Event Quantity Effect loan( ) 1 Increase Return( ) 1 Decrease

These valuations are categorized as a push-pop because their relevant events increase or decrease the value of the book_number attribute 344 by a given quantity (1). In the example, its related event loan( ) has the increasing effect and return( ) has the decreasing effect.

This categorization of the valuations is a contribution of one aspect of the present invention that allows a complete formal specification to be generated in an automated way, completely capturing a event's functionality

Accordingly, the functional model is responsible for capturing the semantics of every change of state for the attributes of a class. It has no graphical diagram. Textual information is collected through an interactive dialog that fills the corresponding part of the Information Structures explained before. FIG. 5 illustrates an exemplary dialog for receiving input for the functional model.

PRESENTATION MODEL

The Presentation Model is a set of pre-defined concepts that can be used to describe user interface requisites. These concepts arise from distilling and abstracting repetitive scenarios in developing the user interfaces. These abstractions of the repetitive scenarios are called patterns. A set of patterns is called a pattern language.

In this sense, the Presentation Model is a collection of patterns designed to reflect user interfaces requirements. A pattern is a clear description of a recurrent problem with a recurrent solution in a given restricted domain and giving an initial context. The documented patterns abstract the essence of the problem and the essence of the solution and therefore can be applied several times to resolve problems that match with the initial context and domain. The pattern language is composed of a plurality of patterns. The present invention is not limited to any particular list of patterns, but the following is a brief description of some user interface patterns that have been found to be useful: Service Presentation Pattern, Instance Presentation Pattern, Class Population Presentation Pattern, Master-Detail Presentation Pattern and Action Selection Presentation Pattern.

A Service Presentation Pattern captures how a service will request data to the final user. This patterns controls the filling out of service arguments and contains actions to launch the service or to exit, performing no action. It is based on other lower level patterns that refer to more specific interface tasks such as an introduction pattern, defined selection pattern, population selection pattern, dependency pattern, status recovery pattern, supplementary information pattern, and argument grouping presentation:

The introduction pattern handles with restrictions to input data that must be provided to the system by the final user (i.e., the user who employs the final application). In particular, edit-masks and range-values are introduced, constraining the values that can validly be input in the interface. In this manner, the user-entry errors are reduced. This pattern can be applied to arguments in services or to attributes in classes to improve data input process through validating input arguments.

The defined selection pattern specifies a set of valid values for an argument. When the input data items are static, are a few, and are well known, the designer can declare by enumeration a set containing such valid values. This pattern is similar to those that define an enumerated type and an optional default value. Accordingly, the final user can only select an entry from the pre-specified set, thereby reducing error prone input. For example, one representation of this pattern could be a Combo-Box. This pattern can be applied to arguments in services or to attributes in classes to improve data input process.

The population selection pattern handles the display and selection of objects inform among a multiple objects. Specifically, this pattern contains a filter, a display set, and an order criterion, which respectively determine how objects are filtered (Filter Expression), what data is displayed (Display Set), and how objects are ordered (Order. Criteria). This pattern may be thought of as a SQL Select statement with columns, where for the filter expression and order by for the ordering clauses, and can be applied to object-valuated arguments in services whenever it is possible to select an object from a given population of existing objects.

The dependency pattern is a set of Event-Condition-Action (ECA) rules allowing the specification of dependency rules between arguments in services. When arguments are dependent on others, these constraints use this kind of rules.

The status recovery pattern is an implicitly created pattern that recovers data from object attributes to initialize service arguments. This can be modeled as an implicit set of dependency patterns. For example, to change the data associated of a Customer object, a form to launch the change service appears. If the user provides the Customer OID (Object Identifier), the interfaces can use this OID to search the object and recover the data associated to the Customer, such as name, telephone, address, etc.

The supplementary information pattern handles the feedback that is provided to final users in order to assure they choose or input the correct OID (object identified) for an existent object. For example, to select a Customer, an OID must be provided. If the name of the Customer is automatically displayed as answer to an OID input, the user receives a valuable feedback data that assures the user in selecting or correcting the input data. The supplementary information pattern is applicable to object-valuated arguments.

The argument grouping presentation pattern captures how to group the requested service arguments according to the user wishes.

An Instance Presentation Pattern captures how the properties of an object are presented to the final user. In this context, the user will be able to launch services or to navigate to other related objects. The instance presentation pattern is a detailed view of an instance.

A Class Population Presentation Pattern captures how the properties of multiple objects of one class are presented to the final user. In this context, once an object is selected, the final user will be able to launch a service or to navigate to other related objects. The objects can also be filtered.

A Master-Detail Presentation Pattern captures how to present a certain object of a class with other related objects that may complete the full detail of the object. To build this pattern the following patterns are used: instance presentation, class population presentation and, recursively, master-detail presentation. In this manner, multi-detail (multiple details) and multi-level master-detail (multiple levels recursively) can be modeled. For example, one scenario involves an invoice header followed by a set of invoice lines related to the invoice.

An Action Selection Pattern captures how the services are offered to final users following the principle of gradual approach. This pattern allows, for example, generating menus of application using a tree structure. The final tree structure will be obtained from the set of services specified in the classes of the Conceptual Model. The user could launch services or queries (observations) defined in the Conceptual Model.

A Filter Expression is a well-formed formula that evaluates to a Boolean type. This formula is interpreted as follows: the objects that satisfy the formula pass the filter; the ones that not fulfill the condition do not pass the filter. Consequently, the filter acts like a sift that only allows objects that fulfill the formula to pass. These formulas can contain parameters that are resolved at execution time, providing values for the variables or asking them directly to the final user. A filter pattern may be thought of as an abstraction of a SQL where clause, and is applied in a population selection pattern.

A Display Set is an ordered set of attributes that is shown to reflect the status of an object. A Display Set may be thought of as an abstraction of the columns in a SQL clause, and is applied in a population selection pattern.

The Order Criteria is an ordered set of tuples that contain: an attribute and an order (ascending/descending). This set of tuples fixes an order criterion over the filtered objects. An order criterion pattern may be thought of as an abstraction of an order by SQL clause, and is applied in a population selection pattern.

FORMAL SPECIFICATION

The CASE tool 210, after presenting a user interface for capturing system requirements 200, converts the system requirements into a formal specification 215. In particular the CASE tool 210 builds upon the previously described models as a starting point and automatically generates a corresponding formal and object-oriented specification 215, which acts as a high-level system repository. In a preferred embodiment, the formal language being employed is OASIS, version 2.2 by Oscar Pastor Lopez and Isidro Ramos Salavert, published October 1995 by the "Servicio de Publicaciones de la Universidad Politecnica de Valencia" (legal deposit number: V-25 1285-1995).

Conversion of captured system requirements 200 into a formal specification 215 is a main feature of one aspect of the invention: each piece of information introduced in the conceptual modeling step has a corresponding formal counterpart, which is represented as formal language concept. The graphical modeling environment associated with one embodiment of the invention may be thus viewed as an advanced graphical editor for formal specifications.

Therefore, an introductory presentation of the OASIS specification language is provided herein for a more detailed view of this embodiment of the present invention. TABLE 3 shows a formal specification 215 for the reader class that was automatically obtained from the Conceptual Model:

TABLE 3 CONCEPTUAL SCHEMA library domains nat, bool, int, date, string class reader identification by_reader_code: (reader_code); constant_attributes age : String ; reader_code : String ; name : String ; variable_attributes book_count : Int ; private_events new_reader( ) new; destroy_reader( ) destroy; punish( ); shared_events loan( ) with book; return( ) with book; constraints static book_count < 10; valuation [loan( )] book_count= book_count + 1; [return( )] book_count= book_count - 1; preconditions librarian:destroy_reader ( ) if book_number = 0 ; triggers Self :: punish( ) if book_count = 10; process reader = librarian:new_reader( ) reader0; reader0 = librarian:destroy_reader( ) + loan ( ) reader1; reader1= if book_count=1 return( ) reader0 + (if book_count >1 return( ) + if book_count <10 loan( )) reader1; end_class END CONCEPTUAL SCHEMA

The meaning of the different sections that integrate the formal description of the exemplary reader class specification is explained. A class in OASIS is made up of a class name "reader", an identification function for instances (objects) of the class, and a type or template that all the instances share.

The identification function by_reader_code, characterizes the naming mechanism used by objects and yields a set of surrogates belonging to a predefined sort or to a sort defined by the user (the so-called domains in OASIS). These domains are imported in the class definition. The most usual are predefined as int, nat, real, bool, char, string and date. They represent numbers, boolean values, characters, strings and dates in a particular format. New domains can be introduced in a specification by defining the corresponding abstract data type.

A type is the template that collects all the properties (structure and behavior) which are shared by all the potential objects of the class being considered. Syntactically, the type can be formalized as a signature, which contains sorts, functions, attributes and events to be used, a set of axioms, which are formulas in a dynamic logic, a process query as a set of equations with variables of a sort process that are solved in a given process algebra. When these variables are instantiated, we have the ground terms that represent possible lives of instances (objects).

A class signature contains a set of sorts with a partial order relation. Among this set of sorts is the sort of interest (the class name) associated with the class being defined. A class signature also contains a set of functions including those functions included in the definition of the (predefined) sorts and the identification function whose sort is the ADT (Abstract Data Type) for identities implicitly provided with a class specification. The identification function provides values of a given sort to identify objects in order to assure that any object of a given class has a unique identity. For specification purposes, an identification is introduced mechanism comprising a declaration of one or more key maps used as aliases for identifying objects. The key maps are similar to the candidate key notion of the relational model. From a given key value, these maps return an associated object identity. Key maps will be declared as (tuples of) constant attributes.

A class signature also contains a set of attributes (constant, variable, and derived), see constant_attributes and variable_attributes sections in TABLE 3. These attributes all have the sort of the class as domain, and the given sort associated to the attribute being considered as co-domain.

A set of events is also contained in the class signature (see private events and shared events in TABLE 3), with the sort of the class as the domain, plus any additional sort representing event information, and with the sort of the class (sort of interest) as the co-domain. This so-called sort of interest can be seen as a sub-sort of a general sort process when objects are viewed as processes.

Each event occurrence is labeled by the agent that is allowed to activate it. When dealing with this actor notion, if the agent x initiates event a is written x: a and called an action; x could be the environment or any object of a system class. In one embodiment, an event always is associated with an agent. When defining an event, the designer is therefore forced to state which agent will be able to activate it. Consequently, a set A of actions may be defined and obtained from and attached to the initial set of events.

In this way, the notion of the set of object services can be represented as an interface that allows other objects to access the state. The object services can be events (server view) or actions (client view) depending on whether these services are offered or requested. Actions become services requested by an object, by which the object can consult or modify states of other objects (or its own state).

In OASIS, there are the following kinds of dynamic formulas (set of class axioms):

Evaluations are formulas of the form .phi. [a].phi.' whose semantics is given by defining a .rho. function that, from a ground action a returns a function between possible worlds. In other words, being a possible world for an object any valid state, the .rho. function determines which transitions between object states are valid after the execution of an action a. In the example, there are the following evaluations: [loan( )] book_count=book_count+1; [return( )] book_count=book_count-1;

Within this dynamic logic environment, the formula .phi. is evaluated in s .epsilon. W, and .phi.' is evaluated in .rho.(a), with .rho.(a) being the world represented by the object state after the execution in s of the action considered.

Derivations are formulas of the type .phi..fwdarw..phi.'. They define derived attributes .phi.' in terms of the given derivation condition (stated in .phi.). Derivations basically differ from the evaluation formulas in that this derived evaluation is done in a unique state.

Integrity constraints are formulas that must be satisfied in every world. Static and dynamic integrity constraints may be distinguished. Static integrity constraints are those defined for every possible world. They must always hold. On the other hand, dynamic integrity constraints are those that relate different worlds. They require the use of a temporal logic, with the corresponding temporal logic operators.

Preconditions are formulas with the template {character pullout}.phi.[a]false, where .phi. is a formula that must hold in the world previous to the execution of action a. Only in the worlds where .phi. holds, is a allowed to occur. If {character pullout}.phi. holds, the occurrence of a gives no state as successor. We have the following precondition in the reader specification: book_number=0 [librarian:destroy_reader( )] false;

or, in a more convenient way for specification purposes, we can write librarian:destroy_reader( ) if book_number=0

Triggers are formulas of the form .phi.[{character pullout}a]false, where {character pullout}a is the action negation. This formula means that a does not occur, and what does occur is not specified. If .phi. holds and an action other than a occurs, then there is no successor state. This forces a to occur or the system remains in a blocked state. For instance, using the appropriate dynamic formula where we include in the triggered service information about the destination (according to the trigger expressiveness presented when the object interaction diagram 420 was introduced), we will declare: book_count=10 [Self::punish( )] false

This trigger may be written in an equivalent but more conventional way for specification purposes as: Self::punish( ) if book_count=10;

Thus, triggers are actions activated when the condition stated in .phi. holds. The main difference between preconditions and triggers comes from the fact that in triggers there is an obligation to activate an action as soon as the given condition is satisfied. In this way triggers allow us to introduce internal activity in the Object Society that is being modeled.

In any of these dynamic formulas, .phi., .phi.' are well-formed formulas in a first order logic that usually refer to a given system state characterized by the set of values attached to attributes of objects in the state or world considered.

In OASIS, an object is defined as an observable process. The process specification in a class allows us to specify object dynamics and determines the access relationship between the states of instances. Processes are constructed by using events as atomic actions. However, the designer also has the choice of grouping events in execution units, which are called transactions.

The molecular units that are the transactions have two main properties. First, they follow an all-or-nothing policy with respect to the execution of the involved events: when a failure happens during a transaction execution, the resultant state will be the initial one. Second, they exhibit the non-observability of intermediate states.

We will finish this section introducing the process specification of the reader class in TABLE 4:

TABLE 4 reader = librarian:new_reader ( ) .cndot.reader_0; reader_0 = librarian:destroy_reader ( ) + loan ( ) .cndot.reader_1; reader_1 = if book_count=1 return ( ) .cndot. reader_0 + (if book_count > 1 return ( ) + if book_count <
10 loan( )) .cndot.reader_1;

The execution of processes are represented by terms in a well-defined algebra of processes. Thus, possible object lives can be declared as terms whose elements are transactions and events. Every process can be rewritten to a term in a basic process algebra BPA_.delta..epsilon., with the .cndot.. (sequence) and + (alternative) process operations. This provides an implementation of concurrence based on arbitrary interleaving.

After having presented Conceptual Model and the OASIS formal concepts associated with them in accordance with one embodiment of the present invention, the mappings will now be discussed that generate a textual system representation 215 (that is a specification in OASIS) taking as input the graphical information introduced in the Conceptual Model. This formal specification 215 has in fact been obtained using CASE tool 210, and constitutes a solid system documentation to obtain a final software product which is compliant with the initial requirements, as represented in the source Conceptual Model.

According to the class template introduced in the previous section, the set of conceptual patterns and their corresponding OASIS representation.

The system classes are obtained from the object model. For each class, there are a set of constant, variable or derived attributes; a set of services, including private and shared events and local transactions; integrity constraints specified for the class; and derivation expressions corresponding to the derived attributes. For a complex class (those defined by using the provided aggregation and inheritance class operators), the object model also provides the particular characteristics specified for the corresponding complex aggregated or specialized class.

The information given by the object model basically specifies the system class framework, where the class signature is precisely declared. The dynamic model uses two kind of diagrams, the state transition diagram and the object interaction diagram. From the state transition diagram, the following are obtained: event preconditions, which are those formulas labeling the event transitions; the process definition of a class, where the template for valid object lives is fixed. From the object interaction diagram, two other features of an OASIS class specification are completed: trigger relationships and global transactions, which are those involving different objects.

Finally, the functional model yields the dynamic formulas related to evaluations, where the effect of events on attributes is specified.

Having thus clearly defined the set of relevant information that can be introduced in a Conceptual Model in accordance with an embodiment of the present invention, the formal specification 215 corresponding to the requirements 200 provides a precise system repository where the system description is completely captured, according to the OASIS object-oriented model. This enables the implementation process (execution model) to be undertaken from a well-defined starting point, where the pieces of information involved are meaningful because they come from a finite catalogue of conceptual modeling patterns, which, furthermore, have a formal counterpart in OASIS.

MODEL VALIDATION

Automatic software production of a complete, robust application from a Conceptual Model to an implementation language (such as a third generation languages like C, C++, or Java) requires the Conceptual Model to be both correct and complete. In this section, the terms "correct" and "complete" have the following meanings dependent on the specific needs for the automated software production process system as:

A Conceptual Model is "complete" when there is no missing information in the requirements specification. In other words, all the required properties of the Conceptual Model are defined and have a value.

A Conceptual Model is "correct" when the information introduced in the Conceptual Model is syntactically and semantically consistent and not ambiguous. In other words, all the properties defined in the Conceptual Model have a valid value.

Referring back to FIG. 2, the validator 220 receives as input the formal specification 215 of the Conceptual Model using an Object-Oriented Formal Specification Language (such as OASIS) as high level data repository. From a formal point of view, a validated OASIS specification 215 is correct and complete because the specification 215 is formally equivalent to a dynamic logic theory, using a well-defined declarative and operational semantics.

Formal specification languages benefit from the ability of formal environments to ensure that formal specifications 215 are valid or can be checked to be valid. Formal languages define a grammar that rules language expressiveness.

Two procedures are used for Conceptual Model validation. For completeness, validation rules are implemented by directly checking the gathered data for the Conceptual Model, e.g., a class must have name, one attribute being its identifier and one service. For correctness, an extended formal specification language grammar is implemented in order to validate the syntax and meaning of all the formulas in the Conceptual Model.

CORRECTNESS

More specifically, for completeness, all the elements in a formal specification language have a set of properties that both have to exist and must have a valid value. Most of the properties are strictly implemented to have a full definition and valid values. However, the CASE tool 210 allows, for easy of use during a model inputting, to leave some properties incomplete or with invalid values. These properties will be checked by the validator 220 to be complete (and correct) prior to any automatic software production process.

The elements which are used to validate a Conceptual Model are described next. For each element it is stated if validation will be strict (e.g. when all his properties have to exist and must have a valid value at creation time) or flexible (e.g. validation will be accomplished at a later time). Some properties are optional, (e.g. that may not exist) but if they are defined, they must be validated. These elements are given in TABLE 5:

TABLE 5 Class .largecircle. Name. Strict .largecircle. ID function Flexible .largecircle. Attributes (at least one) Flexible .largecircle. Services (at least Create service). Flexible .largecircle. Static and Dynamic Integrity Constraints (optional) .box-solid. Their formula Strict Attribute .largecircle. Name. Strict .largecircle. Type (Constant, Variable, Derived). Strict .largecircle. Data-type (Real, integer, etc). Strict .largecircle. Default Value. Strict .largecircle. Size(if proceeds) Strict .largecircle. Request in Creation service. Strict .largecircle. Null value allowed. Strict .largecircle. Evaluations (variable attributes). Flexible .largecircle. Derivation formula (derived attributes). Flexible Evaluation .largecircle. One variable attribute of a class Strict .largecircle. One service of the same class Strict .largecircle. Condition (optional). Strict .largecircle. Formula of evaluation. Strict Derivation .largecircle. Formula. Strict .largecircle. Condition (optional). Strict Service .largecircle. Name. Strict .largecircle. Arguments. .box-solid. argument's name Strict .box-solid. data-type Strict .box-solid. default value (optional) Strict .box-solid. null value Strict .box-solid. size (if proceeds) Strict .largecircle. For a transaction, its formula. Flexible Preconditions of an action .largecircle. Formula. Strict .box-solid. Agents affected by condition Strict Relationship: Aggregation .largecircle. Related classes (component & composite) Strict .largecircle. Relationship name. Strict .largecircle. Both directions Role names. Strict .largecircle. Cardinality. Strict .largecircle. Inclusive or referential. Strict .largecircle. Dynamic. Strict .largecircle. Clause "Group By" (Optional). Strict .largecircle. Insertion and deletion events (if proceed) Strict Relationship: Inheritance .largecircle. Related classes (parent & child) Strict .largecircle. Temporal (versus permanent) Strict .largecircle. Specialization condition or events Strict Relationship: Agent .largecircle. Agent class and service allowed to activate. Strict State Transition Diagram (STD) .largecircle. All states of class (3 at least). Flexible State in STD .largecircle. Name. Strict Transition in STD .largecircle. Estate of origin. Strict .largecircle. Estate of destination. Strict .largecircle. Service of class. Strict .box-solid. Control condition (optional). Strict Trigger .largecircle. Condition. Strict .largecircle. Class or instance of destination. Strict .largecircle. Target (self, object, class) Strict .largecircle. Activated service. Strict .largecircle. Service arguments' initialization (Optional) .box-solid. Arguments' values Strict Global Interactions .largecircle. Name. Strict .largecircle. Formula. Strict User exit functions .largecircle. Name. Strict .largecircle. Return data-type Strict .largecircle. Arguments, (Optional) .box-solid. Argument's name Strict .box-solid. Argument's data-type Strict

COMPLETENESS

Some properties of components in formal specification languages are "well formed formulas" that follow a well-defined syntax. It is therefore, a requirement to ensure that all introduced formulas in the Conceptual Model were both syntactical and semantically correct.

Not all formulas used in the Conceptual Model have the same purpose. Therefore, there will be several types of formulas. Depending of formula's type, the use of certain operators and terms (operands, like: constants, class attributes, user-functions, etc.) are allowed. A process and a set of rules in grammar to validate every type of formula in the Conceptual Model also exist.

More specifically, the Conceptual Model includes formulas of the following types as shown in TABLE 6:

TABLE 6 Default Value Calculation of .largecircle. Class Attributes (Constant and Variable) .largecircle. Service and Transaction Arguments Inheritance: Specialization condition Static and Dynamic Integrity Constraints Derivations and Valuations: .largecircle. Calculation formula (Derived or Variable attributes respectively) .largecircle. Conditions (optional) Preconditions for actions (Services or Transactions) Control Conditions for transitions in State Transitions Diagram Triggering conditions Local and Global Transactions formulas

These formulas are validated at the time they are introduced, by preventing the designer from leaving an interactive textual dialog if formula is not syntactically and semantically correct.

In general, every formula must be syntactically correct; every class must have an identification function; every class must have a creation event; every triggering formula must be semantically correct (e.g. self triggers to an unrelated class are forbidden); and every name of an aggregation must be unique in the conceptual schema. If these conditions are not satisfied, then an error is raised.

A warning may be raised, on the other hand, if any of the following do not hold: every class should have a destroy event; every derived attribute should have at least a derivation formula; every service should have an agent declared to execute it; and every argument declared in a service should be used.

Validation process will also be invoked every time the designer performs a change into the model that may invalidate one or more formulas. As mentioned earlier, for ease of use, certain type of formulas are allowed to be incorrect, which the designer will have to review at a later time. The automatic software production process in accordance with one embodiment of the present invention, however, will not continue to code generation, if not all the formulas are correct. Each time the designer introduces a modification in the Conceptual Model specification, all affected formulas will be checked. As a result, the following cases may happen:

1. If any of the affected formulas makes reference to a "Strict" property, the change will be rejected. An error will be raised to inform the designer.

2. If none of the affected formulas reference a "Strict" property, a modification to the Conceptual Model will be accepted. An action-confirmation dialog is displayed before any action is taken.

3. If there is no affected formula, modification is performed straightawa