Tehingu-valija

Link: http://cs.uni.edu/~wallingf/patterns/sponsor-selector.html

Objekti käitumismuster

Eugene Wallingford
Department of Computer Science
University of Northern Iowa
[email protected]
© 1997

Ilmub Muster keeled Program Design 3,
toimetanud Robert Martin, Dirk Riehle ja Frank Buschmann
Addison Wesley, 1997, lk 67-78.

Minu Mustrid Page
Tuntud ka kui

Vahendas Resources, Kaudsed appihüüd

Tahtlus

Sponsor valija mustri saab ette mehhanism valides parim ressurss ülesanne on kogum vahendeid, mis muudab dünaamiliselt. See võimaldab tarkvara süsteemi integreerida uusi vahendeid ja uusi teadmisi ressursse, run-time viisil, mis on läbipaistev kasutajad ressursse. See muster põhineb ideel, et eraldada kolme liiki kohustusi: teades, kui ressurss on kasulik, valides nende hulgast ressursse ning kasutades ressurss.

Näide

Vaatleme tarkvara süsteem tegeleb ülesanne meditsiiniline diagnoos. Süsteem käsutuses kogum alamsüsteemid võimeline täitma eelkõige diagnostika sub-ülesandeid. Ülesanne / sub-ülesande struktuur võib nägema midagi sellist:

A Task Structure for Diagnosis

 

Joonis 1: Task struktuur Diagnoos

Igas punktis ajal diagnostilist seanssi, süsteem küsimuse ees: Milline sub-ülesandeid tuleks teha edasi? See on küsimus, probleemide lahendamise kontrolli. Varajane sellise süsteemi läbi oma sub-ülesandeid järjest, või mõnel muul ettenähtud järjekorras, kuid selline “kõva kodeeritud” kontrolli toodetud mitterahulda tehasest tulemusi. Sageli esitatud andmed varasemate tegevuste näidanud vajadust murda kindlaksmääratud järjestuses – öelda, et koguda täpsemaid andmeid tehes põhjuslik põhjendusi umbes hüpotees – selleks, et jõuda parima diagnoosi õigeaegselt.

Ideaalis võiks arvata diagnostika süsteem, millel on agent vastutab täitmise iga ülesandeks selles hierarhias. Run-time süsteem tahaks valida kõige sobivam sub-ülesandeid agent tugineda, põhineb kontekstis informatsioon puudub sel hetkel. See hõlmab määrata kindlaks, milliseid alamsüsteemid on tõenäoliselt kõige paremini edusammud eesmärk on jõuda kasulik diagnoosi.

Selline olukord tekib paljudes valdkondades: Operatsioonisüsteem võiksite valida parima protsessi sõiduplaani algoritm põhineb praeguse süsteemi olekut. Keskne veebiserver võiksite tasakaalu juurdepääsu koormus kogu perele veebiserverite aluseks nende tulemuslikkuse võimeid. Sidevõrgu võiksite valida parim marsruut sõnum põhineb hetkeolukorra võrgu ja selle komponendid. Kõigis neis näidetes kasutatakse vajab võime valida ressurss dünaamiliselt kogum vahendeid, mille attri-butes võib muutuda run-time.

kontekst

Sa hoone süsteemi, kus hulk ressursse kasutatakse täita mõned ülesanne, või süsteemi teadmisi nende ressursside saab muuta, kas staatiliselt või dünaamiliselt.

probleem

Mõnikord klassis on mitmeid teisi klasse (ressursid), kellega ta saab teha koostööd, kuid see ei saa teada enne, run-time, mis neid ressursse see vajab teatud situatsioonis. Lisaks hulga potentsiaalsete kaastöötajate võib aja jooksul muutuda, kas staatiliselt programmeerija muutmine või dünaamiliselt ajal süsteemi täitmist. Töötamise ajal, klassi tahaks valida “parim” kaastöötaja põhineb kontekstis informatsioon puudub sel hetkel.

