Softwarové architektury

Transkript

1 od podnikových procesů k IT službám Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů Přednáška pro SRI 15. října 2014 Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

2 Obsah Cíle přednášky Předpoklady 1 Softwarové architektury Definice, pozice ve vývojovém procesu Přehled architektur Problémy a výzvy Aktuální trendy 2 Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie 3 Identifikace služeb Specifikace služeb Realizace služeb 4 Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

3 Cíle přednášky Cíle přednášky Předpoklady Mít přehled o SW architekturách, problémech a řešeních. Porozumět architekturám orientovaným na služby (SOA). Umět používat SOA ve fázi návrhu IS. Mít představu o nástrojích pro návrh a implementaci SOA. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

4 Předpoklady Cíle přednášky Předpoklady 1 Znát životní cykly SW (metody vývoje). 2 Porozumět diagramům BPMN a UML. 3 Mít zběžnou představu o modelování business procesů. 4 Mít zběžnou představu o týmové práci a řízení projektů. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

5 Cíle přednášky Předpoklady Business Process Modeling (Notation) zde má být příloha přejít na přílohu Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

6 Definice, pozice ve vývojovém procesu Přehled architektur Problémy a výzvy Aktuální trendy Logická architektura vs. architektura nasazení Logická architektura (Architecture) je součástí prvních fází návrhu IS, organizuje entity návrhových diagramů (architektonické vzory), (třídy do balíčků, funkčnost do vrstev, podsystémy do systémů, komponenty do složených komponent, služby do agregovaných služeb, atd.) neříká nic o konkrétním fyzickém rozmístění (abstrakce). Architektura nasazení (Deployment) je jednou z posledních fází návrhu IS, definuje fyzické rozmístění funkčních entit, (objekty do aplikačních kontejnerů, systémy na uzly sítě, data do databází, služby mezi poskytovatele služeb, infrastruktura, atd.) nezávisí na logické architektuře, přestože ji většinou respektuje. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

7 Pozice ve vývojovém procesu Definice, pozice ve vývojovém procesu Přehled architektur Problémy a výzvy Aktuální trendy definují se business procesy specifikace navrhne se doménový model a logická architektura návrh... provede se rozmístění integrace 1 1 obrázek převzat z Linking Business Process Modeling to SOA and UML 2.0 with Together technologies (Kari Alho, Borland Finland, 2006) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

8 Přehled architektur Definice, pozice ve vývojovém procesu Přehled architektur Problémy a výzvy Aktuální trendy Logické architektury (Architecture) vrstvené architektury (vertikální a horizontální členění), (peer-to-peer, klient-server, referenční model ISO/OSI,... ) architektonické vzory, (Model-View-Controller, Presentation-Control-Mediator-Entity-Foundation,... ) návrhové vzory, (GoF: adapter, factory, singleton,... ; GRASP: inf. expert, creator, controller,... ) využívající nějaké paradigma. (architektura orientovaná na služby (SOA), komponentové systémy,... ) Architektury nasazení (Deployment) dané prostředím (sít ové topologie), (hvězda, strom, ad-hoc,... ) dané platformou, (BEA WebLogic, IBM WebSphere, JBoss,... ) dané implementační technologií. (EJB, WebServices, CORBA,... ) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

9 Definice, pozice ve vývojovém procesu Přehled architektur Problémy a výzvy Aktuální trendy Co nepřímo ovlivňuje architekturu? vývoj systému (řízení projektu, inkrementální cyklus, FDD, testy, TDD, ale složitější integrace) struktura organizace (autonomní oddělení, fyzické rozmístění, postupné zavádění, vlastní IT) zavedené systémy (adaptace existujících systémů a procesů, daná rozhraní, externí systémy, více dodavatelů) technologie a bezpečnost (heterogenní prostředí, off-line části, vlastnosti sítě, zálohy a dostupnost) finance a marketing (prodej po modulech, customizace, delegace funkčnosti modulů, nákup řešení) logická architektura architektura rozmístění Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

