Assignment No 1

Q1 What is SRS? Why do we need it?

software requirements specification (SRS) is a document that describes what the software will do and how it will be
expected to perform. It also describes the functionality the product needs to fulfill all stakeholders (business, users) needs.

A software requirements specification is the basis for your entire project. It lays the framework that every team involved in
development will follow.It’s used to provide critical information to multiple teams — development, quality assurance,
operations, and maintenance

Q2.What are the content of SRS?

SRS (Software Requirements Specification) is a document that describes the system that should be developed and
implemented. It contains a full and detailed description of intended purposes, system behavior, user’s and system
requirements. Also, SRS defines the expected system performance and capabilities.

The aim of SRS is to specify the software product in details. In other words, it contains all necessary and
important information that the product team should be aware of in order to create the software.

The SRS Structure:

• Introduction (purpose, scope, terms, references, overview)

• Overall description (product perspective, functions, user characteristics, assumptions, etc.)
• Specific requirements (for interface, performance, design, etc.)
SRS should be unambiguous, complete, correct, consistent, modifiable and verifiable. It captures a set of various
requirements types:

• functional
• performance
• quality
• safety
• reliability
• interface
• maintainability
• operational
• resource.
•
Q3.What is data dictionary?

A data dictionary is a file or a set of files that includes a database's metadata. The data dictionary hold records
about other objects in the database, such as data ownership, data relationships to other objects, and other data.
The data dictionary is an essential component of any relational database. Ironically, because of its importance, it
is invisible to most database users. Typically, only database administrators interact with the data dictionary.

The data dictionary, in general, includes information about the following:

o Name of the data item

o Aliases
o Description/purpose
 o Related data items
o Range of values
o Data structure definition/Forms

Q4.What is purpose of using SRS?

The software requirements specification document lists sufficient and necessary requirements for the project
development. To derive the requirements, the developer needs to have clear and thorough understanding of the
products under development.
 Assignment No 2

Q1 In which model use case/sequence/activity diagram can be categorized ?(Object Model/Dynamic/Functional)

Ans:

Use case Diagram -

Sequence Diagram- Dynamic Model

Activity Diagram- Dynamic model

The dynamic model is used to express and model the behaviour of the system over time.

Q2 What is use case, actor and system boundary ?

Ans: -

Use Case: A use case is a list of actions or event steps typically defining the interactions between a role (known
in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal. The actor can be a human
or other external system.

Actor: In UML, an actor is a model element that interacts with a system. As a model element, it can be an
abstract person (e.g. “customer”) or another external system.

e.g. “User”, “Stakehoder” or “External System”.

System Boundary: A system boundary is a rectangle that you can draw in a use-case diagram to separate the use
cases that are internal to a system from the actors that are external to the system.

Q3 List Different relations used in Use case diagram

Ans :

There can be 5 relationship types in a use case diagram.

Association between actor and use case.

Generalization of an actor.
Extend between two use cases.

Include between two use cases.

Generalization of a use case.

Q4 Can we use generalization relation for a use case as well as actors ?

Ans: There may be instances where actors are associated with similar use cases while triggering a few use
cases unique only to them. In such instances, you can generalize the actor to show the inheritance of
functions. You can do a similar thing for use case as well.

Q5 Which different dependencies can be used in use case model ?

Ans:

Include:a] The include relationship allow us to include the behavior one use case into the flow of another use
case.

b] The including use case is called as base use case & included use case is called as inclusion use case.

Eg: E.g. Login use case include Enter credentials use case

Extend: a] This relationship provides a way to insert new behavior in an existing use case.

b] The base use case provides set of extension point where a new behavior can be

added.

c] In this relation the base use case is complete without the extended use case & does

not have the idea about the extension use case

d ]Eg: Invalid password use case extend Login use case (with additional steps of actions or behavior).

Q6 Explain extend and include relationship with proper example

Ans : same ans as 5th ans.

Q7 What kind of information is captured in use case diagram

Ans: The purpose of use case diagram is to capture the dynamic aspect of a system. Additional diagrams and
documentation can be used to provide a complete functional and technical view of the system.
 Assignment No 3

Q1 What are the different elements of activity diagram, explain with notations. Activity Diagram Notations:

Notation Description UML Notation

Activity

Is used to represent a set of actions

Action

A task to be performed

Control Flow

Shows the sequence of execution

Object Flow

Show the flow of an object from one activity (or

action) to another activity (or action).

