OBJEKTOVĚ ORIENTOVANÉ MODELOVÁNÍ V REINŽENÝRINGU BUSINESS PROCESŮ

Object-Oriented Modelling in Business Process Reengineering

Dr. Ing. Vojtěch Merunka

Adresa autora:

Katedra informačního inženýrství, PEF ČZU v Praze

Anotace:

Reinženýring business procesů patří mezi nejdůležitější techniky řízení v 90 letech, ale jeho formální základ je stále ještě ve vývoji, i když po praktické stránce jeho aplikace již většinou přinášejí nezanedbatelné výsledky. Proto je tento článek zaměřen na možnosti využití některých myšlenek objektové analýzy a návrhu ve spojení s teorií automatů a přináší vlastní návrh vhodných technik a nástrojů. Uvedené techniky a nástroje jsou součástí výzkumného grantového projektu VAPPIENS sponzorovaného Britskou radou, jehož cílem je sestavení komplexní objektově orientované metodologie analýzy a návrhu. Po praktické stránce byly uvedené techniky a nástroje od roku 1996 ověřovány a nyní jsou používány na rozsáhlých projektech firmy Deloitte&Touche Česká republika.

Klíčová slova:

objektová analýza a návrh, modelování, formální metody, teorie automatů, business process

Summary:

Business Process Reengineering (BPR) belongs to the most important techniques of management science in this decade, but its formal background is still under development even if the BPR applications put mostly the considerable results from the pragmatic viewpoint. Hence this paper is focused to the using possibilities of some ideas from object-oriented analysis and design of information systems in combination with the theory of automata into this area and presents the own proposal of the proper tools and techniques. Given tools and techniques are a part of the research grant VAPPIENS sponsored by the British Council. This project is targeted to the creation of the complex object-oriented analysis and design methodology. Discussed tools and techniques were practically tested since the year 1996 and now are used for large analysis projects by the Deloitte&Touche Czech Republic.

Keywords:

object-oriented analysis and design, modelling, formal methods, theory of automata, business process

Objektové metody, které dnes již lze označit za klasické, poskytují určité prostředky pro potřeby modelování podnikových procesů. Typickým představitelem je unifikovaná metoda (UML) [Sklenář, Rational], která ve verzi 1.1 obsahuje rozšíření směrem k “business” modelování. Většina takových rozšíření objektových metod (včetně uvedeného) vychází z Jacobsonovy “Use-Case” analýzy [Jacobson]. Tento přístup sice jde správným směrem, ale jednotlivé pojmy “business” modelu jsou na příliš abstraktní úrovni a celkově jsou značně podřízeny a svázány s následnými pojmy modelů ve fázi podrobné analýzy a návrhu.

Notace diagramu “business” modelu podle návrhu UML ukazuje, že se jedná o poměrně velmi jednoduchý nástroj, který dokáže popsat systém pouze na velmi vysoké úrovni zjednodušení. Kromě toho, že tento nástroj nedovoluje uspokojivě zachytit mnohé pro zadání důležité informace (např. pravidla, návaznosti, vazby mezi entitami, ...), tak je jeho další nevýhodou, která dále snižuje jeho použitelnost pro náležitý popis “business” procesů, jeho samotná koncepce a pojmový aparát, protože dle názoru autora má přímou vazbu na programovou strukturu navrhovaného systému, tedy např. na implementaci jednotlivých modulů apod. V případě potřeby zachycení většího detailu o modelovaném systému je doporučováno použití následných nástrojů UML, jako např. object interaction diagram, object-class diagram etc.

Bohužel ani jeden z vyjmenovaných nástrojů nedosahuje takové míry srozumitelnosti, jednoduchosti a zároveň výstižnosti, jaké ve své době dosahoval dodnes známý a používaný ER diagram nebo DF diagram. Například notace UML je pro neprogramátora velmi komplikovaná a obtížně čitelná. Na rozdíl od dříve používaného ER či DF diagramu, který je laikovi čitelný po čtvrthodinovém výkladu (zde je myšleno pouze postačující pasívní pochopení - ne schopnost takový model vytvářet), nelze prostředky UML nasadit například při jednáních se zadavateli a s pomocí nich ověřovat a korigovat správnost zadání, což by jistě bylo žádoucí, jenomže tyto prostředky jsou orientovány více na podporu softwarové implementace než na možnost podrobného modelování vlastních procesů.

