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-aService), 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 issuesVirtualization 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
Requirements
Specification
A document that completely describes all of the
functions of a proposed system and the constraints
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
viewpoints
Analyze the questioners with stake holders.
Functional
Requirement
External interface requirement
Non Functional
Requirement
Internal project 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-softwarerequirements-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 followsResearcher:







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:





11
Provide more resources [tutorials]
Provide all possible tools related to research
Secured System
Authentication System
Instances availability
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:











13
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
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
Requirements
Expected
Requirements
Exciting
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 are3.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:
Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:
Priority:
When available:
Frequently of use:
Channel to actors:
Goal in context:
Authentication
1
User(students/ teachers /
researchers)
Institute, Service Provider
User has to login to authenticate
himself/herself
Must take the digital Id
To use environment and store
documents
Checking the validity of users.
Essential, must be implemented
First increment
Many times per day
Via graphical interface
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:
Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:
Priority:
When available:
Frequently of use:
Channel to actors:
Goal in context:
27
Storage
2
User(students/ teachers /
researchers)
Institute, Service Provider
User can upload, view, download
and delete documents
Must logged in
To storing documents and using for
the next time
If valid user can modify.
Essential, must be implemented
First increment
Many times per day
Via graphical interface
Stored data to use for future
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:
Use case No:
Primary Actor:
SaaS
3
User(students/ teachers /
researchers)
Institute, Service Provider
User can use software
User have to log in
Provide the software services
Get output through the cloud
services
Essential, must be implemented
First increment
Many times per day
Via graphical interface
Use software without installation
Secondary Actor:
Description:
Precondition:
Trigger:
Events:
Priority:
When available:
Frequently of use:
Channel to actors:
Goal in context:
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:
Use case No:
Primary Actor:
PaaS
4
User(students/ teachers /
researchers)
Institute, Service Provider
User can use platform
User have to log in
Provide the platform services
Get output through the cloud
services
Essential, must be implemented
First increment
Many times per day
Via graphical interface
Use software without installation
Secondary Actor:
Description:
Precondition:
Trigger:
Events:
Priority:
When available:
Frequently of use:
Channel to actors:
Goal in context:
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:
Use case No:
Primary Actor:
IaaS
5
User(students/ teachers /
researchers)
Institute, Service Provider
User can use operating system
User have to log in
Provide the operating system
services
Get output through the cloud
services
Essential, must be implemented
First increment
Many times per day
Via graphical interface
Use software without installation
Secondary Actor:
Description:
Precondition:
Trigger:
Events:
Priority:
When available:
Frequently of use:
Channel to actors:
Goal in context:
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:
Use case No:
Primary Actor:
Description:
Precondition:
Trigger:
Events:
Priority:
When available:
Frequently of use:
Channel to actors:
Goal in context:
SaaS
6
Admin, Institute
User can use software
Admin have to log in
Modify dashboard
Adding new instances or modify
anything
Essential, must be implemented
First increment
Many times per day
Via graphical interface
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
User
Admin
Storage
Authentication
Login/Sign up
Upload
View/Download
SaaS
PaaS
IaaS
Database
Service
Institute
Characteristics Number that
Applies
Accepted: All apply
Accepted: All apply
Accepted: All apply
Accepted: All apply
Rejected: 3 fails, attribute of
authentication
Rejected: 3 fails, attribute of
Storage
Rejected: 3 fails, attribute of
Storage
Accepted: All apply
Accepted: All apply
Accepted: All apply
Accepted: All apply
Accepted: All apply
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