How to identify classes in class diagrams?

Explain
Depending on the context, classes in a class diagram can represent the main objects, interactions
in the application
Basic components of a class diagram
A class represents an object or a set of objects that share a common structure and behavior.
They're represented by a rectangle that includes rows of the class name, its attributes, and its
operations. When you draw a class in a class diagram, you're only required to fill out the top
row—the others are optional.
 Name: The first row in a class shape.

o Attributes: The second row in a class shape. Each attribute of the class is displayed on a
separate line.

o Methods: The third row in a class shape. Also known as operations, methods are displayed
in list format with each operation on its own line.

Member access modifiers

All classes have different access levels depending on the access modifier (visibility). Here are the
access levels with their corresponding symbols:
 Public (+)
 Private (-)
 Protected (#)
 Package (~)
 Derived (/)
 Static (underlined)

Additional class diagram components

 Signals
: Symbols that represent one-way, asynchronous communications between active objects.
 Data types:
Classifiers that define data values. Data types can model both primitive types and
enumerations.
 Packages:
Shapes designed to organize related classifiers in a diagram. They are symbolized with a
large tabbed rectangle shape.
 Interfaces:
 A collection of operation signatures and/or attribute definitions that define a cohesive set of
behaviors. Interfaces are similar to classes, except that a class can have an instance of its
type, and an interface must have at least one class to implement it.
 Enumerations:
Representations of user-defined data types. An enumeration includes groups of identifiers
that represent values of the enumeration.
 Objects:
Instances of a class or classes. Objects can be added to a class diagram to represent either
concrete or prototypical instances.
 Artifacts:
Model elements that represent the concrete entities in a software system, such as
documents, databases, executable files, software components, etc.

What are the Benefits of class diagrams

Class diagrams offer a number of benefits for any organization. Use UML class diagrams to:
 Illustrate data models for information systems, no matter how simple or complex.
 Better understand the general overview of the schematics of an application.
 Visually express any specific needs of a system and disseminate that information
throughout the business.
 Create detailed charts that highlight any specific code needed to be programmed and
implemented to the described structure.
 Provide an implementation-independent description of types used in a system that are
later passed between its components.

What is an object diagram? Explain identifying objects in object diagrams

A object diagram represents a specific instance of a class diagram at a certain moment in time.
When represented visually, we will see many similarities to the class diagram.
An object diagram focuses on the attributes of a set of objects and how those objects relate to
each other.
For instance, in this object diagram below, all three bank accounts tie back to the bank itself. The
class titles show the type of accounts (savings, checking, and credit card) that a given customer
could have with this particular bank. The class attributes are different for each account type. For
example, the credit card object has a credit limit, while the savings and checking accounts have
interest rates
 Fig: Object Diagram
Object diagram elements
Object diagrams are simple to create: they're made from objects, represented by rectangles, linked
together with lines. Take a look at the major elements of an object diagram.
Objects
Objects are instances of a class. For example, if "car" is a class, a 2007 Nissan Altima is an object
of a class.
Class titles
Class titles are the specific attributes of a given class. In the family tree object diagram, class
titles include the name, gender, and age of the family members. You can list class titles as items
on the object or even in the properties of the object itself (such as color).
Class attributes
Class attributes are represented by a rectangle with two tabs that indicates a software element.
Links
Links are the lines that connect two shapes of an object diagram to each other.

Fig: Object Diagram

What are advanced relationships in UML? Explain.
The things in diagrams are connected with one another through relationships.

Advanced Relationships can be categorized as:

 Dependency
 Generalization
 Association
 Realization

Dependency

 Specifying a change in the specification of one thing may affect another thing, but not
necessarily the reverse
 Graphically rendered as a dashed line
 There are eight stereotypes that apply to dependency relationships among classes and
objects in class diagrams

bind The source instantiates the target template

derive The source may be computed from target

friend The source is given special visibility into target

instanceOf Source object is an instance of the target classifier

instantiate Source object creates instance of the target

powertype Target is a powertype of the source

Refine Source is at a finer degree of abstraction than target

Use The semantics of the source element depends on the semantics of the public part
of the target
Examples:

 <<bind>>

 <<derive>>

 <<friend>>

 <<instanceOf>>

 <<instantiate>>

 <<powertype>>

 <<refine>>
  <<use>>

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

 <<access>>

 <<import>>

Two stereotypes that apply to dependency relationships among use case

 Extend - Target use case extends the behaviour of source

 Include - Source use case explicitly incorporates the behaviour of another use case at
a location specified by the source

 <<extend>>

 <<include>>

Three stereotypes when modelling interactions among objects

 Become - Target is the same object of source at later time

 Call - Source operation invokes the target operation
  Copy –target is exact, but independent copy of the source.

 Examples:
 <<become>>

 <<call>>

 <<copy>>

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 a historical ancestor of the source (model relationship among

elements in different models)

Example:

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.
Shape class is the parent or super class and the remaining three classes namely Rectangle,
Circle and Polygon are the child or subclasses of the Shape class.
A subclass in the generalization relationship automatically inherits the state and behavior of
the superclass. 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.

To represent extra semantics in a generalization relationship, UML provides one stereotype

and four constraints. The stereotype on generalization relationship is:

There are four standard constraints that apply to the generalization relationship:

AssociationAssociation 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. In some
cases we may need to navigate in only direction. For example, given an order, we can get the
details of the products in the order. But, if we consider a product, there might be no need to
know about the order to which it belongs.
Visibility Given an association, we can navigate from one object to another. However, in some
situations we may want to limit the visibility (access) of an object to the objects outside the
association relationship.
To limit the visibility of an object, we can use the visibility specifiers: public (+), private (-)
and protected (#). For example, a usergroup object can access the user object and an user
object can access the password. If, private visibility is specified for the password object, the
usergroup object cannot access the password of the user object.

Qualification In binary associations, where two classes are connected together, if one object
of a class has to identify a set of instances of another class, we can use qualifiers. 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.

Composition The composition is a flavor of association relationship. Composition as well as

aggregation relationships represent whole-part relationships, in which one thing is a part of
the other thing.
There is a simple difference between the association and composition relationships. In
composition, the lifetime of the part is dependent of the lifetime of the whole thing. Where as
in aggregation, the lifetime of the part is independent of the whole thing.
Composition is graphically represented by adorning the association relationship with a filled
diamond head near the whole end.

Association Class Sometimes in an association relationship, the association might have

attributes or properties like a class does. In such cases, it is modeled as an association class.
An association class in UML is represented with a class icon attached to the association with
a dashed line.
Apart from the above advanced features, UML provides six constraints that can be applied to
an association. They are:

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 a 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.
Write and explain terms and concepts of interfaces, types and roles. [7M]
Interface
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; in its expanded
form, an interface may be rendered as a stereotyped class(a class with sterotype interface).

An interface name must be unique within its enclosing package. Two naming mechanism; a
simple name(only name of the interface)as shown

Figure:1

a path name is the interface name prefixed by the name of the package in which that interface
lives represented in Figure: 2.

Figure:2
To distinguish an interface from a class, prepend an ‗I‘ to every interface name. Operations in
an interface may be adorned with visibility properties, concurrency properties, stereotypes,
tagged values, and constraints. Interface don‘t have attributes. Interfaces span model
boundaries and it does‘nt have direct instances.

Interface relationships

An interface may participate in generalization, association, dependency and realization

relationships.
Note: Interfaces may also be used to specify a contract for a use case or subsystem.

Type
A type is a stereotype of a class used to specify a domain of objects, together with the
operations (but not the methods) applicable to the object of that type. To distinguish a type
from an interface or a class, prepend a ‗T‘ to every type. Stereotype type is used to formally
model the semantics of an abstraction and to a specific interface.

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, PayerOfBills, Employee, Customer, Manager, Pilot,
Singer, and so on. When an object plays a particular role, it presents a face to the world, and
clients that interact with it expect a certain behavior depending on the role that it plays at the
time.

For example, an instance of Person in the role of Manager would present a different set of
properties than if the instance were playing the role of Mother. Figure:3 indicates a role
employee played by person and is represented statically there.

Figure: 3

In Figure:3 the Person presents the role of Employee to the Company, and in that context,
only the properties specified by Employee are visible and relevant to the Company.
Static and Dynamic modeling in UML

A class diagram that indicates a particular role is useful for modeling the static binding of an
abstraction to its interface. To model the dynamic binding of an abstraction to its interface by using
the become stereotype in an interaction diagram, showing an object changing from one role to
another.

To model a dynamic type,

Specify the different possible types of that object by rendering each type as a class stereotyped as
type (if the abstraction requires structure and behavior) or as interface (if the abstraction requires
only behavior).

Model all the roles the class of the object may take on at any point in time. It can be done in two
ways:

First, in a class diagram, explicitly type each role that the class plays in its association with other
classes. Doing this specifies the face instances of that class put on in the context of the associated
object.

Second, also in a class diagram, specify the class-to-type relationships using generalization

In an interaction diagram, properly render each instance of the dynamically typed class. Display the
role of the instance in brackets below the object’s name.

To show the change in role of an object, render the object once for each role it plays in the
interaction, and connect these objects with a message stereotyped as become.

They are represented in the following figures:

Figure:4 Static modeling

Figure:4 shows statically that instances of the Person class may be any of the three types namely,
Candidate, Employee, or Retiree.

Figure:5 Dynamic-modeling

Figure:5 shows the dynamic nature of a person’s type. In this fragment of an interaction diagram, p
(the Person object) changes its role from Candidate to Employee.
Explain common modeling techniques of class.
To model the semantics of a class:
 Specify the responsibilities of the class in a note and attach it to the class with a
dependency relationship.
 Specify the semantics of a class as a whole in a note stereotyped with ―semantics‖.
 Specify the body of a method using structured text or a programming language in a
note and attach it to the class or operation using a dependency relationship.
 Specify the pre-conditions and post-conditions for operations using structured text in
a note.
 Specify a state machine for a class which represents different states the object
undergoes.
 Specify a collaboration that represents a class.

What are common modeling techniques of advanced relationships? Explain. [7M]

1. Apply use cases and scenarios to find the relationships between the abstractions in the
system.
2. Start by modeling the structural relationships (associations) between the things. These
specify the structure of the system.
3. Then, model the generalization-specialization relationships.
4. Finally, after modeling the remaining relationships go for dependency relationships.
5. After representing all the relationships, transform their basic representation by applying
the advanced features to your intent.

What is a package diagram?

Package diagrams are structural diagrams used to show the organization and arrangement of
various model elements in the form of packages. A package is a grouping of related UML
elements, such as diagrams, documents, classes, or even other packages. Each element is
nested within the package, which is depicted as a file folder within the diagram, then
arranged hierarchically within the diagram. Package diagrams are most commonly used to
provide a visual organization of the layered architecture.
 Benefits of a package diagram

A well-designed package diagram provides numerous benefits to those looking to create a

visualization of their UML system or project.
 They provide a clear view of the hierarchical structure of the various UML elements within
a given system.
 These diagrams can simplify complex class diagrams into well-ordered visuals.
 They offer valuable high-level visibility into large-scale projects and systems.
 Package diagrams can be used to visually clarify a wide variety of projects and systems.
 These visuals can be easily updated assystems and projects evolve.
 Basic components of a package diagram
The makeup of a package diagram is relatively simple. Each diagram includes only two
symbols:

Symbol
Symbol Image Description
Name

Groups common elements based on data, behavior,

Package
or user interaction

Depicts the relationship between one element

Dependency
(package, named element, etc) and another

These symbols can be used in a variety of ways to represent different iterations of packages,
dependencies, and other elements within a system. Here are the basic components you‘ll find
within a package diagram:

 Package: A namespace used to group together logically related elements within a system.
Each element contained within the package should be a packageable element and have a
unique name.

 Packageable element: A named element, possibly owned directly by a package. These can
include events, components, use cases, and packages themselves. Packageable elements
can also be rendered as a rectangle within a package, labeled with the appropriate name.

 Dependencies: A visual representation of how one element (or set of elements) depends on
or influences another. Dependencies are divided into two groups: access and import
dependencies. (See next section for more info.)

 Element import: A directed relationship between an importing namespace and an imported

packageable element. This is used to import select individual elements without resorting to
a package import and without making it public within the namespace.

 Package import: A directed relationship between and importing namespace and an

imported package. This type of directed relationship adds the names of the members of the
imported package to its own namespace

 Package merge: A directed relationship in which the contents of one package are extended
by the contents of another. Essentially, the content of two packages are combined to
produce a new package.