Framework pro vývoj ERP aplikací

Framework pro vývoj ERP aplikací Pavel Lelovský CÍGLER SOFTWARE, a. s. plelovsky@money.cz Abstrakt Článek pojednává o softwarovém frameworku, vhodném pro rychlý vývoj ERP aplikací. Dále se zaměřuje na některé typické problémy, spojené s vývojem tohoto druhu aplikací. Klíčová slova: framework, rychlý vývoj aplikací, ERP aplikace, objektově orientovaný přístup, OOP, relační databáze, objektově-relační mapování, ORM, metadata. Abstract The article discusses a software framework suitable for rapid ERP aplications development. It also focuses on some typical issuses related to development of this kind of applications. Keywords: framework, rapid application development, ERP application, objectoriented paradigm, OOP, relational database, object-relational mapping, ORM, metadata. Úvod Zkratkou ERP jsou označovány informační systémy, zastřešující ekonomickou činnost podniku. Typicky se jedná o výrobu, logistiku, distribuci, fakturaci, účetnictví, správu majetku, zpracování mezd. Charakter ERP systémů a prostředí, pro které jsou určeny, klade na jejich vývoj určité specifické požadavky, které se při vývoji jiných druhů SW nevyskytují nebo nejsou tak striktní. ERP systémy jsou zaměřené především na zpracování dat. Jejich účelem je poskytováni potřebných informací uživatelům systému a podpora automatizace podnikových procesů. ERP systém musí být proto koncipovaný a data strukturovaná takovým způsobem, aby odpovídala co nejvíce realitě, tj. aby poskytované informace byly dostatečné a správné a jejich získání nebylo komplikované. Zpracování dat podléhá určitým obchodním a legislativním pravidlům. Tato pravidla často nemají logiku, obsahují velké množství různých výjimek a stále se mění. Uvedené skutečnosti jsou příčinou toho, že data zpracovávaná v ERP systému bývají značně složitá. Obvykle se jedná ukládání a zpracování velkých objemů dat, ERP sytém tedy musí také být dostatečně výkonný, aby informace byly poskytované rychle, nejlépe v reálném čase. Další požadavky kladené na zpracování dat jsou spolehlivost a bezpečnost data musí být dostupná v potřebný okamžik a musí být chráněna před poškozením nebo zneužitím. Systém musí korektně zvládat i situace, kdy se více uživatelů současně snaží pracovat se stejnými daty. SYSTÉMOVÁ INTEGRACE 4/2009 37

