Aktuální vydání

celé číslo

10

2017

Systémy pro řízení výroby, PLM, SCADA

celé číslo

Půl století (super)objektově orientovaného programování

Objektově orientované programování slaví právě padesátileté výročí své existence a je stále aktuální. Autor, který měl příležitost se s kořeny tohoto neuvěřitelného jevu setkat, čtenáři stručně přibližuje jeho vznik, vývoj a výhled. 

Právě před půl stoletím, koncem května roku 1967, se v hotelu Lysebu nad norským hlavním městem Oslo sešla (také) půlstovka odborníků pozvaných z různých zemí světa na pracovní konferenci pořádanou mezinárodní federací pro zpracování informací IFIP (International Federation for Information Processing). Byla to onoho roku jedna z několika konferencí konaných pod patronací této federace, tato s tematikou simulačních programovacích jazyků. Počítačová simulace vznikla v USA a stejně tak programovací jazyky v ní používané. Mnohem později, během ročního pobytu v USA, jsem se mohl poněkud překvapen ujistit, jak i v běžném životě, tedy mimo svou případnou počítačovou profesi, Američané tíhnou k náhražkám; tato zkušenost mi dala schopnost lépe a do detailů porozumět faktu, že zrovna oni vynalezli počítačovou simulaci, kterou by bylo možné zjednodušeně chápat jako techniku záměny experimentálně zkoumaného systému za jeho náhražku, totiž (počítačový) model.

Kdy se používá náhražka? Když je z určitého důvodu výhodnější než ta původní entita. To platí pro náhražky např. v potravinách, oblékání nebo stavebnictví stejně jako při experimentování s něčím, co je moc drahé nebo nebezpečné a nebo těžko ovladatelné (pomalé v reakcích apod.), a co se proto nahradí modelem, přičemž ve věku výpočetní techniky je nasnadě, že je výhodné model realizovat jako výpočetní proces v počítači. V prvních letech se bouřlivě uplatňovaly analogové počítače, ale od počátku se hlásily o slovo ty číslicové: analogové počítače umožnily snadno a rychle realizovat modely, které inženýři – včetně těch „tradičních“ – snadno popsali obyčejnými diferenciálními rovnicemi; na realizaci jiných modelů ovšem většinou nestačily.

Byly to zejména systémy hromadné obsluhy, pro jejichž výzkum se technika simulace nabízela jako velmi užitečná, avšak – jako všechny modely realizované na číslicových počítačích – byly zatíženy potřebou je naprogramovat. Kdo neznal „fígle“, které lidstvo vymyslelo pro práci s číslicovými počítači, před touto potřebou snadno kapituloval, kdo však byl do tajů číslicových počítačů zasvěcen, tušil, že řešení se najde: pro dostatečně velký obor systémů se vytvoří speciální – tzv. simulační – programovací jazyk a překladač (kompilátor), který texty v něm (tedy popisy konkrétních systémů daném oboru) převede do strojového kódu příslušného počítače nebo alespoň blíž k němu.

Brzy – už začátkem 60. let minulého století – se v některých odborných oblastech simulační jazyky velmi přiblížily mentalitě jejich uživatelů: vyjadřování v nich bylo tak přirozené, že jejich uživatel mohl být utvrzován v iluzi, že nepopisuje nějaký počítačový model, nýbrž přímo ten systém (tu věc, ten fenomén), jehož počítačový model hodlá vytvořit. Popis pak byl automaticky přeložen tzv. kompilátorem do strojového programu. Kompilátor „dostal zabrat“, musel být vytvořen s pořádným programátorským fortelem, ale když už jednou byl, pak pro celou danou odbornou oblast umožnil „psát“ modely velmi snadno. Tedy obecně: určete odbornou oblast systémů, u kterých očekáváte, že je bude třeba simulovat, stanovte „profesně orientovaný“ simulační jazyk, v němž se tyto systémy budou „snadno a přirozeně“ popisovat a uživatelé v něm budou své simulační modely popisovat v podstatě stejně, jako by popisovali příslušný systém pro svého kolegu v práci. Tato – pro uživatele výborná – technika však hrozila kolapsem: počítačová simulace se totiž prosazovala stále šířeji, každá inženýrská, vědecká a společenská oblast má vlastní odborný jazyk, a tak hrozilo, že praxí bude požadována realizace stále většího počtu simulačních jazyků a na vytvoření jejich kompilátorů „nebudou lidi“. 

