Jim Arlow, Ila Neustadt. UML 2 a unifikovaný proces vývoje aplikací Objektově orientovaná analýza a návrh prakticky

Jim Arlow, Ila Neustadt

UML 2 a unifikovaný proces vývoje aplikací Objektově orientovaná analýza a návrh prakticky

Computer Press, a.s. Brno 2011

1349_tiraz.indd 1

9.8.2011 10:02:05

UML 2 a unifikovaný proces vývoje aplikací Objektově orientovaná analýza a návrh prakticky Jim Arlow, Ila Neustadt Computer Press, a.s., 2011. Dotisk prvního vydání. Překlad: Bogdan Kiszka Jazyková korektura: Josef Novák Vnitřní úprava: Bogdan Kiszka Sazba: Kateřina Kiszková Rejstřík: Kateřina Kiszková Obálka: Martin Sodomka

Komentář na zadní straně obálky: Václav Kadlec Technická spolupráce: Jiří Matoušek, Petr Klíma, Pavel Kynický, Iva Vilímská, Zuzana Šindlerová Odpovědný redaktor: Václav Kadlec Technický redaktor: Jiří Matoušek Produkce: Daniela Nečasová

Authorized translation from the English language edition, entitled UML 2 AND THE UNIFIED PROCESS: PRACTICAL OBJECT-ORIENTED ANALYSIS AND DESIGN, 2nd Edition, 0321321278 by ARLOW, JIM, NEUSTADT, ILA, published by Pearson Education, Inc, publishing as Addison Wesley Professional, Copyright © 2005 Pearson Education, Inc. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. CZECH language edition published by Computer Press, a.s., Copyright © 2007. Autorizovaný překlad z originálního anglického vydání UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design. Originální copyright: © Pearson Education, Inc./Jim Arlow, Ila Neustadt, 2005. Překlad: © Computer Press, a.s., 2007. Computer Press, a. s., Holandská 3, 639 00 Brno Objednávky knih: http://knihy.cpress.cz [email protected] tel.: 800 555 513 ISBN 978-80-251-1503-9 Prodejní kód: K1349 Vydalo nakladatelství Computer Press, a. s., jako svou 3002. publikaci. © Computer Press, a.s. Všechna práva vyhrazena. Žádná část této publikace nesmí být kopírována a rozmnožována za účelem rozšiřování v jakékoli formě či jakýmkoli způsobem bez písemného souhlasu vydavatele.

1349_tiraz.indd 2

9.8.2011 10:06:10

Stručný obsah Část I

Úvod do jazyka UML a metodiky Unified Process

25

Kapitola 1 Kapitola 2

Co je to vlastně UML? ..............................................................27 Co je to Unified Process (UP)?................................................ 51

Část II

Požadavky

Kapitola 3 Kapitola 4 Kapitola 5

Požadavky a jejich specifikace .............................................73 Modelování případů užití .......................................................89 Pokročilé modelování případů užití................................... 115

Část III

Analýza

Kapitola 6 Kapitola 7 Kapitola 8 Kapitola 9 Kapitola 10 Kapitola 11 Kapitola 12 Kapitola 13 Kapitola 14 Kapitola 15

Analýza.................................................................................... 137 Třídy a objekty ......................................................................143 Hledáme analytické třídy .................................................... 171 Relace ......................................................................................189 Dědičnost a polymorfismus ................................................215 Analytické balíčky ................................................................231 Realizace případů užití .........................................................245 Pokročilé realizace případů užití........................................275 Diagramy aktivit ...................................................................285 Pokročilé diagramy aktivit..................................................309

Část IV

Návrh

Kapitola 16 Kapitola 17 Kapitola 18 Kapitola 19 Kapitola 20 Kapitola 21 Kapitola 22

Pracovní postup Návrh.........................................................329 Návrhové třídy.......................................................................339 Upřesňování analytických relací ........................................357 Rozhraní a komponenty.......................................................381 Realizace případů užití – návrh ..........................................405 Stavové automaty.................................................................427 Pokročilé stavové diagramy................................................445

71

135

327

4

Stručný obsah

Část V

Implementace

459

Kapitola 23 Kapitola 24

Pracovní postup – Implementace ......................................461 Nasazení ..................................................................................467

Část VI

Doplňkový materiál

479

Kapitola 25 Úvod do jazyka OCL ...............................................................481 Příloha A: Ukázkový model případu užití............................................533 Příloha B: Specifikace v XML..................................................................541 Příloha C: Bibliografie .............................................................................549 Příloha D: Stručný slovníček pojmů .....................................................551 Rejstřík .............................................................................................................555

Obsah Poděkování.................................................................................. 17 Předmluva.................................................................................... 19 O této knize ..................................................................................19 Konvence ......................................................................................20 Jak Àíst tuto knihu ....................................................................21

Cestovní mapa této knihy ............................................................22

Část I Kapitola 1


25

Co je to vlastně UML? ............................................ 27 Kudy kam? ....................................................................................27 Co je to UML? ..............................................................................28 Zrození jazyka UML .....................................................................29 MDA – budoucnost jazyka UML .................................................31 ProÀ „unifikovaný“?......................................................................33 Objekty a jazyk UML....................................................................33 Struktura jazyka UML ..................................................................34 Stavební bloky jazyka UML..........................................................35 PÏedmÄty (things).........................................................................35 Relace (relationships) ..............................................................36 Diagramy...................................................................................36

Obecná mechanika jazyka UML ..................................................39 Specifikace ................................................................................39 Ornamenty (Adornments) ......................................................41 Podskupiny ...............................................................................41 Mechanismy rozšiÏitelnosti......................................................43

Architektura .................................................................................46 ¡emu jste se nauÀili .....................................................................48

Kapitola 2

Co je to Unified Process (UP)? .............................. 51 Kudy kam......................................................................................51 Co je to UP?..................................................................................53 Zrození metodiky UP ...................................................................53 UP a RUP......................................................................................56 Konkrétní aplikace metodiky UP v novém projektu..................58 Axiomy metodiky UP ...................................................................59

6

Obsah

Metodika UP je založena na iterativním a pÏírÐstkovém procesu ...............................................................60 Pracovní postupy iterace .........................................................60 Základny iterací a pÏírÐstky (inkrementy)..............................61

Struktura metodiky UP ................................................................61 Fáze podle metodiky UP ..............................................................63 Souhrnné cíle fáze Zahájení ....................................................63 Primární zamÄÏení fáze Zahájení ............................................64 Milník: PÏedmÄt životního cyklu a rozsah systému ...............64 Cíle fáze Rozpracování ............................................................65 Primární zamÄÏení fáze Rozpracování ...................................65 Milník: Architektura jako vodítko pro systém v jeho budoucím životÄ ........................................65 Souhrnné cíle fáze Konstrukce ...............................................66 Primární zamÄÏení fáze Konstrukce.......................................66 Milník: PoÀáteÀní provozní zpÐsobilost .................................67 Cíle fáze Zavedení ....................................................................67 Primární zamÄÏení fáze Zavedení ...........................................67 Milník: Nasazení produktu......................................................68

¡emu jste se nauÀili? ....................................................................68

Část II

Požadavky

71

Kapitola 3

Požadavky a jejich specifikace ........................... 73 Kudy kam? ....................................................................................73 Pracovní postup............................................................................74 Softwarové požadavky – metamodel ...........................................75 Detail pracovního postupu Požadavky........................................76 Význam požadavkÐ.......................................................................78 Definice požadavkÐ ......................................................................78 Specifikace systémových požadavkÐ.......................................79 SprávnÄ formulované požadavky............................................79 FunkÀní a nefunkÀní požadavky .............................................80 UspoÏádání požadavkÐ ............................................................81 Atributy požadavkÐ..................................................................81

Hledání požadavkÐ.......................................................................83 Získávání požadavkÐ: Mít mapu ještÄ neznamená vládnout území! .........................84 Konzultace ................................................................................85 Dotazníky ..................................................................................86 Dílna požadavkÐ.......................................................................86

¡emu jste se nauÀili? ....................................................................87

Kapitola 4

Modelování případů užití ..................................... 89 Kudy kam? ....................................................................................89 Modelování pÏípadÐ užití.............................................................91

Obsah

Aktivita metodiky UP: najít aktéry a pÏípady užití .....................91 Subjekt (Hranice systému) ......................................................92 Co jsou to aktéÏi? .....................................................................93 Co jsou to pÏípady užití? .........................................................95 SlovníÀek pojmÐ.......................................................................97

Aktivita metodiky Unified Process: Detail pÏípadu užití............98 Specifikace pÏípadu užití..............................................................99 Název pÏípadu užití................................................................100 ID pÏípadu užití......................................................................101 StruÀný popis..........................................................................101 AktéÏi ......................................................................................101 Vstupní a výstupní podmínky ...............................................101 Tok událostí............................................................................102 Modelování alternativních scénáÏÐ ......................................106

Sledování požadavkÐ..................................................................110 Kdy modelovat pÏípady užití .....................................................112 ¡emu jste se nauÀili? ..................................................................112

Kapitola 5

Pokročilé modelování případů užití .................115 Kudy kam? ..................................................................................115 ZobecnÄní aktéra (actor generalization) ...................................116 ZobecnÄní pÏípadÐ užití.............................................................118 Relace «include»........................................................................121 Relace «extend» .........................................................................123 RozšíÏení pÏípadu užití ..........................................................125 Více vkládaných segmentÐ ....................................................126 PodmínÄná rozšíÏení..............................................................126

Kdy použít pokroÀilé funkce .....................................................127 Rady a tipy pro psaní pÏípadÐ užití...........................................128 TvoÏte co nejkratší a nejjednodušší pÏípady užití ...............128 SoustÏe×te se na co, nikoli na jak ..........................................129 Vyhýbejte se funkÀní dekompozici .......................................129

¡emu jste se nauÀili ...................................................................131

Část III

Analýza

135

Kapitola 6

Analýza ..................................................................137 Kudy kam? ..................................................................................137 Analýza........................................................................................137 Artefakty analýzy – metamodel.............................................138 Detail pracovního postupu analýzy ......................................139

Analytický model – OsvÄdÀené postupy ...................................139 ¡emu jste se nauÀili? ..................................................................141

Kapitola 7

Třídy a objekty.....................................................143 Kudy kam? ..................................................................................143

7

8

Obsah

Co jsou to objekty?.....................................................................144 ZapouzdÏení ...........................................................................146 PÏedávání zpráv......................................................................147

Notace objektÐ v jazyce UML ....................................................148 Hodnoty atributÐ ...................................................................149

Co jsou to tÏídy? .........................................................................149 TÏídy a objekty .......................................................................151 Tvorba instance......................................................................152

Notace tÏídy v jazyce UML.........................................................152 Oddíl názvu ............................................................................154 Oddíl atributÐ ........................................................................154 Oddíl operací .........................................................................158 Syntaxe stereotypu tÏídy........................................................162

Rozsah platnosti .........................................................................163 Platnost instance a platnost tÏídy..........................................163 PÏístup je urÀen rozsahem platnosti.....................................164

Tvorba a uvolnÄní objektÐ.........................................................164 Konstruktory – ukázková tÏída BankovníÚ¶et .....................165 Destruktory – ukázková tÏída BankovníÚ¶et........................166

¡emu jste se nauÀili? ..................................................................166

Kapitola 8

Hledáme analytické třídy ..................................171 Kudy kam? ..................................................................................171 Aktivita metodiky UP: analýza pÏípadu užití ............................172 Co jsou to analytické tÏídy?........................................................173 Anatomie analytické tÏídy .....................................................174 Jak se pozná dobrá analytická tÏída? ....................................175 Co Ïíká praxe o analytických tÏídách....................................176

Hledáme tÏídy.............................................................................178 Hledáme tÏídy na základÄ analýzy podstatných jmen a sloves.....................178 Hledáme tÏídy pomocí metody štítkÐ CRC .........................180 Hledáme tÏídy pomocí stereotypÐ metodiky RUP..............181 Hledáme tÏídy z jiných zdrojÐ...............................................184

Tvorba první verze analytického modelu..................................185 ¡emu jste se nauÀili? ..................................................................186

Kapitola 9

Relace ....................................................................189 Kudy kam? ..................................................................................189 Co je to relace? ...........................................................................189 Co je to spojení? .........................................................................190 Objektové diagramy...............................................................191 Cesty........................................................................................193

Co je to asociace? .......................................................................194 Syntaxe asociace.....................................................................194 Násobnost (multiplicity) ........................................................195 PrÐchodnost (navigability) ....................................................199

Obsah

Asociace a atributy.................................................................202 AsociaÀní tÏídy........................................................................203 Asociace s kvalifikátorem ......................................................205

Co je to závislost? .......................................................................206 Závislosti v užívání (usage dependencies) ............................208 AbstrakÀní závislosti...............................................................209 Závislosti na základÄ oprávnÄní ............................................211


Kapitola 10

Dědičnost a polymorfismus...............................215 Kudy kam? ..................................................................................215 ZobecnÄní (generalizace) ...........................................................216 ZobecnÄní tÏíd........................................................................216

DÄdiÀnost tÏíd.............................................................................217 PÏekrývání...............................................................................217 Abstraktní operace a tÏídy.....................................................219 StupnÄ abstrakce ....................................................................220 DÄdÄní od více pÏedkÐ ..........................................................220

Polymorfismus............................................................................220 PÏíklad polymorfismu ............................................................221

PokroÀilé zobecÉování ...............................................................224 ZobecÉující množiny..............................................................224 Odvozené metatÏídy ..............................................................227


Kapitola 11

Analytické balíčky...............................................231 Kudy kam? ..................................................................................231 Co je to balíÀek? .........................................................................231 BalíÀky a jmenné prostory .........................................................234 VnoÏené balíÀky..........................................................................234 Závislosti balíÀkÐ ........................................................................235 PÏechodnost ...........................................................................237

ZobecÉování balíÀkÐ ..................................................................238 Architektonická analýza .............................................................238 Hledáme analytické balíÀky...................................................239 Cyklické závislosti balíÀkÐ .....................................................241


Kapitola 12

Realizace případů užití .......................................245 Kudy kam? ..................................................................................245 Aktivita metodiky UP: Analýza pÏípadu užití............................246 Co jsou to realizace pÏípadÐ užití? ............................................247 Realizace pÏípadu užití – prvky .................................................248 Interakce .....................................................................................249 ¡áry života ..................................................................................249

9

10

Obsah

Zprávy .........................................................................................250 Synchronní, asynchronní a návratové zprávy ......................251 Tvorba a uvolnÄní zpráv........................................................252 Nalezené a ztracené zprávy ...................................................252

Diagramy interakce ....................................................................253 SekvenÀní diagramy ...................................................................253 ¡áry života a zprávy ...............................................................254 Aktivace ..................................................................................256 Dokumentace sekvenÀních diagramÐ ..................................257 Invarianty a omezení stavu....................................................258

Kombinované fragmenty a operátory .......................................260 VÄtvení pomocí operátorÐ opt a alt .....................................262 Iterace s operátory loop a break...........................................264

KomunikaÀní diagramy..............................................................267 Iterace .....................................................................................268 VÄtvení ....................................................................................270


Kapitola 13

Pokročilé realizace případů užití ......................275 Kudy kam? ..................................................................................275 Výskyty interakcí ........................................................................275 Argumenty..............................................................................278 Brány.......................................................................................279

Body pokraÀování.......................................................................281 ¡emu jste se nauÀili? ..................................................................283

Kapitola 14

Diagramy aktivit..................................................285 Kudy kam? ..................................................................................285 Co jsou to diagramy aktivit? ......................................................286 Diagramy aktivit a metodika Unified Process...........................287 Aktivity........................................................................................287 Sémantika aktivit ........................................................................289 Oddíly aktivit ..............................................................................291 AkÀní uzly ...................................................................................293 AkÀní uzel: Volání ..................................................................295 AkÀní uzel: PÏijetí Àasové události ........................................296

±ídicí uzly ...................................................................................297 PoÀáteÀní a koncové uzly.......................................................298 Uzly rozhodnutí a slouÀení....................................................298 Uzly rozvÄtvení a spojení – soubÄžnost................................299

Objektové uzly............................................................................301 Sémantika vyrovnávací pamÄti objektového uzlu................302 ZnázornÄní stavÐ objektÐ ......................................................303 Parametry aktivit ....................................................................303

Sponky (pins)..............................................................................305 ¡emu jste se nauÀili ...................................................................306

Obsah

Kapitola 15