Pavel Lelovský Samostatná skupina požadavků, kladených na dostupnost informací, zahrnuje otevřenost, tj. schopnost spolupráce s jinými systémy a zařízeními, exporty a importy dat nebo možnost vzdáleného přístupu uživatelů z libovolného místa. Pro vývoj ERP aplikací je typické, že musí být vyvinuté rychle a i po svém dokončení podléhají neustálým následným změnám. V podnikovém prostředí se mění takřka vše legislativa, organizační změny, trendy a požadavky zákazníků, nové výrobky, postupy a technologie a v neposlední řadě i IT prostředky. Uvádí se, že dokončený systém je v době svého uvedení do provozu v podstatě již zastaralý, vzhledem k tomu, že doba vývoje systému typického rozsahu se počítá na roky. Za tuto dobu se vyskytne mnoho nových okolností, na které je třeba reagovat, a se kterými při návrhu systému nebylo možné počítat. Pokud vývoj trvá neúměrně dlouho nebo není systém schopný přizpůsobení, je odsouzen k neúspěchu. Pro uživatele představuje podnikový informační systém profesionální nástroj a při práci s ním stráví mnoho hodin denně. Proto je důležité hledisko ergonomie uživatelského rozhraní. I při velké různorodosti dat a množství obrazovek v odlišných modulech je žádoucí jednotný vzhled a ovládání. Článek se zabývá řešením, které se snaží postihnout uvedené problémy. Toto řešení spočívá v použití frameworku specializovaného na vývoj ERP aplikací. V následujících kapitolách budou některé aspekty podrobněji rozvedeny a bude uvedeno, jaký může být v konkrétních případech přínos použití frameworku. Architektura softwarových frameworků obecně Framework dle jedné z možných definic představuje rozšiřitelné a přitom konkrétní řídící řešení opakujících se složitých problémů. Softwarovým frameworkem rozumíme softwarové řešení, které slouží jako podpora při vývoji a organizaci jiných softwarových projektů. Framework obsahuje základní kód, poskytující obecnou funkčnost, který může být volitelně nahrazen nebo doplněn uživatelským kódem, zajišťujícím požadovanou specifickou funkčnost. Cílem frameworku je vyřešení typických problémů dané oblasti, takže se vývojáři mohou soustředit na vlastní zadání a jsou oproštěni od nutnosti neustálého řešení množství detailů, bez kterých by ovšem konečný systém nebyl funkční. Softwarový framework má několik vlastností, kterými se odlišuje od knihoven funkcí, návrhových vzorů nebo běžných aplikací: - je konkrétní obsahuje fyzické komponenty, se kterými se dále pracuje. Framework může mít základní funkčnost, která je sama o sobě použitelná v běžných případech, kdy není požadováno specifické chování. - je nekompletní a rozšiřitelný sám o sobě není určen k finálnímu použití. Ponechává doplnění některých částí na svém uživateli a umožňuje rozšíření volitelným přepsáním částí kódu nebo doplněním kódu, který zajišťuje požadovanou funkčnost. - je řídící určuje celkovou architekturu cílového řešení, běh programu je řízen frameworkem, nikoliv volajícím prvkem či uživatelem. - pomáhá při řešení opakujících se problémů. Užitečnost frameworku je tím vyšší, čím častěji ho lze opakovaně použít. Jedná se o základní kriterium, framework pro jedno použití nemá žádný smysl. 38 SYSTÉMOVÁ INTEGRACE 4/2009

Framework pro vývoj ERP aplikací - je určen pro složité problémy problém sečtení dvou čísel vyřeší funkce z knihovny. Zajištění perzistence objektů je již problém, na který je vhodné použít framework. Framework se skládá z pevných částí (tzv. frozen spots) a z měnitelných částí (tzv. hot spots). Pevné části definují celkovou architekturu frameworku, jedná se o jeho základní komponenty a vztahy mezi nimi. Ty zůstávají při jakémkoliv použití frameworku neměnné (frozen). Naproti tomu měnitelné části představují body, ve kterých může aplikační programátor, používající framework, doplnit vlastní kód se specifickou funkčností požadovanou pro konkrétní projekt. V objektově orientovaném prostředí je framework tvořen abstraktními a konkrétními (klasickými) třídami. Třídy mohou mít abstraktní a přepisovatelné (virtuální) metody. Při vývoji konkrétního řešení s použitím frameworku mohou vývojáři kromě používání instancí základních tříd podle potřeb využít hot spots frameworku některým z těchto způsobů: vytvoření vlastních tříd odvozených ze základních tříd frameworku, implementace abstraktních metod nebo přepsání virtuálních metod základních tříd. Většinou se jedná o metody, které umožňují zpracování události, vyvolaných v rámci scénářů prováděných frameworkem. Čím je framework výkonnější a propracovanější, tím méně je částí které musí být doplněny. Současně ovšem složitější framework klade vyšší nároky na jeho zvládnutí. Vždy je třeba zvážit kompromis mezi úsporou času při kódování a křivkou učení. V dnešní době však již nemá smysl snažit se řešit jakýkoliv složitější úkol bez použití frameworku. Platformy a technologie Současným vrcholem znalostí o tvorbě programových a informačních systémů je objektově orientovaný přístup (Object-Oriented Paradigm, OOP). Objektový přístup nejlépe odpovídá činnosti lidského mozku a je proto vhodný k řešení i velmi složitých problémů. Je to metodika vývoje softwaru, při které se aplikace skládá z navzájem propojených a spolupracujících objektů. Složitost dat a výpočtů je zapouzdřena v objektu a přístup k objektu je realizován prostřednictvím jednoduchého, konzistentního rozhraní. Rozhraním objektu rozumíme množinu zpráv, které je možné objektu zasílat a kterým objekt "rozumí". Vlastnosti objektů nejsou omezeny na jednoduché počítačově orientované datové typy. Objekty mohou obsahovat jiné objekty nebo odkazy na jiné objekty, což usnadňuje vytváření užitečných a smysluplných datových modelů. Pomocí objektů se snažíme v počítači modelovat principy reálného světa pokud možno jedna ku jedné. Objekty v ekonomickém informačním systému představují entity jako např. faktura, zákazník nebo bankovní účet. Vývoj složitých aplikací s použitím objektové technologie je mnohem rychlejší a pozdější úpravy jsou jednodušší. Objektový přístup je v současné době proto podporován množstvím programovacích jazyků a vývojových prostředí. V oblasti databázových systémů na rozdíl od programovacích jazyků převládá v současnosti relační model, který nepracuje s objekty, ale s tabulkami, sloupci a relacemi. Tento model vyhovuje jednoduchému a výkonnému dotazovacímu jazyku SQL. Jazyk SQL se stal standardem, který podporuje velké množství nástrojů na vytváření výstupních sestav. Relační databáze mají výhodu také v tom, že disponují prostředky, kterými lze zajistit korektnost ukládaných dat bez ohledu na SYSTÉMOVÁ INTEGRACE 4/2009 39

