Aim : To Prepare Software Design Description Document

1. Introduction a. Purpose

This document provides an overview of the design of the Airline software systems. It is a living document that is expected to evolve throughout the design process. During conceptual design it provides a 'broadbrush' perspective of the design with detail to be added during subsequent design phases. The focus during conceptual design is on describing enough of the design to allow an examination of the design's suitability in meeting the system requirements. In this fashion, the document presents many conceptual design concepts as design requirements.

b. Scope

This Software Design Document provides a complete description of the design of the AFIRS system, developed for the airlines. The dominant design methodology is an object-oriented design using a Visual interface to a database management system. This document describes two levels of the system. The larger system accepts input data from the user. These are stored in airline database. The input data is modified as per the modification by user. The core system then processes these files and store report files in the database. After database files are finalised, the larger system is used to print the tickets. The Administrator accesses this system through forms. These forms interact with code modules to provide the bulk of the services. In turn these code modules interact with the underlying database. The Administrator will work on the larger system using standard utilities such as telnet and ftp. S/he will use a word processor for local printing. The Administrator will do most normal maintenance of the persistent data in the database using database utilities. These include adding new faculty members, adding new flights to the schedule and their recommendation schemes.

Definitions and Acronyms AFIRS.Airline Flight Information And Reservation System .a.

which returns a python dictionary datastructure containing the datamembers of that object. Decomposition Description a.1. Spicejet for overall view of the site 2. This model-object is created and mutated by the object filler. When an action is performed. </MODEL> . the controller puts the right model-object in the view container.. Navathe for database creation 3.. Therefor. Model module . using cgi. References 1. or an exception object. </CONTENT> </PAGE> Databasemodule All data used by the portal can be retrieved. All these objects contain the export method. interaction with the database is needed. using the transformer class of the model. <PAGE> <LOGIN>yes/no</LOGIN> <EDIT>yes/no</EDIT> <CONTENT> <MODEL> . The view container class transforms all these dictionaries to xml... In the controller the right action is performed by dispatching on the operation (which is available in the cgi form). Thereafter. This view container can contain multiple model-objects. When the operation isn't available in the controller. Module Description This is an important aspect of the program. Black Book for HTML designing 2. The requests from the users are provided to the controller. the xsltransformer is called with the xml of the objects of the view container. an error will be displayed by the view. added. updated and deleted through this module.

It doesn't depend on other modules. view: the view module provides functionality to transform xml to xhtml. It depends on the modules libxml2 and libxslt to achieve this. Archive ± Searchable archive offering access to ATI. our program isn't involved here. Airline Business and Flight International. It executes the cgi-scripts (the controller part of our program). Inter-Module Dependency y y y y y y model: this module provides data abstractions for the entities used in the system. 3. For each execution (request to the program) a new thread is started. These dictionaries can contain other dictionaries as values. Aircraft ± Individual aircraft and fleet information. The layout module provides the xsl files for the transformation. When processing these requests the controller uses abstractions provided in the model and manipulates them. Data Description y y y y y Airports ± Up to date information on the world¶s airports. errorhandlers: this module provides exception handling. These threads can access the database concurrently. It requires a MySql Database to be present.. Concurrent Process Description The apache server handles basic webserver functionalities. Dependency Description a. such as users and events. controller: CGI is used to handle input(requests) from the web interface to the controller. This is ensured by underlying sofware. layout: this module exists of xsl files. Suppliers ± Profiles of the leading industry manufacturers. suppliers and maintenance organisations. a.This module is the model part of the Model-View-Controller design pattern. Schedules ± Passenger and cargo schedules provided by Innovata. database: this module provides an interface to the database. They are used by the view to make webpages. It uses the module MySqlDB to achieve this. . It provides data abstractions to the entities that are used in the program. interacting with the database. This module doesn't rely on other modules. The transformer class of the model module transforms a python dictionary datastructure into xml.

When the client requests something the webserver executes a cgi file. this thread handles the whole request and terminates when a webpage is generated to show the user. Data Dependency .a. Inter-Process Dependency The Apache server process handles client-server communication. a. A new thread is started.

.

an error page will be shown to the user. This outputs the data members of a class in a dictionary. to an actual xhtml webpage.1. View interface The view contains the xsltransformer. The form received contains a data field "operation". This dictionary serves as input to the Transformer class (see figure 3) to generate xml. They are cgi files. Notice: every class has a method export(). which transforms a view container. This is the output that is shown to the user. Controller interface When a user interacts with the system (click a link. This xml data is used by the view to create a webpage. thus output to the user. or fill in a form) a controller (usercontroller or agendacontroller) is started. Module Interface Database interface The dataclass provides the interface to the database Model interface The interface to the model is spread over all classes in the model module (see figure 3). This operation is mapped to an action table which contains all the actions provided by that controller. using the xsl files of the layout module. so the needed data is provided to the controller. . When no action is available. The function perform() is called. Interface Description a. The right action is then executed.

Interfaces to a process are described. the process implements one request-response operation in a portType. The input node receives the request message and the output node replies with the response message. From a process implementation point of view. It is a process client dependent callback. From a process implementation point of view. In the case of a synchronous interface. In the case of a synchronous interface. . The input node receives the request message. The interfaces of processes are described using WSDL portTypes. the input and output node of the process point to the same portType and operation. In this case the caller of the process does not wait for a response. The output node in this case is an invocation. In this case the caller of the process waits for a synchronous response. From a process implementation (more details in next section) point of view. described by a oneway operation of another portType (see also the Process deploy scenarios topic for more details). In this case the caller of the process waits for a synchronous response. The interfaces of processes are described using WSDL portTypes. We differentiate between processes with synchronous and asynchronous interfaces. The input node receives the request message and the output node replies with the response message. the process implements a one-way operation in a portType. the process implements one request-response operation in a portType. We differentiate between processes with synchronous and asynchronous interfaces. the input node of the process points to a one-way operation in a portType. Process Interface Interfaces to a process are described.a. the input and output node of the process point to the same portType and operation. In the case of an asynchronous interface.

described by a oneway operation of another portType Detailed Design a. the input node of the process points to a one-way operation in a portType. From a process implementation (more details in next section) point of view. The input node receives the request message. the process implements a one-way operation in a portType. In this case the caller of the process does not wait for a response. Module Detailed Design b. Data Detailed Design . The output node in this case is an invocation. It is a process client dependent callback.In the case of an asynchronous interface.

Sign up to vote on this title
UsefulNot useful