Pokročilé diagramy aktivit................................309 Kudy kam? ..................................................................................309 Spojky .........................................................................................311 PÏerušitelné oblasti aktivit .........................................................311 OšetÏení výjimek ........................................................................312 PÏídavné uzly ..............................................................................313 Odesílání signálÐ a pÏijímání událostí.......................................314 ProudÄní .....................................................................................317 PokroÀilé funkce toku objektÐ ..................................................318 Vstupní a výstupní efekty ......................................................318 Stereotyp «selection» .............................................................318 Stereotyp «transformation» ..................................................319

Multiplexní vysílání a pÏíjem .....................................................319 Množiny parametrÐ....................................................................320 Uzel stereotypu «centralBuffer» ................................................321 StruÀné diagramy interakcí........................................................322 ¡emu jste se nauÀili? ..................................................................324

Část IV

Návrh

327

Kapitola 16

Pracovní postup Návrh .......................................329 Kudy kam? ..................................................................................329 Návrh – pracovní postup ...........................................................330 Artefakty návrhu – metamodel..................................................331 Relace stereotypu «trace»......................................................332 Udržovat jeden nebo dva modely? .......................................333

Detail návrhu ..............................................................................335 Aktivita podle metodiky UP: Architektonický návrh ...............336 ¡emu jste se nauÀili? ..................................................................337

Kapitola 17

Návrhové třídy.....................................................339 Kudy kam? ..................................................................................339 Aktivita podle metodiky UP: Návrh tÏídy .................................340 Co jsou to návrhové tÏídy?.........................................................341 Anatomie návrhové tÏídy ...........................................................343 SprávnÄ formulované návrhové tÏídy........................................344 Úplnost a dostateÀnost ..........................................................344 Jednoduchost..........................................................................345 Vysoká soudržnost .................................................................346 Minimalizace vazeb ................................................................346

DÄdÄní.........................................................................................347 Agregace, nebo dÄdÄní..........................................................347 DÄdÄní od více pÏedkÐ (multiple inheritance) ....................349 DÄdÄní a realizace rozhraní ..................................................350

Šablony .......................................................................................350

11

12

Obsah

VnoÏené tÏídy .............................................................................353 ¡emu jste se nauÀili? ..................................................................353

Kapitola 18

Upřesňování analytických relací ......................357 Kudy kam? ..................................................................................357 Návrhové relace..........................................................................359 Agregace a kompozice ...............................................................359 Sémantika agregace....................................................................360 Sémantika kompozice ................................................................362 Kompozice a atributy.............................................................363

Jak upÏesnit analytické relace ....................................................364 Asociace typu 1:1........................................................................364 Relace typu M:1..........................................................................365 Asociace typu 1:N.......................................................................366 Kolekce ......................................................................................366 Mapa .......................................................................................368

Konkretizované relace ...............................................................369 Asociace typu M:N .................................................................370 ObousmÄrné asociace............................................................370 TÏídy asociací..........................................................................371

Kompozice ve strukturovaných tÏídách ....................................372 Strukturované klasifikátory ...................................................372 Strukturované tÏídy................................................................373


Kapitola 19

Rozhraní a komponenty.....................................381 Kudy kam? ..................................................................................381 Aktivita podle metodiky UP: Návrh podsystému .....................382 Co je to rozhraní?.......................................................................383 ZpÏístupnÄná a požadovaná rozhraní .......................................384 Realizace rozhraní versus dÄdÄní ..............................................386 Porty .........................................................................................390 Rozhraní a vývoj komponentového softwaru ...........................391 Co je to komponenta?................................................................392 Stereotypy komponent...............................................................394 Podsystémy .................................................................................395 Hledáme rozhraní ......................................................................395 Návrh pomocí rozhraní..............................................................396 Vzor fasáda .............................................................................397 Fyzická architektura a vzor rozvrstvení ................................398

Výhody a nevýhody rozhraní .....................................................399 ¡emu jste se nauÀili? ..................................................................400

Kapitola 20

Realizace případů užití – návrh ........................405 Kudy kam? ..................................................................................405 Aktivita: Navrhnout pÏípad užití ...............................................406

Obsah

Realizace pÏípadÐ užití – návrh .................................................407 Návrhové diagramy interakce....................................................408 Modelování soubÄžnosti ............................................................410 Aktivní tÏídy ............................................................................410 SoubÄžnost v sekvenÀních diagramech ................................412 SoubÄžnost v komunikaÀních diagramech...........................414

Interakce podsystémÐ ................................................................416 Diagramy Àasování......................................................................417 PÏíklady realizace pÏípadu užití ve fázi návrhu .........................420 ¡emu jste se nauÀili? ..................................................................425

Kapitola 21

Stavové automaty...............................................427 Kudy kam? ..................................................................................427 Stavové automaty .......................................................................428 Stavové automaty chování a stavové automaty protokolu..429 Stavové automaty a tÏídy .......................................................429

Stavové automaty a metodika Unified Process.........................430 Diagramy stavových automatÐ...................................................431 Stavy .........................................................................................432 Syntaxe stavu ..........................................................................433

PÏechody mezi stavy ...................................................................434 Spojování pÏechodÐ – pÏechodový pseudostav...................435 VÄtvení pÏechodÐ – pseudostav volby..................................436

Události.......................................................................................437 Události volání .......................................................................437 Signální události.....................................................................438 Události zmÄny.......................................................................439 ¡asové události ......................................................................440


Kapitola 22

Pokročilé stavové diagramy..............................445 Kudy kam? ..................................................................................445 Složené stavy...............................................................................446 Jednoduché složené stavy......................................................447 Ortogonální složené stavy .....................................................449

Stavy podautomatÐ ....................................................................452 Komunikace mezi stavovými podautomaty ..............................453 Historie .......................................................................................455 MÄlká historie.........................................................................455 Hluboká historie ....................................................................456


13

14

Obsah

Část V

Implementace

459

Kapitola 23

Pracovní postup – Implementace ....................461 Kudy kam? ..................................................................................461 Pracovní postup – Implementace..............................................461 Artefakty implementace – metamodel......................................463 Detail fáze Implementace ..........................................................464 Artefakty .....................................................................................464 ¡emu jste se nauÀili? ..................................................................465

Kapitola 24

Nasazení ................................................................467 Kudy kam? ..................................................................................467 Aktivita podle metodiky Unified Process: Architektonická implementace..................................................467 Diagram nasazení .......................................................................469 Uzly .............................................................................................470 Artefakty .....................................................................................472 Nasazení......................................................................................476 ¡emu jste se nauÀili? ..................................................................477

Část VI

Doplňkový materiál

479

Kapitola 25

Úvod do jazyka OCL..............................................481 Kudy kam? ..................................................................................481 Co je to jazyk OCL? ...................................................................483 ProÀ vlastnÄ jazyk OCL používat? .............................................483 Syntaxe výrazÐ v jazyce OCL .....................................................484 Obsah balíÀku a názvy cest ........................................................486 Kontext výrazu............................................................................486 Typy výrazÐ v jazyce OCL..........................................................487 TÄlo výrazu .................................................................................489 KomentáÏe, klíÀová slova a pravidla priority .......................489 Systém typÐ v jazyce OCL .....................................................490 Primitivní typy ........................................................................492 Strukturovaný typ Tuple .......................................................494 Infixové operátory .................................................................495 Kolekce OCL..........................................................................496 IteraÀní operace .....................................................................502

Navigace pomocí jazyka OCL....................................................505 Navigace uvnitÏ kontextové instance....................................506 Procházení asociací ................................................................506 Procházení nÄkolika asociací.................................................508

Obsah

Typy výrazÐ OCL pod lupou .....................................................509 inv:...........................................................................................509 pre:, post: a @pre ..................................................................511 body:........................................................................................512 init: ..........................................................................................513 def: ..........................................................................................513 Výrazy s klíÀovým slovem let .................................................515 KlíÀové slovo derive: ..............................................................515

Jazyk OCL v jiných typech diagramÐ ........................................516 Jazyk OCL v diagramech interakce ......................................516 Jazyk OCL v diagramech aktivit............................................518 Jazyk OCL ve stavových automatech....................................519

PokroÀilá témata.........................................................................521 Navigace mezi asociaÀními tÏídami ......................................521 Navigace mezi kvalifikovanými asociacemi..........................522 ZdÄdÄné asociace ...................................................................523 Výrazy typu OclMessage........................................................525


Příloha A

Ukázkový model případu užití ..........................533 Úvod............................................................................................533 Model pÏípadu užití ...................................................................533 Ukázkové pÏípady užití...............................................................533

Příloha B

Specifikace v XML ................................................541 Jazyk XML a šablony pÏípadÐ užití............................................541 SUMR..........................................................................................541

Příloha C

Bibliografie ...........................................................549

Příloha D

Stručný slovníček pojmů ...................................551

Rejstřík .......................................................................................555

15

Našim rodiÀÐm

Poděkování PÏedevším bychom chtÄli podÄkovat Fabriziu Ferrandinovi, Wolfgangu Emmerichovi a našim pÏátelÐm ze spoleÀnosti Zühlke Engineering, kteÏí nás povzbuzovali pÏi pÏípravÄ zaškolovacího kurzu pro práci s jazykem UML, jenž se stal základním kamenem této knihy. Sue a Davidovi Epstainovým dÄkujeme za nepostradatelnou pomoc bÄhem celého projektu. DÄkujeme rovnÄž Andymu Polsovi, aÚ už za posuzování jednotlivých pÏípadÐ užití, Ài za jeho programové inženýrství. Alison Birtwellové a jejím kolegÐm z nakladatelství Addison-Wesley dÄkujeme za vyšperkování textu. RodinÄ Neustadtových dÄkujeme za ohromnou trpÄlivost. Za mírnou útÄchu a podporu dÄkujeme Alu Tomsovi. KoÀkám Homérovi a Isis dÄkujeme za hodiny prospané na rÐzných verzích konceptu pÏipravovaného rukopisu. Nakonec musíme ještÄ zmínit „Tres Amigos“: Gradyho Boocha, Jima Rumbaugha a Ivana Jacobsona – za jejich práci na jazyku UML a standardu Unified Process, o nichž vlastnÄ tato kniha je.

Předmluva O této knize Tato kniha si klade za cíl provést vás procesem objektovÄ orientované analýzy a návrhu v jazyku UML (Unified Modeling Language, unifikovaný jazyk pro tvorbu diagramÐ) v souladu s metodikou Unified Process (UP, unifikovaný proces). Jazyk UML poskytuje syntaxi vizuálního modelování používanou pÏi objektovÄ orientovaném návrhu, zatímco UP nabízí standardní osnovu pro proces tvorby softwarového vybavení, která je vodítkem pÏi vypracovávání objektovÄ orientované analýzy a návrhu. Metodika Unified Process má mnoho rÐzných aspektÐ. V této knize vás seznámíme jen s tÄmi z nich, jež se bezprostÏednÄ týkají práce objektovÄ orientovaných analytikÐ a návrháÏÐ. Podrobnosti týkající se ostatních aspektÐ metodiky UP najdete v knize [Rumbaugh 1] nebo v dalších knihách uvedených v bibliografii. V této publikaci se seznámíte s jazykem UML a se souvisejícími analytickými a návrhovými technikami. Poznáte je do té míry, že budete schopni efektivnÄ modelovat skuteÀné projekty. Podle Stephena J. Mellora [Mellor 1] lze modelování v jazyce UML rozdÄlit na tÏi stupnÄ: UML jako náÀrt, Àrta nebo skica – neformální zpÐsob využití jazyka UML, v nÄmž jsou diagramy naÀrtnuty jako pomÐcka k vizualizaci softwarového systému. MÐžete si to pÏedstavit jako situaci, kdy nÄco nÄkomu kreslíte na ubrousek. Takové náÀrtky nemají pÏíliš velkou hodnotu, ale jsou dobrými pomocníky pÏi úvodním vysvÄtlení základní myšlenky. Proto také nejsou archivovány a obvykle konÀí v koši. K tvorbÄ podobných neformálních náÀrtÐ se obvykle používají bílé tabule nebo kreslicí nástroje jako Visio nebo PowerPoint (www.microsoft.com). UML jako detailní plán – mnohem formálnÄjší a hlavnÄ pÏesnÄjší postup, v nÄmž je jazyk UML využíván k podrobné specifikaci softwarového systému. Tato fáze se podobá architektonickým plánÐm neboli strojovým návrhÐm. Model UML je aktivnÄ uchováván a stává se dÐležitou souÀástí celého projektu. Tento postup vyžaduje užití skuteÀných modelovacích nástrojÐ, jako jsou napÏíklad Rational Rose (www.rational.com) nebo MagicDraw UML (www.magicdraw.com). Spustitelný jazyk UML – pomocí architektury MDA (Model Driven Architecture) lze modely UML použít jako programovací jazyk. Modely UML opatÏíte takovými detaily, jež umožní pÏeklad systému pÏímo

20

Předmluva

z modelu. Jde o nejformálnÄjší a nejpÏesnÄjší zpÐsob využití jazyka UML v praxi a z našeho pohledu jde o budoucnost softwarového vývoje. Chcete-li postupovat takto, musíte mít k dispozici modelovací nástroj UML s podporou architektury MDA, napÏíklad ArcStyler (www.arcstyler.com). Problematika architektury MDA ale pÏekraÀuje rámec této knihy, i když se jí krátce vÄnujeme v podkapitole 1.4. V této knize se na jazyk UML soustÏedíme jako na formu detailního plánu. Techniky, jež se bÄhem jejího Àtení nauÀíte, lze využít rovnÄž i v pÏípadÄ, že chcete jazyk UML používat jako spustitelný jazyk. NauÀíte-li se jazyk UML používat jako detailní plán, budete jej schopni pÏirozeným zpÐsobem využít také ke skicování neformálních náÀrtÐ. Snažili jsme se, aby náš výklad jazyka UML a metodiky Unified Proces byl co možná nejvíce pÏímoÀarý, nekomplikovaný, jasný a srozumitelný.

Konvence Takto jsou ozna:eny odstavce, v nichž se vám snažíme sd?lit dSležitou informaci, kterou byste nem?li pdehlédnout.

Abychom vám orientaci v knize maximálnÄ usnadnili, vložili jsme do každé kapitoly osnovu v podobÄ diagramu Àinností UML. ZmiÉované diagramy vyjadÏují poÏadí, v nÄmž byste jednotlivé oddíly mÄli Àíst. PÏíklad takového diagramu je uveden na obrázku 1.

Obrázek 1:

Ukázka diagramu aktivit

VÄtšina zde uvádÄných diagramÐ jsou diagramy UML. Poznámky zobrazené šedou barvou však souÀástí syntaxe jazyka UML nejsou.

Předmluva

Aby byl text co nejpÏehlednÄjší a abyste mohli lépe sledovat to, co je v dané kapitole, podkapitole nebo oddílu nejdÐležitÄjší, použili jsme pro urÀité typy sdÄlení odlišného formátu. NapÏíklad: Takto jsou zobrazeny prvky jazyka UML a programové výpisy projednávaného kódu.

Jak číst tuto knihu Je tak mnoho knih a tak málo Àasu, abychom je mohli pÏeÀíst! PrávÄ proto jsme naši knihu koncipovali tak, aby ji bylo možné pÏeÀíst nÄkolika rÐznými zpÐsoby (mimo jiné od zaÀátku do konce) a abyste si zpÐsob Àetby mohli vybrat sami.

Metoda rychlého vyhledávání Tuto metodu zvolte, chcete-li o tématech projednávaných v celé knize nebo jen v urÀité kapitole získat celkový pÏehled. Získáte tím „souhrn Ïízení“:

Vyberte kapitolu, prostudujte diagram Àinností, abyste vÄdÄli, kam se pÏi ÀetbÄ dostanete, projdÄte jednotlivé obrázky a poznámky na okraji, pÏeÀtÄte oddíl „¡emu jste se nauÀili“, vraÚte se k oddílu, který vás zajímá a pÏeÀtÄte jej.

ZmiÉovaný postup je velmi rychlým a efektivním zpÐsobem pro získávání dílÀích informací, které tato kniha obsahuje. PravdÄpodobnÄ budete velmi pÏíjemnÄ pÏekvapeni, kolik informací lze takto vyhledat! Metoda rychlého vyhledávání je nejefektivnÄjší, umíte-li na poÀátku hledání jasnÄ formulovat, co chcete najít. NapÏíklad: „Chci pochopit, jak se používá modelování pÏípadÐ užití.“

Referenční příručka Chcete-li se nauÀit urÀité podmnožinÄ jazyka UML nebo vybrané technice, využijte podrobný rejstÏík a tabulku obsahu. Oba zmínÄné nástroje by vám mÄly usnadnit rychlé a efektivní vyhledání požadované informace.

