Dnes: 18. ledna 2018    | Registrace | Hledáme | Redakce | Info | Testy | Školení | Ocenění | Nápověda | Čtenář: nepřihlášen

Rychlé odkazy
  • Hlavní stránka
  • Seznam rubrik
  • Ankety
  • Editoriály
  • TOP 15
  • KONFERENCE 2008
  • KONFERENCE 2007
  • KONFERENCE 2006
  • KONFERENCE 2005
  • KONFERENCE 2004
  • Sborník
  • Testy
  • Virtuální školení
  • Personalizace


  • Hledáte práci?
    Hledáme redaktora - pojďte s námi tvořit Databázový svět!

    Vyhledávání

    Hledej
    na Databázovém světě!



    Rozšířené vyhledávání

    Rubriky
    Aktuality
    Bezpečnost
    Business
    Česká scéna
    Datové sklady
    Dokumentace
    Dotazovací jazyky
    Hardware
    Historie
    Komentáře
    Literatura
    Metodologie
    Nondb
    Open Source
    Poradna
    Produkty
    Případové studie
    Redakce
    Rozhovory
    Standardy
    Technologie
    Tipy - triky
    Tiskové zprávy
    Vývoj
    Vývojové nástroje
    Zajímavosti

    Co je to?
    Datový sklad
    Tento pojem poprvé formuloval koncem 80. let William Inmon jako strategii přístupu k datům určeným pro rozsáhlé analýzy. V případě datového skladu hovoříme o historických, časově rozlišených, agregovaných, průběžně rozšiřovaných datech uspořádaných pro podporu potřeb managementu.

    Akce
    Dynamická Datová Centra
    - na semináři se seznámíte s komplexním řešením a koncepcí Dynamických Datových Center od Fujitsu Siemens Computers se speciálním důrazem na řešení FlexFrame.

    Textová inzerce
    IBPhoenix - Vše o InterBase a Firebirdu.

    Smějete se rádi? - Pak je pro vás Vtipník to pravé!

    Prodejce reklamy - Hledáme schopného prodejce reklamního prostoru, možnost i externí spolupráce.

    Přihlášený čtenář
    Nepřihlášený čtenář

    O portálu
    Databázový svět
    ISSN: 1213-5933

    Web je optimalizován pro rozlišení 1024x768, nicméně kromě větších rozlišení podporujeme i 800x600. Podrobnosti najdete zde.

    Chcete-li mít kdykoliv možnost zkontrolovat obsah našeho portálu, můžete využít podporu rss. Podrobnosti najdete zde.
    Nejčastější chyby při modelování II.


    [Metodologie] - Modelování informačních systémů je obtížnou záležitostí pokrývající mnoho různorodých oblastí. Podobně jako v dalších lidských činnostech je i v případě modelování snaha vyhnout se chybám obvykle vykoupena jistým úsilím. Pojďme se proto spolu ve druhém a současně závěrečném pokračování tohoto mini-seriálu opět podívat na nejčastější chyby ve využití objektově orientovaného přístupu k modelování.



    Objektově orientovaný přístup
    Většinou se při objektovém přístupu hovoří pouze o samotném objektovém programování (OOP). Je však třeba si uvědomit, že principy objektového přístupu se chápou také v obecnější rovině. Týkají se také například modelování a návrhu IS, samotné syntaxe UML, modelování podniku a také i jiných objektově orientovaných systémů. Principy "objektově orientovaného přístupu" jsou trochu obecnější než pouze principy objektově orientovaného programování, které je pouze jednou z možných aplikací těchto principů. Z hlediska dalšího výkladu budeme postupovat od obecně známých vlastností samotného OOP a tyto vlastnosti zobecníme do roviny obecných principů objektového přístupu.

    V literatuře se při v definici zavádějí tři charakteristické atributy OOP:

    • zapouzdření
    • polymorfismus
    • dědičnost

    První vlastnost obecnějšího objektového přístupu souvisí úzce se zobecněním pojmu zapouzdření: Objekt je obecně nějakým prvkem, kterému klient (okolní část systému) posílá své požadavky na služby, přičemž klient je oddělen od implementace, tj. vnitřku tohoto objektu. Svět se tak rozděluje na dvě fyzicky oddělené oblasti "vnitřek a vnějšek objektu". Klient objektu má obecně zpřístupněnu množinu možných služeb objektu, které může žádat od objektu, ale implementace objektu (vnitřní struktura objektu) je mu skryta. Této vlastnosti se obecně říká zapouzdření stejně jako v OOP. Klient používá pouze množinu služeb, v objektu se provede přes převodník provázání těchto nabízených služeb s implementací uvnitř objektu, tj. s jeho vnitřní strukturou. V OOP je reprezentována množina služeb pomocí operací (interface) objektu, přičemž vnitřek objektu je klientovi "fyzicky" skryt.

    V obecnější rovině objektové filosofie se tato vlastnost chápe tak, že klient daného libovolného prvku (objektu) může tento prvek "požádat" o službu, což mu může prvek poskytnout, ale nepřistupuje (a ani nemůže) k vnitřním prvkům objektů přímo. Přesně takto uvažujeme i v analytickém modelování (což zní až tautologicky): Prvek, který patří do daného prvku, není mimo tento prvek, ale v tomto prvku a pokud třeba, může jej daný prvek vydat jako "výstupní parametr" služby. V uvedeném příkladu byl tento princip hrubě narušen: Okolí Hospodářského střediska mohlo "pracovat" s Číslem HS, které mělo být až za hranicí HS (poznámka: logicky vzato kam patří číslo HS? Do HS!) S Číslem HS mohlo být pracováno, aniž by bylo HS "chyceno", což je protimluv. Jediné, co má mít klient, je ukazatel na daný prvek (HS) a možnost dále žádat prvek o služby. Cizí klíč hraje roli tohoto ukazatele a nemůže se tedy jednat o číslo HS podléhající změnám při přečíslování. Není bez zajímavosti, že pokud by bylo opravdu zaručeno, že se střediska nebudou nikdy přečíslovávat (poznámka: známe takováto nikdy!), potom toto číslo by mohlo převzít také roli ukazatele a stalo by se správně realizací šipky v diagramu a žádné problémy by pochopitelně nenastaly.

    Důsledkem těchto a jí podobných chyb narušení obecnějšího principu zapouzdření je "rozprsknutí objektů", systém se stává zbytečně složitý, věci nejsou na svých místech "kam patří", systém je nesrozumitelný, není logický.

    Druhá vlastnost polymorfismus souvisí s existencí zmíněného převodníku vnější služba versus vnitřní implementace objektu. Protože klient používá vnější služby a nemůže použít přímo vnitřní implementaci (je od ní odstíněn), potom může nastat situace, že dva objekty nabízejí stejnou množinu služeb, ale mají je jinak implementovány. Z hlediska klienta oba objekty mohou plnit tytéž požadavky, ale každý z nich je plní jiným chováním. V OOP je tento jev implementován ve statických jazycích pomocí přepisování metod, ale opět se jedná pouze o speciální případ obecnějšího objektového principu, kdy dva prvky mohou plnit tentýž požadavek, ale každý jinak. Klasickým příkladem je věta z analytického modelování: Každý účetní doklad se zaúčtuje, přitom každý se účtuje podle svého typu. Tato věta vede k zavedení polymorfismu například v USE CASE MODELU.

    Poslední vlastnost dědění souvisí s obecnější vlastnosti objektového prostředí a tou je tzv. dichotomie (převzato z biologie) – rozdělení prvků do dvou skupin: Existuje vždy druh a instance druhu. Vlastnosti prvků nejsou definovány přímo ve výskytech prvků, ale pomocí druhu prvků, kam prvek patří. Daný výskyt z druhu nemá definovány vlastnosti sám o sobě, ale má své vlastnosti dány díky příslušnosti k druhu, kde jsou vlastnosti definovány (podobně jako v biologii). Druh se nazývá třída, výskyt se nazývá instance třídy. Je zajímavé, že samy druhy podléhají opět principům objektovosti, tj. obecně jsou chápány jako objekty. Lze tedy opět rozlišit vnější a vnitřní pohled na druh jako objekt a také lze zavést dichotomii u druhu, tj. druh druhu.

    Jinak řečeno platí vlastnost dichotomie a existence druhu na samotný druh. Znamená to tedy, že zkoumaný druh výskytů lze chápat opět jako výskyt nějakého vyššího druhu (tzv. vztah meta). Rekurzivní přechod "meta" nahoru k druhu druhu, dále k druhu druhu druhu atd. je sice teoreticky neuzavřený, ale zastavuje se na té úrovni, kdy je přechod k dalšímu druhu z hlediska řešení konkrétního problému dále nezajímavý a je tedy prakticky zbytečný.

    Dědičnost v pojetí dichotomie není nic jiného, než možnost zavést interakci na úrovni tříd (druhů), tj. "v meta-úrovni". Touto interakcí lze "poskládat třídy" ještě před tvorbou instancí. V UML v modelu tříd z toho důvodu existují dva typy interakcí: asociace a generalizace-specializace. První z nich, tj. asociace, zobrazuje vztahy mezi instancemi (viz předešlé diagramy i s popisem), druhý vztah generalizace-specializace zavádí vztah mezi třídami ještě na úrovni meta, tj. mezi třídami jako takovými (nikoliv mezi instancemi).

    Můžeme tuto situaci vyjádřit pomocí takovéhoto přirovnání: Pokud si třídy představíme jako stroje – kopyta na boty a objekty jako samotné boty, potom vztahy asociace ukazují, jak budou boty (až se narodí) spolu sešněrovány, kdežto generalizace-specializace umožňuje poskládat stroje – kopyta na boty ještě před tvorbou instancí ("typové skládání").

    Je třeba upozornit na velmi časté chyby záměny těchto interakcí, viz například kniha autora článku Design Patterns v OOP, která je ke stažení zdarma.

    Tyto obecné principy objektových prostředí bychom mohli tedy shrnout do několika málo vět:

    • Existuje vnější a vnitřní pohled na objekt: Objekt je zapouzdřen v tom smyslu, že klient má zpřístupněn ukazatel na objekt, tím má zpřístupněny jeho služby, ale nemá zpřístupněnu vnitřní implementaci objektu za hranicí objektu. Jediná možnost, jak pracovat s objektem zvně, je přes tento ukazatel a žádat o tyto služby.
    • Existuje možnost, aby dva objekty mohly plnit tutéž službu jinou implementací což je synonymum pro polymorfismus.
    • Existuje dichotomie rozdělení prvků na třídy a instance. Vlastnosti objektů jsou dány ve třídách (typech), ze kterých pocházejí. Třídy také mohou interagovat na své úrovni typů (skládat se mezi sebou) pomocí vztahu generalizace-specializace, čemuž v OOP odpovídá vztah dědičnosti.

    Jak se vyvarovat "rozprsknutí" objektů
    Při správném pochopení základních principů objektového přístupu se při návrhu systému můžeme podobným chybám "rozprsknutí objektů" vyvarovat. Je dobré znát, jakým způsobem se můžeme této velmi často opakující se chyby dopustit. Již v analytickém modelování dojde k "rozprsknutí" entity. Naštěstí při správné formulaci se tyto chyby dají lehce identifikovat. Začneme totiž pracovat s něčím, co by mělo někam patřit a ono je to v modelu chybně mimo to, kam to správně patří (špatná analytická pozice prvku). Pokud dobře "posloucháme model", potom chybu najdeme snadno. Tato chyba vzniká většinou jako důsledek zavedení pojmů, které spolu zdánlivě nesouvisejí, ale ony spolu souvisejí. Jedná se o klasickou ztrátu kompetence objektů, kdy něco obsahuje něco, co nemá obsahovat a něco neobsahuje něco, co obsahovat má. Poslechněme si na následujících příkladech, jak tyto chyby znějí při jejich vyřknutí:

    • Existuje cena zboží, se kterou se pracuje, ale bez zboží (cena zboží mimo zboží)
    • Existuje číslo HS, se kterým se pracuje, ale bez HS (číslo HS mimo HS)
    • Rodné číslo klienta a nikoliv rodné číslo fyzické osoby, která má vazbu na fyzickou osobu
    • apod.

    Je zřejmé, že tyto chyby reprezentují klasické protimluvy.

    Podobné chyby se může dopustit designér při mapování analytického (logického) modelu, když špatně zvolí primární a následně cizí klíč. Je třeba si uvědomit, že návrh primárního a cizího klíče (viz předešlý příklad) je vlastně návrh realizace daného ukazatele, o kterém je řeč v principech objektového přístupu. Proto musí mít klíč vlastnosti pouze tohoto ukazatele a ničeho jiného. Pokud například zavedeme "kód střediska", což je dohoda a jedná se o údaj již dále neměnný, chápeme jej jako realizaci šipky v předešlých diagramech.

    Pokud tuto vlastnost "jde pouze o realizaci šipky" narušíme, nastávají problémy a zbytečné složitosti. Nevím, jaké má kdo zkušenosti se složenými klíči, ale osobně jsem v projektech pociťoval určitou osobní averzi k tomuto způsobu tvorby vazeb. I když teorie databází povoluje používání složených klíčů a tato teorie je poměrně dost dobře rozpracována, je zřejmé, že složený klíč publikuje vnitřní strukturu instancí. To se projeví snížením flexibility při změnách, protože složený klíč "putuje" ven a když dojde k nějakým změnám v dané struktuře, musíme poté také přebudovat návrh všech entit, které tuto používají ve vazbě a tedy používají daný (mnohdy měnící se) složený cizí klíč.

    Například jsem toto pociťoval jako velmi nepříznivý jev zejména při iterativním vývoji IS, kdy se při vývoji postupuje "krok za krokem", anebo u systémů s velmi rychle měnícími se požadavky na něj. Složené klíče snižovaly flexibilitu systému.

    Nakonec uvedu jeden drobný postřeh s ohledem na vývoj objektově orientovaných databází. Z uvedeného vyplývá zajímavý fakt: Může se stát, že i při použití velmi silného objektově orientovaného databázového prostředí může nastat zmíněná chyba "rozprsknutí objektu" – a to například již v analytickém modelování – tedy v zavádění odpovídajících tříd. Sama "silná objektovost prostředí" tedy nemusí ještě zaručovat "správnost objektů v systému". Velmi také záleží na tom, zda je samotný návrh analytických entit chybný anebo nikoliv.

    Ilja Kraval
    RNDr. Ilja Kraval pracuje jako externí konzultant a školitel softwarových firem v oblasti OOP, UML a OA&OD. Jeho domovským serverem je projekt Objects.CZ, na kterém je možné získat odbornou literaturu (také zdarma), nabídku školení OOP a UML a samozřejmě také další informace z těchto oblastí.

    Související články:
    Nejčastější chyby při modelování I. (04.08.2004)

    ( Celý článek! | Autor: Ilja Kraval | Počet komentářů: 1 | Přidat komentář | Informační e-mailVytisknout článek )

    Vyhledávání
     

    Anketa
    Kolik ročně utratíte za dovolené?

    Nic 
     (1548 hl.)
    Do 1 000,- Kč 
     (1068 hl.)
    Do 10 000,- Kč 
     (999 hl.)
    Do 25 000,- Kč 
     (1378 hl.)
    Do 50 000,- Kč 
     (1016 hl.)
    Do 75 000,- Kč 
     (1178 hl.)
    Více než 75 000,- Kč 
     (1019 hl.)

    Celkem hlasovalo: 8206


    Poslední komentáře
    frontierd@126.com
    frontierd@126.com
    frontierd@126.com
    c
    http://www.coachoutl

    Newsletter
    Přihlaste si nezávazně - i bez registrace - odběr informačního newsletteru. Podrobné informace najdete zde.

    Emailová adresa:


    Kalendář
    <<  Leden  >>
    PoÚtStČtSoNe
    1234567
    891011121314
    15161718192021
    22232425262728
    293031    

    Redakci připojuje


    Nejčtenější

    Databáze je prázdná!


    Nejvíce komentářů

    Databáze je prázdná!


    Reklama






    Nenechte si ujít články na dalších webech




    Na této stránce použité názvy programových produktů, firem apod. mohou být ochrannými známkami
    nebo registrovanými ochrannými známkami příslušných vlastníků.

    Databázový svět | dfKlub - digitální fotografie | Vtipník - vtipy přímo k Vám | Reminder - přestaňte zapomínat | Databázový svět

    Copyright (c) 2004 AVRE Publishing, spol. s r.o. Všechna práva vyhrazena