UBI 622 ÇOK-ETMENLİ SİSTEMLER ÇOK-ETMENLİ SİSTEM GELİŞTİRME METODOLOJİLERİ Doç. Dr. Geylani KARDAŞ

... konulu sunumlar: "UBI 622 ÇOK-ETMENLİ SİSTEMLER ÇOK-ETMENLİ SİSTEM GELİŞTİRME METODOLOJİLERİ Doç. Dr. Geylani KARDAŞ"— Sunum transkripti:

1 UBI 622 ÇOK-ETMENLİ SİSTEMLER ÇOK-ETMENLİ SİSTEM GELİŞTİRME METODOLOJİLERİ Doç. Dr. Geylani KARDAŞ geylani.kardas@ege.edu.tr

2 2 İçerik  Etmen Metodolojileri  Tropos  Gaia  Sabpo

3 3 Etmen Metodolojileri  Yazılım metodolojisi: Genellikle bir modelleme dili ve bir yazılım süreci ile ifade edilir (Bauer and Odell, 2005) :  Modelleme dili: modellerin tanımlanması ve model elemanlarının özel bir sözdizim ve anlamla gösterilmesi için kullanılır  Yazılım süreci: geliştirme aktivitelerini, aktiviteler arasındaki ilişkileri ve aktivitelerin nasıl gerçekleştirileceğini tanımlar Bir metodoloji süreç ve ürün desteğini içerir (Giorgini and Henderson-Sellers, 2005) :  Yaklaşımın içerdiği süreç elemanlarının tanımlanması  İş ürünleri ve belgelendirmenin ortaya konması

4 4 Etmen Metodolojileri  Yazılım metodolojisi: Nesne yönelimli sistem geliştirme metodolojileri:  90’lı yılların eğilimi  Endüstri güdümlü ve sistem geliştirme ve yönetmede endüstri tarafından sıklıkla kullanılıyor Etmen yönelimli sistem geliştirme metodolojileri:  Henüz oldukça yeni ve başlangıç seviyesinde  Küçük akademisyen grupları tarafından destekleniyor  Çok azı test edilmiş ve birkaç küçük endüstriyel uygulamada kullanılmış  Ortak yönleri: Çoğunlukla toplum organizasyonu metaforu kullanılıyor ÇES’lerin organizasyonel doğası gereği bu metodolojiler sosyal ilişkileri, etmenler arası bağımlılıkları ve etmenlerin oynadığı rolleri tanımlamak için etkileşim ve eşgüdüm modellerini ortaya koymayı hedefliyor Sistemlerin uygulamadan çok analiz ve tasarım safhalarını tanımlıyorlar  Pratikte kullanılabilecek etmen yönelimli programlama dili eksikliği

5 5 Etmen Metodolojileri  Bir yazılım metodolojisinin “etmen yönelimli (“agent- oriented”)” olması neyi ifade eder? Nesne yönelimli bir metodolojide nesne yönelimli kavramlar  metodolojiyi tarif etmek ve  nesne temelli sistemleri inşa etmek için kullanılırlar Etmen yönelimli metodolojilerin çoğu kendisini etmen yönelimli prensipler üzerine inşa etmez  Etmen tabanlı (“agent based”) bir yazılımın üretilmesi için geliştirilmişlerdir  Etmen metodolojilerinin soy ağacı (Giorgini and Henderson- Sellers, 2005) : Çeşitli kökler:  yapay zeka temelli,  nesne tabanlı metodolojilerin direkt uzantısı veya  iki yaklaşımı da içeren

6 6 Etmen Metodolojileri  Etmen metodolojilerinin soy ağacı (Giorgini and Henderson-Sellers, 2005) :

7 7 Tropos (Bresciani et al., 2004)  İhtiyaç-güdümlü (“Requirement-driven”) bir geliştirme metodolojisi  i*’dan (Yu, 1995) yararlanarak: Sosyal ortamdaki aktörler Aktörler arasındaki sosyal bağımlılıklar modelleniyor.  Aktörler: Etmenler, Pozisyonlar, Roller  Sosyal bağımlılıklar: Amaçlar, İkinci derecedeki amaçlar (“softgoal”), Görevler ve Kaynaklar arasındaki bağımlılıklar olarak ifade edilebilir.

