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 szakértelem szükséges Szakértelem modell szakmai jártasság igényelt Ágens modell informatikai megoldás kommunikációra való képesség kívánatos Kommunikációs modell Tervezési modell 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 ábra 1. CommonKADS modelljei közti kapcsolat 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 minõségi szemle és döntés A kezelhetetlen megoldások elvetése A következõ cilklus tervezése A tervezett elõrehaladáshoz képest a fejlesztési eredmények értékelése A kockázatok feltárása és dokumentálása Kockázat elemzés Kockázat elemzés Az elfogadhatóság kiértékelése A fejlesztési megközelítés lépéseinek kijelölése Fejlesztés nyomonkövetése Nyomköveté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 <n> é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. Szervezeti Ciklus 1 Ciklus 2 Ciklus 3 Ciklus 4 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 Az ismeret alkalmazás elve A modell alkotás elve A viszonylagos kölcsönhatás hipotézise Részletek megadása kölcsönhatás Az ismeretek típusba sorolásának elve részletek megadása A probléma megoldási eljárás leírása Az ismeret szint elve kiterjesztés A szerep behatárolás elve adaptáció szerint A megkülönböztetett racionalitás elve Á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ó módszerek Probléma megoldás ismeretei 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. önindító feszültség: {van, nincs} (Állapot változó) jelenség jelenség észlelhető Autó alkatrész Állapot változó állapot Hatást fejt ki üzemanyagtartály állapot: {üres, nem-üres} (Állapot változó) akkumulátor gyertya állapot: vizsgálat: {gyenge, normális} {száraz, nedves} (Állapot változó) (észlelhető) van jelenség Autó alkatrész Állapot változó: univerzális észlelhető: univerzális okoz motor Üa. állapot: {van gáz, nincs gáz} (Állapot változó) Önindító-áramköre biztosíték: {rendben, kiégett} (Állapot változó) biztosíték vizsgálat: {rendben, vezeték szakadás} (észlelhető) motor nem indul okoz állapot panasz -> Boolean ok motor megáll Hatást fejt ki Üzemanyag szállító rendszer állapot: {elzáródott, nem} (Állapot változó)} Műszerfal Üzemanyag jelző: jelző értéke (észlelhető) Akku. jelző jelző értéke (észlelhető)) Példányok (instances), a fogalmak olyan megnevezhető, egyedi példányai, amelyek sajátosságainak egyedi értékeik vannak. Tulajdonságok, attribútumok (attributes), tulajdonképpen olyan fogalmak tömör jelölésére alkalmazott rövidítésnek tekinthetők, amelyeknek csak egyetlen egy sajátosságuk van. Az attribútumokat általában az ismeret-bázisú rendszerek dinamikusan változó részében (a memória munkaterületében) 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 panasz állapot Ábra 6. Egy gépkocsi diagnosztikai feladatra a szakterület ontológiájának konstrukciói

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 feszültség = alacsony üzemanyagtartály állapot = üres üa. szállító rendszer állapot = elzáródott önindító feszültség = nincs műszerfal Akku. jelző = nulla motor üa. állapota = nincs gáz műszerfal Üzemanyagjelző = nulla önindító biztosíték vizsgálat =vezeték megszakadva Gyertya fej vizsgálat = száraz ok van jelenség motor nem indul Kapcsolat példányai = igaz 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.

következtetés Művelet típus: lefed Kapcsolat létrehozása; Bemeneti szerep: Kimeneti szerep: Statikus szerep: Kezdeti-panasz -> panasz; Hipotézis -> állapot; 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 lefed tény okok Kapcsolat létrehozása értékadás(jelenség) hipotézis megállapítás Összhangban álló hipotézis állapot Kapcsolat létrehozása á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 cél Találj egy megoldást; 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 specifikáció: Találj egy magyarázatot a kezdeti panaszra, amelyet a felhasználó által szolgáltatott adatokból 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 típus: összetett; részfeladat: generálás, tesztelés; Extra szerepek: hipotézis: Egy tesztelendő lehetséges megoldás; Vezérlési struktúra: Gépkocsi diagnosztika ( c: Kezdeti-panasz + d: Felhasználói-adatok --> h: hipotézis) = 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 tesztelés lefed 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 -3 részfeladat -4 részfeladat -21 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.

Sajátosság Funkció Szervezeti modell meghatározza rendelkezik típus A feladat modell alkotóelemei következő kiszolgálja Feladat SzM feladat Szakértelem modellje által megvalósított fő-/ aláltal be & megvalósított kimenet ismeretbázisú alrendszer által végrehajtott belül végzett megkívánt Környezet Komponens Képesség Tervezési modell által megvalósított által meghatározott része specifikált szolgáltatja / kapja Más alrendszerek Ágens Tranzakció Információ elem Ágens modell 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.