OBJEKTY 2005 - Katedra informatiky FEI VŠB-TUO · 2006-01-31 · Objekty 2005 c Václav Snášel,...

OBJEKTY 2005sborník příspěvků 10. ročníku konference

Fakulta elektrotechniky a informatiky,VŠB – Technická univerzita Ostrava

ISBN 80-248-0595-2

konference

OBJEKTYOBJEKTY 2005

http://www.cs.vsb.cz/objekty/2005

10. ročník konference, Ostrava, 24. – 25. listopadu, 2005sborník příspěvků

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í aKatedra 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 2005c© 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.

Technická redakce:Dušan Fedorčák, Pavel Gavlovský, David Ježek, Jan Kožuszník, Martin Lasoň,Svatopluk Štolfa, Zdeněk [email protected], [email protected], [email protected],[email protected], [email protected], [email protected],[email protected]

Katedra informatiky, Fakulta elektrotechniky a informatiky,VŠB – Technická univerzita Ostrava

Počet stran: 324Náklad: 100 ksVydání: 1.Rok vydání: 2005

Pro sazbu a sestavení sborníku byl použit systém LATEX.Obálku navrhl Tomáš Skopal, [email protected] 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 hoteluZámeček Ostrava.

Hlavním tématem letošního ročníku konference bylo „zavádění moderníchtechnologií 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 nejenpro 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ýchoborů rovněž postupně prosazuje i mimo vlastní „Computer Scienceÿ, jako jenapří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ímpřístupem k diskutované problematice a přátelskou pracovní atmosférou. Jsmetaké rádi, že některá témata jako například návrhové vzory, modelovací jazykUML, 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íkutaké 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, žedesátý ročník celostátní konference OBJEKTY 2005 splní svůj účel a přispěje kvý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 Os-trava – vedle jeho předsedy Davida Ježka bych chtěl poděkovat i VojtěchoviMerunkovi 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ášelpř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ředsedaVá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 Ostrava17. listopadu 15, 708 33, Ostrava-Poruba24. – 25. listopadu, 2005

http://www.cs.vsb.cz/objekty/2005http://www.cs.vsb.cz/objekty

IX

Sponzoři

Konferenci Objekty 2005 částečně finančně podpořily tyto organizace:

Microsoftr Česká republikahttp://www.microsoft.cz

Deloitte Deloitte.http://www.deloitte.com

Sun Microsystems CZhttp://www.sun.com

Mediálním partnerem konference Objekty 2005 je:

COMPUTERWORLDhttp://www.computerworld.cz

X

Obsah

Zvané přednášky

WWWW - How to Get Value from Processes and Systems (keynotespeech) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Jiří Polák

Objektové programování v jazyce R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Ladislav Beránek, Václav Novák

Projekt LINQ a jazyk C# 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Dalibor Kačmář

Modelování podle metody BORM pomocí nástroje Craft.CASE . . . . . . . . . 10Vojtěch Merunka

Začlenění návrhových vzorů do výuky programování . . . . . . . . . . . . . . . . . . . 26Rudolf Pecinovský

Referáty

Podpora výuky softwarového inženýrství a informačních systémů . . . . . . . . 42Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček

Issues in Static Verification of Component Substitutability . . . . . . . . . . . . . 54Přemysl Brada

Agilní modelování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Alena Buchalcevová

Izolácia všeobecných častí vzoru Composite . . . . . . . . . . . . . . . . . . . . . . . . . . 74Jaroslav Jakubík

Thread Local Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Aleš Keprt

Třídy mobilních objektů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Tomáš Kozel

Využití vzorů v širších souvislostech softwarového procesu . . . . . . . . . . . . . . 104Miloš Kudělka, Vladimír Sklenář

II

Řízení projektů v metodě BORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Branislav Lacko

Využití OCL k popisu vztahů mezi přístupovými právy a rolemi . . . . . . . . 122Martin Lasoň, Pavel Gavlovský

Krátký úvod do metodiky (Rational) Unified Process pro vývojsoftwarového produktu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Štěpán Macura

Podpora výuky objektově orientovaného programování . . . . . . . . . . . . . . . . . 147Filip Malý

Podpora aplikační logiky v J2EE aplikačních rámcích . . . . . . . . . . . . . . . . . . 157Petr Matulík, Tomáš Pitner

Podstata konceptuálního modelování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Martin Molhanec

Formální pohled na vztah mezi refaktoringem, návrhovými vzory anormalizací objektů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Oldřich Nouza

Objektové principy a SQL databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Helena Palovská

Nástroje procesního modelování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Martin Papík

Metody testování použitelnosti softwarových produktů . . . . . . . . . . . . . . . . . 209Josef Pavlíček

Zkušenosti s přístupem object-first v úvodním kursu programování . . . . . . 217Jarmila Pavlíčková, Luboš Pavlíček

Systém pro vývoj distribuovaných aplikací Plaant . . . . . . . . . . . . . . . . . . . . . 231Rudolf Pecinovský, Vladimír Lahoda

Použití transformací v metodě BORM v nástroji Craft.CASE 2.x . . . . . . . 241Marek Pícka, Robert Pergl

Standardy XML webových služeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Martin Smítka

Metody odhadu složitosti Feature Point a Funtion Point . . . . . . . . . . . . . . . 261Zdeněk Struska

Moderní přístup koncepčního a programového řešení agrárního WWWportálu Agris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Pavel Šimek, Jiří Vaněk, Jan Jarolímek

III

Využití adaptivního hypermediálního systému AHA! při výuceprogramovacího jazyka C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Zdeněk Velart, Petr Šaloun

Krátké referáty

Akademické programy společnosti Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . 290Dalibor Kačmář

Architektura systému Plaant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Vladimír Lahoda, Rudolf Pecinovský

Arichektura systému Agris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Vladimír Lahoda, Rudolf Pecinovský

Generické programování v C++, Javě a C# . . . . . . . . . . . . . . . . . . . . . . . . . . 293Miroslav Virius

Rejstřík autorů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

WWWW - How to Get Value from Processesand Systems

Jiří Polák

[email protected]

WWWW – How to Get Value from Processes and Systems (keynote speech)

Jiří Polák,

Deloitte [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é programování v jazyce R

Ladislav Beránek, Václav Novák

Katedra informatiky, PF, JCU Jihočeská univerzita v Českých Budějovicích,Jeronýmova 10, 371 15 České Budejovice

[email protected]

Objektové programování v jazyce R

Ladislav Beránek, Václav Novák

Katedra informatiky, PF, JCU – Jihočeská Universita, České Budějovice, Jeronýmova 10, 371 15 České Budějovice [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ů”.


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 Objektové programování v R

3.1 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"


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


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


> 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á


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-387-

95475-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/.

Projekt LINQ a jazyk C# 3.0

Dalibor Kačmář

Microsoft CZ [email protected]

Projekt LINQ a jazyk C# 3.0

Dalibor Kačmář

Microsoft CZ s.r.o. [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.


Modelování podle metody BORM pomocínástroje Craft.CASE

Vojtěch Merunka

Katedra informačního inženýrství, PEF, ČZU [email protected]

Modelování podle metody BORM pomocí nástroje Craft.CASE

Vojtěch Merunka

Katedra informačního inženýrství, PEF, ČZU Praha

[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


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


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


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.


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


4.5 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 Vojtěch Merunka

5 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ů


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 Vojtěch Merunka

6 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í.


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. 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“.

2. 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ů.

3. 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]

4. Přidání fáze softwarového návrhu pro různá implementační prostředí. 5. 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.


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 80-88786-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 Object-Oriented 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ýukyprogramování

Rudolf Pecinovský

Amaio Technologies Inc.Třebohostická 14, 100 00 Praha 10

[email protected]

Začlenění návrhových vzorů do výuky programování

Rudolf Pecinovský1

1Amaio Technologies Inc., 100 00 Praha 10, Třebohostická 14 [email protected]

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 po-lovič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 uka-zuje 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 objek-tový 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ře-ných otázek.

Klíčová slova: OOP, návrhové vzory, výuka programování, vstupní kurzy pro-gramová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 ni-mi 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ředsta-vit, 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 kon-strukce programů ve strojovém kódu a následně ve vyšších programovacích jazycích.


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 progra-má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ře-devší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 ved-lejší 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ě ja-zyka 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, ja-ký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 zna-lostmi studentů.

28 Rudolf Pecinovský

1.2 Současná převažující podoba přístupu „Nejdříve objekty“

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ší pro-blém pouze částečně. Žáci sice od samého začátku pracují s objekty a navrhují pro-gramy, v nichž se učí definovat třídy tak, aby byly jednoduché, kompaktní a minimál-ně 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 ja-ko náhražka násobné dědičnosti. O návrhových vzorech, které jsou považovány za je-den z pilířů současného programování, nepadne ani slovo. Stejně tak autoři nijak ex-plicitně 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 pre-zentovat 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 demon-strovat současné trendy a především pak použití návrhových vzorů. Na přelomu stole-tí 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 kte-rý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é vzo-ry a takové principy, jako programování proti rozhraní a další, lze aplikovat i při řeše-


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 Návrhové vzory použité na samém počátku výuky

2.1 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é progra-má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 stu-denti s předchozími neobjektovými programátorskými zkušenostmi v prvních hodi-ná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 ne-naučí 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ší in-terpretovat 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 struk-turu nějakého předem připraveného programu a ujasní si vzájemné závislosti a in-terakce jednotlivých tříd a jejich instancí. Protože je program předem připravený, ne-musí 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ší pro-stř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 ško-lách prvním domácím úkolem.


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žíva-né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é defi-nujeme 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í me-tody 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í in-stance vůbec vyrobit nešlo. Vysvětlíme si, že třída P je typickým reprezentantem kni-hovní 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é roz-hraní 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.


2.5 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še-ní, 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 do-plň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žadova-nou činnost, pak mohou pouze zavolat příslušnou metodu služebníka a předat mu ob-sluhovanou instanci jako parametr.

Aby mohl služebník danou instanci správně obsloužit, mívá většinou nějaké poža-davky na její schopnosti. Vedle třídy služebníka proto definujeme také rozhraní (na-zvě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řeb-ný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 ne-dokáž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ši-nou bývá definován jako instance – často jako jedináček.

Obr. 1. Diagram tříd návrhového vzoru Služebník.


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 pra-vé 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žado-vá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 meto-dá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 defi-nované 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 hodno-tu. 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 je-jich instance plynule přesouvají po plátně. Ti, kteří ve svých třídách použili při im-plementaci 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řed-nictvím cyklu, tuto schopnost ovládat nebudou.


2.7 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 naprogra-movat plátno tak, aby se objekty neodmazávaly, ale takto můžeme před studenty pře-destří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 nej-prve 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 me-tody nakresli(Kreslítko), po jejímž zavolání se příslušná instance dodaným kres-lítkem nakreslí. Metoda pro přidání dalšího objektu mezi spravované je pak deklaro-vá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řekres-lová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 nakres-leny 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 ak-tivní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 aktiv-ního plátna, tj. vzdálenosti čar této sítě.


Třídy, jejichž instance se mají přizpůsobovat změnám kroku aktivního plátna, mu-sí 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ři-hláš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 mi-mochodem jedináček) může přesouvat několik instancí rozhraní IPosuvný. Je-li pře-souvaný objekt instancí rozhraní IMultiposuvný, vyvolá Multipřesouvač po přesu-nutí 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 rekur-zivní 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é ob-jekty o kousek k jejich zadaným cílovým pozicím, přemístí i staronově zařaze-nou 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 ob-jektové pozadí jim poněkud uniká.

• Vyučujícímu zabere zbytečně moc času testování správnosti řešení požadova-né funkčnosti.

• Chce-li vyučující prověřit pochopení celého zadání studentem a požádá-li stu-denta 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 na-vrhnou pouze předem zadané metody třídy Výpočet.


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 mno-hem 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 rozhra-ní. To přináší řadu výhod.

Tím, že CPU a GUI zastupují ve vzájemné komunikaci jimi implementovaná roz-hraní 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


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ývo-jové prostředí BlueJ, které na kurzech používáme, takovou třídu nepotřebuje. Pro úče-ly 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 konstruk-toru 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í in-stance 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í me-tody getOperace()) a seznam testovacích kroků, jimiž je možno příslušnou CPU otes-tovat. 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 pro-jektu 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 popi-sek 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.


4 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 objek-tů 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 sku-teč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 ob-jektů 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é de-finovat 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 ty-pu. 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.


4.4 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ě, reali-zují 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 neje-nom 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 mati-cové výpočty. Vše pak bude dirigovat řadič (také CPU), který rozlišuje reakci na pře-pí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.


Obr. 4. Diagram tříd kalkulačky demonstrující návrhový vzor Strategie.

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 kal-kulač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ě jednodu-chý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ů pro-gramová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ě na-uč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 ori-entovat na pouhé OO paradigma. OOP je sice vynikající metodika pro tvorbu a


správu rozsáhlých programových systémů. Vedle ní ale existuje ještě lepší me-todika: 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é schop-nosti 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 proti-vá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ě oriento-vané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ě oriento-vané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ývo-je, 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é stu-denti 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.

Reference

1. BARNES David J.; KÖLLING Michael: Objects First with Java: A Practical In-troduction Using BlueJ – 2 editionnd . Prentice Hall, 2005, ISBN: 0-13-124933-9.

2. BLOCH, Joshua. Effective Java – Programming Language Guide. Addi-son-Wesley Professional © 2001. 252 s. (Přeloženo [3]). ISBN 0-201-31005-8

3. BLOCH, Joshua. Java efektivně – 57 zásad softwarového experta. Praha: Grada © 2002. 230 s. (Překlad [2]). ISBN 80-247-0416-1

4. FREEMAN Eric; FREEMAN Elisabeth: Head First Design Patterns. O’Reilly, © 2004. ISBN 0-596-00712-4.


5. GAMMA, Erich; HELM, Richard; JOHNSON Ralph; VLISSIDES, John. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, © 1995. 396 s. (Přeloženo: [6]) ISBN 0-201-30998-X.

6. GAMMA, Erich; HELM, Richard; JOHNSON Ralph; VLISSIDES, John. Návrh programů pomocí vzorů. Stavební kameny objektově orientovaných programů. Praha: Grada, © 2003. 386 s. (Překlad [5]). ISBN 80-247-0302-5.

7. PECINOVSKÝ Rudolf: Myslíme objektově v jazyku Java 5.0, Grada, 2004. ISBN 80-247-0941-4.

8. PECINOVSKÝ Rudolf: Výuka objektově orientovaného programování žá-ků základních a středních škol, Objekty 2003 – sborník příspěvků osmého ročníku konference, VŠB, Ostrava 2003. ISBN 80-248-0274-0.

9. PECINOVSKÝ Rudolf: Jak při výuce Javy opravdu začít s objekty. Objekty 2004 – sborník příspěvků devátého ročníku konference, ČZU, Praha 2004. ISBN 80-248-0672-X.

10. PECINOVSKÝ Rudolf: Proč a jak učit OOP žáky základních a středních škol. Ži-linská didaktická konferencia, 2004, Žilina.

11. PECINOVSKÝ Rudolf: Jak efektivně učit OOP. Tvorba softwaru 2005 – sborník přednášek. ISBN 80-86840-14-X.

Annotation

At first the paper shortly informs about six main implementation strategies for intro-ductory programming courses. Then it concentrates on object-first strategy, which starts the whole course working with objects and consistent explanation of object ori-ented programming principles. The paper criticizes the inconsistency of published les-sons and textbooks and shows how to apply the declared principles better and consis-tently. The key part of the paper demonstrates on the concrete examples how to pro-ceed with lessons, which from the very beginning teach the true object oriented pro-gramming, 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 ex-ams 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 ad-vantageous both for the students and for the teacher. In the last part it notes some de-sign 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 softwarového inženýrství ainformačních systémů

Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček

Katedra informatiky, FEI, VŠB Technická Univerzita Ostrava,17. listopadu 15, 708 33, Ostrava-Poruba

{marek.behalek, lumir.navrat, michal.radecky, tomas.turecek}@vsb.cz

Podpora výuky softwarového inženýrství a informačních systémů

Marek Běhálek1, Lumír Návrat1, Michal Radecký1, Tomáš Tureček1

1Katedra informatiky, FEI, VŠB – Technická Univerzita Ostrava, 17. listopadu 15, 708 33, Ostrava-Poruba

[email protected] [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.


Podpora výuky softwarového inženýrství a informačních systémů 43

2 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 Marek Běhálek, Lumír Návrat, Michal Radecký, Tomáš Tureček

3 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


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;


• 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 – multi-dotazová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].


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


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/JSR-220. 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.


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.


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


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


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.


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 Verification of ComponentSubstitutability

Přemysl Brada

Department of Computer Science and Engineering,University of West Bohemia in Pilsen,30614 Pilsen, Czech Republic

[email protected]

Issues in Static Verification of Component Substitutability

Premysl Brada

Department of Computer Science and Engineering, University of West Bohemia in Pilsen,

30614 Pilsen, Czech Republic [email protected]

Abstract. Components are an efficient means of implementing software appli-cation, 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 sys-tem 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 practi-cal, 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 compo-nents. The term component is used here in the standard definition [9,10] as a black-box 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 functional-ity. Techniques and tools for checking the replacement components for substitutabil-ity 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


Issues in Static Verification of Component Substitutability 552 Premysl Brada

of checking components for safe replacement. Section 3 describes the details of com-paring 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 ex-pected, 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 be-cause they provide a superset of features.

Since component interfaces are defined in terms of programming language con-structs (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 char-acter 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(); }

interface Logging { // v2 void write(String msg); void writeMany(String msgs[]); long countLogItems(); }

Comparison of structured types is then in our approach done by combining the dif-ferences 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 gen-eralization 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 inter-faces 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 contravari-ance: 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


− 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 write-Many() 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 sub-typing-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);}

interface Reading { // v2 short readInteger(); String readStr(long chars); }

However, when Reading version 1 is used in a Java client, and a server compo-nent 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 up-grade 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.


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 Java-Beans (EJB) applications, since the EJB model is widely used in industry and applica-tion 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 functional-ity 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 trans-action (SessionBeans), persistence and reentrancy (Entity), or message type (Mes-sageDriven). 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 compo-nent interface specifications, because the evaluation of incomplete interface defini-tions 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 intro-spection, resulting in duplication and making EJB use prone to errors; the prime ex-ample 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.


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 dif-ficult 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 comple-mentary 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 neces-sary from the substitutability point of view.

Table 3. EJB feature subtyping rules (E = Entity, S = Session, M = MessageDriven, A = all)

Feature Bean Role Type compared Diff required attribute E P+R Name, type { none } business interface A P Java interface { none, insertion } business reference A R Java interface { none, deletion } environment entry A P+R Name, type { none } home interface A P Java interface { none, insertion } home reference A R Java interface { none, deletion } message activation M P Java interface n/a message consumed M P Type { none, insertion } message destination ref A R Name, type, tag { none, deletion } + resource reference A R Name, type { none, deletion } resource manager A R Name, type, tag { none, deletion } + security role A P Name { none } timer service reference A R Java interface { none, deletion } web service endpoint S P Java interface { none, insertion } web service ref A R Name, interface { none, deletion }

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


comparison (for other carriers, completely different set of properties could be speci-fied, rendering the comparison useless).

Table 4. EJB tags subtyping rules

Tag Bean Type compared Diff required message type M Java { none, insertion } persistence E Enumeration { none } reentrancy E Enumeration { none, spec } schema E Name n/a security id A Enumeration n/a state S Enumeration { none, spec } transaction S,M Enumeration { none }

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 as-signed 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, Mes-sageDriven) for equality. If not equal, exit.

2) Compare the same provided features of A and B according to the Type com-pared 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 sub-section 2.1,