proč provádět “business” analýzu

Samotný pojem “business” analýzy podnikových systémů je poměrně novou a v současné době velmi rozvíjenou aplikací OOP v praxi. Tato oblast modelování má dvojí na sobě poměrně nezávislý původ:

1. Prvním je potřeba formálního podchycení prvních fází vývoje informačního systému nástroji používajícími jiný pojmový aparát, než nástroje klasického softwarového inženýrství právě z výše popsaných důvodů. Tato potřeba vznikla na základě zkušenosti, že zahájení tvorby IS nějakou “klasickou” objektovou metodou zbavuje většinu zainteresovaných osob ze strany zadavatele schopnosti sledovat projekt již od samého počátku.

1. Jako druhá příčina rozvoje se považuje rozvoj vlastní teorie “business process” reinženýringu (BPR) právě v souvislosti se zjištěním, že myšlenky OOP jsou velmi přínosné pro konstrukci nástrojů a technik pro potřeby BPR, jak dokazuje např. [Eagle] a [Objecta].

Objektově orientovaná business analýza je metodou, která slouží modelu pro potřeby vlastního BPR a to jak zmapování stávajícího stavu (model as-is), tak i pro popis návrhu budoucího stavu (model to-be) jednotlivých modelovaných procesů.

metoda OBA

Metoda OBA (Object Behavioural Analysis) je představitelem pokročilé techniky sloužící k získávání strukturovaných podkladů ze zadání pro potřeby konstrukce prvotního objektového modelu. Právě proto je velmi vhodná pro nasazení v procesu BPR, kde výstupy OBA analýzy slouží ke konstrukci diagramů “business” objektů.

Metoda vnikla počátkem 90. let na základě zkušeností s aplikacemi různých technik JAD (Joint Application Design) a CRC (Class-Responsibility-Collaborator) pro potřeby objektové analýzy a návrhu a implementace v objektově orientovaných programovacích jazycích.

Jedná se o iterativní techniku začínající řízeným interview se zadavateli a pracující s různými typy formulářů, tabulek a modelových karet, ke kterým přísluší sada postupů a pravidel. Podrobnější popis OBA analýzy lze například nalézt v [OBA].

Jednotlivé kroky OBA analýzy jsou následující:

1. krok - rozpoznání procesů (plánování scénářů). V tomto kroku se na základě provedeného interview sestaví seznam požadovaných funkcí systému a tabulkascénářů systému. Jedná se vesměs o textové popisy, přičemž v nejjednodušší variantě se u každého scénáře rozlišuje původ procesu, vlastní popis procesu, participující entity a popis výsledku procesu.

1. krok - definování objektů pomocí modelových karet. V tomto kroku se pro každý rozpoznaný objekt z předchozího kroku vytvoří jeho modelová karta, která obsahuje jméno objektu, seznam aktivit objektu a s ním související seznam s modelovaným objektem spolupracujících objektů. Předpokládá se, že pro každý rozpoznaný spolupracující objekt je také vytvářena jeho modelová karta.

2. krok - klasifikace objektů. V tomto kroku dochází k přidání další informace k modelovým kartám jednotlivých objektů. Modelové karty jsou tříděny podle různých kriterií a podle určitých pravidel dochází ke vzniku nových modelových karet s novými objekty.

3. krok - sestavenítabulky vztahů mezi objekty. Tabulka vztahů v nejjednodušší podobě vyjadřuje jaký objekt má vztah s jiným objektem.

4. krok - modelování životních cyklů objektů. V tomto kroku se pro každý rozpoznaný objekt s pomocí informací v tabulce scénářů, modelových kartách a tabulkách vztahů sestaví životní cyklus objektu jako sled jeho stavů a přechodů mezi těmito stavy.

