Unit-3

Class & Object Diagrams:

Terms, concepts
modeling techniques for Class & Object Diagrams.
Advanced Structural Modeling:
Advanced classes,
Advanced relationships,
Interfaces,
Types and Roles,
Packages.
Case Study: AI: Cryptanalysis.
 What are objects?

“A discreet entity with a well-defined boundary that

encapsulates state and behavior, an instance of a
class.”
Objects combine data and function as a unit.
 Objects having
• Identification: Every object is uniquely identifiable.
• State: An object’s state is determined by its
attribute values.
• Behavior: An object’s behavior is “what it can do
for us” – its operations.
 How to retrieve data from an object
• The way to get the data part of an object is by
calling one of the functions that the object
makes available. These functions are called
operations .

• Hiding the data part of an object behind this

layer of operations is known as encapsulation
or data-hiding.
• Every object is itself an instance of some class
that defines the common set of features
(attributes and operations) that are shared by
all instances of that class .
 Behavior
There are certain things the printer can do for us:
switchOn()
switchOff()
printDocument()
pageFeed()
clearInkJetNozzles()
changeInkCartridge()
• Invoking an operation on an object will often cause a change
in the values of one or more of its attributes, or in its
relationships to other objects, and this may constitute a state
transition.
• This is a meaningful movement of the object from one state
to another state.
• An object’s state can also affect its behavior.
• For example, if the printer is out of ink (object state =
OutOfBlackInk),
• then invoking the operation printDocument() will cause it to
signal an error.
• The actual behavior of printDocument() is therefore state
dependent.
 What is a method

• An operation is the specification of a piece of

behavior.
• An implementation of that behavior is called a
method
An object’s state is determined by its attribute values.
• The state of this object is the set of attribute values (in this case 1234567801, “Jim
Arlow”, 300.00) held by the object at any point in time.
• Typically, some of these attribute values will remain fixed, and some will change over
time.
• For example, the account number and name will remain fixed, but we hope that the
balance goes up steadily!
• As the balance changes with time, we see that the object’s state also changes with
time.
• For example, if the balance is negative, then we may say that object is in the state
Overdrawn.
• As the balance changes from negative to zero, the object makes a significant change
in its nature – it makes the state transition from the state Overdrawn to the state
Empty.
• Furthermore, as the Account object’s balance becomes positive, it makes another
state transition from the state Emptyto the state InCredit.
• In fact, any operation invocation that leads to a substantive change in the object’s
nature creates a state transition.
• UML provides a powerful set of modeling techniques called state machines for
modeling state changes
An object’s behavior is “what it can do for us” – its operations .
 How the object can generate the system
behavior
• Objects generate system behavior by sending
messages to each other over links. This is
collaboration.
 UML object notation

The UML object icon is a box with two compartments

The top compartment contains the object identifier,
which is always underlined.
 What are classes?

• A class describes the features of a set of objects.

• “The descriptor for a set of objects that share the
same attributes, operations, methods,
relationships, and behavior.”

• Every object is an instance of exactly one class

 Points related to class
• a class determines the structure (set of features) of all
objects of that class.
• All objects of the same class must have the same set of
operations, the same set of attributes, and the same set
of relationships, but may have different attribute values.

• Each object of the class has specific values for the

attributes defined by the class, and will respond to
messages by invoking the operations defined by the
class.
Just think how many classes are there
Relationship between class and objects
• The relationship between a class and objects of that class is an
«instantiate» relationship.

• The dotted arrow is actually a dependency relationship that has

been given a special meaning by the stereotype «instantiate».
• anything inside («…») is known as a stereotype, and stereotypes
are one of the three UML extensibility mechanisms.
• A stereotype is a way of customizing modeling elements – a way
of creating variants with new semantics.
• In this case, the stereotype «instantiate» turns an ordinary
dependency into an instantiation relationship between a class
and objects of that class.
 Dependency
• defines a dependency as,
• “A relationship between two elements in
which a change to one element (the supplier)
may affect or supply information needed by
the other element (the client).”
 Class instantiation

