High level design HLD
- 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.
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.
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:
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
- Stable. There does not exist any known vulnerability on the VM.
- Vulnerable. Presence of one or more vulnerabilities on a VM, which remains unexploited.