CommonKADS módszertan. Molnár Bálint. PhD, egyetemi docens, BKÁE

CommonKADS módszertan

Molnár Bálint PhD, egyetemi docens, BKÁE

MTA Információtechnológiai Alapítvány 2003

1. A CommonKADS módszertan 1.1 A módszertan kifejlesztésének háttere A mesterséges intelligenciának nevezett informatikai terület egyik ága az ismeretalapú, tudásalapú rendszerek fejlesztése. Ez a terület nagyon erősen épít, arra a hipotézisre, amely szerint egy ismeretbázisú rendszer probléma, feladat megoldásra képes. Az informatikai alkalmazási rendszerek, szoftverek tervezői régen felismerték, hogy módszertanok nélkül a fejlesztés megbízhatatlan eredményt hoz. Mivel az ismeretalapú rendszerek fejlesztése sok tekintetben nagyon hasonló a hagyományos alkalmazási rendszerek fejlesztéséhez, hiszen az információ elemzése, alkalmazási terület behatárolása, projekt irányítás, stb., mind megjelenik ezeknél a rendszereknél is, ezért jelentős lépés a rendszertervezési módszertanok kialakulása a mesterséges intelligencia területén is. A fentebbi indokokból azonban az is következik, hogy egy átfogó teljes rendszerfejlesztési módszertan kialakításakor figyelembe kell venni és be kell illeszteni a szoftver és informatikai rendszertervezés tapasztalatait. A KADS (Knowledge Acquisition and Design Support) módszertant két ESPRIT (European Strategic Programme in Research in Information Technology) projekt keretében fejlesztették ki, majd további projektekben fejlesztették tovább és hoztak létre egy a módszertan támogató eszközt CKWB (CommonKADS Workbench)1. Project 12 1983 - 1984 Project 304 1984 - 1985 Project 1098 1985 - 1989 Project 5248 1990 - 1994 Project CP-7599 1994 - 1996 PEKADS (COPERNICUS)

1.2 A CommonKADS A CommonKADS módszertan célja az, hogy a szoftveripar számára nyújtson fejlesztési segítséget. Főként a következő elveken alapszik: • A fejlesztési megközelítés modellekre alapul, nevezetesen olyan modellekre, amelyek a világ olyan strukturált és absztrakt leírását adják, amelyek probléma megoldásra használhatók. A módszertan több olyan modellezési eljárást nyújt, amelyeket a feladat és a helyzet elemzésére illetve új rendszer tervezésére lehet felhasználni. • A módszertan egy olyan rendszer életciklus modellen alapszik, amelyet a konkrét projekt feltételeihez lehet szabni. Ez az életciklus modell különösen alkalmas az iteratív — az egyes fejlesztési lépéseket az előző szakaszok eredményeire támaszkodva, de valamivel magasabb szinten megismétlő — nem egyenes vonalú fejlesztésre. Ezt a spirál modellt eredetileg Boehm javasolta [Boehm88] (lsd. még röviden 1

Részt vevő szervezetek: Cap Gemini Innovation, Cap Programator, Netherlands Energy Research Foundation,Eritel SA, IBM France, Lloyds Register, Swedish Institute of Computer Science, Siemens AG, Touche Ross Management Consultants, University of Amsterdam, Free University of Brussels, Integral Solutions Limited, UK, MTA Információtechnológiai Alapítvány, Research Institute for Informatics, Románia.

[Molnár97]), amelyet a CommonKADS alaposan tovább részletezett, az első két szakaszt pedig a hagyományos szoftver tervezési lépésekhez közelítette.

• valamint egy általánosan felhasználható elemekből álló könyvtárra támaszkodik, amely modell sablonokból és alapvető építőelemekből áll. A módszertan főcélja az, hogy segítse az ismeretbázisú rendszerek tervezőit az adott alkalmazáshoz szükséges szakértelem modelljének megalkotásában, továbbá egy másik szerepe az, hogy az ilyen rendszerek tervezésével foglalkozókat segítse a tapasztalatok öszszegyűjtésében, összehangolásában, feldolgozásában.

1.3 A CommonKADS alapvető elemei A CommonKADS módszertan a következő három elemre épül: • A rendszer életciklus modelljén, amely tartalmazza a szervezet modellezést, minőségbiztosítást, szoftver illetve rendszer metrika kialakítását, rendszer validációt (a rendszer helyességének és az igényeknek való megfelelőségének ellenőrzését). • Újrahasznosítható elemekből álló könyvtáron. • Modellezési alapelveken. A CommonKADS módszertan úgy tekinti a létrehozandó modelleket, mint állandóan fejlődő, alakuló fejlesztési termékeket, amelyek mindegyike lényeges szerepet játszik a teljes fejlesztési folyamatban. A CommonKADS módszertan hat modell alkalmazását javasolja: • szervezeti modell: annak a környezetnek a leírása, amelyben az ismeretbázisú rendszer működni fog; • feladat modell: annak a lokális feladat halmaznak a megfogalmazása, vagy amely szerint jelenleg működnek, vagy amely szerint működni fognak; • ágens modell: azoknak az ágenseknek, rendszer szereplőknek és tulajdonságaiknak a leírása, amelyek a feladatmodellben felismert tevékenységeket hajtják végre; • kommunikációs modell: a rendszer ágensei, szereplői közötti kölcsönhatás, információ csere leírása; • szakértelem modellje: azon rendszer ágensek probléma megoldó képességének leírása, akik vagy amik a rendszer probléma megoldó tevékenységében részt vesznek. A CommonKADS fogalmi szintű modellezési keretének két fő komponense: • alkalmazási ismeretek, tudás; • probléma megoldási tudás, ismerete; Az alkalmazási ismeretek a konkrét alkalmazáshoz kapcsolódó szükséges szakértelmet jelentik, ez három ismeretelméleti kategóriába sorolható, nevezetesen a szakterület, feladat és következtetés logikájának területébe. A probléma megoldási tudás azokat az ismereteket jelenti, amelyek arra vonatkoznak, hogy hogyan kapcsolódik össze a szakterület, a feladat és a következtetések levonásának ismerete, hogyan alkalmazhatók, hogyan szerveződnek össze azért, hogy az alkalmazási ismeretek modelljét fel lehessen állítani. A probléma megoldási tudáson belül két fő alkotórészt különböztet meg a módszertan: • probléma megoldási ismeretek • stratégiai ismeretek. • tervezési modell: az ismeretbázisú rendszer felépítéséhez és működtetéséhez szükséges ismeretábrázolási és informatikai, számítástechnikai technikák segítségével megadható leírások és modellek.

Szervezeti modell a probléma megfogalmazása

Feladat modell szakmai jártasság igényelt kommunikációra való képesség kívánatos

szakértelem szükséges

Ágens modell

Szakértelem modell

Kommunikációs modell

informatikai megoldás

Tervezési modell

ábra 1. CommonKADS modelljei közti kapcsolat

2. A fejlesztési folyamat 2.1 Áttekintés A CommonKADS módszertan kifejezetten támogatja az ismeretbázisú rendszerek projektirányítási tevékenységét. Ez a segítség a következőkben nyilvánul meg: • a spirál modellben, amely a projekt kockázatok elemzésén és kiértékelésén alapul, és amely az ismeretbázisú rendszerek fejlesztési folyamatainak és tevékenységeinek egy szemléletét nyújtja; • a projekt irányítási ciklus tevékenységeinek részletes leírásában; • a projekt irányítás és műszaki fejlesztési tevékenység közötti kapcsolat megadásában (a CommonKADS modelleinek előállítása), amely segít: • projekt tervezési útmutatóval, továbbá; • a minőségi tervre vonatkozó előírások és a minőség tervezésére vonatkozó útmutatókkal.

2.2 A spirál életciklus A CommonKADS módszer nem ír elő rögzitett, egyenes vonalú ismeret bázisú rendszer fejlesztési folyamatot, hanem ehelyett egy a a kockázatok elemzésére támaszkodó fejlesztési folyamatot fogad el és igazit a saját igényeihez, ezt a megközelitést Boehm munkáiból veszik át.

Szemle A célok pontosítása

Alternativák készítése

A választott megközelítés korlátai A kezelhetetlen megoldások elvetése

minõségi szemle és döntés

A kockázatok feltárása és dokumentálása

A következõ cilklus tervezése A tervezett elõrehaladáshoz képest a fejlesztési eredmények értékelése

Kockázat elemzés

A fejlesztési megközelítés lépéseinek kijelölése

Az elfogadhatóság kiértékelése

Fejlesztés nyomonkövetése

Nyomkövetés

Kockázat elemzés

Az elfogadási kritériumok rögzítése

Terv készítés

Tervezés

ábra 2. A spirál modell a CommonKADS projekt tevékenységi ciklusára alkalmazva

Ennek a projekt kockázatok folyamatos elemzésére támaszkodó megközelítés adaptálásának az az értelme, hogy alkalmazodni kellett az ismeretbázisú rendszerek fejlesztésének jellegzetességeihez, nevezetesen az itereatív rendszer fejlesztési megközelítéshez, a követelmények evolúciós továbbfejlődéséhez, az új szoftver tervezési technikák és módszerek felhasználhatóságához, mint például a gyors prototípus fejlesztési eljáráshoz. Ez a spirál modell egy sokkal pragmatikusabb és következésképpen sokkal rugalmasabb szoftver fejlesztési megközelítés valósít meg; figyelembe veszi azokat a tényezőket, amelyek befolyásolják a rendszer fejlesztési projekt kimenetelét és miután ezeket a tényezőket tudatosítja mint létezőket, egy olyan megközelítést javasol, amely sokkal rugalmasabbnak bizonyult, mint a megelőző spirál modellek. Nagyon fontos jellemzője, hogy lehetővé teszi egy adott projekten belül különböző rendszerfejlesztési folyamatokat lehessen összekombinálni, ha ezeknek az alkalmazását a projektben fellépő kockázatok illetve azok kezelése indokolja, ezen módon a vízesés modell, az inkrementális, az evolúciós prototípus fejlesztés és egyéb más fejlesztési eljárások illesztése is szóba jöhet. Egy CommonKADS szerint végrehajtott fejlesztési projekt az irányítási és fejlesztési tevékenységek, ismétlődő, iteratív ciklusaiból áll. Az (ábra 2, ábra 3) érzékelteti az

életciklus spirált, az irányítási fejlesztési lépéseket, a modellek kialakításának és kifejlesztésének fázisait. A legfelső szintű spirál a teljes projekt előrehaladásának, ütemének megjelenítése, amely egy absztrakt képet ad a projekt lefolyásról. A spirál modell valójában a projekt résztvevői közötti kommunikáció eszköze, egyrészt az életciklus modell alap fogalmainak bemutatására szolgál, másrészt a projekt előrehaladását lehet a projekt irányító testülete számára megjeleníteni. A projekt irányító testületének jól meghatározott szerepe van a projekt résztvevői közötti kommunikáció megvalósításában, ezt az irányítási ciklus a részleteiben is tartalmazza; a projekt irányító testület áll a projektben érdekelt felekből, beleértve a megrendelőt, a végfelhasználót, a minőségirányítás, a fejlesztési csoport képviselőjét és a projektvezetőjét.

2.3 A projekt irányítási ciklus A projekt irányítási ciklus tevékenységeit (ábra 3) a ‘Ciklus ‘ érzékelteti, ezek a lépés halmazok foglalkoznak az ismeretbázisú rendszerek fejlesztésének irányításával. Ez a fejlesztés a CommonKADS-ban leírt modellek részletes kidolgozásán keresztül valósul meg, ezek azok a modellek, amelyek az ismeretbázisú rendszerek kialakításához szükséges nagyon fontos információkat tartalmazzák.

Ciklus 1

Ciklus 2

Ciklus 3

Ciklus 4

Szervezeti Feladat Szakértelem Kommunikáció Ágens Tervezés

ábra 3. A CommonKADS életciklusának elemei A CommonKADS modellek kidolgozása számtalan fejlesztési állapoton keresztül történik. A projektvezető felelőssége az, hogy projekt előrehaladásának átfogó elemzése alapján megtervezze, hogy mely modellekre van szükség (a feladat, tevékenység hierarchikus felépítéséből levezetve), a modellek kidolgozását elindítsa, majd nyomon kövesse azok fejlesztési állapotait. A CommonKADS projekt irányítási ciklusa több ismételten visszatérő tevékenységet tartalmaz. Egy ciklus négy fő tevékenység kategóriából áll, ezeket a spirál modell negyedeinek vagy kvadránsainak nevezik: • Szemle: A projekt pillanatnyi állapotának kiértékelése, a projekt globális célkitűzéseinek átértékelése, és a következő fejlesztési ciklus céljainak és feladatainak

meghatározása. A pontosított célok teljesítéséhez vezető utat az igényelt modellek állapotai és az igényelt termékek formájában fogalmazzák meg. • Kockázatelemzés: Azon kockázatok elemzése, amelyek a projekt sikertelen befejeződéséhez vezethetnek, a ciklus vagy a projekt egésze céljainak el nem érését eredményezhetik. A kockázat elemzés kimenetele a kijelölt modellek, termékek és azok állapotainak, rangsorának, egymásutániságának meghatározása. • Tervezés: meg kell tervezni azokat a tevékenységeket, a hozzájuk szükséges időt és erőforrásokat, amelyek a megjelölt modellek valamint további termékek, azok előírt állapotának előállításához szükségesek, továbbá az átadás / átvételi eljárás keretében alakalmayandó elfogadási kritériumok kifejlesztése. • Nyomon követés: azt jelenti, hogy a modellek valamint a termékek állapotainak alakulását követi nyomon úgy, ahogy azt a fejlesztő csoport előállítja, továbbá a termékek elfogadhatóságának, átvehetőségének elemzését és annak vizsgálatát, hogy a következő ciklusban várható előrehaladás milyen mértékű lehet a jelenlegi eredmények fényében. Ez a négy fő tevékenység további tizennégy résztevékenységre bontható, azonban azt hangsúlyozni kell, hogy ezek csupán a projektvezető számára szóló útmutatások, nem pontosan előírt tevékenység sorozatok sem az egymásutániságuk értelmében sem a ráfordítandó idő értelmében. Az a fontos, hogy az életciklus modell alapelveit és a kvadránsok sorrendjét betartsák.

3. A termékek 3.1 A szakértelem modellje 3.1.1 Miért van szükség a szakértelem modelljére A szakértelem modellezésének a célja az, hogy a probléma megoldáshoz szükséges ismereteket írja le, modellezze, például gépkocsi hiba diagnosztika, kémiai vegyület összeállítás, hitel kártya tranzakciókkal kapcsolatos csalások felderítése lehetnek ilyen szakterületek. Ezért először azt a kérdést kell megválaszolni, hogy mit értünk valójában probléma megoldás alatt. Probléma megoldás biztosan nem azt jelenti, hogy véletlenszerűen próbálkozik valaki addig, amíg végül a megoldást meg nem találja. Egy ésszerűnek hangzó meghatározást a következő elv tartalmaz: Az ismeret alkalmazás elve: A valóságban eredményes probléma megoldási eljárásnak az adott szakterület vagy feladat specifikus ismeretek (tudás) birtokában levő ágens racionális vagy legalábbis racionalizálható módon történő ismeret alkalmazását tekintjük. A probléma megoldási eljárás működő informatikai egységgé alakítása során, az ismeret tervezési (mérnökségi) feladatot (knowledge engineering) hagyományosan úgy fogták fel, mint a szakértőtől az ismeretek kinyerését, majd ezeknek az ismereteknek olyan számítástechnikai formára alakítását, amely aztán már emészthető a számítógép számára. Ez a megközelítés azokban a gyors alkalmazás fejlesztési eljárásokban tükröződött vissza, amelyek szabály alapú program fejlesztő környezeteket, keretrendszereket használták. Minthogy ez a megközelítés számtalan kérdést és problémát vetett fel, felmerül az, hogy vajon mi volna, mi lehetne egy mélyebb, alaposabb megértése az isme-

