Chapter1:Introduction

Chapter includes:

 Introduction
 Purpose of the project
 Scope of work
 Glossary
 References
 System overview

3 RPC
1.1 Introduction:
This document is about the project of “Research Portal on Cloud”. It
represents the overall description about the project. Already there are
some research portals which contain only research paper and some tools.
But this project will provide some important tools that will help the
researchers whose are in the research field and they will get a storage
service to store documents. The students also may be benefited using this
portal. Speciality of this portal is that it provides services based on Cloud
Computing. So, the purpose of the document is to help the user to inform
about these issues.

1.2 Purpose of the Project

The main objective of this document is to illustrate the requirements of the
project “Research Portal on Cloud”. The document gives the
detailed description of the both functional and non-functional
requirements. The document is developed after a number of
consultations with the stakeholders and considering the complete
requirement specifications. The final product of the team will be meeting
the requirements of this document. Another purpose is to know the user
about Cloud Computing.

Cloud computing is rapidly becoming a new computing paradigm that

fundamentally alters the landscape of computing services. Cloud based
services such as IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-
Service), and SaaS (Software-as-a-Service) are ideally suited for any
computing devices like computer and other devices and services where
performance, affordability, scalability, availability, and elasticity are critical
metrics. Many potential uses have been proposed to integrate this powerful
paradigm into these computing devices and services.

4 RPC
The purpose of the document is to help the stakeholders to inform about
the project, why they use this project, how they will be benefited using this
project and know about the benefit of using Cloud Computing. It already
informed that the project is especially for researcher. Now the question is
that how they will be benefited using this project. It is known to all that for
research, researcher need an environment and it will take two or three
days to create this environment. But the user of this project will get the
prepared environment that will save his valuable time.

1.3 Scope of Work:

The project will be a web based system. This system will be designed to
reduce the user difficulties by providing some essential tools. The scope of
the project can be described by discussing the following issues-

Virtualization Technology: Virtualization is software technology which

uses a physical resource such as a server and divides it up into virtual
resources such as virtual machines. Virtualization allows users to
consolidate physical resources, simplify deployment and administration
and reduce power and cooling requirements.
Virtualization Storage: Storage virtualization is a concept and term used
within computer science. Specifically, storage systems may
use virtualization concepts as a tool to enable better functionality and more
advanced features within and across storage systems.
Broadly speaking, a 'storage system' is also known as a storage array
or disk array or a filer. Storage systems typically use special hardware and
software along with disk drives in order to provide very fast and reliable
storage for computing and data processing.

Multiplatform Services: Cloud services can be run in various platforms. So

it is also a big scope to work in cloud computing. The may be run in various
types of platforms.

5 RPC
1.4 Glossary

Cloud Cloud computing is the delivery of computing as a

service rather than a product, whereby shared
resources, software over a network.

Software A document that completely describes all of the

Requirements functions of a proposed system and the constraints
Specification under which it must operate. For example, this
document.

Stakeholder The persons are included with this project.

Database Collection of all the information monitored by this

system.

Multiple Analyze the questioners with stake holders.

viewpoints

Functional External interface requirement

Requirement

Non Functional Internal project requirement.

Requirement

1.5 References
1. http://docs.openstack.org/essex/

2. https://github.com/puppetlabs/puppetlabs-openstack

3. www.ubuntu.com/sites//openstack-deployment.pdf

6 RPC
4.http://www.en.wikipedia.org/wiki/Software_requirements_specification

5.http://requirements.seilevel.com/blog/2010/10/using-software-
requirements-models-together-for-completeness.html

6.http://trireme.com/whitepapers/process/requirements/requirements_
modelling_what.html

7. [Book] Software Engineering - A Practitioners Approach 7th Edition by

Pressman

1.6 System Overview

This chapter gives user an overall idea about the project. The next
chapter, the Overall Description section, of this document gives an
overview of the functionality of the product. Inception is described in this
section.

The third chapter, Requirements Elicitation section, of this document is

written primarily for the developers and describes in technical terms the
details of the quality function deployment which describes the normal,
expected and exciting requirements.

The fourth chapter, Software Requirements Modeling section represents

the proper diagram and requirements model. This chapter is very
important for both user and developer to understand about the project.
Next chapter, it will be clear about the inception.

7 RPC
 Chapter2:
Requirements
Inception
Chapter includes:

 Stakeholder identification
 Recognizing viewpoints
 Working towards
collaboration
 Requirements questionnaire

8 RPC
 This chapter, inception describes the intended users of the system
and primitive requirements gathered from their point of view. The chapter
includes stakeholder’s identification, extracting their view point and
working towards the collaboration.

2.1 Inception:

This chapter describes the inception of the project “Research Portal

on Cloud”. In software industry requirements engineering is one of the
most important parts of software engineering process. Requirements
engineering gives us the proper scenarios what the customer wants,
analyzing needs and feasibility, negotiating a reasonable solution.
Inception is the initial step of requirements engineering which makes us
understand “how does a software project get started?” In software
industries, a software project begins when a business need is identified. So
the first step is the need to understand the customer needs. The
development team needs to figure out a rough feasibility analysis, not only
the customer’s need but also with the people who are apparently involved
with the introducing system. This stage is called inception. Inception
involves the following phases:

 Identifying Stakeholders
 Recognizing multiple viewpoints
 Working towards collaboration
 Asking the First Questions

2.2 Identifying Stakeholders:

The stakeholders and users who are most immediately involved in
“Research Portal on Cloud” are identified in this section. The stakeholders
of a software project are those people or positions, who are directly or
indirectly affected or effected by the project. The identified stakeholders
can be divided into following groups.

9 RPC
  Researcher
 Student
 Teacher
 Institute
 Developer
 Service provider

Researcher: Researchers are one of the major stakeholders of the project

because they will use the environment and store their research papers into
the IIT Research Portal.

Student: Students, who directly interact with the software, will be

benefited from this project. So they are also stakeholders of our project.

Teacher: Teachers will use this software hence; teachers are also
stakeholders like other researchers.

Institute: Institute authority is one of the major stakeholders of our

software because they will operate and maintain the system. We have to
follow the institute rules and regulations strictly. So Institute authority is
also our stakeholder.

Developer: Developers are developing this system and will be working for
further development. They are the most attracted by the programmability
of a system. Hence the main need is a good API for the system. The API can
be developed by the core system development team or can be developed by
third party vendors.

Service provider: Service provider will finance the project and it has some
rules and regulations to maintain our system. We have to follow them
strictly. So service provider is also our stakeholder.

10 RPC
2.3 Recognizing Viewpoints:
Each of the stakeholders possesses their own views about the intended
project. This is because; different stakeholders will achieve different
benefits out of this project. So we have to recognize the requirements from
multiple points of view. In order to collect those viewpoints various
discussion and formal question and answer sessions were conducted. To
the best of our understanding, their viewpoints are as follows-

Researcher:

 User friendly interface and easy to use

 Strong authentication system
 Provide full environment
 Provide platform and operating system
 Reliable data transfer
 Response time
 Reliability

Student/Teacher:

 Documents are stored categorically

 System uptime
 High availability instances
 Scalability
 Research environment
 Storage service
 Provide C++, Java, Python, LaTex and CPLEX library
 Provide operating system

Institute:

 Provide more resources [tutorials]

 Provide all possible tools related to research
 Secured System
 Authentication System
 Instances availability
11 RPC
Developer:

 Easy to develop
 No ambiguous requirements
 User response
 Support from other stakeholders
 Open Source technology

Service Provider:

 Proper solution to support customer

 Performance issues
 Availavility of all requriments within the budget
 Efficient and error free system
 Minimum maintenance cost
 Easy to maintain and operate the system
 Provide secured system

2.4 Working towards collaboration:

In our project, we have different types of stakeholders such as Students,
Teachers, and Authorities etc. So, we have different opinions about the
requirements. The opinion about a particular requirement may be common
or different among the developers. For this reason, we combine those
requirements and satisfy our stakeholders. In this step we followed the
steps stated below.

 Gather the common and conflicting requirements discussing

with the stakeholders
 Make final decision from which the requirements should be
implemented and show this to the client and other
stakeholders.

12 RPC
Common Requirements:

 User friendly and secure system

 Authentication system
 Instances availability
 Provide all possible tools
 Reliable data transfer
 System uptime
 Easy to use and sustainable performing server system
 Connectivity whenever necessary

