MODELING AND UML

Learning Objectives
• Define model and diagrams and explain importance of
them to system development.
• Introduce UML
Definitions
• A model is a simplified representation of something in
the real world, usually for the purpose of understanding
that reality, and having all the features of that reality
necessary for the current task or problem.
 Like a map, a model represents something else.
• Thus modeling is a form of abstraction, that is, the
process of focusing only on features essential to the
problem at hand.
What Are Models For?
• Models are used for:
 To capture and precisely state requirements and domain
knowledge so that all stakeholders may understand and
agree on them.
 To think about the design of a system.
 To capture design decisions in a mutable form separate from
the requirements.
 To generate usable work products.
 To organize, retrieve and edit info about large systems.
 To explore multiple solutions economically.
 To master complex systems.
Levels of Models
• Models take on different forms and appear at different
levels of abstraction.
 A useful model has the right level of detail and represents only
what is important for the task in hand.
• The amount of detail in the model is adapted to one of the
following purposes:
 Guides to the thought process.
 Abstract specifications of the essential structure of a system.
 Full specification of a final system.
 Exemplars of typical or possible systems.
 Complete or partial descriptions of systems.
Many Matching Models
• Each model emphasizes some aspect of the real-world
thing.
• Thus, many models are required to reveal all the
important details of that thing.
• Yet, these matching models must eventually fit together.
 What is represented in one model must be consistent with
what is represented in another model.
House Blueprint
Diagrams
• Diagrams are abstract shapes that are used to
represent things or actions from the real world
• Diagrams follow rules or standards
• The standards make sure that different people will
interpret the diagram in the same way
An Example of a Diagram
• An activity diagram of the Author Reviewer Typesetter Printer

tasks involved in Write Chapter

producing a book. Review Chapter

Revise Chapter
[book not
complete]
[book complete]

Typeset Book

Correct Proofs

Reset Book

Print Book
Diagrams versus Models
• A diagram illustrates some aspect of a system.
• A model provides a complete view of a system at a
particular stage and from a particular perspective.
• A model may consist of a single diagram, but most
consist of many related diagrams and supporting data
and documentation.
Models in Systems Development
• To understand the user’s world we need:
 People sensitivity (interviewing and listening skills) for
gathering relevant and accurate information.
 Modeling diagrams to document and communicate what
we’ve learned from the users.
o We are using UML as our modeling notation.
 Modeling techniques to ensure these notations produce an
accurate picture of the user’s business.
o These are partly defined by:
 the modeling notation itself, as well as
 the software process/methodology.
Developing Models
• The models that we produce during the development of
a system change as the project progresses.
• They change by degree of:
 Abstraction
o Model will become less abstract and more concrete.
 Formality
o Degree of formality in which methods, attributes, and constraints
are defined will increase as project progress.
 Level of detail
o More potential detail in every model as project progresses.
Development of Use Case Model through
successive iterations
Iteration 1
Staff Management

Add a new staff

member
Staff Management

Add a new staff

member
Add a new staff
grade

Add a new staff

grade

Obvious use cases.

Change the
rate for a
staff grade

Accountant Change the

rate for a
staff grade Change the
grade for a
staff member
Accountant

Change the
grade for a
staff member
Calculate staff
bonuses

Calculate staff

Simple use case descriptions.

bonuses

Iteration 2
Staff Management

Add a new staff

member
Staff Management

Add a new staff

member
Staff Management
Add a new staff
grade Campaign Selection
Add a new staff
member
Add a new staff Campaign Selection
grade

Additional use cases.

