UML Diagrams (Unified Modeling Language)

1
UML Diagrams (Unified Modeling
Language)
2
UML Diagram Introduction

• Graphical notations are useful and
  straight-forward in displaying information about
  a system design.
• Three gurus Booch, Rumbaugh, and Jacobson
  developed the UML diagrams

3
UML

• Models various aspects of software development
  for OO systems
• Includes several types of diagrams
• Class
• Use Case
• Collaboration
• Sequence
• State
• Activity

4
Class Diagrams (are static)

• Are one of the most significant diagram of the
  UML diagrams used by software developers
• Are used to create logical models of the
  computer-based systems
• Show data members, methods, and the static
  relationships between the classes that are used
  to build the system. The relationships are also
  called associations

5
Basic UML Class and Object Diagram
Person Explanations Class Name
-firstName -lastName -age Private Data Members (named property of a class usually a noun) (- symbol)
Person() Person( firstName, lastName, age) getFirstName()String setFirstName(firstNameString) void getLastName()String setLastName(lastNameString) void getAge() int setAge(ageint) void anyMethod()void getNumberofObjects()int Constructors default and non-default Public Methods (symbol) (usually a verb) Protected Methods ( symbol) Static Methods ( symbol and underlined)
6
Class Diagrams - Data Types and Parameters

• Sometimes the data type of attributes and
  parameters, and return types are not shown on the
  class diagram.
• If you see just the aMethodName(), dont assume
  that there is no parameters for the method.
  Sometimes they are omitted to save space.

7
Class Diagram for Premiere Products Database -
Source Adamski and Pratt
8
Class Diagram with Constraints Source Pratt and
Adamski
9

• Class Diagram with a
• Generalization (super class) and a
• 2. Specialization (subclass) with a Constraint
• Source Pratt and Adamski

10
Building a Specification Model

• The OO way of modeling reality does not try to
  organize all of reality
• We usually try to model only the relevant
  features of a specific application domain
• select a manageable domain
• One way of bounding the domain is to use Use
  Cases
• The main purpose of use case modeling is to
  understand the external behavior of the system.
  The later stages will be easier if up-front
  requirements are clear and unambiguous

11
One of the values of use cases is that they ease
the discussions between stakeholders and
analysts/developers. They are usually written
using business terms known to the majority of the
stakeholders
12
Use Cases

• Uses cases capture the functional requirements
  and the business-value propositions of a proposed
  system -along with its high-level processes
  needed to achieve these specific value
  propositions
• A used case is a generic description of an entire
  transaction involving several objects (Lee and
  Tepfenhart)

13
Building a Specification Model

• A use case
• Specifies a sequence of actions, including
  variants, that a system performs and that yields
  an observable result of value to an actor
  (Jacobson, Booch, Rumbaugh)
• Is a description of all the possible sequences of
  interactions among the system and one or more
  actors in response to some initial stimulus by
  one of the actors (Rumbaugh)
• Is a collection of possible sequences of
  interactions between the system under discussion
  and its external actors, related to a particular
  goal (Cockburn)

14
Use Cases

• Uses cases are concerned with the actors and the
  sequences of interactions between them
• Some important concepts include
• The goal - the business value to the user(s)
• The system - the application with all the
  hardware that will be used by the users
• An actor external entity that interacts with
  the system -represented by a labeled stick
  figures
• Use case describes an interaction that achieves
  a goal for an actor
• Use-case bundle a collection of used cases that
  are highly correlated with some activity or
  organizing business element

15
Use Cases

• Programmers use Use Cases to develop test plans
• The Goal
• use cases describe in a formal way how a computer
  system works from an external view
• to capture a scenario that completes to some
  point the business value of the users view
• To model the system functional requirements
• The System
• Usually viewed as a black-box system -the user
  cannot see the system inner workings. The user
  verifies that the system behaves the way it is
  suppose to no matter how it is built.

16
Use Cases Information Captured

• The Actors
• Uses cases divide the world into two parts the
  system and the users (actors)
• Actors are a way of classifying system users who
  share a set of common interactions to achieve a
  goal
• An actor represents an external entity that can
  initiate actions or receive requests from the
  system
• A specific user is an instance of an actor
• The set of requests/responses from/to the actors
  represents the system boundaries

17
Use Cases

• Use Case and Scenario
• A use case describes a system in terms of
  sequences of interactions between various actors
  and the system
• A scenario is a short narrative that outlines a
  sequence of requests and responses between a user
  and the system what happens next
• A scenario describes how a user will use the
  system to achieve a goal
• A use case is the generalized form of a family of
  scenarios
• A scenario is a specific instance of a use case

18
Use Cases

• The Use Case describes
• The pre-conditions that must exist for the used
  case to be successfully invoked
