PRACTICAL TRAINING REPORT

ON

My Book store
Submitted in the partial fulfillment of the requirements for the award of
the degree of

Bachelor of Technology
In
Computer Science

SUBMITTED TO: -

SUBMITTED BY:-

Mr. Deepak Goyal

Associate professor & Head
CSE, Department
VCE, ROHTAK

Monika yadav
157/CS/11
VCE, ROHTAK

VAISH COLLEGE OF ENGINEERING

(Affiliated to Maharshi Dayanand University, Rohtak)

ROHTAK 124001
June-August-2014
1

ACKNOWLEDGEMENT
I take this opportunity to express my profound gratitude and deep regards to my guide
Mr. Amit Rajput, Technovite Lab Ltd for his exemplary guidance, monitoring and
constant encouragement throughout the course of this thesis. The blessing, help and
guidance given by him time to time shall carry me a long way in the journey of life on
which I am about to embark.
I also take this opportunity to express a deep sense of gratitude to HOD Sir & All
Faculty Members of Department of Computer Science & Engineering, Rohtak for
their cordial support, valuable information and guidance, which helped me in completing
this task through various stages.
I am obliged to staff members of Computer Department, for the valuable information
provided by them in their respective fields. I am grateful for their cooperation during the
period of my Project. Lastly, I thank almighty, my parents, brother, sisters and friends for
their constant encouragement without which this assignment would not be possible.

(MONIKA YADAV)
157/CS/11
Computer Science

Table of Contents
1. Introduction and Objective of Project

2. Introduction to MVC4

3. Requirement Analysis

11

4. Feasibility Study

12

5. Design Analysis

14

6. Models Views and controllers

15

7. Snapshots

17

8. Quality Assurance

25

9. Conclusion

28

10. Bibliography

29

Introduction and Objective of Project:

Introduction:
My Bookshop is an E-commerce site of book shipping. The project created by
using core java. The main components used are:

Mvc4 technology
SQL

The project will ask user name, user password to login for user that wants to buy a
book. User can search a book of any kind from this site and buy it .The user has to
fill its personal details

Objective:
The main objective behind the development of this project is to create
software with the following features:

Highly user-friendly
Enterprise independent
Cross-platform
Easy-to-use
Tested system to track unnoticed error.

Introduction to MVC4:
Modelviewcontroller (MVC) is a software architectural pattern for
implementing user interfaces. It divides a given software application into three
interconnected parts, so as to separate internal representations of information from
the ways that information is presented to or accepted from the user
The ASP.NET MVC is an open source web application framework that
implements the modelviewcontroller (MVC) pattern.
Based on ASP.NET, ASP.NET MVC allows software developers to build a web
application as a composition of three roles: Model, View and Controller. The MVC
model defines web applications with 3 logic layers:

Model (business layer)

View (display layer)
Controller (input control)

A model represents the state of a particular aspect of the application.

A controller handles interactions and updates the model to reflect a change

in state of the application, and then passes information to the view.

A view accepts necessary information from the controller and renders a user
interface to display that information.

ASP.NET MVC framework is a lightweight, highly testable presentation

framework that is integrated with existing ASP.NET features. Some of these
integrated features are master pages and membership-based authentication.
The MVC framework is defined in the System.Web.Mvc assembly.

The ASP.NET MVC Framework couples the models, views, and controllers
using interface -based contracts, thereby allowing each component to be
tested independently.

Model:
The model, the view and the controller involved in the MVC triad must
communicate with each other if an application is to manage a coherent interaction
with the user. Communication between a view and its associated controller is
straightforward because View and Controller are specifically designed to work
together. Models, on the other hand, communicate in a more subtle manner.

The Passive Model

In the simplest case, it is not necessary for a model to make any provision
whatever for participation in an MVC triad. A simple WYSIWYG text editor is a
good example. The central property of such an editor is that you should always see
the text as it would appear on paper. So the view clearly must be informed of each
change to the text so that it can update its display. Yet the model (which we will
assume is an instance of String) need not take responsibility for communicating the
changes to the view because these changes occur only by requests from the user.
The controller can assume responsibility for notifying the view of any changes
because it interprets the user's requests. It could simply notify the view that
something has changed -- the view could then request the current state of the string
from its model -- or the controller could specify to the view what has changed. In
either case, the string model is a completely passive holder of the string data
manipulated by the view and the controller. It adds, removes, or replaces substrings
upon demand from the controller and regurgitates appropriate substrings upon
request from the view. The model is totally "unaware" of the existence of either the
view or the controller and of its participation in an MVC triad. That isolation is not
an artifact of the simplicity of the model, but of the fact that the model changes
only at the behest of one of the other members of the triad.

