Assignment 2&3

OBJECT ORIENTED ANALYSIS AND DESIGN WITH UML
NAME: THAKKAR MAITRI PIYUSHKUMAR

ENROLMENT NO: 23084341015
SUBJECT : OBJECT ORIENTED ANALYSIS AND DESIGN WITH UML
SUBMITTED TO: DR. JIGNESHKUMAR A. CHAUHAN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
UNIT 2 & 3
1) Discuss OOAD for Web Engineering.
Ans:
1.Object-Oriented Approach: OOAD promotes the use of objects and classes
to model real-world entities. In web engineering, this translates to using
objects to represent various components of a web application, such as users,
products, or orders.
2. Abstraction: Abstraction involves simplifying complex systems by focusing
on relevant details. In web engineering, this means identifying the essential
features and functionalities of a web application and modeling them as
abstract classes or interfaces.
3. Inheritance: Inheritance allows you to create new classes based on existing
ones. In web development, you can use inheritance to build upon existing
components or frameworks.
4. Encapsulation: Encapsulation involves bundling data and methods that
operate on that data within a single unit (class). In web engineering,
encapsulation helps in creating modular and maintainable code.
5. Polymorphism: Polymorphism allows different classes to be treated as
instances of a common superclass. In web applications, this can be seen when
handling various HTTP requests.
6. Use of Design Patterns: OOAD often involves applying design patterns like
MVC (Model-View-Controller) or MVVM (Model-View-ViewModel) to organize
code and separate concerns.
7. UML Diagrams: Unified Modeling Language (UML) diagrams, such as class
diagrams, sequence diagrams, and use case diagrams, are valuable tools in
OOAD for visualizing and documenting the design of web applications.
8. Iterative Development: OOAD encourages an iterative and incremental
approach to development. In web engineering, this means continuously
refining and expanding the design as requirements evolve.
9. Testing and Validation: OOAD emphasizes early testing and validation of
design concepts.
25
2)Explain web engineering team.

Ans:
 A successful Web engineering team melds wide variety of talents who
must work as a team in high-pressure project environment.
 The following roles should be distributed among the members of the
Web Engineering Team:
 Content Developer/Providers
 Web Publisher
 Web Engineer.
 Business domain experts
 Support Specialist
 Administrator (“Web Master”)
1. Content Developer/Providers:
 one Web Engineering team member role must focus on the generation
or collection of content.
 content spans a broad array of data objects, content developers and
providers may come from diverse (non-software) backgrounds.
 For example,
 marketing or sales staff may provide product information and graphical
images.
 media producers may provide video and audio.
 graphic designers may provide layout design and aesthetic content.
 copywriters may provide text-based content.
2. Web Publisher:
 The diverse content generated by content developers and providers
must be organized for inclusion within the WebApp.
 This role is filled by the Web publisher, who must understand both
content and WebApp technology including HTML database functionality,
scripts, and general Web-site navigation.
3. Web Engineer:
 A Web engineer becomes involved in a wide range of activities during
the development of a WebApp including requirements elicitation;
analysis modeling; architectural, navigational, and interface design;
WebApp implementation; and testing.
26
 The Web engineer should also have a solid understanding of component

technologies, client/server architectures, HTML/XML, and database
technologies as well as a working knowledge of multi-media concepts,
hardware/software platforms, network security, and Web-site support
issues.
4. Support Specialist:
 This role is assigned to the person (people) who has responsibility for
continuing WebApp support.
5. Administrator (“Web Master”):
 This person has responsibility for the day-to-day operation of the
WebApp, including.
 Development and implementation of policies for the operation of the
WebApp.
 Establishment of support and feedback procedures.
 Implementation of security procedures and access rights.
 Measurement and analysis of Web-site traffic.
3)Write a short note on requirements analysis for Web Apps.

Ans:
 Requirement analysis for WebApps encompasses three major tasks:
i. Formulation:
The basic motivation(goals) and objectives for the WebApp are identified, and
the categories of users are defined.
ii. Requirement Gathering:
Communication between the Web engineering team and WebApp
stakeholders(e.g., Customers, end-users) intensifies.
iii. Analysis Modeling:
Content and functional requirements are listed and interaction scenarios (use-
case) written from the end-user’s point-of-view are developed. The intent is to
establish a basic understanding of why the WebApp is to be built, who will use
it, and what problem(s) it will solve for its users.
27
4)Discuss analysis model for Web Apps.

Ans:
 Analysis modeling helps you to understand the detailed requirements
that will allow you to satisfy user needs.
 Four Analysis activities- each contributing to the creation of a complete
analysis models are:
o Content Analysis.
o Interaction Analysis.
o Functional Analysis.
o Configuration Analysis.
(1) Content Analysis.
 The full spectrum of content to be provided by the webApp. Content
includes text, graphics and images, and video and audio data.
(2) Interaction Analysis.
 The manner in which the user interacts with the WebApp is described in
detail.
(3) Functional Analysis.
 Defines the operations that will be applied to WebApp content and
describes other processing functions that are independent of content
but necessary to the end user.
(4) Configuration Analysis.
 The environment and infrastructure in which the WebApp resides are
described in detail.
5)Write a short note on:

I. Content Model:
Ans:
 The content model contains structural elements that provide an
important view of content requirements for a WebApp.
28
 These structural elements encompass content objects(e.g.. Text,

graphical images, photographs, video images, audio) that are presented
as part of the WebApp.
 In addition, the content model includes all analysis classes – user visible
entities that are created or manipulated as a user interacts with the
WebApp.
 An analysis class encompasses attributes that describe it, operations that
effect behavior required of the class, and collaborations that allow the
class to communicate with other classes.
 Content model is derived from a careful examination of use-cases
developed for the WebApp
 Content objects are extracted from use-cases
 examine the scenario description for direct and indirect references to
content
 Attributes of each content object are identified
 The relationships among content objects and/or the hierarchy of
content maintained by a WebApp
Relationships—entity-relationship diagram or UML
Hierarchy—data tree or UML
II. Interaction Model:

 An interaction model is a design model that binds application
together in a way that supports the conceptual models of its target
users
 Composed of four elements:
 Use-cases
 Sequence diagrams
 State diagrams
 User interface prototype
 Each of these is an important UML notation
(1) Sequence diagram:

 The sequence diagram represents the flow of messages in the system
and is also termed as an event diagram.
 Notations of a Sequence Diagram:
i. Lifeline: An individual participant in the sequence
diagram is represented by a lifeline. It is positioned at
the top of the diagram.
29
ii. Actor: It represents the role, which involves human

users and external hardware or subjects. An actor may
or may not represent a physical entity, but it purely
depicts the role of an entity. Several distinct roles can
be played by an actor or vice versa.
iii. Activation: It is represented by a thin rectangle on
the lifeline. It describes that time period in which an
operation is performed by an element, such that the
top and the bottom of the rectangle is associated with
the initiation and the completion time, each
respectively.
iv. Messages: The messages depict the interaction
between the objects and are represented by arrows.
(2) State Diagram:

 A state diagram, also known as a state machine diagram or statechart
diagram, is a visual representation used in computer science, software
engineering, and various other fields to depict the different states an
object, system, or entity can go through in its lifecycle or operation.
Key components of a state diagram include:
1.States: States represent distinct conditions or modes that an object or
system can be in at a given point in time.
2.Transitions: Transitions are arrows or lines that connect states and
indicate the conditions or events that trigger a change from one state to
another.
3.Actions: Actions are tasks or operations that are performed when a
transition occurs.
4.Initial State: The initial state represents the starting point of the
system or object's lifecycle.
5.Final State: The final state represents the end or termination point of a
particular sequence of states and transitions.
III. Functional Model:
 The functional model addresses two processing elements of