8 8 Tropos (Bresciani et al., 2004)  Tropos metodolojisinin 4 safhası: Önceki ihtiyaçlar (“Early requirements”): Organizasyonel seviyede problemin ne olduğunun anlaşılması Sonraki ihtiyaçlar (“Late requirements”): Gerçekleştirilecek sistemin çalışacağı ortam kapsamında fonksiyonelliği ve diğer özellikleri ile tanımlanması Mimari tasarımı (“Architectural design”): Sistemin genel mimarisinin altsistemler, veri bağlantıları, kontroller ve diğer bağımlıklar üzerinden tanımlanması Detaylandırılmış tasarım (“Detailed design”): Her bir mimari bileşeninin davranışının gözden geçirilmesi ve daha detaylı bir şekilde tanımlanması

9 9 Tropos (Bresciani et al., 2004)  Tropos, çalışacak sistemin bir modelini oluşturmak için ihtiyaç modellemenin kullanılması fikrine dayanır.  Model giderek artan bir şekilde arıtılır ve genişletilir.  Model yazılım sisteminin belgelendirilmesi ve evrimi için de bir temel oluşturur.  Tropos’ta ihtiyaç analizi: Gerçekleştirilecek sistemin organizasyonel içeriğinin anlaşılması için önceki ihtiyaçlar analizi Gerçekleştirilecek sistemin fonksiyonel ve fonksiyonel olmayan ihtiyaçlarının belirlenmesi için sonraki ihtiyaçlar analizi

10 10 Tropos (Bresciani et al., 2004)  i* (“distributed intentionality”) modeling framework: Haksahipleri (“stakeholder”) sosyal aktörler olarak temsil edilir. Strategic dependency model: Aktörler arası bağımlılıklara ait ağı tanımlar.  Tropos’ta “actor diagram”’lar ile gösterilir. Strategic rationale model: Her aktörün diğer aktörlerle olan ilişkilerini göz önüne alarak gerçekleştirdiği akıl yürütmeyi destekler ve tanımlar.  Tropos’ta “rationale diagram”’lar ile gösterilir.

11 11 Tropos (Bresciani et al., 2004)  Önceki İhtiyaçlar Analizi: “Domain stakeholder”’ların belirlenmesi ve birbirlerine bağımlı olan aktörler olarak modellenmesi Bağımlılıklar (“Dependency”) üzerinden sistem fonksiyonelliği göz önünde bulundurularak neden, ne ve nasıl sorularına cevaplar aranmaktadır.  Bu safhada “actor” ve “rationale” diyagramları kullanılır. Bir “actor diagram” birbirleri ile stratejik bağımlılıklar içeren aktörleri içermektedir.

12 12 Tropos (Bresciani et al., 2004)  Aktör diyagramındaki bir bağımlılık “dependum” adı verilen bir anlaşmayı temsil etmektedir. “The depender depends on the dependee to deliver on the dependum” “dependum” örnekleri:  Ulaşılacak bir amaç veya “softgoal”,  Yerine getirilecek bir görev,  Tedarik edilecek bir kaynak Softgoals: Ulaşılmaları için kesin kriterlerin olmadığı ve belirsiz bir şekilde tanımlanmış olan amaçlar Grafiksel gösterim:  Aktör: daire  Amaç: oval  Softgoal: bulut  Görev: altıgen  Kaynak: Dikdörtgen  Bağımlılık: depender → dependum → dependee

13 13 Tropos (Bresciani et al., 2004)  Bir “actor diagram” örneği (Giorgini et al., 2005) :

14 14 Tropos (Bresciani et al., 2004)  “Means-ends Analysis”: Aktör diyagramlarının detaylandırılması için her bir amacın analiz edilmesi  “Rationale” diyagramları ile bu analiz belirtilmektedir. Her aktörün amacı analiz edilir ve diğer aktörlerle olan bağımlılıklar kurulur. Amaçlar altamaçlara ayrıştırılır. Altamaçların amaca pozitif/negatif etkileri belirtilir.  Sonraki İhtiyaçlar Analizi: Bir önceki safhada oluşan kavramsal modelin oluşacak sistemin de bir aktör olarak ele alındığı ve bu yeni aktörün kendi ortamındaki diğer aktörlerle bağımlılıklarının dahil edildiği bir şekilde genişletilmesini içerir. Sistemin fonksiyonel ve fonksiyonel olmayan ihtiyaçları tanımlanır. Yine “actor” ve “rationale” diyagramları kullanılır.

