Softwarové architektury

Softwarové architektury od podnikových procesu˚ k IT službám

Marek Rychlý Vysoké uˇcení technické v Brneˇ Fakulta informaˇcních technologií Ústav informaˇcních systému˚

Pˇrednáška pro SRI 15. ˇríjna 2014

Marek Rychlý

Softwarové architektury — Pˇrednáška pro SRI, 15. ˇríjna 2014

1 / 50

Obsah

1

2

3

4

Cíle pˇrednášky Pˇredpoklady Softwarové architektury Definice, pozice ve vývojovém procesu Pˇrehled architektur Problémy a výzvy Aktuální trendy Architektura orientovaná na služby (SOA) Definice, výhody a nevýhody Vývojový proces Nástroje a implementaˇcní technologie Od podnikových procesu˚ k IT službám (pˇrípadová studie) Identifikace služeb Specifikace služeb Realizace služeb ˇ Shrnutí a záver Marek Rychlý


2 / 50

Softwarové architektury Architektura orientovaná na služby (SOA) Od podnikových procesu˚ k IT službám (pˇrípadová studie) ˇ Shrnutí a záver

Cíle pˇrednášky Pˇredpoklady

Cíle pˇrednášky

Mít pˇrehled o SW architekturách, problémech a ˇrešeních. ˇ architekturám orientovaným na služby (SOA). Porozumet ˇ používat SOA ve fázi návrhu IS. Umet Mít pˇredstavu o nástrojích pro návrh a implementaci SOA.

Marek Rychlý


3 / 50



Pˇredpoklady

1

Znát životní cykly SW (metody vývoje).

2

ˇ diagramum Porozumet ˚ BPMN a UML.

3

ˇ Mít zbežnou pˇredstavu o modelování business procesu. ˚

4

ˇ Mít zbežnou pˇredstavu o týmové práci a ˇrízení projektu. ˚

Marek Rychlý


4 / 50



Business Process Modeling (Notation) — zde má být pˇríloha — pˇrejít na pˇrílohu

Marek Rychlý


5 / 50


Definice, pozice ve vývojovém procesu Pˇrehled architektur Problémy a výzvy Aktuální trendy

Logická architektura vs. architektura nasazení Logická architektura (Architecture) je souˇcástí prvních fází návrhu IS, organizuje entity návrhových diagramu˚ (architektonické vzory), (tˇrídy do balíˇcku, ˚ funkˇcnost do vrstev, podsystémy do systému, ˚ komponenty do složených komponent, služby do agregovaných služeb, atd.)

ˇ (abstrakce). neˇríká nic o konkrétním fyzickém rozmístení Architektura nasazení (Deployment) je jednou z posledních fází návrhu IS, ˇ funkˇcních entit, definuje fyzické rozmístení ˇ data do databází, služby (objekty do aplikaˇcních kontejneru, ˚ systémy na uzly síte, mezi poskytovatele služeb, infrastruktura, atd.)

ˇ nezávisí na logické architektuˇre, pˇrestože ji vetšinou respektuje.

Marek Rychlý


7 / 50



Pozice ve vývojovém procesu definují se business procesy ⇒ specifikace navrhne se doménový model a logická architektura ⇒ návrh ... ˇ ⇒ integrace provede se rozmístení

1 1 obrázek pˇrevzat z Linking Business Process Modeling to SOA and UML 2.0 with Together technologies (Kari Alho, Borland Finland, 2006) Marek Rychlý


8 / 50



