O jednom zajímavém problému Licencování iS

autor: RNDr. Ilja Kraval, září 2010

http://www.objects.cz

Nedávno jsem se při konzultacích nad analytickým modelem jednoho rozsáhlého informačního systému setkal se zajímavým problémem: V této firmě řešili problém dodání informačních systémů „poskládaných“ pro zákazníky s různými licencemi, které vymezovaly pouze určité moduly. Některý ze zákazníků si například nepřál dodat určitou agendu (například skladové hospodářství), jiný by ji naopak chtěl. A tomu nějak odpovídá licenční politika dodavatele SW.

V uvedené firmě řešili tento problém poměrně dost nešťastně tak, že se obraceli zásadně a pouze na modularitu systému. Tomu by např. v .NET odpovídalo „skládání assembly“ resp. v Javě  “skládání package”.V takovém řešení znamenalo poskládání licence tedy nakonfigurovat komponenty systému specifickým způsobem, což způsobilo, že se určitá agenda daná těmito komponentami buď dodala anebo nedodala. Navíc samozřejmě bylo nutné provádět pro danou licenci určité nutné „ad hoc“ úpravy v kódu tak, aby linkování komponent fungovalo korektně.

Obracet se na řešení licencování IS pouze jako na konfiguraci modularity systému při řešení „dodání - nedodání“ agendy však má své nepříjemné nedostatky:

1. Autoři systému musí velmi dobře dbát na korektní modularitu systému. Pokud ji nedodrží, vznikají problémy s vypnutím nebo zapnutím agend, což se provádí poměrně dost nepříjemnými zásahy do systému.

2. Mnohdy se vyžaduje mnohem jemnější licenční politika, než jakou poskytuje rozdělení do komponent resp. modulů.

Problémy zmíněného řešení licencování vznikají díky obrácení jednoduché implikace.

Pro správné (dobré) řešení platí však následující jednoduchá logika:

Ze zavedené licence a z ní plynoucího povolení nebo zákazu určitých činností vyplývá možná konfigurace komponentního modelu (tj. konkrétní skladba modulů) a ne naopak.

Jinak řečeno tzv. Agenda licencí s povolenými činnostmi by měla být chápána jako klasická a normální agenda jako každá jiná (například jako již zmíněná agenda Skladové hospodářství) a jako taková by měla mít svůj analytický model a také technologický návrh. Z podstaty fungování agendy licencí je zřejmé, že bude velmi podobná agendě přístupových práv. Teprve na základě evidence této agendy vznikne následně z ní plynoucí možná konfigurace komponent pro daného zákazníka.

Jak bylo řečeno, Agenda licencí s povolenými činnostmi je vlastně agendou jaká každá jiná. Na tuto skutečnost navazuje také další problém k řešení: Je třeba navrhnout evidenční systém dodaných licencí, který poběží přímo u dodavatele. Analytici a následně technologové by tedy měli vyřešit dvě na sebe navazující agendy: Jedna je nasazena u dodavatele IT v jeho vnitřním systému a tato agenda eviduje, kdo jakou licenci dostal k dispozici, druhá agenda je nasazena u zákazníků a bude konkrétně omezovat nebo povolovat akce a činnosti podle nastavení dané licencí.

Tyto dvě agendy sice žijí každá v jiném prostředí (jedna je implementována u dodavatele, druhá u zákazníka), přesto spolu úzce souvisejí a měly by na sebe logicky navazovat, jak si ukážeme na příkladu.

Jako názorný a vskutku jednoduchý příklad bychom si mohli uvést následující návrh řešení:

Jako první krok si zavedeme tzv. body pro vyhodnocení licence v programu. Můžeme si pod nimi představit jednoduše konkrétní bod v běžícím programu, který je zajímavý tím, že právě zde se bude vyhodnocovat působnost licence pro zákazníka a následně, jak se má podle toho program zachovat. Dá se předpokládat, že 90% takovýchto bodů bude souviset s problematikou budování tzv. menu aplikace.

Podle tohoto návrhu řešení se má program v určitém bodě chodu rozhodnout, zda má dotyčný prvek menu povolit (například „rozsvítit“) anebo ho zakázat (například „schovat“).  V tento moment je známo, ve kterém bodě v programu jsme (například je to „bod vyhodnocení pro tento prvek menu“) a program se dotáže na stav tohoto bodu z hlediska poskytnuté licence. Podle odpovědi - stavu se vyhodnotí, jak pokračovat dále.

