AIRLINE RESERVATION AND TICKET BOOKING SYSTEM PROJECT REPORT

AIRLINE RESERVATION AND TICKET BOOKING SYSTEM PROJECT REPORT

PROJECT REPORT

AIRLINE TICKET BOOKING SYSTEM PROJECT REPORT

PROJECT SOURCE CODE

AIRLINE TICKET BOOKING SYSTEM PROJECT SOURCE CODE IN ASP.NET

AIRLINE RESERVATION SYSTEM PROJECT SOURCE CODE

FREE DOWNLOAD ALL THE PROJECT REPORTS WITH SOURCE CODE FROM HERE



The web based “airline reservation system” project is an attempt to stimulate the basic concepts of airline reservation system. The system enables the customer to do the things such as search for airline flights for two travel cities on a specified date, choose a flight based on the details, reservation of flight and cancellation of reservation.

The system allows the airline passenger to search for flights that are available between the two travel cities, namely the “Departure city” and “Arrival city” for a particular departure and arrival dates. The system displays all the flight’s details such as flight no, name, price and duration of journey etc.

After search the system display list of available flights and allows customer to choose a particular flight. Then the system checks for the availability of seats on the flight. If the seats are available then the system allows the passenger to book a seat. Otherwise it asks the user to choose another flight.

To book a flight the system asks the customer to enter his details such as name, address, city, state, credit card number and contact number. Then it checks the validity of card and book the flight and update the airline database and user database. The system also allows the customer to cancel his/her reservation, if any problem occurs.

 

ANALYSIS

2.REQUIREMENTS ELICITATION: 

Reqirement number	Description	Type	Priority
Req-1	The user will be able to search for flights through a standard screen.	Functional	Must have
Req-2	Database administrator maintains the user details and the flights details in the database.	Non functional	Must have
Req-3	Through a standard flight search method  the user will be able to search one-way,round trip or multi destination flights.	Functional	Must have
Req-4	The user should able to specify the departure,arrival places and date of their flight.	Functional	Must have
Req-5	By advanced flight search method the user will allow the user to specify a preffered airline by its name or its number.	Functional	Could have
Req-6	The user will have the option to select the either non-stop,single stop or multi-stop flights.	Functional	Must have
Req-7	The user can only search for a flight in the future and with in only one year of current date.	Functional	Must have
Req-8	Any error in entry of the system will stop the system fro processing the search. an error message will be presented to the user.	Functional	Must have
Req-9	The user will be able to see the price,duration of trvelling,departure time and arrival time.	Functional	Must have
Req-10	User will able to specify the  flight class which will be with respect to the flight choosen.	Functional	Could have
Req-11	The user will be able to choose the seats from the list of available seats of particular flights.	Functiuonal	Must have
Req-12	The user must complete all the necessary steps to book flight to be gaurenteed and autherentised.	Functional	Must have
Req-13	After booking the flight the user may cancel or modifing their flight.	Functional	Must have
Req-14	Response time of the airline reservation system must be less than 5 sec most of time.	Non functional	Shall have
Req-15	Ars shall be able to handle atleast 1000 transactions  per second.	Non functional	Shall have
Req-16	Ars should  be available 24x7.	Non functional	Must have
Req-17	Ars shall always provide real time information about flight availability information.	Non functional	Must have
Req-18	The web interface should be interactive and easily navigable users  sholud be able to understand the menu and options provided by ars.	Nonfunctional	Must have
Req-19	Users need to authenticated before having access to any personal data	Non functional	Must have
Req-20	Ars shall authenticate the  users credit cards and their personal information.	Functional	Must have
Req-21	Support for waiting list functionality.	Functional	Shall have
Req-22	The ars shall be able to handle the situation where flight services are available to multiple cities or a single city.	Functional	Could have
Req-23	Only the system abministrator hat the right to change the system parameters.	Non-functional	Shall have
Req-24	Ars should be roboust enough to have a high degree fauklt tolerance.	Non-functional	Shall have

3.  System Requirements Specification   

HARDWARE:

 PROCESSOR      : PENTUIUM IV 2.6 GHz

RAM                     : 512MB DD RAM

MONITOR           : 15” COLOR

HARD DISK        :250 GB

CDDRIVE                        : LG52X

KEYBOARD       : STANDARD 102 KEYS

MOUSE                :OPTICAL MOUSE

SOFTWARE:

FORNT END                   :JAVA,HTML,SERVLETS

BACKEND                      : ORACLE 10i

OPERATING SYSTEM  : WINDOWS XP

                                        Use-case view

4. IDENTIFICATION OF ACTORS

Actors are not part of system.

Actors represent anyone or anything that interacts with (input to receive output from) the system.

An actor is someone or something that:

Ø  Interacts with or uses the system.

Ø  Provides input tot and receives information from the system.

Ø  Is external to the system and has no control over the use cases.

Actors are discovered by examining:

Ø  Who directly uses the system?

Ø  Who is responsible for maintaining the system?

Ø  External hardware used by the system.

Ø  Other systems that need to interact with the system.

The need of the actor are used to develop use cases. This insures that the system will be what the user expected.

Graphical Depiction

An actor is a stereotype of a class and is depicted as “stickman” on a use-case diagram. 

Naming:

The name of the actor is displayed below the icon.

Questions that help to identify actors

1. Who is interested in a certain requirement
2. Where is the system used within the organization?
3. Who will benefit from the use of the system?
4. Who will supply the system with information, use this information, and remove this information?
5. Who will support and maintain the system?
6. Does the system use an external resource?
7. Does one person play several different roles?
8. Do several people play the same role?
9. Does the system interact with a legacy system?

Using the above questions we have identified four actors is online airline reservation system. They are

1)      Traveler

2)      Credit and authorization

3)      Airline database

4)      User database

Customer: Initially Customer searches the fights available in the web page by submitting departure city and arrival city. After he chooses a flight from a light of available flights. After choosing he has to submit his details for booking and confirm the booking. He can also have the ability to cancel the flight if any problem occurs.

UML notion:

2) Database Administrator: It is responsible for maintaining all the rights details such as flight number, company, price duration of journey. The request come to any airline database is queried and executed. The query may be either executable or update query. It is invoked by the booking system whenever the traveler confirms the booking. It maintains the customer details such as name, address, city, state and contact number. Whenever the customer cancels the booking his details will be removed from the database.

UML notation

5. IDENTIFICATION OF USE-CASES AND SUB USE-CASES

Use case is a sequence of transactions performed by a system that yields a measurable result of values for a particular actor. The use cases are all the ways the system may be used.

Graphical Depiction:

            The base shape of a use case is an ellipse:

Naming

Ø  A use case may have a name, although it is typically not a simple name. It is often written as an informal text description of the actors and the sequences of events between objects. Use case names often start with a verb.

Ø  The name of the use case is displayed below the icon.

Questions that help to find use cases

1. What are the tasks of each actor?
2. Will any actor create, store, change, remove or read information in the system?
3. What use cases will create, store, change, remove, or read this information?
4. Will any actor need to inform the system about sudden, external changes?
5. Does any actor need to be informed about certain occurrences in the system?
6. What use cases will support or maintain the system?
7. Can all functional requirements be performed by the use cases?

