Yazılımlar arası Kural Dıı Durumları leme için Etmen Tabanlı bir Yaklaım *

Yazılımlar arası Kural Dıı Durumları leme için Etmen Tabanlı bir Yaklaım * Albert ÖZKOHEN 1 Pınar YOLUM 2 1,2 Boaziçi Üniversitesi, Bilgisayar Mühendislii Bölümü, Bebek-stanbul 1 e-posta: aozkohen@elitsoft.com.tr 2 e-posta: pinar.yolum@boun.edu.tr Özet Bu makale yazılım mühendisliinde oluabilecek kural dıı durumları katılımcıların oluturdukları taahhütlerin ihlalleri olarak modellemeyi önermektedir. Katılımcılar etkileimlerinden sonuç çıkarabilen ve dier etmenlerle haberleebilen akıllı etmenler olarak modellenmitir. Etmenler arası haberlemeler taahhütler olarak gösterilmektedir. VE/VEYA aaçları kullanılarak çok katılımcılı taahhütler daha küçük, az katılımcılı taahhütlere bölünebilir. Buna ek olarak taahhütlerde bahsedilen durumlar ve durumlar arasındaki ilikiler bir OWL ontolojisiyle gösterilmitir. VE/VEYA aaçlarını ve OWL ontolojisini kullanarak etmenler kural dıı durumların çaresine bakabilir ve bazı durumlarda kural dıı durumları, daha olmadan, fark edebilirler. Önerilen yöntem, yazılım mühendisliine sıkça konu olan tedarik zincirlerine uygulanmıtır. Abstract This paper proposes to model exceptions in software engineering as violations of commitments of participants. The participants are represented as intelligent agents that can reason about their interactions and communicate with other agents. The communications of the agents lead to creation and manipulation of commitments. Commitments that involve several participants are broken into smaller commitments using AND/OR trees. Further, the commitment conditions and their relations are captured in an OWL ontology. By reasoning based on the AND/OR tree and a given ontology, agents can handle exceptions when they occur and in some cases even detect exceptions before they take place. 1. Giri Yazılım mühendislii etkin, verimli ve daha önemlisi emniyetli yazılımlar tasarlamayı ve gelitirmeyi hedefler. Oysa birçok pratik çalıma, gelitirilen yazılımların hemen hemen hiçbir zaman istendii ekilde hareket etmediini, deiik zamanlarda kural dıı durumların ortaya çıktıını göstermektedir. Gelitirilen yazılımlar, baka yazılımlarla haberleme içerisinde veya baka yazılımlara ilevsel olarak balıysa kural dıı durumların oluma ihtimali de artar [1]. Genelde, yazılımlara karılaabilecekleri kural dıı durumlar ve bu durumların nasıl giderilecei bilgisi verilmise, sistemler belirtilen çözümleri uygulayarak kural dıı durumdan, kurallara uygun bir duruma geçebilirler. Hâlbuki birçok kural dıı durum önceden kestirilemez. Burada yazılımın alt kademelerinde oluan kural dıı durumlar (sıfıra bölme gibi) deil, daha üst seviyelerde olan (bir

üretici firma otomasyon yazılımının müterilere doru fiyatı göndermemesi gibi) kural dıı durumlar düünülmektedir. Bu tür kural dıı durumları ilemek için, yazılımların önce bir sorunun varlıını, sonra sorunun nereden kaynaklandıını, sonrasında ise sorunun çözümünü, kendi balarına (yazılımı gelitiren kiilerin müdahalesi olmadan) bulmaları gerekir. Kural dıı durumları bu ekilde ileyebilmek için yazılımların zeki ve inisiyatifli olmaları arttır. Bunu salayabilmek için bu bildiri, yazılımları algılayan, sonuç çıkaran, buna balı olarak hareket edebilen ve dier yazılımlarla iletiim kurabilen özerk etmenler olarak modellemeyi önermektedir [2,3]. Böylece, etmenler sadece sıralı ilemleri icra etmeyecek, aynı zamanda kendi ilemleri hakkında çıkarsamalar yapabileceklerdir. Baka bir deyile etmenler çalımalarındaki kural dıı durumları algılayıp bunları çözümlemek için yöntemler gelitireceklerdir. Örnek uygulama alanı olarak, yazılım mühendislii problemlerine sıkça konu olan tedarik zincirlerinin otomasyonunu alalım [2]. Tedarik zincirleri müteriler, tedarikçiler, ulaım salayıcılar, fabrikalar, depolama birimleri gibi bileenlerden oluur. Tedarik zincirlerinin otomasyonu ise bu birimlerin fonksiyonlarının bir yazılımla takip edilmesi ve ilevlerinin bir kısmını otomatik ya da yarı otomatik yapmaları anlamına gelir. Bu birimler birbirleriyle sıkça habe 1 rletii ve bir çok ilevleri birbirlerine baımlı olduu için kural dıı durumların oluması hayli mümkündür. Yapılan çalımalarda, eer doru ekilde müdahale edilmezse, tedarik zincirinde oluan kural dıı durumların irketlerde zamansal ve parasal kayıplara yol açabildiini göstermitir [4]. Kural dıı durumlar verimlilik, maliyet artıları, müteri tatmini ve kalite yönetimi gibi çeitli boyutlarda karımıza çıkmaktadır [5]. Tedarik zinciri yönetimini otomasyon altına almak için çeitli yaklaımlar vardır. Fakat bu yaklaımlardan hiçbirisi bugüne kadar tedarik zinciri operasyonlarında oluabilecek kural dıı durumları otomatik olarak yakalayıp çözemez. Tedarik zinciri yönetim sistemlerindeki kural dıı durumların otomasyon yoluyla ilenmesi ile ilgili halen süregelen aratırmalar bulunmaktadır [5,6,7]. stisnaların ilenmesi, tanımlı ve genileyebilen kural kümeleri altında karmaık çıkarsama faaliyetleri gerektiren bir süreçtir. Mevcut durumda, kural dıı durumlar çalıan profesyonellerin beyin gücü kullanılarak halledilmektedir. Bu kiiler mevcut tedarik zinciri yönetim araçlarını kullanmaktadırlar. Fakat bu sonuç pahalı ve verimsizidir, zira insana dayalı operasyonlar otomasyon yaklaımına göre daha zaman alıcı ve hataya açıktırlar. Bu bildiri u ekilde devam etmektedir: Bölüm 2 kural dıı durumların taahhütler ve VE/VEYA aaçları kullanarak modellenmesini anlatır. Bölüm 3 tedarik zinciri uygulamalarında oluabilecek senaryoları anlatmak için kullanılabilecek bir ontoloji gelitirir ve yazılımların bu ontolojiyi nasıl kullanabileceklerini anlatır. Bölüm 4 bu bildiride gelitirilen metodu dier aratırmalarla karılatırıp, tartıır. Buna ek olarak, Bölüm 5 ifade edilen fikirleri birletirip, taahhütlerin VE/VEYA aacı eklindeki gösterimini ve bir bilgi tabanı oluturmak amacıyla taahhütler arasındaki çıkarsamaya yardımcı olacak bir ontolojiyi sunar. 2. Kural Dıı Durumların Modellenmesi Tedarik zinciri sistemlerinde çok çeitli kural dıı durumlar oluabilir. Huhns ve öbürleri [5] kural dıı durumları sınıflara ayırmılardır. Bu gruplar, son günlere uyulmaması, ürün tanımları, ödemeler, sevkıyatlar, depolama seçenekleri, sipariler gibi farklı sınıflarda oluturulabilir. Bunlar birbirinden tamamen baımsız ya da birbirini karılıklı dıarlayan sınıflar deildirdirler. Bir kural dıı durum birden fazla sınıfa ait kural dıı durum olabilir. Örnein bir siparite bir kural dıı durum yanlı ürün tanımından dolayı oluabilir, bu da depolama sorunu oluturabilir. Tüm bu sınıfları 1 Bu çalıma Boaziçi Üniversitesi Aratırma Fonu (BAP05A104) tarafından desteklenmektedir.