Initial Node
Portrays the beginning of a set of actions or
activities

Activity Final Node

Stop all control flows and object flows in an

activity (or action)

Object Node

Represent an object that is connected to a set of

Object Flows

Decision Node

Represent a test condition to ensure that the

control flow or object flow only goes down one
path
Merge Node

Bring back together different decision paths that

were created using a decision-node.
Fork Node

Split behavior into a set of parallel or concurrent

flows of activities (or actions)

Join Node

Bring back together a set of parallel or

concurrent flows of activities (or actions).

Swimlane and Partition

A way to group activities performed by the same

actor on an activity diagram or to group activities
in a single thread
Q2 What is activity, what is difference between activity and action?

An activity, also known as an activity state, on a UML Activity diagram typically represents the invocation of an operation,
a step in a business process, or an entire business process. Action is a named element which represents a single atomic step
within activity, i.e.that is not further decomposed within the activity. Activity represents a behavior that is composed of
individual elements that are actions.

Q3 When to use fork and join nodes in activity diagram.

A fork node is used to split a single incoming flow into multiple concurrent flows. It is represented as a straight, slightly
thicker line in an activity diagram.

A join node joins multiple concurrent flows back into a single outgoing flow. A fork and join node used together are often
referred to as synchronization.

Q4 When to use decision and merge nodes in activity diagram.

A decision node is used to accepts tokens on an incoming edge and presents them to multiple outgoing edges.A merge node
is a control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows but to accept
one among several alternate flows.

Q5 What are the different types of combined fragments (alt, opt, loop, break etc…)

Combined fragment is an interaction fragment which defines a combination (expression) of interaction fragments. A
combined fragment is defined by an interaction operator and corresponding interaction operands.

The different types of combined fragments are:

alt - alternatives

opt - option

loop - iteration

break - break

par - parallel

strict - strict sequencing

seq - weak sequencing

critical - critical region

ignore - ignore

consider - consider

assert - assertion
neg - negative
Assignment No 4 & 5
 Assignment No 6
1. What are different elements in sequence diagram?
Answer: Sequence diagram is the most common kind of interaction diagram, which focuses on
the message interchange between a number of lifelines. Sequence diagram describes an
interaction by focusing on the sequence of messages that are exchanged, along with their
corresponding occurrence specifications on the lifelines. The nodes and edges are typically
drawn in a UML sequence diagram are
• lifeline
• execution specification
• message
• combined fragment
• interaction use
• state invariant
• continuation
• destruction occurrence.

2. What is object lifeline, focus of control?

Answer:
a) Lifeline is a named element which represents an individual participant in the
interaction. A lifeline is shown using a symbol that consists of a rectangle forming its
"head" followed by a vertical line (which may be dashed) that represents the lifetime of
the participant.
b) Focus of control (FOC) is used in sequence diagrams to show the period of time during
which an object performs an action. FOC is rendered as a thin, rectangular object that sits
on top of object lifelines. The top of the FOC rectangle coincides with the receipt of a
message. The bottom of the rectangle coincides with the completion of an action and can
be marked with a return message.
3. What are the different types of messages used in sequence diagram (synchronous,
asynchronous, create, destroy and return) explain with notations.
Answer:
Messages – Communication between objects is depicted using messages. The messages
appear in a sequential order on the lifeline. We represent messages using arrows. Lifelines
and messages form the core of a sequence diagram. The types of messages are as follows:
a) Synchronous messages – A synchronous message waits for a reply before the
interaction can move forward. The sender waits until the receiver has completed the
processing of the message. The caller continues only when it knows that the receiver
has processed the previous message i.e. it receives a reply message. A large number of
calls in object oriented programming are synchronous. We use a solid arrow head to
represent a synchronous message.
b) Asynchronous Messages – An asynchronous message does not wait for a reply from
the receiver. The interaction moves forward irrespective of the receiver processing the
previous message or not. We use a lined arrow head to represent an asynchronous
message.
 c) Create message – We use a Create message to instantiate a new object in the
sequence diagram. There are situations when a particular message call requires the
creation of an object. It is represented with a dotted arrow and create word
labelled on it to specify that it is the create Message symbol.
d) Destroy Message – We use a Destroy Message to delete an object. When
an object is deallocated memory or is destroyed within the system we use
the Delete Message symbol. It destroys the occurrence of the object in the
system. It is represented by an arrow terminating with a x.
e) Reply Message – Reply messages are used to show the message being
sent from the receiver to the sender. We represent a return/reply message
using an open arrowhead with a dotted line. The interaction moves
forward only when a reply message is sent by the receiver.