The Model's Link

But all models cannot be so passive. Suppose that the data object -- the string in the
above example -- changes as a result of messages from objects other than its view or
controller. For instance, substrings could be appended to the end of the string as is the
case with the System Transcript. In that case the object which depends upon the
model's state -- its view -- must be notified that the model has changed. Because only
the model can track all changes to its state, the model must have some communication
link to the view. To fill this need, a global mechanism in Object is provided to keep
track of dependencies such as those between a model and its view. This mechanism
uses an Identity Dictionary called Dependent Fields (a class variable of Object) which
6

simply records all existing dependencies. The keys in this dictionary are all the objects
that have registered dependencies; the value associated with each key is a list of the
objects which depend upon the key. In addition to this general mechanism, the
class Model provides a more efficient mechanism for managing dependents. When
you create new classes that are intended to function as active models in an MVC triad,
you should make them subclasses of Model. Models in this hierarchy retain their
dependents in an instance variable (dependents) which holds either nil, a single
dependent object, or an instance of Dependents Collection. Views rely on these
dependence mechanisms to notify them of changes in the model. When a new view is
given its model, it registers itself as a dependent of that model. When the view is
released, it removes itself as a dependent.
The methods that provide the indirect dependents communication link are in the
"updating" protocol of class Object. Open a browser and examine these methods. The
message "changed" initiates an announcement to all dependents of an object that a
change has occurred in that object. The receiver of the changed message sends the
message update: self to each of its dependents. Thus a model may notify any
dependent views that it has changed by simply sending the message self-changed. The
view (and any other objects that are registered as dependents of the model) receives
the message update: with the model object as the argument. [Note: There is also
a changed: with: message that allows you to pass a parameter to the dependent.] The
default method for the update: message, which is inherited from Object, is to do
nothing. But most views have protocol to redisplay themselves upon receipt of
an update: message. This changed/update mechanism was chosen as the
communication channel through which views can be notified of changes within their
model because it places the fewest constraints upon the structure of models.
Note that nearly all the implementers of update: are varieties of View, and that their
behaviour is to update the display. Your views will do something similar. The senders
of changed and changed: are in methods where some property of the object is
changed which are important to its view. Again, your use of the changed message will
be much like these.

View:
Views are designed to be nested. Most windows in fact involve at least two views,
one nested inside the other. The outermost view, known as the top View is an
instance of Standard System View or one of its subclasses. The Standard System
View manages the familiar label tab of its window. Its associated controller, which
is an instance of StandardSystemController, manages the familiar moving,
framing, collapsing, and closing operations available for top level windows. Inside

a topView are one or more subViews and their associated controllers which
manage the control options available in those views. The familiar workspace for
example has a StandardSystemView as a topView, and a StringHolderView as its
single subView. A subView may, in turn, have additional subViews although this
is not required in most applications. The subView/superView relationships are
recorded in instance variables inherited from View. Each view has an instance
variable, superView, which points to the view that contains it and
another, subViews, which is an OrderedCollection of its subViews. Thus each
window's topView is the top of a hierarchy of views traceable through the
superView/subViews instance variables. Note however that some classes of view
(e.g., BinaryChoiceView, and FillInTheBlankView) do not have label tabs, and are
not resizable or moveable. These classes do not use the StandardSystemView for a
topView; instead they use a plain View for a topView.

