Software Design Document
Content
SOFTWARE DESIGN DOCUMENT
Bhargav Keremane Santosh Kumar G. Sutendra M.R.
December 13, 2009
Abstract
This document contains the Prision Maintainance Software Design Document (SDD), which describes what architecture is to be used andthe architectural design decisions that have to be made. This document is designed conform to the IEEE 1016-1987 standard for Software Design Documents.
Contents
1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 2 References 3 Decomposition description 3.1 Module decomposition 3.2 Concurrent process decomposition 3.3 Data decomposition 3.3.1 User 3.3.2 Group 3.3.3 Post 3.3.4 Category 3.3.5 File 4 Dependency description 4.1 Intermodule dependencies 4.1.1 Independent modules 4.1.2 Dependent modules 4.2 Interprocess dependencies 4.3 Data dependencies 4.3.1 Mapping Procedure 4.3.2 Additional Remarks 5 Interface description 5.1 Module interface 5.1.1 Communication 5.1.2 Database 5.1.3 Utility 5.1.4 Forum 5.1.5 Client 5.2 Process interface 5.2.1 Use Case 1: Reading the forum 5.2.2 Use Case 2: Posting a Reply 5.2.3 Use Case 3: Retrieve lost password 5.2.4 Use Case 4: Logging in
1 Introduction
1.1 Purpose
The following document is the design specification of our project Prision Maintainance. It contain: i. architectural design, and ii. detailed design. The architectural design gives the Decomposition description ,Dependency description and Interface description.
1.2 Scope
This Document consisting of architectural design and detailed design of project prison maintainance gives various conceptual models about the software being developed.These models spread about in the areas of Decomposition description, Dependency description and Interface description. Using these models the implementer can get a wholesome knowledge about project . They get better understanding of various modules and subsystems within the system and the relationships between them.Thus it provides a strong grounds on whose basis the implementer can get to know how the developed design can map on to various requirements. With these backgrounds a well defined algorithm can be developed. Apart from the implementer SDS can be used by the police department to get the keen understanding of the prision maintainance project.
1.3 Definitions, Acronyms and Abbreviations
Definitions • • • • • • • • • • • • • • • • • • • • • Police: Includes nontechnical part of police men like jailor, security etc. Male section: Part of prison dedicated for male prisoners Female section: Part of prison dedicated for female prisoners
Visitors : People (non prisoners)related to prisoner. Investigation: Investigation department . Hospital: Government hospital in city. Module: Group of related activities. Sub module: Sub set of module which also performs set of related works. Name : Complete name of prisoner as in FIR. Height : Height of prisoner . Weight : Weight of a prisoner. Address: Prisoner residential address. Description: Description of crime Place : Place where crime had occurred Dates : Includes date of crime and date of judgment and date of release. Cell no: Cell number of prisoner Attendance : Attendance of prisoner for a work if any he is assigned. Earnings : Earnings of a prisoner at present Belongings : Belongings of a prisoner if any while imprisonment Name : Here name refers to name of a visitor not prisoner. Relation: What is the relation between visitor and prisoner.
Acronyms and Abbrevations
• • • •
FIR: First Investigation Report. PID: Prisoner identification number. BG: Blood group SRS : Software Requirements Specification.
References
The applicable IEEE standards are published in “IEEE Standards Collection,” 2001 edition. IEEE(1016-1987) standard for Software Design Documents. Kolkata police website. Policeone.com Prison break serial.
Decomposition description
The following description gives the idea on how the software is modularized.Here modularization is done ,on the basis of various tasks performed by the software.
3.1 Module decomposition
Conceptually the program can be divided in these modules: 3.1.1Database Maintainance module : This module serves as the core of the software and it will store entire data of the prison.Which includes information corresponding to prisoners,policemen and constructional details of the prison.
3.1.2Network module : This module can be further parted into two submodules: 1..In-department module: This module of the software produces the communication network between all the system within the department. 2.Out-department module: This module of the software produces the communication network between the department and the outside world via internet.
3.1.3Data security module: This module of the software enables the data retrieval from the database along with a password security and hence protects the ‘prison data’ from being misused.
3.2 Concurrent process decomposition
The project will contain two distinct processes : 3.2.1 Database updating process: This process within the software will update the data.It either inserts or deletes or modifies the existing data in the database .Thus this process will be running continuously and concurrentiy along with the inter module communication process .
3.2.2 Inter-module communication process: This process brings in the communication between the three existing modules of the software ,which is a key aspect .
For instance : suppose there occurs a sudden and a fatal health problem of a prisoner. First thing ,since this news is under emergency ,it is to be delivered to all concerened officers of the prison .this thing can be done using ‘in department network module’ of the software . Secondly, to handle this situation ,there is a need to know the entire details of the prisoner (Ex: health background) and this details can be retrieved by ‘database maintenance module’. Thus the whole thing can be worked out if there is a connection between the above two modules and this can be achieved by ‘Inter module communication process’.
3.3 Data decomposition
3.3.1 Prisoners: PriName,PID,Address,BG,Sex,decpn_of_crime,place_of_crime,date_of_crime, FIRNO 3.3.2: Police: i. technical :TecName, ranks, salary, TID, prisoners_caught ii. Non technical:NonTecname,salary,NTID, shifts, 3.3.3. Construction details of prison: prison_location, constrn_year,area,no_of_cells,Fence_height,no_of_gates, head_of_prison.
4 Dependency description
4.1 Intermodule dependencies 4.1.1 Independent modules:
3.1.1Database Maintainance module:- This module relies on the presence of a mysqlclient and the availability of the DvMySQL library. 3.1.3Data security module:This module uses “Extreme password generator pro “set up by Maro’s tools.
4.1.2 Dependent modules:
3.1.2Network module:-It establishes communication,within and outside prison with the help of database module and security module.hence it depends on the above models.
4.2 Interprocess dependencies: 4.1.1 Independent process s: 3.2.1 Database updating process:This module relies on the presence of MYSQL client. 4.1.2 Dependent process: 3.2.2 Inter module communication process:This is a dependent process and depends on data updating process so that it can keep up the consistency while communicating between the various modules.
4.3 Data dependencies:
PRISONER:
Pri_Na me PID Addre ss BG Decpn_of_crii me Place_of_cri me Date FIR_N o
POLICE:
1.Technical: Tec_Name Rank Salary TID Prisoners_Cau ght
2.Non-Technical: Non_Tec_Name Salary NTID Shifts
CONSTRUCTION DETAILS OF PRISON:
Prison_L oc
Constrn_Y ear
Are No_of_Ce a lls
Fence_Hei ght
No_of_Gat es
Head_of_Pris on
5 Interface description:
5.1 Module interface:
3.1.1Database Maintainance module: Display table(x):Display all the tuples in the table.here ‘x’ indicates the name of table to be displayed. Insert record_set (y, table):set of tuples can be inserted at once,helps in reconstruction of tables.here input ‘y’ indicates set of tuples and table indicates the table name.
3.1.2Network module:
1..In-department
module: In_department(service): This function checks whether the server is connected to internet.if the server is not connected, it produces the network between the local connected systems.
2.Out-department module :Out_department(service):this function uploads the most recent informations into the website,if and only if the server connected to internet.
3.1.3Data security module take_password(user)takes the password and store it in the temporary variable.
Implement_query(query): it implements the required query if the password is authenticated. grantlevel(quiery): It gives the priority level of the access for a user. validate(passwd): It verifies the entered password with the assigned passwordof the user.
continue validate():It denies for the intake of the password,if the user has previously given three improper password.
5.2 Process interface: Use case 1: Admission of prisoner The crime details ,personel details is put in the database of the software. The software stores the details in its repository. The software compares the input details with the previously existing details .If the previous record matches with input then it returns a status that details are already present.
Prison management
office
repository
details details update details
update details
conformation message Use case 2: Term completion of prisoner: The software returns the term completion status of the when the system date matches with the term completion date of the prisoner. Sw put all the details of the prisoner in the in a separate backup file as his info is not frequently updated.
Sequence Diagram
6. Detailed design
6.1 Module detailed design
3.1.1Database Maintainance module:
Display table(x) loop(i:=1 to number of tuples in x)do write tuples;
//procedure to insert set of tuples Insert record_set (y, table) loop(i:=0 to | y|) do if(attributes of y[i] ≠ attributes of table) then write “INVALID INPUTS” else do add(tuple y[i] ) to table; end if
end loop
3.1.2Network module:
1..In-department
module:
In_department(service) If(server is not concerned with the internet updates) do Implement(query) //Service requested is carried out between connected systems else return false; endif
2.Out-department module Out_department(service) If(server is connected to internet updates) do append restricted updates to current updates; else
return false; end if
3.1.3Data security module //take password of specific user take_password(user) tempid:=user; temppasswd:=password entered;
//implement the security check for every access of important data Implement_query(query) x:=level(user); y:=grantlevel(quiery) if(y>x)do passwd:=take_password(user);
if(validate(passwd)=true)
do
implement the appropriate query ; else write “password error” take_password(user); continue validate(); if(invalidpassword_entry=3) do invaliduserinfo=userid; exit; end if
endif else implement the query; end if
Bhargav Keremane Santosh Kumar G. Sutendra M.R.
December 13, 2009
Abstract
This document contains the Prision Maintainance Software Design Document (SDD), which describes what architecture is to be used andthe architectural design decisions that have to be made. This document is designed conform to the IEEE 1016-1987 standard for Software Design Documents.
Contents
1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 2 References 3 Decomposition description 3.1 Module decomposition 3.2 Concurrent process decomposition 3.3 Data decomposition 3.3.1 User 3.3.2 Group 3.3.3 Post 3.3.4 Category 3.3.5 File 4 Dependency description 4.1 Intermodule dependencies 4.1.1 Independent modules 4.1.2 Dependent modules 4.2 Interprocess dependencies 4.3 Data dependencies 4.3.1 Mapping Procedure 4.3.2 Additional Remarks 5 Interface description 5.1 Module interface 5.1.1 Communication 5.1.2 Database 5.1.3 Utility 5.1.4 Forum 5.1.5 Client 5.2 Process interface 5.2.1 Use Case 1: Reading the forum 5.2.2 Use Case 2: Posting a Reply 5.2.3 Use Case 3: Retrieve lost password 5.2.4 Use Case 4: Logging in
1 Introduction
1.1 Purpose
The following document is the design specification of our project Prision Maintainance. It contain: i. architectural design, and ii. detailed design. The architectural design gives the Decomposition description ,Dependency description and Interface description.
1.2 Scope
This Document consisting of architectural design and detailed design of project prison maintainance gives various conceptual models about the software being developed.These models spread about in the areas of Decomposition description, Dependency description and Interface description. Using these models the implementer can get a wholesome knowledge about project . They get better understanding of various modules and subsystems within the system and the relationships between them.Thus it provides a strong grounds on whose basis the implementer can get to know how the developed design can map on to various requirements. With these backgrounds a well defined algorithm can be developed. Apart from the implementer SDS can be used by the police department to get the keen understanding of the prision maintainance project.
1.3 Definitions, Acronyms and Abbreviations
Definitions • • • • • • • • • • • • • • • • • • • • • Police: Includes nontechnical part of police men like jailor, security etc. Male section: Part of prison dedicated for male prisoners Female section: Part of prison dedicated for female prisoners
Visitors : People (non prisoners)related to prisoner. Investigation: Investigation department . Hospital: Government hospital in city. Module: Group of related activities. Sub module: Sub set of module which also performs set of related works. Name : Complete name of prisoner as in FIR. Height : Height of prisoner . Weight : Weight of a prisoner. Address: Prisoner residential address. Description: Description of crime Place : Place where crime had occurred Dates : Includes date of crime and date of judgment and date of release. Cell no: Cell number of prisoner Attendance : Attendance of prisoner for a work if any he is assigned. Earnings : Earnings of a prisoner at present Belongings : Belongings of a prisoner if any while imprisonment Name : Here name refers to name of a visitor not prisoner. Relation: What is the relation between visitor and prisoner.
Acronyms and Abbrevations
• • • •
FIR: First Investigation Report. PID: Prisoner identification number. BG: Blood group SRS : Software Requirements Specification.
References
The applicable IEEE standards are published in “IEEE Standards Collection,” 2001 edition. IEEE(1016-1987) standard for Software Design Documents. Kolkata police website. Policeone.com Prison break serial.
Decomposition description
The following description gives the idea on how the software is modularized.Here modularization is done ,on the basis of various tasks performed by the software.
3.1 Module decomposition
Conceptually the program can be divided in these modules: 3.1.1Database Maintainance module : This module serves as the core of the software and it will store entire data of the prison.Which includes information corresponding to prisoners,policemen and constructional details of the prison.
3.1.2Network module : This module can be further parted into two submodules: 1..In-department module: This module of the software produces the communication network between all the system within the department. 2.Out-department module: This module of the software produces the communication network between the department and the outside world via internet.
3.1.3Data security module: This module of the software enables the data retrieval from the database along with a password security and hence protects the ‘prison data’ from being misused.
3.2 Concurrent process decomposition
The project will contain two distinct processes : 3.2.1 Database updating process: This process within the software will update the data.It either inserts or deletes or modifies the existing data in the database .Thus this process will be running continuously and concurrentiy along with the inter module communication process .
3.2.2 Inter-module communication process: This process brings in the communication between the three existing modules of the software ,which is a key aspect .
For instance : suppose there occurs a sudden and a fatal health problem of a prisoner. First thing ,since this news is under emergency ,it is to be delivered to all concerened officers of the prison .this thing can be done using ‘in department network module’ of the software . Secondly, to handle this situation ,there is a need to know the entire details of the prisoner (Ex: health background) and this details can be retrieved by ‘database maintenance module’. Thus the whole thing can be worked out if there is a connection between the above two modules and this can be achieved by ‘Inter module communication process’.
3.3 Data decomposition
3.3.1 Prisoners: PriName,PID,Address,BG,Sex,decpn_of_crime,place_of_crime,date_of_crime, FIRNO 3.3.2: Police: i. technical :TecName, ranks, salary, TID, prisoners_caught ii. Non technical:NonTecname,salary,NTID, shifts, 3.3.3. Construction details of prison: prison_location, constrn_year,area,no_of_cells,Fence_height,no_of_gates, head_of_prison.
4 Dependency description
4.1 Intermodule dependencies 4.1.1 Independent modules:
3.1.1Database Maintainance module:- This module relies on the presence of a mysqlclient and the availability of the DvMySQL library. 3.1.3Data security module:This module uses “Extreme password generator pro “set up by Maro’s tools.
4.1.2 Dependent modules:
3.1.2Network module:-It establishes communication,within and outside prison with the help of database module and security module.hence it depends on the above models.
4.2 Interprocess dependencies: 4.1.1 Independent process s: 3.2.1 Database updating process:This module relies on the presence of MYSQL client. 4.1.2 Dependent process: 3.2.2 Inter module communication process:This is a dependent process and depends on data updating process so that it can keep up the consistency while communicating between the various modules.
4.3 Data dependencies:
PRISONER:
Pri_Na me PID Addre ss BG Decpn_of_crii me Place_of_cri me Date FIR_N o
POLICE:
1.Technical: Tec_Name Rank Salary TID Prisoners_Cau ght
2.Non-Technical: Non_Tec_Name Salary NTID Shifts
CONSTRUCTION DETAILS OF PRISON:
Prison_L oc
Constrn_Y ear
Are No_of_Ce a lls
Fence_Hei ght
No_of_Gat es
Head_of_Pris on
5 Interface description:
5.1 Module interface:
3.1.1Database Maintainance module: Display table(x):Display all the tuples in the table.here ‘x’ indicates the name of table to be displayed. Insert record_set (y, table):set of tuples can be inserted at once,helps in reconstruction of tables.here input ‘y’ indicates set of tuples and table indicates the table name.
3.1.2Network module:
1..In-department
module: In_department(service): This function checks whether the server is connected to internet.if the server is not connected, it produces the network between the local connected systems.
2.Out-department module :Out_department(service):this function uploads the most recent informations into the website,if and only if the server connected to internet.
3.1.3Data security module take_password(user)takes the password and store it in the temporary variable.
Implement_query(query): it implements the required query if the password is authenticated. grantlevel(quiery): It gives the priority level of the access for a user. validate(passwd): It verifies the entered password with the assigned passwordof the user.
continue validate():It denies for the intake of the password,if the user has previously given three improper password.
5.2 Process interface: Use case 1: Admission of prisoner The crime details ,personel details is put in the database of the software. The software stores the details in its repository. The software compares the input details with the previously existing details .If the previous record matches with input then it returns a status that details are already present.
Prison management
office
repository
details details update details
update details
conformation message Use case 2: Term completion of prisoner: The software returns the term completion status of the when the system date matches with the term completion date of the prisoner. Sw put all the details of the prisoner in the in a separate backup file as his info is not frequently updated.
Sequence Diagram
6. Detailed design
6.1 Module detailed design
3.1.1Database Maintainance module:
Display table(x) loop(i:=1 to number of tuples in x)do write tuples;
//procedure to insert set of tuples Insert record_set (y, table) loop(i:=0 to | y|) do if(attributes of y[i] ≠ attributes of table) then write “INVALID INPUTS” else do add(tuple y[i] ) to table; end if
end loop
3.1.2Network module:
1..In-department
module:
In_department(service) If(server is not concerned with the internet updates) do Implement(query) //Service requested is carried out between connected systems else return false; endif
2.Out-department module Out_department(service) If(server is connected to internet updates) do append restricted updates to current updates; else
return false; end if
3.1.3Data security module //take password of specific user take_password(user) tempid:=user; temppasswd:=password entered;
//implement the security check for every access of important data Implement_query(query) x:=level(user); y:=grantlevel(quiery) if(y>x)do passwd:=take_password(user);
if(validate(passwd)=true)
do
implement the appropriate query ; else write “password error” take_password(user); continue validate(); if(invalidpassword_entry=3) do invaliduserinfo=userid; exit; end if
endif else implement the query; end if
