Scribd Logo
Upload

Welcome to Scribd!

  • 340 views

    Use Case Theory

    Uploaded by

    rabinoss
    The document discusses use case diagrams which are used during the analysis phase of a project to identify and partition system functionality. It describes the key components of a use case diagram including actors, use cases, and the relationships between them using associations, includes, generalization, and extends links. Actors represent roles that users play, use cases describe system behavior, and examples of relationships are provided. The purpose of use case diagrams is to specify users' high-level goals for a system in a simple and clarified manner.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd

    Use Case Theory

    Uploaded by

    rabinoss
    340 views3 pages
    The document discusses use case diagrams which are used during the analysis phase of a project to identify and partition system functionality. It describes the key components of a use case diagram including actors, use cases, and the relationships between them using associations, includes, generalization, and extends links. Actors represent roles that users play, use cases describe system behavior, and examples of relationships are provided. The purpose of use case diagrams is to specify users' high-level goals for a system in a simple and clarified manner.

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses use case diagrams which are used during the analysis phase of a project to identify and partition system functionality. It describes the key components of a use case diagram including actors, use cases, and the relationships between them using associations, includes, generalization, and extends links. Actors represent roles that users play, use cases describe system behavior, and examples of relationships are provided. The purpose of use case diagrams is to specify users' high-level goals for a system in a simple and clarified manner.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    340 views3 pages

    Use Case Theory

    Uploaded by

    rabinoss
    The document discusses use case diagrams which are used during the analysis phase of a project to identify and partition system functionality. It describes the key components of a use case diagram including actors, use cases, and the relationships between them using associations, includes, generalization, and extends links. Actors represent roles that users play, use cases describe system behavior, and examples of relationships are provided. The purpose of use case diagrams is to specify users' high-level goals for a system in a simple and clarified manner.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 3

    the use case diagram is the first that designers will work with when starting a project.

      This diagram
    allows for the specification of high level user goals that the system must carry out.  These goals are not
    necessarily tasks or actions, but can be more general required functionality of the system..

    , a use case is made up of a set of scenarios.  Each scenario is a sequence of steps that encompass an
    interaction between a user and a system. 

    Use cases are used during the analysis phase of a project to identify and partition system
    functionality. They separate the system into actors and use cases.
    Actors represent roles that can are played by users of the system. Those users can be humans,
    other computers, pieces of hardware, or even other software systems.
    Use cases describe the behavior of the system

    Actor

    The use case diagram allows a designer to graphically show these use cases and the actors that use
    them.  An actor is a role that a user plays in the system.  It is important to distinguish between a user and
    an actor (better thought of as a role).  A user of the system may play several different roles through the
    course of his, her or its job (since an actor may be another system).  Examples of actors are salesperson,
    manager, support person, and web store system.  It is possible that the same person may be a sales
    person and also provide support.  When creating a use case model, we are not concerned with the
    individuals, only the roles that they play.

    Associations

    On a use case diagram, associations are drawn between actors and use cases to show that an actor
    carries out a use case.  A use case can be carried out by many actors and an actor may carry out many
    use cases.

    In the above diagram, the actors are shown as the green stick figure shapes on the left, the use cases are
    the blue ellipses, and the associations between them are represented by the connecting lines.  The
    developer and the stakeholder both are responsible for specifying the system roles, but only the
    developer creates the model.

    Includes
    Use cases can also be related to each other with three different links.  The diagram below shows the use
    of the includes link.  Both invoice purchase and online purchase include the scenarios defined by
    purchase valuation.  In general, the includes link is to avoid repetition of scenarios in multiple use cases.

    Generalization

    When a use case describes a variation on another use case, use a generalization link.  In the example
    below, the use case limit exceeded describes a situation in which the usual scenario of online purchase is
    not performed.  Use cases that generalize another use case should only specify an alternative, even
    exceptional, scenario to the use case being generalized.  The overall goal of the use cases should be the
    same.

    Extends

    In some instances you want to describe a variation on behaviour in a more controlled form.  In such
    instances you can define extension points in the extended use case.  In the example below, search by
    name is said to extend search at the name extension point.  The extends link is more controlled than the
    generalization link in that functionality can only be added at the extension points.
    Putting it all Together

    When starting a use case model, it is very important to keep it simple.  Often it is easiest to first determine
    the actors of the system, and then flush out the use cases that they perform. 

    a use case represents a goal of a user, not an atomic programming operation.  Your use case design
    should be simple and help to clarify the user's goals and expectations for the system.

    You might also like