7-prinsippene i flerlagsmodellen

Selv om det er lettere sagt enn gjort, vil jeg gjerne starte denne uken geofumando På dette emnet, selv om det er komplett bøker om dette emnet, vil vi bruke 7-prinsippene på 2.0-weben til å oppsummere flerlagsmodellskjemaet og bruke det til det geomatiske feltet.

Konseptet kjent som multilayer, oppstår etter at klientserver-applikasjoner tok en boom, knyttet til veksten av Internett mens private nettverk (Intranett) også ble populært. En av de viktigste målene er at utviklingen ikke påvirker driften, enda mindre spørringsbrukerne i et system som er i konstant bruk.

Slik er tilfellet, for eksempel i et massivt kadastreprosjekt hvor feltteknikere, kartleggere eller digitaliserere må mate informasjonen; da må de juridiske analytikerne, GIS og regulariseringsteknologene behandle dataene, mens fra siden av eksterne brukere, er det en etterspørsel på nivå av konsultasjon eller forespørsler om onlineprosedyrer.

La oss da se lagene i denne modellen og dens prinsipper.

Utviklingslaget

1. Enkel design.  Det er viktig å forstå at når flerlagsapplikasjoner utvikles, kan funksjonaliteter som vil bremse prosessen, datautrulling eller oppdatering av funksjonaliteter ikke overdrives. Dette er grunnen til at bruk av Javascript-lignende prosedyrer som kjører på en server, lar mange brukere utføre oppgaver samtidig uten å laste systemet på nytt. Ettersom prosessene kan gjøres mindre, krever det bare overvåking av antall og kapasiteten til prosessorer for å holde designet enkelt ... selv om dette mer enn å være en spesialitet for programvarearkitekter ser ut til å være en mer god ferdighet.

2. Programmer for bruk av flere enheter.  Det er nødvendig å vurdere at brukere vil ønske å få tilgang til informasjon fra stasjonære enheter eller en rekke mobiltelefoner via nettet, så utviklingen må vurdere dette prinsippet. Selv om det ikke er lett å forutsi utviklingen av de kjente dingsene, bør i det minste prosjektets spesialitet vurderes for å mate og laste ned data, som i tilfelle en matrikkelprosess, bruk av GPS-utstyr og PDAer med GIS-applikasjoner. / CAD med minimal tabellformat, og bruk av raster / vektordata. Siden spesialiteten til virksomheten er diversifisert, er det nødvendig å være klar over utviklingen av teknologier.

3. Via databasen.  For å holde en prosessor fri for kollaps, er det nødvendig å vurdere at enhver handling som brukeren utfører er en enkel samtale til databasen, så hvis filoverføring brukes, er det å foretrekke å opprette webtjenester. Hvis kart vil bli brukt, er det ideelle å opprette IMS-tjenester for publisering, og hvis dokumenter blir lastet ned, se etter bruken av webtjenester.

Prosesslaget

4. Internett som en plattform.  Det være seg intranett eller internett, konseptet er det samme, og ser etter brukernes arbeidsmiljø for å være online, så alle typer prosesser kjøres fra serveren. Dette suppleres med følgende prinsipp siden intensjonen er å sikre at drift av prosesser ikke krever team med store ressurser, selv om det er nødvendig å redesigne skrivebordsprogrammer.

5. Bruk av elektroniske applikasjoner.  Dette er en stor utfordring for utviklere, siden dette laget også inkluderer et nivå av brukere som utfører prosesser som går utover spørringen. Slik er tilfelle matrikkelvedlikehold, som krever bruk av diskrete filer og ikke bare manipulering av tabelldata. For dette må den valgte programvaren tilby et kontrollert filhåndteringsmiljø, versjonering og prosessen kjent som checkout-checkin; API forventes også å gi muligheter for å spesifisere funksjonalitet og forhindre at stasjonære prosesser kompliserer synkronisering.

Brukerlaget

6. Kollektiv intelligens.  Dette prinsippet kommer fra begrepet fellesskap, veldig populært i disse dager. Det er viktig å lage grensesnitt som forenkler kommunikasjon mellom brukere, det være seg disse forumene, støttenettverkene eller direktemeldingskanalene, slik at brukerne kan dele sin tvil, løsninger og dra nytte av kollektive ferdigheter.

7. Feedback.  Tjenestene som opprettes må ha tilstrekkelig funksjonalitet slik at brukerne kan rapportere feil, legge til kommentarer er automatiserte eller frivillige. Det viktige er at brukerne som administrerer de to andre lagene vet om de besøkende. Begrenset tilgang, funksjonell registrering og automatisk oppdatering av endringer forventes også på dette nivået.

Disse prinsippene bør påvirke for øyeblikket å bestemme seg for en programvarevare, hovedsakelig fordi livet til dette ikke er i utgangsproduktene, men i evnen til å sette håndutvikling.