US6314434B1 - Structured data management system and computer-readable method for storing structured data management program - Google Patents

Structured data management system and computer-readable method for storing structured data management program Download PDF

Info

Publication number
US6314434B1
US6314434B1 US09/168,221 US16822198A US6314434B1 US 6314434 B1 US6314434 B1 US 6314434B1 US 16822198 A US16822198 A US 16822198A US 6314434 B1 US6314434 B1 US 6314434B1
Authority
US
United States
Prior art keywords
structured data
node
processing unit
data object
structured
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
US09/168,221
Inventor
Nobuhisa Shigemi
Hiroyuki Yamamoto
Gengo Tazaki
Makoto Yoshioka
Mitsuhiro Kokubun
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Assigned to FUJITSU LIMITED reassignment FUJITSU LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KOKUBUN, MITSUHIRO, SHIGEMI, NOBUHISA, TAZAKI, GENGO, YAMAMOTO, HIROYUKI, YOSHIOKA, MAKOTO
Application granted granted Critical
Publication of US6314434B1 publication Critical patent/US6314434B1/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/289Object oriented databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/12Use of codes for handling textual entities
    • G06F40/14Tree-structured documents
    • G06F40/143Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/953Organization of data
    • Y10S707/955Object-oriented
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99952Coherency, e.g. same view to multiple users
    • Y10S707/99953Recoverability
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99952Coherency, e.g. same view to multiple users
    • Y10S707/99954Version management