retbázisú rendszerek tervezése során alkalmazott ismeret tervezési folyamatnak. A CommonKADS módszertan a következő választ adja: A modell alkotás elve: Az ismeretbázisú rendszerek fejlesztését úgy lehet felfogni mint olyan modellek elkészítésének folyamatát, amelyek a probléma megoldási eljárást írják le. Maga az ismeretbázisú rendszer ezeknek a modelleknek a számítógéppel megvalósított informatikai megjelenése. A CommonKADS módszertan központi modellje a szakértelem modell, amely annak az ágensnek a probléma megoldási eljárását ragadja meg, aki a szakterület ismereteit, tudását egy bizonyos feladat végrehajtása közben alkalmazza. Ezen elv első részének alkalmazása vezet a CommonKADS azon hat modelljének kialakításához, amelyeket továbbiakban majd tárgyalni fogunk. Az elv második része azt állítja, hogy a szakértelem működőképes számítógép modelljének megalkotása, — a szakértelem operacionalizálása — többé nem egy felfedezési, ismeret előbányászási eljárásnak tekintendő, hanem egy modellezési folyamatnak. Ez természetesen további kérdésekhez vezet, nevezetesen mi az az absztrakciós szint, amely illeszkedik a szakértelem modellezési igényekhez. Newell (1982-ben) megpróbálta az ismeret (tudás) és a reprezentáció körül kialakult terminológiai zavart valahogy feloldani. Az ő meghatározása szerint a reprezentáció “a szimbólumok olyan rendszere, amely az ismeretek egy halmazát kódolja”, majd ezt azzal folytatta, amit azóta az ismeret szintek hipotézisének hívnak, azaz “Létezik egy olyan, határozottan elkülöníthető számítógép rendszeren belüli ábrázolási, informatikai szint, amely közvetlenül a szimbólumok szintje fölött helyezkedik el, és amelyet az ismeretek, a tudás mint (információhordozó) közeg, médium jellemez, valamint a probléma megoldási eljárás racionalitás elve”. A szimbólum és az ismeret közötti szint különbséget a klasszikus közlekedési jelző lámpa szemantikájának példájával lehet érzékeltetni (zöld - mehet, piros - állj, indulj, amikor sárga követi a pirost, állj meg, amikor sárgát piros követi): a különböző színek reprezentálhatók a “piros”, “zöld” és “sárga” szimbólumokkal, jelsorozatokkal, vagy akár az “1”, “2”, “3” szimbólumokkal, vagy bármi egyébbel. A közlekedési szabályok leírhatók elsőrendű predikátum kalkulussal, logikával, vagy a megszorításokat, peremfeltételeket (constraint logic programming) felhasználó programozási paradigmával, vagy akár az objektum-orientált programozási stílussal. Vegyük észre, hogy a közlekedési lámpára vonatkozó ismereteink egyáltalán nem változtak bármilyen reprezentációs formát választottunk a szimbólumok szintjén. Egy ágenst az ismeretek szintjén úgy írhatunk le, mint egy olyan valamit, aminek céljai vannak, potenciálisan végrehajtható tevékenységei, és ismeretei, tudása. Probléma megoldási eljárása, ‘viselkedése’ (behaviour) a racionalitás elve alapján jósolható meg: “ Ha egy ágensnek birtokában van az az ismeret, hogy egyik tevékenysége az egyik cél megvalósításához, eléréséhez vezet, akkor az ágens ezt a tevékenységet fogja választani.” Az ismeret szint és a racionalitás elvének előbbi meghatározására támaszkodva, meg lehet adni a választ arra a kérdésre, hogy mi az a szakértelem modellezésének absztrakciós szintje: Az ismeret szint elve: A CommonKADS módszertanban, az ismeretek szintje az a modellezési szint, ami az ismeret-bázisú rendszerek feladat

megoldási képességének, hatókörének (kompetenciájának) megfelel. Ez a probléma megoldási eljárás fogalmi szintű, koncepcionális leírását igényli, ami független a reprezentációra és a megvalósítási módokra vonatkozó döntésektől. Newell ismeret és ágens felfogása túl durva ahhoz, hogy az ismeretek modellezésére eredményesen fel lehessen használni. Egyáltalán nem ad útmutatást arra, hogy egy intelligens ágenset milyen módon lehet leírni az ismeret szintű elemek segítségével; erre a következő elv kínál megoldást: A szerep behatárolás elve (az ismereté): Egy intelligens ágens, amelyik egy bizonyos feladat megoldásával kerül szembe, úgy modellezhető mint akinek az ismereteire egy bizonyos struktúrát kényszerítenek olymódon, hogy ezek a struktúra elemek a probléma megoldási eljárás egészén belül különböző, specializált és korlátozott szerepet játszanak. A szerep behatárolás elvét eredetileg McDermott dolgozta ki, abban az értelemben, hogy egy ágens az ismereteinek csak azt a részét aktiválja, amely segíti az éppen megoldandó probléma megoldásában. Például egy orvosi adat absztrakció végrehajtásakor (39° Celsius → láz) csak azokat az ismereteket használja, amelyek az adat absztrakcióhoz szükségesek és nem használja azokat, amelyek a betegség leküzdéséhez szükségesek. A megkülönböztetett racionalitás elve: A racionalitás elvét tovább kell specializálni azért, hogy magyarázatot adjon arra, hogy az ágens milyen módon strukturálja az ismereteit, amikor egy olyan feladat megoldásához lát hozzá, amelynek pragmatikai és episztemológiai (ismeretelméleti) jellemzői adottak. Az ismeretek pillanatnyi szerepének behatárolása és strukturálása korlátain belül, a racionalitás elvének további specializálására van szükség azért, hogy magyarázatra leljünk, hogy a célokat milyen módon sikerült elérni az ismeretek erre alkalmas részének alkalmazásával. Ez az elv kiterjeszti a Newell által definiált racionalitás elvét (lsd. fentebb). Annak eldöntéséhez, hogy egy bizonyos tevékenység egyik céljának eléréséhez vezet, az ágensnek szükségtelen végig keresnie a teljes ismeret halmazát. Az adott helyzet jellegzetességeit használja arra, hogy eredményes döntéseket hozzon, mégpedig úgy, hogy a ezeket a jellemzőket használja az ismeretek strukturálásának módjának, az alkalmas ismeret elemek megfelelő konfigurációjának megtalálására. Vegyük azt a tevékenységet, amely az ágens céljának eléréséhez vezet, ehhez még szüksége van arra az ismeretre is, hogy milyen módon kell ezt alkalmazni, vagyis a helyzet specifikus ismeretek és ezek irányított alkalmazásának kézben tartása az adott helyzetben szükséges. Két példa: (a) az adat absztrakciós lépés bevezetése azért racionális, mert az adatok közti keresés terét lehet csökkenteni, ez egy példa az ismeretek konfigurálására, (b) egy beteg szimptómáinak megmagyarázására a heurisztikus osztályozás sémáját (heuristics classification scheme) lehet használni, ez az ismeretek alkalmas strukturálására vonatkozó példa egy specifikus helyzetben. Annak észrevétele, hogy az ismeretek különböző részei különböző szerepet játszanak a probléma megoldási eljárásban, lehetővé teszi azt, hogy különbséget tegyünk az ismeretek típusai között. Az általánosan elfogadott megkülönböztetés: a szakértelem ismeretei és az alkalmazásá-

nak irányítási, vezérlési ismerete. A CommonKADS még finomabb megkülönböztetést ad meg: Az ismeretek típusba sorolásának elve: Ez az elv három ismeret típust különböztet meg: a szakterületre, a feladatra, és logikai következtetések levonásának mikéntjére vonatkozó ismereteket. Ezeken a főbb a kategóriákon belül további általános ismeret típusok különböztethetőek meg. A szakterület (a szakértelem, a terület szakértőinek) ismeretei a terület fogalmai, a fogalmak jellemzői, tulajdonságai alapján ragadhatók meg, továbbá a fogalmak szerkezete és a közöttük fennálló kapcsolatok alapján, ez a fogalom készlet megadja az adott alkalmazási terület fogalmi szótárát. A feladatokra vonatkozó ismeretek az ágensek céljait és a célok elérése érdekében kifejtendő tevékenységeket fogja meg, a feladat részekre bontásán és a részfeladatokra vonatkozó vezérlési struktúra megadásán keresztül. A logikai következtetésekre vonatkozó ismeretek a szakterület ismereteinek a feladatok végrehajtása közbeni felhasználását írja le kis következtetési lépéseken keresztül. Az ismeretek típusainak megkülönböztetése után a következő kérdés az, hogy ezek az ismeret típusok hogyan viszonyulnak egymáshoz. Az ismeretbázisú rendszerek tervezése területén több válasz is létezik erre a kérdésre: A KADS-I módszertan azt posztulálta, hogy a szakterület ismeretei a feladat megoldásában történő felhasználástól teljesen függetlenül adhatók meg, míg Chandrasekaran [Chandrasekaran86] általános feladat modellje (generic task) azonban olyan szétválaszthatatlan egységként kezeli ezeket az ismereteket, amelyek értelmesen nem választhatók szét. A gyakorlati tapasztalatok azt mutatták azonban, hogy egyik elméleti megközelítés sem helyes teljesen, ez vezet a következőhöz: A viszonylagos kölcsönhatás hipotézise: Egy jó ismeret modellezési módszertan át tudja fogni a szakterület és a feladatra vonatkozó ismeretek közötti gyenge kölcsönhatástól az erősig terjedő teljes kontinuumot. Ennek a hipotézisnek a következménye az, hogy a CommonKADS nyitott arra, hogy akár egyetlen egy ismeret típus általánosított modellezési komponenseit akár a különböző ismeret típusokat lefedő általános feladat modelleket is be tudja fogadni a szakértelmet modellező könyvtárba.

A probléma megoldási eljárás megvalósítása

A modell alkotás elve

kölcsönhatás

Az ismeretek típusba sorolásának elve

Részletek megadása

Az ismeret alkalmazás elve A probléma megoldási eljárás leírása

A viszonylagos kölcsönhatás hipotézise

részletek megadása

A megkülönböztetett racionalitás elve

adaptáció

Az ismeret szint elve kiterjesztés

A szerep behatárolás elve

szerint

Ábra 4. A CommonKADS módszertanban a szakértelem modellezéséhez felhasznált elvek összefüggése Az ábra (ábra 4) azokat az elveket és azok összefüggéseit próbálja érzékeltetni, amelyeket a CommonKADS módszertanban a szakértelem modellezésre használnak fel. 3.1.2 A szakértelem modellezésének leírása A szakértelem a probléma megoldási és az alkalmazási területre vonatkozó ismeretekből áll össze (ábra 5). Az előbbi a probléma megoldó módszerekről valamint a modellezési stratégiákról szól, vagyis mikor és melyik probléma megoldó módszert kell alkalmazni. Az alkalmazási területre vonatkozó ismereteken belül három kategóriát különböztetnek meg: • szakterület ismeretei (domain knowledge) jelzik azokat az ismereteket, amelyek fontosak, lényegesek a szóban forgó rendszerre vonatkozóan (akár fizikai rendszerről van szó akár nem), és amelyik az adott alkalmazás tárgyaként jelenik meg, mondjuk például egy gép. Az adott szakterületet a fogalmai és a fogalmak tulajdonságai révén próbálja meg megragadni, továbbá az ismeretek szerkezetén és az ismeret elemek között fennálló kapcsolatokon keresztül. Ezáltal létrehozza az alkalmazási terület fogalom szótárát; • logikai következtetésekre (inference knowledge) vonatkozó ismeretek azokat az ismereteket jelzik, amelyek a következtetési eljárásban, az érvelésben használhatók fel. A feladat elvégzése során végrehajtott elemi következtetési lépéseket ( a logikai következtetéseket, ‘inference’) írja le úgy, hogy milyen módon használódnak fel a szakterület ismeretei ezen lépések alatt; • a feladatra vonatkozó ismeretek (task knowledge) egy ágens céljait és a célok eléréséhez felhasználandó tevékenységeket próbálják megfogni olymódon, hogy a feladatot részekre bontják, és megadják a részfeladatok fölötti vezérlési szerkezetet.

Probléma megoldás ismeretei

Probléma megoldó módszerek

Modellezés stratégiai ismeretek

Feladatra vonatkozó ismeretek Logikai következtetésre vonatkozó ismeretek Szakterület ismeretei Az alkalmazásra vonatkozó ismeretek

Ábra 5. A szakértelem modelljének szerkezete felül-nézetből

Noha az általános szoftver tervezési elvekben járatosak számára ezek a megkülönböztetések ismerősnek tűnhetnek nevezetesen az adatmodell, az időfüggő — esemény vagy vezérlés szempontú — modell és a funkcionális modell, azonban vannak bizonyos különbségek: • Az adatmodellezéssel szemben, a szakterület ismeretei nemcsak az adatokról és a köztük fennálló kapcsolatokról szólnak, hanem egy sokkal gazdagabb leírási módot jelentenek, amely nemcsak az adatokról szóló ismereteket fejezi ki, hanem azt is, hogy milyen módon lehet új ismereteket levezetni; • A feladatokra vonatkozó ismeretek kognitív jellegűek (milyen célt és azt hogyan kellene elérni) és nem az idő függő, vezérlési szemléletnek felel

meg, vagyis mikor, mit kell tenni; • A következtetésekre illetve azok levonására vonatkozó ismeretek az adatok illetve még pontosabban az ismeretek között fennálló összefüggések kifejezésére szolgálnak, és nem az adatfolyamok kifejezésére mint az a rendszerek funkcionális ábrázolásában szokásos. 3.1.3 Szakterület ismereteinek ábrázolása A szakterület ismeretei jelzik azokat az ismereteket, amelyek fontosak, lényegesek a szóban forgó rendszerre vonatkozóan (akár fizikai rendszerről van szó akár nem), és amelyik az adott alkalmazás tárgyaként jelenik meg, mondjuk például egy gép. Az adott szakterületet a fogalmai és a fogalmak tulajdonságai révén, továbbá az ismeretek szerkezetén és az ismeret elemek között fennálló kapcsolatokon keresztül próbálja meg megragadni. Ezáltal létrehozza az alkalmazási terület fogalom szótárát. A szakterület ismeretei a következő elemekből állnak: • a szakterület ontológiájából (domain ontology), amely a nevekből (kifejezésekből, terminológia elemekből) és a típusok meghatározásából áll, ezen a módon megadja a szakterület kifejezés szótárát; • a szakterület modelljéből (domain model), amely az állítások egy olyan koherens halmaza, amely a szakterületet egy bizonyos nézőpontból írja le a szakterület ontológiájában megadott fogalom szótár felhasználásával, • a modell ontológiájából (model ontology), amely azokat a neveket adja meg, amelyek a modellen kívülről is elérhetők, láthatók; például a következtetések elvégzésekor a következtetések levonásának módját leíró ismeretek használják. 3.1.4 A szakterület ontológiája A szakterület ontológiája azt a fogalom szótárat adja meg, amelyet a probléma megoldó eljárások leírására lehet használni. A következő elemek meghatározásaiból épül fel: • Fogalmak (concepts), amelyek a szakterület objektumainak osztályait jelenítik meg, A sajátosságaik (properties) révén írják le őket; ezeknek a sajátosságoknak

megengedett értéktartományaik vannak, esetleg alapértelmezésként feltételezett értékekkel (default value). A fogalmakat olyan fogalmi hierarchiába lehet elrendezni (taxonomy), amely visszatükrözi a fogalmak sajátosságai közötti öröklődési viszonyokat. Ezért nagyon sok hasonlóságot mutatnak a keretek (frames) és az objektum-orientált megközelítés objektumaihoz. Autó alkatrész • Példányok Állapot változó: univerzális észlelhető: univerzális (instances), a fogalmak olyan megnevezhető, egyedi pélÜzemanyag szállító motor üzemanyagtartály önindító rendszer Üa. állapot: dányai, amelyek saállapot: állapot: feszültség: {van gáz, nincs gáz} {üres, nem-üres} {elzáródott, nem} {van, nincs} (Állapot változó) (Állapot változó) (Állapot változó)} (Állapot változó) játosságainak egyedi értékeik vannak. Műszerfal Önindító-áramköre • Tulajdonságok, attgyertya akkumulátor Üzemanyag jelző: biztosíték: jelző értéke {rendben, kiégett} vizsgálat: állapot: (észlelhető) (Állapot változó) ribútumok {gyenge, normális} {száraz, nedves} Akku. jelző biztosíték vizsgálat: (Állapot változó) (észlelhető) jelző értéke {rendben, vezeték (attributes), tulaj(észlelhető)) szakadás} (észlelhető) donképpen olyan fojelenség galmak tömör jelölésére alkalmazott röpanasz észlelhető -> Boolean vidítésnek tekintheAutó alkatrész tők, amelyeknek csak motor motor egyetlen egy sajátosmegáll nem indul Állapot változó ságuk van. Az attriállapot bútumokat általában az ismeret-bázisú panasz van rendszerek dinamiállapot ok jelenség jelenség állapot kusan változó részében (a memória Ábra 6. Egy gépkocsi diagnosztikai feladatra a szaktemunkaterületében) rület ontológiájának konstrukciói használják tipikusan, míg a szakértelem modellje az ismeret-bázisú rendszerek statikus, állandónak tekinthető részét írják le. • Kifejezések (expressions) , a majdnem minden szakterületen előforduló szabályok feltételeinek szemantikáját, tartalmát írják le. A kifejezések akár példányok, fogalmak vagy akár attribútumok sajátosságait kapcsolják hozzá egy konkrét értékhez valamilyen logikai műveleten (boolean operator) keresztül (pl. egyenlő, =, kisebb, nagyobb, stb.). • Kapcsolatok (relations), bármelyik fentebb említett elemet, konstrukciót egy másik tetszőleges elemmel kapcsolhatják össze. A kapcsolatok lehetnek binárisak, ternárisak, n-árisak (n≥3), azaz két, három, vagy n db konstrukciót köthetnek egyszerre össze, továbbá a matematikai értelemben vett relációk tulajdonságainak megfelelően, lehetnek tranzítiv, szimmetrikus, reflexív kapcsolatok. • Értéktartományok (value sets), vagy a klasszikus, a programozási nyelvekből jól ismert adattípusoknak felelnek meg — mint például az INTEGER, STRING — vagy ezeknek az adattípusoknak az intervallumairól, esetleg tetszőleges kombinációik véges halmazairól lehet szó. • Halmazok (sets), ebben a fentebbi listában szereplő tetszőleges konstrukció gyűjteményről lehet szó, azonban egy halmaz elemeinek mind ugyanolyan típusúnak Hatást fejt ki

