Napjainkban úgy tekintünk a tudásszerzésre, mint egy konstruktív modellépítő folyamatra. A szakértő, a tudás mérnök és az eszköz interakciója hozza létre a tudást. A modell nem más, mint a valós világból kiragadott probléma strukturált megértése. Egy ilyen struktúra elkészítése két részből áll. Egyrészt a probléma modellezéséből, hogy megértsük a vizsgált tulajdonságokat, összefüggéseket, másrészt a modell implementációjából, mely képes a valós világból vett probléma, és esetleg a hozzá hasonlóak megoldására

A továbbiakban egy valós világból vett probléma modelljén a tények, a közöttük fennálló összefüggések illetve a probléma megoldásához vezető cselekvéssorozat strukturált megértését értjük.

Tapasztalataink alapján 3 fő követelményt támaszthatunk egy tudás tervező rendszerrel szemben:

1. lehetőséget ad modell leírására, formalizálására
2. lehetőséget ad a modell implementálására és segít abban
3. igyekszik csökkenteni az ezek között tátongó “szakadékot”

Ezeket az alábbiakban részletesebben is kifejtjük.

Ahhoz, hogy a modellünket formalizálhassuk, az alábbi dolgokra van szükség

• Explicit jelölésekre, melyek segítségével lehetőségünk van megkülönböztetni egymástól a különféle nézőpontokat (pl. cselekvés orientált, állapot vezérelt, stb.), illetve leírni és összehangolni a különféle, párhuzamosan futó taskok cselekvését.
• Szókészletre, melyet az alulról felfelé haladó építkezésre használhatunk. A legtöbb probléma olyan, hogy teljes egészében tekintve bonyolult lenne megoldani, ezért részekre kell bontani. Olyan kifejezésekre lesz tehát szükségünk, melyeket építőkockákként használhatunk.
• Sablonokra, újrahasznosítható részekre, vagy általánosságban elfogadott modellek ötvözetére, hiszen a legtöbb probléma megoldása folyamán vannak visszatérő, egymáshoz hasonló részek.

Az OMOS egy olyan kísérleti nyelv, melynek segítségével eldönthetjük egy megközelítésről, mely kielégíti az imént tárgyalt feltételeket, hogy keresztülvihető-e vagy sem. Az OMOS és a MODEL-K mindketten csak részei egy nagyobb vállalkozásnak, melynek célja explicit problémamegoldó eljárások felhasználása a tudásalapú rendszerek készítésében.

A megfelelő szorítóeszköz kiválasztása az esztergapadhoz csak egy része egy nagyobb feladatnak, melynek célja az, hogy előállítási tervet kell generálni forgásszimmetrikus alkatrészek gyártásához.

Az OMOS programnyelv a feladat megoldására két irányból történő megközelítést nyújt. Az egyik a probléma megoldás alapú irány, a másik a terület struktúrájának megértésére alapuló irány. A kettő ötvözete lesz a feladat modellje, amely azonnal futtatható, így azonnal tesztelhető, mely által lehetőségünk van azonnal felfedezni jelenlegi modellünk hibáit, hiányosságait, és javítani azokat.

A terület modelljén a modellezni kívánt valós világ részének struktúra alapú megközelítését értjük. Ez azt jelenti, hogy megfigyeljük a tényeket és a közöttük lévő összefüggéseket, és ezeket írjuk le a rendszernek.

Objektum orientált leírást alkalmazunk ahhoz, hogy megadjuk a terület szerkezetét. Az objektum osztályokat nevezzük keretnek, melyeknek különféle tulajdonságokkal bírnak. Ezeket slotnak hívjuk. Meglévő keretekből újak keletkeznek öröklődés segítségével. Az objektumosztályok – melyeket keretek reprezentálnak – mutatják meg a terület szerkezetét. A keretek nem módosulnak a megoldási folyamat során, kizárólag ezek előfordulásait (objektumok) kezeli a rendszer.

Hogy mindezt jobban megérthessük, tekintsük az alábbi kódrészletet:

Az optimális szorítóeszköz reláció írja le az adott munkára ideális eszközt a fordulékonysági tulajdonság függvényében. A Tuples részben az látható, hogy a legmegfelelőbb eszköz az un. collet-chunk, amennyiben átlós irányú fordulékonyság szükséges, de inside-turning (???) nem.

Annak érdekében, hogy képesek legyünk összehasonlítani a különféle problémák megoldási módját, hogy újrahasznosíthassuk őket, és hogy esetleg egy kelléktárrá szervezhessük ezeket, a metódusokat a konkrét területtől függetlenül kell megfogalmaznunk. Hogy támogathassuk az alulról felfelé haladó építkezési formát, az eljárásokat apró építőelemekből kell összeállítanunk.

• a következtetési szabályokhoz hasonló, un. következtetési eljárásokból
• vezérlő szerkezetből

A megfelelő szorítóeszköz kiválasztásához szükség van egyrészt véges számú kritériumra, melyek segítségével kiszűrhetjük a nem megfelelő szorítókat, másrészt optimalizáló kritériumokra, melyek segítségével a “versenyben maradt” szorítók számadatai alapján kiválaszthatjuk a legjobbat.

Ez a fajta problémamegoldó eljárás elkülönítésen alapuló kiválasztás és optimalizálás néven ismert. Lépésekbe foglalva az eljárás így néz ki:

1. A munkadarab leírása, tulajdonságai alapján felállítunk különféle kritériumokat, melyek a kiválasztás alapjául szolgálnak
2. Kiválasztjuk azt a szorítót, mely teljes mértékben kielégíti a kritérium halmazt.
3. Ha a 2. lépés sikertelenül zárul, akkor “gyengítjük” az optimális eszköz fogalmát a “Válaszd ki a legjobb elérhetőt” nevű következtetési eljárás alapján
4. A munkadarab leírása alapján számszerűsítjük a költségeket az összes versenyben maradt szorítóeszköz esetében.
5. A “Találd meg a legjobbat” nevű következtetési eljárást használva kiválasztjuk ezek közül azt, amelyik használata a legkisebb költséggel bír.

Az OMOS-ban ez a változás a változókhoz rendelt értékekre és a változók szerepkörére korlátozódik. Amikor a változóhoz rendelt érték változik, az azt jelenti, hogy az objektum egy attribútuma változik meg.

A következtetési eljárás specifikációs része a változás természetét írja le kifejezések segítségével az érték illetve a szerepkör váltások esetében. Tekintsük az alábbi kódrészletet:

Ez a kódrészlet a “Válaszd ki a legjobbat” nevű következtetési eljárást írja le. Az 1-3. sorok adják meg a bemeneti, a kimeneti és a vezérlő szerepeket. A bemeneti szerepkör a kiolvasás után kiürül; a kimeneti szerepköröket a következtetési eljárás módosítja, a vezérlő szerepkör elemeit viszont módosítás nélkül olvassuk el. A 4. sor azt írja le, hogy ez a következtetési eljárás nem változtat a változók értékén. Az 5. sorból azt olvashatjuk ki, hogy amennyiben ez a következtetési eljárás “tüzel” (lefut), akkor az objektum a bemeneti szerepkörből a kimeneti szerepkörbe kerül át. A 6. sor azt a relációt mutatja (ezt a relációt már leírtuk fent), melyben megtaláljuk azt a tudást, ami alapján a 4-5. sorokban leírt változtatásokat a következtetési eljárás elvégez. (Magyarul ezen tudás alapján döntjük el, hogy egy adott objektum átkerül-e a bemeneti szerepkörből a kimeneti szerepkörbe, vagy változik-e valamely attribútuma.) A 8-10. sorok a következtetési eljárásban használt szerepköröket képzik le a reláció argumentumaira.