Kuid projekteerimisel sellist kontrollimehhanismi tutvustab uusi probleeme. Üks lahendus sellele probleemile on kodeerida ressurss valiku mehhanism süsteemi otse. Selline lahendus toob kaasa kahte sorti raskusi: Kui programmeerija lisab uue ressursi süsteemi, süsteemi kontrolli teadmisi tuleb muuta, et muuta see kättesaadavamaks. Ja kui uue ressursi süsteemi lisada dünaamiliselt run-time – öelda, läbi mingi masina õppimine – süsteem ei saa kasutada ressurssi, sest tema kontrolli teadmisi ei viidata uue ressurss.

Teine lahendus on eraldi valik mehhanism arvesse eraldi klassi, mis on spetsialiseerunud kontrolli otsuste tegemisel, kasutades Blackboard muster. See lahendus muudab süsteemi immuunsüsteemi muutmise ees uusi ressursse. Aga see ikka confounds teadmisi ressurss rakendatavuse koos teadmiste ressursside eelistamist, mistõttu uue “valik” klassi altid sama raskusi uusi ressursse on lisatud süsteemi.

Iga lahendus sellele probleemile peaks tooma järgmised vägede tasakaal:

Süsteem peaks olema võimalik pääseda ressursside vajaduse korral.
See peaks olema võimalik lisada, muuta või eemaldada ressursse, kas staatiliselt või dünaamiliselt, tegemata ulatuslikke muudatusi süsteemi.
Kasuliku mõned vahendid ei või ei saa määrata enne, run-time.

lahendus

Tutvustage sponsor ja valija komponendid saavutada suuremat teineteisest lahutatud süsteemi ja ressursid, mida ta kasutab. Iga ressurss on sponsor, kelle ülesanne on soovitada, kui seda saab kasutada. Valikulülitil võtab neid soovitusi sisend ja otsustab millist ressurssi kasutada.

In täitmise käigus, kui süsteem vajab ressurssi jätkata, saadab ta taotluse valija, kes vastutavad vastavate ressursside kogum. Valikulülitil siis edastab taotluse kõik sponsorid komplekti. Iga sponsor hindab kohaldatavust selle ressursi ja saadab hinnangud tagasi oma vastuse. Valikulülitil siis kasutab neid pole, koos teiste eelistust teadmised ja taust informatsioon, et valida “parim” ressurssi kliendi praeguses kontekstis.

Uus ressurssi saab lisada süsteemi kas staatiliselt või dünaamiliselt hoone sponsor seda ja registreerida uue sponsori vastava valija. Paljudes olukordades looja ressurss on ka vaja registreerida eelistusi, mis on seotud uue ressursi valitavad samuti.

Võti Sponsor-valija muster on eraldamine kolme fundamentaalselt erinevad ülesanded: soovitamine ressursside, valides nende hulgast ressursse ning kasutades ressurss.

struktuur

Sponsor valija muster koosneb kolme liiki komponentidest: valija, komplekt sponsorite ja komplekt ressursse. Üheskoos on need komponendid annavad teenuste kogum teatud kliendi.

The Structure of Sponsor-Selector

 

Joonis 2: struktuur Sponsor-valija

Ressurss on mõni kogum objekte, mis on spetsiifilised funktsioonid mõnes suuremas kontekstis.

Iga sponsor sisaldab teadmisi, kui selle ressursi sobib kasutada. See teadmine viidatakse ainult kohalikku eripära keskkondade milles ressurss on kasulik. Kui võimalik, sponsor ei tohiks viidata ühelegi ressursi peale enda.

Valikulülitil kehastab teadmisi, millist ressurssi eelistavad eelkõige liiki olukorda. See teadmine võib väljendada eelistusi rühmade vahel ressursside ja võib viidata globaalse omadused kontekstis, nagu küsimusi run-time tõhususe ja korrektsuse. Valikulülitil saadab taotlused komplekt sponsorite ja saab komplekti pole tagasi. Seejärel kasutab neid reitinguid, et valida ressursi kasutamiseks praeguses kontekstis.