tanımlamak için ontoloji adını verdiimiz bir bilgi altyapısı kullanmaktayız. Ontoloji kural dıı durumları modellemek için önerdiimiz taahhütlerin arasındaki balantıları tanımlamaya yardımcı olacaktır. Bu kural dıı durumları ve sonuçlarını bulgu-tehis-reçete zinciri eklinde n-ayaklı aaç türü yapılarla gösteriyoruz. Böylece içerik gösterimi için bir altyapı oluturabiliriz. Bu gösterime kısaca taksonomi denir [6]. Burada tehis seviyesi özel bir önem hak etmektedir; zira tehis içerie balı olarak deiiklik gösterebilir. Hareketler de içerik-baımlı olup taksonomimizdeki (ya da aaç yapımızdaki) seviyeyle dorudan ilgilidir. stisna sınıflarında gruplanabilecek kural dıı durumlar önceden tanımlanmı bir hareket kümesini (hareket planı) iç çıkarsama amacıyla tetiklerler. 2.1. Taahhütler Kural dıı durumları anlayabilmek için önce kurallara uygun durumları göstermek gerekmektedir. Veritabanı aratırmalarından yola çıkarak, etmenlerin aralarındaki iletiimleri taahhütler (commitments) olarak gösteriyoruz. Örnein, bir üreticinin alıcı firmaya ürünü 3 Haziran a kadar teslim edeceini taahhüt etmesi yazılımlar arasında beklenen ve istenen bir iletiimi göstermektedir. Bu taahhüdün edildikten sonra yerine getirilmemesi ise kural dıı bir durum yaratacaktır. Bu sebeple, etmenler arası iletiimi taahhütlerle göstermeyi ve taahhütlerin yerine getirilmedii durumları da kural dıı durumlar olarak kabul ediyoruz. Taahhütler, bir veri yapısı eklinde düünülebilir [8]. Bu yapıda borçlu taraf, alacaklı tarafın lehine bir koulu zaman dolmadan yerine getirmekle sorumludur. Bu taahhüt aaıdaki notasyonla gösterilebilir [9]: T (borçlu, alacaklı, koul, zaman) Taahhüt yaratıldıında borçlu taraf, alacaklı taraf lehine koulu belirtilen zaman dan önce yerine getirmekle mükelleftir. Koul doru olunca, taahhüt baarıyla sonlandırılır. artlı taahhüt [9] resme bir ön art ekler. artlı taahhütler iki tarafın birbirlerine karılıklı taahhütte bulunmalarını gerektirir. Bu oluumda borçlu taraf bir koulu alacaklı taraf lehine eer bir önkoul yerine getirilirse taahhüt etmektedir. Bunu aaıdaki ekilde gösterebiliriz: T (borçlu, alacaklı, önkoul, koul, önkoul zamanı, koul zamanı) Yani, böyle bir artlı taahhüt yapan borçlu, alacaklının önkoul zamanına kadar önkoulu yerine getirdii takdirde, koulu koul zamanından önce yerine getireceini taahhüt eder. Taahhütler etmenler (insan ya da yazılım) arası iletiimin her evresinde mevcuttur. Taahhütler, etmenlerin faaliyetleri (dı dünyayla etkileimleri ya da birbirleriyle mesajlamaları) sonucunda yaratılırlar. Örnein, bir tedarik zinciri üzerinde bir üreticinin mallarını 50 YTL den sattıını belirtmesi aslında, 50 YTL veren ilk bireye malını vereceini taahhüt etmesi anlamına gelir. Yaratılan taahhütler zaman içersinde yerine getirilebilir (discharge), gözden geçirilebilir, iptal edilebilir, vb. Bu bildirinin ana konusu olan kural dıı durumları çalımak için yerine getirilen taahhütlerle, yerine getirilmeyen taahhütleri birbirlerinden ayırabilmek yeterlidir. Taahhütlerin yerlerine getirildii durumda beklenmedik, kural dıı bir durum gerçeklemez. Bu sebeple kural dıı durumları fark etmek için taahhütlerin yerlerine getirilmedii durumları tespit etmek gereklidir. Biraz önceki örnekten devam edersek, bir alıcı 50 YTL ödemesine karın, satıcı taahhüdünü yerine getirmezse (ürünü alıcıya vermezse) beklenmedik, kural dıı bir durum olmu demektir. Dolayısıyla yukarıda açıklandıı ekliyle taahhütler i iletiiminde önemli bir role sahiptirler. Bu yüzdendir ki, kural dıı durumların taahhütler (ya da taahhüt ihlalleri) yoluyla modellenmesi i iletiiminin doal sonucu olarak önümüze çıkmaktadır.