By applying the above questions to the online shopping the following use cases are identified. They are

1)      Search Flight

This use case is started by traveler.  It provides the facility for traveler to search for flight based on departure and arrival city.

UML notation:

2) Select Flight

After searching from the list of available flights the choose flight enables the traveler to choose a flight. Then it checks the availability of seats on that flight. If the scats are available then it allows the traveler to book a seat, otherwise it asks the traveler to choose another flight. UML notation:

3) Book Flight

After choosing a flight, the traveler books the flight by using book flight system. To book a seat the traveler first enters his details. The system then checks the credit card and books the ticket and sends confirmation to user.

UML notation:

4) Cancel Flight

This use case is utilized by traveler. It enables the traveler to cancel his/her reservation if any problem occurs.

UML notation:

6. BUILDING REQUIREMNTS MODEL THROUGH USE-CASE DIAGRAM

USE-CASE DIAGRAM

Definition: A Use-case diagram graphically represents system behavior (use cases). These diagrams present a high level view of how the system is used as viewed from an outsider’s (actor’s) perspective. A use-case diagram may contain all or some of the use cases of a system.

Association Relationship:

An association provides a pathway for communication. The communication can be between use cases, actors, classes or interfaces. Associations are the most general of all relationships and consequentially the most semantically weak. If two objects are usually considered independently, the relationship is an association. Associations are of two types

1)      Uni-directional association.

2)      Bi-directional association.

Graphical Depiction

An association relationship is an orthogonal or straight solid line with an arrow at one end:

In An Association Relationship, we can provide Stereotype COMMUNICATE also as shown below

Dependency Relationship:

A dependency is a relationship between two model elements in which a change to one model element will affect the other model element. Use a dependency relationship to connect model elements with the same level of meaning. Typically, on class diagrams, a dependency relationship indicates that the operations of the client invoke operations of the supplier.

We can provide here

1.  Include Relationship.

2.  Extend Relationship

1. Include Relationship

Multiple use cases may share pieces of the same functionality. This functionality is placed in a separate use case rather than documenting it in every use case that needs it

Include relationships are created between the new use case and any other use case that “uses” its functionality.

An include relationship is a stereotyped relationship that connects a base use case to an inclusion use case. An include relationship specifies how behavior in the inclusion use case is used by the base use case.

           

2. Extend Relationship

An extend relationship is a stereotyped relationship that specifies how the functionality of one use case can be inserted into the functionality of another use case. Extend relationships between use cases are modeled as dependencies by using the Extend stereotype. An extend relationship is used to show

Ø  Optional behavior

Ø  Behavior that is run only under certain conditions such as triggering an alarm

Ø  Several different flows that may be run based on actor selection

Ø  An extend relationship is drawn as a dependency relationship that points from the extension to the base use case

The extend relationship sample demonstrates how you can use an extend relationship to connect use cases. The sample illustrates two important aspects of extend relationships:

Ø  An extend relationship shows optional functionality or system behavior.

Ø  A base use case does not need to acknowledge any specific extended use cases The sample below shows a diagram containing an actor interacting with a web site. The Customer has the option of buying merchandise online as shown through the extend relationship.

Finally we can conclude

Ø  Extend is used when you wish to show that a use case provides additional functionality that may be required in another use case.

Ø  Include applies when there is a sequence of behavior that is used frequently in a number of use cases, and you want to avoid copying the same description of it into each use case in which it is used.

 7. FLOW OF EVENTS:

Use case specifications for login system:

 1.Use case name: Login system

2. Flow of events:

   2.1 Basic flow :

      The customer enters the valid login details in login system. If it is not valid 2.2.1 alternate flow is executed.

2.2 Alternate flow:

   2.2.1 Iinvalid user name

    The customer enters the invalid values.

3. Special requirements:

   User can enter as a guest.

4.Pre conditions:

 There are no preconditions.

5.Post conditions:

 There are no post conditions.

6.Extension points:

 There are no extension points.

Use case specification for search flight:

1.Use case name: Search Flight.

    This use case is started traveler. It provides the facility to search the flights available.

2.Flow of events:

 2.1 Basic flow:

   This use case is started when the traveler enter the details such as departure city and arrival city. If the names are invalid alternate flow 2.2.1 is executed. The system then checks for the list of flights available and print them.if the flight is not available alternate flow 2.2.2 is executed.

2.2 Alternate flow:

 2.2.1 If the traveler enters the city with errors such as “arrival date” is preceed departure date or entering the dates are already completed or the cities are invalid then the system informs the traveler that returns the details.

2.2.2  If the flight is not available between the two cities that the user enters then the system display the message that “there is no flight service directly between two cities.

3.Special requirements:

 There are no special requirements.

4.Pre conditions;

 There are no pre conditions.

5. Post conditions:

 There are no post conditions.

6. Extension points:

 There are no extension points.

Use case specifications for the selecting flight:

 1.Use case name: Select Flight

  This use case is started by traveler. It provides the facility for traveler to select a flight from a list of available flights.

2.Flow of events:

 2.1 Basic flow:

    This use case is started after the search flight is completed by traveler. The system chooses a flight from the list of available flights if the search system find any flights between the roots. If there are no seats  available alternate flow 2.2.1 is executed.

2.2 Alternate flow:

  2.2.1 If there are no seats are available on the selected flight then  the system informs the traveler to choose another flight.

3.Special requirements:

There are no special requirements.

4. Pre conditions:

 There are no pre conditions.

5.Post conditions:

There are no post conditions.

6.Extension points:

 There are no extension points.

Use case specifications for bookins a flight :

1.Use case name: Book Flight.

   This is use case is started by the traveler.it provides the facility for the traveler to book tickets.

2. Flow of events:

 2.1 Basic flow;

 This use case is started  after the traveler chooses a flight.the system then asks the traveler to enter his/her details and credit card number. The system then checks the credit card number. The system then checks the credit card validity through credit card authorization mechanism and books the tickets else alternate flow 2.2.1 is executed. After booking the tickets the system update databases.

2.2 Alternate flow:

 2.2.1 If the credit card is not valid the system ask the traveler to re enter the credit card number correctly.

3.Special requirements:

 There are no special requirements.

4. Pre conditions:

 There is availability of seats in the flight which is choosen.

5. Post conditions:

 There are no post conditions.

6.Extension points:

 There are no extension points.

Use case specification for the cancel flight :

1.       Use case name: Cancel Flight.

2.       This use case id started by traveler to cancel his.her reservation.

3.      Flow of events:

3.1   Basic flow:This use case is  started by the traveler if he was some problems with travelling. To cancel the reservation the system asks the traveler his reservation number and confirmation.else alternate flow 2.2.1 is executed. After the conformation of travler the system concedes the reservation and update databases.

3.2  Alternate flow:

3.2.1          If the reservation number is in valid the message is displayed in valid number.

4.       special conditions:

5.       There are no special conditions.