Počítačová simulace u nás před půl stoletím

V současnosti si neumíme představit situaci u nás v 60. letech minulého století. O technice počítačové simulace se u nás vědělo málo a např. autor tohoto článku se dozvěděl, že má odborné výsledky v oblasti počítačové simulace, až z toho, že byl pozván na zmíněnou konferenci v hotelu Lysebu jako jeden z přednášejících, a to na základě svých publikací pro lékařskou veřejnost; on sám v nich slovo simulace vůbec nepoužil a cítil, že ho nepotřeboval. Věda a technika na východ od železné opony byla v té době řízena z Kremlu, tedy v ruštině, a tento jazyk v oné době (a ještě dlouho potom) neměl vůbec termín pro počítačovou simulaci. Výuka v rámci matematiky, která termín simulace používala, totiž výuka zaměřená na metody Monte Carlo, se s cíli, stavem i praxí počítačové simulace zcela míjela. A tak není divu, že až delší dobu po uvedené konferenci, když už si její běžný účastník v hlavě vyjasnil některé reakce hlavně těch „ne běžných“ účastníků (totiž těch, kdo ji organizovali a dohlédli na další souvislosti), se začalo ukazovat, že právě ono setkání v hotelu Lysebu bylo určeno k tomu, aby se dospělo k určitému závěru, jak řešit slibný rozvoj simulace v blízké budoucnosti za situace, že – jak bylo poznamenáno – pro její široké uplatnění „nejsou lidi“.

Autor nebyl jediný, kdo skrytý cíl konference neuhádl: více než polovina z 25 pozvaných přednášejících na ní prezentovala své nejrůznější výsledky – od modelování paralelních dějů na počítači tradiční von Neumannovy koncepce, který má – jak známo – k paralelnosti pěkně daleko, přes zasvěcený přehled prostředků pro spojitou simulaci nabízených firmou IBM až po filozofování o tom, jak se liší popis systému od jeho modelu. Několik autorů však ve svých příspěvcích dalo vědět, že o problému syntézy simulačních jazyků vážně přemýšlejí. Například v té době známý teoretik programování J. L. McNeley měl příspěvek s názvem Compound Declarations o nástroji, který se později bohatě uplatnil v jazyku Simscript II a který uživateli tohoto jazyka umožňuje rozšířit pro potřebné proměnné význam dosazení – když se má nějaká hodnota dosadit, ještě se s ní něco provede (transformace, kontrola smysluplnosti, ale i např. informace o dosazení kdoví kde jinde atd.). Norský počítačový nestor J. V. Garwick měl přednášku s provokujícím názvem Do we need all these languages?, v níž představil návrh svého vlastního jazyka, který považoval za univerzální, schopný rozšiřování. 

Jazyk Simula

