In these slides, a scientific paper was presented for a group of graduate students. The slides shows some fundamental concepts of the original paper. For more information, please refer to the paper, https://dl.acm.org/citation.cfm?id=287875

1. Desharnais J. et al.

2. § Short questions and comments are welcome during the presentation.
§ However, long questions and comments may be asked by the end of
this presentation in the (Discussion Period).
§ Each slide has a unique title and number that may be refer to later
during the discussion period.
§ For the sake of simplicity, “WQ” questions will be used just initially.
§ A sheet of paper has been distributed. It is supposed to assist you to
assess your understanding. However, participation is completely a
personal choice. (The choices you make, the risk you take)

3. § Paper Information /* Who ?, When ?, Where ?*/
§ Integration of Sequential Scenarios /* What ?, Why ? */
§ Methodology of Scenario Integration /* How ? */
§ Discussion /* return long_question() ;-) */

4. Jules Desharnais, Marc Frappier,
Ridha Khédri, Ali Mili
September 1998
IEEE Transactions on Software Engineering Vol. 24 No.9
WHO
WHEN
WHERE

6. /* what is a scenario? */
A scenario is a partial description of the interaction between
a user and a computer system. [see paper for references]
Usage /*WHY*/
Scenarios are used to support requirements elicitation
and specification generation
Scenarios are used informally,
and also defined formally [see paper for references]

7. Scenarios have many benefits and usages,such as the concept of
Combining formallypartial scenarios to produce more global
descriptions of the system that we wish to specify [see paper for references]
/* what does the title mean ? */

8. It simply offers the possibility to move from informal to formal
descriptions at the level of scenarios rather than at the level of
the system specification.
/* why FORMALLY ? */

9. HOW
To integrate sequential scenarios

10. /* short answer */
Represented by means of relations
Defined by means of relational operation

11. /* short answer (2) */
Represented by means of relations
Defined by means of relational operation
Or, equivalently, by means of relational
transition systems, which are graphs.

12. /* a little */
𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛 𝑆𝑦𝑠𝑡𝑒𝑚𝑠
𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛 𝑆𝑦𝑠𝑡𝑒𝑚𝑠
𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛 𝑆𝑦𝑠𝑡𝑒𝑚𝑠

13. /* again, a little */
/𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛 𝑆𝑦𝑠𝑡𝑒𝑚𝑠
Each Relational Transition Systems Uniquely defined relation
A relation Equivalent Relational Transition Systems [see paper]
map semantically
map semantically

14. /* warning */

15. DEFINITION 1.
𝑇ℎ𝑒 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑅 𝑜𝑛 𝑎 𝑠𝑒𝑡 𝑇 𝑖𝑠 𝑎 𝑠𝑢𝑏𝑠𝑒𝑡 𝑜𝑓
𝑡ℎ𝑒 𝐶𝑎𝑟𝑡𝑒𝑠𝑖𝑎𝑛 𝑝𝑟𝑜𝑑𝑢𝑐𝑡 𝑜𝑓 𝑇 𝑤𝑖𝑡ℎ 𝑖𝑡𝑠𝑒𝑙𝑓,
𝑡ℎ𝑎𝑡 𝑖𝑠, 𝑅 ⊆ 𝑇 ×𝑇.
(Some) possible operations on relation include:
𝐸𝑚𝑝𝑡𝑦 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛, 𝐼𝑑𝑒𝑛𝑡𝑖𝑡𝑦 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛, 𝐶𝑜𝑛𝑣𝑒𝑟𝑠𝑒, 𝑈𝑛𝑖𝑜𝑛,
𝐼𝑛𝑡𝑒𝑟𝑠𝑒𝑐𝑡𝑖𝑜𝑛, 𝐷𝑜𝑚𝑎𝑖𝑛, 𝑅𝑎𝑛𝑔𝑒 …

16. 𝐿𝑒𝑡: 𝐴 = 1,2, 3 , 𝐵 = 𝑢, 𝑣 ,
𝑅L = 1, 𝑢 , 2, 𝑢 , 2, 𝑣 , 3, 𝑢 ,
𝑅M = { 1, 𝑣 , 3, 𝑢 , 3, 𝑣 }
𝑅L ∪ 𝑅M =
𝑅L ∩ 𝑅M =
𝑅L𝑅M =
𝑅M𝑅L =
𝐷𝑜𝑚 𝑅L =
{(1, 𝑢), (1, 𝑣), (2, 𝑢), (2, 𝑣), (3, 𝑢), (3, 𝑣)}
{(3, 𝑢)}
{(1, 𝑢), (2, 𝑢), (2, 𝑣)}
{(1, 𝑣), (3, 𝑣)}
{1,2,2,3}
Time is up !

17. For instance:

18. /* the last little */