ii) Combine all differences of required features in the same way,


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 sub-stitute 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 desig-nated components, performs the comparison and outputs a XML file with the com-parison 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 dif-ferences 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 verifi-cation of component substitutability, with special emphasis on Java-based component platforms. We have described the basis for the appropriate checks, which is the sub-type 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-


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 im-plementation 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 sys-tem 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.


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 me-

chanism or what like is and isn’t like. In Proceedings of the European Conference on Ob-ject-Oriented Programming (ECOOP), pages 55–77. Springer-Verlag, 1988.

Agilní modelování

Alena Buchalcevová

Katedra informačních technologií VŠE Prahanám. W.Churchilla 4, Praha 3

[email protected]

Agilní modelování

Alena Buchalcevová 1

1 Katedra informačních technologií VŠE Praha nám. W.Churchilla 4, Praha 3

[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í, metodika, Agilní modelování, Extrémní programování, vývoj softwaru

1 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.


Agilní modelování 65

2 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 vysvětlení Nejdůležitějším úkolem je vytvořit fungující software

cílem není vytvářet modely, ale vytvořit kvalitní software, který odpovídá potřebám zákazníka

Druhým nejdůležitějším úkolem je umožnit další práci na projektu

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ý

Obsah je mnohem důležitější než každý model může být reprezentován různými


Principy agilního modelování princip vysvětlení reprezentace

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

Jednoduchost

nejjednodušší řešení je nejlepší řešení

Komunikace

hlavním smyslem modelování je komunikace mezi členy týmu navzájem i se zákazníky a zájmovými skupinami

Modelovat za určitým účelem

modely by se měly vytvářet jen když je jasné, pro koho je model určen a proč

Uchopit změnu

změny nastávají, je třeba je akceptovat

Změny je třeba dělat přírůstkově

je lepší měnit systém po malých částech než provést jednu všezahrnující změnu

Je třeba se učit od druhých

nikdo nemůže znát vše, je třeba se učit od druhých a rozvíjet své znalosti

Znát své modely

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

Přizpůsobení metodiky

metodiku je třeba přizpůsobit podle konkrétních podmínek

Maximalizovat výnosy z investic

je třeba maximálně zhodnotit vynaložené prostředky

Více modelů

k dispozici je široké spektrum modelů , je třeba použít nejvhodnější

Otevřená komunikace

lidé se musí cítit volní, díky otevřené komunikaci mohou dělat lepší rozhodnutí

Důraz na kvalitu 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

Rychlá zpětná vazba 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

Cestovat nalehko

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

Řídit se instinkty lidí

lidé se snaží dělat vše pro dobro věci, je dobré využít jejich tacit znalostí


3.3 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 vysvětlení Aktivní účast investorů

úspěch projektu často závisí na aktivní účasti investorů – vedení podniku, operativní pracovníci, jiné týmy

Používání standardů při modelování

je třeba používat obecné standardy modelování

Využívání vzorů

je třeba používat architektonické, návrhové a analytické vzory

Používání správných artefaktů

artefaktů je velké množství a je třeba vybrat vhodný pro daný účel

Kolektivní vlastnictví

odvozena od praktiky extrémního programování umožňuje každému pracovat na libovolném modelu

Testovat modely

testování je základní prostředek vytváření kvalitního software, je třeba testovat i modely

Paralelní vytváření různých modelů

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ů

Jednoduchý obsah

je třeba se snažit o jednoduchost obsahu modelů

Jednoduché zobrazení 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

Odstranění dočasných modelů

většina vytvářených modelů je dočasná, když splní svůj účel, je třeba je zrušit

Veřejné vystavení modelů

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

Modelování v malých přírůstcích

souvisí s přírůstkovým vývojem, není možné vytvořit detailní model předem, ale vytváří se postupně

Modelování pro komunikaci smyslem modelování je komunikace v týmu, se zákazníkem, s vedením


Praktiky agilního modelování praktika vysvětlení Modelování pro pochopení smyslem modelování je pochopení problému Je nebezpečné modelovat sám 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

Testování modelů kódem

model je abstrakce, pro zjištění, zda bude skutečně fungovat, je třeba napsat kód

Znovupoužití existujících zdrojů

je třeba využívat hotové modely, vzory

Úprava jen, když je to nezbytné úpravy modelů jsou náročné a měly by se realizovat, jen když je to nezbytně nutné

Používání nejjednodušších nástrojů

většina modelů může být malována na tabuli

4 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.


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.


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


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. Ambler, S. W.: Debunking Modeling Myths, August 2001, Software Development. 2. Ambler, S.W.: The Fragile Manifesto, Software Development, August 2002. 3. Ambler, S.W.: Something’s Gotta Give, Software Development, March 2003. 4. 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


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 častí vzoru Composite

Jaroslav Jakubík

Ústav informatiky a softvérového inžinierstva, FIIT, Slovenská technická univerzita vBratislave

Ilkovičová 3, 842 16, Bratislava, [email protected]

Izolácia všeobecných častí vzoru Composite

Jaroslav Jakubík

Ústav informatiky a softvérového inžinierstva, FIIT, Slovenská technická univerzita v Bratislave, Ilkovičová 3,

842 16, Bratislava, Slovensko [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


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


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


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.


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.


4.1 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.


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.


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.


6 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-0913-designpatterns.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.


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 Local Storage

Aleš Keprt

Katedra informatiky, PrF, Univerzita Palackého, [email protected]


Aleš Keprt

Katedra informatiky, PřF, Univerzita Palackého, [email protected]

Abstrakt. Všechna vlákna v rámci jednoho procesu sdílejí stejný ad-resový prostor. Výjimkou je Thread Local Storage (TLS), lokální da-tový prostor každého vlákna. TLS je vhodným doplňkem objektově ori-entovaného programování. Princip, kterým umožňuje navzájem oddělitproměnné (obecně paměť) v jednotlivých vláknech, je možné nahradit iklasickými prostředky OOP, ale s pomocí TLS můžeme psát některé kon-strukce paralelních výpočetních programů jednodušeji, stručněji a pře-hledně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í veWindows 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). Jeli-kož adresový prostor je vztažený vždy k jednomu procesu, všechna vlákna v pro-cesu 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ílenoupaměť 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í to-hoto typu se objevuje potřeba rozlišovat data sdílená mezi vlákny a data vláknuvlastní. Způsobů, jak zajistit, aby vlákno mělo k dispozici kromě sdílené pamětitaké 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 vy-užít prostřednictvím funkcí operačního systému; některé překladače C/C++ (apravdě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 jemož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.


86 Aleš Keprt

2 Kontext – lokální paměť vlákna bez podporyoperač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 ave 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 po-tř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ímprogramování (vkládání vlastního kódu do kódu cizích knihoven, např. iterátoryv jazyku C#), apod. Další nevýhodou je, že je zde porušen princip odpovědnostitříd, neboť některá data jsou z čistě implementačních důvodů vyčleněna mimotří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ýchkontextů, 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ě, dostanuse 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 pod-porou operačního systému umožňuje používání lokální paměti vláken bez nut-nosti 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í prokaž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 verzioperač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 factovolný 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říkladtypu 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ůjlokální objekt z TLS. Pokud s ním bude pracovat déle, je vhodné si jej uložitdo 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ýchfunkcí. 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.h>pthread_key_t *key;

3

88 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*);

2. Každé vlákno při své inicializaci vytvoří lokální proměnnou (zde pro příkladtypu MyClass – do TLS ukládáme pointer na skutečný objekt).pthread_setspecific(index, new MyClass());

3. Při práci se svou lokální proměnnou si vlákno nejprve přečte pointer na svůjlokální objekt z TLS. Pokud s ním bude pracovat déle, je vhodné si jej uložitdo běžné lokální proměnné metody (tj. na zásobník, mimo TLS).MyClass *objekt = (MyClass*)pthread_getspecific(index);

4. Při ukončování vlákna je třeba uvolnit alokovaný objekt.delete (MyClass*)pthread_getspecific(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.)pthread_key_delete(index);

Zde popsané fungování TLS v Linuxu je možno použít na všech systémech pod-porujících POSIX (viz [1]). Narozdíl od TLS ve Windows umožňuje POSIXpoužívání destruktorů, což je velmi praktické, neboť to zjednodušuje uvolňo-vání dynamicky alokovaných objektů odkazovaných z TLS. Knihovnu pthreadsje 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í tedyz hlediska aplikací na úrovni operačního systému. Proto také sama nabízí funk-cionalitu 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 jsouzde uváděny v jazyce C#.Platforma .NET je plně objektová, místo TLS indexů se zde používají ob-

jekty 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 (viztaké [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říkladtypu MyClass) a do TLS uloží referenci na tento objekt.Thread.SetData(slot, new MyClass());

4


3. Při práci se svou lokální proměnnou si vlákno vytáhne referenci na svůjlokální objekt z TLS. Pokud s ní bude pracovat déle, je vhodné si ji uložitdo 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 tedyde 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ě inicializovanoupromě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 Win-dows, 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ácis 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. Tenpodporuje stejnou funkcionalitu jako Visual C++, ovšem s lehce jiným způsobemdeklarace – 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 verzeGCC 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 syntaktickoupodporou 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 imple-mentová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ímjedinců 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éhodě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 dvou-procesorový nebo dvoujádrový), největšího zrychlení dosáhneme, právě když sezaměříme na paralelizaci pseudo–dělení binárních matic nebo ohodnocování je-dinců populace. Druhá varianta se ukazuje jako mnohem snazší – jelikož jednot-liví jedinci v populaci jsou na sobě navzájem nezávislí, můžeme dělení provádětparalelně 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 dis-pozici jeden registr procesoru navíc pro optimalizace kódu a všechny pro-mě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) sta-tická 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šechnysoučá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 (čiliumístěné na TLS).V našem případě umístíme na TLS především matici nejlepšího jedince, kte-

rého během výpočtu najdeme (toto zapamatování je požadováno algoritmem, vizvýše). Matice nejlepšího jedince je uložena v běžném poli. Používali-li bychomjen jedno pole pro všechna vlákna, museli bychom během výpočtu provádět syn-chronizaci vláken pomocí kritické sekce, aby byl zaručen konzistentní stav tohoto

6


pole. Časté používání kritických sekcí zpomaluje vlastní výpočet. Alokujeme-lipro každé vlákno samostatné pole pro uložení matice nejlepšího jedince, vícevlák-nový 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 tolze jednoduše implementovat pomocí tzv. interlocked operací (tj. bez kritickýchsekcí).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 TLSv překladači C++ je kód i velmi přehledný a je využita silná typová kontrolajazyka (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 proce-sory 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, ne-

boť obojí je vhodné pro každodenní programování. TLS přitom zasahuje doprincipu objektově–orientovaného programování (OOP), neboť deklarace pro-mě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 optimalizacekó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:


The threads of a single process all share the same address space. But there is oneexception to this rule: the Thread Local Storage (TLS), the local data space of athread. TLS may be used as a handy addition to object oriented programming.The separation of variables (generally any data) of particular threads may bealso 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 objektů

Tomáš Kozel

Katedra informatiky a kvantitativních metod, Fakulta informatiky a managementu,Univerzita Hradec Králové

Rokitanského 62, 500 03 Hradec Králové[email protected]

T°ídy mobilních objekt·

Tomá² Kozel

Katedra informatiky a kvantitativních metodFakulta informatiky a managementu

Univerzita Hradec KrálovéRokitanského 62, 500 03 Hradec Králové

[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 velmiz°ídka a to jednak neuv¥dom¥le jako vedlej²í efekt pouºití distribuo-vaných objekt· nebo cílen¥, ale zatím p°edev²ím v experimentálníchpodmí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 budekladen d·raz na pouºitelnost t¥chto t°íd mobilních objekt· p°i imple-mentaci softwarových aplikací.

Klí£ová slova: Mobilní objekt, mobilní agent, RMI, Java.

1 Úvod

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²e-ními. Vývojá°i jsou zvyklí automatizovan¥ p°evád¥t modely s p°irozenými prvkymobility na modely distribuované, aniº by si mobilitu a existenci mobilních ob-jekt· uv¥domovali. V²e p°ipomíná d°ív¥j²í £asy, kdy problémy objektového sv¥tabyly 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ýchaplikací, 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í. Rela-tivn¥ nejdále je vyuºití mobility v oblasti softwarových agent·, které v²ak £astobývají implementovány i jinak neº objektov¥. Jejich objektová implementace jepak 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 sikaºdý £tená° uv¥domil potencionální moºnosti softwarové mobility a zamyslelse 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ál-ného sv¥ta, které se dle stanovených kritérií rozd¥lí n¥kolika skupin (t°íd). Ná-


Třídy mobilních objektů 93

sledn¥ budou pojmenovány jejich charakteristické znaky. Tento rozbor si nekladeza 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, au-tobus, po²tovní balík, letadlo, student, kniha, se²it, notebook, hasi£, dealer, záso-bova£, 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 cho-vání vybraných mobilních objekt·.

1. Jakým zp·sobem je migrace iniciována:

� ºádost/pozvání vzdáleným systémem,� iniciativa lokálního systému,� iniciativa objektu, ...

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 Tomáš Kozel

2.3 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 inici-ována odesílatelem. Objekt je po doru£ení archivován nebo zaniká. Cílovéprost°edí je p°ipraveno nebo schopno zásilky p°ijímat. P°íklady: dopis, ba-lík, fax, email.

� Tazatelé - objekty, jejichº ú£elem je data v cílovém prost°edí získávat. Inici-á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¥rudat 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ía v nich zanechávají dopravované objekty. P°íklady: autobus, dealer, leta-dlo, nákladní vozidlo.

� Experti - objekty poskytující n¥jakou sluºbu, která v cílovém prost°edí nenídostupná. O sluºby experta ºádá cílové prost°edí a po vykonání sluºby seexpert 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énanapomoci s °ízením dal²ích mobilních objekt·, které do cílové oblasti dopu-tovaly. P°íklady: stavbyvedoucí, regionální manaºer.

� Ko£ovníci - st¥hují se do místa s lep²ími podmínkami pro existenci. Své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ínkamipro 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é, ºestudiem 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ºburozhodn¥ 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 sepodrobn¥ji v¥nuje nap°íklad [5].

P°íklady r·zných kombinací jednotlivých kritérií pro r·zné skupiny mobil-ních objekt· jsou uvedeny v tabulce 1. Tabulka ukazuje jen nejb¥ºn¥j²í kombi-nace. Z °ady reálných p°íklad· vyplývá, ºe mobilní objekt m·ºe mít £asto cha-rakter více zde uvedených skupin. To znamená, ºe je schopen poskytovat vícetyp· £inností. Jako p°íklad m·ºe být uveden obchodní cestující, jehoº úkolemje jednak informovat zákazníka o nových výrobcích �rmy a nabízet nejr·zn¥j²í


Zásilka Tazatel Dopravce Expert Manaºer Ko£ovník

Kdo iniciuje migraci

Cílové prost°edí x x x x

Lokální prost°edí x x x x

Objekt sám x x

Charakter £innosti v cíli cesty

Poskytnutí sluºby x x x x

Získání dat x x x

Usídlení x x x

Alokace dist. sluºby x

Zp·sob °ízení objektu

Vlastní �v·le� x x

Lokálním prost°edím x x x

Cílovým prost°edím x x x x x

Po spln¥ní úkolu objekt

Vrací se x x x x

Pokra£uje dále x x x x x

Usídlí se x x x

Zaniká 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 vyba-ven p°ímo zboºím, které m·ºe zanechat u zákazníka v p°ípad¥ jeho okamºitéhozájmu. Obchodní cestující °ady �rem zárove¬ poskytují moºnost nejr·zn¥j²íchdal²ích sluºeb, jako je za²kolení, provedení drobných servisních úprav na jiº d°ívezakoupeném zboºí. Shrneme-li vý²e uvedené £innosti, m·ºeme °íci, ºe takový ob-chodní cestující jako mobilní objekt plní úlohy dopravce, experta, £asto tazatelenebo 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ýchdo prost°edí softwarových aplikací. Nejprve bude uveden popis nejzákladn¥j²íchprvk· kaºdé aplikace schopné pracovat s mobilními objekty - modely �Mobilní ob-jekt� 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 odkazovatna 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átv ú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é mechanismud¥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 me-tod ur£ených primárn¥ pro identi�kaci mobilního objektu dle jména. Výsledekje zobrazen na obrázku 1. Aby mohl mobilní objekt n¥jak zareagovat na procesmigrace, 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 objektylokálního prost°edí. Druhá metoda (resume()) je zavolána po dokon£ení procesumigrace jiº v cílovém prost°edí. Objekt v ní m·ºe nap°íklad spustit £i obnovitsvoji £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 pro-st°edí, je vyvolána metoda prepare() a objekt se díky ní p°ipravuje na p°esun.Voláním metody move() lokálního prost°edí (metoda bude vyvolána vzdálenýmobjektem) 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°enosudo 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étot°ídy. Tím je proces p°enosu binárního obrazu objektu zakon£en. V dal²ím krokudochází k deserializaci objektu a tím k de�nitivnímu vytvo°ení jeho instance. Cí-


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ándo zásobníku mobilních objekt· (repository) a následn¥ p°echází do aktivníhostavu v rámci cílového prost°edí .

Samostatnou kapitolou v oblasti mobilních objekt· je migrace objektu vlákna- tzv. silná mobilita (Strong Mobility) [8], n¥kdy také serializace vláken (ThreadSerialization) [1].

3.2 Mobilní kontejner

Ne vºdy �cestuje" mezi aplikacemi izolovaný objekt s atributy primitivních da-tový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·. Ta-kový 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 podob-jekty 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 Tomáš Kozel

3.3 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 distribuovanouaplikací, 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 mluvito lokálním (p·vodním) £i vzdáleném (cílovém) mobilním prost°edí, v závislostina 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íhoobjektu. Klonovaný objekt je p°enesen do cílového prost°edí. Tato metodaje 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 objektuv zásobníku (repository) lokálního prost°edí. Pokud reference v repositorybyla jedinou referencí na mobilní objekt v lokálním prost°edí, pak dojde i kezru²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·sledekp°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 jeop¥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ácis 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í MobiEnInt de�nováno jako poto-mek rozhraní java.rmi.Remote, jak p°edepisuje technologie RMI, a umoº¬ujetedy 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 MobiEnImpl. Kv·li vazb¥na RMI je tato t°ída zárove¬ potomkem java.rmi.UnicastRemoteObject, po-p°ípad¥ je prost°ednictvím této t°ídy exportována jako vzdálený objekt. Prop°epravu objekt· m·ºe být pouºita t°ída TransportManager. Prost°ednictvímjejich podt°íd lze pak implementovat bezpe£n¥j²í metody p°enosu objektu, na-p°íklad zabezpe£eným komunika£ním kanálem. Jak jiº bylo uvedeno d°íve, p°ed-poklá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 pod-t°í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í referencena prost°edí vzdálené, se budou v °ad¥ aplikací opakovat. Jelikoº se jedná o vcelku


komplikovaný proces vycházející z pravidel tvorby distribuovaných aplikací s vy-uºitím RMI, bude vhodné poskytnou nástroj (t°ídu) pro rychlý p°ístup k t¥mtoobjekt·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°itt°í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 Singletona Factory method [4].

3.4 Zásilka

Zásilka je první konkrétní implementací rozhraní MobileObjInt, která zde budeuvedena. 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ímuz p°íjmu neznámých a nevyºádaných zásilek je vhodné do modelu za°adit obec-nou t°ídu ParcelPolicy, která prost°ednictvím své metody isAcceptable()

vyhodnotí obsah zásilky, odesílatele apod. (konkrétní implementace budou za-ji²´ovány prost°ednictvím podt°íd) a sd¥lí prost°edí, zda je bezpe£né zásilkup°ijmout a zpracovat. Politika práce se zásilkami by m¥la být nastavitelná a takse p°edpokládá moºnost externí kon�gurace této politiky. P°edpokládá se, ºezásilka m·ºe obsahovat více materiál·. Ty jsou po nastavení adresáta do zásilkyvklá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ílo-vém prost°edí v d·sledku uplatn¥ní omezujících pravidel politiky p°ijímání zási-lek. V p°ípad¥ úsp¥²ného doru£ení se dal²í �ºivot� zásilky °ídí aplika£ní logikoucí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ásileka pak je vhodné na n¥ aplikovat model vyhodnocování d·v¥ryhodnosti zásilkyv cílovém prost°edí prost°ednictvím t°ídy ParcelPolicy. Dotazník m·ºe býtjednoduchou implementací rozhraní MobileObjInt s metodou start(), kteráspustí proces získávání dat v cílovém prost°edí. Sou£ástí metody bude v záv¥rui 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 jednotli-vý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 vespolupráci s ob¥ºníkem by speci�koval, jaká £ást ob¥ºníku má být dopl¬ována £iprezentována v konkrétních destinacích. P°ípadné problémy (nedostupnost neboodmí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ávratuobjektu 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é destinacea následn¥ by se vracel zp¥t. Aplika£ní logika výchozího prost°edí by p°edzpra-covala získaná data a odeslala modi�kovaný ob¥ºník dal²ímu p°íjemci. Centrali-zované °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á mo-delu mobilního kontejneru uvedenému v 3.2. Podobnost model· vychází zejménaz faktu, ºe ob¥ t°ídy (dopravce i kontejner) v sob¥ agregují dal²í objekty imple-mentující rozhraní Serializable (v£etn¥ dal²ích mobilních objekt· odvozenýchod rozhraní MobileObjInt). Hlavní rozdíl mezi t¥mito t°ídami je hlavn¥ v tom, ºezatí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, jakje bude �vykládat� v jednotlivých destinací. Mobilní kontejner tedy p°edstavujezapouzd°enou cestující komunitu vzájemn¥ spolupracujících objekt·. Dopravceje pouze do£asnou a ú£elovou strukturou zaloºenou výhradn¥ k tomu, aby bylypoº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°ístupneumoºnil lépe optimalizovat p°enosy mobilních objekt· (resp. obecných dat) popo£í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 jehoimplementaci s modely uvedenými v p°edchozích £ástech. Speci�cká £innost ex-perta - tedy poskytnutí n¥jaké doposud lokáln¥ nedostupné sluºby - je totiº p°e-váº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ýchpro jeho £innost. Kaºdý mobilní expert by mohl obsahovat seznam v²ech svýchpoºadavk· na cílové prost°edí (instance t°ídy Prerequisite). Sou£ástí kaºdéhop°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, komponentunebo 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 spl-n¥ny.


Jako alternativa vý²e uvedeného modelu se nabízí odd¥lené poskytování in-formací o poºadavcích experta na cílové prost°edí. V tomto p°ípad¥ by p°edvlastním st¥hováním experta do cílového prost°edí muselo dojít ke vzdálenémuposkytnutí seznamu p°edpoklad· a teprve po jejich vyhodnocení by docházelok 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 objektuexperta, nebo by mobilní expert musel být schopen poskytnout tyto poºadavkyprost°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¥ kompli-kovala 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íchobjekt·. Jelikoº mobilní prost°edí je pouze obecným nástrojem pro realizacizákladní mobility, ví pramálo o konkrétní implementaci a dokonce i ve°ejnémrozhraní p°ist¥hovav²ích se mobilních objekt·. N¥které objekty mohou být ak-tivní a nevyºadují tedy p°íli² mnoho komunikace s okolím - jejich funk£nost jedo 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ímiobjekty 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 mohoubýt nahrazováni ve chvíli, kdy jiº jejich °ídící mechanismy nesta£í, £i jsou p°eko-ná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 oprotip°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·mnebo se p°esunout do lépe fungujícího prost°edí. Ko£ovník musí mít schopnostjednak 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 vyhod-nocování poºadavk· ko£ovníka a vlastností prost°edí. K tomu, aby se ko£ovníkv·bec mohl rozhodovat, zda migrovat £i ne, pot°ebuje znát seznam dostupnýchdestinací. K tomuto ú£elu by m¥la být v po£íta£ové síti k dispozici registra£nísluºba (MobiEnRegistry), 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¥ im-plementace mobilních objekt· - ko£ovník·. Ostatní modely jsou p°eváºn¥ za-loº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 pro-st°edí. Existence centrálního registru by ale ur£it¥ také nebyla u rozsáhlej²ícha 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 ob-jektu, který bude schopen po usídlení komunikovat vzdálen¥ s jinými objekty £iaplikacemi.

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íchse jedná z pravidla o mechanismus vyvolaný cílovým prost°edím (pozvání). Do-pravce bude nej£ast¥ji implementován jako mobilní kontejner. Pokud bude navíctento kontejner dopravovat objekty do více destinací, je nutné tento proces °íditbu¤ vzdálen¥, nebo lze dopravce vybavit speci�ckým objektem popisujícím pláncesty. Ko£ovník je speci�ckým p°ípadem, v n¥mº je proces st¥hování ovliv¬ovánpoº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 dovíce uzl· sít¥, s p°ihlédnutím k nárok·m jednotlivých objekt· (modul·) a vlast-nostem prost°edí v uzlech. Tento postup je také moºno doplnit o mechanismyzabezpe£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 ob-lasti softwaru a není nutné ji nahrazovat jinými °e²eními a p°ístupy. Skute£némuroz²í°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í objektyobecn¥ 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, InProceedings of the 2nd international conference on Principles and practice of pro-gramming 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 Appli-cations, 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 applicati-ons, Australian Computer Science Communications , Proceedings of the twenty-�fthAustralasian conference on Computer science - Volume 4, Australian Computer So-ciety, Inc., 2002, ISSN:1445-1336


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 ofComputer 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é. FIMUHK. 2005. 122s.

8. Walsh, T., Nixon, P., Dobson, S.: As strong as possible mobility: AnArchitecture for stateful object migration ont the Internet. [online], URLhttp://cuiwww.unige.ch/~ecoopws/ws00/papers/wal.ps, [cit. 28.4.2004]

Annotation

Mobility belongs among common characteristics of many real objects. On theother hand it is very rarely used in object-oriented software development - so-metimes as a side product of using of distributed objects, other times is usedconsciously, but still only in an experimental manner. This contribution introdu-ces some basic classes of mobile objects, developed as a result of the examinationof the real mobility. The characterisation will stress on the usableness of theseclasses of mobile objects in the software development area.

Využití vzorů v širších souvislostechsoftwarového procesu

Miloš Kudělka1, Vladimír Sklenář2

1Inflex, [email protected]

2Katedra informatiky, PřF, UP, Tomkova 40, 779 00, [email protected]

Využití vzorů v širších souvislostech softwarového procesu

Miloš Kudělka1, Vladimír Sklenář2

1Inflex, Olomouc [email protected]

2Katedra informatiky, PřF, UP, Tomkova 40, 779 00, Olomouc [email protected]

Abstrakt. Mezi vývojáři jsou již dostatečné známé a používané návrhové vzo-ry. Jejich cílem je poskytnout vývojáři praxí ověřená řešení opakujících se pro-blé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 pro-vá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 na-jdu 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á.


Využití vzorů v širších souvislostech softwarového procesu 105

2 Co je vzor?

„Každý vzor je pravidlo, které obsahuje tři prvky a vyjadřuje vztah mezi jistou souvis-lostí, 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 ne-byly 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 rozu-mě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še-ní, která nevedou k úspěchu (ač se tak na první pohled může zdát). I tento prvek po-skytuje 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 srozu-mitelně 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 jednotli-vý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 kon-krétním prostředí nebo případem detailněji rozpracovaným. Lze snad říci, že tato ob-last 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á.


3.2 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í implementa-ci. V podstatě vzory popisují vztahy mezi klíčovými byznys prvky systému. Tato ob-last 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ále-ným službám, pro obsluhu událostí, pro zajištění souběžného zpracování a synchroni-zaci.

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ůže-me 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áklad-ní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 ne-vyhnula 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 pro-blematikou v širším měřítku.


3.7 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ži-vatelské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-learningo-vé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řed-nictví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].


4 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.


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é aplika-ce 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 opodstat-ně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: Ef-

fective Teamwork, Practical Integration. Addison Wesley 2002. ISBN : 0-201-74117-2.

3. Borcher, J.: Interaction Design Patterns: Twelve Theses. 4. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. Pattern-

Oriented 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-201-84453-2

7. Coplien, O., Schmidt, D. Pattern Languages of Program Design 1 Addison-Wesley 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 80-247-0302-5.


12. Harrison, N., Foote, B., Rohnert, H. Pattern Languages of Program Design 4 Ad-dison-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 Ana-lysis 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. Pren-tice 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 object-oriented 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. En-

terprise Solution Patterns using Microsoft.NET Version 1.0. Microsoft Corpo-ration 2003.

25. Van Duyne D. K., Landay J. A., Hong J. I. The Design of Sites: Patterns, Princi-ples, 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 Ad-dison-Wesley 1997. ISBN 0-201-60734-4

28. Yacoub, S., Ammar, H. Pattern-Oriented Analysis and Design: Composing Pat-terns 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

Branislav Lacko

Ústav automatizace a informatiky, Fakulta strojního inženýrství, VUT v Brně,Technická 2, 616 69 [email protected]

Řízení projektů v metodě BORM

Branislav LACKO1

[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)


Ří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

01Definice problému

02Sestavení projektu

1 Analýza st. systému

2 Specif. požadavků

3 Výběr techn. řešení

4 Návrh struktury dat 5 Návrh procesů

6 Fyzický návrh

Fáze

Fáze úvodníhoprojektu

Fáze analýzy

Fáze návrhu

Etapy

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).


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.


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 Konec projektu 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ě.


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.147-152

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

120 Branislav Lacko

Příloha č.1 - Logický rámec

Logický Rámec projektu:

Popis projektu

Objektivně ověřitelné ukazatele

Způsob a prostředky k ověření

Předpoklady

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)

• Strengths (Silné stránky) • Weaknesses (Slabosti) • Opportunities (Příležitosti) • Threats (Hrozby)

Přítomnost Budoucnost Potenciál Silné stránky Příležitosti Omezení Slabé stránky Hrozby Přítomnost Budoucnost Pozitiva Silné stránky Příležitosti Negativa Slabé stránky Hrozby


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í OCL k popisu vztahů mezi přístupovýmiprávy a rolemi

Martin Lasoň, Pavel Gavlovský

Katedra informatiky, FEI, VŠB – Technická Univerzita Ostrava17. listopadu 15, 708 33, Ostrava-Poruba

{martin.lason, pavel.gavlovsky}[email protected]

Využití OCL k popisu vztahů mezi přístupovýmiprávy a rolemi

Martin Lasoň a Pavel Gavlovský

Katedra informatiky, FEI, VŠB – Technická Univerzita Ostrava,17. listopadu 15, 708 33, Ostrava-Poruba

{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 flexibilitumodel RBAC (anglicky Role-based access control). Jednou z důležitýchvlastností RBAC je možnost nastavení různých omezení na jeho kom-ponenty. Tento článek ukazuje, jak tato omezení mohou být popsánapomocí jazyka OCL a jak je lze začlenit do UML diagramů. V UMLdiagramech lze navíc identifikovat entity, které mají vztah k bezpečnost-nímu modelu. Cílem tohoto článku je představit postup, jak lze tytoentity a vztahy mezi nimi automatizovaným způsobem převést na modelpří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šaknejsou přiřazeni ke svým přístupovým právům přímo, ale každý uživatel má de-finovánu množinu rolí, ve kterých může vystupovat. Roli můžeme definovat jakomnožinu akcí a odpovědností spjatých s konkrétní pracovní činností. PoužitímRBAC modelu dochází k omezení složitosti, nákladů a potenciálních chyb připř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řitzákladní model rolí a práv na základě UML diagramů, které vznikají ve fázianalý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íceinformací o budoucích přístupových právech, vytvořili jsme vlastní algoritmusna získávání potřebných informací z aktivitních diagramů [3]. Tento algoritmusvšak doposud nedokázal pracovat s omezeními, která mohou být na role či právakladena. Proto chceme ukázat možnosti, jakými lze omezení kladená na role apřístupová práva vyčíst z běžných UML diagramů.


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, ja-kým může být například čeština, nebo pomocí formálního jazyka. Přirozený ja-zyk má výhodu v tom, že je dobře srozumitelný pro většinu vývojářů, ale jeho ne-vý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ů. Protojsme 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 extra-hová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 au-torizací. Základní myšlenkou RBAC je, že uživatelé nemají přímý přístup k ob-jektům. Místo toho jsou přístupová práva administrativně spjata s rolemi auživatelé jsou nastaveni jako členové příslušných rolí [1]. Tento přístup velmizjednoduš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živateleke konkrétní roli tak dojde k přidělení všech přístupových práv spjatých s toutorolí. Při změně role uživatele v organizaci (např. při povýšení nebo změně zařa-zení) dojde pouze ke změně asociace mezi uživatelem a příslušnými rolemi. Tímse 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,– UA ⊆ U×R, je relace mezi množinou uživatelů a množinou rolí odpovídajícívazbě M : N ,

– PA ⊆ 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é sym-bolem ≥ 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) ∈ UA}.