Byly to v těch dnech vynikající podněty, avšak přebil je příspěvek O.-J. Dahla a K. Nygaarda z Norského výpočetního střediska. Přinesl nejen ideje, ale i výsledky. Ty byly shrnuty do definice konkrétního programovacího jazyka nazvaného Simula (zkratkové slovo vytvořené z úplného názvu SIMple Universal programming LAnguage), jehož ideje byly následující:

  1. Počítačový obraz reálné či zamýšlené „věci“ (odborně: prvku systému) je analogie běžícího podprogramu – jeho lokální proměnné reprezentují vlastnosti (data, atributy) prvku, jeho algoritmus reprezentuje „žití“ („životní pravidla“, dynamiku) prvku a jeho lokální podprogramy reprezentují „schopnosti“, které může prvek na požádání (např. se strany jiného prvku) projevit.
  2. Aby mohl být prvek o projevení schopnosti požádán, musí být přímo či nepřímo „osloven“ (identifikován), takže k „typům“ tehdy běžných např. v jazyku Algol 60 (celočíselný, reálný – vlastně s pohyblivou desetinnou čárkou, textový atd.) přibývá typ „referenční“ (pointer), jehož hodnotou je nějaký prvek (ve skutečnosti, avšak skryt řadovému uživateli, běžící programový blok), popř. „nic“, žádný prvek.
  3. S typem pointer lze manipulovat podobně jako s ostatními typy, tj. může figurovat i jako parametr podprogramu, výsledek funkce apod. Je-li něčím takovým dejme tomu A a B je schopnost, kterou by měl mít A, pak A.B značí žádost prvku A, aby „vykonal službu“ tím, že projeví schopnost B. Služba může být spojena s jedním či několika parametry, takže taková žádost může mít tvar např. A.B(P). Šikovný programátor může na místě A a P použít nějaká substantiva a na místě B nějaké sloveso, spojku či předložku, čímž dostane výrazy připomínající konstrukce přirozeného jazyka (nejjednodušší: A.plus(B) např. pro sčítání vektorů nebo X.into(Que2) pro modelování systémů hromadné obsluhy či Vozidlo324.dojeďdo(místoF)).
  4. Když už se běžící konkrétní podprogram jeví jako analogie konkrétního prvku, „věci“, jeví se deklarace takového podprogramu analogie pojmu, který onu věc (a obecně: libovolně mnoho podobných věcí) charakterizuje. Filozoficky řečeno, jeho vyvoláním se taková věc jeví jako „instance“ daného pojmu. Na konferenci zavedli autoři na místě termínu pojem termín třída (class) – příklad zápisu viz obr. 1. Pro vyvolání podprogramu použili termín instance.
  5. Podobně jako „obohacujeme“ pojmy (totiž co do obsahu: např. hornina – metamorfovaná hornina – rula, člověk – Evropan – Čech, obrazec – čtyřúhelník – rovnoběžník – obdélník – čtverec) lze obohacovat čili „specializovat“ třídy a získávat tak podtřídy; specializace spočívá v doplňování dalších atributů a schopností, ve změně (upřesnění, zjemnění) schopností a v dodání dalších „životních pravidel“ (obr. 2).
  6. Autoři použili – jak sami sdělili „z politických důvodů“ – jako výchozí jazyk tehdy populární a propracovaný Algol 60. Téměř automaticky vyšlo z jeho důsledné orientace na vkládání bloků do jiných bloků, že deklarace tříd se může vyskytovat i v deklaraci jiné třídy. Je to něco jiného než podtřída. Už na konferenci v Lysebu autoři věděli, že je-li třída P zaváděna uvnitř třídy T, reprezentuje P pojem použitý v rámci „vidění světa“ reprezentovaného třídou T (např. T je vidění světa, v němž je newtonovský čas, a v něm pojme věc, která s jinými věcmi v tomto čase existuje, nebo vidění světa metalurgie oceli, v němž „se myslí“ v pojmech jako ocelářská pec, ingot, dopravní linka). Takto se mohla formalizovat celá odborná odvětví a pak specializovat na „konkrétnější“ odvětví (např. geometrie na část mechaniky nebo – jak se brzy ukázalo v naší zemi – metalurgie oceli na tu s kontilitím či „vidění světa nemocnic“ na „vidění dějů v konkrétní nemocnici“).
  7. Nechť v podprogramu P je volán podprogram Q. V jazyku Algol 60 (a v mnoha jiných) lze umožnit návrat práce podprogramu P jen tak, že Q „navždy“ ukončí tu svou. Jazyk Simula však má prostředky, jež umožňují návrat práce na podprogram, který už pracoval a své uplatnění opustil; dovoluje to např. modelovat přepínání mezi „aktivními životy“ několika prvků-protivníků ve hře či souboji, a to v jednom společném čase tak, že se několik prvků na dynamice celého systému střídavě uplatňuje v modelu hry dvou hráčů v šachy, ostatní pasivně čekají (častý případ v simulaci systémů hromadné obsluhy – přitom vůbec nejde o přepínání výpočtu v režimu reálného času).
  8. Po mnoho let však nebylo jasné, zda k něčemu bude vícekrát iterované vnoření tříd (P uvnitř T a nadto Q uvnitř P – co reprezentuje Q ve vztahu k T?). Trvalo dvě desítky let (a velmi k tomu přispěli čeští odborníci), než se význam objevil: obecně totiž ono Q uvnitř P vystihuje schopnost instancí třídy P „myslet“ s použitím pojmu Q, přičemž ono „myslet“ zahrnuje pomoc počítače, kde je Q jakožto třída reprezentováno. Takže P může např. reprezentovat i odborníka, který k rozhodování o světě, kde se nachází, používá počítač, na němž modeluje „svět“ Q (obr. 3).
  9. Je nabíledni, že ten svět sám mohl být formulován jako viděný v rámci Q, avšak s pomocí pojmů M, N atd. vnořených do Q, tedy už na čtvrté úrovni vnoření.