Definitions

  • the present invention relates to a structured data management system which processes structured electronic data, and to a computer-readable storage medium which stores a structured data management program which causes a computer to process structured electronic data. More particularly, the present invention relates to a structured data management system which supports such a processing environment where a plurality of structured data objects are associated with each other. Further, the present invention relates to a computer-readable medium which stores a structured data management program designed to make a computer perform the same.
  • ERP Enterprise Resource Planning
  • workflow packages which permits each work to be modeled in accordance with the user's intention.
  • workflow packages have the same deficiencies as existing ERP packages have. That is, everything should be defined at an initial stage; once they are deployed, it is impossible to change them, or complex procedures are required to do it.
  • scope of workflow packages is limited to a small area of business activities, and it is not a practical approach to apply them to an entire business operation.
  • GUI graphical user interface
  • an object of the present invention is to provide a structured data management system which processes structured data objects while adaptively dealing with their changes.
  • Another object of the present invention is to provide a computer-readable medium for storing a structured data management program, which permits a computer to process structured data objects, as well as flexibly dealing with changes in the structured data objects being concerned.
  • a structured data management system for providing services concerning structured electronic data objects.
  • This system comprises a structured data storage unit and a structured data processing unit.
  • the structured data storage unit stores structured data objects, each of which is expressed as a tree structure having a plurality of nodes. Each node represents a unit of data to be processed and is associated with a process script that defines what process should be executed.
  • the structured data processing unit identifies a destination node in one of the structured data objects stored in the structured data storage unit by tracing the tree structure of the one of the structured data objects according to a process request addressed to the destination node. It then executes the process script associated with the destination node according to the process request, and sends another process request to another node if required in the execution of the process script.
  • FIG. 1 is a conceptual view of the present invention
  • FIG. 2 is a diagram which schematically shows the relationships among a plurality of data groups representing various business activities in an enterprise
  • FIG. 3 is a diagram which shows how to manage a change in a structured data object
  • FIG. 4 is a block diagram of a business support system
  • FIGS. 5 (A) and 5 (B) are diagrams which provide supplementary information about management objects
  • FIG. 6 is a diagram which shows what a relationship description contains
  • FIG. 7 is a diagram which shows an example of business process model formulated according to the IDEF 0 notations
  • FIGS. 8 (A) to 8 (C) are diagrams which show the internal structure of activities on the second level
  • FIG. 9 is a diagram which shows a detailed structure definition of a business process model
  • FIG. 10 (A) is a diagram which shows an operator associated with an “Activity” node
  • FIG. 10 (B) is a diagram which shows a relationship description corresponding to the structure definition
  • FIG. 11 is a diagram which shows an instance of the business process model
  • FIG. 12 is a diagram which shows a structure definition of an organization model
  • FIG. 13 (A) is a diagram which shows the definition of an operator being associated with both “Department” and “Section” nodes in the organization model;
  • FIG. 13 (B) is a diagram which shows a relationship description corresponding to the structure definition of the organization model
  • FIG. 14 is a diagram which shows an example of an organization model instance
  • FIG. 15 is a diagram which shows a structure definition, an operator, and a relationship description to define a documentation system model
  • FIG. 16 is a diagram which shows an instance of the documentation system model
  • FIG. 17 is a flowchart which shows a message handling process executed by a processing engine
  • FIG. 18 is a flowchart which shows how the processing engine interacts with a user
  • FIG. 19 is a diagram which shows example screens that appear in the interactive process of FIG. 18;
  • FIG. 20 is a flowchart which shows a process executed when a staff in Design Administration Department logs in to the system
  • FIG. 21 is a flowchart which shows a process executed when the chief of Quality Assurance Section logs in to the system
  • FIG. 22 is a flowchart which shows a process executed when a staff in Quality Assurance Section logs in to the system
  • FIG. 23 is a diagram which schematically shows how structural changes occur
  • FIG. 24 is a diagram which illustrates a change in an organization
  • FIG. 25 is a diagram which illustrates a change in a business process
  • FIG. 26 is a diagram which illustrates a change in a structure definition of the documentation system
  • FIG. 27 is a diagram which illustrates a change in an instance of the documentation system
  • FIG. 28 is a first diagram which shows how the business process model is reused.
  • FIG. 29 is a second diagram which shows how the business process model is reused.
  • FIG. 1 is a conceptual view of a structured data management system according to the present invention.
  • This system comprises three main elements: an input/output interface unit 1 , a structured data storage unit 2 , and a structured data processing unit 3 .
  • the input/output interface unit 1 controls data transfer operations to/from the user or other systems.
  • the structured data storage unit 2 holds a plurality of structured data objects associated with each other.
  • Each structured data object can be represented as a tree structure having a plurality of data elements, or nodes. Further, the individual nodes of a tree structure are associated with their corresponding processes, which are defined in the form of process scripts.
  • the process scripts being written in a computer-executable language, may include a statement that requests another node to execute some specific process.
  • such a process request to another node is called a “message.” Since the system may encounter a power failure during its operation, the structured data storage unit 2 uses a non-volatile storage medium, such as magnetic storage devices, to maintain the data integrity even in such a problem situation.
  • a non-volatile storage medium such as magnetic storage devices
  • the structured data processing unit 3 Upon receipt of a message from the input/output interface unit 1 , the structured data processing unit 3 retrieves from the structured data storage unit 2 a particular structured data object 3 a specified in the received message. The structured data processing unit 3 analyzes the tree structure of this structured data object 3 a to identify a node to be processed, and then executes a specific process script associated with the identified node. When the process script includes a message to another node, the structured data processing unit 3 executes another process script relevant to that node, while parsing the message.
  • the structured data processing unit 3 reads out the specified structured data object 3 b from the structured data storage unit 2 and executes a process script related to the destination node. When it is unable to find the specified destination of the message, the structured data processing unit 3 would attempt to trace the tree structure to identify an alternative node that should receive the message, and execute a process script associated to the node.
  • each individual node is allowed to have a script to define its own local process, and pass the result or parameters to another node within the same data object or in another data object by tracing the tree structure of objects. While the structure varies over time, the system can identify the nodes in a consistent manner, as long as the scope of variation is limited to the locations of nodes. There are, however, other kinds of modifications, such as separation, consolidation, addition, and deletion of nodes. Even if such a modification occurs, it is still possible to investigate to which node the process should be linked, by comparing upper-level nodes of the new structure with those of the old structure, automatically by the system or semi-automatically with the intervention of a user. Because every structured data object has at least its root node, the system can continue the execution of a process without interruption, when a link related to the process has been lost.
  • Hieration describes an enterprise's organizational structure.
  • This organization model should be updated to a new version, each time a change occurs in the enterprise's organization.
  • one member node of the old structured data object has become obsolete as a result of changes in the organization.
  • messages addressed to the obsolete node can still be handled in the new organization model. That is, even if the node itself cannot be found in the new version, the structured data processing unit 3 will investigate the upper-level structure of the obsolete node in the old version, identify its parent node (or grandparent node, or the like) in the new version, and redirect the messages to that node.
  • a structured data object named “Items of Expense” is a typical object of this kind.
  • the structured data processing unit 3 can optionally be configured to notify the system administrator of the contents of a message, when the destination of the message no longer exists.
  • each structured electronic data object is associated with relevant process scripts that describe how the individual nodes will behave. Therefore, in the present invention, the user can easily change the process behavior (i.e., the content of processes), or locate a specific node or link that is causing a problem. If two or more instances of structured electronic data can be processed in an associated manner, the system will be a strong tool that totally supports a variety of business activities in the enterprise by linking many objects that express their structure and behavior.
  • FIG. 2 schematically shows the relationships among a plurality of data objects that may appear in an enterprise's business activities, where each single triangle represents a data object having a tree structure.
  • This specific example of FIG. 2 includes five structured data objects named “Business Process” ( 4 a ), “Bill of Material” ( 4 b ), “Items of Expense” ( 4 c ), “Organization” ( 4 d ), and “Documentation system” ( 4 e ).
  • the links interconnecting these structured data objects 4 a to 4 e denote inter-node relationships.
  • the business activities and services can be rendered as the relationships among many structured data objects.
  • the business support system of the present invention copes with frequent changes in the data structure that may happen during its operations. This is accomplished by storing both old and new versions of structured data objects and defining appropriate relationships between them.
  • FIG. 3 explains how to manage the structured data objects that vary over time, by illustrating three snapshots of a data model at times T 1 , T 2 , and Tn.
  • three structured data objects 5 to 7 exist at time T 1 , being associated with each other. They are named “Al”, “B 1 ,” and “C 1 ,” respectively.
  • the structured data object “A 1 ” 5 has its own internal structure, in which a node M is placed as a parent of two other nodes N 1 and N 2 . There is a reference link from the structured data object “B 1 ” 6 to the node N 1 in the structured data object “A 1 ” 5 .
  • the node N 1 is deleted at time T 2 , and the structured data object “Al” 5 is now revised to a new structured data object 5 a with the name “A 2 ,” as shown in the central part of FIG. 3 .
  • this object 5 a only one node N 2 remains under the top node M.
  • a process script in the structured data object “B 1 ” 6 is executed at time T 2 , and an access request to the obsolete node N 1 of the old structured data object 5 is issued.
  • the system can manage the change to continue the present process script execution, as long as the relationship between the old version “A 1 ” 5 and the new version “A 2 ” 5 a is known.
  • the relationships between old and new versions of a structured data object can be classified into two types.
  • the first type of relationships are called “implicit relationships,” which denote only a simple fact that one is new and the other is old, but provide no further details.
  • the second type of relationships are called “explicit relationships,” which definitely describe how the nodes in the old structure are associated with their counterparts in the new structure. According to such relationships, the following steps will be executed.
  • a node in the structured data object “B 1 ” attempts to make access to the node N 1 , expecting that it is in the structured data object “A 2 ” (Step S 1 ).
  • the structured data object processing unit 3 (FIG. 1 ), however, recognizes that the specified destination node N 1 is not present in the target object. It then refers to the old version “A 1 ” (Step S 2 ) and judges whether the relationship between “A 1 ” and “A 2 ” is explicit or implicit.
  • the structured data processing unit 3 continues the process according to the inter-node relationships being defined explicitly.
  • the new definition recites that the revised object A 2 does not have a node corresponding to the node N 1 .
  • the structured data processing unit 3 then prompts the user to enter an appropriate instruction, while showing him/her the current situation of both structured data objects A 1 and A 2 .
  • the structured data processing unit 3 automatically continues the process by using the node N 2 instead of N 1 (Step S 3 ).
  • the structured data processing unit 3 searches the original structured data object A 1 to find a parent node of the node N 1 (Step S 4 ).
  • the node M is what it is seeking in the current context of FIG. 3 .
  • the structured data processing unit 3 tries to find this node M in the new structured data object A 2 . Since the node M is successfully found, the structured data processing unit 3 continues the process by using the node M instead of N 1 (Step S 5 ).
  • the user will be notified by the system about how the process is reorganized. More specifically, the user is offered an opportunity to change the decision made by the system by specifying his/her preferable node. Now that the new destination is determined in this way, the process scripts in the structured data object B 1 are updated so that their references to the obsolete node N 1 will point to the new destination. This modification yields a new structured data object 6 a with the name “B 2 .”
  • the system of the present invention is designed to preserve the old version of a structured data object when it is changed. This makes it possible for the system to continue the execution of a process by tracing explicit relationships between old and new structured data objects or comparing the structures of the two versions with each other. That is, a partial change in a structured data object does not interrupt the process execution, but will be automatically solved by a flexible mechanism.
  • the above section has illustrated such a situation where one node is deleted, the present invention is not limited to this specific situation, but can be applied to other cases, including the division or consolidation of nodes.
  • the structured data processing unit 3 is designed to search for the parent of a lost destination node, when only an implicit relationship is given. This search, however, would end up with no good results if the parent node has been deleted together with its child node. In this case, the structured data processing unit 3 attempt to find its grandparent node, and if this search fails again, it then goes up to the next level of the tree structure. It should be noted here that the structured data processing unit 3 will finally find an alternative destination node, because the new and old structured data objects must share the root node by definition. This is why the system never stops the process execution, coping with any changes that have been made on the nodes.
  • this mechanism of the structured data processing unit 3 is analogous to how humans deal with an unexpected change by using their logical processing capabilities.
  • one staff has a problem and calls another section to talk to a person who would give him/her a good solution. But if that person (i.e., the destination node) cannot be reached, he/she will then bring the request to the chief of the section (i.e., the parent node of the lost destination).
  • the chief of the section i.e., the parent node of the lost destination.
  • the person would try to continue the process, following the analogy of the old process that he/she is familiar with.
  • This kind of human flexibility is implemented in the structured data processing unit 3 of the present invention.
  • the structured data objects and their definitions, as well as process scripts associated with them are maintained separately from the main system functions provided by the structured data processing unit 3 .
  • This arrangement permits the users to alter their system at any time, in a flexible manner. More specifically, the users can perform the maintenance of their system without stopping it. Or, in order to keep competitive in the ever-changing business environments, the users can alter the behavior of their business support system by modifying a process script associated with each node.
  • This also enables incremental system development, from a simple tool to help a small work to an enterprise-wide integrated business support system. Since each data object is represented by a hierarchical tree structure, an incremental modeling approach can be applied to the system development. That is, the development starts with a broad definition of its fundamental tree structure, and additional support functions will then be gradually implemented by dividing a node into a plurality of low-level nodes.
  • the nodes in a structured data object are associated with specific process scripts that describe how the individual nodes should work. That is, the system's behavior is defined by scripting a local process required in each individual node. This feature is advantageous because the user can easily change the process behavior. Also, in a problem situation, the user can locate a specific node or link that is causing the problem.
  • FIG. 4 is a block diagram of a business support system according to the present invention.
  • This system consists of three parts: a message delivery subsystem, a business support processing subsystem, and a client environment.
  • the message delivery subsystem comprises a message processor 10 and a timer event processor 11 .
  • the business support processing subsystem includes a processing engine 20 , a structured data management unit 21 , and a script interpreter 22 .
  • the client environment involves a client process 61 and various software tools such as an edit tool 62 .
  • a management/control script 73 to define how to operate the processing engine 20 .
  • scripts are stored in a hard disk or other storage media, and executed by the processing engine 20 after being loaded onto its main storage (semiconductor memory).
  • management objects refers to what has been discussed as a structured data object and its corresponding process scripts in the conceptual view of FIG. 1 . While the concepts represented by the management objects 30 , 40 , and 50 are different from each other, their data structure is defined in a unified style, containing the following elements:
  • scripts 33 , 43 , and 53 that define specific processes associated with the elements in each document type definition or the nodes in each structured data object.
  • the data type definitions 31 , 41 , and 51 and instances 32 , 42 , and 52 are written in the Standard Generalized Markup Language (SGML), an international standard for structured electronic documents.
  • SGML Standard Generalized Markup Language
  • the process scripts are written in the Micro Post Script (MIPS), a scripting language whose syntax rules accept natural expressions in Japanese. It should be noted, however, that the MIPS scripts in the accompanying drawings are translated into English, although their original version is written in Japanese.
  • SGML is a suitable foundation for document processing, which enables the user to easily describe the desired system structure by using flexible data modeling rules called “Document Type Definition” (DTD). Since the proposed system is designed to handle various business documents as one of the structured data objects shown in FIG. 1, SGML-based (i.e., structured) documents can readily be subjected to the system.
  • DTD Document Type Definition
  • SGML and MIPS have been chosen in the preferred embodiment, the present invention is not limited to these particular language specifications.
  • XML Extensible Markup Language
  • MIPS any interpreter languages can be used for scripting processes.
  • Messages transmitted in the system of FIG. 4 include the following four types:
  • the client process 61 determines the destination nodes of the first type (1) of messages, based on the basis of the cursor position or mouse pointer position given by the user. The details will be described in a later section, with reference to FIG. 19 .
  • the message delivery subsystem is a mechanism to transfer events, whose main functions are provided by the message processor 10 .
  • an electronic mail (E-mail) facility works as a vehicle of messages, where the message processor 10 acts as an SMTP server and POP server.
  • the message processor 10 sends and receives E-mail messages 72 to/from the processing engine 20 .
  • the pending messages 72 are once saved in a message queue 71 , and the message processor 10 processes them in a sequential manner.
  • the message processor 10 realizes inter-process communication across various business activities, interconnecting remote servers by using existing communication infrastructures. It is of course possible to use alternative mechanisms, as long as they can transfer event information necessary for the operations of the business support system.
  • the message queue 71 actually has two parts; one serves as the temporary storage for event messages, and the other serves as the storage for event log information.
  • the first part of the message cue 71 keeps the messages, making a classification according to their originators.
  • the stored information is used to check the present status of each process concerning individuals or some specialized groups.
  • the second part provides the system administrator with useful information for monitoring or managing the system.
  • the timer event processor 11 generates a timer event at a specified time of day, in response to a request from the processing engine 20 .
  • the business support processing subsystem plays a key role in the present embodiment.
  • the processing engine 20 contains no data or programs that directly relate to the business support functions. In fact, the operation of the processing engine 20 is wholly dependent on the definition of each management object. More specifically, the processing engine 20 is always activated by external events. Such trigger events include messages 72 and 75 sent from the message processor 10 and the client process 61 , and timer event signals generated by the timer event processor 11 . Depending on the content of each active process, a work list 74 written in the Hyper Text Markup language (HTML) is delivered from the processing engine 20 to the client process 61 .
  • This processing engine 20 is constructed within a World Wide Web (WWW) server, while the client process 61 is a WWW browser.
  • WWW World Wide Web
  • FIG. 4 illustrates the processing engine 20 and client process 61 as separate entities, they can be implemented in a single machine.
  • the structured data management unit 21 together with the script interpreter 22 , works as a server for the external environment outside the processing engine 20 . It receives and manages SGML documents, or the structural definitions of management objects, to provide the script interpreter 22 with database services, responding to queries about nodes.
  • the script interpreter 22 parses and executes MIPS scripts which contain the process definition concerning each management object.
  • the scripts offer database access functions and linkage with other systems, for example. They further provide instructions to the structured data management unit 21 for reading and writing SGML instances. Such instructions are called “operators,” and one can create a new operator by combining two or more operators.
  • the management/control scripts 73 can be divided into three groups as follows.
  • the first kind of scripts are used to control the processing engine 20 .
  • one script is used to load SGML documents related to a management object into the structured data management unit 21 .
  • Another script enables a specific process script of a management object to be transferred to the script interpreter 22 .
  • Still another script supports copyright protection for the scripts of management objects.
  • the second kind of management/control scripts are used to process a class of messages concerning administrative operations for the business support system. For example, one script provides such an agent process that responds to a query received through the message delivery subsystem. Another script updates a management object by applying a difference file received from the message delivery subsystem. Still another script automatically sends regular reports in cooperation with the timer event processor 11 .
  • the management objects including structured data objects and associated process scripts
  • This automatic data delivery service can extend to other computers via networks.
  • the third kind of management/control scripts are used to record the history of events and messages that have been processed by the processing engine 20 .
  • the collected history records can be used variously. For instance, they are subjected to process analysis, documented as audit records, or supplied to an application for debugging purposes.
  • This kind of management/control scripts may be integrated into the processing engine 20 as its native function.
  • the system may require appropriate facilities for access control, data security, and copyright protection.
  • Modern cryptography and electronic signature techniques can optionally be introduced to the system to protect the management objects.
  • some management/control scripts 73 will be used to decipher the protected scripts and to test the authenticity of electronic signatures.
  • Security mechanisms for process scripts should be implemented as an integral part of the processing engine 20 . This protects the enterprise's business activities from disruptions which may be caused by unauthorized modification of important program sources.
  • the client environment allows the user to interact with the system through a graphical user interface (GUI) provided by the client process 61 .
  • GUI graphical user interface
  • the client process 61 is actually a WWW browser application.
  • the client environment further provides the edit tool 62 and other software development tools, including: a text editor and viewer, a spreadsheet application, a graphics tool, and client functions of other systems.
  • the client process 61 sends messages to the processing engine 20 in response to inputs from the user or the edit tool 62 . Further, when a work list 74 is received from the processing engine 20 , the client process 61 displays it on the screen of a monitor unit. Both the client process 61 and edit tool 62 are installed on a computer located at the user's site.
  • the proposed business support system comprises management objects (Model), the processing engine 20 and management/control scripts 73 (Controller), and the client environment and message delivery subsystem (View).
  • Model management objects
  • Controller management/control scripts 73
  • View client environment and message delivery subsystem
  • the combination of the processing engine 20 , management objects, and E-mail messages may be interpreted as a combination of people, their knowledge, and work instructions. That is, the above system configuration is an analogy of daily activities in a human organization.
  • the processing engine 20 is positioned as an “agent” that carries out some jobs for the user. Since the system handles electronic data with a human-like concept and structure, the user can easily understand its behavior. Besides being robust and maintainable, the system permits the user to gradually implement required business support functions by giving his/her expert knowledge to the agent.
  • the proposed business support system can be tested by imitating its external environment. This is accomplished by reconfiguring the system of FIG. 4 so that the client process 61 will emulate the user operations and the message processor 10 will emulate E-mail message transmission, while leaving the business support processing subsystem as it is. Another method of enabling such a simulated operation of the system might be to modify some scripts in each management object to stimulate the DTD and SGML instances associated with the scripts.
  • FIGS. 5 (A) and 5 (B) are diagrams which provide supplementary information about management objects.
  • FIG. 5 (A) illustrates a management model 30 and relationships among its components, which include: a structure definition 31 (SGML-DTD), its instances 32 (SGML-instances), process scripts 33 a and 33 b (MIPS scripts), and relationship descriptions 34 a and 34 b (MIPS scripts).
  • FIG. 5 (B) shows the same relationships in the form of an object mapping diagram, which follows a common notation of cardinality constraints.
  • each script 33 contains one or more “methods” 33 c , where the term “method” is used as a synonym of the aforementioned “operator.”
  • This script 33 corresponds to what is referred to as the “process script” being associated with each node within a structured data object shown in the conceptual view of FIG. 1 .
  • scripts can be associated with the structure definition 31 , the instances 32 , or both. More specifically, some elements of the structure definition 31 are associated with the scripts 33 a through the relationship descriptions 34 a , and some elements of the instances 32 are associated with other scripts 33 b through the relationship descriptions 34 b .
  • the former scripts 33 a will be called “model-specific methods,” and the latter scripts 33 b will be called “instance-specific methods.”
  • model-specific methods will determine the system's default operation, when there are no conflicting definitions of instance-specific methods. For example, a model-specific method associated with the structured data object “Business Process” offers a class of business support functions that are beneficial to almost all departments and sections. Additionally, each individual department or section can develop its own specialized support function by preparing instance-specific methods.
  • model-specific methods might be a copyright protection of all SGML instances under a specific DTD.
  • an operator or a model-specific method
  • the copyright protection for a particular SGML instance will be accomplished by simply assigning the above operator to the SGML instance as an instance-specific method.
  • the present embodiment manages the object relationships in table form.
  • the relationship descriptions 34 , 34 a , and 34 b shown in FIGS. 5 (A) and 5 (B) are table-based definitions of relationships.
  • the relationship descriptions 34 a and 34 b contain one or more table entries. When an element of the structure definition 31 or a node in the instances 32 is given, these table entries are used to identify a specific method that is associated with the given element or node.
  • FIG. 6 shows the contents of a relationship description.
  • the relationship descriptions 34 a and 34 b are constructed in the form of a table having three data fields named “logical destination address,” “message name,” and “method name.” As these names imply, a kind of message handling mechanism is employed to control the flow of a process which is passed from node to node. Just as in the case of an external message stimulating the system, a message issued from a node, or object, causes a transition of process flow.
  • the logical destination address is a combination of a management object name and a locator (e.g., XPointer) that specifies a node to the structured data management unit 21 .
  • the message name is used to determine the message types. Each message has different parameters depending on what kind of message it is.
  • the method name indicates which method to choose and execute, from among those in a given script.
  • FIG. 6 illustrates a message 80 containing a logical destination address, a logical source address, a message name, and message-specific parameters.
  • the processing engine 20 uses this information to reach the destination node and to read out the specified script, referring to a relevant relationship description.
  • the relationship descriptions are prepared as separate data. Alternatively, they can be integrated into the structure definition or instances, and if this is the case, they are not necessarily defined in the form of tables.
  • FIGS. 7 to 14 the following paragraphs will present the details of the organization model 40 , documentation system model 50 , and business process model 30 shown in FIG. 4 .
  • FIG. 7 shows an example of a business process model according to the IDEF0 notation. As illustrated in the legend at the lower-left corner of FIG. 7, each process unit, or activity, is represented as a single box 91 , and input/output information to/from the process unit is indicated by four arrows in a classified way.
  • IDEF0 Integrated Computer-Aided Manufacturing Definition Method 0
  • This box together with its associated arrows, is a basic unit of process representation. Every process flow is defined by placing boxes and connecting them with appropriate arrows. Even a hierarchical concept of processes can be expressed by using the same notation.
  • an activity “Design management” 110 is on the top level (or top layer) of a business process model 100 .
  • the second level are the following three activities: “Drawing Quality Control” 111 , “Work Cost Management” 112 , and “Work Schedule Management” 113 .
  • these second-level activities 111 to 113 have their respective lower-level structures.
  • FIGS. 8 (A) to 8 (C) show the internal structure of activities on the second level.
  • FIG. 8 (A) means that two child activities, “Design Check” 111 a and “Design Rule Check” 111 b , are defined under the parent activity “Drawing Quality Control” 111 .
  • FIG. 8 (B) shows, there are two child activities, “Development of Design Rules and Standards” 112 a and “Standardization of Workflow” 112 b , under the activity “Work Cost Management” 112 .
  • Further, under the activity “Work Schedule Management” 113 there are two child activities, “Planning of Daily Schedule” 113 a and “Progress Management” 113 b , as shown in FIG. 8 (C). In this way, activities are defined in a hierarchical fashion.
  • FIG. 9 shows a structure definition of the business process model in more details.
  • a structure definition 31 of a business process is provided as a DTD file presented in the upper half of FIG. 9 .
  • the concept described in this structure definition 31 can be pictured alternatively in a tree structure, as shown in the lower half of FIG. 9 .
  • an abstract concept named “Business Process” is defined at the root node, and its elements are defined as lower-level nodes.
  • the structure definition 31 conforms to the IDEF0 modeling specification, where the element named “Resources” means what is called “mechanisms” in the IDEF0 terminology.
  • Operators 33 aa to 33 ae are defined in association with the nodes 31 a to 31 e.
  • FIG. 10 (A) shows the script of the operator 33 aa associated with the “Activity” node 31 a
  • FIG. 10 (B) shows a relationship description 34 a for the structure definition 31 .
  • a method (or operator) named “Close Work” is defined as a common default operation that is applicable to all instances of the “Activity” (e.g., “Design Management” and “Work Schedule Management”), because it is associated with the “Activity” node 31 a as a model-specific method.
  • FIG. 11 shows the definition of “Design Management” 32 a , an instance of the business process model.
  • the content of this instance 32 a can be represented as a tree structure as shown in the lower half of FIG. 11, while the definition itself is written in SGML as shown in the upper half of FIG. 11 .
  • FIG. 12 shows a typical structure definition 41 of the organization model, its DTD description on the left and its tree-structure representation on the right.
  • this structure definition 41 two element nodes “Department” and “Section” in the “Organization” are associated with a common operator 43 a .
  • FIG. 13 (A) is the definition of this operator 43 a
  • FIG. 13 (B) shows a relationship description 44 a that defines the above node-to-operator association.
  • the structure definition 44 a has two entries corresponding to the elements “Department” and “Section,” both of which include a message name “Send Work” and an operator “Send Work.” In this way, the operator 43 a of FIG. 13 (A) is associated to both of the two elements “Department” and “Section.”
  • FIG. 14 shows the definition of “Design Office” 42 a , an instance of the organization model 40 .
  • the upper half of FIG. 14 shows an SGML-based definition of this “Design Office” instance 42 a , while the lower half of FIG. 14 depicts the same in tree structure form.
  • FIG. 15 presents an example of the documentation system model 50 , which includes its structure definition 51 , its relationship description 54 a , and operators associated with its elements.
  • the documentation system model 50 contains three elements named “Documentation System,” “Standard Specifications,” and “Location.”
  • the relationship description 54 a associates a “Create New Document” operator 53 a with the first element “Documentation System,” and a “View Document” operator 53 b with the second element “Standard Specifications.”
  • FIG. 16 shows an instance 52 a of the documentation system model 50 , which is named “Design Document System.” On the left is an SGML-based definition of this instance 52 a , and on the right is a tree structure that visualizes the same.
  • FIG. 17 is a flowchart which shows a message handling process executed by the processing engine 20 .
  • the script interpreter 22 in the processing engine 20 receives event messages from external sources such as a user authentication process and the timer event processor 11 , according to the management/control script 73 being loaded.
  • the flowchart of FIG. 17 describes how the script interpreter 22 manipulates those incoming messages. The next section explains this process flow, assuming the system configuration of FIG. 4 .
  • the structured data management unit 21 reads the DTD and instances of a management object to which the message is addressed (Step S 11 ). Next, the structured data management unit 21 reads out a relationship description associated with the target instance. It then searches the relationship description for an entry that matches with the logical destination address and message name contained in the message, in an attempt to obtain the name of an operator that should be executed (Step S 12 ). If a relevant entry is found in the relationship description, the process skips to step S 14 . Otherwise, it proceeds to step S 13 . When no relevant entry is found, the structured data management unit 21 searches another relationship description associated with the DTD to find an entry that matches with the logical destination address and message name contained in the message (Step S 13 ).
  • the script interpreter 22 now has the operator name at hand. Accordingly, it reads out and executes the script of that operator. (Step S 14 ). If it encounters a message to another element during the execution of the script, the script interpreter 22 spawns another process, and this child process deals with the new message in the same way as above. Note that the message can be transmitted as an E-mail message to another node, as shown in FIG. 17 . The above steps are repeated until all messages are finished.
  • instance-specific methods take priority over model-specific methods. This permits the default behavior of element nodes to be defined as model-specific methods. It should also be noted that FIG. 17 illustrates only a principle of operation, but in actual implementations, one should take into consideration the performance and security issues.
  • FIG. 18 is a flowchart which shows how the processing engine 20 interacts with a user. This might be one the simplest examples of business support functions, which utilizes the default behavior definition provided by the model-specific methods.
  • the client process 61 executes this sequence of FIG. 18, exchanging information with the processing engine 20 .
  • the next paragraph explains each step of the process, referring to FIG. 4 in addition to FIG. 18 .
  • the user activates the client process 61 (WWW browser) and logs in to the processing engine 20 (WWW Server) (Step S 21 ).
  • the user is requested to enter his/her user name and password.
  • the processing engine 20 returns a list of activities to the client process 61 .
  • This list is called a “work item list” 74 , which shows every possible activity (or work item in the present case) related to the user.
  • the client process 61 Upon receipt of the work item list 74 from the processing engine 20 , the client process 61 displays it on the screen of a computer that the user is viewing (Step S 22 ). On the computer screen, the user can check every work item that has been delivered through the E-mail facility, while some of the displayed items might not have sufficient resources for the user to start working. The user now selects one item out of the work item list 74 on the screen. This item selection will invoke the execution of a script that provides default business support functions. The process, in turn, will be closed when the user enters an exit command. Note again that the default script has to be provided as model-specific methods.
  • the client process 61 sends a “Show Work Details” message 75 to the activity corresponding to the selected work item.
  • the processing engine 20 executes a “Show Work Details” operator, and as a result, detailed information on the selected work item is sent back to the client process 61 .
  • the client process 61 displays this information on the screen (Step S 23 ). Browsing through the displayed information, the user chooses a document to manipulate, or alternatively, he/she makes a notification to the system as will be described later.
  • the client process 61 When the user has selected a document, the client process 61 then sends a prescribed message, such as “Show Document Details,” to a node associated with the document that the user has selected. In response to this message, the processing engine 20 executes a relevant operator and returns the result to the client process 61 .
  • the client process 61 then chooses an edit tool 62 suitable for the selected document and activates it as a separate process (Step S 24 ).
  • This edit tool 62 is, for example, a viewer 62 a or an editor 62 b.
  • Step S 25 Upon completion of his/her work with the edit tool 62 , the user returns to the activity screen of step S 23 and notifies the system of the completion.
  • the client process 61 then presents a selection screen, where he/she is prompted to answer whether his/her output document has completed or not (Step S 25 ).
  • the completion indication is transmitted to the next activity.
  • no information is transmitted, in principle, when the user has selected a “Not Completed” button. It is, however, possible to configure the system to send some notification to the next activity, if a certain condition defined in a script is satisfied.
  • this step S 25 is finished, the process returns to step S 22 to display again a work item list.
  • the steps S 22 to S 25 are then repetitively executed, until the user enters an exit command on the work item list screen.
  • FIG. 19 shows a series of example screens that would appear in the interactive process.
  • a log-in screen 210 appears as the initial screen of the client process 61 , which has a “User Name” input box 211 and a “Password” input box 212 .
  • the user enters his/her user name and password into these two boxes and clicks a “Send” button (i.e., places the mouse pointer on an on-screen button named “Send” and presses a mouse button).
  • This operation directs the client process 61 to transmit the entered user name and password to the processing engine 20 , thus conducting user authentication.
  • the log-in screen 210 has a “Clear” button 214 to erase the present text entry in both the “User Name” input box 211 and “Password” input box 212 .
  • the processing engine 20 supplies a work item list 74 to the client process 61 .
  • the client process 61 displays this list 74 on a “Work Item Lists” screen 220 .
  • this screen 220 proposes two work items 221 and 222 to the user.
  • the first item 221 is what is shown in FIG. 8 (A) as the “Design Check” activity 111 a , which is a child activity of the “Drawing Quality Control” activity 111 (FIG. 7) within the “Design Management” activity 110 (FIG. 7) defined as an instance of the business process model.
  • the second item 222 is what is shown in FIG.
  • a text string “Exit” 223 is placed to allow the user to exit from the present work with a mouse click on it.
  • the underlined text strings on the screens 220 and 230 are so-called hyperlinks, which enables the user to select items or trigger some actions by making a simple point-and-click operation with his/her mouse.
  • the client process 61 sends a “Show Work Details” message to the node representing the “Drawing Check” activity 111 a (FIG. 8 ). Since no instance-specific methods are associated with this “Drawing Check” node, the “Show Work Details” operator, a method common to all activity instances, is executed (See relationship description 34 a in FIG. 10 ). As a result of this execution, a work details screen 230 appears on the monitor, where the user obtains the detailed information on the “Drawing Check” work he/she selected (See step S 23 in FIG. 18 ).
  • the work details screen 230 shows the names of an input document, control document, and output document in their respective display sections 231 , 232 , and 233 .
  • An indicator is placed at the head of each section to show whether the document is available or not. As the notation describes, a letter “A” means that the document is available, while a letter “N” indicates that the document is not available.
  • the client process 61 sends a “Show Document Details” message to the “Input Name” node of the “Design Check” business process instance.
  • the message activates the script interpreter 22 in the processing engine 20 to execute a “Show Document Details” operator, which is a method common to all “Input Name” instances.
  • a viewer application is invoked in the user's computer environment, thereby displaying the detailed contents of the “Drawings.” Note here that every activity produces its output, which means that the activities will not terminate themselves, until they finish output documents.
  • the user Upon completion of his/her work, the user selects the “Close/Suspend” on the work details screen 230 .
  • the client process 61 displays a completion notification screen 240 to ask whether the user has finished the output document.
  • a completion notification screen 240 On this screen 240 , two check boxes, “Completed” 241 and “Not Completed” 242 , are presented to the user, prompting him/her to select either one.
  • the user has a data file containing the result of design check, he/she has to enter the folder and name of the file into a text box 243 , in addition to selecting the “Completed” check box 241 .
  • Clicking a “Browse” button 244 on the right of the text box 243 will call up a file selection window, which shows the directory structure of the computer in which the client process 61 is running, together with a file list in the current directory.
  • the user can select a specific file from this list, instead of directly typing a directory name and file name and into the text box 243 .
  • a “Send” button 245 is placed on the bottom of the screen 240 . When the user clicks this button, the client process 61 sends a notification message to the processing engine 20 to whether the output document is finished or not.
  • FIG. 20 is a flowchart which shows a process executed by the processing engine 20 to help a staff in the Design Administration Department who has logged in to the system. The explanation will follow the step numbers affixed to each box in this flowchart. As the legend of FIG. 20 describes, bold arrows indicate the process transitions caused by messages sent from scripts; broken arrows indicate the process transitions caused by E-mail messages; dotted arrows indicate the process transitions caused by messages generated by user operations. Each box contains the name of a specific operator that is executed by the processing engine 20 , as well as showing the resulting effects in parentheses.
  • the steps S 31 to S 59 describe the following situation.
  • a staff in the Design Administration Department finishes his/her assignment, “Drawing Check.”
  • the chief of the Quality Assurance Section assigns one of his/her staff for the next activity, “Design Rule Check.”
  • the appointed staff executes this task with the assistance of the system.
  • the processing engine 20 executes a “Close Work” operator associated with the “Activity” node in the “Business Process” management object. Note here that the current activity is “Design Check” under the “Drawing Quality Control” activity.
  • the “Close Work” operator is one of the model-specific methods associated with the “Activity” node in the business process model (see FIG. 9 and FIG. 10 (A)). The execution of this “Close Work” operator causes the transmission of a “Send Completion” message to the “Output” node.
  • the processing engine 20 executes a “Send Completion” operator associated with the “Activity.Output” node (i.e., “Output” node under the “Activity” node) in the “Business Process” management object.
  • the execution of this operator results in the transmission of an “Accept Completion” message to an “Input Name” node that has the same name as the output name “Design Check Result.”
  • the processing engine 20 executes an “Accept Completion” operator associated with the “Input Name” node in the “Business Process” management object. This operator causes a “Send Work” message to a “Section” node with the name “Quality Assurance Section” in the “Organization” management object. Note that this node name derives from the “Resource Name” node under the current activity node.
  • the processing engine 20 executes a “Send Work” operator associated with the “Section” node in the “Organization” object. The execution of this operator results in the transmission of a “Check Start Condition” message to the next “Activity” node (i.e., “Design Rule Check”) in the form of an E-mail massage addressed to Mr. Suzuki, Chief of Quality Assurance Section.
  • a “Send Work” operator associated with the “Section” node in the “Organization” object.
  • the execution of this operator results in the transmission of a “Check Start Condition” message to the next “Activity” node (i.e., “Design Rule Check”) in the form of an E-mail massage addressed to Mr. Suzuki, Chief of Quality Assurance Section.
  • FIG. 20 The above process of FIG. 20 is continued to another flowchart of FIG. 21, which shows a process to help Mr. Suzuki who has just logged in to the system.
  • the processing engine 20 executes a “Register Work Item” operator associated with a “Work Item” node in a “Work Item” management object, where the “Work Item” is a management object to be used when the management/control script is executed.
  • the E-mail message generated in step S 34 is received, an “Activity” node is created, and after that, a “Check Start Condition” message is transmitted to the “Activity” node in the “Business Process” management object.
  • the processing engine 20 executes a “Check Start Condition” operator associated with the “Activity” node in the “Business Process” management object. As a result of the execution of this operator, it is tested whether all necessary documents are ready for the execution of the requested activity. Then a “Prepare for Work” message is sent to an “Activity” node of the “Work Item” management object.
  • the processing engine 20 executes a “Prepare for Work” operator associated with the “Activity” node in the “Work Item” management object. As a result of the execution of this operator, the properties and status of the “Activity” node are updated, and a “Show Work Item List” message is transmitted to a “Work Item” node.
  • the processing engine 20 executes a “Show Work Item List” operator associated with the “Work Item” node in the “Work Item” management object. This operator causes the client process 61 to display a list of work items.
  • Mr. Suzuki now directs the system to send the work to his/her staff members.
  • the processing engine 20 then executes an “Assign Work” operator associated with the “Activity” node in the “Business Process” management object.
  • the system prompts Mr. Suzuki to select an appropriate staff member.
  • a “Check Start Condition” message is sent to the “Activity” node via E-mail.
  • FIG. 21 is continued to still another flowchart of FIG. 22, which shows a process to be executed when the selected staff member in the Quality Assurance Section logs in to the system.
  • the processing engine 20 executes a “Register Work Item” operator associated with the “Work Item” node in the “Work Item” management object. As a result of the execution of this operator, the E-mail message produced in step S 46 is received, and an “Activity” node is created. After that, a “Check Start Condition” message is transmitted to the “Activity” node in the “Business Process” management object.
  • the processing engine 20 executes a “Check Start Condition” operator associated with the “Activity” node in the “Business Process” management object. As a result of the execution of this operator, it is examined whether all necessary documents are ready for the execution of the current activity, i.e., “Design Rule Check.” Such documents include: “Quality Standard,” “Product Cost Standard,” and “Design Check Result.” If all these documents are ready, a “Prepare for Work” message is sent to the “Activity” node in the “Work Item” management object.
  • the processing engine 20 executes a “Prepare for Work” operator associated with the “Activity” node in the “Work Item” management object. As a result of the execution of this operator, the properties and status of the “Activity” node are updated, and a “Show Work Item List” message is transmitted to the “Work Item” node.
  • the processing engine 20 executes a “Show Work Item List” operator associated with the “Work Item” node in the “Work Item” management object. This operator causes the client process 61 to display a list of work items.
  • the processing engine 20 executes a “Show Document Details” operator associated with an “Activity.Input.Input Name” node in the “Business Process” management object. As a result of the execution of this operator, the document “Design Check Result” is displayed.
  • the processing engine 20 executes a “Show Document Details” operator associated with an “Activity.Control.Control Name” node in the “Business Process” management object. As a result of the execution of this operator, the documents “Quality Standard” and “Product Cost Standard” are displayed.
  • the processing engine 20 executes a “Create Document” operator associated with an “Activity.Output.Output Name” node in the “Business Process” management object. This operator enables the user to create documents “Design Standard” and “Final Drawings” with an editor application.
  • the processing engine 20 executes a “Close Work” operator associated with the “Activity” node in the “Business Process” management object. This operator causes a “Send Completion” message to be sent to the output tag.
  • the message initiated by the “Close Work” operator of the “Design Check” activity triggers another activity and another message.
  • the messages are propagated from node to node, tracing the tree structures of “Business Process” and “Organization” management objects, as illustrated in FIGS. 20 to 22 .
  • FIG. 23 schematically shows such structural changes by illustrating a business process object, an organization object, and a documentation system object, which have initial structures as explained in FIGS. 9 to 16 .
  • the organization is restructured, the business process model evolves to more detailed levels, the documentation system is redefined and altered, and one business process produces a new business process.
  • the system comprises a “Business Process-A” management object 311 , an “Organization-A” management object 314 , and a “Documentation System-A” management object 316 .
  • the scripts and instances of the management object 311 are changed, and a new management object 312 is created as a new version of “Business Process-A.”
  • a new management object 312 is created as a new version of “Business Process-A.”
  • its replica is created as another management object 313 named “Business Process-B.”
  • the scripts and instances of the “Organization-A” management object 314 are modified in accordance with a change in the enterprise's organizational structure, resulting in a management object 315 having a new version number. Further, a renewal of the “Documentation System-A” management object 316 is conducted, thus producing a new management object 317 having updated scripts, structure definition, and instances.
  • FIG. 24 illustrates a change in an organizational structure, where an instance 331 is revised to another instance 332 .
  • a node named “Quality Assurance Section” in the original instance 331 has grown to “Quality Assurance Department” in the updated instance 332 .
  • This new department has two subordinate sections, “First Quality Assurance Section” and “second Quality Assurance Section,” which are newly established nodes.
  • it is necessary to investigate the influence of the change by searching the present structure definition of business processes to find all activities which involves the old “Quality Assurance Section.”
  • the existing methods that are specific to the old node of “Quality Assurance Section” should be changed so that the messages addressed to the old node will be automatically forwarded to the new nodes.
  • the system can deal with accidental references to the old node, or messages that have already been issued to the old node, thus being able to continue the service.
  • FIG. 25 shows an example of such a process change.
  • a business process instance 341 initially includes an activity named “Work Schedule Management,” whose behavior is broadly defined at this stage.
  • the “Work Schedule Management” activity is divided into two child activities named “Daily Schedule Planning” and “Progress Management.”
  • the system would require no other things than modifying the instance, if the default methods provide sufficient functions. It is of course possible to define methods specific to the new instance. While some messages may still have a logical destination address to reach the old node, the system can handle them properly, if the new node “Work Schedule Management” has a new process script that transfers messages to its child nodes.
  • the new business process model preserves old node names, and thus the messages addressed to the old node can reach a new node having the same node name.
  • a node is renamed in the new business process model, meaning that a message addressed to such a node would be lost.
  • the system would examine the old business process model to find a relevant department or section. The message would be transferred to this alternative destination, if available. It is also possible to configure the system to return the message to its sender, if there is no clue to identify the destination.
  • the business process model can be developed in a stepwise fashion, from a broad layout to detailed definitions. Since the model can be reconfigured easily and its output immediately reflects the alterations being made, the enterprise can keep competitive in today's ever-changing business environment.
  • FIG. 26 shows an example of such a change in the documentation system definition.
  • this documentation system contains only one element named “Standard Specifications” as shown in a structure definition 351 .
  • This primitive definition is changed to a new structure definition 352 , in which the documents are classified into two new groups “Standards” and “Planning.”
  • several lower-level nodes such as“Design Standards” and “Design Planning,” are added to the structure to define appropriated default methods depending on the document types.
  • FIG. 27 illustrates a change in the documentation system instance which is caused by a renewal of the documentation system model shown in FIG. 26 .
  • an original instance 361 has changed to a new instance 362 having a different tree structure.
  • the new structure has a node named “Design Plan Brief” and its two child nodes “Mechanical Design Plan” and “Logic Design Plan.”
  • one business process sometimes produces its derivative processes. For example, a company divides itself into a plurality of companies to make their organization more competitive; a new project starts in a company; part of an existing process forms an independent process. It is not difficult, however, to define new business processes suitable for these cases. Typically, this can be accomplished by replicating a similar business process model and modifying the replica so that it will serve for the purpose.
  • FIG. 28 is a first diagram which shows how to reuse a business process model, assuming that a business process instance is changed as shown in FIG. 25 .
  • a relationship description 381 connects a structure definition 371 with a process script 382 , by which a model-specific method named “Show Work Details” is defined in association with an “Activity” node in the business process model.
  • a new structure definition 372 is now produced by replicating this structure definition 371 .
  • FIG. 29 is a second diagram which shows how to reuse a business process model.
  • a new instance 392 a replica of an existing instance 391 , is also produced in conjunction with the replicated structure definition 372 .
  • This instance 392 contains an activity named “Progress Management” which is associated with an instance-specific method named “Support Work” as described in a relationship description 401 .
  • the definition of this method is added to a process script 402 as a “Support Work” operator.
  • This operator uses the “Show Work Details” operator, which is a model-specific method associated with an activity that has been inherited from the original business process model.
  • the process script 402 defines that the “Support Work” operator finds all activities that are behind the schedule and then displays a list of such delayed activities with the “Show Work Details” operator. As the relationship description 401 shows, this “Support Work” operator is activated when a “Show Work Details” message arrives at the “Progress Management” activity.
  • the system can provide such a service that is specific to a particular activity, without affecting other activities.
  • the new business process model can inherit almost all assets of process definitions from the old model, if the two models bear a close resemblance in their structures.
  • the original and new business process models can be handled by the same processing engine without any interference between the two models, because they are defined as separate management objects.
  • the proposed processing mechanisms are actually implemented as hardware and software functions of a computer system.
  • the process steps of the proposed data business support system are encoded in a computer program, which will be stored in a computer-readable storage medium.
  • the computer system executes such programs to provide the intended functions of the present invention.
  • the suitable computer-readable storage media include magnetic storage media and solid state memory devices. Some portable storage media, such as CD-ROMs (Compact Disk Read Only Memory) and floppy disks, are also suitable for circulation purposes. Further, it will be possible to distribute the programs through an appropriate server computer deployed on a network.
  • the program file delivered to the user is normally installed in his/her computer's hard drive or other local mass storage devices, and executed after being loaded on the main memory.
  • the structured data management program of the present invention is stored in a computer-readable medium. With this program executed on a computer, flexible operations to handle structured data objects, including their changes, will be realized.

