Timed File Viewing: Analysis

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 13

Timed File Viewing

Analysis:
In this project we are going to send file to the user with one time password.
First user has to register in our site. That all details are stored in the database. After that Admin
will send the file with expired date and time to the user with password to the email Id. When the
user clicks on that link, the site will open the pop-up window with password.

We have to enter the password. Once the user click the button , the user can
access the file. When the user opens the file, the timer will starts running, the file will open until
the timer reaches to “0”. After that file will be deleted. While viewing the file, the user has only
read permission. The user does not have the permission to copy, paste and download the file.
After completing the time, the users will logout automatically.

In this project we have three modules, they are

 User Registration
 Administrator Access
 User Access

User Registration:

In the first module, the user has to be registered in our site. He has to give the
details of first name, lastname and email id. While user clicks the submit button all the details
will be stored in the database.

Administrator Access:

In the second module, the administrator will enter into the database. He will set
the password to the user. He will send the file to the user with password and site link.
Administrator will set time limit to each file. When the user login to the site, automatically log
file will be created with the details.
User Access:

In the third module, user will access the site. When user clicks on the link, he will
get the window to enter the password and when he click on the button he can view the file what
he want. When the file was opened, the timer will start. The user can view the file until the timer
expires. After that the file will be deleted automatically and user will be logout. He has the
permission only to view the file. He doesn’t have permission to copy, paste and even
downloading also.

Software Development Life Cycle(SDLC):

Waterfall Model:

The waterfall model is a popular version of the systems development life cycle
model for software engineering. Often considered the classic approach to the systems
development life cycle, the waterfall model describes a development method that is linear and
sequential. Waterfall development has distinct goals for each phase of development. Once a
phase of development is completed, the development proceeds to the next phase and there is no
turning back. 

The advantage of waterfall development is that it allows for departmentalization and


managerial control. Development moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and maintenance. Each phase of
development proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
In the Requirement analysis and definition phase all requirements
are pointed down. Later these requirements are defined and discussed with system users to
specify system configuration.

The next phase is “System and software design” where the actual
design of the project takes place. The designing includes both software and hardware systems
and full system architecture is drawn.

At third stage, the designing is mainly implemented towards the


development of the project requirements. Programs are completed in units and tested accordingly
to verify it coincide with the requirements.

In the integration and system testing phase as the name suggests all
unit tasks that have been performed in the former stage are integrated to produce a complete
system. It is then tested as a complete system to find out the final deliverable to the client.
The final phase operation and maintenance is usually bit longer than
the other phases but not always this is the case. However here the project is run for practical
purpose and resolved any problem that arise during the operation. In addition to that the system
is also aligned with the newer requirements.

Technologies:

In this project we are using the PHP and MYSQL.

About PHP:

PHP is an HTML-embedded scripting language. Much of its syntax is borrowed


from C, Java and Perl with a couple of unique PHP-specific features thrown in. The goal of the
language is to allow web developers to write dynamically generated pages quickly.

It is also helpful to think of PHP in terms of what it can do for you. PHP
will allow you to:

 Reduce the time to create large websites.


 Create a customized user experience for visitors based on information that you have
gathered from them.
 Open up thousands of possibilities for online tools. Check out PHP HotScriptsfor
examples of the great things that are possible with PHP.
 Allow creation of shopping carts for e-commerce websites.

Sessions:

A PHP session solves this problem by allowing you to store user information on
the server for later use (i.e. username, shopping cart items, etc). However, this session
information is temporary and is usually deleted very quickly after the user has left the website
that uses sessions.
It is important to ponder if the sessions' temporary storage is applicable to your website. If
you require a more permanent storage you will need to find another solution, like a MySQL
database.

Sessions work by creating a unique identification(UID) number for each visitor and storing
variables based on this ID. This helps to prevent two users' data from getting confused with one
another when visiting the same webpage.

Pre Defined Constants:

The constants below are defined by this extension, and will only be available when the extension
has either been compiled into PHP or dynamically loaded at runtime.

SID (string)

Constant containing either the session name and session ID in the form of "name=ID" or
empty string if session ID was set in an appropriate session cookie. This is the same id as
the one returned by session_id().

Sessions and Security:

The session module cannot guarantee that the information you store in a session is only
viewed by the user who created the session. You need to take additional measures to actively
protect the integrity of the session, depending on the value associated with it.

