Unit II:Basic

Structural Modelling

Classes, Relationships, Common mechanisms and

diagrams. Advanced Structural Modelling: Advanced
classes, advanced relationships, Interfaces, Types
and Roles, Packages, Common modeling techniques.
 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.
•
 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 the thing
you are modeling that is shared by all objects of
that class
 Operations
• An operation is the implementation of a service that
can be requested from any object of the class to affect
behavior.
• In other words, an operation is an abstraction of
something you can do to an object and that is shared
by all objects of that class.
• A class may have any number of

operations or no operations at all.

 Organizing attributes and relationships
• When drawing a class, you don't have to show every attribute
and every operation at once.
• show only some or none of a class's attributes and operations
• specify more attributes by ending each list with an ellipsis
("...").
• To better organize long lists of attributes and operations
you prefix each group with stereotypes
 Responsibilities
• A responsibility is a contract or an obligation of a class.
• All objects of that class have the same kind of state and behavior .
• Ex:

• A Wall class is responsible for knowing about height, width, and thickness;
• a FraudAgent class, as you might find in a credit card application, is responsible
for processing orders and determining if they are legitimate, suspect, or
fraudulent;
• a TemperatureSensor class is responsible for measuring temperature and raising
an alarm if the temperature reaches a certain point.
• Graphically, responsibilities can be drawn in a separate compartment at the
bottom of the class icon

•
 Relationships
• A relationship is a connection among things.
• The three most important relationships are dependencies,

generalizations, and associations.

• • Graphically, a relationship is rendered as a path, with different kinds of
lines used to distinguish the kinds of relationships.
• Dependency
• A dependency is a using relationship that states that a change in
specification of one thing (for example, class Event) may affect
another thing that uses it (for example, class Window).
• Graphically, a dependency is rendered as a dashed directed line.
 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).
• sometimes called an
"is-a-kind-of" relationship: •
• A child inherits the properties
of its parents, especially their
attributes and operations.
 Association
• An association is a structural relationship that specifies
that objects of one thing are connected to objects of
another.
• There are adornments that apply to associations.
• Name :
• An association can have a name, and you use that name to
describe the nature of the relationship.
 There are four adornments that apply to
associations.
• Role
• When a class participates in an association, it has a
specific role that it plays in that relationship;
• A role is just the face the class at the near end of
the association presents to the class at the other
end of the association.
• Multiplicity specifies how many
instances of one class can relate to a
single instance of a class with which it is
associated..
• one client to a bank may have one or
many accounts.
• • This "how many" is called the
multiplicity of an association's role, and
is written as an expression that
evaluates to a range of values or an
explicit value.
 Aggregation
• A plain association between two
classes represents a structural
relationship between peers, meaning
that both classes are conceptually at
the same level
• Sometimes, you will want 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.
•
•
 Common mechanisms and diagrams

A building is made simpler and more harmonious by the

conformance to a pattern of common features.

A house may be built in the Victorian or French country

style largely by using certain architectural patterns that
define those styles.
The same is true of the UML.
It is made simpler by the presence of four common
mechanisms that apply consistently throughout the
language.

1. Specifications

2. Adornments

3. Common divisions

4. Extensibility mechanisms
 Specifications
The UML is more than just a graphical language.

Rather, behind every part of its graphical notation there is a specification that
provides a textual statement of the syntax and semantics of that building
block.

For example, behind a class icon is a specification that provides the full set of
attributes, operations (including their full signatures), and behaviors that the
class embodies; visually, that class icon might only show a small part of this
specification.

Furthermore, there might be another view of that class that presents a

completely different set of parts yet is still consistent with the class's
underlying specification.
You use the UML's graphical notation to visualize a system;
you use the UML's specification to state the system's
details.

Given this split, it's possible to build up a model

incrementally by drawing diagrams and then adding
semantics to the model's specifications, or directly by
creating a specification,

perhaps by reverse engineering an existing system, and

then creating diagrams that are projections into those
specifications.
 Adornments
Most elements in the UML have a unique and direct graphical
notation that provides a visual representation of the most
important aspects of the element.

For example, the notation for a class is intentionally designed to be