Každý takovýto bod vyhodnocení dostane svůj jednoznačný již dále neměnný kód a přes tento kód se budeme dotazovat na stav tohoto bodu. Dotaz může znít pro bod číslo 135 symbolicky takto:

int mStav = gVyhodnoceniLicence.GetStav(135);

Programátor samozřejmě musel z konfiguračních listů vědět, že v tomto bodě programu se má zeptat právě na bod číslo 135 a na žádný jiný.

Na první pohled by se mohlo zdát, že v tomto mechanismu vystačíme s logikou Ano / Ne určující stavy bodů licence. Dlouholetá zkušenost analytika mne však přesvědčila, že ať už jsme o čemkoliv přesvědčeni na sto procent, budoucí požadavky na systém mohou vždy překvapit. Pro jistotu proto zavedeme raději stavy jako typ integer, což je volnější pro případ evidence vícero možných stavů než pouze dva stavy Ano / Ne.

V prvním nástřelu by tak na straně dodavatele mohla vzniknout následující jednoduchá agenda evidence poskytnutých licencí takto:

Obrázek 1 Jednoduchá agenda evidence licencí dodavatele

Předešlý model čtený zprava doleva vyjadřuje následující myšlenky:

Úplně vpravo je zaveden slangově řečeno „číselník“ (tj. samostatný seznam) všech modulů pomocí třídy Modul. Tento číselník je obrazem konfigurace systému z hlediska komponentního modelu (tj. assembly v .NET, package v Javě apod.). Mezi moduly jsou sice vztahy závislostí, kdo koho si linkuje (using, import, include apod.), které tu nejsou namalovány, ale ty vyplývají z evidence projektu ve fázi návrhu technologie (designu).  Hned nad seznamem modulů je zaveden další seznam („číselník“) všech bodů k vyhodnocení. Každý bod vyhodnocení patří ke svému modulu a odkazuje si na něj.  

Když budeme číst model dále zprava doleva, zřetelně zde rozpoznáme dvojí nasazení vzoru Vlak má svoje vagóny.

Poznámka: O tomto silném vzoru viz například kniha Analytické modelování resp. praktické použití obsahuje navazující internetové školení Kurz profesního růstu analytika od základů - distanční e-kurz. 

Jedna konfigurace licence obsahuje N svých bodů konfigurace licence s nastaveným stavem, zákazník má nasazeno celkem N konfigurací (chápáno i v čase).

Z evidence lze jednoduše určit, které moduly je třeba pro danou konfiguraci licence nezbytně přilinkovat: Pokud se daný bod v dané konfiguraci nachází ve stavu „povoleno“, potom musí být bezpodmínečně přilinkován ten modul, pod nějž tento bod spadá.    

Uvedený model umožňuje velmi detailní licencování akcí a činností „až do mrtě“, pokud tedy „prošpikujeme“ kód velmi mnoha body vyhodnocení. Na druhou stranu u rozsáhlých systémů tato jemnost licencování může být vzhledem k velikosti systému na škodu, protože konfigurace se pak skládá z velmi mnoha „malinkých cihliček“.  Určitého vylepšení této nepříjemné situace dosáhneme zavedením implicitního stavu, který interpretuje situaci „daný bod není zahrnut v evidenci“, například není v evidenci  = „povolen“ anebo naopak „zakázán“, tím se evidence sice zjednoduší, ale stále to neřeší problém složité konfigurace velkého systému.

Proto navrhneme další vylepšení jako možnost „grupování“ bodů do vyšších složených bodů a podobně také navrhneme grupování (neboli skládání) konfigurace licencí. První mechanismus skládání bodů do skupin spočívá v tom, že umožníme vznik „vyšších složených bodů“ jako skupin bodů, což nakonec slouží k jednoduššímu přiřazení bodů do konfigurace pomocí celé skupiny najednou, kdy všichni podřízení mají stejný stav jako nadřízený (například celá agenda). Druhý mechanismus skládání konfigurací slouží k možnosti poskládat konfigurace z již existujících konfigurací.

Všimněme si, že oba modely skládání můžeme zavést jako velmi podobné:

Obrázek 2 Skládání konfigurací a bodů

