Scribd Logo
Upload

Welcome to Scribd!

  • 196 views

    Modeling Tool .: Aim: Prepare Use-Cases and Draw Use-Case Diagram Using Software

    Uploaded by

    02 - CM Ankita Adam
    The document provides information on use case diagrams and their components. It defines a use case diagram as capturing the system's functionality and requirements through actors and use cases. Actors represent entities that interact with the system, while use cases represent the system's services and functions. The document then outlines common notations used in use case diagrams, such as ovals to represent use cases and stick figures to represent actors. It also provides tips for drawing effective use case diagrams, such as keeping them simple and complete.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Modeling Tool .: Aim: Prepare Use-Cases and Draw Use-Case Diagram Using Software

    Uploaded by

    02 - CM Ankita Adam
    196 views18 pages
    The document provides information on use case diagrams and their components. It defines a use case diagram as capturing the system's functionality and requirements through actors and use cases. Actors represent entities that interact with the system, while use cases represent the system's services and functions. The document then outlines common notations used in use case diagrams, such as ovals to represent use cases and stick figures to represent actors. It also provides tips for drawing effective use case diagrams, such as keeping them simple and complete.

    Original Title

    practical 5 SEN

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document provides information on use case diagrams and their components. It defines a use case diagram as capturing the system's functionality and requirements through actors and use cases. Actors represent entities that interact with the system, while use cases represent the system's services and functions. The document then outlines common notations used in use case diagrams, such as ovals to represent use cases and stick figures to represent actors. It also provides tips for drawing effective use case diagrams, such as keeping them simple and complete.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    196 views18 pages

    Modeling Tool .: Aim: Prepare Use-Cases and Draw Use-Case Diagram Using Software

    Uploaded by

    02 - CM Ankita Adam
    The document provides information on use case diagrams and their components. It defines a use case diagram as capturing the system's functionality and requirements through actors and use cases. Actors represent entities that interact with the system, while use cases represent the system's services and functions. The document then outlines common notations used in use case diagrams, such as ovals to represent use cases and stick figures to represent actors. It also provides tips for drawing effective use case diagrams, such as keeping them simple and complete.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 18

    Aim : Prepare use-cases and draw use-case diagram using Software

    Modeling Tool .

    Use Case Diagram for College Management System

    Unified Modeling Language (UML) is a general purpose modelling language.


    The main aim of UML is to define a standard way to visualize the way a system
    has been designed. It is quite similar to blueprints used in other fields of
    engineering.
    UML is not a programming language, it is rather a visual language. We use
    UML diagrams to portray the behavior and structure of a system. UML helps
    software engineers, businessmen and system architects with modelling, design
    and analysis. The Object Management Group (OMG) adopted Unified Modelling
    Language as a standard in 1997. Its been managed by OMG ever since.
    International Organization for Standardization (ISO) published UML as an
    approved standard in 2005. UML has been revised over the years and is
    reviewed periodically.
    What is the Use Case Diagram?
    Use Case Diagram captures the system’s functionality and requirements by
    using actors and use cases. Use Cases model the services, tasks, function
    that a system needs to perform. Use cases represent high-level functionalities
    and how a user will handle the system. Use-cases are the core concepts of
    Unified Modelling language modeling.
    Why Use-Case diagram?
    A Use Case consists of use cases, persons, or various things that are
    invoking the features called as actors and the elements that are responsible
    for implementing the use cases. Use case diagrams capture the dynamic
    behaviour of a live system. It models how an external entity interacts with the
    system to make it work. Use case diagrams are responsible for visualizing the
    external things that interact with the part of the system.

    Use-case diagram notations


    Following are the common notations used in a use case diagram:

    Use-case:

    Use cases are used to represent high-level functionalities and how the user
    will handle the system. A use case represents a distinct functionality of a
    system, a component, a package, or a class. It is denoted by an oval shape
    with the name of a use case written inside the oval shape. The notation of a
    use case in UML is given below:

    Use-case diagram notations


    Following are the common notations used in a use case diagram:

    Use-case:

    Use cases are used to represent high-level functionalities and how the user
    will handle the system. A use case represents a distinct functionality of a
    system, a component, a package, or a class. It is denoted by an oval shape
    with the name of a use case written inside the oval shape. The notation of a
    use case in UML is given below:
    UML Use Case Notation

    Actor:

    It is used inside use case diagrams. The actor is an entity that interacts with
    the system. A user is the best example of an actor. An actor is an entity that
    initiates the use case from outside the scope of a use case. It can be any
    element that can trigger an interaction with the use case. One actor can be
    associated with multiple use cases in the system. The actor notation in UML is
    given below.

    How to draw a use-case diagram?


    To draw a use case diagram in UML first one need to analyse the entire
    system carefully. You have to find out every single function that is provided by
    the system. After all the functionalities of a system are found out, then these
    functionalities are converted into various use cases which will be used in the
    use case diagram.
    A use case is nothing but a core functionality of any working system. After
    organizing the use cases, we have to enlist the various actors or things that
    are going to interact with the system. These actors are responsible for
    invoking the functionality of a system. Actors can be a person or a thing. It can
    also be a private entity of a system. These actors must be relevant to the
    functionality or a system they are interacting with.

    After the actors and use cases are enlisted, then you have to explore the
    relationship of a particular actor with the use case or a system. One must
    identify the total number of ways an actor could interact with the system. A
    single actor can interact with multiple use cases at the same time, or it can
    interact with numerous use cases simultaneously.

    Following rules must be followed while drawing use-case for any system:

    1. The name of an actor or a use case must be meaningful and relevant to


    the system.
    2. Interaction of an actor with the use case must be defined clearly and in
    an understandable way.
    3. Annotations must be used wherever they are required.
    4. If a use case or an actor has multiple relationships, then only significant
    interactions must be displayed.

    Tips for drawing a use-case diagram


    1. A use case diagram should be as simple as possible.
    2. A use case diagram should be complete.
    3. A use case diagram should represent all interactions with the use case.
    4. If there are too many use cases or actors, then only the essential use
    cases should be represented.
    5. A use case diagram should describe at least a single module of a
    system.
    6. If the use case diagram is large, then it should be generalized.

    An example of a use-case diagram


    Following use case diagram represents the working of the student
    management system:
    Use Case Diagram
    What is a Use Case Diagram?
    A use case diagram is a dynamic or behavior diagram in UML. Use case diagrams model
    the functionality of a system using actors and use cases. Use cases are a set of actions,
    services, and functions that the system needs to perform. In this context, a "system" is
    something being developed or operated, such as a web site. The "actors" are people or
    entities operating under defined roles within the system.

    Why Make Use Case Diagrams?


    Use case diagrams are valuable for visualizing the functional requirements of a system
    that will translate into design choices and development priorities.

    They also help identify any internal or external factors that may influence the system and
    should be taken into consideration.
    They provide a good high level analysis from outside the system. Use case diagrams
    specify how the system interacts with actors without worrying about the details of how
    that functionality is implemented.
    Basic Use Case Diagram Symbols and Notations
    System
    Draw your system's boundaries using a rectangle that contains use cases. Place actors
    outside the system's boundaries.

    Use Case
    Draw use cases using ovals. Label the ovals with verbs that represent the system's
    functions.
    Actors
    Actors are the users of a system. When one system is the actor of another system, label
    the actor system with the actor stereotype.

    Relationships
    Illustrate relationships between an actor and a use case with a simple line. For
    relationships among use cases, use arrows labeled either "uses" or "extends." A "uses"
    relationship indicates that one use case is needed by another in order to perform a task.
    An "extends" relationship indicates alternative options under a certain use case.

    Tips for UML Use Case Diagrams


    When thinking of use cases, think of the end goal of a user. They don't want to "login"
    or "sign up." That's not a use case. The use case is more like "make a purchase."

    Actors don't have names. They're not "Bob." They represent the role of someone
    interacting with the system.
    Keep your names short and the size of your use cases consistent for a professional look.
    For a detailed implementation of a user's goal use a sequence diagram.
    Use Case Diagram Examples
    The best way to understand use case diagrams is to look at some examples of use case
    diagrams.
    Use Case Diagram Guidelines for
    Better Use Cases
    Updated on: 30 July 2021

    When it comes to analyzing the requirement of a system use case diagrams


    are second to none. They are visual and usually very easy to understand. The
    following use case diagram guidelines will help you to create better use
    cases that are appreciated by your clients and peers alike.

    A use case diagram mainly consists of actors, use cases and relationships.
    More complex larger diagrams can include systems and boundaries. We’ll
    discuss the use case diagram guidelines based on objects.
    It is important to remember that these are use case diagram guidelines and
    not rules. It’s alright to deviate if it improves the overall quality of the diagram.
    To get a deep understanding of use case diagrams, check out our use case
    diagram tutorial.

    Actors
     Give meaningful business relevant names for actors – For example,
    if your use case interacts with an outside organization it’s much better to
    name it with the function rather than the organization name. (Eg: Airline
    Company is better than PanAir)
     Primary actors should be to the left side of the diagram – This
    enables you to quickly highlight the important roles in the system.
     Actors model roles (not positions) – In a hotel both the front office
    executive and shift manager can make reservations. So something like
    “Reservation Agent” should be used for actor name to highlight the role.
     External systems are actors – If your use case is send-email and if
    interacts with the email management software then the software is an
    actor to that particular use case.
     Actors don’t interact with other actors – In case actors interact within
    a system you need to create a new use case diagram with the system in
    the previous diagram represented as an actor.
     Place inheriting actors below the parent actor – This is to make it
    more readable and to quickly highlight the use cases specific for that
    actor.
    Use Case Diagram Templates

    Use Cases
     Names begin with a verb – A use case models an action so the name
    should begin with a verb.
     Make the name descriptive – This is to give more information for
    others who are looking at the diagram. For example “Print Invoice” is
    better than “Print”.
     Highlight the logical order – For example, if you’re analyzing a bank
    customer typical use cases include open account, deposit and withdraw.
    Showing them in the logical order makes more sense.
     Place included use cases to the right of the invoking use case –
    This is done to improve readability and add clarity.
     Place inheriting use case below parent use case – Again this is done
    to improve the readability of the diagram.

    Relationships
     Arrow points to the base use case when using <<extend>>
     <<extend>> can have optional extension conditions
     Arrow points to the included use case when using <<include>>
     Both <<extend>> and <<include>> are shown as dashed arrows.
     Actor and use case relationship don’t show arrows.

    Check out the link to learn more about use case diagram relationship
    Systems / Packages
     Use them sparingly and only when necessary
     Give meaningful and descriptive names to these objects

    Association Between Actor and Use Case


    This one is straightforward and present in every use case diagram. Few things
    to note.

     An actor must be associated with at least one use case.


     An actor can be associated with multiple use cases.
     Multiple actors can be associated with a single use case.
    Generalization of an Actor
    Generalization of an actor means that one actor can inherit the role of the
    other actor. The descendant inherits all the use cases of the ancestor. The
    descendant has one or more use cases that are specific to that role. Let’s
    expand the previous use case diagram to show the generalization of an actor.
    Extend Relationship Between Two Use Cases
    Many people confuse the extend relationship in use cases. As the name
    implies it extends the base use case and adds more functionality to the
    system. Here are a few things to consider when using the <<extend>>
    relationship.

     The extending use case is dependent on the extended (base) use


    case. In the below diagram the “Calculate Bonus” use case doesn’t
    make much sense without the “Deposit Funds” use case.
     The extending use case is usually optional and can be triggered
    conditionally. In the diagram, you can see that the extending use case is
    triggered only for deposits over 10,000 or when the age is over 55.
     The extended (base) use case must be meaningful on its own. This
    means it should be independent and must not rely on the behavior of
    the extending use case.


     Although extending use case is optional most of the time it is not a
    must. An extending use case can have non-optional behavior as well.
    This mostly happens when your modeling complex behaviors.
     For example, in an accounting system, one use case might be “Add
    Account Ledger Entry”. This might have extending use cases “Add Tax
    Ledger Entry” and “Add Payment Ledger Entry”. These are not optional
    but depend on the account ledger entry. Also, they have their own
    specific behavior to be modeled as a separate use case.

    include Relationship Between Two Use Cases


    Include relationship show that the behavior of the included use case is part of
    the including (base) use case. The main reason for this is to reuse common
    actions across multiple use cases. In some situations, this is done to simplify
    complex behaviors. Few things to consider when using the <<include>>
    relationship.

     The base use case is incomplete without the included use case.
     The included use case is mandatory and not optional.

    Lest expand our banking system use case diagram to show include
    relationships as well.

    Lets expand our current example to show the <<extend>> relationship.

    Conclusion : Hence we have learned to Create Use Case Diagrams In


    Software Engineering.

    You might also like