15 15  Bir “means- ends” analiz örneği (Giorgini et al., 2005) : Tropos (Bresciani et al., 2004)

16 16 Tropos (Bresciani et al., 2004)  Tasarlanan sistemin de bir aktör olarak gösterildiği arıtılmış bir aktör diyagramı örneği (Giorgini et al., 2005) :

17 17 Tropos (Bresciani et al., 2004)  Bir “rationale diagram” örneği (Giorgini et al., 2005) :

18 18 Tropos (Bresciani et al., 2004)  Mimari Tasarımı: Amaçlarına ulaşma gayretinde olan bağımsız haksahipleri arasındaki stratejik işbirliğini modeller. Stratejik müttefiklik görüşü ve organizasyon teorisine dayanır. Structure-in-5 (Mintzberg, 1992) organizasyonel stili:  Bir organizasyon 5 alt- yapının birleşiminden oluşur: Operational Core Middle Line Support Technostructure Strategic Apex

19 19 Tropos (Bresciani et al., 2004)  “Structure-in- 5” stilinde bir sistem mimarisi örneği (Giorgini et al., 2005) :

20 20 Tropos (Bresciani et al., 2004)  Detaylandırılmış Tasarım: Bir önceki safhada ortaya konan mimari bileşenlerinin ek detaylarının tanımlamasını sağlar.  Sosyal desenlere (“Social patterns”) uygun olarak her aktöre atanmış amaçlara etmenler tarafından nasıl ulaşılacağını tanımlamayı içerir. Bu adım için tasarımcılar bir ÇES desen kataloğundan yararlanabilir.  Tanıdık yazılım deseni kataloğu (Gamma et al., 1994) sosyal ve “intentional” bakış açılarını çok az desteklediğinden uygun değil  Bazı etmen desenleri sosyal ve “intentional” bakış açılarını destekliyor ancak bu destek sadece sistemlerin uygulama (“implementation”) safhaları için uygun Tropos Sosyal Desenleri:  ÇES’ler için sosyal ve “intentional” bakış açılarını dikkate alan tasarım desenleri  İki kategori: “Pair Patterns” “Mediation Patterns”

21 21 Tropos (Bresciani et al., 2004)  “Pair Patterns”: Görüşme yapan (“negotiating”) etmenlerin doğrudan etkileşimlerini tanımlar.  Örnek desenler: kiralama, öneri çağrısı veya ihale (“bidding”)  “Mediation Patterns”: Etmenlerin bir anlaşmaya varması veya servis alışverişi için etmenlere yardım eden ara etmenlerin özelliklerini tanımlar.  Örnek desenler: aracı (“broker”), eşleme (“matchmaker”) veya sargı (“wrapper”)  Detaylandırılmış tasarım aynı zamanda aktör iletişimini ve davranışlarını da içerir. FIPA ACL ve KQML gibi mesaj dilleri, mesaj iletişim mekanizmaları ve araçlarının benimsenmesi (“adoption”) UML’i Tropos’da formal gösterim dili olarak kullanmak amacıyla çeşitli stereotiplerin ve etiketlerin tanımlanması

22 22 Gaia (Zambonelli et al., 2003)  Etmen organizasyonel modellerinin tanımlanması ve sistem bileşenlerinin iç ilişkilerinin belirlenmesi amacıyla ÇES geliştiricilerine bir dizi sistem geliştirme adımları sunar.  Gaia safhaları: Analiz Safhası (“Analysis Phase”)  Ortam modelinin tanımlanması, ilkel rollerin belirlenmesi, vb. Mimari Tasarım Safhası (“Architectural Design Phase”)  Sistemin organizasyonel yapısının topoloji ve belli desenlerle ortaya konması ve rol ve etkileşim modellerinin son şeklinin verilmesi Detaylandırılmış Tasarım Safhası (“Detailed Design Phase”)  Teknoloji bağımsız bir şekilde ÇES’in etmen ve servis modelleri göz önüne alınarak ve uygun etmen programlama çerçeveleri kullanılarak hayata geçirilmesi amacıyla tanımlanması