Pˇrehled architektur Logické architektury (Architecture) ˇ vrstvené architektury (vertikální a horizontální cˇ lenení), (peer-to-peer, klient-server, referenˇcní 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í nejaké paradigma. (architektura orientovaná na služby (SOA), komponentové systémy, . . . )

Architektury nasazení (Deployment) dané prostˇredím (sít’ové topologie), ˇ (hvezda, strom, ad-hoc, . . . )

dané platformou, (BEA WebLogic, IBM WebSphere, JBoss, . . . )

dané implementaˇcní technologií. (EJB, WebServices, CORBA, . . . ) Marek Rychlý


9 / 50



ˇ Co „nepˇrímo“ ovlivnuje architekturu? vývoj systému ˇ integrace) (ˇrízení projektu, inkrementální cyklus, FDD, testy, TDD, ale složitejší

struktura organizace ˇ ˇ ˇ (autonomní oddelení, fyzické rozmístení, postupné zavádení, vlastní IT)

zavedené systémy (adaptace existujících systému˚ a procesu, ˚ daná rozhraní, externí systémy, více dodavatelu) ˚

technologie a bezpeˇcnost ˇ zálohy a dostupnost) (heterogenní prostˇredí, off-line cˇ ásti, vlastnosti síte,

finance a marketing (prodej po modulech, customizace, delegace funkˇcnosti modulu, ˚ nákup ˇrešení)

ˇ logická architektura × architektura rozmístení Marek Rychlý


10 / 50



Aktuální trendy Definice (Softwarová architektura, IEEE-Std-1471-2000) základní organizace SW systému˚ zahrnující popis jeho komponent, jejich chování, vztahu˚ a vztahu˚ s okolím (tj. rozhraní), a principu˚ jejich návrhu a vývoje. Gridy (prodávání a nakupování IT zdroju, ˚ globální „super-poˇcítaˇc “, . . . )

Komponentové trhy (obchodování s výpoˇcetními prostˇredky, konstrukce IS ze zapujˇ ˚ cených komponent, vývoj architektury IS, dynamické vazby, agenti, univerzální modelování, . . . )

Service-Oriented Architecture (inzerování služeb, distribuce cˇ ástí IS do center IT služeb, respektování business pravidel, automatizace B2B procesu, ˚ ...) Marek Rychlý


11 / 50


Definice, výhody a nevýhody Vývojový proces Nástroje a implementaˇcní technologie

Architektura orientovaná na služby (SOA) 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ˇrebitel služeb na základeˇ popisu vyhledá službu v registru služeb a použije ji (service consumer).

Marek Rychlý


13 / 50



Spolupráce mezi službami v SOA služby poskytují své prostˇredky bud’ pˇrímo cílovému spotˇrebiteli 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ˇredky jiné (rovnocenné) služby pro realizaci nabízených funkcí,

2

agregace – služba sestavená ze dvou (nebo více, podˇrízených) služeb nabízí kombinaci funkcí dílˇcích služeb,

3

choreografie – služby potom spolupracují za úˇcelem provedení konkrétního business procesu,

4

orchestrace – služba ˇrídí souˇcinost ostatních služeb za úˇcelem provedení své cˇ ásti business procesu.

Marek Rychlý


14 / 50



Základní vlastnosti SOA standardizace: jednotný zpusob ˚ popisu služeb, zajišt’uje jejich kompatibilitu, ˇ volné vázání: co nejméneˇ vztahu˚ mezi službami, navazovány jen úˇcelove, abstrakce: služby pˇrístupné pouze pˇres rozhraní, zbytek zapouzdˇren (zpusob ˚ výpoˇctu, implementaˇcní techonologie, atd.), znovupoužitel.: služba použitelná v ruzných ˚ kontextech (aplikacích), ˇ na svém okolí, nezávislost: služby autonomní jednotky, nezávisí (skryte) ˇ uchovávat (viditelnou) stavovou informaci, bezstavovost: služba by nemela dohledatelnost: poskytovatel služby (dle potˇreby) dohledatelný v adresáˇri, ˇ kompozice: služby možno skládat do vetších funkˇcních celku˚ dle potˇreby.

Marek Rychlý


15 / 50



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ˇrebitel–poskytovatel = potˇrebuje × nabízí funkˇcnost, ˇ dekompozice (napˇr. menší nároky na zdroje), SOA je jemnejší ˇ výpoˇcetní logiky), SOA je více distribuovaná (rozmístení ˇ služby se snaží být bezstavové z vnejšího pohledu.

SOA vs. objektoveˇ orientovaný pˇrístup SOA pˇrístup preferuje volném provázání entit (služeb) × OO pˇrístup ˇ ejší ˇ vazby entit (objektu), pˇresneˇ vztahy mezi tˇrídami, tesn ˚ ˇ cnost × SOA pˇrístup s dediˇ ˇ cností základní vlastností OO pˇrístupu je dediˇ nepoˇcítá, preferuje delegaci, základní vlastností SOA pˇrístupu je bezstavovost entit × zapouzdˇrení dat do objektu˚ v OO pˇrístupu, ˇ aktivita služeb v SOA pˇrístupu je vyvolána až pˇríchodem nejaké zprávy, podobný pohled na abstrakci entit (rozhraní). Marek Rychlý


16 / 50



Konceptuální model SOA

model interakce mezi poskytovatelem služeb a spotˇrebitelem služeb

Marek Rychlý


17 / 50



Struktura SOA SOA je cˇ ásteˇcneˇ vrstvená architektura (vrstva = úrovenˇ abstrakce) 1

vrstva business procesu˚ – BP je posloupnost kroku˚ respektující business pravidla a vedoucí k zisku (hmotnému i ˇ nehmotnému), reprezentován sekvencí provedení nekolika služeb (choreografie služeb),

2

vrstva služeb – rozhraní jednotlivých komponent sjednocena do ˇ služeb, služba za behu sestavuje komponenty a pˇreposílá jim ˇ požadavky, služba na rozhraní zpˇrístupnuje své funkce (popis služby),

3

vrstva komponent – základní stavební kameny služeb, ˇ požadované kvality služeb realizace funkˇcnosti služeb a zajištení ˇ a jejich funkce jsou (QoS), komponenty jsou cˇ erné skˇrínky pˇrístupné pouze pˇres rozhraní.

Marek Rychlý


18 / 50



Service-oriented Analysis and Design (SOAD) Identifikace, specifikace a realizace komponent, služeb a choreografie služeb. Specifikace požadavku˚ z pohledu spotˇrebitele a poskytovatele služeb.

Marek Rychlý


19 / 50



Vývojový cyklus SOAD I 1

Identifikace „kandidátních“ služeb – tˇri pˇrístupy: analýza shora-dolu, ˚ (dekompozice business procesu˚ na nové služby)

analýza zdola-nahoru, (kompozice existujích služeb do business procesu) ˚

modelování cílových služeb (angl. goal-service modeling). ˇ dle jejich business pˇrínosu) (ohodnocení služeb a výber

Využívá diagramy pˇrípadu˚ užití (UML) a popisy business procesu˚ ˇ ˇ (BPMN), tj. aktivity procesu˚ rozdelené mezi za neˇ zodpovedné aktéry. 2

Klasifikace služeb testuje „kandidátní“ služby na soulad s vlastnostmi SOA. (znovupoužitelnost, abstrakce, bezstavovost, atd.)

Marek Rychlý


20 / 50



Vývojový cyklus SOAD II 3

Analýza podsystému˚ (rozkládá „kandidátní“ služby na komponenty, navazuje pˇredchozí na dekompozici)

funkˇcní komponenty – poskytují business funkce, (napˇr. výpis odebraných položek objednávky pro fakturu)

technické komponenty – poskytují podpurné ˚ funkce, ˇ obecný pˇrístup do databáze, atd.) (napˇr. konverze men,

„služby“ jak komponenty – realizují aktivity business procesu. ˚ (napˇr. vystavení faktury) 4

Specifikace komponent vzniká datový model pro rozhraní komponent (rozhraní), (napˇr. jako konceptuální diagram tˇríd v UML)

probíhá návrh spolupráce a komunikace komponent (protokol). (napˇr. jako UML sekvenˇcní diagram volání komponent)

Marek Rychlý


21 / 50



Vývojový cyklus SOAD III

5

Sestavení služeb pˇriˇrazení komponent do pˇríslušných vrstev architektury, (sdílení technických komponent, bezstavovost funkˇcních komponent, atd.)

sestavení komponent do výsledných služeb. 6

Realizace služeb rozhodnutí o zpusobu ˚ realizace služby, (konkrétní technologie)

ˇrešení otázek bezpeˇcnosti, správy a monitorování služeb.

Marek Rychlý


22 / 50



Webové služby (Web Services) ˇ a nejpoužívanejší ˇ technologií pro Webové služby jsou neznámejší implementaci SOA2 . Postaveny na následujících standardech: Simple Object Access Protocol (SOAP) a HTTP protokol, (komunikaˇcní spojení, obálka, adresace, volání konkrétních služeb)

eXtensible Markup Language (XML), ˇ (strukturování informací behem pˇrenosu a pro popisu)

Universal Description, Discovery and Integration (UDDI), (mechanismus registru˚ pro vyhledávání webových služeb)

Web Services Description Language (WSDL). ˇ služeb a zpusobu (popis funkcí a umístení ˚ komunikace)

2 Technologie Web Services samotná není implementací SOA. Implementací SOA je realizace konkrétního systému, napˇr. pomocí WebServices. Marek Rychlý


23 / 50



Simple Object Access Protocol (SOAP)

Protokol SOAP: ˇ základní vrstva WS technologie, výmena XML zpráv, ˇ patˇrí do aplikaˇcní vrstvy petivrstvého TCP/IP modelu, bezstavový protokol, nezávislé na protokolu a implementaci, (jedním z protokolu˚ komunikace je HTTP/HTTPS protokol)

ˇ podporuje nekolik typu˚ volání funkcí služeb, ˇ je implementované Remote (kde klient posílá XML zprávu na server, nejznámejší Procedure Call (RPC), SOAP vychází ze staršího XML-RPC)

ˇ definuje strukturu zprávy (obálka kolem hlaviˇcky a tela). ˇ (pravdepodobn eˇ vychází ze staršího Web Distributed Data eXchange (WDDX))

Marek Rychlý


24 / 50



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 muže ˚ být s danou službou navázána komunikace? Každá služba jako množina koncových bodu˚ (service endpoints). ˇ v techto bodech komunikuje s okolím pomocí zasílání zpráv, (pro jednoduchost si lze koncový bod pˇredstavit jako rozhraní služby)

WSDL poskytuje formální definici koncových bodu: ˚ 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ý


25 / 50



Role, úlohy a nástroje pˇri 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ý


26 / 50


Identifikace služeb Specifikace služeb Realizace služeb

Scénáˇr pˇrípadové studie Definice (Scénáˇr pˇrí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ákladeˇ scénáˇre odstartuje analýza požadavku. ˚ Business analytici urˇcí business procesy, jejich vstupy a cíle. (výsledek je zachycen v business proces modelu „Purchase Order Process“)

Marek Rychlý


28 / 50



Business Process Model Invoicing

Initiate Price Calculation

Process Purchase Order Shipping

Custom er

Com plete Price Calculation

Purchase Order

Receive Purchase Order

Process Schedule Shipping Info

Custom er

Schedule

Shipping Info

Update Shipping Resuest

Request Shipping

Purchase Order

Scheduling

Process Invoice

Custom er

Request Production Scheduling

Send Shipping Schedule

Custom er

Purchase Order

Schedule

Schedule

U každého business procesu je dále urˇcena jeho role, oˇcekávané cíle a zpusob ˚ interakce s okolními procesy. Marek Rychlý


29 / 50



Vlastní identifikace služeb Na základeˇ modelu a popisu jsou vybrány procesy a skupiny spolupracujících procesu, ˚ jako tzv. „candidate services“. (formovány bez nefunkˇcních (IT) požadavku, ˚ „business services“)

Služby jsou navzájem propojeny, dle oˇcekávané spolupráce. (pˇri modelování spolupráce vycházíme z odpovídajících business procesu) ˚

Otázky pˇri 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ý


30 / 50



Specifikace požadavku˚ na služby Nejprve jsou modelovány požadavky na služby ˇrešící proces „Process Purchase Order“. ˇ Požadavky jsou rozdeleny podle tˇríd ˇrešených (pod-)procesu. ˚ (Purchasing, Shipping, Invoicing, Scheduling)

Jsou naznaˇceny závislosti požadavku˚ (dle procesu). ˚

Marek Rychlý


31 / 50



ˇ požadovaných služeb Prub ˚ eh ˇ procesu Je namodelována posloupnost požadavku˚ pro splnení „Process Purchase Order“.

Marek Rychlý


32 / 50



Definice služeb a jejich topologie ˇ Požadavky jsou sdruženy do balíku˚ (oddelení poskytovatelu). ˚ V každém balíku je definována jedna služba, která bude poskytovat požadavky.

Marek Rychlý


33 / 50



Spolupráce služeb na hlavním business procesu Služby budou spolupracovat na ˇrešení hlavního business procesu „Process Purchase Order“. Spolupráce musí odpovídat závislosti požadavku, ˚ které služby implementují. viz

Marek Rychlý


34 / 50



Vlastní specifikace služeb ˇ specifikují, aby bylo zˇrejmé: Identifikované služby se podrobneji jméno služby vˇc. struˇcného popisu cˇ 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ˇcní protokol mezi poskytovatelem a spotˇrebitelem, ˇ omezení a požadavky na použití služby. prub ˚ eh, (vlastnosti spotˇrebitele, kvalitativní požadavky, politiky, atd.)

Obvykle se modeluje pomocí UML diagramu tˇríd a dalších diagramu. ˚ Poskytovatel je tˇrída implementující poskytované rozhraní. Spotˇrebitel je tˇrída používající rozhraní spotˇrebovávané služby.

Marek Rychlý


35 / 50



Modelování specifikace služeb Jednoduché služby jsou modelovány pˇrímo jako tˇrídy. ˇ služby jsou modelovány (ukázka viz další strana) Složitejší jako tˇrídy vˇc. realizovaných a používaných rozhraní, ˇ komunikace (protokolem) pomocí diagramu˚ interakce. s prub ˚ eh

Marek Rychlý


36 / 50


Marek Rychlý



37 / 50



Datový model služeb Definuje se model dat používaných službami. ˇ být provázány, splnovat ˇ Datové entity by mely normální formy, atd. Datový model je souˇcástí obecné specifikace služeb. (tzn. mohou ho používat i služby tˇretích stran, je veˇrejný; nemusí odpovídat struktuˇre zpráv v konkrétní implementaci služeb)

Marek Rychlý


38 / 50



Realizace služeb Na základeˇ 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ˇrebitelu/poskytovatel ˚ u. ˚ Otázky pˇri 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ý


39 / 50



Návrh poskytovatele Komponenta s implementací poskytovaných fcí (dle rozhraní). (modelem, slovneˇ nebo v (pseudo-)programovacím jazyku)

Marek Rychlý


40 / 50



Kompozice 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ˇrí jedinou službu provádející hlavní business process.

Marek Rychlý


41 / 50



Jádro složené služby – struktura a chování

Marek Rychlý


42 / 50


Marek Rychlý



43 / 50



Implementace služeb Implementuje se na základeˇ návrhu (realizace) služeb. Vybere se vhodná implementace SOA a konkrétní technologie. (napˇr. WebServices a Java EE aplikaˇcní kontejner/server)

Na základeˇ specifikace služeb se definují rozhraní a datové typy. (abstraktní popis koncových bodu˚ pomocí WSDL)

Podle návrhu poskytovatelu˚ služeb se implementují rozhraní. (konkrétní popis koncových bodu˚ pomocí WSDL)

Z popisu chování služeb/poskytovatelu˚ se implementuje (business) logika. Vytvoˇrí se systém pro monitoring a správu služeb. ˇ specifikace služeb a implementaˇcních požadavku) (uplatnení ˚

Služby se zapojí do prostˇredí. (napojení na ostatní systémy, tvorba a napojení uživ. rozhraní, atd.)

Marek Rychlý


44 / 50


ˇ Shrnutí a záver logická arch. popisuje návrh, arch. nasazení popisuje provedení, architektura SOA popisuje poskytovatele a spotˇrebitele, pˇri návrhu SOA se vychází z modelu˚ business procesu, ˚ SOA implementuje procesy jako úˇceloveˇ spolupracující služby.

Pokraˇcování? v AIS o návrhu IS pomocí SOA a o Java EE, v PDI o WebServices v Java EE a Enterprise Service Bus, Servisneˇ orientované architektury v prostˇredí Oracle (IOA).

Marek Rychlý


46 / 50

Literatura ˇ Podekování a otázky Pˇrílohy

Literatura 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ý


47 / 50


ˇ Dekuji za pozornost.

Otázky? Diskuze?

Marek Rychlý


48 / 50


Business Process Modeling (Notation) ˇ ˇ — ZACÁTEK PRÍLOHY — ˇ do prezentace zpet

pˇreskoˇcit pˇrílohu

ˇ Výnatek z prezentace: Kari Alho: Linking Business Process Modeling to SOA and UML 2.0 with Together technologies. Borland Finland, 2006. 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ý


49 / 50

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

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

Start

Order processing

Delivery

Invoicing

Event1

Business Process Modeling Notation Created by Business Process Management Initiative the Notation Working Group was formed in Aug 2001. 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 www.bpmn.org BPMN defines Business Process Diagram (BPD) BPDs are an extension of common flowcharting

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

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

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.

Activity Types (atomic) Atomic task

Loop task

Multi-instance loop task

Compensation task

Activity Types (compound) Collapsed Sub-Process (Independent or Referenced)

Collapsed SubProcess

Embedded Sub-Process Task1

Task2

Start

End

Transaction

Embedded Sub-Process (same as referenced, but drawn inside) Transaction

Gateway Types Exclusive Decision/Merge (XOR)

Inclusive Decision/Merge (OR)

Complex Decision/Merge

Parallel Fork/Join (AND)

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

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.

Sequence Flow Markers

Restaurant Selections WithMilk = True

Conditional flow Vegetarian = True

Veggie Coffee

MeatEater = True

Start

Milk

WithSugar = True

Sugar

Meat

Pie Entree

Chicken

Dessert Merge

Default flow

End

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


Business Process Modeling (Notation) ˇ — KONEC PRÍLOHY — ˇ na zaˇcátek pˇrílohy zpet

Marek Rychlý


50 / 50

Softwarové architektury

Recommend Documents