OBJECT ORIENTED CONCEPTS,UML DIAGRAMS,DFD

Introduction to OO concepts, UML Use Case Diagram-Include Extend and Generalization, Class
Diagram-Aggregation and Composition, Object Diagram-Component Diagram-Sequence and
Collaboration diagram-Deployment diagram-Activity diagram-Package diagram-Design with
examples of UML diagrams

1. UNIT 3 OBJECT ORIENTED CONCEPTS
Introduction to OO concepts, UML Use Case Diagram-Include Extend and Generalization, Class
Diagram-Aggregation and Composition, Object Diagram-Component Diagram-Sequence and
Collaboration diagram-Deployment diagram-Activity diagram-Package diagram-Design with
examples of UML diagrams
Introduction to OO concepts:
Characteristics of OO System −
• Objects − An object is something that is exists within problem domain and can be identified by data
(attribute) or behavior. All tangible entities (student, patient) and some intangible entities (bank
account) are modeled as object.
• Attributes − They describe information about the object.
• Behavior − It specifies what the object can do. It defines the operation performed on objects.
• Class − A class encapsulates the data and its behavior. Objects with similar meaning and purpose
grouped together as class.
• Methods − Methods determine the behavior of a class. They are nothing more than an action that an
object can perform.
• Message − A message is a function or procedure call from one object to another. They are information
sent to objects to trigger methods. Essentially, a message is a function or procedure call from one object
to another.
Features of Object-Oriented System
Encapsulation
Encapsulation is a process of information hiding. It is simply the combination of process and data into a single
entity. Data of an object is hidden from the rest of the system and available only through the services of the
class. It allows improvement or modification of methods used by objects without affecting other parts of a
system.
Abstraction
It is a process of taking or selecting necessary method and attributes to specify the object. It focuses on
essential characteristics of an object relative to perspective of user.
Relationships
All the classes in the system are related with each other. The objects do not exist in isolation, they exist in
relationship with other objects.
There are three types of object relationships −
• Aggregation − It indicates relationship between a whole and its parts.
• Association − In this, two classes are related or connected in some way such as one class works with
another to perform a task or one class acts upon other class.
• Generalization − The child class is based on parent class. It indicates that two classes are similar but
have some differences.

2. Inheritance
Inheritance is a great feature that allows to create sub-classes from an existing class by inheriting the attributes
and/or operations of existing classes.
Polymorphism and Dynamic Binding
Polymorphism is the ability to take on many different forms. It applies to both objects and operations. A
polymorphic object is one who true type hides within a super or parent class.
In polymorphic operation, the operation may be carried out differently by different classes of objects. It allows
us to manipulate objects of different classes by knowing only their common properties.
Structured Approach Vs. Object-Oriented Approach
The following table explains how the object-oriented approach differs from the traditional structured approach
−
Structured Approach Object Oriented Approach
It works with Top-down approach. It works with Bottom-up approach.
Program is divided into number of submodules or
functions.
Program is organized by having number of classes and
objects.
Function call is used. Message passing is used.
Software reuse is not possible. Reusability is possible.
Structured design programming usually left until end
phases.
Object oriented design programming done concurrently
with other phases.
Structured Design is more suitable for offshoring. It is suitable for in-house development.
It shows clear transition from design to implementation. Not so clear transition from design to implementation.
It is suitable for real time system, embedded system and
projects where objects are not the most useful level of
abstraction.
It is suitable for most business applications, game
development projects, which are expected to customize
or extended.
DFD & E-R diagram model the data. Class diagram, sequence diagram, state chart diagram,
and use cases all contribute.
In this, projects can be managed easily due to clearly
identifiable phases.
In this approach, projects can be difficult to manage due
to uncertain transitions between phase.

3. Unified Modeling Language (UML)
UML is a visual language that lets you to model processes, software, and systems to express the design of
system architecture. It is a standard language for designing and documenting a system in an object oriented
manner that allow technical architects to communicate with developer.
It is defined as set of specifications created and distributed by Object Management Group. UML is extensible
and scalable.
The objective of UML is to provide a common vocabulary of object-oriented terms and diagramming
techniques that is rich enough to model any systems development project from analysis through
implementation.
UML is made up of −
• Diagrams − It is a pictorial representations of process, system, or some part of it.
• Notations − It consists of elements that work together in a diagram such as connectors, symbols, notes,
etc.
Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of
object-oriented software engineering. UML includes a set of graphic notation techniques to create visual
models of object-oriented software systems. UML combines techniques from data modeling, business
modeling, object modeling, and component modeling and can be used throughout the software
development life-cycle and across different implementation technologies.

UML diagrams represent two different views of a system model:
Static (or structural) view
This view emphasizes the static structure of the system using objects,
attributes, operations, and relationships. Ex: Class diagram, Composite
Structure diagram.
Dynamic (or behavioral) view
This view emphasizes the dynamic behavior of the system by showing collaborations
among objects and changes to the internal states of objects. Ex: Sequence diagram, Activity
diagram, State Machine diagram.

4. Diagrams Overview
UML has 14 types of diagrams divided into multiple categories as shown in the figure below.






Use Case Diagrams
What is a use case?
• A requirements analysis concept
• A case of a use of the system/product
• Describes the system's actions from a the point of view of a user
• Tells a story
• A sequence of events involving
• Interactions of a user with the system
• Specifies one aspect of the behavior of a system,
without specifying the structure of the system
• Is oriented toward satisfying a user's goal
How do we describe use cases?

• Textual or tabular descriptions
• User stories
• Diagrams
Use Case Descriptions
• actors - something with a behavior or role, e.g., a person, another system, organization.
• scenario - a specific sequence of actions and interactions between actors and the system, a.k.a. a use case
instance
• use case - a collection of related success and failure scenarios, describing actors using the system to
support a goal.

5. What is an Actor?
• Include all user roles that interact with the system
• Include system components only if they responsible for
initiating/triggering a use case.
For example, a timer that triggers sending of an e-mail reminder
• primary - a user whose goals are fulfilled by the system
importance: define user goals
• supporting - provides a service (e.g., info) to the system
importance: clarify external interfaces and protocols
• offstage - has an interest in the behavior but is not primary or supporting, e.g., government
importance: ensure all interests (even subtle) are identified and satisfied

Use Case Diagram Objective:
• Built in early stages of development
•  Purpose
• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts and domain experts

Example Use-Case Diagram

6. Elements of use case diagram:

Actor
Use case

Connection between Actor and Use Case


Boundary of system



<<include>>
Include relationship between Use Cases (one UC must
call another; e.g., Login UC includes User Authentication UC)


<<extend>>
Extend relationship between Use Cases (one UC calls Another under
certain condition; think of if-then decision points)
Linking Use Cases
• Association relationships
• Generalization relationships
• One element (child) "is based on" another element
(parent)
• Include relationships
• One use case (base) includes the functionality of
another (inclusion case)
• Supports re-use of functionality

