1 TROPOS İLE MÜZİK ARAMA UYGULAMASI : ÇOKLU ETMEN SİSTEMİ GELİŞTİRİMİ Umut BENZER, [email protected] Beril KAVAKLI [email protected] Duygu ORHUN, [email protected] Ege Üniversitesi, Bilgisayar Mühendisliği, İZMİR ÖZET Tropos metodolojisinden yararlanılarak müzik arama görevini gerçekleştirecek bir çoklu etmen sistemi geliştirimi amaçlanmıştır. Öncelikle Tropos kullanılarak analiz ve tasarım aşamaları gerçekleştirilmiş, sonrasında ise Java dili ve Jade Framework’ü kullanılarak bir uygulama geliştirilmiştir. Uygulama belli kriterlere göre arayıcı etmenlerin satıcı etmenlerden müzik satın alması üzerine kurulmuştur. Anahtar Kelimeler: Etmen; Tropos; Jade. 1. GİRİŞ İnternet üzerinde müzik parçaları arayan bir kişiyi düşünelim. İstediği türde ve kalitedeki parçaları en uygun fiyata satın almak isteyecektir. Bu işlemi ise tek tek bütün satış platformlarını dolaşıp istediği parçaları seçmeli, aynı zamanda da fiyat kısıtlamasına uymalıdır. Ancak bu işi belli kriterlere göre yapacak bir çoklu etmen sistemi geliştirilirse tek yapması gereken kriterleri arayıcı etmenine iletip arayıcı etmenin ona parçaları getirmesini beklemektir. Böylelikle bir etmen sistemi manuel olarak çok daha uzun sürede gerçekleşecek bir görevi daha kısa bir sürede gerçekleştirebilir. Arayıcı etmene ileteceğimiz arama kriterleri ise aşağıdaki gibidir:  Müzik Türü  Müzik Başına Maksimum Bütçe  Maksimum Toplam Bütçe  Maksimum Parça Sayısı  Minimum Müzik Puanı 2. TROPOS METODOLOJİSİ VE UYGULAMASI Tropos, i* organizasyonel modelleme framework’ünde kurulan bir çeşit etmen tabanlı yazılım geliştirme metodolojisidir. i* hedef odaklı gereksinim mühendisliğine etmen odaklı bir yaklaşım getirmiştir. Buradaki hedefler, amaca yönelik ve stratejik olarak davranışlarda bulunan aktörler tarafından yerine getirilir. Tropos metodolojisi bir çoklu etmen sistemi geliştirmede gereksinim analizinden tasarıma kadar yol göstericidir. Temel olarak, oluşturulacak bir sistem ve bu sistemin içinde bulunduğu ortamı modellemek için gereksinim modellemesi kavramına dayalı olarak ortaya atılmış bir fikirdir. Bu model adım adım iyileştirilerek ve genişletilerek yazılım geliştirimi için bir arayüz oluşturumunu sağlar. Ayrıca belgeleme ve yazılım süreçleri için de bir temel olur. 

2 Tropos, temel olarak 4 bölümden oluşmaktadır. Bunlar şu şekildedir:  Erken Gereksinim Analizi  Geç Gereksinim Analizi  Mimari Tasarım  Detaylı Tasarım 2.1 Erken Gereksinim Analizi Gereksinim Analizi için Tropos, i* modelleme framework’ünün özelliklerinden yararlanmıştır. i*’da paydaşlar sosyal aktörler olarak tanımlanmıştır ve bu aktörlerin hedeflerine ulaşmaları için birbirlerine bağımlı olarak çalışmaları gerekmektedir. Bu aşamada sistem içerisindeki aktörler belirlenerek, aralarındaki bağımlılıklar ortaya konur. Oluşturulacak sistemde 3 farklı aktör rol almaktadır. Bunlar şu şekildedir:  Arayıcı Etmen: Kriterleri kullanıcı- dan alarak müzikleri bulup döndüren aktördür.  Rehber Etmen: Müzik Satıcı etmenlerin listesini ve ne tür şarkılar içerdiklerini tutarak Arayıcı etmene söyleyen aktördür.  Satıcı Etmen: Elindeki müzik parçalarını Arayıcı etmene satmaya çalışan aktördür. Sistemimizin ana aktörleri: Arayıcı, Satıcı ve Rehber olarak belirlenmiştir. Arayıcı bir müzik parçası satın alabilmek için Satıcıya bağımlıdır ve bu aktörün ana amacı müzik satın almaktır. Rehber üzerinde ‘uygun satıcıları göster’ görevi tanımlıdır. Yani Rehber müzik arayanlara uygun satıcıların listesini vermelidir. Ayrıca bu listede yer almak isteyen satıcıların ise Rehber’e kayıt yaptırması gerekmektedir. Sistemde tanımlı 2 yan hedef (soft goal) vardır. Satıcı kazancını arttırmak ister ve bunun için Arayıcı’ya bağımlıdır. Rehber ise Satıcıdan müzik listesini isteyerek kendi bilgi tabanını oluşturmayı ve güncellemeyi hedef edinmiştir. Şekil 1: Aktör Diyagramı 2.2 Geç Gereksinim Analizi Bu aşamada bir önceki adımda hazırlanmış aktör diyagramına oluşturulacak sistem yeni bir aktör olarak eklenir. Bu adımda sistem çevresiyle nasıl ilişki kuracağı bağımlılıklarının neler olduğu ortaya konur. Bu bağımlılıklar geliştirilecek sistem için fonksiyonel ve fonksiyonel olmayan gereksinimleri tanımlar. Şekil 2’de oluşturulan grafikte sistem, müzik bulucu sistemini temsil etmektedir ve burada sistemin diğer aktörlerle nasıl ilişkilerde olduğu ayrıca bu aktörlerin sistem ile nasıl ilişkide olduğu detaylı olarak görülmektedir. Arayıcı yani Müşteri aktörü iyi müzik bul görevini sisteme atar. Bu göreve göre sistemin hedefi kriterleri almak olur. Sistem hedefini gerçekleştirince bir satıcı listesi 