okoz

okoz

Hatást fejt ki

kell lennie. Ezek az elemek lehetnek mind valamilyen fentebbi konstrukcióhoz tartozóak, vagy mindegyikük kapcsolat, stb. Az ábra egy (ábra 6) példát mutat egy gépkocsi diagnosztikai alkalmazás szakterület ontológiájának létrehozásakor használt konstrukciókra a CommonKADS módszertannak megfelelően. Ebben a példában a gépkocsi több alkotó részét is egy olyan sajátossággal írták le, amelyet a fölöttes fogalom, az autó alkatrész észlelhető sajátossága specializációjaként határoztak meg, ilyen például a gyertya vizsgálat sajátosság, amely csak két értéket vehet fel nevezetesen száraz, vagy nedves lehet. Ezenkívül két kifejezést definiáltak az egyiket jelenségnek, a másikat állapotnak nevezték el. A jelenség az autó alkatrész észlelhető sajátosságát, illetve ennek valamelyik specializációját használja, míg az állapot pedig az autó alkatrész állapot változó sajátosságát illetve ennek valamelyik specializációját használja. Két attribútumot ( tulajdonságot) definiáltak, nevezetesen a motor nem indul illetve a motor megáll tulajdonságokat mint a panasz logikai (Bool) tulajdonság specializációit. Két bináris kapcsolata szerepel ennek a szakterületnek, nevezetesen a van jelenség, amely az állapotot — amely viszont mint a jelenséget kiváltó ok szerepel és ezáltal a jelenséget kiváltó hatásként jelenik meg — kapcsolja a jelenséghez. Továbbá az ok a másik kapcsolat, amelyik az állapotot — amely mint a panaszt és az állapotot okozó szerepel — kapcsolja a panaszhoz és az állapothoz, és ebben a kapcsolatban, a kapcsolat ezen az oldalán a hatást kifejtőként jelenik meg, vagyis ez az az ok, amelyik a panaszt és az állapotot kiváltja. 3.1.5 A szakterület modelljei A szakterület modellje olyan állításokból áll össze, amely az adott terület, koherens, összehangolt nézőpontját testesítik meg. A szakterület modellje két részből áll: • Az első részben, az összes fogalmat, attribútumot, példányt, halmazt, vagyis az összes lehetséges struktúrát, a kapcsolatok összes elemét, vagyis az aktuális ismereteket, tudást felsorolás szerűen rögzítik; • A második részben, az axiómákat, a sajátosságokat, a szöveges magyarázatokat és bármi egyéb olyan további információt, amely lényeges lehet az adott szakterületre írják le. A szakterület modelljeit tehát az első olyan kísérletnek lehet tekinteni, amelyik az ismeretbázis ésszerű felosztására, particionálására irányul, tartalmazza a teljes ismeret halmazt és információt, amely fontos az alkalmazási területről alkotott nézet szempontjából.

önindító biztosíték = kiégett

akkumulátor üzemanyagtartály feszültség = alacsony állapot = üres

önindító feszültség = nincs

műszerfal Akku. jelző = nulla

motor üa. állapota = nincs gáz

üa. szállító rendszer állapot = elzáródott

műszerfal Üzemanyagjelző = nulla

önindító biztosíték vizsgálat =vezeték megszakadva

ok van jelenség

Gyertya fej vizsgálat = száraz

motor nem indul = igaz Kapcsolat példányai Kapcsolat példányai

motor megáll = igaz

Ábra 7. A gépkocsi diagnosztikai feladat szakterület modellje Az ábra szemlélteti (ábra 7) a két bináris kapcsolatot, nevezetesen az okot és a van jelenséget, pl. az önindító feszültség = nincs az ok kapcsolatnak egyik eleme, míg a motor megáll = igaz pedig egy másik példánya, van jelenség egyik példánya pedig a műszerfal akkumulátor jelző = nulla. Ha a szakterület modelljét és összevetjük a szakterület ontológiájával, akkor megfigyelhető, hogy a kapcsolatok elemei helyes típusúak. 3.1.6 A modell ontológiája A modell ontológia a külső világ számára ad egy olyan kapcsolódási felületet, amelyen keresztül a szakterület ismeretei elérhetőek, és ebben a formában egy fajta meta ismeret halmazt testesítenek meg. Valójában egyszerűen a szakterület összes kifejezéseit, a szakterület ontológiája konstrukcióinak és a szakterület modelljeinek neveit sorolja fel, azokat, amelyekre a következtetések levonásához szükséges ismeretekhez szükség van. Modell ontológiája

panasz

állapot

észlelhető

jelenség

ok

van jelenség

Ábra 8. A gépkocsi diagnosztika feladat modell ontológiája Ezek után a logikai következtetések módjának leírásakor a következő kifejezések alkalmazhatók: panasz, állapot, észlelhető, jelenség, ok és van jelenség. 3.1.7 Logikai következtetések levonásakor alkalmazott ismeretek A logikai következtetések levonásakor alkalmazott ismeretetek arról szólnak, hogy a következtetési folyamatban hogyan lehet használni a szakterület ismereteit. A szakterület ismereteinek használatát írja le azokban az elemi következtetési lépésekben, amelyek egy bizonyos feladat megoldásához szükségesek. A logikai következtetésekre vonatkozó ismeretek azt a célt szolgálják, hogy a feladatokra vonatkozó ismeretek és a szakterület ismeretei közötti összekötő kapocsként jelenjenek meg.

A logikai következtetések végrehajtásához szükséges ismeretek leírásához a következő konstrukciókra van szükség: • A logikai következtetések olyan funkcionális elemek, amelyek azokat az elemi lépéseket adják meg, amelyek a szakterület jól meghatározott részének ismeretein hajtanak végre bizonyos logikai műveleteket, vagyis azokon a kifejezéseken, amelyeket a szakterület leírása során a modell ontológiájában soroltak fel. • A szakterület ismereteinek elemei a logikai következtetések végrehajtása során különböző szerepeket játszathatnak el; például az a hiba állapot, amely a lyuk az üzemanyagtartályon -nak felel meg, lehet akár egy hipotézis, amelyet le kell ellenőrizni, hogy igaz vagy hamis-e, akár egy végső diagnózis, abban az esetben ha igaznak bizonyul az ellenőrzés után. • Statikus szerepek azokra a szakterületbeli ismeretekre utalnak, amelyeket a következtetési eljárásban felhasználnak, azonban ez a logikai eljárás nem gyakorol semmiféle hatást rájuk. Ilymódon segítik a következtetési eljárást. Erre a támogatást nyújtó tudásra példa a jelenségről és az okról (okozatról) szóló szakterületi ismeretek a gépkocsi diagnosztika példában. • Dinamikus szerepek azokra a szakterületbeli ismeretekre utalnak, amelyeket a következtetési eljárás módosíthat, manipulálhat. Azaz a logikai következtetések bemenő és kimenő elemeit jelölik. A megjelölt szakterületi ismereteket fel kell sorolni a modell ontológiájában. • A bemeneti, kimeneti és a statikus ismeret szerepek alapján összekapcsolva a logikai következtetéseket megkapjuk a logikai következtetések szerkezetét, esetleg a szakterület egészére vonatkozóan is. A logikai következtetések specifikációja két részből áll: • Mindegyik következtetésnek (inference) egyedi neve van, amely valamilyen módon tükrözi azoknak a lépéseknek a célját, amely az egész következtetési eljárás hátterében meghúzódik. Például, a döntés-hozatal kifejezi a következtetés célját a kiválaszt pedig nem. • A művelet típusa (operation type) azt jelöli, hogy a következtetést milyen módszerrel hajtja végre. Például a döntés-hozatal eljárás elvégezhető akár a kiválasztás-véletlenszerűen vagy a kiválasztás-sorban műveletek szerint. • A bemeneti szerepek (input roles) azokat a szakterületi ismereteket jelölik, amelyek a következtetési eljárásokhoz mint bemenetek szükségesek, vagyis melyek azok az ismeretek a szakterületből, amelyek a bemenet szerepét játsszák el a következtetés számára. • A kimeneti szerepek (output roles) azokat a szakterületi ismereteket jelölik, amelyek a kimenet szerepét játsszák el a következtetés számára. • A statikus szerepek (static roles) azokat a szakterületi ismereteket jelölik, amelyek következtetés elvégzését támogatják, benne csak passzívan vesznek részt. • A specifikációs rész (specification) egy szöveges vagy többé kevésbé formális leírása annak, hogy a bemeneti szerepek és a kimeneti szerepek, hogyan viszonyulnak egymáshoz. A következtetési lépések meghatározását adja meg. Meglehetősen szabatos és pontos leírásnak kell lennie azért, hogy egyértelműen leírja azt, hogy valójában minek is kell történnie. Minél pontosabb a specifikáció annál inkább fog a leendő specifikáció illeszkedni azokhoz az igényekhez, amit az ismereteknek ezen a szintjén megfogalmaztak. Az ábra (ábra 9) egy példával illusztrálja a fentebbieket, a következtetés és a következtetés szerkezetének leírását.

Vegyük észre, hogy a szerepek révén a következtetések specifikálásakor egyáltalán nem kell tudni a szakterület ismereteinek tartalmáról, csupán azt a kapcsolódási felületet (interface), amelyet a modell ontológiája nyújt. 3.1.8 A feladatra vonatkozó ismeretek Az ágens céljait próbálják megragadni a feladatra vonatkozó ismeretek (task knowledge), továbbá azokat a tevékenységeket, amelyek a célok eléréséhez szükségesek, és ezáltal a feladat részekre bontását és a részfeladatok vezérlési, irányítási módját is megadják. A feladatot egyrészt a feladat meghatározása, definíciója másrészt a feladat részletes leírása adja meg. A feladat meghatározása (task definition) a feladat céljait írja le a következő elemek segítségével: • A cél (goal) a feladat által elérendő célok szöveges leírását adja meg. • A feladat bemenete (input) nevek olyan halmazát jelenti, amelynek egyes elemeit szöveges magyarázatokkal látják el arról, hogy mi is a jelentése a neveknek.

lefed

következtetés Művelet típus:

Kapcsolat létrehozása;

Bemeneti szerep:

Kezdeti-panasz -> panasz;

Kimeneti szerep:

Hipotézis -> állapot;

Statikus szerep:

Lehetséges-ok -> okok ε oksági modell;

spec:

Egy hipotézis akkor fedi le a panaszokat, vagy néhány panaszt, ha létezik oksági kapcsolat, akár közvetlenül akár tranzítiv módon a hipotézis és a panasz között.

Formálisan:

("

h: hipotézis, c: Kezdeti-panasz: Lehetséges-ok (h, c) -> lefed (c, h)) AND