Change the
rate for a Client:
staff grade Campaign Selection Holborn Motors
Add a new staff
grade
Lynch Properties
Client: Yellow Partridge
HolbornYellow Partridge
Accountant Change the
rate for a Motors
staff grade Change the
Zeta Systems
Lynch Properties
grade for a
Client: Yellow Partridge
Accountant Change the
staff member HolbornYellow Partridge
Motors
rate for a Campaign: Zeta Systems
Lynch PropertiesSpring Jewellery Campaign 1997
staff grade Change the
grade for a Yellow PartridgeSpring Jewellery Campaign 2001
Accountant
staff member
Calculate staff Campaign: Zeta Systems Spring Jewellery
Spring Jewellery CampaignCampaign
1997 2002
bonuses Summer Collection
Spring Jewellery Campaign1998
2001
Change the

Simple use case descriptions.

grade for a
Campaign: Spring Jewellery Campaign 2002
staff member
Calculate staff SummerOKCollection 1998 Quit
bonuses

Calculate staff
OK Quit
bonuses

OK Quit

Prototypes.

Iteration 3 Assign staff

to work on
a campaign «include»
Campaign Management

Find campaign
Campaign Management

Assign staff «include»

Campaign Selection

Structured use cases.

to work on Add a new
a campaign advert to
«include»
a campaign
Find campaign«include»
Campaign Management

Assign staff Campaign «include»

Campaign Selection
to work on Manager
Add a new
a campaign advert to
«include» Check campaign Client: Holborn Motors
a campaign
Find campaign«include»
budget Campaign Selection
Campaign «include»
Lynch Properties
Manager
Client: Yellow Partridge
HolbornYellow Partridge
Add a new
advert to
«extend» «extend»
Motors
a campaign
Check campaign
«include»
budget Zeta Systems
Lynch Properties
Print campaign Print campaign
Client: Yellow Partridge
HolbornYellow Partridge
Campaign
Manager
summary invoice
Motors
Check campaign
«extend» «extend»
Campaign: Zeta Systems
Lynch PropertiesSpring Jewellery Campaign 1997
budget

Structured use case descriptions.

Accountant

Print campaign Print campaign

Yellow PartridgeSpring Jewellery Campaign 2001
summary invoice
Campaign: Zeta Systems Spring Jewellery
Spring Jewellery CampaignCampaign
1997 2002
«extend» «extend»
Summer Collection
Spring Jewellery Campaign1998
2001
Accountant

Print campaign Print campaign

Campaign: Spring Jewellery Campaign 2002
summary invoice
SummerOKCollection 1998 Quit
Accountant

OK Quit

OK Quit

Prototypes.
Earlier Models and Diagrams
• A variety of modeling notations have developed over
the years. These include:
 Process models (data flow diagrams)
 Data models (ERDs)
Process Models: Data Flow Diagrams
• Focus not just on Student Details Registration
Validated Student Student

operations but on who

Details Records

does what with whom. Acknowledgement

That is, the focus is on

of Registration
Student
Enrollment
Confirmation

data and how it processes Confirmation of

Enrollment Request Enrollment
through an organization.
Enrollment

• Used Data Flow Diagrams Vacancies Courses

(DFDs) as a way to model

Confirmed
Enrollments Enrollments

the activities, functions,

and processes that make
up a users’ business.
Data Models: ERDs
• Focus on data modeling
rather than on process
modeling.
• Entity Relationship
Diagrams (ERDs) used
as analysis tool as well
as a database design
tool.
OO Diagramming
• There are all sorts of different OO diagrams:
 e.g., Booch OOD, Rumbaugh OMT, Yourdon & Coad, etc.
• UML (Unified Modeling Language) has become the
standard notation for OO diagramming and modeling.
 The modeling notation defined by UML does not define a
modeling technique
o These are defined by the software process/methodology.
 UML is not a methodology or process; rather it is a
universal modeling notation.
UML Defined
• The Unified Modeling Language (UML) is a general
purpose visual modeling language that is used to
specify, visualize, construct, and document the artifacts
of a software system.
• It captures decisions and understanding about systems
that must be constructed.
• It is used to understand, design, browse, configure,
maintain, and control information about systems.
• It is intended to be used with all development methods,
lifecycle stages, application domains, and media.
Not A Programming Language!
• The UML is not a programming language !
• The UML is a general-purpose modeling notation for
discrete systems such as software.
Goals of UML
• There were a number of goals behind the development of UML:
 UML is a general-purpose modeling language that all modelers can