Pavel Lelovský aplikaci, která s těmito daty pracuje. Jedná se zejména o cizí klíče, možnost definice různých omezení a automatických akcí pro jednotlivé tabulky a o transakční zpracování. Relační databázové systémy jsou schopné ukládat a zpracovávat pouze skalární hodnoty, tj. jednoduché datové typy (např. string nebo integer). Pro zajištění perzistence objektů v relační databázi musí programátor provádět konverzi objektových struktur do formy, která může být uložena v databázi. Jedná se o rozdělení objektů na skupiny jednoduchých hodnot do více tabulek. Při načítání dat objektů z databáze je nutné při zpětné konverzi tabulky opět spojovat. S těmito úkony je spojena značná pracnost, zahrnující např. definici primárních a cizích klíčů, zajištění referenční integrity, konstrukci komplikovaných dotazů s různými typy spojení atd. Souhrn koncepčních a technických problémů, které vznikají, pokud objektově orientovaná aplikace používá pro perzistenci objektů relační databázový systém, se nazývá objektově-relační nesoulad (object-relational impedance mismatch). Tento termín byl převzat z elektrotechnické terminologie, kde impedance matching znamená přizpůsobení vstupního odporu elektrické zátěže výstupnímu odporu elektrického zdroje, tedy zjednodušeně přizpůsobení vstupu a výstupu dvou elektrických obvodů. Techniky konverze dat, překonávající nesoulad mezi zmíněnými dvěma nekompatibilními technologiemi, označujeme jako objektověrelační mapování (Object-Relational Mapping, ORM). Objektově-relační mapování je typickým příkladem problému, který je řešen pomocí různých frameworků. Požadavky na framework pro vývoj ERP aplikací ERP systém uchovává a zpracovává údaje o objektech, týkajících se ekonomické činnosti podniku a o vztazích mezi těmito objekty, přičemž tyto vztahy jsou velice různorodé. Reálný svět je složen z objektů, které jsou charakterizovány určitými vlastnostmi a mezi kterými existují určité vztahy. Pojmem objekt v této souvislosti rozumíme i reálně existující, avšak nehmotné entity, jako např. organizace, která je charakterizována svým identifikačním číslem, názvem, adresou, počtem zaměstnanců, roční produkcí apod. Také vlastnosti hmotných objektů mohou být, kromě skutečných "hmatatelných" vlastností, jako je např. délka, hmotnost apod. i nehmotné název, identifikační číslo, datum výroby apod. Protože se jedná o druh aplikace zpracovávající data (používá se pro ně též označení databázová aplikace), nazýváme objekty zpracovávané v takové aplikaci datovými objekty. První krok při vývoji objektově orientované aplikace spočívá v identifikaci všech objektů, se kterými se má v aplikaci pracovat a jejich vzájemných vztahů. Tato fáze je označována jako datové modelování. Přitom na základě jednotlivých identifikovaných objektů popisujeme druh objektu, který definuje vlastnosti a chování všech výskytů množiny určitých objektů. V objektově orientovaném vývojovém prostředí se pro druh objektu používá označení třída objektů. Každá třída poskytuje svému okolí rozhraní, tj. sadu vlastností a metod, pomocí kterého lze s objektem dané třídy komunikovat zjišťovat a měnit hodnoty vlastností a volat metody. Metoda je určitá posloupnost operací definovaných uvnitř třídy, která vrací volajícímu okolí nějaký zjištěný výsledek a/nebo manipuluje s vnitřním stavem objektu. 40 SYSTÉMOVÁ INTEGRACE 4/2009

