#menu(Menu)
RIGHT:[[Japanese>Synthesis(Jpn)]]
** Synthesis State-machines from a communication diagram [#u9bcfbdd]
Its procedure is as follows:
+ [[draw class diagram>#qf791560]]
+ [[draw communication diagram>#wfffa6c5]]
+ [[synthesis state-machine>#r183bb5d]]
*** Example [#zd95a812]
#ref(Synthesis(Jpn)/purchaseordercol.png,right,around)
The example choreography is shown right.
The figure is a collaboration diagram of UML1.x.
((Collaboration diagrams are called communication diagrams in UML2.x. In collaboration diagrams, we can define partial order on messages using the predecessor of each message. For example, 1/ in front of A1 &color(blue){shipReq}; is the predecessor. The predecessor indicates that message 1 must precede message A1. Therefore, ''Vendor'' must send &color(blue){shipReq}; after it receives &color(blue){order};.))
The example is a modified version of a collaboration by [[T. Bultan and X. Fu>http://dx.doi.org/10.1007/s11761-008-0022-7]], which is taken from [[BPEL-WS 2.0>http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.html]] specification.
This example is composed of five services: ''Customer'', ''Vendor'', ''Shipping'', ''Invoicing'', and ''Scheduling''.
When ''Vendor'' receives an &color(blue){order}; from ''Customer'', it sends requests to ''Shipping'', ''Invoicing'' and ''Scheduling''. Finally, ''Vendor'' returns &color(blue){orderReply}; to ''Customer''.
The request to ''Shipping'' is &color(blue){shipReq};, and the reply from ''Shipping'' is &color(blue){shipInfo};.
The requests to ''Invoicing'' are &color(blue){productInfo}; and &color(blue){shipType};; the reply from ''Invoicing'' is &color(blue){invoice};.
''Vendor'' sends &color(blue){productInfo}; after receiving &color(blue){order};; it sends &color(blue){shipType}; after receiving &color(blue){shipInfo};.
''Invoicing'' does internal process to make an &color(blue){invoice}; after receiving &color(blue){productInfo}; and &color(blue){shipType};; then it sends &color(blue){invoice}; as a reply.
The request to ''Scheduling'' are &color(blue){productSchedule}; and &color(blue){shipSchedule};.
''Vendor'' sends &color(blue){productSchedule}; after receiving &color(blue){order};; it sends &color(blue){shipSchedule}; after receiving &color(blue){shipInfo};.
''Vendor'' sends &color(blue){orderReply}; to ''Customer'' after receiving &color(blue){shipInfo}; and &color(blue){invoice}; and sending &color(blue){shipSchedule};.
*** Draw Class Diagram [#qf791560]
Create an UML project in RSA.
Add new class diagram; create classes for the services: ''Customer'', ''Vendor'', ''Shipping'', ''Invoicing'', and ''Scheduling''.
#ref(Synthesis(Jpn)/classDiagram.png,center)
*** Draw Communication Diagram [#wfffa6c5]
Add new communication diagram; place all classes as lifelines.
Draw message pathways between lifelines that communicates.
#ref(Synthesis(Jpn)/communicationDiagram1.png,center)
Add messages.
RSA has three message types:
- Asynchronous Call
- Asynchronous Signal
- Synchronous Call
CSCB Tools supports two of them: Asynchronous and Synchronous Calls.
In this example, we assume that all messages are asynchronous calls.
The communication diagram added messages is shown below.
#ref(Synthesis(Jpn)/communicationDiagram2.png,center)
Define ordering relation among messages.
- Communication diagrams does not have predecessors, which collaboration diagrams have.
- The ordering relation of the example cannot be represented by the sequence number.
In CSCB Tools, we specify the preceding messages in the "Documentation".
For example, because &color(blue){shipInfo};, &color(blue){invoice};, and &color(blue){shipSchedule}; precede &color(blue){orderReply};, we add them in the Documentation of &color(blue){orderReply}; as below.
#ref(Synthesis(Jpn)/communicationDiagram3.png,center)
Now, it is ready to synthesize state machines.
*** synthesis state-machine [#r183bb5d]
Right click the package in Project Explorer and select "Create StateMachine" -> "create State Machine all by CSCB" from the menu; then a state machine for each service is synthesized.
By the way, if "create State Machine by CSCB" is selected, one can select a service to be synthesized.
If "... by projection" is selected, state machines are synthesized by the projection method.
#ref(Synthesis(Jpn)/stateMachine1.png,center)
When there is no problem, state machines are synthesized and added to the model.
The Blank Package of PurchaseOrder; project in the above diagram has only Class Diagrams and Communication Diagrams; now it has State Machine Diagrams as shown below.
#ref(Synthesis(Jpn)/stateMachine2.png,center)
*** Results [#c7d90e10]
- Customer state machine
''Customer'' executes the effect "send order to ''vendor''", i.e. sends message &color(blue){order}; to ''vendor'', at the transition from initial pseudo state to V1; it transitions to final state by the occurrence of the event orderReply_receive, i.e. receives message &color(blue){orderReply};.
''Customer'' executes the effect "send order to vendor", i.e. sends message &color(blue){order}; to ''vendor'', at the transition from initial pseudo state to V1; it transitions to final state by the occurrence of the event orderReply_receive, i.e. receives message &color(blue){orderReply};.
#ref(Synthesis(Jpn)/stateMachine_customer.png,center)
- Vendor state machine
When ''vendor'' receives &color(blue){order};, three processes run concurrently; these processes are represented the state machines in the three regions of the composite state V2.
In the first region, ''vendor'' sends &color(blue){shipReq}; to ''shipping'', and receives &color(blue){shipInfo};.
Then, the process forks into two processes.
In the first process, ''vendor'' sends &color(blue){shipSchedule}; to ''scheduling''; in the another process, it sends &color(blue){shipType}; to ''invoicing'' and receives &color(blue){invoice};.
''Vendor'' sends &color(blue){orderReply} to ''customer'' when two processes terminate.
In the second region, ''vendor'' sends &color(blue){productSchedule}; to ''scheduling''.
In the third region, ''vendor'' sends &color(blue){productInfo}; to ''invoicing''.
When all processes in the three regions terminate, ''vendor'' transitions to the final state.
#ref(Synthesis(Jpn)/stateMachine_vendor.png,center)
- Shipping state machine
''Shipping'' received &color(blue){shipReq};, and then sends &color(blue){shipInfo}; to ''vendor''.
#ref(Synthesis(Jpn)/stateMachine_shipping.png,center)
- Invoicing state machine
''Invoicing'' receives &color(blue){shipType}; and &color(blue){productInfo}; concurrently; then it sends &color(blue){invoice}; to ''vendor'' after receiving &color(blue){shipType};.
((In this example, because &color(blue){invoice}; does not precedes &color(blue){productInfo};, ''invoicing'' may issue &color(blue){invoice}; before receiving &color(blue){productInfo};. This problem is solved by adding preceding relation among &color(blue){invoice}; and &color(blue){productInfo}; in the choreography.))
#ref(Synthesis(Jpn)/stateMachine_invoicing.png,center)
- Scheduling state machine
''Scheduling'' receives &color(blue){shipSchedule}; and &color(blue){productSchedule};.
#ref(Synthesis(Jpn)/stateMachine_scheduling.png,center)
- Class diagram
The class diagram is updated as below, where references to communicating partners and called methods are added.
#ref(Synthesis(Jpn)/classDiagram2.png,center)
RIGHT:[[CSCB Home>CSCB(Eng)]]
