 Hello and welcome to the session on Unified Modeling Language. In this video, we learn how to draw use case diagrams for a software system to be designed. At the end of this session, students will be able to draw use case diagrams representing designs to be used for software development. You have already learnt about the first two diagrams that is class diagram and object diagram in the previous video. Now pause the video for a while and try to answer this question. What could be the next step after developing class diagram and object diagram in modeling a software system? Here is the answer. It is the use case diagram. The contents we are going to cover are use case diagram introduction followed by use case diagram and example. Use case diagrams are the diagrams in the UML for modeling the dynamic aspects of systems. Use case diagrams are central to modeling the behavior of a system, a subsystem or a class. Each one shows a set of use cases and actors and their relationships. We apply use case diagrams to model the use case view of a system. For the most part, this involves modeling the context of a system, subsystem or class or modeling the requirements of the behavior of these elements. Use case diagrams are important for visualizing, specifying and documenting the behavior of an element. They make systems, subsystems and classes approachable and understandable by presenting an outside view of how those elements may be used in context. With the UML, you apply use case diagrams to visualize the behavior of a system, subsystem or class so that users can comprehend how to use that element and developers can implement that element. A use case diagram is a diagram that shows a set of use cases and actors and their relationships. A use case diagram is just a special kind of diagram and shares the same common properties as do all other diagrams, a name and graphical contents that are a projection into a model. What distinguishes a use case diagram from all other kinds of diagrams is its particular content. Use case diagrams commonly contain use cases, actors, dependency, generalization and association relationships. You apply use case diagrams to model the static use case view of a system. This view primarily supports the behavior of a system, the outwardly visible services that the system provides in the context of its environment. When we model the static use case view of a system, we apply use case diagrams in one of two ways. Number one, to model the context of a system. Modeling the context of a system involves drawing a line around the whole system and asserting which actors lie outside the system and interact with it. Here we apply use case diagrams to specify the actors and the meaning of their roles. Number two, to model the requirements of a system. Modeling the requirements of a system involves specifying what that system should do from a point of view of outside the system, independent of how that system should do it. Here we apply use case diagrams to specify the desired behavior of the system. In this manner, a use case diagram lets you view the whole system as a black box. We can see what is outside the system and how that system reacts to the things outside but not how that system works from the inside. As figure shows, you can provide a use case diagram to model the behavior of that box which most people would call a cellular phone. Starting with the first point, modeling the context of a system. Given a system, some things will live inside the system, some things will live outside it. For example, in a credit card validation system, we find such things as accounts, transactions and fraud detection agents inside the system. Similarly, we find such things as credit card customers and retail institutions outside the system. The things that live inside the system are responsible for carrying out the behavior that those on the outside expect the system to provide. All those things on the outside that interact with the system constitute the system's context. This context defines the environment in which that system lives. In the UML, you can model the context of a system with a use case diagram, emphasizing the actors that surround the system. Deciding what to include as an actor is important because in doing so, you specify a class of things that interact with the system. Deciding what not to include as an actor is equally important if not more because that constrained the system's environment to include only those actors that are necessary in the lives of the system. To model the context of a system, identify the actors that surround the system by considering which groups require help from the system to perform their tasks, which groups are needed to execute the system's functions, which groups interact with external hardware or other software systems and which groups perform secondary functions for administration and maintenance. These actors that are similar to one another in a generalization-specialization hierarchy, where it aids understandability, provide a stereotype for each such actor. Populate a use case diagram with these actors and specify the parts of communication from each actor to the system's use cases. For example, figure shows the context of a credit card validation system with an emphasis on the actors that surround the system. You will find customers of which there are two kinds, individual customer and corporate customer. These actors are the roles that humans play when interacting with the system. In this context, there are also actors that represent other institutions such as retail institution with which a customer performs a card transaction to buy an item or a service and sponsoring financial institution which serves as the clearing house for the credit card account. In the real world, these latter two actors are likely software-intensive systems themselves. Next is modeling the requirements of a system. A requirement is a design feature, property or behavior of a system. When we state a system's requirements, we are asserting a contract established between those things that lie outside the system and the system itself, which declares what we expect that system to do. For the most part, we don't care how the system does it, we just care that it does it. A well-behaved system will carry out all its requirements faithfully, predictably and reliably. When we build a system, it's important to start with agreement about what that system should do, although we will certainly evolve your understanding of those requirements as we iteratively and incrementally implement the system. Similarly, when we are handed a system to use, knowing how it behaves is essential to using it properly. Requirements can be expressed in various forms, from unstructured text to expressions in a formal language and everything in between. Most if not all of a system's functional requirements can be expressed as use cases and the UML's use case diagrams are essential for managing these requirements. To model the requirements of a system, establish the context of the system by identifying the actors that surround it. For each actor, consider the behavior that each expects or requires the system to provide. Name these common behaviors as use cases. Factor common behavior into new use cases that are used by others. Factor variant behavior into new use cases that extend more main line flows. Model these use cases, actors and their relationships in a use case diagram. Add on these use cases with nodes that assert non-functional requirements. You may have to attach some of these to the whole system. Figure expands on the previous use case diagram. Although it shows the relationships among the actors and the use cases, it adds additional use cases that are somewhat invisible to average customer, yet are essential behaviors of the system. This diagram is valuable because it offers a common starting place for end users, domain experts and developers to visualize, specify, construct and document their decisions about the functional requirements of this system. For example, detect card fraud is a behavior important to both the retail institution and the sponsoring financial institution. Similarly, report on account status is another behavior required of the system by the various institutions in its context. These are the references referred. Thank you.