Po návratu z uvedené konference vznikla v Československé kybernetické společnosti při ČSAV zájmová Skupina uživatelů jazyka Simula, jejíž členové si mj. vzájemně předávali své poznatky o jazyku Simula. Po letech se dostal do Prahy i jeho kompilátor pro počítač Univac série 1100 a později i pro počítač IBM 370. Tak se mohl jazyk Simula uplatnit i v praxi, a to zejména v hutnictví oceli, v jaderné energetice, v silniční dopravě a po čase i v dalších odvětvích. Avšak to už se k nám dostaly osobní počítače, pro něž také existovaly kompilátory jazyka Simula.

Velmi poučné však je sledovat historický vývoj v zahraničí. Možnosti, které jazyk Simula nabízel, byly často zcela ignorovány. Snad na tom měl podíl i ne zrovna vhodný název jazyka, který u povrchně uvažujících odborníků vedl ke vzniku názoru, že jde o simulační jazyk. Je pravda, že jazyk Simula byl velmi vhodný k tvorbě simulačních modelů, avšak již na konferenci v Lysebu se ukázalo, že jde o moderní univerzální programovací jazyk, jak se tehdy říkalo: jazyk 3. generace, tedy jazyk schopný vlastního rozšiřování, aniž by bylo nutné zasahovat do jeho kompilátoru (to bylo ostatně zaneseno i v jeho již uvedeném úplném názvu – Simple Universal Programming Language). Avšak nechme jazyk Simula jeho osudu a zaměřme se na slova použitá v nadpisu tohoto článku. 

Objektově orientované programování

Termín objektově orientované programování se začal uplatňovat v roce 1980 v souvislosti s tehdejší novou verzí jazyka SmallTalk. Vyjádřeno velmi zjednodušeně, ta verze integrovala do již existujících verzí téhož jazyka možnosti uvedené zde v prvních pěti bodech. Jak to bývá v oboru programování v USA i jinde obvyklé, uvedený termín, zkracovaný na OOP (i v anglických publikacích ze slov object-oriented programming), byl používán, aniž by byl přesně definován1), a tak byl používán i pro některé později vzniklé programovací jazyky jako ModSim, C++, Object Pascal, Beta. A proto se od té doby po mnoho let potvrzovalo, jak podstatně bylo těch pět možností s uvedeným termínem spojeno. Tentýž termín se tu a tam použil – a to oprávněně – i ve vztahu k jazyku Simula, jehož vlastnosti zde byly již naznačeny.

Jakmile začal být termín OOP populární, bylo možné pozorovat jeho používání pro charakteristiku i takové práce, kde ani jeden z již uvedených bodů 1 až 8 nefiguroval. Ono totiž lze všude najít něco jako objekt. Naopak mnohým uživatelům OOP byl termín OOP příliš dlouhý, a tak vypouštěli jeho prostřední slovo a psali a mluvili o objektovém programování (object programming), zatímco jiní tento výraz používali pro popisy systémů, kde něco z bodů 1 až 5 chybělo. V současnosti se však už dostatečně ustálilo pojetí, že možnosti vyslovené v prvních pěti bodech našeho výčtu jsou pro použití termínu objektově orientované programování nutné a postačující.

Uváží-li se to, co existuje v odborné veřejnosti, je možné konstatovat, že objektově orientované programování jako pojem existuje půl století, ačkoliv jeho dnešní název je o něco mladší. Lze ovšem namítat, že onen termín je stejně málo výstižný jako název Simula pro programovací jazyk, který není omezen na použití v simulaci, avšak s tím, jakožto s historickým faktem, nelze už nic dělat2)

Super-objektově orientované programování

