KR100229775B1 - A people oriented work environment tool and data processing system - Google Patents

Abstract

The present invention is directed to a method and apparatus for efficiently displaying, maintaining, and managing a project and its associated lifecycle in a data processing system used to support a human-oriented work environment. Object-oriented language environments can be used to represent projects, processes, states, transitions, and actions as objects. Process objects inherit from project objects. Transition objects inherit from state objects. This system allows the insertion of specific processes.

Description

Human-oriented work environment representation method and data processing system

1 illustrates a distributed processing system configurable to implement the present invention.

2 illustrates a data processing system implementing the present invention.

3 illustrates a static model of the present invention.

4 shows a dynamic model of a project.

5 shows a dynamic model of a process.

6 shows a dynamic model of transition.

FIG. 7 illustrates a graphical user interface representation of a system user view representing all users associated with a particular system.

8, 9 and 10 illustrate drop down menus associated with the user interface shown in FIG.

11 illustrates a graphical user interface representing a process implemented in the present invention.

12, 13, and 14 illustrate drop down menus associated with the user interface shown in FIG.

15 illustrates a graphical user interface representing a project.

16, 17, and 18 illustrate drop down menus associated with the user interface shown in FIG.

19 illustrates a graphical user interface representing ownership.

20 and 21 illustrate drop down menus associated with the user interface shown in FIG. 19;

FIG. 22 illustrates a graphical user interface representing an initiation associated with a particular user.

FIG. 23 illustrates a graphical user interface representing an action associated with a particular user.

24 illustrates a graphical user interface representing whatnext associated with a particular user.

25 illustrates a graphical user interface representing a process bulkslip.

26 and 27 illustrate drop down menus associated with the user interface shown in FIG. 25;

28 illustrates a graphical user interface representing a life cycle.

29, 30, and 31 illustrate drop down menus associated with that shown in FIG. 28;

FIG. 32 illustrates a graphical user interface representing a process from a particular project perspective. FIG.

33-36 illustrate a droop down menu associated with the user interface shown in FIG. 32;

FIG. 37 illustrates a graphical user interface representing a hierarchical view of a process. FIG.

<Description of the code | symbol about the principal part of drawing>

100: distributed processing system 106: network

10: CPU 14: RAM

16: ROM 18: I / O Adapter

20 Disk Unit 22 User Interface Adapter

24: keyboard 34: communication adapter

36: display adapter 38: display device

51, 61: ready state 52, 62: complete state

701: Windows 702: Title Bar Area

707, 1101: display area 803: process

894: Project 903: Minimize Behavior

1001: clone 1104: view

1106: selection unit 1402: open project

1403: Open Test Project 1804: Schedule

2101: creation project 2602: lifecycle

2606: Work Product Definition 3310: Containers

108, 110, 112, 114, 116, 118, 120, 122, 124, 126 and 128: data processing system

The present invention relates to a method and system for efficiently representing, maintaining, and managing a project and its lifecycle in a data processing system used to support a people oriented work environment.

Managing a project can be a logistical and bureaucratic problem. Often, policies governing the number of people, their tasks, their interrelationships, and the workflow within a project can make it difficult or even disrupt the project's success.

This problem is recognized by a particular organization and results in quality standardization that is not associated with the end product of a given project but is associated with the process used to develop this end product. An example of such an organization is the International Standards Organization (ISO) and its standard ISO 9000, which likewise draw attention to the development process rather than the developed product.

The basic idea behind the ISO 9000 standard is that the development process

(1) it must be well defined, documented, (2) repeatable and measurable, and (3) the measurement used to improve the process.

Theoretically, after the process detects and corrects an error, improving the functionality that prevents this error entirely will improve product quality.

In practice, this concept is gaining support in an industry that is increasingly beginning to pay attention to quality. In the European market, for example, many projects may not be sold without ISO 9000 certification. Such certification may be achieved based on the audit results of various members of the project team by independent auditors.

Such audits can be very laborious and time-consuming, because they know what products they produce, why they produce them, and whether they follow and understand the appropriate steps for quality control, Also, many questions are asked to prove that they can use the performance results of modifying (or optimizing) the process, and documentation is required. If an "absolute majority" of project team members pass this audit, a certificate is awarded.

Regardless of these certification requirements, it is still desirable to have some sort of tool or mechanism that monitors, supports, organizes, and manages the project throughout its life cycle. Many prior art tools have evolved in an attempt to support projects. In addition, with the advent and proliferation of computers, a number of programs have been written to help provide and manage documentation in terms of project workflow and processes.

Most of the prior art tools (e.g., KI Shell, Version 1.1, developed by Universal Energy Systems, Dublin, Ohio, September 1990) are available to support the project. It is "process" oriented in that approach. In other words, process-oriented tools focus on the flow of operations and control between them. For example, a process-oriented approach to developing software systems

(a) analysis,

(b) design,

(c) code,

(d) test

(e) delivery

Include operations such as:

Tools that support a process (or "method") oriented approach can provide a means by which actions to be defined that capture the project from one state to another are defined. For example, as a result of a test operation (if there are no significant problems), the following behavior may be "transfer", or "code", "design" or "analysis" (depending on the type of problem found). have.

Not only from a certification standpoint, but from a project team member who tries to optimize processes and reduce costs, a disadvantage of this approach is that there is a way to distinguish between actions that achieve high quality output and those that require rework. It doesn't exist. In other words, there is a need to track both "foward" and "backward" movements through the process to optimize the process.

A simple solution for this is to add an attribute to each action that indicates whether this action represents a "forward" action or a "reverse" action. However, the solution by this approach tends to confuse the definition of a life cycle model with a large number of extra activities. The previously cited US patent application (AT9-92-077) discloses a solution in which a "transition" through the lifecycle is no longer represented by itself, but from one state to another. This flow is assumed to be bidirectional. Each transition has a separate associative action that causes the control flow to advance to the target state and back to the source state.

The main advantage of this solution is that the person involved in the process thinks that the work production is "completed" in his or her process and either moves to the next state, or finds an error that prevents the completion of the work and "rejects" the work. It makes it possible to move back to a previous state. By having a limited number of transitions with specific meaning, processes can be more easily defined, performed, managed, and optimized.

However, this solution goes one step further and solves other problems present in prior art systems in which the system is based on a "frame". Frame-based behavior includes all the logic that represents the policy that governs (permits) the state transition behavior and the code that together causes the state change in a single program.

The more difficult it is to specify, test, and maintain, the more complex the program associated with the frame-based system is, and the policy and state change behaviors are typically "owned" by the people who define the process. Typically, the management team owns a policy that allows for a change of state, while the technical team tends to own a specific action that causes the state change. For example, an administrator may decide to have 99% of the code tested to move to the final state, but the technical team is responsible for defining the "build and package" needed to prepare for delivery to the customer. .

The solution disclosed in U.S. Patent Application (AT-92-077) allows a third "program fragment" associated with each transition representing a "guard" condition that must be prioritized before a state change is executed. Was. Also, when control is passed to the next state, the fourth program fragment has determined a list of legitimate "owners" with the responsibility to complete the actions associated with that state. In addition, guard conditions and owner actions served as the basis for defining the policies associated with the process. It is not only necessary as part of the ISO 9000 certification audit to describe and understand these policies, but it is indispensable to develop high quality products. Indeed, the performance of optimizing processes by blocking backwards behavior is more dependent on the ability to enforce guard conditions and / or control over who owns ownership than to modify state change behavior. Thus, it is expected that the process change will be more local when such a solution is used.

However, this “extended” process-oriented approach is not sufficient because the system only tells the project team what they need to do and helps them understand what they are doing in terms of the product they are trying to produce. Because it does not give.

In many cases, another problem is that a project has a very complex lifecycle to manage the interaction between multiple concurrent operations. Prior art systems based on frames / methods rely on certain kinds of frames such as "sequences", "alternatives" and "parallel operations" to handle this environment. In some cases, the type of operation and the number of operations may not be accurately defined in advance. In any case, the lifecycle may be so complex that the process may not be understood or handled.