Klient on süsteem, mis kasutab ressursse, et täita mõned oma ülesannete raames. Ta saadab taotlused valija, kui ta vajab ressurssi ja viitab ressurss, mis on tagastatud valija.

Meie näites, kui klient on diagnostika süsteem. Ressursid on alamsüsteemid, mis täidavad osad diagnostika süsteem ülesanne, näiteks hüpoteesi, ehitaja ja põhjuslikku reasoner. Iga sub-süsteem on seotud sponsor, mis näitab, kas diagnostika süsteem peaks tugineda sub-süsteem antud olukorras. Ülesanne valija kasutab oma teadmisi, et valida sub-süsteem tugineda kõrval, mis põhineb pole tagastatud sponsorite ja teavet diagnostika süsteemi praeguses kontekstis.

The Sponsor-Selector Pattern Applied to the Diagnostic Example

Joonis 3: Tehinguvalija Muster Applied Diagnostic Näide

dünaamika

Sponsorvalija süsteem toimib järgmisel viisil.

The Dynamic Behavior of the Sponsor-Selector Pattern

Joonis 4: dünaamiline käitumine sponsor valija Muster

Klient jõuab punkti oma tegevust, millega ta vajab ressurssi, et jätkata, seega palub valija ressurss. Valikulülitil saateid taotluse kõigile sponsoritele, millest igaüks määr selle ressursi ja tagastab hinnangud ressurss. Valikulülitil kasutab neid reitinguid, et valida kõige sobivam vahend ja siis küsib vastava sponsor oma ressurss. Valikulülitil naaseb seda ressurssi kliendile. Klient kasutab valitud ressursi soovitud viisil.

Meie näites, diagnostika süsteem teeb mingeid aktiivsus ja tuleb alustada tööd uue sub-ülesandeid. Ta küsib ülesanne selleks, et valida järgmine sub-ülesanne töötada. Ülesanne valija saateid taotluse kõik sub-ülesandeid sponsorid, mis hindavad oma sub-ülesandeid rakendatavust praeguses kontekstis. Ülesanne valija siis kasutab neid reitinguid, et valida järgmine sub-ülesanne ning palub vastavate sponsor oma ressurss. Valikulülitil naaseb selle sub-ülesanne diagnostika süsteem, mis algab kallal valitud sub-ülesandeid

täitmine

Mitmed ühised mustreid saab kasutada rakendada komponentide Sponsor-valija struktuuris. Sponsorid võidakse rakendada Proxy muster, kuna nad seisavad koha ressursside valikuprotsessi käigus. Valikulülitil võib rakendada abil Broker muster, mis koordineerib suhtlust kliendiga ja selle tootmisest lahti ressursse. Lõpuks, kui ressursid on ise meetodid tugineda, neid saab rakendada kasutades strateegia muster.

Sõltumata sellest, kuidas komponentide struktuuris on ehitatud kolme peamist rakendamise tuleb teha otsuseid:

Kuidas iga sponsor hinnata sobivust oma ressurss? Iga sponsor tuleb kodeerida ainult kohalikke olusid silmas pidades: Kas minu ressursi asjakohane praeguses kontekstis? See ei tohiks viidata muid ressursse või muul globaalse küsimused (näiteks kliendi spetsiifiliste ajastus küsimused), kui üldse võimalik. Muidu modifitseeritavusele struktuur on langenud. Memento mustri saab transportida asjakohane riigi infosüsteemi kliendi sponsoritele.

Mida kujutab endast reiting? Olenevalt valdkonnast, sponsorid võib olla võimalik hinnata oma ressursse kvantitatiivselt pideval skaalal, nagu tegelik arv 0 ja 1 vahel, kus valija siis ühendab kasutades pidev funktsioon. Kuid kogemus paljudes valdkondades on näidanud, et sageli kvalitatiivne hinnangust rakendatavuse on kõige sobivam. Üks levinud kõnealune lähenemine on, et sponsorid hinnata oma ressursse skaalal “väga kohaldatav” läbi “neutraalne” kuni “väga tõmmata”. Kasutades kvalitatiivset pole sedasorti lihtsam ehitada valijad, et enam ligi vastavad otsused tehtud inimese ekspertide domeeni.