Opakování Text této knihy lze procházet a opakovat dvÄma rÐznými zpÐsoby: PotÏebujete-li co nejrychleji a nejefektivnÄji osvÄžit znalosti jazyka UML, ÀtÄte souhrny „¡emu jste se nauÀili“, umístÄné na konci jednotlivých kapitol. Nebudete-li nÄÀemu rozumÄt, jednoduše se vraÚte k pÏíslušnému oddílu a prostudujte jej Máte-li více Àasu, mÐžete procházení jednotlivých kapitol omezit na studium diagramÐ a postranních poznámek.

21

22

Předmluva

Metoda povrchního čtení Máte-li volnou chvilku, otevÏete knihu na náhodnÄ vybrané stránce. PÏi tvorbÄ této knihy jsme se snažili o to, aby na každé stránce bylo nÄco zajímavého. Bez ohledu na to, jak dobÏe se v jazyce UML orientujete, budete zajisté pÏekvapeni, že stále existují vÄci, kterým se mÐžete pÏiuÀit.

Cestovní mapa této knihy Na obrázku 2 si mÐžete prohlédnout cestovní mapu této knihy. NaznaÀili jsme v ní poÏadí, v nÄmž byste mÄli jednotlivé kapitoly Àíst. Diagram také naznaÀuje, ve kterých kapitolách jsou popisovány pokroÀilé techniky, jejichž Àetbu mÐžete pÏi prvním prÐchodu knihy pÏeskoÀit.

Předmluva

Obrázek 2

23


÷ Á S T

Kapitola 1

Co je to vlastně UML? 11

1.1 Kudy kam?

Obrázek 1.1

28

Část 1 – Úvod do jazyka UML a metodiky Unified Process

V této kapitole najdete struÀný pÏehled historie a vyšší struktury jazyka UML. Zmíníme se o mnoha tématech, která rozpracujeme v následujících kapitolách. ZaÀáteÀníci by mÄli zaÀít právÄ studiem historie a základÐ tohoto zajímavého jazyka. PatÏíte-li mezi pokroÀilejší uživatele jazyka UML, pÏípadnÄ pokud své znalosti historie jazyka UML nepotÏebujete dále rozšiÏovat, pÏejdÄte k oddílu 1.6, kde najdete výklad struktury jazyka UML. Výklad se vÄtví na ÀtyÏi hlavní témata, která mÐžete Àíst v libovolném poÏadí. Oddíl 1.7 obsahuje informace o stavebních blocích jazyka UML, oddíl 1.8 pojednává o obecné mechanice v jazyku UML a oddíl 1.9 obsahuje výklad architektury jazyka UML (1.10).

1.2 Co je to UML? Jazyk UML (Unified Modeling Language, unifikovaný modelovací jazyk) je univerzální jazyk pro vizuální modelování systémÐ. PÏestože je nejÀastÄji spojován s modelováním objektovÄ orientovaných softwarových systémÐ, má mnohem širší využití, což vyplývá z jeho zabudovaných rozšiÏovacích mechanismÐ. Jazyk UML není metodika. Je to univerzální jazyk pro vizuální modelování. Metodikou je Unified Process.

Jazyk UML byl navržen proto, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství. Jako takový je explicitnÄ navržen takovým zpÐsobem, aby jej mohly implementovat všechny nástroje CASE (computer-aided software engineering). ZmínÄná koncepce vychází z pochopení skuteÀnosti, že se rozsáhlé softwarové systémy obvykle bez podpory nástrojÐ CASE neobejdou. Diagramy vytvoÏené v jazyku UML jsou srozumitelné pro lidi, ale navíc je mohou snadno interpretovat i programy CASE. Je nesmírnÄ dÐležité uvÄdomit si, že jazyk UML nenabízí žádný druh metodiky modelování. PÏirozenÄ, urÀité aspekty metodiky mÐžeme najít v každém z prvkÐ, z nichž se model UML skládá. Samotný jazyk UML však poskytuje pouze vizuální syntaxi, kterou mÐžeme využít pÏi sestavování svých modelÐ. Unified Process již ovšem metodikou je. SdÄluje nám, jaké pracovníky musíme využít, jaké Àinnosti vykonat a jaké produkty vyrobit, aby se nám podaÏilo sestavit model funkÀního softwarového systému. Jazyk UML není vázán na žádnou specifickou metodiku nebo životní cyklus. Lze jej použít spoleÀnÄ se všemi existujícími metodami. Unified Process využívá jazyk UML jako vlastní syntaxi pro vizuální modelování. Z tohoto pohledu lze metodiku Unified Process považovat za upÏednostÉovanou metodu užití jazyka UML, protože je pro tento jazyk nejlépe adaptovaná. Jazyk UML však mÐže poskytovat (a také poskytuje) podporu vizuálního modelování i pro jiné metody. (Chcete-li se seznámit s pÏíkladem vyzrálé metodiky, která pro vizuální syntaxi rovnÄž využívá jazyk

Kapitola 1 – Co je to vlastně UML?

UML, navštivte adresu www.open.org.au, kde najdete domovské stránky metodiky OPEN (Object-oriented Process, Environment and Notation).) ZámÄrem jazyka UML a metodiky UP byla od jejich vzniku podpora nejlepších postupÐ používaných v softwarovém inženýrství, vycházejících z ovÄÏených zkušeností posledního desetiletí. K tomuto úÀelu byly v jazyku UML a metodice UP unifikovány všechny pÏedchozí pokusy o tvorbu jazykÐ pro vizuální modelování a proces softwarového inženýrství do nejÀistšího Ïešení.

1.3 Zrození jazyka UML Do roku 1994 se svÄt objektovÄ orientovaných metod zmítal v chaosu. Existovalo nÄkolik soupeÏících jazykÐ pro vizuální modelování a také nÄkolik metodik. AÀkoli s sebou každá metodika pÏinesla nÄco nového – a obvykle též novou notaci – rozmanité inovace jen výjimeÀnÄ znamenaly i novou kvalitu. Všechny mÄly své stoupence i protivníky. VyjádÏeno v jazyku pro vizuální modelování (viz obrázek 1.2) – více než polovinu tehdejšího trhu si mezi sebe rozdÄlily metody Booch (Booch) a OMT (Object Modeling Technique, Rumbaugh). Na stranÄ metodik si jasnÄ nejlépe vedla metodika Objectory (Jacobson). Mnoho autorÐ prohlašovalo, že mají svou „metodu“. Ve skuteÀnosti však mÄli pouze syntaxi pro vizuální modelování a kolekci více Ài ménÄ užiteÀných aforismÐ a pouÀek.

Obrázek 1.2

Jedním z prvních pokusÐ o sjednocení byla metodika Fusion (Coleman, 1994). PÏestože byla pomÄrnÄ hlasitÄ medializována, nebyli do její pÏípravy zapojeni autoÏi metod, které tvoÏili pro podstatnou Àást tehdejšího trhu (Booch, Jacobson a Rumbaugh). Metodika Fusion skonÀila nenávratnÄ v propadlišti dÄjin, kdy se autoÏi metod Booch a Rumbaugh spojili ve firmÄ Rational Corporation, která pracovala na tvorbÄ jazyka UML. Tato skuteÀnost v té dobÄ znepokojovala mnoho z nás, protože spoleÀnost Rational najednou získala více než poloviÀní podíl na trhu s metodikami.

29

30


Naše obavy však byly plané, protože se jazyk UML stal otevÏeným prÐmyslovým standardem. V roce 1996 navrhlo sdružení OMG (Object Management Group, spojení dodavatelÐ, které vzniklo za úÀelem definování a prosazování specifikací objektÐ CORBA) specifikaci RFP (Request For Proposal, postup vytváÏení standardu v síti Internet a zároveÉ požadavek na oznaÀení takto vzniklého standardu) pro objektovÄ orientovaný jazyk pro vizuální modelování, v nÄmž jako standard navrhlo jazyk UML. V roce 1997 sdružení OMG jazyk UML pÏijalo a první prÐmyslový standard objektovÄ orientovaného jazyka pro vizuální modelování byl na svÄtÄ! Od té doby všechny jiné soupeÏící metody postupnÄ upadaly v zapomnÄní a jazyk UML byl veÏejností bez námitek pÏijat. V roce 2000 byl jazyk UML významnÄ rozšíÏen o sémantiku akcí. Ta slouží k popisu chování množiny primitivních akcí, jež lze implementovat pomocí specifických akÀních jazykÐ. Sémantika akcí ve spojení s akÀními jazyky umožÉuje podrobnÄjší specifikací prvkÐ souvisejících s chováním modelÐ UML (napÏíklad operací) pÏímo v modelu UML. Jedná se o významný pokrok, neboÚ poskytuje možnost dokonÀit specifikaci UML výpoÀetnÄ, což v koneÀném dÐsledku umožÉuje modely UML spouštÄt. PÏíkladem implementace jazyka UML s vestavÄným akÀním jazykem s podporou sémantiky akcí je xUML spoleÀnosti Kennedy Carter (ww.kc.com). BÄhem aktualizace této knihy pro 2. vydání byly v roce 2005 dokonÀeny práce na finalizaci specifikace jazyka UML 2.0. Popisovaný jazyk je nyní velmi vyspÄlým modelovacím jazykem. Od uvolnÄní jeho první verze uplynulo témÄÏ sedm let a za tu dobu byla jeho hodnota potvrzena v tisících softwarových projektÐ na celém svÄtÄ. V jazyce UML 2 bylo zavedeno mnoho nových prvkÐ vizuální syntaxe. NÄkteré z nich nahrazují (a objasÉují) existující syntaxi verzí 1.x. Jiné jsou úplnÄ nové a ztÄlesÉují novou sémantiku pÏidanou k jazyku. Jazyk UML vždy poskytoval mnoho rÐzných možností zobrazení modelovaných prvkÐ, ale ne všechny modelovací nástroje umožÉovaly tak pestrou formu vyjádÏení modelu. V této knize se snažíme konzistentnÄ používat nejbÄžnÄjší syntaktické varianty. Pokud ale dospÄjeme k názoru, že jiná varianta poslouží pÏi bÄžném modelování lépe, neopomeneme tuto skuteÀnost zdÐraznit. UrÀité syntaktické možnosti jsou velmi specializovány a budeme se o nich zmiÉovat nanejvýš jen mimochodem. PÏestože v jazyce UML verze 2 najdete mnoho syntaktických odlišností vÐÀi pÏedchozím verzím, máme pro vás jednu velmi dobrou zprávu. Základní pravidla jsou víceménÄ stejná. Pro modeláÏe zvyklé na pÏedchozí verze jazyka by nemÄl být pÏechod na novou verzi UML nijak obtížný. NejzásadnÄjší zmÄny se týkají v podstatÄ metamodelu a vÄtšina modeláÏÐ je zÏejmÄ pÏímo ani nepostÏehne. Metamodel UML je modelem jazyka UML vyjádÏeným pomocí množiny jazyka UML. Ta pÏesnÄ definuje syntaxi a sémantiku všech modelovaných prvkÐ jazyka UML, s nimiž se v této


knize setkáte. ZmiÉované zmÄny metamodelu se vÄtšinou týkají zpÏesnÄní specifikace jazyka UML a zajištÄní její konzistence. Grady Booch v jedné ze svých knih Ïíká: „Máte-li dobrý nápad, je mÐj!“ Tento výrok struÀnÄ vyjadÏuje filozofii jazyka UML – pÏejímá to nejlepší, co doposud vzniklo a integruje to do vašeho nápadu. Je to nejobecnÄjší forma znovupoužitelnosti. Jazyk UML spojuje mnoho nejlepších myšlenek pÏejatých z „prehistorických“ metod, pÏiÀemž zavrhuje nÄkteré svérázné úlety, které se v tÄchto metodách nacházely.

1.4 MDA – budoucnost jazyka UML Budoucnost jazyka UML mÐže být definována skrze poslední iniciativu organizace OMG nazvanou MDA (Model Driven Architecture). PÏestože tato kniha není vÄnována problematice architektury MDA, pokusíme se vás s ní v této podkapitole alespoÉ struÀnÄ seznámit. Více informací najdete na webových stránkách MDA organizace OMG (www.omg.org/mda) a v knize MDA Explained [Kleppe 1] a Model Driven Architecture [Frankel 1]. Architektura MDA definuje pÏedstavu vývoje softwaru na základÄ modelÐ. Podstatou zmiÉované pÏedstavy je skuteÀnost, že model Ïídí výrobu architektury spustitelného softwaru. Tak je tomu do urÀité míry už i dnes, ale architektura MDA nabízí takový stupeÉ automatizace zmiÉovaného procesu, s jakým se v souÀasné dobÄ setkáte jen zÏídka. Podle MDA je software vyrábÄn jako sled transformací modelÐ provádÄných v modelovacím nástroji kompatibilním s architekturou MDA. Abstraktní model nezávislý na poÀítaÀi (CIM, computer-independent model) je použit jako základ modelu PIM (modelu nezávislého na platformÄ; platform-independent model). Model PIM je následnÄ transformován do modelu PSM (což je model závislý na konkrétní platformÄ; platformspecific model), jenž je nakonec transformován do finálního kódu. PÏedstava modelu v architektuÏe MDA je velmi obecná a kód je považován jen za velmi konkrétní druh modelu. Na obrázku 1.3 si mÐžete prohlédnout ÏetÄzec transformací v architektuÏe MDA. Model nezávislý na poÀítaÀi (model CIM) je velmi obecný a zachycuje klíÀové požadavky na systém, jakož i oborový slovník související s Ïešeným problémem. Forma zachycení požadavkÐ a slovníku je nezávislá na poÀítaÀích. Je to model té Àásti Àinnosti, kterou chcete automatizovat. Tvorba zmiÉovaného modelu je nepovinná, ale pokud se jej rozhodnete vytvoÏit, použijete ho jako základ tvorby modelu PIM (modelu nezávislého na platformÄ). Model PIM je model, který vyjadÏuje sémantiku Àinnosti softwarového systému nezávisle na použité platformÄ (EJB, .NET apod.). Je obvykle stejnÄ obecný jako analytický model, s nímž se seznámíte pozdÄji. Je však úplnÄjší. Musí být, protože obsahuje dostaÀující základ vhodný k transformaci do modelu PSM (modelu urÀeného pro konkrétní platformu), z nÄhož lze generovat výsledný kód. UrÀitÄ stojí za zmínku, že pojem „ne-

31

32


závislý na platformÄ“ nemá v podstatÄ žádný význam, dokud neurÀíte platformu nebo platformy, na nichž chcete být nezávislí! RÐzné nástroje MDA podporují odlišné úrovnÄ nezávislosti na platformách.

Obrázek 1.3

