0% found this document useful (0 votes)
4 views

Introduction To UML

The document provides an introduction to the Unified Modeling Language (UML) including what UML is, why it is used, the basic building blocks and elements of UML like models, views, diagrams, classes and relationships. It describes common UML diagrams like class, sequence, use case diagrams and relationships like association, aggregation and generalization.

Uploaded by

devsuraj2002
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Introduction To UML

The document provides an introduction to the Unified Modeling Language (UML) including what UML is, why it is used, the basic building blocks and elements of UML like models, views, diagrams, classes and relationships. It describes common UML diagrams like class, sequence, use case diagrams and relationships like association, aggregation and generalization.

Uploaded by

devsuraj2002
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 71

INTRODUCTION TO

UML
What is UML?

• Unified Modeling Language


– OMG Standard, Object Management Group
– Based on work from Booch, Rumbaugh, Jacobson
• UML is a modeling language to express and design documents, software
– Particularly useful for OO design
– Not a process, but some have been proposed using UML
– Independent of implementation language
Why use UML
• Open Standard, Graphical notation for
– Specifying, visualizing, constructing, and documenting software systems
• Language can be used from general initial design to very specific detailed design
across the entire software development lifecycle
• Increase understanding/communication of product to customers and developers
• Support for diverse application areas
• Support for UML in many software packages today (e.g. Rational, plugins for popular
IDE’s like NetBeans, Eclipse)
• Based upon experience and needs of the user community
Systems, Models and Views
• A model is an abstraction describing a subset of a system
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual rules for depicting views
• Views and models of a single system may overlap each other

Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system
UML Models, Views, Diagrams
• UML is a multi-diagrammatic language
– Each diagram is a view into a model
• Diagram presented from the aspect of a particular stakeholder
• Provides a partial representation of the system
• Is semantically consistent with other views
– Example views
Models, Views, Diagrams
UML BASELINE
• Use Case Diagrams
• Class Diagrams
• Package Diagrams
• Interaction Diagrams
– Sequence
– Collaboration
• Activity Diagrams
• State Transition Diagrams
• Deployment Diagrams
UML Building Blocks
• Modeling Elements
– Structural
– Behavioral
– Organizational
– Annotational
• Diagrams that communicate
ideas using the modeling elements
• Views
Modeling Elements

• Modeling Elements are building blocks for


• constructing conceptual descriptions of systems
• Definition and Scope • Behavioral Things
– Use Cases • Messages
– Automation Boundaries • States
• Transitions
• Structural • Events
– Objects
– Classes
• Organizational Things
– Relations • Packages
– Interfaces • Views
– Components • Annotation
– Nodes • Comments
• Extension • Specifications
– Templates
– Stereotypes
What is a Class Diagram?
• Suppose you have to design a system. Before implementing a
bunch of classes, you’ll want to have a conceptual understanding
of the system
• What classes do I need?
• What functionality and information will these classes have?
• How do they interact with one another?
• Who can see these classes?
• That’s where class diagrams come in. Class diagrams are a neat
way of visualizing the classes in your system before you actually
start coding them up. They’re a static representation of your
system structure.
Example of a Class Diagram for a Banking System
Why Do We Need Class Diagrams?
• This is a fairly simple diagram.
• However, as your system scales and grows, it becomes
increasingly difficult to keep track of all these
relationships.
• Having a precise, organized, and straight-forward
diagram to do that for you is integral to the success of
your system.
• Planning and modeling ahead of time makes programming much
easier.
• Besides that, making changes to class diagrams is easy, whereas
coding different functionality after the fact is kind of annoying.
• When someone wants to build a house, they don’t just grab a
hammer and get to work. They need to have a blueprint — a
design plan — so they can ANALYZE & modify their system.
• You don’t need much technical/language-specific knowledge to
understand it.
Class Representation in UML
• A class is represented as a box with 3 compartments.
– The uppermost one contains the class name.
– The middle one contains the class attributes
– The last one contains the class methods.
They Adhere to a Convention:
• attribute name : type
• method name (parameter: type)
• if you’d like to set a default value to an attribute do as above
balance : Dollars = 0
• if a method doesn’t take any parameters then leave the
parentheses empty. Ex: checkBalance()
Visibility of Class Members
• Class members (attributes and methods) have a specific visibility
assigned to them. See table below for how to represent them in
UML.
Visibility of Members in the
BankAccount class
• We made the `owner` and balance private as well as the withdraw
method.
• We kept the deposit method public. (Anyone can put money in,
but not everyone can take money out. Just as we like it.)
Relationships
Association
• An association is a relationship between two separate classes. It joins two
entirely separate entities.
• There are four different types of association:
– Bi-directional
– Uni-directional
– Aggregation (includes composition aggregation)
– Reflexive.
• Bi-directional and uni-directional associations are the most common ones.
• This can be specified using multiplicity (one to one, one to many, many to
many, etc.).
• A typical implementation in Java is through the use of an instance field. The
relationship can be bi-directional with each class holding a reference to the
other.
Inheritance
• Indicates that child (subclass) is considered to be a specialized form of
the parent (super class).
• For example consider the following:
• Above we have an animal parent class with all public
member fields.
• You can see the arrows originating from the duck, fish, and
zebra child classes which indicate they inherit all the
members from the animal class.
• Not only that, but they also implement their own unique
member fields.
• You can see that the duck class has a swim() method as
well as a quack() method.
Interface
• A relationship between two model elements, in which one model
element implements/executes the behavior that the other model
element specifies.
Dependency - Aggregation