("

h,h': hipotézis, c: Kezdeti-panasz: Lehetséges-ok (h', c) AND Lehetséges-ok (h, h') -> lefed (c, h));

Kezdeti-panasz panasz

oksági modell

tény

lefed Kapcsolat létrehozása

okok

hipotézis

értékadás(jelenség)

megállapítás állapot

Kapcsolat létrehozása

Összhangban álló hipotézis

állapot

Szükséges feltételek Viselkedési modell

Ábra 9. A gépkocsi diagnosztikai feladat következtetése és annak szerkezete • A feladat kimenete (output) szintén nevek halmazát jelenti, szintén szöveges magyarázatokkal széljegyzetelve. • Az elhagyható, de megengedett feladat specifikáció (task specification) a bemenetek és a kimenetek közötti logikai kapcsolatot, összefüggéseket adja meg.

A feladat részletes leírása (task body) azt adja meg, hogy a célokat hogyan lehet elérni. A következő részekből áll: • A feladat típusa (task type) a következő lehet: összetett, transzfer, primitív ({composite, transfer, primitive}).Egy összetett feladatot a részfeladatokra bontása jellemez, egy transzfer feladat valamilyen kommunikációt tartalmaz és a további, pontosabb leírása a kommunikációs modellben történik, egy primitív feladat pedig olyan, amelyet egyetlen egy következtetéssel le lehet írni és ezért nincs szükség további részekre bontásra. feladat Gépkocsi diagnosztika; Feladat meghatározás Találj egy megoldást; cél bemenet: Kezdeti-panasz:

A panasz, amely a diagnosztikai eljárást indította Felhasználói-adatok: A felhasználó által szolgáltatott további adatok; kimenet: megoldás: A rendszer által előállított diagnózis; Feladat Találj egy magyarázatot a kezdeti panaszra, amelyet a felhasználó által szolgáltatott adatokból specifikáció: származtatott tények megerősítenek. Ha ilyen magyarázat nem lelhető fel, akkor a feladat egyszerűen sikertelenül fejeződik be. feladat részletes leírása összetett; típus: generálás, tesztelés; részfeladat: hipotézis: Egy tesztelendő lehetséges megoldás; Extra szerepek: Vezérlési struktúra: Gépkocsi diagnosztika ( c: Kezdeti-panasz + --> h: hipotézis) =

d:

Felhasználói-adatok

REPEAT generálás ( c: Kezdeti-panasz --> h: hipotézis) UNTIL tesztelés ( h: hipotézis + d: Felhasználói-adatok --> igaz ) RETURN ( h: hipotézis)

Gépkocsi diagnosztika

generálás

lefed

tesztelés

megállapít

Ábra 10 A gépkocsi diagnosztikai feladat specifikációjára és részfeladatokra bontására egy illusztrációs példa • A feladat felbontás (task decomposition) csak összetett és primitív feladatokra értelmezhető, mivel a részfeladatok neveit illetve a következtetés nevét, rá való hivatkozást adja meg. • Extra szerepek (additional roles) arra a célra szolgálnak, hogy a közbenső eredményeket ideiglenesen tárolják, és ezért csak az összetett feladatoknál jelennek meg. • A vezérlési struktúra (control structure) írja le azt a mechanizmust, amin keresztül a részfeladatok tevékenységét koordinálják a feladat végcéljának elérése végett. Ezt általában pszeudo kód formájában fogalmazzák meg, de bármilyen más formális leírási mód használható itt.

• Ha feladat részletes leírásában bármilyen feltételezéssel (assumption) élnek, vagy előfeltételek, peremfeltételek állnak fenn, akkor azt itt meg kell adni. A feladat részekre bontása a szakterület ismereteire korlátokat szabhat, amiket a későbbiekben figyelembe kell venni. Az ábrában (ábra 10) a gépkocsi diagnosztika feladatot összetett feladatként határozták meg, amelyet részfeladatokra bontottak, nevezetesen a generálás és tesztelés nevezetű részfeladatokra. Ezek mindegyike primitív feladatnak bizonyultak, azaz céljaik a megfelelő következtetések elvégzése után elérhetőek, nevezetesen a lefed illetőleg a megállapít következtetések végrehajtása után. 3.1.9 Probléma megoldási ismeretek A CommonKADS módszertanban a probléma megoldási ismereteket (problem solving knowledge) úgy fogják fel mint olyan ismereteket, amelyek az adott alkalmazás modellezésének mikéntjéhez, módjához szükségesek. Ez összhangban van a 3.1.1 fejezetben leírt modellezési elvvel. Ezek az ismeretek tehát arról szólnak, hogy hogyan szervezzék meg és kapcsolják össze egy alkalmazáshoz tartozó feladatokat, a következtetéseket és a szakterület ismereteit az adott alkalmazás által megoldandó problémák megoldása végett. A probléma megoldási ismeretek két különböző típusba sorolhatók: • A probléma megoldási módszerek (problem solving methods) felölelik azokat a lehetőségeket, amelyek segítségével a szakterületi, következtetési és a feladatra vonatkozó ismeretek összekapcsolhatók, együttműködésük megszervezhető. • A stratégiai ismeretek (strategic knowledge) azt az ismeret struktúrát testesítik meg, amely az adott problémához és az azt körülvevő környezethez illeszkedik. A stratégiai ismeretek tehát abban adnak tanácsot, hogy vajon melyik probléma megoldási módszert melyik probléma megoldására alkalmazzák. A probléma megoldási ismeretek nem jelentenek egy új ismeret kategóriát — a szakterületi, következtetési és a feladatra vonatkozó ismereteken kívül, hanem ezekre tulajdonképpen ortogonális (azaz más kategorizálási, osztályozási dimenziót jelent), valójában annak a döntési folyamatnak az ésszerűsítésére szolgál, amikor meg kell határozni, hogy az adott helyzetben melyik ismeretet — szakterületi, következtetési és a feladatra vonatkozó ismeretek közül — miért használják, mi a megfelelő és helyes választás és eljárás. Másrészt a probléma megoldási ismereteket azzal a három ismeret kategóriával is le lehet írni.

3.2 A feladat modell 3.2.1 A feladat modell célkitűzése A feladat modell célkitűzése az, hogy leírja a szervezet vagy szervezeti egység (osztály, főosztály, divízió, stb.) dinamikus mozgását, tevékenységét a feladatainak értelmében, ezek segítségével. A feladatot felfoghatjuk úgy, mint összhangban álló, koherens tevékenységek halmazát, amelyek az adott terület céljának elérése végett hajtanak végre. A feladat modell egy olyan keretet ad, amelyben a feladatok kiválasztott tulajdonságait, bizonyos a feladatra vonatkozó információkat lehet reprezentálni és valamilyen strukturált formában elrendezni. A feladat modellezés a következő dolgokra alkalmazható: • A jelenleg folyó tevékenységek elemzésének dokumentálására. • A leendő tevékenységek tervének leírására. • Az ismeret bázisú rendszer terjedelmének, kiterjedésének, határainak megállapítására. • A projekt megvalósíthatóságának elemzésére.

• A projekt végrehajtásában résztvevő szereplők kiválasztásához. • Az oktatási, képzési igények felméréséhez. • A szervezetben végzett munka hatékonyságának, minőségének és eredményességének kiértékelésére. 3.2.2 Ismertetése Mit nevezünk feladatnak? Egy feladat: tevékenységek egymással összhangban álló halmaza, amelyeket az adott terület célja elérése végett fejtenek ki. Tevékenységnek olyan cselekményeket nevezünk, amelyeket a valós világban végeznek el. Ugyanazt a tevékenységet különböző feladatokon belül is végre lehet hajtani, eltérő célok megvalósítása érdekében. Nagyon fontos, hogy a tevékenységet és a célt megkülönböztessük egymástól, például egy szög megütése egy kalapáccsal megfelelhet annak a célnak, hogy a szöget a fába beleverjük, de annak a célnak is, hogy valakinek a figyelmét magunkra vonjuk. A feladatot tehát még pontosabban a következőképpen fogalmazhatjuk meg: • van célja; • van határozott kezdete és vége; • viszonylag rövid idő alatt hajtják végre; • van mérhető végeredménye. A feladat valaki munkájának egy véges, önálló része. Egy részfeladat csak a főfeladaton belül értelmezhető helyesen. A feladat végrehajtását kezdeményező dolog általában felismerhető, az is, hogy a felelős a feladata elvégzéséért és ki nem az. A feladat végeredményének mérhetőnek kell lennie azért, hogy a feladat végrehajtásának sikerességét és korrektségét ki lehessen értékelni. A feladatot általában egy igével, vagy igéből képzett főnévvel lehet leírni. Mit tartalmaz a feladat modell? A feladat modell a feladatok hierarchikus részfeladatokra bontását tartalmazza, továbbá az egyes részfeladatok, a feladat leírását a sajátosságaik, jellemzőik értelmében. A hierarchikus feladat lebontás ábrázolását feladat diagramnak nevezik (ábra 11). A CommonKADS nem ösztönzi, nem is teszi kötelezővé ennek a diagramnak a használatát.

Feladat

részfeladat-1

részfeladat -2

részfeladat -21

részfeladat -3

részfeladat -4

részfeladat -22

részfeladat -41

Ábra 11. Egy példa feladat diagramra Az alább felsorolandó attribútum lista az egyes részfeladatok, a feladat leírására szolgál. Néhány attribútum megadása kötelező, ezeket aláhúzással jelöljük, másokat csak akkor kell használni ha az adott területen, problémánál fontosnak tűnnek.

A feladat modell alkotóelemei ismeretbázisú alrendszer

fő-/ al-

Tervezési modell Más alrendszerek

által megvalósított által megvalósított

rendelkezik Sajátosság

által végrehajtott

típus

Feladat

belül végzett

meghatározza

Ágens Környezet

következő kiszolgálja

megkívánt be & által megvalósított kimenet

által meghatározott

Ágens modell

szolgáltatja / kapja

Képesség része

Funkció

Tranzakció

SzM feladat Komponens

Szervezeti modell

Szakértelem modellje

specifikált

Információ elem Kommunikáció modell

Ábra 12 A feladat modell sablonja 1. Név: A feladat neve, amely egy igéből / igéből képzett főnévből áll valamint egy tárgyból (nyelvtani értelemben is). A feladat modellen belüli egyedinek kell lenni. 2. Cél: A feladat célja. 3. Bemenet: A feladaton kívül eső információk, amelyeket viszont a feladat felhasznál. Ezt a CommonKADS-ban a bemeneti komponensnek, alkotórésznek (input ingredient) hívják. Az információ forrását szintén meg kell adni. 4. Kimenet: A feladat által előállított információ, a CommonKADS-ban a kimeneti alkotórész (output ingredient), komponens. Az információ befogadóját is meg kell nevezni. 5. Előfeltételek: A környezetre vonatkozó korlátozások — de nem a bemenetek létének feltételezése — amiknek a feladat végrehajtása elütt már fenn kell állniuk. Például más feladatokat már megelőzően is el kellett végezni, vagy bizonyos vezetői döntéseket meg kellett már hozni. 6. Vezérlési struktúra: A részfeladatok irányításának leírása, ezt esetleg a következő két tulajdonság megadásával helyettesíteni. 7. Következő / megelőző feladat: A feladatot megelőző vagy követő feladat rögzítése abban az esetben ha ez felismerhető és azonosítható. 8. Végrehajtási gyakoriság: Milyen gyakran hajtják végre ezt a feladatot. A gyakoriságot meg lehet adni abszolút számokban (pl. egy hétre vonatkoztatva), vagy a bemeneti adatokhoz (pl. minden bemeneti elemhez), vagy a kimeneti információhoz viszonyítva (pl. x-szer bocsát ki kimenetet minden nap, y-szor pedig minden héten), vagy a főfeladat gyakoriságával egyezik meg. 9. Teljesítmény: A kimeneti információk megengedett minősége vagy a megengedett / engedélyezett befejezési idő. 10. Ágens: A feladat végrehajtója. Ez lehet egy szervezeti szerep, egy osztály, vagy egy rendszer illetve egy rendszer része. 11. Szakmai gyakorlat / képzettség / képesség: Szakmai gyakorlat, képzettség vagy képesség, ami feladat végrehajtáshoz megkívánt.

12. A részfeladatokra bontás típusa: A feladat és a részfeladatai közötti viszony típusát adják meg itt. A feladatokat részfeladatokra lehet osztani az idő dimenzió, a feladat által manipulált dolgok, objektumok szerkezete alapján, az egymástól függetlenül és önállóan létező részcélok alapján, a különböző ágensek szerint, vagy a tevékenységek sorrendje révén. 13. Környezet: A feladat végrehajtására vonatkozó formális korlátok mint például a törvények, szabványok, szakmai szabályok és előírások, stb. A környezetet a legjobb szakmai gyakorlatnak megfelelő normák és normatívák alapján lehet leírni, továbbá azoknak a korlátoknak az értelmében, amelyeket nem lehet megsérteni, ilyenek például a törvények, a biztonsági szabályok vagy a szervezeten belül elfogadott szabványok, előírások. 14. Sajátosság: Egy absztrakt leíró nyelvben megfogalmazott feladat jellemzők leírása (feature grammar). A feladat modell alkotórészeinek és a többi CommonKADS modell kapcsolatáról néhány megjegyzés: • A szervezeti modellben megtalálhatónak kell lennie a gyökér feladatnak, ami a feladat hierarchia tetején helyezkedik el. • Az ágens modellben leírt ágensekhez kapcsolt feladatoknak ott is meg kell jelenniük. • A feladat bemeneti és kimenő információi a komponensek értelmében adandók meg. • A kommunikációs modellben a feladat komponensei, információ alkotórészekként jelennek meg. • A különböző ágensek — akik a feladat fa levelein megjelölt tevékenységeket végzik — közötti komponens csere a kommunikációs modellbeli tranzakciók révén írandók le. • Az ismeretbázisú rendszerhez mint ágenshez kötött feladatok a szakértelem modelljében lesznek részletesebben kifejtve. • A tervezési modell fogja megmutatni azokat a megvalósítási részleteket, amelyek azokra a feladatokra vonatkoznak, amiket az ismeretbázisú rendszerhez mint ágenshez illetve egyéb más rendszerekhez mint ágensekhez kapcsolták.

3.3 A szervezeti modell 3.3.1 A szervezeti modell célja A szervezeti modell célja a szervezet tulajdonságainak, jellemzőinek megfogása. Négy fő célt ismerhetünk fel : • az ismeretbázisú rendszer alkalmazások számára ígéretes területek felismerése; • a potenciális ismeretbázisú rendszer alkalmazások hatásának elemzése; • a szervezet szellemi kapacitásának, képességeinek felmérése; • az ismeretbázisú rendszer bevezetése után előálló helyzet elemzése. 3.3.2 Ismertetés A szervezeti modell alkotórészeit az ábra (ábra 13) mutatja be, ezenkívül a CommonKADS többi a modelljeihez való kapcsolatot érzékelteti. A sablont a szervezeti modell egy ideiglenes, fogalmi szintű leírásának kellene tekinteni, amelynek az alkotóelemei kérdéseket, probléma felvetéseket indukálnak a szervezetről. Ezeknek a kérdéseknek a megválaszolása vezethet a szervezeti modell céljaiként megfogalmazottak eléréséhez.

A szervezeti modell alkotó elemei Ágens modell A jelenlegi probléma

hozzátartozik

Szervezetet körülvevő környezet

belül létezik

Problémák és lehetőségek

Ágens

felismerése által kiviteleződik

szerepe lehet

által megcélzott

szerepe lehet Megoldások

Alkalmazott

által támogatott

birtokolja által felhasznált

Ismeret / tudás Informatikai erőforrások által felhasznált

része

birtokol

megvalósul Funkció irányított

Szervezeti felépítés / hierarchia

Folyamat

származik

Hatalom

előírja kiszolgálja

végrehajtódik Feladat

Egyéb erőforrások

végrehajtódik

Feladat modell

Ábra 13. A szervezeti modell sablonja 3.3.2.1 Az egyes alkotórészek leírása • A szervezetet körülvevő környezet azokat a környezeti tényezőket jeleníti meg, amelyekben a szervezet működik, és amelyek az ismeret-bázisú rendszer által a szervezetre kifejtett hatást befolyásolják illetve az ismeret-bázisú technológia alkalmazásának valamilyen lehetőségét jelentik. • A problémák és lehetőségek egy olyan listát jelentenek, amely felsorolja a szervezet problémáit és igényeit, szükségleteit, amelyeket többé kevésbé sürgetőnek tekintenek és talán meg lehet oldani egy ismeret alapú rendszerrel. • A jelenlegi problémák azokat a problémákat és lehetőségeket képviselik, amelyeket a szervezet megkíván oldani és ezért eldöntötte, hogy bizonyos erőforrásokat erre a feladatra szán, erőfeszítéseket fog tenni ezeknek az elrendezésére; ezért ez az elkötelezettség a kiindulási pontja a szóban forgó projektnek. • A megoldások azokat a forgatókönyveket jelentik, amelyeket a jelenlegi problémák megoldására azért alakítottak ki vagy fognak létrehozni, hogy a kielégítsék a mostani igényeket. • A funkció azoknak a funkcióknak a tárháza, amelyek a szóban forgó szervezetben határozottan elkülöníthetők. • A folyamat azokra a szervezetet átfogó, szervezeti szintű munkafolyamatokra és / vagy ellenőrzési eljárásokra vonatkozik, amelyek a szervezet elsődleges tevékenységéhez, főtevékenységéhez tartoznak.

• A szervezeti felépítés / hierarchia a szervezet ‘topológiájára’ utal, amely a szervezet felosztását jelzi funkcionális vagy feladat központú szervezeti egységekre, vagy esetleg a szervezeti részeinek földrajzi szétszórtságát érzékelteti. • Az alkalmazott azokat a személyeket fedi le, akik valamilyen szerepet játszanak a szervezetben, de ebbe nem értendő a speciális ismeretek vagy hatalmi pozíciók birtoklása, mert azokat egy külön alkotórészben írják le. • Az ismeret / tudás annak az általános és a szervezeti hierarchia magas szintjén elhelyezkedő tudásnak és ismereteknek felel meg, amelyek a pillanatnyi a problémák meghatározásában segítenek és a jelenlegi problémák megoldhatóságának életképességét, a megoldások megvalósíthatóságára gyakorolnak hatást. • Az informatikai erőforrások a szervezet folyamatainak számítástechnikai, számítógépes, informatikai támogatottságát reprezentálják, ezek az elemek lehetnek akár logikai akár fizikai elemek. • Az egyéb erőforrások egy minden egyebet felölelő, magában foglaló kategória, amely olyan elemek leírását is tartalmazhatja mint pl. az irodai szobák nagysága, vagy bútorok, stb. • A hatalom annak a leírására szolgál, hogy szervezet működésében, működtetésében érdekelt felek között milyenek a hatalmi viszonyok, és ezek a jelenlegi problémák megoldhatóságát hogyan befolyásolják. 3.3.2.2 A modell alkotórészei közötti kapcsolat A szervezeti modell alkotórészei közötti kapcsolatok azt írják le, hogy a szervezet elemzés legfontosabb témakörei hogyan viszonyulnak egymáshoz és milyen újabb információk nyerhetők ki a szervezetre vonatkozóan, miután az egyes témaköröket külön-külön elemezték és az így nyert adatokat összeillesztették. A jelenlegi probléma a problémákhoz és lehetőségekhez tartozik. A jelenlegi probléma (vagy lehetőség), amelyik a szervezet pillanatnyi belső állapotának egy fajta értékelésén alapul, akár leírható valamilyen természetes nyelven vagy a szervezeti modell más egyéb alkotórészeinek felhasználásával. A jelenlegi probléma (vagy lehetőség) problémák és lehetőségek lista szerű felsorolásához tartozik, ezt a listát a szervezet tagjai segítségével állították össze, vagyis olyan személyek járultak hozzá a lista elemeinek a kialakításához, akik a szervezet működésében és működtetésében érdekeltek, az ő közreműködésükkel történt meg az egyes szervezeti problémák megfogalmazása, illetve a vizsgálati programba beemelendő lehetőségekről a döntés. Az összes probléma és lehetőség a szervezetbe és a szervezetet körülvevő környezetbe illesztve értelmezhető csak, nem elemezhetők vagy vizsgálhatók kiszakítva ebből a környezetből. A jelenlegi problémát valamelyik megoldással próbálják kezelni, erre időnként mint lehetséges forgatókönyvre is hivatkoznak. A megoldások közül néhányat kifejezetten támogatni fognak egyes emberek, ezek azok a személyek, akik bizonyos megoldásokat előnyben részesítenek és ezért hajlandók küzdeni, ezeket a nézeteiket határozottan képviselik. Nagyon fontos azt tudni, hogy az egyes megoldásokat képviselők mekkora hatalommal rendelkeznek a szervezetben, milyen a befolyásuk, mennyire tudják ezt érvényesíteni a támogatott megoldásokkal kapcsolatban, mivel ezek a mozzanatok döntően befolyásolják a megoldások megvalósíthatóságát. A megoldások megvalósíthatóságára a többi befolyásos személy véleménye is komoly hatást gyakorol, különösen azoké, akiknek a viszonya más az adott megoldáshoz, álláspontja különbözik a megoldást képviselőkétől, azt támogatóktól. A megoldásokhoz szükség van ágensekre, akik azt sikerre vive megvalósítják, kivitelezik.

Az alkalmazott (személy) lehet olyan ágens, aki a szervezeten belül olyan feladatokat hajt végre, amelyek vagy kapcsolatban vannak a jelenlegi problémákkal (lehetőségekkel) illetve a megoldásokkal vagy az előbbiek olyan hatásokat váltanak ki, amik érintik ezt a feladatot. Ezeknek a személyeknek a birtokában kell lennie azoknak az ismereteknek, tudásnak, amelyek feladataik végrehajtásához szükségesek, illetve ezt a tudást meg kell szerezniük azért, hogy ennek segítségével elláthassák a szervezet megfelelő funkciót. Az alkalmazottnak (személynek) a szervezeti felépítésben meghatározott helye van (beosztása, pozíciója, informális illetve formális), egy bizonyos csoporton belül vagy azzal együtt végzi a munkáját és vannak hivatalosan ráruházott felelősségei. Az alkalmazottnak (személynek) van bizonyos hatalma a szervezeten belül, amely részben a szervezeten belül elfoglalt helyéből adódik, és ez (részben) meghatározza azt is, hogy mekkora befolyást tud gyakorolni a szervezetre. Az ágensek lehetnek informatikai erőforrások is. Az ismeretbázisú rendszerek azokat az ismereteket alkalmazzák, amelyeket eredetileg az alkalmazottak birtokoltak. Az informatikai erőforrások a szervezeti folyamatokban kerülnek alkalmazásra; vannak olyan erőforrások, amelyeket a folyamat ‘elfogyaszt’, vannak olyanok, amelyek pedig újra felhasználhatók lesznek. Funkciók kétféle módon is kapcsolódhatnak a feladatokhoz: egy funkció több feladatot is meghatározhat, előírhatja a végrehajtásukat; egy feladat egy vagy több funkciót is kiszolgálhat. A funkciók a szervezeti struktúrához kapcsolódva jönnek létre, továbbá a szervezet elsődleges folyamataihoz (primary activities, processes), tevékenységeihez kapcsolódnak abban az értelemben, hogy a szervezeti folyamat leírásában a funkciók ütemezése és a funkciók közötti összefüggés megjelenik.

3.4 Tervezési modell 3.4.1 A tervezési modell célkitűzései A tervezési modell a rendszer architektúrájának specifikációját jelenti, valamint a megfelelő ábrázolási mód, és az illeszkedő informatikai, számítástechnikai leírási és egyéb eljárási, technikai módszerek kiválasztását, amelyek megfelelnek azoknak az információknak, amelyeket a CommonKADS modelljei tartalmaznak. A tervezési modell egy olyan keretet nyújt, amelyben: • az elemzést és a megvalósítás lépéseit határozottan el lehet választani; • a végtermék kielégítő minőségét a megfelelő minőségű, és a megvalósításhoz és az ismeretbázisú rendszer folyamatos karbantartásához használható dokumentáció előállításával lehet biztosítani; • a rendszer specifikációját, annak tartalmát és azt a hardver / szoftver platformot el kell különíteni, amelyen a rendszer megvalósítása meg fog történni; • figyelembe kell venni azokat a környezeti tényezőket, amelyeket a többi modellben eddig nem vizsgáltak (mint például a válasz és futási időre vonatkozó követelmények); • az egyes tervezési komponensek újra felhasználhatóságát kell számításba venni (például az olyan kész elemek felhasználhatóságát mint a falitábla [blackboard]); • az ágensek és a rendszer közötti olyan felület megtervezése, amely összhangban áll a teljes rendszerrel. Az ábra a tervezési modell szerepét érzékelteti az ismeretbázisú rendszerek készítése során (ábra 14). 3.4.2 A tervezési modell ismertetése A tervezési modell tartalmát a rendszer tervezése során hozott döntések adják, amiket három kategóriába lehet sorolni, és amiket azoknak a finomítási lépéseknek tekinthe-

tünk, amelyek a fogalmi modellnek a futtatható rendszerré való átalakítását eredményezik: • Alkalmazás tervezési alkotórész: a rendszer architektúra tervét jelenti, vagyis a rendszer felbontását részrendszerekre (ismeretbázisú rendszer, hagyományos informatikai rendszerek, a rendszerfelülete, adat és információcserét megvalósító részrendszerek, stb.) és a fogalmi szintű entitások; • Architektúra terv: Egy absztrakt számítógépes szintnek, a virtuális gépnek felel meg (virtual machine), egy ilyen virtuális gép gondoskodik azokról az eljárásokról és objektumokról, amelyek elősegítik a fogalmi szintű entitások leképezését a megvalósítási platformra, vagyis a hardver és szoftver környezetre. Az alkalmazás tervezése során felismert fogalmi szintű elemek közvetlen leképezése absztrakt adat típusokra és a hozzájuk kötődő eljárásokra, különösen az olyan nagy bonyolultságú rendszereknél mint például az ismeretbázisú rendszerek meglehetősen nehéz. Szervezeti, feladat, szakértelem, ágens és kommunikáció modellje

világ

Mi a probléma és azt hogyan oldják meg

absztrakció

transzformáció

rendszer

megvalósítás

Tervezési modell

Hogyan valósítsák meg

Ábra 14. A tervezési modell szerepe • A platform terv: Ez annak az aktuális számítástechnikai környezetnek a terve, amelyben az alkalmazási rendszer működni fog. A megvalósításra kiválasztott nyelv, hardver és szoftver leírása, továbbá azoknak a peremfeltételeknek a megadása, amelyek a válaszidőre, futási sebességre, hardver és szoftver megszorításokra, korlátokra vonatkoznak, továbbá a szervezet műszaki politikájából adódó következményekre, mint például a rendszerek kompatibilitása, árszínvonal stb. Az alkalmazási és architektúra terv esetében két szintet különböztetnek meg: a specifikációs vagy magas szintű tervet és a részletes terv szintjét. A részletes terv használ egy program definíciós nyelvet (program definition language, PDL) annak a leírására, hogy a specifikációt hogyan lehet megvalósítani az adott számítástechnikai környezetben mind az absztrakt mind a célkörnyezetben. A tervezési modell magas szintű lebontását az ábra mutatja (ábra 15). 3.4.3 Az egyes alkotórészek leírása 3.4.3.1 Az alkalmazás terve Az alkalmazás terve a következő elemekből áll:

⇒ Alkalmazás: A rendszer magas szintű specifikációja, műszaki, informatikai leírása. Két fő komponense van: ♦ A vezérlési architektúra : a részrendszerek feletti vezérlési struktúra leírása. (Nem keverendő össze az architektúra tervvel). ♦ van-részrendszere (kapcsolat): az alkalmazás egésze és a részrendszerei között fennálló kapcsolat. alkalmazás specifikáció

Segítségével valósítja meg

Belül valósítja meg

részletes architektúra terv

ALKALMAZÁS TERVE

architektúra specifikáció

Segítségével valósítja meg részletes architektúra terv

nyelv specifikáció

Belül valósítja meg Segítségével valósítja meg

megvalósítási platform

ARCHITEKTÚRA TERVE PLATFORM TERV

Ábra 15. A tervezési modell magas szintű felbontása ⇒ Részrendszer: Az alkalmazás mindegyik részrendszerére egy ilyen specifikáció készül. A következő bejegyzések és kapcsolatok rögzítése történik meg: ♦ Név: a részrendszer neve; ♦ Típus: a részrendszer típusának megadása, a következők egyike lehet: ismeretbázisú rendszer, a részrendszerek közötti kommunikációt megoldó részrendszerek, vagy egyéb más részrendszerek típusú (például adatbázis-kezelő rendszerek); ♦ Funkcionalitás: A részrendszer funkcionalitásának rövid leírása. Egyegy részrendszer egy vagy több a feladat és kommunikációs modellben megfogalmazott feladat elvégzését szolgálja; ♦ megvalósítja: A feladat és a részrendszer közötti kapcsolat, amely azt jelöli ki, hogy melyik részrendszer melyik feladatot valósítja meg. Ennek a kapcsolatnak több példánya is lehet, ha a részrendszer több feladatot is megold. ♦ van-része: ez a kapcsolat a részrendszer és részei közötti kapcsolatot jelöli, vagyis ha van a részrendszernek további felbontásra érdemes része. ♦ van-részletes-terve: a részrendszer és részletes terve közötti kapcsolat. Ezt a kapcsolatot nem kell megteremteni ha olyan részrendszer alkalmazására kerül sor, amelyet már előre elkészítettek vagy egyszerűen polcról megvásárolható (például egy adatbázis-kezelő rendszer). ⇒ Dekompozíció: Mindegyik részrendszer felbomlik a fogalmi entitásainak (elemeinek, objektumainak) halmazára. A dekompozíció egyes elemeire a következő bejegyzéseket kell kitölteni: ♦ Paradigma: A részrendszer típusától függ:

• egy ismeretbázisú rendszerre a paradigma a “szakértelem”, mivel a részrendszer specifikációja a szakértelem modellje szerkezetét fogja követni; • a kommunikációs alrendszerre, amely az információ és adatcserét fogja megvalósítani, a paradigma a “kommunikáció”, mivel a részrendszer specifikációjának a kommunikációs modell tranzakciós struktúráját kell megőriznie; • bármilyen egyéb részrendszerre a tervezőnek kell meghatároznia a paradigma típusát (például egy entitás-kapcsolat diagram egy adatbázis specifikációra). FELADAT MODELL

feladat

megvalósít

alkalmazás architektúra

Ismeretbázisú rendszer van-részrendszere név típus: ism.b.rsz funkcionalitás

KOMMUNIKÁCIÓS MODELL van-részrendszere

Kommunikációs alrsz. van-részrendszere név megvalósít típus: kommunikáció funkcionalitás Más részrendsz. van-része név típus: funkcionalitás

megvalósít van-része

dekompozíció

van-része

paradigma: kommunikáció DDL

dekompozíció

dekompozíció paradigma: szakértelem DDL

tranzakció

van-részletes-terve

Alkalmazás részletes terve

paradigma: DDL

belül-valósítja-meg

architektúra

PDL

Ábra 16. Az alkalmazási terv elemei és kapcsolatai ♦ DDL: Ez a “Terv leíró nyelv” angol rövidítése (Design Description Language), amelyet a részrendszer azon elemeinek a leírására használnak, amelyekre a részrendszer tovább bomlik. A CommonKADS módszertan ad egy speciálisan az ismeretbázisú rendszerek részrendszereinek leírására kialakított DDL nyelvet. ⇒ Az alkalmazás részletes terve: Mindegyik részrendszernek van egy részletes terve, amelyik a részrendszer specifikációjának kifejtése, realizálása. Ennek a terv résznek egy bejegyzése és három kapcsolata van: ♦ PDL: Ez a “Program leíró nyelv” angol rövidítése (Program Description Language, PDL), az architektúra terv architektúra specifikációjából vezetik le a részletes leírást. Ezek után ez lesz annak a ‘programnak’ specifikációja, amelyik az architektúra specifikációban megfogalmazott virtuális gépen futna. (Vegyük észre, hogy az architektúra terv részletes tervének elemei írják le az aktuális program specifikációját.)

♦ belül-valósítja-meg: az architektúrán belül az alkalmazás részletes tervének realizálása. ♦ példánya: az alkalmazás részletes tervének elemei által használt számítástechnikai vagy a rendszerfelülethez tartozó objektumokhoz vezető kapcsolatok egyedi példányai. Ez a kapcsolat nem szükséges a készen beszerzett vagy átvett részrendszerekre. ♦ hívja: az alkalmazás részletes terve által használt számítástechnikai eljárásokhoz vagy a rendszerfelület tevékenységeihez vezető kapcsolatok egyedi példányai. Ez a kapcsolat nem szükséges a készen beszerzett vagy átvett részrendszerekre. Az ábra (ábra 16) mutatja az alkalmazás tervének elemeit, a terv elemek közötti kapcsolatot, a tervezési modell egyéb alkotórészeihez, valamint egyéb CommonKADS modellekhez való viszonyt. 3.4.3.2 Az architektúra terv Az architektúra terve a következőket jelenti: ⇒ Architektúra: Az architektúra terv magas szintű leírása. Kétfajta architektúra leírás van: a számítástechnikai komponensek és a rendszerfelület architektúrális leírása. ⇒ A számítástechnikai architektúra: Ez annak az absztrakt gépnek a leírása, specifikációja, amely fölött az alkalmazás alrendszerének funkcionális szolgáltatásait meg fogják valósítani. A következő bejegyzései és kapcsolatai vannak: ♦ Paradigma: (nem kötelező) A számítástechnikai architektúra paradigmatikus osztályának megnevezése (például falitábla [blackboard], szabály alapú [rule-based], stb.);

♦ Parancsok: Azoknak a szolgáltatásoknak a felsorolása, amelyek a rendszeren kívül levő felhasználó számára elérhetőek (például vegyél ki egy elemet a halmazból, készíts egy részhalmazt, stb.); ♦ használja: Mindegyik számítástechnikai objektumra létezik egy példánya ennek a kapcsolatnak nevezetesen az, amelyik azt mutatja, hogy ez a számítástechnikai architektúra terv melyiket használja; ♦ támogatja: Mindegyik olyan számítástechnikai eljárásra létezik egy példánya ennek a kapcsolatnak, amelyet a számítástechnikai architektúra támogat.

♦ van-részletes-terve: A részletes architektúra terv tervezési elemeihez vezető kapcsolat. Ezt a kapcsolatot nem kell megteremteni ha olyan részrendszer alkalmazására kerül sor, amelyet már előre elkészítettek vagy egyszerűen polcról megvásárolható. ⇒ Számítástechnikai objektum: A számítástechnikai architektúra mindegyik entitására (objektumára) — azaz fogalmilag önállóan megálló számítástechnikai elemére — egy egyedi példány keletkezik (lsd. a strukturális programozás absztrakt adattípusát vagy az objektum-orientált programozás objektumait). Példák számítástechnikai objektumokra: halmaz, verem (stack), produkciós szabály. ⇒ Számítástechnikai eljárás: A számítástechnikai architektúra mindegyik szolgáltatására egy egyedi példány jön létre (lsd. az objektum-orientált programozás metódusait, módszereit, procedúráit, eljárásait). A számítástechnikai eljárások a számítástechnikai objektumokon operálnak, és azt a vezérlési, irányítási struktúrát testesítik meg, amely a megtervezett tevé-

kenységek koordinálásához szükséges. Ezért a számítástechnikai eljárásnak csak egy kapcsolata van: ♦ -n–operál: Mindegyik a számítástechnikai eljárás által használt számítástechnikai objektumhoz vezet egy ilyen egyedi kapcsolat. ⇒ Részletes architektúra terv: A kiválasztott – a megvalósítás alapját adó – nyelvben létrehozandó számítástechnikai architektúra illetve rendszerfelület terv realizálása. (Készen kapott, vásárolt, újra felhasznált elemnél ezt nem kell megadni, mivel a megvalósítás nyelvét nem kell kiválasztani.) Egy bejegyzése és egy kapcsolata van: ♦ PDL (Program Description Language): A platform tervben kiválasztott megvalósítási nyelvből származtatott specifikációs nyelv, amely a szóban forgó program részletes leírását adja meg a cél platformon. ♦ belül–valósítja–meg: A részletes architektúra terv elemei és a megvalósítás nyelve — amelyben az architektúra realizálása történik— közötti kapcsolatot érzékelteti. Az ábra (ábra 17) mutatja az architektúra terv elemeit, a terv elemek közötti kapcsolatot, a tervezési modell egyéb alkotórészeihez, valamint egyéb CommonKADS modellekhez való viszonyt. belül-valósítja-meg

architektúra

számítástechnikai

rendszerfelület architektúra

architektúra paradigma parancsok használja

van-részletes-terve

objektum

számítástechnikai eljárás

rendszerfelület

rendszerfelület

médiuma

tevékenysége

-n–operál

-n–operál Egyedipéldányt-hozlétre

hívja

alkalmazás részletes terve PDL

támogatja

használja

támogatja

számítástechnikai

paradigma esemény

van-részletes-terve

Egyedipéldányt-hozlétre

részletes architektúra terv PDL

hívja

megvalósítás nyelv belülvalósítjameg

Ábra 17. Az architektúra terv elemei és közöttük fennálló kapcsolatok 3.4.3.3 A platform terv A platform terv komponensei a következők: • Platform: A platform terv legmagasabb szintű eleme; a következő kapcsolatai állnak fel a platform különböző alkotórészeihez viszonyítva:

• nyelvet–használja: A platform és a platform által támogatott megvalósítási nyelv közötti viszony kifejezése. A platform több megvalósítási nyelv használatát is támogathatja. • szükséges–hardver: A részrendszer(ek) megvalósításához igényelt hardver megjelölése a kapcsolat létrehozásán keresztül. • szükséges–szoftver: A részrendszer(ek) megvalósításához igényelt szoftver megjelölése a kapcsolat létrehozásán keresztül. • szükséges–környezet: A részrendszer(ek) üzembe helyezéséhez igényelt környezethez vezető kapcsolat. • felhasználója: A részrendszer(ek) azon leendő felhasználóinak megnevezése ezen a kapcsolaton keresztül, akiket az ágens modellben emberi, humán ágensekként azonosítottak. • van–rendszer–modellje: Az ágens modellbeli rendszer ágensekhez vezető kapcsolat, amelyik megadja a megtervezendő részrendszer modelljétfelhasználója

platform

részletes architektúra terv

ágens

ÁGENS MODELL ágens

PDL

van–rendszer–modellje nyelvet–használja

belül-valósítjameg szükséges–szoftver

szükséges–hardver

környezet

Megvalósítás nyelve hardver konfiguráció

szoftver konfiguráció -ban–áll– rendelkezésre -ban–áll– rendelkezésre

-ban–áll– rendelkezésre informatikai erőforrások

egyéb erőforrások SZERVEZETI MODELL

Ábra 18. A platform terv elemei és kapcsolatai • A megvalósítás nyelve: A szóban forgó architektúra megvalósítási nyelvének meghatározása, legalább egyet meg kell nevezni. • Hardver konfiguráció: Ez a géptípusok, összekapcsolásuk, rendszer integrációs elemeik stb. megadását jelenti. Csak a lényeges elemeket kell felsorolni, egyébként ennek az elemnek a létrehozása nem kötelező, és csak egy kapcsolata van: • -ban–áll–rendelkezésre: Ezeknek a hardver elemeknek a szervezeten belül valahol elérhetőknek kell lenniük, és szervezeti modell alkotórészében, az informatikai erőforrások keretében a meghatározásukra már sor került. • Szoftver konfiguráció: A kereskedelmi forgalomban beszerezhető szoftverekre vonatkozik, amelyekre a rendszer bevezetéséhez szükség van (például adatbázis-

kezelő rendszer, operációs rendszer, alkalmazás készítő eszközök, stb.). Ez a komponens sem kötelező, egy kapcsolata van: • -ban–áll–rendelkezésre: Ezeknek a szoftver elemeknek a szervezeten belül valahol elérhetőknek kell lenniük, és szervezeti modell alkotórészében, az informatikai erőforrások keretében a meghatározásukra már sor került. • Környezet: Annak a munka környezetnek a leírása, amelyben a végleges rendszer üzembe helyezése meg fog történni. Szintén nem kötelező elem és csak egy kapcsolata van: • -ban–áll–rendelkezésre: Ennek környezetnek a szervezeten belül valahol elérhetőnek kell lenni, és a szervezeti modell alkotórészében, az egyéb erőforrások keretében a meghatározására már sor került. Az ábra (ábra 18) mutatja a platform terv elemeit, a terv elemek közötti kapcsolatot, a tervezési modell egyéb alkotórészeihez, valamint egyéb CommonKADS modellekhez való viszonyt. 3.4.3.4 A tervezési modell alkotórészei közötti kapcsolatok A tervezési modell három alkotórésze közötti kapcsolatok összefoglalásakor emlékezzünk arra, hogy az alkalmazás terve a rendszer funkcionalitásának specifikációja és részletes terve, az architektúra terv a virtuális gép fölött működő rendszer specifikációja és részletes terve, amelynek alapján az aktuális gépnek megfelelő formára hozható ez a specifikáció, a platform terv formájában. Ahogy az előbbi fejezetekben ez már megjelent, a következő kapcsolatok állnak fel a tervezési modell elemei között: • Az alkalmazási terv és az architektúra terv között: Az alkalmazás részletes terve: ⇒ az architektúra határozza meg azt, amin belül a megvalósítás megtörténik; ⇒ számítástechnikai eljárásokat használ fel, hív meg; ⇒ a számítástechnikai objektumok egyedi példányait hozza létre; ⇒ a rendszerfelület tevékenységeinek meghívása; ⇒ a rendszerfelület médiumának, adat- és információhordozójának létrehozása, megállapítása. • Az alkalmazási terv és az architektúra terv között: Az architektúra részletes terve: ⇒ a megvalósítási nyelvvel, ennek a segítségével, ebben a nyelvben valósítják meg. 3.4.3.5 Kapcsolat más modellekkel A tervezési modellnek egyértelmű explicit és világos kapcsolata van a szervezeti, a feladat, kommunikációs és az ágens modellhez, ezt az alábbiakban foglaljuk össze. (A szakértelem modelljéhez való kapcsolata implicit, mivel az ismeretbázisú rendszer kompetenciáját, szakértelmének kiterjedését az adekvát szakértelem modell részben írják le és mint megtervezendő alrendszer jelenik meg a tervezési modellben). • A feladat modellhez való kapcsolat: ⇒ Egy alrendszer (ismeretbázisú vagy egyéb rendszer) egy vagy több feladatot valósít meg. • A kommunikációs modellhez való kapcsolat: ⇒ A kommunikációs alrendszer egy vagy több tranzakciót valósít meg. • Az ágens modellhez való kapcsolat: ⇒ A platformot egy ágens mint felhasználó veszi igénybe;

⇒ A platformhoz tartozik egy (rendszer) ágens, ami a rendszer modell szerepét tölti be, jelöli meg. • A szervezeti modellhez való kapcsolat: ⇒ Az informatikai erőforrások felsorolásában a hardver és a szoftver konfiguráció rendelkezésre áll. ⇒ A környezet leírása az egyéb erőforrások keretében áll rendelkezésre.

3.5 A kommunikációs modell 3.5.1 A kommunikációs modell céljai A CommonKADS kommunikációs modelljének a fő célja az, hogy azoknak a kockázatoknak a csökkentésével foglalkozzék, amelyek közvetlenül érintik az egyes számítógép programok és az emberi felhasználók közötti együttműködést, és olyan információcsere eljárást fejlesszenek ki, amely segíti elkerülni az ezekből származó veszélyeket. Ez az az eszköz, amelyik azt a kommunikációs környezetet specifikálja, amelyben az ismeretbázisú rendszernek működnie kell. Ezt a modellt lehet arra használni, hogy a kommunikációs igények funkcionális oldalával kapcsolatban fellépő kérdéseket kezelni lehessen, továbbá a tervezés során az információ cserével kapcsolatban hozott döntéseket ebben a modellben lehet rögzíteni. Az ember-gép kapcsolat megfogalmazásához a következő eszközöket nyújtja ez a modell: • magyarázó képesség • a hagyományos ismeretbázisú rendszereknél alkalmazott eszköz arra a célra, hogy a felhasználó megértse azt a gondolatmenetet, amit az ismeretbázisú rendszer követett és hogyan jutott az adott következtetésre. Ez az ismeretbázisú rendszereket körülvevő misztikum csökkentését célozza. • kezdeményező képesség • a rendszerrel folytatott dialógus keretében az irányítás átvétele. Időnként a rendszer van irányító helyzetben, időnként pedig a rendszer végfelhasználója. A kezdeményező szerepe azért is fontos mert ennek révén csökkenthető azoknak a kérdéseknek a száma, amelyeket az ismeretbázisú rendszernek fel kell tennie, és ezáltal a magyarázatok iránti igény is mérsékelhető. • dialógus, • a rendszerrel folytatott párbeszéd, a felteendő kérdések sorrendje, a rendszerrel által észlelt veszély helyzetet jelző riasztás jelei, stb. • médium, • az adat- és információcserét megvalósító, információhordozó közeg, a rendszerfelület jellege szerint lehet a közvetlen rendszer kezelést lehetővé tévő (directmanipulation interface), vagy kérdések összeállítását segítő (query interface) rendszerfelület, amelyet a kommunikáció levezénylésére választottak az előbb felsorolt működési módokban. • Felhasználó csoportok, • az összes fentebbi témakör — a kezdeményezés, magyarázó képesség, a dialógus, és médium — mind ahhoz a kérdéshez kapcsolódik, hogy ki is a felhasználó. Talán a legfontosabb az, hogy a felhasználók között úgy tegyünk különbséget, hogy valójában maguk a felhasználók milyenek: vagyis kezdő, naiv felhasználók, vagy gyakorlott felhasználók és fejlesztők, ez az egyik lehetőség osztályozásra; nem pedig egy-egy egyedi felhasználó igényeihez kell alkalmazkodni.

3.5.2 Ismertetés A kommunikációs modell alkalmazhatóságának van néhány korlátja: • A kommunikációs modell egy-egy példányát el kell készíteni mindegyik feladat hozzárendelésre: Ugyanaz a feladat modell a feladatokat szétosztásának többféle módját is megengedi, ha azonban több ilyen lehetőség is van, akkor mindegyik feladat kiadáshoz, megbízáshoz egy kommunikációs modellt kellene létrehozni. Feladat modell Ágens modell

rendelkezik

kezdeményezi Ágens

Komponens

résztvesz -ban

-ben specifikált

Tranzakció

Képességek Kezdeményező Gyakorlat Tudás / ismeret Résztvevő Gyakorlat Tudás / ismeret

igényel

Név Kommunikáció típusa Egyéb komponensek Peremfeltételek

Információ elem Szintaktikus objektum Médium

-ban valósul meg

-ből áll

-nek része által megvalósított

Tranzakció terve Követelmények Kedvezményezett tranzakció

Diskurzus

-ban valósul meg

Transzfer feladat Szakértelem modellje

Kommunikációs alrendszerek Tervezési modell

Ábra 19. A kommunikációs modell felépítése • A kommunikációs modellt nem lehet az emberek közti információcsere modellezésére használni: Az egyes szervezeten belüli személyek egyaránt kölcsönhatásba lépnek számítógépes ágensekkel, valamint más személyekkel bizonyos feladatok megoldása végett. A CommonKADS modelljének felépítése nem alkalmas az ember-ember közötti kommunikáció leírására, főként azért nem, mert kevés támogatás van a feladatok megoldása során lefolytatott ‘tárgyalások’ és a megállapodások rögzítésére, illetve ennek a folyamatnak a leírására, de azért sem mert ez a leírási mód nem használható arra, hogy az ismeret és információ darabkák emberek közti átadását nyomon követhesse. Ennek következtében a kommunikációs modell csak azt célozza meg, hogy az ember és a számítógépes rendszer közötti kölcsönhatást ragadja meg, amelyben az ember a rendszer felhasználója. • Az ismeretbázisú rendszernek nem szabad az ember-ember közti együttműködés segítésében részt venni. Bizonyos esetekben szükség van a számítógépes rendszerek közti kommunikáció leírására is, például olyan esetben is ki kell dolgozni egy kommunikációs modellt, amikor a következtető gépnek adatokra van szüksége vagy egy adatbázisból vagy a felhasználótól, attól függően, hogy vajon az adat megtalálható-e az adatbázisban. Ez a helyzet szükségessé teszi, hogy mind a következtető gép és az adatbázis között lefolytatandó kommunikációt mind az ember-gép párbeszédet modellezni kell. Azokban az esetekben, amikor tisztán csak számítógép kommunikáció merül fel, és az ember-gép párbeszéd nem jön szóba, nem kell kommunikációs modellt készíteni.

Ezeknek a dokumentálását a hagyományos számítógép kommunikációt leíró eszközökkel kell elkészíteni. 3.5.2.1 A modell szerkezete A kommunikációs modellt az ábra (ábra 19) vázolja fel, megmutatva az alkotórészeit, a közöttük fennálló kapcsolatot, valamint a CommonKADS módszertan egyéb más modelljeihez való viszonyát. 3.5.2.1.1 A tranzakciók terve A tranzakciók terve azokat a követelményeket rögzíti, amelyek meghatározzák a tranzakciók végrehajtásának sorrendjét. A tranzakció terv egy a rendszer tervre vonatkozó szigorú követelmény specifikáció, és ezért nagyon pontos és szabatos jelölés technikával kell megfogalmazni. A CommonKADS módszertanbeli kommunikációs modell leírására van egy szintaktikai szabály rendszer, amely a tranzakciók sorrendjére vonatkozó minimális követelmények megformálásra szolgál. A rendszer által kezdeményezett tranzakciók esetében a logikai következtetések stratégiai szintjének először azt kell azonosítania, hogy vajon milyen transzfer feladat végrehajtására van szükség. A tranzakció terv legfeljebb késleltetheti ennek a végrehajtását, megkövetelve vagy előnyben részesítve más egyéb tranzakciók indítását. A tranzakciók terveit több célra is fel lehet használni. Például az ember-gép párbeszédet olyan dialógus blokkokra lehet fel vágni a tranzakció terv segítségével, amelyek mindegyike más-más témakörrel foglalkozik. A tranzakció tervnek két attribútuma van: • Követelmények • azoknak a feltételeknek a megfogalmazása, amelyeknek a tranzakció indítása előtt igaznak kell lenniük; ezek globális követelmények, amelyek a teljes dialógusra érvényesnek kell lenniük. • Kedvezményezett tranzakciók • ha több lehetséges választás van a szóba jöhető tranzakciók között, akkor a kiválasztás módjának megadása. Ezek a követelmények lokálisak, vagyis attól függenek, hogy a dialógus lefolytatása során milyen helyzet áll elő, és ennek megfelelően kell a választást végrehajtani. 3.5.2.1.2 Tranzakciók A tranzakció-űrlap, vagy tranzakció-formalap az egyes tranzakciók szerkezetének leírására használható. A tranzakciók alapvető célja az, hogy (információ) komponensek egy halmazát az egyik információ birtokostól egy vagy esetleg több információ befogadóhoz eljuttassa. Mindegyik tranzakciónak a szakértelem modelljében megadott legalább egyik transzfer feladat megvalósulásának kell lennie, kivéve azokat a párbeszéd kezdeményező tranzakciókat, amelyek az jelzik, hogy a felhasználó valamilyen célra a rendszert akarja használni. A transzfer feladat leírásának részletességét, részekre bontásának finomságát a szakértelem modelljében kell definiálni. A tranzakció leírásának attribútumai: • Név • a tranzakció megnevezése. • Kommunikáció típusa • csak akkor van erre szükség ha a tranzakció tervben osztályozni kell a tranzakciókat. Ez az attribútum kapcsolatot teremt a kommunikáció és a szakértelem modellje között abban az esetben, ha a kommunikáció mikéntjét a szakterület sajátosságai határozzák meg, illetve esetleg megfordítva, a szakterület modellje esetleg rögzíti a szakterület objektumainak vagy típusainak olyan sajátosságait, amelyek a kommunikáció módjával állhatnak kapcsolatban. A kommunikáció

típusát a szakértelem modelljében felhasznált fogalmakkal és az ott alkalmazott kifejezésekkel kell definiálni, ez maga után vonja, hogy ezeknek a terminológiai elemeknek a szakterület ismeretei körében meg kell jelenniük — a szakterület ontológiájának része a szakterület ismeretei, mint a ‘a szakterület kifejezés gyűjteménye’, vagy ‘szótára’. A ‘szakterület taxonómiája’, vagy fogalmi hierarchiájának felépítése szintén használható mind az egyedi tranzakciók leírására, mind a tranzakció terv szabályainak megfogalmazására. Ebben az esetben a szokásos öröklődési mechanizmust kell használni, azaz a magasabb szintű vagy általánosabb szabályt fölülbírálja, fölülírja a sokkal specifikusabb, alacsonyabb szintű szabály érvénybe lépése, léptetése. • Egyéb komponensek • A tranzakcióban átadott azon komponensek halmaza, amelyek léte nem a feladatok szétosztásának módjából következik. Ezt az attribútumot főleg a magyarázatok iránti igény megfogalmazására használják. • Peremfeltételek, nem kötelező • a tranzakció terv ‘elosztott’ változata, amelyik nagyon pontosan előírja azt, hogy milyen feltételeknek kell teljesülniük azelőtt, hogy a tranzakció végrehajtására sor kerülhetne. A szabatos szintaktikai leírási formátumot ( [Waern93a], [Waern94]) kutatási jelentéseiben lehet megtalálni, ebben a formátumban kell a peremfeltételeket leírni. Requirements = PC | PC & PC | PC v PC| after PC | immediately–after (PC) Requirement = követelmény PC = Pre-Conditions, peremfeltétel after = utána immediately–after = közvetlenül utána A tranzakció két olyan modell elemmel is kapcsolatban állhat, amely nem része a kommunikációs modellnek. • Transzfer feladat (a szakértelem modellből) • A szakértelem modellje specifikálja a transzfer feladatokat. Ha a kommunikáció típusát a szakértelem modellből származtatják, onnan örökli, akkor a transzfer feladatnak és a tranzakciónak a típusa meg kell, hogy egyezzék. • Komponens(ek) (a feladat modellből) • Egy tranzakció egy halom (információ) komponenst ad át, transzferál. Pontosan egy ágensnek kell szerepet játszania a feladat végrehajtásában, nevezetesen annak, aki vagy ami szolgáltatja az adott (információ) komponenseket. Ez az ágens — definíció szerint — az információ birtokosa, tulajdonosa. Nincs külön kapcsolat, vagy attribútum az információ birtokosának megjelölésére vagy az információ befogadójának a jelzésére. Annak a ténynek az érzékeltetésére, hogy egy ágens egy bizonyos (információ) komponenst szolgáltat, az ágens egyik példánya és az (információ) komponens megfelelő példánya között egy olyan kapcsolatot kell létrehozni, ami jelzi az információ “szolgáltatást”. 3.5.2.1.3 Diskurzus A diskurzus a ‘beszéd cselekmény’ szintjén történő párbeszéd leírását tartalmazza. (‘Beszéd cselekmény’ alatt az irodalomban a következőt értik: “ Beszéd cselekmény egy olyan atomi nyelvi cselekedet, amelyet azért hajtanak végre, hogy egy bizonyos hatást elérjenek vele, mint például egy kívánatosnak tartott hitet, hiedelmet vagy meggyőződést ébresszenek a beszéd cselekmény befogadójában.”). A diskurzus a tranzakció legbonyolultabb része és számos dolgot ki tud fejezni:

• A diskurzus jelzi azt, hogy vajon a tranzakció végrehajtása abortálható-e (feltétel nélkül megszüntethető), vagy felfüggeszthető-e. • A diskurzus adja meg a tranzakció alternatív kimeneteit, a végrehajtás lehetséges változatait megjelölve, hogy melyek azok, amik sikeresnek és melyek azok, amik sikertelennek tekintendők. • A diskurzusnak egyértelműen és explicit módon meg kell jelölnie a felhasználó jellemző vonásait. Ezek lehetnek sztereotípiák a felhasználókról , vagy esetleg sokkal dinamikusabb jellegű információk, amelyek a felhasználók szándékaira és vélekedéseikre, meggyőződésükre támaszkodik, stb. Mindkét esetben a képességek modell alkotórészben a rendszer ágensre vonatkozó követelményeket rögzíteni kell ezen felhasználók tulajdonságainak napra készen tartása végett. • A ‘beszéd cselekmények’ halmaza, amely egy diskurzuson belül előkerül, azt fejezi ki, hogy milyen kölcsönhatás, milyen információcsere zajlik le ezen a párbeszéden belül. A beszéd cselekményekhez’ tartozó szótárak, kifejezés gyűjtemények létrehozása megengedett, amelyek a különböző információmódok típusaival fognak foglalkozni. A ‘beszéd cselekményre’ vonatkozó nyelvtan pontos, egzakt leírása a már hivatkozott helyen megtalálható ([Waern94]), továbbá egy példa szótárakat is közölnek ugyanott. 3.5.2.1.4 Információelemek Az információelemek határozzák meg azt, hogy egy diskurzuson belül előforduló ‘beszéd cselekmények’ milyen módon írhatók le, fejezhetők ki. Elvileg minden olyan ‘beszéd cselekményre’ – ami bármelyik, tetszőleges tranzakció leírásban felbukkanhat – pontosan egy információelemet kell definiálni. Az egyik beszéd cselekmény információ komponenst fog szolgáltatni, a másik csak a kommunikáció jelzését fogja szállítani, mint például a dialógust kezdeményező üzenetet, vagy bizonyos információk kézhezvételének nyugtázását vagy az információ részletes feldolgozásának kérelmezését. Ahelyett, hogy az összes ‘beszéd cselekményre’ az információelemek explicit meghatározását elkészítenék, a tervezési modell rendszerfelület alkotórésze definiálja azt az információ struktúrát, ami közvetlenül kapcsolódik a diskurzushoz. Az információ struktúra azt írja le, hogy egy adott diskurzus hogyan valósul meg a rendszerfelületen belül. Az információelemeket lehet arra használni, hogy meghatározzák a komponensek átadásának módját. Minden olyan beszéd cselekményre, amely legalább egy információelemet vagy egynek a részét szállítja, definiálni kell egy információelemet. Egy komponenst meg lehet fogalmazni akár kérelemként akár válaszként. Egy információelemnek két attribútuma van: • Szintaktikus objektum • Az információelem szintaxisa, amely megfelel egy komponensnek, vagy egy komponens részének, és egy beszéd cselekményben keretében jelenik meg. • Kimeneti médium • Az információelem lehetséges kimeneti médiumai, szóba jöhető információhordozó közegei. 3.5.2.1.5 A tranzakcióban résztvevő felek mindegyikének a képességek egy jól meghatározott halmazával kell rendelkeznie, nevezetesen azzal, aminek birtokában az ágens el tudja végezni a tranzakciót. Ez a modell elem két részből áll, az egyik az ágensre mint kezdeményezőre szab meg követelményeket, a másik a többi részt vevő féllel szemben támaszt követelményeket.

A képességek attribútumai: • Gyakorlat • Bármilyen olyan képesség, képzettség, gyakorlat, amire az ágensnek szüksége van – a következtetési képesség kivételével – ahhoz, hogy részt vegyen a tranzakcióban. Az elképzelhető példák: szaglás, repülőgép manőver végrehajtásának képessége, két másodpercnél kisebb reakció idő. Igen lényegesnek bizonyult az, hogy a szaknyelvvel és annak szótárával szemben folyamatosan támadó igényeket nyomon kövessék. • Tudás / ismeret • A rendszer következtetési feladatainak ellátásához szükséges ismeretek, illetve más ágensek számára szükséges ismeretek, ami ahhoz kell, hogy az ágens részt tudjon venni a tranzakcióban. Néhány példa: szakterület szótára, következtetési ismeretek, meta-szintű ismeretek a rendszer képességeiről. Az ismeret igényre vonatkozó követelményeket a szakértelem és az ágens modellben használt leírási móddal összhangban kell kifejezni, azonban nincs szükség egy bizonyos szintaktikai leíró mód előírására mivel a képességekkel szemben szabott követelmények nem szolgálnak a tervezési modellben megvalósítandó kommunikáció specifikációjának megadására.

3.6 Ágens modell 3.6.1 Az ágens modell célkitűzései Az ágens modell célja, hogy a feladatok végrehajtásában érdekelt különböző ágensek sajátosságait (képességeit, korlátait, peremfeltételeket) le lehessen írni. Az ágens modell készítés valójában annak az eszköze, hogy: • segítse a meglevő rendszerek és a felhasználók megismerését és megértését; • az új rendszer ágensek funkciót meg lehessen fogalmazni (egy ismeretbázisú rendszer esetében a következtetési képességének globális szintű megértése); • a létező ágensek szerkezetében, felépítésében bekövetkező változások megragadása (a rendszer további, sokkal specializáltabb részekre bontása); • az ágensek feladat végrehajtási módja megváltozásának megformálása, ami az ismeretbázisú rendszer szervezetbe történő bevezetése miatt következik be; • a feladat kiosztás, átruházás, hozzárendelés módja helyességének leellenőrzése, a kommunikációs modell helyességének ellenőrzése, valamint a két modell összhangjának megvizsgálása. Előfordulhat az, hogy nem létezik olyan ágens, aki kielégítené azokat az igényeket, amelyek a feladatok elemzése során felmerültek. Ebben az esetben új feladat felbontást kell készíteni, és ezzel együtt új tranzakció tervet is. 3.6.2 Ismertetés Az ágens modell azon ágensek halmazából áll, akiket a feladat modellezés során ismertek fel. Ezekre az ágensekre az összes olyan sajátosságot rögzíteni kell, amelyek a feladatok végrehajtásához lényegesek, valamint ugyancsak azokat a korlátokat is, amelyeket a szervezet szab meg. Az ábra (ábra 20) mutatja az ágens modell felépítésének szerkezetét, amely négy alkotórészből áll: • Ágens. Az ágens a feladat illetve a feladatok egy bizonyos halmazának végrehajtója. Lehet ember (egy felhasználó vagy felhasználók csoportja), egy másik számítógép, vagy bármilyen másik rendszer vagy alrendszer (például adatbázis-kezelő

rendszer, folyamat vezérlő rendszer, vagy maga az ismeretbázisú rendszer). Ezt az alkotóelemet minden ágensre el kell készíteni és négy attribútuma van: Korlátok

Képességek Gyakorlat Szótár

Alkalmazásra vonatkozó ismeretek /tudás

rendelkezik rendelkezik

Komponens

kap

Logikai / következtetési képesség

írja le

Feladat

végrehajt

írja le Stratégiai tudás

Feladat modell

Normák Kedvezményezettek Engedélyezettek

rendelkezik

Szakértelem Kommunikáció

ad

Ágens

Részt vesz

Név Típus Szerep Pozíció

Kezdeményezés

Szakértelem modellje

által kiviteleződik Megoldás

lehet

Alkalmazott

Tranzakció

rendelkezik

eleme

Kommunikációs modell

Erőforrás

Szervezeti modell

Ábra 20. Az ágens modell felépítése • Név. Az ágens példánynak a neve, ami lehet egy ágens csoportnak is a neve, például az operátorok. • Típus. Az ágens típusa a következők valamelyike lehet: ember, egy új rendszer ágens, vagy egy korábban, előre meghatározott rendszer ágens. Arra lehet használni, hogy az ágens megkívánt képességeivel szemben támasztott követelményeket további minőségi jellemzőkkel írják körül. • Szerep. Az ágens szervezetben betöltött szerepe, amit a szervezeti modellből örököl meg. • Pozíció. Az ágens szervezetben elfoglalt helye, amit a szervezeti modellből örököl meg. • (Logikai) Következtetési képesség. Két bejegyzése van: • Szakértelem. Egy “intelligens ágenstől” elvárható, elvárandó képességek listája, amelyek a következtetések elvégzéséhez szükségesek. Az emberekre vonatkozóan csak olyan követelmények kerülnek rögzítésre, amelyek a rendszer funkcionalitását határozzák meg és esetleg a különböző felhasználók között változnak, mivel az teljesen lehetetlen, hogy egy kimerítő felsorolás készüljön az összes követelményről. Bizonyos esetekben, egyes felhasználókra külön-külön modellt kell a szakértelemre kialakítani abból a célból, hogy az igényelt következtetési képességet le lehessen írni, ez olyankor szükséges, amikor nem világos eléggé, hogy a felhasználó hogyan hajtja, vagy fogja végrehajtani a feladat elvégzéséhez szükséges következtetéseket. • Kommunikáció. A kommunikációs modell által előírt kommunikációs követelmények specifikációja. • Általános képességek. Ez az elem a következőket írja le:

• Gyakorlat, főleg az érzékelő képességekhez kapcsolódik, az érzékelési információkhoz (például egy hőérzékelő), az öt érzékszervhez (látás, hallás, tapintás, ízlelés, szaglás). És a tárgyakkal, objektumokkal való bánáshoz, azok manipulálásához. • Szótár, amelyet az ágens a másokkal való kommunikációban használ. Ha az ágens egy adatbázis-kezelő rendszer, akkor ez az attribútum az adatbázis-kezelő nyelvét jelenti. Ha az adatbázis-kezelő jól ismert, akkor elegendő a lekérdező nyelv megnevezése. Azonban van, amikor a szótár teljes leírását meg kell adni, sőt még arra is szükség lehet, hogy a nyelv szintaktikáját és szemantikáját is részletesen közölni kell. • Korlátok. A következőket határozza meg: • Az emberi ágensek viselkedési normáinak, szabályainak rögzítése bizonyos helyzetekben (pl. jogszabályok, törvények). • Kedvezményezett, vagy előnyben részesített körülmények, helyzetek a feladat végrehajtásával kapcsolatban. • Az engedélyezett dolgok azt fedik, hogy egy ágensnek (ami lehet akár ember akár rendszer) mit engedtek meg csinálni, vagy milyen információkhoz van joga hozzá férni. 3.6.3 A többi modellhez való kapcsolat Az ágens modellnek a következő kapcsolatai vannak a szervezeti, feladat, kommunikációs és a szakértelem modelljéhez. • Egy ágens a szervezet erőforrásainak egy eleme (ember, számítógép, szoftver). • A szervezet modelljében megfogalmazott megoldás(ok) kivitelezése az ágens feladata. • A szervezet alkalmazottai közül egyesek ágensek (felhasználók) lehetnek. • Egy ágens egy vagy esetleg több feladatot hajt végre (a feladat fa levelein, a hierarchia legalján elhelyezkedő feladatokat). • Egy ágens kap (információ) komponenseket egy másik ágenstől illetve ad egy másik ágensnek. • Ha két vagy több ágens vesz részt egy tranzakcióban, az egyiküknél kell lennie a kezdeményezésnek. • Az ágens logikai következtetési képességét a szakértelem modelljének különböző elemei írják le.

4. A CommonKADS specifikációs nyelvei 4.1 A fogalmi modellezés nyelve (The Conceptual Modelling Language) A fogalmi modellezés nyelve (CML) egy félig formális specifikációs nyelv, amely a szakértelem modelljén belül a feladat, a következtetési és a szakterületi ismeretek a rögzítésére szolgál. A CML-t BNF nyelvtanával adják meg (lsd. 4.1.1), ezenkívül egy grafikus ábrázolásra alkalmas jelöléstechnika bemutatása is megtörténik, amin keresztül a szakértelem modelljének legfontosabb tulajdonságainak az összegzése is megtörténik. A diagrammok nem helyettesíthetik a szöveges leírást, mivel a grafikus ábrázolás nem tér ki a részletekre. A diagram jelöléstechnika a szoftver tervezés bevált szabályait igyekszik követni, különösen a szakterület ismereteinek rögzítésénél, ahol az OMT (Object

Modelling technique) jelöléseit követi a módszertan (lsd. [Rumbaugh91]. [Kondorosi97] ) 4.1.1 A CML BNF nyelvtana A következő táblázat ismerteti a BNF fornális leíró elemeit, jelöléseit. Jelölés

Magyarázay

::= * + [] <> A BNF nyelvtan leírásának szimbólumai. . | X ::= Y. X szintaktikáját az Y definiálja. [X] Az X egyszer vagy nullaszor fordulhat elő. X* Az X nullaszor vagy annál többször fordulhat elő. X+ Az X egyszer vagy annál többször fordulhat elő. X|Y Vagy X vagy Y. <X> Csoportosító jel (“zárójel”), amely a müvelet hatókörének specifikálására szolgál. Pl. < X | Y > * A nyelv előredefiniált terminális szimbósymbol luma. symbol A nyelv felhasználó által definiált szimbóluma symbol A nyelv nem terminális szimbóluma. A CML szintaktikai szabályait a szakértelem modelljének leírásakor követetett szerkezetben adják meg (lsd. 3.1). Szakértelem modellje (Expertise Model) expertise-model

::= domain knowledge inference knowledge task knowledge.

Domain Knowledge domain knowledge

::=

domain-knowledge domain-ontology domain-model* model-ontology.

Domain Ontology domain-ontology

::=

domain-ontology domain-construct*.

domain-construct pression-def | relation-def

::=

concept-def | instance-def | attribute-def | ex-

| value-set-def. concept-def

::=

concept concept-name; [ description: text ; ] [ sub-type-of: concept-name <, concept-name

>* ; ] [ properties: property-def <, property-def >* ; ] [ annotations: text ; ]. property-def

::=

property-name : value-set [ cardinality: [ min natural] [ max
finite > ] ; ] [ differentiation-of: property-name ( conceptname ) ; ] [ default-value: value ; ]. value-set sal

::=

number | integer | natural | string | boolean | univer| number-range ( number, number ) | integer-range ( integer, integer ) | value-set-name | { string-value <, string-value >* } .

instance-def

::=

instance instance-name ; of: concept-name ; [ property-values: value-spec < , value-spec >*

value-spec

::=

property-name = value.

attribute-def

::=

attribute attribute-name ; [ sub-type-of: attribute-name ; ] [ description: text ; ] value-set: value-set; .

expression-def

::=

expression expression-name ; [ description: text ; ] operand: expression-operand < , expression-

expression-operand

::=

some-property-of concept-name | property-name of concept-name.

relation-def

::=

general-relation-def | binary-relation-def.

general-relation-def

::=

relation relation-name ; [ description: text ; ] [ sub-type-of: relation-name ; ] arguments: argument-def+ ;

; ].

operand >* ; .

[ properties: property-def <, property-def >* ; ] . binary-relation-def

::=

relation relation-name ; [ description: text ; ] [ sub-type-of: relation-name ; ] [ inverse: relation-name ; ] argument-1: argument-def ; argument-2: argument-def ; [ properties: property-def <, property-def >* ; ]

::=

argument-type < or argument-type >* ; [ argument-role: role-name ; ] [ cardinality: [ min natural] [ max
argument-type

::=

object-type | set ( object-type ) .

object-type

::=

primitive-type | user-defined-type .

primitive-type

::=

object | concept | instance | attribute | expression .

. argument-def finite > ] ; ] .

user-defined-type tribute-name

::=

concept-name | instance ( concept-name ) | atexpression-name .

value-set-def

::=

value-set value-set-name ; type: < nominal | ordinal > ; [ properties: property-def <, property-def >* ; ] value-list: string-value <, string-value >* ; .

::=

domain-model domain-model-name ; parts: < part-name: part-element-def+ >+ ; [ properties: property-def <, property-def >* ; ] [ axioms: text ; ] [ annotations: text ; ] .

Szakterület modellje Domain Models domain-model

part-element-def

::=

< simple-type | complex-type > ; [ cardinality: [ min natural] [ max
finite > ] ; ] . simple-type

::=

object-type | tuple ( relation-name ) .

complex-type

::=

< set | list | tuple > ( simple-type ) .

Modell ontológia Model Ontology model-ontology ]. model-term