easy to draw, because classes are the most common element found
in modeling object-oriented systems.

• Adornments are textual or graphical items that are added to an

element's basic notation and are used to visualize details from
the element's specification.
let us consider association, which in its most simple
notation consists of one single line.

Now, this can be adorned with some additional details,

such as the role and the multiplicity of each end.
One of the most important kinds of adornments is a note.

This is a graphical symbol, which is used for adding some

comments or constraints to an element (or a collection of
elements) to help clarify the models that are being created.

We may use notes in order to attach some additional

information to our model, such as an explanation, a
requirement, or just simply an o observation
 Common
Divisions
In modeling object-oriented systems, the world often gets
divided in at least a couple of ways.

First, there is the division of class and object.

A class is an abstraction;
an object is one concrete manifestation of that abstraction.

In the UML, you can model classes as well as objects

In this figure, there is one class, named Customer, together with three objects:
Jan (which is marked explicitly as being a Customer object), :
Customer (an anonymous Customer object), and

Elyse (which in its specification is marked as being a kind of Customer object, although it's
not shown explicitly here).
In this figure, there is one component named
spellingwizard.dll that implements two interfaces,
IUnknown and ISpelling.
Extensibility Mechanisms

The UML provides a standard language for writing software

blueprints, but it is not possible for one closed language to
ever be sufficient to express all possible nuances of all
models across all domains across all time.

For this reason, the UML is opened-ended, making it

possible for you to extend the language in controlled ways.

The UML's extensibility mechanisms included.

Stereotypes ·
Tagged values ·
Constraints
 stereotype
A stereotype extends the vocabulary of the UML, allowing
you to create new kinds of building blocks that are derived
from existing ones but that are specific to your problem.

For example,
if you are working in a programming language, such as Java
or C++, you will often want to model exceptions.

In these languages, exceptions are just classes, although

they are treated in very special ways.
Typically, you only want to allow them to be thrown and
caught, nothing else.

You can make exceptions first class citizens in your models•

meaning that they are treated like basic building blocks by

marking them with an appropriate stereotype, as for the
class Overflow.
 Tagged value
A tagged value extends the properties of a UML building
block, allowing you to create new information in that
element's specification.

For example, if you are working on a shrink-wrapped

product that undergoes many releases over time, you often
want to track the version and author of certain critical
abstractions.

Version and author are not primitive UML concepts

 constraint
A constraint extends the semantics of a UML building block,
allowing you to add new rules or modify existing ones.

For example, you might want to constrain the EventQueue

class so that all additions are done in order.
COMMON MECHANISMS
COMMON MECHANISMS
 COMMON MECHANISMS
• Tagged Values : 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).
 COMMON MECHANISMS
• Constraints : A constraint is rendered as a string
enclosed by brackets and placed near the
associated element.
 Common Modeling Techniques
• Modeling Comments
• To model a comment
• To model a comment, Put your comment as text in
a note and place it adjacent to the element to
which it refers.
• You can show a more explicit relationship by
connecting a note to its elements using a
dependency relationship.
 Modeling New Building Blocks
• Make sure there’s not already a way to express what you
want by using basic UML. If you have a common
modeling problem, chance are there’s already some
standard stereotype that will do what you want.
• no other way to express these semantics, identify the
primitive thing in the UML that's most like what you want
to model (for example, class, interface, component, node,
association, and so on) and define a new stereotype for
that thing.
• Specify the common properties and semantics that go
beyond the basic element being stereotyped by defining a
set of tagged values and constraints for the stereotype
• If you want these stereotype elements to have a
distinctive visual cue, define a new icon for the stereotype
Figure Modeling New Building Blocks.
 Modeling New Properties
• To model new properties,
• First, make sure there's not already a way to express
what you want by using basic UML. If you have a
common modeling problem, chances are that there's
already some standard tagged value that will do
what you want.
• If you're convinced there's no other way to express
these semantics, add this new property to an
individual element or a stereotype. The rules of
generalization apply• tagged values defined for
one kind of element apply to its children.
Figure Modeling New Properties
 Modeling New Semantics