Conflicting Requirements:

 Access system (by browser or putty, vnc)

 Research data store format
 Maintenance cost
 Faster download system
 No ambiguous requirements
 Availability of all requirements within the budget

Final requirements

We finally gathered common and conflict requirements based on their

priority. These final requirements are:

 User friendly interface and secure system

 Authentication system
 High availability of instances
 Scalability
 Storage service
 Connectivity and reliable data transfer
 Access from anywhere by any computer
 Secure software tool and environment
 Provide more resources (tutorials) and Journal (if possible)
 Provide all possible tools as possible
 Full fill the requirements within the budget

13 RPC
2.5 Requirements questionnaire
For gathering requirements for the project “Research Portal on
Cloud”, we set our first set of context-free questions focuses on the
customer and other stakeholders, overall project goals and benefits. Next
set of questions helped us to gain a better understanding of problem and
allows the customer to voice his or her perception about the solution. The
final set of questions focused on the effectiveness of the communication
activity itself. We followed the following questions to gather all possible
requirements.

 What would be the expected features as a researcher?

 How would you characterize good output that would be
generated by a successful solution?
 What problems will face by the solution?
 Can you show me the business environment in which the solution
will be used?
 Will special performance issues or constraints affect the way the
solution is approached?
 What is the minimum bandwidth and system requirements to
take this service?
 What type of data do you usually need to store in the research
portal?
 Can you tell me about the specific environment where you will do
the research.
 What specific features, tools or database management system do
you require for the research
 Do you want to tell me anything else?
 What are suggestion on how can the application be used more
effectively?
 Are there any relevant points related to your research that were
missed?
 Do you really require the Cloud service for your research?

These all above are the main part of this chapter. The chapter gives a
normal idea about the project and some requirements. It will be clear about
all the requirements and other functional productivity in the next chapter.

14 RPC
 Chapter3:
Requirements
Elicitation for RPC
Chapter includes:

 Collaborative Requirements gathering

 Quality function Deployment
 Usage Scenarios
 Functional Requirements
 Nonfunctional Requirements

15 RPC
 This chapter describes the eliciting requirements of “Research Portal on
Cloud”. Elicitation is a task that helps the customer to define what is
required. To complete the elicitation step we face many problems like
problems of scope, problems of volatility and problems of understanding.
However, this is not an easy task. To help overcome these problems, we
have worked with the Eliciting requirements activity in an organized and
systematic manner.

3.0 Eliciting Requirements of Research Portal on

Cloud:

Unlike inception where Q&A (Question and Answer) approach is used,

elicitation makes use of a requirements elicitation format that combines
the elements of problem solving, elaboration, negotiation, and specification.
It requires the cooperation of a group of end-users and developers to elicit
requirements .To elicit requirements we completed following four tasks.

 Collaborative Requirements Gathering

 Quality Function Deployment
 Usage Scenarios
 Elicitation work products

3.1 Collaborative Requirements Gathering:

Many different approaches to collaborative requirements gathering have

been proposed. Each makes use of a slightly different scenario .We
completed following steps to do it.

 The meetings were conducted with the researchers, teachers and

students of BIT first batch to understand the requirements. They
were questioned about their requirements and expectations from the
cloud service system.
 They were asked about the problems faced at the time of doing
research.

16 RPC
  Defining mechanism (such as preparing questionnaires and scenario)
which was used for collecting requirements.
 At last we selected our final requirements list from the meetings.

3.2 Quality Function Deployment:

If we want to provide much attention on product requirements analysis we
need conduct the QFD (Quality function deployment) in this respect. QFD
provides three basic form of requirements .These are-

Normal Expected Exciting

Requirements Requirements Requirements

3.2.1 Normal Requirements:

Normal requirements consist of objectives and goals that are stated during
the meeting with the customers. Normal requirements of our project are:-

 User friendly interface

 Accessible via the Internet.
 Authentication system
 High availability of instances
 Storage service
 Help feature to explain what they are looking for

17 RPC
3.2.2 Expected Requirements:
These requirements are implicit to the system and may be so fundamental
that the customer does not explicitly state them .Their absence will be a
cause for dissatisfaction.

 Well secured system

 Decrease the human work
 Provide all possible tools and operating system
 The system shall enable the Administrator to change user
passwords.
 The system shall allow the user to log in based upon an assigned
