Advanced structured modeling

advanced classes and relationships, interfaces

types and roles,
instances and object diagram.
Basic idea of behavioral modeling
 Topics
• Advanced Classes
• Advanced Relationships
• Interface, Types and Role
• Package
 Advanced Classes
• Classifier
• Visibility
• Abstract, Leaf and Polymorphic elements
• Multiplicity Advanced Classes
• Attributes Advanced Relationships
Interface Types and Role
• Operations Package
• Template class
• Standard elements
• Common Modeling Techniques
– Modeling the semantics of the class
 Advanced Relationships
• Dependency
• Generalization
• Association
• Navigation Advanced Classes
• Visibility Advanced Relationships
Interface Types and Role
• Qualification Package
• Composition
• Constraints
• Realizations
 Interfaces, Types, and Roles
• Names
• Operations
• Relationships Advanced Classes
Advanced Relationships
Interface Types and Role
Package
 Packages
A package is a general purpose mechanism for
organizing the model itself into hierarchy, it has
no meaning to the execution.
• Names Advanced Classes
Advanced Relationships
• Owned Elements Interface Types and Role
Package
• Visibility
• Importing and exporting
 Classifier
• A UML classifier is “a model element that
describes behavioral (operation) and structural
(attribute) features”.

• Classifiers can also be specialized. They are a

generalization of many of the elements of the
UML, including classes, interfaces, use cases, and
actors. In class diagrams, the two most common
classifiers are regular classes and interfaces.
 Classifier contd…
• Classifier include classes, associations,
interfaces, datatypes, signals, components,
nodes, use cases, and subsystems.
Reference:
• http://umlguide2.uw.hu/
• http://teach.branus.net/CIS510/lectures/
 Classifiers
• A classifier is a mechanism for describing
structural and behavioral features.
– classifiers
• Interfaces, datatypes, association, signals, components,
nodes, use cases, subsystems.
– Advanced features
• Multiplicity, visibility, signatures, polymorphism
• Interface
Classifiers
A collection of operations that are used to specify a service of a class or a
component
• Datatype
A type whose values are immutable, including primitive built-in types (such as
numbers and strings) as well as enumeration types (such as Boolean)
• Association
A description of a set of links, each of which relates two or more objects.
• Signal
The specification of an asynchronous message communicated between instances
• Component
A modular part of a system that hides its implementation behind a set of external
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 component that represents a major part of a system
Type of classifiers
 Visibility
• One of the design details you can specify for an attribute or
operation is visibility. The visibility of a feature specifies whether it
can be used by other classifiers. In the UML, you can specify any of
four levels of visibility.
1. public
Any outside classifier with visibility to the given classifier can use
the feature; specified by prepending the symbol +.
2. protected
Any descendant of the classifier can use the feature; specified by
prepending the symbol #.
3. private
Only the classifier itself can use the feature; specified by
prepending the symbol. Symbol -
4. Package packages are named groups of related classes
Only classifiers declared in the same package can use the feature;
specified by prepending the symbol ~.
Access Levels

Modifier Class Package Subclass World

public Y Y Y Y

protected Y Y Y N

no
Y Y N N
modifier

private Y N N N
Visibility
 Abstract, leaf, root and Polymorphic
Elements
• The classes at the top of the hierarchy are more generalized or abstract and the classes
lower in the hierarchy are more specialized. To represent abstract classes for which we
cannot create instances, the class name is written in italics in UML. To represent abstract
methods, we write the operation signature in italics.
 Leaf and root classes
• A class which has no child classes is known as
a leaf class. Such a class can be represented by
writing leaf as a property under the class
name.
• a class with no parents is known as a root
class and such a class can be represented by
writing root as a property as a property under
the class name.
 Contd.
• Whenever we use a class, we'll probably want to
inherit features from other, more-general
classes, and have other, more-specific classes
inherit features from it. These are the normal
semantics we get from classes in the UML.
• However, we can also specify that a class may
have no children. Such an element is called a leaf
class and is specified in the UML by writing the
property leaf below the class's name.
 Operation Signature
• The signature of an operation is the line of text that represents it in
a class or interface on a UML class diagram.
• Syntax
+ OperationName (parameter1 : Type1 [*], ...) : ReturnType [*]

- + denotes public Visibility.