Chceme-li vytvoÏit model PSM (model spojený s urÀitou platformou), ozdobíme model PIM informacemi souvisejícími s použitou platformou. Výsledkem transformace je zdrojový kód generovaný z modelu PSM pro vybranou cílovou platformu. Z dostateÀnÄ úplného modelu PSM je generován veškerý zdrojový kód a pomocné artefakty, jako jsou dokumentace, simulaÀní program, soubory sestavení a deskriptory nasazení. Aby k tomu ale mohlo dojít, musí být model UML výpoÀetnÄ úplný – sémantika všech operací musí být vyjádÏena v akÀním jazyce. Již jsme se zmiÉovali, že urÀité nástroje MDA jsou takovým jazykem vybaveny. NapÏíklad nástroj iUML spoleÀnosti Kennedy Carter (www.kc.com) nabízí jazyk ASL (Action Specification Language), jenž vyhovuje sémantice akcí jazyka UML 2. AkÀní jazyk je obecnÄjší než jazyky typu Java a C++ a používá se k tvorbÄ výpoÀetnÄ úplných modelÐ UML. Další nástroje MDA, tÏeba ArcStyler (ww.io-software.com), umožÉují generování zhruba 70–90 % kódu a dalších artefaktÐ. Ovšem tÄla operací je stejnÄ tÏeba dokonÀit v cílovém jazyce (napÏíklad v JavÄ). Podle architektury MDA je zdrojový kód (napÏíklad v JavÄ a v C#) pouze „strojovým kódem“, jenž je výsledkem pÏekladu modelÐ UML. Tento kód je generován podle potÏeby pÏímo z modelu PSM. Jako takový má podle architektury MDA ve vývoji pÏirozenÄ menší hodnotu než modely UML. Architektura MDA posouvá modely UML z jejich souÀasné role pÏedchÐdcÐ ruÀnÄ vytváÏeného kódu do pozice primárního mechanismu tvorby kódu.


Už v dobÄ, kdy byl originál knihy odevzdáván do tisku, pÏidávalo možnosti MDA do svých produktÐ stále více výrobcÐ. Všechny podrobnosti zjistíte na webu OMG MDA. Navíc existuje nÄkolik velmi slibných otevÏených iniciativ MDA – napÏíklad Eclipse Modeling Framework (www.eclipse .org/emf) a AndroMDA (www.andromda.org). Tuto podkapitolu jsme pojali jen jako malé okénko do svÄta MDA. Zcela jistÄ jsme nevyÀerpali všechna témata spojená s MDA, a proto všem ÀtenáÏÐm návštÄvu zmiÉovaných odkazÐ, jež vám poskytnou mnohem více dÐležitých informací, velmi doporuÀujeme.

1.5 Proč „unifikovaný“? Unifikace jazyka UML nevychází pouze z historických mÄÏítek. Jazyk UML se (zpravidla úspÄšnÄ) snaží o unifikaci rÐzných domén. Vývojový cyklus. Jazyk UML nabízí vizuální syntaxi pro modelování bÄhem celého vývojového cyklu softwarového projektu – požadavky na analýzu poÀínaje a implementací konÀe. AplikaÀní domény. Jazyk UML byl vytvoÏen jako nástroj pro modelování Àehokoliv systémy zasazenými do reálného Àasu poÀínaje a podpÐrnými systémy rozhodování konÀe. ImplementaÀní jazyky a platformy. Jazyk UML je nezávislý na jakémkoli programovacím jazyce a na jakékoli platformÄ. PÏirozenÄ, že má znamenitou podporu ÀistÄ objektovÄ orientovaných programovacích jazykÐ, jako jsou Smalltalk, Java, C# apod. Je ovšem velmi efektivní rovnÄž pro hybridní objektovÄ orientované jazyky, jako je C++, i pro jazyky založené na objektech, napÏíklad Visual Basic. Používá se kupodivu rovnÄž pro modelování projektÐ vedených v neobjektových jazycích, napÏíklad v jazyce C. Vývojové procesy. PÏestože je metodika UP spolu s jeho variantami pravdÄpodobnÄ nejvíce upÏednostÉovanou metodikou vývoje objektovÄ orientovaných systémÐ, mÐže jazyk UML podporovat mnoho dalších osnov procesu tvorby softwarového vybavení (a také to dÄlá). Vlastní interní pojmy. Jazyk UML se o vnitÏní jednotu a konzistenci snaží prostÏednictvím malé množiny interních pojmÐ. Je pravda, že v této oblasti není vždy úspÄšný. Lze však Ïíci, že každý další pokus je mnohem dokonalejší než jeho pÏedchÐdci.

1.6 Objekty a jazyk UML Základním pÏedpokladem jazyka UML je skuteÀnost, že umožÉuje modelování softwaru, stejnÄ jako dalších systémÐ jako kolekce spolupracujících objektÐ. PÏestože tato pÏedstava zcela zÏejmÄ zapadá do modelu objektovÄ orientovaných softwarových systémÐ a programovacích jazykÐ, funguje stejnÄ spolehlivÄ v obchodních a podnikatelských procesech a dalších aplikacích.

33

34


Uve×me dva aspekty modelu UML. Jazyk UML utvádí sv?t jako systém vzájemn? se ovlivGujících objektS. Objekt je soudržné seskupení dat a funkcí.

Statická struktura. Popisuje, jednak jaké typy objektÐ jsou pro modelování daného systémÐ dÐležité, jednak jak spolu tyto objekty souvisejí. Dynamické chování. Popisuje životní cyklus zmiÉovaných objektÐ a zpÐsob jejich vzájemné spolupráce s cílem dosáhnout požadované funkce navrhovaného systému. Oba výše zmínÄné aspekty jdou na své pouti ruku v ruce jako nerozluÀný pár. Žádný z nich není bez druhého úplný. Objekty (a tÏídami) se budeme podrobnÄ zabývat v 7. kapitole. Do té doby považujme objekty za soudržné seskupení dat s urÀitým chováním. Objekty, jinak ÏeÀeno, obsahují specifické informace a mohou vykonávat urÀité funkce.

1.7 Struktura jazyka UML Funkci jazyka UML jako jazyka vizuálního porozumíte nejlépe, podíváte-li se na jeho strukturu. Je znázornÄna na obrázku 1.4 (jak se dovíte v následujících kapitolách, je to validní diagram UML). Struktura jazyka UML obsahuje tyto souÀásti: Stavební bloky. Jsou to základní prvky modelu, relace a diagramy. SpoleÀné mechanismy. Obecné zpÐsoby, jimiž v jazyku UML dosáhnete specifických cílÐ. Architektura. Pohled v jazyku UML na architekturu navrhovaného systému.

Obrázek 1.4

PorozumÄní struktuÏe jazyka UML je mimo jiné základem užiteÀného uspoÏádání informací pÏedkládaných v této knize. Tento fakt zdÐrazÉuje rovnÄž nepÏehlédnutelnou skuteÀnost, že jazyk UML je sám navrhovaným a sestavovaným systémem. Byl ve skuteÀnosti modelován a navržen právÄ v jazyce UML! Tento návrh oznaÀujeme za metamodel jazyka UML.


1.8 Stavební bloky jazyka UML Podle knihy The Unified Modeling Language User Guide (PrÐvodce uživatele jazykem UML, Booch) je jazyk UML sestaven z pouhých tÏí stavebních blokÐ: Z pÏedmÄtÐ (things), což jsou samotné prvky modelu, vztahÐ (relationships), jež jsou pojítkem mezi pÏedmÄty (relace urÀují, jak spolu dva nebo více pÏedmÄtÐ významovÄ souvisí), a diagramÐ (diagrams), což jsou pohledy na modely UML; ukazují kolekce pÏedmÄtÐ, které „vyprávÄjí pÏíbÄh“ o softwarovém systému a jsou naším zpÐsobem vizualizace toho, co systém bude dÄlat (analytické diagramy, analysis-level diagrams), a toho, jak to bude dÄlat (návrhové diagramy, design-level diagrams).

Obrázek 1.5

V následujících tÏech oddílech se zamÄÏíme pÏedevším na pÏedmÄty, relace a diagramy.

1.9 Předměty (things) „Pdedm?ty“ jsou podstatnými jmény modelu UML.

PÏedmÄty (rovnÄž „vÄci“ nebo abstrakce) dÄlíme v jazyku UML na: Strukturní abstrakce (structural things), což jsou podstatná jména modelu UML, jako jsou tÏídy, rozhraní, spolupráce, pÏípad užití, aktivní tÏída, komponenta, uzel; chování (behavioural things), což jsou slovesa modelu UML, napÏ. interakce, stav; seskupení (grouping things), což jsou balíÀky používané k seskupování sémanticky (významovÄ) souvisejících prvkÐ modelu do soudržných jednotek, poznámky (annotational things), anotace, které lze k modelu pÏipojit s úmyslem zachytit informaci sestavenou jen k tomuto úÀelu (což se velmi podobá zvýraznÄní žlutou tužkou tak, aby poznámka v okolním textu vynikala).

35

36


Jednotlivými pÏedmÄty (abstrakcemi) a jejich úspÄšnou aplikací v modelování UML se budeme podrobnÄji zabývat ve druhé Àásti knihy.

1.9.1 Relace (relationships) Relace umožÉuje ukázat na modelu, jaký je vztah mezi dvÄma pÏedmÄty. Znamenitou analogií role, kterou relace hrají v modelech UML, je rodina a vztahy mezi jejími jednotlivými Àleny. Relace umožÉují zachytit významový (sémantický) vztah mezi pÏedmÄty. Vztahují se na strukturní abstrakce a seskupování a jsou znázornÄny v tabulce 1.1. NesmírnÄ dÐležitou souÀástí modelování v jazyku UML je porozumÄní pÏesné sémantice rÐzných typÐ relací. Její výklad a dÐkladnÄjší prozkoumání však odložíme do dalších kapitol. Pro tuto chvíli si vystaÀíme s tabulkou 1.1, která nabízí struÀný pÏehled. Tabulka 1.1

Typ relace

Syntaxe UML zdroj cíl

Strudný popis

Oddíl

Závislost (Dependency)

Zmgna v urditém pedmgtu ovlivyuje význam zá- 9.5 vislého pedmgtu.

Asociace (Association)

Popis množiny spojení mezi objekty.

9.4

Agregace (Aggregation)

Cílový prvek je soudástí zdrojového prvku

18.4

Kompozice (Composition)

Silngjší forma agregace (má více omezení)

18.5

Ochranná nádoba (Containment)

Zdrojový prvek obsahuje cílový prvek

11.4

Zobecngní (Generalization)

Jeden prvek je specializací jiného prvku a lze jej nahradit obecngjším (univerzálngjším) prvkem.

10.2

Realizace (Realization)

Asociace mezi klasifikátory, kde jeden klasifikátor 12.3 urduje dohodu, jejíž uskutedngní zaruduje druhý klasifikátor

1.9.2 Diagramy Ve všech nástrojích CASE (nástroje pro tvorbu programového vybavení pomocí poÀítaÀe, Computer-Aided Software Engineering) založených na jazyku UML jsou každý novÄ vytvoÏený pÏedmÄt nebo novÄ vytvoÏená relace automaticky pÏidávány do vznikajícího modelu. Model je repositáÏem všech pÏedmÄtÐ a relací vytvoÏených k tomu, aby popisovaly požadované chování softwarového systému, který se snažíte navrhnout.


Diagramy jsou okna nebo pohledy na model. Diagram není model! V tom je veliký rozdíl, protože pÏedmÄty a relace lze z diagramu odstranit; lze je odstranit dokonce ze všech diagramÐ – ale v modelu mohou stále existovat. Ve skuteÀnosti v nÄm zÐstanou až do té doby, dokud nebudou explicitnÄ vymazány z modelu. Velmi Àastou chybou zaÀínajících analytikÐ a návrháÏÐ v jazyku UML je odstranÄní pÏedmÄtu z diagramÐ, ale jeho ponechání v modelu. Diagramy jsou pouze pohledy na model.

Celkem existuje tÏináct rÐzných typÐ diagramÐ UML a všechny si je mÐžete prohlédnout na obrázku 1.6. Každý obdélník zastupuje jeden typ diagramu. Je-li text v obdélníku napsán kurzivou, zastupuje obdélník abstraktní kategorii typu diagramu. Existuje šest rÐzných typÐ strukturovaných diagramÐ. BÄžný text oznaÀuje konkrétní diagram, který byste ve skuteÀnosti mohli vytvoÏit. Obdélníky s šedým pozadím oznaÀují konkrétní typy diagramÐ, jež byly novÄ zavedeny až v jazyce UML 2. ZmiÉovanou množinu diagramÐ lze rozdÄlit na ty, které modelují statickou strukturu systému (takzvaný statický model), a na ty, které modelují dynamickou strukturu systému (dynamický model). Statický model zachycuje pÏedmÄty a strukturní asociace mezi pÏedmÄty. Dynamický model naproti tomu zachycuje zpÐsob, jímž na sebe jednotlivé pÏedmÄty navzájem pÐsobí, aby bylo dosaženo požadovaného chování softwarového systému. Statickým a dynamickým modelÐm se budeme vÄnovat až od druhé Àásti této knihy. Neexistuje žádné pevnÄ stanovené poÏadí, v nÄmž byste mÄli své diagramy UML vytváÏet. PÏesto se obvykle zaÀíná diagramem pÏípadu užití, který definuje rozsah platnosti navrhovaného systému. Ve skuteÀnosti Àasto pracujete soubÄžnÄ s nÄkolika rÐznými diagramy zároveÉ. Každý z nich vybrušujete postupnÄ – kdykoli je odhalen další detail navrhovaného softwarového systému. Tak jsou diagramy nejen pohledem na model, ale rovnÄž prvoÏadým a základním mechanismem pro zadávání nových informací do existujícího modelu.

Obrázek 1.6

37

38


V jazyce UML 2 platí pro diagramy nová syntaktická pravidla. Jsou vyznaÀena na obrázku 1.7. Všechny diagramy mohou obsahovat rámeÀek, oblast záhlaví a kontextovou oblast. Oblast záhlaví je nepravidelný pÄtiúhelník, jenž obsahuje druh diagramu (nepovinný údaj), jeho název a parametry (také nepovinnÄ).

Obrázek 1.7

Stereotyp «kind» (druh) urÀuje typ diagramu. MÄl by popisovat jeden z konkrétních typÐ diagramÐ uvedených na obrázku 1.6. Ve specifikaci jazyka UML sice stojí, že popis druhu diagramu (stereotyp «kind») lze zkrátit, ale specifikace neuvádí seznam standardních zkratek. Druh diagramu budete explicitnÄ uvádÄt jen zÏídka, protože je obvykle patrný z vizuální syntaxe.

Obrázek 1.8


Název (stereotyp «name») by mÄl popisovat sémantiku diagramu (napÏíklad RegistracePÁednášky). Parametry (stereotyp «parameters») poskytují informace nezbytné pro jednotlivé prvky modelu znázornÄné v diagramu. S pÏíklady užití stereotypu «parameters» se v této knize setkáte ještÄ nejednou. Diagram mÐže obsahovat implicitní (pÏedpokládaný, ale nevyjádÏený) rámeÀek. Je tomu tak napÏíklad v situaci, kdy je rámeÀek vyjádÏen oblastí diagramu v modelovacím nástroji. PÏíklad vidíte na obrázku 1.8.

1.10 Obecná mechanika jazyka UML Jazyk UML obsahuje ÀtyÏi spoleÀné mechanismy používané v celém jazyku konzistentnÄ. Popisují ÀtyÏi strategie cesty k modelování objektÐ, jež jsou opakovanÄ používány v rÐzných kontextech v celém jazyce UML. Na zmínÄném pÏíkladu je opÄt patrné, že jazyk UML má vskutku jednoduchou a elegantní strukturu (viz obrázek 1.9).

Obrázek 1.9

1.10.1 Specifikace Specifikace jsou jádrem a podstatou modelu UML. Nabízejí sémantický základ modelu.

Modely UML mají alespoÉ dva rozmÄry – grafický, který umožÉuje vizualizovat model prostÏednictvím diagramÐ a symbolÐ (ikon), a textový, jenž se skládá ze specifikací rÐzných prvkÐ modelu. Specifikace jsou textovým popisem sémantiky jednotlivých prvkÐ. Použijme pÏíklad. TÏídu, jako je tÏeba BankovníÚ¶et, mÐžeme vyjádÏit jako schránku s nÄkolika pÏihrádkami dÄlícími symbol na nÄkolik oddílÐ (viz obrázek 1.10). Tato podoba ovšem nesdÄluje nic o obchodní (podnikatelské) sémantice této tÏídy. Sémantika prvkÐ modelu je zachycena v jejich specifikacích. Bez nich bychom se mohli jenom domnívat, co pÏíslušné prvky modelu ve skuteÀnosti zastupují.

39

40


Diagramy poskytují pohled do zákulisí.

Množina specifikací je „jádrem“ modelu a utváÏí sémantický podklad, který udržuje celý model pohromadÄ a dává mu smysl. RÐzné diagramy jsou rÐznými pohledy nebo obrazovými projekcemi tohoto podkladu. Sémantický podklad je zpravidla udržován pomocí nástroje CASE, jenž obsahuje funkce pro zadávání, prohlížení a úpravy specifikace jednotlivých prvkÐ modelu. Jazyk UML má neobyÀejnou dávku pružnosti a flexibility pro tvorbu modelÐ. V praxi mohou být modely: proškrtané, což znamená, že urÀité prvky jsou sice v podkladu obsaženy, ale v daném diagramu jsou ukryty – napÏíklad proto, aby byl pohled jednodušší, neúplné, což znamená, že urÀité prvky mohou v modelu chybÄt úplnÄ, nekonzistentní, což znamená, že model mÐže obsahovat protimluvy.

Obrázek 1.10

Existence volných pravidel úplnosti a konzistence je nesmírnÄ dÐležitá, protože modely se postupnÄ vyvíjejí a prodÄlávají mnoho zmÄn. PÏesto se klade dÐraz na tvorbu konzistentních modelÐ, které jsou natolik úplné, aby umožÉovaly tvorbu softwarového systému. PÏi modelování v jazyku UML se obvykle zaÀíná tvorbou grafického modelu, který umožÉuje vizualizaci systému. PozdÄji je k podkladu modelu pÏidávána sémantika. Má-li být ovšem model považován za užiteÀný nebo kompletní, musí být sémantika obsažena v podkladu modelu. Není-li, nemáte v ruce žádný model, pouze bezvýznamnou kolekci Àarami propojených ÀtvereÀkÐ a kroužkÐ. Tuto bÄžnou chybu zaÀínajících analytikÐ a návrháÏÐ mÐžeme s klidem nazvat „smrt v zajetí diagramÐ“. Model je diagramy pÏímo pÏeplnÄn, postrádá však specifikaci.


1.10.2 Ornamenty (Adornments) Jednotlivé prvky modelu zdobíme v diagramech UML proto, abychom zdSraznili :i zvýraznili ur:ité dSležité detaily.

Velice pÏíjemnou vlastností jazyka UML je skuteÀnost, že každý prvek modelu je vyjádÏen velmi jednoduchým symbolem, který lze obohatit Ïadou ornamentÐ, je-li tÏeba prostÏednictvím diagramu zobrazit více informací. Tvorbu velmi složitého modelu tedy mÐžete klidnÄ zaÀít pomocí nÄkolika základních symbolÐ s jedním nebo dvÄma ornamenty. PozdÄji však mÐžete model vylepšit dalšími ornamenty. Takto mÐžete postupovat do té doby, dokud pÏíslušný prvek neobsahuje dostateÀný poÀet podrobností. UvÄdomte si, že všechny diagramy UML jsou pouze pohledem na daný model. MÄli byste v nich proto ornamenty používat pouze v pÏípadÄ, kdy zvyšují srozumitelnost a Àitelnost diagramu, pÏípadnÄ tehdy, když zdÐrazÉují urÀitou dÐležitou funkci modelu. V diagramu obvykle není tÏeba zobrazovat všechny podrobnosti. Mnohem dÐležitÄjší je, aby byl diagram srozumitelný, aby znázorÉoval pÏesnÄ ty cíle, jichž chcete dosáhnout, a aby byl snadno Àitelný.

Obrázek 1.11

Na obrázku 1.11 vidíte, že jako nejmenší symbol tÏídy lze použít obdélník, v nÄmž je uveden název tÏídy. Minimalistický pohled modelu lze ovšem snadno rozšíÏit pomocí ornamentÐ. Text zobrazený šedou barvou vyjadÏuje volitelné, nepovinné ornamenty.

1.10.3 Podskupiny Podskupiny (common divisions) popisují rÐzné zpÐsoby vidÄní svÄta. V jazyce UML rozlišujeme dvÄ takové podskupiny: skupinu klasifikátorÐ a instancí a skupinu rozhraní a implementací.

41

42


1.10.3.1 Klasifikátor a instance Klasifikátor (classifier) je abstraktním vyjáddením typu pdedm?tu (napdíklad bankovní ú:et). Instance je naproti tomu konkrétním výskytem abstraktní pdedstavy – napdíklad mSj bankovní ú:et :i váš bankovní ú:et.

Jazyk UML pÏedpokládá, že mÐžeme mít abstraktní pÏedstavu o typu pÏedmÄtu (napÏíklad bankovním úÀtu), ale i pÏedstavu specifickou – o konkrétní instanci naší abstrakce (o mém úÀtu nebo o vašem úÀtu). Abstraktním vyjádÏením typu pÏedmÄtu je klasifikátor, zatímco specifické, konkrétní pÏedmÄty jsou považovány za instance. Tato definice je velmi dÐležitá. NaštÄstí si ji lze velmi snadno osvojit. Klasifikátory a instance jsou všude kolem nás. VezmÄte si tÏeba tuto knihu o jazyku UML. Mohli bychom Ïíci, že abstraktní myšlenkou této knihy je „jazyk UML a metodika UP“ a že existuje mnoho instancí této knihy – jednu z nich právÄ držíte v rukou. Brzo pochopíte, že definice klasifikátoru a instance je klíÀovým pojmem, který prostupuje celým jazykem UML. V jazyce UML je instance obvykle znázornÄna stejným symbolem jako odpovídající klasifikátor. Názvy instancí jsou ovšem na symbolu podtrženy. AlespoÉ zpoÀátku to mÐžete považovat za dÐvtipný zpÐsob rozlišování zmiÉovaných typÐ pÏedmÄtÐ. Jazyk UML 2 nabízí bohatou taxonomii tÏiceti tÏí klasifikátorÐ. Ty ÀastÄji používané jsou uvedeny v tabulce 1.2. PodrobnÄji se s nimi seznámíte v uvedených oddílech. Tabulka 1.2

Rozhraním jsou napdíklad tla:ítka na :elním panelu videorekordéru. Implementací je mechanismus uvnitd videorekordéru.

Klasifikátor

Sémantika

Oddíl

Aktér

Role vngjšího uživatele systému, jemuž systém slouží k užitku.

4.3.2

Tída

Popis množiny objekt sdílejících stejné vlastnosti.

7.4

Komponenta

Modulární a vymgnitelná soudást systému se zapouzdeným obsahem.

19.8

Rozhraní

Kolekce operací používaných k urdení služby poskytované tídou nebo komponentou.

19.3

Uzel

Fyzický prvek obsahující spustitelný kód, který zastupuje výpodetní prostedek – píkladem mže být teba PC.

24.4

Signál

Asynchronní zpráva pedávaná mezi objekty.

15.6

Pípad užití

Popis posloupností dinností, které systém vykoná pro uspokojení poteb uživatele.

4.3.3

1.10.3.2 Rozhraní a implementace PÏi práci v jazyce UML vycházíme ze zásady oddÄlení toho, co pÏedmÄt vykonává (jeho rozhraní), od toho, jak to vykonává (jeho implementace). NapÏíklad: Ïídíte-li auto, používáte je prostÏednictvím velmi jednoduchého a velmi dobÏe definovaného rozhraní. ZmínÄné rozhraní je však v rÐzných vozidlech implementováno jinak. Rozhraní definuje dohodu (jež má mnoho spoleÀného s právní dohodou), která zaruÀuje, Àím se budou jednotlivé implementace Ïídit. OddÄlení toho,


co je slibováno, od skuteÀné implementace daného slibu je v jazyku UML velmi dÐležitým pojmem. PodrobnÄ se jím budeme zabývat v 17. kapitole. Konkrétní pÏíklady rozhraní a implementace jsou všude. NapÏíklad tlaÀítka na pÏedním panelu videorekordéru poskytují (relativnÄ) jednoduché rozhraní k ve skuteÀnosti velmi složitému mechanismu. Rozhraní nás pÏed touto složitostí chrání tím, že ji pÏed námi ukrývá.

1.10.4 Mechanismy rozšiřitelnosti UML je rozšiditelný modelovací jazyk.

AutoÏi jazyka UML si uvÄdomili, že návrh naprosto univerzálního modelovacího jazyka, který by uspokojil potÏeby všech uživatelÐ v souÀasnosti i v budoucnu, je prostÄ nemožný. Z tohoto dÐvodu zahrnuli do jazyka tÏi velice jednoduché mechanismy, umožÉující jeho rozšiÏitelnost. Všechny tÏi jsou uvedeny v tabulce 1.3 MechanismÐm rozšiÏitelnosti se budeme vÄnovat v následujících tÏech oddílech. Tabulka 1.3

Mechanismy rozšiitelnosti

Popis

Omezení (constraints)

Omezující podmínky rozšiují sémantiku prvku tím, že umožyují pidávat k ngmu nová pravidla.

Stereotypy (stereotypes)

Stereotyp umožyuje definovat nový prvek modelu UML, jenž je založen na existujícím prvku – definujeme sémantiku stereotypu. Stereotypy pidávají do metamodelu jazyka UML nové prvky.

Oznadené hodnoty (tagged values)

Oznadené hodnoty umožyují rozšíit specifikaci prvku tím, že k takovému prvku pidáme informaci sestavenou jen k tomuto údelu (ad hoc).

1.10.4.1 Omezení RSzná omezení (constraints) umožGují pdidávat do prvkS modelu nová pravidla.

Omezující podmínka je jednoduše textový ÏetÄzec uzavÏený do složených závorek {}. Tento text specifikuje urÀitou podmínku nebo pravidlo týkající se prvku modelu, které musí být vyhodnoceno jako pravda. Lze Ïíci, že tímto zpÐsobem omezuje urÀité chování daného prvku. Se zmiÉovanými pravidly se v této knize setkáte ještÄ mnohokrát. UML definuje omezující jazyk nazvaný OCL (Object Constraint Language) jako standardní rozšíÏení. Úvod do jazyka OCL najdete ve 25. kapitole.

1.10.4.2 Stereotypy V knize The Unified Modeling Language Reference Manual (ReferenÀní pÏíruÀka jazyka UML) se praví, že „stereotyp zastupuje urÀitou variantu v daném modelu existujícího prvku, který má sice stejnou podobu (atributy a relace), ale používá se s jiným zámÄrem.“

43

44


Stereotypy umožGují definici nových prvkS modelu založených na existujících prvcích.

Stereotypy umožÉují vytváÏet nové prvky modelu založené na existujících prvcích. Název stereotypu staÀí vložit do dvojitých lomených závorek («») a pÏipojit k novému prvku. Každý model mÐže obsahovat nanejvýš jeden stereotyp. Jakýkoli stereotyp mÐže definovat sadu oznaÀených hodnot (tagged values) a omezujících podmínek, které platí pro stereotypní prvek. Ke stereotypu mÐžete pÏidružit rovnÄž samostatný symbol, barvu nebo texturu. Obvykle byste ovšem barvy a textury v jazyce UML používat nemÄli, protože urÀitá skupina ÀtenáÏÐ (napÏíklad barvoslepí) mÐže mít s interpretací diagramÐ potíže. KromÄ toho si uvÄdomte, že diagramy jsou obvykle stejnÄ tištÄny Àernobíle. PÏesto je obvyklé, že je k novému stereotypu pÏiÏazen nový symbol. To umožÉuje rozšíÏit grafickou notaci (zápis) v jazyku UML Ïízeným zpÐsobem. Vzhledem k tomu, že stereotypy zavádÄjí nové prvky modelu s jiným významem, musíte rovnÄž nÄkde definovat jejich sémantiku. Ptáte se jak? Pokud nástroj CASE neposkytuje vestavÄnou podporu pro tvorbu dokumentace stereotypÐ, vkládá vÄtšina analytikÐ pÏíslušnou poznámku pÏímo do vznikajícího modelu, pÏípadnÄ vloží odkaz do externího dokumentu obsahujícího definice stereotypÐ. V souÀasnosti je mezi nástroji CASE podpora tvorby dokumentace rÐzná – vÄtšina nástrojÐ však do urÀité míry stereotypy podporuje. Ne všechny nástroje však nabízejí funkce pro zachycení sémantiky stereotypu. Stereotypy mÐžete modelovat pomocí prvku tÏídy (viz 7. kapitola), k nÄmuž pÏipojíte speciální pÏeddefinovaný stereotyp jazyka UML «stereotyp». Takto vytvoÏíte metamodel prvku, jenž se nachází na zcela jiné úrovni zobecnÄní, než mají obvyklé systémy UML nebo obchodní Ài aplikaÀní modely. Vzhledem k tomu, že je to metamodel, nesmíte jej sluÀovat s normálními modely – musíte jej vždy ukládat do samostatného modelu. Tvorba nového modelu jen pro uchovávání stereotypÐ se vyplatí pouze v pÏípadÄ, že pracujete s mnoha stereotypy. K tomu ovšem dochází velice zÏídka, proto analytici spíše dokumentují stereotypy pomocí poznámky nebo externího dokumentu. Stereotypy lze zobrazovat mnoha rÐznými zpÐsoby. VÄtšina analytikÐ a návrháÏÐ používá jen symbol, nebo název stereotypu uzavÏený do dvojitých lomených závorek. Jiné zpÐsoby jsou používány zÏídka a ani nástroje CASE neposkytují pÏíliš mnoho funkcí, které by to usnadÉovaly. UrÀité pÏíklady jsou však znázornÄny na obrázku 1.12 (Poznámka: Popisky ve tvaru mnohoramenných hvÄzd nejsou souÀástí syntaxe jazyka UML – pouze zdÐrazÉují nejužiteÀnÄjší zobrazovací možnosti.)


Obrázek 1.12

Asociace mezi stereotypy lze tvoÏit stejnÄ snadno jako tÏídy. S tvorbou tÄchto asociací se v této knize setkáte mnohokrát.

1.10.4.3 Označené hodnoty V jazyku UML se za vlastnost považuje jakákoli hodnota pÏipojená k prvku modelu. VÄtšina prvkÐ má mnoho pÏeddefinovaných vlastností. NÄkteré z nich lze zobrazit v diagramech, jiné jsou zase souÀástí sémantického podkladu pÏíslušného modelu.

Ozna:ené hodnoty umožGují rozšidovat prvky modelu o jejich vlastní vlastnosti.

Jazyk UML umožÉuje rozšiÏovat vlastnosti prvkÐ pomocí oznaÀených hodnot. OznaÀená hodnota je založena na velmi jednoduché myšlence – je to klíÀové slovo s pÏidruženou hodnotou. Jak asi vypadá syntaxe užití oznaÀených hodnot? Takto: {tag1 = hodnota1, tag2 = hodnota2, ..., tagN = hodnotaN}. Je to seznam Àárkami oddÄlených dvojic znaÀka = hodnota uzavÏený do složených závorek. UrÀité znaÀky obsahují pouze dodateÀnou informaci pÏipojenou k prvku modelu – napÏíklad {author = Jim Arlow}. Jiné ovšem vyjadÏují vlastnosti nových prvkÐ modelu definované ve stereotypu. Tyto znaÀky byste však nemÄli na prvky modelu aplikovat pÏímo. MÄli byste je spíše pÏidružit k samotnému stereotypu. Je-li pak pÏíslušný stereotyp na daný model aplikován, jsou do modelu automaticky vloženy rovnÄž znaÀky pÏidružené k aplikovanému stereotypu.

1.10.4.4 Profily UML Profil UML je kolekce stereotypÐ, oznaÀených hodnot a omezení. Používá se k pÏizpÐsobení jazyka UML pro konkrétní úÀel. Profily UML umožÉují upravit jazyk UML tak, abyste jej mohli efektivnÄ použít v rÐzných problémových oblastech. UmožÉují užití stereotypÐ, znaÀek a omezení konzistentním a jasnÄ definovaným zpÐsobem. Chcete-li napÏí-

45

46


Profil UML definuje množinu stereotypS, zna:ek a omezení, díky nimž lze jazyk UML pdizpSsobit konkrétnímu ú:elu.

klad použít jazyk UML k modelování aplikace typu .NET, mohli byste použít profil UML pro .NET shrnutý v tabulce 1.4. Tabulka 1.4

Stereotyp

Znadky

Omezení

Rozšíení

Sémantika

«NETComponent»

Žádné

Žádné

Komponenta

Zastupuje komponentu v infrastruktue .NET

«NETProperty»

Žádné

Žádné

Vlastnost

Zastupuje vlastnost komponenty

«NETAssembly»

Žádné

Žádné

Balídek

Spustitelné sestavení komponent

«MSI»

Žádné

Žádné

Artefakt

Samoinstaladní soubor komponenty

«DLL»

Žádné

Žádné

Artefakt

Penosný spustitelný typ knihovny DLL

«EXE»

Žádné

Žádné

Artefakt

Penosný spustitelný typ souboru EXE

Tento profil je jen jedním z mnoha pÏíkladÐ profilÐ UML uvedených ve specifikaci jazyka UML 2.0 [UML2S] a definuje nové modelovací prvky jazyka UML pÏizpÐsobené modelování aplikací pro platformu .NET. Každý stereotyp použitý v profilu rozšiÏuje jeden z prvkÐ metamodelu UML (napÏíklad Class nebo Association). Tímto zpÐsobem vzniká nový vlastní prvek. Stereotyp mÐže definovat nové prvky a omezení, jež nejsou souÀástí pÐvodního prvku.

1.11 Architektura Jazyk UML zachycuje strategické aspekty systému v architektude „4+1“: logický pohled, pohled procesS, pohled implementace, pohled nasazení a pohled pdípadS užití.

PÏíruÀka The Unified Modeling Language Reference Manual (ReferenÀní pÏíruÀka jazyka UML) definuje architekturu systému jako „organizaÀní strukturu systému, vÀetnÄ jeho rozkladu na souÀásti, jeho propojitelnosti, interakce, mechanismÐ a smÄrných zásad, která proniká do návrhu systému“. Standard IEEE definuje architekturu systému jako „nejvyšší úroveÉ koncepce systému v jeho vlastním prostÏedí“. Architektura je zachycením strategických aspektÐ vyšší struktury systému. Na architekturu lze nahlížet mnoha zpÐsoby, ale nejÀastÄji se na ni díváme pohledem „4+1“, který ve své knize [Kruchten 2] popsal Philippe Kruchten. Abychom byli schopni zachytit všechny podstatné aspekty architektury daného systému, definuje jazyk UML ÀtyÏi rÐzné pohledy na systém: logický pohled, pohled procesÐ, pohled implementace a pohled nasazení. Všechny zmiÉované pohledy jsou integrovány do pátého pohledu, jímž je pohled pÏípadÐ užití znázornÄný na obrázku 1.13.


Obrázek 1.13:

Obrázek 5.1 z knihy The Rational Unified Process, An Introduction (Úvod do metodiky RUP) pdizpSsobený se svolením nakladatelství Addison-Wesley.

PÏibližme si nyní jednotlivé pohledy: Logický pohled. Zachycuje slovník oblasti problému jako množinu tÏíd a objektÐ. DÐraz je pÏitom kladen pÏedevším na zobrazení zpÐsobu, jakým objekty a tÏídy tvoÏící základ systému implementují jeho chování. Pohled procesÐ. Modeluje spustitelná vlákna a procesy jako aktivní tÏídy. Je to procesovÄ orientovaná varianta logického pohledu, která obsahuje stejné artefakty. Pohled implementace. Modeluje soubory a komponenty, které utváÏejí hotový kód (kódový základ) systému. Slouží jednak ke znázornÄní závislostí mezi jednotlivými komponentami (souÀástmi), jednak toho, jak spravovat konfiguraci množin vytvoÏených z tÄchto komponent. UmožÉuje definici verze systému. Pohled nasazení. Modeluje fyzické nasazení komponent na množinu fyzických výpoÀetních uzlÐ (poÀítaÀÐ a periferních zaÏízení). UmožÉuje modelování distribuce komponent na pÏíslušné uzly distribuovaného systému. Pohled pÏípadÐ užití. Všechny jiné pohledy jsou odvozeny od pohledu pÏípadÐ užití. Tento pohled zachycuje základní požadavky kladené na pÏíslušný systém jako na množinu pÏípadÐ užití (viz 4. kapitola) a utváÏí tak základ tvorby všech dalších pohledÐ. V této knize se ještÄ nejednou pÏesvÄdÀíte, že jazyk UML nabízí znamenitou podporu všech 4+1 pohledÐ. Metodika Unified Process navíc propa-

47

48


guje pÏístup odvozený od požadavkÐ, jenž velmi dobÏe koresponduje s modelem 4+1. Seznámili jste se s architekturou „4+1“ a prozkoumali všechny klíÀové aspekty systému pomocí modelÐ UML. Budete-li se Ïídit životním cyklem podle metodiky UP, nevytvoÏíte zmínÄnou architekturu v jediném kroku. Bude vznikat postupnÄ. Proces modelování v jazyku UML v prostÏedí založeném na metodice UP je tedy proces postupného upÏesÉování, pÏi kterém se nakonec ke kýžené architektuÏe dopracujete. Architektura 4+1 pak zachytí právÄ tolik informací o systému, abyste jej mohli vytvoÏit.

1.12 Čemu jste se naučili Tato kapitola obsahuje nejen úvod do historie jazyka UML, ale i úvod do struktury, základních pojmÐ a klíÀových funkcí tohoto jazyka. ShrÉme si ve struÀnosti, Àemu jste se nauÀili: Jazyk UML (Unified Modeling Language) je otevÏeným rozšiÏitelným prÐmyslovým standardem pro vizuální modelování, schváleným sdružením OMG (Object Management Group). Jazyk UML není metodikou. Unified Process, stejnÄ jako její rÐzné obmÄny, je metodikou, která jazyk UML znamenitÄ doplÉuje. Modelování objektÐ považuje svÄt za systém vzájemnÄ se ovlivÉujících objektÐ. Objekty obsahují urÀité informace a mohou vykonávat rÐzné funkce. Modely v jazyku UML obsahují: Statickou strukturu (stanoví, jaké typy objektÐ jsou dÐležité a jak spolu souvisejí), dynamické chování (stanoví, jak objekty pÏi zajišÚování funkcí daného systému navzájem spolupracují). Jazyk UML se skládá ze tÏí stavebních blokÐ: PÏedmÄtÐ: strukturní abstrakce jsou v modelu UML vyjádÏeny podstatnými jmény, chování je v modelu UML vyjádÏeno slovesy, jediná abstrakce seskupování, balíÀek, se používá k seskupování významovÄ (sémanticky) souvisejících pÏedmÄtÐ, poznámky slouží podobnému úÀelu jako zvýrazÉovaÀ, relace propojují jednotlivé pÏedmÄty, diagramy znázorÉují zajímavé pohledy na model.


Jazyk UML obsahuje ÀtyÏi obecné mechanismy: Specifikace, jež jsou testovými popisy funkcí a sémantiky jednotlivých prvkÐ použitých v modelu (jádro modelu), ornamenty, jež jsou informacemi o prvku modelu vystavenými proto, aby se poukázalo na jeho význam, podskupiny: klasifikátor a instance: klasifikátor je abstraktním vyjádÏením typu pÏedmÄtu (napÏíklad bankovní úÀet), instance je specifickým výskytem typu pÏedmÄtu (napÏíklad mÐj bankovní úÀet), rozhraní a implementace: rozhraní je dohodou, která specifikuje chování pÏedmÄtu, implementace specifikuje podrobnosti tohoto chování, mechanismy rozšíÏení: omezení, která umožÉují pÏidávat nová pravidla k prvkÐm modelu, stereotypy, které zavádÄjí nové prvky modelu založené na prvcích existujících, oznaÀené hodnoty, které umožÉují doplÉovat prvky modelu o nové vlastnosti; oznaÀená hodnota je klíÀové slovo s pÏidruženou hodnotou. Jazyk UML je založen na pohledu 4+1 na architekturu systému: Logický pohled – funkce systému a slovník, pohled procesÐ – výkon systému, škálovatelnost a propustnost, pohled implementace – montáž systému a správa konfigurace, pohled nasazení – topologie systému, distribuce, doruÀení a instalace, všechny pohledy jsou sjednoceny v pohledu pÏípadÐ užití, který popisuje požadavky uživatele.

49

Kapitola 2

Co je to Unified Process (UP)? 22 Jaký je zámÄr této kapitoly? Nabídnout ÀtenáÏÐm struÀný pÏehled metodiky UP (Unified Process). ZaÀáteÀníci by mÄli zaÀít právÄ studiem historie této metodiky. PatÏíte-li mezi zbÄhlejší ÀtenáÏe, nalistujte podkapitolu 2.4, v níž najdete pojednání o metodikách UP a RUP (Rational Unified Process) nebo podkapitolu 2.5, kde najdete informace o tom, jak aplikovat metodiku UP na svÐj projekt. Náš zájem o metodiku UP vychází, alespoÉ co se této knihy týÀe, ze snahy poskytnout jakýsi aplikaÀní rámec Ài osnovu pracovního prostÏedí, v nÄmž lze techniky objektovÄ orientované analýzy a návrhu ukázat. Úplné pojednání o metodice najdete v knize Unified Software Development Process (Unifikovaný postup pÏi tvorbÄ softwaru). VýteÀné semináÏe o metodice RUP najdete v knihách The Rational Unified Process, An Introduction (Úvod do metodiky RUP), The Unified Process Inception Phase (Metodika unifikovaného postupu: Zahájení), The Unified Process Elaboration Phase (Metodika unifikovaného postupu: Rozpracování) a The Unified Process Construction Phase (Metodika unifikovaného postupu: Konstrukce).

52


2.1 Kudy kam

Obrázek 2.1

Kapitola 2 – Co je to Unified Process (UP)?

2.2 Co je to UP? Proces vývoje softwaru (SDP, software development process) známý rovnÄž jako metodika tvorby softwarového vybavení (SEP, software engineering process) definuje pÏi vývoji softwaru otázky kdo, co, kdy a jak. Z obrázku 2.2 vyplývá, že SEP je proces, v nÄmž jsou uživatelské požadavky realizovány vytvoÏeným softwarem.

Obrázek 2.2 Proces tvorby softwarového vybavení popisuje zpSsob, jakým jsou požadavky pdekládány na software.

Metodika USDP (Unified Software Development Process) je prÐmyslovým standardem SEP (metodiky tvorby softwarového vybavení) pocházejícím od autorÐ jazyka UML. Ten je bÄžnÄ oznaÀován jako Unified Proces (zkrácenÄ UP, viz publikace Unified Software Development Process (Unifikovaná metodika vývoje softwaru)). V této knize budeme používat zkratku metodika UP. Projekt UML vznikl z potÏeby nabídnout jak vizuální jazyk, tak proces tvorby softwarového vybavení. To, co známe dnes pod pojmem UML, je jazykovou Àástí projektu, metodika UP je Àástí procesní. MÄli byste však vÄdÄt, že na rozdíl od jazyka UML není metodika Unified Process standardem organizace OMG. Neexistuje tedy žádný standard metodiky tvorby softwarového vybavení (SEP), který by jazyk UML doplÉoval. Metodika UP je založena na metodách Ericsson (Ericsson approach, 1967), Rational (Rational Objectory Process, 1996-1997) a na dalších zdrojích vycházejících z nejlepších postupÐ. Je to pragmatická a ovÄÏená metoda vývoje softwaru, která zahrnuje nejlepší ovÄÏené postupy.

2.3 Zrození metodiky UP Podíváme-li se na historii metodiky UP znázornÄnou na obrázku 2.3, tÄžko bychom mohli tvrdit, že je její vývoj spjat s kariérou jednoho ÀlovÄka – Ivara Jacobsona. Jacobson je však ve skuteÀnosti Àasto považován za otce tohoto standardu. Není to vÐbec zmenšování podílÐ jiných osob (pÏedevším Boocha), které se na tvorbÄ metodiky UP rovnÄž podílely. Je to spíše zdÐraznÄní klíÀové úlohy, jakou ve vývoji standardu UP hrál právÄ Jacobson.

53

54


Obrázek 2.3 Práce na metodice procesu tvorby softwarového vybavení, která se nakonec pderodila v metodiku UP, za:ala už v roce 1967 tvorbou Ericssonova modelu.

KoÏeny metodiky UP sahají do roku 1967, kdy vznikl EricssonÐv model, jehož radikální pojetí vycházelo z faktu, že se složité systémy mají modelovat jako množiny vzájemnÄ propojených blokÐ. Malé bloky byly vzájemnÄ propojeny tak, aby vznikaly vÄtší stavební bloky, jež utváÏely celou koneÀnou podobu výsledného systému. Základem tohoto postupu byla zásada „rozdÄl a panuj“. Dnes je tento postup znám jako vývoj komponentového softwaru. Pro jedince nahlížejícího na systém jako na monolit mÐže být tento systém jako celek naprosto nepochopitelný. Jakmile jej však rozložíme na menší souÀásti neboli komponenty, mÐže být snazší nejen pochopení funkce jednotlivých komponent (jejich rozhraní), ale i pochopení zpÐsobu, jakým do sebe jednotlivé komponenty zapadají. V jazyce UML jsou velké bloky nazývány subsystémy, pÏiÀemž každý subsystém je implementován výrazovými prostÏedky menších blokÐ nazývaných komponentami. Další inovací Ericssonova modelu byl zpÐsob, jímž identifikoval jednotlivé bloky: nazýval je „provozními pÏípady“ (traffic cases), jež popisují zpÐsob užití daného systému. ZmiÉované „provozní pÏípady“ se Àasem rozvinuly do podoby dnešních pÏípadÐ užití, používaných v jazyce UML. Výsledkem popisovaného procesu byla podoba architektury, jež popisovala nejen všechny stavební bloky, ale i zpÐsob, jakým do sebe bloky zapadaly. Popisovaný postup byl tedy pÏedchÐdcem statického modelu UML. KromÄ pohledu požadavkÐ („provozní pÏípady“) a statického pohledu (popisu architektury) obsahoval EricssonÐv model rovnÄž dynamický pohled. Ten popisoval vzájemnou komunikaci jednotlivých stavebních blokÐ. Skládal se ze sekvenÀních diagramÐ (sequence diagram), spolupráce (collaboration diagram) a stavu (statechart diagram). ZmiÉované diagramy najdete i v dnešní podobÄ jazyka UML, i když v podstatnÄ vylepšené podobÄ. Dalším závažným krokem ve vývoji postupÐ tvorby objektovÄ orientovaných softwarových systémÐ bylo zveÏejnÄní specifikace SDL (Specification and Description Language). Tuto specifikaci zveÏejnil institut pro meziná-


rodní standardy CCITT (Consultative Commitee for International Telephony and Telegraphy, poradní výbor pro mezinárodní standardy v oblasti telefonie a telegrafie). Tento jazyk byl navržen, aby zachycoval chování telekomunikaÀních systémÐ. Systémy byly modelovány jako množina komponent, které spolu komunikují prostÏednictvím zasílaných signálÐ. Jazyk SDL byl ve skuteÀnosti prvním skuteÀnÄ objektovÄ orientovaným standardem modelování. A používá se dodnes. V roce 1987 zakládá Jacobson ve Stockholmu firmu Objectory AB. Tato firma vyvinula a prodávala proces tvorby softwarových systémÐ založený na EricssonovÄ modelu – metodiku Objectory (Object Factory). Metodika Objectory se skládala z množiny dokumentací, pomÄrnÄ svérázného nástroje CASE a pravdÄpodobnÄ velmi potÏebného poradenství ze strany Objectory AB. PravdÄpodobnÄ nejdÐležitÄjší inovací byla skuteÀnost, že metodika Objectory byla považována za systém se svými vlastními zákonitostmi. Toky pracovních Àinností v procesu tvorby softwarového produktu (požadavky, analýza, návrh, implementace, test) byly vyjádÏeny pomocí množiny diagramÐ. Jinými slovy, metodika Objectory byla modelována a vyvinuta jako softwarový systém. PÏipravila tak cestu pro svÐj další vývoj. Metodika Objectory byla, podobnÄ jako UP, rovnÄž pracovním prostÏedím a pÏed zahájením jakéhokoli specifického projektu vyžadovala zevrubné úpravy podle pÏedstav zákazníka. Metodika Objectory jako produkt obsahovala Ïadu šablon pro rÐzné typy projektÐ vývoje softwarového vybavení. PÏesto všechno ji bylo tÏeba témÄÏ vždy pÏizpÐsobovat potÏebám každého nového projektu. Jacobson si uvÄdomil, že žádný projekt není stejný. Tvorba jakési „univerzální“ metody tvorby softwarového vybavení byla proto nejen neuskuteÀnitelná, ale ve skuteÀnosti spíše nežádoucí.

UP je vysp?lý otevdený standard procesu tvorby softwarového vybavení vyvinutý autory jazyka UML.

Když v roce 1995 získala firmu Objectory AB firma Rational, zaÀal se Jacobson zabývat prací nad sjednocením metody Objectory s dalšími pokroÀilými metodami tvorby softwaru, jimiž se zabývali ve firmÄ Rational. Výsledkem byla architektura pohledÐ 4+1 založená na ÀtyÏech samostatných pohledech (logickém, procesním, fyzickém a vývojovém) a na jednom sjednocujícím pohledu pÏípadÐ užití. Tento model je dodnes základem pojetí jak UP, tak UML. Iterativní vývoj byl formalizován do posloupnosti fází (zahájení (Inception), rozpracování (Elaboration), konstrukce (Construction) a zavedení (Transition)). Tyto fáze v sobÄ sluÀují disciplínu kaskádového životního cyklu s dynamickou citlivostí iterativního (založeného na opakování jednotlivých cyklÐ) a pÏírÐstkového (inkrementaÀního) vývoje. Na tomto díle se nejvÄtší mÄrou podíleli Walker Royce, Rich Reitmann, Grady Booch (tvÐrce Boochovy metody) a Philippe Kruchten. Do metody Rational byly zahrnuty pÏedevším Boochovy zkušenosti a pÏesvÄdÀivé pÏedstavy o architektuÏe znamenitým zpÐsobem popsané v knize Object Solutions (Objektová Ïešení). Výsledkem sjednocení prací na postupech Objectory a Rational byla metodika ROP (Rational Objectory Process). Metodika ROP nabídla významné zlepšení pÏedevším v oblastech, v nichž byla metodika Objectory

55

56


slabá – v požadavcích jiných než pÏípady užití, v implementaci, testech, Ïízení projektu, nasazení systému, správÄ konfigurace a ve vývojovém prostÏedí. Jako hnací mechanismus metody ROP bylo použito riziko. Architektura byla definována a formalizována jako doruÀitelný „popis architektury“. BÄhem tohoto období už Booch, Jacobson a Rumbaugh pracovali ve firmÄ Rational na vývoji nového jazyka – jazyka UML. Ten se stal jazykem pro vyjádÏení nejen modelÐ ROP, ale i samotné metody ROP. Od roku 1997 skoupila firma Rational více firem a získala tak odborné znalosti v zachycování požadavkÐ, ve správÄ konfigurace, v testování a mnoha dalších oblastech. To vedlo v roce 1998 k uvedení metodiky RUP (Rational Unified Process, viz www.rational.com ) a knihy The Rational Unified Process, An Introduction (Úvod do metodiky RUP)) na trh. Od té doby se na trhu objevilo mnoho dalších verzí této metody, z nichž každá byla lepší než ta pÏedchozí. V roce 1999 byla publikována velice dÐležitá Jacobsonova kniha Unified Software Development Process (Unifikovaná metodika vývoje softwaru), v níž autor dÐkladnÄ popisuje metodiku UP. Zatímco RUP je produktem firmy Rational, je UP otevÏeným standardem od autorÐ jazyka UML. Není vÐbec pÏekvapující, že metodiky UP a RUP mají mnoho spoleÀného. Pro tuto knihu jsme však zvolili metodiku UP. PÏedevším proto, že je to otevÏený standard dostupný všem. Není tedy vázán na žádný specifický produkt nebo na žádného dodavatele.