login id and password.
 The system shall enable administrators to add, edit or delete an
item.
 The user interface of the system shall be easy to use and shall
make use of drop-down boxes, radio buttons, and other selectable
fields wherever possible instead of fields that require the user to
type in data.
 Password recovery system

3.2.3 Exciting requirements:

These requirements are for features that go beyond the customer's
expectations and prove to be very satisfying when present.

 The user interface should provide appropriate error messages for

invalid input as well as tool-tips and online help
 The user interface should follow standard web practices such that the
web interface is consistent with typical internet applications.
 Offer log in with mobile phone
 Faster download system
 Enrich the portal with eBooks, research related tutorials and Journal.

18 RPC
3.3 Usage Scenarios:

At first user can authenticate in our system by creating an account. If a user

already has an account, user will log in the system with their password and
username. Then our system will permit to use this portal.
Here user will get two available services:
 Storage
 Environment

Storage: In storage, user can upload any file .If uploaded files are available;
user can view files .They also can download and delete files, whenever they
want.

Environment: User will get the following services-

 SaaS (Software as a Service)
 PaaS (Platform as a Service)
 IaaS (Infrastructure as a Service)

SaaS: In SaaS, user will get a list of available software. They select their
needed software and use. If needed software is not existing, request for
these instances.

PaaS: In PaaS, user will get a list of available platform. User selects their
needed platform and use. If needed platform is not existing, request for
these instances.

IaaS: In IaaS, user will get a list of available operating system. User selects
their needed platform and use.

19 RPC
3.4 Functional Requirements

This section describes specific feature of cloud computing. It includes

the input, process, output and all other internal processing task.

Cloud Computing is a new concept on Web Portal base system. In this

system more than one device are connected with internal cloud. Multiple
users can use instances at the same time. The functional requirements are-

3.4.0 User Interfaces

Service Models:

3.4.1 Cloud Software as a Service (SaaS).

The capability provided to the consumer is to use the provider’s

applications running on a cloud infrastructure. The applications are
accessible from various client devices through a thin client interface such
as a web browser (e.g., web-based email). The consumer does not manage
or control the underlying cloud infrastructure including network, servers,
operating systems, storage, or even individual application capabilities, with
the possible exception of limited user-specific application configuration
settings.

3.4.2 Cloud Platform as a Service (PaaS).

The capability provided to the consumer is to deploy onto the cloud

infrastructure consumer-created or acquired applications created using
programming languages and tools supported by the provider. The
consumer does not manage or control the underlying cloud infrastructure
including network, servers, operating systems, or storage, but has control
over the deployed applications and possibly application hosting
environment configurations.

20 RPC
3.4.3 Cloud Infrastructure as a Service (IaaS).

The capability provided to the consumer is to provision processing,

storage, networks, and other fundamental computing resources where the
consumer is able to deploy and run arbitrary software, which can include
operating systems and applications. The consumer does not manage or
control the underlying cloud infrastructure but has control over operating
systems.

3.5 Non-Functional Requirements

Non-functional requirements are external characteristics of a project
or software. Non-functional requirements are often called qualities of a
system. Other terms for non-functional requirements are "constraints",
"quality attributes" and “quality goals". Non-functional requirements may
exist for the following attributes. Often these requirements must be
achieved at a system-wide level rather than at a unit level.

3.5.1 Performance

Cloud Computing services can optimize the time and performance both.
One can execute any process from anywhere by using cloud. No memory
limitation, no processing delay or software limitation.

3.5.2 Reliability

Cloud system must be reliable to its user.

3.5.3 Availability

First time cloud contains limited user. But it will be extended as a large
system in near future. Instances must be available to our entire user. This is
our main challenge. Instances availability may hamper in pick hour when a
number of user are entire on a same cloud.

21 RPC
3.5.4 Maintainability

There must have a project maintain team. Whole work is observed by the
team member in every time. Project must be maintainable. If one can
include any feather or update the whole project that must be performed
correctly.

3.5.5 Security

Security is a very important issue on cloud computing. Cloud admin team

must confirm the data security of this system. Is also secured that the
passing request is absolute same and executed process must send to the
same client

22 RPC
 Chapter4: Software
Requirements Models
Chapter includes:

 Scenario Based Models

 Flow Models
 Class Models
 Behavioral Models