the WebApp
i. user observable functionality that is delivered by the
WebApp to end-users
ii. the operations contained within analysis classes that
implement behaviors associated with the class.
IV. Configuration Model:
30
 Server-side
 Server hardware and operating system environment must
be specified
 Interoperability considerations on the server-side must be
considered
 Appropriate interfaces, communication protocols and
related collaborative information must be specified
 Client-side
 Browser configuration issues must be identified
 Testing requirements should be defined
6)Write a short note on UML detail.

Ans:
 UML - Unified Modeling language
 UML is a modeling language, not a methodology or process
 Developed by Grady Booch, James Rumbaugh and Ivar Jacobson at
Rational Software.
 Accepted as a standard by the Object Management Group (OMG), in
1997.
1. Diagrams:
Class Diagrams: Represent the static structure of a system by showing
classes, their attributes, methods, and relationships.
Use Case Diagrams: Depict the interactions between the system and
external entities, showcasing various use cases and their relationships.
Sequence Diagrams: Illustrate the interactions between objects over
time, displaying the order in which messages are exchanged.
Activity Diagrams: Focus on the workflow and activities within a system,
providing a dynamic view of processes.
2. Elements:
Class: Represents a blueprint for objects, defining attributes and
methods.
Object: An instance of a class in a system.
Use Case: Describes a specific functionality or task that the system must
perform.
Actor: Represents an external entity that interacts with the system.
31
Association: Describes a relationship between classes or objects.

Sequence: Represents the order in which messages are exchanged
between objects.
3. Relationships:
Association: Describes the connections between classes or objects.
Inheritance (Generalization): Represents the "is-a" relationship between
classes, where one class inherits attributes and behaviors from another.
Dependency: Indicates that one class relies on another class.
Aggregation: Denotes a "whole-part" relationship, where one class is
composed of other classes.
Composition: Similar to aggregation but with stronger ownership,
indicating that the composed class is a part of the whole and cannot
exist independently.
4. Annotations:
Notes: Used to provide additional information or clarification on
elements and relationships.
Constraints: Specify conditions or restrictions on elements.
7)Which are the Building Blocks of UML? Explain any one of them.
Ans:
 UML is composed of three main building blocks, i.e., things,
relationships, and diagrams. Building blocks generate one complete UML
model diagram by rotating around several different blocks.
 The basic UML building blocks are enlisted below:
(1) Things:
A. Structural
B. Behaviour
C. Grouping
D. Annotational
(2) Relationship:
A. Dependency
B. Association
C. Generalisation
D. Realization
32
(3) Diagrams:
A. Class Diagram
B. Object Diagram
C. Use Cases Diagram
D. Behaviour Diagram
E. Sequence Diagram
F. Statechart Diagram
 Diagrams:
 The diagrams are the graphical implementation of the
models that incorporate symbols and text. Each symbol
has a different meaning in the context of the UML
diagram.
(1) Class diagram:
o The most common diagram found in OOAD, shows
a set of classes, interfaces, collaborations and their
relationships. Models the static view of the system.
(2) Object diagram:
o shows the set of objects and their relationships.
(3) Use case diagram:
o shows a set of “Use Cases”, the “actors” and their
relationships. Models WHAT the system is expected
to do.
(4) Sequence diagram:
o models the flow of control by time-ordering;
depicts the interaction between various objects by
of messages passed, with a temporal dimension to
it.
8)Write a short note on conceptual model of UML.

Ans:
33
 A conceptual model is composed of several interrelated concepts. It

makes it easy to understand the objects and how they interact with each
other. This is the first step before drawing UML diagrams.
 Following are some object-oriented concepts that are needed to begin
with UML:
o Object: An object is a real world entity. There are many objects present
within a single system. It is a fundamental building block of UML.
o Class: A class is a software blueprint for objects, which means that it
defines the variables and methods common to all the objects of a
particular type.
o Abstraction: Abstraction is the process of portraying the essential
characteristics of an object to the users while hiding the irrelevant
information. Basically, it is used to envision the functioning of an object.
o Inheritance: Inheritance is the process of deriving a new class from the
existing ones.
o Polymorphism: It is a mechanism of representing objects having
multiple forms used for different purposes.
o Encapsulation: It binds the data and the object together as a single unit,
enabling tight coupling between them.
9)List out common mechanisms in UML and explain any two with
example.
Ans:
 Four common mechanism that apply consistently through out the
language.
o Specifications
o Adornments
o Common divisions
o Extensibility mechanisms
i. Adornments:
 Most elements in the UML have a unique and direct graphical
notation that provides a visual representation of the most
important aspects of the element.
34
 Example: The class notation exposes the most important

aspects of a class, namely its name, attributes and operations.
It can include other details like, visibility of its attributes and
operations:
o + Public
o # Protected
o – Private
Transaction
+execute()
+rollback()
#priority()
-timestamp()
ii. Specification:
 UML is more than graphical language. Behind every part of its
graphical notation there is a specification that provides a
textual statement of the syntax and semantics of the building
block.
 Example:
Behind a class icon is a specification that provides the full set
of attributes, operations and behaviors that class renders.
10)Discuss the software Development Life Cycle in depth.

Ans:
 The software development lifecycle is the cost effective and time
efficient process that development teams use to design and build high
quality software.
 There are 4 phases in the software development life cycle:
o Inception
o elaboration
o construction
o Transition
i. Inception:
35
 Inception is the first phase of the process, when the seed idea for
the development is brought up to the point of being entered into
the elaboration phase.
ii. Elaboration:
 It is the second phase of the process, when the product vision and
its architecture are defined.
 In this phase, the system’s requirements are defined and arranged
by certain criteria.
iii. Construction:
 It is the third phase of the process, when the software is actually
constructed and being ready for transitioning to user community.
 Here also the system’s requirements and evaluation criteria are
constantly reexamined against business needs.
iv. Transition:
 It is the fourth phase of the process, when the software is turned
into the hands of user community.
 Even during this period, the system is continuously improved, bugs
are rectified and features that were not there in earlier release are
added.
10)List out different views of modelling a Software system’s

Architecture.
Ans:
 Software architecture provides a basic design of a complete software
system. It defines the elements included in the system, the functions
each element has, and how each element relates to one another.
o Use case view
o Design view
o Implementation view
o Process view
o Deployment
Implementation
Design view
view
36
Use case view
Process view Deployment view

i. Use case view:
 The use case view of a system encompasses the use cases that describe
the behavior of the system. the static aspect of this view is captured in
use case diagram and dynamic view is captured in interaction, statechart
and activity diagram.
ii. Design view:
 The design view of a system encompasses the classes, interfaces, and
collaborations. It supports the functional requirements of the system.
iii. Implementation view:
 The implementation view of a system encompasses the components and
files that are used to assemble and release the physical system.
iv. Process view:
 The process view of a system encompasses the threads and processes
that form the system’s concurrency and synchronization mechanism.
v. Deployment view:
 Deployment view of a system encompasses the nodes that form the
system’s hardware topology on which the system executes. It addresses
the distribution, delivery and installation of the parts that make up the
physical system.
12)Write a short note on Relationship in depth.

Ans:
 It shows the association between the entities and defines the
functionality of an application. There are four types of relationships
given below:
I. Dependency
II. Association
III. Generalization
IV. Realization
37
(I)Dependency:
 Dependency is a kind of relationship in which a
change in target element affects the source element,
or simply we can say the source element is
dependent on the target element.
 It is denoted by a dotted line followed by an arrow at
