Creating sequence diagrams
Video: Creating sequence diagramsWe've seen a few diagrams, conceptual models, use case diagrams, class diagrams. These are what are considered Structural or Static diagrams. They are great at representing things like the overview of the classes in your application and seeing Inheritance and Composition or the actors in a system. But they are not so great at representing, say, the lifetime of an object or actually how objects interact with one another. So there are also Behavioral or Dynamic diagrams in UML. And these can describe how different objects change and how they communicate with each other.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Creating sequence diagrams
We've seen a few diagrams, conceptual models, use case diagrams, class diagrams. These are what are considered Structural or Static diagrams. They are great at representing things like the overview of the classes in your application and seeing Inheritance and Composition or the actors in a system. But they are not so great at representing, say, the lifetime of an object or actually how objects interact with one another. So there are also Behavioral or Dynamic diagrams in UML. And these can describe how different objects change and how they communicate with each other.
And the most common one is the Sequence diagram. Now a Sequence diagram does not describe the entire system just one particular part of it, one particular interaction between a few objects in one scenario. We start a Sequence diagram with some boxes at the top that represent the objects, the participants in this sequence, could have two, could have three, could have several more. Because we are trying to describe an interaction between what will actually be instantiated objects they usually named a little differently, so not just customer class but a customer.
Instead of shopping cart class, we'd have a cart. If you want to use the name of the class you can actually have instance name: class name, and if you do just want to use the class name it's good practice to keep the colon as in colon order. Beneath these we stretch out some dotted lines, these represent lifelines, the timeline of these objects, we are going to begin at the top representing this timeline of interaction, a sequence. And we start to represent the messages that go between the objects. First will be say a checkout message, Customer is telling the Shopping Cart, I want to check out.
The Shopping Cart is going to create a new order to initiate an order object. Once that happens we realize that the shopping cart needs to start adding the different items to this order object. These messages that we are writing can be named very simply or they can be named with parameters such as I'm doing here, when I add an item I know that I will need to tell the order, what item it is, what quantity it is. So if I am doing solid arrows with the full head here, these are regular calls, regular messages. If I want a diagram then I'm expecting a response I would use a dashed arrow with a stick head.
Now you don't always need to write down the return messages only when they add value. You'll also sometimes see solid boxes written on the lifeline called Activation boxes or method-call boxes. These really are representing processing being done in response to--in this case the addItem message. Now these boxes aren't terribly important, and if I'm drawing on paper or on a white board I'll rarely use these because they're kind of annoying to do. Now if we realize that this addItem message might need to happen multiple times if I have multiple items in the cart we can surround this with what's called a Frame and in this case I am saying it's a loop, I'm going to do this for all items in the cart.
Now quite importantly we are not trying to model this entire scenario down to the last conditional and the last iteration, that's not what sequence diagrams are for, they offer an overview of the important parts of this process not to try and model every last if statement or while loop. So we continue on realizing the shopping cart, we will then say, okay, we need to calculate the discount, and we need to start finalizing the sale. That's going to involve a bit of processing in the order object, that will then send the total back.
And even though this might go back to the cart, we realize that effectively that's being passed all the way back to the customer who is going to be the one to submit payment. Now the way that we might have started charting out our conceptual model or class diagrams we now realize we don't have anything here to take care of that payment itself we are using an actual payment class for that. So I can write down the idea that we can initiate a message from order that's going to create a new payment object, and the only reason for this payment object to exist is to validate that payment and return a response, and then it goes off the Timeline. In fact, we can indicate that by saying we will send back some results, and then we'll put in the x here to say the payment's lifeline is now over.
Whether that was successful or not, the object doesn't exist anymore. So order has been given results, we then send those all to the customer. Now one of the benefits of a Sequence diagram is that at this level of interaction you should be able to sit down with say a business user, someone who is not a developer and explain this general process and they can hopefully give you some ideas whether that would be correct or whether something else is missing out of this. These are a thinking tool to help you think through this process.
You may create several Sequence diagrams to help you understand the specific scenarios, but do be aware that there is no need to try and diagram every single part of your application. That's a common beginner's mistake. You don't need to do that. These are for sketching out a situation that's not completely clear already, and they do a great job of making it clear who needs to perform processing in response to what. And they will often result in you realizing that a new class needs to be created somewhere.
And if that happens in this process, then that's great. You may end up changing your class diagrams in response to the work that you do here.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.