7. base
<<extend>>
extending
base
<<include>>
included
• Extend relationships
• One use case (extension) extends the behavior of
another (base)
Generalization

• The child use case inherits the
behavior and meaning of the parent
use case.
• The child may add to or
override the behavior of its parent.

Include

• The base use case explicitly incorporates the behavior of another use case
at a location specified in the base.
• The included use case never stands alone. It only occurs as a part of some
larger base that includes it.

Extend

• The base use case implicitly incorporates the behavior of another use case at
certain points called extension points.
• The base use case may stand alone, but under certain conditions its behavior
may be extended by the behavior of another use case.




parent
child

8. CLASS DIAGRAM

• To understand the need for class diagrams
• To know the elements involved in the class diagrams
▫ Class
▫ Visibility
▫ Multiplicity
▫ Association
▫ Generalization-specialization
▫ Dependence
▫ Realization
▫ Aggregation
▫ Composition
INTRODUCTION
The class diagram shows the different classes involved and the
relationships between different classes. The class also shows the details like
the attributes and the operations carried out by that class. The relationships
describe the details like visibility, multiplicity etc.
NEED FOR CLASS DIAGRAM
The purpose of a class diagram is to model the static view of an
application. This is the only diagram which finds direct relation to object
oriented languages and thus can be extensively used at the time of
construction. This diagram helps in the analysis and design of the static
elements of an application. They describe the responsibilities of the system
from the implementation point of view. This diagram can help in the
development of the component and deployment diagrams.


This is the most common diagram used in the UML. The class diagram
consists of classes, interfaces, relationships and collaborations. This diagram
basically represents the object oriented view of a system which is static in
nature. It is generally used for development purpose. This is the most widely
used diagram at the time of construction of the system.

9. CREATING CLASS DIAGRAM
Since this diagram is very much useful in the construction of the application,
there is need to study the class diagram in detail.
• Decide which classes, interfaces should be involved.
• Find out the relationships among these elements.
• Identify the responsibilities (attributes and operations) for each class
and operations for the interfaces.
• Specify only the most required responsibilities. Do not clutter the classes
and interfaces with unwanted information.


ELEMENTS OF CLASS DIAGRAM

Class
A class is represented as a rectangle with three compartments. The top
compartment is used to write the name of the class. The middle
compartment is used for listing the attributes of that class and the last
compartment is used to list the operations of that class.
Sometimes if there is no need to show all the attributes and operations
simple write the class name in a rectangle which is not compartmentalized.
Sometimes more compartments can also be used. In this case the
compartments are named and the corresponding responsibilities are written
below the compartment name.

10. Reservation


operations
guarantee()
cancel ()
change (newDate: Date)
responsibilities
bill no-shows
match to available rooms


exceptions
invalid credit card

Visibility
There are three types of visibility modes available with the UML as with
many other object oriented languages. These are public (seen by all), private
(seen by itself) and protected (seen by the derived/child/subclass only).
These modes can be used with the responsibilities of a class or roles in the
associations.
This is shown by the symbols + for public, - for private and # for protected.
These symbols precede the name of the attribute, operation or role.
+size, -attach( ), #draw( ), +user, -password
Multiplicity
The classes involved in a relationship may have a relationship which is one-
to- one, one-to-many or many-to-many. That means one instance of a class
may be related to one instance of another class, one instance of a class may
be related to many instances of another class, or many instances of a class
may be related to many instances of another class. This is indicated by a
number or n or m or *.

11. Association
It is the simplest relationship that can exist between a pair of classes. The association can
have multiplicity. This relationship can also be identified by a name. Also a direction of the
relationship may be specified. The role of the participating classes also can be mentioned.
It is shown by a plain line joining two classes.





Generalization-specialization
This is the same kind of relationship which was explained under inheritance.




This is the equivalent of the superclass -subclasses hierarchy.

12. Dependence
When one class changes due to the change in another class, the relationship between
these classes is shown by this relationship. This is shown by a dashed line with normal
arrowhead.


Realization
This is typically shown between a use case and the collaboration or an interface and the
class or component implementing it.


Aggregation
This is a whole-part relationship. Here the part could be part of more than one whole. This
is a weak relationship. When the whole is deleted the part may still exist. This is
represented by a diamond at the end of an association link. The diamond is toward the
whole end.


Composition
This is a whole-part relationship. Here the part is a part of exactly one whole. This is a
strong relationship. When the whole is deleted the part also gets deleted. This is
represented by a filled diamond at the end of an association link. The diamond is toward
thewholeend.

13. Class Diagram: Describes the structure of a system by showing the system’s classes,
their attributes, and the relationships among the classes.




Association vs Aggregation vs Composition

Aggregation and Composition are subsets of association meaning they are specific cases of
association. In both aggregation and composition object of one class "owns" object of another
class. But there is a subtle difference:
• Aggregation implies a relationship where the child can exist independently of the
parent. Example: Class (parent) and Student (child). Delete the Class and the Students
still exist.
• Composition implies a relationship where the child cannot exist independent of the
parent. Example: House (parent) and Room (child). Rooms don't exist separate to a
House.

Composition Example:

We should be more specific and use the composition link in cases where in addition to the part-
of relationship between Class A and Class B - there's a strong lifecycle dependency between the

14. two, meaning that when Class A is deleted then Class B is also deleted as a result



Aggregation Example:

It's important to note that the aggregation link doesn't state in any way that Class A owns
Class B nor that there's a parent-child relationship (when parent deleted all its child's are being
deleted as a result) between the two. Actually, quite the opposite! The aggregation link is
usually used to stress the point that Class A instance is not the exclusive container of Class B
instance, as in fact the same Class B instance has another container/s.





Summing it up -
To sum it up association is a very generic term used to represent when one class used the
functionalities provided by another class. We say it's a composition if one parent class object
owns another child class object and that child class object cannot meaningfully exist without
the parent class object. If it can then it is called Aggregation

15. Object Diagram
Objects are the real-world entities whose behavior is defined by the classes. Objects are used to
represent the static view of an object-oriented system. We cannot define an object without its
class. Object and class diagrams are somewhat similar.

Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts are similar for
class diagrams and object diagrams. Object diagrams also represent the static view of a system
but this static view is a snapshot of the system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an instance
Sr.
No.
Key Composition Aggregation

1

Basic

Composition(mixture) is a way to
wrap simple objects or data types
into a single unit

Aggregation(collection) differs from
ordinary composition in that it does not
imply ownership

2

Relationship

In composition, parent entity owns
child entity.

In Aggregation, parent Has-A
relationship with child entity

3

UML
Notation

