s in the collaboration uses to the composite roles, PatientT, ReceptionistT, DoctorT, and TeleSvcDsk has been explained above in Section 5.4. Step 2: Specify the behavior of each elementary collaboration For each of the elementary collaborations used in the UML 2.x service specification in Step 1, if collaboration is not already specified and stored in the repository of reusable service specifications, specify the visible interface behavior as a UML 2.x sequence diagram. For ensuring that the behavior associated with the elementary collaborations can execute correctly during dynamic service execution in the run- time system, the visible interface behavior between the two elementary roles should be validated with respect to safety and liveness properties. This may be done using static analysis, for example, by checking the type compatibility of signals exchanged, or using dynamic analysis, that is, taking into consideration the order of events occurring during dynamic execution [2,11,12]. Consultation Consult administrator Administrator Consulter dap : Administrate, Callee dcp : call AdminUser Caller Consultant Figure 5.17 The consultation collaboration. How to Model Dynamic Service Composition Using UML 2.x Step 2 applied to the tele-consultation service: We illustrate this step by specifying the UML 2.x sequence diagram for the call collaboration from Step 1. This sequence diagram is shown in Figure 5.18. Here, we use the STAIRS [15,16] opera- tor xalt to express that each of the alternatives are mandatory in the final imple- mentation. We also use UML state invariants declared on the lifelines to express rolegoal assertions for each of the roles, forexample, Caller.TalkedT (Callee) and Callee. Ta alkedTo (Caller), and UML continuation labels, for example, Connected, to express collaboration goal assertions as in [2]. For examples demonstrating validation of the visible interface behavior between the two elementary roles in the call collaboration with respect to safety and liveness properties, we refer to [2] wh