124 Martin Lasoň, Pavel Gavlovský

RBAC model se skládá ze čtyř částí: jádro modelu RBAC, hierarchický mo-del, statická omezení (SSD) a dynamická omezení (DSD). Jádro modelu RBACje jedinou z těchto částí, která musí být vždy implementována. Ostatní částijsou 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 po-dobnost 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, jakochránit systém proti střetu zájmů jednotlivých uživatelů. Proto se v dalšímtextu 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ůževzniknout při autorizaci získáním přístupových práv asociovaných ke konfliktnímrolím. Jednou z možností, jak se vyhnout střetu zájmů pomocí SSD je uplat-ně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ží keschvalování těchto výdajů. V organizaci by tyto dvě role neměly být přiřazenystejné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živatelev jedné roli může zabránit, aby se tento uživatel stal členem jedné nebovíce rolí, na které jsou uplatněny SSD pravidla. V případě hierarchie rolí jemožné tato pravidla vztáhnout i na všechny zděděné role. Obrázek 1 grafickyzná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 jev kontextu, na který jsou tato omezení uvalena. DSD omezení jsou uvalenana role, které mohou být najednou aktivovány v rámci uživatelova sezení.

Obr. 1. Statická omezení v RBAC modelu


Vzhledem k tomu, že se v dalším textu budeme zabývat automatickým gene-rováním RBAC modelu z UML diagramů, musíme se omezit jen na část RBACmodelu, kterou jsme schopni používat. První komponentou, kterou musíme v au-tomatické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ří budouse systémem pracovat. Proto nelze automaticky vygenerovat z UML diagramůmnožinu uživatelů pro RBAC model. Pokud bude potřeba se nějak odkazovatna množinu uživatelů, bude to pouze pomocí abstraktní třídy zastupující uživa-tele. Druhou komponentou, kterou nelze automaticky vygenerovat je množinasezení, neboť se jedná o systémově závislou komponentu [1]. Z tohoto důvodunemůžeme ani pracovat s dynamickými omezeními DSD a soustředíme se pouzena SSD.