Another problem is that often the state associated with a project can be complicated. That is, a given state, such as "analysis", may be broken down into more detailed states, such as "plan", "analysis", "review", "rework" or "accept".

Another problem is that many states, except one or two operations, often have very similar complex breakdowns. For example, "analysis" and "design" may be the same except for the second action involved (in terms of "analysis" rather than "design").

In short, this problem makes the system very complex and redundant and makes it difficult for the system to be set up first, and then maintained and / or optimized.

The object of the present invention is to solve this problem.

The object of the present invention is to assist in organizing and managing a project using a computer implemented interface that defines the project in terms of the work products of the project components and the lifecycle of controlling these configurations in a clear and unambiguous way. There is.

The invention is preferably implemented in an object-oriented programming language environment in which various parts of the invention are composed of objects. As is well known to those skilled in the art, this configuration makes the program relatively easy to modify, and the operation and interrelationships of the system components can be more easily described. For more information on object-oriented programming, see Object-Oriented Technology: A Manager's Guide, Taylor, D., Addison-Wesley 1994 and Object-Oriented Analysis and Design, Booch, G., 2nd, which are hereby incorporated by reference. Edition, The Benjamin Cummings Publishing Co. See 1994.

Objects within these environments can consist of projects, work products, states, and transitions. The project represents the final product and optionally consists of the working product. The project has a lifecycle defined by state, the progression through this lifecycle is controlled by the transition operation, which project is guarded according to US patent application (AT-92-077), which is incorporated herein by reference. , Has an associated code fragment describing the owner, forward and backward movement through the lifecycle.

In addition, projects are defined by other projects and can depend on or be organized into other (sub) projects. States are a kind of subproject in their own right, the difference being that they function to identify transitions (actions) that can occur within the state of the project (or subproject) lifecycle. Transitions are also a specific kind of project, which keeps the code necessary to cause a state change.

In addition, the "default" process for all complex projects (i.e., subdivided projects) assuming that the lifecycle associated with the "source" and "component" work products follows (in parallel if project resources are allowed). Is assumed.

The present invention preferably provides a computer-assisted environment that informs members of an action project what actions should be performed. This information is typically communicated to project members in any one of a variety of user interface techniques utilized within computer systems. An example of such a user interface may be a graphical user interface, such as a "windows" program, which the user "clicks" through icons and various other windows to determine the tasks and tasks required for the user. Allow to do The present invention does not confuse a particular user with unnecessary information about a user's task, but rather focuses on the responsibility for that particular user, such as conditions, details, states, identities and assignments. Configure project information.

Thus, through this user interface, the user may utilize the summarized components of the present invention to define project deliverability and lifecycle, and may use the system to ensure that the process is done as defined.

The advantage that a project can be defined and achieved by another project is that it can be reused by another designated project without redefining the details.

The benefits that a product can achieve by being composed of other (sub) projects can be defined in terms of the main intermediate work product being developed, and it becomes easier to understand what is being developed at each stage using the system. In other words, the reuse described above can be utilized even within the component.

The advantage that a project can achieve by relying on another project is that as dependencies between work products are explicitly made, the system can automatically perform sequential actions when required (ie, "source" work products). This is developed first, then components are developed), which allows parallel operation when no dependencies are identified, making it easier to define and optimize the process.

The benefits that can be achieved by dealing with states such as projects are that these states can take advantage of the performance that can be defined by other, more general states, reuse is also used, and the definition process can be taken at any granular level. As such, these projects can be easily broken down into associated work products and support the appropriate lifecycle for combining them.

The advantage that a project can achieve by dealing with the same transition is that if necessary, these states can be broken down and, if required by the system's policy, can support complex lifecycles with intermediate work products. The system of the present invention not only utilizes reuse, but also allows the definition and execution of "long running" transitions.

In order that the detailed description of the present invention may be better understood, the characteristics and technical advantages of the present invention have been described in a broad, broad manner. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, those skilled in the art will fully appreciate that the present invention may be practiced without these specific details. As another example, well-known circuits are shown in block diagram form in order not to obscure the present invention in unnecessary detail. In most cases, it is not necessary to achieve a thorough understanding of the present invention, and details of timing considerations and the like have been omitted when the field is well known to those skilled in the art.

Referring to the drawings, the components shown are not drawn to scale, and the same or similar components are denoted by the same reference numerals in each of the drawings.

Referring to FIG. 1, a distributed processing system having data processing systems 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and 128, to which these systems are connected in a conventional manner ( 100 is shown. The network 106 may be a national or international data transfer network such as a local area network, wide area network or the Internet.

Referring to FIG. 2, a representative hardware environment is shown and, in accordance with the present invention, having a central processing unit 10, such as a conventional microprocessor, and a number of other devices interconnected via a system bus 12. A typical hardware configuration of data processing system 108 (see FIG. 1) is shown. The system 108 shown in FIG. 2 busses peripheral devices such as random access memory (RAM) 14, read-only memory (ROM) 16, disk device 20 and tape drive 40. Input / output adapter 18 connected to 12, and other user interfaces such as keyboard 24, mouse 26, speaker 28, microphone 32, and / or touch screen device (not shown) A user interface adapter 22 that connects the device to the bus 12, a communication adapter 34 that connects the system 108 to the network 106, and a display that connects the bus 12 to the display device 38. Adapter 36.

Referring to FIG. 3, there is shown a model depicting the present invention in a rumbaaugh style. Rumbo marking is a technique well known in the art and is described by James Rumbaugh, Michael Blaha, William Premerlani, Fredderich Eddy, and William Lorensen. Reference is made to Object-Oriented Modeling and Design, which was invented and published by Prentice Hall, 1991, which is incorporated by reference in its entirety.

3 shows a static model of the process for managing the project lifecycle. The purpose of a static model is to illustrate the static organization of projects, users, actions, and processes involved in a project lifecycle management system. The main object of interest is project 301. In discussing the project 301 later, it is desirable to note the relationship that the project 301 has with other objects in the system that will drive its operation. Project 301 may include (1) "initiated" by user 301, "(2) owned by user" 303, "and (3) a list of work products that are substantially different projects. (4) have a list of projects that they are waiting on (i.e., dependent), and (5) conversely, having a set of projects 301 (i.e., projects supporting them) that should be notified when completed. Has characteristics. In addition, project 301 is associated with a history of operations 302 that occurred during the lifecycle of that project 301. In addition, project 301 is defined by process object 304 and may also be controlled by a given bed 305 within that process 304.

Explaining the difference between the "initiated" and "owned" relationship for user 303 described above, "initiated by user 303" substantially reduces project 301 from process 304 or other means. While referring to a user 303 that was created, "owned by a user" is the user 303 (ie, the actual owner of the project 301) who is responsible for moving the project 301 through his lifecycle. ).

Conversely, what is "initiated" for a given project 301 is that user 303 can have a set of projects 301 initiated. In addition, user 303 may own zero or more projectors 301 moving through the lifecycle at a given point in time. As the project 301 moves through the lifecycle, the user 303 executes a specific set of operations 302 to perform this move. These actions 302 are also recorded as being associated with the user 302.

Although operation 302 is associated with project 302 as part of its history, operation 302 is optionally defined by transition 306 in the lifecycle of process 304. In addition, operations 302 are all optionally performed by user 303. This operation is optional because the system can substantially perform the operation 302 directly, without the user 303 having to explicitly initiate this operation. Label 307 represents a factorial relationship that indicates that operation 302 is substantially one type of project 301. This factorial 307 can benefit from the performance that the operation 302 has substantially a lifecycle associated with it, as well as the "waiting", "notification" of other projects 301 or operation 302, and the like. It includes all properties of the project 301, such as the associated "retention of work product" and "controlled by a given state 305". This allows the user 303 of the system to create very complex processes if needed.