10 Aktuální trendy Definice, pozice ve vývojovém procesu Přehled architektur Problémy a výzvy Aktuální trendy Definice (Softwarová architektura, IEEE-Std ) základní organizace SW systémů zahrnující popis jeho komponent, jejich chování, vztahů a vztahů s okolím (tj. rozhraní), a principů jejich návrhu a vývoje. Gridy (prodávání a nakupování IT zdrojů, globální super-počítač,... ) Komponentové trhy (obchodování s výpočetními prostředky, konstrukce IS ze zapůjčených komponent, vývoj architektury IS, dynamické vazby, agenti, univerzální modelování,... ) Service-Oriented Architecture (inzerování služeb, distribuce částí IS do center IT služeb, respektování business pravidel, automatizace B2B procesů,... ) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

11 Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie SOA: architektura orientovaná na služby (Service-Oriented Architecture), obecný koncept spolupracujících služeb, WS: webové služby (Web Services), technologie pro implementaci SOA, spravuje W3C skupina Web Services Architectures. Role komunikujících a spolupracujících stran: poskytovatel služeb implementuje a nabízí služby (service provider), služba je specifikovaná svým popisem (URI, rozhraním a protokolem), spotřebitel služeb na základě popisu vyhledá službu v registru služeb a použije ji (service consumer). Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

12 Spolupráce mezi službami v SOA Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie služby poskytují své prostředky bud přímo cílovému spotřebiteli anebo jiným službám, služby mezi sebou spolupracují (komunikují) zasíláním zpráv. Spolupráce mezi službami: 1 kooperace služba využívá prostředky jiné (rovnocenné) služby pro realizaci nabízených funkcí, 2 agregace služba sestavená ze dvou (nebo více, podřízených) služeb nabízí kombinaci funkcí dílčích služeb, 3 choreografie služby potom spolupracují za účelem provedení konkrétního business procesu, 4 orchestrace služba řídí součinost ostatních služeb za účelem provedení své části business procesu. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

13 Základní vlastnosti SOA Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie standardizace: jednotný způsob popisu služeb, zajišt uje jejich kompatibilitu, volné vázání: co nejméně vztahů mezi službami, navazovány jen účelově, abstrakce: služby přístupné pouze přes rozhraní, zbytek zapouzdřen (způsob výpočtu, implementační techonologie, atd.), znovupoužitel.: služba použitelná v různých kontextech (aplikacích), nezávislost: služby autonomní jednotky, nezávisí (skrytě) na svém okolí, bezstavovost: služba by neměla uchovávat (viditelnou) stavovou informaci, dohledatelnost: poskytovatel služby (dle potřeby) dohledatelný v adresáři, kompozice: služby možno skládat do větších funkčních celků dle potřeby. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

14 Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie Porovnání SOA s jinými architekturami a principy SOA vs. klient-server architektura klient server = rozhraní a apl. logika apl. logika, stav a sdílené zdroje, spotřebitel poskytovatel = potřebuje nabízí funkčnost, SOA je jemnější dekompozice (např. menší nároky na zdroje), SOA je více distribuovaná (rozmístění výpočetní logiky), služby se snaží být bezstavové z vnějšího pohledu. SOA vs. objektově orientovaný přístup SOA přístup preferuje volném provázání entit (služeb) OO přístup přesně vztahy mezi třídami, těsnější vazby entit (objektů), základní vlastností OO přístupu je dědičnost SOA přístup s dědičností nepočítá, preferuje delegaci, základní vlastností SOA přístupu je bezstavovost entit zapouzdření dat do objektů v OO přístupu, aktivita služeb v SOA přístupu je vyvolána až příchodem nějaké zprávy, podobný pohled na abstrakci entit (rozhraní). Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

15 Konceptuální model SOA Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie model interakce mezi poskytovatelem služeb a spotřebitelem služeb Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

16 Struktura SOA Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie SOA je částečně vrstvená architektura (vrstva = úroveň abstrakce) 1 vrstva business procesů BP je posloupnost kroků respektující business pravidla a vedoucí k zisku (hmotnému i nehmotnému), reprezentován sekvencí provedení několika služeb (choreografie služeb), 2 vrstva služeb rozhraní jednotlivých komponent sjednocena do služeb, služba za běhu sestavuje komponenty a přeposílá jim požadavky, služba na rozhraní zpřístupňuje své funkce (popis služby), 3 vrstva komponent základní stavební kameny služeb, realizace funkčnosti služeb a zajištění požadované kvality služeb (QoS), komponenty jsou černé skříňky a jejich funkce jsou přístupné pouze přes rozhraní. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