• To model new semantics,
• First, make sure there's not already a way to express what
you want by using basic UML. If you have a common
modeling problem, chances are that there's already some
standard constraint that will do what you want.
• If you're convinced there's no other way to express these
semantics, write your new semantics as text in a
constraint and place it adjacent to the element to which it
refers. You can show a more explicit relationship by
connecting a constraint to its elements using a
dependency relationship.
• If you need to specify your semantics more precisely and
formally, write your new semantics using OCL.
Figure Modeling New Semantics
 Advanced Structural modelling
Structural model represents a view of a system that focuses on the structure
of the objects, including their classifiers, relationships, attributes and
operations.

The advanced Structural Modeling describes some advanced features of

classes and their relationships.

Advanced Classes feature contains classifier, visibility and scope.

The classifier is a modeling element that defines attributes and operations.

It can be accessed by other classifiers through the visibility feature.

 Advanced classes
• A classifier is a kind of UML element that is used to define some
common features in terms of structural (attributes) as well as
behavioral (operations).

• Class, interface, data types, use case, collaboration, node, signal

and subsystems all are examples of classifier

• A class is an important type of classifier in UML, which describes a

group of objects that share the same features. Some more
classifiers are given as follows:
Visibility - UML, you can specify any of three
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 -.
 The visibility
The visibility is one of the important features and we have seen it
has been applied to attributes and operations of the classifier.
In the same direction, another feature also applied to the
classifier’s attributes and operations is scope.

This feature signifies that an attribute or an operation has their

existence in all the instances of the classifier(Instance) or only one
copy is available and is shared across all the instances of the
classifier(Classifier).

There are two types of scope specifiers as “instances” and “class

scope”
Scope-
 Attributes
• You can Specify the visibility, scope, and multiplicity of each attribute.
There's still more.

• You can also specify the type, initial value, and changeability of each
attribute.

• • In its full form, the syntax of an attribute in the UML is

• [visibility] name [multiplicity] [: type] [= initial-value]
[{property-string}].
There are three defined properties that you
can use with attributes.
 Operations
• you can also specify the visibility and scope of each
operation.

• • You can also specify the parameters, return type,

concurrency semantics, and other properties of each
operation.

• • The name of an operation plus its parameters (including its return

type, if any) is called the operation's signature.

• • In its full form, the syntax of an operation in the UML is

• [visibility] name [(parameter-list)] [: return-type]
 Multiplicity
Multiplicity pronounces how many instances of one class
may communicate to a single instance of another class.

One customer has one to five bank accounts and one bank
account belongs to one or two customers.
 Advanced Relationships
• A relationship is a connection among things.

• In object-oriented modeling, the most important

relationships are dependencies, generalizations,
associations.
In UML modeling, dependency describes the relationships
among elements in which one element is dependent on
another element.

It means that if changes occur in one element, it will affect

the other element.

This type of relationship comes with named elements such

as classes, interfaces, components, packages etc.
Dependency is graphically shown as a dashed line.
Dependency
 Dependency
• Two stereotypes that apply to dependency relationships
among packages.
• – access – source package is granted the right to reference
the elements of the target package.
• – import – a kind of access, but only public content.
• • Two stereotypes that apply to dependency relationships
among use case.
• – extend – target use case extends the behavior of source.
• – include – source use case explicitly incorporates the
behavior of another use case at a location specified by the
source
 Dependency
• Three stereotypes when modeling interactions among objects.
• – become – target is the same object of source at later time
• – call – source operation invoke the target operation
• – copy – target is an exact, but different, copy of source
• •In the context of state machine
• – send – source operation sends the target event
• • In the context of organizing the elements of your system into
subsystem and model
• – trace – target is an historical ancestor of the source (model
relationship among elements in different models)
 Generalization
• A generalization is a relationship between a general thing (called the superclass
or parent) and a more specific kind of that thing (called the subclass or child).
• There is the one stereotype.
• • Implementation: Specifies that the child inherits the implementation of
the parent but does not make public nor support.
• The four constraints that may be applied to generalization relationships.
• 1.Complete - Specifies that all children in the generalization have been specified
in the model and that no additional children are permitted
• 2.Incomplete - Specifies that not all children in the generalization have
been specified and that additional children are permitted
• 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
 Interfaces