23 RPC
 This chapter describes all the requirements for the project
RPC. We know that there are five types of requiremets modeling.
Scenario based model is about understanding the project. Data model
and class based modeling give a clear concept of understanding about
information and data of the project. Finally DFD and Behavioral
model gives the logical information of the project. All models are
describing in the below-

4.1 Scenario Based Models

Introduction: Scenario based modeling of the requirements model are
the first part of the model that is developed. They serve as input for the
creation of other modeling elements. In our project, it is used to understand
how the software will be used.

Scenario:
A normal user wants to use an environment for their research and wants a
storage service where they can upload their work documents. For this
system, user has to go through an authentication system by logging in or
signing up. If they are eligible, they will get use all services.

Here user will get storage and environment services. In storage services
they can upload files, able to view the uploaded files. They can download
and delete files, whenever they want. They can also modify their files.

In environment, user will get SaaS, PaaS and IaaS services. SaaS is a service
where user will get many types of software whose are needed for
researching, such as – Latex, MS word, MS Visio, Visual paradigm, Origin
pro, Gantt Chart etc. PaaS is also a service like SaaS where user will get
necessary platforms, such as – C, C++, Java, C#, Python etc. In IaaS,
operating system services like Windows, Linux are offered for the user.

When any instance is unavailable then the user will request for this
software. Admin panel will create this instance.

Admin can login to the system and modify the Dashboard.

24 RPC
4.1.1 Use Cases: Use cases are used to understand how the software will
be used, what will be the input etc. The use cases for RPC are

 Authentication
 Storage
 SaaS
 PaaS
 IaaS
 Dashboard Modification

4.1.2 Use Case Diagram: In RPC, use case diagrams are used in the
sense that how the users are interacts with the software. The following
diagram is described the overall use case diagram for RPC

Figure: Use case for RPC

25 RPC
Authentication: User login to the RPC by using their user id and password.

Use case Name: Authentication

Use case No: 1
Primary Actor: User(students/ teachers /
researchers)
Secondary Actor: Institute, Service Provider
Description: User has to login to authenticate
himself/herself
Precondition: Must take the digital Id
Trigger: To use environment and store
documents
Events: Checking the validity of users.
Priority: Essential, must be implemented
When available: First increment
Frequently of use: Many times per day
Channel to actors: Via graphical interface
Goal in context: Non validate user not access to the
system

Use case diagram for authentication: In RPC, how user and admin will
login or logout is described by the following model.

Figure: Authentication

26 RPC
System maintenance: Admin can add, delete and modify user from RPC
and the use case diagram is

Figure: System maintenance

Storage: upload files to RPC and download, view files from RPC.

Use case Name: Storage

Use case No: 2
Primary Actor: User(students/ teachers /
researchers)
Secondary Actor: Institute, Service Provider
Description: User can upload, view, download
and delete documents
Precondition: Must logged in
Trigger: To storing documents and using for
the next time
Events: If valid user can modify.
Priority: Essential, must be implemented
When available: First increment
Frequently of use: Many times per day
Channel to actors: Via graphical interface
Goal in context: Stored data to use for future

27 RPC
Use case diagram for storage: User can upload files to RPC and download,
view, and delete files. The diagram is

Figure: Storage

Storage Maintenance: Admin have the ability to add or delete files.

Figure: Storage maintenance

28 RPC
SaaS: User uses the software via the internet such as MS word, Latex etc.

Use case Name: SaaS

Use case No: 3
Primary Actor: User(students/ teachers /
researchers)
Secondary Actor: Institute, Service Provider
Description: User can use software
Precondition: User have to log in
Trigger: Provide the software services
Events: Get output through the cloud
services
Priority: Essential, must be implemented
When available: First increment
Frequently of use: Many times per day
Channel to actors: Via graphical interface
Goal in context: Use software without installation

Use case diagram for SaaS: User login to RPC for using software and
after using exit from the system. The diagram is

Figure: SaaS

29 RPC
PaaS: User uses the platform via the internet such as C, C++, and Java etc.

Use case Name: PaaS

Use case No: 4
Primary Actor: User(students/ teachers /
researchers)
Secondary Actor: Institute, Service Provider
Description: User can use platform
Precondition: User have to log in
Trigger: Provide the platform services
Events: Get output through the cloud
services
Priority: Essential, must be implemented
When available: First increment
Frequently of use: Many times per day
Channel to actors: Via graphical interface
Goal in context: Use software without installation