2.2. VE/VEYA Aaçları Birçok zaman yazılımlar arası olan taahhütler daha küçük taahhütlere bölünebilir. Örnein, bir üreticinin bir alıcıya belirli bir ürünü 15 gün içinde teslim edeceini taahhüt etmesi aslında (1) üreticinin 15 günden önce ürünü hazır edecei ve (2) üreticinin hazır ettii ürünü postaya zamanında verecei anlamına gelir. Bu ekilde daha basit taahhütlere bölünebilen taahhütleri, VE/VEYA aaçlarıyla [10] göstermeyi öneriyoruz. Aaçtaki her düüm, bir ii modelleyen bir taahhüt içerir. hayatında iler alt-ilere bölünebilir. Baka bir deyile bir ii baarılı bir ekilde bitirebilmek için onu oluturan alt-ileri bitirmek gerekir. Bu olayı da taahhütleri (yani olayları) alt-taahhütlere (yani alt-olaylara) bölerek modelliyoruz. Her alt-taahhüt yukarıda tanımlandıı gibi normal bir taahhüttür. Ancak alt-taahhütler bir araya gelerek üstteki ana-taahhüdü olutururlar. Alt-taahhütler aralarında mantıksal VEYA (OR) ya da mantıksal VE (AND) ilemleriyle balı olabilirler. Bu yüzden VE/VEYA aaçlarını alanı göstermek amacıyla kullanıyoruz. Sistem tanımlama safhasında, taahhütler VE/VEYA aacını oluturmak içi uygun ekilde girilmeli ve iaretlenmelidirler. Bu bölünme faaliyeti taahhütteki tüm borçlu ve alacaklı tarafların çoklu-etmenli sistemimizin sınırları içerisinde kaldıı sürece devam edebilir. Eer taahhüdün baarılı ya da baarısız bir ekilde bitmesi algılanamayacaksa bu borçlu ve alacaklı taraflar için taahhüt tanımlanamaz. Böylece taban seviyesinde bulunan bir taahhüdün baarılı bitiini ya da baarısız bir bitii ile kural dıı duruma yol açtıını algılayabiliyor ve dolayısıyla onu düzenleyecek hareket planı için gereken çıkarsamayı kurabiliyoruz. VE/VEYA aacını kullanmanın ana amacı, kural dıı durumları modellerken edimlerini yerine getirmeyen taahhütleri arayıp bulmak ve böylece uygulanması gereken doru hareket planını uygulamaktır. Yukarıdaki örnekte eer sevkıyat olmadıysa, düzeltici hareket olarak yeniden sevkıyat istemek yine aynı kural dıı duruma sebep olabilir. Fakat daha fazla aratırıp, kural dıı durumun sürücüden dolayı olutuunun bulunması, bu sefer sevkıyatı kargo irketiyle yapmamızı salayacaktır (VEYA OR balantısı). Sistem balangıç kural konfigürasyonu ile çalımaya balar. Uygulama esnasında sistem her kural dıı durum oluumunda paralel bir yapı yaratır ve VE/VEYA aacının içinde arama yaparak tam olarak uyumsuzluk yapan düümü bulur. 2.3. Kural Dıı Durumları zlemek Tüm taahhütleri kalıcı olarak zaman aımı deerleriyle kayıt etmek olasıdır. Verimlilik ve doruluk amacıyla, tüm taahhütleri merkezi bir veri havuzunda tutuyoruz. Bu veri havuzunu izleyen etmen (MA) olarak adlandırdıımız bir etmen yönetmektedir. MA tüm taahhütlerin zaman aımı verip vermediini denetler. Eer bir taahhüt zaman aımına uradıysa, bu durum burçlu (sorumlu) tarafın edimini yerine getirmedii anlamına gelir, aksi takdirde MA konu ile ilgili bir ileti almalıydı. Bu durumda MA taahhüdün alacaklısına borçlunun baarısız olduuna dair ileti gönderir. Eer bu taahhüdün yerine getirilmemesi baka taahhütleri de yerine getirilemez kılıyorsa bu taahhütlerin de alacaklıları haberdar edilir.

