Sequence diagrams -Introduction

Class diagrams show how classes will interact and enable the programmer to create a “shell”, Class definitions, inheritance and aggregation can be automated by a CASE tool (computer aided software engineering). If you think of class diagrams as the structure of the program a sequence diagram would be the interactions.

Sequence diagrams work on the object level. They show how objects will communicate with each other, what messages they will pass and the order they are passed in. It also shows when a object is created or destroyed. Specifying the order which methods are called is essential. Consider a customer using a ATM machine. The sequence of events should be -

• Enter card
• Enter pin number
• Enter cash amount
• Check account pin and if they have enough money in their account
• Dispense money
• Dispense card

What happens if we dispensed the money before checking the pin number? Clearly this would be a critical system flaw and would cause massive issues for customers and banks alike. However the only mistake we have made is moving one event. Hopefully this is enough to convince you of the importance of sequence diagrams!

Object – This is an instantiated object of a class. You can see a object as a concrete example of the representing class. In the example above a Quiz object would a actual Quiz while the Quiz class would represent ALL possible quizzes.

Time line – The doted line represents time. Time flows from top to bottom.

Active object –When a object is created it becomes active. This means that it is in use and available for communication. The solid box on top of the dotted line shows if a object is active. A object only needs to be active when it is needed.

Method call – This is based on the class diagram (which restricts what methods are available for communication) . The class diagram also shows exactly what classes may communicate with. A method call will show that one object has called a method on another object.

Message (or return) – When a method returns it may pass information back. This is represented as a message. A message could also be an event and could be based on the listener design pattern.