2.4 UP a RUP RUP je komer:ním produktem, který rozšiduje metodiku UP.

Metodika Rational Unified Process (RUP) je komerÀní verzí metodiky Unified Process dodávanou spoleÀností IBM, která v roce 2003 pÏevzala spoleÀnost Rational Corporation. Metodika RUP obsahuje veškeré standardy, nástroje a další nezbytnosti, jež nejsou souÀástí metodiky Unified Process, ale jež byste si stejnÄ museli opatÏit. Metodika RUP je navíc dodávána spoleÀnÄ s bohatým uživatelským prostÏedím doplnÄným o úplnou dokumentaci a „rádce“ k jednotlivým nástrojÐm. V roce 1999 bylo rozumné považovat RUP jen za komerÀní implementaci metodiky UP. Od té doby však uplynulo mnoho vody a RUP je nÄkde jinde – dnes již rozšiÏuje metodiku UP mnoha významnými zpÐsoby. V dnešní dobÄ bychom mÄli považovat UP za otevÏený standard a RUP za specifickou komerÀní podtÏídu, která urÀité vlastnosti a funkce bázové tÏídy (nadÏazené tÏídy, nadtÏídy) pÏekrývá a urÀité rozšiÏuje. PÏesto však metodiky RUP a UP více vÄcí spojuje, než dÄlí. Hlavní rozdíly spoÀívají spíše v úplnosti a v jednotlivých detailech než v otázkách sémantiky a ideového obsahu. Hlavní pracovní postupy objektovÄ orientované analýzy jsou dostateÀnÄ podobné, aby byl popis z pohledu UP postaÀující i pro uživatele produktu RUP. Díky tomu, že jsme pro tuto knihu zvolili obecnÄjší metodiku UP, je její text vhodný jak pro vÄtšinu objektovÄ orientovaných analytikÐ a návrháÏÐ, kteÏí nepoužívají RUP, tak pro menšinu, která tento produkt používá.