- OperationName is underlined if the Is Static property is true, and is
italic if the Is Abstract property is true.
- : ReturnType is omitted if no return type is defined.
- [*] denotes the multiplicity of a parameter or return type. It is
omitted if the multiplicity is 1.
- Summarizes the visibility, name, parameters, and return type of
this operation. You can change these properties by editing the
signature on the diagram, or by editing the individual properties.
• Operations are shown in the third partition. They are services the
class provides.
• The return type of a method is shown after the colon at the end of
the method signature.
• The return type of method parameters are shown after the colon
following the parameter name. Operations map onto class methods
in code
• Attributes map onto member variables (data
members) in code.
 Attribute Signature
• An attribute's signature is the line that represents it in
a class or interface on a UML class diagram. It has this
form:
+ AttributeName : TypeName [*]
- + denotes public Visibility. The other permitted values
are - (private), # (protected), ~ (package).
- AttributeName is underlined if the attribute is static.
- : TypeName is omitted if the attribute has no type.
- [*] denotes the multiplicity. It is omitted if the
multiplicity is 1.
 Polymorphic Elements
• Polymorphism means “many forms”. Polymorphic
operations have many implementations.
polymorphism means objects of different classes have
operations with the same signature but different
implementations.
 Multipilicity
• Multiplicities answer the following question: "How many
objects of each class take part in the relationships?“
 Scope and Instance
• Details specified for classifier attributes and operation
is scope.
• An instance is a concrete manifestation of an
abstraction to which a set of operations may be applied
and which may have a state that stores the effects of
the operation. An instance is a single and unique unit
of a class.
• The scope of a feature specifies whether each instance
of the classifier has its own distinct value of the feature
or whether there is just a single value of the feature
shared by all instances of the classifier.
 Types of scope
• 1.Instance scope
Each instance of the classifier holds its own value
for the feature. This is the default and requires no
additional notation.

• 2. Static scope
There is just one value of the feature for all
instances of the classifier. This has also been
called class scope. This is notated by underlining
the feature string.
 Operations
• A class’s behavioral features are indicated by its
operations.

• The UML distinguishes between operation and

method. An operation specifies a service that can
be requested from any object of the class to affect
behavior; a method is an implementation of an
operation.
 Advanced Relationships

• A relationship is a connection among things.

In object-oriented modeling, the four most
important relationships are dependencies,
generalizations, associations, and realizations
Relationship
Relationship is another most important building block of UML. It shows how
the elements are associated with each other and this association describes
the functionality of an application.
There are four kinds of relationships available.
Dependency
• Dependency is a relationship between two things in which change in one
element also affects the other.
Association
• Association is basically a set of links that connects the elements of a UML
model. It also describes how many objects are taking part in that
relationship.
Generalization
• Generalization can be defined as a relationship which connects a
specialized element with a generalized element. It basically describes the
inheritance relationship in the world of objects.
Realization
• Realization can be defined as a relationship in which two elements
are connected. One element describes some responsibility, which is not
implemented and the other one implements them. This relationship exists
in case of interfaces.
Aggregation and Composition
• Aggregation is a special type of association that models a
whole- part relationship between aggregate and its parts.
Here, the college class will remain even if the student is not
available.

• The composition is a special type of aggregation which

denotes strong ownership between two classes when one
class is a part of another class. if college is not functioning all
the students also removed.
 Dependency and generalization
• Student has dependency on college

• A generalization helps to connect a subclass to

its superclass. A sub-class is inherited from its
superclass. Student is generalized from Person
Class.
 Association and Multiplicity
• The relationship between student and college is shown which is studies.
This kind of relationship represents static relationships between classes A
and B. For example; an employee works for an organization.
• Multiplicity : The college can have multiple students.
 Dependency

• UML defines a number of stereotypes that may be

applied to dependency relationships.

• There are 17 such stereotypes, all of which can be

organized into six groups.

• First, there are eight stereotypes that apply to

dependency relationships among classes and objects in
class diagrams.
• <<bind>> Specifies that the source instantiates (Create Objects)the target
template using the given actual parameter

• <<derive>> Specifies that the source may be computed from the target
• <<friend>> Specifies that the source is
accessible from the target regardless of the
visibility of the source element

• <<instance Of>> Specifies that the source

object is an instance of target classifier. When
you want to model the relationship between a
class and an object in the same diagram, or
between a class and its metaclass
• <<instantiate>> Specifies that the source creates instance of the target