Kuidas valija ühendada hinnangust valida teatavat ressurssi? Valikulülitil tavaliselt kasutab hinnangust selle tagasi sponsorid selle peamine kriteerium valiku. Valijat võivad lihtsalt vali kõrgeima reitinguga ressurss, purustades sidemeid kasutades kas vaikimisi eelistus ressursse või juhusliku valiku hulgast ressursse kõrgeima reitingu. Aga see võib olla vaja rakendada globaalset teadmisega, et jääb väljapoole iga üksiku sponsor (nt võrdlusi hulgast konkreetsed ressursid). Sellistel juhtudel võib olla kasutada riigi infosüsteemi kliendi, mis on väljapoole üksikisiku sponsori otsusest.

Kaks teist rakendamisega seotud küsimusi tuleks käsitleda:

Kas valija tugineda otseselt valitud ressurss või tagastada ressurssi kliendile? Otsene appihüüd poolt valija mõttekam kui ressursse on meetodid tugineda, kuna klient võib olla valmis läbima kontrolli, et valitud meetod. Üks eelis otsest appihüüd on, et ressursse pole enam vaja on ühine liides; ainult ressursi sponsor peab teadma ressursi kasutajaliides. Sel juhul sponsorid olla adapterid vahel klient ja ressursse. Tulles ressurssi kliendile on sobivam kui ressurss mängib nii staatiline rolli (näiteks andmete poest) ja dünaamilist rolli (nagu käitumine) kliendile, kuna klient võib siis vajavad pikemaajalist interaktsioon – ja seega ühise liidese – koos ressurss.

Kas sponsor objektide võrdsustada otse ressursse? Kui sponsorlus otsused on tühised, struktuuri Sponsor-valija saab lihtsustada, lisades hinnangud käitumist ressursi objekte. See võib olla kasulik, kui hinnangud käitumist saab rakendada ülemklassi ja pärinud kõik ressursi klassid. Selline rakendamine sarnaneb Tahvel muster, kus valija rollis kontrolli objekt ja ressursi mängib rolli teadmiste allikas.

Kuidas kulukas on reitingu andmise protsessi? Arvestades, et hinnangud ressursid seda suurem, klient maksab run-time karistus selle paindlikkus. Täitja sponsori-valija muster peab olema tundlik võimalike jõudlus. Üks võimalus kasutada Sponsor-valija ees kõrge hinne kulud on kasutada “paralleelselt ressurss valik” variant on kirjeldatud allpool.

Peab ressursse oleks võimalik jagada teadmisi? Üks kuludest, mis võivad olla seotud kõrge moodulitest on raskusi jagada domeeni teadmisi hulgast ressursse, mis võib viia korrata rakendamist. Üks võimalus selle probleemi lahendamiseks on kasutada singletons ja Flyweights kodeerida teadmisega, et tuleb jagada.

Näide Lahendatud

Kasutamine Sponsor-valija muster lahendab turujõudude meie diagnostika süsteem näiteks. Luues sponsorid iga sub-ülesanne ja mis kodeerib valikut mehhanism ülesanne valija, muudatusi ülesanne süsteemi struktuur on lokaliseeritud.

Oletame, et me soovinud lisada uue sub-ülesandeid, ütlevad hüpoteesi identifitseerimise süsteemi. See sub-ülesandeid võib tähendada valides uue hüpoteesi kaaluda trumpe süsteemi diagnoosi. Programmeerija võiks teha seda lisaks süsteemi poolt:

kodeerivad sub-ülesandeid nagu uus ressurss,
kodeerib teadmisi kohalike kui tuvastada uue hüpoteesi või mitte sponsor ressursi ja
registreerida uue sponsori ülesande valija.

Nr teisi muudatusi valijat või kliendi oleks vajalik.