ekil 1. Sevkıyat senaryosu çerçevesinde kural dıı durumların modellenmesi 2.4. Örnek Yukarıda resmedilmi örnei varsayalım. Örnek çeitli malların göndericiden alıcıya sevk edilmesi sürecini seçenekli yöntemlerle modellemektedir: 1. Aaıdaki taahhüdün Varı zamanı zaman aımı deeriyle yaratıldıını varsayalım. C sevk =T (Gönderici, Alıcı, Mal-Gönder, Varı zamanı) Bu parametre baarılı bir biçimde görevin yerine getirilip getirilmediini kontrol edecektir. Eer taahhüt normal yollardan yerine getirilmezse, otomatik olarak Gönderici Mal-gönder yüklemini yerine getirmemi sayılacaktır ki bu da bir kural dıı duruma yol açmaktadır. 2. Daha sonra MA (bkz Bölüm 2.3) C sevk taahhüdünü yaratılmasının hemen ardından kaydeder. 3. MA Alıcı etmenden taahhüdün yerine getirilip getirilmedii ile ilgili bilgi ya da ileti bekler. 4. Eer Alıcı etmenden uygun yanıt gelmez ve bu arada da Varı zamanı dolarsa, o zaman MA Gönderici etmenin edimini yerine getirmediini anlar ve Alıcı etmeni bu sorundan haberdar eden bir ileti gönderir. 5. Edimin yerine getirilmedii durumu daha iyi anlayıp inceleyebilmek için C sevk taahhüdü (ya da en son bilgisi gelen kural dıı durum) balantılı alt-taahhütlere bölünebilir. C sevk = C 1 ^ C 2 öyle ki C 1 =T(Gönderici, Kargoirketi, YüklemeYap, t 1 ) ve C 2 =T (Kargoirketi, Alıcı, YükTaı, VarıZamanı) ve t 1 < VarıZamanı 6. Seçenekli olarak (ekil 1 deki ana OR dallanması) aaıdaki bölünmeyi de yapabiliriz. C sevk = C 3 ^ C 4 öyle ki C 3 =T (Gönderici, Sürücü, YükVer, t 1 ) ve C 4 =T (Sürücü, Alıcı,YükTaı, VarıZamanı) ve t 1 < VarıZamanı 7. Son olarak ekil 1 i daha iyi ve anlaılır bir gösterime ulamak amacıyla çizdik. Her taahhüt bir alttaahhüde, borçlu ve alacaklı etmenle etmen topluluuna dâhilse, bölünebilir. 8. Önerilen yapının sonucu VE/VEYA aacıdır. Bu aaç ayrıntılarıyla [10] da anlatılmaktadır. Bu yapıda yapraklar en son bölünebilen kural dıı durumlardır. Bu yapraklardaki kural dıı durumlardan düzeltici hareket planlarına ulamak mümkün olmaktadır.