• It is the creation of new instances of model

elements.
• In this case we are instantiating objects from
classes –
• we are creating new instances of classes.
 constructor

• In most OO programming languages, there are special

operations, called constructors, which really belong to
the class itself rather than the objects of that class.
• The purpose of constructor operations is to create
new instances of the class.
• The constructor allocates memory for the new object,
gives it a unique identity, and sets the initial attribute
values for the object.
• It also sets any links to other objects.
UML class notation
 Analysis of class
In analysis models, you typically only need to
show the following:
class name;
key attributes;
key operations;
stereotypes (if they have business significance).
 You typically do not show:

tagged values;
operation parameters;
visibility;
initialization values (unless they have business
significance).
 Name compartment
• Class name is in UpperCamelCase – it begins with an uppercase
letter, and then is in mixed upper and lowercase, with each word
beginning in uppercase.
• Special symbols such as punctuation marks, dashes, underscores,
ampersands, hashes, and slashes are always avoided. .

• Never abbreviate class, attribute, or operation names.

For example: DepositAccount is always preferable to DpstAccnt.

If there are domain specific acronyms (e.g. CRM - Customer

Relationship Management) that are in common use, and will be
understood by all readers of the model,
• Classes represent “things”,
• so they should have a name that is a noun or a
noun phrase,
• e.g. Person, Money, BankAccount.
 Attribute compartment

Attributes are named in lowerCamelCase - starting with a lowercase letter

and then mixed upper and lowercase.

Attribute names are usually nouns or noun phrases as attributes indicate

some “thing” such as an account balance.

You must avoid special symbols and abbreviations.

 Visibility
• Visibility controls access to the features of a
class.
 Type

• The type of an attribute may be another class or a

primitive type.
• The UML specification defines four primitive types that
are used in the UML specification itself,
• The Object Constraint Language (OCL) is a formal
language for expressing constraints in UML models
• OCL defines standard operations for these types
(except UnlimitedNatural) and adds a new type called
Real.
 Multiplicity
• multiplicity allows you to model collections of things or null
values.
• This constraints relating to the “number of things”
participating in a relationship.
• Multiplicity allows you to model two distinctly different things
by using a multiplicity expression on an attribute
• Collections – if the multiplicity expression results in an integer
greater than 1, then you are specifying a collection of the type.
• For example, colors : Color[7]
• Null values – there is a difference in most languages between
an attribute that contains an empty or uninitialized object,
example
 Initial value
The initial Value allows you to set the value of an
attribute at the point of object creation.
• The initial Value allows you to specify the
value an attribute will take when an object is
instantiated from the class.
• This is known as the initial value of the
attribute because
 Advanced attribute syntax
• «stereotype» attribute { tag1 = value1, tag2 = value2, …}

• Example: address {addedBy=“RAM", dateAdded="20MAR2004"}

• In this example, we have recorded that RAMadded the address

attribute to some class on 20 March 2004.
 Operation compartment
• Operations are functions that are bound to a
particular class. As such, they have all of the
characteristics of functions:
• Name
• Parameters list
• Return type
 Operation signature

• The combination of the operation name, types of all

the parameters, and the return type is the operation
signature
• Every operation of a class must have a unique
signature, as it is this signature that gives the
operation its identity.
• When a message is sent to an object, the message
signature is compared to the operation signatures
defined in the object’s class, and if a match is found
the appropriate operation is invoked on the object.
 Parameter direction

• Operation parameters can be given a

direction:
• operation( in p1:Integer, inout p2:Integer,
out p3:Integer, return p4:Integer, return
p5:Integer )
• If the direction is not specified, then it
defaults to in.
 Parameter default values

• You can give an operation parameter a default

value.
• When the operation is called, if no value is
given for that parameter, its default value will
be used.
 Query operations

• Each operation has a property called

isQuery.
• Is query : true(no change ) on
• Is query : flase
example
 Scope

• There are two types of scopes

1)instance scope(object scope)
2)class scope.
• Scope.
• —Instance scope attributes and operations belong
to or operate on specific objects:
– –instance scope operations can access other instance
scope operations or instance scope attributes;
– –instance scope operations can access all class scope
attributes or operations.
• —Class scope attributes and operations belong
to, or operate on, the whole class of objects:
• –class scope attributes and operations can only
access other class scope operations.
 Instance scope
