Ooad Assignment SS

8/10/2019 Ooad Assignment SS

1/12

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.


2/12

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.


3/12

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:


4/12

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


5/12

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.


6/12

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.


7/12

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


8/12

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.


9/12

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.


10/12

Data Flow Diagram-


11/12

Object Diagram-


12/12

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.

Ooad Assignment SS

Documents