2.5. VE/VEYA Aacının lenmesi Yapıya bir düüm (taahhüt) eklemek için, eklenecek düümün aaçtaki seviyesini ve karde düümlerle olan ilikisini (AND ya da OR) bilmeliyiz. Gerisi genel bir aaca düüm ekleme algoritmasıdır. Düüm silmek için, düümün aaçtaki tam yerini belirtmek yeterlidir. Sistem silinen düümün karde düümü olup olmadıını kontrol edecek, duruma göre alt-düümü olmayan baba-düümü yaprak-düümü olarak iaretleyecektir. Aaçta herhangi bir düümün yerini deitirmek ise önce eskiyi silip daha sonra yeniyi girmek eklinde olacaktır. Yaprak düümü taban seviyesinde bir düüm içerir. Etki alanı içerisinde daha fazla bölünme burada mümkün deildir. stisnaları ilemek için gerekli tüm hareketler ve planlar yaprak düümlerde bulunan taahhütlerden balatılacaktır. Aaç duraan olmayabilir. Sisteme her yeni düüm (taahhüt) eklendiinde istisnaların modeli deiecektir. Hangi durumlarda hangi düümlerin eklendii kodlanabilir. 3. Kural Dıı Durumları Belirlemek için Ontoloji Kullanımı Bilinen bir ontoloji dili olan OWL kullanarak bir kural dıı durum ontolojisi gelitirdik [11]. Bu ontoloji kural dıı durumlar arasındaki benzerlikleri ve dier ilikileri yakalamasını ve böylece sistemin benzer kural dıı durumlar için benzer reçeteler hazırlamasını salar.. Bu ontolojinin bileenleri Bölüm 5 tedir. Bu ontoloji kurallarla birletirilerek çıkarımlar yapmaya elverili hale gelir. Çoklu-etmen sistemimize gelen girdi hangi taahhüdün baarısız olduuna dair hiç bir bilgi içermeyebilir. Sistemin kullanıcıları kural dıı durumları belki de zaman aımı olmadan önce bile algılama gereksinimi duyabilirler. Bu durumda eer ontoloji yeterli olacak ve olası kural dıı durumları yakalayabilecek ekilde tasarlanmısa bu ontoloji ile ilgili örnekler veren bir veri kümesi, taahhütlerle yakalanamayacak kural dıı durumları yakalamamızı salayabilir. Bu sonuca, ontolojide sunulan kurallar üzerinde yapılacak akıl yürütme (çıkarsama) yoluyla ulaılacaktır. Bu durumda bazı taahhütlerin gelecekte ihlal edilmi olacaını önceden kestirmek mümkün olacaktır. Bu sistemdeki dier etmenler ya da ihlal edilecek taahhütteki alacaklı konumda bulunan taraf böylece sorunu giderici ya da düzeltici alternatif hareket planlarını çaırabilmek için zaman kazanacaktır ki bu da verimlilii ciddi ölçüde arttıracaktır. ekil-1 deki örnekle ilikili bir çıkarsama ve sonucu aaıda verilmitir. Kamyonla sevkıyat yapılan bir durumu ele alalım. Bu durumda sevkıyat yolu üzerinde bulunan bir etmenden bir ileti ya da bilginin alacaklı etmen tarafından düzenli abonelik yoluyla alındıını varsayalım. Bu durumda yollarda kazalarla ilgili bilgiler kaza olduu anda elektronik yoldan tüm abonelere ulamaktadır. Böylece MA etmeni (bkz Bölüm-3) bu durumu önceden belirlenmi bir biçemde alabilmekte ve daha ilgili taahhüdün varı zamana sona ermeden sorun olabileceinin çıkarsamasını yapabilecektir. Çoklu-etmen sistemimize gelen bu bilgi, yükümüzü taıyan sürücünün izledii yolla ilgili olabilir. O zaman çıkarsamamız öyle olacaktır: Ontolojide tanımlı olgular: - Sevkıyatı sürücüler yapar. - Sürücüler kamyon kullanır. - Kamyonlar çalıır ya da durmu halde olabilirler. Ontolojide tanımlı kural: - Eer bir kamyon durmu ise sürücüsü onu süremez. - Bir sevkıyat, sürücüler ilgili kamyonu süremediklerinde iptal olur.

