Post on 09-Dec-2015
description
Introduction to UML
Prepared By:
Prof. U. Verma
MPSTME Shirpur Campus
psg/1upendra.verma@nmims.edu
What is UML?Modeling involves
• understanding ( semantics) a subject (system)
and
• capturing and communicating this knowledge
The Unified Modeling Language ( UML) is:
• A complete language for capturing knowledge (semantics) about a subject
(system) and communicating the knowledge (syntax)
– the result of unifying the IT industry’s best engineering practices
– proposed by Booch, Rumbaugh and Jacobson-the Three Amigos
psg/2upendra.verma@nmims.edu
psg/3
..What is UML?
• UML is the standard language for visualizing, specifying,
constructing, and documenting the artifacts of a software
intensive system
• It can be used with all processes, throughout the development
life cycle, and across different implementation technologies
upendra.verma@nmims.edu
psg/4
..What is UML?
• Visualizing – UML is more than just a bunch of graphical
symbols. For each symbol in the UML notation is a well defined
semantics.
• Specifying – Building models that are precise, unambiguous,
and complete.
• Constructing – models can be directly connected to a variety of
programming language. It is possible to map model in the UML
to a programming language like JAVA, C++, or VB.
• Documenting – UML addresses the documentation of a
system’s architecture and all of its details, provides language for
expressing requirements, for test, for modeling the activities of
project planning and release management.
upendra.verma@nmims.edu
psg/5
Evolution of the UML
• Unification
– James Rumbaugh, Grady Booch and Ivar Jacobson joined Rational
Software Corporation to unify their methods.
• Rumbaugh - Analysis oriented (OMT)
• Booch - Design and Construction oriented
• Jacobson - Use case oriented (OOSE)
– Since the independent methods were evolving towards one
another, continue evolution by unification.
– Identify and incorporate fundamental concepts, building a meta
model and a notation to describe them.
upendra.verma@nmims.edu
psg/6
Standardization
• More companies joined the UML partner’s consortium to
contribute their ideas and produce version 1.1 of the UML with
– Increased formalism
– Improved structural packaging
– Improved mapping of notation to semantics
• UML 1.1 is accepted by OMG as a standard in fall 1997.
upendra.verma@nmims.edu
psg/7
The UML Scope
• Fusing concepts of Booch, OMT and OOSE.
• Focusing on a standard modeling language (common notation
and semantics)
• Incorporating the object-oriented community’s consensus on
core modeling concepts.
• Providing sufficient notation to address contemporary modeling
issues directly and economically.
• Providing extensibility mechanisms to extend UML for individual
projects.
upendra.verma@nmims.edu
psg/8
– The UML enables and promotes a use-case-driven, architecture-
centric, iterative, and incremental process that is object oriented
and component based.
upendra.verma@nmims.edu
The UML Definition
psg/9
• Defined by a set of documents
– UML Semantics
– UML Notation Guide
upendra.verma@nmims.edu
psg/10
The UML Semantics Document
• Constitutes the single, common, formal and comprehensive
specification of the UML (inside view).
• Primarily used by tool vendors.
• Specifies the UML’s layered architecture, organization and
defines modeling elements.
• Enables consistent usage of the UML.
upendra.verma@nmims.edu
psg/11
The UML Notation Guide
• Constitutes the notational or visual representation of the UML
and provides examples (outside view)
• Primarily used by practitioners applying the UML
• Specifies UML diagrams and their modeling elements
upendra.verma@nmims.edu
psg/12
A Conceptual Model of UML
• To understand UML -
– You need to form a conceptual model of the language.
• This requires learning three major elements.
– The UML’s basic building blocks
– The rules that dictate how those building blocks may be
put together
– Some common mechanism that apply throughout the UML
upendra.verma@nmims.edu
psg/13
Basic Building Blocks of UML
• Three kinds of building blocks -
– Things
– Relationships
– Diagrams
upendra.verma@nmims.edu
psg/14
Basic Building Blocks of UML - Things
• Things
– The abstractions that are first-class citizens in a model.
– There are four kinds of things in the UML
1. Structural
2. Behavioral
3. Grouping
4. Annotational
upendra.verma@nmims.edu
psg/15
Basic Building Blocks of UML – Things -
Structural
• Structural
– These are nouns of UML models which are static parts
represent elements that are either conceptual or physical.
– There are seven kinds of structural things in the UML
1. class
2. interface
3. collaboration
4. Use case
5. Active class
6. Component
7. node
upendra.verma@nmims.edu
psg/16
Basic Building Blocks of UML – Things –
Structural – Class, Interface
• Class
– Description of as set of objects that share same attributes,
operations, relationships, and semantics.
– Graphically, a class is rendered as a rectangle.
• interface
– A collection of operation that specify a service of a class or
component.
– Describes externally visible behavior of a class or
component or only a part of that behavior.
– Defines set of operation specifications
– Graphically, an interface is rendered as a circle.
upendra.verma@nmims.edu
psg/17
Basic Building Blocks of UML – Things –
Structural – Collaboration
• Collaboration
– Defines an interaction and is a society of classes, interfaces
and other elements work together to provide some
cooperative behavior.
– A given class might participate in several collaborations
– Represents the implementation of patterns that make up a
system
– Graphically, a collaboration is rendered as an ellipse with
dashed line, usually including only its name.
upendra.verma@nmims.edu
psg/18
Basic Building Blocks of UML – Things –
Structural – Use case
• Use case
– It is a description of set of sequence of actions that a
system performs that yields an observable result of value to
a particular actor.
– It is used to structure the behavioral things in a model.
– It is realized by a collaboration.
– Graphically, a use case is rendered as an ellipse with solid
line, usually including only its name.
upendra.verma@nmims.edu
psg/19
Basic Building Blocks of UML – Things –
Structural – Active class, Component
• Active Class
– The objects of active class own one or more processes or
threads so initiate control activity.
– Graphically, an active class is rendered as a rectangle with
heavy lines.
• Component
– It is a physical and replaceable part of a system that
conforms to and provides the realization of a set of
interface.
– Graphically, a component is rendered as a rectangle with
tabs, usually including only its name.upendra.verma@nmims.edu
psg/20
Basic Building Blocks of UML – Things –
Structural – Node
• Node
– It is a physical element that exists at run time.
– It represents a computational resource.
– It has some memory and often processing capabilities.
– Graphically, a node is rendered as a cube, usually including
only its name.
upendra.verma@nmims.edu
psg/21
Basic Building Blocks of UML – Things –
Behavioral
• Behavioral
– These are dynamic parts of UML model.
– These are verbs of a model.
– Represents behavior over time and space.
– There are two primary kinds of behavioral things
1. Interaction
2. State machine
upendra.verma@nmims.edu
psg/22
Basic Building Blocks of UML – Things –
Behavioral - Interaction
• Interaction
– It comprises a set of messages exchanged among set of
objects within a particular context to accomplish a specific
purpose.
– It includes messages, action sequences, and links.
– Graphically, a message is rendered as a directed line,
usually including name of its operation.
upendra.verma@nmims.edu
psg/23
Basic Building Blocks of UML – Things –
Behavioral – State Machine
• State Machine
– It is a behavior that specifies the sequence of state an
object or an interaction goes through during its lifetime in
response to events, together with its responses to those
events.
– It includes events and activities.
– Graphically, a state is rendered as a rounded rectangle,
usually including its name and its substates.
upendra.verma@nmims.edu
psg/24
Basic Building Blocks of UML – Things –
Grouping
• Grouping
– These are the organizational parts of UML model.
– There is one primary kind of grouping thing, namely,
packages.
– Package
– It is a general purpose mechanism for organizing element
into groups.
– Structural, behavioral and grouping things may be placed in
a package.
– Graphically, a package is rendered as a tabbed folder,
usually including only its name and sometimes its contents.upendra.verma@nmims.edu
psg/25
Basic Building Blocks of UML – Things –
Annotational
• Annotational
– These are the explanatory parts of UML model.
– These are the comments.
– There is one primary kind of annotational thing, called a
note.
– Note
– It’s a symbol for rendering constraints and comments
attached to an element or a collection of elements.
– Graphically, a note is rendered as a rectangle with a dog-
eared corner, together with a textual or graphical comment.
upendra.verma@nmims.edu
psg/26
Basic Building Blocks of UML –
Relationships
• Relationships
– It tie things together.
– There are four kinds of relationships in the UML.
1. Dependency
2. Association
3. Generalization
4. realization
upendra.verma@nmims.edu
psg/27
Basic Building Blocks of UML –
Relationships - Dependency
• Dependency
– It is a semantic relationship between two things in which a
change to one thing may affect the semantics of the other
things.
– Graphically, a dependency is rendered as a dashed line,
possibly directed, and occasionally including a label.
upendra.verma@nmims.edu
psg/28
Basic Building Blocks of UML –
Relationships - Association
• Association
– It is a structural relationship that describes a set of links, a
link being a connection among objects.
– Aggregation is a special kind of association representing a
structural relationship between a whole and its parts.
– Graphically, an association is rendered as a solid line,
possibly directed, occasionally including a label, and often
containing multiplicity and role names.
upendra.verma@nmims.edu
Association
psg/29
Teacher
Aggregation
Student
1 Guides *
Teacher
DepartmentInstitute
1 *
upendra.verma@nmims.edu
psg/30
• An association is a bi-directional connection between classes
– An association is shown as a line connecting the related classes
• An aggregation is a stronger form of relationship where the relationship is
between a whole and its parts
– An aggregation is shown as a line connecting the related classes with a
diamond next to the class representing the whole
• A dependency relationship is a weaker form of relationship showing a
relationship between a client and a supplier where the client does not have
semantic knowledge of the supplier
• A dependency is shown as a dashed line pointing from the client to the
supplier
upendra.verma@nmims.edu
Relationships - contd..
• An association class is an association that also has class properties(or aclass has association properties)
• A constraint is a semantic relationship among model elements thatspecifies conditions and propositions that must be maintained as true:otherwise, the system described by the model is invalid
• An interface is a specifier for the externally visible operations of a classwithout specification of internal structure. An interface is formallyequivalent to abstract class with no attributes and methods, only abstractoperations.
• A qualifier is an attribute or set of attributes whose values serve topartition the set of instances associated with an instance across anassociation.
psg/31upendra.verma@nmims.edu
Association
psg/32
Teacher
Navigation
Aggregation
StudentGuide RS
1 Guides *
Teacher
DepartmentInstitute
1 *
upendra.verma@nmims.edu
Association Vs Composition
psg/33
Page Frame
1 *
Page Frame
1 *
Page Frame
1 *
Window
Header SliderMenu
upendra.verma@nmims.edu
Dependency
psg/34
Window Button
uses
SalaryEmployee
access
upendra.verma@nmims.edu
Association Classes
psg/35
CourseTeacher
Offering
No of students
Venue
Slot number
1 Teaches *
Company Employee
Job
Designation
Salary
1 employs *
upendra.verma@nmims.edu
psg/36
Realization
AccountImpl
<interface>
Iaccount
Deposit()
withdraw()
upendra.verma@nmims.edu
psg/37
Basic Building Blocks of UML –
Relationships - Generalization
• Generalization
– It is a specialization/generalization relationship in which
objects of the specialized elements are substitutable for
objects of the generalized element.
– The child share the structure and the behavior of the parent.
– Graphically, a generalization is rendered as a solid line with
a hollow arrowhead pointing to the parent.
upendra.verma@nmims.edu
psg/38
Superclass, Subclass, or Inheritance comes into picture in
generalization/Specialization.
Generalization/Specialization
upendra.verma@nmims.edu
psg/39
Generalization/Specialization..Continued
Bees and grasshoppers are specialized versions of an insect
upendra.verma@nmims.edu
psg/40
Basic Building Blocks of UML –
Relationships - Realization
• Realization
– It is a semantic relationship between classifier, wherein one
classifier specifies a contract that another classifier
guarantees to carry out.
– Realization encounter in two places –
• Between interfaces and the classes or components that
realize them
• Between use cases and the collaborations that realize them.
upendra.verma@nmims.edu
psg/41
Realization
AccountImpl
<interface>
Iaccount
Deposit()
withdraw()
upendra.verma@nmims.edu
psg/42
Basic Building Blocks of UML – Diagrams
• Diagrams
– It is the graphical presentation of a set of elements, most
often rendered as a connected graph of vertices (things)
and arcs (relationships).
– UML includes nine different diagrams.
upendra.verma@nmims.edu
UML Diagrams• Use Case diagram
For High level business scenarios
• Sequence diagram or Collaboration diagram
For detailed activities within a scenario
• Class diagram
For a view of the static structure of the system
• State chart diagram and Activity Diagram
For classes with a dynamic behavior
• Component diagrams
For describing organization and dependencies among software components
• Deployment diagrams
For describing the configuration of resource elements and mapping of software implementation components on to them
• Package diagram
For Modules
psg/43upendra.verma@nmims.edu
Model Views and UML
Diagrams
psg/44
•Use Case
User View
Behavioral View
•Sequence
•Collaboration
•State Chart
•Activity
Structural View
•Class
•Object
Implementation View
•Component
Environment View
•Deployment
User view
* Use
case
upendra.verma@nmims.edu
Library Management System- A Case Study
The Library has:
• three categories of members
• a librarian and assisting staff
• an accounts section
The Library Management System should provide the following functionality:
• borrowing and returning of books
• querying, reserving and recommending books
• acquiring books
• issuing overdue notices to members
psg/45upendra.verma@nmims.edu
…Use Case Diagram
• Represent the interaction between users and the system
• Identifies users (roles) and external systems
• Determines the functional scope of the package (module)
psg/46upendra.verma@nmims.edu
Use Case Diagram Notation
psg/47
Actor
Association
Use Case
Use case with Extension points
<<Uses>>
<<Extends>>
upendra.verma@nmims.edu
Use Case Diagram
psg/48upendra.verma@nmims.edu
Use case diagram for RMS
49upendra.verma@nmims.edu
Interaction Diagram
• Interaction diagrams describe how use cases are
realized as interactions among objects
• Show classes, objects, actors and messages
between them to achieve the functionality of a
UseCase
• Two types of interaction diagrams– Sequence diagrams
– Collaboration diagrams
psg/50upendra.verma@nmims.edu
..Sequence Diagram
• Is used to elaborate a use case
• Describes a scenario - it is normal that a use
case has multiple scenarios
• Helps to describe the expected system
behavior to a user
• Follows an event from inception to
completion of processing by the system
psg/51upendra.verma@nmims.edu
Sequence Diagram Notation
psg/52
Actor
Class
Synchronous message
Asynchronous message
Return message
Focus of Control
lifeline
Termination
upendra.verma@nmims.edu
Sequence Diagram
psg/53
Library
member UI Member Book Copy
upendra.verma@nmims.edu
..Collaboration Diagram
• describes interactions among Classes (
objects)
• can be drawn instead of a sequence diagram
• Message sequencing is shown using
sequence numbers
psg/54upendra.verma@nmims.edu
Collaboration Diagram Notation
psg/55
Class
Messages with
sequence
numbers
( “Collaborates
with Class”)
Actor
upendra.verma@nmims.edu
Collaboration Diagram
psg/56upendra.verma@nmims.edu
..Class Diagram• Shows the static structure of the system -
classes and their relationships
• Classes– structure (attributes)
– behavior (operations)
• Relationships– Association, aggregation, dependency, and
inheritance
– Multiplicity and navigation indicators
– names
psg/57upendra.verma@nmims.edu
Class Diagram Notation
psg/58
4
5
Class
Class with a compartment
Realizes Interface
Interface
Constraint
Nary Association
Binary Association
1
2
3
4
5
6
7
upendra.verma@nmims.edu
Class Diagram
psg/59
Library
Book
no
VisibilityAttribute TypeScopeInitVal
Title a
Author a
Publisher a
Subject a
Keywords a
edition a
Price a
CopyInLib
VisibilityAttribute TypeScopeInitVal
isReference a
accessionNo a
isIssued a
copyNo a
Librarian
LibraryMember
VisibilityAttribute TypeScopeInitVal
name a
memberId a
Accountant
OrderInfo
VisibilityAttribute TypeScopeInitVal
supplierId a
NoOfCopies a
hasBooks1*
hasCopies
1
*
hasLibrarian
1
1
borrows1
0..5
hasMembers
1
0..200
orders
1
*
upendra.verma@nmims.edu
Relationships
psg/60
• An association is a bi-directional connection between classes
– An association is shown as a line connecting the related classes
• An aggregation is a stronger form of relationship where the relationship is
between a whole and its parts
– An aggregation is shown as a line connecting the related classes with a
diamond next to the class representing the whole
• A dependency relationship is a weaker form of relationship showing a
relationship between a client and a supplier where the client does not have
semantic knowledge of the supplier
• A dependency is shown as a dashed line pointing from the client to the
supplier
upendra.verma@nmims.edu
Relationships - contd..• An association class is an association that also has class
properties(or a class has association properties)
• A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true: otherwise, the system described by the model is invalid
• An interface is a specifier for the externally visible operations of a class without specification of internal structure. An interface is formally equivalent to abstract class with no attributes and methods, only abstract operations.
• A qualifier is an attribute or set of attributes whose values serve to partition the set of instances associated with an instance across an association.
psg/61upendra.verma@nmims.edu
Association
psg/62
Teacher
Navigation
Aggregation
StudentGuide RS
1 Guides *
Teacher
DepartmentInstitute
1 *
upendra.verma@nmims.edu
Association Vs Composition
psg/63
Page Frame
1 *
Page Frame
1 *
Page Frame
1 *
Window
Header SliderMenu
upendra.verma@nmims.edu
Dependency
psg/64
Window Button
uses
SalaryEmployee
access
upendra.verma@nmims.edu
Association Classes
psg/65
CourseTeacher
Offering
No of students
Venue
Slot number
1 Teaches *
Company Employee
Job
Designation
Salary
1 employs *
upendra.verma@nmims.edu
psg/66
Realization
AccountImpl
<interface>
Iaccount
Deposit()
withdraw()
upendra.verma@nmims.edu
Qualifier
psg/67
Bank
Customer
Account #
*
*
Factory
Itemproduced
Item #
*
1
upendra.verma@nmims.edu
..State Chart DiagramA state chart (transition) diagram is used to
show
– The life history of a given class, UseCase,
operation
– The events that cause a transition from one state to
another
– The actions that result from a state change
State transition diagrams are created for objects
with significant dynamic behavior
psg/68upendra.verma@nmims.edu
State Chart Diagram Notation
psg/69upendra.verma@nmims.edu
State Chart Diagram
psg/70upendra.verma@nmims.edu
..Activity DiagramActivity diagrams are similar to State Chart
diagrams.
However they describe the behavior of a Class in
response to internal processing.
• Transitions are triggered by completion of activity
• For describing behavior of Use Cases or operations
psg/71upendra.verma@nmims.edu
Activity Diagram Notation
psg/72upendra.verma@nmims.edu
Activity Diagram
psg/73upendra.verma@nmims.edu
..Component Diagram
• Describe organization and dependency
between the software implementation
components
• Components are distributable physical units
-e.g. source code, object code.
psg/74upendra.verma@nmims.edu
Component Diagram Notation
psg/75
Component
Dependency
upendra.verma@nmims.edu
Component Diagram
psg/76upendra.verma@nmims.edu
..Deployment Diagram
• Describe the configuration of processing
resource elements and the mapping of
software implementation components onto
them
• contain components - e.g. object code, source
code, and nodes - e.g. printer, database, client
machine
psg/77upendra.verma@nmims.edu
Deployment Diagram Notation
psg/78
Component
Interface
Dependency
Node
Connector
upendra.verma@nmims.edu
Deployment Diagram
psg/79
LibClient2
ClientLibrarian
LibClient1
LibServer
LibMgmtSys
ClientMember
tcp-ip tcp-ip
upendra.verma@nmims.edu
…Package Diagram
A Package is :
• an application view
• exploded into a set of modules
• linked to the diagrams that model that application view
psg/80upendra.verma@nmims.edu
Package Diagram Notation
psg/81
Container package
Package
Dependency
Generalization
upendra.verma@nmims.edu
Package Diagram
psg/82upendra.verma@nmims.edu
psg/83upendra.verma@nmims.edu
Modeling Process
• Break up the system into packages. Draw a high level Package Diagram for the system.
• Draw Use Case diagrams for each package
• Analyze each use case in detail - identifying variations, common use cases, scenarios of interest
• Draw a Sequence /Collaboration diagram for each scenario
psg/84upendra.verma@nmims.edu
.. Modeling Process
• Draw a Class Diagram for each package
– classes will be shared across the entire
application model
– a class will be owned by a “package” - others
will use it
• Refine the inheritance hierarchy (this will
be across the application)
• Identify attributes and keys for the classes
psg/85upendra.verma@nmims.edu
..Modeling Process
Draw
• State Chart Diagrams or Activity Diagrams for classes that exhibit a significantly dynamic behavior
• Component Diagrams to elucidate the intercomponent dependencies
• Deployment Diagrams to describe the configuration of resource elements and mapping of the software implementation components onto them
psg/86upendra.verma@nmims.edu