Unified Modelling Language

The Unified Modeling Language
g g g

R. Akerkar

CIS 260 Software Engineering - I (R.
10:16:25 AM Akerkar) 1

A movie project plan
 One of the key artifacts in the RUP
framework is the project plan
plan.
 The project plan details the tasks, schedule,
cost, resources, milestones,
cost resources milestones and deliverables
needed to complete the project.
 Progress is tracked against the plan and
measured by work completed by milestones
reached and results delivered.
 The plan is conceived early in the project and
frequently updated throughout the lifecycle.

The Iterative Model graph of RUP
 The horizontal axis
represents time and
shows the dynamic
aspect of the process as
it is enacted, and it is
expressed in terms of
cycles, phases,
iterations, and
milestones.

 The vertical axis
represents the static
aspect of the p
p process:
how it is described in
terms of activities,
artifacts, workers and
workflows.


A movie project plan = a software
development project


A movie project plan = a software
development project
 In this figure, activities related to making a movie are substituted
for the RUP disciplines.
 Developing the screenplay is analogous to writing requirements,

 filming corresponds to implementation, and

 producing the movie is more or less like project management.

 Dividing the timeline into four p
g phases pputs the focus on different
aspects of the movie project at different times.
 We also see that the activities run in parallel, typically
exchanging information and work packages in a highly efficient,
cross-functional manner:
f
 just as the RUP.


The Essentials of RUP
 In all projects, it is important to explore what will
happen if any of these essentials is ignored.

 For example:
1. No vision? You may lose track of where you are going.
2. No plan? You will not be able to track progress.
3. No risk list? You may be focusing on the wrong issues
now.
4. No issues li ? With t accountability, th
N i list? Without t bilit these are th
the
roadblocks to success.
5. No architecture? You may be unable to handle
communication, synchronization,
communication synchronization and data access issues
as they arise.


The Essentials of RUP
6. No product (prototype)? Get started writing code; just
accumulating paperwork won’t get you very far; get
won t
something working in front of the customers.
7. No evaluation? Don’t keep your head in the sand. It is
important to face the truth How close are you really to your
truth.
deadline? To your goals in quality or budget?
8. No change requests? How do you keep track of these?
9. No user support? What happens when a user has a
question or can’t figure out how to use the product?


Next Step: Terminology
 Playing with Rational Rose
 To create three diagrams in Rational Rose,
 the use-case diagram,
 the sequence diagram, and
 the class diagram
diagram.
 Rational Rose is a program that allows you to build
models based on the Unified Modeling Language (UML).
 The
Th use-case didiagrams allow you t see all th scenarios and
ll to ll the i d
how the users act on them.
 The sequence diagrams allow you to elaborate on each of the
use cases by showing example objects and messages that
are passed between these objects.
 The class diagram describes the types of objects in the
program and how they are related to each other.
g y


Use Case
“A use case specifies the behavior of a system or a part of a
system, and i a description of a set of sequences of actions,
d is d i i f f f i
including variants, that a system performs to yield an observable
result of value to an actor.”
- The UML User Guide, [Booch,99]

“An actor is an idealization of an external person, process, or
An person process
thing interacting with a system, subsystem, or class. An actor
characterizes the interactions that outside users may have with
the system.”
h ”
- The UML Reference Manual, [Rumbaugh,99]


Use Case (Cont’d)

A use case is rendered as an ellipse
Register for Courses
in a use case diagram. A use case is
diagram
always labeled with its name.

10:16:25 AM Akerkar) 10

Use Case (Cont’d)

An actor is rendered as a stick
figure in a use case diagram.
diagram
Each actor participates in one or
more use cases.

Student

10:16:25 AM Akerkar) 11

Use Case (Cont’d)
Actors can participate in a generalization relation with other
actors.
actors

Student Person

10:16:25 AM Akerkar) 12

Use Case (Cont’d)

Actors may b connected to use cases
be d
only by associations.

Register for Courses

Student

10:16:25 AM Akerkar) 13

Use Case (Cont’d)
Here we have a Student interacting with the Registrar and the
Billing System via a “Register for Courses” use case.

Billing System

Student Register for Courses

Registrar

10:16:25 AM Akerkar) 14

Draw Use Case Diagram
 The diagram describes the functionality of the (simple)
Restaurant System.

 The Food Critic actor can Eat Food, Pay for Food, or
Drink Wine.
 Only the Chef Actor can Cook Food.

10:16:25 AM Akerkar) 15

Use Cases are represented
U C t d
by an oval and Actors are
stick figures.

The box defines the
boundaries of the Restaurant
System

10:16:25 AM Akerkar) 16

