Beruflich Dokumente
Kultur Dokumente
Lecture Notes
On
UML
UNIT-IV
UML DIAGRAMS: TERMS AND CONCEPTS, RELATIONSHIP, DIAGRAMS.
ADVANCED CLASS DIAGRAM: ADVANCED RELATIONSHIP, INTERFACE TYPES
AND RULES, PACKAGES COMMON MODELLING TECHNIQUES, MODELLING
GROUPS ELEMENTS, MODELLING ARCHITECTURAL VIEWS. - INSTANCES AND
OBJECT DIAGRAMS: MODELLING CONCRETE/PROTOTYPICAL INSTANCES.
LINKS, OBJECTS INTERATION. -COLLABORATIONS, USE CASES,
INTERACTION DIAGRAMS, STATE TRANSITION DIAGRAMS. –
ARCHITECTURAL MODELLING: COMPONENT DIAGRAM, DEPLOYMENT
DIAGRAM, PATTERN AND FRAME WORK.
UML Diagrams:
In UML 2.0 there are 13 types of diagrams. To understand them, it is
sometimes useful to categorize them hierarchically:
Structure Diagrams emphasize what things must be in the system being
modeled:
Class diagram
Component diagram
Composite structure diagram
Deployment diagram
Object diagram
Package diagram
Behavior Diagrams emphasize what must happen in the system being
modeled:
Activity diagram
State Machine diagram
Use case diagram
Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of
control and data among the things in the system being modeled:
Interaction overview diagram (UML 2.0)
*Communication diagram (Collaboration Diagram)
Sequence diagram
UML Timing Diagram (UML 2.0)
Class Diagrams:
A Class defines the attributes and the methods of a set of objects. All objects
of this class (instances of this class) share the same behavior, and have the
same set of attributes (each object has its own set).
The term “Type” is sometimes used instead of Class, but it is important to
mention that these two are not the same, and Type is a more general term. In
UML, Classes are represented by rectangles, with the name of the class, and
can also show the attributes and operations of the class in two other
“compartments” inside the rectangle.
Graphical Notation, example:
POS System
Advanced Classes:
Classes are indeed the most important building block of any object-oriented
system. However, 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. Classifiers include classes, interfaces,
datatypes, signals, components, nodes, use cases, and subsystems.
Classifiers (and especially classes) have a number of advanced features
beyond the simpler properties of attributes and operations described in the
previous section: You can model multiplicity, visibility, signatures,
polymorphism, and other characteristics. In the UML, you can model the
semantics of a class so that you can state its meaning to whatever degree of
formality you like.
In the UML, there are several kinds of classifiers and classes; it's important
that you choose the one that best models your abstraction of the real world.
Advance Classes
The UML provides a representation for a number of advanced properties, as
Figure shows. This notation permits you to visualize, specify, construct, and
document a class to any level of detail you wish, even sufficient to support
forward and reverse engineering of models and code.
Classifiers:
Visibility:
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 the UML, you
can specify two kinds of owner scope.
Component Diagram:
Component diagrams show the organization and dependencies among a
group of components. Component diagrams comprise of:
Components
Interfaces
Relationships
Example
Part:
A part is an element that represents a set of one or more instances which are
owned by a containing classifier instance. So for example, if a diagram
instance owned a set of graphical elements, then the graphical elements could
be represented as parts; if it were useful to do so, to model some kind of
relationship between them. Note that a part can be removed from its parent
before the parent is deleted, so that the part isn't deleted at the same time.
A part is shown as an unadorned rectangle contained within the body of a
class or component element.
Port:
A port is a typed element that represents an externally visible part of a
containing classifier instance. Ports define the interaction between a classifier
and its environment. A port can appear on the boundary of a contained part, a
class or a composite structure. A port may specify the services a classifier
provides as well as the services that it requires of its environment.
A port is shown as a named rectangle on the boundary edge of its owning
classifier.
Interfaces:
An interface is similar to a class but with a number of restrictions. All interface
operations are public and abstract, and do not provide any default
implementation. All interface attributes must be constants. However, while a
class may only inherit from a single super-class, it may implement multiple
interfaces.
An interface, when standing alone in a diagram, is either shown as a class
element rectangle with the «interface» keyword and with its name italicized to
denote it is abstract, or it is shown as a circle.
Note that the circle notation does not show the interface operations. When
interfaces are shown as being owned by classes, they are referred to as
exposed interfaces. An exposed interface can be defined as either provided or
required. A provided interface is an affirmation that the containing classifier
supplies the operations defined by the named interface element and is defined
by drawing a realization link between the class and the interface. A required
interface is a statement that the classifier is able to communicate with some
other classifier which provides operations defined by the named interface
element and is defined by drawing a dependency link between the class and
the interface.
A provided interface is shown as a "ball on a stick" attached to the edge of a
classifier element. A required interface is shown as a "cup on a stick" attached
to the edge of a classifier element.
Delegate:
A delegate connector is used for defining the internal workings of a
component's external ports and interfaces. A delegate connector is shown as
an arrow with a «delegate» keyword. It connects an external contract of a
component as shown by its ports to the internal realization of the behavior of
the component's part.
Collaboration:
Collaboration defines a set of co-operating roles used collectively to illustrate
a specific functionality. Collaboration should only show the roles and attributes
required to accomplish its defined task or function. Isolating the primary roles
is an exercise in simplifying the structure and clarifying the behavior, and also
Role Binding:
A role binding connector is drawn from collaboration to the classifier that
fulfils the role. It is shown as a dashed line with the name of the role at the
classifier end.
Represents:
A represents connector may be drawn from collaboration to a classifier to
show that collaboration is used in the classifier. It is shown as a dashed line
with arrowhead and the keyword «represents».
Occurrence:
An occurrence connector may be drawn from collaboration to a classifier to
show that collaboration represents the classifier. It is shown as a dashed line
with arrowhead and the keyword «occurrence».
Deployment diagram:
A deployment diagram puts emphasis on the configuration of runtime
processing nodes and their components that live on them. They are
commonly comprised of nodes and dependencies, or associations between
the nodes. Deployment diagrams are used to:
Model devices in embedded systems that typically comprise of software-
intensive collection of hardware.
Represent the topologies of client/server systems.
Model fully distributed systems.
Example
The following figure shows the topology of a computer system that follows
client/server architecture. The figure illustrates a node stereotyped as server
that comprises of processors. The figure indicates that four or more servers
are deployed at the system. Connected to the server are the client nodes,
where each node represents a terminal device such as workstation, laptop,
scanner, or printer. The nodes are represented using icons that clearly depict
the real-world equivalent.
Object Diagram:
An object diagram models a group of objects and their links at a point of
time. It shows the instances of the things in a class diagram. Object diagram
is the static part of an interaction diagram.
Package Diagram:
Package diagrams are used to reflect the organization of packages and their
elements. When used to represent class elements, package diagrams provide
a visualization of the namespaces. The most common use for package
diagrams is to organize use case diagrams and class diagrams, although the
use of package diagrams is not limited to these UML elements.
The following is an example of a package diagram.
so has a unique name or type. The package must show the package name and
can optionally show the elements within the package in extra compartments.
Package Merge:
A «merge» connector between two packages defines an implicit generalization
between elements in the source package, and elements with the same name
in the target package. The source element definitions are expanded to include
the element definitions contained in the target. The target element definitions
are unaffected, as are the definitions of source package elements that don't
match names with any element in the target package.
Package Import:
The «import» connector indicates that the elements within the target
package, which in this example is a single class, use unqualified names when
being referred to from the source package. The source package's namespace
gains access to the target classes; the target's namespace is not affected.
Nesting Connectors:
The nesting connector between the target package and source packages
shows that the source package is fully contained in the target package.
Behavior Diagrams:
Activity diagram:
Overview:
Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It
captures the dynamic behavior of the system. Other four diagrams are used
to show the message flow from one object to another but activity diagram is
used to show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only
used for visualizing dynamic nature of a system but they are also used to
construct the executable system by using forward and reverse engineering
techniques. The only missing thing in activity diagram is the message part.
It does not show any message flow from one activity to another. Activity
diagram is some time considered as the flow chart. Although the diagrams
looks like a flow chart but it is not. It shows different flow like parallel,
branched, concurrent and single.
Activities
Association
Conditions
Constraints
Once the above mentioned parameters are identified we need to make a
mental layout of the entire flow. This mental layout is then transformed into
an activity diagram.
The following is an example of an activity diagram for order management
system. In the diagram four activities are identified which are associated with
conditions. One important point should be clearly understood that an activity
KHALID AMIN AKHOON 21
Subject: OOAD Semester: 8TH Course No: CSE-802
diagram cannot be exactly matched with the code. The activity diagram is
made to understand the flow of activities and mainly used by the business
users.
The following diagram is drawn with the four main activities:
Send order by the customer
Receipt of the order
Confirm order
Dispatch order
After receiving the order request condition checks are performed to check if it
is normal or special order. After the type of order is identified dispatch
activity is performed and that is marked as the termination of the process.
o Transitions
o Objects
Action states represent the non interruptible actions of objects which can’t be
further decomposed & takes insignificant execution time.
There is no notational distinction between action & activity states, except that an
activity state may have additional parts, such as entry & exit action.
Action Flow:
Object Flow:
An object flow arrow from an action to an object means t hat the action creates or
influences the object.
An object flow arrow from an object to an action indicates that the action state
uses the object.
Branching:
The basic usage of activity diagram is similar to other four UML diagrams.
The specific usage is to model the control flow from one activity to another.
This control flow does not include messages.
The activity diagram is suitable for modeling the activity flow of the system.
An application can have multiple systems. Activity diagram also captures
these systems and describes flow from one system to another. This specific
usage is not available in other diagrams. These systems can be database,
external queues or any other system.
Now we will look into the practical applications of the activity diagram. From
the above discussion it is clear that an activity diagram is drawn from a very
high level. So it gives high level view of a system. This high level view is
mainly for business users or any other person who is not a technical person.
This diagram is used to model the activities which are nothing but business
requirements. So the diagram has more impact on business understanding
rather implementation details.
State-chart diagrams are used for modeling objects which are reactive in
nature.
Example
Purchase Drink
Use cases
Actors
Use-Case:
Is an abstraction of a set of sequences that yield some functionality?
Represents some user-visible function.
Is always initiated by an “actor”.
Describes the interaction between the actors and the system for a
system function.
Achieves a discrete goal for the actor.
Use Case B extends Use Case A when Use Case B describes the
behavior of Use Case A under a particular condition.
Use Case A uses (or “uses”) Use Case B when Use Case B is a
behavior/functionality that is required by Use Case A. That
behavior has been factored out into a separate Use Case because
it is required across several use cases.
Example:
Interaction Element:
Interaction elements are similar to interaction occurrences, in that they
display a representation of existing interaction diagrams within a rectangular
frame. They differ in that they display the contents of the references diagram
inline.
Interaction Diagrams:
Interaction diagrams depict interactions of objects and their relationships.
They also include the messages passed between them.
There are two types of interaction diagrams:
Communication diagram (Collaboration Diagram)
Sequence Diagram
2: Check coin
1: Insert coin
Customer Coin
Reader
7: Checking
4: Display menu
Dispencer System
interface
6: Check for availability
Sequence Diagrams:
Sequence diagrams are interaction diagrams that illustrate the ordering of
messages according to time.
Notations:
These diagrams are in the form of two-dimensional charts. The objects that
initiate the interaction are placed on the x–axis. The messages that these
objects send and receive are placed along the y–axis, in the order of
increasing time from top to bottom.
Sequence Diagrams: the basic elements:
Class roles:
Class roles describe the way an object will behave in context. Use the UML
object symbol to illustrate class roles, but don't list object attributes.
Activation:
Activation boxes represent the time an object needs to complete a task.
Messages
Messages are arrows that represent communication between objects. Use
half-arrowed lines to represent asynchronous messages. Asynchronous
messages are sent from an object that will not wait for a response from the
receiver before continuing its tasks.
Lifelines:
Lifelines are vertical dashed lines that indicate the object's presence over
time.
Destroying Objects:
Objects can be terminated early using an arrow labeled "< < destroy > >"
that points to an X.
Loops:
A repetition or loop within a sequence diagram is depicted as a rectangle.
Place the condition for exiting the loop at the bottom left corner in square
brackets [ ].
Display menu
select item
Check for availability
Checking
Acknowledgement of availablility
Request of item
Recieved item
Timing Diagrams:
UML timing diagrams are used to display the change in state or value of one
or more elements over time. It can also show the interaction between timed
events and the time and duration constraints that govern them.
State Lifeline:
A state lifeline shows the change of state of an item over time. The X-axis
displays elapsed time in whatever units are chosen, while the Y-axis is labeled
with a given list of states. A state lifeline is shown below.
Value Lifeline:
A value lifeline shows the change of value of an item over time. The X-axis
displays elapsed time in whatever units are chosen, the same as for the state
lifeline. The value is shown between the pair of horizontal lines which crosses
over at each change in value. A value lifeline is shown below.
Pattern:
Patterns help you to visualize, specify, construct, and document the artifacts
of a software intensive system. You can forward engineer a system by
selecting an appropriate set of patterns and applying them to the abstractions
specific to your domain. You can also reverse engineer a system by
discovering the patterns it embodies, although that's hardly a perfect process.
Even better, when you deliver a system, you can specify the patterns it
embodies so that when someone later tries to reuse or adapt that system, its
patterns will be clearly manifest.
Framework:
A framework is an architectural pattern that provides an extensible template
for applications within a domain. For example, one common architectural
pattern you'll encounter in real time systems is a cyclic executive, which
divides time into frames and sub frames, during which Processing takes place
under strict deadlines. Choosing this pattern versus its alternatives (an even-
driven architecture) colors your entire system. Because this pattern (and its
alternative) is so common, it makes sense to name it as a framework
Reference Books:
Online References:
1. http://www.sparxsystems.com/resources/uml2_tutorial
2. https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_oriented_ana
lysis.htm