23 23 Gaia (Zambonelli et al., 2003)  Gaia özel modelleme tekniklerini göz önüne almaz. Örneğin rol, çevre ve etkileşimler için özel modelleme teknikleri önerir ama kullanılması zorunlu değildir.  Gaia doğrudan ÇES’lerin uygulanma (“implementation”) konuları ile ilgilenmez.  Gaia sistem ihtiyaçlarının yakalanması ve modellenmesi ile ilgili aktiviteleri dikkate almaz.  Yazılım geliştirme için sıralı bir yaklaşım sunan Gaia’nın belirgin olmayan sistem ihtiyaçları, yanlış varsayımlar ve eksik bilgiler sonucunda tasarımcıların süreçte geriye dönüşlerini tanımlamamış olması bir eksiliktir. Bu nedenle esnek ve yinelemeli bir yapısının olmadığı söylenebilir.

24 24 Gaia (Zambonelli et al., 2003)  Gaia metodolojisindeki modeller ve Gaia sürecinde bunların ilişkileri:

25 25 Gaia (Zambonelli et al., 2003)  Analiz Safhası: Aşağıdakilerin belirlenmesini içerir:  Organizasyonun amaçları ve bunlara ait sistemin beklenen global davranışı  Çevresel model (“Enviromental model”)  Başlangıç rol modeli (“Preliminary role model”)  Başlangıç etkileşim modeli (“Preliminary interaction model”)  Organizasyonun kendi iç yapısında ve global davranışında uyması gereken kurallar

26 26 Gaia (Zambonelli et al., 2003)  Analiz safhasının çıktıları olan: Çevresel model, Başlangıç rol modeli, Başlangıç etkileşim modeli ve Bir dizi organizasyonel kurallar Gaia metodolojisinin tasarım safhasında kullanılmaktadır.  Gaia tasarım safhasının mantıksal ayrışımı: Mimari tasarım safhası Detaylandırılmış tasarım safhası

27 27 Gaia (Zambonelli et al., 2003)  Mimari Tasarım Safhası: Aşağıdakileri içerir:  Sistemin organizasyonel yapısının topoloji ve bir “control regime” ile tanımlanması Organizasyon teorisinden (Simon, 1957) faydalanılır Organizasyonel etkinlik ÇES’in eğer varsa gerçek dünya için organizasyonu Organizasyonel kuralların uygulanması  Başlangıç rol ve etkileşim modellerinin tamamlanması Analiz safhasında belirlenen organizasyon bağımsız yapılarla bir önceki adımda belirlenen organizasyonun spesifik yapısına dayalı organizasyona bağımlı yapıların ayrıştırılması Bir başka deyişle sistem yapısı ve amaçlarının ayrıştırılması

28 28 Gaia (Zambonelli et al., 2003)  Detaylandırılmış Tasarım Safhası: Sistemin genel mimarisi tüm rolleri ve etkileşimleri ile belirlendikten sonra bu safha başlar. Aşağıdakileri içerir:  Etmen modelinin tanımlanması Sistemi oluşturan etmen sınıflarının (“agent classes”) ve bunlara dayalı olarak oluşturulan etmen örneklerinin (“agent instance”) ortaya konması Etmen ve roller arasında birebir eşleme olacağı gibi birden fazla rol sistemin etkinliği açısından bir etmene atanabilir.  Servis modelinin tanımlanması Etmenlerin rollerini gerçekleştirmede ihtiyaç duyulan servislerin ve servis özelliklerinin ortaya konması

29 29 Gaia (Zambonelli et al., 2003)  Gaia sürecinin sonuç ürünü: Süreç başarıyla uygulandıktan sonra geliştiriciler iyi tanımlanmış etmen sınıflarını elde etmekte ve tanımladıkları etmen ve servis modeline göre bu sınıflardan örnekler türetebilmektedirler.  Gaia metodolojisinin uygulanması örneği (Zambonelli et al., 2005) : Uluslararası bir konferansın etmen tabanlı bildiri yönetim sistemi Konferans yönetimi:  Yazarların bildiri göndermesinden yayımcının bildirileri basmasına kadar farklı bireyleri ve grupları içeren çok-fazlı bir süreç.