UP a RUP více spojuje, než d?lí.

Jak UP, tak RUP modelují aspekty kdo, kdy a co procesu tvorby softwarového vybavení – Àiní tak ale nepatrnÄ odlišnými zpÐsoby. NejnovÄjší verze metodiky RUP (RUP 2001) vykazuje urÀité terminologické a syntaktické odlišnosti vÐÀi metodice UP, pÏestože sémantika prvkÐ jednotlivých metod se v podstatÄ nezmÄnila. Z obrázku 2.4 vyplývá, jak jsou symboly metodiky RUP 2001 mapovány na symboly metodiky UP, které používáme v této knize. VšimnÄte si relace «trace» mezi symbolem RUP 2001 a pÐvodním symbolem UP. V jazyce UML je relace «trace» speciálním typem závislostí mezi jednotlivými prvky modelu a vyjadÏuje fakt, že prvek na poÀátku relace «trace» vznikl historickým vývojem prvku na konci relace. To pÏesnÄ odpovídá modelÐm UP i RUP. Abyste mohli v daném procesu modelovat aspekt „kdo“, nabízí metodika UP koncepci „dÄlníka“ (worker). Ta popisuje roli jedince Ài vývojového týmu uvnitÏ projektu. Každý z dÄlníkÐ mÐže mít podobu mnoha jednotlivcÐ nebo týmÐ, pÏiÀemž každý jednotlivec nebo každý tým mÐže mít podobu mnoha rÐzných dÄlníkÐ. „DÄlníci“ v RUP jsou ve skuteÀnosti oznaÀováni jako role – na sémantice to však nic nemÄní. Aspekty „jak“ procesu tvorby softwarového vybavení jsou podle metodiky UP modelovány jako aktivity a artefakty (artefacts). Aktivity jsou úlohy, jež jsou v rámci projektu uloženy jednotlivcÐm nebo týmÐm. Tito jednotlivci nebo tyto týmy budou pÏi vykonávání urÀitých aktivit vždy pÏijímat urÀité konkrétní role, takže podle metodiky UP (a také RUP) lze na základÄ jakékoli aktivity urÀit také dÄlníky (role), jež se dané aktivity úÀastní. Aktivity je možné rozložit na menší úlohy. Jako artefakty jsou oznaÀovány vstupy a výstupy projektu – takto lze oznaÀit napÏíklad zdrojový kód, spustitelné programy, standardy, dokumentaci apod. K vyjádÏení artefaktÐ mÐžete použít mnoho rÐzných symbolÐ. Na obrázku 2.4 jsou artefakty znázornÄny pomocí obecné symboly dokumentu. Aspekty „kdy“ jsou podle metodiky UP modelovány jako pracovní postupy (workflows). Jde o posloupnosti souvisejících aktivit jednotlivých dÄlníkÐ. Podle metodiky RUP se obecnÄjším pracovním postupÐm, jako jsou napÏíklad Požadavky nebo Testování, dává zvláštní název – disciplíny. Pracovní postupy lze rozložit na aktivity, role a artefakty. Tyto detaily pracovního postupu se podle metodiky UP oznaÀují pouze jménem, ale podle metodiky RUP jim náleží vlastní symbol.