6.      Pre conditions:

  User must have the reservation with that number.

7.      Post conditions:

There are no post conditions.

8.      Extension points:

There are no  extension points.

  

 9. ACTIVITY DIAGRAM

An Activity diagram is a variation of a special case of a state machine, in which the states are activities representing the performance of operations and the transitions are triggered by the completion of the operations. The purpose of Activity diagram is to provide a view of flows and what is going on inside a use case or among several classes. We can also use activity diagrams to model code-specific information such as a class operation. Activity diagrams are very similar to a flowchart because you can model a workflow from activity to activity.

An activity diagram is basically a special case of a state machine in which most of the states are activities and most of the transitions are implicitly triggered by completion of the actions in the source activities.

Ø  Activity diagrams represent the dynamics of the system.

Ø  They are flow charts that are used to show the workflow of a system; that is, they show the flow of control from activity to activity in the system, what activities can be done in parallel, and any alternate paths through the flow.

Ø  At this point in the life cycle, activity diagrams may be created to represent the flow across use cases or they may be created to represent the flow within a particular use case.

Ø  Later in the life cycle, activity diagrams may be created to show the workflow for an operation.

Activity diagrams contain activities, transitions between the activities, decision points, and synchronization bars. In the UML, activities are represented as rectangles with rounded edges, transitions are drawn as directed arrows, decision points are shown as diamonds, and synchronization bars are drawn as thick horizontal or vertical bars as shown in the following.

Activities:

An activity represents the performance of some behavior in the workflow.

Transitions:

Transitions are used to show the passing of the flow of control from activity to activity. They are typically triggered by the completion of the behavior in the originating activity.

Decision Points:

When modeling the workflow of a system it is often necessary to show where the flow of control branches based on a decision point. The transitions from a decision point contain a guard condition, which is used to determine which path from the decision point is taken. Decisions along with their guard conditions allow you to show alternate paths through a work flow.

Synchronization Bars

In a workflow there are typically some activities that may be done in parallel. A synchronization bar allows you to specify what activities may be done concurrently. Synchronization bars are also used to show joins in the workflow; that is, what activities

must complete before processing may continue. Means, a synchronization bar may have many incoming transitions and one outgoing transition, or one incoming transition and many outgoing transitions.

Swim lanes

Swim lanes may be used to partition an activity diagram. This typically is done to show what person or organization is responsible for the activities contained in the swim lane.

Initial and Final Activities

There are special symbols that are used to show the starting and final activities in a workflow. The starting activity is shown using a solid filled circle and the final activities are shown using a bull’s eye. Typically, there is one starting activity for the workflow and there may be more than one ending activity (one for each alternate flow in the workflow).

Modeling a workflow in an activity diagram can be done several ways; however, the following steps present just one logical process:

1. Identify a workflow objective. Ask, “What needs to take place or happen by the end of the workflow? What needs to be accomplished?” For example, if your activity diagram models the workflow of ordering a book from an online bookstore, the goal of the entire workflow could be getting the book to the customer.
2. Decide the pre and post-conditions of the workflow through a start state and an end state. In most cases, activity diagrams have a flowchart structure so start and end states are used to designate the beginning and ending of the workflow. State and end states clarify the perimeter of the workflow.
3. Define and recognize all activities and states that must take place to meet your objective. Place and name them on the activity diagram in a logical order.
4. Define and diagram any objects that are created or modified within your activity diagram. Connect the objects and activities with object flows.
5. Decide who or what is responsible for performing the activities and states through swim lanes. Name each swim lane and place the appropriate activities and states within each swim lane.
6. Connect all elements on the diagram with transitions. Begin with the “main” workflow.
7. Place decisions on the diagram where the workflow may split into an alternate flow. For example, based on a Boolean expression, the workflow could branch to a different workflow.
8. Evaluate your diagram and see if you have any concurrent workflows. If so, use synchronizations to represent forking and joining.
9. Set all actions, triggers and guard conditions in the specifications of each model element.

LOGICAL VIEW

10. IDENTIFICATION OF ANALYSIS CLASSES

1) USE-CASE DRIVEN APPROACH

One of the first steps in creating a class diagram is to derive from a use case, via a

collaboration (or collaboration diagram), those classes that participate in realizing the use case. Through further analysis, a class diagram is developed for each use case and the various use case class diagrams are then usually assembled into a larger analysis class diagram. This can be drawn first for a single subsystem or increment, but class diagrams can be drawn at any scale that is appropriate, from a single use case instance to a large, complex system.

Identifying the objects involved in collaboration can be difficult at first, and takes some practice before the analyst can feel really comfortable with the process. Here collaboration (i.e. the set of classes that it comprises) can be identified directly for a use case, and that, once the classes are known, the next step is to consider the interaction among the classes and so build a collaboration diagram.

Consider the following use case order products, to identify a set of classes.

Use case description: Search flight.

Actor Action

1. None

3. The actor (Customer) selects a product.

5. Prepare for order

System Response

2. Displays list of Products.

4. Displays a list of all details for ordering a product.

6. Presents a message confirming that the order has been allotted.

Here objective is to find a set of classes that can interact to realize the use case. In this case, we know from the use case diagram that the traveler is the actor for this use case. The use case description tells us that traveler search for the flight by giving arrival and departure city. The objective of the use case search flight is allow the user to search for flights

First begin by picking out from the description all the important things or concepts in the application domain. Our first list might include traveler, airline database, and user database. But we are only interested in those about which the system must store some information or knowledge in order to achieve its objectives. The traveler will be modeled as an actor.

For the purposes of this particular use case, it is unlikely the system will need to encapsulate any further knowledge about the actor.

The Collaboration Diagram for the Above USE CASE.

Collaboration is between individual object instances, not between classes. This is shown in the diagram by the convention of writing a colon before the class name, which indicates that this is an anonymous instance of the class, rather than the class itself. Messages between classes are shown by arrows, and their sequence is indicated by the number alongside. In this example, these are not yet labeled, although some those that can be most easily related to the use case description will probably soon be given names that correspond to responsibilities of the class to which the message is addressed.

The collaboration diagram drawn above does not yet show any boundary or control objects, and these must be added. It is also based on certain assumptions about how the interaction between objects would take place, and we must make these assumptions explicit and question them.

Although the messages are not yet labeled, the numbers alongside the message arrows indicates their sequence. The diagram implies a linear flow of messages, along the following lines.

The system is started by traveler by entering details for search, which is assumed to know its current status and type.    The following figure shows the collaboration diagram after this refinement adding a boundary object and control object.

A boundary object will be responsible for the capture of input from the user and display of results. All messages are now routed centrally through the control object. This means that no entity class needs to know anything about any other entity class unless this is directly relevant to its own responsibilities.

The above figure addresses one major issue, that, it seems reasonable to assume that a traveler is responsible for search flights. But the collaboration diagram now shows no communication between traveler and Searching system, so it is not clear how this knowledge will be maintained.

For this we can have another way that the interaction might work, and we could perhaps expand this as follows. The entity object airline database obtains a list of available flights and a control object searching system obtains the need from available and display them using boundary object display details.