17 Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie Service-oriented Analysis and Design (SOAD) Identifikace, specifikace a realizace komponent, služeb a choreografie služeb. Specifikace požadavků z pohledu spotřebitele a poskytovatele služeb. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

18 Vývojový cyklus SOAD I Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie 1 Identifikace kandidátních služeb tři přístupy: analýza shora-dolů, (dekompozice business procesů na nové služby) analýza zdola-nahoru, (kompozice existujích služeb do business procesů) modelování cílových služeb (angl. goal-service modeling). (ohodnocení služeb a výběr dle jejich business přínosu) Využívá diagramy případů užití (UML) a popisy business procesů (BPMN), tj. aktivity procesů rozdělené mezi za ně zodpovědné aktéry. 2 Klasifikace služeb testuje kandidátní služby na soulad s vlastnostmi SOA. (znovupoužitelnost, abstrakce, bezstavovost, atd.) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

19 Vývojový cyklus SOAD II Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie 3 Analýza podsystémů (rozkládá kandidátní služby na komponenty, navazuje předchozí na dekompozici) funkční komponenty poskytují business funkce, (např. výpis odebraných položek objednávky pro fakturu) technické komponenty poskytují podpůrné funkce, (např. konverze měn, obecný přístup do databáze, atd.) služby jak komponenty realizují aktivity business procesů. (např. vystavení faktury) 4 Specifikace komponent vzniká datový model pro rozhraní komponent (rozhraní), (např. jako konceptuální diagram tříd v UML) probíhá návrh spolupráce a komunikace komponent (protokol). (např. jako UML sekvenční diagram volání komponent) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

20 Vývojový cyklus SOAD III Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie 5 Sestavení služeb přiřazení komponent do příslušných vrstev architektury, (sdílení technických komponent, bezstavovost funkčních komponent, atd.) sestavení komponent do výsledných služeb. 6 Realizace služeb rozhodnutí o způsobu realizace služby, (konkrétní technologie) řešení otázek bezpečnosti, správy a monitorování služeb. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

21 Webové služby (Web Services) Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie Webové služby jsou neznámější a nejpoužívanější technologií pro implementaci SOA 2. Postaveny na následujících standardech: Simple Object Access Protocol (SOAP) a HTTP protokol, (komunikační spojení, obálka, adresace, volání konkrétních služeb) extensible Markup Language (XML), (strukturování informací během přenosu a pro popisu) Universal Description, Discovery and Integration (UDDI), (mechanismus registrů pro vyhledávání webových služeb) Web Services Description Language (WSDL). (popis funkcí a umístění služeb a způsobu komunikace) 2 Technologie Web Services samotná není implementací SOA. Implementací SOA je realizace konkrétního systému, např. pomocí WebServices. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

22 Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie Simple Object Access Protocol (SOAP) Protokol SOAP: základní vrstva WS technologie, výměna XML zpráv, patří do aplikační vrstvy pětivrstvého TCP/IP modelu, bezstavový protokol, nezávislé na protokolu a implementaci, (jedním z protokolů komunikace je HTTP/HTTPS protokol) podporuje několik typů volání funkcí služeb, (kde klient posílá XML zprávu na server, nejznámější je implementované Remote Procedure Call (RPC), SOAP vychází ze staršího XML-RPC) definuje strukturu zprávy (obálka kolem hlavičky a těla). (pravděpodobně vychází ze staršího Web Distributed Data exchange (WDDX)) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