57

58


Obrázek 2.4

2.5 Konkrétní aplikace metodiky UP v novém projektu Metodika UP je obecnou metodou tvorby softwaru. Pro každou organizaci stejnÄ jako potom pro každý jednotlivý projekt je tedy tÏeba vytvoÏit její novou instanci. Tím se uznává, že každý softwarový projekt se od ostatních liší a že model „tato košile padne všem“ zde rozhodnÄ neplatí. Proces konkrétní aplikace metodiky zahrnuje rovnÄž definici a zaÀleÉování. ¡eho?

Vnitropodnikových standardÐ, šablon dokumentÐ, nástrojÐ – pÏekladaÀÐ, nástrojÐ pro správu konfigurace apod., databází – sledování chyb, sledování projektu apod., úprav životnosti – napÏíklad rafinovanÄjších mÄÏítek pro kontrolu kvality používaných v zabezpeÀovacích Ài bezpeÀnostních systémech.

Podrobnosti procesu zmiÉovaných úprav pÏekraÀují rámec této knihy. Jsou však znamenitÄ popsány v knize The Unified Modeling Language Reference Manual (ReferenÀní pÏíruÀka jazyka UML).


PÏestože je metodika RUP úplnÄjší než metodika UP, musíte ji upravovat a dokládat pÏíklady stejnÄ jako v pÏípadÄ metodiky UP. Kdybyste ovšem museli zaÀínat od syrového základu UP, stálo by to vÄtší námahu. Ve skuteÀnosti jakýkoli technologický proces vývoje softwaru vyžaduje urÀitý Àas a urÀité množství finanÀních prostÏedkÐ k vytvoÏení modelu, takže byste asi mÄli vyÀlenit také urÀité prostÏedky pro poradenské služby dodavatele metodiky tvorby softwarového vybavení.

2.6 Axiomy metodiky UP Metodika UP obsahuje tÏi základní axiomy. Jsou to: zásada Ïízení pÏípadem užití a rizikem, zásada soustÏedÄní se na architekturu zásada iterace a pÏírÐstku (inkrementu). PÏípady užití se budeme podrobnÄ zabývat ve 4. kapitole. Prozatím si vystaÀíte s tím, že jsou zpÐsobem, jak zachytit požadavky. Docela pÏesnÄ bychom tedy mohli tvrdit, že metodika UP je Ïízena požadavky. UP je moderní metodikou tvorby softwarového vybavení, dízenou uživatelskými požadavky a rizikem.

Riziko je dalším z hnacích mechanismÐ metodiky UP. Nikdy se totiž sami do rizik nepustíte, to ona vás aktivnÄ napadají! Každý, kdo už na projektu vývoje nového softwaru pracoval, bude s touto tezí souhlasit. Metodika UP tuto otázku Ïeší tak, že posuzuje stavbu softwaru na základÄ analýzy možných rizik. To je však práce pro manažera projektu nebo pro jeho tvÐrce, proto se touto otázkou dále v knize zabývat nebudeme. Metodika UP používaná pro tvorbu softwarových systémÐ je založena na návrhu a postupném vývoji robustní architektury pÏíslušného systému. Architektura popisuje nejen strategické aspekty možností rozkladu systému na jednotlivé komponenty, ale rovnÄž zpÐsob, jakým se tyto komponenty vzájemnÄ ovlivÉují a jakým jsou nasazeny do pÏíslušného hardwaru. Je zÏejmé, že ke vzniku kvalitního systému vede spíše kvalitní architektura systému než spatra a s minimální úvahou napsaný zdrojový kód. Metodika UP je koneÀnÄ iterativní a pÏírÐstková (inkrementaÀní). Iterativní aspekt znamená rozklad projektu na menší podprojekty (iterace), které systému dodávají funkce dávkovÄ, nebo na pÏírÐstky (inkrementy), které vedou k tvorbÄ plnÄ funkÀního systému. Jinými slovy to znamená, že tvoÏíme software v procesu postupných upÏesÉování našeho koneÀného zámÄru. Tento postup se zásadnÄ liší od kaskádové tvorby softwaru, která byla založena na dÐsledné posloupnosti analýzy, návrhu a tvorby. V našem pÏípadÄ je posloupnost ménÄ restriktivní. Ke klíÀovým pracovním postupÐm metodiky UP, jako je analýza, se ve skuteÀnosti vracíme v prÐbÄhu projektu nÄkolikrát.

59

60


2.7 Metodika UP je založena na iterativním a přírůstkovém procesu Ke správnému porozumÄní metodiky UP je tÏeba porozumÄt iteracím. Základní myšlenka je velice prostá – historie ukazuje, že ÀlovÄku se obecnÄ vzato Ïeší lépe menší problémy než vÄtší. Snažíme se tedy o rozložení velkého softwarového projektu na Ïadu menších „miniprojektÐ“. Výsledek? Snazší správa a úspÄšné dokonÀení. Každý ze zmiÉovaných „miniprojektÐ“ je považován za iteraci. KlíÀovým východiskem je skuteÀnost, že iterace obsahuje všechny prvky normálního softwarového projektu: Metodika UP usiluje o pdírSstkovou (inkrementa:ní) tvorbu robustní architektury navrhovaného systému.

Plánování, analýzu a návrh, tvorbu, integraci a testování, interní nebo externí uvedení.

Každá iterace generuje vlastní základní linii (baseline), která se skládá z ÀásteÀnÄ kompletní verze finálního systému a z veškeré pÏidružené projektové dokumentace. ZmiÉované základní linie jsou postupnÄ vrstveny tak dlouho, dokud není dosažena koneÀná podoba vytváÏeného systému. Rozdíl mezi dvÄma základními liniemi je oznaÀován za pÏírÐstek (inkrement). PrávÄ proto je životní cyklus projektÐ podle metodiky UP oznaÀován jako iterativní a pÏírÐstkový (inkrementaÀní). Iterace jsou seskupovány do fází, což je podrobnÄji popsáno v oddílu 2.8. Fáze vytváÏejí makrostrukturu metodiky UP.

2.7.1 Pracovní postupy iterace Metodika UP obsahuje p?t základních pracovních postupS.

V každé iteraci existuje pÄt základních pracovních postupÐ (workflows), jež urÀují, co je tÏeba udÄlat, a zpÐsob, jakým toho dosáhnout. KromÄ pÄti základních pracovních postupÐ obsahuje obvykle každá iterace ještÄ další pracovní postupy, jako jsou plánování, odhad a vše, co je pro danou iteraci specifické. Tyto pracovní postupy ovšem v metodice UP zajištÄny nejsou. Jaké jsou tedy základní pracovní postupy?

Požadavky. Zachycují to, co by mÄl systém dÄlat. Analýza. Vybroušení požadavkÐ a jejich strukturování. Návrh. Realizace požadavkÐ v architektuÏe systému. Implementace. Tvorba softwaru. Testování. OvÄÏení, zda implementace funguje tak, jak se od ní oÀekává.

UrÀité pracovní postupy jsou znázornÄny na obrázku 2.5. V dalších kapitolách se budeme podrobnÄji zabývat pracovními postupy požadavkÐ, analýzy, návrhu a implementace (pracovní postup testování pÏesahuje rámec této knihy).


PÏestože mÐže každá iterace obsahovat všech pÄt základních pracovních postupÐ, závisí dÐraz kladený na urÀitý pracovní postup na jeho umístÄní v životním cyklu daného projektu. Rozkladem projektu na sled iterací dosáhneme pružného pÏístupu k plánování projektu. Nejjednodušší je sestavit Àasovou posloupnost iterací, kdy dokonÀení jedné vede k zahájení další. Iterace lze však Àasto vykonávat soubÄžnÄ. Proto je tÏeba správnÄ porozumÄt jednotlivým závislostem mezi artefakty každé iterace, což vyžaduje zpÐsob vývoje softwaru založený na architektuÏe a modelování. Výhodou soubÄžných iterací je možnost zkrácení celého projektu a snad i lepší využití vývojového týmu. Podstatou je však velmi peÀlivé plánování.

Obrázek 2.5

2.7.2 Základny iterací a přírůstky (inkrementy) Každá iterace v metodice UP generuje základní linii (baseline). Je to interní (nebo externí) verze množiny revidovaných a schválených artefaktÐ generovaných pÏíslušnou iterací. Každá základní linie: Poskytuje smluvený základ pro další pÏezkoumání a vývoj, mÐže být mÄnÄna pouze prostÏednictvím formálních metod správy konfigurace a zmÄn. PÏírÐstky (inkrementy) jsou však pouze rozdílem mezi jednou základní linií a základní linií další. PÏírÐstky jsou jednotlivými dílÀími kroky smÄrem k finální odevzdávané verzi systému.

2.8 Struktura metodiky UP Na obrázku 2.6 je znázornÄna struktura metodiky UP. Životní cyklus projektu je rozdÄlen na ÀtyÏi fáze: zahájení (inception), rozpracování (elaboration), konstrukce (construction) a zavedení (transition). Všechny fáze konÀí defi-

61

62


Metodika UP se skládá ze :tyd fází. Každá fáze kon:í hlavním milníkem.

novanými hlavními milníky (což jsou indikátory pokroku v projektu). Každá fáze mÐže obsahovat jednu nebo více iterací. V každé iteraci mÐžeme realizovat pÄt základních pracovních postupÐ a libovolný poÀet dodateÀných pracovních postupÐ. PÏesný poÀet iterací v jednotlivých fázích závisí na velikosti projektu. Každá iterace by však nemÄla trvat více než dva až tÏi mÄsíce. Náš pÏíklad je typický pro stÏednÄ velké projekty, jejichž délka se pohybuje okolo 18 mÄsícÐ.

Obrázek 2.6

Z obrázku 2.6 vyplývá, že metodika UP se skládá ze ÀtyÏ po sobÄ následujících fází, z nichž každá konÀí hlavním milníkem.

Zahájení (inception) – období plánování, rozpracování (elaboration) – období architektury, konstrukce (construction) – poÀátky provozuschopnosti, zavedení (transition) – nasazení produktu do uživatelského prostÏedí.

