Previous Next Methods Allocation  
4.43 Elementary Method "Use Case Modeling" (UCM)  

  4.43 Elementarmethode "Use-Case-Modellierung" (UCM)

Contents  
  • 1 Identification/Definition of the Method
  • 2 Brief Characteristic of the Method
  • 3 Limits of the Methods Application
  • 4 Specification of the Methods Allocation
  • 5 Interfaces
  • 6 Further Literature
  • 7 Functional Tool Requirements
  • Links to the V-Model Mailinglist
  • 1 Identification/Definition of the Method

    /Jacobson, 1992/

    2 Brief Characteristic of the Method

    Objective and Purpose

    The objective of this method is to collect and represent functional requirements with regard to a system from the point of view of external actors. The requirements must be described in form of Use Cases. A Use Case can be realized in a set of scenarios. External actors (e. g. staff members, project manager or administrator) represent roles that might be taken over by actual persons, machines, computer tasks or other systems.

    A Use Case is initiated by an actor and must be described by means of the dialogues or interactions "required" to handle a task between these actors and the system. The interactions can be specified by a sequence of actions and events started by the initiating actor, the system or other actors. Only such actions or events must be specified that can be recognized from the actors point of view, not, however, details describing how the system has to work internally.

    Altogether, the Use Cases specified for a system represent a set of user-oriented functional system requirements. In order to be complete it should be tried to specify all detected Use Cases in this form.

    Means of Representation

    The method was introduced Ivar Jacobson et al. in the field of object-oriented system development and is part of the complex method "Object-Oriented Software Engineering (OOSE)" /Jacobson, 1992/.

    The method is intended for the description of Use Cases in text form. First approaches for a formalized description are discussed by Jacobson in /Jacobson, 1995b/. In addition, the defined Use Cases and their relationships to actors are graphically represented and listed in overview diagrams. Symbols for the representation of the Use Cases, the actors and their relationships are available. It is possible to represent relationships between Use Cases and actors as well as relationships between Use Cases among each other.

    Based on the definition introduced by Jacobson, other authors also discuss this method in slightly different versions. Its usefulness for the software development process is recognized by most authors and the path for a shared understanding seems clear /Jacobson, 1995a/. By means of the cooperation of Booch and Rumbaugh with Jacobson, the method has also been integrated into /Booch, 1997/.

    Operational Sequence

    For practical reasons, the Use Case modeling is realized with the following steps:

    The defined actors, the defined use cases and their relationship have to be represented in overview diagrams.

    3 Limits of the Methods Application

    - not applicable -

    4 Specification of the Methods Allocation

    No. Activity Description
    4.1 SD1.1 - Recording of Actual Status and Analysis With the help of this method, operation and use of the old system can be analysed, collected and documented by external actors.

    The method covers operation and use of the system for subproduct User Requirements.Actual Status and Current Analysis.

    4.2 SD1.2 - Description of Application System With the help of this method requirements to operation and use of the system can be analysed and defined by external actors within the scope of the preliminary system description.

    The method covers subproduct User Requirements.Preliminary System Description.

    4.3 SD1.4 - Definition of Marginal Conditions With the help of this method the requirements to operation and use of the system resulting from technical, organizational and other marginal conditions can be specified by external actors.

    The method covers subproduct User Requirements.Marginal Conditions from the point of view of the operation and use of the system.

    4.4 SD1.5 - User-Level System Structure With the help of this method the functional requirements to the system can be analysed and defined by various actors from the point of view of the operation and use of the system.

    The method covers subproduct User Requirements.Utilization.

    5 Interfaces

    No. Interface Observation Information in Annex 1
    5.1 UCM-COM The functional requirements defined with method UCM have to be converted for the definition of the class and object structures in method COM. With their functional requirements, the defined Use Cases represent a basis for the determination of classes and objects, for the allocation of functionality to classes and for the interface design.  
    5.2 UCM-STMO The Use Cases defined by means of method UCM can be used as information base when modeling state models.  
    5.3 UCM-IAM The Use Cases defined with method UCM can be substantiated with method IAM in form of sequence diagrams or collaboration graphs.  

    6 Further Literature

    /Booch, 1997/ Unified Modeling Language, Version 1.0
    /Jacobson, 1995a/ Modeling With Use Cases - A growing consensus on use cases)
    /Jacobson, 1995b/ Modeling with Use Cases - Formalizing use-case modeling
    /Jacobson, 1992/ Object-Oriented Software Engineering - A Use Case Driven Approach

    7 Functional Tool Requirements

    SSD26 - Supporting Use Case Modeling

    Links to the V-Model Mailinglist

    Mail 0200 - Re: Methodenzuordnung fuer UML (200)

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster