Vous êtes sur la page 1sur 6

Use Cases & Class Diagrams

Agenda

1. Use Cases

2. Class Diagrams

1. Symbology

2. Basic Modeling

3. Intermediate Modeling

3. Why UML Use Cases?

4. Use Case

5. – A set of scenarios related by a common actor and a goal

6. – A description of sequences of actions performed by a given

7. system to produce a result for an actor

8. Use cases specify the expected behavior [what], and not the

9. exact method of making it happen [how]

10.Use cases are created based on identified functional

11.requirements but are not mapped one-to-one to requirements

12.Use cases once specified can be denoted using a clear and

13.precise visual modeling language such as UML

14.Use-case diagram

15.Shows services that expected from a system

16.Provides outsider view (customer)

17.Main ingredients:

1. use case service provided by system

2. actor agent using a system service (“beneficiary”)

Introduced in early phases of system analysis

Use Case Names

Use Case Names

– Simple Name
– Path Name

Package name :: Use case name

Actors

Actors

– Represent roles that humans, hardware devices, or external

systems play while interacting with a given system

– They are not part of the system and are situated outside of

the system boundary

– Actors may be both at input and output ends of a use case

Scenarios

– Specify behavior of use case by description, not modeling

• Examples include informal structured text, formal

structured text with conditions, and pseudo code

– Typically specifies:

• How and when the use case starts and ends

• Interaction with the actors and the exchange of objects

• Flow of events: main / typical (success), alternative

(success), and exceptional (failure) flows

Scenarios Example
Scenarios Example: Validate User

Main event flow:

Start: prompt for Username and Password (system)

Enter Username and Password via keypad (customer)

Commit to entry by pressing “Submit” (customer)

Check validity of Username and Password (system)

Acknowledge entry (system)

Exceptional flow of Events:

The customer can clear a Username/password any time

before committing, and enter a new username/password

The customer can cancel a transaction at any time

by pressing the “Cancel” button

Conditions and Quality Requirements

Entry and Exit Conditions

– Entry conditions describe the environment under which the

use case is invoked

– Exit conditions reflect the impact of the use case on the

environment through its execution

Quality Requirements

– Describe quality attributes in terms of a specific functionality

– For example, requires system response in < 30 seconds

Relationships

– Organize use cases by grouping them in packages as in the


organization of classes

– Generalization: The child use case exhibits a more specific

variation in behavior than as specified for its parent

– Include: Common behavior of more than one use case is

referenced as a separate instance to avoid repetition

– Extend: Implicit integration of the behavior of another use

case by declaring the extension points / events in the base

Constructing a use-case model

1. Identify actors

2. For Each actor

1. Identify required services (beneficiary)

2. Identify other services in which it takes part

Actors and classes

1. Actors are external to the system; classes are internal

2. However, often we need to represent information about an actor internally

Create a class for the actor

3. Services can be modeled as operations on such an “actor” class

Use of use-case models

1. Capturing functional requirements

2. Project planning

1. Identify “risky” or “politically important” use cases

2. Plan project accordingly

3. Total project duration should be at least the sum of the time needed to
develop the use cases

4. Use the use cases for generating system tests


3. Always do class modeling in parallel

1. Prevents a pure functional bias

4. A class diagram shows:

5. Classes

6. Attributes

7. Methods

8. Interfaces

9. Collaborations

10.Dependency, Generalization, Relationships

11.A class diagram is a STATIC view of system

Three Levels of Class Diagrams

1. Conceptual (Domain) Model

2. Analysis (Specification)

3. Implementation

Basic Class Diagrams

+ public

# protected

- private

~ package

/ derived

Class Scope (static)

Formats for boxes:


Visibility Attribute_Name [Multiplicity]:Type = Initial_Value {property-string}

Visibility Method_Name (Parameter_List) : Return-List {property-string}

Kind param_Name :type = default value

where kind = in, out , inout

Basic Class Diagrams

Basic Class Diagram (Example)

Basic Class Diagram (Example)