Object-oriented modelingModeling the functions and

dynamics of the systemUse case diagram

Karolina Muszyńska

Based on: http://www.csun.edu/~dn58412/IS431/IS431_SP13.html G. Schneider , J.P. Winters „Stosowanie przypadków użycia” S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu

SI”

Why Object Modeling? Genesis of UML UML diagrams Use Case Diagrams From business tasks to Use Cases

2

Object Modeling

Object modeling is a technique for identifying objects within the systems environment and the relationships between those objects.

Object-oriented analysis (OOA) techniques are used to (1) study existing objects to see if they can be reused or adapted for new uses, and (2) define new or modified objects that will be combined with existing objects into a useful business computing application.

The Unified Modeling Language (UML) is a set of modeling conventions (notations) to specify or describe a software system in terms of objects.

3

Object Modeling

Benefits:◦ Break a complex system into manageable

components◦ Create reusable components can be plugged

into other systems or use them as starting points for other projects

◦ “Object-think” is more realistic !!!

4

Object Modeling

Methodological storm in object-oriented solutions (1989-94)◦ over 50 various object-oriented methods/solutions

Unified Modeling Language (UML)◦ Third generation OO method◦ An attempt to combine advantages of previous

methods Basis for the UML standard

◦ Object Modeling Technique (J. Rumbaugh) – UML diagrams notation, analysis and design

◦ Object Oriented Analysis and Design (G. Booch) – analysis and design

◦ Object Oriented Software Engineering (I. Jacobson) – business modeling, use cases

5

Genesis of UML

6

UML Diagrams

Structure diagrams.  A type of diagram that depicts the elements of a specification that are irrespective of time.  This includes class, object, package, composite structure diagrams and implementation diagrams: component and deployment diagrams.

Behavior diagrams.  A type of diagram that depicts behavioral features of a system or business process.  This includes activity, state machine, and use case diagrams as well as the four interaction diagrams.

Interaction diagrams.  A subset of behavior diagrams which emphasize object interactions.  This includes sequence, communication, interaction overview, and timing diagrams.

7

UML Diagrams

Modeling the functions of the system (with a use case diagram).

Modeling the objects within the scope of the system and their relationships (with class and object diagrams for each use case, and then for the integrated system).

Modeling the interactions between objects to complete a function/use case (with a sequence diagram and activity diagram for each use case).

Modeling the behavior / logic of the objects (with a statechart diagram for each complex class).

8

Most common UML Diagrams

9

UML Diagrams

STATECHART DIAGRAM FOR OBJECT “Order”

Enter New Customer

Create New Order

:customer :order

Create Order

SHIP ORDERCREATE ORDER

ORDER

CUSTOMER

SHIPMENT

USE CASE DIAGRAM CLASS DIAGRAM FOR USE CASE

“Create New Order”

SEQUENCE DIAGRAM

FOR USE CASE “Create

New Order”

Order Clerk

Order Clerk

:shipment

Create Shipment

Use case modeling is the process of modeling a system’s functions in terms of business events, who initiated the events, and how the system responds to the events.

A use case is a complete sequence of related actions (a scenario), both automated and manual, for the purpose of completing a business function: What the system must do.

An actor represents an external entity that needs to interact with the system to exchange information. An actor is a user, a role, which could be an external system as well as a person.

A temporal event is a system event that is triggered by time. (The actor of a temporal event use case is time.)

10

Use Case Modeling

Use Case Diagram is a functional description (use cases, actors) of the entire system: functions being supported by the system

Use Case Diagram does NOT indicate data flows or flows of information in and out the system (they are identified later in interaction diagrams)

11

USE CASE DIAGRAM

An extension use case extends the functionality of an original use case to add new behaviors or actions to the basic course. An extension use case can only be invoked by the use case it is extending.

An abstract use case contains typical course steps that were common to two or more original use cases. An abstract use case reduces redundancy and promotes reuse.

12

Extension and Abstract Use Cases

“Class registration” is the basic course of actions.

On special occasions, “Registration for special classes” and/or “Insufficient prerequisites” will be invoked.

Special cases add new data/behaviors to the normal case.

13

Extension Use Cases(“extend” relationship)

<<extend>> <<extend>>

Class registration

Registration for special classes

Insufficient prerequisites

“Track sales & inventory” includes “Reorder Supplies” and “Generate reports”

14

Abstract Use Cases (“include” relationship)

<<include>>

<<include>>

Track sales & inventory

Reorder supplies

Generate reports

“Place order by telephone” or “Place order via webpage” are possible types of “Place order”

“Sales Representative” plays all roles of “Client”

15

Inheritance among Actors or Use Cases

Place order

Place order by telephone

Place order via webpage

Client

Prepare sales reportSales

Representative

CRUD (Create, Read, Update, Delete) type use cases are used when application is meant to store data and one actor interacts with it (e.g. database maintenance, order management, etc.).

16

CRUD Use Cases vs. Individual Use Cases

Place order

Check order status

Cancel order

Client

Administer warehouse state DataBase

Administrator

Salesman

Each use case should include documentation in the form of scenarios

Scenario is a sequence of actions documenting a behavior

Each use case should have at least the main scenario but it is preferable to include the alternative scenarios as well

Both main and alternative scenarios precisely describe the full functionality represented by a use case

Additional important elements of the use case documentation include: pre-conditions and post-conditions

17

Use Case Documentation

Identify actors (look at the sources and destinations of major inputs and outputs)

Identify use cases (major system functions)

Identify the system boundary

Identify associations between actors and use cases

Identify additional associations between use cases (“extend”, “include”)

Identify inheritance relationships among use cases and actors

18

Building a Use Case Diagram

From business tasks to Use Cases

20

Business task description

21

Use case diagram

1. Service personnel selects 'Make repair reservation‘2. System displays 'repair reservation' form3. Service personnel selects client search 4. System displays list of clients5. Service personnel chooses a client6. System inserts the client's data into the 'repair

reservation' form7. Service personnel selects repairs search 8. Include: Display repair types9. Service personnel selects the repair type10. System inserts the repair's data together with the cost

to the 'repair reservation' form 11. Service personnel selects 'make repair reservation‘12. System displays confirmation

22

„Make repair reservation” use case specification

before point 5. extend: Add client

23

„Make repair reservation” use case extension point

„Add client” use case specification

1. System displays 'add client' form2. Service personnel inserts client's data (name, address,

phone number, e-mail address)3. Service personnel selects 'add client‘4. System displays confirmation

24

Rent-a-Car case study Possible business tasks:

Rent a car

Take back the rented car

Prepare cars for rental

Make a reservation for a car

Buy a car

Sell a car

…

25

„Rent a car” business task

Business steps:

Identifying the type of car and rental time frame the client is interested in

Identifying the client

Preparing the rental contract

Signing the contract and informing garage about new rental