Kuna aga kõik muutus on lokaliseeritud ümber uus sub-ülesanne, lisaks võiks teha ka nii et süsteem ise run-time. Täitmise ajal võiks süsteemi kasutada mingi masin õppe avastada ja kodeerida uute diagnostiliste teadmisi. Kui uus sub-ülesanne on avastanud, kõik andmed, mida on vaja lisada ressursi süsteemi (mis see on ja kui see on kasulik) on loodud osana õppeprotsessi. Viimane etapp registreerida uue sponsori valitavad hõlmab vähe või ei muuda struktuuri valija ise.

variante

Mitmeid huvitavaid variante Sponsor-valija on võimalik:

Paralleelselt ressurss valikut. Iga sponsor on sõltumatu agent süüdistatakse hinnangud üksikisiku ressursi kasutatavus ja kasulikkus. Sellisena neid võib sooritata samaaegselt eraldi protsessorid, või taustal samal protsessor, samas kui teised protsessid on aktiivne. Valikulülitil Seejärel saab ellu viia, “igal algoritm,” töötlemine sponsor hinnet kui need muutuvad kättesaadavaks ja pakkuda ressurss valikut kliendi nõudmisel.

Hierarhiad Sponsor-valija mooduleid. Oletame, et üks ressurss, mis on kättesaadav klient on ise sisuliselt kogum ressursse. Näiteks andmete valideerimine sub-ülesande meie diagnostika süsteem võib olla mitmeid erinevaid meetodeid, mille abil ta saaks oma ülesannet täita. Sellises olukorras, mitmekordne Sponsor-valija mustreid saab koosseisus moodustada hierarhia.

A Hierarchy of Sponsor-Selector Modules

 

Joonis 5: hierarhia Sponsor-valija moodulid

Hierarhia Sponsor-valija mustrid annab võimaluse korraldada keeruline ressurss komplekti, nagu paljud ülesanded, sub-ülesandeid ja meetodeid suur süsteem, nii et soodustab süsteemi modifitseeritavusele nägu muutus.

tuntud Kasutab

Esimene dokumenteeritud kasutamisest Sponsor-valija oli DSPL (Brown ja Chandrasekaran’i, 1986), mis kasutas muster mehhanismi valides disain plaanid süsteem, mis mõeldud õhu silindrite lennukit. Mehhanism võeti kest hoone teadmistepõhise süsteemid, mis teevad “rutiinne disain”, kus palju või kõik disaini ülesanne on saavutatav läbi, kasutades selleks eelnevalt loetletud disaini ja ümber kujundada plaane.

TIPS (Punch ja Chandrasekaran’i, 1993) üldistab Sponsor-valija arvesse mehhanismi tegemise dünaamiline kontroll otsuseid sub-ülesandeid. Punch on taotlenud TIPS ehitamisel meditsiinilise diagnostika ekspert süsteemi.

VIGA-II (Benjamini 1993) läheb edasi, kasutades Sponsor-valija muster kui taotluse alusel raamistik dünaamiliselt valides teostamise meetod iga sub-ülesande selgelt esindatud ülesanne struktuure.

IPCA (Decker et al., 1994) kasutab Sponsor-valija alusena kontrolli kava valiku ja täitmise süsteem, mis kontrollib mikrolaine komposiitmaterjalide töötlemine pehme reaalajas keskkond.

Goel ja tema kolleegid (1994) on kasutatud Sponsor-valija dünaamilise meetodi valikut navigatsiooni planeerimine mobiiltelefoni robotid. Katsed selles valdkonnas kinnitavad, et Sponsor-valija on hea ideelahendus olukordades, kus klient taotluse õppida uusi kontrolli teadmisi. Kuna planeerija omandab domeeni teadmisi, Sponsor-valija võimaldab agent lisada uusi teadmisi dünaamiliselt selle probleemi lahendamise ja valida meetod, mis näitab, et teadmised. Planeerija on kehastunud füüsilises robot, mis näitab selle tulemuslikkust plaanid.

