Introducing the UML and UML Diagrams
1
What is UML?
• Is a language. It is not simply a notation for drawing diagrams, but a
complete language for capturing knowledge(semantics) about a subject and
expressing knowledge(syntax) regarding the subject for the purpose of
communication.
•
Applies to modeling and systems. Modeling involves a focus on
understanding a subject (system) and capturing and being able to
communicated in this knowledge.
•
It is the result of unifying the information systems and technology
industry’s best engineering practices (principals, techniques, methods and
tools).
• used for both database and software modeling
2
Overview of the UML
• The UML is a language for
– visualizing
– specifying
– constructing
– documenting
the artifacts of a software-intensive system
3
Overview of the UML
• The UML is a language for
– visualizing
– specifying
– constructing
– documenting
the artifacts of a software-intensive system
4
Visual modeling (visualizing)
• A picture is worth a thousand words!
- Uses standard graphical notations
- Semi-formal
- Captures Business Process from enterprise information systems to
distributed Web-based applications and even to hard real time embedded
systems
Specifying
• building models that are: Precise, Unambiguous, Complete
• UML symbols are based on well-defined syntax and semantics.
• UML addresses the specification of all important analysis, design, and
implementation decisions.
5
Constructing
• Models are related to OO programming languages.
• Round-trip engineering requires tool and human intervention to avoid
information loss
– Forward engineering — direct mapping of a UML model into code.
– Reverse engineering — reconstruction of a UML model from an
implementation.
Documenting
– Architecture, Requirements, Tests, Activities (Project planning, Release
management)
6
Conceptual Model of the UML
» To understand the UML, you need to form a conceptual model
of the language, and this requires learning three major elements.
Elements:
1. Basic building blocks
2. Rules
3. Common Mechanisms
Basic Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building
blocks:
» Things
» Relationships
» Diagrams
7
Things in the UML
• There are four kinds of things in the UML:
1. Structural — nouns of UML models.
2. Behavioral — dynamic (verbal) parts of UML models.
3. Grouping — organizational parts of UML models.
4. Annotational — explanatory parts of UML models.
8
1.Structural Things
• These are the Nouns and Static parts of the model.
• These are representing conceptual or physical elements.
There are seven kinds of structural things:
1. Class
2. Interface
3. Collaboration
4. Use Case
5. Active Class
6. Component
7. Node
9
1.Class
2.Interface
Is a description of set of objects that
share the same attributes, operations
methods, relationships and
semantics.
Window
origin
size
open( )
close( )
move( )
A Simple Class
A collection of operations that
specify a service (for a resource
or an action) of a class or
component. It describes the
externally visible behavior of
that element
Name
Attributes
Operations
name
Iname
operations
<<interface>>
IWindow
open()
close()
A Simple Interface
10
3.Collaboration
–
–
–
–
–
Define an interaction among two or more classes.
Define a society of roles and other elements.
Provide cooperative behavior.
Capture structural and behavioral dimensions.
UML uses ‘pattern” as a synonym (careful)
Name
Behavior
4.Use Case
–
A sequence of actions that produce an observable result for a specific actor.
– A set of scenarios tied together by a common user goal.
– Provides a structure for behavioral things.
– Realized through a collaboration (usually realized by a set of actors and the
system to be built).
Place order
11
Heavy border
5. Active Class
– Special class whose objects own one or
more processes or threads.
– Can initiate control activity.
Name
attributes
operations
Event
Manager
Thread
time
suspend()
flush()
6. Component
•
•
•
•
•
Replaceable part of a system.
Components can be packaged logically.
Conforms to a set of interfaces.
Provides the realization of an interface.
Represents a physical module of code
7. Node
• Element that exists at run time.
• Represents a computational resource.
• Generally has memory and processing power.
Orderform.java
Web Server
12
2.Behavioral Things
• These are Verbs of UML models.
• These are Dynamic parts of UML models: “behavior over time and space”
• Usually connected to structural things in UML.
There are two kinds of Behavioral Things:
1.Interaction
• Is a behavior of a set of objects comprising of a set of messages exchanges
within a particular context to accomplish a specific purpose.
display
2.State Machine
• Is a behavior that specifies the sequences of states an object or an interaction
goes through during its lifetime in response to events, together with its
responses to those events.
Idle
Waiting
13
3.Grouping Things
• These are the organizational parts of the UML models.
There is one primary kind of group thing:
1.Packages
-
General purpose mechanism for organizing elements into groups.
Purely conceptual; only exists at development time.
Contains behavioral and structural things.
Can be nested.
Variations of packages are: Frameworks, models, & subsystems.
Business rules
14
4.Annotational Things
• These are Explanatory parts of UML models
• These are the Comments regarding other UML elements (usually called
adornments in UML)
There is one primary kind of annotational thing:
1.Note
A note is simply a symbol for rendering constraints and comments
attached to an element or collection of elements.
Is a best expressed in informal or formal text.
comments
15
Relationships
There are four kinds of relationships:
1. Dependency
2. Association
3. Generalization
4. Realization
» These relationships tie things together.
» It is a semantic connection among elements.
» These relationships are the basic relational building blocks of the UML.
16
1. Dependency
Is a semantic relationship between two things in which a change to one
thing (the independent thing) may affect the semantics of the other thing
( the dependent thing).
2. Association
Is a structural relationship that describes a set of links, a link being a
connection among objects.
employer
0..1
employee
*
17
Aggregation
» Is a special kind of association. It represents a structural
relationship between the whole and its parts.
» Represented by black diamond.
3. Generalization
Is a specialization/generalization relationship in which objects of the
specialized element (the child) are more specific than the objects of the
generalized element.
18
4. Realization
a semantic relationship between two elements, wherein one
element guarantees to carry out what is expected by the other
element.
Where?
Between interfaces and classes that realize them…
Between use cases and the collaborations that
realize them...
19
Diagrams
• A diagram is the graphical presentation of a set of elements.
• Represented by a connected graph: Vertices are things; Arcs are behaviors.
UML includes nine diagrams:
•
•
•
•
•
•
•
•
•
Use case Diagram
Class Diagram;
Object Diagram
Sequence Diagram;
Collaboration Diagram
Statechart Diagram
Activity Diagram
Component Diagram
Deployment Diagram
20
1.Class Diagram
• Class Diagrams describe the static structure of a system, or how it is
structured rather than how it behaves.
• A class diagram shows the existence of classes and their relationships in the
logical view of a system
These diagrams contain the following elements.
– Classes and their structure and behavior
– Association, aggregation, dependency, and inheritance
relationships
– Multiplicity and navigation indicators
– Role names
These diagrams are the most common diagrams found in O-O
modeling systems.
21
Examples:
Registration Form
Registration Manager
Student
Course
Course Offering
22
Example
23
2. Object Diagrams
• Shows a set of objects and their relationships.
• A static snapshot of instances.
• Object Diagrams describe the static structure of a system at a particular time.
Whereas a class model describes all possible situations, an object model
describes a particular situation.
Object diagrams contain the following elements:
Objects which represent particular entities. These are instances of
classes.
Links
which represent particular relationships between objects.
These are instances of associations.
Harry
(Student)
Name: “Harry Mat”
Major: CS
24
25
Use case diagrams
Use Case Diagrams describe the functionality of a system and users of the
system.
These diagrams contain the following elements:
Actors : which represent users of a system, including human
users and other systems.
Use Cases : which represent functionality or services
provided by a system to users.
Maintain Schedule
Registrar
Student
26
Example
27
Sequence Diagrams
Sequence Diagrams describe interactions among classes. These interactions
are modeled as exchange of messages.
These diagrams focus on classes and the messages they exchange to
accomplish some desired behavior. These are time ordering messages.
Sequence diagrams are a type of interaction diagrams.
Sequence diagrams contain the following elements:
Class roles: which represent roles that objects may play within the
interaction.
Lifelines
which represent the existence of an object over a period
of time.
Activations : which represent the time during which an object is
performing an operation.
Messages : which represent communication between objects.
28
Collaboration Diagram
Collaboration Diagrams describe interactions among classes and
associations. These interactions are modeled as exchanges of messages
between classes through their associations. Collaboration diagrams are a
type of interaction diagram. It is a structural organization of the objects than
are send and receive messages.
Collaboration diagrams contain the following elements.
Class roles: which represent roles that objects may play within the
interaction.
Association roles: which represent roles that links may play within
the interaction.
Message flows: which represent messages sent between objects via
links. Links transport or implement the delivery of
the message.
29
30
Statechart Diagrams
Statechart (or state) diagrams describe the states and responses of a class.
Statechart diagrams describe the behavior of a class in response to external
stimuli.
These diagrams contain the following elements:
States : which represent the situations during the life of an object in
which it satisfies some condition, performs some activity, or
waits for some occurrence.
Transitions: which represent relationships between the different
states of an object.
31
32
Activity Diagrams
Activity diagrams describe the activities of a class. These diagrams are
similar to statechart diagrams and use similar conventions, but activity
diagrams describe the behavior of a class in response to internal processing
rather than external events as in statechart diagram.
Swimlanes: which represent responsibilities of one or more objects for
actions within an overall activity; that is, they divide the
activity states into groups and assign these groups to objects
that must perform the activities.
Action States: which represent atomic, or noninterruptible, actions of
entities or steps in the execution of an algorithm.
Action flows: which represent relationships between the different action
states of an entity.
Object flows: which represent the utilization of objects by action states and
the influence of action states on objects.
33
34
Component Diagram
Component diagrams describe the organizations and dependencies among
software implementation components. These diagrams contain
components, which represent distributable physical units, including source
code, object code, and executable code.
These are static implementation view of a system.
Deployment Diagrams
Deployment diagrams describe the configuration of run-time processing
resource elements and the mapping of software implementation
components onto them. These diagrams contain components and nodes,
which represent processing or computational resources, including
computers, printers, etc.
35
Rules of the UML:
•
•
•
•
The UML building blocks can’t simply put together in a random fashion.
Like any language , the UML has a number of rules that specify what a
well-formed model should look like.
well-formed models
Is a model semantically self-consistent and in harmony with all its
related
models
Semantic rules for:
Names — what you can call things.
Scope — context that gives meaning to a name.
Visibility — how names can be seen and used.
Integrity — how things properly and consistently relate to one another.
Execution — what it means to run or simulate a dynamic model.
Avoid models
Elided — certain elements are hidden for simplicity.
Incomplete — certain elements may be missing.
Inconsistent — no guarantee of integrity.
36
Common Mechanisms:
• The UML is made simpler by the presence of some features called common
mechanisms.
There are four kinds of mechanisms;
1. Specifications: It provides a textual statement of the syntax and
semantics of the building blocks.
2. Adornments: It provides detail from an element’s specification added
to its basic graphical notation.
3. Common divisions: There is a division of class and object and also the
division of interface and implementation.
4. Extensibility mechanisms: The UML provides a standard language for
software blueprints. The UML is
opened,
making it possible to extend
the language in
controlled ways to
express all possible
nuances of all
models across all time.
37
The UML’s extensibility mechanisms include
Stereotypes can be used to extend the UML notational elements
(extends vocabulary.)
» Name shown in guillements <<stereotype>>
» Stereotypes may be used to classify and extend associations,
inheritance relationships, classes, and components
» Examples:
– Class stereotypes: boundary, control, entity,
utility, exception
– Inheritance stereotypes: includes and extends
– Component stereotypes: subsystem
Ex: << include>>, <<extend>>
38
Tagged values — extends properties of UML building
blocks,allowing you to create new information in that element
specification . Placed in braces beneath the name of the
element to which the property applies
Ex:
An Object: Class A
{location=server)
Constraints — extends the semantics of UML building blocks.it allow you to
add new rules or modify exesting rules.
A string placed in braces
Ex: {and}, {or}, {abc}
39
Architecture:
Visualizing, specifying, constructing, and documenting a software system
demands that the system be viewed from a number of perspectives.
A system’s architecture is perhaps the most important artifact that can be
used to manage these different viewpoints and so control the iterative and
incremental development of a system throughout of its lifecycle.
s/w architecture is not only concerned with structure and behavior , but also
it’s usage, functionality, performance, resilience, reuse, comprehensibility,
economic and technology constraints and trade-offs, and aesthetic concerns.
The below figure illustrates, the architecture of a system can be
described by five interlocking views.
40
Design
Design View
View
Classes,
Classes, interfaces,
interfaces,
collaborations
collaborations
Implementation
Implementation View
View
Components
Components
Use cases
Use cases
Use
Use Case
Case View
View
Process
Process View
View
Deployment
Deployment View
View
Active
Active classes
classes
Nodes
Nodes
Modeling a system’s architecture
41
Use case view
Encompasses the use cases that describes the behavior of the system as seen by its end
users, analysts, and testers
Design view
Encompasses the classes, interfaces, and collaborations that form the vocabulary of the
problem and its solution
Process view
Shows the flow of control among its various parts, including possible concurrency and
synchronization mechanisms
Implementation view
Encompasses the artifacts that are used to assemble and release the physical
system
Deployment view
Encompasses the nodes that form the system’s hardware topology on which the system
executes
42
Software Development Life Cycle
The UML is largely process- independent
To get the most benefit from the UML, you should consider a process that is
– Use case driven — use cases are primary artifact for defining
behavior of the system for verifying and
validating the system’s architecture, for
testing, and for communicating among the
stakeholders of the project. .
– Architecture-centric — the system’s architecture is primary
artifact for conceptualizing, constructing,
managing, and evolving the system under
development.
– Iterative— managing streams of executable releases.
43
Incremental
One that involves the continuous integration of the system’s
architecture to produce these releases
This process is furthurly can be broken into phases.
A Phase is the span of time between two major milestones of the
process
44
Lifecycle Phases
Inception
Elaboration
Construction
Transition
time
• Inception
– Define the scope of the project and develop business case
– Deliver the product to its users
• Elaboration
– Plan project, specify features, and baseline the architecture
• Construction
– Build the product
• Transition
– Turned over to the user community `
45
46
Advantages of UML
• You can model just about any type of application, running on any type and
combination of hardware, operating system, programming language, and
network, in UML.
• Used for modeling middleware
• Built upon the MOF™ metamodel for OO modeling
• UML Profiles (that is, subsets of UML tailored for specific purposes) help
you model Transactional, Real-time, and Fault-Tolerant systems in a natural
way.
• UML is effective for modeling large, complex software
systems
• It is simple to learn for most developers, but provides
advanced features for expert analysts, designers and architects
• It can specify systems in an implementation-independent manner
• 10-20% of the constructs are used 80-90% of the time
• Structural modeling specifies a skeleton that can be refined
and extended with additional structure and behavior
• Use case modeling specifies the functional requirements of
system in an object-oriented manner
47
Advanced Classes
*
Classes are certainly the most important building block of any
object-oriented system.
*
Classes are just one kind of an even more general building
block in the UML-classifiers.
*
A classifier is a mechanism that describes structural and
behavioral features.
* Classifier include classes, interfaces, datatypes, signals,
components, nodes, usecases, and subsystems.
* The most important kind of classifier in the UML is the class.
*
A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics.
48
The UML provides a number of other kinds of classifiers to help you model.
■ Interface
A collection of operations that are used to specify a service of a class or a
component.
■ Datatype
A type whose values have no identiy, including primitive built-in types(such as
numbers and strings), as well as enumeration types (such as booleans).
■ Signal
The specification of an asynchronous stimulus communicated between
instances.
■ Component
A physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces.
■ Node
A physical element that exists at run time and that represents a computational
resource, generally having at least some memory and often processing
capability.
■ Use case
A description of a set of a sequence of actions, including variants, that a system
performs that yields an observable result of value to a particular actor.
■ Subsystem
A grouping of elements of which some constitute a specification of the behavior
offered by the other contained elements.
49
UML provides a representation for a number of advanced properties.
They are
■ Visibility
■ Scope
■ Visibility:
One of the most important details for a classifier’s attributes and operations is
its visibility. i.e. it specifies whether it can be used by the other classifiers.
In general we have three levels of visibility.
1. Public
Any outside classifier with visibility to the given classifier
can use the feature. Represented by the symbol ‘+’.
2. Private
Only the classifier itself can use the feature. Represented by
the symbol ‘-’.
3. Protected
Any descendant of the classifier can use the feature.
Represented by the symbol ‘#’
Protected
Toolbar
Public
Private
Protected
# Currentselection : Tool ●
# toolcount : integer ●
● + Pick item(i: int)
● - Compact()
● # check orphans()
50
■ scope
Another important detail you can specify for a classifier’s attributes and
operations is its owner scope.
The owner scope of a feature specifies whether the feature appears in each
instance of the classifier or whether there is just a single instance of the feature
for all instances of the classifier.
In UML we have two kinds of owner scope.
1. Instance
2. Classifier
Each instance of the classifier holds its own value
for the feature.
There is just one value of the feature for all
instances of the classifier.
Frame
Class scope
Instance scope
Header : FrameHeader ●
● uniqueID : Long
51
Advanced Relationships
♦ A relationship is a connection among things.
♦ Graphically, a relationship is rendered as a path, with
diffferent kinds of lines used to distinguish the different
relationships
1.Dependency
Is a using relationship.
Apply dependencies when you want to show one thing
using another.
For details UML defines a number of stereotypes that
may be applied to dependency relationships.
There are 17 kinds of stereotypes, but these are can be
organized into six groups.
52
The First eight stereotypes that apply to dependency relationships among classes and
objects in class diagrams.
1.bind
The Source instantiates the target template using the given
actual parameters.
2.derive
The Source may be computed from the target.
3.friend
The Source is given special visibility into the target.
4.instanceof
The Source object is an instance of the target classifier.
5.instantiate
The Source creates instances of the target.
6.powertype
The Target is a powertype of the source. A powertype is a
classifier whose objects are all the children of a given parent.
7.refine
The Source is at a finer degree of abstraction than the target.
8.use
The semantics of the Source element depends on the
semantics of the public part of the target.
53
The next two stereotypes are that apply to dependency relationships among packages.
1.access
The source package is granted the right to reference the elements of
the target package.
2.import
A kind of access that specifies that the public contents of the target
package enter the flat namespace of the source, as if they
declared in the source.
had been
The next two stereotypes apply to dependency relationships among usecases.
1.extend
Specifies that the target use case extends the behavior of the source.
2.include
Specifies that the source use case explicitly incorporates the behavior
of another use case at a location specified by the source.
The next three stereotypes when modeling interactions among objects.
1.become
Specifies that the target is the same object as the source but at a later
point in time and with possibly different values, states, or
roles.
54
2.call
Specifies that the source operation invokes the target
operation.
3.copy
Specifies that the target object is an exact, but independent,
copy of the source
The next stereotype will useful in the context of state machines.
1.send
Specifies that the source operation sends the target event.
The next stereotype will useful in modeling the context of organizing the
elements of your system into subsystems and models is .
1.trace
Specifies that the target is an historical ancestor of the source.
55
Generalization
A generalization is a relationship between a general thing and a more
specific kind of that thing.
UML defines one Stereotype and four Constraints.
First, there is one stereotype.
1.implementation
Specifies that the child inherits the implementation of
the parent but does not make public nor support its
interfaces, thereby violating substitutability.
Four standard constraints are
1.complete
2.incomplete
Specifies that all children in the generalization have
been specified in the model and that no additional children
are permitted.
Specifies that not all children in the generalization have been
specified and that additional children are permitted.
56
3.disjoint
Specifies that objects of the parent may have no more than
one of the children as a type.
4.overlapping
Specifies that objects of the parent may have more than one of
the children as a type.
57
Association
An association is a structural relationship.
It specifies that objects of one thing are connected to objects of
another.
It is represented as a solid line connecting the same or different
classes.
You use associations when you want to show structural
relationships.
There are four basic adornments that apply to an association.
1. Name
2. Role
3. Multiplicity
4. Aggregation
You can use these adornments at each end of the association.
58
name
0…1
multiplicity
• Employs
End
e: employer
• * End
• employee
role name
1.Name
An association can have name
You use that name to specify the nature of the relationship.
2.Role
When a class participates in an association, it has a specific role that it plays in
that relationship.
3.Multiplicity
In many modeling situations, it’s important to state how many objects may
be connected across an instance of an association.
Represented with (0…1), (0….*) and (1…..*).
4.Aggregation
Is a “part-of” or “whole” or “has a” relationship
59
Advanced Features:
For advanced uses, there are a number of other properties are defined.
1. Navigation
2. Qualification
3. Interface Specifier
4. Association Class
5. Composition
6. Visibility
Association
End
0…1
e: employer
Navigation
• * •
End
• employee
Interface Specifier
60
1.Navigation
Is a bidirectional association.
In some cases you will use unidirection.
2. Interface Specifier
An interface is a collection of operations that are used to specify a service of
class or a component. Every class may realize many interfaces.
a
Collectively, the interfaces realized by a class represent a complete
specification of the behavior of that class.
3. Association Class
An association class has properties of both an association and a class.
4.Qualification
In modeling association one of the most common modeling idioms you’ll
encounter is the problem of lookup.
To overcome this problem an association creates qualifier at source object.
An association attribute whose values partition the set of objects related to an object
across an association.
The source object, together with the values of the qualifier’s attributes ,yield a target
object.
61
5.Composition
Composition is a special form of aggregation within which the parts are
inseparable from the whole.
UML defines five constraints that may be applied to association relationships.
1. Implicit
It decides whether the association is real or conceptual.
Specifies that the relationship is not manifest but, rather, is only conceptual
2. Ordered
Specifies that the set of objects at one end of an association are in explicit
order
3.Changeable
Links between objects may be added, removed, and changed freely.
4.Addonly
New links may be added from an object on the opposite end of the
association
5. Frozen
A link, once added from an object on the opposite end of the association,
may not be modified or deleted.
62
INTERFACES
An interface is a collection of operation that are used to specify a
services of a class or a component.
Interfaces may also be used to specify a contract for a use case
or subsystem.
ISpell
interfaces
IUnknown
Order form. java
63
♦ Names
Every interface must have a name that distinguishes it from
others.
A simple name is the name of the interface alone.
A path name is the interface name prefixed by the name of
the package in which the interfaces lives.
An interface may be showing only its name.
IUnknown
ISensor
ISpell
Networking::IRouter
64
♦ Operations
Interfaces do not specify any structure (attributes).
They do not specify any implementation.
Like a class, an interface may have any number of
operations.
An interface can be visualized as a circle or as a stereotyped
class, listing its operations in appropriate
compartment.
Stereotyped
Name
<<interface>>
Course
Add( )
Update( )
Delete( )
Operations
65
♦ Relationships
Like a class an interface may participate in different
relationships.
An interface may also participate in a realization
relationship.
A class that realizes an interface must provide a set of
methods that implement the operations defined in the
interface.
♦ Types and Roles
A type is a stereotype of a class used to specify a domain
of objects , together with the operations applicable to the
object.
A role is the behavior of an entity participating in a particular
context.
66
PACKAGES
A package is a general-purpose mechanism for organizing
elements of a model, such as classes or diagrams, into
groups.
♦ Names
Every package must have a name that distinguishes it from
others.
A simple name is the name of the package alone.
A path name is the package name prefixed by the name of
the package in which the interfaces lives.
A package may be showing only its name.
A package may own other elements.
Simple name
Business rules
Sensors::vision
67
♦ Visibility
same like as classes.
♦ Importing and Exporting
Importing grants a one-way permission for the elements in one
package to access the elements of the other.
An import relationships is a dependency adorned by the stereotype
import.
The public parts of a package are called its exports.
The parts that one package exports are visible only to the contents
of those packages that explicitly import the package.
Refer text book 12-4 diagram
68
69
♦ Generalization
It is used to specify a family of packages.
Refer text book 12-5 diagram
70
INSTANCES
Every instance must have a name that distinguishes it from
others.
Refer text book 13-2 diagram
71