Software Modeling with UML

1
What is Modeling?
 Modeling is simplifying the concept of target system and building
a visual image of it
 Representation of the design results into some sort of
diagrams
di

 Models
M d l are necessary ffor
 Organization of the concept
 Communication
C
 Delivery of the concept to the implementation process among developers
and development processes

2
High level models in Information Systems
Development
 Business
B i C
Case:
 a model used to help people decide if a system is worth developing.
 Business
B i R
Requirements
i t
 The more detail of processes in a business, the customers of the business,
the workers,
workers and the assets.
assets
 System Requirements
 define
d fi what
h t a system
t isi tto do;
d ddetail
t il by
b llooking
ki att use case modelling
d lli
 Logical Design
 describe
d b ways in which
h h a computer system can meet the
h requirements.
We will be looking at object models, sequence diagrams and activity
diagrams to elaborate this model.
model
3
High level models in Information Systems
Development (contd.)
 Technical Design
 After having the logical design, this design include the screens that make
up a system, where
h ddata iis stored,
d andd so on
 Implementation
 the
h endd output off modelling.
d ll
 Testing
 Testing models consist of test plans derived from design and requirements
models.

4
Unified Modeling Language - UML
 UML only offers a model notation, not
a methodology
h d l ffor hhow to ddo modeling.
d l BUSINESS LOGIC
 a general purpose language that uses a
graphical designation which can
create an abstract model. ANALYSIS &
 A language that could support every DESIGN
object oriented approach to solve
various engineering challenges.
UML MODEL
 UML models
d l can be
b transformed
f d into
i
various other representations, often
without a great deal of effort.
effort
 One example of this is the ability to
transform UML models into Java
representations.
5
UML Modeling
 UML has a number of models which in turn form part of the
models for information systems development, such as the
systems requirements
 There are total of 13 types of diagrams in UML 2.0. They can be divided
into two categories:
 structural diagrams
 Static structure or Snapshots of a scene at a moment
 behavioral diagrams
 Story (scenario) of changing scene along the time

6
Types of UML Diagrams
UML 2 Diagrams
g

Structural Diagrams Class Diagram

Object Diagram

Component Diagram

D l
Deployment Di
Diagram

Package Diagram

Behavioral Diagram Activity Diagram

Use Case Diagram

Interaction Diagram

g
State Machine Diagram

7
8
9
Basic Concepts of Object Orientation
 Object orientation is
 an idea that uses object units to represent the real world on
computers
 For example
 Cars and cameras are objects in real world
 Represent these objects in computers using same concepts as in real
world
 In
I object
b orientedd method,
h d the
h objects
bj are independent
i d d parts
 To change or modification is only concerned with particular object
 E.g.,
E to change
h color
l off the
h car, only
l that
h object
b hhas to bbe modified
df d

10
Basic Principles of Object Orientation

Object Orientation

ncapsuulation
Abstracction

Modulaarity

Hierarrchy
M
A

En

11
 UML Diagrams : Use Case

12
13
Use case Diagram
 A use case is a set of scenarios that describing an interaction
between a user and a system.
 A use case diagram
g
 displays the relationship among actors and use cases.
 describes “how the system
y will be used from
f the user’s
viewpoint”
 Is suited for the analysis
y and representation
p in Requirements
q
Definition Process
 Basic notations
 Relationships
 Tips in Usecases

14
Use case Diagram: Basic Notations
 Consists of only 3 elements:
 actor,
 use case and
 association

Association
Use case
Actor

15
Elements of use case and typical representations in the real system

Use case Typical representations in real system

Element
Actor User / Operator / People involved in the system
Any external entity for the system
Agent-like process inside the system
U case
Use A ti it / Action
Activity A ti / Process
P

Association Involvement of an actor to a use case such as usage,

g
communication, command, etc.
Usually, association will be drawn without any
description If necessary
description. necessary, however
however, you can describe the
association by words or sentences.
Note: You should NOT use arrow, but should use simple
line
16
Use Case Diagram: Example
 "A patient calls the clinic to make an appointment for a yearly
check up. The receptionist finds the nearest empty time slot in
the appointment book and schedules the appointment for that
time slot.” System boundary

17
Use Case Diagram: Example - Online shop system

System boundary

Show
catalog
Purchase
Place order stock
t k Supplier

Ship product
Customer

<<system>>
Shop controller

18
Use case Diagram: Relationships
 Represents any kind of involvement for the use case, including
data flow, control flow, action, event, etc

 Generalization
 Some detailed dependencies between use cases or between
actors
 For possible reuse of common,
common shared part within the
target system

19
Use case Diagram: Relationships
 Use Case Example for Placing a bids
 duplicate behaviour in both the buyer and seller which includes
"create an account" and "search listings".

20
Use case Diagram: Relationships

 Generalization
 A generic user creates accounts and
search listings and that a buyer and a
seller have their own behaviour but also
have the behaviour of the generic user.
 The benefits of ggeneralization are that
you eliminate duplicate behavior and
attributes that will ultimately make the
system
y more understandable and flexible.
21
Use case Diagram: Relationships
 Refined use case diagram with system boundary for placing a bids

Create
<<extend>> Account

Search listing for

<<extend>> Items
Generic User
Place Bids

Purchase
<<generalization>>
g
I
Items
buyer

Create an
auction

Ships Items
Seller

22
Use case Diagram: Extend and Include Dependency
 This dependency is used for adding an extended or additional use
case that
h has
h not bbeen included
l d d in the
h originall use case

Original use case <<extend>> An extended use case or

Extension points added use case to the
original use case

 Used for indicating possible module or function that is shared and used
by many other modules in system design process

A use case that is <<include>> A use case that includes

included in other use (uses) the function of
cases other use cases

23
Use case Diagram: Extend and Include Dependency

order
enough
stock

<<extend>>

shipping

<<include>>

reduce
d
stock

24
Use case Diagram: Inheritance
 Complete replacing of one or more actions in the inherited use case
 The target system needs to implement specialized version of
original use case

A use case that is the

Original use specialized version
case of original use case

Original Inherited
actor actor

25
Use case diagram that uses generalization relations

System boundary

Show catalog <<include>>

Ch k
Check
inventory
Place order
Get shipment address

<<extend>>
Customer
Enter shipment Purchase
address stock
Supplier
<<include>>
Ship product

Registered Show personalized

Member <<system>>
catalog Shop
Customer
controller
26
Use case diagram: Example using (eclipse Software)

27
Exercise
 Draw a use-case diagram for “Post-graduate Admission System”

28