19. DEFINITION 3.
𝐿𝑒𝑡 𝑇 𝑏𝑒 𝑎 𝑠𝑒𝑡. 𝐿𝑒𝑡 𝒱 𝑎𝑛𝑑 𝒫 𝑏𝑒 𝑡ℎ𝑒 𝑠𝑒𝑡 𝑜𝑓 𝑣𝑒𝑐𝑡𝑜𝑟𝑠 𝑎𝑛𝑑 𝑡ℎ𝑒 𝑠𝑒𝑡 𝑜𝑓 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠
𝑜𝑣𝑒𝑟 𝑇, 𝑟𝑒𝑠𝑝𝑒𝑐𝑡𝑖𝑣𝑒𝑙𝑦. 𝐴 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑡𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛 𝑠𝑦𝑠𝑡𝑒𝑚 𝑖𝑠 𝑎 6-𝑡𝑢𝑝𝑙𝑒:
𝑁, 𝐴, 𝛼, 𝛽, λ, λ]
𝑤ℎ𝑒𝑟𝑒
𝑁 𝑖𝑠 𝑎 𝑠𝑒𝑡 𝑜𝑓 𝑛𝑜𝑑𝑒𝑠,
𝐴 𝑖𝑠 𝑎 𝑠𝑒𝑡 𝑜𝑓 𝑡𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝑠 𝑎𝑟𝑟𝑜𝑤𝑠 ,
𝛼, 𝛽: 𝐴 → 𝑁 𝑎𝑟𝑒 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠 𝑔𝑖𝑣𝑖𝑛𝑔 𝑡ℎ𝑒 𝑠𝑜𝑢𝑟𝑐𝑒 𝑎𝑛𝑑 𝑡𝑎𝑟𝑔𝑒𝑡
𝑛𝑜𝑑𝑒 𝑜𝑓 𝑎 𝑡𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛, 𝑟𝑒𝑠𝑝𝑒𝑐𝑡𝑖𝑣𝑒𝑙𝑦,
λ: 𝑁 → 𝒱 𝑖𝑠 𝑎 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝑎𝑠𝑠𝑖𝑔𝑛𝑖𝑛𝑔 𝑎 𝑣𝑒𝑐𝑡𝑜𝑟 𝑡𝑜 𝑒𝑎𝑐ℎ 𝑛𝑜𝑑𝑒,
λ]: 𝐴 → 𝒫 𝑖𝑠 𝑎 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝑎𝑠𝑠𝑖𝑔𝑛𝑖𝑛𝑔 𝑎 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑡𝑜 𝑒𝑎𝑐ℎ 𝑡𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛.