Actor and Use Case Diagram
g

• An actor is a user of a system in a
particular role.
An
A actor can b h
be human or an external
l
BookBorrower
system.

• A use case is a a task that an actor
needs to perform with the help of the
Borrow book system.
system

10:16:25 AM Akerkar) 17

Use Cases and Actors

• A scenario is an instance (example) of a use case
• A t i role, not an individual
Actor is l t i di id l
(e.g., librarian can have many roles)
• Actor must be a "beneficiary" of the use case
(e.g., not librarian who processes book when borrowed)
In UML the system boundary is the set of use cases.
UML, cases

10:16:25 AM Akerkar) 18

Use Cases for Borrowing Books
g

Borrow copy
of book

BookBorrower
Return copy
of book

Reserve
book
Extend
loan
10:16:25 AM Akerkar) 19

Case Study: Use Cases Drive the Development
Process

 A Process for Writing Use Cases
 Step 1: Identify Actors
 Step 2: Identify Use Cases
 Step 3: Prioritize Use Cases
 Step 4: Elaborate Use Cases
 Step 5: Create a Structured Use Case Model

10:16:25 AM Akerkar) 20

Step 1: Identify Actors
 The actors represent users and external systems
that will interact with the system under development.
development
 One way to identify actors is to list the specific users
that will use the system and then organize them into
y g
categories based on their role or the purpose they
have for using the system.

 Example:
 Consider th t k of fi di actors f a software
C id the task f finding t for ft
system which simulates a virtual mall. A virtual mall
connects buyers and merchants
merchants.
10:16:25 AM Akerkar) 21

Step 1: Identify Actors (Example)
 Potential actors are:
 Customer - A customer represents any
C t t t
person who uses the services of the virtual
mall.
mall
 Affiliate - An affiliate represents a person or
organization who is authorized to sell
merchandise at the virtual mall.
 Credit Bureau - A credit bureau represents
p
an external system used to verify the
creditworthiness of a customer.
10:16:25 AM Akerkar) 22

Step 2: Identify Use Cases
 This step may be performed simultaneously
with the previous step
step.
 Many development projects start with a high-
level list of desired features
features.
 For example, the feature list for a virtual mall
might include:
 1) list item for sale,
 2) browse items for sale,
)
 3) purchase an item.
 Each feature is a potential use case.

10:16:25 AM Akerkar) 23

Step 2: Identify Use Cases (Example)
 The use cases that emerge
from exploring how each actor
gets value from or provides
value to the system are:

 Browse I
B Inventory - Thi use
t This
case is used by a customer to
shop for items to purchase.
 Purchase an Item - This use
case is used by a customer to
purchase an item.
 Offer Item For Sale - This use
case is used by an affiliate to
make an item available for
purchase.

10:16:25 AM Akerkar) 24

Step 3: Prioritize Use Cases
 There are two reasons to prioritize use cases.
 First, h l determine what order th uses cases
Fi t it helps d t i h t d the
will be implemented.
 Implementing the highest priority use cases first reduces
the risk a high priority item won't make the schedule and
provides more time to insure the item is implemented
correctly.
correctly
 Second, a prioritized list of use cases helps
establish architecture.
 A system structure that is organized around high priority
use cases tends to be more stable over time.

10:16:25 AM Akerkar) 25

Step 4: Elaborate Use Cases
 Developers work from use cases when they
implement th system. Therefore, they must
i l t the t Th f th t
contain all the details of interaction between
actors and the system
system.
 It's convenient to organize the interaction
between a use case and it associated actors
b t d its i t d t
as a flow of events.
 Each th through th use case i called a
E h path th h the is ll d
scenario.

10:16:25 AM Akerkar) 26

Step 4: Elaborate Use Cases (Example)
 Purchase an Item - This use case is used by a customer
to purchase an item.

10:16:25 AM Akerkar) 27

Step 5: Create a Structured Use Case
Model
 A use case model shows the
relationships between actors and
use cases.
 Apply to Become an Affiliate and
Purchase Item are both
generalized b th V if C dit
li d by the Verify Credit
use case.

 Verify Credit is an abstract use
case.
case
 The two concrete use cases Apply
to Become an Affiliate and
Purchase Item both include the
behavior described by Verify Credit
plus more
more.

10:16:25 AM Akerkar) 28

Class Diagram
•This diagram describes
the structure of a simple
p
Restaurant System.
•UML shows is_a
relationships with a
triangle; and containers
with diamond shape

10:16:25 AM Akerkar) 29

Sequence Diagram
 This diagram describes the
sequences of messages of the
q g
(simple) Restaurant System.
 This diagram represents a