From collaboration diagram to class diagram:

The next step in the development of a requirements model is usually to produce a class diagram that corresponds to each of the collaboration diagrams. Collaboration diagrams are obtained by result of reasonably careful analysis, the transition is not usually too difficult.

When the rectangular box variant of the notation is used in a collaboration diagram it represents object instances rather than classes, is normally undivided and contains only the class name .On a class diagram, the symbol is usually divided into three compartments that contain in turn the class name, its attributes and its operations.

An actor is almost always shown on a collaboration diagram, but not usually shown on a class diagram. This is because the collaboration diagram represents a particular interaction and the actor is an important part of this interaction. However, a class diagram shows the more enduring structure of associations among the classes, and frequently supports a number of different interactions that may represent several different use cases.

The connections between the object symbols on a collaboration diagram symbolize links between objects, while on a class diagram the corresponding connections stand for associations between classes.

A collaboration diagram shows the dynamic interaction of a group of objects and thus every link needed for message passing is shown. The labeled arrows alongside the links represent messages between objects. On a class diagram, the associations themselves are usually labeled, but messages are not shown.

The messages towards the objects in collaboration diagram are considered as operations in the class represented by that object. Attributes are also identified using some techniques which are discussed later.

2. NOUN PHRASE APPROACH.

In this method, analysts read through the requirements or use cases looking for noun phrases. Nouns in the textual description are considered to be classes and verbs to be methods of the classes All plurals are changed to singular, the nouns are listed, and the list divided into three categories relevant classes, fuzzy classes (the “fuzzy area,” classes we are not sure about), and irrelevant classes as shown below.

Using the noun phrase strategy, candidate classes can be divided into three categories: Relevant Classes, Fuzzy Area or Fuzzy classes (those classes that we are not sure about), and irrelevant Classes.

It is safe to scrap the irrelevant classes, which either have no purpose or will be unnecessary. Candidate classes then are selected from the other two categories. Here identifying classes and developing a UML class diagram just like other activities is an iterative process. Depending on whether such object modeling is for the analysis or design phase of development, some classes may need to be added or removed from the model .Analyst must be able to formulate a statement of purpose for each candidate class; if not, simply eliminate it.

1 Identifying Tentative Classes:

The following are guidelines for selecting classes in an application:

Ø  Look for nouns and noun phrases in the use cases.

Ø  Some classes are implicit or taken from general knowledge.

Ø  All classes must make sense in the application domain; avoid computer implementation classes-defer them to the design stage.

Ø  Carefully choose and define class names.

Identifying classes is an incremental and iterative process. This incremental and iterative nature is evident in the development of such diverse software technologies as graphical user interfaces, database standards, and even fourth-generation languages.

2 Selecting Classes from the Relevant and Fuzzy Categories:

The following guidelines help in selecting candidate classes from the relevant and fuzzy categories of classes in the problem domain.

A) Redundant classes.

Do not keep two classes that express the same information. If more than one word is being used to describe the same idea, select the one that is the most meaningful in the context of the system. This is part of building a common vocabulary for the system as a whole. Choose your vocabulary carefully; use the word that is being used by the user of the system.

E.g.: Traveler, Passenger

b) Adjectives classes.

“Be wary of the use of adjectives. Adjectives can be used in many ways. An adjective can suggest a different kind of object, different use of the same object, or it could be utterly irrelevant. Does the object represented by the noun behave differently when the adjective is applied to it? If the use of the adjective signals that the behavior of the object is different, and then makes a new class”.

For example : Single account holders behave differently than Joint account holders, so the two should be classified as different classes.

c) Attribute classes: Tentative objects that are used only as values should be defined or restated as attributes and not as a class

d) Irrelevant classes: Each class must have a purpose and every class should be clearly defined and necessary. You must formulate a statement of purpose for each candidate class. If you cannot come up with a statement of purpose, simply eliminate the candidate class.

As this is an incremental process. Some classes will be missing; others will be eliminated or refined later. Unless you are starting with a lot of domain knowledge, you probably are missing more classes than you will eliminate. Although some classes ultimately may become super classes, at this stage simply identify them as individual, specific classes. Your design will go through many stages on its way to completion, and you will have adequate opportunity to revise it.

This refining cycle through the development process until you are satisfied with the results. Remember that this process (of eliminating redundant classes, classes containing adjectives, possible attributes, and irrelevant classes) is not sequential. You can move back and forth among these steps as often analysts likes.

3. COMMON CLASS PATTERNS APPROACH

The second method for identifying classes is using common class patterns, which is based on a knowledge base of the common classes. The following patterns are used for finding the candidate class and object:

a) Concept class:

A concept is a particular idea or understanding that we have of our world. The concept class encompasses principles that are not tangible but used to organize or keep track of business activities or communications. E.g. Performance is an example of concept class object.

b) Events class

Events classes are points in time that must be recorded. Things happen, usually to something else at a given date and time or as a step in an ordered sequence. Associated

with things remembered are attributes (after all, the things to remember are objects) such as who, what, when, where, how, or why.

E.g.: Landing, interrupt, request, and order are possible events.

c) Organization class

An organization class is a collection of people, resources, facilities, or groups to which the users belong; their capabilities have a defined mission, whose existence is largely independent of the individuals. E.g.: An accounting department might be considered a potential class.

d) People class (also known as person, roles, and roles played class)

The people class represents the different roles users play in interacting with the application. E.g. Employee, client, teacher, and manager are examples of people.

e) Places class

Places are physical locations that the system must keep information about. E.g.: Buildings, stores, sites, and offices are examples of places.

11. IDENTIFICATION OF RESPONSIBILITIES OF CLASSES

Class Responsibility collaboration Cards ( CRC Cards)

At the starting, for the identification of classes we need to concentrate completely on uses cases. A further examination of the use cases also helps in identifying operations and the messages that classes need to exchange. However, it is easy to think first in terms of the overall responsibilities of a class rather than its individual operations.

A responsibility is a high level description of something a class can do. It reflects the knowledge or information that is available to that class, either stored within its own attributes or requested via collaboration with other classes, and also the services that it can offer to other objects. A responsibility may correspond to one or more operations. It is difficult to determine the appropriate responsibilities for each class as there may be many alternatives that all appear to be equally justified.

Class Responsibility Collaboration (CRC) cards provide an effective technique for exploring the possible ways of allocating responsibilities to classes and the collaborations that are necessary to fulfill the responsibilities.

CRC cards can be used at several different stages of a project for different purposes.

1.  They can be used early in a project to help the production of an initial class diagram.

2.  To develop a shared understanding of user requirements among the members of the team.

3.  CRCs are helpful in modeling object interaction. The format of a typical CRC card is shown below

Class Name:
Responsibilities	Collaborations
Responsibilities of a class are listed in this section	Collaborations with other classes are listed here, together with a brief description of the purpose of the collaboration

CRC cards are an aid to a group role-playing activity. Index cards are used in preference to pieces of paper due to their robustness and to the limitations that their size

