Software Design Document

E.W.
Liner Charts & Publications Pte Ltd

Document Name Doc # Version # Date
SOFTWARE DESIGN DOCUMENT EWL-SWQD-009 1.0 01-11-2021

Software Design Document

E‐Logbooks

Document Revision History
Prepared
Version Date Reviewed by Approved by Summary of Change
by
1.0 01‐11‐2021 JNV. Tataji Suranjan Naidu Capt Kumar Document Creation

This document or parts thereof, may not be copied or disclosed to third party without the written Page 1 of 83
permission from the management of the company.
©E.W. Liner Charts & Publications Pte Ltd
E.W. Liner Charts & Publications Pte Ltd
Contents

1. INTRODUCTION .................................................................................................................... 3
1.1 PURPOSE .................................................................................................................................. 3
1.2 SUMMARY ................................................................................................................................ 3
1.3 HARDWARE REQUIREMENTS ....................................................................................................... 3
1.4 SOFTWARE REQUIREMENTS ........................................................................................................ 3
2. ARCHITECTURE ..................................................................................................................... 4
2.1 REQUIREMENTS ......................................................................................................................... 4
2.2 RISKS INVOLVED ........................................................................................................................ 4
2.3 DECISION ANALYSIS .............................................................................................................. 4
2.4 PROPOSED ARCHITECTURE ..................................................................................................... 5
3. HIGH LEVEL DESIGN.............................................................................................................. 7
3.1 LEVEL 0 DESIGN DESCRIPTION ..................................................................................................... 7
3.2 DESIGN ATTRIBUTES .............................................................................................................. 8
3.3 REUSE ................................................................................................................................. 9
3.4 BUILD STRATEGY .................................................................................................................. 9
3.5 INTERFACE MANAGEMENT ..................................................................................................... 9
4. PRESENTATION LAYER ....................................................................................................... 11
4.1 SCREENS................................................................................................................................. 11
4.2 REPORTS ........................................................................................................................... 16
5. BUSINESS LAYER ................................................. ERROR! BOOKMARK NOT DEFINED.
6. DATABASE LAYER ............................................................................................................... 82
7. DETAILED DESIGN............................................................................................................... 83
7.1 ENTITY 1 DESCRIPTION ............................................................................................................. 83
7.2 ENTITY 2 DESCRIPTION ............................................................................................................. 83
1. Introduction
1.1 Purpose

 The e‐logbook software will provide a digital platform which will simplify data entry,
increase data reliability & storage. It will improve compliance with Flag State authority
requirements and ensure all required information is recorded properly.

 Specify the intended audience ‐ Ship owning & Ship management companies
1.2 Summary
This document describes the detailed architectural design for the system. It specifies all
known components needed to deliver a complete system.
1.3 Hardware Requirements
The following are all the hardware requirements needed to run the system. Include server
and client configurations.
Hardware requirement for client:
Intel Core i3 and above
Minimum RAM is 8GB DDR3
Minimum HDD is 160 GB
Display properties are 24‐bit color depth
Screen resolution 1024x768 recommended minimum at normal size (96 dpi)

Server requirements:
To communicate with EWL Data Server client required either email or internet connectivity
and minimum transmission data limit of 5 MB.
1.4 Software Requirements
The following are the list of all software used to develop the system (Visual Basic, Visual
Interdev, SQL Server, etc) along with any other software necessary for the system to
function (MS Excel, True DB Grid, Internet Explorer, etc).

1. Visual Studio
2. SQLite studio 3.3
3. SAP Crystal report.
4. SQL Server.
2. Architecture
This section describes the selection of architecture for the proposed solution and rationale
behind selection of the architecture.

N‐Tier Architecture
 A number of different layers are defined with each layer performing a well‐defined
set of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
 At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system interfacing