Bu tip çıkarsamalar için çeitli kural-tabanlı otomatik çıkarsama sistemleri, tanımlanmı ontolojiden üretilen nesneler üzerine uygulanarak elde edilebilir. 4. Tartıma ve Sonuç Yukarıda uygulanan örnekler tedarik zinciriyle alakalı olmakla beraber gelitirilen yöntem geneldir ve baka uygulamalarda da kullanılabilir. Tabii ki uygulamaya balı olarak baka bir ontoloji kullanılması ya da gelitirilmesi gerekecektir. Fakat bunun dıında kullanılan, taahhüt ve VE/VEYA aaçlarının yapılarında bir deiiklik olmayacaktır. Endüstri ile olan birebir balantısından dolayı tedarik zincirleri yazılım mühendisliinde çok ilgi çeken bir alandır. Tedarik zinciri otomasyonunda ve tedarik zinciri kural dıı durumlarının ilenmesinde çeitli yaklaımlar izlenmitir. Huhns ve öbürleri tedarik zinciri yönetiminde gerekecek egüdümü modellemek için dilbilim örnekleri kullanmaktadırlar [5]. Öncelikle etkileim emaları gelitirdiler. Daha sonra use case modeli ile etmenler arası konumayı belirlediler. Oradan da Dooley çizgelerini elde ettiler. Son olarak da sonlu otomat ları ina ederek gerekli etmen ana iskeletlerine ulatılar. Bu sıra, olaan tedarik zinciri yönetimi için bir üretim zinciri oluturmak gibi görünmektedir. Ancak kural dıı durum ilenmesi bu süreçte yalnızca dikkat atfedilen bir adım olarak kalmıtır. Yazarlar, kural dıı durum sınıflarını tanımlamılar ancak kural dıı durumlarla baa çıkabilmek için saladıkları katkı yetersiz kalmıtır zira taahhütler bir taksonomi çerçevesinde ayrıntılı olarak belirtilmemitir. Hatta kavramları tanımlayacak ve kavram sözlüü gibi kullanılabilecek ontoloji türünde bir araç da önerilmemitir. Fox ve öbürleri tedarik zincirlerini akıl yürütebilen ve baımsız davranabilen akıllı yazılım etmenleriyle modeller [2]. Fox ve öbürlerine göre, etmen tabanlı bir yapı kullanılınca, tedarik zinciri yönetim sisteminin dinamizm, çıkarsama, yanıt vericilik, ibirliine hazır ve geriye dönük uyumluluk içerme, etkileimlilik ve uyarlanırlık özellikleri vardır. Kolayca görülmektedir ki, bu özellikler sadece geleneksel tedarik zinciri yönetimi için deil, aynı zamanda tedarik zincirlerinde oluabilecek kural dıı durumlarda da geçerlidir. Fakat, Fox ve öbürleri tedarik zincirlerinin etmenlerle modellemenin ilerisinde, kural dıı durumları ilemek için bir yöntem gelitirmemilerdir. Dellarocas ve Klein [6] da dilbilim modeli yerine bir bilgi tabanı yaklaımı önermektedirler. Bu çalıma kural dıı durumlarla ilgili çalımalar için daha kuvvetli bir yaklaım içermektedir. Taksonomi n-bacaklı bir aaçtır. Ancak bu aacın çocuk-düümleri arasında herhangi bir iliki düünülmemitir. Üstelik çocuk-düümler (alt-taahhütlerin bulunduu) ile baba-düümler arasında da herhangi bir iliki mevcut deildir. Kalakota ve öbürleri tedarik zinciri mimarisini duraandan (statik) hareketliye (dinamik) taımaktadırlar [12]. Bunu çoklu-etmen ortamı kullanarak yapmaktadırlar. Müterilerden, perakendecilerden, daıtım merkezlerinden ve üretim tesislerinden tarihsel verileri toplayarak, karar vermede kullanmak üzere bilgi tabanını bu toplanmı bilgilerden oluacak duraan bir altyapı ile kullanmak yerine, tüm bilgiyi yerel etmenlerde hareketli (dinamik) olarak tutup daha küçük zaman aralıklarında daha sık ve hızlı kararlar vermeyi hedeflemilerdir. çsel ilemlerdeki varsayımları her etmenin kendi hakkında karar verme yetisine balı olarak istatistiksel metotlarla belirlenmektedir. Yazarlar, tedarik zinciri ile ilgili bir ontoloji de önermektedirler ancak kural dıı durum yönetimi için çok fazla önerileri yoktur. Frey ve öbürleri [13] sisteme ek bir özellik önermilerdir. Bu da çeitli ve baımsız çoklu-etmenli sistemin, üst seviyeli bir topluluk oluturmak amacıyla tümletirilmesidir. Yazarlar bize çokluetmen altyapısının küresel/esnek ve yerel/özerk i ihtiyaçları için mükemmel olarak uygunluunu göstermilerdir. Bu sistemlerde rekabet ve birlikte çalıma kavramları birbirlerini rahatsız etmeden