Assess the importance of the data carried by your sessions and deploy additional protections --
this usually comes at a price, reduced convenience for the user. For example, if you want to
protect users from simple social engineering tactics, you need to
enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the
user side, or sessions will not work.
Cookies:

A cookie is often used to identify a user. A cookie is a small file that the server
embeds on the user's computer. Each time the same computer requests a page with a browser, it
will send the cookie too. With PHP, you can both create and retrieve cookie values.

When you create a cookie, using the function setcookie, you must specify three
arguments. These arguments are set cookie (name, value, expiration):

1. Name: The name of your cookie. You will use this name to later retrieve your cookie, so
don't forget it!
2. Value: The value that is stored in your cookie. Common values are username(string) and
last visit(date).
3. Expiration: The date when the cookie will expire and be deleted. If you do not set this
expiration date, then it will be treated as a session cookie and be removed when the
browser is restarted.

In this project we are using the cookies and sessions and some
other functions. Cookies allow the webmaster to store information about the site visitor on their
computer to be accessed again the next time they visit. One common use of cookies is to store
your username and password on your computer so you don't need to login again each time you
visit a website. Cookies can also store other things such as your name, last visit, shopping cart
contents, etc.

The main difference between a cookie and a session is that a


cookie is stored on your computer, and a session is not. Although cookies have been
around for many years and most people do have them enabled, there are some who do
not. Cookies can also be removed by the user at any time, so don't use them to store
anything too important
How to Delete a Cookie:
You can delete a cookie, regardless of whether it is temporary
or persistent, simply by changing its expiration date to a time in the past. 

System Design:

System Design is a solution to how to approach to the creation of a system.


This important phase provides the understanding and procedural details necessary for
implementing the system recommended in the feasibility study. The design step produces a data
design, an architectural design and a procedural design. The data design transforms the
information domain model created during analysis in to the data structures that will be required
to implement the software.

The architectural design defines the relationship among major structural components into a
procedural description of the software. Source code generated and testing is conducted to
integrate and validate the software.

From a project management point of view, software design is conducted in two steps.
Preliminary design is connected with the transformation of requirements into data and software
architecture. Detailed design focuses on refinements to the architectural representation that leads
to detailed data structure and algorithmic representations of software.

Logical Design:

The logical design of an information system is analogous to an engineering blue print or


conceptual view of an automobile. It shows the major features and how they are related to one
another.
The outputs, inputs and relationship between the variables are designed in this phase. The
objectives of database are accuracy, integrity and successful recover from failure, privacy and
security of data and good overall performance.

Data Design:

Data design is the first of the three design activities that are conducted during software
engineering. The impact of data structure on program structure and procedural complexity causes
data design to have a profound influence on software quality. The concepts of information hiding
and data abstraction provide the foundation for an approach to data design.

UML DIAGRAMS:

OBJECT ORIENTED ANALYSIS AND DESIGN:

Object-oriented analysis and design (OOAD) is often part of the


development of large scale systems and programs often using the Unified Modeling Language
(UML). OOAD applies object-modeling techniques to analyze the requirements for a context —
for example, a system, a set of system modules, an organization, or a business unit — and to
design a solution. Most modern object-oriented analysis and design methodologies are use case
driven across requirements, design, implementation, testing, and deployment.

Use cases were invented with object oriented programming, but


they’re also very well suited for systems that will be implemented in the procedural paradigm.

The Unified Modeling Language (UML) has become the standard


modeling language used in object-oriented analysis and design to graphically illustrate system
concepts. Part of the reason for OAD is its use in developing programs that will have an
extended lifetime.
Object Oriented Systems

An object-oriented system is composed of objects. The behavior of


the system is achieved through collaboration between these objects, and the state of the system is
the combined state of all the objects in it.

Collaboration between objects involves them sending messages to


each other. The exact semantics of message sending between objects varies depending on what
kind of system is being modeled. In some systems, “sending a message” is the same as “invoking
a method”. In other systems, “sending a message” might involve sending data via a socket.

 Object Oriented Analysis:

Object-Oriented Analysis (OOA) aims to model the problem domain, the


problem we want to solve by developing an object-oriented (OO) system. The source of the
analysis is a written requirement statements, and/or written use cases, UML diagrams can be
used to illustrate the statements.