(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.

Reasons:
Simple and fast for a lower number of users due to fewer processes and fewer tiers;
maintenance and deployment easy. And it meets the application requirement.
2.1 Requirements
The e‐logbook software should generate Electronic Logbooks that meet all Flag State audit & survey
requirements of the flag state under which the vessel is registered.
2.2 Risks Involved
Application side Risks
The end user application is a standalone. Hence, they must sync the data immediately once
the operation is completed. If not in any case if the system crashes, we will lose the latest
operational updates.
Server‐side Risk
If any Server down time with any reason that time the user unable sync the data.

2.3 Decision Analysis ‐ NA
Record the various design issues related to architecture in order to meet the above‐
mentioned requirements and overcome the above‐mentioned risks

Requirements Possible alternatives Rationale behind selecting the
best alternative

2.4 Proposed architecture
Describe in detail the proposed architecture along with the rationale behind selecting this
architecture.

N‐Tier Architecture
 A number of different layers are defined with each layer performing a well‐defined
set of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
 At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system interfacing
(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.

Reasons:
Simple and fast for a lower number of users due to fewer processes and fewer tiers;
maintenance and deployment easy.

2.4.1 Life Cycle Model
Describe the preferred life cycle model with impact of the proposed architecture at various
phases of the software development

Agile methodology
2.4.2 Robustness ‐ NA
Describe the robustness of the proposed architecture in terms of withstanding future
enhancements using the same architecture.
2.4.3 Technology
Describe the technology compatible with the proposed architecture as well as the
technological constraints

Framework: DotNet Framwork 4.7.2,
Language: C#
Front End (UI): WPF
Reporting: Crystal report
Database: SQLite.
Data export: JSON
2.4.4 Impact Analysis ‐ NA
Carry out an impact analysis of the proposed architecture on cost, schedule, performance
and risk

2.4.5 Detailed Design convention ‐ NA
Describe details related to pseudocode, program specification etc. that forms the basis for
carrying out detailed design
3. High Level Design
3.1 Level 0 Design Description

 This section shall contain (a) the Software System Context definition and (b) the
Software System Architecture definition as defined in the Design Procedure.
 The description of the external entities’ attributes shall be limited by the relevance that
these attributes have towards the software design and description. In lieu of a complete
description, reference can be made to relevant documentation of the concerned
software entity, e.g., OS Programmer’s Manual.

3.1.1 Decomposition Description ‐ NA
Include here the Decomposition descriptions for the various Modules / Subsystems

3.1.1.1 Concurrent Process Decomposition ‐ NA

Include here the Process Decomposition descriptions for the various Processes

3.1.1.2 Data Decomposition ‐ NA
Include here the Data Decomposition descriptions for the Data Entities

3.1.2 Dependency Description ‐ NA
Include here the Dependency descriptions for the following:
a. Intermodule / Subsystem Dependencies
b. Interprocess dependencies
c. Data Dependencies

3.1.3 Interface Description ‐ NA
Include here the Interface descriptions for the various Module / Subsystems

3.1.3.1 Process Interfaces ‐ NA
Include here the Interface descriptions for the various Processes

3.2 Design Attributes
This section describes the various design attributes and details of including these attributes
in the software design. (Note that all of these attributes may not be required for all software
development. Some attributes other than those listed below would be required for a specific
product)

Design Expected criteria Component / Module / Methodology
Attributes (Qualitative or by which the criteria would be met
Quantitative)
Clarity
Maintainability Completely customize so Dotnet framework 4.7.2
can be modified and n‐tier architecture.
customized easily
Portability Can be run on multiple OS Used dot net framework
with different screen Responsive design throughout
resolution application
Reliability System shall be completely No external source to interrupt
operational at least 100% of system.
the time
Accuracy
Security Used
1.Encryption of passwords Encryption with cypher key and SHA
2.Prevention of SQL algo in login and different part of
injection. application
3. Restrictions of user access
by
authentication/authorization
Usability User should be able to use Dashboard and Role to assignment
the system in his job after
very short training
Dashboard provided to
navigate and access
different modules with
secure way.
Functionality
3.3 Reuse ‐ NA
This section describes the interface requirements and design considerations that needs to be
followed when reusing a software component.

Reuse To be interfaced Interface requirements that needs to
Component with (affected be considered
component and
module)

3.4 Build Strategy ‐ NA
Describe using the table below (additional diagrams can also be used to represent this) the
interface mapping between components (or modules) and strategy of building the same.

Component Interfaces with Build Script Sequence for Complier /
(or Module) other details building the Environment and
Name component or component Resources required
module name or module for integrating the
component (or
module)

3.5 Interface Management ‐ NA

In this section describe the action items for interface updating and for maintaining
compatibility of the interfaces throughout the development cycle.

List down the entire interface related data required for reference by project team members
in this section.

The appearance and the behaviour of the interface, based on the Requirements Specification
in a way that resources for its implementation can be foreseen.
 This point is worth considering for interactive systems where the development of the
user interface is anticipated to be nontrivial.
 If the system under consideration does not have a user interface (e.g. a web service),
this step is simply ignored.
 For a system that has a user interface which poses no specific challenges, the user
interface can be considered simply as another feature of the system to be developed.

4. Presentation Layer
This section describes all the screens and reports needed to deliver all the functional
requirements. Include screen descriptions, screen shots, report descriptions and report
shots. The client should understand that the final product may not be exactly as listed here
but the functionality will stay the same. During coding, we may merge or separate screens to
achieve a nicer user interface and to promote reusability of components.
4.1 Screens
4.1.1 Login screen
Include screen shot here

Describe the purpose of the screen as to ensure the client and
Description developer agrees on its functionality.
To open application, need to enter valid user name and password.
Security Group List the security groups that may use the screen
Every user has assigned role and each role have multiple privileges (ex
can open create user screen)
Data Describe each field on the screen and how it is derived
Username and password derive from table of users and match
combination
Actions Describe each action that can be performed from this screen. This
usually involves command buttons, menu items, etc.
Exit: Exit button close application
Submit: submit button verify entered username and password

Dashboard

Assign Privilege
My Account
User Management

ORB 1 Group Screen

ORB1 Group A screen
View Summary
4.2 Reports

ORB1 Group B screen :Discharge of dirt ballast or cleaning water from fuel tanks
ORB1 Group B View Summary Screen
ORB1 Group C screen :Collection ,Transfer and disposal of oil residues(Sludge)

ORB1 Group D screen :Non‐Automatic starting of discharge overboard
ORB1 Group D View Summary Report
Orb-I Group-D Print Summary Screen

ORB1 Group E screen :Automatic starting of discharge overboard
ORB1 Group E View Summary Report
ORB1 Group E Print Summary Report

ORB1 Group F screen :Condition of the oil filtering equipment
ORB1 Group F View Summary Report
ORB1 Group F Print Summary Report

ORB1 Group G screen :Accidental or other exceptional discharge of oil
ORB1 Group G View Summary Report
ORB1 Group G Print Summary Report

ORB1 Group H screen :Bunkering of fuel or bulk lubricating oil
ORB1 Group H View Summary Report
ORB1 Group H Print Summary Report

ORB1 Group I screen :Additional operational procedures and general remarks
ORB1 Group I View Summary Report
ORB1 Group I Print Summary Report
ORB-II Group Screen
ORB-II Group -A :Loading of oil Cargo
ORB-II Group -A View Summary Screen
ORB-II Group-B :Internal Transfer of Oil Cargo
ORB-II Group-B View Summary Report
ORB-II Group C :Unloading of oil Cargo
ORB-II Group C View Summary Report
ORB-II Group-D :Crude oil washing
Orb-II Group-D View summary
ORB-II Group-E :Ballasting of cargo tanks
ORB-II Group-E View Summary
ORB-II Group-F :Ballasting of dedicated clean ballast (CBT tankers only)
ORB-II Group-F view summary
ORB-II Group-G:Cleaning of cargo tanks
ORB-II Group-G View Summary
ORB-II Group-H:Discharge of dirty ballast
ORB-II Group-H view summary
ORB-II Group-I:Discharge of water from slop tanks into the sea
ORB-II Group-I view summary
ORB-II Group-J Collection,transfer and disposal of residues and oily mixtures not other wise dealt with
ORB-II Group-J view summary
ORB-II Group-K Discharge of clean ballast contained in cargo tanks
ORB-II Group-K View summary
ORB-II Group-L :Discharge of ballast from dedicated clean ballast tanks
ORB-II Group-L View Summary
ORB-II Group-M:condition of oil discharge monitoring and control systems
ORB-II Group-M View Summary
ORB-II Group-N Accidental or other exceptional discharge of oil
ORB-II Group-N view Summary
ORB-II Group-O Loadig of ballast water
ORB-II Group-O view summary
ORB-II Group-P :Re-allocation of ballast water with in the ship
ORB-II Group-P :View Summary
ORB-II Group-Q :Ballast of water discharge to reception facility
ORB-II Group-Q view summary
Garbage Record Book-1
GRB-1 Screen 4.1.1
Preview 4.1.1
GRB-1 Screen 4.1.2
Preview 4.1.2
GRB-1 Screen 4.1.3
Preview 4.1.3
GRB-1 Screen 4.1.4
Preview 4.1.4
GRB-1 Report
Describe the purpose of the report as to ensure the client and
Display GRB 1 data for all 4 forms
Security Group List the security groups that may use the report
Data Describe each field on the report and how it is derived
Groupings Describe how the report should be grouped and/or sorted
GRB
Totals Describe the sub and grand totals needed on the report
Filters Describe any filter or selection criteria needed for the report. How is
this selection criteria entered?
From date and To date filtration
Export Formats Describe the export format of the report (print preview, printer, MS
Word, MS Excel, HTML, etc.)
print preview, printer, MS Word, MS Excel,CSV,PDF,XML
Frequency If this report should be run periodically, specify the frequency (Daily,
Weekly, Monthly, Quarterly, Yearly, On Demand)
On Demand
Garbage Record Book-2
GRB-2 Screen 4.1.1
Preview 4.1.1
GRB-2 Screen 4.1.2
Preview 4.1.2
GRB-2 Screen 4.1.3
Preview 4.1.3
GRB-2 4.1.4
Preview 4.1.4
Garbage recordbook 2 Report
4.2.1

Describe the purpose of the report as to ensure the client and
Display GRB 2 data for all 4 forms
Security Group List the security groups that may use the report
Data Describe each field on the report and how it is derived
Groupings Describe how the report should be grouped and/or sorted
GRB
Totals Describe the sub and grand totals needed on the report
Filters Describe any filter or selection criteria needed for the report. How is
this selection criteria entered?
From date and to date filtration.
Export Formats Describe the export format of the report (print preview, printer, MS
Word, MS Excel, HTML, etc.)
print preview, printer, MS Word, MS Excel, CSV, PDF, XML
Frequency If this report should be run periodically, specify the frequency (Daily,
Weekly, Monthly, Quarterly, Yearly, On Demand)
Daily or On Demand

Model GRB‐1 4.1.1
Object Cube strings
Description The metric cube we have to create in the GRB forms for entry in fields of estimated
garbage discharged Category. There is no degree symbol available in the coding
language so we had to create one for the fields of degree. eg (m³) and to store it in
the database we need to put the text value and insert it in the database.

In the image shown entries in the fields are only numbers without symbol.

In the image after entering fields for the results are converted to cube meter format and the
symbol is shown.


Model GRB‐1 4.1.1
Object Degree and minutes
Format
Description In the code to show for latitude and longitude we need to add and convert the
degree symbol for the degree field. There is no degree symbol in the code
language. Hence to create the degree symbol we need to convert and make some
formats. Degrees are in the format of latitude and longitude. Start & stop position
of the ship when any procedure is done should be recorded in the database
For eg 12°.
Create the minute format for minute field. This is not also available in coding
language to create so we need to make and convert the minute symbol. For eg 14ˈ.

In the image shown degree and minutes in the fields block when user enter details.

In the image shown preview result for the above entries which have degree and minute
symbol.

Model GRB View summary

Report
Object Fields data fetching
to database
Description View summary report is when a user enters all the details in the form and submits
the form. The preview page will show as below but the printed report will have to
be as per the required format. All the entered data is stored in the database and
shown in the view summary report page. Data of the form is saved date wise so
whenever user wants to see or print a report it can be achieved by entering the
date.

The preview page

View summary report for the GRB form.

Model Login Page
Object Password
Description Password and login details should be encrypted in the code. Login and Password
details are stored in the database and need to be encrypted by the code for
security purpose.


Model Assign Privilege
Object Assign role to user
Description Each user is assigned the log books he can access to enter information and the
privileges he has to create new users, new rules and entry of holding tank
information etc. This is done by ticking the available options. When a user logs in
only the assigned log books he is authorized to use will be accessible to him.

Define all of the objects necessary to support the presentation layer.
ORB‐I Group‐A
Model ORB‐1 Group‐A 4.1
Format
For eg 12°.

symbol.


Model ORB‐1 Group‐A

4.2
Object Cube strings
Description The metric cube we have to create in the GRB forms for entry in fields of estimated
garbage discharged Category. There is no degree symbol available in the coding
language so we had to create one for the fields of degree. eg (m³) and to store it in
the database we need to put the text value and insert it in the database.
In the image after entering fields for the results converted cube meter format shows the
symbol.
Model ORB‐1 Group‐A 4.1
Object Start and Stop Time

setting
Description In the code to show the stop time fields the input of start time fields are used and
as the reference.
For e.g. if start time is 4 hrs 15mins the stop time field entries can be done only
after the start time.
Those combo boxes are populating by using this business logic section
This logic has been implemented for all applicable sections like for 3.1,3.3,2 etc…

ORB‐I Group‐B
Model ORB‐1 Group‐B 6,7
Format
For eg 12°.
symbol.

Model ORB‐1 Group‐B 6,7
Object Radio Button

Operation
Description Entry fields can be enabled or disabled by using the Radio Buttons. If vessel is in
port, choosing the Port radio button will disable the Ship Position entry fields.

ORB‐I Group‐C
Model ORB‐1 Group‐C 12.1
Object Radio Button

Operation
Description If 12.1 is selected 12.2 12.3 12.4 should be disabled.


ORB‐I Group‐D
Model ORB‐1 Group‐D 14
Object Time Operation
as the reference.

Object Radio Button

operation, degree
minutes symbol
presentation
Description In this we implemented enabling and disabling of items if we select 15.1 other
items 15.2 15.3 items should disabled and vice versa

In the code to show for latitude and longitude we need to add and convert the
For eg 12°.
ORB‐I Group‐E
Model ORB‐1 Group‐E
16,17,18
Object Radio Button
operation, degree
minutes symbol
presentation
Description In the we implemented enabling and disabling of items if we select 16 remain
items 17 & 18should disable and vice versa

For eg 12°.
Model ORB‐1 Group‐E 17,18

setting
as the reference.
ORB-I Group-G,ORB-I group-H

Model ORB‐1 Group‐G,H
23,26
Object Radio Button
operation, degree
minutes symbol
presentation
Description In this we implemented enabling and disabling of items if we select Position radio
button port textbox items should disabled and vice versa

For eg 12°.
ORB‐II

ORB‐II Group‐A
Model ORB‐2 Group‐A 2,3
Object Cube strings
Description The metric cube we need to convert in the GRB forms for fields of estimated
amount discharged Category there is no degree symbol available in the coding
language so we had to create one for the fields of degree. eg (m³) to send it in the
database we need to put the text value and insert it in the database.
ORB‐II Group‐D
Object Radio Button

Operation
Description In this we implemented enabling and disabling of items if we select position then
the port text box is disabled and vice versa.

ORB‐II Group‐E
Model ORB‐2 Group‐E 18
Object Radio Button

operation, degree
minutes symbol
presentation
Description In this we implemented enabling and disabling of items if we select Position radio
button port textbox items should disabled and vice versa

For eg 12°.
Model ORB‐2 Group‐E 19.2

setting
as the reference.
Model ORB‐2 Group‐G 28
Object Radio Button

Operation
Description In this we implemented enabling and disabling of items if we select position then
the port text box is disabled and vice versa.

Model ORB‐2 Group‐I 42,43
Object Radio Button

Operation
Description In this we implemented enabling and disabling of items. If we select item 42 item
then 43 should disabled and vice versa.

Model ORB‐2 Group‐J 57
Object Radio Button

Operation
Description In this we implemented enabling and disabling of items if we select 57.1 item
57.2,57.3,57.4 Items are disabled and vice versa.

Model ORB‐2 Group‐Q 85
Object Date conversion
Description Implemented Date format logic to get the required date format

The format of string will displayed as like below Image
5. Business Layer ‐ NA
Define all of the objects necessary to support the presentation layer.

6. Database Layer
Define all of the tables/columns/views/stored procedures necessary to support the business
layer along with an Entity‐To‐Relationship diagram.

tbl_ship_details
id
name
distinct_num
tbl_record_book * gross
id
book_name
tbl_master *
tbl_privilege
Id
privilegeId
tbl_details * operation_date
tbl_tank_type id formName
book_id
id orb_master_id action
group_name
name item roleId
user_id
column1 create_date
is_deleted
column2
status
tbl_tanks column3
tank_id column4
name column5
column6
tbl_users
frames
user_id
lateral column7 tbl_roles
user_name role_id
volume column8
first_name
column9 name
user_id
last_name
column10 remarks
tank_type
password
column11
designation
column12
role_id
created_date
7. Detailed Design ‐ NA

 This section should focus on the description of the detailed design of the software
entities that are a part of the software being described by the Software Design
Document.
 Each Entity described in this section should either be identified in the Section 2, High
Level Design, or be identified as part of another entity in this section. The level of detail
to which the document describes the design is left to the scope of the documentation.
 Each entity is described as given below using the Dependency, Decomposition, Interface,
and Detailed Design Descriptions as mentioned in Sec 2.3. Note that Detailed Design
Description is mandatory.
7.1 Entity 1 Description ‐ NA
7.2 Entity 2 Description ‐ NA


Software Design Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Design Document

Uploaded by

Copyright:

Available Formats

E.W.

Liner Charts & Publications Pte Ltd

ORB1 Group D View Summary Report

Orb-I Group-D Print Summary Screen

ORB1 Group E View Summary Report

ORB1 Group E Print Summary Report

ORB1 Group F View Summary Report

ORB1 Group F Print Summary Report

ORB1 Group G View Summary Report

ORB1 Group G Print Summary Report

ORB1 Group H View Summary Report

ORB1 Group H Print Summary Report

ORB1 Group I View Summary Report

ORB1 Group I Print Summary Report

ORB-II Group Screen

ORB-II Group -A :Loading of oil Cargo

ORB-II Group -A View Summary Screen

ORB-II Group-B :Internal Transfer of Oil Cargo

ORB-II Group-B View Summary Report

ORB-II Group C :Unloading of oil Cargo

ORB-II Group C View Summary Report

ORB-II Group-D :Crude oil washing

Orb-II Group-D View summary

ORB-II Group-E :Ballasting of cargo tanks

ORB-II Group-E View Summary

ORB-II Group-F :Ballasting of dedicated clean ballast (CBT tankers only)

ORB-II Group-F view summary

ORB-II Group-G:Cleaning of cargo tanks

ORB-II Group-G View Summary

ORB-II Group-H:Discharge of dirty ballast

ORB-II Group-H view summary

ORB-II Group-I:Discharge of water from slop tanks into the sea

ORB-II Group-I view summary

ORB-II Group-J view summary

ORB-II Group-K Discharge of clean ballast contained in cargo tanks

ORB-II Group-K View summary

ORB-II Group-L :Discharge of ballast from dedicated clean ballast tanks

ORB-II Group-L View Summary

ORB-II Group-M:condition of oil discharge monitoring and control systems

ORB-II Group-M View Summary

ORB-II Group-N Accidental or other exceptional discharge of oil

ORB-II Group-N view Summary

ORB-II Group-O Loadig of ballast water

ORB-II Group-O view summary

ORB-II Group-P :Re-allocation of ballast water with in the ship

ORB-II Group-P :View Summary

ORB-II Group-Q :Ballast of water discharge to reception facility

ORB-II Group-Q view summary

Garbage Record Book-1

GRB-1 Screen 4.1.1

GRB-1 Screen 4.1.2

GRB-1 Screen 4.1.3

GRB-1 Screen 4.1.4

Garbage Record Book-2

GRB-2 Screen 4.1.1

GRB-2 Screen 4.1.2

GRB-2 Screen 4.1.3

Garbage recordbook 2 Report

Model GRB View summary

Model ORB‐1 Group‐A

Object Start and Stop Time

Object Radio Button

Object Radio Button

Object Radio Button