Vzhledem ke stále větším snahám o prosazení jednoho konkrétního standardu by se mohlo nezúčastněnému pozorovateli zdát, že již není při výběru vhodné metodiky co řešit. Chyba lávky, zatím ještě nejsme tak daleko, aby bylo možno s klidným srdcem doporučit jeden jediný nástroj, který by dokonale sloužil rozmanitým účelům objektového modelování. Zůstává zodpovědět otázku, zda-li je vůbec možno takový univerzální, jednoduše použitelný prostředek vytvořit. Teprve čas ukáže, budeme-li moci tuto otázku zodpovědět kladně či nikoliv. Zatím se spokojme s nejrůznějšími řešeními, která jsou dostupná již dnes, přičemž nutno podotknout, že mnohá z nich jsou vcelku i použitelná a jejich nasazením lze zcela jistě dosáhnout hmatatelných výsledků. Po přečtení tohoto článku byste měli získat pokud možno komplexní pohled, v lepším případě přímo nadhled, na možnosti a přínosy nejvíce používaných metodik a metod objektové analýzy a designu IS.
Historie
Souběžně s postupným pronikáním objektového programování do běžné praxe vzrůstaly pochopitelně i požadavky na vytvoření odpovídajících metodik a metod pro analýzu a následný návrh informačních systémů, tzn. fází, které samotné programování (v širším slova smyslu implementaci) předcházejí. Nejschůdnější cestou se zdálo používání stávajících metodik, které se pro objektový přístup mírně přizpůsobily. Jako základ pro notaci (tj. grafický zápis) nejpoužívanějších objektových nástrojů se většinou použil ER diagram, který byl rozšířen o několik dalších nezbytných rysů. Přechod od strukturovaných metodik na metodiky objektové byl tedy někdy spíše záležitostí evoluční než revoluční, přičemž lze dnes jen těžko soudit, zda-li to bylo dobře či špatně. Podobným způsobem se vyvinula kupříkladu metodika OMT (Object Modeling Technique), naopak odlišnou cestou se vydala například metodika Booch, která se vždy prezentovala jako čistě objektová. Pravdou ovšem je, že toto členění nehraje zásadní roli a porovnáme-li například ony dvě zmíněné metodiky, najdeme jen málo opravdu výrazných rozdílů.
Intenzivněji se začalo o objektovém modelování hovořit v druhé polovině osmdesátých let, tj. v době, kdy se začal znatelně prosazovat celý objektový přístup. V průběhu několika málo let vzniklo až nepřehledné množství nejrůznějších metod a celých metodik, které byly postaveny na objektových základech. Ještě vcelku střízlivé odhady hovoří asi o padesáti, nicméně ve skutečnosti je toto číslo podstatně, podstatně větší. Některé z nich byly přínosem a inspirací (a dokonce se i používaly), jiné se nikdy neprosadily mimo úzký okruh svých tvůrců. Co je však důležitější, rychle vznikl nenasycený segment trhu, který skýtal potenciální zisk pro výrobce CASE nástrojů a konzultační firmy, kterých se za pár let objevilo nepočítaně. Jak jistě čtenář správně tuší, popisujeme situaci na západ od našich hranic, především v USA. Realita v ČR je diametrálně odlišná, nicméně už i u nás se blýská na lepší časy.
První generací nazýváme dnes ty metody a metodiky, které vznikly (spíše než dobou vzniku máme na mysli dobu, kdy byly prezentovány široké odborné veřejnosti) přibližně do konce osmdesátých let a začátkem let devadesátých. Jednalo se například o metodiky Booch nebo Shlaer/Mellor. Následovala druhá, o poznání mohutnější vlna, která přinesla metodiky OMT, Coad/Yourdon, Martin/Odell, Objectory, později BON apod. S postupem času vznikaly nové verze, do kterých se zapracovávaly nápady a koncepty „konkurenčních“ metodik. Například Use-Case modelování, které tvoří jádro metodiky Objectory/OOSE si postupně našlo cestu do metodiky OMT, naopak stavové diagramy z metodiky Booch byly nakonec nahrazeny stavovými diagramy dle OMT. Některé změny byly spíše charakteru kosmetického (dílčí změna notace), jiné byly docela zásadní (například vypuštění DF diagramů z poslední verze OMT apod.).
 |