It is denoted by a filled diamond.

It is denoted by an empty diamond.

4.

Life cycle

Child doesn’t have their own life
time

Child can have their own life time

5.

Association

It is a strong association

It is a weak association

16. Purpose of Object Diagrams

The purpose of a diagram should be understood clearly to implement it practically. The
purposes of object diagrams are similar to class diagrams.
The difference is that a class diagram represents an abstract model consisting of classes and
their relationships. However, an object diagram represents an instance at a particular
moment, which is concrete in nature.
It means the object diagram is closer to the actual system behavior. The purpose is to capture
the static view of a system at a particular moment.
The purpose of the object diagram can be summarized as −
• Forward and reverse engineering.
• Object relationships of a system
• Static view of an interaction.
• Understand object behaviour and their relationship from practical perspective

How to Draw an Object Diagram?

We have already discussed that an object diagram is an instance of a class diagram. It implies
that an object diagram consists of instances of things used in a class diagram.
So both diagrams are made of same basic elements but in different form. In class diagram
elements are in abstract form to represent the blue print and in object diagram the elements
are in concrete form to represent the real world object.
To capture a particular system, numbers of class diagrams are limited. However, if we consider
object diagrams then we can have unlimited number of instances, which are unique in nature.
Only those instances are considered, which have an impact on the system.
From the above discussion, it is clear that a single object diagram cannot capture all the
necessary instances or rather cannot specify all the objects of a system. Hence, the solution is
−
• First, analyze the system and decide which instances have important data and
association.
• Second, consider only those instances, which will cover the functionality.
• Third, make some optimization as the number of instances are unlimited.
Before drawing an object diagram, the following things should be remembered and
understood clearly −
• Object diagrams consist of objects.
• The link in object diagram is used to connect objects.

17. • Objects and links are the two elements used to construct an object diagram.
After this, the following things are to be decided before starting the construction of the
diagram −
• The object diagram should have a meaningful name to indicate its purpose.
• The most important elements are to be identified.
• The association among objects should be clarified.
• Values of different elements need to be captured to include in the object diagram.
• Add proper notes at points where more clarity is required.
The following diagram is an example of an object diagram. It represents the Order
management system.. The following diagram is an instance of the system at a particular time
of purchase. It has the following objects.
• Customer
• Order
• SpecialOrder
• NormalOrder





Now the customer object (C) is associated with three order objects (O1, O2, and O3). These
order objects are associated with special order and normal order objects (S1, S2, and N1). The
customer has the following three orders with different numbers (12, 32 and 40) for the
particular time considered.

18. The customer can increase the number of orders in future and in that scenario the object
diagram will reflect that. If order, special order, and normal order objects are observed then
you will find that they have some values.
For orders, the values are 12, 32, and 40 which implies that the objects have these values for a
particular moment (here the particular time when the purchase is made is considered as the
moment) when the instance is captured
The same is true for special order and normal order objects which have number of orders as
20, 30, and 60. If a different time of purchase is considered, then these values will change
accordingly.
The following object diagram has been drawn considering all the points mentioned above

Where to Use Object Diagrams?

Object diagrams can be imagined as the snapshot of a running system at a particular moment.
Let us consider an example of a running train
Now, if you take a snap of the running train then you will find a static picture of it having the
following −
• A particular state which is running.
• A particular number of passengers. which will change if the snap is taken in a different
time
Here, we can imagine the snap of the running train is an object having the above values. And
this is true for any real-life simple or complex system.
In a nutshell, it can be said that object diagrams are used for −
• Making the prototype of a system.
• Reverse engineering.
• Modeling complex data structures.
• Understanding the system from practical perspective


The difference between the class and object diagram is that the class diagram mainly
represents the bird's eye view of a system which is also referred to as an abstract view. An
object diagram describes the instance of a class. It visualizes the particular functionality of a
system.

19. Notation of an object diagram:













Object Notation

Object diagram example:


The above UML object diagram contains two objects named Ferrari and BMW which belong to
a class named as a Car. The objects are nothing but real-world entities that are the instances of
a class.
Applications of Object Diagrams:

1. Object diagrams play an essential role while generating a blueprint of an object-oriented
system.
2. Object diagrams provide means of modeling the classes, data and other information as a
set or a single unit.
3. It is used for analyzing the online or offline system. The functioning of a system can be
visualized using object diagrams.

20. UML Component Diagram
A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system
such as executables, files, libraries, etc. that resides within the node.

It visualizes the relationships as well as the organization between the components present in
the system. It helps in forming an executable system. A component is a single unit of the
system, which is replaceable and executable. The implementation details of a component are
hidden, and it necessitates an interface to execute a function. It is like a black box whose
behavior is explained by the provided and required interfaces.

Notation of a Component Diagram

a) A component



b) A node

21. Purpose of a Component Diagram

Since it is a special kind of a UML diagram, it holds distinct purposes. It describes all the
individual components that are used to make the functionalities, but not the functionalities of
the system. It visualizes the physical components inside the system. The components can be a
library, packages, files, etc.

The component diagram also describes the static view of a system, which includes the
organization of components at a particular instant. The collection of component
diagrams represents a whole system.

The main purpose of the component diagram are enlisted below:

1. It envisions each component of a system.
2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.

Why use Component Diagram?

The component diagrams have remarkable importance. It is used to depict the functionality
and behavior of all the components present in the system, unlike other diagrams that are
used to represent the architecture of the system, working of a system, or simply the system
itself.

In UML, the component diagram portrays the behavior and organization of components at
any instant of time. The system cannot be visualized by any individual component, but it can
be by the collection of components.

Following are some reasons for the requirement of the component diagram:

1. It portrays the components of a system at the runtime.
2. It is helpful in testing a system.
3. It envisions the links between several connections.

When to use a Component Diagram?

It represents various physical components of a system at runtime. It is helpful in visualizing
the structure and the organization of a system. It describes how individual components can
together form a single system. Following are some reasons, which tells when to use
component diagram:

1. To divide a single system into multiple components according to the functionality.
2. To represent the component organization of the system.

22. How to Draw a Component Diagram?

The component diagram is helpful in representing the physical aspects of a system, which are
files, executables, libraries, etc. The main purpose of a component diagram is different from
that of other diagrams. It is utilized in the implementation phase of any application.

Once the system is designed employing different UML diagrams, and the artifacts are
prepared, the component diagram is used to get an idea of implementation. It plays an
essential role in implementing applications efficiently.

Following are some artifacts that are needed to be identified before drawing a component
diagram:

1. What files are used inside the system?
2. What is the application of relevant libraries and artifacts?
3. What is the relationship between the artifacts?

Following are some points that are needed to be kept in mind after the artifacts are identified:

1. Using a meaningful name to ascertain the component for which the diagram is about
to be drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.
Example of a Component Diagram

