hello friends in this video we are going to learn about the use case diagrams of uml we will practice use case diagram with the online tool that is visual paradigm but after having a brief introduction of use case diagram its usage characteristics and notations so let's start so uml is unified modeling language that is used to describe the language of an application with some common notations and it is worldwide used for various organizations to represent their work so that one can easily understand the work done by other person with the with the help of common notation there are so many or we can say that around 14 types of diagrams included with the unified modding language to represent different stages and different scenarios of the application to be developed by an organization so there can be use case diagrams activity diagrams state diagrams class object diagrams etc so we will be learning them one by one in this video we are focusing only on the use case diagram so use case diagrams are used to gather the requirements so we can say that at the first stage means we need to gather the requirements for every application to be developed and for this requirement gathering requirement elicitation analysis and to prepare the software requirement specification document we need to present the results with the help of use case diagrams because the graphical notations are always better than the documentation so here we will be using some basic notations for representing the requirements to the user and to other team members working with the design of of the project working with the implementation of the project so this use case diagram will be used as the basic for all other stages of the life cycle for a for a software development project and it include so use case diagrams are used to represent internal and external influences means they are they will be used to represent the internal entities or we can say that internal functions of an application means for a system for a software project what are the necessary functions that will be included so this rectangle is representing the boundary of the system and what other entities means what other external entities are interacting with the system from outside so this type of representation is done with the help of use case diagram so let's have a brief of the notations used for the use case diagram with an example so here these are the notation that can be used for a use case diagram depending on the you are required depending on the applications requirement so first of all we have the system that is represented with the help of rectangular box and this rectangular box will comprise of different use cases so this is the notation means the this oval shape is used to represent different use cases and they are going to represent our goal means our main focus or we can say that the feature that we want to implement for a system one feature will be representing one use case okay so here the use case will be represented by a specific name next is actor so actors are the are the external entities that are inter that are interacting with the internal use cases okay there may be multiple entities interacting with the uh with the system and they may not be linked with or associated with all the use cases okay they may be linked with one two or as per the applications requirement with uh with some or many we can say that number of use cases depending on the requirements an actor can be a user actor can be any other system so you this you should note that actor can be a user can be a customer or can be any external system it can be external system or the sub system that is interacting with the system okay this can be a actor can be a software entity a actor can be external hardware entity so all other things outside the system are actors next we have the notations for the defining the relationships we call them association include extend dependency and generalization so association is used to link or we can say that to define the relationship between actor and the use case if actor if an actor is linked with a particular use case then they are linked or associated with the association line so this is the simple line without any arrow so next we have the include relationship include an extent for these are the stereotype we call them stereotypes so these are two stereotypes include an extent so include is used if i use case if a use case is always requiring some other functionality okay like we always suppose we we are filling the details for some airline ticket booking then we need to make a payment so payment fill details after filling the details we also need to pay the fee or pay the charges of the ticket so this payment module this payment entity is included with the detail where we are filling the details so this use case is including this payment detail always not usually or or not not we can say that sometimes or not on the requirement basis but always so while filling the detail you must make the payment so this use case is including the payment use case next is the case of extend that is not used always so include is mandatory to be used while filling the detail you must make the payment but here the extend is optional suppose you are filling the detail and you encounter some network error or the server is not reachable so all these types of exceptions are extended to a use case and the arrow suppose this first use case is including the second use case then error would be towards the included use case okay the payment is included in the fill details same but on the other case we can say that extended use cases are are marked towards the use case where they are extending the functionality so here the error is extended by extended for the fill detail or you may have server not reachable error so all these types of exceptions like you include some header files in a program and all those files are always included but sometimes you need to extend some other functionalities like you are having exception handling so exceptional handlings is like extends and all the header files that you are including are mandatory for the program to use for the program to include okay next we have the dependency and dependency is defined by only the single arrow without any stereotype so if a one we can say that one use case is dependent on the another use case or one entity is dependent on another entity then we will be using the dependency relationship like for every uh we can say that fill detail or any other functionality any other feature we need the network so internet is required so we can say that fill detail or making the payment is dependent on the availability of the network so here we have the dependency not include or extend relationship next we have the case of generalization so generalization is like inheritance where we are generalizing the case like a person is can be a journal class for any user so a person can be a faculty can be a student so here the person is the common or we can say that base class for the faculty and student because every user every faculty or student can must be a person first means they must possess the properties of a person then they are specialized to faculty or to student we have a detailed discussion of the specialization generalization in the dbms lecture series so here if we are going upwards then this is the generalization relationship and if we are going downward then this is specialization relationship because we are specializing the journal class so general class is person class that can be used as a base class or can be abstract class for faculty and student and we can we can specialize it to some specific functionality like person is specialized to student so this type of relationship is represented with the help of generalization we call it generalization next let's take the example if we want to draw the use case diagram for the cellular system cellular system is the system where a user is making a call means we are using our cellular cellular mobile phones and we are making a call we are uh we are attend receiving the call we are making conference call and we are tracking some location or or someone's location so these type of functionality we will be defining through use case diagram so this is the boundary so this rectangle is representing the use case boundary means this is our system okay so this is our system and within this system we have multiple features so first feature that can be included with cellular system is make a call so make call is our first feature or we can say that the most required feature of any cellular system next is receiving a call yes we can receive a call we can schedule a call we can locate a user okay we can locate a user through the gps system included or we can say that integrated to our cellular system and we can generate the bill as well means after the usage we can generate a bill now what are the different actors involved with this system cellular system so first actor obviously is a user and next sector is a provider so provider is a service provider that is providing this the service to the user next we have the gps system so gps system will be used to locate a user so every mobile phone is having the gps system so they they must be interacting with some gps or geographical positioning system so here apart from these cases we may have some other cases but before that let's decide the association of these actors with the system so this is our boundary of the system and these are the features of the system so let's see the how the user is associated with the system so user is associated with make a call receive a call and schedule a call on the other side provider is associated with make a call receive a call and generate bill use case so these are the we can say that associated features of these two actors next we have the gps system as well so gps system is associated with the locate user use case okay so for locating a user we need the geographical positioning system now let's see other cases so other cases if we have if we want to locate a user so we need a network we need a network so this use case must be uh included in the in in our cellular system and we can say that this use case is dependency of locate user to locate a user we need a network connection but to make a call receive a call we we are not requiring any network okay but we may have the network but we are not requiring it but look to locate a user is a dependency with network this is having dependency with network right so let's let's consider some other cases so if you want to generate a bill so if a user or we can say that a monthly bill is generated for a user then to generate a bill we must analyze and we must check the usage of the user and the bill is generated according to the usage for a particular customer right so to check the usage is unnecessary so this use case must be included with the generate bill use case so this is the included feature necessary feature that will be used all the time we are generating a bill right so this is necessary feature that is included all the time while generating the bill next we need we we can have some other use cases that are extended to our features means our present use cases so while making a call we may have some additional call like i would like if i would like to make make a conference call or i may receive a conference call in that case i need some additional call feature or additional call use case that must be extended with our make call and receive call use case but this feature or this use case is not used always so we have the extend feature for this use case because they are not used all the time so they are extended features they are extending the functionality usual functionality we can say that and last notation we can present as the generalization so we can generalize the thing like here we have the provider so this provider can be of multiple type suppose we have two type or two sim cards for a cellular phone then provider can be generalized to two things so provider can be generalized to two or more actors so here we are taking the case of two vectors so first provider can be atl and another can be bsnl so here you can draw the functionality like this for first actor and for another actor okay so you can draw the generalized case of this actor but i am drawing here for the clear visibility but you can have this generalization structure with the provider actor over here so this will be the case if you want to draw the use case diagram to represent the cellular system so let's start the practical implementation how we can draw this diagram through some online available tool so for this i am going to use online.visualparadigm.com and this is the tool that that is available free of cost to any user but this is free for non-commercial use only if you want to use it for commercial purpose then you you must upgrade it to paid version okay so let's start so let me copy this url so this is our online available tool you can simply log in with your gmail account so this is the type of interface that you are going to get here you can create multiple things like infographics cards brochures etc gift greeting cards posters etc you can design a number of things but here we are going to create only uml diagrams so as we are working with the use case diagram so you can also browse for different templates but we will be creating a blank uml diagram so first of all drag drag a system tool means this is the rectangular box to represent a system and within the system you can rename it i am renaming it to cellular system you can change the color and background color of your system so this is our system next you can draw some use cases so you can simply create the use case like make a call and put it inside your system boundary so this is our system boundary with this rectangle and next we have receive a call this is our third use case and for these two use cases we also need the extended case and that was additional call okay that must be extended here so we are just creating the use cases for the for timing next after scheduling the call we have locate user and generate bill you can always copy paste one entity next is locate user and generate the bill okay so these use cases are complete to locate a user we need another use case that is your network okay and for generating the bill we need to include another use case that was check usage done now we need to add actors so for actors we are having this first actor as our user next is our provider and one more we need as the gps system okay so this is our gps system now how to form the relationship between them so for this we have these association include extend dependency and this is our generalization so you nee you can simply drag and drop these linkage tools to your diagram or you can simply have use these arrows so you can simply drag these arrows to make a connection and you can you will get the option to select the type of the arrow and this is done so association is complete next make one more association for receiving the call so here also i am making the connection it is also scheduling the call done so the users association are complete now let's move to the provider so provider is associated with making a call you can always reposition your associations next provider is also responsible for receiving a call and next the provider is generating the bill okay so these connections are done next gps system is responsible for locating the user so this is done now let's add the dependency include and extend stereotypes so here for checking so let's add the dependency first so from locating the user we need the network and this is our dependency so simply select the dashed arrow now for generating the bill we need to include the check usage and this is a type of include stereotype so simply selected it will be added automatically here this orange dot can be used to repos position your stereo type so this functionality is included over here now we need to extend this use case to our make call sorry i need to extend additional call to make also i need to start from here because arrow will be positioned directed accordingly so here this is extended functionality extended use case similarly for receiving the call we have the additional call we may have the conference call so this is also extended case so this is our complete diagram you can give a name to your use case like cellular system and you can always save your uh diagrams that you are preparing creating with this tool so you can create it to save it to your google drive or you can simply store it with your visual paradigm account so here i am using it with vp online means all the diagrams my projects will be saved with this tool only so this is saving this is taking some time so this is saved for my project this is now saved but you also have the option to export you can export this diagram this use case diagram as pdf as svg file as png file or as jpeg file so let's download or export this file you can add while downloading you can add the border to your diagram you can add shadow grid to your diagram so i am not adding border shadow or grid so i am simply using the export option to download the image so you need to select download and after clicking download the image is downloaded to your local drive so here is your diagram this okay and you can create any number of diagram with this tool for non-commercial use only so that's it for this video in next video we will learn the basics and notations for the class diagrams and why we use class diagrams and we will also design some useful class diagrams with this tool so till then bye and take care
Get free YouTube transcripts with timestamps, translation, and download options.
Transcript content is sourced from YouTube's auto-generated captions or AI transcription. All video content belongs to the original creators. Terms of Service · DMCA Contact