Part A

Q:-1 Differentiate between the terms Generalization and

Specialization. Explain with an example the close
association between Generalization and Inheritance.

Ans.1 Generalization

Generalization uses a “is-a” relationship from a

specialization to the generalization class. Common structure
and behaviour are used from the specializtion to the
generalized class. At a very broader level you can
understand this as inheritance. Why I take the term
inheritance is, you can relate this term very well.
Generalization is also called a “Is-a” relationship
specialization
means creating new subclasses from an existing
class. If it turns out that certain attributes,
associations, or methods only apply to some of the
objects of the class, a subclass can be created. The
most inclusive class in a generalization/specialization
is called the superclass and is generally located at
the A n k u r S i n g h

top of the diagram. The more specific classes are called subclasses
and are generally placed below the superclass.

Q:-3 What is association? Differentiate between 1-way and

2-way association with example for each.

Ans.3 Association
Association is a relationship between two objects. In other
words, association defines the multiplicity between objects.
You may be aware of one-to-one, one-to-many, many-to-
one, many-to-many all these words define an association
between objects. Aggregation is a special form of
association. Composition is a special form of aggregation.In
a one-way association, the first class has a reference to an
object of the second class, but the second class does not
have a reference to an object of the first class. In a two-way
association, each class contains a reference to an object of
the other class.

UML indicates a one-way association with an arrow at the

end of the association line. The attribute in the first class that
contains a reference to an object of the second class is also
written at the end of the line. A class can contain more than
one association with another class.

Q:-4 Write a short note on Structural and Behavioural

diagrams. What are the constituent diagrams of these two
broad categories? Discuss in brief, any two constituent
diagrams of each type.

Ans. 4 Class diagram in the Unified Modeling Language

(UML) is a type of static structure diagram that describes the
structure of a system by showing the system's classes, their
attributes, and the relationships between the classes.

A class with three sections.

• The upper part holds the name of the class

• The middle part contains the attributes of the class
• The bottom part gives the methods or operations the
class can take or undertake
In the system design of a system, a number of classes are
identified and grouped together in a class diagram which
helps to determine the static relations between those
objects. With detailed modeling, the classes of the
conceptual design are often split into a number of
subclasses.

In order to further describe the behavior of systems, these

class diagrams can be complemented by state diagram or
UML state machine. Also instead of class diagrams Object
role modeling can be used if you just want to model the
classes and their relationships

object diagram is an instance of a class diagram. It implies

that an object diagram consists of instances of things used in
a class diagram.

So both diagrams are made of same basic elements but in

different form. In class diagram elements are in abstract form
to represent the blue print and in object diagram the
elements are in concrete form to represent the real world
object.

To capture a particular system, numbers of class diagrams

are limited. But if we consider object diagrams then we can
have unlimited number of instances which are unique in
nature. So only those instances are considered which are
having impact on the system.

it is clear that a single object diagram cannot capture all the

necessary instances or rather cannot specify all objects of a
system. So the solution is:

• First, analyze the system and decide which instances

are having important data and association.
• Second, consider only those instances which will cover
the functionality.
• Third, make some optimization as the numbers of
instances are unlimited.

Behaviour Diagram Types

• Sequence Diagram

– contains objects and messages

– objects on 'time lines'

– mixture of static and dynamic aspects of behaviour

• Collaboration Diagram

– contains objects and messages

– static aspects of behaviour

• Statechart Diagram

– models reaction to external stimuli

– states and transitions

– dynamic aspects of behaviour

• Activity Diagram

– models internal processing

– states and transitions

– dynamic aspects of behaviour

Q:-5 Write short notes on any four:

(i) DFD and its features

Data flow diagrams (DFDs) are categorized as

either logical or physical. A logical DFD focuses
on the business and how the business
operates. It describes the business events that
take place and the data required and produced
by each event. On the other hand, a physical
DFD shows how the system will be
implemented as we mentioned before. The
chart contrasts the features of logical and
physical models. Notice that thelogical model
reflects the business, while the physical model
depicts the system

(iv) 4+1 view of software architecture

4+1 Architectural View Model

• Logical view : The logical view is concerned with the

functionality that the system provides to end-users.
UML Diagrams used to represent the logical view
include Class diagram, Communication diagram,
Sequence diagram.

• Development view : The development view illustrates a

system from a programmer's perspective and is
concerned with software management. This view is also
known as the implementation view. It uses the UML
 Component diagram to describe system components.
UML Diagrams used to represent the development view
include the Package diagram.

• Process view : The process view deals with the

dynamic aspects of the system, explains the system
processes and how they communicate, and focuses on
the runtime behavior of the system. The process view
addresses concurrency, distribution, integrators,
performance, and scalability, etc. UML Diagrams to
represent process view include the Activity diagram.

• Physical view : The physical view depicts the system

from a system engineer's point-of-view. It is concerned
with the topology of software components on the
physical layer, as well as the physical connections
between these components. This view is also known as
the deployment view. UML Diagrams used to represent
physical view include the Deployment diagram.

• Scenarios : The description of an architecture is

illustrated using a small set of use cases, or scenarios
which become a fifth view. The scenarios describe
sequences of interactions between objects, and
between processes. They are used to identify
architectural elements and to illustrate and validate the
architecture design. They also serve as a starting point
for tests of an architecture prototype. UML Diagram(s)
used to represent the scenario view include the Use
case diagram

(v) Mapping object classes and association to tables

Part B
Q:-5 Write short notes on any four:
(i) DFD and its features
Data flow diagrams illustrate how data is processed
by a system in terms of inputs and outputs.
FEATURES OF DATA FLOW DIAGRAM
1. All processes must have at least one data flow in
and one data flow out.
2. All processes should modify the incoming data,
producing new forms of outgoing data.
3. Each data store must be involved with at least one
data flow.
4. Each external entity must be involved with at least
one data flow.
5. A data flow must be attached to at least one
process.