::= ::=

model-ontology [ model-term <, model-term >*

object-type | relation-name .

Logikai következtetések ismerete Inference Knowledge inference-knowledge ::=

inference-knowledge inference-def* .

inference-def

inference inference-name; operation-type: text ; input-roles: dynamic-role-mapping+ output-roles: dynamic-role-mapping+ static-roles: static-role-mapping spec: text ; .

::=

dynamic-role-mapping

::=

static-role-mapping model-name ; .

::=

inference-role-name --> domain-reference ε domain-

domain-reference

::=

model-term-ref <, model-term-ref >* | text .

model-term-ref term ) .

::=

inference-role-name --> domain-reference ; .

model-term | set ( model-term ) | list ( model-

Feladatra vonatkozó ismeretek Task Knowledge task-knowledge

::=

task-knowledge task-description* .

task-description

::=

task task-name ; task-definition task-body .

task-definition

::=

task-definition goal: text ; input: < task-role-name : text ; >+ output: < task-role-name : text ; >+ [ spec: text ; ] .

task-body

::=

task-body type: < composite | primitive > ; sub-tasks: function-name <, function-name >* ;

[ additional-roles: < task-role-name : text ; >+ ] control-structure: text ; [ assumptions: text ; ] .

4.1.2 CML grafikus jelöléstechnikája Szakterület ismeretei (Domain Knowledge) concept

concept property: value-set property: value-set ...

concept concept

concept

fogalom

fogalom sajátosság:értéktartomány

fogalom

...

fogalom

Fogalmak

fogalom

Fogalom hierarchia

(concept) (concept)

property = value property = value ...

(concept)

concept

(fogalom)

fogalom

(fogalom) (fogalom)

sajátosság = érték sajátosság = érték ...

Egyedi példányok

Egyedi példány és az általános kapcsolata attribútum

attribute

-> értéktartomány

-> value-set

Attribútum

expression

expression

property

concept

concept

kifejezés

kifejezés

sajátosság

fogalom

Kifejezés egy bizonyos sajátosságra

relationname

argumentrole argument cardinality

fogalom

Kifejezés a fogalom bármelyik sajátosságára

argument

relationname

argument

property: value-set

kapcsolat neve

paraméterszerep számosság

paraméter

paraméter

kapcsolat neve

sajátosság: értéktartomány

N-áris kapcsolatok kapcsolat sajátossággal

Bináris kapcsolatok

paraméter

relationname

relationname

argument

argument

kapcsolat neve

kapcsolat neve

paraméter

Kapcsolat példány

relationname

kapcsolat neve

expression (concept)

kifejezés (fogalom)

paraméter

Kapcsolat Kapcsolat különböző típusú pahalmaz para- raméterrel métere

domain model

part name (concept)

part name relation

Szakterület modellje

Rész neve (fogalom)

Rész neve kapcsolat

A szakterület modellje és részei

Logikai következtetésekre vonatkozó ismeretek (Inference Knowledge)

static-role

model-term

input-role model-term

output-role

inference

model-term

operationtype

input-role model-term

statikus-szerep bemeneti-szerep

modellbeli kifejezés

modellbeli kifejezés

kimeneti-szerep

következtetés művelet típus

bemeneti-szerep

modellbeli kifejezés

modellbeli kifejezés

Következtetések és a szerepek finding

inf-1

inf-2

test observable

discriminating observable

observable select obtain specific finding

observable

finding compare

inf-3

......

megállapítás észlelhető kiválaszt begyűjti

2.következtetés

1.következtetés észlelhető tesztelés

megkülönböztető észlelhető

egyedi megállapítás

megállapítás összehasonlít ......

Transzfer feladat (a következtetés szerkezetének felrajzolásához szükséges)

észlelhető

3. következtetés

Halmaz mint Szerep nevek általánosítása (Halmaz részhalbemeneti sze- maz kapcsolat a szerepek között) (Supersetrep subset relation between roles)

4.2 A formális modellező nyelv (The Formal Modelling Language) Van egy teljesen formális leíró nyelv, amelyet CommonKADS módszertan számára fejlesztettek ki, ezt a nyelvet FML-nek vagy (ML)2-nek hívják. Ez a nyelv az elsőrendű predikátim kalkulusnak (a szakterület ismereteinek deklaratív reprezentációját

szolgálja), meta logika (a szakterület ismeretei felhasználásának módját lehet leírni vele), és a dinamikus logika (ami a vezérlési, ‘program’ vezérlési ismeretek rögzítésére alkalmazható). Ez egy meglehetősen bonyolult nyelv, aminek megértéséhez magas szintű logikai előképzettség is szükséges. Az érdeklődő az irodalomban találhat további részleteket ([Balder92],[Harmelen93]).

4.3 A magas szintű alkalmazás tervező nyelv (The High Level Application Design Language (HADL)) A CommonKADS jelölésrendszere, ami a tervezési döntések dokumentálását szolgálja, főként az ismeretbázisú rendszer specifikálását célozza meg. A HADL-nek nevezett nyelvnek a szakértelem modelljének szerkezetére támaszkodó jelölésrendszere van, és azzal foglalkozik, hogy a szakértelem modelljének következtetési és feladat rétegét olyan módon írja le, hogy az a megvalósítást elősegítse. A szakterületnek megfelelő réteg tervezése nagyon függ a választott architektúrától és ezért nem tárgya a magas szintű alkalmazás tervezési eljárásnak. 4.3.1 Feladat réteg (Task layer) A CML feladat leíró szintaxisát lényegében megőrizte a HADL feladat leírás is. Néhány további szolgáltatással bővült, a szerepeket típus információkkal lehet ellátni, a feladatra vonatkozó bejegyzéseket pedig tovább lehet finomítani. A következő leíró nyelvet javasolja a módszertan (a kifejezésekre nem ír elő egy egzakt formalizmust). Task Module Name Refinement of A szakértelem modelljén belül definiált feladat, és ebben a modulban lesz feladatként megtervezve. (The expertise model task, which is being designed in this task.) Task Definition Goal Input A bemeneti szerepek listája (A list of input roles (cf. input parameters)). Output A kimeneti szerepek listája ( A list of output roles (cf. output parameters or function results)). Spec A feladat szöveges leírása. (A textual description of the task.) Task Body Type Primitív vagy összetett, egy primitív feladat csak következtetéseket hív meg. Egy összetett feladat más feladatokat is meghív. (Primitive or composite. A primitive task activates only inferences. A composite task invoke other tasks.) Subtasks Additional Roles Azon szerepek listája, amelyek csak a feladaton belül láthatók. (A list of roles, which are only visible in the task (cf. local variables)). Control Structure A feladat lényegét alkotó tevékenység specifikációja, a feladat ‘teste’, amit egy procedurális nyelvben pszeudó kód formájában kell megadni. (The body of the task, described as a pseudo code in an imperative language.) End Module

4.3.2 A logikai következtetések rétege (Inference layer) A szakértelem modelljének logikai következtetéseit egy olyan következtetési eljárás formájában fogalmazzák meg, ami tartalmazza a paraméterek meghatározását, saját magának a következtetésnek a specifikációját pszeudó kódban és egy vagy több következtetési módszert, amik olyan algoritmusok, amelyek a következtetést valósítják meg. A paraméterek meghatározása Egy szakértelem modellbeli következtetés mindegyik szerepét a HADL-beli következtetési eljárásban egy-egy paraméterrel jelölik meg. A következő paramétereket különböztetik meg: • bemeneti paraméter: A következtetés olyan bemeneti szerepe, ami nem kapcsolódik közvetlenül a szakterület ismereteinek egyik eleméhez sem. (A következtetések összekötésére alkalmazzák.) • kimeneti paraméter: A következtetés olyan kimeneti szerepe, ami nem kapcsolódik közvetlenül a szakterület ismereteinek egyik eleméhez sem. (A következtetések összekötésére is alkalmazzák.) • szakterületből kivezető bemeneti kapcsolat: Ez a következtetés egy olyan bemeneti szerepe, amelyik a szakértelem modell szakterületi ismereteinek egyik eleméhez kapcsolódik. • szakterületbe vezető kimeneti kapcsolat: Ez a következtetés egy olyan kimeneti szerepe, amelyik a szakértelem modell szakterületi ismereteinek egyik eleméhez kapcsolódik. • lokális változó: A következtetés belső változója. Azokra a szerepekre, amelyek közvetlenül kapcsolódnak a szakterület ismereteinek elemeihez, olyan további információkat kapcsolnak hozzá, amelyek jelzik a szerep leképezését a szakterület ismereteire, kifejezéseire, szótári elemeire és arra használható, hogy az egyedi változó egyedi példányának létrehozását hogyan lehet korrekt módon megcsinálni. • A szakterület particionálása, részekre bontása (szakterület modellje), amiből az ismeretek és szerepek leképezése, összerendelése kinyerhető, a szakterület alkalmas konstrukciói megállapíthatók. • A leképezés leírásának formalizmusa (a következtetések paraméterezése, indexelése, dedukció, stb.) • a leképezés teljességének megfogalmazása, vagyis visszaadja-e az összes lehetséges szakterület ismeret elemeihez való lekötést, vagy csak mindig a következőt. • A leképezés irányának rögzítése, azaz a leképezés a szakterület ismereteinek rétegéből emeli át az információt a következtetések rétegébe vagy pedig megfordítva. A következtetési módszerek definiálása Egy következtetési módszer olyan eljárás, ami egy következtetés specifikációt valósít meg. Három lehetséges rétege van következtetésnek: • következtetési réteg szintű következtetési lépések: a következtetési módszer az összes információt a következtetési rétegből nyeri, vagyis a szakterület információit kiválasztották a szakterület ismereteinek rétegéből, ezeket leképezték és átnevezték a következtetési réteg terminológiájára.

• szakterület ismeretei szintű következtetési lépések: a következtetési módszer közvetlenül a szakterületi információkkal dolgozik. • vegyes következtetési lépések: a következtetési módszer bizonyos információkat a következtetési rétegből veszi és a szakterület ismereteinek rétegén, annak valamilyen alkalmas reprezentációján dolgozik. Ez a következtetési eljárások BNF jelölés szerinti leírása (4.1.1). inference-procedure-spec

::= inference procedure name parameter-definitions layer layer-specification (inference-method)* specification (pseudo) code end procedure

inference-method

::=

method layer

layer-specification

::=

(inference layer | domain layer | inference-domain layer)

name layer-specification

parameter-definitions ::=

input-parameters from-domain-input-links output-parameters to-domain-output-links local-variables

input-parameters ter-declaration)*