Landauer ja Bellman (1995) on välja pakkunud uue tehnika arendamise, integreerides ja juhtima keerukaid tarkvara, mis põhinevad idee väga sarnane sponsor valija muster. Nende tehnikat kasutab kahte tüüpi komponent, ümbris ja juhid. Ümbris on kvalitatiivne informatsioon süsteemi komponenti: kuidas kasutada komponent, millal ja miks seda kasutada, ja mis kombinatsioone saab neid kasutada. Juhid on algoritme, et valida ja kombineerida komponendid teabe põhjal nende pakendid. See meetod ulatub Sponsor-valija taotleda kõik komponendid süsteemis üldse korda.

tagajärjed

Paljud tagajärgi, mis tulenevad kasutamise strateegia tuleneda ka kasutades Sponsor-valija. Sponsor-valija pakub järgmisi eeliseid:

Suur moodulitest. Ressursse saab lisada, muuta või reimplemented see ei mõjutanud teiste vahenditega või kliendi kood. Ainult ressursi sponsori tuleb muuta. Juhul uue ressursi, kui valijat muuta ainult selle poolest, et uue sponsori tuleb registreerida see.

Otsuse kontrolli selgesõnaliselt ja sõltumatu teistest süsteemi komponendid. Sponsor-valija veelgi parandab strateegia muster lahkumineku meetodi ja kliendi edasise lahtisidumise valikut ConcreteStrategy kontekstist. Strateegia jätab kliendile töö valides sobiva ConcreteStrategy et algväärtustan kliendi. See võib tekitada segadust kliendile täiendavaid andmeid uurimine koodi, teadmised, mis ei ole osa kliendi esmane ülesanne (seega hägustumas selgus tema esitus) ja kohmakas kontrolli avaldused.

Sponsor-valija paneb ka mõned puudused:

Potentsiaalselt tihe sidestus Kliendi ja valija. Tõmmates kõik valikut teadmisi läbi klient võib olla rumal. Valik teadmised võivad olla nii kontekstist sõltuv, et see oleks (1) ei ole korduvkasutatavad eraldi objekti ja / või (2) lihtsam väljendada otse kliendile, sest suure hulga informatsiooni võib osutuda möödunud kliendi valija.

Potentsiaalselt tihe sidestus valija ja toetajad. Sponsor valija muster võib olla asjakohane, kui sponsorid peavad arvestama teadmisi suhtelise kvaliteedi nende meetodid “lahendusi konkreetses kontekstis või globaalse piiranguid panna ressurss. Näiteks kui on ülemaailmne piire panna aeg arvutamise ressurss, see võib olla raske ehitada kohalik sponsor võimeline tegema selliseid teadmisi arvesse.

Üks võimalus tegeleda nende potentsiaali sidurid on kasutada Observer muster mehhanismi, mis võimaldab valijad ja toetajad vaatamiseks välise kontekstis teavet ilma kodeerib konteksti need komponendid.

Kulude inDirection raske reaalajas keskkond. Decker (1994) on väitnud, et tähtajad on seotud raske reaalajas töötlemise võib tekitada probleeme sponsor-valija arhitektuuri. Juhul, kui kulud inDirection ja hinnangud ületada olemasolevaid ressursse, et süsteem, Sponsor-valija võib olla sobimatu muster.

Vaata ka

Nagu eespool kirjeldatud, Sponsor-valija võib lisada palju funktsioone Broker, Proxy ja strateegia mustrid. Mementos, vaatlejad, singletons ja Flyweights võib kasutada, et lahendada mõned probleemid, mis tekivad siis, kui rakendatakse Sponsor-valija.

Sponsor-valija on sarnane Tahvel muster oma lahtisidumine kontrolli vahenditest, mis sisaldavad süsteem. Aga Sponsor-valija lisab ekstra paindlikkust lahutades veel teada, kui teadmiste allikas on kasulik (sponsor) teadmisest allikas ise (ressurss). Selline paindlikkus saab realiseerida lisades eraldi kihina süsteemi arhitektuuri.