23 Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie Web Services Description Language (WSDL) W3C zavedla WSDL jako standard pro XML popis webových služeb. Jaké funkce poskytuje daná služba? Kde je daná služba uložena? Jak může být s danou službou navázána komunikace? Každá služba jako množina koncových bodů (service endpoints). v těchto bodech komunikuje s okolím pomocí zasílání zpráv, (pro jednoduchost si lze koncový bod představit jako rozhraní služby) WSDL poskytuje formální definici koncových bodů: 1 abstraktní popis koncového bodu, (popis rozhraní služby bez ohledu na konkrétní technologie a protokoly) 2 konkrétního popis koncového bodu. (navázání abstraktního popisu na reálnou implementaci a komunikace na konkrétní protokol) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

24 Definice, výhody a nevýhody Vývojový proces Nástroje a implementační technologie Role, úlohy a nástroje při vývoji SOA (dle IBM) 1 Business Executive? Convey business goals and objectives Rational RequisitePro 2 Business Analyst? Analyze business requirements WebSphere Business Modeler 3 Software Architect? Design the architecture of the solution Rational Software Architect 4 Web Services Developer? Implement the solution Rational Application Developer, WebSphere Integration Developer Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

25 Scénář případové studie Identifikace služeb Specifikace služeb Realizace služeb Definice (Scénář případové studie) A consortium of companies has decided to collaborate to produce a reusable service for processing purchase orders. The goals of this project are to: establish a common means of processing purchase orders, ensure that orders are processed in a timely manner and deliver the required goods, help minimize stock on hand and inventory maintenance costs, minimize production and shipping costs. Na základě scénáře odstartuje analýza požadavků. Business analytici určí business procesy, jejich vstupy a cíle. (výsledek je zachycen v business proces modelu Purchase Order Process ) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

26 Business Process Model Identifikace služeb Specifikace služeb Realizace služeb Process Purchase Order Scheduling Shipping Invoicing Initiate Price Calculation Complete Price Calculation Process Invoice Customer Purchase Order Receive Purchase Order Process Schedule Shipping Info Schedule Shipping Info Update Shipping Resuest Request Shipping Customer Purchase Order Customer Request Production Scheduling Send Shipping Schedule Customer Purchase Order Schedule Schedule U každého business procesu je dále určena jeho role, očekávané cíle a způsob interakce s okolními procesy. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

27 Vlastní identifikace služeb Identifikace služeb Specifikace služeb Realizace služeb Na základě modelu a popisu jsou vybrány procesy a skupiny spolupracujících procesů, jako tzv. candidate services. (formovány bez nefunkčních (IT) požadavků, business services ) Služby jsou navzájem propojeny, dle očekávané spolupráce. (při modelování spolupráce vycházíme z odpovídajících business procesů) Otázky při specifikaci spolupráce: What effect is the requirement intended to accomplish? Who participates to get it done? What are the roles responsible for? What roles interact? What are the rules for how the roles interact? How do we evaluate whether the requirements were met? Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

28 Identifikace služeb Specifikace služeb Realizace služeb Specifikace požadavků na služby Nejprve jsou modelovány požadavky na služby řešící proces Process Purchase Order. Požadavky jsou rozděleny podle tříd řešených (pod-)procesů. (Purchasing, Shipping, Invoicing, Scheduling) Jsou naznačeny závislosti požadavků (dle procesů). Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

29 Průběh požadovaných služeb Identifikace služeb Specifikace služeb Realizace služeb Je namodelována posloupnost požadavků pro splnění procesu Process Purchase Order. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

30 Identifikace služeb Specifikace služeb Realizace služeb Definice služeb a jejich topologie Požadavky jsou sdruženy do balíků (oddělení poskytovatelů). V každém balíku je definována jedna služba, která bude poskytovat požadavky. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

31 Identifikace služeb Specifikace služeb Realizace služeb Spolupráce služeb na hlavním business procesu Služby budou spolupracovat na řešení hlavního business procesu Process Purchase Order. Spolupráce musí odpovídat závislosti požadavků, které služby implementují. viz Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

32 Vlastní specifikace služeb Identifikace služeb Specifikace služeb Realizace služeb Identifikované služby se podrobněji specifikují, aby bylo zřejmé: jméno služby vč. stručného popisu činnosti, poskytovaná a požadovaná rozhraní služby, (jména funkcí, (ne)povinné vstupy, výstupy, vstupní a výstupní podmínky, výjimky) komunikační protokol mezi poskytovatelem a spotřebitelem, průběh, omezení a požadavky na použití služby. (vlastnosti spotřebitele, kvalitativní požadavky, politiky, atd.) Obvykle se modeluje pomocí UML diagramu tříd a dalších diagramů. Poskytovatel je třída implementující poskytované rozhraní. Spotřebitel je třída používající rozhraní spotřebovávané služby. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