::=

parameter input

from-domain-input-links declaration

::=

input from domain layer

(parame(parameter-

link-definition)* output-parameters

::=

parameter output

local-variables declaration)*

::=

local variables

to-domain-output-links ter-declaration

::=

(parameter-declaration)* (parameter-

output to domain layer

(parame-

link-definition)* parameter-declaration ::=

variable-name

type parameter sort

link-definition

role type from mapping formalism

(dynamic | static) domain partition name mapping name formalism name

::=

direction exhaustiveness

( up | down | both) ( one | all)

5. Irodalom Elektronikus világháló cím további olvasmányokhoz, ahonnan a KADS projektek kutatási jelentéseinek legtöbbje Postscript formában letölthetők: http://swi.psy.uva.nl/projects/CommonKADS. [Aben95] [Aamodt92]

[Balder92]

[Boehm88] [Breuker94] [Chandrasekaran86]

[Duursma93] [Fensel&vanHarmelen] [Gustafsson94] [Harmelen93] [Hoog93] [Kondorosi97] [Linster93] [Molnár97] [Newell, 1982] [Olsson94] [Olsson94a] [Olsson94b]

Aben, M., Formal Methods in Knowledge Engineering, PhD thesis, University of Amsterdam, 1995. Aamodt, A., Benus, B., Duursma, C., Tomlinsen, C., Schrooten, R., Van de Velde, W., Task features and their use in CommonKADS, KADSII/T1.5/VUB/TR/014/1.0, KADS Consortium, ESPRIT KADS-II P5248, 1992. Balder, J., Akkermans, H., Formal Methods for Knowledge Modelling in the CommonKADS Modelling Methodology: A compilation, KADSII/T1.2/TR/ECN/014/1.0, KADS Consortium, ESPRIT KADS-II P5248, 1992. Boehm, B. (1988). A spiral model of sofware development and ehancement. IEEE Computer. Breuker, J., Van de Velde, W., CommonKADS Library for Expertise Modelling, Reusable Problem Solving Components, IOS Press, Amsterdam, 1994. Chandrasekaran, B., Generic tasks in knowledge based reasoning: High level building blocks for expert system design, IEEE Expert, 1(3):2330,1986. Duursma, C., Task Model definition and task Analysis process, KADSII/M5/VUB/RR/004/1.0, KADS Consortium, ESPRIT KADS-II P5248, 1993. Fensel, D., van Harmelen, F., A Comparison of Languages which Operationalise and Formalise KADS Models of Expertise, Report 280, Sept.93, Karlsruhe Univ. Gustafsson, M., Menezes, W., CommonKADS Reference Manual, KADSII/P2/WP/CP/011/1.0, KADS Consortium, ESPRIT KADS-II P5248, 1994. Harmelen, F., Balder, J., (ML)2 : A Formal Language for KADS Models of Expertise, in [Schreiber&all93]. Hoog, R., et al., The Common KADS model set, , KADSII/M1/DM1.1b/UvA/018/5.0, KADS Consortium, ESPRIT KADS-II P5248, 1993. Kondorosi, K., László, Z., Szirmay-Kalos, L., Objektum-orientált szoftverfejlesztés, ComputerBooks, Budapest, 1997. M. Linster, Using OMOS to Represent KADS Conceptual Models., in [Schreiber&all93], pp. 221-245. Molnár, B., Bevezetés a rendszerelemzésbe (2. fejezet) in Gábor, A., Információmenedzsment, 143-144 o., Aula kiadó, 1997. Newell, A. , The knowledge level. Artificial Intelligence. 1982 Olsson, O., User guide for the Task Model Editor, KADSII/T3/UG/SICS/003/1.0, KADS Consortium, ESPRIT KADS-II P5248, 1994. Olsson, O., User guide for the Communication Model Editor, KADSII/T3/UG/SICS/005/1.0, KADS Consortium, ESPRIT KADS-II P5248, 1994. Olsson, O., User guide for the Agent Model Editor, KADSII/T3/UG/SICS/004/1.0, KADS Consortium, ESPRIT KADS-II P5248, 1994.[Pradera94] Pradera, A., CommonKADS Workbench: Demonstrating

[Pradera94] [Pradera94a] [Rumbaugh91] [Schreiber93] [Schreiber&all93] [Waern93] [Waern93a] [Waern94] [Wielemaker91] [Wielemaker92] [Wielinga92] [Wielinga93] [Wielinga94]

the Expertise Model Tools, Technical Report KADSII/T3/ERITEL/O21/1.0, Sept. 1994. Pradera, A., CommonKADS Workbench: Expertise Model Tools User Guide, ESPRIT Project P5248 KADS-II/T3/UG/UvA/022/1.0, ERITEL, 1994. Pradera, A., CommonKADS Workbench: Demonstrating the Expertise Model Tools, ESPRIT Project P5248 KADS-II/T3/TR/ERITEL/021/1.0, ERITEL, 1994. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Object-Oriented Modelling and Design. Englewood Cliffs, New Jersey, Prentice Hall. Schreiber, Guus, Operationalizing Models of Expertise, in [Schreiber&all93]. G. Schreiber, B. Wielinga, and J. Breuker, KADS: A Principled Approach to Knowledge - Based System Development, Academic Press, 1993, pp. 119-149], Waern, A., The Common KADS Agent Model, ESPRIT Project P5248 KADS-II/M4/TR/SICS/001/V.1.0, Swedish Institute of Computer Science, 1993. Waern, A., Höök, K., Gustavson, R., The communication model, ESPRIT Project P5248 KADS-II/M3/TR/SICS/002/V.1.0, Swedish Institute of Computer Science, 1993. The Common-KADS Communication Model, Waern A., Höök K., Gustavsson R., Holm P. KADS-II/M3/SICS/TR/003/V.1.2 Wielemaker, J. (1991). SWI-Prolog 1.5: Reference Manual. University of Amsterdam. Wielemaker, J. & A. Anjewierden Programming in PCE/Prolog, University of Amsterdam, 1992. Wielinga, B. J., Schreiber, A. T., & Breuker, J. A. (1992). KADS: A modelling approach to knowledge engineering. Knowledge Acquisition, 4(1). Special issue 'The KADS approach to knowledge engineering'. Wielinga, B. J.(ed.), Expertise Model Definition Document, ESPRIT Project P5248 KADS-II/M2/UvA/026/1.1, University of Amsterdam, 1993. Wielinga, B. J.(ed.), Expertise Model Definition Document, ESPRIT Project P5248 KADS-II/M2/UvA/026/5.0, University of Amsterdam, 1994.