30 30 Gaia (Zambonelli et al., 2003)  Gaia metodolojisinin uygulanması örneği (Zambonelli et al., 2005) : Uluslararası bir konferansın etmen tabanlı bildiri yönetim sistemi Analiz:  Çevresel model: Etmenlerin kullanacağı çevresel kaynaklar: bildiriler ve değerlendirme formları Model:  bildiri özellikleri (yazar, başlık, anahtar kelimeler, vb.) ve değerlendirme formlarının (örneğin puanlama) özelliklerini tanımlar  Çevreyi bildirilerin ve değerlendirme formlarının bir bütünü olarak modeller  Başlangıç rol modeli: Hakem, program komitesi başkanı, program komitesi üyeleri ve yazarlara ait rollerin izinleri ve sorumlukları ile beraber tanımlanması  Örnek: “reviews collector” yazarların gönderdiği bildiriler için uygun hakemleri seçer ve bu hakemlere bildirileri gönderir ancak bildiriler ve değerlendirme formlarında değişiklik yapamaz

31 31 Gaia (Zambonelli et al., 2003)  Gaia metodolojisinin uygulanması örneği (Zambonelli et al., 2005) : Uluslararası bir konferansın etmen tabanlı bildiri yönetim sistemi Analiz:  Başlangıç etkileşim modeli: Rollere dayalı olarak başlangıç seviyesinde etmen etkileşimleri belirlenir.  Örneğin: “reviews collector” rolü “reviewer” rolü oynayan etmenlerin dahil olduğu bir etkileşimi de ortaya çıkaracaktır.  Gerçek organizasyon yapısının tasarım safhasında ortaya çıkmasından sonra yeni rollerin ve bunlara dayanan yeni etkileşimlerin belirlenmesi mümkündür.  Organizasyonel kurallar: Çeşitli örnekler:  Bir yazar kendi bildirisi için hakemlik yapamaz  Gönderilen her bildiri için “reviewer” rolü her biri farklı etmen tarafından oynanmak koşulu ile en az üç kez oynanmalıdır.

32 32 Gaia (Zambonelli et al., 2003)  Gaia metodolojisinin uygulanması örneği (Zambonelli et al., 2005) : Uluslararası bir konferansın etmen tabanlı bildiri yönetim sistemi Mimari Tasarım:  Sistemin organizasyonel yapısının tanımlanması: Başlangıç noktası olarak gerçek dünya organizasyonundan esinlenerek problemin karmaşıklığının belirlenmesi  Örneğin konferansa yollanan bildiri sayısı Gerçek dünya organizasyonunun temsili için önceden belirlenmiş organizasyon kuralları uygun seçenekler sunabilir  Örneğin her bildirinin en az üç hakem tarafından değerlendirilmesi için bildirilerin seçimi hakemlere bırakılabilir ancak bu büyük çaplı konferanslar için sorun oluşturabilir. Bu durumda merkezi bir seçim mekanizmasının oluşturulması daha doğru bir seçenek  Başlangıç rol ve etkileşim modellerinin tamamlanması ÇES’in en son organizasyon yapısı içerdiği roller, protokoller ve çevredeki kaynaklarla olan etkileşimlerle beraber ortaya konur

33 33 Gaia (Zambonelli et al., 2003)  Gaia metodolojisinin uygulanması örneği (Zambonelli et al., 2005) : Uluslararası bir konferansın etmen tabanlı bildiri yönetim sistemi Detaylandırılmış Tasarım:  Etmen modelinin tanımlanması: Rolleri oynayacak asıl etmenlerin ortaya konması Rol-etmen atamaları birebirden farklı olabilir.  Örneğin program komitesi başkanı rolünü oynayan bir etmen aynı zamanda bir bildiri için hakem başka bir bildiri için yazar rollerini oynayabilir.  Servis modelinin tanımlanması: Etmenlerin sunacağı servislerin ortaya konması Servisler bütünleşik bir yapıda olabilir.  Örneğin “reviewer” rolünü oynayan bir etmen önce bir bildiriyi alır, bildiriyi değerlendirir, değerlendirme formunu yollar. Servisin girdisi hakemlik isteği, çıktısı ise değerlendirme formudur. Servisin ön koşulu hakemin maksimum bildiri değerlendirme sayısına ulaşmamış olması, sonlanma koşulu da formun düzgün doldurulmuş olması olabilir.