one side as shown below,
(II) Association:
 A set of links that associates the entities to the UML
model. It tells how many elements are actually taking
part in forming that relationship.
 It is denoted by a dotted line with arrowheads on
both sides to describe the relationship with the
element on both sides.
(III) Generalization:
 It portrays the relationship between a general thing
(a parent class or superclass) and a specific kind of
that thing (a child class or subclass). It is used to
describe the concept of inheritance.
(IV) Realization:
 It is a semantic kind of relationship between two
things, where one defines the behavior to be
carried out, and the other one implements the
mentioned behavior. It exists in interfaces.
 It is denoted by a dotted line with an empty
arrowhead at one side.
38
(13) Explain Association Relationship with their adornments.

Ans:
 Association relationship is a structural relationship in which different

objects are linked within the system. It exhibits a binary relationship
between the objects representing an activity. It depicts the relationship
between objects, such as a teacher, can be associated with multiple
teachers.
 It is represented by a line between the classes followed by an arrow that

navigates the direction, and when the arrow is on both sides, it is then
called a bidirectional association. We can specify the multiplicity of an
association by adding the adornments on the line that will denote the
association.
o One to One
o One to Many
o Many to One
o Many to Many
 Example:
 A single teacher has multiple students(One to Many).
 A single student can associate with many teachers(Many to One).
39
(14) Give Difference between “Is-a-kind-of” and “has-a”

Relationship.
Ans:
Is-a-kind-of Has-a
1. Also known as inheritance or 1. Also known as composition or
generalization. aggregation.
2. Describes a relationship where one class 2. Describes a relationship where one class
is a specialized version of another class. has another class as a component or part.
3. It signifies a hierarchy, where a subclass 3. It signifies a containment or association,

inherits properties and behaviors from a where an object of one class contains an
superclass. object of another class.
4.”Is-a-kind-of” represents a relationship of 4. “has-a” represents a relationship of
specialization and inheritance. composition or containment.
5. Example: if you have a class "Vehicle" 5. Example: if you have a class "Car" and
and another class "Car," you might say that another class "Engine," you might say that
"Car is a kind of Vehicle." In this case, "Car has an Engine." In this case, "Engine" is
"Vehicle" is the superclass, and "Car" is the a component of the "Car" class.
subclass inheriting characteristics from
"Vehicle."
(15) Write a short note on structural diagrams.

Ans:
 Structural diagrams in UML (Unified Modeling Language)
focus on illustrating the static structure of a system by
representing its components and their relationships.
These diagrams provide a visual representation of the
system's architecture and the organization of its elements.
Here are some key structural diagrams in UML:
1. Class Diagrams:
40
 They showcase classes, their attributes, methods, and

relationships. These diagrams are fundamental for
understanding the building blocks of an object-
oriented system.
2. Object Diagrams:
 These provide a snapshot of the system at a
particular moment, displaying instances of classes
and the relationships between them.
3. Component and Package Diagrams:
 Component diagrams emphasize the physical aspects
of the system, illustrating how various components
(e.g., modules, libraries) interact. Package diagrams,
on the other hand, organize related elements into
packages, offering a higher-level view of the system's
architecture. elements into packages, offering a
higher-level view of the system's architecture.
4. Composite Structure Diagram:
 Purpose: Represents the internal structure of a class
and how its parts collaborate to achieve the class's
behavior.
 Elements: Classes, parts, connectors, ports.
 Use Case: Useful for modeling the internal structure
of complex classes.
5. Deployment Diagram:
 Purpose: Represents the deployment of software
artifacts to nodes (hardware devices) and the
relationships between them.
 Elements: Nodes, components, artifacts, associations.
 Use Case: Useful for understanding how software
components are deployed on hardware.
(16) Write a short note on behavioral diagrams.

Ans:
41
 Behavioral diagrams in UML (Unified Modeling Language) focus on

capturing and visualizing the dynamic aspects of a system,
showcasing how various components interact, collaborate, and
behave over time. These diagrams help in understanding the flow
of control, the sequence of actions, and the responses to events
within a software system. Here's a brief overview of key behavioral
diagrams in UML:
 We can model a dynamic part of the system by using following
diagrams (behavioral diagrams).
 Use case diagram
 Sequence diagram
 Collaboration diagram
 State chart diagram
 Activity diagram
1. Use case diagram:
o Shows a set of “Use Cases” (sets of functionality
performed by the system), the “actors” (typically,
people/systems that interact with this system[problem-
domain]) and their relationships. Models WHAT the
system is expected to do.
2.Sequence diagram:
o models the flow of control by time-ordering; depicts the
interaction between various objects by of messages passed,
with a temporal dimension to it.
3.Collaboration diagram:
o models the interaction between objects, without the
temporal dimension; merely depicts the messages passed
between objects.
4.State chart diagram:
o shows the different state machines and the events that leads to
each of these state machines. State chart diagrams show the flow
of control from state to state.
5.Activity diagram:
42
o shows the flow from activity to activity; an “activity” is an ongoing

execution within a state machine.
(17) Explain class diagram with example.

Ans:
 A class diagram is a type of UML (Unified Modeling Language) diagram
used in software engineering and systems design to visualize the
structure and relationships of classes or objects within a system.
 Key components of a class diagram include: (1) Class
(2) Attributes
(3) Methods
(4) Relationships
i. Association
ii. Generalization
iii. Aggregation
iv. Composition
(1) Class:
 A class represents a blueprint or template for creating objects.
Classes are typically depicted as rectangles with three
compartments: one for the class name, one for attributes, and
one for methods.
(2) Attributes:
 Attributes represent the data or properties that objects of a class
possess. They are listed in the attribute compartment of the class
and are typically shown with a name and a data type.
(3) Method:
 Methods represent the behaviors or operations that objects of a
class can perform. They are listed in the method compartment of
the class and include the method name, parameters, and return
type.
(4) Relationships:
 Class diagrams depict the relationships between classes.
43
(18) Explain forward and reverse engineering.

Ans:
 Forward engineering and reverse engineering are two
complementary processes in software development, each serving
distinct purposes in the software life cycle.
(1) Forward Engineering:
 Forward engineering is the traditional process of creating
software from scratch, starting with requirements analysis
and design and proceeding to implementation, testing, and
deployment.
 Requirements Analysis:
Understanding and documenting the desired functionalities
and constraints of the software.
 Design:
44
Creating high-level and low-level design specifications, often

represented through diagrams like UML class diagrams or
flowcharts.
 Implementation:
Writing code based on the design specifications.
 Testing:
Verifying that the implemented software meets the specified
requirements.
 Deployment:
Introducing the software into the operational environment
for end-users.
 Use cases:
o New software development projects.
o Iterative development where new features are added.
 Advantages:
o Clear and controlled development process.
o Easier to plan and manage.
 Disadvantages:
Time-consuming, especially for large systems.
2. Reverse Engineering:
 Reverse engineering involves analyzing an existing
software system to extract information about its design,
structure, and functionality, often with the goal of
understanding or enhancing the system.
 Code Analysis:
Ex amining the source code to understand its structure,
relationships, and behavior.
 Data Flow Analysis:
Investigating how data moves through the system.
 Dependency Analysis:
Identifying dependencies between different components
or modules.
 Documentation Extraction:
45
Generating or updating documentation based on the

analysis.
 Use cases:
o Understanding legacy systems with undocumented
code.
o Migrating from one technology to another.
o Reversing engineered products for interoperability
or compatibility.
 Advantages:
o Gain insights into existing systems.
o Preserve and extend the life of legacy systems.
o Facilitates migration and integration efforts.
 Disadvantages:
o Challenges in dealing with poorly documented or
obfuscated code.
o Legal and ethical considerations, as reverse
engineering may violate licensing agreements.
(19) What is importing and Exporting in package? Explain

With figure.
Ans:
 If A’s package imports B’s package, A can see now B But B can not
see A. Importing grants a one way permission for the elements in
one package to access the elements in another package.
46
 The public parts of a package are called its exports.

 For ex. In previous figure the package GUI exports two classes,
window and Form. Event Handler is not exported by GUI. Event
Handler is protected part of the package.
 The parts that one package exports are visible only to the contents
of those packages that explicitly import the package. In the
example policies explicitly imports the package GUI.
 GUI::window and GUI::form are therefore made visible to
the contents of the package policies. But GUI::Event
handler is not visible because it is protected.
 Import and access dependencies are not transitive. Client
imports policies and policies import GUI. Client have
access the exports of Policies but do not have access to
the exports of GUI.
(20) Draw a class diagram of B2C shopping web site.

Ans:
47
1.Shopping cart class:

- Represents the shopping cart for a customer.
- Contains a list of items (Product, represented by the Item class)
and methods to add and remove items.
2.Customer class:
- Represents a customer with attributes such as customer ID,
name, email, and address.
- Has a method to place an order, creating an instance of the

Order class.
3.Product class:
48
- Represents a product available for purchase on the website.

- Includes attributes like product ID, name, price, and category.
- Category is represented as an enumeration.
4.Order class:
- Represents a seller id, customer id, product , address, delivery
status.
5.Shopping cart:
- Represents a cart item, check out, cart details.
 This is a basic representation, and in a real-world scenario, you
would likely have additional classes and relationships, such as User,
Payment, Shipping, and more, to capture the full complexity of a
B2C shopping website.
(21) Write a short note on Advance Classes.

Ans:
1) Abstract classes:
 Abstract classes are classes that cannot be instantiated and
are often used as base classes for other classes.
 Abstract classes provide a way to define common behavior
and properties shared by multiple subclasses while enforcing
a certain structure.
2) Interface classes:
 Interfaces define a contract of methods that implementing
classes must adhere to.
 Interfaces allow for multiple inheritance, as a class can
implement multiple interfaces.
3) Generic classes:
 Generics allow the creation of classes, methods, and
interfaces with parameters that represent data types. This
promotes code reusability and type safety.
 For example, in Java, you can create a generic class that
works with various types without sacrificing type safety.
4) Design pattern:
49
 These design pattern involve organizing classes into tree

structures or adding behaviour dynamically to objects.
5) Reflection and Metadata:
 Reflection allows classes to inspect and manipulate their
own structure at runtime.
 Metadata annotations can be used to add information or
behaviour to classes, methods, or properties.
Give short answer:
1. Which relationship known as “Is-a-kind-of” relationship.

Ans: Generalization
2. Which relationship known as “has-a” relationship.
Ans: Aggregation
3. In packages import and access dependencies are not transitive. [True/False]
Ans. True
4. Which sign used to indicate export component of a package.
Ans.
 In many programming languages, there isn't a specific "export" keyword
or sign used to indicate that a component of a package should be
exported. Instead, the default behaviour is often that all components
(classes, functions, etc.) within a package are accessible to other parts of
the program unless specified otherwise.
 However, in some languages, there are mechanisms to control the
visibility of components.
 For example, in languages like Java, you might use the `public` keyword
to indicate that a class or method should be accessible from outside the
package. In Python, you can use the `__all__` attribute to specify which
names should be exported when someone uses the `from module
import *` syntax. It's important to note that the specific syntax and
conventions can vary between programming languages. If you have a
particular language in mind, I can provide more specific information!
5. List the stereo types used in packages.
Ans.
50
 In UML, stereotypes are used to extend or redefine the semantics of

UML elements. While UML itself doesn't define stereotypes for
packages, you can create your own stereotypes based on your modeling
needs. Stereotypes are typically denoted by guillemets (« and ») in UML.
 For example, you might create stereotypes for packages like:
o «controller»
o «model»
o «view»
 These stereotypes can be used to convey additional information about
the role or purpose of the package in your system architecture. Keep in
mind that the specific stereotypes you use may depend on your
modeling conventions and the context of your system.
6.Define: Class, Interface, Active class, Component, Node, Package.

Ans:
i. Class:
o A class is a blueprint for creating objects in object-
oriented programming. It defines a set of attributes and
methods that characterize any object instantiated from
the class.
ii. Interface:
o An interface defines a contract for a class, specifying a set
of methods that the class must implement. It declares the
methods without providing the implementation details.
iii. Active class:
o An active class in UML represents a class that initiates
behavior independently. It is capable of initiating
processes or activities in a system.
iv. Component:
o In UML, a component represents a modular and
deployable part of a system. It encapsulates its content
and provides a well-defined interface, making it a
building block for larger systems.
v. Node:
o A node in UML represents a physical resource or
computational element in a system. It could be a
51
hardware device, like a server or a computer, or a

software environment where components can run.
vi. Package:
o A package in UML is used to organize and structure the
elements of a model. It provides a way to group related
elements and can contain classes, interfaces,
components, and other packages.
52
UNIT – 4
(1) What is an Interaction?

Ans:
 In the context of UML (Unified Modeling Language), an interaction
refers to a behaviour that involves a set of objects or roles playing
parts in a specific collaboration. It's used to model how a group of
objects collaborate to achieve a certain purpose or behaviour over
a period of time.
 Key components of an interaction in UML include:
1. Lifelines:
o Lifelines represent the individual participants or objects
involved in the interaction. They are typically depicted as
vertical lines.
2. Messages:
o Messages represent the communication or interaction
between lifelines. They can be simple messages or more
complex ones, such as synchronous calls or asynchronous
signals.
3. Fragments:
o Fragments are used to represent different scenarios or
conditions within an interaction, such as alternative or
parallel behaviour.
4. Interaction Occurrences:
o Interaction occurrences allow you to reuse and reference
interactions within other interactions, promoting
modularity and reusability.
(2) What is the use of interaction?

Ans:
 Interactions in the context of UML serve several purposes in the
modeling of software systems:
1. Dynamic Behaviour Modeling:
o Interactions help model the dynamic behaviour of a
system by illustrating how different objects collaborate
and communicate with each other over a period of time.
53
They provide a time-ordered sequence of events and

messages.
2. Sequence of Messages:
o They allow you to represent the sequence of messages
exchanged between objects during a specific scenario or
use case. This is particularly useful for understanding the
flow of control and data in a system.
3. Collaboration Visualization:
o Interactions provide a visual representation of the
collaboration between objects, helping stakeholders
understand how different components work together to
achieve a specific behaviour.
4. Identification of Scenarios:
o Interactions can be used to identify and model different
scenarios within a system, including alternative or parallel
behaviour. This is valuable for capturing variations in
system behaviour.
5. Communication Flow:
o They help to model the flow of communication between
objects, including synchronous calls, asynchronous
signals, and other types of interactions. This is crucial for
understanding the messaging patterns in a system.
6. Verification and Validation:
o Interactions can aid in the verification and validation of
system requirements. By visualizing the dynamic
behaviour, stakeholders can review and validate whether
the system behaves as intended.
(3) What is message?

Ans:
 A messages is a request to an object to invoke one of its methods.
A messages therefore contains the name of the method and the
arguments of the method.
(4) What is link?

Ans:
54
 A link refers to a connection or relationship between objects in a

system. It represents an association between instances of different
classes.
(5) Explain kind of actions that could be used in an interaction.

Ans:
 Actions represent executable behaviours or operations performed by