|
Vzájemné ovlivňování metodik a metod OOAD |
S postupnou konvergencí se od sebe jednotlivé metodiky navzájem lišily čím dál méně. Nebylo tedy divu, že se postupně začaly ozývat hlasy volající po vytvoření pokud možno jednotného a široce akceptovaného standardu, který by sloužil jako doporučený prostředek objektového modelování. Všechny tyto snahy vyústily až v iniciování „Call for Proposal“ konsorciem OMG (Object Management Group – sdružení několika set firem realizujících se na trhu objektových technologií), které si kladlo za cíl zejména vytvoření obecně akceptovaného standardu notace objektových metodik, který by posléze sloužil jako vhodný komunikační prostředek. V průběhu let 1996 a 1997 bylo předloženo několik návrhů, z nichž byl později vybrán jeden, který posloužil jako základ pro budoucí standard. Zrodila se třetí generace metodik objektové analýzy a designu (OOAD).
Objektové metodiky a objektové modelování
Některé z objektových metodik, jejichž popis bude následovat nejsou metodikami v pravém slova smyslu. Některé jsou spíše množinou metod a nástrojů a nezabývají se až tak detailně například definováním odpovídajících procesních postupů pro jejich používání. Mnohé z nich jsou opravdu pouze nástroji, jejichž použití závisí na libovůli uživatele. Nicméně všechny jsou plnohodnotnými a použitelnými prostředky objektového modelování a více či méně odpovídají pojetí a chápání pojmu metodika. U případů, kde by toto označení přeci jenom mohlo selhávat na tento fakt upozorníme.
Začněme ovšem od začátku. Možná by nebylo od věci zodpovědět otázku: „co to vlastně to objektové modelování je ?“. Především vycházíme z předpokladu, že je možné na jakýkoliv reálný systém nazírat jako na množinu objektů, mezi nimiž mohou existovat určité vazby. O tomto sebevědomém tvrzení by se sice dalo dlouze diskutovat a nepochybně by bylo možno nalézt ilustrativní příklady, kdy tato idea selhává. Pro naše účely je ovšem toto tvrzení postačující a nebudeme se ho snažit dále nijak dokazovat. De facto jediným cílem objektového modelování je pak najít patřičné objekty, nějakým způsobem je popsat a především začlenit do společenství objektů ostatních, tj. nalézt ony vzájemné vazby. S tím pochopitelně úzce souvisí i další činnosti. Například ve fázi analýzy systému je přinejmenším vhodné přesně vymezit, co oním „systémem“ vlastně rozumíme, jinými slovy definovat zkoumanou oblast. Snažíme se hledat hranice systému, vysledovat vazby na jeho okolí atp. Již při těchto činnostech nalézáme objekty, které utvářejí celý systém.
V následujících etapách, tzn. designu a implementaci, už „pouze“ rozpracováváme jednotlivé objekty, blíže definujeme vazby mezi nimi a vůbec se snažíme vzniklé objektové modely nějakým způsobem konsolidovat, aby nám posléze zůstala jen nezbytná množina základních objektů tvořící jakési jádro systému. Tyto objekty tvořící tzv. obchodní logiku mohou být následně provázány například se SW objekty zajišťujícími komunikaci s uživatelem nebo persistentními objekty uloženými v databázi. Podíváme-li se blíže na dnešní postupy při tvorbě SW systémů, zjistíme, že je právě vrstva objektů obchodní logiky často opomíjena. Příčinou je samozřejmě chybějící analýza problému a problémové oblasti jako celku.
Uvědomujeme-li si tento základní princip objektového modelování, nečiní nám potíže pochopit návaznost jednotlivých kroků, které metodika předepisuje a můžeme daleko lépe využít všech metod a nástrojů, které metodiku podporují. Právě u objektových metodik je často rozhodující tento nadhled a zdravý rozum, který nám téměř v každé situaci pomůže zvolit optimální cestu dalšího postupu. Slepé následování metodických pravidel bez pochopení širších souvislostí a důvodů vykonávání jednotlivých kroků může mít mnohdy zhoubné následky.
Následující odstavce slouží jako přehled vybraných metodik objektové analýzy a designu, který nemůže být z pochopitelných důvodů chápán jako vyčerpávající průvodce detailně popisující specifika jednotlivých metodik. Detailní informace může čtenář hledat v doporučené literatuře, jejíž seznam je součástí tohoto článku.
Unified Modeling Language
Jedním z několika kandidátů, který se ucházel o přijetí sdružením OMG je Unified Modeling Language, doporučená notace objektových modelů. V tomto případě se nejedná o plnohodnotnou metodiku, ale pouze množinu nástrojů a prostředků, které bývají nějakou metodikou podpořeny. Co se týče postavení UML v rámci zmiňovaného “Call for Proposal” OMG, byl již od počátku tento návrh považován za favorita. Za UML stojí ve světě objektových technologií věhlasná jména jako Grady Booch (autor metodiky Booch), Ivar Jacobson (Objectory/OOSE) či James Rumbaugh (OMT). V souladu s obecným očekáváním byl nakonec tento návrh sdružením OMG adoptován. Nejnovější oficiální verze je OMG UML 1.3 z léta 1999.
Spojením OMT, metodiky vcelku silné v analýze, Booch, jejíž hlavní prostředky tvoří nástroje pro návrh a implementaci a Objectory/OOSE, osvědčené metodiky i v oblastech business modelování a BPR měla původně vzniknout tzv. Unified Method. Postupem času však začínalo být zřejmé, že se nepodaří navrhnout odpovídající proces, který by alespoň doporučoval, kdy a jak jednotlivé nástroje používat. Takřka přes noc se z Unified Method stal Unified Modeling Language a dnes se již nikdo nad pohnutou minulostí tohoto de facto standardu nepozastavuje.
UML slouží především jako sjednocující komunikační nástroj a takřka všechny výstupy z ostatních metodik je možné transformovat do podoby odpovídající UML. V současné době je v rámci UML k dispozici osm typů diagramů, které dovolují modelovat statickou i dynamickou stránku uvažovaného systému.
Téměř současně se vznikem OMG UML bylo prezentováno i několik metodik a metod, které berou sadu nástrojů UML za svou integrální součást. Za všechny jmenujme například Unified Process částečně vycházející z Objectory/OOSE nebo Catalysis, která je vhodná zejména pro tvorbu SW s využitím znovupoužitelných SW komponent. Co se týče budoucnosti UML, je možné vysledovat snahy o redukci a zjednodušení některých diagramů, na druhou stranu jsou právě na úkor jednoduchosti neustále přijímány nejrůznější rozšíření, která činí UML v některých oblastech težkopádným a přespříliš komplexním.
Nicméně i přes všechny výtky a nedostatky je UML použitelnou množinou nástrojů, které docela dobře slouží svému účelu a základní vytyčený cíl, tj. poskytnutí jednotného prostředku pro komunikaci, tento standard bezezbytku splňuje.
Object-oriented Process, Environment and Notation
 |