3 Object Constraint Language

Object Constraint Language (OCL) je formální jazyk sloužící k definování ome-zení nad prvky UML modelu [7]. Obvykle (a v našem případě také) je využívánk 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 mezijednotlivý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 jevztaž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 sevě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 odkazujena prvek daný kontextem z deklarace omezení.

Příklad 1. Definujme omezení pro třídu Company, které omezí počet zaměst-nanců 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 ope-

race definované u jednotlivých tříd.

Příklad 2. Definujme, že žádný objekt třídy Person nemůže při volání operacegetAge() 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í defi-novat proměnné i funkce lokálně platné v rámci tohoto omezení.


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) inif isUnemployed then

self.income < 100else

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− > forAll(m|m.value > 5)

definuje, že každý prvek množinyM 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 kom-ponent na základě UML diagramů byla snaha usnadnit práci správci bezpečnostipři prvotním nastavování přístupových práv k jednotlivým rolím. V našem před-chozím článku [3] jsme ukázali algoritmus, který generuje hrubý RBAC modelna základě aktivitních diagramů. Uvádíme zde postupy, jakými lze vytvořit ma-pová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žinarolí 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 ak-tivit. Na základě objektových toků jsou generována práva čtení nebo zápisuk objektům. Při zpracovávání jednotlivých aktivit se na základě řídících toků adalší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 zdaje k dané aktivitě potřeba vygenerovat právo k jejímu spuštění, je vygenerovánkandidát na právo.Diagram 2 popisuje část metamodelu UML, která reprezentuje aktivitní di-

agramy. Takto popsaný diagram je dále zpracováván a jsou v něm vyhledáványRBAC komponenty. K reprezentaci diagramu byly použity třídy ze strukturydefinované pro výměnný formát XMI ze specifikace UML 1.4.2. Využití formátuXMI umožňuje jednoduchou transformaci z XML souborů a také další snadnérozšiřování o dosud nepoužité prvky UML modelu.


Obr. 2. Metamodel UML


5 Rozpoznání statických omezení v OCL

Nevýhodou základního vygenerovaného modelu je, že se jedná pouze o jádroRBAC, které vsak neobsahuje podporu pro SSD a DSD omezení. Protože před-poklá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ůmdobř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ělobýt podmíněno použitím RBAC modelu, ale mělo by se jednat o obecný popischová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živatelia rolemi, je těžké tento vztah definovat bez přítomnosti entit označující uživa-tele. Za tímto účelem jsme definovali třídní diagram reprezentující RBAC model,ke kterému vztahujeme OCL omezení. Tento princip pak popisujeme podrobnějiv čá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í RBACmodelu definovat pomocí OCL. Při navrhování formátu zápisu v OCL jsme vy-cházeli z již užívaných způsobů specifikace RBAC omezení uvedených v [4]. Sta-tická omezení v tomto případě nejsou vázána k jedné konkrétní roli, ale platí provšechny role v daném kontextu a proto je možno je přiřadit celému diagramuaktivit. 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é vztahymezi 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 pravidlavztahující se ke kontextu User a Role. Význam těchto kontextů bude dále blížepopsán v následující kapitole. V této části se omezíme na tvrzení, že kontext Userreprezentuje množinu všech uživatelů a kontext Role reprezentuje množinu všechrolí. Díky těmto kontextům je možno v OCL rozeznat, zda se vztahuje k asociaciuž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živa-tele 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 aktivit-ních diagramech nelze najít dostatek informací, protože potřebné prvky nejsoumodelová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ý


diagram, omezení jsou popsána výčtem všech vzájemně neslučitelných rolí iden-tifikovaných v diagramu. Následující příklad by měl sloužit jako ilustrace popisutěchto omezení. Vzájemná negace u vazby UA (viz sekce 2) specifikuje, že jedenuživatel nesmí mít nastaveny obě role. Toto omezení lze popsat následujícímOCL výrazem:

context User inv:let M: Set = { { vedoucí nákupu,

revizor spatnosti faktur }, . . . } inM->select(m | self.role->intersection(m)->size > 1)->isEmpty

Tento výraz vybere všechny vzájemně neslučitelné množiny, zkontroluje vše-chny role přiřazené každému uživateli a vyhodnotí požadavky. Naše implemen-tace nemůže vyhodnotit tuto podmínku, protože nezná množinu uživatelů, ale jez 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á, žeuživatel může mít nejvýše jedno konfliktní právo získané pomocí rolí přiřazenýchuživateli. Toto omezení je silnější než předchozí případ a chrání před chybamipř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 aSandhu.

