UML-Unit 2

Classes, Relationships, Common Mechanisms and Diagrams

Class
• A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics.
• A class implements one or more interfaces.
• The UML provides a graphical representation of class.
• Graphical representation of class is as follows:
Terms and Concepts
• Names
• Attributes
• Operations
• Organizing Attributes and Operations
• Responsibilities
Names
• Every class must have a name that distinguishes it from other classes.
• A name is a textual string that name alone is known as a simple
name.
• A path name is the class name prefixed by the name of the package in
which that class lives.
Attributes
• An attribute is a named property of a class that describes a range of
values that instances of the property may hold.
• A class may have any number of attributes or no attributes at all.
• An attribute represents some property of thing modelled that is
shared by all objects of that class.
• An attribute is further specified by stating its class and possibly a
default initial value
Operations
• An operation is the implementation of a service that can be
requested from any object of the class to affect behavior.
• A class may have any number of operations or no operations at all.
• Graphically, operations are listed in a compartment just below the
class attributes.
• An operation can be specified by stating its signature, covering the
name, type, and default value of all parameters and a return type.
Organizing Attributes and Operations
• To better organize long lists of attributes and operations, each group
can be prefixed with a descriptive category by using stereotypes
Responsibilities
• A Responsibility is a contract or an obligation of a class.
• To model classes, a good starting point is to specify the
responsibilities of the things in the vocabulary.
• A class may have any number of responsibilities, although, in practice,
every well-structured class has at least one responsibility and at most
just a handful.
• Graphically, responsibilities can be drawn in a separate compartment
at the bottom of the class icon
Modelling the vocabulary of system
Relationships
• In the UML, the ways that things can connect to one another, either
logically or physically, are modeled as relationships.
• In object-oriented modeling, there are three kinds of relationships
that are most important:
• Dependencies
• Generalizations
• Associations
Terms and Concepts
• Dependency
• Generalization
• Association
• Name
• Role
• Multiplicity
• Aggregation
Dependency
• A dependency is a using relationship that states that a change in
specification of one thing may affect another thing that uses it but
not necessarily the reverse.
• Graphically dependency is rendered as a dashed directed line,
directed to the thing being depended on.
Generalization
• A generalization is a relationship between a general thing (called the
super class or parent)and a more specific kind of that thing (called the
subclass or child).
• Generalization means that the child is substitutable for the parent. A
child inherits the properties of its parents, especially their attributes
and operations
• An operation of a child that has the same signature as an operation in
a parent overrides the operation of the parent; this is known as
polymorphism.
• Graphically generalization is rendered as a solid directed line with a
large open arrowhead, pointing to the parent
Generalization
Aggregation
• An association is a structural relationship that specifies that objects of
one thing are connected to objects of another.
• An association that connects exactly two classes is called a binary
association
• An associations that connect more than two classes; these are called
n-ary associations.
• Graphically, an association is rendered as a solid line connecting the
same or different classes.
• Beyond this basic form, there are four adornments that apply to
association: Name, Role, Multiplicity, Aggregation
Cont..
• Name: An association can have a name, and to describe the nature of
the relationship.
Cont..
• Role : When a class participates in an association, it has a specific role
that it plays in that relationship.
• The same class can play the same or different roles in other
associations.
• An instance of an association is called a link
Cont..
Multiplicity
• In many modeling situations, it's important to state how many objects
may be connected across an instance of an association.
• This "how many" is called the multiplicity of an association's role.
• Multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one
or more (1..*). One can even state an exact number (for example, 3).
Cont..
Aggregation
• Sometimes it is required to model a "whole/part" relationship, in
which one class represents a larger thing (the "whole"), which
consists of smaller things (the "parts").
• This kind of relationship is called aggregation, which represents a
"has-a" relationship, meaning that an object of the whole has objects
of the part.
• Aggregation is really just a special kind of association and is specified
by adorning a plain association with an open diamond at the whole
end
Aggregation
Model structural relationships
Common Mechanisms
• Note
• Stereotypes
• Tagged Values
• Constraints
Note
• A note is a graphical symbol for rendering constraints or 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
Stereotypes
• A stereotype is an extension of the vocabulary of the UML, allowing
to create new kinds of building blocks similar to existing ones but
specific to your problem.
• Graphically, a stereotype is rendered as a name enclosed by
guillemets and placed above the name of another element
Tagged Values
• Every thing in the UML has its own set of properties: classes have names,
attributes, and operations; associations have names and two or more ends (each
with its own properties); and so on.
• With stereotypes, one can add new things to the UML; with tagged values, one
can add new properties.
• A tagged value is not the same as a class attribute. It can be thought as a
metadata because its value applies to the element itself, not its instances.
• A tagged value is an extension of the properties of a UML element, allowing one
to create new information in that element's specification.
• Graphically, a tagged value is rendered as a string enclosed by brackets and
placed below the name of another element.
• In its simplest form, a tagged value is rendered as a string enclosed by brackets
and placed below the name of another element.
• That string includes a name (the tag), a separator (the symbol =), and a value (of
the tag).
Tagged Value
Constraints
• A constraint specifies conditions that must be held true for the model
to be well-formed.
• A constraint is rendered as a string enclosed by brackets and placed
near the associated element.
• Graphically, a constraint is rendered as a string enclosed by brackets
and placed near the associated element or connected to that element
or elements by dependency relationships.
Common Modelling Techniques
• Modelling Comments
• Modelling New Building Blocks
• Modelling New Properties
• Modelling New Semantics
Modelling Comments
Modelling New Building Blocks
Modelling New Semantics
Diagrams
• A diagram is the graphical presentation of a set of elements, most
often rendered as a connected graph of vertices (things) and arcs
(relationships).
• Each diagram provides a view into the elements that make up the
system
• The UML defines nine kinds of diagrams, which can be mixed and
matched to assemble each view.
• To fit the needs of the project or organization, one can create its own
kind of diagrams to view UML elements in different ways.
• Two basic ways to use UML's diagrams:
• To specify models from which an executable system is constructed(forward
engineering)
• To reconstruct models from parts of an executable system (reverse
engineering).
• Structural Diagrams: to view static part of system
• Class diagram: Classes, interfaces, and collaborations
• Object diagram: Objects
• Component diagram: Components
• Deployment diagram: Nodes
• Behavioral Diagrams: to view dynamic part of system
• Use case diagram : Organizes the behaviors of the system
• Sequence diagram : Focused on the time ordering of messages
• Collaboration diagram : Focused on the structural organization of objects that
send and receive messages
• Statechart diagram : Focused on the changing state of a system driven by
events.
• Activity diagram : Focused on the flow of control from activity to activity
Structural Diagrams
• The UML's four structural diagrams exist to visualize, specify,
construct, and document the static aspects of a system.
• Class Diagram:
• It is used to illustrate the static design view of a system.
• These are the most common diagrams found in modelling object-oriented
systems.
• It shows a set of classes, interfaces, and collaborations and their relationships.
• It can include active classes to address the static process view of a system.
• Object Diagram
• Object diagrams address the static design view or static process view of a
system just as do class diagrams, but from the perspective of real or
prototypical cases.
• It shows a set of objects and their relationships.
• It is used to illustrate data structures, the static snapshots of instances of the
things found in class diagrams.
• Component Diagram
• The component diagram is used to illustrate the static implementation view
of a system.
• It shows a set of components and their relationships.
• These are related to class diagrams in that a component typically maps to one
or more classes, interfaces, or collaborations.
• Deployment Diagram
• The deployment diagram is used to illustrate the static deployment view of an
architecture.
• It shows a set of nodes and their relationships.
• These are related to component diagrams in that a node typically encloses
one or more components.
Behavioral Diagrams
• The UML's five behavioral diagrams are used to visualize, specify,
construct, and document the dynamic aspects of a system.
• Use Case Diagram
• A use case diagram shows a set of use cases and actors and their
relationships.
• It is used to illustrate the static use case view of a system.
• Use case diagrams are especially important in organizing and modelling the
behaviors of a system.
• Sequence Diagram
• Sequence diagrams are used to illustrate the dynamic view of a system.
• A sequence diagram is an interaction diagram that emphasizes the time
ordering of messages.
• A sequence diagram shows a set of objects and the messages sent and
received by those objects.
• Collaboration Diagram
• A collaboration diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages.
• It is used to illustrate the dynamic view of a system.
• It shows a set of objects, links among those objects, and messages sent and
received by those objects.
• The objects are typically named or anonymous instances of classes, but may
also represent instances of other things, such as collaborations, components,
and nodes.
• Sequence and collaboration diagrams are isomorphic, meaning that
they can be converted from one to the other without loss of
information.
• Statechart Diagram
• A statechart diagram shows a state machine, consisting of states, transitions,
events, and activities.
• It is used to illustrate the dynamic view of a system.
• They are important in modelling the behaviour of an interface, class, or
collaboration.
• It emphasizes the event-ordered behaviour of an object, which is especially
useful in modelling reactive systems.
• Activity Diagram
• An activity diagram shows the flow from activity to activity within a system. It
shows a set of activities, the sequential or branching flow from activity to
activity, and objects that act and are acted upon.
• It is used to illustrate the dynamic view of a system.
• It is important in modelling the function of a system. It emphasize the flow of
control among objects.