CHAPTER 1IntroductionMobilehasbecomeavital communicationtool whicheveryonepreferstopossessandcarry along. Initially mobile phones were developed only for voice communication but now daysthe scenario has changed, voice communication is just one aspect of a mobile phone. There areother aspects which are major focus of interest. Ubiquitous existence of the mobile phones hasdemandeda needfor developingvarietyof light weightedperating!ystems as well asapplications that would facilitate user requirements. !mart mobile phones have grownsignificantlyinterms of bothprocessinganduser interfacewhichwill satisfythegrowingdemands of user. "ith the development of the information era, people hope to access data anywhere and anytime. To meet this requirement, we propose a hierarchical location and proximity based accessframewor# which uses the services provided by the $ndroid perating !ystem. %ocation basedinformation is become increasingly important in the world of mobile application development.$ndroidoffersthisfunctionality,usingnetwor#locationproviders, whichdeterminetheuserlocation using &'!, cell tower and "i()i signals. $ndroid platform is a new generation of smart mobile phone platform launched by &oogle.$ndroid provides the support of mobile map and location service,It also supports &'!, *ideo+amera, compass, and ,d(accelerometer and provides rich $'Is for map and location )unctions.$ndroidisfreeandopen, providinganeasy(to(usedevelopment #it containingflexiblemapdisplay and control functions.!ome applications of %-! are as follow.(/0 %ocation -ased +$! in &ames10 2mergency, !afety and Medical34ealth !ervices,0 Information !ervices50 6avigation37outingBeWell. $ context and preference aware %-! application80 %ocation Trac#ing !ervices 6) Trac#ing. last minute delivery changes can be made based on truc# inventory and location, enhancing efficiency and customer service.1.1 Purpose7ight fromthe advent of mobile application development search applications wereprominent, but now%ocationbasedserviceshavealsobecomeanintegral part. Theprojectproposes a highly filtered search results based upon users contexts and preferences incombination with the user9s current location. Thus, provides a flexible user friendly interface forthe smart phone users.1.2 Scope)or a %-! application the entire user has to have a &'!(enabled mobile device, using thisuser has togivetheir demographicdetails andpreferences. Theapplicationneeds locationinformation from &'! !erver and user information in order to provide the optimal solution to theuser request. This application design to provide list of nearest hospital to the user along with &oogle mapbydisseminatinginformationgivenbyuseranditscurrentlocation. Incaseofemergencyitprovides ambulance service of the hospital by ma#ing call for it and list of user:s family doctors. 1.3 AimTo develop BeWell. $ preference and context aware %-! application, which provides optimum location to the user. 1.4 Obecti!es1 To stud" t#e e$istin% &oc'tion b'sed ser!ices. 2 Tode!e&op'simp&e'nde((icientmobi&ec&ient'pp&ic'tion(or'#ospit'&sse'rc# imp&ementin%.3 Toidenti("ro&eo( pre(erences'ndconte$t in&oc'tionb'sedser!ices (ordi((erent business 'pp&ic'tions.5 To develop user profile for the application.) To imp&ement ser!er t#'t (i&ters t#e 'ppropri'te d't' e((icient&" 'nd time&".BeWell. $ context and preference aware %-! application6 To demonstr'te t#e de!e&oped 'pp&ic'tion in 'ndroid b'sed sm'rtp#one.1.) *e!ice Speci(ic'tion 1.).1 H'rd+'re; / &- 7$M; 1< M- of free space; / &4= processor; !martphone1.).2 So(t+'re; &oogle 'lay !ervice ; $ndroid ! 1.1 or above1.6 *esi%n ,et#odo&o%iesArc#itecture o( -.S S"stems/There are three types of design methodology used in %-! application. They are as follows.0') Pu&&1b'sedmode&/Inthis, a%ocation'roxysits betweenclient applicationand%-!application. "hentheclient initiates %-!request tothe%-!application, his3her locationinformation is attached to the request by %ocation 'roxy and then forwarded to %-! application.Inthiscase, locationawareserviceisdeliveredwhiletheclient pullstheinformationfromservices. Usually%ocation'roxyis integratedintoamiddlewareinfrastructureuponwhichserviceis deployed, suchas I-M"ebsphere2veryplace!uite. This model facilitates %-!developer in building and deploying %-! applications in the sense that the location retrieving istransparent and existing application could be converted to location(aware ones easily. 0b) Po&&1b'sed mode&/ In this, %-! application actively sends location request via well definedor industry standard location interface to location server >%!0, which is responsible for gettingthe location of requested client. In this model, %-! application #eeps polling %! or queries %!on demand in order to answer questions from client. The advantage of this model is that moreadvanced location functionaries >such as periodic location report supported by %I) and "$'0BeWell. $ context and preference aware %-! applicationcould be supported and a standard location interface ma#es widely distributed location awarecomputing >e.g., location "eb !ervice0 possible.0c)Pus#1b'sedmode&/Inthis,%-! applicationpusheslocation(aware information to clientaccording to the user preference by trac#ing the position of mobile users. 'ush model enables thescenario of delivering right information to right people on right time at right location. )igure/./. Three Models of %-! !ervices-.S pro%r'mmin% in 'ndroid/$ndroid provides access to the following components to facilitate the implementation of %-! services./. %ocation Manager1. %ocation 'rovider,. &eo(coding5. &oogle(MapBeWell. $ context and preference aware %-! application-oc'tion ,'n'%er%ocation Manager +lass of android is present to manage all other components needed to establish a %-! system. -oc'tion Pro!ider%ocation provider represents the technology to determine the physical location i.e. to handle &I!.LocationProvider component of $ndroid application is a present to facilitate the determination ofavailable provider and selection of suitable one. )inding the %ist of $vailable %ocation 'roviderto get a list of names for all the providers available on the device, call get 'roviders, using a-oolean to indicate if you want all, or only the enabled, providers to be returned.boolean enabledOnly = true;List providers = locationManager.getProviders(enabledOnly);In addition to this &'! provider and 6etwor# provider can be accessed directly by using thestatic variables defined in the LocationManager class.LocationManager.GPSP!O"#$%!LocationManager.&%'WO!(P!O"#$%!)urthermore for finding the provider on the basis of some criteria, the criteria class is used andthen find the best provider for defined criteria using the BestProviderMethod as shown is thefollowing code snaps.)riteria criteria = ne* )riteria();criteria.set+ccuracy()riteria.+)),!+)-)O+!S%);criteria.setPo*er!e.uire/ent()riteria.POW%!LOW);00 /ore criteria 1ereString bestProvider = locationManager.getBestProvider(criteria2 true);BeWell. $ context and preference aware %-! applicationIf morethanoneprovider is availablefulfillingthe givencriteria thentheonewithbestperformance is returned. n the other hand if no provider is found for the defined criteria thencriteria are loosened in order 'ower use, $ccuracy, $bility to return bearing, speed, and altitude.2eocodin%7everse geocoding provides a way to convert geographical coordinates >longitude, latitude0 intostreet addressandforwardgeocodingprovidesameantoget geographical coordinatedfromstreet address.)or forwardgeocodingweusegetLatitude()andgetLongitude()methodas shownis thefollowing code bloc#double latitude = location.getLatitude();double longitude = location.getLongitude();)or reverse geocoding, get3ro/Location method is used with geocoder variable as shown is the following code bloc#00geocod is geocoder variableaddresses = geocod.get3ro/Location(latitude2 longitude2 45);2oo%&e ,'p in Android$ndroidprovidesanumber of objectstohandlemapsin%-!systemli#eMap"ie*whichdisplays the map.To handle this,Map+ctivityclass is there. To annotate map it provides theoverlaysclass. 2venit providescanvasbywhichonecaneasilycreateanddisplaymultiplelayers over the map. Moreover, sufficient provisions are there to =oom the map, locali=e the mapby means of Map)ontroller.)ollowing code(line shows the Map 4andling in $ndroid.6co/.google.android./aps.Map"ie*android7id=89:id0/apvie*800speci;y di;;erent attributes0+T%0 flow for!martphoneenvironments. The+T% flowbasedmobileclient $ppisbasedonModel(*iew(+ontroller >M*+0 model. It applies pluggable modules for connecting geospatial servicespointed by each geotag and translating geospatial content retrieved from such services. The $ppdisplays details information specified by a geotag following the &!. The $ndroid(based mobileclient $pp was developed for &+:s &+ "eb !ervices, 'hase B >"!(B0. It was applied as amobile trac#ingclientingeospatial webservice testbed scenarios forthebservation)usion>Trac#ing0 thread. Two pluggable modules were developed for the scenario application. ne is aconnector modulefor connectingtoatrac#server, andanother is atranslator modulefortranslating trac# information for displaying on map views.Person Bide Beb/ Acti!e -oc'tion b'sed Beb Ser!ice Arc#itecture usin% Bire&essIn(r'structure 4E56 Seun%'e S#in6 P"un% 9im6 ;eoeon% ;oon6 Seon%be' Eun6 'nd H"unsoo;oon'erson "ide "eb is a location based web service architecture which tries to maximi=e the %-!supportability by 'U!4I6&, active notification aboutgeographically effectiveweb resources.Thus, '"" can be understood as a subset of the """ which consists of location specific webresources based on the user:s geographical position. In '"", each mar#eter ma#es their own'U!4I6& document including lin# to their web site, then upload it to the 'U!4 server and localnetwor# service provider or data hosting provider ta#e exclusively charge of the 'U!4 servermanagement. By using the PWW, various location specifc data services such asshopadvertisement, restaurant menu, anddiscount coupon, canactivelypromote the mobile device users to gladly use their services.BeWell. $ context and preference aware %-! applicationHidin% on t#e Ro'd 1 Anon"mous Fs'%e o( -oc'tion .'sed Ser!ices 41G56 A&'n B'&s# 'ndTom P(ei(erThepaperdiscusseshowtheconcept ofanonymitycanbeappliedto!martphoneplatformswithout theneedfor aninterveningtrustedserver but usingtheexistingroadnetwor#andestablished traffic patterns and describes an algorithm which implements these ideas.

BeWell. $ context and preference aware %-! applicationCHAPTER 3S"stem An'&"sis3.1 Identi(ic'tion o( t#e =eedThesearchbasedapplications either useservices of somestandardsearchengineli#e&oogle, -ing, msn etc. or use search algorithms. These searches fetch millions of records.!omeapplicationsfilter theresultsinadomainspecificmanner, e.g. searchingnearestrestaurants application. 4owever, these outputs are still numerous and user has to explore forthe desired result. The need of this project arises here as the context(aware applications provideuser specificoptimi=edsolutiontothesearch. $s the2ndUsers usingsmart phoneisincreasing day by day. It is very necessary to develop an efficient, highly responsive real(time application that provides optimal solution to the specific user. They gives their profileinformation and preferences as an input for getting the desired result. The system requiresuserprofileinformationonlyforthenewuserandforregistereduserit usesthestoredinformation and additional information given by user.3.2 Te'm StructureThe software team for our project is a ?emocratic ?ecentrali=ed >??0 team. The salientfeatures of our team are./. There is no permanent leader of the team.1. The decision ma#ing process is a team activity.,. The communication between the team members is hori=ontal.BeWell. $ context and preference aware %-! application)igure ,.1. Team !tructure3.3 Proect Sc#edu&in% Time&ine C#'rtWork tasksWeek1, 2,3,4Week, !,",#Week$, 1%,11Week12,13,14Week1,1!,1",1#,1$Week2% ,21,22,23,24Week2,2!,2",2#,2$Week3%,31,32,33,34,3Week,3!,3",3#,3$,4%,41Week42,43,44,4,4!,4",4#,4$Month tasks1&31'ul1&31(ug1&21sep22sep&1oct1!oct&22nov23nov&31dec1)an&"*eb#*eb&23march24mar&"april"apr&")un/././ Meeting the client/./.1 &athering the userrequirementsMilestone.7equirements gathered/.1./!tudyofgatheredrequirements/.1.1 -rea#ing therequirementsMilestone.7equirements analy=ed.BeWell. $ context and preference aware %-! application1././ +omparison ofavailable tools.1./.1 2valuate theselected tool.Milestone. Tooldecided.1.1./ !eparationmodule(wise info.1.1.1 Modulari=ing thesoftware.Milestone. -ac#endmodulari=ed.1.,./+odingof accessthe root)rom !ource to?estination 1.,.1+odingof accessthe interested area1.,., +oding of6otificationservices inmobileMilestone. -ac#end+oded.,././ $ssessing thefront(end tools.,./.1 +hoosing a toolfor &UI.Milestone. )ront(endtool decided.,.1./?ecidingthebestpossible layout,.1.1 ?esigning of &UI.Milestone. &UIdesigned.,.,./ $dding eventhandlers.Milestone. Interfaceaccomplished.5././ Integrating )rontBeWell. $ context and preference aware %-! applicationand -ac# end.Milestone. !oftwareintegrated.8././ +ompiling thesource code.8./.1 +hec#ing for noruntime errors.Milestone. !oftwaretested.8.1./Testing the inputand output file8.1.1 2rror free retrievalof dataMilestone. utputtested.BeWell. $ context and preference aware %-! applicationBeWell. $ context and preference aware %-! applicationC#'pter4So(t+'re En%ineerin% Appro'c# So(t+'re En%ineerin% P'r'di%m App&iedIn incremental model the whole requirement is divided into various builds. Multipledevelopment cycles ta#e place here, ma#ing the life cycle a Fmulti(waterfallG cycle.+ycles aredividedupintosmaller, moreeasilymanagedmodules. 2achmodulepasses throughtherequirements, design, implementationand testingphases.$wor#ingversionof softwareisproduced during the first module, so you have wor#ing software early on during the softwarelife cycle. 2ach subsequent release of the module adds function to the previous release. Theprocess continues till the complete system is achieved.Incremental development is the construction of a software system in a series of small mini(life(cycles, rather than construction in one large monolithic life cycle.$n incremental approachpostpones detail insomeor all phases toproducewor#ingsoftwareearlier intheprojectdevelopment time scale. The basic idea is to develop the system in a vertical slice rather than ahori=ontal slab. Increment'& *e!e&opmentIncremental ?evelopment is the development of asystemina series of partial products>increments0 throughout the project timescale. Increment'& *e&i!er"Incremental ?elivery is the delivery of increments to the customer3users at intervals throughoutthe project timescale.6ote. $ system can be developed incrementally without being delivered incrementally to users,but not vice versa. BeWell. $ context and preference aware %-! applicationIncrement$nIncrement is aself(containedfunctional unit of software, together withall supportingmaterial, includes.7equirementsspecification, ?esigndocumentation, Test plans, casesandresults, User manuals and training, 2stimates, plans, schedules, resourcing, Huality assuranceinformation >e.g. reviewreports0, +onfiguration management information. $n incrementproduces>oralters0across(sectionofthefinal systemdeliverables, relatedtoafunctionalportion of the final system.4.1 Increment'& -i(e C"c&e ,ode&s In the following sections, a number of incremental life cycle models are shown.4.1.1 Increment'& .ui&d 'nd TestBeWell. $ context and preference aware %-! application)igure 5././. Incremental -uild and TestTheincremental buildandtest approachbeginstheincremental development inthecodingphase, with the previous phases being monolithic. ?eutsch and "ong. Many developers go some way toward this approach informally, although often without thecompleteset of lifecycledocumentation. !incethis is not what is recommendedbythemonolithicwaterfall model, thedevelopersmayfeel guiltythat theyarenot followingthemodel correctlyI -etter results will be obtained from following the incremental build and testapproach intentionally rather than accidentally. 4.1.2E!o&ution'r"*e&i!er")igure 5./.1. 2volutionary ?eliveryBeWell. $ context and preference aware %-! application2volutionary delivery is the most extreme incremental approach, defining the increments fromthe top of the life cycle. &ilb9s method includes incremental delivery as well as incrementaldevelopment, andthereforehas useful wor#ingfacilities availabletothecustomers muchearlier than other life cycle models.The diagram shown actually does not do justice to the evolutionary delivery method, however,since there is a higher level process which precedes the incremental steps, consisting of settingsystem and business objectives, open architecture design, planning and quality assurance.The evolutionary deliveries are made at frequent intervals >possibly as small as a wee#0, andconsist of some function, facility, or organi=ational change which is useful to the customer andrelatively easy to produce. In fact that ratio is used to determine the order of the increments.$ majoreffect ofevolutionarydeliveryistoelicit requestsforchange, mainlyfromusers.4owever, these change requests maybe Jfolded bac#J into the development process atsignificantly less cost than for monolithic models, for two reasons. )irst, change is expectedand planned for, so it does not come as an unwelcome surprise. !econdly, when requirementshave been completely detailed and designed >in the monolithic approach0, the changes whichare requested will affect the wor# already invested in the fro=en specification."ith incrementaldevelopment, requested changes which affect those areas which have not yet been completelydetailed, do not result in discarding wor# already done. +hange can be turned to advantage,provided it is controlled. BeWell. $ context and preference aware %-! application4.1.3Cr'me+or> Increment'& -i(e C"c&e )igure 5./.,. )ramewor# Incremental %ife +ycleKust as one extreme being wrong does not imply that the other extreme is right, a framewor#incremental approach may be the Jbest of both worldsJ, by providing a compromise betweenthe monolithic waterfall and &ilb9s evolutionary delivery. 2nough of the initial requirementsspecification and architectural design is done so that the direction and structure of the systemproduced is clear enough to direct the software development process. This approach can stillgiveuseful productsveryearlyinthedevelopment timescale.$nexampleofthistypeofapproachis thespecificationof thestructureandinterfaces for adatabase, withdetailedfacilities to be specified later.BeWell. $ context and preference aware %-! application4.1.4P#'sed*e!e&opment)igure 5./.5. 'hased ?evelopment'hased development has frequently been used in the development of large systems, and is astep in the right direction. The difference between a very small phase and a large increment isnot distinct. 4owever, phases tend to be large and growingI there is a tendency to put as muchaspossibleintothecurrent phase. Thereisalsoatemptationtocompensatefortimescaleslippage by bringing forward the later phases to overlap the earlier ones. This approach canresult in severe incompatibility between successive phase products. The emphasis withincremental development is to include as little as possible, i.e. as little as would be useful intoeach increment.4.2 Increment'& Str'te%"4.2.1 Suit'bi&it"BeWell. $ context and preference aware %-! application%arge systems are particularly suitable for incremental development. Monolithic developmentis suitable only for small systems of short duration, where the requirements are well #nown atthebeginningof development andunli#elytochange, accordingtoLr=ani#MNO, andforcommercial pac#ages such as a database pac#age, operating system, or word processor,according to +onnell and !hafer M//O. &ilb maintains that any system can be developed usingevolutionary delivery. M@O4.2.2 P'rtitionin% t#e S"stem into Increments?eciding howthe systemcan be divided up into self(contained functional increments,particularly for incremental delivery to users, can be difficult when incremental techniques areinitiallytried. Thereareanumberofgooddesignmethodologiesforproducingalooselycoupled architecture of non(overlapping functions incremental development does not requireanyparticular or specific designtechnique. The involvement of outside consultants with#nowledge and experience of incremental development can be very helpful in the initial stages.The initial difficulties experienced in designing increments are often due to thin#ing about thesystem in ways which are quite different to the monolithic approach. Monolithic thin#ing isdirectedtowardcompletingall requirements first, but incremental thin#ingta#es asmallrequirement subset toward implementation first.Theobjectiveswhichdrivethepartitioningprocessareto#eeptheincrementsassmall aspossible, provided they will provide a useful function to the users. The temptation tocontinuallyincreasethefunctionalitywithineachincrement shouldberesisted. It is alsoessentialtoretaincontroloverthecontent ofeachincrement, andprevent developersfromincorporating other Jgood changes at the same timeJ, which then becomes undisciplined anduncontrolled.4.2.3 Prioriti?in% 'nd Sc#edu&in%The scheduling and sequencing of development is based on three aspects. first, any parts of thesystem which must be in place before functional increments can be implemented should becompleted first, but only the minimum needed.BeWell. $ context and preference aware %-! application!econd,the broad strategy for the next series of increments should be defined. $lternativesinclude the development of the most critical increments first to minimi=e ris#, the developmentof interface increments first to test control, or the development of functional threads first toachieveawor#ingpartialproduct.Thelatterisneededasearlyaspossibleinordertouseincremental delivery effectively.4.3 Prob&ems o( Increment'& *e!e&opment 'nd *e&i!er"In this section, various problems related to incremental development and delivery are outlined.'ossible solutions are suggested where appropriate. )urther discussion, particularly ofmanagement problems, can be found in 7edmill MBO.There are manyaspects of software development whichare not affectedbyincrementaldevelopment or delivery, such as the need for good management, quality assurance,configuration management, and the training of staff in software engineering principles.$dditional training is needed, however, when departing from development techniques whichare widely accepted, even when extensive benefits can be gained.4.3.1 H'rd+'re Re&'ted Prob&ems1. Ris>o( in'deHu'tec#oice/Thechoiceof hardwarefor asystemtobedevelopedincrementally will be based on intentionally incomplete specifications, with the ris# thatan inadequate choice will be made. 1. Responsetimes. Ifasmall number ofincrementshavebeendeliveredonthetargethardware, response times should be extremely good at first, but will gradually deterioratewith increasing functionality, to the disappointment and frustration of users. ,. *e!e&opment #'rd+'re. If the target hardware is delivered with the early increments,additional hardware may be needed to continue the development of the system. 5. Embeddeds"stems#'rd+'re. Theparallel development ofhardwarefor embeddedsystems may constrain the definition of the increments.BeWell. $ context and preference aware %-! application4.3.2 -i(e C"c&e Prob&emsIncremental development is not an alternative to applying life cycle disciplineI the phases of thelife cycle still need to be followed in the right order and with all of the associated controls.2ach increment is a small life cycle in its own right.1. ReHuirementsspeci(ic'tion. The7equirements!pecificationisneededtodefinetheboundaries of the system and of the increment.2. *esi%n/ ?esign is needed in order to preserve a coherent structure to the software systemthroughout the changes which will occur during incremental development. The overalldesignshouldbedefinedinthefirst increment, but eachincrement shouldalsobedesigned, andthedesignmust wor#towards preservingtheintegrityof theoverallarchitecture. 3. Testin%/ Testing is needed to ensure that each increment fulfils its requirement, and hasnot adversely affected the rest of the system. "ith incremental delivery, more extensiveregression testing will probably be needed, since any change to the system results in achanged system. $ll tests should be run again to ensure that there are no adverse side(effects of the change.4. Ot#er &i(e c"c&e products/?ocumentation, user manuals, training, and quality controlprocedures should not be s#imped in the excitement of having something wor#ing. Theyare still needed in order to retain control over the development process. $goodconfiguration management system is essential for #eeping trac# of increments in variousstages of completion. 4.3.3 ,'n'%ement Prob&ems1. -i!in% +it# uncert'int"/ It is unsettling to live with uncertaintyI this is one reason whydevelopers prefer to specify complete requirements before beginning to design a system.4owever, incremental development requires a certain level of uncertainty to be toleratedwithinthe context of controlleddevelopment. There are levels of uncertaintywithBeWell. $ context and preference aware %-! applicationmonolithic development as well, but we tend to hide them from ourselves by attemptingto resolve specification uncertainties on paper.2. Te'm coordin'tion/The coordination of teams of people wor#ing on different parts ofthesystem, andbeingindifferent lifecyclephasesat once, presentsachallengetomanagement. +orrections found in the use of a delivered increment have to beincorporated into the system as part of an increment further Jdown(streamJ.+onfiguration management is essential.3. S"stem re&e'ses/ 7eleasing a system to a large user base incrementally is even more of achallenge, andmayproveverydifficult evenwithagoodconfigurationmanagementsystem.4. Sc#edu&in% 'nd prioriti?in%/ The scheduling and prioritising of increments is a processwhich is constantly being altered by the results of earlier incremental deliveries,management must be prepared to spend effort in supporting this continuing process.). .'&'nce bet+een ori%in'& speci(ic'tion 'nd desired c#'n%es/?evelopment may tendtoproceedintwodirectionsat onceI pulledtowardtheoriginal specificationbythedevelopers >who can easily become Jloc#ed inJ to local goals0, and pushed toward newchanges by the users. Management needs to #eep the balance between these two. Therequests for change should not be allowed to Jhijac#J the original system objectives, butsome change must be allowed or the benefit of incremental delivery will be lost. +hangesneed to be controlled at a strategic level, in order to ta#e the widest view of the systemobjectives into account.6. Or%'ni?'tion'& cu&tur'& c#'n%e/+hanging the waya large organi=ation developssoftwareis not easyandcannot bedoneovernight. 2ffort is neededinintroducingincremental development ideas, to assess and then convince of the benefits. 2ffort is alsoneededtoensurethattheconceptsarebeingimplementedcorrectlyI forexample, thetemptation to merge increments together in order to meet a timescale should be resisted."ithout continuing pressure, attitudes and habits will revert to the earlier ideas, even ifthe new words are used.BeWell. $ context and preference aware %-! application4.4 Ad!'nt'%es o( Increment'& *e!e&opmentThe advantages of incremental development are givenseparatelytothoseof incrementaldelivery.Incrementaldevelopment without delivery gives advantages tothe developers,andincremental delivery gives advantages to the users. Improved Team Morale 2arly !olution of Implementation 'roblems 7educed 7is# of ?isaster Improved Maintenance Measurement of 'roductivity 2stimation )eedbac# !moother !taffing 7equirements4.) Ad!'nt'%es o( Increment'& *e&i!er"The benefits of incremental development for developers are significant, but the greatest benefitscome from both incremental development and delivery to users. Increased Understanding of 7equirements !ystem can meet 7eal 6eed, not )ro=en 6eed. ?elivery of useful product is within time. -etter quality software. -etter acceptance of the system by the user organi=ation.BeWell. $ context and preference aware %-! application The system will have a longer useful life. More flexible options the system is produced within the original financial constraints. If an incremental project is cancelled, the increments already produced form a wor#ingproduct of some sort. It allows small areas of the organi=ational procedures to be altered at any one time, when the problems are overcome, those areas are then established, and this also increases system assimilation.4.6 Comp'r'ti!e CostsBeWell. $ context and preference aware %-! applicationThe comparative costs of monolithic and incremental development for a hypothetical projectare.)igure 5.@./. +omparative +osts of Monolithic and Incremental ?evelopment1. Ori%in'& Speci(ic'tion"ith monolithic development, the cost of developing the original specification must be met infull in order for the project to produce anything useful. "ith incremental development, it ispossible that the original specification would still be produced, but is more li#ely that only partof the original specification will be produced.BeWell. $ context and preference aware %-! application2. CorrectionsThe cost of corrections is no more, and should be less, for incremental development than formonolithic, sinceerrorsofanalysis, designorimplementationwill bediscoveredearlierindevelopment and will not have propagated through the rest of the system requirements, designsand code.3. Ine!it'b&e C#'n%eIt will not be any more costly to respond to inevitable change, such as a changed hardwareenvironment or newwor# practices. It should in fact be less costly for incrementaldevelopment, since a systemwhich has been developed incrementallyis accustomed tofrequent change.4. ReHuirements E!o&utionIt will not be any more costly to implement evolving requirements, and in fact should be less inincremental development, since many changed requirements can be incorporated into the finalsystem without having to discard wor# already done on superseded requirements. ). Con(i%ur'tion ,'n'%ement+onfigurationmanagementcosts areli#ely tobehigher withincremental developmentthanwithmonolithicdevelopment, particularlyif theexistingconfigurationmangement methodand3or tools are fairly primitive. +onfiguration management is more essential for incrementaldevelopment and delivery, although it is a good idea for any software development.BeWell. $ context and preference aware %-! application4.4 Comp'r'ti!e Sc#edu&in%The comparison of scheduling differences between monolithic and incremental development is. )igure 5.A./. +omparative !cheduling for Monolithic and Incremental ?evelopment1. Timesc'&e to Cinis#The elapsed time to finish the total development may be longer for incremental developmentthan for monolithic development, but it is not as critical.2. Timesc'&e to Produce Fse(u& CunctionBeWell. $ context and preference aware %-! applicationThe timescale until something useful is produced is much shorter with incrementaldevelopment and deliveryI this is the main reason for using incremental models. This is alsowhyit isnot ascritical iftheelapsedtimetofinishthetotal systemisgreater thanwithmonolithic development.3. ReHuirements E!o&ution7eal requirements doevolve, whether thedevelopers ta#enoteof thechanges or not. Inmonolithicdevelopment, onlyalimitednumber of requirement changesarepermittedI theremaining changes are therefore stac#ed up waiting until after handover to be implemented. Inincremental development, theevolvingrequirementscanbeincorporatedintotheevolvingproduct.$fterhandover,theincrementallydevelopedsystemmerelycontinuestoadjusttochangingrequirements in much the same way as it did during development, but probably at a reducedrate >fewer new facilities being included0.The monolithic system has two problems after handover. )irst, it must become a maintenance(type environment capable of handling changes in a controlled way, which may involve someJteethingJ troubles. !econd, it must deal with the bac#log of changed requirements which havebeen stac#ed up and prohibited during development, in addition to coping with the on(goingrequests for changes. BeWell. $ context and preference aware %-! applicationC#'pter )ReHuirement Speci(ic'tion).1 ReHuirements %'t#erin%7equirement 2ngineering >720 is the first major activity which involves withunderstanding problem domain >described in a statement of needs0, solution determination,and specification of a solution that is testable, understandable, and maintainable.$ll the information required for the project is collected by reviewing the existing researchpaper which is based on location based services for smart phone. $part from this, informationis gathered through discussion about every phase of project with our project guide and peoplewhoexpertiseinfieldof%-!andperformresearchonbuildingapplicationson $ndroidframewor#. The information regarding this application is collected through elicitation with hospitaladministrator, friends whohavewor#ingexperienceinvarious technologies usedintheproject development.These involve interviewing the end(users and customer to collect all possible informationregarding the system. If the project involves automating some existing procedures then thetas# of the system analyst becomes a little easier as he can immediately obtain the input andoutput data formats and the details of the operational procedures. ).2 ReHuirements An'&"sisBeWell. $ context and preference aware %-! application7equirements analysis involve obtaining a clear and through understanding of the product tobedeveloped, withaviewtoremovingall ambiguitiesandinconsistencefromtheinitialcustomer perception of the problem. It is quite difficult to obtain an unambiguousunderstanding of the problem, especially if there is no wor#ing model of the problem to besolved.Therefore the analyst should first understand many basic questions pertaining to the projectsuch as the following clearly. "hat is the problemP "hy is it important to solve the problemP "hat are the possible solutions to the problemP "hat exactlyare the data inputs tothe systemandwhat exactlyare the dataoutputs by the systemP "hat are the li#ely complexities that might arise while solving the problemPnce the analyst understands the above basic question, he sets out to collect moredetailed information regarding the project.-elow are the software and hardware requirements for developing this application >not for installing the application0. ).3 So(t+'re ReHuirementsperating !ystem7 "indows'latform7 $ndroid !?L )ramewor# I?27 2clipse I?2$ndroid 2mulator. !?L *ersion 1.1 or 4igher Technologies used7 '4' 8.8 >QII )ramewor#0, android!erver. "$M' server?atabase. My !H%BeWell. $ context and preference aware %-! application).4 H'rd+'re ReHuirements'rocessor7 /&4= 7$M78/1 M-!pace on dis#7 minimum 8inQii framewor#0, addresseshavespecial format. Theyincludeparameter that specifieswhichcontroller will be used. There can be more than one controllers. 2ach controller can be used to wor# in different part ofyour web. ne controller can wor# with user accounts, another one with products you sell etc.$nd the web address loo#s li#e.***./y*eb.co/0inde>.p1p?r=/y)ontroller'arameter FrG says the +ontroller named Fmy+ontrollerG is to be used. $ddresses contain onlyindex.php. 6o other files. $ll the navigation is done by the FrG parameter and controllers.D.1.2 Action+ontroller can have one or more sub(controllers. 2ach does something else. If controller wor#swithusersthanhisonesub(controllercandeleteusers,anotheronecanaddusers,thirdonechanges them R These sub(controllers are called $ctions. The FrG parameter can be specified. $swesawabove, controllerwasspecifiedli#ethis. FPrSmy+ontrollerG. Ifcontrollerhadactioncalled Fmy$ctionG, to run it address should be as below.***./y*eb.co/0inde>.p1p?r=/y)ontroller0/y+ctionBeWell. $ context and preference aware %-! applicationcan be rewritten as.***./y*eb.co/0inde>.p1p?r=users0editThe default action has to be specified in the controller using function action#nde>().D.1.3 ,ode& Model is very simple thing in Qii. 6ot a single line of its code needs to be written, it can becreated automatically using command line. 2ach table in ?- has its own model. This model hasthe similar name li#e the table. 2ach model has two important functions, )ind data and !avedata. To read data from ?- to controller something li#e below needs to be written.Model&a/e.3ind+ll() 6o !H% queries, no fetching array >as you would have to do in '4'0. That:s the advantage ofQii and its object(oriented access to ?-. "hen you want to write to table, the command loo#sli#e this.Model&a/e.colu/n = value;@Model&a/e.Save()$nother thing that the Model provides is relations. These relations enable to FtunnelG throughone table to another. Important are )oreign Leys. 7elation is something li#e !H% Koin. "henevery employee has in its table the I? of his department, info about this department can be easilyaccessed by writing something li#e this.e/ployeeAUM%0, the use case diagram is a type ofbehavioral diagram defined by and created from a use(case analysis. It represents a graphicalover viewof the functionality of the systemin terms of actors, which are persons,organi=ations or external system that plays a role in one or more interaction with the system.Thesearedrawnasstic#figures. Thegoalsoftheseactorsarerepresentedasusecases,BeWell. $ context and preference aware %-! applicationwhich describe a sequence of actions that provide something of measurable value to an actorand any dependencies between those use cases. In this application there are two actors T User, *irtual User and below is the use case diagramof this application.D.2.1 Hospit'& Admin Fse C'se *i'%r'm/)igure B.1./. 4ospital $dmin Use +ase ?iagramFse C'se ='me. 4ospital $dmin Use +ase ?iagramActor/ 4ospital $dmin.rie( *escription/This use case described the functionality performed by hospital administration.Tri%%erin% E!ents/ "hen hospital registration event is triggered

C&o+ o( E!ents/Acti!it" Response7egister 4ospital $ble to download application from !erver Table B.1./. 4ospital $dmin )low of 2ventBeWell. $ context and preference aware %-! application D.2.2 @irtu'& Fser Fse C'se *i'%r'm.)igure B.1.1. *irtual User Use +ase ?iagram

Fse C'se ='me. *irtual User Use +ase ?iagramActor/ *irtual User3!erverBeWell. $ context and preference aware %-! application.rie( *escription/This use case described the functionality performed by !erver.Tri%%erin% E!ents/ "hen user request is accepted by server.C&o+ o( E!ents/Acti!it" Response1Se'rc# !earch hospital on the basis of user profile information2 Ad!'nced Se'rc# !earch hospital on the basis of user preferences 3 Store And ,'n'%e Fser $dd or ?elete User 4 Store And ,'n'%e#ospit'&in(orm'tion$dd or ?elete hospital and consultantTable B.1.1. *irtual User )low of 2ventThe process of searching ta#es place as./0 $t first the distance from the current location to all hospital locations is calculated with thehelp of their latitudes E longitudes.10 Then the hospitals whose distance is equal or below 18 mile are selected.,0 Then the speciali=ation of the ?octors >+onsultants0 is compared to the diseases related toheart, eye etc. $fter that the range of fees is mapped along with the consultation time tofetch the name of the 4ospitals and doctors in the hospitals. These results will be sent fromserver to mobile device. >above , steps are wor#ing in '4'0.50 6ow the ordering according to preferences is in K$*$ classes is done.Thedefault searchisbasedonprofileinformation. )ore.g. theuserprofilecontainsoccupation of the user, accordingly results will be displayed. !ample rules are as follows.If(occupation.equals("Private Industry")) {searchspecialization_doctor("Eye");}BeWell. $ context and preference aware %-! application else if (occupation.equals("he!ical Industry")) {"sonstr # uf.searchspecialization_doctor("Physician"); } else if (occupation.equals("e!ent Industry")) {"sonstr # uf.searchspecialization_doctor(specialization); })or getting most appropriate advance search results rules as follows have been implemented.7ules defining quality.i( >>6oUofU-eds V 6oUofU-eds W /J/.1hUnabhUaccrediation.equals>JhUisoUcertificatied.equals>J>6oUofU-eds V /hUnabhUaccrediation.equals>JhUisoUcertificatied.equals>J>6oUofU-eds V 1J/J00 EE >hUisoUcertificatied.equals>J>6oUofU-eds V 8J/J00EE >hUisoUcertificatied.equals>J>6oUofU-eds V /J/J00EE >hUisoUcertificatied.equals>J