|
Rozsah metodiky OPEN |
Metodikou, tentokrát již opravdu plnohodnotnou, usilující o “vítězství” v Call for Proposal byla též OPEN. Své kořeny má tato metodika v projektu COMMA (Common Object Methodology Metamodel Architecture), jehož cílem bylo vytvořit metamodely většiny metodik a metod OOAD, na jejichž základech měl být poté vystavěn univerzální metodický prostředek. Klíčovými postavami, které se zasloužili o vytvoření a rozšíření OPEN jsou Brian Henderson-Sellers, Meilir Page Jones, Ian Graham a Donald Firesmith jakožto i osoby organizované v konsorciu OPEN. Některá z těchto jmen jsou dobře známa i mezi uživateli klasických strukturovaných metodik.
OPEN tvoří doporučená notace OML (OPEN Modeling Language), pro kterou existuje i zjednodušená verze OML light, jež je svým způsobem protipólem výše zmíněné notaci UML, dále odpovídající proces a definovaný životní cyklus tvorby IS, použité metriky atd.
Pokud jde o diagramy zaváděnými OML, existuje jich celá řada. Samozřejmě jsou většinou striktně odděleny na ty, které slouží pro modelování statické a naopak na ty, používané při modelování dynamické stránky systému. Do první kategorie spadají například kontextové diagramy pro zobrazení hranic a spolupracujících částí systému, diagramy hladin pro rozklad systému ve vertikálním směru a rozdělení aplikace na dílčí celky, diagramy konfigurací pro znázornění SW a HW celků a jejich spolupráce, dále například diagramy hierarchií dědičnosti, diagramy nasazení apod. Dynamická stránka systému je zpracovávána protřednictvím diagramů případů užití, diagramů spolupráce, sekvenčních diagramů, stavových diagramů apod.
 |