34 34 Sabpo (Dikenelli and Erdur, 2003)  Standards Based and Pattern Oriented (SABPO)  Sabpo, etmen sistemleri için “organizasyon” metaforunu temel almakta ve bu metaforu FIPA standartları ve bilinen etkileşim protokolleri ile sistematik bir biçimde bütünleştirmektedir.  FIPA standartlarının uzantısı olan bir etkileşim deseni tanımlama mekanizması içerir. Bu amaca yönelik yeni bir desen: “ontology inception”  Ontolojilerin çalışma zamanında değiştiği ortamlarda çalışabilecek, uyarlanabilir ÇES organizasyonlarının kurulabilmesini sağlar.

35 35 Sabpo (Dikenelli and Erdur, 2003)  FIPA soyut mimarisi tanımlamasına dayalı olarak sistem ihtiyaçlarına cevap veren somut bir mimari ortaya koyar.  FIPA soyut mimarisinde seçimlik olarak görünen ontoloji hizmetleri Sabpo’da zorunlu kabul edilir ve bu amaçla bir Ontoloji Servisi ve bu servisi sunan etmenler bulunur.

36 36 Sabpo (Dikenelli and Erdur, 2003)  Sabpo sistem geliştirme sürecinin sadece analiz ve tasarım aşamalarını tanımlar. Analiz safhası:  Rollerin bulunması  Rollerin etmenlere eşlenmesi ve ontolojilerin belirlenmesi  Sistemdeki etkileşimlerin belirlenmesi  Senaryolar için “Hierarchical Task Network (HTN)”’lere (Williamson, 1996) dayalı planların tanımlanması Tasarım safhası:  Ontolojilerin modellenmesi  Etmen modelinin oluşturulması  Detaylandırılmış etkileşim modelinin oluşturulması

37 37 Sabpo (Dikenelli and Erdur, 2003)  Analiz safhası: FIPA soyut mimarisini ve etkileşim protokollerini dikkate alan iki farklı model hazırlanır:  Rol Modeli: Organizasyon içerisindeki rolleri belirleme Organizasyonun global amaçları için rollerin sorumluluklarını belirleme FIPA soyut mimarisi tanımına ek olarak iki yeni rol tanımı:  Directory Service Provider  Ontology Service Provider Rol modelin belgelendirilmesi Gaia (Zambonelli et al., 2003) modelleme stiline uygun bir şekilde gerçekleştirilir.

38 38 Sabpo (Dikenelli and Erdur, 2003)  Analiz safhası:  Etkileşim Modeli: Etmenler arası etkileşimlerin tanımlanması FIPA tanımlamalarında verilen etkileşim desenlerine uygun olarak “Ontology Service Provider” ve “Directory Service Provider” rolleri etkileşimlerde önemli rol oynamaktadırlar. Etkileşimler Agent UML (Bauer et al., 2001) notasyonu kullanılarak belgelendirilebilir. Etkileşim diyagramlarında FIPA iletişimsel edinleri açık bir şekilde ifade edilmektedir. Geliştiricilerin verecekleri kararlar:  Global ontolojinin adı ve genel amaçları  Birden fazla ontoloji kullanılacaksa her rolün kullanacağı ontolojilerin özellikleri  Uygun FIPA standartları göz önüne alınarak oluşturulan sistem servislerinin özellikleri

