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.
A use case diagram is another diagram that comes from UML. The name can be a little misleading. It sounds like a diagram of a use case, and it isn't. It's almost always a diagram of several use cases and multiple actors at the same time. The reason it exists is so we can get an overview of these and see how they interact all in context. So it's not a replacement or substitution for a written use case. It's not the same thing. We still need the written use cases, we have this so we can see a different perspective.
So, imagine that we've been asked to write a simple knowledge base for an organization. We've talked to the customer, written a few casual use cases, brainstormed some actors of this new system that we plan to build. The use case titles are in no particular order, Search Articles, View an Article, Manage Users, Create an Article, and View Analytics. I am not trying to be exhaustive here, just list a few use case goals that make sense. Let's say our actors are all role-based. We've got a Visitor, a Contributor, and an Administrator.
Now I'll use stick figures to represent the primary actors, and this is how you represent actors in a UML use case diagram, because stick figures are easy, easy on paper, easy on a whiteboard, you don't have to have drawing skills. We're not trying to make this look impressive. Just as I show actors with stick figures, I'm going to draw ellipses around my use case titles. This is the way we make it obvious that this is a self-contained use case and not just a piece of text. Now I'm going to draw a box around all the use cases.
This box represents the boundaries of my system, my knowledge base application that I'm going to write. Anything inside the box is part of my system and anything outside is not. So the actors are all outside. Next, I'll draw a line between any of the actors and the use cases they will interact with. So let's say a Visitor can search and view articles, a Contributor can create articles, and an Administrator can manage users and view statistics. Now of course, the Administrator would likely be able to search articles and read articles, too, although you could argue that when doing that he's just the same as the Visitor role.
Now these lines don't need arrows. It's not really about direction, it's merely saying this actor uses this use case. I'm also going to say they we're using a separate external computer system to store our article analytics data. So I'll represent that external system over here on the right. Now I could use another stick figure, because it's an actor. But because it's a non-human actor, I prefer to use a box. Though in that box, I'm going to write the word actor with these two angle quotes just to make it obvious.
You can use to two less than signs and two greater than signs around the word actor, although officially it is the French style quote, the guillemots, sometimes called angle quotes or chevrons here. I'm going to connect lines between this external system and the two use cases I plan to use with it. The View Article use case, which would save some analytics data back to this external system, and the View Analytics use case, which would allow the administrator to read the details of them. Now typically you put the primary actors on the left-hand side, these are the ones who initiate any of the use cases and the secondary actors on the right-hand side, and these actors take more of a reactive role, but even that's not a hard and fast rule.
Now this diagram is not referring to sequence. There is no necessary order to it. Sometimes people will write the use cases in order from the top down if the application naturally flows that way, but very often the use cases themselves don't have a built-in sequence. It's a simple overview of multiple use cases and multiple actors at the same time without the details of each particular written use case. It can be useful as a Communication tool, even with business users as it's not particularly technical, and sometimes helpful to figure out if something is missing from the picture.
The use case diagrams can get a little deeper than this, but what we've done here will let you read the vast majority of use case diagrams and easily create your own.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.