context Role inv:let M: Set = { { připravení šeku,

vydání šeku }, . . . } inM->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 speci-fikaci požadavků) vzniká předběžný model struktury aplikace. Popisuje logikua statické vztahy mezi objekty v systému. Tyto třídy však svou strukturou ne-odpovídají struktuře modelu RBAC. Obrázek 3 popisuje strukturu ukázkovéhopří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ákaz-níkem Manažer, jenž zadává konkrétní úkoly Dispečerovi. Dispečer organizujevozidla firmy, přiděluje jim Přepravní plány a u Infrastruktury zjišťuje infor-mace 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ý modelvhodně propojit s obecným modelem struktury RBAC.


Obr. 3. Třídní diagram příkladu

V následujícím diagramu jsou popsány základní třídy modelu RBAC a je-jich vazby. Význam většiny z nich byl definován výše avšak, oproti základnímustandardu RBAC, model detailněji definuje strukturu práv. Ke třídě Permis-sion 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 nadobjekty RBAC modelu. Jedná se o akce čtení, zápisu, vytvoření a zrušení ob-jektu. 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 jejichpropojení. To je relativně jednoduché. Z diagramu užití (případně z drah zodpo-vědnosti) získáváme seznam rolí v systému. Proto definujeme, že námi získané


role dědí z třídy Role RBAC modelu. Práva v RBAC modelu odpovídají akcímv 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 UMLmetamodelu. Zdroje (Resource) v RBAC modelu odpovídají třídám v třídnímdiagramu 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). Tyzískáme analýzou toku objektů v aktivitních diagramech (algoritmus je popsánv [3]). Stručně se dá říci, že když – v rámci aktivitního diagramu – z/do ob-jektu vystupuje/vstupuje tok objektu, pak to znamená, že aktér, v jehož drázezodpovědnosti leží akce z/do níž tok vede, nutně potřebuje právo k manipu-laci s tímto objektem. Nyní již můžeme zpracovávat omezení zapsaná v OCL, asrozumitelně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éhomodelu

Oproti výše zmíněnému přístupu definice omezení, pomocí OCL nad UML mo-delem RBAC, se nabízí ještě možnost přímé definice omezení nad analytickýmmodelem. 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 modelemvytvořeným zvlášť v RBAC modelu.


Omezení současného přiřazení rolí jednomu uživateli (SSD). UML dia-gramy 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í jezřejmá i v následujícím případě. Nelze dovolit, aby zákazník byl zároveň ma-naž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živa-telů, resp. rolí můžeme definovat omezení říkající, že konkrétní právo nelze kom-binovat s jinými právy. Abychom zajistili platnost této podmínky, připojímek akci, reprezentující toto právo, omezení vylučující současné přiřazení konflikt-ní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 provšechna práva p tohoto uživatele podmínku, že jejich průnik s množinou kon-fliktní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 di-agramů. Konkrétně se jedná o specifikaci SSD omezení definující vzájemnounesluč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í, jemožné tyto informace získat z klasických UML diagramů. Tento článek navazujena 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


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 po-třebné informace z použité syntaxe. Námi popsaný proces se nám podařilo doznačné míry automatizovat díky implementaci podmnožiny gramatiky jazykaOCL. Naše další práce se bude soustřeďovat na další upřesnění získaných infor-mací 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. ArtechHouse Publishers, 2003, Boston. ISBN 1-58053-370-1.

2. Lason, M., Gavlovsky, P. An Automatized Extraction RBAC Models From UMLBusiness Process Models. Proceedings of 8th Spring International ConferenceISIM ’05. Ostrava, 2005. ISBN 80-86840-09-3.

3. Lasoň, M., Gavlovský, P. The Ways of an Automatized Extraction of RBAC Mo-dels from UML Business Process Models. Proceedings of the 3th annual workshopWOFEX 2005. Ostrava, 2005. ISBN 80-248-0866-8

4. Ahn, G. J., Shin, M.E. Role-Based Authorization Constraints SpecificationUsing Object Constraint Language. Proceedings of the 10th IEEE InternationalWorkshops 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. ACMTransactions 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 Propo-sed Standard for Role Based Access Control. http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf

7. Object Management Group. Unified Modeling Language Specification Version1.4.2. 2003. http://www.omg.org/cgi-bin/apps/doc?formal/04-07-02.pdf.

Krátký úvod do metodiky (Rational) UnifiedProcess pro vývoj softwarového produktu

Štěpán Macura

Katedra informatiky, FEI, VŠB Technická univerzita Ostrava,17. listopadu 15, 708 33, Ostrava-Poruba

[email protected]

Krátký úvod do metodiky (Rational) Unified Process pro vývoj softwarového produktu

Štěpán Macura

1Katedra informatiky, FEI, VŠB – Technická Univerzita Ostrava, 17. listopadu 15, 708 33, Ostrava-Poruba

[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.


Krátký úvod do metodiky (Rational) Unified Process pro vývoj. . . 135

2.2 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 Štěpán Macura

3 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.


3.4 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.


5.2 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) Je třeba dodat Uživatelé a zainteresované osoby (zadavatel) souhlasí se záměry životního cyklu

Dokument o představě, jenž obsahuje hlavní požadavky na projekt, funkce a podmínky

S uživateli a zainteresovanými osobami byl dohodnut rozsah projektu

Počáteční případ užití (kompletní asi z 10 nebo 20%)

S uživateli a zainteresovanými osobami byly dohodnuty zachycené klíčové požadavky

Slovník projektu

Uživatelé a zainteresované osoby schválili náklady a pracovní rozvrh

Počáteční plán projektu

Manažer projektu nadnesl obchodní případ

Obchodní případ

Manažer projektu odhadl rizika Dokument nebo databáze obsahující odhad rizik

Potvrzení proveditelnosti obsažené v technických studiích a v prototypech

Jeden nebo více prototypů, které bude možno zahodit

Náčrt architektury Počáteční dokument zachycující architekturu

5.3 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.


5.4 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) Je třeba dodat Byl vytvořen odolný robustní spustitelný architektonický základ

Spustitelný architektonický základ. Statický model UML

Spustitelný základ ukazuje, že byla rozpoznána a vyřešena důležitá rizika

Dynamický model UML. Model případu užití

Vize produktu byla stabilizována Dokument o vizi Odhad rizik byl revidován Aktualizovaný odhad rizik Obchodní případ byl revidován a odsouhlasen uživateli a zainteresovanými osobami

Aktualizovaný obchodní případ

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

Aktualizovaný plán projektu

Plán projektu byl porovnán s obchodním případem

Obchodní případ a plán projektu

Bylo dosaženo dohody s uživateli a zainteresovanými osobami o pokračování v projektu

Konečný dokument

5.5 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.


Tabulka 6.3. Podmínky pro dosažení milníku fáze konstrukce Hodnotící kritéria (metriky) Je třeba dodat Softwarový produkt je dostatečně stabilní a na takové úrovni, aby jej bylo možno nasadit na počítače uživatele

Softwarový produkt. Model UML. Testovací sadu.

Uživatelé a zainteresované osoby souhlasí s nasazením softwaru do svého prostředí a je k němu připraven

Uživatelské příručky. Popis verze

Poměr skutečných výdajů vůči plánovaným je přijatelný

Plán projektu

5.7 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) Je třeba dodat Beta-testy jsou dokončeny, byly provedeny nezbytné změny a uživatel souhlasí s faktem, že systém byl úspěšně nasazen

Softwarový produkt

Pracovníci uživatele produkt aktivně využívají

Strategie podpory produktu byla nejprve s uživateli dohodnuta a později implementována

Plán uživatelské podpory. Uživatelské příručky


6 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]


6.2 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]


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á.


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.


Obr 6.4. Právě probíhá proces publikování [4]

Obr. 6.5. Výsledek publikační činnosti


7 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éhoprogramování

Filip Malý

Katedra informatiky a kvantitativních metod, Fakulta informatiky a managementu,Univerzita Hradec Králové,

Rokitanského 62, 500 03 Hradec Králové[email protected]

Podpora výuky objektově orientovaného programování

Filip Malý

Katedra informatiky a kvantitativních metod, Fakulta informatiky a managementu, Univerzita Hradec Králové, Rokitanského 62, 500 03 Hradec Králové

[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.


148 Filip Malý

1.2 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.

Podpora výuky objektově orientovaného programování 149

2 Výuka objektově orientovaného programování

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 Filip Malý

4 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).


Obr.1: Klient Wide J

5.1 Popis jednotlivých částí prostředí

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).


5.2 Interakce mezi jednotlivými částmi systému Wide J

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 object-oriented 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íchrámcích

Petr Matulík, Tomáš Pitner

Masarykova univerzita v Brně, Fakulta informatiky

Podpora aplikační logiky v J2EE aplikačních rámcích

Petr Matulík, Tomáš Pitner

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.


158 Petr Matulík, Tomáš Pitner

1.2 Ří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 Spring2. 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 name="productlist"> <logic class="org.vraptor.example.chain.ProductLogic" method="listAll"/> <view>chain/productList.vm</view> </chain> <chain name="newproduct"> <view>chain/productForm.vm</view>

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.


</chain>  <chain name="saveproduct"> <logic class="org.vraptor.example.chain.ProductLogic" method="save"/> <logic class="org.vraptor.example.chain.ProductLogic" method="listAll"/> <view>chain/productList.vm</view> </chain> <chain name="editproduct"> <logic class="org.vraptor.example.chain.ProductLogic" method="edit"/> <view>chain/productForm.vm</view> </chain> </package>

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();


} 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): <vraptor> <package name="simple"> <chain name="helloWithServletAndVRaptorStuff"> <logic class="org.vraptor.example.simple.TextInverser" method="invertName"/> <view>simple/templateWithServletAndVRaptorStuff.vm</view> </chain> </package> </vraptor>

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:


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"); }


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"> <interceptor class="org.vraptor.example.interceptor.LoggingInterceptor"/> </domain>