objects or participants during the course of an interaction. There are
several kinds of actions in UML, each serving a specific purpose in
modeling the dynamic behaviour of a system. Here are some common
kinds of actions:
1. Call Operation Action:
 Represents the invocation of an operation on an object. It specifies
the target object, the operation to be called, and any arguments.
2. Send Signal Action:
 Represents the sending of a signal to an object. Signals are used to
communicate between objects asynchronously.
3. Accept Event Action:
 Waits for the occurrence of a specified event before proceeding. It is
often used in conjunction with signals.
4. Create Object Action:
 Represents the creation of a new object. It specifies the type of the
object to be created and, optionally, initial values for its attributes.
5. Destroy Object Action:
 Represents the destruction of an object during the course of an
interaction.
6. Control Flow Action:
 Represents the control flow in an interaction. It is used to model the
sequence of actions and the order in which they are executed.
7. Loop Node:
55
 Represents a loop in the interaction. It includes a set of actions that

are repeated as long as a specified condition is true.
8. Conditional Node:
 Represents a conditional branch in the interaction. It includes
multiple sets of actions, and the execution path is determined based
on specified conditions.
9. Sequence Node:
 Represents a sequence of actions that are performed in a specific
order. It helps organize and structure the flow of actions within an
interaction.
(6) Which are the interaction diagrams?

Ans:
 Interaction diagrams are graphical representations that illustrate how
objects collaborate or interact during the execution of a use case or a
scenario.
 Two main types of interaction diagrams in OOAD are:
o Sequence Diagrams,
o Collaboration Diagrams (Communication Diagrams)
1. Sequence Diagrams:
 Sequence diagrams focus on the chronological ordering of
messages exchanged between objects over a specific scenario or
use case.
 Lifelines (representing objects), messages, activations (execution
occurrences), and other notations to show the sequence of
interactions.
 Useful for visualizing the flow of control and communication
between objects in different scenarios.
2. Collaboration Diagram (Communication Diagram):
56
 Collaboration diagrams emphasize the structural organization of

objects and their interactions within a system.
 Objects, links (associations between objects), messages, and other
notations to show the relationships and interactions between
objects.
 Provide a clear view of how objects are connected and how they
communicate in a system.
(7) Explain Sequence diagram in detail and with example.

Ans:
 A Sequence Diagram in UML (Unified Modeling Language) is a type of
interaction diagram that visualizes the interactions and messages
exchanged between different objects or components over time. It
illustrates the chronological order in which these interactions occur,
making it useful for understanding the dynamic behaviour of a system.
 Here are the key components and concepts of a Sequence Diagram:
I. Lifelines
II. Messages
III. Activations
IV. Focus of control
V. Return Messages
1. Lifelines:
 Represent individual objects or participants in the interaction.
Each lifeline is depicted as a vertical line, and its length represents
the time of its existence during the interaction.
2. Messages:
 Represent the communication between lifelines. Messages are
depicted as arrows indicating the direction of communication, and
they may be labeled to specify the type of interaction.
3. Activation:
 Represent the period during which an object is actively processing
a message. Activations are shown as a box or vertical bar on the
lifeline.
57
4. Focus of Control:
 Represents the flow of control between different lifelines. It helps
to visualize the order of message execution.
5. Return Messages:
 Indicate the response from the receiver to the sender after the
execution of a synchronous message.
Example for student login system:
(8) What is Object Life line?

Ans:
 An object lifeline, in the context of UML (Unified Modeling Language),
represents the existence of an object over a specific period of time
during an interaction or scenario. It is a visual element in a Sequence
Diagram, which is a type of UML diagram used to model the dynamic
behaviour of a system.
(9) What is focus of control?
58
Ans:
 In the context of UML (Unified Modeling Language) and sequence
diagrams, the "focus of control" refers to the period during which an
object is actively processing a message or performing an action. It is
associated with the concept of an activation bar on an object's lifeline.
1. Activation Bar:
 The activation bar is a graphical representation associated with a
lifeline on a sequence diagram. It is often depicted as a box or
vertical bar along the lifeline.
2. Period of Activity:
 The activation bar represents the time interval during which the
object associated with the lifeline is actively engaged in processing
a message or performing an action.
3. Visualizing Execution:
 The activation bar helps visualize when an object is in control and
actively executing a particular part of the interaction. It provides a
way to understand the flow of control during the sequence of
messages.
4. Sequential Flow:
 In a sequence diagram, the focus of control moves sequentially
along the lifeline as messages are processed. When a message is
received, the focus of control shifts to the activation bar
associated with the receiving object.
(10) Explain Collaboration Diagram In detail with suitable example.

Ans:
 A Collaboration Diagram, also known as a Communication Diagram, is a
type of UML (Unified Modeling Language) diagram that visualizes the
interactions and relationships between objects or components within a
59
system. It emphasizes the structural organization of objects and their

communication in a dynamic context.
 Here are the key components and concepts of a Collaboration Diagram:
1. Objects:
 Represented as rectangles, objects are instances of classes or
components participating in the collaboration.
2. Links (Association):
 Represent relationships or associations between objects. Links
connect objects and may be annotated with labels to indicate the
nature of the relationship.
3. Messages:
 Represent communication or interaction between objects.
Messages are shown as arrows between objects, indicating the
direction of communication.
4. Roles:
 Objects in a collaboration diagram may play specific roles in the
interaction. Roles help to clarify the responsibilities or functions of
each object.
5. Multiplicity Notation:
 Indicates the number of instances participating in an association. It
is often represented near the link with notations like "1," "0..1,"
"*", etc.
(11) Differentiate Collaboration and sequence diagram.

Ans:
Collaboration Diagram Sequence Diagram
1. The collaboration diagram is a 1. The sequence diagram is a UML
UML representation to visualize the representation to visualize the
organization of the objects and their sequence of calls in a system to
interaction. perform a specific functionality.
60
2. The collaboration diagram 2.The sequence diagram represents

represents the structural the sequence of messages flowing
organization of the system and the from one object to another.
messages sent and received.
3. If the time sequence is important, 3. If the object organization is
the sequence diagram can be used. important, then the collaboration
diagram can be used.
4. Collaboration diagrams are often 4. Sequence diagrams are often
used to illustrate the relationships associated with specific use cases or
between objects at a higher level, scenarios, providing a detailed view
providing a holistic view of the of the interactions between objects
system's architecture. in a particular context.
5. Collaboration diagrams typically do 5. Sequence diagrams include
not include activation bars, which activation bars, representing the
represent the duration of an object's periods during which objects are
activity in sequence diagrams. actively processing messages. They
show the focus of control during the
interaction.
(12) Explain the common uses of interaction diagram.

Ans:
 Interaction diagrams, including Sequence Diagrams and Collaboration
Diagrams in UML (Unified Modeling Language), are widely used in
software development for various purposes. Here are some common
uses of interaction diagrams:
1. Visualizing System Behaviour:
 Interaction diagrams provide a visual representation of how
objects or components within a system interact with each other.
They help stakeholders, including developers and designers, to
understand the dynamic behaviour of the system during specific
scenarios.
2. Modeling Use cases:
 Interaction diagrams are often associated with specific use cases
or scenarios. They help model and document the sequence of
61
interactions between objects, providing a detailed view of how the

system behaves in response to user actions or external events.
3. Clarifying Communication Flow:
 These diagrams clarify the flow of communication between
objects. They show the order and timing of messages exchanged
during an interaction, helping stakeholders understand the
sequence of actions.
4. Identifying Collaboration and Relationships:
 Collaboration diagrams specifically emphasize the relationships