(approx. 15cm x 8cm) imposes on the number of responsibilities and collaborations that can be effectively allocated to each class.

A class name is entered at the top of each card and responsibilities and collaborations are listed underneath as they become apparent. For the sake of clarity, each collaboration is normally listed next to the corresponding responsibility.

From a UML perspective, use of CRC cards is in analyzing the object interaction that is triggered by a particular use case scenario. The process of using CRC cards is usually structured as follows.

1.  Conduct a session to identify which objects are involved in the use case.

2.  Allocate each object to a team member who will play the role of that object.

3.  Act out the use case: This involves a series of negotiations among the objects to explore how responsibility can be allocated and to identify how the objects can collaborate with each other.

4.  Identify and record any missing or redundant objects.

Before beginning a CRC session it is important that all team members are briefed on the organization of the session and a CRC session should be preceded by a separate exercise that identities all the classes for that part of the application to be analyzed.

The team members to whom these classes are allocated can then prepare for the role playing exercise by considering in advance a first-cut allocation of responsibilities and identification of collaborations. Here, it is important to ensure that the environment in which the sessions take place is free from interruptions and free for the flow of ideas among team members.

During a CRC card session, there must be an explicit strategy that helps to achieve an appropriate distribution of responsibilities among the classes. One simple but effective approach is to apply the rule that each object should be as lazy as possible, refusing to take on any additional responsibility unless instructed to do so by its fellow objects.

During a session conducted according to this rule, each role player identifies the object that they feel is the most appropriate to take on each responsibility, and attempts to

persuade that object to accept the responsibility. For each responsibility that must be allocated, one object is eventually persuaded by the weight of rational argument to accept it. This process can help to highlight missing objects that are not explicitly referred to by the use case description. When responsibilities can be allocated in several different ways it is useful to role-play each allocation separately to determine which is the most appropriate. The aim normally is to minimize the number of messages that must be passed and their complexity, while also producing class definitions that are cohesive and well focused.

Consider CRC exercise for the use case allotting buses to routes. This use case involves instances of Bus, and Depot. The resulting CRC cards are shown in the following figure.

Class Name : traveler
Responsibilities	Collaborations
Provide traveling details	Search flight UI provide flights available.

CRC card for Traveler class in search flight.

Class Name : Searching system
Responsibilities	Collaborations
Search for the flight available.	Airline database provides the list of available flights

CRC card for Searching system in Search Flight

12. USE-CASE REALIZATIONS

Use case realization is nothing but an instance of a use case which involves the identification of a possible set of classes, together with an understanding of how those classes might interact to deliver the functionality of the use case. The set of classes is known as collaboration.

Use case realization diagram:

13. SEQUENCE DIAGRAM

A sequence diagram is a graphical view of a scenario that shows object interaction in a time based sequence i.e. what happens first and what happens next. Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces.

In Sequence diagram the vertical dimension represents time and all objects involved in the interaction are spread horizontally across the diagram.

Time normally proceeds down the page. However, a sequence diagram may be drawn with a horizontal time axis if required, and in this case, time proceeds from left to right across the page. Each object is represented by a vertical dashed line, called a lifeline, with an object symbol at the top. A message is shown by a solid horizontal arrow from one lifeline to another and is labeled with the message name. Each message name may optionally be preceded by a sequence number that represents the sequence in which the messages are sent, but this is not usually necessary on a sequence diagram since the message sequence is already conveyed by their relative positions along time axis.

Steps:

1. An object is shown as a box at the top of a dashed vertical line. Object names can be specific (e.g., Algebra 101, Section 1) or they can be general (e.g., a course offering). Often, an anonymous object (class name may be used to represent any object in the class.)

2. Each message is represented by an Arrow between the lifelines of two objects. The order in which these messages occur is shown top to bottom on the page. Each message is labeled with the message name.

14. COLLABORATION DIAGRAM

A collaboration diagram is an alternate way to show a scenario. This type of

diagram shows object interactions organized around the objects and their links to each other. A collaboration diagram contains:

Ø  Objects drawn as rectangles

Ø  Links between objects shown as lines connecting the linked objects

Ø  Messages shown as text and an arrow that points from the client to the supplier Message labels in collaboration diagrams:

Messages on a collaboration diagram are represented by a set of symbols that are the same as those used in a sequence diagram, but with some additional elements to show sequencing and recurrence as these cannot be inferred from the structure of the diagram. Each message label includes the message signature and also a sequence number that reflects call nesting, iteration, branching, concurrency and synchronization within the interaction.