Process 304 also inherits from project 301 by factorial 307, meaning that process 304 can also be recognized as a project 301 moving through its lifecycle. For additional properties where process 304 is superior to project 301, process 304 will define zero or more projects 301. That is, the purpose of process 304 is to define general attributes, relationships, and the state and lifecycle of project 301, while project 301 itself is the actual project 301 as it moves through its lifecycle. It means keeping the example variables. Project 301 will have a "wait" and a "notification" relationship that joins the project 301 together through a dependency relationship. In process 304, there will be an analog that performs "input from" and "output to". That is, a given process 304 may provide output to substantially other processes 304. Conversely, process 304 can receive input from another process 304. This relationship is then the type of project 301 in which "input from another processor 304" represents a "input from" relationship of the project 301 defined by the processor 304. To imply that it should wait.

The "output to" relationship is an analog to "notification" in project 301. That is, when project 301 is defined by process 304, the process 304 that provides output to other processes 304 may then terminate those processes 301 and no longer process 304. You will be notified to not wait.

In addition, the project 301 has a work product here, and the process 304 includes a definite analog called a "work product definition", which is why the process 304 is substantially a subwork product. Divided by, when project 301 is defined by process 304, if there is a work product definition associated with project 301, these work product projects are also created and at the same time these projects are their process 304. It suggests that you will have to go through. An important aspect of these four components from the defining aspect of process 304 and the practical example aspects in project 301 is that these components allow a user to define a particular process 304. That is, although process 304 has not been discussed yet, without having a defined lifecycle, a user can control and have a lifecycle of project 301 in a substantially specific manner. This is a very important factor for ISO 9000 compliance where we can have a good understanding of the work products that make up the project 301 and the dependencies between the projects 301, but the state that leads to development 305 and There is no good understanding of the very specific lifecycle of transition 306. This allows the user to build and proceed with process 304, which then optimizes the process.

For the lifecycle, process 304 includes the lifecycle of state 305. State 305 also has a factorial relationship 308 to process 304. That is, state 305 is one kind of process 304. This fact is important in that state 305 can have defined inputs and outputs, and can have defined detail products. And one of the most important characteristics is that as the state 305 has a sublifecycle, the user can build a very complex lifecycle representing the development of the project 301 in a phased manner, and also a lot of reuse. Can be obtained, which is described below.

Returning to process 304, process 304 may have a superclass. Conversely, process 304 may also have subclasses. This relationship allows the user to build hierarchies of process 304. This relationship is also how the system provides a high degree of reuse that has not been seen in any flow control system of the prior art.

From the point of view of state 305, state 305 is included in some process 304 lifecycle, and by inheritance 308 allows state 305 to be a process 304, so state and substates are There may be a hierarchically nested process 304 having. Since state 305 is supposed to inherit all attributes of process 304, by process 304 inheriting from project 301, state 305 inherits all attributes of project 301, and state 305 There are only a few specific attributes associated with). The first is that state 305 can control substantially zero or more projects 304. That is, project 301 will be in a given state 305 within its lifecycle, and thus this state 305 will maintain a list of those projects 301 currently present in that state 305. This is very useful when the user wants to scan through the system and know which objects and which projects are in the ready state. This provides the user with a quick way to discover the project 301, which may help to move these projects through the lifecycle of these projects.

Another important characteristic is that state 305 can have multiple transitions 306. An important fact about state 305 is that state 305 is a collector of transitions 306 that may occur during that state 305. Since transition 306 is substantially the control flow from one state 305 to the next, transition 306 can also be a type of state 305, the main purpose of which is current state 305. And attach the two states 305 together from one state to the next state 305, and also maintain a list of information as disclosed in US Patent Application (AT9-92-077), which is incorporated by reference. ) And a code fragment that takes a complete action indicative of a forward or backward direction, i.e., a forward movement through process 304, and a return action indicative of a backward movement through process 304.

Transition 306 is similar to process 304 in that transition 306 is state 305 and state 305 is a type of process 304. The main difference is that transition 306 defines the behavior. Thus, in the exemplary aspect shown in FIG. 3, there is a complete loop between the user 303, the project 301, the operation 302, the process 304, the state 305, the transition 306, Operation 302 is connected to process 304 in a relationship defined by project 301, defined by transition 306, and state 305 controlled by project 301. In a relationship.

Referring to FIG. 4, a dynamic model of project 301 is shown. The purpose of the dynamic model is to show the control of the motion associated with the object shown in FIG. 4 is associated with an example of a project 301 object as shown in FIG. Actions associated with project 301 create a transition or method (which causes a new project 301 to exist), retrieve (retrieve various attributes of project 30), and update (various associated with project 301). Update properties) and break down (which causes project 301 to be removed from the system). These methods are merely primitive methods associated with any object in an object oriented system, and there may be certain overrides for the operations associated with these methods to be described as part of the description of FIG.

There are some additional operations that do not exist in this primitive set. For example, the "waiting" transition or method is two cases: the actual project 301 is added to the "wait" list of a given project 301 and the work of the project 301 given the new project 301. Called when added to a product list. In this case, the "wait" method is called on a given project 301.

"Notification" is the inverse concept of "waiting." Each time project 301 is completed, project 301 sends a "notification" method that is called and taken on that project 301 to work in the "notification" list in project 301 given project 301. If it is for a product and for the whole product, the "notice" method is included. "Notification" and "waiting" are the inverse concepts of the same relationship. While "notifications" and "waits" can be recognized as transitions or methods that are executed automatically, there are two ways to cause explicit movement throughout the life cycle of the project 301, namely "complete transitions" and "return transitions". And the method is suitably adjusted to take one forward and backward in a process as described in US patent application (AT9-92-077).

Another transition is a "whatnext" transition, which describes whether an operation can be performed for a given project 301 at a given time. This is useful when building a "whatnext" view from a user to know what project 301 owns and is currently waiting for some kind of action from that user.

Given the set of operations described above that can be invoked on a given project 301 at any given time, the purpose of the dynamic model is the specific behavior of each of these methods depending on the global state of the lifecycle model of the project 301. To describe. 4 shows a possible default process 304 model for any given project 301. The key point in FIG. 4 is to illustrate the adjustment behavior of a particular default process 304 with a process 304 explicitly specified by the user in this figure. This has the advantage that it allows a user to quickly build a project 301 and process 304 from scratch without having a properly predefined process before work commences.

In general, a user may consider that there are three major status categories, namely three major categories that are automatic, explicit and inactive. The first automatic state, i.e., the input wait 41, indicates that the project 301 has a list of projects 301 in its "wait" list that must be completed before another action on that project 301 occurs. Having a project 301 in the "waiting" list requires that all pending projects 301 be in a completed state before additional work takes place.

The next automatic state is the work product waiting state wait, which is given a state that may have a defined work product when the project 301 is included in this state. This means that project 301 cannot be completed until all work products have been completed. This does not prevent the work that occurs in parallel on the project 301 before these work products themselves are completed. This is one of the dynamic differences between the "wait" and "notify" relationships and the work product relationships between projects 301 and other differences beyond the containership versus reference perspective. In the work product standby state 43, once all work products are completed, it is considered that another progression on the project 301 may occur.

Next, there are two explicit states. These states are the states of the dynamic model of the project 301 that the user is expected to cause a state change explicitly through a return or completion transition. The user completes the state change to the next state and returns the state change to the previous state. In the "in progress" state 42, it is indicated that the project 301 has a complex lifecycle that must be followed before completion of the project. The ready state 45 is in the next explicit state (and completion is required to be moved to the next state). In the ready state 45, all pending projects 301 are completed, all work products are completed, and if there is any complex lifecycle, the complex lifecycle will also be completed. Thus, in the ready state 45, the project 301 is ready for review and is completed by the project 301 team.

Then there are two inactive states. When the project 301 is in the ready state 45, a completion state 46 occurs, and when the project 301 is completed, the completed method in the ready state 45 is called. Thus, completed state 46 indicates that project 301 completed successfully. The cancel state 44 occurs whenever the project 301 returns back through the first state in the process 304. That is, in any of the input wait 41 states or work product wait states 43 of the progress 42 in the very first state of the complex life cycle, if such a complex life cycle does not exist, the project 301 is cancelled. do. The concept of cancellation of project 301 is that there is no intention to complete the lifecycle.

