Welcome to this lecture on use cases and UML. This is the last of the methods in the UX research cycle that we're going to talk about. What I'm trying to cover in this lecture is really to present both types of use cases that are commonly seen, text-based use cases, and UML diagram based cases. We'll talk about the strengths and weaknesses of those approaches. Since we're talking about UML, we'll also talk about some of the other UML diagrams that might help your design cycle as you're trying to build the requirements and capture what the design is. But let's dig into use cases. Again, this is one of the most common user research tools to document what a user's trying to do with this system. The tasks and scenarios that are going to play out as they use the device or system that you're developing. Again, use cases can be done in text using a template form, or they can use a special UML diagram. UML stands for unified modeling language. We'll look at where that came from. It's very useful in a lot of ways for use cases, certainly. But there's some other diagrams, sequence activity, state, and class diagrams that are commonly used. And we'll look at those as well just to give you an idea of how UML might fit into your designs. So use cases really probably straddle research and design. This is where you're finalizing what it is that your system is going to address. Usually comes up as part of user research and starts to capture both some system design concerns and business requirements for what it is you're going to produce. You can combine the focus on the business side, which is really what the user is focusing on, versus what the system is going to be doing. Use cases generally tend to focus on user activities and we'll talk about that. One thing you don't want to do is dismiss use cases because they look easy. When you see the templates for both the text version and the UML version they're fairly straightforward to put together. But what you have to do is also include some diligence to make sure that what it is you're designing represents that users concern for that specific scenario and captures what the system will be doing. Not how it does it, that comes later in design, but what it is that they're trying to do during a specific task scenario. You want to avoid getting into an in kind of a functional decomposition. Or breaking down what it is that the system is going to be doing. That's not what this is about. Text-based use cases are probably the most common thing you'll see. A lot of what I talk about here comes from Alistair Cockburn, who created a book called Writing Effective Use Cases. He also did a nice presentation on agile use of use cases. He talks about what is and isn't a good use case. And interestingly, he has a bias towards the text-based use case. He doesn't feel that UML use cases are a good way to go. I would dispute that and we'll talk about it. More importantly, probably, are the other constraints that he places on use cases. They shouldn't include any sort of a UI. They shouldn't include any details on data formats. They should really include 3 to 9 steps on what it is that a user is trying to do in a given scenario. They should be very easy to read and they should focus on what the user's goal is. Use cases can be developed in an up front manner all at once. They can be developed iteratively. They can be developed when an issue comes up. They can be written completely, or they can be written incrementally and detailed as more information becomes available. Here's an example use case of something called placing an order. This is from Coborn's agile use case presentation. Pretty typical, it includes what the goal of the primary actor is, what the title of the use case is, what happens during this scenario. In this case, a clerk identifying a customer and the items that are being targeted, and the system accepts and queues the order. There's also a common extension, part of the use case that talks about conditional things that might happen during a scenario. What you'll find is there are many alternative templates to use to create text use cases. It makes sense for you to spend a little bit of time looking at those templates to find one that you're comfortable with that you think best fits how you want to capture this kind of information. The key elements, again, are a short summary of the system goals. Making sure you capture the main success scenario that the user is expecting, which really drives what the system is responsible for. And what things might be, extensions or conditional elements of the use case that you might have to think about or that might have impacts on decisions that are made during the design cycle. The suggested way to create these things is to start with the basics. Title the use case, figure out what the goal for it is, who's doing the work, how important it is, how frequently they do the task. And then start to look at what the triggers are and what the steps are that lead you through the main scenario. Once that's done, you can start to think about the conditional extensions and other variations. And you might drive it further into performance targets or other issues or schedule elements that impact a given use case. Again, a wide variety of templates. Cockburn presents a very complex use case template that has lots of different sections on related information. Typically, most people use a very simple format. I would say the name of the case, the summary of the task, who the actor is, any preconditions, what the flow of the task is, what triggers certain changes. Maybe who the stakeholders are that they're doing this task for. I've given a link here for over 40 different templates, so you'll start to see that there's a lot of variation in how you capture this information. That variation, frankly, is one of the reasons that I like to focus more on the UML side of use cases. But again, your mileage may vary and you can decide which type of use case makes most sense for you. UMLs been around for a long time, it's a graphical language for describing software designs. And it comes out of the effort to take several different competing graphical notations and drive them into a single unified one which is controlled by a group called the Object Management Group. If UML is done thoroughly, you can actually create executable code and code generation, but really most people just use it as a documentation tool. As you'll see here, a UML use case is pretty simple, and it focuses on who the actor is, what the high level elements of the tasks are that are being done. And it captures the entire flow of a given scenario moving from task to task. This view of the system from the actors viewpoint, really can be very valuable. And I do think here are in these use cases, you get a sense of that picture versus 1,000 words balance. Use cases in UML have two additional nomenclatures. There's an include phrase and an extends phrase. An include phrase points to shared or required tasks that are not optional that have to be done as part of a full flow. The extends phrase talks to optional or conditional tasks. And this is a typical example of a fairly simple use case. There's a book that I like called UML for Mere Mortals that talks about use cases in. In that book, it's posited that most of the times use case diagrams probably should number In the 10s, not the 100s there. You should really focus on what the key priorities are. And you can flesh these out as you learn more about the system. So the one element from that book that I particularly liked was a thing called the WAVE test and this simple acronym really represents a way to think about use cases that I think is very valuable. What the use case should do? Who the actor is that has the point of view on the use case? What value there is in this operation for that actor? And does the use case model the entire scenario that that actor has to perform? This is a really great way to keep good design for use cases tucked in your head for when you have to go through one of these exercises. I do want to touch quickly on some other useful UML diagrams that might help you as you develop your designs. The UML definition includes over 20 different types of diagrams, and I would encourage you to go take a look at the different structural behavior role in supplemental models that are out there. You might find some particular UML diagram fits a particular design that you're doing, but what I would say is most design tools for UML kind of circle in on of five diagrams that are pretty common in creating requirements for a system. The use case, but also see sequence activity, state and class, so we'll take a look at these four just so you can see what they look like. Again, you'd probably want to look for a UML tutorial if you were going to be doing these in detail. Sequence diagrams are great and I've used them quite a bit because I deal with embedded devices that are often making message transactions. A sequence diagram really helps to show how the different objects in a system communicate with each other and just by looking at the diagram, you can usually see the lifetime of a given object and you can also see how messages are moving between the objects. Really effective way to diagram a lot of information in a small space. UML activity diagrams really aren't much different from old-fashioned flowcharts. There a little more structured and they can be partitioned to identify separate workflows that might be going on, but really as with the flow chart, it kind of helps identify the start and end of a given condition and the steps that are happening during the activity. These can be used as a way to document task analysis which we talked about earlier is one of the main user research methods. UML state diagrams are similar to activity diagrams, but they're really looking at how a system is moving through different states. This is common again in creating devices that are based on state machines and helps define what those states are and how conditions might come up that might move you from different states to other states. So again, I'd recommend you take a look at these as part of your design toolkit. Finally, class diagrams are little more specific to object-oriented software development. You may or may not be using those kind of tools in a given design, but if you are using something like C++, or Java, or C Sharp where you're using an object-oriented language, being able to use a standardized diagram to define your system and the architecture of your system, including the attributes and the member functions that make up your classes can be really valuable. And again, if it's done at a detailed enough level, there are tools out there that can be used to create code from the diagrams. You'll see lots of UML tools and resources out on the web. I've included a link for a tutorial here. You can use almost any kind of tool to do UML diagram, as you can do them on paper and pencil. You can do them on a white board and take pictures with a digital camera. You can do them inside a drawing tool or in a word processor, but I would suggest that if you're going to be doing a lot of UML, that you dig into the wide variety of open UML tools that are out there. There's a picture of one here called StarUML, but really, there are a lot of different tools available to create these basic diagrams. So in summary, use cases are extremely common tool in very useful for detailing the key user interactions that you'll have as you create your systems. You'll need to decide whether it makes sense to use words to describe those use cases, or whether you want to use a picture using UML. I personally tend towards UML, but certainly text-based description of a system is just as valuable. So take a look at these approaches, consider how they might help your designs, and think about how they would blend into all the methods you might use to closeout the UX research phase of a development cycle and move into your design and verification stages. Thank you.