objects have their own attributes defined in
their class.
so that different objects can have different
attribute values.
Similarly, the operations that you have seen so
far all act on specific objects.
This is the normal case, and we say that these
attributes and operations have instance scope.
 Class scope
• Class scope attributes and operations belong
to, or operate on, the whole class of objects.
Notation of instance and class scope
 What Scope determines access

• Whether an operation can access another feature of the class or not is

determined by the scope of the operation and the scope of the feature it
is trying to access.

• Instance scope operations can access other instance scope attributes

and operations, and also all of the class scope attributes and operations.

• Class scope operations can only access other class scope operations
and attributes.

• Class scope operations can’t access instance scope operations because:

• there might not be any class instances created yet;
• even if class instances exist, you don’t know which one to use.
 Constructors & destructors
• Constructors are special operations that
create new instances of classes – these
operations must be class scope.
 Naming constructors
• Different languages have different standards
for naming constructors.
• A completely generic approach is just to call
the constructor create(…).

• Java, C#, and C++ all demand that the

constructor name is the same as the class
name.
 A class may have many constructors, all with the
same name,
but each distinguished by a different parameter
list.
The constructor with no parameters is known as
the default constructor.
You can use constructor parameters to initialize
attribute values at the point of object construction.
Example on constructor &destructors
• The numberOfMembers attribute is a private class scope
attribute of type int.
• This attribute is therefore shared by all objects of the Club
Member class, and will have the same value for each of those
objects.

• At the point at which the numberOfMembers attribute is

created, it is initialized to zero.
• Now, if this were an instance scope attribute,
• each object would get its own copy of it when the object
was created.
• However, it is class scope – this means that there is only
one copy, and this single copy is only initialized once.
• create(...) operation you invoke the class scope
operation incrementNumberOfmembers().
• As you might expect from its name, this operation
increments the value of the class scope attribute
numberOfMembers.
• Every time an instance of the class is created,
numberOfMembers is incremented – a counter has
been added to the class!
• You can query the value of numberOfMembers by
using the class scope operation
getNumberOfMembers(). This returns a number that is
equal to the number of ClubMember objects created.
 destructors

• Destructors are special operations that “clean

up” when objects are destroyed.
• an operation to the class to decrement
numberOfMembers, then ensuring that this
operation is called every time an instance of
ClubMember is destroyed.
• Some OO languages have special instance scope
operations called destructors that are
automatically called at the point of object
destruction.
• In C++, for example, the destructor is always of
the form ~ClassName( parameterList ).
• In C++ the destructor operation is guaranteed to
be called at the point at which an object is
destroyed.
 What is an interface?

• An interface specifies a named set of public features.

• Interfaces separate the specification of functionality from its

implementation.

• Interfaces may be attached to classes, subsystems,

components and any other classifier and define the services
offered by these.

• If a classifier inside a subsystem realizes a public interface then

the subsystem or component also realizes the public interface.
 Interface implementing specifications
• The attributes and operations in an interface
should be fully specified and should include:
• the complete operation signature (name, types
of all parameters, and return type);
• the semantics of the operation – this can be
recorded as text or pseudo-code;
• the name and type of the attributes;
• any operation or attribute stereotypes,
constraints and tagged values.
• Java is the first commonly used language to
introduce a specific language construct for
interfaces
 Types of interfaces
Provided interface - an interface provided by a classifier:
• the classifier realizes the interface;
• use the “class” style notation when you need to show
the operations on the model;
• use the shorthand “lollipop” style notation when you
just want to show the interface without operations.
Required interface - an interface required by a classifier:
• the classifier requires another classifier that realizes the
interface;
• show a dependency to a “class” style interface, a
“lollipop” style interface or use an assembly connector.
 The UML syntax for provided