In summary, the input wait state 41 indicates that there is a project 301 that is substantially waiting for completion and that this project 301 depends on the input wait state 41. Progress state 42 indicates that state 305 exists in the complex lifecycle of process 304 associated with this project 301 awaiting completion. Work product wait state 43 indicates that there is a work product associated with this project 301 waiting to be completed. The ready state 45 indicates that the project 301 is in a substantially ready state for completion, and that all work associated with that project 301 is in the ready state. The canceled state 44 indicates that the project 301 has no intention of completing. And completion state 46 indicates that project 301 has completed successfully.

Project 301 is created in the input wait state 41 where this particular project 301 is waiting when the project 301 is substantially present. The "wait" list is non-null and will cause the project 301 to be created in this state 401. Once in this state 41, the atmosphere 402 will basically have no effect. The control flow will stay in the input wait state 41. Likewise, completion transition 448 has no effect and returns flow control back to standby input state 41. Likewise, the "whatnext" transition 406 indicates whether or not this project 301 is waiting for any kind of action from the owner, and the "whatnext" transition 406 is not associated with a particular project 301 at this point. It will return an empty list indicating that nothing is done on it.

Since the input wait state 41 is one of the automatic states, the notification transition 403 will be a transition to automatically move the control flow in the process 304. The "notification" transition is generally activated or initiated by the project 301, and this particular project 301 follows the "notification" transition. This transition is either one in the "wait" list of project 301 or one of the "work product" list of project 301. "Notifications" has two different effects possible, which depend on the size of the "wait" list. The notification transition 403 causes the control flow to be reversed to the input waiting state 41, and if the list is not yet empty after removing the project 301 which is notifying this notification project 301 from the list, this list is It remains in the input waiting state 41. This is somewhat accurate and if there are other projects 301 still waiting, notification transition 403 simply removes one project from the list by indicating that the project has completed. However, if the list resulting from removing the notification project 301 is empty, a notification transition 401 occurs. That is, a notification transition 401 may occur if another project 301 is not waiting. In this case, the following state becomes relatively complicated. This state may proceed to a progress state 42, a work product wait state 43, or a ready state 45. As mentioned above, if there is a complex lifecycle, the notification 407 will take a progress state 42, with the project 301 where no complex lifecycle exists or the complex lifecycle is already completed but not yet completed. If there is an associated work product, notification 409 will take the work product waiting state 43. Only when there is no state in the incomplete lifecycle or when there are no incomplete work products, the notification 411 will take the flow of control from the input wait 41 to the ready state 45. That is, if everything is ready after the pending input is complete, it will enter the ready state immediately (transition 411).

Project 301 is created in progress 42 when there is no input pending. All of these projects are completed or none of them are in the list. In this case, there is a complex lifecycle to be performed. In this case, project 301 is created in several lifecycle states described below. This transition is generation 413. The generation transition 413 will generate the project 301 in the progress state 42. Progress state 42 is an explicit state, meaning that a return or completion transition needs to be moved in the lifecycle. In this case, the notification transition generally has no effect, so the notification transition 444 will just send the control flow directly to the state 42 without any effect. Waiting for transition 414 may have an effect when a new project 301 is associated with this pending project 301. If a "wait" occurs for the work product, there is no reason for the control flow to return to the input wait state 41. Thus, transition 414 associated with "waiting" will cause the ongoing control flow to return to the current state, while if a valid dependency in progress is added to project 301, "waiting" means that transition 408 is waiting for input. Will return to (41). In this case, the wait will return to the input wait 41 state.

The action associated with the "return" transition depends on the actual lifecycle. If the "return" transition is in the first state of the lifecycle, the "return" transition will operate as described in return transition 419 and project 301 will be moved back to the canceled state 44. That is, if a project is returned at the beginning of project 301, the project will be returned to the initiator. If the "return" transition is not present in the first state 305 of the lifecycle, the return transition 447 will remain within the control of the progress state 42 at the high level, and the "control by" link is in the lifecycle. A reset to the previous state 305 is taken. This behavior is determined by history. This is essentially similar to the operation supported through operation 302 and the operation of determining which state 305 is performed or passed through to return control flow to that state 305. As shown in US patent application AT9-92-077, incorporated herein by reference, a "return" transition is performed in return transition 447 or return transition 419 to generate any control flow that may occur. Has a specific undo action associated with itself that previously caused an action to be undone.

"Complete" transitions are very similar in terms of forward direction. There are three different possible states, where there may be a "complete" transition, depending on the state 305 of the project 301. In other words, if project 301 is in the middle of a complex lifecycle, completion transition 415 only allows control flow to remain in progress 42. However, when a particular transition 306 is performed, the detailed status is indicated by changing the "control by" criteria associated with the project 301 to the next associated state 305. If many transitions 306 have occurred from state 305, the "complete" transition will provide a list showing the set of transitions that can be invoked, after which the user can select one transition, and the selected transition is performed. Will be.

In the last state 305 of the complex lifecycle, there is a transition 305 having no next state 305 associated with it, and the control flow proceeds to one of two states. If there is a work product that has not yet been completed, the control flow goes to completion 417 to work product wait state 43. Once all work products have been completed, the control flow will proceed directly to the ready state 45 via the completion transition 445. Transition, in any case, through completion 415, or completion 417 or completion 445, as disclosed in U.S. Patent Application (AT9-92-077), herein incorporated by reference. Has a guard associated with itself to determine whether or not the condition is required for the action to occur. Thus, a "complete" transaction is possible because of an unpassed guard.

A "whatnext" transition 418 for the team returns a list with a particular project 301 therein. This indicates that there is work to be done for this project 30.

The generation transition 435 may include a work product in which there is no waiting project 301 and no complex lifecycle that is not completed, but a work product exists and this particular project 301 is not yet completed. At that time, control flow is initiated in the work product waiting state 43. Thus, in this case, the project 301 will begin in the work product waiting state 43 via the transition 435. If this work product standby state 43 is an automatic state, the operation of "waiting" and "notification" has a great effect. Because the user does not allow this project 301 to complete directly, the completion transition 424 may not have an effect in this regard. The completion transition 434 will automatically move to the ready state 45 through the notification operation. At this point, a notification occurs when each work product associated with the project 301 transition to completion status 46 is present and they invoke a notification transition 430 or 432. Called notification 430 is taken when another work product remains and is completed. Called notification 432 is taken when the work product to be completed no longer exists. In the case of notification 432, a transition or control flow is taken for the ready state 45. Unlike the completion operation, which has no effect, the return operation will cause a control flow to transition state 416 through transition state 42 or transition 427 to cancellation state 44. Return transition 416 is taken when there is a complex lifecycle completed before entering work product wait state 43. Work product wait is returned to canceled state 44 when there is no such lifecycle associated with project 301. Atmospheric transition 410 also has two possible effects. When a new project 301 is added to the work product associated with that project 301, the wait returns control flow only through 429 to work product wait state 43. That is, only one or more work products involved are present. However, if the new project 301 described above is not added to the work product associated with the project, but instead is added to the actual waiting list (ie one of the inputs of the project 301), the new project 301 is still If not complete, the control flow will proceed to input wait state 41.

"Notifications" also have two similar effects (or two flows that may occur). Notification 430 indicates that the particular work product associated with project 301 has completed, but this product is not the final work product that needs to be completed. Notification 432 occurs when the final work product associated with project 301 is complete and this transition 432 causes a flow of control to the ready state 45.

In the work product standby state 44, no explicit action may be taken that may be taken by the owner of this particular project 301 except for watching the work product accompanying it. Thus, in this case, "whatnext" returns as an empty list.