use.
 It is meant to include the concepts of the leading methods so that it
can be used as their modeling language.
 It was intended to be as familiar as possible.
 It is meant to support good practices for design such as
encapsulation, separation of concerns, and capture of the intent of a
model construct.
 It is intended to address current software development issues, such as
large scale, distribution, concurrency, patterns and team development.
 It was to be as simple as possible while still being capable of
modeling the full range of practical systems that need to be built.
What Does Unified Mean?
• The word unified has the following relevant meanings
for UML:
• Across historical methods and notations.
• Across the development lifecycle
• Across application domains
• Across implementation languages and platforms
• Across development processes
• Across internal concepts
UML Building Blocks
• UML is composed of three building blocks:
 Things
o These are the modeling elements
 Relationships
o These tie things together
 Diagrams
o These are views into UML models
UML Things
• UML thing may be partitioned into:
 Structural things
o Represent the nouns of a UML model such as class, component,
use case, etc
 Behavioral things
o Represent the verbs of a UML model such as interactions, states,
etc.
 Grouping things
o Represent things that group elements together such as the
package.
 Annotational things
o The note
UML Relationships
• Used to show how two or more things relate to each
other.

generalization association

dependency realization
Diagrams in UML

• UML diagrams consist of: Write Chapter

• icons Plan Chapter

• two-dimensional symbols
Produce
• paths First Draft

• Strings
Revise Draft

[not satisfied]

[satisfied]

• UML diagrams are views into the model. Add Exercises

• They are not the model itself

Add References
to Bibliography
UML Diagrams

Static Model Dynamic Model

class diagram object diagram

component diagram use case diagram

deployment diagram sequence diagram

collaboration diagram

statechart diagram

activity diagram
UML Parts
• A system is modeled as a collection of discrete objects
that interact to perform work that ultimately benefits an
outside user.
• UML has:
 static and,
 dynamic parts.
Static and Dynamic Information
• In particular UML captures information about the
static structure and the dynamic behavior of a
system.
 The static structure defines the kinds of objects
important to a system and to its implementation, as
well as the relationships among the objects.
 The dynamic behavior defines the history of objects
over time and the communications among objects to
accomplish goals.
Organization
• The UML also contains organization constructs for
arranging models into packages that permit software
teams to:
 partition large systems into workable pieces.
 understand and control dependencies among the packages,
and
 manage the versioning of model units in a complex
development environment.
• The UML contains constructs for representing
implementation decisions and for organizing run-time
elements into components.
Organization
• The UML also contains organization constructs for
arranging models into packages that permit software
teams to:
 partition large systems into workable pieces.
 understand and control dependencies among the packages,
and
 manage the versioning of model units in a complex
development environment.
• The UML contains constructs for representing
implementation decisions and for organizing run-time
elements into components.
Static Structure
• Any precise model must first define the universe of
discourse.
 That is, the key concepts from the application, their
internal properties, and their relationships to each other.
• This set of constructs is the static view of the system.
• The static view is notated by class diagrams (also
called class static structure diagrams).
 That is, the application concepts are modeled as classes,
each of which describes a set of discrete objects that
hold information and communicate to implement behavior.
Class static structure diagrams
BankAccount Customer
-customerName
-accountNum
-balance
+getCustomerName()
+getAccountNum()
+getBalance()
+setBalance()

Loan CheckingAccount

-interestRate -serviceCharge

+makePayment() +deposit()
+addInterest() +withdrawal()
Dynamic Behavior
• There are two ways to model behavior:
 One is the communication patterns of a set of connected