• The post-conditions that define the state of the
  system after the use case is concluded
• Detailed business logic that is performed
  (non-technology-dependent)
• Business exceptions that can occur
• required data not location, computations
  aborted
• Business constraints that apply to the system
  when reacting to a specific user request
  resource allocation not available

19
Use Cases

• To effectively capture the functional aspects of
  a system the description of the system must be
  kept at a consistent level of abstraction
• To successfully develop use cases we must know
  the dimension of the functional description we
  are trying to capture
• These dimensions include
• High-level and low-level
• Primary and secondary
• Essential and concrete

20
Use Cases

• High-level functional descriptions
• Provide general and brief descriptions of the
  essence of the business values provided by the
  system- No concern of how to achieve the business
  values
• Low-level functional descriptions
• Provide details showing the exact order of
  activities, tasks, or alternatives

21
Use Cases

• Primary functions
• Describe the essential functionality provided to
  the user the reason the system exists
• Secondary functions
• Deal with rare and exceptional cases necessary
  to deliver a robust system
• Essential functions
• Describe business solutions that are independent
  of implementation (Hardware and software
  -black-box implementation is done in total
  ignorance of how the object was constructed)
• Concrete functions
• Describe use cases that are design dependent
  (clear-box)

22
High-level, primary, essential use case diagram
Course Registration System
23
Template for Documenting Use Cases Textual
Description
Description A one or two sentence description of the use case a descriptive name
Actors Identifies the actors participating in the use case
Includes Identifies the use cases included in it
Extends Identifies the use cases that it may extend
Pre-Conditions Identifies the conditions that must be met to invoke this use case

24
Template for Documenting Use Cases Textual
Description
Details Identifies the details of the use case
Post-Conditions Identifies the conditions that are assured to hold at the conclusion of the use case
Exceptions Identifies any exceptions that might arise in the execution of this use case
Constraints Identifies any constraints that might apply
Variants Identifies any variations that might hold for the use case
Comments Provides any additional info that Might be important in this use case
25
The Vending Machine Class Diagram
1 buys
Customer money insertCoint() receiveProduct()
Merchant money product removeMoney() addProduct(
)
Coin Box money requestProduct() rejectCoin()
1 owns 1
Coin

1
Bad Coin
1
1
supplier
Dispenser product dispenseProduct() reject
Request()
Apple Juice
1 0..
Product
1
1
26
The Vending Machine System Use Case
Diagram
Add product
Remove Coins
Receive product
Request product
ltltextendsgtgt
A link that displays exactly how an optional
actor interact with an exception
Rejected Coin
27
Sequence Diagrams

• Model system behavior (methods) for use cases by
  showing the necessary class interactions. Shows
  the time ordering of a sequence of method calls.
• They show how the user (actor) communicates with
  the system to complete the job.
• The events modeled in the diagram are external
  events started by an actor.
• The actors and objects are placed horizontally
  across the top of the diagram.
• The vertical lines called a lifeline is
  attached to each actor or object. The lifeline
  becomes an activation box to depict the live
  activation period of the object or actor.
• A message is represented using an arrow labeled
  with a message. The message may hold an argument
  list and a return type.
• Dashed arrows may be used to indicate object
  flow. If an objects ends during the execution of
  the use case an X is placed at the bottom of its
  lifeline.

28
The Vending Machine System Sequence
Diagram
Dispenser
Coin Box
insertCoin()
requestProduct()
rejectRequest()
rejectCoin()
Product
29
See the skeleton code to use for the Vending
Machine System sequence diagram Vending
Machine Sequence UML Diagram Skeleton
Code.doc Stored on the M drive in the UML
folder.
30
Collaboration Diagrams Show the message passing
structure of the system. The emphasis is on the
roles of the objects as they work together to
complete a system function. They can be used to
display parts of a design pattern and they are
helpful for verifying class diagrams
2. requestProduct
1. SendCoin
Coin Box
Dispenser
4. returnCoin
3. rejectRequest
Return coin collaboration diagram
31
Collaboration Diagrams Product delivery
collaboration diagram
2. e
1. SendCoin
2. requestProduct
Coin Box
3. deliverProduct
Dispenser
32
State Diagram Describes the behavior (method) of
a system, subsystem, or an individual object. The
system state is determined by the values assigned
to objects data members. A systems current
state is only changed by a new event.. State
diagrams display changes that affect the system
behavior or its object data members when an
external factor triggers an event..

Wait for Coin
insert coin
Return Coin
bad coin
Check Coin
good coin
Check Dispenser
no product
product available
Dispense Product
33
Activity Diagram Display the work flow of an
object. They are similar to state diagrams See
Activity Diagram.doc