• A special form of association which is a unidirectional (a.k.a one way)


relationship between classes.
• The best way to understand this relationship is to call it a “has a” or “is
part of” relationship.
• For example, consider the two classes: Wallet and Money.
• A wallet “has” money. But money doesn’t necessarily need to have a
wallet so it’s a one directional relationship.
Composition
• A restricted form of Aggregation in which two entities (or you can say
classes) are highly dependent on each other.
• A human needs a heart to live and a heart needs a human body to
function on. In other words when the classes (entities) are dependent
on each other and their life span are same (if one dies then another
one does too) then it’s a composition.
Multiplicity
• After specifying the type of association relationship by connecting the classes, you
can also declare the cardinality between the associated entities. For example:

• The above UML diagram shows that a house has exactly one kitchen, exactly one
bath, at least one bedroom (can have many), exactly one mailbox, and at most one
mortgage (zero or one).
UML Class Diagram Example
• Now, let’s take what we’ve learned in the previous tutorial and apply it.
• In this example we are asked to create a class diagram for a banking
system. It must have the following classes:
– Bank
– ATM
– Customer
– Account
– Transaction
– Checking Account
– Savings Account
Determine Possible Class Members
Bank
• The bank class represents a physical bank.
• It has a location and a unique id.
• This bank also manages several accounts. **There’s an association!**
– What type of association is this?
– Is a bank entirely composed of accounts (composition)?
– Or are accounts ‘part of’ a bank (aggregation)?
– It looks like aggregation.
– It can’t be composition because that would mean that both classes live and die
together.
– That’s not quite right because you can have a bank without accounts and you can
have accounts without a bank.
• We’ll add a method called getAccounts().
ATM
• The ATM class represents a physical ATM.
• Right off the bat, we can come up with three methods for
the ATM:
– withdraw()
– deposit()
– checkBalance()
• Each of these methods takes the card number as input.
• In terms of attributes, an ATM has a location and is
managed by a specific bank.
Customer
• The customer class represents a real customer.
• This customer has a
– name
– address
– date of birth (dob)
– card number
– pin
• For this person to be considered a customer, they must have an
account. **There’s another association!**
– This isn’t aggregation or composition, it’s just a bi-directional association
(drawn using a blank line no arrows).
Account
• The account class represents a bank account.
• Common attributes of bank accounts include
– account number
– balance
– And more
• You can deposit() withdraw() money from the account.
• In addition, banks might offer two types of accounts:
– A checking account
– A savings account.
– These two can thus be considered child classes of the account class and can inherit from
it too.
– We’ll denote this by using a solid black line with an unfilled arrow going into the account
class.
Completed Diagram
Object Diagrams
• Shows instances of Class Diagrams and links among them
– An object diagram is a snapshot of the objects in a system
• At a point in time
• With a selected focus
– Interactions – Sequence diagram
– Message passing – Collaboration diagram
– Operation – Deployment diagram
• Format is
– Instance name : Class name
– Attributes and Values
– Example:
Objects and Links
SEQUENCE DIAGRAM
sequence diagram: an "interaction diagram" that models a single scenario executing in the
system
– perhaps 2nd most used UML diagram (behind class diagram)
• relation of UML diagrams to other exercises:
– CRC cards -> class diagram
– use cases -> sequence diagrams
Key parts of a sequence diag.
• participant: an object or entity that acts in the sequence diagram
– sequence diagram starts with an unattached "found message" arrow
• message: communication between participant objects
• the axes: in a sequence diagram:
– horizontal: which object/participant is acting
– vertical: time (down -> forward in time)
Sequence dg. from use case
Representing objects

