Chapter3

Chapter 3
UML
Presented by:
Dr.Fahad Alsheref

Outlines
• Unified Modeling Language
• Structure Diagrams
• Modeling Behavior

UML Diagrams
• UML recognizes 13 diagram types, although
most users of UML make do using three or four
types of diagram, depending on what they are
using it for.

UML class diagrams
5
 UML class diagram: a picture of the classes in an OO
system, their fields and methods, and connections
between the classes that interact or inherit from each
other details of how the classes interact with each other
algorithmic details; how a particular behavior is
implemented.

Diagram of one class
• class name in top of box
– write <<interface>> on top of interfaces' names
– use italics for an abstract class name
• attributes (optional)
– should include all fields of the object
• operations / methods (optional)
– may omit trivial (get/set) methods
• but don't omit any methods from an interface!
– should not include inherited methods
6

Class attributes
• attributes (fields, instance variables)
– visibility name : type [count] = default_value
– visibility: + public
# protected
- private
~ package (default)
/ derived
– underline static attributes
– derived attribute: not stored, but can
be computed from other attribute values
– attribute example:
- balance : double = 0.00
7

Class operations / methods
• operations / methods
– visibility name (parameters) : return_type
– visibility: + public
# protected
- private
~ package (default)
– underline static methods
– parameter types listed as (name: type)
– omit return_type on constructors and
when return type is void
– method example:
+ distance(p1: Point, p2: Point): double
8

Comments
• represented as a folded note, attached to the
appropriate class/method/etc by a dashed line
9

Relationships btwn. classes
• generalization: an inheritance relationship
– inheritance between classes
– interface implementation
• association: a usage relationship
– dependency
– aggregation
– composition
10

Generalization relationships
• Generalization (Inheritance) Relationships
– Hierarchies Drawn Top-down With Arrows
Pointing Upward To Parent
– Line/Arrow Styles Differ, Based On Whether
Parent Is A(n):
• Class:
Solid Line, Black Arrow
• Abstract Class:
Solid Line, White Arrow
• Interface:
Dashed Line, White Arrow
– We Often Don't Draw Trivial / Obvious
Generalization Relationships, Such As Drawing
The Object Class As A Parent
11

Associational relationships
• Associational (Usage) Relationships
1. Multiplicity (How Many Are Used)
• *  0, 1, Or More
• 1  1 Exactly
• 2..4  Between 2 And 4, Inclusive
• 3..*  3 Or More
2. Name (What Relationship The Objects Have)
3. Navigability (Direction)
12

Multiplicity of associations
13
 one-to-one
 each student must carry exactly one ID card
 one-to-many
 one rectangle list can contain many rectangles

Class diagram example 2
15
DVD Movie VHS Movie Video Game
Rental Item
Rental Invoice
1..*
1
Customer
Checkout Screen
0..1
1
Simple
Association
Class
Abstract
Class
Simple
Aggregation
Generalization
Composition
Multiplicity

Class diagram example 3
16
StudentBody
+ main (args : String[])
+ toString() : String
1 100
Student
- firstName : String
- lastName : String
- homeAddress : Address
- schoolAddress : Address
+ toString() : String
- streetAddress : String
- city : String
- state : String
- zipCode : long
Address

Class design exercise
• Consider this Texas Hold 'em poker game system:
– 2 to 8 human or computer players
– Each player has a name and stack of chips
– Computer players have a difficulty setting: easy, medium,
hard
– Summary of each hand:
• Dealer collects ante from appropriate players, shuffles
the deck, and deals each player a hand of 2 cards from
the deck.
• A betting round occurs, followed by dealing 3 shared
cards from the deck.
• As shared cards are dealt, more betting rounds occur,
where each player can fold, check, or raise.
• At the end of a round, if more than one player is
remaining, players' hands are compared, and the best
hand wins the pot of all chips bet so far. 17

Class design exercise
– Draw a class diagram for this system. Include
relationships between classes (generalization and
associational).
18

UML Modeling Behavior
19
 Use Case: a picture of the classes in an OO system, their
fields and methods, and connections between the
classes that interact or inherit from each other details of
how the classes interact with each other algorithmic
details; how a particular behavior is implemented.

Use Cases
• The use case is a summary of scenarios for a
single task or goal.
• So What is the Use Case????
• The Use Case is Make Appointment.
• It is a use case for the medical clinic.

Use Cases
• The picture below is a Make Appointment use case for
the medical clinic.
• The actor is a Patient. The connection between actor and
use case is a communication association (or
communication for short).
Actors are stick figures. Use cases are ovals. Communications are lines that
link actors to use cases.