Abstract

A structured data management system which provides services concerning a structured electronic data object. In this system, a structured data storage unit stores a plurality of structured data objects associated with each other. Each structured data object can be represented as a tree structure constructed by a plurality of data elements, or nodes. Further, the individual nodes of a tree structure are associated with their respective process scripts. Through an input/output interface unit, a message addressed to a certain destination node arrives. Upon receipt of the message, a structured data processing unit identifies the destination node by tracing the tree structure of a particular structured data object where the destination node resides. The structured data processing unit then executes a process script associated with the destination node being identified. During the execution of this process script, the structured data processing unit may encounter another message that is addressed to a node in a different structured data object. In this case, the structured data processing unit reads out the specified object from the structured data storage unit and executes a process script of that node.

Description

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a structured data management system which processes structured electronic data, and to a computer-readable storage medium which stores a structured data management program which causes a computer to process structured electronic data. More particularly, the present invention relates to a structured data management system which supports such a processing environment where a plurality of structured data objects are associated with each other. Further, the present invention relates to a computer-readable medium which stores a structured data management program designed to make a computer perform the same.
2. Description of the Related Art
Conventionally, the efforts to develop information systems to aid various business activities in an enterprise have been directed toward the support of routine works that do not change very much with time. In reality, however, there is no business that can sustain without changes, and the user needs to constantly grow in sophistication. System development usually starts with the analysis and modeling of current business processes, and time-consuming development work follows them. This conventional way of system development, however, would sometimes result in a big disappointment of users because their requirements vary with time. The system becomes out-of-date soon after its deployment, or the obsolescence begins even at the moment when its development is started.
Additionally, the basic design of conventional business support systems do not allow for possible changes in the real-life business operations. Therefore, the data storage structure and behavioral definitions of data objects (i.e., definitions of how to process given data objects) are integrated in the applications as part of their system functions. Such conventional business support systems have difficulty in adapting themselves to new user requirements that stem from ever-changing business environments. As a result, conventional systems often require the conversion of a large amount of corporate information assets into a new data structure.
To solve the above problems, new integrated software suites called the “Enterprise Resource Planning” (ERP) packages have been developed. This type of software package offers various business process models in the form of software components having parameterized behavior models. This makes it possible to develop a desired system by simply combining software components and setting their parameters in accordance with the user's business environment.
The above integrated software packages, however, require all business processes to be analyzed and set up at a very early stage of development, and therefore, the system engineers must have deep knowledge about both ERP tools and real-world business activities. This leads to another problem that it takes much time to start up the system. In order to keep up with ever-changing business operations and continuously provide effective support to the user, it is necessary to dynamically change, expand, and/or consolidate the system in the course of operations, by combining the best-suited technologies in a timely manner. Unfortunately, the existing ERP packages are lacking in this capability.
No matter how versatile the software components are, actual business activities have a unique personality all their own. A business support system constructed with such components would require the users to adapt themselves to the system. This situation, however, seems to get things the wrong way around.
Furthermore, data models offered by system vendors are not flexible. Their fundamental features are fixed, and user-definable part is limited. Additionally, it is hard to know the relationships between data items and process definitions. As a matter of fact, it is impossible for the users to alter the predefined data structures.
Meanwhile, there are business support packages called “workflow,” which permits each work to be modeled in accordance with the user's intention. These types of packages, however, have the same deficiencies as existing ERP packages have. That is, everything should be defined at an initial stage; once they are deployed, it is impossible to change them, or complex procedures are required to do it. In addition, the scope of workflow packages is limited to a small area of business activities, and it is not a practical approach to apply them to an entire business operation.
Another problem with the ERP and workflow packages is the difficulty in customizing their standard definitions of business processes or organizational structures. One reason for this is that the definitions are formulated through a graphical user interface (GUI) and their internal representation is hidden from the user. Therefore, it is hard for the user to add a new data structure, or to define links to other systems.
In summary, conventional tools are not suitable for the development and operations of a business support system for non-routine tasks that often change over time. Therefore, it is necessary to introduce manual operations to process non-automated tasks. In addition, the user has to enter the same data over and over, since conventional system tools are unable to effectively reuse the legacy information.
SUMMARY OF THE INVENTION
Taking the above into consideration, an object of the present invention is to provide a structured data management system which processes structured data objects while adaptively dealing with their changes.
Another object of the present invention is to provide a computer-readable medium for storing a structured data management program, which permits a computer to process structured data objects, as well as flexibly dealing with changes in the structured data objects being concerned.
To accomplish the above objects, according to the present invention, there is provided a structured data management system for providing services concerning structured electronic data objects. This system comprises a structured data storage unit and a structured data processing unit. The structured data storage unit stores structured data objects, each of which is expressed as a tree structure having a plurality of nodes. Each node represents a unit of data to be processed and is associated with a process script that defines what process should be executed. The structured data processing unit identifies a destination node in one of the structured data objects stored in the structured data storage unit by tracing the tree structure of the one of the structured data objects according to a process request addressed to the destination node. It then executes the process script associated with the destination node according to the process request, and sends another process request to another node if required in the execution of the process script.
The above and other objects, features and advantages of the present invention will become apparent from the following description when taken in conjunction with the accompanying drawings which illustrate a preferred embodiment of the present invention by way of example.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a conceptual view of the present invention;
FIG. 2 is a diagram which schematically shows the relationships among a plurality of data groups representing various business activities in an enterprise;
FIG. 3 is a diagram which shows how to manage a change in a structured data object;
FIG. 4 is a block diagram of a business support system;
FIGS. 5(A) and 5(B) are diagrams which provide supplementary information about management objects;
FIG. 6 is a diagram which shows what a relationship description contains;
FIG. 7 is a diagram which shows an example of business process model formulated according to the IDEF0 notations;
FIGS. 8(A) to 8(C) are diagrams which show the internal structure of activities on the second level;
FIG. 9 is a diagram which shows a detailed structure definition of a business process model;
FIG. 10(A) is a diagram which shows an operator associated with an “Activity” node;
FIG. 10(B) is a diagram which shows a relationship description corresponding to the structure definition;
FIG. 11 is a diagram which shows an instance of the business process model;
FIG. 12 is a diagram which shows a structure definition of an organization model;
FIG. 13(A) is a diagram which shows the definition of an operator being associated with both “Department” and “Section” nodes in the organization model;
FIG. 13(B) is a diagram which shows a relationship description corresponding to the structure definition of the organization model;
FIG. 14 is a diagram which shows an example of an organization model instance;
FIG. 15 is a diagram which shows a structure definition, an operator, and a relationship description to define a documentation system model;
FIG. 16 is a diagram which shows an instance of the documentation system model;
FIG. 17 is a flowchart which shows a message handling process executed by a processing engine;
FIG. 18 is a flowchart which shows how the processing engine interacts with a user;
FIG. 19 is a diagram which shows example screens that appear in the interactive process of FIG. 18;
FIG. 20 is a flowchart which shows a process executed when a staff in Design Administration Department logs in to the system;
FIG. 21 is a flowchart which shows a process executed when the chief of Quality Assurance Section logs in to the system;
FIG. 22 is a flowchart which shows a process executed when a staff in Quality Assurance Section logs in to the system;
FIG. 23 is a diagram which schematically shows how structural changes occur;
FIG. 24 is a diagram which illustrates a change in an organization;
FIG. 25 is a diagram which illustrates a change in a business process;
FIG. 26 is a diagram which illustrates a change in a structure definition of the documentation system;
FIG. 27 is a diagram which illustrates a change in an instance of the documentation system;
FIG. 28 is a first diagram which shows how the business process model is reused; and
FIG. 29 is a second diagram which shows how the business process model is reused.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
An embodiment of the present invention will be described below with reference to the accompanying drawings.
FIG. 1 is a conceptual view of a structured data management system according to the present invention. This system comprises three main elements: an input/output interface unit 1, a structured data storage unit 2, and a structured data processing unit 3. The input/output interface unit 1 controls data transfer operations to/from the user or other systems. The structured data storage unit 2 holds a plurality of structured data objects associated with each other. Each structured data object can be represented as a tree structure having a plurality of data elements, or nodes. Further, the individual nodes of a tree structure are associated with their corresponding processes, which are defined in the form of process scripts. The process scripts, being written in a computer-executable language, may include a statement that requests another node to execute some specific process. In this description, such a process request to another node is called a “message.” Since the system may encounter a power failure during its operation, the structured data storage unit 2 uses a non-volatile storage medium, such as magnetic storage devices, to maintain the data integrity even in such a problem situation.
Upon receipt of a message from the input/output interface unit 1, the structured data processing unit 3 retrieves from the structured data storage unit 2 a particular structured data object 3 a specified in the received message. The structured data processing unit 3 analyzes the tree structure of this structured data object 3 a to identify a node to be processed, and then executes a specific process script associated with the identified node. When the process script includes a message to another node, the structured data processing unit 3 executes another process script relevant to that node, while parsing the message. If the message specifies still another node that resides in a different structure data set 3 b, for example, the structured data processing unit 3 reads out the specified structured data object 3 b from the structured data storage unit 2 and executes a process script related to the destination node. When it is unable to find the specified destination of the message, the structured data processing unit 3 would attempt to trace the tree structure to identify an alternative node that should receive the message, and execute a process script associated to the node.
In the above-described arrangement, each individual node is allowed to have a script to define its own local process, and pass the result or parameters to another node within the same data object or in another data object by tracing the tree structure of objects. While the structure varies over time, the system can identify the nodes in a consistent manner, as long as the scope of variation is limited to the locations of nodes. There are, however, other kinds of modifications, such as separation, consolidation, addition, and deletion of nodes. Even if such a modification occurs, it is still possible to investigate to which node the process should be linked, by comparing upper-level nodes of the new structure with those of the old structure, automatically by the system or semi-automatically with the intervention of a user. Because every structured data object has at least its root node, the system can continue the execution of a process without interruption, when a link related to the process has been lost.
For example, there is a structured data object named “Organization,” which describes an enterprise's organizational structure. This organization model should be updated to a new version, each time a change occurs in the enterprise's organization. Suppose here that one member node of the old structured data object has become obsolete as a result of changes in the organization. In this case, messages addressed to the obsolete node can still be handled in the new organization model. That is, even if the node itself cannot be found in the new version, the structured data processing unit 3 will investigate the upper-level structure of the obsolete node in the old version, identify its parent node (or grandparent node, or the like) in the new version, and redirect the messages to that node.
The above approach, however, may not always work well, depending on the types and properties of structured data objects. Take other objects such as “Documentation System” and “Bill of Material” for example. In the case of this kind of structured data object, any attempt to redirect the messages to upper-level nodes would end up with unsuccessful results. When the specified destination node is found obsolete in a new structured data object of this kind, the structured data processing unit 3 locates relevant nodes in both old and new objects, and presents them to the user. This feature allows the user to specify or select which node should handle the messages, thus making it possible to continue the process.
There is still another group of structured data objects, to which the above automatic or manual message redirection cannot apply. A structured data object named “Items of Expense” is a typical object of this kind. To cope with such objects, the structured data processing unit 3 can optionally be configured to notify the system administrator of the contents of a message, when the destination of the message no longer exists.
As explained above, each structured electronic data object is associated with relevant process scripts that describe how the individual nodes will behave. Therefore, in the present invention, the user can easily change the process behavior (i.e., the content of processes), or locate a specific node or link that is causing a problem. If two or more instances of structured electronic data can be processed in an associated manner, the system will be a strong tool that totally supports a variety of business activities in the enterprise by linking many objects that express their structure and behavior.
FIG. 2 schematically shows the relationships among a plurality of data objects that may appear in an enterprise's business activities, where each single triangle represents a data object having a tree structure. This specific example of FIG. 2 includes five structured data objects named “Business Process” (4 a), “Bill of Material” (4 b), “Items of Expense” (4 c), “Organization” (4 d), and “Documentation system” (4 e). The links interconnecting these structured data objects 4 a to 4 e denote inter-node relationships.
By defining each individual inter-node relationship in this way, the business activities and services can be rendered as the relationships among many structured data objects. This results in a large network of structured data objects, which encompasses various aspects of concurrent business activities in a flexible manner, while involving a plurality of organizational units in the enterprise. Accordingly, the proposed system will be able to support the entire set of activities in the enterprise.
Further, the business support system of the present invention copes with frequent changes in the data structure that may happen during its operations. This is accomplished by storing both old and new versions of structured data objects and defining appropriate relationships between them.
FIG. 3 explains how to manage the structured data objects that vary over time, by illustrating three snapshots of a data model at times T1, T2, and Tn. In this specific example, three structured data objects 5 to 7 exist at time T1, being associated with each other. They are named “Al”, “B1,” and “C1,” respectively. The structured data object “A15 has its own internal structure, in which a node M is placed as a parent of two other nodes N1 and N2. There is a reference link from the structured data object “B16 to the node N1 in the structured data object “A15.
Suppose here that the node N1 is deleted at time T2, and the structured data object “Al” 5 is now revised to a new structured data object 5 a with the name “A2,” as shown in the central part of FIG. 3. In this object 5 a, only one node N2 remains under the top node M. Consider that a process script in the structured data object “B16 is executed at time T2, and an access request to the obsolete node N1 of the old structured data object 5 is issued. In this situation, the system can manage the change to continue the present process script execution, as long as the relationship between the old version “A15 and the new version “A25 a is known.
In general, the relationships between old and new versions of a structured data object can be classified into two types. The first type of relationships are called “implicit relationships,” which denote only a simple fact that one is new and the other is old, but provide no further details. The second type of relationships are called “explicit relationships,” which definitely describe how the nodes in the old structure are associated with their counterparts in the new structure. According to such relationships, the following steps will be executed.
First, a node in the structured data object “B1” attempts to make access to the node N1, expecting that it is in the structured data object “A2” (Step S1). The structured data object processing unit 3 (FIG. 1), however, recognizes that the specified destination node N1 is not present in the target object. It then refers to the old version “A1” (Step S2) and judges whether the relationship between “A1” and “A2” is explicit or implicit.
If the two versions have an explicit relationship, the structured data processing unit 3 continues the process according to the inter-node relationships being defined explicitly. Suppose, for example, that the new definition recites that the revised object A2 does not have a node corresponding to the node N1. The structured data processing unit 3 then prompts the user to enter an appropriate instruction, while showing him/her the current situation of both structured data objects A1 and A2. Consider another situation where the new definition suggests that the node N2 in the object A2 inherits the function of the old node N1. In this situation, the structured data processing unit 3 automatically continues the process by using the node N2 instead of N1 (Step S3).
If the relationship between A1 and A2 is implicit, the structured data processing unit 3 searches the original structured data object A1 to find a parent node of the node N1 (Step S4). The node M is what it is seeking in the current context of FIG. 3. Next, the structured data processing unit 3 tries to find this node M in the new structured data object A2. Since the node M is successfully found, the structured data processing unit 3 continues the process by using the node M instead of N1 (Step S5). At this step, the user will be notified by the system about how the process is reorganized. More specifically, the user is offered an opportunity to change the decision made by the system by specifying his/her preferable node. Now that the new destination is determined in this way, the process scripts in the structured data object B1 are updated so that their references to the obsolete node N1 will point to the new destination. This modification yields a new structured data object 6a with the name “B2.”
As described above, the system of the present invention is designed to preserve the old version of a structured data object when it is changed. This makes it possible for the system to continue the execution of a process by tracing explicit relationships between old and new structured data objects or comparing the structures of the two versions with each other. That is, a partial change in a structured data object does not interrupt the process execution, but will be automatically solved by a flexible mechanism. Although the above section has illustrated such a situation where one node is deleted, the present invention is not limited to this specific situation, but can be applied to other cases, including the division or consolidation of nodes.
Recall that the structured data processing unit 3 is designed to search for the parent of a lost destination node, when only an implicit relationship is given. This search, however, would end up with no good results if the parent node has been deleted together with its child node. In this case, the structured data processing unit 3 attempt to find its grandparent node, and if this search fails again, it then goes up to the next level of the tree structure. It should be noted here that the structured data processing unit 3 will finally find an alternative destination node, because the new and old structured data objects must share the root node by definition. This is why the system never stops the process execution, coping with any changes that have been made on the nodes.
In other words, this mechanism of the structured data processing unit 3 is analogous to how humans deal with an unexpected change by using their logical processing capabilities. Suppose, for example, that one staff has a problem and calls another section to talk to a person who would give him/her a good solution. But if that person (i.e., the destination node) cannot be reached, he/she will then bring the request to the chief of the section (i.e., the parent node of the lost destination). Consider another situation where an experienced person is stuck at a certain business process change that is new to him/her. In such a case, the person would try to continue the process, following the analogy of the old process that he/she is familiar with. This kind of human flexibility is implemented in the structured data processing unit 3 of the present invention.
Further, in the present invention, the structured data objects and their definitions, as well as process scripts associated with them, are maintained separately from the main system functions provided by the structured data processing unit 3. This arrangement permits the users to alter their system at any time, in a flexible manner. More specifically, the users can perform the maintenance of their system without stopping it. Or, in order to keep competitive in the ever-changing business environments, the users can alter the behavior of their business support system by modifying a process script associated with each node. This also enables incremental system development, from a simple tool to help a small work to an enterprise-wide integrated business support system. Since each data object is represented by a hierarchical tree structure, an incremental modeling approach can be applied to the system development. That is, the development starts with a broad definition of its fundamental tree structure, and additional support functions will then be gradually implemented by dividing a node into a plurality of low-level nodes.
Moreover, in the present invention, the nodes in a structured data object are associated with specific process scripts that describe how the individual nodes should work. That is, the system's behavior is defined by scripting a local process required in each individual node. This feature is advantageous because the user can easily change the process behavior. Also, in a problem situation, the user can locate a specific node or link that is causing the problem.
Now, the following section will describe the details of the present embodiment by illustrating a typical business support system as an application of the structured data management system of the present invention.
FIG. 4 is a block diagram of a business support system according to the present invention. This system consists of three parts: a message delivery subsystem, a business support processing subsystem, and a client environment. The message delivery subsystem comprises a message processor 10 and a timer event processor 11. The business support processing subsystem includes a processing engine 20, a structured data management unit 21, and a script interpreter 22. The client environment involves a client process 61 and various software tools such as an edit tool 62.
To make this system work as intended, several kinds of scripts should be written. They include:
scripts to define a business process model 30,
scripts to define an organization model 40,
scripts to define a documentation system model 50, and
a management/control script 73 to define how to operate the processing engine 20.
These scripts are stored in a hard disk or other storage media, and executed by the processing engine 20 after being loaded onto its main storage (semiconductor memory).
The business process model 30, organization model 40, and documentation system model 50 are called “management objects.” Actually, this term “management object” refers to what has been discussed as a structured data object and its corresponding process scripts in the conceptual view of FIG. 1. While the concepts represented by the management objects 30, 40, and 50 are different from each other, their data structure is defined in a unified style, containing the following elements:
document type definitions 31, 41, and 51 that define the basic structure of data objects,
instances 32, 42, and 52 created in accordance with the document type definitions, and
scripts 33, 43, and 53 that define specific processes associated with the elements in each document type definition or the nodes in each structured data object.
More specifically, the data type definitions 31, 41, and 51 and instances 32, 42, and 52 are written in the Standard Generalized Markup Language (SGML), an international standard for structured electronic documents. On the other hand, the process scripts are written in the Micro Post Script (MIPS), a scripting language whose syntax rules accept natural expressions in Japanese. It should be noted, however, that the MIPS scripts in the accompanying drawings are translated into English, although their original version is written in Japanese.
As such, two different language specifications, SGML and MIPS, are used the present invention. This is because they are helpful in clearly separating data from processes. SGML is a suitable foundation for document processing, which enables the user to easily describe the desired system structure by using flexible data modeling rules called “Document Type Definition” (DTD). Since the proposed system is designed to handle various business documents as one of the structured data objects shown in FIG. 1, SGML-based (i.e., structured) documents can readily be subjected to the system. MIPS, on the other and, offers a good readability for Japanese users, since it allows scripting in Japanese language.
Although the SGML and MIPS have been chosen in the preferred embodiment, the present invention is not limited to these particular language specifications. As an alternative to SGML, the Extensible Markup Language (XML), for example, can be used to produce DTDs. Further, instead of MIPS, any interpreter languages can be used for scripting processes.
Messages transmitted in the system of FIG. 4 include the following four types:
(1) messages sent from the client process 61 to the processing engine 20 in response to the user's keyboard/mouse operations,
(2) E-mail messages sent from processing engines in other systems (not shown in FIG. 4),
(3) messages sent from the timer event processor 11 at a predetermined time of day, and
(4) messages generated by a script in a management object to call up another script in a different management object.
Here, the client process 61 determines the destination nodes of the first type (1) of messages, based on the basis of the cursor position or mouse pointer position given by the user. The details will be described in a later section, with reference to FIG. 19.
The message delivery subsystem is a mechanism to transfer events, whose main functions are provided by the message processor 10. In the present embodiment, an electronic mail (E-mail) facility works as a vehicle of messages, where the message processor 10 acts as an SMTP server and POP server. The message processor 10 sends and receives E-mail messages 72 to/from the processing engine 20. The pending messages 72 are once saved in a message queue 71, and the message processor 10 processes them in a sequential manner. In the system illustrated in FIG. 4, the message processor 10 realizes inter-process communication across various business activities, interconnecting remote servers by using existing communication infrastructures. It is of course possible to use alternative mechanisms, as long as they can transfer event information necessary for the operations of the business support system.
The message queue 71 actually has two parts; one serves as the temporary storage for event messages, and the other serves as the storage for event log information. The first part of the message cue 71 keeps the messages, making a classification according to their originators. The stored information is used to check the present status of each process concerning individuals or some specialized groups. The second part, on the other hand, provides the system administrator with useful information for monitoring or managing the system. The timer event processor 11 generates a timer event at a specified time of day, in response to a request from the processing engine 20.
The business support processing subsystem plays a key role in the present embodiment. Note that the processing engine 20 contains no data or programs that directly relate to the business support functions. In fact, the operation of the processing engine 20 is wholly dependent on the definition of each management object. More specifically, the processing engine 20 is always activated by external events. Such trigger events include messages 72 and 75 sent from the message processor 10 and the client process 61, and timer event signals generated by the timer event processor 11. Depending on the content of each active process, a work list 74 written in the Hyper Text Markup language (HTML) is delivered from the processing engine 20 to the client process 61. This processing engine 20 is constructed within a World Wide Web (WWW) server, while the client process 61 is a WWW browser. Although FIG. 4 illustrates the processing engine 20 and client process 61 as separate entities, they can be implemented in a single machine.
The structured data management unit 21, together with the script interpreter 22, works as a server for the external environment outside the processing engine 20. It receives and manages SGML documents, or the structural definitions of management objects, to provide the script interpreter 22 with database services, responding to queries about nodes.
The script interpreter 22, on the other hand, parses and executes MIPS scripts which contain the process definition concerning each management object. The scripts offer database access functions and linkage with other systems, for example. They further provide instructions to the structured data management unit 21 for reading and writing SGML instances. Such instructions are called “operators,” and one can create a new operator by combining two or more operators.
The management/control scripts 73 can be divided into three groups as follows. The first kind of scripts are used to control the processing engine 20. For example, one script is used to load SGML documents related to a management object into the structured data management unit 21. Another script enables a specific process script of a management object to be transferred to the script interpreter 22. Still another script supports copyright protection for the scripts of management objects.
The second kind of management/control scripts are used to process a class of messages concerning administrative operations for the business support system. For example, one script provides such an agent process that responds to a query received through the message delivery subsystem. Another script updates a management object by applying a difference file received from the message delivery subsystem. Still another script automatically sends regular reports in cooperation with the timer event processor 11. As in the above second example, the management objects (including structured data objects and associated process scripts) can be automatically delivered to different sites, in order to maintain the up-to-date environment for business operations. This automatic data delivery service can extend to other computers via networks.
The third kind of management/control scripts are used to record the history of events and messages that have been processed by the processing engine 20. The collected history records can be used variously. For instance, they are subjected to process analysis, documented as audit records, or supplied to an application for debugging purposes. This kind of management/control scripts, however, may be integrated into the processing engine 20 as its native function.
Regarding the security issues, the system may require appropriate facilities for access control, data security, and copyright protection. Modern cryptography and electronic signature techniques can optionally be introduced to the system to protect the management objects. Here, some management/control scripts 73 will be used to decipher the protected scripts and to test the authenticity of electronic signatures. Security mechanisms for process scripts should be implemented as an integral part of the processing engine 20. This protects the enterprise's business activities from disruptions which may be caused by unauthorized modification of important program sources.
The client environment allows the user to interact with the system through a graphical user interface (GUI) provided by the client process 61. The client process 61 is actually a WWW browser application. The client environment further provides the edit tool 62 and other software development tools, including: a text editor and viewer, a spreadsheet application, a graphics tool, and client functions of other systems. The client process 61 sends messages to the processing engine 20 in response to inputs from the user or the edit tool 62. Further, when a work list 74 is received from the processing engine 20, the client process 61 displays it on the screen of a monitor unit. Both the client process 61 and edit tool 62 are installed on a computer located at the user's site.
The above-described system configuration conforms to the Model View Controller (MVC) architecture. That is, the proposed business support system comprises management objects (Model), the processing engine 20 and management/control scripts 73 (Controller), and the client environment and message delivery subsystem (View).
From another point of view, the combination of the processing engine 20, management objects, and E-mail messages may be interpreted as a combination of people, their knowledge, and work instructions. That is, the above system configuration is an analogy of daily activities in a human organization. In this system, the processing engine 20 is positioned as an “agent” that carries out some jobs for the user. Since the system handles electronic data with a human-like concept and structure, the user can easily understand its behavior. Besides being robust and maintainable, the system permits the user to gradually implement required business support functions by giving his/her expert knowledge to the agent.
The proposed business support system can be tested by imitating its external environment. This is accomplished by reconfiguring the system of FIG. 4 so that the client process 61 will emulate the user operations and the message processor 10 will emulate E-mail message transmission, while leaving the business support processing subsystem as it is. Another method of enabling such a simulated operation of the system might be to modify some scripts in each management object to stimulate the DTD and SGML instances associated with the scripts.
In this way, the behavior of some particular processes that are directly coupled to the external environment is emulated on the computer. This produces simulated events and inputs, which activates the processes related to structured data objects stored in the business support processing subsystem. In this simulated operation environment, the system will output the result faster than in the real environment.
FIGS. 5(A) and 5(B) are diagrams which provide supplementary information about management objects. FIG. 5(A) illustrates a management model 30 and relationships among its components, which include: a structure definition 31 (SGML-DTD), its instances 32 (SGML-instances), process scripts 33 a and 33 b (MIPS scripts), and relationship descriptions 34 a and 34 b (MIPS scripts). FIG. 5(B) shows the same relationships in the form of an object mapping diagram, which follows a common notation of cardinality constraints.
As shown in FIGS. 5(A) and (B), each script 33 contains one or more “methods” 33 c, where the term “method” is used as a synonym of the aforementioned “operator.” This script 33 corresponds to what is referred to as the “process script” being associated with each node within a structured data object shown in the conceptual view of FIG. 1. In the present invention, scripts can be associated with the structure definition 31, the instances 32, or both. More specifically, some elements of the structure definition 31 are associated with the scripts 33 a through the relationship descriptions 34 a, and some elements of the instances 32 are associated with other scripts 33 b through the relationship descriptions 34 b. Hereafter, the former scripts 33 a will be called “model-specific methods,” and the latter scripts 33 b will be called “instance-specific methods.”
The above object mappings make it possible to define some common model-specific methods representing such processes that will be shared by the same kind of nodes included in all instances. On the other hand, a process corresponding to a particular node in a particular instance will be defined as an instance-specific method. In this way, the proposed system clarifies the meaning and scope of each process.
The model-specific methods will determine the system's default operation, when there are no conflicting definitions of instance-specific methods. For example, a model-specific method associated with the structured data object “Business Process” offers a class of business support functions that are beneficial to almost all departments and sections. Additionally, each individual department or section can develop its own specialized support function by preparing instance-specific methods.
Another usage of model-specific methods might be a copyright protection of all SGML instances under a specific DTD. To implement this function, one should define an operator (or a model-specific method) that will add an electronic signature as an attribute of the SGML instances, and also place a relationship between the operator and relevant elements in the SGML instances. On the other hand, the copyright protection for a particular SGML instance will be accomplished by simply assigning the above operator to the SGML instance as an instance-specific method.
The present embodiment manages the object relationships in table form. Actually, the relationship descriptions 34, 34 a, and 34 b shown in FIGS. 5(A) and 5(B) are table-based definitions of relationships. The relationship descriptions 34 a and 34 b contain one or more table entries. When an element of the structure definition 31 or a node in the instances 32 is given, these table entries are used to identify a specific method that is associated with the given element or node.
FIG. 6 shows the contents of a relationship description. To simplify the execution of process scripts, the relationship descriptions 34 a and 34 b are constructed in the form of a table having three data fields named “logical destination address,” “message name,” and “method name.” As these names imply, a kind of message handling mechanism is employed to control the flow of a process which is passed from node to node. Just as in the case of an external message stimulating the system, a message issued from a node, or object, causes a transition of process flow.
The logical destination address is a combination of a management object name and a locator (e.g., XPointer) that specifies a node to the structured data management unit 21. The message name is used to determine the message types. Each message has different parameters depending on what kind of message it is. The method name indicates which method to choose and execute, from among those in a given script.
FIG. 6 illustrates a message 80 containing a logical destination address, a logical source address, a message name, and message-specific parameters. The processing engine 20 uses this information to reach the destination node and to read out the specified script, referring to a relevant relationship description. In the present embodiment, the relationship descriptions are prepared as separate data. Alternatively, they can be integrated into the structure definition or instances, and if this is the case, they are not necessarily defined in the form of tables.
Referring now to FIGS. 7 to 14, the following paragraphs will present the details of the organization model 40, documentation system model 50, and business process model 30 shown in FIG. 4.
In the present invention, a modeling methodology called the “Integrated Computer-Aided Manufacturing Definition Method 0” (IDEF0) is used to profile business operations in an enterprise. Once a business process model is formulated, it is then described in the SGML language specification. FIG. 7 shows an example of a business process model according to the IDEF0 notation. As illustrated in the legend at the lower-left corner of FIG. 7, each process unit, or activity, is represented as a single box 91, and input/output information to/from the process unit is indicated by four arrows in a classified way. They include; a left-side incoming arrow indicating inputs to the process, a top-side incoming arrow indicating control inputs that governs the process, a right-side outgoing arrow indicating outcomes of the process, and a bottom-side incoming arrow indicating mechanisms used in the process. This box, together with its associated arrows, is a basic unit of process representation. Every process flow is defined by placing boxes and connecting them with appropriate arrows. Even a hierarchical concept of processes can be expressed by using the same notation.
In the present example, an activity “Design management” 110 is on the top level (or top layer) of a business process model 100. Defined on the second level are the following three activities: “Drawing Quality Control” 111, “Work Cost Management” 112, and “Work Schedule Management” 113. Actually, these second-level activities 111 to 113 have their respective lower-level structures.
FIGS. 8(A) to 8(C) show the internal structure of activities on the second level. FIG. 8(A) means that two child activities, “Design Check” 111 a and “Design Rule Check” 111 b, are defined under the parent activity “Drawing Quality Control” 111. Likewise, as FIG. 8(B) shows, there are two child activities, “Development of Design Rules and Standards” 112 a and “Standardization of Workflow” 112 b, under the activity “Work Cost Management” 112. Further, under the activity “Work Schedule Management” 113, there are two child activities, “Planning of Daily Schedule” 113 a and “Progress Management” 113 b, as shown in FIG. 8(C). In this way, activities are defined in a hierarchical fashion.
FIG. 9 shows a structure definition of the business process model in more details. A structure definition 31 of a business process is provided as a DTD file presented in the upper half of FIG. 9. The concept described in this structure definition 31 can be pictured alternatively in a tree structure, as shown in the lower half of FIG. 9. In this example, an abstract concept named “Business Process” is defined at the root node, and its elements are defined as lower-level nodes. The structure definition 31 conforms to the IDEF0 modeling specification, where the element named “Resources” means what is called “mechanisms” in the IDEF0 terminology. Operators 33 aa to 33 ae are defined in association with the nodes 31 a to 31 e.
FIG. 10(A) shows the script of the operator 33 aa associated with the “Activity” node 31 a, and FIG. 10(B) shows a relationship description 34 a for the structure definition 31. In this example, a method (or operator) named “Close Work” is defined as a common default operation that is applicable to all instances of the “Activity” (e.g., “Design Management” and “Work Schedule Management”), because it is associated with the “Activity” node 31 a as a model-specific method.
FIG. 11 shows the definition of “Design Management” 32 a, an instance of the business process model. The content of this instance 32 a can be represented as a tree structure as shown in the lower half of FIG. 11, while the definition itself is written in SGML as shown in the upper half of FIG. 11.
In a similar way, the following section will present several examples of detailed definitions of the organization model and documentation system model.
FIG. 12 shows a typical structure definition 41 of the organization model, its DTD description on the left and its tree-structure representation on the right. In connection with this structure definition 41, two element nodes “Department” and “Section” in the “Organization” are associated with a common operator 43 a. FIG. 13(A) is the definition of this operator 43 a, while FIG. 13(B) shows a relationship description 44 a that defines the above node-to-operator association. More specifically, the structure definition 44 a has two entries corresponding to the elements “Department” and “Section,” both of which include a message name “Send Work” and an operator “Send Work.” In this way, the operator 43 a of FIG. 13(A) is associated to both of the two elements “Department” and “Section.”
FIG. 14 shows the definition of “Design Office” 42 a, an instance of the organization model 40. The upper half of FIG. 14 shows an SGML-based definition of this “Design Office” instance 42 a, while the lower half of FIG. 14 depicts the same in tree structure form.
FIG. 15 presents an example of the documentation system model 50, which includes its structure definition 51, its relationship description 54 a, and operators associated with its elements. According to the structure definition 51, the documentation system model 50 contains three elements named “Documentation System,” “Standard Specifications,” and “Location.” The relationship description 54 aassociates a “Create New Document” operator 53 a with the first element “Documentation System,” and a “View Document” operator 53 b with the second element “Standard Specifications.”
FIG. 16 shows an instance 52 a of the documentation system model 50, which is named “Design Document System.” On the left is an SGML-based definition of this instance 52 a, and on the right is a tree structure that visualizes the same.
Now, the following section will describe the operation of the present embodiment, citing the preceding figures (FIGS. 4 to 16) for reference.
FIG. 17 is a flowchart which shows a message handling process executed by the processing engine 20. As described earlier, the script interpreter 22 in the processing engine 20 receives event messages from external sources such as a user authentication process and the timer event processor 11, according to the management/control script 73 being loaded. The flowchart of FIG. 17 describes how the script interpreter 22 manipulates those incoming messages. The next section explains this process flow, assuming the system configuration of FIG. 4.
First, the structured data management unit 21 reads the DTD and instances of a management object to which the message is addressed (Step S11). Next, the structured data management unit 21 reads out a relationship description associated with the target instance. It then searches the relationship description for an entry that matches with the logical destination address and message name contained in the message, in an attempt to obtain the name of an operator that should be executed (Step S12). If a relevant entry is found in the relationship description, the process skips to step S14. Otherwise, it proceeds to step S13. When no relevant entry is found, the structured data management unit 21 searches another relationship description associated with the DTD to find an entry that matches with the logical destination address and message name contained in the message (Step S13). As a result of the data search conducted in step S12 or S13, the script interpreter 22 now has the operator name at hand. Accordingly, it reads out and executes the script of that operator. (Step S14). If it encounters a message to another element during the execution of the script, the script interpreter 22 spawns another process, and this child process deals with the new message in the same way as above. Note that the message can be transmitted as an E-mail message to another node, as shown in FIG. 17. The above steps are repeated until all messages are finished.
It should be noted here that in the process flow of FIG. 17, instance-specific methods take priority over model-specific methods. This permits the default behavior of element nodes to be defined as model-specific methods. It should also be noted that FIG. 17 illustrates only a principle of operation, but in actual implementations, one should take into consideration the performance and security issues.
FIG. 18 is a flowchart which shows how the processing engine 20 interacts with a user. This might be one the simplest examples of business support functions, which utilizes the default behavior definition provided by the model-specific methods. The client process 61 executes this sequence of FIG. 18, exchanging information with the processing engine 20. The next paragraph explains each step of the process, referring to FIG. 4 in addition to FIG. 18.
First, the user activates the client process 61 (WWW browser) and logs in to the processing engine 20 (WWW Server) (Step S21). In this log-in procedure, the user is requested to enter his/her user name and password. When the user has successfully logged in to the system, the processing engine 20 returns a list of activities to the client process 61. This list is called a “work item list” 74, which shows every possible activity (or work item in the present case) related to the user.
Upon receipt of the work item list 74 from the processing engine 20, the client process 61 displays it on the screen of a computer that the user is viewing (Step S22). On the computer screen, the user can check every work item that has been delivered through the E-mail facility, while some of the displayed items might not have sufficient resources for the user to start working. The user now selects one item out of the work item list 74 on the screen. This item selection will invoke the execution of a script that provides default business support functions. The process, in turn, will be closed when the user enters an exit command. Note again that the default script has to be provided as model-specific methods.
Now that the user has selected a work item, the client process 61 sends a “Show Work Details” message 75 to the activity corresponding to the selected work item. In response to this message 75, the processing engine 20 executes a “Show Work Details” operator, and as a result, detailed information on the selected work item is sent back to the client process 61. The client process 61 displays this information on the screen (Step S23). Browsing through the displayed information, the user chooses a document to manipulate, or alternatively, he/she makes a notification to the system as will be described later.
When the user has selected a document, the client process 61 then sends a prescribed message, such as “Show Document Details,” to a node associated with the document that the user has selected. In response to this message, the processing engine 20 executes a relevant operator and returns the result to the client process 61. The client process 61 then chooses an edit tool 62 suitable for the selected document and activates it as a separate process (Step S24). This edit tool 62 is, for example, a viewer 62 a or an editor 62 b.
Upon completion of his/her work with the edit tool 62, the user returns to the activity screen of step S23 and notifies the system of the completion. The client process 61 then presents a selection screen, where he/she is prompted to answer whether his/her output document has completed or not (Step S25). When the user selects a “Completed” button, the completion indication is transmitted to the next activity. On the other hand, no information is transmitted, in principle, when the user has selected a “Not Completed” button. It is, however, possible to configure the system to send some notification to the next activity, if a certain condition defined in a script is satisfied. When this step S25 is finished, the process returns to step S22 to display again a work item list. The steps S22 to S25 are then repetitively executed, until the user enters an exit command on the work item list screen.
More specific and detailed explanation of the above interaction will now be provided below, with reference to some example screens displayed by the client process 61.
FIG. 19 shows a series of example screens that would appear in the interactive process. In the log-in procedure (Step S21 in FIG. 18), a log-in screen 210 appears as the initial screen of the client process 61, which has a “User Name” input box 211 and a “Password” input box 212. The user enters his/her user name and password into these two boxes and clicks a “Send” button (i.e., places the mouse pointer on an on-screen button named “Send” and presses a mouse button). This operation directs the client process 61 to transmit the entered user name and password to the processing engine 20, thus conducting user authentication. The log-in screen 210 has a “Clear” button 214 to erase the present text entry in both the “User Name” input box 211 and “Password” input box 212.
If the user authentication process is successfully finished, the processing engine 20 supplies a work item list 74 to the client process 61. The client process 61 displays this list 74 on a “Work Item Lists” screen 220. In the present context of FIG. 19, this screen 220 proposes two work items 221 and 222 to the user. The first item 221 is what is shown in FIG. 8(A) as the “Design Check” activity 111 a, which is a child activity of the “Drawing Quality Control” activity 111 (FIG. 7) within the “Design Management” activity 110 (FIG. 7) defined as an instance of the business process model. The second item 222 is what is shown in FIG. 8(B) as the “Development of Design Rules and Standards” activity 112 a, which a child activity of the “Work Cost Management” activity 112 (FIG. 7) in the “Design Management” activity 110 (FIG. 7). An indicator is placed at the head of each work item 221 and 222 to show whether all necessary resource documents are ready or not. As the foot note on the screen 220 describes, a letter “C” means that all necessary documents are finished and ready for use in the corresponding work. A letter “P”, on the other hand, indicates that some necessary documents are not ready.
At the bottom line of the screen 220, a text string “Exit” 223 is placed to allow the user to exit from the present work with a mouse click on it. Note that the underlined text strings on the screens 220 and 230 are so-called hyperlinks, which enables the user to select items or trigger some actions by making a simple point-and-click operation with his/her mouse.
Suppose here that the user has selected the “Design Check” work item 221. In response to this selection, the client process 61 sends a “Show Work Details” message to the node representing the “Drawing Check” activity 111 a (FIG. 8). Since no instance-specific methods are associated with this “Drawing Check” node, the “Show Work Details” operator, a method common to all activity instances, is executed (See relationship description 34 a in FIG. 10). As a result of this execution, a work details screen 230 appears on the monitor, where the user obtains the detailed information on the “Drawing Check” work he/she selected (See step S23 in FIG. 18).
The work details screen 230 shows the names of an input document, control document, and output document in their respective display sections 231, 232, and 233. An indicator is placed at the head of each section to show whether the document is available or not. As the notation describes, a letter “A” means that the document is available, while a letter “N” indicates that the document is not available.
On the bottom line of the work details screen 230, there are two text strings that reads as: “Send Work” 234 and “Close/Suspend” 235. The former text string 234, if selected, will allow the user to assign the present work to another person. The latter text string, on the other hand, will bring the process flow to step S25 in the flowchart of FIG. 18.
Suppose here that the user has selected a text string “Drawings” on the present screen 230. In response to this selection, the client process 61 sends a “Show Document Details” message to the “Input Name” node of the “Design Check” business process instance. The message activates the script interpreter 22 in the processing engine 20 to execute a “Show Document Details” operator, which is a method common to all “Input Name” instances. In addition to this, a viewer application is invoked in the user's computer environment, thereby displaying the detailed contents of the “Drawings.” Note here that every activity produces its output, which means that the activities will not terminate themselves, until they finish output documents.
Upon completion of his/her work, the user selects the “Close/Suspend” on the work details screen 230. The client process 61 then displays a completion notification screen 240 to ask whether the user has finished the output document. On this screen 240, two check boxes, “Completed” 241 and “Not Completed” 242, are presented to the user, prompting him/her to select either one. When the user has a data file containing the result of design check, he/she has to enter the folder and name of the file into a text box 243, in addition to selecting the “Completed” check box 241. Clicking a “Browse” button 244 on the right of the text box 243 will call up a file selection window, which shows the directory structure of the computer in which the client process 61 is running, together with a file list in the current directory. The user can select a specific file from this list, instead of directly typing a directory name and file name and into the text box 243. A “Send” button 245 is placed on the bottom of the screen 240. When the user clicks this button, the client process 61 sends a notification message to the processing engine 20 to whether the output document is finished or not.
Recall here that in the “Drawing Quality Control” activity 111 of FIG. 8(A), the “Drawing Check” activity 111 a runs first and then the “Design Rule Check” activity 111 b follows. Referring next to FIGS. 20 to 22, the details of these two activities will be explained below, according to the order of operators to be activated.
FIG. 20 is a flowchart which shows a process executed by the processing engine 20 to help a staff in the Design Administration Department who has logged in to the system. The explanation will follow the step numbers affixed to each box in this flowchart. As the legend of FIG. 20 describes, bold arrows indicate the process transitions caused by messages sent from scripts; broken arrows indicate the process transitions caused by E-mail messages; dotted arrows indicate the process transitions caused by messages generated by user operations. Each box contains the name of a specific operator that is executed by the processing engine 20, as well as showing the resulting effects in parentheses.
In brief, the steps S31 to S59 describe the following situation. First, a staff in the Design Administration Department finishes his/her assignment, “Drawing Check.” Upon receipt of the design check results, the chief of the Quality Assurance Section assigns one of his/her staff for the next activity, “Design Rule Check.” The appointed staff then executes this task with the assistance of the system.
(S31) The processing engine 20 executes a “Close Work” operator associated with the “Activity” node in the “Business Process” management object. Note here that the current activity is “Design Check” under the “Drawing Quality Control” activity. The “Close Work” operator is one of the model-specific methods associated with the “Activity” node in the business process model (see FIG. 9 and FIG. 10(A)). The execution of this “Close Work” operator causes the transmission of a “Send Completion” message to the “Output” node.
(S32) The processing engine 20 executes a “Send Completion” operator associated with the “Activity.Output” node (i.e., “Output” node under the “Activity” node) in the “Business Process” management object. The execution of this operator results in the transmission of an “Accept Completion” message to an “Input Name” node that has the same name as the output name “Design Check Result.”
(S33) The processing engine 20 executes an “Accept Completion” operator associated with the “Input Name” node in the “Business Process” management object. This operator causes a “Send Work” message to a “Section” node with the name “Quality Assurance Section” in the “Organization” management object. Note that this node name derives from the “Resource Name” node under the current activity node.
(S34) The processing engine 20 executes a “Send Work” operator associated with the “Section” node in the “Organization” object. The execution of this operator results in the transmission of a “Check Start Condition” message to the next “Activity” node (i.e., “Design Rule Check”) in the form of an E-mail massage addressed to Mr. Suzuki, Chief of Quality Assurance Section.
The above process of FIG. 20 is continued to another flowchart of FIG. 21, which shows a process to help Mr. Suzuki who has just logged in to the system.
(S41) The processing engine 20 executes a “Register Work Item” operator associated with a “Work Item” node in a “Work Item” management object, where the “Work Item” is a management object to be used when the management/control script is executed. As a result of the execution of this operator, the E-mail message generated in step S34 is received, an “Activity” node is created, and after that, a “Check Start Condition” message is transmitted to the “Activity” node in the “Business Process” management object.
(S42) The processing engine 20 executes a “Check Start Condition” operator associated with the “Activity” node in the “Business Process” management object. As a result of the execution of this operator, it is tested whether all necessary documents are ready for the execution of the requested activity. Then a “Prepare for Work” message is sent to an “Activity” node of the “Work Item” management object.
(S43) The processing engine 20 executes a “Prepare for Work” operator associated with the “Activity” node in the “Work Item” management object. As a result of the execution of this operator, the properties and status of the “Activity” node are updated, and a “Show Work Item List” message is transmitted to a “Work Item” node.
(S44) The processing engine 20 executes a “Show Work Item List” operator associated with the “Work Item” node in the “Work Item” management object. This operator causes the client process 61 to display a list of work items.
(S45) The user, Mr. Suzuki, selects a specific work item. The processing engine 20 then executes a “Show Work Details” operator associated with the “Activity” node in the “Business Process” management object. This operator causes the client process to display the details of the selected activity.
(S46) Mr. Suzuki now directs the system to send the work to his/her staff members. The processing engine 20 then executes an “Assign Work” operator associated with the “Activity” node in the “Business Process” management object. As a result of the execution of this operator, the system prompts Mr. Suzuki to select an appropriate staff member. When the selection is finished, a “Check Start Condition” message is sent to the “Activity” node via E-mail.
The above process of FIG. 21 is continued to still another flowchart of FIG. 22, which shows a process to be executed when the selected staff member in the Quality Assurance Section logs in to the system.
(S51) The processing engine 20 executes a “Register Work Item” operator associated with the “Work Item” node in the “Work Item” management object. As a result of the execution of this operator, the E-mail message produced in step S46 is received, and an “Activity” node is created. After that, a “Check Start Condition” message is transmitted to the “Activity” node in the “Business Process” management object.
(S52) The processing engine 20 executes a “Check Start Condition” operator associated with the “Activity” node in the “Business Process” management object. As a result of the execution of this operator, it is examined whether all necessary documents are ready for the execution of the current activity, i.e., “Design Rule Check.” Such documents include: “Quality Standard,” “Product Cost Standard,” and “Design Check Result.” If all these documents are ready, a “Prepare for Work” message is sent to the “Activity” node in the “Work Item” management object.
(S53) The processing engine 20 executes a “Prepare for Work” operator associated with the “Activity” node in the “Work Item” management object. As a result of the execution of this operator, the properties and status of the “Activity” node are updated, and a “Show Work Item List” message is transmitted to the “Work Item” node.
(S54) The processing engine 20 executes a “Show Work Item List” operator associated with the “Work Item” node in the “Work Item” management object. This operator causes the client process 61 to display a list of work items.
(S55) Here, the user selects a specific work item. The processing engine 20 then executes a “Show Work Details” operator associated with the “Activity” node in the “Business Process” management object. This operator causes the client process 61 to display the details of the selected activity.
The user now carries out a task of “Design Rule Check” by viewing the input documents (S56), referring to the control documents (S57), and creating the output documents (S58). Finally, the user notifies the system of the completion of the task, thereby concluding his/her assignment (S59). As indicated by the dotted arrows, these steps are initiated by the user, and the processing engine 20 responds to him/her by executing a relevant operator as follows.
(S56) The processing engine 20 executes a “Show Document Details” operator associated with an “Activity.Input.Input Name” node in the “Business Process” management object. As a result of the execution of this operator, the document “Design Check Result” is displayed.
(S57) The processing engine 20 executes a “Show Document Details” operator associated with an “Activity.Control.Control Name” node in the “Business Process” management object. As a result of the execution of this operator, the documents “Quality Standard” and “Product Cost Standard” are displayed.
(S58) The processing engine 20 executes a “Create Document” operator associated with an “Activity.Output.Output Name” node in the “Business Process” management object. This operator enables the user to create documents “Design Standard” and “Final Drawings” with an editor application.
(S59) The processing engine 20 executes a “Close Work” operator associated with the “Activity” node in the “Business Process” management object. This operator causes a “Send Completion” message to be sent to the output tag.
In the way described above, the message initiated by the “Close Work” operator of the “Design Check” activity triggers another activity and another message. The messages are propagated from node to node, tracing the tree structures of “Business Process” and “Organization” management objects, as illustrated in FIGS. 20 to 22.
Referring next to FIG. 23, the following section will describe how the system deals with structural changes of objects.
In real-life organizational activities, changes are virtually a daily occurrence. As a matter of fact, a company's organizational structure, business operations, documentation systems, design rules, and standard specifications are all subject to continual changes. FIG. 23 schematically shows such structural changes by illustrating a business process object, an organization object, and a documentation system object, which have initial structures as explained in FIGS. 9 to 16. With the passage of time, the organization is restructured, the business process model evolves to more detailed levels, the documentation system is redefined and altered, and one business process produces a new business process. In FIG. 23, the circles symbolize scripts, the squares show structure definitions, and the triangles represent instances. Additionally, capital letters “P,” “O,” and “D” denote data objects of the business process model, organization model, and documentation system model, respectively. The superscripts attached to these symbols are identifiers that distinguish derivative management objects from their original management object. The subscripts, on the other hand, indicate each data's version numbers.
Initially, the system comprises a “Business Process-A” management object 311, an “Organization-A” management object 314, and a “Documentation System-A” management object 316. In the course of real-life business operation, there arises a need for more detailed modeling to support some particular business operations. Accordingly, the scripts and instances of the management object 311 are changed, and a new management object 312 is created as a new version of “Business Process-A.” On the other hand, to reuse the original management object 311 to support generic business activities, its replica is created as another management object 313 named “Business Process-B.”
Similarly, the scripts and instances of the “Organization-A” management object 314 are modified in accordance with a change in the enterprise's organizational structure, resulting in a management object 315 having a new version number. Further, a renewal of the “Documentation System-A” management object 316 is conducted, thus producing a new management object 317 having updated scripts, structure definition, and instances.
The next section presents several examples of structural changes.
FIG. 24 illustrates a change in an organizational structure, where an instance 331 is revised to another instance 332. In this example, a node named “Quality Assurance Section” in the original instance 331 has grown to “Quality Assurance Department” in the updated instance 332. This new department has two subordinate sections, “First Quality Assurance Section” and “second Quality Assurance Section,” which are newly established nodes. When implementing such a change into the business support system, it is necessary to investigate the influence of the change by searching the present structure definition of business processes to find all activities which involves the old “Quality Assurance Section.” Additionally, the existing methods that are specific to the old node of “Quality Assurance Section” should be changed so that the messages addressed to the old node will be automatically forwarded to the new nodes. By taking those measures, the system can deal with accidental references to the old node, or messages that have already been issued to the old node, thus being able to continue the service.
There is an alternative way of handling obsolete references to the old node “Quality Assurance Section” even after the change is implemented. More specifically, when a process script having a reference to the old node is encountered, the system will locate its child node, such as a node of Mr. Suzuki, ex-chief of the section. The system then makes a search for a relevant node in the new organization by using the name “Suzuki” as a keyword. This will allow the system to send a query to that node to ask how to handle the pending process.
Concerning the new nodes, they do not have to be fully furnished with a complete set of methods from the beginning. Rather, one can add new method definitions in an incremental manner, alleviating the expected impact of changes on the user environment. As described above, it is possible to clarify which part to modify and what steps to take toward expected changes. Actual tasks required are only to modify a part of the business process model and documentation system model related to the organization model. It is not difficult to develop a tool to support such tasks.
To incorporate detailed operations into the business process model, the SGML instance of FIG. 11 has to be changed. FIG. 25 shows an example of such a process change. In this specific example, a business process instance 341 initially includes an activity named “Work Schedule Management,” whose behavior is broadly defined at this stage. In a modified instance 342, the “Work Schedule Management” activity is divided into two child activities named “Daily Schedule Planning” and “Progress Management.” To update the model, the system would require no other things than modifying the instance, if the default methods provide sufficient functions. It is of course possible to define methods specific to the new instance. While some messages may still have a logical destination address to reach the old node, the system can handle them properly, if the new node “Work Schedule Management” has a new process script that transfers messages to its child nodes.
In the above case, the new business process model preserves old node names, and thus the messages addressed to the old node can reach a new node having the same node name. However, there may be such a situation where a node is renamed in the new business process model, meaning that a message addressed to such a node would be lost. In this case, the system would examine the old business process model to find a relevant department or section. The message would be transferred to this alternative destination, if available. It is also possible to configure the system to return the message to its sender, if there is no clue to identify the destination.
As described above, the business process model can be developed in a stepwise fashion, from a broad layout to detailed definitions. Since the model can be reconfigured easily and its output immediately reflects the alterations being made, the enterprise can keep competitive in today's ever-changing business environment.
The next example is a change in the documentation system definition. Since a change in the DTD will affect its instance, or the documentation system, the definition of the SGML instance of FIG. 16 should be changed, in addition to the DTD of FIG. 15. FIG. 26 shows an example of such a change in the documentation system definition. Originally, this documentation system contains only one element named “Standard Specifications” as shown in a structure definition 351. This primitive definition is changed to a new structure definition 352, in which the documents are classified into two new groups “Standards” and “Planning.” In addition, several lower-level nodes, such as“Design Standards” and “Design Planning,” are added to the structure to define appropriated default methods depending on the document types.
FIG. 27 illustrates a change in the documentation system instance which is caused by a renewal of the documentation system model shown in FIG. 26. In this example, an original instance 361 has changed to a new instance 362 having a different tree structure. The new structure has a node named “Design Plan Brief” and its two child nodes “Mechanical Design Plan” and “Logic Design Plan.” Although model-specific methods should be developed to provide better services to the user, it is still possible to apply the existing methods in most cases since the main concept of the documentation system is fully preserved. In spite of the structural changes described above, the processing engine 20 serves well for both the old and new versions of a documentation system since they are described in the same style.
In real-life activities, one business process sometimes produces its derivative processes. For example, a company divides itself into a plurality of companies to make their organization more competitive; a new project starts in a company; part of an existing process forms an independent process. It is not difficult, however, to define new business processes suitable for these cases. Typically, this can be accomplished by replicating a similar business process model and modifying the replica so that it will serve for the purpose.
FIG. 28 is a first diagram which shows how to reuse a business process model, assuming that a business process instance is changed as shown in FIG. 25. In FIG. 28, a relationship description 381 connects a structure definition 371 with a process script 382, by which a model-specific method named “Show Work Details” is defined in association with an “Activity” node in the business process model. A new structure definition 372 is now produced by replicating this structure definition 371.
FIG. 29 is a second diagram which shows how to reuse a business process model. Here, a new instance 392, a replica of an existing instance 391, is also produced in conjunction with the replicated structure definition 372. This instance 392 contains an activity named “Progress Management” which is associated with an instance-specific method named “Support Work” as described in a relationship description 401. The definition of this method is added to a process script 402 as a “Support Work” operator. This operator uses the “Show Work Details” operator, which is a model-specific method associated with an activity that has been inherited from the original business process model. The process script 402 defines that the “Support Work” operator finds all activities that are behind the schedule and then displays a list of such delayed activities with the “Show Work Details” operator. As the relationship description 401 shows, this “Support Work” operator is activated when a “Show Work Details” message arrives at the “Progress Management” activity.
The above example has shown that the system can provide such a service that is specific to a particular activity, without affecting other activities. Additionally, the new business process model can inherit almost all assets of process definitions from the old model, if the two models bear a close resemblance in their structures. Furthermore, the original and new business process models can be handled by the same processing engine without any interference between the two models, because they are defined as separate management objects.
The proposed processing mechanisms are actually implemented as hardware and software functions of a computer system. The process steps of the proposed data business support system are encoded in a computer program, which will be stored in a computer-readable storage medium. The computer system executes such programs to provide the intended functions of the present invention. The suitable computer-readable storage media include magnetic storage media and solid state memory devices. Some portable storage media, such as CD-ROMs (Compact Disk Read Only Memory) and floppy disks, are also suitable for circulation purposes. Further, it will be possible to distribute the programs through an appropriate server computer deployed on a network. The program file delivered to the user is normally installed in his/her computer's hard drive or other local mass storage devices, and executed after being loaded on the main memory.
The above discussion will now be summarized as follows. In the structured data management system of the present invention, appropriate process scripts are associated with nodes of a tree structure that represents a structured data object. The system provides services related to the structured data object by executing the process scripts of relevant nodes. It is easy for the system to deal with possible changes in the structured data object, since it is designed to trace the tree structure to determine which nodes to execute.
The structured data management program of the present invention is stored in a computer-readable medium. With this program executed on a computer, flexible operations to handle structured data objects, including their changes, will be realized.
The foregoing is considered as illustrative only of the principles of the present invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and applications shown and described, and accordingly, all suitable modifications and equivalents may be regarded as falling within the scope of the invention in the appended claims and their equivalents.

