Modelování webových služeb v UML Jaromír Šveřepa LBMS, s.r.o. Abstrakt: Tento příspěvek se zaměřuje na praktický postup pro identifikaci potřeby webové služby, modelování způsobu jejího použití, popřípadě zadání tvorby webové služby externímu vývojovému týmu. Příspěvek je zaměřen na modelování věcných (business) vlastností webových služeb v UML. Klíčová slova: webové služby, UML
1
Úvod
Webové služby představují sadu standardů umožňujících komunikaci aplikací bez ohledu na platformu, na které jsou provozovány. Webové služby tak přinášejí technologický základ pro integraci různorodých aplikací. Zužovat však použití webových služeb pouze na technologické otázky je značně nepraktické. Při tvorbě IT systémů je totiž mechanismus komunikace (předávání zpráv) pouze prostředkem pro splnění požadavků uživatelů. Zaměřím se proto na postup, který vychází z uživatelských požadavků a který využívá webových služeb ve formě otevřeného komunikačního média.
2
Definice zadání
Zadání jakéhokoliv softwarového projektu vývoje či rozvoje aplikace je možné zúžit na množinu uživatelských požadavků. Celý další postup je vlastně postupná transformace těchto požadavků do určitého softwarového řešení, kdy se snažíme základní uživatelské požadavky pochopit, ověřit jejich správnost a úplnost.
3 3.1
Identifikace potřeb Model firemních procesů
Výchozím modelem pro vyjasnění potřeb je model firemních procesů. Jedná se o model sekvence činností, které mají být podporovány vyvíjenou aplikací. Příklad modelu firemních procesů je na obrázku 1. Vzhledem k tomu, že modelování procesů není součástí standardu UML, je použita notace diagramu procesních řetězců z metodiky Select Perspective.
Obrázek 1 - firemní proces pro externí Help Desk
Pro pochopení významu diagramu uvádím stručně jeho syntaxi: plné šipky zleva doprava – událost obdélníky – tzv. elementární procesy, tj. souvislé činnosti v rámci firemního procesu poloovál – přerušení procesu, kdy další činnosti mohou probíhat až po výskytu události plná šipka zprava doleva – ukončení procesu, je produkována hodnota generovaná procesem 3.2
Use Cases
Na základě požadavků a modelu firemního procesu je nyní možné odvodit detailní požadavky na funkcionalitu aplikace – Use Cases. Tím vlastně definujeme potřebu automatizované podpory pro jednotlivé aktivity v procesu. Use Case Diagram odvozený z procesu na obrázku 1 je znázorněn na obrázku 2.
Obrázek 2 – Use Case diagram odvozený z modelu procesů
Vzhledem k expresivnímu charakteru Use Cases je však velmi problematické jejich přímé použití pro identifikaci potřebných služeb systému. Pro tyto účely je proto každý Use Case rozpracován pomocí Diagramů objektových sekvencí (Object Sequence Diagram) do tzv. interakcí na úrovni zpráv na rozhraní. Takovýto model zachycuje interakci pouze na úrovni hrubých analytických packages, které mají zatím definovány pouze rozhraní (interfaces) a není rozpracována jejich vnitřní struktura.
Obrázek 3 – Object Sequence Diagram registrace incidentu
Na obrázku 3 je znázorněno, že Use Case registrace incidentu vede na potřebu čtyř služeb (dejProdukty, dejProduktyKlienta, dejSeznamVerziProduktu a zalozIncident).
3.3
Model tříd
Souběžně s tvorbou těchto analytických modelů interakcí je vytvářen model struktury systému ve formě hrubých packages, kde jsou zatím modelována pouze potřebná rozhraní a operace rozhraní potřebné k uspokojení požadované interakce. Příklad je uveden na obrázku 4.
Obrázek 4 – prvotní model tříd na úrovni rozhraní a packages
Průběžně je nezbytné revidovat rozložení zodpovědností v jednotlivých packages (zde chápáno jako abstrakce služeb poskytovaných packagem). V případě nízké soudržnosti je nutné provést přeskupení služeb mezi packages (refactoring rozhraní a služeb) tak, abychom dosáhli vysoké soudržnosti jednotlivých služeb v rámci rozhraní i package.
4
Definování způsobu pořízení
V této fázi nejprve zkoumáme, zda požadované služby již nejsou k dispozici, a to vyhledáváním ve firemním katalogu služeb a/nebo ve veřejně dostupných zdrojích nebo tržištích. Pokud služba není k dispozici a je potřeba ji vyvinout, doplňuje se popis rozhraní o vyžadované parametry (předávané struktury). Pro jejich popis se používá model tříd (struktur). Takto doplněná specifikace pak slouží jako zadání pro tým, který příslušné služby vyvine (ať již interní nebo externí), většinou přímým převodem těchto struktur do podoby WSDL. V našem příkladu předpokládejme, že služby dejProduktyKlienta a dejSeznamVerziProduktu nebudou v systému k dispozici, neboť tyto služby jsou již k dispozici v obchodním systému.
5
Tvorba služby
Na základě věcné specifikace (požadovaná rozhraní, požadované operace na rozhraních a požadované parametry/struktury), navrhne vývojový tým způsob implementace služby. Vývojový tým to provádí formou doplnění interních tříd v package a návrhem interakcí pro každou operaci na rozhraní. Na základě této specifikace je potom vytvořena komponenta nebo aplikace, která poskytuje požadované služby. Ilustrativní příklad modelu tříd je uveden na obrázku 5 a diagram interakcí pro službu dejSeznamVerziProduktu je na obrázku 6.
Obrázek 5 – návrh rozhraní webové služby
Obrázek 6 – návrh interakce realizující webovou službu
6
Sesazení řešení z připravených služeb
Poslední fáze spočívá v sesazení řešení z dodaných (nebo opakovaně využitých) služeb a doplnění implementačních objektů specifických pro řešení (např. objekty prezentační vrstvy, řídící logika jednotlivých Use Cases). Vzhledem k tomu, že posloupnost a názvy zpráv se při zakládání incidentu našeho help desku nezměnily, je použití webových služeb patrné stereotypem u rozhraní iProdukt a také tím, že nyní je toto rozhraní označeno jako externí („e“ v pravém horním rohu), čili nelze je v tomto modelu měnit.
Obrázek 7 – finální interakce pro Registraci incidentu
7
Shrnutí
Uvedený postup v tomto příspěvku lze použít obecně pro všechny systémy, jejichž architektura je postavena na poskytování služeb. 7.1
Výhody uvedeného přístupu: Jasné a pochopitelné oddělení analytického modelu a implementačního modelu (na úrovni diagramů interakcí, na úrovni modelu tříd). Pro rozhodování o způsobu pořízení služby není nutné provádět velmi detailní analýzu. Snadné opakované využití již vytvořených služeb.
7.2
Rizika uvedeného postupu: Dle našich poznatků vyžaduje tento postup zkušenější analytiky a návrháře. Především ve fázi identifikace potřeb.
7.3
Jiné postupy modelování webových služeb – vztahy mezi Use Cases
Shora uvedený postup se nabízí jako praktičtější varianta velmi obecného postupu vycházejícího čistě z modelu Use Case. Při takovémto postupu je cílem definovat webové služby pomocí vztahů mezi Use Cases, přičemž Use Case (identifikovaný stereotypem <<web service>>) představuje požadovanou webovou službu. Při zkoumání toho postupu jsme však narazili na problém, jak modelovat požadavek na obecnou službu, která může být realizována jako webová služba, ale může být zároveň realizována jako interní služba systému – ve fázi analýzy to ještě není známo. Pokud bychom všechny služby modelovali jako Use Cases, vzniká příliš velké množství Use Cases, což je u středně složitého nebo složitějšího systému značný modelový problém. Shora uvedený postup modeluje webové služby na úrovni operací rozhraní (interfaces), tím pádem lze udržet přehlednost i u složitějších modelů.
Reference 1. Hedley Apperly, Ralph Hofman, Steve Latchem, Barry Maybank, Barry McGibbon, David Piper, Chris Simons, Ralph Hoffman. Service- and Component-based Development: Using the Select Perspective and UML. Addison-Wesley Pub Co; 1st edition (January 24, 2003). ISBN: 0321159853.
Abstract: This contribution is focused on practical approach how to identify web service demand, how to model usage of web service, eventually how to create request specification for external web service development. The contribution is focused on web services business properties modeling using UML.