The formal message label syntax is as follows: [Predecessor] [guard-condition] sequence-expression [return-value ':='] message-name’ (‘ [argument-list] ') '

A predecessor is a list of sequence numbers of the messages that must occur before the current message can be enabled. This permits the detailed specification of branching pathways. The message with the immediately preceding sequence number is assumed to be the predecessor by default, so if an interaction has no alternative pathways the predecessor list may be omitted without any ambiguity. The syntax for a predecessor is as follows:

Sequence-number { ',' sequence-number} '1'

The 'l' at the end of this expression indicates the end of the list and is only included when an explicit predecessor is shown.

Guard conditions are written in Object Constraint Language (OCL), and are only shown where the enabling of a message is subject to the defined condition. A guard condition may be used to represent the synchronization of different threads of control.

A sequence-expression is a list of integers separated by dots ('.') optionally followed by a name (a single letter), optionally followed by a recurrence term and terminated by a colon. A sequence-expression has the following syntax:

Integer {'.' integer} [name] [recurrence] ': '

In this expression integer represents the sequential order of the message. This may be nested within a loop or a branch construct, so that, for example, message 5.1 occurs after message 5.2 and both are contained within the activation of message 5.

The name of a sequence-expression is used to differentiate two concurrent messages since these are given the same sequence number. For example, messages 3.2.1a and 3.2.1b are concurrent within the activation of message 3.2.

Recurrence reflects either iterative or conditional execution and its syntax is as follows:

Branching:    ‘[‘condition-clause’ ],

Iteration: ‘* “[‘iteration-clause ‘ ]’

Difference between sequence and collaboration diagrams

Ø  Sequence diagrams are closely related to collaboration diagrams and both are alternate representations of an interaction.

Ø  Sequence diagrams show time-based object interaction while collaboration diagrams show how objects associate with each other.

Ø  A sequence diagram is a graphical view of a scenario that shows object interaction in a time based sequence

Ø  A collaboration diagram shows object interactions organized around the objects and their links to each other.

 15. IDENTIFICATION OF METHODS AND ATTRIBUTES OF CLASSES

Attributes

Attributes are part of the essential description of a class. They belong to the class, unlike objects, which instantiate the class. Attributes are the common structure of what a member of the class can 'know'. Each object will have its own, possibly unique, value for each attribute.

Guidelines for identifying attributes of classes are as follows:

Ø  Attributes usually correspond to nouns followed by prepositional phrases. Attributes also may correspond to adjectives or adverbs.

Ø  Keep the class simple; state only enough attributes to define the object state.

Ø  Attributes are less likely to be fully described in the problem statement.

Ø  Omit derived attributes.

Ø  Do not carry discovery attributes to excess.

Some questions are there which help in identifying the responsibilities of classes and deciding what data elements to keep track of:

·         What information about an object should we keep track of?

·         What services must a class provide?

Answering the first question helps us to identify the attributes of a class. Answering the second question helps us to identify class methods.

The attributes identified in our system are:

• Attributes for Airline Reservation : details,country,date
• Attributes for User : name,number.

The responsibilities identified in our system are:

• Methods for  Administrator:update,details.
• Methods for User: enter detais.

  

16. IDENTIFICATION OF RELATIONSHIPS AMONG CLASSES

NEED FOR RELATIONSHIPS AMONG CLASSES:

All systems are made up of many classes and objects. System behavior is achieved through the collaborations of the objects in the system.

For example, a passenger can perform reservation operation by submitting form to reservation clerk. This is often referred to as an object sending a message to another object. Relationships provide the medium or tool for object interaction. Two types of relationships in CLASS diagram are:

1.  Associations Relationship

2.  Aggregations Relationship

1. ASSOCIATION RELATIONSHIPS:

An association is a bidirectional semantic connection between classes. It is not a data flow as defined in structured analysis and design data may flow in either direction across the association. An association between classes means that there is a link between objects in the associated classes.

For example, an association between the Searching system class and the Airline database means that objects in the class searching system are connected to objects in the Airline database.

Association Relationship with Multiplicity

2. AGGREGATION RELATIONSHIPS:

An aggregation relationship is a specialized form of association in which a whole is related to its part(s).

Aggregation is known as a “part-of’ or containment relationship. The UML notation for an aggregation relationship is an association with a diamond next to the class denoting the aggregate (whole), as shown below:

 

NAMING RELATIONSHIPS:

An association may be named. Usually the name is an active verb or verb phrase that communicates the meaning of the relationship. Since the verb phrase typically implies a reading direction, it is desirable to name the association so it reads correctly from left to right or top to bottom. The words may have to be changed to read the association in the other direction. It is important to note that the name of the association is optional.

ROLE NAMES:

The end of an association where it connects to a class is called an association role. Role names can be used instead of association names.

A role name is a noun that denotes how one class associates with another. The role name is placed on the association near the class that it modifies, and may be placed on one or both ends of an association line.

Ø  It is not necessary to have both a role name and an association name. >• 

Ø  Associations are named or role names are used only when the names are needed for clarity.

MULTIPLICITY INDICATORS:

Although multiplicity is specified for classes, it defines the number of objects that participate in a relationship. Multiplicity defines the number of objects that are linked to one another. There are two multiplicity indicators for each association or aggregation one at each end of the line. Some common multiplicity indicators are

1          Exactly one

0.. *     Zero or more

1... *    One or more

0 .. 1    Zero or one

5 .. 8    Specific range (5, 6, 7, or 8)

4 .. 7,9 Combination (4, 5, 6, 7, or 9)

REFLEXIVE RELATIONSHIPS:

Multiple objects belonging to the same class may have to communicate with one another. This is shown on the class diagram as a reflexive association or aggregation. Role names rather than asociation names typically are used for reflexive relationships.

17. UML CLASS DIAGRAM

CLASS DIAGRAMS

Ø  Class diagrams are created to provide a picture or view of some or all of the classes in the model.

Ø  The main class diagram in the logical view of the model is typically a picture of the packages in the’ system. Each package also has its own main class diagram, which typically displays the “public” classes of the package.

A class diagram is a picture for describing generic descriptions of possible systems. Class diagrams and collaboration diagrams are alternate representations of object models.

Class diagrams contain icons representing classes, packages, interfaces, and their relationships. You can create one or more class diagrams to depict the classes at the top level of the current model; such class diagrams are themselves contained by the top level of the current model.

CLASS :

A class is a description of a group of objects with common properties (attributes), common behavior (operations), common relationships to other objects, and common semantics. Thus, a class is a template to create objects. Each object is an instance of some class and objects cannot be instances of more than one class.

Classes should be named using the vocabulary of the domain. For example, the Bus class may be defined with the following characteristics: Attributes - location, time offered Operations   - retrieve location, retrieve time of day, add a student to the offering.

Each object would have a value for the attributes and access to the operations specified by the Airline database class.

UML REPRESENTATION:

Ø  In the UML, classes are represented as compartmentalized rectangles.

Ø  The top compartment contains the name of the class.

Ø  The middle compartment contains the structure of the class (attributes).

Ø  The bottom compartment contains the behavior of the class  as shown below. 

ANALYSIS CLASS STEROTYPES

Analysis class stereotypes represent three particular kinds of class that will be encountered again and again when carrying out requirements modeling. UML DEFINITION:

Stereotype:

Ø  A new type of modeling element that extends the semantics of the metamodel.

Ø  Stereotypes must be based on certain existing types or classes in the metamodel.

Ø  Stereotypes may extend the semantics but not the structure of preexisting classes.

Ø  Certain stereotypes are defined in the UML, others may be user defined.

UML is designed to be capable of extension; developers can add new stereotypes depend on need. But this is only done when it is absolutely necessary. Three analysis class stereotypes to the UML are:

Ø  Boundary classes,

Ø  Control classes

Ø  Entity classes.

1. Boundary classes:

Boundary classes, it is a   ‘model interaction between the system and its actors’. Since they are part of the requirements model, boundary classes are relatively abstract.  They do not directly represent all the different sorts of interface that will be used in the implementation language. The design model may well do this later, but from an analysis perspective we are interested only in identifying the main logical interfaces with users and other systems.

This may include interfaces with other software and also with physical devices such as printers, motors and sensors. Stereotyping these as boundary classes emphasizes that their main task is to manage the transfer of information across system boundaries. It also helps to partition the system, so that any changes to the interface or communication aspects of the system can be isolated from those parts of the system that provide the information storage.

The class Search flight Ul is a typical boundary class. This style of writing the name shows that the class is Search flight UI and it belongs to the User Interface package when we write the package name in this way before the class name, it means that this class is imported from a different package from the one with which we are currently working. In this case, the current package is the Agate application package, which contains the application requirements model, and thus consists only of domain objects and classes. Alternative notations for Boundary class stereotype can be represented as shown below

a) With stereotype

b) Symbol 

 

2. Entity classes

The second analysis class stereotype is the entity class, which are given in the class diagram of Allotting Buses to Routes by the two classes Bus and Route.

Entity classes are used to model ‘information and associated behavior of some phenomenon or concept such as an individual, a real-life object, or a real-life event’. As a general rule, entity classes represent something within the application domain, but external to the software system, about which the system must store some information. Instances of an entity class will often require persistent storage of information about the things that they represent. This can sometimes help to decide whether an entity class is the appropriate modeling construct.

