UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Transkript

UNICORN COLLEGE
Katedra informačních technologií
BAKALÁŘSKÁ PRÁCE
Automatické plánování
Autor BP: Yan Zaytsev
Vedoucí BP: Ing. David Hartman Ph. D.
2013 Praha
2
ZADÁNÍ
3
Čestné prohlášení
Prohlašuji, že jsem svou bakalářskou práci na téma Automatické plánování vypracoval
samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a
dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu
literatury a použitých zdrojů.
Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením
jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení
ustanovení § 11 a následujícího autorského zákona č. 121/2000 Sb.
V Praze dne ….........................
…......................................
Yan Zaytsev
4
Poděkování
Děkuji vedoucímu bakalářské práce Ing. Davidu Hartmanovi Ph.D. za účinnou
metodickou, pedagogickou a odbornou pomoc a za další cenné rady při zpracování této
bakalářské práce.
5
Automatické plánování
Automated planning
6
Abstrakt
Předmětem této bakalářské práce je provedení analýzy problematiky automatického
plánování, navržení a implementování knihovny a aplikace pro řešení zadaní
automatického plánování harmonogramu předmětů na univerzitě.
Práce je rozdělena do kapitol dle jednotlivých kroků v procesu analýzy a tvorby
aplikace.
Práce začíná úvodem do problematiky, kterou budeme řešit. V další kapitole
popisujeme úkol, který řešíme v bakalářské práci. Úvod do problematiky obsahuje
informace o problematice automatického plánování a také příklady, kde jej v současné
době uplatnit.
Další kapitola popisuje hlavní přístupy k problematice, způsoby řešení, náročnost,
výhody a nevýhody jednotlivých přístupu. Detailněji pak popisuje vybraný algoritmus.
Další kapitola řeší návrh knihovny a aplikace pro plánování harmonogramu. Popisuje
rozdělení systému na logické části a požadavky pro každou část.
Poslední kapitola řeší vývoj a specifikace knihovny a aplikace. Obsahuje detailní
dokumentaci pro všechny třídy knihovny. Popisuje rovněž příklady použití knihovny.
Klíčová slova: automatické plánovaní, weak-commitment search, timetabling,
automatické generovaní harmonogramu, plánovací algoritmus.
7
Abstract
The subject of this thesis is to analyze the automated planning problem, design and
implement a library and automated scheduling solution for university.
The thesis is divided into chapters according to the steps in the process of application
development.
The work begins with an introduction to the problem that we are dealing with. The
next chapter describes the task that we are dealing with in the thesis. Introduction
contains information about automated planning problem and use it nowadays.
Next chapter describes the main approaches to the problems, possible solutions, the
complexity, the advantages and disadvantages of each approach and separately describes
the selected algorithm.
The third chapter contains information about the algorithmic requirements for
application. Describes entities, which are represented in our task.
Next chapter is about the automated planning library and automated scheduling
system. It divides system into logical parts and it contains information about requirements
for each part.
The final chapter is about the development and specification of library and automated
scheduling application. It contains detailed documentation for all classes and objects of
library. It also describes all conditions of algorithm working and it contains library using
examples.
Keywords: automated planning, weak-commitment search, automated timetabling,
automated scheduling , planning algorithm.
8
Obsah
1.Úvod.................................................................................................................................10
1.1 Popis jednotlivých kapitol..............................................................................................10
1.2 Konvence použité v této práci.......................................................................................11
2.Teoretický popis problému automatického plánování.....................................................12
2.1 Statické plánování..........................................................................................................14
2.2 Dynamické plánování.....................................................................................................14
2.3 Omezující podmínky......................................................................................................14
3.Popis specifického plánovacího problému pro Unicorn College......................................15
3.1 O Unicorn College..........................................................................................................15
3.2 Problematika automatického plánovaní harmonogramu.............................................15
4.Popis existujících způsobu řešení problematiky...............................................................17
4.1 Barvení grafu.................................................................................................................17
4.2 Genetické algoritmy.......................................................................................................18
4.3 Logické programování....................................................................................................19
4.4 Constraint satisfaction problem....................................................................................19
4.4.1 Backtracking................................................................................................................20
4.4.2 Asynchronous backtracking.........................................................................................20
4.4.3 Weak-commitment search...........................................................................................22
4.4.4 Asynchronous weak-commitment search....................................................................24
4.4.5 Příklad běhu asynchronous weak-commitment search...............................................25
4.4.6 Srovnání rychlosti algoritmů........................................................................................27
5.Návrh aplikace řešící problém plánování harmonogramu pro Unicorn College..............28
5.1 Detailní popis použitého algoritmu...............................................................................28
5.1.1 Algoritmus...................................................................................................................30
5.1.2 Optimalizace algoritmu................................................................................................31
5.2 Návrh knihovny pro řešení problematiky automatického plánovaní............................33
5.2.1 Use-case diagram.........................................................................................................33
5.2.2 Domain model.............................................................................................................35
5.2.3 Popis jednotlivých částí systému..................................................................................37
5.3 Návrh aplikace plánovaní..............................................................................................42
5.3.2 Datová vrstva...............................................................................................................43
5.3.3 GUI...............................................................................................................................46
6.Implementace navržené aplikace.....................................................................................47
6.1 Implementace knihovny................................................................................................47
6.1.1 Implementace prostředí Solver....................................................................................48
6.1.2 Implementace prostředí Agent....................................................................................60
6.2 Implementace aplikace plánování.................................................................................67
6.2.1 Datová a business vrstva..............................................................................................67
6.2.2 GUI – Práce s daty........................................................................................................68
6.2.3 GUI – Plánování harmonogramu..................................................................................77
6.2.4 Min-conflict search algoritmy a výsledky plánování....................................................79
7.Závěr.................................................................................................................................81
8.Conclusion........................................................................................................................82
9
9.Seznam použitých zdrojů..................................................................................................83
10.Seznam obrázků.............................................................................................................85
11.Seznam tabulek..............................................................................................................86
12.Seznam příloh.................................................................................................................88
13.Příloha A: obsah přiloženého CD....................................................................................89
10
1. Úvod
Cílem této práce je analyzovat problematiku automatického plánování. Zabývat se
budeme rovněž detailní analýzou konkretního zadání z oblasti automatického plánování
harmonogramu předmětů na vysoké škole s různými omezeními dat.
Automatické plánování řeší problematiku vytvoření správné sekvence činností a akcí,
aby se systém mohl dostat ke stanovenému cíli pomocí změn parametrů dat se
stanovenými omezeními. Problematika automatického plánování se týká oblasti umělé
inteligence a je v současnosti velmi aktuální. Úloha automatického plánování je komplexní
a musí být vyvinuta a optimalizována v multidimenzionálním prostoru. 1
Tato práce se zabývá analýzou problematiky automatického plánovaní harmonogramu
předmětů, implementace knihovny a aplikace, která řeší tuto problematiku. Tento typ
řešení je o něco jednoduší než úkol automatického plánovaní. Na rozdíl od plánovaní
harmonogramu, kde máme fixní seznam událostí2, pro které musíme definovat parametry,
jako jsou čas a místnost, řešení problematiky universálního automatického plánovaní se
zabývá i tím, jaké vůbec události potřebujeme k dosažení cíle.
1.1 Popis jednotlivých kapitol
Text je rozdělen do kapitol dle jednotlivých kroků v procesu analýzy problematiky
automatického plánování a vývoje knihovny.
Kapitola „Teoretický popis problému automatického plánování“ obsahuje informace o
problematice automatického plánování včetně toho, kde ho lze využít v současně době.
Kapitola „Popis specifického plánovacího problému pro Unicorn College“ obsahuje
informace o funkčních požadavcích pro aplikaci.
Kapitola „Popis existujících způsobu řešení problematiky“ popisuje hlavní přístupy k
problematice, způsoby řešení, náročnost, výhody a nevýhody jednotlivých přístupu.
1
2
Ghallab, Malik; Nau, Dana S.; Traverso, Paolo (2004), Automated Planning: Theory and Practice, Morgan
Kaufmann, ISBN 1-55860-856-7
Pod pojmem událost v této práci rozumíme především přednášku či seminář. Pojem lze také rozšířit na
test, zkoušku atd.
11
Kapitola „Návrh aplikace řešící problém plánování harmonogramu pro Unicorn
College“ řeší návrh knihovny a aplikace pro plánování harmonogramu. Popisuje rozdělení
systémů na logické častí a požadavky pro každou část.
Kapitola „Implementace navržené aplikace“ řeší vývoj a specifikaci knihovny a
aplikace. Obsahuje detailní dokumentaci pro všechny třídy knihovny. Popisuje kromě toho
všechny podmínky práce a příklady použití knihovny. Součástí této kapitoly je analýza
výsledků práce plánovací aplikace.
1.2 Konvence použité v této práci
Obzvláště v příkladech se budou vyskytovat ukázky částí kódů nebo návrhové
diagramy. Pro odlišení byly použity různé typografické konvence:
1. Neproporcionální písmo − všechny ukázky zdrojových kódů.
2. Tučné písmo – zvýrazňuje důležité informace nebo klíčové pojmy.
3. Kurzíva – označuje nějakou dodatečnou informaci.
12
2. Teoretický popis problému automatického plánování
V popisu budou použity následující termíny:
•
Událost – v automatickém plánovaní základní jednotka vstupních dat. Lze ji chápat tak, že událost je
něco, co se může stát v čase a obsahuje nějaké další parametry.
•
Omezující podmínky – omezení pravidel spojení dat ve výsledku získaném v průběhu řešení
plánovacího úkolu.
•
Úkol – úloha, kterou musíme vyřešit; konkrétně popsané zadání.
•
Kontext úkolu – okolí, ve kterém se nachází úkol. Je to míra znalostí o spojení, struktuře a formě
dat, se kterými pracujeme. Když je kontext neznámý (úkol je nezávislý na kontextu) – pracujeme s
abstraktními jednotkami a neznáme specifická pravidla jejich spojení. Když je kontext známý (úkol
je závislý na kontextu) – máme informaci o všech typech a formách dat. Víme, jaké typy omezujících
podmínek můžou existovat ve vstupních datech.
Úkolem automatického plánování je vytvoření sekvence událostí a akcí, které
transformují vstupní udaje systému do cílového stavu.3 Automatické plánovaní lze,
například, použít v následujících úlohách: plánování harmonogramu událostí s omezujícími
podmínkami4, minimalizování nákladů na operaci ve vesmíru5, zlepšení efektivity
samostatných a dálkově ovládaných robotů6.
Řešení problematiky automatického plánování je možné rozdělit do dvou skupin:
nezávislé na kontextu úkolu a závislé na kontextu. Řešení prvního typu jsou pomalejší ale
univerzální. Řešení druhého typu jsou praktičtější a specializují se na zadaní s předem
definovanou datovou strukturou.
Samotné automatické plánování lze rozdělit podle přístupu k řešení. Nejpopulárnější a
nejpoužívanější jsou satisfiability (SAT) problem, constraint satisfaction problem (CSP),
large logical formula, integer programming (IP) problem 7 a grafové algoritmy.
3
4
5
6
7
Menkes, H..: INTEGER PROGRAMMING APPROACHES FOR AUTOMATED PLANNING [online]. Arizona ,
2008. Dissertation. ARIZONA STATE UNIVERSITY, page 1
Tato uloha bude popsana v další části práce
S. Chien and G. Rabideau, 2000, ASPEN - Automated Planning and Scheduling for Space Mission
Operations
Ezequiel Q. Ángel G.-Olaya D. Borrajo F., 2011, “Control of Autonomous Mobile Robots with Automated
Planning“, „JOURNAL OF PHYSICAL AGENTS“, vol. 5, no. 1, january
Menkes, H..: INTEGER PROGRAMMING APPROACHES FOR AUTOMATED PLANNING [online]. Arizona ,
2008. Dissertation. ARIZONA STATE UNIVERSITY, page 18
13
SAT – odpovídá na otázku, zda existuje řešení logického vzorce.8 Tento přístup je
obtížné aplikovat na problematiku automatického plánování harmonogramu, protože
transformace vstupních dat a jejich omezení do logických vzorců je velice náročnou
operací.
CSP – velmi univerzální přístup pro řešení problémů. Definice přístupu je následující: V
zadání máme seznam parametrů, pro něž musíme definovat hodnoty, které splňují
všechna omezení.9 Tato bakalářská práce popisuje CSP přístup a jeho použití pro řešení
problematiky automatického plánování harmonogramu. Pro CSP řešení existují velice
efektivní algoritmy. Tato práce vysvětluje a porovnává CSP algoritmy.
Large logical formula má stejné vlastností jako SAT, ale používá jiné metody pro řešení.
IP – zadání a řešení jsou pouze v celých číslech10. Hlavní podmínkou použítí tohoto
přístupu je, že problém musí být transformovatelný do IP, což někdy není možné, protože
podmínky často nelze převést do integer formy. Základní algoritmy pro řešení tohoto typu
jsou algoritmy pro řešení soustav lineárních rovnic. Přidávat nové omezující podmínky a
nové typy dat je složité.
Grafové algoritmy (barvení grafu) – široce používaný přístup pro řešení dané
problematiky. Podmínka použití je stejná jako v IP – problém musí být transformovatelný
do formy grafu. Detailnější popis přístupu naleznete v kapitole Popis existujících způsobu
řešení problematiky
8
Rodriguez, C.; Villagra, M.; Baran, B. (2007). "Asynchronous team algorithms for Boolean Satisfiability".
2007 2nd Bio-Inspired Models of Network, Information and Computing Systems.
doi:10.1109/BIMNICS.2007.4610083
9 Müller T.: Constraint-based Timetabling. Prague, 2005. Ph.D. Thesis. Charles University in Prague Faculty
of Mathematics and Physics
10 Menkes, H..: INTEGER PROGRAMMING APPROACHES FOR AUTOMATED PLANNING [online]. Arizona ,
2008. Dissertation. ARIZONA STATE UNIVERSITY
14
2.1 Statické plánování
Názvem „statické plánování“ míním systém, v němž jsou všechny údaje jednoznačně
definované a v budoucnu se nezmění. V našem případě (plánovaní harmonogramu) to
znamená, že algoritmus bude pracovat jen jednou. Když dojde ke změně základních dat, je
nutné adaptovat veškerá data pro nové podmínky a znovu spustit algoritmus. Každé
spuštění ovšem bude lokální a nebude používat data z předchozího vypočtu.
2.2 Dynamické plánování
V dynamickém systému algoritmus naplánuje výsledek jednou, a pokud dojde ke
změně základního či stávajícího stavu systému, algoritmus vše propočítá a vytvoří nové
řešení. Pro výpočet používá data z předchozích iterací. V takovém systému lze ručně
nastavit určité parametry, změnit omezující podmínky atd. Algoritmus ověří všechny
změny a provede adaptaci řešení pro tato data.
2.3 Omezující podmínky
Tato práce se bude zabývat řešením problematiky automatického plánování s různými
způsoby omezení dat. Automatické plánování má vždy určitá omezení a pravidla pro
výsledná data. V některých případech jsou omezení jednoduchá (omezuje se počet, pořadí
akcí nebo událostí), jiná jsou náročná, jako jsou například vztahy mezi událostmi,
nejednoznačná omezení a priority.
15
3. Popis specifického plánovacího problému pro Unicorn College
3.1 O Unicorn College
Unicorn College je vysoká škola v Praze, která nabízí vzdělání v oblasti informačních a
komunikačních technologií, ekonomie a managementu.
Ve zprávě akreditační komise z roku 2010 se můžeme dočíst následující: „UC je velmi
dobře materiálně vybavenou soukromou vysokou školou, která deklaruje těžiště svého
vzdělávání do oblasti profesního bakaláře. Značný důraz klade na propojení vzdělávací a
tvůrčí činnosti s praxí (výraznou podporu má v tomto ohledu ve firmě Unicorn). UC dbá na
transparentnost procesů, včetně procesu přijímacího řízení (tj. na jasné dodržování nároku
na kvalitu). Na velmi dobré úrovni je systém elektronických opor studia, což umocňuje
transparentnost celého vzdělávacího procesu. Tyto skutečnosti považuje sama vysoká
škola za své silné stránky spolu se zdůrazně-ním, že absolventi školy zůstávají v oboru.“ 11
3.2 Problematika automatického plánovaní harmonogramu
Jedním z cílů této bakalářské práce je implementace aplikace s ohledem na
charakteristiky rozvrhu Unicorn College. Cílová aplikace by navíc mela umožňovat
dynamické přeplánování.
V této kapitole popíšeme funkční požadavky pro budoucí aplikaci, podle těchto
požadavků budeme porovnávat jednotlivé způsoby řešení problematiky automatického
plánovaní a zvolíme jeden z přístupů pro implementaci.
Problém automatického plánování harmonogramu se týká následujících dat: událostí
(přednášek a seminářů), studentů, vyučujících, místností.
•
Každý student je účastníkem definovaného seznamu událostí (protože si je zapsal).
•
Každý vyučující může přednášet definovaný seznam předmětů.
•
Vyučující má preferenci na pracovní dobu (lze časové omezit úřední hodiny práce)
11 GERŠLOVÁ a kol. Zpráva Akreditační komise o hodnocení Unicorn College s.r.o. Praha [online] vyd.
listopad 2010 dostupné z URL:
http://www.akreditacnikomise.cz/attachments/article/252/CZ_hodnoceni_unicorn_college_2010.pdf
16
•
Škola má definovaný seznam místností, které je možné používat pro výuku. Je dána
rovněž kapacita místností a jejich vybavenost počítači.
•
Algoritmus musí definovat čas začátku pro každou událost. Událost obsahuje další
parametry: dobu trvání, seznam vyučujících, kteří mohou učit tento předmět,
seznam učeben, kde může probíhat výuka.
•
Algoritmus musí definovat seznam účastníků dané události (studenti jsou fixně
definováni, musíme definovat i vyučující).
•
Každá událost obsahuje seznam událostí na které je závislá (seminář musí byt
později než odpovídající přednáška).
•
Lze časově omezit celou výuku školy.
•
Během výuky lze přidat nové časové omezení pro výuku nebo vyučujícího a
algoritmus musí předělat výsledek podle nových podmínek.
17
4. Popis existujících způsobu řešení problematiky
Tato bakalářská práce se zabývá implementací řešení problematiky automatického
plánovaní pro harmonogram předmětů na univerzitě. Následující algoritmy a přístupy
budou řešit právě tuto problematiku. Existuje rovněž možnost rozšíření pro řešení
univerzálních úkolů automatického plánovaní.
De Werra12, A. Schaerf13, Edmund Kieran Burke a Sanja Petrovic14 ve svých pracech
popisují různé přístupy pro řešení problematiky automatického plánovaní harmonogramu.
4.1 Barvení grafu
Prvním z jmenovaných přístupů je transformace úkolu na úkol barvení grafu. Tato
metoda je poměrně efektivní, ale má své nevýhody. Jak bylo popsáno v úvodu do
problematiky, hlavní podmínkou použití barvení grafu je, že úkol musí být
transformovatelný na graf. Datová struktura zadání by měla být předem definována,
protože v případě použití této metody je obtížné adaptovat existující implementaci na
novou strukturu dat a nové typy omezujících podmínek. Některá omezení dat je těžké
adaptovat pro graf – například preferenci učitelů v rámci pracovní doby nebo časovou
návaznost lekcí a seminářů. Barvení grafu je často používaným přístupem pro řešení úkolů,
které mají jednoduché omezení (návaznost událostí a místností, událostí a studentů) nebo
malý počet událostí. Algoritmus není vhodný pro dynamické přizpůsobení systému ke
změně parametrů.
Struktura transformovaných dat bude sledující: každý vrchol grafu reprezentuje
jednotlivou událost harmonogramu. Barva vrcholu reprezentuje čas (začátku) události.
Hrany pak mohou být několika typů. První typ hran – studentská hrana reprezentující
studenta, který si zapsal předměty (události). Spojení dvou vrcholů touto hranou
znamená, že existuje student, který si zapsal související předměty, a události nemohou mít
konflikt v čase. Když obarvíme graf v běžném stavu, ve výsledku budeme mít seznamy
12 de Werra, D., 1985. „An introduction to timetabling“, European Journal of Operational Research,
Elsevier, vol. 19(2), pages 151-162, February.
13 Schaerf A., 1999, „A Survey of Automated Timetabling“, ARTIFICIAL INTELLIGENCE REVIEW, vol. 13(2),
pages 87-127
14 Burke, Edmund Kieran & Petrovic, Sanja, 2002. "Recent research directions in automated timetabling,"
European Journal of Operational Research, Elsevier, vol. 140(2), pages 266-280, July.
18
událostí, které nemohou probíhat ve stejném čase. Jestliže událost může probíhat jen v
jediné místnosti, musíme vytvořit jednotlivé hrany mezi vrcholy pro případ, že související
události musejí probíhat ve stejné místností. Stejný princip je možné použít i pro vyučující.
Když je definováno, že událost může probíhat v několika učebnách nebo tento
předmět může učit několik vyučujících, musíme přidat speciální typ hran – dynamické
hrany. Dynamická hrana může být definována jednostranně pro každý spojitý vrchol. Pod
pojmem „jednostranně“ rozumíme, že stejná hrana může být pro první vrchol dynamická a
pro související vrchol obyčejná, statická. Každý vrchol, který má dynamické hrany, během
barvení může zvolit, kterou z těchto hran použije pro ověření barvy. Vrchol musí zvolit
vždy jednu z dynamických hran stejného typu. Typ dynamické hrany je druhem
souvisejícího parametru (viz příklad níž). Když je určitá dynamická hrana vybrána jen
jedním vrcholem, pak hrana ztratí svůj význam, svou „moc“.
Příklad dynamické hrany: události A a B můžou probíhat v učebnách U1 a U2.
Vytvoříme následující graf: existují vrcholy VA a VB, které reprezentují události; existují
dvě dynamické hrany DU1 a DU2, které reprezentují učebny. V kvalitním výsledku barvení
grafu by musely dostat následující vztahy: U1 – barva 0 a použitá hrana DU1 (která ztratí
svou moc), U2 – barva 0 a použitá hrana DU2 (která ztratí svou moc).
Tento přístup nebudeme používat z důvodu obtížné adaptace časových podmínek,
možností budoucího rozšíření (nové typy podmínek) a složitého dynamického
přeplánovávání změněných dat.
4.2 Genetické algoritmy
A. Schaerf, E. Burke, S. Petrovic popisují přístup pomocí genetických algoritmů. Tato
metoda je efektivní pro řešení nastoleného problému, dává dobré výsledky s malým
počtem jednoduchých podmínek. Genetické algoritmy jsou algoritmy pro minimalizaci či
maximalizaci (fitness15) funkce. Z toho důvodu výsledkem genetického algoritmu bude
harmonogram, který má vysoké hodnocení pouze z pohledu fitness funkce. Vysoké
hodnocení přitom není známkou toho, že harmonogram neobsahuje žádné konflikty mezi
15 Fitness funkce – analytická funkce, která popisuje běžný stav dat a vrátí „hodnoceni“ stavu – číslo
které reprezentuje data
19
událostmi. Mohou například existovat události, které probíhají ve stejném čase a zapsal si
je nějaký stejný student. Fitness funkce musí jen zmenšit/zvetšit hodnocení stavu vůči
tomuto konfliktu, nemůže ale odstranit celý stav z iterace algoritmu. Genetické algoritmy
jsou dobře použitelné pro zadaní, která obsahují prioritní omezení dobře
transformovatelná do fitness funkce. Tato metoda se pohodlně používá pro úkoly s
efektivní alokací zdroje. Použití genetického algoritmu vyžaduje jemné doladění, aby se
nevyskytovaly nežádoucí výsledky, což je někdy velmi obtížné. Základní algoritmus také
není přípraven na dynamické přeplánování a z tohoto důvodu ho nebudeme používat pro
implementaci aplikace.
4.3 Logické programování
Jedním z přístupů pro řešení daného úkolu, o kterém se zmiňuje práce Schaerfa A., je
použití logického programování. Tento přístup je efektivní s malým množstvím dat a
poskytuje dobré výsledky. Pokud ovšem počet dat a podmínek stoupá, rychlost algoritmů
prudce klesá. Důvodem je skutečnost, že algoritmy zpracování programu v logickém
programování jsou univerzální. Chcete-li zvýšit rychlost, musíte vytvořit specializovaný
algoritmus, který je závislý na kontextu řešení problému v daně doméně.
4.4 Constraint satisfaction problem
Všichni zmínění autoři popisují způsob řešení problematiky automatického plánovaní
pomocí CSP. Jde o univerzální typ řešení, při němž je nutné definovat pro určitou sadu
parametrů hodnoty, které splňují všechna omezení a podmínky. CSP umožňuje
přidávat/vytvářet omezení libovolného typu (pro zadávaná data), s prioritními omezeními
ale má nízkou efektivitu práce. CSP algoritmy buď nabídnou řešení, které plně splní úkol,
nebo zjistí, že dokonalé řešení neexistuje, a nabídne aspoň částečné. Tato bakalářská práce
bude používat tento přístup pro implementaci aplikace.
CSP řešení se skládá ze tří částí: V, D, C.16
V – skupina všech parametrů systému. V rámci našeho úkolu máme tři druhy
parametrů: událost – čas (musíme definovat čas začátku), událost – místnost (musíme
16 Müller T.: Constraint-based Timetabling. Prague, 2005. Ph.D. Thesis. Charles University in Prague
Faculty of Mathematics and Physics, page 4
20
definovat místnost, kde bude probíhat samotná událost) a událost – vyučující (musíme
definovat vyučujícího, který bude účastníkem dané události). V rámci rozšíření úkolu lze
též přidat parametry jako „student – skupina předmětu“(musíme definovat skupinu, ve
které student bude studovat jednotlivý předmět). Pro naplnění skupiny V musíme pro
každou událost vytvořit 3 parametry(podle druhu parametru, které byli popsané) a přidat
jej do V.
D – skupina všech domén parametru v (doména D(v) je skupina všech hodnot, které
mohou byt definovány pro parametr v). V případě harmonogramu například D(událostčas) obsahuje všechny časové intervaly, kdy může probíhat výuka.
P – množství všech omezení a podmínek v systému. Podmínky mohou být různého
typu. V harmonogramu jde o podmínky, které omezuje čas nebo podmínka, že ve stejnou
dobu nemohou probíhat události ve stejné místností.
Řešením CSP problému je definování všech parametrů ze skupiny V, některých hodnot
ze skupiny Dv, které budou splňovat všechna omezení P.
Existují různé algoritmy pro řešení CSP problému. Dál popíšeme základní algoritmy.
4.4.1 Backtracking
Není okamžitě zřejmé, že backtracking algoritmus je součástí CSP přístupu. Je to
nejjednodušší algoritmus. Tento algoritmus postupně prochází všechny parametry ze
skupiny V, snaží se postupně použít všechny hodnoty ze skupiny D a ověřuje stav podle
omezujících podmínek P. Vždy poskytuje řešení úkolu nebo odpověď, že řešení neexistuje.
Tento algoritmus má vysokou výpočetní náročnost, která závisí na množství parametrů,
množství jejich možných hodnot a množství omezujících podmínek.
4.4.2 Asynchronous backtracking
Algoritmus17 přináší novou strukturu dat: všechny parametry ze skupiny V jsou
přiřazeny k novému prvku „agent“. Agent obsahuje dvě vlastnosti – parametr v a jeho
hodnotu ze skupiny D(v).
17 Makoto Yokoo, 1995, „Asynchronous Weak-commitment Search for Solving Distributed Constraint
Satisfaction Problems“, International Conference on Principles and Practice of Constraint Programming,
pages 88-102
21
Během zpracování algoritmu se každý agent nachází ve zvláštním okolí 18 a na začátku
nezná žádné jiné parametry ze skupiny V. Agent má také spojení se všemi agenty nebo se
speciálním mezisystémem, pomocí kterého může komunikovat s ostatními agenty. Každý
agent pracuje samostatně. V začáteční konfigurace, máme systém, ve kterém se nacházejí
všechny agenti, které mohou mezi sebou komunikovat(viz niž.). Znalostí každého agenta o
ostatních parametru ze skupiny V jsou prázdné a budou naplnění během práce algoritmu.
Začínáme tím, že algoritmus spustí operace definovaní hodnoty pro každého agenta.
Agent se snaží definovat pro svůj parametr hodnotu, která bude splňovat všechny
podmínky P. Když agent mění hodnotu, odesílá notifikace (notifikace má název „ok?“) do
všech jiných agentů. Zpracování různých notifikací je v tomto algoritmu důležité během
obdržení notifikace: agent mění své okolí a znalosti o jiných parametrech ze skupiny V a
jejich hodnotách. Po obdržení notifikace „ok?“ ostatní agenti ověřují své hodnoty a
omezení P, mění svou hodnotu stejným způsobem jako první agent, odesílají další
notifikace a také ukládají změněné či nové znalosti o parametrech do svého okolí. Když
agent nemůže vybrat správnou hodnotu pro svůj parametr, odesílá notifikaci chyby
(notifikace má název „nogood“). Když agent obdrží notifikaci „nogood“, musí označit stav
systému(běžné znalosti o parametrech) který uchovává ve svém okolí jako chybný
(„nogood“) a vrátit svou předchozí hodnotu. Seznam chybných stavů je v tomto algoritmu
důležitý. Všechní nogood stavy se přidávají jako omezující podmínka do skupiny P(nogood
stavy jsou ve speciálním seznamu „nogood list“), abych do teto situace nedošlo později.
Tento algoritmus pracuje výrazně rychleji než backtracking algoritmus, ale má také své
nevýhody. Během práce algoritmus neposkytuje žádné částečné řešení a musíme čekat, až
se celé zpracovaní dokončí. Algoritmus také přináší nové požadavky na paralelní
zpracování jednotlivých agentů, paměť (okolí jednotlivého agentu) a komunikační
schopnost mezi agenty. Ve své práci19 ale Roie Zivan a Amnon Meisel píšou, že rychlost
algoritmu ABT (Asynchronous Backtracking) lze zlepšit, když všechny agenty budou čekat
na všechny notifikace v běžné iteraci. Iterace – jedno zpracovávaní všech aktuálních
18 Okolí agenta – izolované prostředí, které uchovává informace o ostatní agenti a parametry. Taky
uchovává informace o všech podmínkách P a hodnotách ze skupiny D(V). Během práce algoritmu, agent
modifikuje své okolí: doplňuje nové informace či mění existující. Okolí reprezentuje stav „systému“ pro
každého agenta zvlášť.
19 Roie Zivan and Amnon Meisels, 2006 ,„Message delay and Asynchronous DisCSP search“
22
notifikací v jednotlivých agentech.
4.4.3 Weak-commitment search
Weak-commitment search je dalším vylepšením backtracking algoritmu. Algoritmus
používá jednotku „agent“ podobně jako Asynchronous Backtracking. Vlastnosti algoritmu
jsou: poskytování částečného řešení v jakémkoli momentu, používání min-conflict
ordering algoritmu.
Min-conflict ordering(search) algoritmus – speciální algoritmus, který vyhledává
hodnotu ze skupiny D(v) pro parametr v ze skupiny V, která vyvolává minimální množství
konfliktů s ostatními parametry ve skupině V podle omezujících podmínek P.
Algoritmus během práce vždy poskytuje částečné řešení. Hlavní myšlenkou algoritmu
je definovat hodnotu(ze skupiny D(v)) parametru (ze skupiny V) agenta a přidat ho do
částečného řešení. Detailní popis algoritmu můžete najít v kapitole „Detailní popis
použitého algoritmu“
Pro zvýšení rychlosti práce algoritmus používá min-conflict search pro hledání takové
hodnoty agenta, která má nejméně konfliktů s běžným stavem systému. Min-conflict
search algoritmus je velice důležitý a přímo ovlivňuje rychlost weak-commitment search
algoritmu.
Ilustrace 1: Weak-commetment search algortihm
Zdroj: Makoto Yokoo 21
23
Algoritmus je následující:
Máme dvě skupiny agentů20 - „left group of solution“(levá skupina řešení) a „partial
solution“ (částečné řešení). Algoritmus se v jedné iteraci snaží vzít agenta z levé skupiny,
definovat jeho hodnotu, která bude splňovat všechny podmínky P v rámci částečného
řešení a bude mít nejméně konfliktu s agenty levé skupiny. Na začátku zpracování se
všechny agenty nacházejí v levé skupině.
Když algoritmus takovou hodnotu definovat nemůže, přidává běžné částečné řešení
jako chybné(chybný stav) do „nogood listu“(které je součástí podmínek P) a přesouvá
všechny agenty do levé skupiny a začíná novou iteraci.
Tato bakalářská práce popisuje implementaci tohoto algoritmu pro řešení
problematiky automatického plánování harmonogramu předmětů. Weak-commitment
search vykazuje vysokou efektivitu a rychlost na příkladu řešení klasických zadaní: barvení
grafu, n-queens, 3SAT. Algoritmus je universální a je použitelný pro velké množství úkolů.
Jediný komponent algoritmu, který není universální a lze ho specifikovat pro konkretní
systém, je min-conflict search algoritmus.
Algoritmus podporuje dynamické přeplánování. Pro dynamické přeplánování musíme
přidat běžný stav do „nogood listu“ nebo přidat nové podmínky a přesunout všechny
agenty do levé skupiny. Dál pak jednoduše spustíme algoritmus, pokud změna byla malá,
neměla velký vliv na celý stav a pravděpodobnost, že velké množství agentů nezmění své
hodnoty, je vysoká. Když chceme kromě toho zafixovat nějakou hodnotu agentu, v minconflict search algoritmu budeme vracet vždy stejnout hodnotu nebo prázdnou hodnotu
(když existují konflikty s částečným řešením) a algoritmus se bude snažit vyřešit tento stav.
20 Dohromady jejich sjednocení je celé V (resp. Množina agentů odpovídající V)
24
4.4.4 Asynchronous weak-commitment search
Tento algoritmus je sjednocením asynchronous backtracking algoritmu a weakcommitment search algoritmu. Přidává novou vlastnost agenta – prioritu.21 Dál bude
popsán algoritmus stanovení priority.
Ilustrace 2: Procedures for receiving messages (AWC)
Původní hodnota priority je 0. V případě, že algoritmus nemůže definovat korektní
hodnotu agenta a spustí operaci přidání částečného řešení do „nogood listu“, zvýší prioritu
tohoto agenta(nová priorita se rovná maximální priorita v okolí agenta + 1). V algoritmu se
všechny genti snaží definovat svou hodnotu paralelně. Algoritmus vyhledává novou
pages 88-102
25
hodnotu pomocí min-conflict search algoritmu a pro minimalizaci konfliktů uvažuje jen
agenty, které mají vyšší prioritu. Když agent nemůže definovat svou hodnotu vůči
agentům, které mají nižší prioritu, běžný agent mění jejich hodnoty, aby nevyvolávaly
konflikty podle omezujících podmínek, a odesílá notifikace.
V našem případě by šlo použít i AWC, kdyby s tím nebylo několik problémů. Teoreticky
je algoritmus rychlejší než synchronní WC, ale jen v ideálním vícevláknovém prostředí.
Emulace tohoto prostředí, samozřejmě, zpomalí běh aplikace, což znamená, že aplikace
nebude tak rychlá jako WC. Z tohoto důvodu budu ve své práci používat synchronní WC s
prioritními agenty.
4.4.5 Příklad běhu asynchronous weak-commitment search
Na další ilustrace 3 můžete znázornit běh AWC algoritmu na příkladů úlohy N
dam(n=4)22.
Ilustrace 3: Příklad běhu AWC algoritmu
Vytvoříme 4 agenty, pro každou dámu. Přiřazeny parametr agenta je číslo řádku, kde se
nachází dáma(x1,x2,x3,x4). Číslo v závorce reprezentuje prioritu agenta. Počáteční
hodnota priority je 0. Počáteční hodnoty agentův jsou zobrazení na ilustrace (agent x1 = 1,
agent x2 = 4, agent x3 = 2, agent x4 = 4). Tato hodnota je generována náhodně, když
algoritmus spustil operace definovaní hodnoty agenta na začátku práce.
22 Problém osmi(v našem případě čtyř) dam je šachová úloha, respektive kombinatorický problém umístit
na šachovnici osm dam tak, aby se podle pravidel šachu navzájem neohrožovaly, tedy vybrat osm polí
tak, aby žádná dvě nebyla ve stejné řadě, sloupci, ani diagonální linii. Obecněji jde o to nalézt všechna
možná taková rozmístění nebo určit jejich počet.
26
Dal, agenty odesílají notifikace „ok?“ pro všechny ostatní agenty(„zpráva“,“odesílající
agent“,“hodnota“,“priorita“):
•
Agent x1 odesílá notifikace (ok?, „x1“, „0“, „0“)
•
Agent x2 odesilí notifikace („ok?“,“x2“,“4“,“0“)
•
•
V našem případě jen agent x4 není v konzistence s ostatní agenty, které mají stejnou
nebo vyšší prioritu. Agent x4 odesílá notifikace „nogood“ a zvětšuje své prioritu. Dal,
agent x4, pomocí min-conflict search algoritmu vyhledává novou hodnotu, která
minimalizuje množství konfliktu z ostatní agenty (nová hodnota je 3). Agent x4 definuje
své hodnotu jako 3 a odesílá notifikace („ok?“,“x4“,“3“,“1“) - ilustrace 3(b). Dal, agent x3 se
snaží změnit své hodnotu(běžná vyvolává konfliktu v omezujících podmínkách) ale to není
možná. Agent x3 taky zvětšuje své prioritu(nová priorita je 2(maximální priorita v okolí
agenta + 1)) a odesílá notifikace „nogood“. Dal, agent x3 vyhledává hodnotu která bych
minimalizovala konflikty vůči agentův x1 a x2 (protože mají menší prioritu) a odesíla
notifikace („ok?“,“x3“,“2“,“1“) - ilustrace 3(c). Dal, agent x1 mění definuje své hodnotu jako
2 a řešení je nalezeno (ilustrace 3(d)).
27
4.4.6 Srovnání rychlosti algoritmů
Pro srovnání rychlosti algoritmů lze použít následující tabulky z práce Makoto Yokoo23.
Symbol „-“ zmámená, že algoritmus neřešil úkol v odpovídající dobu.
Tabulka 4.1: Požadované množství cyklů pro n-queens problém
n
asynchronous
backtracking
min-conflict only
Asynchronous weak-commitment
10
105.4
102.6
41.5
50
662.7
623.0
59.1
100
931.4
851.3
50.8
1000
-
891.8
29.6
Zdroj: Makoto Yokoo23
Tabulka 4.2: Požadované množství cyklů pro problém barvení grafu
n
asynchronous
backtracking
min-conflict only
60
917.4
937.8
59.4
90
-
994.5
70.1
120
-
-
106.4
Tabulka 4.3: Požadované množství cyklů pro network resource allocation problém
asynchronous
backtracking
min-conflict only
984.8
428.4
17.3
pages 88-102
28
5. Návrh aplikace řešící problém plánování harmonogramu pro
Unicorn College
5.1 Detailní popis použitého algoritmu
Pro řešení běžného problému budeme používat Weak-Commitment Search algoritmus
s prioritními agenty (Ilustrace 4).
Tabulka 5.1: Použité pojmy v navrhu řešení
Pojem
Popis
Agent
Jednotka, která je vytvořená pro specifický parametr zadání a musí definovat
svou hodnotu. Agent A1 například obsahuje parametr „událost-čas“ a je
spojen s událostí „UA“, která je součástí předmětu „PA“.
Kontext
Jednotka algoritmu, která uchovává všechny agenty a nogood snímky.
Nogood
snímek
Angl. „snapshot“. Uchovává seznam agentů částečného řešení v moment, kdy
min. conflict algoritmus nemůže definovat hodnotu, aby se stejná situace
neopakovala později.
Leva část
řešení
Skupina agentů, které nemájí definovanou hodnotu nebo hodnota není
vhodná
Částeční
řešení
Skupina agentů, které mají definovanou hodnotu a nejsou v konfliktu s jinými
agenty v částečném řešení
WC
Weak-Commitment Search
Zdroj: Vlastní zpracování
Hlavní myšlenka algoritmu je definovat specifickou hodnotu pro každého agenta.
Podmínky definování hodnoty:
•
Hodnota agenta a samotný agent nemusejí být v konfliktu s jinými agenty v
částečném řešení.
•
Hodnota agenta a samotný agent musí mít nejméně konfliktů s levou častí řešení v
porovnání s jinými možnými hodnotami agenta.
•
Hodnota při definování nemusí vést ke stavu, který je zapsaný v jakémkoli nogood
snímku.
Všechny tyto podmínky musí být zapsány ve specifickém min. conflict search
algoritmu, který definuje hodnotu agenta.
29
30
5.1.1 Algoritmus
Algoritmus na začátku přesouvá všechny agenty do levé části řešení. Poté začne
„iterace přesouvání“. WC algoritmus musí vybrat takového agenta z levé části řešení, který
splňuje následující podmínky:
•
Všechny agenty, na nichž je závislý, musejí být v částečném řešení.
•
Musejí mít nejvyšší prioritu.
Když není možné vybrat agenta, ale přesto agenty v levé častí řešení existují, znamená,
to, že agenty mají cyklickou závilost a tuto situaci není možné řešit – řešení neexistuje.
Když není možné vybrat agenta, protože levá část řešení je prázdná, pak jsou všechny
agenty v částečném řešení – řešení nalezeno.
Když je možné vybrat agenta, pak definujeme, že tento agent je běžný, a postupujeme
dál.
Algoritmus používá min. conflict search vyhledávání hodnoty agenta. Pro každý
jednotlivý typ parametru (událost-čas, událost-místnost, událost-vyučující) bychom měli
mít zvláštní min-conflict search algoritmus. Tento algoritmus musí zjistit hodnotu agenta
podle definovaných podmínek. Podmínky jsou popsány v kapitole „Popis specifického
plánovacího problému pro Unicorn College“ a jsou následující: „celá výuka je časové
omezená, pracovní doba vyučujícího je omezena, studenti nemusejí mít zapsané události
ve stejný čas“ atd.
Když hodnota, která je vrácena min-conflict search algoritmem, není prázdna, pak
definujeme hodnotu agenta, přesuneme ho do částečného řešení a začneme další iteraci.
Když vrácená hodnota je prázdná a částečné řešení též, pak řešení neexistuje.
Když vrácená hodnota je prázdná a částečné řešení není prázdné, pak musíme vytvořit
nový nogood snímek a uložit ho do kontextu. Zvýšíme prioritu běžného agenta(maximální
priorita v kontextu +1) a přesuneme všechny agenty do levé častí řešení. Konec iterace
hledaní.
31
5.1.2 Optimalizace algoritmu
Pro algoritmus je možné použít několik optimalizací pro zrychlení.
1. Práce se skupinami agentů v kontextu24: levá část řešení a částečné řešení. Pro
zrychlení přesouvání agentů mezi skupinami je možné zadat nový parametr agenta
(„kontext-skupina“) a uchovávat všechny agenty v jednom poli.
2. Ověření, že nová hodnota neexistuje v žádném nogood snímku. Tato operace je
často používána pro hledaní nové hodnoty agenta. Nogood snímek je vytvořen
tehdy, když agent nemůže definovat svou hodnotu. Aby nedošlo k této situaci
opakovaně, musíme vyhledávat takovou hodnotu, která nepřivede běžný stav do
jednoho ze stavů, který se nachází v nogood listu. Optimalizace může být
provedena ve třech etapách.
◦ V první etapě (před spuštěním min. conflict algoritmu) vybíráme pouze ty
nogood snímky, které mají velikost částečného řešení +1. Plus jeden, protože
budeme přidávat novou hodnotu.
◦ Pro další etapu musíme přidat do agenta možnost počítat unikátní číslo. Toto
číslo identifikuje agenta, který je díky tomu závislý na následujících
jednotkách: hodnota agenta, typ parametru agenta a objekty zadaní, které
souvisí s tímto agentem. Máme například agenta, který reprezentuje
parameter „událost-místnost“(napr. identifikační číslo 1), je spojen s událostí
U1 (identifikační číslo 34) a má hodnotu M1 (identifikační číslo 57). Generátor
unikátního čísla by musel vratít číslo závislé na těchto datech, např.
((1*100)+34)*100+57 = 13457 a toto číslo bude používáno jako identifikátor
agenta. Pro každý nogood snímek a pro aktuální částečné řešení musíme sečíst
všechny unikátní čísla agentů a uložit jako novou charakteristiku seznamu
agentů (hash číslo). Dál, když ověřujeme novou hodnotu, sečteme hash číslo
částečného řešení a unikátní číslo agenta s novou hodnotou. Nové číslo
porovnáme s hash číslem všech nogood snímku. Když byl nalezen snímek, který
má stejné hash číslo, postupujeme do třetí etapy.
24
Jednotka algoritmu, která uchovává všechny agenty a nogood snímky
32
◦ V poslední etapě musíme porovnat vhodný nogood snímek s průběžným
částečným řešením (+ nová hodnota). Pro optimalizaci této etapy musíme
vytřídit agenty průběžného částečného řešení podle jejich unikátního čísla. V
takovém stavu srovnání nogood snímku a částečného řešení vyžaduje max. N
operací porovnání (počet agentů v nogood snímku).
3. Uchování agentů v kontextu struktury „sorted array/list“. Lze také řadit agenty
podle unikátního čísla, který potřebujeme pro předchozí optimalizace či priority
agenta. Když nebudeme používat první optimalizaci, je možné vytvořit dvě pole:
pro částečné řešení a pak řadit podle unikátního čísla, a pro levou čast řešení a
řadit podle priority agenta.
V navrhu řešení a jeho implementace budeme používat optimalizaci č. 2 a kombinaci
optimalizací 1 a 3, které porovnáme včetně jejich kombinací (tabulky 5.2 a 5.4).
Tabulka 5.2: Porovnání optimalizací (jeden seznam)
Jeden seznam
Vybrat agenta z
O(n)
levé častí řešení
Přesunout
agenta mezi
O(1)
skupinami
Změnit prioritu
O(1)
agenta
Seřadit
seznam(pro
O(nlogn)
nogood ověřeni)
Jeden seznam
uspořádaný podle
unikátních čísel agentů
O(n)
Jeden seznam uspořádaný
podle priority agentu
O(1) – závilost agenta zvýší
náročnost
O(n) – přesunout levou O(n) – přesunout z částečného
část do částečného řešení řešení do levé častí
O(1)
O(n)
O(1)
O(nlogn)
33
Tabulka 5.3: Porovnání optimalizace (dva seznamy)
Vybrat agenta z levé
časti řešení
Přesunout agenta
mezi skupinami
Změnit priority
agenta
Seřadit seznam (pro
nogood ověřeni)
Dva seznamy
Dva uspořádané seznamy
O(n)
O(1) – zavilost agenta zvýší náročnost
O(n)
O(n)
O(1)
O(n)
O(nlogn)
O(1)
Ze srovnávacích tabulek vyplývá, že nejlepší optimalizace je implementace jediného
listu agentů ve struktuře „sorted list“, který je řazen podle unikátního čísla agenta.
5.2 Návrh knihovny pro řešení problematiky automatického plánovaní
Knihovna pro řešení problému plánovaní pomocí Weak-Commitment Search algoritmu
musí být univerzální. Knihovna musí poskytovat možnost přidávat libovolné objekty a
nastavovat parametry pro řešení aktuálního stavu systému. Knihovna kromě toho musí
poskytovat metody pro kontrolu algoritmu během výpočtu. Název knihovny je MWCS
library (Modified Weak-Commitment Search).
5.2.1 Use-case diagram
Případy užití (use-case), které bude řešit knihovna, jsou zobrazeny na ilustraci 5. Jediný
aktér na diagramu je aplikace, která používá knihovnu. Popis jednotlivých use-case se
nachází v tabulce 5.4
34
Ilustrace 5: Use-case diagram - MWCS knihovna
Tabulka 5.4: Popis use-case knihovny MWCS
Kód
Use-case
Popis
UC01 Přidat informace o všech Knihovna musí poskytovat metody pro přidání agentů
objektech
pro jednotlivé objekty a parametry systému
UC02 Přidat min. conflict
search algoritmy
Knihovna musí poskytovat metody pro nastavení
specifického algoritmu pro vyhledání hodnoty, která by
mohla být v konzistenci se všemi existujícími omezeními
UC03 Přidat algoritmy pro
generování unikátních
čísel
Knihovna musí poskytovat metody pro přidání
jednotlivých algoritmů generování unikátních čísel pro
agenty
UC04 Spustit další iteraci
Aplikace musí mít možnost kontrolovat průběh výpočtu
UC05 Získat informaci o stavu
výpočtu
Aplikace musí mít možnost dostávat informace o stavu
výpočtu (stav běhu, agenty, nogood list)
35
5.2.2 Domain model
Na ilustraci 6 (ilustrace je rozdělená na jednotlivé části v dalších kapitolách) je
zobrazen domain model celé knihovny. MWCS knihovnu lze rozdělit na dvě části: Solver
prostředí a Agent prostředí. Solver prostředí řeší vypočítání a běh WC algoritmu. Agent
prostředí řeší práci s daty a specifickými min. conflict search algoritmy.
Ilustrace 6: MWCS domain model
Popis jednotlivých tříd se nachází v tabulce 5.5. V této tabulce jsou popsány hlavní
elementy knihovny a souvislost jednotlivých jednotek s use-case modelem. Implementace
jednotlivých tříd bude popsána v další části této práce.
Příklad použití knihovny lze vidět na sekvenčním diagramu (7). Na ilustraci je zobrazen
způsob použití a komunikace s knihovnou. Na této ilustraci je možné vidět také postup
použití jednotlivých metod a operací pro řešení problematiky automatického plánování.
Práci s knihovnou lze rozdělit na dvě častí: transformace objektového modelu ze systému a
rovněž spuštění a kontrola algoritmu. V prví části musí aplikace vytvořit agenty a
definovat jejich parametry a objekty související s agenty. Dál pak musí aplikace nastavit
algoritmus min. conflict search a také algoritmus generovaní unikátních čísel pro každý typ
parametru. V druhé častí musí aplikace kontrolovat běh algoritmu a měla by se stále
36
spouštět iterace, dokud se nedostane k jednomu z následujících výsledků: řešení existuje
či neexistuje.
Tabulka 5.5: MWCS domain model - popis
Třída
Use
case
Prostředí
Popis
Solver
UC04
UC05
Solver
Poskytuje metody pro kontrolu běhu
algoritmu
Context
UC01
UC05
Solver
Úložiště všech dat v systému
ContextNogoodSnapshot
Solver
Specifický kontejner pro uložení kopie
kontextu
AgentNogood
Solver
Specifický kontejner pro uložení kopie
agentu
Agent
UC01
Agent
Jednotka, která reprezentuje parametr,
pro který je nutné definovat hodnotu
Parameter
UC01
Agent
Popisuje parametr agenta; úložiště
souvisejících dat
ParameterType
UC03
UC02
Agent
Popisuje typ konkrétního parametru a
poskytuje přístup k min. conflict search a
algoritmu generovaní unikátního čísla
IMinConflictSearchAlg
UC03
UC02
Agent
Univerzální rozhraní pro min. conflict
search algoritmus
Během práce algoritmu má uživatelská aplikace přístup ke všem datům uvnitř
knihovny. Aby nedošlo k chybám, min. conflict search algoritmus nesmí měnit data, která
souvisejí s agenty v uživatelské aplikaci. Knihovna zpracovává události pro změnu hodnoty,
priority a stav agentu. Aplikace musí definovat delegáty pro tyto události. Měnit data v
objektovém modelu aplikace je možné jen v době spuštění delegátu.
V další kapitole se popisuje základní návrh knihovny: základní třídy a jejich atributy a
metody. V kapitole o implementaci knihovny se popisuje konkretní realizace jednotlivých
častí knihovny MWCS.
37
Ilustrace 7: Sekvenční diagram použíti knihovny
5.2.3 Popis jednotlivých částí systému
Třída MWCS::Solver – základní jednotka pro přístup k algoritmu a datům, která
poskytují funkčnost pro vytváření jednotlivých instancí algoritmu. Hlavní funkčnost –
kontrola běhu algoritmu.
Tabulka 5.6: Třída MWCS::Solver - Atributy
Atribut
Popis
iteration
Uchovává pořadové číslo běžně iterace
context
Běžný kontext algoritmu, který uchovává všechna data
result
Běžný stav běhu algoritmu
Tabulka 5.7: Třída MWCS::Solver - Metody
Metoda
Popis
Solver
Konstruktor
nextIteration
Spustit další iteraci algoritmu
38
Třída MWCS::Context – třída, která poskytuje metody pro kontrolu hodnoty na
nogood snímcích. Uchovává všechna data algoritmu.
Tabulka 5.8: Třída MWCS::Context - Atributy
Atribut
Popis
agents
Seznam všech agentů, které jsou používané v algoritmu
hash
Hash číslo, které je používané pro optimalizaci ověřeni hodnoty
podle nogood listu
leftSideAgentsCount
Číslo ukazuje na množství agentů, které se nacházejí v levé části
řešení a jejich hodnota není definovaná
rightSideAgentsCount
Číslo ukazuje na množství agentů, které se nacházejí v
částečném řešení a jejich hodnota je definovaná
nogood
Seznam, který uchovává všechny nogood snímky, které byly
vytvořeny během práce algoritmu
Tabulka 5.9: Třída MWCS::Context - Metody
Metoda
Popis
Context
Konstruktor
snapshotWithSize
Vrátí seznam nogood snímků. Množství agentů v každém
snímku se rovná definovanému číslu.
moveAgent
Změna stavu agenta
checkValueWithNogood Ověřit hodnotu agenta podle nogood listu
Třída MWCS::ContextNogoodSnapshot – uchovává seznam agentů a hash číslo
kontextu ve chvíli vzniku snímku.
Tabulka 5.10: Třída MWCS::ContextNogoodSnapshot - Atributy
Atribut
Popis
hash
Hash číslo kontextu
agents
Seznam agentů a jejich hodnot v částečném řešení v momentu
vytvoření snímku
39
Tabulka 5.11: Třída MWCS::ContextNogoodSnapshot - Metody
Metoda
Popis
ContextNogoodSnapshot
Konstruktor
Třída MWCS::AgentNogood – je speciální třída, která uchovává hodnotu a
souvisejícího agenta pro vytvoření nogood snímku.
Tabulka 5.12: Třída MWCS::AgentNogood - Atributy
Atribut
Popis
agent
Související agent
hash
Unikátní číslo agenta
value
Hodnota agenta
Tabulka 5.13: Třída MWCS::AgentNogood - Metody
Metoda
AgentNogood
Popis
Konstruktor
Třída MWCS::Agent::Agent – reprezentuje základní jednotku dat pro práci algoritmu.
Uchovává hodnotu agenta a související parametr.
Tabulka 5.14: Třída MWCS::Agent::Agent - Metody
Metoda
Popis
Agent
Konstruktor
hash
Vrátí unikátní číslo pro běžný stav agenta
onPriorityChanged
Spustit událost pro změnu priority agenta
onValueChanged
Spustit událost pro změnu hodnoty agenta
onSideChanged
Spustit událost prozměnu stavu agenta
40
Tabulka 5.15: Třída MWCS::Agent::Agent - Atributy
Atribut
Popis
id
Automaticky generovaný identifikátor agenta
priority
Priorita agenta v algoritmu
value
Aktuální hodnota agenta
dependencies
Seznam agentů, na nichž je závislý běžný agent
PriorityChanged
Obsluhování události změny priority agenta
ValueChanged
Obsluhování události změny hodnoty agenta
SideChanged
Obsluhování události změny stavu agenta
side
Aktuální stav agenta
parameter
Související parametr agenta
Třída MWCS::Agent::Parameter – reprezentuje jednotku uživatelských dat a definuje
typ agenta. Uchovává související uživatelská data.
Tabulka 5.16: Třída MWCS::Agent::Parameter - Atributy
Atribut
Popis
details
Uchovává související uživatelská data pro souvisejícího agenta
type
Jednotlivý typ parametru, který umožňuje přístup do specifických
algoritmů. Tento algoritmus potřebuje WC.
Tabulka 5.17: Třída MWCS::Agent::Parameter - Metody
Metoda
Parameter
Popis
Konstruktor
Třída MWCS::Agent::Events::AgentEventArgs – Třída, která uchovává souvisejícího
agenta pro zpracovaní události změny priority/hodnoty/stavu agenta.
Tabulka 5.18: Třída MWCS::Agent::Events::AgentEventArgs - Atributy
Atribut
agent
Popis
Související
41
Tabulka 5.19: Třída MWCS::Agent::Events::AgentEventArgs - Metody
Metoda
Popis
AgentEventArgs
Konstruktor
Třída MWCS::Agent::ParameterType – reprezentuje jednotlivý typ parametru agenta.
Uchovává specifické algoritmy pro práci s agentem a uživatelská data.
Tabulka 5.20: Třída MWCS::Agent::ParameterType - Atributy
Atribut
Popis
id
Automaticky generovaný identifikátor typu
name
Název typu parametru agentu
alg
Uchovává jednotlivý algoritmus pro hledání další hodnoty agenta
Tabulka 5.21: Třída MWCS::Agent:: ParameterType - Metody
Metoda
Popis
ParameterType Konstruktor
agentHash
Vrátí unikátní hash číslo, které je závislé na hodnotě agenta, související
uživatelská data a typ parametru
Rozhraní MWCS::Agent::IMinConflictSearchAlg – popisuje rozhraní pro implementaci
specifického algoritmu, který hledá hodnoty agenta.
Tabulka 5.22: Třída MWCS::Agent::IMinConflictSearchAlg - Metody
Metoda
nextValue
Popis
Vrátí novou hodnotu agenta, která je v konzistenci se všemi omezeními
dat a nogood listů.
42
Ilustrace 8: Datová vrstva aplikace
5.3 Návrh aplikace plánovaní
Požadavkem pro vývoj aplikace je naprogramovat plánovací systém, který vytvoří
harmonogram předmětů pro cely semestr na základě školních dat.
Aplikaci lze rozdělit na tří častí: Business25 vrstvu, GUI26 a Datovou vrstvu.
Datová vrstva se zabývá kontrolou všech dat v systému. GUI se zabývá reprezentací
všech dat uživatele.
5.3.1.1 Businnes vrstva
Tato vrstva bude řešit úlohu práce s daty a samotné plánovaní harmonogramu.
Obsahuje metody pro ukládání, načítání a změnu dat. Součást plánování obsahuje
nutné min-conflict search algoritmy a generátory unikátních čísel agentů.
25 Business vrstva se zabývá funkčními požadavky a prací s daty a datovou vrstvou.
26 GUI – Graphic User Interface se zabývá zobrazováním dat.
43
5.3.2 Datová vrstva
Na ilustraci 8 je zobrazena datová vrstva, kterou potřebujeme pro splnění požadavků
na aplikaci. Následuje popis jednotlivých elementů této vrstvy.
Datovou vrstvu lze rozdělit na dvě části: základní informace o škole a informace o
harmonogramu. Informace o harmonogramu přitom budou uchovávat také základní školní
data.
5.3.2.1 Základní informace o škole
Tato část vrstvy musí uchovávat další informace:
•
Všechny předměty školy
•
Všichni studenti školy
•
Všechny místnosti školy
•
Všichni vyučující školy
Událost obsahuje další časové omezení:
•
Seznám časových intervalů, kdy může/nemůže probíhat školní výuka
5.3.2.1.1 Předměty
Každý předmět uchovává další informace:
•
Název předmětu
Předmět je provázán s dalšími objekty:
•
Seznam studentů, kteří studují tento předmět
•
Seznam událostí, které v semestru jsou a lze je rozdělit podle typu: přednáška a
seminář.
5.3.2.1.2 Událost předmětu
Každá událost uchovává další informace:
•
Název události
•
Délka trvání události
44
Událost je spojena s dalšími objekty:
•
Seznam mistrností, kde událost může probíhat
•
Seznam vyučujících, kteří mohou vyučovat tento předmět
•
Seznam událostí, na nichž je běžná událost závislá
5.3.2.1.3 Student
Informace o každém studentovi obsahuje:
•
Jméno studenta
Student je spojen s dalšími objekty:
•
Seznam předmětů, které sleduje tento student
5.3.2.1.4 Vyučující
Každý vyučující uchovává další informace:
•
Jméno vyučujícího
•
Seznam časových intervalů, kdy může/nemůže pracovat vyučující
Vyučující je povázán s dalšími objekty:
•
Seznam předmětů, které vyučuje tento vyučující
5.3.2.1.5 Místnost
Každá místnost uchovává další informace:
•
Budova, kde se nachází běžná učebna
•
Název místnosti
•
Kapacita místnosti
Místnost je spojena s dalšími objekty:
•
Seznam událostí, které mohou probíhat v této místnosti
45
5.3.2.2 Informace o harmonogramu
Do události musíme přidat další informace:
•
Čas počátku události
•
Fixní čas začátku (doplňující informace pro případ, že bude nutné změnit a
naplánovat znovu/doplnit existující harmonogram)
•
Vyučující
•
Místnost
Do mistnosti musíme přidat další informace:
•
Uchovává seznam událostí, které budou probíhat v této místnosti.
Do yučujícího musíme přidat další informace:
•
Uchovává seznam událostí, které bude učit během semestru.
46
5.3.3 GUI
Aplikaci lze rozdělit na dvě časti: přehled a modifikace všech dat a proces plánovaní
harmonogramu a jeho výprava
První část musí poskytovat další možností:
•
CRUD27 předmětů, seznám předmětů
•
CRUD událostí
•
CRUD studentů, seznám studentů
•
CRUD vyučujících, seznám vyučujících
•
CRUD místností a budov, seznam místností a budov
•
CRUD časové omezení výuky školy
•
Ukládaní a načítaní informací
Druhá část aplikace musí poskytovat další možnosti:
•
Ukládaní a načítaní harmonogramu
•
Spuštění a kontrola průběhu plánování
•
Modifikace částečně naplánovaného harmonogramu
27 CRUD – (angl. Create Read Update Delete) – skupina funkčností, které poskytují základní metody pracé s
daty: vytvořit nový objekt, prohlédnout data, změnit a smazat.
47
6. Implementace navržené aplikace
Pro implementaci byla vybrána platforma .NET Framework od společnosti Microsoft ve
verzi 4 a jako vývojový nástroj – MS Visual Studio 2012.
6.1 Implementace knihovny
Na ilustraci 9 je zobrazen class diagram cele knihovny. Na ilustracích 10 a 11 jsou
zobrazeny jednotlivé častí knihovny: Solver a Agent prostředí. Dál popisujeme
implementaci jednotlivých tříd. Součástí implementace knihovny je dokumentace, která
popisuje všechny nutné elementy a příklady použití. Během vývoje knihovny byla navíc
vyvíjena aplikace „N-Queens“ pro účely testovaní a jako praktický příklad použití knihovny.
Tato aplikace řeší klasickou úlohu osmi dam (je možné i více). Problém osmi dam je
šachová úloha, respektive kombinatorický problém, jak umístit na šachovnici osm dam
tak, aby se podle pravidel šachu navzájem neohrožovaly, tedy vybrat osm polí tak, aby
žádná dvě nebyla ve stejné řadě, sloupci ani diagonální linii. V příkladech dokumentace
budou použity zdrojové kódy z teto aplikace. Všechní další uvedené obrázky jsou součástí
přílohy A na CD.
48
Ilustrace 9: MWCS class diagram
6.1.1 Implementace prostředí Solver
Prostředí Solver se zabývá kontrolou běhu algoritmu a přístupu ke všem datům
algoritmu. Na ilustraci 11 je zobrazena detailní struktura tohoto prostředí. V dalších
kapitolách popisuji realizaci tříd, jejich atributů a metod a rovněž podmínky a příklady
použíti jednotlivých metod.
49
Ilustrace 10: MWCS class diagram - Solver
6.1.1.1 Třída Solver
Hierarchie dědičnosti: System.Object → MWCS.Solver
Assembly: MWCS (MWCS.dll)
Namespace: MWCS
50
Thread safety: Ne
Syntax: public class Solver
6.1.1.1.1 Konstruktory
Tabulka 6.1: Implementace třídy MWCS::Solver - Konstruktory
Modifikátory
public
Syntax
Solver()
Popis
Vytvořit novou instanci algoritmu
6.1.1.1.2 Atributy
Tabulka 6.2: Implementace třídy MWCS::Solver - Atributy
Modifikátory
public
Syntax
Popis
SolverResult
result
Běžný stav výpočtu. Počáteční
hodnota
SolverResult.Unknown
6.1.1.1.3 Vlastnosti
Tabulka 6.3: Implementace třídy MWCS::Solver - Vlastnosti
Modifikátory
Syntax
Popis
public get
internal set
Context
context
Související kontext
public get
internal set
uint
iteration
Číslo běžné iterace
public get
internal set
uint
maxAgentPriority
Max. priorita agenta v kontextu
6.1.1.1.4 Metody
Tabulka 6.4: Implementace třídy MWCS::Solver - Metody
Modifikátory
public
Syntax
void
nextIteration()
51
Popis
Spustit další iteraci
6.1.1.1.5 Poznámky
Tato třída zajišťuje kontrolu běhu algoritmu a přístup k samotným datům algoritmu.
Příklady jsou převzaty z testovací aplikace Nqueens.
Uživatelská aplikace musí manuálně spouštět každou iteraci do té doby, než se stav
změní na Solved či NotExisted. Počáteční stav atributu result je Unknown.
6.1.1.1.6 Implementace metody void nextIteration()
public void nextIteration()
{
if (result == SolverResult.Solved || result == SolverResult.NotExisted) return;//Check
current state
iteration++;
if (result == SolverResult.Unknown)//Initialization
{
//move all agent to left part of solution
foreach (Agent.Agent agent in context.agents)
{
context.moveAgent(agent, ContextSide.Left);
}
result = SolverResult.Running;//Change state
}
if (context.leftSideAgentsCount == 0)//All agents have defined values, problem
is solved
{
result = SolverResult.Solved;
return;
}
Agent.Agent currentAgent = null;
foreach (var agent in context.agents)//Search agent in left part of solution
with max. priority
{
if (agent.side == ContextSide.Left && (currentAgent==null ||
agent.priority>currentAgent.priority))
{
bool dependencies = true;
foreach (var a in agent.dependencies)
{
if (a.side != ContextSide.Partial)
{
dependencies = false;
break;
}
}
if(dependencies)
currentAgent = agent;
}
}
object value = null;//New value for agent
if (currentAgent != null)//Agent was not founded. It means, that context contains
cyclic dependencies
{
//Method nextValue must find value.
//It will be good with current partial solution and good with nogood list.
//Optional: minimize conflicts with all left agents.
//Need to prepeare spec. nogood list for checking optimization,
//where agents list size will be "current partial solution size + 1"
value = currentAgent.parameter.type.alg.nextValue(currentAgent, context,
context.snapshotsWithSize(context.partialSideAgentsCount + 1));
}
//Min. conflict search alrogithm found good value. Need to move currentAgent to
partial solution.
52
if (value != null)
{
currentAgent.value = value;
context.moveAgent(currentAgent, ContextSide.Partial);
context.hash -= currentAgent.hash();//spec. simple hash for nogood list
checking optimization
context.hash += currentAgent.hash();
}
else//Good value was not founded
{
if (context.partialSideAgentsCount == 0 || currentAgent==null)//Problem has
not solution
{
result = SolverResult.NotExisted;
}
else//Add current partial solution as new nogood state
{
currentAgent.priority = maxAgentPriority + 1;//change priority of
agent, which triggered this situation
maxAgentPriority = currentAgent.priority;
context.nogood.Add(new ContextNogoodSnapshot(context));
foreach (var agent in context.agents)//move all agents to left and
begin new solving iteration
{
context.moveAgent(agent, ContextSide.Left);
}
}
}
}
6.1.1.1.7 Příklad použití
Samotný kód a komentáře jsou v angličtině. Tento příklad ilustruje způsob spuštění
algoritmu v jiném vláknu a jeho kontrolu.
public void start()
{
running = true;
solvingThread = new Thread(delegate() {
this.solve(interval);
});//New thread for solving
solvingThread.Start();
}
public void solve(uint interval)
{
//Checking for running status, solving result
while (running
&& solver.result != MWCS.SolverResult.Solved
&& solver.result != MWCS.SolverResult.NotExisted)
{
solver.nextIteration();//Next algorithm iteration
}
}
public void stop()
{
running = false;//Stop algorithm. It is used as cross-thread synchronization
if (solvingThread != null)
{
if (solvingThread.ThreadState==ThreadState.Running)
{
solvingThread.Join();//Wait for canceling
}
solvingThread = null;
}
}
53
6.1.1.2 Třída Context
Hierarchie dědičnosti: System.Object → MWCS.Context
Namespace: MWCS
Thread safety: Ne
Syntax: public class Context
Tabulka 6.5: Implementace třídy MWCS::Context - Konstruktory
Modifikátory
Syntax
internal
Context()
Popis
Vytvořit novou instanci kontextu
6.1.1.2.2 Atributy
Tabulka 6.6: Implementace třídy MWCS::Context - Atributy
Modifikátory
Syntax
Popis
public
readonly
List<Agent>
agents
Všechny agenty v aktuální instanci
algoritmu
public
readonly
List<ContextNogoodSnapshot>
nogood
Seznam všech nogood snímků
Tabulka 6.7: Implementace třídy MWCS::Context - Vlastnosti
Modifikátory
Syntax
Popis
public get
private set
uint
leftSideAgentsCount
Počet agentů v levé časti řešení
public get
private set
uint
partialSideAgentsCount
Počet agentů v částečném řešení
public get
internal set
uint
hash
Běžné hash číslo částečného
řešení
54
6.1.1.2.4 Metody
Tabulka 6.8: Implementace třídy MWCS::Context - Metody
Modifikátory
Syntax
Popis
public
snapshotsWithSize
(uint size)
Vybrat nogood snímky, na
kterých se počet agentů
rovná size
public
bool
checkValueWithNogood
(Agent agent,
object curValue,
nogood)
Ověřit novou hodnotu
agenta podle nogood
snímků
internal
void
moveAgent
(Agent agent,
ContextSide toSide)
Změnit stav agenta
6.1.1.2.5 Poznámky
Kontext je hlavní úložiště instance algoritmu. Uchovává všechny agenty a nogood
snímky. Nelze vytvořit ručně. Automaticky se vytvoří v konstruktoru třídy Solver.
6.1.1.2.6 Implementace metody bool checkValueWithNogood (Agent agent, object
curValue, List<ContextNogoodSnapshot> nogood)
//Nogood list checking
public bool checkValueWithNogood(Agent.Agent agent, object curValue,
List<ContextNogoodSnapshot> nogood)
{
bool satisfyNogood = true;//method result
//Current context's agents list is sorted by hash(on Solver.nextIteration method)
//All nogood's agents lists are sorted by hash too
foreach (var nogoodContext in nogood)
{
if (!satisfyNogood) break;
if (this.partialSideAgentsCount + 1 != nogoodContext.agents.Count) continue;//Check
agents lists size
if (nogoodContext.hash == this.hash + agent.hash(curValue))//Firstly, need to compare
by hashes
{//Hashes are same, but need to check raw agents list
var contextAgentIterator = this.agents.GetEnumerator();
bool curValueUsed = false;//New value can be used only one time
foreach (var nogoodContextAgent in nogoodContext.agents)
{
//Searching next partial agent in current context
while (contextAgentIterator.Current!=null && contextAgentIterator.Current.side !=
MWCS.ContextSide.Partial && contextAgentIterator.MoveNext()) ;
//check next agent
55
if (contextAgentIterator.Current!=null &&
contextAgentIterator.Current.side == MWCS.ContextSide.Partial)
{
bool nextAgent = true;//If new value will be used, we will not move to next agent
//Compare agents by hash. Hash are unique for unique agent's parameter
type+value+details setup
if (nogoodContextAgent.hash != contextAgentIterator.Current.hash())
{
satisfyNogood = false;//conflict
break;
}
else if (nogoodContextAgent.hash == agent.hash(curValue))//check for new value
{
if (curValueUsed)//New value can be used only one time
{
break;
}
else
{
//Use new value
curValueUsed = true;
nextAgent = false;//Need to use current agent in next checking iteration
}
}
else
{
break;
}
if(nextAgent)//move to next agent
contextAgentIterator.MoveNext();
}
else if (contextAgentIterator.Current == null)//New agent was not founded. This
situation should not be reached, but...
{
break;
}
}
//break; if satisfyNogood is true, need to check other nogood snapshots (this
situation is very very very rare)
}
}
return satisfyNogood;
}
Samotný kód a komentáře jsou v angličtině. Příklady jsou převzaty z testovací aplikace
N-Queens, která součástí přílohy A na CD..
6.1.1.2.7.1 Generace agentů
public NQueens()
{
solver = new MWCS.Solver();
//Custom parameter type for agents
MWCS.Agent.ParameterType type = new YPositionParameterType(new
YMinConflictSearchAlg(this));
for (uint i = 0; i < N; i++)//Creating of queens
{
Queen queen = null;
queen = new Queen(i, 0);
queens.Add(queen);
MWCS.Agent.Parameter parameter = new MWCS.Agent.Parameter(type);//Parameter for
individual agent instance
56
parameter.details = new object[1] {queen};//Set details object
MWCS.Agent.Agent agent = new MWCS.Agent.Agent(parameter, (uint)queen.Y);//New Agent
instance with spec. parameter, details, min. conflict search algorithm, hash function..
agent.ValueChanged += this.updateQueenY;//For state & UI updating
agent.SideChanged += this.updateQueenSide;//For state & UI updating
solver.context.agents.Add(agent);
}
}
6.1.1.2.7.2 Ověření nové hodnoty agenta podle nogood listu
public class YMinConflictSearchAlg : MWCS.Agent.IMinConflictSearchAlg
{
public object nextValue(MWCS.Agent.Agent agent,
MWCS.Context context,
List<MWCS.ContextNogoodSnapshot> nogood)
{
//Get current queen object from agent details
Queen queen = (Queen)agent.parameter.details[0];
uint curValue = (uint)agent.value;//Get current value
uint bestValue = queen.Y;
for (uint i = 0; i < enviroment.N; i++)//Possibles values are 0..(N-1)
{
uint conflicts = 0;//Number of conflicts with left agents
//Is value in consistency with partial solution?
bool satisfyPartialSolution = true;
//Is value in consistency with nogood?
bool satisfyNogood = context.checkValueWithNogood(agent, curValue,
nogood);
if(satisfyNogood)
//Need to calculate number of conflicts with every agents
//Need to check consistency with partial solution
foreach (var a in context.agents)
{
//...
}
if (satisfyPartialSolution && satisfyNogood)
{
//...
}
curValue = //...;
}
return bestValue;
}
}
6.1.1.3 Třída ContextNogoodSnapshot
Hierarchie dědičnosti: System.Object → MWCS.ContextNogoodSnapshot
Namespace: MWCS
Thread safety: Ne
Syntax: public class ContextNogoodSnapshot
57
Tabulka 6.9: Implementace třídy MWCS::ContextNogoodSnapshot - Konstruktory
Modifikátory
internal
Syntax
Popis
ContextNogoodSnapshot(Context context) Vytvořit novou instanci snímku
kontextu
6.1.1.3.2 Atributy
Tabulka 6.10: Implementace třídy MWCS:: ContextNogoodSnapshot - Atributy
Modifikátory
Syntax
Popis
public
uint
hash
Všechny agenty v aktuální instanci
algoritmu
public
readonly
List<AgentNogood>
agents
Seznam agentů částečného řešení v
moment vytvoření snímku
6.1.1.3.3 Poznámky
Hlavní funkčnost této třídy je zapamatování seznamu agentů pro budoucí ověření
hodnoty podle nogood listů.
6.1.1.4 Třída AgentNogood
Hierarchie dědičnosti: System.Object → MWCS.Agent.AgentNogood
Namespace: MWCS::Agent
Thread safety: Ne
Syntax: public class AgentNogood
Tabulka 6.11: Implementace třídy MWCS::Agent::AgentNogood - Konstruktory
Modifikátory
internal
Syntax
Popis
AgentNogood(Agent agent)
58
Vytvořit novou instanci snímku
agenta
Tabulka 6.12: Implementace třídy MWCS:: Agent::AgentNogood - Vlastnosti
Modifikátory
Syntax
Popis
public get
internal set
Agent
agent
Související agent
public get
internal set
object
value
Hodnota agenta v moment
vytvoření snímku
public get
internal set
uint
hash
Unikátní číslo agenta v moment
vytvoření snímku
6.1.1.4.3 Poznámky
Hlavní funkčnost teto třídy je zapamatování hodnoty agenta pro budoucí ověření
podle nogood listů.
6.1.1.5 Enum SolverResult
Namespace: MWCS
Syntax: public enum SolverResult
6.1.1.5.1 Hodnoty
Tabulka 6.13: Implementace MWCS::SolverResult - Hodnoty
Syntax
Popis
Unknown
Počáteční hodnota
Running
Algoritmus ještě nedoběhl
Solved
Konečný stav – řešení existuje
NotExisted
Konečný stav – řešení ne existuje
59
6.1.2 Implementace prostředí Agent
Ilustrace 11: MWCS class diagram - Agent
Prostředí Agent se zabývá objektovým modelem algoritmu a transformací
uživatelských dat na použitelnou formu. Na ilustraci 11 je zobrazena detailní struktura
tohoto prostředí. V dalších kapitolách popisuji realizaci tříd, jejich atributů a metod a
rovněž podmínky a příklady použítí jednotlivých metod.
6.1.2.1 Enum ContextSide
Namespace: MWCS
Syntax: public enum ContextSide
60
6.1.2.1.1 Hodnoty
Tabulka 6.14: Implementace MWCS::ContextSide - Hodnoty
Syntax
Popis
Left
Levá část řešení
Partial
Částečné řešení
None
Počáteční hodnota
6.1.2.2 Třída Agent
Hierarchie dědičnosti: System.Object → MWCS.Agent.Agent
Thread safety: Ne
Syntax: public class Agent
Tabulka 6.15: Implementace třídy MWCS::Agent::Agent - Konstruktory
Modifikátory
public
Syntax
Agent
(Parameter par,
object initialValue)
Popis
Vytvořit novou instanci agenta
6.1.2.2.2 Atributy
Tabulka 6.16: Implementace třídy MWCS:: Agent::Agent - Atributy
Modifikátory
Syntax
Popis
private
static
uint
lastid
Hodnota, která se používá pro
automatické generování
identifikátoru agenta
private
ContextSide
_side
Stav agenta
private
uint
_priority
Priorita agenta
public
EventHandler
<Events.AgentEventArgs>
PriorityChanged
Událost změny priority agenta
61
Modifikátory
Syntax
Popis
public
EventHandler
ValueChanged
Událost změny hodnoty agenta
public
EventHandler
SizeChanged
Událost změny stavu agenta
public
Parameter
parameter
Parametr agenta
private
object
_value
Hodnota agenta
private
uint
_hash
Tabulka 6.17: Implementace třídy MWCS:: Agent::Agent - Vlastnosti
Modifikátory
Syntax
Popis
public get
internal set
List<Agent>
dependencies
Seznam agentů, na nichž je závislý
běžný agent
public get
internal set
ContextSide
side
Stav agenta
public get
internal set
uint
id
Identifikátor agenta
public get
internal set
uint
priority
Priorita agenta
public get
internal set
object
value
Hodnota agenta
6.1.2.2.4 Metody
Tabulka 6.18: Implementace třídy MWCS:: Agent::Agent - Metody
Modifikátory
Syntax
Popis
internal
void
onPriorityChanged()
Spustit událost změny priority
agenta
internal
void
onValueChanged()
Spustit událost změny hodnoty
agenta
62
Modifikátory
Syntax
Popis
internal
void
onSideChanged()
Spustit událost změny stavu
agenta
public
uint
hash()
public
uint
hash(object value)
Unikátní číslo agenta s novou
hodnotou
6.1.2.2.5 Poznámky
Tato třída zajišťuje transformaci uživatelských dat na formu, se kterou algoritmus může
pracovat.
Generace identifikátoru: this.id = ++Agent.lastid;
Metoda hash() používá metodu uint
ParameterType::agentHash(Agent agent) pro generování unikátního
čísla.
Metoda hash(object value) používá metodu uint
ParameterType::agentHash(Agent agent, object value) pro
generování unikátního čísla.
V případě, že se hodnota, priorita nebo stav agenta změní pomocí vlastností, bude
automaticky spuštěna událost.
6.1.2.2.6 Příklad použítí
Viz. Příklad 6.1.1.2.7.1.
63
6.1.2.3 Třída Parameter
Hierarchie dědičnosti: System.Object → MWCS.Agent.Parameter
Thread safety: Ne
Syntax: public class Parameter
Tabulka 6.19: Implementace třídy MWCS::Agent::Parameter - Konstruktory
Modifikátory
Syntax
public
Parameter
(ParameterType type)
Popis
Vytvořit novou instanci parametru
6.1.2.3.2 Atributy
Tabulka 6.20: Implementace třídy MWCS:: Agent:: Parameter - Atributy
Modifikátory
Syntax
Popis
public
object[]
details
Související uživatelské objekty
public
ParameterType
type
Související typ parametru
6.1.2.3.3 Poznámky
Třída uchovává uživatelské objekty související s aktualním agentem.
6.1.2.3.4 Příklad použítí
Viz. příklad 6.1.1.2.7.1.
64
6.1.2.4 Třída ParameterType
Hierarchie dědičnosti: System.Object → MWCS.Agent.ParameterTyp
Thread safety: Ne
Syntax: public abstract class Agent
Tabulka 6.21: Implementace třídy MWCS::Agent::ParameterType - Konstruktory
Modifikátory
Syntax
Popis
ParameterType
(string name,
IMinConflictSearchAlg alg)
public
Vytvořit novou instanci typu
parametru
6.1.2.4.2 Atributy
Tabulka 6.22: Implementace třídy MWCS:: Agent:: ParameterType - Atributy
Modifikátory
Syntax
Popis
private
static
uint
lastid
Hodnota, která se používá pro
automatické generovaní
identifikátoru
public
string
name
Jméno typu
public
IMinConflictSearchAlg
alg
Algoritmus pro hledání hodnoty
agenta podle běžného typu
parametru
Tabulka 6.23: Implementace třídy MWCS:: Agent:: ParameterType - Vlastnosti
Modifikátory
public get
internal set
Syntax
uint
id
Popis
Identifikátor agenta
65
6.1.2.4.4 Metody
Tabulka 6.24: Implementace třídy MWCS:: Agent:: ParameterType - Metody
Modifikátory
Syntax
Popis
public
uint agentHash
(Agent agent)
Metoda vrací unikátní číslo pro
agenta podle svého parametru
public
uint agentHash
(Agent agent,
object value)
Metoda vrací unikátní číslo pro
agenta podle svého parametru a
nové hodnoty
6.1.2.4.5 Poznámky
Tato třída zajišťuje konektivitu mezi agentem a uživatelským algoritmem pro hledaní
hodnoty a generování unikátního čísla.
Generace identifikátoru: this.id = ++Agent.lastid;
Metoda agentHash() používá metodu uint
ParameterType::agentHash(Agent agent, object value) pro
generování unikátního čísla.
Metoda agentHash(Agent agent, object value)musí byt
implementována v uživatelské aplikaci a musí vrátit hodnotu, která je závislá na hodnotě
parametru agenta a souvisejících uživatelských objektech.
Viz. příklad 6.1.1.2.7.1.
6.1.2.5 Rozhraní IMinConflictSearchAlg
Syntax: public interface IMinConflictSearchAlg
66
6.1.2.5.1 Metody
Tabulka 6.25: Rozrhaní MWCS:: Agent:: IMinConflictSearchAlg - Metody
Syntax
Popis
object
nextValue
(Agent agent,
Context context,
List<ContextNogoodSnapshot> nogood)
Metoda vrací novou hodnotu
agenta, která je v konzistenci s
nogood listem a všemi
uživatelskými omezeními
6.1.2.5.2 Poznámky
Uživatelská aplikace musí implementovat toto rozhraní pro zajištění funkčnosti celého
algoritmu. Přímo ovlivňuje rychlost a efektivitu algoritmu.
Důležité: během hledaní hodnoty by měl algoritmus měnit hodnoty objektů
souvisejících s agentem. Hodnoty lze měnit pouze v delegátu, který zpracovává události
agentů.
Viz. Příklad 6.1.1.2.7.2.
67
6.2 Implementace aplikace plánování
Spustitelná verze aplikace a samotné zdrojové kódy jsou součástí přílohy A na CD.
6.2.1 Datová a business vrstva
V aplikaci bude business vrstva implementovaná jako součást datového modelu a UI
časti.
Datový model (viz. Ilustrace 8) poskytuje všechny metody pro práci s daty a také
ukládaní a načítaní ze souboru.
Data se budou ukládat do souboru v binárním formátu pomocí
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
třídy, kterou poskytuje .NET prostředí.
UI část aplikace reprezentuje GUI a vyvolává metody pro práci s daty (CRUD).
Aplikaci lze rozdělit na dvě části: CRUD data a plánovaní harmonogramu.
GUI aplikace bude vyvíjena pomocí technologie WinForms28.
28 WinForms – název API pro grafické elementy aplikace, které existují jako součást Microsoft .NET
knihovny a poskytují přístup k rozhraní operačního systému Microsoft Windows.
68
6.2.2 GUI – Práce s daty
Všechní další uvedené obrázky jsou součástí přílohy A na CD.
Menu:
•
Soubor
•
Nový – smaže běžná data
•
Načíst data – načítání dat ze souboru
•
Uložit data – uložit data do souboru
•
Zavřít – zavřít aplikaci
•
Plánování – otevřít formulář pro panování harmonogramu
•
Výuka - otevřít formulář pro omezení časových podmínek výuky
69
6.2.2.1 Úvodní obrazovka
Úvodní obrazovka ukazuje seznam existujících předmětů, učeben a vyučujících.
Ilustrace 12: Úvodní obrazovka
TreeView v levé části aplikace obsahuje seznamy všech předmětů, studentů,
vyučujících a učeben. Po kliknutí na název„Unicorn College“ se otevře úvodní obrazovka.
Po kliknutí na název „Předměty/Studenti/Vyučující/Učebny“ se otevře náhled všech
odpovídajících elementů.
Nahoře v pravé častí aplikace je umístěn navigační bar a dvě tlačítka „Předchozí
strana“ a „Následující strana“.
Zelené tlačítko plus otevře formulář pro přidání nového elementu.
Tlačítko „Oko“ otevře náhled vybraných elementů.
Tlačítko „Koš“ smaže vybrané elementy.
70
6.2.2.2 Časová omezení
Ilustrace 13: Časová omezení
Tato obrazovka obsahuje metody pro úpravu časových intervalů.
Dole je zobrazen seznam všech existujících intervalů. Každý interval obsahuje další
informace: priorita, začátek, konec a typ (akce) intervalu. Interval s vyšší prioritou má vyšší
sílu. Akce může být pouze dvou druhů: „Povolit“ a „Zakázat“
71
6.2.2.3 Náhled předmětů
Ilustrace 14: Náhled předmětů
V pravém listu je seznam vybraných předmětu pro tento náhled, v tomto seznamu
můžeme také vybrat nějaké předměty a otevřít náhled v jiné obrazovce.
Levý list obsahuje seznam „skupiny událostí“ - přednášky, semináře. Lze přidat nové
skupiny jako „zkouška“ apod.
Uprostřed je seznam studentů, kteří si zapsali tento předmět.
Tlačítko
nastaví všechny vybrané elementy (studenty) pro všechny předměty,
pro něž je vytvořena běžná obrazovka.
Pomocí této obrazovky lze rozdělit předmět na jednotlivé skupiny. Každá skupina bude
vytvořena jako nový předmět.
72
6.2.2.4 Náhled skupiny událostí
Ilustrace 15: Náhled skupiny událostí
V listu, který se nachází dole, je seznam běžně vybraných skupin.
V pravé časti je seznam vyučujících, kteří mohou učit tento předmět. V levé části
obrazovky je seznam událostí, které jsou součástí této skupiny a předmětů.
73
6.2.2.5 Náhled událostí
Ilustrace 16: Náhled událostí
V listu, který se nachází dole, je seznam běžně vybraných událostí.
Nahoře je seznam událostí, na kterých jsou závislé běžně vybrané události.
Vpravo se nachází seznam učeben, kde mohou probíhat běžně vybrané události.
74
6.2.2.6 Náhled studentů
Ilustrace 17: Náhled studentů
Obrazovka obsahuje jen dva seznamy: seznam zapsaných předmětů a seznam běžně
vybraných studentů. Lze změnit jméno studenta a přidat nebo smazat zapsané předměty.
75
6.2.2.7 Náhled místností
Ilustrace 18: Náhled místností
V pravém listu se nachází seznam vybraných učeben.
Levý list obsahuje seznam všech událostí, které mohou probíhat ve vybraných
učebnách.
Nastavení které místností jsou počítačové a které předměty potřebují počítači je
implementováno tím, že uživatel mel by ručně nastaví odpovídající učebnu pro
předmět(až pro každou událost, která je součástí předmětů, zvlášť)
76
6.2.2.8 Náhled vyučujících
Ilustrace 19: Náhled vyučujících
V pravém listu se nachází seznam vybraných vyučujících.
Levý list obsahuje seznam všech skupin událostí, které mohou učit vybraní vyučující.
77
6.2.3 GUI – Plánování harmonogramu
Menu:
•
Spustit
◦ Všechny události - lze spustit plánování pro všechny události
◦ Pouze změněné události – lze spustit plánování jen pro události, které nejsou
zafixované (když událost je zafixovaná, v pravoúhelníku, který reprezentuje tuto
událost, je slovo „definováno“:
).
•
Zastavit – zastavit běžný propočet
•
Aktualizovat – aktualizovat náhled (během výpočtu). Náhled se automaticky
aktualizuje každých 20 sekund.
•
Zavřít – zastavit výpočet a zavřít plánovací obrazovku. Otevřít obrazovku pro
úpravu dat.
78
6.2.3.1 Plánování
Ilustrace 20: Plánování
Jednotlivé pravoúhelníky reprezentují události. Barva pravoúhelníků reprezentuje
předmět. Pokud přesunete kurzor myši na pravoúhelník, zobrazí se parametry události:
předmět, skupina událostí, místnost, vyučující a časový interval.
Dole je zobrazena informace pro běžné propočítání: číslo iterace, trvání vypočtu,
množství nogood snímků, počet agentů.
Pokud kliknete pravým tlačítkem myši na událost, můžete změnit stav události na
„nezafixovaný“.
Pokud kliknete levým tlačítkem myši na událost, můžete otevřít nastavení časového
intervalu pro vyučujícího, který je naplánovaný pro tuto událost.
79
6.2.4 Min-conflict search algoritmy a výsledky plánování
V rámci aplikace byly naprogramovány tři min-conflict search algoritmy pro každý typ
parametru. Největší algoritmus byl vytvořen pro parametry „událost-čas“ a musel
uvažovat všechny parametry událostí. Další algoritmy pro parametry „událost-místnost“ a
„událost-vyučující“ uvažovaly jen čas a hodnotu odpovídající parametru.
Pro zpracovávaní dat udělal jsem sledující optimalizace:
•
Vytvořil jsem novou třídu pro uchováváni času a práce s časem – čas je nějaké cele
číslo. Jednotka času se rovna 45 minutám reálného času
•
Plánování se provádí v jednotlivých týdnech, v sledujících týdnech min-conflict
search algoritmus se snaží použít hodnotu z předchozího týdnu, když to není
možná, snaží se definovat novou hodnotu
•
Před otevřením formy pro plánovaní, po načítaní a před ukládáním dat se provádí
validace dat. Během validace, datový model ověřuje všechny data na souvislost,
např., že když u vyučujícího je naplánovaná nějaká událost, teto událost musí mít
taky naplánovaného stejného vyučujícího. Potřeboval jsem teto operace, abych ne
došlo k chybám během vývoje a testovaní aplikace.
•
Pro zpracování jednotlivého týdnu, plánovací aplikace používa jen takové událostí,
která musejí byt naplánování v tomto týdnu a seznam dostupných učeben a
vyučujících nemusí byt prázdny.
Pro testování aplikace jsem získal data o studentech a předmětech od Unicorn College.
Na začátku byla data filtrována následujícím způsobem: vymazány všechny předměty, u
nichž byl počet studentů nižší pěti. Dál byli vymazáni studenti, kteří si zapsali více než 12
předmětů, což bylo nutné pro víceméně rychlé propočítání harmonogramu. Pro každý
předmět pak byli náhodně přirazeni vyučující s učebnami. Součástí omezujících podmínek
výuky bylo vytvoření časových intervalů pro každý pracovní den v semestru.
80
Data:
•
60 časových intervalů
•
6 učeben
•
51 předmětů
•
56 skupin událostí
•
656 událostí
•
68 vyučujících
•
297 studentů
•
1426800 spojení mezi studenty a událostmi
•
1312 spojení mezi událostmi a vyučujícími
•
1320 spojení mezi událostmi a učebnami
Propočítání testovacích dat (je součástí přílohy) na počítači Intel Core i5, 2.30GHz
probíhá 17 sekund, což je velmi dobrý výsledek.
Řešení lze rozšířit o další omezující podmínky jako: „max. počet událostí během
jednoho dne je X pro vyučujícího/studenta“, „každý student nemusí mít volný čas mezi
naplavovanými událostmi (podmínka spíše pro základní školu)“, „student může mít max. X
konfliktů v harmonogramu“ atd.
Existuje jedná nepříjemná záležitost – když řešení pro běžná data neexistuje,
algoritmus to ukaže, ale před tím musí ověřit všechny kombinace dat, což trvá velmi
dlouho (pro data, která mají velikost přibližně jako ty testovací, to může trvat až dny).
81
7. Závěr
Předmětem této bakalářské bylo provést analýzu problematiky automatického
plánování, navrhnout a implementovat knihovnu a plánovací aplikaci.
V rámci této práce vznikla MWCS knihovna, která řeší problematiku automatického
plánování a obsahuje detailní dokumentaci. Knihovna je implementovaná na základě
Weak-commitment search algoritmu s prioritními agenty. Práce obsahuje popis
požadavků, návrh a implementaci aplikace, která řeší úkol automatického plánování
harmonogramu předmětů univerzity. Součástí implementace je daná dokumentace
knihovny a příklady použíti. Taky, součástí přílohy A naleznete aplikace N-Queens, která je
dobrým příkladem použíti knihovny a je dobré komentována.
Aplikace vhodně podporuje proces vytváření bezkonfliktního harmonogramu s
omezením dat. Vytvořená aplikace může usnadnit prací studijního oddělení, které se
zabývá problémem plánování rozvrhu předmětu. Aplikace v budoucnu lze rozšířit pro
podporu nových typu podmínek, jako např.: „student, který si zapsal vice než 12
předmětů, muže obsahovat max. 2 konflikty v harmonogramu“.
Tato bakalářská práce je z teoretického hlediska přínosná především kvůli analýze
složité problematiky a pokusu o její řešení.
V rámci bakalářské práce došlo k naplnění všech stanovených cílů a požadavků, které
na ni byly kladené, a proto tuto práci považuji za úspěšnou.
82
8. Conclusion
The subject of this bachelor thesis was to analyze the automated planning problem,
design and implement a library and planning solution.
As a result of this work MWCS library that solves automated planning problem was
created, detailed documentation about library included. The library is implemented based
on the Weak-commitment search algorithm with priority agents. This work describes the
requirements, design and implementation of automated scheduling problem for
university. The implementation of a given library contains complete documentation and
program examples. Also, you can found application “N-Queens” in an attachments of this
work, which represents example of use MWCS library and it is good commented
Application appropriately supports the process of creating a conflict-free schedule
with a lot of data constraints. Created application can reduce study department the work
that deals with scheduling problem. Applications can be expanded in the future to
support new types of constraints such as "student who learns more than 12 subjects may
contains a maximum of two conflicts in the his schedule.
Theoretical aspect of this thesis is mainly beneficial, because it analyses the
automated planning problem and attempts to solve it.
I consider my bachelor thesis successful as it accomplished all assigned goals.
83
9. Seznam použitých zdrojů
Burke, Edmund Kieran & Petrovic, Sanja, 2002. "Recent research directions in
automated timetabling," European Journal of Operational Research,
Elsevier, vol. 140(2), pages 266-280, July.
De Werra, D., 1985. „An introduction to timetabling“, European Journal of
Operational Research, Elsevier, vol. 19(2), pages 151-162, February.
Chien S. and Rabideau G., 2000, ASPEN - Automated Planning and Scheduling for
Space Mission Operations
Ezequiel Q. Ángel G.-Olaya D. Borrajo F., 2011, “Control of Autonomous Mobile
Robots with Automated Planning“, „JOURNAL OF PHYSICAL AGENTS“, vol. 5,
no. 1, january
GERŠLOVÁ a kol. Zpráva Akreditační komise o hodnocení Unicorn College s.r.o.
Praha [online] vyd. listopad 2010 dostupné z URL:
http://www.akreditacnikomise.cz/attachments/article/252/CZ_hodnoceni_
unicorn_college_2010.pdf
Ghallab, Malik; Nau, Dana S.; Traverso, Paolo (2004), Automated Planning: Theory
and Practice, Morgan Kaufmann, ISBN 1-55860-856-7
Makoto Yokoo, 1995, „Asynchronous Weak-commitment Search for Solving
Distributed Constraint Satisfaction Problems“, International Conference on
Principles and Practice of Constraint Programming, pages 88-102
Menkes, H..: INTEGER PROGRAMMING APPROACHES FOR AUTOMATED PLANNING
[online]. Arizona , 2008. Dissertation. ARIZONA STATE UNIVERSITY
Müller T.: Constraint-based Timetabling. Prague, 2005. Ph.D. Thesis. Charles
University in Prague Faculty of Mathematics and Physics, page 4
Rodriguez, C.; Villagra, M.; Baran, B. (2007). "Asynchronous team algorithms for
Boolean Satisfiability". 2007 2nd Bio-Inspired Models of Network,
Information and Computing Systems. doi:10.1109/BIMNICS.2007.4610083
84
Roie Zivan and Amnon Meisels, 2006 ,„Message delay and Asynchronous DisCSP
search“
Schaerf A., 1999, „A Survey of Automated Timetabling“, ARTIFICIAL INTELLIGENCE
REVIEW, vol. 13(2), pages 87-127
85
10.Seznam obrázků
Ilustrace 1: Weak-commetment search algortihm................................................................22
Ilustrace 2: Procedures for receiving messages (AWC).......................................................24
Ilustrace 3: Příklad běhu AWC algoritmu............................................................................25
Ilustrace 4: Algoritmus Weak-Commitment Search s prioritními agenty............................29
Ilustrace 5: Use-case diagram - MWCS knihovna...............................................................34
Ilustrace 6: MWCS domain model.......................................................................................35
Ilustrace 7: Sekvenční diagram použíti knihovny................................................................37
Ilustrace 8: Datová vrstva aplikace......................................................................................42
Ilustrace 9: MWCS class diagram........................................................................................48
Ilustrace 10: MWCS class diagram - Solver........................................................................49
Ilustrace 11: MWCS class diagram - Agent.........................................................................59
Ilustrace 12: Úvodní obrazovka...........................................................................................69
Ilustrace 13: Časová omezení...............................................................................................70
Ilustrace 14: Náhled předmětů.............................................................................................71
Ilustrace 15: Náhled skupiny událostí..................................................................................72
Ilustrace 16: Náhled událostí................................................................................................73
Ilustrace 17: Náhled studentů...............................................................................................74
Ilustrace 18: Náhled místností..............................................................................................75
Ilustrace 19: Náhled vyučujících..........................................................................................76
Ilustrace 20: Plánování.........................................................................................................78
86
11.Seznam tabulek
Tabulka 4.1: Požadované množství cyklů pro n-queens problém........................................27
Tabulka 4.2: Požadované množství cyklů pro problém barvení grafu.................................27
Tabulka 4.3: Požadované množství cyklů pro network resource allocation problém..........27
Tabulka 5.1: Použité pojmy v navrhu řešení........................................................................28
Tabulka 5.2: Porovnání optimalizací (jeden seznam)...........................................................32
Tabulka 5.3: Porovnání optimalizace (dva seznamy)...........................................................33
Tabulka 5.4: Popis use-case knihovny MWCS....................................................................34
Tabulka 5.5: MWCS domain model - popis.........................................................................36
Tabulka 5.6: Třída MWCS::Solver - Atributy......................................................................37
Tabulka 5.7: Třída MWCS::Solver - Metody.......................................................................37
Tabulka 5.8: Třída MWCS::Context - Atributy....................................................................38
Tabulka 5.9: Třída MWCS::Context - Metody.....................................................................38
Tabulka 5.10: Třída MWCS::ContextNogoodSnapshot - Atributy......................................38
Tabulka 5.11: Třída MWCS::ContextNogoodSnapshot - Metody.......................................39
Tabulka 5.12: Třída MWCS::AgentNogood - Atributy........................................................39
Tabulka 5.13: Třída MWCS::AgentNogood - Metody.........................................................39
Tabulka 5.14: Třída MWCS::Agent::Agent - Metody.........................................................39
Tabulka 5.15: Třída MWCS::Agent::Agent - Atributy.........................................................40
Tabulka 5.16: Třída MWCS::Agent::Parameter - Atributy..................................................40
Tabulka 5.17: Třída MWCS::Agent::Parameter - Metody...................................................40
Tabulka 5.18: Třída MWCS::Agent::Events::AgentEventArgs - Atributy..........................40
Tabulka 5.19: Třída MWCS::Agent::Events::AgentEventArgs - Metody...........................41
Tabulka 5.20: Třída MWCS::Agent::ParameterType - Atributy..........................................41
Tabulka 5.21: Třída MWCS::Agent:: ParameterType - Metody..........................................41
Tabulka 5.22: Třída MWCS::Agent::IMinConflictSearchAlg - Metody.............................41
Tabulka 6.1: Implementace třídy MWCS::Solver - Konstruktory.......................................50
Tabulka 6.2: Implementace třídy MWCS::Solver - Atributy...............................................50
Tabulka 6.3: Implementace třídy MWCS::Solver - Vlastnosti............................................50
Tabulka 6.4: Implementace třídy MWCS::Solver - Metody................................................50
Tabulka 6.5: Implementace třídy MWCS::Context - Konstruktory.....................................53
Tabulka 6.6: Implementace třídy MWCS::Context - Atributy.............................................53
Tabulka 6.7: Implementace třídy MWCS::Context - Vlastnosti..........................................53
Tabulka 6.8: Implementace třídy MWCS::Context - Metody..............................................54
Tabulka 6.9: Implementace třídy MWCS::ContextNogoodSnapshot - Konstruktory.........57
Tabulka 6.10: Implementace třídy MWCS:: ContextNogoodSnapshot - Atributy..............57
Tabulka 6.11: Implementace třídy MWCS::Agent::AgentNogood - Konstruktory.............57
Tabulka 6.12: Implementace třídy MWCS:: Agent::AgentNogood - Vlastnosti.................58
Tabulka 6.13: Implementace MWCS::SolverResult - Hodnoty...........................................58
Tabulka 6.14: Implementace MWCS::ContextSide - Hodnoty............................................60
Tabulka 6.15: Implementace třídy MWCS::Agent::Agent - Konstruktory..........................60
Tabulka 6.16: Implementace třídy MWCS:: Agent::Agent - Atributy.................................60
Tabulka 6.17: Implementace třídy MWCS:: Agent::Agent - Vlastnosti..............................61
Tabulka 6.18: Implementace třídy MWCS:: Agent::Agent - Metody..................................61
Tabulka 6.19: Implementace třídy MWCS::Agent::Parameter - Konstruktory....................63
Tabulka 6.20: Implementace třídy MWCS:: Agent:: Parameter - Atributy..........................63
87
Tabulka 6.21: Implementace třídy MWCS::Agent::ParameterType - Konstruktory............64
Tabulka 6.22: Implementace třídy MWCS:: Agent:: ParameterType - Atributy..................64
Tabulka 6.23: Implementace třídy MWCS:: Agent:: ParameterType - Vlastnosti...............64
Tabulka 6.24: Implementace třídy MWCS:: Agent:: ParameterType - Metody...................65
Tabulka 6.25: Rozrhaní MWCS:: Agent:: IMinConflictSearchAlg - Metody.....................66
88
12.Seznam příloh
A) Přiložené CD obsahující text práce, MWCS knihovnu, plánovací aplikace
UUScheduling, testovací aplikace NQueens, diagramy navrchu a obrázky UI
aplikace a testovací data.
89
13.Příloha A: obsah přiloženého CD
Obsah CD je organizován do následujících složek:
•
Bakalářská práce – Obsahuje samotnou bakalářskou práci
•
MWCS knihovna - Obsahuje dll soubor knihovny
•
UUScheduling – Obsahuje spustitelnou plánovací aplikaci
•
N-Queens – Testovací aplikace, jako příklad použíti knihovny
•
Zdrojové kódy – Součástí CD je Microsoft Visual Studio 2012 projekt který obsahuje
zdrojové kódy knihovny, plánovací aplikace a aplikace N-Queens
•
Obrázky – diagramy a obrázky UI
•
„Unicorn College.sd“ - testovací data pro plánovací aplikace

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Transkript

Podobné dokumenty

zde

Vývoj e-‐shopu na redakčním systému WordPress