Daniel Amyot, PhD student, University of Ottawa Scenarios As First-Class Entities Functional Entities Mapping Scenarios on Functional Entities Network Entities Mapping Functional Entities to Network Entities Resulting Mapping: Scenarios to Network Entities Deriving Message Sequence Charts Towards Validation Towards Testing

Scenarios paths can be used as first-class entities. In this way, we can focus on causality relationships between responsibilities, without any reference or commitment to architectural components and messages. These scenarios are useful as thinking tools in the early steps of feature definitions. Features can be expressed as one or many high-level scenarios, as shown in Figure 1. T dial busy connect R1 R2 henceforth: dial =d, connect=c, busy=b Figure 1. A Use Case Map that represents a set of scenarios

Functional entities (FEs) collaborate with each other in order to describe features. We can use different collections of FEs for the design of one feature. Choices have to be made at this level (see Figure 2). Figure 2. Two collections of Functional Entities FE1 FE3 FE2 FE4 FE1 FE5FE6

The mapping of scenarios to architectures is done through responsibilities allocated to components (FEs in this case). For one specific collection of FEs (the left alternative in Figure 2), many mappings are possible. Figure 3 illus- trates two such mappings for our scenario. Very useful design information can be collected and reasoned about at this level of abstraction. Figure 3. Feature scenario on Functional Entities FE1 FE3 FE2 FE4 FE1 FE3 FE2 FE4 T d b c R1 R2R1 R2 d b c T

Functional entities are used in IN’s distributed functional plane. In the physical plane, the architectural components are called Network Entities (NEs). Again, many structures of NEs are possible for the support of features, as shown in Figure 4. Figure 4. Two collections of Network Entities, with channels NE1 NE2 NE1NE2 NE4NE5 NE3

FEs being mostly static (not mobile), they can be allocated to NEs. Figure 5 shows that for one specific structure of NEs (the left alternative in Figure 4), our collection of FEs can be distributed in many ways. Figure 5. Functional Entities on Network Entities NE1 NE3 NE1 NE3 FE1 FE3 FE2 FE4 FE1 FE2 FE4 FE3 NE2

From the mapping of scenarios to FEs and the mapping of FEs to NEs, we get the following result for free (Figure 6). Responsibilities become allocated to NEs, and communication channels that link NEs can be used to implement causal relationships between responsibilities. Figure 6. Scenarios bound to Functional Entities and Network Entities NE1 NE3 NE1 NE3 FE1 FE3 FE2 FE4 FE1 FE3 NE2 T d b c R1 R2 FE2 d c T R1 R2 FE4 b

In order to derive valid Message Sequence Charts (MSCs) from scenarios bound to a structure of NEs, we need to: define coordination messages and information flow between NEs satisfy the constraints imposed by the channels satisfy the constraints imposed by causal relations between responsibilities From the path in our scenario, MSCs can be generated according to the chosen structure, coordination, and information flow (Figure 7). Figure 7. Message Sequence Chart derived from our UCM scenario NE1 NE3 FE1 FE3 FE2 FE4 NE2 T d bc R1 R2 c d T m1 m2 R2 NE1NE2NE3

Figure 8. Two Message Sequence Charts derived from one UCM scenario R2 NE2 NE1 NE3 R1 b d c A different binding causes channel constraints to be satisfied differently from those of Figure 7 More complex coordination and information flow c d T m2 m1 R2 NE1NE2NE3 m3 T NE1NE2NE3 c d R2 m1 m2 m3m4 m5 m6 m7 T

Figure 9. Example: from UCMs to LOTOS structure and processes R2 NE2 NE1 NE3 R1 b d c The component structure is mapped to a composition of processes T Each compo- nent becomes a process that implements all traversing paths (possibly from many scenarios) specification Feature [T, R1, R2]… hide Chan12, Chan 23 in (NE1[T, Chan12] | | | NE3[Chan23]) | [Chan12, Chan23] | NE2[R1, R2, Chan12, Chan23] where (* Components as processes *) … endspec (*Feature*) process NE2[R1, R2, Chan12, Chan23]... hide b, c in Chan12 !m1; Chan23 !m2; NE2[…] Chan23 !m3; c; R2; NE2[…] Chan12 !m8; Chan23 !m9; NE2[…] Chan23 !m10; b; R1; NE2[…] endproc (*NE2*)

Many testing strategies, techniques, and tools can be used to validate the com- position of features with respect to their intended behaviour. Figure 10 shows two test cases, derived from the original UCM, that must be accepted by the Feature specification of Figure 9. Figure 10. Example: test cases generation from UCMs process Test1[T, R1, R2, success] : noexit := T !some_parameters; R1; success; stop endproc (*Test1*) process Test2[T, R1, R2, success] : noexit := T !other_parameters; R2; success; stop endproc (*Test2*) c b d R2 R1 T Other techniques could help validate, for instance, that specific partial traces exist (e.g., using goal-oriented execution: GOAL [T, R1]), or that some prop- erty, derived from the UCM, is satisfied by the resulting specification (e.g., using model checking: AG( ‘ T ’ -->AF ( ‘ R1 ’ v ‘ R2 ’ )))