For example, an actor is often not represented as an entity class. This is in spite of the fact that all actors are within the application domain, external to the software system and important to its operation. But most systems have no need to store information about their users or to model their behavior. While there are some obvious exceptions to this (consider a system that monitors user access for security purposes), these are typically separate, specialist applications in their own right. In such a context, an actor would be modeled appropriately as an entity class, since the essential requirements for such a system would include storing information about users, monitoring their access to computer systems and tracking their actions while logged on to a network. But it is more commonly the case that the software we develop does not need to know anything about the people that use it, and so actors are not normally modeled as classes. The following are representations for Entity classes.

3. Control classes

The third of the analysis class stereotypes is the control class, given by y the class Searching system in Search flight.

Control classes ‘represent coordination, sequencing, transactions and control of other objects’ .In the USDP, as in the earlier methodology Objectory. it is generally recommended that there should be a control class for each use case.

In a sense, then, the control class represents the calculation and scheduling aspects of the logic of the use case at any rate, those parts that are not specific to the behavior of a particular entity class, and that are specific to the use case. Meanwhile the boundary class represents interaction with the user and the entity classes represent the behavior of things in the application domain and storage of information that is directly associated with those things. The following are the notations can be used to represent Control class

18. UML STATE CHART DIAGRAM

Use cases and scenarios provide a way to describe system behavior; in the form of interaction between objects in the system. Some times it is necessary to consider inside behavior of an object.

A state chart diagram shows the states of a single object, the events or messages that cause a transition from one state to another , and the actions that result from a state change. As in Activity diagram , state chart diagram also contains special symbols for start state and stop state.

State chart diagram cannot be created for every class in the system, it is only for those class objects with significant behavior. STATE :

A state represents a condition or situation during the life of an object during which it satisfies some condition , performs some action or waits for some event. UML notation for STATE is

To identify the states for an object its better to concentrate on sequence diagram. In an APSRTC application the object for Course Offering may have in the following states, initialization, open and closed state. These states are obtained from the attribute and links defined for the object. Each state also contains a compartment for actions .

ACTIONS :

Actions on states can occur at one of four times:

Ø  on entry

Ø  on exit

Ø  do

Ø  on event.

On entry: What type of action that object has to perform after entering into the state.

On exit : What type of action that object has to perform after exiting from the state.

Do : The task to be performed when object is in this state, and must to continue until it leaves the state.

On event: An on event action is similar to a state transition label with the following syntax:

event(args)[condition] : the Action

STATE TRANSITION:

A state transition indicates that an object in the source state will perform certain specified actions and enter the destination state when a specified event occurs or when certain conditions are satisfied. A state transition is a relationship between two states, two activities, or between an activity and a state.

We can show one or more state transitions from a state as long as each transition is unique. Transitions originating from a state cannot have the same event, unless there are conditions on the event. Graphical Representation

Provide a label for each state transition with the name of at least one event that causes the state transition. You do not have to use unique labels for state transitions because the same event can cause a transition to many different states or activities. Transitions are labeled with the following syntax:

event (arguments) [condition] / action ^{^} target.sendEvent (arguments)

Only one event is allowed per transition, and one action per event.

STATE DETAILS:

Actions that accompany all state transitions into a state may be placed as an entry action within the state. Likewise that accompany all state transitions out of a state may be placed as exit actions within the state. Behavior that occurs within the state is called an activity.

An activity starts when the state is entered and either completes or is interrupted by an outgoing state transition. The behavior may be a simple action or it may be an event sent to another object.

DESIGN

19. DESIGNING CLASSES BY APPLYING DESIGN AXIOMS

3 Criteria for Good Design

1 Coupling and cohesion - These factors coupling and cohesion are important factors for good design.

Coupling describes the degree of interconnectedness between design components and is reflected by the number of links an object has and by the degree of interaction the object has with other objects.

Cohesion is a measure of the degree to which an element contributes to a single purpose. The concepts of coupling and cohesion are not mutually exclusive but actually support each other. This criteria can be used within object-orientation as described below.

Interaction Coupling is a measure of the number of message types an object sends to other objects and the number of parameters passed with these message types. Interaction coupling should be kept to a minimum to reduce the possibility of changes rippling through the interfaces and to make reuse easier. When an object is reused in another application it will still need to send these messages and hence needs objects in the new application that provide these services. This complicates the reuse process as it requires groups of classes to be reused rather than individual classes. Inheritance Coupling describes the degree to which a subclass actually needs the features it inherits from its base class.

For example, in the above figure, the inheritance hierarchy exhibits low inheritance coupling and is poorly designed. The subclass Land Vehicle needs neither the attributes maximum Altitude and takeoff Speed nor the operations check Altitude () and takeOff (). They have been inherited unnecessarily.

In this example it shows the base class, Vehicle, would be better named Flying Vehicle and the inheritance relationship is somewhat suspect. A land vehicle is not a kind of flying vehicle .However, many systems developers view designs with a small degree of unnecessary inheritance as being acceptable if the hierarchy is providing valuable reuse and is meaningful. However, a subclass with unnecessary attributes or operations is more complex than it needs to be and objects of the subclass may take more memory than they actually need. The real problems may come when the system needs maintenance. The system’s maintainer may not realize that some of the inherited attributes and operations are unused and may modify the system incorrectly as a result. Alternatively the system’s maintainer may use these unneeded features to provide a fix for a new user requirement,

making the system even more difficult to maintain in the future. For these reasons, unnecessary inheritance should be kept as low as possible.

Operation Cohesion measures the degree to which an operation focuses on a single functional requirement. Good design produces highly cohesive operations, each of which deals with a single functional requirement. For example in the following figure , the operation calculateRoomSpace () is highly cohesive.

Class Cohesion reflects the degree to which a class is focused on a single requirement. The class Lecturer in the previous figure exhibits low levels of cohesion as it has three attributes (roomNumber, roomLength and room Width and one operation calculate RoomSpace ()) that would be more appropriate in a class Room. The class Lecturer should only have attributes that describe a Lecturer object (e.g. lecturerName and lecturerAddress) and operations that use them. Specialization Cohesion addresses the semantic cohesion of inheritance hierarchies. For example in the following figure all the attributes and operations of the Address base class are used by the derived classes - this hierarchy has high inheritance coupling. However, it is neither true that a person is a kind of address nor that a company is a kind of address. The example is only using inheritance as a syntactic structure for sharing attributes and operations. This structure has low specialization cohesion and is poor design. It does not reflect meaningful inheritance in the problem domain.

2 Liskov Substitution Principle

The Liskov Substitution Principle (LSP) is another design criteria which is applicable to inheritance hierarchies. LSP states that, in object interactions, it should be possible to treat a derived object as if it were a base object. If the principle is not applied then it may be possible to violate the integrity of the derived object.

In the following figure objects of the class MortgageAccount cannot be treated as if they are objects of the class ChequeAccount because MortgageAccount objects do not have a debit operation whereas ChequeAccount objects do. The debit operation is declared private in MortgageAccount and hence cannot be used by any other object. It also shows an alternative structure that satisfies LSP. Interestingly, this inheritance hierarchy has maximal inheritance coupling, and enforcing the LSP normally produces structures with high inheritance coupling.

3 Further design guidelines

The following are the further guidelines which are to be considered for good design.