Možnosti naznačené shora v devíti bodech byly zahrnuty už v příspěvku předneseném Dahlem a Nygaardem roku 1967 v hotelu Lysebu a je třeba zdůraznit, že to platí i o bodech 8 a 9, nikoho však, ani ony autory, nenapadla hlubší interpretace. Ta autorům došla až o 30 let později, když se seznámili s konkrétními případy použití realizovanými mezitím českými odborníky. Dahl k nim tehdy poznamenal: „Nyní víme, k čemu to je. My jsme totiž tyto možnosti zahrnuli do jazyka kvůli jeho orthogonalitě.“ Doplňme, že pod tímto termínem byl skryt důsledně respektovaný princip vnořování bloku do jiného bloku, který byl tehdy zaveden v mezinárodní normě jazyka Algol 60, avšak důsledně nebyl realizován snad v žádné jeho konkrétní implementaci. Ani v drtivé většině objektově orientovaných jazyků navržených po roce 1967 nebyly zmíněné možnosti reflektovány3).

České zkušenosti nabídly využít je mj. v simulaci technických a společenských systémů, které samy obsahují počítače, jež jsou v těchto systémech schopny simulovat, a tak např. hodnotit, kam by mohla v budoucnosti vést okamžitá rozhodnutí, a podle výsledků takové „lokální simulace“ toto rozhodnutí případně modifikovat. Takže při simulaci „celého“ systému se v jeho modelu musí reflektovat to, že mezi jeho prvky jsou počítače, ty obsahují modely použité v oné „lokální simulaci“ a ty musí mít otevřené, avšak bezpečné kontakty s ostatními prvky zahrnutými v „celém“ systému (obr. 4, obr. 5).

Je evidentní, že s rozvojem informatizace společnosti se podobné „simulace simulací“ budou uplatňovat stále více. Pro dosavadní úlohy realizované s použitím uvedených možností se začal používat termín super-objektově orientované programování (Super-Object Oriented Programming – SOOP), jehož rozšíření ovšem dodnes nepřekračuje hranice komunity odborníků, kteří význam simulace systémů obsahujících prvky, které samy simulují, pochopili.

Těchto odborníků není mnoho a situace v oboru SOOP vypadá podobně jako kdysi v oboru OOP. Když něco dlouho proniká do odborné veřejnosti a nakonec do ní pronikne, zůstane to v ní dlouhou dobu, jak mimo jiné ukazuje i OOP: je jako zázrak, když se ono jako pojem udrželo půl století v oboru, kde se skoro vše mění tak rychle, že se na to za několik let zapomene. Uplatní se podobně i SOOP, ať už se nazývá jakkoliv? 

Evžen Kindler

Obr. 1. Třída geometry

Obr. 2. Třída transport

Obr. 3. Třída i_transport

Obr. 4. Snímek obrazovky, na níž je animována simulace kruhového dopravníku: objekt je po vstupu (místo znázorněno vlevo nahoře – O1) posílán na vybraná pracoviště z pěti připojených pracovišť, určených výrobním programem pro daný objekt; lze-li vybrat z několika, určuje optimální výběr pracoviště počítač integrovaný do simulovaného dopravníku: vytvoří si automaticky „ad hoc“ simulační program, na němž testuje možné následky učiněného výběru do budoucnosti a podle nich vybírá; nakonec objekt opouští dopravník (také na místě vstupu O1); animace „ad hoc vytvořeného“ modelu se objevuje výše na obrazovce pomocí stejných grafických prostředků: parametry modelu lze experimentálně zvolit tak, že reprezentují „ad hoc“ počítač tak pomalý, že se během simulace na něm realizované situace na dopravníku mění

Obr. 5. Vlevo je na obrázku snímek obrazovky s animovaným modelem kontejnerového překladiště, které obsahuje počítač, jenž toto překladiště řídí a mimo jiné pomáhá tehdy, když je třeba (1) určit optimální způsob „vydolování“ daného kontejneru a dopravit ho ven, (2) ověřit, zda nedojde ke konfliktu mezi dvěma takovými činnostmi, který by mohl umrtvit dění v celém překladišti, (3) opravit plánované činnosti, kdyby konflikt hrozil; počítač v takových případech automaticky vytvoří vlastní simulační model, jehož snímek je v pravé části obrázku