Project 301 is created in ready state 45 when there are no pending projects 301, no work products that have not yet completed, and no lifecycles that have not yet completed. Thus, the overall effect is that some projects 301 will only be location owners or reminders, so these projects will be created and taken directly in the ready state 45. Thus, the transition 436 causes a direct control flow for the ready state 45.

The " whatnext " transition 437 associated with the ready state 45 is relatively simple, and this transition can also be an explicit state, returning a list with a particular project 301 therein, allowing the owner to specify this particular. Responsible for substantially completing the project 301.

Given the " waiting " and " notification " actions that can occur from the automation basis, these actions will now be described. When a new project 301 is added as a dependency (ie as an input or a work product), the "wait" transition occurs again. The type of dependency added and the state of the project 301 will result in a particular control flow. If any type has already been added, the wait 449 will return the control flow to the ready state 45, and no change exists in the state of the project 301. If a valid input dependency that has not been completed via the "wait" list associated with the project 301 is added, a wait transition 412 is called, causing it to return control flow to the input wait state 41. Finally, when an incomplete work product is added, wait transition 433 is invoked, thereby causing the control flow to proceed to work product wait state 43.

Completion transition 438 has one purpose in the ready state 45, which is to allow the control flow from the ready state 45 to complete. This is the minimum amount of work performed by the user, and there will always be an explicit action. That is, each time project 301 is created, it should be in the completed state 46 or the canceled state 44. The cancel operation occurs by performing "return". When the return transition 425 is performed, the transition causes the control flow to proceed to the canceled state 44. However, return 425 proceeds to canceled state 44 only if there is no explicitly defined lifecycle state entered. If there is a complex lifecycle performed, the control flow returns to the final state in that lifecycle entered. This return will return the state or control flow to transition state 42 via transition 446. Completion state 46 is one of inactive states, where " whatnext " transition 443 only returns an empty list.

Since project 301 has already been completed, completion transition 442 is ignored and has no effect. "Notify" and "Wait" have no effect on state 46. This may be shown more explicitly by the transition update 440. This transition 440 is included to indicate that no update is allowed in the complete state 46. The user cannot add these to the project 301 once the "wait" or other work product is in the completed state 46. In this case, the user must perform a return transition 439 to bring the control flow back to the ready state 45. This operation is a way for the user to update or add a new "standby" project 301 or new work product, which may then cause a control flow in the ready state 45 as described above.

Once project 301 is created, the project is not destroyed until one of the inactive states is reached. Destruction transition 441 can only occur when project 301 does not have a dependency thereon. However, as mentioned above, if there are no output dependencies, it is possible to remove the work product of another project.

The canceled state 44 is very similar to the completed state 46 in that it is inactive 45. However, another action may occur, and similar to the completion project 46, which may return back to the ready state, the cancel project 44 may be reopened. Complete, update, and return operations are ignored, as shown by update transition 420, return transition 424, and completion transition 422. These actions indicate that none of these actions occur during the particular canceled state of project 301. There are only three practical actions that can occur for the project 301 during the cancel state 44. These operations may be "searched", which does not appear explicitly in any of these states, and may also be "reopened" or "destroyed". This "destruction" causes the destruction transition 423 in that all contained work products are destroyed and the project 301 is removed from the "wait" list of all projects 301 in the notification list of this project 301. Very similar to)

There are four "reopen" types that bring project 301 back to one of its active states. When there is still an input waiting to be completed in the "wait" list, the reopen transition 404 is called by "reopen" causing the control flow to proceed to the input wait state. If there is a complex lifecycle, reopening 421 causes the project 301 to "reopen" to progress 42. When there is no lifecycle or when the lifecycle is complete and the project 301 is reopened via 428, the control flow will proceed to work product wait state 43 only if there is a work product waiting to be completed. Finally, reopen transition 426 occurs when all basic operations are completed on project 301 and ready to complete in completion state 46, after which reopen 426 causes control flow to be canceled in state 44. The process proceeds to the ready state 45.

Referring next to FIG. 5, process 304 inherits project 301, so the dynamic model is basically the same as shown in FIG. FIG. 5 illustrates only the relatively complicated life cycle of FIG. 4. The important thing is still complicated. This only adds some additional behavior. In the ready state, shown as 45 in FIG. 4 and 51 in FIG. 5, an additional transition opening 501 used to cause a new project 301 to be created by a given process 304 model. This exists. That is, the project 301 defined by this specific project 301 is generated. The overall effect of this project is to cause the lifecycle model of process 304 to be examined for transitions 306 that do not have a current state 305 associated with them, as discussed in transition 306. If more than one model exists, a list is provided to the user for selection. If there is only one model, it is automatically taken and the object can be controlled by that particular state. In the ready state 51, this opening 501 is substantially similar to a test. Only when process 304 is completed is considered to be in production mode, in which open 501 allows substantial operation to occur. One attribute discussed in connection with each project 301 shown in FIG. 3 is a test attribute. This attribute indicates that this project 301 is just a test project 301 for the purpose of determining whether the process 304 is complete and ready for use in production.

Next, referring to the completion state, shown at 46 in FIG. 4 and at 52 in FIG. 5, two transitions are shown, an open transition 503 and a test transition 502. Open transition 503 is as discussed in open 501 except that the test attribute is set to the default. In other words, it is assumed that a production level project 301 exists at this point. This helps explain why the test transition 52 is added so that the project 301 can be created in test mode while the process 304 is in the completed state. Once the process is complete, no further updates occur except during the ready state 51. At the point of preparation 51, the process is ready to be tested, and when the process is in the completed state 52, at the point of completion 52, the process is substantially used to generate the actual project 301. Can also be used to optionally test project 301.

Referring now to FIG. 6, a dynamic model of transition is shown. Transition 306 is one kind of state 305, and thus one kind of process 304, and thus one kind of project 301, in which transition 306 inherits the model associated with project 301. , Also means to inherit process 304. Therefore, it is important to ignore certain states and transitions. The same two state preparation 61 and completion 62 are ignored similarly to that performed in FIG. Open transition 601 causes an operation 302 to be attached to or associated with a particular transition 306. The difference here is that open transition 601 is not directly performed by any user 303. Instead, an open transition 601 is performed during the completion transition of the dynamic model of the regular project, in particular during transitions 415 and 417, which causes an action 302 to be generated and displayed in the history as it uses that particular transition. Will be. The test transition 602 shown in completion status 62 may be performed by the end user. The purpose of performing this test transition is to perform any operation 302 associated with the transition 306 itself, and does not allow any substantial motion log records to be generated for the history of the project 301.

FIG. 7 shows a graphical user interface (GUI) representation of a system user's view and displays all users associated with the system. For example, the system may include icons that allow various components, for example, automatic closing of window 701, maximizing 710 of window 701, and minimizing or iconifying 711 of window 701. A window 701 having a title bar area 702 having a structure is shown. The window 701 may also have a scroll bar area 712 that scrolls the screen to the top and bottom 713 of the screen and, if necessary, to the left 714 and the right 715. The window 701 also has a menu bar area 708, which in this particular example includes within this window 701 the menu associated with the view 703, action 704, selection 705. It may include functions that can be used. Most of all windows 701 include a help button 716, which may provide a touch sensing help function 701, which may be a particular window 701 and / or this window ( 701 is specific to the selected object inside. In addition, in most windows 701, there are some major display areas 707, called fields. This field 707 may have icons arranged on the field. In this particular example, there is an icon 706 representing the user Joe.

The operation is called in two different ways. One way is to pull down the menu bar and select a function within it. However, an icon such as Joe 706 can also be manipulated directly by a selection device such as a mouse. In general, there are four actions that a user can perform on the icon 706 associated with the display area 707. The first operation is to move the icon 706 onto the display area 707. This action can be invoked through a hold type action such as pressing the right mouse button. The menu may also be associated with the icon 706. In this case, the menu can be called by pressing the left button of the mouse, after which one item on the menu is selected. A third function that can be called directly via icon 706 can be selected for use in a selection button associated with menu bar 708, for example. This selection can also be accomplished by pressing the left button of the mouse. Finally, a default action may be called for the object in the user case. Perhaps this default behavior may be open for objects that can own or create user configurations. In this case, this operation can be accomplished by placing the cursor on top of the icon 706 and then double-clicking either button.

