Proces vývoje programového systému

Proces vývoje programového systému Objektov orientovaný pístup vznikl v oblasti programování, ale postupn se rozšíil i do dalších fází vývoje programového systému. Vznikaly rzné metodiky objektové analýzy a návrhu programového systému. Metodiky návrhu programového systému definují: procesy množinu pedem stanovených krok pi návrhu SW, notaci jazyk - grafické symboly a textové znaky pro reprezentaci prvk softwarových systém, heuristiky množinu pravidel uplatovaných pi návrhu SW. Podrobné zvládnutí jedné i nkolika metodik pesahuje rámec tchto skript, podrobnjší popis mžeme nalézt napíklad v [OOMT]. Metodiky se vtšinou zamují na vývoj velkých programových systém a podrobn rozpracovávají jednotlivé fáze tohoto vývoje. Naším cílem je v tomto textu poskytnout studentm jen základní pedstavu o objektov orientované analýze, návrhu a implementaci programového systému (v prostedí Delphi nebo Javy). Notace UML Jednotlivé metodiky objektov orientované analýzy a návrhu (Coad-Yourdon, OMT - Rumbaugh, Booch, OOSE- Jacobson, OOMT) používaly rznou notaci pro vyjádení prvk návrhu. Pro výrobce CASE nástroj bylo problematické zvolit notaci, kterou budou podporovat. Proto firma Rational Software Corporation povolala 3 nejvýznamnjší pedstavitele objektov orientovaných metodik (Grady Booch, Jim Rumbaugh, Ivar Jacobson), kteí se spojili a spolen vypracovali jednotnou notaci nazvanou UML (Unified Modelling Language), která byla poprvé publikována v roce 1995. Notace se neustále rozvíjí a je podporována celou adou CASE nástroj. V souasné dob zahrnuje 10 druh diagram, které reprezentují rzné stránky návrhu programového systému. Dležité je si uvdomit, že UML je jen jazyk pro záznam analýzy a návrhu, ne metodika. Existují rzné metodiky používající jako notaci UML. Sama firma Rational Software Corporation vypracovala i metodiku pro vývoj SW, kterou distribuuje pod názvem Rational Unified Process (RUP). UML zahrnuje následující typy diagram: diagram užití (Use Case diagram, model jednání), diagram tíd (Class diagram), diagram objekt (object diagram), sekvenní diagram (sequence diagram), diagram spolupráce (collaboration diagram), diagram aktivit (activity diagram), stavový diagram (state diagram), diagram komponent (component diagram), diagram balík (package diagram), diagram nasazení (deployment diagram). Jednotlivé typy diagram reprezentují rzné dimenze pohledu na navrhovaný systém. Nkteré diagramy jsou statické (diagram tíd), jiné zachycují dynamiku v systému (stavový diagram). Nkteré diagramy se dívají na systém z lidského hlediska (diagram užití), jiné jsou spíše technologické (diagram nasazení, diagram komponent). V tomto textu se zamíme zejména na diagram užití, diagram tíd a sekvenní diagram. Poznámka: eské termíny pro jednotlivé typy diagram UML nejsou ješt ustálené. V rzných zdrojích se mžete setkat s rznými názvy, zejména pokud jde o diagram užití (Use Case diagram).