• Squares with object type, optionally preceded by object name and colon
– write object's name if it clarifies the diagram
– object's "life line" represented by dashed vert. line
Messages between objects

• message (method call) indicated by horizontal arrow to other object


– write message name and arguments above arrow
Messages, continued
• message (method call) indicated by horizontal arrow to other
object
– dashed arrow back indicates return
– different arrowheads for normal / concurrent (asynchronous) methods

39
Lifetime of objects
• creation: arrow with 'new'
written above it
– notice that an object created after
the start of the scenario appears
lower than the others
• deletion: an X at bottom of
object's lifeline
– Java doesn't explicitly delete
objects; they fall out of scope and
are garbage-collected 40
Indicating method calls
• activation: thick box over object's life line; drawn when
object's method is on the stack
– either that object is running its code, or it is on the stack waiting for
another object's method to finish
– nest to indicate recursion
Activation

Nesting

41
Indicating selection and loops
• frame: box around part of a sequence
diagram to indicate selection or loop
– if -> (opt) [condition]
– if/else -> (alt) [condition],
separated by horizontal dashed line
– loop -> (loop) [condition
or items to loop over]

42
linking sequence diagrams
• if one sequence diagram is too large or refers to another diagram, indicate it with either:
– an unfinished arrow and comment
– a "ref" frame that names the other diagram
– when would this occur in our system?

Customer Info ref

Verify customer credit

Approved?

43
Example sequence diagram
sd Example

StoreFront Cart Inventory

loop
AddItem
ReserveItem

Checkout

ProcessOrder
ConfirmOrder

PlaceItemInOrder

44
Example sequence diagram
Example sequence diagram
Collaboration Diagram
• Collaboration Diagrams show similar information to sequence diagrams,
except that the vertical sequence is missing. In its place are:
– Object Links - solid lines between the objects that interact
– On the links are Messages - arrows with one or more message name that show the direction and
names of the messages sent between objects
• Emphasis on static links as opposed to sequence in the sequence diagram
• The collaboration diagram will indicate the objects participating in the
collaboration, and
• The sequence of messages {message(parameters), sender, receiver}
exchanged to achieve the task involved.
Collaboration Diagram
Collaboration Diagrams
Actor System
SystemOp
:ClassA
System Op
Operation:xxx
+ 1: message1()
Precondition:..

:ClassB

Contract Collaboration
Diagram
Use Case
Diagram
Collaboration Diagrams Notation

Student :Student John:Student

class instance named instance

The Collaboration diagram should consist of illustrations of the


messages sent to objects of the classes identified in the
creates/destroys, reads, changes sections of the contract. The
system operation will be directed to one of the objects in this
group that will act as the controller for executing this task.
Collaboration Diagrams

Illustrating links

UML standard syntax for messages

return := message(parameter : parameterType) : returnType

sysOp() optional

1: tot := total():integer
:POST :Sale

sender receiver
Collaboration Diagrams

Illustrating Iteration

SystemOp( )

1*: [i:=0..9] str : getName(): String


CS335:ClassList
:Grader

sender receiver
Sequence number followed by a Iteration clause is optional
* indicates iteration
Collaboration Diagrams

Illustrating Iteration

In the example described on the previous slide, we


assumed that the target object contained a sequence of
names (simple strings) as an attribute. More generally the
ClassList may be considered a collection of StudentRec
objects, and messages may be directed to the collection.
The depiction of a message to a multiobject – a group of
objects stored in a collection – is indicated on the next
slide.

1: message( )
:ClassA

Representation of a collection (multiobject)


Collaboration Diagrams

Given: A vector of StudentRecord

1: inx := find(name: String): integer


v: vector

Version 1 – message to a collection (but vector is NOT a


concept in the problem domain)

1: inx := find(name: String): integer


:StudentRecord

Version 2 – (preferred) Emphasizes the objects in the


collection, not (the solution domain) container.
Collaboration Diagrams
Conditional Paths – mutually exclusive messages
msg1( )

1a: [test] msg2( ) :ClassB


:ClassA
guard – if true send msg

1b: [not test] msg4( ) 1a.1: msg3( )

1b.1: msg5( )
:ClassC :ClassD
Collaboration Diagrams

Creating a new instance during implementation of the


system operation

New
1: create( )
c: Controller m:MenuItem

2: add(m)
:MenuItem

Create a new MenuItem, m, and add it to the Menu


Activity diagrams
• Useful to specify software or hardware system behaviour
• Based on data flow models – a graphical representation (with
a Directed Graph) of how data move around an information
system
[order reject]

