Assignment No.

- 05
Q.1. (a) Describe the generic phases of software development. How does RUP
define these phases?
Ans. Generic Phases of Software Development - There are a number of phases common to
every development, regardless of methodology, starting with requirements capture and ending
with maintenance. With the traditional approach, youre expected to move forward gracefully
from one phase to the other. With the modern approach, on the other hand, youre allowed to
perform each phase more than once and in any order.
1. Requirements - Requirements capture is about discovering what were going to achieve with
our new piece of software and has two aspects. Business modeling involves understanding the
context in which our software will operate if we dont understand the context, we have little
chance of producing something to enhance that context. The sort of question we ask during the
business modeling phase is How does a customer purchase a television from this shop? System
requirements modeling (or functional specification) mean deciding what capabilities the new
software will have and writing down those capabilities. We need to be clear about what our
software will do and what it wont do, so that the development doesnt veer off into irrelevant
areas and we know both when weve finished and whether weve been successful. The sort of
question we ask during the system requirements modeling phase is How do we update the
inventory system when a television has been purchased?
2. Analysis - Analysis means understanding what were dealing with. Before we can design a
solution, we need to be clear about the relevant entities, their properties and their
inter-relationships. We also need to be able to verify our understanding. This can involve
customers and end users, since theyre likely to be subject-matter experts. What products do we
sell in this shop? Where do they come from? How much do they cost?
3. Design - In the design phase, we work out how to solve the problem. In other words, we make
decisions, based on experience, estimation and intuition, about what software we will write and
how we will deploy it. System design breaks the system down into logical subsystems
(processes) and physical subsystems (computers and networks), decides how machines will
communicate, and chooses the right technologies for the job, and so on. The sort of decision we
make during the system design phase is Were going to use an intranet and the Java Messaging
Service for communicating sales results to head office. In subsystem design we decide how to
cut each logical subsystem into effective, efficient and feasible code. The sort of decision we
make during the subsystem design phase is Line items in an inventory are implemented as a
hash table, keyed by part number.

4. Specification - Specification is an often-ignored, or at least often-neglected, phase. The term

specification is used in different ways by different developers. For example, the output of the
requirements phase is a specification of what the system must be able to do; the output of
analysis is a specification of what were dealing with; and so on. In this book, the term is used to
mean describing the expected behavior of our programming components. (Since the
specification techniques described are performed on classes of objects, some of the confusion
can be avoided by using the term class specification.) A class specification is a clear,
unambiguous description of the way the components of our software should be used and how
they will behave if used properly. The sort of statement we make during the specification phase
is If the shop assistant object is logged on, it can ask the store object for todays special offers;
in return, it receives a list of products, sorted in alphabetical order.
This book gives special attention to specification, because of the crucial underlying principle of
Design by Contract. The idea behind a contract is that whenever one piece of software calls upon
the services of another, both the caller and the called have obligations to fulfill. Bearing software
contracts in mind is useful at all stages of development.
Specification can be used in the following ways:
As a basis for designing test software to exercise the system.
To demonstrate that our software is correct (this is desirable for life-critical applications).
To document our software components to the extent that they could be implemented by third
parties.
To describe how our code can be reused safely by other applications.
5. Implementation - This is where we do the donkey work, writing pieces of code that work
together to form subsystems, which in turn collaborate to form the whole system. The sort of task
we carry out during the implementation phase is Write the method bodies for the Inventory
class, in such a way that they conform to their specification. Although we would expect most of
the difficult coding decisions to have been made before we reach this phase (during design),
there is still plenty of scope for creativity: although the public interfaces of our software
components will have been well designed, specified and documented, programmers have free
rein to decide on the inner workings. As long as the end result is effective and correct, everyone
will be happy.
6. Testing - When our software is complete, it must be tested against the system requirements to
see if it fits the original goals. The sort of question we ask during the testing phase is Can a shop
assistant use the till interface to sell a toaster, decreasing the products inventory as a
side-effect? As well as this kind of conformance testing, its a good idea to see if our software
can be broken via its external interfaces this helps to protect us against accidental or malicious
abuse of the system when its been deployed.

It is a good idea for programmers to perform small tests as they go along, to improve the
quality of the code that they deliver. Generally speaking, however, major tests should not be
designed, implemented or carried out by the developers who wrote the software.
To understand why, consider buying a new house and spending vast amounts of time and
money refurbishing it from top to bottom. Its unlikely that you would want to whack the
structures and fixtures with a sledgehammer to see if theyre durable, ask passing strangers
whether they think that you have good taste or pretend to be a burglar to see if you can break in.
These are exactly the kinds of things that we need to be doing during software testing. (It helps if
members of the test team have a cruel streak.)
7. Deployment - In the deployment phase, were concerned with getting the hardware and
software to the end users, along with manuals and training materials. This may be a complex
process, involving a gradual, planned transition from the old way of working to the new. The sort
of task we carry out during the deployment phase is Run the program setup.exe on each server
machine and follow the instructions that appear.
8. Maintenance -When our system is deployed, it has only just been born. A long life stretches
before it, during which it has to stand up to everyday use this is where the real testing happens.
The sort of problem we discover during the maintenance phase is When the log-on window
opens, it still contains the last password entered. As software developers, were normally
interested in maintenance because of the faults (bugs) that are found in our software. We must
find the faults and remove them as quickly as possible, rolling out fixed versions of the software
to keep the end users happy. As well as faults, our users may discover deficiencies (things that
the system should do but doesnt) and extra requirements (things that would improve the
system). From the business point of view, we would hope to fix and improve our software over
time to maintain competitive advantage.
How RUP define those phases The Rational Unified Process has four phases:

1. Inception phase of the UP encompasses both customer communication and planning

activities. By collaborating with stakeholders, business requirements for the software are
identified; a rough architecture for the system is proposed; and a plan for the iterative,
incremental nature of the ensuing project is developed. Fundamental business requirements are
described through a set of preliminary use cases that describe which features and functions each
major class of users desires. Architecture at this point is nothing more than a tentative outline of
major subsystems and the function and features that populate them. Later, the architecture will be
refined and expanded into a set of models that will represent different views of the system.
Planning identifies resources, assesses major risks, defines a schedule, and establishes a basis for
the phases that are to be applied as the software increment is developed.
2. Elaboration phase encompasses the communication and modeling activities of the generic
process model. Elaboration refines and expands the preliminary use cases that were developed as
part of the inception phase and expands the architectural representation to include five different
views of the softwarethe use case model, the requirements model, the design model, the
implementation model, and the deployment model. In some cases, elaboration creates an
executable architectural baseline that represents a first cut executable system.The
architectural baseline demonstrates the viability of the architecture but does not provide all
features and functions required to use the system. In addition, the plan is carefully reviewed at
the culmination of the elaboration phase to ensure that scope, risks, and delivery dates remain
reasonable. Modifications to the plan are often made at this time.
3. Construction phase of the UP is identical to the construction activity defined for the generic
software process. Using the architectural model as input, the construction phase develops or
acquires the software components that will make each use case operational for end users. To
accomplish this, requirements and design models that were started during the elaboration phase
are completed to reflect the final version of the software increment. All necessary and required
features and functions for the software increment (i.e., the release) are then implemented in

source code. As components are being implemented, unit tests21 are designed and executed for
each. In addition, integration activities (component assembly and integration testing) are
conducted. Use cases are used to derive a suite of acceptance tests that are executed prior to the
initiation of the next UP phase.
4. Transition phase of the UP encompasses the latter stages of the generic construction activity
and the first part of the generic deployment (delivery and feedback) activity. Software is given to
end users for beta testing and user feedback reports both defects and necessary changes. In
addition, the software team creates the necessary support information (e.g., user manuals,
troubleshooting guides, installation procedures) that is required for the release. At the conclusion
of the transition phase, the software increment becomes a usable software release.

Q.1. (b) Describe relationships among objects and compare their types with suitable
example.
Ans. When were modeling with objects, we can connect them in
Association
Aggregation
Composition
Dependency
Generalization
Realization
1. Association is a weak form of connection: the objects may be part of a group, or family, of
objects but theyre not completely dependent on each other. For example, consider a car, a
driver, a passenger and another passenger. When the driver and the two passengers are in the car,
theyre associated: they all go in the same direction; they occupy the same volume in space, and
so on. But the association is loose: the driver can drop off one of the passengers to go their
separate way, so that the passenger is no longer associated with the other objects. Figure shows
how we can draw an association on an object diagram the attributes and operations have been
omitted here in order to emphasize the structure.

2. Aggregation means putting objects together to make a bigger object. Manufactured items
usually form aggregations: for example, a microwave is made up of a cabinet, a door, an
indicator panel, buttons, a motor, a glass plate, a magnetron, and so on. Aggregations usually
form a partwhole hierarchy. Aggregation implies close dependency, at least of the whole to the
part; for example, a magnetron is still a magnetron if you take it out of its microwave, but the
microwave would be useless without the magnetron, because it wouldnt be able to cook
anything.
Figure shows how we can draw a house as an aggregation: in order to emphasize
the difference between this kind of connection and an association, we place a white diamond on
the whole end.

3. Composition A form of aggregation with strong ownership and coincident lifetimes. The parts
cannot survive the whole/aggregate.

4. Dependency - A relationship between two model elements where a change in one may cause a
change in the other

Non-structural, using relationship

5. Generalization - A relationship among classes where one class shares the structure and/or
behavior of one or more classes
Defines a hierarchy of abstractions in which a subclass inherits from one or more
superclasses - Single inheritance, Multiple inheritance .Generalization is an is-a-kind of
relationship . Single Inheritance One class inherits from another

Multiple Inheritance A class can inherit from several other classes

6. Realization - One classifier serves as the contract that the other classifier agrees to
carry out. Found between:

Interfaces and the classifiers that realize them

Use cases and the collaborations that realize them

Q.1. (c) Justify the statements:

I.

By abstraction, we create a clear separation of concerns among the

logically different parts of system.

II.

Encapsulation is most commonly achieved through information

hiding.

Ans.

Q.2. (c) Draw Object,State and Data flow diagram for Airline Reservation
System.
Ans.
Problem Statement- Airline Reservations Systems contain airline schedules, fare tariffs,
passenger reservations and ticket records. An airline's direct distribution works within their own
reservation system, as well as pushing out information to the Global Distribution System (GDS).
A second type of direct distribution channel is consumers who use the internet or mobile
applications to make their own reservations. Travel agencies and other indirect distribution
channels access the same GDS as those accessed by the airlines' reservation systems, and all
messaging is transmitted by a standardized messaging system that functions primarily on TTY
messaging called SITA. The Airline Reservations System (ARS) was one of the earliest changes
to improve efficiency. ARS eventually evolved into the Computer Reservations System (CRS).
A Computer Reservation System is used for the reservations of a particular airline and interfaces
with a Global Distribution System (GDS) which supports travel agencies and other distribution
channels in making reservations for most major airlines in a single system.

Data Flow Diagram-

Object Diagram-

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. This view is also known as use case view.