Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze
Martin Skatula
Vývoj fakturační softwarové aplikace pro obchodníka s elektřinou Bakalářská práce
2010
Zadávací list
Prohlášení: Prohlašuji, že jsem bakalářskou práci na téma Vývoj fakturační softwarové aplikace pro obchodníka s elektřinou zpracoval samostatně a použil pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 20. 12. 2010 ………..………………………………. Podpis studenta
Poděkování Děkuji svému vedoucímu bakalářské práce RNDr. Juliu Janovskému za pomoc při tvorbě této práce.
Anotace Cílem této bakalářské práce je zpracování průběhu návrhu, implementace a testování nové funkce do stávající fakturační aplikace. Práce obsahuje postup, který je znázorněn na ukázkovém příkladu změny data splatnosti faktury. V teoretické části jsou popsány rigorózní a agilní metodiky vývoje softwaru. Praktickou část tvoří základní popis aplikace a postup zpracování změny aplikace včetně zdrojového kódu. Výsledkem práce je funkční změna aplikace ve výpočtu data splatnosti. Annotation The aim of this bachelors work is to work up the process of the design, implementation and testing of the new function into already existing invoicing application. The work consists of the procedure which is demonstrated on the example of maturity date change of the invoice. Rigorous and agile methods of software development are described in the theoretical part. The practical part consists of the basic description of application and the procedure of processing the change of this application including the source code. The outcome of this work is the functional change of application in the way how the application calculates the maturity date of the invoice.
Obsah
1. Úvod .................................................................................................................................... 8 Teoretická část ........................................................................................................................................ 9
2. Softwarový proces ............................................................................................................ 10 2.1.
Modely softwarového procesu ..................................................................................... 10
2.1.1.
Vodopádový model.................................................................................................... 10
2.1.1.1.
Roycův konečný model .......................................................................................... 11
2.1.1.2.
Sašimi model .......................................................................................................... 13
2.1.2.
Rational Unified Process............................................................................................ 13
2.1.3.
Extrémní programování............................................................................................. 16
2.1.4.
Feature driven development..................................................................................... 19
Společnost ALPIQ ENERGY SE................................................................................................................ 22
3. O systému ......................................................................................................................... 23 3.1.
Invoicing Client .............................................................................................................. 23
3.1.1.
Definice pojmů........................................................................................................... 23
3.1.2.
Základní datový model .............................................................................................. 24
3.1.2.1.
Tabulka C_Customer .............................................................................................. 24
3.1.2.2.
Tabulka CO_Contract ............................................................................................. 25
3.1.2.3.
Tabulka IGH_InvoicingGroupHeader ..................................................................... 26
3.1.3.
Datový model fakturace ............................................................................................ 27
3.1.3.1.
Fakturace velkoobchodu (wholesale) .................................................................... 28
3.1.3.2.
Fakturace maloobchodu (Retail)............................................................................ 30
Praktická část......................................................................................................................................... 31
4. Specifikace požadavků ...................................................................................................... 32 4.1. 4.1.1.
Zadání ............................................................................................................................ 32 Funkcionalita.............................................................................................................. 32
5. Analýza .............................................................................................................................. 33 5.1.
Analýza současného stavu............................................................................................. 33
5.1.1.
Datový model............................................................................................................. 33
5.1.2.
Výpočet data splatnosti ............................................................................................. 33
5.2.
Analýza zadání............................................................................................................... 34
6. Návrh řešení...................................................................................................................... 35 6.1.
Návrh realizace.............................................................................................................. 35 6
6.1.1.
Definice parametrů.................................................................................................... 35
6.1.2.
Příklad ........................................................................................................................ 36
6.1.3.
Technický postup ....................................................................................................... 36
6.1.3.1.
Datový model......................................................................................................... 37
6.1.3.2.
Pravidla výpočtu..................................................................................................... 37
6.1.3.2.1.
Pohyblivý ............................................................................................................ 37
6.1.3.2.2.
Fixní (FixedDueDate) .......................................................................................... 38
6.2.
Schválení návrhu ........................................................................................................... 38
7. Implementace ................................................................................................................... 39 7.1.
Datová vrstva................................................................................................................. 39
7.1.1.
Tabulky....................................................................................................................... 39
7.1.2.
Uložené procedury .................................................................................................... 40
7.2.
Aplikační vrstva ............................................................................................................. 42
7.2.1.
Kódování .................................................................................................................... 43
7.2.1.1.
Konstruktor ............................................................................................................ 43
7.2.1.2.
Metody................................................................................................................... 43
8. Testování........................................................................................................................... 47 8.1.
Příprava testovacího serveru ........................................................................................ 47
8.1.1.
Přenos databáze ........................................................................................................ 47
8.1.2.
Přenos změn .............................................................................................................. 47
8.1.3.
Naplnění nově vytvořených tabulek.......................................................................... 47
8.2. 8.2.1. 8.3.
NUnit (regresní) testy.................................................................................................... 48 Výsledky regresních testů.......................................................................................... 49 Akceptační testy ............................................................................................................ 50
9. Produkční verze................................................................................................................. 51 9.1.
Přenos databáze............................................................................................................ 51
9.2.
Instalace ........................................................................................................................ 51
9.3.
Dokumentace ................................................................................................................ 51
9.4.
Předání aplikace ............................................................................................................ 51
10.
Závěr.............................................................................................................................. 52
11.
Seznam použitých zdrojů .............................................................................................. 53
12.
Seznam použitých zkratek............................................................................................. 54
7
1. Úvod Hlavním cílem bakalářské práce Vývoj fakturační softwarové aplikace pro obchodníka s elektřinou je zpracovaní řešení změny fakturační aplikace společnosti ALPIQ ENERGY SE, aby vyhovovalo zadaným požadavkům. Práce obsahuje tři části. První část – teoretická, se zaměřuje na čtyři zástupce metodik vývoje tak, jak byla svými tvůrci popsána. Každé z těchto metod je věnována samostatná kapitola. Druhá část se věnuje přestavení společnosti ALPIQ ENERGY SE a základním popisu fakturační aplikace. Třetí část – praktická, se zabývá samotným vývojem změny v aplikaci. Popisuje reálné řešení problému v šesti kapitolách, kde je čtenář seznámen se zadáním, návrhem, implementací a testováním provedených změn. Pro splnění cíle bylo nutné využít poznatků z objektově orientovaného programování a ze znalostí jazyka SQL.
8
Část I Teoretická část
9
2. Softwarový proces Softwarovým procesem rozumíme po částech uspořádanou množinu kroků směřujících k vytvoření nebo úpravě softwarového díla.
2.1.
Modely softwarového procesu
Za desítky let vývoje softwarových systémů se objevila celá řada modelů určujících, jak by měl takový softwarový proces vypadat. Dodnes však neexistuje detailně a přesně definovaná podoba softwarového procesu, který by mohl být přijat jako referenční. Přesto lze konstatovat, že základem téměř všech modelů se stal tzv. vodopádový model, který je možno v různých modifikacích a rozšíření nalézt ve většině současných přístupů. [1, s. 8‐9]
2.1.1.
Vodopádový model
Jako první tento model představil Winston W. Royce (1925‐1995); paradoxně se však jednalo o příklad chybného vývojového modelu. Původně chtěl představit dokonalejší iterační model a poukázat na chyby vodopádu. Vodopádový model se tak stal jedním ze základních modelů používaných pro vývoj softwaru, který využívá přímý postup bez možnosti vracet se, modifikovat předchozí části nebo nechávat tyto části otevřené pro pozdější doplnění. Winston W. Royce popsal životní cyklus softwarového díla jako sedm oddělených, samostatných, na sebe navazujících částí, viz obrázek 2.1.1‐1.
Obrázek 2.1.1‐1: Vodopádový model
10
Základní části modelu jsou: systémové a softwarové požadavky, analýza a návrh softwarového systému, implementace a testování včetně udržování vytvořeného produktu. Princip vodopádu spočívá v návaznosti činností, které mohou započít až po skončení činnosti předchozí. Znamená to tedy, že uzavřenou část nelze později modifikovat a není ani umožněna práce na dvou částech najednou. [2, s. 1‐2] Existuje zjednodušená forma modelu, která rozděluje cyklus na čtyři základní fáze, viz obrázek 2.1.1‐2. Nejčastěji se tato forma využívá u menších projektů, kde nemá význam oddělovat specifikaci od analýzy.
Obrázek 2.1.1‐2: Vodopádový model
Hlavní podstata vodopádového modelu spočívá především v jeho jednoduchosti. Po prvotním seznámení se s obrázkem a pochopením jeho základních vlastností, je ihned pochopena jeho funkčnost, která funguje i v jeho použití. Proto je vodopád často používán jako základní model k vysvětlování problému metodik. Z důvodu chybějící zpětné vazby s sebou model přináší řadu nedostatků, kterými jsou zejména: • Dlouhá prodleva mezi zadáním projektu a vytvořením spustitelné verze systému. • Výsledek je závislý na úplnosti a přesnosti zadání požadavků na výsledný produkt. • Před dokončením výsledného softwarového systému nelze odhalit kvalitu produktu. [1, s. 9‐10] Odstranění těchto zásadních nedostatků vedlo ke vzniku mnoha modifikací základního vodopádového modelu. Takovou modifikací je například původní Royceův iterační model. [3]
2.1.1.1. Roycův konečný model Winston W. Royce ve své modifikaci usiluje o zavedení neexistující zpětné vazby mezi jednotlivými fázemi, viz obrázek 2.1.1.1‐1. Dále zavádí zpětnou vazbu z návrhu do požadavků na software a z testování do návrhu, které jsou znázorněné na obrázku 2.1.1.1‐2. Zdůvodněním je jednoduchost obou fází a minimální dopad na zbylé fáze. [2, s. 2‐3]
11
Obrázek 2.1.1.1‐1: Zpětná vazba v Royceově modelu 1
Obrázek 2.1.1.1‐2: Zpětná vazba v Royceově modelu 2
12
2.1.1.2. Sašimi model Další modifikaci vodopádového modelu zastupuje sašimi model přestavený Peterem DeGracem. Podstata spočívá v překrývání jednotlivých fází, viz obrázek 2.1.1.2‐1. Na rozdíl od původního modelu, který vyžaduje ukončování fází před započetím nové fáze, sašimi modifikace striktně ruší oddělování fází. Tak například fáze návrhu a implementace se mohou překrývat, takže implementační problémy mohou být objeveny během fáze návrhu, jakož i během fáze implementace vývojového procesu. Velikost překrytí není v šasimi modelu definována. Může tedy nastat situace, kdy bude souběžně probíhat více fází, nebo, v případě malého překrytí, se může model blížit původnímu vodopádu, kdy současně probíhá pouze jedna fáze. Nevýhodou sašimi modifikace je vytváření méně zřetelných hranic mezi jednotlivými fázemi a neschopnost určení fáze, ve které se projekt právě nachází. [3]
Obrázek 2.1.1.2‐1: Překrývání v sašimi modelu
2.1.2.
Rational Unified Process
Proces Rational Unified Process (RUP) je rigorózní metodika vývoje softwaru, která vznikla spoluprací řady velkých firem se společností Rational. Proces RUP definuje přístup k přiřazování úkolů a zodpovědnosti v organizacích zabývajících se vývojem softwaru. Jeho cílem je zajištění vysoké kvality vytvořeného produktu v daném časovém rozsahu a zadaném rozpočtu. Metodika klade největší důraz na iterační vývojový cyklus, vizuální modelování a častou komunikaci se zákazníkem. Základní princip spočívá v dodržení sady těchto šesti bodů používaných při vývoji softwaru: • Iterativní vývoj softwaru (Develop Software Iteratively) Pokud se týká rozsáhlého softwarového produktu, není v současné době možné nejprve celý problém nejprve přesně definovat, poté navrhnout jeho řešení, následně veškeré zadání implementovat a na závěr vše otestovat a nasadit. Jediným možným řešením je tak přistupovat k jednotlivým problémům v iteracích. To spočívá v rozdělení celého projektu na čtyři fáze, z nichž se každá skládá z několika iterací podobných klasickému vodopádovému modelu, viz obrázek 2.1.2‐1. Výsledkem každé iterace je spustitelný software. [1, s. 10‐11] 13
Obrázek 2.1.2‐1: Iterativní vývoj softwaru
•
•
•
•
•
V rámci každé iterace probíhají činnosti vázané na byznys modelování, následují specifikace požadavků, analýza a návrh, implementace, testování a nasazení (instalace). Snadná správa požadavků (Manage Requirements) U vodopádového přístupu se nepřipouští změna požadavků v průběhu projektu. Naproti tomu RUP jasně definuje koncepci, která spočívá ve stálém kontaktu zadavatele s vývojovým týmem, umožňující průběžné úpravy požadavků v projektu. Využití existujících komponent (Use Component‐Based Architectures) RUP stanovuje systematický přístup k definování architektury systému s použitím nových a existujících komponent. Komponentou se v tomto kontextu označují netriviální části systému zajišťující funkcionalitu. Projekt tak lze snáze rozdělit mezi několik vývojářských týmů a umožňuje postupnou tvorbu systému. Rational Unified Process podporuje standardní komponentové infrastruktury COM a CORBA. Důraz na vizualizaci vyvíjeného softwaru (Visually Model Software) Moderní nástroje poskytují vhodné grafické znázornění systému, které zpřehledňují návrh a udržují tak konzistenci mezi modelem a vlastní implementací. Základem pro vizualizaci modelů je jazyk UML. Průběžné testování produktu (Verify Software Quality). Pro zajištění požadované kvality jsou v RUP kladeny velké nároky na spolehlivost, funkčnost a výkon aplikace. Nástrojem k dodržení těchto kritérií je průběžné testování. Testování tak stojí v hlavní linii vývoje produktu, které je realizováno speciální skupinou. Snadné řízení změn (Control Changes to Software) Možnost provádění změn v pozdějších fázích vývoje s sebou přináší řadu problémů v řízení a dokumentaci projektu. RUP těmto problémům předchází pomocí verzování softwaru. Jedná se o vytvoření složky (repozitáře), do které každý programátor zaznamenává a současně zdokumentovává každou změnu ve zdrojovém kódu. Výsledkem je velmi kvalitní a podrobný popis iterací vývoje aplikace se snadným zpětným vrácením změn. [4, s. 3‐4]
Proces tak lze popsat ve dvou dimenzích, které odpovídají osám na obrázku.
14
Obrázek 2.1.2‐2: Fáze a disciplíny RUP
„Horizontální osa představuje dynamický pohled na proces, který je vyjádřen pomocí cyklů, fází, iterací a milníků. Vertikální osa reprezentuje statické hledisko procesu, popis činností, artefaktů, pracovníků a pracovních postupů. Na obrázku je na vertikální ose znázorněno 9 tzv. disciplín, které představují logické seskupení činností. Graf ukazuje podíl jednotlivých disciplín v různých fázích projektu.“ [5, s. 122] Životní cyklus softwaru je rozdělen na cykly, přičemž předmětem každého cyklu je nová verze produktu. Cyklus lze v RUP rozdělit do čtyř po sobě jdoucích fází, z nichž každá je zakončena tzv. milníkem. Po dokončení každé fáze se posuzuje, zda byly splněny požadované cíle. Další postup projektu je možné zahájit pouze v případě splnění všech požadovaných kritérií kladených na tu kterou jednotlivou fázi. Průběh jednotlivých fází je následující: • Zahajovací fáze (Inception) Během této fáze se vymezí projekt, na jehož základě se definují cíle a způsob, kterým bude celý systém vyvíjen a implementován. • Elaborační fáze (Elaboration) Fáze věnovaná podrobné definici architektury systému, specifikaci požadavků, stručného plánu iterací a definici komponent, které je třeba vyvinout pro opakované použití. • Konstrukční fáze (Construction) Předposlední fáze je zaměřena na dokončení návrhu, realizace a testování první funkční verze systému. • Fáze nasazení (transition) Hlavním účelem této fáze je zajištění finální verze systému koncovým uživatelům. V jejím průběhu se provádí beta testování, zapracovávají se drobné úpravy na základě připomínek uživatelů a dokončují se úpravy odložených funkcí. Součástí je i školení uživatelů, předání dokumentace a vytvoření podpory systému. V této fázi by již nemělo docházet k žádným zásadním změnám funkcionality softwaru. Připomínky 15
zadavatele by se měly týkat pouze instalace, konfigurace a odlaďování drobných chyb zjištěných při testovacím provozu. [4, s. 5‐9] V průběhu všech fázi projektu probíhají opakovaně následující disciplíny: • Byznys modelování (Business modeling) Zahrnuje tvorbu podnikového modelu a podnikových procesů. • Specifikace požadavků (Requirements) Úspěch projektu závisí na splnění požadavků (kritérií). Je proto třeba požadavky evidovat a dokumentovat pro případné změny. • Analýza a návrh (Analysis & Design) Disciplína, která definuje architekturu systému včetně členění komponent. • Implementace (Implementation) Úkolem implementace je převést návrh modelu do spustitelné podoby, tj. vytvoření komponent a spustitelného programu. • Testování (Test) Slouží k ověření funkčnosti implementovaných komponent. • Nasazení (Deployment) Disciplína pro předání softwaru koncovým uživatelům. • Řízení změn a konfigurací (Configuration and Change Management) Disciplína sloužící pro řízení verzování softwaru a koordinaci implementace změn. • Projektové řízení (Project Management) Pro plánování a koordinaci prací na projektu slouží projektové řízení. Současně tato disciplína zajišťuje potřebné personální a materiální zdroje. • Prostředí (Environment) Disciplína pro stanovení pravidel jednotlivých činností a příslušných nástrojů. [5, s. 121‐123]
2.1.3.
Extrémní programování
Mezi nejznámější a nejpoužívanější zástupce agilní 1 metodiky vývoje softwaru patří Extrémní programování (XP). Vytvořila ji skupina odborníků okolo Kenta Becka v roce 1996. XP předepisuje všem účastníkům vývoje činnosti, vycházející z běžných principů a postupů vývoje softwaru, které jsou dovedeny do extrémů. Metoda je založena na velmi krátkých iteracích, jež jsou zachyceny na obrázku 2.1.3‐1 a dále popsány. [6, s. 10‐13] Základní aktivity XP jsou velmi podobné předešlým popsaným modelům. Patří mezi ně: • plánování, • návrh, • programování, • testování.
1
Metodiky, které umožňují vytvořit řešení velmi rychle a pružně je přizpůsobovat měnícím se požadavkům.
16
Obrázek 2.1.3‐1: Praktiky XP
XP zavádí 13 základních a jednoduchých postupů. • Tým jako celek (Whole Team) Zákazník je základem týmu složeného z manažerů, programátorů a testerů, který stanovuje základní specifikace projektu. • Plánovací hra (Planning Game) Plánování v XP je dialog mezi manažery a programátory, při němž se řeší tyto okruhy problémů: zadání požadavků zákazníka, určení priorit jednotlivých požadavků a určení důležitých termínů. Každý požadavek se definuje jako tzv. uživatelský příběh (user story). Při plánovací hře zákazník pouze určuje hrubý plán projektu, který je zpřesňován po každé iteraci. • Malá verze (Small Releases) Výsledkem každé iterace je funkční verze projektu s implementovanými požadavky zákazníka. Nové verze jsou uvolňovány do provozu tak často, jak je to jen možné. Nejsou tedy výjimkou denní či týdenní změny verzí, které přinášejí programátorům velmi rychlou zpětnou vazbu. • Zákaznické testy (Customer Tests) Úspěšnost implementovaných požadavků ověřuje zákazník pomocí akceptačních testů, které sám specifikuje, a které vycházejí z uživatelských příběhů. Jejich používáním dokáže zákazník jasně definovat problém a předat ho programátorům. • Metafora (Metaphor) Pro komunikaci v týmu existuje pomůcka nazvaná metafora. Metafora poskytuje
17
• •
•
•
•
•
•
•
systém jmen a popisů architektury systému. Pomáhá pochopit prvky systému a vztahy mezi nimi v jazyce, kterému rozumí zákazník i programátor. Nepřetržitá integrace (Continuous Integration) Do funkčního systému se změny integrují několikrát denně. Jakmile je kód hotový, okamžitě proběhnou testy, které prověří funkčnost změny. Společné vlastnictví kódu (Collective Ownership). Žádná část projektu nemá svého vlastníka. Každý programátor má přístup ke kódu a může tak kdykoliv provést jeho změnu, refaktoraci či přidat testy. Tato praktika je základem pro párové programování a testy. Standardy pro psaní zdrojového kódu (Coding Standard) Pro psaní zdrojového kódu jsou vytvořeny konvence, které umožňují komunikaci prostřednictvím zdrojového kódu, udržují konzistentnost kódu a umožňují snadnou refaktorizaci. Jedná se zejména o sjednocené odsazování, pojmenovávání či psaní komentářů. Cílem je, aby v projektu nebylo poznat, který programátor určitou část napsal. Dodržování tohoto principu je nutným předpokladem pro praktiky párového programování a společného vlastnictví kódu. Udržitelný vývoj (Sustainable Pace) XP prosazuje názor, že unavení programátoři dělají více chyb, odvádí méně práce a produkují špatný kód. Proto XP stanovuje týdenní pracovní dobu s přesčasy trvající maximálně 1 týden. Metodologie XP výslovně přesčasy nezakazuje, v praxi jsou však využívány pouze v případě nutných rychlých zásahů. Jednoduchý návrh (Simple Design) XP prosazuje jednoduché návrhy, které řeší aktuální požadavky a které nelze dále zjednodušit. Budoucnost požadavku není v návrhu zahrnuta, řeší se jen to, co je požadováno. Párové programování (Pair Programming) U jednoho počítače pracují, společně při programování, dva programátoři. Zatímco první programátor píše kód, druhý vymýšlí testy k aktuálnímu kódu, radí a opravuje píšícího programátora nebo přemýšlí o refaktoringu. Páry si své role vyměňují a proces opakují. Páry v průběhu dne nejsou stálé, mohou se měnit i několikrát denně. Tento postup je velice efektivní, podněcuje komunikaci, sdílí a přenáší znalosti a zajišťuje dodržování praktik XP. Refaktorizace (Refactoring) Proces refaktorizace provádí změnu v projektu tak, že vylepší jeho strukturu a zároveň nezmění funkčnost softwarového systému. Jeho cílem je zjednodušení a zpřehlednění projektu. Společné vlastnictví umožňuje programátorům vylepšit jakýkoli kód při zachování srozumitelnosti nově refaktorovaného kódu. Tím je zároveň zajištěna zvyšující se kvalita projektu. Postup refaktorizace je zcela bezpečný, neboť je zajištěn vytvořenou sadou testů. Vývoj řízený testy (Test‐Driven Development) Princip vývoje řízeného testy (TDD) spočívá v tom, že se před začátkem implementace kódu nejdříve napíše jednotkový test (unit test) a až poté samotný kód. TDD se v XP hojně využívá k regresnímu testování a refaktorizace. Nové verze projektu vždy musí úspěšně projít všemi jednotkovými testy. Celý cyklus je znázorněn v diagramu aktivit na obrázku 2.1.3‐2. [5, s. 148‐152] [6, s. 52‐64] [7]
18
Obrázek 2.1.3‐2: Vývoj řízený testy
2.1.4.
Feature driven development
Druhou a zároveň poslední agilní metodikou, kterou představím, je Feature driven development (FDD). Tuto metodiku poprvé použil Jeff De Luca v roce 1997 a detailně ji popsal v roce 2002. FDD je zaměřená na užitné vlastnosti (feature) vyvíjeného systému, které se zakládají na iterativním a inkrementálním základu. Výsledkem je pro zákazníka srozumitelný, měřitelný a realizovaný užitek. Cílem tedy není splnění předepsaného procesu, ale vytvoření kvalitního a fungujícího produktu splňujícího požadavky zákazníka. [8, s. 51] Podobně jako u předešlých metodik vývoje softwaru, je FDD postaveno na skupině praktik a osvědčených postupů. Metodika nevyžaduje přijmout všechny praktiky naráz, pouze doporučuje jejich správnou kombinaci. • Doménové objektové modelování (Domain Objec Modeling). Model využívá objektové modelování domény, tedy oblast, do které se následně zasazuje funkcionalita jednotlivých užitných vlastností. Pro zachycení důležitých typů objektů, jejich chování a vzájemných vztahů, model využívá především diagram tříd doplněných sekvenčními diagramy. • Vývoj podle užitných vlastností (Developing by Feature) Vývoj je veden ve formě užitných vlastností (features) ‐ malých funkcí, které řídí další vývoj softwaru a mají hodnotu pro zákazníka. • Individuální vlastnictví tříd (Individual Class Ownership) Na rozdíl od XP jsou jednotlivé části kódu (třídy) vlastněny programátorem, který má plnou odpovědnost za jejich implementaci, testování a integritu. Výhodou je snadná 19
•
• • • •
dohledatelnost autora, jenž kódu rozumí. Tím jsou snadněji a hlavně rychleji vyřešitelné jakékoli úpravy. Týmy pro užitné vlastnosti (Feature Teams) Každou implementovanou užitnou vlastnostnost spravuje dílčí tým, který dočasně sdružuje vlastníky tříd, potřebné pro implementaci užitné vlastnosti. Týmy pro užitné vlastnosti vybírá hlavní programátor podle konkrétní funkcionality; z toho důvodu může být jedna osoba členem více týmů. Inspekce (Inspections) Během vývoje jsou naplánovány časté inspekce kvality návrhu a kódu. Důvodem je odstranění chyb, které během vývoje vznikají. Pravidelné buildy (Regular Builds) Pravidelná integrace všech hotových užitných vlastností a spuštění automatických testů, zaručují funkčnost celého projektu. Řízení konfigurací (Configuration Management) Sledování průběhu zdrojového kódu zaručuje možnost kdykoliv se vrátit k fungující části systému. Reporting/viditelnost výsledků (Reporting/Visibility of Results) Lepší plánování a organizace vývoje přispívají k minimalizaci a automatizaci sběru informací. To umožňuje kdykoliv sledovat, v jakém stavu se projekt nachází.
FDD se skládá z pěti procesů, které umožňují vývojářům pracovat na potřebných částech projektu. • Proces 1 Vypracování celkového modelu Při tomto procesu dochází k tvorbě hrubého modelu celé domény. Během něj spolupracují členové vývojového týmu s uživateli pod vedením hlavního architekta. Celý proces začíná uživatelskou prezentací úvodní představy systému, následuje vytvoření kostry modelu, která se dále podrobně specifikuje. Z výsledků se vybírá nejlepší řešení, jež se doplní o postřehy z ostatních řešení, ze kterého vznikne celkový model. • Proces 2 Sestavení seznamu užitných vlastností Tento proces definuje seznam užitných vlastností vyvíjeného systému. • Proces 3 Plánování užitné vlastnosti Pro plánování a realizaci seznamu užitných vlastností je vytvořen tým, který určí pořadí vývoje užitných vlastností. • Proces 4 Návrh užitné vlastnosti Hlavní programátor určí třídy, kterých se užitná vlastnost týká a z příslušných vlastníků kódu vytvoří tým, který vypracuje návrh. • Proces 5 Realizace užitné vlastnosti Poslední část obsahuje implementaci navržených tříd z předchozího procesu, která je každým vlastníkem otestovaná jednotkovými testy.
20
Obrázek 2.1.4‐1: Procesy FDD
První tři procesy jsou společné pro celý projekt; během nich se vytvoří celkový model a plán vytvořeného seznamu užitných vlastností. Následují dva procesy, které se střídavě opakují. V každé iteraci je od jednotlivých vlastníků tříd implementována požadovaná užitná vlastnost. [5, s. 135‐138]
21
Část II Společnost ALPIQ ENERGY SE
22
3. O systému Informační systém společnosti ALPIQ ENERGY SE, která se zabývá obchodováním s elektřinou (výroba, nákup, prodej), se skládá z několika částí. Jde především o část plánovací, obchodní, fakturační a účetní. Každá část využívá jiné softwarové aplikace, vyvíjené různými společnostmi, které sbírají, udržují a zpracovávají data. Ve své bakalářské práci se zaměřím na vývojový model fakturačního softwaru, jenž je interně nazýván Invoicing Client.
3.1.
Invoicing Client
Invoicing Client (IC) je interní fakturační software vyvíjený společností ALPIQ ENERGY SE, který zajišťuje zpracování konečného vyúčtování dodané a prodané elektřiny. V současné době se software převážně využívá pro: • fakturaci smluvených energetických profilů velkoobchodních (wholesale) zákazníků, • fakturaci spotřebované energie maloobchodních (retail) zákazníků. Mimo jiné jsou v IC zabudované moduly pro: • import příchozích faktur, • export faktur do účetního softwaru SAP, • import měřených spotřeb jednotlivých zákazníků, • import predikčních profilů a jejich oceňování, • kontrolu konzistence dat. Rozsah aplikace je nad rámec možností jedné osoby, tudíž celý proces vývoje obstarává tým lidí. Ten se skládá ze čtyř členů: projektového manažera, dvou vývojářů a testera. Je použita architektura klient‐server ve formě tzv. „tlustého klienta“. IC je napsán v jazyce C# a pro tvorbu využívá Microsoft Visual Studio 2008. Software je možné spustit pod systémem Microsoft Windows XP. Data jsou uložena na databázovém serveru se systémem Microsoft SQL Server 2003. Většina výpočtů probíhá v klientovi, server je využíván pouze jako centrální prvek uložených dat. Pro zpracování požadavků je využíván sašimi modifikace vodopádového modelu s použitím TDD principu v testovací fázi projektu. V současné chvíli se IC využívá na fakturaci tří entit – české (CZ), polské (PL) a maďarské (HU).
3.1.1.
Definice pojmů
• • • • • • •
zákazník: smluvní partner, kontrakt: smlouva o sjednaném obchodu se zákazníkem, odběrné místo: místo napojení zákazníka na síť elektrické energie, energetický profil: množství energie nakoupené zákazníkem pro určité období, wholesale: velkoobchodní zákazník nakupující energetické profily, retail: maloobchodní zákazník vlastnící odběrné místo, fakturační skupina: skupina odběrných míst či energetických profilů, jejichž vyúčtování služeb je zákazníkovi vystaveno na jedné faktuře, • servis: služba objevující se na vystavené faktuře, 23
• counterparty: protistrana; interní označení zákazníka jednoznačným názvem (většinou zkratka názvu společnosti + řetězec „_p“), • energetická burza: místo prodeje a nákupu elektřiny, • směr dodávky: odlišení nákupu a prodeje z pohledu ALPIQu.
3.1.2.
Základní datový model
Obrázek 3.1.2‐1: Základní datový model IC
Datový model IC je složen ze tří hlavních tabulek. C_Customer, CO_Contract a IGH_InvoicingGroupHeader (IGH). Tabulky CO_Contract a IGH_InvoicingGroupHeader jsou propojeny přes primární klíč tabulky C_Customer, tj. sloupce C_Id. Všechny názvy tabulek a sloupců jsou v korporátním jazyce společnosti – angličtině. Nyní detailněji pohovořím o každé tabulce.
3.1.2.1. Tabulka C_Customer
Obrázek 3.1.2.1‐1: Tabulka C_Customer 24
Tabulka C_Customer slouží pro evidenci obchodních partnerů (zákazníků). Nejdůležitějšími sloupci pro fakturaci jsou: • C_Id [int], tj. primární klíč tabulky a zároveň identifikátor zákazníka. • C_ValidFrom [datetime] a C_ValidTo [datetime] určují platnost zákazníka. • C_Cpty [varchar(50)] identifikuje counterparty. • C_Option [int] určuje, zda se jedná o velkoobchodního nebo maloobchodního zákazníka.
3.1.2.2. Tabulka CO_Contract
Obrázek 3.1.2.2‐1: Tabulka CO_Contract
Slouží pro úschovu sjednaných kontraktů s daným zákazníkem. Důležitost tabulky se postupem času snižuje. V důsledku potřeby různého nastavení fakturačních skupin 2 pod jedním kontraktem, jsou potřebné sloupce přemisťovány do tabulky IGH_InvoicingGroupHeader.
2
Vystavují se 2 a více faktur pro stejného zákazníka.
25
3.1.2.3. Tabulka IGH_InvoicingGroupHeader
Obrázek 3.1.2.3‐1: Tabulka IGH_InvoicingGroupHeader Výše uvedená tabulka patří při fakturaci mezi klíčové a slouží k uložení nastavení fakturačních skupin pro jednotlivé zákazníky. Přes cizí klíče jsou na tuto tabulku navázány např.: vytvořené faktury, servisy (jednotlivé řádky faktury), zálohové platby či odběrná místa (OPM). Mezi nejdůležitější sloupce pak patří: • IGH_Id [int], tj. primární klíč tabulky a zároveň identifikátor fakturační skupiny. • IGH_SC_Id [int] určuje, pod jakou entitou je daný záznam fakturován. • IGH_CU_Id [int] definuje, v jaké měně bude vytvořena výsledná faktura. • IGH_Periodicity [tinyint] zaznamenává, jak často se na fakturační skupinu vystavuje faktura v měsíčním období. • IGH_CAH_Id [int] odkazuje na číselník typu kalendáře. • IGH_RoundInvoice [tinyint] popisuje, na kolik desetinných míst má být faktura zaokrouhlována. • IGH_InvoiceMaturityDays [smallint] určuje počet dní. 26
• IGH_FirstPossibleDueDate [smallint] identifikuje první možný den data splatnosti faktury. • IGH_InvoiceCalculationOption [int] na základě bitového součtu definuje možnosti výpočtu. Přes formulář v IC lze pomocí RadioButton prvků nastavit: Tabulka 3.1.2.3‐1: Možnosti nastavení sloupce IGH_InvoiceCalculationOption Bit True False 1 Exchange rate in the last day of Exchange rate in invoice day period 2 InvoiceDutyDay based on working InvoiceDutyDay based on calendar day day 4 Use scheduled profile Use measured profile 8 Tax date = invoice date Tax date = end of invoice period 16 Tax date = due date Tax date = above 32 kWh MWh (stored quantity is divided by 1000) 64 Total prepayment (sum of amount) Normal prepayment 128 ER in the penultimate wednesday in ER according to first line the month 256 Due date based on end of invoice Due date based on invoice date period 512 Due date at the last day of invoice Due date according to line above period + 1 m. 1028 Due date at the first day of invoice Due date according to line above period 2048 Use bonus scheduled profile Use above selected profile Z této tabulky se mimo jiné vybírají podklady pro zobrazení tištěné faktury. Patří mezi ně: adresa (IGH_InvoicingAddress [nvarchar(255)]), IČO (IGH_INO [varchar(50)]), DIČ (IGH_VatId [char(30)]), telefonní číslo (IGH_Phone [varchar(30)]) a Fax (IGH_Fax [varchar(30)]).
3.1.3.
Datový model fakturace
V současné chvíli existují dva způsoby fakturace. Datové modely se od sebe liší tím, odkud energie pochází, zda ze spotřeby či z prodeje na burze.
27
3.1.3.1. Fakturace velkoobchodu (wholesale)
Obrázek 3.1.3.1‐1: Základní datový model fakturace velkoobchodu Předmětem fakturace velkoobchodních partnerů je vyúčtování smluvených energetických profilů, které vznikly obchodováním na energetické burze. Prodaná energie se do fakturačního modelu (do tabulky DAILY_TICKET) vkládá pomocí příchozích XML souborů z obchodní aplikace. Tabulky jsou propojené pomocí cizího klíče přes counterparty (sloupec CPTY). Struktura je následující:
28
Obrázek 3.1.3.1‐2: Tabulka DAILY_TICKET Pro každý den (sloupec Date) a protistranu (Cpty) je po jednotlivých hodinách (h0‐h23) zaznamenána a oceněna (D_Currency) prodaná energie. Typ obchodu je rozlišen pomocí 29
sloupce Book a výslednou energií k fakturaci je jednoduchá suma všech hodin v daném fakturačním období.
3.1.3.2. Fakturace maloobchodu (Retail) Pomocí měřicích přístrojů se zaznamenává spotřebovaná energie. Každý přístroj je označen nezaměnitelným 18ti místným registračním číslem, začínajícím na 859182240. Údaje o spotřebě shromažďuje Operátor trhu s elektřinou (OTE), jenž dále distribuuje získaná data pomocí XML souborů dodavatelům, na která jsou OPM registrovaná. Tyto údaje jsou zaznamenávány v hodinových intervalech v tabulce MD_MeasuredData.
Obrázek 3.1.3.2‐1: Tabulka MD_MeasuredData
Registrační číslo je uvedeno ve sloupci MD_LocationId. Dále následuje datum (MD_Date), hodina (MD_Hour) a naměřené množství odebrané elektřiny (MD_Qty). Sloupec MD_MDV_Id odkazuje na poslední záznam v tabulce uchovávající historii záznamů. Poslední sloupec MD_ProfileRole určuje, jakým směrem proběhla dodávka elektřiny, zda se spotřebovávala či vyráběla.
Obrázek 3.1.3.2‐2: Datový model fakturace maloobchodu
Seznam měřicích přístrojů uchovává tabulka IG_InvoicingGroup, jež je přes cizí klíč napojena na tabulku IGH. Registrační číslo je uvedeno pod sloupcem IG_OPM, na který je zároveň cizím klíčem propojena tabulku MD_MeasuredData.
30
Část III Praktická část
31
4. Specifikace požadavků Cílem specifikace požadavků je popsat, jak má softwarový systém pracovat prostřednictvím specifikace jeho funkcionality. Modely specifikace požadavků slouží k odsouhlasení zadání mezi vývojovým týmem a zadavatelem. [1, s. 27]
4.1.
Zadání
Fakturační oddělení podalo žádost o změnu výpočtu data splatnosti faktury. Cílem má být umožnění nastavení různých variant splatnosti, které jsou specifikovány ve smlouvách se zákazníky.
4.1.1.
Funkcionalita
Aplikace IC bude, na základě uživatelského nastavení parametrů, umožňovat následující volby: − Pro datum splatnosti závislé na datu vystavení faktury: o Umožnit nastavení počtu dní ode dne vystavení faktury. o Umožnit zadání počtu dní nad rámec standardní smluvené doby splatnosti faktury. o Umožnit volbu mezi kalendářním a pracovním dnem (určených dle kalendáře země). o Umožnit nastavení nebankovních dnů 3 na základě národního kalendáře. − Pro datum splatnosti závislé na fakturačním období: o Umožnit nastavení pevného data splatnosti pro jakékoli fakturační období. o Umožnit zadání počtu dní nad rámec standardní smluvené doby splatnosti faktury. o Umožnit nastavení nebankovních dnů2 na základě národního kalendáře. − Pro datum splatnosti bez ohledu na datum vystavení faktury: o Umožnit zadání minimálního možného dne data splatnosti. o Umožnit nastavení nebankovních dnů2 na základě národního kalendáře. o Definovat datum splatnosti fakturačního období bez ohledu na datum vystavení. Například pevné datum splatnosti je 25. den v měsíci předcházejícího měsíci dodání. Musí tedy být možné vygenerovat zálohové faktury na celý rok v jednom dni tak, aby data splatnosti spadala do 25. dne příslušného měsíce dodání. [9, s. 4]
3
Například pokud datum splatnosti spadá na neděli, bude automaticky posunuté na pondělí.
32
5. Analýza Analýza je fází softwarového procesu, který pokrývá převod slovního zadání či jinak zpřesněného popisu reality do tvaru, který může sloužit jako podklad pro zahájení návrhu řešení a pro vlastní implementaci. Analýza znamená studium problému (jeho poznání, popis, modelování) dříve, než se začnou provádět akce směřující k řešení tohoto problému (tvorba IS). Za řešení se považuje i odůvodněné negativní stanovisko odmítnutí realizace. Současně se v této fázi může provádět návrh ovládání programu a jeho vzhledu.
5.1.
Analýza současného stavu
IC pracuje s výpočtem data splatnosti na datové vrstvě, to znamená, že aplikace neprovádí žádný výpočet, pouze po zavolání získá výsledné datum. Výpočet data splatnosti do této chvíle nevyžadoval mnoho nastavení. Řešení počítá s jednoduchými posuny o n dní či posunem o jeden měsíc.
5.1.1.
Datový model
Ze zadaných hodnot sloupců IGH_InvoiceMaturityDays a IGH_FirstPossibleDueDate je dle nastavení sloupce IGH_InvoiceCalculationOption (viz tabulka č. 3.1.2.3‐1 bit 256, 512 a 1024) počítáno výsledné datum splatnosti.
5.1.2.
Výpočet data splatnosti
Na výpočet hodnoty data splatnosti se používá procedura spGetDueDate. Vstupními parametry jsou: • @pIGH_Id [int] – identifikační číslo fakturační skupiny • @pDateFrom [datetime] – počátek fakturačního období • @pDateTo [datetime] – konec fakturačního období • @pInvoiceDate [datetime] – datum fakturace
Obrázek 5.1.2‐1: Procedura spGetDueDate část 1.
Nejdříve se dekladují dvě proměnné. @DueDate1 a @DueDate2. První proměnná @DueDate1 se dle nastaveného bitového součtu naplní jednou z těchto možností: @pDateFrom, poslední den následujícího měsíce nebo posunem dnů zvolených ve sloupci IGH_InvoiceMaturityDays . Druhá proměnná @DueDate2 je vypočítána jako posun dnů ze sloupce IGH_FirstPossibleDueDate, tedy první možné datum splatnosti. 33
Obrázek 5.1.2‐2: Procedura spGetDueDate část 2.
Tato podmínka zajistí, že datum splatnosti proměnné @DueDate1 bude vždy větší nebo rovno @DueDate2. Obrázek 5.1.2‐3: Procedura spGetDueDate část 3.
A nakonec se vybere proměnná @DueDate1 jako výstup procedury spGetDueDate.
5.2.
Analýza zadání
Současná struktura zadané specifikaci nevyhovuje. Je velmi těžko rozšiřitelná o nové požadavky. Nabízí se tedy možnost refaktorizace celého výpočtového modelu s provedením potřebných úprav. Bylo dohodnuto, že změna bude převedena do aplikační vrstvy, tedy práce se třídami.
34
6. Návrh řešení Tato část práce obsahuje návrh řešení požadavku, tj. zahrnuje definici parametrů a technický postup pro jejich řešení.
6.1.
Návrh realizace
Nejprve zvážíme, jaký druh výpočtu bude jednotlivá fakturační entita využívat. Tabulka 6.1‐1: Druh výpočtu fakturačních entit Entita Druh výpočtu CZ Fixní datum Pohyblivé datum Zohlednění pracovních dní Zohlednění nebankovních dní PL Fixní datum dekádních a měsíčních faktur HU Pohyblivé datum Fixní datum Přidání počtu dní nad rámec standardní smluvené doby Poslední den v měsíci
6.1.1.
Definice parametrů
Aspektů, které ovlivňují datum splatnosti, je mnoho. Proto si nadefinujeme základní parametry a určíme typy a hodnoty, kterých budou nabývat. Tabulka 6.1.1‐1: Definice základních parametrů Č. Parametr Typ nebo hodnota 1 Typ výpočtu Pohyblivý/fixní 2 Počátek Datum vystavení/poslední den dodávky 3 Splatnost Číselné vyjádření počtu dnů 4 Počet dnů navíc Číselné vyjádření počtu dnů 5 Typ dne Kalendářní/pracovní 6 Bankovní dny Ano/ne Sada těchto parametrů bude dostačující pro výpočet pohyblivého data splatnosti, kde se pracuje s jednoduchými posuny. Fixní typ výpočtu vyžaduje detailnější specifikaci parametrů. Tabulka 6.1.1‐2: Detailní specifikace parametrů Č. Parametr Typ nebo hodnota 1 Počátek fakturačního Číselné vyjádření dne období 2 Počet fixních dní Číselné vyjádření počtu dní (0 = poslední den v měsíci) 3 Relativní posun měsíců Počet měsíců od fakturačního období (0 = stejný měsíc fakturačního období; 1 = měsíc po fakturačním období) 35
6.1.2.
Příklad
Pro úplnost uvádím šest typových situací, které mohou nejčastěji nastat. Tabulka 6.1.2‐1: Typové situace Č. Parametr 1. př. 2. př. 3. př. 4. př. 5. př. 6. př. 1 Typ výpočtu Pohyblivý Pohyblivý Fixní Fixní Fixní Fixní 2 Počátek Vystavení Konec Konec Vystavení Konec Konec 3 Splatnost 20 15 0 5 0 0 4 Počet dnů navíc 0 1 0 0 0 0 5 Typ dne Kalend. Kalend. Kalend. Kalend. Kalend. Kalend. 6 Bankovní dny Ne Ne Ne Ne Ne Ne 1 Počátek fakturačního X X 1 1 1 1 období 2 Počet fixních dní X X 0 20 16 25 3 Relativní posun v X X 1 1 0 ‐1 měsíci 11 26 0 21 6 1 Pozn. 1. př.: standardní wholesale zákazník; 20 dní po vystavení faktury 2. př.: maďarský retail; 15 dní od konce fakturačního období; přidaný 1 den navíc 3. př.: maďarský retail; poslední den měsíce následující po měsíci fakturačního období 4. př.: nestandardní wholesale zákazník; fixní 20. den měsíce, ovšem minimálně 5 dní po vystavení faktury 5. př.: polský dekádní wholesale zákazník; fixní 6., 16. a 26. den měsíce 6. př.: zálohová faktura; fixní 25. den měsíce předcházející měsíci fakturačního období Tabulka 6.1.2‐2: Výsledné datum splatnosti Příklad Datum vystavení Fakturační období Výsledné datum splatnosti 1 3. 1. 2011 1. ‐31. 12. 2010 20. 1. 2011 2 7. 1. 2011 1. ‐31. 12. 2010 16. 1. 2011 3 7. 1. 2011 1. ‐31. 12. 2010 31. 1. 2011 4 17. 1. 2011 1. ‐31. 12. 2010 22. 1. 2011 5 3. 1. 2011 21. ‐31. 12. 2010 6. 1. 2011 6 3. 1. 2011 1. ‐28. 2. 2011 25. 1. 2011
6.1.3.
Technický postup
36
6.1.3.1. Datový model
Obrázek 6.1.3.1‐1: Datový model nové struktury
Základní parametry definuje tabulka DDD_DueDateDefinition (DDD), která je přes cizí klíč napojena na tabulku fakturačních skupin IGH. Tabulka DDD obsahuje identifikátor DDD_Id, rozsah platnosti (sloupce DDD_ValidFrom a DDD_ValidTo) a jednotlivé parametry uvedené v následující tabulce. Tabulka 6.1.3.1‐1: Názvy sloupců základních parametrů v tabulce DDD Č. Parametr Datový typ Název sloupce 1 Typ výpočtu bit DDD_IsFloatinCalculationType 2 Počátek bit DDD_IsDeliveryBaseDate 3 Splatnost int DDD_MaturityDays 4 Počet dnů navíc int DDD_DaysAbove 5 Typ dne bit DDD_IsMaturityDaysWorking 6 Bankovní dny bit DDD_IsDueDateWorking Poslední sloupec DDD_Periodicity [int] udává periodicitu faktur v měsíci. Detailní specifikaci pak zastupuje tabulka DDP_DueDateParameter (DDP), jež je pomocí cizího klíče napojena na tabulku DDD přes sloupec DDP_DDD_Id [int]. Tabulka 6.1.3.1‐2: Názvy sloupců detailní specifikace v tabulce DDP Č. Parametr Datový typ Název sloupce 1 Počátek fakturačního období int DDP_PeriodStartDay 2 Počet fixních dní int DDP_FixedDueDay 3 Relativní posun měsíců int DDP_RealMonthShift
6.1.3.2. Pravidla výpočtu Pro výpočet je třeba držet se zadání a definovat si, dle jakých podmínek a pravidel bude datum splatnosti počítáno.
6.1.3.2.1. Pohyblivý • Pokud DDD_IsDeliveryBaseDate = 1 potom datum splatnosti = konec fakturačního období + DDD_MaturityDays + DDD_DaysAbove • Pokud DDD_IsDeliveryBaseDate = 0 potom datum splatnosti = datum vystavení + DDD_MaturityDays + DDD_DaysAbove 37
• Pokud DDD_MaturityDaysWorking = 1 zůstává způsob výpočtu stejný, jen s tím rozdílem, že datum splatnosti je počítáno pouze z pracovních dnů. • Pokud DDD_IsDueDateWorking = 1 posouvá se datum splatnosti posunuté na nejbližší následující pracovní den (pouze v případě, že datum splatnosti připadne na nepracovní den). • Záznamy s pohyblivým typem výpočtu nemají definované parametry v tabulce DDP. • Nepracovní dny jsou soboty, neděle a svátky, které jsou definovány v samostatné tabulce CAH_Calendar, jež je propojena vazbou přes IGH_CAH_Id.
6.1.3.2.2. Fixní (FixedDueDate) • • • • •
Pokud DDP_FixedDueDate= 0 potom den FixedDueDate = poslední den v měsíci DDP_PeriodStartDay = den počátku fakturačního období Den FixedDueDate = DDP_FixedDueDate Měsíc FixedDueDate = měsíc konce fakturačního období + DDP_RelMonthShift Pokud DDD_MaturityDaysWorking = 1 je způsob výpočtu stejný, s tím rozdílem, že je datum splatnosti počítáno pouze z pracovních dnů. • Pokud DDD_IsDueDateWorking = 1 je vypočtené datum splatnosti posunuté na následující pracovní den (pouze v případě, že datum splatnosti připadne na nepracovní den). • Záznamy s pohyblivým typem výpočtu nemají definované parametry v tabulce DDP. • Nepracovní dny jsou soboty, neděle a svátky, které jsou definovány v samostatné tabulce CAH_Calendar, jež je propojená vazbou přes IGH_CAH_Id.
Pokud datum vystavení + DDD_MaturityDays+DDD_DaysAbove > FixedDueDate pak datum splatnosti = datum vystavení + DDD_MaturityDays + DDD_DaysAbove jinak datum splatnosti = FixedDueDate
6.2.
Schválení návrhu
V této formě byl návrh předložen fakturačnímu oddělení a byl schválen, proto se okamžitě mohlo začít s vývojem.
38
7. Implementace Tato část bakalářské práce obsahuje realizaci řešení problému do stávající aplikace. Poukazuje na konkrétní řešení struktur tabulek, použitých objektů a vytvoření zdrojového kódu.
7.1.
Datová vrstva
Obrázek 7.1‐1: Datový model pro nastavení data splatnosti
Navrhovaný model se od návrhu téměř nezměnil. Byl pouze odstraněn nadbytečný sloupec DDD_Periodicity z tabulky DDD. Existuje sloupec IGH_Periodicity v tabulce IGH, na který je tabulka DDD připojena přes cizí klíč, a který uchovává stejnou informaci.
7.1.1.
Tabulky
Pro vytvoření nových tabulek slouží následující skript, který stačí spustit v příslušné databází vývojového serveru. CREATE TABLE [dbo].[DDD_DueDateDefinition] ( [DDD_Id] [int] NOT NULL , [DDD_IGH_Id] [int] NOT NULL , [DDD_ValidFrom] [datetime] NOT NULL , [DDD_ValidTo] [datetime] NULL , [DDD_IsFloatingCalculationType] [bit] NOT NULL , [DDD_IsDeliveryBaseDate] [bit] NOT NULL , [DDD_MaturityDays] [int] NOT NULL , [DDD_DaysAbove] [int] NOT NULL , [DDD_IsMaturityDaysWorking] [bit] NOT NULL , [DDD_IsDueDateWorking] [bit] NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[DDP_DueDateParameter] ( [DDP_DDD_Id] [int] NOT NULL , [DDP_PeriodStartDay] [int] NOT NULL , [DDP_FixedDueDay] [int] NOT NULL , [DDP_RelMonthShift] [int] NOT NULL ) ON [PRIMARY] 39
GO ALTER TABLE [dbo].[DDD_DueDateDefinition] WITH NOCHECK ADD CONSTRAINT [PK_DDD_DueDateDefinition] PRIMARY KEY CLUSTERED ( [DDD_Id] ) ON [PRIMARY] GO ALTER TABLE [dbo].[DDP_DueDateParameter] WITH NOCHECK ADD CONSTRAINT [PK_DDP_DueDateParameter] PRIMARY KEY CLUSTERED ( [DDP_DDD_Id], [DDP_PeriodStartDay] ) ON [PRIMARY] GO ALTER TABLE [dbo].[DDD_DueDateDefinition] ADD CONSTRAINT [FK_DDD_DueDateDefinition_IGH_InvoicingGroupHeader] FOREIGN KEY ( [DDD_IGH_Id] ) REFERENCES [dbo].[IGH_InvoicingGroupHeader] ( [IGH_Id] ) GO ALTER TABLE [dbo].[DDP_DueDateParameter] ADD CONSTRAINT [FK_DDP_DueDateParameter_DDD_DueDateDefinition] FOREIGN KEY ( [DDP_DDD_Id] ) REFERENCES [dbo].[DDD_DueDateDefinition] ( [DDD_Id] ) GO Skript vytvoří nejen tabulky, ale i příslušné vazby mezi nimi, tj. primární a cizí klíče.
7.1.2.
Uložené procedury
Pro pozdější využití byly vytvořeny procedury na získávání uloženého nastavení (obrázek 7.1.2‐1) a na posuny dnů (obrázek 7.1.2‐2). Uložené procedury mají, oproti přímé implementaci do aplikace, několik výhod. Především izolují aplikaci od změn v databázi. Při změně struktury databáze stačí pouze proceduru modifikovat a nemusí se měnit kód aplikace. To se samozřejmě týká pouze změn logického významu uložených dat, kterých nebývá mnoho. Většinou se jedná o přidávání nových sloupců, na což ovšem aplikace reagovat musí. Druhá výhoda spočívá ve vyšší výkonnosti. To se zejména projeví při častém volání procedury. Uložená procedura má proti přímo poslanému SQL dotazu výhodu v tom, že je zkompilovaná a zoptimalizovaná pouze jednou, zatímco k provedení dochází mnohokrát. SQL server automaticky vytváří spouštěcí scénáře a statistiky, které optimalizují rychlost provedení. [10, s. 303] 40
Obrázek 7.1.2‐1: Procedura spGetDueDateSettings
Procedura vybírá nastavení z databáze pro konkrétní fakturační skupinu. Bere přitom v potaz validitu záznamu dle počáteční hodnoty fakturačního období. K tabulce DDD je tabulka DDP propojena levým joinem, jelikož nutně nemusí existovat doplňující specifikace v případě pohyblivého typu data splatnosti.
41
Obrázek 7.1.2‐2: Procedura spAddNWorkingDays
Vstupní parametry procedury jsou: typ kalendáře, datum posunu a hodnota splatnosti. Procedura postupně hledá nepracovní dny, které jsou uváděny v tabulkách WD_WorkingDay (speciální tabulka pro maďarské pracovní soboty) a CA_Calendar (tabulka se seznamem státních svátků).
7.2.
Aplikační vrstva
42
7.2.1.
Kódování Obrázek 7.2.1‐1: Použití jmenných prostorů
Na začátku se definují jmenné prostory (namespace), které se budou ve třídě využívat.
Obrázek 7.2.1‐2: Třída DueDateCalculator Pro další členění je deklarována třída DueDateCalculator pod jmenný prostor INV.Common.Calculation.
7.2.1.1. Konstruktor V dalším kroku jsem vytvořil konstruktor třídy DueDateCalculator. Konstruktor je metoda, která se zavolá vždy, když dojde k vytvoření instance třídy nebo struktury. Vstupními parametry jsou: IGH_Id, počátek fakturačního období, konec fakturačního období, datum fakturace, IGH_Periodicity, IGH_CAH_Id a IGH_InvoiceCalculationOption
Obrázek 7.2.1.1‐1: Konstruktor třídy DueDateCalculator
7.2.1.2. Metody
Obrázek 7.2.1.2‐1: Metoda InitInstanceSettings 43
Jako vstupní bod třídy je deklarována metoda InitInstanceSettings, která se spouští při každém zavolání konstruktoru DueDateCalculator. Tato metoda buď nic nevrací (void), nebo vrací datum (datetime).
Obrázek 7.2.1.2‐2: Definice proměnné DueDate V prvním kroku se definuje proměnná DueDate, která se naplní pomocí metody Calculate() a je výstupem celé třídy DueDateCalculator.
Obrázek 7.2.1.2‐3: Metoda Calculate
Metoda Calculate() na základě podmínky IsFloatingCalculationType vrací proměnnou baseDate (datetime), kterou vypočítá z množiny následujících metod (CalculateBaseDate, CalculateMaturity, CalculateShift a CalculateFinal).
44
Obrázek 7.2.1.2‐4: Metoda CalculateBaseDate
Nejdůležitější metodou třídy DueDateCalculator je CalculateBaseDate. Na základě nastavení sloupce IsFloatingCalculationType (fixní nebo pohyblivé datum splatnosti) rozhoduje o tom, jaká bude výsledná hodnota data splatnosti.
Obrázek 7.2.1.2‐5: Plnění tabulky DueDateSetting
Pro načtení nastavení parametrů slouží již vytvořená procedura spGetDueDateSettings, jež naplní tabulku DueDateSetting. Tato tabulka je definována ve třídě InvData 4 a její struktura je totožná se strukturou volané procedury. V případě neúspěchu – například při chybějících právech na proceduru – aplikace zobrazí výjimku o chybějícím nastavení.
Obrázek 7.2.1.2‐6: Metoda CalculateMaturity() Metoda CalculateFinal() zohledňuje nastavení bankovních dní.
4
Třídu InvData vytváří automatický skript.
45
Obrázek 7.2.1.2‐7: Metoda CalculateShift
Metoda CalculateShift() přidává počet dní nad rámec standardní smluvené doby.
Obrázek 7.2.1.2‐8: Metoda CalculateFinal
Metoda CalculateMaturity() zvyšuje datum o zadaný počet dnů. V případě nastavení volby pracovního dne je zavolána procedura spAddNWorkingDays, která datum posune na nejbližší následující pracovní den. [11]
46
8. Testování V této části práce je popsáno, jaké nástroje byly využity pro testování softwaru. Není opomenuta příprava testovacího serveru včetně přenosu změn z vývojového serveru. Pro tento proces je hojně využíván anglický jednoslovný pojem deployment. Testování je nejdůležitější fází vývojového cyklu, protože v jeho průběhu se z nedokončeného polotovaru stává hotová aplikace. [10, s. 155]
8.1.
Příprava testovacího serveru
Pro testování je velmi důležité mít připraven samostatný testovací server s aktuálními daty. Nejperspektivnějším řešením je kopie všech databází, týkající se testování, z produkčního serveru.
8.1.1.
Přenos databáze
Přenos databází z produkčního na testovací server se realizuje pomocí nastavených voleb v Microsoft SQL Server 2003. Je vytvořen tzv. lokální balíček, který obsahuje příkazy potřebné k uskutečnění přenosu. Pro každou databázi učiní lokální balíček následující kroky: • vytvoří zálohu produkční databáze do souboru, • odpojí všechny uživatele z testovací databáze, • nastaví testovací databázi do stavu offline, • obnoví testovací databázi z vytvořené zálohy, • odstraní soubor se zálohou, • upraví přihlašovací SQL účty na testovací databázi včetně přidání testovacího uživatele s administrátorskými právy, • přidělí databázový přístup na testovací databázi, • nastaví testovací databázi do stavu online.
8.1.2.
Přenos změn
V dalším kroku je potřeba aplikovat všechny změny, provedené v datové vrstvě při implementaci, na testovací server. Pro tyto účely se využívá komerční software DB Ghost od firmy Innovartis 5 . Program porovnává chybějící a změněné objekty (uložené procedury, funkce, pohledy, tabulky a triggery) mezi dvěma servery. V případě nalezených rozdílů, vytvoří soubor obsahující SQL příkazy pro aplikaci změn, tzv. delta skript. Tento skript se zarchivuje do složky a ručně spustí v příslušné databázi testovacího serveru.
8.1.3.
Naplnění nově vytvořených tabulek
Tímto jsme dospěli do stavu, kdy je testovací server připraven k testování a lze tedy naplnit novou strukturu tabulek původním nastavením. K tomu poslouží dva jednoduché skripty.
5
Více informací na http://www.innovartis.co.uk/
47
Obrázek 8.1.3‐1: Skript pro naplnění tabulky DDD
Skript zajišťující naplnění tabulky DDD. Respektuje zadané požadavky pro jednotlivou fakturační entitu se zohledněním nastavení sloupce IGH_InvoiceCalculationOptions.
Obrázek 8.1.3‐2: Skript pro naplnění tabulky DDP
Skript pro naplnění tabulky DDP. Vkládá detail DDD záznamu pouze fakturačním skupinám, které mají mít nastavené fixní datum splatnosti, v dřívější struktuře upřesněné ve sloupci IGH_InvoiceCalculationOptions.
8.2.
NUnit (regresní) testy
Po úspěšném naplnění tabulek lze přejít k otestování vytvořeného kódu. Jelikož počet faktur je rozsáhlý, cca 500 faktur za měsíc, volba druhu testování není jednoznačná. Musí splňovat možnost automatického testování včetně jeho opakování. Nabízí se možnost regresního testování, které umožňuje opakování testů změněného a upraveného kódu od předchozího testování. Vzhledem k náročnosti regresních testů je nezbytné testování softwaru automatizovat. Pro testování tříd jsou nejvhodnější unit testy. Napsané unit testy zaručují stoprocentní jistotu rozpoznané chyby. To znamená, že v případě změny rozhraní test selže, a tedy můžeme sledovat správnost vráceného výsledku. Tento přístup se nazývá testování bílé 48
skříňky, kdy má tester možnost přístupu ke zdrojovému kódu a může tak ověřovat vnitřní reakce systému. Tím se daleko lépe hledají a odhadují chyby. Nevýhodou tohoto způsobu testování je absence pohledu uživatele. [10, s. 156] Bezplatným nástrojem, který obsahuje podporu pro unit testy, je NUnit. Je kompletně napsán v jazyce C# a využívá mnoho .NET prvků, tedy i podporu vývojového prostředí Visual studio. Dokáže automaticky testovat algoritmy, které by jinak museli být otestovány ručním klikáním po GUI obrazovce. V případě IC NUnit znovu vytváří XML soubory faktur a porovnává s existujícími soubory, vytvořené poslední fakturací.
Obrázek 8.2‐1: Nástroj NUnit
V levé části je vypsaný seznam položek určených k testování. V případě selhání testu dojde k označení testovací jednotky červenou barvou. Zelenou barvou jsou označovány úspěšné testy, tedy že porovnávané XML soubory jsou shodné. V pravé části jsou zobrazené podrobnosti o neúspěšných testech a ve spodní části vypsané informace ze zásobníku.
8.2.1.
Výsledky regresních testů
Výsledky regresních testů dopadly úspěšně. Bylo nalezeno několik nesrovnalostí, které vyžadovaly drobné zásahy do kódu. Mezi chybami se objevily: • Chybějící specifikace pro fixní výpočet data splatnosti V tomto případě došlo k chybnému zpracování skriptu plnící tabulku DDP. Zároveň byla do metody CalculateBaseDate() přidána podmínka o chybějící specifikaci pro fixní záznam.
Obrázek 8.2.1‐1: Úprava metody CalculateBaseDate()
• Chybně vypočtené datum splatnosti Jednalo se o chybu vyhodnocení podmínky, kdy se místo hodnoty fixedDueDate vypočítala hodnota floatingDate v metodě CalculateBaseDate().
49
Obrázek 8.2.1‐2: Úprava metody CalculateBaseDate()
• Chybné datum splatnosti Šlo o změnu v nastavení hodnot původní struktury mezi vytvořením faktury a testovací fází. Nalezené chyby bylo nutné opravit a celý proces regresních testů zopakovat. [12, s. 5‐18]
8.3.
Akceptační testy
V této fázi také proběhlo testování funkcionality vytvořeného GUI rozhraní 6 . Smyslem je zajistit správné chování softwaru z pohledu uživatele. Tento způsob je nazýván testováním černé skříňky. Zaměřuje se na vstupy a výstupy programu bez znalosti zdrojového kódu. [10, s. 157‐158]
6
Současně probíhal vývoj GUI rozhraní, který není s ohledem na svůj rozsah součástí této práce.
50
9. Produkční verze Po úspěšném testování je aplikace s implementovanou změnou dokončena a může být nasazena do produkčního provozu.
9.1.
Přenos databáze
Před instalací aplikace je třeba, pro správnou funkčnost, připravit databázové prostředí. Samotný proces se velmi podobá přenosu změn na testovací server. Jelikož jsou z testovací fáze vytvořeny tzv. delta skripty, ke změně databáze stačí skripty, včetně dvou ručně vytvořených plnících skriptů, spustit v příslušné produkční databázi.
9.2.
Instalace
Pro snadnou rozšiřitelnost aplikace je nezbytné vytvořit instalační program, nejlépe v jednom souboru, který si později uživatelé sami spustí. Instalační soubor je automaticky vytvářen bezplatným integračním serverem CruiseControl.NET (CCNET) 7 . Integrační server automaticky kontroluje změny kódu projektu. V případě zjištěných změn automaticky celý projekt přeloží a vytvoří instalační soubor.
9.3.
Dokumentace
Ještě před finálním předáním aplikace uživatelům musí být vytvořen seznam provedených změn a zdokumentovaný popis obsluhy GUI rozhraní.
9.4.
Předání aplikace
Nyní zbývá poslední krok k dokončení celého vývojového procesu, tj. prostřednictvím e‐mailu informovat uživatele o nové verzi s odkazem na instalační soubor.
7
Více informací na http://confluence.public.thoughtworks.org/display/CCNET
51
10. Závěr Stanovený cíl práce, tj. zpracovaní řešení změny fakturační aplikace, se mi podařilo naplnit. Všechny změny, které byly definovány ve specifikaci požadavků, jsou úspěšně implementovány, otestovány a nasazeny v produkční verzi aplikace. V úvodní části práce jsem se zaměřil na čtyři existující zástupce metodik vývoje softwaru. Vybral jsem si metodiky Vodopádový model, Rational Unified Process, Extrémní programování a Feature Driven Development. Tyto metodiky jsem detailně popsal a následně jednu z nich ukázal na příkladu, jehož cílem bylo zpracovat změnu data splatnosti ve fakturační aplikaci. Hlavní přínos této práce spatřuji nejen ve shrnutí teoretických poznatků metodik vývoje softwaru, ale především ve zpracování praktického průběhu procesu vývoje softwaru, ve kterém jsem zužitkoval poznatky ze své dosavadní praxe ve společnosti ALPIQ ENERGY SE. V důsledku těchto zkutečností byly nalezeny drobné nedostatky v procesu, zejména ve fázi testování. Po nasazení aplikace objevilo fakturační oddělení nefunkčnost bankovních dní. Tento problém se podařilo vyřešit jednoduchou změnou v kódu; ovšem nemusel vůbec nastat, kdyby byl parametr (IsMaturityDaysWorking) zahrnut do fáze testování. Problém by nenastal, pokud by byla vytvořena sady unit testů pro každý parametr, a tato sada by byla spouštěna před každým nasazením nové verze do produkce.
52
11. Seznam použitých zdrojů [1] VONDRÁK, Ivo. Úvod do softwarového inženýrství. [online]. 2002, [cit. 2010‐10‐10]. Dostustupný na WWW:
[2] ROYCE, Winston W. Managing the development of large software systems. [online]. 1970, [cit. 2010‐11‐15]. Anglicky. Dostupný z WWW: [3] WIKIPEDIA. Vodopádový model. [online]. 2008, 26.8.2010 [cit. 2010‐12‐11]. Dostupný z WWW: [4] RATIONAL SOFTWARE WHITE PAPER. Rational Unified Process: Best Practices for Software Development Teams. [online]. 1998, [cit. 2010‐12‐15]. Anglicky. Dostupný z WWW: [5] BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. Praha: Oeconomica, 2009. 206 s. ISBN 978‐80‐245‐1540‐3 [6] BECK, Kent. Extrémní programování. Praha: Grada, 2002. 160 s. ISBN 80‐247‐0300‐9. [7] WIKIPEDIA. Extrémní programování. [online]. 2003, 22.9.2010 [cit. 2010‐12‐17]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Extrémní_programování> [8] BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů: Kategorizace, agilní metodiky, vzory pro návrh metodiky. Praha : Grada, 2005. 164 s. ISBN 80‐247‐1075‐7 [9] Interní dokument společnosti ALPIQ ENERGY SE. ALL_DueDates.doc [10] PALETA, Petr. Co programátory ve škole neučí aneb Softwarové inženýrství v reálné praxi. 1. vyd. Brno: Computer Press, 2003. 337 s. ISBN 80‐251‐0073‐1 [11] NAGEL, Christian a kolektiv. C# 2008 Programujeme profesionálně. 1. vyd. Brno: Computer Press, 2009. 1126 s. ISBN 978‐80‐251‐2401‐7 [12] Interní dokument společnosti ALPIQ ENERGY SE. Test050400.doc
53
12. Seznam použitých zkratek .NET C# CCNET COBRA COM DDD DDP FDD IC IGH OPM OTE RUP SAP SQL
‐ aplikační platforma společnosti Microsoft ‐ objektově orientovaný programovací jazyk ‐ CruiseControl.NET ‐ Common Object Request Broker Architecture ‐ Component Object Model ‐ prefix tabulky DDD_DueDateDefinition ‐ prefix tabulky DDP_DueDateParameter ‐ Feature driven development ‐ InvoicingClient ‐ prefix tabulky IGH_InvoicingGroupHeader ‐ odběrné a předací místo ‐ Operátor trhu s elektřinou ‐ Rational Unified Process ‐ společnost poskytující podnikový software ‐ Structured Query Language (strukturovaný dotazovací jazyk) pro práci s daty v relačních databázích UML ‐ Unified Modeling Language Visual Studio ‐ prostředí pro vývoj aplikací od společnosti Microsoft
54
