REAL TIME INTERACTIVE LECTURE DELIVERY SYSTEM

Contents
Table of Contents
1. Introduction
2. Phases .
2.1 Module 1
2.2 Module 2
2.3 Module 3
3. Purpose
3.1 Scope
4. Application, Objective and ene!its ..
". #M$ ..
".1 Structural %ia&ra's
".2 %eplo('ent %ia&ra's
".3 ehavioral %ia&ra's
".4 Se)uence %ia&ra's
"." *ollaboration %ia&ra's
".+ State chart %ia&ra's
+. Architecture %ia&ra' .
,. %atabase .
-. #ser Inter!ace
.. So!t/are 0e)uire'ent Speci!ication 1S0S2
..1 Overvie/
..2 Product Perspective ...
..3 S(ste' Inter!aces ..
..3.1 #ser Inter!ace
..3.2 3ard/are inter!ace
..3.3 So!t/are Inter!aces
..3.4 Me'or( *onstraints ..
..4 Product 4unctions
.." #ser *haracteristics .
..+ *onstraints
.., $o&ical %atabase 0e)uire'ents
..- %esi&n *onstraints
... Standard *o'pliance
..15 0eliabilit( ...
..11 Availabilit( .
..12 Securit( .
..13 Maintainabilit( ...
..14 Portabilit( ..
..1" S(ste' Mode .
..1+ Supportin& In!or'ation

..1, %ocu'ent *ontrol
..1- Appendi6 A
..1. Speci!ic 0e)uire'ents ..
..25 Per!or'ance re)uire'ents .
..21 So!t/are S(ste' Attributes ..
..22 4eatures ..
..23 Objects ..
..24 Sti'ulus
..2" 0esponse
..2+ 4unctional 3ierarch( .
..2, Additional *o''ents
15. Pro&ra''in& *ode
11. 7echnolo&( 4eatures .
11.18299 .
11.282M9
11.38%*
11.4:9 S90;I*9S..
11."4$AS3 #I$%904."..
11.+A<%00OI%..
12. 7estin&
12.1 lac= o6 7estin&
12.2 :hite o6 7estin&
12.3 Securit( 7estin&
12.4 *o'patibilit( 7estin&
13. *onclusions
14. 4uture 9nhance'ents
1". 0e!erences ..
1. Introduction
Interactive lectures are an i'portant /a( to enhance student learnin&, particularl( in lar&e
classes. 7he( help to =eep students> attention !ocused on the class, &ive students repeated
opportunities to practice, and increase student retention o! lecture 'aterial. 7he( also provide an
eas( /a( to e6peri'ent /ith di!!erent teachin& techni)ues. In s'all classes 1less than 35
students2 'ost students are prepared to as= )uestions i! the( are stru&&lin& to understand /hat is
bein& covered b( the lecturer. 3o/ever the( 'a( be inti'idated in lar&er &roups. In s'all
classes students have a sense o! inclusion and involve'ent that enhances their learnin& and

'otivation. ut this is lost in lar&er classes leadin& to reduced satis!action and less e!!ective
learnin&.
! "#ase
Module1
*reate a /eb ad'inistration !ront end /here a lecturer can activate?deactivate users, upload
presentations, upload )ui@@es, vie/ statistics1results, !eedbac=s2.
Module!
*reate an android application !or students to send their )uestions and ans/ers to the pro!essor.
A!ter validatin& the( /ill receive the results /hich /ill be presented b( this android application.
Module$
*reate a lecturer 'odule that /ill receive a students> doubts?)uestions /hile the lecture is bein&
delivered and to 'ana&e the si'ilar and dissi'ilar doubts a'on& the'.
Module%
%atabase to store all the )ui@@es and ans/ers to the' as /ell as the !eedbac=s &iven b( the
students re&ardin& the lecture.
"ur&ose
7he purpose o! this project is to develop an Interactive $ecture %eliver( S(ste' in real ti'e to
address the students directl( in vast class roo's /here hundreds o! students &ather !or an(
session.
Sco&e
7he scope o! this project is to 'a=e the lectures ver( interactive a'on& students and lecturers in
order to clari!( the students doubts then and there durin& a session in lar&e lecture halls.
%. A&&lication' (b)ecti*e and +enefits

A&&lication
7he application /ill be utili@ed b( the #sers.
,-oal
7he :eb Site is intended to avoid server !ailure, virus attac= and decrease the
in!rastructure costs, 'aintenance costs occurred to 'aintain the application .
,(b)ecti*e
%esi&n is the !irst step in 'ovin& !ro' proble' do'ain to solution do'ain. %esi&n is essentiall( the
brid&e bet/een re)uire'ents speci!ication and the !inal solution.
7he &oal o! desi&n process is to produce a 'odel or representation o! a s(ste' can be used later to
build that s(ste'. 7he produced 'odel is called the A%esi&n o! the S(ste'>.
It is a plan !or a solution o! the s(ste'.
7he objective o! desi&n phase is toB
*reate #ser Inter!ace.
*reate Application.

.
.. UML
%esi&n Patterns brou&ht a paradi&' shi!t in the /a( object oriented s(ste's are desi&ned.
Instead o! rel(in& on the =no/led&e o! proble' do'ain alone, desi&n patterns allo/ past
e6perience to be utili@ed /hile solvin& ne/ proble's. 7raditional object oriented desi&n 1OO%2
approaches such as ooch, OM7, etc. advocated identi!ication and speci!ication o! individual
objects and classes. %esi&n Patterns on the other hand pro'ote identi!ication and speci!ication o!
collaborations o! objects and classes. 3o/ever, 'uch o! the !ocus o! recent research has been
to/ards identi!ication and catalo&in& o! ne/ desi&n patterns. 7he e!!ort has been to assi'ilate
=no/led&e &ained !ro' desi&nin& s(ste's o! the past, in various proble' do'ains. 7he proble'
anal(sis phase has &ained little bene!it !ro' this paradi&'. Most projects still use traditional
object oriented anal(sis 1OOA2 approaches to identi!( classes !ro' the proble' description.
0esponsibilities to those classes are assi&ned based upon the obvious description o! entities
&iven in the proble' de!inition.

Pattern Oriented 7echni)ue 1PO72 is a 'ethodolo&( !or identi!(in& interactions a'on& classes
and 'appin& the' to one or 'ore desi&n patterns. 3o/ever, this 'ethodolo&( also uses
traditional OOA !or assi&nin& class responsibilities. As a result, its interaction oriented desi&n
phase 1driven b( desi&n patterns2 receives its input in ter's o! class de!initions that 'i&ht not
lead to best possible desi&n.
7he 'issin& piece here is the lac= o! an anal(sis 'ethod that can help in identi!(in& class
de!initions and the collaborations bet/een the' /hich /ould be a'enable to application o!
interaction oriented desi&n. 7here are t/o =e( issues here. 4irst is to co'e up /ith &ood class
de!initions and the second is to identi!( &ood class collaborations.
It has been observed in that even arrivin& at &ood class de!initions !ro' the &iven proble'
de!inition is nonCtrivial. 7he =e( to various success!ul desi&ns is the presence o! abstract classes
1such as an event handler2 /hich are not 'odeled as entities in the ph(sical /orld and hence do
not appear in the proble' description. In anticipatin& chan&e has been proposed as the 'ethod
!or identi!(in& such abstract classes in a proble' do'ain. Another di!!icult tas= is related to
assi&n'ent o! responsibilities to entities identi!ied !ro' the proble' description. %i!!erent
responsibilit( assi&n'ents could lead to co'pletel( di!!erent desi&ns. *urrent approaches such
as *oad and Dourdon, PO7 etc. !ollo/ the si'ple approach o! usin& entit( descriptions in the
proble' state'ent to de!ine classes and !i6 responsibilities. :e propose to !ollo/ a !le6ible
approach to/ards assi&nin& responsibilities to classes so that the best responsibilit( assi&n'ent
can be chosen.
7he second issue is to identi!( class collaborations. 7echni)ues such as PO7 anal(@e interactions
a'on& di!!erent sets o! classes as speci!ied in the proble' description. Such interactin& classes
are then &rouped to&ether to identi!( desi&n patterns that 'a( be applicable. 3o/ever, as
'entioned earlier, onl( the interactions a'on& obvious classes are deter'ined currentl(. Other
interactions involvin& abstract classes not present in the proble' or interactions that beco'e
!easible due to di!!erent responsibilit( assi&n'ents are not considered. :e present so'e
techni)ues that enable the desi&ner to capture such interactions as /ell.
Interaction +ased Anal/sis and Desi0n
To&1do2n a&&roac#
7his approach is applicable to situations /here the desi&ner =no/s the solution to the &iven
proble'. It is true !or proble' do'ains that have /ell established hi&hClevel solutions and
di!!erent i'ple'entations var( in lo/ level details 1!or e.&. 9nterprise 0esource Plannin& 190P2
s(ste's2. 3er 'ain concern is to reali@e that solution in a /a( such that the i'ple'ented s(ste'
has nice properties such as 'aintainabilit( and reusabilit( etc.
7o achieve this &oal, the s(ste' desi&ner selects appropriate desi&n patterns that !or' the
buildin& bloc=s o! her solution. 3avin& obtained this desi&n te'plate 1desi&n t(pe2, she 'aps the
classes and objects participatin& in those patterns to the entities o! the proble' do'ain. 7his
'appin& i'plicitl( de!ines the responsibilities o! various classes?objects that represent those
entities. 7o help clari!( the concept, consider a scenario /here an architect is assi&ned the tas= o!
buildin& a !l(over. 4l(over construction is an established science and the architect =no/s the

solution to the proble'. She starts b( identi!(in& co'ponent patterns such as road strip, support
pillars, side railin&s and so on. 3avin& done that, she 'aps the participatin& objects to actual
entities in the proble' do'ain. 7his /ould involve de!inin& the len&th and /idth o! the road
strip based upon the space constraints speci!ied in the proble'. 7he hei&ht and /ei&ht o! the
pillars &et decided based upon the load re)uire'ents speci!ied. 7he entr( and e6it points &et
decided based upon the &eo&raph( o! the location and so on. 7his results in a concrete desi&n
instance. So'e ne/ classes or objects, not e6istin& in the do'ain 'odel, 'a( also have to be
introduced !or a success!ul instantiation o! the desi&n te'plate. 4or instance, the proble'
do'ain 'a( not 'odel an abstract entit( such as an event handler /hich 'a( be a participant in
so'e portion o! the desi&n te'plate. Such &eneric classes?objects 'a( be dra/n !ro' a co''on
repositor( o! utilit( classes. Interaction driven anal(sis phase here is si'ple since the interactions
1in the !or' o! desi&n patterns2 are alread( /ell established and directl( obtained !ro' the
=no/led&e base.
+otto31u& a&&roac#
7his approach is applicable in scenarios /here interactions in the proble' do'ain are not /ell
understood and need to be discovered and e6plored. 7his situation is a !unda'ental proble'
!aced b( the desi&ners o! object oriented s(ste's. It relates to the !act that objects oriented
anal(sis 1OOA2 does not help 'uch in creatin& a solution to the proble' at hand. 7he anal(sis
phase is 'ainl( concerned /ith enhancin& the understandin& o! the proble' do'ain. 7his
=no/led&e is then later used b( a proble' solvin& approach to co'e up /ith a solution
possessin& &ood desi&n properties. As a result, at the end o! the anal(sis phase the desi&ner has a
set o! /ell de!ined co'ponents that need to be asse'bled to&ether !or reali@in& a solution. 4or
instance, to build a route !inder application the OOA phase helps in 'odelin& the do'ain objects
such as roads, vehicles, cities, addresses etc. but does not actuall( provide a solution !or !indin&
routes bet/een t/o &iven addresses. 7his is si'ilar to havin& various pieces o! a ji&sa/ pu@@le
but the pu@@le still needs to be solved. 7he proble' in so!t/are s(ste's is !urther co'plicated b(
the !act that there is &enerall( no uni)ue solution to a proble'. 7here are al/a(s tradeCo!!s at
various sta&es and the resultin& desi&ns are a re!lection o! the choices 'ade at those sta&es. In
the ji&sa/ pu@@le e6a'ple this is si'ilar to the situation /here di!!erent sets o! the sa'e pu@@le
are available each di!!erin& !ro' another in ter's o! the desi&n o! its co'ponent pieces. So'e
co'ponent desi&ns 'a( help in solvin& the pu@@le !aster and 'ore e!!icientl( than others.
7he botto'Cup approach helps in such situations /here the entities in the proble' do'ain have
been identi!ied b( traditional OOA techni)ues but 'ultiple choices e6ist in ter's o! assi&nin&
responsibilities to those entities. #nli=e topCdo/n approach, the 'appin& o! responsibilities to
entities is not dictated b( the desi&n solution speci!ied b( the desi&ner. Instead, the tas= o! the
desi&ner here is to tr( various responsibilit( assi&n'ents and create an interaction speci!ication
involvin& those objects. 7he objective o! this interaction driven anal(sis is to obtain an
interaction speci!ication that helps in arrivin& at a solution /ith best desi&n characteristics
possible. 3avin& identi!ied the entities in the do'ain, the startin& point !or the desi&ner is to
identi!( various alternatives available !or assi&nin& responsibilities to individual objects. 3er
do'ain =no/led&e helps her in this tas=. Eiven these alternatives !or potential object de!initions
and standard utilit( objects 1such as schedulers, event handlers etc.2, the ne6t step is to !ind
co'positions o! these buildin& bloc=s 1i.e. interactions o! these objects2 that provide alternative
solutions to the proble'. 7his tas= is a nonCtrivial one especiall( /hen done 'anuall(. 7here are

just too 'an( co'binations to be considered, !or an( hu'an desi&ner to obtain alternative
solutions in a reasonable a'ount o! ti'e. :e need to appl( 1se'iC2auto'ated so!t/are
co'position techni)ues based on so'e !or'al speci!ication. Several such approaches have been
recentl( investi&ated in the conte6t o! eCservices. 7hese include /or=!lo/ based approaches and
AI Plannin& based techni)ues. Other !or'al techni)ues !or speci!(in& co'position include PetriC
net based 'odels, auto'ataCbased 'odelsF te'poral lo&ics etc. !ro' veri!ication co''unit( and
GHuer(, GM$ constraint tools based techni)ues !ro' data 'ana&e'ent co''unit( .
7he resultin& candidate co'positions 1i.e. interaction speci!ications2 then need to be co'pared
/ith e6istin& desi&n patterns either 'anuall( or auto'aticall(. It is not be(ond i'a&ination to
visuali@e that /ith advance'ent in auto'ated co'position techni)ues, ne/ desi&n patterns 'a(
&et identi!ied durin& this process. 4or instance, techni)ues such as 0ein!orce'ent $earnin& have
resulted in ne/ novel solutions in various do'ains such as pla(in& ac=&a''on. In such a case,
the resultin& desi&ns 'a( need to be evaluated 'anuall(. 7he best desi&n a'on& the alternatives
is then chosen !or i'ple'entin& the s(ste'.
(&en Issues
Identif/in0 interactions
7his is a crucial step in the anal(sis phase and the success o! re'ainin& phases depends on it.
7he issue here is to identi!( interactions /hich are not evident !ro' the proble' description but
'a( hold the =e( to an e!!icient desi&n solution. 7he botto'Cup approach proposed in this paper
ta=es a step in this direction but a lot 'ore /or= is needed. 7he anal(sis 'ethod should be such
that it is able to incorporate abstract classes such as event handlers, pro6ies etc. Moreover,
current anal(sis 'ethods 'ap entities to responsibilities o! individual classes in ter's o! services
the( provide and 'ethods the( invo=e on other classes. 3o/ever, an entit( 'a( be reali@ed b( a
set o! classes. 4or instance, an adapter class hides the inter!ace o! an adoptee class and the(
collectivel( provide the desired !unctionalit(. Si'ilarl(, an abstraction and its i'ple'entation
provide a sin&le !unctionalit( throu&h separate classes resultin& in increased 'aintainabilit(. 7he
anal(sis 'ethod needs to be able to deter'ine /hen is it appropriate to reali@e an entit(
responsibilit( b( 'eans o! 'ultiple interactin& classes.
Re&resentation of Class Res&onsibilities
Since /e need to speci!( di!!erent alternative class responsibilities, as in botto'Cup approach, a
'echanis' is re)uired to docu'ent the' in a 'achine interpretable !or'at. So'e o! these
responsibilities /ould &et captured in the !or' o! 'ethods a class e6ports or 'ethods it invo=es
on other classes. 3o/ever, other responsibilities /ith respect to its interaction /ith other classes
need to be e6plicitl( speci!ied. 7hese 'a( include preC and postCconditions !or di!!erent 'ethod
invocations, other properties such as >hasSa'eInter!aceAs Ianother classJ>, >hidesInter!aceO!
Ianother classJ> etc. $an&ua&es such as could be used as it is or e6tended !or this purpose.
Lan0ua0e for S&ecif/in0 Desi0n "atterns
7he approaches !or OO %esi&n proposed in this paper !avor auto'atic techni)ues over 'anual
ones !or reasons described earlier. 7his 'eans that /e need a 'echanis' to be able to e6press

desi&n patterns in a !or'at a'enable to be read and interpreted b( pro&ra's. So'e atte'pts
have been 'ade at de!inin& such pattern description lan&ua&es K14, 13L. One o! these or so'e
variation o! these could be used to e6press desi&n patterns in a !or'al lan&ua&e.
Co3&arison of Soft2are Desi0ns
Once /e have alternative desi&ns available, the( need to be co'pared to arrive at the best one.
9ach desi&n 'a( consist o! 'ultiple desi&n patterns. 7he criteria here /ould not be to si'pl(
count the nu'ber o! desi&n patterns used but to evaluate the interaction bet/een patterns and
also bet/een other desi&n ele'ents used. 7his /ould involve an understandin& o! &ood and bad
desi&n interactions and an abilit( to identi!( the' in a &iven desi&n. 7he !inal challen&e /ould
be to do it auto'aticall(.
..1 Structural Dia0ra3
Class Dia0ra3
*lass dia&ra's identi!( the class structure o! a s(ste', includin& the properties and 'ethods o!
each class. Also depicted are the various relationships that can e6ist bet/een classes, such as an
inheritance relationship. 7he *lass dia&ra' is one o! the 'ost /idel( used dia&ra's !ro' the
#M$ speci!ication
Class Dia0ra3s are 0i*en to de&ict interactions

Student
username
password
login()
sendQueries()
attemptQuiz()
sendFeedback()
Professor
username
password
register()
login()
receiveQueries()
viewResults()
viewFeedback()
Admin
username
passowrd
login()
registerStudents()
managePresentations()
manageQuiz()
manageUserdetails()
Database
presentationTable
QuizTable
usersTable
sendsResponse()
(b)ect Dia0ra3
Object dia&ra's 'odel instances o! classes. 7his t(pe o! dia&ra' is used to describe the s(ste'
at a particular point in ti'e. #sin& this techni)ue, (ou can validatin& the class dia&ra' and itMs
'ultiplicit( rules /ith realC/orld data, and record test scenarios. 4ro' a notation standpoint,
Object dia&ra's borro/ ele'ents !ro' *lass dia&ra's.
Co3&onent Dia0ra3
*o'ponent dia&ra's !all under the cate&or( o! an i'ple'entation dia&ra', a =ind o! dia&ra'
that 'odels the i'ple'entation and deplo('ent o! the s(ste'. A *o'ponent %ia&ra', in
particular, is used to describe the dependencies bet/een various so!t/are co'ponents such as the
dependenc( bet/een e6ecutable !iles and source !iles. 7his in!or'ation is si'ilar to that /ithin
'a=e !iles, /hich describe source code dependencies and can be used to properl( co'pile an
application.
..! De&lo/3ent Dia0ra3

%eplo('ent dia&ra's are another 'odel in the i'ple'entation dia&ra' cate&or(. 7he
%eplo('ent dia&ra' 'odels the hard/are used in i'ple'entin& a s(ste' and the association
bet/een those hard/are co'ponents. *o'ponents can also be sho/n on a %eplo('ent dia&ra'
to sho/ the location o! their deplo('ent. %eplo('ent dia&ra's can also be used earl( on in the
desi&n phase to docu'ent the ph(sical architecture o! a s(ste'.
..$ +e#a*ioral Dia0ra3s
Use Case Dia0ra3
#se *ase dia&ra's identi!( the !unctionalit( provided b( the s(ste' 1use cases2, the users /ho
interact /ith the s(ste' 1actors2, and the association bet/een the users and the !unctionalit(. #se
*ases are used in the Anal(sis phase o! so!t/are develop'ent to articulate the hi&hClevel
re)uire'ents o! the s(ste'. 7he pri'ar( &oals o! #se *ase dia&ra's includeB
Providin& a hi&hClevel vie/ o! /hat the s(ste' does
Identi!(in& the users 1NactorsN2 o! the s(ste'
%eter'inin& areas needin& hu'anCco'puter inter!aces
#se *ases e6tend be(ond pictorial dia&ra's. In !act, te6tCbased use case descriptions are o!ten
used to supple'ent dia&ra's, and e6plore use case !unctionalit( in 'ore detail.

Register
login
receiveQueries
viewResults
Professor1
viewFeedback

adminLogin
registerStudents
managePresentations
manageQuiz
Admin1
maintainUserDetails

login
sendQueries
attemptQuiz
Student1
sendFeedback
..% Se4uence Dia0ra3
Se)uence dia&ra's docu'ent the interactions bet/een classes to achieve a result, such as a use
case. 7he Se)uence dia&ra' lists objects hori@ontall(, and ti'e verticall(, and 'odels these
'essa&es over ti'e.

A : admin P : professor S : student Android : application DB : database Web : application
login
upload presentations, quiz, userdetails
store all fles and details
login
get presentation
login
send doubts
presents a pop up message on screen
update student status
presents list of presentations
display quiz
send answers for the quiz
sends answers for validation
register students
get results
... Collaboration Dia0ra3
*ollaboration dia&ra's 'odel the interactions bet/een objects. 7his t(pe o! dia&ra' is a cross
bet/een an object dia&ra' and a se)uence dia&ra'. It uses !reeC!or' arran&e'ent o! objects
/hich 'a=es it easier to see all iterations involvin& a particular object.

A : admin
P :
professor
S :
student
Android :
application
DB :
database
Web :
application
1: login
2: register students
3: upload presentations, quiz, userdetails
5: login
7: get presentation
11: update student status
12: display quiz
8: login
9: send doubts
13: send answers for the quiz
10: presents a pop up message on screen
14: sends answers for validation
15: get results
4: store all fles and details
6: presents list of presentations
..5 State c#art Dia0ra3
State dia&ra's, are used to docu'ent the various 'odes 1NstateN2 that a class can &o throu&h, and
the events that cause a state transition.
..6 Acti*it/ Dia0ra3
Activit( dia&ra's are used to docu'ent /or=!lo/s in a s(ste', !ro' the business level do/n to
the operational level. 7he &eneral purpose o! Activit( dia&ra's is to !ocus on !lo/s driven b(
internal processin& vs. e6ternal events.
5. Arc#itecture Dia0ra3
Project architecture represents no o! co'ponents /e are usin& as part o! our project and the
!lo/ o! re)uest processin&.


6. Database
RealTi3e1Interacti*e Lecture Deli*er/ S/ste3
Data+aseTables

UserDetails Table:
DoubtsTable:
FeedBack Table:
ManagementDetails Table:
PresentationTable:

QuizTable:
ResultsTable:
7. User InterfaceB
8Version 1.9.9:

Approvals ignature Block
(r0ani;ation Res&onsibilit/ Si0nature Date
*usto'er ?custo'er representative
Project Mana&er
So!t/are Hualit( Assurance $eader
So!t/are *on!i&uration Mana&e'ent
$eader
#ser %ocu'entation $eader
#ser <a'e
#ser 7rainin& $eader

Definitions' Acron/3 and Abbre*iation
Ter3 or Acron/3 Definition
Stora&e Eenerall(, Stora&e can be de!ined as the act o! storin&
so'ethin&
Store Mana&e'ent Store Mana&e'ent can be si'pl( de!ined as 'ana&in& or
'aintain the stored data properl(.
82M9 Application An Application /hich is deplo(ed and run on 'obile.

<.1 (*erall Descri&tion
7he 0eal 7i'e Interactive $ecture %eliver( S(ste' is 'otivated b( the need to increase
students> interaction /ith the lecturer in real ti'e durin& a lecture. :ith the &ro/th o! the
nu'ber o! students in a class, interaction /ith students has beco'e increasin&l( di!!icult. 7his
s(ste' co'prises o! a /ebsite that 'aintains pro!iles o! lecturers and lecture 'aterial
1presentations, )ui@@es, student !eedbac=, etc.2. 7he ai' o! this project is to build a s(ste' that
!acilitates !eedbac= !ro' students and also to !acilitate interactive )uestionCans/er sessions /ith
the teacher via our 'obile client that runs on an( 8ava enabled 'obile phone /ith an internet
connectivit(. $ecturers /ould be 'ana&in& the presentations o! their respective subjects and also
conduct )ui@@es.
<.! "roduct "ers&ecti*e
7he project is a part o! a lar&e s(ste'.
+loc= dia0ra3B 7he 'ajor co'ponents o! the lar&er s(ste' are sho/n as belo/.
<.$ S/ste3 Interfaces
%escription o! various inter!aces used in the s(ste' is described in the subse)uent para&raph.
<.$.1 User Interfaces
Interface bet2een t#e soft2are &roduct and its usersB
#ser !riendl( inter!aces as depicted belo/ /ill be used.
1. Screen for3ats are re)uired to be created /ith !ollo/in& !eaturesBC
a2 #ser !riendl(.
b2 Indicate the Mandator( !ields b( asteris= 1O2.
c2 4ill up de!ault values /here ever possible
d2 Eive co'bo bo6es in all input screens.

e2 #ser and %ata entr( personnel details should be stored in the database throu&h
PSaveQ button.
!2 Authentication o! users should be carried out /here ever re)uired.
!. >eb "a0e or 2indo2 la/outs
9ach screen should have
Menu driven !acilit(
#ni!or'it(
*onsistenc(
3. (ut&uts
Anal(tical outputs should be supported b( &raphs.
a2 4or each output there should be provision o! printin&
c2 9'ails should be /ell structured
d2 9ach paper output should be !or'atted to A4 si@e paper.

%. D(s ?In&ut@
a2 9ach input bo6 to be supported b( label
b2 Eive tool tips /here re)uired
c2 Eive !or'ats 1''? dd ?((2
d2 Provide 7ab Inde6
e2 Input ele'ents /ithout visible labels s#ould continue to contain te6t 1search,
lo&in2
Enter search t

Search site
!2
Enter login nam
Pass/ord
Login
&2 radio inputs s#ould have one option chec=ed as de!ault
.. D(NTs ?In&uts@
a2 %on>t distract users !ro' their &oals
b2 %on>t use dar= bac=&round /ith dar= !ont colors
c2 %on>t use too 'an( colors
5. Error 3essa0es Eive s'all error 'essa&es li=e PIncorrect %ataQ or PIncorrect %ate 4or'atQ
or P4ield is re)uiredQ and supple'ent it /ith PO=Q utton.
<.$.! Aard2are Interfaces
4ollo/in& 3ard/are Inter!aces are re)uiredB
1. 1E 0AM

2. -5E 3ard%is=
3. Pentiu' 4 Processor
4. Internet *onnectivit(
<.$.$ Soft2are Interfaces
4ollo/in& So!t/are is re)uiredBC
8ava
Adobe 4lash uilder 4.".1
M( 9clipse -.+
8oss ".1
M(s)l ".1
Android S%R
<.$.% Me3or/ Constraints
0AM /ith 'ini'u' 1 E and 45 E 3% space
1.1.1.1 Broad level software requirements :
Re4uire3ent Re3ar=s
1. Ma=e #ser !or 0e&istration. Provide a
0e&istration and
authentication user
inter!ace.
!. Allo/s #ser to #pload 4iles
$. Allo/s #ser to ;ie/ the 4iles
%. Allo/s #ser to %o/nload the 4iles
<.% "roduct Bunctions
Database Bunctions

1. %atabase should have the !acilit( to
a2 insert records,
b2 update,
c2 edit,
d2 delete 10estricted users onl(2,
e2 Search and
!2 Sort records.
&2 *reate and edit 'aster and transaction records.
h2 All the interaction to and !ro' the database should be throu&h :eb Pa&es.
i2 %atabase should have !ollo/in& tablesBC
I. Data Entr/ "ersonnel 4irst <a'e, $ast <a'e, Address, *ontact
%etails, Huali!ication, Place o! /or=, %esi&nation. etc
II. Data Entr/ "oints user credentials.
2. Aut#entication
#sers at all levels should be authenticated be!ore &ivin& the' access.
$. Anal/sis
Outputs o! all anal(sis should be in the !or' o!
a2 %ata in tabular !or'
b2 Eraphical representation o! Per!or'ance.
<.. User c#aracteristics
4ollo/in& are the characteristics o! the intended usersBC
9ducational $evelB $evel o! the users is bet/een 9ducated to hi&hl( educated.
96perienceB 96perienced in their do'ain but trainin& in the proposed application.
7echnical 96pertiseB 7rainin& re)uired in the proposed application.

<.5 Constraints
Site Ada&tion Re4uire3ents
Onl( s(ste' Ad'inistrator and %A are authori@ed to carr( out this tas= jointl(.
Assu3&tions and De&endencies
It is assu'ed that all the s(ste's /ill have the basic 3:, S: and *o''unication Inter!aces
available. 7he users are trained in usin& the application.
A&&ortionin0 of Re4uire3ents
Identi!( re)uire'ents that 'a( be dela(ed until !uture versions o! the s(ste'.
All re)uire'ents /ill be 'et.
<.6 Lo0ical Database Re4uire3ents
$o&ical re)uire'ents connected /ith the database includeB
a2 Most o! the values are strin& t(pes but the count is in nu'bers.

b2 *ountin& o! the patients connected /ith a speci!ic disease is 'onitored i''ediatel( a!ter
enterin& the record o! each patient.
c2 Accessin& ri&hts are li'ited to authenticated users onl(.
d2 Inte&rit( constraints are 'aintained b( settin& the relationships.
Bunctions
;alidit( chec=s on the inputs
Data Entr/ (&erators
a2 0esponses to abnor'al situation, includin&
Over!lo/ S Periodic ac=ups
*o''unication !acilities B Internet, 7elephone
9rror handlin& and recover( B Periodic ac=up, 9rror alerts, Maintain 9rror $o&s
b2 9!!ect o! para'eters
<.7 Desi0n Constraints
Aard2are Constraints
Pentiu' 4 processor,
0AM Mini'u' 1 E 'e'or(,
45 E 3ard dis=.
155 Mbps Mode'
Desi0n constraints
*harts have to be created usin& 4le6
All user inter!aces have to be created usin& 4le6
Interaction bet/een #ser Inter!ace and the database should be throu&h :eb Services.
<.< Standards Co3&liance
4ollo/in& standards /ill be 'aintainedBC
0eport !or'at.
%ata na'in& 1As per the <a'in& *onventions S or&ani@ation polic(2
Accountin& procedures
Audit 7racin& 1All chan&es 'ade to student details /ill be traced in trace !iles /ith
be!ore and a!ter values2
<.19 Reliabilit/
So!t/are /ill be handed over to the client a!ter carr(out e6tensive
#nit 7estin&
Inte&ration 7estin&
S(ste' 7estin&

A!ter per!or'in& periodic de'onstrations to the end users on co'pletion o! each 'odule
and =eep a lo& o! the errors ? observations 'ade b( the user
<u'ber o! errors durin& #nit 7estin& 'a( be 'ore but the( should sho/ decreasin&
trend durin& Inte&ration and S(ste' 7estin& and should reduce to @ero at the ti'e o!
deliver(.
9nsure strict co'pliance to Project Plan
<.11 A*ailabilit/
Speci!( the !actors re)uired to &uarantee a de!ined availabilit( level !or the entire s(ste'
such as chec=point, recover(, and restart.
<.1! Securit/
Authentication 'odule /ill ensure that onl( authori@ed users are provided access control
on the /eb site.
0oles /ill be de!ined to i'pose restrictions on the authori@ed users.
9nsure that bu!!er over!lo/ and inte&er over!lo/ /ill be avoided.
:henever user is deleted his privile&es /ill also &et deleted.
*arr(out periodic bac=up o! the database and 'aintain a lo&.
3one( Pots Intentionall( include so'e P*s in the net/or= /hich are vulnerable !or
hac=ers. 7he( can be used to catch hac=ers or !i6 vulnerabilit(.
<.1$ Maintainabilit/
Reep a count o! the nu'ber o! lines o! code. 7hou&h there cannot be a bench'ar= !or the
'a6i'u' lines o! code in a sub routine but hi&her the lines o! code indicates
3i&her is the 'aintenance.
<eed to split up in to child levels.
Place ever( 'odule in 7r( *atch 12 and !inall( 12 bloc= to prevent dis&race!ul e6it.
Avoid e6cessive co'ple6it(
Avoid e6cessive Inheritance
;ariable na'e should not 'atch the !ield na'es
0educe co'ple6it( o! conditional branchin&
<.1% "ortabilit/
Speci!( attributes o! so!t/are that relate to the ease o! portin& the so!t/are to other host
'achines and?or operatin& s(ste's. 7his 'a( include
a2 Percenta&e o! co'ponents /ith hostCdependent code
b2 Percenta&e o! code that is host dependent
c2 #se o! a proven portable lan&ua&e
d2 #se o! a particular co'piler or lan&ua&e subset

e2 #se o! a particular operatin& s(ste'.
Once the relevant characteristics are selected, a subsection should be /ritten !or each, e6plainin&
the rationale !or includin& this characteristic and ho/ it /ill be tested and 'easured. A chart li=e
this 'i&ht be used to identi!( the =e( characteristics 1ratin& the' 3i&h, Mediu', or $o/2, or
ran=in& the' in order o! i'portance 11, 2, 3, etc.2.
ID C#aracteristic Ran=
1 *orrectness
2 9!!icienc(
3 4le6ibilit(
etc.
(r0ani;in0 t#e S&ecific Re4uire3ents
4or an(thin& but trivial s(ste's the detailed re)uire'ents tend to be e6tensive. 4or this
reason, it is reco''ended that care!ul consideration be &iven to or&ani@in& these in a 'anner
opti'al !or understandin&. 7here is no one opti'al or&ani@ation !or all s(ste's. %i!!erent
classes o! s(ste's lend the'selves to di!!erent or&ani@ations o! re)uire'ents in section 3. So'e
o! these or&ani@ations are described in the !ollo/in& subsections.
<.1. S/ste3 Mode
So'e s(ste's behave )uite di!!erentl( dependin& on the 'ode o! operation. 4or e6a'ple, a
control s(ste' 'a( have di!!erent sets o! !unctions dependin& on its 'odeB trainin&, nor'al, or
e'er&enc(. :hen or&ani@in& b( 'ode there are t/o possible outlines. 7he choice depends on
/hether inter!aces and per!or'ance are dependent on 'ode.
:eb Site bein& developed in ASP.<97 2.5 it is co'patible to 'ost o! the OS and the :eb
ro/sers.
<.15 Su&&ortin0 Infor3ation
7he supportin& in!or'ation 'a=es the S0S easier to use. It includesB
a2 7able o! *ontents at the !ront o! the docu'ent
b2 Inde6
c2 AppendicesB %e!initions o! i'portant ter'inolo&ies are &iven in the Appendi6
7he Appendices are not al/a(s considered part o! the actual re)uire'ents speci!ication and are
not al/a(s necessar(. 7he( 'a( includeB
1a2 Sa'ple I?O !or'ats, descriptions o! cost anal(sis studies, results o! user surve(sF
1b2 Supportin& or bac=&round in!or'ation that can help the readers o! the S0SF
1c2 A description o! the proble's to be solved b( the so!t/areF

1d2 Special pac=a&in& instructions !or the code and the 'edia to 'eet securit(, e6port,
initial loadin&, or other re)uire'ents.
:hen Appendices are included, the S0S should e6plicitl( state /hether or not the Appendices
are to be considered part o! the re)uire'ents.
7ables on the !ollo/in& pa&es provide alternate /a(s to structure section 3 on the speci!ic
re)uire'ents.
<.16 Docu3ent Control
C#an0e Aistor/
Re*ision
Release
Date
Descri&tion Clist of c#an0ed &a0es and reason for
c#an0eD
Docu3ent Stora0e
7his docu'ent /as created usin& standard S0S 7e'plate !ollo/ed b( I999. 7he !ile is stored
b( the Project Mana&er, one si&ned cop( is handed over to the authori@ed representative o! the
custo'er and the second cop( is =ept /ith the Ad'inistrator. It establishes the basis !or
a&ree'ent /ith the client on /hat the so!t/are product is e6pected to do, as /ell as /hat it is not
e6pected to do.
Docu3ent (2ner
Project Mana&er is responsible !or developin& and 'aintainin& this docu'ent.
<.17 A&&endiE A
%e!initions o! the )ualit( characteristics !ollo/.
*orrectness C e6tent to /hich pro&ra' satis!ies speci!ications, !ul!ills user>s
'ission objectives
9!!icienc( C a'ount o! co'putin& resources and code re)uired to per!or' !unction
4le6ibilit( C e!!ort needed to 'odi!( operational pro&ra'
Inte&rit(?Securit( C !actors that protect the so!t/are !ro' accidental or 'alicious
access, use, 'odi!ication, destruction, or disclosure
Interoperabilit( C e!!ort needed to couple one s(ste' /ith another
Maintainabilit( C ease o! 'aintenance o! the so!t/are itsel!
Portabilit( C ease o! portin& the so!t/are to another host
0eliabilit( C !actors re)uired to establish the re)uired reliabilit( o! the s(ste'
0eusabilit( C e6tent to /hich it can be reused in another application

7estabilit( C e!!ort needed to test to ensure per!or's as intended
#sabilit( C e!!ort re)uired to learn, operate, prepare input, interpret output
Availabilit( C !actors re)uired to &uarantee a de!ined availabilit( level !or the
s(ste'

<.1< S&ecific Re4uire3ents

Uni4ue
ID
Re4uire3ent Re3ar=s
1.
2.
3.
4.
".
+.
,.
-.
<.!9 "erfor3ance Re4uire3ents
Presentl( /e are /or=in& on three ter'inals. It is e6pected that at an( point o! ti'e three
ter'inals /ill be in operation si'ultaneousl(. 7he a'ount o! in!or'ation /ill be nu'erical and
te6t oriented and the volu'e /ill be li'ited
<.!1 Soft2are S/ste3 Attribute
Anal(sisB 7his is an i'portant 'odule and this 'odule should be able to raise an alert b(
esti'atin& the probabilit( o! disease bein& escalated to epide'ic.
Modular approach /ill be !ollo/ed.
1. *reate 0oles.
2. Mana&e the application
Eraphs and e'ail &eneration should be as(nchronous.
<.!! ob)ects
4ollo/in& objects are bein& considered in this applicationBC
Authori@ed users.
Per!or'ance 0eport.
<.!$ Beature
7he !eatures are listed in the subse)uent para&raphs in the !or' o! Sti'ulus and 0esponse.

<.!% Sti3ulus
#ser I% T P/d o! %ata 9ntr( Operators

<.!. Res&onse
Per!or'ance 0eport.
%(na'ic Eraphs.
Authentication Alert.
<.!5 Bunctional Aierarc#/
:hen none o! the above or&ani@ational sche'es prove help!ul, the overall !unctionalit( can
be or&ani@ed into a hierarch( o! !unctions or&ani@ed b( co''on inputs, co''on outputs, or
co''on internal data access. %ata !lo/ dia&ra's and data dictionaries can be used to sho/ the
relationships bet/een and a'on& the !unctions and data.
%ra/ %4%s
Prepare %ata %ictionaries.
<.!6 Additional Co33ents
:henever a ne/ S0S is conte'plated, 'ore than one o! the or&ani@ational techni)ues &iven
in 3., 'a( be appropriate. In such cases, or&ani@e the speci!ic re)uire'ents !or 'ultiple
hierarchies tailored to the speci!ic needs o! the s(ste' under speci!ication. An( additional
re)uire'ents 'a( be put in a separate section at the end o! the S0S.
7here are 'an( notations, 'ethods, and auto'ated support tools available to aid in the
docu'entation o! re)uire'ents. 4or the 'ost part, their use!ulness is a !unction o! or&ani@ation.
4or e6a'ple, /hen or&ani@in& b( 'ode, !inite state 'achines or state charts 'a( prove help!ulF
/hen or&ani@in& b( object, objectCoriented anal(sis 'a( prove help!ulF /hen or&ani@in& b(
!eature, sti'ulusCresponse se)uences 'a( prove help!ulF /hen or&ani@in& b( !unctional
hierarch(, data !lo/ dia&ra's and data dictionaries 'a( prove help!ul.
In an( o! the outlines belo/, those sections called P4unctional 0e)uire'ent iQ 'a( be
described in native lan&ua&e, in pseudo code, in a s(ste' de!inition lan&ua&e, or in !our
subsections titledB Introduction, Inputs, Processin&, and Outputs.
I*lic=.
19. "ro0ra33in0 Code
11.
11.TECAN(L(-Y
11.1 F!EE ?Fa*a ! "latfor3' Enter&rise Edition@
Introduction
Distributed Multi1tiered A&&lications
F!EE Co3&onents

Conclusion
7he 8299 plat!or' uses a distributed 'ultitiered application 'odel !or enterprise
applications. Application lo&ic is divided into co'ponents accordin& to !unction, and the various
application co'ponents that 'a=e up a 8299 application are installed on di!!erent 'achines
dependin& on the tier in the 'ultitiered 8299 environ'ent to /hich the application co'ponent
belon&s. Multitiered 8299 applications divided into the tiers described in the!ollo/in& list.B
Client1tier co3&onents run on t#e client 3ac#ine.
>eb1tier co3&onents run on t#e F!EE ser*er.
+usiness1tier co3&onents run on t#e F!EE ser*er.
Enter&rise infor3ation s/ste3 ?EIS@1tier soft2are runs on t#e EIS ser*er.
Multi1tiered F!EE A&&lication .

F!EE Co3&onents
8299 applications are 'ade up o! co'ponents. A 8299 co'ponent is a sel!Ccontained
!unctional so!t/are unit that is asse'bled into a 8299 application /ith its related classes and
!iles and that co''unicates /ith other co'ponents. 7he 8299 speci!ication de!ines the
!ollo/in& 8299 co'ponentsB
Application clients and applets are co'ponents that run on the client.
8ava Servlet and 8ava Server Pa&esU 18SPU2 technolo&( co'ponents are :eb
co'ponents that run on the server.
9nterprise 8avaeansU 198U2 co'ponents 1enterprise beans2 are business
co'ponents that run on the server.
8299 co'ponents are /ritten in the 8ava pro&ra''in& lan&ua&e and are co'piled in the
sa'e /a( as an( pro&ra' in the lan&ua&e. 7he di!!erence bet/een 8299 co'ponents and
PstandardQ 8ava classes is that 8299 co'ponents are asse'bled into a 8299 application, are
veri!ied to be /ell !or'ed and in co'pliance /ith the 8299 speci!ication, and are deplo(ed to
production, /here the( are run and 'ana&ed b( the 8299 server.
8299 /eb co'ponents are either servlets or pa&es created usin& 8SP technolo&( 18SP pa&es2.
Servlets are 8ava pro&ra''in& lan&ua&e classes that d(na'icall( process re)uests and construct
responses. 8SP pa&es are te6tCbased docu'ents that e6ecute as servlets but allo/ a 'ore natural
approach to creatin& static content.
Static 37M$ pa&es and applets are bundled /ith /eb co'ponents durin& application
asse'bl( but are not considered /eb co'ponents b( the 8299 speci!ication. ServerCside utilit(
classes can also be bundled /ith /eb co'ponents and, li=e 37M$ pa&es, are not considered /eb
co'ponents.
11.! Fa*a ME
8ava plat!or' desi&ned !or e'bedded s(ste's 1'obile devices are one =ind o! such s(ste's2 .
7ar&et devices ran&e !ro' industrial controls to 'obile phones 1especiall( !eature phones2 and
setCtop bo6es. 8ava M9 /as !or'erl( =no/n as Fa*a ! "latfor3' Micro Edition 1F!ME2.

8ava M9 /as desi&ned b( Sun Micros(ste's, no/ a subsidiar( o! Oracle *orporationF the
plat!or' replaced a si'ilar technolo&(, Personal 8ava. Ori&inall( developed under the 8ava
*o''unit( Process as 8S0 +-, the di!!erent !lavors o! 8ava M9 have evolved in separate
8S0s. Sun provides a re!erence i'ple'entation o! the speci!ication, but has tended not to
provide !ree binar( i'ple'entations o! its 8ava M9 runti'e environ'ent !or 'obile devices,
rather rel(in& on third parties to provide their o/n.
8ava M9 source code is licensed under the E<# Eeneral Public $icense, and is released under
the project na'e phoneM9.
As o! 255-, all 8ava M9 plat!or's are currentl( restricted to 809 1.3 !eatures and use that
version o! the class !ile !or'at 1internall( =no/n as version 4,.52. Should Oracle ever declare
a ne/ round o! 8ava M9 con!i&uration versions that support the later class !ile !or'ats and
lan&ua&e !eatures, such as those correspondin& 809 1." or 1.+ 1notabl(, &enerics2, it /ill entail
e6tra /or= on the part o! all plat!or' vendors to update their 809s.
8ava M9 devices i'ple'ent a pro!ile. 7he 'ost co''on o! these are the Mobile In!or'ation
%evice Pro!ile ai'ed at 'obile devices, such as cell phones, and the Personal Pro!ile ai'ed at
consu'er products and e'bedded devices li=e setCtop bo6es and P%As. Pro!iles are subsets o!
con!i&urations, o! /hich there are currentl( t/oB the *onnected $i'ited %evice *on!i&uration
1*$%*2 and the *onnected %evice *on!i&uration
7here are 'ore than 2.1 billion 8ava M9 enabled 'obile phones and but it is beco'in& old
technolo&( as it is not used on an( o! toda(Ms ne/est 'obile plat!or's 1e& iPhone, Android,
:indo/s Phone ,, MeeEo, lac=err(Ms ne/ H<G2.
*onnected $i'ited %evice *on!i&uration 1*$%*2 contains a strict subset o! the 8avaCclass
libraries, and is the 'ini'u' a'ount needed !or a 8ava virtual 'achine to operate. *$%* is
basicall( used !or classi!(in& '(riad devices into a !i6ed con!i&uration.
A con!i&uration provides the 'ost basic set o! libraries and virtualC'achine !eatures that 'ust
be present in each i'ple'entation o! a 82M9 environ'ent. :hen coupled /ith one or 'ore
pro!iles, the *onnected $i'ited %evice *on!i&uration &ives developers a solid 8ava plat!or'
!or creatin& applications !or consu'er and e'bedded devices.
Mobile Infor3ation De*ice "rofile
%esi&ned !or 'obile phones, the Mobile In!or'ation %evice Pro!ile includes a E#I, and a
data stora&e API, and MI%P 2.5 includes a basic 2% &a'in& API. Applications /ritten !or this

pro!ile are called MI%lets. Al'ost all ne/ cell phones co'e /ith a MI%P i'ple'entation, and
it is no/ the de !acto standard !or do/nloadable cell phone &a'es. 3o/ever, 'an( cellphones
can run onl( those MI%lets that have been approved b( the carrier, especiall( in <orth
A'erica.
8S0 2,1B Mobile In!or'ation %evice Pro!ile 3 14inal release on 5. %ec, 255.2 speci!ied the
3rd &eneration Mobile In!or'ation %evice Pro!ile 1MI%P32, e6pandin& upon the !unctionalit(
in all areas as /ell as i'provin& interoperabilit( across devices. A =e( desi&n &oal o! MI%P3
is bac=/ard co'patibilit( /ith MI%P2 content.
Information Module Profile
7he In!or'ation Module Pro!ile 1IMP2 is a pro!ile !or e'bedded, NheadlessN devices such as
vendin& 'achines, industrial e'bedded applications, securit( s(ste's, and si'ilar devices
/ith either si'ple or no displa( and /ith so'e li'ited net/or= connectivit(.
Ori&inall( introduced b( Sie'ens Mobile and <o=ia as 8S0C1.", IMP 1.5 is a strict subset o!
MI%P 1.5 e6cept that it doesnMt include user inter!ace APIs V in other /ords, it doesnMt
include support !or the 8ava pac=a&e java6.'icroedition.lcdui. 8S0C22-, also =no/n as IMPC
<E, is IMPMs ne6t &eneration that is based on MI%P 2.5, levera&in& MI%P 2.5Ms ne/ securit(
and net/or=in& t(pes and APIs, and other APIs such as Push0e&istr( and plat!or'0e)uest12,
but a&ain it doesnMt include #I APIs, nor the &a'e API.
Connected De*ice Confi0uration
Main articleB *onnected %evice *on!i&uration
7he *onnected %evice *on!i&uration is a subset o! 8ava S9, containin& al'ost all the libraries
that are not E#I related. It is richer than *$%*.
Boundation "rofile
7he 4oundation Pro!ile is a 8ava M9 *onnected %evice *on!i&uration 1*%*2 pro!ile. 7his
pro!ile is intended to be used b( devices re)uirin& a co'plete i'ple'entation o! the 8ava
virtual 'achine up to and includin& the entire 8ava Plat!or', Standard 9dition API. 7(pical
i'ple'entations /ill use so'e subset o! that API set dependin& on the additional pro!iles
supported. 7his docu'ent describes the !acilities that the 4oundation Pro!ile provides to the
device and other pro!iles that use it. 7his speci!ication /as developed under the 8ava
*o''unit( Process.

"ersonal +asis "rofile
7he Personal asis Pro!ile e6tends the 4oundation Pro!ile to include li&ht/ei&ht E#I support
in the !or' o! an A:7 subset. 7his is the plat!or' that %C8 is built upon.
I3&le3entations
Sun provides a re!erence i'ple'entation o! these con!i&urations and pro!iles !or MI%P and
*%*. Startin& /ith the 8ava M9 3.5 S%R, a <et beansCbased I%9 /ill support the' in a
sin&le I%9.
In contrast to the nu'erous binar( i'ple'entations o! the 8ava Plat!or' built b( Sun !or
servers and /or=stations, Sun does not provide an( binaries !or the plat!or's o! 8ava M9
tar&ets /ith the e6ception o! an MI%P 1.5 809 18;M2 !or Pal' OS. Sun provides no 82M9
809 !or the Microso!t :indo/s Mobile 1Poc=et P*2 based devices, despite an openCletter
ca'pai&n to Sun to release a ru'ored internal i'ple'entation o! Personal8ava =no/n b( the
code na'e N*aptain A'ericaN.7hird Part( ;MMs li=e 8lend and 8ed are /idel( used b(
:indo/s Mobile vendors li=e 37* and Sa'sun&
Operatin& s(ste's tar&etin& 8ava M9 have been i'ple'ented b( %o*oMo in the !or' o!
%o8a, and b( Sava8e as Sava8e OS. 7he latter co'pan( /as purchased b( Sun in April 255,
and no/ !or's the basis o! SunMs 8ava4G Mobile. 7he co'pan( IS27 provides 8ava M9
virtual 'achine 1Micro8v'2, !or an( 07OS and even /ith noC07OS then )uali!ied as
bare'etal. :hen bare'etal, the virtual 'achine is the OS?07OSB the device boots in 8ava.
K"L
Micro9'ulator provides an open source 1$EP$2 i'ple'entation o! MI%P e'ulator. 7his is a
8ava Applet based e'ulator and can be e'bedded in /eb pa&es.
7he openCsource Mi=a ;M ai's to i'ple'ent 8avaM9 *%*?4P, but is not certi!ied as such
1certi!ied i'ple'entations are re)uired to char&e ro(alties, /hich is i'practical !or an openC
source project2. *onse)uentl( devices /hich use this i'ple'entation are not allo/ed to clai'
8avaM9 *%* co'patibilit(.
11.$ FD+C
7he 8ava %ataase connectivit( is a set o! java classes that provide connectivit( to relational
databases. :e can use 8%* !ro' java pro&ra's to access al'ost ever( SH$ database li=e
Oracle, S(base, %2, SH$ server, Access and 4o6AS9, etc. 8%* drivers are available !ro'
S('antec, Intersolve, IM, javaso!t and orelan?;isi&enic etc., /ith little e!!ort /e can
connect to database.

(ri0in of FD+C
8%* is not a ne/ )uer( lan&ua&e. It is a si'pl( a java object inter!ace 1co''unication2 to
SH$. Our applications use 8%* to !or/ard SH$ state'ents to a %MG. :e /rite SH$
state'ents in a java pro&ra' to per!or' database )ueries and updates. :e can thin= o! 8%*
as just a java SH$ /rapper. 8%* does not enhance or di'inish the po/er o! SH$. It>s si'pl(
a 'echanis' !or sub'ittin& SH$ state'ents. 8%* can handle easil( the 'anipulations li=e
connectin& to a database, retrievin& )uer( results, co''ittin& or rollin& bac= transactions.
8%* is based on the G?Open SH$ *$I 1*all $evel Inter!ace2, /hich is also the basis !or
Microso!t>s O%* inter!ace. 7he *$I is not a ne/ )uer( lan&ua&e. It is si'pl( a procedural
inter!ace to SH$.
FD+C Dri*ers
8%* drivers are either direct or O%* brid&ed direct driver sits on top o! the %MS>s native
inter!ace. 4or e6a'ple, S('antec provides direct drivers !or Oracle ,.G usin& O%*. IM
also provides a native 8%* driver !or its %2 products direct 'eans no transactions /ill be
done bet/een a 8%* pro&ra' and the database. 7his /ill be !aster and used in realCti'e
environ'ent.
In contrast to direct drivers, brid&ed drivers are built on the top o! e6istin& O%* drivers.
8%* is created a!ter O%*. *onse)uentl(, there e6ists a translation bet/een these the t/o
protocols. 7hese t(pes o! brid&e drivers are slo/ in co''unication. 8ava So!t and Intersolve
provide 8%* to O%* brid&e drivers that 'a=e it easier to translate bet/een 8%* and the
various O%* drivers. As a result, the 8%* applications, /e /rite are &uaranteed to be
portable across 'ulti vendor %MS. 7hat is, a 8%* pro&ra' is both plat!or'Cindependent
and dataCbaseCindependent.
All the classes and inter!aces re)uired !or /ritin& a 8%* pro&ra' are included in java.s)l
pac=a&e. 7he java.s)l pac=a&e is supplied /ith the core jd= so!t/are itsel!. 8%* drivers
provide i'ple'entation !or these classes and inter!aces o! java.s)l pac=a&e. 7he other
responsibilit( o! drivers is to 'aintain transaction reliabilit(. 7he drivers 'ust provide the
re)uired s(nchroni@ation protection.
Fa*a Database Connecti*it/ ?FD+C@

8%* is a set o! classes and Inter!ace used !or the purpose o! connectin& to a database usin&
applications developed in 8ava lan&ua&e. 7o &et a connection /ith the database, a %river,
/hich is the i'ple'entation o! 8%* API loaded. 7his driver is used to create a State'ent,
/hich is an object used to e6ecute SH$ )ueries. 0esult o! a state'ent is stored as 0esultSet.
FD+C Arc#itecture

JAVA
Application
JAVA
Application
JAVA
Application
JDBC TO ODBC
DRIVER
ODBC DRIVER
Sybase

DRIVER
Oracle
DRIVER
MS SQL
SERVER
SQL

DRIVER
Oracle
DATABASE
JDBC DRIVER MANAGER

11.% >eb Ser*ice
:eb services can be de!ined as loosel( coupled so!t/are co'ponents delivered over IP
net/or=s. 7he pri'ar( objective o! :eb services is to si'pli!( and standardi@e application
interoperabilit( /ithin and across co'panies, leadin& to increased operational e!!iciencies and
ti&hter partner relationships.
>eb ser*ice
A :eb service is a unit o! 'ana&ed code that can be re'otel( invo=ed usin& 377P, that is, it
can be activated usin& 377P re)uests.
3istoricall( spea=in&, re'ote access to binar( units re)uired plat!or'Cspeci!ic and so'eti'es
lan&ua&eCspeci!ic protocols. 4or e6a'ple, %*OM clients access re'ote *OM t(pes usin&
ti&htl( coupled 0P* calls. *O0A re)uires the use o! ti&htl( coupled protocol re!erred to as
Internet InterCO0 Protocol 1IIOP2, to activate re'ote t(pes. 9nterprise 8avaeans 198s2
re)uires a 0e'ote Method Invocation 10MI2 Protocol and b( and lar&e a speci!ic lan&ua&e
18ava2. 7hus each o! these re'ote invocation architectures needs proprietar( protocols, /hich
t(picall( re)uire a ti&ht connection to the re'ote source.
One can access :eb services usin& nothin& but 377P. O! all the protocols in e6istence toda(,
377P is the one speci!ic /ire protocol that all plat!or's tend to a&ree on. 7hus , usin& :eb
services, a :eb service developer can use an( lan&ua&e he /ish and a :eb service consu'er
can use standard 377P to invo=e 'ethods a :eb service provides. 7he botto' line is that /e
have true lan&ua&e and plat!or' inte&ration . Si'ple Object Access Protocol 1SOAP2 and
GM$ are also t/o =e( pieces o! the :eb services architecture.
>#at is a >eb Ser*ice
:eb services constitute a distributed co'puter architecture 'ade up o! 'an( di!!erent
co'puters tr(in& to co''unicate over the net/or= to !or' one s(ste'. 7he( consist o! a set
o! standards that allo/ developers to i'ple'ent distributed applications C usin& radicall(
di!!erent tools provided b( 'an( di!!erent vendors C to create applications that use a
co'bination o! so!t/are 'odules called !ro' s(ste's in disparate depart'ents or !ro' other
co'panies.
A :eb service contains so'e nu'ber o! classes, inter!aces, enu'erations and structures that
provide blac= bo6 !unctionalit( to re'ote clients. :eb services t(picall( de!ine business
objects that e6ecute a unit o! /or= 1e.&., per!or' a calculation, read a data source, etc.2 !or the

consu'er and /ait !or the ne6t re)uest. :eb service consu'er does not necessaril( need to be
a bro/serCbased client. *onsoleCbaed and :indo/s 4or'sCbased clients can consu'e a :eb
service. In each case, the client indirectl( interacts /ith the :eb service throu&h an
intervenin& pro6(. 7he pro6( loo=s and !eels li=e the real re'ote t(pe and e6poses the sa'e
set o! 'ethods. #nder the hood, the pro6( code reall( !or/ards the re)uest to the :eb service
usin& standard ATT" or optionall( S(A" 'essa&es.
>eb Ser*ice Standards
:eb services are re&istered and announced usin& the !ollo/in& services and protocols. Man(
o! these and other standards are bein& /or=ed out b( the #%%I project, a &roup o! industr(
leaders that is spearheadin& the earl( creation and desi&n e!!orts.
#niversal %escription, %iscover(, and Inte&ration 1#%%I2 is a protocol !or describin&
available :eb services co'ponents. 7his standard allo/s businesses to re&ister /ith an
Internet director( that /ill help the' advertise their services, so co'panies can !ind one
another and conduct transactions over the :eb. 7his re&istration and loo=up tas= is done usin&
GML and ATT"?S@Cbased 'echanis's.
Si'ple Object Access Protocol 1SOAP2 is a protocol !or initiatin& conversations /ith a #%%I
Service. SOAP 'a=es object access si'ple b( allo/in& applications to invo=e object 'ethods
or !unctions, residin& on re'ote servers. A SOAP application creates a re)uest bloc= in GM$,
suppl(in& the data needed b( the re'ote 'ethod as /ell as the location o! the re'ote object
itsel!.
:eb Service %escription $an&ua&e 1:S%$2, the proposed standard !or ho/ a :eb service is
described, is an GM$Cbased service I%$ 1Inter!ace %e!initition $an&ua&e2 that de!ines the
service inter!ace and its i'ple'entation characteristics. :S%$ is re!erenced b( #%%I entries
and describes the SOAP 'essa&es that de!ine a particular :eb service.
ebGM$ 1eCbusiness GM$2 de!ines core co'ponents, business processes, re&istr( and
repositor(, 'essa&in& services, tradin& partner a&ree'ents, and securit(.
I3&le3entin0 >eb Ser*ices
3ere co'es a brie! stepCb(Cstep on ho/ a :eb service is i'ple'ented.
A service provider creates a :eb service
7he service provider uses :S%$ to describe the service to a #%%I re&istr(

7he service provider re&isters the service in a #%%I re&istr( and?or ebGM$
re&istr(?repositor(.
Another service or consu'er locates and re)uests the re&istered service b( )uer(in&
#%%I and?or ebGM$ re&istries.
7he re)uestin& service or user /rites an application to bind the re&istered service usin&
SOAP in the case o! #%%I and?or ebGM$
%ata and 'essa&es are e6chan&ed as GM$ over 377P
>eb Ser*ice Infrastructure
9ven thou&h :eb services are bein& built usin& e6istin& in!rastructure, there e6ists a stron&
necessit( !or a nu'ber o! innovative in!rastructures. 7he core architectural !oundation o! :eb
services are GM$, GM$ na'espaces, and GM$ sche'a. #%%I, SOAP, :S%$, ebGM$ and
securit( standards are bein& developed in parallel b( di!!erent vendors
>eb Ser*ices Tec#nolo0ies and Tools
7here are a nu'ber o! 'echanis's !or constructin& :eb services. Microso!t has co'e out
/ith a ne/ objectCoriented lan&ua&e *W as the develop'ent lan&ua&e !or :eb services and
.<97 !ra'e/or=. Microso!t has an e6citin& tool called ;isual Studio .<97 in this re&ard. 7he
bac= end database can be Microso!t SH$ Server 2555 in :indo/s 2555 Pro!essional.
Sun Micros(ste's has its o/n set o! technolo&ies and tools !or !acilitatin& :eb services
develop'ent. 8ava Servlets, 8ava Server Pa&es 18SPs2, 9nterprise 8avaeans 1982
architecture and other 8ava 2 9nterprise 9dition 182992 technolo&ies pla( a ver( critical role in
developin& :eb services.
7here are a nu'ber o! tools !or developin& :eb services. 7he( are 4orte 8ava I%9, Oracle
8%eveloper, and :ebEain Studio.
Sun Micros(ste's has ta=en an initiative called Sun O<9 1Open <et/or= 9nviron'ent2 and
is plannin& to push 8ava !or/ard as a plat!or' !or :eb services. It is developin& 8ava APIs !or
GM$Cbased re'ote procedure calls and !or loo=in& up services in GM$ re&istries C t/o 'ore
8AG !a'il( APIsB 8AG?0P* 18ava API !or GM$ 0e'ote Procedure *alls2 and 8AG0 18ava
API !or GM$ 0e&istries2. 7hese /ill /rap up i'ple'entations o! :eb services standards,
such as SOAP and #%%I.
IM also !or its part has alread( developed a suite o! earl(Caccess tools !or :eb services
develop'ent. 7he( are :eb Services 7ool=it 1:S7R2, :S%$ 7ool=it, and :eb Services
%evelop'ent 9nviron'ent 1:S%92.

Apache A6is is an i'ple'entation o! the SOAP 1NSi'ple Object Access ProtocolN2 sub'ission
to :3*.
4ro' the dra!t :3* speci!icationB
SOAP is a li&ht/ei&ht protocol !or e6chan&in& structured in!or'ation in a decentrali@ed,
distributed environ'ent. It is an GM$ based protocol that consists o! three partsB an envelope
that de!ines a !ra'e/or= !or describin& /hat is in a 'essa&e and ho/ to process it, a set o!
encodin& rules !or e6pressin& instances o! applicationCde!ined datat(pes, and a convention !or
representin& re'ote procedure calls and responses.
Apache A6is is an Open Source SOAP server and client. SOAP is a 'echanis' !or interC
application co''unication bet/een s(ste's /ritten in arbitrar( lan&ua&es, across the Internet.
SOAP usuall( e6chan&es 'essa&es over 377PB the client POS7s a SOAP re)uest, and
receives either an 377P success code and a SOAP response or an 377P error code. Open
Source 'eans that (ou &et the source, but that there is no !or'al support or&ani@ation to help
(ou /hen thin&s &o /ron&.
4or the last !e/ (ears, GM$ has enabled hetero&eneous co'putin& environ'ents to share
in!or'ation over the :eb. It no/ o!!ers a si'pli!ied 'eans b( /hich to share process as /ell.
4ro' a technical perspective, the advent o! :eb services is not a revolution in distributed
co'putin&. It is instead a natural evolution o! GM$ application !ro' structured representation
o! in!or'ation to structured representation o! interCapplication 'essa&in&.
Prior to the advent o! :eb services, enterprise application inte&ration 19AI2 /as ver( di!!icult
due to di!!erences in pro&ra''in& lan&ua&es and 'iddle/are used /ithin or&ani@ations. 7his
led to the situation /here interoperabilit( /as cu'berso'e and pain!ul. :ith the arrival o!
:eb services, an( application can be inte&rated as lon& as it is InternetCenabled.
It is di!!icult to avoid the popularit( and h(pe that is surroundin& :eb services. 9ach so!t/are
vendor has so'e initiative concernin& :eb services and there is al/a(s &reat speculation
about the !uture o! the 'ar=et !or the'. :hichever /a( it turns out, :eb service architectures
provide a ver( di!!erent /a( o! thin=in& about so!t/are develop'ent. 4ro' clientCserver to nC
tier s(ste's, to distributed co'putin&, :eb service applications represent the cul'ination o!
each o! these architectures in co'bination /ith the Internet.

11.. BLASA +UILDER %..
:ith the rapid evolution o! 'obile co'putin& plat!or's, ne/ challen&es have e'er&ed !or
application developers. Much li=e the earl( da(s o! /eb and des=top co'putin&, each plat!or'
has its o/n develop'ent 'odel, includin& pro&ra''in& lan&ua&e, !ra'e/or=, tools, and
di!!erent deplo('ent options. 7hese challen&es add ti'e, cost, and co'ple6it( to deliverin&
applications across the /eb, the des=top, and the 'an( 'obile device plat!or's.
7he Adobe 4lash Plat!or' alread( enables developers to deliver consistent application
e6periences across 'ultiple bro/sers and operatin& s(ste's. :ith the introduction o! the
Adobe 4le6 4." S%R and Adobe 4lash uilder 4." so!t/are alon& /ith the availabilit( o! the
Adobe AI0 runti'e on 'obile devices, developers can no/ build 'obile 4le6 applications !or
touch screen s'art phones and tablets /ith the sa'e ease and )ualit( as on des=top plat!or's.
( providin& a co''on path to creatin& applications !or /eb, des=top, and 'ultiple 'obile
plat!or's, 4le6 and 4lash uilder can si&ni!icantl( reduce the ti'e and cost associated /ith

application develop'ent and testin& /hile providin& users /ith a consistent application
e6perience.
Mobile 2eb co3&onents
4le6 4." e6pands the e6tensive e6istin& /eb and des=top co'ponent librar( b( addin& 21 ne/
touchCenabled, opti'i@ed, and densit(Ca/are 'obile co'ponents, acceleratin& 'obile
application develop'ent. <e/ 'obile Spar= co'ponents include ;ie/, ;ie/<avi&ator,
7abbed;ie/<avi&atorF MobileApplication, ;ie/<avi&atorApplicationF ;ie/Menu,
;ie/MenuIte'F us( *ursorF S=innablePop#p*ontainerF ScrollerF $istF Ite'0endererF
utton, *hec=o6, 0adioutton, 7o&&leuttonF 7e6tArea, 7e6tInputF 3Slider, ;SliderF and
Actionar.
In addition to the ne/ 'obile co'ponents, 4le6 4." adds other i'portant capabilities and
i'prove'ents !or buildin& 'obile applications includin& =inetics and elastic bounce?pull
e!!ects !or scrollin& co'ponents, per!or'ance opti'i@ations !or scrollin& and transitions, autoC
scalin& based on device pi6el densit(, de!ault 'obile the'es includin& a li&htConCdar= color
sche'e !or 'obile co'ponent s=ins, native support !or =e(board input, splash screen support,
and 'ultiresolution bit'ap support.
Toolin0 for 3obile de*elo&3ent
4lash uilder 4." adds i'portant ne/ 'obile develop'ent /or=!lo/s to help (ou code,
debu&, and opti'i@e 'obile applications. It !eatures a ne/ 'obile project t(pe, ne/ desi&nC
vie/ perCdevice previe/, ne/ support !or 'ultidensit( authorin&, perCplat!or' application
per'issions editin&, and a po/er!ul ne/ debu&&in& /or=!lo/ that allo/s (ou to debu& on a
ph(sical device or on the des=top usin& a device e'ulator. Dou can deplo(, pac=a&e, and si&n
the re)uired resources as a plat!or'Cspeci!ic installer !ile !or upload to a 'obile application
distribution site or store.
Mobile &latfor3 su&&ort
Build apps for Android, Blackberry Playbook, iPone and iPad
oth 4le6 4." and 4lash uilder 4." provide !ull support !or buildin& and deplo(in& 'obile
4le6 and ActionScript applications !or Android, lac=berr( 7ablet OS, iPhone, and iPad.
Adobe 4lash uilder 1previousl( =no/n as Adobe 4le6 uilder2 is an inte&rated develop'ent
environ'ent 1I%92 built on the 9clipse plat!or' 'eant !or developin& rich Internet applications
10IAs2 and crossCplat!or' des=top applications, particularl( !or the Adobe 4lash plat!or'.

Support !or crossCplat!or' des=top applications /as added in 4le6 uilder 3 /ith the
introduction o! AI0.
Adobe 4lash 1!or'erl( Macro'edia 4lash2 is a proprietar( 'ulti'edia plat!or' used to add
ani'ation, video, and interactivit( to :eb pa&es. 4lash is !re)uentl( used !or advertise'ents and
&a'es. More recentl(, it has been positioned as a tool !or N0ich Internet ApplicationsN.
Res&onsi*eness
:hen the application responds directl( to a user>s co''and, or /hen the user can
directl( 'anipulate ele'ents on the screen, it en&enders a !eelin& o! connectedness and
responsiveness to the application. 7he user trusts the application, /hich !eels 'ore li=e a solidC
state 'achine than a harried librarian shuttlin& o!! to !etch the ne6t volu'e at a user>s re)uest.
"roducti*it/
<ot havin& to subtl( reCorient the'selves /ith each ne/ pa&e, users can opti'i@e their
!ocus and sta( en&a&ed /ith the tas=s at hand. 7he !eelin& o! a solidCstate 'achine also
e'po/ers the user to e6plore 'ore, /ithout !ear o! losin& the pa&eCoriented thread or havin& to
reload previous dataC!illed pa&es upon return.
User &ersistence
7he !eelin& o! connectedness to the application, /ithout pa&e transitions that cause
attention &aps, =eeps users 'ore co''itted throu&hout the course o! an application tas=. 9ach
attention &ap provides an openin& !or a user to shi!t his or her attention and 'ove to a di!!erent
tas=, application or site.
Inte0rated de*elo&3ent en*iron3ent
An inte&rated develop'ent environ'ent 1I%92 also =no/n as inte&rated desi&n environ'ent or
inte&rated debu&&in& environ'ent is a so!t/are application that provides co'prehensive
!acilities to co'puter pro&ra''ers !or so!t/are develop'ent. An I%9 nor'all( consists o!B
Source code editor

*o'piler and?or an interpreter
uild auto'ation tools
%ebu&&er
11.5 Android
Android is a 'obile operatin& s(ste' !or 'obile devices such as 'obile phones and tablet
co'puters developed b( the Open 3andset Alliance led b( Eoo&le.
Eoo&le purchased the initial developer o! the so!t/are, Android Inc., in 255". 7he unveilin& o!
the Android distribution on " <ove'ber 255, /as announced /ith the !oundin& o! the Open
3andset Alliance, a consortiu' o! -5 hard/are, so!t/are, and teleco''unication co'panies
devoted to advancin& open standards !or 'obile devices. Eoo&le released 'ost o! the Android
code under the Apache $icense, a !ree so!t/are license. 7he Android Open Source Project
1AOSP2 is tas=ed /ith the 'aintenance and !urther develop'ent o! Android.
Android consists o! a =ernel based on the $inu6 =ernel, /ith 'iddle/are, libraries and APIs
/ritten in * and application so!t/are runnin& on an application !ra'e/or= /hich includes
8avaCco'patible libraries based on Apache 3ar'on(. Android uses the %alvi= virtual 'achine
/ith justCinCti'e co'pilation to run co'piled 8ava code. Android has a lar&e co''unit( o!
developers /ritin& applications 1NappsN2 that e6tend the !unctionalit( o! the devices.
%evelopers /rite pri'aril( in 8ava. 7here are currentl( 'ore than 2"5,555 apps available !or
Android. Android Mar=et is the online app store run b( Eoo&le, thou&h apps can also be
do/nloaded !ro' thirdCpart( sites.
Boundation
Android, Inc. /as !ounded in Palo Alto, *ali!ornia, #nited States in October, 2553 b( And(
0ubin 1coC!ounder o! %an&er2, 0ich Miner 1coC!ounder o! :ild!ire *o''unications, Inc.2,
<ic= Sears 1once ;P at 7CMobile2, and *hris :hite 1headed desi&n and inter!ace develop'ent
at :eb7;2 to develop, in 0ubinMs /ords N...s'arter 'obile devices that are 'ore a/are o! its
o/nerMs location and pre!erencesN. %espite the obvious past acco'plish'ents o! the !ounders
and earl( e'plo(ees, Android Inc. operated secretivel(, revealin& onl( that it /as /or=in& on
so!t/are !or 'obile phones.
7hat sa'e (ear, 0ubin ran out o! cash. Steve Perl'an brou&ht hi' X15,555 in cash in an
envelope and re!used a sta=e in the co'pan(.

Ac4uisition b/ -oo0le
Eoo&le ac)uired Android Inc. in Au&ust 255", 'a=in& Android Inc. a /holl( o/ned
subsidiar( o! Eoo&le Inc. Re( e'plo(ees o! Android Inc., includin& And( 0ubin, 0ich Miner
and *hris :hite, sta(ed at the co'pan( a!ter the ac)uisition.
<ot 'uch /as =no/n about Android Inc. at the ti'e o! the ac)uisition, but 'an( assu'ed that
Eoo&le /as plannin& to enter the 'obile phone 'ar=et /ith this 'ove.
Version #istor/
Android has seen a nu'ber o! updates since its ori&inal release. 7hese updates to the base
operatin& s(ste' t(picall( !i6 bu&s and add ne/ !eatures. Eenerall(, each ne/ version o! the
Android operatin& s(ste' is developed under a code na'e based on a dessert ite'. Past
updates included *upca=e and %onut. 7he code na'es are in alphabetical order 1*upca=e,
%onut, 9clair, 4ro(o, Ein&erbread, 3one(co'b, and the upco'in& Ice *rea' Sand/ich2.
elo/ is a list o! the 'ost recent versions, and /hat the( includeB
!.9 ?Eclair@ included a ne/ /eb bro/ser, /ith a ne/ user inter!ace and support !or
37M$" and the :3* Eeolocation API. It also included an enhanced ca'era app /ith
!eatures li=e di&ital @oo', !lash, color e!!ects, and 'ore.
!.1 ?Eclair@ included support !or voice controls throu&hout the entire OS. It also included
a ne/ launcher, /ith " ho'escreens instead o! 3, ani'ated bac=&rounds, and a button to
open the 'enu 1instead o! a slider2. It also included a ne/ /eather app, and i'proved
!unctionalit( in the 9'ail and Phoneboo= apps.
!.! ?Bro/o@ introduced speed i'prove'ents /ith 8I7 opti'i@ation and the *hro'e ;-
8avaScript en&ine, and added :iC4i hotspot tetherin& and Adobe 4lash support
!.$ ?-in0erbread@ re!ined the user inter!ace, i'proved the so!t =e(board and cop(?paste
!eatures, and added support !or <ear 4ield *o''unication
$.9 ?Aone/co3b@ /as a tabletCoriented release /hich supports lar&er screen devices and
introduces 'an( ne/ user inter!ace !eatures, and supports 'ulticore processors and
hard/are acceleration !or &raphics.
K""L
7he 3one(co'b S%R has been released and the
!irst device !eaturin& this version, the Motorola Goo' tablet, /ent on sale in 4ebruar(
2511.
$.1 ?Aone/co3b@ /as announced at the 2511 Eoo&le I?O on 15 Ma( 2511. C 7o allo/
hone(co'b devices to directl( trans!er content !ro' #S devices
$.! ?Aone/co3b@ is Nan incre'ental release that adds several ne/ capabilities !or users
and developersN. 3i&hli&hts include opti'i@ation !or a broader ran&e o! screen si@esF ne/
N@oo'CtoC!illN screen co'patibilit( 'odeF capabilit( to load 'edia !iles directl( !ro' the
S% cardF and an e6tended screen support API, providin& developers /ith 'ore precise
control over the #I.

4uture releases that have been announced includeB
%.9 ?Ice Crea3 Sand2ic#@ is said to be a co'bination o! Ein&erbread and 3one(co'b
into a Ncohesive /holeN.It /ill be released in H4 2511.
Desi0n
AndroidMs =ernel is derived !ro' the $inu6 =ernel. Eoo&le contributed code to the $inu6
=ernel as part o! their Android e!!ort, but certain !eatures, notabl( a po/er 'ana&e'ent !eature
called /a=eloc=s, /ere rejected b( 'ainline =ernel developers, so the Android =ernel is no/ a
separate version or !or= o! the $inu6 =ernel.
Eoo&le announced in April 2515 that the( /ould hire t/o e'plo(ees to /or= /ith the $inu6
=ernel co''unit(. Ere& RroahC3art'an, the current $inu6 =ernel 'aintainer !or the Cstable
branch, said in %ece'ber 2515 that he /as concerned that Eoo&le /as no lon&er tr(in& to &et
their code chan&es included in 'ainstrea' $inu6. So'e Eoo&le Android developers hinted
that Nthe Android tea' /as &ettin& !ed up /ith the processN, because the( /ere a s'all tea'
and had 'ore ur&ent /or= to do on Android.
Android does not have a native G :indo/ S(ste' nor does it support the !ull set o! standard
E<# libraries, and this 'a=es it di!!icult to port e6istin& E<#?$inu6 applications or libraries
to Android. 3o/ever, support !or the G :indo/ S(ste' is possible.
Beatures

7he Android 9'ulator de!ault ho'e screen 1v1."2
Architecture dia&ra'
*urrent !eatures and speci!icationsB
3andset la(outs
7he plat!or' is adaptable to lar&er, ;EA, 2% &raphics librar(, 3% &raphics librar( based
on OpenE$ 9S 2.5 speci!ications, and traditional s'artphone la(outs.
Stora&e
SH$ite, a li&ht/ei&ht relational database, is used !or data stora&e purposes.
*onnectivit(
Android supports connectivit( technolo&ies includin& ESM?9%E9, I%9<, *%MA, 9;C
%O, #M7S, luetooth, :iC4i, $79, <4* and :iMAG.
Messa&in&
SMS and MMS are available !or's o! 'essa&in&, includin& threaded te6t 'essa&in& and
no/ Android *loud 7o %evice Messa&in& 4ra'e/or=1*2%M2 is also a part o! Android
Push Messa&in& service.
Multiple lan&ua&e support
Android supports 'ultiple hu'an lan&ua&es. 7he nu'ber o! lan&ua&es 'ore than
doubled !or the plat!or' 2.3 Ein&erbread. Android lac=s !ont renderin& o! several
lan&ua&es even a!ter o!!icial announce'ents
K
o! added support 1e.&. 3indi2.

:eb bro/ser
7he /eb bro/ser available in Android is based on the openCsource :ebRit la(out en&ine,
coupled /ith *hro'eMs ;- 8avaScript en&ine. 7he bro/ser scores a .3?155 on the Acid3
7est.
8ava support
:hile 'ost Android applications are /ritten in 8ava, there is no 8ava ;irtual Machine in
the plat!or' and 8ava b(te code is not e6ecuted. 8ava classes are co'piled into %alvi=
e6ecutables and run on %alvi=, a speciali@ed virtual 'achine desi&ned speci!icall( !or
Android and opti'i@ed !or batter(Cpo/ered 'obile devices /ith li'ited 'e'or( and
*P#. 82M9 support can be provided via thirdCpart( applications.
Media support
Android supports the !ollo/in& audio?video?still 'edia !or'atsB :ebM, 3.2+3, 3.2+4 1in
3EP or MP4 container2, MP9EC4 SP, AM0, AM0C: 1in 3EP container2, AA*, 39C
AA* 1in MP4 or 3EP container2, MP3, MI%I, O&& ;orbis, 4$A*, :A;, 8P9E, P<E,
EI4, MP.
Strea'in& 'edia support
07P?07SP strea'in& 13EPP PSS, ISMA2, 37M$ pro&ressive do/nload 137M$"
IvideoJ ta&2. Adobe 4lash Strea'in& 107MP2 and 377P %(na'ic Strea'in& are
supported b( the 4lash plu&in. Apple 377P $ive Strea'in& is supported b( 0ealPla(er
!or Mobile, and b( the operatin& s(ste' in Android 3.5 13one(co'b2.
Additional hard/are support
Android can use video?still ca'eras, touchscreens, EPS, accelero'eters, &(roscopes,
'a&neto'eters, dedicated &a'in& controls, pro6i'it( and pressure sensors,
ther'o'eters, accelerated 2% bit blits 1/ith hard/are orientation, scalin&, pi6el !or'at
conversion2 and accelerated 3% &raphics.
MultiCtouch
Android has native support !or 'ultiCtouch /hich /as initiall( 'ade available in
handsets such as the 37* 3ero. 7he !eature /as ori&inall( disabled at the =ernel level
1possibl( to avoid in!rin&in& AppleMs patents on touchCscreen technolo&( at the ti'e2.
Eoo&le has since released an update !or the <e6us One and the Motorola %roid /hich
enables 'ultiCtouch nativel(.
luetooth

Supports A2%P, A;0*P, sendin& !iles 1OPP2, accessin& the phone boo= 1PAP2, voice
dialin& and sendin& contacts bet/een phones. Re(board, 'ouse and jo(stic= 13I%2
support is available in Android 3.1T, and in earlier versions throu&h 'anu!acturer
custo'i@ations and thirdCpart( applications.
;ideo callin&
Android does not support native video callin&, but so'e handsets have a custo'i@ed
version o! the operatin& s(ste' that supports it, either via the #M7S net/or= 1li=e the
Sa'sun& Eala6( S2 or over IP. ;ideo callin& throu&h Eoo&le 7al= is available in Android
2.3.4 and later. Ein&erbread allo/s <e6us S to place Internet calls /ith a SIP account.
7his allo/s !or enhanced ;oIP dialin& to other SIP accounts and even phone nu'bers.
S=(pe 2.1 o!!ers video callin& in Android 2.3, includin& !ront ca'era support.
Multitas=in&
Multitas=in& o! applications is available.
;oice based !eatures
Eoo&le search throu&h voice has been available since initial release. ;oice actions !or
callin&, te6tin&, navi&ation, etc. are supported on Android 2.2 on/ards.
7etherin&
Android supports tetherin&, /hich allo/s a phone to be used as a /ireless?/ired :iC4i
hotspot. e!ore Android 2.2 this /as supported b( thirdCpart( applications or
'anu!acturer custo'i@ations.
Screen capture
Android does not support screenshot capture as o! 2511. 7his is supported b(
'anu!acturer and thirdCpart( custo'i@ations. Screen *apture is available throu&h a P*
connection usin& the %%MS developerMs tool.

1!. Testin0
A pri'ar( purpose !or testin& is to detect so!t/are !ailures so that de!ects 'a( be uncovered and
corrected. 7his is a nonCtrivial pursuit. 7estin& cannot establish that a product !unctions properl(
under all conditions but can onl( establish that it does not !unction properl( under speci!ic
conditions. 7he scope o! so!t/are testin& o!ten includes e6a'ination o! code as /ell as e6ecution
o! that code in various environ'ents and conditions as /ell as e6a'inin& the aspects o! codeB
does it do /hat it is supposed to do and do /hat it needs to do. In the current culture o! so!t/are
develop'ent, a testin& or&ani@ation 'a( be separate !ro' the develop'ent tea'. 7here are
various roles !or testin& tea' 'e'bers. In!or'ation derived !ro' so!t/are testin& 'a( be used
to correct the process b( /hich so!t/are is developed.
Defects and failures
<ot all so!t/are de!ects are caused b( codin& errors. One co''on source o! e6pensive de!ects is
caused b( re)uire'ents &aps, e.&., unreco&ni@ed re)uire'ents that result in errors o! o'ission b(
the pro&ra' desi&ner. A co''on source o! re)uire'ents &aps is nonC!unctional re)uire'ents
such as testabilit(, scalabilit(, 'aintainabilit(, usabilit(, per!or'ance, and securit(.
So!t/are !aults occur throu&h the !ollo/in& process. A pro&ra''er 'a=es an error 1'ista=e2,
/hich results in a de!ect 1!ault, bu&2 in the so!t/are source code. I! this de!ect is e6ecuted, in
certain situations the s(ste' /ill produce /ron& results, causin& a !ailure. <ot all de!ects /ill
necessaril( result in !ailures. 4or e6a'ple, de!ects in dead code /ill never result in !ailures. A
de!ect can turn into a !ailure /hen the environ'ent is chan&ed. 96a'ples o! these chan&es in
environ'ent include the so!t/are bein& run on a ne/ hard/are plat!or', alterations in source
data or interactin& /ith di!!erent so!t/are. A sin&le de!ect 'a( result in a /ide ran&e o! !ailure
s('pto's.
Co3&atibilit/
A !re)uent cause o! so!t/are !ailure is co'patibilit( /ith another application or ne/ operatin&
s(ste' 1or, increasin&l( /eb bro/ser version2. In the case o! lac= o! bac=/ard co'patibilit( this
can occur because the pro&ra''ers have onl( considered codin& the pro&ra's !or, or testin& the
so!t/are, on the latest operatin& s(ste' the( have access to or else, in isolation 1no other
con!lictin& applications runnin& at the sa'e ti'e2 or under MidealM conditions 1Munli'itedM
'e'or(F Msuper!astM processorF latest operatin& s(ste' incorporatin& all updates, etc2. In e!!ect,
ever(thin& is runnin& Nas intendedN but onl( /hen e6ecutin& at the sa'e ti'e on the sa'e
'achine /ith the particular co'bination o! so!t/are and?or hard/are. 7hese are so'e o! the
hardest !ailures to predict, detect and test !or and 'an( are there!ore discovered onl( a!ter
release into the lar&er /orld /ith its lar&el( un=no/n 'i6 o! applications, so!t/are and
hard/are. It is li=el( that an e6perienced pro&ra''er /ill have had e6posure to these !actors
throu&h NcoCevolutionN /ith several older s(ste's and be 'uch 'ore a/are o! potential !uture
co'patibilit( proble's and there!ore tend to use tried and tested !unctions or instructions rather

than al/a(s the latest available /hich 'a( not be !ull( co'patible /ith earlier 'i6tures o!
so!t/are?hard/are. 7his could be considered a prevention oriented strate&( that !its /ell /ith the
latest testin& phase su&&ested b( %ave Eelperin and :illia' *. 3et@el cited belo/.
In&ut co3binations and &reconditions
A proble' /ith so!t/are testin& is that testin& under all co'binations o! inputs and
preconditions 1initial state2 is not !easible, even /ith a si'ple product. 7his 'eans that the
nu'ber o! de!ects in a so!t/are product can be ver( lar&e and de!ects that occur in!re)uentl( are
di!!icult to !ind in testin&. More si&ni!icantl(, nonC!unctional di'ensions o! )ualit( 1ho/ it is
supposed to be versus /hat it is supposed to do2 CC !or e6a'ple, usabilit(, scalabilit(,
per!or'ance, co'patibilit(, reliabilit( CC can be hi&hl( subjectiveF so'ethin& that constitutes
su!!icient value to one person 'a( be intolerable to another.
Static *s. d/na3ic testin0
7here are 'an( approaches to so!t/are testin&. 0evie/s, /al=throu&hs or inspections are
considered as static testin&, /hereas actuall( e6ecutin& pro&ra''ed code /ith a &iven set o! test
cases is re!erred to as d(na'ic testin&. 7he !or'er can be, and un!ortunatel( in practice o!ten is,
o'itted, /hereas the latter ta=es place /hen pro&ra's be&in to be used !or the !irst ti'e C /hich
is nor'all( considered the be&innin& o! the testin& sta&e. 7his 'a( actuall( be&in be!ore the
pro&ra' is 155Y co'plete in order to test particular sections o! code 1'odules or discrete
!unctions2. 4or e6a'ple, Spreadsheet pro&ra's are, b( their ver( nature, tested to a lar&e e6tent
Non the !l(N durin& the build process as the result o! so'e calculation or te6t 'anipulation is
sho/n interactivel( i''ediatel( a!ter each !or'ula is entered.
Soft2are *erification and *alidation
So!t/are testin& is used in association /ith veri!ication and validationB
;eri!icationB 3ave /e built the so!t/are ri&ht 1i.e., does it 'atch the speci!icationZ2Z It is
process based.
;alidationB 3ave /e built the ri&ht so!t/are 1i.e., is this /hat the custo'er /antsZ2Z It is
product based.
T#e soft2are testin0 tea3
So!t/are testin& can be done b( so!t/are testers. #ntil the 1."5s the ter' Nso!t/are testerN /as
used &enerall(, but later it /as also seen as a separate pro!ession. 0e&ardin& the periods and the
di!!erent &oals in so!t/are testin& there have been established di!!erent rolesB test lead?'ana&er,
test desi&ner, tester, test auto'ater?auto'ation developer, and test ad'inistrator.

Soft2are Hualit/ Assurance ?SHA@
7hou&h controversial, so!t/are testin& 'a( be vie/ed as an i'portant part o! the so!t/are
)ualit( assurance 1SHA2 process. In SHA, so!t/are process specialists and auditors ta=e a
broader vie/ on so!t/are and its develop'ent. 7he( e6a'ine and chan&e the so!t/are
en&ineerin& process itsel! to reduce the a'ount o! !aults that end up in de!ect rate. :hat
constitutes an acceptable de!ect rate depends on the nature o! the so!t/are. An arcade video
&a'e desi&ned to si'ulate !l(in& an airplane /ould presu'abl( have a 'uch hi&her tolerance
!or de!ects than 'ission critical so!t/are such as that used to control the !unctions o! an airliner.
Althou&h there are close lin=s /ith SHA, testin& depart'ents o!ten e6ist independentl(, and
there 'a( be no SHA !unction in so'e co'panies.
So!t/are 7estin& is a tas= intended to detect de!ects in so!t/are b( contrastin& a co'puter
pro&ra'Ms e6pected results /ith its actual results !or a &iven set o! inputs. ( contrast, HA is the
i'ple'entation o! policies and procedures intended to prevent de!ects !ro' occurrin& in the !irst
Testin0 3et#ods
So!t/are testin& 'ethods are traditionall( divided into blac= bo6 testin& and /hite bo6 testin&.
7hese t/o approaches are used to describe the point o! vie/ that a test en&ineer ta=es /hen
desi&nin& test cases.
+lac= boE testin0
lac= bo6 testin& treats the so!t/are as a blac= bo6 /ithout an( =no/led&e o! internal
i'ple'entation. lac= bo6 testin& 'ethods include e)uivalence partitionin&, boundar( value
anal(sis, allCpairs testin&, !u@@ testin&, 'odelCbased testin&, traceabilit( 'atri6, e6plorator(
testin& and speci!icationCbased testin&.
Speci!icationCbased testin&
Speci!icationCbased testin& ai's to test the !unctionalit( accordin& to the re)uire'ents. 7hus,
the tester inputs data and onl( sees the output !ro' the test object. 7his level o! testin&
usuall( re)uires thorou&h test cases to be provided to the tester /ho then can si'pl( veri!(
that !or a &iven input, the output value 1or behavior2, is the sa'e as the e6pected value
speci!ied in the test case.
Speci!icationCbased testin& is necessar( but insu!!icient to &uard a&ainst certain ris=s.
Ad*anta0es and disad*anta0es
7he blac= bo6 tester has no NbondsN /ith the code, and a testerMs perception is ver( si'pleB a
code M#S7 have bu&s. #sin& the principle, NAs= and (ou shall receive,N blac= bo6 testers
!ind bu&s /here pro&ra''ers donMt. #7, on the other hand, blac= bo6 testin& is li=e a /al=
in a dar= lab(rinth /ithout a !lashli&ht, because the tester doesnMt =no/ ho/ the bac= end
/as actuall( constructed. 7hatMs /h( there are situations /hen 1. A blac= bo6 tester /rites
'an( test cases to chec= so'ethin& that can be tested b( onl( one test case and?or 2. So'e
parts o! the bac= end are not tested at all

7here!ore, blac= bo6 testin& has the advanta&e o! an una!!iliated opinion on the one hand and the
disadvanta&e o! blind e6plorin& on the other.
>#ite boE testin0
:hite bo6 testin&, b( contrast to blac= bo6 testin&, is /hen the tester has access to the internal
data structures and al&orith's 1and the code that i'ple'ent these2
7(pes o! /hite bo6 testin&
7he !ollo/in& t(pes o! /hite bo6 testin& e6istB
api testin& C 7estin& o! the application usin& Public and Private APIs.
code covera&e C creatin& tests to satis!( so'e criteria o! code covera&e. 4or
e6a'ple, the test desi&ner can create tests to cause all state'ents in the pro&ra'
to be e6ecuted at least once.
!ault injection 'ethods.
'utation testin& 'ethods.
static testin& C :hite bo6 testin& includes all static testin&.
Code co3&leteness e*aluation
:hite bo6 testin& 'ethods can also be used to evaluate the co'pleteness o! a test suite
that /as created /ith blac= bo6 testin& 'ethods. 7his allo/s the so!t/are tea' to
e6a'ine parts o! a s(ste' that are rarel( tested and ensures that the 'ost i'portant
!unction points have been tested.
7/o co''on !or's o! code covera&e areB
Function coverage, /hich reports on !unctions e6ecuted and statement coverage,
/hich reports on the nu'ber o! lines e6ecuted to co'plete the test.
7he( both return covera&e 'etric, 'easured as a percenta&e.
-re/ +oE Testin0
In recent (ears the ter' &re( bo6 testin& has co'e into co''on usa&e. 7his involves havin&
access to internal data structures and al&orith's !or purposes o! desi&nin& the test cases, but
testin& at the user, or blac=Cbo6 level. Manipulatin& input data and !or'attin& output do not
)uali!( as &re(Cbo6 because the input and output are clearl( outside o! the blac=Cbo6 /e are
callin& the so!t/are under test. 7his is particularl( i'portant /hen conductin& inte&ration testin&
bet/een t/o 'odules o! code /ritten b( t/o di!!erent developers, /here onl( the inter!aces are
e6posed !or test. Ere( bo6 testin& 'a( also include reverse en&ineerin& to deter'ine, !or
instance, boundar( values or error 'essa&es.
Acce&tance testin0
Acceptance testin& can 'ean one o! t/o thin&sB

1. A s'o=e test is used as an acceptance test prior to introducin& a build to the 'ain
testin& process.
2. Acceptance testin& per!or'ed b( the custo'er is =no/n as user acceptance
testin& 1#A72.
Re0ression Testin0
Re0ression testin0 is an( t(pe o! soft2are testin0 that see=s to uncover so!t/are re&ressions.
Such re&ressions occur /henever so!t/are !unctionalit( that /as previousl( /or=in& correctl(
stops /or=in& as intended. 7(picall( re&ressions occur as an unintended conse)uence o! pro&ra'
chan&es. *o''on 'ethods o! re&ression testin& include reCrunnin& previousl( run tests and
chec=in& /hether previousl( !i6ed !aults have reCe'er&ed.
Non Bunctional Soft2are Testin0
Special 'ethods e6ist to test nonC!unctional aspects o! so!t/are.
Per!or'ance testin& chec=s to see i! the so!t/are can handle lar&e )uantities o!
data or users. 7his is &enerall( re!erred to as so!t/are scalabilit(. 7his activit( o! <on
4unctional So!t/are 7estin& is o!ten ti'es re!erred to as $oad 7estin&.
#sabilit( testin& is needed to chec= i! the user inter!ace is eas( to use and
understand.
Securit( testin& is essential !or so!t/are /hich processes con!idential data and to
prevent s(ste' intrusion b( hac=ers.
Internationali@ation and locali@ation is needed to test these aspects o! so!t/are, !or
/hich a pseudo locali@ation 'ethod can be used.
In contrast to !unctional testin&, /hich establishes the correct operation o! the so!t/are 1correct
in that it 'atches the e6pected behavior de!ined in the desi&n re)uire'ents2, nonC!unctional
testin& veri!ies that the so!t/are !unctions properl( even /hen it receives invalid or une6pected
inputs. So!t/are !ault injection, in the !or' o! !u@@in& is an e6a'ple o! nonC!unctional testin&.
<onC!unctional testin&, especiall( !or so!t/are, is desi&ned to establish /hether the device under
test can tolerate invalid or une6pected inputs, thereb( establishin& the robustness o! input
validation routines as /ell as errorChandlin& routines. ;arious co''ercial nonC!unctional testin&
tools are lin=ed !ro' the So!t/are !ault injection pa&eF there are also nu'erous openCsource and
!ree so!t/are tools available that per!or' nonC!unctional testin&.
Testin0 &rocess
A co''on practice o! so!t/are testin& is per!or'ed b( an independent &roup o! testers a!ter the
!unctionalit( is developed be!ore it is shipped to the custo'er. 7his practice o!ten results in the
testin& phase bein& used as project bu!!er to co'pensate !or project dela(s, thereb(
co'pro'isin& the ti'e devoted to testin&. Another practice is to start so!t/are testin& at the
sa'e 'o'ent the project starts and it is a continuous process until the project !inishes.

In counterpoint, so'e e'er&in& so!t/are disciplines such as e6tre'e pro&ra''in& and the a&ile
so!t/are develop'ent 'ove'ent, adhere to a NtestCdriven so!t/are develop'entN 'odel. In this
process unit tests are /ritten !irst, b( the so!t/are en&ineers 1o!ten /ith pair pro&ra''in& in the
e6tre'e pro&ra''in& 'ethodolo&(2. O! course these tests !ail initiall(F as the( are e6pected to.
7hen as code is /ritten it passes incre'entall( lar&er portions o! the test suites. 7he test suites
are continuousl( updated as ne/ !ailure conditions and corner cases are discovered, and the( are
inte&rated /ith an( re&ression tests that are developed. #nit tests are 'aintained alon& /ith the
rest o! the so!t/are source code and &enerall( inte&rated into the build process 1/ith inherentl(
interactive tests bein& rele&ated to a partiall( 'anual build acceptance process2.
7estin& can be done on the !ollo/in& levelsB
#nit testin& tests the 'ini'al so!t/are co'ponent, or 'odule. 9ach unit 1basic
co'ponent2 o! the so!t/are is tested to veri!( that the detailed desi&n !or the unit has
been correctl( i'ple'ented. In an objectCoriented environ'ent, this is usuall( at the class
level, and the 'ini'al unit tests include the constructors and destructors.
Inte&ration testin& e6poses de!ects in the inter!aces and interaction bet/een
inte&rated co'ponents 1'odules2. Pro&ressivel( lar&er &roups o! tested so!t/are
co'ponents correspondin& to ele'ents o! the architectural desi&n are inte&rated and
tested until the so!t/are /or=s as a s(ste'.
S(ste' testin& tests a co'pletel( inte&rated s(ste' to veri!( that it 'eets its
re)uire'ents.
S(ste' inte&ration testin& veri!ies that a s(ste' is inte&rated to an( e6ternal or
third part( s(ste's de!ined in the s(ste' re)uire'ents.
e!ore shippin& the !inal version o! so!t/are, alpha and beta testin& are o!ten done additionall(B
Alpha testin& is si'ulated or actual operational testin& b( potential
users?custo'ers or an independent test tea' at the developersM site. Alpha testin& is o!ten
e'plo(ed !or o!!CtheCshel! so!t/are as a !or' o! internal acceptance testin&, be!ore the
so!t/are &oes to beta testin&.
eta testin& co'es a!ter alpha testin&. ;ersions o! the so!t/are, =no/n as beta
versions, are released to a li'ited audience outside o! the pro&ra''in& tea'. 7he
so!t/are is released to &roups o! people so that !urther testin& can ensure the product has
!e/ !aults or bu&s. So'eti'es, beta versions are 'ade available to the open public to
increase the !eedbac= !ield to a 'a6i'al nu'ber o! !uture users.
4inall(, acceptance testin& can be conducted b( the endCuser, custo'er, or client to validate
/hether or not to accept the product. Acceptance testin& 'a( be per!or'ed as part o! the handC
o!! process bet/een an( t/o phases o! develop'ent.
Re0ression testin0

A!ter 'odi!(in& so!t/are, either !or a chan&e in !unctionalit( or to !i6 de!ects, a re&ression test
reCruns previousl( passin& tests on the 'odi!ied so!t/are to ensure that the 'odi!ications havenMt
unintentionall( caused a re&ression o! previous !unctionalit(. 0e&ression testin& can be
per!or'ed at an( or all o! the above test levels. 7hese re&ression tests are o!ten auto'ated.
More speci!ic !or's o! re&ression testin& are =no/n as sanit( testin&, /hen )uic=l( chec=in& !or
bi@arre behavior, and s'o=e testin& /hen testin& !or basic !unctionalit(.
ench'ar=s 'a( be e'plo(ed durin& re&ression testin& to ensure that the per!or'ance o! the
ne/l( 'odi!ied so!t/are /ill be at least as acceptable as the earlier version or, in the case o!
code opti'i@ation, that so'e real i'prove'ent has been achieved.
Testin0 Tools
Pro&ra' testin& and !ault detection can be aided si&ni!icantl( b( testin& tools and debu&&ers.
7(pes o! testin&?debu& tools include !eatures such asB
Pro&ra' 'onitors, per'ittin& !ull or partial 'onitorin& o! pro&ra' code includin&B
o Instruction Set Si'ulator, per'ittin& co'plete instruction level 'onitorin& and
trace !acilities
o Pro&ra' ani'ation, per'ittin& stepCb(Cstep e6ecution and conditional brea=point
at source level or in 'achine code
o code covera&e reports
4or'atted du'p or S('bolic debu&&in&, tools allo/in& inspection o! pro&ra' variables
on error or at chosen points
ench'ar=s, allo/in& runCti'e per!or'ance co'parisons to be 'ade
Per!or'ance anal(sis, or pro!ilin& tools that can help to hi&hli&ht hot spots and resource
usa&e
So'e o! these !eatures 'a( be incorporated into an inte&rated develop'ent environ'ent 1I%92.
Measurin0 soft2are testin0
#suall(, )ualit( is constrained to such topics as correctness, co'pleteness, securit(,
Kcitation neededL
but
can also include 'ore technical re)uire'ents as described under the ISO standard ISO .12+,
such as capabilit(, reliabilit(, e!!icienc(, portabilit(, 'aintainabilit(, co'patibilit(, and usabilit(.
7here are a nu'ber o! co''on so!t/are 'easures, o!ten called N'etricsN, /hich are used to
'easure the state o! the so!t/are or the ade)uac( o! the testin&.
Testin0 artifacts

So!t/are testin& process can produce several arti!acts.
Test case
A test case in so!t/are en&ineerin& nor'all( consists o! a uni)ue identi!ier, re)uire'ent
re!erences !ro' a desi&n speci!ication, preconditions, events, a series o! steps 1also
=no/n as actions2 to !ollo/, input, output, e6pected result, and actual result. *linicall(
de!ined a test case is an input and an e6pected result. 7his can be as pra&'atic as M!or
condition 6 (our derived result is (M, /hereas other test cases described in 'ore detail the
input scenario and /hat results 'i&ht be e6pected. It can occasionall( be a series o! steps
1but o!ten steps are contained in a separate test procedure that can be e6ercised a&ainst
'ultiple test cases, as a 'atter o! econo'(2 but /ith one e6pected result or e6pected
outco'e. 7he optional !ields are a test case I%, test step or order o! e6ecution nu'ber,
related re)uire'ent1s2, depth, test cate&or(, author, and chec= bo6es !or /hether the test
is auto'atable and has been auto'ated. $ar&er test cases 'a( also contain prere)uisite
states or steps, and descriptions. A test case should also contain a place !or the actual
result. 7hese steps can be stored in a /ord processor docu'ent, spreadsheet, database, or
other co''on repositor(. In a database s(ste', (ou 'a( also be able to see past test
results and /ho &enerated the results and the s(ste' con!i&uration used to &enerate those
results. 7hese past results /ould usuall( be stored in a separate table.
Test scri&t
7he test script is the co'bination o! a test case, test procedure, and test data. Initiall( the
ter' /as derived !ro' the product o! /or= created b( auto'ated re&ression test tools.
7oda(, test scripts can be 'anual, auto'ated, or a co'bination o! both.
Test data
7he 'ost co''on test 'anuall( or in auto'ation is retestin& and re&ression testin&, In
'ost cases, 'ultiple sets o! values or data are used to test the sa'e !unctionalit( o! a
particular !eature. All the test values and chan&eable environ'ental co'ponents are
collected in separate !iles and stored as test data. It is also use!ul to provide this data to
the client and /ith the product or a project.
Test suite
7he 'ost co''on ter' !or a collection o! test cases is a test suite. 7he test suite o!ten
also contains 'ore detailed instructions or &oals !or each collection o! test cases. It
de!initel( contains a section /here the tester identi!ies the s(ste' con!i&uration used
durin& testin&. A &roup o! test cases 'a( also contain prere)uisite states or steps, and
descriptions o! the !ollo/in& tests.
Test &lan
A test speci!ication is called a test plan. 7he developers are /ell a/are /hat test plans
/ill be e6ecuted and this in!or'ation is 'ade available to the developers. 7his 'a=es the
developers 'ore cautious /hen developin& their code. 7his ensures that the developers
code is not passed throu&h an( surprise test case or test plans.
Test #arness

7he so!t/are, tools, sa'ples o! data input and output, and con!i&urations are all re!erred
to collectivel( as a test harness.
So!t/are testin& certi!ication t(pes
*erti!ications can be &rouped intoB e6a'Cbased and educationCbased.
96a'Cbased certi!icationsB 4or these there is the need to pass an e6a', /hich can also be
learned b( sel!Cstud(B e.&. !or IS7H or HAI.
9ducationCbased certi!icationsB 9ducation based so!t/are testin& certi!ications are
instructorCled sessions, /here each course has to be passed, e.&. IIS7 1International
Institute !or So!t/are 7estin&2.
Testin0 certifications
*A79 o!!ered b( the International Institute !or So!t/are 7estin&
*7S o!!ered b( the ra@ilian *erti!ication o! So!t/are 7estin& 1A$A7S2
*erti!ied So!t/are 7ester 1*S792 o!!ered b( the Hualit( Assurance Institute 1HAI2
*erti!ied So!t/are 7est Pro!essional 1*S7P2 o!!ered b( the International Institute
!oftware "estin#
*S7P 17M2 1Australian ;ersion2 o!!ered b( K. J. Ross & Associates
IS9 o!!ered b( the In!or'ation S(ste's 96a'inations oard
IS7H *erti!ied 7ester, 4oundation $evel 1*74$2 o!!ered b( the International So!t/are
7estin& Huali!ication oard
IS7H *erti!ied 7ester, Advanced $evel 1*7A$2 o!!ered b( the International So!t/are
7estin& Huali!ication oard
*7S o!!ered b( the Brazilian Certification of Softare !esting 1A$A7S2
7MP4 <e6t 4oundation o!!ered b( the "#amination $nstitute for $nformation Science
Hualit/ assurance certifications
*SH9 o!!ered b( the A'erican Societ( !or Hualit(
*SHA o!!ered b( the %ualit& Assurance $nstitute
*HIA o!!ered b( the A'erican Societ( !or Hualit(
*MSH o!!ered b( the %ualit& Assurance $nstitute
Contro*ers/
So'e o! the 'ajor so!t/are testin& controversies includeB
:hat constitutes responsible so!t/are testin&Z

Me'bers o! the Nconte6tCdrivenN school o! testin& believe that there are no Nbest
practicesN o! testin&, but rather that testin& is a set o! s=ills that allo/ the tester to select
or invent testin& practices to suit each uni)ue situation.
A0ile *s. traditional
Should testers learn to /or= under conditions o! uncertaint( and constant chan&e or
should the( ai' at process N'aturit(NZ 7he a&ile testin& 'ove'ent has received &ro/in&
popularit( since 255+ 'ainl( in co''ercial circles, /hereas &overn'ent and 'ilitar(
so!t/are providers are slo/ to e'brace this 'ethodolo&(, and 'ostl( still hold to *MMI.
EE&lorator/ test *s. scri&ted
Should tests be desi&ned at the sa'e ti'e as the( are e6ecuted or should the( be desi&ned
be!orehandZ
Manual testin0 *s. auto3ated
So'e /riters believe that test auto'ation is so e6pensive relative to its value that it
should be used sparin&l(. Others, such as advocates o! a&ile develop'ent, reco''end
auto'atin& 155Y o! all tests.
Kcitation neededL
More in particular, testCdriven develop'ent states
that developers should /rite unitCtests o! the 6Cunit t(pe be!ore codin& the !unctionalit(.
7he tests then can be considered as a /a( to capture and i'ple'ent the re)uire'ents.
So!t/are desi&n vs. so!t/are i'ple'entation
Should testin& be carried out onl( at the end or throu&hout the /hole processZ
:ho /atches the /atch'enZ
7he idea is that an( !or' o! observation is also an interaction that the act o! testin& can
also a!!ect that /hich is bein& teste
1$.(UT"UT SCREENS
REAL TIME INTERACTIVE LECTURE DELIVERY SYSTEM
Screen1 3o'e pa&e o! the application.

!

Screen! "#en click on $%et &ogin' &ink button( a login
component )ill be presented as in t#e belo) screen:

Screen"! &ogin as $admin'

Screen#! Admin #ome page )ill be presented as s#o)n in t#e
belo) screen* T#is is to register t#e students

Screen$! Upload presentation screen )ill be presented as s#o)n
in t#e belo) screen* Admin )ill upload t#e presentations #ere*

Screen%! $&ist o+ presentations' screen is s#o)n as in t#e belo)
screen( All t#e uploaded presentations can be vie)ed #ere:

Screen&! elect t#e sub,ect and t#en t#e list o+ presentations o+ selected
sub,ect )ill be presented as s#o)n in t#e belo) screen:
Screen'! Adding -uiz component screen( -uiz )ill be uploaded
#ere:

Screen()! &ogin as pro+essor in login component

Screen((! Pro+essor #ome screen

Screen(! T#e list o+ presentations o+ selected sub,ect )ill be
presented as s#o)n in t#e belo) screen

Screen("! T#e pro+essor can vie) t#e registered students in t#is
belo) screen

Screen(#! "#en click on t#e %et Users list button( t#e enrolled students )ill
be displa.ed in t#e data grid as in t#e belo) screen

Screen($! Presentation screen )ill be presented as s#o)n in t#e belo) screen( t#e
students doubts )ill be displa.ed in t#e list on rig#t #and side*

Screen(*! T#e pro+essor )ill conduct -uiz as s#o)n in t#is screen( Top t#ree
students in+ormation )ill be displa.ed on t#e rig#t #and side*

Real Time /nteractive &ecture Deliver .stem






1$ Conclusions
7his so!t/are is developed usin& 4le6 as !ront end, java as 'iddle /are and S)l server as
bac=end. 7he &oals that are achieved b( the so!t/are areB
Instant Access
I'proved Productivit(
Opti'u' #tili@ation o! resources
9!!icient 'ana&e'ent o! records
Si'pli!ication o! the operations
$ess processin& ti'e and re)uired in!or'ation
#ser 4riendl(
Portable and !le6ible !or !urther enhance'ents.

Intensive care has been ta=en b( the develop'ent tea' to 'eet all the re)uire'ents o! the client.
9ach 'odule has under&one strin&ent testin& procedures and the inte&ration testin& activit( has
been per!or'ed b( the tea' leaders o! each 'odule.
A!ter co'pletion, e6ecution and success!ul de'onstration, /e con!ir' that the
Product has reached client re)uire'ents and is read( !or launch. 4inall( /e conclude that the
project stands up in 'aintainin& its sole 'otive o! better'ent to the societ( and /or= !or a social
cause.
1% Buture En#ance3ents
It is not possible to develop a s(ste' that 'a=es all the re)uire'ents o! the user .user
re)uire'ents =eep chan&in& as the s(ste' is bein& used. So'e o! the !uture enhance'ents that
can be done to this s(ste' areB
12 7he S(ste' can be enhanced to increase loo= and !eel o! the Application.
22 :ill tr( to scale the application.
1.. References
List of Reference Docu3ents
7he #ni!ied Modelin& $an&ua&e #sers &uide
( Erad( rooch
So!t/are 9n&ineerin&, A practitioners approach
( 0o&er S Press'an
So!t/are Project Mana&e'ent
( :al=er 0o(ce
7he applicable I999 standards as published in AI999 standards collection, !or the
preparation o! S0S>.
ac=up polic(, <a'in& *onventions as per 7eleparadi&' *onventions.