Use case diagram for PaaS: User login to RPC for using software and
after using exit from the system. The diagram is

Figure: PaaS

30 RPC
IaaS: User uses the infrastructure via the internet such as Linux, Windows
etc.

Use case Name: IaaS

Use case No: 5
Primary Actor: User(students/ teachers /
researchers)
Secondary Actor: Institute, Service Provider
Description: User can use operating system
Precondition: User have to log in
Trigger: Provide the operating system
services
Events: Get output through the cloud
services
Priority: Essential, must be implemented
When available: First increment
Frequently of use: Many times per day
Channel to actors: Via graphical interface
Goal in context: Use software without installation

Use case diagram for IaaS: User login to RPC for using platform and
after using exit from the system. The diagram is

Figure: IaaS

31 RPC
Dashboard Modification: Admin can interact to the system via dashboard.

Use case Name: SaaS

Use case No: 6
Primary Actor: Admin, Institute
Description: User can use software
Precondition: Admin have to log in
Trigger: Modify dashboard
Events: Adding new instances or modify
anything
Priority: Essential, must be implemented
When available: First increment
Frequently of use: Many times per day
Channel to actors: Via graphical interface
Goal in context: Modify instances or other parts
whenever it need to do

Use case diagram for dashboard modification: Dashboard can be brand

able depending on the service holder. Admin modify the dashboard due to
their business purposes. The diagram is

Figure: Dashboard modification

32 RPC
4.1.3 Activity Diagram: The activity diagram represents the
actions and decisions that occur as some function is performed. Text based
diagram such as use case may not impart information in a clear and concise
manner. For this reason, graphical model such as activity diagram are used.
So the activity diagram for the use case is as follows

Authentication: First check the availability of user account. If the

account exists, the system takes input. Correct information is required for
logged in. Otherwise the user should retry.
e

Figure: Activity diagram of authentication for RPC

33 RPC
Dashboard Modification: Admin can modify the dashboard. Admin
logged into the system by correct ID and password. If the information is
correct, admin will login to the system and dashboard is viewed. Then
admin have two choice, Environment and storage.

Figure: Activity diagram of dashboard modification for RPC

34 RPC
SaaS: After login to the system, user will request for necessary software.
Then, the system provides the software to the user. After completion, user
leaves the software and exit from the system. User can also see the list of
available software and request for new software which are not available to
the system.

Figure: Activity diagram of SaaS for RPC

35 RPC
PaaS: After login to the system, user will request for necessary platform.
Then, the system provides the platform to the user. After completion, user
leaves the platform and exit from the system. User can also see the list of
available platform and request for new platform.

Figure: Activity diagram of PaaS for RPC

36 RPC
IaaS: After login to the system, user will request for necessary
infrastructure. Then, the system provides the infrastructure to the user.
After completion, user leaves the infrastructure and exit from the system.
User can also see the list of available infrastructure and request for new
infrastructure.

Figure: Activity diagram of IaaS for RPC

37 RPC
Storage: In storage services, user can upload files, they are able to view
the uploaded files. They can download and delete files whenever they want.
They can modify their files.

Figure: Activity diagram of Storage for RPC

38 RPC
4.1.4 Swimlane Diagram: Swimlane diagram represents the
flow of actions and decisions and indicates which actors perform each. It
represents the flow of activities described by the use case and also
indicates which actor or analysis class has responsibility for the action. In
RPC, to indicate the flow of the use case and responsibility of actors, use
this diagram.

Authentication: To authenticate, check account availability in the

system level and if account exists, the work of sign up is in the interface
level.

Figure: Swimlane diagram of authentication for RPC

39 RPC
SaaS: For checking availability, the system take the responsibility. User
can select and use the software as needed are the responsibility of the user
and here the actor is user. After completion, user can exit from the system.

Figure: Swimlane diagram of SaaS for RPC

40 RPC
PaaS: For checking availability, the system take the responsibility. User
can select and use the platform as needed are the responsibility of the user.
User can see the list of the platform in the interface and has the
responsibility to view the list of platform.

Figure: Swimlane diagram of PaaS for RPC