|
Diagramy OML COMN |
Komplexnost OML je porovnatelná s rozsahem notace UML. OPEN proces obsahuje popis doporučeného životního cyklu tvorby IS, v rámci něhož jsou nástroje OML používány. Jak proces, tak i notace jsou vytvořeny pokud možno tak, aby mohly být libovolně záměnné. Je tedy možné používat OPEN proces s notací UML a naopak například notaci OML spolu s procesem definovaným metodikou Catalysis.
I přes některé zjevné výhody oproti UML se OML a celá metodika OPEN moc neprosadila. Jak už to tak bývá, není to zapříčiněno technickými nedostatky, ale především obchodní politikou. Za OPEN stojí poměrně úzké konsorcium jednotlivých odborníků (i když pravda, že co jméno to pojem) kterému se bohužel nepodařilo prosadit svůj výtvor především mezi producenty CASE nástrojů. Zejména to je ten hlavní důvod, proč se OPEN, chtělo by se říct enfant terrible objektových metodik, výrazněji neprosadila.
Booch
Jedná se o jednu z vůbec nejstarších metodik OOAD, jejímž autorem je Grady Booch. Tato metodika je asi nejsilnější ve fázích designu, implementace a nasazení IS. Metodika Booch je výrazně ovlivněna programovacími jazyky Ada a zejména C++, s kterým se nejčastěji používá. Pro modelování statické stránky systému používá Booch diagramy tříd a diagramy objektů, pro modelování dynamiky zase diagramy interakce, stavové diagramy a nakonec diagramy modulů, diagramy procesů a kategorie tříd. Některé z nástrojů vhodných pro implementační fáze si později našly cestu v obměněné podobě i do množiny UML. Ve skutečnosti však nejsou stěžejními prostředky a jejich používání není zdaleka tak intenzivní, jako používání ostatních.
Metodika Booch postrádá některé fundamentální prostředky pro analýzu, což ji činí poměrně nevhodnou pro aktivity typu BPR a vůbec pro použití mimo rámec tvorby SW systémů. Spolu s OMT byla ve své době pravděpodobně nejvíce používanou objektovou metodikou, nicméně nutno podotknout, že podle nejrůznějších odhadů dohromady nesdílely více než 40 procent trhu.
Object Modeling Technique
Hlavním návrhářem Object Modeling Technique je James Rumbaugh. OMT je vlastně reprezentantem oněch smíšených metodik, které za svůj základ vzaly ER diagram a rozšířily ho o nezbytné objektové rysy. V prvních verzích obsahovala OMT navíc ještě DFD diagramy, které však byly později vypuštěny.
Ve druhé verzi přebrala OMT Use Case modelování z metodiky Objectory/OOSE, které je používáno především v analýze pro vymezení hranic systému a interakci systému s vnějším okolím. Na rozdíl od metodiky Booch se jako víceméně vhodné jeví i použití OMT ve fázi analýzy. Zkrácený životní cyklus je rozdělen do etap analýzy, systémového návrhu, objektového návrhu a implementace. OMT používá tři základní modely. Objektový (využití diagramů tříd vycházejícího z ERD), dynamický (zejména stavové diagramy vytvářené pro jednotlivé třídy) a funkcionální (právě tolik diskutované DFD).
Vzhledem ke svému původu jsou nástroje OMT používány i pro datové modelování. Možná, že právě kvůli svým kořenům ležícím v klasické strukturované analýze se OMT stala patrně nejrozšířenější objektovou metodikou vůbec a výraznou měrou ovlivnila své následníky. OMT zaujímá asi největší podíl mezi vývojáři CASE nástrojů, kde zejména ve spojení s notací UML suveréně dominuje. Kromě jiného se OMT stala základem pro jednu z českých variant, tzv. OOMT, která má svůj původ na VŠE, kde byla vyvýjena pod vedením P. Drbala.
Objectory/Object-Oriented Software Engineering
Z původně firemní metodiky Objectory (název vznikl spojením slov „object“ a „factory“) vytvořené Ivarem Jacobsonem se nakonec stal uznávaný prostředek pro business modelování. Zjednodušením Objectory vznikla metoda OOSE, která je určena především pro tvorbu počítačově orientovaných systémů.
Jádro Objectory/OOSE tvoří Use Case modelování, které slouží jako sjednocující prostředek mezi všemi fázemi vývoje IS včetně testování. Celá metodika byla detailně popsána v knize „Object-oriented Software Engineering: Use Case Driven Approach“, která se posléze stala jednou z biblí objektového programování. Ve spojení s Objectory se též poprvé začalo hovořit o objektových technologiích jako vhodném prostředku pro Business Process Reengineering. Zásadní prací na toto téma se stala další Jacobsonova kniha „The Object Advantage: Business Process Reengineering with Object Technology“.
Samotná metodika, ač vcelku známá a úspešná se moc neprosadila. Byla a stále je spíše inspirací pro ostatní metodiky, které z ní převzaly zejména techniky Use Case modelování. Možné příčiny, proč nebyla tato metodika více používána lze spatřovat jednak v nedosatku CASE nástrojů, zejména však ve faktu, že trvalo dlouhá léta, než se tato metodika plně „otevřela světu“. Zpočátku se za její nasazení platily značné částky, které mohly odradit vysoké procento případných zájemců. Namísto OOSE tak světu dominovala dvojice Booch+OMT, která má na rozdíl od OOSE svůj původ v zámoří.
Coad/Yourdon
 |