39 39 Sabpo (Dikenelli and Erdur, 2003)  Tasarım safhası: Analiz safhasında ortaya konan soyut varlıklara dayalı olarak bir FIPA uyumlu somut mimari inşa edilir. Üç model üretilir:  Ontoloji modeli  Etmen modeli  Detaylandırılmış etkileşim modeli Ontoloji modeli:  Bir ontoloji dili kullanılarak (örneğin (DARPA Agent Markup Language (DAML) veya Web Ontology Langauge (OWL)) sistemde yer alacak ontolojilerin modellemesi gerçekleştirilir.  Organizasyonel kurallar (Zambonelli et al., 2003) ’teki çalışmaya dayalı olarak tanımlanır ve ontoloji bilgisinin bir parçası olarak saklanır.

40 40 Sabpo (Dikenelli and Erdur, 2003)  Tasarım safhası: Etmen modeli:  Etmen tiplerini ve analiz safhasında tanımlanan rollerin etmen tiplerine atanmasını ifade eder.  Etmenlerin rollerinin sorumluluğuna dayalı olarak her etmenin servisleri tanımlanır.  Her etmenin organizasyonda kullanılan ontolojilere kendini uyarlaması gerektiğinden etmen iç bilgileri ile sistem ontolojileri arasında her etmen için eşlemeler gerçekleştirilir. Detaylandırılmış etkileşim modeli:  Analiz safhasında tanımlanan etkileşim desenlerinin FIPA tanımlamalarına eşlenmesini sağlar.  Etmenler arasındaki mesajların FIPA ACL tanımlamasına göre yeniden yazılması gerçekleştirilir. Tasarım safhası sonucunda organizasyonun tüm somut elemanları herhangi bir FIPA uyumlu etmen geliştirme çerçevesi ile hayata geçirilmeye hazır vaziyettedir.

41 41 Sabpo (Dikenelli and Erdur, 2003)  Sabpo metodolojisi etkileşim modeli örnekleri:

42 42 Sabpo (Dikenelli and Erdur, 2003)  Sabpo metodolojisi etkileşim modeli örnekleri:

43 43 Sabpo (Dikenelli and Erdur, 2003)  Sabpo metodolojisinde etkileşimlerin “sequence diagram”’larla gösterilmesi:

44 44 Sabpo (Dikenelli and Erdur, 2003)  Sabpo metodolojisinde senaryolar için HTN’lerin oluşturulması :

45 45  Tartışma  Araştırma projelerinin atanması: ADELFE INGENIAS MAS-CommonKADS MaSE PASSI Prometheus RAP / AOR SODA

46 46 Kaynaklar  Bauer, B., Müller, J. P. and Odell, J. (2001) “Agent UML:A formalism for specifyingmultiagent interaction”, International Journal of Software Engineering and Knowledge Engineering, Vol. 11 Issue 3, pp. 207-230.  Bauer, B. and Odell, J. (2005) “UML 2.0 and agents: how to build agent-based systems with the new UML standard”, Engineering Applications of Artificial Intelligence, Vol. 18, Issue 2, pp. 141-157.  Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F. and Mylopoulos, J. (2004) “Tropos: An agent-oriented software development methodology”, Autonomous Agents and Multi- Agent Systems, Vol. 8, Issue 3, pp. 203-236.  Dikeneli, O. and Erdur, R. C. (2003) “SABPO: A Standards Based and Pattern Oriented Multiagent Development Methodology”, Lecture Notes in Artificial Intelligence, Vol. 2577, pp. 213-226.  Gamma E., Helm R., Johnson R. and Vlissides J. (1994) “Design Patterns - Elements Of Reusable Object-Oriented Software”, Addison-Wesley, Massachusetts - USA, 395p.  Giorgini, P. and Henderson-Sellers, B. (2005), "Agent-Oriented Methodologies: An Introduction", 1-19, Agent-Oriented Methodologies, Henderson-Sellers, B. and Giorgini, P. (Eds.), Idea Group Publishing, 429p.  Giorgini, P., Kolp, M., Mylopoulos, J. and Castro, J. (2005), "Tropos: A Requirements- Driven Methodology for Agent-Oriented Software", 20-46, Agent-Oriented Methodologies, Henderson-Sellers, B. and Giorgini, P. (Eds.), Idea Group Publishing, 429p.

47 47 Kaynaklar  Mintzberg, H. (1992) “Structure in fives: Designing effective organizations”, Upper Saddle River, NJ, Prentice-Hall.  Simon, H. A. (1957) “Models of man: social and rational”, New York, Wiley, 287p.  Williamson, M., Decker, K. and Sycara, K. (1996), “Unified Information and Control Flow in Hierarchical Task Networks”, In proceedings of the AAAI-96 Workshop, California, USA, pp. 142-150.  Yu, E. (1995), “Modelling strategic relationships for process reengineering”, PhD thesis, University of Toronto, Department of Computer Science.  Zambonelli, F., Jennings, N.R. and Wooldridge, M. (2003), “Developing multiagent systems: The Gaia methodology”, ACM Transactions on Software Engineering and Methodologies, Vol. 12, Issue 3, pp. 317-370.  Zambonelli, F., Jennings, N.R. and Wooldridge, M. (2005), "Multi-Agent Systems as Computational Organizations: The Gaia Methodology", 136- 172, Agent-Oriented Methodologies, Henderson-Sellers, B. and Giorgini, P. (Eds.), Idea Group Publishing, 429p.