Framework pro vývoj ERP aplikací Mezi různými druhy objektů existuje určitá příbuznost, to znamená, že mají řadu vlastnosti společných. V jiných vlastnostech se naopak liší. Koncept popisu objektů pomocí tříd umožňuje definovat odvozené třídy objektů. Odvozené třídy sdílejí některé nebo všechny vlastnosti základní třídy a přidávají k nim vlastnosti, které jsou specifické pouze pro odvozenou třídu. Tento vztah mezi základní a odvozenou třídou nazýváme vztahem generalizace specializace. Což znamená, že při datovém modelování většinou při nalezení shodných vlastností několika tříd definujeme obecnou třídu objektů, do které soustředíme společné vlastnosti několika tříd (generalizace) a následně tyto třídy definujeme jako odvozené speciální případy obecné třídy (specializace). Vztahy generalizace specializace se mohou opakovat odvozená třída může mít další odvozené třídy a tím se vytváří stromy hierarchie tříd objektů. Tato vlastnost OOP vyžaduje důkladnou analýzu při datovém modelování, na druhé straně přináší úsporu času při vývoji nejen díky tomu, že jsou společné vlastnosti naprogramované pouze jednou v obecných třídách, ale také proto, že hotové třídy je možné opakovaně použít, nebo z nich vytvořit třídy odvozené, v různých částech aplikace. Určité vlastnosti chceme sledovat u všech evidovaných druhů objektů. Jsou to takové vlastnosti jako název, datum vytvoření, autor, apod. Tyto základní vlastnosti jsou součástí nejzákladnější třídy datových objektů, která je vrcholem celé hierarchie tříd datových objektů. Při práci uživatele s jakýmkoliv druhem evidovaných záznamů se některé činnosti stále opakují a stejně jako u tříd objektů, vyskytují se i zde určité společné rysy. Mezi opakované činnosti patří zejména - zobrazení seznamu záznamů - organizace seznamu záznamů do skupin - filtrování seznamu záznamů - vyhledání požadovaného záznamu - přidání nového záznamu - kopírování záznamu - editace záznamu - smazání záznamu - zobrazení ostatních záznamů a informací souvisejících se záznamem - tisk detailu záznamu nebo tisk seznamu záznamů - export a import dat do/z různých formátů a další. Dále se jedná o funkce, které uživatel přímo neovlivňuje např. řízení přístupových práv k objektům a jejich jednotlivým údajům, záznam historie změn a akcí prováděných s objektem a mnoho dalších. Z uvedených důvodů vyplývá potřeba jednotného uživatelského rozhraní pro práci s libovolným druhem objektu. Vytvoření takového rozhraní je možné pouze díky existenci obecné třídy datových objektů. Důležitou vlastností OOP je tzv. polymorfismus. V objektově orientované technologii je odděleno samotné rozhraní objektu od jeho implementace. Znamená to, že okolí komunikuje s objektem výhradně prostřednictvím jeho rozhraní, které je definováno třídou objektu. Každý objekt implementuje rozhraní (tj. je schopen SYSTÉMOVÁ INTEGRACE 4/2009 41

Pavel Lelovský pomocí tohoto rozhraní komunikovat) nejen své třídy, ale i všech obecnějších tříd, ze kterých je třída objektu odvozena. Okolí při komunikaci pomocí rozhraní nezajímá, ze které konkrétní třídy komunikující objekt pochází; zcela stačí, že tento objekt dané rozhraní implementuje, tj. rozumí zasílaným zprávám. Rozhraní třídy obecného datového objektu implementují všechny datové objekty v aplikaci. Nad tímto rozhraním je proto možné definovat univerzální scénáře, které probíhají stejně pro jakýkoliv konkrétní druh objektu a které je v případě potřeby možné doplnit nebo modifikovat. Práce aplikačního programátora pak spočívá právě v těchto specifických úpravách, bez nutnosti řešení stále se opakujících základních operací. Metadata Běžný ERP systém obsahuje řádově stovky druhů evidovaných objektů. Doplnění specializovaného kódu do všech těchto tříd stále představuje značný objem pracnosti. Navíc kromě datových objektů samotných je zapotřebí ke každé třídě datového objektu vytvořit několik tříd objektů služebních, které s datovými objekty pracují pro správu seznamu datových objektů, pro ukládání a načítání dat objektu do/z databáze a další. Snaha o další zjednodušení a automatizaci procesu vývoje vedla proto k vytvoření konceptu tzv. metadat. Předpona "meta-" je používána u pojmů, které představují popis jiných pojmů. Je možné ji přeložit jako předložku "o". Metadata jsou tedy data o datech, data určená k popisu jiných dat. Metadata jsou používána jako prostředek, který umožňuje pochopit význam dat, podporuje jejich použití a správu. Metadata jsou v softwarových systémech uložena ve specializovaném úložišti metadat. Každý systém používá metadata v podobě, která umožňuje práci s daty podle účelu a zaměření daného systému. Příkladem metadat může být databázové schema, popisující tabulky a vazby v relační databázi nebo XML schema, popisující strukturu, tj. elementy a atributy, XML dokumentu. Metadata popisující datové objekty, evidované v ekonomické aplikaci, obsahují proto takové informace o datových objektech, které jsou potřebné pro práci s nimi. Jedná se o popis vlastností objektů a popis vztahů mezi objekty. Na základě tohoto popisu je umožněno jednak automatizované generování kódu tříd objektů a databázových tabulek pro ukládání dat objektů, jednak vytvoření univerzálních algoritmů, které pracují s objekty libovolného druhu a přitom využívají informací uložených v metadatech. Vlastnosti objektů, které jsou jednoduchých datových typů, nazýváme atributy objektů. Vztahy mezi objekty nazýváme asociace. V terminologii objektových technologií jsou atributy i asociace souhrnně označovány jako properties (jednotné číslo property) objektu. Atributy jsou properties jednoduchých datových typů, asociace jsou properties objektových typů. Popis veškerých properties v metadatech obsahuje některé společné prvky. Především je to název property, který slouží jako identifikátor pro přístup k obsahu property v kódu programu. Dále je to typ property. U atributu se jedná o výběr z typů podporovaných programovacím prostředím. Pro datové objekty v ekonomickém IS používáme většinou pouze podmnožinu možných typů: - string řetězec znaků s udanou maximální délkou, případně s neomezenou délkou 42 SYSTÉMOVÁ INTEGRACE 4/2009