between objects. They are useful for identifying and modeling
associations and collaborations between objects, aiding in the
understanding of system structure.
5. Verifying Requirements:
 Interaction diagrams help verify and validate system requirements
by visualizing how the system responds to different inputs or
stimuli. They assist in ensuring that the system behaviour aligns
with the specified requirements.
6. Detecting Design Issues:
 By modeling interactions, designers can identify potential design
issues or bottlenecks in the system. The diagrams may reveal
areas where improvements in communication or optimization are
needed.
7. Communication Among Team Members:
 Interaction diagrams serve as effective communication tools
among team members. They provide a shared visual language that
can be used by developers, architects, and other stakeholders to
discuss and refine the design of the system.
8. Supporting Implementation:
 Interaction diagrams can be valuable during the implementation
phase. Developers can use them as a reference to understand how
different components or objects should interact, aiding in the
coding process.
62
9. Documentation:
 Interaction diagrams serve as part of the documentation for a
system. They capture the dynamic aspects of the system,
providing insights into its behavior that can be referenced by
current and future development teams.
(13) What is Use case?

Ans:
 A use case is a representation of a system's behaviour or functionality
from the perspective of an external actor, such as a user or another
system. It describes a specific interaction between the system and its
users (or external entities) to achieve a particular goal or outcome. Use
cases are widely used in software development to capture and model
requirements.
(14) What is actor?

Ans:
 In the context of use case modeling in software development, an actor is
an external entity that interacts with a system. Actors are not part of the
system but rather represent roles that users, other systems, or external
components play in relation to the system. Actors initiate and
participate in use cases, which are representations of specific
interactions or functionalities within the system.
(15) By which relationship, actor and usecases can be connected?

Ans:
 In a use case diagram in UML (Unified Modeling Language), the
relationship between actors and use cases is typically represented by an
association. An association is a relationship that shows how elements,
such as actors and use cases, are related to each other.
63
 There are two main types of associations used to connect actors and use
cases: 1. Association Relationship,
2. Include Relationship
1. Association Relationship:
 The association relationship is the primary relationship used to
connect actors and use cases. It is represented by a line
connecting an actor to a use case. The association line may include
an arrow indicating the direction of the relationship.
2. Include Relationship:
 The include relationship is used to show that one use case includes
the behaviour of another use case. It is represented by a dashed
line with an "include" keyword. This relationship is often used to
indicate that a use case includes the behaviour of another use
case under certain conditions.
(16) Explain include and extend sterotypes in the context of

usecase.
Ans:
 In the context of use case modeling in UML (Unified Modeling
Language), stereotypes such as "include" and "extend" are used to
denote specific types of relationships between use cases. These
stereotypes provide additional information about how use cases are
related to each other and help to capture different aspects of the
system's behaviour.
1. Include Stereotype:
 The "include" stereotype is used to indicate that one use case
includes the behaviour of another use case under certain
conditions. It is often employed to represent a modular or
reusable aspect of the system's functionality.
2. Extend Stereotype:
 The "extend" stereotype is used to represent optional or
conditional behaviour that can extend the behaviour of a base use
64
case. It allows for the modeling of variations or optional steps that

may be performed under specific conditions.
(17) State the Static and Dynamic diagram in UML.

Ans:
 Static Diagram:
Static diagrams in UML focus on depicting the structural aspects of a
system. They illustrate the static relationships, structure, and
organization of elements within the system. Some common types of
static diagrams include:
1. Class Diagram:
 Represents the static structure of a system by showing classes,
their attributes, methods, and relationships.
2. Object Diagram:
 Provides a snapshot of the instances of classes at a specific point
in time, showing the relationships between objects.
3. Package Diagram:
 Represents the organization of elements into packages, helping to
manage the complexity of large systems.
4. Component Diagram:
 Shows the physical components and dependencies between them
in a system.
5. Deployment Diagram:
 Illustrates the physical deployment of software components to
hardware nodes.
6. Composite Structure Diagram:
 Represents the internal structure of a class, including its parts,
collaborations, and interactions.
 Dynamic Diagram:
65
Dynamic diagrams in UML focus on depicting the dynamic behaviour and

interactions of elements within a system over time. They show the flow
of control, the sequence of events, and the interactions between
objects. Some common types of dynamic diagrams include:
1. Use Case Diagram:
 Represents the interactions between actors (external entities) and
use cases, showcasing the high-level functionality of a system.
2. Sequence Diagram:
 Illustrates the sequence of messages exchanged between objects
or components over time, showing the dynamic behaviour of a
system.
3. Collaboration Diagram:
 Visualizes the interactions between objects and their
relationships, emphasizing the structural organization during
dynamic behaviour.
4. Activity Diagram:
 Represents the flow of activities, actions, and decisions within a
system, providing a high-level view of dynamic behaviour.
5. State Machine Diagram:
 Models the dynamic behaviour of an object or system in terms of
states, transitions, and events.
6. Timing Diagram:
 Depicts the behaviour of objects over a period of time, showing
the timing constraints and interactions.
(18) What is Usecase diagram? Explain it in detail also explain the

components of use case diagram. Give example of use case
diagram.
Ans:
66
 A use case diagram is a type of UML (Unified Modeling Language)

diagram that represents the interactions between actors (external
entities) and use cases in a system. It provides a high-level view of
the functionality of a system, focusing on what a system will do
from the user's perspective. Use case diagrams are widely used
during the requirements analysis phase to capture and visualize
the functional requirements of a system.
 Components of Use Case Diagram:
1. Actor:
 An actor represents an external entity that interacts with
the system. Actors can be users, other systems, or entities
that initiate or participate in use cases.
2. Use Case:
 A use case represents a specific functionality or behaviour
of the system. It describes a set of interactions between
the system and external entities to achieve a particular
goal.
3. Association:
 An association represents the relationship between an
actor and a use case. It shows that an actor is involved in
or interacts with a particular use case. Associations are
depicted by connecting lines between actors and use
cases.
4. System Boundary:
 The system boundary is represented by a box that
encloses all the use cases of the system. It defines the
scope of the system being modeled.
5. Include Relationship:
 The include relationship is used to show that one use case
includes the behaviour of another use case. It is denoted
by the <include> stereotype.
6. Extend Relationship:
67
 The extend relationship is used to represent optional or

conditional behaviour that can extend the behaviour of a
base use case. It is denoted by the <extend> stereotype.
 Use Case Diagram example for ATM Subsystem:
(19) State the common uses of use case diagram.

Ans:
 Use case diagrams are widely used in software development and
systems engineering to capture, model, and communicate the functional
requirements of a system. Here are some common uses of use case
diagrams:
1. Requirements Analysis:
68
 Use case diagrams are instrumental in requirements

analysis by providing a visual representation of the high-
level functionalities that a system must deliver. They help
stakeholders understand the intended behaviour and
interactions of the system.
2. Communication with Stakeholder:
 Use case diagrams serve as a communication tool between
various stakeholders, including clients, users, designers,
and developers. They provide a common visual language
to discuss and validate system requirements.
3. System Design:
 During the design phase, use case diagrams contribute to
the creation of a blueprint for the system's structure. They
help in defining the major functionalities and the expected
interactions between users and the system.
4. Scope Definition:
 Use case diagrams help in defining the scope of the system
by identifying the external actors (users, other systems)
and the major functionalities that need to be
implemented.
5. User-Centered Design:
 Use case diagrams are user-centered and focus on the
interactions between external actors (users) and the
system. This approach helps ensure that the system meets
the needs and expectations of its users.
6. System Validation:
 Use case diagrams provide a foundation for validating the