In the case of FIG. 7, Joe 706 represents a particular user in the system, and the default behavior is to be able to open a project owned by the user to be displayed. However, as shown in the pull down view of FIG. 8, this project can easily be some other view or can be user configured.

When the user selects the view pull down menu 703, a view typically associated with the system is shown in FIG. The button 801 for the view may be attached to the menu 703 for the window 701 shown in FIG. 7 or 11. The main idea is that there are three possible views associated with this system. Button 802 provides a view of all users associated with the system process. Button 803 displays a view of all top level processes, where the top level indicates that this process 304 is not included inside any other process 304. Thus, the project button 804 to which a project with an undefined process 304 is associated allows for a particular process associated with the project 301. If an object is included, it will appear inside the selected object's view (see Figure 11).

9 shows a pull down menu of operation 704 associated with a user view of the system. The function of this pull down menu is to provide actions that can occur regardless of what is selected on the screen. For example, generation 901 can cause a new user to be created and associated with the system, and closure 902 can cause window 701 to be closed. Minimization 903 and Maximization 904 are also shown.

10 shows a selection 705 menu bar pull down with replica 1001 and destruction 1002. These operations are also operations that can be performed on all objects of the field 707 that can be selected. In the case of FIG. 10, it is expected that if no object is selected, the menu bar item, which is a visual indication that the action cannot be selected properly at this point, will be "grayed out".

Referring to FIG. 8, if the view has already been opened, the view may not be regenerated but rather moved to the top, or may return to normal size if the size of the view is maximized or minimized.

Thus, given the window 701 shown in FIG. 7 and the pull down menus shown in FIGS. 8, 9 and 10, the view menu pull down 703 is called and this pull down menu is assigned to the user 802, Process 803 and project 804 can be displayed, and the process 803 is selected as an operation. This allows to determine which top level process 304 is in the system as described above and will display a window 701 to be opened for FIG.

In FIG. 11, the same basic processing as shown in FIG. 7 is used. The main difference is that the view shown in title bar 1102 shows the process. Also, the view menu bar button will be the same as shown in FIG. The fields in window 1101 will show icon representations of various top-level processes 304 described in the system, eg, "bucksilp", "engineering change". Bucksilp 1103 will then be used to describe what happened when the user selects a given icon, as shown in the direct manipulation section above. The action pull-down menu shown in FIG. 12 is similar to that shown in FIG. 9 except that the creation 1201 process should create a new process 304 associated with the system at this level, at the highest level. .

FIG. 13 shows a menu pull down similar to that shown in FIG. Replication 1301 will cause the process 304 to be replicated, and destruction 1302 will cause the process to be destroyed.

14 illustrates the operation of pulling down a menu on a given process 304. The first action is to view 1401 a menu, the second action is to open 1401 a new project 301 associated with this process, and the third action is to open a test project 1403. This function becomes selectable only when the process 304 is in the completed state 52, and corresponds directly to the test transition 502, dynamic model of the process 304, shown in FIG.

Assuming that the view pull down is selected as shown in FIG. 8 and the project 301 button or item is selected as shown in 804, this assumption assumes that the window is It will be displayed in the system workspace. In this particular case, the window has a title bar area that represents the project from system level 1501. Field 1502 represents the project 301 in this case or represents a particular project 301 that does not have a substantial definition process 304 or a particular project 301 that does not have a substantial definition process 304. Show the list of icons. For example, two specific types of icons are shown, namely, a call home 1506 and a lunch lunch representing a project 301 in the system. Menu pull down view 1503 also uses processing and logic similar to that shown in FIG. Operation 1504 is also similar to that shown in FIG. 8 except that FIG. 16 is used. Selection 1506 will cause the pull down shown in FIG. 17 to be displayed to the user. If a menu button is selected on a mouse associated with an icon, such as home call 1506, a pull down associated with FIG. 18 will be displayed.

Referring to FIG. 16, the basic operation is very similar to that shown in FIG. 12 and FIG. The main difference is that the create operation 1601 is suitable for creating the project 301 without being defined by the process 304. Here, the user can be free to create the project 301 and associate the project 301 with other projects 301 without using the "wait" list.

FIG. 17 shows the available actions when an item is selected 1505. If nothing is selected, all items will be "grayed out", indicating that these items are not selectable. Here, a return operation 1702, completion 1703, schedule 1704, allocation 1705, destruction 1706, and replication 1707 are shown. These actions are actions that can be taken on any given set of projects 301 to be selected. In addition, these operations are shown almost directly in the dynamic model shown in FIG. Operations not shown are schedule and assignment operations, which are basic updating functions, and are disclosed in US Patent Application No. AT9-92-077, which is incorporated herein by reference, and is not disclosed herein.

Referring to FIG. 18, a menu that is pulled down when a menu direct manipulation selection is selected for a given icon such as house call 1506, that is, operation view 1801, return 1802, finish 1803, A schedule 1804, assignment 1805, destruction 1806, replication 1807 are shown, except for views that sense a single project 301 selected only for selection and opening for a particular one operation. Is almost a direct analog to those shown in FIG. When multiple objects are selected, it is impossible to make all view aggregations open. The processing associated with return 1802 through destruction 1506 and the like is controlled by the dynamic model shown in FIG.

Assuming that the user view is reselected from any screen shown in FIGS. 11 or 15 or from the main system window, and the user Joe is selected, it is possible for the owning list to be the default view associated with a given user. In this case, another window that may appear would be a user specific window as shown in FIG. In this case, title bar 1901 indicates that user Joe owns the view as the default view. Field 1902 represents these icons associated with project 301 substantially owned by user Joe, for example buckslip club note 1903. The menu bar items are very similar to those disclosed in all other windows in view 1904, shown in more detail in FIG. The “operation” 1905 shown in FIG. 19 is also relatively different and therefore will be shown in more detail in FIG. 21. However, the selection menu pull down and the icon pull down are the same as those shown in Figs. 17 and 18, because the selected object is the project 301. Referring to FIG. 20, a view that is available for a given user is shown, and this set of views can be derived almost directly from the static model shown in FIG. Ownership 2001 is likewise associated with the "owner" relationship of user 303 to project 301. Initiation 2002 is associated with a relationship between user 303 and project 301. Action view 2003 is the result of a direct association between user 303 and actions 302 performed by that user. Thus, there is no complicated processing involved in building the operation view 2003. whatnext 2004 is also an important view associated with user 303, which merely illustrates those projects 301 that are responsible for moving this particular user from one state 305 to another. Thus, the list of projects 301 returned during the whatnext view depends on whether this user is associated with the next action. Thus the processing involved is to iterate through these projects 301 " owned by a given user 303 " and to determine if project 301 whatnext returns a non-empty list. If the processing does not return an empty list, i.e., a project 301 that is in an active state that is in progress 42 or ready state 45, then this user is responsible for performing an operation to move the processing to the next state. Indicates responsibility. These result lists sending the test are returned as part of the whatnext view. The advantage of the whatnext view is that "own by" is not enough, and "start" is not enough on its own, while representing these actions as alternatives to the current user.

The final view associated with the user is the property view 2005, which represents attributes such as only the name and default view, etc., which can be updated or reviewed by the user.

Referring to FIG. 21, this figure is the result when the action pull down 1905 is called and the main action is very similar to the action associated with another window. Here, there are three practical types of production that can occur: a creation project, which is the particular process 304 shown in (1) 2100, (2) an open project 2102, which substantially opens the project associated with the process (3). There is an open test project 2103 that can cause the project 301 to open in a test mode associated with the dynamic model shown in FIG. The transition will be 502. This open test project 301 may only be allowed when the selected process 304 is in a completed state.