Číselníky Typ konfigurace a Typ bodu mají oba pouze po dvou prvcích, první má text „jednoduchý“ (tj. nesložený) a druhý má text „složený“.  

Poznámka: Je dobře viditelné, že díky tomu, že mají stejný obsah, daly by se oba číselníky sloučit, tj. mohl by se zvolit pouze jeden číselník. Ale nevíme, zda se v budoucnu „náhodou“ oba číselníky pro oba typy „nerozejdou“. Poučen následnými nechutnými předělávkami systému jsem v tomto ohledu pesimista (tedy přesněji realista) a zavádím proto v příkladu oba číselníky, i když jsou obsahově shodné.

Tyto dva modely umožňují vytvořit „vyšší“ složené prvky jak z konfigurací, tak z bodů vyhodnocení (proto jsou si oba modely velice podobné). Princip fungování je však u nich trochu jiný: Vytvoření vyššího bodu umožňuje následně v dané konfiguraci přiřadit stav celé skupině bodů najednou, skládání konfigurací znamená možnost poskládat jinou konfiguraci z již existujících. Při skládání konfigurací je třeba zohlednit možnost kolize, kdy se může jeden a tentýž bod objevit ve složené konfiguraci dvakrát (resp. vícekrát) díky jeho opakovanému výskytu ve skládajících podřízených konfiguracích. Je tedy třeba vyřešit „algebru skládajících stavů“. Vzhledem k povaze věci, kdy „udělení licence“ znamená povolení akce v nich, by logicky nejjednodušší správnou variantou bylo to, že „povolení bodu vždy vyhraje nad zákazem“, tj. jakmile se ve skládajících konfiguracích objeví alespoň jednou povoleno, bude platit povoleno bez ohledu na ostatní skládající konfigurace (obdoba OR).

V předešlé kapitole bylo pojednáno o agendě, kterou spravuje dodavatel, tedy tvůrce IS, ve svém vnitřním systému u sebe, například na firemním intranetu. Je zřejmé, že tato agenda nebude nasazena u zákazníka v této podobě.

Pro nasazení u zákazníka je třeba z předešlé agendy vytvořit konkrétní export jeho konfigurace s body a jejich stavy. Předešlá agenda tedy bude mít jeden specifický případ užití, nazvěme jej například Export konfigurace licence do systému zákazníka.

V tomto případu užití se na základě poskytnuté licence vygenerují všechny stavy bodů, což je vlastně seznam dvojic „kód bodu + stav bodu“ například do zvláštní tabulky anebo souboru.

Scénář tohoto případu užití není v podstatě až tak složitý (viz Obrázek 1): Pro danou Konfiguraci se projdou všechny Stavy bodů v licenci, v každém z nich se převezme Stav a Bod z odkazů do seznamů (konce šipek). Pokud je agenda rozšířena o skládání, pak se navíc ještě projdou podřízené prvky odpovídajícím algoritmem průchodu dolů k nadřízeným, což bude specifické pro zpracování složených bodů resp. složených licencí.

Jako vedlejší produkt dostaneme také nutné moduly, které (kromě jiných modulů) vyplývají z povolených činností dané konfigurace licence jako nezbytně přilinkované.

Takže nakonec jako doslova primitivní výsledek tohoto zpracování dostaneme seznam dvojic „kód bodu + stav bodu“ odpovídající dané konfiguraci při nasazení u zákazníka. Tento seznam se umístí do systému zákazníka (například jako jedna tabulka), na něj se bude obracet běžící systém při vyhodnocování práva v dané licenci.

V některých firmách se řeší licencování a z toho plynoucí práva k činnostem „ad hoc“ u zákazníka bez toho, že by vznikla relevantní agenda s evidencí licencí a práv v nich.

Dodavatel by si měl evidovat konfigurace licencí jako odpovídající práva k činnostem a také přiřazení konfigurací licencí k zákazníkům.

Na základě této evidence by se měla vygenerovat práva aplikace k činnostem, ta jsou odvozena z licence, a také by se měl vytvořit odpovídající seznam nutných modulů, které tato konfigurace (kromě jiných modulů) vyžaduje.

Konec článku

Zajímavá nabídka pro firmy z Brna a okolí Pobytový kurz návrh IS pomocí UML a OOP jaro 2012 Kurz profesního růstu analytika AM ADVANCED, termín 12.3.2012