Displaying Views
Your view may need its own display protocol. This protocol will be used both for
the initial display of your view and for redisplays when the model signals a change
(and possibly for redisplay instigated by the controller as well). Specifically,
the update: method in View sends self-display. View display in turn sends selfdisplay Border. Self displayView. Self displaySubviews. If your view requires any
special display behaviour other than what is inherited, it belongs in one of these
three methods. You can browse implementers of displayView for examples of
different sorts of display techniques. If you do, you will note that several display
methods make use of display transforms.
Display transforms are instances of Windowing Transformation. They handle
scaling and translating in order to connect windows and viewports. A window is
the input to the transformation. It is a rectangle in an abstract display space with
whatever arbitrary coordinate system you find most appropriate for your
application. A viewport can be thought of as a specific rectangular region of the
display screen to which the abstract window should be mapped. The
class WindowingTransformation computes and applies scale and translation factors
on displayable objects such as points and rectangles so that a Window, when
transformed, corresponds to viewport. However the transformation simply scales
and translates one set of coordinates to another hence there is no necessary
connection to the display screen; the transformation could be used for other
purposes.

WindowingTransformation can be composed, and their inverses can be invoked.

Views use transformations to manage subView placement. You too can use them if
you need to draw directly in a view. View display Transform: an Object applies the
display transformation of the receiver to anObject and answers the resulting scaled,
translated object. It is usually applied to Rectangles, Points, and other objects with
coordinates defined in the Views local coordinate system to obtain a scaled and
translated object in display screen coordinate. The View
displayTransformation returns a WindowingTransformation that is the result of
composing all local transformations in the receiver's superView chain with the
receiver's own local transformation. View inverseDisplayTransformation: aPoint is
used by controllersredButtonActivity to convert aPoint (e.g., Sensor cursorPoint)
from screen coordinates to view's window coordinates.

Controller:
The primary organizing principle which makes this trick possible is that the active
controllers for each project form a hierarchical tree. At the root of this tree is the
global variable ScheduledControllers, which is a ControlManager attached to the
active project. Branching from ScheduledControllers are the topLevel controllers
of each active window, plus an additional controller which manages the main
system yellowButtonMenu available on the grey screen background. Since each
view is associated with a unique controller, the view/subView tree induces a
parallel controller tree within each topView. Further branches from each topLevel
controller follow this induced tree. Control passes from controller to controller
along the branches of this tree
In simple terms the control flow requires the cooperative action of well bred
controllers each of which politely refuses control unless the cursor is in its view.
And upon accepting control the well bred controller attempts to defer to some
subView's controller. The top level ControlManager asks each of the controllers of
the active topViews if it wants control. Only the one whose view contains the
cursor responds affirmatively and is given control. It, in turn, queries the
controllers of its subViews. Again the one that contains the cursor accepts control.
This process finds the innermost nested view containing the cursor and, in general,
that view's controller retains control as long as the cursor remains in its view. (A
more detailed exposition of this control flow appears in Appendix A.) In this
scheme, control management involves the cooperation of all the active views and
controllers in an intricately coordinated minuet. Views are required to poll the
controllers of their subViews. Controllers ask their views if they contain the cursor.
For that reason, it is unusual -- and risky -- to make modifications to your views or
9

controllers that involve nonstandard flow of control. Keep this firmly in mind
when you first attempt to install a new application controller because inadvertent
disruption of the flow of control will crash the system. The prudent programmer
does a snapshot before making the attempt!
The vital role played by controllers implies that you cannot have a model-view pair
without a controller. If that were allowed, the flow of control would disappear in
the gap left by the missing controller. Yet there are some cases where you might
want a set of subViews to be controlled collectively from the containing controller,
rather than from the individual controllers of the subViews. A special controller for
such subViews is provided by the class NoController which is specifically
constructed to refuse control.
Entering and leaving the flow of control
Remember that this minuet of manners is a constantly ongoing one. How then does
your newly created MVC triad step into the process, and how does it retire when it
is done?
First, the controller of your topViews is the one responsible for entering this
process. It then passes control to its subView controllers (which in reality do most
of the work in a typical application). The top level controllers must all be
descendants of the class StandardSystemController which is designed to be the
controller of a top level view. The open message to a standardSystemController
causes your new MVC to become a top level branch of the control tree.
The open message should be the last message in the method which creates the new
MVC because control does not return from this message. Code appearing after
the controller open message will not be executed. The controlTerminate method of
a StandardSystemController takes responsibility for unscheduling when the
window is closed.

10

