Project: LICOM
SOFTWARE DESIGN SPECIFICATION
Date of preparation: Jan 30, 2005
Prepared by:
Sowmya MS
Pradeep V
1. Introduction
1.1 Purpose of this document
The following SDS document specifies the structure and design of LICOM.
The various proposed or actual designs for every module in LICOM are discussed clearly, thereby forming the essential blue-print for coding the software.
The outcome of the SDS is the modularity that has been achieved, which will help in organizing code and determining better solutions wherever applicable.
1.2 Scope of the development project
LICOM is a compression/de-compression tool that sits in-between the browser and content from the server. It aims to facilitate compression of ASCII text, RTF, DOC, PDF, HTML and similar file types upto 550% and GIF, JPG, BMP and similar image file types upto 70% of their original size.
1.3 Acronyms and abbreviations
- LICOM: Linux Compression / De-compression
- LICOMed: A file is said to be LICOMed if it has been compressed by the LICOM tool/agent (at the server-end)
- deLICOMed: A file is deLICOMEd when it is de-compressed by the LICOM tool/agent (at the client-end)
- Client: A computer connected to a network that receives data from a server
- Server: A computer on a network that services several other clients
- Request: A proposal for data from a client to a server
- Response: The process by which the server sends the requested data to the client.
- Client-side user: A person who uses the computer at the client-end
- Server Administrator: A person who installs and maintains software on the server and whose primary job is to ensure that the server is always up and is effectively functioning, without any undesired outside interference.
- User: Refers to both Client-side user and Server Administrator, unless specified otherwise
1.4 References
General study of existing Image compression technologies:
JPG Format FAQ:
-
HTTP Proxy Servers:
-
HTTP protocol specification:
-
HTTP protocol working:
-
Socket Programming in C:
http://www.ecst.csuchico.edu/~beej/guide/net/html/intro.html
1.5 Overview of this document
Section 1 previews this document as a whole
Section 2 presents the structure of LICOM, the various user interfaces that come with it, and the relationship between the various modules.
Section 3 illustrates each LICOM module and throws more light on its design specification
Section 4 describes existing solutions that LICOM re-used, and also describes how LICOM modules can be re-used for other purposes.
Section 5 depicts design issues
Section 6 is the appendices section
2. System architecture description
The following section depicts the architectural organization of the entire LICOM application
2.1 Overview of modules / components
There are 3 basic modules:
- LCM Compressor/De-Compressor - Logic to compress and de-compress files
- LCM ControlBox - Used to set user-options
- LCM Interfacer - Necessary interfacing logic to connect LICOM in-between the network port and the internet browser (or) server
Each of these modules are further split into two more sub-modules:
- A Client version
- A Server version
2.2 Structure and relationships
The actual structure (module-wise) can be realized by the following figures:
Server-side components/modules:
Client-side components/modules:
2.3 User interface issues
There are two user-interfaces available. Both of them can be represented with the following figure:
These interfaces are not mandatory for the proper functioning of LICOM, but are useful for advanced users who wish to customize LICOM.
The interfaces are:
- LCM Client ControlBox
- LCM Server ControlBox
Both the interfaces are just a single-page display form that will update configuration files (written in XML). These files will be read by the LICOM system when LICOM starts up.
Few options provided in these interfaces are:
- Disabled Mode - On/Off
- Choose File types applicable - ASCII text, RTF, DOC, PDF, HTML, GIF, JPG, BMP
- Security Features
- Other Features
3. Detailed description of components
All components (modules) in the LICOM application are discussed in this section
3.1 Component template description
Following is the template upon which the rest of the section will be based:
| Identification | The unique name for the component in the system. |
| Type | A module, a subprogram, a data file, a control procedure, a class, etc |
| Purpose | Function and performance requirements implemented by the design component, including derived requirements. Derived requirements are not explicitly stated in the SRS, but are implied or adjunct to formally stated SDS requirements |
| Function | What the component does, the transformation process, the specific inputs that are processed, the algorithms that are used, the outputs that are produced, where the data items are stored, and which data items are modified. |
| Subordinates | The internal structure of the component, the constituents of the component, and the functional requirements satisfied by each part. |
| Dependencies | How the component's function and performance relate to other components. How this component is used by other components. The other components that use this component. Interaction details such as timing, interaction conditions (such as order of execution and data sharing), and responsibility for creation, duplication, use, storage, and elimination of components. |
| Interfaces | Detailed descriptions of all external and internal interfaces as well as of any mechanisms for communicating through messages, parameters, or common data areas. All error messages and error codes should be identified. All screen formats, interactive messages, and other user interface components should be given here. |
| Resources | A complete description of all resources (hardware or software) external to the component but required to carry out its functions. Some examples are internet connection, databases, memory, CPU requirements if any, I/O channels, printers, cdwriters, libraries, and system services etc., |
| Processing | The full description of the functions presented in the Function subsection. Pseudocode can be used to document algorithms, equations, and logic. |
| Data | For the data internal to the component, describe the representation method, initial values, use, semantics, and format. |
3.2 LCM Compressor
| Identification | LCM Compressor |
| Type | LICOM System Module present at the middle-level of the system architecture |
| Purpose | This module is responsible for compressing data so that it is in the compressed LCM format |
| Function | The component/module will be called by a higher-level module. It compresses data and returns the compressed data to the higher-level module. Input: A File Output: Compressed LCM data |
| Subordinates | N/A |
| Dependencies | The module is called by the higher-level LCM Server Interfacer module. Therefore, this module reads data from the higher-level module and returns data to it. |
| Interfaces | N/A |
| Resources |
|
| Processing | N/A |
| Data | The external data representation format is XML. Compression tables are represented in XML. |
3.3 LCM De-Compressor
| Identification | LCM De-Compressor |
| Type | LICOM System Module present at the middle-level of the system architecture |
| Purpose | This module is responsible for de-compressing data so that the compressed LCM format can be converted back to the original file-format |
| Function | The component/module will be called by a higher-level module. It de-compresses data and returns the original data to the higher-level module. Input: A compressed LCM File Output: Original file |
| Subordinates | N/A |
| Dependencies | The module is called by the higher-level LCM Client Interfacer module. Therefore, this module reads data from the higher-level module and returns data to it. |
| Interfaces | N/A |
| Resources |
|
| Processing | N/A |
| Data | The external data representation format is XML. De-compression tables are represented in XML. |
3.4 LCM Client ControlBox
| Identification | LCM Client ControlBox |
| Type | User-Interface Module present at an isolated level away from the internal system architecture |
| Purpose | To set customized options for advanced users |
| Function | The component/module will be run by the user whenever required. It will let the user choose from a pool of options and write out these new options as a configuration file Input: User-options Output: Configuration file |
| Subordinates | N/A |
| Dependencies | The LCM Client Interfacer will depend on the output produced by this module, though not mandatory |
| Interfaces | A simple 1-page user interface form |
| Resources |
|
| Processing | N/A |
| Data | The external data representation format is XML. Configuration files are represented in XML. |
3.5 LCM Server ControlBox
| Identification | LCM Server ControlBox |
| Type | User-Interface Module present at an isolated level away from the internal system architecture |
| Purpose | To set customized options for advanced users |
| Function | The component/module will be run by the user whenever required. It will let the user choose from a pool of options and write out these new options as a configuration file Input: User-options Output: Configuration file |
| Subordinates | N/A |
| Dependencies | The LCM Server Interfacer will depend on the output produced by this module, though not mandatory |
| Interfaces | A simple 1-page user interface form |
| Resources |
|
| Processing | N/A |
| Data | The external data representation format is XML. Configuration files are represented in XML. |
3.6 LCM Client Interfacer
| Identification | LCM Client Interfacer |
| Type | LICOM System Module present at the highest-level of the system architecture |
| Purpose | To interface network connection with the application, and perform header-analysis for implementing LICOM functionality |
| Function | This module interfaces the application with the network connection. If any request HTTP headers pass out of the client, it appends a compression-request header. It scans incoming HTTP response headers and looks for a compressed-header. If it sees one, it calls the LCM De-Compression module and routes the thus de-compressed data to the browser |
| Subordinates | N/A |
| Dependencies | It depends on LCM De-Compressor to perform de-compression |
| Interfaces | N/A |
| Resources |
|
| Processing | N/A |
| Data | The data handled is HTTP headers, native-format data, LCM format data and XML |
3.7 LCM Server Interfacer
| Identification | LCM Server Interfacer |
| Type | LICOM System Module present at the highest-level of the system architecture |
| Purpose | To interface network connection with the application, and perform header-analysis for implementing LICOM functionality |
| Function | This module interfaces the application with the network connection. It reads HTTP request headers and looks for a compression-request. If it gets one, it calls the LCM Compression module, sets an appropriate compressed-header and sends the response back to the client |
| Subordinates | N/A |
| Dependencies | It depends on LCM Compressor to perform compression |
| Interfaces | N/A |
| Resources |
|
| Processing | N/A |
| Data | The data handled is HTTP headers, native-format data, LCM format data and XML |
4. Reuse and relationships to other products
The following components of LICOM can be re-used by any other software application:
- XML Read/Write:
- Compressor/De-compressor:
This is an utility which reads simple XML data into a program for processing. It also writes out program-data as a XML file (say, a configuration file). This will be useful for an application that needs to represent its data in a standard format (ie. XML), for the sake of later processing
The basic compression and de-compression algorithms can be used as a general utility to compress files into the LCM format, and de-compress them for later use. The supported file-formats are as documented in the appropriate sections
The algorithms for image compression MAY be borrowed from another open-source algorithm, if the current research to develop our own algorithm is not successful.
5. Design decisions and tradeoffs
The following design decisions are considered to be worth a mention:
- Logically Stand-alone Components:
- To support the cause of these algorithms to be used as a general utility, rather than for LICOMs original purpose
- To support the cause of these algorithms to be easily re-usable for other programmers
- Use of XML:
The compression/de-compression algorithms are abstracted from the rest of the LICOM implementation. This was for two major purposes:
XML is used as the data-format for both configuration files and internal data. This is in conformance to the needs of the industry, thereby allowing easier re-use of our code, and for providing better transparency.
6. Pseudocode for components
The following is the pseudo-code for all LICOM components/modules:
- LCM Client ControlBox
- LCM Server ControlBox
- LCM Server Interfacer
- LCM Client Interfacer
- LCM Compressor
- LCM De-Compressor
At Startup: Read settings.xml file Update settings based on that data IF Updation of settings is requested Convert settings into XML Write out the XML file as settings.xml ENDIF IF Default options are requested Load the default.xml file Update settings based on that data ENDIF
At Startup: Read settings.xml file Update settings based on that data IF Update is requested Convert settings into XML Write out the XML file as settings.xml ENDIF IF Default options are requested Load the default.xml file Update settings based on that data ENDIF
Use Network Connection
Read request from client
IF licom_compr_request HTTP header is not present
Abandon all operations for this request, just route the request through
ELSE
Load the requested file and determine its data-type
IF file can be compressed
Load config file
Set appropriate HTTP headers
Pass control to LCM Compressor module
ENDIF
Route out data towards client
ENDIF
Use Network Connection
IF request is being sent
ADD licom_compr_request HTTP header
ENDIF
IF response is being read
Read HTTP headers
IF licom_compressed HTTP header is not present
Abandon all operations for this response, just route the response through
ELSE
Pass control to LCM De-Compressor module
ENDIF
Route in data towards browser
ENDIF
Read data (file and its format) from higher module (LCM Server Interfacer) Load the appropriate compression table Perform compression Return compressed data to higher module (LCM Server Interfacer)
Read data (file and its format) from higher module (LCM Client Interfacer) Load the appropriate de-compression table Perform de-compression Return de-compressed data to higher module (LCM Client Interfacer)
7. Appendices
N/A