objects as they interact to implement behavior.
o This is modeled using use case diagrams, sequence
diagrams, collaboration diagrams, and activity diagrams.
 The other is the evolution of an object’s state over time
as it interacts with the rest of the world.
o State change refers to possible changes in object’s attributes
and associations with other objects.
o This is modeled as a statechart.
Use Cases
• When we analyze a system we try to identify the main
functionality that the system will have and the main
ways it will be used.
• Each of these ways the system is going to be used is
called a use case.
 A use case is a sequence of actions a system performs
that yields an observable result of value to a particular
actor.
o An actor is either a person (user) interacting with the system
or, in some cases, another system interacting with the
system.
Using Use Cases
• A use case captures the main functionality of the
system from a user or actor’s perspective.
• It also serves as a vehicle to divide the system into
parts that can be implemented somewhat
separately.
 For any given system, we will usually develop and
implement the most important use cases first.
 Establishing which use cases are important often
follows from looking at the main events in the problem
domain.
Use Case Diagram
• We can model use cases in a Video Store System
use case diagram.
 Stick figures represent actors. Rent Videos

 Ovals represent the use case.

 The arrows show interactions.
Video Store Clerk Add New Videos
Activity Diagrams
• Used to model business activities/tasks in the
very early stages of a project.
• Also used to describe a system function described
by a use case.
• They are analogous to standard flowcharts.
Activity Diagrams

Campaign Accountant Client

• Swimlanes Manager

• vertical columns
• labelled with the Record Completion
of a campaign

person, organisation
or department Issue invoice
responsible for the
activities in that
column Pay invoice

Record client
payment
Sequence Diagrams
• The class diagram is limited in that it does not
represent time-dependent behaviors.
• Sequence diagrams present object interactions
arranged in time sequence.
 It shows the actors or objects participating in an
interaction and the events they generate arranged in a
time sequence.
 Often, a sequence diagram shows the events that result
from a particular instance of a use case but a sequence
diagram can also exist in a more generic form.
Sequence Diagrams

Patron Librarian System

SubmitResources() Rectangles represent objects.

Stick figures represent actors.
Vertical lines represent the lifeline of the object or actor.
SubmitLibraryCard() Horizontal arrows indicate messages.

RecordID()

CheckStatus()
status()

RecordCallNumber()

CalcDueDate()

RecordLoan()

dueDate()
Collaboration Diagram
• A collaboration diagram shows interactions organized
around the objects and their messages to each other.
 Collaboration diagrams and sequence diagrams are
used interchangeably.
• Unlike a sequence diagram, a collaboration diagram
shows relationships among object roles and it does
not express time as a separate dimension.
2: Message2()
Message1() 3: Message3()
ClassAInstance ClassBInstance
Statechart Diagram
• The statechart diagram shows the states an object might be
in and the actions or conditions that cause an object to
make a transition from one state to another.
• By documenting events and transitions, a statechart
diagram shows the sequence of states an object goes
through during its life.
• Statecharts are extensions of the class diagram and you
could create one statechart for each class.
 In practice, you will only create a statechart for those classes
that exhibit especially interesting or complex time-dependent
behavior.
Statechart Diagram

Retrieving Books Packaging

setFulfilledFlag
Shipped Shipping

Boxes represent states.

Arrows represent transitions between states.
Solid dots represent start and end states.
Model Organization
• Computers can deal with large flat models, but humans
cannot.
• In a large system, modeling information must be
divided into coherent pieces so that teams can work on
different parts concurrently.
• Packages are general-purpose hierarchical
organizational units of UML models.
 Packages can be used for storage, access control,
configuration management, and constructing libraries that
contain reusable model fragments.
Packages
• If the class diagram becomes large, it will become
quite difficult to use for an overview of the system.
• In such cases we create a high-level view of the
system, using some kind of partitioning or cluster
scheme.
• UML calls these clusters packages and provides
modeling notation called a package diagram.
Sales Human Resources