Framework pro vývoj ERP aplikací - integer celé číslo, volitelně s udáním minimální a/nebo maximální hodnoty - date kalendářní datum - decimal číslo s udaným pevným počtem desetinných míst pro zápis částek, množství apod. - boolean logická hodnota Ano/Ne Zejména pro zajištění objektově-relačního mapování je důležitý popis asociací, tj. vazeb mezi objekty. Z hlediska popisovaného objektu, tj. objektu, který obsahuje danou property objektového typu, dělíme asociace na tyto základní skupiny: - běžná asociace. Objekt používá odkaz na jiný objekt, není však vlastníkem asociovaného objektu, tj. žádným způsobem neřídí jeho vznik ani zánik. Asociovaný objekt existuje nezávisle na objektu, který na něj má asociaci. Při ukládání objektu nedochází k ukládání asociovaného objektu. V databázi je běžná asociace uložena jako ID asociovaného objektu v tabulce popisovaného objektu. Nad tímto ID je vhodné vytvořit cizí klíč, který zabrání jednak vložení neplatného odkazu na neexistující záznam, jednak smazání záznamu, na který existuje nějaký odkaz.např. faktura obsahuje odkaz na firmu odběratele. Firma může být evidována bez toho, že by na ni odkazoval nějaký doklad. Zrušení dokladu s odkazem na firmu nijak neovlivní existenci firmy. - agregace. Objekt obsahuje jiný objekt jako svou součást, tj. je vlastníkem tohoto podřízeného objektu. Agregovaný objekt je vytvořen po vytvoření vlastníka a je zrušen při zrušení vlastníka. Většinou je vazba mezi hlavním a podřízeným objektem 1:N, tj. objekt vlastní seznam podřízených objektů. Agregace je v databázi uložena jako ID nadřazeného objektu v tabulce podřízeného objektu. Nad tímto ID může být vytvořen cizí klíč, který při smazání záznamu nadřazeného objektu smaže i záznam podřízeného objektu, tím se zabrání vzniku tzv. "sirotků".např. faktura vlastní položky faktury, položka nemůže existovat bez existence dokladu. - sériový objekt Objekt vlastní jiný objekt podobně jako při agregaci, z hlediska objektového přístupu není mezi agregovaným a sériovým objektem rozdíl. Data sériového objektu však nejsou uložena v samostatné tabulce, ale v tabulce nadřazeného objektu se speciálním pojmenováním. (Tento typ vazby bývá také označován jako Embedded Value.)Např. objekt Firma obsahuje property objektového typu s názvem Adresa, jedná se o sériový objekt, který má atributy Ulice, PSC, Misto. Při objektovém přístupu se k hodnotám dostaneme běžným způsobem Informací uložených v metadatech využívá framework ke konstrukci databázových SQL dotazů. Tím je řízeno pořadí ukládání a načítání objektů tak, aby bylo optimalizované a zároveň aby nebyla porušena referenční integrita dat v relační databázi. Framework zajišťuje i transakční zpracování a řešení konfliktů při konkurenčním přístupu více uživatelů k datům. Pro aplikační programátory tedy úplně odpadá nutnost se těmito nízkoúrovňovými záležitostmi zabývat. Na druhé straně je možná v případě potřeby úprava generovaných dotazů, kterou mohou SYSTÉMOVÁ INTEGRACE 4/2009 43