• <<powertype>> A powertype is a classifier whose objects are children of

a given parent

• <<refine>> Specifies that the target is at lower of abstraction then the

source, when you want to model classes that are essentially the same but
at different levels of abstraction.

• <<use>> Specifies that the source elements depends on the target for
its functionality
There are two stereotypes that apply to
dependency relationships among packages.
Two stereotypes apply to dependency
relationships among use cases
 There are three stereotypes when
modeling interactions among objects.
One stereotype applies to dependencies in
the context of state machines

• We'll use send when we want to model an

operation dispatching a given event to a target
object.
• * The send dependency in effect lets you tie
independent state machines together.
 One stereotype applies to dependencies in the
context of subsystem

• We'll use trace when we want to model the

relationships among elements in different
models
 Generalization
• A generalization relationship represents generalization-
specialization relationship between classes. The class
with the general structure and behavior is known as
the parent or superclass and the class with specific
structure and behavior is known as the child or
subclass.
• The generalization relationship is also known as the “is-
a” relationship. If a class has only one parent, such
inheritance is known as single inheritance and if a class
has one or more parents, such inheritance is known as
multiple inheritance.
• UML provides one stereotype and four
constraints. The stereotype on generalization
relationship is:
• There are four standard constraints that apply
to the generalization relationship:
 Association
• Association is a structural relationship which denotes a
connection between two or more things. The
association relationship can represent either physical
or logical connections between things. The graphical
representation of the association relationship is a solid
line.
• The four basic adornments for an association
relationship are: name, role at each end of the
association, multiplicity at each end of the association
and aggregation. Over these basic features, there are
other advanced features like: navigation, visibility,
qualification, composition and association classes.
• Navigation
• Given an association between two things, we
can navigate from one thing to another and
vice versa. By default the navigation of an
association is bidirectional.
• Visibility
• in some situations we may want to limit the
visibility (access) of an object to the objects
outside the association relationship.
 Qualification
• A qualifier is a set of attributes of an association which is used
to identify a set of instances of a class.
• Each qualifier is represented with a name and type in a
rectangle box at the qualified end of the association
relationship. For example, a bank object is able to recognize
the person (account holder) based on the account number.
So, account number is the qualifier which is used to identify
an account holder.
 Association – Qualification
Bank Qualifier,
account # cannot access person without knowing the account
* #

0..1
Person

Chessboard
rank:Rank
file:File
1
1
Square

* 0..1
WorkDesk jobId : int returnedItem
66
 Composition
• Composition as well as aggregation
relationships represent whole-part
relationships, in which one thing is a part of
the other thing.
• Composition is graphically represented by
adorning the association relationship with a
filled diamond head near the whole end.
 Realization
• Realization is a semantic relationship between
classifiers, where one classifier provides the
specification which is implemented by the other
classifier.
• Realization can exist between an interface and
class, interface and component and between a
use case and collaboration.
• Realization is graphically represented as dashed
line with a hollow arrow head pointing towards
the classifier which provides the specification.
 Interfaces, Types, and Roles
• An interface is a collection of operations that are used
to specify a service of a class or a component.
• We use interfaces to visualize, specify, construct, and
document the seams within your system.
• Types and roles provide a mechanism for you to model
the static and dynamic conformance of an abstraction
to an interface in a specific context.
• Graphically, an interface is rendered(represented) as a
circle; in its expanded form, an interface may be
rendered as a stereotyped class(a class with stereotype
interface). An interface name must be unique within its
enclosing package.
 Interface contd.
• To realize an interface a class or component
must implement the operations and attributes
defined by the interface.
• Any given class or component may implement
zero or more interfaces and one or more
classes or components can implement the
same interface.
• Each end of the association is called a role. Each role
describes the properties of the equivalent attribute on the
class at the opposite end of the association.
In the example diagram, the association between Menu
and Menu Item has roles called Menu and Contents.
Contents is the name of an attribute on the Menu class.
• instances and object diagram. Basic idea of
behavioral modeling
• Instance is some system entity, concrete
manifestation (implementation) of an
abstraction.
• Class may be modeled as being active, meaning
that an instance of the class has some
autonomous behavior.
• Objects are rendered as instance specifications,
usually on object diagrams. So when we see
instance of a class, we can call it object.
• Instance specification describes instance with
appropriate degree of details, either partially or
completely. The description may include:
• Type of the entity, specified by none, one or more
classifiers of which the entity is an instance.
• Definition of values of structural features of the
entity.
• Specification of how to construct, derive, or
compute the instance.
• Anonymous instance: Customer class instance
without name, anonymous object of customer
class
• Orphan Instance: In some cases, class of an
instance is either unknown or not specified.
An instance named newPatient of some
unnamed or unknown class.
• Named Instance: An object could have all of
instance name, class, and namespace
(package) specified. myCustomer

