Assignment No.

– 1
Ques:1 Differentiate aggregation and generalization with an example.
Ans:1 Difference Between Aggregation and Generalization in UML
Definition: -
a) Aggregation: - is an association between two objects which describes the “has a” relationship
while generalization is a mechanism for combining similar classes of objects into a single
general class. Thus, this explains the main difference between aggregation and generalization in
UML.
b) Relationship: - Aggregation denotes “has a” relationship while Generalization denotes “is a”
relationship.
c) UML representation: - A diamond symbol represents an aggregation whereas an arrow
symbol represents generalization. Hence, this further explains the difference between
aggregation and generalization in UML.
d) Example
 Aggregation Example: -

The employee and address are linked with the “has a” relationship. An instance of the Address
class can exist without an instance of the Employee. It is an aggregation. In UML, the diamond
symbol represents an aggregation. The direction denotes which object contains the other
object.

 Generalization Example: -

Employee is the superclass. Permanent and Temporary Employee are subclasses whereas
Employee is the generalized form of Permanent and Temporary Employee. On the other hand,
Permanent and Temporary Employee are specialized forms of Employee. Employee has
properties id, name, salary and the method display. The subclasses Permanent and Temporary
Employee can also use these properties and methods. Furthermore, the subclasses have their
own properties and methods.  In UML, an arrow represents generalization.
Ques:2 Explain is one-way association and two-way association.
Ans:2 a) One-Way Association
• We can navigate along a single direction only.
• Denoted by an arrow towards the server object.
• Example – Association
• A one-way association indicates the direction in which one can navigate from an object
of one class to an object of another class.
• 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.
• Example: -

b) Two-Way Association
• We can navigate in both directions
• Denoted by a line between the associated objects
• Example – Two-way Association
• A two-way association indicates bi-directional navigation between objects of two
classes.
• Each class contains a reference to an object of the other class.
• Example: -

Ques:3 Explain process, data flows, actors and data stores.

Ans:3 a). Process – An activity that changes or transforms data flows. Since they transform
incoming data to outgoing data, all processes must have inputs and outputs on a DFD. This
symbol is given a simple name based on its function. In Gane-Sarson notation, a rectangular box
is used, and a short title that describes its function. Processes are typically oriented from top to
bottom and left to right on a data flow diagram.

b). Data Store – A data store does not generate any operations but simply holds data for later
access. Data stores could consist of files held long term or a batch of documents stored briefly
while they wait to be processed. Input flows to a data store include information or operations
that change the stored data. Output flows would be data retrieved from the store.

c). Data Flow – Movement of data between external entities, processes and data stores is
represented with an arrow symbol, which indicates the direction of flow. This data could be
electronic, written or verbal. Input and output data flows are labeled based on the type of data
or its associated process or data store, and this name is written alongside the arrow.

d). Actor - Actors can be people, other systems, time triggers, or event triggers. An actor
specifies a role played by a user or any other system that interacts with the subject. It may
represent roles played by human users, external hardware, or other subjects. Actors are always
outside the system and interact directly with it by initiating a use case, provide input to it,
and/or receive outputs from it. While a single physical instance may play the role of several
different actors, an actor does not necessarily represent specific physical entities, i.e. a timer
that triggers sending of an e-mail reminder.

Figure: Actor

Ques:4 List and compare software life cycle model that supports object oriented
software development.
Ans:4 Software Development Life cycle: -
The essence of the software development process that consists of analysis, design,
implementation, testing, and refinement is to transform user’s needs into a software to
transform user’s needs into a software solution that satisfies those needs. Some people view
software development process as interesting but feel it has little importance in developing
software. In general, dynamics of software development provides little room for such shortcuts,
and bypasses have been less than successful. The object-oriented approach requires a more
rigorous process to do things right, more rigorous process to do things right. You need not see
code until after about 25 percent of the development time, because you need to spend more
time in gathering requirements, developing a requirement model and an analysis model, then
turning them into the design model.
 The software development process can be divided into smaller, interacting sub processes.
Generally, software development can be. Generally, software development can be seen as a
series of transformations, where the output of one transformation becomes the input of the
subsequent transformation.
Transformation1(Analysis):
◦ Translates the user’s needs into system requirements and responsibilities.
◦ The way they use the system can provide insight into the user’s requirements. Insight into the
user’s requirements.
◦ For example: one use of system might be analyzing an incentive payroll system, which will tell
us that this capacity will be included in the system requirements.