33 Modelování specifikace služeb Identifikace služeb Specifikace služeb Realizace služeb Jednoduché služby jsou modelovány přímo jako třídy. Složitější služby jsou modelovány (ukázka viz další strana) jako třídy vč. realizovaných a používaných rozhraní, s průběh komunikace (protokolem) pomocí diagramů interakce. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

34 Identifikace služeb Specifikace služeb Realizace služeb Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

35 Datový model služeb Identifikace služeb Specifikace služeb Realizace služeb Definuje se model dat používaných službami. Datové entity by měly být provázány, splňovat normální formy, atd. Datový model je součástí obecné specifikace služeb. (tzn. mohou ho používat i služby třetích stran, je veřejný; nemusí odpovídat struktuře zpráv v konkrétní implementaci služeb) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

36 Realizace služeb Identifikace služeb Specifikace služeb Realizace služeb Na základě specifikace se navrhnou poskytovatelé služeb. Rozhodne se, kdo bude co poskytovat. (jeden poskytovatel pro vše až po jednom poskytovateli na každou službu) Modelují se vztahy spolupracujících spotřebitelů/poskytovatelů. Otázky při návrhu spolupráce: Where the services are most likely used? Where they are most likely to be deployed? What qualities of service are required? Stability of the functional area? Where the most change is anticipated? How much coupling is tolerable in the domain? Security issues? Applicable platform implementation technologies? Integration and reuse of existing systems? Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

37 Návrh poskytovatele Identifikace služeb Specifikace služeb Realizace služeb Komponenta s implementací poskytovaných fcí (dle rozhraní). (modelem, slovně nebo v (pseudo-)programovacím jazyku) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

38 Kompozice služeb Identifikace služeb Specifikace služeb Realizace služeb Služby spolupracující v rámci choreografie se složí. (zde všechny služby spolupracují na procesu Process Purchase Order ) Celek tvoří jedinou službu provádějící hlavní business process. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

39 Identifikace služeb Specifikace služeb Realizace služeb Jádro složené služby struktura a chování Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

40 Identifikace služeb Specifikace služeb Realizace služeb Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

41 Implementace služeb Identifikace služeb Specifikace služeb Realizace služeb Implementuje se na základě návrhu (realizace) služeb. Vybere se vhodná implementace SOA a konkrétní technologie. (např. WebServices a Java EE aplikační kontejner/server) Na základě specifikace služeb se definují rozhraní a datové typy. (abstraktní popis koncových bodů pomocí WSDL) Podle návrhu poskytovatelů služeb se implementují rozhraní. (konkrétní popis koncových bodů pomocí WSDL) Z popisu chování služeb/poskytovatelů se implementuje (business) logika. Vytvoří se systém pro monitoring a správu služeb. (uplatnění specifikace služeb a implementačních požadavků) Služby se zapojí do prostředí. (napojení na ostatní systémy, tvorba a napojení uživ. rozhraní, atd.) Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

42 logická arch. popisuje návrh, arch. nasazení popisuje provedení, architektura SOA popisuje poskytovatele a spotřebitele, při návrhu SOA se vychází z modelů business procesů, SOA implementuje procesy jako účelově spolupracující služby. Pokračování? v AIS o návrhu IS pomocí SOA a o Java EE, v PDI o WebServices v Java EE a Enterprise Service Bus, Servisně orientované architektury v prostředí Oracle (IOA). Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

43 Literatura Literatura Poděkování a otázky Přílohy Amsden, J. (2007). Modeling SOA: Part 1. service identification, Part 2. service specification, Part 3. service realization,.... IBM developerworks. Arsanjani, A. (2004). Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA. IBM developerworks. Bass, L., Clements, P., and Kazman, R. (2006). Software Architecture in Practice. Addison-Wesley Professional, second edition. Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