|
Vrstvový model v pojetí Coad / Yourdon |
Jméno Ed Yourdon je těm, kteří se orientují již delší dobu v problematice tvorby IS asi dostatečně známé. Klasická Yourdonova strukturovaná analýza patří dnes již mezi legendární a osvědčené prostředky. Především Peter Coad nese zásluhu na vytvoření objektové metodiky Coad/Yourdon, kterou řadíme spíše do druhé generace (i když toto zařazení může být sporné) metodik OOAD. Metodika se vyznačuje především svojí jednoduchostí, kvůli které byla často používána pro výuku objektového modelování.
Coad/Yourdon rozděluje systém do několikavrstvého modelu, jehož první vrstvou je vrstva subjektů následovaná vrstvou tříd/objektů, vrstvou struktury, atributů a služeb. Kromě tohoto členění je možné provádět i rozklad podle zaměření jednotlivých participujících objektů. Oddělující se tedy například objekty tvořící vrstvu zajišťující interakci s uživatelem (Human Interaction Layer), dále klíčová vrstva problémové oblasti (Problem Domain Layer), která de facto reprezentuje modelovaný problém, vrstva datových objektů apod. Tyto vrstvy si můžeme představit jako jednotlivé průsvitky, které na sebe můžeme poskládat, čímž dostaneme výslednou podobu objektového systému. Toto logické členění je do jisté míry obdobou hitu dnešních dnů – logického (nikoli fyzického) modelu trojvrstvé architektury.
Coad/Yourdon není, jakožto extrémně jednoduchá metodika příliš použitelná pro komplexní systémy, které kladou velký důraz na dynamické chování. Na druhou stranu byla nasazována pro tvorbu aplikací klient/server, kde se mohl dokonale uplatnit vrstvový model.
Shlaer/Mellor
Na rozdíl od ostatních metodik stojí přístup Shlaer/Mellor ke tvorbě IS na trochu odlišných principech. Zatímco OMT, Booch apod. využívají tzv. evoluční přístup, kdy se většinou střídají fáze analýzy / designu / implementace / validace s postupným zjemňováním a rozpracováváním, v metodě S/M (autory jsou Sally Shlaer a Stephen Mellor) použito odlišné schéma.
Odděleně je navrhnuta obecná, na konkrétní problematice nezávislá, architektura systému sestávající se de facto ze dvou částí. Na jedné straně máme klasické koncepty jako prostředky perzistence, datové struktury apod., na druhé straně máme přesně vymezená pravidla, jak rozčlenit aplikaci mezi tyto obecné koncepty. Takovýto model softwarové architektury je nakonec provázán s výsledky analýzy problémové oblasti, která probíhá obdobně jako při nasazení ostatních metodik.
Oddělení SW architektury od problémové oblasti může usnadnit dosažení maximální možné míry znovupoužitelnosti a tím i zvýšení efektivity práce, což je zároveň asi největším přínosem při nasazení této metodiky. Výše popsané principy tvoří dohromady filosofii tzv. rekurzivního translačního vývoje, který je do jisté míry protipólem onomu zmíněnému evolučnímu přístupu. Nejčastěji a nejúspěšněji je metodika Shlaer/Mellor používána pro vývoj systémů pracujících v reálném čase.
Class, Responsibility, Collaborators
Class-Responsibility-Collaborators zaujímá mezi ostatními metodikami výhradní postavení. Někdo by možná mohl zpochybnit její zařazení do kategorie metodik, neboť je často používána pouze jako nástroj pro dílčí problémy spojené s tvorbou objektových systémů. Hlavní přínos tkví především v jejím použití pro nalezení objektů participujících v modelovaném systému. Vůbec problém nalézt vhodné objekty je jednou z fundamentálních otázek, které musí být uspokojivě řešeny. Bohužel zatím neexistuje univerzální, efektivní a formálně popsatelný postup, jak toho dosáhnout.
K dosažení tohoto cíle se často používá Use Case modelování spojené s tvorbou dynamických modelů, při jejichž tvorbě se objekty postupně „vynořují“. Nicméně některé metodiky, které Use Case modelování vůbec neberou v potaz (např. Booch) se často omezují pouze na vágní slovní doporučení, jak si při hledání objektů počínat. Jednou z možných metod nalezení objektů může být například lexikální analýza, jejíž úspěšnost se ovšem pohybuje okolo 20%.
Právě tehdy může být úspěšně použita CRC (nebo metody a metodiky z ní vycházející, jako je OBA). Její použití spočívá v tvorbě a používání indexových karet (fyzické papírové karty libovolného formátu), které mají doporučený vzhled. Každá karta představuje samostatný objekt (resp. třídu), ke kterému je posléze přiřazena zodpovědnost (responsibility) a dále ke každé zodpovědnosti objektu jsou přiřazeny objekty, který na zajištění konkrétní zodpovědnosti spolupracují (collaborators). Objekty se tedy postupně vynořují právě jako jedinci z řad spolupracujích objektů. Celá dynamika objektového systému pro zajištění konkrétního scénáře může být následně simulována například v rámci pracovního workshopu řešitelského týmu. Z popisu je vidět, že se jedná o extrémně jednoduchý, ale vcelku efektivní (a v neposlední řadě i efektní) nástroj. Při podrobnějším pohledu je zřejmé, že se jedná o postup téměř identický s Use Case modelováním. S rostoucí složitostí se samozřejmě stává obhospodařovávání velkého množství karet oříškem, který může být vyřešen používáním podpůrného CASE nástroje. Na druhou stranu se tím ztrácí možnost „sáhnout si přímo na objekt“.
CRC se nejvíce hodí pro výuku objektového přístupu, pro kterýžto účel byla také původně svými autory vytvořena (Ward Cunningham, Rebecca Wirfs-Brock). CRC se stala mj. inspirací pro metodiku RDD (Responsibility-Driven Design) a metodu OBA.
Business Object Notation
Jedná se o poměrně mladou a jednoduchou metodiku uvedenou poprvé K. Waldenem a J. M. Nersonem v roce 1994. Právě její nenáročnost je často oceňována jako velká výhoda proti nadměrně komplexním metodikám ostatním. Business Object Notation (dříve Better Object Notation) je výrazně ovlivněna objektovým jazykem Eiffel, který je díky své jednoduchosti, konzistentnímu návrhu a silným výrazovým prostředkům používán především pro tvorbu systémů, jejichž klíčovou vlastností je bezpečnost a spolehlivost.
BON zohledňuje některé pokročilé objektové technologie, jakým je například princip kontraktu apod. Na druhou stranu kvůli své jednoduchosti neobsahuje některé prostředky, které jsou již považovány za téměř nezbytnou součást jakékoliv objektové metodiky. BON obsahuje poměrně slabé nástroje pro modelování dynamiky systému, paralelismu apod. BON je vedle Coad/Yourdon velmi vhodná pro výuku objektového modelování.
Business Object Relation Modeling
BORM je metodika částečně českého původu, která byla svými autory (J.Polák, V.Merunka, R. Knott) od roku 1993 vyvýjena pod záštitou grantového programu VAPPIENS (Various Programming Paradigms in Integrated Environments), později s podporou Deloitte&Touche.
Na rozdíl od jiných metodik BORM neodděluje striktně statický a dynamický pohled, naopak podporuje jejich koexistenci v rámci jednoho modelu. Důležité je však vůbec celé směřování této metodiky, která je orientována spíše více směrem k BPR a business modelování obecně než směrem k tvorbě SW, i když i v této oblasti byla používána, především pak ve spojení se systémy postavenými nad Smalltalkem. BORM vychází částečně z metodiky Coad/Yourdon, z které přejímá vrstvový model a metody OBA používané při počátečních analytických fázích. V nedávné době také začaly být některé z nástrojů této metodiky implementovány do metacase systému MetaEdit+, čímž se této metodice otevírá cesta do světa.
Business Object Relation Modeling je mj. používána při výuce objektových technologií na některých českých univerzitách, jmenovitě na fakultách PEF ČZU a FEL ČVUT.
Závěr
Z metodik a metod objektové analýzy a designu se postupem času stávají již poměrně vyzrálé prostředky tvorby IS. V posledních několika letech se ovšem do popředí zájmu stále výrazněji dostávají aktivity vedoucí i na BPR, které s tvorbou IS bezprostředně souvisí. I v této oblasti mají objektové technologie co nabídnout. Mluvíme-li o metodikách OOAD, pak je patrný stále větší příklon k zavádění prostředků vhodných právě pro tuto specifickou oblast. V ideálním případě je možné použít metody a nástroje jedné metodiky jako nosný prostředek business modelování, stejně dobře jako efektivní prostředky tvorby IS, který nové pracovní postupy adekvátně podpoří.
Objektové technologie nacházejí stále širší uplatnění. Zdaleka se již nejedná pouze o záležitosti spojené výhradně s „computer science“. Snad proto by se měly metody a metodiky příštích generací spíše než na cokoliv jiného zaměřit právě na tento fakt.