system against user requirements. By clearly illustrating
the expected interactions, they help ensure that the
system aligns with the intended functionality.
7. Identification of System Boundaries:
69
 The system boundary in a use case diagram defines the

scope of the system. This helps in clearly identifying what
is part of the system and what lies outside of it.
8. Impact Analysis:
 Use case diagrams help in understanding the impact of
changes or updates to the system. By visualizing the
dependencies between use cases, developers can assess
the potential impact on other parts of the system.
9. Project Planning:
 Use case diagrams aid in project planning by providing a
high-level overview of the system functionality. They can
assist in estimating the scope of work and prioritizing
development tasks.
10. Documentation:
 Use case diagrams contribute to the documentation of the
system by capturing key functional aspects. They provide a
concise and visual representation that can be referenced
by various project stakeholders.
(20) What is Activity?

Ans:
 In UML (Unified Modeling Language), an "activity" refers to a unit of
work or behavior performed by a system, typically depicted in an activity
diagram. An activity diagram visually represents the flow of activities
within a system or a business process.
 Activities are represented by rounded rectangles, and arrows indicate
the flow of control between them. These diagrams are useful for
modeling dynamic aspects of a system, illustrating the sequence of
activities, decision points, concurrency, and synchronization.
 They provide a high-level view of the workflow and are particularly
helpful in understanding business processes or the behaviour of a
software system.
70
(21) What is Action?

Ans:
 In the context of UML (Unified Modeling Language) and activity
diagrams, an action is a fundamental unit that represents a specific
operation or step within an activity.
 Actions in UML activity diagrams depict atomic, indivisible tasks or
behaviours that contribute to the overall functionality of the system or
process being modeled.
1. Atomic Operation:
 An action is considered atomic, meaning it represents a
single, indivisible operation. It is not further decomposed
within the context of the activity diagram.
2. Operation or Task:
 Actions can represent a variety of operations or tasks,
ranging from simple operations like calculations to more
complex tasks like sending a message or invoking a
method.
3. Symbol:
 In activity diagrams, actions are represented by rectangles
with rounded corners. The name of the action is typically
written inside the rectangle.
4. Control Flow:
 Actions are connected by control flow arrows, indicating
the sequence in which they are executed within the
activity.
(22) What is action state and activity state?

Ans:
1. Action State:
 An action state in a state machine diagram represents a
state where a specific action or operation is being
71
executed. It signifies that an object is performing a

particular behavior or task.
 Action states are often used to model atomic actions or
operations that are instantaneous and do not have an
inherent duration.
2. Activity State:
 An activity state, on the other hand, represents a state where a
more complex activity or behavior is ongoing. Unlike action states,
activity states imply that the behavior within the state has a
duration and may involve multiple steps or actions.
(23) What is forking and joining? Explain it with suitable example.

Ans:
 Fork:
The fork symbol in an activity diagram is represented by a small bar, and
it indicates the point where a single flow of control is split into multiple
parallel flows. Each parallel flow represents a separate execution path
for concurrent activities.
 Example:
In this diagram the process order fork allows for the parallel execution of
checking stock availability and applying a discount code.
The flows then merge back into a single flow at the complete order join
node before moving on to the order conformation step.
72
 Joining:
The join symbol in an activity diagram is represented by a small bar
enclosed in a circle, and it indicates the point where multiple parallel
flows converge back into a single flow of control. It represents the
synchronization point where the parallel activities are joined.
 Example:
This example at the left of the figure indicates that a join is used to
synchronize the processing of the ship order and send invoice
behaviours.
Here, when both have been completed, control is passed to close order.
(24) What is branching?

Ans:
 In the context of activity diagrams within UML (Unified Modeling
Language), branching refers to the representation of decision points
where the flow of control in a process or activity can take different paths
based on certain conditions or decisions.
 Branching is used to model scenarios where the next action or set of
actions depends on the evaluation of a decision.
(25) What is transition?

Ans:
 In the context of UML (Unified Modeling Language) and state machine
diagrams, a transition represents a change of state within a system.
73
 Transitions capture the conditions or events that trigger a change from

one state to another, indicating how the system evolves over time.
(26) Explain the use of swimlanes in activity diagram.

Ans:
 Swimlanes in an activity diagram are visual elements that partition and
organize the actions and activities based on the roles or responsibilities
of different participants or entities involved in a process. They provide a
way to represent the flow of activities and actions in a structured
manner, making it clear which entities are responsible for each part of
the process. Swimlanes are especially useful in depicting the
interactions and collaborations between different participants.
1. Partitioning:
 Swimlanes divide the activity diagram into horizontal or vertical
partitions, each representing a participant, role, or organizational
unit involved in the process. This partitioning helps in organizing
and categorizing activities.
2. Participants:
 Participants within swimlanes can be individuals, roles,
departments, or external entities. Each participant is associated
with the activities that they are responsible for or involved in.
3. Roles and Responsibilities:
 Swimlanes make it easy to visualize the roles and responsibilities of
different participants in the overall process. Each swimlane is
dedicated to a specific participant or role, and the activities within
that swimlanes belong to that participant.
4. Cross-Functional Processes:
 swimlanes are particularly beneficial for representing cross-
functional processes where activities involve multiple participants
or departments. They show how different parts of the process are
distributed among various entities.
74
5. Clarity and Communication:
 Swimlanes enhance the clarity of the activity diagram, making it

more understandable for stakeholders. They help in communicating
the collaboration and coordination aspects of the process.
(27) Explain how we can show the flow of object in activity

diagram.
Ans:
 In UML (Unified Modeling Language) activity diagrams, the flow of

objects can be represented using object nodes. Object nodes depict the
creation, flow, and destruction of objects as they participate in the
activities within the diagram. Object nodes are used to model the
passing of objects between actions, showing how data or entities move
through the different steps of the process.
1. Object Nodes:
 Object nodes are used to represent objects within an activity

diagram. They are typically represented by rectangles with the
name of the object inside.
2. Object Flows:
 Object flows represent the flow of objects between actions or

activities. They are depicted by arrows connecting object nodes.
3. Initial Nodes and Activity Final Nodes:
 Initial nodes (filled circle) and activity final nodes (enclosed circle)
are used to denote the start and end points of the object flow
within an activity.
4. Actions and Behaviours:
 Actions and behaviors in the activity diagram are connected by
object flows, indicating the input and output objects for each
action.
75
(28) Explain the common uses of activity diagram.

Ans:
 Activity diagrams in UML (Unified Modeling Language) are versatile and
can be used for various purposes in the analysis, design, and
documentation of a system. Here are some common uses of activity
diagrams:
1. Modeling Business Processes:
 Activity diagrams are often used to model and visualize business

processes. They provide a clear and structured representation of how
different activities, tasks, and decisions are performed within an
organization.
2. Workflow Modeling:
 Activity diagrams are employed to model workflows, showing the
sequence of activities and their dependencies. They help in
understanding and optimizing the flow of work within a system or a
business process.
3. System Behavior Modeling:
 Activity diagrams can be used to model the dynamic behavior of a
system. They depict the sequence of activities and actions that take
place in response to external stimuli or events.
4. Use case scenarios:
 Activity diagrams are used to model use case scenarios, illustrating the
flow of events and actions that occur when a particular use case is
executed. They help in capturing the interactions between users and the
system.
5. Requirements Analysis:
 Activity diagrams assist in requirements analysis by providing a visual
representation of the functional aspects of a system. They help
stakeholders, including analysts and developers, to understand the
intended behavior of the system.
6. Collaboration and Communication:
76
 Activity diagrams serve as a communication tool between stakeholders.