A component diagram for an online shopping system is given below:

23. Where to use Component Diagrams?

The component diagram is a special purpose diagram, which is used to visualize the static
implementation view of a system. It represents the physical components of a system, or we
can say it portrays the organization of the components inside a system. The components, such
as libraries, files, executables, etc. are first needed to be organized before the implementation.

The component diagram can be used for the followings:

1. To model the components of the system.
2. To model the schemas of a database.
3. To model the applications of an application.
4. To model the system's source code.
UML: SEQUENCE DIAGRAM

Each use case involves different interactions between a set of objects.
These interactions follow a certain sequence to get the job done. The
sequence diagram shows the interaction based on the time ordering.

NEED FOR SEQUENCE DIAGRAM


To understand how the different objects interact with each other, some
type of interaction diagram is necessary. If there is a need to understand in
what sequence the interaction takes place, the sequence diagram is best
suited for the purpose. This diagram is best suited to explore the different
scenarios or flows of a particular use case. This diagram also helps
understand which classes are needed for the interaction. These diagrams can
be easily drawn. They are also easy to understand for the developers and
clients. These diagrams basically display their lifelines of participants as they
exchange messages. A lifeline shows the life of the participating object by
showing the relevant events that are important to the object in that
interaction.
CREATING SEQUENCE DIAGRAM
There is no need to draw sequence diagram for each and every use
case and each and every scenario of the use cases.
• All the use cases are to be studied well and then which of them are
likely to be complex is to be found out. If the interaction is a typical
one, then you may safely ignore that particular use case.

24. • One by one pick up the use cases which were listed in the above step.
Explore all the scenarios of to find out which are not routine ones. Pick
up only those which have complex interaction involved.
• Use the same actor from the use case diagram who initiated that use
case.
• Find out which other objects need to interact to fulfill the functionality
suggested by the chosen use case and its scenarios.
• Decide on the sequence of messages required to be exchanged to fulfill
the requisite functionality. Also find out which object is sending the
message and which one is receiving as well as what message is passed.
• Determine the type of the interaction i.e. whether it is synchronous,
asynchronous, return, creation of object, or destruction of object.
• Draw the objects at the top with the initiating actor at the extreme left.
• Below each of the above objects including the actor draw vertical
dashed lines to indicate the lifelines.
• Show interactions between the objects by drawing horizontal arrows
between the corresponding lifelines. (To decide the type of arrow
consider the type of the interaction determined above)
• Write text along the arrow to indicate the message passed. The
message could plain text or it could be function or procedure call.
• Put a box around all these to indicate that this is interaction for one
particular use case.
• At the top left corner using a special notation write the name of the
corresponding use case.

ELEMENTS OF SEQUENCE DIAGRAM

Object
The objects if known or the classes are shown using a rectangular box with name written
inside it. If the object is known write inside the box the_object_name: the_class_name to
indicate which class the object is an instance of. If the object is not known simply write
:the_class_ name. If it is an actor then the stick figure is used.

25. Lifeline
The lifeline is shown vertical with a dashed line starting from the corresponding

actor going down till after the last interaction.



Synchronous message
An object passes a message and waits till it receives some reply from the
recipient object. If one object asks another object to calculate salary and it wants
to get back the result so that it can print the salary slip, then this type of message
is used. It is denoted by a line with a plain arrowhead.


Asynchronous message
When a message is passed by one object to another, and the sender object does
not wish to wait till the action is carried out by the other object, this type of

message is used. It is denoted by a line with a triangular filled block head.
Return
This is used to indicate return from a call. It is not mandatory to show the return
arrow. It can be assumed that the recipient carries out its job correctly and if
asked returned the requisite information. It is denoted by a dashed line with a
plain arrowhead.

26. Creation of object
During the interaction some object is not required from the beginning and it has
to be created explicitly then message is used. It is shown as given below.
Destruction of object
During the interaction some object has to be destroyed explicitly this type of
message is used. On the lifeline of the object which is to be destroyed a cross is
drawn at the end of the arrow.

Looping
There might be a situation in which there is a need to perform some set of interactions
again and again. This is a place which is a situation where a loop is required. Within a
sequence diagram all the steps which need to be repeated are picked up. A box put around
these steps. In the top left corner in a rectangle with the right bottom corner removed is
placed. Inside this corner rectangle, the looping condition is written. The syntax for this is
loop minint, maxint,[guard]

27. Naming the sequence diagram
Every sequence diagram has to be given an identity. This identity is specified
by the name of the use case for which the particular sequence diagram is

drawn. This is written in a rectangle with the lower right corner cut off.


The sequence diagrams are used to clarify the complexity in the execution of any interaction.
Here only the complex scenarios for use cases are modeled. This diagram gives the time
ordering of the interactions

28. The below example shows how objects communicate with each other in terms of a sequence of
messages. Also indicates the lifespans of objects relative to those messages

29. UML: Collaboration Diagram
The collaboration diagram is used to show the relationship between the objects in a system.
Both the sequence and the collaboration diagrams represent the same information but
differently. Instead of showing the flow of messages, it depicts the architecture of the object
residing in the system as it is based on object-oriented programming. An object consists of
several features. Multiple objects present in the system are connected to each other. The
collaboration diagram, which is also known as a communication diagram, is used to portray the
object's architecture in the system.

Notations of a Collaboration Diagram

1. Objects: The representation of an object is done by an object symbol with its name and
class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is
specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the
use case.
3. Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to
another object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and
includes a sequence number, so that the activity may take place. It is represented by a
labeled arrow, which is placed near a link. The messages are sent from the sender to the
receiver, and the direction must be navigable in that particular direction. The receiver
must understand the message.

30. When to use a Collaboration Diagram?

The collaborations are used when it is essential to depict the relationship between the object.
Both the sequence and collaboration diagrams represent the same information, but the way of
portraying it quite different. The collaboration diagrams are best suited for analyzing use cases.

Following are some of the use cases enlisted below for which the collaboration diagram is
implemented:

1. To model collaboration among the objects or roles that carry the functionalities of use
cases and operations.
2. To model the mechanism inside the architectural design of the system.
3. To capture the interactions that represent the flow of messages between the objects
and the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a collaboration
of several objects and interactions.
5. To support the identification of objects participating in the use case.
6. In the collaboration diagram, each message constitutes a sequence number, such that
the top-level message is marked as one and so on. The messages sent during the same

31. call are denoted with the same decimal prefix, but with different suffixes of 1, 2, etc. as
per their occurrence.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are specified.
2. Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and
operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence
diagram for summarizing alternative situations.

Example of a Collaboration Diagram

32. Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.
2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how
lifelines are connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram; just the
difference is that the lifeline does not consist of tails.
4. The messages transmitted over sequencing is represented by numbering each individual
message.
5. The collaboration diagram is semantically weak in comparison to the sequence diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence diagram can be
directly converted to the collaboration diagram.
9. There may be a chance of losing some amount of information while implementing a
collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration diagram, as it
becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on every
single that has occurred inside the object of a system.

Difference between Sequence diagram and Collaboration diagram

A Sequence diagram is an interaction diagram that details about the operation that is carried
out. The sequence diagram captures the interaction between the objects in the context of
collaboration. Sequence diagrams are time focused and they show the order of the interaction
visually by using the vertical axis of the diagram to represent time.

33. Example:

Collaboration Diagram represents the interaction of the objects to perform the behavior of a
particular use case or a part of use case. The designers use the Sequence diagram and
Collaboration Diagrams to define and clarify the roles of the objects that perform a particular
flow of events of a use case.
Example:

34. Similarities Between Sequence and Collaboration Diagram
1. In Unified Modelling Language both the sequence diagram and collaboration diagram are
used as interaction diagrams.
2. Both the diagrams details about the behavioral aspects of the system.

Differences Between Sequence and Collaboration diagram:

Sequence Diagrams Collaboration Diagrams

The sequence diagram represents the UML,
which is used to visualize the sequence of
calls in a system that is used to perform a
specific functionality.

The collaboration diagram also comes under
the UML representation which is used to
visualize the organization of the objects and
their interaction.

The sequence diagrams are used to represent
the sequence of messages that are flowing
from one object to another.
The collaboration diagrams are used to
represent the structural organization of the
system and the messages that are sent and
received.
The sequence diagram is used when time
sequence is main focus.
The collaboration diagram is used when object
organization is main focus.

The sequence diagrams are better suited of
analysis activities.
The collaboration diagrams are better suited
for depicting simpler interactions of the
smaller number of objects.

UML Package Diagram

A package is a grouping of model elements which means that a package can contain model
elements of different kinds, including other packages to create hierarchies. A package defines
a namespace for its contents using for various purposes.
Package diagram is used to simplify complex class diagrams, you can group classes into
packages. A package is a collection of logically related UML elements.
The diagram below is a business model in which the classes are grouped into packages:
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.

35. • One package depends on another if changes in the other could possibly force
changes in the first.



Basic Concepts of Package Diagram

Package diagram follows hierarchal structure of nested packages. Atomic module for nested
package are usually class diagrams. There are few constraints while using package diagrams,
they are as follows.
• Package name should not be the same for a system, however classes inside
different packages could have the same name.
• Packages can include whole diagrams, name of components alone or no
components at all.
• Fully qualified name of a package has the following syntax.

36. Packages can be represented by the notations with some examples shown below:

Package Diagram — Dependency Notation
There are two sub-types involved in dependency. They are <<import>> & <<access>>. Though
there are two stereotypes users can use their own stereotype to represent the type of
dependency between two packages.

37. Key Elements of Package Diagram
Packages are used to organize a large set of model elements:
• Visibility
• Import
• Access



When to Use Packages?
To create an overview of a large set of model elements
• To organize a large model
• To group related elements
• To separate namespaces
Visibility of Packages
Each contained element has a visibility relative to the containing package.
• A public element is visible to elements outside the package, denoted by ‘+’
• A protected element is visible only to elements within inheriting packages,
denoted by ‘#’
• A private element is not visible at all to elements outside the package, denoted
by ‘-’
• Same syntax for visibility of attributes and operations in classes

38. Import Relationship between Packages
The associations are owned by package X:


Import and Access

39. Inheritance
A package with a generalization to another package inherits public and protected elements
that are owned or imported by the inherited package. Packages are shown in static diagrams
two equivalent ways to show containment:


Subsystems
Subsystems are used for system decomposition that can be represented by the parts of a
system: (Specification / Realization)


Subsystem Internal and External Aspects
A subsystem has a specification and a realization to represent the two views:
• An external view, showing the services provided by the subsystem
• An internal view, showing the realization of the subsystem
• There is a mapping between the two aspects

40. Modeling Tips of Subsystem

• Define a subsystem for each separate part of a large system
• Choose specification technique depending on factors like kind of system and
kind of subsystem
• Realize each subsystem independently, using the specification as a
requirements specification
Modeling Complex Grouping
A package diagram is often used to describe the hierarchical relationships (groupings)
between packages and other packages or objects. A package represents a namespace.
Package Diagram Example — Layering Structure

42. Deployment diagram
This diagram depicts the static view of the run-time configuration of hardware nodes and the
software components that run on those nodes. It shows the hardware of the system, the
software that is installed on that hardware and the middleware that is used to connect the
dissimilar machines to one another. These nodes are physical entities where the components
are deployed. This diagram is used to visualize the deployment view of a system. This is a
structure diagram. This diagram helps in the management of the system.
Deployment diagrams are used to visualize the topology of the physical components of a
system, where the software components are deployed.
Deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships.
Purpose of Deployment Diagrams

The term Deployment itself describes the purpose of the diagram. Deployment diagrams are
used for describing the hardware components, where software components are deployed.
Component diagrams and deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams
shows how they are deployed in hardware.
UML is mainly designed to focus on the software artifacts of a system. However, these two
diagrams are special diagrams used to focus on software and hardware components.
Most of the UML diagrams are used to handle logical components but deployment diagrams
are made to focus on the hardware topology of a system. Deployment diagrams are used by
the system engineers.
The purpose of deployment diagrams can be described as −
• Visualize the hardware topology of a system.
• Describe the hardware components used to deploy software components.
• Describe the runtime processing nodes.
How to Draw a Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to the
component diagram because the components are deployed using the deployment diagrams.
A deployment diagram consists of nodes. Nodes are nothing but physical hardware used to
deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is
very important as it controls the following parameters −
• Performance
• Scalability
• Maintainability

43. • Portability
Before drawing a deployment diagram, the following artifacts should be identified −
• Nodes
• Relationships among nodes

Following is a sample deployment diagram to provide an idea of the deployment view of order
management system. Here, we have shown nodes as −
• Monitor
• Modem
• Caching server
• Server
The application is assumed to be a web-based application, which is deployed in a clustered
environment using server 1, server 2, and server 3. The user connects to the application
using the Internet. The control flows from the caching server to the clustered environment.
The following deployment diagram has been drawn considering all the points mentioned
above.

Symbol and notation of Deployment diagram
The deployment diagram consists of the following notations:

1. A component
2. An artifact
3. An interface
4. A node

44. One of the essential elements of the deployment diagram is the nodes and artifacts. So it is
necessary to identify all of the nodes and the relationship between them. It becomes easier
to develop a deployment diagram if all of the nodes, artifacts, and their relationship is
already known.

Example of a Deployment diagram

