Introduction to the Sequence Diagrams with stereotypes Department of Information Systems and Computation (DSIC) Valencia Polytechnic University

2 Requirements Analysis Process Sequence Diagram A Use Case functionality is specified identifying interacting classes and messages that they interchange Structure and Notation

3 Requirements Analysis Process Sequence Diagram Blocks: they are used to specify conditions or iterations that affect to one or many messages NOT ALL the messages are of the same nature… An UML extension is introduced (stereotypes) to classify messages according to its nature: «signal», «service», «query», «connect»

4 Sequence Diagram Stereotypes extension « Signal » stereotype

5 Sequence Diagram Stereotypes extension « Service » stereotype

6 Sequence Diagram Stereotypes extension « Query » stereotype

7 Sequence Diagram Stereotypes extension « Connect » stereotype

8 Sequence Diagram Stereotypes extension « Connect » stereotype example

9 An example 2- Functionality is specified identifying object classes and interactions 1- Use Case is identified and its actor(s) specified Sale items Cashier

10 RAP – Sequence Diagram (1/8) (Relevant actors are identified) Sale items Cashier

11 RAP – Sequence Diagram (2/8) (Messages between actors and the system) Sale items Cashier

12 RAP – Sequence Diagram (3/8) (Internal messages, Sale and Sale-line are identified)

13 RAP – Sequence Diagram (4/8) (To create a sale-line it’s necessary an item) until end of lines

14 RAP – Sequence Diagram (5/8) (the cashier finishes the data entry) until end of lines

15 RAP – Sequence Diagram (6/8) (Subtotal has to be calculated and also the item stock has to be updated) until end of lines

16 RAP – Sequence Diagram (7/8) (Final information about the sale is shown) until end of lines

17 RAP – Sequence Diagram (8/8) (Messages are stereotyped) <<signal>> <<signal>> <<service/new>> <<service/new>> <<connect/1,1>> <<query>> <<query>> <<service>> <<signal>> <<signal>> until end of lines

18 Summary Sequence Diagrams (SD) are used to specify functionality in terms of object interactions (they are not algorithm specifications!) Objects from classes communicate each other by sending messages A SD is structured in three regions:  External: actors outside of the system – users  Interface: user interface (boundary class) to receive information from actors or to show information produced by the system  Internal: classes in which the system is structured Depending on the nature of messages they are classified in:  Signal: messages to get information into the system or to show information from the system  Service: messages that change the state of the system (create, destroy, update)  Query: messages to query the state of an object or a set of objects  Connect: messages that relates objects to each other (when an object needs to be “connected” to other objects)