birlikte bulunabilirler. Yazarlar zaten mevcut ya da gelitirme altında olan çoklu-etmenli projeler kullanmaktadırlar. Her çoklu-etmen sistemi, müzakere, süreç planlama, üretim planlama ve denetimi gibi farklı görev sınıflarından sorumludur. Yazarların çalıması bu alt sistemlerin arasındaki etkileimi ve tümletirmeyi tanımlar. Ancak tüm zamanlama, izleme, güvenilirlik ina etme çabalarına ramen kural dıı durumlar dikkate alınmamıtır. Bu da tedarik zinciri yönetiminde kural dıı durumlar için özel ilgi ve çabanın gerekliliini ortaya koymutur. Sonuç olarak, yazılımlar arası kural dıı durumların otomatik olarak önlenebilecei ve düzeltici durumlarla ilgili hareket planlarına ulaılabilecei gösterilmitir. Modelimiz karma bir metot kullanarak ya VE/VEYA aaçlarındaki taahhütlerin ihlallerinden kural dıı durumları saptamakta ya da daha bu taahhütlerin zaman aımı bilgisi gelmeden ontoloji yardımıyla sorun çıkacaını önceden kestirerek büyük ölçüde verimlilik salamaktadır. Burada açıkladıımız metot gelimelere açıktır. Eer sistem küresel ve dev bir aa doru daha büyük ve karmaık olacak ekilde büyüyecek ve tedarik zinciri dünyasındaki tüm etmenleri içerecekse, tüm taahhüt verisini tek bir MA içine yükleme zor ve yapılabilirlikten uzak olacaktır. letiim ve depolama kısıtları sorun yaratabilecektir. Bu durumda MA etmeninin daıtık bir versiyonu baarım ve özellik hedeflerinden dolayı tasarlanabilir. Benzer ekilde VE/VEYA aacı etmenler arasında daıtık olarak tutulabilir. 5. Ek: Kural Dıı Durumları Bulmak çin Kullanılan Ontoloji <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE rdf:rdf [ <!ENTITY owl 'http://www.w3.org/2002/07/owl#'> ]> <rdf:rdf xml:base="http://boun.edu.tr/driver" xmlns:a="http://boun.edu.tr/driver#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:swrl="http://www.w3.org/2003/11/swrl#"> <owl:ontology rdf:about=""/> <owl:objectproperty rdf:id="cancelled"> <rdfs:domain rdf:resource="#delivery"/> <rdfs:range rdf:resource="#truck"/> </owl:objectproperty> <owl:objectproperty rdf:id="doneby"> <rdfs:domain rdf:resource="#delivery"/> <rdfs:range rdf:resource="#driver"/> </owl:objectproperty> <owl:objectproperty rdf:id="drives"> <rdfs:domain rdf:resource="#driver"/> <rdfs:range rdf:resource="#truck"/> </owl:objectproperty> <owl:objectproperty rdf:id="workmode"> <rdfs:domain rdf:resource="#truck"/> </owl:objectproperty> <a:driver rdf:id="george"> <a:drives rdf:resource="#bmc"/> </a:driver> <a:driver rdf:id="john"> <a:drives rdf:resource="#fiat50nc"/>

