0115 966 7955 Today's Opening Times 10:00 - 20:00 (BST)

Development of Relational Enzymes Function Model

Published: Last Edited:

Disclaimer: This essay has been submitted by a student. This is not an example of the work written by our professional essay writers. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.

Development of Relational Enzymes Function Model for Medicinal Plants. June 2015

CHAPTER 4

SYSTEM DESIGN

  1. System Perspective/Architectural Design

The main perspective of the system is to manage the enzymes details with proper structure and EC no. As the system is organized specially for the differently abled people it is designed in such a way that the person must be convenient in using the system. The design involves new person’s registration with the help of unique no or by mobile no. Then further the person will be assigned to access the model. Fig 4.1.1 shown below is the architectural design for enrolling new person for accessing the model.

Fig 4.1.1: Architectural design for Adding New Enzymes in Functional Model

  • Problem Specification for Adding Enzymes in Data base:

The detail of enzymes can be found in many websites but the web sites doesn’t give the permission to direct fetch data from the its web page, there are some limitation’s and data can be accessed by using some protocols.

By using some rules we have to fetch data from the websites but it can’t be directly inserted to database, it has to match some rule on basis of the medicinal uses and Enzymes name.

  • Block Diagram for enrolling candidates to the training program:

Fig 4.1.2 shows the block diagram to Adding New Enzymes to the database. Initially here the Enzymes will be matched with their EC no and check for similar data present in database if it found then it can’t not be inserted o database and if didn’t found then it will save in database.

Fig 4.1.2: Block Diagram for enrolling candidates to the training program

  • Data definition/Dictionary:

Enzymes Details Table Definition and login page table Defination

The table 4.1.1 Person Details shows various fields related to persons and data type for each field with constraints.

Column

Data type

Key

Description

Mobile No/UID

integer

Primary key

All the persons have different Identification so record should keep the no of persons accessing the model.

Name of Person

Varchar

Foreign key

Name of candidate. First, Middle and Last names are entered separately

Date-Of-Birth

Int

Not Null

Date of birth of the candidate

Gender

Varchar

Not Null

Gender of the candidate

Qualification

Varchar

Not Null

It determine the qualification of person who accessing the model

Address

Varchar

Not Null

Address of the candidate

Table 4.1.1: Table shows the definitions Person Details

Enzymes Table Definition

The table 4.1.2 Enzymes Details shows the details of Enzymes and its Description

Column

Data type

key

Description

EC No

Int

Primary Key

It displays the Enzymes Unique identification

Enzymes Name

Varchar

Not Null

It Displays the Enzymes Name

Medicinal Plants

Varchar

Not Null

It Displays the Medicinal Plants name .

Table 4.1.2: Table shows the definitions of Enzymes Details

Enzymes Description Table Definition

In the table 4.1.3 Enzymes Description it contains the details of searching the Enzymes Details with EC no Medicinal Plants Name and Disease which includes data type and constraints for each field.

Column

Data type

Key

Description

Search for

int

Primary key

EC No to Search

EC No

int

Foreign key

Display EC NO With Details

Medicinal Plants

Varchar

Not null

Types Of Enzymes Present

Disease

Varchar

Not null

Medicinal Plants used for Disease

Table 4.1.3: Table shows the definitions of Enzymes Description

  • Module Specification

The system consists of 4 modules. They are

  • Input Module

In this module the files which are being fetched or downloaded using third party tool are fetched from the repository.

  • Extraction Module

In this module, from the files that are stored in the MySQL, the required data is extracted.

  • Output Module

This module consists of the output data that are extracted based on requirement, from the files that are passed as input

  • Processing Module

This module does the processing of the output obtained.

  • Assumptions Made

There are some assumptions made during the work. They are: When the tool is ported the tool consists of 1 GB RAM, 120 GB Hard Disk, 2.3 HZ Processor and Windows Operating System, .NET Framework and Visual Studio 2010 are installed.

4.2 Context Diagram for enrolling candidates to the training program

The boundary of the elements in the system have been showed in the below diagram

Fig 4.2.1: Context diagram for enrolling candidates to the training program

CHAPTER 5: DETAILED DESIGN DOCUMENT SPECIFICATION

(OBJECT ORIENTED APPROACH)

5.1 System Design

  • Brief description

OMT (Object Modeling Technique) has proposed three main types of modeling.

  • Object Modeling

The object model represents the static and most stable phenomena in the modeled domain. Main concepts are classes and associations with attributes and operations. Aggregation and generalization (with multiple inheritances) are predefined relationships. The object model represents the artifacts of the system.

  • Dynamic Modeling

The dynamic model represents a state/transition view on the model. Main concepts are states, transitions between states, and events to trigger transitions. Actions can be modeled as occurring within states. Generalization and aggregation (concurrency) are predefined relationships. The dynamic model represents the interaction between these artifacts represented as events, states, and transitions.

  • Functional Modeling

The functional model handles the process perspective of the model, corresponding roughly to data flow diagrams. Main concepts are process, data store, data flow, and actors. In brief, a functional model in OMT defines the function of the whole internal processes in a model with the help of “Data Flow Diagram (DFD’s)”. It details how processes are performed independently. The functional model represents the methods of the system from the perspective of data flow.

  • Dynamic Modeling
  • Use Case Diagram

Figure 5.1.2 Use Case Diagram of Textual Extraction Automation Tool

The Use case Diagram shows the functional aspect of the system. Document Chunk Reader fetches the documents and reads through the Repository and the extracted data are sent is sent through the same Repository Service. Extend and Include use cases are shown in the figure.

  • Activity Diagram

Figure 5.1.3 Activity Diagram of Textual Extraction Automation Tool

The Activity Diagram here shows the flow of activities performed. Once the application is started, it fetches the paragraph and extracts the sentences that match the rules and apply regular expressions to extract the required data.

  • Sequence Diagram

Figure 5.1.4 Sequence Diagram of Textual Extraction Automation Tool

The Sequence Diagram shows the sequence of events that are to be performed.

  • State Machine Diagram

Figure 5.1.5 State Machine Diagram of Textual Extraction Automation Tool

The State Machine Diagram consists of a state called Textual Extraction in which the application is executed and the output in stored after displaying and the same output (required data and value).

  • Functional Modeling
  • Data Flow Diagram

Figure 5.1.6 Data Flow Diagram of Textual Extraction Automation Tool

The Data Flow Diagram shows the flow of data of the project in which the data are been fetched and stored in MySQL .On these files are stored then rules are applied and required data are extracted.

5.3 Detailed design

Detailed design of the system is the last design activity before implementation begins. The hardest design problems must be addressed by the detailed design or the design is not complete.

The detailed design is still an abstraction as compared to source code, but should be detailed enough to ensure that translation to source is a precise mapping instead of rough interpretation.

Design decisions:

Software architecture can be perceived as a decision making process. It involves making right decision at right time. Hence, even though we had a web based application for ease of use and especially with the browser problems associated with the application.

Logic Design:

The logic designs are relevant to abstract representation of the input; output the data flow of the system. For the module registration inputs are taken by Person and stored it in to the data base. The profile module accesses this data to make the profile of the candidates. The module accesses the data from the repository and matches the result with the stored data and gives the output.


To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Request Removal

If you are the original writer of this essay and no longer wish to have the essay published on the UK Essays website then please click on the link below to request removal:


More from UK Essays

We can help with your essay
Find out more
Build Time: 0.0039 Seconds