Use Case Components
• The use case has three components.
• The use case task referred to as the use case that
represents a feature needed in a software system.
• The actor(s) who trigger the use case to activate.
• The communication line to show how the actors
communicate with the use case.

Use Case Diagram - Use Case
• A major process performed by the system that
benefits an actor(s) in some way
• Models a dialogue between an actor and the system
• Represents the functionality provided by the system

Use Case
• Each use case in a use case diagram describes one
and only one function in which users interact with
the system
– May contain several “paths” that a user can take
while interacting with the system
– Each path is referred to as a scenario

Use Case
• Labelled using a descriptive verb-noun phrase
• Represented by an oval
Make
Appointment
Make
Appointment

Use Case - Actor
• Labelled using a descriptive noun or phrase
• Represented by a stick character

Use Case - Relationships
• Relationships
– Represent communication between actor and use
case
– Depicted by line or double-headed arrow line
– Also called association relationship
Make
Appointment

Use Case - Relationships
• Boundary
– A boundary rectangle is placed around the perimeter
of the system to show how the actors communicate
with the system.
Make
Appointment

Guidelines for Creating
Use-Case Diagrams
– Order messages from left to right, top to bottom
• Name actors and objects the same if they represent the
same idea
• Place the initiator of the scenario on the left of the
diagram
• Multiple objects of the same class: name each
• Only show return values when they are not obvious
• Justify messages near the arrowhead for improved
readability

Use-Case Diagram
A use case diagram is a collection of actors, use cases, and their communications.

State Machine
Software Design (UML)
• An object must be in some specific state at any given time
during its lifecycle.
• An object transitions from one state to another as the
result of some event that affects it.
• You may create a state diagram for any class,
collaboration, operation, or use case in a UML model .
• There can be only one start state in a state diagram, but
there may be many intermediate and final states.

Components of State Machines
• States—values of an object’s attributes at a point in
time
• Events—the cause of the change in values of the
object’s attributes
• Transitions—movement of an object from one state
to another
– May include a guard condition to flag that a condition is true and
allow the transition

State Machine
selecting
verifying
downloading
checking schedule
download course offerings
make a course selection
verify selection
check schedule
select another course
make a different selection
unscheduled
scheduled
sign schedule

Guidelines for Creating Behavioral State
Machines
• Use only for complex objects
• Draw the initial state in the upper left corner
• Draw the final state in the bottom right corner
• Use simple, but descriptive names for states
• Look out for “black holes” and “miracles”
• Ensure guard conditions are mutually exclusive
• Ensure transitions are associated with messages
and operations

Building a Behavioral State Machine
• Set the context
• Identify the states of the object
• Initial
• Final
• Stable states during its lifetime
• Lay out the diagram—use a left to right sequence
• Add the transitions
• Identify the triggers (events that cause the transition)
• Identify the actions which execute
• Identify the guard conditions
• Validate the model—ensure all states are reachable

UML Modeling Behavior
39
 Sequence Diagram: Sequence Diagram is a diagram that
depicts object interactions arranged in time sequence,
where the direction of time is down the page. The
objects, which exchange information, are shown at the
top of a vertical line or bar, known as the object’s
lifeline. An arrow between the lifelines of two objects
represents each message.

Sequence Diagram
An object in a sequence diagram is rendered
as a box with a dashed line descending from it.
The line is called the object lifeline, and it
represents the existence of an object over a
period of time.
an Order Line

Sequence Diagram
an Order Line a Stock Item
[check = “true”]
remove()
check()
Messages are rendered as horizontal
arrows being passed from object to
object as time advances down the
object lifelines. Conditions ( such as
[check = “true”] ) indicate when a
message gets passed.

Sequence Diagram
an Order Line a Stock Item
[check = “true”]
remove()
check()
Notice that the bottom arrow is different. The arrow
head is not solid, and there is no accompanying
message.
This arrow indicates a return from a previous
message, not a new message.

Sequence Diagram
an Order a Order Line
* prepare()
An iteration marker, such as * (as shown), or *[i
= 1..n] , indicates that a message will be
repeated as indicated.
Iteration
marker

Building Sequence Diagrams
• Set the context
• Identify actors and objects that interact in the use-case
scenario
• Set the lifeline for each object
• Add messages by drawing arrows
• Shows how they are passed from one object to
another
• Include any parameters in parentheses
• Obvious return values are excluded
• Add execution occurrence to each object’s lifeline
• Validate the sequence diagram
• Ensures that it depicts all of the steps in the process

Chapter3

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Chapter3

Similaire à Chapter3 (20)

Dernier

Dernier (20)

Chapter3

Notes de l'éditeur