High level design HLD

  1. High level design

High level design (HLD) gives the complete system design of functional architecture and database design. For the developers it is very much important to understand how the flow of the system is. In this phase the system design team testers team and the customers plays an important role. For this entry criteria are required the document that is SRS and the then exit criteria will be high level design, projects standards, functional design documents , and the database design documents.

5.2.2.1 Problem specification

  • Data has to be processed in a effective and efficient way.
  • Time consumption should be less.
  • Easy to implement.

5.2.2.2 Data Definition/ Dictionary

Data dictionary is a repository that contains all the description of all data produced by the application. It is an organization listing of all data elements that are pertinent to the system.

Tables

Tables For Colud Sever 1

FIELD NAME

DATA TYPE

SIZE

KEY

FName

Varchar

30

primary

Sk

Int

10

Owner

Varchar

30

CloudName

Varchar

15

Table 5.1: Owner File [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

Vm

Int

10

primary

Owner

Varchar

20

Memory

Int

10

Thrushold

Int

10

Status

Varchar

30

AttackerIP

Int

10

Attempts

Int

10

Table 5.2: Virtual Memory1 [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

FileName

Varchar

30

primary

Owner

Varchar

20

Sk

Int

10

Table 5.3: CloudFile1 Table [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

Owner

Varchar

30

primary

FileName

Varchar

20

Sk

Int

10

Table 5.4: Receive File1 Table [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

RemoteUser

Varchar

30

primary

Owner

Varchar

20

Table 5.5: Remote File Table [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

Attacker

Varchar

30

primary

AttackerName

Varchar

20

IP-Address

Int

10

Table 5.6: Attacker1 Table [Table Design]

Tables For Cloud Sever 2

FIELD NAME

DATA TYPE

SIZE

KEY

Vm

Int

10

primary

Owner

Varchar

20

Memory

Int

10

Thrushold

Int

10

Status

Varchar

30

AttackerIP

Int

10

Attempts

Int

10

Table 5.7: Virtual Memory2 Table [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

FileName

Varchar

30

primary

Owner

Varchar

20

Sk

Int

10

Table 5.8: Cloud File2 Table [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

Owner

Varchar

30

primary

FileName

Varchar

20

Sk

Int

10

Table 5.9: Receive File2 Table [Table Design]

Remote File2 Table

FIELD NAME

DATA TYPE

SIZE

KEY

RemoteUser

Varchar

30

primary

Owner

Varchar

20

Table 5.10: Remote File2 Table [Table Design]

FIELD NAME

DATA TYPE

SIZE

KEY

Attacker

Varchar

30

primary

AttackerName

Varchar

20

IP-Address

Int

10

Table 5.11: Attacker2 Table [Table Design]

5.2.3 Assumptions and dependencies

  • The user should know the authentication details to prevent the unauthorized access of the system.
  • The user must be aware of the government rules and regulations that are to be implemented on the terms.
  • The user must be aware of the flow at which the process of system takes place.
Read also  Design and cost analysis to build a 3 storey new offices with construction

5.2.4 Low level design

Low level design (LLD) is like detailing the High level design. It defines the real logic for each and the each every component of the system. Class diagrams with the methods and relation between the classes comes under the low level design.

The main phase of the object oriented approach is as follows:-

  • Object modeling
  • Dynamic modeling

Object modeling

  • Object modeling technique describes a method for the analysis, design, and implementation of a system using an object-oriented technique.
  • Object modeling technique consists of four phases, which can be performed iteratively are Analysis, system design, object design, implementation

Dynamic modeling

The dynamic model describes the functionalities involved in the project and the person performing those functionalities. Following are the different kind of dynamic diagrams namely; Use case, Sequence, Activity diagrams.

5.2.5 Use case diagram

Ause case diagramis the simple and it is a represented as the user’s interaction with the system and describes the specifications of ause case. A use case diagram can represent the different kinds of users of a system and the different ways that they will interact with the system. Such diagrams is typically used in conjunction with the textualuse caseas well as it will often be accompanied by other kinds of diagrams. It is the high level piece of functionality that the system provides. An actor is one who interacts with the system.

This Use Case diagrams are included into two modeling languages defined by the Object Management Group (OMG). Both the UML and SysML standards define a graphical notation for modeling use cases with diagrams. One complain is that they will not define the format for depicting these use cases. Generally both the graphical notation and the descriptions are very important as they document the use case and it is showing the reason for which an actor uses a system.

The use case diagram shows the place of use case with the other use cases. As organizing the mechanism a set of consistent and coherent use cases promotes important figure of system behavior and have a common understanding between the customer or owner or user and the development team.

USE CASE DIAGRAM

Figure 5.1 : Use case diagram

5.2.6 Sequence diagrams

Asequence diagramis a kind ofinteraction diagramthat shows how processes is operated with one another and in what order the processes is operated. It is the construction of aMessage Sequence Chart. A sequence diagram shows how the object interaction is arranged in time sequence. It describes the objects and classes which is involved in the scenario as well as in the sequence of messages that has been exchanged between the objects and it is needed to carry out the functions of the scenario. Sequence diagrams are typically mixed with use case in the Logical View of the system in the development. Sequence diagrams are calledevent diagrams orevent scenarios andtiming diagrams.

Read also  Importance Of Using Self Compacting Concrete Construction Essay

A sequence diagram shows the parallel vertical lines (lifelines), the different processes or objects that live parallel and the horizontal arrow. The messages exchanged between them in an order in which they have occurred. This allows the specification of simple runtime in a graphical manner.

Sequence diagrams

Create the account

Account Acceptance res

Upload the file

File received confirmation

Create the End User account

Account confirmation

Request the file

File request confirmation

File sending response

VM’s details

Threshold Details

Account details

Figure 5.2 : Sequence diagrams

5.2.7 Activity diagram

Activity diagrams is a graphical representations of flow of work of steps that have taken in the activities and actions with support for choice and interact and concurrency. In the UML activity diagrams are intends to for both the computational and also for the organizational processes (i.e. workflows)..

Activity diagrams 1

Figure 5.3 : Activity diagrams 1

Activity diagrams 2

Figure 5.4 : Activity diagrams 2

5.2.7 Functional modeling

Afunction modelorfunctional modelinsystems engineeringandsoftware engineering is a structured representation of thefunctions(activities,actions,processes,operations) within the modeledsystemor subject area.

A function model, similar with theactivity modelorprocess model, is a graphical representation of anenterprise’s function within a defined scope. The main purposes of the function model is to describe the functions and processes, and help with discovery of information needs and also help to identify opportunities, and establish a basis for determine the product and the actual service costs.

5.2.7.1 Data flow diagram

Adata flow diagram(DFD) is a graphical representation of the flow of data through aninformation system modeling its process. The step is used to create an overall view of the system which can be elaborated later. DFDs are also used for visualizationofdata processing(structured design).

A DFD shows what type of information will be input to and what type of information will the output from the system, and from where the comes and from where it goes to, and where the data will be exactly stored in the system. It does not show information about the time of processes or gives the information about the processes will operate in parallel way or in a sequence way (which is shown on aflowchart).

DFDs are the model of the proposed system. They should clearly show the requirements on which the new system should be built. Later during the design activity is taken as the basis for drawing the system’s structure charts. The Basic Notation used to create a DFD’s are as follows:

Read also  Workplace Safety And Health Policy And Objectives

1. Dataflow: Data move in a specific direction from an origin to a destination.

2. Process: People, procedures, or devices that use or produce (Transform) Data. The physical component is not identified.

3. Source: External sources or destination of data, which may be People, programs, organizations or other entities.

4. Data Store: Here data are stored or referenced by a process in the System.

Data Flow Diagram

5.2.7.2 ER Diagram

An ER model is an abstract way of describing adatabase. In the case of arelational database, which stores data in tables, some of the data in these tables point to data in other tables. It is essential to have one of these if you want to create a good database design. The patterns help focus on how the database actual works with all of the interactions and data flows.

Building Blocks of Entity Diagram are:

  • Entities: An entity is a ‘’thing” that exists and can be uniquely identi¬ed.
  • Relations: A (binary) relationship type is an association between two entity types.
  • Attributes: Attribute names (or simply attributes) are properties of entity types.

The Main Advantages of Entity relation diagrams are:

  • They are relatively simple
  • They are user friendly
  • They can provide a unique view of data, which is independent of any data models

5.2.8 Module Description

NICE Systems consists of following sub modules such as:

  • Data Owner
  • Cloud Service Provider (CSP)
  • Virtual Machine for Cloud data storage
  • Attack Analyzer
  • Remote User

Data Owner:

Users who have the data and that have to be stored in the cloud and rely on the cloud for data computation, it consist of both the individual consumers and the organizations.

Cloud Service Provider (CSP):

A Cloud Service Provider (CSP) who has significant resources and who are expert in building and managing distributed cloud storage servers on different virtual machines, owns and operates live Cloud Computing systems.

Virtual Machine for Cloud data storage

Cloud data storage, a user will stores his data through a Cloud Service Provider (CSP) into a group of cloud servers, which are running in a simultaneous, the user interacts with the cloud servers via CSP to access or retrieve his data. In some cases, the user may need to perform block level operations on his data. Users should be equipped with security means so that they can make continuous correctness assurance of their stored data even without the existence of local copies. The cloud consists of different Virtual machines on which the owner data will be allocated and shared and the cloud will listen the different types of attackers called

  1. Stable. There does not exist any known vulnerability on the VM.
  2. Vulnerable. Presence of one or more vulnerabilities on a VM, which remains unexploited.
Order Now

Order Now

Type of Paper
Subject
Deadline
Number of Pages
(275 words)