Nßvrh aplikacφ v jazyce UML
"Kvalitnφ objektov∞ orientovan² nßvrh aplikace je nezbytn²m p°edpokladem jeho ·sp∞ÜnΘ implementace". Tuto floskuli pravd∞podobn∞ slyÜel ka₧d², kdo se v²vojem aplikacφ zab²vß profesionßln∞. I v p°etechnizovanΘ IT oblasti je m≤dnφ pou₧φvat libozvuΦnß magickß zaklφnadla, je₧ majφ zßkaznφka utvrzovat v profesionalit∞ dodavatele, kter² ale Φasto nenφ schopen dostßt nßrok∙m kvalitnφho nßvrhu, zato se brilantn∞ orientuje v PR frßzφch a znß nazpam∞¥ aktußlnφ slovnφk buzzwords. Ambicφ tΘto sΘrie Φlßnk∙ je oΦistit v∞tu o kvalitnφm nßvrhu od otravn²ch pseudomarketingov²ch zplodin a ukßzat skuteΦnΘ v²hody precizn∞ provedenΘho nßvrhu pomocφ modelovacφho jazyka UML.
Kvalita je ideßl
Kvalitu aplikace nenφ mo₧nΘ empiricky zm∞°it Φi exaktn∞ definovat postupy k jejφmu dosa₧enφ ve form∞ receptu pro lφnΘ nßvrhß°e. Je vÜak mo₧nΘ identifikovat nßroky kladenΘ na aplikaci, kterou bude pova₧ovat za kvalitnφ zßkaznφk i dodavatel.
- Shoda p∙vodnφch po₧adavk∙ zadavatele s funkΦnφ specifikacφ vyvinutΘ aplikace. Ad hoc ·pravy dodanΘ aplikace na vlastnφ nßklady a ned∙stojnΘ handrkovßnφ se zßkaznφkem si snad nikdo nem∙₧e p°ßt.
- Spravovatelnost aplikace. Aplikaci je mo₧nΘ snadno rozÜi°ovat na zßklad∞ nov²ch po₧adavk∙ zadavatele. SnadnΘ rozÜφ°enφ opravdu neznamenß, ₧e aplikaci poka₧dΘ v rekordn∞ krßtkΘ dob∞ z devadesßti procent p°epφÜete. RychlΘ ruce "buÜiΦ∙ k≤du" nemohou b²t donekoneΦna adekvßtnφ nßhradou intelektu analytik∙. SΘrie strastipln²ch porod∙ zcela nov²ch verzφ aplikace vede v∞tÜinou k nasazovßnφ zmetk∙, u nich₧ se odstra≥ujφ stßle stejnΘ chyby.
- Opakovanß pou₧itelnost Φßstφ aplikace. Nemß smysl psßt stßle dokola stejnΘ komponenty, ale je vhodnΘ jejich funkcionalitu zobecnit, aby je bylo mo₧nΘ beze zm∞ny pou₧φvat v dalÜφch aplikacφch.
- Spolehlivost aplikace. Spolehlivost se definuje jako schopnost aplikace reagovat na stejnou sadu podmφnek stejn²m zp∙sobem. Zßkaznφk v∞tÜinou nechce sv∙j informaΦnφ systΘm provozovat jako vnitrofiremnφ loterii, ze kterΘ vypadßvajφ nßhodnß data.
- Robustnost aplikace. Dodanß aplikace musφ b²t schopnß zotavit se z r∙zn²ch v²jimek, ani₧ by doÜlo ke ztrßt∞ Φi ·niku dat, nebo dokonce k celkovΘmu dlouhotrvajφcφmu v²padku aplikace.
V²Φet vlastnostφ kvalitnφ aplikace jist∞ nenφ ·pln², ale pojem kvalita mß nynφ z°eteln∞jÜφ kontury. Dob°e vytvo°en² nßvrh umo₧≥uje do vyvφjenΘ aplikace zmφn∞nΘ vlastnosti integrovat u₧ na poΦßtku jejφho ₧ivotnφho cyklu.
Spasφ nßs UML?
Nßvrh aplikace m∙₧e teoreticky vzniknout pouze za pou₧itφ tu₧ky, mozku a poznßmkovΘho bloku, s jejich₧ pomocφ naΦrtnete jednoduch² model aplikace. Model ale bude pou₧φvat jen vßm znßmou syntaxi a sΘmantiku, tak₧e budete jen t∞₧ko svΘ zßhadnΘ omalovßnky s n∞k²m sdφlet. DalÜφm problΘmem je, ₧e za t∞mito nßΦrty v∞tÜinou nestojφ ₧ßdn² konzistentnφ logick² metamodel ani formßln∞ kodifikovanß sΘmantika jednotliv²ch element∙ modelu, tak₧e p°φpadnß komunikace mezi nßvrhß°i p°ipomφnß situaci v IT Babyl≤nu po zmatenφ jazyk∙ a je protkßna slovy "asi", "mo₧nß" a "jak to vlastn∞ bylo myÜleno".
Unified Modeling Language (UML) mß ji₧ ve svΘm nßzvu slovo unifikovan², proto₧e jednφm z jeho cφl∙ je sjednocenφ pou₧φvan²ch v²razov²ch prost°edk∙. UML je jazykem s bohatou sΘmantikou a syntaxφ, kter² usnad≥uje nßvrh a vizualizaci r∙zn²ch typ∙ aplikacφ. Navφc tv∙rci jazyka UML nebyli natolik naivnφ ani sebev∞domφ, aby v∞°ili, ₧e standardnφmi elementy jazyka UML pokryli kompletn∞ veÜkerΘ po₧adavky nßvrhß°∙, a p°φmo do jazyka zabudovali mechanismy rozÜφ°enφ, kterΘ usnad≥ujφ °φzenou deklaraci a definici nov²ch element∙ jazyka.
UML je jazyk, kter² umo₧≥uje modelovat jednoduchΘ i slo₧itΘ aplikace pomocφ stejnΘ formßlnφ syntaxe, a proto m∙₧ete v²sledky svΘ prßce sdφlet s ostatnφmi nßvrhß°i. UML ale nenφ vÜemocnΘ. I kdy₧ umφte UML, ovlßdßte pouze nßstroj. Sice velmi v²konn², ale stßle jen nßstroj û ty, kte°φ si myslφ, ₧e UML je cizokrajnΘ ko°enφ, kterΘ pou₧ijφ na dokrvenφ sv²ch anemick²ch nßvrh∙, musφm zklamat. Znalcem UML se Φlov∞k stßvß, nßvrhß°em Φi analytikem se rodφ.
StruΦnß historie cesty k eklektickΘmu UML
Jazyk UML nevznikl ve vzduchoprßzdnu, p°edchßzelo mu myÜlenkovΘ ·silφ mnoha OOP znalc∙ o vytvo°enφ kvalitnφ metodiky. Nßsledujφcφ struΦn² v²Φet metodik, kterΘ m∞ly nejv∞tÜφ vliv na jazyk UML, si neΦinφ nßrok na ·plnost.
- Object modeling technique (Rumbaugh, Premerlani)
- Object oriented software development (G. Booch)
- Object oriented software engineering (I. Jacobson)
- Object oriented structured design notations (Wassermann, Pircher)
V roce 1996 pßnovΘ Jacobson, Booch a Rumbaugh, kte°φ ji₧ d°φve v²znamn∞ p°isp∞li k rozvoji OOP metodik, p°eÜli k firm∞ Rational Corp., pro kterou vytvo°ili jazyk UML. V roce 1997 byl jazyk UML akceptovßn jako pr∙myslov² standard a postupn∞ zaΦal vytlaΦovat ostatnφ analytickΘ jazyky na pov∞stnΘ smetiÜt∞ d∞jin. V souΦasnΘ dob∞ se p°ipravuje uvedenφ verze 2.0. V existujφcφch CASE nßstrojφch se m∙₧ete v∞tÜinou setkat s podporou UML verze 1.2, 1.3 nebo dokonce 1.4. Na klφΦovΘ rozdφly mezi jednotliv²mi verzemi vßs v₧dy upozornφm v p°φsluÜnΘ tΘmatickΘ Φßsti o jazyce UML.
V nadpise tΘto Φßsti Φlßnku je UML oznaΦeno jako eklektickΘ. Auto°i UML i podle vlastnφch slov postupovali tak, ₧e z existujφcφch konkurenΦnφch jazyk∙ vybrali nejlepÜφ myÜlenky a adoptovali je do jazyka UML, kter² podtrhl jejich v²znam integracφ do nov∞ promyÜlenΘho celku. Termφn eklektismus nenφ tedy zmi≥ovßn v souvislosti s UML nijak pejorativn∞, ale naopak popisuje nutnou selekci hodnotn²ch myÜlenek z mnohdy obskurnφch nßpad∙ r∙zn²ch metodik.
UML pohledy na systΘm
JakΘ hlavnφ aspekty modelovanΘ aplikace dovoluje UML zachytit? Model v UML se sklßdß z r∙zn²ch diagram∙, je₧ p°edstavujφ pr∙hledy na r∙znΘ Φßsti sΘmantickΘho zßkladu navrhovanΘ aplikace. SΘmantick²m zßkladem je souhrn specifikacφ aplikace, kter² vymezuje teritorium, v n∞m₧ se m∙₧e nßvrh pohybovat. Diagram ve vizußlnφ form∞ vyprßvφ prßv∞ jeden konkrΘtnφ "p°φb∞h" o aplikaci. Äßdn² dvourozm∞rn² diagram nem∙₧e zachytit komplexnφ aplikaci v celku, ale soust°edφ se v₧dy prßv∞ na jeden d∙le₧it² aspekt. Jazyk UML rozeznßvß p∞t zßkladnφch pohled∙ na systΘm.
- Pohled p°φpad∙ u₧itφ. V p°φpadech u₧itφ jsou vyjßd°eny zßkladnφ po₧adavky kladenΘ na systΘm. VeÜkerΘ dalÜφ pohledy se pohybujφ v mantinelech vymezen²ch pohledem p°φpad∙ u₧itφ.
- Logick² pohled se zab²vß zejmΘna pojmy z problΘmovΘ domΘny zadavatele a jejich vzßjemn²mi statick²mi vztahy.
- Procesnφ pohled se soust°e∩uje na chovßnφ systΘmu, kterΘ musφ spl≥ovat po₧adavky a omezenφ z p°φpad∙ u₧itφ, je₧ jsou kladeny na pr∙b∞h proces∙. Pregnantn∞ °eΦeno, jednß se o procesn∞ orientovan² dopln∞k logickΘho pohledu.
- ImplementaΦnφ pohled zachycuje fyzickΘ rozd∞lenφ aplikace na samostatnΘ komponenty a jejich zßvislosti.
- Pohled nasazenφ mapuje komponenty na mno₧inu fyzick²ch v²poΦetnφch uzl∙ v cφlovΘm prost°edφ.
Pohledy jsou konkretizovßny v nßsledujφcφch typech diagram∙, jejich₧ detailnφ popis bude p°edm∞tem dalÜφch Φlßnk∙.
- Diagram p°φpad∙ u₧itφ
- Diagram t°φd
- Diagram objekt∙
- Diagram komponent
- Diagram nasazenφ
- SekvenΦnφ diagram
- KolaboraΦnφ diagram
- Stavov² diagram
- Diagram aktivit
V nßsledujφcφm Φlßnku se podφvßme podrobn∞, jak je UML jazyk strukturovßn, jak²m zp∙sobem jej m∙₧eme rozÜi°ovat a jak jsou zßkladnφ pohledy na aplikaci sjednoceny v termφn "architektura".