t : Transaction

• Multiobject : keyCode
• active object (with a thicker border; owns a thread or process
and can initiate control activity)
r : FrameRenderThread

• instance with attribute values myCustomer

id : SSN = “432-89-1738”
active = True

• Instance with current state

c : Phone
[WaitingForAnswer]
 Common Modeling Techniques
Modeling Groups of Elements
• To model groups of elements, Scan the modeling
elements in a particular architectural view and look for
clumps defined by elements that are conceptually or
semantically close to one another. Surround each of
these clumps in a package.
• For each package, distinguish which elements should
be accessible outside the package. Mark them public,
and all others protected or private. When in doubt,
hide the element. Explicitly connect packages that
build on others via import dependencies. In the case of
families of packages, connect specialized packages to
their more general part via generalizations.
 Modeling Architectural Views
• To model architectural views, Identify the set of
architectural views that are significant in the
context of your problem. In practice, this typically
includes a design view, an interaction view, an
implementation view, a deployment view, and a
use case view. Place the elements (and diagrams)
that are necessary and sufficient to visualize,
specify, construct, and document the semantics
of each view into the appropriate package. As
necessary, further group these elements into
their own packages.
 Instances & Object Diagrams
 “instance” and “object” are largely synonymous; used interchangeably.

 difference:
 instances of a class are called objects or instances; but
 instances of other abstractions (components, nodes, use cases, and associations)
are not called objects but only instances.

Object Diagrams
 very useful in debugging process.
– walk through a scenario (e.g., according to use case flows).
– Identify the set of objects that collaborate in that scenario (e.g., from use case
flows).
– Expose these object’s states, attribute values and links among these objects.

86
 3 basic building blocks of UML - Diagrams
Graphical representation of a set of elements.
Represented by a connected graph: Vertices are things; Arcs are relationships/behaviors.
5 most common views built from
UML 1.x: 9 diagram types. UML 2.0: 12 diagram types
Structural Diagrams Structural Diagrams
Represent the static aspects of a – Class;
system.
Object
– Class;
– Component
Object
– Deployment
– Component
– Composite Structure
– Deployment
– Package

Behavioral Diagrams Interaction Diagrams

Represent the dynamic aspects. Behavioral Diagrams – Sequence;
– Use case – Use case Communication
– Sequence; – Statechart – Interaction
– Activity Overview
Collaboration
– Timing
– Statechart
– Activity
87
 object diagram
• An Object Diagram can be referred to as a screenshot
of the instances in a system and the relationship that
exists between them. Since object diagrams depict
behaviour when objects have been instantiated, we are
able to study the behavior of the system at a particular
instant. Object diagrams are vital to portray and
understand functional requirements of a system.
• “An object diagram in the Unified Modeling Language
(UML), is a diagram that shows a complete or partial
view of the structure of a modeled system at a specific
time.”
• An object diagram is similar to a class diagram
except it shows the instances of classes in the
system. We depict actual classifiers and their
relationships making the use of class diagrams
• an Object Diagram represents specific instances
of classes and relationships between them at a
point of time
• In UML a classifier refers to a group of elements
that have some common features like methods,
attributes and operations.
• Object Diagrams use real world examples to depict
the nature and structure of the system at a particular
point in time. Since we are able to use data available
within objects, Object diagrams provide a clearer
view of the relationships that exist between objects.
 Basic Object Diagram Symbols and
Notations
• Object Names: Every object is actually symbolized like a
rectangle, that offers the name from the object and its class
underlined as well as divided with a colon.

• Object Attributes: Similar to classes, you are able to list object

attributes inside a separate compartment. However, unlike
classes, object attributes should have values assigned for
them.
• Links: Links tend to be instances associated with associations.
You can draw a link while using the lines utilized in class
diagrams.