SYSTEM DEVELOPMENT SUPPORT

Abstract: The method and system of this invention assist a user (16) in the achievement of a task according to a set of procedures such as those used in the development of software products. A process description of the software being developed is instantiated by the system whereupon a support system (8) provides the user (16) with a series of choices relating to the software development. The choices selected, in turn, permit a variety of system tools (22), each operating in parallel and concurrently, to be used in the development of the software. The system automatically monitors and checks the process during any manipulation and provides error analysis as well as suggested courses of action to the user (16). The system provides flexible support without requiring the user (16) to follow a rigid development pattern.

Description: SYSTEM DEVELOPMENT SUPPORT BACKGROUND OF THE INVENTION Field of the Invention The present invention relates to a system which assists in the development of software products according to a described set of procedures, and more particularly, to an interactive support medium which automatically monitors, records, invokes and suggests past, present and future actions according to a set of procedures such as those found in many methods related to computer program design. Description of Related Art For years computer software developers and programmers have desired and sought after tools which ease the burdens associated with the creation of complex computer programs. Software development of the distant, and not so distant, past has required the programmer's specific attention to every detail associated with the program's progression and all the documents, descriptions and the like associated therewith. A computer software system was built, tested, the components revised and the system rebuilt until the programmer created the desired product. Aε software systems have grown in size and complexity, the number of programmers required for the design of a single system has also grown dramatically. Consequently, it is now quite common that different individual programmers will design separate elements of an overall software system in which each is required to interact and work together in the final product. Clearly, problems of consistency and uniformity arise in such projects. If, for example, one programmer modifies his or her section of the program, ramifications are experienced in other parts of the program which should be brought to the attention of the designers working on those parts. Thus, there exists a need for development support systems which track and assist software developers during the creation of complex computer programs. One solution is shown, in U.S. Patent No. 4,860,204 to Gendron et al. , wherein a workstation employs methods to construct computer programs through the use of visual graphical representations. The computer based workstation of Gendron allows the user to create a computer program by connecting graphical programming blocks together and thereby create the desired functional result. While the Gendron system performs integrity checks on the interconnections chosen, the system does not provide or automatically present suggestions to the user regarding the courses of action available and the consequences of the actions taken by the user. Similarly, in U.S. Patent No. 4,734,854 to Afshar, there is taught a system for designing generic program modules which perform commonly needed computing functions. The user may then integrate the generic module into a specific or concrete software unit and the Afshar system automatically generates a concrete version of the generic module to fit into the specific software unit. This system, while having some automated features, does not inform the user which generic system or tool is required during the development, nor does it suggest alternative avenues of implementation to the user. Recently, however, Computer-Aided Software Engineering ("CASE") environments have become not only helpful but, in many instances, essential for complex software projects; just as Computer-Aided Design ("CAD") systems have become essential for complex hardware projects. "Software engineering environment" generally refers to an operating system environment and a collection of tools or subroutines which function within the realm of conditions generated by the developing computer program. For example, U.S. Patent No. 4,809,170 to Leblang et al. , teaches a support system for computer aided software engineering applications. The support system of Leblang monitors changes made in the developing system and records such changes for future retrieval. In addition, the system notifies concurrent users of the system of any such changes. However, Leblang does not teach a support system that automatically invokes various program construction tools and interactively forwards suggestions to the user. The early software engineering environment systems as well as the theories and objectives of software development support are described in general terms in the following articles: Griffiths, et al. , "ALF: Its Process Model and its Implementation on PCTE," ESPRIT ALF Project, Technical Paper 1989. Kaiser, et al. "Intelligent Assistance for Software Development and Maintenance," IEEE Software, 1988. Clemm, "Replacing Version-Control with Job- Control," Association for Computing Machinery, 1989. In addition, CASE systems assist users in ways other than code generation. For example, tasks undertaken by software developers which modify a particular aspect of the program not only affect program module elements but other non-code elements of the program as well. Adding an enhancement to the program may also demand updating the program's design specification, user manual, and on-line "help" files. Some steps may involve off-line activities such as communicating the change to others working on the program or using the program, constructing floppy disks for the updated program and transmitting the new disks to programmers and users. The software development process involves much more than just programming, and a practical software development environment should support more than just programming. Industrial computer program development today begins with describing the methods and procedures by which the particular software should evolve. The description contains numerous standards as well as complex processes requiring a multitude of steps to complete. Previous software support systems comprised "toolboxes" which contained several tools for the accomplishment of a specific task. Tools utilized within these support systems included editors, compilers, flow chart editors, etc. The programmer was responsible for choosing the correct tool and for ensuring consistency among various program elements. Other software support systems have included process programming techniques which describe a process in terms of software. Process programming implements software processes as software. This approach describes as much as possible of the software process by means of a formal language, and the process description is interpreted by the computer which can then guide the user in how to execute a specific task. Prior art process programming techniques, while arguably operating as software development assistance means, do not provide the user with flexible assistance. Instead, prior process programming forces the user to proceed through a variety of different steps in the development process. Users, however, reluctantly accept the forced regiment imposed by the process programming technique. To be truly effective in the software development process, a more flexible support system is required, including one that monitors the actions taken by the user, allows the user to proceed in several directions consistent with the underlying development process, interprets the actions of the user and gives support for the activities performed. Thus, there exists a need in the art for an interactive process programming support system which assists software programmers and engineers in a flexible way in the development of complex computer programs. SUMMARY OF THE INVENTION In one embodiment, the present invention includes a method of providing interactive support for the development of a software product according to a specified software process. The method comprises the first step of defining a software process in a specific language which relates the set of steps used in the development of a software product. The description created must then be converted into a form executable by an interpreter. During the interpretation the method generates a menu of choices in which each of the choices constitutes a suggestion regarding possible actions relevant to the specified software process. The user selects one of the choices; whereupon, one of a group of system tools may be initiated and a tool operation performed. The user can also initiate tool operations directly. The results of any operation performed via the tool are tracked to see if it is relevant to the process. An analysis of the results is made, and as an effect, other system tools or other tool operations may be automatically initiated. Subsequently, the user is provided with feedback which covers the current status of the development in light of the prior steps taken. The method of the present invention includes consistency checks which are specified in a formal process description. These consistency checks can occur after each usage of the system tools and reports of errors discovered during the consistency checks are created. An additional element of the aforementioned method permits browsing through objects within a data base associated with the development. Searching for specific objects within the data base may occur as may initiation of any of the available system tools from the browser. In another aspect, the invention is a computer system which provides interactive support during a development phase according to a specified software process. The interactive support system includes a means for specifying and storing a formal process description. Further provided within the system is a means for the transformation of the functional process description into an interpretable form. The interpreter includes an expert system as well as a data base that is electronically accessible to the logic interpreter. A message handler which is electronically linked to the logic interpreter handles the communication with a group of system tools which are configured to perform specific tasks related to the described process. Finally a user interface graphically communicates with the user of the system and allows user input as well. BRIEF DESCRIPTION OF THE DRAWINGS The invention may be better understood and its numerous objects, features and advantages become apparent to those skilled in the art by referencing the accompanying drawings in which: FIG. 1 is a block diagram illustrating the steps needed to define a formal specification of a process; FIG. 2 is a block diagram illustrating the steps required to make a formal specification executable; FIG. 3 is a block diagram illustrating the primary components of an expert system as may be employed in the present invention; FIG. 4 is a block diagram illustrating the primary components of the support system of the present invention; FIG. 5 is a flow diagram wherein the steps preformed in the "eractive support of the process are illustrated in ε ential order; FIG. 6 is a flow diagram of the browser feature of the present invention; FIG. 7 is a flow diagram illustrating the initiation and operation of the tool functions; FIG. 8 shows the elements comprising an activity utilized in accordance with the teachings of the present invention; FIGS. 9A-9C are flow diagrams of different parts of the method of processing data in accordance with the teachings of the present invention; FIG. 10 is a flow diagram further illustrating the method of processing data in accordance with the teachings of the present invention; FIG. 11 is a flow diagram further illustrating the usage of graphical symbols within the method of processing data in accordance with the teachings of the present invention; FIG. 12 is a flow diagram illustrating a method of data retrieval utilizing the teachings of the present invention; FIG. 13 is a flow diagram further illustrating the method of processing data, and in particular, teaches execution of an activity pursuant to the principles of the present invention; FIG. 14 is a flow diagram further illustrating, in diagrammatic form, execution of an activity not supported by a tool in accordance with the teachings of the present invention; and FIG. 15 is a flow diagram illustrating completion of the data processing subprocess. DETAILED DESCRIPTION OF THE INVENTION Everything a user of a support system is doing can be related to the accomplishment of a goal, for example, to create a new εoftware product. Hereinafter the term "process" is used to describe the steps needed to accomplish such goals, including the order in which such steps occur and the like. Procesεeε are a natural way to structure the work of a designer. The description of a process, therefore, must be the result of a careful analysis by experts of how a des.igner should proceed in an optimal way in order to achieve the intended goal. To describe a procesε formally in the present invention, a special language called PDL (Process Description Language) is used. In order to assist a designer in the work defined by the process, the PDL description must be executable, otherwiεe it would only be a description comparable to a textual description. By executing the description, the user of the system receives guidance through all of the steps required to reach the desired goal. It should be understood that the present invention comprises two distinct elements. First, the process element, and second, the support system element. Prior to receiving assistance the process to be supported must be described formally, using PDL as described above. This process . escription is then input (in modified form) to a process description interpreter, whereby the support system can provide assistance in the achievement of the process goals. Thus, FIG. 1 illustrates the initial steps of process definition. The process requirements are analyzed in block 300 and an informal model of the process is then created in block 302 (as for example, a textual description) . In blocks 300 and 302 we have an informal indication of what results should be produced and which different steps need to be taken in the process. Next, a PDL process specification is created in block 304, while the information model of the process, such as data schemes, are fabricated in block 306. The PDL specification is made by system designers responsible for the support system and who specialize in developing processes tailor-made to the needs of a specific company and/or for a specific purpose, e.g., feature design, fault reports, etc. (although an ordinary user could in principle also design a procesε description) . The PDL description, for example, containε a number of baεic features. First, it describes the breakdown of a process into separate subprocesses, each εubproceεε describing tasks that can be performed in parallel with tasks described by other subprocesses so as to increase productivity. This cloεely matcheε the situation a designer faces using a modern workstation, where a number of computer tools can be executed in parallel. Each of the tools would then be described by some procesε in PDL, the subproceεε describing what should be achieved by using the tool and how the tool interacts with the other subprocesseε or toolε. Second, it describes how the tasks described by different subprocesses interact by specifying events that are communicated asynchronously between the processes. Third, the PDL description describes conditions for the start and finish of a specific subprocess. Fourth, it describes the different steps and activities comprising a subprocess, e.g., edit, compile, link, test, and for each of the activities the conditions that need to be fulfilled in order to start that step or activity. Finally, the PDL description illustrates the interaction with the user by dictating how to present information about the state of the process and which possible stepε are appropriate to be executed at the preεent state of the process. In order for the user to make his or her own choices and to avoid the support system being perceived as a hinderance by restricting the uεer to a certain sequence of activities, three properties of the PDL description are essential. First, only the state of the process determines what can be done; this assures that the order in which activities are performed are of minimal importance. Second, the PDL description asεures flexibility by presenting the user with a number of suggestions relevant to the current state of -li¬ the process, any of which the user is free to chooεe. Thus, the support system does not force the user to follow a certain choice of actions. Third, the user can perform activities directly, without using the choices presented by the present invention. Theεe three properties of the PDL description will ensure that the different taskε which the designer haε to do can be handled in a way that is not perceived as too rigid. Referring now to FIG. 2 there iε εhown the εteps needed to be taken in order to execute the PDL description of the procesε defined in FIG. 1 and thuε give aεεiεtance for some particular process. First, in block 350, the PDL description of the process is created. Thiε deεcription iε then analyzed and converted in block 352 to the appropriate format for the assistant logic interpreter. Once properly formatted the description is loaded into the assiεtant logic interpreter 44 (see FIG. 4) at block 354 so that the system can provide the necessary support for the user. These stepε are taken by a system programmer in order to prepare the support εyεtem to give the assistance expresεed in the PDL description. Thus, this readies the second aspect of the invention, i.e., the assistance element. When the user decides to work with tasks described by a certain procesε, the assistant logic interpreter 44 startε to interpret the converted format of the PDL deεcription, thereby giving aεsistance to the designer trying to accompliεh hiε taεk. Thuε, another name for a PDL description is "asεistant logic," since PDL describes the logic of the asεiεtant, i.e., how it works. During execution of the assistant logic, a number of "shadow" objectε are created in the aεεiεtant. Theεe shadow objects repreεent the "real" objects, fileε, descriptions, etc. which the designer iε creating and working with as a part of his task. These shadow objects are used in the asεistant logic to keep track of the statuε of each of the real objectε with reεpect to the process describing the work. By keeping track of the state of the objects, conditions can be checked in order to see if new actions are appropriate and in that case εuggeεt them to the user. These shadow objects are part of the information model described in FIG. 1. Now referring to FIG. 3, there is shown a block diagram illustrating the primary components of an expert system, similar to the expert system 20 of the present invention. The typical expert system relies upon a corpus of knowledge that accumulates during the creation of the system itself. This corpus of knowledge resides within the knowledge base 30 of the expert system 20. Information stored within the knowledge base 30 may be broken down into categorical units and discrete sectionε of the knowledge base 30. This aspect is shown through the #1KB and the #2KB contained in the knowledge base 30. The knowledge required for proper operation of the support εystem 8 muεt be explicit and acceεεible to the expert εyεtem 20. The general problem εolving element of the expert εyεtem 20 comprises the inference engine 32. The inference engine 32 invokes rules εtored within the rule baεe 34. The inference engine 32 determineε how the ruleε contained within the rule baεe 34 apply to the problem at hand and the order in which theεe ruleε εhould be executed. Many of the ruleε in the expert εystem 20 take the form of heuriεticε which conεist of simplified appr acheε to the εearch for a εolution. In operation, the inference engine 32 εcans data in the data baεe 36, matching data with the criteria from the rule baεe 34. In turn, the heuristic approach relating to the rule base 34 generates information for the knowledge base 30. Initially, the rules employed in the process originate from an expert 38, with no specific order being required for the rules. Further, the information in the knowledge base 30 undergoes real time updating during the operation of the expert syεtem 20. Alternatively, operation of the expert εystem 20 may proceed by utilizing the induction engine 40 to formulate rules for the rule base 34. The induction engine 40 operates by deriving general principleε applicable to the proceεε from particular information found within the knowledge base 30. The expert 38 can either provide ruleε directly or give exampleε which can be converted to rules by the induction engine 40. Referring next to FIG. 4, there is shown a block diagram of the support syεtem illuεtrating the component partε thereof in accordance with the teachingε of the present invention. Being a computer based εyεtem, εo aε to provide the advantageε thereof, the preferred embodiment of the preεent invention resides in a computer 41 which is adapted to execute pre-establiεhed sequences of logic statements (i.e., programs and/or firmware) and to read from and write to memory. Central to the operation of the εupport εyεtem 8 is the asεiεtant 12. The asεiεtant 12 comprises the asεistant logic module 42 and the asεiεtant logic interpreter 44. The assistant logic module 42 consists of a converted PDL description as described above, which defines the procesε and repreεentε the goal to be achieved. The asεiεtant logic interpreter 44 houses the expert system 20. In one preferred embodiment, the expert εyεtem iε programmed in ProKappa language aε deεigned by Intellecorp, Inc. , 1975 El Camino Real West, Mountain View, California. The present invention adds graphics to the supplied ProTalk language for increased operational simplicity. The assiεtant 12, and εpecifically the assiεtant logic interpreter 44, communicate through the mesεage handler 46 with tools in the support syεtem, including but not limited to, compilerε and editors. The tool and the tool functions are the baεic building blockε in termε of which the process is expressed, and the way through which the process is implemented in the support syεtem. In thiε way moεt of the proceεs specific knowledge can be allocated to the PDL description instead of in the tools. Therefore the different tools are easier to reuse in other proceεεes, and the tools do not have to be changed when the process is modified. Also connected to the assistant 12 is the data base 36. The data base 36 both storeε information generated or processed by the support system 8 in general as well as provides access for the asεiεtant logic interpreter 44 and the aεεiεtant logic 42 to previouεly stored procesε information. In order to increaεe productivity when uεing the εupport εyεtem 8, each of the toolε 22 operate in parallel with each of the other toolε 22 (in different UNIX processes if implemented on a UNIX platform) . Each tool interacts with the asεiεtant 12 by exchanging meεεageε regarding the current εtatuε of actions being taken by that tool. Thus, many concurrent activities occur within the support system 8, and each of these concurrent activities iε monitored and analyzed by the assistant 12. Still referring to FIG. 4, there is alεo illustrated the user interface/activity window 48 of the aεsistant. The uεer interface 48 communicateε to the uεer 16 the εtatus of the process and provides the user with guidance in performing the activitieε defined by the proceεε. The uεer interface comprises the only element of the assistant 12 apparent to the user 16. The expert system 20 in the asεistant analyzeε the actionε of the user 16 (through messages received from the tools or choices made in the aεsistant user interface) in the context of the current procesε and generateε the proper graphical information for the particular situation. Within the user interface 48 communications of information iε poεεible using a number of different representations. The information displayed, for example, may take the form of lists, or could take the form of graphical representations as well as flow charts. The numerous interfaces available are illustrated by means of the block 50 representing a first alternative interface and the block 52, representing a second alternative interface. The uεer haε the choice as to which mode of interface is most appropriate with his or her skills and the task at hand. Referring now to FIG. 5, there iε shown a more detailed flow chart describing the way in which the asεiεtant workε in run time, when the assistant logic interpreter 44 is loaded with the procesε description, as described above. From the flow chart it is apparent that the aεεistant 12 depends on a number of factors regarding the tools 22 that are part of the support system 8. First, the asεiεtant 12 muεt be able to εtart the toolε 22 and to invoke tool functions. This iε done through a meεεage handler 46 that takeε care of communication. Alεo, the tools must report different events taking place, since most of the tool events have relevance to the state of the procesε and the achievement of the deεign goal, such as modifying a file, creating an interface deεcription, or compiling a program. Which eventε a tool εhould report iε decided when the procesε deεcription describing the task is designed. Since a tool can communicate with the asεistant 12 no matter where it was started (from the asεiεtant activity window, from a databaεe browser, or from a Unix shell) , the system 8 allows the user 16 to start tools by other means than the activity windows 48-52 handled by the assiεtant. The user can also execute different tool functionε directly from the toolε that are not necessarily shown as suggestions in the activity windows. Therefore, the asεistant 12 and the asεistant logic 42 must be able to handle eventε originating from different toolε at any time. Thiε iε poεεible since the PDL description, which describes what to do when an event occurs, only refers to the current state of the procesε, not to the order in which eventε have occurred (thiε is possible using the triggering mechanisms of the underlying expert system) . Any event, therefore, is interpreted in terms of the state of the procesε, regardleεε of if it waε related to a εuggeεtion from the aεεistant 12 or not. Still referring to FIG. 5, a detailed explanation of the flow εhown there followε. Beginning with block 60, the uεer 16 selects the task that he or she should perform. For example, the task could be the design of a new εoftware product, or taking care of an error report. In block 61, the assiεtant 12 εelectε the appropriate PDL deεcription of the particular taεk (thiε is done internally and automatically within the assistant) . This description has previouεly been analyzed and converted aε described in FIG. 2. Proceeding on to block 62, the current εtate of the proceεε deεcribing the taεk is loaded into the asεistant 12 from the database 36. Thiε loading iε moεt relevant when the user 16 has previously worked on the task and saved the status of the prior work. In block 63 the assistant 12 makes suggestions on the actions to be taken based upon the current state of the process. The manner in which the suggestionε are εhown dependε upon the user interface employed as deεcribed above. Block 65 deεcribes the assistant waiting for events occurring in the support syεtem 8. The branch to block 66 indicateε that a tool reports the result of a function invocation as an event to the assistant 12. In response to the event generated in block 66, block 67 changes the state of the process, since it is derived from the events taking place in the εupport εyεtem. If the user 16 had made a εelection of one of the assistant's suggestions from within the activity window, block 68 would be active. If the branch from block 68 to block 69 is followed, and the suggeεtion selected rom within the activity window involves executing . tool function, the tool 22 is started (if needed) and the proper function called via the mesεage handler 46. Proceeding on to block 70, the εtate of the process is changed, reflecting the invocation of the tool function. If, however, the εuggestion selected by the user 16 does not involve invoking a tool function, the internal state of the procesε iε changed through the mere selection made by the user 16. In thir case, the user 16 usually indicates that some manual activity has been performed in the proceεs. After the state change has been effected, in block 72 the assiεtant 12 deduces the effects of the change. Aε a reεult of the analysis conducted in block 72 the asεistant may then automatically invoke other tools in block 73. Further, as a result of the analysiε in block 72 a consistency check between different information elements may automatically be precipitated in block 74 and the errorε found therein would then be reported in block 75. Additionally, the assistant 12 may, as a result of the analysiε of block 72, deem automatic tool invocation unneceεεary and, instead, generate a new εet of suggestions for the user 16. The new εet of suggeεtionε are baεed upon the new procesε state created, whereupon the cycle is repeated. If, however, the user 16 wishes to quit that occurs in block 77 and the state of the process iε saved in block 78. Referring next to FIG. 6, there is illustrated the browser server 90 aspect of the preεent invention which comprises an independent element of the support syεtem 8. The browεer server 90 allows the user 16 to look for objects in the system data base 36 and to select thoεe objectε without direction from the assistant 12. The browser server 90 does not provide suggestionε to the uεer 16. Found objects such aε deεcriptionε, flow chartε, programs, etc. may be examined through the browser server 90, and tool operations on the object can be initiated. Still referring to FIG. 6, the browser server 90 begins with the start browser block 92. Upon commencement of the browser server 90, the uεer 16, at block 93 and 94, can εearch for and select an object in the syεtem data baεe 36. When the object is selected a menu can be displayed, at block 95, of available operationε for the object. The block 96 εtartε the tool 22 and thiε fact iε reported to the assistant 12 in block 98. This permits the assistant view of the syεtem to be consistent, in terms of knowing what events are taking place. Thus, the user 16 may interact with the support system 8 in a variety of ways, one of which being through the browser server 90, and still getting support from the assiεtant. Referring next to FIG. 7, there iε εhown a flow diagram of tool function invocation. Since the uεer 16 can initiate the tools 22 without help from the assistant 1 the user 16 can also execute different tool functι«_..s that are not necessarily shown as suggeεtions in the activity window handled by the assistant 12 (aε deεcribed above in the browser aspect) . Thuε, the aεεiεtant 12 and the assiεtant logic 42 muεt be able to handle eventε originating from various tools at any given time. This is posεible because the PDL description, which describes what to do when an event occurs, refers only to the current εtate of the process, not to the order in which activities have been performed as mentioned above. Any event, therefore, iε interpreted in ter ε of the state of the procesε regardleεε of whether or not the aεεistant forwarded it in terms of a suggeεtion. Conεequently, for a tool deεigner to conform to the requirementε imposed by the asεiεtant 12, the tool muεt function in the following manner. Firεt, the tool function iε started at block 370, and this fact iε reported to the aεεiεtant. After the εtart, the tool can accept an invocation of a tool function in block 371. The tool function iε invoked either through the assiεtant 12 via block 372 or through the tool user interface via block 374. Next, the tool function is performed at block 376, and, if required by the proceεε, the results therefrom are reported to the asεistant 12 at block 378. Again, the tool functions relevant to the procesε (and thuε required to be reported to the aεεiεtant) are determined during deεign of the process. The cycle iε repeated, and the tool is ready for the next tool function to be initiated from the waiting for invocation block 371, or the tool iε εtopped at block 380. Referring next to FIG. 9, there is shown a PDL diagram of an example of a typical process description specifying the assistance given in one of the prototypes of the present invention which illuεtratively deεcribeε the different steps a secretary needs to take when handling a meeting. Since the process description is expressed through graphical εy bolε, the flow diagram of FIG. 9 employε such graphical symbolε in the following diεcussion. Furthermore, the εystem 8 converts the graphical flow diagram to a format that can be interpreted by the asεistant logic interpreter as described above. The textual information shown in FIGS. 9-15 is a partial view of the complete content of the flow diagram. Each graphical symbol can have different kinds of textual information attached to it; an informal comment, implicitly or explicitly specified executable code, documentation, parameter specifications, etc. The view presented in FIGS. 9-15 only shows the parameter specifications for the icons in order to simplify the diagrams and render them eaεier to read. In thiε view both variableε and conεtantε are specified aε parameters, with variables being designated by a question mark as the firεt character thereof. In the graphical editor εupporting thiε language, thiε view can be changed to any of the other views described previously. Referring next to FIG. 8, there iε shown further exampleε of the components of the PDL iconε. A baεic building block in PDL iε the activity conεtruct which deεcribeε the conditions and effects of an activity and takes the general structure illustrated in FIG. 8. The activity icon 386 iε εurrounded on one εide by the precondition icons 388. The precondition icons 388 describe the necessary conditions for the activity to be executed. For example, in FIG. 11, the symbols 140, 142, and 144 are all preconditions. The activity icon 386 acts as a reference to the complete construct, i.e., all of the preconditions and effectε. The effect icon 390 can repreεent an operation to be performed, either by the user 16 or automatically through the assistant 12. There also exists a number of different predefined icons representing specific conditions and effects, e.g., menu icons, file icons, clock iconε, etc. Predefined executable code, documentation, etc. are attached to thoεe iconε, and parameters can be given to the icons. It should be noted that all variables introduced in an activity are local to the activity. Aε εtated above, εhadow objectε internal to the assistant are holders of state information. In order to keep track of documents, programs, the different processes, subprocesses, etc. all of them are represented aε shadow objects in the assistant. These shadow objects are created when the corresponding real objects are created. There exists a specific icon in PDL, the inεtantiation icon (inεtantiation in general means creating a particular example from a template, εuch aε a deεcription of a εhadow object) , that repreεentε the creation of a shadow object. In the case of the instantiation symbol 102 in FIG. 9, a secretary taεk iε instantiated. The diagram of the secretary taεk is in general describing a number of poεεible ta.*3<:ε and many different meetingε can be arranged uεing this description. When executing the description in order to assist a user in arranging a particular meeting, this particular meeting arrangement task must have a representation, i.e., a shadow object. The instantiation symbol 102 represents the creation of such an instance, which then can hold statuε information about thiε particular meeting arrangement taεk, and can be referred to from other parts of the diagram. Referring next to the flow diagrams of FIGS. 9A- 9C, the process described relates to the tasks required of a secretary to arrange a business meeting or the like. The diagrams show different aspectε of the proceεs. The uppermost part, FIG. 9A, is a descriptive illustration of the start conditions of the procesε while the middle part, FIG. 9B, describeε the breakdown of the proceεε into subprocesses. The secretary process, as is possible for any other process handled by the support system 8, can contain several subprocesses. The subprocesses illustrated in FIG. 9B are the material subproceεε 108, the notice subprocesε 116, the meeting subprocess 118, the text editing subprocesε 119, and the protocol handling subprocess 122. The material subprocess 108 describeε how to collect the materials needed for the particular meeting while the notice subprocess 116 describes how to send information to the attendees of the meeting. The meeting subprocess 118 describes how to conduct the meeting and the text editing subprocess 119 describeε how to enter text (for example, what tool to uεe) . The protocol handling εubprocess 122 deεcribes how to handle the subtaεk of writing a protocol. The lower part, FIG. 9C, describes the stop condition of the process. It should alεo be understood that there exist other viewε of the proceεε (interface view, activity view, etc.) which are not εhown in FIGS. 9A-9C. Each of the εubproceεεeε beginε automatically once the criteria for instantiation have been satiεfied, which for example, could be that a service which the procesε offers has been requeεted (such as text input from some other subprocesε) . A εequence of processes or subproceεses can also be deεcribed, and in thiε caεe the event important to the task of a succeeding procesε iε the event "finiεhed" reported by the preceding proceεε. The transfer of information diagrammatically indicated by arrows such as the "edit" arrow 112 and the "material finished" arrow 114 within FIG. 10, further illustrates the exchange of events relevant to the subprocesses describing concurrent tasks. The arrows are of no semantic importance in the diagram and are only an informal way of describing information flow. The real exchange of information is handled by the inference engine of the underlying expert system and is described in detail in the corresponding subprocesses. The icon 100, represents the fact that the support syεtem 8 beginε itε operation by receiving an external event that initiateε the proceεε (corresponding or example, to the user creating a new meeting arrang-. .ant taεk) ; the parameterε of the event is the name ("start") and the kind of proceεs to start ("secretary") . Inεtantiation occurs at icon 102. The symbol 104 represents the setting of initial values associated with the secretary procesε, and is described as a state change of the proceεε (the aεpect "started" of the proceεε iε εet to true) . The activity icon 101 represents the complete activity, as deεcribed above. Referring next to the different arrowε εhown in FIG. 9, the edit arrow 112 indicateε the material subprocess 108 referring to a service handled by another subproceεε. In this caεe, from within the material εubprocesε 108 the text editing subprocesε 119 iε utilized. The text editing εubprocesε 119 deεcribeε how to uεe a text editor which can be performed in parallel and concurrently with activities described by other subprocesses in the system. Once the material subprocesε 108 and the notice εubprocess 116 have completed their respective taskε the finished events 114 and 115 occur. The "notes from meeting" event 120 from the meeting 118 indicates that data from the meeting iε available. The meeting data is utilized by protocol handling subprocess 122 which representε the poεtmeeting work which muεt be done. The edit event 112 leadε to further text editing by text editing subprocesε 119. Thus, FIG. 9 illustrates event exchanges between subprocesses describing tasks that can be executed in parallel. The tasks of the material subprocesε 108 and the notice subprocess 116, for example, can occur in parallel, as is evidenced by the lack of any εynchronizing eventε being exchanged between them. In icon 124, the condition describes the state where the halted aspect in any subprocess is true. In icon 126 the condition stateε that εuch a proceεε must be of kind "protocol handling" to be of interest for this activity. In icon 128 the εecretary process (identified by ?process) is found which owns the halted εubproceεs. Finally, in icon 130 the secretary procesε iε halted. Referring next to FIG. 10, there iε alεo illuεtrated the method for proceεsing data pursuant to the teachings of the preεent invention. This representε an inεtantiation of the notice εubprocesε 116 of FIG. 9. Thus, the secretary taεk must have been started, which is repreεented by the εymbols 130 and 132 (the started aεpect iε true and the kind of process is "secretary") . When the precondition is true, the activity 135 is begun and the instantiation of the notice εubproceεε 116 iε effected in symbol 136 (the reference to this instance iε "subprocesε") . Then at the symbol 138, the initial values of the notice εubproceεε are recorded aε εtate information. Referring next to FIG. 11, there iε illuεtrated, in further detail, the method for proceεεing data pursuant to the teachings of the present invention and, in particular, an edit activity 145. The mechaniεmε of the underlying expert εyεtem will detect when the preconditions of the activity are true. For the edit activity 145 to be poεεible, the εymbol 140 indicates that the notice subproceεε muεt be started. The symbol 142 indicateε that data requiring temporary file storage will be generated through the present activity and, therefore, a temporary file name must be known in order to store the information (the way in which this is done is described in the code section of the symbol which is not shown here) . Next, the menu 144 functions as the description of interaction with the user 16. In PDL language the menu symbol abstracts the way in which the aεεiεtant 12 interactε with the uεer 16, for example, activity lists can be presented to the uεer 16. First, the symbol represents the text (in this particular case "write notice") that iε presented to the user 16. The text presented deεcribeε an activity that can or εhould be performed by the uεer 16. The menu 144 alεo implieε an object, e.g., a file, code, etc., on which the activity is performed (in this case the temporary file represented by ?temp) . Further, the menu 144 representε a condition. Before the uεer 16 explicitly εelectε the activity in the activity list, this condition is always false, and the effects, such aε execution of a tool function or a εtate change, are not effected. When the user 16 selectε the activity in the uεer interface, the condition becomeε true and the effectε are executed. In thiε case, when the user 16 selects the write notice choice in the activity list, an edit event is sent (corresponding to arrow 112 in FIG. 9) in symbol 146 to another subprocesε requeεting an edit taεk. Thiε requeεt is handled by the text editing subprocess (not shown here) , where the editor is started and the user 16 then uses the editor to write notice of the meeting. Referring next to FIG. 12, there is shown further details of the data proceεεing of the present invention. The description of the notice εubprocess 116 continues with an activity 151 comprising the retrieval of data pertaining to who is going to attend the meeting. The symbol 150 indicates that information must be retrieved if the state of the "others" aspect of the process is false. The symbol 152 could result in a menu window which requests entry of those expected to attend which would then be described in the code view of the icon 152, using basic windowing primitives supported by the syεtem. The symbol 154 represents the state of the notice subproceεε 116 and εymbolizeε that retrieval of the nameε haε occurred (the εtate of the "others" aspect is now true) . Thiε activity is triggered by the activity described below in connection with FIG. 13. Referring now to FIG. 13, the description of the notice process continues. Beginning with the symbol 160, an event from another subprocesε iε detected in which a file has been saved. This information originates from the text editing εubproceεε 119. At the symbol 162, the syεtem performε a check to verify that the file εaved iε the same file as referred to in the temporary filename 142 (this is part of the state information of the process) . The system next checks whether the next condition has been εatiεfied, i.e., whether all other attendees have been accounted for, which occurs at εy bol 164. If thiε is not true, the activity of FIG. 12 is triggered in order to get the attendeeε. Here the goal driven aspect of the underlying expert system is used, i.e., if a condition is not fulfilled and there exists an activity the effectε of which will satisfy the condition, this activity will be performed. At the symbol 166, the system ascertainε whether noticeε have previously been sent to the attendees (this is recorded as state information on the ?file object) . This illustrates the non-sequential character of the overall support system 8. With each of the processes and subprocess operating in parallel fashion and concurrently, the system must perform checks to assure itself that work does not get repeated, and thereby result in erroneous results, in decreased performance and slower processing capabilities of the system. Thus, because only one notice of the meeting is required the symbol 166 performs the check. In satisfying the final condition, the menu 170 provides the user 16 with the choice of selecting the "send notice" activity 171. At symbol 172, the assistant of the present invention sends the notice and prints it. The symbol 172 symbolizes an operation which loads, mails, and prints the notice for transmittal to all neceεsary parties (which could be achieved by using the UNIX mail and print services which are again described in the code view of the icon) . The symbol 174 records the εtate information that the notice has been sent on the ?file object, and thereby this activity cannot be repeated. Referring now to FIG. 14, elements of the notice subprocess are further detailed in diagrammatic form. The symbol 180 indicateε the condition that a "hard copy" of the notice muεt already have been created; in other words, the notice was printed (thiε occurε in activity 171 above). The menu 182, tellε the uεer 16 that the notice εhould be placed on the notice board in the desired location. The activity 184 in this case represents an activity which the support syεtem 8 cannot aεsist in by supplying tools; rather, the uεer 16 must physically place the notice himεelf or herself. Therefore the icon 186 indicates that only an internal εtate change takes place in this activity and no external tool iε involved. Finally, referring to FIG. 15, the activity 194 compriεing completion of the notice εubproceεs is illustrated therein. The conditions 190 and 192 are true when the notice has been sent and posted. The symbol 196 stops the process, and the symbol 198 records this state change. It also operates an event for processes interested in thiε fact due to the triggering mechanisms of the expert system. Referring back to FIG. 9, it is seen that the notice subprocess 116 leads to the meeting 118, when the finished arrow 114 iε followed. Thuε, at the occurrence of the event 198 the meeting 118 would be instantiated and the neceεεary steps and taskε required to complete the meeting would then take place. A εymbol identifier deεcription iε attached hereto aε Appendix A. The deεcription defines the graphical symbols utilized by the support system 8 as illustrated in FIGS. 8-15. Also attached hereto, as Appendices B and C are detailed program listingε for carrying out the data proceεsing stepε for a different prototype designed according to the teachings described in thiε application. More particularly, Appendiceε B and C are program liεtingε illustrating the manner in which code is generated in ProKappa language by the PDL graphical language for execution within an expert εystem 20 of the type used in the present invention. While the exemplary processeε defined by the program liεtings of Appendices B and C are entirely different from the example of the secretary process shown in FIGS. 8-15, the listings are instructive to illustrate how the PDL definition of a procesε iε reduced to executable code. In FIGS. 8-15 a number of different activitieε have been shown. These are internally non-sequential, since the conditions for each of them are tested for validity no matter which other activities have been performed. In this way a maximum of flexibility can be achieved for the end user. Through the mechaniεmε deεcribed above, the εupport for different taεkε can be created and modified without having to change the different tools being used. The formal description acts as a control program on top of a number of components, deεcribing the logic that is needed in order to make single tools act in an integrated way. Thus, there has been described and illustrated herein a method and apparatus for system development support. Those skilled in the art, however, will recognize that many modificationε and variationε beεideε thoεe specifically mentioned may be made in the techniques deεcribed herein without departing substantially from the concept of the present invention. Accordingly, it should be clearly unάerεtood that the form of the invention aε described herein is exemplary only and is not intended as a limitation on the scope of the invention. APPENDI X A 1 Symbol identifier daeπrlptlon 1.1 Activities A central concept in PDL is the activity. An activity is represented by a cube. Conditions are connected to the activity to describe when it can be performed. Effects are connected to the activity to described what is achieved (how it effects the rest of the world). 1.2 Conditions A general condition is represented by a triangle with the top pointing downwards. A condition is connected to an activity through a flow arrow. V More than one condition can be connected to an activity. When one condition must be valid before the next can be tested, it is expressed as: The condition furthest away from the activity is tested first. To be able to express something more specific than a general condition, a number of specific condition icons exists: I I Input (a general object) must exist. Input (a document or file) must exist in a certain status (described by parameters), for example a certain revision. This is a specialization of the previous sy bol. Describes a state, for example an attribute in an object C must have a certain value (proc. state==validation or obj. al>obj. 2). Describes a time expression, for example that something should happen at a certain time (now. date>=1991-10-15). Describes an activity that should be presented to the user in the user interface. The corresponding activity is executed when the user selects the activity in the user interface. This condition should be placed last in a chain of conditions, so as to make certain that the rest of the con ,*..ions really are valid when the activity is performed. Describes a condition on an incoming signal (parameters can be attached to it). 1.3 Effects A general effect is represented by a triangle with its base downwards. Δ An activity is connected to an effect through a flow arrow. An activity can be connected to many effects. If one effect must be performed before another, it is expressed as: e effects closest to the activity is performed first. Also more complex effects can be described: The figure implies the following effects: x To express something more s i xfic than a general effect, there exists a number of specific eifect symbols: [ j A general object is created as output. 1 PDL has a statement form and semantics that is reminiscent of Prolog, which means that each statement (effect) either succeeds or fails. This can be mapped to the flow relations of the effects. "Or" in this case is interpreted as all branches are tested until one succeeds. A document or file is created as output or receives a new status (for example a new revision). This is a specialization of the previous symbol. Describes a state D change (for example proc. state=validation). example wait for a asynchronous signal Describes an outgoing signal. The signal can either be broadcasted or be directed to a specific receiver. creation of a shadow object (could ess or an object describing a real object Describes the removal of an object (usable when a process is terminated). <generic effect symbol>:: Δ <specific effect symbol>: <and association symbol > ^ <or association symbol > *► <not association sym b o l : w <control association symbol> <inherit association symbol> APPENDIX B * * Generated by PDL for ProKappa at: May-20-1991 12:49:30 from: Vtmp_mnt/usr/local/sds/pgm/ess/assistent/bin/eslambada' * */ =include <prk/lib.pth> /* * PROCESS: v flow design' type: process with process icon on page: 003 design' ruleset: flowDesign PRE-CONDITIONS: ACTIVITY: flow design POST-CONDITIONS: * */ /* * ACTIVITY: flow design' type: activity with stamp icon on page: 004 flow design' refined: no rule: flowDesign_flowDesign_l ruleset: flowDesign PRE-CONDITIONS: ACTIVITY: flow design POST-CONDITIONS: * */ /* no code available*/ /* * ACTIVITY: λ flow design rules' type: activity with decomposition icon on page: 004 flow design' refined: yes rule: flowDesignRules_flowDesign_2 ruleset: flowDesign PRE-CONDITIONS: ACTIVITY: flow design rules POST-CONDITIONS: * */ /* no code available*/ /* * ACTIVITY: unnamedActivity' type: activity with box icon on page: 012 λ flow design rules' refined: no rule: unnamedActivity_flowDesign_3 ruleset: flowDesign PRE-CONDITIONS: instance of flow design activities ACTIVITY: POST-CONDITIONS: ferule unnamedActivity_flowDesign_3 in flowDesign { if: /* precond with precondition icon */ ?process == instanceof NonToolProcessObj ; ?process.Type ■== flowDesign; /* precond with menu icon */ ?process.presentAlternative("activities" , flowDesign) ?process.Selected == TRUE; ?process.SelectedActivity =-= "activities"; then: /* activity with box icon */ / * / ACTIVITY: unnamedActivity' type: activity with state change icon on page: 012 x flow design rules' refined: no rule: unnamedActivity_flowDesign_4 ruleset: flowDesign PRE-CONDITIONS: SavedTime > TouchedTime Working Name != "unnamed" "done for now" ACTIVITY: POST-CONDITIONS: TemporarlyFinished * ferule unnamedActivity_flowDesign_4 in flowDesign { if: /* precond with precondition icon */ ?x.SavedTime > ?x.TouchedTime; /* precond with precondition icon */ ?x.Status == Working; /* precond with precondition icon */ ?nm == ?x.Name; /* Forward chaining */ ?nm != "unnamed"; /* precond with menu icon */ ?x.presentAlternative("done for now",ESed) ; ?x.Selected ■=■= TRUE; ?x.ActivitySelected = "done for now" ; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker. ; angeState(?x,Status,TemporarlyFinished) ; /' ACTIVITY: unnamedActivity' type: activity with state change icon on page: 012 λ flow design rules' refined: no rule: unnamedActivity_flowDesign_5 ruleset: flowDesign PRE-CONDITIONS: SavedTime > TouchedTime Working Name = "unnamed" "name flow" ACTIVITY: POST-CONDITIONS: Print "Choose Save As option in the editor" * * ferule unnamedActivity_flowDesign_5 in flowDesign { if: /* precond with precondition icon */ ?x.SavedTime > ?x.TouchedTime; /* precond with precondition icon */ ?x.Status == Working; /* precond with precondition icon */ ?x.Name == "unnamed"; /* precond with menu icon */ ?x.presentAlternative("name flow",ESed) ; ?x.Selected == TRUE; ?x.ActivitySelected = "name flow"; then: /* activity with state change icon */ /* postcond with transmitter icon */ /*displayMgr.presentInfo("choose the Save As option in the editor") ;*/ Print("choose the Save As option in the editor") ; /' ACTIVITY: unnamedActivity' type: activity with state change icon on page: 012 flow design rules' refined: no rule: unnamedActivity_flowDesign_6 ruleset: flowDesign PRE-CONDITIONS: TranslationError "correct errors" ACTIVITY: POST-CONDITIONS: request edit ferule unnamedActivity_flowDesign_6 in flowDesign if: /* precond with precondition icon */ ?x.TranslationStatus == TranslationError; /* precond with menu icon */ ?x.presentAlternative("correct errors",ESed) ; ?x.Selected == TRUE; ?x.SelectedActivity == "correct errors"; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker.requestService(?x.Esed,edit) ; } /* ACTIVITY: flow design rules 2' type: connector with mooring icon on page: 012 Λ flow design rules' refined: yes rule: flowDesignRules2_flowDesign_7 ruleset: flowDesign PRE-CONDITIONS: ACTIVITY: flow design rules 2 POST-CONDITIONS: * /* no code available*/ /* ACTIVITY: unnamedActivity' type: activity with state change icon on page: 013 λ flow design rules 2' refined: no rule: unnamedActivity_flowDesign_8 ruleset: flowDesign PRE-CONDITIONS: Working not in editor "continue work" ACTIVITY: POST-CONDITIONS: request edit * * ferule unnamedActivity_flowDesign_8 in flowDesign { if: /* precond with precondition icon */ ?x.Status ■== Working; ,/* precond with precondition icon */ ?processes ■=■= all Tx.ProcessList; for ?process inlist ?processes; never ?process.Type ■=■= editor; /* precond with menu icon */ ?x.presentAlternative("continue work",ESed) ; ?x.Selected == TRUE; ?x.SelectedActivity == "continue work"; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker.requestService(?x,ESed,edit) ; } * ACTIVITY: unnamedActivity' type: activity with state change icon on page: 013 flow design rules 2' refined: no rule: unnamedActivity_flowDesign_9 ruleset: flowDesign PRE-CONDITIONS: ESed process no files loaded "create file" ACTIVITY: POST-CONDITIONS: request createFile * * ferule unnamedActivity_flowDesign_9 in flowDesign { if: /* precond with precondition icon */ ?x == instanceof ToolProcessObj ; ?x.Name == ESed; /* precond with precondition icon */ ?objectlist == all ?x.ObjectSet; ?objectlist == x () ; /* precond with menu icon */ ?x.presentAlternative("create file",ESed) ; ?x.Selected == TRUE; ?x.SelectedActivity == "create file"; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker.requestService(?x,ESed,createFile) ; }* * ACTIVITY: unnamedActivity' type: activity with state change icon on page: 013 x flow design rules 2' refined: no rule: unnamedActivity_flowDesign_10 ruleset: flowDesign PRE-CONDITIONS: ChangedTime > SavedTime Working "save changes" ACTIVITY: POST-CONDITIONS: request save * * / ferule unnamedActivity_flowDesign_10 in flowDesign { if: /* precond with precondition icon */ ?x.ChangedTime > ?x.SavedTime; /* precond with precondition icon */ ?x.Status == Working; /* precond with menu icon */ ?x.presentAlternative("save changes",ESed) ; ?x.Selected •== TRUE; ?x.ActivitySelected = "save changes"; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker.requestService(?x,ESed,save) ; } /* * ACTIVITY: x flow design rules 3' type: connector with mooring icon on page: 013 x flow design rules 2' refined: yes rule: flowDesignRules3_flowDesign_ll ruleset: flowDesign PRE-CONDITIONS: ACTIVITY: flow design rules 3 POST-CONDITIONS: * /* no code available*/ /' ACTIVITY: x unnamedActivity' type: activity with state change icon on page: 014 x flow design rules 3' refined: no rule: unnamedActivity_flowDesign_12 ruleset: flowDesign PRE-CONDITIONS: !Translating, !CorrectlyTranslated SemanticallyModified TemporarlyFinished TouchedTime > TranslateTime "translate" ACTIVITY : POST-CONDITIONS : request translate * */ ferule unnamedActivity_flowDesign_l2 in flowDesign { if: /* precond with precondition icon */ ?ts == ?x.TranslationStatus;Print(11) ; C : P rk F i n d L i s t E l t ( x ( N o t T r a n s 1 a t e d , T r a n s l a t i n g , Correct lyTranslated) i , ?ts ) ! = /* precond with precondition icon */ Tx.ChangedStatus == SemanticallyModified;Print(13) ; /* precond with precondition icon */ ?x.Status == TemporarlyFinished;Print(14) ; /* precond with precondition icon */ ?x.TouchedTime > ?x.TranslationTime;Print(15) ; /* precond with menu icon */ ?x.presentAlternative("translate" ,ESed) ; ?x.Selected == TRUE; ?x.SelectedActivity == "translate"; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker.requestService(?x.ESe ,edit) ; /' ACTIVITY: x unnamedActivity• type: activity with state change icon on page: 014 x flow design rules 3' refined: no rule: unnamedActivity_flowDesign_13 ruleset: flowDesign PRE-CONDITIONS: lUnTranslated SemanticallyModified, CosmeticallyModified TemporarlyFinished TouchedTime > TranslateTime "translate" ACTIVITY: POST-CONDITIONS: request translate ferule unnamedActivity_fJ-owDesign_13 in flowDesign { if: /* precond with precondition icon */ Tx.TranslationStatus =•= NotTranslated;Print(21) ; /* precond with precondition icon */ ?ChangedStatus == Tx.ChangedStatus; Print(22) ; or { ?ChangedStatus == SemanticallyModified;Print(23) ; ?ChangedStatus == CosmeticallyModified; }Print(24) ; /* precond with precondition icon */ ?x.Status == TemporarlyFinished;Print(25) ; /* precond with precondition icon */ ?x.TouchedTime > ?x.TranslationTime;Print(26) ; /* precond with menu icon */ ?x.presentAlternative("translate" ,ESed) ; ?x.Selected == TRUE; Tx.SelectedActivity == "translate"; then: /* activity with state change icon */ postcond with transmitter icon */ broker.requestService(?x.ESed,edit) ; APPENDIX C /* * Generated by PDL fo: ProKappa at: May-20-1991 1 49:37 from: /tmp_mnt/usr/local/scl pgm/css/assistent/bin/esla bada' * */ r,include <prk/lib.pth> /* * PROCESS: x ESed' type: process with process icon on page: 004 x flow design' ruleset: ESed ' PRE-CONDITIONS: ACTIVITY: ESed POST-CONDITIONS: * */ /* * ACTIVITY: ESed' type: activity with stamp icon on page: 005 x ESedl' refined: no rule: ESed_ESed_l ruleset: ESed PRE-CONDITIONS: ACTIVITY: ESed POST-CONDITIONS: * */ /* no code available*-/ /* * ACTIVITY: shadow object' type: activity with stamp icon on page: 005 x ESedl' refined: no rule: shadowObject_ESed_2 ruleset: ESed PRE-CONDITIONS: objectCreated find flow shadow object exists ACTIVITY: shadow object POST-CONDITIONS: set initial values ChangeStatus, Status link symbol * * ferule shadowObject_ESed_2 in ESed { if: /* precond with receiver icon */ ?msg.Sender ■=■= ESed; ?msg.MsgName == objectCreated; /* precond with precondition icon */ ?DbId = ?msg.formDbId(0) ; ?flow == instanceof EslObj ; ?flow.DbId == ?DbId; /* precond with precondition icon */ for ?cpp inlist all Tflow.EMSet; never ?cpp.Name == ListNth(?msg.Parameters, 4) ; then: /* activity with stamp icon */ Tnewcpp = MakeAnonymousInstance(assistent,CppCodeObj ) ; /* postcond with postcondition icon */ ?newcpp.Name = LiεtNth(?msg.Parameters,4) ; Tnewcpp.initValues() ; Tnewcpp.Dbld = SendMsg(?msg, formDbld, 0) ; ?newcpp.Type = ListNth(?msg.Parameters, 3) ; /* postcond with transmitter icon */ broker.changeState(?newcpp,Status,NotExisting) ; broker.changeState(?newcpp,ChangedStatus,Unmodified) ; /* postcond with postcondition icon */ ?flow.EMSet +== ?newcpp; ) ACTIVITY: x unnamedActivity* type: activity with state change icon on page: 005 x ESedl' refined: no rule: unnamedActivity_ESed_3 ruleset: ESed PRE-CONDITIONS: objectDeleted find flow shadow object exists ACTIVITY: POST-CONDITIONS: unlink object delete object ferule unnamedActivity_ESed_3 in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; ?msg.MsgName == objectDeleted; /* precond with precondition icon */ ?DbId = ?msg. formDbld(0) ; ?flow == instanceof EslObj ; ?flow.DbId == ?DbId; /* precond with precondition icon */ local ?cpp == find ?flow.EMSet; local ?cpp.Name == ListNth(?msg.Parameters,4) ; then: /* activity with state change icon */ /* postcond with postcondition icon */ ?flow.EMSet === ?cpp; /* postcond with postcondition icon */ DeleteObject(?cpp) ; ) /* ACTIVITY: x unnamedActivity' type: activity with state change icon on page: 005 x ESedl' refined: no rule: unnamedActivity_ESed_4 ruleset: ESed PRE-CONDITIONS: objectRenamed find flow shadow object exists ACTIVITY : POST-CONDITIONS : set new name * * ferule unnamedActivity_ESed_4 in ESed ( if: /* precond with receiver icon */ ?msg.Sender == ESed; ?msg.Msg ame == objectRenamed; /* precond with precondition icon */ ?DbId = ?msg.formDbld(0) ; ?flow == instancec EslObj ; Tflow.Dbld = ~ = ?Db -; /* precond with precondition icon */ local ?cpp == find ?flow.EMSet; local ?cpp.Name == ListNth (?msg.Parameters, 4) ; then: /* activity with state change icon */ /* postcond with postcondition icon */ ?cpp.Name = ListNth(?msg.Parameters,5) ; /' ACTIVITY: ESed2' type: connector with mooring icon on page: 005 x ESedl' refined: yes rule: ESed2_ESed_5 ruleset • ESed PRE-CONDITIONS: ACTIVITY: ESed2 POST-CONDITIONS: /* no code available*/ ACTIVITY: x read from DB' type: activity with box icon on page: 006 ESed2' refined: no rule: readFromDB_ESed_6 ruleset: ESed PRE-CONDITIONS: flowOpened FB? find ESed process ACTIVITY: read from DB POST-CONDITIONS: link flow fetch FU's ferule readFromDB_ESed_6 in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; ?msg.MsgName == flowOpened; /* precond with precondition icon */ ListNth(?msg.Parameters,2) == ""; /* precond with precondition icon */ ?process == instanceof ToolProcessObj ; ?process . Pid == ?msg . SendersPid ; then : / * activity with box icon */ ?flow = db . GetAssInfo ( SendMsg ( ?msg , formDbld , 0 ) , " " ) ; /* postcond with postcondition icon */ ?process . Ob ectSet +== ?flow ; Tflow. ProceεsList +== ?procesε ; /* poεtcond with poεtcondition icon */ } * ACTIVITY: x shadow object' type: activity with stamp icon on page: 006 x ESed2' refined: no rule: shadow0bject_ESed_7 ruleset: ESed PRE-CONDITIONS: flowCreated FB? find ESed process ACTIVITY: shadow object POST-CONDITIONS: link flow set initial values ChangeStatuε, SimulationStatus, Status * * ferule shadowObject_ESed_7 in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; Tmsg.MsgName == flowCreated; /* precond with precondition icon */ ListNth(?msg.Parameters,2) == ""; /* precond with precondition icon */ ?process -- instanceof ToolProcessObj ; ?process.Pid == Tmsg.SendersPid; then: /* activity with stamp icon */ ?flow = MakeAnonymousInstance(assistent,FB) ; /* postcond with postcondition icon */ ?process.ObjectSet +== ?flow; Tflow.ProcessList +== ?process; /* postcond with postcondition icon */ ?flow.initValues() ; ?flow.Type = FB; ?flow.Name = ListNth(?msg.Parameters,1) ; ?flow.DbId = SendMsg(?msg. formDbld,0) ; /* postcond with transmitter icon */ broker.changeState(?flow,Status, orking) ; Broker.changeState(?flow,ChangedStatus,Unmodified) ; broker.changeState(?flow,SimulationStatus,Unsimulated) ; / * ACTIVITY: x ESed3' type: connector with mooring icon on page: 006 x ESed2' refined: yes rule: ESed3_ESed_8 ruleset: ESed PRE-CONDITIONS : ACTIVITY : ESed3 POST-CONDITIONS : * -k / /* no code available*/ ACTIVITY: x close all subobjects and abort' type: activity with box icon on page: 007 x ESed3' refined: no rule: closeAHSubobjectsAndAbort_ESed_9 ruleset: ESed PRE-CONDITIONS: flowAborted find FB flow ACTIVITY: close all subobjectε and abort POST-CONDITIONS: * ferule cloεeAHSubobjectsAndAbort_ESed_9 in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; Tmsg.MsgName ■== flowAborted; /* precond with precondition icon */ ?DbId = ?msg.formDbld(0) ; ?flow == instanceof FB; ?flow.DbId == ?DbId; then: /* activity with box icon */ for ?fu inlist all ?flow.FUSet; do {for ?cpp inlist all Tfu.EMSet; do broker.requestService(?cpp,ESed,close) ; DeleteOb ect(?fu) ; } DeleteObject(?flow) ; db.abort() ; } /* ACTIVITY: x close all subobjectε and abort' type: activity with box icon on page: 007 ESed3' refined: no rule: closeAHSubobjectsAndAbort_ESed_10 ruleset: ESed PRE-CONDITIONS: flowAborted find FU flow ACTIVITY: close all subobjects and abort POST-CONDITIONS: * ferule closeAHSubobjectsAndAbort_ESed_10 in ESed ( if: /* precond with receiver icon */ ?msg.Sender =■= ESed; ?msg.MsgName == flowAborted; /* precond with precondition icon */ ?DbId = ?msg.formDbld(0) ; ?flow == instanceof FU; ?flow.DbId == ?DbId; then: /* activity with box icon */ for ?cpp inlist all ?flow.EMSet; do broker.requeεtService(?cpp,ESed,cloεe) ; DeleteObject(?flow) ; db.abort() ; / }* * ACTIVITY: x unnamedActivity' type: activity with state change icon on page: 007 x ESed3' refined: no rule: unnamedActivity_ESed_ll ruleset: ESed PRE-CONDITIONS: flowChanged find flow ACTIVITY: POST-CONDITIONS: set change status set change time * -k / ferule unnamedActivity_ESed_ll in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; ?msg.MsgName == flowChanged; /* precond with precondition icon */ ?DbId = ?msg.formDbld(0) ; ?flow == instanceof EslObj ; Tflow.Dbld == ?DbId; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker.changeState(?flow,ChangedStatus,ListNth(?msg.Parameters, 3) ) ; /* postcond with transmitter icon */ broker.changeState(?flow,ChangedTime,SendMsg(?flow,getTime) ) ; } /* * ACTIVITY: x delete process' type: activity with box icon on page: 007 ESed3' refined: no rule: deleteProcess_ESed_12 ruleset: ESed PRE-CONDITIONS: ESedQuit find ESed process ACTIVITY: delete process POST-CONDITIONS: * */ ferule deleteProcess_ESed_12 in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; Tmsg.MsgName ■== ESedQuit; /* precond with precondition icon */ ?process == instanceof ToolProcessObj ; ?procesε.Pid ■== ?msg.SendersPid; then: /* activity with box icon */ DeleteObject(Tprocess) ; ACTIVITY: x unnamedActivity' type: activity with state change icon on page: 007 x ESed3' refined: no rule: unnamedActivity_ESed_l3 ruleset: ESed PRE-CONDITIONS: StartEditEM find FU flow find EM ACTIVITY: POST-CONDITIONS: request edit ferule unnamedActivity_ESed_13 in ESed { if: /* precond with receiver icon */ ?msg.Sender ■== ESed; ?msg.MsgName == StartEditEM; /* precond with precondition icon */ ?DbId = ?mεg.formDbld(0) ; ?flow == instanceof FU; ?flow.DbId == ?DbId; /* precond with precondition icon */ local ?cpp == find Tflow.EMSet; local lcpp.Name == ListNth(?msg.Parameters,3) ; the : /* activity with state change icon */ /* postcond with transmitter icon */ broker.requestService(?cpp,ESed,edit) ; /' ACTIVITY: x unnamedActivity' type: activity with state change icon on page: 007 λ ESed3' refined: no rule: unnamedActivity_ESed_l4 ruleset: ESed PRE-CONDITIONS: transStarted find flow ACTIVITY: POST-CONDITIONS: set compilation status * ferule unnamedActivity_ESed_l4 in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; Tmεg.MεgName == transStarted; /* precond with precondition icon */ ?DbId = ?msg. formDbld(0) ; ?flow ■== instanceof EslObj ; ?flow.DbId == ?DbId; then: /* activity with state change icon */ /* postcond with transmitter icon */ broker.changeState(?flow,TranslationStatus,Translating) ; } /* ACTIVITY: x ESed4 ' type: connector with mooring icon on page: 007 x ESed3' refined: yes rule: ESed4_ESed_15 ruleset: ESed PRE-CONDITIONS: ACTIVITY: ESed4 POST-CONDITIONS: * /* no code available*/ ACTIVITY: x unnamedActivity' type: activity with state change icon on page: 008 x ESed4' refined: no rule: unnamedActivity_ESed_16 ruleset: ESed PRE-CONDITIONS: transCompleted find flow ACTIVITY: POST-CONDITIONS: set compilation status set compilation time ferule unnamedActivity_ESed_l6 in ESed { if: /* precond with receiver icon */ ?msg.Sender == ESed; Tmsg.MsgName == transCompleted; /* precond with precondition icon */ ?DbId = ?msg.formDbld(0) ; ?flow == instanceof EslObj ; ?flow.DbId == ?DbId; then: /* activity with state change icon */ /* postcond with transmitter icon */ if ListNth(?msg.Parameters,3) == 0; broker . changeState ( ? flow , TranslationStatus , CorrectlyTranslated) ; else broker. changeState (?f low, TranslationStatus , TranslationError) ; /* postcond with transmitter icon */ broker.changeState(?flow,CompilationTime,SendMsg(?flow,getTime() ) ) ; / } *. * ACTIVITY: x tranεlateFlow' type: activity with pencil icon on page: 008 x ESed4' refined: no rule: translateFlow_ESed_17 ruleset: ESed PRE-CONDITIONS: translate find ESed process ACTIVITY: translateFlow POST-CONDITIONS: set compilation status * — */ ferule translateFlow_ESed_17 in ESed ( if: /* precond with receiver icon */ ?msg.RqstName == translate; ?msg.ActiveObj == inεtanceof EslObj ; /* precond with precondition icon */ ?process == find Tmsg.ActiveObj .ProcessList; ?process.Type == ESed; then: /* activity with pencil icon */ Tmsg.ActiveObj .translateFlow(?process) ; /* postcond with transmitter icon */ broker.changeState(?msg.ActiveObj ,CompilationStatus,Compiling) ; ) /* * ACTIVITY: loadFlow ■ type: activity with pencil icon on page: 008 ESed4' refined: no rule: loadFlow_ESed_18 ruleset: ESed PRE-CONDITIONS: load find ESed process ACTIVITY: loadFlow POST-CONDITIONS: * -k / ferule loadFlow_ESed_18 in ESed { if: /* precond with receiver icon */ ?msg.RqstName == load; Tmsg.ActiveObj == instanceof EslObj; /* precond with precondition icon */ ?process =■= find Tmsg.ActiveObj .ProcessList; Tprocess.Type == ESed; then: /* activity with pencil icon */ Tmsg.ActiveObj .loadFlow(Tprocess) ; } /* * ACTIVITY: x createFlow' type: activity with pencil icon on page: 008 x ESed4" refined: no rule: createFlow_ESed_19 ruleset: ESed PRE-CONDITIONS: create find ESed proceεs ACTIVITY: createFlow POST-CONDITIONS: * ferule createFlow_ESed_19 in ESed { if: /* precond with receiver icon */ Tmsg.RqstName == create; Tmsg.ActiveObj == instanceof FB; /* precond with precondition icon */ Tprocess == find Tmsg.ActiveObj .ProcessList; Tprocess.Type == ESed; then: /* activity with pencil icon */ Tmsg.ActiveObj .createFB(Tprocess) ; ) /* * ACTIVITY: x saveFlow' type: activity with pencil icon on page: 008 x ESed4' refined: no rule: saveFlow_ESed_20 ruleset: ESed PRE-CONDITIONS: save find ESed process ACTIVITY: saveFlow POST-CONDITIONS: * ferule saveFlow_ESed_20 in ESed { if: /* precond with receiver icon */ Tmsg.RqstName == save; Tmsg.ActiveObj == instanceof EslObj; /* precond with precondition icon */ Tprocess == find Tmsg.ActiveObj .ProcessList; Tprocess.Type == ESed; then: /* activity with pencil icon */ Tmsg.ActiveObj .saveFlow(Tprocess) ; ) /* . ACTIVITY: x quitEsed' type: activity with pencil icon on page: 008 ESed4* refined: no rule: quitEsed_ESed_21 ruleset: ESed PRE-CONDITIONS: quit find ESed process ACTIVITY: quitEsed POST-CONDITIONS: * ferule quitEsed_ESed_21 in ESed { if: /* precond with receiver icon */ Tmsg.RqstName -= quit; Tmsg.ActiveObj == instanceof EslObj ; /* precond with precondition icon */ Tprocess == find Tmsg.ActiveObj .ProcessList; Tprocess.Type == ESed; then: /* activity with pencil icon */ Tprocess.quit() ; > /* , ACTIVITY: x unnamedActivity' type: activity with box icon on page: 008 x ESed4' refined: no rule: unnamedActivity_ESed_22 ruleset: ESed PRE-CONDITIONS: test actbrowser ACTIVITY: POST-CONDITIONS: * V ferule unnamedActivity_ESed_22 in ESed { if: /* precond with precondition icon */ Tmsg.MsgName == edit; Tmsg.ActiveObj == instanceof TextObj ; Tmsg.presentAlte native("edit",ESed) ; Tmsg.ActiveObj .Selected == TRUE; Tmsg.ActiveObj .SelectedActivity =■= edit; then: /* activity with box icon */ Print("It works! !!••); ) /' ACTIVITY: x read from DB' type: activity with box icon on page: 006 x EScd2* refined: no rule: readFromDB_ESed_23 ruleset: ESed PRE-CONDITIONS: flowOpened FUT find FB ACTIVITY: read from DB POST-CONDITIONS: link flow fetch EM's ferule readFromDB_ESed_23 in ESed { if: /* precond with receiver icon */ Tmsg.Sender == ESed; Tmsg.MsgName == flowOpened; /* precond with precondition icon */ LiεtNth(Tmεg.Parameterε,2) != ""; /* precond with precondition icon */ TDbld = Tmεg. formDbld(0) ; Tfb == inεtanceof FB; Tfb.Dbld == TDbld; then: /* — activity with box icon */ Tflow = db.GetAssInfo(SendMsg(Tmsg,formDbld,0) ,"") ; /* postcond with postcondition icon */ Tfb.FUSet +== Tflow; /* postcond with postcondition icon */ } /* ACTIVITY: x shadow object' type: activity with stamp icon on page: 006 x ESed2' refined: no rule: shadowObject_ESed_24 ruleset: ESed PRE-CONDITIONS: flowCreated FUT find FB ACTIVITY: shadow object POST-CONDITIONS: link flow set initial values ChangeStatus, SimulationStatus, Status * ferule shadowθbject_ESed_24 in ESed { if: /* precond with receiver icon */ Tmsg.Sender == ESed; Tmsg.MsgName == flowCreated; /* precond with precondition icon */ ListNth(Tmsg.Parameters,2) != ""; /* precond with precondition icon */ TDbld = Tmsg.formDbld(0) ; Tfb == instanceof FB; Tfb.Dbld == TDbld; then: /* activity with stamp icon */ Tflow = MakeAnonymousInstance(assistent,FU) ; /* postcond with postcondition icon */ Tfb.FUSet +== Tflow; /* postcond with postcondition icon */ Tflow.initValues() ; Tflow.Type = FU; Tflow.Name = ListNth(Tmsg.Parameters,2) ; Tflow.Dbld = SendMsg(Tmsg,formDbld,0) ; /* postcond with transmitter icon */ broker.changeState(Tflow,Status,Working) ; Broker.changeState(Tflow,ChangedStatus,Unmodified) ; broker.changeState(Tflow,SimulationStatus,Unsimulated) ; /' ACTIVITY: λ ESed2.5' type: connector with mooring icon on page: 006 x ESed2' refined: yes rule: ESed25 Esed 25 ruleset: ESed PRE-CONDITIONS: ACTIVITY: ESed2.5 POST-CONDITIONS: * */ /* no code available J / /* . * ACTIVITY: sav shadow object' type: activity with box icon on page: 009 ESed2.5' refined: no rule: saveShadowθbject_ESed_26 ruleset: ESed PRE-CONDITIONS: flowSavedlnDb find flow ACTIVITY: save shadow object POST-CONDITIONS: set save time * * / ferule saveShadowObject_ESed_26 in ESed { if: /* precond with receiver icon */ Tmsg.Sender == ESed; Tmsg.MsgName == flowSavedlnDb; /* precond with precondition icon */ TDbld = Tmsg.formDbld(0) ; Tflow == instanceof EslObj; Tflow.Dbld == TDbld; then: /* activity with box icon */ Tflow.putInDb() ; db.commit() ; /* postcond with transmitter icon */ broker.changeState(Tflow,SavedTime,SendMsg(Tflow,getTime) ) ; } /* * ACTIVITY: save shadow object under new name' type: activity with box icon on page: 009 x ESed2.5* refined: no rule: saveShadowθbjectUnderNewName_ESed_27 ruleset: ESed PRE-CONDITIONS: flowSavedAsInDb find flow ACTIVITY: save shadow object under new name POST-CONDITIONS: set save time * */ ferule saveShadowObjectUnderNewName_ESed_27 in ESed { if: /* precond with receiver icon */ Tmsg.Sender == ESed; Tmsg.MsgName == flowSavedAsInDb; /* precond with precondition icon */ TDbld = Tmsg.formDbld(0) ; Tflow == instanceof EslObj ; Tflow.Dbld *== TDbld; then: /* activity with box icon */ Tflow.Dbld = SendMsg(Tmsg, formDbld, 3) ; if ListNth(Tmsg.Parameters,5) == ""; Tflow.Name = ListNth(Tmsg.Parameters,4) ; else Tflow.Name = ListNth(Tmsg.Parameters,5) ; Tflow.putInDb() ; db.commit() ; /* postcond with transmitter icon */ Broker.changeState(Tflow,SavedTime,SendMsg(Tflow,getTime) ) ; / }* * ACTIVITY: x close all subobjects' type: activity with box icon on page: 009 x ESed2.5' refined: no rule: closeAHSubobjectε_ESed_28 ruleset: ESed PRE-CONDITIONS: flowClosed find FU flow ACTIVITY: close all subobjects POST-CONDITIONS: * ferule closeAHSubobjects_ESed_28 in ESed { if: /* precond with receiver icon */ Tmsg.Sender =■■= ESed; Tmsg. sgName == flowClosed; /* precond with precondition icon */ TDbld = Tmsg.formDbld(0) ; Tflow == instanceof FU; Tflow.Dbld == Dbld; then: /* activity with box icon */ for Tcpp inlist all Tflow.EMSet; do broker.requestService(Tcpp,ESed,close) ; DeleteObject(Tflow) ; / }* ACTIVITY: close all subobjects' type: activity with box icon on page: 009 x ESed2.5' refined: no rule: closeAHSubobj ectε_ESed_29 ruleset: ESed PRE-CONDITIONS: flowClosed find FB flow ACTIVITY: close all subobjects POST-CONDITIONS: * ferule closeAHSubobjects_ESed_29 in ESed { if: /* precond with receiver icon */ Tmsg.Sender == ESed; Tmsg.MsgName == flowClosed; /* precond with precondition icon */ TDbld = Tmsg. formDbld(0) ; Tflow == instanceof FB; Tflow.Dbld == TDbld; then: /* activity with box icon */ for Tfu inlist all Tflow.FUSet; do {for Tcpp inlist all Tfu.EMSet; do broker.requestService(Tcpp,ESed,close) ; DeleteObject(Tfu) ; } DeleteObject(Tflow) ;

Claims: WHAT IS CLAIMED IS: 1. A method of providing interactive support for developing computer baεed productε according to a set of procedures comprising: defining said set of procedures as a description using a graphical language; converting said set of procedures into a format understandable by a processor; storing said converted description; generating a menu of choices, each of said choices constituting a suggeεtion regarding the actions relevant to the development according to said set of procedures; selecting one of said choices; responding to said choice selection by either initiating at least one of a group of system tools or changing the state representation of the process; tracking operations performed by said syεtem tool by monitoring and storing each event related to the development according to εaid set of procedures; interpreting each of said operations performed by said system tool; automatically initiating others of said tools in response to said interpretation and tracking of said operations; and providing feedback to a uεer. 2. The method of claim 1 f rther compriεing the εtep of dynamically updating an activity window in response to said initiation of said εystem tool, said dynamic update permitting said uεer to reεpond. 3. The method of claim 1 wherein said set of procedureε compriεe a proceεε, said proceεε further containing subprocess units contained within said description of said procesε. 4. The method of claim 1 further comprising the step of performing conεiεtency checks between different information units deεcribed by said subproceεε unitε contained within said description after initiation and execution of said tools. 5. The method of claim 5 further comprising the step of reporting process errors diεcovered by said consistency check step. 6. The method of claim 1 further comprising the step of browsing. 7. The method of claim 6 wherein said step of browsing comprises: finding and retrieving objects from within a data base asεociated with εaid process; εelectively viewing εaid objectε retrieved from within said data base; selectively manipulating said objects within said data base; selectively initiating any of said system tools; and reporting activities performed by tools initiated by the browser. 8. The method of claim 1 further comprising the step of independently initiating said system tools through a unix shell level. 9. A computer εyεtem for providing interactive support during the development of a set of procedures, said system comprising: means for storing a formal process description; meanε for tranεforming said formal proceεε description into an executable format; and a user interface. 10. The computer syεtem of claim 9 wherein εaid process storage means maintains state information in the form of shadow objects of said formal procesε deεcription to permit perεiεtent εtorage of the εtate of said subprocess. 11. The computer system of claim 9 wherein said assistance means comprises: an assistant logic module; an assistant logic interpreter; a data base electronically accessible to said logic interpreter; a message handler electronically linked to said logic interpreter; and a group of tools capable of being accessed concurrently by said meεεage handler and configured to perform specific tasks related to process. 12. The computer system of claim 11 wherein said assistant logic interpreter comprises: means for graphically communicating with the user of said system. 13. The computer system of claim 11 wherein said asεiεtant logic .interpreter comprises an expert syεtem. 14. The computer εyεtem of claim 11 wherein εaid toolε operate in parallel to permit the concurrent operation of each of εaid tools. 15. The computer system of claim 9 wherein said user interface includes means for dynamically updating an activity window in response to operations performed by said system. 16. A method, within a data processing syεtem, for developing proceεε oriented systems comprising: formally deεcribing a functional proceεε through a graphical language; converting said formal process description into a processor understandable format; communicating development progress to a user; satisfying conditional requirements inherent within εubprocesseε of εaid proceεε; indicating εaid satisfaction of said conditional requirements; executing taskε deεcribed by each of said subproceεεeε in parallel; and stopping said execution upon completion of each subprocess. 17. The method of claim 16 further comprising the step of mapping the activitieε into a hierarchy of εubprocesses in order to perform the activitieε in parallel. 18. The method of claim 16 further comprising the step of defining ruleε repreεenting expressions of said conditional requirementε inherent within εaid εubproceεεeε. 19. The method of claim 16 further compriεing the εtep of analyzing said formal procesε deεcription. 20. The method of claim 16 further compriεing the step of interpreting said formal procesε deεcription. 21. A εyεtem for providing interactive support for the development of a computer program comprising: means for εtoring a formal deεcription of a proceεε which deεcribeε εaid development in language underεtandable and εtorable by a computer; meanε for generating a menu of choiceε, each of εaid choiceε conεtituting a εuggeεtion regarding the actionε relevant to said development; means for selecting one of said choices; meanε for reεponding to said choice selection by initiating at leaεt one of a group of εyεtem tools; meanε for tracking operationε performed aε a reεult of εaid system tool being initiated by monitoring and storing each event produced by the tool relevant to said development; meanε for interpreting each of εaid operations performed by said system tool according to the description of said process; means for automatically initiating others of said tools in response to results forwarded from said interpretation means and said tracking operationε meanε; and meanε for providing feedback to a uεer. 22. The εyεtem of claim 21 further compriεing means for dynamically updating an activity window in responεe to εaid initiation of εaid system tool, said dynamic update permitting εaid user to respond. 23. The system of claim 21 wherein said proceεε εtorage means further stores information units described by the subproceεε unitε contained within εaid deεcription of εaid process. 24. The εyεtem of claim 23 further compriεing meanε for manipulating information unitε deεcribed by εaid εubproceεs unitε by said system toolε. 25. The system of claim 24 further comprising means for performing consistency checks among information unitε after εaid manipulation deεcribed by εaid subprocess units by said syεtem tools. 26. The system of claim 25 further comprising means for reporting proceεε errorε discovered by said conεistency check means. 27. The system of claim 21 further comprising means for browsing. 28. The system of claim 27 wherein said meanε for browεing compriεeε: means for searching and retrieving objects from within a data baεe aεsociated with said developing computer program; meanε for εelectively viewing said objects retrieved from within εaid data baεe; means for εelectively manipulating said objects within said data base; means for selectively initiating any of said syεtem toolε; and meanε for reporting activities performed while browsing. 29. The system of claim 21 further comprising means for independently initiating said system tools through a unix εhell level. 30. A εyεtem, within a data proceεεing εyεtem: meanε for deεcribing a functional process through a graphical language; meanε for converting εaid functional procesε deεcription into a processor understandable format; meanε for communicating development progress to a user; means for εatisfying conditional requirements inherent within εubproceεεes of said functional procesε; meanε for indicating εaid satisfaction of said conditional requirements; means for executing tasks described by each of said subprocesses in parallel; and means for εtopping εaid execution upon completion of each subprocesε. 31. The εyεtem of claim 30 further comprising means for mapping the activities into a hierarchy of εubproceεses in order to perform the activities in parallel. 32. The syεtem of claim 30 further comprising means for defining rules representing expressions of said conditional requirements inherent within said subprocesses. 33. The syεtem of claim 30 further compriεing meanε for analyzing εaid functional process description. 34. The system of claim 30 further comprising means for interpreting said functional procesε description.

Inventors: WENNMYR EINAR, WENNMYR, EINAR
Applicants: ERICSSON TELEFON AB L M, TELEFONAKTIEBOLAGET LM ERICSSON
Application year: 1993
Main classification: G06F9
IPC codes: G06F9