Pavel Lelovský provádět implementátoři systému bez nutnosti zásahu do zdrojového kódu aplikace. Základní části frameworku Podle osvědčených pravidel pro tvorbu programových systémů je vhodné framework rozdělit do dvou vrstev: - První z nich se skládá z tříd systémových objektů, které obsahují základní mechanismy, zajišťující perzistenci dat objektů, tj. ukládání a načítání dat objektů do / z relační databáze, včetně objektově relačního mapování, inicializaci objektů, tj. nastavení výchozích hodnot vlastností objektů apod. - Druhá část obsahuje prvky uživatelského rozhraní, ve kterých jsou realizovány základní scénáře, ty pracují s obecným rozhraním společným pro všechny datové objekty. Základními prvky uživatelského rozhraní jsou - seznam záznamů Zobrazuje záznamy jednoho druhu objektu ve formě gridu s řádky představujícími jednotlivé záznamy a sloupci s hodnotami jednotlivých údajů objektů. V seznamu je možné zobrazovat údaje samotného objektu i objektů spojených pomocí asociací. Seznam automaticky podporuje výše uvedené základní operace se záznamy. - karta záznamu Zobrazuje editační formulář s vizuálními prvky, které zobrazují a pomocí kterých lze měnit hodnoty editovaného objektu. Formulář může obsahovat i seznam záznamů objektů, které jsou editovanému objektu podřízené např. editační formulář dokladu obsahuje seznam položek dokladu. V podřízeném seznamu je opět přístupná množina základních operací, která je ovšem oproti standardnímu seznamu omezena na operace, které mají v podřízeném seznamu smysl. Informační systém je dělen do relativně samostatných celků, tzv. modulů. Každý modul je určen pro řešení určité problematiky (např. fakturace, sklady, mzdy, majetek) a obsahuje svoje třídy objektů. Některé moduly jsou systémové. Ty tvoří jádro aplikace a obsahují objekty, které nejsou předky datových objektů. Jedná se o "služební" objekty, zajišťující vlastní běh aplikace, připojení k databázi, správu aktivní relace přihlášeného uživatele (session), přístupová práva k datovým objektům a další. Správa uživatelů a přístupových práv jsou důležitou součástí frameworku. Pro evidované uživatele lze definovat oprávnění k objektům jednotlivých modulů, a to až na úroveň jednotlivých vlastností. Přitom je tento mechanismus společný pro všechny třídy objektů definované pomocí metadat, tedy i pro objekty z dosud neexistujících budoucích modulů. Vývoj aplikace s pomocí frameworku Závěrečná kapitola článku popisuje způsob vývoje s využitím frameworku. 44 SYSTÉMOVÁ INTEGRACE 4/2009