Claims (8)

What is claimed is:
1. A computer-readable storage medium for storing a structured data management program that provides services concerning a structured electronic data object, the structured data management program being designed to run on a computer to cause the computer to function as:
a structured data storage unit storing the structured data objects, each of which is expressed as a tree structure having a plurality of nodes representing units of data to be processed, each of the nodes being associated with a process script that defines what process should be executed; and
a structured data processing unit identifying a destination node in a particular one of the structured data objects stored in said structured data storage unit by tracing the tree structure of the particular structured data object according to a process request addressed to the destination node, executing the process script associated with the destination node according to the process request, and sending another process request to another node if required in the execution of the process script, wherein:
the particular structured data object is changed from a first version to a second version;
as a result of the change, one of the nodes defined in the first version of the particular structured data object becomes obsolete in the second version,
said structured data storage unit stores both the first and second versions of the particular structured data object in an associated manner, and
said structured data processing unit identifies an alternative destination node in the second version of the particular structured data object, upon receipt of a process request addressed to the obsolete node, by analyzing the tree structures of the first and second versions of the particular structured data object.
2. A structured data management system for providing services concerning structured electronic data objects, comprising:
a structured data storage unit storing the structured data objects, each of which is expressed as a tree structure having a plurality of nodes representing units of data to be processed, each of the nodes being associated with a process script that defines what process should be executed; and
a structured data processing unit identifying a destination node in a particular one of the structured data objects stored in said structured data storage unit by tracing the tree structure of the particular structured data object according to a process request addressed to the destination node, executing the process script associated with the destination node according to the process request, and sending another process request to another node if required in the execution of the process script wherein:
the particular structured data object is changed from a first version to a second version,
as a result of the change, one of the nodes defined in the first version of the particular structured data object becomes obsolete in the second version,
said structured data storage unit stores both the first and second versions of the particular structured data object in an associated manner, and
said structured data processing unit identifies an alternative destination node in the second version of the particular structured data object, upon receipt of a process request addressed to the obsolete node, by analyzing the tree structures of the first and second versions of the particular structured data object.
3. The structured data management system according to claim 2, wherein said structured data processing unit sends another process request to another node in another structured data object, if required in the execution of the process script.
4. The structured data management system according to claim 2, wherein said structured data processing unit provides business support functions by processing a structured data object that contains definitions of business processes.
5. The structured data management system according to claim 2, wherein said structured data processing unit automatically delivers the structured data objects and the process scripts.
6. The structured data management system according to claim 2, wherein said structured data processing unit performs security protection of the process scripts by using cryptography techniques.
7. The structured data management system according to claim 2, wherein said structured data processing unit simulates processes concerning the structured data objects by imitating external environments with a computer, when executing the process script.
8. The structured data management system according to claim 2, wherein said structured data processing unit performs security protection for each element of the structured data objects by using cryptography techniques.
US09/168,221 1998-04-15 1998-10-08 Structured data management system and computer-readable method for storing structured data management program Expired - Fee Related US6314434B1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP10-104266 1998-04-15
JP10426698A JP3912895B2 (en) 1998-04-15 1998-04-15 Structured data management system, computer-readable recording medium on which structured data management program is recorded, and structured data management method