They provide a visual language that can be easily understood by both
technical and non-technical team members, fostering collaboration and
discussion.
7. Process Improvement:
 Organizations use activity diagrams to identify bottlenecks,
inefficiencies, and opportunities for improvement in their processes.
Analyzing the flow of activities helps in streamlining processes and
increasing efficiency.
8. System Design:
 During the design phase of software development, activity diagrams
contribute to the creation of a blueprint for the system. They help in
defining the major functionalities, interactions, and dependencies.
9. Testing:
 Activity diagrams can be used as a basis for generating test cases. Each
activity represents a specific scenario, and testing can be organized
around these scenarios to verify the system's functionality.
10. Project Management:
 Activity diagrams contribute to project planning by providing a high-level
overview of the system's functionality. They can assist in estimating the
scope of work, identifying dependencies, and prioritizing tasks.
(29) Explain Activity Diagram in detail with suitable example.

Ans:
 An activity diagram in UML (Unified Modeling Language) is a graphical
representation of the dynamic aspects of a system, capturing the flow of
activities and actions within a process or a workflow. It provides a visual
depiction of the sequential and parallel activities, along with decisions
and the flow of control between them. Activity diagrams are often used
to model business processes, use case scenarios, and system behaviors.
1. Activity:
77
An activity represents a specific unit of work or behavior within the

system. It can be a simple action or a more complex set of actions.
2. Action:
Actions are atomic elements within an activity, representing individual
steps or operations. They are depicted as rounded rectangles.
3. Decision Node:
A decision node is represented by a diamond shape and indicates a
branching point in the flow of activities. The decision is typically based
on a condition or a decision-making criterion.
4. Merge Node:
A merge node is represented by a diamond enclosed in a circle and
indicates the point where parallel flows converge back into a single flow.
5. Fork and Join Nodes:
Fork nodes split the flow of control into multiple parallel paths, allowing
for concurrent execution of activities. Join nodes bring these parallel
paths back together.
6. Initial Node:
An initial node (filled circle) marks the starting point of the activity
diagram.
7. Final Node:
A final node (enclosed circle) marks the end or completion of the activity
diagram.
 Example:
Consider an example of an emotion based music player:
78
(30) Explain notations and symbols used in activity diagram.

Ans:
 Activity diagrams in UML (Unified Modeling Language) use specific
notations and symbols to represent various elements and structures.
Here are the key notations and symbols commonly used in activity
diagrams:
1. Activity:
An activity is represented by a rounded rectangle. It signifies a specific
unit of work or behavior within the system.
2. Action:
Actions are depicted as rounded rectangles with a solid border. They
represent atomic elements within an activity, representing individual
steps or operations.
3. Decision Node:
A decision node is represented by a diamond shape. It indicates a
branching point in the flow of activities, where the decision is typically
based on a condition or a decision-making criterion.
4. Merge Node:
79
A merge node is represented by a diamond enclosed in a circle. It

indicates the point where parallel flows converge back into a single flow.
5. Fork Node:
A fork node is represented by a solid horizontal bar, indicating the point
where the flow of control is split into multiple parallel paths. It allows for
concurrent execution of activities.
6. Join Node:
A join node is represented by a solid horizontal bar with a circle,
indicating the point where parallel paths converge back into a single
flow.
7. Initial Node:
An initial node is represented by a filled circle and marks the starting
point of the activity diagram.
8. Final Node:
A final node is represented by an enclosed circle and marks the end or
completion of the activity diagram.
9. Object Node:
An object node is used to represent objects within an activity diagram. It
is depicted as a rectangle with the name of the object inside.
10. Object Flow:
Object flows represent the flow of objects between actions or activities.
They are depicted by arrows connecting object nodes.
(31) What is Collaboration? How it can be represented in UML?

Ans:
 In UML (Unified Modeling Language), collaboration refers to the
interactions and collaborations among objects or components within a
system to achieve a specific goal or perform a particular task. It
emphasizes the communication and relationships between objects and
how they work together to fulfill a common objective.
80
 Collaboration can be represented in UML using collaboration diagrams,

also known as communication diagrams. Collaboration diagrams visually
depict the interactions and relationships between objects or
components, emphasizing the messages exchanged during a particular
scenario or use case.
1. Object:
 Objects are represented by rectangles with the name of the object
inside. Each object represents an instance of a class or a
component participating in the collaboration.
2. Links:
 Links (also known as associations) connect objects and represent
the relationships between them. They are typically represented by
lines connecting objects.
3. Messages:
 Messages represent the communication between objects.
Messages can be synchronous (indicated by a solid arrow) or
asynchronous (indicated by an open arrow). They convey the flow
of information or the invocation of methods.
4. Roles:
 Roles are used to specify the specific responsibilities or roles that
objects play in the collaboration. They are often indicated near the
object.
81

Assignment 2&3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Assignment 2&3

Uploaded by

Copyright:

Available Formats

OBJECT ORIENTED ANALYSIS AND DESIGN WITH UML

NAME: THAKKAR MAITRI PIYUSHKUMAR

2)Explain web engineering team.

 The Web engineer should also have a solid understanding of component

3)Write a short note on requirements analysis for Web Apps.

4)Discuss analysis model for Web Apps.

5)Write a short note on:

 These structural elements encompass content objects(e.g.. Text,

II. Interaction Model:

(1) Sequence diagram:

ii. Actor: It represents the role, which involves human

(2) State Diagram:

6)Write a short note on UML detail.

Association: Describes a relationship between classes or objects.

8)Write a short note on conceptual model of UML.

 A conceptual model is composed of several interrelated concepts. It

 Example: The class notation exposes the most important

10)Discuss the software Development Life Cycle in depth.

10)List out different views of modelling a Software system’s

Process view Deployment view

12)Write a short note on Relationship in depth.

(13) Explain Association Relationship with their adornments.

 Association relationship is a structural relationship in which different

 It is represented by a line between the classes followed by an arrow that

 A single teacher has multiple students(One to Many).

 A single student can associate with many teachers(Many to One).

(14) Give Difference between “Is-a-kind-of” and “has-a”

3. It signifies a hierarchy, where a subclass 3. It signifies a containment or association,

(15) Write a short note on structural diagrams.

 They showcase classes, their attributes, methods, and

(16) Write a short note on behavioral diagrams.

 Behavioral diagrams in UML (Unified Modeling Language) focus on

o shows the flow from activity to activity; an “activity” is an ongoing

(17) Explain class diagram with example.

(18) Explain forward and reverse engineering.

Creating high-level and low-level design specifications, often

Generating or updating documentation based on the

(19) What is importing and Exporting in package? Explain

 The public parts of a package are called its exports.

(20) Draw a class diagram of B2C shopping web site.

1.Shopping cart class:

- Has a method to place an order, creating an instance of the

- Represents a product available for purchase on the website.

(21) Write a short note on Advance Classes.

 These design pattern involve organizing classes into tree

Give short answer:

1. Which relationship known as “Is-a-kind-of” relationship.

 In UML, stereotypes are used to extend or redefine the semantics of

6.Define: Class, Interface, Active class, Component, Node, Package.

hardware device, like a server or a computer, or a

(1) What is an Interaction?

(2) What is the use of interaction?

They provide a time-ordered sequence of events and

(3) What is message?

(4) What is link?

 A link refers to a connection or relationship between objects in a

(5) Explain kind of actions that could be used in an interaction.

 Represents a loop in the interaction. It includes a set of actions that

(6) Which are the interaction diagrams?

 Collaboration diagrams emphasize the structural organization of

(7) Explain Sequence diagram in detail and with example.

(8) What is Object Life line?

(9) What is focus of control?