Design Clarity. A design should be made as easy to understand as possible. This reinforces the need to use design standards or protocols that have been specified.

Don’t Over-Design. Developers are on occasions tempted to produce designs that may not only satisfy current requirements but may also be capable of supporting a wide range of future requirements. Designing flexibility into a system has a cost, the system may take longer to design and construct but this may be offset in the future by easier and less expensive modification. However, it is not feasible to design for every eventuality. Systems that are over designed in first instance are more difficult to extend if the modifications are not sympathetic to the existing structure.

Control Inheritance Hierarchies. Inheritance hierarchies should be neither too deep nor too shallow. If a hierarchy is too deep it is difficult for the developer to understand easily what features are inherited. There is a tendency for developers new to 00 to produce over-specialized hierarchies, thus adding complexity rather than reducing it.

Keep Messages and Operations Simple. In general it is better to limit the number of parameters passed in a message to no more than three .Ideally an operation should be capable of specification in no more than one page.

Design Volatility. A good design will be stable in response to changes in requirements. It reasonable to expect some change in the design if the requirements are changed, However, any change in the design should be commensurate with the change in requirements. Enforcing encapsulation is a key factor in producing stable systems.

Evaluate by Scenario. An effective way of testing the suitability of a design is to role paly it against the use cases using CRC cards.

Design by Delegation. A complex object should be decomposed (if possible) into component objects forming a composition or aggregation. Behavior can then be delegated to the component objects producing a group of objects that are easier to construct and maintain. This approach also improves reusability.

Keep Classes Separate. In general, it is better not to place one class inside another. The internal class is encapsulated by the other class and cannot be accessed independently. This reduces the flexibility of the system. 

20.REFINING ATTRIBUTES, METHODS AND RELATIONSHIPS

Attributes

            During analysis Stage we need to consider in detail the data types of the attributes also. Common primitive data types include Boolean (true or false), Character (any alphanumeric or special character), Integer (whole numbers) and Floating-Point (decimal numbers). In most object-oriented languages more complex data types, such as Money, String, Date, or Name can be constructed from the primitive data types or may be available in standard libraries. An attribute's data type is declared in UML using the following syntax:

            name ':' type-expression '=' initial-value '{'property-string'}'

            The name is the attribute name, the type-expression is its data type, the initial value is the value the attribute is set to when the object is first created and the property-string describes a property of the attribute, such as constant or fixed. The characters in single quotes are literals.

The following is a class Staff which is shown along with attribute data types declared.

Attribute declarations can also include arrays also. For example, an Employee class might include an attribute to hold a list of qualifications that would be declared using the syntax:

Qualification [O  ... 10]: String

Operations

            Each operation also has to be specified in terms of the parameters that it passes and returns. The syntax used for an operation is:

            Operation name' ('parameter-list ') “: “return-type-expression

            An operation's signature is determined by the operation's name, the number and type of its parameters and the type of the return value if any.

             

Object visibility

            The concept of encapsulation is one of the fundamental principles of object-orientation. During analysis various assumptions have been made regarding the encapsulation boundary for an object and the way that objects interact with each other.

            For example, it is assumed that the attributes of an object cannot be accessed directly by other objects but only via 'get' and 'set' operations (primary operations) that are assumed to be available for each attribute. Moving to design involves making decisions regarding which operations (and possibly attributes) are publicly accessible. In other words we must define the encapsulation boundary.

  

The following are the different kinds of visibilities, their symbols and their meaning.

Visibility symbol	Visibility	Meaning
+	Public	The feature (an operation or an attribute) is directly accessible by an instance of any class.
-	Private	The feature may only be used by an instance of the class that includes it.
#	Protected	The feature may be used either by instances of the class that includes it or of a subclass or descendant of that class.
~	Package	The feature is directly accessible only by instances of a class in the same package.

 Interfaces

Generally a class may present more than one external interface to other classes or the same interface may be required from more than one class. An interface in UML is a group of externally visible (i.e. public) operations. The interface contains no internal structure, it has no attributes, no associations and the implementation of the operations is not defined. Formally, an interface is equivalent to an abstract class that has no attributes, no associations and only abstract operations.

            The following figure shows two alternative notations for an interface. The simpler of the two UML interface notations is a circle. This is attached by a solid line to the classes that support the interface. For example, in Figure the Advert class supports two interfaces, Manageable and accessible, that is, it provides all of the operations specified by the interface. The circle notation does not include a list of the operations provided by the interface type, though they should be listed in the repository. The dashed arrow from the Staff class to the Manageable interface circle icon indicates that it uses or needs, at most, the operations provided by the interface.

            The alternative notation uses a stereotyped class icon. As an interface only specifies the operations and has no internal structure, the attributes compartment is omitted. This notation lists the operations on the diagram. The realize relationship, represented by the dashed line with a triangular arrowhead, indicates that the passenger class (e.g reservation) supports at least the operations listed in the interface .Again the dashed arrow from staff means that the class needs or uses no more than the operations listed in the interface.

CLASS SPECIFICATION - Attributes and operation signatures

Object visibility

Interfaces

In general it is better to limit the number of parameters passed in a message to no more than three .Ideally an operation should be capable of specification in no more than one page.

Design Volatility. A good design will be stable in response to changes in requirements. It is reasonable to expect some change in the design if the requirements are changed. However, any change in the design should be commensurate with the change in requirements. Enforcing encapsulation is a key factor in producing stable systems.

22.IMPLEMENTATION DIAGRAMS

22  (a).COMPONENT DIAGRAM     

     

     Two type’s implementation diagrams in UML terminology are

1.       Component diagrams

2.       Deployment diagrams

            In a large project there will be many files that make up the system. These files will have dependencies on one another. The nature of these dependencies will depend on the language or languages used for the development and may exist at compile-time, at link-time or at run-time. There are also dependencies between source code files and the executable files or byte code files that are derived from them by compilation. Component diagrams are one of the two types of implementation diagram in UML. Component diagrams show these dependencies b/n software components in the system. Stereotypes can be used to show dependencies that are specific to particular languages also.

            A component diagram shows the allocation of classes and objects to components in the physical design of a system. A components diagram may represent all or part of the component architecture of a system along with dependency relationships.

The dependency relationship indicates that one entity in a components diagram uses the services or facilities of another.

Ø  Dependencies in the component diagram represent compilation dependencies.

Ø  The dependency relationship may also be used to show calling dependencies among components, using dependency arrows from components to interfaces on other components.

Different authors use component diagrams in different ways

Here we have the following distinction b/n them

Ø  Components in a component diagram should be the physical components of a system.

Ø  During analysis and the early stages of design, package can be used to show the logical grouping of class diagrams or of models that use other kinds of diagrams into packages relating to sub-systems.

Ø  During implementation, package diagrams can be used to show the grouping of physical components into sub-systems.

If component diagrams are used, it is better to keep separate sets of diagrams to show compile-time and run-time dependencies, however, this is likely to result in a large number of diagrams. Component diagrams show the components as types. If you wish to show instances of components of components you can use a deployment diagram.