3 oluşur. Bu satıcı listesi üzerinden sistem müzik sorgusu görevini sonra da müzik sorgula görevini gerçekleştirir. Müzik sorgulama görevi, müzik veritabanı kaynağı aracılığı ile gerçekleştirilir. Müzik sorgulama görevi tamamlanınca, müzik sorgulama görevi tamamlanması görevi yerine getirilmiş olur. Bu senaryo Arayıcı ile Sistem arasında geçen diyalogları tanımlar. Şekil 2 : Rasyonel Diyagram Bunun dışında, ara işlemleri gerçekleştiren Rehber ve müziklerin bulunabileceği Satıcı aktörleri ile olan ilişkiler vardır. Rehber aktörünün temel olarak satıcı listesi kaynağı ile ilgili görevi vardır. Bu görev, satıcı listesini güncel tutmaktır. Bu listeyi güncel tutması için Satıcıdan bilgiler alması gerekmektedir. Satıcı aktörünün ise birden fazla görevi vardır. Kayıt olma ve kayıt silme görevleri ile satıcı kayıt işlemleri hedefi gerçekleştirilir ve Rehber bilgilendirilmiş olur. Satıcının ayrıca, müzik ekleme, müzik silme ve müzik bilgisi güncelleme görevleri vardır. Bu işlemler gerçekleşince müzik veritabanı güncellendi hedefi gerçekleştirilmiş olur. Bu sayede müzik araması yapılan müzik veritabanı kaynağı güncellenmiş olur. 2.3 Mimari Tasarım Tropos’ta çok etmenli sistemler için uygun mimari stiller geliştirilmiştir. Çok etmenli sistemler temelde amaca yönelik ve sosyaldirler. Bu sebepten dolayı, Organizasyon Teorisi (Organization Theory) ve Stratejik Anlaşma (Strategic Alliances) tasarım süreçlerinden kaynaklı sosyal yapılarla ilgileniliyor. Organizasyon Teorisi, organizasyonun yapısı ve tasarımını tanımlar. Stratejik Anlaşma ise, aynı hedefe odaklanan bağımsız organizasyonel paydaşların stratejik işbirliğini modeller. Tropos için organizasyon yapısını tanımlayan bir organizasyonel stil tanımlandı. Bu sayede, organizasyonel hedefler ve süreçlerin tanımlanması koordine edilebilir olmaktadır. Structure-in-5; organizasyonu 5 alt yapı halinde kümelendirir. Temelde Operational Core vardır ve bu ürün ve servislerle 

4 doğrudan ilişkili temel görev ve prosedürler ile ilgilenir. Yukarıda, yönetimsel kararlarla ilgilenen Strategic Apex vardır. Middle Line, Strategic Apex ile Operational Core arasındaki yetki hiyerarşisini kurar. Operational Core’un etkinliklerini yönetmek ve koordine etmekten sorumlu yöneticilerden oluşur. Technostructure, iş sürecini, çıktıları vs. standartlaştırarak diğerlerinin daha etkin çalışmasını sağlar. Support ise bu hiyerarşinin her seviyesinde ve iş akışı dışında kullanılmak için özelleştirilmiş servisler sağlar. Bu yöntemi müzik bulma sistemine uygularsak, Operational Core olarak, Music Store adlı bir aktör olarak görebiliriz. Bu aktörün görevleri arasında müzik listesinin güncellenmesi, kullanıcıdan arama kriterlerini alma ve bunları Music Coordinator adlı Middle Line’ı gösteren aktöre yönlendirir. Strategic Apex aktörünün görevini Decisioner adlı aktör gerçekleştirir ve kısıtları alma, bu kısıtlara uygun stratejik yol geliştirip uygun müzikleri bulma gibi görevleri vardır. Support aktörünün temsili ise Rehber gibi görülebilir. Kayıtlar bu aktör aracılığı ile fiziksel olarak gerçekleştirilir. Technostructure aktörünün görevini uygulama geliştirilip internete taşındığı durumda benzer bir aktör karşılıyor olacak. Bu aktör ödeme ve finansal görevlerle ilgileniyor olacak. 2.4 Detaylı Tasarım Mimari tasarımda tanımlanan her bir bileşen için detaylı tasarım yapılır. Her aktöre atanmış olan hedeflerin sosyal desenler doğrultusunda her bir aktör tarafından nasıl gerçekleştirildiği tasarlanır. Şekil 3’ te görülen ekran sistem başlatıldığında ilk karşımıza gelen ekrandır. Bu ekran üzerinden sistemde var olacak satıcı ve arayıcı etmenler oluşturulabilmektedir. Şekil 3 : Platform Yönetimi - Giriş Ekranı Şekil 4’ te görülen ekran aracılığıyla satıcı etmenlerin müzik listeleri güncellenebil- mektedir. Yeni müzik girmek istendiğinde sağ üst kısımda bulunan bölümden müzik tipi, artist, müzik adı, fiyat ve rating bilgileri girilerek listeye yeni müzik eklenebilir. Soldaki bölümde ise Satıcının müzik listesi görüntülenmektedir. İstenirse müzikler listeden seçilip Sil denerek listeden çıkartılabilir. Şekil 4: Satıcı Etmen ve Müzik Ekleme Şekil 5’te görülen ekranda kullanıcı ekranda bulunan kısıtları girerek arayıcı etmene müzik bulma emrini verir. Etmen işini bitirdikten sonra aldığı müzikleri kullanıcıya döndürür. 