Diagram užití Diagram užití popisuje chování systému z hlediska uživatele. Modeluje úlohy, které vykonávají uživatelé, reprezentovaní aktory, s využitím navrhovaného SW. Každá úloha je reprezentována jako typ užití (Use case) a celý systém je souhrnem takových typ užití - modeluje se pomocí diagramu užití. Tento diagram popisuje i okolí navrhovaného systému a tím vymezuje jeho hranice. V diagramu užití se specifikuje: jaké typy uživatel (lidé i jiné systémy) používají systém, jaké innosti vykonávají jednotlivé typy uživatel, jaké innosti nemohou jednotlivé typy uživatel vykonávat. Diagram užití obsahuje tyto prvky: aktor, typ užití, vztah (relace). Aktor (Actor) Aktor reprezentuje prvek okolí systému, který bu informace dostává nebo je pijímá. Zakazn ik Obrázek 3.1 : Vyjádení aktora v UML Pokud vyjmenujeme všechny aktory, specifikujeme okolí systému a vymezíme tak jeho hranice. Aktorem nemusí být pouze živá osoba (obsluha, manažer, editel, aj.), ale také jiné systémy (externí), komponenty pro pístup k datm apod. Aktor se v UML oznauje panákem, u kterého se uvádí struný a výstižný popis (napíklad recepní, manažer, vedoucí, externí systém, bankovní systém atd.). Typ užití Typ užití specifikuje jeden prvek funkcionality systému, kterou využívá aktor (charakterizuje uritý zpsob použití systému uživatelem. Obrázek 3.2 : Vyjádení typu užití v UML Typ užití je chápán jako množina následných transakcí v systému, které v koneném dsledku P rohliz enizajez du vedou ke splnní požadované funkcionality. Znázornní typu užití v notaci UML je uvedeno na obrázku 3.2. Typ užití se oznaí jménem, je vhodné k nmu pipojit také slovní popis - scéná typu užití. Ve slovním popise se nepoužívají pojmy jako objekty, tídy, ale pouze pojmy z dané problémové oblasti (zákazník, rodné íslo, adresa atd.). Vztah (relace) Vztahy v diagramu užití mohou být dvojího typu: vztah mezi aktorem a typem užití vztah mezi typy užití Vztah mezi aktorem a typem užití Vztah mezi aktorem a typem užití vyjaduje tok informace mezi vnjším prvkem (aktorem) a typem užití aplikace. Nkdy se tento vztah oznauje jako komunikaní asociace

a znázoruje se šipkou mezi aktorem a typem užití. Definování tchto tok je velmi dležité, protože se tím vymezí hranice aplikace. Zakaznik ProhlizeniZajezdu Obrázek 3.3: Vztah mezi aktorem a typem užití v UML Vztah mezi typy užití Vztah mezi typy užití dává do uritého vztahu dva typy užití. Existují dva typy vztah mezi typy užití: Uses Extends Vztah uses Pi tvorb diagramu užití se mohou nkteré typy užití v rzných ástech navrhovaného systému opakovat - napíklad pihlášení do systému nebo výbr prvku ze seznamu. V tchto pípadech je lepší opakující se innosti vyjmout do samostatného typu užití a odkázat se na n v jiných typech užití, které je používají, pomocí relace uses. <<uses>> A Zakaznik UP rohliz enizajez du UP rohliz enihtm L Obrázek 3.4: Vztah uses v UML Vztah extends Vztah extends pedstavuje vztah generalizace - specializace v diagramech užití. Umožuje zjednodušit hlavní diagram užití, který se vyjádí pomocí obecných typ užití. Ty je možné v dalším kroku zpodrobnit a specifikovat u nich podmínné vtve, chybové stavy apod. Vztah extends mezi typy užití se používá v pípad: volitelného chování aplikace, chování za specifických podmínek, chování rzných tok aplikace podle volby aktora. Slovní popis typ užití (slovní scénáe) Diagram užití dává pehled o jednotlivých zpsobech použití navrhovaného systému. Každý typ užití je však teba doplnit slovním popisem. V popise se používají slova problémové oblasti nikoli programátorský žargon. Je vhodné popsat i kontroly formuláových položek, unikátnosti položek v systému a také chybové stavy a reakce systému na n.

<<extends>> UNovyZakaznik <<extends>> AZamestPobocky USpravaZakazniku <<extends>> UEdit acezakazn ika UZruseniZakaznika Obrázek 3.5: Vztah extends v UML Diagram tíd (Class diagram) Diagram tíd reprezentuje strukturu tíd v rámci systému, u každé tídy zachycuje atributy a metody a vyjaduje vztahy mezi tídami. Pedstavuje statický pohled na modelovaný systém. Nelze jím vyjádit interakce mezi tídami, ke kterým dochází v ase. Tento diagram se vytváí v etap analýzy a postupn se dopluje a zpesuje v dalších fázích tvorby systému (viz 3.2). Je také základem pro implementaci a nástrojem dokumentace. Mžeme tedy mluvit o rzných úrovních diagramu tíd: konceptuální (celková hierarchie tíd), specifikaní (tídy a rozhraní), implementaní (vetn skrytých atribut a všech metod). Základním prvkem diagramu tíd je tída. Tída se znázoruje obdélníkem, který se skládá ze tí ástí: jméno tídy, datové položky tídy - atributy, operace - metody tídy. Symbol pro tídu v notaci UML je uveden na obrázku 3.6, úplná notace zápisu tídy je uvedena na obrázku 3.7. Píklad tídy je zachycen na obrázku 3.8. Obrázek 3.6: Zápis tídy v UML Os oba rodnecis lo jm eno prijm eni vypis identifik aci() zj is ti vek() zadej udaje() v UML Obrázek 3.8: Píklad tídy Obrázek 3.7: Úplný zápis tídy

Asociace Když modelujeme njaký systém, identifikujeme v nm objekty a seskupíme je do tíd. Objekty však nejsou izolované. Každý objekt má v sob krom dat i operace s tmito daty, ale to pro celý systém nestaí. Objekt ke svému chování zpravidla potebuje využít schopností jiného objektu. Objekty jsou ve vzájemném vztahu (komunikují spolu, posílají si zprávy). Tyto vztahy modelujeme jako asociace. Asociace mže být analyticky chápána dvojím zpsobem - jako agregace nebo bžná asociace. Bžná asociace Pi bžné asociaci získává vnjší objekt referenci na vnitní objekt zvenku a doasn. Tento vnitní objekt tedy není vlastnictvím vnjšího objektu, ale je mu jen doasn zapjen - pedává se formou parametru zaslané zprávy (metody). Proto vnjší objekt nemže vnitní objekt vytváet ani rušit. Píklad bžné asociace mezi tídou a Auto je znázornn na obrázku 3.9. Asociace je dobré pojmenovat, piemž jméno vyjaduje význam daného vztahu (v našem pípad si pujcuje) Os oba rodneci s lo jm eno prijm eni vypis identifikaci() zjis ti vek() zadej udaje() 0..1 si pujcuje 1..* Auto SPZ typ denní s azba Obrázek 3.9: Bžná asociace Násobnost (Multiplicity) Násobnost uruje, kolik instancí jedné tídy má vztah k jedné instanci asociované tídy. Násobnost se asto popisuje jako jeden nebo mnoho. UML umožuje urit násobnost pesnji. Násobnost se znaí speciálními symboly na konci áry asociace. V tabulce 3.1 jsou uvedeny možnosti vyjádení násobnosti v UML. Symbol význam anglický výraz 1 práv jeden Exactly one 1..* jeden a více One or more 0..* nula a více Zero or more 0..1 nula nebo jeden Zero or one m..n urený interval (nap. 4..7) Specified range Tabulka 3.1: Možnosti vyjádení násobnosti v UML Na obrázku 3.9 je znázornna násobnost u asociace mezi tídou a Auto. Tento vztah lze interpretovat :" si mže pjit jedno a více aut, jedno auto má pjené žádná nebo jedna osoba". Role Role pedstavuje jeden konec asociace. Binární asociace má dv role. Pokud není explicitn uveden název role, chápe se jako role název tídy. Definování role pedstavuje pojmenování prchodu asociací od jednoho objektu k druhému. Na obrázku 3.10 jsou uvedeny role u asociace - Firma. vystupuje v roli zamstnance a firma vystupuje v roli zamstnavatele. Použití rolí není povinné, ale je mnohdy lepší a srozumitelnjší uvést

v modelu role než pojmenovávat asociaci. Na druhé stran je použití rolí tém nezbytné u asociace mezi objekty téže tídy viz obrázek 3.11. jméno píjmení rodné íslo +zamestnanec 0..* pracuje pro +zamest navat el 0..* Firma název Obrázek 3.10: Role v asociaci "pracuje pro" Firma nazev sidlo +m at esk á 1 +dc einná 0..* vlast ní Obrázek 3.11: Role u asociace na sebe sama Asociativní tída V uritých pípadech nastanou v analýze situace, kdy sama vazba mezi objekty by mla nést njakou informaci. Vezmme asociaci uvedenou na obrázku 3.10. Pokud osoba pracuje pro více firem (má více pracovních pomr), potom je teba u každého pracovního pomru sledovat od kdy probíhá, jakou funkci v tomto pracovním pomru osoba vykonává, jaký plat za to pobírá. Tyto informace nejsou ani atributem tídy ani atributem tídy Firma, ale vztahují se práv k asociaci mezi osobou a firmou, která pedstavuje daný pracovní pomr. Mžeme proto navrhnout asociativní tídu PracPomer, která tyto informace ponese. V diagramu tíd ji mžeme znázornit tak, jak je uvedeno na obrázku 3.12. jméno píjmení rodné íslo +zamestnanec 0..* pracuje pro +zamest navat el 0..* Firma název PracPomer datum nástupu funkce plat Obrázek 3.12: Asociativní tída Agregace Pokud vnjší objekt obsahuje vnitní objekt jako svou ást, tj. vnitní objekty skládají vnjší objekt, potom hovoíme o agregaci. Jedná se tedy o vztah skládání celku z ástí. Celek pitom odpovídá za vytvoení a zrušení svých ástí - objekt. ásti mohou nebo nemohou existovat

i mimo celek. Agregaci definujeme jako vztah celku k jedné ásti. Celku s více ástmi odpovídá více agregací. Agregace je vlastn druhem asociace, mžeme tedy definovat násobnost ásti v celku. Na obrázku 3.13 je znázornna agregace vyjadující, že objekt Auto obsahuje 4 objekty Kolo a 1 objekt Karoserie. Na obrázku 3.14 je píklad vyjadující, že objekt obsahuje jeden nebo více objekt Adresa (trvalé bydlišt, pechodné bydlišt apod.). Auto SPZ typ denní s azba 4 1 Kolo Karos erie rodneci slo jmeno prijmeni vypis identifikaci() zjisti vek() zad ej udaje() Adre sa 1..* typ ulicecislo mesto PSC stat Obrázek 3.13: Agregace ve tíd Auto Obrázek 3.14: Agregace ve tíd Generalizace - specializace rodnecislo jmeno prijmeni vypis identifikaci() zjisti vek() zadej udaje() Generalizace-specializace je druh abstrakce, který umožuje sdílet stejné vlastnosti a chování mezi tídami a pitom umožuje zachovat rozdíl mezi nimi. Vztah generalizace - specializace: je vztah mezi tídou a speciálním pípadem této tídy, je koncept užitený jak pro konceptuální modelování, tak pro implementaci, usnaduje modelování tím, že rozlišuje, co je stejné a ím se tídy liší, implementuje se pomocí ddinosti, pípadn delegace (viz 3.2.4.2) Zame stnanec ID funkce plat Obrázek 3.15: Píklad vztahu generalizace - specializace Rozhraní (interface) Rozhraní pedstavuje zpsob specifikace používání tídy. Pínosem objektov orientovaného pístupu je oddlení rozhraní od implementace. Nkteré objektov orientované jazyky umožují explicitn definovat rozhraní jako samostatnou entitu. Platí to pro jazyk Java (viz

6.6) i Object Pascal. V kontextu programovacích jazyk íkáme, že tída implementuje rozhraní (implements). V UML íkáme, že tída realizuje (realize) rozhraní. V diagramu tíd mžeme znázornit rozhraní nkolika zpsoby, které jsou uvedeny na obrázku 3.16 a 3.17. Na nich jsou zachyceny tídy Student a Ucitel. Každá z tchto tíd realizuje rozhraní Rozvrh, které poskytuje rozvrh aktuálních kurz, které student studuje (uitel vyuuje). <<Interface>> PrumPocetHodinTydne <<Interface>> PrumPocetHodinTydne <<realize>> <<realize>> Student Ucitel Student Ucitel Obrázek 3.16: Píklady zachycení rozhraní v UML Student PrumPocetHodinTydne PrumPocetHodinTydne Ucitel Obrázek 3.17: Jiná možnost zachycení rozhraní v UML Sekvenní diagram Sekvenní diagram reprezentuje zasílání zpráv mezi objekty v rámci systému. Ve 2. kapitole jsme uvedli, že základní charakteristikou objektu je jeho schopnost pijmout zprávu a reagovat na ni. V rámci této reakce mže probhnout nejen urité zpracování, ale objekt mže poslat zprávu dalšímu objektu. Dalším posíláním zpráv objektm vzniká sekvence posílání zpráv. Zápis takovéto sekvence je práv pedmtem sekvenního diagramu. Pi popisu chování aplikace pomocí sekvenního diagramu se vychází z diagramu užití (Use Case Diagram), kdy každý typ užití je popsán njakou sekvencí zasílání zpráv. Sekvenní diagram obsahuje následující prvky: objekt (mže být popsáno z jaké je tídy), zpráva mezi objekty, innost objektu a její popis. Objekt Objekt se v sekvenním diagramu oznauje pomocí svislé áry. Na vrcholu této áry se oznaí název objektu. Zpráva Zpráva se v sekvenním diagramu znázoruje pomocí šipky od objektu, který zprávu posílá, k objektu, který zprávu pijímá. Zprávy mžeme dlit na synchronní a asynchronní. Synchronní zpráva je taková, kdy vysílající objekt vykává na zpracování této zprávy a pokrauje v další innosti až po ukonení zpracování pijímajícího objektu. Pokud vysílající objekt pošle druhému objektu zprávu a neeká na její zpracování, potom se jedná o

asynchronní zprávu. V tom pípad pijímající objekt zpracovává zprávu a soubžn bží proces v objektu, který zprávu vyslal. Objekt, který zprávu pijal, mže napíklad výsledek své innosti poslat zpt objektu jako zprávu. V sekvenním diagramu se znázoruje sekvence zpráv daného typu užití. Vzniká tak jeden scéná zpracování. FormNovy Student : vytvo NovyStudent : Student Seznam : Sez nam Studentu "OK" pidej do seznamu Obrázek 3.18: Sekvenní diagram Na obrázku 3.18 je zachycen scéná typu užití "Pidání nového studenta do evidence student". Interakci zahajuje objekt FormNovyStudent, který posílá požadavek na vytvoení objektu NovyStudent tídy Student. Parametrem této zprávy jsou atributy objektu tídy Student, které byly zadány v polích formuláe. Formulá potom zasílá zprávu do objektu Seznam tídy SeznamStudentu a požaduje pidání nového studenta, piemž parametrem je instance práv naplnného studenta (na obrázku není vstupní parametr objekt znázornn). Pokud má objekt schopnost pijímat uritou zprávu, znamená to, že na tuto zprávu objekt spustí nkterou z metod. Pokud u objekt sekvenního diagramu máme ureny tídy, ke kterým objekty patí, potom mžeme na základ zpráv, které objekt pijímá, urovat jaké metody musí objekt mít. Znamená to, že u objekt, u kterých koní zpráva, musí existovat metoda, která je piazena k této zpráv. Vtšinou je dobré používat stejný název jak pro metodu, tak pro zprávu. Zpráva zasílaná objektu má své parametry jak vstupní, tak výstupní. Tyto parametry se poté stávají vstupními a výstupními parametry dané metody. Mohou se vyznait do diagramu, nebo se popisují zvláš. Sekvenní diagramy pomáhají odhalovat chování aplikace (metody objekt), ale také kompetence objekt za jednotlivé innosti (kdo co bude konat sám a k emu použije jiný objekt). Diagram spolupráce (Collaboration diagram) Diagram spolupráce zachycuje interakce mezi objekty v systému. V tomto ohledu je obdobný sekvennímu diagramu. Diagram objekt (Object diagram) Diagram objekt znázoruje vztahy objekt v systému. Je odvozen z diagramu tíd a pedstavuje jeho instancializaci. Používá se spíše jako píklad a ovení správnosti diagramu tíd.

Stavový diagram (State Transition diagram) Stavový diagram znázoruje jednotlivé stavy, kterými prochází uritý objekt v závislosti na událostech. Diagram aktivit (Activity diagram) Diagram aktivit umožuje modelovat obchodní procesy. Diagram komponent (Component diagram) Diagram komponent ukazuje vzájemné závislosti softwarových komponent. Diagram balík (Package diagram) Diagram balík ukazuje rozdlení systému do modul. Diagram nasazení (Deployment diagram) Diagram nasazení znázoruje konfiguraci jednotlivých prvk systému pi instalaci a bhu. Podrobnjší popis jednotlivých diagram naleznete v [WWWDrbal], [OOMT ], [MyslUML ], [ZaklUML ] a dalších zdrojích. Fáze vývoje programového systému V tomto odstavci je uveden postup vývoje programového systému s následujícími charakteristikami: programový systém menšího rozsahu, draz kladen na objektov orientovaný vývoj, nezávislost na konkrétní metodice, snaha o zobecnní. Postup mžeme rozložit do následujících fází: 1. Píprava plánu projektu 2. Specifikace požadavk 3. Analýza 4. Návrh 5. Implementace 6. Testování 7. Nasazení 8. Údržba Píprava plánu projektu V této fázi je teba pipravit plán, podle kterého bude projekt probíhat. Problematika ízení projekt je zpracována v ad publikací a na VŠE je náplní samostatného pedmtu "Projektování a ízení IS" a pedmtu " ízení projekt". Pro naše úely postaí, když si uvdomíme nutnost této fáze a základní innosti, které je teba v této fázi provést: urení vedoucího projektu, urení len týmu, definování termín dokonení jednotlivých fází a výstup z tchto fází, Pechody z jedné fáze do druhé jsou charakterizovány tzv. milníky (milestone), které specifikují podmínky, za kterých lze fázi ukonit. definování metrik kvality, definování ekonomických charakteristik (náklad, pínos).

Závrem této fáze je rozhodnutí, zda je projekt za daných požadavk, dostupných technologií, zdroj a rozpotu možné realizovat. Specifikace požadavk Díve než zahájíme analýzu, návrh a kódování, je teba identifikovat požadavky, které má program splovat. Je teba zjistit, jaké funkce bude zákazník, respektive uživatel, s programem realizovat, za jakých podmínek, v jakém prostedí apod. Je teba sepsat požadavky systematicky a pehledn. Požadavkem se rozumí požadavek na funkcionalitu budoucí aplikace. Musí být vyjáden pouze v pojmech problémové oblasti, aby jim uživatel dobe rozuml. V mnoha pípadech je sám uživatel spoluautorem tohoto dokumentu. Výsledkem by mla být specifikace požadavk, která mže mít napíklad strukturu uvedenou v tabulce 3.2. Rozsah, podrobnost a forma takového dokumentu bývá zpravidla pedmtem diskusí. Nkteré firmy dávají pednost textovým dokumentm, jiné diagramm. Dokument Specifikace požadavk Identifikace aplikace charakteristika aplikace a pro koho je urena Funkce aplikace hlavní funkce, které má aplikace mít a jejich struný popis Popis uživatel hlavní skupiny uživatel, kteí budou program používat, popisuje, jak jej budou používat vetn jakých funkcí Prostedí specifikace operaního systému, hardware apod. Požadavky na UI specifický vzhled a ovládání, hardwarová omezení SW interface definuje interface na jiné systémy a vlastní interface Omezení veškerá omezení pokud jde o technologie, programovací jazyky apod. Pedpoklady a závislosti napíklad komunikace s externím SW Výkonnost požadavky na dobu odezvy, poet uživatel apod. Obchodní procesy definuje vztah funkcí programu k procesm v organizaci Tabulka 3.2: Specifikace požadavk Analýza Abychom mohli navrhnout programový systém, je teba pochopit danou problémovou oblast. To je pedmtem fáze analýzy. Této fáze se aktivn úastní uživatelé systému. Základem této fáze pi objektov orientované analýze je tvorba diagram užití (Use Case Diagram dle UML). Tyto diagramy jsou podrobn popsány v 3.1.1. Na základ analýzy jednotlivých typ užití se vytváí analytický návrh struktury tíd (diagram tíd viz. 3.1.2). Tento pohled na problémovou oblast je statický, a proto bývá doplován scénái pro jednotlivé typy užití, které se vyjadují pomocí sekvenních diagram (viz. 3.1.8) Fáze analýzy zahrnuje zejména následující kroky: definování typ užití a vytvoení diagramu užití, vytvoení analytického diagramu tíd, vytvoení sekvenních diagram pro každý typ užití, definování test. Již v této fázi je dobré navrhnout testy, na kterých má být vyvíjený SW testován. Návrh test v ranných fázích vývoje má nkolik pedností. Jednak svdí o snaze vyvinout kvalitní SW, jednak vede vývojáe k vytvoení spustitelné verze. Pokud je realizován iterativní vývoj, potom výsledkem každé iterace by mla být spustitelná verze programu, která musí být otestována. Testy mají provit jak vlastní funknost aplikace, tak i uživatelské rozhraní. Vasným testováním uživatelského rozhraní samotnými uživateli, lze pedejít mnohým zklamáním na konci projektu.

Návrh struktury tíd Cílem fáze analýzy je definovat strukturu tíd objekt a u každé tídy definovat atributy a metody. Nalezení správných tíd, urení relevantních atribut a metod, definování vztah mezi tídami, to vše je dosti nároný proces, který je do znané míry ovlivnn zkušenostmi analytika. Pesné postupy, jak se dobrat výsledné struktury tíd, metodiky vtšinou neuvádjí. Poskytují jen návody i doporuení. Vtšinou se doporuuje provádt analýzu a návrh iterativn, nartnout základní strukturu tíd, tu upesovat a rozvíjet. Vhodná je pro tuto fázi práce v týmu, kdy lenové týmu spolen analyzují danou oblast a navrhují tídy. Strukturu tíd je teba zdokumentovat, nejlépe pomocí CASE nástroje, který podporuje standardní notaci napíklad UML. Výhoda použití CASE nástroje spoívá v možnosti snadných úprav modelu: v jednotlivých iteracích fáze analýzy a návrhu, pi pechodu ke kódování, kdy pistupuje ada implementaních charakteristik, po nasazení systému pi jeho údržb a rozvoji. Východiskem pro návrh tíd a vztah mezi nimi je specifikace požadavk a diagramy užití. Rozborem tchto dokument získáme kandidáty na tídy. Mžeme postupovat následujícím zpsobem, který je po zjednodušení pevzat z [ZaklUML ]: 1. Výbr kandidát Proítáme specifikaci požadavk a typy užití a vybíráme všechna podstatná jména, která si vypíšeme. 2. Rozlišení kandidát na tídy a kandidát na atributy Mezi vybranými podstatnými jmény se snažíme odlišit kandidáty na tídy (entita, která mže sama o sob existovat - napíklad Student) a kandidáty na atributy urité tídy - podstatné jméno, které samostatn neexistuje, ale je vlastností njaké jiné entity - napíklad píjmení studenta. 3. Záznam tíd Výsledek tohoto procesu mžeme zaznamenat napíklad na karty. Pro každou tídu pipravíme kartu, na níž uvedeme jméno tídy a atributy nebo mžeme zapsat kandidáta na tídu následujícím zpsobem: Student = ( rodné íslo, jméno, píjmení, adresa trvalého bydlišt, adresa pechodného bydlišt, fakulta, obor studia..atd.) Student rodné íslo jméno píjmení adresa trv. bydlišt adresa pech.bydlišt fakulta obor studia 4. Provení, zda nemá být atribut tídou Volba, zda má být uritý prvek tídou a nebo atributem mže být nkdy obtížná, v každém pípad nemusí být konená. Prvek navrhneme napíklad jako atribut, ale ukáže-li se pozdji, že je to vhodnjší, mžeme z nj udlat tídu. Píkladem mže být teba rodné íslo. Pokud budeme chtít provádt speciální kontroly rodného ísla,

poskytovat jej v rzných formátech (s lomítkem, bez lomítka apod.), vypoítávat vk, bude možná vhodnjší udlat pro nj tídu a do objektu tídy Student vložit instanci této tídy. 5. Dv tídy nebo dv instance téže tídy Je teba také odlišit, kdy dva prvky pedstavují jen dv instance téže tídy a kdy je teba skuten vytvoit dv tídy. Mžeme si to ukázat na píklad adresy. V našem výtu atribut tídy Student se objevily atributy: adresa trvalého bydlišt, adresa pechodného bydlišt Po hlubší analýze dojdeme k závru, že pro n bude vhodné vytvoit tídu. Tato tída bude mít nkolik atribut (ulice, íslo, msto, ps, stát). Všechny tyto atributy jsou jak u trvalého bydlišt, tak u pechodného bydlišt. Také metody, které tída Adresa bude poskytovat, se nijak neliší pro adresu trvalého a adresu pechodného bydlišt. Proto vytvoíme tídu jednu. Do tídy Student potom vložíme dv instance téže tídy Adresa. 6. Kandidáti na vztah generalizace-specializace Pokud se ve více tídách opakují tytéž informace, mžeme uvažovat o vytvoení obecné tídy. Tuto tídu vybavíme atributy a metodami, které jsou spolené a od ní odvodíme speciální tídy. Pokud v našem pípad krom student budeme evidovat i uitele, ukáže se, že i ve tíd Uitel budou atributy jako rodné íslo, jméno, píjmení, adresa trvalého bydlišt, adresa pechodného bydlišt. Potom bude možná vhodné vytvoit tídu s atributy rodné íslo, jméno, píjmení, adresa trvalého bydlišt, adresa pechodného bydlišt. Od této tídy potom odvodíme speciální tídy Student a Uitel. 7. Vyhledání odvozených tíd typu seznam Zárove hledáme i odvozené tídy (kolekce) - seznam student, seznam pedmt. U každé tídy je teba si všímat charakteristik uvedených v tabulce 3.3 Charakteristika Jméno tídy Vztah k jiným tídám Poznámka Je teba dát tíd smysluplné jméno, které jasn vyjaduje informace, které tída pedstavuje Pokud zmníte obsah tídy, možná bude teba zmnit i její jméno, aby bylo konzistentní s obsahem Je teba zkoumat, zda navrhovaná tída není speciálním pípadem njaké již definované tídy a nebo naopak, jestli nkolik tíd neobsahuje spolené vlastnosti, které by bylo možné piadit njaké obecnjší tíd. Podtídy nemá smysl vytváet za každou cenu, ale jen v tch pípadech, kdy je to smysluplné. Funkcionalita tídy Jde o to urit co navrhovaná tída: 1. zná (jaké má vlastnosti) 2. dlá (jaké má metody) Spolupráce Zajímáme se o interakci s ostatními tídami. Pokud dv tídy píliš mnoho spolupracují, bude možná vhodnjší vytvoit z nich jedinou tídu. Tabulka 3.3: Charakteristiky uvažované pi návrhu tíd Navržená struktura tíd musí být porovnána s diagramy užití. Nastupují otázky typu: Pokryjí navržené tídy všechny definované typy užití? Poskytuje navržená struktura tíd prostor pro další rozšíení a pidání funkcí? Pi návrhu tíd se snažíme o jednoduchost. Pínos objektov orientovaného pístupu spoívá v možnosti rozdlit problém na malé ásti, které mohou stát samostatn a pitom reprezentují ucelenou funknost. Je lepší navrhnout více malých objekt, které reprezentují jasn a dobe

jednu vc, než jeden velký nepochopitelný a složitý objekt. Navíc malé, jasné objekty, lze snadno znovupoužít. Návrh Fáze návrhu bývá nkdy rozdlována na dv fáze : systémový návrh, objektový návrh. V rámci systémového návrhu je teba zvolit implementaní prostedí a architekturu aplikace. Fáze objektového návrhu definuje tídy a vztahy mezi tídami, algoritmy metod a uživatelské rozhraní. Volba implementaního prostedí, architektury a vytvoení i využití aplikaního rámce V tomto kroku je teba uinit tzv. implementaní rozhodnutí, tj. definovat: platformu - operaní systém, rozhodnout o technologické architektue aplikace: o jednouživatelská (desktop) aplikace, o aplikace typu klient/server s tlustým klientem (nap. pod Windows), o internetová aplikace, o vícevrstvá aplikace snadno penositelná z tlustého na tenkého klienta vybrat programovací jazyk a vývojové prostedí, vytvoit a nebo použít aplikaní rámec (application framework). V závislosti na technologické architektue aplikace je ureno uživatelské rozhraní: klasické aplikace - textové UI, grafické UI rozhraní akceptované prohlížeem. Pi vytváení uživatelského rozhraní aplikace se zpravidla využívá celá ada již hotových objekt, jak jednotlivých prvk jako jsou tlaítka, editaní pole apod., tak i formulá i celých šablon aplikací. Tyto prvky tvoí tzv. aplikaní rámec. Pokud jsme vybrali programovací jazyk a vývojové prostedí, které již tyto objekty má vytvoeny, staí je jen použít. Pokud ne, je teba tyto prvky nejdíve naprogramovat. Takovým aplikaním rámcem je teba : knihovna VCL v Delphi, knihovna Swing pro Javu, ActiveX prvky, CSS pro WWW stránky. Aplikaní rámec bývá dodáván jako knihovna tíd (MFC pro C++ nebo Swing pro Javu, kde je souástí základního SDK) a nebo je souástí vizuálních vývojových nástroj jako jsou Delphi, JBuilder, NetBeans a další. S pomocí tchto nástroj lze velmi rychle vytvoit prototypy aplikací a otestovat uživatelské rozhraní pímo koncovými uživateli. Objektový návrh Ve fázi objektového návrhu se pidávají další implementaní tídy, optimalizují se algoritmy a datové struktury. V této fázi pracujeme s diagramy vytvoenými ve fázi analýzy a dále je doplujeme o prvky, které jsou již implementan závislé. Ve fázi návrhu pecházíme z aplikaní oblasti do poítaové oblasti. Objekty identifikované pi analýze tvoí kostru návrhu, ale návrhá musí volit mezi rznými zpsoby, jak je implementovat. Hlediskem pitom je minimalizace doby provádní, pamti a další metriky. Operace identifikované pi

analýze je teba vyjádit ve form algoritm. Složité operace musí být dekomponovány na jednodušší. Je teba zavést nové objekty pro uchování mezivýsledk. innosti provádné ve fázi objektového návrhu mžeme rozdlit do tchto krok: 1. Práce s rznými typy diagram, kontroly konzistence a pevod do algoritm Navzájem porovnáváme jednotlivé diagramy a snažíme se nalézt rozpory. 2. Návrh algoritm pro implementaci operací Každá operace musí být formulována jako algoritmus. Je teba: vybrat nejvýhodnjší algoritmus, zvolit pro daný algoritmus vyhovující datové struktury, definovat nové interní tídy a operace, je-li teba, piadit odpovdnost za operace jednotlivým tídám. 3. ešení pístupu k datm Je teba vyešit uložení dat. Zvolit bu uložení v souborech a nebo použít databáze. V tom pípad je teba vytvoit datový model, definovat strukturu databáze a vytvoit vrstvu mapující data objekt do databáze. 4. Implementace ízení interakce s jinými objekty Vztahy mezi tídami, které byly v diagramu tíd znázornny jako asociace, je teba implementovat. Musí pro n existovat metody (je teba rozhodnout v kompetenci které tídy budou), objekt se kterým se komunikuje musí být pedán jako parametr dané metod. 5. Provení struktury objekt pro zavedení ddinosti Peskupení tíd V nkterých pípadech je stejná operace definována v rzných tídách a mohla by být zddna. Staí napíklad trochu pozmnit operaci nebo návrh tíd a je možné využít operaci z tídy pedka bez jejího pedefinování. Abstraktní tídy Je teba projít tídy a hledat pípadné abstraktní tídy, které budou implementovat spolenou základní funknost. Rozhraní Pokud vývojové prostedí podporuje rozhraní, je teba provit spolené operace a pípadn je vylenit do rozhraní. Využití delegace pro sdílení implementace Ddinost je mechanismus pro implementaci generalizace - specializace v pípadech, kdy chování nadtídy je sdíleno ve všech podtídách. Použití ddinosti je oprávnné v tch pípadech kdy podtída je specializací nadtídy i v analytickém smyslu. Operace podtídy pepisují operace nadtídy a pípadn pidávají nco navíc. Pokud tída B ddí po tíd A, pedpokládáme, že každá instance tídy B je i instancí tídy A. Nkdy ovšem programátoi používají ddinost jako implementaní techniku bez zámru garantovat stejné chování tíd v ddické hierarchii. Tak se stává, že nová tída ddí z tídy pedka urité chování, ale jinak jsou tídy úpln rozdílné. To mže vést k problémm v jiných operacích dané tídy, které mohou psobit nechtné chování. Jako píklad takové ddinosti implementace, kterému je lépe se vyhnout, mžeme uvést implementaci tíd List a Stack. Tída List reprezentuje datovou strukturu typu spojového seznamu, do které je možné pidávat prvky v kterémkoli míst, mazat jakýkoli prvek. Naproti tomu Stack reprezentuje zásobník, u kterého je pesn stanoven zpsob pidávání a odebírání prvk - prvky se pidávají a odebírají vždy na jednom konci - vrcholu zásobníku. Pokud máme implementovat tídu Stack a máme již tídu List, možná bychom ji chtli využít a navrhli bychom tídu Stack jako potomka tídy List. V tom pípad ovšem zddíme do tídy Stack i operace pro pidání

prvku, vymazání prvku z kteréhokoli místa. Potom se tída Stack nebude chovat tak, jak bychom oekávali. V pípadech, kdy chceme použít ddinost jako implementaní techniku, dosáhneme stejného cíle bezpenjším zpsobem pomocí vloženého objektu. Tento zpsob se nazývá delegace, nebo objekt pro uritou innost vyvolá metodu jiného objektu, který je jeho souástí a nebo s kterým je spojen. Toto ešení je ilustrováno na obrázku 3.18. [Merunka] List add() rem ove() first () last () Stack Stac k push() pop() List add() remove() first() last() push() pop() Obrázek 3.18: Nesprávné použití ddinosti, ešení pomocí vloženého objektu 6. Návrh asociací Asociace jsou konceptuální entity ve fázi analýzy. Pi návrhu je teba urit strategii, jak je implementovat. Tato strategie mže být bu univerzální, použitá pro všechny asociace v modelu, a nebo se pro rzné asociace použijí rzné techniky. V analytické fázi vtšinou pedpokládáme, že asociace jsou obousmrné. Pokud je však asociace jednosmrná, mže být její implementace jednodušší. Bute ovšem opatrní, protože se tato situace mže zmnit. Napíklad pidání nové operace si vyžádá vytvoit asociaci obousmrnou. Pi prototypování používáme vždy obousmrnou asociaci, protože tak mžeme snadno pidat nové chování. Jednosmrné asociace mohou být implementovány jako ukazatel - atribut, který obsahuje referenci na objekt. Pokud je násobnost asociace 1, jde o jednoduchý ukazatel (obrázek 3.19). Je-li násobnost N, jde o množinu ukazatel. Jsou-li objekty v asociaci uspoádané, je lepší použít seznam. zamestnavatel pracuje pro 1 Firma Obrázek 3.19: Implementace jednosmrné asociace pomocí ukazatele

Obousmrné asociace Mnoho asociací se prochází obma smry, i když ne se stejnou frekvencí. Obousmrnou asociaci mžeme realizovat jedním z následujících 3 zpsob: [1] asociaci implementujeme jako atribut (ukazatel) jen v jednom smru a pi obráceném prchodu provádíme vyhledání - tento zpsob je vhodný jen pro pípady, kdy zptný prchod není astý [2] implementujeme atributy (ukazatele) v obou smrech ( viz obrázek 3.20), tento zpsob dovoluje rychlý pístup, ale pi zmn jednoho ukazatele je tena zmnit i ukazatel druhý zamest navat el pracuje pro 1 Firma zamestnanci Seznam Zamestn ancu kolekce of zamestnanec Obrázek 3.20: Implementace obousmrné asociace [3] implementujeme asociaci jako zvláštní objekt - asocianí tídy (obrázek 3.21) Firma Firma Obrázek 3.21: Implementace obousmrné asociace asocianí tídou 7. rozhodnutí o reprezentaci objekt Implementace objekt je nkdy jasná, nkdy je teba se rozhodnout pro nkterou z alternativ. Atribut mžeme reprezentovat rznými datovými typy (napíklad íslo pracovníka jako integer nebo string). Pro uritý atribut mžeme definovat také samostatnou tídu. Na obrázku 3.22 je znázornna tída Usecka, definovaná 4 souadnicemi. Jinou možností urení úseky je definovat tídu Bod a úseku potom složit ze dvou instancí tídy Bod tak, jak ukazuje obrázek 3.23. Obrázek 3.23: Úseka složená ze dvou bod

Us ecka b 1 x1 : real y1 : real x2 : real y2 : real U s ecka b 2 Bod x : real y : real Obrázek 3.22: Úseka se 4 atributy souadnic 8. Doplnní vrstvy uživatelského rozhraní Diagramy vytvoené ve fázi analýzy je teba doplnit o objekty uživatelského rozhraní, zejména o tídy formulá. 9. Seskupení tíd do modul Ve fázi návrhu bychom mli rozhodnout o rozdlení aplikace do komponent a vytvoit diagram komponent. Implementace Na zaátku implementace je teba urit poadí implementace jednotlivých tíd. Probíhá-li fáze implementace v iteracích, je teba urit, které tídy implementovat v jednotlivých iteracích. K tomu pistupuje ješt problém týmové práce. Jak rozdlit tídy mezi jednotlivé leny týmu? Jak se vypoádat se vzájemnými závislostmi tíd? Je dobré dodržovat pravidlo, že každá iterace reprezentuje verzi programu, kterou lze testovat vi typm užití. Doporuení pro programování Jak si mohl vyzkoušet každý lyža, šachista i kucha, existuje velký rozdíl mezi tím, že nkdo nco zná, a nkdo to umí. S psaním objektov orientovaných program je to podobné. Nestaí znát pouze principy, ale je teba mít dovednosti, jak navrhnout tídy, jejich vazby, jak je spojit do programu, který dlá to, co po nm požadujeme. Zkušený programátor dodržuje principy, které umožují psát itelné a rozšiitelné programy. Dobrý programovací styl je dležitý ve všech metodách programování, ale v objektov orientovaném návrhu nabývá na vtší dležitosti, protože cílem objektov orientovaného pístupu je produkovat znovupoužitelné a rozšiitelné programy. V objektov orientovaném programování platí obecné programovací zásady a doporuení, ale pidávají se i nové zásady, které jsou spojeny s novými rysy OOP jako je ddinost apod. Uvedeme nejdležitjší zásady v rámci následujících kategorií: znovupoužitelnost, rozšiitelnost, robustnost, programování ve velkém. Pravidla pro zajištní znovupoužitelnosti: 1. Realizujte koherentní metody, tj. metody, které provádjí jednu funkci a nebo skupinu tsn svázaných funkcí. 2. Realizujte malé metody. Je-li metoda velká, rozdlte ji na menší, které budou lépe znovupoužitelné. 3. Realizujte konzistentní metody, to znamená, že stejné metody by mly mít stejná jména, podmínky, poadí argument, návratové hodnoty, chybové stavy. 4. Oddlte ídící a implementaní metody. ídící metody pijímají rozhodnutí, drží celkový kontext, volají implementaní metody, kontrolují stav vetn chybového. Implementaní metody provádjí specifické operace bez rozhodování pro. Provádjí výpoet pro pln definované parametry.

5. Realizujte metody pln pokrývající danou oblast. Pokud se vstupní podmínky mohou vyskytovat v rzných kombinacích, obslužte všechny možnosti. 6. Rozšite metodu, jak je to jen možné. Snažte se zobecnit parametry, vstupní podmínky, omezení, pedpoklady, za jakých metoda pracuje, a kontext, v jakém pracuje. 7. Realizujte smysluplné akce pro nulové a extrémní hodnoty. asto je možné udlat obecnjší metodu jen s malým navýšením kódu. 8. Vyhnte se globálním informacím. Minimalizujte vnjší vazby, místo toho použijte parametry. 9. Vyhnte se módm. Funkce, jejichž chování velmi závisí na kontextu, jsou tžko znovupoužitelné. 10. Využívejte ddinost. Spolený kód implementujte jako metodu pedka a u potomk ji pedefinujte. 11. Využívejte vkládání objekt. Pravidla pro zajištní rozšiitelnosti: 1. Dodržujte zapouzdení tíd. 2. Ukryjte datové struktury. 3. Vyhnte se procházení více link. Metoda musí mít jen omezenou znalost objektového modelu. 4. Rozlišujte public a private operace. Pravidla pro zajištní robustnosti: 1. Program se musí bránit chybám - kontrolujte vstup. 2. Optimalizujte program až po té, co bhá - optimalizujte jen asto volané funkce. 3. Kontrolujte parametry metod 4. Pokud je to možné, používejte pro uchování dat dynamické promnné, které nevyžadují pedem definované meze. 5. Vybavte program promnnými pro ladní a monitorování bhu. Pravidla pi programování ve velkém - na velkých projektech, v týmu: 1. Nepedbíhejte s programováním - nejprve je teba kompletn dokonit návrh. 2. Realizujte pochopitelné metody. 3. Realizujte itelné metody. 4. Používejte stejná jména v kódu jako v objektovém modelu. 5. Volte správná jména - ujistte se, že pesn vyjadují operace, tídy, atributy, používejte dané konvence. 6. Seskupte tídy do modul. 7. Dokumentujte tídy a metody. Závrené testování I když testy provádíme po každé iteraci fáze implementace, je teba provést i závrené testování, které má odhalit chyby ped nasazením systému. Nasazení a údržba Problematika zavádní programových systém a jejich údržby pesahuje rámec tchto skript. Píklad Cestovní kancelá Jednotlivé fáze vývoje programového systému, které byly uvedeny v 3.2 budeme demonstrovat na píklad ešení aplikace pro cestovní kancelá. Zárove na dané problémové oblasti ukážeme i píklady jednotlivých diagram UML. Fázi plánu projektu popisovat nebudeme.

Píklad Cestovní kancelá - specifikace požadavk Výsledkem fáze specifikace požadavk je dokument Specifikace požadavk, který mže mít strukturu uvedenou v tabulce 3.4. Specifikace požadavk Identifikace Funkce aplikace Popis uživatel Prostedí Požadavky na UI Aplikace Cestovní kancelá je urena pro podporu innosti menší cestovní kanceláe. Bude umožovat evidovat a nabízet zájezdy, evidovat zákazníky a zamstnance, realizovat objednávky zájezd. Evidence zájezd Cestovní kancelá poskytuje rzné druhy zájezd po celém svt. Jejich výbr je každoron upravován podle analýz prodeje z minulého roku a prognóz do budoucna. Každý zájezd, je-li v daném roce aktivní, je složen z turnus. Turnusy se liší termínem, cenou a kapacitou. K turnusm jsou piazeni instruktoi. Evidence zákazník Cestovní kancelá eviduje své zákazníky, kterými jsou soukromé osoby. Eviduje u nich, zda v minulosti již njaký zájezd zakoupili. Evidence zamstnanc Cestovní kancelá eviduje také své zamstnance (vedení, zamstnanci na pobokách, zamstnanci správy zájezd, instruktoi) Objednávky zájezd Registrovaní zákazníci se pihlašují na zájezdy (turnusy) Uživateli aplikace budou následující typy: pracovníci vedení, zamstnanci na pobokách, zamstnanci správy zájezd, instruktoi zájezd, zákazníci. Vedení firmy pijímá strategická a operativní rozhodnutí, provádí analýzy prodej. Zamstnanci na pobokách spravují data o zákaznících a zajišují pihlašování na zájezdy. Zamstnanci správy zájezd vytváejí a editují zájezdy, turnusy, piazují instruktory k turnusm zájezd. Zákazníci si mohou prohlížet nabídku zájezd. operaní systém Windows, jednouživatelská aplikace klasická Windows aplikace, použití menu, panelu nástroj, jednotný vzhled formulá aplikace, ovládání pomocí myši i klávesnice generování HTML dokument programovací jazyk Object Pascal nebo Java ukládání do soubor SW interface Omezení Pedpoklady a závislosti Výkonnost nepedpokládají se velké objemy dat Tabulka 3.4: Specifikace požadavk aplikace Cestovní kancelá Aplikace Cestovní kancelá - diagramy užití Po fázi specifikace požadavk následuje fáze analýzy, ve které se nejprve zamíme na tvorbu diagram užití. Na obrázku 3.24 je uveden diagram užití pro aplikaci Cestovní kancelá na nejvyšší úrovni. Hlavní diagram užití mžeme dále rozpracovat napíklad tak, jak je uvedeno na obrázku 3.25 a 3.26.

AZakaznik UProhlizeniZajezdu USpravaZakazniku AZamestPobocky URezervaceZajezdu USpravaZajezdu AZa mestzajezd Odd USpravaTurnusu UPrirazeniInstruktora APersonalista USpra vazamest nancu Obrázek 3.24: Diagram užití pro aplikaci Cestovní kancelá- hlavní

<<extends>> UNovyZakaznik <<extends>> AZamestPobocky USpravaZakazniku <<extends>> UEdit acezakazn ika UZruseniZakaznika Obrázek 3.25: Podrobnjší rozvedení typu užití USpravaZakazniku <<e xtends >> <<extends>> UNovyZajezd USpravaZajezdu U Edit acezajezdu <<extends>> AZamestZajezd Odd <<extends>> UZruseniZajezdu USpravaTurnusu <<extends>> UN ovyturn us <<extends>> UEditaceTurnusu UPrirazeniInstruktora UZruseniTurnusu Obrázek 3.26: Podrobnjší rozvedení typu užití USpravaZajezdu Identifikovali jsme 4 aktory - zákazník, zamstnanec poboky, zamstnanec zájezdového oddlení a zamstnanec personálního oddlení. Diagram užití je vytvoen v CASE nástroji Rational Rose, jehož ovládání je popsáno v píloze 1. Diagram užití by ml být doplnn

o slovní popis jednotlivých typ užití. Píklad slovního popisu typu užití je uveden na obrázku 3.27. Pípad užití UNovyZakaznik - slovní popis (scéná) Obsluze se zobrazí formulá pro zadávání položek zákazníka: rodné íslo, jméno, píjmení, adresa - ulice, msto, ps. Obsluha zadává údaje, po volb založit zákazníka se provádjí kontroly na povinné položky - rodné íslo, jméno, píjmení - (chyba 1), rodné íslo se kontroluje podle pravidel kontroly rodného ísla (chyba 2). Program kontroluje, zda zákazník s daným rodným íslem v systému není (chyba 3). Zákazník se uloží. chyba 1 Obsluze se oznámí "Je teba vyplnit povinné položky" a systém se vrací do formuláe chyba 2: Obsluze se oznámí "Chybn vyplnná položka rodné íslo" a systém se vrací do formuláe chyba 3: Obsluze se oznámí "Rodné íslo v systému již existuje" a systém se vrací do formuláe Obrázek 3.27: Slovní popis pípadu užití UNovyZakaznik Aplikace Cestovní kancelá - diagram tíd na konceptuální úrovni Na základ diagramu užití, zejména slovního popisu typ užití a specifikace požadavk provedeme první návrh tíd. Budeme postupovat podle doporuení uvedených v 3.2.3.1 a tak mžeme dojít napíklad k diagramu tíd uvedeném na obrázku 3.28. KatalogZajezdu pridej Zajezd() zruszajezd() vyberzajezdy() 1..* cislo stat misto aktivni Zájezd pridejturnus() zrusturnus() vypisturnusy() 1 0..* Turnus cislo termin cena kapacita UbytZarizeni ID typ kategorie popis nazev 0..* Telefon typ predvolba cislo 0..* 1..* Adresa typ ulicecislo mes to PSC stat celaadresa() k upuje 1..* rodnecislo jmeno prijm eni JmenoPrijm eni() Vek() Zamestnanec funk ce plat oddeleni 0..* SeznamZamestnanc u pridej() zrus() vyber() PobytZájezd dalsi sluzby PoznZájezd program doprava Zákazník jizcestoval cislopasu zmennastaleho() 0..* SeznamZakazniku pridejzakaznika() zruszakaznika() setridzakazniky() vypiszakazniky() Obrázek 3.28: Konceptuální diagram tíd aplikace Cestovní kancelá Poznámka: Zastavme se u jedné otázky, se kterou se pi tvorb diagramu tíd asto setkáváme. Jde o rozdíl mezi bžnou asociací a agregací. Pokusíme se objasnit daný problém na píklad naší cestovní kanceláe. Základem aplikace je piazování zákazník k jednotlivým zájezdovým turnusm. Ke každému turnusu bude piazeno "nula a více" zákazník, kteí se na daný turnus pihlásili. Bude tento vztah asociací a nebo agregací? Vztah Turnus - Zákazník jako asociace Existuje globální seznam zákazník, který obsahuje všechny zákazníky cestovní kanceláe (v našem pípad tída SeznamZakazniku). V objektu tídy Turnus jsou potom jen ukazatele na objekty zákazník z tohoto seznamu (viz obrázek 3.28). Vztah Turnus - Zákazník jako agregace Samostatný seznam zákazník neexistuje. Objekty zákazník jsou drženy vždy u píslušných turnus. Pihlásí-li se zákazník na turnus, vytvoí si objekt turnus vložený vnitní objekt

zákazníka (respektive si jej pidá do svého seznamu zákazník pihlášených na daný turnus). Protože rozlišení, zda použít asociaci i agregaci bývá nkdy obtížné, je v sporných pípadech lepší oznait takové vztahy jako asociace a pi dalším rozvoji modelu je pípadn zmnit na agregace. Aplikace Cestovní kancelá - specifikaní diagram tíd Ve fázi návrhu se rozhodneme o implementaním prostedí, uložení dat, vzhledu uživatelského rozhraní. V souvislosti s tím doplníme konceptuální diagram tíd o tídy uživatelského rozhraní, další tídy potebné napíklad pro realizaci vazeb, tídy pro pístup k datm. Protože aplikace Cestovní kancelá je pomrn rozsáhlá, provedeme návrh a implementaci jen pro malou ást dané oblasti. Vezmeme pro jednoduchost jen ást odpovídající typu užití USpravaZakazniku. Adresa typ ulicecislo mesto PSC stat tostring() fromstring() CelaAdresa() 1..* rodnecislo jmeno prijmeni JmenoPrijmeni() tostring() fromstring() Vek() Ces tovnikance lar spravazakazniku() spravazajezdu() spravazamestnancu() OknoCest Ka ncelar zobraz() spravazakazniku() 1 1 spravazajezdu() spravazamest nancu() Zákaz ník jizcestoval cislopasu tostring() fromstring() zmennastaleho() 1 1 O knozakazn ik 0..* 1 SeznamZakazniku nactizesouboru() ulozdosouboru() pridejzakaznika() zruszakaznika() setridzakazniky() vypiszakazniky() 1 1 OknoZakaznici zobraz() nactizakazniky() ulozzakazniky() novyzakaznik() zruszakaznika() detailzakaznika() setridzakazniky() vypiszakazniky() zobrazprozadavani() zobrazproeditaci()