4. Why to use swim lanes?

Answer: Swim lanes are used to show which activities are performed by
which organization in the activity diagram. The lanes are boundaries are
drawn and the activities of a particular organization are drawn in the same lane
as that of the organization. Swim lanes have to be ordered in a Logical
Manner. It is suggested to have less than five swim lanes in an activity
diagram.
 Assignment No 7
Q1 what is state,compositestate,historystate,sequentialstate,concurrent state and nested
state?

State:

A state diagram is a type of diagram used in computer science and related fields to
describe the behavior of systems.

State diagrams require that the system described is composed of a finite number of states;
sometimes, this is indeed the case,

while at other times this is a reasonable abstraction.

Composite state:

A composite state is a state that contains one or more other substates.

It can be used to group states into logical compounds and thus make the statechart more
comprehensible.

When a composite state is entered, its entry node denotes the substate to be activated.

History State:

History states allow the state machine to re-enter the last substate that was active prior to
leaving the composite state.

An example of history state usage is presented in the figure below.

Sequential State:

A sequential composite state contains a single state diagram composed of sub-states or

inner states and the transitions between them.

Concurrent state:

A concurrent composite state contains two or more sequential state diagrams in regions
separated by dashed lines called concurrent region boundary lines.
Nested state:

A state can contain other states, often called as nested states or substates.

If you are modeling complex state machines, use nested states to separate detailed
behavior into multiple levels.

Q2 What is Event? Give the type of event with example?

Events:

Events are some occurrences that can trigger state transition of an object or a group of
objects.

Events have a location in time and space but do not have a time period associated with it.
Events are generally associated with some actions.

Types:

External and Internal Events:

External events are those events that pass from a user of the system to the objects within
the system.

For example, mouse click or key−press by the user are external events.

Internal events are those that pass from one object to another object within a system. For
example, stack overflow, a divide error, etc.

Deferred Events:

Deferred events are those which are not immediately handled by the object in the current
state but are lined up in a queue so that

they can be handled by the object in some other state at a later time.

Event Classes:
 Event class indicates a group of events with common structure and behavior. As with
classes of objects, event classes may also be organized in a hierarchical structure. Event classes
may have attributes associated with them, time being an implicit attribute. For example, we can
consider the events of departure of a flight of an airline, which we can group into the following
class –

Flight_Departs (Flight_No, From_City, To_City, Route)

Q3 What is Transition?

Transition:

A transition denotes a change in the state of an object. If an object is in a certain state

when an event occurs, the object may perform certain activities subject to specified conditions
and change the state. In this case, a state−transition is said to have occurred. The transition gives
the relationship between the first state and the new state.

A transition is graphically represented by a solid directed arc from the source state to the
destination state.

The five parts of a transition are −

Source State − The state affected by the transition.

Event Trigger − The occurrence due to which an object in the source state undergoes a
transition if the guard condition is satisfied.

Guard Condition − A Boolean expression which if True, causes a transition on receiving

the event trigger.

Action − An un-interruptible and atomic computation that occurs on the source object
due to some event.
 Target State − The destination state after completion of transition.

Q4 what is exit action, entry action and do?Explain with different state?

In UML models, you can add an entry, do, or exit activity to a state to describe an activity
that is performed only upon entry into a state,

exit out of a state, or that is ongoing in a particular state.

Ex:

Right-click a state; then click Add UML and complete one of the following steps:

To add an entry action to a state, click Entry.

To add a do action to a state, click Do.

To add an exit action to a state, click Exit.

Q5 what are different components of state diagrams, draw each with its notations?

- Initial State: This state shows the first activity of the flow.

- State: A state represents the state of an object at a particular given point of time.
- Transition: The transition from one state to another state of objects is represented by an arrow.

- Event and Action: A trigger that causes a transition to occur.

- Signal: When a message or a trigger caused by an event to a state, which causes a transition,
this message is called as a signal.

- Final State: The state diagram ends with a diagram that depicts a bull’s eye is known as Final
State.

Q6 In which model state chart or state diagram falls?(Object model/dynamic/functional)?

Objet Model:

"An object diagram is a graph of instances, including objects and data values.

A static object diagram is an instance of a class diagram; it shows a snapshot of the

detailed state of a system at a point in time.