</a:driver> <a:truck rdf:id="bmc"> <a:workmode rdf:resource="#working"/> </a:truck> <a:delivery rdf:id="del01"> <a:doneby rdf:resource="#john"/> </a:delivery> <a:delivery rdf:id="del02"> <a:doneby rdf:resource="#george"/> </a:delivery> <a:delivery rdf:id="del03"> <a:doneby rdf:resource="#john"/> </a:delivery> <a:delivery rdf:id="del04"> <a:doneby rdf:resource="#george"/> </a:delivery> <a:truck rdf:id="fiat50nc"> <a:workmode rdf:resource="#stopped"/> </a:truck> <swrl:variable rdf:id="v"/> <swrl:variable rdf:id="t"/> <swrl:variable rdf:id="d"/> <swrl:imp> <swrl:head rdf:parsetype="collection"> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="#cancelled"/> <swrl:argument1 rdf:resource="#v"/> <swrl:argument2 rdf:resource="#t"/> </swrl:individualpropertyatom> </swrl:head> <swrl:body rdf:parsetype="collection"> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="#doneby"/> <swrl:argument1 rdf:resource="#v"/> <swrl:argument2 rdf:resource="#d"/> </swrl:individualpropertyatom> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="#drives"/> <swrl:argument1 rdf:resource="#d"/> <swrl:argument2 rdf:resource="#t"/> </swrl:individualpropertyatom> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="#workmode"/> <swrl:argument1 rdf:resource="#t"/> <swrl:argument2 rdf:resource="#stopped"/> </swrl:individualpropertyatom> </swrl:body> </swrl:imp> <owl:class rdf:id="delivery"/> <owl:class rdf:id="driver"/> <owl:class rdf:id="truck"/> </rdf:rdf>

Kaynakça [1] H. van Vliet. Software Engineering: Principles and Practice, Second Edition, Wiley, 2000. [2] M. S. Fox, M. Barbuceanu ve R. Teigen. Agent-oriented supply-chain management. The International Journal of Flexible Manufacturing Systems, 12(2000) s. 165-188. [3] N.Jennings. On Agent-Oriented Software Engineering. Artificial Intelligence Journal, 117 (2) 277-296, 2000. [4] T. J. Becker, "Putting a Price on Supply Chain Problems: Study Links Supply Chain Glitches with Falling Stock Prices", Georgia Tech Research News, Aralık 2000, Web adresi: http://www.gtresearchnews.gatech.edu/newsrelease/ [5] M. N. Huhns, L M.Stephens ve N Ivezic. Automating supply-chain management. Proceedings of the 1st International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS), s. 1017-1024. ACM Press, Temmuz 2002. [6] C. Dellarocas ve M. Klein. A knowledge-based approach for designing robust business processes. W. van der Aalst et al. (eds.): Business Process Management, LNCS 1806, s. 60-65, 2000. [7] C. Dellarocas, M. Klein ve J. A. Rodriguez-Aguilar. An exception handling architecture for open electronic marketplaces of contract net software agents. Proc. of the ACM Conf. on Electronic Commerce, s. 225-232, 2000. [8] N. Fornara ve M. Colombetti. A commitment-based approach to agent communication. Applied Artificial Intelligence: an International Journal, 18(9-10):853-866, 2004. [9] P. Yolum ve M. P. Singh. Reasoning about commitments in the event calculus: An approach for specifying and executing protocols. Annals of Mathematics and Artificial Intelligence 42:227-253, Kluwer Academic Publishers, 2004. [10] N. J. Nilsson, Principles of Artificial Intelligence, Springer Verlag, 1980. [11] OWL. Web Ontology Language. Web adresi : http://www.w3.org/tr/owl-features/ [12] R. Kalakota, J. Stallaert ve A. B. Whinston, Implementing Real-time Supply Chain Optimization, Web adresi: http://cism.nccombs.utexas.edu/jan/sc_imp.html [13] D. Frey, T. Stockheim, P. O. Wolk ve R. Zimmermann. Integrated multiagent based supply chain management. Proceedings of the First International Workshop on Agent-based Computing for Enterprise Collaboration (ACEC), 2003.