A problémamegoldás alatt a terület elemei - az objektumok – sokféle szerepben tetszelegnek. Eddigi példánknál maradva ezt úgy lehetne a legjobban szemléltetni, hogy megvizsgáljuk a különböző szorító eszközöket különböző szerepekben. Ha megvizsgáljuk az imént bemutatott következtetési eljárást, kezdetben minden szorító eszköz az “alternatív választás” szerepkörében látható. Amennyiben azonban kielégítik az aktuális kritériumokat, hirtelen ebből a szerepkörből átkerülnek a “lehetséges választás” szerepkörébe. Ezek közül pedig az, amelyik a legkedvezőbb költségeket mutatja, átkerül a “kiválasztott” szerepkörbe.

A szerepkörök dinamikusan változnak tehát a futás során, és a problémamegoldó éppen aktuális állapota jellemezhető velük. Az itt tárgyalt elkülönítésen alapuló kiválasztás és optimalizálás nevű problémamegoldó eljárásnak az alábbi szerepkörei léteznek:

• alternatív választás: az összes szorítóeszköz beletartozik, mely a modellünk része
• lehetséges választás: a kritériumrendszert kielégítő eszközök tartoznak ide
• kiválasztott: az optimális választás az eszközök közül

A vezérlő szerkezet egy általános eljárás, mely arra hivatott, hogy eldöntse: melyik következtetési eljárás fog tüzelni a következő alkalommal. Ez úgy működik, hogy meghívunk minden következtetési eljárást, hogy teszteljük, eszközölnének-e bármilyen változtatást. Hogy jobban értsük mindezt, áttekintjük, mit is csinál ez a vezérlő eljárás lépésenként

1. Meghívja az “Instantiate” nevű következtetési eljárást, mely létrehozza az aktuális munkadarab megmunkálásához szükséges elforgatási követelményeket.
2. Meghívja a “Válaszd ki a legjobbat” nevű következtetési eljárást, hogy az szigorú értelemben vett megfelelő eszközt találjon
3. Amennyiben a 2. lépés nem hoz eredményt, egy gyengébb kritériumokkal dolgozó következtetési eljárás kerül tüzelő pozícióba annak érdekében, hogy kiválassza a “lehetséges megoldások” szerepkörére alkalmas szorítókat
4. Kiválasztja az optimális szorítót

A feladat modellje a fentiekben részletesen leírt két rész, a struktúra és az eljárások ötvözete lesz. A következtetési eljárásokat megfeleltetjük a relációknak, a szerepköröket pedig megfeleltetjük a kereteknek és az ő előfordulásaiknak. A feladat tehát az, hogy egy ilyen megfeleltetést találjunk.

Példánknál maradva ez a következőképpen történik:

A költség leíró keret összes előfordulása írja le az optimalizáló kritériumot.

A szituációs paraméter a munkadarab leírása lesz.

A kiválasztó kritériumok a szorítók fordulékonyági jellemzőiből adódnak.

Az alternatív választás szerepkörébe kerül kezdetben az összes szorító eszköz, a többi szerepkör üres.

Ne felejtsük el: mindkét részmodell (struktúra, eljárás) fejlesztése tulajdonképpen párhuzamosan zajlik, és tulajdonképpen valamelyest független egymástól, viszont a végén a feladat modellje a kettőt ötvözve kerül ki.

Mint már korábban említettük, az OMOS-t úgy fejlesztették, mint egy kísérleti nyelvet, melynek segítségével megnézhetjük, hogy lehetséges-e kielégíteni mindazon követelményeket, melyeket a 2. részben támasztottunk.

A modell készítésre az OMOS két megközelítési lehetőséget ajánl: az eljárás alapút és a struktúra alapút. Mindkét megközelítési formának megvannak a maga egyszerű építőkövei, mint pl. az első esetben a következési eljárások, a szerepkörök, míg a második esetben a keretek, az előfordulások, a relációk. Így látható, hogy mindkét rész újrahasznosítható elemekből áll. A kettő ötvözéséből nyert modell közvetlenül futtatható, így az OMOS nem követel meg külön implementációs részt.