20. Consider the above transition system, where 𝑥: ℤ.
For this system, complete the following:
𝑁 = {1,
𝐴 = { 1,2 ,
𝛼 1,2 = 1,
𝛽 1,2 = 2,
λ 1 = 𝑥 ≥ 3 ,
λ] 1,2 = 𝑥` = 𝑥 − 1 ,
Time is up !
𝑁 = {1,2,3}
𝐴 = { 1,2 , 2,3 }
𝛼 1,2 = 1, 𝛼 2,3 = 2
𝛽 1,2 = 2, 𝛽 2,3 = 3
λ 1 = 𝑥 ≥ 3 , λ 2 = 𝑥 ≥ 2 , λ 3 = 𝑥 ≥ 4
λ] 1,2 = 𝑥` = 𝑥 − 1 , λ] 2,3 = 𝑥` = 𝑥M
,

21. /* warning, (repeat) */
/* should be by now */
/* should be by now */

22. A scenario is a partial description of the interaction between
a human user and a computer
A scenario is a partial description of the interaction between
an unconstrained system, called the environment (a human user being a particular case)
and a computer-based system (program), simply called the system in the
sequel

23. DEFINITION 4. 𝐴 𝑠𝑐𝑒𝑛𝑎𝑟𝑖𝑜 𝑖𝑠 𝑎 𝑡𝑟𝑖𝑝𝑙𝑒 𝑇, 𝑅e, 𝑅f ,
𝑤ℎ𝑒𝑟𝑒
𝑇 𝑖𝑠 𝑎 𝑠𝑝𝑎𝑐𝑒 (𝑖. 𝑒. 𝑎 𝑠𝑒𝑡 𝑜𝑓 𝑠𝑡𝑎𝑡𝑒𝑠),
𝑎𝑛𝑑 𝑅e 𝑎𝑛𝑑 𝑅f 𝑎𝑟𝑒 𝑡𝑤𝑜 𝑑𝑖𝑠𝑗𝑜𝑖𝑛𝑡 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠 𝑜𝑛 𝑇
𝒕𝒉𝒂𝒕 𝒊𝒔, 𝑹 𝒆 ∩ 𝑹 𝒔 = ∅ ,
𝑐𝑎𝑙𝑙𝑒𝑑 𝑡ℎ𝑒 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝑡ℎ𝑒 𝑒𝑛𝑣𝑖𝑟𝑜𝑛𝑚𝑒𝑛𝑡
𝑎𝑛𝑑𝑡ℎ𝑒 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝑡ℎ𝑒 𝑠𝑦𝑠𝑡𝑒𝑚, 𝑟𝑒𝑠𝑝𝑒𝑐𝑡𝑖𝑣𝑒𝑙𝑦.
𝑇ℎ𝑒 𝑟𝑒𝑙𝑎𝑡𝑖𝑜𝑛 𝑅e ∩ 𝑅f 𝑖𝑠 𝑐𝑎𝑙𝑙𝑒𝑑
𝑡ℎ𝑒 𝒓𝒆𝒍𝒂𝒕𝒊𝒐𝒏 𝒐𝒇 𝒕𝒉𝒆 𝒔𝒄𝒆𝒏𝒂𝒓𝒊𝒐.
/* Formal Definition */

24. The first scenario that we consider is about the checkout of a book. The informal description of this
scenario, given by the client to the specifier, is the following:
The reader comes in. The system is in the initial state of the reader_serv menu. The user enters the
name of the reader. If the system does not know this name, then the user either:
1) switches to the registration menu, or
2) reenters the name correctly, or
3) goes back to the initial state of the reader_serv menu
(and abandons the operation)
the system knows the reader’s name, it asks whether the transaction is a checkout or the return of a
document. The user may choose to return to the initial state of the reader_serv menu (abandoning
the operation) or choose the checkout option. In the latter case, for each document that the reader
wants to borrow, the system displays the list of books already loaned to the reader and asks for the
code of the new document; the user then enters the code of the borrowed document, the system
adds the document to the set of documents borrowed by the reader, and also registers who the
document is loaned to (so that it is possible to obtain the name of the borrower from a description of
the document). The user finally returns the system to the initial state of the reader_serv menu.

25. 1) A, a set of symbols (an alphabet). In what follows, A+ denotes the set of nonempty finite
sequences of elements of A, and A* = A U {λ} where λ is the empty sequence.
2) C, a set of commands. Commands begin with the symbol ‘@’. These commands are given by
the user to navigate the menus.
3) Readers: P(A+), the set of readers known to the system, where the symbol P denotes the
power set operator.
4) r: A+ , a variable used by the system to hold the name of a reader.
….
8) i: A* U C, an input variable. It is set to a nonempty sequence by the user to transmit
information to the system. The system resets it to λ by consuming it.
9) o: A*, an output variable. It is set by the system to transmit information to the user.
10) M: A+, a variable giving the name of the current menu. It is set by the system.
The first scenario that we consider is about the checkout of a book. The informal description of this scenario, given
by the client to the specifier, is the following: The reader comes in. The system is in the initial state of the
reader_serv menu. The user enters the name of the reader. If the system does not know this name, then the user
either: 1)switches to the registration menu, or 2) reenters the name correctly, or 3) goes back to the initial state of
the reader_serv menu (and abandons the operation) If the system knows the reader’s name, it asks whether the
transaction is a checkout or the return of a document. The user may choose to return to the initial state of the
reader_serv menu (abandoning the operation) or choose the checkout option… [see paper for a complete description]

26. The reader comes in. The
system is in the initial state
of the reader_serv menu.
The user enters the name of
the reader. If the system
does not know this name,
then the user either:
1)switches to the
registration menu, or 2)
reenters the name correctly,
or 3) goes back to the initial
state of the reader_serv
menu (and abandons the
operation) If the system
knows the reader’s name, it
asks whether the transaction
is a checkout or the return of
a document. The user may
choose to return to the
initial state of the
reader_serv menu
(abandoning the operation)
or choose the checkout
option… [see paper for a complete
description]

27. The scenario is about the enrolment of a class. The informal description of this
scenario, given by the administrator to the specifier, is the following:
The student login the system. The system is in the initial state of the class_enrol
screen. The student enters the name of the class. If the system does not know
this name, then the student either: 1) reenters the name correctly, or 2) goes
back to the initial state of the class_enrol screen (and abandons the operation) If
the system knows the class’s name, it asks whether the transaction is an
enrollment or drop. The student may choose to cancel and return to the initial
state of the class_enrol screen (abandoning the operation) or choose the
enrollment option [a partial description as an exercise]
Time is up !

28. 28
The student login the
system. The system is in the
initial state of the
class_enrol screen. The
student enters the name of
the class. If the system does
not know this name, then
the student either: 1)
reenters the name correctly,
or 2) goes back to the initial
state of the class_enrol
screen (and abandons the
operation) If the system
knows the class’s name, it
asks whether the transaction
is an enrollment or drop. The
student may choose to
cancel and return to the
initial state of the
class_enrol screen
(abandoning the operation)
or choose the enrollment
option [a partial description as an
exercise]
S = class_enrol
i = λ
o = name?
S = class_enrol
i = λ
o = unk;name?
S = class_enrol
i = λ
o = enrl, drp?
S = class_enrol
i ∈ A+
o = name ?
S = class_enrol
i ∈ A+
o = unk; name ?
S = class_enrol
i = @enrol
o = enrl, drp ?
S = class_enrol
i = @class_enrol
o = unk; name?
S = class_enrol
i = @class_enrol
o = enrl, drp ?
𝑖 ∉ 𝐶 ⋀𝑐y
= 𝑖
𝑖 ∈ 𝐶 ⋀𝑐y
= 𝑖
S:A+, a variable of the current screen
Class: P(A+), the set of identified class.
c: A+, a variable holds the class’s name

29. /*Finally */

32. /* ;-) */