An analysis model will not take into account implementation constraints,


such as concurrency, distribution, persistence, or inheritance, nor how the system will be built.

The model of a system can be divided into multiple domains each of


which are separately analyzed, and represent separate business, technological, or conceptual
areas of interest. The result of object-oriented analysis is a description of what is to be built,
using concepts and relationships between concepts, often expressed as a conceptual model. Any
other documentation that is needed to describe what is to be built is also included in the result of
the analysis. That can include a detailed user interface mock-up document. The implementation
constraints are decided during the object-oriented design (OOD) process.

 Object-Oriented Design:

Object-Oriented Design (OOD) is an activity where the designers are


looking for logical solutions to solve a problem, using objects. Object-oriented design takes the
conceptual model that is the result of object-oriented analysis, and adds implementation
constraints imposed by the environment, the programming language and the chosen tools, as well
as architectural assumptions chosen as basis of design.

The concepts in the conceptual model are mapped to concrete


classes, to abstract interfaces in APIs and to roles that the objects take in various situations. The
interfaces and their Implementations for stable concepts can be made available as reusable
services. Concepts identified as unstable in object-oriented analysis will form basis for policy
classes that make decisions, implement environment-specific or situation specific logic or
algorithms. The result of the object-oriented design is a detail description how the system can be
built, using objects.

Object-oriented software engineering (OOSE) is an object


modeling language and methodology OOSE was developed by Ivar Jacobson in 1992 while at
Objectory AB. It is the first object-oriented design methodology to employ use cases to drive
software design. It also uses other design products similar to those used by OMT.

The tool Objectory was created by the team at Objectory AB to


implement the OOSE methodology. After success in the marketplace, other tool vendors also
supported OOSE. After Rational bought Objectory AB, the OOSE notation, methodology, and
tools became superseded.

As one of the primary sources of the Unified Modeling Language


(UML), concepts and notation from OOSE have been incorporated into UML. The methodology
part of OOSE has since evolved into the Rational Unified Process (RUP). The OOSE tools have
been replaced by tools supporting UML and RUP.OOSE has been largely replaced by the UML
notation and by the RUP methodology.

 Sequence Diagram:

The Message Sequence Chart technique has been incorporated


into the Unified Modeling Language (UML) diagram under the name of Sequence Diagram. A
sequence diagram shows, as parallel vertical lines, different processes or objects that live
simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in
which they occur. This allows the specification of simple runtime scenarios in a graphical
manner.
For instance, the UML 1.x diagram on the right describes the
sequences of messages of a (simple) Restaurant System. This diagram represents a Patron
ordering food and wine, drinking wine then eating the food, and finally paying for the food. The
dotted lines extending downwards indicate the timeline, time flows from top to bottom. The
arrows represent messages (stimuli) from an actor or object to other objects. For example, the
Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.

The UML 2.0 Sequence Diagram supports similar notation to


the UML 1.x Sequence Diagram with added support for modeling variations to the standard flow
of events. If the lifeline is that of an object, it is underlined (if not it is a role). Note that leaving
the instance name blank can represent anonymous and unnamed instances.

In order to display interaction, messages are used. These are


horizontal arrows with the message name written above them. Solid arrows with full heads are
synchronous calls, solid arrows with stick heads are asynchronous calls and dashed arrows with
stick heads are return messages. This definition is true as of UML 2, considerably different from
UML 1.x.

Activation boxes, or method call boxes, are opaque rectangles


drawn on top of lifelines to represent that processes are being performed in response to the
message. Objects calling methods on themselves use messages and add new activation boxes on
top of any others to indicate a further level of processing.

When an object is destroyed (removed from memory), an X is


drawn on top of the lifeline, and the dashed line ceases to be drawn below it (this is not the case
in the first example though). It should be the result of a message, either from the object itself, or
another. A message sent from outside the diagram can be represented by a message originating
from a filled-in circle.
Use case Visitor:

Enter into site

Go to Register Page

Enter the user name


Visitor
Enter the email-id

Click the submit button

Logout from the site

Use case Administrator:

Enter into database

Send password and file to visitor

Administrator

Set time limit

Create auto log file when user login


Enter into email id

Click on the link

It opens window

Visitor
Enter password

View the file

Timer will starts

File Deleted If time expires

You might also like