Jak projekt pÏechází z jedné fáze do druhé, mÄní se i objem prací vykonávaných v každém z pÄti základních pracovních postupÐ. Množství práce vykonané v jednotlivých základních pracovních postupech se liší v závislosti na dané fázi.

Podívejte se na obrázek 2.7. Je klíÀem k pochopení funkce metodiky UP. Podél horního okraje jsou znázornÄny jednotlivé fáze. Pod nimi je uvedeno pÄt základních pracovních postupÐ. Podél dolního okraje jsou znázornÄny urÀité iterace. KÏivky ukazují relativní objem práce vykonané v jednotlivých základních pracovních postupech v pÏíslušných fázích projektu. Z obrázku 2.7 vyplývá, že v poÀáteÀní fázi je nejvíce Àasu vÄnováno sestavení požadavkÐ a analýze. Ve fázi rozpracování je dÐraz kladen na požadavky, analýzu a ÀásteÀnÄ na návrh. Ve fázi stavby je už dÐraz zcela zÏetelnÄ kladen pÏedevším na návrh a implementaci. KoneÀnÄ ve fázi zavedení je dÐraz položen na implementaci a testování. Jednou z nejskvÄlejších vlastností metodiky Unified Process je fakt, že se soustÏe×uje na cíl, nikoli na výsledek. Každá fáze je zakonÀena milníkem, jenž je definován podmínkami splnÄní. Mezi zmiÉované podmínky mÐže v závislosti na potÏebách konkrétního projektu patÏit mimo jiné také zajištÄní dílÀího výsledku.


Následující oddíly obsahují struÀný pÏehled jednotlivých fází.

2.9 Fáze podle metodiky UP Každá fáze má urÀitý cíl, na nÄjž jsou soustÏedÄny aktivity jednoho nebo více pracovních postupÐ a jenž je významným milníkem v životÄ projektu. Tato osnova se stane rámcem, v nÄmž budeme zkoumat jednotlivé fáze.

Obrázek 2.7:

Upravený obrázek pdevzatý se svolením nakladatelství Addison-Wesley z knihy Unified Software Development Process (Unifikovaná metodika vývoje softwaru).

2.9.1 Souhrnné cíle fáze Zahájení Cílem fáze Zahájení je „odstartování projektu“. Tato fáze obsahuje: Fáze Zahájení je zahájením projektu.

Tvorbu podmínek proveditelnosti – to mÐže zahrnovat návrh urÀitých technických prototypÐ (pozn. pÏekl.: tvorba modelu pÏedmÄtu reálného svÄta a simulace jeho Àinnosti; v poÀítaÀové oblasti se používají termíny typu virtual prototyping, znamenající tvorbu tohoto modelu plnÄ pomocí výpoÀetní techniky), které umožní ovÄÏit validitu technologických rozhodnutí nebo korekturu koncepÀního návrhu prototypÐ s cílem ovÄÏit validitu aplikaÀních požadavkÐ; nadnesení obchodního (podnikatelského) pÏípadu, na nÄmž by bylo možno ukázat, že projekt bude mít kvantitativní obchodní pÏínos; zachycení podstatných požadavkÐ, které umožní definovat rozsah vznikajícího systému, oznaÀení kritických rizik.

63

64


Hlavními pracovníky jsou v této fázi manažer projektu a systémový projektant.

2.9.2 Primární zaměření fáze Zahájení Hlavní dÐraz je v této fázi kladen na pracovní postupy zabývající se specifikací požadavkÐ a jejich analýzou. Do této fáze však mohou spadat rovnÄž urÀité návrháÏské Ài implementaÀní práce – je-li rozhodnuto vytvoÏit technický prototyp, jenž by potvrzoval správnost koncepce. V této fázi obvykle nedochází k pracovnímu postupu testování, protože jedinými softwarovými artefakty jsou prototypy, které budou stejnÄ zahozeny.

2.9.3 Milník: Předmět životního cyklu a rozsah systému Zatímco se vÄtšina procesÐ tvorby softwarového vybavení zamÄÏuje na tvorbu klíÀových artefaktÐ, je metodika UP zamÄÏena spíše na koneÀné cíle. Každý milník nastavuje urÀité cíle, kterých musí být dosaženo, aby bylo možné považovat milník za dosažený. NÄkteré cíle mohou být výsledkem urÀitých artefaktÐ, jiné nikoliv. Milníkem poÀáteÀní fáze je pÏedmÄt životního cyklu a rozsah systému (Life Cycle Objectives). Podmínky, jež musí být splnÄny, aby byl milník považován za dosažený, jsou shrnuty v tabulce 2.1. KromÄ toho doporuÀujeme stanovit také množinu výsledkÐ, které je tÏeba dodat, abyste zmiÉované podmínky splnili. Pamatujte však, že výsledky je tÏeba dodávat jen v pÏípadÄ, že jsou pro daný projekt skuteÀným pÏínosem. Tabulka 2.1

Hodnotící kritéria (metriky)

Je teba dodat

Uživatelé a zainteresované osoby (zadavatel) souhlasí se zámgry životního cyklu.

Dokument o pedstavg, jenž obsahuje hlavní požadavky na projekt, funkce a podmínky.

S uživateli a zainteresovanými osobami byl dohod- Podátední pípad užití (kompletní asi z 10 nebo nut rozsah projektu. 20 %). S uživateli a zainteresovanými osobami byly dohod- Slovník projektu. nuty zachycené klídové požadavky. Uživatelé a zainteresované osoby schválili náklady Podátední plán projektu. a pracovní rozvrh. Manažer projektu nadnesl obchodní pípad.

Obchodní pípad.

Manažer projektu odhadl rizika.

Dokument nebo databáze obsahující odhad rizik.

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

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

Nádrt architektury.

Podátední dokument zachycující architekturu.


2.9.4 Cíle fáze Rozpracování Výstupy fáze rozpracování lze shrnout následujícím zpÐsobem: Tvorba spustitelného architektonického základu, vylepšení odhadu rizik, definice atributÐ kvality (pomÄr odhalení nedostatkÐ, pÏijatelná hustota nedostatkÐ apod.) zachycení pÏípadÐ užití pro 80 % funkÀních požadavkÐ (co to pÏesnÄ vyžaduje, se dovíte ve 3. a 4. kapitole), tvorba pÏesného plánu konstrukÀní fáze, formulace nabídky, která zahrnuje veškeré prostÏedky, Àas, vybavení, personál a náklady. Fáze rozpracování je zam?dena na tvorbu :áste:né, avšak funk:ní verze systému – spustitelného architektonického základu.

Hlavním cílem fáze rozpracování je tvorba spustitelného architektonického základu. Je to skuteÀný spustitelný systém, sestavený na základÄ specifikované architektury. Není to prototyp (který lze zahodit), je to spíše „první pokus“ o kýžený systém. Tento poÀáteÀní spustitelný základ bude bÄhem dalších prací rozšiÏován a vyvine se v plnohodnotnou koneÀnou verzi pÏedávaného systému – k tomu však dojde až v konstrukÀní a koneÀnÄ v zavádÄcí fázi. Vzhledem k tomu, že budoucí fáze vycházejí z výsledkÐ fáze rozpracování, lze poslednÄ zmiÉovanou fázi považovat za kritickou. Na tuto fázi se ve skuteÀnosti zamÄÏuje i naše kniha.

2.9.5 Primární zaměření fáze Rozpracování Ve fázi rozpracování je dÐraz v jednotlivých pracovních postupech kladen na následující aktivity:

požadavky – upÏesnÄní rozsahu systému a požadavkÐ na nÄj kladených, analýza – stanovení toho, co budeme tvoÏit, návrh – tvorba stabilní architektury, implementace – tvorba spustitelného architektonického základu, testování – testování architektonického základu.

Ve fázi rozpracování je dÐraz kladen zcela zjevnÄ na pracovní postupy zabývající se požadavky, analýzou a návrhem. Implementace nabývá na dÐležitosti s blížícím se koncem fáze rozpracování, kdy je vytváÏen spustitelný základ vznikajícího systému.

2.9.6 Milník: Architektura jako vodítko pro systém v jeho budoucím životě Milníkem této fáze je architektura (Life Cycle Architecture). Chceme-li považovat milník za dosažený, musíme splnit podmínky, které jsou shrnuty v tabulce 2.2.

65

66


Tabulka 2.2


Co je teba dodat

Byl vytvoen odolný robustní spustitelný architektonický základ.

Spustitelný architektonický základ.

Spustitelný základ ukazuje, že byla rozpoznána a vyešena dležitá rizika.

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

Vize produktu byla stabilizována.

Dokument o vizi.

Odhad rizik byl revidován.

Aktualizovaný odhad rizik.

Obchodní pípad byl revidován a odsouhlasen uživateli a zaintereso- Aktualizovaný obchodní pípad. vanými osobami. Projekt byl vytvoen do dostatedné hloubky, aby umožnil sestavení realistické nabídky zahrnující odhad dasu, pengz a prostedk pro nadcházející fáze.

Aktualizovaný plán projektu.

Uživatelé a zainteresované osoby souhlasí s plánem projektu. Plán projektu byl porovnán s obchodním pípadem.

Obchodní pípad a plán projektu

Bylo dosaženo dohody s uživateli a zainteresovanými osobami o po- Konedný dokument. kradování v projektu.

2.9.7 Souhrnné cíle fáze Konstrukce B?hem konstruk:ní fáze se spustitelný architektonický základ postupn? pderodí v kompletní a funk:ní systém.

Cílem konstrukÀní fáze je splnit všechny požadavky analýzy a návrhu a vyvinout ze spustitelného základu vytvoÏeného ve fázi rozpracování koneÀnou verzi systému. KlíÀovým zadáním konstrukÀní fáze je zachování integrity architektury vytváÏeného systému. Jakmile se totiž zaÀne klást dÐraz na kód systému a jakmile vás zaÀne tlaÀit Àas, dochází obÀas k narušení pÐvodní vize, což neodvratnÄ vede ke snížení kvality výsledného systému a k následnému nárÐstu nákladÐ na jeho údržbu. Takovým smutným koncÐm bychom se mÄli vyhýbat.

2.9.8 Primární zaměření fáze Konstrukce V této fázi je kladen dÐraz na pracovní postup implementace. V jiných oblastech již toho bylo vykonáno dost – byly zachyceny požadavky, zpracována analýza a vytvoÏen návrh. Testování bude rovnÄž velice dÐležité – to však až ve chvíli, kdy bude tvorba systému natolik pokroÀilá, že bude zapotÏebí provádÄt dílÀí i integraÀní testy. ShrÉme tedy práci uskuteÀnÄnou v jednotlivých pracovních postupech: Požadavky – odhalit veškeré požadavky, které byly v pÏedchozích fázích pÏehlédnuty, analýza – dokonÀit analytický model, návrh – dokonÀit model návrhu,


implementace – zajistit poÀáteÀní provozní zpÐsobilost (Initial Operational Capability), testování – testovat poÀáteÀní funkÀní variantu.

2.9.9 Milník: Počáteční provozní způsobilost V podstatÄ je tento milník velmi jednoduchý – softwarový systém je pÏipraven pro testování na poÀítaÀích uživatele. Hodnotící kritéria (metriky) tohoto milníku jsou shrnuta v tabulce 2.3. Tabulka 2.3


Co je teba dodat

Softwarový produkt je dostatedng stabilní a na takové úrovni, aby jej bylo možno nasadit na podítade uživatele.

Softwarový produkt. Model UML. Testovací sadu.

Uživatelé a zainteresované osoby souhlasí s nasazením softwaru do svého Uživatelské pírudky. prostedí a je k ngmu pipraven. Popis verze. Pomgr skutedných výdaj vdi plánovaným je pijatelný.

Plán projektu.

2.9.10 Cíle fáze Zavedení Fáze zavedení spo:ívá v nasazení hotového systému na pracovišt? uživatele.

Fáze Zavedení (Transition) zaÀíná v okamžiku, kdy je dokonÀeno testování a koneÀné nasazení systému. To zahrnuje opravu všech chyb nalezených v beta-verzi a pÏípravu pro pÏenesení systému na všechny poÀítaÀe uživatele. Cíle této fáze lze shrnout následujícím zpÐsobem:

Oprava chyb, pÏíprava uživatelského pracovištÄ na pÏijetí nového softwaru, pÏizpÐsobení softwaru tak, aby fungoval na pracovišti uživatele, úprava softwaru v pÏípadÄ vzniku neoÀekávaných problémÐ, tvorba manuálÐ a další dokumentace, konzultace s uživateli, koncová revize.

2.9.11 Primární zaměření fáze Zavedení V této fázi klademe dÐraz na implementaci a testování. Je pÏipraven vhodný návrh, který pomÐže odstranit veškeré závady nalezené pÏi testování. Existuje velká pravdÄpodobnost, že se v této fázi projektu tvoÏí minimum požadavkÐ a minimálnÄ se analyzuje. Je-li tomu naopak, ocitá se projekt ve svízelné situaci. Požadavky – nepoužitelné, analýza – nepoužitelná,

67

68


návrh – úprava návrhu, jsou-li bÄhem testování nalezeny chyby, implementace – pÏizpÐsobení softwaru pracovišti uživatele a oprava chyb, které nebyly pÏi testování nalezeny. Testování – beta-testy a pÏejímací testy na pracovišti uživatele.

2.9.12 Milník: Nasazení produktu To je poslední milník – beta-testy, pÏejímací testy a oprava pÏípadných chyb jsou dokonÀeny a produkt je uvolnÄn a pÏijat do užívání na pracovišti uživatele. Podmínky dosažení zmiÉovaného milníku jsou shrnuty v tabulce 2.4. Tabulka 2.4


Co je teba dodat

Beta-testy jsou dokondeny, byly provedeny nezbytné zmgny a uživatel sou- Softwarový produkt. hlasí s faktem, že systém byl úspgšng nasazen. Pracovníci uživatele produkt aktivng využívají. Strategie podpory produktu byla nejprve s uživateli dohodnuta a pozdgji implementována.

Plán uživatelské podpory. Uživatelské pírudky.

2.10 Čemu jste se naučili? Proces tvorby softwarového vybavení pÏevádí uživatelské požadavky na software, pÏiÀemž specifikuje aspekty kdo dÄlá co a kdy. Metodika UP byla vyvinuta v roce 1967. Je to vyspÄlý otevÏený standard, pocházející od autorÐ jazyka UML. Metodika RUP (Rational Unified Process) je komerÀním rozšíÏením metodiky UP. S touto metodou je zcela kompatibilní; je však úplnÄjší a podrobnÄjší. Pro každý nový projekt je tÏeba vytvoÏit úplnÄ novou instanci metodiky UP (stejnÄ tak jako u metodiky RUP), neboÚ je do ní tÏeba zapracovat napÏíklad vnitropodnikové standardy. UP je moderní metodika tvorby softwarového vybavení, jež: Je Ïízeno rizikem a pÏípady užití (požadavky), se soustÏe×uje na architekturu, je iterativní a pÏírÐstkové (inkrementaÀní). Software je v metodice UP vytváÏen v iteracích: Každá iterace je jako samostatný „miniprojekt“, který dodává jednotlivé souÀásti vznikajícího systému, iterace jsou skládány jedna na druhou, Àímž vytváÏejí koneÀnou podobu systému.


Každá iterace obsahuje pÄt pracovních postupÐ: Požadavky, které slouží k zachycení toho, co má systém umÄt, analýzu, která upÏesÉuje a strukturuje požadavky, návrh, který pÏevádí požadavky na architekturu systému (aspekt: jak to systém udÄlá), implementaci, bÄhem níž je software skuteÀnÄ vytvoÏen, testování, bÄhem kterého je ovÄÏena vÄtšina požadovaných funkcí poskytovaných vytvoÏenou implementací. Metodika UP se skládá ze ÀtyÏ fází, z nichž každá konÀí definovaným hlavním milníkem: Zahájení (inception), fáze, bÄhem níž projekt startuje; milníkem jsou zámÄry životního cyklu (Life Cycle Objectives); rozpracování (elaboration), fáze, bÄhem níž vzniká architektura systému; milníkem je architektura životního cyklu programového díla (Life Cycle Architecture); konstrukce (construction), fáze, v níž je vytváÏen software; milníkem je poÀáteÀní funkÀní varianta (Initial Operational Capability); zavedení (transition), fáze, bÄhem níž je software nasazen do uživatelského prostÏedí; milníkem je nasazení produktu (Product Release).

69

Jim Arlow, Ila Neustadt. UML 2 a unifikovaný proces vývoje aplikací Objektově orientovaná analýza a návrh prakticky

Recommend Documents