• An interface is a collection of operations that are used to
specify a service of a class or a component.

• Graphically, an interface is rendered (represented) as a

circle;
• Every interface must have a name that distinguishes it
from other interfaces

• You can define any number of operations in interface

to provide services to a class or component, but you
can neither define any attributes nor any
implementation of the operations in the interface
 Operations:
• To distinguish an interface
from a class, prepend an ‗I‘
to every interface name.
• Interface don't have
attributes.
 Understanding an Interface
• In the UML, you can supply much more
information to an interface in order to make it
understandable and approachable.
• First, you may attach pre- and postconditions to
each operation and invariants to the class or
component as a whole.

• By doing this, a client who needs to use an

interface will be able to understand what the
interface does and how to use it, without having to
dive into an implementation.
 Interface relationships

• An interface may participate in generalization,

association, dependency and realization relationships
 Types and Roles
• Type:

• • A type is a stereotype of a class used to specify a domain of objects, together with

the operations applicable to the object of that type.

A type is a stereotype of class used to specify attributes, operations but does not
have methods.

It is generally used in the analysis process to identify the objects for a system.

It is just like conceptual classes because it gives an idea of possible classes.

They do not have methods and instances.

• • To distinguish a type from an interface or a class, prepend a ‗T‘ to every type.
• Role
• • A role names(indicates) a behavior of an entity
participating in a particular context. Or, a role is the face
that an abstraction presents to the world.

• • For example, consider an instance of the class Person.

Depending on the context, that Person instance may play
the role of Mother, Comforter, PayerOfBills, Employee,
Customer, Manager, Pilot, Singer, and so on.
 Packages
• A package is a general-purpose mechanism for organizing elements into groups.‖

• Graphically, a package is rendered as a tabbed folder.

• UML permits us to place a set of related classes together into a group is called package

• Package is more helpful to organize a large model. Packages are supported by Java.

• Classes in one package cannot access the classes and services in another package

unless the package is imported..

 Packages
• Names
• • Every package must have a name that
distinguishes it from other packages. A name is a
textual string.
• A Simple and Extended Package
 Packages
• Visibility

• Typically, an element owned by a package is

public, which means that it is visible to the
contents of any package that imports the
element's enclosing package.
• • Conversely, protected elements can only be seen
by children, and private elements cannot be seen
outside the package in which they are declared
 Importing and
Exporting
• Suppose you have two classes named A and B sitting side by side.
Because they are peers, A can see B and B can see A, so both can
depend on the other. Just two classes makes for a trivial system, so
you really don't need any kind of packaging.

• • In the UML, you model an import relationship as a dependency

adorned with the stereotype import
• • Actually, two stereotypes apply here—import and
access— and both specify that the source package has
access to the contents of the target.

• • Import adds the contents of the target to the source's

namespace

• • Access does not add the contents of the target

• • 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.
Import and Export
 Generalization
• There are two kinds of relationships you can have between packages:
import and access dependencies used to import into one package
elements exported from another and generalizations, used to specify
families of packages
• • Generalization among packages is very much like
generalization among classes.
• • Packages involved in generalization relationships follow the same
principle of substitutability as do classes.

• A specialized package (such as WindowsGUI) can be used anywhere a

more general package (such as GUI) is used.
 Common Modeling Techniques

• Modeling 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.
 2. Modeling 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,
• a process 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.

• • There will typically be dependencies across the

elements in different views.

• So, in general, let each view at the top of a system be

open to all others at that level
Modeling Architectural
Views
 Common Modeling Techniques
• 1. Modeling the Seams in a Systemizing the Seams in a System

• Within the collection of classes and components in your

system, draw a line around those that tend to be tightly
coupled relative to other sets of classes and components.

• • Refine your grouping by considering the impact of change.

• Classes or components that tend to change together should

be grouped together as collaborations.
• For each such collaboration in your system, identify the
interfaces it relies on (imports) and those it provides to
others (exports).

• You model the importing of interfaces by dependency

relationships, and

• you model the exporting of interfaces by realization

relationships.
2. Modeling Static and Dynamic Types