(ii) Multiple Inheritance

Multiple Inheritance occurs when a class inherits

from more than one parent. For example, a person is
a mammal and an intellectual entity, and a
document may be an editable item and a kind of
literature.
Q:-7 How do we implement the concept of association in C+
+/Java?
Ans.7 A class is a template for an object, a user-defined
datatype that contains variables, properties of an object. A
class defines abstract characteristics of a thing (object),
including its characteristics (its attributes, fields or
properties) and the things it can do (behaviors, methods,
operations or features). One might say that a class is a
blueprint or factory that describes the nature of something.
For example, the class Dog would consist of traits shared by
all dogs, such as breed and fur color (characteristics), and
the ability to bark and sit (behaviors). Classes provide
modularity and structure in an object-oriented computer
program. A class should typically be recognizable to a non-
programmer familiar with the problem domain, meaning that
the characteristics of the class should make sense in
context. Also, the code for a class should be relatively self-
contained (generally using encapsulation). Collectively, the
properties and methods defined by a class are called
members.

Instance

One can have an instance of a class; the instance is the

actual object created at run-time. In programmer vernacular,
the Lassie object is an instance of the Dog class. The set of
values of the attributes of a particular object is called its
state. The object consists of state and the behavior that's
defined in the object's classes.

Method

A method is a set of procedural statements for achieving the

desired result. It performs different kinds of operations on
different data types. In a programming language, methods
(sometimes referred to as "functions") are verbs. Lassie,
being a Dog, has the ability to bark. So bark() is one of
Lassie's methods. She may have other methods as well, for
example sit() or eat() or walk() or save(Timmy). Within the
program, using a method usually affects only one particular
object; all Dogs can bark, but you need only one particular
dog to do the barking.

Message passing

"The process by which an object sends data to another

object or asks the other object to invoke a method." Also
known to some programming languages as interfacing. For
example, the object called Breeder may tell the Lassie object
to sit by passing a "sit" message that invokes Lassie's "sit"
method. The syntax varies between languages, for example:
[Lassie sit] in Objective-C. In Java, code-level message
passing corresponds to "method calling". Some dynamic
languages use double-dispatch or multi-dispatch to find and
pass messages.

Abstraction

Abstraction refers to the act of representing essential

features without including the background details or
explanations. Classes use the concept of abstraction and
are defined as a list of abstract attributes.
Abstraction is a mechanism where we hide the
implementation or another way of looking, we want to
achieve loose coupling.

Encapsulation

Encapsulation conceals the functional details of a class from

objects that send messages to it.
For example, the Dog class has a bark() method variable,
data. The code for the bark() method defines exactly how a
bark happens (e.g., by inhale() and then exhale(), at a
particular pitch and volume). Timmy, Lassie's friend,
however, does not need to know exactly how she barks.
Encapsulation is achieved by specifying which classes may
use the members of an object. The result is that each object
exposes to any class a certain interface — those members
accessible to that class. The reason for encapsulation is to
prevent clients of an interface from depending on those parts
of the implementation that are likely to change in the future,
thereby allowing those changes to be made more easily, that
is, without changes to clients. For example, an interface can
ensure that puppies can only be added to an object of the
class Dog by code in that class. Members are often specified
as public, protected or private, determining whether they
are available to all classes, sub-classes or only the defining
class. Some languages go further: Java uses the default
access modifier to restrict access also to classes in the
same package, C# and VB.NET reserve some members to
classes in the same assembly using keywords internal (C#)
or Friend (VB.NET). Eiffel and C++ allow one to specify
which classes may access any member. by abhishek
chaudhary kangra himachal pradesh phone---9816067063

Inheritance

Inheritance allows the programmer to treat derived class

members just like their parent class's members. This type of
relationship is called child-Parent or is-a relationship.
"Subclasses" are more specialized versions of a class, which
inherit attributes and behaviors from their parent classes,
and can introduce their own.
For example, the class Dog might have sub-classes called
Collie, Chihuahua, and GoldenRetriever. In this case, Lassie
would be an instance of the Collie subclass. Suppose the
Dog class defines a method called bark() and a property
called furColor. Each of its sub-classes (Collie, Chihuahua,
and GoldenRetriever) will inherit these members, meaning
that the programmer only needs to write the code for them
once.

Each subclass can alter its inherited traits. For example, the
Collie subclass might specify that the default furColor for a
collie is brown-and-white. The Chihuahua subclass might
specify that the bark() method produces a high pitch by
default. Subclasses can also add new members. The
Chihuahua subclass could add a method called tremble().
So an individual chihuahua instance would use a high-
pitched bark() from the Chihuahua subclass, which in turn
inherited the usual bark() from Dog. The chihuahua object
would also have the tremble() method, but Lassie would not,
because she is a Collie, not a Chihuahua. In fact, inheritance
is an "a… is a" relationship between classes, while
instantiation is an "is a" relationship between an object and a
class: a Collie is a Dog ("a… is a"), but Lassie is a Collie ("is
a"). Thus, the object named Lassie has the methods from
both classes Collie and Dog.

Q:-8 How do you show instantiation in a UML Sequence

Diagram?

Ans.8 Sequence diagrams are used to model the logic of

usage scenarios. A usage scenario is exactly what its name
indicates -- the description of a potential way your system is
used. The logic of a usage scenario may be part of a use
case, perhaps an alternate course. It may also be one entire
pass through a use case, such as the logic described by the
basic course of action or a portion of the basic course of
action, plus one or more alternate scenarios. The logic of a
usage scenario may also be a pass through the logic
contained in several use cases