41 RPC
IaaS: The system take the responsibility for checking availability. User can
select and use the infrastructure as needed are the responsibility of the
user. User can see the list of the infrastructure in the interface and has the
responsibility to view the list of infrastructure.

Figure: Swimlane diagram of IaaS for RPC

42 RPC
Dashboard Modification: Admin can interact with the system via the
dashboard. Dashboard can be brand able depending on the service holder.
Admin can modify the dashboard due to their business purposes.

Figure: Swimlane diagram of dashboard modification for RPC

43 RPC
Storage: Selection of files are the responsibility of the user. User can
upload files to RPC and download, view, and delete files. Admin can add
new user or delete user from the system.

Figure: Swimlane diagram of Storage for RPC

44 RPC
Conclusion: This chapter describes what will be the input or output of
the project. This is used to understand how the user used the software. The
responsibility of the actor and the flow of the analysis class are described
here. The next chapter will describe the activity diagram for the system.

4.2 Data Models

Introduction: A software engineer or analyst defines all data object
that are processed within the system, the relationship between the data
object and other information that is pertinent to the relationships. To find
relationship from one entity to others, E-R diagram is used in RCP.

E-R Diagram: It represents the relationship between the entities to

entity, entity to attributes etc. In RPC, it indicates how one entity are
related to the others.

Figure: E-R diagram for RPC

45 RPC
4.3 Class Based Models:
Introduction: Class based modeling represents the object that the
system will manipulate, the operations that will be applied to the objects to
effect the manipulations, relationships between the objects, the
collaborations that occur between the classes that are defined. To effect the
manipulations, relationships between the objects, these model are used.

Now analyzing the main scenario or the story to get classes:

A normal user wants to use an environment for his research and wants a
storage service where he can upload his work documents. For this system,
user has to go through an authentication system by logging in or signing up.
And if he is eligible only then he will get use all services.

Here user will get storage and environment services. In storage services he
can upload any file, then also able to view the uploaded files. He also can
download and delete any file, if he wants. He can modify his data.

In environment, he will get SaaS, PaaS and IaaS services. SaaS is a service
where user will get many types of software whose are needed for
researching, such as – Latex, MS word, MS Visio, Visual paradigm, Origin
pro, Gantt Chart etc. PaaS is also a service like SaaS where user will get
necessary platforms, such as – C, C++, Java, C#, Python etc. In IaaS, he will
get operating system services like Windows, Linux etc.

When any instance is unavailable, the user will request for this software.
Admin panel will create this instance. User also can create any instance if
he feels very necessary.

Admin can modify the Dashboard. He can add, delete and edit any
instance. He also can create any instance.

Here the probable classes are

 User
 Admin
 Environment
 Storage
 Authentication

46 RPC
  View files
 Upload
 Download
 Service
 SaaS
 PaaS
 IaaS
 Software
 Platform
 Operating System
 Instance
 Database

4.3.1 Identifying analysis classes and attributes:

Step1: Identifying and categorize all nouns.

Analysis classes manifest themselves in one of the following ways.

1. External entities: User, Admin, SaaS, PaaS, IaaS, Database,

Instance
2. Things: View, upload, download
3. Occurrences Or Events: Service, upload, view, download,
Authentication
4. Roles: Researcher, student
5. Organizational Units: Institute
6. Places: Platform, storage, environment
7. Structures: Environment, Operating System

Step2: Selection of potential Class

Selection Characteristics:

 Retained information
 Needed services
 Multiple attributes
 Common attributes
 Common operations
 Essential requirements

47 RPC
Potential Classes Characteristics Number that
Applies
User Accepted: All apply
Admin Accepted: All apply
Storage Accepted: All apply
Authentication Accepted: All apply
Login/Sign up Rejected: 3 fails, attribute of
authentication
Upload Rejected: 3 fails, attribute of
Storage
View/Download Rejected: 3 fails, attribute of
Storage
SaaS Accepted: All apply
PaaS Accepted: All apply
IaaS Accepted: All apply
Database Accepted: All apply
Service Accepted: All apply
Institute Rejected: 4,5,6 fails

Finally the potential classes are:

 User
 Admin
 Authentication
 Storage
 SaaS
 PaaS
 IaaS
 Database
 Service

48 RPC
4.3.2 Class Cards:

Class Name: User

Methods: Attributes:

ChangePassword( ); String ID: Bigint

CreateAccount( ); void Username: String

BlockAccount():void Password: String

CheckServiceAvailability():void Name: String

RequestForInstances():void Type: String

Class Name: Admin

Methods: Attributes:

ChangePassword( ); String ID : Bigint

CreateAccount( ); void Username: String

BlockUser():void Password: String

ModifyDashboard():void Name: String

Type: String

49 RPC
 Class Name: Authentication

Methods: Attributes:

SignUp( ); Void AuthenticationNumber : Bigint

SignIn( ); void User(Object)

SignOut( );void DB(Object)

Class Name: Service

Methods: Attributes:

CreateInstances():void InstanceName:String

ModifyInstances( ); void InstanceType: String

ShowAvailability( ); Void

Class Name: Database

Methods: Attributes:

SetAttribute():void QueryString: String

GetAttribute(): void

StoreData():void

Cra
50 RPC
4.3.3 Class Responsibility Collaborator Modeling:
CRC modeling provides a simple means for identifying and organizing the
classes that are relevant to system or product requirements. Here it helps
to find the dependencies of the class.

Figure: CRC model for RPC

51 RPC
4.3.4 CRC Card: The combinations of CRC cards are represent the
CRC diagram.

Conclusion: This chapter helps to find the dependency of one class to

other. It also requires for identifying or organizing the class. In data
modeling, how data are stored in database are seen.

52 RPC
4.4 Flow Oriented Models
Data Flow Diagram:
Introduction: In RPC, DFD provide additional insight into system
requirements and flow. It simply takes an input-process-output view of a
system. The purpose of the data flow diagram is to provide a semantic
bridge between users and systems developers.

Level-0 DFD:

Level-1 DFD:

53 RPC
Level-2 DFD:

Conclusion: This chapter describes the flow of one process to other and
defined by the different level. After DFD, evaluate all use cases to fully
understand the sequence of interaction within the system.

54 RPC
4.5 Behavioral Models
4.5.1 Sequence Diagram:
Introduction: Sequence diagram indicates how events cause transitions
from object to object. It is a short hand version of the use case. It represents
key classes and the events that cause behavior to flow from class to class.

SaaS: The sequence diagram for SaaS is

Figure: sequence diagram of SaaS for RPC

55 RPC
PaaS: The sequence diagram for PaaS is

Figure: sequence diagram of PaaS for RPC

56 RPC
IaaS: The sequence diagram for IaaS is

Figure: sequence diagram of IaaS for RPC

57 RPC
Authentication: The sequence diagram for authentication is

Figure: sequence diagram of authentication for RPC

58 RPC
Storage: The sequence diagram for storage is

Figure: sequence diagram of Storage for RPC

59 RPC
Dashboard Modification: The sequence diagram for dashboard
modification is-

Figure: sequence diagram of dashboard modification for RPC

Conclusion: The sequence diagram represents behavior without noting

the classes involved. It represents the behavior, by describing how class
move from state to state.

60 RPC
4.5.2 State Diagram:
Introduction: Two different characterizations of states must be
consider the state of its class as the system performs it function and the
state of the system as observed from the outside as the system performs
the function. Here in RPC, how the class are performs it function are
described.

SaaS: The state diagram for SaaS is

Figure: State diagram of SaaS for RPC

61 RPC
PaaS: The state diagram for PaaS is

Figure: sequence diagram of PaaS for RPC

IaaS: The state diagram for IaaS is

62 RPC
Authentication: The state diagram for authentication is

Figure: State diagram of authentication for RPC

63 RPC
Database: The state diagram for database is

Figure: State diagram of Database for RPC

64 RPC
Storage: The state diagram for Storage is

Conclusion: In this chapter, how class performs their function, how an

object take to make a transition from one active state to other are
described here.

65 RPC
5. Conclusion

The proposed project stands for a Research Portal on Cloud. This

project may reduce time and energy both because user can excess any data
from anywhere in their network.
In our project, we have established a basic understanding of the
problem, the nature of the solution that is desired and the effectiveness of
preliminary communication and collaboration between the stake-holders
and the software team. More studies and communication will help both
side (developer and client) to understand the future prospect of the project.
Our team believes that the full functioning document will help us to define
that future prospect.

…..End….

66 RPC