Framework pro vývoj ERP aplikací K popisu objektů pomocí metadat je určena speciální aplikace (Správa metadat), která umožňuje správu metadat. Vývoj každého nového modulu a nového objektu pak začíná právě v této aplikaci. Na první úrovni zobrazuje Správa metadat seznam modulů. Metadata modulu obsahují popisné informace název a popis modulu. Dále je zde název jmenného prostoru (namespace), který třídy z daného modulu používají a jméno výsledného sestavení (assembly), ve kterém bude modul umístěn. Pro každý modul jsou opět podle pravidel vrstvení aplikací vytvářeny 2 projekty ve vývojovém prostředí: projekt tzv. business logiky obsahující vlastní datové objekty a projekt s vrstvou uživatelského rozhraní (user interface, UI), obsahující formuláře, dialogy a další prvky uživatelského rozhraní, používající různé vizuální komponenty. Projekt s UI vrstvou obsahuje referenci na související business projekt a podle potřeby může obsahovat reference i na další potřebné moduly, s jejichž objekty potřebuje pracovat. Oba typy projektů pak obsahují reference na knihovny se základními aplikačními moduly. Po otevření některého modulu se zobrazí seznam objektů v modulu. Zde je možné přidávat a upravovat objekty. Při přidávání nového objektu je možné využít buď jeho odvození z již existujícího objektu, nebo vybrat rozhraní některého existujícího objektu, které bude nový objekt implementovat. Mezi vlastnosti nově definovaného objetu se automaticky přidají vlastnosti jiných objektů získané odvozením nebo implementací rozhraní. Při práci s definicí objektu je možné přidávat a editovat jeho properties, které mohou být jednoduchých datových typů (atributy) nebo objektových typů (asociace). U každé property se pomocí jednoduchého tzv. property editoru nastavuje několik vlastností, které potom určují chování objektu při běhu aplikace. Mimo jiné se zde zdává uživatelský popis property, který se zobrazuje uživateli při práci s aplikací v záhlaví sloupců seznamu záznamů, při definici podmínek pro filtrování dat apod. Tyto popisy je možné vyexportovat pro překlad do cizích jazyků a lze z nich vytvořit tzv. resources pro.net aplikaci, které obsahují popisy vždy pro určitý jazyk. Aktivací určitého resource lze potom přepínat jazykovou verzi za běhu programu. Na základě vlastností objektu se v další části Správy metadat definují sloupce seznamu, ve kterém budou data daného druhu objektu zobrazovány uživateli. Základní scénáře, vytvořené v kódu části framewoku týkající se uživatelského rozhraní, zajišťují jednotné provádění operací v seznamu s jakýmkoliv druhem objektů. Důležitou částí, která tvoří závěr části vývoje probíhající v prostředí Správy metadat, je generování kódu tříd objektů a scriptů s DDL příkazy pro vytvoření databázových tabulek. Samostatnou částí je správa indexů a cizích klíčů, pro které existuje možnost automatického vytvoření a pro které lze též generovat DDL scripty. Správa metadat obsahuje také část, ve které se definuje obsah hlavního menu aplikace. Menu se generuje podle popisu v metadatech. Jeho struktura se využívá i v jiných částech aplikace, např. při definici přístupových práv k jednotlivým volbám. Další vývoj již probíhá v programovacím prostředí, ve kterém je možné upravovat kód vygenerovaných tříd. V projektu s UI vrstvou se navrhují editační formuláře objektů. Přitom se opět vychází z připravených obecných tříd s definicí formulářů, které obsahují základní vizuální prvky a jsou v nich naprogramovány obecné SYSTÉMOVÁ INTEGRACE 4/2009 45