Receive Fill Ship Close


Order Order Order Order

[order
accepted]

Send Accept
Invoice Make Payment
Invoice Payment

57
Activity Diagrams
• Fancy flowchart
– Displays the flow of activities involved in a single process
– States
• Describe what is being processed
• Indicated by boxes with rounded corners
– Swim lanes
• Indicates which object is responsible for what activity
– Branch
• Transition that branch
• Indicated by a diamond
– Fork
• Transition forking into parallel activities
• Indicated by solid bars
– Start and End
Some definitions
• Flow: permits the interaction between two nodes of the activity diagram
(represented by edges in activity diagram)
• State: a condition or situation in the life of an object during which it satisfies
some conditions, performs some activities, or waits for some events
• Type: specifies a domain of objects together with the operations applicable to
the objects (also none); includes primitive built-in types (such as integer and
string) and enumeration types
• Token: contains an object, datum, or locus of control, and is present in the
activity diagram at a particular node; each token is distinct from any other, even
if it contains the same value as another
• Value: an element of a type domain

59
Sample Activity Diagram

• Ordering System
• May need multiple
diagrams from
other points of view
Activity Diagram

Supplements the use-case


by providing a diagrammatic
representation of procedural
flow

Details:
-Start is a single circle
-End is a bulls-eye
-Decisions are diamonds
(guards must be on both
branches of the diamond!)
Activity Diagram Example
Swimlane Diagrams

Allows the modeler to


represent the flow of
activities described by the
use-case and at the same
time indicate which actor
(if there are multiple
actors involved in a
specific use-case) or
analysis class has
responsibility for the
action described by an
activity rectangle

Coming up: Activity Diagram Example


Activity Diagram Example
Fork/
- To show concurrent Branch
activity, activity
diagrams allow
branches and joins.

- You can also


reference or include
other activity
diagrams
Join

Coming up: Lets Try It


Actions
• The fundamental unit of executable
functionality in an activity
• The execution of an action represents some
transformations or processes in the modeled
system (creating objects, setting attribute
values, linking objects together, invoking user-
defined behaviours, etc.)
Description of
the action
behaviour
65
Conditions to start and end actions
• An action can start only if:
– all non-stream inputs have arrived (or at least one
stream input if there are only stream inputs)
• The action can finish only if:
– all inputs have arrived (streaming inputs included)
– all non-stream and non-exception outputs (or an
exception outputs) have been provided

• Prevent deadlock: an input pin of an action cannot


accept tokens until all the input pins of the action can
accept them

66
Activities
• An activity is the specification of parameterized behaviour as the
coordinated sequencing of subordinate units whose individual
elements are actions
• Uses parameters to receive and provide data to the invoker

Activity
nodes
Parameter Activity Parameter Output
Input name
edges name
parameter Parameter parameter
name

 An action can invoke an activity to describe its action more finely


This action invokes the
activity Fill Order 67
Activity nodes
• Three type of activity nodes:
– Action nodes: executable activity nodes; the execution of an
action represents some transformations or processes in the
modeled system (already seen)

– Control nodes: coordinate flows in an activity diagram


between other nodes

– Object nodes: indicate an instance of a particular object, may


be available at a particular point in the activity (i.e Pins are
object nodes)

68
Activity edges (1)
• Are directed connections
• They have a source and a target, along which tokens may flow

• Any number of tokens can pass along the edge, in groups at


one time, or individually at different times
• Weight: determines the minimum number of tokens that
must traverse the edge at the same time

In this example we use a non-constant weight: an invoice for a particular job can
69
only be sent when all of its tasks have been completed
Activity edges (2)
• Two kinds of edges:
– Control flow edge - is an edge which starts an activity
node after the completion of the previous one by
passing a control token
Notation without
activity nodes
– Object flow edge - models the flow of values to or from
object nodes by passing object or data tokens

Notation without
activity nodes

70
Example – go to Genova Go to
Heaven/Hell ;)
Car crash
«local precondition»
Have a license

To Catch
Turn on [else] Fill up
motorway the
the car with fuel
[on car] tollgate ticket
[the tank is full]

Get Go home Exit to


Pay the
luggage with the Genova
ticket
ready car tollgate
[on train]

Go to the
Buy the Obliterate Catch the
station with a
ticket the ticket train
friend
The train
Go to derail
Heaven/
Hell ;) The friend
goes home
When the train
arrives
to Genova

[else] Study for


Go home Get off
5
with bus the train
minutes

71
[Genova is a long way]

You might also like