UML Basic Behavioral Modeling Part I

1
UMLBasic Behavioral Modeling Part I
2
UML Birds Eye View

• Building Blocks
• Things abstractions, main concepts in a model
• Relationships tie the things together
• Diagrams group interesting collections of
  things

3
Things in the UML

• Structural Things (7)
• static part of a model, conceptual or physical
  elements
• nouns of UML Models
• Behavioral Things (2)
• dynamic parts of models
• verb, representing behavior over time and space
• Grouping Things (1)
• Organizational parts of models, decomposition
  element
• Annotational Things (1)
• explanatory parts of models, comments about
  other elements

4
Relationships in the UML

• Dependency
• semantic relationship, a change in one element
  may affect the other element
• Association
• structural relationship that describes a set of
  links among objects
• Generalization/Specialization
• relationship in which objects of the
  specialized element (child) are substitutable for
  objects of the generalized element (parent)
• Realization
• semantic relationship between classifiers
  (class realizes an interface or collaboration
  realizes a use case)

5
Diagrams in the UML

• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Statechart diagram
• Activity diagram
• Component diagram
• Deployment diagram

6
Rules of the UML

• UML defines Rules for
• Names
• Scope
• Visibility
• Integrity
• Execution

7
Common Mehanism in the UML

• Specifications
• Adornments
• Common Division
• Extensibility Mechanisms

8
Behavioral Modeling

• Use Cases / Use Cases Diagrams
• Interactions / Interaction Diagrams
• State Diagrams
• Activity Diagrams

9
Use Cases

• Description of a set of sequences of actions,
  that a system performs to yield an observable
  result to an end-user
• Categories of interactions between the system to
  be built and external actors
• Identify high-level services provided by the
  system
• Specify the behavior of a system
• Popularized by Ivar Jacobson with Objectory
• Have been adopted by or have influenced many
  methods (eg. OMT, Fusion, Booch)

10
Use Cases (cont.)

• Can be applied to whole system as well as part of
  system such as a subsystem or a class
• Sources of integration tests and system tests
• May have variants specialized use cases or
  extension of use cases.
• Do not specify any implementation detail
• Main communication tool with end-user
• Each use case must have a name (simple or path
  name)

11
Actors

• Objects outside the system which play a
  particular role
• Represent the user(s) of the system
• Interact with the system through use cases
• May participate in more than one use case
• May or may not be represented as a class or
  object in the object model
• Also known as agents (Jacobson)

12
UML Use Case Graphical Representation
Storage depot system
Delivery
Collection
Status
Clerk
Storage
Use case
Actor
Manager
13
Why Modeling Use Cases

• Use Case model describes WHAT the system will do
  at a high-level
• User focus
• Capture requirements from user's perspective.
• Users are involved.
• Goal is to scope the project and give the
  application some structure
• Use Cases are the unit of estimation
• Uses Cases are smallest unit of delivery
• One way of estimating the percentage of
  requirements captured.
• Prioritizing use cases for "phased delivery"
  according to user's immediate needs.
• Better way of estimating the percentage of
  requirements completed during development

14
Benefits of use cases

• Good way to start identifying objects from
  scenarios.
• Test plan can be immediately generated based on
  use cases.
• Easier user validation.
• Helps technical writers in structuring the
  overall work on the users manuals at an early
  stage.
• Better traceability throughout the system
  development process.
• Quality of the software is improved by
  identifying the exception scenarios earlier in
  the development process.

15
Problems with use cases

• What is the right granularity
• What is a correct Use Case
• Explosion of different scenarios
• Focus on functions, with potential for
  functional decomposition
• Too often too informal

16
Use Cases and Scenarios

• Scenario is a specific sequence of actions
• Scenario is one instance of a Use Case
• Typically many scenarios correspond to one Use
  Case
• Example
• Use Case Hire Employee
• Scenarios
• Hire at Job Fair
• Hire through newspaper ad
• Hire from internal promotion
• Hire Temp

17
Use Cases and Collaborations

• Use Case captures WHAT the system does
• Use Cases do not specifies HOW the System does
  it
• Development effort is aimed at implementing the
  use cases by creating a society of classes
  working together
• These interacting classes are modeled using
  Collaborations
• A Collaboration is the realization of a Use Case
• A Collaboration represents how responsibilities
  are distributed across objects
• A Collaboration has a Static and a Dynamic
  aspect

18
Organizing Use Cases

• Relationships Generalization, Include (Use) and
  Extend
• Generalization
• Like for Classes
• Include
• Use Contains another complete use-case
• Extend
• Extends another use-case
• used for optional separate flow (exception)
• Beware
• Over-use of extends functional decomposition
• Rumbaugh says Use aggregation and Extend
  inheritance

19
Hints and Tips

• Each Use Case should represent a single,
  identifiable and reasonably atomic part of the
  behavior of the system
• Factors Common Behavior by pulling such behavior
  from other use cases that it includes
• Factors variants by pushing such behavior into
  other use cases that extend it
• Describe flow of vents clearly enough for anyone
  to easily understand it
• Each Use Case is described by a number of
  scenarios that specify the normal and variants

20
Use Case Diagrams

• system is represented by a large rectangle
• uses cases are represented as ellipses within the
  system rectangle
• actors are represented as stick figure outside
  the system
• an arrow connects the initiating actor to the use
  case (ending at the use case)
• other participating actors are joined by arrows
  terminating at the actor