Publications (1)

Publication Number Publication Date
US6314434B1 true US6314434B1 (en) 2001-11-06

Family

ID=14376136

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/168,221 Expired - Fee Related US6314434B1 (en) 1998-04-15 1998-10-08 Structured data management system and computer-readable method for storing structured data management program

Country Status (2)

Country Link
US (1) US6314434B1 (en)
JP (1) JP3912895B2 (en)

Cited By (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020059282A1 (en) * 2000-10-12 2002-05-16 Johan Andersson Object oriented data processing
WO2002045323A2 (en) * 2000-12-01 2002-06-06 Sri International Data relationship model
US20020073110A1 (en) * 2000-12-12 2002-06-13 Edouard Duvillier Version collection technique implemented on an intrinsic versioning information storage and retrieval system
US20020108101A1 (en) * 1999-10-05 2002-08-08 Dietrich Charisius Methods and systems for relating a data definition file and a data model for distributed computing
US20020138781A1 (en) * 2001-03-26 2002-09-26 Sony Corporation File management method, program therefor, recording medium containing the program, and file management apparatus for performing the method
US20020142273A1 (en) * 2001-03-30 2002-10-03 Dollins James T. Interactive process learning aid
US6476828B1 (en) * 1999-05-28 2002-11-05 International Business Machines Corporation Systems, methods and computer program products for building and displaying dynamic graphical user interfaces
US20020178394A1 (en) * 2000-11-06 2002-11-28 Naama Bamberger System for processing at least partially structured data
US20020188761A1 (en) * 2000-09-28 2002-12-12 Chikirivao Bill S. Data-type definition driven dynamic business component instantiation and execution framework
US20020188703A1 (en) * 2001-06-04 2002-12-12 Mckesson Information Solutions Holdings Ltd. Graphical tool for developing computer programs via specifications
US20030018628A1 (en) * 2001-07-18 2003-01-23 Yih-Ping Luh System and method for automated management of electronic information derivatives
US6513050B1 (en) * 1998-08-17 2003-01-28 Connected Place Limited Method of producing a checkpoint which describes a box file and a method of generating a difference file defining differences between an updated file and a base file
WO2003010691A1 (en) * 2001-07-26 2003-02-06 Thought, Inc. Method for creating distributed transparent persistence of complex data object
US6563521B1 (en) * 2000-06-14 2003-05-13 Cary D. Perttunen Method, article and apparatus for organizing information
US20030204835A1 (en) * 2001-03-30 2003-10-30 Versioning Method For Business Process Models Versioning method for business process models
US6647394B1 (en) * 1999-06-08 2003-11-11 International Business Machines Corporation Doing business employing linked trees having retrievable embedded information
US20030233420A1 (en) * 2000-04-03 2003-12-18 Juergen Stark Method and system for content driven electronic messaging
US6697784B2 (en) * 1998-04-30 2004-02-24 Enterworks Workflow management system, method, and medium with personal subflows
US6704873B1 (en) 1999-07-30 2004-03-09 Accenture Llp Secure gateway interconnection in an e-commerce based environment
US6718535B1 (en) 1999-07-30 2004-04-06 Accenture Llp System, method and article of manufacture for an activity framework design in an e-commerce based environment
WO2004038556A2 (en) * 2002-10-23 2004-05-06 David Theiler Method and apparatus for managing workflow
US20040103374A1 (en) * 2002-11-20 2004-05-27 Nec Corporation Function extension type browser, browser component, program and recording medium
US20040143597A1 (en) * 2003-01-17 2004-07-22 International Business Machines Corporation Digital library system with customizable workflow
US20040267796A1 (en) * 2003-04-25 2004-12-30 Yumiko Shimogori Data exchanger apparatus, data exchange method and program therefore
US6898621B2 (en) * 1998-04-24 2005-05-24 Fujitsu Limited Message processing device message management method and storage medium for storing message management program
US20060026568A1 (en) * 2001-07-05 2006-02-02 Microsoft Corporation System and methods for providing versioning of software components in a computer programming language
US7024670B1 (en) * 1998-12-17 2006-04-04 International Business Machines Corporation Timed start-conditions for activities in workflow management systems
US7046248B1 (en) 2002-03-18 2006-05-16 Perttunen Cary D Graphical representation of financial information
US7062535B1 (en) * 2000-04-03 2006-06-13 Centerpost Communications, Inc. Individual XML message processing platform
US20060259962A1 (en) * 2005-05-12 2006-11-16 Microsoft Corporation Method and system for performing an electronic signature approval process
US20060271606A1 (en) * 2005-05-25 2006-11-30 Tewksbary David E Version-controlled cached data store
US20060271583A1 (en) * 2005-05-25 2006-11-30 Microsoft Corporation Dimension member sliding in online analytical processing
US20070005618A1 (en) * 2005-06-07 2007-01-04 Konstantin Ivanov Systems and methods for modeling business processes
WO2007081677A1 (en) * 2006-01-04 2007-07-19 Microsoft Corporation Structured data storage
US7277931B1 (en) 1999-06-08 2007-10-02 International Business Machines Corporation Representing, configuring, administering, monitoring, and/or modeling connections using catalogs and matrixes
US20080068381A1 (en) * 2006-09-19 2008-03-20 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Using network access port linkages for data structure update decisions
US20080098016A1 (en) * 2003-01-31 2008-04-24 Yuji Ikeda Database system in which logical principles for a data retrieval process can evolve based upon learning
US20080163262A1 (en) * 2005-06-30 2008-07-03 Huawei Technologies Co., Ltd. Method and apparatus for implementing a predetermined operation in device management
US20090006459A1 (en) * 2003-08-12 2009-01-01 Michael T. Parks Presentation generator
US20090113394A1 (en) * 2007-10-31 2009-04-30 Sap Ag Method and system for validating process models
US7540012B1 (en) * 1999-06-08 2009-05-26 International Business Machines Corporation Video on demand configuring, controlling and maintaining
AU2003204382B2 (en) * 2002-06-03 2009-09-17 Microsoft Corporation Dynamic wizard interface system and method
US20100017401A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
US20100017486A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited System analyzing program, system analyzing apparatus, and system analyzing method
US20100036845A1 (en) * 2008-08-07 2010-02-11 Research In Motion Limited System and Method for Negotiating the Access Control List of Data Items in an Ad-Hoc Network with Designated Owner Override Ability
US20100037238A1 (en) * 2008-08-08 2010-02-11 Research In Motion Limited System and Method for Registration of an Agent to Process Management Object Updates
US20100110903A1 (en) * 2007-03-23 2010-05-06 Spott Martin W Fault location
US7853565B1 (en) * 2003-04-09 2010-12-14 Cisco Technology, Inc. Method and apparatus for efficient propagation of large datasets under failure conditions
US7895332B2 (en) 2006-10-30 2011-02-22 Quest Software, Inc. Identity migration system apparatus and method
US7904949B2 (en) 2005-12-19 2011-03-08 Quest Software, Inc. Apparatus, systems and methods to provide authentication services to a legacy application
US7984104B1 (en) 2000-04-03 2011-07-19 West Corporation Method and system for content driven electronic messaging
US8001523B1 (en) 2001-07-05 2011-08-16 Microsoft Corporation System and methods for implementing an explicit interface member in a computer programming language
US8087075B2 (en) 2006-02-13 2011-12-27 Quest Software, Inc. Disconnected credential validation using pre-fetched service tickets
US8086710B2 (en) 2006-10-30 2011-12-27 Quest Software, Inc. Identity migration apparatus and method
US8245242B2 (en) 2004-07-09 2012-08-14 Quest Software, Inc. Systems and methods for managing policies on a computer
US8255984B1 (en) 2009-07-01 2012-08-28 Quest Software, Inc. Single sign-on system for shared resource environments
US20120303396A1 (en) * 2011-05-27 2012-11-29 Sap Ag Model-based business continuity management
US8429712B2 (en) 2006-06-08 2013-04-23 Quest Software, Inc. Centralized user authentication system apparatus and method
US8447829B1 (en) 2006-02-10 2013-05-21 Amazon Technologies, Inc. System and method for controlling access to web services resources
CN103365960A (en) * 2013-06-18 2013-10-23 国家电网公司 Off-line searching method of structured data of electric power multistage dispatching management
US20140081600A1 (en) * 2012-09-20 2014-03-20 Fujitsu Limited Computer-readable recording medium having stored therein design support program, design supporting apparatus, and design supporting method
US8996482B1 (en) 2006-02-10 2015-03-31 Amazon Technologies, Inc. Distributed system and method for replicated storage of structured data records
US9454286B1 (en) 1999-02-03 2016-09-27 Cary D. Perttunen Representing purchasable item sizes using annulus sectors
US9680699B2 (en) 2006-09-19 2017-06-13 Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US10387270B2 (en) 2005-04-21 2019-08-20 Justservice.Net Llc Data backup, storage, transfer and retrieval system, method and computer program product
US10476868B2 (en) 2005-04-21 2019-11-12 Justservice.Net Llc Data backup and transfer system, method and computer program product
US10608921B2 (en) * 2018-04-19 2020-03-31 Cisco Technology, Inc. Routing in fat tree networks using negative disaggregation advertisements
US10783122B2 (en) * 2002-05-10 2020-09-22 Servicenow, Inc. Method and apparatus for recording and managing data object relationship data
US20230237394A1 (en) * 2022-01-26 2023-07-27 Qingdao Zhenyou Software Technology Co., Ltd. Intelligent management method and system for organizational structure, and medium

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3912895B2 (en) * 1998-04-15 2007-05-09 富士通株式会社 Structured data management system, computer-readable recording medium on which structured data management program is recorded, and structured data management method
JP2001202283A (en) * 1999-11-09 2001-07-27 Fujitsu Ltd System for monitoring contents updating situation
JP4529213B2 (en) * 2000-01-19 2010-08-25 富士ゼロックス株式会社 Element organization support apparatus and storage medium on which element organization support program is recorded
US7114123B2 (en) * 2001-02-14 2006-09-26 International Business Machines Corporation User controllable data grouping in structural document translation
US7392165B2 (en) * 2002-10-21 2008-06-24 Fisher-Rosemount Systems, Inc. Simulation system for multi-node process control systems
US7805324B2 (en) * 2004-10-01 2010-09-28 Microsoft Corporation Unified model for authoring and executing flow-based and constraint-based workflows
JP5232748B2 (en) * 2009-09-17 2013-07-10 東芝テック株式会社 Workflow display support apparatus and workflow display program

Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4987536A (en) * 1988-05-12 1991-01-22 Codex Corporation Communication system for sending an identical routing tree to all connected nodes to establish a shortest route and transmitting messages thereafter
US5226163A (en) * 1989-08-01 1993-07-06 Silicon Graphics, Inc. File characterization for computer operating and file management systems
US5430869A (en) * 1991-05-29 1995-07-04 Hewlett-Packard Company System and method for restructuring a B-Tree
US5553216A (en) * 1993-02-26 1996-09-03 Fujitsu Limited Structured database system together with structure definition frame storing document body data
US5671398A (en) * 1995-06-09 1997-09-23 Unisys Corporation Method for collapsing a version tree which depicts a history of system data and processes for an enterprise
US5706431A (en) * 1995-12-29 1998-01-06 At&T System and method for distributively propagating revisions through a communications network
US5805889A (en) * 1995-10-20 1998-09-08 Sun Microsystems, Inc. System and method for integrating editing and versioning in data repositories
US5819280A (en) * 1995-04-04 1998-10-06 Fujitsu Limited Data structure determining method for hierarchically structured data corresponding to identifiers and apparatus thereof
US5877766A (en) * 1997-08-15 1999-03-02 International Business Machines Corporation Multi-node user interface component and method thereof for use in accessing a plurality of linked records
US5897636A (en) * 1996-07-11 1999-04-27 Tandem Corporation Incorporated Distributed object computer system with hierarchical name space versioning
US5903902A (en) * 1996-09-09 1999-05-11 Design Intelligence, Inc. Design engine with tree and component structure
US5909688A (en) * 1993-10-29 1999-06-01 Fujitsu Limited Information management system
US5915259A (en) * 1996-03-20 1999-06-22 Xerox Corporation Document schema transformation by patterns and contextual conditions
JPH11296544A (en) * 1998-04-15 1999-10-29 Fujitsu Ltd Structured data management system and computer-readable recording medium where structured data management program is recorded
JPH11296541A (en) * 1998-04-14 1999-10-29 Fujitsu Ltd Structured data management system, and computer-readable recording medium recorded with structured data managing program
US6023691A (en) * 1998-12-22 2000-02-08 Ac Properties B.V. Goal based stimulator utilizing a spreadsheet architecture
US6108676A (en) * 1996-10-28 2000-08-22 Fuji Xerox Co., Ltd. Document processing apparatus, document type determining method, and hierarchical regular expression determining method
US6145119A (en) * 1997-03-31 2000-11-07 International Business Machines Corporation Programming development environment for intranet and internet applications employing unique project data structure
US6158044A (en) * 1997-05-21 2000-12-05 Epropose, Inc. Proposal based architecture system
US6182121B1 (en) * 1995-02-03 2001-01-30 Enfish, Inc. Method and apparatus for a physical storage architecture having an improved information storage and retrieval system for a shared file environment
US6226675B1 (en) * 1998-10-16 2001-05-01 Commerce One, Inc. Participant server which process documents for commerce in trading partner networks

Patent Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4987536A (en) * 1988-05-12 1991-01-22 Codex Corporation Communication system for sending an identical routing tree to all connected nodes to establish a shortest route and transmitting messages thereafter
US5226163A (en) * 1989-08-01 1993-07-06 Silicon Graphics, Inc. File characterization for computer operating and file management systems
US5430869A (en) * 1991-05-29 1995-07-04 Hewlett-Packard Company System and method for restructuring a B-Tree
US5553216A (en) * 1993-02-26 1996-09-03 Fujitsu Limited Structured database system together with structure definition frame storing document body data
US5909688A (en) * 1993-10-29 1999-06-01 Fujitsu Limited Information management system
US6182121B1 (en) * 1995-02-03 2001-01-30 Enfish, Inc. Method and apparatus for a physical storage architecture having an improved information storage and retrieval system for a shared file environment
US5819280A (en) * 1995-04-04 1998-10-06 Fujitsu Limited Data structure determining method for hierarchically structured data corresponding to identifiers and apparatus thereof
US5671398A (en) * 1995-06-09 1997-09-23 Unisys Corporation Method for collapsing a version tree which depicts a history of system data and processes for an enterprise
US5805889A (en) * 1995-10-20 1998-09-08 Sun Microsystems, Inc. System and method for integrating editing and versioning in data repositories
US5706431A (en) * 1995-12-29 1998-01-06 At&T System and method for distributively propagating revisions through a communications network
US5915259A (en) * 1996-03-20 1999-06-22 Xerox Corporation Document schema transformation by patterns and contextual conditions
US5897636A (en) * 1996-07-11 1999-04-27 Tandem Corporation Incorporated Distributed object computer system with hierarchical name space versioning
US5903902A (en) * 1996-09-09 1999-05-11 Design Intelligence, Inc. Design engine with tree and component structure
US6108676A (en) * 1996-10-28 2000-08-22 Fuji Xerox Co., Ltd. Document processing apparatus, document type determining method, and hierarchical regular expression determining method
US6145119A (en) * 1997-03-31 2000-11-07 International Business Machines Corporation Programming development environment for intranet and internet applications employing unique project data structure
US6158044A (en) * 1997-05-21 2000-12-05 Epropose, Inc. Proposal based architecture system
US5877766A (en) * 1997-08-15 1999-03-02 International Business Machines Corporation Multi-node user interface component and method thereof for use in accessing a plurality of linked records
JPH11296541A (en) * 1998-04-14 1999-10-29 Fujitsu Ltd Structured data management system, and computer-readable recording medium recorded with structured data managing program
JPH11296544A (en) * 1998-04-15 1999-10-29 Fujitsu Ltd Structured data management system and computer-readable recording medium where structured data management program is recorded
US6226675B1 (en) * 1998-10-16 2001-05-01 Commerce One, Inc. Participant server which process documents for commerce in trading partner networks
US6023691A (en) * 1998-12-22 2000-02-08 Ac Properties B.V. Goal based stimulator utilizing a spreadsheet architecture

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Dattolo et al., "Analytical Version Control Management in a Hypertext System," ACM 1994, pp. 132-139. *

Cited By (143)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6898621B2 (en) * 1998-04-24 2005-05-24 Fujitsu Limited Message processing device message management method and storage medium for storing message management program
US20050188041A1 (en) * 1998-04-24 2005-08-25 Fujitsu Limited Message processing device, message management method and storage medium for storing message management program
US6697784B2 (en) * 1998-04-30 2004-02-24 Enterworks Workflow management system, method, and medium with personal subflows
US6513050B1 (en) * 1998-08-17 2003-01-28 Connected Place Limited Method of producing a checkpoint which describes a box file and a method of generating a difference file defining differences between an updated file and a base file
US7024670B1 (en) * 1998-12-17 2006-04-04 International Business Machines Corporation Timed start-conditions for activities in workflow management systems
US9454286B1 (en) 1999-02-03 2016-09-27 Cary D. Perttunen Representing purchasable item sizes using annulus sectors
US6476828B1 (en) * 1999-05-28 2002-11-05 International Business Machines Corporation Systems, methods and computer program products for building and displaying dynamic graphical user interfaces
US6647394B1 (en) * 1999-06-08 2003-11-11 International Business Machines Corporation Doing business employing linked trees having retrievable embedded information
US7277931B1 (en) 1999-06-08 2007-10-02 International Business Machines Corporation Representing, configuring, administering, monitoring, and/or modeling connections using catalogs and matrixes
US7540012B1 (en) * 1999-06-08 2009-05-26 International Business Machines Corporation Video on demand configuring, controlling and maintaining
US6718535B1 (en) 1999-07-30 2004-04-06 Accenture Llp System, method and article of manufacture for an activity framework design in an e-commerce based environment
US6704873B1 (en) 1999-07-30 2004-03-09 Accenture Llp Secure gateway interconnection in an e-commerce based environment
US7188332B2 (en) * 1999-10-05 2007-03-06 Borland Software Corporation Methods and systems for relating a data definition file and a data model for distributed computing
US20020108101A1 (en) * 1999-10-05 2002-08-08 Dietrich Charisius Methods and systems for relating a data definition file and a data model for distributed computing
US20060259563A1 (en) * 2000-04-03 2006-11-16 Centerpost Communications, Inc. Individual XML message processing platform
US9083662B1 (en) 2000-04-03 2015-07-14 West Notifications, Inc. Method and system for content driven electronic messaging
US7984104B1 (en) 2000-04-03 2011-07-19 West Corporation Method and system for content driven electronic messaging
US7809855B2 (en) 2000-04-03 2010-10-05 West Notifications Group, Inc. Individual XML message processing platform
US20030233420A1 (en) * 2000-04-03 2003-12-18 Juergen Stark Method and system for content driven electronic messaging
US20060259562A1 (en) * 2000-04-03 2006-11-16 Centerpost Communications, Inc. Individual XML message processing platform
US8296371B2 (en) 2000-04-03 2012-10-23 West Corporation Individual XML message processing platform
US8326937B1 (en) 2000-04-03 2012-12-04 West Corporation Method and system for content driven electronic messaging
US7711849B2 (en) 2000-04-03 2010-05-04 West Notifications Group, Inc. Individual XML message processing platform
US8386569B2 (en) 2000-04-03 2013-02-26 West Corporation Individual XML message processing platform
US8655967B1 (en) 2000-04-03 2014-02-18 West Notifications, Inc. Individual XML message processing platform
US8706904B1 (en) * 2000-04-03 2014-04-22 West Notifications, Inc. Individual XML message processing platform
US7533152B2 (en) 2000-04-03 2009-05-12 West Notifications Group, Inc. Method and system for content driven electronic messaging
US20060265462A1 (en) * 2000-04-03 2006-11-23 Centerpost Communications, Inc. Individual XML message processing platform
US9300608B1 (en) 2000-04-03 2016-03-29 West Notifications, Inc. Individual XML message processing platform
US20070192422A1 (en) * 2000-04-03 2007-08-16 Centerpost Corporation Method and system for content driven electronic messaging
US20060259564A1 (en) * 2000-04-03 2006-11-16 Centerpost Communications, Inc. Individual XML message processing platform
US9634968B1 (en) * 2000-04-03 2017-04-25 West Notifications, Inc. Individual XML message processing platform
US10277541B1 (en) * 2000-04-03 2019-04-30 West Notifications, Inc. Individual XML message processing platform
US7062535B1 (en) * 2000-04-03 2006-06-13 Centerpost Communications, Inc. Individual XML message processing platform
US7177909B2 (en) * 2000-04-03 2007-02-13 Centerpost Communications, Inc. Method and system for content driven electronic messaging
US6563521B1 (en) * 2000-06-14 2003-05-13 Cary D. Perttunen Method, article and apparatus for organizing information
US9742614B2 (en) 2000-09-28 2017-08-22 Wellogix Technology Licensing, Llc Data-type definition driven dynamic business component instantiation and execution framework
US20020188761A1 (en) * 2000-09-28 2002-12-12 Chikirivao Bill S. Data-type definition driven dynamic business component instantiation and execution framework
US7016918B2 (en) * 2000-10-12 2006-03-21 Abb Ab Object oriented data processing
US20020059282A1 (en) * 2000-10-12 2002-05-16 Johan Andersson Object oriented data processing
US7233940B2 (en) * 2000-11-06 2007-06-19 Answers Corporation System for processing at least partially structured data
US20020178394A1 (en) * 2000-11-06 2002-11-28 Naama Bamberger System for processing at least partially structured data
WO2002045323A3 (en) * 2000-12-01 2003-02-06 Stanford Res Inst Int Data relationship model
US7133781B2 (en) 2000-12-01 2006-11-07 Sri International Biopolymer sequence comparison
WO2002045323A2 (en) * 2000-12-01 2002-06-06 Sri International Data relationship model
US7039238B2 (en) 2000-12-01 2006-05-02 Sri International Data relationship model
US20020073110A1 (en) * 2000-12-12 2002-06-13 Edouard Duvillier Version collection technique implemented on an intrinsic versioning information storage and retrieval system
US6789095B2 (en) * 2001-03-26 2004-09-07 Sony Corporation File management method, program therefore, recording medium containing the program, and file management apparatus for performing the method
US20020138781A1 (en) * 2001-03-26 2002-09-26 Sony Corporation File management method, program therefor, recording medium containing the program, and file management apparatus for performing the method
US20030204835A1 (en) * 2001-03-30 2003-10-30 Versioning Method For Business Process Models Versioning method for business process models
US20020142273A1 (en) * 2001-03-30 2002-10-03 Dollins James T. Interactive process learning aid
US9667468B2 (en) 2001-04-12 2017-05-30 Wellogix Technology Licensing, Llc Data-type definition driven dynamic business component instantiation and execution framework and system and method for managing knowledge information
US20020188703A1 (en) * 2001-06-04 2002-12-12 Mckesson Information Solutions Holdings Ltd. Graphical tool for developing computer programs via specifications
US20060026568A1 (en) * 2001-07-05 2006-02-02 Microsoft Corporation System and methods for providing versioning of software components in a computer programming language
US7873958B2 (en) * 2001-07-05 2011-01-18 Microsoft Corporation System and methods for providing versioning of software components in a computer programming language
US8001523B1 (en) 2001-07-05 2011-08-16 Microsoft Corporation System and methods for implementing an explicit interface member in a computer programming language
US20030018628A1 (en) * 2001-07-18 2003-01-23 Yih-Ping Luh System and method for automated management of electronic information derivatives
WO2003010691A1 (en) * 2001-07-26 2003-02-06 Thought, Inc. Method for creating distributed transparent persistence of complex data object
US20030046266A1 (en) * 2001-07-26 2003-03-06 Ward Mullins System, method and software for creating or maintaining distributed transparent persistence of complex data objects and their data relationships
US9135659B1 (en) 2002-03-18 2015-09-15 Cary D. Perttunen Graphical representation of financial information
US7830383B1 (en) 2002-03-18 2010-11-09 Perttunen Cary D Determining related stocks based on postings of messages
US7046248B1 (en) 2002-03-18 2006-05-16 Perttunen Cary D Graphical representation of financial information
US8228332B1 (en) 2002-03-18 2012-07-24 Perttunen Cary D Visible representation of a user's watch list of stocks and stock market indices
US8456473B1 (en) 2002-03-18 2013-06-04 Cary D. Perttunen Graphical representation of financial information
US8659605B1 (en) 2002-03-18 2014-02-25 Cary D. Perttunen Graphical representation of financial information
US7928982B1 (en) 2002-03-18 2011-04-19 Perttunen Cary D Visible representation of stock market indices
US10783122B2 (en) * 2002-05-10 2020-09-22 Servicenow, Inc. Method and apparatus for recording and managing data object relationship data
AU2003204382B2 (en) * 2002-06-03 2009-09-17 Microsoft Corporation Dynamic wizard interface system and method
US20100205033A1 (en) * 2002-10-23 2010-08-12 David Theiler Method and Apparatus for Managing Workflow
US7945465B2 (en) 2002-10-23 2011-05-17 David Theiler Method and apparatus for managing workflow
WO2004038556A3 (en) * 2002-10-23 2004-11-04 David Theiler Method and apparatus for managing workflow
US20040138939A1 (en) * 2002-10-23 2004-07-15 David Theiler Method and apparatus for managing workflow
US7729935B2 (en) * 2002-10-23 2010-06-01 David Theiler Method and apparatus for managing workflow
WO2004038556A2 (en) * 2002-10-23 2004-05-06 David Theiler Method and apparatus for managing workflow
US20040103374A1 (en) * 2002-11-20 2004-05-27 Nec Corporation Function extension type browser, browser component, program and recording medium
US20040143597A1 (en) * 2003-01-17 2004-07-22 International Business Machines Corporation Digital library system with customizable workflow
US7668864B2 (en) * 2003-01-17 2010-02-23 International Business Machines Corporation Digital library system with customizable workflow
US20080098016A1 (en) * 2003-01-31 2008-04-24 Yuji Ikeda Database system in which logical principles for a data retrieval process can evolve based upon learning
US8332398B2 (en) 2003-01-31 2012-12-11 Minolta Co., Ltd. Database system in which logical principles for a data retrieval process can evolve based upon learning
US7853565B1 (en) * 2003-04-09 2010-12-14 Cisco Technology, Inc. Method and apparatus for efficient propagation of large datasets under failure conditions
US20040267796A1 (en) * 2003-04-25 2004-12-30 Yumiko Shimogori Data exchanger apparatus, data exchange method and program therefore
US7761784B2 (en) * 2003-08-12 2010-07-20 Accenture Global Services Gmbh Presentation generator
US20090006459A1 (en) * 2003-08-12 2009-01-01 Michael T. Parks Presentation generator
US8429519B2 (en) 2003-08-12 2013-04-23 Accenture Global Services Limited Presentation generator
US20100241657A1 (en) * 2003-08-12 2010-09-23 Accenture Global Services Gmbh Presentation generator
US8713583B2 (en) 2004-07-09 2014-04-29 Dell Software Inc. Systems and methods for managing policies on a computer
US8533744B2 (en) 2004-07-09 2013-09-10 Dell Software, Inc. Systems and methods for managing policies on a computer
US8245242B2 (en) 2004-07-09 2012-08-14 Quest Software, Inc. Systems and methods for managing policies on a computer
US9130847B2 (en) 2004-07-09 2015-09-08 Dell Software, Inc. Systems and methods for managing policies on a computer
US10476868B2 (en) 2005-04-21 2019-11-12 Justservice.Net Llc Data backup and transfer system, method and computer program product
US11436095B2 (en) 2005-04-21 2022-09-06 Justservice.Net Llc Data backup, storage, transfer and retrieval system, method and computer program product
US11425116B2 (en) 2005-04-21 2022-08-23 Justservice.Net Llc Data backup and transfer system, method and computer program product
US10387270B2 (en) 2005-04-21 2019-08-20 Justservice.Net Llc Data backup, storage, transfer and retrieval system, method and computer program product
US20060259962A1 (en) * 2005-05-12 2006-11-16 Microsoft Corporation Method and system for performing an electronic signature approval process
US7958360B2 (en) * 2005-05-12 2011-06-07 Microsoft Corporation Method and system for performing an electronic signature approval process
US7716182B2 (en) * 2005-05-25 2010-05-11 Dassault Systemes Enovia Corp. Version-controlled cached data store
US20060271606A1 (en) * 2005-05-25 2006-11-30 Tewksbary David E Version-controlled cached data store
US7698349B2 (en) * 2005-05-25 2010-04-13 Microsoft Corporation Dimension member sliding in online analytical processing
US20060271583A1 (en) * 2005-05-25 2006-11-30 Microsoft Corporation Dimension member sliding in online analytical processing
US20070005618A1 (en) * 2005-06-07 2007-01-04 Konstantin Ivanov Systems and methods for modeling business processes
US8434094B2 (en) * 2005-06-30 2013-04-30 Huawei Technologies Co., Ltd. Method and apparatus for implementing a predetermined operation in device management
US8001231B2 (en) 2005-06-30 2011-08-16 Huawei Technologies Co., Ltd. Method and apparatus for implementing a predetermined operation in device management
US20080163262A1 (en) * 2005-06-30 2008-07-03 Huawei Technologies Co., Ltd. Method and apparatus for implementing a predetermined operation in device management
US7904949B2 (en) 2005-12-19 2011-03-08 Quest Software, Inc. Apparatus, systems and methods to provide authentication services to a legacy application
USRE45327E1 (en) 2005-12-19 2015-01-06 Dell Software, Inc. Apparatus, systems and methods to provide authentication services to a legacy application
US7747652B2 (en) 2006-01-04 2010-06-29 Microsoft Corporation Structured data storage
WO2007081677A1 (en) * 2006-01-04 2007-07-19 Microsoft Corporation Structured data storage
US10805227B2 (en) 2006-02-10 2020-10-13 Amazon Technologies, Inc. System and method for controlling access to web services resources
US9413678B1 (en) 2006-02-10 2016-08-09 Amazon Technologies, Inc. System and method for controlling access to web services resources
US10116581B2 (en) 2006-02-10 2018-10-30 Amazon Technologies, Inc. System and method for controlling access to web services resources
US8447829B1 (en) 2006-02-10 2013-05-21 Amazon Technologies, Inc. System and method for controlling access to web services resources
US8996482B1 (en) 2006-02-10 2015-03-31 Amazon Technologies, Inc. Distributed system and method for replicated storage of structured data records
US8584218B2 (en) 2006-02-13 2013-11-12 Quest Software, Inc. Disconnected credential validation using pre-fetched service tickets
US8087075B2 (en) 2006-02-13 2011-12-27 Quest Software, Inc. Disconnected credential validation using pre-fetched service tickets
US9288201B2 (en) 2006-02-13 2016-03-15 Dell Software Inc. Disconnected credential validation using pre-fetched service tickets
US8978098B2 (en) 2006-06-08 2015-03-10 Dell Software, Inc. Centralized user authentication system apparatus and method
US8429712B2 (en) 2006-06-08 2013-04-23 Quest Software, Inc. Centralized user authentication system apparatus and method
US9680699B2 (en) 2006-09-19 2017-06-13 Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US20080068381A1 (en) * 2006-09-19 2008-03-20 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Using network access port linkages for data structure update decisions
US8346908B1 (en) 2006-10-30 2013-01-01 Quest Software, Inc. Identity migration apparatus and method
US7895332B2 (en) 2006-10-30 2011-02-22 Quest Software, Inc. Identity migration system apparatus and method
US8966045B1 (en) 2006-10-30 2015-02-24 Dell Software, Inc. Identity migration apparatus and method
US8086710B2 (en) 2006-10-30 2011-12-27 Quest Software, Inc. Identity migration apparatus and method
US8213319B2 (en) * 2007-03-23 2012-07-03 British Telecommunications Plc Fault location
US20100110903A1 (en) * 2007-03-23 2010-05-06 Spott Martin W Fault location
US8660905B2 (en) 2007-10-31 2014-02-25 Sap Ag Method and system for validating process models
US20090113394A1 (en) * 2007-10-31 2009-04-30 Sap Ag Method and system for validating process models
US20100017486A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited System analyzing program, system analyzing apparatus, and system analyzing method
US20100017401A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
US8326977B2 (en) 2008-07-16 2012-12-04 Fujitsu Limited Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
US20100036845A1 (en) * 2008-08-07 2010-02-11 Research In Motion Limited System and Method for Negotiating the Access Control List of Data Items in an Ad-Hoc Network with Designated Owner Override Ability
US9882769B2 (en) * 2008-08-08 2018-01-30 Blackberry Limited System and method for registration of an agent to process management object updates
US20100037238A1 (en) * 2008-08-08 2010-02-11 Research In Motion Limited System and Method for Registration of an Agent to Process Management Object Updates
US9576140B1 (en) 2009-07-01 2017-02-21 Dell Products L.P. Single sign-on system for shared resource environments
US8255984B1 (en) 2009-07-01 2012-08-28 Quest Software, Inc. Single sign-on system for shared resource environments
US20120303396A1 (en) * 2011-05-27 2012-11-29 Sap Ag Model-based business continuity management
US8457996B2 (en) * 2011-05-27 2013-06-04 Sap Ag Model-based business continuity management
US20140081600A1 (en) * 2012-09-20 2014-03-20 Fujitsu Limited Computer-readable recording medium having stored therein design support program, design supporting apparatus, and design supporting method
CN103365960A (en) * 2013-06-18 2013-10-23 国家电网公司 Off-line searching method of structured data of electric power multistage dispatching management
US10608921B2 (en) * 2018-04-19 2020-03-31 Cisco Technology, Inc. Routing in fat tree networks using negative disaggregation advertisements
US11271844B2 (en) 2018-04-19 2022-03-08 Cisco Technology, Inc. Routing in fat tree networks using negative disaggregation advertisements
US11689442B2 (en) 2018-04-19 2023-06-27 Cisco Technology, Inc. Routing in fat tree networks using negative disaggregation advertisements
US20230237394A1 (en) * 2022-01-26 2023-07-27 Qingdao Zhenyou Software Technology Co., Ltd. Intelligent management method and system for organizational structure, and medium

Also Published As

Publication number Publication date
JPH11296544A (en) 1999-10-29
JP3912895B2 (en) 2007-05-09

Similar Documents

Publication Publication Date Title
US6314434B1 (en) Structured data management system and computer-readable method for storing structured data management program
US6336217B1 (en) Systems, methods and computer program products for end-to-end software development process automation
US6907546B1 (en) Language-driven interface for an automated testing framework
CN100547552C (en) The system and method that is used for the automatic management task
US7093247B2 (en) Installation of a data processing solution
US6502102B1 (en) System, method and article of manufacture for a table-driven automated scripting architecture
US6701514B1 (en) System, method, and article of manufacture for test maintenance in an automated scripting framework
US6144967A (en) Object oriented processing log analysis tool framework mechanism
US7363628B2 (en) Data centric and protocol agnostic workflows for exchanging data between a workflow instance and a workflow host
EP1269321B1 (en) Method and system for an automated scripting solution for enterprise testing
CN101351771B (en) Mechanism for obtaining and applying constraints to constructs within an interactive environment
EP2492806A1 (en) Unified interface for meta model checking, modifying, and reporting
WO2007050110A2 (en) Method and model for enterprise system development and execution
Belkhatir et al. THE ADELE-TEMPO experience: an environment to support process modeling and enaction
US20020111840A1 (en) Method and apparatus creation and performance of service engagement modeling
EP1234257A1 (en) Method for enforcing workflow processes for website development and maintenance
Clements et al. Discovering a system modernization decision framework: a case study in migrating to distributed object technology
Thomsen Database programming with C
van de Burgt et al. Testability of formal specifications
Kral Middleware orientation: Inverse software development strategy
Smith System support for design and development environments
Ballard et al. InfoSphere Warehouse: A Robust Infrastructure for Business Intelligence
WO2001009794A2 (en) A system, method and article of manufacture for an e-commerce based architecture
NIST Reference model for frameworks of software engineering environments
Westfechtel et al. Management System

Legal Events

Date Code Title Description
AS Assignment

Owner name: FUJITSU LIMITED, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHIGEMI, NOBUHISA;YAMAMOTO, HIROYUKI;TAZAKI, GENGO;AND OTHERS;REEL/FRAME:009519/0460

Effective date: 19980925

CC Certificate of correction
FEPP Fee payment procedure

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20131106