Patron ordering food, eating
g , g
the food, drinking wine, then
paying for the food.
 The dotted lines extending g
downwards indicate the
timeline.
 The arrows represent
p
messages (stimuli) from an
actor or object to other objects.

10:16:25 AM Akerkar) 30

Collaboration Diagram
 A Collaboration diagram
models the interactions
between objects in terms of
sequenced messages.

 Collaboration diagrams
represent a combination of
information taken from Class,
Sequence, and Use Cases
Diagrams

 Collaboration and sequence
diagrams d
di describe th same
ib the
information, and can be
transformed into one another
without difficulty.

10:16:25 AM Akerkar) 31

Relationships
In UML, object interconnections, are modeled as relationships.

There are three kinds of relationships in UML:

• dependencies

• generalizations
li ti

• associations

10:16:25 AM Akerkar) 32

Dependency Relationships
p y p
A dependency indicates a relationship between two or
more elements.
elements
The dependency from CourseSchedule to Course exists because
Course is used in both the add and remove operations of
CourseSchedule.
C S h d l

CourseSchedule
C S h d l
Course
add(c : Course)
Co rse)
remove(c : Course)

10:16:25 AM Akerkar) 33

Generalization Relationships

Person
A generalization connects a subclass
to its superclass. It denotes an
p
inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
of the more general superclass.
Student

10:16:25 AM Akerkar) 34

Generalization Relationships (
p (Cont’d)
)
UML permits a class to inherit from multiple superclasses,
although some programming languages (e.g., Java) do not permit
(e g
multiple inheritance.

Student Employee

TeachingAssistant

10:16:25 AM Akerkar) 35

Association Relationships
p
If two classes in a model need to communicate with each other,
there must be link between them.
them

An association denotes that link.

Student Instructor

10:16:25 AM Akerkar) 36

Association Relationships (
p (Cont’d)
)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.
association

The example indicates that a Student has one or more
Instructors:

Student Instructor
1..*

10:16:25 AM Akerkar) 37

p (Cont’d)
)

The example indicates that every Instructor has one or more
Students:

Student Instructor
1..*

10:16:25 AM Akerkar) 38

p (Cont’d)
)
We can also indicate the behavior of an object in an association
(i.e.,
(i e the role of an object) using rolenames
rolenames.

teaches learns from
Student Instructor
1..* 1..*

10:16:25 AM Akerkar) 39

p (Cont’d)
)
We can also name the association.

membership
Student Team
1..* 1..*

10:16:25 AM Akerkar) 40

p (Cont’d)
)
We can specify dual associations.

member of
1..* 1..*
Student Team
1 president of 1..*

10:16:25 AM Akerkar) 41

p (Cont’d)
)
We can constrain the association relationship by defining the
navigability of the association.
g y

Here, a Router object requests services from a DNS object by
sending messages to (invoking the operations of) the server. The
server
direction of the association indicates that the server has no
knowledge of the Router.

Router DomainNameServer

10:16:25 AM Akerkar) 42

p (Cont’d)
)
Associations can also be objects themselves, called link classes
or an association classes.

Registration
modelNumber
d lN b
serialNumber
warrentyCode
y

Product Warranty

10:16:25 AM Akerkar) 43

p (Cont’d)
)
A class can have a self association.

next

LinkedListNode
previous

10:16:25 AM Akerkar) 44

p (Cont’d)
)
We can model objects that contain other objects by way of
special associations called aggregations and compositions.
p gg g p

An aggregation specifies a whole-part relationship between an
aggregate (a whole) and a constituent part, where the part can
part
exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.

Engine
Car
Transmission

10:16:25 AM Akerkar) 45

p (Cont’d)
)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
p y ( , y
whole). Compositions are denoted by a filled-diamond
adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *

10:16:25 AM Akerkar) 46

Quiz 1
 Consider the following class diagram:

 According to this class diagram is there any
way to express, with an object diagram, that
Jane (a g ) likes Brian ( boy)?
( girl) (a y)

Answer 

10:16:25 AM Akerkar) 47

 No.
No The relationship is boy-likes-girl With the
boy likes girl.
class diagram above there is no way to
express that a g likes a boy.
p girl y

10:16:25 AM Akerkar) 48

Quiz 2
Match the UML model with the
appropriate interpretation.
i t i t t ti

___ A plan i d
l is dependent on a
d t
a.
document. (dependency)
___ Plan first, then document.
first document b.
___ A plan is a special type of
document. (generalization)
(g ) c.
c

10:16:25 AM Akerkar) 49

Quiz 3
 Create an UML class diagram that models the
data relationships described in the following
paragraph.

 To be a collector you have to have one or more