Transformation 2 (design):
◦ Begins with a problem statement and ends with a detailed design that can be transformed
into an operational system.
◦ This transformation includes the bulk of the software development activity, including the
definition of how to build the software, its development, and its testing.
◦ It also includes design descriptions, the programs and the testing material.

Transformation 3(Implementation)
◦ refines the detailed design into the system deployment that will satisfy the user’s needs.
◦ This takes into account equipment, procedures, people, and the like. Procedures, people, and
the like.
◦ It represents embedding the software product within its operational environment. 

Waterfall Model An example of the software development process is the waterfall approach
which starts with deciding what has to be done. Once the requirements have been determined,
we next must decide how to accomplish them. This is followed by a step in which we do it,
whatever it has required us to do. We then must test the result to see if we have satisfied the
user’s requirements. Finally, we use the what we have done.

Object-Oriented Life cycle Model: -

The Object-Oriented approach of Building Systems takes the objects as the basis. For this, first
the system to be developed is observed and analyzed and the requirements are defined as in
any other method of system development. Once this is often done, the objects in the required
system are identified. For example, in the case of a Banking System, a customer is an object, a
cheque-book is an object, and even an account is an object.
Object-oriented model employs an object-oriented strategy. The primary objectives are:
1. Object-oriented analysis,
2. Object-oriented design,
3. Object-oriented programming

Object-oriented analysis develops an object-oriented model of the application domain. Object-

oriented design develops an object-oriented model of the software system. Object oriented
programming realizes the software design with an object-oriented programming language that
supports direct implementation of objects, classes, and inheritance.
There are a variety of object-oriented methodologies such as:
 Object Identification:
System objects and their characteristics and events.
 Object Organization:
Shows how objects are related via “part-of” relationships.
 Object Interfaces:
Shows how objects interact with other objects.

These activities tend to be overlapping and in general and parallel.

The requirements analysis stage strives to achieve an understanding of the client’s application
domain. The task that a software solution must address emerge in the course of requirement
analysis. The requirement analysis phase remains completely independent of an
implementation technique that might be applied later.
In the system specification section, the wants definition describes what the software product
must do, but not how this goal is to be achieved.
One point of divergence from conventional phase model arises because implementation with
object-oriented programming is marked by the assembly of already existing components. The
class library serves as a tool that extends beyond the scope of an individual project because
class provided by one project can increase productivity in subsequent projects.

Ques:5 What is requirement validation? Specify some of the requirement

validations.
Ans:5 Requirements Validation: - It’s a process of ensuring the specified requirements meet
the customer needs. It’s concerned with finding problems with the requirements. These
problems can lead to extensive rework costs when these they are discovered in the later stages,
or after the system is in service.
The cost of fixing a requirements problem by making a system change is usually much greater
than repairing design or code errors. Because a change to the requirements usually means the
design and implementation must also be changed, and re-tested.

During the requirements validation process, different types of checks should be carried out
on the requirements. These checks include:
a). Validity checks: The functions proposed by stakeholders should be aligned with what the
system needs to perform. You may find later that there are additional or different functions are
required instead.
b). Consistency checks: Requirements in the document shouldn’t conflict or different
description of the same function.
c). Completeness checks: The document should include all the requirements and constrains.
d). Realism checks: Ensure the requirements can actually be implemented using the knowledge
of existing technology, the budget, schedule, etc.
e). Verifiability: Requirements should be written so that they can be tested. This means you
should be able to write a set of tests that demonstrate that the system meets the specified
requirements.

There are some techniques you can use to validate the requirements, and you may use one or
more of them together, depending on your needs.
a). Requirements Reviews
A team of system customer; those who interact with the customer to gather requirements, and
system developers start reading the requirements in the document, and investigate in a great
detail to check for errors, inconsistency, conflicts, and any ambiguity. Then they may negotiate
with the customer on how to solve the problems and errors found.

b). Prototyping
Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of
the system to validate the requirements. If it fails, we then refine it, and check again, until it
meets the customer needs. This definitely will decrease the cost as a result of having a clear,
understandable, consistent requirements.

c). Test-case Generation

The requirements need to be testable. If the tests for the requirements are added as part of the
validation process, this often reveals requirements problems. If a test is difficult or impossible
to design, this usually means that the requirements will be difficult to implement and should be
reconsidered.