From the owning view shown in FIG. 19, if the view 1904 program is activated and the initiating view 2002 is selected, it will result in FIG. 22, in which case those projects initiated by the given user 303. 301 will be represented. Thus, the window shown in FIG. 22 will have a title bar 2201, and field 2202 will represent a list of icons representing these projects initiated by Joe. For example, there is a buckslip 12-1, a trip summary 2203. The menu bar is the same as any other menu user, and includes a view 2204 that is processed as shown in FIG. 20 and a selection 2206 that is processed very similarly to that shown in FIG. 17. The icon menu can be processed as shown in FIG.

Assuming motion view 2003 has been selected (see FIG. 20), a window may be displayed as shown in FIG. 23 to illustrate processing. The title bar 2301 indicates the view action of the user Joe in this case, while field 2302 shows a list of icons representing the action 302 that Joe executed with the generated bulkslip 12-1 trip summary 2303. do. View 2304 also corresponds to FIG. 20. Operation 2305 will cause FIG. 21 to be called or displayed. 18 shows an icon menu that can be displayed when selected. Also, processing is similar to that described above.

Referring again to FIG. 20, if the whatnext view 004 has been selected, in FIG. 23 a title bar 2401 will be shown that represents the user's whatnext view. Field 2402 shows a list of icons representing the project 301 ready for the project 301 to complete in one or the other. One example may be shown by an icon 2403 representing a bulkslip club memo forward indicating the status of process 304. The processing appearing from the menu bar items is the same as described above. View 2404 may be processed the same as described for menu pull down shown in FIG. 20, and operation 2405 may be processed the same as described in menu bar shown in FIG. And selection 2406 may likewise be handled via the pull down shown and described in FIG. 17. The icon menu may be displayed and operate as described in connection with FIG. 18.

Referring again to FIG. 11, assuming a particular process 304, i.e., bulkslip 1103, is selected, FIG. 25 shows a possible screen that can be used to provide a user interface for the functions associated with that process 304. FIG. . In this particular embodiment, title bar 2501 represents a "process bulkslip view definition." Field 2502 shows an icon representing a particular bulkslip created using this process 304 and present at some point within that process 304. One icon bulkslip club note 2503 is one such icon. Like other windows, the menu bar has a view 2504, the operation of which is described by the pull down menu shown in FIG. Operation 2505 is likewise shown through FIG. 27. Selection 2506 and icon menus are also shown in FIGS. 17 and 18, respectively.

Referring to FIG. 26, when view 2504 is selected, the items shown will correspond almost directly to those shown in the process 304 object on the static model shown in FIG. Definition view 2601 shows a list of projects, for which process 304 is now the definition process 304. Lifecycle 260 represents the state 305 and transition 306 of that lifecycle. "Input from" 2603 and "Output to" 2604 directly correspond to the list associated with the process 304 object, and are not shown as a separate drawing and are processed similarly to FIG.

Hierarchy 2605 corresponds to a superclass / subclass relationship between processes 304. Also, except that the display of this layer will look very similar to a hierarchical display graph (see Figure 37) with a superclass at the top, a process 304 at the center, and a subclass at the bottom (see Figure 37). It is very similar to the PLM system view process screen shown in FIG. Each process has the same menu bar pull down item as shown in FIG. 11 and is selected similarly as described in FIG.

Work product definition 2606 then corresponds to a process included within this particular process 304 and representing a definition of the work product for a given process 304. For example, a user may have increments in the release process 304. These increments will be the work product associated with a given release.

Project view 2607 cascades a menu that looks like the view menu shown in FIG. In other words, this view moves the viewpoint from the project 304 viewpoint to the project 301 viewpoint. Since process 304 is a type of project 301, movement at this point in time is allowed, so that the user owns the process 304 and who initiated the process 304 as shown in FIG. , What actions 302 are involved, history, characteristics, and the like can be considered. Finally, the properties 2608, which may also be very similar to the properties on any other object described above, represent names and default views, etc., which may be set or reset by the user.

Referring to FIG. 27, when an operation pull down 2505 is selected, this figure will look very similar to FIG. 14 with an open project 301 and an open test project 301. The only difference is that the view is no longer needed because the view already exists within the given project 301's view. Open project 2701 can be initiated in the same manner as open project 1402 shown in FIG. 14, and open test project 2702 becomes identical to open test project 1403 in FIG. Any operation that puts on one menu should also be associated with the other menu. Finally, in Fig. 25, since the object displayed on the field is the actual project 301, the selection menu 1505 in Fig. 17 is applied, and if the direct manipulation of the icons is made in order, the selection shown in Fig. 18 is made. The icon menu is applied.

28 shows a lifecycle view of process 304 or project 301, depending on how it is invoked. If a lifecycle view is invoked or selected from a screen such as FIG. 25, the window shown in FIG. 28 represents a particular process 304, while the process is shown in FIG. 20 from the time point of the project 301. If a lifecycle is invoked for a given project 301 selected, the window will have a title bar 2801 with a "process bulkslip view lifecycle". Field 2802 will represent a graphical representation of the process lifecycle with an advancing state 2804 and transition state 2803, which is a no state representing a transition from one state to another. ) Represents the transition of the production type from the forward state to the forward state, in this case 2805. There is also a transition from one state to non-state, as shown later at 2806. Operation bar pull down 2808 is also very similar to view 2807, which will be shown as discussed in FIG. 26 with any other process type view pull down. Operation 2808 will be described in accordance with FIG. 29 and display a pull down. Selection 2809 will be displayed in FIG. 30 and an icon menu will be displayed in FIG. Once operation 2808 is selected (see FIG. 29), what is shown is the ability to open project 2901 and to open a test project 2902 very similar to other process related operations. Other windowing operations, such as closing, minimizing, and maximizing, may also exist within the pull down.

The selection 2809 is different in that the selected item proceeds to a state or transition, and thus even if its functions, namely open project 301 and 3001 and open test project 301 and 3002, look similar. There is a difference in that is selected, the indication is that the project 301 requires a particular state, so if there is only one transition, that transition will be selected. If this transition is selected, that particular transition will be a transition that can be used to create a given project 301.

31 shows an icon menu, which includes a view 3101 and will provide a particular view of the selected state 305 or transition 306. Open project 3102 and open test project 3103 correspond directly to that shown in state 30, except that a given transition or state, a single user is selected.

Referring to FIG. 32, a process 304 will be shown at the point in time of a particular project 301 to allow direct activation, and the window will display a title bar 3201 with processes of project, bulkslip, club note, and view. Indicates. Field 3202 is similar to that shown in FIG. 28 and shows states and transitions. However, some other indication will be used to indicate that the deactivation state and transition (ie, not currently used) are indicated by a dashed line or not selectable. These indications are not part of the current state. This screen can also be used as part of the user interface to be selected when multiple transitions are possible. In other words, this window can be popped up and describes these transitions that can occur. In some sense, this function is available in two different ways. One way is to just select the process view of the project, and the other way is by taking this view as a dialog. Also, as field 3202 shows, a transition such as 3203 taken to create a bulkslip in the advanced state is no longer available. Similarly, since the bulkslip is not seen by all transitions, the transition 3204 that is output in a non-state suggesting completion is also unusable and is therefore shown in dashed lines. State 3209 is shown as a thick line or as a line rather than a dotted line, indicating that the advance state is active, and transition 3205 means that the bulkslip is not seen by all transitions, indicating that it is an active transition. . Thus, there is only one active transition in this case. And if the user has made a complete transition on this project 301, this will basically take that transition.

The view 3206, operation 3207, and selection 3208 menu bar items are very similar, although different in content. The operation 3207 menu bar is shown in FIG. 34, the selection 3208 menu bar is shown in FIG. 35, and the icon menu will be shown in FIG. The key point here is that the only selectable item is cloth. The state is not selectable for direct selection.