The use of object diagrams is fairly limited, namely to show examples of data structure."
 Assignment No 8

Q1 What is GRASP Pattern?

Ans : GRASP (General Responsibility Assignment Software Patterns) is a design pattern in object-
oriented software development used to assign responsibilities for different modules of code.
As a tool for software developers, GRASP provides a means to solve organizational problems and offers a
common way to speak about abstract concepts. The design pattern sets responsibilities
for objects and classes in object-oriented program design.GRASP with object-oriented programming
classifies problems and their solutions together as patterns.With these problems and solutions well
defined, they can be applied in other similar instances. GRASP assigns seven types of roles to classes and
objects in order to make for clear delineation of responsibilities.

Q2 Enlist the different types of GRASP pattern?

Ans: This is the list of 9 GRASP patterns (sometimes called principles )

1.Information Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Indirection
7. Polymorphism
8. Pure Fabrication
9. Protected Variations

Q3 What is Information Expert Pattern?

Ans:

• Information expert is a principle used to determine where to delegate responsibilities. These

responsibilities include methods, computed fields, and so on.
• Using the principle of information expert, a general approach to assigning responsibilities is to
look at a given responsibility, determine the information needed to fulfill it, and then determine
where that information is stored.
• Information expert will lead to placing the responsibility on the class with the most information
required to fulfill it.
• The Information Expert pattern states that we need to assign responsibilities to the right expert. Is
the game board itself the expert on how pieces can move or are the pieces themselves the experts
at their moves? In the case of the chess board, the piece is the expert on the possible move options
for that piece.
Q4 What is a Creator Pattern?

Ans: Creator is a GRASP principle which helps to decide which class should be responsible for
creating a new instance of a class. Object creation is an important process, and it is useful to have
a principle in deciding who should create an instance of a class.

The Creator defines WHO instantiates WHAT object. In object-oriented design lingo, we need to ask the
question of who creates an object A. The solution is that we give class B the role of instantiating (creating
an instance of) a class A if ;

• B contains A
• B uses most of A's features
• B can initialize A

Let's use a real-world example of a chess game. A chess game includes 2 players, 32 pieces (16 per
player) and a game board with 64 squares.

Q5 Explain High Cohesion pattern.

Ans: High cohesion is an evaluative pattern that attempts to keep objects appropriately focused,
manageable and understandable. High cohesion is generally used in support of low coupling.The
term cohesion is used to indicate the degree to which a class has a single, well-focused
responsibility. Cohesion is a measure of how the methods of a class or a module are meaningfully and
strongly related and how focused they are in providing a well-defined purpose to the system.

It is important to have code that is clean. Objects need to be manageable, easy to maintain and
have clearly-stated properties and objectives. This is High Cohesion which includes defined
purposes of classes, ability to reuse code, and keeping responsibility to one unit. High Cohesion,
Low Coupling, and clearly defined responsibilities go together. To achieve High Cohesion, a
class should have ONE job. A game piece should move across the board. It should not need to
setup the board or define moves for other players.

Q6 Explain Low Coupling GRASP Pattern?

Ans: Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on
other elements. Low coupling is an evaluative pattern that dictates how to assign responsibilities to
support

• lower dependency between the classes

• change in one class having a lower impact on other classes
• higher reuse potential

Low Coupling can be described as following the path of least resistance. Coupling is a measure of how
much objects are tied to one another. We can follow the information expert for the lowest level of
coupling. So, to get the moves available to a piece, we start with the information expert, and not some
other class. In the chess game, the MovePiece class needs to get information from the board and the place
it intends to move to. We can couple all of this together in one flow,

Q.7) what is controller grasp pattern ?

Ans : The Controller is responsible for handling the requests of actors. The Controller is the middle-man

between your user clicking “Send” and your back-end making that happen. The Controller knows how to

interpret the actions of user-interfaces, and how to connect those actions to behaviours in your system.

When a request comes from the UI layer object, Controller pattern helps us in determining what is that

first object that receives the message from the UI layer objects.

This object is called a controller object which receives a request from the UI layer object and then

controls/coordinates with other objects of the domain layer to fulfill the request.

It delegates the work to other class and coordinates the overall activity .

Q.8) Explain polymorphism grasp pattern with example ?

Ans: The Polymorphism GRASP pattern deals with how a general responsibility gets distributed to a set

of classes or interfaces. It is proposed to distribute responsibilities between classes using polymorphic

operations, leaving each external system with its own interface.