A deployment diagram for the Apple iTunes application is given below.

The iTunes setup can be downloaded from the iTunes website, and also it can be installed on
the home computer. Once the installation and the registration are done, iTunes application
can easily interconnect with the Apple iTunes store. Users can purchase and download music,
video, TV serials, etc. and cache it in the media library.

Devices like Apple iPod Touch and Apple iPhone can update its own media library from the
computer with iTunes with the help of USB or simply by downloading media directly from the
Apple iTunes store using wireless protocols, for example; Wi-Fi, 3G, or EDGE.

45. Where to Use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to
describe the physical components (hardware), their distribution, and association.
Deployment diagrams can be visualized as the hardware components/nodes on which the
software components reside.
Software applications are developed to model complex business processes. Efficient
software applications are not sufficient to meet the business requirements. Business
requirements can be described as the need to support the increasing number of users, quick
response time, etc.
To meet these types of requirements, hardware components should be designed efficiently
and in a cost-effective way.
Now-a-days software applications are very complex in nature. Software applications can be
standalone, web-based, distributed, mainframe-based and many more. Hence, it is very
important to design the hardware components efficiently.
Deployment diagrams can be used −
• To model the hardware topology of a system.
• To model the embedded system.
• To model the hardware details for a client/server system.
• To model the hardware details of a distributed application.
• For Forward and Reverse engineering.

46. ACTIVITY DIAGRAM

There are certain parts in the system which is very complex. The activity
diagrams describe the flow of control from activity to activity. This helps simplify
the part involving complexity.

NEED FOR ACTIVITY DIAGRAM

The activity diagram is a diagram that models business processes. It also
emphasizes the flow of control from activity to activity. It is very much similar to
the traditional program flowchart. It is typically used to provide details for
complex algorithms. This diagram is typically used for business process modeling,
for modeling the logic captured by a single use case or usage scenario.


CREATING ACTIVITY DIAGRAM

While creating an activity diagram that following steps could be taken.
• Set the context or scope of the activity being modeled.
• Give the diagram an appropriate title.
• Identify the activities, control flows and object flows that occur between
the activities.
• Identify any decisions that are part of the process being modeled.
• Identify any prospects for parallelism in the process.
• Draw the activity diagram.

47. Create new
patient
Search Scan customer
card
ELEMENTS OF THE ACTIVITY DIAGRAMS
Start symbol
This indicates the starting point of the diagrams. This is optional. If it is used it makes it
significantly easier to read the diagram. This is denoted by a filled in circle.

End symbol
This indicates the final node after which there will not be any more activities.This is denoted
by a filled in circle with a boundary.


Activity
This is a behavior an object carries out while in a particular state. A rounded rectangle
specifies an activity. The name of the activity is to be written inside the rounded rectangle.


Forks and joins
These are used when we wish to denote the parallel or concurrent paths of activities.
When the concurrent or parallel paths begin at the top we denote a thick line called the
synchronization bar (fork) and have different parallel paths coming from it shown by
transitions. Once all the concurrent or parallel activities are over they all should come
together to continue with the further processing. Here we have multiple transitions coming
together in a thick line called the synchronization bar (join).

49. Is N
integer?
Decision point/branch
When we find a situation with different possibilities then we need to decide
which path is to be taken. To indicate the choice decision points are used. This is
denoted by a diamond symbol containing a condition whose results provide
transition to different paths. Typically the condition to be checked is written
inside the diamond. There is more than one possible path to choose from. During
execution one of the possible paths will be selected. There one transition
entering and several transitions leaving the diamond. The outgoing flows include
conditions on the basis of which that particular transition is selected.


Merges
This indicates that one or more incoming flows must reach this point until
processing continues, based on any guards on the outgoing flow. This is
denoted by a diamond with several flows entering and one leaving.

Guard/condition
This is given by text written in between ‘[‘ and ‘]’. This is placed on a flow.
The guard must evaluate to TRUE in order to traverse the node.

50. Swimlane/partition
The swimlanes or partitions indicate who or what is performing the activities.
Every participant gets a swimlane in which that participant’s activities are
shown. The interactions are shown by transitions across swimlanes.

51. The classes have operations which take in parameter and generate results. These
operations may modify one or more of the attributes of the class. Thus the state of the
object changes. Activities also may modify objects or they may transform one object to
another.
This is shown by a rectangle inside which the name of the object is written. Below the
name inside square brackets the state of the object is mentioned.




Transition/control flow
This indicates the movement from one activity to another. The arrowhead
indicates the destination activity. This is shown by a line with an
arrowhead.


The activity diagram is used to understand the flow of the business functions.
This helps in explaining the parts which are complex to understand. There are
a variety of elements used in these diagrams.

52. Example of an Activity Diagram

An example of an activity diagram showing the business flow activity of order
processing is given below.

Here the input parameter is the Requested order, and once the order is accepted, all
of the required information is then filled, payment is also accepted, and then the
order is shipped. It permits order shipment before an invoice is sent or payment is
completed.



When to use an Activity Diagram?

An activity diagram can be used to portray business processes and workflows. Also, it
used for modeling business as well as the software. An activity diagram is utilized for
the followings:

1. To graphically model the workflow in an easier and understandable way.
2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed
within the system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an application.
7. To represent a high-level view of a distributed or an object-oriented system.

53. One mark:
1. A class is divided into which of these compartments?
a) Name Compartment
b) Attribute Compartment
c) Operation Compartment
d) All of the mentioned

Answer: d

2. Diagrams in unified modified language which are used to test class diagrams for accuracy
purpose are called
a) deployment diagrams
b) component diagrams
c) object diagrams
d) package diagrams

Answer: a

3. In Unified Modeling Language, diagrams which captures system static structure and
provide foundation for other models is called
a) deployment diagrams
b) class diagrams
c) component diagrams
d) object diagrams

Answer: b


4.In Unified Modeling Language, diagrams that organize system elements into groups are
classified as
a) package diagrams
b) organized diagram
c) system diagrams
d) class diagrams

Answer: a

54. 5.In component diagrams, building block which is represented with two rectangles laid on
left side is classified as
a) type of components
b) interfaces
c) dependency relationships

Answer: c

6.Which among the following are not the valid notations for package and component diagram?
a) Notes
b) Box
c) Extension Mechanisms
d) Packages

Answer: b

7.What is collection of model elements called?
a) Box
b) Dependency
c) UML packages
d) Package members

Answer: d

8. What types of units does Component follow?
a) Modular Unit
b) Replaceable Unit
c) Unit with well defined interface
d) All of the mentioned

Answer: d

55. 9. Components can be represented by which of the following?
a) Component symbols
b) Stereotypes
c) Rectangular boxes
d) a, b
e) a, c

Answer: d