Referring to FIG. 33 shown by view 3206, it is also useful to refer back to FIG. 3 to see where most of the content shown in this figure is derived. View 3301 of process 304 is a substantial view that can be passed through process 304 "defined by" associated with project 301, if this view is null, this view depicts the lifecycle. However, it will also capture the information contained in the "control by" state 305. Thus, if there is no active state right now, that is, if the project 301 is in the waiting state, the user may see that "control by" is null, so that the object or project 301 is around forward. It will have a dotted line and will not be seen by all transitions. It will then take advantage of the current state of the project 301 as shown in the dynamic model of FIG. The atmosphere 3302, notification 3303, work product 3304 shows the project 301 to which one of them is associated. Another view container 310 represents project 301 and, if present, will be considered a work product. The container is slightly different in that it results in a default view of the project 301 as there is a single process 304 view instead of multiple process 304 views. History view 3305 represents a history of project 301, which is a list of operations 302 that may occur. And, what is initiated by the view 3306 represents a view similar to the user view shown in FIG. 19. Owned by the view (3307) is very similar. User views are also illustrated in FIG. 19. State view 3308 will show the current state, which becomes very similar to process 304. In this case, what this state view defines may be a project that exists in that state. Thus, this will be similar to any process 304 as shown in FIG. Feature 3309 is similar to all other features described above. "Defined by" 3311 illustrates process 304 as a definitive apparatus that is not associated with this object, and thus is substantially a shift in focus. While "define by" 3311 switches the view shown in FIG. 28, this process 3301 switches the view shown in FIG. This view is the general view of the process 304, and by default the lifecycle is the default view of the process 304.

Referring to FIG. 34 having an operation shown as a return operation 3401, a completion operation 3402, a schedule operation 3403, and an allocation operation 3404, the dynamic model and the US application (AT9-AT) shown in FIG. 92-077). If there is more than one transition in this figure, selecting this transition from an operational point of view will result in the selection dialog appearing as described above. Break 3405, copy 3406, close 3407, minimize 3408, maximize 3408 are very similar to those shown in the other menus described above.

35 shows the selected box 3208 in detail. Only transition is selectable, and the only operation that can be performed on the transition at this point is the completion operation. If the user wants to move the view, FIG. 36 shows an icon menu 3601 representing the view, which will provide a transition view according to FIG. 28 if a complex transition occurs. If the transition is not complicated, it will show the action defined by that transition.

37 shows a hierarchical view of process 304. Title 3701 has a hierarchy of "processes, changes, views". Field 3702 represents a base hierarchical view of the process. In all other respects, this view is the same as the screen of another process 304, such as FIG. 11, which merely represents multiple processes. Parent class or super class 3703 is a "work item". "Change" 3704 may be current process 304. Subprocess 304 " engineering change " 3705 indicates in a nearly hierarchical manner what inheritance structures can occur to provide the components of a definitive process 304. In terms of menu bar items, view 3706 is treated like any other process 304 type view. Operation 3707 and selection 3708 are also controlled to be the same as any other process oriented screen that is the same as shown in FIGS. 26 and 27 with views.

In summary, the foregoing is directed to how a system can be used to provide a very efficient and integrated system, similar to any other project 301 that can be utilized after the process is in a ready or completed state. Do. And project 301 has a function with a well defined process 304 or rather specific. The user has the ability to see the operations that these functions can perform and the projects 301 they own or initiate. The user has a clear way of knowing what actions are currently pending, which allows the user to easily focus on those projects 301 that require attention. In addition, a rich definitional structure that can take advantage of inheritance is implemented to describe a very complex process 304 at any hierarchical level, which can take advantage of inheritance through subclass and superclass arrays. .

With the above hardware in mind, it is possible to describe the characteristics related to the process 304 of the present invention. In order to more clearly explain these characteristics of the present invention, the discussion of other conventional characteristics apparent to those skilled in the art is omitted. Those skilled in the art will appreciate multiuser, multiprocess operating systems, in particular virtual memory, processor scheduling, synchronization facilities for both processes and processors, message transfer, conventional device drivers, terminal and network support, system initialization, interrupt management, system call functions, management It is assumed that you understand the requirements of this operating system for memory management, including facilities.

Since most of the apparatus of the present invention consists of electronic components and electronic circuits well known to those skilled in the art, detailed descriptions of the circuits are not disclosed except those necessary to understand and recognize the main concepts of the present invention.

Although the present invention has been described in detail according to a preferred embodiment, the present invention is not limited to the above embodiment, and various changes, substitutions, and modifications are possible without departing from the spirit and scope thereof.

Claims (20)

A method of representing a people-oriented work environment for managing a project in a data processing system that implements an object-oriented programming language environment, comprising: Modeling the project as an object-like software packet at and modeling the results of the project as an object-type software packet in the object-oriented programming language environment, wherein the project is A step defined by a result, and modeling the process as an object-type software packet within the object-oriented programming language environment, wherein the process inherits the attributes of the project, and the result is achieved by the process. Human oriented work Environmental representation method. The method of claim 1, further comprising modeling a state as an object-type software packet within the object-oriented programming language environment, wherein the state inherits attributes of the process. The method of claim 1, wherein the process includes a state, wherein the state is modeled as an object type software packet within the object oriented programming language environment. 3. The method of claim 2, further comprising modeling the transition as an object-type software packet within the object-oriented programming language environment, wherein the transition inherits the attributes of the state. 5. The method of claim 4 wherein the state is one type of the project and the transition is one type of the project. The method of claim 1, further comprising modeling an operation in the object-oriented programming language environment as an object-type software packet, the operation being included in the project. The method of claim 1, further comprising modeling a user as an object-type software packet within the object-oriented programming language environment, wherein the user owns and / or initiates the project. The process of claim 1, wherein the process modeled as an object type software packet in the object oriented programming language environment is as follows: the object-oriented programming language of at least one of (a) in progress explicit and transition states, (b) waiting for completion of a work product subproject, (c) waiting for input, and (d) ready. A human-oriented work environment representation method, each of which is an object type software packet in an environment. The process of claim 8, wherein upon completion of state (a), the process transitions to one of states (b), (c), or (d), and upon completion of state (b) the process comprises: state (c) or transition to one of (d), and upon completion of state (c) the process transitions to state (d). 6. The method of claim 5, wherein the state is defined by a process object that includes one or more states. The method of claim 1, further comprising creating and integrating a project object with the processor when the process has already been established and transitioned through one or more states. A data processing system that implements an object-oriented programming language environment, represents a human-oriented work environment tool for managing a project, and includes a processor, storage means, input means and output means connected via a bus, wherein the object-oriented programming Means for modeling the project as an object type software packet in a language environment, and modeling the result of the project as an object type software packet in the object oriented programming language environment, wherein the project is defined by the result; A data processing system in which the model is modeled as an object-type software packet within the text-oriented programming language environment, the process inherits the attributes of the project, and the result is achieved by the process; 13. The data processing system of claim 12, wherein the state is modeled as an object type software packet within the object oriented programming language environment, the state further comprising means for inheriting an attribute of the process. 13. The data processing system of claim 12, wherein the process includes a state, wherein the state is modeled as an object type software packet within the object oriented programming language environment. 14. The data processing system of claim 13, wherein the transition is modeled as an object-type software packet within the object-oriented programming language environment, wherein the transition further comprises means for inheriting an attribute of the state. 16. The data processing system of claim 15, wherein the state is a type of the project, the transition is a type of the project, and the state is defined by a process object that includes one or more states. 13. The process of claim 12, wherein the process modeled as an object-type software packet in the object-oriented programming language environment comprises (a) a progress specification state and a transition state, (b) a wait state for completion of a work product subproject, c) an input wait state and (d) one or more of a ready state, wherein each state is an object-type software packet in the object-oriented programming language environment. 18. The process of claim 17, wherein upon completion of state (a) the process transitions to one of states (b), (c), or (d), and upon completion of state (b) the process is either state (c) or ( d) transition to one of the following, and upon completion of state (c) the process transitions to state (d). 13. The data processing system of claim 12, further comprising means for creating and integrating a project object when the process has already been established and transitioned through one or more states. 13. The data processing system of claim 12, further comprising display means connected to the processor for displaying a graphical user interface representing the project and the process.