Vlastní aplikační logika (představovaná třídou SomeLogic a metodou doSomething musí deklarovat, že je v příslušné doméně s intercepcí:

<package name="interceptor" domains="logging-interceptor-domain"> <chain name="log"> <logic class="org.vraptor.example.interceptor.SomeLogic" method="doSomething"/> <view>interceptor/logging.vm</view> </chain> </package>

3 Komplexní přístup – rámec Spring

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.


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.


3.3 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: <beans> <bean id="dao" class="cz.neco.NejakeDaoImpl" /> <bean id="sluzba" class="cz.neco.NejakaSluzba" > <property name="konf"> <value>nejakaHodnota</value> </property> <property name="dao" ><ref bean="nejakeDao" /></property> </bean> </beans>

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");


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 (Aspect-Oriented 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: <bean id="nejakyInterceptor" class="cz.neco.NejakyInterceptor"/> <bean id="nejakyAdvisor" class="org.springframework...RegexpMethodPointcutAdvisor"> <property name="advice"> <ref bean="nejakyInterceptor"/> </property> <property name="patterns"> <list> <value>.*get.*</value> <value>.*set.*</value> </list> </property> </bean> <bean id="nejakaSluzba" class="cz.neco.NejakaSluzbaImpl" /> <bean id="proxySluzba" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="proxyInterfaces"> <value>cz.neco.NejakaSluzba</value> </property>


<property name="target"> <ref local="nejakaSluzba"/> </property> <property name="interceptorNames"> <list> <value>nejakyAdvisor</value> </list> </property> </bean>

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. <bean id="transakcniProxySluzba" class="org.springframework...TransactionProxyFactoryBean"> <property name="transactionManager"> <ref bean="transactionManager"/> </property> <property name="target"> <ref bean="nejakaSluzba"/> </property> <property name="transactionAttributes"> <props> <prop key="insert*"> PROPAGATION_REQUIRED,-NejakaVyjimka </prop> <prop key="update*">PROPAGATION_REQUIRED</prop> <prop key="*">PROPAGATION_REQUIRED,readOnly</prop> </props> </property> </bean> 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“,


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í

Martin Molhanec

České vysoké učení technické – FEL, K-313Technická 2, 166 27 Praha 6, Dejvice, Česká republika

[email protected]

KONCEPTUÁLNÍHO MODELOVÁNÍ

Martin Molhanec 1

1 České vysoké učení technické – FEL, K-313 Technická 2, 166 27 PRAHA 6, Dejvice, Česká republika

[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:


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 80-248-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 80-85988-83-6.

174 Martin Molhanec

On line: http://martin.feld.cvut.cz/~molhanec/VaV/files/publik/2003/OOkrit-co.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 na vztah mezi refaktoringem,návrhovými vzory a normalizací objektů

Oldřich Nouza

Katedra matematiky, FJFI, ČVUT v Praze,Břehová7, 115 19, Praha [email protected]

Formální pohled na vztah mezi refaktoringem, návrhovými vzory a normalizací objektů

Oldřich Nouza1

1Katedra matematiky, FJFI, ČVUT v Praze, Břehová 7, 115 19, Praha 1

[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


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žnic e

# barva:integer# x:integer# y:integer# poloměr:integer

+ nakresli()

O bdé lník

# barva:integer# x1:integer# y1:integer# x2:integer# y2:integer

+ nakresli()

P lá tno

+ nakresliVše()

0..*

0..*

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. . . 177

P lá tno

+ nakresliVše()

Ge ome tric k ýÚ tv a r

# barva:integer

+ nakresli()

Kružnic e

+ x:integer+ y:integer+ poloměr:integer

+ nakresli()

Obdé lník

# x1:integer# y1:integer# x2:integer# y2:integer

+ nakresli()

0..*

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ř idejPotomka()+ odstraňPotomka()+ vraťPotomka():Prvek+ velikost():integer

S ložk a


S oubor


0..*

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


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.

Obje dná v k a

jménoDodavatelepříjmeníDodavateleadresaDodavatelejménoKlientapříjmeníKlientaadresaKlientadatumObjednávkyzpůsobPlatbynázevPrvníhoProduktucenaPrvníhoProduktunázevDruhéhoProduktucenaDruhéhoProduktunázevTřetíhoProduktucenaT řetíhoProduktu

D odá v k a

jménoDodavatelepříjmeníDodavateleadresaDodavatelejménoKlientapříjmeníKlientaadresaKlientadatumDodávkyzpůsobPlatbynázevPrvníhoProduktucenaDruhéhoProduktunázevDruhéhoProduktucenaPrvníhoProduktunázevTřetíhoProduktucenaT řetíhoProduktu

Obr. 4. – Objektový datový model v žádné normální formě

180 Oldřich Nouza

Obje dná v k a

jménoDodavatelepříjmeníDodavateleadresaDodavatelejménoKlientapříjmeníKlientaadresaKlientadatumObjednávkyzpůsobPlatby

D odá v k a

jménoDodavatelepříjmeníDodavateleadresaDodavatelejménoKlientapříjmeníKlientaadresaKlientadatumObjednávkyzpůsobPlatby

P roduk ty

názevcena

1..*

1..*

0..*

0..*

produkty

produkty

Obr. 5. – Objektový datový model v první normální formě

Kontra k t

jménoDodavatelepříjmeníDodavateleadresaDodavatelejménoKlientapříjmeníKlientaadresaKlienta

Obje dná v k a

datumObjednávky

D odá v k a

datumDodávky

P roduk t

názevcena

11

1

1

0..* 1..*

0..*

1..*

produkty

produkty detail

detail

Obr. 6. – Objektový datový model v druhé normální formě


Kontra k t

způsobPlatby

Osoba

jménopříjmení

Obje dná v k a

datumObjednávky

D odá v k a

datumDodávky

Produk t

názevcena

Adre sa

uliceč .p.PSČ0..* 1

0..*0..* 1

1

1 1

1

1

0..* 1

0..*

1

produkty

produkty

adresa

klient

dodavatel

detail

detail

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.

S ložk a

+ př idejPodsložku()+ odstraňPodsložku()+ vraťPodsložku():Složka+ odstraňSoubor()+ př idejSoubor()+ vraťSoubor():Soubor+ velikost():integer

S oubor

+ velikost():integer0..*

0..*

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().


• 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().

4. Přidání metody přidejPotomka(), odstraňPotomka() a vraťPotomka() do třídy Soubor.

5. 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ů


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 Význam T (vstup, stav před, stav po)

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.

C Množina všech tříd v daném modelu. A Množina všech atributů všech tříd v daném modelu. M Množina všech metod všech tříd v daném modelu. A(c) Množina všech atributů ve třídě c. M(c) Množina všech metod ve třídě c. .name Název třídy, atributu či metody. $ Označení parametru transformace. α(c1, c2) Třída c1 je v asociaci se třídou c2. σ(c) Předek třídy c. ι(c) Množina všech rozhraní, která implementuje třída c. E≈F E a F jsou opakující se skupiny atributů, ve smyslu

definice 1. Ω(E) Množina obsahující všechny neopakující se atributy ze

skupiny atributů E. ϖ(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 Oldřich Nouza

4.2 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 Formální vyjádření Přejmenování třídy T({c.name, $newName}, {c∈C}, {c.name=$newName }) Přejmenování atributu T ({a, $newName}, {a∈A}, {a.name=$newName}) Přejmenování metody T ({m, $newName}, {m∈M}, {m.name=$newName}) Vyčlenění atributů a metod do samostatné třídy

T ({c1, c2, E}, {c1∈C, c2∉C, E⊂A(c1) ∪A(c1)}, {c2∈C, E=A(c2) ∪A(c2), ∃!a∈α(c1, c2)})

Přesunutí atributu do předka

T ({c, a}, {c∈C, a∈A(c)}, {a∈A(σ(c))})

Přesunutí metody do předka

T ({c, m}, {c∈C, m∈M(c)}, {m∈M(σ(c))})

Přesunutí atributu do potomků

T ({c1, a}, {c1∈C, a∈A(c1)}, {a∈A(c2) ∀c2|c1= σ(c2)})

Přesunutí metody do potomků

T ({c1, m}, {c1∈C, m∈M(c1)}, {m∈M(c2) ∀c2|c1= σ(c2)})

Vyčlenění metody do rozhraní

T ({c, m, i}, {c∈C, m∈M(c)}, {m∈M(i), i∈ι(c)})

Transformace třídy z 0NF do 1NF

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


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

Helena Palovská1,2

[email protected]

1Katedra systémové analýzy, VŠE Praha, W. Churchilla 4, 130 00, Praha 32Katedra informatiky, VŠFS o.p.s., Estonská 500, 101 00, Praha 10

Objektové principy a SQL databáze

Helena Palovská1

1Katedra systémové analýzy, VŠE Praha, W. Churchilla 4, 130 00, Praha 3, 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ší.


Objektové principy a SQL databáze 189

2 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-860-5694-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 procesního modelování

Martin Papík

Katedra informačního inženýrství, PEF, ČZU [email protected]

Nástroje procesního modelování

Martin Papík 1

1 Katedra informačního inženýrství, PEF, ČZU Praha [email protected]

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.


194 Martin Papík

• 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ů).

2 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. 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:

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:

Jméno participanta (s velkým písmenem)

Název aktivity

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]. Symboly: začátek role: konec role: přechody: stav:

5. 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ě

Název stavu

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 Action participants result Uzivatel spousti IS PneuServis (Login)

Spuštěni IS PneuServis a

Uzivatel, IS

Uzivatel je prihlasen a muze pracovat s IS


autorizace uzivatele PneuServis,DB PneuServis

PneuServis

Scenario No.2 - realizes function(s): 5

follows scenario No. 1 follows scenario No. 4 continues in scenario No. 3

intiation action participants result Uzivateli jsou pomoci IS PneuServis nabidnuty informace, ktere mu poslouzi k jeho rozhodovani

Ziskani informace

IS PneuServis,Uzivatel

Uzivatel ziskava potrebnou informaci

Scenario No.3 - realizes function(s): 1, 2, 3

follows scenario No. 2 follows scenario No. 1 follows scenario No. 4

intiation action participants result Uzivatel manipuluje se zaznamy v IS PneuServis

Pridej zaznam Smaz zaznam Aktualizuj zaznam

Uzivatel, IS PneuServis,DB PneuServis

Uzivatel modifikoval potrebne zaznamy v IS PneuServis

Scenario No.4 - realizes function(s): 4 continues in scenario No. 2 continues in scenario No. 3

intiation action participants result Uzivatel potrebuje vyhledat zaznam

Hledej Uzivatel, IS PneuServis,DB PneuServis

Vyhledal pozadovany zaznam

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.


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). 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.

Obr.č. 5 – Graf a popis sítě N

200 Martin Papík

5 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

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í :

Obr.č. 2 – Metamodel Petriho sítě


• 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 Martin Papík

7 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


rozhodne, která činnost (větev) se provede. V Petriho síti tomu odpovídá následující konstrukce :

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 :

8 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


9 Vlastní praktický příklad transformace

1.

2. 3.

206 Martin Papík

10 Ověření správnosti transformace

Simulace Petriho sítě z předchozí kapitoly je následující :


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í P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10

m0 1 0 0 0 0 0 0 0 0 0 0 m1 0 1 0 0 1 0 0 0 0 0 0 m2 0 0 1 0 0 1 0 0 0 0 0 m3 0 0 1 0 0 0 1 0 0 1 0 m4 0 0 1 0 0 0 1 0 0 0 1 m5 0 0 1 0 0 0 0 1 1 0 0 m6 0 0 0 1 0 0 0 0 1 0 0

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.

Tabulka - parciální stavy (značení) Petriho sítě

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 80-85867-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ýchproduktů

Josef Pavlíček

Sun Microsystems Czech s.r.o.,Evropská 33e, 160 00 Praha 6 - Dejvice, ČR

[email protected]

Metody testování použitelnosti softwarových produktů

Josef Pavlíček1

1 Sun Microsystems Czech s.r.o., Evropská 33e, 160 00 Praha 6- Dejvice, Č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.


210 Josef Pavlíček

2 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. Praktické (practical)3 2. Užitečné (useful) 3. Použitelné (usable) 4. Uspokojivé (satisfying)“ [1]. 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áš produkt4 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ětve5 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 3 Ú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.

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 beta6 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.


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 Uživatelé s ním mohou přímo pracovat o Často pokrývá více funkčností než prototyp na papíře o Vypadá jako finální produkt o 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ý


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).


5 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.


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-321-17934-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


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 020-

1571-692; Published: Feb 4, 1999; Copyright 1999; 7. JoAnn T.Hackos, Janice C. Redish, User and Task Analysis for Interface Design, ISBN 0-

471-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 s přístupem object-first v úvodnímkursu programování

Jarmila Pavlíčková, Luboš Pavlíček

Katedra informačních technologií, FIS, VŠE Prahanám. W. Churchilla 4, 130 00 Praha 3

{pavjar, pavlicek}@vse.cz

Zkušenosti s přístupem object-first v úvodním kursu programování

Jarmila Pavlíčková1, Luboš Pavlíček2

1Katedra informačních technologií, FIS, VŠE Praha nám. W. Churchilla 4, 130 00 Praha 3

[email protected] 2Katedra 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


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.

Austrálie Nový Zéland dle jazyka dle přístupu dle jazyka dle přístupu

procedurální 11,7 % 53,0 % 8,3 % 34,0 % objektově-orientovaný

82,2 % 36,6 % 91,7 % 66,0 %

funkcionální 6,1 % 10,3 % 0 % 0 %

2 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 Projekty pro úvodní kurs programování

3.1 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


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.


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.


3.3 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í.


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().


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.


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.


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.


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).

úvodní znalost studentů průměrný počet hodin

týdně věnovaný kurzu z toho programováním

začátečníci (158 studentů) 4,75 3,90 umí programovat (95 studentů)

4,33 3,59

zkušení programátoři (20 studentů)

4,64 4,08

celkem 4,58 3,82


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ů


(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 Strongly-

Typed 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.


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/ag-schaefer/Veroeffentlichungen/Quellen/Papers/2002/PTLOOC2002.pdf

Systém pro vývoj distribuovaných aplikacíPlaant

Rudolf Pecinovský, Vladimír Lahoda

Amaio Technologies Inc.{rpecinovsky, vlahoda}@amaio.com

Systém pro vývoj distribuovaných aplikací Plaant

Rudolf Pecinovský1, Vladimír Lahoda1

1Amaio Technologies Inc., 100 00 Praha 10, Třebohostická 14 [email protected] [email protected]

Abstrakt. Při vývoji distribuovaných podnikových aplikací na zakázku se set-káváme s poměrně typickou sadou požadavků, které se neustále opakují. Sys-tém Plaant byl vyvinut jako nástroj pro vývoj a následnou údržbu distribuova-ný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í grafic-ký 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, kte-rý 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 ro-bustních datově orientovaných distribuovaných aplikací. Uživatelé aplikací vyvinu-tý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 respek-tují všeobecně zavedené standardy. To přináší jejich snadnou nasaditelnost na nejrůz-


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 kom-pletní 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ývo-jové 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šech-ny 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 233

3.1 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 pro-středím používaným při návrhu aplikace. Výrazně usnadňuje návrh, vytvoření a nasa-zení (deployment) aplikace. Poskytuje prostředky pro návrh základní struktury data-bá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 kla-sický WYSIWYG, nicméně umožňuje velmi snadno navrhnout i relativně kompliko-vané 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 budou-cích aplikací i zkušenější uživatel.

Plaant Commander Plaant Commander je také samostatný program a slouží k přípravě vytvořené a nasa-zené 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 pro-vozová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ří in-stalač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 komponen-tá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 ne-korektními úpravami, při nichž vývojáři zapomenou na některé důležitě aspekty či vazby.


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ývo-jáře na to, aby ji opravil.

Na druhou stranu tato koncepce umožňuje kdykoliv snadno, rychle a s minimál-ní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žo-vatka. 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ěkoli-ka 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 nezobrazova-ných), ale podle libovolně složitých logických výrazů, v nichž porovnání těchto hod-not vystupují. Při specifikaci rozhodovacích pravidel se přitom uživatel nemusí ome-zovat pouze na hodnoty polí dané agendy, ale může se odkázat na libovolné pole kte-ré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 pochopitel-ně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ů.


Pohledy Souhrn nastavení zobrazovaných a třídících polí, filtru a sestavy je chápán jako po-hled 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 bu-doucnu 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 funk-ce, 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é) mode-lovat jednotlivé knihy, nakladatele, autory, čtenáře atd.; tvoříme-li databázi pro účtár-nu, 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í spo-jeny. 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 ce-lek 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í mechaniz-mu dědičnosti výrazně zjednodušuje analýzu a realizaci některých typických zákaz-nický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 vy-tváření odkazů typu 1:N přitom nebývá nutno vytvářet explicitně příslušnou mezita-bulku, protože ji Plaant dokáže vytvořit a spravovat sám.

Agendy mohou obsahovat nejenom odkazy na jiné agendy, ale mohou také obsa-hovat jiné agendy jako své komponenty. To ulehčuje analýzu i realizaci častých úloh,


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ářů, pro-stř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 podpo-rovat, 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í. Tako-véto závislosti bývá výhodné popsat stavovým diagramem, v němž můžeme k jednot-livý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é ne-standardní č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ži-vateli postupně specifikovat jeho konkrétní požadavky.

Pro tvorbu případného uživatelského rozhraní těchto speciálních funkcí má návr-hář 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 pro-stř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živatel-ský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ůz-nějších bezpečnostních hledisek.

Bezpečnostní koncepce aplikací vyvíjených pomocí systému Plaant není postave-na 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 bez-peč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ži-ku přiřadí celý komplexní balík práv a omezení odpovídající jeho nové pozici.


5.2 Vytvoření kostry aplikace v Plaant Tools

Datová struktura Po analýze nastupuje návrh kostry aplikace. Návrhář aplikace, který nemusí být pro-gramá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ž řek-li, 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é ne-standardní 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 za-dá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í po-le, 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é jazyko-vé 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 ToolsNa 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 aplika-ce, odpovídajících datových strukturách a klientském uživatelském rozhraní. Tyto


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. Ty-to diagramy pak aplikace při svém spouštění načte a podle získaných informací nasta-ví potřebné vnitřní parametry.

Generátor sestav XANDYVětšina aplikací se neomezuje pouze na komunikaci s uživatelem prostřednictvím ob-razovky, 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 doku-mentů ve WYSIWYG režimu. Výstupem tohoto programu je opět sada XML doku-mentů, 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é pro-gramá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 stan-dardní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.


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 kon-trol, 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, na-stavení 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 nasta-vit 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ě nej-zná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 od-borně 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 uve-dení 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ů.


• Systém Plaant umožňuje vývojářům vyvíjet uživatelské rozhraní pouze jed-nou. Systém pak sám realizuje potřebné modifikace pro jednotlivé typy klien-tů.

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í.

Reference

1. Sun, Java 2 Platform, Enterprise Edition (J2EE), http://java.sun.com/j2ee.

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 fea-tures and functions. Besides the possibility of simple definition of the basic forms, which are automatically adapted for different types of clients (thin client, web inter-face, mobile phone, …) it also offers sophisticated functions for control of the docu-ments workflow and for preparing of the complex reports for different targets (printer, comfortable graphical output, web service, …).

Použití transformací v metodě BORM v nástrojiCraft.CASE 2.x

Marek Pícka, Robert Pergl

Katedra informačního inženýrství, Provozně ekonomická fakulta, Česká zemědělskáuniverzita v Praze

{picka, pergl}@pef.czu.cz

Použití transformací v metodě BORM v nástroji Craft.CASE 2.x

Marek Pícka1 , Robert Pergl1

1Katedra informačního inženýrství, Provozně ekonomická fakulta, Česká zemědělská univerzita v Praze, Kamýcká 129, 165 21 Praha 6 {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é


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


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ářů


Obrázek 4 Craft.CASE – business hierarchie

Obrázek 5 Craft.CASE – simulace scénářů


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.


4 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:


1. Každý nový prvek, přidávaný do modelu informačního systému, musí mít smysl.

2. 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).

3. 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ů.

Podání žádostio auto

Referenti používajíauta na služ. cesty

Vedoucí potvrzujížádosti zam. o auto

Funkce

