Software Design Description Document
Content
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.
a. Definitions and Acronyms
AFIRS- Airline Flight Information And Reservation System
1. References
1. Black Book for HTML designing 2. Navathe for database creation 3. Spicejet for overall view of the site
2. Decomposition Description a. Module Description
This is an important aspect of the program. The requests from the users are provided to the controller, using cgi. In the controller the right action is performed by dispatching on the operation (which is available in the cgi form). When the operation isn't available in the controller, an error will be displayed by the view. When an action is performed, the controller puts the right model-object in the view container. This model-object is created and mutated by the object filler. Therefor, interaction with the database is needed. This view container can contain multiple model-objects, or an exception object. All these objects contain the export method, which returns a python dictionary datastructure containing the datamembers of that object. The view container class transforms all these dictionaries to xml, using the transformer class of the model. Thereafter, the xsltransformer is called with the xml of the objects of the view container.
<PAGE> <LOGIN>yes/no</LOGIN> <EDIT>yes/no</EDIT> <CONTENT> <MODEL> ... </MODEL> ... </CONTENT> </PAGE>
Databasemodule All data used by the portal can be retrieved, added, updated and deleted through this module. Model module
This module is the model part of the Model-View-Controller design pattern. It provides data abstractions to the entities that are used in the program, such as users and events.. The transformer class of the model module transforms a python dictionary datastructure into xml. These dictionaries can contain other dictionaries as values.
Concurrent Process Description
The apache server handles basic webserver functionalities. It executes the cgi-scripts (the controller part of our program). For each execution (request to the program) a new thread is started. These threads can access the database concurrently. This is ensured by underlying sofware, our program isn't involved here.
a. Data Description
y y y y y Airports ± Up to date information on the world¶s airports. Archive ± Searchable archive offering access to ATI, Airline Business and Flight International. Aircraft ± Individual aircraft and fleet information. Schedules ± Passenger and cargo schedules provided by Innovata. Suppliers ± Profiles of the leading industry manufacturers, suppliers and maintenance organisations.
3. Dependency Description a. Inter-Module Dependency
y y
y
y y y
model: this module provides data abstractions for the entities used in the system. This module doesn't rely 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. The layout module provides the xsl files for the transformation. controller: CGI is used to handle input(requests) from the web interface to the controller. When processing these requests the controller uses abstractions provided in the model and manipulates them, interacting with the database. database: this module provides an interface to the database. It uses the module MySqlDB to achieve this. It requires a MySql Database to be present. errorhandlers: this module provides exception handling. It doesn't depend on other modules. layout: this module exists of xsl files. They are used by the view to make webpages.
a. Inter-Process Dependency
The Apache server process handles client-server communication. When the client requests something the webserver executes a cgi file. A new thread is started; this thread handles the whole request and terminates when a webpage is generated to show the user.
a. Data Dependency
1. Interface Description a. 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). Notice: every class has a method export(). This outputs the data members of a class in a dictionary. This dictionary serves as input to the Transformer class (see figure 3) to generate xml. This xml data is used by the view to create a webpage, thus output to the user.
Controller interface
When a user interacts with the system (click a link, or fill in a form) a controller (usercontroller or agendacontroller) is started. They are cgi files, so the needed data is provided to the controller. The function perform() is called. The form received contains a data field "operation". This operation is mapped to an action table which contains all the actions provided by that controller. The right action is then executed. When no action is available, an error page will be shown to the user.
View interface
The view contains the xsltransformer, which transforms a view container, using the xsl files of the layout module, to an actual xhtml webpage. This is the output that is shown to the user.
a. Process Interface
Interfaces to a process are described. The interfaces of processes are described using WSDL portTypes. We differentiate between processes with synchronous and asynchronous interfaces. In the case of a synchronous interface, the process implements one request-response operation in a portType. In this case the caller of the process waits for a synchronous response. From a process implementation point of view, the input and output node of the process point to the same portType and operation. The input node receives the request message and the output node replies with the response message.
In the case of an asynchronous interface, the process implements a one-way operation in a portType. In this case the caller of the process does not wait for a response. From a process implementation (more details in next section) point of view, the input node of the process points to a one-way operation in a portType. The input node receives the request message. The output node in this case is an invocation. It is a process client dependent callback, described by a oneway operation of another portType (see also the Process deploy scenarios topic for more details).
Interfaces to a process are described. The interfaces of processes are described using WSDL portTypes. We differentiate between processes with synchronous and asynchronous interfaces. In the case of a synchronous interface, the process implements one request-response operation in a portType. In this case the caller of the process waits for a synchronous response. From a process implementation point of view, the input and output node of the process point to the same portType and operation. The input node receives the request message and the output node replies with the response message.
In the case of an asynchronous interface, the process implements a one-way operation in a portType. In this case the caller of the process does not wait for a response. From a process implementation (more details in next section) point of view, the input node of the process points to a one-way operation in a portType. The input node receives the request message. The output node in this case is an invocation. It is a process client dependent callback, described by a oneway operation of another portType
Detailed Design a. Module Detailed Design
b. Data Detailed Design
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.
a. Definitions and Acronyms
AFIRS- Airline Flight Information And Reservation System
1. References
1. Black Book for HTML designing 2. Navathe for database creation 3. Spicejet for overall view of the site
2. Decomposition Description a. Module Description
This is an important aspect of the program. The requests from the users are provided to the controller, using cgi. In the controller the right action is performed by dispatching on the operation (which is available in the cgi form). When the operation isn't available in the controller, an error will be displayed by the view. When an action is performed, the controller puts the right model-object in the view container. This model-object is created and mutated by the object filler. Therefor, interaction with the database is needed. This view container can contain multiple model-objects, or an exception object. All these objects contain the export method, which returns a python dictionary datastructure containing the datamembers of that object. The view container class transforms all these dictionaries to xml, using the transformer class of the model. Thereafter, the xsltransformer is called with the xml of the objects of the view container.
<PAGE> <LOGIN>yes/no</LOGIN> <EDIT>yes/no</EDIT> <CONTENT> <MODEL> ... </MODEL> ... </CONTENT> </PAGE>
Databasemodule All data used by the portal can be retrieved, added, updated and deleted through this module. Model module
This module is the model part of the Model-View-Controller design pattern. It provides data abstractions to the entities that are used in the program, such as users and events.. The transformer class of the model module transforms a python dictionary datastructure into xml. These dictionaries can contain other dictionaries as values.
Concurrent Process Description
The apache server handles basic webserver functionalities. It executes the cgi-scripts (the controller part of our program). For each execution (request to the program) a new thread is started. These threads can access the database concurrently. This is ensured by underlying sofware, our program isn't involved here.
a. Data Description
y y y y y Airports ± Up to date information on the world¶s airports. Archive ± Searchable archive offering access to ATI, Airline Business and Flight International. Aircraft ± Individual aircraft and fleet information. Schedules ± Passenger and cargo schedules provided by Innovata. Suppliers ± Profiles of the leading industry manufacturers, suppliers and maintenance organisations.
3. Dependency Description a. Inter-Module Dependency
y y
y
y y y
model: this module provides data abstractions for the entities used in the system. This module doesn't rely 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. The layout module provides the xsl files for the transformation. controller: CGI is used to handle input(requests) from the web interface to the controller. When processing these requests the controller uses abstractions provided in the model and manipulates them, interacting with the database. database: this module provides an interface to the database. It uses the module MySqlDB to achieve this. It requires a MySql Database to be present. errorhandlers: this module provides exception handling. It doesn't depend on other modules. layout: this module exists of xsl files. They are used by the view to make webpages.
a. Inter-Process Dependency
The Apache server process handles client-server communication. When the client requests something the webserver executes a cgi file. A new thread is started; this thread handles the whole request and terminates when a webpage is generated to show the user.
a. Data Dependency
1. Interface Description a. 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). Notice: every class has a method export(). This outputs the data members of a class in a dictionary. This dictionary serves as input to the Transformer class (see figure 3) to generate xml. This xml data is used by the view to create a webpage, thus output to the user.
Controller interface
When a user interacts with the system (click a link, or fill in a form) a controller (usercontroller or agendacontroller) is started. They are cgi files, so the needed data is provided to the controller. The function perform() is called. The form received contains a data field "operation". This operation is mapped to an action table which contains all the actions provided by that controller. The right action is then executed. When no action is available, an error page will be shown to the user.
View interface
The view contains the xsltransformer, which transforms a view container, using the xsl files of the layout module, to an actual xhtml webpage. This is the output that is shown to the user.
a. Process Interface
Interfaces to a process are described. The interfaces of processes are described using WSDL portTypes. We differentiate between processes with synchronous and asynchronous interfaces. In the case of a synchronous interface, the process implements one request-response operation in a portType. In this case the caller of the process waits for a synchronous response. From a process implementation point of view, the input and output node of the process point to the same portType and operation. The input node receives the request message and the output node replies with the response message.
In the case of an asynchronous interface, the process implements a one-way operation in a portType. In this case the caller of the process does not wait for a response. From a process implementation (more details in next section) point of view, the input node of the process points to a one-way operation in a portType. The input node receives the request message. The output node in this case is an invocation. It is a process client dependent callback, described by a oneway operation of another portType (see also the Process deploy scenarios topic for more details).
Interfaces to a process are described. The interfaces of processes are described using WSDL portTypes. We differentiate between processes with synchronous and asynchronous interfaces. In the case of a synchronous interface, the process implements one request-response operation in a portType. In this case the caller of the process waits for a synchronous response. From a process implementation point of view, the input and output node of the process point to the same portType and operation. The input node receives the request message and the output node replies with the response message.
In the case of an asynchronous interface, the process implements a one-way operation in a portType. In this case the caller of the process does not wait for a response. From a process implementation (more details in next section) point of view, the input node of the process points to a one-way operation in a portType. The input node receives the request message. The output node in this case is an invocation. It is a process client dependent callback, described by a oneway operation of another portType
Detailed Design a. Module Detailed Design
b. Data Detailed Design