5 Şekil 5 : Müzik Arama 2.4.1 Sınıf Diyagramı Şekil 7’de tüm sistemin sınıf diyagramı görünmektedir.  Music Seeker, sistemimizdeki Arayıcı etmene karşılık gelmektedir. Bu etmen için 3 ana behaviour tanımlanmıştır. Bunlar: - ShutdownAgent, -UpdateMusicDiscoveryAgents -FindAndPurchaseMusics dir. ShutdownAgent davranışı etmenin sonlandırılmasını sağlamaktadır. UpdateMusicDiscoveryAgents davranışı bir TickerBehaviour’dur. Belli sürelerde çalışarak müzik satıcı listesini günceller. FindAndPurchaseMusics, ComplexBehaviour tipindedir ve sırasıyla aşağıdaki davranışları çalıştırır. LookForMusic: Satıcı listesindeki etmenlere kriterleri SongRequestInfo olarak gönderir. ListenLookForMusicAnswers: Satıcılardan gelecek cevapları bekler. Belirli sürede cevap gelmezse o etmenin cevap vermeyeceği kabul edilir. Cevaplar SongSellInfo tipinde gelir. SelectMusic: Dönen müzikler arasından uygun olanları seçer. BuyMusic: Almak istenen müzikler için satıcılara alım isteği gönderir. ListenBuyMusicAnswers: Satın alma isteği gönderilen etmenlerden müziklerin gelmesini bekler. 

6  Music Provider, sistemimizdeki Satıcı etmene karşılık gelmektedir. Bu etmen için 6 behaviour tanımlanmıştır. Bunlar: - ShutdownAgent, - CheckBuyerMessages - AddSong - RemoveSong, - BuySong - SongSearch dür. ShutdownAgent davranışı etmenin sonlandırılmasını sağlamaktadır. CheckBuyerMessages davranışı bir CyclicBehaviour’dur. Diğer etmenlerden gelen mesajlara bakar ve mesaj içeriğine göre BuySong veya SongSearch davranışını başlatır. AddSong davranışı satıcı etmenin listesine müzik eklemeye yarar. RemoveSong davranışı satıcı etmenin listesinden müzik silmeye yarar. BuySong davranış istenen müziği arayıcı etmene gönderir. SongSearch davranışı istenen kriterlere uygun müzikleri arayıcı etmene iletir. 2.4.2 Akış Diyagramı Şekil 6’da görülen akış diyagramı sistemin işleyişini özetlemektedir. Şekildeki aktörler sistemimizde sırasıyla Arayıcı, Satıcı ve Rehber etmen olarak geçmektedir. Satıcı etmenin, arayıcılar tarafından bulunabilmesi için Rehber etmene kayıt olması gerekmektedir. Arayıcı etmen, Rehber’den satıcıların listesini ister. Daha sonra satıcılara kriterlerini göndererek uygun müzikleri satıcılardan ister. Daha sonra hangisini alacağına karar vererek satıcıdan o müziği alır. Şekil 6 : Akış Diyagramı 5. KAYNAKLAR Handerson-Sellers, B., Giorgini, P., 2005, Agent-Oriented Methodologies, USA,UK: Idea Group Publishing, 413s Wooldridge, M., 2002, An Introduction to MultiAgent Systems, UK:Wiley, 348s Bellifemine, F., Caire, G., GreenWood, D., 2007, Developing Multi-Agent Systems with Jade, UK:Wiley, 286s Caire, G., 2003, Jade Turorial-Jade Programming For Beginners, 20s 

7 Şekil 7 : Sınıf Diyagramı