10. Which of these is true with respect to interfaces?
a) Interfaces in component diagram defines relationship between components and environment
b) Interfaces realized by a class or a component are required interfaces
c) Interface on which a class or component depends are called provided interfaces
d) All of the mentioned

Answer: a

11. Which among these are the common notations for deployment diagrams?
a) Artifacts and nodes
b) Stereotypes
c) Components
d) All of the mentioned

Answer: a

12. What does a deployment diagram consists of?
a) Computational resource
b) Communication path between resource
c) Artifacts that execute resource
d) All of the mentioned

Answer: d

56. 13. Which of the following is incorrect in deployment diagram?
a) Communication connections between nodes are shown by communication paths
b) Communication paths are represented by dotted lines
c) Artifacts are deployed inside nodes where they reside and execute
d) None of the mentioned

Answer: b

14. Which of these is correct?
a) Artifacts instances and types have same names
b) Artifact names and instances are underlines
c) All of the mentioned
d) None of the mentioned

Answer: a

15. What is true about the artifacts?
a) An Artifact is a physical entity
b) An artifact has spatio temporal location
c) All of the mentioned
d) None of the mentioned

Answer: c

16. What is Interaction diagram?
a) Interaction diagrams are the UML notations for dynamic modeling of collaborations
b) Interaction diagrams are a central focus of engineering design
c) All of the mentioned
d) None of the mentioned


Answer: c

57. 17. What are the different interaction diagram notations does UML have?
a) A sequence diagram
b) A communication diagram
c) An interaction overview diagram
d) All of the mentioned

Answer: d

18. What is a sequence diagram?
a) A diagram that shows interacting individuals along the top of the diagram and
messages passed among them arranged in temporal order down the page
b) A diagram that shows messages super imposed on a diagram depicting collaborating
individuals and the links among them
c) A diagram that shows the change of an individual’s state over time
d) All of the mentioned

Answer: a
19. What is a lifeline?
a) It is a frame consisting of a rectangle with a pentagon inits upper left-hand corner
b) It is a rectangle containing an identifier with a dashed line extending below the rectangle
c) It is a name compartment ; the interaction is represented inside the rectangle
d) None of the mentioned
Answer: b
20. Which core element of UML is being shown in the figure?

a) Node
b) Interface
c) Class
d) Component

Answer: d

58. 21. What type of relationship is represented by Shape class and Square?




a) Realization
b) Generalization
c) Aggregation
d) Dependency

Answer: b

22. Which diagram in UML shows a complete or partial view of the structure of a modeled
system at a specific time?

a) Sequence Diagram

b) Collaboration Diagram

c) Class Diagram

d) Object Diagram

Answer: d

23. Interaction Diagram is a combined term for

a) Sequence Diagram + Collaboration Diagram

b) Activity Diagram + State Chart Diagram

c) Deployment Diagram + Collaboration Diagram

d) None of the mentioned

Answer: a

59. 24. Which of the following diagram is time oriented?

a) Collaboration
b) Sequence
c) Activity
d) None of the mentioned
Answer: b

25. Which UML diagram’s symbols are shown below?

a) Deployment diagram
b) Collaboration Diagram
c) Component Diagram
d) Object Diagram

Answer: a

26. Which consider diagrams as a type of Class diagram, component diagram, object diagram,
and deployment diagram?
A) structural
B) behavioral
C) non-behavioral
D) non structural
Answer:a
27.__________ represented by In UML diagrams, relationship between component parts and
object.
A) ordination
B) aggregation
C) segregation
D) increment

Answer:b

28.Which type they considered Activity diagram, use case diagram, collaboration diagram,
and sequence diagram?
A) non-behavioral
B) non-structural

60. C) structural
D) behavioral

Answer d
29. Which diagram is used to show interactions between messages are classified as?
A) activity
B) state chart
C) collaboration
D) object lifeline

Answer c

30.Which diagrams are used to distribute files, libraries, and tables across topology of the
hardware?
A) deployment
B) use case
C) sequence
D) collaboration

Answer: a

31.Which diagram that helps to show Dynamic aspects related to a system?
A) sequence
B) interaction
C) deployment
D) use case

Answer: b

32.These are the heuristics _________.
A) Name classes attributes with noun phrases
B) Name operations with verb phrases
C) Stick to binary associations
D) All of the mentioned

Answer: d

33.__________UML diagrams has a static view.
A) Collaboration
B) Use case
C) State chart
D) Activity
Answer: b

61. 34. Select from the following in which engineering and reverse engineering can be applicable
(A) tagged values
(B) stereotypes
(C) class diagram
(D) adornments
Answer (C)

35.UML diagram that shows the interaction between users and system, is known as
A. Activity diagram
B. E-R diagram
C. Use case diagram
D. Class diagram

Answer:C

36. UML diagram that specifies sequences/ steps of operations to be performed
A. Activity diagram
B. Use case diagram
C. Class diagram
D. E-R case diagram
Answer:B

37. A UML diagram that facilitates requirements gathering and interacts between system and
external users, is called as
A. Flowchart diagram
B. Sequence diagram
C. Use case diagram
D. Data flow diagram

Answer: C

38.The behavior of a system can be modeled with the help of which kind of UML diagrams?
a. class diagram
b. activity diagram
c. use case diagram
d. interaction diagram

Answers: b

39.To hide the internal implementation of an object, use _____________
a) inheritance
b) encapsulation
c) polymorphism
d) none of these

62. Answers: b
40.Aggregation is …
a) set of relationship
b) composed of relationship
c) part of relationship
d) all of these

Answer - b
41. Cohesion and coupling are represented by using …
a) structure part
b) structure effect
c) dependence matrix
d) all of these
Answer - c
42. Refinement is a process of
a) inheritance
b) colaboration
c) elaboration
d) polymorphism
Answer - c

43. In a sequence diagram, the _____ indicates when an object sends or receives a message.

(A)command line
(B)focus
(C)request link
(D)lifeline
Answer - c

44.Which of the following is not an OOPS concept?
a) Encapsulation

63. b)Polymorphism
c)Exception
d)Abstraction
Answer: c.
45.Which feature of OOPS described the reusability of code?
a)Abstraction
b)Encapsulation
c)Polymorphism
d)Inheritance
Answer: d
46.Which feature of OOPS derives the class from another class?
a)Inheritance
b)Data hiding
c)Encapsulation
d)Polymorphism
Answer: a.


47.Which two features of object-oriented programming are the same?
a)Abstraction and Polymorphism features are the same
b)Inheritance and Encapsulation features are the same
c)Encapsulation and Polymorphism features are the same
d) Encapsulation and Abstraction
Answer: d
48.How can the concept of encapsulation be achieved in the program?
a)By using the Access specifiers
b)By using the concept of Abstraction
c)By using only private members
d)By using the concept of Inheritance