Metoda OBA je přímo založena na předpokladu iterativního přístupu k analýze. Například jednotlivé scénáře z 1. kroku jsou v 5. kroku příslušným předepsaným způsobem konfrontovány s životními cykly jednotlivých objektů a kontroluje se jejich vzájemná úplnost a souvislost. Následné kroky OBA tedy mohou posloužit i jako podklady pro dodatečné upřesňování informace v krocích předchozích. (Pro varianty známých řešení se doporučuje provést 2 až 3 opakování všech kroků).

OBA pomáhá získávat strukturovaným způsobem potřebné podklady k sestavení prvotních objektových diagramů. Má však i další zajímavé přínosy:

1. poskytuje prostředky pro kvalitní dokumentování projektu od samého počátku,

1. modelové karty a další výstupy OBA jsou znovupoužitelné v dalších podobných projektech (například jako návrhové vzory) a

Metodu OBA lze provádět dokonce jen s tužkou v ruce a příslušnými předtištěnými formuláři a tabulkami na papíře. Samozřejmě lepším způsobem je použití CASE nástroje, který dokáže většinu rutinních operací (například různé vzájemné kontroly, udržování projektových dat v konzistentním tvaru a možnost tisku tabulek a formulářů) provádět automaticky. (bude dále diskutováno v kapitole: softwarové nástroje “business” analýzy)

diagramy pro “business” analýzu

Již bylo řečeno, že pro potřeby konstrukce modelu s “business” objekty je nevhodné použití “klasických” konceptuálních diagramů. Z tohoto důvodu autoři jednotlivých metod doplňují svoje metody o různá rozšíření. Diagram, který by byl vhodný pro konstrukci modelů “business” objektů musí splňovat následující podmínky:

1. Musí být podstatně jednodušší a srozumitelnější než konceptuální diagramy typu object-class diagram, jak je známe např. z OMT nebo UML.

1. Musí zobrazovat objekty, jejich jména a aktivity .

2. Musí zobrazovat vazby (asociace) mezi jednotlivými objekty i přímo mezi aktivitami jednotlivých objektů (komunikace mezi objekty). Není potřebné vyjadřovat detailní podrobnosti vazeb jako např. různé varianty dědičnosti a nebo agregací, neboť se nejedná o podrobnosti nutné pro zobrazování procesů v BPR.

3. Musí zobrazovat stavy a přechody jednotlivých objektů v čase včetně souvislostí, jaké aktivity a jaké vazby má příslušný objekt v příslušném stavu. Množina spolu souvisejících stavů a přechodů jednoho objektu je označována jako “role objektu” v systému. Předpokládá se, že jeden objekt může mít v systému více rolí a že role jednotlivých objektů jsou na sobě závislé.

4. Musí dovolovat propojení spolu souvisejících stavů a přechodů různých objektů. Právě tato propojení, která vlastně obsahují propojené role různých objektů, slouží k popisu jednotlivých “business” procesů v systému. Tyto modely procesů (agend, zákaznických procesů,...) podrobně popisují způsoby užití (“use-cases”) modelovaného systému.

Obrázek v příloze je ukázkou velmi jednoduchého zákaznického procesu pomyslného kontraktu na softwarový produkt v notaci BORM. Diagram ukazuje sled stavů a přechodů (operací) hlavního objektu Kontrakt a jeho souvislosti s dalšími spolupracujícími objekty. Obrázek byl pořízen pomocí softwarového nástroje Metaedit [Metaedit].

softwarové nástroje pro “business” analýzu

Softwarová podpora “business” analýzy je již dnes částečně zahrnuta ve většině profesionálních CASE objektových nástrojích, jako například Rational Rose, Select nebo Paradigm Plus a další.

Kromě toho existují i specializované CASE nástroje pro podrobnou “business” analýzu, které však nejsou snadno dostupné na běžném softwarovém trhu, protože kromě toho, že jsou velmi drahé a málo poptávané, tak jsou většinou součástí know-how příslušných firem - viz. např. [Eagle] a [Objecta].

Pokud nutně nepotřebujeme drahý profesionální CASE, je také možné použít některý z inteligentních programů pro tvorbu prezentační grafiky (např. Visio nebo Visual Though) a opatřit si nebo sám vyrobit šablonky pro podporu příslušné metody.