As an example, we can cite standardized libraries, or application configuration by connecting certain

plugins for different customers according to their needs. The presence of a switch construction in the

code is a violation of this principle, switches and are subject to refactoring. Overuse of polymorphism

leads to over-complication of the code and is generally discouraged.

Q.9) explain pure fabrication pattern with example ?

Ans: A pure fabrication is a class that does not represent a concept in the problem domain, specially

made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a

solution presented by the information expert pattern does not). This kind of class is called a "service" in

domain-driven design.
For example, Suppose we Shape class, if we must store the shape data in a database.

● If we put this responsibility in Shape class, there will be many database related operations thus

making Shape incohesive.

● So, create a fabricated class DBStore which is responsible to perform all database operations.

● Similarly logInterface which is responsible for logging information is also a good example for Pure

Fabrication.

Q.10) Explain indirection pattern with example ?

Ans: Indirection introduces an intermediate unit to communicate between the other units, so that the

other units are not directly coupled.

The indirection pattern supports low coupling and reuses potential between two elements by assigning

the responsibility of mediation between them to an intermediate object. An example of this is the

introduction of a controller component for mediation between data (model) and its representation (view)

in the model-view control pattern. This ensures that coupling between them remains low.

● Benefits: low coupling

● Example: Adapter, Facade, Obserever

Q.11) Explain protected variation GRASP pattern in details with example ?

Ans: The protected variations pattern protects elements from the variations on other elements (objects,

systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to

create various implementations of this interface.

For example, the prior external tax calculator problem and its solution with Polymorphism illustrate

Protected Variations. The point of instability or variation is the different interfaces or APIs of external tax

calculators. The POS system needs to be able to integrate with many existing tax calculator systems,

and also with future third - party calculators not yet in existence.

By adding a level of indirection, an interface, and using polymorphism with various TaxCalculator

Adapter implementations, protection within the system from variations in external APIs is achieved.
Internal objects collaborate with a stable interface; the various adapter implementations hide the

variations to the external systems.

Assignment No 9
Q6 what is context class?
context is defined as: Interface to global information about an application
environment. This is an abstract class whose implementation is provided by the Android
system.These properties represent information about the client, the environment, or
the circumstances of a request and generally are properties that might be inconvenient to
pass as parameters.
A Context object is created by first calling the ORB method get_default_context and then
calling the method create_child on the default context.

Q7 explain strategy design pattern

the strategy pattern (also known as the policy pattern) is a behavioral software design pattern
that enables selecting an algorithm at runtime. Instead of implementing a single algorithm
directly, code receives run-time instructions as to which in a family of algorithms to use.

Strategy lets the algorithm vary independently from clients that use it. Strategy is one of the
patterns included in the influential book Design Patterns by Gamma et al. that popularized
the concept of using design patterns to describe how to design flexible and reusable
object-oriented software. Deferring the decision about which algorithm to use until
runtime allows the calling code to be more flexible and reusable.

Q8 explain static design pattern.

The state pattern is a behavioral software design pattern that allows an object to alter its
behavior when its internal state changes. This pattern is close to the concept of finite-state
machines. The state pattern can be interpreted as a strategy pattern, which is able to switch a
strategy through invocations of methods defined in the pattern's interface.

The state pattern is used in computer programming to encapsulate varying behavior for the
same object, based on its internal state. This can be a cleaner way for an object to change its
behavior at runtime without resorting to conditional statements and thus improve
maintainability.

Q9 explain adaptor design pattern.

In software engineering, the adapter pattern is a software design pattern (also known as
wrapper, an alternative naming shared with the decorator pattern) that allows the interface
of an existing class to be used as another interface.[1] It is often used to make existing classes
work with others without modifying their source code.

An example is an adapter that converts the interface of a Document Object Model of an XML
document into a tree structure that can be displayed.

Q10 what is interface, explain difference between interface and abstract data.
In computing, an interface is a shared boundary across which two or more separate
 components of a computer system exchange information. The exchange can be between
software, computer hardware, peripheral devices, humans, and combinations of these.

Abstract class. Interface

1) Abstract class can have Interface can have only abstract methods.
abstract and non-abstract method.

2)Abstract class doesn't support Interface supports multiple

multiple inheritance. Inheritance.

3)Abstract class can provide Interface can't provide the

implementation of interface. implementation of abstract class.

4)An abstract class can be An interface can be implemented

extended using "extends". using keyword "implements".