64. Answer: a.
49. Which of the following feature interacts one object with another object?
a)Message reading
b)Message passing
c)Data transfer
d)Data binding
Answer: b.
50.Which definition best defines the concept of abstraction?
a) Hides the important data
b) Hides the implementation and showing only the features
c) Hiding the implementation
d) Showing the important data
Answer: b.

Two Marks
1. What is UML?
Unified Modelling Language.
It is a Industry standard graphical language for modelling and hence visualizing a blue print of all the
aspects of the system, before implementing the system. It is an e asy way to specify, visuallize,
document and understand the structure and behaviour of the system.
2. Goals/Benefits of UML?
Ans. few Goals and Benifits of UML are:
1. Being independent of any particular programming language and development process
its easy to understand.
2. To provide best engineering practices for large and complex system.
3. Encourage the growth of Object Oriented tools.
4. Provides a good way to gather requirements.

65. 5. Improve software quality and decreases time and cost of the software.
3. Explain core elements of UML diagrams?
Ans. Core elements of Use Case UML diagrams are given below in table:

Elements
Name
Description Element Image
Use Case. Describes one of the Action of the system.

Actor An Actor is the one who uses the System.
Note: It may not always be a human being but can
be another system


Association. Links an Actor to the Use Case.

System
Boundary.
Represents the boundary between an Actor
(External entity) and the System.


Extend Links an Actor to the Use Case.

Generalization. Basically describes "Inheritance" Object
orientation terms. The arrow points to the
base / parent class.


Dependency. Explains dependency relation between two
components. Arrow points to the component
it depends on.


Class. Class - the building blocks of Object Oriented
language. A Rectangle divided into 3 parts
horizontally, top gives the class name, middle to
give the properties (main variables), the
bottom to give the method names

66. Object. Object is basically ONE instance of a class.
Objects are displayed as a rectangle divided in two
horizontal parts, with "instance name : class
name: on top and properies "Name = Value" in
bottom part.


Lifeline. Represents the life time of an object.

Activation. Represents when the object is performing
some action.


Message. Links the two objects and Describes the
communication taking place between them.


4.Define Use case.
A use case is a collection of related success and failure scenarios that describe an actor
using a system to support a goal. Use cases are text documents, not diagrams, and use-
case modeling is primarily an act of writing text, not drawing diagrams.
5.List the relationships used in use cases?
Include, Extend and Generalization
6.What is an object?

An object is a combination of data and logic; the representation of some real-world entity.

7.What is the main advantage of object-oriented development?
• High level of abstraction

67. • Seamless transition among different phases of software development

• Encouragement of good programming techniques.

• Promotion of reusability
8.Define Association.
An association is a relationship between classes (more precisely, instances of those
classes) that indicates some meaningful and interesting connection.
9.What is Aggregation?

Aggregation is a vague kind of association in the UML that loosely suggests whole-
part relationships (as do many ordinary associations). It has no meaningful distinct
semantics in the UML versus a plain association, but the term is defined in the UML.

10.What is meant by interaction diagram?

The term interaction diagram is a generalization of two more specialized UML diagram
types; both can be used to express similar message interactions:
. Collaboration diagrams
. Sequence diagrams
11.What is meant by Low Coupling?

Coupling is a measure of how strongly one element is connected to, has knowledge
of, or relies on other elements. An element with low (or weak) coupling is not
dependent on too many other elements; "too many" is context-dependent, but will
be examined. These elements include classes, subsystems, systems, and so on.

12.What is meant by High COHESION?
Cohesion (or more specifically, functional cohesion) is a measure of how strongly
related and focused the responsibilities of an element are. An element with highly
related responsibilities, and which does not do a tremendous amount of work, has high
cohesion. These elements include classes, subsystems, and so on.

13.List down the basic concepts of OOP.
1. Objects
2. Classes
3. Data abstraction and encapsulation

68. 4. Inheritance
5. Polymorphism
6. Dynamic binding
7. Message passing

14. Define a class.
A class is a collection of objects with similar attributes and operations.
Eg. Class – Account
It will create an object savings_account belonging to the class Account.
15. Define Encapsulation.
The wrapping up of data and functions into a single unit is known as encapsulation. The data is
kept safe from external interference and misuse.

16. Define Data hiding?
The isolation of data from direct access by the program is called as data hiding or information
hiding.

17. Define Abstraction.
It refers to the act of representing essential features without including the background details.

18.Define Inheritance?
Inheritance is the process by which objects of one class acquire the properties of objects of
another class. The new derived class inherits the members of the base class and also adds its
own.

19. Define Polymorphism?
It allows a single name/operator to be associated with different operations depending on the
type of data passed to it. An operation may exhibit different behaviors in different instances.

20. What is message passing?
It is the process of invoking an operation on an object. In response to a message, the
corresponding function is executed in the object.


21.What is the critical ability of an objectorientedsystem?
A critical ability of Object Oriented development is to skillfully assign responsibilities to
software
objects. It is one activity that must be performed either while drawing a UML diagram or
programming and it strongly influences the robustness, maintainability, and reusability of
software
components.

22. What is meant by object oriented system development methodology?

69. Object oriented system development methodology is a way to develop software by building
selfcontained modules or objects that can be easily replaced, modified and reused

23.What is an UML activity diagram?
A UML activity diagram shows sequential and parallel activities in a process. They are useful for
modeling business processes, workflows, data flows, and complex algorithms

24.What are UML state machine diagrams?
A UML state chart diagram illustrates the interesting events and states of an object, and the
behavior of
an object in reaction to an event. Transitions are shown as arrows, labeled with their event.
States are
shown in rounded rectangles.

25.Define − Event, State andTransition
An event is defined as a significant or noteworthy occurrence. It is a label associated with a
transition
that identifies the message which causes a state change. Example: A telephone receiver is taken
off the
hook.
A state is defined as the condition of an object at a moment in time, the time between events.
Example: A telephone is in the state of being "idle" after the receiver is placed on the hook and
until
it is taken off the hook.
A transition is defined as a relationship between two states that indicates that when an event
occurs,
the object moves from the prior state to the subsequent state. Example: When the event "off
hook"
occurs, transition the telephone from the "idle" to "active" state.


26.What are deployment diagrams?
A deployment diagram shows the assignment of concrete software artifacts (such as executable
files) to
computational nodes (something with processing services). It shows the deployment of
software elements to the physical architecture and the communication (usually on a network)
between physical elements.

27.What is component diagram?
The component diagram helps to model the physical aspect of an Object-Oriented software
system. It
illustrates the architectures of the software components and the dependencies between them.

28. Define−Component

70. A component is defined as a modular part of a system that encapsulates its contents and
whose manifestation is replaceable within its environment. A component defines its behavior in
terms of provided and required interface