21
Banking System Use Case Diagram
Cash Dispenser
open_account
withdraw_cash
Customer
Clerk
clear_checks
loan_application
Manager
get_report
Loan Officer
22
Use Case Identification Steps

• Determine the boundary of the system
• consider system as a single black box object
• Identify who is going to be using the system
  directly - e.g. hitting keys on the keyboard.
  These are the Actors
• start by considering physical object
• an individual object may play several roles
• Choose One of these Actors and determine the
  fundamental ways in which each actor uses the
  system
• each of these is a use case
• must be enumerable
• for each of those Use Cases decide on the most
  usual course when that Actor is using the system.
  What normally happens. This is the basic course

23
Use Case Identification Steps (2)

• Describe it as "Actor does something, system
  does something. Actor does something, system does
  something." but keep it at a high level.
• do not mention any GUI specifics
• only describe things that the system does that
  the actor would be aware of and conversely you
  only describe what the actor does that the system
  would be aware of.
• do not worry about the alternate paths (extends)
  or common courses (uses) - Yet -
• Review each Use Case descriptions against the
  descriptions of the other Use Cases.
• Once basic course is OK, consider the alternates
  and add those as extending use cases.

24
Use Case Identification Steps (3)

• Good way of getting started with Use Case
  modelling.
• Once started and comfortable with this process,
  next step
• understand the trade-offs that can be made
• simplicity versus "completeness"
• putting too much in is the most common mistake.

25
Use Case Textual Descriptions

• a clerk requests the system to create a new
  account

OPEN_ACCOUNT
WITHDRAW_CASH

• a customer requests the system to withdraw a
  specified amount of money from a specified account

• a clerk instructs the system to update all
  accounts according to specified transactions
  including checks

CLEAR_CHECKS
LOAN_APPLICATION

• a customer files a loan application

GET_REPORT

• a manager or loan officer requests a report of
  the days transactions from the system

26
Use Cases Diagram Hint and Tips

• Put all the Use Cases that describe one aspect
  of the system together
• Contains only those use cases and actors
  essential to understanding that aspect
• Diagram should be named to communicate its
  purpose
• Minimize crossing lines
• Dont draw too many use cases or too many
  relationships in one diagram

27
Modeling Exercices

• Develop the Use Cases for a Telephone Catalog
  System
• Develop the Use Cases for a Point Of Sales
  System
• grocery store requires a computer system to
  control the checkout points at which customers
  pay for the items they have selected. Using the
  bar code the checkout controller determine the
  price, name, number in stocks, sell-by-date (if
  applicable)
• Develop the Use Cases for a Access Control
  System
• System maintains the security and access t a
  number of doors inside or into a building. Doors
  are linked to keypads and card reader. All doors
  are connected to a central controlling unit
• Develop the Use Cases for a Course Scheduling
  System

28
Modeling Exercices

• Develop the Use Cases for a Library System
• supports library
• library lends books and magazines to borrowers
  who are registered in the system, as are books
  and magazines
• library buys new titles, eventually in multiple
  copies
• old books and magazines are removed when out of
  date.
• borrower can reserve a book or magazine not
  currently available

29
Detail Use Cases

• Start with a short, step-by-step description of
  the use-case flow of events, and gradually make
  it more detailed.
• Describe how the use case start and what is the
  signal that activates the use case.
• Describe how the use case terminate
• Describe what will reside inside the system, and
  what will reside outside the system.
• Describe the interaction between use case and
  actors.
• Describe how the use case exchange data with an
  actor.

30
Use Case Details

• Name
• The name of the use case.
• Brief Description
• A brief description of the role and purpose of
  the use case.
• Flow of Events
• A textual description of what the system does in
  regard to the use case. Understandable by the
  customer. Include the main flow of events as well
  as the alternate flow of events
• Special Requirements
• A textual description that collects all
  requirements, such as non-functional
  requirements, on the use case, that are not
  considered in the use-case model, but that need
  to be taken care of during design or
  implementation.

31
Use Case Details

• Preconditions
• A textual description that defines the state of
  the system prior to the use case may being
  performed.
• Postconditions
• A textual description that defines a list of
  possible states the system can be in immediately
  after a use case has finished.
• Extension points
• A list of locations within the flow of events of
  the use case at which additional behavior can be
  inserted using the extend-relationship.
• Relationships
• The relationships, such as communicates-associatio
  ns, include-, generalization-, and
  extend-relationships, in which the use case
  participates.

32
Use Case Details - Example

• Name
• Register for Courses
• Description
• This use case is started by the actor student. It
  provides the capability for the student to manage
  his registration to a course for a semester, and
  to have the billing information sent to the
  Billing Office.
• Main Flow of Events
• The student enters his Id.
• The system verifies the student Id, and prompt
  the student to select the current or a future
  semester.
• The student selects the semester.
• The system prompts the student to select the
  desired activity (create a registration, review a
  registration, change a registration).
• Once completed the student indicates that the
  activity is completed.
• The system acknowledge and displays the result of
  the activity.
• The system sends the billing information to the
  billing system for processing.

33
Use Case Details Example (cont.)

• Alternative Flow of Events
• 1- If an invalid Id is entered, the system will
  not allow access to the registration system and
  displays an error message to the student.
• Special Requirements
• The student should be able to access the system
  through the web. It should take less than 30
  seconds to display the web page. A student can
  register to a maximum of 5 courses per semester.
• Pre-Conditions
• The system is operational.
• Post-Conditions
• The student information has been updated. His
  bill is sent.
• Extension Points
• None
• Relationships
• None