interfaces
• There are two variants,
• The “class” style notation (on which you may
show the attributes and operations)
• The concise “lollipop” style notation (on which
you may not show the attributes and
operations).
• Interfaces are typically named just like classes
in UpperCamelCase.

• In Visual Basic and C# there is a common

standard to prefix each interface name with
uppercase I,
• for example IBorrow.
• Another naming idiom is to add “able” to the
end of the name.
• For example, Borrowable or IBorrowable.
 Realization relationship
• The realization relationship is the relationship
between a specification (in this case an
interface)
• the things that realize the specification (in
this case the classes Book and CD).
• In the “class” style notation, the realization
relationship is drawn as a dotted line with an
unfilled arrowhead.
• In “lollipop” style notation it becomes a single
solid line with no arrowhead.
shows the Library class that requires the Borrow interface.
You can show a required interface as a dependency to an interface (in either class or
lollipop notation) or as a socket into which the required interface fits.
shows the Library system assembled.
The assembly connector indicates that Book and CD both provide the

set of services (defined by Borrow) that the Library requires .

 Interface realization vs inheritance

• Interface realization - “realizes a contract

specified by”.
• Inheritance - “is a”.
Notice that the Library now has to maintain two lists of objects - those that are
borrowable, and those that are not.
This solution would work, but it is not very elegant as it mixes two very different
concerns of the Library:
storing objects;
borrowing objects.
We can improve this model somewhat by adding
an extra level in the inheritance hierarchy
A model that uses both interfaces and
inheritance provides a more elegant solution.
The advantages of this interface based solution are as follows:

• Every item in the Library is a LibraryItem - this makes

intuitive sense;
• we have factored out the notion of “borrowability” into
a separate interface, Borrowable, that we can apply to
LibraryItems as needed;
• we have fewer classes - five classes and one interface,
as opposed to seven classes for the other solution;
• we have fewer composition relationships - one as
opposed to two in the other solution;
• we have a simpler inheritance hierarchy with only two
levels;
 Package

• A package is the UML grouping thing –

• it is a container and owner for model elements.
• Each package has its own namespace within which all names
must be unique.

• It can be used to:

• provide an encapsulated namespace within which all names must
be unique;
• group semantically related elements;
• define a “semantic boundary” in the model;
• provide units for parallel working and configuration management.
• Analysis packages should contain:
• use cases.
• analysis classes.
• use case realizations.
 Syntax for package
• The package icon is a folder, and the package
name may be shown on the tab if package
contents are shown, or on the body of the
folder.
Package syntax
Visibility determines whether a package element is visible outside the package
or not.

UML provides two standard stereotypes to tailor the semantics of packages for
specific purposes – these are listed in Table 11.2.
• when an element in one namespace needs to
refer to an element in a different namespace,
• it has to specify both the name of the element
it wants, and a way to navigate through the
namespaces to that element.
• This navigation path is known as the qualified
name or pathname of the element.
 You create a qualified name by prefixing the element name with the names of the packages in which it resides, separated by a double colon.
You list the outermost package first, and then each package in order of nesting until you get to the element. Qualified names are very similar to path names in directory structures.
 Nested packages

• Packages may be nested inside other packages

to any depth.
• However, just two or three levels of nesting
are generally enough.
 Package dependencies

• A dependency relationship indicates that one

package depends in some way on another.
Types of dependecy
 Transitivity
• Transitivity is a term that applies to
relationships.
• It means that if there is a relationship
between thing A and thing B and a
relationship between thing B and thing C,
• then there is an implicit relationship between
thing A and thing C.
 Package generalization

• In package generalization,
• the more specialized child packages inherit the
public elements from their parent package.
• Child packages may add new elements, and
may override elements in the parent package
by providing an alternative element with the
same name.
Child packages inherit elements from their parent.
They may override parent elements. They may add new elements.