44 Literatura Poděkování a otázky Přílohy Děkuji za pozornost. Otázky? Diskuze? Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

45 Literatura Poděkování a otázky Přílohy Business Process Modeling (Notation) ZAČÁTEK PŘÍLOHY zpět do prezentace přeskočit přílohu Výňatek z prezentace: Kari Alho: Linking Business Process Modeling to SOA and UML 2.0 with Together technologies. Borland Finland, Business is Driven by Process Business Process Modeling Notation BPMN Elements, Flow Objects, and Artifacts Event, Activity, and Gateway Types Connecting Objects, Sequence Flow Markers BPMN Swimlanes Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50

46 Linking Business Process Modeling to SOA and UML 2.0 with Together technologies Kari Alho Borland Finland Oy

47 Business is Driven by Process Organizations have strategic objectives that they aim to achieve: Vision, Mission, Business plan Stakeholders work subject to policies, regulations, and established practices to achieve these goals. The fundamental concept bringing these together is a business process. Every business has a set of processes that define: how it develops products and services (Development, Change Management) how it generates revenue (Orders, Support) how business administration operates (HR, Finance, Legal) Business Process Modeling captures these details Business processes are a strategic and critical asset To be used as documented process for process improvement Or capturing the context and high-level requirements of a software system Order Order Delivery Invoicing processing Start Event1

48 Business Process Modeling Notation Created by Business Process Management Initiative the Notation Working Group was formed in Aug It composed of members representing 35 companies, organizations, or individuals. May 2004, the BPMN 1.0 specification 2005, merged to OMG Feb 2006, OMG Final Adopted Specification Main web site BPMN defines Business Process Diagram (BPD) BPDs are an extension of common flowcharting

49 BPMN Elements BPMN defines four core categories of elements: 1. Flow Objects Events, Activities, Gateways 2. Connecting Objects 3. Swimlanes Pools and Lanes which contain flow objects specific to participants and categories 4. Artifacts Data Objects, Text Annotations, Groups

50 BPMN Flow Objects Start Intermediate End Event: an open circle, affect the flow of a process, usually have a cause (trigger) or an impact (result). An event can start, interrupt, or end the flow. Activity: rounded rectangle; task Gateway: diamond shape; controls fork or join of flow

51 Event Types Start and most Intermediate Events have Triggers that define the cause for the event. There are multiple ways that these events can be triggered. End Events may define a Result that is a consequence of a Sequence Flow ending.

52 Activity Types (atomic) Atomic task Loop task Multi-instance loop task Compensation task

53 Activity Types (compound) Collapsed Sub- Process Collapsed Sub-Process (Independent or Referenced) Embedded Sub-Process Start Task1 Task2 End Embedded Sub-Process (same as referenced, but drawn inside) Transaction Transaction

54 Gateway Types Exclusive Decision/Merge (XOR) Inclusive Decision/Merge (OR) Complex Decision/Merge Parallel Fork/Join (AND)

55 Connecting Objects Three types of Connecting Objects: Sequence Flow: indicates order (sequence) of activities in a process Message Flow: indicates flow between two process pools Association: used to associate artifacts with flow objects; show inputs and outputs of activities

56 BPMN Artifacts Artifacts are used as an extension mechanism. Three standard types exist: Data Object: shows how data is required or produced by activities Annotation: provide textual comments Group draws a visual boundary for documentation or analysis purposes but does not affect the model.

57 Sequence Flow Markers Restaurant Selections Conditional flow WithMilk = True Milk Vegetarian = True Veggie Coffee WithSugar = True Sugar MeatEater = True Meat Start Entree Chicken Dessert Pie Merge End Default flow

58 BPMN Swimlanes Swimlanes are used to visually organize work by role or responsibility. Two types: 1. Pool: represents a participant (organization) in a process; can also partition activities 2. Lane: a sub-partition within a Pool. Used to categorize and organize activities by organizational untis

59 Literatura Poděkování a otázky Přílohy Business Process Modeling (Notation) KONEC PŘÍLOHY zpět na začátek přílohy Marek Rychlý Softwarové architektury Přednáška pro SRI, 15. října / 50