Pavel Lelovský funkce. Mezi ně patří například automatizovaná obousměrná synchronizace mezi hodnotami properties editovaného objektu a obsahem vizuálních prvků (editační pole, zatrhávací pole, přepínače apod.). Stačí přidat dvojici konkrétních hodnot property objektu + vizuální prvek do seznamu sledovaných vazeb na formuláři. Dalším příkladem může být automatické uložení objektu do databáze, jestliže uživatel aktivoval na formuláři příslušnou funkci, nebo vyhodnocení, zda došlo během editace ke změně některé hodnoty a zobrazení dotazu na uložení při uzavírání okna formuláře. Podle nastavení přístupových práv přihlášeného uživatele k druhu editovaného objektu jsou také automaticky nepřístupné nebo zcela skryté editační prvky s hodnotami těch údajů, ke kterým uživatel nemá oprávnění k editaci nebo ke čtení. Závěr Podle požadavků popsaných v článku byl vyvinut framework pro potřeby společnosti CÍGLER SOFTWARE, a. s. Tento framework byl s úspěchem použit při vývoji informačního systému Money S4. Aplikační část je vytvořena na platformě Microsoft.NET, ve vývojovém prostředí MS Visual Studio 2008 v programovacím jazyce C#. Data jsou ukládána v relační databázi Microsoft SQL Server 2005/2008. Literatura 1. Ilja Kraval: Základy objektově orientovaného programování, Computer Press, 1998 2. Ilja Kraval: Objektové modelování a UML v praxi, elektronická kniha, 2001 3. Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2003 4. Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki 5. Pavel Drbal: Objekty, http://objekty.vse.cz/objekty/objekty 46 SYSTÉMOVÁ INTEGRACE 4/2009