Klient-dispetšer-Server Samuti meenutab Sponsor-valija oma lahtisidumine kliendi vahenditest, mis aitavad seda. Aga Sponsor-valija veelgi ette nähtud, et teadmised, kui teadmiste allikas on kasulik lahti siduda teadmised, mis ressurssi kasutada igal ajahetkel. Klient-dispetšer-Server muster ei kohustu selles osas. Mõlemad Sponsor-valija ja Klient-dispetšer-Server võib vaadelda arhitektuursed vormid kaudne appihüüd (Notkin et al., 1993), ettekujutuse, mida saab rakendada ka tasemel üldotstarbeline programmeerimiskeeli.

Kui võtta tasemele ümbris (Landauer ja Bellman, 1995), Sponsor-valija saab vaadelda rakendamise mehhanismi Reflection muster. Sponsor-valija annab vahendid, mille abil süsteem võib peegeldada kohta oma sub-ülesandeid ja meetodeid ning vali vahendeid, kui nad on kõige kasulikum saavutada süsteemi eesmärke. Lisaks Sponsor-valija võimaldab süsteemi täielikult integreerida uusi vahendeid run-time säilitades oma võimet peegeldada nende kohta.

Tänusõnad

Varasem versioon see muster ilmunud PloP’96. Shepherd Chris Landauer esimene soovitas suhet Sponsor-valija ja ideed pakkimine ja kaudsed appihüüd. Tänan liikmed PloP’96 töörühm 4 nende väärtusliku kriitikat ja parandusettepanekuid. Frank Buschmann, Eric Hughes, ja Peter Sommerlad olid eriti kasulik, andes põhjaliku kirjalikke märkusi minu paber. Lõpetuseks tänan Bobby Woolf, kelle läbimõeldud kommentaarid aitas mind mõtlema, kuidas lugejad väljaspool domeeni teadmisi süsteemide võiks tõlgendada minu muster.

viited

Benjamini, Richard. Probleemi lahendus Diagnoosimismeetodid. Ph.D. Lõputöö, Amsterdami Ülikool, 1993.

Pruun, David ja B. Chandrasekaran’i. Teadmised ja Tõrje mehaanilise Design Expert süsteem. IEEE Computer, 19: 92-101, juuli 1986.

Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter Sommerlad ja Michael Stal. Muster orienteeritud tarkvara arhitektuuri. John Wiley and Sons, New York, 1996.

Decker, David, Bill Punch, Jim McDowell ja Jon Sticklen. Arukat juhtimist Arhitektuur mikrolaine Fabrication komposiitmaterjalide põhjal Generic Task lähenemisviisi teadmistepõhise Systems. In Proceedings of the AAAI Fall sümpoosion Intelligent Systems, New Orleans, november 1994.

Gamma, Erich, Richard Helm, Ralph Johnson ja John Vlissides. Design Patterns. Addison-Wesley, New York, 1995.

Goel, Ashok Khaled Ali, Michael DONNELLAN, Andres Gomez ja Todd Callantine. Multistrategy Adaptive Navigatsiooniseadmed Path planeerimine. IEEE Expert, 9 (6): 57-65, detsembrit 1994.

Landauer, Christopher ja Kirsti Bellman. Teadmistepõhine Integratsiooni infrastruktuur Complex Systems. TAC tehniline aruanne, 1995.

Notkin, David, David GARLAN, William G. Griswold ja Kevin Sullivan. Lisades Kaudsed invokatsiooni Keeled: kolm lähenemist. In Proceedings of the objekt Technologies for Advanced Software konverents, Springer-Verlag, Berlin, 1993.

Punch, Bill ja B. Chandrasekaran’i. Uurimise rollide probleemide lahendamise meetodid diagnoosi. Teise põlvkonna Expert Systems, Ed. poolt Juan Manuel David, J.-P. Krivine ja R. Simmons. Springer Verlag, Berlin, lehekülgi 673-688, 1993.

Punch, Bill, Ashok Goel ja David C. Brown. Teadmistepõhise valik Mechanism for Strategic Control Application Design, montaaž ja planeerimine. International Journal of Artificial Intelligence tööriistad, 4 (3): 323-348.

 

Comments are closed.