collections. Each collection must have 2 or more
items. E h collection b l
it Each ll ti belongs t one collector. A
to ll t
collection is made up of items owned. A particular
item may be in more than one collection

Answer 

10:16:26 AM Akerkar) 50

10:16:26 AM Akerkar) 51

Quiz 4

 Use the figure to answer the
three questions below.

a. How many portable audio
yp
devices does each student
own?
b. Can there be a portable audio
p
device not owned by any
student?
c. Can there be a CD player not
p y
owned by any student?

Answer 

10:16:26 AM Akerkar) 52

 (a) 1 or more.
more
 (b) no.
 (c) no
no.
 A CD player is a portable audio device. All
portable audio d i
t bl di devices hhave t b owned b
to be d by
exactly one student, so any CD player must
be owned by exactly one student
student.

10:16:26 AM Akerkar) 53

Quiz 5

 What, if anything, is
wrong with the following
model. The model
shows th activities and
h the ti iti d
data flows during a visit
to a doctor s office.
doctor's

Answer 
A
10:16:26 AM Akerkar) 54

 It mixes control flow and data flow
flow.
 The arrows to and from the "Patient Data"
store represent data flow
flow.
 All other arrows are control flow arrows.
Because of this it's not a valid activity
this, it s
diagram or data flow diagram.
 Mixing control flow and data flow is
confusing.

10:16:26 AM Akerkar) 55

References
 Rational Unified Process, version 5.5, Rational Software
Corporation, Cupertino, CA (1999)
 Philippe Kruchten, The Rational Unified Process—An
Introduction, Addison-Wesley-Longman, Reading, MA (1999)
 Ivar Jacobson, Grady Booch, Jim Rumbaugh, The Unified
Software Development Process, Addison-Wesley (1999)
 Grady Booch, et al., UML User’s Guide, Addison-Wesley-
Longman, Reading
Longman Reading, MA (1999).
(1999)
 Stefan Bergstrand, Adopting the Rational Unified Process:
Success with the RUP, Addison Wesley (2004).
 Introduction to the IBM Rational Unified Process Essentials,
an article by Mats Wessberg (2005).

10:16:26 AM Akerkar) 56

Term Project 1
 Option #1 -- Connect Four Game
 This project implements the Connect Four game, a more
complex version of tic-tac-toe.
 The game board is seven squares across and six squares tall.
The winner is the first person to get four of their markers in a row
(vertical, horizontal, or di
( ti l h i t l diagonal). Th wrinkle i th t th b d i
l) The i kl is that the board is
standing upright and you can only add markers from the top. (So
a marker only can be placed at the bottom of a column, or
directly on top of an existing marker )
marker.)
 You will write a program that plays this game against a human
user. The two main parts of the program are the user interface
and strategy algorithm. The program needs to play reasonably
well (it cannot make random moves), but does not have to be
provably optimal or play without errors.

10:16:26 AM Akerkar) 57

Term Project 2
 Option #2 -- Appointment Book
 This project implements a simple appointment book for one person.
 The user should be able to:
 Create new appointments.
 Delete existing appointments.
 List all appointments on a given date.
 List all appointments in a range of dates.
 List all appointments in a given category.
 Each appointment contains the following information:
 Date and time of appointment.
 Length of appointment.
 Description of the appointment.
 A "category" for the appointment.
 Optional features:
 Search appointments for a matching string.
 Edit existing appointments.
 Warn user of conflicting appointments (when creating a new one).

10:16:26 AM Akerkar) 58

Term Project 3
 Option #3 -- Contact List
 This project implements a simple name and address book for one user.
p j p p
 The user should be able to:
 Create new contacts.
 Delete existing contacts.
 Search for (and display) a person by last name or first name Should handle
name.
multiple matches.
 Edit existing contacts.
 Each contact contains the following information:
 First name last name
name, name.
 Street address, town, state, zip code.
 Phone number, email address.
 A "notes" field, where the user can enter any information.
 Optional features:
 Search contacts for a matching string (other than name).

10:16:26 AM Akerkar) 59

Structure of the Project Report
 Title Page (Title, Group Members, Course, Year)
 Contents Page
 Summary of the project
 Requirements (purpose, functional, non-functional
(purpose functional non functional,
constraints)
 Design (
g (DFD level 1, Use case, Sequence
q
diagram, Algorithms etc)
 User Interface (Screen Shots)
 Coding
 Reports, if any

10:16:26 AM Akerkar) 60

Unified Modelling Language

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Unified Modelling Language

Similar a Unified Modelling Language (20)

Más de R A Akerkar

Más de R A Akerkar (11)

Último

Último (20)

Unified Modelling Language