Patent Publication Number: US-8539441-B2

Title: Method and system for specifying and developing application systems with dynamic behavior

Description:
PRIORITY CLAIM/RELATED CASE 
     This application is a continuation of U.S. patent application No. 11/432,849 filed May 13, 2006, entitled “Method and System for Specifying and Developing Application Systems with Dynamic Behavior”, issued as U.S. Pat. No. 8,117,597 on Feb. 14, 2012, which claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application Ser. No. 60/681,420, filed on May 16, 2005 and entitled “Method and apparatus for modeling dynamic system behavior”, both of which are incorporated herein by reference in its entirety for all purposes. 
    
    
     CROSS-REFERENCES TO RELATED APPLICATION(S) 
     United Modeling Language (UML): Superstructure, Version 2.0, Aug. 2005. 
     Business Process Modeling Notation (BPMN), Version 1.0, May 3, 2004. 
     Process Definition Interface-XML Process Definition Language (XPDL), Version 1.0, Oct. 25, 2002. 
     Business Process Execution Language (BPEL) for web services, Version 1.1, May 5, 2003. 
     Web Services Choreography Description Language (WS-CDL), Version 1.0, Nov. 9, 2005. 
     Method and apparatus for specifying reactive systems (Dynamic State Machine), Apr. 30, 2003. 
     FIELD OF THE INVENTION 
     The present invention relates to flow charts, activity diagrams, business process, process modeling, work flow, state machines, protocol specifications, application software design and implementation. 
     BACKGROUND OF THE INVENTION 
     Traditionally, the system behavior are modeled in two different approaches. One focuses on internal active activities that a system performs, whereas the other focuses on behavior reacting to external events. This two-prong approach is reflected by the fact that Activity diagram, which focuses on active behavior, and Statechart, which focuses on reactive behavior, are two different styles of diagrams in United Modeling Language (UML). Let&#39;s call the former approaches “active behavior modeling” and the latter ones “reactive behavior modeling”. 
     Active behavior modeling includes flow chart, Business Process Modeling Notation (BPMN), XML Process Definition Language (XPDL), Business Process Execution Language (BPEL) and UML Activity diagrams. Both BPMN and UML Activity diagram use nodes in a diagram to represent activities to perform, while using links to connect one node to another representing the sequence of these activities. On the other hand, XPDL and BPEL define these activity nodes and their links in an XML syntax instead of a diagram. 
     While these active behavior modeling notations are useful in describing internal active behavior of a system, they are inadequate for defining reactive behavior in response to external events that may occur at any time. A typical approach is to have some special event detecting activities, such as “receive” in BPMN and BPEL, to detect these possible external events. Since external events can happen any time, various event detecting activities have to be inserted in various places in a diagram. However, unlike a state machine, these active behavior modeling diagrams don&#39;t have a “state” where all event detecting activities can be grouped together. The result is that these event detecting activities are scattered all over the places in a diagram and makes it very difficult to know what external events an application system is waiting for at any point in time during execution. 
     A major drawback of this approach is that if a correct detection activity is not inserted in a critical position in a diagram, some unexpected events will be left unprocessed and the application system may crash at run time. To overcome this problem, a designer may try to place various event detection activities all over the diagram. The result may be an overly complex diagram. 
     Another drawback is that since these event detection activities are inserted in a diagram in an ad hoc and unstructured way, it is very difficult to verify if the system behavior as defined in the diagram is consistent with other systems that it communicates with. This deficiency has caused many critical design problems with an application system that needs to interact with other systems. 
     While an active behavior modeling notation fails to provide an adequate facility to support reactive behavior in response to external events, a reactive behavior modeling notation is designed specifically to address this issue. 
     Reactive behavior modeling includes finite state machines (FSMs), UML Statechart, and Dynamic State Machine. A pure FSM includes a number of states and their outgoing transitions with external events dearly specified for each transition. While at a state, the FSM is waiting for all possible external events. Upon receiving a valid external event, a transition is triggered and an associated action is performed along with the transition. After a transition, the current state becomes inactive, and another state becomes active. The FSM then waits for another set of events associated with the new active state. Therefore, at any time, a FSM typically is in a particular state waiting for various possible external events to happen. 
     A pure FSM has a number of disadvantages. For example, one undesirable restriction is that a pure FSM has no memory. Due to its lack of memory, the usage of a pure FSM is very limited. Since a state in a pure FSM contains no memory, any change or information about history, such as a simple counter, must be presented by defining additional states in order to maintain these changes. Given the infinite number of values that a counter may have, an infinite number of states would be required. 
     Extended finite state machines (EFSMs) or Register Automata add memory or data variables to each state to contain values, such as numbers and counters, to overcome the major problem of a pure FSM as described above. EFSMs are widely used to model various reactive systems. 
     When EFSMs are used to model some real world events or behavior, it is often found that a hierarchical of states or nested states are useful to reduce the number of states and to organize a complex set of states into a hierarchy. Statechart as part of the United Modeling Language (UML) and STATEMATE are some examples. Statechart is the term used herein to refer to a hierarchical finite state machine. 
     Although a reactive behavior modeling notation is design to deal with external events, it typically overlooks how to specify complex internal active behavior. As we have already learned from using some active behavior modeling notations, these internal active behavior can be extremely complex. It would be highly desirable to incorporate an active behavior modeling notation that is consistent to the reactive behavior modeling notation. 
     Another common deficiency shared by existing active and reactive behavior modeling notations is that they can only specify the behavior of a single system. Complex internal messages exchanged among components inside of a super system are not modeled in any way. The lack of support for behavior of multiple parties is very limiting in a distributed computing environment where a system may contain multiple sub-systems who communicate with each other to coordinate their work. 
     In addition to above mentioned active behavior modeling and reactive behavior modeling, some other notations are designed to specify a protocol in between two interacting systems. Web Services Choreography Description Language (WS-CDL) is such an example. One possible application development procedure is to define a protocol in WS-CDL and then design the behavior of a participating system in another notation, such as BPEL, XPDL or BPMN. However, due to differences among these notations, mapping from a protocol to two participating systems and ensuring these two participating systems are compatible with each other can be problematic. 
     What is needed is a comprehensive approach to unify both active behavior modeling and reactive behavior modeling notations in a single consistent modeling notation that also supports dynamic behavior of multiple parties in the modern distributed computing environment. The present invention provides such a solution. 
     BRIEF SUMMARY OF THE INVENTION 
     This invention describes method and system for specifying and developing application systems with dynamic behavior. 
     One purpose of this invention is to improve how we specify dynamic behavior of an application system in diagrams to facilitate the development of such a system in a computer software or hardware. 
     Another purpose is to provide necessary mechanisms and methods so that design tools, code generators and run time platforms can be developed to realize the dynamic behavior specified. 
     In order to achieve these purposes, system for specifying dynamic application system behavior, procedures and methods about its operations, and methods about how to develop such a behavior model are provided in the present invention. 
     This invention uses a Dynamic System (DS) type for specifying dynamic behavior of an application system. A DS type can be either simple or composite. A simple DS type has a Behavior type for specifying simple behavior of the application system. A composite DS type (of model  1 ) has a number of Phased Machine (PM) types, which specify complex sequential and parallel behavior of the application system, and either an Exit-condition set or an exit function. Each PM type has one or more Phase types and an optional Static-count. Each Phase type has a sub-DS type and zero or more Transitions. Each Transition has a Transition-predicate and a Target-phase. 
     If an exit function is specified, it returns an exit code that identifies a condition under which an instance of the composite system type exits. If an Exit-condition set is specified, each Exit-condition has a pair of Exit-predicate that specifies a condition under which an instance of the composite system type exits and an exit-code that identifies the associated Exit-condition. 
     While one PM type may have a plurality of Phase types for specifying a sequential behavior of the composite DS, another PM type may have only one Phase type for specifying a parallel behavior of the composite DS. 
     The DS type can be specialized into a Proactive System (PS) type to specify the reactive behavior of a system that interacts with others in a distributed environment. A PS type is either simple or composite. A simple PS type is a specialization of the simple DS type. It&#39;s behavior has an External DS (Ext-DS) type followed by an Internal DS (Int-DS) type. The Ext-DS type specifies external incoming events to occur when communicating with another system, whereas the Int-DS type specifies internal actions to perform in response to the occurrence of those external events. A composite PS type is a specialization of the composite DS type. Hence, it is the same as a composite DS type except that it contains sub-PS types instead of sub-DS types. 
     An Ext-DS type is also a specialization of a DS type. An Ext-DS type is either simple or composite. A simple Ext-DS type is a specialization of the simple DS type with an Event type as its Behavior to specify an external incoming event type in a communication protocol. A composite Ext-DS type is a specialization of the composite DS type. Hence, it is the same as a composite DS type except that it contains sub-Ext-DS types instead of sub-DS types. 
     An Int-DS type is also a specialization of a DS type. An Int-DS type is either simple or composite. A simple Int-DS is a special kind of simple DS that has an Action type as its Behavior to specify an internal action to perform. A composite Int-DS s a specialization of the composite DS type. Hence, it is the same as a composite DS type except that it contains sub-Int-DS types instead of sub-DS types. 
     At run time, multiple instances of DS types, including PS types, Ext-DS types and Int-DS types, can be created. A DS instance is either simple as composite. A simple DS instance has a type reference to its DS type and a Result that records the outcome of performing its behavior. A composite DS instance has a type reference to its DS type, a Result, and a number of PM&#39;s. Each PM has a type reference to its PM type, a Current-phase, and a number of Phases. Each Phase has a type reference to its Phase type and a sub-DS instance. 
     After a DS instance is created, various parts of the DS instance can be activated and deactivated at run time to model the evolving behavior of a real world system. Similar to a DS instance, various parts of a Ext-DS instance, Int-DS instance and PS instance can be activated and deactivated at run time to model the evolving behavior of the corresponding real world system. 
     To specify an Int-DS to be performed immediately after a simple PS becomes active, a predefined “Entry” event type can be specified in the Ext-DS of the simple PS type. To specify an Int-DS to be performed immediately before a simple PS becomes inactive, a predefined “Exit” event type can be specified in the Ext-DS of the simple PS. 
     One main benefit of the present invention is that a single consistent general model based on DS is used throughout the design process while a particular specialization of this general model is used in each design step to focus on a specific behavior aspect. 
     Several design methods are provided in this invention so that the behavior of a system that interacts with others can be derived from its protocol specifications. First, following a generalized conversion method, a Participant-PS is derived from each Protocol that a role may support. Then, these Participant-PS&#39;s are merged into a single Role-PS. These design methods ensure that the specifications of the protocol and communicating parties are consistent with each other. 
     Some components used in these design methods are generalized so that they can also be used in other behavior modeling notations. The unspecified Ext-DS is generalized into an unspecified external activity that describes an activity to receive some unspecified external events. The unspecified Int-DS is generalized into an unspecified internal activity that describes an activity to perform some unspecified internal actions. 
     A generalized conversion method is used for converting a composite-activity from a protocol specification to a behavior specification of a participant. The method comprises: for each incoming simple-activity that describes an incoming event for the participant to receive, replacing the incoming simple-activity by a reactive composite-activity with the incoming simple-activity as its external activity and an unspecified internal activity that describes activities to perform in response to the occurrence of the incoming simple-activity; and for each outgoing simple-activity that specifies an event for the participant to send, replacing the outgoing simple-activity by a reactive composite-activity with an unspecified external activity that describes events to receive and the outgoing simple-activity as its internal activity to perform in response to the occurrence of the unspecified external activity. 
     Several exemplary embodiments are provided to apply similar methods to define reactive and active behavior using UML Statechart, UML Activity Diagram, BPMN, and BPEL notations. 
     Another method is provided to generate a protocol composite-activity for specifying a protocol from a participant composite-activity. The method comprises: copying a participant composite-activity that specifies a behavior of a participant; and changing each simple-activity that neither receives an incoming event nor sends an outgoing event to a null activity. 
     A graphical representation of these DS types, including PS types, Ext-DS types and Int-DS types, are provided in this invention. A DS type can be graphically represented as a containment box. A containment box representing a composite DS type may contain a number of sub-containment boxes, a number of bi-directional interaction links, a number of Creation arrows, a number of Transition arrows, and a number of Exit-points. Each of these sub-containment boxes represents either a simple or composite sub-DS. A composite sub-DS may be shown with its own sub-sub-containment boxes within its boundary. A sub-containment box with at least one Transition arrow represents a sequential sub-DS, whereas a sub-containment box without any transition arrow represents a parallel sub-DS. 
     A simple PS is graphically represented as a containment box with two sub-containment boxes. One of these sub-containment boxes represents the Ext-DS that specifies external events to receive and another sub-containment box represents the Int-DS that specifies internal activities to perform in response to the occurrence of the external events. 
     Reference to the remaining portions of the specification, including the drawings and claims, will realize other features and advantages of the present invention. Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with respect to accompanying drawings, like reference numbers indicate identical or functionally similar elements. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 
         FIG. 1  is a simplified block diagram showing an example of a distributed computing environment; 
         FIG. 2  is a simplified block diagram illustrating a computer system that can be used to implement the present invention; 
         FIG. 3  is a DS containing a tree of sub-DS&#39;s; 
         FIG. 4  is a simple DS; 
         FIG. 5  is a composite DS; 
         FIG. 6  shows an Exit-condition comprising a pair of explicit Exit-predicate and corresponding Exit-code; 
         FIG. 7  is the general life cycle of a DS; 
         FIG. 8  shows Protocol, Participant-PS and Role-PS; 
         FIG. 9  is a simple Ext-DS; 
         FIG. 10  is a simple PS; 
         FIG. 11  is a simple Int-DS; 
         FIG. 12  shows the matching procedure pseudo code in a graphical notation 
         FIG. 13  shows the react procedure pseudo code in a graphical notation 
         FIG. 14  shows the act procedure pseudo code in a graphical notation 
         FIG. 15A  is a Parallel PM with zero Transition to emulate a Parallel-element; 
         FIG. 15B  is a Parallel PM with only one Transition to emulate a Parallel-element; 
         FIG. 16  is a model  1  composite DS; 
         FIG. 17  is an exemplary graphical notation of a DS example; 
         FIG. 18  is another exemplary graphical notation of a DS; 
         FIG. 19  is an exemplary graphical notation of a composite PS example; 
         FIG. 20  shows an example composite PS containing a sub-PS with a composite Ext-DS 
         FIG. 21  is a composite PS with “Entry” and “Exit” predefined events; 
         FIG. 22  X-server Participant-PS without predefined “Entry” event; 
         FIG. 23  X-server Participant-PS with a predefined “Entry” event; 
         FIG. 24  shows type properties and instance properties of a simple DS; 
         FIG. 25  shows type properties and instance properties of a simple DS in UML class diagram; 
         FIG. 26  shows type properties and instance properties of a simple Ext-DS; 
         FIG. 27  shows type properties and instance properties of a simple Ext-DS in UML class diagram; 
         FIG. 28  shows type properties and instance properties of a simple PS; 
         FIG. 29  shows type properties and instance properties of a simple PS in UML class diagram; 
         FIG. 30  shows type properties and instance properties of a simple Int-DS; 
         FIG. 31  shows type properties and instance properties of a simple Int-DS in UML class diagram; 
         FIG. 32A  shows model  1  composite DS type with an exit condition set and instance; 
         FIG. 32B  shows model  1  composite DS type with an exit function and instance; 
         FIG. 32C  shows model  1  composite PS type and instance; 
         FIG. 33  shows the process to design, build and run DS based application software; 
         FIG. 34  shows the process to design a DS-based application and build it to run on various run time platforms; 
         FIG. 35  shows type properties and instance properties of a composite model  1  DS in UML class diagram; 
         FIG. 36  shows the composite PS type and instance of X-server Participant-PS type of  FIG. 23 ; 
         FIG. 37  shows a system “X” interacting with a client and a server; 
         FIG. 38  shows exemplary Protocol “protocol  0 ” and “protocol  1 ”; 
         FIG. 39  is the Participant-PS for “X-server” derived from “protocol  0 ” in FIG.  38 ; 
         FIG. 40  is the Participant-PS for “X-client” derived from “protocol  1 ” in  FIG. 38 ; 
         FIG. 41  is the Protocol “protocol 2 ”; 
         FIG. 42  shows how Participant-PS&#39;s are Combined into a Role-PS; 
         FIG. 43  shows how internal interactions and behavior are added; 
         FIG. 44  is the Role-PS of “X” using a composite Protocol “protocol 2 ”; 
         FIG. 45  shows “protocol  0 ” and “protocol  1 ” specified in UML Activity Diagram; 
         FIG. 46  shows “X-server” in UML Activity Diagram derived from “protocol 0 ” in  FIG. 45 ; 
         FIG. 47  shows “X-client” in UML Activity Diagram derived from “protocol 1 ” in  FIG. 45 ; 
         FIG. 48  shows that “X-server” and “X-client” are combined into a role composite-activity in UML Activity Diagram using a pair of fork and join nodes; 
         FIG. 49  shows “protocol  0 ” and “protocol  1 ” specified in BPMN; 
         FIG. 50  shows “X-server” in BPMN derived from “protocol 0 ”; 
         FIG. 51  shows “X-client” in BPMN derived from “protocol 1 ”; 
         FIG. 52  shows that “X-server” and “X-client” are combined into a Role-PS in BPMN using a pair of fork and join parallel gateways; 
         FIG. 53  shows that “X-server” and “X-client” are combined into a Role-PS in BPMN in a parallel box; 
         FIG. 54  shows “protocol  0 ” and “protocol  1 ” specified in Statechart; 
         FIG. 55  shows “X-server” in Statechart derived from “protocol 0 ”; 
         FIG. 56  shows “X-client” in Statechart derived from “protocol 1 ”; 
         FIG. 57  shows that “X-server” and “X-client” are combined into a Role-PS in Statechart; 
         FIG. 58  shows a protocol derived from “X-server” participant composite-activity; 
         FIG. 59  shows how to follow the design process described in this invention to design an application and build it to run on various run time platforms; 
         FIG. 60  shows a composite-activity with sequential and parallel sub-composite-activities, one of which is a reactive composite-activity; 
         FIG. 61  shows a composite-activity with sub-composite-activities, an Interaction-link and two Exit-points; 
         FIG. 62  shows a composite-activity with sequential and parallel sub-composite-activities, one Creation arrow and one Interaction-link; 
         FIG. 63  shows a composite-activity with sequential and parallel sub-composite-activities, and the external activity is linked to the internal activity by an arrow. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The present invention in the form of one or more exemplary embodiments will now be described. In the following description, numerous specific details are set forth in detail to provide a more thorough description of the invention. It will be apparent to one skilled in the art, however, that this invention can be practiced without these specific details. In other instances, well known features have not been described in detail so as not to unnecessarily obscure the invention. 
     Many of the real world systems have complex and dynamic behaviors. A behavior is complex because there are lots of elements involved. A behavior is dynamic because it evolves or changes over time. One guiding principle to model complex and dynamic behavior is to divide and conquer. The present invention uses Dynamic Systems (DS&#39;s) and sub-DS&#39;s to divide and model or specify any complex and dynamic behavior that may be present in a wide range of software or hardware systems in a real time or distributed environment as in  FIG. 1  as well as real world entities, such as people and organizations. 
     A distributed environment typically is made up of multiple hardware systems connected by a network. Each hardware system has a central processing unit (CPU), memory (ROM, RAM, and disks), and input and output devices as in  FIG. 2 . 
     The hardware system is a computer, which may be a Personal Data Assistant, a laptop, a desktop, a workstation, a mainframe, a real time control device, a networked equipment, or any of a variety of other devices providing computing and input/output capabilities. 
     In the present invention, types (or classes) and instances are differentiated. A type or class is a design time concept that specifies some behavior properties of an entity, whereas an instance is a run time entity whose behavior property is defined by a particular class. Unless explicitly described as a class, a term in the present invention typically refers to an instance. 
     Specifying Dynamic Behavior Using the DS 
     In order to divide complex system behavior into smaller components, this invention borrows the idea from a common sense that the universe we live in has two fundamental dimensions, namely time and space. Along the time dimension, a composite system can be divided into sequential sub-DS&#39;s, while along the space dimension, a composite system can be divided into parallel sub-DS&#39;s. At any point in time and space, a DS can be decomposed into multiple sequential sub-DS&#39;s and multiple parallel sub-DS&#39;s. Each sub-DS may also be further decomposed into its own sub-DS&#39;s along these two dimensions. 
     In general, a DS may contain a set of sequential sub-DS&#39;s and a set of parallel sub-DS&#39;s. Since each of these sub-DS&#39;s may have its own sub-DS&#39;s, a DS typically contains a tree of sub-DS&#39;s. An intermediate DS in this tree can be viewed as a super-DS with regard to its sub-DS&#39;s, and as a sub-DS with regard to its super-DS. Hence, a DS may be called a DS, a super-DS or a sub-DS depending on the context it is referred to. For example, as shown in  FIG. 3 , DS 0  is a super-DS of DS 1  and DS 2 . Hence, DS 1  is a sub-DS of DS 0 . However, DS 1  is also a super-DS of DS 3  and DS 4 . 
     When specifying the behavior of a system in an interconnected world, both external and internal readiness need to be considered. Typically, a particular action can be performed only when both the system itself is ready and certain external conditions are met. The present invention also reflects these interdependencies among systems. 
     A DS can be either simple or composite. A simple DS ( FIG. 4 ) has a Behavior and a Result. The Behavior describes the behavior of a DS and the Result may be used by the Behavior to record the final outcome after the behavior is completely performed. An exemplary Behavior may specify that when a certain condition is met, the DS performs a particular action. 
     Note that in  FIG. 4  The simple DS is shown as a box with a label on the top. Components are shown as smaller boxes inside of the containing box. This is the convention used in this document. 
     A composite DS ( FIG. 5 ) has following components:
     zero or more Phased Machines (PM&#39;s)  501  that represent the sequential part of behavior of the composite DS.
       Each PM has one or more Phases  502  and a Current-phase  503 .
           When a PM becomes active, one of its Phases becomes active. While the PM is active, its Phases are being activated and deactivated according to their Transition specifications. In general, while the PM is active, at most one of its Phases can be active.   A normal Phase has a sequential sub-DS  504  and zero or more Transitions  505 .
               The sequential sub-DS contains the behavior of the Phase. It can be either a simple or composite DS.   Each Transition has a Transition-predicate  506  and a Target-phase  507 .
                   When a Current-phase subsequently becomes inactive, another Phase is selected to become active. A Transition specifies that if its Transition-predicate is evaluated as true, its Target-phase is the next phase to become active after the transition. The Transition-predicate may use information in the Result of the sequential sub-DS or any other information available to it at run time for the evaluation.   The Target-phase in any Transition must refer to one of the Phases in the same PM. In other words, transition cannot go beyond the boundary of a PM. Note that a particular Phase can be the target of more than one other source Phases. In addition, cyclical transitions are allowed, including transitioning to Current-phase itself. This is how a repetitive behavior can be specified.   Since at most one Phase can be active at any time, all those Transition-predicates of the same source Phase must be mutually exclusive.   
                   
               the Current-phase is a pointer or reference to the currently active Phase in the PM at run time.   For setting the Current-phase, a PM may have two kinds of special phases.
               One special phase is the Initial-phase. A PM can have at most one Initial-phase. The Initial-phase is used to select the first Phase to become active when the PM becomes active. This Initial-phase has a dummy null sequential sub-DS and a list of initial Transitions.   Another special phase is the Null-phase. When the Current-phase of a PM refers to a Null-phase, the entire PM has became inactive. A PM may have zero or more user defined Null-phases and a default Null-phase. A Null-phase is a phase without any sub-DS nor Transition defined. It only has a unique ID that differentiates one Null-phase from another in a PM and the default Null-phase has a predefined unique ID that is different from any user defined Null-phase in the same PM. The ID of a Null-phase can be used by the Exit-condition or Exit-predicate (described below) to determine if a composite DS should exit or not.   
               
           
       zero or more Parallel-elements  508 
       Each Parallel-element has a parallel sub-DS  509  that represents part of the parallel behavior of the composite DS, an optional Static-count  510 , and a Mode  511  that indicates whether the corresponding parallel sub-DS is active or inactive at run time.
           The optional Static-count is a number that indicates how many static instances of the parallel sub-DS is to be created when its containing composite DS is created. If no Static-count is specified, the default value of Static-count is 1 and one instance of the parallel sub-DS is always created when its containing composite DS is created. In addition to these statically created instances, other instances of the parallel sub-DS may be dynamically created by a user defined Behavior at run time. Dynamically created sub-DS&#39;s are called dynamic sub-DS&#39;s, whereas those sub-DS&#39;s created along with its super-DS are called static sub-DS&#39;s. The dynamic sub-DS is useful when the number of instances of a parallel sub-DS is not known at design time, but can only be found out at run time.   When a parallel sub-DS becomes active at run time, its Mode is set as “active”. When the parallel sub-DS becomes inactive at run time, its Mode is set as “inactive”.   When a composite DS becomes active, all its parallel sub-DS instances become active.   Each of these parallel sub-DS&#39;s can be either simple or composite.   
           
       An Exit-condition set  512  with zero or more Exit-conditions, where each Exit-condition  600  specifying a condition under which the entire composite DS should become inactive and exit. Each Exit-condition comprises a pair of explicit Exit-predicate  601  and its corresponding Exit-code  602  ( FIG. 6 ). The Exit-predicate can be specified as a logical expression, a mathematical formula or symbol, or a description in text. The Exit-code is unique among all Exit-codes within the same Composite DS. It is typically a number that is either generated by a design tool or specified by a designer. When one Exit-predicate is tested to be true at run time, the composite DS exits and its corresponding Exit-code is recorded in the Result of the composite DS to indicate under which condition the composite DS exits. Alternatively, the Exit-condition set can be specified by defining an exit function, which is either a procedure or function of a functional programming language or a method of an object-oriented programming language. The exit function uses a list of implicit Exit-predicates internally to decide whether any Exit-condition is met or not at run time, and returns the corresponding Exit-code to indicate which particular Exit-predicate that is evaluated as true.
       One exemplary Exit-predicate is that when any PM or parallel sub-DS exits, the composite DS exits.   Another exemplary Exit-predicate is that when one particular parallel sub-DS exits, the composite DS exits.   If no Exit-condition is specified in the Exit-condition set, the default Exit-condition is that when all PM&#39;s and all parallel sub-DS&#39;s become inactive, the containing composite DS becomes inactive and a predefined default Exit-code is recorded in the Result. This default Exit-condition is always in effect in any composite DS.   
       a Result  513  for the entire composite DS. The Result records the Exit-code returned by the exit function, or, if an Exit-condition set is specified, it records the Exit-code whose corresponding Exit-predicate is evaluated as true.   

     Note that if more than one instance of a particular component is allowed, the component is shown in the diagram with a shade. For example, within a composite DS, there can be a number of PM&#39;s and Parallel-elements, and within a PM, there can be one or more Phases, which may have a number of Transitions. Hence, each of PM, Parallel-element, Phase and Transition is shown with a shade as in  FIG. 5 . 
     Many real world systems display different behavior as time passes. To model the changes of behavior over time, some part of a DS is activated and deactivated as time passes and only the active part of the DS is in effect at any point in time. Hence, the way to control the changing behavior is by controlling when to activate and deactivate sub-DS&#39;s within a DS. 
     The general life cycle of a DS ( FIG. 7 ) is that after it is created, it may become either active or inactive. An active DS becomes inactive when its behavior completes or ends. A DS (either active or inactive) can be destroyed when it can no longer become active again. In  FIG. 7 , a rectangle box represents a phase, and a phase may have a label (such as “Created”) attached to it. An arrow represents a transition from one phase to another. A small empty rectangle on the boarder represents an Initial-phase or a Null-phase, which indicates that the DS does not exist (either before it is created or after it is destroyed). A phase may contain sub-phases. For example, the “Created” phase contains “Active” and “Inactive” sub-phases. 
     A DS instance as specified by a DS type can be created by loading relevant code and data into memory or a persistent storage device at run time. However, the exact procedures for creation and destruction of a DS is not essential to this invention, hence, is left for an application system, which is an embodiment of this invention that executes DS or DS derived models, to decide. The application system only needs to ensure that after a DS instance is created, all its static components are created and the DS and all its components are ready to be activated and deactivated until the DS is finally destroyed. Specific activation and deactivation procedures of a DS are described below. 
     The run time activation and deactivation procedure of a simple DS ( FIG. 4 ) is as follows:
         When a simple DS becomes active, its Behavior is performed.   After its Behavior is performed, the outcome is recorded in the Result, and the simple DS subsequently becomes inactive.       

     The run time activation and deactivation procedure of a composite DS ( FIG. 5 ) is as follows:
         When a composite DS becomes active, all its PM&#39;s and static Parallel-elements become active.   When a Parallel-element becomes active, its parallel sub-DS becomes active and its Mode is set as “active”.   When a PM becomes active, one of its Phases (including its sequential sub-DS) becomes active.   The first active Phase is selected in the follow way. If there is only one Phase in the PM, that Phase is selected as the Current-phase to become active. Otherwise, one of the Phases must be the Initial-phase, which is required for the selection procedure. The Transition-predicates of these initial Transitions are evaluated when a PM becomes active. If one Transition-predicate is evaluated as true, its associated Target-phase is selected as the next Current-phase to become active after the transition.   When a Sequential or parallel sub-DS (either simple or composite) becomes active, the same behavior described here for either simple or composite DS is repeated recursively for that sub-DS.   When a parallel sub-DS subsequently becomes inactive, its corresponding Mode is set as “inactive”.   When a sequential sub-DS subsequently becomes inactive, its Phase becomes inactive and its Transition-predicates are evaluated. When one Transition-predicate is evaluated as true, its associated Target-phase (may be a dummy Null-phase) is the next phase to become active after the transition and the Current-phase is changed to the Target-phase. If no Transition-predicate is evaluated as true, the default is to change the Current-phase to the default Null-phase.   When the Current-phase is changed to a Null-phase, the entire PM becomes inactive.   Whenever any PM or Parallel-element becomes inactive, the Exit-condition set is evaluated. If a set of Exit-predicate and Exit-code pair is explicitly specified ( FIG. 6 ) in an Exit-condition set, whenever an Exit-predicate is evaluated to be true, its corresponding Exit-code is recorded in the Result and the composite DS becomes inactive. If an exit function is specified, it tests each Exit-condition, and if any Exit-condition is met, an appropriate Exit-code is recorded in the Result and the composite DS becomes inactive. Otherwise, the composite DS remains active.   When a composite DS becomes inactive, all its PM&#39;s (along with their active sequential sub-DS&#39;s) and Parallel-elements (along with their parallel sub-DS&#39;s) become inactive.       

     Repetitive behavior may be specified in a repetitive Phase. A repetitive Phase is a Phase that has itself as the Target-phase in one of its Transitions. 
     In the present invention, recursive DS&#39;s are supported. A recursive DS has one or more sub-DS&#39;s with the same type or class as itself or one of its direct or indirect super-DS&#39;s. With recursive DS&#39;s, the same behavior typically repeats recursively in ever smaller scopes. The recursion is usually terminated by a choice that no further recursive sub-DS would be required. 
     The benefits of using DS for dynamic behavior modeling are that
         its composition structure directly reflects the fact that we live in a universe with both time and space dimensions and that these dimensions are orthogonal to each other;   Viewing things in both time and space dimensions is natural to human minds. It also adds significant meaning on top of a bunch of nodes and links typically defined in many existing behavior specification techniques. Hence, it is easy to learn and comprehend;   By activating and deactivating various sub-DS&#39;s, the behavior of a DS can evolve over time in a well controlled way;   The Exit-condition set with a number of Exit-predicates and Exit-codes provides a powerful and flexible mechanism to control when a composite DS should end;   Unlike many existing behavior specification techniques with fork and join nodes, the containment box of a composite DS maintains a dean life cycle boundary for all its components.   Since each sub-DS in a composite DS can be composite, it supports recursive specifications of behavior in ever refined details;   By supporting repetitive phases and dynamic parallel sub-DS&#39;s, repetitive behavior and dynamic behavior can also be specified.
 
Specialization of DS into Ext-DS, PS, Int-DS
       

     Although DS is a very powerful tool to describe dynamic behavior, to fully specify the behavior of an application system that interacts with multiple peer systems in a distributed environment, we need three kinds of specialization of a DS. One is the External DS (Ext-DS) that is used to specify external activities, including incoming messages and events, that an application system must deal with. The second one is the Internal DS (Int-DS) that is used to specify internal activities that an application system performs to get some work done. The third one is the Proactive System (PS) to combine Ext-DS and Int-DS for specifying the reactive and proactive behavior of an application system. 
     External DS (Ext-DS) 
     An Ext-DS defines what incoming external events a PS waits for before performing some internal actions. 
     An Ext-DS is a specialization of DS, and it can be either simple or composite. As a specialization of a simple DS, a simple Ext-DS ( FIG. 9 ) has an Event type as its Behavior, and a Result. The Event type specifies the type of a signal, message or event that may be received by a PS. An Event type may be specified in one of the following: 1) a programming language, such as C and Java, 2) a data specification notation, such as Abstract Syntax Notation One, 3) an XML-based notation, or 4) a graphical notation. 
     The run time activation and deactivation procedure of a simple Ext-DS is as follows:
         When a simple Ext-DS becomes active, its Event type becomes active.   When a message specified by its Event type occurs on a connection subsequently, the event is matched. The message is saved for use later and the simple Ext-DS becomes inactive. Otherwise, the message is dropped and the simple Ext-DS remains active.       

     A composite Ext-DS is the same as a composite-DS ( FIG. 5 ) except that each of sub-DS is replaced by a sub-Ext-DS and any of these sub-Ext-DS&#39;s (sequential or parallel) can be either simple or composite. 
     Since a composite Ext-DS is a specialization of a composite DS, the activation and deactivation procedure of a composite Ext-DS is identical to the activation and deactivation procedure of a composite DS as described previously with each “DS” replaced by an “Ext-DS”. 
     When a simple PS receives an incoming event at run time, it calls an event matching procedure Matching( ) to check if the event matches a valid event type in its Ext-DS or not. The Matching procedure returns one of the following:
         no-match, indicating that there is no match;   partial-match, indicating that there is a match, the event is saved for processing later, but the Ext-DS has not exited, since more events are expected by the Ext-DS; or   full-match, indicating that there is a match, the event is saved for processing later, and the Ext-DS has exited.       

     An exemplary run time Matching procedure of an active Ext-DS is described in the following pseudo code, where “Ext-DS” is the Ext-DS that specifies incoming external events to receive, and “event” is the incoming event to be checked. Note that comments are included in between an opening ‘[’and a closing‘]’. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 Matching (Ext-DS, event) { 
               
            
           
           
               
            
               
                 If the Ext-DS is simple, 
               
            
           
           
               
               
            
               
                   
                 Checks if the event is the same type as specified in Event type or not; 
               
               
                   
                 If no, return “no-match”; 
               
               
                   
                 Else [the event is the right type ], 
               
            
           
           
               
               
            
               
                   
                 Save the event; 
               
               
                   
                 return “full-match”; 
               
            
           
           
               
            
               
                 Else [the Ext-DS is composite], 
               
            
           
           
               
               
            
               
                   
                 [Check all PM&#39;s] 
               
               
                   
                 For each PM whose Current-phase is not null, do the following: 
               
            
           
           
               
               
            
               
                   
                 recursively calls itself for the sequential sub-Ext-DS; 
               
               
                   
                 If it returns “partial-match”, return “partial-match” 
               
               
                   
                 Else, if it returns “full-match”, 
               
            
           
           
               
               
            
               
                   
                 check each Transition one at a time; 
               
            
           
           
               
               
            
               
                   
                 If any Transition-predicate is “true”, 
               
            
           
           
               
               
            
               
                   
                 change the Current-phase to the Target-phase; 
               
            
           
           
               
               
            
               
                   
                 Else [if none of these Transition-predicates is true], 
               
            
           
           
               
               
            
               
                   
                 change the Current-phase to the default 
               
               
                   
                 Null-phase; 
               
            
           
           
               
               
            
               
                   
                 If the Current-phase is not a Null-phase, 
               
            
           
           
               
               
            
               
                   
                 return “partial-match”; 
               
            
           
           
               
               
            
               
                   
                 Else [the Current-phase is a Null-phase], 
               
            
           
           
               
               
            
               
                   
                 check the Exit-condition set; 
               
               
                   
                 If any Exit-condition is met, 
               
            
           
           
               
               
            
               
                   
                 record the Exit-code in Result; 
               
               
                   
                 return “full-match”; 
               
            
           
           
               
               
            
               
                   
                 Else [No Exit-condition is met], 
               
            
           
           
               
               
            
               
                   
                 return “partial-match”; 
               
            
           
           
               
               
            
               
                   
                  Else [returns “no match”], go check the next PM; 
               
               
                   
                 [If it reaches here, all PM is “No match”, go check all 
               
               
                   
                 Parallel-elements] 
               
               
                   
                 For each active Parallel-element, 
               
            
           
           
               
               
            
               
                   
                 recursively call itself for the parallel sub-Ext-DS; 
               
               
                   
                 If it returns “partial-match”, return “partial-match”; 
               
               
                   
                 Else, if it returns “full-match”, 
               
            
           
           
               
               
            
               
                   
                 set Mode as “inactive”; 
               
               
                   
                 check the Exit-condition set; 
               
               
                   
                 If any Exit-condition is met, 
               
            
           
           
               
               
            
               
                   
                 record the Exit-code in Result; 
               
               
                   
                 return “full-match”; 
               
            
           
           
               
               
            
               
                   
                 Else [No Exit-condition is met], return “partial-match”; 
               
            
           
           
               
               
            
               
                   
                  Else [returns “no match”], go check the next parallel-element; 
               
               
                   
                 [If it gets here, there is no match in all sequential and parallel 
               
               
                   
                  sub-Ext-DS&#39;s,] return “no-match”; 
               
            
           
           
               
            
               
                 } 
               
               
                   
               
            
           
         
       
     
     For clarification purpose, the event matching procedure is also shown in  FIG. 12  using the graphical notation described later in this invention. 
     Internal DS (Int-DS) 
     Once triggered by a full match of Ext-DS, the corresponding Int-DS in a simple PS is performed. Hence, an Int-DS is viewed as the active part of the behavior or active behavior of the PS. 
     An Int-DS is a specialization of DS, and it can be either simple or composite. As a specialization of a simple DS, a simple Int-DS ( FIG. 11 ) has an Action as its Behavior, and a Result. The Action is the most basic unit of behavior that is not further broken down to smaller components in the current specification. It can be reading or writing a piece of information, searching or matching, accessing data in events saved by an Ext-DS, building or sending out events, creating or destroying dynamic DS instances, or invoking a complex actions performed by others. An Action can be implemented as a procedure of a functional language, such as C, a method of an object-oriented language, such as Java, or a script of a script language, such as Shell in Linux. An Action may also be implemented as a fragment of code in a script language, a programming language, a byte code, such as Java byte code, or even in an assembly language. The Result may be used by the Action to record the outcome of its execution. 
     The run time activation and deactivation procedure of a simple Int-DS is as follows:
         When a simple Int-DS becomes active, its Action becomes active and is performed.   After the Action is performed, the simple Int-DS subsequently becomes inactive.       

     A composite Int-DS is the same as a composite DS ( FIG. 5 ) except that each sub-DS is replaced by a sub-Int-DS, and any of these sub-Int-DS&#39;s (sequential or parallel) can be either simple or composite. 
     Since a composite Int-DS is a specialization of a composite DS, the activation and deactivation procedure of a composite Int-DS is identical to the activation and deactivation procedure of a composite DS as described previously with each “DS” replaced by an “Int-DS”. 
     When a simple PS receives an incoming event at run time, it calls an event matching procedure to check if the event matches a valid event type in its Ext-DS or not. If there is a full match, the simple PS calls an action performing procedure Act ( ) to perform internal activities as defined in its Int-DS. The Act procedure returns one of the following:
         error, indicating that there is an error, or   OK, indicating that internal activities have been successfully performed.       

     An exemplary run time Act procedure for an active Int-DS is described in the following pseudo code, where “Int-DS” is the Int-DS that defines the internal activities to be performed. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 Act (Int-DS) { 
               
            
           
           
               
            
               
                 If the Int-DS is simple, 
               
            
           
           
               
               
            
               
                   
                 Perform the Action to process saved events; 
               
               
                   
                 If there is error detected, return “error”; 
               
               
                   
                 Else, return “OK”; 
               
            
           
           
               
            
               
                 Else [the Int-DS is composite], 
               
            
           
           
               
               
            
               
                   
                 [Check all PM&#39;s] 
               
               
                   
                 For each PM whose Current-phase is not null, do the following: 
               
            
           
           
               
               
            
               
                   
                 Recursively call itself for the sequential sub-Int-DS; 
               
               
                   
                 If It returns “error”, return “error”; 
               
               
                   
                 Else, check each Transition; 
               
            
           
           
               
               
            
               
                   
                 If any Transition-predicate is “true”, 
               
            
           
           
               
               
            
               
                   
                 Change the Current-phase to the Target-phase; 
               
            
           
           
               
               
            
               
                   
                 Else, change the Current-phase to default Null-phase; 
               
            
           
           
               
               
            
               
                   
                 If Current-phase is not null, repeat this for the (new) 
               
               
                   
                 Current-phase; 
               
               
                   
                 Else, 
               
            
           
           
               
               
            
               
                   
                 Check the Exit-condition set; 
               
               
                   
                 If any Exit-condition is met, 
               
            
           
           
               
               
            
               
                   
                 record the Exit-code in Result; 
               
               
                   
                 return “OK”; 
               
            
           
           
               
               
            
               
                   
                 Else, go check the next PM; 
               
            
           
           
               
               
            
               
                   
                 [Check all Parallel-elements] 
               
               
                   
                 For each active Parallel-element, 
               
            
           
           
               
               
            
               
                   
                 Recursively call itself for the parallel sub-Int-DS ; 
               
               
                   
                 If it returns “error”, return “error”; 
               
               
                   
                 Else, 
               
            
           
           
               
               
            
               
                   
                 set Mode as “inactive”; 
               
               
                   
                 check the Exit-condition set; 
               
               
                   
                 If any Exit-condition is met, 
               
            
           
           
               
               
            
               
                   
                 record the Exit-code in Result; 
               
               
                   
                 return “OK”; 
               
            
           
           
               
               
            
               
                   
                 Else, go check the next Parallel-element; 
               
            
           
           
               
            
               
                 } 
               
               
                   
               
            
           
         
       
     
     For clarification purposes, the action performing procedure is also shown in  FIG. 14  using the graphical notation described later in this invention. 
     PS 
     An application system with a reactive behavior that is triggered by external interactions or events can be defined as a PS. 
     A PS is a specialization of DS, and it can be either simple or composite. As a specialization of a simple DS, a simple PS ( FIG. 10 ) has a Behavior that includes an External DS (Ext-DS) followed by an Internal DS (Int-DS), and a Result The Ext-DS specifies external events to occur and the Int-DS specifies internal actions to perform in response to the occurrence of external events defined in the Ext-DS. Each of Ext-DS and Int-DS can be either simple or composite. The Result may be used by the Int-DS to record the outcome of performance of its actions. 
     The run time activation and deactivation procedure of a simple PS is as follows:
         When a simple PS becomes active, its Ext-DS becomes active.   When its Ext-DS subsequently has a full match (to be described later), its Int-DS becomes active and is performed.   After the Int-DS is performed, the simple PS subsequently becomes inactive.       

     A composite PS is the same as a composite DS ( FIG. 5 ) except that each sub-DS is replaced by a sub-PS and any of these sub-PS&#39;s (sequential or parallel) can be either simple or composite. 
     Since a composite PS is a specialization of a composite DS, the activation and deactivation procedure of a composite PS is identical to the activation and deactivation procedure of a composite DS as described previously with each “DS” replaced by a “PS”. 
     When a PS receives an incoming event at run time, it calls a React procedure to handle the event The React procedure returns one of the following:
         nothing-done, indicating that no internal activity is done;   partial, indicating that part of internal activities are done, but the PS has not exited yet; or   done, indicating that internal activities are done and the PS has exited.       

     An exemplary run time React procedure of an active PS upon receiving an event is described in the following pseudo code, where “PS” is the reacting PS and “event” is the event to process. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 React (PS, event) { 
               
            
           
           
               
            
               
                 If the PS is simple, 
               
            
           
           
               
               
            
               
                   
                 Call the Matching procedure for its Ext-DS with the event; 
               
               
                   
                 If the result is “no-match”, return “nothing-done”; 
               
               
                   
                 Else if the result is “partial-match”, return “partial”; 
               
               
                   
                 Else [the result is “full-match”], 
               
            
           
           
               
               
            
               
                   
                 call Act procedure to perform the Int-DS; 
               
               
                   
                 return “done”; 
               
            
           
           
               
            
               
                 Else [PS is composite], 
               
            
           
           
               
               
            
               
                   
                 [Check all PM&#39;s] 
               
               
                   
                 For each PM whose Current-phase is not null, do the following: 
               
            
           
           
               
               
            
               
                   
                 recursively call itself for the sequential sub-PS; 
               
               
                   
                 If it returns “partial”, return “partial”; 
               
               
                   
                 Else if it returns “done”, check each Transition; 
               
            
           
           
               
               
            
               
                   
                 If any Transition-predicate is “true”, 
               
            
           
           
               
               
            
               
                   
                 change the Current-phase to the Target-phase; 
               
            
           
           
               
               
            
               
                   
                 Else [no Transition-predicate is true], 
               
            
           
           
               
               
            
               
                   
                 change the Current-phase to default Null-phase; 
               
            
           
           
               
               
            
               
                   
                 If the Current-phase is not null, return “partial”; 
               
               
                   
                 Else [the Current-phase is null], 
               
            
           
           
               
               
            
               
                   
                 check the Exit-condition set; 
               
               
                   
                 If any Exit-condition is met, 
               
            
           
           
               
               
            
               
                   
                 record the Exit-code in Result; 
               
               
                   
                 return “done”; 
               
            
           
           
               
               
            
               
                   
                 Else [No Exit-condition is met], 
               
            
           
           
               
               
            
               
                   
                 return “partial”; 
               
            
           
           
               
               
            
               
                   
                 Else [returns “nothing-done”], go check the next PM; 
               
            
           
           
               
               
            
               
                   
                 [If it reaches here, all PM is “nothing-done”, go check all 
               
               
                   
                 Parallel-elements] 
               
               
                   
                 For each active Parallel-element, 
               
            
           
           
               
               
            
               
                   
                 Recursively call itself for the parallel sub-PS ; 
               
               
                   
                 If it returns “partial”, return “partial”; 
               
               
                   
                 Else If it returns “done”, 
               
            
           
           
               
               
            
               
                   
                 set Mode as “inactive”; 
               
               
                   
                 check the Exit-condition set; 
               
               
                   
                 If any Exit-condition is met, 
               
            
           
           
               
               
            
               
                   
                 record the Exit-code in Result; 
               
               
                   
                 return “done”; 
               
            
           
           
               
               
            
               
                   
                 Else [No Exit-condition is met], return “partial”; 
               
            
           
           
               
               
            
               
                   
                 Else [returns “nothing-done”], go check the next 
               
               
                   
                 parallel-element; 
               
            
           
           
               
               
            
               
                   
                 [If it reaches here, nothing is done] return “nothing-done”; 
               
            
           
           
               
            
               
                 } 
               
               
                   
               
            
           
         
       
     
     For clarification purpose, the reactive procedure is also shown in  FIG. 13  using the graphical notation described later in this invention. 
     Using Ext-DS, PS and Int-DS, which are specializations of DS, in various steps instead of using the more general DS has many additional benefits. They are:
         Ext-DS, PS and Int-DS provide layers of abstraction to facilitate defining complex system behavior in a distributed environment, since each one is specialized in a way to help the designer to focus on a particular aspect of the system behavior.   PS is a useful extension and improvement over the conventional state machine based techniques, such as Statechart, whereas Int-DS is a useful extension and improvement over conventional flow chart based techniques, such as BPMN and UML 2.0 Activity diagram.   Since each of them is a specialization of the same DS, there is strong consistency in each layer of design to make the present invention easy to learn and to understand.   Because of this consistency, as shown later in this invention, reactive behavior defined in a PS can be systematically and mechanically derived from a protocol defined as a DS. Hence, the present invention provides a solution to the difficult problem of keeping the protocol and communicating parties consistent with each other.
 
Simplified Model of DS, Ext-DS, PS, and Int-DS
       

     So far the basic model of DS and its specializations, such as Ext-DS, PS, and Int-DS, have been described. Together, they are referred to as the DS model in the present invention. This basic DS model (referred to as “model  0 ” hereafter) may be simplified by emulating each Parallel-element by a Parallel PM. The simplified model is referred to as “model  1 ” hereafter. 
     A Parallel-element in a composite DS of model  0  can be emulated by a PM with only one Phase with a dummy Transition. The PM that emulates a Parallel-element is called a “Parallel PM” in the present invention. The Phase in a Parallel PM has only one sub-DS. Its dummy Transition may be implemented as one of the following:
         no Transition is defined as shown in  FIG. 15A ;   there is only one Transition, which is marked as null;   there is only one Transition with its Transition-predicate set to be true  1501  and its Target-phase pointing to a Null-phase  1502  as shown in  FIG. 15B .       

     A new optional component Static-count  1604  is added to the PM. Like the Static-count in a Parallel-element, the Static-count in a PM indicates how many static instances of the PM type should be created when its containing DS is created. If no Static-count is specified, the default value of Static-count is 1 and one instance of the PM type is always created when its containing DS is created. 
     The sub-DS of such a Parallel PM would have the same behavior as the parallel sub-DS of the Parallel-element that the PM is emulating. 
     In the present invention, the term “Sequential PM” is used when referring to a full-fledged PM without the above-mentioned limitations of a Parallel PM. A Sequential PM&#39;s Static-count may be set as 1 so that one static instance of the Sequential PM is created when its containing composite DS is created. 
     Using a Parallel PM to emulate each Parallel-element in a composite DS, a model  1  composite DS has a number of PM&#39;s  1601 , an Exit-condition set  1602  and a Result  1603 . Some of these PM&#39;s are Sequential PM&#39;s and others are Parallel PM&#39;s ( FIG. 16 ). 
     Since each Parallel-element is emulated by a PM, the procedure for activation and deactivation of a composite DS of model  1  is the same as model  0  except that the part of code that deals with a Parallel-element is not executed, since there is no Parallel-element defined in a composite DS. 
     Similarly, a composite Ext-DS, PS, or Int-DS can be a specialization of model  1  composite DS&#39;s. Since each Parallel-elements are now replaced by a parallel PM, the procedure for activation and deactivation of each of these model  1  DS components is the same as model  0  except that the part of code that deals with a Parallel-element is not executed. Similarly, the event matching procedure for an active Ext-DS of model  1 , the action performing procedure for an active Int-DS of model  1 , and the reactive procedure for an active PS of model  1  as described earlier are all still applicable. 
     Graphical Notation 
     One exemplary embodiment of the present invention is to represent PS, Ext-DS, Int-DS or any other DS derived components (all of these are referred to as “DS components” hereafter) in a human readable graphical notation. 
     As an example for this graphical notation, a DS or a sub-DS can be shown as either a containment box or a containment box with a label attached to it. The containment box can be in many shapes, such as a polygon, a circle, or an oval. A super-DS containing a number of sub-DS&#39;s (either Sequential or Parallel) can be shown as a large containment box (the super-DS) containing a number of sub-containment boxes (both sequential and parallel sub-DS&#39;s) within its boundary. If the DS can have multiple instances, it is shown with a shade. An Initial-phase or a Null-phase can be shown as a small box or a symbol at the boarder of the composite DS box. 
       FIG. 17  depicts an exemplary graphical notation of an example composite DS “DS  0 ”  1700  with three sequential sub-DS&#39;s (“sub-DS s 0 ”  1701 , “sub-DS s 1 ”  1702 , and “sub-DS s 2 ”  1703 ), three parallel simple sub-DS&#39;s (“sub-DS p 0 ”  1706 , “sub-DS p 3 ”  1709  and “sub-DS p 5 ”  1704 ), and two parallel composite sub-DS&#39;s (“sub-DS p 1 ”  1705  and “sub-DS p 2 ”  1708 ). Note that each of “sub-DS p 2 ”  1708  and “sub-DS p 3 ”  1709  is shown with a shade indicating that it may have more than one instance at run time. 
     In this example, a simple DS is shown as a rectangle box with the name or a short description of its Behavior inside of the box. “sub-DS p 0 ”  1706  and “sub-DS p 5 ”  1704  in  FIG. 17  are two simple DS examples. 
     A Transition can be shown as a link or arrow (called Transition arrow) with its Transition-predicate (TransPred) close to it as its label, and the arrow points to its Target-phase. For example, in  FIG. 17 , there is a Transition arrow from “sub-DS s 2 ”  1703  to “sub-DS s 0 ”  1701  (the Target-phase) with “TransPred  5 ” as the label for the Transition. Any sub-DS with at least one Transition arrow (incoming or outgoing) is a sequential sub-DS, whereas a sub-DS without any Transition arrow is a parallel sub-DS. 
     A Creation arrow can be used to point to a dynamic component that is created dynamically. Although a Creation arrow is shown as a thick dashed line arrow  1707  in  FIG. 17  as an exemplary graphical notation, it can be represented by another kind of link as long as it is visually distinctive from a Transition arrow. As shown in  FIG. 17 , “sub-DS p 0 ”  1706  can create multiple instances of “sub-DS p 2 ”  1708  dynamically, and “sub-DS p 2 ”  1708  can create multiple instances of “sub-DS p 3 ”  1709  dynamically. A parallel sub-DS, such as “sub-DS p 2 ”  1708  and “sub-DS p 3 ”  1709  in  FIG. 17 , with an incoming creation arrow is a dynamic parallel sub-DS whose corresponding Static-count in Parallel-element is set to 0, whereas a parallel sub-DS, such as “sub-DS p 0 ”  1706  and “sub-DS p 1 ”  1705  in  FIG. 17 , without an incoming creation arrow is a static one with its Static-count typically set to 1 indicating that one instance should be created when “DS  0 ”  1700  is created. 
     Note that “DS  0 ”  1700  in  FIG. 17  does not explicitly specify any Exit-condition. As described earlier, the default Exit-condition is that “DS  0 ”  1700  exits when all its sub-DS&#39;s have exited. 
       FIG. 18  shows how Initial-phases, Null-phases, Exit-predicates and Exit-points can be explicitly represented visually. In  FIG. 18 , the Initial-phase  1801  is shown as a small box at the left boarder. It has one Transition to the Phase containing “sub-DS s 0 ”  1802  and another Transition to the Phase containing “sub-DS s 1 ”  1803 . “sub-DS s 0 ”  1802  has a Transition to “sub-DS s 2 ”  1804  and its Transition-predicate is always true. “sub-DS s 2 ”  1804  has one Transition (“TransPred 2 ” in  FIG. 18 ) leading to a Null-phase  1806 , a Transition “TransPred  3 ” leading to itself, and another “TransPred  4 ” leading back to the Phase containing “sub-DS s 0 ”  1802 . “DS  0 ” also contains a parallel “sub-DS p 1 ”  1805  and two Exit-points. 
     Each exit-point represents an Exit-condition that indicates the condition under which a composite DS exits. An Exit-condition has a pair of Exit-predicate and Exit-code. An Exit-point can be shown as a symbol or a small box inside of or at the boundary of the containing composite DS box. As an example, each of these exit-points is shown in  FIG. 18  as a small dark box  1807  at the boundary and labeled with its associated Exit-predicate. 
     An Exit-predicate can be shown as a text, a logical expression, or a mathematical formula describing a condition under which a composite DS exits. Exit-predicate “Sub-DS P 1  has exited” is a text example indicating that when “sub-DS P 1 ” exits, the composite DS “DS  0 ”  1800  exits. Exit-predicate “®” is an exemplary logical expression indicates that when all components exit, “DS  0 ”  1800  exits. Exit-predicate “Age &lt;10” is an exemplary mathematical formula indicating that when a datum “Age” is smaller than 10, “DS  0 ”  1800  exits. 
     In order to simplify the behavior models and their graphical representations, following exemplary default cases are defined:
         A Transition-predicate that is always true can be omitted.   If a Phase has only one incoming Transition that is connected from the Initial-phase and its Transition-predicate is always true, that Transition may be omitted completely.   If a Phase has only one outgoing Transition that is connected to a Null-phase and its Transition-predicate is always true, that Transition may be omitted completely.       

       FIG. 19  depicts an exemplary graphical representations of a composite PS example. In this exemplary diagram, “Composite PS 0 ”  1902  contains two sequential sub-PS&#39;s, namely “sub-PS s 0 ”  1903  and “sub-PS s 1 ”  1904 , three parallel sub-PS&#39;s, namely “sub-PS p 0 ”  1905 , “sub-PS p 1 ”  1906 , and “sub-PS p 2 ”  1911 , and two Exit-points  1913 ,  1915  with “ExitPred 0 ” and “ExitPred 1 ” as their respective Exit-Predicates. 
     A simple PS  1906  is shown as a box with its Ext-DS  1908  and Int-DS  1910  components inside. To differentiate an Ext-DS from an Int-DS in a simple PS, a divider (a vertical  1909  or a horizontal line  1907 ) is drawn in between the two components. “sub-PS p 0 ”  1905  and “sub-PS p 1 ”  1906  are two examples. 
     Interactions in between two PS&#39;s are bi-directional lines (called Interaction-links) connecting two participating PS&#39;s.  FIG. 19  shows that the “composite PS  0 ”  1902  interacts with “PS 1 ”  1900 , “sub-PS s 1 ”  1904  interacts with “sub-PS p 2 ”  1911  and “sub-PS p 0 ”  1905  interacts with “sub-PS p 2 ”  1911 . In this particular example, an Interaction-link is shown as a dashed line (“protocol 0 ” in  FIG. 19  is such an example). However, it can be represented by another kind of link as long as it is visually distinctive from a Transition arrow and a Creation arrow. Optionally, one or two arrow heads can be used to indicate the direction of an interaction flow. A simple interaction with only one event sent is shown by a dashed line with only one arrow head (“protocol 2 ” in  FIG. 19  is such an example). An Interaction-link with arrow heads on both sides indicate a set of interactions that flow in both directions (“protocol 1 ” in  FIG. 19  is such an example). An Interaction-link can optionally have an associated label or identifier describing the protocol specification with which the interactions must comply. “protocol 0 ”, “protocol 1 ” and “procotol 2 ” in  FIG. 19  are such examples. 
     In the present invention, any sub-DS in a composite DS can be either simple or composite. Even the Ext-DS or Int-DS in a simple sub-PS can be either simple or composite. Therefore, a containment box may have a plurality of sub-containment boxes, wherein any of these sub-containment boxes may comprise a plurality of sub-sub-containment boxes. Some of these sub-sub-containment boxes are sequential, hence, are connected by Transition arrows. Some of these sub-sub-containment boxes are parallel, hence, are not connected to any other sub-sub-containment box.  FIG. 20  shows an example composite PS “PS  0 ”  2000  containing a sub-PS “sub-PS s 0 ”  2001  with a composite Ext-DS  2002  and a composite Int-DS  2006 . The composite Ext-DS  2002  contains two sequential Ext-DS&#39;s, namely “ext-DS s 0 ”  2003  and “ext-DS s 1 ”  2004 , and a parallel Ext-DS “ext-DS p 0 ”  2005 . The composite Int-OS  2006  contains two sequential Int-DS&#39;s  2007  and  2008 , and a parallel Int-DS  2009 . 
     Benefits of the graphical notation of a DS, Ext-DS, PS and Int-DS (for brevity, when referring to either DS, Ext-DS, PS or Int-DS, the term “system” is used here) are as follows:
         A composite system is dearly shown with all its sequential and parallel components at the same time.   The containment box clearly shows that when a super-system becomes inactive or is destroyed, all its components become inactive or be destroyed.   Exit-points can dearly show how internal operations of a composite sub-system can affect how its super-system changes its current Phase.   Only essential elements of a composite system are shown. For example, PM&#39;s, Phases, and Parallel-elements are not shown in the diagram, since they are not critical in a diagram to understand the behavior. This greatly simplifies the graphical notation of a system specification.   The consistency among Ext-DS, PS and Int-DS diagrams makes it easier to learn and understand a specification of a complex behavior.       

     Note that the above descriptions use one particular way to represent DS, Ext-DS, PS, Int-DS and their components. However, based on the disclosure and teachings provided herein, it should be apparent to a person of ordinary skill in the art that various diagramming presentations may be used to represent the same mechanisms in accordance with the present invention as long as the following essences are preserved:
         a composite DS is shown as a containment box containing its components, such as sequential sub-DS, parallel sub-DS, Initial-phase, Null-phase, exit-points, transition arrows, creation arrows and Interaction-links;   Each of these components inside of the composite DS box must be visually differentiated from each other,   A simple PS box contains an Ext-DS component and an Int-DS component and that they are visually differentiated from each other.
 
Predefined Event Types
       

     Some systems may need to perform a certain Int-DS as soon as a PS becomes active. The present invention supports a predefined event “Entry” that is always delivered to a newly active PS. The exemplary composite PS  2100  in  FIG. 21  has a simple sub-PS  2101  with the “Entry” specified as its Ext-DS  2102 . When the containing composite PS  2100  becomes active, all parallel sub-PS&#39;s become active. Hence, the Int-DS  2103  associated with “Entry” is performed immediately after the composite PS  2100  becomes active. 
     Some systems may need to perform a certain Int-DS immediately before a PS becomes inactive. The present invention supports a predefined event “Exit” that is always delivered to a PS that is becoming inactive. The exemplary composite PS  2100  ( FIG. 21 ) has a simple sub-PS  2104  with the “Exit” specified as its Ext-DS  2105 . When the composite PS  2100  becomes inactive, all parallel sub-PS&#39;s become inactive. Hence, the Int-DS  2106  associated with “Exit” is performed immediately before the composite PS becomes inactive. 
     The benefits of predefined event “Entry” and “Exit” are:
         UML Statechart needs additional special mechanisms for an entry action and an exit action in a state. With “Entry” and “Exit” event types, the same simple PS mechanism can be used to achieve the same function. Therefore, users need to learn less specialized mechanisms in the present invention.   Sometimes it is desirable to keep a particular Int-DS separate from an Ext-DS. For example, when deriving a Participant-PS from a Protocol as described later in this invention, it is desirable for the derived Participant-PS to keep the same composition structure as the Protocol. For example, the X-server Participant-PS in  FIG. 39  should have the same composition structure as the Protocol “protocol 0 ” in  FIG. 38 . However, if there is no additional incoming event needed for the unspecified Ext-DS “??”  3905 , the Int-DS “Reply 0 ”  3906  would have to be combined with Ext-DS “Request 0 ”  3902 , hence, destroy the same composition structure as shown in  FIG. 22 . Using a “Entry” for the unspecified Ext-DS, the same composition structure would be maintained as shown in  FIG. 23 .
 
Implementation Issues
       

     While some run time properties of a DS, Ext-DS, PS and Int-DS are frequently changed at run time, some static design time properties remain unchanged in its entire life time. In addition, there can be multiple instances of the same type at run time. Therefore, it makes sense to separate these design time properties in a class or type structure from run time properties in an instance structure. 
     In one exemplary embodiment, the instance structure of a simple DS  2402  has a pointer or reference  2403  to its type structure  2400  and a Result component  2404  ( FIG. 24 ). The type structure  2400  of a simple DS has one Behavior type component  2401 . As shown in  FIG. 24 , there can be more than one simple DS instance sharing the same simple DS type.  FIG. 25  shows the same simple DS type and instance structures in a UML class diagram. 
     In one exemplary embodiment, the instance structure of a simple Ext-DS has a pointer or reference to its type structure and a Result component ( FIG. 26 ). The type structure of a simple Ext-DS has one Event type component. As shown in  FIG. 26 , there can be more than one simple Ext-DS instance sharing the same simple Ext-DS type.  FIG. 27  shows the same simple Ext-DS type and instance structures in a UML class diagram. 
     In one exemplary embodiment, the instance structure of a simple PS has a pointer or reference to its type structure and a Result component ( FIG. 28 ). The type structure of a simple PS has one Ext-DS type (simple or composite) component and an Int-DS type (simple or composite) component. As shown in  FIG. 28 , there can be more than one simple PS instance sharing the same simple PS type.  FIG. 29  shows the same simple PS type and instance structures in a UML class diagram. 
     In one exemplary embodiment, the instance structure of a simple Int-DS has a pointer or reference to its type structure and a Result component ( FIG. 30 ). The type structure of a simple Int-DS has one Action type component, which can be a code fragment, a procedure of a functional language, such as C, a method of an object-oriented language, such as Java, or a script of a script language, such as Shell in Linux. As shown in  FIG. 30 , there can be more than one simple Int-DS instance sharing the same simple Int-DS type.  FIG. 31  shows the same simple Int-DS type and instance structures in a UML class diagram. 
     Composite DS Type and Instance 
     As shown in  FIG. 32A , the composite DS type  3200  of model  1  has a number of Phased Machine (PM) types  3201 , and either an Exit-condition set  3202  as in  FIG. 32A  or an exit function  3218  as shown in  FIG. 32B . If an exit condition set is specified, it includes at least one exit condition, each exit condition including a pair of an exit predicate that specifies a condition under which an instance of the composite DS type exits and an exit code that identifies the associated exit condition. If an exit function is specified, the exit function returns an exit code that identifies a condition under which an instance of the composite DS type exits. Each PM type includes an optional Static-count  3203  and one or more Phase types  3204 . Each Phase type has a sub-DS type  3205 , and zero or more Transitions  3206 . Each Transition includes a Transition-predicate  3207  and a Target-phase  3208 . Each sub-DS type can be either a simple DS type or a composite DS type. 
     If a Static-count is specified in a PM type, it specifies the number of static instances of the PM type. If it is not specified, the default is that the PM type has one static instance. 
     Note that each PM type can be either a sequential PM or a parallel PM. As described earlier, a parallel PM type has only one phase type as shown in  FIG. 15A  and  FIG. 15B . 
     The instance structure  3209  of a model  1  composite DS has a type reference  3210  to its DS type structure, a number of PM&#39;s  3211 , and a Result  3212 . Each PM has a type reference  3213  to its PM type structure, a number of Phases  3214 , and a Current-phase  3215 . Each Phase has a type reference  3216  to its Phase type structure, and a sub-DS instance structure  3217 . The sub-DS instance can be either simple or composite. If it is simple  2402  as shown in  FIG. 24 , it includes a type reference  2403  to its associated simple DS type  2400  and a Result  2404  that records the outcome of performing the behavior  2401  of its associated simple DS type. If the sub-DS instance is composite, it has the same structure as  3209 . 
     Note that the shade of the instance structure in  FIGS. 32A , B and C indicates that there can be more than one composite DS instance sharing the same composite DS type. 
       FIG. 35  shows the same composite-DS type and instance structures in a UML class diagram. 
     As a specialization of a composite DS of model  1 , a composite Ext-DS of model  1  can be similarly separated into a type structure and an instance structure. The type structure of a composite Ext-DS of model  1  is identical to a composite DS type structure in  FIG. 32A  or  32 B after replacing each “DS” with an “Ext-DS”. The instance structure of a composite Ext-DS of model  1  is identical to a composite DS instance structure in  FIG. 32A  or  32 B after replacing each “DS” with an “Ext-DS”. 
     As a specialization of a composite DS of model  1 , a composite PS of model  1  can be similarly separated into a type structure and an instance structure. The type structure of a composite PS of model  1  is identical to a composite DS type structure in  FIG. 32A  or  32 B after replacing each “DS” with a “PS”. Note that the sub-PS type in a Phase type can be either simple or composite.  FIG. 32C  shows a composite PS type  3219  with a simple PS type  3220 . The simple PS type includes an Ext-DS type that specifies external events to occur and an Int-DS type that specifies internal actions to perform in response to the occurrence of said external events. 
     The instance structure of a composite PS of model  1  is identical to a composite DS instance structure in  FIG. 32A  or  32 B after replacing each “DS” with a “PS”. Note that the sub-PS in a Phase can be either simple or composite.  FIG. 32C  shows a composite PS instance  3221  with a simple PS instance  3222 . The simple PS includes an Ext-DS instance and an Int-DS instance. 
       FIG. 36  shows how “X-server” Participant-PS type of  FIG. 23  is specified as a composite PS type structure  3600  containing a default Exit-condition set and a PM type “ 0 ”  3601 . PM type “ 0 ” has a Static-count and three Phase types. They are “init”  3615 , “ 0 ”  3602  and “ 1 ”  3605 . Its Static-count with a value of 1 indicates that one instance of this PM type is created when the composite PS is created. Phase type “init”  3615  is an Initial phase with a Transition  3616 , whose Transition-predicate  3617  is always true and Target-phase  3618  is phase type “ 0 ”. Note that the dummy null sequential sub-DS is not shown in  FIG. 36 . Phase type “ 0 ”  3602  has one Transition  3603  and a sub-PS type  3604  with an Ext-DS type of “Request 0 ” and an Int-DS type of “??”. Phase type “ 1 ”  3605  has a Null-phase as its Target-phase  3606  and a predefined “Entry” event type specified as its sub-Ext-DS type  3607 . 
       FIG. 36  also shows an instance  3608  of “X-server” Participant-PS type. The instance has a Result, a type reference  3609  pointing to its type  3600 , and a PM “ 0 ”  3610 , which has a type reference pointing to its PM type “ 0 ”. PM “ 0 ”  3610  has a type reference pointing to its PM type “ 0 ”  3601 , a Current-phase, and two Phases, namely Phase “ 0 ”  3611  and Phase “ 1 ”  3613 . Phase “ 0 ” has a type reference pointing to its Phase type “ 0 ”  3602  and a sub-PS  3612  containing a type reference pointing to its PS type  3604  and a Result. 
     As a specialization of a composite DS of model  1 , a composite Int-DS of model  1  can be similarly separated into a type structure and an instance structure. The type structure of a composite Int-DS of model  1  is identical to a composite DS type structure in  FIG. 32A  or  32 B after replacing each “DS” with an “Int-DS”. The instance structure of a composite Int-DS of model  1  is identical to a composite DS instance structure in  FIG. 32A  or  32 B after replacing each “DS” with an “Int-DS”. 
     Although type information is abstracted out of the instance information, as long as both type and instance information are accessible at run time, the run time procedures, such as the event matching procedure for an active Ext-DS, the reactive procedure for an active PS, and the action performing procedure for an active Int-DS, described previously in the present invention are still applicable. 
     Although there are some advantages to have type structure cleanly separated from the instance structure, an embodiment may choose to combine type and instance attributes in a single structure or mix them in certain ways. This is an implementation decision, which is not restricted by this invention. 
     Those run time procedures described in this invention earlier may need to store some transient data during their executions. In one exemplary embodiment of the present invention, the instance structure of a DS component may contain a local data areas in addition to these defined in an instance structure. 
     The present invention includes methods and components that can be used to benefit the entire life cycle of developing an application software. One exemplary embodiment of the present invention is to design an application software based on DS components using a design tool, then use a code generator to generate machine readable binary code to be run on a run time platform. As shown in  FIG. 33 , the output of the design tool is the DS type specification, which can be transmitted to a code generator or stored on a storage device for later retrieval by a code generator. The output of the code generator is a set of DS types in binary format that can be loaded by a run time platform into memory to be executed. The run time platform may also input some supporting binary code that implements basic Actions or some existing Int-DS&#39;s. 
     The design tool may support a graphical user interface (GUI) to allow a designer to define DS components based on the graphical notation described earlier. After the design process is done, the design tool generates the DS type specification, which is a set of user defined DS types or classes, such as PS, Ext-DS and Int-DS types. At design time, the design tool only needs to deal with the type information. Therefore, there is no need to deal with instance structures. 
     A code generator reads the DS type specification stored on a storage device and then generate these DS types in binary code. The output of the code generator can be stored on a storage device to be retrieved later by a run time platform or be transmitted to the run time platform directly for execution. 
     During the execution, the run time platform can load the DS types in binary code into memory and create instance structures with references to their type structures as described by this invention. These DS component instances are created and initialized using information available in the DS type specification. These DS components can also be activated and deactivated dynamically following procedures described in this invention to perform their assigned functions. 
     In one embodiment, a run time platform may implement the action performing procedure to process each composite Int-DS defined in Int-DS types, whereas in another embodiment of this invention may have each composite Int-DS type specification complied into a lower layer code that can be executed more efficiently by the run time platform. A lower layer code may be in the form of a byte code, such as Java byte code, which can be executed directly by a virtual machine, such as Java Virtual Machine. Another lower layer code may be a binary code of a programming language, such as C or Java. In this case, source code in a programming language for each specific composite Int-DS type can be generated and then compiled into binary code. 
     The type and instance structures described in this invention are abstract, namely they are implementation independent. These abstract structures need to be mapped to various concrete structures implemented by each tool. For example, these DS components may be stored in one external concrete forms on permanent storage devices and loaded into memory for processing in another internal concrete form. The external concrete form can be any of the following: 1) a programming language, such as C or Java, 2) a data specification notation, such as Abstract Syntax Notation One, 3) an XML based notation, or 4) any proprietary representation that a visual design tool may support. The internal concrete form can be in the form of a data element in a data specification notation, an XML based notation, a script language, a programming language, such as C or Java, or a machine readable binary code of any programming language. 
     The concrete format that implements the abstract structures described in this invention does not have to follow the abstract structure in verbatim. For example, the Static-count in the PM type or Parallel-element type can be in the form of a flag that indicates whether any static instance of a PM should be created statically when its containing composite DS is created. The flag information may also be implemented as a specifically designated bit of another variable. For another example, the Result in a DS instance structure can be implemented as an integer or a complex data structure to contain various result information. In short, the concrete format of an embodiment of this invention does not need to follow the abstract structures described in this invention closely. 
     Although the present invention uses PS, Ext-DS and Int-DS to model the behavior of a system interacting with others, each of these can be replaced by components of an existing or a future behavior specification technique, script language, or programming language. There is no requirement that all Ext-DS, PS and Int-DS have to be used together. 
     Another embodiment of this invention is to use DS components only in the design and code generation phases. As shown in  FIG. 34 , an application can be designed based on DS components. However, its output DS type specification can be read by a code generator that generates code for a different platform, which does not support DS components, to run. This code generator would only need to use the DS type structures described in this invention along with a proprietary way to map DS components into another set of mechanisms supported by its run time platform. 
     Design Methods 
     To design application systems that need to interact with each other in a distributed environment is a challenging task. If two interacting systems are designed separately, it would be difficult to ensure that their behaviors are fully compatible with each other. A better approach is to first define the communication protocol in between two interacting parties and then convert the protocol specification into the behavior specification for each party in a systematic and mechanical way, hence, removing the possibility of inconsistency from the design process. 
     An embodiment application system of this invention may play multiple roles, and each role may need to participate in interactions with multiple parties simultaneously. For clarity purposes, this invention uses the term “Role-PS” to refer to the behavior of a role played by the application system. With regard to each Protocol, there are two interacting participating parties. The term “Participant-PS” refers to the part of the behavior of a particular participant. Therefore, a system typically has multiple Role-PS&#39;s and each Role-PS may have multiple Participant-PS&#39;s, one for each Protocol that the role supports.  FIG. 8  depicts an example “System 0 ”  800  interacting with “System 1 ”  801 , “System 2 ”  802 , and “System 3 ”  803 . “System 0 ” plays 2 roles. They are “Role-PS  0 ”  804  and “Role-PS 1 ”  805 , where “Role-PS  0 ” interacts with both “System 1 ” and “System 2 ” and “Role-PS 1 ” interacts with “System 3 ”. 
     To illustrate the desirable design procedure, an example application system “X” is used.  FIG. 37  depicts the system with one Role-PS interacting with a client and a server simultaneously. Internally, “X” has an “X-server” Participant-PS that interacts with the client through protocol “protocol 0 ”, and another “X-client” Participant-PS that interacts with the server through protocol “protocol 1 ”. Following the design procedure, we first define protocol “Protocol  0 ” and protocol “Protocol  1 ”. We then convert “Protocol  0 ” to “X-server” Participant-PS and “Protocol  1 ” to “X-client” Participant-PS. Finally, we merge “X-server” and “X-client” into an “X” Role-PS. 
     The most preferred design procedure of this invention is described as follows:
         The first step is to define a protocol for each peer system that a Role may interact with. A protocol is defined as a DS type including all possible external events that may flow in both directions on a connection or session between the Role being defined and another peer system.   The second step is to follow a conversion method to convert each protocol defined in the previous step into a Participant-PS of the Role;   The third step is to follow a merging method to merge all Participant-PS&#39;s of the same role derived from the previous step into a single Role-PS.   The final step is to complete the behavior specification for the Role by adding internal interactions and internal active behavior. Each of these internal interactions is defined as a DS type, whereas the internal active behavior is defined as an Int-DS type.   When changes are required, these steps can be iterated as needed.       

     In this invention, a protocol is typically specified as a DS type describing only incoming events to receive and outgoing events to send for a participant, while other internal activities not related to sending and receiving events are ignored. This protocol DS type can also be viewed as if it is defined for the behavior of an entity that sits in between the two communicating participants and receives events flowing in both directions. 
       FIG. 38  depicts the example Protocol “protocol 0 ” and “protocol 1 ” specified as DS types. The “protocol 0 ” Protocol specifies that the client first sends a “Request 0 ” event to “X-server” and then “X-server” sends back a “Reply 0 ” event. The “protocol 1 ” Protocol specifies that “X-client” first sends a “Request 1 ” event to the server and then the server sends back a “Reply 1 ” event. Note that “→” and “←” are used to make the direction of the event flow easier to see in the diagram. 
     The conversion method to convert a DS type specifying a protocol to a PS type that specifies the reactive behavior of a participant is described as follows:
         for each incoming simple sub-DS type that describes an event for the participant to receive in the protocol DS type, replace the incoming simple sub-DS type by a simple sub-PS type with the simple sub-DS type as its Ext-DS type and an unspecified Int-DS type;   for each outgoing simple sub-DS type that specifies an event for the participant to send in the protocol DS type, replace the outgoing simple sub-DS type by a simple sub-PS type with an unspecified Ext-DS type and the outgoing simple sub-DS type as its Int-DS type.       

     Based on the conversion method described above, the Participant-PS  3900  for “X-server” ( FIG. 39 ) can be derived as follows:
         Since “Request 0 ” is an incoming simple sub-DS type for “X-server”, it is replaced by a simple sub-PS type  3901  with “Request 0 ” as its Ext-DS type  3902  and an unspecified Int-DS type (shown as “??” in  FIG. 39 )  3903 .   Since “Reply 0 ” is an outgoing simple sub-DS type for “X-server”, it is replaced by a simple sub-PS type  3904  with an unspecified Ext-DS type (shown as “??” in  FIG. 39 )  3905  and the outgoing simple sub-DS type “Reply 0 ” as its Int-DS type  3906 .       

     Based on the conversion method described above, the Participant-PS  4000  for “X-client” ( FIG. 40 ) can be derived as follows:
         Since “Request 1 ” is an outgoing simple sub-DS type for “X-client”, it is replaced by a simple sub-PS type  4001  with an unspecified Ext-DS type  4002  and the outgoing simple sub-DS type “ReRequest 1 ” as its Int-DS type  4003 .   Since “Reply 1 ” is an incoming simple sub-DS type for “X-client”, it is replaced by a simple sub-PS type  4004  with “Reply 1 ” as its Ext-DS type  4005  and an unspecified Int-DS type  4006 .       

     In one embodiment, the conversion method can also be implemented directly over the data structures of DS types without using the graphical notations of DS types as in  FIGS. 38 ,  39  and  40 . 
     The merging method to combine all derived Participant-PS&#39;s of the same Role into a single Role-PS is to add a super-PS to contain all these derived Participant-PS&#39;s as parallel sub-PS&#39;s.  FIG. 42  depicts how the Role-PS “X” is derived from Participant-PS&#39;s for “X-server” and “X-client”. 
     In one embodiment, the merging method can also be implemented directly over the data structures of Participant-PS types without using the graphical notations of PS types as in  FIG. 42 . 
     The derived Role-PS is typically incomplete, since there may be some unspecified Ext-DS&#39;s and Int-DS&#39;s. The next step is to replace these unknown Ext-DS&#39;s and Int-DS&#39;s with internal interactions and behavior. 
     Let&#39;s assume the behavior of “X” is that after receiving “Request 0 ”, “X-server” does part of the work and then ask the server to do the rest by sending “Request 1 ” to the server. Lets also assume that after receiving a response “Reply 1 ” from the server, “X-client” informs “X-server” about the result of work done by the server, and then “X-server” sends “Reply 0 ” back to the client. 
     To accomplish these internal interactions, a event “aa” is defined for “X-server” to send to “X-client” to ask the server to do the rest of work. A event “bb” is defined for “X-client” to sent to “X-server” to inform about the result of work done by the server. After replacing those unspecified Ext-DS&#39;s and Int-DS&#39;s, the new Role-PS is shown as in  FIG. 43 . 
     This example uses two very simple internal protocols (each protocol has only one event), i.e. “aa” and “bb”, to accomplish the job. The present invention supports complex protocols defined in composite DS types in between any two internal sub-PS&#39;s. In fact, the same example can be used to illustrate this feature.  FIG. 44  depicts the same example except that the internal protocol is defined in a composite DS type “protocol 2 ” as shown in  FIG. 41 . 
     Benefits of using various design methods described in the present invention are:
         By mechanically deriving the reactive behavior specification from an external behavior, the present invention ensures that the protocol and communicating parties are consistent with each other.   Since Ext-DS, Int-DS and PS are specializations of DS and share the same composition structure, it is easy to identify internal behavior that are added to the mechanically derived reactive behavior specification.   By mechanically deriving the reactive behavior specification from an external behavior, the effort and time for specifying complex behavior is greatly reduced.       

     It is possible that these design methods described above can be generalized when applied to another modeling notation based on nodes and links, such as UML Activity Diagram, BPMN, XPDL, WS-CDL and BPEL, or a combination of these modeling notations. An equivalent of the composite-DS in the present invention is called an Activity in UML Activity diagram, a process in BPMN, XPDL, and BPEL, or a choreography in WS-CDL. To simplify the description, an equivalent of composite-DS in another modeling notation is referred to as a composite-activity hereafter. An equivalent of the simple DS in the present invention is called an action in UML Activity Diagram, a task in BPMN and XPDL, and an activity in BPEL and WS-CDL. They are referred to as a simple-activity hereafter. In addition, the term activity is used to refer to either a simple-activity or a composite-activity. 
     A simple-PS can be mapped to a reactive composite-activity in one of these modeling notations comprising an external activity describing external events to receive, and an internal activity describing internal actions to perform in response to the occurrence of the associated external activity. Since a composite-PS has the same structure as a composite-DS, it can be mapped to a composite-activity. 
     Some other components used in these design methods are also generalized so that they can also be used in other behavior modeling notations. The unspecified Ext-DS is generalized into an unspecified external activity representing an activity to receive some unspecified external events. The unspecified Int-DS is generalized into an unspecified internal activity representing an activity to perform some unspecified internal actions. 
     Using these generalized components, these design methods described above can be generalized when applied to other behavior notations. The procedure for using those generalized design methods is as follows:
         The first step is to specify each of those protocols supported by a role as composite-activities in UML Activity Diagram, BPMN, XPDL, WS-CDL or BPEL   The second step is to apply a generalized conversion method to derive a participant composite-activities from each of these protocol composite-activities,   The third step is to merge those participant composite-activities of the same role to form a role composite-activity in UML Activity Diagram, BPMN, XPDL, WS-CDL or BPEL.   The forth step is to complete the role specification by replacing unspecified external activities and unspecified internal activities in the resulting role composite-activity from last step with internal interactions and behavior.       

     A protocol can be specified in UML Activity Diagram, BPMN, XPDL, WS-CDL or BPEL as a composite-activity containing a series of simple-activities describing only external events flowing in both directions in between two interacting parties, while other activities not related to sending and receiving events are ignored. Since each of these modeling notations has a simple-activity to receive an external event, a protocol can be specified using event receiving simple-activities. In other words, this protocol composite-activity can be specified as if it is defined for the behavior of an entity that sits in between the two communicating participants receiving external events flowing in both directions. Following this approach, a protocol can be defined as composite-activities in UML Activity Diagram using “AcceptEventAction” to receive external events coming from both directions. As an example, the same protocols “Protocol  0 ” and “Protocol  1 ” defined as DS types as shown in  FIG. 38  can be defined in UML Activity Diagram as shown in  FIG. 45 . 
     Converting to a Participant Composite Activity 
     The generalized conversion method is used for converting a composite-activity from a protocol specification to a behavior specification of a participant. The method comprises:
         For each incoming simple-activity in the composite-activity that describes an event for the participant to receive, replace the incoming simple-activity by a reactive composite-activity including the incoming simple-activity as its external activity followed by an unspecified internal activity that describes activities to perform in response to the occurrence of the incoming simple-activity.   For each outgoing simple-activity in the composite-activity that specifies an event for the participant to send, replace the outgoing simple-activity by a reactive composite-activity including an unspecified external activity that describes events to receive followed by the outgoing simple activity as its internal activity to perform in response to the occurrence of the unspecified external activity.       

       FIG. 46  shows the resulting Participant composite-activity  4600  of “X-server” in UML Activity Diagram, which is converted from “Protocol  0 ”  4500  in  FIG. 45 . The simple-activity “Request 0 ”  4501  is an incoming event to receive, hence, is replaced by a reactive composite-activity  4601  containing an external activity to receive the incoming event “Request 0 ”  4602 , followed by an unspecified internal activity  4603 , which is to be performed in response to its associated incoming event “Request 0 ”. This internal activity may be defined as either an action or an activity in UML Activity Diagram. The simple-activity “Reply 0 ”  4502  in “Protocol  0 ”  4500  is an outgoing event to send, hence, is replaced by a reactive composite-activity  4604  containing an unspecified external activity  4605  to receive unspecified incoming events followed by an internal activity to send out the outgoing event “Reply 0 ”  4606 . Each of these external activity and internal activity may be defined as either an action or an activity in UML Activity Diagram. 
       FIG. 47  shows the resulting Participant composite-activity of “X-client”  4700  in UML Activity Diagram, which is converted from “Protocol  1 ”  4503  in  FIG. 45 . The simple-activity “Request 1 ”  4504  is an outgoing event to send, hence, is replaced by a reactive composite-activity  4701  containing an unspecified external activity to receive unspecified incoming events  4702 , followed by an internal activity to send out the outgoing event “Request 1 ”  4703 , which is to be performed in response to its associated unspecified incoming event “??”. Each of these external activity and internal activity may be defined as either an action or an activity In UML Activity Diagram. The simple-activity “Reply 1 ”  4505  in “Protocol  1 ”  4503  is an incoming event to receive, hence, is replaced by a reactive composite-activity  4704  containing an external activity  4705  to receive the incoming event “Reply 1 ”, followed by an unspecified internal activity  4706 . This external activity may be defined as either an action or an activity In UML Activity Diagram. 
     A generalized merging method to combine all resulting participant composite-activities of the same role into a composite-activity specifying the behavior of a single role when using a nodes and links based modeling notation is as follows:
         Add a super composite-activity to contain all these derived participant composite-activities as its parallel sub-activities. This is achieved by adding a fork node with a link leading to each of these participant composite-activities followed by a join node as the target of each of these participant composite-activities.       

       FIG. 48  shows how derived participant composite-activity “X-server” and “X-client” are merged into the “X role composite-activity” in UML Activity Diagram. Note that the fork node  4800  and join node  4801  are shown as vertical lines in a UML Activity Diagram. 
     When applying the general design methods to BPMN, the specific procedure is described as the following:
         Specify protocol composite-activities in BPMN ( FIG. 49 ) with only event receiving tasks to receive external events flowing in both directions.   modify the following to convert it into a participant composite-activity ( FIG. 50  and  FIG. 51 ):
           For each “receive” task  4901  receiving an incoming event as viewed by the participant, replace the “receive” task by a reactive process  5001  including the “receive” task  5003  as its external activity followed by an unspecified internal activity  5004  (a sub-process or task in BPMN) as its internal activity to perform in response to the occurrence of the incoming event.   For each “receive” task  4902  in the composite-activity that specifies an event for the peer to receive, hence, for the participant to send, replace the task by a reactive process  5002  including an unspecified external activity  5005  (a task or sub-process in BPMN) as its external activity that describes unspecified external events to receive followed by a task to send the event as its internal activity  5006  to perform in response to the occurrence of the unspecified external activity.   
           to combine all these participant composite-activities into a single role composite-activity, add a super process to use either a pair of AND-Split  5200  and AND-join  5201  parallel gateways ( FIG. 52 ) or a parallel box  5300  ( FIG. 53 ) to combine all these derived participant composite-activities as its parallel sub-processes. Similar to parallel sub-PS&#39;s in a composite PS, these sub-processes start to run in parallel with each other when the super process starts to run.       

     The resulting process can subsequently be completed by replacing unspecified external activities and unspecified internal activities with internal interactions and behavior. 
     When applying the general design methods to BPEL, the specific procedure is described as the following:
         Specify a protocol composite-activity in BPEL with only event receiving tasks to receive external events flowing in both directions using either “receive” or “pick” activity of BPEL.   If “pick” is used to specify a protocol, its &lt;on Message&gt; structure should have the event name specified as its “operation” and “empty” specified as its activity. For example, the pseudo code of BPEL of “protocol 0 ” may look like this:       

     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;sequence ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;pick ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;onMessage ... operation=“Request0” ...&gt; 
               
               
                   
                 ... 
               
               
                   
                 empty 
               
               
                   
                 &lt;/onMessage&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/pick&gt; 
               
               
                   
                 &lt;pick ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;onMessage ... operation=“Reply0” ...&gt; 
               
               
                   
                 ... 
               
               
                   
                 empty 
               
               
                   
                 &lt;/onMessage&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/pick&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/sequence&gt; 
               
               
                   
                   
               
            
           
         
       
         
         
           
             If “receive” is used to specify a protocol, the event name should be specified as its “operation”. For example, the pseudo code of BPEL of “protocol 1 ” may look like this: 
           
         
       
    
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;sequence ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;receive ... operation=“Request1” ...&gt; 
               
               
                   
                 ... 
               
               
                   
                 &lt;/receive&gt; 
               
               
                   
                 &lt;receive ... operation=“Reply1” ...&gt; 
               
               
                   
                 ... 
               
               
                   
                 &lt;/receive&gt; 
               
            
           
           
               
               
            
               
                   
                  &lt;/sequence&gt; 
               
               
                   
                   
               
            
           
         
       
         
         
           
             Note that although “sequence” is used in this example to define sequential activities, a “flow” with “links” can also be used to define sequential activities in BPEL. 
             modify the following to convert it into a participant composite-activity: for each “receive” or “pick” activity in the protocol composite-activity,
           If the activity describes an incoming event for the participant to receive, replace it by a reactive composite-activity including the incoming activity as its external activity followed by an unspecified internal activity (a sub-activity in BPEL) as its internal activity to perform in response to the occurrence of the incoming activity:
               For “pick”, the activity in the &lt;on Message&gt; structure should be changed from “empty” to an unspecified internal activity “InternalActivity??”, and   For “receive”, it should be followed by an unspecified internal activity “InternalActivity??” in a “sequence”.   
               If the activity specifies an event for the participant to send, replace the activity by a reactive composite-activity including an unspecified external activity that describes events to receive followed by an activity to send the event as its internal activity to perform in response to the occurrence of the unspecified external activity.
               If “pick” is used, the &lt;on Message&gt; structure of an unspecified external activity should be waiting for an unspecified incoming event “??”, and its internal activity should contain the outgoing event.   If “receive” is used, the unspecified external activity should wait for an unspecified event, and followed by an internal activity of sending the outgoing event in a “sequence”.   
               For example, “X-server” participant composite-activity in the BPEL pseudo code using “pick” may look like this:   
         
           
         
       
    
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;sequence ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;pick ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;onMessage ... operation=“Request0” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
               
                   
                 InternalActivity?? 
               
            
           
           
               
               
            
               
                   
                 &lt;/onMessage&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/pick&gt; 
               
               
                   
                 &lt;pick ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;onMessage ... operation=“??” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
               
                   
                 &lt;invoke ... operation=“Reply0” ... 
               
               
                   
                 &lt;/invoke&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/onMessage&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/pick&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/sequence&gt; 
               
               
                   
                   
               
            
           
         
       
         
         
           
             
               
                 For example, “X-client” participant composite-activity in the BPEL pseudo code using “receive” may look like this: 
               
             
           
         
       
    
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;sequence ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;receive ... operation=“??” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
            
           
           
               
               
            
               
                   
                 &lt;/receive&gt; 
               
               
                   
                 &lt;invoke ... operation=“Request1” ... 
               
               
                   
                 &lt;/invoke&gt; 
               
               
                   
                 &lt;receive ... operation=“Reply1” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
            
           
           
               
               
            
               
                   
                 &lt;/receive&gt; 
               
               
                   
                 InternalActivity?? 
               
            
           
           
               
               
            
               
                   
                 &lt;/sequence&gt; 
               
               
                   
                   
               
            
           
         
       
         
         
           
             to define a single role composite-activity, add a super process by using a “flow” structure to combine all these derived participant composite-activities as its parallel sub-processes.
           For example, the combined role composite-activity in the BPEL pseudo code may look like this:   
         
           
         
       
    
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;flow&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;sequence ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;pick ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;onMessage ... operation=“Request0” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
               
                   
                 InternalActivity?? 
               
            
           
           
               
               
            
               
                   
                 &lt;/onMessage&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/pick&gt; 
               
               
                   
                 &lt;pick ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;onMessage ... operation=“??” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
               
                   
                 &lt;invoke ... operation=“Reply0” ... 
               
               
                   
                 &lt;/invoke&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/onMessage&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/pick&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/sequence&gt; 
               
               
                   
                 &lt;sequence ...&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;receive ... operation“??” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
            
           
           
               
               
            
               
                   
                 &lt;/receive&gt; 
               
               
                   
                 &lt;invoke ... operation=“Request1” ... 
               
               
                   
                 &lt;/invoke&gt; 
               
               
                   
                 &lt;receive ... operation=“Reply1” ...&gt; 
               
            
           
           
               
               
            
               
                   
                 ... 
               
            
           
           
               
               
            
               
                   
                 &lt;/receive&gt; 
               
               
                   
                 InternalActivity?? 
               
            
           
           
               
               
            
               
                   
                  &lt;/sequence&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;/flow&gt; 
               
               
                   
                   
               
            
           
         
       
     
     The resulting process can subsequently be completed by replacing unspecified external activities and unspecified internal activities with internal interactions and behavior. 
     Note that the above exemplary embodiment uses “operation=“??” “to represent an unspecified external activity and “InternalActivity??” to represent an unspecified internal activity, each of unspecified external activity and unspecified internal activity can be represented by other ways in another embodiment as long as they can be differentiated from other normal activities. 
     Although the above exemplary embodiment of general design methods is based on specifying a protocol composite activity and a participant composite activity in BPEL, a similar approach can be applied to any XML based behavior notation that support a “sequence” activity, such as XPDL and WS-CDL, by persons skilled in the art. In general, a reactive composite-activity described above can be defined as a sequence activity containing an external activity to wait for an incoming event and an internal activity to perform some actions in response to the occurrence of the incoming event. The XML below shows a reactive composite-activity defined in a sequence activity: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;sequence&gt; 
               
            
           
           
               
               
            
               
                   
                 ExternalActivity 
               
               
                   
                 InternalActivity 
               
            
           
           
               
               
            
               
                   
                 &lt;/sequence&gt; 
               
               
                   
                   
               
            
           
         
       
     
     For a reactive composite-activity defined in WS-CDL, its external activity can be a WS-CDL Interaction activity specifying an incoming event to wait for, and its internal activity can be an activity specifying some actions to perform. Although WS-CDL currently does not support internal activities, it is conceivable that WS-CDL can be extended to allow for internal activities. These general design methods described in the present invention can then be applied to such an extended behavior notation. 
     Generating a Participant State Machine 
     The procedure to apply these generalized design methods to a state machine modeling notation, such as Statechart, is described as the following:
         Specify each protocol as a state machine (“protocol 0 ”  5400  and “protocol 1 ”  5403  in  FIG. 54 ) with only incoming events and outgoing events (“Request 0 ”  5401  and “Reply 0 ”  5402  in “protocol 0 ”, and “Request 1 ”  5404  and “Reply 1 ”  5405  in “protocol 1 ”) specified as events or triggers in its transitions without any action or effect specified. A protocol state machine can be viewed as if it is defined for the behavior of an entity that sits in between the two communicating participants and receives events flowing in both directions. Each of these events is defined as a trigger in its corresponding transition.   modify the following for each protocol state machine to convert it into a Participant state machine ( FIG. 55  and  FIG. 56 ):
           for each transition in the Protocol state machine that has an incoming event, as viewed by the participant, in its trigger, add an unspecified effect (shown as “??”  5501  in  FIGS. 55 and 5603   FIG. 56 ) to the transition.   for each transition having said outgoing event, as viewed by the participant, in its trigger, add an effect to send the outgoing event, and change the trigger to wait for an unspecified incoming event (shown as “??” in  FIG. 56 ).   
               

     To generate a Role state machine, a super state is added to merge all these Participant state machines into a single Role state machine. The super state contains all these derived Participant state machines as its orthogonal regions. As shown in  FIG. 57 , the derived participant state machine “X-server”  5701  and participant state machine “X-client”  5702  are combined as orthogonal regions in a super state “X”  5700 . Note that orthogonal regions in state machine are similar to parallel sub-PS&#39;s in a composite PS. 
     The resulting Role state machine can subsequently be completed by replacing those unspecified triggers and effects with internal interactions and behavior. 
     Although  FIGS. 54 ,  55 ,  56  and  57  are shown as Statechart diagrams, they can be substituted by other state machine diagrams without any loss of the essence of this invention. 
     Sometimes a designer needs to specify the behavior of a new application that needs to interact with an existing application. Since it is not possible to change the existing application, it is desirable to derive the protocol supported by the existing application from the behavior specification of the existing application, and then apply the conversion method to generate the participant composite-activity for the new application. The resulting participant composite-activity would be able to interact with the existing application correctly. 
     Generating a Protocol Composite-Activity 
     The method for generating a protocol composite-activity for specifying the protocol between two participants from a participant composite-activity specifying the behavior of one of these said two participants is described as follows:
         copy the participant composite-activity to the protocol composite-activity;   change each simple-activity in the copied composite-activity that does not receive an incoming event nor send an outgoing event to a null-activity while keeping the same outgoing links.       

     An example showing how this method can be applied is now described using UML Activity Diagram as the behavior modeling notation.  FIG. 46  shows the “X-server” participant composite-activity defined in a UML Activity Diagram. By following the protocol generating method described above, a protocol composite-activity can be derived:
         copy “X-server” participant composite-activity  4600  in  FIG. 46  to the protocol composite-activity  5800  in  FIG. 58 ;   Since simple-activity “??”  4603  does not receive an incoming event nor send an outgoing event, change it to a null-activity  5803 ;   Since simple-activity “??”  4605  does not receive an incoming event nor send an outgoing event, change it to a null-activity  5805 .       

     Note that the null-activity is like an ordinary node except that it does not include any real action to perform. If a composite-activity is specified in BPEL, an “empty” activity can be used as a null-activity. If a composite-activity is specified in WS-CDL, a “noAction” activity can be used as a null-activity. If a composite-activity is specified in a behavior modeling notation that does not support an empty activity, such as BRIAN, XPDL and UML Activity Diagram, a special null-activity can be added. 
     The generated protocol composite-activity may contain many null-activities. These null-activities can be cleaned up using following rules:
         Each of these null-activities can be deleted by linking all targets of its outgoing links directly to each source activity of the deleted null-activity.   If a pair of fork and join nodes is left with either no link or only one link in between the fork and join nodes, this fork and join pair can be deleted.   If a composite activity has only one sub-activity left, the composite activity can be replaced by the sub-activity.       

     After cleaning up null-activities, the protocol in  FIG. 58  is changed into “Protocol 0 ”  4500  as defined in  FIG. 45 . 
     A design tool or a runtime system that implements these generalized design methods above needs to represent these generalized components, such as unspecified external activities and unspecified internal activities, the protocol composite-activity and the participant composite-activity in a particular concrete form. A concrete form can be in any of the following: 1) a programming language, such as C and Java, 2) a data specification notation, such as Abstract Syntax Notation One, 3) an XML based notation, such as XPDL, BPEL and WS-CDL, or 4) a graphical notation, such as BPMN, UML Activity Diagram, or any proprietary representation that a visual design tool may support 
     In one embodiment of these design methods may represent both protocol and participant composite-activities in the same concrete form. In another embodiment, the protocol composite-activity may be represented in one concrete form, while the participant composite-activity may be represented in another concrete form. 
     CONCLUSIONS 
     The present invention includes methods and components that can be used to benefit the entire life cycle of developing an application software. 
     In one embodiment, DS components and methods described in this invention can be used in design, code generation, and execution phases. In another embodiment, DS components and methods are used in design and code generation phases. In yet another embodiment, DS components and methods are used only by a design tool. 
     Another embodiment may use generalized methods and graphical notations described in this invention in the design phase along with another behavior modeling notation, such as UML Statechart, UML Activity Diagram, BPMN, XPDL, and BPEL. As shown in  FIG. 59 , a design tool may support an application design process using those generalized methods and guidelines to specify external behavior and internal behavior of an application system. All or part of the graphical notation described in this invention can be adopted by a design tool to facilitate the design process. However, the resulting behavior may be specified in another behavior modeling notation, such as UML Statechart, UML Activity Diagram, BPMN, XPDL, and BPEL. The resulting behavior can be subsequently used by a code generator to generate binary code to be loaded by a run time platform for execution. 
     The graphical notation described in this invention is versatile and modular in that not all components need to be supported by a design tool. Hence, a design tool may choose to use only some of those components described in this invention for various purposes. In the next three diagrams, some of these embodiment examples are presented. 
       FIG. 60  shows a containment box  6000  representing an application system whose dynamic behavior is specified as a composite-activity including three sub-containment boxes  6001 ,  6002  and  6003 , where two sub-containment boxes  6001  and  6002  represent sequential sub-activities and one sub-containment box  6003  represents a parallel sub-activity. There is one Transition arrow connecting sub-containment box  6001  to sub-containment box  6002 , whereas the parallel sub-activity  6003  does not have any Transition arrow. One of those two sequential sub-activities is a reactive composite-activity  6001  containing an event sub-sub-containment box  6004  representing an external activity that specifies external events to occur and an action sub-sub-containment box  6005  representing an internal activity that specifies internal activities to perform in response to the occurrence of these external events. A bi-directional Interaction-link  6006  represents a set of interactions in between a sequential sub-activity  6001  and the parallel sub-activity  6003 . The protocol is specified by an identifier as “protocol  0 ”, which is a DS not explicitly specified in this diagram. 
       FIG. 61  shows a containment box  6100  representing an application system whose dynamic behavior is specified as a composite-activity including three sub-containment boxes  6101 ,  6102  and  6105 , each representing a sub-activity. A bi-directional Interaction-link  6106  represents a set of interactions in between two sub-containment boxes  6101  and  6105 . The Interaction-link has an identifier “Protocol 0 ” indicating the protocol specification for the set of interactions. The composite-activity  6100  has two Exit-points. One Exit-point  6103  has a default Exit-predicate, which is not explicitly shown. The other Exit-point  6104  has an Exit-predicate “TransPred 1 ”. 
       FIG. 62  shows a containment box  6200  representing an application system whose dynamic behavior is specified as a composite-activity  6200  with two sequential sub-activities  6201  and  6202  and one parallel sub-activity  6205 , and an Interaction-link  6206  in between one sequential sub-activity  6201  and the parallel sub-activity  6205 . There is one Transition arrow  6208  for pointing from a source sub-containment box  6201  to a target sub-containment box  6202 . There is one creation arrow  6207  for pointing to a dynamic component  6205  that may be created by one sequential sub-activity  6202  at run time. One sub-containment box  6201  represents a reactive composite-activity that includes an event sub-sub-containment box  6209  that specifies external events to occur and an action sub-sub-containment box  6210  that specifies internal activities to perform in response to the occurrence of said external events. 
     In another embodiment, instead of using a divider to separate the external activity from the internal activity inside of a reactive composite-activity as shown in  FIG. 60 , a directional link can be used.  FIG. 63  shows the same exemplary composite-activity as in  FIG. 60  with an additional directional link  6303  connecting the external activity  6301  to the internal activity  6302  inside of the reactive composite-activity  6300 . 
     In addition to a visual design tool, other tools can be used to generate user defined DS type specifications based on the present invention. For example, a Computer-Aided Software Engineering (CASE) tool may be used. A CASE tool may support creating and editing user defined DS components as part of an overall development methodology incorporating features of this invention. 
     One CASE tool may provide support for performing analysis and verification of user defined DS type specifications, while another may support reuse of user defined DS type specifications by providing catalogs and directories of existing DS type specifications, and searching/matching capabilities. 
     Other CASE tools may support simulation of DS component based applications, or even provide automatic testing by generating test cases from these specifications. 
     In another embodiment, an Integrated Development Environment (IDE) may support the development of software based on the present invention, including design, build and execution time support. In particular, the execution time support may be provided by a run time platform with software libraries to support DS components. 
     Similar to a run time platform, another embodiment is to support DS components and its run time procedures in a software implemented virtual machine or a computing device that is built entirely in hardware and firmware. 
     On the other hand, not all DS components need to be automated or executed by software. An alternative embodiment is that a designer may use a design tool to define human activities, business process, or action plans in terms of DS components or composite-activities. Some of these DS components or composite-activities may be jobs for human to perform. 
     Although the description above contains many specificities, these should not be construed as limiting the scope of the present invention but as merely providing illustrations of some of the presently described embodiments of the present invention. Based on the disclosure and teachings provided herein, it will be appreciated by a person of ordinary skill in the art that various other embodiments and ramifications are possible within the scope of the present invention. 
     The application of the present invention is very extensive, since most systems solving real world problems can be modeled as reactive systems. For example, in a 3-tier architecture, the database management system can be viewed as a reactive system reacting to input from its upper tier servers. Servers can be viewed as systems reacting to input from its upper tier, namely the presentation tier. The presentation tier can also be viewed as systems reacting to input from human beings. In other words, nearly all computing systems can be modeled by DS, PS, Ext-DS and Int-DS described in the present invention and benefit from the extended, advanced features as described above. 
     The present invention can also be used to model highly complex communication protocols. In particular, using a composite DS specification, a protocol not only supports one single session, but also supports multiple concurrent nested sessions. 
     The present invention can also be used to model man-machine interfaces. A human user can deal with multiple things at the same lime. To match such a multi-processing capability of a human user, a graphical user interface based application may use a composite DS to define its interface with human users, while using a composite PS to define its reactive behavior. 
     With its highly sophisticated modeling capabilities, it is even possible to model human behavior or an organization behavior with the present invention. For example, the entire business process of an organization can be modeled by a composite PS with various levels of sub-PS&#39;s that implement behavior of departments, teams and employees. The process of planning, decision making and problem solving can also be modeled using DS, PS, Ext-DS and Int-DS. 
     A general business operation environment, such as a business process management platform, a work flow engine or a general business operational framework, can be implemented by supporting DS, PS, Ext-DS and Int-DS specifications for carrying out various business processes and activities. 
     Some real world objects, which can have multiple states, such as machinery, customer records, and order entries, can also be modeled with DS&#39;s or their extensions. 
     Using the method of the present invention for modeling and designing various application systems, such as the ones described above, DS, PS, Ext-DS and Int-DS specifications can be defined. Some of these specifications can also be generated or derived using other approaches. Disregarding which approach to use, the resulting user DS, PS, Ext-DS and Int-DS specifications of these applications can be performed by a device or machine, such as a computer, that practicing the present invention to carry out these specifications. 
     In general, the present invention can be embodied in the form of methods and apparatuses for practicing those methods and operations. The present invention can also be embodied in the form of program code embodied in tangible media, such as floppy diskettes, CD-ROMs, disk drives, or any other machine-readable storage medium. When the program code is loaded into and executed by a device or machine, such as a computer, the machine becomes an apparatus for practicing the invention. The present invention can also be embodied in the form of program code, which can be transmitted over some transmission medium, such as electrical wiring or cabling, through fiber optics, or via electromagnetic radiation. When the program code is loaded into and executed by a device or machine, such as a computer, the machine becomes an apparatus for practicing the invention. 
     Accordingly, it can be seen that DS components and their related methods and procedures described in accordance with the present invention is a very powerful method and technique to define behavior and protocols of systems. In particular, the present invention extends and improves the prior art, BPMN, XPDL, BPEL, WS-CDL or UML, in several major areas. 
     One is that the DS model, which reflects both time and space dimensions in the universe we live in, adds significant meaning and structure to a bunch of nodes and links specified with a prior art technique. The second is that using a containment box to contain both sequential and parallel components in a diagram, various forking and joining nodes and links can be eliminated. The third is that the combination of Result and Exit-conditions provides a very powerful and flexible mechanism to control when a composite DS should end. The forth is the use of specializations of DS, such as Ext-DS, PS, and Int-DS, to specify external behavior, reactive behavior and internal behavior of a system in a consistent way. The fifth is to specify the behavior of multiple systems that may have complex interactions with each other. The sixth is that systematic design methods are provided to derive a Role-PS from Protocol&#39;s and to ensure consistency among related specifications. 
     It is understood that the examples and embodiments described herein are for illustrative purposes only and that various modifications or changes in light thereof will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application and scope of the appended claims. It is further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of this invention may be made by those skilled in the art without departing from the principle and scope of the invention as expressed in the claims. All publications, patents, and patent applications cited herein are hereby incorporated by reference for all purposes in their entirety.