Princip 7 vícevrstvého modelu

Přestože je to jednodušší, než bych udělal, chtěl bych tento týden začít geofyzikální na toto téma, i když existují celé knihy na toto téma, budeme používat principy 7 2.0 na webu shrnout schéma vícevrstvého modelu a aplikovat je na poli geomatiky.

Koncept známý jako vícevrstvý vzniká poté, co aplikace klient-server zaznamenaly boom spojený s růstem internetu, zatímco populární sítě (Intranet) se také staly populárními. Jedním z nejdůležitějších cílů je, že vývoj neovlivní provoz, natož uživatelé dotazů v systému, který je neustále používán.

Tak je tomu například v případě rozsáhlého katastrálního projektu, v němž musí informační technici, mapovací nebo digitalizační pracovníci informovat; pak právní analytici, GIS a regularizační technici musí zpracovávat data, zatímco ze strany externích uživatelů existuje poptávka na úrovni konzultací nebo požadavků na online postupy.

Podívejme se tedy na vrstvy tohoto modelu a jeho principy.

Vývojová vrstva

1. Jednoduchý design.  Je důležité si uvědomit, že při vývoji vícevrstvých aplikací nelze přehnat funkce, které zpomalí proces, nasazení dat nebo aktualizaci funkcí. To je důvod, proč použití procedur podobných JavaScriptu spuštěných na serveru umožňuje mnoha uživatelům provádět úkoly současně bez opětovného načtení systému. Jelikož lze procesy zmenšit, vyžaduje to pouze sledování počtu a kapacity procesorů, aby byl design jednoduchý ... i když to víc než být specializací softwarových architektů se zdá být spíše dovedností bohů.

2. Aplikace pro použití více zařízení.  Je nutné vzít v úvahu, že uživatelé budou chtít získat přístup k informacím ze stolních zařízení nebo z různých mobilních telefonů přes web, takže vývoj musí tento princip zohlednit. I když není snadné předpovědět vývoj známých gadgetů, měla by být pro účely podávání a stahování dat zvážena přinejmenším specialita projektu, jako v případě katastrálního procesu, použití zařízení GPS a PDA s aplikacemi GIS / CAD s minimálními možnostmi podávání tabulkových dat a použití rastrových / vektorových dat. Vzhledem k tomu, že specializace podnikání je diverzifikovaná, je třeba si uvědomit pokrok technologií.

3. Prostřednictvím databáze.  Abychom zabránili kolapsu procesoru, je nutné si uvědomit, že jakákoli akce, kterou uživatel provede, je jednoduchým voláním do databáze, takže pokud je použit přenos souborů, je lepší vytvořit webové služby. Pokud budou použity mapy, je ideální vytvořit služby IMS pro publikaci a pokud budou dokumenty staženy, podívejte se na využití webových služeb.

Procesní vrstva

4. Web jako platforma.  Ať už je to intranet nebo internet, koncept je stejný a hledá pracovní prostředí uživatelů, aby bylo online, takže ze serveru běží jakýkoli typ procesů. To je doplněno následujícím principem, protože záměrem je zajistit, aby provoz procesů nevyžadoval týmy s velkými prostředky, i když je nutné redesign desktopových aplikací.

5. Použití on-line aplikací.  To je velká výzva pro vývojáře, protože tato vrstva zahrnuje také úroveň uživatelů, kteří provádějí procesy, které přesahují rámec dotazu. To je případ katastrální údržby, která vyžaduje použití diskrétních souborů a nejen manipulaci s tabulkovými údaji. K tomu musí vybraný software poskytovat prostředí řízené správy souborů, správu verzí a proces známý jako checkout-checkin; Očekává se také, že API bude poskytovat funkce pro upřesnění funkčnosti a zabránění desktopovým procesům v komplikování synchronizace.

Uživatelská vrstva

6. Kolektivní inteligence.  Tento princip vychází z dnes velmi populární koncepce komunity. Je důležité vytvořit rozhraní, která usnadní komunikaci mezi uživateli, ať už jde o tato fóra, podpůrné sítě nebo kanály pro zasílání rychlých zpráv, aby uživatelé mohli sdílet své pochybnosti, řešení a využívat kolektivních dovedností.

7. Zpětná vazba.  Vytvořené služby musí mít dostatečné funkce, aby uživatelé mohli hlásit chyby, přidávat komentáře automaticky nebo dobrovolně. Důležité je, aby uživatelé, kteří spravují další dvě vrstvy, věděli o návštěvnících. Na této úrovni se také očekává omezený přístup, funkční registrace a aktualizace automatických změn.

Tyto zásady by měly ovlivnit okamžik, kdy se rozhodne pro značku softwaru, zejména proto, že život není v produktech výstupu, ale ve schopnosti dát mu rozvojovou ruku.