Funkce

Scénář

ReferentParticipant

Vedoucí

Participant

Vedoucí autoprovozuParticipant

ReferentTřída

Požaduje autoAkce

Dostává potvrzenížádosti

Akce

AutoParticipant

Výběr služebníhoauta

Scénář

Autoprovoz přidělujeauta zaměstnancům

Funkce Čeká na rozhodnutívedoucího

Stav

zadejAutoMetoda

Diagram funkcí a scénářů Object-Relationship diagram 2

Object-Relationship diagram 1

Diagram tříd

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ě.


4.4 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. Všechny entity převeď na tabulky. 2. 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.

3. 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.

4. 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.


Entita

Relace

Tabulka

Atribut

1

1

1

1

1

2..*

ERAtribut 1

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ý.


5 Přechody mezi pojmy v metodě BORM

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.

Funk

ce Scén

ář

Part

icip

ant

Rol

e Pa

rtic

ipan

tu

Stav

Přec

hod

Akc

e

Vazb

a

ISA

Aso

ciac

e

Obj

ekt

Tříd

a

Mno

žina

Met

oda

Kom

unik

ace

Dat

ový

Tok

Sklá

dání

Děd

ění

1..*

1..*

1..*

0..*

1..* 0..*

1

11

0..*

0..*

0..*

1

1 1

1

1

1

1 1

0..1

1

0..*1.

.*

0..*

1

1

0..*

0..*

0..*

1

1..*

Obrázek 9 Model transformací pojmů metody BORM


6 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:


(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.

Transformace

AutomTransformace PoloAutomTransformace ObecnaTransformace

Podminka

Pojem

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 1-58603-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.


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 XML webových služeb

Martin Smítka

Katedra informačních technologií, PEF, ČZU [email protected]

Standardy XML webových služeb

Martin Smítka

Katedra informačních technologií, PEF, ČZU Praha [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í.

HTTP

XML

XML Schéma, Namespaces...

SOAP WSDL

Rozšiřující standardy

TCP/IP

Obr. 1 - Základní struktura standardů WS


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.

<?xml version="1.0" encoding="utf-8" ?><definitions

xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="The WSDL target namespace" xmlns:s0="The WSDL target namespace”xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" ><import namespace="Jmenný prostor Schéma" location="URL Schéma" /><types>

</types> <message name="Žádost">

<part name="inPart1" element="s0: " /></message><message name="Odpověď">

<part name="outPart1" element="s0:element ve Schématu" /></message><portType name="NázevTypuPortu">

<operation name="NázevOperace"><input message="s0:Žádost" /><output message="s0:Odpověď” />

</operation></portType><binding name="Interface name" type="s0:NázevTypuPortu”>

<soap:binding transport="http://schemas.xmlsoap.org/soap/http” style="document" />

<operation name="OperationName"><soap:operation soapAction="" style="document" /><input>

<soap:body use="literal" /></input><output>

<soap:body use="literal" /></output>

</operation></binding>

</definitions>

element ve Schématu

Datové typy definované přímo v dokumentu

Datové typy

Importovaná Schémata

Přenášené zprávy

Port služby

Použité jmenné prostory

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 257

3 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 259

4.4 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: <http://www.webservicesarchitect.com/content/articles/myerson01.asp>

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: <http://www.sys-con.com/webservices/article.cfm?id=592>.

4. PELTZ, Ch:. Web Services Orchestration, [on-line], URL: <http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf>

5. Srivastava, B., Koehler, J.: Web Service Composition - Current Solutions and Open Problems, [on-line], URL: <http://www.zurich.ibm.com/pdf/ebizz/icaps-ws.pdf>

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 aFuntion Point

Zdeněk Struska

Katedra informačního inženýrství, PEF, ČZU Praha,165 21 Praha 6 - [email protected]

Metody odhadu složitosti – Feature Point a Funtion Point

Zdeněk Struska1

1Katedra informačního inženýrství, PEF, ČZU Praha, 165 21 Praha 6 - Suchdol [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.

PDF vytvoreno zkušební verzí pdfFactory Pro www.fineprint.cz


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



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

DATOVÉ PRVKY FTR's

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

DATOVÉ PRVKY FTR's

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

HODNOTY ODHAD

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

DATOVÉ PRVKY RET'S

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

HODNOTY ODHAD

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).



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ý Celkem

External Inputs __ x 3 = __ __ x 4 = __ __ x 6 = __

External Outputs __ x 4 = __ __ x 5 = __ __ x 7 = __

External Inquiries __ x 3 = __ __ x 4 = __ __ x 6 = __ Internal Logical Files __ x 7 = __ __ x 10 = __ __ x 15 = __ External Interface Files __ x 5 = __ __ x 7 = __ __ x 10 = __

Celkový počet nevyrovnaných funkčních jednic (UFP)

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 využití konfigurace

Jaká je intenzita využití současné HW platformy, na které budou aplikace vykonávány?

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 koncového uživatele

Byla aplikace navržena, aby zlepšila pracovní výkon koncového uživatele?

8 On-line aktualizace Kolik vnitřních logických souborů je aktualizováno on-line?

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?

11 Jednoduchost instalace Jak složitá je úprava a instalace?

12 Provozní jednoduchost

Jak účinně a/nebo automatizovaně je aplikace startována, zálohována a obnovena?

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, vyvinuta, aby podporovala lehké zavedení změn?

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



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 Zdeněk Struska

4.1 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 320 C 128 COBOL 107 Ada 70 DB Languages 40 Object Oriented 29 Query Languages 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.



Tab. 9.: Postup výpočtu nevyrovnaných feature point

Funkce Váha Celkem EI _ x 4 = EO _ x 5 = EQ _ x 4 = ILF _ x 7 = EIF _ x 7 = Algoritmus _ x 3 =

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 Jednoduché algoritmy a jednoduché výpočty? 2 Většina jednoduchých algoritmů a výpočtů? 3 Algoritmy a výpočty s průměrnou složitostí? 4 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 Jednoduchá data obsahující málo proměnných? 2 Četnost proměnných, ale jednoduché datové vztahy? 3 Multiplikační soubory, pole a datové průniky? 4 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ů.



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í přístup koncepčního a programovéhořešení agrárního WWW portálu Agris

Pavel Šimek, Jiří Vaněk, Jan Jarolímek

Katedra informačních technologií PEF ČZU v Praze,Kamýcká 129, 165 21 Praha 6 Suchdol{simek, vanek, jarolimek}@pef.czu.cz

Moderní p�ístup koncep�ního a programového �ešení agrárního WWW portálu Agris

Pavel Šimek, Ji�í Van�k, Jan Jarolímek

Katedra informa�ních technologií PEF �ZU v Praze Kamýcká 129, 165 21 Praha 6 – Suchdol

[email protected], [email protected], [email protected]

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


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 Pavel Šimek, Jiří Vaněk, Jan Jarolímek

4 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


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


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.

+getText()+getTextList()+forwardText()+transformText()

-id-name-url-path-date-perex-source

Texts

+getLink()+getLinkList()+forwardLink()

-id-name-desc-url

Links

+readWeather()+getIcon()+getWeather()+getShortWeather()

-todayIcon-shortWeather-completeWeather

Weather

+getCompany()+getCompanyList()

-id-name-address-city-zip-contacts-activities

Companies

+openDbConn()+closeDbConn()+getConnParams()

-dbConn

dbClass

+getDbConn()+getSectionName()+getSectionId()+sendServisMail()

-idCurrSection-nameCurrSection-dbCurrConn-adminEmail-errorEmail

agris

+genSQLContent()+insertText()+setHeading()

-heading-content-linkHeader

box

+genMostRead()+genActualities()+genAdvices()+getNew()

boxTexts

+genJustText()+genTip()

boxLinks

+genMenu()+getMenuLink()

boxMenu

Obr. 1. Objektový návrh portálu Agris

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.


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.


2. CORMEDIA – Document and Content Management Solutions – Internet portals [online]. [cit. 20. 10. 2005] <http://www.cormedia.com.sg/DOCPortal.htm>.

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í adaptivního hypermediálního systémuAHA! při výuce programovacího jazyka C++

Zdeněk Velart, Petr Šaloun

Katedra informatiky, FEI, VŠB - Technická univerzita Ostrava,17. listopadu 15, 708 33, Ostrava-Poruba, Česká republika

{zdenek.velart.fei, petr.saloun}@vsb.cz

Využití adaptivního hypermediálního systémuAHA! při výuce programovacího jazyka C++

Zdeněk Velart, Petr Šaloun

Katedra informatiky, FEI, VŠB - Technická univerzita Ostrava,17. listopadu 15, 708 33, Ostrava-Poruba, Česká republika

{zdenek.velart.fei, petr.saloun}@vsb.cz

Abstrakt V příspěvku je popsáno nasazení open source webového adap-tivního hypermediálního systému AHA! v procesu výuky programovacíhojazyka C++. Náš přístup je založen na principu adaptivní prezentace do-mé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 mohoubýt studentům předkládany jako interaktivní PDF formuláře nebo jakostandardní HTML formuláře.

Klíčová slova: adaptace, adaptivní hypermedia, PDF, AHA!, výuka C++, testo-vání

1 Úvod

Naučit se programovací jazyk jen z učebních materiálů a knih, ať jsou napsánysebelépe, je prakticky nemožné. Velké nároky jsou kladeny na samotného stu-denta, který musí ukázat ochotu a vůli se učit. K úspěšnému zvládnutí ovšem jezapotř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 studentaprogramovací jazyk, je dosahován za pomocí ukázek příkladů a adaptivních pre-zentací připraveného studijního materiálu.V příspěvku je prezentován postup, který jsme zvolili k výuce programova-

cího jazyka C++. Kapitola 2 popisuje oblast adaptivních hypermédií, v jakýchoblastech jsou použitelné a jakými technikami a postupy se provádí vlastní adap-tace zobrazovaného učebního obsahu. V další kapitole je pak následně představenadaptivní hypermediální systém AHA!, který implementuje některé z technik proadaptaci a který byl zvolen jako nástroj pro adaptivní prezentaci obsahu studen-tům. Poté následuje představení doménového modelu, který jsme vytvořili prooblast programovacího jazyka C++ a která představuje znalosti, které chceme


282 Zdeněk Velart, Petr Šaloun

studenty naučit. Kapitola 5 popisuje, jaké jsou možností testování studentů ato buď sebetesty, které mohou studenti provádět samostatně nebo hodnocenýmitesty. 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ámevyuž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 jakozpě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, sezabývá výzkumem za účelem zvýšení funkcionality hypermédií tím, že se stanoupersonalizované. 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í aznalostí 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íchoblastech:

– Systémy pro získávání informací (IR, information retrieval) - po-má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á informacemetodou procházení hyperlinky propojených dokumentů.

– On-line informační systémy - hlavním cílem těchto systémů, kterými mo-hou být systémy on-line dokumentace nebo on-line encyklopedie, je uživatelis 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 sezabývají jen nějakou konkrétní aplikaci (např. tabulkový procesor) a uživatelipř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 jepomoci studentům zvládnout učební materiály. Velmi důležitým aspektemtěchto systémů je, jak uživatelé znají dané téma. V průběhu času se charak-teristiky 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 po-stupy sloužící k adaptaci zobrazované informace uživateli. Adaptační technikyse 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. . . 283

Obrázek 1. Adaptivní techniky


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 postupumohou 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ý zob-razovaný 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 nazá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é infor-mace nebo na základě určených podmínek pro fragmenty.

– potlačení fragmentů (dimming fragments) - tato technika představuje me-todu zašeďování nepodstatných fragmentů.

Adaptivní navigace

– přímé vedení (direct guidance) - uživatel je systémem za pomocí hyper-linků 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ýtsetříděny tak aby odrážely uživatelovy požadavky, nastavení a pravidla sys-té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 mohoubý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 od-kazy textově či graficky rozdílně na základě relevantnosti odkazů. Např. za-jí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ředstavujeadaptaci 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) jevyvíjen na Eidhoven University of Technology týmem vedeným prof. Paulem De


Bra jako open source projekt a patří do skupiny výukových hypermediálníchsysté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íchadaptivních systémů. AHAM definuje čtyři základní části systému:

– doménový model popisuje aplikační doménu pomocí fragmentů, stránek akonceptů. Jednotlivé stránky se skládají z žádného či více fragmentů a jsounavzájem propojeny pomocí hyperlinků.

– uživatelský model slouží k uložení nasbíraných dat o jednotlivých uživa-telích a jejich chování v systému. AHA! používá pro stránku nebo konceptvíce atributů, které určuje autor a mohou být využity např. k určení zainte-resovanosti uživatele nebo k vyjádření znalosti o konceptu. Atributy mohoubýt logické, číselné nebo řetězcové.

– adaptační model obsahuje adaptační pravidla, která určují za jakých pod-mínek a kdy má být adaptace provedena.Pro jednotlivé stránky a fragmenty existuje předpoklad, který má formu bo-olean 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 doprezentace.Dále pro každou stránku a koncept může být definována množina tvořícíchpravidel. Každé pravidlo má podmínku, která se testuje a určuje, zda aso-ciovaná 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íchpravidel a vytváří pro uživatele finální stránky, za pomocí existujících adap-tač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 dvadruhy updatů: absolutní - atributu stránky nebo konceptu je přiřazena hod-nota specifikována v akci - nebo relativní - daná hodnota je použita jakoprocentuální část, která má být přidána nebo odebrána atributu stránkynebo 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áz-kami 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íceuč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ět-lující dané učivo;


– žádného či více ukázkových příkladů - tyto příklady úzce souvisejí s probíra-ným učebním textem;

– a žádného čí více testů - jedná se o sebetesty, ve kterých si student můžeotestovat 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 na-vazující části. Pro pokračování musí student získat v systému určité dané mi-nimální bodové hodnocení v systému AHA!. Tohoto může dosáhnout jedním zezpůsobů:

– Student projde všechny nebo alespoň podstatnou část připravených učebníchtextů. 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ždoustránku minimální čas, který student musí na stránce strávit, aby se takpředešlo pokusům o „proklikáníÿ.

– Student neprochází učební text, nebo jen letmo a rozhodne se udělat si jedennebo více kontrolních testů. Za každý úspěšný test student získá body. Pokudbyl 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ítdostatek odhodlání či času absolvovat dostupnou část kurzu, je nutné zohled-nit i tento fakt. Proto a také z důvodu časového omezení pro absolvování


kurzu předpokládáme ještě jedno a to časové hledisko, tzn. po určitém pře-dem 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řed-klá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 znalostdoposud 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íhotextu a přímo se pokusit o zvládnutí testu. Pokud test zvládne úspěšně, je muumož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ů sepředpokládá, že se budou přistupné jen po určitou dobu a každý student budemí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 vyhodnocovatjen 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 jakoPDF formuláře, které student vyplní a odešle ke kontrole. Mezi hlavní před-nosti tohoto řešení patří tyto:• sazba - PDF nabízí možnost sazby textu, obrázků a grafiky se zacho-váním kvality při výstupů na jakémkoliv zařízení nebo při zvětšování čizmenšování na obrazovce.

• „all in oneÿ - veškeré obrázky, grafika, JavaScript i případné další ob-jekty 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í rozpracova-né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 lzeomezit 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 kontroluformulářových dat a pro dynamické akce PDF dokumentů.

– HTML formuláře - student s testy pracuje pomocí webového prohlížeče apo vylnění je odešle na server ke zpracování.


6 Závěr

V tomto článku jsme naznačili princip jak aktuálně probíhá na FEI VŠB-TUOstrava 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 jestudijní materiál předkládán studentovi postupně společně s velkým množstvímukázkových příkladů a testů, na kterých si student může otestovat své znalostinabyté 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, žeby se tento princip výuky mohl rozšířit i na jiné předměty a to nejen z oblastiprogramování.

Reference

1. BIELIKOVÁ Mária. Využitie adaptívnych hypermédií pre e-vzdělávanie, Techno-logie pro e-vzdělávání: sborník semináře: Praha 10. června 2003, Praha: ČVUT2003, s. 15-21. ISBN 80-01-02761-9

2. BIELIKOVÁ Mária, KURUC Jaroslav, ANDREJKO Anton. Learning Program-ming with Adaptive Web-Based Hypermedia System AHA!, In Proc. of ICETA2005, 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 mul-tichoice testing in AHA!, In Proc. of ICETA 2005, Košice, Slovakia, September2005, p. 251-256, ISBN 80-8086-016-6

4. BRUSILOVSKY Peter. Methods and Techniques of Adaptive Hypermedia, Adap-tive 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 Re-ference Model for Adaptive Hypermedia. In Proceedings of the ACM Conferenceon Hypertext and Hypermedia, Darmstadt, Germany, 1999, p. 221-239.

6. De BRA Paul, RUITER Jan-Peter. AHA! Adaptive Hypermedia for All. In Pro-ceedings 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’2002conference, 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 Web-

Based Systems, May 2002. Springer LNCS 2347, pp. 381-384.9. De BRA Paul, AERTS Ad, BERDEN Bart, De LANGE Barend, ROUSSEAUBrendan, SANTIC Tomi, SMITS David, STASH Natalia. AHA! The AdaptiveHypermedia Architecture. In Proceedings of the ACM Hypertext Conference, Not-tingham, UK, August 2003, pp. 81-84.

Anotation

This paper describes the use of the open source web-based adaptive hypermediasystem AHA! in the process of teaching of the C++ programming language. Our


solution is based on adaptive presentation of the domain model, which describesthe problem domain of the C++ programming language. The domain modelis divided into chapters, where every chapter is focused on different part of theproblem domain. Chapters are further divided into knowledge blocks. Knowledgeblock is a compositon of three basic parts: learning material, examples and tests.The testing of students is one of optional parts of AHA! funcionality. Nowa-

days only multichoice tests are supported. Test can be presented to student asinteractive PDF forms or simple HTML forms.

Akademické programy společnosti Microsoft

Dalibor Kačmář

Microsoft CZ [email protected]

Akademické programy společnosti Microsoft

Dr. Ing. Dalibor Kačmář

Microsoft

[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.


Architektura systému Plaant

Vladimír Lahoda, Rudolf Pecinovský

Amaio Technologies Inc.,100 00 Praha 10, Třebohostická 14{lahoda, rpecinovsky}@amaio.com

Architektura systému Plaant

Vladimír Lahoda1, Rudolf Pecinovský1

1Amaio Technologies Inc., 100 00 Praha 10, Třebohostická 14 {lahoda, rpecinovsky }@amaio.com

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.


Arichektura systému Agris


Katedra informačních technologií PEF ČZU v Praze,Kamýcká 129, 165 21 Praha 6 - Suchdol{simek, vanek, jarolimek}@pef.czu.cz

Arichektura systému Agris


Katedra informačních technologií PEF ČZU v Praze Kamýcká 129, 165 21 Praha 6 – Suchdol

[email protected], [email protected], [email protected]

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.

+getText()+getTextList()+forwardText()+transformText()

-id-name-url-path-date-perex-source

Texts

+getLink()+getLinkList()+forwardLink()

-id-name-desc-url

Links

+readWeather()+getIcon()+getWeather()+getShortWeather()

-todayIcon-shortWeather-completeWeather

Weather

+getCompany()+getCompanyList()

-id-name-address-city-zip-contacts-activities

Companies

+openDbConn()+closeDbConn()+getConnParams()

-dbConndbClass

+getDbConn()+getSectionName()+getSectionId()+sendServisMail()

-idCurrSection-nameCurrSection-dbCurrConn-adminEmail-errorEmail

agris

+genSQLContent()+insertText()+setHeading()

-heading-content-linkHeader

box

+genMostRead()+genActualities()+genAdvices()+getNew()

boxTexts

+genJustText()+genTip()

boxLinks

+genMenu()+getMenuLink()

boxMenu

Obr. 1. Objektový návrh portálu Agris


Generické programování v C++, Javě a C#

Miroslav Virius

Katedra softwarového inženýrství v ekonomii, FJFI ČVUT Praha,Trojanova 13, 120 00 Praha [email protected]

Generické programování v C++, Javě a C#

Miroslav Virius

Katedra softwarového inženýrství v ekonomii, FJFI ČVUT Praha, Trojanova 13, 120 00 Praha 2

[email protected]

Abstrakt. Tento příspěvek nabízí porovnání nástrojů pro generické programo-vá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 programo-vacích paradigmat – je zabránit opakovanému psaní stejného nebo podobného zdrojo-vého kódu. Nástroje pro generické programování poskytuje řada programovacích ja-zyků; za zmínku stojí Ada, C++, C#, Eiffel, Haskel, ML nebo Java. V tomto příspěv-ku 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ě orientova-ný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í ne-stojí 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 šab-lony (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 teh-dejší 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.


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 Micro-soft 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 programova-cí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 ho-voř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 polymor-fizmu. 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 Ob-ject 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 na-prosto nesmyslného typu (např. odkaz na tlačítko místo odkazu na objed-ná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ís-tě, 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 vhod-ného předka; tím se ovšem ztrácí univerzálnost. (Poznamenejme, že na po-dobný problém narazíme i ve starších verzích Javy v souvislosti s primitiv-ními typy.)

V jazycích, které nepožadují, aby instance objektových typů byly dynamic-ké, 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 pro-blémům, uložíme-li do kontejneru vedle sebe odkazy na dynamické i nedy-namické 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í pa-rametrizovaný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 pa-rametrem je datový typ. V předchozím oddílu jsme uvažovali o generickém progra-mová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ži-tých datových strukturách, a způsob, jak vyjádřit datové struktury s mini-mální závislostí na algoritmech.

Poskytnout programátorovi možnost implementovat algoritmy co nejobec-ně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 al-goritmů, 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 <typename T> // 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 definu-jeme 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. Po-dí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 dosa-dí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á pra-vidla, která umožní oznámit překladači, že při práci s touto konstrukcí poža-dujeme 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 typo-vých parametrech.

První dvě možnosti jsou v podstatě statické – genericita se uplatňuje pouze na syntak-tické úrovni, tedy v době překladu, nikoli za běhu. Třetí možnost znamená dynamic-kou 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++ syntaktic-ky omezit – to znamená, že z deklarace šablony nejsou zřejmé požadavky

2 Tedy funkcí, které nejsou metodami žádného objektového typu.


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 sku-tečnou příčinou.

Nástroje pro generické programování poskytují možnost přesnější specifika-ce 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ře-kladač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.)

3.2 Java 2, JDK 5

Jazyk Java 5 se opírá o druhý uvedený přístup k implementaci generického progra-mová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 (po-pří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 ty-py 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 po-mocí lze např. deklarovat metodu, jejímž skutečným parametrem bude in-stance 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 po-mocí 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í vy-

nechat. 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 hodno-tový 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 po-užití jednu instanci generického typu, která bude společná pro všechny od-kazové 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 konstruk-torem, 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é třídy nebo třídy obsahující generické metody lze překládat samo-statně, odděleně od použití.

Generické metody mohou být přetěžovány na základě počtu typových para-metrů.

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ůso-bem. 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.

C++ Java 5 C# 2β Oddělený překlad ne ano ne Explicitní specializace ano ne ne Parciální specializace ano ne ne Explicitní omezení typů parametrů ne ano ano Implicitní vytváření instancí ano ano ano Základní typy jako parametry ano ne ano Žolíky ne ano ne Přetěžování generických funkcí 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 paramet-rem 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 pro-gramming is shortly compared.

Rejstřík autorů

Běhálek, Marek, 42Beránek, Ladislav, 2Brada, Přemysl, 54Buchalcevová, Alena, 64

Gavlovský, Pavel, 122

Jakubík, Jaroslav, 74Jarolímek, Jan, 274, 292

Kačmář, Dalibor, 9, 290Keprt, Aleš, 85Kozel, Tomáš, 92Kudělka, Miloš, 104

Lacko, Branislav, 112Lahoda, Vladimír, 231Lahoda, Vladimír , 291Lasoň, Martin, 122

Macura, Štěpán, 134Malý, Filip, 147Matulík, Petr, 157Merunka, Vojtěch, 10Molhanec, Martin, 169

Návrat, Lumír, 42Nouza, Oldřich, 175

Novák, Václav, 2

Palovská, Helena, 188Papík, Martin, 193Pavlíček, Josef, 209Pavlíček, Luboš, 217Pavlíčková, Jarmila, 217Pecinovský, Rudolf, 26, 231, 291Pergl, Robert, 241Pícka, Marek, 241Pitner, Tomáš, 157Polák, Jiří, 1

Radecký, Michal, 42

Sklenář, Vladimír, 104Smítka, Martin, 255Struska, Zdeněk, 261

Šaloun, Petr, 281Šimek, Pavel, 274, 292

Tureček, Tomáš, 42

Vaněk, Jiří, 274, 292Velart, Zdeněk, 281Virius, Miroslav, 293

Academic Alliance Program

MSDN AA – neomezený počet licencí pro katedry a studenty

za dostupnou cenu.

Program MSDN Academic Alliance je navrženspecificky 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ší verzesoftware 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.

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 MSDNAcademic 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íchprojektů 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

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 jejichaktualizace.

Oficiální partneři v ČR a SR s oprávněním vyřídit potřebnou licenční smlouvu jsou:

• 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

Software zahrnutý do předplatného MSDN Academic Alliance obsahuje nejnovější verze produktů

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/

DAQUAS, s.r.o. Anny Letenské 7, 120 00 Praha 2, Czech Republic http://www.daquas.cz, [email protected] tel. +420 222 512 201 Kontakt: [email protected]

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]

Využijte výhod pro školství!

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ýchlaboratořích Microsoft technologie. Licence mohou tímto způsobem získat oddělení, laboratoře a studentioborů Programování, Počítače, Infomační systémy, Infomatika apod. Program významým způsobemzlevň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.

The Hitchhiker’s Guide to CIO Advisory ServicesA practitioner reference guide to all Business IT Strategy, CIO Services and Portfolio Management materials

April 2005

Version 4.1

Designing and adapting effective information and technology architectures to effectively fulfill today's needs and serve as tomorrow's foundation.

Enterprise Architecture

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.

IT Governance

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.

IT Assessment & Due Diligence

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 Sourcing Advisory

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 Transformation

Formalizing the tools and processes needed to bring a shareholder/stakeholder value perspective and fiscal discipline to IT.

IT Value Management

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.

Business and IT Strategy & Planning

DescriptionService Offering

Our PracticeOur CIO Advisory Services practice is focused on the roles and responsibilities associated with information and technology leadership within commercial, private, and public enterprises. Our practiceincludes 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 Capabilities

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

All content referenced in this guide can be accessed on the ‘CIO Advisory Services’ homepage: (https://km.deloitteresources.com/C14/CIO%20Services/default.asp

Example CIO Advisory Services Tools

We Address Executive Issues

Risk Identification and Management

Driving Regulatory Compliance

Measuring and Improving IT performance

Transforming IT Support of the Business/ Agency

Information and Technology Strategy

Complex Business/Agency Operations and Technology Change

Business/Agency Performance Improvement

Cost Reduction

Acquisitions, Mergers, Consolidation, and Divestitures

Establishing or Improving IT Governance

Realize ValueFrom IT

Change in Business/Agency Strategy or Direction

Issue

• IT Assessment & Due Diligence

• Enterprise Architecture

CIO, CEO, CFO, COO

• IT Transformation • IT Assessment & Due

Diligence

CIO, CEO, CFO, COO

• IT Value Management • IT Assessment & Due

Diligence

CIO

• IT Transformation• Enterprise Architecture

CIO

• IT Strategy & Planning • IT Value • IT Transformation • IT Sourcing Advisory • Business IT Governance• Enterprise Architecture

CIO, CEO, CFO, COO

• IT Transformation • IT Sourcing Advisory• Enterprise Architecture

CIO, COO

• IT Strategy & Planning • IT Value • IT Sourcing Advisory • IT Assessment & Due

Diligence • Enterprise Architecture

CIO, COO, CEO

• IT Sourcing Advisory • IT Value • Enterprise Architecture

CIO, CFO

• IT Assessment & Due Diligence

• IT Sourcing Advisory

CEO, CFO, CIO

• IT Value Management • Business IT Governance • IT Strategy & Planning• Enterprise Architecture

CIO, CEO, CFO, COO

• IT Value Management • Business IT Governance • IT Strategy & Planning • Enterprise Architecture

CIO, CEO, CFO, COO

• IT Strategy & Planning • IT Transformation• Enterprise Architecture

CIO, CEO, CFO, COO

Our CapabilitiesStakeholders

CIO Management FrameworkThis 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 MapThe 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.

Landscape MapITPart of the Portfolio Landscape toolbox, this tool allows practitioners to produce a comprehensive view of a client's project / investment portfolio.

PMO in a boxThis set of tools allows practitioners to transform a client’s business strategy into a portfolio of effective programs and projects.

IT M&A Integration ToolkitA set of tools offering a complete approach to conducting M&A integration planning activities.

IT Due Diligence OverviewThe 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 ToolkitToolkit 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.

Portfolio LandscapeDeloitte 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.

IT Transformation ToolkitLessons learned from IT Transformation efforts and examples how to use in relation to the IT Resource Management Toolkit.

IT Resource Management ToolkitExamples of project plans, deliverables and presentations required to successfully complete an IT Resource Management or IT Transformation effort.

RoadmapsVisual 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

ReductionWorkshopsTemplates to walk through Day One activities.Topics include:

IT Inventory ToolkitThe 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 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ří PustinaPetra Křičky 24, 702 00 Ostrava 1

Náklad: 100 kusů

Neprodejné.

ISBN 80-248-0595-2

Date post:	17-Jan-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

OBJEKTY 2005 - Katedra informatiky FEI VŠB-TUO · 2006-01-31 · Objekty 2005 c Václav Snášel,...

Documents