Vzhledem k rychlému rozvoji a změnám v této oblasti je především pro potřeby velké konzultační firmy a nebo na akademickou půdu vhodné použití některého z meta CASE nástrojů, které jsou někdy také označovány jako CAME - Computer Aided Method Engineering. jedná se o takové CASE nástroje, které kromě tvorby modelu (jako obyčejný CASE) také dovolují modelovat samotnou metodu - např. doplňovat symboly a vazby a kromě definování jejich grafické reprezentace i popisovat jejich chování např. pomocí programovatelného generátoru výstupních sestav a tím například měnit z modelu generovaný kód apod.

Je třeba zdůraznit, že použití meta CASE nástroje není vhodné jen kvůli možnosti úprav a doplňování podporované metody vlastní silou. Je tu i možnost snadných úprav a změn používané metody na objednávku dokonce v průběhu řešení projektu a samozřejmě bez nutnosti měnit celý softwarový produkt.

Autor sám má zkušenosti s programem Metaedit, který patří do kategorie meta CASE systémů. Jedná se o nástroj, který již podporuje 3 metody vhodné pro BPR (Porters Method, Business Systems Planning by IBM a Godkuhls Activity Analysis) a 6 metod OOA&D (OMT, UML, Coad/Yourdon, Shlaer/Mellor, Fusion, Moses a Embley). Generuje kód SQL, Smalltalku, C++, Delphi Pascalu a Javy. Pro ukládání dat a metadat používá víceuživatelskou třídně-instanční objektovou databázi s podporou transakcí. Kromě různých i uživatelsky definovaných výstupních sestav Metaedit dovoluje prezentovat informaci každého modelu trojím možným způsobem: 1) graficky jako diagram, 2) ve vztahových maticích a 3) v tabulkách, přičemž například změna informace v tabulce či vztahové matici může vyvolat automatickou změnu grafické podoby odpovídajícího objektu v diagramu.

V době psaní tohoto článku byla v tomto prostředku zahájena implementace metodologie BORM.

závěr

OOP má v úvodních fázích analýzy informačních systémů nezastupitelnou úlohu. Dnes již neobstojí názor, že objektové prostředky jsou vhodné pouze jako lepší implementační softwarové nástroje dovolující využívat například předností vizuálního programování a nebo používání hotových komponent.

Vzhledem k neustále rostoucí složitosti zadání informačních systémů a také vzhledem k souvislostem s reinženýringem “business” procesů je třeba úvodním fázím analýzy prováděné objektovým způsobem věnovat náležitou pozornost.

literatura

[BORM] Knott R P, Polák J, Merunka V.: BusinessObject Relation Modeling Methodology, závěrečná zpráva k řešení projektu VAPPIENS, British Council - Know-How Fund, Dept. of Computer Studies, Loughborough University.

[Eagle] Andersen Consulting, The Project Eagle, http://www.ac.com/aboutus/tech/eagle/

[Jacobson] Jacobson I.: Object-Oriented Software Engineering - A Use Case Driven Approach, Addison Wesley 1992, ISBN 0-201-54435-0

[Merunka1] Merunka V.: Zkušenosti s objektově orientovanou analýzou a návrhem, ve sborník konference Tvorba softwaru 97, Ostrava 1997

[Merunka2] Merunka V.: Výuka OOP, ve sborníku sborníku konference Objekty 97, Praha, listopad 1997

[Metaedit] Metacase inc.: http://www.jsp.fi/metacase

[OBA] Rubin K.S., Goldberg A.: Object Behavioural Analysis, pp 48-62 Communications of the ACM 35(9) 1992; Goldberg Adele, Kenneth Rubin S.: Succeeding with Objects - Decision Frameworks for Project Management, Addison Wesley 1995, ISBN 0-201-62878-3

[Objecta] Objecta Ltd.: Object-Oriented Business Process Reengineering, http://www.objecta.demon.co.uk/home.html

[Rational] Rational inc.: Unified Modelling Language, http://www.rational.com

[Sklenář] Sklenář V.: Jazyk UML, ve sborníku konference Objekty 97, Praha, listopad 1997