Requirement Analysis
For analysis of requirement for the software to be developed first of all we set
some guidelines and following those only we start analyzing in specific manner.
The whole analysis work is divided in following activities:
1.
2.
3.
4.
5.

Problem Recognition
Problem Evaluation and Solution Synthesis
Modeling
Creation Of Specification
Review Of Analysis

Problem Recognition:

We deeply assess the use and technical feasibility of the software

to be
developed
We meet the users and select all the persons who will be helping in
specifying requirements and then understand their organizational bias.
Then we define the technical environment into which the product or system
was to be placed of the software.
Then we identify the Domain Constraints i.e the specific environment
needed for effective application. This helps us to limit the functionality and
performance of the software.
We choose the team meeting with users to elect one or more requirement.

Problem Evaluation and Solution Synthesis:

We observe all the data objects to be used by us and according to

requirement.
Then according to the objects and functions we have analyzed we now
decided the flow of the information as per the requirements
Then we define the software functions which we must make to obtain the
flow and results with the data and achieve the projects objective.
Now we analyze the behavior of the software in context with the software
after defining all above tasks so as to fix the performance.

11

Now we planned and analyzed the way which we must apply to have the
asked type of user interface as per demand of the functions and data flow we
have decided to use.

Now we decide the requirements

Feasibility Analysis
Introduction of Feasibility Study:
Many feasibility studies are disillusions for both user and analysts. First , the study
often presupposed that when the feasibility of a document is being prepared, the
analyst is in a position to evaluate solution. Second, most studies tend to overlook
the confusion inherent in the system development. If the feasibility study is to
serve as a decision document, it must answer three questions
1. Is there a new and better way to do the job that will benefit the user?
2. What are the costs and saving of the alternative(s)?
3. What is recommended?
The most successful system projects are not necessarily the biggest or most visible
in a business but rather those that truly meet user expectations. Most projects fail
because of inflated expectation than for any other reason.
Feasibility Study:
As not every imagination is feasible, not even in software, evanescent a sit may
appear to outsiders. On the contrary, software feasibility has five solid dimensions:
Technical Feasibility
Is the prepared technology practical? Technical feasibility centers around the
existing computer system and to what extent it can support the proposed addition.

12

But in this case since earlier all the work was manual and there was no existing
system, so the system proposed is technically feasible. Also, the new system
should be brought according to the specification of the product being designed.
Operational Feasibility
Is the problem worth solving? Will the solution to problem work? The answer to
the above question is yes. As the problem is worth solving because the manual
work is very inefficient and from the statement of the problem gives us a clue that
there is a solution to the problem and there are pretty good chances that the
solution will work.

Economic Feasibility
It is used to measure the cost effectiveness of a project which is commonly known
as cost-benefit analysis. The project is also economically feasible as the only
requirement involving expenses are related to the cost of buying a new system and
a printer for the hard copies. And the maintenance involved in this is only the
maintenance of the computer and that does not cost much. So according to the
requirements the system is economically fit.
Legal Feasibility
Legal feasibility means that the software developed is legal; it is not violating any
governmental constraints and it is following all the legal laws. Since the project is
developed for use within a particular college only, it can by no mean violate any
legal laws.
Therefore, it is said to be legally feasible too.
Behavioral Feasibility

13

Behavioral feasibility is an estimate of how strong reaction the user staff is likely
to have towards the development of a computer system. Since this project lightens
the burden of the manual work in the cell, so the end users of the software will
always be encouraging towards the use of computer. Also, no jobs are going to be
replaced in this case.

Design Analysis
Designing is the most important part of the software development lifecycle. It
requires careful planning and logical thinking on the part of the software designer.
Designing the software means how the various parts of the software are going to
meet the user requirement and goals. It should be done with utmost care as a
simple mistake or miscalculation at this stage can result in errors which can be
compounded manifold as the development process moves up the development
hierarchy. This compounded error can result in low performance, more processing
time, and more coding and extra load.
System Design attempts to accomplish the following:

Improve productivity of analysts and programmers.

Improve documentation and subsequent maintenance and enhancements.
Cut down drastically on cost over runs and delays.
Improved communication among the users ,analysts, designers and
programmers
Standardize the approach to analysis and design
Simplify design by segmentation

14

Models, controllers and views

Models:
The main models used in this project are:

AccountModels.cs
Admin.cs
Books.cs
Bookview.cs
Cart.cs
Categories.cs
Order.cs
Order_details.cs
Shoppingcart.cs

Controller:
The main controllers used in this project are:

Accountcontroler.cs
Homecontoller.cs
Storecontroller.cs
Ordercontroller.cs
Admincontoller.cs
Bookscontoller.cs
Categoriescontoller.cs
Order_detailscontoller.cs
Shoppingcartcontoller.cs

Views:
Account
Admin

15

Books
Categories
Home
Order
Order_details
Shoppingcart

Store
shared

16

Snapshots:

17

18

19

20

21

22

23

24

Quality Assurance
There are basically three levels of Quality Assurance, namely, testing, validation
and certification. Each of these is described below:
1. Testing
The purpose of system testing is to identify and correct errors in the system and
also to judge if the system meets the requirements of the user or not. There are
three levels of system testing. They are as follows:
Unit Testing:
This type of testing focuses on the verification of the smallest unit of software
design namely the module. Using the procedural description as a guide, important
control paths are tested to uncover the errors within the boundary of a module. Unit
testing is normally white-box oriented, and the steps can be conducted in parallel
for multiple modules. In this project the sub-modules have been individually
tested.
Following checks were made:

Given set of data was taken as input to the module and the output was
observed
Logic and boundary conditions for input and output were also checked
Interfaces between two modules were also checked
Runtime Exceptions were thrown which were detected and rectified by
taking the Stack Trace
Also all the possible situation were anticipated with the help of the user to
conduct thorough tests of the system.

Integration Testing:
In this type of testing the main aim is to take the unit tested modules and build a
program structure which can be directed and dictated by the design.
This includes:

Top-down Testing
Bottom-up testing
Regression Testing
25

The last of the above was particularly important in this project which helped in
ensuring changes without introducing unintended behavior in addition.
System Testing:
This type of testing consists of a series of tests whose primary purpose is to fully
exercise the computer based system all work to verify that system elements have
been properly integrated and that they perform specified functions.
When the individual program modules are working, we combined the modules into
single working system. This integration was planned and conducted in such a way
that whenever an error occurs we get an idea about the source of it.
The entire system was viewed as a hierarchy of modules. We began with the
module at the highest level of design and worked down. Then the next modules to
be tested were those that called previously tested modules.
Functional Testing:
Once it was certain that information passed between modules according to the
design description, the system was tested to assure whether the functions
describing the requirement specification were performed by the system.
Acceptance Testing:
When the functional test completed. The user gets involved to make sure that the
system works according to the users expectation.
2. Validation
System validation checks the quality of the software in both simulated and live
environments. It has two phases.
Alpha Testing:
In this the software goes through a phase in which errors and failures based on
simulated user requirements are verified and studied. The modified software is
then subjected to Beta Testing.
Beta Testing:

26

This is testing the software in the actual users site or a live environment .The
system is used regularly with live transaction .After a scheduled time, failures and
errors are documented and final correction and enhancements are made before the
package is released for use.
Checks & Constraints:
There are many validations and checks to control input and navigational errors.
These are as follows:
Input validations are done for the following cases:
Essential fields
Character numeric Input
Choosing from certain range of values
Non-repetition of primary key values
No-input or wrong input
3. Certification
The third level of quality assurance is to certify that the program or software
package is correct and conforms to standards.

27

Conclusion:
From a proper analysis of the positive points and constraints on the component, it
can be safely concluded that the product is a highly efficient GUI based
component. This component can be easily being plugged in many other systems.
Also the component is highly user friendly. Generally the search and updating in
stores are done by non-technical people. So it is in the best interest of the
organization to use such software which their employees can handle easily. This
software comes with just that solution. Being mostly GUI based, this component
can be used very easily. With very little training, users can learn the usage of the
product. Also the search results are presented in numerous forms like report
format, graphical format etc which makes it versatile. Again the GUI based system
is certainly more eye-catching and attractive. Nowadays most of the companies are
going global .So their business has also become distributed and diverse .

28

Bibliography
beginning Asp.net Mvc4
http://stackoverflow.com/questions/19544140/using-displayformodel-withmvc4-and-the-aspx-view-engine

29