Pořádající instituce VŠB – Technická univerzita Ostrava, FEI, Katedra informatiky Česká zemědělská univerzita v Praze, PEF, Katedra informačního inženýrství a Katedra informačních technologií VŠE Praha, FIS, Katedra informačních technologií Univerzita Palackého v Olomouci, PřF, Katedra informatiky ČVUT Praha, FEL, Katedra počítačů a Katedra elektrotechnologie
Objekty 2005 c Václav Snášel, editor
ISBN 80-248-0595-2
Všechna práva vyhrazena podle autorského zákona. Jakákoliv, i částečná, reprodukce či publikace pouze se souhlasem editora.
Pro sazbu a sestavení sborníku byl použit systém LATEX. Obálku navrhl Tomáš Skopal, [email protected]. Tisk a knihařské práce provedl TiskServis Jiří Pustina v Ostravě.
Vydala Fakulta elektrotechniky a informatiky, VŠB - Technická univerzita Ostrava.
Předmluva
Konference Objekty 2005 se konala ve dnech 24. - 25. listopadu 2005 v hotelu Zámeček Ostrava. Hlavním tématem letošního ročníku konference bylo „zavádění moderních technologií do praxeÿ. Je tomu tak proto, že za uplynulých deset let se objektový přístup stal důležitým stylem tvorby softwaru v praktických aplikacích nejen pro Internet, ale i v modelování a návrhu podnikových informačních systémů a mnoha dalších oblastech. Objektový přístup se kromě vlastních počítačových oborů rovněž postupně prosazuje i mimo vlastní „Computer Scienceÿ, jako je například modelování podnikových procesů a jako přístup k modelování systémů obecně. Naše konference se již stala u odborné veřejnosti známou svým neformálním přístupem k diskutované problematice a přátelskou pracovní atmosférou. Jsme také rádi, že některá témata jako například návrhové vzory, modelovací jazyk UML, business modelování či objektové a objektově relační databáze byla poprvé v českých zemích prezentována právě na naší konferenci. Obsah letošního ročníku také ukazuje, že některá témata od počátku konference zůstávají stále aktuální. Proto i letos najdete zajímavé příspěvky o objektových programovacích jazycích, databázích a teorii objektově orientovaného programování. Přejeme Vám všem příjemný pobyt v areálu VŠB-TU Ostrava a věříme, že desátý ročník celostátní konference OBJEKTY 2005 splní svůj účel a přispěje k výměně znalostí i názorů a k upevnění či navázání vzájemných kontaktů. Zvláštní díky zaslouží organizační výbor složený z pracovníků VŠB-TU Ostrava – vedle jeho předsedy Davida Ježka bych chtěl poděkovat i Vojtěchovi Merunkovi z PEF ČZU Praha za náročnou práci spojenou s evidencí příspěvků a technickou přípravou sborníku.
Za programový a organizační výbor
listopad 2005
Václav Snášel předseda programového výboru Objekty 2005
VI
Organizace
Řídící výbor Alena Buchalcevová (VŠE Praha) Vojtěch Merunka (PEF ČZU Praha) Martin Molhanec (FEL ČVUT Praha) Karel Richta (FEL ČVUT Praha) Vladimír Sklenář (PřF UP Olomouc) Václav Snášel (FEI VŠB – TU Ostrava)
Programový výbor Předseda Václav Snášel (FEI VŠB - TU Ostrava) Členové Přemysl Brada (FAV ZČU Plzeň) Antonín Carda (Deloite & Touche) Vratislav Datel (Infomedica s r.o.) Klára Hennyeyová (SPU v Nitre) David Ježek (FEI VŠB - TU Ostrava) Daniel Kardoš (Úřad vlády ČR) Jiří Kofránek (LF KU Praha) Martin Lukáš (EDS s r.o.) Vojtěch Merunka (PEF ČZU Praha) Martin Molhanec (FEL ČVUT Praha) Arnošt Motyčka (PEF MZLU Brno) Rudolf Pecinovský (Amaio Technologies, Inc.) Jiří Polák (Deloite & Touche) Karel Richta (FEL ČVUT Praha) Vladimír Sklenář (PřF UP Olomouc) Antonín Slabý (UHK) Dalibor Kačmář (Microsoft CZ) Petr Šaloun (FEI VŠB - TU Ostrava) Svatopluk Štolfa (FEI VŠB - TU Ostrava) Jan Toman (Microsoft) Jiří Vaněk (PEF ČZU Praha) Miroslav Virius (FJFI ČVUT Praha) Štefan Zajac (JČMF)
VIII
Organizační výbor David Ježek (FEI VŠB – TU Ostrava) Yveta Geleticová (FEI VŠB – TU Ostrava) Svatopluk Štolfa (FEI VŠB – TU Ostrava) Jan Kožusznik (FEI VŠB – TU Ostrava)
Místo konání: Areál VŠB – Technické univerzity Ostrava 17. listopadu 15, 708 33, Ostrava-Poruba 24. – 25. listopadu, 2005 http://www.cs.vsb.cz/objekty/2005 http://www.cs.vsb.cz/objekty
IX
Sponzoři
Konferenci Objekty 2005 částečně finančně podpořily tyto organizace:
Microsoftr Česká republika http://www.microsoft.cz
Deloitte
Deloitte. http://www.deloitte.com
Sun Microsystems CZ http://www.sun.com
Mediálním partnerem konference Objekty 2005 je:
COMPUTERWORLD http://www.computerworld.cz
X
Obsah
Zvané přednášky WWWW - How to Get Value from Processes and Systems (keynote speech) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jiří Polák
WWWW -WWWW How to– Get from Processes How Value to Get Value from Processesand and Systems Systems(keynote speech) Jiří Polák, Polák Deloitte Deloitte [email protected][email protected] Abstract: Why/What/Why/hoW is suggested approach to bring top strategies into operations by appropriate processes and systems. The core concepts are Value, Objects, and Processes. They should have a value for business, otherwise it becomes a boring cost item. The new discussion on Process/Object (and a Role) is needed to clarify their relationship and their use for putting strategies into reality.
The Motivation When working on projects, information system analysts are confronted with the problem that not all system requirements are known from the beginning. It is expected from the client that their specification and complement will be a part of a project. The whole problem is even more important since the functionality of designed systems influences the organizational and management structure of a company itself. These are for instance new or updated job positions, changes in management structure, creation of new departments, etc. It is thus necessary to take these changes into account when designing an information system. Processes and process models are indeed a method for analysis, design and implementation of organizational changes with active client support (interviews, workshops).
Fig. 1. – WWWW scheme
c Václav Snášel, editor: Objekty 2005, pp. 1–1, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Objektové jazyce Objektovéprogramování programování vvjazyce R R Ladislav VáclavNovák Novák Ladislav Beránek, Beránek, Václav Katedra informatiky, PF, –JCU Jihočeská univerzita Českých Budějovicích, Katedra informatiky, PF, JCU Jihočeská Universita, České v Budějovice, Jeronýmova 10, Jeronýmova 371 15 České Budejovice 371 10, 15 České Budějovice [email protected][email protected]
Abstrakt. Jazyk R je vývojové prostředí pro statistické zpracování dat a pro jejich grafické znázorňování. Je volně dostupný pod licencí GNU a je rozšířen zejména v komunitě pracovníků zabývajících se statistikou a v akademické sféře. Přestože se při jeho používání využívá zpravidla procedurální přístup, je jazyk R, jistě překvapivě pro většinu uživatelů, vývojová prostředí, které je objektově orientované. Příspěvek vychází z vlastních zkušeností s tímto jazykem a klade si za cíl ukázat jeho objektové rysy. Klíčová slova: objektové programování, jazyk R, zpracování dat
1
Úvod
Všechny moderní programovací jazyky dnes využívají objektově orientovaného přístupu. Také jazyk R, který je pro většinu uživatelů jen prostředím pro zpracování dat a statistické výpočty včetně grafiky, je také objektově orientované vývojové prostředí určené pro vývoj nástrojů statistického zpracování dat.
2
Jazyk R
Jazyk R je určen pro statistickou analýzu dat. Jedná se vlastně o prostředí pro zpracování dat a statistické výpočty včetně grafiky. Je odvozen od jazyka S, který byl navržen v 80tých letech v Bell Laboratories a od té doby se rozšířil zejména mezi komunitou statistiků. Prostředí obsahuje vlastní interpret jazyku R, ve kterém lze připravit jak dávkové soubory, tak definovat nové funkce. Tyto funkce mohou být interpretovány buď přímo z textové podoby souborů nazývaných R-soubory nebo z předzpracované podoby pomocí „balíčků“ (packages). Jazyk R je tedy integrovaná sada programových příslušenství pro analýzu dat a grafické znázorňování. Mezi jinými nabízí: • rozsáhlý soubor nástrojů pro statistické zpracování dat a pro grafiku, • jazyk sloužící pro vyjádření statistických modelů a jako nástroj pro lineární a nelineární statistické modely. Důležité v souvislosti s tímto příspěvkem je, že tento jazyk je efektivní objektově orientovaný a je dále rozšiřován uživatelskou komunitou, • grafické prostředky pro analýzu dat na obrazovce nebo pro tisk, • je volně dostupný pod licencí GNU na www stránkách [1] včetně “balíčků”.
c Václav Snášel, editor: Objekty 2005, pp. 2–8, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Objektové programování v jazyce R
3
Důležitou součástí jazyku R jsou dnes „balíčky“, které obsahují vždy uceleným způsobem včetně dokumentace a příkladů zpracovaný určitý obor statistických metod, nástrojů a numerické matematiky.
3 3.1
Objektové programování v R Třídy
Definice třídy obsahuje komponenty. Pojmenovaným komponentům říkáme členy. Třída v jazyce R je definována použitím setClass setClass(Class, representation, prototype, contains=character(), validity, access, where, version, sealed, package) Kde základní argumenty jsou: Class: jméno třídy (řetězec) representation: člen, který nová třída má mít nebo jiná třída, která tuto třídu rozšiřuje prototype: seznam poskytující implicitní hodnoty pro členy contains: uvádí jaké třídy tato třída rozšiřuje (ty se v některých jazycích nazývají supertřídy). Jestliže tyto třídy mají určité členy, všechny jejich členové budou obsaženy v nové třídě. where: Pro „setClass“ a „removeClass“, prostředí, v kterém bude uložena definice. Standardně na vrcholu volaných funkcí (globální prostředí pro normální výpočty, jména „balíčků“, jestliže se připojí „balíček“). Pro jiné funkce „where“ definuje, kde je možno najít definici třídy. unique: jestliže je použit pro „findClass“ očekává se unikátní řetězec pro třídu, standardně „unique“ je řetězec vysvětlující účel hledání (a je použit v varovných a chybových hláškách). Poté co jsme definovali třídu, můžeme vytvářet instance třídy pomocí new. Třída definuje strukturu objektu. Instance třídy representuje objekt samotný. Třída může být rozšířena jednou nebo více třídami. Můžeme pak hovořit o hierarchii tříd, kterou pak můžeme znázornit přímým grafem nebo stromem. Rozšířené třídy jsou považovány za rodičovské. Graf tříd musí být necyklický. Rozšířením se míní ta skutečnost, že nová třída bude obsahovat všechny členy, které mají rodičovské třídy. Příklad: setClass("fix",representation(a="character",b="numeric")) [1] "fix" > setClass("tuzka",representation(d="numeric",c="numeric")) [1] "tuzka" > setClass("penal",contains=c("fix","tuzka")) [1] "penal"
4
Ladislav Beránek, Václav Novák
> getClass("penal") Slots: Name: a b d c Class: character numeric numeric numeric Extends: "fix", "tuzka" Nyní můžeme vytvořit instanci třídy penal. Jestliže neznáme instanci třídy fix nebo tužka, můžeme vytvořit instanci penal přímo. Přístup k hodnotám členu je prostřednictvím speciálního operátoru @. Výhodnější však samozřejmě je, když nepřistupujeme k hodnotám členu přímo, ale prostřednictvím přiřazovacích metod. > x = new("penal",a="xxx",b=10,c=3) >x An object of class "penal" Slot "a": [1] "xxx" Slot "b": [1] 10 Slot "d": numeric(0) Slot "c": [1] 3 Přímý přístup pomocí operátoru @: > x@a [1] "xxx" 3.2
Inicializace a prototypování
V některých případech potřebujeme kontrolovat vytváření nových instancí třídy. V některých situacích můžeme provádět výpočty nebo jiné inicializační procesy. Můžeme použít dvou mechanismů. První je použít argument prototype příkazu setClass. Použijeme-li tento argument, můžeme pro libovolný člen zadat počáteční hodnotu. > setClass("pozdrav",representation(a="numeric",b="character"), + prototype(a=10,b="Hello world")) [1] "pozdrav" > new("pozdrav") An object of class "pozdrav" Slot "a": [1] 10 Slot "b": [1] "Hello world"
Objektové programování v jazyce R
5
Vidíme, že nové instance třídy pozdrav budou mít všechny hodnotu 10 a „Hello world“, které jsou asociované s členy a resp. b. V některých případech chceme použít obecnější přístup a potřebuje větší flexibilitu. Toho dosáhneme, definujeme-li inicializační metodu pro naši třídu: > setMethod("initialize","xx",function(.Object,b) { + .Object@b = b + .Object@a = nchar(b) + .Object + }) [1] "initialize" > new("xx",b="Ahoj") An object of class "xx" Slot "a": [1] 4 Slot "b": [1] "Ahoj" Poznamenejme, že poslední příkaz v inicializační metodě musí vracet objekt. Příkaz „initialize“ nemění hodnoty členů v argumentech, vytváří celý nový objekt, nastavuje hodnoty těchto členům a vrací nový objekt. 3.3
Virtuální třídy
Virtuální třída je třída jejíž účelem je poskytnout nějakou společnou strukturu, kterou bude sdílet více tříd. Pro virtuální třídy nejsou vytvářeny žádná instance (proto i ten název). Existují dva způsoby jak vytvořit virtuální třídu: 1. nevytvoříme žádnou representaci ve volání setClass 2. uveden příkaz VIRTUAL v definici třídy Příklad virtuální třídy v jazyce R: například „vector“ je virtuální třída: > getClass("vector") Virtual Class No Slots, prototype of class "NULL" Known Subclasses: Class "logical", directly Class "numeric", directly Class "character", directly Class "complex", directly Class "integer", directly Class "single", directly
6
Ladislav Beránek, Václav Novák
Class "double", directly Class "raw", directly Class "expression", directly Class "list", directly Class "structure", directly, with explicit coerce Class "ts", from data part Class "matrix", by class "structure", with explicit coerce Class "array", by class "structure", with explicit coerce Následující příkaz nám ukáže metodu pro tuto virtuální třídu: > getMethods("length") x = "ANY": .Primitive("length") 3.4
Generické funkce a metody
Důležitý aspekt objektově orientovaného programování je použití generických funkcí a metod. Generická funkce obsahuje specifické metody. Tyto metody jsou specializované funkce, které provedou požadovaný úkon při specifickém vstupu. Úloha generické funkce je určit, kterou z metod lze nejlépe aplikovat při specifické množině argumentů. Jakmile je proveden výběr, volá se vybraná metoda s patřičnými argumenty. Jestliže vytváříme metody, nejdříve potřebujeme určit, zda existuje generická funkce. Jestliže žádná generická funkce neexistuje, je potřeba nějakou vytvořit. Definice generické funkce je jednoduchá: > setGeneric("mujFix",function(object) standardGeneric("mujFix")) Tento příkaz definuje generickou funkci a zavádí implicitní metodu. Tato metoda je volána, pokud při volání generické funkce mujFix není nalezena jiná metoda. Ve většině případů vhodná implicitní metoda vrací např. hlášku o chybě a indikaci toho, že nebyla nalezena vhodná metoda. Jakmile máme definovánu generickou funkci, můžeme začít přidávat metody, například: > setMethod("mujFix","character", function(object) print(object)) [1] "mujFix" Tato metoda definuje pro generickou funkci mujFix metodu, která pouze vytiskne svoji hodnotu. Pokud bychom se pokusili zavola mujFix(1) objeví se chybová hláška. Metoda není definována pro typ numerického argumentu: > mujFix(1) Error in mujFix(1) : no direct or inherited method for function 'mujFix' for this call
Objektové programování v jazyce R
7
> mujFix("a") [1] "a" Volání s hodnotou „a“ je v pořádku. 3.5
Přístup k hodnotám
Členy jsou vždy dosažitelné přímo pomocí operátoru @. To však není vhodné, protože výsledný kód je závislý na aktuální reprezentaci třídy. Jestliže potom měníme tuto reprezentaci třídy, musíme všechen kód, který používá operátor @ najít a příslušně modifikovat. Proto doporučujeme pro přístup ke členům použít vhodně definované metody. Předpokládejme, že třída fix má člen pojmenovaný „a“. K vytvoření přístupové metody pro tento člen lze například postupovat takto: > setClass("fix",representation(a="ANY")) [1] "fix" > if (!isGeneric("a")) { + if (is.function("a")) + fun=a + else fun=function(object) standardGeneric("a") + setGeneric("a",fun) +} [1] "a" > setMethod("a","fix",function(object) object@a) [1] "a" > b=new("fix",a=10) > a(b) [1] 10 3.6
Polymorfismus
Potřebujeme například, aby v R operátor + působil tak, že spojí dva řetězce. Metodu bychom definovali na + takto: > setMethod("+", c("character","character"), function(e1,e2) paste(e1,e2, sep="")) Pro numerické hodnoty metoda funguje jako předtím. Výsledná funkce je polymorfní.
4
Závěr
Většinou uživatelé jazyka R používá procedurální programování tak, že mají data uloženy v proměnných, které pak různě modifikují a využívají různých nástrojů. To, že metody objektového programování jsou integrální součástí tohoto jazyka, naprostá
8
Ladislav Beránek, Václav Novák
většina uživatelů ani neví, protože dostupné manuály k tomuto jazyku se objektovému přístupu příliš nevěnují [4], [5]. Avšak při řešení komplexnějších úloh nebo při tvorbě „balíčku“ je použití objektového přístupu nutné. Výhodou objektově orientovaného přístupu je především zjednodušení a zpřehlednění návrhu. Rozdělením logických celků na třídy totiž vnáší do návrhu novou dávku abstrakce, kterou lze ocenit především u složitých návrhů a větších aplikací v souvislosti například s tvorbou „balíčku“ jazyka R. Cílem tohoto příspěvku je ukázat některé možnosti objektového programování v jazyce R, které vycházejí ze zkušeností s tímto jazykem.
Reference 1. http://www.r-project.org/. 2. Peter Dalgaard. Introductory Statistics with R. Springer, 2002. ISBN 0-38795475-9. 3. W. N. Venables and B. D. Ripley. Modern Applied Statistics with S. Fourth Edition. Springer, 2002. ISBN 0-387-95457-0. 4. Writing R Extensions, R Development Core Team, http://www.r-project.org/. 5. The R language definition, R Development Core Team, http://www.r-project.org/.
ProjektLINQ LINQ aa jazyk 3.03.0 Projekt jazykC# C# Dalibor Kačmář Dalibor Kačmář Microsoft CZ Microsoft CZ s.r.o. s.r.o. [email protected][email protected] Abstrakt. The LINQ Project is a codename for a set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations. It extends C# and Visual Basic with native language syntax for queries and provides class libraries to take advantage of these capabilities.
c Václav Snášel, editor: Objekty 2005, pp. 9–9, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Modelování podle metody BORM Modelování podle metody BORM pomocípomocí nástroje Craft.CASE nástroje Craft.CASE Vojtěch Merunka Vojtěch Merunka Katedra informačního inženýrství, PEF, PEF, ČZU Katedra informačního inženýrství, ČZU Praha Praha [email protected][email protected] Abstrakt. Příspěvek obsahuje přehled metody BORM na praktickém příkladě s využitím modelovacího nástroje Craft.CASE, který je vyvíjený firmou e-Fractal s.r.o. pro mezinárodní poradenskou a konzultační firmu Deloitte. Příklad je zaměřen na návrh organizačních a řídících struktur. Klíčová slova: CASE, Smalltalk, VisualWorks, Craft.CASE, BORM, objektově orientovaná analýza, objektová databáze, analýza požadavků na informační systém, business inženýrství.
1
Úvod
Pod objektově orientovaným přístupem si většina odborníků v IT představí především jeho přínosy do oblasti tvorby informačních systémů – tedy do oblasti analýzy a návrhu softwarových struktur a jejich následné implementace pomocí objektových programovacích jazyků a někdy také i objektových databází. V tomto příspěvku se ale budeme více zabývat jinou neméně zajímavou oblastí využití objektově orientovaného přístupu. Jde o samostatný obor, kam patří sada metod a postupů, které se používají pro získávání, evaluaci a verifikaci zadání na informační systémy. Zároveň lze zde diskutované myšlenky úspěšně použít i pro konzultační a poradenskou činnost za účelem optimalizace řídících struktur a business procesů aniž by se potom nutně musel budovat nějaký nový informační systém.
2
Metoda BORM
Metoda BORM (Business and Object Relation Modeling) je vyvíjena postupně od roku 1993. Je založen na kombinaci objektově orientovaného přístupu a procesního modelování. BORM je možné využít nejen ve tvorbě softwaru, ale i k analýze požadavků na projektovaný systém a na modelování business procesů. Práce na BORMu byla od svého počátku součástí grantu VAPPIENS (research project Various Programming Paradigms in Integrated Environments), který je součástí programu "Know How Fund of Czech Academic Link Programme of the British Council". Od roku 1996 je další vývoj podporován firmou Deloitte, kde je tato metoda používána na reálných projektech. Velká pozornost je v BORMu věnována
c Václav Snášel, editor: Objekty 2005, pp. 10–25, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Modelování podle metody BORM pomocí nástroje Craft.CASE
11
úvodním fázím projektu a postupům, jak najít objekty v zadaném problému a zkontrolovat jejich správnost. Techniky z této fáze BORMu lze používat samostatně pro modelování procesů i takových systémů, které nemají přímý vztah k tvorbě software – tedy přímo pro účely organizačního poradenství. Objektové modely BORMu zde slouží k nalezení slabin ve stávající organizaci a procesech a k návrhu změn, které by tyto nedostatky odstranily. 2.1
Vývoj pojmu objekt během projektování podle BORMu
Samotný pojem objektu včetně jeho vlastností se v jednotlivých fázích projektu podle zásad BORMu mění. Jinak chápe objekt programátor při implementaci v nějakém konkrétním programovacím jazyce a jinak chápe objekt zadavatel, protože pro něj je objekt zobrazením nějaké entity reálného světa, která je v okruhu jeho zájmu při formulaci zadání. Každý následující pojem má svého abstraktnějšího předchůdce, ze kterého byl odvozen. Tyto transformace jednotlivých pojmů mezi sebou jsou obsahem jednotlivých technik v různých fázích tvorby informačního systému. V průběhu modelování nelze libovolně přidávat nebo měnit prvky modelu, protože každá změna musí být vždy konzistentní a zdůvodnitelná s odpovídajícím předchozím stavem modelu. BORM rozděluje objektové modely na tři hlavní skupiny: 1.
Softwarové objekty, se kterými se pracuje v závěrečných fázích vývoje IS za účelem softwarové implementace. Tyto objekty obsahují pojmy přímo odpovídající konstrukcím z objektových programovacích jazyků a nebo standardu UML.
2.
Konceptuální objekty, se kterými se pracuje v prostředních fázích vývoje IS. Tyto objekty obsahují základní pojmy objektově orientovaného paradigmatu, jako například polymorfismus objektů, zapouzdření, skládání, delegování, klasifikace objektů podle různých dimenzí, závislost objektů, třídy a množiny objektů atd. Je pravda, že mnohé z konceptuálních pojmů jsou shodné se softwarovými pojmy, ale značnou část z nich je třeba při přechodu na softwarové objekty transformovat, protože současné používané programovací jazyky podporují pojmy OOP pouze omezeným způsobem. Zhruba řečeno je rozdíl mezi konceptuálními a softwarovými objekty závislý na použitém programovacím prostředí a je proto např. v případě C++ větší, než při použití Smalltalku. Smyslem tvorby modelu s konceptuálními objekty je snaha mít implementačně nezávislou ale dostatečně podrobnou dokumentaci softwarového řešení, která by byla použitelná i pro inovace systému po změně technologie. To by nebylo možné, kdyby se modelovalo jen podle možností aktuálního programovacího prostředí.
3.
Objekty reálného světa, (anglicky jako „business objects“). Tyto objekty vyplňují mezeru mezi zadáním - tj. chápáním na aplikační úrovni zadavatele
12
Vojtěch Merunka
a mezi konceptuálním objektovým modelem. Business analýza BORMu se používá k modelování požadavků na informační systém. Objekty reálného světa podporují pouze vybrané pojmy OOP a většinu pojmů ponechávají na pozdějších transformacích. Podrobnější výklad BORMu přesahuje možnosti tohoto článku, ale můžeme čtenáře odkázat na domácí [3, 10, 11] nebo zahraniční [6, 12] literaturu.
3
Craft.CASE
Craft.CASE® je původní český modelovací a analytický CASE nástroj podporující metodu BORM®. Nástroj vzniká ve firmě e-Fractal s.r.o. na zakázku pro mezinárodní poradenskou a konzultační firmu Deloitte (uživatele a spolutvůrce BORMu). Vedoucí vývoje ve firmě e-Fractal s.r.o. jsou Ing. Ladislav Lenárt a Ing. Petr Skála. Ve firmě Deloitte je hlavním zadavatelem Ing. Jiří Polák, CSc. a analytikem projektu je autor tohoto článku. Program je napsán v prostředí VisualWorks/Smalltalk a je určen pro použití ve Windows 2000 a XP. Jsou ale také podporovány platformy MacOS a Linux. Zadání vychází ze dvou potřeb: 1) Jednoduše ovladatelný a na prostředky počítače nenáročný program. 2) Modelovací nástroj přesně šitý na míru metodě BORM, také částečně konfigurovatelný, který dokáže procesy simulovat a generuje výstupní dokumentaci. Craft.CASE verze 1.3 podporuje business analýzu, což je úvodní fáze metody BORM, a konceptuální analýzu. V obou fázích analýzy se rozpoznává a modeluje zadání pro systém na základě objektového modelování business procesů. Craft.CASE během modelování kontroluje úplnost a správnost modelu pomocí informací uložených v projektové databázi. V době psaní tohoto článku byly již ohlasy na jeho použití v projektech modelování procesů velké firmy. S pomocí Craft.CASE byl také zahájen projekt tvorby nové verze interní referenční příručky organizace a procesů telekomunikačních firem. Uživatelé kladně hodnotí nenáročnost programu, originalitu a jednoduchost obsluhy. Na druhou stranu je třeba přiznat, že někteří z nich mají problémy s jeho grafickým rozhraním. Je tomu tak proto, že VisualWorks je jednotné vývojové prostředí, ve kterém lze programovat aplikace nejen pro Windows, ale i pro Unix a MacOS. Proto chování některých grafické komponent není identické s tím, jak vypadají a fungují produkty Microsoftu. 3.1
Metamodel Craft.CASE
Všechny druhy diagramů, jejich elementů i dalších dat v Craft.CASE jsou navrženy podle jednotného metamodelu. Prvky všech modelů jsou nazývány „nodes“ (uzly) a
Modelování podle metody BORM pomocí nástroje Craft.CASE
13
vazby mezi nimi „connections“ (spojení). Každý uzel i spojení může mít různé proměnné. Uzly jsou například třídy objektů a spojení jsou například vazby skládání a dědění mezi třídami. Nebo podle jiného příkladu uzly jsou aktivity objektů a spojení jsou komunikace mezi aktivitami. Craft.CASE při vytváření modelů dodržuje pravidla konkrétních uzlů a spojení a dovoluje modelovat jen takové údaje, které jsou pro příslušný typ uzlu a vazby přípustná. Kromě toho Craft.CASE obsahuje nástroj pro kontrolu konzistence a správnosti modelů, který hierarchickou formou zobrazuje nalezené nedostatky. Pro každou nalezenou chybu se zobrazí rada, jak ji lze napravit a dále vlastnosti prvku s nalezenou chybou. Pomocí menu pravého tlačítka myši lze lokalizovat nalezenou chybu přímo v diagramu. (viz. obr. 14) Diagramy lze kopírovat. Rovněž tak je možné kopírovat a vkládat objekty mezi diagramy. Každý prvek (uzel i spojení) v databázi projektu má zajištěnou identitu nezávisle na hodnotách jeho atributů. Díky tomuto mechanismu, který je převzat z objektových databází, je možné mít například v jednom modelu dva různé objekty se stejným jménem nebo mít přehled o objektech, u kterých není ještě vyplněné jméno nebo ani ještě nejsou zakresleny v žádném diagramu. Skupiny některých objektů (například aktivit v procesním diagramu) lze nahrazovat jediným objektem. Po takové transformaci diagramu jsou všechny vazby s okolím nahrazených původních objektů automaticky přepojeny na nový objekt. 3.2
Výstupy z projektové databáze
Craft.CASE umožňuje uložit strukturu projektové databáze do XML souboru. V tomto souboru je úplná informace o všech objektech a vazbách. Tyto údaje jsou využitelné ke tvorbě generátorů různých dalších výstupů, zdrojových kódů programovacích jazyků a nebo souborů pro přenos dat do jiných modelovacích nástrojů. Tento přístup byl zvolen záměrně. Cílem je otevřenost a rozšiřitelnost našeho nástroje. Formát výstupních dat je zveřejněn a jsou také k dispozici zdrojové kódy ukládaných objektů do XML. Druhou možností je export celého obsahu interní objektové databáze do soustavy relačních tabulek ve formátu CSV. Kromě výpisu obsahu projektové databáze je možné využívat řadu předpřipravených výstupů v podobě seznamů a tabulek ve formátech HTML a PDF.
4
Praktický příklad modelovaní v Craft.CASE
Jak bylo řečeno v předcházejících kapitolách, Craft.CASE slouží nejen pro potřeby softwarového inženýrství, ale i pro modelování business procesů a organizační struktury. Na tomto místě bude proto uveden jednoduchý příklad smyšlené firmy, ve
14
Vojtěch Merunka
které je třeba provést analýzu informačního systému pro registraci faktur, který bude spolupracovat s již existujícím finančním systémem pro platby.
Obr. 1. – základní spouštěcí okno přepnuté do fáze business modelování
Pro potřeby projektu bude také potřeba zachytit model ICT architektury celé firmy a dále i organizační model celého podniku. Oba tyto pohledy na podnik musí být svázány s architekturou procesů, z nich jedním z nich bude právě proces popisující oběh faktury firmou. 4.1
Nastavení nástroje pro business modelování
Business modelování je první fází BORMu. Tato fáze spočívá v rozpoznání a modelování problému. Zde se analyzuje celý kontext modelovaného systému – především objekty a procesy v organizaci, pro kterou se systém analyzuje. Ve složitějších případech je třeba sestavit dvě sady modelů. První z nich je tzv. AS-IS model, který zobrazuje stávající stav a po jeho dokončení následuje tzv. TO-BE stav, který zobrazuje novou strukturu objektů a procesů po implementaci systému. Po nastartování nástroje je nejprve třeba nastavit možnosti vazeb a atributů business objektů. Toto nastavení lze uložit ve formě znovupoužitelné šablonky. Na obrázku 2 je příklad takového nastavení pro role participantů v procesech, které budeme modelovat.
Obr. 2. – nastavení parametrů pro modelované pojmy
Modelování podle metody BORM pomocí nástroje Craft.CASE
15
Dalším přípravným krokem je vytvořená pomocných hierarchií, které budeme potřebovat pro zachycení organizační struktury naší firmy a architektury ICT. Pro prvky těchto hierarchií je také možné nastavit parametry shodným způsobem jako na obr. 2.
Obr. 3. – organizační struktura a ICT architektura
Obr. 4. – propojení prvků hierarchií mezi sebou
Pomocné hierarchie jsou prostředek, jak zaznamenat vícedimenzionální informaci. V našem příkladě máme vytvořeny dvě takové hierarchie, které se typicky používají i v praktických projektech. Kromě nich si lze představit ještě například hierarchii zákaznických služeb, a pro formulaci business strategie firmy ještě třeba hierarchii podnikových cílů, ohrožení, kritických faktorů atp.
16
Vojtěch Merunka
Atributy prvků hierarchií lze uživatelsky nastavovat zcela shodným způsobem jako ostatní prvky modelu. Na našem příkladě na obrázku 3 je například vidět barevné rozlišení organizačních jednotek, kde v editoru označený prvek „Firma Z“ má barevně odlišený typ „přidružená firma“. Prvky různých hierarchií lze propojovat mezi sebou a tak vytvářet zobrazení mezi nimi. V horní části obrázku 4 jsou dvě taková propojení. Jedno z nich, které je pojmenované „finanční informační systém“, ukazuje, že je tvořeno prvky „MS SQL Server“, „síť MS Windows“ a „Účto“ z hierarchie ICT architektury s prvky „Oddělení ICT“ a „Závod A“ z hierarchie organizační struktury. Další možností je propojení mezi prvky hierarchií a ostatními pojmy business fáze modelování. Na obrázku 4 je vidět, že prvky z hierarchie ICT architektury lze dekomponovat na participanty. Prakticky to znamená, že z modelu ICT architektury lze přecházet na participanty procesů, které se pod příslušnými prvky ICT architektury skrývají. 4.2
Funkce business modelu, architektura business modelu
Nyní lze již přikročit k podrobnému business modelování podle zásad BORMu. Procesy na nejvyšší úrovni abstrakce se nazývají „funkce systému“ a lze je interpretovat jako procesní funkční oblasti. Na ukázce na obr. 5 je seznam obsahující čtyři takové oblasti.
Obr. 5. – funkce systému
Každá funkční oblast obsahuje jednotlivé procesy, které jsou popisovány procesními scénáři (podrobněji v následující kapitole 4.3). Pojem scénáře v BORMu do značné míry odpovídá pojmu „use-case“ z UML. Vztahy mezi scénáři lze shodně jako v UML zobrazovat pomocí diagramů, které se nazývají „business architektura“. Ikonka u scénáře „oběh faktury firmou“ na obrázku 6 znamená, že se pod tímto scénářem skrývá procesní diagram.
Modelování podle metody BORM pomocí nástroje Craft.CASE
17
Obr. 6. – business architektura
4.3
Scénáře a participanti business modelu
Každý scénář obsahuje popis činností, které lze ještě podrobně zobrazit procesním diagramem. Součástí každého scénáře je popis toho, jak jeho proces začíná, probíhá a končí a dále také participanty – objekty, které se procesu ve scénáři účastní. U participantů lze nastavovat jejich různé role v modelovaném procesu.
Obr. 7. – participanti a scénáře procesů
18
Vojtěch Merunka
Obr. 8. – role participantů v scénáři
4.4
Diagram business procesu
Tento původní diagram BORMu současně zobrazuje jak stavové diagramy každého z objektů - účastníků procesu ve scénáři, tak i jejich vzájemnou interakci v různých stavech včetně datových toků, které si při této interakci mohou odehrávat. Stavový diagram participanta zobrazuje jeho roli v procesu. Druhý pohled je sled komunikací mezi aktivitami (činnostmi) různých objektů v různých stavech, což zobrazuje vlastní průběh procesu. Na proces je nahlíženo jako na spojení vzájemně komunikujících automatů. Na komunikacích mezi objekty lze také vyznačovat datové toky (malé šipky).
Obr. 9. – procesní diagram procesu zpracování faktury
Modelování podle metody BORM pomocí nástroje Craft.CASE
4.5
19
Simulace procesu
Business procesy je možné simulovat. Díky grafickému simulátoru lze názorným způsobem objasnit principy objektového přístupu i těm účastníkům projektu, kteří nemají žádné programátorské zkušenosti. Toto je velmi cenný přínos, protože právě jejich znalosti problému a názor na navrhované řešení jsou kriticky důležité pro podobu budoucího systému. Simulace je tak velmi vhodným nástrojem k ověřování správnosti a přesnosti modelu.
Obr. 10. – Krokování procesu v simulátoru
Dokončenou simulaci lze vyhodnocovat. Na obrázku 11 jsou posloupnosti provedených událostí z pohledu různých účastníků procesu.
Obr. 11. – simulační záznamy
20
5
Vojtěch Merunka
Konceptuální analýza
Konceptuální analýza je postavena na upraveném standardu UML. Slouží jako spojovací článek mezi business modelem a softwarovým řešením. Podle BORMu jde o postupnou transformaci objektů a vazeb do podoby popisující softwarové řešení. Tato transformace podléhá určitým pravidlům, která Craft.CASE podporuje. Konceptuální modelování v Craft.CASE je velmi podobné klasickým nástrojům CASE používajícími jazyk UML. Odlišnosti spočívají ve dvou věcech: •
Pojmy v jazyce UML v této fázi modelování vycházejí z pojmů modelovaných v předchozí fázi. Craft.CASE tento vztah podporuje a kontroluje.
•
Jazyk UML je zjednodušen, ale na druhou stranu také doplněn o některé nové prvky. To vše za účelem podpory objektově orientovaného konceptuálního modelování více nezávislého na implementačních prostředích smíšených programovacích jazyků (např. C++). Originální UML je totiž s těmito jazyky příliš těsně svázán. To nejen zbytečně komplikuje analýzu, ale také nedává dostatek výrazových prostředků pro implementaci v čistě objektově orientovaných prostředích a především objektových databázích.
Obr. 12. – základní spouštěcí okno přepnuté do fáze konceptuálního modelování
5.1
Přechod z business modelování do konceptuálního modelování
Před začátkem konceptuálního modelování je potřeba nejprve naplnit projektovou databázi. Na obrázku 13 je pohled do databáze tříd objektů.
Obr. 13. – databáze tříd konceptuálních objektů
Modelování podle metody BORM pomocí nástroje Craft.CASE
21
U každého pojmu je potřeba vyznačit tzv. „business origin“, tedy informaci, jak daný konceptuální pojem souvisí s dříve zadanou informací v business modelu. Pro kontrolu konzistence (a samozřejmě i pro jiné kontroly formální správnosti všech modelů v Craft.CASE) slouží nástroj, který dokáže chybu lokalizovat a naznačuje i způsob nápravy. Příklad rozpoznané chyby je na obrázku 14.
Obr. 14. – nástroj pro kontrolu správnosti
5.2
Konceptuální modely
Konceptuální objekty lze potom používat v diagramech. Na ukázce je diagram tříd konceptuálních objektů.
Obr. 15. – diagram tříd
22
6
Vojtěch Merunka
Výstupní dokumentace
Projekt lze uložit nejen v nativním formátu Craft.CASE, ale také ve formátu XML a nebo CSV, což je sada souborů v textovém formátu obsahujících vzájemně propojené relační tabulky. Ve fázi konceptuálního návrhu je možné generovat kód. Současná verze obsahuje generátor zdrojového kódu pro databázi Gemstone a pro jazyk Smalltalk. Informaci z business modelování je také možné zpracovávat ve formě reportů. Jde o dokumentaci ve formátu HTML a nebo PDF, která se skládá z řady různých seznamů a tabulek obsahujících informace vypočítané z projektové databáze.
Obr. 16. – Generování druhu a rozsahu reportu
6.1
Modelové karty
Velmi populárním druhem reportu pro potřeby manažerské dokumentace jsou takzvané modelové karty. Modelová karta je tabulka, která se generuje pro každý participant, a obsahuje všechny vazby a činnosti, které daný objekt má ve scénářích procesů a diagramech procesů. Na obrázku 17 jsou karty, které na řádcích obsahují aktivity objektů a na sloupcích jsou spolupracující objekty. Průniky řádků a sloupců potom ukazují, zda daná činnost potřebuje spolupráci příslušného objektu. V praxi takové karty slouží například jako podklad pro dokumentaci obsahující popisy pracovních činností.
Modelování podle metody BORM pomocí nástroje Craft.CASE
23
Obr. 17. – Modelové karty (z reportu ve formátu PDF)
7
Implementace Craft.CASE
Craft.CASE je programován v prostředí VisualWorks v programovacím jazyce Smalltalk. V našich i evropských podmínkách tedy jde o velmi netradiční způsob implementace. S výjimkou podobného finského projektu Metaedit, který je také programován v prostředí VisualWorks/Smalltalk, jsou ostatní CASE nástroje programovány především v jazyce C++. Obecně rozšířený názor na programování aplikací podobných naší je ten, že je potřeba použít jazyk pokud možno nižší úrovně a proto rozhodně ne čistě objektově orientovaný jazyk Smalltalk. Tento názor vychází z přesvědčení, že abstraktnější jazyky nedokáží dostatečně efektivně zvládnout sestavení grafického editoru a obsluhu interní projektové databáze. Naše zkušenosti však prokázaly něco jiného. První verze Craft.CASE se vyvíjela od konce roku 2004 přibližně osm měsíců včetně analýzy a testování. Průměrný počet vývojářů i analytiků po tuto dobu byl asi 1.5 člověka na den. To dohromady znamená odhadem pouze 12 člověkoměsíců. V případě použití jazyka nižší úrovně by to bylo jistě podstatně více. Problémy nebyly ani s výkonností. Využili jsme knihovny pro dvojrozměrnou grafiku, práci s XML formátem a binární ukládání objektů na disk standardně dodávaných v prostředí VisualWorks. Přestože všechny tyto knihovny jsou napsané jen ve Smalltalku, tak jsme nenarazili na žádné problémy s výkonem.
24
Vojtěch Merunka
Pro zajímavost budiž uvedena ještě jedna pozoruhodnost; Craft.CASE je vytvářen v duchu zásad agilních metodik na platformě PC/Linux. Tam je postupně sestavován a testován. Základní uživatelskou platformou je ale PC/Windows XP. Díky vlastnostem prostředí VisualWorks je tvorba instalace ostré verze pro Windows a nebo MacOS z programu ve vývojovém prostředí na Linuxu otázkou několika desítek sekund.
8
Závěr
V blízké budoucnosti – s největší pravděpodobností v lednu 2006 – se předpokládá zásadní změna Craft.CASE pod označením 2.0. Předpokládáme kromě drobných vylepšení následující podstatná rozšíření a změny: 1.
2.
3.
4. 5.
Programovatelné rozhraní využívající zjednodušený Smalltalk. Pomocí tohoto rozhraní bude možné programovat refaktoringové operace nad modelem a práci s návrhovými vzory jako uživatelsky definovatelná „makra“. Doplnění nástroje o volné kreslení a nestrukturovaný záznam požadavků, který bude východiskem pro formulaci prvků hierarchií, business funkcí, scénářů a participantů. Víceuživatelský režim, který umožní pracovat na jednom projektu z více počítačů současně napojených na sdílený repozitář projektů implementovaný jako aplikace v objektovém databázovém systému Gemstone/S. [7] Přidání fáze softwarového návrhu pro různá implementační prostředí. Vylepšený procesní simulátor zahrnující prvky what-if analýzy a různých optimalizací.
Projekt Craft.CASE je pro náš tým zajímavou a originální zkušeností. Samozřejmě, že námi zvolený přístup nemá jen samé výhody. Největším problémem, který nás tíží, je právě originalita řešení i použitého vývojového prostředí. Každý člen našeho malého týmu je v podstatě nezastupitelný, což představuje nezanedbatelnou míru rizika. Nástroj je zdarma nabízen českým a slovenským vysokým školám k výuce. Na naší fakultě jej studenti poprvé používali v letním semestru 2004/2005 ve výuce objektových databází a projektování informačních systémů. Používá jej rovněž několik diplomantů na FEL ČVUT i PEF ČZU, kteří se s ním naučili pracovat sami. Projekt Craft.CASE je praktickým příkladem toho, že i v „neobvyklých“ programovacích jazycích lze udělat použitelný software. To jako učitel velmi oceňuji: Díky tomuto nástroji mají studenti možnost vidět, že principy čistého objektového programování a nerelačních objektových databází, které je učíme, jsou prakticky užitečné. Tento článek se týká obsahu výzkumného projektu Ministerstva školství, mládeže a tělovýchovy České republiky číslo MSM 6046070904.
Modelování podle metody BORM pomocí nástroje Craft.CASE
25
Reference 1. Brechlerová Dagmar, Merunka Vojtěch: Our Experiences with Developing Software Systems, 9th International Conference of European University Information Systems - EUNIS 2003 University van Amsterdam, Amsterdam, 2003 ISBN 90-9017079-0 2. Buchalcevová A.: Agilní metodiky, sborník konference OBJEKTY 2002, ČZU Praha, ISBN 80-213-0947-4 3. Carda A., Merunka V., Polák J.: Umění systémového návrhu - objektově orientovaná tvorba informačních systémů pomocí původní metody BORM. Grada, Praha 2003. ISBN 80-247-0424-2. 4. Garcia L. Rivas, Merunka Vojtěch, Polák Jiří: BORM - Business and Object relation Modeling In: Proceedings of WOON - 6th international conference on object technology Institute of Electrotechnology St. Petersburg, 2001, ISBN 8088786-8 5. Lacko B.: Vademekum objektově orientované technologie, sborník konference Programování, Ostrava 1993. 6. Liping Liu, Borislav Roussev, Knott Roger et al.; Management of the ObjectOriented Development Process - Part 15: BORM Methodology, Acron Publishing, ISBN 1-59140-605-6 7. Merunka V.: Objektový databázový systém Gemstone, sborník konference OBJEKTY 2003. Ostrava 2003. ISBN 80-248-0274-0 8. Merunka Vojtěch, Objektově orientovaná analýza informačních systémů In: Professional Computing, DCD Computing Praha, 2005, ISSN 1213-1180 9. Merunka Vojtěch, Objektový přístup v databázových systémech, ČZU Praha, 2002, ISBN 80-213-0882-6 10. Merunka Vojtěch, Pergl Robert, Pícka Marek, Objektově orientovaná tvorba softwaru, ČZU Praha, 2004, ISBN 80-213-1159-2 11. Merunka Vojtěch, Pergl Robert, Pícka Marek: Objektově orientovaný přístup v projektování informačních systémů, ČZU Praha 2005, ISBN 80-213-1352-8 12. Merunka Vojtěch, Polák Jiří, Knott Roger: Process Modeling for Object-Oriented Analysis Using BORM Behavioral Analysis In: Proceedings of Fourth International Conference on Requirement Engineering - ICRE 2000, IEEE Computer Society, Chicago 2000, ISBN 0-7695-0565-1 13. Molhanec M.: Kritika některých chápání objektově orientovaného paradigmatu, Sborník 30. ročníku konference Tvorba softwaru, Ostrava 2004 14. Virius M., Merunka V., Unifikovaný modelovací jazyk UML I., II. a III., série tří článků, Chip Vogel Publishing Praha 2002, ISSN 1210-0684 15. webová stránka http://www.craftcase.com, týkající se nástroje Craft.CASE. This paper contains an overview of the method BORM (Business and Object Relation Modeling) and a practical example with the analytical and modeling tool Craft.CASE, which is developed by the e-Fractal Ltd. for international consulting company Deloitte.
Začlenění návrhových vzorů do výuky programování Začlenění návrhových vzorů do výuky programování Rudolf Pecinovský Rudolf Pecinovský1 Amaio Technologies Inc. Amaio Technologies Inc., 100 00 Praha 10, Třebohostická 14 Třebohostická 14, 100 00 Praha 10 [email protected][email protected]
1
Abstrakt. Příspěvek nejprve stručně seznamuje se šesti hlavními současnými přístupy k výuce základů programování. Poté se soustředí na přístup, při němž celá výuka začíná prací s objekty a důslednou aplikací zásad OOP. Kritizuje polovičatost doposud publikovaných učebních textů a naznačuje, jak je možno deklarované zásady aplikovat důsledněji. V druhé, klíčové části příspěvku ukazuje na konkrétních příkladech, jak lze postupovat při výuce, při které se od počátku učí doopravdy objektově orientované programování a předvádí, jak je možno prakticky od prvních hodin začlenit do výuky programování seznámení s návrhovými vzory a možnostmi jejich použití. V třetí části srovnává dva přístupy k zadání zkušebního příkladu: klasický, s nímž se můžeme setkat v řadě učebnic a kurzů, a skutečně objektově orientovaný. Ukazuje, že opravdu objektový přístup je výhodnější jak pro studenty, tak pro vyučujícího. V poslední, čtvrté části pak zmiňuje návrhové vzory, které by si také zasloužily zařazení do vstupních kurzů, avšak v předchozím textu na ně nedošlo, a přidává pár otevřených otázek. Klíčová slova: OOP, návrhové vzory, výuka programování, vstupní kurzy programování, přístup „nejdříve objekty“, přístup „object first“
1
Úvod
Stejně jako jiné oblasti činnosti, i programování se neustále vyvíjí. Bohužel, metodika výuky programování nesleduje tyto trendy vždy dostatečně dobře a většinou se za nimi výrazně opožďuje. Učitelé proto často připravují žáky na styl programování, který byl progresivní před 15 až 25 lety, ale v současné době je již dávno překonaný. O to překonanější bude v době, kdy budou jejich studenti vstupovat do praxe. 1.1
Přehled používaných přístupů k výuce
V současné době se na různých místech učí programování podle různých metodik, které jsou rozdělovány do následujících šesti skupin: Nejdříve hardware (Hardware-first) Zastánci tohoto přístupu tvrdí, že k tomu, aby studenti dokázali správně programovat, musí nejprve vědět, jak je počítač konstruován, protože jedině tak si mohou představit, jak bude jejich program prováděn. Výuka začíná výkladem spínacích obvodů, konstrukcí registrů a aritmetických jednotek, a teprve poté pokračuje výkladem konstrukce programů ve strojovém kódu a následně ve vyšších programovacích jazycích.
c Václav Snášel, editor: Objekty 2005, pp. 26–41, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Začlenění návrhových vzorů do výuky programování
27
Tato koncepce se uplatní pouze v několika speciálních oborech, protože většinou, zejména pak při tvorbě rozsáhlých aplikací, je považováno za optimální, je-li programátor od realizačního hardwaru co nejvíce odstíněn. Nejdříve algoritmy (Algorithms-first) Tento přístup nevyužívá k výkladu některého z existujících jazyků, ale vykládá základní algoritmy za použití pseudokódu. Studenti se nejprve učí základní principy, aniž by se zdržovali laděním nějakých programů. Zkušenost však ukazuje, že právě absence této zpětné vazby a nemožnost si vše vyzkoušet je pro studenty demotivující. Nejdříve příkazy (Imperative-first) Klasická, a jak odhaduji u nás stále nejpoužívanější metodika výuky. Při ní se studenti nejprve seznámí s klasickými programovými konstrukcemi a teprve pak s případnou objektově orientovanou nadstavbou. Zkušenost však ukazuje, že takto připravovaní studenti se nesžijí s objektově orientovaným paradigmatem tak dobře, jako studenti, kteří začali výuku hned prací s objekty, což je vzhledem k současnému významu OOP považováno za velký handicap tohoto přístupu. Jednou z velkých nevýhod takto koncipovaných kurzů je pak to, že se jedná především o kurzy syntaxe a nikoliv o kurzy programování. Vyučující přednáší a cvičí tak, jakoby předpokládali, že umění programovat přijde se znalostí syntaxe jako vedlejší efekt. Nepřijde. Nejdříve funkce (Functional-first) Tento přístup zavedli v osmdesátých letech v MIT. Jeho výhodou je sjednocení počáteční úrovně studentů, protože se zde setkají s jazykem, jehož filozofie je výrazně jiná než filozofie jazyků hlavního proudu. Tato odlišnost ale na druhou stranu mnohé ze studentů demotivuje, protože se nechtějí učit něco, co pak ve své praxi přímo nepoužijí. Nejdříve objekty (Objects-first) Tato koncepce vychází ze skutečnosti, že OOP je zdaleka nejpoužívanější metodikou programování a mají-li si je studenti opravdu osvojit, musí se s ním setkávat od samého počátku výuky. Nevýhodou tohoto přístupu je, že objektově orientované jazyky bývají koncipovány jako komplexní a studenti si pak někdy připadají jejich složitostí zcela zahlceni. Je přitom jedno, zda jde o složitost vlastního jazyka, jak je tomu např. v případě jazyka C++, nebo o složitost standardní knihovny, jak je tomu v případě jazyka Java. Kurzy je proto třeba koncipovat tak, aby k tomuto zahlcení nedošlo. Nejdříve zeširoka (Breadth-first) Zastánci této koncepce tvrdí, že by se studenti měli nejprve seznámit s problematikou počítačové vědy v co největší šířce, a teprve pak se soustředit na takové detaily, jakým je např. programování. Studenti prošedší takovýmito kurzy přistupují k řešení problémů z většího nadhledu a jsou jej často schopni chápat v celé jeho šíři. Kritici však této koncepci vytýkají, že odkládá výuku programování a tím i na ni navazující předměty o jeden až dva semestry, což není vždy vyváženo lepšími výchozími znalostmi studentů.
Objektově orientované programování je hlavním proudem v programování již téměř 20 let. Přibližně stejně staré jsou i první práce, které ukazovaly, že výuka, při níž se výuka práce s objekty probírá až v závěru kurzu, nepřináší zdaleka tak dobré výsledky jako výuka, při které výuky prací s objekty naopak začíná. Postupně se proto rozšiřují řady vyučujících, kteří se snaží koncipovat svoji výuku tak, aby se jejich žáci na počátku výuky s objekty nejenom seznámili, ale aby s nimi od samého začátku výuky také pracovali. Typickým, a pravděpodobně také nejznámějším představitelem výukového textu připraveného pro tento typ výuky je [1]. Přiznejme si však, že i tato kniha řeší problém pouze částečně. Žáci sice od samého začátku pracují s objekty a navrhují programy, v nichž se učí definovat třídy tak, aby byly jednoduché, kompaktní a minimálně provázané, ale zůstávají pouze u definice jednoduchých tříd. S existencí rozhraní se seznámí až v závěru kurzu a navíc jsou zde rozhraní prezentována do jisté míry jako náhražka násobné dědičnosti. O návrhových vzorech, které jsou považovány za jeden z pilířů současného programování, nepadne ani slovo. Stejně tak autoři nijak explicitně nezdůrazňují základní pravidlo, že programovat se má proti rozhraní tříd a ne proti jejich implementaci. Pak by totiž museli rozhraní jako druh datového typu prezentovat zcela jinak a především daleko dříve. V [1] i v nejrůznějších dalších „Object-First kurzech“ však bývá opominuta řada neméně důležitých zásad, které by bylo třeba žákům vštěpovat již od samého začátku výuky. Řada těchto zásad je poměrně pregnantně vysvětlena např. v [4], avšak tato učebnice předpokládá, že čtenář již prošel základním kurzem jazyka Java. Při jejím pročítání si však bystrý čtenář musí uvědomit, že výklad řady z vysvětlovaných zásad již mohl a měl být součástí vstupního kurzu programování. 1.3
Snahy o zavedení návrhových vzorů do výuky – killer examples
Základním problémem současné metodiky (alespoň jak jej mnozí cítí) je nedostatek názorných příkladů, na kterých by bylo možno již v začátečnických kurzech demonstrovat současné trendy a především pak použití návrhových vzorů. Na přelomu století se proto skupina vysokoškolských učitelů dohodla, že budou pořádat pravidelné semináře nazvané „Killer Examples“ for Design Patterns and Objects First, na kterých se pokusí představit tzv. „killer examples“, což by měly být právě příklady, které jsou na jednu stranu dostatečně jednouché, aby je bylo možno použít i ve vstupních kurzech programování, avšak na druhou stranu budou dostatečně „složité“, aby se na nich dalo přirozeně demonstrovat použití návrhových vzorů. Když jsem procházel příklady prezentovanými na těchto seminářích, připadala mi většina z nich pro vstupní kurzy s minimální hodinovou dotací stále příliš (možná bych mohl říci zbytečně) složitá. Zdá se mi, že ani po těch čtyřech letech, po něž se tyto semináře konají, se nepodařilo vymyslet ty správné „killer examples“ (zatím mne nenapadl ten správný český překlad). Ve svém příspěvku bych se proto pokusil předvést několik příkladů, které možná nebudou oněmi pravými „killer examples“, ale alespoň demonstrují, že návrhové vzory a takové principy, jako programování proti rozhraní a další, lze aplikovat i při řeše-
Začlenění návrhových vzorů do výuky programování
29
ní velice jednoduchých příkladů, které lze studentům vstupních kurzů programování předložit již na prvních cvičeních.
2 2.1
Návrhové vzory použité na samém počátku výuky Rozdílná vstupní úroveň studentů
Jedním z problémů počátečních hodin výuky je rozdílná úroveň studentů. Někteří z nich se s programováním setkávají poprvé, jiní již mají za sebou řadu programů. Drobnou výhodou je, že převážná většina těch, kteří se považují za zkušené programátory, má zkušenosti pouze se strukturovaným programováním, protože objektově orientované programování se většinou na středních školách ani v zájmových kroužcích neučí. Pokud na ně tedy včas „vybafneme“ s dostatečně objektovými příklady, máme šanci relativní vstupní úroveň studentů ve vztahu k probírané látce částečně sjednotit. Nutnost onoho „včasného vybafnutí“ je o to větší, že v opačném případě se studenti s předchozími neobjektovými programátorskými zkušenostmi v prvních hodinách často snaží znevažovat některé předváděné postupy, protože je ze své zkušenosti dokáží naprogramovat zdánlivě jednodušeji či efektivněji. Neuvědomují si však, že OOP vyžaduje přece jenom poněkud odlišný styl řešení problémů, a že to, co se nenaučí na jednoduchých příkladech, jim bude chybět při řešení příkladů složitějších. O tom, jak se programátoři s předchozími neobjektovými zkušenostmi pokouší interpretovat přednášenou látku za pomoci svých dosavadních znalostí, jsem již hovořil v [8], [9] a [11]. V kurzech profesionálních programátorů jsem si ověřil, jak důležité je těmto programátorům co nejdříve „podříznout větev“ jejich dosavadních znalostí, na které „sedí“, a co nejdříve jim předložit příklady, na něž jejich dosavadní znalosti nestačí. Obdobný postup lze aplikovat i na studenty středních a vysokých škol. 2.2
Testovací třída
Na první hodině/cvičení se studenti většinou teprve seznamují s objekty a třídami, s vývojovým prostředím, které budou po zbytek kurzu používat. Prohlédnou si strukturu nějakého předem připraveného programu a ujasní si vzájemné závislosti a interakce jednotlivých tříd a jejich instancí. Protože je program předem připravený, nemusí být triviálně jednoduchý (alespoň z jejich pohledu). Při té příležitosti si studenti ujasní, že vše, co v programu vystupuje, je objekt, včetně toho, co by v běžném životě za objekt nepovažovali – např. vlastnosti jako je barva nebo směr. Používáme-li vhodné interaktivní prostředí, jakým je např. stále populárnější prostředí BlueJ, mohou studenti hned na počátku vytvářet nejenom instance tříd, které již v projektu existují, ale mohou definovat i svoji vlastní třídu – konkrétně testovací třídu, která si ve formě jednotlivých testů zapamatuje operace, jež v projektu s jeho třídami a jejich instancemi prováděli. Vytvoření vlastní testovací třídy, jejíž testy např. nakreslí nějaké zajímavé obrázky, může být při výuce na základních a středních školách prvním domácím úkolem.
30
Rudolf Pecinovský
Na vysokých školách se dá na tyto úvodní hrátky navázat ještě v prvním cvičení konstrukcí prázdné třídy, kterou postupně doplníme o konstruktor, jenž nakreslí některý z obrázků, které byly dříve kresleny interaktivně. Poté si předvedeme možnosti definice přetížených verzí konstruktorů a seznámíme se s klíčovým slovem this. Pokračujeme definicí metod, které mají s obrázkem manipulovat (např. jej mají přesunout). Ukážeme si, že k takovýmto operacím potřebujeme zavést atributy a současně si předvedeme, jak se svými atributy pracují instance grafických tříd v používaném projektu. 2.3
Návrhový vzor Knihovní třída (Library class)
Definujeme si třídu Světlo a její metody rozsviť() a zhasni(). Pak si řekneme, že bychom mohli naučit naše světlo blikat. Seznámím je proto s pomocnou třídou P a její metodou čekej(int), která na zadanou dobu zastaví provádění programu. Poté definujeme metodu blikni(), která světlo rozsvítí, chvíli počká, zhasne je a zase chvíli počká. Při té příležitosti jim prozradím, že třída P nemá žádné instance, protože je její metody ke své činnosti nepotřebují. Všechny jsou proto definovány jako metody třídy (statické metody) a třída má svůj konstruktor definován jako soukromý, aby její instance vůbec vyrobit nešlo. Vysvětlíme si, že třída P je typickým reprezentantem knihovní třídy a zopakujeme si, jaké vlastnosti knihovní třída má. 2.4
Zavedení rozhraní
Jednou z možností, jak studentům co nejdříve představit úlohy, v jejichž řešení jim neobjektové zkušenosti příliš nepomohou, je vyložit co nejdříve vedle tříd také rozhraní a předkládat pak úlohy, při jejichž řešení je využijí. V knize [7] jsem zaváděl rozhraní až po ukončeném výkladu základních vlastností tříd (atributy, metody, statické a nestatické členy, referenční a hodnotové datové typy atd.). Obdobnou posloupnost jsem prezentoval i v [8], [9], [10] a [11]. Postupem doby jsem ale dospěl k závěru, že to je příliš pozdě. Zkušenosti s kurzy dětí i dospělých ukázaly, že rozhraní je vhodné vyložit hned poté, co se žáci seznámí se základní syntaxí použitého programovacího jazyka. Stačí opravdu základní znalosti o definicích tříd, jejich konstruktorů, atributů a metod. Seznámení s rozhraními jsem v současné době předřadil před výklad řady rysů tříd. Studenti se tak seznámí s tímto druhem datového typu na samém počátku kurzu a budou se s ním setkávat ve většině svých následných úloh. Velkou výhodou včasného zavedení rozhraní je, že se pak daleko snáze vymýšlí automatizované kontroly odevzdaných úkolů. Příklady takovýchto automatizovaných kontrol si ještě ukážeme.
Začlenění návrhových vzorů do výuky programování
2.5
31
Návrhový vzor Služebník
V současné době seznamuji studenty s rozhraním hned po prvních definicích vlastních tříd. Protože v tuto chvíli ještě studenti neprobrali cyklus, navrhnu jim náhradní řešení, které bude využívat objektových možností jazyka. Teoretický úvod Seznámím je s návrhovým Služebník a prozradím jim, že tento vzor použijeme ve chvíli, kdy potřebujeme vybavit skupinu tříd novou schopností. Vysvětlím jim, že doplňovat kód do každé ze tříd nebývá optimální, protože jednou z důležitých programátorských zásad je, nepoužívat stejný kód na různých místech programu. Při jeho případné pozdější modifikaci (a je jedno, jestli jsme v něm našli chybu nebo jestli si zákazník objednal úpravu chování programu) si pak totiž nemusíme pamatovat, kde všude byl daný kód použit, a všechna místa navštívit a kód na nich shodně opravit. Stačí nám totiž opravit kód na jediném místě. Tím snížíme pracnost a naopak zvýšíme spolehlivost dané opravy. Jednou z možností, jak tento problém řešit, je definovat třídu – služebníka, která bude obsahovat potřebné metody. V místě, kde mají naše instance provést požadovanou činnost, pak mohou pouze zavolat příslušnou metodu služebníka a předat mu obsluhovanou instanci jako parametr. Aby mohl služebník danou instanci správně obsloužit, mívá většinou nějaké požadavky na její schopnosti. Vedle třídy služebníka proto definujeme také rozhraní (nazvěme jej pracovně IObsluhovaný), které požadované schopnosti blíže specifikuje. Služebník pak definuje metodu, jejímž parametrem je instance tohoto rozhraní. Výhodou tohoto přístupu je také to, že nemusíme třídu služebníka spolu s potřebným rozhraním definovat sami, ale můžeme je získat od někoho jiného. To se nám hodí zejména tehdy, pokud víme o tom, kde hotové řešení seženeme, nebo pokud nedokážeme danou úlohu vyřešit sami a musíme si její řešení někde objednat. Vysvětlíme si, že služebník může být sice definován jako knihovní třída, ale většinou bývá definován jako instance – často jako jedináček.
Obr. 1. Diagram tříd návrhového vzoru Služebník.
32
Rudolf Pecinovský
Realizace Po tomto teoretickém úvodu nabídnu studentům hotovou třídu Opakovač s metodami opakujKrát(int) a opakujVteřin(double) doplněnou rozhraním IAkce (pro lepší orientaci studentů přidávám ke všem identifikátorům rozhraní standardně prefix I) vyžadujícím implementaci metody akce(). Upravíme pak definici třídy Světlo tak, aby implementovala rozhraní IAkce, a doplníme metodu akce(). Ukážeme si, že tuto metodu lze definovat jednouše tak, že zavolá dříve definovanou metodu blikni(). Poté definujeme metodu blikej(int). Následně definujeme třídu Přejezd simulující výstražná světla na železničním přejezdu, která bude mít (mimo jiné) metodu blikni(), jež rozsvítí levé a zhasne pravé světlo, chvíli počká, zhasne levé a rozsvítí pravé světlo a opět chvíli počká. Za domácí úkol dostanou studenti doplnit třídu Přejezd o schopnost dlouhodobého blikání a definovat vlastní třídu Semafor, která bude schopna simulovat standardní semafor řídící provoz na silnicích. V profesionálních kurzech řeší převážná většina kurzantů úkol tak, jak je požadováno, tj. s využitím rozhraní. Mezi žáky v kroužcích i mezi studenty na VŠ se však vždy najde dost takových, kteří již vědí, jak se programuje cyklus, a rozhodnou se ušetřit si práci tím, že místo implementace rozhraní použijí rovnou cyklus. Na ty mám připraven malý podraz: v některé z dalších hodin rozšíříme schopnosti vytvořených přejezdů a semaforů zavedením dalších služebníků. Instance, které ve svých metodách nevyužívají opakovače, protože řeší opakování vlastním cyklem, nebudou schopny některé z nových akcí realizovat. Za chvíli se k těmto zadáním dostaneme. 2.6
Návrhový vzor Přepravka (Messenger)
Abychom si návrhový vzor Pomocník zopakovali a upevnili, doplníme doposud definované třídy o schopnost pohybu. Společně se zamyslíme nad množinou zpráv, na něž musí umět reagovat instance, které budou chtít využívat služebníka, jenž s nimi bude plynule pohybovat. Při definici metod pro zjišťování a nastavování pozice narazíme na problém, že pozice je definována dvěma hodnotami, kdežto metoda smí vrátit pouze jednu hodnotu. Tento problém lze řešit dvěma způsoby: buď definovat několik metod, z nichž každá vrátí jednu z požadovaných hodnot, nebo definovat novou třídu, jejíž instance budou sloužit jako přepravky pro skupiny předávaných hodnot. Pro každou hodnotu bude definován jeden atribut, přičemž atributy přepravky budou (na rozdíl od běžné praxe) deklarovány jako veřejné. Definujeme proto třídu Pozice, jejíž instance budou sloužit jako přepravky při předávání informací o pozicích různých objektů. Poté definujeme rozhraní IPosuvný, jehož instance budou implementovat metody getPozice() a setPozice(Pozice) a upravíme definici tříd Světlo a Přejezd, aby jejich instance byly posuvné. Poté si studenti stáhnou předpřipravenou třídu Přesouvač a vyzkouší si, jak se jejich instance plynule přesouvají po plátně. Ti, kteří ve svých třídách použili při implementaci blikání opakovače, si mohou dokonce vyzkoušet, že jejich instance jsou schopny se posouvat a přitom blikat. Instance těch, kteří definovali blikání prostřednictvím cyklu, tuto schopnost ovládat nebudou.
Začlenění návrhových vzorů do výuky programování
2.7
33
AktivníPlátno a událostmi řízené programování
Již při počátečním hraní si s objekty jsme zjistili, že přesouvané objekty odmazávají objekty, které přes ně v jejich výchozí pozici přesahují. Při plynulém přesouvání pak odmazávají vše, přes co cestou přejedou. (Nejde o to, že bychom nemohli naprogramovat plátno tak, aby se objekty neodmazávaly, ale takto můžeme před studenty předestřít pádný důvod pro změnu koncepce zobrazování.) Abychom tento nepříjemný stav odstranili, nahradíme dosavadní třídu Plátno představující pasivní plátno, na něž se všechny obrazce kreslí, třídou AktivníPlátno. Její instance však již není skutečným plátnem, na které se kreslí, ale pouze takovým manažerem, který rozhoduje o tom, kdy se má co na plátno nakreslit. Tato instance má skutečné plátno schované a zobrazení instance na tomto plátně zprostředkuje tak, že instanci poskytne kreslítko, jímž se daná instance na ono soukromé plátno nakreslí. Jinak, než dodaným kreslítkem se na toto plátno nic nakreslit nedá, takže tímto způsobem AktivníPlátno zabezpečí, že se na plátno nakreslí pouze ten obrazec, který samo určí, a v okamžiku, který určí. Budeme-li chtít od této chvíle nějaký objekt nakreslit na plátno, musíme jej nejprve přihlásit u manažera – aktivního plátna, aby jej přidal mezi spravované objekty, o jejichž vykreslovaní se stará. Aby bylo AktinvíPlátno ochotno přijmout někoho do své správy, musí o něm vědět, že se bude umět na požádání nakreslit dodaným kreslítkem. Vedle aktivního plátna je proto definováno ještě rozhraní IKreslený, jež vyžaduje implementaci metody nakresli(Kreslítko), po jejímž zavolání se příslušná instance dodaným kreslítkem nakreslí. Metoda pro přidání dalšího objektu mezi spravované je pak deklarována nakresli(Kreslítko). Objekt, který bude svěřen do správy aktivního plátna, však nikdy nebude vědět, kdy bude o své vykreslení požádán. AktivníPlátno totiž spustí posloupnost překreslování pokaždé, když někdo vyvolá jeho metodu překresli(). Spravované objekty však dopředu nevědí, kdy to bude. V tuto chvíli se studenti poprvé setkávají s událostmi řízeným programem. Pokaždé, když se někdo domnívá, že se situace na plátně změnila (např. když se nějaký objekt posunul nebo změnil svoji velikost), požádá AktivníPlátno, aby vše překreslilo, a to pak oslovuje jednotlivé nakreslené objekty, předává jim aktuální kreslítko a žádá je, aby se překreslily. 2.8
Návrhový vzor Pozorovatel (Observer)
AktivníPlátno je vzorovou implementací návrhového vzoru Pozorovatel, a to hned dvakrát. O prvním významu jsem již hovořil. Kromě objektů, které chtějí být nakresleny na plátně, nabízí AktivníPlátno možnost evidovat tzv. přizpůsobivé objekty, tj. objekty, které chtějí mít svoji pozici i rozměr neustále v korelaci s velikostí kroku aktivního plátna. AktivníPlátno totiž kreslí na plátno čtvercovou síť, která uživatelům umožňuje přesněji odhadnout pozice a rozměry nakreslených obrazců. V některých aplikacích je výhodné, aby se zobrazované objekty uměly přizpůsobit změně velikosti kroku aktivního plátna, tj. vzdálenosti čar této sítě.
34
Rudolf Pecinovský
Třídy, jejichž instance se mají přizpůsobovat změnám kroku aktivního plátna, musí implementovat rozhraní IPřizpůsobivý, jež vyžaduje od je implementujících tříd implementaci metody krokZměněn(int,int). Přizpůsobivé instance opět vystupují jako pozorovatelé, kteří se zavoláním metody přidejPřizpůsobivý(IPřizpůsobivý) přihlásí u aktivního plátna a to pak při každé změně svého kroku zavolá u všech přihlášených přizpůsobivých instancí jejich metodu krokZměněn(int,int). Návrhový vzor Pozorovatel využívá i třída Multipřesouvač a její rozhraní IMultiposuvný, jež je potomkem rozhraní IPosuvný vyžadujícím navíc implementaci metody přesunuto(Multipřesouvač). Instance třídy Multipřesouvač (která je mimochodem jedináček) může přesouvat několik instancí rozhraní IPosuvný. Je-li přesouvaný objekt instancí rozhraní IMultiposuvný, vyvolá Multipřesouvač po přesunutí objektu do požadované cílové pozice jeho metodu přesunuto(Multipřesouvač), které se předá jako parametr. Instance se v této metodě může rozhodnout o svém dalším přesunu a opět o něj Multipřesouvač požádat. Poznámka. Možná bude někomu připadat předchozí mechanizmus jako rekurzivní volání. Není tomu tak. Instance se přihlásí u multipřesouvače o přesun a tím svoji metodu ukončí. Až bude příště multipřesouvač posouvat svěřené objekty o kousek k jejich zadaným cílovým pozicím, přemístí i staronově zařazenou instanci.
3
Návrh úprav stávajících příkladů
Prozatím jsem uváděl pouze příklady pracující s grafickými objekty. Přiznám se, že ty patří k mým oblíbeným, protože je na nich názorně vše vidět a vysvětlované principy při jejich použití „lépe tečou studentům do hlavy“. Nesmíme se však omezovat pouze na tento druh příkladů, protože pak studenti mohou podlehnout dojmu, že se OOP týká pouze práce s grafickými objekty. Vyučující předkládají studentům různé druhy příkladů, přičemž část projektu často navrhnou sami a část projektu nechávají řešit studenty. Běžně zadávané projekty však mívají několik společných nevýhod: • Požadují po studentech především vyřešení algoritmických částí řešení a objektové pozadí jim poněkud uniká. • Vyučujícímu zabere zbytečně moc času testování správnosti řešení požadované funkčnosti. • Chce-li vyučující prověřit pochopení celého zadání studentem a požádá-li studenta o jakékoliv rozšíření, musí kvůli tomu měnit i třídu, kterou sám navrhl (nebo o její změnu požádat studenta). Jedním z oblíbených zadání je návrh kalkulačky. Tento příklad uvádí již [1] a můžete se s ním setkat na řadě škol. Jeho diagram tříd většinou odpovídá diagramu na obr. 2, přičemž třídy Kalkulačka a Zobrazení definuje vyučující a student má za úkol navrhnou pouze předem zadané metody třídy Výpočet.
Začlenění návrhových vzorů do výuky programování
35
Obr. 2. Diagram tříd klasicky navrženého příkladu s kalkulačkou.
Takto navržená aplikace má výše popsané nevýhody. Pro vyučujícího by bylo mnohem výhodnější, kdyby definoval zadání podle diagramu tříd na obr. 3.
Obr. 3. Diagram tříd příkladu s kalkulačkou využívajícího rozhraní.
Toto zadání je sice na první pohled složitější, ale to je opravdu pouze na první pohled. Ve skutečnosti je pro vyučujícího mnohem výhodnější, protože mu šetří hodně práce. Svým způsobem je jednodušší i pro studenty (tedy alespoň pro ty, kteří chápou význam a možnosti použití rozhraní). Zkusím je proto popsat podrobněji: Rozdělení na CPU a GUI Kalkulačka je obdobně jako v předchozím zadání rozdělena na centrální procesorovou jednotku (CPU) a grafické uživatelské rozhraní (GUI). Na rozdíl od předchozího zadání však nejsou tyto části definovány primárně jako třídy, ale jsou zavedeny jako rozhraní. To přináší řadu výhod. Tím, že CPU a GUI zastupují ve vzájemné komunikaci jimi implementovaná rozhraní ICPU a IGUI, si osvobodíme ruce k tomu, abychom mohli svobodně vyměňovat třídy reprezentující kteroukoliv z obou částí. Rozhraní IGUI deklaruje pouze dvě přetížené metody setRozměr; první umožní zadat rozměr klávesnice (tj. počet sloupců a řádků kláves) a druhá vedle rozměru umožní zadat i bodovou velikost jejích tlačítek (to kdyby studenti používali funkce s delšími popisky). Rozhraní ICPU deklaruje také dvě metody: metodu getOperace(IGUI), která vrátí seznam popisků na klávesách kalkulačky přičemž ve svém parametru dostane odkaz
36
Rudolf Pecinovský
na aktuální GUI, a metodu příkaz(String), která převezme jako parametr popisek na stisknuté klávese a vrátí textový řetězec, jenž se má vypsat na displeji. To, že zde odpadla hlavní třída Kalkulačka, je pouze vedlejší efekt, protože vývojové prostředí BlueJ, které na kurzech používáme, takovou třídu nepotřebuje. Pro účely testování ji s výhodou zastoupí přípravek (fixture) v testovací třídě TestCPU. Pro pozdější úpravu na samostatně spustitelnou aplikaci ji můžeme kdykoliv doplnit. Popis činnosti Kalkulačku spustíme tak, že vytvoříme novou instanci GUI, přičemž jejímu konstruktoru předáme jako parametr odkaz na instanci použité CPU. Při vytváření své instance nejprve konstruktor GUI požádá svůj parametr o seznam popisků na klávesách, a pak vytvoří klávesnici, na jejíž klávesy postupně umístí obdržené popisky. Klávesy, pro něž obdrží prázdný popisek, přitom přeskočí. CPU může v reakci na žádost o seznam operací zadat GUI požadovaný rozměr klávesnice a případně i jejích tlačítek. Musí to však učinit před tím, než vrátí požadovaný seznam popisků. Význam třídy Verze Instance třídy Verze uchovávají informace o jednotlivých zadáních. Při vytváření instance zadáme konstruktoru číslo požadované verze a konstruktor vytvoří instanci, která si pamatuje seznam požadovaných operací dané verze (ten vrátí po zavolání metody getOperace()) a seznam testovacích kroků, jimiž je možno příslušnou CPU otestovat. Tento seznam, resp. jeho iterátor získáme zavoláním metody getTesty(). Snadné testování Třídu GUI zobrazující podobu kalkulačky na obrazovce můžeme pro účely testování snadno nahradit třídou TestCPU, která se bude při komunikaci s testovanou CPU vydávat za plnohodnotnou GUI (CPU nemá šanci poznat, zda se něco doopravdy zobrazuje) a při té příležitosti její chování kompletně otestuje. Každý student definuje svoji vlastní CPU, kterou je možno kdykoliv přidat do projektu a kompletně otestovat. Testování je velice jednoduché: vytvoříme přípravek obsahující instanci testované CPU a instanci třídy Verze odpovídající příslušnému zadání. Pak už jen spustíme testy a BlueJ nám oznámí, jak dopadly. Snadné ověřování znalostí Rozhodne-li se vyučující prověřit pochopení studenta zadáním nějaké rozšiřující funkce, stačí studentu, aby jeho metoda getOperace() vrátila seznam bohatší o popisek pro nově přidanou funkci a aby naprogramoval reakci na stisk příslušné klávesy. GUI samo automaticky upraví vzhled kalkulačky podle obdrženého seznamu.
Začlenění návrhových vzorů do výuky programování
4
37
Další návrhové vzory, které by měly být probrány ještě ve vstupním kurzu
V předchozích dvou kapitolách jsem nastínil možnosti zařazení výkladu některých objektově orientovaných rysů (a především pak návrhových vzorů) do prvních hodin vstupního kurzu programování. Ve zbylých hodinách bychom neměli opomenout výklad následujících návrhových vzorů: 4.1
Neměnné objekty (Immutable objects)
V začátečnických kurzech i učebnicích často postrádám výklad toho, že datové typy můžeme dělit na odkazové (referenční) a hodnotové, tj. na typy, u nichž shodu objektů odvozujeme ze shody jejich odkazů a typy, u nichž shodu instancí odvozujeme ze shody jejich hodnot a v Javě ji zjišťujeme voláním metody equals(Object). Řada učebnic se sice zmíní, že instance některých datových typů (např. typu String) je třeba porovnávat prostřednictvím jejich metody equals(), avšak tuto skutečnost nijak dále nerozebírají. To, že hodnotové datové typy rozdělujeme ještě na proměnné (mutable) a neměnné (immutable) již většinou naprosto pominou a nejvýše upozorní, že instance datového typu String jsou neměnné a naznačí některé důsledky této skutečnosti. Pokud se autor o dělení na proměnné a neměnné typy zmíní, tak tento výklad již většinou nedoprovodí výkladem toho, jaké jsou výhody a nevýhody neměnných objektů a především jak neměnné objekty definovat. Vynechám-li svoji učebnici, tak mezi texty, do nichž jsem měl možnost nahlédnout, jsem rozumně podrobný rozbor této otázky našel pouze v [2], resp. [3]. Autoři běžných kurzů většinou předpokládají, že na to jejich žáci přijdou sami. Nepřijdou. Mojí totiž tolik starostí s pochopením nového světa, že na odhalování některých detailů již nemají volnou mentální kapacitu. 4.2
Jedináček (Singleton)
Z tříd, o nichž jsem se zmiňoval v kapitole 2, jsou jako jedináčci definovány Plátno, AktivníPlátno a Multipřesouvač. S třídami, jejichž instance jsou jedináčci, se tedy studenti seznámí. Bylo by proto nanejvýš vhodné, aby se takové třídy naučili také definovat sami. 4.3
Výčtový typ (Enumerated Type)
Výčtový typ řeší problém definice třídy s předem známým počtem předem známých instancí. Java 5.0 jej zavedla vedle tříd a rozhraní jako samostatný druh datového typu. Bylo by vhodné seznámit studenty nejenom s jeho definicí a používáním, ale také s tím, jak jeho ekvivalent definovat v předchozích verzích Javy.
38
4.4
Rudolf Pecinovský
Prázdný objekt (Null Object)
Bývá častým zvykem, že metody vracejí v nejrůznějších okrajových situacích prázdný odkaz null. Metody, které takové metody volají, pak musejí ošetřovat, zda jim byl vrácen plnohodnotný objekt nebo prázdný odkaz. V řadě situací je vhodné definovat v aplikaci nebo třídě objekt nazvaný např. NULL, který by byl vracen místo prázdného odkazu. Řada metod se tak zjednoduší, protože již nebudou muset testovat prázdnost vráceného odkazu. Je však třeba, aby měl onen prázdný objekt definovány správné metody. 4.5
Iterátor (Iterator)
S iterátorem se studenti seznámí při probírání kolekcí. Bylo by vhodné jim při té příležitosti prozradit, že se jedná o návrhový vzor, a rozebrat situace, kdy je výhodné jej použít. 4.6
Tovární metoda (Factory Method)
Metody iterator(), které poskytují všechny kolekce ve standardní knihovně, realizují návrhový vzor Tovární metoda. Na příkladu iterátoru lze také studentům tento návrhový vzor dostatečně průzračně vysvětlit. 4.7
Zástupce (Proxy)
Zástupce je další z jednoduchých vzorů, s nímž je vhodné studenty seznámit již ve vstupním kurzu. Ukázka zadání, jehož řešení využívá tento vzor, je např. v [7]. Rád bych ale časem nalezl nějaké lepší příklady, ve kterých by studenti tento vzor nejenom potkali, ale bylo by v nich pro ně užitečné tento návrhový vzor také použít. 4.8
Stav (State) a Strategie (Strategy)
Další návrhové vzory, které si pro svoji jednoduchost zaslouží být vyloženy již v úvodním kurzu, jsou vzory Stav a Strategie. Vzor Stav je v [7] demonstrován na příkladu šipek (v současných kurzech nahrazuji šipky roboty), které se chovají odlišně podle směru, do nějž jsou natočeny (jinak se kreslí, pohybuje a zatáčí šipka či robot směřující na východ a jinak šipka či robot směřující na jih). Pro demonstraci návrhového vzoru Strategie mi připadá optimální rozšířit před chvílí probíraný příklad s kalkulačkou. Navrhneme kalkulačku, která má několik CPU – jednu pro výpočty s reálnými čísly, druhou pro komplexní čísla, třetí např. pro maticové výpočty. Vše pak bude dirigovat řadič (také CPU), který rozlišuje reakci na přepínací příkaz (po něm změní obsah vnitřní proměnné odkazující na aktuální CPU) a jinak na ostatní příkazy (ty beze změny přepošle aktivní CPU) – viz obr. 4.
Na webu najdeme řadu dalších jednoduchých příkladů, v nichž se tyto návrhové vzory s úspěchem využijí. 4.9
Příkaz (Command)
Návrhový vzor Příkaz byl použit (spolu s několika dalšími vzory) už v příkladu s kalkulačkou. U něj by bylo vhodné poukázat na jeho příbuznost s návrhovým vzorem Služebník – liší se vlastně pouze v tom, jakými úvahami se k výslednému schématu dostaneme. 4.10 … a další V předchozím výčtu jsem jmenoval pouze vzory, s nimiž se studenti ve vstupních kurzech bezpečně setkají (nebo by se s nimi setkat měli). Vedle toho je řada dalších vzorů, které nejsou tak složité, aby je nebylo možno použít v příkladech řešených ve stupních kurzech. Hlavním problémem je podle mne nalezení těch správně jednoduchých příkladů, na nichž se toho ale studenti hodně naučí.
5
Další náměty k zamyšlení • Metodikou výuky ve vstupních kurzech se u nás hlouběji skoro nikdo nezabývá – většina vyučujících směřuje ve svém bádání k „vyšším metám“. Lepší vstupní kurzy jim však „přihrají“ lépe připravené studenty. Bylo by proto vhodné nové trendy v této oblasti alespoň sledovat a vyzkoušet. • Neměli bychom se omezovat pouze na bádání nad vysokoškolskými kurzy programování. Programování se stále častěji učí na středních a dokonce i na základních školách. Nebudeme-li motivovat středoškolské učitele, aby změnili paradigma, v němž žáky vychovávají, budou do vysokoškolských kurzů programování stále přicházet strukturovaní (a to v lepším případě) programátoři, které zde bude nutno nejprve odnaučit mnohému z toho, co se dříve pracně naučili, a poté je naučit zcela novému, objektovému přístupu k řešení problémů. • Při sledování současných trendů v programování bychom se neměli úzce orientovat na pouhé OO paradigma. OOP je sice vynikající metodika pro tvorbu a
40
Rudolf Pecinovský
správu rozsáhlých programových systémů. Vedle ní ale existuje ještě lepší metodika: Ať to udělá někdo jiný. Vedle umění navrhnout správný algoritmus či použít správný návrhový vzor bychom měli naše studenty naučit také schopnosti odpovědět si na otázku Jaký hotový program nebo přípravek mohu při řešení svého problému využít? • Nepodařilo se mi vymyslet, jak terminologicky odlišit rozhraní představující množinu zveřejněných vlastností třídy a jejích objektů (tj. rozhraní jako protiváhu k implementaci) od představujícího druhu datového typu (tj. od rozhraní jako protiváhy k třídě). Tato snadná záměna termínů zbytečně komplikuje výklad, protože vyučující musí často používat termín střídavě v obou významech a to ztěžuje výklad i jeho chápání. V předjavovských dobách tento problém neexistoval, ale zavedením datových typů typu interface tento problém vyvstal a považuji jej za docela nepříjemný.
6
Závěr
Přes deklaraci principu „object-first“ je začlenění výuky principů objektově orientovaného programování v kurzech a učebnicích, s nimiž jsem měl možnost se seznámit, pouze částečné. Domnívám se, že tato skutečnost je do značné míry dána nedostatkem příkladů, na nich by bylo možno návrhové vzory a další principy objektově orientovaného programování demonstrovat. Příspěvek ukázal některé možnosti a především pak příklady, které mohou být inspirací pro prohloubení „objektovosti“ současných vstupních kurzů. Vzhledem k tomu, že je tato problematika stále ještě v počátečních etapách vývoje, bylo by vhodné uspořádat obdobné semináře, jako jsou v textu zmiňované semináře „Killer Examples“ for Design Patterns and Objects First, na nichž by si vyučující mohli vyměňovat své zkušenosti. Tyto semináře mohou být i virtuální nebo mohou být přidruženy k nějaké (např. této) konferenci. Nezanedbatelnou je i nutnost osvěty mezi středoškolskými učiteli, kteří své studenti stále vychovávají podle dávno překonaných metodik, takže je vysokoškolské kurzy musí nejprve odnaučit mnohému z toho, co se pracně naučili. Ale to je již téma na samostatný příspěvek.
Annotation At first the paper shortly informs about six main implementation strategies for introductory programming courses. Then it concentrates on object-first strategy, which starts the whole course working with objects and consistent explanation of object oriented programming principles. The paper criticizes the inconsistency of published lessons and textbooks and shows how to apply the declared principles better and consistently. The key part of the paper demonstrates on the concrete examples how to proceed with lessons, which from the very beginning teach the true object oriented programming, and shows how it is possible to incorporate the explanation of the design patterns into the first lessons. The third part compares the two approaches to the exams test: the classical one, which we can find in many textbooks and lessons, and the true object oriented one. It shows that the true object oriented approach is more advantageous both for the students and for the teacher. In the last part it notes some design patterns, which should be incorporated in the introductory courses despite they were not mentioned in this paper so far, and puts some open questions.
Podpora výuky inženýrství a Podpora výukysoftwarového softwarového inženýrství a informačníchsystémů systémů informačních Marek Běhálek1, Lumír Návrat1, Michal Radecký1, Tomáš Tureček1 Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček 1
Katedra informatiky, FEI, VŠB – Technická Univerzita Ostrava, 17. listopadu 15, Katedra informatiky,708 FEI, Technická Univerzita Ostrava, 33,VŠB Ostrava-Poruba 17. listopadu 15, 708 33, Ostrava-Poruba [email protected] {marek.behalek, lumir.navrat, michal.radecky, tomas.turecek}@vsb.cz [email protected][email protected][email protected] Abstrakt. V rámci výuky se studenti seznámí s různými technologiemi a nástroji pro vývoj softwaru. Většinou jsou tyto technologie úzce spjaty s obsahem předmětu, ve kterém jsou probírány. Studenti často mají problém tyto přístupy spojit při realizaci složitější aplikace. Pomoci by jim mohl doplňující výukový materiál obsahující zejména sadu ukázkových příkladů, ve kterém by v praxi viděli probírané technologie v širším kontextu. Popis řešení výukového materiálu je předmětem tohoto příspěvku. Klíčová slova: výuka, RUP, objektové technologie, informační systémy, UML.
1
Úvod
Výuka studentů bakalářského studijního programu Informační technologie oboru Informatika a výpočetní technika je na fakultě elektrotechniky a informatiky VŠB-TU v Ostravě zaměřena zejména na rozvíjení praktických dovedností absolventů založených na dostatečných znalostech základních principů a metod. Studenti absolvují řadu předmětů, které je seznamují s různými přístupy a technologiemi při vývoji softwaru. Tyto technologie a přístupy mají většinou úzkou vazbu na předmět, ve kterém jsou probírány. Díky tomu studentům často chybí komplexní pohled na probíranou problematiku a často nejsou schopni využít nabytých znalostí při řešení složitější a větších projektů, k jejichž řešení by bylo vhodné sloučit znalosti z různých oblastí. Pomoci by jim mohla sada řešených úloh, které prakticky demonstrují probírané technologie a přístupy na složitější a ucelené aplikaci. Proto byl pro potřeby studentů vypracován materiál, který ukazuje vývoj aplikací od specifikace zadání až po instalaci výsledného produktu. Tyto ukázkové úlohy by byly řešeny s využitím různých technologií a s pomocí různých vývojových nástrojů. Studenti tak mají možnost vidět probírané technologie v širším kontextu a ověřit si, že danou problematiku úspěšně zvládli. Tyto zkušenosti (získané při výuce) jsme se snažili zohlednit při realizaci doplňkového výukového materiálu. Popis jeho řešení je obsahem toho článku.
c Václav Snášel, editor: Objekty 2005, pp. 42–53, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Podpora výuky softwarového inženýrství a informačních systémů
2
43
Cíle výukového materiálu
Vytvářený výukový materiál je primárně určen pro studenty bakalářského studijního oboru Informatika a výpočetní technika. V tomto programu byl určen zejména pro podporu následujících předmětů. • Úvod do softwarového inženýrství – zde se studenti seznámí se základními metodami pro tvorbu softwarového produktu. Kurz je rozložen do dvou částí zabývajících se procesem vývoje softwaru a způsoby jeho řízení. Proces vývoje softwaru je postaven na objektově-orientovaném přístupu využívajícím specifikační jazyk UML. • Programovací techniky - předmět pokrývá oblast pokročilých algoritmů a nástrojů, jejichž zvládnutí je vyžadováno při programování rozsáhlejších aplikací. • Uživatelská rozhraní – zde jsou probírány metody návrhu rozhraní mezi softwarovým systémem a uživatelem. Posluchači se seznámí s různými hledisky, která návrh ovlivňují, s různými metodami, které k návrhu vedou, a také s různými metodami vyhodnocení kvality návrhu. • Internetové technologie - cílem předmětu je seznámit studenty se základními praktikami pro návrh a vývoj internetových aplikací. • Databázové a informační systémy – předmět seznamuje studenty s vývojem informačního systému a specifika základních etap životního cyklu. • Tvorba informačních systémů - předmět je zaměřen na vytváření rozsáhlejších informačních systémů založených zejména na architektuře klient/server, případně na vícevrstvových architekturách. Výukový materiál by měl co nejlépe postihovat technologie probírané právě ve zmíněných předmětech. Jednou z hlavních forem, kterými jsou získané znalosti upevňovány a v nichž studenti prokazují své praktické schopnosti, je řešení semestrálních projektů. Tyto projekty jsou v současném stavu navrženy spíše v těsné vazbě na konkrétní vyučovaný předmět, což vede na jedné straně k příliš úzce zaměřenému pohledu na konkrétní problémy a na druhé straně tento přístup zvyšuje celkovou zátěž studentů, zejména při realizaci projektů vždy od samého začátku a bez návazností. Vytvořený ukázkový materiál může studentům prakticky přiblížit, jak u řešení svých semestrálních projektů využít projekty z jiných předmětů. Dalším cílem projektu je vytvořit sadu zadání, které by studenti mohli realizovat v rámci samostudia. Tyto úlohy by vhodně rozšiřovaly realizované příklady a studenti by si na nich mohli prakticky ověřit své znalosti. Některé technologie vyžadují komplexnější přístup. Proto bude studentům nabídnuta jakási kostra, kterou pak studenti mohou dále rozšiřovat. Při řízené výuce u počítačů v laboratořích studenti často používají různé vývojové nástroje a aplikace. Problém je, že student při samostudiu nemusí mít možnost využívat školní počítače. Mnohdy také studenti preferují své osobní PC. Pro samostudium tedy potřebují zprovoznit nutné aplikace pro vývoj, ladění a běh vyvíjených aplikací. Součástí výukového materiálu bude i přehled volně dostupných vývojových nástrojů a návod k jejich používání a instalaci. Studentům by tak nemělo nic bránit zprovoznit tyto aplikace na svém osobním počítači.
44
3
Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček
Principy pro vytváření výukového materiálu
V první fázi jsme hledali zadání úloh, která by pokrývala co největší oblast zmíněných předmětů. Navíc jsme se pro vytvářené příklady snažili zvolit oblast, kterou studenti důvěrně znají a často používají. Výsledkem této analýzy bylo, že ukázkové aplikace budou směřovány do oblastí informačních systému přístupných prostřednictvím internetu. Důvody pro tento výběr jsou dva: 1. internetový informační systém nejlépe spojuje oblasti probírané v představených předmětech; 2. informační systém dostupný prostřednictvím Internetu je nejčastějším tématem bakalářské práce; Všichni studenti fakulty elektrotechniky a informatiky používají fakultní informační systém KATIS. Tento systém řeší velkou část agendy spojené se studiem. Řeší například zápis předmětů, podporu zkoušek nebo třeba rozvrhy studentů. Navíc jde o aplikaci dostupnou prostřednictvím internetu. Pro ukázkové aplikace jsme se tedy rozhodli použít funkční podmnožiny tohoto systému. Studenti se tak nemusí seznamovat s další oblastí, do které by byly směřovány ukázkové aplikace a naopak uvidí detailní řešení pro ně známého problému. Pro vlastní implementaci jsme zvolili tyto tři prostředí. 1. Java – Java je na fakultě brán jako hlavní programovací jazyk. Většina předmětů je směřována právě na tento programovací jazyk 2. .NET – Firma Microsoft investovala do vývoje platformy .NET mnoho prostředků a díky rozšířeností produktů této firmy získává toto prostředí čím dál větší oblibu. 3. PHP - Nejčastější technologií, kterou studenti používají pro řešení svých bakalářských prací, je právě PHP (obvykle ve spojení s MySQL). Proto jsme i my do připravovaného výukového materiálu přidali podporu této technologie. Pro řešení jsme se snažili maximálně využít volně dostupných nástrojů a prostředků. Pro vytváření dokumentace jsme využili obvyklé formáty jako PDF, HTML, nebo XML. 3.1
PHP
Dnešní informační systémy postavené na moderních technologiích a využívající prostředky a možnosti sítě Internet se neobejdou bez programových nástrojů, které tak tvoří funkční základ celé takovéto aplikace. Jednou z těchto technologií, které jsme se také rozhodli využít pro praktickou implementaci ukázkových aplikací, je technologie PHP (Personal Home Page). Jedná se technologií, která svůj vývoj započala někdy v roce 1994 a od té doby se tato aplikační platforma stala velmi populární a efektivně využívaným nástrojem pro tvorbu a provoz internetových či intranetových aplikací a informačních systémů. Na svém začátku vývoje byl jazyk PHP vytvořen jen pro osobní potřeby jednoho z členů týmu Apache - Ramous Lerdorf[7]. Tato myšlenka a vytvořený základ se setkal s velkou odezvou a tak započal vývoj aplikační platformy PHP, kdy její atraktivnost a rozšíření bylo podpořeno také skutečností, že se jedná o volně použitelnou
Podpora výuky softwarového inženýrství a informačních systémů
45
programovou platformu, a to včetně volně přístupných zdrojových kódů. Mezi klady použití této technologie patří také integrace s dalšími aplikacemi pro provoz internetových informačních systémů (Apache, MySQL, atd.), kdy uvedené softwarové aplikace jsou dnes již automaticky integrovány do nejrůznějších distribucí operačních systémů Linux a jejich instalace a provoz v operačních systémech řady Windows jsou také bezproblémové. Mezi dnes nejrozšířenější verzi tohoto jazyka patří verze 4, která nabízí vše, co je potřeba pro tvorbu informačních systémů[2]. Nicméně, poslední PHP 5 rozšiřuje a doplňuje svou předchozí verzi o celou řadu prvků, které vylepšují, usnadňují a zkvalitňují jak vlastní práci s jazykem PHP, tak výsledné aplikace a informační systémy. Konkrétním novinkám se věnuje část následujícího textu. PHP patří do skupiny tzv. skriptovacích jazyků, které jsou založeny na principu spojování a rozšiřování (X)HTML ((eXtensible)HyperText Markup Language) o aktivní programové prvky, které jsou zpracovávány na straně aplikačního serveru ještě před odesláním klientovi. Jak již z názvu vyplývá, jedná se o skriptovací jazyk, kdy jeho příkazy jsou prováděny a zpracovány až ve chvíli řešené požadavku klienta. PHP zdrojový kód je tedy prováděn přímo, bez předchozího předzpracování či kompilace. Jedná se tedy o jazyk, který je ve spojení s odpovídajícím WWW serverem velmi silným nástrojem pro poměrně snadnou, rychlou a přímočarou tvorbu informačních systémů postavených na technologiích internetových aplikací. To je také hlavním důvodem, proč jsou témata bakalářských prací velmi často směrována právě na problematiku informačních systémů v PHP. Zařazení PHP mezi skriptovací jazyky přináší celou řadu výhod i nevýhod. Mezi hlavní výhody patří skutečnost, že není třeba provádět jakékoliv zpracování zdrojových kódů a změny provedené v programech se tak mohou okamžitě projevit na straně uživatele při vlastním běhu informačního systému. Další významnou výhodou je přímé propojení příkazů a programových struktur PHP s jazykem pro specifikaci vlastního obsahu WWW stránek ((X)HTML). PHP je všestranný jazyk pokrývající celou řadu problémů a témat spojených s vývojem a provozem internetové aplikace. Pomocí jazyka PHP není problémem obsluhovat požadavky zasílané formou formulářů, spolupracovat s datovými úložišti a databázovými servery (např. MySQL je ve spojení s PHP velmi častou a efektivní volbou), vytvářet a manipulovat se soubory či obrázky, rozšiřovat své funkce a možnosti spojováním s dalšími technologiemi (Java, .NET, COM/DCOM), atd. Jak již bylo zmíněno výše, poslední oficiální verze přináší celou řadu oprav, vylepšení, ale také novinek [1]. Hlavní novinkou, která je s PHP 5 spojena, je pak zcela nová a výkonná objektově orientovaná technologie (OOT). Zařazení této technologie přináší celou řadu nových možností mající svůj hlavní význam převážně při vývoji rozsáhlých a náročných projektů, kdy je nyní možné při vývoji aplikací postupovat podle metodik objektově orientovaného modelování. Samozřejmě, že jazyk PHP 5 si zachoval i čistě neobjektový přístup, který tak dále může být využívat při tvorbě menších projektů a projektů bez nutnosti využití OOT. Objektová technologie aplikovaná v jazyce PHP zahrnuje všechny základní vlastnosti a techniky vycházející právě z objektového přístupu. PHP 5 tedy z pohledu OOT podporuje: • tvorbu tříd a jejich instancí a zapouzdření dat a metod;
46
Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček
• • • • •
dědičnost mezi třídami a polymorfizmus; podpora konstruktorů, destruktorů a výjimek; zabezpečení proměnných a metod: public, protected a private; statické metody a proměnné; rozhraní a abstraktní třídy.
Globálně je však možné problematiku OOT v jazyce PHP považovat za trochu odlišnou, než je tomu například u čistě objektových aplikačních jazyků Java či C++, či dokonce než je tomu u aplikačního rámce ASP.NET. Tato uvedená prostředí nereagují jen na jednotlivé požadavky separátně, ale tvoří jakýsi celistvý aplikační prostor kolem celé vykonávané aplikace, což takto v případě jazyka PHP není. V praxi to znamená, že instance tříd jsou v PHP svázány pouze se zpracováním jednoho konkrétního požadavku a v rámci celé aplikace tak neexistuje možnost udržování instancí a dat mezi těmito požadavky. Celkový aplikační rámec je následně potřeba realizovat pomocí dalších technik a postupů, které jsou založeny na vlastním PHP jazyce a nikoliv na vnitřní struktuře programového prostředí. Mimo výše uvedené novinky v oblasti OOT přináší poslední verze jazyka PHP také další prvky spadající převážně do následujících oblastí: • podpora systému MySQL s ohledem na jeho verze 4.x a 5.x – multidotazování, předpřipravené dotazy, zabezpečená komunikace, vázané parametry, atd.; • zpracování a manipulace s XML dokumenty s ohledem na standardy W3C; • podpora alternativního způsobu ukládáni dat SQLite; • zpracování a ošetřování chyb a výjimek; • podpora SOAP technologií pro webové služby; • práce s lokalizovanými daty a kódováními; • vlastní programovací struktury a prvky. 3.2
Java
Jedná se o druhou platformu, pro kterou jsme se rozhodli implementovat ukázkové příklady. Historie tohoto jazyka trvá již 10 let. Za tuto dobu si získala mnoho příznivců a existuje spoustu podpůrných nástrojů pro tuto platformu. Jazyk Java patří mezi interpretované jazyky. Jelikož samotná interpretace není příliš výkonná, je Java obohacena o JIT1 překladač. Díky své architektuře postavené na virtuálním stroji je pak dostupná na mnoha platformách. Java patří v dnešní době mezi velmi rozsáhlé nástroje a používá se v mnoha oblastech. Od mobilních zařízení až po rozsáhlé systémy na architektuře klient/server. Jak již bylo zmíněno výše, zaměřili jsme se právě na oblast internetových aplikací. Technologie postavené na platformě Java a určené pro prostředí webu jsou probírány zejména v předmětu Tvorba informačních systémů. V dnešní době existuje mnoho takových technologií a v průběhu tohoto jednosemestrálního kurzu studenti nemohou pojmout ani nejrozšířenější technologie. Důkladněji je v rámci řízené výuky probírán 1
Just In Time – překlad za chodu aplikace. Více v [8].
Podpora výuky softwarového inženýrství a informačních systémů
47
například aplikační rámec Jakarta Struts. Existuje ale i mnoho dalších aplikačních rámců, z nichž některé budou popsány ve tvořeném výukovém materiálu. V následující části jsou popsány technologie, které byly vybrány pro implementaci ukázkových příkladů v první vlně. Jejich výběr byl proveden na základě jejich oblíbenosti mezi vývojáři a s ohledem na dostupnost pro studenty z hlediska ceny a licencí. Přehled použitých technologií: Jakarta Struts – aplikační rámec pocházející z dílny The Apache Software Foundation, jehož autorem je Craig McClanahan. Tento aplikační rámec je postaven na standardních Java technologiích jako jsou servlety, beany, balíky zdrojů. Architektura je postavena na Modelu 2, který vychází z MVC paradigmatu pro který poskytuje vlastní Controler. V rámci modelu je dále možné použít další technologie a nástroje jako je JDBC, EJB, Hibernate, iBatis, Spring atd. Rovněž i View spolupracuje s mnoha prezentačními systémy. Z těch základních můžeme jmenovat JSP včetně JSTL či JSF. Nicméně nám nic nebrání použít např. Velocity či XSLT a další. Spring – Jedná se o další z velmi populárních aplikačních rámců. Autorem je Rod Johnson. Stejně jako Strutsy patří mezi aplikační rámce dostupné zdarma. Spring má mnoho modulů, jejich popis by přesáhl tento článek. Podrobnosti lze najít v [6]. Podle autorů tohoto rámce patří mezi jeho hlavní výhody zaměření na oblasti, kterým se jiné rámce nevěnují. Další jeho vlastností je modularita. Spring jako takový nenabízí nástroje pro konkrétní úlohy. Místo toho je nutné použít různé externí nástroje pro logování zpráv, sdílení databázových spojení apod.
Obrázek 1. Struktura aplikačního rámce Spring. Hibernate – další z popisovaných nástrojů spadá do oblasti perzistence dat. Konkrétně slouží k objektově relačnímu mapování, kdy poskytuje Javě podporu persistentních tříd včetně asociací, dědičnosti, polymorfismu či kompozice. Umožňuje
48
Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček
vytvářet dotazy nejen ve vlastním rozšíření jazyka SQL (HQL), ale i pomocí standardního SQL. Na rozdíl od jiných O/R nástrojů tak neskrývá před vývojářem sílu SQL a JDBC. V posledních verzích podporuje již novou specifikaci EJB 3.0/JSR220. Nicméně je zde možnost používat jej samostatně v rámci klasických Java aplikací nebo uvnitř aplikačního serveru. Podrobnosti o vlastnostech lze najit na [2]. Zde uvádíme jen hlavní vlastnosti. • Transparentní persistenci – nepotřebujeme žádné další rozhraní a třídy a vystačíme si jen s POJO objekty. • Flexibilní O/R mapování – popis mapování je založen na XML, kdy nám umožňuje generovat DDL skripty tabulek. Rovněž podporuje všechny typy vazeb, asociace a jemné kompozice. • Jednoduché API rozhraní – obsahuje tři různé API. Pro aplikační kód, možnosti úprav a API pro metadata. Posledně zmiňované API je možné použít například pro potřeby EJB 3.0 a serveru JBOSS. • OOQL – vlastní dotazovací jazyk, podporující polymorfní dotazy. V rámci podpory SQL máme možnost mnoha dialektů různých SQL databází. • Podpora řízeného i neřízeného režimu – může pracovat jak v kooperaci s JMX a JTA, tak i mimo J2EE server v rámci běžné aplikace. • Vysoce výkonná – podporuje línou inicializaci objektů, různé způsoby propojování, stejně jako optimistické zamykání s automatickou správou verzí. Dále Hibernate nepotřebuje žádné další pomocné tabulky pro svůj běh. • Dvouvrstvá vyrovnávací paměť – umožňuje bezpečně používat vlákna a neblokovaný přístup k datům. Enterprise Java Beans – jedná se technologii, která byla definována přímo firmou SUN. V dnešní době již se dokončuje specifikace ve verzi 3.0. Pomocí EJB je možné tvořit ty nejrozsáhlejší informační systémy. Samotný popis všech možností této platformy překračuje rozsah tohoto článku a informace lze najít v [9]. 3.3
.NET
.NET je nová platforma firmy Microsoft. Tato platforma se skládá z celé řady nových technologií, které jsou určeny zejména pro aplikace postavené pro prostředí rodiny operačních systémů Windows. Souhrnně se tato množina technologií nazývána .NET Framework. Tento vývojový rámec se snaží o zjednodušení a urychlení vývoje aplikace. Strukturu tohoto vývojového rámce zachycuje obrázek 2. Na nejnižší úrovni se nachází CLR - Common Language Runtime realizující základní infrastrukturu, nad kterou je vývojový rámec vybudován. V prostředí .NET jsou zdrojové soubory libovolného programovacího jazyka zkompilovány do intermediárního jazyka (nazvaného MSIL – Microsoft Intermediate Language). V případě, že má být taková aplikace spuštěna, systém detekuje, že jde o aplikaci v MSIL a spustí Just-In-Time kompilátor. Ten vygeneruje skutečné instrukce cílové platformy. Jedním z hlavních cílů při vývoji .NETu je podpora různých programovacích jazyků. Důležitým prvkem CLR je podpora společného typového systému (Common Type Systém – CTS). Další vlastnosti které CLR také implementuje je mechanismus zajišťující typovou bezpečnost a automatický management paměti.
Podpora výuky softwarového inženýrství a informačních systémů
49
Nad CLR se nachází několik hierarchicky umístěných knihoven. Ty jsou rozděleny do jmenných prostorů. Základem je knihovna nazvaná Base Class Libary. Nad ní je knihovna pro přístup k datům a práci s XML soubory. Poslední vrstvou je sada knihoven usnadňující práci s uživatelským rozhraním. Je rozdělena do dvou skupin: pro usnadnění vytváření webových aplikací a pro vytváření klasických aplikací. Poslední vrstvu tvoří nelimitovaná množina programovacích jazyků. Jejich základní vlastnosti definuje CLS – Common Language Specification. V současné době jsou firmou Microsoft podporováno pět jazyků Visual Basic, C++, C#, Jscript a J#. Tato množina ale není uzavřena a jakýkoliv výrobce ji může rozšířit. Více informací o platformě .NET lze nalézt v [6, 5].
Obrázek 2. Architektura .NET Framework. Pro vývoj webových aplikací je primárně určena podmnožina vývojového rámce .NET s názvem ASP.NET. ASP.NET se dá rozdělit na dvě větší části. 1. Webové formuláře (Web Forms) – Jde o programový model, ve kterém jsou stránky (obsahující webové formuláře) generovány na straně serveru a v podobě čistého HTML dodávány klientovi (prohlížeči). Architektura webových formulářů je postavena na událostech. Události jsou generovány ve chvíli kdy uživatel stiskne tlačítko, vybere položku v menu nebo jinak využije možnosti, které mu poskytuje uživatelské rozhraní. Další události také může generovat systém. Právě obsluha těchto událostí tvoří logiku webového formuláře. Tato logika může být implementována v libovolném jazyce vývojového rámce .NET. 2. Webové služby (Web Services) – webové služby jsou aplikace, které poskytují svou funkcionalitu prostřednictvím Internetu nebo intranetu. Webové služby v prostředí .NET pro komunikaci s okolím používají protokol SOAP.
50
Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček
Problémem při vytváření ukázkových příkladů v tomto prostředí byla zejména podpora nástrojů. Nejrozšířenější nástroj pro vývoj aplikací v prostředí .NET je Visual Studio.NET (nebo novější verze označená Visual Studio 2003). Tento produkt ale není veřejně k dispozici. Pro potřeby výuky je sice zajištěna jeho multilicence a studenti tak k tomuto nástroji mají přístup, ale problémem může být případ, kdy studenti chtějí pracovat na svých osobních počítačích. Navíc jedním z cílů, které jsme si při vytváření výukové opory vytýčili, bylo využití zejména volně dostupných nástrojů. Firma Microsoft volně poskytuje základní součásti prostředí .NET jako je společné běhové prostředí a kompletní sada knihoven. Abychom mohli provozovat webové aplikace, potřebujeme webový server. Volně dostupný webový server pro ASP.NET je produkt s názvem Cassini. Pro vlastní realizaci aplikací můžeme použít volně dostupné vývojové prostředí ASP.NET Web Matrix.
4
Realizace výukového materiálu
Po zvážení všech okolností jsme se rozhodli použít jako ukázkové úlohy tato témata. 1. Zápis na zkoušky - Student je zapsán do několika předmětů a v těchto předmětech jsou vyhlašovány zkušební termíny. Aplikace zajistí možnost přihlášení studenta na zkoušku podle platných pravidel a umožní vytváření sestav se seznamy zapsaných studentů. 2. Anketa - Student má k dispozici seznam zapsaných předmětů a vyučujících, kteří v těchto předmětech učí. Aplikace zajistí studentům možnost vyplnění ankety k obsahu a formě výuky v předmětech a k úrovni výuky vyučujících a umožní vytváření sestav s přehledy pro konkrétní předměty a vyučující. Jde o témata, která splňuji již dříve uvedená kritéria. 1. Jde o části informačního systému fakulty. Studenti tuto problematiku velmi dobře znají z uživatelského hlediska. 2. Tyto oblasti bývají často podstatou studentských projektů. Také jde často o příklad, které jsou uváděny na cvičeních a proto jsou s těmito oblastmi studenti seznámeni i z programátorského hlediska. Jako typ softwarového procesu jsme použili RUP (Rational Unified Process). Studenti tento softwarový proces probírají, ale většinou prakticky používají klastický vodopádový model. V této práci jsme chtěli studentům ukázat v praxi tento komplexnější přístup při vývoji aplikace a jak lze vyvíjet aplikaci interakčním způsobem. Tvořené aplikace jsme postavili na objektově orientovaných principech. Při implementaci jsme se snažili o oddělení datové, prezentační a aplikační úrovně aplikace. Dále jsme se snažili ukázat různá řešení stejného problému pomocí různých technologií. Jako nástroj pro modelování aplikace jsme použili UML. Výsledkem jsou webové aplikace postavené na standardním modelu: • Uživatel k práci s aplikací používá internetový prohlížeč využívající jazyk HTML. • Celá aplikace je umístěna na Internetovém nebo intranetovém serveru. Všichni uživatel pak komunikují s tímto serverem. U webových aplikací je nutné dbát zvýšených požadavků na bezpečnost aplikace. Každá stránka (skript) bude mít specifikovány role, které mají právo danou stránku
Podpora výuky softwarového inženýrství a informačních systémů
51
požadovat. Před zpracování požadavku pak bude seznam rolí uživatele maskován s rolemi stránky a v případě neshody nebude uživateli umožněno pokračování ve zpracování požadavku. Podobně bude možné ovlivňovat celé stránky či jejich části na základě konkrétního uživatelského jména uživatele (např. při změně osobních informací). S tímto problémem také souvisí autentifikace a autorizace. Nejprve jsme začali exaktnější specifikací požadavků pro obě úlohy. V další fázi jsme provedli analýzu. Pak jsme realizovali zmíněné úlohy v PHP, .NETu a v Javě. • PHP – Pro implementaci jsme využili PHP5. K uložení dat jsme použili MySQL. • .NET – Pro implementaci v prostředí .NET jsem použili ASP.NET verze 1.1 v kombinaci s jazykem C#. K uložení dat jsme použili opět MySQL. Dále zkoumáme možnost využití některého SQL serveru firmy Microsoft. • Java – Pro řešení v Javě jsme využili rámce Struts. Opět jsme využili MySQL. Tentokrát jsme pro přístup do databáze striktně použili rozhraní JDBC. Jako volitelnou část pro další rozšíření jsme zvolili O/R framework Hibernate. Použití plnohodnotné objektové databáze je zvažováno. ¨ V další fázi jsme implementovaná řešení dále rozšiřovali. 1. Rozšiřovali jsme zadání úloh o další funkční požadavky a ukázali, jak na tyto změny budeme reagovat při vývoji aplikace. Studenti při svých projektech prakticky nikdy nepoužívají iterační způsob vývoje aplikací (nebo celý vývoj obsahuje právě jednu iteraci). Takto uvidí vývoj aplikace s více iteracemi. 2. Od fáze návrhu jsme začali znovu a implementovali danou úlohu s využitím jiných technologií. Tento přístup jsme uplatnili zejména pro technologie postavené na jazyku Java. Takto jsme použili pro perzistencí uložení dat jak technologii Hibernate, tak technologii Enterpise Java Beans. Pro aplikační logiku jsme použili vývojový rámec Spring. Stejně tak jsme představili několik technologií pro prezentační vrstvu. Díky tomu mohou studenti v praxi vidět několik technologií pro stejnou oblast a vybrat si z nich tu, která je jim nejbližší. Navíc tyto technologie často vyžadují komplexnější přístup a „dobrý“ příklad může velice pomoct při jejich pochopení. 3. Dále jsme přidali další technologie a pomocí nich rozšiřovali funkcionalitu. Typickým příkladem jsou webové služby, které jsme implementovali do řešení v ASP.NET. Výukový materiál pak obsahuje jak původní „jednodušší“ implementace, tak složitější verze řešení. Celkově jsme s použitím představených dvou zadání implantovali již více něž deset příkladů a další dále doplňujeme. Protože máme k dispozici pro různé technologie různá řešení, můžeme studentům nabídnout jejich srovnání. Celé řešení je detailně dokumentováno a spolu s komplexními modely všech fází vývoje ukázkových aplikací v jazyce UML je součástí výukového materiálu a je k dispozici studentům. Důležitou součástí výukového materiálu je také návod jak implementované aplikace nainstalovat a spustit. Většina popisovaných technologií potřebuje ke svému provozu celou řadu aplikací jako webový server nebo databázový server. V dnešní době existuje celá řada takových aplikací. Snažili jsme se studentům poskytnout obecný přehled dostupných technologiích a popsat jejich výhody a nevýhody. Tento
52
Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček
jejich popis, stejně jako tyto produkty samotné (případně odkazy na ně) jsou součástí výukového materiálu.
5
Další práce
Představený výukový materiál je i nadále tvořen. Ne všechny části jsou zcela hotovy, navíc jsou průběžně přidávány další rozšíření. Výukový materiál je připravován s podporou agentury FRVŠ (jde o projekt skupiny F1 a s názvem: Podpora výuky softwarového inženýrství a informačních technologií). Jeho kompletní řešení bude k dispozici do konce tohoto roku. Jak již bylo uvedeno, jedním z hlavních prostředků, kterým jsou upevňovány a testovány znalosti studentů jsou právě projekty, které studenti samostatně řeší. Důležitou součástí řešení konkrétních projektů je také jejich veřejná prezentace. Vzhledem k relativně velkému počtu studentů v bakalářských předmětech jsou však možnosti osobní prezentace řešení projektů před ostatními studenty a vyučujícími značně omezeny jak časově, tak i dostupnou prezentační technikou. Aby bylo možné dát prostor pro prezentaci výsledků práce všech studentů a zároveň ve snaze podpořit týmovou práci se jako účelné jeví zadávání komplexnějších projektů řešených malými skupinami studentů (okolo 3 lidí). Prezentace těchto projektů je pak rozdělena na publikování výsledků na webových stránkách projektu a na krátkou obhajobu řešení před ostatními studenty. K tomuto účelu v rámci běžících diplomových prací na katedře informatiky vzniká také systém pro prezentaci projektů a pro podporu týmové práce na jejich řešení. Pro rozjezd takového systému a jeho zapojení do běžné výuky je potřeba připravit dostatečnou sadu zadání a ukázkové příklady. Vytvořený výukový materiál je pak dobrý základ pro takový systém. Navíc v návaznosti na tvořený výukový materiál byly zadáno několik témat bakalářských prací, jejichž výsledkem bude vytvoření dalších ukázkových příkladů a nebo použití jiných technologií a nástrojů pro řešení popsaných úloh.
6
Závěr
Vytvořený výukový materiál poskytuje studentům širší rozhled a umožňuje jim lépe porozumět látce, kterou probírají v průběhu studia. Formou bakalářských prací bude projekt i nadále rozšiřován a zdokonalován. Navíc je tento projekt základem pro vytvoření rozsáhlé databáze studentských prací.
7
Literatura
1. Gilmore, Jason. Velká kniha PHP 5 a MySQL. Zoner Press, 2005. ISBN 808681520X. 2. Hibernate. http://www.hibernate.org.
Podpora výuky softwarového inženýrství a informačních systémů
53
3. Jan Ježek, http://www.pcsvet.cz/art/article.php?id=3521, Minulost a budoucnost PHP. 4. Johnson R. http://www.theserverside.com/articles/article.tss?l=SpringFramework, Introduction to the Spring Framework. 5. Kačmář D.: Programuje .NET aplikace ve Visual Studiu .NET. Computer Press 2001, ISBN 80-7226-569-5. 6. Microsoft, http://msdn.microsoft.com. 7. Rasmus Lerdorf, Programming PHP, O'Reilly&Associates, Inc., 2002. ISBN 1565926102. 8. Sun Microsystem, http://Java.sun.com/developer/onlineTraining/Programming/JDCBook/perf2.html #jit 9. Sun Microsystem, http://Java.sun.com/products/ejb/.
Issues in Static of Component Issues Verification in Static Verification Substitutability of Component Substitutability PremyslBrada Brada Přemysl Department ComputerScience Science and and Engineering, Department of of Computer Engineering, UniversityofofWest West Bohemia University BohemiaininPilsen, Pilsen, 30614Pilsen, Pilsen, Czech 30614 Czech Republic Republic [email protected][email protected]
Abstract. Components are an efficient means of implementing software application, ranging from mobile/embedded to enterprise-wide, since they enable to assemble functionality in the form of interdependent but separately maintained parts. This enables fine-grained upgrades where only the affected components are replaced. In this paper we argue that the replacement must include a careful verification step otherwise an incompatible component may break the whole application. We discuss the characteristics of Java-based component models (EJB, OSGi) with respect to this verification and describe a case study of a system which applies static subtyping checks to ensure safe upgrades of Enterprise JavaBeans components.
1. Introduction The trend in building modern software systems is towards assembling – rather than developing – the bulk of their functionality. This means to (re)use, as much as practical, parts that already have been built: libraries, frameworks, components. Components and plugins in particular are an efficient means since they enable to create applications as frameworks and tailor and extend their functionality by simply putting together a required set of functionalities in the form of interdependent components. The term component is used here in the standard definition [9,10] as a blackbox software part whose interface defines both its provided and required side. This interpretation holds for a wide range of component platforms, from those targeted to embedded systems like OSGi [7] to enterprise-grade systems [3, 4]. Unlike standard software, bug fixing and upgrading is easier in component-based applications since only the affected components have to be replaced, not the whole application. But this flexibility comes at a price – the replacement must be done very carefully otherwise an incompatible component may be introduced, breaking the dependencies within the whole application and consequently degrading its functionality. Techniques and tools for checking the replacement components for substitutability are therefore needed. In this paper we analyse the options in checking component substitutability using type relations and describe a system which applies this principle on the Enterprise JavaBeans (EJB) component model. The following section deals with the principles
c Václav Snášel, editor: Objekty 2005, pp. 54–63, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
2
Premysl Brada Issues in Static Verification of Component Substitutability
55
of checking components for safe replacement. Section 3 describes the details of comparing EJB components for substitutability as implemented in a prototype tool. The Conclusion contains plans for further work.
2. Principles of Component Substitution Checks In the introduction we stated the need for verifying component substitutability. Many ad-hoc approaches exist that attempt to ensure this, ranging from regression testing to intercepting incorrect functioning at run-time in fault-tolerant systems [6]. In this section we present a formal underpinning of a method which tests two components for substitutability a-priori. The goal is applicability in fully automated upgrades. The basic principle of substitutability was defined by Wegner and Zdonik [11] as follows: a substitute component should be usable whenever the current one was expected, without the client noticing it. Type systems and the subtype relation [2] in particular are used to ensure safe substitutability in (object-oriented) programming languages: subtype instances can be bound to variables declared as supertypes because they provide a superset of features. Since component interfaces are defined in terms of programming language constructs (interface types, attributes, etc.) subtyping can similarly be used for component compatibility evaluation. Our approach therefore says that component B can replace component A if B’s type is a subtype of A. 2.1. Component Type Differences To determine whether a structured data type B is a subtype of A (denoted B <: A), one needs to compare the content of the types. The subtyping rules for type constructs of the content parts [2] are used recursively until primitive types are reached, for which the rules are defined by enumeration (e.g. short <: long). The result of comparing two primitive types a and b can be described by the character of changes between them. We capture these as classification values returned by a function diff(a,b) which computes the difference between types a and b: − none
if b = a
− insertion
if a is not defined but b is
− specialization
if b <: a
− deletion
if a is defined but b is not
− generalization
if a <: b
− mutation
if b contains both ins/spec and del/gen differences
− unknown
if b cannot be compared to a (e.g. due to recursive cycles)
Let us say we have two versions of a Java interface called Logging (see Table 1) and want to compare just its constituent methods. The write() method is un-
56
Přemysl Brada
Issues in Static Verification of Component Substitutability
3
changed in version 2, its difference is therefore none. There is no writeMany() method in the first version, thus there is insertion difference in this method. Since short <: long, the last method exhibits a generalization difference. Table 1. Example interface types with constituent parts interface Logging { // v1 void write(String msg); short countLogItems(); }
Comparison of structured types is then in our approach done by combining the differences of their constituent parts. The combination of two difference values is given by their relative priority. The priorities are as follows, in increasing order: 1.
none
2.
insertion, deletion
3.
specialization, generalization
4.
mutation
5.
unknown
The general combination rule is that higher priority values override the lower ones, with one exception: the mutual combination of the values at the second as well as third level results in mutation. For example, the values are combined as none ⊕ insertion = insertion or insertion ⊕ generalization = mutation. When determining the difference between the versions of the Logging interface, we proceed as follows: the combined differences of the first two methods form a specialization, and its combination with last method’s generalization results in mutation. 2.2. Component Substitutability Defined by Differences When we want to ensure that component B can safely replace component A, we need to determine that B <: A. In this case, we work at the level of whole component interfaces where the provided and required roles of their parts (e.g. the business interface vs. the ejb-ref business references of an EJB, or the types in Export-Package vs. Import-Package declarations of an OSGi bundle) have to be considered. The formalism that captures the effect of these roles in type theory is contravariance: B is a subtype of A only if the provided part of B is a superset and the required part is a subset of corresponding A’s parts. This can be re-phrased as the (obvious) requirement that B provides at least the same functionality and requires at most as much as A did. Using the difference values we therefore say that B is a (strict) substitute for A if and only if
4
Premysl Brada Issues in Static Verification of Component Substitutability
57
− diff(Aprov,Bprov) ∈ { none, insertion, specialization }, and − diff(Areq,Breq) ∈ { none, deletion, generalization } . In simple words, functionality must not change or can only be added at the client-side of component’s interface. On the other hand, reduction is the only allowed change at the side of component’s dependencies. For example, if Logging was the business interface of an EJB component, version 2 could not replace version 1 because of the mutation change – clients compiled for version 1 would not mind that the writeMany() method was inserted but would have problems with the long return values of the changed countLogItems() since these cannot be assigned to variables of the short type. 2.3. Issues with Statically Typed Languages The above example points to a discrepancy between theory and practice when subtyping-based upgrade checks are applied on component platforms which use static type checking and binding – for example in the Java and C++ languages. The problem is that we can have formally substitutable types X <: Y whose use nevertheless causes runtime errors. Let us take the example of interface Reading from Table 2 below. Version 2 is a subtype of version 1 and if it was used as a component’s provided interface, version 2 should be a “clean” substitute for version 1. Table 2. Subtypes that are not substitutable statically interface Reading { // v1 long readInteger(); String readStr(short chars); }
However, when Reading version 1 is used in a Java client, and a server component is upgraded to version 2 of the interface, a NoSuchMethodError is thrown at runtime when readInteger() is called. This is because version 2 contains no method with exactly the same prototype (definition type) as the one client tries to call, namely one that returns long. The JVM does not dynamically adapt the call to the subtype-safe new version of the method. If we want the new version to work, it has to contain both versions of the changed methods; this is however possible usually only if the methods differ in parameter types since in many languages, differences in return type are insufficient for distinguishing overridden methods. A completely different situation is with dynamically typed languages where the type of the object to be used is determined upon its use (for example, SmallTalk, JavaScript or PHP). Components in these languages have no problems with the upgrade since the runtime needs only to match method name and parameter number, and performs type casts as needed. We can conclude that the subtyping-based definition of substitutability can be fully used only with dynamically typed languages.
58
Přemysl Brada
Issues in Static Verification of Component Substitutability
5
With respect to the definitions in the previous sub-section, these issues lead to the following refinement of the substitutability rule in case of statically bound languages: component B is a (strict) substitute for A if and only if − diff(Aprov,Bprov) ∈ { none, insertion }, and − diff(Areq,Breq) ∈ { none, deletion } . This changed rule thus says that the replacement component type can only add new features on the provided part of its interface (leaving the existing ones unchanged), and only remove features on the required side. Subtype-related specialization and generalization changes are unfortunately not allowed.
3. Case Study: Substitutability for Enterprise JavaBeans One of the appealing application areas of substitutability checks are Enterprise JavaBeans (EJB) applications, since the EJB model is widely used in industry and application robustness is highly desirable. In this section we describe how substitutability checking is done for EJBs and the caveats that have to be observed in this process. The same process (subsection 3.2) can be applied to other component platforms like OSGi [7]. The Enterprise JavaBeans meta-model version 2.1 [4] defines three component types: Session, Entity, and MessageDriven beans. These types share some functionality features accessible by component’s clients or suppliers (business interfaces, home interfaces, business references, referenced environment entries, referenced resource managers, etc.) and differ in a few (EntityBeans have attributes while SessionBeans can have a web service endpoint, for example). Each component type has as well some non-functional “tags” like state and transaction (SessionBeans), persistence and reentrancy (Entity), or message type (MessageDriven). The upcoming version 3.0 of EJB [5] simplifies the model from the programmer’s point of view, nevertheless all of the 2.1 features and tags are available. 3.1. Problems in Modeling EJB Components Our approach to substitutability checking depends on a completeness of the component interface specifications, because the evaluation of incomplete interface definitions allows incompatibilities to slip in. Our study [1] of the EJB 2.1 platform has shown that it has several weaknesses from the blackbox component point of view1. Firstly, information about some features is available both in the deployment descriptor and in the component code via introspection, resulting in duplication and making EJB use prone to errors; the prime example is the specification of business and home interfaces, or the specification of
1
That is, when the component is studied in its distribution form (the .jar file) without access to the original source code.
6
Premysl Brada Issues in Static Verification of Component Substitutability
59
referenced component meta-type (the ejb-ref-type element in the deployment descriptor) which is in our opinion completely irrelevant. Even worse, there are several feature traits which can be reliably found only by thorough analysis of the component source code (introspection is insufficient), for example the messages consumed in MessageDriven beans or attributes in case of bean-managed persistence Entity beans. This means that checking substitutability of EJB components is fundamentally difficult and unreliable. To overcome this deficiency, either the checks have to be done in part manually, or the EJB component model would have to be re-designed (which is unlikely). 3.2. Substitutability Checks for EJB Components Despite the problems mentioned above, we have defined subtyping rules for EJBs that cover all of the available elements of their interface. The rules come in two complementary sets: one covers the functionality features, the other one the non-functional tags attached to component types. Tables 3 and 4 show the rules for features and tags. Because a feature has either provided (P) or required (R) role, the rules define the difference value that is necessary from the substitutability point of view. Table 3. EJB feature subtyping rules (E = Entity, S = Session, M = MessageDriven, A = all)
Feature attribute business interface business reference environment entry home interface home reference message activation message consumed message destination ref resource reference resource manager security role timer service reference web service endpoint web service ref
Bean E A A A A A M M A A A A A S A
Role P+R P R P+R P R P P R R R P R P R
Type compared Name, type Java interface Java interface Name, type Java interface Java interface Java interface Type Name, type, tag Name, type Name, type, tag Name Java interface Java interface Name, interface
The Type compared column describes what is compared – whether a Java type, name of the feature, or some other aspect. Message destinations and resource manager reference features have also additional tags which have to be compared using rules defined separately [8]. The message activation feature defines messaging properties only in the special case of JMS as message carrier, and is therefore not included in the
60
Přemysl Brada
Issues in Static Verification of Component Substitutability
7
comparison (for other carriers, completely different set of properties could be specified, rendering the comparison useless). Table 4. EJB tags subtyping rules
Tag message type persistence reentrancy schema security id state transaction
Bean M E E E A S S,M
Type compared Java Enumeration Enumeration Name Enumeration Enumeration Enumeration
Two tags are neglected in the subtyping comparison. The “schema” tag contains a name of the database schema of an entity bean’s attributes, but the content of the schema is unavailable. Security ID itself does not have an effect on component’s functionality, and the accessible component’s features defined by the ultimately assigned identity cannot be determined until the component is deployed. There are several aspects of checking EJB substitutability that relate to the Java implementation language. Firstly, when interfaces are checked for substitutability, the exceptions thrown by their methods need to be accounted for. Handling of exceptions is similar to that of method return type – ideally the specialization change is allowed, practically only insertion works due to static type binding. Second special case is the void keyword used to denote methods without return type (procedures). Change in the return type between any type and void is classified as mutation because this change would result in runtime errors even in a dynamically bound language: the client which expects a return value would be suddenly denied any value at all. The algorithm of checking EJB components A and B for substitution is as follows: 1) Check the names and type of the components (Session, Entity, MessageDriven) for equality. If not equal, exit. 2) Compare the same provided features of A and B according to the Type compared column in Table 3, and save the differences found. 3) Compare equivalent component-wide tags according to Table 4, and save the differences. 4) Compare the same required features according to the Type compared column in Table 3, and save the differences found. 5) Compute the overall difference between the components: i)
Combine all differences of provided features and tags according to subsection 2.1,
ii) Combine all differences of required features in the same way,
8
Premysl Brada Issues in Static Verification of Component Substitutability
61
iii) The difference of the components is given by the diff value combination and contravariance rules, described in subsection 2.2. The overall result of the check is a single difference value at the component type level. If the value is in the { none, insertion, specialization } set then B is a safe substitute for A, at least as far as static type information is concerned. In any other case, replacement is not desirable. 3.3. Implementation of EJB Comparison The substitutability rules and algorithms described in the previous paragraphs can be implemented by automated checking tools. We have designed and implemented a prototype tool which enables pair-wise checking of EJBs. The tool operates on two JAR files which each contains a set of EJB components. It reads the data of designated components, performs the comparison and outputs a XML file with the comparison result.
Fig. 1. Comparison tool command line
The component data – features and tags – is obtained from two sources: (1) the ejb-jar.xml deployment descriptor, using XML parser and DOM representation, and (2) the component implementation in .class files, using Java introspection mechanism. The data is stored internally in structures defined by the ENT meta-model [1] which makes it easier to analyze component interface and compare its parts. The output contains three information sets, see Fig. 2 on the next page: (1) the differences of the provided and required parts of the EJB interface; (2) the details of differences in individual features and component-wide tags; and (3) the resulting judgement whether the component given as second parameter can safely replace (is a subtype of) the first one.
4. Conclusion The goal of this paper was to describe the options which are available for static verification of component substitutability, with special emphasis on Java-based component platforms. We have described the basis for the appropriate checks, which is the subtype relation of the corresponding parts of the component interface, and re-phrased its rules using simple-to-understand classification of changes in the type contents. Unfor-
62
Přemysl Brada
Issues in Static Verification of Component Substitutability
9
tunately, the practical limitations of static type binding in Java mean that we have to use a restricted form of subtyping for practical applications. At present, we have an implementation of the verification in a command-line tool which operates on the binary distributions of EJB components. Its comparison results are available both as XML output and via an API. We are currently working on a way to integrate this tool into an EJB container so that the checks could be performed when a component is being deployed. Furthermore, we are working on a similar implementation for the OSGi platform, to target embedded component markets.
Fig. 2. Comparison tool output
4.1. Acknowledgements This work was supported by grant from the Grant Agency of the Czech Republic GAČR 102/03/0672 “Methods and tools for verification of embedded computer system fault tolerance”. The author would like to thank his students Pavel Stuna and Lukáš Valenta for their work on the implementation tools, and especially for their feedback and ideas.
10
Premysl Brada Issues in Static Verification of Component Substitutability
63
5. References [1]
Přemysl Brada. The ENT model: a general model for software interface structuring. Technical Report DCSE/TR-2002-10, Department of Computer Science and Engineering, University of West Bohemia, Pilsen, Czech Republic, 2002. [2] Luca Cardelli. Type systems. In Handbook of Computer Science and Engineering, chapter 103. CRC Press, 1997. [3] Object Management Group. CORBA Components, June 2002. Version 3.0. OMG Specification formal/020665. [4] Sun Microsystems. Enterprise JavaBeans Specification, Version 2.1. 2003 [5] Sun Microsystems. Enterprise JavaBeans, Version 3.0. Public Draft, June 2005 [6] Herrmann Kopetz. Real-Time Systems, Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, 1987. [7] The Open Services Gateway Initiative. OSGi Service Platform, Release 3. IOS Press, March 2003. [8] Pavel Stuna. Ověřování nahraditelnosti EJB komponent (in Czech). Master thesis, University of West Bohemia, Pilsen, Czech Republic, 2005. [9] Clemens Szyperski. Component Software. ACM Press, Addison-Wesley, 1998. [10] Object Management Group: UML 2.0 Superstructure Specification. OMG Adopted Specification, ptc/03-08-02, 2003. [11] Peter Wegner and Stanley B. Zdonik. Inheritance as an incremental modification mechanism or what like is and isn’t like. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP), pages 55–77. Springer-Verlag, 1988.
Agilní Agilní modelování modelování Alena Buchalcevová Buchalcevová1 Alena 1 Katedra informačních VŠEPraha Praha Katedra informačníchtechnologií technologií VŠE nám. Churchilla 4, 4,Praha Praha nám.W. W.Churchilla 33 [email protected][email protected]
Abstrakt. Příspěvek se zabývá významem modelování při vývoji softwaru a ukazuje jak vyvrátit některé mýty spojené s modelováním. Představuje sadu principů a praktik, které jejich autor, Scott Ambler, nazývá Agilní modelování. Agilní modelování není samostatná metodika, ale je možné ji využít v rámci jiných ucelených metodik vývoje softwaru jako RUP, XP, FDD a dalších. Příspěvek ukazuje, jak je možné při vývoji softwaru využít přínosů modelování a přitom vyvíjet agilně a dodávat fungující software. Klíčová slova: modelování, programování, vývoj softwaru
1
metodika,
Agilní
modelování,
Extrémní
Význam modelování při vývoji softwaru
Na celou historii vývoje softwaru můžeme pohlížet jako na boj se složitostí. Na jedné straně se do tohoto boje nasazují stále výkonnější nástroje, na druhé straně rostou požadavky na software (rozsah, kvalita, rychlost vývoje, flexibilita, přívětivost a další). A tak je složitost vývoje softwaru stále klíčovým problémem a je také jednou z příčin velkého počtu neúspěšných softwarových projektů. Jedním z nástrojů, které nám pomáhají bojovat se složitostí, je modelování. Modelování představuje činnost, která probíhá v rámci fáze analýzy a návrhu a jejímž výsledkem je jeden či více modelů. Model představuje abstraktní obraz reality, tedy oblasti, ze které pochází úloha, jež má být řešena informačním resp. programovým systémem [18]. „Smyslem modelování jako základního principu metodiky vývoje IS je především zabezpečit smysluplnost a správnost obsahu informačního systému. Platí-li, že informační systém je modelem reality, potom jeho správnost je dána tím, jak správně a přesně modeluje reálné skutečnosti.“[17] Modelování umožňuje řešit i otázku velkého rozsahu softwarových projektů. Potřebujeme-li rozdělit práci mezi několik dílčích týmů, je kvalitní model nutným předpokladem efektivní spolupráce [16]. Model poskytuje informace o kontextu řešené části v rámci celého systému a slouží také jako prostředek komunikace mezi členy týmu. Modely slouží také jako dokumentace řešení a v poslední době se stále více používají pro automatické generování kódu v rámci Modelem řízené architektury (Model Driven Architecture) MDA.
c Václav Snášel, editor: Objekty 2005, pp. 64–73, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Agilní modelování
2
65
Mýty o modelování a jak je překonat
Přestože modelování prosazují standardizační organizace jako OMG a IEEE, výrobci CASE nástrojů a vývojových nástrojů a je součástí většiny metodik, v praxi se často neprovádí. Jednou z příčin jsou „mýty o modelování“ jak je formuloval Scott Ambler v [1]. Podívejme se na jednotlivé mýty podrobněji. Mýtus 1: Modelování je vždy svázáno s dokumentací Velmi častým a nebezpečným mýtem je přesvědčení, že modelování je vždy svázáno s dokumentací. Vývojáři nechtějí ztrácet čas tvorbou dokumentace, a tak nemodelují. Výsledkem je potom nízká kvalita vytvářených systémů. Náčrtky na papíře, obrázky na tabuli, CRC karty, nákresy uživatelského rozhraní nejsou dokumenty, ale přesto představují hodnotné modely. Modelování plní podobnou úlohu jako plánování. Při plánování není hodnotou plán samotný, ale proces plánování. Stejně tak při modelování je důležitý proces modelování. Mýtus 2: Je možné vše namodelovat předem a správně Druhý mýtus přeceňuje význam modelů vytvořených předem. Jeho zastánci věří, že je možné namodelovat vše předem a správně. Výsledkem je potom obrovské množství dokumentace namísto fungujícího softwaru. Tento mýtus je spojen s běžnou praxí zmrazení požadavků na začátku životního cyklu vývoje, což vede k tomu, že dodané systémy neodpovídají skutečným potřebám uživatelů. Pro překonání tohoto mýtu je třeba si uvědomit, že i když bychom předem vytvořili sebelepší model, při vývoji dochází ke změnám, takže po čase model již nebude odpovídat kódu. Řešením je iterativní přístup - trochu modelování, trochu kódování, trochu testování a hlavně nasazení fungující verze softwaru a zpětná vazba od zákazníka. Mýtus 3: Modelování je spojeno s rigorózními metodikami Tento mýtus souvisí s prvním mýtem. Pokud si uvědomíme rozdíl mezi modelem a dokumentací, můžeme modelovat agilním způsobem, to znamená vytvářet jednoduché modely a používat jednoduché nástroje. Mýtus 4: Při vývoji softwaru je třeba zmrazit požadavky Pokud se zmrazí požadavky na začátku životního cyklu, pak nejspíš bude dodáno to, co bylo požadováno, ale pravděpodobně ne to, co je třeba. Mýtus 5: Návrh (model) je vytesán do kamene Zastánci tohoto mýtu požadují, aby prvotní návrh zůstal neměnný. Pokud však dojde ke změnám, bude návrh zastaralý a neaktuální. Programátoři pak takový návrh ignorují. Nikdo, ani nejlepší návrhář není dokonalý a stejně tak není dokonalé jeho dílo. Pokud se zafixuje návrh, zafixují se také chyby. Mýtus 6: Při modelování je nutné používat CASE nástroj Dalším mýtem při modelování je představa, že pro modelování je nutné používat CASE nástroj, který nejlépe zvládne složité modely. Mnohdy je ale účinnější vytvářet jednoduché modely, které zachytí jen důležité informace. Mýtus 7: Modelování je ztráta času Tento mýtus zastávají zejména nováčci, kteří se orientují jen na kódování. Zkušenější vývojáři vědí, že se produktivita jejich práce zvýší náčrtkem diagramu, vytvořením prototypu atd. Mýtus 8: Základem je datové modelování Datová komunita má historicky poměrně silnou pozici. Datové modelování je důležitý, ale sekundární úkol modelování.
66
Alena Buchalcevová
Mýtus 9: Všichni vývojáři umí modelovat To je nesprávná představa, protože umění modelovat vyžaduje léta zkušeností.
3
Charakteristika metodiky Agilní modelování
O překonání výše uvedených mýtů usiluje metodika Agilní modelování (dříve nazývaná Extrémní modelování, XM). Autorem této metodiky je Scott Ambler. Metodika je také stručně charakterizovaná v [14]. Agilní modelování je metodika založená na praktikách, principech a hodnotách, které jsou odvozeny z hodnot metodiky Extrémní programování (XP) [12]. 3.1
Hodnoty Agilního modelování
Základní hodnoty Agilního modelování jsou převzaty z Extrémního programování. Jsou jimi komunikace, jednoduchost, zpětná vazba a odvaha. Komunikace je při vývoji softwaru velmi důležitá. Jde o komunikaci mezi všemi zainteresovanými (vývojáři, uživateli, projektovými manažery, vedením). Modely jsou důležitým faktorem, který podporuje jednoduchost vytvářeného softwaru i jednoduchost procesu jeho vývoje. Je mnohem jednodušší objasnit myšlenku pomocí obrázku či diagramu než stovkou řádků kódu. Při komunikaci pomocí diagramu lze získat rychle zpětnou vazbu, která je pro vývojáře velmi důležitá. Při vývoji softwaru je třeba mít také odvahu činit rozhodnutí. K hodnotám převzatým z XP přidává Scott Ambler ještě skromnost, kterou chápe jako umění přiznat si, že sám neznám vše, ale ostatní mi mohou být nápomocni. 3.2
Principy Agilního modelování
Agilní modelování opět přebírá některé principy z metodiky Extrémní programování například jednoduchost, otevřená komunikace, cestování nalehko. Kromě toho ale přidává několik specifických modelovacích principů. Pokud je obrázek cennější než tisíc slov, je model cennější než 1024 řádek kódu. Principy agilního modelování uvádí tabulka 1. Tabulka 1. Principy agilního modelování - zdroj [9]
Principy agilního modelování princip Nejdůležitějším úkolem je vytvořit fungující software Druhým nejdůležitějším úkolem je umožnit další práci na projektu
Obsah je mnohem důležitější než
vysvětlení cílem není vytvářet modely, ale vytvořit kvalitní software, který odpovídá potřebám zákazníka vytvořený software musí být natolik robustní, aby jej bylo možné dále rozvíjet, současně je třeba mít k dispozici takovou dokumentaci, aby byl další rozvoj možný každý model může být reprezentován různými
Agilní modelování
Principy agilního modelování princip reprezentace
Jednoduchost Komunikace
Modelovat za určitým účelem Uchopit změnu Změny je třeba dělat přírůstkově Je třeba se učit od druhých Znát své modely
Přizpůsobení metodiky Maximalizovat výnosy z investic Více modelů Otevřená komunikace Důraz na kvalitu
Rychlá zpětná vazba
Cestovat nalehko
Řídit se instinkty lidí
67
vysvětlení způsoby, je třeba vybrat dostačující způsob – aby splnil účel modelování, modely nemusí být tedy perfektní ani nemusí být nutně vytvořené v CASE nástrojích nejjednodušší řešení je nejlepší řešení hlavním smyslem modelování je komunikace mezi členy týmu navzájem i se zákazníky a zájmovými skupinami modely by se měly vytvářet jen když je jasné, pro koho je model určen a proč změny nastávají, je třeba je akceptovat je lepší měnit systém po malých částech než provést jednu všezahrnující změnu nikdo nemůže znát vše, je třeba se učit od druhých a rozvíjet své znalosti existují různé modely, které odrážejí pohledy na systém, je třeba znát jejich silné a slabé stránky a efektivně je využívat metodiku je třeba přizpůsobit podle konkrétních podmínek je třeba maximálně zhodnotit vynaložené prostředky k dispozici je široké spektrum modelů , je třeba použít nejvhodnější lidé se musí cítit volní, díky otevřené komunikaci mohou dělat lepší rozhodnutí je třeba se zaměřovat na kvalitu software v celém procesu jeho vývoje, kvalitní software může splnit požadavky zákazníka, je snazší jej měnit nejcennější při vývoji je rychlá zpětná vazba, prostředkem pro její zajištění je – krátké iterace, prototypy, uživatel součástí týmu tento princip vychází z paralely mezi vývojem software a slézáním hory, je třeba vytvářet jen tolik modelů a dokumentace, aby je člověk mohl vzít s sebou lidé se snaží dělat vše pro dobro věci, je dobré využít jejich tacit znalostí
68
3.3
Alena Buchalcevová
Praktiky Agilního modelování
Praktiky agilního modelování jsou uvedeny v tabulce 2. Tabulka 2. Praktiky agilního modelování - zdroj [9]
Praktiky agilního modelování praktika Aktivní účast investorů
Používání standardů při modelování Využívání vzorů Používání správných artefaktů Kolektivní vlastnictví
Testovat modely Paralelní vytváření různých modelů Jednoduchý obsah Jednoduché zobrazení modelů
vysvětlení úspěch projektu často závisí na aktivní účasti investorů – vedení podniku, operativní pracovníci, jiné týmy je třeba používat obecné standardy modelování
je třeba používat architektonické, návrhové a analytické vzory artefaktů je velké množství a je třeba vybrat vhodný pro daný účel odvozena od praktiky extrémního programování umožňuje každému pracovat na libovolném modelu testování je základní prostředek vytváření kvalitního software, je třeba testovat i modely modely reprezentují různé pohledy na vytvářený systém, je třeba znát silné a slabé stránky jednotlivých typů modelů a vytvářet více modelů je třeba se snažit o jednoduchost obsahu modelů
Veřejné vystavení modelů
je třeba se snažit o jednoduchost zobrazení modelů, je vhodné používat podmnožinu notace, cílem je jednoduchý model, který zachycuje klíčové rysy většina vytvářených modelů je dočasná, když splní svůj účel, je třeba je zrušit podporuje princip otevřené komunikace
Formalizace požadovaných modelů
některé modely jsou požadovány např. vedením, ty je třeba formálně upravit
Přechod na jiné artefakty
protože modely reprezentují různé pohledy na vytvářený systém a vzájemně se doplňují, je třeba přecházet mezi modely souvisí s přírůstkovým vývojem, není možné vytvořit detailní model předem, ale vytváří se postupně smyslem modelování je komunikace v týmu, se zákazníkem, s vedením
Odstranění dočasných modelů
Modelování v malých přírůstcích
Modelování pro komunikaci
Agilní modelování
Praktiky agilního modelování praktika Modelování pro pochopení Je nebezpečné modelovat sám
Testování modelů kódem Znovupoužití existujících zdrojů Úprava jen, když je to nezbytné Používání nejjednodušších nástrojů
4
69
vysvětlení smyslem modelování je pochopení problému modelování je činnost, která vyžaduje abstrakci, zkušenosti, existuje více možností, jak model navrhnout, proto je vhodné modelovat s jinými model je abstrakce, pro zjištění, zda bude skutečně fungovat, je třeba napsat kód je třeba využívat hotové modely, vzory úpravy modelů jsou náročné a měly by se realizovat, jen když je to nezbytně nutné většina modelů může být malována na tabuli
Co je agilní model?
Abychom pochopili agilní modelování, je třeba pochopit rozdíl mezi modelem a agilním modelem. Model je abstrakce, která popisuje jeden nebo více aspektů problému. V tradičním pojetí je model chápán jako několik diagramů a odpovídající dokumentace. Na druhé straně za modely jsou považovány také nevizuální artefakty jako CRC karty, popis byznys pravidel a textový popis byznys procesů. Agilní model je takový model, který je právě dostatečně dobrý („just barely good enough“). Tuto podmínku splňuje model pokud: 1. Plní svůj účel Účel modelování může být různý. Někdy slouží model k domluvě mezi členy týmu a se zákazníkem, jindy je na jeho základě definován rozsah projektu a nebo slouží pro pochopení věcné oblasti. 2. Je pochopitelný Důležitým předpokladem účelnosti modelu je, aby byl pochopen cílovým subjektem. Model požadavků musí být psán jazykem věcné oblasti, ale model technologické architektury může používat technické termíny. Use case diagram nemá pro uživatele, který nezná notaci, hodnotu. Důležitým kritériem čitelnosti modelu je dodržování konvencí a doporučení pro modelování. 3. Je dostatečně přesný Model často nemusí být 100% přesný, aby splnil svůj účel. Důležité je uvažovat o nákladech na 100% přesnost. 4. Je dostatečně konzistentní Model nemusí být perfektně konzistentní, je třeba najít správný poměr mezi náklady na perfektní konzistenci a ztrátami z nedostatečné konzistence. 5. Je dostatečně detailní Podle účelu modelu je třeba stanovit míru detailu.
70
Alena Buchalcevová
6. Přináší kladnou hodnotu Přínosy vytvoření určitého artefaktu musí převážit náklady na jeho vytvoření a údržbu, kam je třeba zařadit licence CASE nástroje, zaškolení, čas na tvorbu modelu a další. 7. Je co možná nejjednodušší Jednoduchost je ovlivněna úrovní detailu a rozsahem notace. Proto je vhodné zvolit podmnožinu notace.
5
Vztah Agilního modelování k jiným metodikám
Agilní modelování není ucelená metodika, ale poskytuje sadu principů a praktik, které se vztahují k modelování. Agilní modelování tak může být začleněno jak do tradičních metodik, tak do agilních metodik. Spojení Agilního modelování s metodikou Rational Unified Process (RUP) je popsáno například v [7]. Stejně tak je možné využít Agilní modelování i spolu s dalšími agilními metodikami jako například Scrum, Feature Driven Development (FDD)[6], [15] a nebo Extrémní programování.
Obr.1. Agilní modelování doplňuje ostatní softwarové procesy (metodiky) – zdroj [9]
6
Agilní modelem řízený vývoj
Autor metodiku neustále rozvíjí. S prosazováním Modelem řízené architektury (MDA) představuje Agilní modelem řízený vývoj (Agile Model Driven Development AMDD) [5]. Agilní modelem řízený vývoj je iterativní přístup, který místo vytváření modelů před kódováním vytváří agilní, právě dostatečné modely v jednotlivých iteracích. Schéma modelů používaných v AMDD a jejich posloupnost zachycuje obrázek 2.
Agilní modelování
71
Obr. 2. Schéma modelů v rámci AMDD - zdroj [5].
Během prvního týdne práce na projektu se provádí Úvodní modelování (Initial Modeling), které zahrnuje Úvodní model požadavků (Initial Requirements Model) a Úvodní architektonický model (Initial Architectural Model). Pro modelování požadavků doporučuje Ambler následující modely: • Model užití (Usage model), • Úvodní doménový model (Initial domain model), • Model uživatelského rozhraní (User interface model). Každý z těchto tří typů modelů může mít různou podobu, která závisí na tom, v rámci které metodiky je Agilní modelování použito. Tak například Model užití (Usage model) může být tvořen základními Případy užití (Use case) pokud je hlavní metodikou RUP a nebo seznamem užitných vlastností, pokud agilně modelujeme v
72
Alena Buchalcevová
rámci metodiky Feature Driven Development (FDD). Používáme-li Agilní modelování v rámci Extrémního programování, pak vyjádříme požadavky na systém v podobě „user stories“. Stejně tak Úvodní doménový model může vystupovat v podobě kolekce CRC karet nebo konceptuálního UML diagramu tříd či datového modelu. Účelem vytváření architektonického modelu je definovat architekturu, která povede k fungujícímu systému. Pro modelování architektury je možné použít různé techniky, ale zatím žádná z nich není převažující. Často je architektura vyjadřována diagramy ve volné formě. Jak postupuje poznání dané oblasti, jsou úvodní modely upravovány. Ale vždy by měly zůstat jen dostatečně dobré. Naproti tomu detailní modelování se provádí až v jednotlivých iteracích v rámci „model storming“ schůzek. Tyto schůzky vznikají neplánovaně, podle potřeby. Dva až tři vývojáři se sejdou a diskutují. Přitom na papír nebo tabuli zaznamenávají návrhy (modely).
7
Závěr
Procesy vývoje softwaru stále nejsou dostatečně zvládnuté. Jsme vystaveni velkému množství přístupů, které jsou reprezentovány různými metodikami. Žádná z nich ovšem není všeobjímající a použitelná na všechny případy. Autorka doufá, že příspěvek ukázal, jaký je význam modelování při vývoji softwaru a jak je efektivně používat. Ukazuje se však, že agilní přístup k modelování vyžaduje nový typ vývojářů. Místo specialistů na modelování, specialistů na kódování a specialistů na testování potřebujeme generalisty, kteří umějí jak modelovat, tak kódovat a testovat.
Reference 1. 2. 3. 4.
Ambler, S. W.: Debunking Modeling Myths, August 2001, Software Development. Ambler, S.W.: The Fragile Manifesto, Software Development, August 2002. Ambler, S.W.: Something’s Gotta Give, Software Development, March 2003. Ambler, S. W.: Agile Architectural Modeling. Dostupný z WWW: http://www.agilemodeling.com/essays/agileArchitecture.htm 5. Ambler, S.W.: Agile Model Driven Development (AMDD), Dostupný z WWW:http://www.agilemodeling.com/essays/amdd.htm 6. Ambler, S.: Agile Modeling and Feature Driven Development: Not just another agile methodology, Agile Modeling, May 2002. 7. Ambler, S.: Agile Modeling and the Unified Process, Agile Modeling, 2001. 8. Ambler, S. W.: Architecture and Architecture Modeling Techniques, 2002. 9. Ambler, S. W.: Introduction to Agile Modeling, Dostupný z WWW: http://www.agilemodeling.com/essays/introductionToAM.htm 10. Ambler, S.W.: Agile Software Development. Dostupný z WWW: http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
Agilní modelování
73
11. Ambler, S.W.: Examining the Model Driven Architecture (MDA). Dostupný z WWW:http://www.agilemodeling.com/shared/mda.pdf 12. Beck, K.: Extrémní programování, Grada 2002, ISBN 80-247-0300-9 13. Buchalcevová, A.: Agilní metodiky, In: Objekty 2002, ČZU Praha, 2002, ISBN 80-213-0947-4. 14. Buchalcevová, A.: Metodiky vývoje a údržby informačních systémů, Grada, 2005, ISBN 80-247-1075-7. 15. Buchalcevová, A.: Metodika feature-driven development neopouští modelování a procesy, a přesto přináší výhody agilního vývoje, Tvorba softwaru 2005 16. Carda A., Merunka V., Polák J.: Umění systémového návrhu - objektově orientovaná tvorba informačních systémů pomocí původní metody BORM. Grada, Praha 2003. ISBN 80-247-0424-2. 17. Chlapek D., Řepa V. : Materiály ke strukturované anylýze, skripta VŠE, 1. vyd. Praha 1997, ISBN 80-7079-60-4 18. Řepa, V.: Analýza a návrh informačních systémů, 1. vyd Praha: Ekopress 1999, ISBN 80-86119-13-0
Izolácia všeobecných vzoru Composite Izolácia všeobecných častí častí vzoru Composite Jaroslav Jakubík Jaroslav Jakubík Ústav informatiky aÚstav softvérového inžinierstva, FIIT, Slovenská technická univerzita v informatiky a softvérového inžinierstva, FIIT, Bratislave Slovenská technická univerzita v Bratislave, Ilkovičová 3, Ilkovičová 16, Bratislava, Slovensko 8423,16,842 Bratislava, Slovensko [email protected][email protected]
Abstrakt. Existuje málo riešení znovupoužitia existujúcich implementácií návrhových vzorov. V predkladanom článku predstavujeme experimenty s izolovaním všeobecných častí návrhového vzoru Composite. Riešenie porovnávame s existujúcim riešením v knižnici DPL v jazyku Beta a s riešením realizovaným formou schém vo frameworku FACE. Experiment s oddelením všeobecných častí od doménovo závislých častí sme realizovali nad obomi alternatívami vzoru Composite, bezpečnou i transparentnou. Navrhnuté riešenie je implementované v jazyku C++ s využitím viacnásobného dedenia a mechanizmu šablón. Oddelenie všeobecnej a doménovo závislej časti podporuje viditeľnosť vzoru v návrhu i implementácií aplikácie, umožňuje implicitné použitie mikroarchitektúr a podporuje znovupoužitie predimplementovaných častí návrhového vzoru. Klíčová slova: návrhový vzor, Composite, skladba, znovupoužitie, doménovo závislá časť vzoru
1
Úvod
Návrhové vzory sú abstrakciou vytvorenou z mnohých skúseností vývojárov pri riešení opakujúcich sa návrhových problémov v rôznom kontexte [6]. Mnoho odborníkov, vývojárov, návrhárov a architektov v súčasnosti využíva výhody návrhových vzorov. Najmä v oblasti objektovo – orientovaného vývoja aplikácií existuje mnoho publikácií, návodov a materiálov napr. [2][3] ako a kedy použiť ten ktorý návrhový vzor. Vo väčšine z týchto kníh nie je spomenutá jedna zo základných myšlienok objektovo – orientovaného prístupu k vývoju aplikácií a to znovupoužitie zdrojového kódu. Prečo pri každom použití návrhového vzoru musíme vzor implementovať od úplného začiatku? Nedá sa vzor rozdeliť na dve nezávislé časti, z ktorých prvá bude súčasťou znovupoužiteľnej knižnice a druhá zameraná na doménovú oblasť, pomocou ktorej prispôsobíme vzor konkrétnej doméne použitia? Nehovoríme len o 23 vzoroch z [3], chceme uvažovať všeobecne o použití návrhových vzorov, ktorých počet vzrástol po vydaní [3] v roku 1993. Neustále vznikajú nové katalógy, publikácie a články zverejňujúce ďalšie vzory, či už ako modifikáciu pôvodných 23 vzorov, alebo vzory nové, postavené na inom základe napr. [2]. Využitie jediného z množstva existujúcich vzorov si vyžadujú znalosť detailov mnohokrát nesúvisiacich priamo s použitím návrhového vzoru v samotnej
c Václav Snášel, editor: Objekty 2005, pp. 74–84, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Izolácia všeobecných častí vzoru Composite
75
implementácii. Nehovoríme o procese návrhu, ktorý si naopak vyžaduje znalosti spojené s návrhovými vzormi (čo, ako, kedy riešia, ako a prečo ich použiť/nepoužiť a ďalšie), sústredíme sa na samotnú implementáciu, kedy transformujeme návrhový model do vykonateľného zdrojového kódu. V nasledujúcich častiach článku sa pokúsime načrtnúť proces rozdelenia návrhového vzoru Composite na doménovo závislú a všeobecnú časť. V kapitole 2 uvedieme dva odlišné varianty návrhového vzoru Composite so zameraním na implementačné detaily. V kapitole 3 porovnáme nami navrhované riešenie s podobným riešením formou knižnice vzorov v jazyku Beta [1] a riešením vo frameworku FACE [5] . V kapitole 4 uvedieme nami navrhované riešenie v jazyku C++ pre oba varianty návrhového vzoru Composite. V kapitole 5 načrtneme možnosti pokračovania a ďalšej práce s knižnicou vzorov. Článok je ukončený záverom v kapitole 6.
2
Variácie vzoru Composite
Medzi najčastejšie používané vzory z [3] patrí aj vzor Composite. Composite zabezpečuje skladanie objektov do stromových štruktúr k vyjadreniu hierarchií. Composite umožňuje klientom zaobchádzať rovnako s jednotlivými objektmi ako aj s ich zloženinami. [3] Návrhový vzor Composite, v doslovnom preklade Skladba, má dve základné implementácie: - bezpečná skladba - transparentná skladba. Hlavný a najmarkantnejší rozdiel je v definovaní metód pre kontajner manažment. Pri bezpečnej skladbe (obr. 1) sú metódy pre pridávanie, odstraňovanie a pristupovanie k prvkom kontajnera definované až na úrovni samotnej triedy Composite. Implementácia je označovaná ako bezpečná, pretože nie je možné volať metódy kontajnera pre elementárne prvky skladby (listy). Na druhej strane je však narušený rovnaký prístup k elementárnym prvkom a k ich zloženinám.
Obr. 1. Bezpečná skladba
Pri transparentnej skladbe (obr. 2) sú metódy pre manažment obsahu kontajnera definované už v triede Component a teda je vytvorené prostredie pre rovnaký prístup aj k listom aj k zloženým štruktúram. Nevýhodou v tomto prípade je nutnosť
76
Jaroslav Jakubík
ošetrenia práce elementárneho prvku ako kontajnera (pridávanie hierarchie listov k inému listu, v ktorom táto funkcionalita vôbec nie je podporovaná).
Obr. 2. Transparentná skladba
Obe implementácie majú svoje výhody ako i nevýhody, ktorými sa na tomto mieste nebudeme zaoberať. Podrobnejšie informácie k obom implementáciám nájdete v [3] a [4]. V oboch implementáciách je na bližší pohľad zrejmé, že práve metódy spojené s manažmentom obsahu kontajnera sa môžu vo viacerých prípadoch použitia vzoru opakovať. V každej inštancii vzoru potrebujeme kontajner pre ukladanie elementárnych prvkov v zloženinách, no potrebujeme i modifikovať, v závislosti od domény použitia, názvoslovie či už ide o názvy tried, metód alebo atribútov. Vzor je teda nepoužiteľný bez predchádzajúcej modifikácie.
3
Existujúce riešenia
Existuje niekoľko málo riešení zaoberajúcich sa oddelením všeobecnej časti od doménovo závislej časti vzoru. V tejto časti sa budeme zaoberať dvomi z nich. V prvom prípade ide o knižnicu znovupoužiteľných častí vzoru v jazyku Beta [1], v druhom prípade o znovupoužitie vzorov vo frameworku Face [5]. 3.1
Composite v knižnici vzorov v jazyku Beta
V [1] autori predstavujú knižnicu pod názvom DPL (Design Pattern Library) v jazyku Beta. Jazyk Beta je špeciálny objektovo – orientovaný programovací jazyk. Beta disponuje špeciálnymi vlastnosťami a prostriedkami ako napríklad virtuálne zoznamy a premenovávanie. Premenovávanie umožňuje dynamicky v runtime meniť názvoslovie používané v konkrétnej triede (resp. objekte). Vytváraný objekt je parametrizovaný názvom
Izolácia všeobecných častí vzoru Composite
77
konkrétnej metódy podobným spôsobom ako parametrizácia šablóny v C++ konkrétnym typom. Virtuálne zoznamy sú používané na definovanie metód v abstraktných triedach alebo rozhraniach počas behu programu. Abstraktné triedy sú opäť parametrizované podobným spôsobom ako šablóny v C++. Autori v plnej miere využili ponúkané prostriedky jazyka Beta a vytvoril kompletnú knižnicu znovupoužiteľných častí vzorov podľa [3]. V [1] môžeme nájsť opis celej knižnice a tiež procesu vytvárania tejto knižnice. Pre naše účely vyberáme časť pre vzor Composite. Vzor ako každý iný v knižnici je rozdelený na dve časti. Prvá časť je súčasťou samotnej knižnice, druhá je doménovo špecifická a teda je súčasťou konkrétnej aplikácie. Vzťahy medzi triedami ako i medzi časťami vzoru sú znázornené na obr. 3.
Obr. 3. Štruktúra použitia vzoru Composite z knižnice DPL v jazyku Beta
78
Jaroslav Jakubík
Metóda Operation je definovaná v triede Component v časti DPL. Ak by autori použili mechanizmus premenovania, obmedzili by sa iba na jedinú doménovo špecifickú metódu, čo v niektorých prípadoch nemusí postačovať. V tomto prípade autori nemohli triedu Component parametrizovať virtuálnym zoznamom, pretože trieda Composite dedí správanie od Component a následne musí implementovať všetky metódy definované v Component. Autori riešili tento problém parametrizáciou metódy Operation. Na základe vstupného parametra metódy Operation je vykonaná doménovo špecifická metóda. Autori presunuli celý kontajner manažment do DPL časti vzoru. 3.2
Vzory vo frameworku Face
V porovnaní s riešením uvedením v [1] je v článku [5] opísaný úplne odlišný prístup pre prácu s návrhovými vzormi. Návrhové vzory resp. ich schémy sú koncentrované vo frameworku FACE. Každý návrhový vzor je rozdelený na prvotnú a doménovú schému. Prvotná schéma definuje abstraktné triedy a ich vzťahy, definuje základné štruktúry doménovej schémy. Pre definovanie prvotnej schémy je použitý špeciálny modelovací jazyk. Doménová schéma je konkrétnou inštanciou prvotnej schémy, ku ktorej dopĺňa doménové triedy a operácie pre definovanie použitia vzoru. FACE (Framework Adaptive Composition Environment) je prostredie pre vytváranie aplikácií jednoduchým skladaním vzorov založenom na modelovacom prístupe. Vytvorenie aplikácie pozostáva z vytvorenia konzistentného a úplného modelu využitím modelovacích primitív definovaných frameworkom. Po zovšeobecnení myšlienky použitia vzorov vo frameworku na úroveň knižnice vzorov je všeobecná časť vzoru umiestnená v primal schéme. Zdrojový kód aplikácie (resp. vzoru) nemôže byť vygenerovaný bez došpecifikovania konkrétnych tried k zodpovedajúcej primal schéme. Rozdiel medzi prístupom s využitím knižnice DPL a pri použití frameworku FACE je v spôsobe generovania vykonateľného kódu. Pri použití DPL je aplikácia vytváraná štandardnými prostriedkami objektovo – orientovaného prístupu (dedenie, asociácia, agregácia atď.), špeciálnymi prostriedkami jazyka Beta (premenovávanie, virtuálne zoznamy atď.) a prostriedkami samotnej knižnice DPL (znovupoužiteľné časti vzorov). Na druhej strane pri použití FACE frameworku je kód aplikácie generovaný až po vytvorení konzistentného modelu. Na obr. 4 je zobrazený model použitia návrhového vzoru Abstract Factory vo FACE frameworku.
Izolácia všeobecných častí vzoru Composite
79
Obr. 4. Schéma použitia návrhového vzoru Abstract Factory vo FACE frameworku
4
Oddelenie všeobecných častí vzoru Composite
V nasledujúcich kapitolách sa pokúsime rozdeliť obe implementácie vzoru Composite (bezpečnú aj transparentnú) na časť všeobecnú a časť doménovo závislú. Na začiatok označíme za doménovo nezávislé časti tried Component, Composite súvisiace s kontajner manažmentom. Trieda Leaf je úplne doménovo závislá. Cieľom je osamostatniť všeobecné časti tried Component a Composite a vhodným spôsobom ich umiestniť do knižnice. Component ale definuje doménové operácie, ktoré nevieme vopred definovať. Operácie definované v Component sú implementované i v triede Composite. V nasledujúcom príklade rozdelíme Component, resp. Composite na CommonComponent, resp. CommonComposite a ConcreteComponent, resp. ConcreteComposite, pričom triedy s prefixom Common predstavujú všeobecné časti vzoru a triedy s prefixom Concrete doménovo závislé časti vzoru. CommonComposite obsahuje podporu pre kontajner manažment ako je výber, odstraňovanie a pristupovanie k prvkom kontajnera. ConcreteComposite zabezpečuje podporu doménovo špecifických operácií. Implementácia triedy CommonComponent je závislá od konkrétneho typu vzoru Composite, môže byť prázdna pri bezpečnej skladbe alebo môže definovať operácie spojené s kontajner manažmentom pri transparentnej skladbe. Až do tohto bodu sme hovorili iba málo o konkrétnom jazyku implementácie. Je ale dôležité vedieť aké prostriedky môžeme v nasledujúcich experimentoch použiť. Použijeme C++ s možnosťami viacnásobného dedenia a mechanizmom šablón.
80
4.1
Jaroslav Jakubík
Oddelenie všeobecných častí vzoru pri bezpečnej skladbe
Pri bezpečnej skladbe nie je nutné definovať žiadnu operáciu v CommonComponent triede. V procese návrhu knižnice nepoznáme doménovo závislé operácie. Tieto operácie sme oddelili do ConcreteComponent, ktorý dedí od CommonComponent. ConcreteComponent potom predstavuje rozhranie, ktoré musí byť implementované všetkými listami i ConcreteComposite triedou. Trieda ConcreteComposite musí dediť operácie spojené s kontajner manažmentom od CommonComposite. Triedu CommonComposite sme parametrizovali ConcreteComponent-om pre došpecifikovanie operácií spojených s kontajner manažmentom. Pomocou tejto parametrizácie sme vyriešili aj chýbajúcu asociáciu medzi triedou Composite a Component definovanú vzorom Composite. Pre parametrizáciu CommonComposite sme využili mechanizmus šablón. Schéma riešenia je zobrazená formou diagramu tried na obr. 5.
Obr. 5. Diagram tried predstaveného riešenia pre bezpečnú skladbu
Vzor sme rozdelili na všeobecnú a doménovo závislú časť. Všeobecnú časť predstavujú triedy CommonComponent, CommonComposite a List. Triedy CommonComposite a List sú implementované pomocou šablón, proces vytvárania inštancií je parametrizovaný konkrétnym komponentom v našom prípade ConcreteComponent. Trieda CommonComposite zaobaľuje operácie nad List-om.
Izolácia všeobecných častí vzoru Composite
81
Konkrétnu časť vzoru predstavujú triedy ConcreteComponent, ConcreteLeaf a ConcreteComposite. ConcreteComposite je vytváraná viacnásobným dedením od ConcreteComponent – doménovo závislé operácie a od CommonComposite – operácie spojené so zaobaľovaním triedy List.
4.2
Oddelenie všeobecných častí vzoru pri transparentnej skladbe
Rozdiel medzi bezpečnou a transparentnou skladbou je v umiestnení definícií metód spojených s kontajner manažmentom. V prípade transparentnej skladby sú metódy definované už v triede Component. Metódy súvisiace s kontajner manažmentom musia byť implementované v každom liste a tiež v triede Composite. Vo všeobecnej časti vzoru musíme modifikovať triedu CommonComponent, ktorá definuje rozhranie (spolu s preddefinovanou implementáciou) kontajner manažment metód. Metódy definované v tejto triede musia byť prekryté v CommonComposite a môžu byť prekryté (podľa typu implementácie v CommonComponent) v každom liste. Štruktúra riešenia je znázornená na obr. 6. Triedu CommonComponent sme vytvorili ako šablónu, ktorá je parametrizovaná typom ConcreteComponent pre dodefinovanie metód spojených s kontajner manažmentom. Tieto metódy môžu obsahovať default implementáciu alebo môžu byť čisté virtuálne metódy bez akejkoľvek implementácie. V našom experimente sme použili čisté virtuálne metódy a definovali sme konkrétne správanie v CommonComposite (štadardne pre pridávanie, odoberanie a pristupovanie prvkov v použitom kontajneri) a v ConcreteLeaf (getChild – s návratovou hodnotou null, a ostatné metódy s prázdnou implementáciou). Trieda ConcreteLeaf dedí od triedy ConcreteComponent, ktorá dedí od CommonComponent s definíciou metód pre kontajner manažment. Tento model implementácie umožňuje implementovať metódy spojené s kontajner manažmentom už v ConcreteComponent alebo v ConcreteLeaf podľa potreby. ConcreteComposite využíva viacnásobné dedenie pre zloženie správania súvisiaceho s kontajner manažmentom CommonComposite a doménovo závislého správania z ConcreteComponent.
82
Jaroslav Jakubík
Obr. 6. Diagram tried predstaveného riešenia pre transparentnú skladbu
Vzťah medzi triedami Component a Composite zo vzoru Composite je v tomto prípade implementovaný cez šablónu CommonComposite, ktorá je parametrizovaná doménovo závislým typom ConcreteComponent.
5
Ďalšie ciele
Tento článok je iba začiatkom v procese vytvárania knižnice znovupoužiteľných častí návrhových vzorov. Na začiatok chceme bližšie analyzovať všetkých 23 návrhových vzorov podobným spôsobom ako vzor Composite. Cieľom je izolovať všeobecné časti všetkých 23 vzorov z [3] a pripraviť otvorený koncept pre pridávanie znovupoužiteľných častí ďalších vzorov.
Izolácia všeobecných častí vzoru Composite
6
83
Záver
V článku sme predstavili riešenie izolácie všeobecných častí oboch variácií návrhového vzoru Composite. Predstavili sme riešenie, ktoré zvyšuje viditeľnosť použitia návrhového vzoru v implementácií komplexných softvérových systémov. Náš prístup podporuje znovupoužitie zdrojového kódu pre tie časti vzorov, ktoré sa v rôznych implementáciách opakujú a umožňuje vývojárom sústrediť sa na doménovo špecifické časti vzorov. Použitie vzoru z knižnice taktiež umožňuje implicitné využívanie mikroarchitektúr, ktoré vznikajú spájaním návrhových vzorov. Vývojár knižnice definuje mikroarchitektúry priamo v knižnici. Aplikačný vývojár následne použije konkrétny vzor, ktorý môže byť vo vnútri knižnici zviazaný s iným vzorom. V našom konkrétnom príklade môžeme použiť mikroarchitektúru spojením vzorov Composite a Iterator cez triedu CommonComposite pre prácu s prvkami uloženými v použitom kontajneri. Uloženie vzorov, resp. ich znovu použiteľných častí, v knižnici umožňuje podporovať rôzne mikroarchitektúry bez potreby ich explicitného poznania. Nevýhodou navrhovaného riešenia môže byť použitie viacnásobného dedenia a mechanizmu šablón, ktoré sú dostupné len vo vybraných programovacích jazykoch. Pre iné objektovo – orientované jazyky by bolo potrebné modifikovať riešenie podľa možností konkrétneho jazyka. Poďakovanie: Táto práca je čiastočne podporovaná z grantov APVT-20-007104 a ZOD 1025/2004.
Referencie 1. Agerbo E., Cornils A. Theory of Language Support for Design Patterns. December, 1997, Computer Science Department, Aarhus University, Denmark. 2. Alur D., Crupi J., Malks D. Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall / Sun Microsystems Press, 1st edition, June 2001. ISBN 0-130-64884-1. 3. Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Company, 1995, Massachusetts. ISBN 0-201-63361-2. 4. Geary D. A look at the Composite design pattern. Java Design Patterns, September, 2002. http://www.javaworld.com/javaworld/jw-09-2002/jw-0913designpatterns.html. 5. Meijler T., Demeyer S., Engel R. Making Design Patterns Explicit in FACE. Proceedings of the 6th European conference held jointly with the 5th ACM SIGSOFT international symposium on Foundations of software engineering. Zurich 1997, pp. 94 – 110. ISBN 0163-5948.
84
Jaroslav Jakubík
6. Taibi T., Check Ling Ngo D. Formal Specification of Design Patterns – A Balanced Approach. Journal of Object Technology, číslo 4, Júl – August 2003, pp. 127-140, http://www.jot.fm/issues/issue_2003_07/article4. Annotation There are few solutions how to reuse existing implementation of design patterns. In this paper, we present one example illustrated with the Composite pattern. Our solution is compared with the solution in the Beta language and with the solution connected with the Face framework. We use one of the most popular and common object oriented language C++ as the implementation language. For the purpose of splitting Composite pattern into domain specific and common part we used special mechanisms specific for C++, such as templates and multiple inheritance. We present solutions for both variants of Composite design pattern, safe and transparent too.
Thread Thread Local Local Storage Storage Aleš Keprt Aleš Keprt Katedra informatiky, PřF, Univerzita Palackého, Olomouc Katedra informatiky, PrF, Univerzita Palackého, Olomouc [email protected][email protected] Abstrakt. Všechna vlákna v rámci jednoho procesu sdílejí stejný adresový prostor. Výjimkou je Thread Local Storage (TLS), lokální datový prostor každého vlákna. TLS je vhodným doplňkem objektově orientovaného programování. Princip, kterým umožňuje navzájem oddělit proměnné (obecně paměť) v jednotlivých vláknech, je možné nahradit i klasickými prostředky OOP, ale s pomocí TLS můžeme psát některé konstrukce paralelních výpočetních programů jednodušeji, stručněji a přehledněji. Klíčová slova: TLS, thread local storage, Windows, Linux, .NET, C++, C#
1
Úvod
Vícevláknové programování není žádnou novinkou. Většina běžných aplikací ve Windows ale i dalších operačních systémech dnes používá více než jedno vlákno, nejčastěji pro zlepšení odezvy uživatelského rozhraní (na povely uživatele). Jelikož adresový prostor je vztažený vždy k jednomu procesu, všechna vlákna v procesu sdílí stejnou paměť. To má za následek, že všechny globální proměnné, včetně statických proměnných tříd a metod, jsou sdílené mezi všemi vlákny. V běžném scénáři, kdy jednotlivá vlákna mají v rámci aplikace odlišné úlohy, je tento fakt výhodou, neboť každé vlákno pracuje s odlišnými daty a sdílenou paměť je možno využít k rychlé mezivláknové komunikaci. S příchodem dvou- a vícejádrových mikroprocesorů a jejich postupným rozšiřováním na běžné počítače se začal objevovat i jiný druh vícevláknových aplikací – více vláken je nasazeno na urychlení jedné operace, provádějí tedy společně výpočet jedné úlohy, čili pracují se stejnými daty. U vícevláknových aplikací tohoto typu se objevuje potřeba rozlišovat data sdílená mezi vlákny a data vláknu vlastní. Způsobů, jak zajistit, aby vlákno mělo k dispozici kromě sdílené paměti také nějakou vlastní paměť nezávislou na ostatních vláknech, je hned několik. Běžné operační systémy, jako Windows nebo Linux, nabízejí pro tyto účely tzv. Thread Local Storage (TLS), česky „lokální paměť vláknaÿ. TLS je možno využít prostřednictvím funkcí operačního systému; některé překladače C/C++ (a pravděpodobně i jiných jazyků) podporují TLS přímo a umožňují tak používat TLS velmi jednoduchým a přehledným způsobem. Lokální paměť vlákna je možno také simulovat pomocí čistých objektově–orientovaných konstrukcí, což je však nepraktické a vyžaduje složitější kód. V následujících kapitolách bude představeno několik způsobů, jak lokální paměť vlákna realizovat.
c Václav Snášel, editor: Objekty 2005, pp. 85–91, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
86
2
Aleš Keprt
Kontext – lokální paměť vlákna bez podpory operačního systému
Zdánlivě nejjednodušší způsob, jak dosáhnout toho, aby vlákno mělo vlastní paměť, nepotřebuje žádnou podporu operačního systému. Stačí všechna data, která chceme mít duplikována pro každé vlákno, umístit do samostatné třídy a ve spouštěcí funkci vlákna pak vytvořit vždy jednu novou instanci této třídy. Referenci tohoto objektu pak předáváme jako „kontextÿ do každé metody, která lokální data vlákna používá nebo volá jiný kód, který by je používat nebo potřebovat mohl. Výhodou tohoto řešení je nezávislost na platformě. Nevýhodou je nutnost předávat kontext jako parametr do každé metody (ve všech třídách celé aplikace), což může být navíc nerealizovatelné při používání cizích knihoven, inverzním programování (vkládání vlastního kódu do kódu cizích knihoven, např. iterátory v jazyku C#), apod. Další nevýhodou je, že je zde porušen princip odpovědnosti tříd, neboť některá data jsou z čistě implementačních důvodů vyčleněna mimo třídy, kam by měla patřit, do třídy kontextu. Je-li program rozsáhlejší, vzniká tím navíc velká nepřehlednost. Tu lze částečně zlepšit použitím kaskádových kontextů, tj. shlukováním souvisejících lokálních proměnných do tříd, jejichž instance teprve umístíme do třídy kontextu. Nevýhodou může být rovněž o jednu úroveň vyšší nepřímost adresování (proměnná není přímo v „méÿ třídě, dostanu se k ní až pomocí reference na jiný objekt), což může výrazně zpomalit časově náročné výpočty (platí o to více u kaskádových kontextů).
3
TLS s podporou operačního systému
Oproti čistě objektovému řešení popsanému v předcházející kapitole, TLS s podporou operačního systému umožňuje používání lokální paměti vláken bez nutnosti předávat do všech metod navíc tzv. kontext jako další parametr. 3.1
Win32 (Windows 95/98/NT/2000/XP)
Princip je následující: Jedno vlákno (obvykle hlavní/primární vlákno procesu) alokuje tzv. TLS–index pro každou proměnnou, kterou chceme mít lokální pro každé vlákno. TLS–index je číslo, které si musíme uložit do globální proměnné přístupné všem vláknům. Lokální proměnné vlákna tak dostanou číselné indexy, pomocí kterých je můžeme (a musíme) identifikovat. Index proměnné je stejný ve všech vláknech, ale adresa proměnné na tomto indexu je v každém vlákně jiná. Rámcově je tento princip nastíněn na obrázku 1. Každé vlákno má TLS tabulku, což je právě ona lokální paměť vlákna. Tato tabulka je inicializovaná nulami a její velikost je vždy stejná, závisí jen na verzi operačního systému (Windows 95/NT4.0 má 64 buněk, Windows 98/ME má 80 buněk, Windows 2000/XP má 1088 buněk). Do této paměti máme de facto volný přístup pomocí příslušných funkcí operačního systému, je však doporučeno ji adresovat pomocí oněch TLS–indexů. Každá buňka TLS tabulky je typu 2
Thread Local Storage
87
Obr. 1. TLS ve Windows – převzato z MSDN [3]
LPVOID, čili je to 4bajtová hodnota. Potřebujeme-li ukládat více než 4 bajty, ukládáme do TLS pouze pointery na skutečná data, která umístíme do běžné paměti. Proměnné o délce do 4 bajtů můžeme do TLS ukládat přímo. Postup: 1. Hlavní vlákno alokuje TLS–index pro lokální proměnnou vláken. static DWORD index = TlsAlloc(); 2. Každé vlákno při své inicializaci vytvoří lokální proměnnou (zde pro příklad typu MyClass – do TLS ukládáme pointer na skutečný objekt). TlsSetValue(index, new MyClass()); 3. Při práci se svou lokální proměnnou si vlákno nejprve přečte pointer na svůj lokální objekt z TLS. Pokud s ním bude pracovat déle, je vhodné si jej uložit do běžné lokální proměnné metody (tj. na zásobník, mimo TLS). MyClass *objekt = (MyClass*)TlsGetValue(index); 4. Při ukončování vlákna je třeba uvolnit alokovaný objekt. delete (MyClass*)TlsGetValue(index); 5. Po skončení všech pracovních vláken pak hlavní vlákno uvolní TLS–index. (Není nutno dělat při ukončování celého procesu.) TlsFree(index); 3.2
POSIX a Linux
V Linuxu můžeme používat TLS pomocí knihovny pthreads (POSIX Threads), viz [1]. Postup práce je stejný jako ve Windows, liší se jen jména systémových funkcí. Výjimkou je možnost definovat destruktory (viz níže). Postup: 1. Hlavní vlákno alokuje TLS–index pro lokální proměnnou vláken. #include pthread_key_t *key; 3
88
2.
3.
4. 5.
Aleš Keprt
pthread_key_create(key,NULL); Jako druhý parametr je možno předat pointer na destruktor – funkci, která je volána při ukončování vlákna pro všechny nenulové buňky TLS tabulky. void (*destructor)(void*); Každé vlákno při své inicializaci vytvoří lokální proměnnou (zde pro příklad typu MyClass – do TLS ukládáme pointer na skutečný objekt). pthread_setspecific(index, new MyClass()); Při práci se svou lokální proměnnou si vlákno nejprve přečte pointer na svůj lokální objekt z TLS. Pokud s ním bude pracovat déle, je vhodné si jej uložit do běžné lokální proměnné metody (tj. na zásobník, mimo TLS). MyClass *objekt = (MyClass*)pthread_getspecific(index); Při ukončování vlákna je třeba uvolnit alokovaný objekt. delete (MyClass*)pthread_getspecific(index); Po skončení všech pracovních vláken pak hlavní vlákno uvolní TLS–index. (Není nutno dělat při ukončování celého procesu.) pthread_key_delete(index);
Zde popsané fungování TLS v Linuxu je možno použít na všech systémech podporujících POSIX (viz [1]). Narozdíl od TLS ve Windows umožňuje POSIX používání destruktorů, což je velmi praktické, neboť to zjednodušuje uvolňování dynamicky alokovaných objektů odkazovaných z TLS. Knihovnu pthreads je možno používat, a tím dosáhnout zde popsané funkcionality, i v jiných systémech než jen v Linuxu (včetně Windows, není to však obvyklé). 3.3
Microsoft .NET Framework
Platforma .NET je prostředím, ve kterém jsou spouštěny aplikace, stojí tedy z hlediska aplikací na úrovni operačního systému. Proto také sama nabízí funkcionalitu TLS a popis je zařazen do této kapitoly k běžným operačním systémům. TLS v .NETu je možno používat ve všech programovacích jazycích, příklady jsou zde uváděny v jazyce C#. Platforma .NET je plně objektová, místo TLS indexů se zde používají objekty typu LocalDataStoreSlot, které jsou v terminologii .NETu nazývány sloty. Samotná funkcionalita je však v zásadě stejná jako ve Windows či Linuxu (viz také [2]). Použití: 1. Hlavní vlákno alokuje TLS slot pro lokální proměnnou vláken. LocalDataStoreSlot slot = Thread.AllocateDataSlot(); Alternativně je možno TLS slot pojmenovat. LocalDataStoreSlot slot = Thread.AllocateNamedDataSlot("jméno"); Pojmenovaný slot je možno později najít podle jména. LocalDataStoreSlot slot = Thread.GetNamedDataSlot("jméno"); 2. Každé vlákno při své inicializaci vytvoří lokální proměnnou (zde pro příklad typu MyClass) a do TLS uloží referenci na tento objekt. Thread.SetData(slot, new MyClass()); 4
Thread Local Storage
89
3. Při práci se svou lokální proměnnou si vlákno vytáhne referenci na svůj lokální objekt z TLS. Pokud s ní bude pracovat déle, je vhodné si ji uložit do běžné lokální proměnné metody (tj. na zásobník, mimo TLS). MyClass objekt = (MyClass)Thread.GetData(slot); 4. Po skončení všech pracovních vláken pak hlavní vlákno uvolní pojmenovaný TLS slot. Nepojmenované TLS sloty se v .NETu neuvolňují (uvolňuje se tedy de facto jen jméno). Thread.FreeNamedDataSlot(slot);
4
Podpora TLS v překladačích C/C++
Některé překladače jazyků C/C++ podporují TLS přímo, tj. na úrovni syntaxe. Používání TLS na úrovni programovacího jazyka je od výše uvedených postupů velmi odlišné. Výhodou je pohodlnější práce, přehlednější kód a silnější typová kontrola. Obecně lze říci, že TLS podporované překladači C/C++ je lepší než TLS pomocí funkcí operačního systému. 4.1
Visual C/C++
Visual C++ umožňuje označit jakoukoliv statickou a konstantně inicializovanou proměnnou modifikátorem declspec(thread), například takto: static __declspec(thread) int lokalni; Takto deklarovaná proměnná je překladačem umístěna do TLS, není třeba volat žádné další funkce operačního systému. Jelikož pracujeme v systému Windows, stále platí omezení velikosti TLS paměti uvedené v kapitole 3.1. Práce s TLS tímto způsobem zajišťuje silnou typovou kontrolu – nepracujeme již s obecnými pointery LPVOID (void*), což je jistě výhodou. Při časté práci s některou proměnnou je opět vhodné udělat is její kopii do lokální proměnné metody/funkce (tj. mimo TLS). 4.2
GNU C/C++ (GCC) a Sun Studio C/C++
V Linuxu a obecně mimo Windows je nejčastěji používán překladač GCC. Ten podporuje stejnou funkcionalitu jako Visual C++, ovšem s lehce jiným způsobem deklarace – používáme modifikátor thread. static __thread int lokalni; Funkcionalita je pak stejná jako ve Visual C++. Možnost používat TLS tímto způsobem je jen na určitých mikroprocesorech (Intel x86/IA-32 a IA-64 od verze GCC 3.3). Stejnou syntaxi podporuje i Sun Studio C++ (pro Solaris a Linux).
5
Case study: BiF
V předchozích kapitolách bylo popsáno několik způsobů použití TLS. Pro názornost uvedeme praktický příklad – kód, který používá TLS se syntaktickou podporou Visual C++. 5
90
Aleš Keprt
5.1
Co je to BiF
BiF je binární faktorizační program sloužící ke statistické analýze dat pomocí metody zvané binární faktorová analýza. Tato metoda je v programu BiF implementována několika různými algoritmy, z nichž pro většinu úloh je nejvhodnější GABFA, výpočet založený na modifikovaném genetickém algoritmu. Profilováním programu lze vysledovat, že zhruba 90% času program stráví ohodnocováním jedinců umělé populace pomocí pseudo–dělení binárních matic. Je také důležité, že – ohodnocení jednoho jedince populace sestává z 99% z jednoho maticového dělení – během výpočtu se ohodnocuje velké množství jedinců – každé ohodnocení jednoho jedince je nezávislé na ostatních – pamatujeme si nejlepšího jedince, kterého během výpočtu najdeme 5.2
Paralelizace
Je tedy zřejmé, že máme-li k dispozici víceprocesorový počítač (obvykle dvouprocesorový nebo dvoujádrový), největšího zrychlení dosáhneme, právě když se zaměříme na paralelizaci pseudo–dělení binárních matic nebo ohodnocování jedinců populace. Druhá varianta se ukazuje jako mnohem snazší – jelikož jednotliví jedinci v populaci jsou na sobě navzájem nezávislí, můžeme dělení provádět paralelně v tolika vláknech, kolik máme fyzických procesorů či jader. TLS pak využijeme právě ve třídě provádějící dělení matic. Paralelizaci této operace můžeme samozřejmě provést i bez TLS způsobem popsaným v kapitole 2, tj. vytvořením instance této třídy pro každé vlákno. Je zde však několik důvodů, proč je použití TLS lepší variantou: – Jedná se třídu algoritmu. Takové třídy je vhodnější vytvářet jako statické. Nepotřebujeme pak zakládat instance této třídy. – Kód statické třídy je vždy rychlejší než kód běžné třídy (překladač má k dispozici jeden registr procesoru navíc pro optimalizace kódu a všechny proměnné třídy jsou adresovatelné přímo bez odkazování pomocí „thisÿ). – Operace dělení v programu BiF používá jako dělenec (největší matici) statická konstantní data. Je vhodné tato data mít jako statickou položku dělicí třídy. Dělicí třídu tedy v zájmu efektivity kódu deklarujeme jako statickou (tj. všechny součásti třídy jsou statické). Aby statická třída byla použitelná i pro vícevláknové programy, všechny lokální proměnné používané při výpočtu musí být buď lokální v rámci metody (což platí ve většině případů), nebo lokální v rámci vlákna (čili umístěné na TLS). V našem případě umístíme na TLS především matici nejlepšího jedince, kterého během výpočtu najdeme (toto zapamatování je požadováno algoritmem, viz výše). Matice nejlepšího jedince je uložena v běžném poli. Používali-li bychom jen jedno pole pro všechna vlákna, museli bychom během výpočtu provádět synchronizaci vláken pomocí kritické sekce, aby byl zaručen konzistentní stav tohoto 6
Thread Local Storage
91
pole. Časté používání kritických sekcí zpomaluje vlastní výpočet. Alokujeme-li pro každé vlákno samostatné pole pro uložení matice nejlepšího jedince, vícevláknový výpočet může běžet zcela bez vzájemné synchronizace vláken. Do společné paměti ukládáme jen údaj kvality nejlepšího řešení (což je celé číslo – int) a to lze jednoduše implementovat pomocí tzv. interlocked operací (tj. bez kritických sekcí). S použitím TLS jsme tedy dosáhli toho, že dělicí algoritmus je ve statické třídě (máme přehlednější a rychlejší kód) a výpočet navíc běží bez vzájemné synchronizace vláken (máme kratší a rychlejší kód). S přímou podporou TLS v překladači C++ je kód i velmi přehledný a je využita silná typová kontrola jazyka (samozřejmě jen do míry typové kontroly v C++).
6
Shrnutí
Příspěvek představil Thread Local Storage a jeho použití v různých systémech, platformách i jazycích. Na praktickém příkladě jeho použití bylo demonstrováno, jaké výhody může TLS přinést při optimalizaci kódu pro počítače s více procesory nebo vícejádrovými procesory, které začínají být dnes již naprosto běžné. Technologie TLS úzce souvisí s objektově–orientovaným programováním, neboť obojí je vhodné pro každodenní programování. TLS přitom zasahuje do principu objektově–orientovaného programování (OOP), neboť deklarace proměnných jako vláknově–lokálních není v běžné teorii OOP diskutována a její opis jinými prostředky čistě na bázi OOP je nevýhodný z hlediska optimalizace kódu pro rychlost. Kód využívající TLS je kratší, přehlednější i rychlejší, než kód stejné funkcionality bez TLS.
Reference 1. Blaise Barney. POSIX Threads Programming. Livermore Computing, 2005. http://www.llnl.gov/computing/tutorials/pthreads/ 2. Doug Doedens. Use Thread Local Storage to Pass Thread Specific Data. 2003. http://www.c-sharpcorner.com/Code/2003/March/UseThreadLocals.asp 3. Thread Local Storage. Položka MSDN Library. Microsoft, 2005. http://msdn.microsoft.com/library/en-us/dllproc/base/thread local storage.asp 4. Thread Local Storage. Z encyklopedie Wikipedia, 2005. http://en.wikipedia.org/wiki/Thread Local Storage
Annotation: Thread Local Storage The threads of a single process all share the same address space. But there is one exception to this rule: the Thread Local Storage (TLS), the local data space of a thread. TLS may be used as a handy addition to object oriented programming. The separation of variables (generally any data) of particular threads may be also compensated by classic OOP facilities, but it can be done much more simply, more shortly, and more clearly with TLS. 7
T°ídy mobilních mobilních objekt· Třídy objektů Tomá² Kozel
Tomáš Kozel Katedra informatiky a kvantitativních metod
Katedra informatiky a kvantitativních metod, Fakulta informatiky a managementu, Fakulta informatiky a managementu Univerzita Hradec Hradec Králové Králové Univerzita Rokitanského 62, 62, 500 500 03 03 Hradec Hradec Králové Králové Rokitanského [email protected][email protected]
Abstrakt Mobilita je b¥ºnou vlastností °ady objekt· reálného sv¥ta.
V oblasti tvorby objektového softwaru je zatím vyuºívána jen velmi z°ídka a to jednak neuv¥dom¥le jako vedlej²í efekt pouºití distribuovaných objekt· nebo cílen¥, ale zatím p°edev²ím v experimentálních podmínkách. Tento p°ísp¥vek p°edstaví základní t°ídy mobilních objekt· odvozené na základ¥ zkoumání objekt· reálného sv¥ta. P°i popisu bude kladen d·raz na pouºitelnost t¥chto t°íd mobilních objekt· p°i implementaci softwarových aplikací.
Mobilita se mezi ostatními objektovými vlastnostmi drºí stále velmi v pozadí. Hlavním d·vodem je její relativn¥ snadná nahraditelnost distribuovanými °e²eními. Vývojá°i jsou zvyklí automatizovan¥ p°evád¥t modely s p°irozenými prvky mobility na modely distribuované, aniº by si mobilitu a existenci mobilních objekt· uv¥domovali. V²e p°ipomíná d°ív¥j²í £asy, kdy problémy objektového sv¥ta byly p°i vývoji softwaru °e²eny p°edev²ím pomocí strukturovaných nástroj·. Tato situace je v²ak vcelku pochopitelná. Existuje °ada velmi kvalitních, obecn¥ známých standard· a technologií, které lze pouºít p°i tvorb¥ distribuovaných aplikací, ale neexistuje v podstat¥ ºádný standard a jen velmi málo nástroj· nabízejících plnou podporu mobility objekt·. Navíc je valná v¥t²ina t¥chto nástroj· prozatím nepouºitelná pro nasazení p°i tvorb¥ komer£ních aplikací. Relativn¥ nejdále je vyuºití mobility v oblasti softwarových agent·, které v²ak £asto bývají implementovány i jinak neº objektov¥. Jejich objektová implementace je pak zaloºena práv¥ na pouºití mobilních objekt·. V následujících £ástech p°ísp¥vku bude mobilita p°edstavena tak, aby si kaºdý £tená° uv¥domil potencionální moºnosti softwarové mobility a zamyslel se nad tím, co by mohla do budoucna nabídnout.
2
Reálná mobilita jako zdroj inspirace
Nejprve budou namátkou vybráni zástupci skute£ných mobilních objekt· reálného sv¥ta, které se dle stanovených kritérií rozd¥lí n¥kolika skupin (t°íd). Ná-
c Václav Snášel, editor: Objekty 2005, pp. 92–103, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Třídy mobilních objektů
93
sledn¥ budou pojmenovány jejich charakteristické znaky. Tento rozbor si neklade za cíl být zcela komplexní.
2.1
Výb¥r zástupc·
Bez jakéhokoli t°íd¥ní budou nyní uvedeny objekty, respektive t°ídy objekt· skute£ného sv¥ta, o kterých lze °íci, ºe jsou mobilní. Seznam objekt·: u£itel, opravá°, dopis, léka°, policista, osobní automobil, autobus, po²tovní balík, letadlo, student, kniha, se²it, notebook, hasi£, dealer, zásobova£, faxová zpráva, email, °emeslník, cestovatel, tazatel, výzkumník, ko£ovník, ale nap°íklad i zlod¥j, terorista, tunelá°, ²pión . . . .
2.2
Kritéria £len¥ní
Následuje vý£et základních kritérií, která nám pomohou popsat vlastnosti a chování vybraných mobilních objekt·.
2. Jaký je charakter £innosti mobilního objektu v cíli cesty:
poskytnutí sluºby, získání dat, vyuºití vlastností nového prost°edí, usídlení se, alokace distribuované sluºby, ...
3. Jakým zp·sobem je pohyb objektu °ízen:
objekt jedná z vlastní v·le (agent), objekt je °ízen systémem, z n¥hoº pochází, objekt je °ízen novým prost°edím, kombinace vý²e uvedeného, ...
4. Co se stane s objektem po spln¥ní úkolu:
objekt se vrací dom·, pokra£uje dále v cestách, usídlí se v novém prost°edí zaniká, ...
94
2.3
Tomáš Kozel
Skupiny mobilních objekt·
Bez nároku na komplexnost jsou dále uvedeny p°íklady t°íd £i skupin objekt· s podobnými charakteristikami, které mohou z této analýzy vznikat.
Zásilky - cílem je p°inést informace do cílového prost°edí. Migrace je iniciována odesílatelem. Objekt je po doru£ení archivován nebo zaniká. Cílové
P°íklady: dopis, balík, fax, email. Tazatelé - objekty, jejichº ú£elem je data v cílovém prost°edí získávat. Inici-
prost°edí je p°ipraveno nebo schopno zásilky p°ijímat.
átorem je výchozí prost°edí objektu. Objekt se po spln¥ní úlohy bu¤ vrací, nebo komunikuje vzdálen¥ s p·vodním prost°edím, m·ºe pokra£ovat ve sb¥ru
dat v dal²ích destinacích (ob¥ºník). P°íklady: dotazník, ob¥ºník, tazatel.
Dopravci - objekty, které se starají o hromadnou dopravu jiných objekt·. Znají zpravidla cestu, po které zásilky distribuují. Nav²tíví více prost°edí
P°íklady: autobus, dealer, letadlo, nákladní vozidlo. Experti - objekty poskytující n¥jakou sluºbu, která v cílovém prost°edí není a v nich zanechávají dopravované objekty.
dostupná. O sluºby experta ºádá cílové prost°edí a po vykonání sluºby se expert zpravidla vrací zp¥t, nebo pokra£uje.
P°íklady:
léka°, opravá°, °e-
meslník, u£itel, policista, kalkula£ka.
Manaºe°i - vná²í nové prvky °ízení do cílového prost°edí. Mohou zejména napomoci s °ízením dal²ích mobilních objekt·, které do cílové oblasti dopu-
P°íklady: stavbyvedoucí, regionální manaºer. Ko£ovníci - st¥hují se do místa s lep²ími podmínkami pro existenci. Své tovaly.
st¥hování m·ºe ko£ovník iniciovat sám (agent), nebo je vyslán a °ízen p·-
vodním prost°edím. P°íklady: putování lidí za prací, za lep²ími podmínkami pro podnikaní, st¥hování provoz· blíºe za surovinami apod. Jelikoº si tento p°ísp¥vek klade za úkol p°edstavit uºite£né mobilní objekty, byly zám¥rn¥ ve vý£tu opomenuty skupiny, jako jsou nap°íklad viry a r·zní jiní ²k·dci (tunelá°i,
²pióni, zlod¥ji, . . . ). Na druhou stranu je zcela jisté, ºe
studiem t¥chto ²kodlivých skupin objekt· by bylo moºno najít a popsat také °adu zajímavých model· správy a chování mobilních objekt·. k·dc·m nejp°íbuzn¥j²í uºite£nou skupinou mobilních objekt· jsou z°ejm¥ ko£ovníci s vlastní v·lí, jejichº implementace se m·ºe p°ibliºovat implementaci mobilních agent· (trochu nadnesen¥ je lze za°adit samoz°ejm¥ i mezi experty, které o jejich sluºbu rozhodn¥ nikdo neºádal). Ur£it¥ by si ale zaslouºili spí²e svoji vlastní skupinu. Z existence svévolných ²k·dc· vyplývá jedno z velkých potencionálních bezpe£nostních ohroºení kaºdého mobiln¥ orientovaného systému. Této problematice se podrobn¥ji v¥nuje nap°íklad [5]. P°íklady r·zných kombinací jednotlivých kritérií pro r·zné skupiny mobilních objekt· jsou uvedeny v tabulce 1. Tabulka ukazuje jen nejb¥ºn¥j²í kombinace. Z °ady reálných p°íklad· vyplývá, ºe mobilní objekt m·ºe mít £asto charakter více zde uvedených skupin. To znamená, ºe je schopen poskytovat více typ· £inností. Jako p°íklad m·ºe být uveden obchodní cestující, jehoº úkolem je jednak informovat zákazníka o nových výrobcích rmy a nabízet nejr·zn¥j²í
Třídy mobilních objektů
95
Zásilka Tazatel Dopravce Expert Manaºer Ko£ovník
Kdo iniciuje migraci Cílové prost°edí Lokální prost°edí
x x
Objekt sám
x x
Charakter £innosti v cíli cesty Poskytnutí sluºby Získání dat Usídlení
x x
x x
x
x
x
x
x x
x
Vlastní v·le Lokálním prost°edím Cílovým prost°edím
x x
Po spln¥ní úkolu objekt Vrací se Pokra£uje dále Usídlí se Zaniká
x x x
x x
x
Alokace dist. sluºby
Zp·sob °ízení objektu
x
x x x
x x
x x
x x
x x
x x x x x x
x x x x x
Tabulka 1. Obvyklé kombinace kritérií skupin mobilních objekt·
informa£ní a propaga£ní materiály. Na druhé stran¥ je £asto obchodník vybaven p°ímo zboºím, které m·ºe zanechat u zákazníka v p°ípad¥ jeho okamºitého zájmu. Obchodní cestující °ady rem zárove¬ poskytují moºnost nejr·zn¥j²ích dal²ích sluºeb, jako je za²kolení, provedení drobných servisních úprav na jiº d°íve zakoupeném zboºí. Shrneme-li vý²e uvedené £innosti, m·ºeme °íci, ºe takový obchodní cestující jako mobilní objekt plní úlohy dopravce, experta, £asto tazatele nebo nositele r·zných zpráv.
3
T°ídy zástupc· vybraných skupin
Z p°ede²lé analýzy bude vycházet de nice n¥kolika model· t°íd adaptovaných do prost°edí softwarových aplikací. Nejprve bude uveden popis nejzákladn¥j²ích prvk· kaºdé aplikace schopné pracovat s mobilními objekty - modely Mobilní objekt a Mobilní prost°edí. V dal²í £ásti jiº bude p°istoupeno k rozvinutí model· do podoby d°íve vytypovaných skupin objekt·. Popisy se budou £asto odkazovat na konkrétní t°ídy návrhu základního frameworku pro tvorbu mobilních aplikací, který byl popsán v [7].
3.1
Mobilní objekt
Je bezesporu nutné za£ít u návrhu mobilního objektu. P°i tom se jiº bude brát v úvahu moºná budoucí implementace v jazyku Java. Kaºdý mobilní objekt, máli se úsp¥²n¥ st¥hovat z jednoho místa na druhé, musí implementovat rozhraní
96
Tomáš Kozel
java.io.Serializable. Bez toho by se nezda°ilo úsp¥²n¥ p°enést stav objektu. Aby bylo moºno v budoucnu vyuºít pro nov¥ vznikající objekty také mechanismu d¥di£nosti, vezme se za základ mobilních objekt· rozhraní MobileObjInt, které vznikne d¥d¥ním z rozhraní Serializable. Dále budou p°idány je²t¥ hlavi£ky metod ur£ených primárn¥ pro identi kaci mobilního objektu dle jména. Výsledek je zobrazen na obrázku 1. Aby mohl mobilní objekt n¥jak zareagovat na proces migrace, jsou do jeho rozhraní p°idány je²t¥ metody
prepare()
a
resume().
První z nich je volána t¥sn¥ p°ed startem migrace a m·ºe být pouºita nap°íklad k úprav¥ stavu objektu, k dopln¥ní mechanismu serializace, k zastavení a uloºení stavu vláken nebo k vypo°ádání aktuálních asociací s dal²ími objekty lokálního prost°edí. Druhá metoda (resume()) je zavolána po dokon£ení procesu migrace jiº v cílovém prost°edí. Objekt v ní m·ºe nap°íklad spustit £i obnovit svoji £innost, navázat komunikaci s novým (cílovým) prost°edím.
Obrázek 1. Rozhraní MobileObjInt
Ve stavovém diagramu obecného mobilního objektu na obrázku
2 je de-
monstrován proces migrace mobilního objektu. Za£íná se ve stavu, kdy mobilní objekt standardn¥ pracuje ve svém p·vodním prost°edí. Pokud toto prost°edí zahájí proces migrace, a´ uº z vlastní iniciativy nebo na ºádost vzdáleného prost°edí, je vyvolána metoda Voláním metody
move()
prepare()
a objekt se díky ní p°ipravuje na p°esun.
lokálního prost°edí (metoda bude vyvolána vzdáleným
objektem) dochází k zahájení migrace. Mobilní objekt je nejprve serializován (stav objektu je zakódován do binární podoby) a následn¥ dochází k p°enosu do cíle prost°ednictvím komunika£ního kanálu. Pokud není v cílovém prost°edí dostupná implementace t°ídy objektu, dochází je²t¥ k p°enesení bytekódu této t°ídy. Tím je proces p°enosu binárního obrazu objektu zakon£en. V dal²ím kroku dochází k deserializaci objektu a tím k de nitivnímu vytvo°ení jeho instance. Cí-
Třídy mobilních objektů
97
Obrázek 2. Stavový diagram mobilního objektu
lové prost°edí noti kuje vyvoláním metody
resume() mobilní objekt o dokon£ení
procesu a objekt na tuto událost m·ºe reagovat. Objekt m·ºe být zaregistrován do zásobníku mobilních objekt· (repository ) a následn¥ p°echází do aktivního stavu v rámci cílového prost°edí . Samostatnou kapitolou v oblasti mobilních objekt· je migrace objektu vlákna
silná mobilita (Strong Mobility) [8], n¥kdy také serializace vláken (Thread Serialization) [1]. - tzv.
3.2
Mobilní kontejner
Ne vºdy cestuje" mezi aplikacemi izolovaný objekt s atributy primitivních datových typ·. Velmi £asto je mobilní objekt sloºen z více díl£ích podobjekt·. Mobilní objekt tedy vzniká agregací (resp. kompozicí) z dal²ích objekt·. Takový je ozna£ován jako
mobilním kontejner. Aby byla zaru£ena schopnost st¥ho-
vání celého objektu v£etn¥ vno°ených podobjekt·, je nutné, aby i tyto podobjekty implementovaly minimáln¥ rozhraní
Serializable.
V opa£ném p°ípad¥
nemusí dojít k jejich p°enosu do cílového prost°edí. Typickým p°ípadem, v n¥mº se na tuto povinnost zapomíná, je pouºití mobilního objektu typu okno GUI
(javax.swing.JFrame). V okn¥ jsou tém¥° vºdy zaregistrovány n¥jaké listenery (objekty obsluhy událostí) a velmi £asto jsou de novány jako vno°ené anonymní t°ídy. Díky tomu, ºe neimplementují rozhraní
Serializable, dojde po p°enesení
objektu (okna) do cílového prost°edí ke ztrát¥ funk£nosti v²ech ovládacích prvk· okna.
98
3.3
Tomáš Kozel
Mobilní prost°edí
Mobilní objekty se mohou pohybovat pouze v prost°edí, které je akceptuje a které implementuje základní metody správy migrace objekt·. Poºadavky a hrubý návrh takového prost°edí je uveden v [6]. Celé mobilní prost°edí je distribuovanou aplikací, která je tvo°ena instancemi lokálních aplikací spravujících své mobilní i dal²í aplika£ní objekty. Tyto lokální aplikace budou dále trochu zjednodu²en¥ ozna£ovány za mobilní prost°edí daného uzlu sít¥ (zkrácen¥
MobiEn ). P°i po-
hledu na n¥jaký sloºit¥j²í model zahrnující i procesy migrace se pak bude mluvit o lokálním (p·vodním) £i vzdáleném (cílovém) mobilním prost°edí, v závislosti na tom, z jakého umíst¥ní je na modelovanou situaci nahlíºeno. Základním stavebním kamenem modelu je rozhraní
MobiEnInt, které zve°ej-
¬uje a p°edepisuje implementaci £ty° základních metod pro p°enos objektu:
Metoda
cloneObject() slouºí k vytvo°ení klonu (kopie) lokálního mobilního
objektu. Klonovaný objekt je p°enesen do cílového prost°edí. Tato metoda
je volána vzdálen¥ ze vzdáleného (cílového) prost°edí. Metoda
moveObject()
pracuje tém¥° shodn¥ jako metoda p°edchozí, jedi-
ným rozdílem je, ºe nedochází k zachování instance p°esunovaného objektu v zásobníku (repository) lokálního prost°edí. Pokud reference v repository byla jedinou referencí na mobilní objekt v lokálním prost°edí, pak dojde i ke
zru²ení mobilního objektu. Metoda
acceptObject()
p°ijímá nový mobilní objekt ze vzdáleného pro-
st°edí. Metoda je vyvolávána práv¥ vzdáleným systémem a má za d·sledek p°idání p°ená²eného mobilního objektu do lokální repository a aktivaci ob-
jektu v lokálním prost°edí. Metoda
requestObject()
má za úkol kontaktovat vzdálené prost°edí a po-
ºádat o zaslání speci kovaného mobilního objektu. Po úsp¥²ném p°enosu je op¥t reference na objekt p°idána do lokální repository. Mobilní prost°edí musí existovat v kaºdém uzlu sít¥, který bude akceptovat práci s mobilními objekty. P°i p°esunu objektu mezi dv¥ma uzly musí dojít ke vzájemné vzdálené komunikaci dot£ených mobilních prost°edí a k fyzickému p°edání mobilního objektu. Z tohoto d·vodu je rozhraní mek rozhraní
java.rmi.Remote,
MobiEnInt de nováno jako poto-
jak p°edepisuje technologie RMI, a umoº¬uje
tedy v implementa£ních t°ídách vyuºít mechanismu vzdáleného volání metod.
Zavedené rozhraní je v modelu implementováno t°ídou na RMI je tato t°ída zárove¬ potomkem
p°ípad¥ je prost°ednictvím této t°ídy exportována jako vzdálený objekt. Pro p°epravu objekt· m·ºe být pouºita t°ída
TransportManager.
Prost°ednictvím
jejich podt°íd lze pak implementovat bezpe£n¥j²í metody p°enosu objektu, nap°íklad zabezpe£eným komunika£ním kanálem. Jak jiº bylo uvedeno d°íve, p°edpokládá se existence zásobníku mobilních objekt·. Tento zásobník (Repository)
usnadní správu mobilních objekt· v lokálním prost°edí a prost°ednictvím podt°íd nabídne i moºnost perzistentního uchování mobilních objekt·. Operace vytvo°ení instance mobilního prost°edí, respektive získání reference na prost°edí vzdálené, se budou v °ad¥ aplikací opakovat. Jelikoº se jedná o vcelku
Třídy mobilních objektů
99
komplikovaný proces vycházející z pravidel tvorby distribuovaných aplikací s vyuºitím RMI, bude vhodné poskytnou nástroj (t°ídu) pro rychlý p°ístup k t¥mto objekt·m. V p°ípad¥ lokálního mobilního prost°edí navíc bude nutné zabezpe£it, aby se vytvá°ela pouze jediná jeho instance. K tomu ú£elu bude vhodné vytvo°it t°ídu, která poskytne referenci na instanci lokálního mobilního prost°edí (resp. ji na poprvé vytvo°í). K tomu bude vhodné pouºít návrhové vzory a
Singleton
Factory method [4].
3.4
Zásilka
Zásilka je první konkrétní implementací rozhraní
MobileObjInt, která zde bude
uvedena. Zasílání a p°ijímání zásilek je realizováno prost°ednictvím d°íve zmín¥ných metod mobilního prost°edí. Vzhledem k moºnému nebezpe£í vyplývajícímu z p°íjmu neznámých a nevyºádaných zásilek je vhodné do modelu za°adit obecnou t°ídu
ParcelPolicy,
která prost°ednictvím své metody
isAcceptable()
vyhodnotí obsah zásilky, odesílatele apod. (konkrétní implementace budou zaji²´ovány prost°ednictvím podt°íd) a sd¥lí prost°edí, zda je bezpe£né zásilku p°ijmout a zpracovat. Politika práce se zásilkami by m¥la být nastavitelná a tak se p°edpokládá moºnost externí kon gurace této politiky. P°edpokládá se, ºe zásilka m·ºe obsahovat více materiál·. Ty jsou po nastavení adresáta do zásilky vkládány. Posléze dojde k pokusu o p°edání zásilky cílovému mobilnímu prost°edí (prost°edí adresáta). Selhání procesu je vºdy noti kováno odesílateli. Základní d·vody selhání jsou: nedostupnost cílového prost°edí a odmítnutí zásilky v cílovém prost°edí v d·sledku uplatn¥ní omezujících pravidel politiky p°ijímání zásilek. V p°ípad¥ úsp¥²ného doru£ení se dal²í ºivot zásilky °ídí aplika£ní logikou cílového prost°edí.
3.5
Tazatel
P°i návrhu modelu tazatele se vychází z analýzy reálných objekt· - tazatel·.
Budou uvaºováni tazatelé dvou typ· - jednoduchý dotazník (Questionnaire) a ob¥ºník (Circular). Ob¥ t°ídy m·ºeme povaºovat i za speciální typy zásilek
a pak je vhodné na n¥ aplikovat model vyhodnocování d·v¥ryhodnosti zásilky
ParcelPolicy. Dotazník m·ºe být MobileObjInt s metodou start(), která
v cílovém prost°edí prost°ednictvím t°ídy jednoduchou implementací rozhraní
spustí proces získávání dat v cílovém prost°edí. Sou£ástí metody bude v záv¥ru i kód zaji²´ující zp¥tný p°enos informací, nebo kód, který zaºádá cílové prost°edí o zprost°edkování návratu tazatele zp¥t do výchozího prost°edí. Ob¥ºník bude mít implementaci roz²í°enou o de nici cíl· putování ob¥ºníku. Tyto cíle jsou popsány itinerá°em. Pokud nejsou informace získávané z jednotlivých destinací na sob¥ závislé, pak je implementace itinerá°e velmi jednoduchá a m·ºe se jednat o neuspo°ádanou posloupnost adresát· ob¥ºníku. Pokud by jistá závislost (návaznost) mezi daty existovala, musel by být itinerá° uspo°ádán a ve spolupráci s ob¥ºníkem by speci koval, jaká £ást ob¥ºníku má být dopl¬ována £i prezentována v konkrétních destinacích. P°ípadné problémy (nedostupnost nebo odmítnutí) p°i £innosti ob¥ºníku nejsou tentokrát p°ímo noti kovány výchozímu
100
Tomáš Kozel
prost°edí, ale jsou zaznamenávány a k jejich vyhodnocení dochází aº po návratu objektu do výchozího prost°edí. Vý²e uvedený model správy ob¥ºníku je £ist¥ mobilním °e²ením problému. Jako alternativa se nabízí realizace ob¥ºníku pomocí centralizované správy ob¥hu. V tomto p°ípad¥ by byl ob¥ºník vyslán výchozím prost°edím do jedné destinace a následn¥ by se vracel zp¥t. Aplika£ní logika výchozího prost°edí by p°edzpracovala získaná data a odeslala modi kovaný ob¥ºník dal²ímu p°íjemci. Centralizované °e²ení umoºní lep²í reakci na výpadek jednoho p°íjemce (cíle) ob¥ºníku.
3.6
Dopravce
Návrh modelu mobilního objektu - dopravce se do zna£né míry podobá modelu mobilního kontejneru uvedenému v 3.2. Podobnost model· vychází zejména z faktu, ºe ob¥ t°ídy (dopravce i kontejner) v sob¥ agregují dal²í objekty imple-
Serializable (v£etn¥ dal²ích mobilních objekt· odvozených MobileObjInt). Hlavní rozdíl mezi t¥mito t°ídami je hlavn¥ v tom, ºe
mentující rozhraní od rozhraní
zatímco mobilní kontejner zachovává tém¥° nem¥nnou strukturu a po£et v sob¥ agregovaných objekt·, dopravce bude o své objekty postupn¥ p°icházet tím, jak je bude vykládat v jednotlivých destinací. Mobilní kontejner tedy p°edstavuje zapouzd°enou cestující komunitu vzájemn¥ spolupracujících objekt·. Dopravce je pouze do£asnou a ú£elovou strukturou zaloºenou výhradn¥ k tomu, aby byly poºadované objekty p°eneseny do cílových umíst¥ní. Sloºit¥j²í implementace modelu dopravce by mohla teoreticky vycházet i z dal²ích reálných princip· p°epravy - nap°íklad z procesu optimalizace vyt¥ºování dopravních prost°edk· ve spedi£ních rmách. Je otázkou, zda by tento p°ístup neumoºnil lépe optimalizovat p°enosy mobilních objekt· (resp. obecných dat) po po£íta£ové síti. Ov¥°ení této hypotézy by v²ak vyºadovalo provést °adu pokus· a m¥°ení.
3.7
Expert
Expert je tradi£ním mobilním objektem. Ve v¥t²in¥ p°ípad· vysta£íme p°i jeho implementaci s modely uvedenými v p°edchozích £ástech. Speci cká £innost experta - tedy poskytnutí n¥jaké doposud lokáln¥ nedostupné sluºby - je totiº p°eváºn¥ záleºitostí vnit°ní implementace objektu. Jediným p°edpokladem pouºití experta v novém prost°edí je p°ítomnost v²ech zdroj· a prost°edk· pot°ebných pro jeho £innost. Kaºdý mobilní expert by mohl obsahovat seznam v²ech svých poºadavk· na cílové prost°edí (instance t°ídy
Prerequisite).
Sou£ástí kaºdého
p°edpokladu by bylo pravidlo, které ov¥°í dostupnost p°edpokládaného zdroje, a dále informaci o tom, jak v p°ípad¥ nedostupnosti daný zdroj, komponentu nebo objekt do cílového prost°edí nainstalovat. Zpracování p°edpoklad· je sou£ástí instalace mobilního objektu do cílového umíst¥ní. Je tedy odpov¥dností cílového prost°edí p°evzít a zpracovat v²echny poºadavky experta na prost°edí. Spu²t¥ní £innosti experta není moºné, dokud nejsou v²echny p°edpoklady spln¥ny.
Třídy mobilních objektů
101
Jako alternativa vý²e uvedeného modelu se nabízí odd¥lené poskytování informací o poºadavcích experta na cílové prost°edí. V tomto p°ípad¥ by p°ed vlastním st¥hováním experta do cílového prost°edí muselo dojít ke vzdálenému poskytnutí seznamu p°edpoklad· a teprve po jejich vyhodnocení by docházelo k p°enosu experta do cíle. To by v²ak £áste£n¥ komplikovalo situaci se správou poºadavk·, jelikoº by musely být evidovány odd¥len¥ od mobilního objektu experta, nebo by mobilní expert musel být schopen poskytnout tyto poºadavky prost°ednictvím vzdáleného volání metod a m¥l by tedy charakter jak mobilního, tak distribuovaného objektu. Posledn¥ zmín¥ná varianty by neúm¥rn¥ komplikovala implementaci takového objektu - experta.
3.8
Manaºer
Mobilní objekt - manaºer je charakteristický tím, ºe bude zván jako speciální expert do cílového umíst¥ní, kde uº existuje n¥jaká kolonie p°eváºn¥ mobilních objekt·. Jelikoº mobilní prost°edí je pouze obecným nástrojem pro realizaci základní mobility, ví pramálo o konkrétní implementaci a dokonce i ve°ejném rozhraní p°ist¥hovav²ích se mobilních objekt·. N¥které objekty mohou být aktivní a nevyºadují tedy p°íli² mnoho komunikace s okolím - jejich funk£nost je do zna£né míry izolována od ostatních objekt·. Jiné objekty mohou být pasivní a vyºadují jistou míru °ízení ze strany dal²ích objekt·. Práv¥ t¥mito °ídícími objekty budou mobilní manaºe°i, kte°í o svých sv¥°encích v¥dí nejvíce a v¥dí, jak je ú£eln¥ vyuºít k realizaci rozsáhlej²ích £inností. Manaºe°i dokonce mohou být nahrazováni ve chvíli, kdy jiº jejich °ídící mechanismy nesta£í, £i jsou p°ekonány. Zasláním nového manaºera se pak dá dosáhnout, t°eba i p°i stejné sestav¥ pod°ízených objekt·, efektivn¥j²ího výsledku.
3.9
Ko£ovník
Ko£ovník velmi speci ckým typem mobilního objektu. Na jeho migraci se oproti p°edchozím typ·m objekt· podílí p°eváºn¥ jeho vlastní v·le a rozhodování. Nej£ast¥ji je migrace vyvolána pot°ebou dostat se k doposud nedostupným zdroj·m nebo se p°esunout do lépe fungujícího prost°edí. Ko£ovník musí mít schopnost jednak formulovat své poºadavky na ºivotní prost°edí a pak musí mít také k dispozici informace o stavu a vlastnostech potenciáln¥ dostupných prost°edí v okolí. Pomocí speciální t°ídy jsou popisovány jednak poºadavky ko£ovníka a zárove¬ i vlastnosti prost°edí. Tím je zabezpe£ena moºnost jednoduchého vyhodnocování poºadavk· ko£ovníka a vlastností prost°edí. K tomu, aby se ko£ovník v·bec mohl rozhodovat, zda migrovat £i ne, pot°ebuje znát seznam dostupných destinací. K tomuto ú£elu by m¥la být v po£íta£ové síti k dispozici
sluºba (MobiEnRegistry),
registra£ní
která by na základ¥ ov¥°ení klienta (objektu) po-
skytla v²echna pro n¥j dostupná mobilní prost°edí. Zdá se, ºe zavedení takové centralizované sluºby je v mobilním prost°edí opravdu t°eba aº v p°ípad¥ implementace mobilních objekt· - ko£ovník·. Ostatní modely jsou p°eváºn¥ zaloºeny na faktu, ºe výchozí, £i cílové prost°edí ví, s kým bude spolupracovat
102
Tomáš Kozel
a p°íslu²ná strana si vede sv·j vlastní registr sp°átelených £i pouºívaných prost°edí. Existence centrálního registru by ale ur£it¥ také nebyla u rozsáhlej²ích a velkorysej²ích implementací na ²kodu.
4
Záv¥r
Kaºdý z mobilních objekt· m·ºe mít charakter klasického mobilního objektu (3.1) nebo mobilního kontejneru (3.2) a lze dokonce uvaºovat i o mobilním objektu, který bude schopen po usídlení komunikovat vzdálen¥ s jinými objekty £i aplikacemi. Skupiny
Zásilka, Expert a Manaºer lze implementovat jako b¥ºné mobilní ob-
jekty li²ící se aplika£ní logikou odpovídající charakteru £innosti objekt·. Dal²í rozdíl bude spo£ívat v implementaci mechanismu p°enosu objektu. V p°ípad¥ zásilky p·jde o v¥t²inou nezvané zaslání objektu do cílového místa. U ostatních se jedná z pravidla o mechanismus vyvolaný cílovým prost°edím (pozvání). Dopravce bude nej£ast¥ji implementován jako mobilní kontejner. Pokud bude navíc tento kontejner dopravovat objekty do více destinací, je nutné tento proces °ídit bu¤ vzdálen¥, nebo lze dopravce vybavit speci ckým objektem popisujícím plán cesty. Ko£ovník je speci ckým p°ípadem, v n¥mº je proces st¥hování ovliv¬ován poºadavky mobilního objektu - ko£ovníka na pot°ebné zdroje. Ideálním vyuºitím takového mechanismu by byla automaticky °ízená distribuce aplikace do více uzl· sít¥, s p°ihlédnutím k nárok·m jednotlivých objekt· (modul·) a vlastnostem prost°edí v uzlech. Tento postup je také moºno doplnit o mechanismy zabezpe£ení rovnom¥rného distribuování zát¥ºe v síti (viz [2,3]). Tento £lánek se snaºil p°edev²ím ukázat, ºe mobilitu objekt· lze vyuºít i v oblasti softwaru a není nutné ji nahrazovat jinými °e²eními a p°ístupy. Skute£nému roz²í°ení v²ak zatím brání nedostupnost vhodného prost°edí pro tvorbu komer£ních aplikací a díky tomu i nedostatek zku²eností z nasazení reálných aplikací vyuºívajících mobilní objekty. Je samoz°ejmé, ºe i pokud se mobilní objekty obecn¥ prosadí, nikdy nenahradí stávající, zejména distribuované technologie. Ideální by v²ak bylo, kdyby se tyto technologie v budoucnu dopl¬ovaly stejn¥ jako v reálném sv¥t¥.
Reference 1. Bouchenak, S., Hagimont, D., Palma, N.: E cient Java Thread Serialization,
In
Proceedings of the 2nd international conference on Principles and practice of programming in Java, 2003, s. 35-39, ISBN:0-9544145-1-9 2. Budi, E. M., Roy, G., Cole, G.: Jawa: A Java Tool-Kit for Mobile Objects Applications, Lecture Notes in Computer Science, Volume 2604, 2003, s. 39 - 48, ISSN: 0302-9743 3. Fuad, M. M., Oudshoorn, M. J.: AdJava: automatic distribution of Java applications, Australian Computer Science Communications , Proceedings of the twenty- fth Australasian conference on Computer science - Volume 4, Australian Computer Society, Inc., 2002, ISSN:1445-1336
Třídy mobilních objektů
103
4. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Návrh program· pomocí vzor· (orig. Design Patterns - Elements of Reusable Object-Oriented Software). Praha : Grada, 2003, ISBN 80-247-0302-5 5. Karnik, N.: Security in Mobile Agent Systems, Ph.D. dissertation. Department of Computer Science and Engineering, University of Minnesota, 1998 6. Kozel, T.: Správa mobilních objekt·. In Objekty 1999, Praha: ZU Praha, 1999, s. 93-97, ISBN 80-213-0552-5 7. Kozel, T.: Metody správy mobilních objekt·. Diserta£ní práce. Hradec Králové. FIM UHK. 2005. 122s. 8. Walsh,
Annotation Mobility belongs among common characteristics of many real objects. On the other hand it is very rarely used in object-oriented software development - sometimes as a side product of using of distributed objects, other times is used consciously, but still only in an experimental manner. This contribution introduces some basic classes of mobile objects, developed as a result of the examination of the real mobility. The characterisation will stress on the usableness of these classes of mobile objects in the software development area.
Využití v širších souvislostech Využití vzorůvzorů v širších souvislostech softwarového procesuprocesu softwarového 2 MilošKudělka Kudělka11,, Vladimír Vladimír Sklenář Miloš Sklenář2 11
Inflex, Olomouc Inflex, Olomouc [email protected][email protected] 2 2 Katedra informatiky, UP,Tomkova Tomkova40,40, 779 Olomouc Katedra informatiky,PřF, PřF, UP, 779 00,00, Olomouc [email protected][email protected] Abstrakt. Mezi vývojáři jsou již dostatečné známé a používané návrhové vzory. Jejich cílem je poskytnout vývojáři praxí ověřená řešení opakujících se problémů při návrhu. V posledních několika letech se pojem vzor začal spojovat nejenom s návrhem softwarového řešení, ale s celou řadou dalších aktivit prováděných během tvorby softwarového díla. Cílem článku je poskytnout přehled o jednotlivých skupinách vzorů a možnostech jejich využití.. Klíčová slova: vzor, vývoj software Motto: „Dělejme věci tak, jak je úspěšně dělají jiní…“
1
Úvod
Myšlenka vzoru jako popisu podstaty úspěšného a praxí ověřeného řešení opakujícího se problému byla zavedena v knihách architekta Christophera Alexandera, které byly vydány na konci sedmdesátých let. Na počátku devadesátých let se stejnou myšlenku pokusila aplikovat na oblast vývoje software skupina vývojářů sdružená ve skupině nazývané Hillside Group. Cílem bylo především poskytnout řešení, která umožní vývoj flexibilního software. Proto bývá v současnosti pojem vzor v komunitě vývojářů obvykle spojován s přechodem od analýzy k implementaci konkrétního softwarového systému. Nejčastěji bývá v této souvislosti zmiňována kniha GoF [10], ve které byly poprvé systematicky popsány tzv. návrhové vzory. Praxe ukázala, že použití vzorů v této oblasti vývoje software je přínosné. Vzniklo několik klíčových publikací, které se snaží oblast návrhu softwarových systémů pokrýt v co největší míře. Dnes jsou již návrhové vzory zařazovány do výuky budoucích softwarových vývojářů. I přesto se názory vývojářů na návrhové vzory liší a pokrývají celou škálu od „…ve vzorech najdu pouze to, na co bych sám stejně přišel…“ až po „… nedělám nic, co by už v nějakém vzoru nebylo popsáno, proto nejdříve hledám vzor…“. Nechceme hodnotit, který přístup je lepší, spíše chceme pohled na vzory trochu rozšířit a položit si některé další otázky. V podstatě jde o to, že s pojmem vzor se začalo pracovat (a pracuje) i mimo softwarový návrh. Díky tomu je pravděpodobné, že pokud se seznámíme se vzory z jiné oblasti, můžeme lépe a přesněji pochopit, co od nás náš zákazník nebo spolupracovník očekává.
c Václav Snášel, editor: Objekty 2005, pp. 104–111, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Využití vzorů v širších souvislostech softwarového procesu
2
105
Co je vzor?
„Každý vzor je pravidlo, které obsahuje tři prvky a vyjadřuje vztah mezi jistou souvislostí, problémem a řešením.“ Takto jednoduše bývá citován autor pojmu vzor, architekt Christopher Alexander. V praxi je vzor pojmenovaný stručný text, který obsahuje charakteristiku problému a popis jeho obecného řešení v konkrétních souvislostech, přičemž návod řešení pak musí být tak pružný, aby se vzor dal aplikovat opakovaně a aby přitom výsledky nebyly stereotypní. Přitom je důležité, aby skupina vzorů určená pro řešení jisté, účelově zaměřené, skupiny problémů, byla popsána stejnou formou, strukturou, která zajišťuje jednotnou podobu jejich popisu. Snahou je, aby všechny části vzoru byly popsány jednoduše, výstižně a úplně. Nikde tedy není napsáno, že pojmem vzor máme rozumět pouze návrhový vzor. V posledních několika letech se pojem vzor začal spojovat nejenom s návrhem softwarového řešení, ale s celou řadou dalších aktivit prováděných během tvorby softwarového díla. Zajímavou součástí práce se vzory jsou tzv. antivzory. V nich autoři popisují ta řešení, která nevedou k úspěchu (ač se tak na první pohled může zdát). I tento prvek poskytuje zkušenost, a to mnohdy důležitější, než vzor samotný. Rádi bychom zmínili zajímavý článek (viz [3]), který se zabývá především oblastí uživatelského rozhraní a komunikace člověka s počítačem. Autor formuluje několik tezí, z nichž některé snad můžeme zobecnit a použít i v širším kontextu. Jedná se o to, že • • • •
vzory potřebují empirické důkazy pro opodstatněnost jejich užití, vzory musí být čitelné pro jejich uživatele, vzory mohou modelovat mnoho aplikačních domén, použití vzorů v softwarové architektuře, uživatelském rozhraní a aplikační doméně projektu může zlepšit komunikaci v interdisciplinárních vývojových týmech.
Za uživatele lze v kterékoli ze zmíněných oblastí považovat osoby, které v této oblasti pracují a mají zkušenosti s úspěšnými řešeními problémů. Pokud by v každé z těchto oblastí byly popsány vzory, návrháři počítačových systémů by si asi lépe porozuměli. Následující obrázek popisuje oblasti, ve kterých lze vzory používat a naznačuje, jak by potom mohl vypadat efektivně pracující vývojový tým. V takovém týmu by se lépe provazovaly, předávaly a používaly znalosti. Při pohledu na obrázek je zřejmé, že vlevo se počítá se znalostmi expertů problémové domény, uprostřed se znalostmi a očekáváními běžných uživatelů, vpravo pak se znalostmi a schopnostmi softwarových architektů a vývojářů. Pokud bychom v každé části pracovali se vzory, pak musí být jasné, že vzory musí být formulovány specialisty z řad těch, pro které jsou určeny. Tak tomu koneckonců dnes už začíná být, jak bude vidět dále v textu. Ten z vývojářů, který dnes vzory používá, jistě potvrdí, že jejich použitím se značně zprůhlední po-
106
Miloš Kudělka, Vladimír Sklenář
hled zvnějšku dovnitř systému a funkčnost velké části systému se dá mnohdy srozumitelně popsat v několika větách.
Obrázek dobře odpovídá výše zmíněnému obecnějšímu pohledu na pojem vzor. Každé softwarové řešení je realizováno v jisté doméně, s jistým uživatelským rozhraním a v jistém technickém prostředí. Je tedy zřejmé, že v každé z těchto oblastí můžeme nacházet vzory a tyto vzory pak použít pro rozhodnutí o způsobu realizace jednotlivých částí systému.
3
Kde všude se vzory můžeme setkat?
Nemáme žádnou ambici provést důslednou recenzi oblastí, ve kterých se objevují vzory. Chtěli bychom ale ukázat, že má smysl se vzory pracovat v širším kontextu, a to především v oblastech, ve kterých máme sami nějaké zkušenosti. I přesto, že se může jevit některá skupina na první pohled pro vývojáře nezajímavá, v kontextu výše uvedeného textu tomu tak vždy nemusí být. Přirozeně začneme s oblastí, která je nám nejbližší, tedy s oblastí architektury počítačových systémů. 3.1
Návrhové vzory
Mezi vývojáři nejznámější skupina vzorů. Většina z nich je popsána v knize [10]. Aplikují se při vytváření návrhu a jsou zaměřeny především na zajištění flexibility programu, tj. jejich schopnosti snadno se přizpůsobit přicházejícím změnám. Mnoho dalších návrhových vzorů je pouze jejich speciálním případem, realizovaných v konkrétním prostředí nebo případem detailněji rozpracovaným. Lze snad říci, že tato oblast je již mezi vývojáři vnímána víceméně jako samozřejmost a znalost vzorů z této oblasti se předpokládá.
Využití vzorů v širších souvislostech softwarového procesu
3.2
107
Analytické vzory
V této oblasti bývá zmiňována především kniha [8]. Analytickými vzory autor rozumí takové vzory, které jsou víceméně nezávislé na problémové doméně a popisují řešení problémů na konceptuální úrovni, která je minimálně závislá na budoucí implementaci. V podstatě vzory popisují vztahy mezi klíčovými byznys prvky systému. Tato oblast vzorů by se v žádném případě neměla podceňovat, protože dobrý analytický návrh je nutnou podmínkou kvalitní implementace. 3.3
Vzory orientovaná architektura
Pro používání vzorů na úrovni architektury systému měla podobný význam jako pro návrhové vzory GoF kniha [4]. Tyto dvě knihy složí dodnes jako základní literatura pro všechny nové zájemce. S růstem počtu distribuovaných aplikací se k nim přiřadila kniha [21], která je vlastně druhým dílem. Věnuje se vzorům pro přístup ke vzdáleným službám, pro obsluhu událostí, pro zajištění souběžného zpracování a synchronizaci. 3.4
Vzory pro podniková řešení
Další oblastí pokrývanou vzory, které je věnována v poslední době značná pozornost, a to i ze strany komerčních firem, je vytváření aplikací velkého rozsahu, například na úrovni podnikových informačních systémů. Na návrh takové aplikace se totiž můžeme podívat z různých hledisek, která odpovídají např. úrovni abstrakce pohledu na systém či pohledu na způsob implementace některé konkrétní části systému.Tento přístup vede ke snaze v maximální možné míře definovat pro vývoj informačních systémů prostředí, které na jedné straně poskytne dostatečnou flexibilitu a na druhé straně základní schémata, která umožní používat a sdílet zkušenost jako jeden základních prvků efektivního vývoje. Nejlepšími zdroji pro tuto oblast jsou knihy [9,23]. 3.5
Vzory pro integraci
Integrace systémů je jednou z aktuálních úloh současné doby. Ani této oblasti se nevyhnula snaha o formulování vzorů. Pro tuto problematiku lze doporučit knihu [13], která tuto oblast popisuje velmi důsledně. 3.6
Vzory pro testování
Zajímavým, velmi stručným a čitelným katalogem vzorů je [5], kde se autor zabývá vzory pro tzv. unit testing. Kromě toho vyšlo několik knih zabývajících se tuto problematikou v širším měřítku.
108
3.7
Miloš Kudělka, Vladimír Sklenář
Vzory pro správu softwarových konfigurací
Ve spojení se správou verzí a s dalšími úlohami s tím spojenými vzniká potřeba dobře popsat, jak tyto úlohy řešit. Lze doporučit knihu [2], která (byť poněkud rozvláčně) popisuje prostřednictvím vzorů, jak jednotlivé úkoly realizovat. 3.8
Vzory pro tvorbu uživatelského rozhraní
Grafické uživatelské rozhraní je z pohledu uživatele nejdůležitějším prvkem aplikace a jako s takovým se s ním musí zacházet. Důležitou vlastností dobře navrženého uživatelského rozhraní je dodržování ergonomických zásad a standardů, které s rozvojem kvality počítačů přispívají ke kvalitě komunikace člověka s počítačem. I zde se dá velmi efektivně (a v tomto případě i velmi efektně) popsat většina kompozic a akcí v běžných systémech a aplikacích prostřednictvím vzorů [15, 23]. 3.9
Vzory pro e-learning
Katalog vzorů na [29] slouží k popisu vlastností, které jsou očekávány u e-learningového systému a jeho obsahu. Vzory byly nalezeny v profesionálních systémech a jako takové na obecné úrovni popisují systémy jako sobě rovné. 3.10 Pedagogické vzory Při výuce se učitel i posluchač časem dostává do stejných situací. Vzniká tedy určitý stereotyp – daný problém se řeší obdobně, jistou metodou. Takto vnímané metody se dají popsat prostřednictvím vzorů, které lze najít především na [30]. Kromě jejich možného použití pro návrh nebo hodnocení systému, lze tyto vzory aplikovat při proškolování uživatelů. 3.11 Vzory pro návrh zákaznicky orientovaných webů V knize [25] je popsáno mnoho vzorů, které lze použít při návrhu a implementaci komerčních webových stránek. Kniha vyšla i v češtině a poskytuje opravdu podrobný soupis mnoho z toho, co je potřeba pro návrh úspěšného webu, a to vše opět prostřednictvím vzorů. 3.12 Vzory pro psaní vzorů Nakonec v tomto (zcela jistě neúplném) seznamu oblastí pokrývaných vzory nemůže chybět odkaz na materiál, ve kterém se autoři podrobně zabývají tím, jak vzory hledat a jak je správně formálně popsat [19].
Využití vzorů v širších souvislostech softwarového procesu
4
109
Jakým způsobem lze vzory použít?
Kromě toho, že vzory se prostě vyhledají a problém se řeší s jejich pomocí, můžeme zdůraznit některá další použití. 4.1
Vzory jako slovník
Možná nejdůležitější vlastností vzorů je to, že se pro jejich pojmenování používají výrazy, které výstižně charakterizují, o co se ve vzoru jedná. Použitím těchto výrazů v komunikaci pak velmi usnadní vzájemné pochopení toho, o čem se mluví. Mnohdy ani člověk nemusí mít detailní představu o tom, co přesně vzor při realizaci přináší za problémy, ale na komunikační úrovni to postačuje. 4.2
Vzory jako součást dokumentace
Použité vzory by se měly stát nezbytnou součástí dokumentace. Celá dokumentace se tím může velmi zjednodušit, protože ze vzoru vyplývá, jak se problém řešil. Je možné dokonce říct, že čím lépe dokumentujeme vzory, tím méně musíme dokumentovat detaily (které automaticky vyplynou z použití vzoru). 4.3
Vzory jako kontrola řešení
Pokud se zaměříme na vzory z oblasti aplikační domény (např. e-learning, výuka, komerce, správa verzí apod.), pak můžeme existující (nebo navrhovaný) systém měřit tím, jaké vzory jsou v něm realizovány. Jednoduše tak zjistíme, zda je pro uživatele vhodný a zda má (či bude mít) očekávané vlastnosti. Např. i v pedagogických vzorech lze najít takové, které dají odpověď na otázku, jak by měla vypadat výuková aplikace. 4.4
Hodnocení kvality software podle použitých vzorů
Fakt, že vzorem se může stát pouze řešení, které se opakovaně ukázalo jako úspěšné dává jistou záruku, že jeho další použití bude opět fungovat. Správná volba a použití vzorů v daném kontextu vyvíjené aplikace by tedy mohla poskytovat jistou záruku kvality a spolehlivosti. Od tohoto předpokladu již není daleko myšlence, že volba vzorů a způsob jejich použití by mohly sloužit jako jedno z kritérií při posuzování kvality práce vývojáře (a tím myslíme vzory pro všechny činnosti spojené s vývojem – analýza, návrh, testování, dokumentování, verzování). Ve své praxi se při vývoji běžných softwarových aplikací přikláníme spíše k myšlence, že pokud existuje na některou situaci vzor, měli bychom se především snažit jej použít. Není nám proto cizí názor, že použití vzoru by mělo být standardem a jeho nepoužití by mělo být zdůvodněno.
110
Miloš Kudělka, Vladimír Sklenář
Jsme si samozřejmě vědomi toho, že mechanické aplikování takovéhoto požadavku by za určitých okolností mohlo způsobit více škody než užitku. Samotný fakt, že byl použit vzor totiž ještě neznamená, že použitý vzor je vhodný pro kontext dané aplikace a že byl použit správně. Pro zkušeného projektového manažera je ale posouzení vhodnosti vzoru rozhodně snadnější úkol, než vyhodnotit všechny důsledky použití zcela nového neověřeného řešení.
5
Závěr
V textu jsme se snažili nabídnout širší pohled na použití vzorů při vývoji a hodnocení softwarových systémů. To, že vzory se hledají a úspěšně nacházejí i v oblastech, které s tvorbou softwarových systémů na první pohled nijak nesouvisí, svědčí o opodstatněnosti jejich použití. Domníváme se, že orientace ve vzorech v různých (i jiných než softwarových) oblastech, může velmi pomoci vývoji kvalitních počítačových systémů pro tyto oblasti.
Reference 1. Alexander, Ch. A Pattern Language. New York. Oxford University Press 1977. 2. Berczuk, S., P., Appleton, B. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison Wesley 2002. ISBN : 0-20174117-2. 3. Borcher, J.: Interaction Design Patterns: Twelve Theses. 4. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. PatternOriented Software Architecture. A system of patterns., John Wiley & Sons 1996, ISBN 0-471-95869-7. 5. Clifton, M. Advanced Unit Test, Part V - Unit Test Patterns. http://www.codeproject.com/gen/design/autp5.asp. Code Project 2004. 6. Cooper, J. C# Design Patterns: A Tutorial, Addison-Wesley 2002, ISBN 0-20184453-2 7. Coplien, O., Schmidt, D. Pattern Languages of Program Design 1 AddisonWesley 1995. ISBN 0-201-60734-4 8. Fowler, M. Analysis Patterns. Reusable Object Models. Addison-Wesley 1997, ISBN 0-201-89542-0 9. Fowler, M. Patterns of Enterprise Application Architecture, Addison-Wesley 2003, ISBN 0-321-12742-0 10. Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley 1995. ISBN 0-201-63361-2 11. Gamma, E., Helm, R., Johnson, R., Vlissides, J. Návrh programů pomocí vzorů. Stavební kameny objektově orientovaných programů. GRADA 2003, ISBN 80247-0302-5.
Využití vzorů v širších souvislostech softwarového procesu
111
12. Harrison, N., Foote, B., Rohnert, H. Pattern Languages of Program Design 4 Addison-Wesley 1999. ISBN 0-201-43304-4 13. Hohpe, G., Woolf, B. Enterprise Integration Patterns. Addison-Wesley 2003. ISBN 0321200683. 14. Kraval, I. Design Patterns v OOP se zaměřením na JAVU, C# a Delphi. www.objects.cz 15. Kudělka M.. Vzory pro HCI a GUI. Sborník konference Tvorba softwaru 2004, Ostrava 2004, ISBN 80-85988-96-8. 16. Larman, C. Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and the Unified Pracess. Second Edition. Prentice Hall 2001, ISBN 0-13-092569-1 17. Martin, R. Agile Software Development. Principles, Patterns, and Practices. Prentice Hall 2002, ISBN 0-13-597444-5 18. Martin, R., Riehle, D., Buschmann, F. Pattern Languages of Program Design 3 Addison-Wesley 1998. ISBN 0-201-31011-2 19. Meszaros, G., Doble, J. A Pattern Language for Pattern Writing. http://hillside.net/patterns/writing/patternwritingpaper.htm. 20. Rising, L. The Pattern Almanac 2000, Addison-Wesley 2000 21. Schmidt, D., Stal, M., Rohnert, H., Buschmann, F. Pattern-Oriented Software Architecture. Volume 2. Patterns for concurrent and Networked Objects. John Wiley & Sons 2000, ISBN 0-471-60695-2. 22. Shalloway, A., Trott, J. Design Pattern Explained. A new perspective on objectoriented design, Addison-Wesley 2001, ISBN 0-201-71594-5 23. Tidwell, J. UI Patterns and Techniques. http://time-tripper.com/uipatterns/. 24. Trowbridge, D., Mancini, D., Quick, D., Hohpe, G., Newkirk, J., Lavigne, D. Enterprise Solution Patterns using Microsoft.NET Version 1.0. Microsoft Corporation 2003. 25. Van Duyne D. K., Landay J. A., Hong J. I. The Design of Sites: Patterns, Principles, and Pro-cesses for Crafting a Customer-Centered Web Experience. Pearson Education 2002. ISBN 020172149X. (česky CP BOOKS, 2005) 26. Vlissides, J. Pattern Hatching. Design Patterns Applied, Addison-Wesley 1998, ISBN 0-201-43293-5 27. Vlissides, J., Coplien, O., Kerth, N.. Pattern Languages of Program Design 2 Addison-Wesley 1997. ISBN 0-201-60734-4 28. Yacoub, S., Ammar, H. Pattern-Oriented Analysis and Design: Composing Patterns to DesignSoftware System Addison-Wesley 2003. ISBN 0-201-77640-5 29. http://www2.tisip.no/E-LEN/patterns_info.php 30. http://www.pedagogicalpatterns.org/
Řízení projektů v metodě BORM Řízení projektů v metodě BORM Branislav Lacko Branislav LACKO1
Ústav automatizace a informatiky, Fakulta strojního inženýrství, VUT v Brně, Technická 2, 616 69 Brno [email protected][email protected] Abstrakt. Příspěvek navrhuje doplnění metody BORM o fáze z hlediska potřeb řízení projektu návrhu a realizace automatizovaného informačního systému. Klíčová slova: objektově orientovaná metoda analýzy a návrhu, projektové řízení, studie příležitosti, studie proveditelnosti, projekt automatizovaných informačních systémů, softwarové inženýrství.
1
Úvod
V příspěvku na konferenci Objekty 2004 [10] vysvětlil autor potřebu a nutnost doplnit do metod pro analýzu a návrh informačních systémů pohled projektového řízení, který by doplňoval pohled softwarového inženýrství. Takové řešení podstatně zvyšuje pravděpodobnost úspěchu projektu návrhu a realizace automatizovaného informačního systému. Předkládaný příspěvek popisuje návrh na doplnění metody BORM [1] o prvky projektového řízení.
2
Motivace a východiska
Motivací pro obohacení metody BORM o prvky projektu odrážející principy projektového řízení jsou jednak současné požadavky na projekty automatizovaných informačních systémů, jednak zkušenosti s postupným vývojem metody SSADM, která byla zdokonalována v závěru svého zlepšování právě o etapy, které odrážely principy a zásady projektového řízení. Metoda strukturované systémové analýzy a systémového návrhu [2] byla navržena v prvních dvou verzích podle zásad systémového přístupu, s využitím technik diagramů datových toků (Data Flow Diagram), diagramu logické struktury dat (Logical Data Structure), diagramů životních cyklů datových entit (Entity Life History) a několika dalších podpůrných technik (Third Normal Form Analysis, Logical Update Process Outline, Logical Enquiry Process Outline, Composite Logical Data Design). Metoda byla rozdělena do dvou fází – Fáze analýzy a Fáze návrhu. Každá z fází obsahovala tři etapy. Etapy se dále dělily na jednotlivé kroky (Steps) a kroky na úkoly (Tasks). Aplikace metody v praxi ukázala potřebu předřadit před fázi analýzy úvodní fázi, která by definovala řešenou problematiku a sestavila návrh projektu automatizovaného informačního systému. Etapy 01 a 02 umožňovaly dohodnout s uživatelelem a zákazníkem (představovaným obvykle jednou a toutéž firmou)
c Václav Snášel, editor: Objekty 2005, pp. 112–121, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Řízení projektů v metodě BORM
113
rozsah provedených analytických prací a správné zacílení prováděné analýzy a návrhu systému. Stávalo se totiž, že se analyzovaly a rešily oblasti, které nebyly předmětem zájmu zákazníka, který pak následně odmítl platit náklady na jejich provedení. Tím, že bylo dohodnuto předem, z jakých hledisek a s jakými cíly budou analýzy a návrh prováděny, bylo zaručeno, že výsledný systém bude co nejlépe splňovat požadavky uživatele. Strukturu SSADM verze 3.0 ukazuje obr.1. Ve verzi 4.2., jak ukazuje tab.1 byl ještě výrazněji zdůrazněn význam studie proveditelnosti (Feasibility Study) ve smyslu zásad projektového řízení. Studie proveditelnosti zde představuje analýzu těch podnikových procesů na nejvyšší úrovni, které určují, jak může navrhovaný systém podpořit efektivně vznesené požadavky. Dále odpovídá studie na otázky, zda je projekt: • Technicky možný • Finančně a sociálně ustálen • Přijatelný pro firmu • apod. Pro úspěch realizace informačního systému je zodpovězení podobných otázek velmi důležité a představuje zároveň získání podkladů pro strategické rozhodnutí, zda projekt dále v dané podobě realizovat nebo jej zastavit a přehodnotit. Proto např. metoda SSADM (Structured System Analysis and Design Metod) do své třetí verze v počátku devadesátých let zařadila jednak novou fázi s názvem “Úvodní projekt”.
114
Branislav Lacko
Etapy
Fáze
01Definice problému
Fáze úvodního projektu 02Sestavení projektu
1 Analýza st. systému
Fáze analýzy
2 Specif. požadavků
3 Výběr techn. řešení
4 Návrh struktury dat
5 Návrh procesů
Fáze návrhu 6 Fyzický návrh
Obr. 1. Struktura SSADM verze 3.0
Do verze 4.2 nap následně byla doplněna studie proveditelnosti, jako samostatná fáze a činnosti spojené s řízením projektu byly doplněny k činnostem, které se týkají návrhu dat a funkcí informačních systémů. Tabulka 1. Struktura SSADM verze 4.2
1 Studie proveditelnosti 2 Analýza požadavků na informační systém 3 Specifikace požadavků na systém 4 Specifikace systému na logické úrovni 5 Realizace systému U metody RUP (Rational Unified Process) firmy Rational Software Corporation. bylo projektové řízení zapojeno v rámci metody jako nedílná součást po celou dobu vývoje navrhovaného systému (viz stránky této firmy www.rational.com). Metoda projektové řízení využívá jako podpůrnou disciplínu, zajišťující plánování a koordinaci projektu v průběhu všech fází (viz obr.1).
Řízení projektů v metodě BORM
115
Obr. 2. RUP – Rozdělení do fází a použité dosciplíny
Z výše uvedených příkladů vyplývá, že obohacení metody BORM o činnosti, které jsou spojeny s řízením projektu, rozhodně vytvoří předpoklady pro další zdokonalení metody a její efektivní používání. Cílem obohacení metody je prostřednictvím zejména předporjektových fází zajistit přijetí všech strategických rozhodnutí, které jsou potřebná pro úspěšný průběh návrhu informačního systému . Zkušenosti ukazují, že v řadě případů se taková rozhodnutí provádějí v praxi pozdě, což značně komplikuje realizaci návrhu informačního systému nebo nejsou provedena v průběhu projetu vůbec, což se negativně projeví při ukončování projektu, kdy uživatel kritizuje celou řadu nedostatků softwarového produktu resp. celého informačního systému.
3
Návrh řešení
3.1 Stávající fáze BORM 3.2 Doplněné etapy předprojektové fáze 3.2.1 Význam doplněných etap Význam doplněných etap spočívá v zajištění konkretizace cíle (resp.cílů), který má naplnit plánovaný informační systém. Co nejpřesnější specifikace cíle informačního systému má umožnit, aby realizátoři mohli zajistit všechny funkce, které zjistí splnění cíle. Cíl je zde představován zamýšleným výsledkem našeho snažení a představuje zodpovězení otázky: „Čeho se má dosáhnout?“ S tím souvisí
116
Branislav Lacko
zodpovězení navazující otázky: „Proč se má cíle dosáhnout?“ Ve většině případů lze cíl dosáhnout různými prostředky a různými způsoby. Je proto velmi důležité stanovit základní směry postupu k cíle a podmínky pro tento postup (plánovaný čas dosažení cíle, plánované náklady na dosažení cíle, přidělené zdroje, které budou k dispozici pro realizaci cíle. Pokud se tyto strategické věci nestanoví předem, je velká pravděpodobnost, že se cíle nedosáhne a náklady překročí, jak to dokazuje celá řada projektů takto realizovaných v oblasti IT. 3.2.2 Etapa Goal Idetification Obsahem této etapy je identifikace a definice cíle informačního systému tj. jednotlivých funkčních a provozních parametrů, které mají zajistit poskytování požadovaných informací pro rozhodování ve firemních procesech. Je nutno vymezit očekávané přínosy automatizovaného informačního systému a také obsah a rozsah celé akce. Specifikují se předpoklady, ze které byly použity při stanovování cílů a vymezují se kritéria, podle kterých se bude posuzovat dosažení cíle. Zvažují se strany dotčené celou akcí a stanovují se zainteresovaní účastníci. Provádějí se první odhady potřebného objemu finančních prostředků a hledají se zdroje financování. Navrhuje se plánovaný termín ukončení akce a základní milníky. Analyzují se významná rizika, která mohou ovlivnit negativně úspěch celé akce. Zvažují se vhodné osoby, které by se podílely na řízení akce. Používají se takové metody jako: • Analýza silných a slabých stránek ( SWOT Analysis) • Metoda logického rámce (Logical Framework Method) • SMART ( i ) princip stanovení cíle • Analýza kritických faktorů úspěchu (Critical Success Factors Analysis) • Metoda stromu cílů • Metoda dekompozice problémů • apod. Stručný přehled koncept SWOT, SLEPT, PORTER analýz a metody logického rámce viz přílohy příspěvku. 3.2.3 Etapa Project Definition V této etapě se hledají způsoby, jak řešit návrh a realizaci informačního systému, a vybírá se optimální postup. Zpřesňují se odhady potřebného času, nákladů a zdrojů pro projekt. Sestavuje se návrh zadávací listiny projektu. Specifikují se podmínky a zásady pro použité technické a programové prostředky. Zpřesňují se odhady pro očekávané přínosy. Provádí se finanční a ekonomická analýza základních ukazatelů (doba návratnosti, míra zhodnocení investic, apod.). Navrhují se akceptační testy apod.
Řízení projektů v metodě BORM
117
Používají se takové metody jako: • Ganttovy diagramy • Vícekriteriální analýza • Analýza nákladů a přínosů ( Cost/Benefit Analysis, COCOMO, UCP, apod.) • Hodnotová analýza (Value Analysis) • Modelování a simulace • apod. Výsledkem je návrh zadávací listiny projektu.
4
Doporučení a závěr
Doporučuji ověřit návrh na některém z nejblíže zahajovaných návrhů informačního systému, který bude prováděn metodou BORM a vyhodnotit získané zkušenosti. K ověření návrhu je nutno vytvořit předpoklady tím, že pracovníci, kteří budou ověření provádět by měli mít znalosti z projektového řízení, zejména by měli být seznámeni s problematikou předprojektových fází. Tento příspěvek deklaruje základní principy, kroky a metody. Při začlenění do metody BORM bude podrobněji rozpracován popis obou etap, aby týmy mohly popis využít pro podporu své práce. Úspěch zavádění informačních systémů a informačních technologií obecně závisí velmi významně na kvalitním návrhu a dobře řízeném projektu. Bylo by zbytečné zde citovat a uvádět odkazy publikace a materiály, které popisují a dokumentují neutěšený stav v oblasti projektů ICT, které končí ve velké míře neúspěšně! Zdá se, že objektově orientovaná technologie přinesla významný pokrok a zdokonalení v oblasti analýzy a návrhu automatizovaných informačních a řídicích systémů. Jistě je možno očekávat ještě řadu dalších zlepšení jednotlivých technik a postupů. V nejbližším horizontu několika let to však budou spíše dílčí, postupná, drobná vylepšení stávajícího stavu. Významnou myšlenkou, se kterou přichází projektové řízení, je zdůraznění, že při návrhu projektu je potřeba věnovat velkou pozornost strategickým úvahám, které formují projekt. Proto je potřeba vzít v úvahu i změnu priorit v kladení otázek před startem projektu
118
Branislav Lacko
Množství vynaloženého úsilí na zodpovězení otázky
Proč?
Co? Kdy? Jak? čas Start projektu
Konec projektu
Právě předprojektové fáze hledají odpovědi na otázky typu: Proč se má projekt realizovat? Co projektem sledujeme? Zásadní změnu je potřeba očekávat v aplikací jakostního projektového řízení na příslušný projekt tak, aby byla vytvořeny předpoklady pro dosažení konečného úspěchu. Vysoké procento neúspěšných projektů v oblasti ICT má příčinu také ve špatném řízení projektu, nejen ve špatně provedené analýze a návrhu dat, procesů a událostí z hlediska zpracování informací. Jakost správného nasměrování projektu zdůrazňují jak rigorózní, tak agilní metody tvorby informačních systémů [11] i když samozřejmě pohled na detailní plánování a řízení projektů se v těchto metodách liší i články o významu dobré analýzy informačních systémů [12]. V souvislosti s požadavkem zajištění úspěšného projektu vystupuje do popředí problematiku vyjasnění a specifikace požadavků uživatele navrhovaného informačního systému. Specifikace požadavků na systém je totiž klíčovým faktorem jakosti informačního systému (viz ISO 9000 - Jakost, schopnost produktu nebo služby uspokojit požadované i předpokládané požadavky zákazníky) a základem pro jeho konečné testování (Není-li něco dobře specifikováno, jak je možno se přesvědčit, že to bylo dobře splněno?!) Skloubením hledisek softwarového inženýrství, projektového managementu a řízení jakosti je možno vytvořit synergický efekt, který umožní dosáhnout lepších informačních systémů než dosud, kdy často tato hlediska byla aplikována izolovaně nebo nekomplexně.
Řízení projektů v metodě BORM
119
Seznam literatury 1. Merunka,V.-Polák,J.-Carda,A.: Umění systémového návrhu. Grada Publishing 2003 Praha 2. Nicholls, D.: Introducing SSADM (The NCC Guide). National Computer Centre for Information Technology1987 Menchester, 58 p. 3. Úvod do metodologie SSADM (3.verze). Studijní materiály pro účastníky kurzu. Polytechna 1992 Praha, 113 str. 4. SSADM – Základný štrukturálny model (Verzia 4.2). INFOSTAT 1996 Bratislava, 83 str. 5. Berrinford,G.-Robinson,K.: Object oriented SSADM. Prentice Hall 1994, 375 p. 6. Rational Unified Process. IBM/Rational Software 2003 7. Beránek,M.-Slabý,A.: Řízení projektu dle RUP využívající princip KKTR. In: Sborník konference OBJEKTY 2004. ČZU Praha 2004, str. 47-56 8. EUROMEHTOD Overview (EM-1-EO). Euromethod Project 1994, 30 p. 9. Introduction to ISPL. Ten Hagen & Stam 1999 Hague , 39 p. 10. Lacko,B.: Metodologie objektově orientovaných metod: současnost a cesty vývoje. In: Sborník konference OBJEKTY 2004. ČZU Praha 2004, str.147152 11. Buchalcevová, A.: Metodika Feature-Driven Development neopouští modelování a procesy, přesto přináší výhody agilního vývoje. In: Sborník konference Tvorba softwaru 2005. VŠB-TU Ostrava 2005, str. 25-30 12. Merunka, V.: Objektově orientovaná analýza informačních systémů. In: Professional Computing, DCD Computing Praha, 2005
Cíl projektu Účel projektu Konkrétní výstupy projektu Klíčové činnosti Zde uvedený logický rámec je prezentován v podobě, která je vhodná pro firemní projekty, jak ji uvedla do povědomí firma Team Technologies. Je možno však použít logický rámec ve formě, jakou používá Evropská unie pro své strukturální projekty. Příloha č. 2 - SLEPT Analysis (vliv změn v obecném okolí ) • • • • •
Social - sociální hledisko Legal - právní a legislativní hledisko Economic - ekonomické hledisko Policy - politické hledisko Technology - technické hledisko
Příloha č. 3 – SWOT Analysis (Analýza silných a slabých stránek) • • • •
Příloha č.4 - Porter´s Analysis Porterův model vlivu oborového okolí (mikroprostředí) • • • • •
Rivalita v oboru Hrozba vstupu nových konkurentů Vyjednávací vliv dodavatelů Vyjednávací vliv velkoodběratelů a zákazníků Hrozba substitutů
Resumé The contribution describes two new proposal stages for BORM method – Goal Definition and Project Definition. The contents of these stage and some method ( for example logical framework method, SWOT analysis, critical success factors analysis, Gantt chart, multiple criteria decision analysis) are recommended for realization of these stages.
Využití Využití OCL OCL k k popisu popisu vztahů vztahů mezi mezi přístupovými přístupovými právy a rolemi právy a rolemi Martin Lasoň a Pavel Gavlovský Martin Lasoň, Pavel Gavlovský Katedra informatiky, FEI, VŠB – Technická Univerzita Ostrava, Katedra informatiky, FEI, Technická Univerzita Ostrava 17. listopadu 15,VŠB 708 –33, Ostrava-Poruba 17. listopadu 15, 708 33, Ostrava-Poruba {martin.lason, pavel.gavlovsky}[email protected] {martin.lason, pavel.gavlovsky}[email protected]
Abstrakt. Kontrola přístupu uživatelů do systému má v dnešní době velký význam. Velký zájem v této oblasti vzbudil pro svou flexibilitu model RBAC (anglicky Role-based access control). Jednou z důležitých vlastností RBAC je možnost nastavení různých omezení na jeho komponenty. Tento článek ukazuje, jak tato omezení mohou být popsána pomocí jazyka OCL a jak je lze začlenit do UML diagramů. V UML diagramech lze navíc identifikovat entity, které mají vztah k bezpečnostnímu modelu. Cílem tohoto článku je představit postup, jak lze tyto entity a vztahy mezi nimi automatizovaným způsobem převést na model přístupových práv a nastavit příslušná omezení.
Klíčová slova: OCL, RBAC, UML, bezpečnost.
1
Úvod
RBAC omezuje přístup uživatelů k informacím a systémovým zdrojům na základě aktivit, které uživatelé potřebují vykonávat v systému. Uživatelé však nejsou přiřazeni ke svým přístupovým právům přímo, ale každý uživatel má definovánu množinu rolí, ve kterých může vystupovat. Roli můžeme definovat jako množinu akcí a odpovědností spjatých s konkrétní pracovní činností. Použitím RBAC modelu dochází k omezení složitosti, nákladů a potenciálních chyb při přiřazování přístupových práv. Definování RBAC modelu je časově náročná činnost, zvláště pokud se jedná o systém ve kterém se uživatelé mohou vyskytovat ve velmi mnoha rolích. V naší práci se pokoušíme definovat proces, pomocí kterého by bylo možno vytvořit základní model rolí a práv na základě UML diagramů, které vznikají ve fázi analýzy vývoje softwaru. V omezené míře lze k tomuto účelu použít existujících nástrojů, jak jsme ukázali v [2]. Aby bylo možné získat co možná nejvíce informací o budoucích přístupových právech, vytvořili jsme vlastní algoritmus na získávání potřebných informací z aktivitních diagramů [3]. Tento algoritmus však doposud nedokázal pracovat s omezeními, která mohou být na role či práva kladena. Proto chceme ukázat možnosti, jakými lze omezení kladená na role a přístupová práva vyčíst z běžných UML diagramů.
c Václav Snášel, editor: Objekty 2005, pp. 122–133, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Využití OCL k popisu vztahů mezi přístupovými právy a rolemi
123
Omezení v RBAC modelu je možné vyjádřit pomocí přirozeného jazyka, jakým může být například čeština, nebo pomocí formálního jazyka. Přirozený jazyk má výhodu v tom, že je dobře srozumitelný pro většinu vývojářů, ale jeho nevýhodou je jeho nejednoznačnost. Z tohoto důvodu byl pro popis RBAC omezení vyvinut formální jazyk RCL2000 [5]. Tento jazyk však znají spíše bezpečnostní návrháři, ale nelze předpokládat jeho znalost u softwarových analytiků. Proto jsme se rozhodli pro vyjádření těchto omezení použít standard OCL popisující omezení v UML. V následujících kapitolách nejprve popíšeme RBAC model a ukážeme způsoby, jak lze pomocí OCL specifikovat omezení kladené na prvky RBAC modelu. V závěru pak představíme způsob, jakým se nám povedlo automatizovat extrahování informací o omezeních RBAC modelu z UML diagramů.
2
RBAC
Role-Based Access Control (RBAC) je silný bezpečnostní model pro správu autorizací. Základní myšlenkou RBAC je, že uživatelé nemají přímý přístup k objektům. Místo toho jsou přístupová práva administrativně spjata s rolemi a uživatelé jsou nastaveni jako členové příslušných rolí [1]. Tento přístup velmi zjednodušuje správu přístupových práv. Při použití RBAC modelu je možné uživatelům jednoduše přidávat a odebírat přístupová práva, která potřebují k vykonávání své profese. Přiřazením uživatele ke konkrétní roli tak dojde k přidělení všech přístupových práv spjatých s touto rolí. Při změně role uživatele v organizaci (např. při povýšení nebo změně zařazení) dojde pouze ke změně asociace mezi uživatelem a příslušnými rolemi. Tím se snižuje riziko, že zaměstnanec nebude mít nastavena všechna práva nutná k vykonávání své profese. Snižuje se tím složitost přidělování nových práv a také riziko, že některá nebudou uživateli včas odebrána. V základním RBAC modelu jsou definovány role a přístupová práva, která omezují přístup k systémovým zdrojům. RBAC model má následují komponenty, které lze formalizovaně zapsat takto: – – – – – – – – –
U je množina uživatelů, R je množina rolí, P je množina práv, U A ⊆ U ×R, je relace mezi množinou uživatelů a množinou rolí odpovídající vazbě M : N , P A ⊆ P × R, je mapování M : N přístupových práv na role, RH ⊆ R × R je částečné uspořádání hierarchie rolí (často zapisované symbolem ≥ v infixové notaci), S je množina sezení, user sessions(u : U ) → 2S , je mapování uživatelů do množiny sezení. session roles(s : S) → 2R , je mapování sezení do množiny rolí. Formálně: session roles(si ) ⊆ {r ∈ ROLES|(session roles(si ), r) ∈ U A}.
124
Martin Lasoň, Pavel Gavlovský
RBAC model se skládá ze čtyř částí: jádro modelu RBAC, hierarchický model, statická omezení (SSD) a dynamická omezení (DSD). Jádro modelu RBAC je jedinou z těchto částí, která musí být vždy implementována. Ostatní části jsou volitelnými nadstavbami, které je možno vynechat. Zatímco hierarchie rolí, umožňující dědičnost práv je poměrně často využívána (snad také pro svou podobnost s dědičností mezi objekty), statická a dynamická omezení jsou poměrně často a neprávem opomíjena. Přitom toto je jediná systémová možnost, jak ochránit systém proti střetu zájmů jednotlivých uživatelů. Proto se v dalším textu zaměříme právě na tato omezení. 2.1
Statická a dynamická omezení
Vztahy statických omezení SSD (anglicky Static Separation of Duty) se využívají k vynucování zásad definovaných konfliktů zájmů. Konflikt zájmů může vzniknout při autorizaci získáním přístupových práv asociovaných ke konfliktním rolím. Jednou z možností, jak se vyhnout střetu zájmů pomocí SSD je uplatnění omezení na vazby mezi uživateli a rolemi. Příkladem takového střetu zájmů může být situace, kdy jedna role provádí výdaje prostředků a druhá slouží ke schvalování těchto výdajů. V organizaci by tyto dvě role neměly být přiřazeny stejnému uživateli. – Statické omezení (anglicky Static Separation of Duty nebo jen SSD) – jedná se o omezení kladené na vazby mezi uživateli a rolemi. Členství uživatele v jedné roli může zabránit, aby se tento uživatel stal členem jedné nebo více rolí, na které jsou uplatněny SSD pravidla. V případě hierarchie rolí je možné tato pravidla vztáhnout i na všechny zděděné role. Obrázek 1 graficky znázorňuje, na které vazby se SSD omezení vztahují. – Dynamické omezení (anglicky Dynamic Separation of Duty nebo jen DSD) – podobně jako SSD omezují práva, která může uživatel získat. Rozdíl je v kontextu, na který jsou tato omezení uvalena. DSD omezení jsou uvalena na role, které mohou být najednou aktivovány v rámci uživatelova sezení.
Obr. 1. Statická omezení v RBAC modelu
Využití OCL k popisu vztahů mezi přístupovými právy a rolemi
125
Vzhledem k tomu, že se v dalším textu budeme zabývat automatickým generováním RBAC modelu z UML diagramů, musíme se omezit jen na část RBAC modelu, kterou jsme schopni používat. První komponentou, kterou musíme v automatickém generování vynechat je množina uživatelů. Je zřejmé, že analytik, v době kdy vytváří aktivitní diagramy, nezná konkrétní uživatele, kteří budou se systémem pracovat. Proto nelze automaticky vygenerovat z UML diagramů množinu uživatelů pro RBAC model. Pokud bude potřeba se nějak odkazovat na množinu uživatelů, bude to pouze pomocí abstraktní třídy zastupující uživatele. Druhou komponentou, kterou nelze automaticky vygenerovat je množina sezení, neboť se jedná o systémově závislou komponentu [1]. Z tohoto důvodu nemůžeme ani pracovat s dynamickými omezeními DSD a soustředíme se pouze na SSD.
3
Object Constraint Language
Object Constraint Language (OCL) je formální jazyk sloužící k definování omezení nad prvky UML modelu [7]. Obvykle (a v našem případě také) je využíván k definování invariantů, neboli podmínky, která musí být v každém okamžiku života vytvořeného modelu pravdivá. Na rozdíl od čistě matematických jazyků, OCL se vztahuje k UML modelu, tj. využívá k definici omezení asociace mezi jednotlivými třídami a vlastnostmi daných prvků modelu. Jeho zápis je podobný zápisu kódu objektového programovacího jazyka. Každý zápis v jazyce OCL je vztažen k danému kontextu, kterým je konkrétní prvek UML modelu. K tomuto účelu je definováno klíčové slovo context za nímž následuje název daného prvku – ve většině případů třídy. Deklaraci uzavírá určení typu tohoto omezení. Zde se většinou jedná o invariant, tedy klíčové slovo inv – a dvojtečku, jež uvozuje začátek samotného omezení. Důležitým klíčovým slovem je self, které se odkazuje na prvek daný kontextem z deklarace omezení. Příklad 1. Definujme omezení pro třídu Company, které omezí počet zaměstnanců ve firmě na nejméně 51. context Company inv: self.numberOfEmployees > 50 Jedná se o invariant říkající, že atribut numberOfEmployees nesmí mít nižší hodnotu než 51. Protože OCL pracuje nad vytvořeným UML modelem, umožňuje volat operace definované u jednotlivých tříd. Příklad 2. Definujme, že žádný objekt třídy Person nemůže při volání operace getAge() vrátit menší číslo než 17. context Person inv: self->getAge() > 17 Pro zjednodušení zápisu složitých omezení lze v rámci zápisu omezení definovat proměnné i funkce lokálně platné v rámci tohoto omezení.
126
Martin Lasoň, Pavel Gavlovský
Příklad 3. Definice vlastní proměnné a funkce context Person inv: let income : Integer = self.job.salary->sum() let hasTitle(t : String) : Boolean self.job->exists(title = t) in if isUnemployed then self.income < 100 else self.income ≥ 100 and self.hasTitle(’manager’) endif V jazyce OCL je plně podporována práce s množinami. Například M − > select(boolean expression) nám umožní vybrat z množiny M pouze prvky odpovídající podmínce zadané v parametru příkazu select. Nebo také M − > f orAll(m|m.value > 5) definuje, že každý prvek množiny M musí mít hodnotu atributu value větší než 5.
4
Generování základního RBAC modelu
Hlavním cílem při vytváření systému pro automatické generování RBAC komponent na základě UML diagramů byla snaha usnadnit práci správci bezpečnosti při prvotním nastavování přístupových práv k jednotlivým rolím. V našem předchozím článku [3] jsme ukázali algoritmus, který generuje hrubý RBAC model na základě aktivitních diagramů. Uvádíme zde postupy, jakými lze vytvořit mapování mezi prvky aktivitních diagramů a komponentami RBAC modelu. Například aktéry vystupující v diagramu aktivit můžeme považovat za základ pro role, neboť se jedná o sdružení akcí vykonávaných jednou entitou. Výsledná množina rolí by měla dále správci bezpečnosti sloužit jako základ pro další role. Poněkud složitější identifikace přístupových práv je založena na způsobech přístupu k jednotlivým objektům a aktivitách vyskytujících se v diagramu aktivit. Na základě objektových toků jsou generována práva čtení nebo zápisu k objektům. Při zpracovávání jednotlivých aktivit se na základě řídících toků a dalších informací generují z aktivit přístupová práva k provedení příslušné akce. V případech, kdy nelze na základě vstupních údajů algoritmicky rozhodnout zda je k dané aktivitě potřeba vygenerovat právo k jejímu spuštění, je vygenerován kandidát na právo. Diagram 2 popisuje část metamodelu UML, která reprezentuje aktivitní diagramy. Takto popsaný diagram je dále zpracováván a jsou v něm vyhledávány RBAC komponenty. K reprezentaci diagramu byly použity třídy ze struktury definované pro výměnný formát XMI ze specifikace UML 1.4.2. Využití formátu XMI umožňuje jednoduchou transformaci z XML souborů a také další snadné rozšiřování o dosud nepoužité prvky UML modelu.
Využití OCL k popisu vztahů mezi přístupovými právy a rolemi
Obr. 2. Metamodel UML
127
128
5
Martin Lasoň, Pavel Gavlovský
Rozpoznání statických omezení v OCL
Nevýhodou základního vygenerovaného modelu je, že se jedná pouze o jádro RBAC, které vsak neobsahuje podporu pro SSD a DSD omezení. Protože předpokládáme, že na tvorbě analýzy systému se správce bezpečnosti nebude podílet, zvolili jsme pro popis omezení jazyk OCL, který je softwarovým analytikům dobře znám a přitom je dostatečně mocný na to, aby dokázal popsat omezení kladená na role uživatelů a jejich práva. Zapisování OCL omezení by nemělo být podmíněno použitím RBAC modelu, ale mělo by se jednat o obecný popis chování systému. Vzorové šablony pro takovéto popisy jsou uvedeny v části 5.1. Nicméně vzhledem k tomu, že SSD omezení jsou vázána na vazbu mezi uživateli a rolemi, je těžké tento vztah definovat bez přítomnosti entit označující uživatele. Za tímto účelem jsme definovali třídní diagram reprezentující RBAC model, ke kterému vztahujeme OCL omezení. Tento princip pak popisujeme podrobněji v části 5.2. 5.1
Specifikace RBAC omezení pomocí OCL
Cílem této kapitoly je definovat základní způsoby, jak lze statická omezení RBAC modelu definovat pomocí OCL. Při navrhování formátu zápisu v OCL jsme vycházeli z již užívaných způsobů specifikace RBAC omezení uvedených v [4]. Statická omezení v tomto případě nejsou vázána k jedné konkrétní roli, ale platí pro všechny role v daném kontextu a proto je možno je přiřadit celému diagramu aktivit. Pokud u aktivitních diagramů mluvíme o rolích, máme na mysli ty role, které byly z diagramu vygenerovány. Pomocí OCL lze definovat vzájemné vztahy mezi všemi aktéry a všemi aktivitami. Aby bylo možné pracovat s v tomto případě neexistující vazbou mezi rolí a uživatelem, umožňujeme definovat pravidla vztahující se ke kontextu User a Role. Význam těchto kontextů bude dále blíže popsán v následující kapitole. V této části se omezíme na tvrzení, že kontext User reprezentuje množinu všech uživatelů a kontext Role reprezentuje množinu všech rolí. Díky těmto kontextům je možno v OCL rozeznat, zda se vztahuje k asociaci uživatel – role nebo role – právo. Díky tomu můžeme definovat všechny vzájemně se vylučující role nebo přístupová práva, která nesmí být přiřazena téže roli. Omezení, která lze v modelu specifikovat je celá řada. V našem přístupu se však zaměříme na dvě základní: definování konfliktních rolí pro jednoho uživatele a definování konfliktních práv pro jednu roli. OCL umožňuje definovat také konflikty mezi jednotlivými uživateli (například provádění potenciálně nebezpečných akcí by nemělo být možné členům jedné rodiny) nebo definování konfliktů mezi rolemi v rámci jednoho sezení (DSD). Pro tato omezení však v aktivitních diagramech nelze najít dostatek informací, protože potřebné prvky nejsou modelovány. Konfliktní role nesmí být přiřazena stejnému uživateli – Při definování takovéhoto omezení definujeme dvojice vzájemně neslučitelných rolí (například vedoucí nákupu a revizor spatnosti faktur). Pokud je takovéto omezení vztaženo na celý
Využití OCL k popisu vztahů mezi přístupovými právy a rolemi
129
diagram, omezení jsou popsána výčtem všech vzájemně neslučitelných rolí identifikovaných v diagramu. Následující příklad by měl sloužit jako ilustrace popisu těchto omezení. Vzájemná negace u vazby U A (viz sekce 2) specifikuje, že jeden uživatel nesmí mít nastaveny obě role. Toto omezení lze popsat následujícím OCL výrazem: context User inv: let M: Set = { { vedoucí nákupu, revizor spatnosti faktur }, . . . } in M->select(m | self.role->intersection(m)->size > 1)->isEmpty Tento výraz vybere všechny vzájemně neslučitelné množiny, zkontroluje všechny role přiřazené každému uživateli a vyhodnotí požadavky. Naše implementace nemůže vyhodnotit tuto podmínku, protože nezná množinu uživatelů, ale je z tohoto výrazu schopná zjistit množiny vzájemně se vylučujících se rolí, které lze použít pro další zpracování. Konfliktní práva nesmí být přiřazeny stejné roli – Tento požadavek říká, že uživatel může mít nejvýše jedno konfliktní právo získané pomocí rolí přiřazených uživateli. Toto omezení je silnější než předchozí případ a chrání před chybami při vytváření vazeb role–právo. Je nutno poznamenat, že toto omezení nepatří mezi klasická RBAC omezení a poprvé je popsali až v roce 2000 autoři Ahn a Sandhu. context Role inv: let M: Set = { { připravení šeku, vydání šeku }, . . . } in M->select(m | self.permission->intersection(m)->size > 1)->isEmpty 5.2
Reprezentace prvků RBAC modelu
V rámci prvotní analýzy systému (při modelování byznys procesů nebo specifikaci požadavků) vzniká předběžný model struktury aplikace. Popisuje logiku a statické vztahy mezi objekty v systému. Tyto třídy však svou strukturou neodpovídají struktuře modelu RBAC. Obrázek 3 popisuje strukturu ukázkového příkladu vycházejícího z modelu vytvořeného v rámci grantu AV ČR, projekt č. 1ET101940420. Jedná se o systém dopravní firmy. Zákazník v něm vytváří zakázky pro dopravní firmu. Zákazníky lze rozdělit na Odesílatele a Příjemce. Zakázky obsahují požadovaný Náklad k převezení. Zadané zakázky řeší se Zákazníkem Manažer, jenž zadává konkrétní úkoly Dispečerovi. Dispečer organizuje vozidla firmy, přiděluje jim Přepravní plány a u Infrastruktury zjišťuje informace o dopravní síti. Přepravní plán vozidla zahrnuje převážený náklad, který byl zadán v přijaté Zakázce. Protože je vhodné v rámci definice omezení RBAC modelu pracovat s rolemi a uživateli jako instancemi tříd User a Role, je třeba získaný analytický model vhodně propojit s obecným modelem struktury RBAC.
130
Martin Lasoň, Pavel Gavlovský
Obr. 3. Třídní diagram příkladu
V následujícím diagramu jsou popsány základní třídy modelu RBAC a jejich vazby. Význam většiny z nich byl definován výše avšak, oproti základnímu standardu RBAC, model detailněji definuje strukturu práv. Ke třídě Permission byly přidány třídy Action a Resource. Třída Permission definuje konkrétní právo. Toto právo je asociováno s Akcemi, které realizují základní operace nad objekty RBAC modelu. Jedná se o akce čtení, zápisu, vytvoření a zrušení objektu. Objekty RBAC modelu reprezentuje třída Resource, jež se skládá z již zmíněných Akcí umožňujících systému pracovat s objektem.
Obr. 4. UML reprezentace RBAC modelu
Nyní již máme popsány oba potřebné modely a je třeba definovat jejich propojení. To je relativně jednoduché. Z diagramu užití (případně z drah zodpovědnosti) získáváme seznam rolí v systému. Proto definujeme, že námi získané
Využití OCL k popisu vztahů mezi přístupovými právy a rolemi
131
role dědí z třídy Role RBAC modelu. Práva v RBAC modelu odpovídají akcím v aktivitních diagramech. Z tohoto důvodu stačí pouze přidat asociaci mezi třídou Permission RBAC modelu a třídou ActionState představující akci v UML metamodelu. Zdroje (Resource) v RBAC modelu odpovídají třídám v třídním diagramu analyzovaného systému. Propojení je, stejně jako v případě rolí, řešeno přidáním dědičnosti. Nejsložitější části propojení jsou akce (Action). Ty získáme analýzou toku objektů v aktivitních diagramech (algoritmus je popsán v [3]). Stručně se dá říci, že když – v rámci aktivitního diagramu – z/do objektu vystupuje/vstupuje tok objektu, pak to znamená, že aktér, v jehož dráze zodpovědnosti leží akce z/do níž tok vede, nutně potřebuje právo k manipulaci s tímto objektem. Nyní již můžeme zpracovávat omezení zapsaná v OCL, a srozumitelněji se odkazovat na prvky modelu RBAC.
Obr. 5. Spojení RBAC modelu s UML
5.3
Možnosti definice omezení přímo v diagramech analytického modelu
Oproti výše zmíněnému přístupu definice omezení, pomocí OCL nad UML modelem RBAC, se nabízí ještě možnost přímé definice omezení nad analytickým modelem. Tento přístup umožňuje definovat zásadní bezpečnostní omezení již analytikovi systému a ty pak automatizovaně ověřit s bezpečnostním modelem vytvořeným zvlášť v RBAC modelu.
132
Martin Lasoň, Pavel Gavlovský
Omezení současného přiřazení rolí jednomu uživateli (SSD). UML diagramy mohou snadno určit role, které se účastní jednotlivých případů užití (resp. procesů). Co však nelze graficky popsat, je definování, či spíše omezení vztahů mezi jednotlivými aktéry, kteří v nich vystupují. Důležitost tohoto omezení je zřejmá i v následujícím případě. Nelze dovolit, aby zákazník byl zároveň manažerem, nebo dispečer firmy schvalující jeho zakázku. Na obrázku 6 zároveň vidíme způsob zápisu tohoto omezení. Protože se omezení týká celého diagramu, a komentář nelze připojit k dráhám zodpovědnosti, je připojeno na počáteční stav aktivitního diagramu. Další možnosti je definovat toto omezení rámci diagramů případů užití. Jedná se o stejné omezení, ale je připojeno k případu užití, kterého se týká.
Obr. 6. Vyloučení konfliktu rolí
Vyloučení konfliktních práv. V rámci popisu aktivit jednotlivých uživatelů, resp. rolí můžeme definovat omezení říkající, že konkrétní právo nelze kombinovat s jinými právy. Abychom zajistili platnost této podmínky, připojíme k akci, reprezentující toto právo, omezení vylučující současné přiřazení konfliktních práv. Zápis v následujícím příkladě využívá vazeb získaných transformací znalostí z analytického UML modelu definovaného systému do modelu RBAC. Zápis self.permission.role.permission... vrací množinu všech práv role, jež vlastní dané právo viz obrázek 7. Následující ->forAll(...) definuje pro všechna práva p tohoto uživatele podmínku, že jejich průnik s množinou konfliktních práv je prázdný.
6
Závěr
Tento článek popisuje možnost získání informací o RBAC modelu z UML diagramů. Konkrétně se jedná o specifikaci SSD omezení definující vzájemnou neslučitelnost rolí, které umožňuje v systému předcházet střetu zájmů uživatelů. Bez toho, aby se návrháři byli nuceni učit zvláštní jazyk pro popis omezení, je možné tyto informace získat z klasických UML diagramů. Tento článek navazuje na naši předchozí práci [3] a rozšiřuje ji o další funkce. Díky tomu je možné rozšířit předchozí základ bezpečnostního modelu o nové informace týkající se
Využití OCL k popisu vztahů mezi přístupovými právy a rolemi
133
Obr. 7. Vyloučení konfliktu práv
statických omezení povinností. Přestože nebylo možné ze vstupních diagramů nastavit konkrétní uživatele, navrhovaný způsob zápisu, umožňuje získat potřebné informace z použité syntaxe. Námi popsaný proces se nám podařilo do značné míry automatizovat díky implementaci podmnožiny gramatiky jazyka OCL. Naše další práce se bude soustřeďovat na další upřesnění získaných informací a další zpracování vygenerovaného RBAC modelu. Tento článek vznikl za podpory grantu FRVŠ „Podpora výuky softwarového inženýrství a informačních systémůÿ
Reference 1. Ferraiolo, D. F., Kuhn, D. R., Chandramouli, R. Role-Based Access Control. Artech House Publishers, 2003, Boston. ISBN 1-58053-370-1. 2. Lason, M., Gavlovsky, P. An Automatized Extraction RBAC Models From UML Business Process Models. Proceedings of 8th Spring International Conference ISIM ’05. Ostrava, 2005. ISBN 80-86840-09-3. 3. Lasoň, M., Gavlovský, P. The Ways of an Automatized Extraction of RBAC Models from UML Business Process Models. Proceedings of the 3th annual workshop WOFEX 2005. Ostrava, 2005. ISBN 80-248-0866-8 4. Ahn, G. J., Shin, M. E. Role-Based Authorization Constraints Specification Using Object Constraint Language. Proceedings of the 10th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises. IEEE Computer Society, 2001. ISBN:0-7695-1269-0 5. Ahn, G. J., Sandhu, R. Role-based Authorization Constraints Specification. ACM Transactions on Information and Systems Security (TISSEC). ACM Press, 2000. ISSN:1094-9224 6. Ferraiolo, D. F., Sandhu R., Gavrila S., Kuhn, D. R., Chandramouli R. A Proposed Standard for Role Based Access Control. http://csrc.nist.gov/rbac/rbacSTDACM.pdf 7. Object Management Group. Unified Modeling Language Specification Version 1.4.2. 2003. http://www.omg.org/cgi-bin/apps/doc?formal/04-07-02.pdf.
Krátký úvod do metodiky (Rational) Unified Process pro Krátký úvod do metodiky (Rational) Unified softwarového produktuproduktu Process vývoj pro vývoj softwarového Štěpán Macura Štěpán Macura 1
Katedra informatiky, FEI, VŠB – Technická Univerzitauniverzita Ostrava, 17. listopadu 15, Katedra informatiky, FEI, VŠB Technická Ostrava, 708 15, 33, Ostrava-Poruba 17. listopadu 708 33, Ostrava-Poruba [email protected][email protected] Abstrakt. Má-li proces vývoje softwarového řešení skončit úspěchem, je hned na počátku nutné zvolit vhodnou metodiku, metriky a také nástroj pro podporu projektů. Všechny tyto prvky umožňují dostát požadavkům zadavatele na dodržení stanoveného rozpočtu, splnění sjednaného termínu a v neposlední řadě zachování použitelnosti výsledného řešení. Klíčová slova: artefakty, metodologie, pracovníci, proces, UML, UP, RUP, RUP builder, software, workflow
1
Úvod
Proces vývoje softwaru (SPD, software development process) známý rovněž jako metoda tvorby softwarového vybavení (SEP, software engineering process) definuje při vývoji softwaru otázky kdo, co, kdy a jak. Metodika USDP (Unified Software Development Process) je průmyslovým standardem SEP pocházejícím od autorů jazyka UML. Ten je běžně označován jako Unified Process (zkáceně UP).
2
Principy úspěšného softwarového vývoje
Pro zvýšení kvality a produktivity softwarového vývoje byl vypracován soubor principů, metod a procesů známých pod názvem. "Šest nejlepších praktik softwarového vývoje". Tyto principy jsou součástí světově uznávané metodiky Rational Unified Process (RUP) společnosti IBM, která je komerční verzí Unified Process.
c Václav Snášel, editor: Objekty 2005, pp. 134–146, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Krátký úvod do metodiky (Rational) Unified Process pro vývoj. . .
2.2
135
Správa požadavků
Požadavek je definován jako schopnost, kterou musí systém splňovat (syndrom IKIWISI – I Will Know It When I See It – „budu to vědět, až to uvidím“: s nadsázkou vyjádřená neschopnost zákazníka specifikovat dopředu všechny požadavky na vyvíjený produkt). Sběr požadavků probíhá hned na začátku vývoje. Před započetím jakékoli další činnosti musí být shromážděny všechny požadavky, které jsou následně vyhodnoceny a zpracovány do projektové dokumentace. V rámci správy požadavků je nutné zjistit požadovanou funkčnost, zpracovat detailní dokumentaci, průběžně vyhodnocovat změny požadavků a jejich důsledky a dokumentovat jednotlivá rozhodnutí. 2.3
Komponentová architektura
Komponentová architektura spolu s iterativním vývojem softwaru přispívá k postupné tvorbě systémové architektury. Takový přístup usnadňuje identifikaci rizik a jejich odstranění již v samotném procesu vývoje. 2.4
Vizuální modelování
Model představuje zjednodušení reality. Vizuální modelování pomáhá zpřehlednit, specifikovat, zkonstruovat a zdokumentovat strukturu a chování systémové architektury. K jednomu systému se vytváří zpravidla více modelů (například z různých pohledů). Jako standardní jazyk pro modelování slouží Unified Modeling Language (UML), díky němuž mohou jednotliví členové týmu mezi sebou srozumitelně komunikovat a předávat si informace bez ohledu na fázi vývoje. 2.5
Ověřování kvality
Kvalitu produktu s ohledem na funkčnost, spolehlivost a výkon je třeba sledovat nepřetržitě v průběhu celého procesu vývoje. Po dodání softwaru už je zpravidla pozdě na jakékoli změny a dodatečné opravy nalezených chyb jsou obtížné. Z tohoto důvodu je nutné průběžné testování a kontrola. Pro nejvyšší kvalitu produktu je nutné se zaměřit na oblasti s nejvyšším rizikem. 2.6
Řízení změn
Důležitou podmínkou úspěchu při vývoji softwaru je efektivní koordinace všech aktivit, aby bylo možné opakovaně využívat standardní pracovní metody a reagovat na změny a byla tak zajištěna lepší alokace zdrojů. RUP se ve svých jednotlivých oblastech snaží řídit všemi uvedenými obecnými praktikami a přibližuje se k nim pomocí mnoha definovaných aktivit.
136
3
Štěpán Macura
Elementy modelování RUP
RUP definuje čtyři základní, nejdůležitější elementy modelování, na nichž ovšem staví nejen celé modelování, ale přeneseně i celý vývojový proces (pomocí těchto elementů se modelují základní případy použití a pracovní procesy, z nichž se celý RUP skládá). 3.1
Pracovníci (workers)
Pracovníci (workers) odpovídají na otázku kdo. Pracovník definuje chování a odpovědnost jedince nebo skupiny. Chování pracovníka je popsáno pomocí činností (activities); každý pracovník je asociován s množinou činností. Odpovědnost je obvykle definována ve vztahu k meziproduktům (artifacts), které pracovník vytváří, modifikuje nebo kontroluje. Pracovníkem není ani tak fyzická osoba, jako spíše jakýsi „klobouk“, který může být v průběhu projektu „nasazován“ různým fyzickým osobám (jedna osoba může postupně nosit více klobouků). Pracovníka je vhodné vidět jako roli. 3.2
Činnosti (activities)
Činnosti (activities): odpovídají na otázku jak. Činnost je jednotkou práce, kterou má provést jednotlivec nebo skupina, a která má vyústit ve smysluplný výsledek v kontextu projektu. Činnost má jasně definovaný účel, obvykle vyjádřený jako vytvoření nebo modifikace meziproduktu (např. modelu, třídy, plánu apod.). Rozsah činností je různý, od několikahodinových po několikadenní. Činnost se však obvykle týká jen jednoho pracovníka a ovlivňuje nejvýše několik málo meziproduktů. Každá činnost má definovány své vstupní a výstupní meziprodukty. Konkrétní činnost má vždy stanovenu podrobnou posloupnost kroků, které vedou k jejímu uspokojivému provedení. Každý z uvedených kroků je v rámci RUP velmi podrobně dokumentován; RUP poskytuje řadu tipů, návodů, pomůcek a rad potřebných ke zvládnutí daného kroku. 3.3
Meziprodukty (artifacts)
Meziprodukty (artifacts) odpovídají na otázku co. Meziprodukt je část informace, která je produkována, modifikována nebo použita v rámci procesu. Meziprodukty jsou hmatatelné výsledky projektu; jsou použity pracovníky jako vstupy svých činností a jsou zároveň výstupy těchto aktivit. Za vytvoření a správnost meziproduktu odpovídá definovaný pracovník. Přestože RUP definuje mnoho meziproduktů, v konkrétním projektu není typicky nutné použít všechny.
Krátký úvod do metodiky (Rational) Unified Process pro vývoj. . .
3.4
137
Pracovní procesy (workflows)
Pracovní procesy (workflows) odpovídají na otázku kdy. Pouhý výčet všech pracovníků, činností a meziproduktů ještě nepředstavuje proces. Zbývá definovat smysluplnou posloupnost činností a stanovit interakce mezi pracovníky. Pracovní proces je posloupnost činností vedoucí k vytvoření požadovaného výsledku. Pracovní proces může být s výhodou modelován v UML jako sekvenční diagram (sequence diagram), diagram spolupráce (collaboration diagram) nebo diagram činnosti (activity diagram). Činnosti bývají navzájem značně protkány. Diagram pracovního procesu tedy nesmí být interpretován mechanicky. Každý pracovní proces se tedy skládá z několika (typicky nejvýše z desíti) činností. RUP definuje devět klíčových pracovních procesů (Core Workflows). Tyto klíčové procesy se kryjí se skupinami meziproduktů uvedenými v předchozí kapitole. Protože každý z devíti klíčových procesů pokrývá širokou oblast, dělí je dále RUP na tzv. podrobnosti pracovních procesů (Workflow Details). Ty se používají k vyjádření specifické skupiny úzce souvisejících činností.
4
Základní fáze podle RUP
RUP zavádí čtyři základní fáze vývoje, přičemž každá z nich je organizována do několika iterací. Před započetím nové iterace musí být splněna definovaná kritéria předchozí iterace. Ve fázi zahájení (inception) musí vývojáři definovat účel a rozsah projektu a jeho obchodní kontext; ve fázi rozpracování (elaboration) je úkolem vývojářů analyzovat potřeby projektu a zákazníka a definovat základy architektury. Třetí fáze, konstrukce (construction), je zaměřena na vývoj designu aplikace a tvorbu zdrojových kódů, zatímco v poslední fázi, ve fázi předání (transition), dochází k předání projektu – buď zákazníkovi nebo do dalšího vývojového cyklu.
5
Fáze metodiky UP
Každá fáze má určitý cíl, na nějž jsou soustředěny aktivity jednoho nebo více pracovních postupů a jenž je významným milníkem v životě projektu. 5.1
Fáze zahájení - cíle
Cílem fáze Začátku je „odstartování projektu“. Tato fáze obsahuje: • Tvorbu podmínek proveditelnosti; • nadnesení obchodního (podnikatelského) případu; • zachycení podstatných požadavků; • označení kritických rizik. Hlavními pracovníky jsou v této fázi manažer projektu a systémový projektant.
138
5.2
Štěpán Macura
Fáze zahájení - milník: Předmět životního cyklu a rozsah systému
Zatímco se většina procesů tvorby softwarového vybavení zaměřuje na tvorbu klíčových artefaktů, je metodika UP zaměřena spíše na konečné cíle. Každý milník nastavuje určité cíle, kterých musí být dosaženo, aby bylo možné považovat milník za dosažený. Některé cíle mohou být výsledkem určitých artefaktů, jiné nikoliv. Milníkem počáteční fáze je předmět životního cyklu a rozsah systému (Life Cycle Objectives). Podmínky, jež musí být splněny, aby byl milník považován dosažený, jsou shrnuty v tabulce 6.1.
Tabulka 6.1. Podmínky pro dosažení milníku ve fázi zahájení
Hodnotící kritéria (metriky) Uživatelé a zainteresované osoby (zadavatel) souhlasí se záměry životního cyklu S uživateli a zainteresovanými osobami byl dohodnut rozsah projektu S uživateli a zainteresovanými osobami byly dohodnuty zachycené klíčové požadavky Uživatelé a zainteresované osoby schválili náklady a pracovní rozvrh Manažer projektu nadnesl obchodní případ Manažer projektu odhadl rizika Potvrzení proveditelnosti obsažené v technických studiích a v prototypech Náčrt architektury
5.3
Je třeba dodat Dokument o představě, jenž obsahuje hlavní požadavky na projekt, funkce a podmínky Počáteční případ užití (kompletní asi z 10 nebo 20%) Slovník projektu
Počáteční plán projektu Obchodní případ Dokument nebo databáze obsahující odhad rizik Jeden nebo více prototypů, které bude možno zahodit Počáteční dokument zachycující architekturu
Fáze rozpracování - cíle
Výstupy fáze rozpracování lze shrnout následujícím způsobem: • Tvorba spustitelného architektonického základu; • vylepšení odhadu rizik; • definice atributů kvality; • zachycení případů užití pro 80 % funkčních požadavků; • tvorba přesného plánu konstrukční fáze; • formulace nabídky, která zahrnuje veškeré prostředky, čas, vybavení, personál a náklady.
Krátký úvod do metodiky (Rational) Unified Process pro vývoj. . .
5.4
139
Fáze rozpracování - milník: Architektura jako vodítko pro systém v jeho budoucím životě
Milníkem této fáze je architektura (Life Cycle Architecture). V tomto bodě prověřujeme detailní předměty systému a rozsah, výběr architektury a výsledek základních rizik. Chceme-li považovat milník za dosažený, musíme splnit podmínky, které jsou shrnuty v tabulce 6.2. Tabulka 6.2. Podmínky pro dosažení milníku ve fázi rozpracování
Hodnotící kritéria (metriky) Byl vytvořen odolný robustní spustitelný architektonický základ Spustitelný základ ukazuje, že byla rozpoznána a vyřešena důležitá rizika Vize produktu byla stabilizována Odhad rizik byl revidován Obchodní případ byl revidován a odsouhlasen uživateli a zainteresovanými osobami Projekt byl vytvořen do dostatečné hloubky, aby umožnil sestavení realistické nabídky zahrnující odhad času, peněz a prostředků pro nadcházející fáze. Uživatelé a zainteresované osoby souhlasí s plánem projektu Plán projektu byl porovnán s obchodním případem Bylo dosaženo dohody s uživateli a zainteresovanými osobami o pokračování v projektu
5.5
Je třeba dodat Spustitelný architektonický základ. Statický model UML Dynamický model UML. Model případu užití Dokument o vizi Aktualizovaný odhad rizik Aktualizovaný obchodní případ
Aktualizovaný plán projektu
Obchodní případ a plán projektu Konečný dokument
Fáze konstrukce - cíle
Cílem konstrukční fáze je splnit všechny požadavky analýzy a návrhu a vyvinout ze spustitelného základu vytvořeného ve fázi rozpracování konečnou verzi systému. Klíčovým zadáním konstrukční fáze je zachování integrity architektury vytvářeného systému. 5.6
Fáze konstrukce - milník: Počáteční provozní způsobilost
V podstatě je tento milník velmi jednoduchý - softwarový systém je připraven pro testování na počítačích uživatele. Tato verze je často nazývána beta-verzí. Hodnotící kritéria (metriky) tohoto milníku jsou shrnuta v tabulce 6.3.
140
Štěpán Macura
Tabulka 6.3. Podmínky pro dosažení milníku fáze konstrukce
Hodnotící kritéria (metriky) Softwarový produkt je dostatečně stabilní a na takové úrovni, aby jej bylo možno nasadit na počítače uživatele Uživatelé a zainteresované osoby souhlasí s nasazením softwaru do svého prostředí a je k němu připraven Poměr skutečných výdajů vůči plánovaným je přijatelný
5.7
Je třeba dodat Softwarový produkt. Testovací sadu.
Model
UML.
Uživatelské příručky. Popis verze
Plán projektu
Fáze předání - cíle
Cíle této fáze lze shrnout následujícím způsobem: • Oprava chyb; • příprava uživatelského pracoviště na přijetí nového softwaru; • přizpůsobení softwaru tak, aby fungoval na pracovišti uživatele; • úprava softwaru v případě vzniku neočekávaných problému; • tvorba manuálu a další dokumentace; • konzultace s uživateli; • koncová revize.
5.8
Fáze předání - milník: Nasazení produktu
To je poslední milník - beta-testy, přejímací testy a oprava případných chyb jsou dokončeny a produkt je uvolněn a přijat do užívání na pracovišti uživatele. Podmínky dosažení zmiňovaného milníku jsou shrnuty v tabulce 6.4. Tabulka 6.4. Podmínky pro dosažení milníku fáze předání
Hodnotící kritéria (metriky) Beta-testy jsou dokončeny, byly provedeny nezbytné změny a uživatel souhlasí s faktem, že systém byl úspěšně nasazen Pracovníci uživatele produkt aktivně využívají Strategie podpory produktu byla nejprve s uživateli dohodnuta a později implementována
Je třeba dodat Softwarový produkt
Plán uživatelské podpory. Uživatelské příručky
Krátký úvod do metodiky (Rational) Unified Process pro vývoj. . .
6
141
Konkrétní aplikace metodiky RUP v novém projektu
Metodika RUP je obecnou metodou tvorby softwaru. Pro každou organizaci stejně jako potom pro každý jednotlivý projekt je tedy třeba vytvořit její novou instanci. Tím se uznává, že každý softwarový projekt se od ostatních liší a že model „tato košile padne všem“ zde rozhodně neplatí. 6.1
RUP Builder - start
Pro částečné usnadnění této práce nabízí firma IBM produkt RUP Builder, který z RUP, která má přes 10 000 stran dokumentace, vytvoří přijatelný balík, který by vyhovoval potřebám dané firmy a nezatěžoval věcmi, které se v projektu nepoužijí. Při samotném spuštění aplikace se otevře dialogové okno, které vyzývá k volbě ze tří možností: • Klasické RUP - jedná se o klasickou šablonu RUP, která se používá u rozsáhlých projektů pro vývoj produktu, který může přesáhnout i několika let. • Střední projekt - pro projekty, kde zaměstnanci nejsou umístění ve stejné budově a neexistuje dobrá neformální komunikace nebo kde je více formality vyžadováno a malý tým očekává regulátory nebo nařízení klienta. • Malý projekt - je vhodný pro projekty do 15-ti lidí, kteří jsou umístěni ve stejné budově a s trváním projektu méně jak rok.
Obr. 6.1. Startovací obrazovka RUP Builder [4]
142
6.2
Štěpán Macura
RUP Builder - Výběr procesu
Dalším krokem, ke kterému nás RUP Builder vyzve je volba zásuvných modelů. Je možno si vybrat např. formální nebo neformální zdroje, RUP .NET, RUP J2EE… Ve stejném kroku, ale v jiném okně nám nabízí možnost volby komponent, které budou nejvíce vyhovovat našim potřebám, ať už se jedná o životní cyklus, různé výcviky (např. Reguirements Discipline, Analysis & Design Discipline, Implemantation Discipline, atd.), požadavky, architektura, design (obr. 6.3.), implementace, atd. obr. 6.2.
Obr. 6.2. Výběr zásuvných modulů a komponent v RUP Builderu [4]
Krátký úvod do metodiky (Rational) Unified Process pro vývoj. . .
143
Obr. 6.3. „Rozpad“ komponenty Design [4]
6.3
RUP Builder - výběr pohledu
Ve třetím kroku se dostáváme do voleb možností úpravy pohledů. V této části si můžeme nastavit, co se nám bude zobrazovat, kde se nám to bude zobrazovat nebo zobrazení celkové potlačíme a to v konkrétních záložkách: Analytik, návrhář, manažer, tým, testovač, postupný start… V každé této záložce jsou uzlové body, které si můžeme vybrat k publikování nebo k nepublikovaní. Mohu je v rámci hierarchie posouvat výše, či níže nebo vkládat nové objekty. Takto si můžeme vytvořit navigaci, která nám bude nejvíce vyhovovat a bude pro nás přijatelná a srozumitelná.
144
Štěpán Macura
Obr. 6.4. Úprava pohledů [4]
6.4
RUP Builder - publikování procesu
Posledním krokem je vypublikování našich úprav do vybraného adresáře. Můžeme dodatečně zakázat generování některých pohledů, zvolit startovací stránku, vybrat politiku pro práci s grafikou. Zda se mají po vypublikování databáze regenerovat (míněno index a vyhledávání). Když jsme s nastavením spokojení, můžeme stlačit tlačítko Publish a dojde ke generování HTML dokumentu, obr. 6.4. Výsledek je poté dostupný v internetovém prohlížecí, obr. 6.5. Procházení dokumentu pak probíhá hypertextovými odkazy nebo pomocí menu v levé části obrazovky.
Krátký úvod do metodiky (Rational) Unified Process pro vývoj. . .
Obr 6.4. Právě probíhá proces publikování [4]
Obr. 6.5. Výsledek publikační činnosti
145
146
7
Štěpán Macura
Závěr
Musím říci, že pochopit celou metodologii UP (RUP) není jednoduchý úkol a ani já se zatím o to nepokusím. V tomto článku jsem se pokusil nastínit její základy a možnosti přizpůsobení libovolnému projektu. Pravděpodobně bych se ji nesnažil použit v některém projektu bez člena, který s ní má zkušenosti z jiného projektu. Naprosto nezkušený tým by podle mě přivedla k zahlcení a do hledání těch „správných“ cest.
Reference 1. Arlow J., Neustat I. UML a unifikovaný proces vývoje aplikací. Computer Press 2003, Nám. 28. dubna 48, Brno, ISBN 80-7226-947-X 2. IBM Corp. http://www-5.ibm.com/cz/software/rational/ 3. IBM Corp. C:\Program Files\Rational\RationalUnifiedProcess\index.htm, Rational Unified Process® Version 2003.06.13 4. IBM Corp. RUP Builder Version 2003.06.14.567.000 5. Kadlec V. http://www.zive.cz/h/Programovani/AR.asp?ARI=111889, Nevěříte Extrémnímu programování? Zkuste klasiku: Rational Unified Process 6. Kadlec V. http://www.zive.cz/h/Programovani/AR.asp?ARI=112011, Rational Unified Process: základní pojmy 7. McCarthy J. Softwarové projekty. Computer Press 1999, Hornocholupická 22, Praha 4, ISBN 80-7226-164-0 8. Vondrák I. Úvod do softwarového inženýrství verze 1.1. VŠB-TUO 2002, učební materiál Annotation Short introduction into the methodology (Rational) Unified Process for development software product That the may be process of software development successful, it is important to choose suitable methodology, metric and some tool for support of project at the beginning. All of them enabling realize submitter’s demands on budget, deadline and usability of product.
Podpora výuky objektově orientovaného programování Podpora výuky objektově orientovaného programování Filip Malý Filip Malý Katedra informatiky a kvantitativních metod, Fakulta informatiky a managementu, Univerzita Katedra informatiky a kvantitativních metod,Hradec FakultaKrálové, informatiky a managementu, Univerzita HradecRokitanského Králové, Rokitanského 500 03 Hradec Králové 62, 500 62, 03 Hradec Králové [email protected][email protected] Abstrakt: Příspěvek představuje prostředí Wide J, které společně s knihovnou příkladů (mechanismem knihovny příkladů) slouží jako dodatečná podpora výuky objektově orientovaného programování. Článek také poukazuje na problémy spojené s distanční výukou programování a naznačuje směr, kterým je možné se při tvorbě případných podpůrných prostředí ubírat. Text příspěvku také podává bližší pohled na prostředí Wide J, zejména se zaměřuje na jednotlivé části systému a interakci mezi těmito částmi, dále pak na celkovou koncepci a architekturu tohoto prostředí. Klíčová slova: objektově orientované programování, výuka, Java, vývojové prostředí
1
Úvod
V současné době se výuka programování soustřeďuje v souladu s aktuálními trendy především na výuku objektově orientovaného programování. Kurzy distančního vzdělávání jsou dostupné především prostřednictvím virtuálních studijních prostředí využívajících jako klienta webové prohlížeče. Podíváme-li se na webový prohlížeč důkladněji, zjistíme, že nám pro podporu a vývoj prostředí podporujícího výuku objektově orientovaného programování nenabízí téměř nic. Kurzy podporující výuku anglického jazyka umožňují například vyhledání příslušného slovíčka včetně zvukové nahrávky výslovnosti. Kurzy objektově orientovaných programovacích jazyků potřebují především spojení teorie s praxí, tzn. teoretických znalostí, které budou doprovázeny příslušnými ukázkovými aplikacemi ve formě zdrojových kódů tak, aby bylo možné tyto zdrojové kódy přeložit a ověřit tak bezprostředně teoretické znalosti v praxi. Zobrazení teoretických znalostí webovým prohlížečem nebývá závažný problém, závažným se tento problém stává v okamžiku, kdy chceme do takto vytvořeného prostředí integrovat překladové nástroje příslušných zdrojových kódů. 1.1
Současný stav
Současný stav výuky programování na Fakultě informatiky a managementu Univerzity Hradec Králové vychází ze zkušeností získaných v předešlých letech, kdy se uplatňoval postup směřující od výuky algoritmizace, přes strukturované programování až k programování objektovému.
c Václav Snášel, editor: Objekty 2005, pp. 147–156, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
148
1.2
Filip Malý
Stará koncepce
Tato koncepce spočívala zejména ve výuce jazyka Pascal a Delphi bez použití jakéhokoliv prostředí podporujícího distanční vzdělávání. Krátce po nasazení systému WebCT, který se masově používá na Fakultě informatiky a managementu Univerzity Hradec Králové, byl vytvořen i online kurz objektového programování s využitím prostředí nástroje Borland Delphi, zejména jako podpora pro kombinovanou formu studia, ale zároveň i jako podpůrný nástroj v prezenční formě. S nově vytvořeným kurzem programování v prostředí WebCT se přišlo na řadu problémů a komplikací, které značně snižovaly efektivnost výuky tohoto předmětu. Hlavními problémy byly tyto: • Studenti se soustředili převážně na uvedené úryvky zdrojových kódů a ty potom kopírovali z WebCT do prostředí Borland Delphi bez čtení příslušných doprovodných textů. V důsledku toho často docházelo, že takto vytvářené aplikace nebylo možné v Delphi přeložit a spustit, protože tyto zdrojové kódy nebyly úplné. Část řešení byla obsažena v samotných doprovodných textech, kterým studenti nevěnovali pozornost. • Vyskytl se problém přenosu informací mezi prostředím WebCT a vývojovým prostředím Delphi, docházelo k nepohodlnému a zbytečnému „překlikávání“ z jednoho prostředí do druhého. • Borland Delphi je jako prostředí pro studenty značně nevýhodné, především z hlediska ceny pořízení tohoto prostředí. • Prostředí Borland Delphi je zaměřeno na objektově orientované programování, ale zároveň umožňuje i strukturované programování. 1.3
Nová koncepce
V souvislosti s reakcí na potřeby trhu se přistoupilo k modifikaci výuky programování. Strukturovaný programovací jazyk Pascal a prostředí Borland Delphi nahradilo objektově orientované programování v čele s programovacím jazykem Java. Došlo tak k odstranění jednoho z problémů, který provázel původní online kurz ve WebCT, neboť Java spolu s vývojovými nástroji je na Internetu k dispozici ke stažení zcela zdarma a legálně. Bohužel s odstraněním tohoto problému vznikl problém jiný. Vývojová prostředí jsou sice k dispozici zcela zdarma, avšak jejich instalace, nastavení a konfigurace je pro nováčka velice složitá a mnohdy může studium studentům značně znechutit (toto ale platilo i pro prostředí Borland Delphi, takže tento problém spíše přetrval). Student se musí věnovat instalaci a konfiguraci takovýchto prostředí a musí obětovat čas na úkor toho, aby se věnoval zvládnutí základních konstruktů objektově orientovaného programovacího jazyka. Lze tedy konstatovat, že se zavedením této koncepce došlo ke změně problému: místo finančního hlediska se objevilo hledisko náročnosti instalace a konfigurace vývojového prostředí. Nutná podpora studentů při instalaci zabrala mnoho času, který by jinak mohl být věnován již výkladu principů programování. Vzhledem k předešlým, převážně negativním zkušenostem bylo prozatím upuštěno od online kurzu vytvořeného v prostředí WebCT a výuka se nadále orientovala na prezenční formu studia.
Výše popsané zkušenosti však vyústily ve shrnutí, co by takové prostředí podporující distanční výuku objektově orientovaného programování mělo splňovat: • Prvním bodem by měla být především možnost integrace do prostředí pro distanční výuku (v našem případě WebCT). Rovněž by bylo vhodné, aby vzniklé prostředí mohlo být na WebCT i nezávislé. • Prostředí podporující distanční výuku by mělo být co nejvíce dostupné, aby mohlo splňovat požadavky a nároky distančního kurzu. • Možnost plné integrace do WebCT může být rozšířena o knihovnu řešených příkladů a zadání, která by na řešené příklady navazovala. Prostředí by tedy mělo umožňovat rychlé a snadné načítaní ukázkových příkladů a následnou manipulaci s nimi (překlad, úpravy,...). • Nenáročná nebo téměř minimální instalace prostředí by měla být samozřejmostí. Student by měl mít možnost začít s takovýmto prostředím co nejdříve pracovat bez toho, aniž by se musel zaobírat otázkou instalace prostředí. S tímto bodem je spojena i jakási intuitivnost a přívětivost ovládání celého prostředí.
3
Navrhované řešení – Wide J
Z uvedených bodů vycházela idea vývojového prostředí Wide J. Vytvořené prostředí není plnou náhradou distančního vzdělávacího kurzu programování, ale poskytuje velmi silnou oporu především v následujících bodech: • Integrace prostředí Wide J do prostředí WebCT je velice snadná a jednoduchá. • Prostředí Wide J může být nasazeno i mimo prostředí WebCT. • Prostředí samotné je vytvořeno v Javě, která je ze své podstaty multiplatformní, tzn. student není závislý na použitém operačním systému. Dostupnost prostředí je možná v celém Internetu. • Student není nucen instalovat žádné dodatečné technologie na svůj počítač, pouze je nucen mít k dispozici tzv. JRE (Java Runtime Environment) [4]. JRE je dnes standardní součástí každého webového prohlížeče a pokud tomu tak není, lze tuto aplikaci zdarma stáhnout a jediným kliknutím ji nainstaluje i úplný začátečník. • Prostředí Wide J bylo od počátku vyvíjeno tak, aby umožňovalo použití knihovny příkladů, tzn. prostředí implementuje mechanismy, kterými lze s příklady pracovat. Jediným problémem pak tedy zůstává výběr vhodných témat a samotná příprava a tvorba příslušných příkladů.
150
4
Filip Malý
Cíle
Hlavním cílem tedy bylo navrhnout a vytvořit integrované výukové a vývojové prostředí pro objektově orientovaný programovací jazyk Java jako webovou aplikaci, to je vytvořit takové prostředí, ve kterém by student mohl začít tvořit a učit se vytvářet své první aplikace tak, aniž by musel shánět příslušné překladače a vývojová prostředí pro tento programovací jazyk. Při výuce programování jazyka Java vyvstaly během výuky určité problémy spojené především s vývojovými prostředími, která se během výuky používají. Při použití vytvořeného prostředí Wide J může student věnovat výuce tohoto jazyka mnohem více času, který by jinak musel věnovat instalaci a nastavení všech výkonových a vývojových složek jazyka Java. Student ztrácí svůj čas také tím, že se musí věnovat tomu, aby porozuměl nainstalovanému prostředí, jeho ovládání a funkcím, které toto prostředí poskytuje. Pro tento případ je naše integrované prostředí Wide J sestrojeno tak, aby veškeré funkce byly snadno pochopitelné a vytváření nových aplikací bylo intuitivní a pro práci uživatele přívětivé a přátelské.
5
Prostředí
Pro tvorbu integrovaného prostředí, které je také předmětem tohoto příspěvku, byl programovací jazyk Java vybrán hned z několika důvodů. Jednak může být výsledná aplikace příkladem a ukázkou toho, co vše je možné v tomto jazyce realizovat a tím tak ukázat sílu, možnosti a mohutnost tohoto programovacího jazyka. Druhým důvodem je fakt, že tento jazyk je nezávislý na operačním systému. Z toho vyplývá, že celé prostředí pak mohou používat všichni uživatelé (studenti) bez ohledu na to, jaký používají operační systém a jaký hardware ve svém počítači mají. Tím se značně rozšiřuje použití celého integrovaného prostředí, neboť uživatelé používající například operační systém Linux tak nejsou odkázáni pouze na školní vybavení, ale mohou toto prostředí používat i z domova (pokud mají přístup na Internet).
Celé integrované prostředí Wide J se skládá z těchto částí: • klient Wide J pro uživatele, • řídicí applet Control pro správce, • serverová aplikace zajišťující překlad zdrojových kódů, • servlet zajišťující funkce knihovny příkladů (jedná se tedy o mechanismus knihovny příkladů). Je důležité si ujasnit pojmy klient Wide J a integrované prostředí Wide J. Pokud budeme hovořit o aplikaci Wide J, případně o programu, o klientu Wide J a podobně, budeme mít vždy na mysli pouze applet Wide J, ke kterému má uživatel přístup. Pojem klient Wide J tedy označuje aplikaci, se kterou přichází uživatel do styku, se kterou pracuje. Pokud budeme hovořit o celém integrovaném prostředí, budeme používat označení integrované prostředí Wide J, popřípadě systém Wide J. Celý tento systém se skládá ze serverové aplikace, dále z klienta Wide J, z řídicího appletu Control a ze servletu, který zprostředkovává uživateli funkce knihovny.
152
Filip Malý
Celé prostředí pak vypadá následovně:
Obr. 2: Vývojové prostředí Wide J
Jak vidíme z předchozího obrázku, každý klient Wide J naváže komunikaci se serverovou aplikací a to konkrétně s hlavním vláknem. Toto vlákno ihned přidělí klientovi nové vlákno, které obslouží klientův požadavek, vrátí mu odpověď a pak zanikne. Můžeme tedy vlastně říci, že každý klient Wide J bude mít své vlastní vlákno, které bude zpracovávat jeho požadavek. Řídicí applet Control bude komunikovat se serverovou aplikací prostřednictvím vyhrazeného vlákna. Toto vlákno pak bude vykonávat všechny požadavky klienta Control a bude ovlivňovat chod hlavního vlákna a tím i celé serverové aplikace. Klient Wide J je ta část systému, se kterou bude pracovat uživatel. Tento klient především umožňuje vytvoření zdrojového kódu, odeslání tohoto kódu na server a spuštění přeložené aplikace. Kromě toho poskytuje aplikace i vedlejší funkce, jako je například uložení či načtení zdrojového kódu, tisk zdrojového kódu a obarvování zdrojového kódu (syntax highlighting).
Integrované vývojové prostředí Wide J se skládá z několika aplikací, proto je vhodné popsat, které aplikace spolu komunikují, jakým způsobem a dále jaká data si navzájem předávají. Celý systém a komunikaci mezi jednotlivými články jsme znázornili na následujícím obrázku, ve kterém jsme některé datové toky odlišili jiným typem čáry z důvodu lepší přehlednosti:
Obr. 3: Datové toky a interakce mezi částmi systému Wide J
Klient Wide J navazuje spojení se serverovou aplikací v okamžiku, kdy uživatel požaduje překlad svých zdrojových kódů. Klient Wide J odešle zdrojový kód ze všech otevřených záložek serverové aplikaci. Serverová aplikace přijme a zpracuje zdrojový kód a postupně jej uloží do samostatných souborů (každý zdrojový kód příslušný jedné třídě do samostatného souboru). Následuje překlad takto vytvořených souborů a komprimace překladu do
154
Filip Malý
Java archivu. V dalším kroku je sestaven hypertextový soubor, jehož celá cesta je vrácena (včetně dalších informací o překladu) klientovi Wide J, a ten rozborem příchozího textu tuto adresu nalezne. Aplikace Wide J předá adresu internetovému prohlížeči, ten zobrazí příslušný hypertextový soubor, který obsahuje příkazy pro spuštění vytvořeného Java archivu. Předáním zpětné odpovědi včetně adresy hypertextového souboru končí celá komunikace mezi klientem Wide J a serverovou aplikací. Serverová aplikace však ještě zapíše příslušné informace o spojení do logu, aby bylo možné později zjistit, kdo překlad prováděl (tzn. z jaké adresy počítače bylo spojení se serverovou aplikací navázáno). Přístup k příkladům v knihovně příkladů je řešen pomocí odkazů na příslušný servlet. Servlet po obdržení požadavku se jménem příkladu příklad načte z úložiště knihovny a odešle jej aplikaci Wide J. V tomto případě nezahajuje komunikaci klient Wide J na pokyn uživatele, ale tento proces zahajuje uživatel sám a to v okamžiku, kdy klikne na příslušný odkaz příkladu. Jakmile na tento odkaz klikne, zavolá tak vlastně servlet, který má jako parametr jméno příslušného příkladu. Klient Control, který je určený pro ovládání serveru, naváže spojení se serverem a odešle mu příkaz, který uživatel požaduje. Server příkaz zpracuje, tzn. nejprve specifikuje typ příkazu a pak provede požadovaný úkon. Pokud požaduje uživatel provést upload souboru do knihovny příkladů, celý proces komunikace je trochu odlišný. Především je z komunikace vyřazen server a applet Control tak vlastně s nikým nenavazuje komunikaci. Uživatel vybere soubor určený k uploadu do úložiště knihovny a applet tento soubor načte a uloží jej přímo do úložiště knihovny. Poté klient Control informuje uživatele o tom, jak celá operace uploadu proběhla. Podrobnosti o celé komunikaci mezi jednotlivými složkami integrovaného prostředí Wide J a rovněž i podrobnosti o administrační části Control lze nalézt v [3]. Systém Wide J byl vytvořen na verzi Javy 1.4.2, otestován byl rovněž na verzi 1.4.0. Zároveň je však nutné dodat, že i když samotný systém nevyžaduje nejnovější verzi Javy, mohou tuto verzi vyžadovat příklady umístěné v knihovně příkladů ke svému překladu.
6
Zpětná vazba a knihovna příkladů
Vytvořené integrované prostředí rovněž umožňuje i okamžitou zpětnou vazbu. Uživatel vytvoří nějakou jednoduchou aplikaci, přeloží ji a ihned vidí co tato aplikace provádí a jak se chová. Okamžitě může aplikaci modifikovat a opět bez dalších potřebných zásahů přeložit a opět uvidí výsledek. To vše stále v prostředí standardního webového prohlížeče. Pro zjednodušení výuky a práce studenta s tímto integrovaným prostředím byla vytvořena knihovna příkladů, která je součástí celého prostředí (přesněji mechanismus této knihovny). Uživatel může kliknutím vybrat z knihovny potřebný příklad a tím jej nahrát do uživatelského prostředí a následně příklad přeložit a podívat se, jak se chová zdrojový kód aplikace v praxi. Význam této knihovny je obrovský, protože umožňuje uživateli – studentovi učit se tento programovací jazyk pomocí příkladů. Pokud si představíme, že jednoduché příklady vkládané do knihovny budou tuto knihovnu dále rozšiřovat, a z jednoduchých příkladů budeme vytvářet příklady složitější, vytvoříme pro konstrukci nových
aplikací mohutný nástroj vhodný nejen pro výuku ale i příjemnou práci. Výsledkem pak bude to, že student bude postupovat od základů a pokud tyto základy zvládne, bude moci postupovat ke složitějším a složitějším programům vytvořených v jazyce Java. Důležitým faktem je hlavně to, že student uvidí zdrojový kód a ihned bude mít možnost vyzkoušet, co tento zdrojový kód vlastně dělá. A to bez použití jakýchkoli standardních vývojových nástrojů a bez instalace vývojového kitu Javy. Studentovi postačí jen webový prohlížeč s technologií JRE. Je důležité poznamenat, že pokud student neporozumí danému kódu, může mu porozumět právě v okamžiku, kdy uvidí, jak se přeložená aplikace chová. Pokud student tomuto kódu přesto neporozumí, může některé části programového kódu dočasně uzavřít do komentářových značek a aplikaci znovu spustit a sledovat, jestli aplikace splní jeho záměr. Jakmile student získá jistotu, že danému problému rozumí, může pak kód příkladu dále rozvíjet a doplňovat, modifikovat a měnit podle svého rozmyslu a opět pak sledovat, jestli přeložená aplikace pracuje v souladu s jeho předpokladem. Výhodou navrženého řešení je také to, že se student může k jednotlivým příkladům vracet, protože všechny budou k dispozici v knihovně příkladů. Ve výše popsaném způsobu je právě síla tohoto integrovaného prostředí. Student se nemusí učit jazyk způsobem, že vyčte nějaký kód příkladu z učebnice jazyka Java a pak u počítače bude marně vzpomínat, jaké mechanismy tento kód implementoval. Integrované prostředí Wide J by mělo odstranit únavné vyhledávání vhodných aplikací v učebnicích a nahradit jej vyhledáváním aplikací v knihovně s možností předkládané aplikace okamžitě doplňovat a rozšiřovat. Jak již bylo řečeno, student uvidí příklad a ihned bude mít možnost tento příklad přeložit, modifikovat, upravovat, optimalizovat, zkrátka s ním provádět vše, co uzná za vhodné. Samotné integrované prostředí není jen zaměřeno na příklady z knihovny, student může sestavovat i své vlastní aplikace. Příklady mohou vycházet z různých vzorových příkladů, například [1] nebo [2], nebo je možné vytvářet příklady vlastní a tematicky se zaměřovat na specifické oblasti objektově orientovaného programovacího jazyka.
7
Závěr
Vytvořené prostředí může být rovněž pojato jako základ pro další vývoj a rozvíjení integrovaného výukového a vývojového prostředí. Prostředí bylo vytvářeno tak, aby umožňovalo jednoduché a intuitivní ovládání klientské aplikace, tzn. aby se student mohl okamžitě již v úplném počátku výuky programování věnovat programovacímu jazyku a nemusel se zaobírat konfigurací složitých vývojových prostředí. Zaujme-li studenta tento programovací jazyk, může po zvládnutí základů jazyka Java obohatit své zkušenosti o práci s dalšími vývojovými prostředími, které se však vyznačují svou složitou instalací a konfigurací. Integrovaný systém Wide J je v současnosti jedinou možností, jak kompletně integrovat výuku programování do eLearningových kurzů. Je tedy možné klienta Wide J umístit do prostředí WebCT na Fakultě informatiky a managementu. Student by pak nemusel „přeskakovat“ mezi systémem WebCT a IDE nástrojem (například Eclipse nebo Netbeans IDE).
156
Filip Malý
Do budoucna by bylo možné celý tento integrovaný systém rozvinout v jeden velký portál, kterým by student při výuce programovacího jazyka postupně procházel krok za krokem. Tento systém by mu v každém kroku nabídl vždy určité a nezbytné množství teorie, za touto teorií by pak následovaly příklady, které by nově získané znalosti prověřovaly. Bylo by velkým úspěchem, kdyby vytvořené integrované prostředí bylo vyhledávaným prostředkem pro zájemce o objektově orientovaný programovací jazyk, jakým je například Java.
Literatura 1. ECKEL, B.: Myslíme v jazyku Java. Knihovna programátora. První vydání. Praha: Grada Publishing, spol. s r.o., 2001. ISBN 80-247-9010-6. 2. HEROUT, P.: Učebnice jazyka Java. Dotisk prvního vydání. České Budějovice: Kopp, 2001. ISBN 80-7232-115-3. 3. MALÝ, F.: WIDE J – Integrované prostředí pro výuku Javy. Diplomová práce. Hradec Králové. FIM UHK. 2005. 117 s. 4. Sun Microsystems, Inc. Java Technology. Přístup z Internetu. URL: http://java.sun.com/, 20.9.2005.
Annotation The paper presents the environment Wide J, which serves as additional objectoriented programming support education with program library (mechanism of program library). The text also adverts to problems, which are connected with distance teaching of programming and indicates feasible solution by which it is possible to proceed with creation of supportive environments. The text of this paper also reports further particulars about the environment Wide J especially it takes look on individual parts of the system and interaction between them, and then on general conception and architecture of this environment.
Podpora aplikační logiky v J2EE aplikačních Podpora aplikační logiky v J2EE aplikačních rámcích rámcích Petr Matulík, Matulík, Tomáš Petr TomášPitner Pitner Masarykova univerzita v Brně, Fakulta informatiky Masarykova univerzita v Brně, Fakulta informatiky Abstrakt. Prostředí J2EE (Java2 Enterprise Edition) je dobrou volbou všude tam, kde jsou požadována robustní, platformově nezávislá řešení podnikových aplikací různého rozsahu. V příspěvku se zaměříme na velmi podstatnou vrstvu těchto aplikací – vrstvu aplikační logiky. Hlavní pozornost budeme logicky věnovat aplikačním rámcům (frameworks), neboť rámce pomáhají řešit základní úkoly návrhu architektury rozsáhlejších aplikací a jsou rovněž místem praktického uplatnění moderních programovacích technik a principů podporujících aplikační logiku – programování orientovaného na aspekty (či Aspect-Oriented Programming) a obrácení řízení (Inversion of Control). Vše bude ilustrováno na příkladech jednoduchého rámce VRaptor a komplexního rámce Spring.
1
Úvod
Prostředí J2EE (Java2 Enterprise Edition) je dobrou volbou všude tam, kde jsou požadována robustní, platformově nezávislá řešení podnikových aplikací různého rozsahu. V příspěvku se zaměříme na velmi podstatnou vrstvu těchto aplikací – vrstvu aplikační logiky – a její podporu v prostředích J2EE. Hlavní pozornost budeme logicky věnovat aplikačním rámcům (frameworks), jichž je pro J2EE k dispozici celá řada a patří již k základní výbavě soudobého vývojáře webových, ale i jiných javových aplikací. Rámce pomáhají řešit základní úkoly návrhu architektury rozsáhlejších aplikací a jsou rovněž místem praktického uplatnění moderních programovacích technik a principů podporujících aplikační logiku – programování orientovaného na aspekty (či Aspect-Oriented Programming) a obrácení řízení (Inversion of Control). Tyto techniky budeme demonstrovat na příkladech rámce jednoduchého (VRaptor) i komplexního (Spring). 1.1
Požadavky na aplikační logiku
Jelikož Java je objektový jazyk, je aplikační logika reprezentována metodami objektů. Snahou vývojáře je, aby aplikační logika byla kromě funkční správnosti – také přehledná, snadno testovatelná, udržovatelná a znovupoužitelná – a to i mimo prostředí, pro nějž primárně vznikla. Zajištění těchto mimofunkčních požadavků je mnohdy obtížnější než vyřešení samotné funkcionality. V poslední době se však objevilo (či znovuobjevilo) několik technik a přístupů, které to usnadňují. Nejprve se podívejme na to, jakými technikami je aplikační logika řízena.
c Václav Snášel, editor: Objekty 2005, pp. 157–168, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
158
1.2
Petr Matulík, Tomáš Pitner
Řízení aplikační logiky
Valná část moderních aplikací odděluje jednotlivé vrstvy a je vybudována na modelu MVC (model – view/pohled – controller/řadič). Aplikační vrstva je skryta v metodách modelu a aktivace těchto metod je posláním řadiče. O prezentaci výstupů uživateli se stará pohled. Velké procento aplikací – zejména webových – je realizovaných s pomocí tzv. aplikačních rámců. Rámce jsou z hlediska řízení charakteristické zejména použitím tzv. Hollywood Principle: „Do not call us, we will call you!“, což vyjadřuje, že nastává obrácení řízení (Inversion of Control, IoC). Namísto samotné výkonné komponenty obsahující vlastní aplikační logiku se o tok výpočtu stará rámec na základě pravidel specifikovaných vývojářem aplikace – rámec tedy volá metody komponent. Rámec tedy není prostá knihovna (i když knihovny může rovněž nabízet); jeho hlavní role spočívá v řízení toku aplikace a v jednotném zajištění nezbytných podpůrných služeb aplikacím. Jak ale rámec aplikaci řídí? 1.3
Deklarativní řízení
Valná většina rámců používá deklarativní řízení toku výpočtu. Tok výpočtu je řízen pravidly zachycenými v popisných souborech (deskriptorech), které dnes mají převážně strukturovanou XML podobu. Vezměme příklad webové aplikace. Uživatel zastupovaný webovým prohlížečem vyšle HTTP požadavek směrem k aplikaci vytvořené pomocí některého z webových aplikačních rámců. Deskriptor dané aplikace obvykle podle cílového URL nasměruje dotaz na příslušný řetěz zpracování: 1. nejprve je získán patřičný model, 2. na něm jsou volány metody aplikační logiky a 3. následně je na výsledek aplikován vhodný pohled, který se dostane zpět klientovi. Toto vše řídí aplikační rámec, nikoli samotná komponenta s aplikační logikou. To, že řízení je obráceno, že je uplatňováno zvenčí, dovoluje aplikační logiku znovupoužít i mimo její původní místo. 1.4
Injektáž závislostí
Obrácení řízení je již dlouho používaný návrhový vzor, jenž v původním významu představoval techniku, s jejíž pomocí dochází k přenesení řízení běhu programu z kódu, který navrhuje programátor, na podpůrný aplikační rámec. Lze tedy říci, že jakýkoliv moderní aplikační rámec včetně dále diskutovaného rámce Spring či EJB je aplikací návrhového vzoru IoC. S nástupem aplikačních rámců, jakými jsou Spring či PicoContainer, se však význam IoC začal posunovat a byl spíše používán pro popis způsobu, jakým je v těchto rámcích zajištěno provázání spravovaných komponent a řešení závislostí mezi nimi. Na toto zmatení pojmů reagovali přední teoretici i praktici v této oblasti (včetně Roda Johnsona) a rozhodli se pro zavedení nového pojmu injektáž závislostí
Podpora aplikační logiky v J2EE aplikačních rámcích
159
(Dependency Injection, DI). Zjednodušeně řečeno lze postup při použití DI popsat takto. Mějme závislost komponenty A na komponentě B; jinými slovy komponenta A obsahuje odkaz na komponentu B. Při použití DI budou při startu kontejneru, který je spravuje, obě komponenty vytvořeny a v komponentě A bude vytvořen odkaz na komponentu B. Existuje několik způsobů, jak toho lze dosáhnout, my však zmíníme jen dva zdaleka nejrozšířenější. První způsob umožňuje uspokojení závislostí prostřednictvím nastavovacích („set“) metod komponenty a proto bývá označován jako Setter Injection. Druhou možností je pak varianta s názvem Constructor Injection, která využívá standardních konstruktorů jazyka Java. A právě tyto dvě varianty jsou podporovány rámcem Spring 2 . V minulosti se provázání komponent dosahovalo buď přímou instanciací v kódu třídy, případně různými vyhledávacími („lookup“) mechanismy (např. JNDI) či aplikací návrhového vzoru Service Locator. Přestože v tomto pořadí šlo vždy o krok kupředu, všechna tato řešení jsou horší než IoC, a to zejména z hlediska příliš úzkého vzájemného svázání komponent a zhoršené čitelnosti a udržovatelnosti kódu. Nyní se podívejme na vybrané aplikační rámce a způsob, jakým uvedené techniky využívají. Za příklady zvolíme jeden komplexní rámec – Spring – a jako protiváhu jednoduchý rámec VRaptor. Začneme přitom tím jednodušším, kde jsou principy na první pohled vidět.
2
Jednodušší řešení – rámec VRaptor
V poslední době se jako odpověď na složitost „plných“ webových aplikačních rámců jako je Struts, WebWork nebo Spring zmíněný dále objevují jednoduché rámce neřešící „vše“. Příkladem takového rámce je VRaptor [2]. 2.1
Řízení toku
Nejdůležitějším posláním aplikačního rámce je řízení toku – rámec tedy realizuje obrácení řízení. Tok výpočtu vyřízení klientského požadavku je deklarativně specifikován popisným souborem vraptor.xml, který může vypadat např. takto (podrobněji viz dokumentace rámce VRaptor): <package name="chain"> chain/productList.vmchain/productForm.vm 2
Kromě toho se hovoří i o tzv. interface injection, která ale vyžaduje, aby komponenty, do nichž se závislost bude injektovat, implementovaly určité předepsané rozhraní, což je poměrně úzce svazuje s daným prostředím.
160
Petr Matulík, Tomáš Pitner
chain/productList.vmchain/productForm.vm
Popisovač rámci sděluje, jak reagovat na jednotlivé klientské požadavky – akce. Každá akce je realizovaná jako řetěz (element chain) operací (elementy logic) zakončený obvykle zobrazením výsledku operací (element view). Jak vidět, samotná aplikační logika proces neřídí a má být znovupoužitelná mezi různými akcemi – viz např. metoda listAll třídy ProductLogic. Aby byla logika opravdu znovupoužitelná, musí však být vhodně napsaná.
2.2
Nezávislost aplikační logiky
Podívejme se, jak VRaptor umožňuje vyčlenění aplikační logiky mimo prostředí úzce svázané se servlety a dalšími prvky JavaServlet API. Příklad převzatý z dokumentace VRaptor ukazuje na triviálním úloze obrácení zadaného řetězce, jak zbavit aplikační logiku závislosti na konkrétním prostředí (API): public class TextInverser { private HttpServletRequest request; private RaptorContext context; public TextInverser(HttpServletRequest request, RaptorContext context) { this.request = request; this.context = context; } public void invertName() { String submittedName = this.request.getParameter("name"); String inversedName = null; if (submittedName != null) { StringBuffer buffer = new StringBuffer(submittedName); buffer.reverse(); inversedName = buffer.toString();
Podpora aplikační logiky v J2EE aplikačních rámcích
161
} this.context.put("name", inversedName); } }
Výstup výše uvedené metody invertName je vložen do kontextu (objekt context) rámce. To umožní tento výsledek následně zobrazit v prezentační vrstvě realizované např. rámcem Velocity, populárním FreeMarkerem nebo klasickými JSP. Izoluje tedy aplikační logiku od prezentační. Souhra aplikační logiky a následné prezentace je zajištěna deklarací v souboru vraptor.xml (umístěn v adresáři /WEB-INF webové aplikace): <package name="simple"> simple/templateWithServletAndVRaptorStuff.vm
Tento postup však stále předpokládá, že aplikační logika realizovaná třídou TextInverser zná JavaServlet API (např. třídu HttpServletRequest) a rovněž API rámce VRaptor (třída Context) a je na nich tedy závislá. Odstranění závislosti na obou zmíněných API lze provést takto: public class TextInverser { private HttpServletRequest request; private String name; public TextInverser(HttpServletRequest request) { this.request = request; } public void invertName() { String submittedName = this.request.getParameter("name"); String inversedName = null; if (submittedName != null) { StringBuffer buffer = new StringBuffer(submittedName); buffer.reverse(); inversedName = buffer.toString(); } this.name = inversedName; } public String getName() { return this.name; } }
Místo, abychom výsledek inverze uložili do přímo kontextu VRaptoru, je zde místo toho dána k dispozici metoda getName(), kterou klient (např. rámec VRaptor, ale i kdokoli jiný) po provedení inverze zavolá, aby získal výsledek. Tím je odstraněna svázanost s rámcem VRaptor. Zbývá odstranit závislost na JavaServlet API:
162
Petr Matulík, Tomáš Pitner
public class TextInverser { private String name; public void invertName() { if (this.name != null) { StringBuffer buffer = new StringBuffer(this.name); buffer.reverse(); this.name = buffer.toString(); } } public String getName() { return this.name; } public void setName(String name) { this.name = name; } }
Vstupní parametr name lze nyní nastavit metodou setName, o jejíž zavolání se ovšem musí postarat rámec, který to zajistí za běhu aplikace pomocí reflexe. Přijde-li ve vstupu od klienta – webového prohlížeče parametr name, rámec vyvolá setName a jméno nastaví podle hodnoty parametru. Pak zavolá metodu invertName a výsledek bude k dispozici metodou getName. Rámec tedy k nastavení používá tzv. Setter Injection, tj. injektáž hodnoty pomocí metod setXXX. VRaptor takto umí nastavovat i parametry jiných typů než String – automaticky provede konverzi. Po poslední úpravě je aplikační logika představovaná třídou TextInverser nezávislá na API servletů i VRaptoru – a tedy 100% znovupoužitelná. 2.3
Interceptory
VRaptor umožňuje podobně jako u programování orientovaného na aspekty definovat speciální ortogonálně (znovu)použitelné části aplikační logiky zvané interceptory (Interceptors). Jsou to třídy, jejichž metody jsou volány ve význačných okamžicích vyřizování klientského požadavku: • před vstupem do řetězce, • po jeho realizaci (před aplikací pohledu) • a po ní. Takto lze např. velni snadno realizovat protokolování (logging) běhu aplikace: public class LoggingInterceptor implements ChainInterceptor { private static Logger logger = Logger.getLogger(LoggingInterceptor.class); public void beforeChain(RaptorData data) { logger.info("before chain"); } public void afterChain(RaptorData data) { logger.info("after chain"); }
Podpora aplikační logiky v J2EE aplikačních rámcích
163
public void afterViewRendering(RaptorData data) { logger.info("after view rendering"); } }
Podobné úlohy je někdy možné zvládnout i s pouhým JavaServlet API – použitím tzv. filtrů [3], ale tam vzhledem k neoodělení fáze aplikační logiky od prezentační není tak snadné proniknout k jednotlivým fázím životního cyklu požadavku. Interceptory jsou také, jak vidět, daleko elegantnější. Vlastní „intercepce“ je zajištěna deklarací domény, v níž interceptor použijeme: <domain name="logging-interceptor-domain">
Vlastní aplikační logika (představovaná třídou SomeLogic a doSomething musí deklarovat, že je v příslušné doméně s intercepcí:
Hitem v oblasti vývoje pokročilých J2EE aplikací se v průběhu posledních tří let stal rámec pro jejich správu s názvem Spring. V základech tohoto open-source projektu se nachází kód, který byl publikován v roce 2003 Rodem Johnsonem v jeho knize J2EE Design and Development [1] a který odráží Johnsonovu několikaletou analytickou, konzultantskou ale i programátorskou zkušenost s tvorbou rozsáhlých J2EE aplikací. Tento kód byl autorem navržen pro zefektivnění řešení některých běžných problému, se kterými se každý vývojář pokročilých Java aplikací setkává téměř denně, a celkově pro zjednodušení a snížení ceny návrhu a vývoje těchto programů. Jeho intenzivním rozšiřováním vznikl aplikační rámec, jehož celkový počet stažení se k dnešnímu dni rychle blíží k půl miliónu. 3.1
Charakteristika
Spring [4] je modulární Java/J2EE aplikační rámec, jenž také bývá někdy označován jako odlehčený (lightweight) kontejner. Využíván je stejně jako Enterprise JavaBeans zejména pro tvorbu webových aplikací, ale lze jej použít v podstatě pro jakýkoliv typ aplikace, včetně aplikací s grafickým rozhraním.
164
Petr Matulík, Tomáš Pitner
Cílem tohoto projektu je samozřejmě zejména usnadnění vývoje Java (a zejména J2EE) aplikací. Prostředků k dosažení tohoto primárního cíle poskytuje Spring několik. Prvním z nich je podpora pro aplikační vrstvu programů, což je vlastnost, která je na trhu unikátní a která představuje hlavní lákadlo pro vývojáře J2EE aplikací. Budeme se jí proto později věnovat podrobněji. Dalším důležitým cílem použití rámce Spring je snadná testovatelnost výsledné aplikace. Spring, jak později uvidíme, umožňuje čistým a pohodlným způsobem vzájemně oddělit nejen jednotlivé vrstvy, ale dokonce i jednotlivé objekty, což je klíčovou podmínkou pro možnost využití testování jednotek (unit testing). Vzhledem k tomu, že agilní metodiky vývoje software, které jsou na testování ve většině případů postaveny, jsou stále populárnější a rozšířenější, je rovněž tato vlastnost rámce považována za klíčovou. Drtivá většina existujících aplikačních rámců se soustřeďuje na podporu jen určité architekturní vrstvy aplikace. Příkladem budiž oblíbený rámec Struts, který usnadňuje vývoj webové prezentační vrstvy aplikací, nebo neméně populární objektově-relačně mapovací nástroj Hibernate, orientující se na datovou (perzistenční) vrstvu. Spring naproti tomu konzistentním způsobem podporuje všechny vrstvy aplikací, prezentační vrstvou počínaje, přes již zmíněnou aplikační vrstvu až k datové a perzistenční vrstvě. Zásadou vývoje aplikačního rámce Spring je nevynalézat kolo. Integrace velkého množství rozšířených softwarových nástrojů poskytuje uživateli možnost využít specializovaných a časem prověřených řešení na danou problémovou oblast, a to konzistentním způsobem. K těmto podporovaným nástrojům patří samozřejmě již zmíněné Struts a Hibernate, jejich celkové množství však jde řádově do desítek. 3.2
Podpora aplikační vrstvy
Jak už jsme se výše zmínili, chtěli bychom se v tomto příspěvku věnovat zejména podpoře, kterou Spring poskytuje aplikační vrstvě programů. Objekty, které tvoří aplikaci, jsou během svého životního cyklu spravovány kontejnerem rámce Spring a výjimku netvoří ani objekty aplikační vrstvy. Spring opravdu spravuje aplikaci již na úrovni objektů, nikoliv ucelených komponent, jako je tomu u EJB. Ke službám, které může návrhář aplikace pro správu objektů využít, patří zejména jednotné procedurální i deklarativní řízení transakcí, jednotný způsob konfigurace aplikace v době nasazení, pokročilá procedurální i deklarativní správa zabezpečení, správa provázání a závislostí objektů, pooling objektů a další. Stěžejními technologiemi, které poskytování těchto služeb umožňují jsou aspektově orientované programování a obrácení řízení. Pokud jde o AOP, tak lze použít jednak vlastního řešení rámce Spring, které je postaveno na standardních dynamických proxy jazyka Java, je ale také možno využít integrace s populárním open-source nástrojem AspectJ. Implementace obrácení řízení, respektive injektáže závislostí v rámci Spring představuje pravděpodobně nejkomplexnější řešení těchto technik vůbec.
Podpora aplikační logiky v J2EE aplikačních rámcích
3.3
165
Injektáž závislostí
Kontejner rámce Spring (nazývaný také aplikační kontext) při svém startu načte definiční soubor. Na základě definic v něm uvedených vytvoří pomocí reflexe specifikované objekty, vzájemně je prováže a tuto síť objektů spravuje po dobu běhu aplikace. Definiční soubor mívá v drtivé většině případů formát XML, lze ovšem použít i jiné formáty, například tzv. „properties“ soubor. Uveďme si nyní příklad obsahu takového XML definičního souboru: <property name="konf"> nejakaHodnota <property name="dao" >
Předpokládejme tedy existenci následujících tříd a rozhraní: interface NejakeDao {} class NejakeDaoImpl implements NejakeDao {} interface NejakaSluzba {} class NejakaSluzbaImpl implements NejakaSluzba { private NejakeDao dao; private String konf; public void setDao(NejakeDao dao) { this.dao = dao; } public void setKonf(String konf) { this.konf = konf; } }
V tomto případě by kontejner použil k injektáži závislostí Setter Injection a prostřednictvím reflexe provedl kód ekvivalentní tomuto: NejakeDao nejakeDao = new NejakeDaoImpl(); NejakaSluzba nejakaSluzba = new NejakaSluzbaImpl(); nejakaSluzba.setKonf("nejakaHodnota"); nejakaSluzba.setDao(nejakeDao);
Nastavení atributu konf třídy NejakaSluzbaImpl ilustruje konfigurační možnosti rámce Spring. Stejným způsobem lze inicializovat hodnoty atributů ostatních primitivních typů. Nastavení atributu dao třídy NejakaSluzbaImpl naopak ukazuje, jakým způsobem lze využít Spring pro správu provázání a závislostí objektů. Pojmenujeme-li tento definiční soubor kontext.xml a umístíme-li jej do classpath, pak kontejner nastartujeme například takto: ApplicationContext context = new ClassPathXmlApplicationContext("/kontext.xml");
166
Petr Matulík, Tomáš Pitner
Vytvořenou službu s id nejakaSluzba získáme z kontejneru voláním: NejakaSluzba sluzba = (NejakaSluzba)context.getBean("nejakaSluzba");
Pomocí dalších deklarací v tomtéž souboru lze také definovat, jakým způsobem budou dříve vyjmenované služby poskytnuty našim objektům. Naše třídy se tedy nemusí například transakčním či bezpečnostním managementem zabývat, vše zajistí Spring. 3.4
Programování orientované na aspekty
Na podrobný vhled do techniky zvané programování orientované na aspekty (AspectOriented Programming, AOP) není v tomto článku prostor, dostatek informací je však možné najít např. v [5] nebo [6]. AOP v zásadě směřuje k tomu, jak elegantně dosáhnout vyčlenění opakovaných „nezáživných“, „režijních“ částí kódu, řešících obvykle nějaké (mimofunkční, napříč jdoucí) záměry (cross-cutting concerns, např. autentizaci/autorizaci klienta při vstupu do určité metody, protokolování volání metod, přístup k perzistentnímu úložišti dat …) do tzv. pokynů (advices). Tyto jsou vyčleněny do speciálních tříd a deklarativním způsobem je řečeno, kam všude se příslušný pokyn má aplikovat (ta místa se označují jako point-cuts). Běhové prostředí příslušného nástroje pro AOP (pro Javu je známý např. AspectJ [7]) pak zajistí aplikaci příslušného pokynu a vzniká tak tzv. aspekt (aspect). Podívejme se teď na příklad zapojení AOP v rámci Spring: <property name="advice"> <property name="patterns"> <list> .*get.*.*set.* <property name="proxyInterfaces"> cz.neco.NejakaSluzba
Podpora aplikační logiky v J2EE aplikačních rámcích
V tomto příkladu jsme opět využili objekt aplikační vrstvy NejakaSluzbaImpl z předchozího příkladu. Dále jsme definovali objekt třídy NejakyInterceptor, který představuj samotný interceptor, tedy kus kódu, který se bude vykonávat před nebo po provedení nějaké metody. Objekt s id nejakyAdvisor definuje, že interceptor nejakyInterceptor bude aplikován na „get“ a „set“ metody cílového objektu a konečně objekt s id proxySluzba představuje proxy pro náš objekt aplikační vrstvy. V konečném důsledku tedy definuje, že před a/nebo po provedení jakékoliv „get“ nebo „set“ metody cílového objektu s id nejakaSluzba bude proveden kód objektu nejakyInterceptor. Jelikož jde o příklad použití AOP na rozhraních, lze výsledný objekt s id proxySluzba přetypovat pouze na specifikovaná rozhraní – v našem případě rozhraní NejakaSluzba. Za pomoci knihovny CGLIB lze však v rámci Spring aplikovat AOP i na konkrétní třídy. 3.5
Řízení transakcí
Tímto jsme si připravili půdu pro krátkou ukázku deklarativního řízení transakcí, které je postaveno na právě předvedených možnostech AOP. <property name="transactionManager"> <property name="target"> <property name="transactionAttributes"> <props> <prop key="insert*"> PROPAGATION_REQUIRED,-NejakaVyjimka <prop key="update*">PROPAGATION_REQUIRED <prop key="*">PROPAGATION_REQUIRED,readOnly
Zde jsme definovali transakční proxy pro naši třídu aplikační vrstvy a transparentním způsobem jsme z ní v podstatě vytvořili transakční kód. Konkrétně zde je specifikováno, že na všechny metody, jejichž název začíná řetězcem „insert“,
168
Petr Matulík, Tomáš Pitner
bude uplatněno standardní transakční chování s propagací platnosti transakcí do nižších úrovní, a navíc že pokud daná metoda vyvolá výjimku třídy NejakaVyjimka, pak transakce bude vrácena zpět (proběhne rollback). Pokud bychom definovali příznak +NejakaVyjimka, pak by se při vyvolání výjimky třídy NejakaVyjimka provedl commit transakce. U jiných než „insert“ a „update“ metod pak definujeme, že transakce je pouze pro čtení. Velmi podobným deklarativním a snadným způsobem lze definovat například přístupová práva k jednotlivým objektům a metodám, pooling objektů a další užitečné služby, bez nichž se aplikační vrstva J2EE systémů často neobejde.
4
Perspektivy
O výhodnosti použití technik obrácení řízení a programování orientovaného na aspekty svědčí i fakt, že podobné směry zvolili autoři návrhu standardu Enterprise JavaBeans 3.0. Tento aplikační rámec by také měl při správě aplikační logiky programů využívat výhod IoC a AOP a do jisté míry kopírovat přístupy, které se do povědomí širokých vývojářských vrstev dostaly do značné míry díky aplikačnímu rámci Spring. Čím dříve jako vývojáři J2EE aplikací tyto principy zvládneme, tím lépe. Časem nám stejně nic jiného nezbude…
Reference 1. Rod Johnson. J2EE Design and Development. Wiley Publishing, 2003, Indianapolis. ISBN:0764543857. 2. VRaptor – Simple Web MVC Framework. http://vraptor.dev.java.net 3. JavaServlet API. http://java.sun.com/products/servlet/docs.html 4. Spring Framework. http://www.springframework.org 5. Aspect-Oriented Programming. http://dmoz.org/Computers/Programming/Methodologies/Aspect-Oriented 6. Kroha, P. Aspektově orientované programování. Tutoriál konference DATAKON 2005, Brno, 2005. 7. AspectJ. http://eclipse.org/aspectj
Podstata konceptuálního modelování KONCEPTUÁLNÍHO MODELOVÁNÍ Martin Molhanec1 Martin Molhanec 1 České vysoké FEL,K-313 K-313 České vysokéučení učenítechnické technické – FEL, Technická 27 PRAHA Praha 6,6,Dejvice, republika Technická 2, 2, 166 27 Dejvice, Česká Česká republika [email protected][email protected]
Abstrakt. Obsahem příspěvku jsou úvahy o podstatě konceptuálního modelování. Autor nejprve definuje co je vlastním obsahem konceptuálního modelování. Bude se dále zabývat pojmy, jako jsou objekt, vlastnost, podobnost, třída, struktura a souvislost..
1
Úvod
Jako tradičně v posledních letech, se můj příspěvek na této konferenci zabývá problematikou konceptuálního modelování, především objektově orientovaného, jeho chápáním a způsobem jeho výkladu. Aniž bych si dělal nárok na neomylnost, a fakta obsažená v tomto příspěvku je nutné chápat jako osobní vhled autora na tuto problematiku, jsem přesvědčen o skutečnosti, že se neškodí neustále vracet k vlastní podstatě pojmů, jako jsou pojmy: modelování, koncept, objekt, třída, entita, vztah atp. Motivem pro vznik mých příspěvků [1], [2], [3], [4] a [5] na téma problematika objektového přístupu a jeho konceptuálního modelování byla především skutečnost, že jsem při četbě různých učebnic vykládajících objektový přístup, v poslední době výlučně založených na výkladu UML, zjistil, že s jejich autory a jejich pojetím a výkladem četných pojmů bytostně nesouhlasím. Díky této uvedené skutečnosti, jsem se dostal ke snaze lépe proniknout do základních principů konceptuálního objektového modelování. Některé svoje úvahy na toto téma jsem již uveřejnil na konferenci Tvorba software 2005 [1] a Objekty 2004 [2] aniž by, jak se zdá, zasáhly širší odbornou veřejnost.
2
Konceptuální modelování
Co je vlastní podstatou konceptuálního modelování? Anglické slovo conceptual překládáme českým slovem pojmový. Jedná se tedy o pojmový model. Dle [10] konceptuální model představuje abstraktní pohled na některé aspekty reálného světa. Konceptuální model může být použit pro různé účely, jako prostředník pro komunikaci mezi uživatelem a vývojářem (informačního systému), pro řízení a porozumění složitých systému v určité oblasti, dokumentaci systému, atp. Podobně v [11] je připomenuto, že konceptuální model je softwarově inženýrská prezentace věčné filosofické otázky o tom, jak reprezentovat správně realitu světa kolem nás. Základem pro konceptuální paradigma je filosofie! Z faktů zde uvedených, lze vyvodit následující teze:
c Václav Snášel, editor: Objekty 2005, pp. 169–174, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
170
Martin Molhanec
• • •
Zdrojem konceptuálního paradigmatu je filosofie. Konceptuální modelování se zabývá modelováním skutečností reálného světa, a proto musíme tento svět pochopit a popsat prostřednictvím pojmů z tohoto světa. Konceptuální modelování není žádným způsobem závislé na případné implementaci jím vytvořeného modelu.
Jaké modely však tvoří obsah konceptuálního modelování? Na tuto otázku není triviální odpověď. Vzhledem ke složitosti reality kolem nás obsahuje pojem konceptuální modelování celou řadu modelů, které modelují různé aspekty reality. Skutečnost, že se nesnažíme modelovat najednou celou realitu v jednom modelu, spočívá ve skutečnosti, že bychom pak nebyli schopni takový model jako jeden celek pochopit. Nejčastěji se mluví o dvou modelech: o modelu statickém a dynamickém (funkčním). • Statický model zachycuje strukturu modelovaného systému. • Dynamický model zachycuje funkcionalitu modelovaného systému v čase. 2.1
Statický konceptuální model
Jak již bylo předesláno, statický konceptuální model se zabývá strukturou systému (reálného světa) kolem nás. Tady je nutné připomenout, že strukturou rozumíme ne toliko fyzické skládání objektů ve světě kolem nás, ale i jejich podobnost a existenci souvislostí mezi jednotlivými objekty v realitě. Ve svém příspěvku na konferenci Objekty 2004 [2] se zabývám vymezením pojmu konceptuální statického modelování. Pojem vymezuji pomocí následujících tvrzení: • Objektem jeho zájmu jsou objekty v reálném nebo abstraktním světě (objekty). • Zajímá se o vlastnosti těchto objektů (atributy). • Zajímá se o identifikaci těchto objektů (identifikátor objektu). • Jeho zájmem je klasifikace těchto objektu dle různých společných vlastností (třídy). • Jeho zájmem jsou vztahy mezi těmito klasifikačními třídami (dědičnost). • Jeho zájmem je vzájemná strukturalizace těchto objektů (skládání). • Zajímá se o vzájemné souvislosti mezi objekty a o klasifikaci těchto vztahů (vztahy obecné). • Zajímá se o životní cyklus objektu (vznik, trvání, zánik). • Zajímá se o chování objektu (reakce na interní a externí události). Podívejme se nyní na některé výše uvedené pojmy podrobněji. 2.2
Objekty a jejich vlastnosti.
Pokusme se pojem objekt chápat intuitivně, koneckonců jako jeden z nejzákladnější pojmů objektového paradigma bude stěží moci být definován pomocí ostatních pojmů. V monografii Object-Oriented Analysis autoři Coad a Yourdon [6] konstatují:
Podstata konceptuálního modelování
171
„Od poloviny 70 let se v oboru informačního modelování začal užívat pojem objekt velice nestandardním způsobem v porovnání s jeho používáním v předešlých stoletích. V metodách entitně-vztahového modelování (Chen [7]), informačního modelování (Flavin [8]) a sémantického datového modelování (Shlaer a Mellor [9]) se termínem objekt rozumí pojem, který reprezentuje jeden nebo více výskytů jsoucnosti z reálného světa“. O něco dále autoři uvádějí svojí definici pojmu objekt takto: „Objekt je abstrakcí něčeho v oblasti našeho zájmu, reflektující schopnosti systému o tomto udržovat informaci a/nebo s tím interagovat. Je to také množina jemu (objektu) přináležejících hodnot atributů a výlučných služeb.“. Z odkazu na výše uvedené, můžeme proto pojem objekt jednoduše definovat, jako něco co existuje v reálném nebo abstraktním světě, jako pojem, který má nějaký smysl. Objektem je všechno o čem lze něco říci, každý objekt je pojem a každý pojem se stává objektem v určitém smyslu slova. Termíny jako osoba, faktura, automobil, slovo nebo barva jsou určité pojmy, které mají svůj význam, ale také to jsou objekty, které mají své vlastnosti (atributy) a které jsou v zájmové oblasti našeho informačního modelování. 2.3
Otázka vztahů
Zajímavou skutečností je fakt, že jsme zatím při našich úvahách nepotřebovali definici něčeho, jako jsou vztahy. To, co je považováno za vztahy, není prvotní. Vztahem totiž v konceptuálním modelování nazýváme několik od sebe rozdílných vlastností vyplývajících ze vzájemných souvislostí mezi objekty, které mají společné toliko to, že se snaží množinu všech objektů podle různých hledisek utřídit (klasifikovat). Je zajímavé, že z tohoto úhlu výkladu je jedním z naprosto primárních vztahů vztah mezi objektem samotným a jeho vlastností (atributem), která je přeci také objektem! Podobnost. Podíváme-li se na naší relevantní množinu objektů, uvidíme, že některé objekty jsou si v něčem podobné. Mají totiž shodné množiny vlastností. Například všechny objekty, které udržují informaci o nějakých osobách, mají z našeho úhlu pohledu stejnou množinu relevantních vlastností! Tuto vlastnost – vztah, protože je to vlastnost daná určitou souvislostí mezi objekty, nazvěme podobností. Objekty, které si jsou podobné, jsou stejného typu, a můžeme tedy hovořit o vlastnosti typovosti. Množinu objektů stejného typu nazvěme třídou (class). Protože každý pojem je objektem i pojem třída je objektem, množina tříd je také pojem, je metatřídou (metaclass) a je to také objekt,… Pojem dědičnosti potom můžeme definovat následujícím způsobem. Třída, která má nadmnožinu vlastností jiné třídy jest jejím potomkem a třída, která má podmnožinu vlastností jiné třídy jest jejím předkem. Struktura. Není pochyb o tom, že ve světě kolem nás se vyskytují různé struktury! Jaké je podstata této skutečnosti? • Celek jen pojem pro souhrn částí. (Například nůž je souhrn střenky a rukojeti.) • Část je pojem pro podíl celku. (Například noha je podíl těla.)
172
Martin Molhanec
•
Objekt obsahuje jiné objekty. (Například místnost obsahuje osoby, stoly, židle, atp.)
V konceptuálním modelování je zvykem tento typ vztahu (vyjadřujícího strukturu) nazývat následujícími termíny: celek-část, agregace, kontejner nebo kompozice. Bohužel se terminologie různých autorů liší. Další problém je v preciznosti vyjádření tohoto vztahu! Důležité pro pochopení významu vztahu struktury je fakt, že dané struktury skutečně existují a nejsou pouhou abstrakcí nějaké souvislosti mezi dvěma objekty! Souvislost. Posledním typem vztahu je prostý vztah – souvislost mezi objekty. Prostým vztahem může být například vztah mezi autorem a knihou, je to vztah M : N a není to vztah typu podobnosti (dědičnosti) ani struktury (kontejneru). Nicméně, bezpochyby lze tvrdit, že výrok je autorem je zcela určitě vlastností, podobně jako tvrzení má autora. Obě výše uvedená tvrzení (výroky) dávají skrze své vlastnosti do souvislosti různé objekty, které nejsou stejného typu ani se ze sebe navzájem neskládají! Nicméně nelze pochybovat, že autor napsáním knihy vytvořil určitou souvislost mezi sebou a danou knihou, má jistě smysl se ptát, kdo danou knihu napsal či jaké knihy napsal daný autor. Je nutné připomenout skutečnost, že i kdyby neexistoval jediný fyzický záznam o tom, že daný autor napsal danou knihu, přesto je nepochybné to – že jí byla někým napsána! 2.4
Dynamický konceptuální model
Je na místě poněkud upřesnit co v tomto textu myslíme pojmem dynamický konceptuální model. Především zde nestudujeme funkcionality jakéhokoliv informačního systému, který plní nějaké určité požadavky uživatele, leč studujeme chování části reálného světa, který je objektem našeho konceptuálního modelování! I zde pochopitelně studujeme chování objektů vztažené k naší problémové oblasti (problem domain). Dynamický model je založen na popisu reakcí (aktivit), které reagují na určité akce (události). Existují následující zdroje událostí, na které objekt může reagovat: • Interní časová (V určitém věku objekt osoba dostane přidělen občanský průkaz.) • Interní datová (Je odvozena od kombinace hodnot atributů daného objektu.) • Externí vztahová (Je odvozena od skutečnosti, že objekt vstupuje či vystupuje do/ze vztahů s jinými objekty.) • Externí datová (Je odvozena od skutečnosti, že daný objekt může být cílem zpráv, které vysílá jiný objekt.) Reakce na výše uvedené události mohou být následující: • Interní datová (Změna obsahu atributů v daném objektu.) • Externí vztahová (Objekt vstupuje či vystupuje do vztahů s jinými objekty.) • Externí datová (Objekt zasílá zprávu jinému objektu či objektům.)
Podstata konceptuálního modelování
173
Speciálními případy je pak vznik a zánik objektu. Nicméně tyto dvě události, lze obecně považovat za speciální případ událostí výše uvedených. Ostatně celá na první pohled jednoduchá záležitost se komplikuje, pokud vezmeme v potaz skutečnost, že i čas může být speciální forma atributu a podobně i vztah je jenom určitou formou atributu, protože každý atribut může být ve skutečnosti objektem a v dokonale objektovém modelu jsou objekty i vztahy. Důležitá je však skutečnost, že nás při modelování systému z reálného světa nezajímají všechny události, na které může modelovaný systém reagovat, ale pouze ty, které souvisejí s tím, jak systém reaguje na události, které jsou součástí naší problémové domény. Jednoduše řečeno, při modelování studenta vysoké školy, z hlediska problémové domény informačního studijního systému, nás zajímá, jak bude objekt student reagovat na dosažení požadovaného počtu kreditů a nikoliv, jakým způsobem bude student reagovat na skutečnost, že ho opustila jeho dívka!
3
Závěr
Náš výklad pojmů z oblasti konceptuálního modelování je možné dále upřesňovat a doplnit o celou řadou dalších příkladů. Domnívám se, že kvalifikované uvažování o základních principech pojmů, se kterými zacházíme, je důležité pro další rozvoj oboru, ve kterém tyto pojmy užíváme a je to také důležité s ohledem na jejich výuku a praxi. Výklad pojmů v tomto příspěvku není pochopitelně jediným vhledem do celé problematiky. Jako příklad poněkud odlišného, ale současně moderního a netradičního pojetí chápání objektově orientovaného paradigmatu je možné uvést koncepci autorů původní české metodiky BORM [12]. Neexistuje pochopitelně jediná definitivní odpověď, které paradigma, který výklad je ten správný. Bez neustále diskuze o základních pojmech oboru není možný jeho další rozvoj!
Reference 1. Molhanec, Martin. „Zásady konceptuálního totálně objektově orientovaného modelování“ In: Tvorba softwaru 2005. Ostrava: VŠB, 2005, s. 153-158. ISBN 80-86840-14-X. 2. Molhanec, Martin. „Několik poznámek k porozumění objektového paradigmatu“. Sborník konference Objekty 2004, Praha. ČZU PEF 2004, s. 189-197. ISBN 80248-0672-X. 3. Molhanec, Martin. „Kritika některých výkladů objektově orientovaného paradigmatu“. Sborník konference Tvorba software 2004. Ostrava. Tanger, 2004, s. 163-172. ISBN 80-85988-96-8. 4. Molhanec, Martin. „Objektové metodologie – jejich užití a výklad“. Sborník konference Tvorba software 2003. Ostrava. Tanger, 2003, s. 111-115. ISBN 8085988-83-6.
174
Martin Molhanec
On line: http://martin.feld.cvut.cz/~molhanec/VaV/files/publik/2003/OOkritco.pdf 5. Molhanec, Martin. „UML – několik kritických poznámek“. Sborník konference Tvorba software 2002. Ostrava. Tanger, 2002, s. 150-159. ISBN 80-85988-74-7. On line: http://martin.feld.cvut.cz/~molhanec/VaV/files/publik/2002/UML.pdf 6. Coad, P., Yourdon, E.: Object-Oriented Analysis. YOURDON PRESS, 1991. ISBN 0-13-629981-4 7. Chen, P. "The Entity Relationship Model Toward a Unified View of Data". ACM Transaction on Database Systems. March 1976. 8. Matt Flavin: Fundamental Concepts of Information Modeling. Prentice-Hall, 1979. 9. Sally Shlaer, Steve Mellor: Object-Oriented Systems Analysis. Prentice-Hall, 1988. 10. Manfred A. Jeusfeld. “Conceptual Modeling in a Computerised World”. In: System Development Topsy Turvy – Controlling the Process. Proc. Annual Congress SBIT, Tilburg University, march 24, 1998. 11. Pastor Oscar, Fons Joan, Torres Victoria, Pelechano Vicente. “Conceptual Modelling versus Semantic Web: the two side of the same coin?” In: Proceedings of the WWW2004 Workshop on Application Design, Development and Implementation Issues in the Semantic Web. New York, NY, USA, May 18th, 2004. 12. Carda A., Merunka V., Polák J.: Umění systémového návrhu – objektově orientovaná tvorba informačních systémů pomocí původní metody BORM. Grada, Praha 2003. ISBN 80-247-0424-2.
Formální pohled mezirefaktoringem, refaktoringem, Formální pohledna navztah vztah mezi návrhovýmivzory vzory a normalizací objektů návrhovými normalizací objektů 1 Oldřich Nouza Oldřich Nouza 1
Katedra matematiky, FJFI,FJFI, ČVUTČVUT v Praze,vBřehová Katedra matematiky, Praze, 7, 115 19, 1 Břehová7, 115Praha 19, Praha 1 [email protected][email protected]
Abstrakt. Refaktoring, návrhové vzory a normalizace objektů - v dnešní době často zmiňovaná a diskutovaná témata. V Tomto příspěvku je pojednáváno především o souvislostech mezi nimi a nastíněn způsob, jak tyto souvislosti vyjádřit pomocí jednotných formálních prostředků.. Klíčová slova: návrhové vzory, objekty, normalizace, refaktoring, UML
1
Úvod
Při vývoji rozsáhlých softwarových projektů mají refaktoring, používání návrhových vzorů a normalizace objektů již delší dobu své uplatnění. Přestože tyto aspekty moderního softwarového inženýrství mají mezi sebou úzký vztah, souvislosti mezi nimi jsou často opomíjeny. Jak bude nastíněno v následujících odstavcích, principy refaktoringu, návrhových vzorů a normalizace objektů jsou v podstatě stejné – jen se v každém z těchto případů aplikují jiným způsobem. Je několik možností, jak tyto principy vyjádřit. Samozřejmě se nabízí slovní popis, což ovšem bývá velice nepřehledné. Názornější je grafické vyjádření. Použití formálního jazyka na přehlednosti sice moc nepřidá, má však jednu velkou výhodu – vhodně navržený formální jazyk je algoritmicky rozpoznatelný, což usnadňuje implementaci refaktoringu, návrhových vzorů a normalizace objektů, např. v CASE nástrojích či jiných aplikací používaných při vývoji softwarových projektů.
2
Vysvětlení pojmů
Rozhodně nebude na škodu, když nejdříve připomeneme, co vlastně refaktoring, návrhové vzory a normalizace objektů jsou. 2.1
Refaktoring
Refaktoring lze definovat jako libovolnou transformaci systému, přičemž chování systému zůstane nezměněno. Výjimkou může být doba odezvy na některé impulsy ze
c Václav Snášel, editor: Objekty 2005, pp. 175–187, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
176
Oldřich Nouza
strany uživatele, nicméně z uživatelského pohledu refaktoring prakticky nemá význam. Z hlediska softwarového vývoje však může být refaktoring velmi užitečný. Lze jej použít jak na úrovni návrhu (pak hovoříme o refaktoringu modelu), tak na úrovni implementace (v tomto případě se jedná o refaktoring zdrojového kódu). Vhodně provedený refaktoring může přinést následující: • Zvýšení přehlednosti – Např. s rostoucím počtem řádků v těle metody klesá její přehlednost. Vhodné rozdělení této metody na dvě či více přehlednost zvýší. • Usnadnění dalších úprav – Toto přímo souvisí s přehledností. Přehlednější model, popřípadě zdrojový kód, lze rychleji rozluštit, a tím i upravit. Příklad 1. Na obr. 1 je znázorněn zjednodušený model tříd primitivního prohlížeče vektorových obrazců. Kruž n ic e
Obr. 1. Třídy Kružnice a Obdélník bez společného rozhraní
Třída Plátno představuje plátno, na které se obrazec vykresluje, a zapouzdřuje třídy Kružnice a Obdélník. Třída Kružnice obsahuje atributy x, y a poloměr, které udávají souřadnice středu a poloměr kružnice, a třída Obdélník atributy x1, y1, x2 a y2, které vymezují příslušnou obdélníkovou oblast. Obě třídy navíc obsahují atribut barva představující barvu a metodu nakresli(), která se stará o vykreslení daného útvaru. Třída Plátno obsahuje metodu nakresliVše(), která vykreslí všechny zapouzdřené kružnice a obdélníky na plátno tím, že zavolá metodu nakresli() postupně všech zapouzdřených instancí tříd Kružnice a Obdélník. Třídy Kružnice a Obdélník mají dost společného, a proto se nabízí definovat jejich společného předka, abstraktní třídu GeometrickýÚtvar Do ní přesuneme společný atribut barva a definujeme v ní abstraktní metodu nakresli(). Třída Plátno bude zapouzdřovat třídu GeometrickýÚtvar místo tříd Kružnice a Obdélník. Model tříd po refaktoringu je zachycen na obr. 2.
Formální pohled na vztah mezi refaktoringem, návrhovými vzory. . .
P lá tn o
177
G e o me tric k ýÚ tv a r # barv a:integer
+ nak resliVše()
0..*
+ nak resli()
Kru ž n ic e + x:integer + y:integer + poloměr:integer
O b d é ln í k # # # #
x1:integer y1:integer x2:integer y2:integer
+ nak resli() + nak resli()
Obr. 2. Třídy Kružnice a Obdélník implementující společné rozhraní GeometrickýÚtvar
Poznámka. Bližší informace o refaktoringu modelů lze nalézt např. v [1]. 2.2
Návrhové vzory
Návrhovým vzorem rozumíme předpis, které slouží k návrhům řešení stejného typu. Jinými slovy, návrhový vzor udává třídu návrhů řešení, a konkrétní návrh řešení je potom instancí této třídy. Z výše uvedeného vyplývá velká výhoda aplikace návrhových vzorů, a sice úspora času. Opětovné použití návrhového vzoru na určité řešení je méně časově (a tím i finančně) náročné, než vymýšlet návrh takového řešení od základů. Podrobnější informace o jednotlivých návrhových vzorech a jejich klasifikaci najdete v [2]. Příklad 2. Význam návrhových vzorů si ukážeme na příkladě. Obr. 3 ukazuje návrhový vzor COMPOSITE a jeho použití.
178
Oldřich Nouza
P rv e k
+ + + +
přidejPotomk a() odstraňPotomk a() v raťPotomk a():Prv ek v elik ost():integer
0..*
S lo ž k a
+ + + +
přidejPotomk a() odstraňPotomk a() v raťPotomk a():Prv ek v elik ost():integer
S ou bo r
+ + + +
přidejPotomk a() odstraňPotomk a() v raťPotomk a():Prv ek v elik ost():integer
Obr. 3. Použití návrhového vzoru COMPOSITE
Jak je patrné z názvu vzoru a z obrázku, použijeme vzor pro návrh stromové struktury. V uvedeném případě se jedná o adresářovou stromovou strukturu. Rozlišujeme dva druhy prvků stromu – uzly (tj. ty, které mohou obsahovat podřízené prvky neboli potomky, na obrázku třída Složka) a listy (tj. ty, které potomky obsahovat nemohou, na obrázku třída Soubor). Obě třídy implementují stejné rozhraní Prvek, které obsahuje metody pro práci s potomky, např. přidejPotomka(), odstraňPotomka(), vraťPotomka() apod., a navíc některé další metody, např. velikost() pro zjišťování objemu dat. Vztah kompozice mezi tímto rozhraním a třídou Složka říká, že instance třídy Složka může obsahovat libovolný počet instancí třídy implementující rozhraní Prvek (v tomto případě instancí tříd Složka a Soubor). Poznámka. Jelikož třída Soubor dědí metody pro práci s potomky z rozhraní Prvek a zároveň nemůže obsahovat potomky (jelikož se jedná o list stromu), je nutné implementovat tyto metody ve třídě Soubor tak, aby byl při jejich volání nějakým způsobem nastaven chybový stav (např. vyvoláním výjimky). Opětovné použití návrhového vzoru COMPOSITE je možné například pro znázornění organizace tříd v jazyce Java do balíčků. V tomto případě budou uzly stromu představovat balíčky, zatímco listy budou reprezentovat třídy. 2.3
Objektová normalizace
Objektová normalizace se týká objektově orientovaných datových modelů, tedy nikoliv objektového aplikačního modelu. Definuje několik stupňů normálních forem a
Formální pohled na vztah mezi refaktoringem, návrhovými vzory. . .
179
podmínky, která musí objektový datový model splňovat, aby byl v normální formě daného stupně. Existuje řada přístupů k objektové normalizaci, z nichž některé lze najít v [3], kde je rovněž podrobněji diskutováno téma objektové datové modely. Pro účely tohoto příspěvku použijeme přístup autora [3], který definuje tři stupně normální formy objektového datového schématu následovně: Definice 1. Třída je v první objektové normální formě (1ONF), jestliže její objekty neobsahují skupinu opakujících se atributů. Schéma je v 1ONF, jestliže všechny třídy objektů v něm jsou v ONF. Definice 2. Třída je ve druhé objektové normální formě (2ONF), jestliže je v 1ONF a její objekty neobsahují atribut nebo skupinu atributů, které by byly sdílené nějakým jiným objektem. Schéma je v 2ONF, jestliže všechny třídy objektů v něm jsou v 2ONF. Definice 3. Třída je ve třetí objektové normální formě (3ONF), jestliže je v 2ONF a její objekty neobsahují atribut nebo skupinu atributů, které mají samostatný význam nezávislý na objektu, ve kterém jsou obsaženy. Schéma je v 3ONF, jestliže všechny třídy v něm jsou v 3ONF. Poznámka. Pod pojmem atribut v uvedených definicích rozumíme jak datovou složku tak metodu, přesněji řečeno výsledek zpracování dat pomocí metody. Toto souhrnné označení umožní jednodušší formulaci definic bez újmy na obecnosti. Atributem třídy budeme rozumět atributy jejích instancí. Příklad 3. Na obr. 4 - 7 jsou postupně znázorněny objektové datové modely postupně v 0NF (tzn. že není v žádné normální formě), 1NF, 2NF a 3NF. Tyto modely byly převzaty z [3], kde jsou rozebrány podrobněji. O b je dn á v k a
D od á v k a
jménoDodav atele příjmeníDodav atele adresaDodav atele jménoKlienta příjmeníKlienta adresaKlienta datumObjednáv k y způsobPlatby název Prv níhoProduk tu c enaPrv níhoProduk tu název DruhéhoProduk tu c enaDruhéhoProduk tu název TřetíhoProduk tu c enaT řetíhoProduk tu
jménoDodav atele příjmeníDodav atele adresaDodav atele jménoKlienta příjmeníKlienta adresaKlienta datumDodáv k y způsobPlatby název Prv níhoProduk tu c enaDruhéhoProduk tu název DruhéhoProduk tu c enaPrv níhoProduk tu název TřetíhoProduk tu c enaT řetíhoProduk tu
Obr. 4. – Objektový datový model v žádné normální formě
180
Oldřich Nouza
O b je dn á v k a jménoDodav atele příjmeníDodav atele adresaDodav atele jménoKlienta příjmeníKlienta adresaKlienta datumObjednáv k y způsobPlatby
P ro du k ty
produkty 0..*
název c ena
1..*
D o dá v k a jménoDodav atele příjmeníDodav atele adresaDodav atele jménoKlienta příjmeníKlienta adresaKlienta datumObjednáv k y způsobPlatby
1..*
produkty
0..*
Obr. 5. – Objektový datový model v první normální formě
Kontra k t
P roduk t
O b je dná v k a jménoDodav atele příjmeníDodav atele adresaDodav atele jménoKlienta příjmeníKlienta adresaKlienta
detail 1
datumObjednáv k y 1
produkty 0..*
název c ena 1..*
1..* D odá v k a 1
detail
produkty
datumDodáv k y 1
0..*
Obr. 6. – Objektový datový model v druhé normální formě
Formální pohled na vztah mezi refaktoringem, návrhovými vzory. . .
Ko ntra k t
detail 1
0..*
P ro du k t
O b je d ná v k a
způsobPlatby
0..*
datumObjednáv k y
produkty 0..*
1
181
název c ena 1
1
1 D od á v k a
detail
0..*
1
klient
produkty
datumDodáv k y
Adre sa
O sob a 1
dodavatel
jméno příjmení
adresa 0..*
1
ulic e č .p. PSČ
1
Obr. 7. – Objektový datový model ve třetí normální formě
3
Sjednocení pohledu na refaktoring, návrhové vzory a objektovou normalizaci
V minulé kapitole jsme stručně vysvětlili pojmy refaktoring, návrhový vzor a objektová normalizace. Následující řádky nastíní univerzální způsob, jakým lze na ně nahlížet. 3.1
Refaktoring jako složení elementárních transformací
Vraťme se k výše uvedenému příkladu refaktoringu modelu grafického prohlížeče. Jedná se o transformaci modelu, které docílíme provedením následující posloupnosti dílčích transformací: 1. Přidání nové abstraktní třídy GeometrickýÚtvar do modelu. 2. Přidání vazby dědičnosti mezi třídu GeometrickýÚtvar a každou ze tříd Kružnice a Obdélník (stanovení třídy GeometrickýÚtvar společným předkem tříd Kružnice a Obdélník). 3. Přesun společného atributu barva ze tříd Kružnice a Obdélník do třídy GeometrickýÚtvar. 4. Přidání společné metody nakresli() tříd Kružnice a Obdélník do třídy GeometrickýÚtvar jako abstraktní metody. 5. Sloučení agregačních vazeb mezi třídami Plátno a Kružnice a třídami Plátno a Obdélník do jedné agregační vazby mezi třídami Plátno a GeometrickýÚtvar.
182
Oldřich Nouza
Poznámka. Sekvence takovýchto transformací zajisté vede k výsledku refaktoringu, jaký je znázorněn na obr. 2. Z obecného hlediska je však otázkou, zda je provedení elementární transformace možné, a zda se jím neporuší podmínka, že chování systému musí zůstat nezměněno. 3.2
Použití návrhového vzoru jako refaktoring
Aplikaci návrhového vzoru na řešení daného problému lze chápat dvěma způsoby: 1. Na počátku máme prázdný model. V každém kroku přidáme do modelu jeden prvek (např. třídu, vazbu apod.), s tím, že pokaždé dbáme na to, aby výsledek nebyl v rozporu s pravidly návrhového vzoru. 2. Nejdříve vytvoříme model, který pravidlům návrhovému vzoru neodpovídá, ale je alternativním řešením daného problému. Jedná se tedy o jakýsi stavební kámen pro použití návrhového vzoru. Ve druhé fázi provedeme transformaci modelu do podoby, která již pravidlům návrhového vzoru odpovídá. Příklad 4. Porozumění bodu 2 bude snazší, ukážeme-li jej na příkladě. Dejme tomu, že chceme použít návrhový vzor COMPOSITE na návrh stromu adresářů a souborů. Vyjdeme z modelu na obr. 8, který návrhovému vzoru COMPOSITE neodpovídá, avšak vystihuje stromovou strukturu adresářů a souborů stejně, jako obr. 2.
0..* S lo ž k a
+ + + + + + +
přidejPodsložk u() odstraňPodsložk u() v raťPodsložk u():Složk a odstraňSoubor() přidejSoubor() v raťSoubor():Soubor v elik ost():integer
S ou bo r
0..*
+ v elik ost():integer
Obr. 8. – Model stromové struktury souborů a složek bez použití návrhového vzoru
Nyní provedeme následující kroky: 1. Přidání rozhraní Prvek do modelu. 2. Přidání do modelu vazby generalizace znázorňující skutečnost, že třídy Složka a Soubor implementují rozhraní Prvek. 3. Sloučení obou agregačních vazeb mezi směřujících od tříd Soubor a Složka do třídy Složka v jednu agregační vazbu, která bude směřovat od rozhraní Prvek. do třídy Složka. To obnáší rovněž následující: • Sloučení metod přidejPodsložku() a přidejSoubor() do metody přidejPotomka().
Formální pohled na vztah mezi refaktoringem, návrhovými vzory. . .
183
•
4. 5.
Sloučení metod odstraňPodsložku() a odstraňSoubor() do meody odstraňPotomka(). • Sloučení metod vraťPodsložku() a vraťSoubor() do meody vraťPotomka(). Přidání metody přidejPotomka(), odstraňPotomka() a vraťPotomka() do třídy Soubor. Přidání metod přidejPotomka(), odstraňPotomka(), vraťPotomka() a velikost() do rozhraní Prvek.
Výsledný model po provedení všech kroků transformace je znázorněn na obr. 2. Poznámka. Podobně jako v případě refaktoringu, i zde je nutno si při každém kroku klást otázku: Bude model po provedení tohoto kroku vystihovat řešení původního problému? Uvažujeme-li použití návrhového vzoru jako transformaci alternativního návrhu, dojdeme k závěru, že na aplikaci návrhového vzoru lze nahlížet jako na refaktoring. Avšak ne ke každému refaktoringu lze nalézt odpovídající použití návrhového vzoru. 3.3
Objektová normalizace jako refaktoring
V souvislosti s objektovou normalizací se nabízí otázka: Je-li objektový datový model v normální formě určitého stupně (včetně 0NF a kromě 3NF), jak tento model transformovat, aby byl v normální formě o stupeň vyšší? Vraťme se k příkladu 3. Přechod od 0NF do 1NF modelu vyžaduje vyčlenění opakujících se atributů do nové třídy a skupinu těchto atributů nahradit vazbou do této nové třídy, což obnáší následující kroky: 1. Přidání nové třídy Produkt do modelu. 2. Přidání asociačních vazeb mezi třídami Objednávka a Produkt a třídami Dodávka a Produkt. 3. Přesunutí opakujících se atributů název a cena ze tříd Objednávka a Dodávka do třídy Produkt. Pro přechod modelu od 1NF k 2NF je nutné zajistit, aby sdílené atributy či skupiny atributů byly vyčleněny do nové třídy, a ze všech tříd, kde se vyskytovaly, přidat asociační vazbu do této nové třídy. Postup krok za krokem je následující: 1. Přidání nové třídy Kontrakt do modelu. 2. Přidání asociačních vazeb 1:1 mezi třídy Kontrakt a Objednávka a třídy Kontrakt a Dodávka. 3. Přesunutí sdílených atributů do týkajících se dodavatele a klienta ze tříd Dodávka a Objednávka do třídy Kontrakt. Zbývá ukázat možnosti transformace 2NF modelu do 3NF modelu. Toto obnáší vyčlenění atributu či skupiny atributů se samostatným významem nezávislým na objektu do nové třídy. Z každé třídy, kde se takový atribut či skupina atributů
184
Oldřich Nouza
vyskytovaly, je nutné přidat asociační vazbu do nově vytvořené třídy. V uvedeném příkladě to znamená následující: 1. Přidání nové třídy Osoba do modelu. 2. Přidání dvou asociačních vazeb klient a dodavatel mezi třídami Kontrakt a Osoba (dvě vazby je nutné přidat proto, že atributy jméno, příjmení, ulice, č.p. a PSČ se ve třídě Kontrakt vyskytují dvakrát, jednou pro klienta a jednou pro dodavatele). 3. Přesunutí atributů jméno, příjmení, ulice, č.p. a PSČ ze třídy Kontrakt do třídy Osoba. 4. Kroky 1-3 provedeme pro vyčlenění atributů ulice, č.p. a PSČ ze třídy Osoba do třídy Adresa. Poznámka. Kromě otázky, zda je možno daný krok transformace provést a případně zda toto provedení nezmění smysl objektového datového modelu, se nabízí další: • Jak rozpoznat u transformace 0NF na 1NF modelu opakující se atribut či jejich skupinu? • Jak rozpoznat u transformace 2NF na 3NF, že určitá skupina atributů má samostatný význam? Transformaci modelu do vyššího stupně normální formy lze rozdělit na posloupnost elementárních transformací. Jedná se tedy o zvláštní případ refaktoringu. 3.4
Jednotnost pohledu
Z výše uvedených poznatků vyplývá, že na použití návrhového vzoru a objektovou normalizaci lze pohlížet jako na refaktoring, avšak refaktoring nemusí vždy znamenat použití návrhového vzoru či normalizaci objektů. Tato myšlenka je znázorněn na obr. 9.
Refaktoring Použití návrhového vzoru
Normalizace objektů
Obr. 9. – Vztah mezi refaktoringem, použitím návrhového vzoru a normalizací objektů
Formální pohled na vztah mezi refaktoringem, návrhovými vzory. . .
185
Poznámka: Není známo, že by některé případy normalizace objektů byly zároveň i použitím návrhového vzoru či naopak. Z tohoto důvodu jsme příslušné množiny ve výše uvedeném obrázku nakreslili disjunktní.
4
Formalizace transformací
Aby nedošlo k nedorozumění, transformací budeme dále rozumět refaktoring, použití návrhového vzoru nebo normalizaci objektů. 4.1
Transformační kalkul
Nejprve je potřeba definovat kalkul, který umožní formálně popsat jednotlivé transformace. Budeme jej nazývat transformační kalkul. Vychází z kalkulu predikátové logiky a je doplněn o prvky, jejichž význam je uveden v tabulce 1. Tabulka 1. – Rozšíření predikátového kalkulu o nové prvky transformačního kalkulu
Prvek kalkulu T (vstup, stav před, stav po)
C A M A(c) M(c) .name $ α(c1, c2) σ(c) ι(c) E≈F Ω(E) ϖ(E)
Význam Zápis transformace. Transformaci chápeme jako uspořádanou trojici (vstup, stav před, stav po). Vstup je množina elementů, které do transformace vstupují. Stav před je množina podmínek, které jsou splněny před transformací, a stav po je množina podmínek, které jsou splněny po transformaci. Množina všech tříd v daném modelu. Množina všech atributů všech tříd v daném modelu. Množina všech metod všech tříd v daném modelu. Množina všech atributů ve třídě c. Množina všech metod ve třídě c. Název třídy, atributu či metody. Označení parametru transformace. Třída c1 je v asociaci se třídou c2. Předek třídy c. Množina všech rozhraní, která implementuje třída c. E a F jsou opakující se skupiny atributů, ve smyslu definice 1. Množina obsahující všechny neopakující se atributy ze skupiny atributů E. Význam skupiny atributů E ve smyslu definice 3. Je-li význam jednotlivých atributů v této skupině různý, pak význam skupiny atributů není definován.
186
4.2
Oldřich Nouza
Přehled transformací vyjádřených pomocí transformačního kalkulu
Nyní můžeme přistoupit k vyjádření transformací pomocí výše uvedeného transformačního kalkulu. V tabulce 2. jsou uvedeny základní transformace a jejich formální zápis. Tabulka 2. – Formální popis transformací
Transformace Přejmenování třídy Přejmenování atributu Přejmenování metody Vyčlenění atributů a metod do samostatné třídy Přesunutí atributu do předka Přesunutí metody do předka Přesunutí atributu do potomků Přesunutí metody do potomků Vyčlenění metody do rozhraní Transformace třídy z 0NF do 1NF Transformace třídy z 1NF do 2NF Transformace třídy z 2NF do 3NF
Formální vyjádření T({c.name, $newName}, {c∈C}, {c.name=$newName }) T ({a, $newName}, {a∈A}, {a.name=$newName}) T ({m, $newName}, {m∈M}, {m.name=$newName}) T ({c1, c2, E}, {c1∈C, c2∉C, E⊂A(c1) ∪A(c1)}, {c2∈C, E=A(c2) ∪A(c2), ∃!a∈α(c1, c2)}) T ({c, a}, {c∈C, a∈A(c)}, {a∈A(σ(c))}) T ({c, m}, {c∈C, m∈M(c)}, {m∈M(σ(c))}) T ({c1, a}, {c1∈C, a∈A(c1)}, {a∈A(c2) ∀c2|c1= σ(c2)}) T ({c1, m}, {c1∈C, m∈M(c1)}, {m∈M(c2) ∀c2|c1= σ(c2)}) T ({c, m, i}, {c∈C, m∈M(c)}, {m∈M(i), i∈ι(c)}) T ({c1}, {c1∈C; ∃E⊂A(c1) ∀F,G ⊂(A(c1)-E) non(F≈G)}, {E⊄A(c1), c2∈C; Ω(E)=A(c2), ∃!a∈α(c1, c2)}) T ({c1}, {c1∈C; ∃E⊂A(c1) ∀c2 ⊂(C-{c1}) E⊂A(c2)}, {E⊄A(c1), c3∈C; E=A(c2), ∃!a∈α(c1, c3)}) T ({c0}, {c0∈C; ∃!{E1,…,En | Ei⊂A(c0)∀i et ϖ(Ei) ≠ϖ(Ej)≠ϖ(A(c0)-(E1∪…∪En))∀i,j }}, {Ei⊄A(c0)∀i, Ei=A(ci)∀i, ∃!ai∈α(c0, ci)∀i})
Poznámka. V tabulce 2 nejsou uvedeny speciální transformace popisující použití jednotlivých návrhových vzorů. Vzhledem k jejich rozsáhlosti by formální zápisy a jejich nezbytné vysvětlení vydaly na další samostatný článek.
5
Závěr
Výše uvedené odstavce nastínily souvislosti mezi refaktoringem, návrhovými vzory a normalizací objektů. Došli jsme k závěru, že refaktoring je v podstatě vlastní nadmnožinou normalizace objektů a použití návrhových vzorů. Formální vyjádření transformací při refaktoringu může pomoci při jeho implementaci ve vývojových nástrojích, avšak nejspíš nebude možné jej plně automatizovat. Například při
Formální pohled na vztah mezi refaktoringem, návrhovými vzory. . .
187
normalizaci objektů do 3NF nelze vždy algoritmicky vyřešit, které atributy mají „samostatný význam nezávislý na objektu“. Důležitější otázkou však je, jakým způsobem ve vývojových nástrojích implementovat interpretaci zmíněného transformačního kalkulu. Hledání odpovědi je předmětem stávajícího výzkumu.
Poděkování Tento příspěvek byl vytvořen za podpory grantu MŠMT 1P04LA211.
Reference 1. Sunyé G. –Pollet D. – Le Traon Y. – Jézéquel J. M. Refactoring UML Models. http://www.irisa.fr/triskell/publis/2001/Sunye01b.pdf 2. Kraval I. Design Patterns v OOP se zaměřením na JAVU, C# a Delphi. Elektronická publikace, 2002 3. Merunka V. Normalizace v objektových databázích. Sborník konference OBJEKTY 2004. Praha 2004. 4. Carda A. – Merunka V. – Polák J. Umění systémového návrhu – Tvorba informačních systémů pomocí původní metody BORM. Grada Praha, 2000, ISBN 80-247-0424-2 5. Garcia L. R: – Merunka V. – Polák J. BORM – Business and Object Relation Modelling. In: Proceedings of WOON – 6th international conference on object technology Institute of Electrotechnology, St. Petersburg, 2001, ISBN 80-88786-8 6. Merunka, V. Modelování podle metody BORM pomocí nástroje Craft.CASE. Sborní konference Objekty 2005 7. Booch, G. – Rumbaugh, J. – Jacobson, I. The Unified Modelling Language User Guide. Addison-Wesley, 1999. 8. Booch, G. – Rumbaugh, J. – Jacobson, I. The Unified Modelling Language Reference Manual. Addison-Wesley, 1999. 9. Fowler, M. – Scott, K. UML Distilled. Addison-Wesley, 2000.
Objektové principy a SQL databáze Objektové principy a SQL databáze Helena Palovská11,2 Helena Palovská [email protected] 1
1 Katedra systémovéanalýzy, analýzy, VŠE VŠE Praha, 4, 130 00, Praha 3, Katedra systémové Praha,W. W.Churchilla Churchilla 4, 130 00, Praha 3 Katedra informatiky, VŠFS o.p.s., Estonská 500, 101 00, Praha 10 2 Katedra informatiky, VŠFS o.p.s., Estonská 500, 101 00, Praha 10 [email protected]
Abstrakt. Databázový přístup je založen na základní myšlence: aplikace jsou odděleny od správy dat, spravovaná data jsou sdílena. Každý datový objekt mívá svou zodpovědnou osobu, ale přísné zapouzdření objektů brání efektivnímu programování aplikací požadujících výběr dat. Manipulace s daty jsou na druhou stranu bezpečnější, pokud jsou prováděny pomocí zapouzdřených metod objektů. Návrh SQL databáze proto musí respektovat dvojí požadavky: zaprvé napomáhat efektivnímu vyhledávání dat, zadruhé nabízet interface v řeči objektů odrážejících reálné objekty aplikační domény. Tento článek předkládá některé myšlenky vhodné pro výuku informatiků v této problematice. Klíčová slova: objekty, návrh SQL databáze, výuka
1
Úvod
Studenti informatiky jsou konfrontováni s nekonzistencí mezi objektovým paradigmatem tvorby aplikací a idejemi pro návrh a užití SQL databází. Tato nekonzistence je principielní. Myšlenka dělby zodpovědností a zapouzdření služeb je v konfliktu s potřebou znát a používat efektivní způsob práce s databázovým strojem, rozumět mechanismům jeho fungování. Z hlediska databázového přístupu by bylo možné vidět databázi jako jediný objekt, nabízející své služby. Jenže těchto služeb není malá omezená množina, ale jsou jimi potenciálně všechny SQL příkazy. Specielně možných SQL SELECTů nad konkrétní databázovou strukturou je příliš mnoho na to, aby byly jednotlivě nabízeny jako služby. Samozřejmě je běžnou praxí to, že typové SELECTy navrhují zkušení databázoví programátoři, a pro ostatní jsou tyto zapouzdřeny do uložených procedur. Nicméně potřeba na ad-hoc dotazování tuto architekturu nabourává. V následující kapitole jsou shrnuty základní principy efektivního vyžití databázového stroje. Specielně jsou vyjmenována pravidla pro správný návrh databázové struktury z tohoto hlediska. Směrem k usnadnění objektově orientované tvorby aplikací přistupujících k SQL databázím je možno udělat některé kroky, zmíněné v kapitole další.
c Václav Snášel, editor: Objekty 2005, pp. 188–192, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Objektové principy a SQL databáze
2
189
Efektivní využití databázového stroje
SQL databázové stroje byly optimalizovány hlavně v 80. letech, většina principů je dnes obecně známa. Zde je výčet těch základních: • Databázový stroj je optimalizován pro efektivní vyhledávání záznamů podle hodnot v polích, nikoli podle jejich částí či podle výrazů, až na výjimky. - Výjimkou jsou začátky hodnot textových polí a některé SQL funkce, například YEAR, MONTH, DAY. • Urychlení vyhledávání se provozuje pomocí indexů, ty jsou navrhovány pro konkrétní pole či jejich kombinace. - U specifických datových typů je nabízena možnost indexovat podle částí nebo funkcí. • Vyhledávání podle hodnoty v poli, jež není indexováno, vyžaduje scan celé tabulky, jehož trvání je přímo úměrné délce záznamů a jejich počtu. • Nejnáročnější operací je JOIN, k jehož urychlení je možno udržovat indexy pro spojovací pole, či denormalizovat – tedy vlastně se JOINu vyhnout. • SELECTy a aktualizace jsou vzájemně konfliktní. - Operace UPDATE a DELETE vyžadují uzamčení alespoň nejmenší množiny fyzických bloků, obsahujících měněná data. - Operace INSERT nejméně zatěžuje provoz, její konflikt se SELECT je možno dobře řešit. 2.1
Důsledky pro návrh databáze
Vše, co bude samostatně vyhledáváno či porovnáváno, navrhněte jako pole nebo množinu polí. Jinými slovy, nalezněte atomy vyhledávání či porovnávání, a ty navrhněte jako samostatná pole. K některým funkcím nad určitými datovými typy lze přistupovat stejně, jako by jimi vracené hodnoty byly samostatnými poli tabulky. Odlišujte „historická“ data, která po uložení zůstávají nadále beze změny, a „aktuální“ data, jež jsou měněna podle aktuálního stavu světa. U historických dat je možno zvážit jejich archivy či „sklady“, redundantní uložení sloužící výhradně k SELECTům. Také je u nich možno zvážit denormalizaci. Je třeba zvážit i dynamický návrh, vhodně oddělit historická data od aktuálních kvůli aktualizacím a nutností uzamykat odpovídající logické celky databázové struktury. Vícehodnotové atributy objektů je nejlépe ukládat do samostatné tabulky se vztahem n:1 k tabulce ukládající objekty. Složené atributy je nejlépe ukládat ve složkách, pro každou složku samostatné pole. Je možno zvážit ukládání odvozených hodnot, pokud jsou často požadovány.
3
Objektové přístupy v návrhu databáze
Při návrhu databáze můžeme potřeby objektového přístupu zohlednit třemi způsoby: důsledně podporovat objektovou identitu, používat moderní logické struktury pro
190
Helena Palovská
ukládání komplexních objektů a navrhnout a nabízet metody pro přístup k objektům a pro manipulaci s datovými objekty. 3.1
Objektová identita, reference
Objekty lze do SQL databází ukládat jako řádky tabulek, a mohou mít objektovou identitu. Objektový identifikátor tak může sloužit místo primárního klíče, což má mnoho výhod: Nehrozí, že by někdo omylem změnil hodnotu tohoto identifikátoru za života objektu-řádku tabulky. Toto však lze bohužel obejít, jestliže je smazán řádek a pak založen nový řádek se stejnými hodnotami atributů (a stejným významem řádku). Zajišťování jedinečnosti objektových identifikátorů je prováděno databázovým strojem efektivněji, než u „klasických“ primárních klíčů. Sémantické klíče objektů z aplikační oblasti mohou být nadále udržovány jako UNIQUE. Sémantické klíče jsou důležité, protože pomocí nich lidé vyhledávají záznamy. Vztahy mezi objekty zaznamenávané v relačním modelu prostřednictvím cizích klíčů mohou být zachycovány objektovými referencemi. Výhody jsou následující: Při moudrém návrhu konstruktorů event. destruktorů není v mnoha případech třeba hlídat referenční integritu. V ostatních případech stačí vhodný návrh metod pro aktualizaci odkazů. Hodnota referencí se zadává jako odkaz na konkrétní objektový řádek, což výrazně snižuje riziko chyby. Indexy pro realizaci vazeb mezi nadřízenými a podřízenými řádky (vazby 1:n) jsou při použití objektových identifikátorů velmi efektivní. Při použití konstruktu SET by bylo možno přirozeně realizovat i vazby n:m, tento konstrukt však zatím není v SQL databázích podporován. 3.2
Abstraktní datové typy, zahnízděné tabulky, strukturované hodnoty
V moderních SQL databázích je nabízena značná podpora pro návrh složité logické struktury objektových záznamů. Ta sahá od možnosti definovat různé datové typy pro daný aplikační kontext až k možnostem vytvářet složité logické struktury v organizaci databáze. Abstraktní datové typy a tzv. odlišující typy slouží k respektování aplikační sémantiky a k ochraně před lidskými chybami silným typováním. Konstrukce strukturovaných atributů a zahnízděných tabulek umožňují odrážet realitu složitých struktur objektů. 3.3
Metody
K zapouzdření manipulací s objektovými záznamy nabízejí SQL databáze možnost definovat metody příslušné jednotlivým řádkovým (tj. objektovým) typům i sloupcovým typům.
Objektové principy a SQL databáze
191
Důsledné užívání těchto metod může zajistit větší bezpečnost dat, na druhou stranu možnost manipulovat s daty přímo tuto výhodu narušuje. Nedat práva k přímým manipulacím je řešením v případě, že nemusíme udržovat funkčnost „legacy“ aplikací. Protože SQL databáze umožňují používat typovou hierarchii v definici dat, v aplikacích je možno využívat i polymorfismu.
4
Požadavky na manipulace s daty
Pro aplikačního programátora je ideální následující přístup. K manipulací s daty používá metody, vytvořené designérem databáze. V ideálním případě ani jinou možnost nemá. K požadavkům na výběr dat buď používá předdefinované SELECTy v uložených procedurách, nebo zadává SELECT příkaz sám a přitom respektuje mj. doporučení zmíněná v tomto článku v kapitole 2 k podpoře efektivity zpracování požadavku, a také se řídí zkušenostmi a znalostmi o konkrétním databázovém stroji a o tom, jak efektivně které formulace stejného požadavku zpracovává.
5
Závěr
Moderní SQL databáze nabízejí podporu objektových přístupů, bohužel však nabízejí také „staré“ možnosti práce s daty, takže designéři a programátoři nejsou vedeni ke správným postupům a volbám. Tento článek má ozřejmit jaká je cesta k objektovému návrhu SQL databáze a k objektovému přístupu při realizaci požadavků na data v aplikacích.
Reference 1. ORACLE. http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10743/objects.htm#i431766, Object Datatypes and Object Views. 2. Pokorný J. Objektově relační databáze. Objekty ’1999. Česká zemědělská univerzita Praha. 80-213-0552-54 3. Pokorný J. Objektově relační databáze. Datakon 2002. Masarykova universita v Brně. 80-210-2958-7. 4. Stonebraker M., Brown P. Objektově relační SŘBD, analýza příští velké vlny. Softwarové aplikace a systémy, BEN - technická literatura, Praha 2000. 80-8605694-5 (BEN-technická literatura, Praha) 80-901-5074-8 (Softwarové aplikace a systémy, Praha).
192
Helena Palovská
Annotation Object principles applicable in SQL databases are presented. Database approach is discussed with respect to encapsulation and responsibility division. Advices for teaching of informatics are proposed.
Nástroje modelování Nástrojeprocesního procesního modelování Martin Papík1 Martin Papík
Katedrainformačního informačníhoinženýrství, inženýrství,PEF, PEF, ČZU ČZU Praha Praha
Abstrakt. Cílem této práce je představit možnosti metody a nástroje pro procesní modelování a uvést je do vzájemné souvislosti. Konkrétně se budeme zabývat metodou BORM. Jde o objektově-orientovanou metodu pro modelování podnikových (business) procesů. Druhý nástroj pak bude představovat matematicko-grafický aparát Petriho sítí, kterého se využívá již řadu let pro analýzu a modelování různých systémů diskrétních událostí. Přínos spočívá zejména v nalezení podobných a silných stránek obou těchto prostředků. Charakteristické vlastnosti těchto dvou prostředků budou prezentovány na vlastních praktických příkladech. Dále pokus o vytvoření možnosti zatím neexistující transformace mezi BORMem a Petriho sítěmi. Pro korektnost uvádím, že tato práce přímo navazuje na mojí diplomovou práci. Klíčová slova: BORM (Business object relation modeling), Petriho sítě, Proces, Informační systém, Transformace, Metamodel
1
Metoda BORM
BORM stojí na určitých hlavních přístupech, jimiž jsou : Proces (Business process), každý produkt či služba vyprodukovaná podnikem (organizací) je výstupem (výsledkem) určitého konkrétního procesu (činnosti). Na procesy můžeme aplikovat řadu norem (např. ISO 9001:2000), které upravují a definují jakost (kvalitu) procesů na základě systémového procesního modelu. Podnik při správné aplikaci těchto norem zvyšuje svou konkurenceschopnost na daném trhu díky snížení potřebného času potřebného k dosažení daného cíle, snížením nákladů, zvýšením spolehlivosti, zjednodušením (zprůhledněním) operací atd. Objekt, slouží k popisu jak vnitřních procesů a přechodů mezi jednotlivými stavy, tak i k popisu vnějších procesů, kde je objekt také účastníkem. Vlastnosti objektu se mohou v čase měnit, proto se v BORMu pohled na objekt mění podle fáze projektování. Budeme rozlišovat objekty směrem od reálného světa k objektům použitým ve funkčním informačním systému (pojem informační systém chápejme jako lidi - uživatele + hardware + software) na : • Business objetky (Business objects, BO), jsou objekty reálného světa (např. faktura, úředník atd.). Tyto objekty jsou východiskem k analýze a popisu zadání projektu. Právě zde je hlavní prostor pro použití procesního modelování a tedy i BORMu.
c Václav Snášel, editor: Objekty 2005, pp. 193–208, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
194
Martin Papík
•
•
2
Konceptuální objekty (Conceptual objects, CO), odvozují se z BO a používají k prvnímu popisu podoby modelu softwaru. Řešíme zde strukturu tříd, instancí či množin. Nejsme zde zatíženi konkrétní softwarovou implementací . Právě zde se může nejlépe uplatnit UML (Unified modeling language), model v UML se skládá z různých diagramů, jež představují pohledy na různé části navrhovaného systému (aplikace, softwaru). Softwarové objekty (Software objects, SO), odvozují se z CO a na rozdíl od CO popisují konkrétní softwarovou implementaci, zohledňují tedy určitá omezení konkrétních vývojových prostředí (programovacích jazyků).
Procesní diagram BORMu
Procesní diagram se skládá z pěti základních pojmů a jejich symbolů, těmi jsou : 1.
Participant, hlavní pojem diagramu. Reprezentuje nějakou konkrétní jednotku z modelované reality (např.: úředníka, aplikaci, apod.). Je to v podstatě, objekt který se účastní nějakého procesu. Symbol :
2.
Jméno participanta (s velkým písmenem)
Aktivita, chování (aktivita) vždy náleží nějakému participantu. V procesním diagramu se pomocí aktivit provádí přechody mezi stavy. Symbol: Název aktivity
3.
Komunikace mezi participanty, má dva body : •
komunikace, představuje propojení/návaznost aktivit jednotlivých participantů na sebe. Komunikace vždy vychází od jedné aktivity participanta, který zahajuje komunikaci a vede k jedné aktivitě (jiného) participanta, který přijímá komunikaci. Je to v podstatě abstrakce zpráv mezi objekty. Symbol:
Nástroje procesního modelování
•
195
parametry komunikace, jsou data, která mohou být součástí komunikace (např.: důvod zamítnutí, žádost, faktura, materiál apod.). Parametry proti směru komunikace představují odpovědi od aktivity, které byla komunikací vyvolána. Symbol:
4.
Stavy a přechody participanta (role), stejný participant se může v průběhu procesu měnit (na základě chování – aktivit). Některé z aktivit (činností), které participant provádí v jednom stavu, mohou způsobit přechod od jednoho stavu tohoto participanta k druhému stavu téhož participanta. Vzájemně související stavy a přechody jednoho participanta tvoří jeho roli v systému. V podstatě se jedná o automat v čase, tj. po přijetí informace může automat přejít do následujícího stavu. Takže v procesech se na objekty dá nahlížet jako na automaty, které v různých stavech mohou provádět různé aktivity [5].
5.
Symboly: začátek role:
konec role:
přechody:
stav:
Název stavu
Podmínky - v případě potřeby je možné znázornit u komunikací a přechodů podmínky, které blíže vymezují pravidla za jakých komunikace nebo přechod bude proveden(a) (např.: pravda x nepravda, ano x ne, apod.). Symbol:
3
IS PneuServis – vlastní praktický příklad metody BORM
Stručná charakteristika zadání je následující: Systém je určen pro registraci zákazníků pneuservisu, dále pak pro příjem, objednání a předběžnou kalkulaci zakázek pneuservisu. Základem je databáze zákazníků a k nim přiřazeným vozům na základě ID_Zákazníka a SPZ automobilu. Uživatel má možnost přidat, odebrat, vyhledávat a aktualizovat záznamy zákazníků, případně je totéž schopen provádět u tabulky automobilů a služeb v záznamu daného zákazníka. Zadání zakázky (objednávky) probíhá tak, že se k dané SPZ přiřadí termín výměny (datum) pneumatik a případně
196
Martin Papík
předběžná cena za provedenou službu. Hlavní funkcí programu (systému) je uchování si komplexních informací o zákaznících a jejich automobilech a poskytovaných službách. Výsledkem interview (rozhovoru) by měl být vždy seznam požadovaných funkcí aplikace (systému). Seznam má šest následujících funkcí (report CASE nástroje MetaEdit+) : Required System Functions Required System Function No. 0 Autorizace uzivatele Required System Function No. 1 Editace zakazniku Required System Function No. 2 Editace aut Required System Function No. 3 Editace sluzeb Required System Function No. 4 Vyhledani informace Required System Function No. 5 Ziskani potrebne informace/i V druhé fázi prvního kroku metody BORM pak definujeme scénáře, které se vždy přímo vážou nejméně na jednu funkci. System Scenarios
Scenario No.1 - realizes function(s): 0
continues in scenario No. 2 continues in scenario No. 3
intiation
participants result
Action
Uzivatel spousti IS Spuštěni IS PneuServis (Login) PneuServis a
Uzivatel modifikoval Pridej zaznam Smaz Uzivatel, potrebne zaznamy v IS zaznam Aktualizuj IS PneuServis, PneuServis zaznam DB PneuServis
Scenario No.4 - realizes function(s): 4
continues in scenario No. 2 continues in scenario No. 3
intiation
action
participants
Uzivatel potrebuje vyhledat zaznam
Vyhledal pozadovany Hledej Uzivatel, IS PneuServis, zaznam DB PneuServis
result
Vzhledem k tomu, že využíváme CASE nástroje můžeme si dovolit použít zrychlený postup a přejít k pátému kroku metody BORM. Tím je simulace scénářů (propojíme scénáře a každému scénáři přidělíme nejméně jednu funkci), jde tedy o následující diagram.
198
Martin Papík
Ke každému scénáři existuje právě jeden jemu odpovídající procesní diagram. Uvádíme jeden procesní diagram, který popisuje proces, kdy uživatel (zaměstnanec) spouští informační systém PneuServis.
Nástroje procesního modelování
199
Konečným výstupem by měl být funkční software, který se bude maximálně snažit uspokojit zákazníkem dříve definované potřeby. Tento software s názvem IS PneuServis byl tedy v závěru projektu vytvořen. Rozhodli jsme se pro integrované vývojové prostředí DELPHI 6 (firma Borland).
4
Formální matematická definice Petriho sítí
Uvádím základní matematickou definici Petriho sítě. Je do určité míry zjednodušující, protože se nijak nedotýká definicí značení, kapacity místa a nedefinuje ani váhu hrany v Petriho síti. Definice 1. [2] Uspořádanou trojici N = (P, T, F) nazýváme sítí, jestliže P a T jsou disjunktní množiny a F ⊆ (P x T) ∪ (T x P) je binární relace. P se nazývá množinou míst (Places) sítě N. T se nazývá množinou přechodů (Transitions) sítě N. F se nazývá tokovou relací (Flow relation) sítě N. Jak již bylo řečeno v úvodu, grafem sítě je orientovaný (případně ohodnocený) bipartitní graf . Ten vzniká právě grafovou reprezentací tokové relace F. Množinu tohoto grafu tvoří obě množiny P a T, tedy P ∪ T (viz. obr.č. 5).
Obr.č. 5 – Graf a popis sítě N
Další definice, se pak „opírají“ o definici č. 1, zavádí další pojmy jako vstupní / výstupní množina, cyklus, čistá síť a izolovaný prvek.
200
5
Martin Papík
Vlastní softwarová implementace Petriho sítě
Následující vlastní obrázek č. 2 představuje první pokus o vytvoření jednoduchého obecného metamodelu Petriho sítí, avšak pro zjednodušení ještě bez návaznosti na strukturu specifikace UML. Popíšeme si, co uvidíme. Na obrázku č. 2 je celkem sedm tříd. Třída Síť (Net) představuje nějakou konkrétní Petriho síť. Mezi třídou Sítˇ a třídami Místo (Place), Přechod (Transition) a Hrana (Arc) existuje vztah celek – část (kompozice), který znamená, že Síť nemůže existovat bez míst, přechodů a hran. Třída Značka (Token) má vztah s třídou Místo , jedná se o agregaci, která vyjadřuje, že značka může nebo nemusí být součástí místa v Petriho síti. Dále je zde asociativní vztah mezi třídou Hrana (Arc) a třídami Místo a Přechod, který obecně vyjadřuje, že místa a přechody v Petriho síti mají (have) hrany (resp. jsou jimi propojeny). Pro korektnost je na závěr naznačen vztah nadtyp – podtyp (generalizace) mezi třídou Hrana (nadtyp) a třídami Vstupní hrana (Input arc) a Výstupní Hrana (Output arc), přičemž vstupní hranou se myslí hrana jdoucí z míst do přechodů a výstupní hranou se myslí hrana jdoucí z přechodů do míst
Obr.č. 2 – Metamodel Petriho sítě
6
PNSim
Náš objektový model (softwarovou implementaci v jazyku Smalltalk) Petriho sítě (nazvali jsme ji PNSim) bude mít z reprezentačního hlediska jen textovou podobu. Především budeme požadovat schopnost provedení následujících funkcí :
Nástroje procesního modelování
• • • • •
201
Vytvoření množiny míst sítě N. Vytvoření množiny přechodů sítě N. Vytvoření tokových relací (binární relace – hrana) sítě N. Nastavení počátečního značení M0 (tj. umístění značek) sítě N. Simulace následného stavu (textový výstup) sítě N.
Pro korektnost uvádíme, že vydatným pomocníkem při vytváření PNSimu byl zdroj [3]. Nyní zde předvedeme konkrétní příklad použití PNSimu na dané Petriho síti. Příklad použití PNSimu: Vytvoření (definice) dané Petriho sítě. Následuje definice této sítě v prostředí Squeak (Workspace-textové okno).
Po spuštění pomocí příkazu print it obdržíme následující výstup (výsledek) :
Z výstupu je dobře patrné, že následující značení M1=(0, 1, 0). Další stav(y) této Petriho sítě bychom obdrželi opětovným voláním metody nextState. Tato implementace Petriho sítě je velice jednoduchá a vůbec neuvažuje kapacitu míst či váhu hran.
202
7
Martin Papík
Transformace procesního diagramu BORMu do Petriho sítě
Uvědomme si, že to na čem tento převod stojí, a to u obou modelovacích prostředků, je pojem proces (business proces). Proces si můžeme definovat jako seřazenou sadu nějakých činností, které jsou propojeny za účelem dosažení nějakého cíle (výstupu apod.). Při definici procesu se využívá několika obecných konstrukcí (struktur), jejichž analogii můžeme hledat například v programovacích technikách. Proto v této části budou rozebírány základní konstrukce používané pro grafický popis procesu pomocí Petriho sítí. Později tyto konstrukce využijeme při samotné transformaci. Petriho sítí můžeme vytvářet tyto konstrukce: 1.
Sekvence, jednotlivé činnosti na sebe lineárně navazují, sled činností existuje pouze jeden. V Petriho síti tomu odpovídá následující konstrukce :
2.
Paralelní směrování (AND-split), na jednu činnost navazují dvě či více činností, které pak probíhají současně. V Petriho síti tomu odpovídá následující konstrukce:
3.
Synchronizace (AND-join), dvě či více paralelně probíhajících činností mají vyústit do jediné činnosti. V Petriho síti tomu odpovídá následující konstrukce:
4.
Větvení (OR-split), existuje sice lineární sled činností, ale jako jeden z několika možných. Až v průběhu procesu se na základě podmínky
Nástroje procesního modelování
203
rozhodne, která činnost (větev) se provede. V Petriho síti tomu odpovídá následující konstrukce :
8
5.
Spojení (OR-join), dvě či více alternativních činností se může sbíhat do jedné. V Petriho síti tomu odpovídá následující konstrukce :
6.
Opakování (iterace), činnost probíhající opakovaně, dokud není splněna podmínka. V Petriho sítitomu odpovídá následující konstrukce :
Definice ekvivalentních struktur pro transformaci
Ještě předtím než uvedeme tabulku pravidel pro transformaci, musíme upozornit na skutečnost, že některé struktury (symboly, vrcholy) procesního diagramu BORMu nemají své rovnocenné protějšky v Petriho síti. Máme tím na mysli zejména následující : • Participant, Petriho síť představuje pouze jeden model, tj. jeden orientovaný graf, při transformaci pak budeme převádět jednotlivé participanty odděleně do Petriho sítí. Na jednoho participanta (pokud je jich v modelu více) se můžeme dívat z hlediska Petriho sítě jako na podproces. Nicméně Petriho sítě nedefinuje ani nedisponuje žádným symbolem, který je rovnocenný pro symbol participanta. • Počátek role, Petriho síť bere v úvahu pouze počáteční značení M0, což nám symbolizuje nějaký parciální (dílčí) stav modelu (sítě). Teoreticky každý stav může být počátečním stavem pokud nebereme v úvahu čas. • Konec role, konečný stav nám v Petriho síti bude symbolizovat nějaké značení Mi, což bude opět nějaký parciální (dílčí) stav modelu (sítě).
204
Martin Papík
Při vytváření tabulky pro převod jsme se přiklonili k názoru, že Petriho síť vzniklá převodem z procesního diagramu BORMu, by měla být schopna simulovat (modelovat) různé stavy systému, které v něm mohou nastat. To je důvod, proč jsme do pravidel pro převod nezařadili větvení (OR-split), protože pak by proběhla pouze jedna z alternativních (možných) činností (větví).
Tabulka - ekvivalentní struktury pro transformaci
Nástroje procesního modelování
9 1.
2.
3.
Vlastní praktický příklad transformace
205
206
Martin Papík
10 Ověření správnosti transformace Simulace Petriho sítě z předchozí kapitoly je následující :
Nástroje procesního modelování
207
Simulace začíná ve chvíli, kdy se uživatel rozhodne spustit IS PneuServis. Končí dvěma možnostmi buď je IS PneuServis spuštěn nebo není spuštěn, díky nesprávné autorizaci, to je dobře vidět z posledního kroku simulace. Od počátku simulace až do jejího konce nedošlo k uváznutí (deathlock), který by mohl být případně způsobem špatným návrhem sítě (nejsou splněny podmínky pro uvolnění a aktivaci nějakého přechodu). Simulace končí v místech P3 a P8, což vede na stav (m6), který říká, že bylo rozhodnuto, zda se IS PneuServis spustí či nespustí (například špatná autorizace). Dále můžeme lehce analyzovat všechny značení (stavy), ke kterým v průběhu simulace došlo. Kompletní výčet značení (stavů) je uveden níže v tabulce: Místa / Značení m0 m1 m2 m3 m4 m5 m6
P0 1 0 0 0 0 0 0
P1 0 1 0 0 0 0 0
P2 0 0 1 1 1 1 0
P3 0 0 0 0 0 0 1
P4 0 1 0 0 0 0 0
P5 0 0 1 0 0 0 0
P6 0 0 0 1 1 0 0
P7 0 0 0 0 0 1 0
P8 0 0 0 0 0 1 1
P9 0 0 0 1 0 0 0
P10 0 0 0 0 1 0 0
Tabulka - parciální stavy (značení) Petriho sítě
Následuje strom dosažitelných řešení pro tuto Petriho síť. Připomínáme, že kořenem stromu je počáteční značení Petriho sítě, tedy M0. Strom dosažitelných řešení byl vygenerován pomocí softwarového nástroje PeSim.
Strom dosažitelných řešení
208
Martin Papík
11 Závěr Existuje rozdílný pohled na proces v BORMu a v Petriho sítích. Pohled v BORMu je ucelený, tj. při pohledu na procesní diagram je zřejmé jako proces probíhá. V Petriho sítích je pohled na proces roztříštěn do mnoha různých parciálních stavů, které získáme simulací vzniklé Petriho sítě. To je ale zároveň i výhoda Petriho sítě, protože to umožňuje diskrétnější přístup k modelovanému procesu. Proces v BORMu má větší srozumitelnost, ale menší matematickou přesnost (viz. následující porovnání)
Budoucí práce by se měla zaměřit na prohloubení souvislostí mezi BORMem a Petriho sítí. Zejména pak vytvoření většího množství transformací, prohloubení softwarové implementace. Bude dobré vytvořit i transformaci s použitím větvení (OR-split) a pokusit se ji porovnat s představenou transformací v tomto příspěvku.
Reference 1. Bayer J., Hanzálek Z., Šusta R. Logické systémy pro řízení. Vydavatelství ČVUT 2000. ISBN 80-01-02147-5. 2. Češka M. Petriho sítě. Akademické nakladatelství CERM. Brno 1994. ISBN 8085867-35-4. 3. Křivánek P. http://www.root.cz/serialy/squeak-navrat-do-budoucnosti/. Squeak Návrat do budoucnosti. 4. Lenárt L., Skála P. Původní český CASE nástroj pro metodu BORM. Objekty 2004. sborník konference OBJEKTY 2004. Praha 2004. ISBN XXX-XXX. 5. Merunka V., Pergl R., Pícka M. Objektově orientovaná tvorba softwaru. ČZU PEF 2004. ISBN 80-213-1159-2. 6. Pícka M. Metamodel BORMu jako rozšíření metamodelu UML. Objekty 2003. sborník konference OBJEKTY 2003. Ostrava 2003. ISBN 80-248-0247-0 7. Polák J., Merunka V., Carda A. Umění systémového návrhu. Grada Publishing a.s. 2003. ISBN 80-247-0424-2. 8. Vaníček J. Měření a hodnocení jakosti informačních systémů. ČZU PEF 2004. ISBN 80-213-1206-8.
Metody testování použitelnosti softwarových Metody testování použitelnosti softwarových produktů produktů Josef Pavlíček Josef Pavlíček1 Sun Microsystems Czech s.r.o., 1 Sun Microsystems Czech Evropská 33e,ČR 160 00 Praha 6Evropská 33e,s.r.o., 160 00 Praha 6 - Dejvice, Dejvice, [email protected] ČR, [email protected] Abstrakt. Testování použitelnosti softwarových produktů je problematika, které je věnováno stále větší úsilí. Programové produkty si stále častěji pořizují lidé, kteří k software přistupují jako prostí uživatelé. Doby kdy byl počítač doménou počítačových mágů je pryč. Čím více se počítače stávají součástí běžného života, tím více je nutné přizpůsobit jejich softwarové vybavení právě nezkušenému uživateli. Proto je také nutné klást stále větší důraz na testování použitelnosti. Za její pomoci pak vzniká uživatelsky přívětivý softwarový produkt. Klíčová slova: Usability test, test použitelnosti, mentální model, prototyp, design, uživatel
1
Úvod
Dovolte nám na začátku přednášky uvést krátký žert. „Víte proč je ruské rádio lepší než to americké“? „ S tím ruským lze totiž zatlouci hřebík“. Tento žert hezky rozlišuje dva základní typy v přístupu k designu: 1. Design je nepotřebný výstřelek – slouží jen k ozdobě výrobku, pro nenáročné není zapotřebí 2. Design je nezbytnou součástí výrobku – pomáhá odlišit výrobek od ostatních výrobků, pomáhá uživateli výrobek používat, je jeho součástí Ačkoliv nám ten první přístup připadá směšný, lze se s ním často setkat. Nejlepším příkladem jsou pak nejrůznější internetové presentace a firemní informační portály. Druhý přístup již tak směšný nepřipadá. S jeho extrémem se můžeme setkat také nejlépe na Internetu. Grafická studia někdy dají přednost „půvabné“ grafice na úkor přehlednosti. Intuitivně cítíme, že správná cesta je někde uprostřed. To je nám jasné. A právě úkolem testování použitelnosti je odhalení, zda jsme střední cestu vybrali dobře.
c Václav Snášel, editor: Objekty 2005, pp. 209–216, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
210
2
Josef Pavlíček
Proč použitelnost testovat
Eric Schaffer v knize Institutionalization of Usability v kapitole 2 (The Value of Usability) uvádí: 2 „Použitelnosti je třeba věnovat velkou pozornost“. „V dnešní době si jak zákazníci tak firmy vyrábějící nejrůznější produkty uvědomují její důležitost“. „Obecně lze říci že produkt easy to use se lépe prodává a vyžaduje menší náklady na udržování“[1]. „ Aplikujeme-li inženýrské postupy na její zajištění, pak budeme vyrábět produkty: 1. 2. 3. 4.
Allan Cooper [3] ve svých knihách s oblibou uvádí: „uživatel se nesmí cítit hloupě“[2]. Toto pravidlo by mělo být „svaté“. Jeho zobecnění platí jak pro výrobky běžné spotřeby [4], tak pro softwarové produkty [4]. Uchopí-li uživatel náš produkt 4 do ruky a je-li pro něj jednoduché jej používat, pak jsme jej vyrobili dobře. Uživateli nedělá problémy jej používat. Výrobek „dělá to co si uživatel myslí že by měl dělat“ [2]. Byl tedy dodržen tzv. „mentální model uživatele“ [2] a „uživatel se při používání výrobku necítí hloupě“ [2]. Vzorem takového výrobku může být například iPod shuffle [5] navržený a vyrobený firmou Apple Computer, Inc.. Použitelnost testujeme tedy proto, abychom odhalili porušení „mentálního modelu uživatele“[2]. I když na úplnou opravu celého produktu (v našem případě software) již může být v době testování pozdě, je dobré odstranit alespoň některé prvky porušení mentálního modelu. Mimo porušení mentálního modelu uživatele můžeme během testu použitelnosti odhalit i řadu chyb. Nejčastěji se lze při testování použitelnosti softwarových produktů setkat s chybami v programu. Tyto chyby nebyly odhaleny během testů. V současné době totiž již netestujeme celý program (respektive všechny větve 5 programu), ale používáme vybrané typy testů (testujeme pouze vybrané části programu). Testy jsou připraveny podle tzv. scénářů. Scénáře jsou navrženy podle tzv. typických „Use Case“ [6] (případu užití). Tento způsob testování má několik předností. Především je oproti celkovému testu všech variant případů užití (procházení všech větví programu) mnohem rychlejší. Při své rychlosti je velmi účinný. Byť neodhalí veškeré chyby, většinu chyb odhalí. 2
Volný překlad z originálu Úmyslně uvádíme český překlad a v závorce anglický originál. Český překlad totiž nevyjadřuje zcela význam originálu. 4 V našem případě hovoříme o testování softwarových produktů. Hovoříme-li zobecněně jako o výrobcích, tak jen proto, aby si čtenář mohl představit i jiný druh výrobku, než je software. 5 Zobrazíme-li program pomocí vývojového diagramu, pak se program stane orientovaným grafem s ukončujícími, výkonnými a rozhodovacími bloky, které jsou spolu spojeny hranou. Hranu vystupující z podmínky chápejme jako větev programu. 3
Metody testování použitelnosti softwarových produktů
211
Odhalí-li test použitelnosti nějaké neznámé chyby, pak došlo k tomu, že typický scénář použití nebyl buď dobře navržen a nebo účastník testu použitelnosti nepostupuje podle předpokládaného scénáře. To může být dáno řadou různých faktorů. Počínaje špatně navrženým případem užití, atypickým chováním účastníka testu konče.
3
Kdy testovat
U použitelnosti, jako snad u veškerého testování, platí pravidlo „Testuj ihned jak je něco možné testovat“ [9]. Jenomže testování použitelnosti se velmi špatně dělá, pokud ještě produkt není téměř hotový. Proto převážná část usability testů probíhá až v době, kdy je produkt v beta 6 verzi. To je sice dříve než softwarový produkt ohlásíme jako finální, nic méně, mnohé nedostatky ukázané testem použitelnosti jsou již v této době velice špatně odstranitelné. Existuje ale několik způsobů jak použitelnost alespoň odhadnout v době specifikace požadavků na softwarový produkt. Pomocí metodologie RUP a navržení případů užití [6] můžeme vypracovat předpokládané scénáře užití software. S jistou dávkou obratnosti pak můžeme odhadovat, jak by asi finální software měl vypadat.
4
Možnosti testování použitelnosti
Testování použitelnosti lze rozdělit do dvou základních skupin: 1. Testování před existujícím produktem – prototyp 2. Testování na již hotovém produktu v beta verzi
4.1
Testování před existujícím produktem - prototyp
Tento nástroj pro testování použitelnosti, zdál by se být na první pohled ideální. „Vždyť můžeme odhadnout použitelnost, aniž bychom napsali řádek kódu programu!“ Bohužel tato teze není pravdivá. Podívejme se hlouběji na problém prototypů. Prototypy můžeme rozdělit z hlediska jejich schopnosti věrně zobrazit budoucí produkt do dvou skupin: 1. S malou věrností zobrazení (Low fidelity) [7] 2. S velkou věrností zobrazení (High fidelity) [7] 6
Nebo vytváříme speciální build, právě pro účel testu použitelnosti.
212
Josef Pavlíček
Oba typy prototypů mají své pozitiva a negativa. V krátkosti se je pokusíme uvést.
Prototypy s malou věrností zobrazení Klasickým zástupcem tohoto prototypu je prototyp na papíře (Sketches and paper prototypes) [7]. •
•
Výhody o Je levný o Jednoduše se vyrábí o Je snadné jej měnit a lze jednoduše vytvářet jeho alternativy o Požadavky na znalosti nástrojů jsou nízké, „každý ví, jak jej použít“ o Umožňuje každému v týmu spolupracovat na prototypu o Umožňuje řadu návrhů a změn Nevýhody o Často zobrazuje pouze finální funkčnosti o Co lze namalovat (nebo nalepit) nemusí být snadné technicky realizovat o Papír svádí k pocitu malé důležitosti. Někteří členové týmu jej nemusí považovat za seriozní prototyp. Věnují mu menší pozornost.
Prototypy s velkou věrností zobrazení Klasickým zástupcem je prototyp vytvořený pomocí visuálního programovacího nástroje jako je Flash, NetBeans Matisse, Delphi a podobně. •
•
Výhody o o o o
Uživatelé s ním mohou přímo pracovat Často pokrývá více funkčností než prototyp na papíře Vypadá jako finální produkt Pokud je použitý vhodný programovací nástroj, pak ukazuje, co je možné realizovat a co nikoliv o Může být použitý pro marketing a pro demonstraci produktu před prodejem Nevýhody o Je velmi nákladné jej vyrobit o Spotřebujeme mnoho času na jeho realizaci o Pro svůj design vyžaduje znalosti z prototypu (který v této fázi nemáme) o Svádí zákazníka k nereálné představě, že je produkt již téměř hotový
Metody testování použitelnosti softwarových produktů
213
Kdy a jaký prototyp použít záleží na řešeném problému. Obecně lze o prototypech říci, že šetří peníze. Změna ve finálním produktu je-li možná, bývá velmi nákladná. Není-li možná, cena za prodání „nepovedeného“ produktu je velmi vysoká. Lze těžko číselně vyjádřit ztrátu důvěry zákazníka. Na druhé straně, značka výrobku je často symbolem kvality a je velmi bolestivé ji - byť neúmyslně poškodit.
4.2
Testování na již hotovém produktu v beta verzi
Jak již bylo zmiňováno, testování již téměř hotového produktu je problematické a má svá specifika. Odhalené chyby se špatně opravují. Především chyby v porušení mentálního modelu uživatele. Jedná-li se o přemístění tlačítka z pravého horního rohu do levého dolního, může to být snadné. Horší je, objevíme-li, že scénář podle kterého jsme design navrhli je chybný. V tomto okamžiku čtenář jistě poznamená 7 „ha, dokažte, že design je špatně, já si myslím, že je dobře“. A my, milému čtenáři dokážeme, jak to vlastně s designem je. Nejprve je ale potřeba něco říci o testování použitelnosti.
7
Uvažujeme čtenáře, kterého problematika zajímá a nebojí se konfrontovat své názory s okolím. Typickým zástupcem tohoto čtenáře je vývojář (developer).
214
5
Josef Pavlíček
Testování použitelnosti
Testovat použitelnost můžeme různým způsobem. Sun Microsystems postavil v budově ČVUT na Karlově náměstí Usability laboratoř – Obr.1. Tato laboratoř se skládá z řady videokamer, mikrofonů, reproduktorů a počítačů. Nejvíce je v této laboratoři však monitorů.
Obr.1 :Usability laboratoř Tester – člověk náhodně vybraný ze zvoleného vzorku budoucích uživatelů sedí u zvláštního počítače a řeší většinou triviální úlohu. Počítač simuluje testerovu pracovní stanici. Veškerá testerova činnost se nahrává. Nahrává se pohyb myší, počet kliků na ikonu. Mimo to externí kamery a mikrofony snímají testera a jeho reakce. Tester hlasitě komentuje svou činnost.
Jakob Nielsen [7] se zabýval problémem testováním použitelnosti a vypracoval zajímavý graf zobrazený na Obr.2. Graf (zjednodušeně řečeno) říká, kolik je potřeba testerů, na naleznutí problémů v použitelnosti.
Metody testování použitelnosti softwarových produktů
215
Obr.2: Počet testerů potřebných k testu Z něj vyplývá, že 15 testerů je schopno odhalit téměř všechny problémy v použitelnosti produktu. To je pro nás příjemná zpráva, protože testovat 15 lidí je relativně snadné a není proto zapotřebí složitých studií a masových výzkumů. Odpověď „odvážnému“ čtenáři je jednoduchá. Za dodržení definovaného pravidla jimž je správný výběr testera a předložením vhodných úkolů nám 15 uživatelů ukáže a řekne, zda je zvolený design použitelný (usable) a nebo není.
6
Závěr
Závěrem je třeba říci, že testování použitelnosti, jako každá práce vyžaduje určitou praxi. Postupem času se nám některé chyby v návrhu stávají viditelné na první pohled. Test použitelnosti pak je víceméně nástrojem k jejich ověření a k přesvědčení tvůrců, kteří jen velmi neradi mění svůj design. Testování použitelnosti ale není pouhým nástrojem pro přesvědčování tvůrců. Je to nástroj, který ukazuje, je-li produkt použitelný či nikoliv. To by mělo být základním cílem pro každého tvůrce ať již softwaru či jiných produktů.
Použitá literatura 1. Eric Schaffer, Institutionalization of Usability (a step-by-step guide), Canada, ISBN 0-32117934-X 2. Alan Cooper, The inmates are running the asylum. A Division of Macmillan, Computer Publishing 201 West 103rd Street, Indianapolis, Indiana 46290 3. Who is Alan Cooper, Free Internet encyclopedia, http://en.wikipedia.org/wiki/Alan_Cooper, 10.10.2005
216
Josef Pavlíček
4. Josef Pavlíček, Jakub Franc, Interdisciplinární přístup k sběru uživatelských požadavků na funkčnosti programovacích nástrojů, Sborník konference Tvorba softwaru 2005, Tanger s.r.o., Ostrava, ISBN 80-86840-14X 5. iPod shuffle, Apple web page, http://www.apple.com/ipodshuffle/, 10.10.2005 6. Jacobson I.,Booch G., Rumbaugh J., Unified Software Development Process, ISBN 0201571-692; Published: Feb 4, 1999; Copyright 1999; 7. JoAnn T.Hackos, Janice C. Redish, User and Task Analysis for Interface Design, ISBN 0471-17831-4; Published: Wiley computer publishing, New York, 1998; 8. Jakob Nielsen's Alertbox, March 19, 2000, web page: http://www.useit.com/alertbox/20000319.html, 10.10.2005 9. Vaníček J., Měření a hodnocení jakosti informačních systémů, 2., přepracované vydání, ČZU PEF, Praha, 2004, 328 stran, ISBN 80-213-1206-8
Zkušenosti přístupem object-first v úvodním Zkušenosti sspřístupem object-first v úvodním kursu programování kursu programování Jarmila Pavlíčková1, Luboš Pavlíček2 Jarmila Pavlíčková, Luboš Pavlíček 1 Katedra informačních technologií, FIS, VŠE Praha Katedra nám. informačních technologií, W. Churchilla 4, 130 00FIS, PrahaVŠE 3 Praha nám. W. Churchilla 4, 130 00 Praha 3 [email protected] 2 {pavjar, pavlicek}@vse.cz Katedra informačních technologií, FIS, VŠE Praha nám. W. Churchilla 4, 130 00 Praha 3 [email protected]
Abstrakt. Již od roku 2000 používáme v úvodním kursu Javu, ale teprve od roku 2004 používáme i přístup object-first ve vlastní výuce. V článku jsou popsány naše zkušenosti s procedurálním přístupem k výuce i náš přístup k výuce objektů. Podrobněji popisujeme problémově orientované projekty řešené na cvičeních. Na závěr uvádíme naše zkušenosti s výukou objektů v úvodním kurzu i některé náměty do budoucna. Klíčová slova: výuka programování, Java, BlueJ, objekty, object-first
1
Úvod
Od roku 2000 učíme Javu, ze začátku paralelně s Pascalem, od roku 2004 výhradně Javu. Do roku 2004 jsme první semestr učili studenty procedurálně a až druhý semestr jsme se snažili vysvětlit objekty. Naráželi jsme však na následující problémy: Část studentů v úvodním kurzu již měla předchozí znalosti programování – obvykle Pascalu či PHP. Vzhledem ke svým předchozím zkušenostem s programováním a algoritmizací se tito studenti na úvodních cvičeních nudili a nemuseli se programování věnovat mimo cvičení. Pak se jim často stávalo, že „zaspali“ okamžik, kdy by se měli začít učit. Vytvářelo to i špatnou atmosféru pro začínající studenty – ti viděli, že někteří jejich kolegové nemají žádné problémy s programy a byli z toho zbytečně frustrovaní. Tyto problémy jsou na některých univerzitách jedním z hlavních důvodů pro používání funkcionálních programovacích jazyků v úvodních kurzech programování. Mezi algoritmickým myšlením a chápáním objektů je poměrně velký myšlenkový rozdíl – to jsme si zažili sami. Mnoho studentů nebylo schopno v rámci druhého semestru přejít od algoritmického myšlení k objektovému. Nechápali, proč mají používat objekty, když předtím používali objektový jazyk neobjektově. Vzhledem k rozsahu jimi laděných programů je obtížné ukázat jim výhody objektového přístupu pro řešení složitých úloh. Stejný přístup – procedurální výuka v objektovém jazyce – nebyl našim specifikem. Lze to dokladovat na výsledcích průzkumu úvodních programátorských kurzů v Austrálii a na Novém Zélandu [15]. Z tabulky o používaných programovacích jazycích a přístupech k výuce programování vyplývá, že se většinou používá v
c Václav Snášel, editor: Objekty 2005, pp. 217–230, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
218
Jarmila Pavlíčková, Luboš Pavlíček
úvodních programovacích kurzech objektově orientovaný programovací jazyk, ale objektový přístup k výuce je v Austrálii uplatněn pouze v 36% kurzů. Tabulka 1: Používané programovací jazyky a přístupy ve výuce úvodních kursů programování v Austrálii a na Novém Zélandu.
procedurální objektověorientovaný funkcionální
2
Austrálie dle jazyka dle přístupu 11,7 % 53,0 % 82,2 % 36,6 % 6,1 %
10,3 %
Nový Zéland dle jazyka dle přístupu 8,3 % 34,0 % 91,7 % 66,0 % 0%
0%
Výuka objektů
V Computing Curricula (CC2001) [7] z roku 2001 se doporučuje v úvodních kursech programování začít objektovým přístupem, tj. od začátku výuky programování soustředit pozornost na objektově-orientované programování a návrh. Pro školní rok rozdělený do dvou semestrů se navrhují dva předměty: CS111 Objektově orientované programování CS112 Objektově orientovaný návrh a metodika Za základní výhodu tohoto přístupu je označováno brzké seznámení s objektově orientovaným programováním, které je standardem při tvorbě programového vybaveni. Objektový přístup je výhodný pro složitější úlohy, tudíž studenti se při výuce budou od začátku seznamovat se složitějšími aplikacemi se složitějšími vnitřními vazbami, složitější komunikací. Studenti by se o objektech měly naučit a pochopit následující: Třídy a instance – studenti by měly být schopni nejen deklarovat třídy a vytvářet instance, ale i určovat datové atributy, správně určovat metody a jejich parametry. Zapouzdření – tj. vytvářet zapouzdřené třídy, které zajišťují jednu věc, metody, které dělají pouze jednu činnost, u metod pouze nezbytně nutné parametry, minimalizovat „globální“ proměnné. Polymorfismus – studenti by měli získat základní zkušenosti s polymorfismem, s výhodami a nevýhodami situací, kdy se při stejných voláních provádí různý kód. Předpokladem pro zvládnutí polymorfismu je samozřejmě znalost dědičnosti a implementace rozhraní. Návrhové vzory – logicky navazují na předchozí témata. V rámci úvodních kursů nelze návrhové vzory probrat podrobně, studenti by se však měli aspoň s některými seznámit. 2.1
Náš přístup k výuce objektů
V naší výuce objektů jsme se inspirovali přístupem M. Köllinga [8, 9, 10, 11], autora výukového vývojového prostředí BlueJ a propagátora přístupu k výuce object-first. Rozhodli jsme se pro následující postup ve výuce:
Zkušenosti s přístupem object-first v úvodním kursu programování
219
-
objekty byly navrženy pro pochopení/zvládnutí složitých problémů. Studentům je potřeba ukazovat používání objektů na „složitých“ problémech. Přitom je potřeba výuku připravit tak, aby studenti mohli postupovat od jednoduchého ke složitějšímu. Postup cvičení máme následující: o nejdříve ukážeme studentům na existující aplikaci, jak fungují objekty, jaký je rozdíl mezi třídou a instancí (vytvořit více instancí), jak volat metody instancí, o na jiné úloze studenti mění hodnoty řetězců, naučí se na tom překládat a rozumět chybovým hlášením překladače, o dále následuje úprava obsahu metod či psaní obsahu metod, o dalším krokem je návrh metod v existujících třídách, o dále studenti k existujícím třídám navrhují další třídy, o posledním krokem je návrh aplikace od začátku do konce, - náročnost úloh a rychlost postupu musí být odpovídající tomu, že jsme na vysoké škole a je to oborový předmět, průměrný student by se měl předmětu věnovat 3 až 5 hodin týdně ve svém volném čase (tj. vedle účasti na přednáškách a cvičeních), z toho vyplývá nutnost vytvořit ke každému cvičení náměty na domácí úkoly, - na přednáškách vykládáme objekty a jazyk, na cvičeních se řeší problémy. Cílem cvičení je trénování objektového myšlení na řešení předložených problémů, tj. ukázat jim problémy, diskutovat s nimi jak je řešit. Vlastní postup výuky objektů ukážeme na projektech popsaných v další části příspěvku. 2.2
Výběr vhodného vývojového prostředí
Dalším logickým krokem je volba vývojového prostředí, které bude pro výuku využíváno. Při předchozím procedurálním přístupu jsme používali v úvodu kurzu pouze Poznámkový blok a příkazovou řádku. V rámci školní sítě pak byla nainstalována některá jednodušší vývojová prostředí pro Javu jako je JEdit, JCreator nebo BlueJ, z tech složitějších NetBeans nebo Eclipse. Volbu vývojového prostředí jsme pak nechali na studentech. Podle našich zkušeností si asi 90% studentů zvolilo některé z jednodušších (JCreator, BlueJ, JEdit). Pro výuku objektů je vhodné prostředí, které studentům ukáže graficky vytvářené instance a umožňuje prohlížení obsahu jejich datových atributů a spouštění jednotlivých metod. Logicky padla volba na BlueJ [4], které je určeno pro výuku objektů a má tyto vlastnosti. Nezanedbatelnou výhodou je i lokalizace do češtiny.
3 3.1
Projekty pro úvodní kurs programování Projekt Obrázek
Projekt Obrázek se skládá z několika tříd – třídy Platno, na kterou se kreslí geometrické tvary představované třídami Ctverec, Trojuhelnik a Kruh. Na prvním
220
Jarmila Pavlíčková, Luboš Pavlíček
cvičení studenti vytvářejí instance tříd geometrických tvarů a pomocí volání metod instancí pohybují s nimi po plátně či mění jejich vlastnosti. Snaží se nakreslit jednoduchý obrázek (např. sněhuláka). Na tomto studentům vysvětlujeme rozdíl mezi třídou a instancí, posílání zpráv (volání metod), smysl datových atributů (vyjádření statického stavu instance). Cílem druhého cvičení je programové nakreslení obrázku. Studenti na začátku mají další třídu Obrazek, která nakreslí obrázek domečku. Prvním cílem je upravit tuto třídu tak, aby se nakreslil jiný obrázek (např. sněhulák). Na tom se studenti učí zapisovat jednoduchou sekvenci příkazů – vytváření instancí a volání metod. Součástí tohoto cvičení je i návrh datových atributů, překládání a seznamování se s chybovými hlášeními překladače. Do obrázku se snažíme doplnit i určitou dynamiku – metody pro východ a západ slunce či metodu pro příjezd/odjezd auta. 3.2
Kalkulačka
Na dalším cvičení pracujeme s projektem Kalkulačka. Již od začátku se snažíme studentům ukázat, že je třeba grafické aplikace vytvářet tak, že grafika je oddělena od logiky. Projekt Kalkulačka se skládá z následujících tříd (obrázek z BlueJ):
Obr. 1. Diagram tříd projektu Kalkulačka.
Třída GrafikaKalkulacky zajišťuje obsluhu grafického rozhraní a řízení aplikace, instance třídy Kalkulator provádí vlastní výpočty (vždy vypočte hodnotu, která se má zobrazit na displeji). Třída Kalkulator obsahuje pouze hlavičky metod Úkolem studentů je „naučit kalkulačku počítat“, tj. doplnit datové atributy a dokončit předpřipravené metody ve třídě Kalkulator. Cílem je: • navrhnout datové atributy pro třídu Kalkulátor, • použití datových atributů pro ukládání hodnot a stavů, • procvičit základní operace s primitivními datovými typy (čísla, znaky, logická hodnota), • používání selekcí (příkaz if) a vytváření podmínek. • zdůraznit význam komunikace mezi instancemi, kterou jim pro lepší pochopení simulujeme nejprve pomocí vláčků, viz obrázek.
Zkušenosti s přístupem object-first v úvodním kursu programování
221
Obr. 2. Komunikace mezi instancemi v projektu Kalkulačka.
Poté co studenti pochopí, jak probíhá komunikace mezi jednotlivými instancemi v této aplikaci, jim totéž ukážeme v sekvenčním diagramu (viz následující obrázek). V dalších projektech již pro znázornění a objasnění komunikace mezi instancemi v aplikaci používáme sekvenční diagramy.
Obr. 3. Komunikace mezi instance v projektu Kalkulačka.
222
3.3
Jarmila Pavlíčková, Luboš Pavlíček
Hádání slov
Tento projekt používáme pro vysvětlení seznamů. Na začátku aplikace poskytuje jedno slovo k hádání, cílem je rozšířit aplikaci o seznam slov k hádání. Po zvládnutí tohoto cíle studenti mají za úkol poskytovat slova v náhodném pořadí. Studenti opět doplňují předpřipravené metody a doplňují do třídy PoskytovatelSlov potřebné datové atributy.
Obr. 4. Obrazovka aplikace na hádání slov.
Cílem tohoto projektu je naučit se používat seznamy v Javě (konkrétně třídu java.util.ArrayList a některé její metody). V minulém školním roce jsme studenty nejdříve seznamovali s polem jako se statickou datovou strukturou. Od letošního roku v souvislosti s používáním Java 5.0 a generických typů začínáme seznamy, neboť jejich použití nám přijde v Javě jednodušší, než použití polí. 3.4
Trojúhelníky
V projektu Trojuhelniky jsou studenti nuceni používat statické prvky, výčtový typ a opět seznamy. Je to jednoduchá aplikace, která na základě vstupních parametrů vypočte informace pro jednotlivé typy trojúhelníků (rovnostranný, pravoúhlý se znalostí stran a a b, pravoúhlý se znalostí stran a a c, atd.). V tomto projektu studenti doplňují metody do tříd (tj. zde nemají předpřipravené metody). Aplikace není grafická – používá textové rozhraní.
Zkušenosti s přístupem object-first v úvodním kursu programování
223
Obr. 5. Diagram tříd v projektu Troúhelníky.
Projekt používáme ještě na jednom cvičení ke konci semestru, kdy studenti doplňují do projektu detekci chybových stavů, generování a odchytávání výjimek. 3.5
Škola
Projekt Skola je pouze fragment aplikace – cílem je ukázat, jak v instancích zachytit stromovou strukturu. Aplikace na začátku není funkční - po dokončení aplikace studenty by se měla na obrazovku vypsat organizační struktura školy (variantně s pracovníky či bez pracovníků). V tomto projektu studenti řeší tyto úkoly: - navrhnout datové atributy ve třídě Utvar pro uložení podřízených útvarů a osob pracujících v útvaru, - doplnit obsah metod pridej() ve třídě Utvar, - vypsat seznamu podřízených útvarů, tj. doplnit obsah metod vypis() ve třídě Utvar. Tento projekt má následující cíle: - ukázat vytvoření složitější datové struktury – v tomto projektu se vytvoří stromová struktura instancí (organizační struktura školy) – viz obrázek 6. Projekt též ukazuje rozdíly mezi strukturou tříd a strukturou instancí. - ukázat přetěžování metod na metodě pridej().
224
Jarmila Pavlíčková, Luboš Pavlíček
Obr. 6. Diagram instancí v projektu Škola.
3.6
Adventura
Po zavolání metody hraj() nad instancí třídy Hra se spustí jednoduchá adventura s textovým rozhraním, která umožní hráči procházet jednotlivými místnostmi hry. Hráč může zadávat příkazy „jdi“, „napoveda“ a „konec“. Na tomto projektu studentům ukazujeme vytváření nové třídy, která představuje věci v místnostech, které hráč může sbírat do batohu či z batohu vyndávat a pokládat do místnosti.
Zkušenosti s přístupem object-first v úvodním kursu programování
225
Obr. 7. Diagram tříd projektu Adventura
Studenti dále hru rozvíjejí ve své semestrální úloze – mají za úkol vymyslet svůj příběh a ten poté naprogramovat. Příběh může vypadat takto: „Ztratili jste se v dole. Potkáte trpaslíka. Když najdete něco k jídlu a dáte to trpaslíkovi, trpaslík vám řekne, kde je kouzelná hůlka. Pokud použijete kouzelnou hůlku ve velké jeskyni, otevře se východ z podzemí a vyhrajete.“ Mnoha zadání vytvořená studenty vedou k vytvoření dalších tříd a k naprogramování mnoha změn do poskytnuté předlohy. Teprve na této, z jejich pohledu relativně velké úloze, si mnozí z nich uvědomí nutnost dodržování konvencí či potřebu správného rozdělení činností do jednotlivých metod a jednotlivých tříd. 3.7
Domácí mediotéka
V projektu Domácí mediotéka (Dome) se jednoduchým způsobem evidují CD a videa. Projekt je velmi jednoduchý, cílem je vysvětlit na něm dědičnost a polymorfismus.
226
Jarmila Pavlíčková, Luboš Pavlíček
Obr. 8. Diagram tříd projektu Domácí mediotéka
Prvním úkolem studentů je omezit duplicity ve třídách Video a CD pomocí vytvoření společného předka, který bude obsahovat společné datové atributy a metody. Dalším úkolem je zrušit duplicity ve třídě Evidence – na začátku třída obsahuje samostatné seznamy knih a CD, na konci je pouze jeden seznam, který obsahuje videa i CD. Předpokladem pro to je definice abstraktní metody u předka (u třídy Polozka), aby se mohl využít polymorfismus při výpisu informací o položkách v seznamu. Výsledný diagram tříd je zobrazen na obrázku 9. Studenti dále doplní evidenci o knihy – na tom se ukážou další výhody společného předka, ze kterého lze dědit některé metody a který nutí k implementaci konkrétních metod, což usnadňuje použití polymorfismu.
Zkušenosti s přístupem object-first v úvodním kursu programování
227
Obr. 9. Výsledný diagram v projektu Domácí mediotéka.
Na dalším cvičení stejný projekt používáme pro vysvětlení rozhraní.
4
Závěr
V zimním semestru 2004/5 jsme u studentů zjišťovali jak jejich úvodní znalost programování, tak i počet hodin strávených přípravou na tento předmět (každých 14 dní studenti sdělovali, kolik hodin strávili přípravou na předmět za minulý týden). Z výsledných dat vyplývá, že není výrazný rozdíl mezi začínajícími programátory a studenty, kteří o sobě sami prohlásili, že umí programovat. Zjišťovali jsme i vazbu na úspěšnost v předmětu, ta ale není relevantní – většina studentů, která neuspěla ani neodpovídala na dotazníky. Je z toho jeden poznatek – studenti, kteří věnovali předmětu potřebný čas bez problémů absolvovali. Tabulka 2. Vztah mezi úvodní znalostí studentů a průměrným počtem hodin věnovaných přípravě na úvodní kurs programování (není zahrnuta přímá výuka).
průměrný počet hodin týdně věnovaný kurzu 4,75 4,33
z toho programováním
4,64
4,08
4,58
3,82
3,90 3,59
228
Jarmila Pavlíčková, Luboš Pavlíček
Naše zkušenosti za 1 rok výuky object-first: - Ve druhém kursu programování jsou velmi znát lepší znalosti objektů u většiny studentů, Zatím nemůžeme posoudit lepší schopnosti abstrakce a analýzy/návrhu aplikací v navazujících projekčních kurzech, neboť tyto kurzy zatím neabsolvovali. - Není výrazný rozdíl v úspěšnosti studentů v procedurálním přístupu a přístupu object-first – úspěšnost se pohybuje mezi 65-70%. Dle našich zkušeností za většinou neúspěchů dříve i nyní je podcenění předmětu – studenti nevěnují předmětu dostatek času. - Na cvičeních je mnohem menší rozdíl mezi studenty, kteří již dříve programovali proti studentům, kteří začínají. Výjimkou jsou samozřejmě studenti, kteří programovali již dříve objektově. Bohužel se občas projevuje frustrace u studentů, kteří dříve programovali strukturovaně, protože jejich předchozí znalosti jim spíše brání v pochopení objektů. Je zajímavé i sledovat vývoj názorů studentů, kteří již dříve programovali. Na začátku semestru se občas ptají, proč nezačínáme „Hello World!” a nepoužíváme přístup popisovaný ve většině učebnic programování. Při psaní zápočtu do indexu sami přiznají, že teprve v tomto kursu pochopili objekty. Náš přístup k výuce objektů není jediný. V literatuře lze najít i jiné pohledy a doporučení pro výuku objektů. Jsou to pro nás náměty pro úpravy výuky do budoucna, byť ne všechny je možné bez výhrad přijmout. Z těchto námětů zde vybíráme následující: Dříve vykládat rozhraní. Rozhraní (ve smyslu jazykové konstrukce interface v Javě) je považována některými autory (např. [5]) za jednu z nejdůležitějších „novinek“ ve vývoji programovacích jazyků, neboť vytváří abstraktní vrstvu mezi konkrétními implementacemi a jejich klienty. A. Schmolitzsky z University Hamburk v [16] doporučuje seznámit studenty s rozhraními před dědičností a polymorfismem – přibližně v 6. týdnu výuky. Ing. Pecinovský [14] se snaží učit rozhraní od druhého týdne výuky. My máme rozhraní nyní zařazeny až na konec semestru v souvislosti s dědičností a polymorfismem. Dříve začlenit testy. Testy by měly být samozřejmou výbavou každého programátora. Jejich význam se stále zvýrazňuje, viz např. kniha Programování řízení testy od K. Becka [2]. Někteří [6] doporučují začlenit testy již do úvodního kursu programování – v podstatě výuku řízenou testy. Jednotkové testování je též integrální součástí výukového prostředí BlueJ. My máme nyní testy začleněny do 2. semestru. Používat větší projekty. K. Nygaard, jeden ze zakladatelů objektově-orientovaného programování, doporučuje v úvodním kursu použít pouze několik velkých projektů [13]. Výhodou je lepší porozumění projektu (problémové oblasti) i větší prokázání výhody objektového přístupu. Náš názor je, že větší projekt znamená vyšší míru složitosti, kterou je náročná pro studenty. Vysvětlení některých objektových prvků na velkém projektu může být obtížné či kostrbaté. Na druhou stranu pedagogicky dobře připravený větší projekt by mohl být přínosem. Začlenit návrh do úvodního kursu programování. Začínat výuku programováním je trochu proti logice vývoje programů. Například C. Alphonce [1] začleňuje do prvních týdnů úvodního kursu návrh aplikace včetně výuky UML diagramů
Zkušenosti s přístupem object-first v úvodním kursu programování
229
(v prvních 4 týdnech semestru s pomocí UML vysvětlí dědičnost a polymorfismus). Projektování přináší do úvodního kurzu další dimenzi, která ubírá čas na programování. Vhodnější je dle nás úvodní kurs věnovaný pouze návrhu, na který bude navazovat kurz programování. Tento přístup používá např. J. Bennedsend [3], který vidí hlavní výhodu ve větší úspěšnosti studentů – nároky na abstraktní a symbolické myšlení jsou při projektování odlišné od programování a často více schůdné pro studenty v prvním ročníku. Velkým příznivcem model-first přístupu jsou autoři vývojového prostředí Fujaba, kteří se snaží aplikovat tento přístup i ve výuce programování na středních školách [17].
Reference 1. Alphonce C., Ventura P.: Object Orientation in CS1-CS2 by Design. ITiCSE’02, 2002, Aarhus, Denmark. 2. Beck K.: Programování řízení testy. Grada 2004 Praha. ISBN 8024709015. 3. Bennedsen J., Caspersen M. E.: Programming in Context – A Model-First Approach to CS1. SIGCSE’04, 2004, Norfolk, Virginia, USA. 4. BlueJ – výukové vývojové prostředí. www.bluej.org. 5. Canning, P.S., Cook, W.R, Hill, W.L., Olthoff, W.G.: „Interfaces for StronglyTyped Object-Oriented Programming“. OOPSLA’89, New Orleans, Louisiana. 6. Edwards S. H.: Rethinking Computer Science Education from Test-first Perspective. OOPSLA’03, 2003, Anaheim, California, USA. 7. The Joint Task Force on Computing Curricula (IEEE Computer Society and Association for Computing Machinery): Curriculum Guidelines for Undergraduate Degree Program in Computer Science (CC2001). http://www.computer.org/education/cc2001/final. 8. Kölling M., Barnes D.J.: Enhancing Apprentice-Based Learning of Java. SIGCSE’04, 2004, Norfolk, Virginia, USA. 9. Kölling M., Barnes D.J.: Object First with Java: a practical introduction using BlueJ. Pearson Education Limited, 2nd edition 2005. ISBN 0131249339. 10. Kölling M., Quig B, Patterson A., Rosenberg J.: The BlueJ system and its pedagogy. Published in the Journal of Computer Science Education, special issue on Learning and Teaching Object Technology, Vol 13, No 4, Dec 2003. 11. Kölling M., Rosenberg J.: Guidelines for Teaching Object Orientation with Java. 6th conference Information Technology in Computer Science Education, Canterbury, 2001. 12. Merunka V.: Objektově orientované technologie ve výuce projektování informačních systémů. Ve sborníku konference Informatika 1999. 13. Nygaard K.: COOL (Comprehensive Object-Oriented Learning). Proceedings of the 7th Annual Conference on Innovation and Technology in Computer Science Education (ITiCSE), 2002. 14. Pecinovský R.: Začlenění návrhových vzorů do výuky programování. Ve sborníku konference Objekty 2005.
230
Jarmila Pavlíčková, Luboš Pavlíček
15. Raadt M., Watson R., Toleman M.: Introductory Programming: What’s Happening Today and Will There Be Any Students to Teach Tomorrow?. 6th Australasian Computing Conference 2004, Dunedin, NZ. 16. Schmolitzsky, A: „Object First, Interfaces Next“ or Interfaces Before Inheritance. OOPSLA’04, Vancouver, Canada. 17. Schulte C., Niere J.: Thinking in Object Structures: Teaching Modelling in Secondary Schools. Proc. of the ECOOP Workshop on Pedagogies and Tools for Learning Object-Oriented Concepts, 2002. http://www.upb.de/cs/agschaefer/Veroeffentlichungen/Quellen/Papers/2002/PTLOOC2002.pdf
Systémpro pro vývoj distribuovaných aplikací Systém vývoj distribuovaných aplikací Plaant Plaant 1
Rudolf Pecinovský1, Vladimír Lahoda1 Rudolf Pecinovský, Vladimír Lahoda
Amaio Technologies Inc., 100 00 Praha 10, Třebohostická 14 [email protected] Amaio Technologies Inc. [email protected] {rpecinovsky, vlahoda}@amaio.com
Abstrakt. Při vývoji distribuovaných podnikových aplikací na zakázku se setkáváme s poměrně typickou sadou požadavků, které se neustále opakují. Systém Plaant byl vyvinut jako nástroj pro vývoj a následnou údržbu distribuovaných databázových aplikací. Nástroj, který výrazně snižuje jejich pořizovací i provozní náklady. Současně snižuje požadavky na kvalifikaci a zkušenosti vývojářů, kteří v něm tyto aplikace vyvíjejí. Celý systém je postaven na platformě J2EE a nabízí řadu jedinečných sofistikovaných vlastností a funkcí. Vedle možnosti snadné definice základních formulářů, které systém automaticky upraví pro různé druhy klientů (tlustý klient, webové rozhraní, mobilní telefon, …), nabízí i propracované možnosti řízení koloběhu dokumentů (workflow) a tvorby komplexních sestav určených pro různé cíle (tiskárna, komfortní grafický výstup, webová služba, …). Klíčová slova: framework, distribuované aplikace, vývoj, J2EE
1
Úvod
Při vývoji distribuovaných podnikových aplikací pro naše zákazníky jsme se setkávali se stále stejnými požadavky a problémy, které byly vždy jen trochu modifikované. Cítili jsme potřebu používat při vývoji těchto aplikací nějaký sofistikovaný systém, který by s těmito typickými požadavky předem počítal a řešil je automaticky, čímž by nám umožnil se soustředit na vlastní logiku aplikace. Protože na trhu žádný takový systém nebyl, rozhodli jsme se jej vyvinout sami. Výsledný vývojový a provozní nástroj jsme nazvali Plaant.
2
Základní charakteristika Plantu a v něm vytvořených aplikací
Plaant je systém umožňující rychlý vývoj, jednoduché nasazení a snadnou správu robustních datově orientovaných distribuovaných aplikací. Uživatelé aplikací vyvinutých v systému Plaant se mohou k těmto aplikacím připojovat prostřednictvím mnoha druhů klientských zařízení od klasického stolního počítače připojeného k místní síti, přes webový terminál až po mobilní telefony programovatelné v Javě (dnes již téměř všechny). Komponentová podstata aplikací vytvořených v systému Plaant navíc umožňuje jejich snadnou rozšiřitelnost. Aplikace vytvořené v systému Plaant jsou postavené na platformě J2EE a respektují všeobecně zavedené standardy. To přináší jejich snadnou nasaditelnost na nejrůz-
c Václav Snášel, editor: Objekty 2005, pp. 231–240, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
232
Rudolf Pecinovský, Vladimír Lahoda
nější počítače a operační systémy a schopnost komunikovat se širokým spektrem používaných databází a aplikačních serverů. Plaant poskytuje automatizované mechanizmy správy databáze, poštovních služeb a posílání zpráv. Navíc je pro klientské stanice schopen samostatně připravit kompletní grafické uživatelské rozhraní, které již nevyžaduje žádnou další údržbu, a to ani při změnách požadavků. Osvobozuje tak vývojáře od značné části kódování, protože podstatnou část aplikace vytvoří systém sám na základě dodané specifikace jejího požadovaného chování. Tím se veškeré vývojové práce samozřejmě výrazně zrychlí. Zkušenost ukázala, že použitím systému Plaant se doba vývoje aplikace a s ní i vývojové a udržovací náklady sníží zhruba na polovinu (40 až 60 %). Klienti vytvoření systémem Plaant nevyžadují, nezávisle na svém typu, žádnou dodatečnou údržbu. Po prvotním nastavení klientského zavaděče aplikace jsou všechny aktualizace realizovány automaticky.
3
Části systému Plaant
Systém Plaant je tvořen několika relativně nezávislými částmi, z nichž některé se uplatní při vývoji nových aplikací, některé při jejich provozu a další v obou etapách života aplikace.
Obr. 1: Architektura systému Plaant
Systém pro vývoj distribuovaných aplikací Plaant
3.1
233
Prostředky pro návrh a správu aplikace
Plaant Tool Plaant Tool je samostatný program, který je základním integrovaným vývojovým prostředím používaným při návrhu aplikace. Výrazně usnadňuje návrh, vytvoření a nasazení (deployment) aplikace. Poskytuje prostředky pro návrh základní struktury databáze (detaily struktury dotvoří systém sám) spolu s prostředky pro návrh uživatelského rozhraní a automatizuje vytvoření potřebné struktury tabulek a následně nasazení aplikace na aplikační server. Způsob návrhu uživatelského rozhraní, který Plaant Tools využívá, není sice klasický WYSIWYG, nicméně umožňuje velmi snadno navrhnout i relativně komplikované formuláře. V kterémkoliv okamžiku pak na požádání zobrazí aktuální podobu navrhovaného formuláře ve swingovém či webovém rozhraní, takže návrhář si může ihned zkontrolovat, nakolik jeho návrh odpovídá požadavkům zadavatele. Práce s programem Plaant Tool nevyžaduje žádné programátorské znalosti a zkušenosti. Při vhodném zaškolení může s jeho pomocí vyvíjet základních kostru budoucích aplikací i zkušenější uživatel. Plaant Commander Plaant Commander je také samostatný program a slouží k přípravě vytvořené a nasazené aplikace k jejímu prvnímu spuštění. V dalších etapách jejího života je to pak základní pracovní nástroj jejího správce. Jeho GIU je odvozeno od oblíbených správců souborů à la Norton Commander, takže uživatelům nečiní žádné problémy. 3.2
Jádro aplikací Plaant
Jádro plaantových aplikací je tvořeno několika spolupracujícími komponentami. Využívají je nejenom vlastní aplikace, ale i výše zmíněné nástroje Plaant Tool a Plaant Commander. Komponenty systému Plaant vyhovují specifikaci EJB 1.1, takže mohou být provozovány i na starších verzích aplikačních serverů. Organizace, které jeho aplikace nasazují, proto nejsou nuceny vyměnit používané systémy, což často výrazně šetří instalační náklady. 3.3
Centralizovaná správa datových struktur
Všechny informace o systémových datových strukturách aplikace, jejích komponentách a uživatelském rozhraní jsou uloženy v datovém úložišti (repository). Při spuštění si aplikace tyto informace přečte a podle nich se nastaví. Stejně tak i klient obdrží při přihlášení k aplikaci informace o struktuře dat a uživatelského rozhraní a podle nich se pak nastaví. Tato koncepce výrazně urychluje vývoj aplikace a zároveň chrání systém před nekorektními úpravami, při nichž vývojáři zapomenou na některé důležitě aspekty či vazby.
234
Rudolf Pecinovský, Vladimír Lahoda
Při každé změně uložených informací Plaant zkontroluje jejich korektnost a v případě odhalení jakékoliv nekorektnosti ji odmítne zanést do úložiště a upozorní vývojáře na to, aby ji opravil. Na druhou stranu tato koncepce umožňuje kdykoliv snadno, rychle a s minimálními náklady změnit některé vlastnosti aplikace či upravit funkčnost jednotlivých komponent.
4
Vlastnosti vytvořených aplikací
Křižovatka Po spuštění aplikace se otevře aplikační okno s panelem označovaným jako Křižovatka. Na tomto panelu je několik karet přiřazených skupinám tzv. agend (pojem bude vysvětlen dále). Na každé kartě pak uživatel nalezne tlačítka zastupující dostupné agendy. Stiskem tlačítka se pak přímo přesune do panelu dané agendy. Tabulky a formuláře Panel agendy má opět několik karet. Jako první je vždy uvedena karta tabulky, což je základní zobrazení, které se nastaví při přechodu do okna agendy. V tabulce je možno se pohybovat po záznamech v agendě, vyhledávat je, řadit a filtrovat. Výběr polí a řazení záznamů Na kartě tabulky si může uživatel kdykoliv vybrat, která z polí příslušné agendy, resp. z agend, na jejichž záznamy dané agendy odkazují (resp. z agend odkazovaných z odkazovaných agend atd.) budou v tabulce zobrazena a v jakém pořadí. Současně může zadat, zda budou záznamy nějak seřazeny, přičemž je může řadit i podle několika polí současně (např. příjmení – křestní jméno – rodné číslo). Filtry Plaant nabízí bohaté a propracované možnosti filtrování zobrazovaných záznamů. Filtrovat lze přitom nejenom podle hodnot v polích (zobrazovaných i nezobrazovaných), ale podle libovolně složitých logických výrazů, v nichž porovnání těchto hodnot vystupují. Při specifikaci rozhodovacích pravidel se přitom uživatel nemusí omezovat pouze na hodnoty polí dané agendy, ale může se odkázat na libovolné pole kterékoliv z agend, na jejíž záznamy se záznamy dané agendy odkazují, na pole agend odkazovaných z odkazovaných agend atd. To vše bez nutnosti explicitního uvádění vazeb mezi jednotlivými tabulkami. Troufáme si tvrdit, že prostředky, které takto koncipované filtry poskytují, jsou daleko mocnější a přitom uživatelsky pochopitelnější než dotazovací mechanizmus programu Access, jenž je na mnoha místech vydáván za vzor uživatelské přívětivosti. Sestavy Aplikace jsou připraveny i na situace, kdy uživatel potřebuje „vyjet“ nějakou sestavu, která reaguje na okamžitou situaci a v návrhu aplikace se s ní nepočítalo. Pro definici sestav je k dispozici nástroj, který nabízí obdobné možnosti, jaké mají uživatelé pro definici zobrazovaných a třídících polí a k definici filtrů.
Systém pro vývoj distribuovaných aplikací Plaant
235
Pohledy Souhrn nastavení zobrazovaných a třídících polí, filtru a sestavy je chápán jako pohled na agendu. Uživatel může definovat řadu různých pohledů a každý si uložit pro případ, že se situace či úloha, pro níž daný pohled definoval (např. účetní uzávěrka, vyhledání faktur po splatnosti, přehled nejdůležitějších zákazníků atd.), bude v budoucnu opakovat.
5
Jak se v systému Plaant vyvíjí aplikace
Plaant je komplexní systém. Je to zároveň sada nástrojů pro vytvoření aplikace a zároveň prostředí, v němž na serveru aplikace běží a které komunikuje s koncovými uživateli prostřednictvím klientského GUI a umožňuje administrátorovi správu celé aplikace. 5.1
Analytická příprava – návrh agend
Při analýze úlohy je třeba navrhnout databázovou strukturu budoucí aplikace a funkce, které bude aplikace plnit. Typický objekt databázové aplikace modeluje nějakou datovou entitu – tvoříme-li např. databázi pro knihovnu, budeme (mimo jiné) modelovat jednotlivé knihy, nakladatele, autory, čtenáře atd.; tvoříme-li databázi pro účtárnu, budeme modelovat účty, faktury, zákazníky, dodavatele, položky faktur atd. Kolem každé modelované entity vzniká celá agenda činností, které jsou s ní spojeny. Tuto agendu má v Plaant aplikacích na starosti samostatná komponenta, kterou budeme označovat termínem Agenda a která představuje modelovanou entitu jako celek s jejím funkčním i datovým obsahem. Data Agendy bývají v relační databázi většinou reprezentovány jako tabulky, ale není to pravidlo. Agendy jsou totiž obecnější. Na jednu stranu mohou existovat tzv. agendy bez dat, které nemají v databázi žádnou přímou reprezentaci a jsou realizovány čistě programově, na druhou stranu však mohou existovat také agendy, které jsou v relační databázi reprezentovány celou skupinou tabulek. Agendy mohou vytvářet stromy dědičnosti, v nichž dceřiné agendy přebírají do svých záznamů všechna pole svých rodičovských agend. Možnost využití mechanizmu dědičnosti výrazně zjednodušuje analýzu a realizaci některých typických zákaznických požadavků. Jak bývá v relačních databázích zvykem, agendy mohou obsahovat odkazy na jiné agendy, přičemž Plaant rozeznává dva druhy odkazů: jednoduchý odkaz směřující na konkrétní záznam a tabulkový odkaz odkazující na celou množinu záznamů. Při vytváření odkazů typu 1:N přitom nebývá nutno vytvářet explicitně příslušnou mezitabulku, protože ji Plaant dokáže vytvořit a spravovat sám. Agendy mohou obsahovat nejenom odkazy na jiné agendy, ale mohou také obsahovat jiné agendy jako své komponenty. To ulehčuje analýzu i realizaci častých úloh,
236
Rudolf Pecinovský, Vladimír Lahoda
které je tak možno předem připravit jako samostatné komponenty a poté je do vytvářené aplikace pouze vložit. Formuláře Součástí definice agendy je nejenom návrh jejích polí, ale také návrh formulářů, prostřednictvím nichž budou uživatelé přistupovat k jejím datům. Jak jsme již naznačili, tyto formuláře budou použity pro všechna rozhraní, která bude daná aplikace podporovat, a proto je vhodné na tuto skutečnost při jejich návrhu myslet (např. nevytvářet příliš rozměrné formuláře, počítáme-li s častým použitím aplikace na různých PDA a dalších zařízeních s menší obrazovkou). Stavové diagramy U některých aplikací se množina operací, které je třeba provádět, resp. které se smí provádět s daty v záznamu, závislá na stavu, v němž se daný záznam nachází. Takovéto závislosti bývá výhodné popsat stavovým diagramem, v němž můžeme k jednotlivým stavům přiřadit jak množinu přípustných, resp. povinných operací, tak akce, které se automaticky spustí při přechodu mezi zadanými stavy. Výstupní sestavy Prakticky všechny aplikace musí být schopny generovat nejrůznější sestavy. Plaant v tomto směru vychází zákazníkům vstříc a na požadované formátování a obsah výstupních sestav neklade prakticky žádná omezení. Speciální funkce Součástí návrhu aplikace je také zadání speciálních funkcí, které realizují některé nestandardní činnosti. Tyto funkce jsou většinou následně implementovány buď jako spouštěče (triggery) nebo jako průvodci, kteří při vyvolání dané funkce pomohou uživateli postupně specifikovat jeho konkrétní požadavky. Pro tvorbu případného uživatelského rozhraní těchto speciálních funkcí má návrhář aplikace k dispozici stejné nástroje jako pro definici základního chování agend. Vlastní výkonný kód funkcí je však třeba naprogramovat klasickými prostředky prostřednictvím tříd postavených nad API sytému Plaant. Přístupová práva Poslední, avšak velmi důležitou součástí zadání je specifikace jednotlivých uživatelských rolí a práv, která jsou s těmito rolemi spojena. Možnosti systému Plaant jsou v této oblasti opět nesmírně bohaté. Na rozdíl od běžných standardů má jeho přístup k bezpečnosti nízkou granularitu, takže umožňuje daleko jemnější nastavení nejrůznějších bezpečnostních hledisek. Bezpečnostní koncepce aplikací vyvíjených pomocí systému Plaant není postavena na uživatelích, ale na rolích. Každý uživatel může mít v systému řadu rolí a jeho možnosti přístupu k informacím jsou ovlivněny jeho aktuální rolí. Tato koncepce umožňuje snadné a rychlé nastavení i velmi komplikovaných bezpečnostních pravidel a především pak jejich rychlou operativní změnu. Změní-li se např. pozice nějakého uživatele v hierarchii společnosti, stačí mu pouze přiřadit role odpovídající jeho nové pozici a tímto jednoduchým přiřazením se uživateli v okamžiku přiřadí celý komplexní balík práv a omezení odpovídající jeho nové pozici.
Systém pro vývoj distribuovaných aplikací Plaant
5.2
237
Vytvoření kostry aplikace v Plaant Tools
Datová struktura Po analýze nastupuje návrh kostry aplikace. Návrhář aplikace, který nemusí být programátor, navrhne za pomoci programu Plaant Tools základní objektové schéma, tj. definuje, které agendy bude aplikace obsahovat a jaké údaje v nich budou uloženy. Součásti zadávaných informací je i to, zda se má vyžadovat zadání hodnoty, v jakém rozsahu hodnot se smí zadávané hodnoty pohybovat a případně i vzor (šablona) pro vstup i zobrazování dat. Při té příležitosti vývojář také definuje strom případných dědičností jednotlivých agend a vložení obsahu jedné agendy do druhé jako její komponenty. Jak jsme již řekli, návrhář se při tomto návrhu nemusí zabývat definicí nějakých pomocných tabulek, protože ve většině případů mu stačí pouze odsouhlasit, že zadání vyhovují ty tabulky, které pro takovéto účely definuje Plaant automaticky. Má-li však návrhář nějaké nestandardní požadavky, může zadáním příslušných parametrů tvorbu těchto tabulek samozřejmě ovlivnit. Formuláře Současně s datovým obsahem agend navrhne vývojář v této etapě i podobu budoucích formulářů. Tuto podobu sice nedefinuje pomocí nějakého WYSIWYG návrháře, ale prostřednictvím nastavení různých parametrů. V každém okamžiku však má možnost zkontrolovat, jak bude navržený formulář vypadat jak v desktopové, tak ve webové verzi GUI. WYSIWYG návrhář není v systému použit především proto, že se s jeho pomocí špatně nastavuje vzhled formuláře pro několika výrazně odlišných platforem současně (např. pro desktopovou aplikaci, pro webovou aplikaci a pro PDA). Byla proto dána přednost koncepci, při níž tvůrce nedefinuje přesnou konečnou podobu GUI, ale zadává pouze parametry definující sdružování zobrazovaných objektů do větších skupin a vzájemnou relativní pozici těchto objektů a skupin. Součástí definice formuláře je jak specifikace druhu použitého prvku (vstupní pole, rozbalovací seznam, přepínač, skupina odkazů, …), tak popis rozmístění a rozměrů prvků zobrazujících jednotlivé datové položky, tak sada doplňujících informací, které specifikují, zda bude zobrazovaná hodnota zadávána uživatelem nebo počítána systémem, zda bude požadováno její povinné zadání, kontrola povolených hodnot, šablona pro zadávané hodnoty a některé další informace. Lokalizace Součástí základního návrhu je i lokalizace používaných pojmů pro jednotlivé jazykové mutace. Aplikace pak při přihlášení každého klienta připraví svoji lokalizovanou mutaci podle lokality nastavené v klientském systému, případně zadané ve spouštěcím příkazu. Výstupy Plaant Tools Na základě informací zadaných ve výše popsaných fázích vytvoří Plaant Tools sadu XML souborů, do nichž vloží informace o jednotlivých funkčních segmentech aplikace, odpovídajících datových strukturách a klientském uživatelském rozhraní. Tyto
238
Rudolf Pecinovský, Vladimír Lahoda
soubory aplikace při svém spouštění načte a podle získaných informací vše potřebné nastaví. Současně Plaant Tools připraví skripty pro použitý RDBMS (Relational Database Management System). Tyto skripty zabezpečí vytvoření potřebných tabulek v databázi, a to jak tabulek s informacemi potřebnými pro vlastní činnost aplikace, tak tabulek pro uložení uživatelských dat. Nejedná-li se o počáteční návrh, ale modifikaci nějakého staršího návrhu, generuje Plaant Tools skripty, které pouze modifikují stávající databázi, aniž by přitom došlo ke ztrátě dat. 5.3
Další „neprogramové“ části návrhu
Stavové diagramy Součástí návrhu aplikace mohou být i stavové diagramy specifikující stavy, kterými mohou procházet záznamy jednotlivých agend, možné operace s daty v jednotlivých stavech záznamu i operace, které se spouští při přechodu záznamu z jednoho stavu do druhého (např. automatické odeslání mailu po vypršení doby splatnosti faktury). Stavový diagram může vývojář navrhnout v jakémkoliv nástroji pro kreslení UML diagramů, který je schopen ukládat diagramy ve standardizovaném formátu XMI. Tyto diagramy pak aplikace při svém spouštění načte a podle získaných informací nastaví potřebné vnitřní parametry. Generátor sestav XANDY Většina aplikací se neomezuje pouze na komunikaci s uživatelem prostřednictvím obrazovky, ale součástí zadání je i schopnost generace nejrůznějších sestav. Poměrně propracovaný, nicméně jednoduše ovladatelný generátor sestav je součástí každé aplikace a může jej použít kterýkoliv uživatel, a to zejména při vytváření některých speciálních (často jednoúčelových) sestav, případně pro export tabulkových dat. Pro opravdu náročné sestavy, u nichž je požadováno propracované formátování, se však nehodí. Takovéto sestavy je třeba navrhnout ve fázi návrhu aplikace. Pro návrh sestav a dalších složitě formátovaných dokumentů byl vyvinut program XANDY, což je specializovaný XML editor podporující tvorbu formátovaných dokumentů ve WYSIWYG režimu. Výstupem tohoto programu je opět sada XML dokumentů, které si aplikace při svém spuštění načte. 5.4
Programové doladění
Pro všechny doposud popsané činnosti nebylo potřeba, aby měl vývojář nějaké programátorské znalosti a zkušenosti. Nicméně prakticky každá aplikace vyžaduje jisté schopnosti a funkce, které se pomocí výše popsaných nástrojů zabezpečit nedají. Tyto schopnosti bychom mohli rozdělit do dvou skupin: na spouštěče (triggery), které jsou automaticky spouštěny při nějaké události (vytvoření záznamu, uložení záznamu, …), a speciální funkce, které jsou přístupné uživateli. Všechny se vyvíjejí za pomoci standardních nástrojů pro vývoj aplikací v jazyce Java a pro jejich vývoj je potřeba, aby měl vývojář jisté programátorské zkušenosti a znal API systému Plaant.
Systém pro vývoj distribuovaných aplikací Plaant
239
Spouštěče (triggery) Pro každou agendu je možno definovat její vlastní třídu, která obsahuje předem danou sadu metod automaticky spouštěných při předem známých událostech, jakými jsou např. otevření nového prázdného záznamu (zde se většinou předvyplní některá pole), uložení nově vytvořeného záznamu (v tuto chvíli se provádí řada nestandardních kontrol, tj. těch, které není možno nastavit v programu Plaant Tools), otevření existujícího záznamu, uložení modifikovaného záznamu, změna hodnoty sledovaného pole, nastavení speciálního filtru, atd. atd. Speciální funkce Speciální funkce realizují buď operace, které může uživatel přímo spouštět stiskem příslušného tlačítka v aplikačním okně (každá uživatelem spustitelná speciální funkce má v okně vlastní tlačítko), nebo operace automaticky spouštěné např. při přechodu mezi jednotlivými stavy dokumentu. Uživatelem spouštěné operace jsou většinou koncipovány jako průvodci, kteří uživatele nejprve požádají o přesnější specifikaci jeho požadavků a na závěr provedou požadovanou operaci. 5.5
Příprava nasazení aplikace
Před nasazením aplikace je třeba definovat role, specifikovat práva a omezení kladená na jednotlivé role, připravit uživatelská konta, přiřadit uživatelům jejich role a nastavit výchozí podobu uživatelského rozhraní pro jednotlivé skupiny uživatelů. K tomu slouží program Plaant Commander, jehož uživatelské rozhraní je podobné klasickým souborovým správcům odvozeným od programu Norton Commander, a to včetně nejznámějších klávesových zkratek. Jeho ovládání je proto pro většinu správců naprosto intuitivní a nemívají s ním problémy.
6
Závěr
Nasazení systému Plaant přináší řadu konkurenčních výhod. Jedny z nejvýraznějších jsou výhody při vývoji. Vývoj rozsáhlých podnikových aplikací je totiž vysoce odborně i časově náročný a tím také velmi drahý. Použití systému Plaant umožní mnohé z této náročnosti výrazně eliminovat. Zkušenosti získané při použití tohoto systému u několika velkých zákazníků ukazují, že jeho nejdůležitější výhody, které se projeví při vývoji systému, jsou: • Doba od počátku vývoje do výsledného zprovoznění aplikace nebo jejího uvedení na trh se zkrátí o 30 %. • Počáteční vývojové náklady se sníží o 25 až 40 %. • Použití systému dokáže výrazně snížit požadavky na kvalifikaci a předchozí zkušenost vývojářů. • Vývojové náklady během celého životního cyklu aplikace se sníží v průměru o 40 až 60 %. • Systém Plaant umožňuje snadnou a především rychlou úpravu uživatelského rozhraní podle měnících se požadavků uživatelů.
240
Rudolf Pecinovský, Vladimír Lahoda
• Systém Plaant umožňuje vývojářům vyvíjet uživatelské rozhraní pouze jednou. Systém pak sám realizuje potřebné modifikace pro jednotlivé typy klientů. Aplikace vyvinuté pod systémem Plaant jsou nejenom vyvinuté rychle a levně, ale nabízejí zároveň široké možnost při následné správě systému a vysokou variabilitu při nastavování nejrůznějších okrajových podmínek a požadavků. Koncovým uživatelům pak nabízí rozsáhlé možnosti individuálního přizpůsobení aplikace jejich konkrétním okamžitým potřebám a možnost kdykoliv snadno upravit výchozí uživatelské nastavení.
Annotation In the custom development of distributed enterprise applications we encounter typical set of repeating requirements. Therefore we developed system Plaant as the tool for development and following management of distributed database applications. The tool, which significantly decreases their total cost of ownership. At the same time it decreases the demands for developers qualification and experience. The system is built on the J2EE platform and offers the large set of unique and sophisticated features and functions. Besides the possibility of simple definition of the basic forms, which are automatically adapted for different types of clients (thin client, web interface, mobile phone, …) it also offers sophisticated functions for control of the documents workflow and for preparing of the complex reports for different targets (printer, comfortable graphical output, web service, …).
Použití transformací BORM v nástroji Použití transformacívv metodě metodě BORM v nástroji Craft.CASE 2.x Craft.CASE 2.x 1 1 Marek Pícka Robert Pergl Marek Pícka,, Robert Pergl 1
Katedra inženýrství, Provozně ekonomická fakulta,fakulta, Česká zemědělská univerzita Katedrainformačního informačního inženýrství, Provozně ekonomická Česká zemědělská v Praze, Kamýcká 129, 165 21 Praha 6 univerzita v Praze {picka,pergl}@pef.czu.cz {picka, pergl}@pef.czu.cz Abstrakt. Cílem tohoto článku je ukázat praktické použité principu transformací mezi prvky v metodě BORM a navrhnout praktický postup jak tento princip implementovat do nástroje Craft.CASE. Klíčová slova: metoda BORM, model, CASE, Craft.CASE, transformace, model metody
1
Úvod
Úspěšná metodika analýzy a návrhu informačních systémů v poslední době v poslední době přestává být pouze souhrnem psaných návodů (metod), jak postupovat při analýze a návrhu informačního systému, ale stává se celým „balíkem“ zahrnujícím nejen metody, ale i k nim příslušející nástroje. Ústředním nástrojem jsou CASE (Computer Aided Software Engineering) nástroje. Kvalita tohoto CASE nástroje častokrát rozhoduje o úspěchu dané metodiky na trhu. Vývoj kvalitního CASE je však velmi náročný úkol. Mnoho metodik tento problém řeší tak, že jsou založeny na široce používaném standardu (u objektově-orientovaných metodik typicky UML) a používají nějaký „generický“ CASE určený pro tento standard. Používání standardů má své nesporné výhody (například jednotná notace, snadná srozumitelnost atd.), nevýhodou je však nevhodnost použití těchto obecných standardů v některých oblastech (například UML při procesním modelování). Je to daň jejich nutné obecnosti. Nevýhodou specializovanějších metodik, nezaložených na nejrozšířenějších standardech, je typicky horší podpora z hlediska nástrojů. Nástroje lze sice rychle navrhnout pomocí metod metamodelování (viz 11.) a následnč implementovat v mataCASE (říká se jim také CAME nástroje – Computer Aided Method Engineering) nástroji (viz 15.), ale kvalita metaCASE nástrojů při modelování nedosahuje kvalit specializovaných CASE nástrojů. Pro úspěch metodiky je třeba vyvinout specializovaný, uživatelsky přístupný CASE.
2
BORM
BORM (Business Object Relational Modeling – viz například 5. nebo 6.) je objektově orientovanou metodou analýzy a návrhu informačních systémů. Hlavní důraz klade na procesy probíhající v modelovaném systému, na jejich nalezení, analýzu a následné
c Václav Snášel, editor: Objekty 2005, pp. 241–254, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
242
Marek Pícka, Robert Pergl
modelování. BORM je iterativní metoda a je založena na spirálovém modelu návhu systému. Jednou z hlavních zásad BORMu je zachycení jeho pojmů jako pomocí postupných transformací. V BORMu je procesní model znázorněn jako soustava vzájemně komunikujících automatů. Tyto automaty představují business objekty. Příklad je na obrázku 1. Po namodelování všech procesů pomocí procesních diagramů je vytvořen procesní model. V tomto okamžiku mnoho projektů realizovaných v BORMu končí – BORM je častokrát používán pouze pro procesní analýzu, například pro potřeby reingeneeringu procesů.
Obrázek 1 Procesní diagram v BORMu – Object Relationship Diagram (ORD) Jako další krok může následovat transformace procesního modelu v model konceptuální. To je zidealizovaný objektový model vytvořený bez ohledu na implementační prostředí (viz obrázek 2). Jako grafický jazyk používá konceptuální model zjednodušený třídní diagram z UML (viz 7.). Posledním krokem je transformace konceptuálního modelu do implementačního prostředí a následná implementace. Tato transformace může být poměrně jednoduchá – při použití čistě objektově-orientovaného jazyku (například SmallTalku) a objektových databází , nebo složitější – například při použití relační databáze. Výhodou tohoto postupu je, že model zůstává co nejdéle implementačně nezávislý, implementačně závislá rozhodnutí se dělají až v závěrečné fázi.
Použití transformací v metodě BORM v nástroji Craft.CASE 2.x
243
Obrázek 2 Konceptuální diagram – základem je zjednodušený třídní diagram UML Jednou z nejdůležitějších příčin menší rozšířenosti metody BORM byla absence dobrého specializovaného CASE nástroje. Používal se buď MetaEdit (více 17) s implementovaným BORMem (více 4.) nebo Visio. V MetaEditu se dobře udržovaly souvislosti v modelu, ale jako kreslící nástroj a z hlediska uživatelské přítulnosti MetaEdit nevyhovuje. Nevýhodou byle také jeho vysoká cena a malá rozšířenost a dostupnost. Visio je pouze kreslítko a nešlo ho používat jako repositář modelu. Nedostupnost kvalitního CASE nástroje se změnila příchodem Craft.CASE.
3
Craft.CASE
Craft.CASE je původní český modelovací a analytický CASE nástroj podporující metodu BORM, která je založena na kombinaci objektově orientovaného přístupu a procesního modelování. Nástroj vzniká ve firmě e-Fractal s.r.o. na zakázku pro mezinárodní poradenskou a konzultační firmu Deloitte & Touche (uživatele a spolutvůrce BORMu). Program je napsán v prostředí VisualWorks/Smalltalk a je určen pro použití ve Windows 2000 a XP. Craft.CASE podporuje procesní (business) , konceptuální analýzu i vlastní návrh informačního systému. Umožňuje modelovat systém po celý cyklus jeho návrhu – jeho procesní model (pomocí object relationship diagramů), konceptuální model (konceptuální diagram – zjednodušený třídní UML) a případně implementační diagram (třídní UML diagram). Nástroj Craft.CASE se rozvíjí – v současnosti je aktuální verze 1.2. Jednotlivé verze vznikaly jednak přidáváním nových vlastností, reakcí na požadavky uživatelů a opravou chyb. Craft.CASE byl již s úspěchem nasazen v praxi – největší projekt, pro
244
Marek Pícka, Robert Pergl
který byl použit obsahoval cca 15 funkcí, 30 scénářů a k nim příslušející 20 procesních diagramů. Model dále obsahoval cca 40 participantů.
Obrázek 3 Craft.CASE – úvodní menu
3.1
Současný stav – Craft.CASE 1.x
Postupně vznikly tyto verze Craft.CASE: • • •
Verze 1.0 – úvodní verze. Zahrnovala business (viz obrázky 1 a 3) i konceptuální modelování (ukázka na obrázku 2), generování chybových reportů Verze 1.1 – rozšířeno o simulátor procesů (viz obrázek 5) a možnost vytváření hierarchií (viz obrázek 4) a diagramů softwarové a business architektury. Verze 1.2 – zejména přidány nové možnosti exportu a generování dokumentace.
Obrázek 3 Craft.CASE – procesní modelování, seznam scénářů
Použití transformací v metodě BORM v nástroji Craft.CASE 2.x
Obrázek 4 Craft.CASE – business hierarchie
Obrázek 5 Craft.CASE – simulace scénářů
245
246
Marek Pícka, Robert Pergl
Chyby v Craft.CASE 1.x Craft.CASE verzí 1.x je vyspělý a použitelný nástroj, ale obsahuje některé chyby, které jsou neopravitelné, tedy přesněji neopravitelné bez ztráty kompatibility datových souborů mezi verzemi. Jde zejména o chyby v metamodelu. S těmito chybami lze Craft.CASE používat, ale analytik používající Craft.CASE musí ještě dodržovat další pravidla (jako například, že nesmí nakreslit z akce dvě šipky). Situace porušující tato pravidla lze sice nakreslit, ale tyto situace odporují logice metody BORM a to se projeví například v tom, že taková scénář nejde odsimulovat-
Obrázek 6 Craft.CASE – chybně navržený metamodel Jedna z chyb v metamodelu je znázorněna na obrázku 6. Přechod mezi stavy je vytvořen pomocí prvků vlastnictví (ownership), akce (action) a přechodu (transition). To umožňuje mít z akci s více přechody (transition). Jedno ze správných řešení je mít přechod mezi dvěma stavy a součástí přechodu bude i akce. Stav i akce je vlastněn prvkem stavový stroj, který lze je skládán se stavem nebo rolí participantu (tím jsme vyřešili problém stavových podstrojů). 3.2
Budoucnost – Craft.CASE 2.x
Hlavním cílem verze 2 Craft.CASE je odstranění hlavních nedostatků předcházejících verzí, které nejdou z principiálních důvodů odstranit ve verzích 1.x. Nejdůležitější nové vlastnosti Craft.CASE verze 2 budou: • Zvýšení uživatelské příjemnosti – zejména zavedení funkcí Undo a Redo. • Možnost spolupráce v týmu – zavedení společného síťového repositáře (nejdříve nad databází Gemstone) • Zlepšení možností exportu modelu a možností generování dokumentace. • Změny v metamodelu – kompletní předělání metamodelu Craft.CASE. • Zlepšení možností automatické kontroly modelu. • Zavedení transformací – implementování principů pčechodů mezi pojmy a transformací prvků do Craft.CASE. To umožní zejména lepší kontrolu správnosti modelu a definici transformací modelu. Například umožní definovat refaktorovací transformace (refaktorování do návrhových vzorů) a jejich (polo)automatické provedení. Tímto posledním bodem (transformacemi) se budeme zabývat zbytek článku.
Použití transformací v metodě BORM v nástroji Craft.CASE 2.x
4
247
Princip postupných transformací
Tvůrce informačního systému postupuje při vytváření jeho modelu tak, že postupně přidává jednotlivé nové prvky do již existujícího modelu. O tom, jaký nový prvek přidá do modelu se rozhoduje na základě již existujících prvků modelu – nový prvek tedy vzniká transformací již existujících prvků. Typ prvku (tj. v našem názvosloví pojmu) tvůrci modelu předepisuje metoda podle které pracuje. 4.1
Definice použitých pojmů
Pro lepší pochopení následujícího textu si definujeme nové pojmy s kterými budeme dále pracovat: • Pojem (anglicky concept) – je entita, s kterou pracujeme v rámci metody (či metodiky). Příkladem pojmů jsou: třída, package, use-case, funkce, scénář, stav, aktivita atd. Pojmy jsou obsaženy v metamodelu metody. • Přechod (přeměna) mezi pojmy (anglicky transition)– je to možná přeměna (několika) pojmů na nové pojmy, která je dovolená metodou. Tyto přechody definují návaznosti v metodě. • Model (možných, dovolených?) přeměn (přechodů) pojmů metody (či zkráceně model metody) – je model zachycující všechny pojmy metody a vzájemné, metodou dovolené, přechody mezi nimi. Tento model je vyjádřen pomocí diagramu přechodů (přeměn) pojmů metody. • Prvek (anglicky element) – je instancí pojmu. Reprezentuje konkrétní, dále již nedělitelnou, část modelu informačního systému. Prvek je uložen v repositáři modelu. Prvkem může být například konkrétní třída, metoda, funkce, scénář atd. Nový prvek v modelu vzniká transformací z již existujících prvků v modelu. Speciální prvky jsou tzv. vstupní prvky, které jsou do modelu vloženy zvnějšku, typicky jako důsledek analýzy zadání a potřeb. • Transformace mezi prvky – je instancí přechodu mezi pojmy. Transformace mezi prvky je proces pomocí něhož vznikají nové prvky v modelu ze stávajících. Transformace mezi prvky je předepsána svým příslušejícím přechodem. Všechny uskutečněné transformace jsou zaznamenány v repositáři modelu. • Záznam transformací prvků – je vrstva modelu, která zachycuje všechny uskutečněné transformace v modelu. Tento záznam zachycuje „rodokmen“ všech prvků modelu (tj. vztahy typu předchůdce-následník mezi prvky modelu). Je vyjádřena příslušným diagramem. 4.2
Postupná konstrukce modelu informačního systému
Postupné modelování informačního systému v malých krocích (pro zajištění kontextu a relevance), lze chápat jako postupné přidávání nových prvků do existujícího modelu. Pro zajištění správnosti navrhuji dodržovat tyto zásady:
248
Marek Pícka, Robert Pergl
1. 2.
3.
Každý nový prvek, přidávaný do modelu informačního systému, musí mít smysl. Každý nový prvek musí vzniknout relevantní (pro daný okamžik a dané prvky) transformací z již v modelu existujících prvků (vztah předchůdce – následník). V modelu existují tzv. vstupní prvky, které v modelu nemají žádného předchůdce a vznikly přímo ze zadání. U těchto prvků je třeba dát co největší pozor na jejich správnost, protože na nich závisí celý další návrh informačního systému (když jsou špatné základy, je špatná celá stavba).
Pokud budu dodržovat tyto zásady, tak zkonstruuji jednak model, a také novou vrstvu modelu, která bude ukazovat jaké prvky z kterých prvků vznikly a bude zaznamenávat transformace mezi nimi (bude k dispozici rodokmen všech prvků v modelu). Pokuď budu původ všech prvků (jejich rodičovské prvky), tak mi to poskytne silný nástroj ke kontrole relevance těchto prvků. Object-Relationship diagram 1 Funkce Referenti používají auta na služ. cesty
Scénář
Funkce
Podání žádosti o auto
Participant
Třída
Referent
Referent
Participant
Akce
Metoda
Požaduje auto
zadejAuto
Vedoucí
Vedoucí potvrzují žádosti zam. o auto
Akce Dostává potvrzení žádosti
Diagram tříd
Participant Funkce
Scénář
Autoprovoz přiděluje auta zaměstnancům
Výběr služebního auta
Vedoucí autoprovozu
Stav Čeká na rozhodnutí vedoucího
Participant Auto
Diagram funkcí a scénářů
Object-Relationship diagram 2
Obrázek 7 Vztahy mezi prvky části is autoprovozu pomocí BORMu
4.3
Vlastnosti záznamu transformací prvků
Pokud bude model informačního systému vytvářen pomocí výše zmíněných principů, potom budeme moci: • Zajistit konzistenci vyvíjeného informačního systému. • Lépe dokumentovat průběh vytváření informačního systému. • Kontrolovat vytvářený model pomocí pravidel uvedených výše. • Lokalizovat změny – pokud nastane změna v už existujícím projektu, tak lze snadno určit všechny prvky, kterých se tato změna týká (jsou to všechny ty, které vznikly ze změněného prvku řetězem transformací). Konstrukce modelu transformací bez dalších znalostí je obtížná jak na zjištění předchůdců prvku, tak je velmi pracná. Je zde nebezpečí, že tvůrce informačního systému přestane výše uvedená pravidla dodržovat, nebo je bude provádět pouze formálně.
Použití transformací v metodě BORM v nástroji Craft.CASE 2.x
4.4
249
Model přechodů mezi pojmy metody
Při vlastním návrhu informačního systému nám konstrukce záznamu transformací prvků pomáhá pouze omezeně. Výše uvedené zásady nám pouze říkají, že do modelu nemůžeme přidávat nové prvky libovolně – každý nově přidávaný prvek do modelu má svého předchůdce. To nutí návrháře přemýšlet o kontextu každého nově přidávaného prvku a tím snižovat pravděpodobnost chybného návrhu, ale neradíme mu, jakou transformací tento nový prvek vzniká. Tedy, při návrhu informačního systému by se hodilo vědět, jaké prvky mohou v daném kontextu vzniknout. Potřebujeme tedy určit možné transformace. Vznik nových prvků je řízen metodou analýzy a návrhu informačního systému. Tato metoda určuje jaké transformace mohu v daném kontextu použít a jaké nové prvky mohou vzniknout. Potřebujeme tedy umět znázornit pojmy používané v metodě a možné přechody mezi nimi. Potřebujeme vytvořit „data-flow“ model metody. Tento model jsme nazvali model přechodů mezi pojmy metody. 4.5
Diagram přechodů mezi pojmy metody – ukázka
Pro názornost si ukážeme nejdříve příklad modelu transformací mezi pojmy metody. Pro jednoduchost jsme zvolili transformaci mezi Chenovým entitně-relačním diagramem a fyzickým modelem relační databáze. Tato transformace dobře známá a často používaná a (téměř) každý CASE nástroj používaný pro modelování relačních databází jí provádí automaticky. Nejdříve si připomeneme jak probíhá: 1. 2.
3. 4.
Všechny entity převeď na tabulky. Pokuď je relace mezi entitami binární a typu 1:N a bez atributů, potom transformuj relaci na nový atribut (cizí klíč) a přidej ho k atributům tabulky u které je N. Pokud je relace typu 1:1 přidej cizí klíč k jedné z tabulek. Jinak převeď relaci na tabulku, k jejímž atributům přidej cizí klíče ukazující na tabulky, mezi kterými je relace. Převeď zbývající atributy u entit a relací na atributy u tabulek.
Tento slovní popis je znázorněn pomocí diagramu transformací pojmů metody na obrázku 2. Je zde vidět, že (jedna) entita se transformuje na (jednu) tabulku. Relace se může transformovat buď na atribut (cizí klíč), nebo na tabulku s dvěma nebo více (podle stupně relace) cizími klíči (atributy). Atributy u entit a relací se transformují na atributy u tabulek.
250
Marek Pícka, Robert Pergl
Entita
1 1
Tabulka
1
Relace
1
2..*
Atribut
1
1
ERAtribut
1
Obrázek 8 Model transformací pojmů metody transfornace ER konceptuálního diagramu do fyzického relačního diagramu Výše uvedený slovní popis lépe vyjadřuje algoritmus, ale diagram přehledněji znázorňuje vztahy a možnosti v transformaci. Tuto transformaci je možno provádět automaticky, protože známe její přesný algoritmus (viz např. 1). Toto však v metodologiích analýzy a návrhu informačních systémů není typické. V nich typicky známe vztahy mezi pojmy metodiky (tj model metodiky), ale konkrétní realizaci těchto vztahů volí analytik podle své zkušenosti. 4.6
Použití modelu přechodů mezi pojmy
S metodou analýzy a návrhu informačních systémů zachycenou pomocí modelu přechodů mezi pojmy je možno: • Řídit vývojový proces metodou – v každém okamžiku jsem schopen určit, jaké transformace mi metoda dovoluje v daném okamžiku použít (lze například vytvořit CASE nástroj, který bude nabízet možné transformace). Vím, kolik a jaké prvky v příštím kroku metody mohou vzniknout. • Kontrolovat, jestli vytvářený model informačního systému odpovídá použité metodě. Je možno v kontrolovat, zda prvek přidaný do modelu odpovídá metodě. • Takto definovaný zápis mi pomůže pro případné provádění některých transformací automaticky či poloautomaticky. Pro automatické a poloautomatické provádění transformací musím doplnit algoritmus, pomocí kterého si transformaci definuji (viz odkaz). • Znázornit průběh metody – tento model lze použít k definici vztahů v metodě a to lze využít například k snazšímu pochopení vztahů v metodě, k výuce metody atd.. • Kontrolovat a vylepšovat metody – tím že, mám definovány všechny pojmy a přechody v metodě, jsem schopen zkontrolovat, jestli přechod mezi prvky není příliš hrubý (tj. například v extrému netransformuje přímo zadání na výsledné třídy), nebo příliš jemný.
Použití transformací v metodě BORM v nástroji Craft.CASE 2.x
5
251
Přechody mezi pojmy v metodě BORM
0..1
Datový Tok
0..*
1
1
ISA
1
1
Asociace
1
0..*
Akce
Přechod 0..*
Vazba
0..*
Scénář
1
1..*
Obrázek 9 Model transformací pojmů metody BORM
1
Dědění
Skládání Komunikace
1
0..*
Množina
Třída Stav 0..*
1 1..* 0..* 1..*
1..*
Participant Funkce
1
1
1..*
Role Participantu
0..*
0..*
1
0..*
Objekt
1
1..*
1
1
Metoda
Metoda BORM je přímo založena na principu postupných přechodů mezi pojmy, takže vytvoření jejího diagramu přechodů mezi pojmy je poměrně jednoduché (více 14.). Výsledek je znázorněn na obrázku 9.
252
6
Marek Pícka, Robert Pergl
Návrh implementace transformací v CraftCASE 2.x
Do Craft.CASE potřebujeme zavést transformace zejména pro možnost dobré kontroly modelu a tím udržení jeho správností a pro možnost zavedeni automatických a poloautomatických transformací mezi prvky modelu. Cílem je například mít možnost si označit skupinu tříd a zvolit si návrhový vzor, do kterého se mají tyto třídy transformovat. Následně proběhnou kontroly, zda je tato transformace možná a pak se (pokuď je přípustná) transformace provede. V návrhu implementace se zaměříme zejména na navržení celkové koncepce (tj. třídního modelu) a implementace kontrol v modelu. 6.1
Vlastní návrh
Implementace transformací do CASE nástroje lze dvěma způsoby. Jedem z nich je přímá implementace transformací. Vytvoříme novou vrstvu metamodelu s přechody odpovídající obrázku 9. Výhodou tohoto přístupu je jeho přímočarost a jednoduchost a nevýhodou je jeho nepružnost. Přechody v metamodelu jsou „natvrdo“ definované a nejdou měnit. To sice nevadí například u BORMu (kde jsou přechody mezi pojmy dané), ale vadí to například u metodik založených na UML – kde k transformaci můžeme použít různé metody v závislosti na použité metodice. Například k získání tříd můžeme použít buď analýzu podstatných jmen nebo např. CRC karty. Zde musíme zvolit pružnější způsob definice přechodů. Jeden z nich je do metamodelu přidat obecný prvek (odpovídající název našemu názvosloví je Pojem – Concept) od kterého jsou všechny prvky metamodelu zděděny a obecně definovat, že může existovat přechody (vyjádřené asociační třídou Přechod – Transition) typu M:N mezi Pojmy. Přechod je tedy sám třídou. Takto jsme definovali nekonečně mnoho přechodů mezi Pojmy a tak tyto přechody musíme omezit pouze na dovolené, odpovídající dané metodě. K omezení vlastností prvků modelu existuje jazyk OCL (Object Constraint Language – viz 7.), který je standardní součástí (i když ne moc využívanou) jazyka UML. Tento jazyk můžeme tedy s výhodou použít pro popis omezení jednotlivých přechodů nezi pojmy metody. Příklad pro definici omezení pro přechod mezi Scenarem, RoliParticipantu a Stavem, Prechodem nebo Akci (viz obrázek 9) je: (self.scenar->notEmpty() and self.roleParticipantu->notEmpty()) implies ((self.akce->size => 0) or (Self.stav->size => 0) or (self.prechod->size => 0)) V tomto výrazu určuji povolené násébnosti – ze scenare a roleParticipantu vzniká několik akcí nebo několik stavů nebo několik přechodů. Pro jednoduchost je výhodné v reálné implementaci zadávat podmínky ne přímo v jazyce OCL, ale převést je do implementačního jazyka. Tím je v našem případě SmallTalk. Jazyk OCL se naštěstí dá velmi lehce převést na SmallTalk a tak bude omezení zapsáno ve SmallTalku takto: (self scenar notNull and:
Použití transformací v metodě BORM v nástroji Craft.CASE 2.x
253
(self roleParticipantu notNull) implies: (self akce size >= 0 or: self stav size >= 0 or: self prechod size >= 0) Návrh struktury uchovávající tyto omezení je na obrázku 10. Poj em
Transformace
AutomTransformace
PoloAutomTransformace
Podminka
ObecnaTransformace
Obrázek 10 Navrh části struktury repozitáře
7
Závěr
Zavedením transformací do transformací do CASE nástroje získáme vhodný prostředek k provádění automatických a poloautomatických transformací a ke kontrole konzistence modelu.
Reference. 1. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J: Návrh programů pomocí vzorů – Stavební kameny objektově orientovaných programů, Grada Publishing, Praha 2003, ISBN 80-247-0302-5 2. Gogolla M, Lindow A.: Transforming Data Model with UML, In: Knowledge Transformation for the Semantic Web. IOS Press, Amsterdam 2003, ISBN 158603-325-5 3. Lenárt, L., Skála, P.: Comet, první původní CASE nástroj pro metodu BORM. In: Objekty 2004 – sborník příspěvků devátého ročníku konference, Fakulta elektrotechniky a informatiky, VŠB TU, Ostrava 2004, ISBN 80-248-672-X 4. Merunka V.: Implementace metody BORM v nástroji MetaEdit Plus Workbench verze 3.0 na příkladu diagramu ORD. In: Objekty 1999 – sborník konference OBJEKTY 1999. Praha 1999.
254
Marek Pícka, Robert Pergl
5. Merunka V., Polák J., Carda A. Umění systémového návrhu – Objektově orientovaná tvorba informačních systémů pomocí původní metody BORM. Grada Publishing 2003, Praha. ISBN 80-247-0424-2 6. Merunka V., Pícka M., Pergl R.: Spojení business a informačního inženýrství pomocí metody BORM, In: Sborník 8. ročníku mezinárodního semináře Modelování a optimalizace podnikových procesů, Západočeská univerzita v Plzni, Plzeň 2005, ISBN 80-7043-352-3 7. Object Management Group (OMG), ed: OMG Unified Modeling Language Specification – version 1.5. 2003. http://www.omg.org 8. Object Management Group (OMG), ed: OMG MDA – Model Driven Architecture, OMG 2001, http://www.omg.org/docs/ormsc/01-07-01.pdf 9. Pícka, M.: Metamodel BORMu jako rozšíření metamodelu UML. In: Objekty 2003 – sborník příspěvků osmého ročníku konference, Fakulta elektrotechniky a informatiky, VŠB TU, Ostrava 2003, ISBN 80-248-0274-0 10. Pícka, M.: Definice omezení v metamodelu BORMu pomocí jazyka OCL. In: Mendelnet 2003 – sborník příspěvků z doktorandské konference, MLZU PEF, Brno 2003 11. Pícka, M.: Metamodeling and Development of Information Systems, Zemědělská ekonomika č.2, ročník 2004, Ústav zemědělských a potravinářských informací, Praha 2004, ISSN 0139-570X 12. Pícka, M.: Záznam procesu tvorby informačního systému. In: Sborník příspěvků z doktorandského semináře, Česká zemědělská univerzita, Provozně ekonomická fakulta, Praha 2004, ISBN 80-213-1150-9 13. Pícka, M.: Řízená tvorba modelu informačního systému. In: Objekty 2004 – sborník příspěvků devátého ročníku konference, Fakulta elektrotechniky a informatiky, VŠB TU, Ostrava 2004, ISBN 80-248-672-X 14. Pícka, M.: BORM z pohledu transformací pojmů. In: Sborník z mezinárodní vědecké konference Agrární perspektivy IX., Česká zemědělská univerzita, Praha 2005 15. Tolvanen, J.P.: Incremental Method Engineering with Modeling Tools – TheoreticalPrinciples and Empirical Evidence. PhD Thesis. University of Jyväskylä. Jyväskylä 1998. 16. webová stránka programu Craft.CASE: http://www.craftcase.com 17. webová stránka programu MetaEdit: http://www.metacase.com Annotation Using transformation in BORM method in Craft.CASE version 2 The aim of this article is show practical using of principle of transformation among elements in BORM methodology and design practical way to implement this principle into Craft.CASE.
Standardy webovýchslužeb služeb StandardyXML XML webových Martin Smítka Martin Smítka Katedra PEF,ČZU ČZU Praha Katedrainformačních informačních technologií, technologií, PEF, Praha [email protected][email protected]
Abstrakt. Standardy pro oblast webových služeb založené na XML jsou v současnosti velmi často vyzdvihovány pro jejich přínos k rozšíření webových služeb. V této práci je představen obecný pohled na standardy popisující rozhraní webových služeb a jejich vzájemnou komunikaci s ohledem na dosah těchto standardů a jejich vlivu na komunikaci. Klíčová slova: XML, Webové služby, standardy, Orchestrace, Choreografie
1
Úvod
Prostředí WWW (World Wide Web) je stále častěji využíváno jako prostředek komunikace mezi aplikacemi. Rozhraní těchto aplikací jsou označována jako webové služby. Při užším vymezení Webových služeb se jedná o aplikace, které využívají standardy odvozené z XML (eXtensible Markup Language). Právě XML je označováno jako nejvýraznější standard, který umožnil tak široké rozšíření webových služeb. Tento standard sám o sobě nestačí pokrýt širokou řadu problémů komunikace a je tak rozšiřován o doplňující specifikace. Ani v současné době však nejsou některé oblasti zcela pokryty a dořešeny.
2
Základní standardy
Webové služby využívají pro přenos zpráv již osvědčené stávající standardy Internetu a WWW, z nichž mezi nejdůležitější patří TCP/IP a HTTP (Hypertext Transfer Protocol). Nad těmito standardy jsou „položeny“ samotné Webové služby. Mezi základní aplikace XML (odvozené specifikace založené na XML) patří zejména XML Schéma, popisující základní a odvozené datové typy, a XPath a XML Namespaces, popisující způsob jednoznačné identifikace skupin značkování. Rozšiřující standardy SOAP
WSDL
XML Schéma, Namespaces... XML HTTP TCP/IP
Obr. 1 - Základní struktura standardů WS
c Václav Snášel, editor: Objekty 2005, pp. 255–260, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
256
Martin Smítka
Pro Webové služby jsou tyto standardy dále rozšiřovány ve specifikaci protokolu SOAP (Simple Object Access Protocol), který je v současné době fakticky nejrozšířenějším přenosovým protokolem. Mezi základní standardy webových služeb je řazen i UDDI (Universal Description, Discovery and Integration) sloužící k publikování informací o webových službách a k jejich nalezení. Samotná rozhraní jsou popsána pomocí strojově zpracovatelného formátu, v praxi nejčastěji WSDL (Web Services Definition Language). V případě popisu WSDL se jedná o popis statického rozhraní. Jsou definovány vstupní a výstupní operace, použité datové typy a jejich vazby. Použité jmenné prostory <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="The WSDL target namespace" Datové typy xmlns:s0="The WSDL target namespace” xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > Importovaná Schémata <message name="Žádost"> <part name="inPart1" element="s0:element ve Schématu" /> Přenášené zprávy <message name="Odpověď"> <part name="outPart1" element="s0:element ve Schématu" /> <portType name="NázevTypuPortu"> <soap:operation soapAction="" style="document" /> <soap:body use="literal" />
Obr. 2 - Struktura WSDL Uvedené základní standardy definují webovou službu jako samostatnou jednotku komunikačního procesu, bez jakýchkoli vazeb na ostatní Webové služby.
Standardy XML webových služeb
3
257
Rozšiřující standardy
Poté, co byly vyřešeny základní standardy webových služeb, se vývoj zaměřil na pokrytí dalších oblastí. Objevily se standardy rozšiřující zejména komunikační protokol a řešící problematiku přesahující samostatné webové služby. Příkladem takových standardů mohou být WS-Secuity, XML Signature, XML Encryption apod. V případě těchto standardů se však stále nejedná o řešení postihující komplexní operace složené z více zpráv jednotlivých webových služeb. Tyto rozšiřující standardy obohacují slovník značkování použitý v rámci SOAP zpráv a samozřejmě i implementaci ve vývojovém prostředí. Zároveň bohužel zvyšují celkovou složitost a počet vrstev protokolu. Je tedy vhodné je považovat za volitelnou součást prostředí webových služeb a jejich použití v konkrétních případech zvážit.
4
Skládání Webových služeb
Významnou charakteristikou webových služeb je jejich skládatelnost, tedy možnost využití Webové služby jinou webovou službou a vytvoření tak vyšší funkčnosti (obchodního procesu). V současné době se připravují otevřené standardy, které popisují chování webových služeb a oblast působnosti jednotlivých účastníků. Z pohledu vzájemných vztahů webových služeb lze rozlišovat mezi orchestrací a choreografií webových služeb. 4.1
Choreografie
Choreografie definuje pro dosažení obchodního procesu skládajícího se z více webových služeb posloupnosti a závislosti interakcí mezi rolemi. Choreografie popisuje spolupráci webových služeb, návaznost vztahů pro zprávy a podmínky, za kterých je konkrétní Webová služba vyvolána. WSDL popisuje statické rozhraní a choreografie popisuje dynamické chování vnějšího rozhraní. Na rozdíl od orchestrace nikdo “nevlastní” tok zpráv. Jedná se ve skutečnosti o architekturu peer-to-peer, kdy každá webová služba je samostatnou jednotkou, která není ovlivňována podmínkami ostatních služeb. 4.2
Orchestrace
Orchestrace vypadá na první pohled velmi podobně. Popisuje způsob, jak mohou webové služby vzájemně komunikovat na úrovni zpráv včetně obchodní logiky, a pořadí vykonávání interakcí. Tyto interakce mohou překračovat hranice aplikací (organizací) a vytvářet procesní model charakterizovaný transakcemi, delší dobou vykonávání a procesním modelem ve více krocích. Na rozdíl od choreografie se jedná o spustitelný proces, tedy formální popis, zpracovatelný orchestračním serverem. Jde tedy o architekturu klient-server. Místo zakomponování logiky posloupností do každé služby je workflow obsluhováno externě orchestračním serverem nebo integračním
258
Martin Smítka
brokerem. Orchestrační server se odlišuje od integračního brokeru pouze tím, že je speciálně navržený právě pro orchestraci. Vyčleněním workflow z webových služeb je každá webová služba použitelná samostatně. Variací orchestračního vzoru je agregační model, který jednotlivé webové služby zapouzdřuje do komplexních služeb. PELTZ[3] shrnuje technické požadavky na orchestraci: • Přizpůsobivost: Přizpůsobivost může být dosažena jasným oddělením procesní logiky a vyvolávaných služeb. Tohoto požadavku je obvykle dosaženo použitím orchestračního stroje, který se stará o celý procesní tok. • Základní a strukturované aktivity: Orchestrační jazyk musí podporovat aktivity pro komunikaci s ostatními webovými službami a řízení workflow. Za základní aktivitu lze považovat komponentu, která je ovlivňována z prostředí mimo vlastní proces. Strukturované aktivity řídí celkově toky procesů a určují, které aktivity budou vykonávány a v jakém pořadí. • Rekurzivní skládání: Jediný obchodní proces může být výsledkem použití několika webových služeb. Tento proces může být sám o sobě vystaven jako webová služba, což umožňuje v kombinaci s jinými vystavenými obchodními procesy vytvoření procesů vyšší úrovně PELTZ[3] dále shrnuje požadavky na správu celistvosti a soudržnosti interakcí: • Stálost a souvztažnost: Požadavek na schopnost uchovat stav v žádostech webových služeb je velmi důležitý, zejména při práci s asynchronními webovými službami. Jazyk a infrastruktura by měly poskytovat nástroje pro správu stálosti dat a vztahů požadavků a umožnit tím vytvářet komunikaci na vyšší úrovni. • Zpracování výjimek a transakcí: Webové služby používají prostředí webu a je tedy nutné zajistit řízení výjimek a integritu transakcí. 4.3
Standardy orchestrace a choreografie
Standardy řešící orchestraci a choreografii v současné době reprezentují zejména standardy velkých výrobců softwaru, např.: BPEL4WS (Business Process Execution Language for Web Services) je výsledkem průniku dvou proprietárních specifikací XLANG (Microsoft) a WSFL (IBM) vyvinutý firmami BEA, IBM a Microsoft. V současné době se o jeho vývoj stará OASIS (Organization for the Advancement of Structured Information Standards) WSCI (Web Services Choreography Interface) je společnou specifikací firem Sun, SAP, BEA a Intalio. BPML (Business Process Management Language) je specifikace neziskové organizace Business Process Management Initiative (BPMI.org). Doporučení konsorcia W3C WS-CDL (Web Services Choreography Description Language) je zatím ve fázi schvalování (Working Draft).
Standardy XML webových služeb
4.4
259
Společné prostředí webových služeb
S možností vytvářet obchodní procesy (skládané webové služby) se objevuje i problematika vyplývající z nutnosti spojit samostatně navržené webové služby do jednotného celku, aniž by bylo nutné do nich jakkoli zasahovat. V těchto případech je zřejmá výhoda orchestračních řešení, která využívají orchestrační server, jako společné prostředí všech webových služeb. Jedná se o takové oblasti, ve kterých je nutné využít nezávislého, důvěryhodného prostředníka, nebo kdy je nutné přenést výkon role mimo vlastní webovou službu. Příkladem takových oblastí mohou být např.: Sdílená úložiště, kdy by bylo možné využívat data mezi jednotlivými voláními nebo dokonce mezi jednotlivými obchodními procesy. Centralizovaná administrace pro vytváření souhrnných statistik, audit logů apod. Doručování zpráv ve smyslu garance doručení, nonrepudiace a sledování výjimek. Vynucování obchodních podmínek na základě měření spolehlivosti a výkonu služby. Proces standardizace prozatím v těchto oblastech není dokončen, popř. není řešen vůbec. Některé nedostatky lze řešit využitím stávajících nástrojů middleware např. pro messaging. Obecně lze říci, že proces standardizace je zde nejpomalejší.
5
Závěr
V této práci byly představeny webové služby z pohledu standardů, které upravují komunikaci založenou na XML. Tyto standardy byly rozčleněny do tří skupin, podle dosahů působnosti a schopnosti ovlivnit komunikaci. Základní standardy představují nejmenší společný jmenovatel všech služeb, tedy nezbytné minimum pro úspěšnou komunikaci. Jejich vývoj je z větší části ukončen a případné změny nebudou příliš zásadní. Rozšiřující standardy většinou rozšiřují komunikační protokol a řeší konkrétní oblasti komunikace, jako je bezpečnost, routing zpráv apod. Z pohledu působnosti se jedná o volitelná rozšíření, které musí obě strany komunikace podporovat. Specifikace upravující tyto standardy nejsou často v konečné podobě nebo se jedná o řešení skupin komerčních společností. Poslední skupinou jsou standardy pokrývající oblast nad úrovní samostatných webových služeb. Jedná se o takové oblasti, ve kterých je nutné využít nezávislého, důvěryhodného prostředníka, nebo kdy je nutné přenést výkon role mimo vlastní Webovou službu.
Reference 1. Myerson, J. M.,: Web Services Business Strategies and Architectures, [on-line], URL:
260
Martin Smítka
2. NGHIEM, A.: IT Web Services: A Roadmap for the Enterprise, New Jersey: Pearson Education, 2003, 313 s. ISBN 0-13-009719-5. 3. PELTZ, Ch.: Web Services Orchestration and Choreography, [on-line], URL: . 4. PELTZ, Ch:. Web Services Orchestration, [on-line], URL: 5. Srivastava, B., Koehler, J.: Web Service Composition - Current Solutions and Open Problems, [on-line], URL:
Annotation XML Web Services standards Standards for XML Web Services are for their benefit to widespread adoption discussed very often nowadays. In this thesis here is presented general classification of Web Services standards from the scope and influence to communication process point of view.
Metody odhadu složitosti Feature Point a Metody odhadu složitosti – Feature Point a Funtion Point Funtion Point Zdeněk Struska1 Zdeněk Struska 1 Katedra informačního inženýrství, PEF, ČZU Praha, Katedra informačního inženýrství, PEF, ČZU Praha, 165 21 Praha 6 - Suchdol 165 21 Praha 6 - Suchdol [email protected][email protected]
Abstrakt. Článek představuje dvě současné metody z oblasti odhadu složitosti. Jedna pro klasické informační systémy a druhá pro systémy objektového prostředí. V první části článku je popsána metoda IFPUG function point. V druhé části pak metoda SPR feature point. Obě metody včetně naznačení postupu jejich výpočtu. Dále jsou shrnuty společné vlastnosti nastíněných metod. Na závěr je nabídnuto srovnání těchto dvou metod a také autorův pohled na diskutovanou problematiku. Klíčová slova: metoda IFPUG funtion point, metoda SPR feature point, IFPUG, SPR, , External Inputs (EI), External Outputs (EO), External inQuiry (EQ), Internal Logica Files (ILF), External Interface Files (EIF), back-fire metoda.
1
Úvod
Přestože již existuje mnoho dílčích teoretických prací, které jednotlivě dokazují účelnost objektově orientovaného datového modelu v databázových systémech, tak se zatím v oblasti metod analýzy a návrhu objektových databázových aplikací vesměs používají jen postupy původně určené pro práci s relačními systémy a nebo jen intuitivní přístupy založené na zkušenosti s imperativními objektově orientovanými programovacími jazyky. Předpokládá se využití refaktoringu, návrhových vzorů a agilních metodik. Bohužel pro objektový datový model zatím není žádná všeobecně uznávaná a používaná technika nebo metoda návrhu, více [4]. Na základě předpovídaného vývoje v oblasti návrhu databázových systému se dá očekávat, že objektově orientovaný datový model postupně nahradí model relační. Jednou z významných nevýhod objektového prostředí je chybějící standardizace, která negativně ovlivňuje větší rozšíření objektově orientovaného modelu v praxi. Na nastalou situaci by měly včas reagovat obory, které přímo souvisejí s některou z fází návrhu informačního systému pomocí objektově orientovaných metod. Pokud si představíme časovou posloupnost jednotlivých fází, pak jako první je definování požadavků. Právě na startovní čáře tvorby informačního systému bývá velmi přínosné odhadnout budoucí cílový stav projektu. Ač se dá zcela důvodně pochybovat o přesnosti těchto odhadů, přesto existují metody, které v počátcích vývoje mohou tvůrcům softwaru částečně napomoci.
c Václav Snášel, editor: Objekty 2005, pp. 261–273, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
262
Zdeněk Struska
První metodou, která se pokusila odhadnout složitost informačních systému, byla metoda function point. Na ní úzce navazuje její současná platforma označovaná dle skupiny, která ji upravila, jako IFPUG (International Function Point Users Group). Jednodušší formou, která také vychází z původní metody function point ze sedmdesátých let minulého století je metoda označovaná jako SPR function point. Právě ta se stala základem pro expanzi metody function point do objektového prostředí. Výsledkem je metoda označovaná jako SPR feature point.
2
Function Point
Metoda vyvinutá A. Albrechtem v laboratořích IBM v polovině 70 let minulého století za účelem odhadu složitosti projektů informačních systémů [1]. Společným rysem metod funkčních jednic je to, že složitost odhadují jako součin dvou faktorů. Prvý faktor je založen na funkcích, které jsou od produktu vyžadovány, druhý na podmínkách, které pro vytvoření produktu objektivně jsou. Obecně je známo, že se jedná o poněkud problematický a neúplný podklad pro odhad složitosti, která jistě závisí na mnoha dalších faktorech, než pouze na rozsahu funkcí. Tyto faktory se mohou pro funkční jednice uplatnit pouze nepřímo.
Obr. 1: Grafické znázornění fungování metody function point
Definice pěti hlavních komponent Typy transakčních funkcí
Metody odhadu složitosti Feature Point a Funtion Point
°
263
EI (External Inputs) – je základním procesem, ve kterém data procházejí hranice z venku dovnitř systému. Data mohou pocházet z datové vstupní obrazovky nebo z jiné aplikace. Data mohou být využita k údržbě jednoho nebo více vnitřních logických souborů. Data mohou být buď kontrolními informacemi nebo obchodními informace. Jestliže se jedná o kontrolní informace, pak nemusí docházet k aktualizaci vnitřních logických souborů. Obrázek reprezentuje jednoduchý EI, který aktualizuje 2 ILF’s (FTR’s).
Obr. 2. – Grafické znázornění External Inputs
°
EO (External Outputs) – základní process, ve kterém získaná data přecházejí hranice systému z vnitřku ven. Dodatečně EO může aktualizovat ILF. Data vytvářející reporty nebo výstupní soubory posílané dalším aplikacím. Tyto reporty a soubory jsou vytvořeny z jednoho nebo více vnitřních a vnějších logických souborů. Následující obrázek reprezentuje na příkladu EO s 2 FTR’s, obrázek obsahuje také odvozenou informaci (zeleně), která byla odvozena z ILF’s.
Obr. 3. – Grafické znázornění External Outputs
°
EQ (External inQuiry) – základní proces se vstupními i výstupními komponentami, který výsledná data získává z jednoho nebo více vnitřních a vnějších logických souborů. Vstupní proces neaktualizuje žádné vnitřní logické soubory a výstupní strana neobsahují odvozená data. Níže umístěný obrázek reprezentuje EQ s dvěmi ILF’s a bez odvozených dat.
264
Zdeněk Struska
Obr. 4. – Grafické znázornění External inQuiry
Typy datových funkcí ° ILF (Internal Logical Files) – uživatelem identifikovatelná skupina logicky svázaných dat, která se sdílí pouze v rámci hranic aplikace a je udržována prostřednictvím vnějších vstupů. ° EIF (External Interface Files) – uživateli identifikovatelná skupina logicky svázaných dat, které jsou použity pouze pro referenční účely. Data jsou umístěna zcela mimo aplikaci a jsou udržována prostřednictvím jiné aplikace. Vnější logické soubory jsou vnitřním logickým souborem pro jiné aplikace.
3
IFPUG Function Point
Tato metoda vznikla v dílně neziskové organizace International Function Point Users Group (IFPUG). Jednoduše by se dalo říci, že je přímou pokračovatelkou původního konceptu z laboratoří IBM [9]. Po definování výše zmíněných funkcí, je při použití této metody každé funkci přidělen odhad její složitosti, jakási váha. jednoduchá – průměrná – složitá, založená na počtu datových položek, složitosti formátu, lidských faktorech, atd. 3.1
Výpočet IFPUG function point
1. Odhad systémových charakteristik (odhad CHS) Poté co byla každá komponenta zařazena mezi pět hlavních (EI’s, EO’s, EQ’s, ILF’s or EIF’s) a ohodnocena jako jednoduchá, průměrná nebo složitá. Přejde se k hodnocení transakcí (EI’s, EO’s, EQ’s), které je založeno na počtu aktualizovaných nebo referenčních (File Types Referenced – FTR’s) souborů a počtu prvků datových typů (Data Element Types – DET’s). Pro soubory typu ILF’s a EIF’s je jejich hodnota stanovena na základě dvou matic typů záznamových (Record Element Types – RET’s) a datových prvků (Data Element Types – DET’s). Typ záznamového prvku je
Metody odhadu složitosti Feature Point a Funtion Point
265
uživatelsky rozpoznatelná podskupina datových prvků v rámci ILF nebo EIF. Typ datového prvku je jedinečné uživatelsky rozpoznatelné, nerekurzivní pole. Každá z následujících tabulek participuje na klasifikaci procesu (číselné ohodnocení je v tabulkách). Např. EI, které odkazuje nebo aktualizuje 2 typy referenčních souborů (FTR’s) a má 7 datových prvků, by mělo přiděleno ohodnocení průměrné, s výsledným hodnocením 4. Kde FTR’s jsou kombinovaná čísla vnitřních logických souborů (ILF’s) referenčních nebo aktualizovaných a vnějších logických souborů. Tabulka 1: Hodnocení EI FTR's
DATOVÉ PRVKY 1-4
5 - 15
> 15
0-1
Nízký
Nízký
Prům
2
Nízký
Prům
Vysoký
3 nebo více
Prům
Vysoký
Vysoký
Tabulka 2: Společné hodnocení EO a EQ FTR's
DATOVÉ PRVKY 1-5
6 - 19
> 19
0–1
Nízký
Nízký
Prům
2-3
Nízký
Prům
Vysoký
>3
Prům
Vysoký
Vysoký
Tabulka 3: Hodnoty pro datové funkce ODHAD
HODNOTY EO
EQ
EI
Nízký
4
3
3
Prům
5
4
4
Vysoký
7
6
6
EQ’s jsou ohodnoceny a získány jako všechny komponenty. V podstatě EQ je hodnoceno (nízký, průměrný nebo vysoký) jako EO, ale přidělená hodnota odpovídá EI. Hodnocení je založeno na celkovém počtu unikátních (kombinující unikátní vstupní a výstupní strany) datových elementů (DET’s) a typech referenčních souborů (FTR’s) (kombinující unikátní vstupní a výstupní strany). Jestliže stejná FTR je užita na obou vstupních a výstupních stranách, pak dochází k počítání pouze v jeden
266
Zdeněk Struska
časový okamžik. Jestliže stejná matice DET je užita na obou vstupních i výstupních stranách, potom dochází k počítání pouze v jeden časový okamžik. Pro obě matice ILF a EIF – počet typů záznamových prvků a počet typů datových elementů jsou užity pro určení pozice jako nízký, průměrný a vysoký. Typ záznamového prvku je uživatelsky rozpoznatelná podskupina datových prvků v rámci ILF nebo EIF. Typ datového prvku (DET) je jedinečné uživatelsky rozeznatelné, nerekurzivní pole na ILF nebo EIF. Tabulka 4: Společné hodnocení ILF a EIF RET'S
DATOVÉ PRVKY 1 - 19
20 - 50
> 50
1
Nízký
Nízký
Prům
2-5
Nízký
Prům
Vysoký
>5
Prům
Vysoký
Vysoký
Tabulka 5: Hodnoty pro transakční funkce ODHAD
HODNOTY ILF
EIF
Nízký
7
5
Průměrný
10
7
Vysoký
15
10
Výsledek každé úrovně složitosti každého typu komponenty může být vložen do tabulky, tak jako následující. Každá vypočítaná hodnota je roznásobena číselným hodnocením s pevně stanovenou hodnotou. Vypočtené hodnoty jsou po řádkách sečteny, čímž je získána hodnota celého řádku každé komponenty. Sečtením tohoto sloupce je vypočten celkový počet nevyrovnaných funkčních jednic (viz. tabulka 6).
Metody odhadu složitosti Feature Point a Funtion Point
267
Tabulka 6: Tabulka pro výpočet celkového počtu funkčních jednic Typ komponenty
Složitost komponent
Nízký
Průměrný
Vysoký
External Inputs
__ x 3 = __
__ x 4 = __
__ x 6 = __
External Outputs
__ x 4 = __
__ x 5 = __
__ x 7 = __
External Inquiries __ x 3 = __ __ x 4 = __ Internal Logical Files __ x 7 = __ __ x 10 = __ External Interface Files __ x 5 = __ __ x 7 = __ Celkový počet nevyrovnaných (UFP)
Celkem
__ x 6 = __ __ x 15 = __ __ x 10 = __ funkčních jednic
Vynásobíme hodnotou vyrovnávacího faktoru Upravené funkční jednice celkem
2. Odhad charakteristiky podmínek vývoje – Vyrovnávací faktor (odhad CHP) Pro získání hodnoty upravených funkčních jednic, která je zobrazena v předposledním řádku tabulky 6., je nutné: ° zhodnotit 14 obecných charakteristik systému. Hodnocení probíhá pomocí stupnice od 0 do 5. (0 – faktor nemá žádný vliv, 5 – faktor má velmi významný vliv). Charakteristiky určují pracnost vývoje bez ohledu na podmínky, za kterých bude systém vyvíjen.
268
Zdeněk Struska
Tabulka 7: Charakteristiky systému Obecné charakteristiky systému Krátký popis 1
Datová komunikace
Kolik komunikačních zařízení podporuje přenos nebo výměnu informací s aplikací nebo systémem?
2
Distribuované zpracování dat
Jak jsou řízena, distribuovaná data a zpracování funkcí?
3
Výkon
Byla časová odezva nebo výkon v souladu s požadavky uživatele?
4
Intenzita konfigurace
5
Transakční míra
Jak často jsou transakce zpracovávány – denně, týdně, měsíčně, atd.?
6
On-line vkládání dat
Jaké procento informací je vkládáno on-line?
7
Výkonnost Byla aplikace navržena, aby zlepšila pracovní výkon koncového uživatele koncového uživatele?
8
On-line aktualizace
Kolik vnitřních logických souborů je aktualizováno online?
9
Složité zpracování
Disponuje aplikace rozsáhlým logickým a matematickým zpracováním?
10 Znovupoužitelnost
Byla aplikace vyvinuta, aby uspokojila jednu nebo více uživatelských potřeb?
využití Jaká je intenzita využití současné HW platformy, na které budou aplikace vykonávány?
11
Jednoduchost instalace
Jak složitá je úprava a instalace?
12
Provozní jednoduchost
Jak účinně a/nebo automatizovaně startována, zálohována a obnovena?
je
aplikace
13 Multifunkční využití
Byla aplikace speciálně navržena, vyvinuta a podporována, aby mohla být instalována pro multifunkční využití v rámci organizací?
14 Ulehčení změn
Byla aplikace speciálně navržena, podporovala lehké zavedení změn?
vyvinuta,
aby
Tímto krokem je odhadnut stupeň důležitosti každé charakteristiky a vlivu na celkový systém. Dále vypočteme hodnotu vyrovnávacího faktoru (VAF) tak, že ° sečteme ohodnocení (0-5) všech 14 obecných charakteristik. ° a součet vynásobíme 0,01 a následně přičteme 0,65. VAF = 0,65 + (suma obecných charakteristik systému x 0,01) 3. Odhad celkového počtu funkčních jednic
Metody odhadu složitosti Feature Point a Funtion Point
269
Výslednou hodnotu IFPUG function point získáme tak, že vynásobíme hodnoty vyrovnané a nevyrovnané části FP (viz. tabulka 6.): FP (IFPUG) = VAF * UFP.
4
SPR Feature/Function Point
Metoda SPR function point byla vyvinuta v roce 1986 organizací Software Productivity Research při experimentální aplikaci metody funtion point na logické softwarové systémy, např. operační systémy, systémy pro přepojování telefonních linek, real time software, MIS software a další. Původně byla metoda SPR function point určena k řešení problematiky měření klasických manažerských informačních systémů. Z tohoto původu pramení jejich nevhodnost využití pro vyjmenované oblasti: ° real time software – raketový obranný systém, ° systémový software – operační systémy, ° komunikační software – systémy pro přepojování telefonních linek, ° vnořený software – navigační balíčky, ° software kontroly procesů – systémy pro řízení rafinérií, ° strojírenské aplikace – CAD, CIM, diskrétní simulace, ° matematický software a další. Pokud na vyjmenované systémy použijeme metody function point, získáme také konkrétní výsledek. Nicméně ten se jeví jako matoucí pro software, který je vysoce algoritmicky složitý a zároveň rozptýlený do vstupů a výstupů. Z pohledu intuice a praktických výhod se jeví zřejmé, že tyto typy systémových softwarů vyžadují postup výpočtu, který bere v úvahu citlivé otázky týkající se vysoké algoritmické složitosti, a zároveň je blízký metodě function point. Podle výše vyjmenovaných nedostatků byla původní metoda SPR function point rozšířena tak, aby byla použitelná právě pro výše vyjmenované systémy. Vznikla tak metoda metoda SPR feature point, která zahrnuje SPR funtion point a bere v úvahu také šestý parametr – algoritmus. Ten je rozšířením původních pěti parametrů metody IBM function point. Parametru algoritmus je přidělena váha 3. Metoda feature point tedy omezuje empirické váhy vnitřních logických souborů z původní průměrné hodnoty 10 na průměrnou hodnotu 7. To reflektuje poněkud omezený význam vnitřních logických souborů u systémových softwarů vzhledem k systémům informačním. Algoritmus lze definovat jako množinu pravidel, které musí být vyjádřeny kompletně, aby řešily významné výpočetní problémy. Příkladem mohou být dva algoritmy – rutinní odmocňování nebo rutinní konverze Juliánských datumů.
270
4.1
Zdeněk Struska
Výpočet SPR feature point
Při využití metody SPR feature point není nutné zjišťovat počet typů datových prvků, typů referenčních nebo záznamových souborů. Zároveň se nevyžaduje ohodnocení jednotlivých funkcí pomocí ordinální stupnice (jednoduchý-průměrný-složitý). Na první pohled se tato metoda se jeví jako daleko jednodušší a poskytuje rychlejší odhad složitosti budoucího informačního systému. 1. Odhad hodnota nevyrovnaných feature point V případě odhadu hodnoty nevyrovnaných feature point jsou na výběr dvě možnosti. První je prostřednictvím metody back-fire a druhá je založena na klasickém postupu sčítání transakčních a datových funkcí. a) Back-fire metoda Metoda odhaduje funkční body na základě empirických vztahů objevených již existujících mezi zdrojovým kódem a function/feature point ve všech známých jazycích. Tato metoda je založena na tabulkách průměrných hodnot. Je využitelná v případech zpětného hodnocení dříve realizovaných projektů a pro uživatele, kterým jsou bližší metriky vycházející z řádků zdrojového kódu. Tab. 8: Odhad poměru zdrojový kód/FP pro jednotlivé programovací jazyky [6] Programovací jazyk
Zdrojový kód/FP
Assembler C COBOL Ada DB Languages Object Oriented Query Languages
320 128 107 70 40 29 25
Generators
16
b) součet funkcí V prvním kroku se stejně jako u metody IFPUG function point zjistí počet datových a transakčních funkcí a navíc ještě algoritmů, ten se dále roznásobí jakýmisi vahami dle tabulky 9. Po jejich sečtení se získá celkový počet nevyrovnaných feature point.
Metody odhadu složitosti Feature Point a Funtion Point
271
Tab. 9.: Postup výpočtu nevyrovnaných feature point Funkce
Váha
Celkem
EI EO EQ ILF EIF
_x4 _x5 _x4 _x7 _x7
= = = = =
Algoritmus
_x3
=
Celkový počet nevyrovnaných feature point (FC)
2. Odhad faktoru a multiplikátoru složitosti V dalším krokem je nutné se zamyslet nad odpovědí na dvě skupiny otázek v tabulce 10., první skupina se dotýká složitosti problému a druhá datové složitosti. Tab. 10: Složitost problému a datová složitost Složitost problému? 1 2 3 4
Jednoduché algoritmy a jednoduché výpočty? Většina jednoduchých algoritmů a výpočtů? Algoritmy a výpočty s průměrnou složitostí? Některé obtížné nebo složité algoritmy?
5 Mnoho obížných algoritmů a složitých výpočtů? Datová složitost? 1 2 3 4
Jednoduchá data obsahující málo proměnných? Četnost proměnných, ale jednoduché datové vztahy? Multiplikační soubory, pole a datové průniky? Složité struktury souborů a datové průniky?
5 Velmi složité struktury souborů a datové průniky?
Po zodpovězení vyjmenovaných otázek se vyberou dvě, které nejlépe charakterizují vznikající informační systém a jejich pořadová hodnota se sečte. Dle její výše se vybere z tabulky 11. příslušný multiplikátor složitosti. Tab. 11: Multiplikátor složitosti Složitost problému a datová složitost
2
3
4
5
6
7
8
9
10
Multiplikátor složitosti (CoM)
0,6
0,7
0,8
0,9
1
1,1
1,2
1,3
1,4
272
Zdeněk Struska
3. Odhad celkového počtu feature point Výsledný počet SPR feature points získáme: FP (SPR) = FC * CoM.
5
Feature nebo function point
Metody function point a feature point generují stejné početní výsledky u aplikací, kde je stejný počet algoritmů a logických datových souborů. Pokud budeme chtít odhadnout počet function nebo feature point u aplikací, které obsahují více algoritmů než souborů, ačkoliv se nejedná o neobvyklý systémový software, pak metoda feature point vygeneruje vyšší celkový počet jednic než metoda function point. Naopak, jestliže bude systém obsahovat několik algoritmů a mnoho souborů, které jsou běžné pro některé informační systémy, bude metoda feature point generovat nižší celkový výsledek než metoda function point. Metoda SPR feature point a IBM function point jsou metody založené na podobném komceptu, ale v některých případech se jimi odhadnuté výsledky liší, jak bylo zmíněno ve výše uvedeném odstavci. Na těchto úvahách by se daly uvést následující závěry: 1) Pokud jsou metody feature a function point aplikovány na klasický projekt MIS (Management Information System) poskytují téměř identické výsledky. 2) Pokud jsou ale aplikovány na real time a systémový software, pak metoda feature point vygeneruje vyšší odhad než metoda function point.
6
Závěr
Je všeobecně známo, že se objektové databázové technologie pokládají za perspektivní technologie, která nabízí velký užitný potenciál. Je jen otázkou času, kdy se na ně výrobci informačních systémů přeorientují. S rostoucím významem objektových technologií se dá očekávat i růst zájmu o odhad složitosti objektových systémů. Je zřejmé, že vždy se bude jednat spíše o nástřel budoucí složitosti než o exaktně přesný výsledek. Snahou všech, kteří se zabývají touto problematikou samozřejmě je, zdokonalování používaných metod, které budou i lépe reagovat na potřeby tvůrců informačních systémů.
Metody odhadu složitosti Feature Point a Funtion Point
273
Reference 1. Albrecht, A. J. and Gaffney, J. E., Jr. Software Functions, Source Line sof Code and Development Effort Prediction.: A Software Science Validation, IEEE Transactions on Software Engineering (TSE) 9, no. 6 (November 1983) 2. International Function Point Users Group. IT Measurement PractialAdvice from the Experts.Addison-Wesley, 2002 Boston. ISBN 0-201-74158-X. 3. International Funtion Point Users Group. www.ifpug.com 4. Meruňka, V. Normalizace objektových databází. Sborník konference OBJEKTY 2004. Praha 2004. ISBN 80-248-0672-X. 5. Quantitative Methods – Principles of Function Points. www.itpapers.com 6. Software Productivity Research. www.spr.com 7. Struska, Z. Measurement and rating of information systems quality. Part 3: Design Komplexity and Software Engineering Consequences. PEF ČZU, 2005, Praha. 8. Struska, Z. Measurement and rating of information systems quality. Part 2: Quality Model.PEF ČZU, 2005, Praha. 9. Struska, Z.. Porovnání vybraných přístupů aplikace funkčních jednic. Agrární perspektivy 2005 10.ročník. Praha 2005. ISBN 80-213-1372-2. 10. Vaníček, J. Měření a hodnocení jakosti informačních systémů. PEF ČZU, 2004 Praha. ISBN 80-213-0667-X. Annotation. Complexity Estimation in object environment – Feature Point with connection to Function Point This paper contains an overview of two current methods from the area of complexity estimation in object environment. In the first part of the paper there is description of IFPUG Function Point with advice, how it should use. In the second part there is description of SPR Feature Point with counting advices. Then it offers the comparison of these two methods and own author’s view of discussed question as well.
Moderní koncepčního a programového Moderní ppřístup ístup koncep ního a programového ešení WWW portálu Agris Agris řešeníagrárního agrárního WWW portálu PavelŠimek, Šimek,Jiří Ji í Vaněk, Van k, Jan Pavel JanJarolímek Jarolímek Katedra informa níchtechnologií technologií PEF ZU v v Praze Katedra informačních PEF ČZU Praze, Kamýcká 129, 129, 165 Kamýcká 165 21 21 Praha Praha6 6– Suchdol Suchdol [email protected], [email protected] {simek,[email protected], vanek, jarolimek}@pef.czu.cz Abstrakt. Internetové portály využívají výhod t íúrov ové architektury a tenkého klienta v podob b žn dostupného webového prohlíže e. Vytvá ení portálu není možné bez d kladné analýzy, která musí zmapovat reálné prost edí, ve kterém bude portál implementován a navrhnout jakým zp sobem jej p evést do portálu. Programové ešení portálu by m lo umož ovat práci s r znými datovými formáty (p edevším XML), podporovat zp ístupn ní informací na r zných platformách a dovolovat tvorbu modulárního a opakovateln využitelného kódu, nejlépe prost ednictvím objektov orientovaného programování. Konkrétní implementace t chto p ístup je prezentována na nové verzi portálu Agris. Je založena na p ednostech skriptovacího jazyka PHP 4.3, jazyku XML, XHTML, XSLT a databázového serveru MS SQL Server 2000. Koncept se vyzna uje p edevším p ív tiv jším uživatelským prost edím a také univerzálností a modularitou programového ešení. P ísp vek se zabývá p edevším aspekty vývoje portálového ešení a získanými poznatky. Klí ová slova: portal, Agris, agriculture, PHP, XML, XSLT, XHTML, SQL, object, class
1
Úvod
Pojem portál je sklo ován v nejr zn jších tvarech tém na všech stránkách internetových e-zin , jakožto nejvhodn jší nástroj pro zp ístupn ní informací ur ité skupin uživatel . P esnou definice portálu není možné sestavit, protože vždy existuje ur itý pohled na konkrétní internetovou aplikaci, který ji m že ozna it za portál. Nejobecn jší definice portálu íká, že je to vstupní brána k informacím, které jsou ur eny r zn široké skupin uživatel . Z technologického hlediska m že být takovýmto „portálem“ webová aplikace komunikující s r znými aplikacemi r znými rozhraními, napojená na databázové stroje a to samoz ejm s plným využitím možností moderních skriptovacích jazyk . Na druhé stran m že být za portál považován také web, který obsahuje všechny pot ebné informace v as a v požadované kvalit , ale nemusí v bec využívat skriptovací jazyky nebo databáze. Tato varianta pro tvorbu portálu je na p echodnou dobu možná, ale jak bude nazna eno dále, není dlouhodob udržitelná. D ležitými faktory proti této variant jsou p edevším asová náro nost aktualizací a nekonzistentnost obsahu, který je p i nar stajícím množství informací dlouhodob neudržitelný. Porovnání t chto dvou
c Václav Snášel, editor: Objekty 2005, pp. 274–280, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Moderní přístup koncepčního a programového řešení agrárního WWW. . .
275
možností podle množství vynaložené práce pracovníka IT v pr b hu budování a následném provozu portálu vykazuje p esn opa ný trend.
2
Internetový prohlíže jako tenký klient
Nejobecn jší d lení portál je na portály pravidelných návšt vník a portály uzav ené (nap . firemní). Portál p edstavuje webovou aplikaci, která využívá výhody všudyp ítomného internetového prohlíže e, který p edstavuje prezen ní vrstvu internetové aplikace. Výhoda internetového prohlíže e spo ívá p edevším v jeho velké rozší enosti a nezávislosti na druhu a verzi opera ního systému. Internetová aplikace tak m že být provozována jak na Windows, tak nap . na Linuxu, bez sebemenší zm ny nebo omezení. Ovšem tato hlavní výhoda okamžit posouvá technologické možnosti dvou základních skupin portál na úpln odlišnou úrove . Pokud má portál pracovat efektivn a má být samoz ejm co možná nejvíce p izp sobitelný a rozši itelný, m l by využívat nejmodern jší technologie v oblasti tvorby webu, které zajistí uvedené požadavky. Moderní technologie, p edevším na stran klienta (DHTML, ActiveX, JavaScript, Java, CSS, apod.) jsou dnes základním úskalím portál pravidelných návšt vník . Tv rci takovéhoto portálu musí brát v potaz nejednotnost ve verzi a zna ce prohlíže e, se kterým si budou návšt vníci web prohlížet. Moderní technologie se za ínají na tomto typu portálu využívat v tšinou až n kolik let od jejich uvedení, aby existovala pom rn vysoká pravd podobnost, že návšt vník v prohlíže bude technologii podporovat. Naproti tomu firemní portály jsou v tšinou vytvá eny na zakázku a už v samotných požadavcích na vybavení klient je možné p edem stanovit minimální požadavky na prohlíže , což umožní mnohem efektivn jší využití všech možností prohlíže e.
3
OOP p i tvorb portálu
P i použití objektov orientovaného p ístupu lze rozd lit vyvíjený portál na jednotlivé objekty jako celky. Každý problém je ešen obecn a vzniká tak knihovna objekt , o které lze p edpokládat, že bude v budoucnu využita i p i tvorb jiných aplikací. Nové objekty je žádoucí vytvá et z objekt již existujících s využitím vazeb skládaní, d di nosti, závislosti a delegování a nov implementovat jen ty charakteristiky, jimiž se liší od stávajících objekt . OOP zatím p ekonává nejlépe ze všech známých p ístup nebezpe í, že tv rci portál nebo jiných systém vy erpají svoji energii na jednotlivých ástech, vynucených obtížnou implementací detail . U dob e navrhnutého objektov orientovaného portálu je možné skrýt zna nou ást primitivních operací, které jsou p i tvorb na obtíž. Jsou totiž zapouzd eny do kód metod objekt a takové objekty potom spolu komunikují na vyšší úrovni. Mnoho objekt lze využít jako hotové komponenty v knihovn systému. Celý portál m že být navrhován, testován a odlad n po jednotlivých ástech, objektech.
276
4
Pavel Šimek, Jiří Vaněk, Jan Jarolímek
Stádium expanze
Stádiem expanze se ozna ují vývojové fáze portálu zadání a analýza. Zadání vcelku není tak složité jako samotná analýze, která by se m la skládat ze ty samostatných ástí: • analýza zdroj • analýza proces • datová analýza • analýza uživatelského prost edí Analýza zdroj by m la být provedena jak na stran uživatel , administrátor (zadavatele) tak i na stran zhotovitele samotného portálu. Zadavatel portálu by m l zanalyzovat dostupné informa ní zdroje, místa, kde informace vznikají a požadovanou formu v jaké by m ly být portálem zpracovávány a prezentovány. Analýzou zdroj na stran uživatele se míní analýza požadavk na systém. Ob tyto analýzy zpracovává zadavatel. Analýza zdroj na stran zhotovitele portálu p edstavuje p edevším plánování použitých hardwarových a softwarových prost edk , které má zhotovitel k dispozici, které jsou pro daný ú el vhodné, a pro které lze efektivn využít projektové ízení. Vnit ní transformace informací uvnit portálu, zp soby zobrazení, použité nástroje a systém získávání informací by m ly tvo it základ analýzy proces . Tato analýza vyús uje v model proces . Na jedné stran vzniká modelovaný systém, který je tvo en adou proces , na druhé stran je tedy i odpovídající funk ní model obsahující množinu vzájemn souvisejících proces . Na základ této analýzy je naprogramována aplika ní logika celého systému. Následn je možné p istoupit k analýze datové základny, tedy databází, ve kterých budou uchovávána veškerá data neboli informace. Datová analýza musí vycházet z p edcházejících dvou krok . Kvalitn navržená datová základna se projeví p edevším v postimplementa ním období, tedy v dob , kdy zadavatel za ne vznášet dodate né a nové požadavky na funkcionalitu portálu. V p ípad bezchybn navržené datové základny a využití OOP by m la být pracnost t chto zm n minimální. tvrtá ást základní analýzy se týká p edevším uživatel , kte í budou se systémem pracovat. Je zapot ebí zjistit v jakém prost edí jsou zvyklí pracovat, jak jsou zde rozmíst ny ovládací prvky, jak se systém chová, jak vypadá a jaká je úrove informa ní gramotnosti. Krom toho by m la analýza p inést informace o tom, co by systém m l um t a jaké funkce by v n m m ly být zahrnuty. Takovýto zp sob analýzy je možný p edevším u uzav ených portál , kde je cílová skupina známa. U portál pravidelných návšt vník se tato analýza provádí p edevším prost ednictvím analýzy fungování podobných a již osv d ených systém na internetu.
5
Stádium konsolidace
Fáze implementace, lad ní, testování, provoz a údržba se ozna ují stádiem konsolidace proto, že v t chto etapách se model, který je produktem p edchozího stádia expanze, postupn stává fungující aplikací. Nejobtížn jší fází je fáze
Moderní přístup koncepčního a programového řešení agrárního WWW. . .
277
implementace, kde se po návrhu a realizaci designu i vzhledu p ejde k aplika ní logice celého portálu. 5.1
Design
Na základ stanovení a návrhu designu je možné ešit ovládání tak, aby bylo jednotné v celém prost edí. Na úrovni kódu je nutné vytvo it tzv. stylesheet (katalog použitých styl ) a stanovit zp soby jeho používání a rozši ování. Stylesheet je v prost edí internetového portálu tvo en pomocí kaskádních styl (CSS). Jako nejrozumn jší se jeví zmín ný stylesheet uložit do externího souboru. Pokud budou všichni vývojá i využívat stylesheet podle pravidel je možné jednoduchým zp sobem a b hem krátké doby m nit vzhled celého portálu. I zde je pot eba mít na mysli, že dodate ná implementace kaskádních styl je asov velice náro ná. 5.2
Aplika ní logika
Nejd ležit jší ást pro provoz portálu p edstavuje funk ní jádro www aplikace. V naprosté v tšin p ípad se ale nejedná o asov nejnáro n jší ást projektu. Mnohem náro n jší na as je tedy samotná analýza, jejíž kvalitní provedení snižuje asovou náro nost realizace aplika ní ásti. Výše uvedené skute nosti otevírají cestu efektivnímu využití skriptovacích jazyk a technologií na stran serveru. Mezi nejpoužívan jší pat í ASP 3.0 nebo ASP.NET s využitím jazyk Visual Basic a C#, PHP 4 a Java Server Pages. V sou asné dob již mají implementovánu podporu objektového programování všechny zmi ované skriptovací jazyky na dobré úrovni a umož ují tak vytvá et webovou aplikaci efektivn . Programováním na úrovni t íd s využitím inheritance je možné odd lit designovou a aplika ní ást webu, což u skriptovacích jazyk d ív jší generace bylo velice obtížné. Pokud je vytvo en kvalitní objektový návrh a metody jsou navrženy dostate n univerzáln , je možné jednotlivé stránky portálu zkonstruovat pouze vytvo ením z n kolika instancí t íd. Technologie Microsoft .NET má p edevším velkou p ednost v již vytvo ené rozsáhlé objektové knihovn t íd. Celý portál je však t eba vytvo it na základ výše uvedených analýz. Proto není pro kompletní tvorbu nového portálu p íliš d ležité jaká platforma bude zvolena, ale spíše na tvorb kvalitního objektového návrhu. 5.3
XML, XHTML
Každý portál by svá rozsáhlá data m l uchovávat v ur itém, snadno rozši itelném, standardu, který lze snadno distribuovat do r zných koncových zobrazení. Jako nejlepší se jeví formát XML. Aby mohl být dokument XML pokládán za správn strukturovaný, musí být dodržena syntaktická pravidla stanovená konsorciem W3C v doporu ení XML 1.0. Neoficiáln znamená fráze „správn strukturovaný“ p edevším to, že dokument obsahuje jeden
278
Pavel Šimek, Jiří Vaněk, Jan Jarolímek
nebo více element , p i emž jen jeden z nich musí obsahovat všechny ostatní elementy. Tento element se nazývá ko enový (root element). Krom toho musí být všechny elementy správn ohrani eny p íslušnými zna kami – tagy. Na tvorbu samostatných stránek celého portálu jsou kladeny vysoké požadavky a nároky, nebo by m ly být postaveny na XHTML Transitional. Musí tedy respektovat striktní zásady XHTML, které vychází z HTML a XML. Tyto požadavky mají svoje opodstatn ní, nebo výsledný formát (XHTML) neobsahuje žádné chyby, které se b žn vyskytují u klasických HTML dokument (neukon ené tagy, p ekrývající se vno ení, apod.).
6
WWW portál Agris
WWW portál Agris je vytvo en pomocí skriptovacího jazyka PHP 4.3 v kombinací s Microsoft Internet Information Serverem a Microsoft SQL Serverem 2000. Objektový návrh celého portálu je zobrazen na obrázku . 1, kde nejv tší ást služeb celého portálu pokrývají t ídy Texts, Links, Weather a Companies. agris -idCurrSection -nameCurrSection -dbCurrConn -adminEmail -errorEmail +getDbConn() +getSectionName() +getSectionId() +sendServisMail()
Agris je zpravodajským portálem pro agrární sektor, a proto je nejv tším celkem databáze text a odkaz . Zárove také disponuje databází firem a aktuálním po asím. Všechny tyto portálové elementy využívají databáze a m ly by proto p i svém rozsahu um t vyhledávat a klasifikovat obsažené informace. T ídy reprezentující tyto hlavní elementy portálu umož ují vlastní výb ry z databáze a jejich prezentaci v podob XHTML stránek.
Moderní přístup koncepčního a programového řešení agrárního WWW. . .
279
Databázi text je z d vodu technické realizace velmi d ležité držet v ur ité zformátované a dále zformátovatelné podob . Proto jsou uloženy v XML a lze je tedy zformátovat jako data po jejich jednotlivých elementech. Agrární www portál Agris využívá definice XML podle News Industry Text Format (NITF), jenž text formátuje vlastními zna kami, které se potom p i zobrazení textu uživateli portálu transformují do XHTML. XSLT šablon je využíváno práv pro p em nu XML v XHTML a vlastní p evod probíhá na serveru pomocí PHP. Velmi pružné reagování na p ípadné zm ny v požadavcích na zobrazení textu je nespornou výhodou tohoto systému. Uskute n ní zm ny stylu zobrazení všech tabulek, obrázk , odstavc , i dopln ní ur itého textu lze provést s minimálním úsilím, pouze pomocí zm ny v p íslušné XSLT šablon , p i emž zdrojový text v XML z stane stejný.
7
Alternativní ešení portál
Portál je možné vytvá et bu úpln od za átku zakázkovým zp sobem, nebo je možné využít již hotového ešení, kterých je na trhu pom rn mnoho a implementovat ho do vlastních podmínek. P íklady takovýchto ešení m že být Oracle 9iAS Portal, Novell Portal Services a Microsoft SharePoint Portal. Nasazení takovéhoto ešení je ovšem vhodné p edevším na portály uzav ené, tedy nap . firemní. Tato ešení umož ují nastavit a spustit základní verzi portálu již b hem n kolika dní nebo hodin, umož ují zakomponovat do portálu další aplikace (nap . v Oracle nazývané portlety), se kterými komunikuje pomocí XML zpráv. Takovéto typové ešení nemusí vždy pln odpovídat požadavk m zadavatele.
8
Záv r
P i tvorb www portál a jiných rozsáhlejších www aplikací je velmi vhodné využít OOP. Ú eln a vhodn se OOP projevil i p i realizaci agrárního www portálu Agris, kdy veškeré zm ny, které se promítají do funk nosti celého portálu je možné spravovat pouze na jednom míst . Tvorba stránek pro jednotlivé rubriky portálu, pop . rozší ení portálu je pak velice rychlá a efektivní a byla realizována pomocí skriptovacího jazyka PHP 4.3 a databázového serveru MS SQL Serveru 2000. Zavedení formátu XML pro uchovávání dat v portálu je výrazným krokem vp ed, který m že zp ístup ovat texty nejen skrze klasický web, ale i p es Wap, PDA, i jiná za ízení.
Reference 1. CASTEGNETO, J.; RAWAT, H.; SCHUMANN, S.; SCOLLO, C.; DEEPAK, V. Programujeme PHP profesionáln . Praha : Computer Press, 2001. 656 s. ISBN 80-7226-310-2.
280
Pavel Šimek, Jiří Vaněk, Jan Jarolímek
2. CORMEDIA – Document and Content Management Solutions – Internet portals [online]. [cit. 20. 10. 2005] . 3. HOLZNER, S. XSLT – P íru ka internetového vývojá e. Praha : Computer Press, 2002. 516 s. ISBN 80-7226-600-4. 4. PETERKA, J. Od distribuce informací po podnikové portály. In Softwarové noviny. . 5 (kv ten), ro . 13, s. 10-15. ISSN 1210-8472. 5. POLÁK, J.; MERUNKA, V.; CARDA, A. Um ní systémového návrhu – Objektov orientovaná tvorba informa ních systém pomocí p vodní metody BORM. Praha : Grada Publishing a. s., 2003. 196 s. ISBN 80-247-0424-2.
Využití Využitíadaptivního adaptivního hypermediálního hypermediálního systému systému AHA! při výuce programovacího jazyka AHA! při výuce programovacího jazyka C++ C++ Zdeněk ZdeněkVelart, Velart,Petr PetrŠaloun Šaloun Katedrainformatiky, informatiky,FEI, FEI,VŠB VŠB- -Technická Technickáuniverzita univerzita Ostrava, Ostrava, Katedra 17.listopadu listopadu15, 15,708 70833, 33,Ostrava-Poruba, Ostrava-Poruba, Česká Česká republika republika 17. {zdenek.velart.fei, petr.saloun}@vsb.cz petr.saloun}@vsb.cz {zdenek.velart.fei,
Abstrakt V příspěvku je popsáno nasazení open source webového adaptivního hypermediálního systému AHA! v procesu výuky programovacího jazyka C++. Náš přístup je založen na principu adaptivní prezentace doménového modelu, který popisuje oblast programovacího jazyka C++. Doménový model je rozdělen na kapitoly popisující jednotlivé problémové oblasti. Každá kapitola se skládá z více učebních bloků, přičemž každý učební blok má tři základní části: učební text, příklady a testy. Testování studentů je jednou z volitelných částí AHA! systému. V současnosti jsou podporovány jen otázky s výběrem odpovědi. Testy mohou být studentům předkládany jako interaktivní PDF formuláře nebo jako standardní HTML formuláře. Klíčová slova: adaptace, adaptivní hypermedia, PDF, AHA!, výuka C++, testování
1
Úvod
Naučit se programovací jazyk jen z učebních materiálů a knih, ať jsou napsány sebelépe, je prakticky nemožné. Velké nároky jsou kladeny na samotného studenta, který musí ukázat ochotu a vůli se učit. K úspěšnému zvládnutí ovšem je zapotřebí i vhodná prezentace učebního materiálu a množství učebních příkladů a úkolů, které mohou být prakticky procvičovány. Naše řešení vychází z návrhu obecného řešení výuky programovacích jazyků pomocí adaptivních hypermedií představeného v [2]. Cíl, jímž je naučit studenta programovací jazyk, je dosahován za pomocí ukázek příkladů a adaptivních prezentací připraveného studijního materiálu. V příspěvku je prezentován postup, který jsme zvolili k výuce programovacího jazyka C++. Kapitola 2 popisuje oblast adaptivních hypermédií, v jakých oblastech jsou použitelné a jakými technikami a postupy se provádí vlastní adaptace zobrazovaného učebního obsahu. V další kapitole je pak následně představen adaptivní hypermediální systém AHA!, který implementuje některé z technik pro adaptaci a který byl zvolen jako nástroj pro adaptivní prezentaci obsahu studentům. Poté následuje představení doménového modelu, který jsme vytvořili pro oblast programovacího jazyka C++ a která představuje znalosti, které chceme
c Václav Snášel, editor: Objekty 2005, pp. 281–289, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
282
Zdeněk Velart, Petr Šaloun
studenty naučit. Kapitola 5 popisuje, jaké jsou možností testování studentů a to buď sebetesty, které mohou studenti provádět samostatně nebo hodnocenými testy. Představujeme zde dvě možnosti prezentace testů studentům - pomocí interaktivních PDF formulářů nebo pomocí HTML formulářů. V probíhajícím roce využijeme AHA! k výuce programovacího jazyka C++ pro přibližně 350 studentů denního a kombinovaného studia a předpokladáme využití i v dalších letech a případné rozšiření na výuku i jiných předmětů. Počítáme s tím, že získané výsledky a hodnocení výuky studenty využijeme jako zpětnou vazbu k zlepšení výukových materiálů nabízených studentům.
2
Adaptivní hypermédia
Oblast adaptivních hypermédií, jejíž počátky se datují zpětně do roku 1990, se zabývá výzkumem za účelem zvýšení funkcionality hypermédií tím, že se stanou personalizované. K tomuto účelu slouží adaptivní hypermediální systémy, které sbírají data o chování uživatelů a na základě požadavků a cílů, nastavení a znalostí individuálních uživatelů provádí adaptaci zobrazovaných informací. Adaptivní hypermediální systémy mohou být využity ve všech oblastech, kde existuje předpoklad, že systém bude využíván různými lidmi s různými požadavky. Proto tyto systémy nacházejí uplatnění např. v těchto následujících oblastech: – Systémy pro získávání informací (IR, information retrieval) - pomáhají uživatelům při vyhledávání informací v hyperprostoru, v případech, kdy uživatel není schopen sestavit formální dotaz a vyhledává informace metodou procházení hyperlinky propojených dokumentů. – On-line informační systémy - hlavním cílem těchto systémů, kterými mohou být systémy on-line dokumentace nebo on-line encyklopedie, je uživateli s různými stupni znalostí a s různými požadavky poskytnout referenční přístup k informaci. – On-line help systémy - velmi podobné předchozím systému, s tím že se zabývají jen nějakou konkrétní aplikaci (např. tabulkový procesor) a uživateli předkládají informace sloužící k práci s touto aplikací. – Výuková hypermédia - představují jen omezenou část hyperprostoru, většinou se jedná jen o jeden kurz, téma či materiál. Cílem těchto systému je pomoci studentům zvládnout učební materiály. Velmi důležitým aspektem těchto systémů je, jak uživatelé znají dané téma. V průběhu času se charakteristiky uživatele mění, podle toho, jak prochází a chápe probírané téma. Systémy patřící do uvedených oblastí využívají následující techniky a postupy sloužící k adaptaci zobrazované informace uživateli. Adaptační techniky se dají rozdělit na dvě základní oblasti a to adaptivní prezentace a adaptivní navigace. Každá z těchto oblastí se dále dělí na podoblasti a jednotlivé techniky (viz obrázek 1). Adaptivní systémy při adaptaci pracují s celými stránkami, jejich fragmenty (logický uzavřené celky) nebo skupinami odkazů či odkazy, nad kterými pomocí některých z dále popsaných adaptačních technik provádí adaptaci.
Využití adaptivního hypermediálního systému AHA! při výuce. . .
Obrázek 1. Adaptivní techniky
283
284
Zdeněk Velart, Petr Šaloun
Adaptivní prezentace – vkládání/odebírání fragmentů (inserting/removing fragments) - na základě určených podmínek pro fragmenty, uživatelova nastavení a postupu mohou být jednotlivé fragmenty odstraněny z nebo naopak přidány do výsledného zobrazení. – záměna fragmentů (altering fragments) - tato technika představuje možnost při zobrazování fragmentu výběr z několika alternativ. – rozklikávací text (strechtext) - pro každý fragment existuje krátký zobrazovaný zástupce. Systém rozhoduje, který fragment má být „rozkliknutýÿ a který ne, tzn. má být zobrazen jen zástupce. Uživatel může kliknutím na zástupce zobrazit nebo schovat obsah fragmentu. – třídění fragmentů (sorting fragments) - fragmenty jsou dynamicky setříděny tak, aby odrážely požadavky uživatele na důležitost zobrazované informace nebo na základě určených podmínek pro fragmenty. – potlačení fragmentů (dimming fragments) - tato technika představuje metodu zašeďování nepodstatných fragmentů. Adaptivní navigace – přímé vedení (direct guidance) - uživatel je systémem za pomocí hyperlinků pomocí tlačítek další a zpět přímo naváděn k požadované informaci. – třídění odkazů (adaptive link sorting) - zobrazované odkazy mohou být setříděny tak aby odrážely uživatelovy požadavky, nastavení a pravidla systému. Čím více je odkaz výše v seznamu, tím více odkazuje na relevantní informaci. – schovávání odkazů (adaptive link hiding) - zobrazované odkazy mohou být uživateli skryty nebo zobrazovány a to pomocí technik: • schovávání - odkazy jsou uživateli zobrazovány, mají svou funkčnost, ale jsou zobrazovány stejně jako okolní text, takže na první pohled není zřejmé, že se jedná o odkaz; • zakázaní - odkazy jsou uživateli zobrazovány, ale nejsou funkční; • odstranění - odkazy nejsou vůbec zobrazovány. – anotace odkazů (adaptive link annotation) - tato technika zobrazuje odkazy textově či graficky rozdílně na základě relevantnosti odkazů. Např. zajímavé odkazy jsou zobrazovány zelenou barvou a nezajímavé (irelevantní) červenou. – vytváření odkazů (adaptive link generation) - systém může nalézt nové nebo užitečné propojení mezi existujícími stránkami a vygenerovat pro ně odkazy a prezentovat je uživatelům. – adaptace hypermedia map (map adaptation) - tato technika představuje adaptaci mapy odkazů v systému, která je uživatelům graficky prezentována.
3
AHA!
Adaptivní hypermediální systém AHA! [6–9] (Adaptive Hypermedia for All) je vyvíjen na Eidhoven University of Technology týmem vedeným prof. Paulem De
Využití adaptivního hypermediálního systému AHA! při výuce. . .
285
Bra jako open source projekt a patří do skupiny výukových hypermediálních systémů. V současné době (podzim 2005) je dostupná na stránkách projektu (http://aha.win.tue.nl) verze AHA! 3.0 pre-release. Architektura AHA! vychází z obecného referenčního modelu AHAM [5], který byl vytvořen jako abstrakce struktury a funkcionality existujících a budoucích adaptivních systémů. AHAM definuje čtyři základní části systému: – doménový model popisuje aplikační doménu pomocí fragmentů, stránek a konceptů. Jednotlivé stránky se skládají z žádného či více fragmentů a jsou navzájem propojeny pomocí hyperlinků. – uživatelský model slouží k uložení nasbíraných dat o jednotlivých uživatelích a jejich chování v systému. AHA! používá pro stránku nebo koncept více atributů, které určuje autor a mohou být využity např. k určení zainteresovanosti uživatele nebo k vyjádření znalosti o konceptu. Atributy mohou být logické, číselné nebo řetězcové. – adaptační model obsahuje adaptační pravidla, která určují za jakých podmínek a kdy má být adaptace provedena. Pro jednotlivé stránky a fragmenty existuje předpoklad, který má formu boolean podmínky, která určuje zda odkazy vedoucí na danou stránku mají být zobrazeny jako požadované nebo zda daný fragment má být zahrnut do prezentace. Dále pro každou stránku a koncept může být definována množina tvořících pravidel. Každé pravidlo má podmínku, která se testuje a určuje, zda asociovaná akce má být provedena. Je také možné definovat alternativní akci, která se provede, když podmínka není splněna. – adaptační mechanismus provádí vlastní adaptaci na základě adaptačních pravidel a vytváří pro uživatele finální stránky, za pomocí existujících adaptačních technik. V AHA! jsou použity tyto následující techniky - podmíněné vkládání fragmentů, schovávání nebo anotace odkazů. Současně adaptační mechanismus je také odpovědný za vyvolání pravidel, která jsou určená ke spuštění při přístupu na stránku. AHA! rozlišuje dva druhy updatů: absolutní - atributu stránky nebo konceptu je přiřazena hodnota specifikována v akci - nebo relativní - daná hodnota je použita jako procentuální část, která má být přidána nebo odebrána atributu stránky nebo konceptu.
4
Doménový model pro C++
Naše řešení spočívá v adaptivní prezentaci učebního materiálu spojeného s ukázkami probírané látky na příkladech. Kurz je rozdělen (viz obrázek 2) do jednotlivých kapitol, které představují logicky uceléné části učiva. Každá kapitola se následně dělí do jednoho či více učebních bloků, kde každý blok se skládá: – z učebního textu - představuje fragmenty či stránky obsahující text vysvětlující dané učivo;
286
Zdeněk Velart, Petr Šaloun
– žádného či více ukázkových příkladů - tyto příklady úzce souvisejí s probíraným učebním textem; – a žádného čí více testů - jedná se o sebetesty, ve kterých si student může otestovat své nabyté znalosti a zda pochopil probírané učivo.
Obrázek 2. Rozdělení kurzu
Adaptace Na začátku kurzu se studentovi nezobrazí kompletní celý kurz, ale jen jeho první ucelená část. Jak student bude postupovat kurzem, budou mu zpřístupněny navazující části. Pro pokračování musí student získat v systému určité dané minimální bodové hodnocení v systému AHA!. Tohoto může dosáhnout jedním ze způsobů: – Student projde všechny nebo alespoň podstatnou část připravených učebních textů. Projitím každé stránky student získává předem určené množství bodů. Při tomto způsobu je dobré zvážit, zda by nebylo vhodné zavést pro každou stránku minimální čas, který student musí na stránce strávit, aby se tak předešlo pokusům o „proklikáníÿ. – Student neprochází učební text, nebo jen letmo a rozhodne se udělat si jeden nebo více kontrolních testů. Za každý úspěšný test student získá body. Pokud byl v některém testu neúspěšný, systém ho odkáže na část učebního text, která se vztahuje k dané otázce. – Protože nelze vždy automaticky předpokládat že všichni studenti budou mít dostatek odhodlání či času absolvovat dostupnou část kurzu, je nutné zohlednit i tento fakt. Proto a také z důvodu časového omezení pro absolvování
Využití adaptivního hypermediálního systému AHA! při výuce. . .
287
kurzu předpokládáme ještě jedno a to časové hledisko, tzn. po určitém předem určeném datu systém automaticky zpřístupní navazující část kurzu.
5
Testy
V procesu učení můžeme rozlišovat dva druhy testů, které jsou studentovi předkládány, a to sebetesty a hodnocené testy. Sebetesty uzavírají učební blok, kapitolu či téma a představují pro studenta možnost otestovat si, do jaké hloubky pochopil probíranou látku. Současně také sebetesty slouží jako mezník, kde student musí prokázat dostatečnou znalost doposud probírané látky, aby mu systémem bylo umožněno pokračovat dále. Toto řešení nabízí také druhou možnost a to, že pokud si student dostatečně důvěřuje, že zná látku, která bude probíraná, muže přeskočit pročítání učebního textu a přímo se pokusit o zvládnutí testu. Pokud test zvládne úspěšně, je mu umožněno ihned pokračovat v další látce a pokud ne, je upozorněn na oblasti, ve kterých má ještě nedostatky a které by si měl prostudovat. Na druhou stranu hodnocené testy slouží k ověření znalosti studentů za účelem jejich průběžného nebo konečného hodnocení v kurzu. U těchto textů se předpokládá, že se budou přistupné jen po určitou dobu a každý student bude mít jen omezený počet pokusů (většinou jeden). Technologie testů V současné době systém AHA! umožňuje předkládat studentům a vyhodnocovat jen testy s otázkami s volenou odpovědí. Testy lze studentům prezentovat pomocí dvou rozdílných přístupů: – interaktivní PDF formuláře [3] - studentům jsou předkládány testy jako PDF formuláře, které student vyplní a odešle ke kontrole. Mezi hlavní přednosti tohoto řešení patří tyto: • sazba - PDF nabízí možnost sazby textu, obrázků a grafiky se zachováním kvality při výstupů na jakémkoliv zařízení nebo při zvětšování či zmenšování na obrazovce. • „all in oneÿ - veškeré obrázky, grafika, JavaScript i případné další objekty jsou společně s textem uloženy v jediném souboru, což znamená výhodu při distribuci testů. Je také možné povolit uložení rozpracovaného formuláře přímo do PDF souboru a tím studentům umožnit uložení rozpracovaného testu a po znovuotevření jej dovyplnit a odeslat. • omezení přístupu a digitální podpisy - přístup k PDF dokumentu lze omezit a to třeba možnost změny dokumentu či tisku. Současně lze také PDF dokument digitálně podepsat za účelem ověření pravosti. • JavaScript - PDF dokument umožňuje použití JavaScriptu pro kontrolu formulářových dat a pro dynamické akce PDF dokumentů. – HTML formuláře - student s testy pracuje pomocí webového prohlížeče a po vylnění je odešle na server ke zpracování.
288
6
Zdeněk Velart, Petr Šaloun
Závěr
V tomto článku jsme naznačili princip jak aktuálně probíhá na FEI VŠB-TU Ostrava výuka programovacího jazyka C++ za pomocí adaptivních hypermédií a adaptivního systému AHA!. Přístup se snaží zohlednit principy výuky, kdy je studijní materiál předkládán studentovi postupně společně s velkým množstvím ukázkových příkladů a testů, na kterých si student může otestovat své znalosti nabyté v kurzu. Naším dalším cílem v této oblasti je vyhodnocení nasbíraných dat po skončení kurzu za účelem vylepšení nebo úpravy adaptačního mechanismu, případně průběžná úprava dle připomínek a návrhů studentů. Dále předpokládáme, že by se tento princip výuky mohl rozšířit i na jiné předměty a to nejen z oblasti programování.
Reference 1. BIELIKOVÁ Mária. Využitie adaptívnych hypermédií pre e-vzdělávanie, Technologie pro e-vzdělávání: sborník semináře: Praha 10. června 2003, Praha: ČVUT 2003, s. 15-21. ISBN 80-01-02761-9 2. BIELIKOVÁ Mária, KURUC Jaroslav, ANDREJKO Anton. Learning Programming with Adaptive Web-Based Hypermedia System AHA!, In Proc. of ICETA 2005, Košice, Slovakia, September 2005, p. 251-256, ISBN 80-8086-016-6 3. BOBER Marek, ŠALOUN Petr, VELART Zdeněk, Interactive PDF forms for multichoice testing in AHA!, In Proc. of ICETA 2005, Košice, Slovakia, September 2005, p. 251-256, ISBN 80-8086-016-6 4. BRUSILOVSKY Peter. Methods and Techniques of Adaptive Hypermedia, Adaptive Hypertext and Hypermedia, Kluwer Academic Publisher, 1998, p. 1-44, ISBN: 0-7923-4843-5 5. De BRA Paul, HOUBEN Geert-Jan, WU Hongjing. AHAM: A Dexter-based Reference Model for Adaptive Hypermedia. In Proceedings of the ACM Conference on Hypertext and Hypermedia, Darmstadt, Germany, 1999, p. 221-239. 6. De BRA Paul, RUITER Jan-Peter. AHA! Adaptive Hypermedia for All. In Proceedings of the WebNet Conference, October 2001, pp. 262-268. 7. De BRA Paul, AERTS Ad, SMITS David, STASH Natalia. AHA! Version 2.0, More Adaptation Flexibility for Authors. In Proceedings of the AACE ELearn’2002 conference, October 2002, pp. 240-246. 8. De BRA Paul, AERTS Ad, SMITS David, STASH Natalia. AHA! meets AHAM. Second International Conference on Adaptive Hypermedia and Adaptive WebBased Systems, May 2002. Springer LNCS 2347, pp. 381-384. 9. De BRA Paul, AERTS Ad, BERDEN Bart, De LANGE Barend, ROUSSEAU Brendan, SANTIC Tomi, SMITS David, STASH Natalia. AHA! The Adaptive Hypermedia Architecture. In Proceedings of the ACM Hypertext Conference, Nottingham, UK, August 2003, pp. 81-84.
Anotation This paper describes the use of the open source web-based adaptive hypermedia system AHA! in the process of teaching of the C++ programming language. Our
Využití adaptivního hypermediálního systému AHA! při výuce. . .
289
solution is based on adaptive presentation of the domain model, which describes the problem domain of the C++ programming language. The domain model is divided into chapters, where every chapter is focused on different part of the problem domain. Chapters are further divided into knowledge blocks. Knowledge block is a compositon of three basic parts: learning material, examples and tests. The testing of students is one of optional parts of AHA! funcionality. Nowadays only multichoice tests are supported. Test can be presented to student as interactive PDF forms or simple HTML forms.
Akademické programy společnosti Microsoft Akademické programy společnosti Microsoft Dr. Ing. Dalibor Kačmář Dalibor Kačmář Microsoft Microsoft CZ s.r.o. [email protected][email protected]
Abstract. The presentation will introduce overview of all Academia projects and activities Microsoft corporation has worldwide and localy. It will cover, just to name few, MSDN Academic Alliance, MS IT Academy, Imagine Cup, and MS Research.
c Václav Snášel, editor: Objekty 2005, pp. 290–290, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Architektura systému Plaant Architektura systému Plaant Vladimír Lahoda, Rudolf Pecinovský Vladimír Lahoda1, Rudolf Pecinovský1 Amaio Technologies Inc., Amaio Technologies Inc., 100 Praha 10, Třebohostická 14 100 00 Praha 10, 00 Třebohostická 14 {lahoda, rpecinovsky }@amaio.com {lahoda, rpecinovsky}@amaio.com
1
Abstrakt. Plaant je softwarový framework pro vytváření, provoz a následnou údržbu distribuovaných databázových aplikací. Jádro systému je založeno na technologii Java 2 Enterprise Edition. Aplikace instalované v systému Plaant jsou úplně popsány pomocí sady XML souborů uložených v metadata repository. Běhový systém Plaant z těchto informací dynamicky vytváří jednotlivé komponenty Enterprise Java Beans, datový modul připraví automatická mapování na SQL databázi. Klientské kontejnery na základě poskytnutých XML metadat vytvoří kompletní uživatelské rozhraní včetně formulářů pro zadávání dat a navazující služby (aktuálně je podporován webový klient a samostatný aplikační klient v Javě). Metadata repository obsahuje i informace o přístupových právech k jednotlivým složkám aplikace, které jsou využívány modulem zabezpečení. Modul výstupních sestav načítá z repository definice sestav a pomocí XSLT transformací naplňuje jejich šablony daty z jádra Plaantu, převádí je do požadovaného výstupního formátu, např. PDF nebo CSV a dopraví je na určené výstupní zařízení. Modul stavového stroje načítá z repository UML stavové diagramy ve formátu XMI a v součinnosti s jádrem Plaantu a časovačem Quartz řídí stavové přechody jednotlivých datových záznamů. Klíčová slova: framework, distribuované aplikace, vývoj, J2EE
Annotation Plaant is a software framework for development, deployment and maintenance of the distributed database applications. The core of the system is based on the Java 2 Enterprise Edition technology. The applications deployed on the Plaant system are fully described in a set of XML files that are stored in the metadata repository. Plaant runtime system uses these informations to dynamically create particular Enterprise Java Beans components, while the persistence module creates automatic SQL database mappings. Client containers create (from the provided XML metadata) complete graphical user interface including the data entry forms and additional services (currently the web client and standalone Java application client are supported). The metadata repository contains also the information about the access rights for the application components, that are used by the security module. The reporting module reads the report definitions from the repository and using XSLT transformations fills their templates with the data provided by the Plaant core. The reports are then converted to the required output format, e.g. PDF or CSV and consequently transferred to the appropriate output device. The state machine module reads the UML state diagrams in the XMI format and in cooperation with the Plaant core and Quartz timer it controls the state transistions of data records.
c Václav Snášel, editor: Objekty 2005, pp. 291–292, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Arichektura systému systému Agris Arichektura Agris PavelŠimek, Šimek,Jiří Jiří Vaněk, Vaněk, Jan Pavel JanJarolímek Jarolímek Katedra informačníchtechnologií technologií PEF Praze Katedra informačních PEFČZU ČZUv v Praze, Kamýcká 129, 165 21 Praha 6 – Suchdol Kamýcká 129, 165 21 Praha 6 - Suchdol [email protected], [email protected] {simek,[email protected], vanek, jarolimek}@pef.czu.cz
Projekt WWW portálu AGRIS si od počátku klade za cíl vytvořit platformu pro poskytování informací z oblasti zemědělství, potravinářství, lesnictví a z dalších navazujících odvětví zahrnujících venkovský prostor. Cílem je zpřístupňovat již existující informační zdroje, vytvářet vlastní zpravodajství a napomáhat zveřejnění informací od subjektů, které mají omezené podmínky pro elektronické (internetové) prezentování. Na základě těchto skutečností byl na PEF ČZU v Praze již v roce 1999 zahájen výzkum a vývoj portálového řešení informačních služeb agrárního sektoru. WWW portál Agris je vytvořen pomocí skriptovacího jazyka PHP 4.3 v kombinací s Microsoft Internet Information Serverem a Microsoft SQL Serverem 2000. Objektový návrh celého portálu je zobrazen na obrázku č. 1, kde největší část služeb celého portálu pokrývají třídy Texts, Links, Weather a Companies. V současné době se jedná již o třetí verzi celého portálu (první objektově orientovanou). Kromě zcela nového vzhledu a programového řešení, je rozšířen celkový záběr portálu, modernizována a optimalizována struktura rubrik a celé řešení se opírá o využití značkovacího jazyka XML. agris -idCurrSection -nameCurrSection -dbCurrConn -adminEmail -errorEmail +getDbConn() +getSectionName() +getSectionId() +sendServisMail()
c Václav Snášel, editor: Objekty 2005, pp. 292–292, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
Generické programování Javě a C# Generické programovánívv C++, C++, Javě a C# Miroslav Virius Miroslav Virius Katedra softwarového inženýrství v ekonomii, FJFIPraha, ČVUT Praha,13, Katedra softwarového inženýrství v ekonomii, FJFI ČVUT Trojanova Trojanova 002Praha 2 12013, 00 120 Praha [email protected][email protected]
Abstrakt. Tento příspěvek nabízí porovnání nástrojů pro generické programování ve třech nejrozšířenějších programovacích jazycích, které ho podporují, a to nejen na úrovni syntaktické, ale především na úrovni implementační. Přes společný název a podobný cíl jde v různých jazycích o různé nástroje s poněkud odlišnými možnostmi, s odlišným způsobem překladu a s odlišným chováním za běhu programu. Klíčová slova: generické programování, C++, Java 2 JDK 5, C# 2.0, šablona, kontejner, prostředí .NET
1
Úvod
Smyslem generického programování – stejně jako smyslem mnoha jiných programovacích paradigmat – je zabránit opakovanému psaní stejného nebo podobného zdrojového kódu. Nástroje pro generické programování poskytuje řada programovacích jazyků; za zmínku stojí Ada, C++, C#, Eiffel, Haskel, ML nebo Java. V tomto příspěvku se zaměříme na C++, Javu a C#, neboť patří mezi nejrozšířenější. Cílem tohoto příspěvku není ukázat, že jeden z jazyků je v nějakém smyslu „lepší“ než jiný; nejde ani o porovnávání generického programování s objektově orientovaným programováním nebo jiným paradigmatem, i když právě generické programování umožňuje elegantně vyřešit některé problémy, na které jsme naráželi při použití metod objektově orientovaného programování. Ostatně generické programování nestojí v protikladu k objektově orientovanému programování; navazuje na ně, doplňuje a zesiluje jeho možnosti, neboť přidává nové možnosti abstrakce. V tomto příspěvku si kladu za cíl ukázat rozdíly mezi implementacemi v různých jazycích a ukázat, jaké mají tyto rozdíly důsledky. 1.1
Historické ohlédnutí
Začneme pohledem do minulosti: Prvním rozšířeným jazykem, který poskytl nástroje pro generické programovaní, byla patrně Ada. V jazyce C++ se nástroje pro generické programování objevily pod názvem šablony (template) ve specifikaci CFront 2.1 na konci 80. let a prvním běžně dostupným komerčním překladačem, který je implementoval, byl Borland C++ 3.0. I když je tehdejší implementace šablon v C++ značně odlišná od současného standardu [1], způsob implementace se od té doby v zásadě nezměnil.
c Václav Snášel, editor: Objekty 2005, pp. 293–300, ISBN 80-248-0595-2.
VŠB – Technická univerzita Ostrava, Fakulta elektrotechniky a informatiky, 2005.
294
Miroslav Virius
V Javě se nástroje pro generické programování objevily ve verzi Java 2, JDK 5, uvolněné firmou Sun Microsystems na podzim roku 2004; pro stručnost budu o této verzi Javy dále hovořit jako o Javě 5. Ve skutečnosti šlo o největší zásah do jazyka Java od jeho uvedení v roce 1995. V době psaní tohoto příspěvku nebyly nástroje pro generické programování v C# ještě součástí komerčně dodávaných vývojových nástrojů. Jsou však již delší dobu dostupné v betaverzi překladače C# verze 2.0 a vývojového prostředí nástroje Microsoft Visual Studio, jehož uvedení na trh se očekává do konce roku.
2
Generické programování
Než se pustíme do porovnávání, podíváme se, proč je vlastně generické programování potřebné a jak ho lze implementovat. Typickým příkladem, uváděným v téměř každé učebnici jakéhokoli programovacího jazyka, který generické programování podporuje, je implementace kontejnerů (nebo též kolekcí) – objektů, do nichž lze ukládat jiné objekty. Budeme tedy dále hovořit o kontejnerech, i když generické programování lze v některých programovacích jazycích využít i k značně odlišným účelům. Při vytváření knihovny kontejnerů stojíme před problémem, jak zabezpečit na jedné straně jejich univerzálnost a na druhé straně jejich typovou bezpečnost. 2.1
Objektové řešení
Tradiční řešení založené na objektově orientovaného paradigmatu vychází z polymorfizmu. Jsou-li všechny třídy v daném jazyce odvozeny od společného předka, řekněme od třídy Object, stačí, vytvoříme-li kontejner pro ukládání odkazů na typ Object a dostaneme univerzální (nebo téměř univerzální) kontejner. Toto řešení má v závislosti na použitém programovacím jazyce řadu nevýhod. Nic nebrání uživateli uložit do takového kontejneru odkaz na instanci naprosto nesmyslného typu (např. odkaz na tlačítko místo odkazu na objednávku). Takovouto chybu neodhalí překladač, chyba se projeví až za běhu aplikace, a to při vyjímání objektu z kontejneru – tedy jindy a na jiném místě, než vznikla. V jazycích, jako je C++, v nichž není jednotná předem daná hierarchie tříd, je třeba ukládané objekty „zabalit“ do obalových tříd odvozených od vhodného předka; tím se ovšem ztrácí univerzálnost. (Poznamenejme, že na podobný problém narazíme i ve starších verzích Javy v souvislosti s primitivními typy.) V jazycích, které nepožadují, aby instance objektových typů byly dynamické, a které neobsahují automatickou správu paměti (garbage collector), se musí programátor sám starat o jejich správné uvolnění. To může vést k problémům, uložíme-li do kontejneru vedle sebe odkazy na dynamické i nedynamické instance. (Na problémy tohoto druhu narazíme např. v C++ nebo v Pascalu.)
Generické programování v C++, Javě a C#
295
Můžeme samozřejmě také navrhnout jednoúčelový kontejner, do kterého lze ukládat pouze hodnoty předem daného typu. To ovšem znamená vytvořit pro různé typy ukládaných hodnot různé kontejnery, tedy opakovaně psát (téměř) identický kód. Zdá se tedy, že máme na vybranou buď typově nezabezpečený, ale více či méně univerzální kontejner, nebo typově zabezpečený kontejner, který musíme napsat pro každý typ ukládaných hodnot zvlášť. 2.2
Generické programování a jeho cíle
Řešením dilematu, k němuž jsme dospěli na konci předchozí sekce, je vytvoření parametrizovaných neboli generických konstrukcí – datových typů, metod, případně dalších součástí programů. Přitom „parametrizace“ zde znamená, že měnitelným parametrem je datový typ. V předchozím oddílu jsme uvažovali o generickém programování v souvislosti s implementací kontejnerů. Je ale jasné, že jde o obecnější nástroj a kontejnery – nebo jakékoli abstraktní datové struktury – představují jen jednu z aplikací. Neméně důležitá je i možnost implementovat na dostatečně abstraktní úrovni algoritmy, které s daty pracují. Současné generické programování si klade následující cíle [5]: Poskytnout způsob, jak vyjádřit algoritmy s minimální závislostí na použitých datových strukturách, a způsob, jak vyjádřit datové struktury s minimální závislostí na algoritmech. Poskytnout programátorovi možnost implementovat algoritmy co nejobecněji, aniž by při přechodu ke konkrétním typům došlo ke ztrátě efektivity. V případě, že zcela obecná forma algoritmu je v některých speciálních případech neefektivní nebo není použitelná, dát programátorovi možnost tyto speciální případy implementovat zvlášť. V případě, že k řešení určitého problému existuje několik rovnocenných algoritmů, poskytnout programátorovi možnost implementovat je všechny a dát tak uživateli na vybranou podle dalších kritérií. Typickým příkladem může být šablona funkce počítající minimum v C++: template // Obecný tvar algoritmu T Min(T a, T b) { return a < b ? a : b; } template<> // Zvláštní případ pro určitý char *Min(char *a, char *b) // datový typ { return strcmp(a, b) < 0 ? a : b; }
První je obecná šablona použitelná pro jakýkoli datový typ T, pro který je definován operátor <. (Nemusí jít o vestavěný typ; lze použít i typ, pro který je tento operátor přetížen.) Ovšem pro typ char*, který se používá pro práci se znakovými řetězci, nám jeho implementace nevyhovuje, neboť nepotřebujeme porovnávat numerickou
296
Miroslav Virius
hodnotu ukazatelů, ale znakové řetězce, na které tyto ukazatele ukazují. Proto definujeme ještě explicitní specializaci – implementaci algoritmu pro zvláštní případ. Tento příklad také ukazuje, že použití genericity nemusí být vázáno na kontejnery. 2.3
Implementace generického programování
Generické konstrukce mohou být implementovány mnoha různými způsoby. Podívejme se na tři z nich: Lze použít nástroj podobný preprocesoru jazyka C, v němž lze vytvářet makra s parametry. (Může, ale nemusí jít o součást překladače.) Generickou konstrukci, např. kontejner, naprogramujeme jako makro, v němž bude typ ukládaných hodnot vyjádřen parametrem; hodnotu tohoto parametru dosadíme před překladem. Přeložený program bude stále obsahovat konstrukci založenou na společném předkovi, tedy na univerzální třídě Object. Zavedeme však syntaktická pravidla, která umožní oznámit překladači, že při práci s touto konstrukcí požadujeme jistá typová omezení, silnější typovou kontrolu atd. Překladem generické konstrukce vznikne kód, který bude za běhu vytvářet instance (tedy datové typy nebo metody) podle předaných informací o typových parametrech. První dvě možnosti jsou v podstatě statické – genericita se uplatňuje pouze na syntaktické úrovni, tedy v době překladu, nikoli za běhu. Třetí možnost znamená dynamickou genericitu, při níž nemusí být požadované instance známy v době překladu.
3
Generické programování v C++, Javě a C#
Podívejme se nyní na způsob implementace generického programování v uvedených programovacích jazycích. 3.1
ISO C++
Jazyk C++ používá první z uvedených možností; na tom nic nemění skutečnost, že šablony nezpracovává preprocesor, ale překladač. Šablona v C++ představuje neomezenou množinu objektových typů, metod nebo volných funkcí.2 Takto vytvořené typy, metody nebo šablony se nazývají instance šablony a pro různé hodnoty parametrů představují různé typy, resp. metody nebo volné funkce v tom smyslu, že jim odpovídá různý strojový kód. Tento přístup má některé zajímavé důsledky: Parametry šablon v C++ mohou být nejen jakékoli datové typy, ale i číselné hodnoty, ukazatele, reference a dokonce i jiné šablony. Datový typ, použitý jako skutečný parametr šablony, nelze v C++ syntakticky omezit – to znamená, že z deklarace šablony nejsou zřejmé požadavky 2
Tedy funkcí, které nejsou metodami žádného objektového typu.
Generické programování v C++, Javě a C#
3.2
297
kladené na typy skutečných parametrů. Jejich porušení se pak při překladu často projeví jako podivná syntaktická chyba, zdánlivě nesouvisející se skutečnou příčinou. Nástroje pro generické programování poskytují možnost přesnější specifikace algoritmu nebo datové struktury pro speciální hodnoty parametrů (parciální a explicitní specializace, přetěžování šablon volných funkcí atd.) Šablony v C++ lze využít jako výpočetně úplný nástroj k programování překladače (generické metaprogramování, viz [4]). Instance šablon funkcí lze vytvářet implicitně. Implementace šablon klade mimořádné nároky na tvůrce překladače. V současné době např. téměř žádný překladač nevyhovuje plně standardu [1]. Při šíření šablon je třeba dodávat i zdrojový kód. Současné implementace jazyka C++ zpravidla neumožňují oddělený překlad šablon. To znamená, že nejen deklarace, ale i definice šablony musí být v místě použití viditelná. Úplná syntaktická kontrola šablony probíhá až při použití. (Standard [1] jazyka C++ sice zavádí klíčové slovo export, jehož použití by mělo umožnit oddělenou kompilaci, ale s plnou implementací se setkáme jen výjimečně, neboť vede ke značným problémům.)
Java 2, JDK 5
Jazyk Java 5 se opírá o druhý uvedený přístup k implementaci generického programování. Překlad parametrizované třídy, rozhraní nebo metody (volné funkce Java neobsahuje) je založen na procesu vymazání (erasure), který lze zjednodušeně popsat takto: Ze záhlaví třídy (resp. metody) se odstraní lomené závorky s parametry představujícími typ (tzv. formální typy). Všechna použití formálních typů v těle třídy se nahradí typem Object (popřípadě prvním typem uvedeným v omezeních daného parametru generické konstrukce). Výsledkem je surová třída (rozhraní, metoda), která se objeví v bajtovém kódu. Jméno surového typu vznikne ze jména parametrizovaného typu vypuštěním formálních typů; podobně jméno surové metody vznikne vypuštěním formálních typů ze jména parametrizované metody. Výsledkem je jediná třída, resp. jediná metoda se zesílenou typovou kontrolou. Vraťme se ke kontejnerům: Při vkládání překladač kontroluje, zda jsou předávané hodnoty odpovídajícího typu, a při vyjímání připojí automaticky přetypování z typu Object na typ daný typovým parametrem. Podívejme se na některá specifika tohoto přístupu v Javě 5: Formální typ lze v Javě 5 syntakticky omezit – to znamená, že z deklarace parametrizovaného typu nebo metody jsou zřejmé požadavky kladené na typy skutečných parametrů. To výrazně zpřehledňuje diagnostiku. Překlad je ve srovnání s C++ jednodušší. Vytvořený bajtový kód lze převést na bajtový kód pro starší typy virtuálního stroje Javy. (První testovací verze překladačů Javy 5 dokonce produkovaly bajtový kód, který bylo možno bez úprav spouštět na starších verzích JVM.)
298
Miroslav Virius
Generické třídy a třídy obsahující generické metody lze samostatně překládat (plná syntaktická kontrola generické konstrukce není závislá na kontextu použití). Mechanizmus parametrizovaných typů v Javě 5 zná tzv. žolíky. S jejich pomocí lze např. deklarovat metodu, jejímž skutečným parametrem bude instance parametrizovaného typu s libovolným parametrem. Parametry generických konstrukcí mohou být pouze objektové datové typy. Primitivní typy je třeba nahradit jejich obalovými třídami. Generické konstrukce založené na stejném surovém typu nelze rozlišit pomocí nástrojů reflexe. Formální typy nelze použít jako typy statických datových složek nebo jako typy ve statických metodách. V parametrizovaných třídách nelze vytvářet instance formálních typů. Typové parametry lze při volání generických metod za jistých okolností vynechat. To můžeme považovat za na analogii implicitního vytváření instancí v C++. Nejsou k dispozici parciální ani úplné specializace. Poznamenejme, že omezení, uvedená v předchozím výčtu, mají svůj původ v procesu vymazání typů.
3.3
C# 2.0β
Implementace nástrojů pro generické programování v C# vychází v podstatě z třetí možnosti, vede tedy k „dynamické“ implementaci. MSIL (bajtový kód prostředí .NET), který vznikne překladem generického typu nebo metody, obsahuje metadata, jež identifikují daný typ jako generický. Způsob použití se pak liší podle toho, zda programátor použije jako skutečný parametr hodnotový nebo referenční (odkazový) typ. V případě hodnotových typů vytvoří běhový systém jednu instanci3 pro každý jednotlivý typ parametru, a to v okamžiku použití – tedy např. deklarace instance. V případě odkazových typů vytvoří běhový systém v okamžiku prvního použití jednu instanci generického typu, která bude společná pro všechny odkazové typy. Řešení pro odkazové typy je velmi podobné jako v Javě 5. Důvodem je, že tak lze snadněji udržet kontrolu nad počtem instancí. Podívejme se opět na některé důsledky tohoto řešení. Generické konstrukce lze používat i pro atomické typy. Formální typ lze podobně jako v Javě 5 syntakticky omezit. Lze předepsat omezení na třídy, na hodnotové typy, na typu s bezparametrickým konstruktorem, na typy odvozené od daného typu nebo na typu implementující jedem nebo několik rozhraní. Instance generických typů lze rozlišit pomocí nástrojů reflexe.
3
Instance generického typu v C# je ovšem typ.
Generické programování v C++, Javě a C#
299
Generické třídy nebo třídy obsahující generické metody lze překládat samostatně, odděleně od použití. Generické metody mohou být přetěžovány na základě počtu typových parametrů. Nejsou k dispozici parciální ani úplné specializace. Při volání generických metod lze vynechat typové parametry, pokud si je dokáže překladač odvodit. Zavedení generických typů do C# (a do platformy .NET) vyžadovalo zásah do jazyka MSIL, do společného běhového systému CLR.
4
Shrnutí
Každý z uvedených jazyků přistupuje ke generickému programování jiným způsobem. Odlišnosti se týkají především způsobu překladu. V tomto příspěvku jsme se zabývali pouze vybranými charakteristikami nástrojů pro generické programování v jazycích C++, C# 2β a Java 2 (JDK 5). Následující tabulka přehledně shrnuje různé aspekty.
Oddělený překlad Explicitní specializace Parciální specializace Explicitní omezení typů parametrů Implicitní vytváření instancí Základní typy jako parametry Žolíky Přetěžování generických funkcí
C++ ne ano ano ne ano ano ne ano
Java 5 ano ne ne ano ano ne ano ne
C# 2β ne ne ne ano ano ano ne ano
Nástroje pro generické programování se ovšem stále vyvíjejí. Očekává se např., že připravovaná nová verze standardu jazyka C++ bude obsahovat rozšíření dovolených hodnot parametrů (např. že bude možno deklarovat šablony s hodnotovým parametrem typu double nebo že bude možné deklarovat šablonu deklarace typedef).
Poděkování Tento příspěvek vznikl v rámci grantů MŠMT Kontakt ME 492 a 1P04LA211.
Reference 1. International Standard ISO/IEC 14882:1998. Programming Languages — C++. 2. Dokumentace dodávaná s JDK 5.
300
Miroslav Virius
3. Generics in the Runtime (C# Programming Guide). http://msdn2.microsoft.com/en-us/library/f4a6ta2h 4. M. Virius: Fascinující svět šablon v C++. Ve sborníku Objekty 2004, ed. D. Ježek a V. Merunka, Česká zemědělská univerzita v Praze 2004, str. 305. 5. R. Garcia J., Järvi. A., Lumsdaine, J. Siek, J. Willcock: A Comparative Study of Language Support for Generic Programming. Ve sborníku OOPSLA’03, str. 115–134. 6. Hall James, Merunka Vojtěch, Polák Jiří et al., Accounting information systems Part 4: System development activities , 4th ed., Thomson South-Western New York 2004, ISBN 0-324-19202-9 Annotation. Generic programming in C++, Java and C#. A brief comparisson of generic programming tools in ISO C++, Java 2 (JDK 5) and C# 2.0 β programming languages is given. Implementation of tools for generic programming is shortly compared.
MSDN AA – neomezený počet licencí pro katedry a studenty za dostupnou cenu.
Academic Alliance Program Program MSDN Academic Alliance je navržen specificky pro katedry vysokých škol vyučující odbornou práci na počítači, akademické laboratoře a studenty oborů Programování, Počítače, Informační systémy, Informatika apod. Program usnadňuje a zlevňuje získání vývojových nástrojů, platforem a serverů společnosti Microsoft pro účely výuky, výzkumu a vývoje. V rámci programu získá katedra nejnovější verze software Microsoft a její studenti účastnící se kurzů si mohou bezplatně stáhnout software do svých osobních počítačů a používat jej k práci týkající se kurzů a osobních výukových projektů i mimo školu.
Základní informace o programu MSDN Academic Alliance je ročním členským programem pro školy, které vyučují nebo používají ve svých laboratořích Microsoft technologie. Licence mohou tímto způsobem získat oddělení, laboratoře a studenti oborů Programování, Počítače, Infomační systémy, Infomatika apod. Program významým způsobem zlevňuje získání vývojových nástrojů, operačních systémů a serverů společnosti Microsoft pro výuku, výzkum a vývoj nekomerčního charakteru.
Podrobnosti o členství Počáteční členský poplatek, na celý školní rok, pro oddělení (katedru) činí 799 USD, každý další rok pak 399 USD. (Katedra nebo škola zaplatí poplatek pouze jedenkrát, bez ohledu na počet učitelů, studentů nebo počítačů.)
Výhody členství • Přístup k nejnovější Microsoft platformě, serverům a vývojářským nástrojům prostřednictvím zasílaných CD nebo formou downloadu. • Elektronický distribuční systém pro studenty "e-academy" License Management System (ELMS) • Čtyři incidenty technické podpory (vedle volného přístupu do řízených diskusních skupin) • Dodatek licenční smlouvy pro koncové uživatele (EULA – End User License Agreement) pro MSDN umožňuje oddělením umístit na svých laboratorních počítačích, určených k výuce a nekomerčnímu výzkumu, libovolný počet kopií produktů zařazených do programu předplatného MSDN Academic Alliance. • Studenti účastnící se kurzů si mohou bezplatně stáhnout software do svých osobních počítačů a používat jej k práci týkající se kurzů a osobních projektů souvisejicích se školní výukou a vzděláním. • Webový server http://www.msdnacademicalliance.net pro účastníky programu MSDN AA poskytuje fakultám prostředky a podporu programu – registraci do programu a novinky – další prostředky, jako jsou projekty, učebnice, akademicky zaměřené články a technické rozbory (white papers) – speciální nabídky pro členy programu – software ke stažení – diskusní fóra pro učitele i studenty
Software zahrnutý do předplatného MSDN Academic Alliance obsahuje nejnovější verze produktů • Visual Studio • .NET Enterprise Servery. Zahrnuje Windows Server, SQL Server, Exchange Server, Commerce Server, BizTalk Server, Host Integration Server, Application Center Server, Systems Management Server • Všechny operační systémy Microsoft, včetně všech SDK a DDK • Betaverze, nové verze, aktualizace • Visio Professional
• MSDN Library • Dokumentace, technické články, ukázky kódu • Knihovna technické podpory Knowledge Base (znalostní báze) • 4× technická podpora pro nastavení a instalaci • Diskusní skupina Tech Support • Vývojové nástroje pro Windows CE • Měsíční dodávky software na CD s aktualizacemi
Požadavky • Vývojové nástroje mohou být používány pouze k výuce, nikoli k ziskovému výzkumu nebo k provozování infrastruktury oddělení • Členství je omezeno pouze na oddělení kvalifikované, neziskové, akreditované vzdělávací instituce zařazené do sítě (registru) škol ČR • Volné stahování je přístupné pouze studentům (mimo postgraduálních), účastnícím se výuky programování na katedře (ve škole), která je členem programu • Studenti nevlastní média, software mohou pouze instalovat ze serveru nebo použít CD z knihovny, kterou si katedra může vytvořit.
Další informace • http://msdn.microsoft.com/academic
• http://www.msdnacademicalliance.net
• http://www.microsoft.com/cze/education/
Kontakty a objednávka MSDN® Academic Alliance v ČR a SR Do programu MSDN Academic Alliance se lze zapojit v ČR a SR objednávkou ročního předplatného zajišťujícího zásilky potřebného software a jejich aktualizace.
Oficiální partneři v ČR a SR s oprávněním vyřídit potřebnou licenční smlouvu jsou: Computer Help, s.r.o. Blanická 16, 120 00 Praha 2, Czech Republic http://www.computerhelp.cz tel. +420 221 503 111, fax +420 221 503 333 Kontakt: Klára Lišková, [email protected] exe, s.r.o. Na Hrebienku 5, 811 02 Bratislava, Slovakia http://www.exe.sk tel. +421 (2) 67 296 111 Kontakt: [email protected]
Our Practice Our CIO Advisory Services practice is focused on the roles and responsibilities associated with information and technology leadership within commercial, private, and public enterprises. Our practice includes a wide spectrum of capabilities from corporate competitive strategy to specialty business operations to architectures to implementation and risk management. We maintain an unwavering focus on shareholder/stakeholder value in everything we do.
Our Services at a Glance • • • • •
Revenue (2004): 208 million USD 23 countries 500 professionals globally Active global network of 1,000+ professionals 483 projects during FY ‘04
Our Capabilities Service Offering
Description
Business and IT Strategy & Planning
Defining and integrating business and IT strategy and planning processes to continually assess current state market positioning and operational capabilities in order to exploit new opportunities and respond to threats.
IT Value Management
Formalizing the tools and processes needed to bring a shareholder/stakeholder value perspective and fiscal discipline to IT.
IT Transformation
Reshaping information and technology operations to achieve business/agency and IT goals. Guiding the organization through what can be turbulent--yet extraordinarily high value--change.
IT Sourcing Advisory
Examining IT cost structures and service levels, whether insourced or outsourced. Evaluating options to improve cost and service through internal adjustments or vendor selection, contract negotiation, sourcing, and effective transition.
IT Assessment & Due Diligence
Evaluating IT strengths and risk factors across a wide array of IT disciplines, whether for current leaders looking to improve the organization or for a potential buyer seeking to understand whether IT is likely to be an asset or a liability to the acquisition.
A practitioner reference guide to all Business IT Strategy, CIO Services and Portfolio Management materials
IT Governance
Institutionalizing the capacity to guide the formulation of IT strategy and plans, develop and implement initiatives, and oversee IT operations in order to minimize risk, maximize return, and build current and future value.
April 2005
Enterprise Architecture
Designing and adapting effective information and technology architectures to effectively fulfill today's needs and serve as tomorrow's foundation.
All content referenced in this guide can be accessed on the ‘CIO Advisory Services’ homepage: (https://km.deloitteresources.com/C14/CIO%20Services/default.asp
The Hitchhiker’s Guide to CIO Advisory Services
Version 4.1
We Address Executive Issues Issue
Stakeholders
Our Capabilities
Change in Business/Agency Strategy or Direction
CIO, CEO, CFO, COO
• • •
IT Strategy & Planning IT Transformation Enterprise Architecture
Realize Value From IT
CIO, CEO, CFO, COO
• • • •
IT Value Management Business IT Governance IT Strategy & Planning Enterprise Architecture
Establishing or Improving IT Governance
CIO, CEO, CFO, COO
• • • •
IT Value Management Business IT Governance IT Strategy & Planning Enterprise Architecture
Acquisitions, Mergers, Consolidation, and Divestitures
CEO, CFO, CIO
• •
IT Assessment & Due Diligence IT Sourcing Advisory
Cost Reduction
CIO, CFO
• • •
IT Sourcing Advisory IT Value Enterprise Architecture
Business/Agency Performance Improvement
CIO, COO, CEO
• • • • •
IT Strategy & Planning IT Value IT Sourcing Advisory IT Assessment & Due Diligence Enterprise Architecture
Complex Business/Agency Operations and Technology Change
CIO, COO
• • •
IT Transformation IT Sourcing Advisory Enterprise Architecture
Information and Technology Strategy
CIO, CEO, CFO, COO
• • • • • •
IT Strategy & Planning IT Value IT Transformation IT Sourcing Advisory Business IT Governance Enterprise Architecture
Transforming IT Support of the Business/ Agency
CIO
• •
IT Transformation Enterprise Architecture
Measuring and Improving IT performance
CIO
• •
IT Value Management IT Assessment & Due Diligence
Driving Regulatory Compliance
CIO, CEO, CFO, COO
• •
IT Transformation IT Assessment & Due Diligence
Risk Identification and Management
CIO, CEO, CFO, COO
•
IT Assessment & Due Diligence Enterprise Architecture
•
Example CIO Advisory Services Tools CIO Management Framework This tool depicts an integrated view of IT: from the role of IT through capabilities, processes, people, sourcing options, metrics/measures, and supporting tools. We use the Framework to help IT executives assess their organization’s capabilities and performance as well as address improvement opportunities.
The Enterprise Value Map The Enterprise Value Map™ is a practical way of looking at what companies can do and how those activities can drive improvements in shareholder value. The map is a powerful tool because it draws practical links between shareholder value and the things clients can do to improve it.
Portfolio Landscape Deloitte Consulting conducted many portfolio alignment initiatives to provide clients with a clear vision of their investment portfolio and to help clients optimize the value generated by their portfolio. To leverage our past experience, this tool was developed to address current and future needs in investment portfolio management.
Landscape MapIT Part of the Portfolio Landscape toolbox, this tool allows practitioners to produce a comprehensive view of a client's project / investment portfolio.
PMO in a box This set of tools allows practitioners to transform a client’s business strategy into a portfolio of effective programs and projects.
IT M&A Integration Toolkit A set of tools offering a complete approach to conducting M&A integration planning activities.
IT Due Diligence Overview The presentation explains the key objectives of a Due Diligence review to help company management identify and evaluate key risks in the target's IT function, and develop a roadmap for risk mitigation.
IT Assessment & Due Diligence Toolkit Toolkit offering a complete approach to conducting an IT Assessment and / or an IT Due Diligence effort. The toolkit provides a sample project plans, deliverables and presentations for such efforts.
IT Inventory Toolkit The IT Inventory Toolkit is a data capture toolkit that was developed by the Deloitte Team at Pitney Bowes. This tool provides comprehensive capture maintenance and analysis of critical business and technology architecture components.
IT Transformation Toolkit Lessons learned from IT Transformation efforts and examples how to use in relation to the IT Resource Management Toolkit.
IT Resource Management Toolkit Examples of project plans, deliverables and presentations required to successfully complete an IT Resource Management or IT Transformation effort.
Roadmaps Visual overview of the various components involved in assessing and evaluating the IT effort. Topics include: • Outsourcing • Portfolio Management • IT Transformation • Information Management • IT Structural Cost Reduction
Workshops Templates to walk through Day One activities. Topics include: • IT Prioritization • IT Value
Poznámky:
Poznámky:
Poznámky:
Editor:
Václav Snášel
Název:
Objekty 2005
Místo, rok, vydání:
Ostrava, 2005, 1.
Počet stran:
324
Vydavatel:
VŠB – Technická univerzita Ostrava, 17. listopadu 15, 708 33, Ostrava–Poruba
Tisk:
TiskServis Jiří Pustina Petra Křičky 24, 702 00 Ostrava 1
