MODEL DÖNÜŞÜM DİLLERİNİN İNCELENMESİ VE BİR MODEL SORGU DİLİ ÖNERİSİ

Transkript

1 EGE ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ (YÜKSEK LİSANS TEZİ) MODEL DÖNÜŞÜM DİLLERİNİN İNCELENMESİ VE BİR MODEL SORGU DİLİ ÖNERİSİ Arda GÖKNİL Bilgisayar Mühendisliği Anabilim Dalı Bilim Dalı Kodu: Sunuş Tarihi: Tez Danışmanı: Prof. Dr. N. Yasemin Topaloğlu Bornova-İZMİR

2

3 III Arda GÖKNİL tarafından yüksek lisans tezi olarak sunulan Model Dönüşüm Dillerinin İncelenmesi ve Bir Model Sorgu Dili Önerisi başlıklı bu çalışma E.Ü. Lisansüstü Eğitim ve Öğretim Yönetmeliği ile E.Ü. Fen Bilimleri Enstitüsü Eğitim ve Öğretim Yönergesi nin ilgili hükümleri uyarınca tarafımızdan değerlendirilerek savunmaya değer bulunmuş ve 25/07/2006 tarihinde yapılan tez savunma sınavında aday oybirliği/oyçokluğu ile başarılı bulunmuştur. Jüri Üyeleri: İmza Jüri Başkanı : Prof. Dr. N. Yasemin TOPALOĞLU Raportör Üye : Prof. Dr. Oğuz DİKENELLİ... Üye : Yrd. Doç. Dr. Adil ALPKOÇAK...

4

5 V ÖZET MODEL DÖNÜŞÜM DİLLERİNİN İNCELENMESİ VE BİR SORGU DİLİ ÖNERİSİ GÖKNİL, Arda Yüksek Lisans Tezi, Bilgisayar Mühendisliği Bölümü Tez Yöneticisi: Prof. Dr. N. Yasemin TOPALOĞLU Temmuz 2006, 112 sayfa Bu tez çalışmasında, Model Tabanlı Mühendislik kapsamında model dönüşümleri için geliştirilmiş ATL, MOLA, TEFKAT, GREAT, YATL model dönüşüm dilleri incelenmiş ve model dönüşüm dilleri değerlendirmesi için literatürde yer alan çalışmalar tartışılmıştır. Bu çalışmalar temel alınarak genel amaçlı bir model dönüşüm dilinin sağlaması gereken istekler ve bu istekler arasındaki ilişkiler araştırılmıştır. Tanımlanan istekler doğrultusunda, rol tabanlı bir model dönüşüm dilinin sorgu kısmını oluşturacak bir sorgu dili önerilmiştir. Rol tabanlı sorgu dilinde rollerin ve dönüşümlerin ifade edilmesinde gösterim olarak literatürde tanımlanmış Role-Based Modeling Language (RBML) dilinden yararlanılmıştır. Bu gösterim, rolü oynayan sınıfların sayılarını belirtmemize ve bu sınıflara ait kısıtları üst (meta) seviyede OCL kullanarak göstermemize olanak sağlamaktadır. Rol tabanlı sorgu dilinin UML-RDBMS ve çoklu kalıtım-tekli kalıtım dönüşümlerinde kullanımı örneklenmiş ve tartışılmıştır. Anahtar Sözcükler: Üst modelleme, Model Dönüşüm Dilleri, Rol Tabanlı Modelleme, Model Sorgu Dili.

6

7 VII ABSTRACT A SURVEY OF MODEL TRANSFORMATION LANGUAGES AND A MODEL QUERY LANGUAGE PROPOSAL GÖKNİL, Arda MSc in Computer Engineering Supervisor: Prof. Dr. N. Yasemin TOPALOĞLU July 2006, 112 pages In this thesis, model transformation languages like ATL, MOLA, TEFKAT, GREAT, and YATL which were developed for Model Driven Engineering (MDE) are studied. The requirements that model transformation languages should fulfill are examined by discussing the related work in the literature. Based on this survey, a set of generic transformation language requirements and the relations between these requirements are defined. According to the survey of transformation languages and the defined requirements, a role based model query language is proposed. The notation used in defining roles in role based model query language is Role-Based Modeling Language (RBML) which is defined by France (France et al., 2003a). This notation allows us to specify the number of model elements playing the role and to define the meta level constraints of that role as OCL constraints. The use of role based query language in UML-RDBMS and Multiple Inheritance-Single Inheritance transformations is defined and discussed. Keywords: Metamodeling, Model Transformation Languages, Role Based Modeling, Model Query Language.

8

9 IX TEŞEKKÜR Bu çalışmam süresince her türlü desteği sağlayan çok değerli danışmanım Sayın Prof. Dr. N. Yasemin Topaloğlu na teşekkürü bir borç bilirim. Çalışmam sırasında desteklerini hiç bir zaman esirgemeyen aileme, çalışma arkadaşım Ahmet Sıkıcı ya, arkadaşlarım Sinan Yıldırım, Zekai Demirezen, Tayfun Elmas, İnanç Seylan ve Önder Gürcan a teşekkür ederim.

10

11 XI İÇİNDEKİLER ÖZET... V ABSTRACT... VII TEŞEKKÜR... IX İÇİNDEKİLER... XI ŞEKİLLER DİZİNİ...XV 1 GİRİŞ MODEL TABANLI MÜHENDİSLİK Üst Modelleme ve Üst Model Katmanları Model Dönüşümleri Model Tabanlı Mühendislik için Teknik Uzaylar Model Tabanlı Mimari (Model Driven Architecture) Teknik Uzayı Diğer Teknik Uzaylar Ontoloji Teknik Uzayının Model Tabanlı Mühendislik Kapsamında İncelenmesi MODEL DÖNÜŞÜM DİLLERİ MOF 2.0 QVT RFP Kapsamında Geliştirilen Model Dönüşüm Dilleri için İstekler Czarnecki ve Helsen in Model Dönüşüm Dilleri Sınıflandırması ATL (ATLAS Transformation Language) Model Dönüşüm Dili ATL Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış Örnek Bir Dönüşüm... 30

12 XII 3.4 MOLA (MOdel transformation LAnguage) Model Dönüşüm Dili MOLA Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış Örnek Bir Dönüşüm TEFKAT Model Dönüşüm Dili TEFKAT Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış Örnek Bir Dönüşüm GREAT (Graph Rewriting and Transformation language) Model Dönüşüm Dili GREAT Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış Örnek Bir Dönüşüm YATL (Yet Another Transformation Language) Model Dönüşüm Dili YATL Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış Örnek Bir Dönüşüm MODEL DÖNÜŞÜM DİLLERİNİN DEĞERLENDİRİLMESİ Literatürdeki Çalışmalar Gronmo (Gronmo et al., 2005) Kurtev (Kurtev, 2005) Model Dönüşüm Kriterlerinin Sınıflandırılması ve Aralarındaki İlişkilerin Tanımlanması için Önerilen Yaklaşım Yapılan Çalışmalar Işığında Kriterlerin Sınıflandırılması Kriterlerin Sınıflandırma İçerisindeki Dağılımı ve Kriterler Arasındaki Bağlantılar Önerilen Kriterlere Göre Model Dönüşüm Dillerinin Değerlendirilmesi...64

13 XIII 5 ROL TABANLI MODEL SORGU DİLİ Çizge Kavramı ve Çizge Tabanlı Dönüşüm Araçları Rol Kavramı Rol ve Çizge Kavramlarının Tasarlanan Dil İçerisinde Kullanılması Sorgu Dili Üst Modeli ve Üst Model Katmanları Arasındaki İlişkiler Dil İçerisindeki Temel Yapılar Desen Eşleşmelerinde Belirsizlikleri Önlemek İçin Kullanılan Yapılar Rol Tabanlı Sorgu Tanımları UML-RDBMS Dönüşümü için Rol Tabanlı Sorgu Tanımı Çoklu Kalıtım Tekli Kalıtım Dönüşümü için Rol Tabanlı Sorgu Tanımları SONUÇ KAYNAKLAR DİZİNİ ÖZGEÇMİŞ

14 XIV

15 XV ŞEKİLLER DİZİNİ Şekil Sayfa Şekil 2.1 Model Tabanlı Mimari İlkeleri...4 Şekil 2.2 Model Tabanlı Mühendislik, Standartlar ve Araçlar...5 Şekil 2.3 Dört Katmanlı Yapı...7 Şekil 2.4 OMG nin Dört Katmanlı Üst Modelleme Alt Yapısı...8 Şekil 2.5 Üst Modele Dayanan Model Dönüşümleri...9 Şekil 2.6 İki Model Tabanlı Mühendislik Teknik Uzayı...11 Şekil 2.7 Teknik Uzaylar Arasındaki Köprüler...12 Şekil 2.8 Model Tabanlı Mimari Seviyeleri ve Bu Seviyeler Arasındaki Geçişler...14 Şekil 2.9 Ontoloji Teknik Uzayının Model Tabanlı Mimari Teknik Uzayı ile Çıkarsama İşlemi için Beraber Kullanımı...17 Şekil 2.10 Model Tabanlı Mimari Kapsamında Ontolojik Model Seviyeleri...18 Şekil 3.1 Desen Tabanlı Bir Model Dönüşümü...20 Şekil 3.2 AMMA Platformu...28 Şekil 3.3 ATL İşletim Motoru Mimarisi...29 Şekil 3.4 MOLA Araç Şeması...33 Şekil 3.5 Ana Dönüşüm Diyagramı...35 Şekil 3.6 CreateAttributeCopies Alt Dönüşümü...36 Şekil 3.7 GREAT Dönüşüm Platformu Bileşenleri...42 Şekil 3.8 Çoklu Kalıtım-Tekli Kalıtım Dönüşümünde Kaynak ve Hedef Desenler...43 Şekil 3.9 UML-Java Dönüşümü İçerisinde Tanımlanan Kurallar ve Kuralların İşletim Sırası...44 Şekil 3.10 CopyClasses Kuralının İç Yapısı...45 Şekil 3.11 CreateInheritance Kuralının İç Yapısı...46

16 XVI Şekil 4.1 Model Dönüşüm Dili Kriterlerinin Sınıflandırılması için Önerilen Yaklaşım...57 Şekil 4.2 Dönüşüm İçerisinde Tanımlı Bir İzlenebilirlik Bağlantısı...58 Şekil 4.3 Tanımlanan Dil Kriterleri ve Model Dönüşüm Dilleri...65 Şekil 5.1 Modeller ve Çizge Gösterimleri Arasındaki İlişki...70 Şekil 5.2 UML Mimarisi ile Model Rol İlişkisi...73 Şekil 5.3 Bir Class Rolünün Yapısı...73 Şekil 5.4 Modelleme Dillerini Oluşturan Katmanlar...75 Şekil 5.5 Sorgu Dilinin Üst Modeli (Soyut Sözdizimi)...76 Şekil 5.6 Sorgu Dilinin Anlamsal Alanı...77 Şekil 5.7 Kaynak Üst Model Sınıfları ve Roller Arasındaki İlişkiler...78 Şekil 5.8 Dönüşüm Üst Sınıfı ve <<Dönüşüm Rolü>> Arasındaki İlişki...78 Şekil 5.9 Örnek Sorgunun Sorgu Dili Üst Modeli Örnekleriyle İfadesi...80 Şekil 5.10 Basitleştirilmiş UML Üst Modeli...82 Şekil 5.11 RODEL Sorgu Dilinde Örnek Bir UML Model Sorgusu...83 Şekil 5.12 Yayıncı-Kitap UML Modeli...84 Şekil 5.13 Sorgunun İşletilmesi Sonucu Dönen Değerler...84 Şekil 5.14 Sorgu Tanımı İçerisindeki Mantıksal Operatörler...85 Şekil 5.15 Değil Operatörünün Rol Tanımları Arasındaki İlişkiler Üzerine Uygulanması...86 Şekil 5.16 Desen Tanımları...87 Şekil 5.17 Sabit Sayılı Bir Desenin Uygulama Modeli Üzerindeki Eşleşmeleri...88 Şekil 5.18 Rolü Oynayan Model Elemanları Arasındaki İlişkiler için Sayı Kısıtları...89 Şekil 5.19 Kaynak Üst Model Kullanılarak Kaynak Desenin Tutarlılığının Kontrolü...90 Şekil 5.20 UML-RDBMS Sorgu Deseni I...92 Şekil 5.21 UML-RDBMS Sorgu Deseni II...93

17 XVII Şekil 5.22 UML-RDBMS Sorgu Deseni III...94 Şekil 5.23 Çoklu Kalıtım Tipleri...95 Şekil 5.24 Tek Seviyeli Çoklu Kalıtım İçin Sorgu Tanımı...96 Şekil 5.25 İki Seviyeli Çoklu Kalıtım İçin Sorgu Tanımı...96

18

19 1 1 GİRİŞ Günümüz yazılım sistemlerinin çözüm getirmeye çalıştığı problemlerin karmaşık yapısı ve sistemlerin bir çok değişik alt sistemden oluşması, bu sistemlerin geliştirilmesini ve bakım işlemini zorlaştırmaktadır. Bu nedenle yazılım endüstrisi, yazılım teknolojileri açısından büyük bir rekabet içerisindedir. Bu rekabetin bir yansıması olarak yeni programlama dilleri, yeni platformlar ve yeni veri gösterim teknikleri geliştirilmektedir. Yeniden kullanılabilir ve bakım aşamasının daha yönetilebilir olduğu yazılımların geliştirilmesi, yazılım mühendisliği araştırmacılarının öncelikli hedeflerini oluşturmaktadır. Var olan sistemlerin büyüklüğü ve karmaşıklığı bu tip yazılım sistemlerinin tamamen kod tabanlı geliştirilmesini zorlaştırmaktadır. Bu nedenle yazılım geliştirme paradigmalarında kod seviyesinden daha soyut seviyelerde geliştirme yapma ihtiyacı hissedilmektedir. Yüksek seviyede yazılım geliştirme yaklaşımlarından biri olan model tabanlı yazılım geliştirme, yazılımların yeniden kullanılabilirliğinin ve bakım kolaylığının model geliştirme ve model dönüşümleri ile artırılması fikrine dayanmaktadır. Model tabanlı yazılım geliştirme içerisinde tanımlanan yaklaşımların bir çoğu, farklı soyutlama seviyelerindeki modeller arasında otomatik geçişler ile soyutlama seviyesi yüksek olan alan modellerinden nihai kaynak kodu üretmeyi amaçlamaktadır. Farklı soyutlama seviyelerindeki modelleri kullanarak çalıştırılabilir kaynak kod üretme amacı, otomatik model dönüşüm yaklaşımı ile mümkün olabilecektir. Model dönüşümlerini tanımlamanın en etkili yöntemlerinden biri model dönüşüm dillerini kullanmaktır. Dönüşümlerin tanımlanması ve uygulanması için kullanılan dil, programlama dillerinde olduğu gibi kontrol ve döngü ifadeleri içerebilir. Dönüşüm dilleri ile diğer model dönüşüm yaklaşımların da yapılamayan kaynak ve hedef modellerdeki değişken noktaların yakalanması, kuralların esnek olarak işletilmesi gibi işlemler gerçekleştirilir.

20 2 Bu tezde literatürde model dönüşüm dillerinin sınıflandırılması ve model dönüşüm dilleri kriterleri üzerine yapılan çalışmalar incelenmiştir. Bu çalışmalar ışığında model dönüşüm dillerinin sağlaması gereken genel kriterler ve bu kriterler arasındaki ilişkiler araştırılarak tanımlanan bu kriterler kapsamında bazı model dönüşüm dilleri değerlendirilmiştir. Bu değerlendirmeden yola çıkarak bir rol tabanlı model dönüşüm dilinin ilk parçası olan rol tabanlı sorgu dili tasarlanmıştır. 2. bölümünde, tez içerisinde yer alan temel kavramlar incelenmiştir. Bu bölümde anlatılan kavramlar ve tanımlar, diğer bölümlerin anlaşılabilmesi için gerekli olan temel bilgileri içermektedir 3. bölümde, model dönüşüm dillerinin sınıflandırılması üzerine yapılmış olan çalışmalar tarafından belirtilmiş dil özellikleri incelenmiştir. Ayrıca ATL, MOLA, TEFKAT, GREAT ve YATL model dönüşüm dilleri, bu özellikler ışığında incelenmiştir. 4. bölümde, model dönüşüm dillerinin değerlendirilmesi için literatürdeki iki farklı çalışma incelenmiş ve bu çalışmalardan yola çıkılarak bir model dönüşüm dilinin sağlaması gereken genel amaçlı istekler ve bu istekler arasındaki ilişkiler tanımlanmıştır. Son olarak da üçüncü bölümde incelenen model dönüşüm dillerinin, tanımlanan bu istekleri ne ölçüde desteklediği tartışılmıştır. 5. bölümde, model elemanlarının genel karakteristiklerini modelleyen Rol kavramını temel alan bir model sorgu dilinin tasarımı açıklanmıştır. 6. bölümde, tez çalışmasının sonuçları belirtilmiştir.

21 3 2 MODEL TABANLI MÜHENDİSLİK Günümüzde yazılım mühendisliği araştırmacılarının öncelikli hedefi, yazılım geliştirmede üretkenlik artışının sağlanması ve bakımı kolay yazılımların geliştirilmesidir. Model tabanlı yazılım geliştirme, yazılımların yeniden kullanılabilirliğinin ve bakım kolaylığının model geliştirme ve model dönüşümleri ile artırılması fikrine dayanmaktadır. Bu fikrin temeli ise, yazılım geliştirme paradigmasının bir seviye yükseltilerek yazılım geliştiricilerinin zamanlarının büyük bir kısmında program kaynak kodu geliştirmesi yerine değişik soyutlama seviyelerinde yazılım modelleri geliştirmesidir. Model tabanlı yazılım geliştirmenin, yazılım geliştirmedeki üretkenlik artışını; ve Yazılım geliştirmede soyutlama düzeyini kod seviyesinden model seviyesine çıkartarak, Yazılım ürünlerin teknolojik değişimlerden en az seviyede etkilenmesini sağlayarak, mümkün kılacağı öne sürülmektedir (Atkinson and Kuhne, 2002). Model Tabanlı Mühendislik (Model Driven Engineering MDE), yazılım sistemlerinin model tabanlı bir şekilde geliştirilebilmesi için ortaya konulan mühendislik ilkelerini kapsamaktadır. Model Tabanlı Mimari, OMG tarafından tanımlanmış olan MOF, XMI, OCL, UML, CWM ve SPEM gibi standartlar etrafında Model Tabanlı Mühendislik kavramlarının uygulanması olarak düşünülebilir. IBM manifesto (Booch et al., 2004), Model Tabanlı Mimari yaklaşımının doğrudan gösterim, otomasyon ve standartlar olmak üzere üç kavrama dayandığını belirtmektedir.

22 4 Şekil 2.1 Model Tabanlı Mimari İlkeleri (Booch et al, 2004) Doğrudan gösterim ile belirtilen, bir problemin alana özgü diller (domain specific languages) kullanılarak modellenmesi iken bu alana özgü modellerin otomatik model dönüşümleri ile uygulama modellerine dönüştürülmesi, otomasyon kavramı ile açıklanmıştır. Modellerin birbirine dönüştürülebilir olması ise bazı standartların gerekliliğini ortaya çıkarmıştır. Modellerin doğrudan gösterimi, Model Tabanlı Mimari içerisinde büyük önem taşımaktadır. Problemin bulunduğu alanda yer alan varlıklar ve bu varlıklar arasındaki ilişkiler, alana özgü modelleme dilinin (Domain Specific Modeling Languages DSML) üst modelinde tanımlanmaktadır. Bu nedenle modellerin genel amaçlı modelleme dilleri yerine alana özgü modelleme dilleri ile ifade edilmesi, problemin tam olarak ve yoruma açık olmadan kullanıcılar tarafından modellenebilmesini mümkün kılmaktadır. Bezivin (Bezivin, 2005), IBM manifesto tarafından Model Tabanlı Mimari için ortaya atılan kavramları Model Tabanlı Mühendislik kapsamında genelleştirebilmek için birbirini takip eden iki adım tanımlamaktadır. İlk olarak Model Tabanlı Mühendislik tanımını oluşturan ilkeleri tanımlanırken, daha sonra bu tanımlanan ilkelerin

23 uygulamasının yapıldığı araçlar oluşturulmaktadır. Bu tanıma göre Şekil 2.2 de Model Tabanlı Mühendislik içerisinde tanımlı değişik standartlar ve bu standartların kullanıldığı platformlar yer almaktadır (Bezivin, 2005). 5 Şekil 2.2 Model Tabanlı Mühendislik, Standartlar ve Araçlar (Bezivin, 2005) 2.1 Üst Modelleme ve Üst Model Katmanları Model tabanlı geliştirmenin ana etkinliği, model dönüşümleridir. Modeller arası işbirliğini ve dönüşümü sağlamada önemli bir bileşen, üst modelleme (meta-modeling) kavramı ve üst modellerdir. Bir üst model (meta-model), belirli bir modelleme dilinde geçerli olan modelleri tanımlayan bir modeldir (Seidewitz, 2003). Üst model gibi üst düzey tanımlamalar, modeller üzerinde çalışılmasını kolaylaştırırlar (Atkinson and Künhe, 2002). OMG tarafından 1997 yılında tanımlanan Unified Modeling Language (UML) (OMG, 2003b), son yıllarda nesneye yönelik yazılım geliştirmede yaygın kullanılan bir modelleme standardıdır. UML modelleri ile geliştirilen sistemin yapısı ve davranış şekli, farklı bakış açılarından gösterilebilir. Bunun yanı sıra UML modellerinin metinsel

24 6 olarak açıklanması için Object Constraint Language (OCL) (Warmer and Kleppe, 2003) tanımlanmıştır. Üst model kavramı, UML tanımının da temelini oluşturmaktadır. UML üst modeli, geçerli olan UML modellerinin sağlaması gereken kuralları tanımlamaktadır. OMG tarafından sadece UML üst modelini değil, benzer dillerin de tanımını sağlamak için MOF (OMG, 1997) adı verilen bir çerçeve tanımlanmıştır. UML üst modeli, nesneye yönelik yazılım sistemleri için model tanımlamada kullanılan dili sağlarken, MOF, üst modeller oluşturmak için kullanılan dili tanımlar. MOF ile, yazılım geliştirme alanında farklı konularda, örneğin; veri ambarı, iş akışı, yazılım süreci gibi, birbirleriyle uyumsuz üst modellerin tanımlanmasının önlenmesi amaçlanmıştır (Bezivin, 2001). MOF un dört katmanlı üst model yapısı şu şekildedir: Üst-üst model (M3): Üst-model katmanın gerçekleştirilmesi için gerekli üst yapılarının bulunduğu katman. Üst model (M2): Model katmanın üst-veri yapısının tanımlandığı katmandır. Üst-üst veri ya da üst-model katmanı olarak model tanımları için gerekli dili sunar. Model (M1): Bilgiyi yani veriyi tanımlayan üst-veriden oluşan model katmanı. Kullanıcı Nesneleri (M0): Veri diye tanımlanan ve anlatılmak istenen bilgiden oluşan kullanıcı nesneleri katmanı. Bu kapsamda, UML üst model düzeylerini Şekil 2.3 deki gibi örnekleyebiliriz:

25 7 Şekil 2.3 Dört katmanlı yapı (OMG, 2003b) Bezivin (Bezivin, 2001), dört katmanlı hiyerarşi içerisinde tanımlanan modeller ile programlama dilleri arasında bir benzerlik kurmuştur. Bu benzetimde M0 katmanındaki çalışma zamanı örnekleri Pascal programının belirli bir andaki çalışmasıyla, M1 katmanındaki kullanıcı modelleri bir Pascal programıyla, M2 katmanında tanımlı modelleme dili üst modeli, Pascal dil bilgisiyle ilişkilendirilirken M3 katmanında yer alan üst üst model ise çeşitli programlama dillerinin tanımına olanak sağlayan EBNF kurallarına benzemektedir. Bu katmanlı yapının daha iyi anlaşılabilmesi için Şekil 2.4 te programlama dilleri bakış açısıyla katmanlar örneklenmiştir.

26 8 Şekil 2.4 OMG nin Dört Katmanlı Üst Modelleme Alt Yapısı (Bezivin, 2001) 2.2 Model Dönüşümleri Model dönüşümleri, bir veya daha fazla kaynak modelin girdi olarak alınıp bir dizi dönüşüm kuralının uygulanması sonucunda bir veya daha fazla hedef modeli oluşturma süreci olarak tanımlanmaktadır (Sendall and Kozaczynski, 2003). Model dönüşümleri farklı hedefler için gerçekleştirilebilir (France and Bieman, 2001): Modeller, aynı soyutlama düzeyinde kalarak, sistemin farklı özelliklerini göstermek için kullanılabilir veya modeller iyileştirilebilir. Bu tür dönüşüm, yatay dönüşüm olarak nitelenmektedir. Modeller, daha yüksek bir soyutlama düzeyinden daha düşük bir soyutlama düzeyine geçmek için kullanılabilir. Bu tür dönüşüm, dikey dönüşüm olarak nitelendirilir. Örneğin,

27 Modellerden kaynak kodun üretilmesi bu tür bir dönüşüme örnektir. Model Tabanlı Mimari içerisinde platform bağımsız modellerin platform bağımlı modellere dönüştürülmesi de bir dikey dönüşümdür. Üst modele dayanan model dönüşümlerinde kaynak model, dönüşümün sonunda elde edilecek hedef model ve dönüşüm kuralları tanımlanmış olmalıdır. Model dönüşüm işleminde öncelikle başlangıç modeli yani kaynak modeli içerisinde kaynak üst modeller aranır ve değiştirilmek istenen yapılar belirlenir. Daha sonra model dönüşümü için tanımlanmış olan dönüşüm kuralları, belirlenen bu yapılar üzerinde uygulanır. Dönüşüm kurallarının uygulanması sonucu üretilen hedef modelin hedef üst modeline uygun olması gereklidir. Böylece üretilen modelin doğruluğu, hedef üst model ile yapılan eşlemelerde sınanır. Şekil 2.5 de görülen kaynak ve hedef üst modeller, dönüşüme girecek kaynak modeller ile dönüşüm sonucu elde edilecek hedef modellerin bilgilerinin tutulduğu modellerdir. 9 Şekil 2.5 Üst Modele Dayanan Model Dönüşümleri (Bezivin, 2001)

28 10 Sendall ve Kozaczynski (Sendall and Kozacynski, 2003), model dönüşümlerinin tanımlanmasında araçlar tarafından kullanılan yaklaşımları üçe ayırmıştır: Doğrudan Model İşleme: Bu yaklaşımda amaç, Rational gibi yazılım geliştirme araçları ile model üzerinde işlem yapılabilmesini sağlayan API ler yardımıyla modellerin dönüşüme uğratılmasıdır. Ara Gösterim: Bu yaklaşımda, model standart bir biçimde tanımlanır ve bu tanım üzerinde çalışır. Örneğin uygulama modelleri, kaynak ve hedef desenler; XMI formatında tutulur (Wagner, 2002) (Demirezen, 2004). Her biri üç ayrı XMI dosyasında tutulan uygulama modeli, kaynak ve hedef desen belleğe yüklenir. Daha sonra kaynak desen, uygulama modeli içerisinde aranarak uygulama modelinin dönüşüme uğratılacak kısımları belirlenir ve kaynak ve hedef desene göre ilgili kural dosyası işletilir. Genel olarak bu yaklaşımda dönüşüm kurallarının XSLT formatında kodlanması tercih edilmektedir. XSLT formatında kodlanmış kurallar belleğe yüklenip uygulama modeli üzerinde işletilerek dönüşüm gerçekleştirilmiş olur. Model dönüşümünün doğru gerçekleşip gerçekleşmediği ise ilgili hedef desenlerin dönüşüme uğrayan uygulama modeli üzerinde aranması ile belirlenir. Bu yaklaşımın bazı dezavantajları bulunmaktadır. Örneğin kaynak ve hedef desenlerin statik olarak XMI dosyaları içerisinde kodlanması, desenlerdeki her bir değişken nokta için değişik XMI dosyalarının var olmasını gerektirmektedir. Bu nedenle aynı dosya içerisinde And, Or, XOR gibi mantıksal operatörler belirtilememektedir. Yine ayrıca kuralların da statik olarak kodlanması, koşulların kontrol edilerek kuralların işletilmesini olanaksız kılmaktadır. Dönüşüm dili desteği: Bu yaklaşımda ise dönüşümlerin tanımlanması ve uygulanması için tanımlanan dil, programlama dillerinde olduğu gibi kontrol ve döngü ifadeleri içerebilir. Dönüşüm dili desteği ile ara gösterimde

29 11 yapılamayan kaynak ve hedef desenlerdeki değişken noktaların yakalanması, kuralların esnek olarak işletilmesi gibi işlemler gerçekleştirilir. Dönüşüm dilleri, bu desteği And, Or, XOR, If gibi mantıksal ifadeleri kullanarak verir. 2.3 Model Tabanlı Mühendislik için Teknik Uzaylar Teknik uzay, değişik teknolojilerin bir problemi çözmek için bir araya gelerek oluşturduğu toplam uzaydaki teknolojiler olarak tanımlanmaktadır (Kurtev et al., 2002). Teknik uzay kavramı ile teknolojileri daha soyut seviyede tanımlayarak bu teknolojiler arasındaki benzerlikleri, farklılıkları ve olası işbirliklerini tanımlamak amaçlanmaktadır. Bazı teknik uzaylar kolayca tanımlanabilir. Örneğin programlama dilleri (Java, C#), veritabanı sistemleri, markup diller (XML), bilgi gösterim dilleri (OWL, RDF), modelleme ortamları ve dillerinin (UML, Model Tabanlı Mimari, Model Bağlantılı Programlama) her biri; bir teknik uzayı oluşturmaktadır. Şekil 2.6 İki Model Tabanlı Mühendislik Teknik Uzayı (Bezivin, 2005) Şekil 2.6; Model Tabanlı Mühendislik, Model Tabanlı Mimari ve Microsoft Yazılım Fabrikaları (Microsoft Software Factories) yaklaşımları arasındaki ilişkileri teknik uzay bakış açısıyla tanımlamıştır

30 12 (Bezivin, 2005). Buna göre Model Tabanlı Mühendislik, bir teknik uzay iken Model Tabanlı Mimari ve Microsoft Yazılım Fabrikaları, Model Tabanlı Mühendislik teknik uzayının alt uzayı olan teknik uzaylardır. Teknik uzay kavramında birden fazla teknoloji arasındaki ilişkilerin tanımlanabilmesi için değişik teknik uzaylar arasında köprülerin (Bridge) tanımlanmış olması gerekmektedir (Bezivin and Kurtev, 2005). Tanımlanan bu köprüler ile birden fazla teknik uzay arasında geçişler sağlanarak bu teknik uzayların bir problemin çözümünde birbirini tamamlaması sağlanacaktır. Bezivin (Bezivin and Kurtev, 2005), iki teknik uzay arasında tanımlanan köprüleri technical projector olarak adlandırarak injector ve extractor olmak üzere iki farklı technical projector tanımlamıştır. Şekil 2.7 deki gibi Teknik Uzay 1 den Teknik Uzay 2 ye doğru tanımlanan ilk geçiş injector olarak adlandırılırken bu işlemin tam tersi yani eski teknik uzaya dönüş extractor olarak adlandırılmaktadır. Şekil 2.7 Teknik Uzaylar Arasındaki Köprüler Model Tabanlı Mimari (Model Driven Architecture) Teknik Uzayı Object Management Group un (OMG), Kasım 2000 tarihinde model tabanlı yazılım geliştirme için ortaya koyduğu Model Tabanlı Mimari (Model Driven Architecture MDA) (OMG, 2003a), Model

31 Tabanlı Mühendislik yaklaşımının bir uygulaması olarak tanımlanmaktadır. Model Tabanlı Mimari ile nesne modellerinin çalıştırılabilir bileşenlere ve uygulamalara dönüştürülerek yazılım sistemlerinin geliştirilmesi amaçlanmaktadır. Model Tabanlı Mimari kapsamında üç soyutlama seviyesi tanımlanmaktadır: Programlama Bağımsız Modeller (Computation Independent Models CIMs) Platform Bağımsız Modeller (Platform Independent Models PIMs) Platforma Özgü Modeller (Platform Specific Models PSMs) Tüm bu soyutlama seviyelerinin en altında da kaynak kod yer almaktadır. Geliştirici, programlama bağımsız modelleri kullanarak sadece problem içerisinde yer alan varlıkları ve bu varlıklar arasındaki ilişkileri modelleyecektir. Bu soyutlama seviyesindeki bir modelde uygulama ile ilgili herhangi bir bilgi yer almamaktadır. Ancak programlama bağımsız modellerden platform bağımsız modellere otomatik olarak geçebilmek için geliştirici, programlama bağımsız model üzerinde işaretleme işlemini yapmalıdır. Model dönüşüm tanımları ise programlama bağımsız modelde yer alan işaretlemelerden yola çıkarak bir alt seviyedeki platform bağımsız modeli oluşturacaktır. Platform bağımsız modeller, herhangi bir platformu temel almamasına rağmen programlanabilir yapıları içerisinde barındırmaktadır. Platform bağımsız modellerden herhangi bir platforma özgü modele geçiş tanımlanabileceği gibi bu modellerden doğrudan platforma özgü kaynak kod da üretilebilir olmalıdır. 13

32 14 Şekil 2.8 Model Tabanlı Mimari Seviyeleri ve Bu Seviyeler Arasındaki Geçişler (Topaloglu ve Goknil, 2004) OMG, bu model seviyeleri için sunduğu UML tabanlı tüm model ve üst modelleri dört katmanlı yapıyı göz önünde tutarak geliştirmektedir. UML genel amaçlı bir dil olmasına rağmen dile yeni profil paketleri eklenerek değişik seviyelerde değişik sistemler için modelleme ortamları oluşturulabilmektedir Diğer Teknik Uzaylar Model Tabanlı Mimari teknik uzayının haricinde Model Tabanlı Mühendislik kapsamında incelenebilecek bir çok teknik uzay tanımlanabilir. Bu teknik uzaylar içerisinde Model Tabanlı Mühendislik ile iç içe geçmiş olan teknik uzay XML teknik uzayıdır. OMG tarafından tanımlanan XMI (XML Metadata Interchange) (OMG, 2003c), Model Tabanlı Mimari teknik uzayı ile XML teknik uzayı arasında Model Tabanlı Mühendislik kapsamında tanımlanmış bir köprüdür. Diğer bir önemli teknik uzay ise programlama dilleri teknik uzayıdır. EMF (EMF, 2002) teknik uzayı ile Model Tabanlı Mimari teknik uzayı, birbirini tamamlayan teknik uzaylar olarak tanımlanabilir. Model Tabanlı Mimari, standartların tanımlandığı bir teknik uzay iken EMF ise bu standartların gerçekleştirildiği bir teknik uzaydır. EMF içerisinde tanımlı modelleme de aynı OMG nin üst modelleme yapısında olduğu

33 gibi dört katmana dayanmaktadır. EMF içerisinde tanımlı M3 katmanı Ecore (EMF, 2002) üst üst modelidir. Ecore üst üst modeli, MOF üst üst modelinden çok farklılık içermemesine karşın MOF a göre daha basitleştirilmiş bir üst modeldir. Microsoft DSL teknik uzayı, yazılım fabrikaları olarak adlandırılmaktadır (Greenfield et al., 2004). Model Tabanlı Mühendislik teknik uzayının altında tanımlanmış bir teknik uzay olup Model Tabanlı Mimari ile aynı hedefleri taşımasına rağmen yazılım geliştirme süreci içerisinde tanımladığı adımlar Model Tabanlı Mimari teknik uzayından farklılıklar göstermektedir. Bu teknik uzay içerisinde geliştirim için izlenecek adımlar; nesne modelin tanımlanması, modelleme dilinin somut söz diziminin belirlenmesi, kullanıcıların alana özgü yazılım sistemini tanımlayabilmesi için dilin grafik editörünün oluşturulması ve modelleme dili kullanılarak oluşturulmuş yazılım modellerinden kod üretecek yapıların oluşturulması şeklinde özetlenebilir. Değişik teknik uzaylar arasında ilgili işlemleri gerçekleştirebilmek için tanımlanan köprülerden bir tanesi de ontoloji teknik uzayı ile Model Tabanlı Mimari teknik uzayı arasında kurulabilecek köprüdür. M3 seviyesinde Web Ontology Language (OWL) (Dean et al., 2004) ile çıkarsama gibi işlemlerin yapılması, ontoloji teknik uzayında bu işlemler ile ilgili alt yapının tanımlanmış olmasından dolayı daha olası gözükmektedir. 2.4 Ontoloji Teknik Uzayının Model Tabanlı Mühendislik Kapsamında İncelenmesi 15 Ontoloji teknik uzayının Model Tabanlı Mühendislik kapsamında kullanılması için yapılan çalışmalar iki farklı açılımda ilerlemektedir. Bu açılımların ilki UML yapıları ve OWL yapıları arasında eşlemelerin ve dönüşümlerin tanımlanarak UML tabanlı ontoloji geliştiriminin sağlanması şeklindedir. Bu konudaki bir çok araştırma (Backlawski et al., 2002) (Falkovych et al., 2003) (Gasevic et al., 2004), UML alt yapısının ontoloji geliştirmek için uygun bir omurga görevi üstlenebileceğini göstermektedir. Bu çalışmaların sonucunda ise OMG M2 seviyesinde UML-OWL eşlemesinin tanımlanabilmesi için gerekli Ontoloji Üst

34 16 Modeli (Ontology Definition Metamodel ODM) (OMG, 2004) üzerinde çalışan bir çalışma grubu kurmuştur. Ontoloji üst modeliyle hedeflenen, UML modelleri kullanılarak ontoloji tanımlarını oluşturabilmektir. Bu şekilde bir gerçekleştirme için OWL ile ontoloji üst modeli arasında ve ontoloji üst modeli ile UML ontoloji profili arasında her iki yönde de eşlemeler tanımlanabilmelidir (Bezivin, Devedzic et al., 2005). Ontoloji teknik uzayının Model Tabanlı Mühendislik kapsamında kullanımı konusundaki çalışmalarda ikinci açılım ise, Model Tabanlı Mimari içerisindeki farklı yazılım modellerinin tanımında ve bu modeller arasındaki otomatik dönüşümlerde ontoloji dillerinden yararlanmak şeklindedir. Roser ve Bauer (Roser and Bauer, 2005), ontoloji tabanlı model dönüşümlerinin gerçekleştirilmesi için bir mimari önermektedirler. Önerdikleri mimari, üst modellerin tanımladığı söz dizim ile ontoloji yapılarının tanımladığı anlam arasında bir ilişki içermektedir. Bu önerilen mimarinin yanı sıra Pahl (Pahl, 2005), Model Tabanlı Mimari kapsamındaki Programlama Bağımsız Model, Platform Bağımsız Model ve Platforma Özgü Modellerin üst modelleme mekanizmasından bağımsız olarak ontoloji kavramları ve dilleriyle modellenebileceği ve bu ontolojiler arasındaki geçişlerin de ontoloji eşleme araçları ile gerçekleştirilebileceğini ileri sürmektedir. Ontoloji kullanılarak Model Tabanlı Mimari modellerinin oluşturulmasıyla modeller üzerinde çıkarsama işlemleri gerçekleştirilebilecektir (Pahl, 2005). Ontoloji tabanlı bir model dönüşüm alt yapısı için kullanılabilecek sorgu ve dönüşüm kurallarının ontolojik tanımları (Goknil and Topaloglu, 2005a) da yapılmıştır. Ontoloji ile model kavramlarını teknik uzay kapsamında incelediğimizde bu iki kavramın Model Tabanlı Mühendislik içerisinde kullanımında ontoloji teknik uzayı ile Model Tabanlı Mimari teknik uzayları arasında model çıkarsama işlemleri için bir köprü kurulabileceğini gördük. Üst modelleme alt yapısı anlamsal olarak çalışmadığı ve model çıkarsama işlemlerini doğrudan desteklemediği için modeller üzerinde çıkarsama işlemi gerektiği durumlarda ontoloji teknik uzayına geçilerek çıkarsama işlemleri gerçekleştirilir. İlgili işlem ontoloji teknik uzayı içerisinde gerçekleştirildikten sonra tekrar eski teknik uzaya geçilerek işlemlere kalınan yerden devam edilir. Şekil 2.9, ontoloji teknik

35 uzayının Model Tabanlı Mimari teknik uzayı ile çıkarsama işlemi için beraber kullanımı için önerilen yaklaşımı göstermektedir. 17 Şekil 2.9 Ontoloji Teknik Uzayının Model Tabanlı Mimari Teknik Uzayı ile Çıkarsama İşlemi için Beraber Kullanımı Programlama bağımsız modeller aslında birer alan modeli olduğu için alanın modellenmesi ilk olarak ontoloji teknik uzayı içerisinde alan ontolojisinin tanımlanması şeklinde gerçekleştirilebilir. Bu şekilde bir ontoloji geliştirimi bize aslında doğrudan ontoloji teknik uzayı içerisinde aynı zamanda programlama bağımsız modeller üzerinde (Xu, 2004) da anlatılan çıkarsama işlemlerinin otomatik olarak gerçekleştirilmesi imkanını verecektir. Alan ontolojisinin ontoloji teknik uzayında tanımlanıp çıkarsama işlemlerinin yapılmasından sonra Şekil 2.9 da gösterilen injector (1) işlemi ile Model Tabanlı Mimari teknik uzayına geçilmektedir. İki teknik uzay arasında tanımlanan bu injector işlemi ile M2 seviyesindeki ontoloji tanımları ile yine aynı seviyedeki üst modeller arasında veri transferi gerçekleştirilerek alan ontolojisinden alan modeli oluşturulmaktadır. Bu noktadan itibaren Model Tabanlı Mimari teknik uzayında hali hazırda seviyeler arasında tanımlanmış dönüşümler

36 18 gerçekleştirilir. Platform bağımsız model seviyesine inildiğinde eğer tekrar bir çıkarsama işlemi gerekirse yine iki teknik uzay arasında injector ve extractor işlemleri gerçekleştirilebilir. Bu şekilde iki teknik uzay arasında geçişlerin gerçekleştirilebilmesi için iki teknik uzay arasında gerekli köprünün kurulması gerekmektedir. Bu köprü ise Model Tabanlı Mimari içerisinde tanımlı üst modelleme kavramı ile ontoloji teknik uzayı içerisinde ontoloji kavramları arasındaki ilgili eşlemelerin tanımlanması ile mümkün olabilmektedir. Şekil 2.10, üst modelleme ile ontoloji kavramları arasındaki eşlemeyi göstermektedir. Buna göre Model Tabanlı Mimari teknik uzayında M3 seviyesinde bulunan MOF üst üst modeline karşılık ontoloji teknik uzayında OWL ın kendi içerisinde tanımlı temel yapılar yer almaktadır. (Goknil and Topaloglu, 2005b) de iki teknik uzay arasında tanımlanan bu köprü içerisinde model elemanları ile ontoloji elemanları arasındaki eşlemeler tanımlanmaktadır. Şekil 2.10 Model Tabanlı Mimari Kapsamında Ontolojik Model Seviyeleri (Goknil and Topaloglu, 2005b)

37 19 3 MODEL DÖNÜŞÜM DİLLERİ Model Tabanlı Mühendislik (Model Driven Engineering) (Bezivin, 2005) kapsamında model tabanlı yazılım geliştirmek için temel şart, farklı soyutlama seviyelerinde tanımlanan modeller arasında otomatik geçişler yapabilmektir. Böylece bir üst soyutlama seviyesinde tanımlanan bir model, daha önce tanımlanmış dönüşümleri kullanan model dönüşüm araçları ile daha alt soyutlama seviyesindeki modellere dönüştürülebilir. Model dönüşümleri ile program kaynak koduna en yakın seviyedeki yazılım modelinden çalıştırılabilir program kodu üretilmesi hedeflenmektedir. Model Tabanlı Mühendislik altında tanımlanan Model Tabanlı Mimari, EMF, Microsoft Yazılım Fabrikaları ve Model Bağlantılı Programlama gibi teknik uzayların her birinin temelini model dönüşümleri oluşturmaktadır. Model dönüşümleri için farklı yaklaşımlar tanımlanmıştır. Uygulamalar farklı teknik uzaylarda farklılıklar göstermekle birlikte model dönüşümleri, temelde uygulama modellerinin kaynak ve hedef desenler doğrultusunda dönüşüm kuralları uygulanarak dönüşüme uğratılmasını sağlamaktadır. Dönüşüm dili desteği yaklaşımında (Sendall and Kozaczynski, 2003), dönüşümlerin tanımlanması ve uygulanması için tanımlanan dil, programlama dillerinde olduğu gibi kontrol ve döngü ifadeleri içerebilir. Dönüşüm dili desteği ile ara gösterimde yapılamayan kaynak ve hedef desenlerdeki değişken noktaların yakalanması, kuralların esnek olarak işletilmesi gibi işlemler gerçekleştirilir. Bu bölümde öncelikle Model Tabanlı Mimari için model dönüşüm dillerinin sağlaması gereken kriterlerin anlatıldığı OMG QVT (OMG, 2002) ve Czarnecki ve Helsen tarafından dönüşüm dillerinin sınıflandırılması üzerine yapılmış olan çalışma (Czarnecki and Helsen, 2003) incelenmiştir. Literatürde yer alan model dönüşüm dillerinden ATL (Jouault and Kurtev, 2005), MOLA (Kalnins et al., 2004b), TEFKAT (Lawley and Steel, 2005), GREAT (Agrawal et al., 2003) ve YATL (Patrascoiu, 2004a) bu çalışmalar doğrultusunda incelenmiştir.

38 MOF 2.0 QVT RFP Kapsamında Geliştirilen Model Dönüşüm Dilleri için İstekler Desen tabanlı dönüşüm yaklaşımında (Judson et al., 2003) kaynak modeller daha önceden belirlenen kaynak desenlerinden yola çıkılarak hedef modele dönüştürülmektedir. Şekil 3.1, desen tabanlı dönüşüm yaklaşımının bir özetini vermektedir. Şekil 3.1 deki M2 seviyesi dönüşümün üst modelini desteklerken, M1 seviyesi de model dönüşümlerinin gerçekleştirilmesini tanımlamaktadır. T1 ile ifade edilen model dönüşümü, M1 seviyesindeki kaynak UML modelini alır ve hedef UML modeline dönüştürür. Dönüşüm deseni (Transformation Pattern) ise, kaynak ve hedef modellerinin tanımlarını ve bunlar arasındaki ilişkilerle ilgili kısıtlamaları içerir. Şekil 3.1 Desen Tabanlı Bir Model Dönüşümü (Judson et al., 2003) QVT, bir model dönüşümünü Sorgu (Query), Görünüm (View), ve Dönüşüm (Transformation) olmak üzere üç parçaya ayırmaktadır: Sorgu bölümü, kaynak modeli girdi olarak almakta ve bu model içerisindeki bazı model elemanlarını seçmektedir. Görünüm bölümü, diğer modellerden elde edilen alt modellerdir.

39 21 Dönüşüm bölümü ise modeli girdi olarak alır veya bu model üzerinde değişiklikler yapar ya da bu modelden yola çıkarak yeni bir model yaratır. Desen tabanlı model dönüşümlerinin model dönüşüm dilleri tarafından gerçekleştirilebilmesi için QVT kapsamında tanımlanan istekleri şu genel başlıklar altında toplayabiliriz (OMG, 2002): Şekil 3.1 de ifade edilen desen tabanlı bir model dönüşüm dilinde M2 katmanında belirtilen kaynak desenin M1 katmanındaki kaynak model içerisinde aranması gerekmektedir. Bir model dönüşüm dilinin bu işlemi gerçekleştirebilmesi için MOF modellerini sorgulayacak bir sorgu diline ihtiyacı vardır. Şekil 3.1 deki dönüşümde kaynak desen ve hedef desen elemanları arasındaki dönüşümleri göstererek kaynak modeli hedef modele dönüştüren dönüşüm kurallarının tanımlandığı dönüşüm deseni yer almaktadır. Bir model dönüşüm dilinde de bu kuralların ifade edileceği ve sorgu dilinde tespit edilen model elemanları üzerinde işletilecek dönüşüm kurallarının tanımlanacağı bir dil tanımlanmalıdır. Değişik kaynak desenler tanımlanabilir ve aynı kaynak desenden yola çıkılarak farklı hedef desenlere ulaşılabilir. Bu nedenle modelin tanımlanması için bir dil gereklidir. QVT dillerinin standartlaştırılması için öngörülen istekler, zorunlu istekler (mandatory requirements) ve zorunlu olmayan istekler (optional requirements) olmak üzere iki başlık altında toplanmaktadır. Zorunlu İstekler: Sorgu Dili (Query Language): MOF (OMG, 1997) tabanlı modelleri sorgulamak için bir dile ihtiyaç vardır.

40 22 Dönüşüm Dili (Transformation Language): QVT kapsamında yapılacak öneriler, dönüşüm tanımlamalarının yapılabilmesi için bir dil tanımlamalıdır. Tanımlanacak bu model dönüşümleri, MOF tabanlı modeller üzerinde işletilebilmelidirler. Soyut Söz Dizimi Tanımı (Abstract Syntax Definition): QVT dilleri, soyut söz dizimi tanımlarını MOF modelleri şeklinde yapmalıdırlar. Yani her bir dilin MOF tabanlı bir üst modeli olmalıdır. Görünüm Dili (View Language): QVT dilleri, modellerin değişik görünümlerinin yaratılmasını desteklemelidirler. Tanımlayıcı Dil (Declarative Language): QVT kapsamında yapılan önerilerde dönüşümlerin eksiksiz şekilde gerçekleştirilebilmesi için önerilen dilin tanımlayıcı (declerative) olması gerekmektedir. Zorunlu Olmayan İstekler: Çift Taraflı Dönüşüm Tanımları (Bidirectional transformation definitions): Geliştirilen diller, tanımlanan dönüşümleri her iki yönde de desteklemelidir. İzlenebilirlik (Traceability): Diller, model elemanları arasında tanımlanan izlenebilirlik bilgisini desteklemelidir. Bu, kaynak modelde bulunan hangi model elemanına karşılık hedef modelde hangi model elemanının yer aldığı bilgisinin tutulmasını sağlar. Yeniden Kullanılabilirlik Mekanizmaları (Reuse Mechanisms): QVT dilleri, daha genel tanımlanmış dönüşüm tanımlarının genişletilmesini ve yeniden kullanılmasını sağlayan mekanizmaları destekleyebilirler.

41 23 Hareketsel Dönüşümler (Transactional Transformations): Dönüşümlerin parçalarının işletilmesi bir hareket (transaction) olarak düşünülebilir. Varolan Modellerin Güncellenmesi (Update of existing models): Önerilen diller, kaynak ve hedef modellerin aynı model olduğu dönüşümleri destekleyebilir. Bu istekler, QVT kapsamında önerilen dillerin bir standart içinde gerçekleştirilmesi amacıyla ortaya konmuştur. Önerilen diller, bu ana maddeleri sağlamakla beraber kendileri de bazı ilave maddeleri destekleyebilirler. DSTC (Duddy et al., 2003) (Gerber et al., 2002), QVT RFP dokümanında belirtilen standartları bir model dönüşüm dilinin sağlaması gereken temel kriterler olarak ele aldıktan sonra bu kriterlere ek olarak kendi önerdikleri dil içerisinde bazı ek kriterler geliştirmiştir: Dönüşüm kuralları, model elemanlarını tek tek işleyebileceği gibi, model elemanları kümesini de işleyebilmelidir. Kurallar, kaynak ve hedef model elemanları arasında ilişkiler kurarak işletilmelidir. Kurallar, değişik üst seviyelerde eşleme yapabilmeli ve model elemanı oluşturabilmelidir. Bunun için de model dönüşümlerinde dinamik tipleme (dynamic typing) desteklenmelidir. Dönüşümler, hem kaynak modelde hem de hedef modelde oluşabilecek değişkenlikleri işleyebilmelidir. Çeşitli hedef elemanları tek bir kural içerisinde tanımlanabilmelidir.

42 24 Tek bir hedef elemanı, çeşitli kurallar tarafından tanımlanabilmelidir. Böylece değişik kurallar, aynı nesne için değerler üretebilir. Okunabilirliği ve modülerliği sağlamak için kurallar gruplandırılmalıdır. Model dönüşüm dili ya da dili işleyen dönüşüm motoru, dönüşüm kurallarının bir sıra dahilinde işletilmesini desteklemelidir. 3.2 Czarnecki ve Helsen in Model Dönüşüm Dilleri Sınıflandırması Czarnecki ve Helsen (Czarnecki and Helsen, 2003), var olan model dönüşüm dili yaklaşımlarını inceleyerek model dönüşüm dillerindeki ortak noktaları ve farklılıkları tartışmıştır. Tanımlanan bu özellikler, bu bölüm içerisinde incelenecek olan ATL, MOLA, TEFKAT, GREAT ve YATL model dönüşüm dillerini sınıflayabilmek ve birbirleriyle olan benzerliklerini tanımlayabilmek açısından önem taşımaktadır. Czarnecki ve Helsen in tanımladığı özellikler aşağıda kısaca açıklanmıştır: a) Kaynak-Hedef İlişkisi Bir dönüşüm işleminde, kaynak model ve hedef model aynı olabilir veya dönüşüm işlemi sonucunda oluşan hedef model ayrı bir model olabilir. b) Dönüşüm Kuralları Kaynak modelde yer alan bir eleman ile hedef modelde o elemana karşı gelen hedef model elemanı arasındaki işlemi tanımlayan kurallarda, kuralın yönü, kural parametreleri ve kuralda kullanılan ara yapılar açısından farklılıklar olabilir.

43 25 Kuralların Yönü (Directionality): Dönüşüm kuralları tek yönde (unidirectionality) tanımlanabileceği gibi her iki yön (bidirectionality) için de tanımlanabilir. Kural Parametreleri (Rule parametrization): Dönüşüm kuralları parametreler ile çağrılırlar. Aynı kural, dönüşümün içerisinde farklı parametrelerle farklı işlemler için kullanılabilir. Ara Yapılar (Intermediate Structures): Bazı diller kurallar içinde ara yapıların yer almasına izin verebilir. c) Kuralların Uygulanması Esnasında İzlenen Yaklaşımlar Bir kural, kaynak model içerisinde yer alan birden fazla model elemanı üzerine uygulanabilir. Bu durumda izlenebilecek değişik yöntemler mevcuttur: Deterministik Yaklaşım (Deterministic): Bu yaklaşımda kuralın her çalıştırılmasında bu kuralın uygulandığı model elemanları aynı sırada bulunur. Deterministik Olmayan Yaklaşım (Non-deterministic): Bu yaklaşımda kuralın her çalıştırılmasında kuralın model elemanları üzerine uygulanma sırası değişir. Etkileşimli (Interactive): Bu durumda kuralların uygulanma sırasını kullanıcı belirler. d) Kuralların Zamanlaması Kural zamanlaması ile hangi kuralın hangi sırada işletileceği tanımlanmaktadır.

44 26 Biçim (Form): İşletim sırası, içsel (implicit) ve dışsal (explicit) olmak üzere iki değişik şekilde belirtilebilir. Kural Seçimi (Rule Selection): Kuralların hangi sırada işletileceğinin seçimi kaynak model üzerinde belirtilen kurallara göre yapılabilir. Birden fazla kuralın aynı anda model elemanı üzerinde uygulanabileceği durumlarda ise kural önceliklerine bakılır. Kural Yinelemeleri (Rule Iteration): Kural yinelemeleri, özyineleme (recursion), döngü gibi temel yapılar ve bunların birleşiminden oluşabilir. Aşama (Phasing): Dönüşüm tanımları ardışık olarak işletilen aşamalara bölünebilir. e) Kuralların Organizasyonu Kuralların organizasyonu ile dönüşüm kuralları arasındaki ilişkiler düzenlenir. Bu ilişkilerin düzenlenmesinde üç farklı mekanizma tanımlanmıştır: Modül Mekanizmaları (Modularity mechanisms): Kurallar gruplanarak ayrı paketler altında toplanabilir ve bu paketler içerisinde yeniden kullanılabilirler. Yeniden Kullanım Mekanizmaları (Reuse mechanisms): Var olan kural tanımları kullanılarak yeni kural tanımları oluşturulabilir. Organizasyon Yapıları (Organizational structure): Kurallar; kaynak dile, hedef dile ya da başka faktörlere göre düzenlenebilir. Örneğin, kaynak modelin UML modeli olduğu bir dönüşümde UML de bulunan paket-sınıf-metot hiyerarşisinin aynısı kurallar için de geçerlidir.

45 27 f) İzlenebilirlik Bağlantıları İzlenebilirlik bağlantıları ile model dönüşümünün işletilmesi sırasında kaynak ve hedef model elemanları arasında kurulan ilişki tutulabilir. İzlenebilirlik bağlantıları, iki şekilde oluşturulabilir: Kullanıcı Tabanlı (user-based): Model elemanları arasındaki bağlantıları kullanıcı tanımlar Adanmış Destek (Dedicated Support): Model dönüşüm dili ve model dönüşüm motoru, model elemanları arasındaki bağlantıları tanımlar. g) Dönüşüm Yönü Model dönüşüm dilleri, kuralların kaynak modelden hedef modele tek yönlü veya iki yönlü tanımlanmalarına izin verirler. Czarnecki ve Helsen, tanımladıkları bu sınıflandırma kriterleri ile var olan model dönüşüm dillerinin alan analizini yapmıştır. Burada kısaca, tanımladıkları değişken noktaları ve kategorileri belirttik. Bu değişken noktalar, bir model dönüşüm dilinin tasarımında verilen kararları yansıtmaktadır. Bu nedenle bölüm içerisinde ilgili model dönüşüm dillerini ve bu dillerin tasarımlarını incelerken Czarnecki ve Helsen tarafından tanımlanan bu değişken noktalar önem taşımaktadır. 3.3 ATL (ATLAS Transformation Language) Model Dönüşüm Dili ATLAS Model Transformation Language (ATL) (Jouault and Kurtev, 2005) (Bezivin et al., 2003), Fransa daki Nantes Üniversitesinde Prof. Dr. Jean Bezivin ve ekibi (ATLAS Grup) tarafından geliştirilmiş bir model dönüşüm dilidir. ATL, QVT standartlarını temel almasına rağmen hızlı geliştirim yapabilmek için Eclipse Modeling Framework (EMF) (EMF, 2002) çatısı altında geliştirildiğinden dolayı MOF üst modeli

46 28 benzeri Eclipse ECore üst modelini desteklemektedir. ATL dili, AMMA model platformunun bir parçasıdır. AMMA platformu, ATL ile birlikte dört ayrı bileşenden oluşmaktadır: Atlas Transformation Language (ATL), Atlas ModelWeaver (AMW), Atlas MegaModel Management (AM3), Atlas Technical Projectors (ATP). ATL, tanımlayıcı ve prosedürel özelliklerini taşıyan bir dil olup temel olarak desen tabanlı model dönüşüm yaklaşımını benimsemiştir. Platform içerisinde AMW aracı üst modeller arasında tanımlanan eşlemelerden yola çıkarak otomatik olarak ATL dönüşüm kodu üretmektedir (Fabro and Jouault, 2005). Şekil 3.2 AMMA Platformu (Bezivin, 2005) ATL Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış ATL dönüşüm alt yapısı, değişik katmanlardan ve bu katmanlar içerisinde birbiriyle haberleşen bileşenlerden meydana gelmektedir. Şekil 3.3, ATL işletim motoru mimarisini göstermektedir. Buna göre ATL dönüşüm alt yapısı; ATL derleyicisi, ATL programları, ATL sanal makinası, model soyutlama katmanı, model ambarından XMI formatında kodlanmış model elemanlarını belleğe yükleyen EMF ve MDR bileşenlerinden oluşmaktadır. Bu bileşenler içerisinde ATL sanal makinası, ATL derleyicisi tarafından oluşturulmuş byte kodunu çalıştırmaktadır.

47 29 Şekil 3.3 ATL İşletim Motoru Mimarisi (Jouault and Kurtev, 2005) ATL de kaynak ve hedef modeller, farklı modellerdir. Kaynak model için sadece okuma izni verilirken hedef modeller için sadece yazma yetkisi verilmiştir. Bu nedenle modellerin iyileştirilmesini (model refactoring) amaçlayan kaynak ve hedef modelin aynı olduğu ve kaynak model için yapılan değişikliklerin aynı model üzerine yansıtıldığı dönüşümler, ATL tarafından doğrudan desteklenmemektedir. ATL, bu tip dönüşümleri dolaylı olarak destekleyebilmek için refining mode adı verilen bir modda çalışmaktadır. ATL nin dönüşüm kuralları, bir dönüşüm tanımı içerisinde tek yönlü olarak işletilirler. Kural içerisinde kaynak ve hedef model elemanları, söz dizimsel olarak ayrı yapılar içerisinde tanımlanmaktadır. Kurallara parametre geçirilmesi ise sadece dışarıdan çağrılabilen called rules adı verilen özel kurallar için desteklenmektedir. ATL, kuralların uygulanması için deterministik olmayan yaklaşımı desteklemektedir. Normal kural yapısı içerisinde tanımlanan kuralların model elemanları üzerindeki uygulanma sırası, dönüşümün her çalıştırılmasında farklı olabilmektedir. ATL, kuralların uygulanma yaklaşımını kullanıcının belirlediği etkileşimli yaklaşımı

48 30 desteklememektedir. Kuralların organizasyonu için ATL, içerdiği modül ve kütüphane yapıları ile modül mekanizmalarını desteklemektedir. Yardımcı kural (Helper rules) adı verilen kurallar, kütüphane yapıları içerisinde tanımlanarak birden fazla kural ve dönüşüm tarafından ortak olarak kullanılmasına imkan verilmektedir. İzlenebilirlik bağlantıları için ATL, adanmış destek yaklaşımı izlenmektedir. Buna göre ATL dili ve dönüşüm tanımlarını işleyen dönüşüm motoru, izlenebilirlik bağlantılarını oluşturur. Kuralların zamanlaması konusunda ATL, hem içsel hem de dışsal kural çağrımlarının her ikisine de destek vermektedir. Buna göre matched rules adı verilen model elemanıyla eşlenilmesi durumunda çalıştırılan normal kural tanımlarının çağırılması içsel (implicit) olarak gerçekleştirilir. Bunun yanı sıra çağırılan kurallar (called rules) dışsal olarak başka bir kural tarafından gerektiğinde parametre geçirilerek çağrılmaktadır Örnek Bir Dönüşüm ATL içerisinde dönüşüm tanımları modül başlıkları altında toplanmıştır. Bir modül içerisinde header adı verilen başlık bölümü, diğer modüllerin ve kuralların dönüşüm içerisine alındığı import bölümü, helpers adı verilen yapılar ile dönüşüm kurallarını içermektedir. Başlık bölümünde dönüşüm modülünün ismi verildikten sonra kaynak ve hedef modeller türedikleri üst modeller ile birlikte belirtilir. Aşağıda örnek UML model - RDBMS model dönüşümü için tanımlanmış başlık bölümü belirtilmektedir. module SimpleClass2SimpleRDBMS; create OUT : SimpleRDBMS from IN : SimpleClass; Bu başlık bölümünde create kelimesi ile OUT isimli hedef model belirtilirken from kelimesi ile de IN isimli kaynak model belirtilmektedir. SimpleRDBMS ve SimpleClass ifadeleri, bu kaynak ve hedef modellerin türedikleri üst modelleri tanımlamaktadır.

49 Başlık bölümünden sonra tanımlanan yardımcı kurallar (helper rules) ve dönüşüm kuralları, dönüşümün görevini tanımlayan bölümlerdir. ATL içerisinde tanımlanan yardımcı kurallar, diğer kurallar tarafından ortak olarak çağırılabilen ara yapılardır. Aşağıda bir yardımcı kural tanımı (Jouault and Kurtev, 2005) verilmiştir. 31 helper context SimpleClass!Class def : allattributes : Sequence(SimpleClass!Attribute) = self.attrs->union( if not self.parent.oclisundefined() then self.parent.allattributes->select(attr not self.attrs->exists(at at.name = ) else Sequence {} endif )->flatten(); attr.name) allattributes ismiyle tanımlanmış olan yardımcı kural, parametre olarak geçirilen ilgili sınıfın kalıtım yoluyla üst sınıflardan alınan özellikleri de dahil olmak üzere bütün özelliklerini sorgulamaktadır. ATL nin tanımlayıcı kural yapısı ise eşlenen kurallar şeklinde adlandırılmaktadır. Eşlenen bir kural; kaynak desen elemanları, hedef desen elemanları, kaynak desen elemanları üzerindeki OCL kısıtları ve kaynak desen elemanları ile hedef desen elemanları arasındaki atama operatörlerinden oluşmaktadır. Dilin şu anki kural yapısında bire-çok (mn) eşleme yapılmaktadır. Yani kaynak desen elemanı olarak tek bir eleman belirtilebilirken hedef desen elemanı olarak da birden fazla eleman kullanılabilmektedir. Aşağıda kaynak model içerisinde kalıcı olarak tanımlanmış sınıfları hedef modelde tablo yapısı olarak tanımlayan örnek bir kural (Jouault and Kurtev, 2005) verilmiştir. rule PersistentClass2Table{ from c : SimpleClass!Class ( c.is_persistent and c.parent.oclisundefined() )

50 32 } to t : SimpleRDBMS!Table ( name <- c.name ) PersistentClass2Table adıyla tanımlanan yukarıdaki kural tanımı içerisinde from kelimesinden sonra belirtilen tanım ile SimpleClass üst modelinde tanımlı Class ların ilgili koşutları sağlaması durumunda c değişkenine bağlanması ifade edilmektedir. Bu ifadeden sonra gelen kısıt yapıları ile c değişkenine bağlanacak Class ların kalıcı özelliğe sahip olması koşulu tanımlanmıştır. to kelimesinden sonra ise c değişkenine bağlanan her bir kaynak model elemanı için hedef üst model olan SimpleRDBMS üst modelinden türeyen hedef modelde Table üst sınıfından türemiş bir model elemanının yaratılacağı belirtilmiştir. name <- c.name ataması ile ise kaynak modelde eşlenen her bir model elemanı için hedef modelde yaratılan model elemanının name özelliğine eşlenen kaynak model elemanının name özelliğinin değerinin atanması gerçekleştirilmektedir. 3.4 MOLA (MOdel transformation LAnguage) Model Dönüşüm Dili MOLA (Model transformation LAnguage) (Kalnins et al, 2004b) (Kalnins et al, 2005), Letonya daki Latvia Üniversitesinde Prof. Dr. Audris Kalnins ve ekibi tarafından geliştirilmiş bir model dönüşüm dilidir. MOLA, QVT standartları kapsamında geliştirilmesinin yanında çizge dönüşümlerini temel alan grafik gösterime sahip bir model dönüşüm dilidir MOLA Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış MOLA dönüşüm alt yapısı, Dönüşüm Tanımlama Ortamı (Transformation Definition Environment) ve Dönüşüm İşletim Ortamı (Transformation Execution Environment) olmak üzere iki kısımdan oluşmaktadır. Her iki ortam da ilişkisel veritabanına dayanan çalışma

51 zamanı ambarını (runtime repository) kullanmaktadır. Bu ilişkisel veritabanı içerisinde dönüşümler, üst modeller ve modeller tutulmaktadır. MOLA nın dönüşüm tanımlama ortamı MOF sınıflandırması içerisinde M2 seviyesine karşılık gelen üst model seviyesinde yer almaktadır. Dil içerisindeki yapıların grafiksel olarak gösterilmesi nedeniyle dönüşüm tanımlama ortamı grafik çizim editörü şeklinde davranmaktadır. Bu ortam, aynı üniversite tarafından geliştirilen Generic Modeling Framework (GMF) alt yapısı (Celm et al., 2003) üzerine kurulmuştur. Dönüşüm tanımlama ortamı aynı zamanda içerisinde MOLA derleyicisini de içermektedir. Böylece, tanımlanan dönüşümlerin söz dizimi kontrolleri yapılarak bütün üst modeller ve dönüşüm tanımları GMF formatından MOLA nın çalışma zamanı formatına çevrilebilmektedir. Dönüşüm işletim ortamı ise MOLA sanal makinesi üzerine kurularak bir yorumlayıcı ile çalışma zamanı ambarında bulunan örnekler işletilir. MOLA sanal makinesi, dil içerisinde tanımlanmış dönüşüm ifadelerini SQL sorgularına çevirerek dönüşümü gerçekleştirmektedir. Buna göre Şekil 3.4, genel olarak MOLA içerisinde yer alan bileşenleri ve araçları göstermektedir. 33 Şekil 3.4 MOLA Araç Şeması (Kalnins et al, 2005) MOLA, dönüşüm kurallarına parametre geçirilmesini desteklemektedir. Dönüşüm tanımları, dil içerisinde aynı prosedürel programlama dillerinde olduğu gibi ana dönüşüm ve alt dönüşüm olmak üzere ikiye ayrılmaktadır. Ana dönüşüm içerisinde alt dönüşümler

52 34 parametreli ya da parametresiz olmak üzere çağrılabilir. Kurallar ise tek yönlüdür. Aynı dönüşüm tanımı içerisinde hem kaynak modelden hedef modele hem de hedef modelden kaynak modele dönüşüm tanımlanamamaktadır. Kuralların işletim sırasının belirtilmesi etkileşimli olarak kullanıcıya bırakılmaktadır. Ana dönüşüm içerisinde alt dönüşümlerin sırası kullanıcının tercihine bağlı olarak tanımlanmaktadır. Alt dönüşüm içerisinde ise kurallar yine kullanıcı tarafından sıralanır. MOLA dilinde sağlanan döngü yapısı ile kurallar gruplanarak yinelemeler olarak işletilebilir. Kurallar, model elemanları üzerinde farklı sıralarda uygulanabilir. İzlenebilirlik bağlantıları ise kullanıcı tabanlıdır. Kullanıcının kaynak ve hedef model elemanları arasında tanımladığı işlemler aynı zamanda kaynak ve hedef model elemanları arasındaki izlenebilirlik bağlantılarını oluşturmaktadır Örnek Bir Dönüşüm Bu bölümde MOLA dili kullanılarak UML modellerinin RDBMS modellerine dönüştürülmesi için tanımlanan alt dönüşüm adımları anlatılmıştır. Şekil 3.5 de, UML model RDBMS model dönüşümü için MOLA da tanımlanan ana dönüşüm ve ana dönüşüm içerisindeki dört alt dönüşüm gösterilmiştir.

53 35 Şekil 3.5 Ana Dönüşüm Diyagramı (Kalnins et al, 2004a) Şekil 3.5 de verilen ana dönüşüm Class model elemanı ve diğer üç alt dönüşümü için bir FOREACH döngüsü içermektedir. MOLA içerisinde bu tip döngüler kalın çerçeveli dikdörtgen ile ifade edilmektedir. Bu dikdörtgenin içerisinde Class model elemanı ve diğer üç alt dönüşümün belirtilmesiyle birlikte bütün bu tanımlanan yapılar döngü içerisine alınmaktadır. Döngünün içerisinde ilk olarak Class yapısına eşlenen model elemanları c adı verilen değişkene atanmaktadır. Bu ifadenin de kalın dikdörtgen içerisine alınması bir döngü içerisinde kaynak modelin dolaşılarak c değişkenin eşlenen bütün elemanları bir küme halinde tutmasını sağlamaktadır. {kind= persistent } ifadesi ile de Class model elemanlarının c değişkenine eşlenebilmeleri için kalıcı olma kısıtı belirtilmiştir. İlk olarak eşlenen bütün Class lara ait Attribute ler kopyalanmakta daha sonra bu Class ve Attribute lere karşılık Table ve Column yapıları hedef model içerisinde oluşturulmakta

54 36 ve son olarak da daha önce kaynak model içerisinde oluşturulan kopya Attribute ler silinmektedir. Bütün bu işlemler sırasıyla CreateAttributeCopies, BuildTableColumns ve DeleteCopies alt dönüşümlerinin her bir model elemanı için teker teker bir döngü içerisinde çağrılmasıyla sağlanmaktadır. Ana döngüden çıkıldıktan sonra çağırılan AssociationToForeignKeys alt dönüşümü ile kaynak modelde yer alan bütün Association yapılara karşılık hedef modelde ilgili Table yapıları içerisinde ForeignKey yapıları oluşturulmaktadır. Şekil 3.6 CreateAttributeCopies Alt Dönüşümü (Kalnins et al, 2004a)

55 Şekil 3.6 ise ana dönüşüm içerisinde parametre gönderimi ile çağırılan CreateAttributeCopies alt dönüşümünü göstermektedir. Bu alt dönüşüm içerisinde iki tanesi iç içe olmak üzere üç FOREACH döngüsü içererek bu dönüşümü takip eden diğer alt dönüşümlerin Table ve bunlara bağlı Column yapılarını oluşturabilmeleri için eşlenen Class yapılarının sahip oldukları Attribute leri kopyalamaktadır TEFKAT Model Dönüşüm Dili TEFKAT model dönüşüm dili, Avustralya nın Quensland üniversitesinde Pegamento projesi kapsamında Dr. Michael Lawley ve ekibi tarafından geliştirilmiş tanımlayıcı (declerative) bir model dönüşüm dilidir (Lawley and Steel, 2005) (Duddy et al, 2003). TEFKAT dili, mantık tabanlı (logic based) ve MOF üst modelini destekleyen bir dildir. OMG nin MOF QVT kapsamında tanımlamış olduğu model dönüşüm dili istekleri doğrultusunda tasarlanmış bir dil olup ayrıca QVT RFP için de bir teklif belgesi (DSTC et al, 2003) hazırlanmıştır. Genel olarak dönüşüm dili, MOF meta elemanlarını da kapsayan bir dönüşüm üst modelini (transformation metamodel) içermektedir. Bu dönüşüm üst modeli, dil içerisinde tanımlı bütün kural ve dönüşüm elemanlarını kapsamaktadır. Dil, dönüşüm deseni ve kurallar olmak üzere ikiye ayrılmaktadır. Dönüşüm deseni, uygulama modelinde değiştirilecek model elemanlarını belirleyen sorgu cümleciklerini oluştururken, kurallar ise uygulama modeli üzerinde çalıştırılan dönüşüm işlemlerini temsil etmektedir TEFKAT Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış TEFKAT dönüşüm motoru, Eclipse ortamı içerisinde geliştirilmiştir. Bu nedenle kullanıcılar dönüşüm motorunu Eclipse ortamına uyumlu bir yazılım olarak (eclipse plug-in) kullanabilirler. Dil, metinsel bir söz dizime sahip olmakla birlikte dil editörü içerisinde dönüşümü izleyebilmek ve sınayabilmek için debug ortamı mevcuttur.

56 38 TEFKAT dili, kaynak ve hedef modelin aynı model olduğu dönüşümleri desteklememektedir. Dönüşüme girdi olarak birden fazla sayıda kaynak model tanımlanabilirken, dönüşümden çıktı olarak da birden fazla hedef model tanımlanabilir. Dönüşüm kuralları parametre alarak, bu parametreler ile çağrılabilirler. Bu şekilde aynı kural dönüşümün içerisinde farklı parametrelerle farklı işlemler için kullanılabilir. TEFKAT, kuralların uygulanmasında deterministik olmayan yaklaşımı desteklemektedir. Normal kural yapısı içerisinde tanımlanan kuralların model elemanları üzerindeki uygulanma sırası, dönüşümün her çalıştırılmasında farklı olabilmektedir. Kuralların organizasyonu kapsamında TEFKAT içerdiği modül ve kütüphane yapıları ile modül mekanizmalarını desteklemektedir. İzlenebilirlik bağlantıları kullanıcı tabanlıdır. Kuralların zamanlaması konusunda TEFKAT, hem içsel hem de dışsal kural çağrımlarının her ikisine de destek vermektedir. TEFKAT da etkileşimli bir ortam bulunmaktadır. Kurallar, dönüşüm içerisinde sırayla yazılır ancak kuralların işletiminde bu sıra önemli değildir. Bir kural içerisinden başka kuralın çağrılması ise içsel çağrım (implicit rule call) ile sağlanır. Bunun yanı sıra bir kuralın sorgu bölümünde dışsal (explicit) olarak özyineli bir şekilde aynı sorgu ya da başka bir sorgu çağrılabilir. Dilin soyut söz dizimi MOF üst modeline dayanmaktadır. TEFKAT ile tanımlanan dönüşümler, MOF üst modeline dayanan dil üst modelinden türeyen modeller şeklinde belirtilmektedir. Dilin somut söz dizimi ise metinsel bir gösterime sahiptir Örnek Bir Dönüşüm TEFKAT içerisinde dönüşüm tanımları Transformation deyimi ile yapılmaktadır. Bir dönüşüm; içerisinde genel olarak Transformation adı verilen başlık bölümü, kaynak ve hedef üst modellerin içerisine alındığı import bölümü, izlenebilirlik bağlantılarının yapıldığı Tracking adı verilen yapılar ile dönüşüm kurallarını içermektedir. Başlık bölümünde dönüşümün ismi verildikten sonra kaynak ve hedef model isimleri belirtilir. IMPORT deyimleri ile birlikte de belirtilen kaynak ve hedef modellerin dayandığı kaynak ve hedef üst modelleri

57 dönüşüm içerisinde tanımlanır. Aşağıda örnek UML model RDBMS model dönüşümü için tanımlanmış başlık bölümü belirtilmektedir. 39 TRANSFORMATION mtip05_class_to_relational: class -> relational IMPORT IMPORT Başlık bölümünden sonra izlenebilirlik bağlantılarının tanımlandığı sınıf ifadeleri tanımlanmaktadır. Örnek dönüşümde kaynak ve hedef modeller için Class model elemanı ile Table model elemanı ve Attribute model elemanı ile Column model elemanı arasında izlenebilirlik bağlantısını tanımlayan iki sınıf ifadesi yer almaktadır. CLASS ClsToTbl { Class class; Table table; }; CLASS AttrToCol { Class class; Attribute attr; Column col; }; TEFKAT içerisinde kullanılan söz diziminde kurallar SQL benzeri ifadeler ile belirtilmektedir. Her bir kural kaynak ve hedef olmak üzere iki tane kısıt içermektedir. WHERE ifadesi ile kuralın eşleşeceği kaynak model içerisindeki model elemanlarına ait kısıtlar yazılırken MAKE ifadesi ile de eşlenen kaynak model elemanlarına karşılık hedef model içerisinde oluşturulacak model elemanları tanımlanmaktadır. LINKING bölümünde daha önce tanımlanan sınıf yapıları kullanılarak kural içerisinde izlenebilirlik bağlantıları tanımlanır. SET ifadesi ise MAKE ifadesi içerisinde oluşturulan hedef model elemanlarına ait özelliklerin atamalarının yapıldığı bölümdür. Aşağıda verilen ClassAndTable adlı kural (Lawley and Steel, 2005) ile kaynak model içerisindeki her bir Class yapısına karşılık hedef model içerisinde Table yapısı

58 40 oluşturulmaktadır. Kural C ve T parametrelerini dışarıdan aldığı için dışsal olarak çağırılan bir kuraldır. RULE ClassAndTable(C, T) FORALL Class C { is_persistent: true; name: N; } MAKE Table T { name: N } LINKING ClsToTbl WITH class = C, table = T; Aşağıda verilen MakeColumns kuralı (Lawley and Steel, 2005) ile de ClassAndTable kuralı ile oluşturulan Table model elemanları için kaynak modelde yer alan her bir Attribute model elemanına karşılık hedef model tarafında ilgili Column model elemanı oluşturulmaktadır. RULE MakeColumns WHERE ClassHasAttr(C, A, N, IsKey) AND ClsToTbl LINKS class = C, table = T MAKE Column Col FROM col(c, N) { name: N; type: A.type.name; } SET T.cols = Col, IF IsKey = true THEN SET T.pKey = Col ENDIF LINKING AttrToCol WITH class = C, attr = A, col = C;

59 3.6 GREAT (Graph Rewriting and Transformation language) Model Dönüşüm Dili 41 GREAT model dönüşüm dili ABD nin Vanderbilt üniversitesinde Dr. Gabor Karsai ve ekibi tarafından geliştirilmiş çizge tabanlı bir model dönüşüm dilidir (Agrawal et al, 2003) (Agrawal et al, 2004) (Agrawal, 2004). GREAT dili, MOF ya da ECore gibi Model Tabanlı Mimari kapsamında geliştirilen ve benzerlikler taşıyan modelleme alt yapılarını kullanmak yerine Model Bağlantılı Programlama (Model Integrated Computing - MIC) (Sztipanovitz and Karsai, 1997) yaklaşımı çerçevesinde geliştirilen Generic Modeling Environment (GME) (Agrawal et al, 2003) modelleme ortamı kullanılarak geliştirilmiştir GREAT Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış GREAT dönüşüm alt yapısı kural işleyici (rule executor) ve kural sıralayıcı (sequencer) olmak üzere iki farklı bileşenden oluşmaktadır. Kural işleyici, bir kural içerisinde tanımlanan kaynak desen, hedef desen ve dönüşüm kurallarını alıp yorumlayarak ilk önce kaynak desen tarafından belirtilen problemi kaynak model içerisinde arar. Bu arama işleminden uygun bir eşleşme döndüğü takdirde kural işleyici, dönüşüm kurallarını hedef desen içerisinde belirtilen örnek modele göre eşlenen model üzerinde uygulayarak hedef modeli oluşturur. Kural işleyici, desenin eşlenmesi ve dönüşüm kurallarının model üzerinde uygulanabilmesi amacıyla desen eşleyici (pattern matcher) ve uygulayıcı (effecter) olmak üzere iki bileşenden oluşmaktadır. GREAT kullanılarak aynı model dönüşümü içerisinde birden fazla kural tanımlanabileceği için bu kuralların geliştirici tarafından belirtilen sıraya göre dönüşüm motoru tarafından işletilmesi kural sıralayıcı tarafından gerçekleştirilmektedir. GREAT, kuralların hem ardışık hem de paralel işletilmesine destek vermesine rağmen kuralların işletim sırasının belirlenmesini dışsal olarak dönüşümü geliştiren kişiye bırakmaktadır. Dönüşüm platformu bütün bu bileşenlerin kullanacağı modelleme API lerini de içermektedir. Kural işleyici, Universal Data Model (UDM) API yi kullanırken kural sıralayıcı Graph Rewrite (GR) API yi kullanmaktadır. Şekil 3.7, GREAT dönüşüm platformu içerisindeki bileşenleri ve aralarındaki ilişkiyi göstermektedir.

60 42 Şekil 3.7 GREAT Dönüşüm Platformu Bileşenleri (Agrawal et al., 2003) GREAT, dil kaynak-hedef ilişkisi bakımından kaynak ve hedef modellerin aynı olduğu dönüşümleri de destekleyebilmektedir. Kurallar, dönüşüm içerisinde tek yönlü tanımlanabilmektedir. GREAT, kurallara parametre geçirilmesini desteklemektedir. Bir kuraldan dönen model elemanları diğer kural içerisine parametre olarak gönderilerek aynı model elemanlarının dönüşüm motoru tarafından tekrar eşlemek zorunda kalması önlenir. Kuralların yanında test yapıları da GREAT içerisinde desteklenerek dönüşüm gerçekleştirmeden sadece sorgu yapabilme özelliği dile kazandırılmıştır. Kuralların model elemanları üzerinde işletilmesinde deterministik olmayan bir yaklaşım vardır. Kuralların işletim sırası, kullanıcı tarafından açık olarak belirtilir. GREAT içerisinde tanımlanmış akış kontrol dilinde (control-flow language) belirtilen kurallar ile birlikte kuralların ardışık olarak işletilme sırası ya da hangi kuralların paralel işletileceği kullanıcı tarafından belirlenir. İzlenebilirlik bağlantısı da kullanıcı tabanlıdır. Kullanıcı, Cross-Link adı verilen bağlantı yapılarını kullanarak kaynak ve hedef model elemanları arasındaki bağlantıyı belirtmektedir.

61 3.6.2 Örnek Bir Dönüşüm GREAT dilinin uygulandığı örnek bir dönüşüm, nesneye yönelik yaklaşımın temel özelliklerinden kalıtım için tanımlanan bir dönüşümle açıklanacaktır. Çoklu kalıtım-tekli kalıtım dönüşümü, UML modellerinin Java modellerine dönüşümünde gerçekleştirilmesi gerekli bir dönüşümdür. UML modelleri çoklu kalıtıma izin vermesine rağmen Java programlama dilinin çoklu kalıtıma izin vermemesi nedeniyle bu modellerin Java modellerine dönüşümünde çoklu kalıtım içeren model yapılarının tekli kalıtım içeren yapılara dönüştürülmesi gerekmektedir. (Dao et al., 2004), çoklu kalıtım-tekli kalıtım dönüşümü için altı değişik dönüşüm tekniği önermektedir. Gerçekleştirilen dönüşüm Role Aggregation tekniğini temel almaktadır. Şekil 3.8, Role Aggregation kullanılarak gerçekleştirilen dönüşüm için kaynak ve hedef desenleri göstermektedir. 43 Şekil 3.8 Çoklu Kalıtım-Tekli Kalıtım Dönüşümünde Kaynak ve Hedef Desenler GREAT kullanarak bu dönüşümü UML-JAVA dönüşümü içerisinde bir alt dönüşüm olarak tanımladık. Şekil 3.9, tanımladığımız UML-Java dönüşümünü oluşturan kuralları ve bu kuralların işletim sırasının GREAT dilinin kontrol akış dili içerisindeki tanımını vermektedir. Şekilde belirtilen her bir kutucuk bir kuralı temsil etmekteyken kurallar arasında kırmızı çizgiler ile yapılan bağlantılar ise kurallar arasındaki parametre geçişleridir.

62 44 Şekil 3.9UML-Java Dönüşümünü İçerisinde Tanımlanan Kurallar ve Kuralların İşletim Sırası Buna göre dönüşüm dokuz tane dönüşüm kuralı ve TestDiamond adı verilen bir tane test kuralından oluşmaktadır. Bu kurallar içerisinde örneğin CopyClasses ve CopyFeatures gibi kurallar UML üst modelindeki UML Class ve UML Feature model elemanlarını Java üst modelindeki JClass ve JFeature gibi model elemanlarına eşleyerek UML-Java dönüşümünü gerçekleştirmektedir. Şekil 3.10, CopyClasses kuralının iç yapısını göstermektedir. Buna göre kural UML üst modelinde tanımlı Class üst sınıfından örneklenen her bir model elemanına karşılık hedef model içerisinde Java üst modelinde tanımlı bir JClass yaratırken AttributeMapping bölümü içerisinde, oluşturulan model elemanının özellikleri atanmaktadır. Kural içerisinde Class ile JClass arasında tanımlanan ilişki bir izlenebilirlik bağlantısı olup tanımlı diğer kurallar içerisinde Class için oluşturulan JClass lara ulaşmada kullanılmaktadır. UMLOut ve JavaOut olarak tanımlanan yapılar ise bağlantı çıktıları olarak adlandırılıp eşlenen ve yaratılan model elemanlarının kural dışarısına çıkartılarak diğer kurala parametre olarak geçirilmesi için kullanılmaktadır.

63 45 Şekil 3.10 CopyClasses Kuralının İç Yapısı Şekil 3.10 da verilen TestDiamond, CreateAggregation, CreateInheritance ve RefactorFeatures kuralları ile UML-Java dönüşümü içerisinde çoklu kalıtım içeren UML modelleri tekli kalıtım içeren Java modellerine dönüştürülmektedir. TestDiamond kuralı, bir test kuralı olup sadece sorgulama yapmakta herhangi bir dönüşüm işlemi içermemektedir. Bu kural içerisinde çoklu kalıtım içeren yapılar tespit edilerek bu yapılar diğer kurallara parametre olarak geçirilmektedir. CreateAggregation kuralında kalıtım ilişkisi kaldırılan alt sınıflar için sahip olma (aggregation) ilişkisi oluşturulmakta ve CreateInheritance kuralıyla da bu sınıflar ile oluşturulan bir soyut sınıf arasında kalıtım ilişkisi kurulmaktadır. Şekil 3.11 de CreateAggregation kuralının iç yapısı verilmiştir.

64 46 Şekil 3.11 CreateInheritance Kuralının İç Yapısı 3.7 YATL (Yet Another Transformation Language) Model Dönüşüm Dili YATL dili, İngiltere nin Kent üniversitesinde QVT kapsamında geliştirilmiş bir model dönüşüm dilidir (Patrascoiu, 2004a). Dil, OMG nin Model Tabanlı Mimari yaklaşımında tanımlanan model dönüşümlerini gerçekleştirmek için Kent Modeling Framework KMF (KMF, 2002) tabanlı geliştirilmiştir YATL Dönüşüm Alt Yapısı ve Dönüşüm Yaklaşımına Genel Bir Bakış YATL dili, tanımlayıcı ve imperative özellikleri bir arada barındıran bir dildir. Dil, MOF üst üst modelinden türetilmiş soyut sözdizimiyle BNF tabanlı somut söz diziminden oluşmaktadır. QVT

65 isteklerinde belirtilen görsel gösterime sahip değildir. Kural tanımlarının yapıldığı ve işletildiği KMF ortamı, KMF-Studio ve YATL-Studio olmak üzere iki bileşenden oluşmaktadır. KMF-Studio, model şeklinde tanımlanan dil tanımlarından modelleme araçları üreten bir araçtır. YATL-Studio ise KMF-Studio aracılığıyla oluşturulan modelleri dönüştürmek için YATL dönüşüm kodlarını üreten ve işleten bir araçtır. Bu araçları kullanarak tanımlanan dönüşüm yaklaşımı, dört ana adımdan oluşmaktadır (Patrascoiu, 2004b). İlk olarak Rational Rose, Poseidon gibi MOF editörleri kullanılarak kaynak ve hedef üst modeller tanımlanır. KMF-studio ile ilk adımda oluşturulan kaynak ve hedef üst modellerin Java kodları üretilir. KMF-studio içerisindeki kullanıcı arayüzü ile kaynak model oluşturulur. Son olarak YATL-studio kullanılarak ilgili dönüşümün kodlanacağı bir YATL projesi tanımlandıktan sonra bu proje içerisinde ilgili dönüşüm kuralları kodlanarak işletilir Örnek Bir Dönüşüm Bu bölümde örnek dönüşüm olarak UML modellerinin Java modellerine dönüştürülmesi alınmıştır. YATL ile hazırlanmış örnek dönüşüm (Patrascoiu, 2004a), dilin temel özelliklerini anlatabilmek için basit tutulmuş olup sadece UML sınıf ve özelliklerinin Java sınıf ve sahalarına dönüştürülmesini içermektedir. YATL içerisindeki kural yapısı, dönüşümü birimler halinde tanımlayan kuralların bir ana kural içerisinden çağrılması şeklindedir. Bu ana kuralın çağrılması işlemi ise yine dil içerisinden start komutu ile gerçekleştirilir. start kmf::uml2java::main; Yukarıda verilen satır ile dil içerisinden uml2java isimli dönüşümün main isimli ana kuralı çağrılmaktadır. Ana kural içerisinde ise dönüşüm içerisindeki bütün kurallar belirli bir sıra dahilinde çağırılarak çalıştırılmaktadır. Aşağıda verilen ana kural (Patrascoiu, 2004a), UML sınıfı ile özelliklerini Java sınıf ve sahalarına dönüştüren üç kuralı sırayla çağırmaktadır.

66 48 rule main() { -- Birebir eşlemelerin tanımlandığı -- kurallar çağırılıyor apply umlclass2javaclass(); apply umlattribute2javafield(); } -- Sahayı Java sınıfına ekleyen -- kural çağırılıyor apply linkattribute2class(); Ana kural içerisinden çağırılan dönüşüm kuralları ise ana kuralın dışarısında tanımlanmaktadır. Kuralların tanımlanabilmesi için bir isim sahasının altında dönüşüm başlığı açılmalıdır. namespace kmf(uml, javamodel) { transformation uml2java { -- Dönüşüm kuralları burada tanımlanmalıdır } } namespace ifadesi ile dönüşüm için bir isim sahası açılmaktadır. Bu isim sahasına gelen parametreler ile dönüşümün üzerinde çalışacağı kaynak ve hedef modellerin üst modelleri belirtilmektedir. İsim sahasının içerisinde transformation deyiminden sonra gelen ifade ile dönüşümün ismi belirtilmiştir. rule umlclass2javaclass match uml::foundation::core::class() { -- Java sınıfı yaratılıyor let jclass: javamodel::javaclass; jclass := new javamodel::javaclass; -- İsim ataması gerçekleştiriliyor jclass.name := self.name.body_;

67 49 } -- İzlenebilirlik bağlantısı kuruluyor track(self, class2class, jclass) Yukarıda verilen umlclass2javaclass isimli kural ile kaynak modelde yer alan her bir UML sınıfı, hedef model içerisinde bir Java sınıfına dönüştürülmektedir. Kural isminden sonra kullanılan match ifadesiyle kuralın, işletildiğinde hangi tip model elemanıyla eşleşeceği tanımlanmaktadır. Kuralın içerisinde önce bir Java sınıfı yaratılmakta daha sonra eşlenen UML sınıfına ait özellikler yaratılan Java sınıfına atanmakta ve son olarak da hangi UML sınıfına karşılık hangi Java sınıfının yaratıldığı bilgisinin tutulduğu izlenebilirlik bilgisi tanımlanmaktadır.

68 50 4 MODEL DÖNÜŞÜM DİLLERİNİN DEĞERLENDİRİLMESİ Bu bölümde, model dönüşüm dillerinin değerlendirilmesi için literatürdeki iki farklı çalışma incelenmiş ve bu çalışmalardan yola çıkılarak bir model dönüşüm dilinin sağlaması gereken genel amaçlı istekler ve bu istekler arasındaki ilişkiler tanımlanmıştır. Son olarak da üçüncü bölümde incelenen model dönüşüm dillerinin, tanımlanan bu istekleri ne ölçüde desteklediği araştırılmıştır. 4.1 Literatürdeki Çalışmalar Model dönüşüm dillerinin sınıflandırılması ve model dönüşüm dili kriterleri üzerine Twente Üniversitesinde (Kurtev, 2005) ve Norveç te SINTEF te (Gronmo et al., 2005) çalışmalar yapılmıştır. Gronmo (Gronmo et al., 2005), MODELWARE projesi kapsamında geliştirilen model dönüşüm dilleri için gereksinimler tanımlamıştır. Daha sonra bu gereksinimler üç grup altında toplanmış ve her birisine önem derecesine göre ağırlıklar verilmiş olup QVT RFP (OMG, 2002) dokümanına yapılan bir öneri olan QVTMerge (QVT-Merge_Group, 2004) dili bu istekler doğrultusunda değerlendirilmiştir. Kurtev (Kurtev, 2005), çalışmasında dönüşüm parçalama ve birleştirimi (transformation decomposition and composition) için incelediği çeşitli model dönüşüm senaryoları kapsamında bir model dönüşüm dilinin sağlaması gereken istekleri tanımlamıştır. Çalışmanın devamında Kurtev, bazı model dönüşüm dillerinin tanımlanan bu istekleri ne ölçüde sağladığını araştırmıştır Gronmo (Gronmo et al., 2005) Model dönüşüm dilleri üzerine gerçekleştirilen çalışmalardan biri de QVT RFP (OMG, 2002) kapsamında önerilen QVTMerge (QVT- Merge_Group, 2004) model dönüşüm dilinin değerlendirildiği çalışmadır. Gronmo (Gronmo et al., 2005), çalışmasında MODELWARE

69 projesi kapsamında geliştirilen model dönüşüm dilleri için gereksinimler tanımlamıştır. Çalışmada model dönüşüm dillerinin incelenmesi ve değerlendirilebilesi için tanımlanan üç sınıf: 51 Dil İncelemesi (Language Inspection): Kriterin dil tarafından desteklenip desteklenmediğinin değerlendirilmesi için o dilin kağıt üzerinde incelenmesi Örnek Bağımlı Değerlendirme (Example-Dependant): Kriterleri dil kapsamında incelemek için örnek dönüşümlerin kullanılması Araç Bağımlı Değerlendirme (Tool-Dependant): Bu tip değerlendirme için model dönüşüm dilinin gerçekleştirilmesine ihtiyaç duyulmaktadır. Bu kategoriler, çalışmada belirtilen kriterleri kesin ifadelerle birbirinden ayırmamaktadır. Hangi kriterin hangi kategoriye girdiği konusu tartışmaya açık bir konu olup belirtilen bir kriter için birden fazla kategori söz konusu olabilir. QVTMerge dili gerçekleştirilmediğinden dolayı Gronmo, çalışmasında araç bağımlı değerlendirme kriterlerini göz önüne almamış, dil incelemesi ve örnek bağımlı değerlendirme kriterleri incelemiştir. Dillerin sağlaması gereken zorunlu istekler: İzlenebilirlik (Traceability): Czarnecki ve Helsen tarafından tanımı yapılmış zorunlu bir istektir. Tek Yönlü Dönüşüm Tanımları (Unidirectionality): Tek yönde işletilecek dönüşümler için bu tanımları uygulamak, tek yönlü dönüşümleri kolaylaştırmaktadır.

70 52 Metinsel Gösterim (Complete textual notation): Metinsel gösterime sahip diller ile büyük ve karmaşık dönüşümlerin ifade edilmesi daha kullanışlıdır. Kapalı Kutu Birlikte İşlerlik (Black-box Interoperability): Bu özellik, diğer dillerde yazılmış kodların dışarıdan çağırılabilmesini sağlamaktadır. Dönüşümlerin Birleştirilmesi (Composition of transformations): Küçük ve basit birden fazla dönüşümün büyük bir dönüşümü tanımlamasıdır. Görsel Gösterim (Graphical notation): Görsel gösterim, metinsel gösterime oranla anlaşılması çok daha kolaydır. Kaynak Modellerin Güncellenmesi (Updating source models): Kaynak model üzerinde değişiklikler yaparak kaynak modelin güncellenmesidir. Dönüşümlere Parametre Geçirilmesi (Incomplete transformations completed with pattern parameters): Czarnecki ve Helsen tarafından tanımı yapılmış zorunlu bir istektir. Zorunlu olmayan istekler: Modülerlik (Modularity): Dönüşümü oluşturan dosyalar, değişik paketler altında toplanabilecektir. Yeniden Kullanılabilirlik (Reusability): Dönüşüm kurallarının tekrar kullanılması ile kural tekrarından kaçınılması amaçlanmaktadır. Ön Koşulların Sınırlanması (Restricting conditions/preconditions): Dönüşüm içerisindeki kaynak modellerin,

71 dönüşüm içerisinde tanımlanan kısıtları sağladığını temin etmek için kullanılmaktadır. 53 Çift Yönlü Dönüşüm Tanımları (Bidirectionality): Kullanıcının, iki farklı dönüşüm tanımlamak yerine her iki yönde dönüşüm tanımlarını destekleyen tek bir dönüşüm tanımlaması daha kolay olacaktır. Birden Fazla Kaynak Model (Multiple source models): Dönüşüm içerisinde birden fazla kaynak modele ihtiyaç duyulduğu durumlar olabilmektedir. Nesneye Yönelim (Object orientation): Nesne kavramından yararlanılması; dönüşümlerin bakımını, yeniden kullanılmasını ve anlaşılmasını kolaylaştıracaktır. Öğrenme Eğrisi (Learning Curve): Bu kriter, değişikliklerin hızlı olduğu bir ortamda gereklidir. Birden Fazla Hedef Model (Multiple target models): Birden fazla hedef modelin oluştuğu durumlar olabilir Kurtev (Kurtev, 2005) Bu bölümde incelenen model dönüşüm dili kriterleri, Ivan Kurtev tarafından 2005 yılında Twente Üniversitesinde sunulan doktora tezi içerisinde tanımlanan kriterlerdir. Kurtev (Kurtev, 2005), dönüşümlerin yeniden kullanılabilirliğini işleyen senaryolardan yola çıkarak bir model dönüşüm dilinin sağlaması gereken istekleri önermiştir. Model dönüşüm dili istekleri, dönüşüm tanımlarının ayrıştırılması ve birleştirilmesini destekleyen model dönüşüm dilleri için tanımlanmıştır. Kurtev, model ayrışımı ve birleşimi konusundaki üç temel konuyu ele almış ve bir model dönüşüm dilinin bu yöndeki istekleri desteklemesi gerektiğini savunmuştur. Ele alınan problemleri sıralarsak: Karmaşıklığı Yönetmek İçin Dönüşümün Ayrıştırılması: Özellikle kaynak ve hedef modellerin karmaşık olduğu

72 54 model dönüşümlerinde dönüşüm tanımları da karmaşık olabilmektedir. Bu gibi karmaşık dönüşümleri işlemenin en temel yolu, dönüşüm tanımlarını daha basit birimlere bölmektir. Kaynak ve hedef modeller; paket, sınıf gibi yapılar arasındaki hiyerarşiler kullanılarak daha basit birimlere ayrılabilir. Modellerde Meydana Gelen Değişimlerin Model Dönüşümlerinde Değişimlere Neden Olması: Model dönüşümünün üzerinde çalıştığı kaynak ve hedef modellerin değişime uğraması dönüşümün de değişime uğramasına sebep olur. Modellerin Birleşiminin Model Dönüşümlerinin Birleşimine Neden Olması: Burada yaşanan problemler, bir önceki durumda meydana gelen problemlerle benzerlik taşımaktadır. Tek fark, ilk durumdaki gibi tek bir dönüşümün yeniden kullanılması değil de iki dönüşümün yeniden kullanılarak bir araya getirilmesi gerekliliğidir. Kurtev, bu temel problemlerden yola çıkarak model dönüşüm dillerinin sağlaması gereken istekleri senaryolar dahilinde incelemiştir. Bu senaryolardan ilki, modellerin çok boyutta parçalanmasıdır. Dönüşümün büyüklüğüne göre kuralların yapılandırılması gerekli olup kaynak ve hedef tarafta bulunan birden fazla model elemanı üzerinde çalışabilen kurallar tanımlanmalıdır. Senaryoya göre bir kural, başka bir kural tarafından oluşturulan model elemanına ulaşabilmelidir. Kaynak modelden hedef modele tanımlanan bir dönüşümde kaynak modelde yer alan bir model elemanı için hedef model tarafında eşlenen bir model elemanının özelliklerinin (attributes) hesaplanması ve o model elemanına atanması gereklidir. Bu senaryoyla ilgili son olarak tanımlanan, tek bir birim içerisinde tanımlanan kuralların gruplanması için bir paketleme mekanizmasının gerekli olduğudur. İkinci senaryo modellerde çoklu hiyerarşiler için tanımlanmış olup dönüşümü tasarlayan kişinin kuralların işletim sırasını göz önünde bulundurması gerekliliğini ortaya koymaktadır. Bu nedenden dolayı Kurtev, model dönüşüm dillerinin kuralların işletim sırasını göz önünde

73 bulundurması gerekliliğini bir istek şeklinde tanımlamıştır. Kurallar arasındaki ilişkinin tanımlanabilmesi için kuralların birbirini bilmesi gerekmektedir. Kuralların birbirini bilmesi ise bir kuralın oluşturduğu model elemanına diğer kuralın erişebilmesi ile mümkün olur. Üçüncü senaryo, bir dönüşümün parçalarının değişik modüller şeklinde tanımlanabilmesi gerekliliğine işaret etmektedir. Kurtev, bu senaryo için başlıca iki tane istek tanımlamıştır. Bu isteklerden birisi dönüşüm parçalarının modüllere ayrılması ile ilgiliyken diğeri de birleşim operatörleriyle ilgilidir. Dördüncü senaryo olan artırımsal evrim ile tanımlanan, modellerin ve buna bağlı olarak model dönüşümlerinin gelişmesi durumlarında dönüşüm içerisindeki kurallar üzerinde bazı değişiklikler gerekli olduğudur. 4.2 Model Dönüşüm Kriterlerinin Sınıflandırılması ve Aralarındaki İlişkilerin Tanımlanması için Önerilen Yaklaşım Yapılan Çalışmalar Işığında Kriterlerin Sınıflandırılması Bölüm 4.1 de model dönüşüm dillerinin sınıflandırılması ve dil kriterleri üzerine yapılan literatürdeki çalışmalara değinildi. Czarnecki ve Helsen (Czarnecki and Helsen, 2003), çalışmalarında tanımladıkları kavramlar ile model dönüşüm dillerinin sınıflandırılmasında ve özelliklerinin incelenmesinde göz önüne alınacak ilkeleri tanımlamışlardır. Tartışılan kavram ve konu başlıkları aslında model dönüşüm dili isteklerinin ve kriterlerinin de (OMG, 2002) (Gronmo et al., 2005) (Kurtev, 2005) temelini oluşturmaktadır. OMG (OMG, 2002) ve Gronmo (Gronmo et al., 2002), daha çok genel kavramlar üzerinden yola çıkarak bir model dönüşüm dili için istekleri tanımlama yoluna giderken Kurtev, çalışmasında model ayrışımı ve birleşimi konusundaki üç temel sorun için tanımladığı özelleşmiş senaryolardan yola çıkarak model dönüşüm dillerinin sağlaması gereken kriterleri incelemiştir. Kurtev in kriterleri daha özelleşmiş durumlar için tanımlandığından dolayı diğer

74 56 çalışmalardan ayrılırken OMG nin QVT RFP dokümanında belirttiği kriterlerle Gronmo nun model dönüşüm kriterleri benzerlik taşımaktadır. Bu iki çalışmadaki kriterler benzerlik taşımasına rağmen farklı bakış açılarından dolayı her iki çalışmada geçen ortak bir kavram farklı derecelerde değerlendirilebilmektedir. Örneğin, izlenebilirlik kavramı QVT RFP dokümanında zorunlu olmayan bir istek şeklinde tanımlanmışken Gronmo çalışmasında izlenebilirliği model dönüşüm dillerinin zorunlu olarak desteklemesi gereken bir istek olarak belirtmiş ve ağırlığını yüksek tutmuştur. Yine Gronmo, bir dilin tanımlanması için hem metinsel hem de görsel söz dizimin ikisinin birlikte tanımlanmış olmasını zorunlu tutarken QVT RFP dokümanında dönüşüm tanımlarının MOF modelleri şeklinde tutulması zorunlu kılınmış, dilin gösterimi konusunda bir ifadede bulunulmamıştır. Biz kendi çalışmamızda genel olarak QVT RFP dokümanında ve Gronmo nun çalışmasında belirtilen genel amaçlı model dönüşüm dili kriterlerini toparlayıp kendi oluşturduğumuz bir sınıflandırmada tanımlamaya çalıştık. Bu kriterleri tanımlarken dayandığımız sınıflandırma iki eksenden oluşmaktadır. İlk eksen olan X eksenindeki kriterler, zorunlu istekler-zorunlu olmayan istekler olmak üzere ikiye ayrılırken ikinci eksen olan Y eksenindeki kriterler ise düşük seviyeli istekler-yüksek seviyeli istekler olmak üzere ayrılmaktadır. Şekil 4.1, bu sınıflandırmayı ve kriterlerin bu sınıflandırma içerisindeki dağılımını göstermektedir. Düşük seviyeli istekler, kuralların işletimiyle ilgili daha detaylı konular üzerinde tanımlanırken yüksek seviyeli istekler kuralların organizasyonu, bir model dönüşüm dilinde bulunması gereken bileşenler ve bu bileşenler arasındaki ilişkileri tanımlayan isteklerdir. Bizim yapmış olduğumuz sınıflandırmada bazı istekler tek başlarına zorunlu olmayabilir ancak bağlantılı olduğu isteğin bulunması durumunda o istek zorunlu bir istek haline gelebilir. Aynı zamanda bir istek, ancak bağlantılı olduğu bir isteğin dil tarafından desteklenmesi durumunda zorunlu olmayabilir. Bu nedenle kriterler, her zaman sınıflandırma içerisinde sabit bir yerde bulunmayabilirler.

75 57 Şekil 4.1 Model Dönüşüm Dili Kriterlerinin Sınıflandırılması için Önerilen Yaklaşım Kriterlerin Sınıflandırma İçerisindeki Dağılımı ve Kriterler Arasındaki Bağlantılar QVT RFP dokümanında ve Gronmo nun çalışmasında belirtilen dil kriterlerinden yola çıkarak tanımladığımız genel amaçlı model dönüşüm dili isteklerini, Şekil 4.1 deki sınıflandırma yöntemi ile gruplandırdık. Böylece kurallar arasındaki ilişkileri belirttik. İzlenebilirlik (Traceability): İzlenebilirlik kavramı, zorunlu ve düşük seviyeli istekler kapsamına girmektedir. Zorunlu bir istektir çünkü bir kuralın kaynak model elemanından yola çıkarak üzerinde çalıştığı hedef model elemanına bir başka kural erişmek isteyebilir. Bu kuralın da o hedef model elemanına erişimi, ancak kaynak ve hedef model elemanları arasında kurulan izlenebilirlik bilgisi ile mümkündür. Bu, kuralların mikro seviyede işletimiyle ilgili bir istek olduğundan dolayı düşük seviyeli bir istektir. Şekil 4.1 deki sınıflandırmada t1 bölgesinde yer almaktadır. Ayrıca izlenebilirlik isteği, kurallara parametre geçirilmesi isteğiyle yakın ilişkilidir. Kurallara parametre geçirilmesi ile bir kuralda kullanılan model elemanları diğer bir kurala parametre olarak geçirilebilir ve parametre olarak geçirilen bu model elemanları kural içerisinde kullanılır. Parametre olarak geçen model elemanları kural içerisinde tekrar aranmayacağından dolayı, arama algoritması verimli olarak işletilebileceği gibi iki kural arasında bir etkileşim de

76 58 sağlanmış olur. Ancak parametre olarak kurala geçen model elemanından bir önceki kural içerisinde etkilenen hedef model elemanlarına ulaşılmak istenebilir. Bu noktada izlenebilirlik bilgisine ihtiyaç vardır. Şekil 4.2 Dönüşüm İçerisinde Tanımlı Bir İzlenebilirlik Bağlantısı Şekil 4.2, GREAT model dönüşüm dilinde UML sınıflarını Java sınıflarına dönüştüren bir kural yapısını göstermektedir. Bu kural ile kaynak model içerisinde eşlenen her bir UML sınıfına karşılık hedef model içerisinde bir Java sınıfı yaratılmaktadır. GREAT dili, izlenebilirlik bağlantılarının kullanıcı tarafından oluşturulduğu bir dil olduğu için Şekil 4.2 de Class ve JClass arasında tanımlı CrossLink adı verilen izlenebilirlik bağlantısı kullanıcı tarafından oluşturulmuştur. Bu izlenebilirlik bağlantısı aracılığıyla her bir UML sınıfına karşılık bu kural içerisinde oluşturulan Java sınıflarına daha sonra işletilecek kurallar içerisinde erişim mümkündür. Metinsel Gösterim (Complete Textual Notation): Metinsel gösterim, zorunlu olmayan yüksek seviyeli bir istektir. Bir model dönüşüm dilinde dönüşüm tanımları, görsel gösterim ile de ifade edilebilir. Ancak görsel gösterim ile metinsel gösterimin en az birisinin desteklenmesi, zorunlu istektir. Çünkü dönüşüm dilinde bir

77 59 dönüşüm tanımı en az bir gösterim türü ile ifade edilmelidir. Gronmo, hem görsel gösterimi hem de metinsel gösterimi ayrı ayrı zorunlu istek olarak adlandırsa da bu istekler tek başlarına zorunlu olmayan bir istektir. Örneğin, metinsel gösterimin desteklendiği bir dilde görsel gösterimin de desteklenmesi gerekli değildir. ATL model dönüşüm dili (Bezivin et al., 2003), metinsel gösterimi desteklerken dönüşüm tanımlarının görsel gösterimi bulunmamaktadır. Kural yapısı ve kuralların işletimiyle ilgili olmadığı için bu kavram yüksek seviyeli bir istek olarak adlandırılmıştır. Görsel Gösterim (Graphical Notation): Zorunlu olmayan yüksek seviyeli bir istektir. Şekil 4.1 deki sınıflandırmada t4 bölgesinde yer alır. Görsel gösterim, metinsel gösterim ile paralellik taşır ve aynı zamanda yakın ilişkide olduğu bir istektir. Bu iki istek, ayrı ayrı zorunlu olmayan istekler olmasına rağmen en az birisinin desteklenmesi bir model dönüşüm dili için zorunlu bir istektir. Görsel gösterime sahip dillerde de kendi içerisinde model elemanları üzerindeki kısıtları belirtmek için metinsel söz dizime sahip kısıt dillerini kullanabilir. Örneğin GREAT model dönüşüm dili (Agrawal et al., 2003), görsel gösterime sahip bir model dönüşüm dili olmasına rağmen model elemanları üzerindeki kısıtları göstermek için Guard adı verilen metinsel kısıtların tanımlanmasını da desteklemektedir. Kapalı Kutu Birlikte İşlerlik (Black-box Interoperability): Kapalı kutu birlikte işlerlik, var olan kodların tekrar kullanılmasını ya da diğer dillerde yazılmış script kodların dışarıdan çağırılabilmesini sağlamaktadır. Temel olarak bu özellik, Java, C# gibi programlama dili ortamlarında yazılmış kodların model dönüşüm dili içerisinden yerel olarak çağrılmasını desteklemektedir ve zorunlu olmayan yüksek seviyeli bir istektir. Zorunlu olmayan bir istek olmasının nedeni, bir model dönüşüm dilinde dönüşüm tanımlarının yapılabilmesi için Java, C# gibi programlama dillerinde derlenmiş kaynak kodların çağrımının zorunlu olmamasıdır. Bu özelliğiyle kapalı kutu

78 60 birlikte işlerlik, yeniden kullanılabilirlik ve modülerlik gibi isteklerle yakından ilişkilidir. Yerel kodların ayrı bir modül şeklinde saklanması, dönüşümün modüllere ayrılmasına yardımcı olur. Dönüşümün Yönetilmesi (Transformation Management): Dönüşümün yönetilmesiyle kastedilen, kuralların paralel ve ardışık olarak işletilmesidir. Dönüşümün yönetilmesi kriteri, zorunlu ve yüksek seviye bir istektir. Karmaşık dönüşümler tek bir kural ile ifade edilemeyeceği için dönüşümün birden fazla kurala bölünmesi ve bu kurallar arasındaki ilişkiler ile kuralların işletim sıralarının belirlenmesi gereklidir. Kuralların yönetilmesi, bazı diller içerisinde otomatik şekilde gerçekleştirilirken (implicit rule calls) bazı diller kural zamanlamasını ve ilişkilendirmesini dönüşümü tanımlayana bırakmaktadır (explicit rule calls). Kural zamanlamasını kullanıcıya bırakan model dönüşüm dillerinde bu iş için özelleşmiş kural yönetimiyle ilgili alt diller bulunmaktadır. Kuralların içsel olarak çağrıldığı dillerde ise bir kuralın çağırılması ancak başka bir kuralın işletilmesinde o kuralın çıktısına ihtiyaç duyulduğu takdirde gerçekleşir. Ancak bu demek değildir ki kural motor tarafından çağrıldığı anda işletilir. Kuralın çağrıldıktan sonra işletilmesi kullanılan zamanlama algoritmasına bağlı olarak değişir. Bu kriter; modülerlik, kurallara parametre geçirilmesi ve izlenebilirlik istekleriyle yakın ilişkilidir. Dönüşüm içerisindeki yapıların modüllere ayrılmasında kuralların birbiriyle olan ilişkileri ve kural zamanlaması gibi etkenler göz önünde bulundurulabileceğinden dolayı dönüşümün yönetilmesi isteği modülerlik isteğiyle yakın ilişkilidir. Ayrıca kural zamanlaması, kurallara parametre geçirilmesini etkiler. GREAT gibi kuralların yönetilmesini ve işletim sırasını kullanıcıya bırakan dillerde bu iş için özelleşmiş kural yönetim dilleri bulunmaktadır. Şekil 3.9, UML modellerinin Java modellerine dönüşümü için tanımlanmış kuralların işletim sırasını belirleyen dönüşüm yönetim tanımını vermektedir. Buna göre ilk önce RootFolder kuralından başlanılarak tanımlanmış diğer dokuz kural belirtilen sırada

79 61 işletilmektedir. Tanımlanan bu kuralların işletim sırası, GREAT içerisinde bir alt dil olarak tanımlanmış dönüşüm yönetim dili kullanılarak Şekil 3.9 daki şekilde tanımlanmaktadır. Modeller Üzerinde Yazma/Okuma İşleminin Aynı Anda Desteklenmesi (Both read/write support on Models): Kaynak modelden hedef modele doğru tanımlanan model dönüşümleri için bazı durumlarda kaynak ve hedef modeller aynı model olabilmektedir. Bu tip dönüşümler, yatay (horizontal) dönüşüm içerisinde tanımlanmaktadır (France and Bieman, 2001). Kaynak ve hedef modelin aynı model olduğu dönüşümlerde model üzerinde aynı anda hem okuma hem de yazma işleminin desteklenmesi gerekmektedir. Kaynak ve hedef modelin farklı modeller olduğu dikey (vertical) dönüşümlerde ise model dönüşüm motoru bir taraftan kaynak modeli okurken diğer taraftan da hedef modeli oluşturmaktadır. Bir model dönüşüm dilinin, yatay ve dikey olmak üzere her iki tip model dönüşümünü destekleyebilmesi için modeller üzerinde yazma ve okuma işlemini aynı anda desteklemesi gerekmektedir. Bu nedenle bu istek zorunlu ve yüksek seviye bir istektir. Modülerlik (Modularity): Dönüşümün değişik dosyalar altında modüllere ayrılmasıdır. Modülerlik, zorunlu olmayan yüksek seviyeli bir istektir. Dönüşümün yönetilmesi ve kapalı kutu birlikte çalışabilirlik ile yakından ilişkilidir. Kurallara Parametre Geçirilmesi: Zorunlu ve yüksek seviyeli bir istektir. Kurallara parametre geçirilerek kurallar arasındaki etkileşim sağlanmaktadır. Bir kural içerisinde eşlenen model elemanları diğer kurala parametre olarak geçirilerek diğer kural içerisinde aynı model elemanları için tekrar arama işleminin yapılması önlenmektedir. Ayrıca parametre olarak geçen model elemanları ve bu elemanların sahip olduğu izlenebilirlik bilgisi kullanılarak diğer kuralların oluşturduğu ya da değişiklik yaptığı hedef model

80 62 elemanlarına erişim sağlanmaktadır. Bu nedenlerle kurallara parametre geçirilmesi isteği, izlenebilirlik ve dönüşümün yönetilmesi istekleriyle yakından ilgilidir. Ayrıca parametre alan kurallar, dönüşüm içerisinde ya da başka dönüşümler tarafından tekrar kullanılabileceğinden dolayı yeniden kullanılabilirliği arttırmaktadır. Şekil 3.9 da tanımlanan kurallar belirtilen işletim sırası ile çalıştırılırken bir kuraldan çıkan model elemanları diğer kurala girdi olarak atanmaktadır. Kuralların Kümelenmesi (Rule Aggregation): Kuralların kümelenmesi, bir kuralın başka bir kural içerisinde çağrılarak kullanılabilmesi anlamına gelmektedir. Zorunlu olmayan alt seviyeli bir istektir. Bir model dönüşüm dilinin kural kümelenmesini destekleyebilmesi için kurallara parametre geçirilmesini desteklemesi gerekmektedir. Kuralların kümelenmesi ile dönüşümün yönetilmesi arasında yakın bir ilişki kurulabilir. Çünkü kural yönetim dili kullanılarak tanımlanmış kuralları ana kural içerisinde çağrılan alt kurallara benzetirsek bir ana kural, içerisinde alt kuralları kümeleyerek o kurallar arasındaki işletim zamanlarını ve bağlantılarını tanımlayabilir. Kuralların dışarıdan çağrılabilmesi (explicit rule calls) için dönüşüm yönetim diline sahip olan ancak bir kuralın kendi içerisinden bir başka kuralı çağıramadığı model dönüşüm dilleri, kuralların kümelenmesini tam olarak desteklememektedir. Dönüşümün yönetilmesi, zorunlu bir istek iken kuralların kümelenmesi, zorunlu olmayan bir istektir. Kuralların kümelenmesini doğrudan destekleyen dillerden birisi de ATL dilidir. Aşağıdaki kod parçası ATL ile tanımlanmış bir kural ve bu kural içerisinde çağırılan ikinci bir kuralı (Kurtev et al., 2006) göstermektedir. rule MultipleChoiceView{ from e : MultipleChoiceElement to vmultiplechoice : MultipleChoiceView ( controller<-[cmultiplechoice]e )

81 63 } do{generatetrace(e, vmultiplechoice, MultipleChoiceView);} rule GenerateTrace(source : OclAny, target : OclAny, name : String){ do { } } t : TraceRecord = new TraceRecord; t.source<-source; t.target<-target; t.rulename<-name; Kuralların Kalıtımı (Rule Inheritance): Daha önce tanımlanan bir kural başka bir kural tarafından kalıtım ile alınarak o kurala yeni fonksiyonlar eklenebilir ya da var olan fonksiyonlar geliştirilebilir. Kuralların kalıtımı, zorunlu olmayan alt seviyeli bir istektir. Kuralların yeniden kullanılabilirliğinin sağlanmasında en etkili yöntem olarak tanımlanabilir. Kuralların yeniden kullanılabilirliğin arttırılması sadece kurallara parametre geçirilerek değil kuralların kümelenmesi, kuralların kalıtımı ve modülerlik gibi kavramların dil tarafından desteklenmesiyle gerçekleştirilir. Bu nedenle kuralların yeniden kullanılabilirliğini ek bir istek şeklinde belirtmedik. Kuralların kalıtımını doğrudan destekleyen dillerden birisi de ATL dilidir. ATL içerisinde soyut kurallar tanımlanarak bu kurallardan kalıtım ile alt kurallar tanımlanabilir. Aşağıdaki kod parçası ATL ile tanımlanmış soyut bir kural ve bu kuraldan türemiş alt bir kuralı (Kurtev et al., 2006) göstermektedir. abstract rule ExamItemView{ from e : ExamItemElement to vexamitem : ExamItemView ( ) fontname <- Times, fontcolor <- red

82 64 } rule OpenQuestionView extends ExamItemView{ from e : OpenElement to vexamitem : OpenView ( controller <- [copen] e ) } Önerilen Kriterlere Göre Model Dönüşüm Dillerinin Değerlendirilmesi Bu bölümde, Bölüm de tanımladığımız model dönüşüm dili kriterlerini kullanarak bazı model dönüşüm dillerini değerlendirdik. Bu değerlendirme için seçilen model dönüşüm dilleri: ATL (Bezivin et al., 2003) (Jouault and Kurtev, 2005), GREAT (Agrawal et al., 2003), TEFKAT (Duddy et al., 2003), MOLA (Kalnins et al., 2004b), YATL (Patrascoiu, 2004a). Bu dillerden bazılarının gerçekleştirme safhasına geçilmediği bazı dillerin de gerçekleştirilmesi devam ettiğinden dolayı çoğu zaman bu dillerle ilgili kapsamlı dokümantasyon bulunmamaktadır. Bu nedenle yaptığımız çalışmada devam eden çalışmalarla ilgili eldeki verilerden yola çıktık. Şekil 4.3 de tanımladığımız kriterlerin incelenen diller tarafından ne derecede destek verildiği belirtilmiştir. Değerlendirmede bulunurken destek var, yarı destek var, destek yok şeklinde üç aşamalı bir yöntem kullanılmıştır. Bazı model dönüşüm dilleri için yeterli dokümantasyon bulunmadığı için ilgili kriterler için dil hanesinde boş bırakılan yerler belirtilmemiş anlamı taşımaktadır.

83 65 Şekil 4.3 Tanımlanan Dil Kriterleri ve Model Dönüşüm Dilleri İzlenebilirlik bilgisi, bir model dönüşüm tanımının eksiksiz yapılabilmesi için zorunlu bir istek olduğundan dolayı incelenen beş dil tarafından da desteklenmektedir. ATL dışındaki diğer dört dil, izlenebilirliğin kullanıcı tarafından yapılmasını gerektirmektedir. Örneğin, GREAT içerisinde kaynak model elemanına karşılık hedef model elemanı oluştururken bunlar arasındaki izlenebilirlik bilgisine daha sonra da erişebilmek için iki model elemanı arasında cross reference adı verilen bağlantıların tanımlanması gereklidir. Tanımlanan bu

84 66 bağlantılar diğer kural içerisinde kullanılarak kaynak modele karşılık oluşturulan hedef model elemanına erişilir. Yine TEFKAT ve YATL dilleri içerisinde izlenebilirlik için kullanılan mekanizmalar kullanıcı tarafından işletilmekte olup benzerlik taşımaktadır. Bu iki dilde de track ve linking adı verilen yapılar içerisine hangi kaynak model elemanına karşılık hangi hedef model elemanının hangi kural içerisinde eşlendiği bilgileri, dönüşümü hazırlayan kişi tarafından belirtilmek zorundadır. Daha sonra bu yapılar, kaynak model elemanı ve kural bilgileri ile çağırılarak oluşturulan hedef model elemanına erişilir. TEFKAT dili, geliştiricilerin CLASS deyimlerini kullanarak bir dönüşüm içerisinde izlenecek bilgileri tanımlayabilmesine izin vermektedir. Dönüşüm içerisinde değer atanan bu yapılar diğer kurallar içerisinde çağırılarak izlenebilirlik bilgisine ulaşılır. MOLA, kural içerisindeki dönüşüm işlemlerinin tanımlanabilmesi için kaynak ve hedef model elemanları arasında bağlantıların tanımlanmasını zorunlu kılmaktadır. Bu bağlantılara diğer kurallar içerisinde atıf yapılarak hedef model elemanlarına ulaşılabilir. MOLA içerisindeki bu bağlantılar, kullanıcı tanımlı olduğundan dolayı MOLA dönüşüm motoru, otomatik olarak izleme bilgisi tutmamaktadır. ATL model dönüşüm dili motoru ise izleme bilgilerini otomatik olarak kayıtlamakta ve bu bilgileri kullanarak model elemanlarına erişimi sağlamaktadır. TEFKAT ve YATL dilleri, QVT RFP dokümanına uygun olarak geliştirilen diller olmasına rağmen şu an için görsel gösterimi desteklemeyip sadece metinsel gösterime sahiptirler. TEFKAT dilinin soyut söz dizimi (abstract syntax), MOF modelleri şeklinde ifade edilirken somut söz dizimi (concrete syntax), SQL benzeri bir metinsel gösterime sahiptir. MOLA ve GREAT dilleri, görsel gösterime sahip dillerdir. Bu dillerde modelleri sorgulayan sorgu dilleri ve kural tanımları, görsel elemanlar ile ifade edilmektedir. Bunun yanında model elemanları üzerindeki kısıtların ve atama işlemlerinin ifade edilmesi metinsel gösterim aracılığıyla olmaktadır. İncelenen diller içerisinde YATL ve GREAT dilleri, başka dillerde yazılmış kod bloklarının dil içerisinden çağrılıp çalıştırılmasını desteklemektedir. YATL dili içerisinde native{... } şeklinde tanımlanmış blok içerisine yazılmış diğer kodlar, ortam içerisinden çalıştırılıp işletilebilir. Ancak bu kodlar, platform bağımlı kodlar olup

85 işletim sırasında oluşabilecek hatalara karşı davranış, kodun yazıldığı platforma bırakılmaktadır. GREAT dilinde ise C++ dilinde bir modül içerisine yazılmış kodlar çalıştırılıp işletilebilmektedir. TEFKAT dili için kapalı kutu birlikte işlerliği desteklediğine dair herhangi bir ifadede bulunulmamıştır. Dönüşümün yönetilmesi yani kuralların zamanlaması, incelenen bütün diller tarafından desteklenmektedir. Kuralların zamanlaması, ATL ve TEFKAT dillerinde model dönüşüm motorlarına bırakılmıştır. Kullanıcının herhangi bir şekilde hangi kuralın hangi kuraldan önce ya da sonra işletileceğine dair bir bildirimde bulunmasına gerek yoktur. Dönüşüm algoritması, kurallar arasındaki ilişkilerden yola çıkarak kuralların işletim sırasını tespit etmektedir. Bu algoritmalar belirleyici (deterministik) bir yapıda olup dönüşümlerin farklı zamanlardaki işletiminde farklı kural işletim sırası tanımlamaz. GREAT, MOLA ve YATL dillerinde dışsal olarak kuralların işletim sırası belirtilmektedir. GREAT ve MOLA dillerinde kuralların organizasyonu ve zamanlaması için özelleşmiş dönüşüm yönetim dili adında alt diller tanımlanmıştır. Modülerlik yani dönüşüm tanımlarının birimlere ayrılması, zorunlu bir istek olmamasına rağmen bütün model dönüşüm dilleri tarafından desteklenmektedir. ATL içerisinde bir dönüşüm için tanımlanan kurallar module ifadesi kullanılarak belirtilen isimde birimlere ayrılmaktadır. Değişik modüller dönüşüm içerisine dahil edilerek daha önce tanımlanmış kuralların kullanılmasının da önü açılmaktadır. TEFKAT dilinde ise bir kuralın, birden fazla kuralın değişik parçalarından oluşabilmesine imkan sağlanmaktadır. Bu parçaların kurallara dahil edilmesi ve kullanılması modüler mekanizmalar ile sağlanmaktadır. Modeller üzerinde yazma/okuma işleminin aynı anda yapılması zorunlu bir istek olmasına rağmen TEFKAT dili tarafından desteklenmemektedir. (Lawley and Steel, 2005) de belirtildiği üzere bu dil, aynı model üzerinde güncelleme işlemlerinin yapılması (in-place model updates) gibi yatay dönüşümlerin işletilmesi için tasarlanmamıştır. MOLA dilinin ise henüz tam bir uygulaması yapılmadığı ve yayınlanan çalışmalarda da bu durumla ilgili bir ifade yer almadığı için aynı model üzerinde okuma/yazma işleminin desteklenmesi konusunda MOLA dili için belirtilmemiş ifadesini kullandık. Bu iki dil haricindeki ATL, GREAT ve YATL gibi diller, bu desteği vermektedir. Özellikle GREAT dilinde 67

86 68 kaynak ve hedef modelin aynı model olarak gösterilmesi ve model üzerinde okuma/yazma işlevinin aktif hale getirilmesi durumunda model elemanlarının eklenmesi, silinmesi ve güncellenmesi işlemleri aynı model üzerinde yapıldığından dolayı bu dil, yatay ve dikey dönüşümlere tam destek vermektedir. GREAT ve MOLA model dönüşüm dilleri, kuralların dışarıdan çağrılabilmesi (explicit rule calls) için dönüşüm yönetim diline sahip oldukları halde bu diller içerisinde tanımlı bir kural kendi içerisinden bir başka kuralı çağıramadığı için kuralların kümelenmesi, GREAT ve MOLA tarafından tam olarak desteklenememektedir. ATL ve TEFKAT model dönüşüm dillerinde ise dönüşümün yönetilmesi için kuralların çağrımı içsel olarak (implicit rule class) dönüşüm motoru tarafından belirlenmesine rağmen bir kuralın içerisinde başka bir kurala atıf da bulunulabildiği için bu diller, kuralların kümelenmesini desteklemektedir.

87 69 5 ROL TABANLI MODEL SORGU DİLİ Bir model dönüşüm dilinde QVT tarafından tanımlanan gereksinimlerin üç başlık altında toplandığı Bölüm 4 de belirtilmişti. Bu gereksinimlerden yola çıkılarak rol kavramını temel alan bir model dönüşüm dili tasarımı hedeflenmiştir. Öncelikle bu model dönüşüm dilinin sorgu dili tasarımı üzerinde çalışılmıştır. Model sorgu diline ek olarak dilde bulunması planlanan bölümler: Dönüşüm Dili (Transformation Language): Model sorgu dili, uygulama modeli içerisinde değiştirilecek olan kısmı tanımlayan bölümdür. Yani problem tanımının yapılacağı kısım model sorgu dili iken dönüşüm dili, model elemanları arasında uygulanacak dönüşüm işlemlerinin tanımlanacağı bölümdür. Dönüşüm dilinin bir dönüşümü tanımlayabilmesi için kaynak desen ve hedef desen tanımlarının model sorgu dili ile birlikte yapılması gereklidir. Böylece dönüşüm dili; model sorgu dilini içerecek ve kaynak ile hedef tarafta tanımlanmış desenler arasında uygulanacak kuralları belirtecektir. Dönüşüm Yönetim Dili (Transformation Management Language): Bir dönüşüm içerisinde dönüşüm kuralları; ekleme (add), silme (delete), ve güncelleme (update) gibi atomik işlemlerden oluşur. Bu atomik işlemlerin kaynak ve hedef desenler üzerine uygulanması ise dönüşümü meydana getirir. Bu dönüşümler, aslında daha büyük bir dönüşümü oluşturan alt dönüşümler olarak tanımlanabilir. Model dönüşüm dili içerisindeki bu dönüşüm-alt dönüşüm ilişkisini prosedürel programlama dilleri içerisinde tanımlanmış program-alt program ilişkisine benzetebiliriz. Bir dönüşüm içerisindeki bu alt dönüşümlerin anlamsal bütünlük içerisinde işletilebilmesi ve yönetilebilmesi ise dönüşüm yönetim dili vasıtasıyla gerçekleştirilebilir. Dönüşüm yönetim dili ile ana dönüşüm içerisinde yer alan alt dönüşümlerin tanımlanması ve

88 70 bu alt dönüşümlerin hangi sıra ile çağırılacağı gibi işlemler tanımlanacaktır. Rol kavramı ile sorgu yapılarının kaynak modeller içerisinde aranmasında ve eşleşen model elemanlarının hedef desene uygun olarak hedef model elemanlarına dönüştürülmesinde çizge dönüşümleri içerisinde tanımlanan kavramlardan yararlanılabilir. 5.1 Çizge Kavramı ve Çizge Tabanlı Dönüşüm Araçları Bir çizge, E VxV olmak üzere G = (V, E) şeklinde tanımlanmış bir ikiliden meydana gelmektedir. V kümesinin elemanları çizgenin köşelerini (vertices) oluştururken, E kümesinin elemanları çizgenin kenarlarını (edge) oluşturmaktadır. Bu tanımdan yola çıkarak çoklu çizge (multi graph), tipsiz çizge (untyped graphs), tipli çizge (typed graphs), iki bölümlü çizge (bipartite graphs), etiketli çizge (labeled graphs) ve özellikli çizge (attributed graph) olmak üzere değişik çizge tipleri bulunmaktadır. Bu çalışmada kullanılan üst modele dayanan yazılım modellerini, tipli ve özellikli çizgeler kapsamında inceleyebiliriz. Şekil 5.1, Mens (Mens, 2005) tarafından tanımlanan modeller ile çizgeler arasındaki ilişkiyi göstermektedir. Şekil 5.1 Modeller ve Çizge Gösterimleri Arasındaki İlişki (Mens, 2005) Modeller, bir üst modelden türetildikleri için tipli çizge olurken üst modelde yer alan üst sınıfların Attribute içermesi nedeniyle bu modeller, özellikli çizge olurlar. Modellere çizgeler olarak davranılması, model dönüşümlerinde çizge dönüşüm sistemlerinin kullanılmasını

89 sağlamaktadır. Mens (Mens, 2005), çizge dönüşümlerinin model dönüşümlerinin tanımlanmasında ve uygulanmasında kullanılmasını aşağıdaki nedenlerle açıklamaktadır: 71 Model elemanları ve bu elemanlar arasındaki ilişkiler, bire bir olarak çizge içerisindeki köşeler ve bu köşeler arasındaki bağlantılara eşlenebilir. Çizge dönüşümleri için tanımlanan teori, model dönüşümlerinin uygulanması için bir taban oluşturmaktadır. GREAT (Agrawal et al., 2003), MOLA (Kalnins et al, 2004b), VIATRA (Csertan et al., 2002) çizge tabanlı model dönüşüm tekniğini temel alan dillere örnektir. Çizge teorisi kapsamında bir çok dönüşüm aracı geliştirilmiştir. PROGRES (Schürr, 1994), AGG (Ermel and Schultzke, 1999), DiaGen (Viehstaedt and Minas, 1995), GenGEd (Bardohl et al., 2003), VIATRA (Csertan et al., 2002) ve GREAT (Agrawal et al., 2003) bu araçlardan bazılarıdır. DiaGen ve GenGEd, görsel dil ortamları iken PROGRES, AGG, VIATRA ve GREAT genel amaçlı çizge dönüşüm dilleridir. Programmed Graph Replacement System (PROGRES), Aachen Teknoloji Üniversitesinde geliştirilmiş bir araçtır. Araç, çizge tanımlarını yapabilmek için bir editör içermektedir. Kalıtım (Inheritance), birleştirme (composition) gibi tip tanımlarını içeren tip sistemi Schema adı verilen bir metinsel dil ile yazılmıştır. Görsel bir editör aracılığıyla tanımlanan çizge dönüşümleri, metinsel bir akış dili ile ana dönüşümün içerisinde kullanılır. AGG ise tipli çizge tanımlarının kullanıcı tarafından yapılabilmesi amacıyla görsel bir editöre sahiptir. Bu editör yardımıyla oluşturulan tipli çizgede belirtilen tipler kullanılarak çizgeler tanımlanmaktadır. Tipli çizge ve bu tipli çizgedeki tipleri kullanarak oluşturulan çizge, üst model ve bu üst model kullanılarak oluşturulan model ile paralellik taşımaktadır.

90 72 Bölüm 3.6 da ayrıntılı şekilde incelenen GREAT model dönüşüm dili, ABD nin Vanderbilt üniversitesinde geliştirilmiş çizge tabanlı bir model dönüşüm dilidir. GREAT dili, MOF ya da ECore gibi MDA kapsamında geliştirilen ve benzerlikler taşıyan modelleme alt yapılarını kullanmak yerine Generic Modeling Environment (GME) modelleme ortamı kullanılarak geliştirilmiştir. Dil içerisinde tanımlanan model elemanları ve bu elemanlar arasındaki ilişkiler, dönüşüm alt yapısında birer çizge ve bu çizgeler arasında tanımlanmış bağlantılar şeklinde tutulmakta ve bu modellerin dönüşüme uğratılması yine dile özel çizge dönüşüm algoritması ile gerçekleştirilmektedir. 5.2 Rol Kavramı Rol kavramı, ilk olarak Backhman ve Daya (Backhman and Daya, 1977) tarafından nesneye dayalı programlama grubunda tanıtılmıştır. Bu kavram, bir sistemde yer alan elemanların sistem içerisindeki görevlerini tanımlar. Bu görevlerin ilgili sistem elemanlarına atanması, o elemanlara rol ataması ile gerçekleştirilir. France (France et al., 2003a), tasarım desenlerinin modellenmesinde model rolü kavramını kullanmıştır. Nesne rolleri, sadece nesne tabanlı sistemlerde kullanılabileceğinden bu kavram değiştirilerek model rolü haline getirilmiştir. Model-Rol ilişkisi Şekil 5.2 de gösterilmektedir. Dört katmanlı UML mimarisinde model rolleri, M2 katmanında tanımlanırlar. Her bir model rolü, UML üst-modeline ait bir üst sınıfından türetilir. Roller, bu üst sınıflar üzerine bazı kısıtlamalar tanımlayarak bir sınıftan örneklenebilecek alt kümeyi tanımlarlar.

91 73 Şekil 5.2 UML Mimarisi ile Model Rol ilişkisi (France et al., 2003a) Roller, Classifier ve Relationship UML üst sınıflarından türetilirler. Classifier üst sınıfından türetilen bir rol, rolün sahip olması gereken yapısal ve davranışsal özellikler ile bu rolü oynayacak model elemanlarının sayısını belirtir. Bir Classifier rolünün sahip olması gereken bu özellikler, sırası ile StructuralFeature ve BehavioralFeature üst sınıflarından türetilmiş rolleri oynayan model elemanlarına karşılık gelmektedir. Örnek bir Class rolü, UML sınıf sembolü ile Şekil 5.3 de gösterilmiştir. Bu gösterimde rolün üst sınıfı, üst model seviyesindeki kısıtları ve bu rolleri oynayacak model eleman sayılarını tanımlar. Şekil 5.3 Bir Class rolünün yapısı (Kim et al., 2004)

92 Rol ve Çizge Kavramlarının Tasarlanan Dil İçerisinde Kullanılması Bu çalışmada model sorgu dili tasarlanan ROl tabanlı model dönüşüm dilinde (RODEL) bütün yapıların roller ile gösterilmesi planlanmıştır. Dönüşümde yer alan bütün yapıların roller ile ifade edilmesi, dil içerisinde tanımlanacak rollerin hem kaynak üst modelini hem hedef üst modelini hem de dönüşüm dili üst modelini desteklemesini gerektirir. Bu nedenle dildeki dönüşüm kuralları, alt dönüşüm çağrımları, kontrol yapıları gibi dil elemanları da roller ile ifade edilmelidir. Sorgu dilinin tanımlanmasında gösterim olarak görsel gösterim tercih edilmiş ve dil içerisindeki her bir elemanı tanımlayan rollerin ifade edilmesinde ise (France et al., 2003a) da anlatılan rol gösteriminden yararlanılmıştır. Bu roller, UML model diyagramları içerisinde modellenen tasarım desenlerinin formalize edilmesi için tanımlanmıştır. Rol modeller; katlı ifade (folded expression), kısaltılmış ifade (abbreviated expression), ve ayrıntılı ifade (detailed expression) gibi farklı şekillerde gösterilmektedir (France et al., 2003a). Bu çalışmada hedef ve kaynak desenlerin rol modeller ile gösteriminde ayrıntılı ifadelerden yararlanılmıştır. Ayrıntılı ifadeler, bire bir rol modellerin üst modeldeki sınıflarla olan eşleşmesini tanımlamaktadır. Genel olarak rol gösterimi; rol gerçekleştirme sayısı (role cardinality) ve Object Constraint Language (OCL) (Warmer and Kleppe, 2003) kullanarak rolü oynayan sınıflara ait bir çok özelliği tanımlamamıza olanak sağlamaktadır. Dilin tanımlanmasında çizge dönüşüm (graph transformations) kavramlarından yararlanılabilir. Rollerin ifade ettiği model elemanları kümesi bir çizgenin köşelerine benzetilirse roller arasında tanımlanan ilişkiler de çizgenin köşeleri arasında tanımlanmış kenarlara benzetilebilir. Çizge dönüşüm sistemleri, desenlerin uygulama modelleri içerisinde eşlenmesi ve eşlenen modellerin birbirlerine dönüştürülmesi işlemi için tanımlayıcı (declerative) bir yöntem sunmaktadır (Sendall and Kozacyski, 2003). Bir çizge dönüşümü, çizge yeniden yazma kuralları (graph rewriting rules) adı verilen çizge kuralları kümesi olarak tanımlanmaktadır. Bir çizge kuralı ise sol taraf çizgesi (left hand side graph LHS) ve sağ taraf çizgesi (right hand side graph RHS) olmak

93 üzere iki tane çizge içermektedir. Sol taraf çizgesi, eğer ana çizge içerisinde eşlenirse ana çizge içerisinde eşlenen alt çizge yerine sağ taraf çizgesi oluşturulur. Çizge dönüşüm sistemi, sol taraf çizgesini uygulama modeli içerisinde aranan bir kaynak desen gibi kullanır. Birer çizge olan model elemanlarının sorgu tanımları içerisinde roller ile gösterilmesi, çizge dönüşümlerini dilin söz diziminde roller ve aralarındaki ilişkiler ile somutlaştıracaktır Sorgu Dili Üst Modeli ve Üst Model Katmanları Arasındaki İlişkiler Önerdiğimiz model sorgu dilinin katmanları, görsel modelleme dilleri katmanları olarak düşünülebilir. Buna göre görsel bir modelleme dili; somut sözdizimi (concrete syntax), soyut sözdizimi (abstract syntax) ve anlamsal alan (semantics domain) olmak üzere üç farklı seviye etrafında tanımlanmaktadır (Akehurst and Kent, 2002) (Baresi and Heckel, 2002). Şekil 5.4, modelleme dili tanımlanmasında kullanılan bu üç farklı seviyeyi ve bu seviyeler arasındaki ilişkileri göstermektedir. Şekil 5.4 Modelleme Dillerini Oluşturan Katmanlar (Baresi and Heckel, 2002) Dilin soyut sözdiziminde yani üst modelinde rol ve içerisindeki elemanların (üst model seviyesi kısıtları, rol gerçekleştirme sayıları, vb.) tanımlanması gerekmektedir. Bütün bu yapılar, dil üst modelinde yer alan

94 76 üst sınıflardan türeyen örnekler ile tutulmalıdır. Şekil 5.5 de dönüşüm, rol ve role ait üst seviyedeki yerel kısıtların dönüşüm dilinin üst modelinde nasıl tanımlandığı gösterilmektedir. Şekil 5.5 Sorgu Dilinin Üst Modeli (Soyut Sözdizimi) Şekil 5.5 deki sorgu dili üst modeline göre dönüşüm, içerisinde bir çok rolü içermektedir. Dönüşüm üst sınıfı, dönüşümü temsil etmekte ve Rol üst sınıfını tutmaktadır. Rol ise, OCL deyimlerini taşıyan üst kısıtlarla model elemanlarını eşler. Rol üst sınıfının sahip olduğu üst model seviyesindeki kısıtlar, Rol üst sınıfı için yazılan kısıtlar olmayıp kaynak ya da hedef üst modelde o rolü oynayan model elemanları için yazılacak kısıtlardır. Bunun dışında rol için tanımlanmış bütün özellikler, Rol üst sınıfı üzerinde birer özellik olarak tanımlanır. Rolün hangi kaynak ya da hedef üst modelindeki üst sınıflar tarafından oynandığı bilgisi, rolü oynayan model elemanlarının minimum ve maksimum sayı bilgileri yine birer özellik olarak Rol üst sınıfında tanımlanır. Şekil 5.5 de OCL ile ilgili deyimler OCLExpression üst sınıfı ile temsil edilmektedir. OCL in üst modelinde tanımlanan OCLExpression üst sınıfı, OCL içerisinde yer alan deyimleri temsil eder. Şekil 5.5 de dil üst sınıflarının OCL üst sınıflarıyla ilişkisi OCLExpression üst sınıfı

95 aracılığıyla sağlanmaktadır. ÜstSeviyeKısıt üst sınıfı, OCLExpression üst sınıfını tutarak OCL deyimlerini içerir. Bir modelleme dilinin anlamsal alanı, o dildeki yapıların anlamlarını ifade eder. Bu ifadenin tanımlanması için iki adım izlenmektedir: ilk olarak bir anlamsal alan tanımlanmalı, ikinci olarak da tanımlanan bu anlamsal alan ile soyut söz dizim arasında ilgili eşlemeler yapılmalıdır (Rumpe, 1998). Tanımlanan sorgu dilinin anlamsal alanı; kaynak model elemanlarını, değerleri, bağlantıları ve sorgunun kendisini içermelidir. Şekil 5.6, sorgu dilinin anlamsal alanını göstermektedir. 77 Şekil 5.6 Sorgu Dilinin Anlamsal Alanı Dil içerisindeki bütün kavramların roller ile ifade edilmesine karşılık, dil üst modeli ile olan ilişkilere bakıldığında iki değişik rol yer alır. Birinci tip rolde, rolü oynayan sınıflar kaynak ya da hedef modellerde yer almaktadır. Bu nedenle rolün tanımladığı üst sınıflar kaynak ya da hedef üst modellerinde yer alırken rolün türediği üst sınıf dil üst modelinde yer almaktadır.

96 78 Şekil 5.7 Kaynak Üst Model Sınıfları ve Roller Arasındaki İlişkiler Şekil 5.7 de kaynak üst modeli ile dil üst modeli arasındaki ilişki görülmektedir. Dil üst modelinde yer alan Rol üst sınıfından örneklenen <<Class Rolü>>, kaynak üst model içerisinde yer alan <<Class>> üst sınıfını tanımlamakta ve bu üst sınıftan örneklenen model elemanları bu <<Class Rolü>> oynamaktadır. Kaynak ya da hedef modellerde yer alan model elemanlarının oynadığı roller, aynı zamanda dil üst modelinde yer alan Rol üst sınıfından türetilmektedir. Şekil 5.8 Dönüşüm Üst Sınıfı ve <<Dönüşüm Rolü>> Arasındaki İlişki

97 Şekil 5.8, ikinci tip rollerin dil üst modelindeki üst sınıflarla olan ilişkisini göstermektedir. Dil içerisinde yer alan ikinci tip roller, dil içerisinde dönüşüm kuralları gibi dil üst sınıfında yer alan üst sınıflar tarafından oynanır. Bu tip sınıflar, dil içerisindeki temel kavramları oluşturur. Dil üst sınıfları tarafından oynanan roller, Şekil 5.7 deki gibi Rol üst sınıfından örneklenmeyip yine o rolü oynayan üst sınıftan türetilir. Şekil 5.8 deki <<Dönüşüm Rolü>> ile Dönüşüm üst sınıfı arasında hem <<tanımlar>> hem de <<örnekler>> ilişkisi mevcuttur. <<Dönüşüm Rolü>>, Dönüşüm üst sınıfından türediği gibi bu üst sınıfı da tanımlar. Bu rol tipleri ve dil üst modelindeki eşlemeler ışığında Şekil 5.9, en az bir metoda sahip hiç özelliği olmayan bir sınıfı sorgulayan sorgunun sorgu dili üst modeli örnekleriyle ifadesini göstermektedir. Bu sorgu tanımı içerisinde Trs ve Cls adlarında iki farklı rol bulunmaktadır. Bu iki rol arasında tanımlanmış olan başlatır adlı ilişki, Şekil 5.5 deki dil üst modelinde Dönüşüm üst sınıfıyla Rol üst sınıfı arasında tanımlanmış olan üst ilişki ile ifade edilir. Diğer roller arasındaki ilişkiler ise, dil üst modelinde bulunan İlişki üst sınıfının örnekleri şeklinde tanımlanır. Bu ilişkiler, kaynak ve hedef üst modellerinde bu rolleri oynayan üst model elemanları arasındaki ilişkileri tanımlar. Tanımı daha basitleştirebilmek amacıyla Şekil 5.9 de sorgu tanımındaki kısıtlara yer verilmemiştir. 79

98 80 Şekil 5.9 Örnek Sorgunun Sorgu Dili Üst Modeli Örnekleriyle İfadesi 5.5 Dil İçerisindeki Temel Yapılar Aynı özelliklere sahip model elemanlarını sorgulayabilmek için model elemanlarının tip bilgisine, model elemanlarının sağlaması gereken kısıtlara, model elemanı sayısına ve model elemanlarının diğer model elemanları ile olan ilişki bilgisine ihtiyaç vardır. Rol tabanlı sorgu dili içerisinde bütün bu bilgileri içerecek temel eleman Rol kavramıdır. Roller, sorgunun üzerinde çalışacağı model elemanlarını tanımlamak için kullanılabilir. Örneğin, Şekil 5.3 de tanımlanan bir <<Class Rolü>> sorgu tanımı içerisinde bir UML Class ını sorgulamak için bütün bilgiye sahiptir. <<Class Rolü>>, UML üst modelindeki Class üst sınıfına karşılık gelerek sorgulayacağı model elemanının tip bilgisini tutar. 0..* olarak belirtilen rol gerçekleştirme sayısı, bu rolü oynayan birden fazla sınıf olabileceğini yani sorgudan dönecek model elemanı sayısının birden fazla olabileceğini belirtmektedir. Yine <<Class Rolü>> ile <<Attribute Rolü>> gibi diğer roller arasında tanımlanacak ilişkiler, <<Class Rolü>> nü oynayacak model elemanlarının diğer model elemanları ile arasındaki ilişkileri tanımlayacaktır. Meta-Level Constraints başlığı altına yazılmış kısıt ile de sorgulanacak Class üst sınıf örneklerinin kind

99 özelliğinin persistent olması gerektiği belirtilmektedir. Bu şekilde sorgulanacak model elemanlarının sağlaması gereken kısıt bilgileri de ifade edilebilir. Böylece Rol kavramı, temel sorgu elemanı olarak sorgudan dönecek model elemanlarını tanımlamak için yeterli olacaktır. Diğer model dönüşüm dillerinin sorgu dillerinden (Duddy et al., 2003) (Agrawal, 2004) (Jouault and Kurtev, 2005) farklı olarak rol tabanlı sorgu tanımlarında yer alan kısıtlar yereldir. Bir rol içerisinde belirtilen üst model seviyesindeki kısıtlar, o rolü oynayan model elemanlarını tanımlar. O rol ile ilişkili diğer rolleri oynayan model elemanlarını tanımlayan herhangi bir kısıt içermezler. Kısıtların yerel olması ise sorguların daha kolay okunabilir, izlenebilir ve yeniden kullanılabilir olmasını sağlamaktadır. Karmaşık desen tanımlarını (Goknil and Topaloglu, 2006) içeren dönüşüm kurallarının dönüşüm operasyonlarının birleşimini ve yeniden kullanımını desteklemesi için kısıtların her bir desen elemanı için yerel olması gerekmektedir. Kısıtların yerel olmadığı model dönüşüm dillerinde bir sorgu yazılırken model elemanları arasındaki ilişkiler de kısıt şeklinde yazılmak zorundadır. Örneğin Şekil 5.10 da verilen basitleştirilmiş UML üst modelinden türetilen modellerde en az bir özelliğe (attribute) sahip olan kalıcı sınıfların aranacağı bir sorgu yazılmak istenirse, bu sorgunun üç değişik kısıttan oluşması gerekmektedir. Sorgunun modelden uygun bir eşleşme ile dönebilmesi için ilk kısıt, uygulama modelinde en az bir tane sınıf olmasıdır. İkinci kısıt, bu sınıfın kind üst özelliği kalıcı yani persistent olmasıdır, üçüncü kısıt ise bu sınıfın sahip olduğu en az bir tane özellik bulunmasıdır. Kısıtların yerel olarak yazılamadığı bir model dönüşüm dilinde bu tip bir sorguyu oluşturan kural, bu üç kısıtı da aynı desen elemanı üzerinde içermek durumundadır. Bu sorguyu karmaşıklaştırdığı gibi kısıt sayısının daha fazla olduğu durumlarda karmaşık sorguların yazılmasını zorlaştırmaktadır (Goknil and Topaloglu, 2006). 81

100 82 Şekil 5.10 Basitleştirilmiş UML Üst Modeli Kısıtların yerelliğini ilkesini sağlamayı amaçladığımız için tasarladığımız dilde her bir kısıt, üzerinde işletileceği model elemanını karakterize eden rol için üst seviye kısıtları (meta-level constraint) başlığının altına yazılacaktır. Örneğin bu tip bir sorgu RODEL ile ifade edildiğinde bir <<Class Rolü>>, bir <<Attribute Rolü>> ile ilişkilendirilir ve <<Class Rolü>> için üst seviye kısıtlarda belirtilen (self.kind=persistent) kısıtı ile o rolü oynayacak sınıflar için yerel kısıt yazılmış olacaktır. Sorgu dilinde <<Class Rolü>> nün varlığı tiple ilgili ilk kısıtı oluştururken, o rol için yazılan üst seviye kısıtlar da ikinci kısıtı oluşturur. Yine <<Attribute Rolü>> nün varlığı ve <<Class Rolü>> ile arasında tanımlanan ilişki de sorgudaki üçüncü kısıtı meydana getirmektedir. Kısıtların yerelliği ilkesi ile kısıtlar arasındaki eşleme (coupling) azalmaktadır. Şekil 5.11 de rol tabanlı sorgu dili içerisinde anlatılan bu sorgu tanımı verilmektedir.

101 83 Şekil 5.11 RODEL Sorgu Dilinde Örnek Bir UML Model Sorgusu Şekil 5.11 deki sorgu ile bir UML sınıfının sıfır ya da daha fazla sayıda özelliğe sahip olma durumu tanımlanmıştır. Bu sorgunun bir UML modelinden en az bir eşleşme ile dönebilmesi için aranan modelde en az bir sınıfın olması gerekir. <<Attribute Rolü>> nü oynayan Attribute üst sınıflarının sayısı sıfır olabileceği için, <<Attribute Rolü>> veya mantıksal operatörü ile sorguya bağlanır. Roller üzerine yazılan kısıtlar yereldir. <<Class Rolü>> içinde <<Attribute Rolü>> ile ilgili kısıtlar yazılamaz. Örneğin desen tanımını biraz değiştirirsek, en az bir özelliğe sahip UML sınıflarının tanımı için gerekli kısıt <<Class Rolü>> üzerinde üst seviye kısıtı olarak yazılamaz. Bu kısıt, desende <<Class Rolü>> nün <<Attribute Rolü>> ile ilişkili olması ve <<Attribute Rolü>> nün rol gerçekleştirme sayısının 0..* yerine 1..* olarak değiştirilmesi ile ifade edilir. Aynı zamanda bu şekilde iki rolü oynayan üst sınıflar üzerine ve mantıksal operatörü uygulanır. Desende <<Class Rolü>> ile <<Attribute Rolü>> arasındaki ilişki UML in üst modelinde Class ve Attribute üst sınıfları arasındaki ilişkiden kaynaklanmaktadır. Dilin derleme aşamasında desenlerin içerdiği rollerin arasındaki ilişkilerin doğruluğu, kaynak yada hedef üst modelleri arasında o rolleri oynayan üst sınıfların arasındaki ilişkilere bakılarak sınanabilir. Rol gerçekleştirme sayıları, bütün modelde o rolü oynayan model elemanı sayısına göre değil, desen için dönecek bir eşleşmede yer alan model elemanı sayısına göre yazılacaktır. Örneğin, Şekil 5.12 de verilen örnek bir UML modeli üzerine Şekil 5.11 deki kaynak desenin

102 84 uygulanması sonucunda dönecek eşleşmeler Şekil 5.13 deki gibi olacaktır. Şekil 5.12 Yayıncı-Kitap UML Modeli Şekil 5.11 deki kaynak desenin Yayıncı-Kitap UML modeli üzerine uygulanması sonucunda iki tane eşleşme dönecektir. Şekil 5.11 deki <<Class Rolü>> nü oynayan tek bir sınıf olmalı koşulu bu durumu göstermektedir. Sorgu bir eşleşmeyi tarif eder ve sorgu içindeki roller bütün uygulama modelini aynı anda kapsamaz. Şekil 5.13 de gösterilen eşleşmelerin birincisinde <<Class Rolü>> nü oynayan Yayıncı sınıfı ile <<Attribute Rolü>> nü oynayan isim özelliği sorgu sonucunu oluşturur. Model içerisinde hem Kitap sınıfı hem de Yayıncı sınıfı <<Class Rolü>> nü oynamasına rağmen desen bir eşleşmeyi tarif ettiği için modelden aynı desen tanımı için iki farklı eşleşme dönecektir. Şekil 5.13 Sorgunun İşletilmesi Sonucu Dönen Değerler

103 Rolleri oynayan model elemanları üzerine ve, veya gibi mantıksal operatörlerin yanı sıra değil mantıksal operatörü de uygulanabilir. ve ve veya mantıksal operatörleri rol gerçekleştirme sayıları ile gösterilirken değil operatörü roller arasındaki ilişkinin değil operatörü ile etiketlenmesi ile gösterilir. Bir A rolünün ilişkili olduğu B rolü üzerinde değil operatörünün kullanılması herhangi bir model elemanının A rolünü oynayabilmesi için B rolünü oynayan model elemanlarından hiçbiri ile ilişkide olmamasını gerektirir. Şekil 5.14 de değil operatörü kullanan bir desen tanımı verilmiştir. 85 Şekil 5.14 Sorgu Tanımı İçerisindeki Mantıksal Operatörler Şekil 5.14 deki desen, özelliği olmayan ama en az bir tane metoda sahip olan bir UML sınıfını tanımlamaktadır. <<Class Rolü>> ile <<Attribute Rolü>> arasındaki ilişkiye değil operatörünün uygulanması, <<Class Rolü>> nü bir sınıfın oynayabilmesi için herhangi bir özelliğinin olmamasını gerektirmektedir. Şekil 5.14 de değil operatörünün uygulandığı <<Attribute Rolü>> için rol gerçekleştirme sayısı belirtilmemiştir. Rol gerçekleştirme sayısının belirtilmemesinin nedeni eşleşme içerisinde o rolü oynayacak model elemanlarının bulunmayacağını ifade etmektir. Şekil 5.15 de belirtilen desen tanımında Şekil 5.14 deki değil işleminden farklı olarak <<Y Rolü>> ile <<Z Rolü>> arasındaki ilişki üzerinde değil operatörü işletilirken <<X Rolü>> ile <<Y Rolü>> arasında bu iki rolün

104 86 rol gerçekleştirme sayılarının sıfırdan farklı olması nedeniyle bir ve ilişkisi kurulur. Şekil 5.15 Değil Operatörünün Rol Tanımları Arasındaki İlişkiler Üzerine Uygulanması Şekil 5.15 da belirtilen sorgu tanımında <<X Rolü>> nü oynayan model elemanı, <<Y Rolü>> nü oynayan en az bir model elemanı ile ilişkili olmalıdır. Şekil 5.14 deki değil işleminden farklı olarak <<Y Rolü>> için rol gerçekleştirme sayısı belirtilmiştir. Bu şekilde sorgu için uygun bir eşleşmede herhangi bir Y model elemanı ile ilişkili olmayan bir Z model elemanı ile bu Z model elemanıyla ilişkili olmayan bir ya da birden fazla sayıda Y model elemanı dönecektir. Eğer değil operatörü roller arasındaki ilişkiler üzerinde işletilmeyip direk rolü oynayan model elemanları üzerinde işletilmiş olsaydı Şekil 5.15 deki gibi bir sorgu tanımı yapmak mümkün olmayacaktı. 5.6 Desen Eşleşmelerinde Belirsizlikleri Önlemek İçin Kullanılan Yapılar Agrawal (Agrawal et al., 2003), bir model dönüşüm dilinde tanımlanabilecek desenleri; basit desenler (simple patterns), sabit sayılı desenler (fixed cardinality patterns) ve değişken sayılı desenler (variable cardinality patterns) olmak üzere üç başlık altında tanımlamıştır.

105 87 Şekil 5.16 Desen Tanımları (Agrawal et al., 2003) Şekil 5.16(a) da basit desen olarak tanımlanmış desen tanımı verilmiştir. Bu desen tanımlarını rol modellerle de açıklayabiliriz. Buna göre bir desenin basit desen olarak tanımlanabilmesi için deseni oluşturan her bir rolü oynayan model elemanı sayısının her bir desen için bir olması gerekmektedir. Bu desende her bir rolü oynayan tek bir model elemanı olduğu için bir rolü oynayan bir model elemanı diğer rolü oynayan sadece bir model elemanıyla ilişkilidir. Örneğin Şekil 5.16(a) da <<A Rolü>> nü oynayan bir model elemanı, <<B Rolü>> ve <<C Rolü>> nü oynayan sadece birer elemanla ilişkilidir. Sabit sayılı desenlerde deseni oluşturan rol gerçekleştirme sayılarının sabit ve birden fazla olabildiği durumlardır. Değişken sayılı desenlerde ise deseni oluşturan rollerden en az birisinin rol gerçekleştirme sayısı değişkendir. Örneğin Şekil 5.16(c) de <<B Rolü>> nü oynayan model elemanı sayısı ikiden az olmamak şartı ile değişken sayıdadır. Bu duruma örnek olarak çoklu kalıtım içeren modelleri sorgulayan desen tanımını verebiliriz. Çünkü çoklu kalıtımın desen tanımında rol gerçekleştirme sayısı bir olan <<Class Rolü>>, rol gerçekleştirme sayısı 2..* olan başka bir <<Class Rolü>> ne üst modelden gelen generalization ilişkisi ile bağlıdır. Sabit sayılı ve ya değişken sayılı desenlerin model üzerinde eşleşmesinde farklı sonuçlarla karşılaşılabilir. Şekil 5.17(a) da bir sabit sayılı desen tanımlanmıştır. Şekil 5.17(b) ve Şekil 5.17(c) de bu desenin model üzerinde uygulanması sonucu ortaya çıkan farklı eşleşmeler gösterilmektedir.

106 88 Şekil 5.17 Sabit Sayılı Bir Deseninin Uygulama Modeli Üzerindeki Eşleşmeleri Şekil 5.17(a) da B rolünü oynayan üç model elemanı ile C rolünü oynayan altı model elemanı arasında tanımlı ilişki nedeniyle farklı eşleşmeler gerçekleşebilir. Bu iki rolü oynayan model elemanları arasındaki ilişkinin iki ucundaki model elemanlarının sayısının belirtilmemesi nedeniyle iki tane farklı eşleşme dönebilir. Örneğin Şekil 5.17(b) de desen uygulama modeli eşleşmesinde B rolünü oynayan her bir model elemanı C rolünü oynayan iki tane model elemanı ile ilişkiliyken Şekil 5.17(c) deki eşleşmede B rolünü oynayan her bir model elemanı C rolünü oynayan bütün model elemanlarıyla yani altı model elemanıyla da ilişkilidir. Şekil 5.17(a) daki desen tanımında sadece rolü oynayan model elemanlarının sayısı belirtilmiş olup bu rolleri oynayan model elemanlarının birbiriyle hangi sayıda ilişkili olabilecekleri bilgisi verilmemiştir. A rolü ile B rolü arasındaki ilişkideki gibi 1-n (one-tomany) ilişkilerde ya da 1-1 (one-to-one) ilişkilerde rolü oynayan

107 model elemanları arasındaki ilişkilerin tanımı roller üzerinde verilen rol gerçekleştirme sayılarından çıkarılabilir. Bu nedenledir ki A rolü ile B rolünü oynayan model elemanları ancak ve ancak 1-3 bir ilişkiyle bağlıdır ve aralarında daha farklı bir ilişki kurulamaz. Ancak B rolü ile C rolü arasındaki ilişkide olduğu gibi n-n (many-to-many) ilişkilerde model elemanları arasındaki belirsizliği kaldırmak için rol gerçekleştirme sayılarının yanı sıra rolü oynayan model elemanları arasındaki ilişkiler için de ayrıca ilişki tanım sayılarının (relation cardinality constraints) belirtilmesi gerekmektedir. Şekil 5.18 de Şekil 5.17(b) ve Şekil 5.17(c) deki eşleşmeler için ilgili ilişki tanım sayıları verilmiştir. 89 Şekil 5.18 Rolü Oynayan Model Elemanları Arasındaki İlişkiler için Sayı Kısıtları Şekil 5.18 deki desen tanımlarından görülebileceği gibi rolleri oynayan model elemanları arasındaki ilişkilere de sayı kısıtı koyarak desen eşleşmelerindeki farklılıklar ortadan kaldırılmıştır. Bununla birlikte RODEL içerisinde bir kaynak ya da hedef deseni oluşturan roller için rol gerçekleştirme sayısı (role cardinality) ve ilişki tanım sayısı (relation cardinality) olmak üzere iki farklı sayı kısıtı tanımlanmaktadır. Rol gerçekleştirme sayısı, o rolü oynayabilecek model elemanı sayısını belirtirken roller arasındaki ilişkiler için yazılan ilişki tanım sayısı ise rolleri oynayan model elemanlarının birbiriyle hangi sayıda ilişki kuracağını tanımlayan kısıttır. Şekil 5.18(a) daki desen tanımının bir model üzerine uygulanması sonucu ile Şekil 5.17(b) deki eşleşme

108 90 gerçekleşecektir. Bu desene göre A rolünü oynayan bir model elemanı B rolünü oynayan üç tane model elemanı ile ilişkiliyken B rolünü oynayan her bir model elemanı C rolünü oynayan iki tane model elemanı ile ilişkilidir. A ile B rollerini oynayan model elemanları arasındaki ilişki, 1-n bir ilişki olduğundan dolayı A ile B rolleri arasında bir ilişki tanım sayısı belirtmek gerekli değildir. Bu ilişki kısıtları, rol gerçekleştirme sayılarından da çıkarılabilir. RODEL ile tanımlanmış bir desen içerisinde roller arasındaki 1-1 ya da 1-n ilişkiler için ilişki tanım sayısı belirtmek gerekli değildir çünkü bu durumlarda rol gerçekleştirme sayısı aynı zamanda ilişki tanım sayısını da verir. Şekil 5.18(b) deki desen tanımında B ile C rolleri arasındaki ilişki tanım sayıları, 1-2 yerine 3-6 şeklindedir. RODEL içerisinde tanımlanan kaynak ve hedef desenlerin tutarlılığının kontrol edilmesi gerekmektedir. Bir desen, söz dizimsel olarak doğru olduğu halde ilgili üst modelde yer alan üst sınıflar ve bu üst sınıflar arasındaki ilişkiler desen ile tutarlı olmayabilir. Örneğin Şekil- 18(a) deki desende B rolü ile C rolleri ve aralarında bir ilişki tanımlanmıştır. Bu tanımlanan desen, söz dizimsel olarak doğru olmasına rağmen çeşitli sebeplerden dolayı geçerli olmayabilir. Uygulanacağı üst modelde B ve C gibi iki tane üst sınıf olmayabilir, bu üst sınıflar arasında geçerli bir ilişki olmayabilir ya da roller için belirtilen rol gerçekleştirme sayıları ve ilişki tanım sayıları birbiriyle tutarlı olmayabilir. Bu ve bunun gibi benzeri durumların bir desen tanımında kontrol edilmesi gereklidir. Şekil 5.19 Kaynak Üst Model Kullanılarak Kaynak Desenin Tutarlılığının Kontrolü

109 Şekil 5.19 daki gibi geçerli bir kaynak ya da hedef desenin kaynak ya da hedef üst modele bakılarak oluşturulabilmesi için desenin aşağıdaki şartları sağlaması gereklidir. Desen içerisinde rol tanımlarının yapılabilmesi için hedef ya da kaynak üst modelde o rollerin türediği üst sınıflar bulunmalıdır. Örneğin Şekil 5.19 da belirtilen desen için; A Rolü, A üst sınıfını belirtmektedir. B Rolü, B üst sınıfını belirtmektedir. İki ya da daha fazla rol arasında bir ilişki tanımlayabilmek için kaynak ya da hedef üst modelde o rollerin tanımladığı üst sınıflar arasında da aynı ilişki bulunmalıdır. ( ( A Rolü, A üst sınıfını belirtmekte ) ve ( B Rolü, B üst sınıfını belirtmekte ) ve ( A Rolü ile B Rolü arasında ilişki2 adlı bir ilişki bulunmakta) ) şeklinde tanımlanmış bir sorgunun geçerli olabilmesi için ( (A üst sınıfı ile B üst sınıfı arasında ilişki1 adlı ilişki bulunmalıdır) ve ( ilişki2 adlı ilişki ilişki1 adlı ilişkiyle uyumlu olmalıdır) ) Roller üzerinde tanımlanmış rol gerçekleştirme sayıları ve ilişki tanım sayıları, birbiriyle ve üst modelde belirtilmiş sayı kısıtlarıyla tutarlı olmalıdır. Şekil 5.19 da belirtilen desen için; f(a, b) = a / b şeklinde tanımlı bir fonksiyonda iki rol arasındaki rol gerçekleştirme sayısı ile ilişki tanım sayısının tutarlı olabilmesi için; f(a1,a2) = f(b1,b2) a1 ve b1 kısıtları kendi aralarında asal sayı ise ilişki tanım sayısı, rol gerçekleştirme sayısına eşit olmalıdır. a2 x ve b2 y olmalıdır. 91

110 Rol Tabanlı Sorgu Tanımları Bu bölümde rol tabanlı sorgu tanımları örneklenecektir. Bölüm de değişik bir çok çalışmada da (Compuware and Sun, 2003) (Kalnins et al., 2005) (Kleppe et al., 2003) (QVT-Merge Group, 2004) (Willink, 2003) kullanılan UML-RDBMS dönüşümü için rol tabanlı sorgular tanımlanırken Bölüm de ise çoklu kalıtım-tekli kalıtım dönüşümü için rol tabanlı sorgular tanımlanacaktır UML-RDBMS Dönüşümü için Rol Tabanlı Sorgu Tanımı UML modellerinin veritabanı modellerine olan dönüşümü, bir çok model dönüşüm dili tanımında kullanılmıştır (Compuware and Sun, 2003) (Kalnins et al., 2005) (Kleppe et al., 2003) (QVT-Merge Group, 2004) (Willink, 2003). Bu nedenle, rol tabanlı sorgu geliştirilmesinin örneklenmesi için, UML kaynak modellerinin veritabanı modellerine dönüşümü incelenecektir. UML modellerinin veritabanı modellerine dönüştürülmesinin ilk aşamasında kaynak modelde tipi kalıcı olan UML sınıfları, aynı isimde veritabanı hedef modelinde tablo üst sınıfından örneklenen tablolara dönüştürülmektedir. Bu dönüşüm için geliştirilen sorguda sahası olmayan herhangi bir tablo olamayacağı için, en az bir özelliğe sahip üst sınıf özelliği kalıcı olan sınıflar sorgulanmalıdır. Şekil 5.20 deki sorgu, tipi kalıcı olan UML sınıflarını ve bu sınıflara ait özellikleri tablo ve o tablonun sahalarına dönüştüren bir dönüşüm için UML sınıflarının ve o sınıflara ait özelliklerin sorgulanmasını örneklemektedir. Şekil 5.20 UML RDBMS Sorgu Deseni - I

111 Kaynak model içerisinde tanımlı ilişkiler (Associations), veritabanı üst modelinde ilgili tablo içerisinde bir anahtar sahaya (foreign key) karşılık gelmektedir. İlişkilerin 1-1 ve m-n ilişki olması durumuna göre hedef model içerisinde kurulan yapılar farklılık göstermektedir. Buna göre 1-1 olarak tanımlanan ilişkiler için her bir ilişki, ilişkinin bağlandığı UML sınıflarına karşılık gelen veritabanı tabloları için bir tablodan diğerine anahtar saha oluşturmaktadır. Şekil 5.21 de Ptr2 ismiyle gösterilen desen tanımı, 1-1 bir ilişkiyi, bu ilişkiyi UML sınıflarına bağlayan AssociationEnd üst sınıflarını ve ilişkinin bağladığı UML sınıflarını sorgulamaktadır. 93 Şekil 5.21 UML RDBMS Sorgu Deseni - II m-n olarak tanımlanmış ilişkilerde ise her bir m-n ilişkiye karşılık veritabanı modelinde anahtar sahaları tutan ayrı bir tablo yaratılmaktadır. m-n ilişkiler için yazılan bir desen tanımı; upper üst sınıf özelliği bire eşit olmayan Association üst sınıflarını, UML sınıflarını bu ilişkiye bağlayan AssociationEnd üst sınıflarını ve UML sınıflarını sorgulamalıdır. Bu desen tanımını içeren bir dönüşüm, her bir ilişki için bir tablo yaratırken bu ilişkiyi bağlayan AssociationEnd üst sınıfları için de tablo içerisinde anahtar sahaları oluşturmalıdır. Şekil 5.22 de verilen

112 94 Ptr3 isimli desen tanımı, UML modeli içerisindeki m-n ilişkileri sorgulamaktadır. Şekil 5.22 UML RDBMS Sorgu Deseni - III Çoklu Kalıtım Tekli Kalıtım Dönüşümü için Rol Tabanlı Sorgu Tanımları Bazı programlama dilleri sadece tekli kalıtım gerçekleştirilmesini desteklerler. Java da çoklu kalıtım, dilin bir başka yapısı olan arayüzler kullanılarak desteklenir. Bir yazılım sisteminin modellenmesinde bir sınıfın birden fazla sınıftan türetilmesi gerektiği durumlar tanımlanabilir. Bu nedenle çoklu kalıtım içeren yazılım modellerinin tekli kalıtıma izin veren platformlara dönüştürülmesi gerekebilir. Çoklu kalıtım içeren modellerin sorgulanmasında tek seviyeli çoklu kalıtım ve iki seviyeli çoklu kalıtım olmak üzere iki farklı çoklu kalıtım yapısı göz önünde bulundurulabilir. Şekil 5.23 de çoklu kalıtım için bu iki farklı yapı gösterilmektedir. Sebesta (Sebesta, 2002), Şekil 5.23(b) de verilen iki seviyeli çoklu kalıtımı diamond inheritance olarak tanımlamaktadır.

113 95 Şekil 5.23 Çoklu Kalıtım Tipleri Şekil 5.24, tek seviyeli çoklu kalıtım içeren yapıların sorgulanması için rol tabanlı yaklaşım kullanılarak geliştirilmiş sorguyu içermektedir. TekSeviyeKalıtım isimli <<Dönüşüm Rolü>>, bir dönüşüm rolü olmasına rağmen üst seviye kısıtı (self.sorgu=true) şeklinde tanımlanarak bu rolün dönüşüm içerisinde bir sorgu tanımı olduğunu belirtilmektedir. Sorgu içerisinde ChildClass ve ParentClass olmak üzere iki ana rol tanımlıdır. ChildClass rolü çoklu kalıtım içerisinde alt sınıfı temsil eder. ParentClass rolü ise, alt sınıfın türetildiği iki ya da daha fazla sayıdaki üst sınıfı temsil etmektedir. GenPC ismindeki <<GeneralizeElement Rolü>>, alt sınıf ile üst sınıflar arasındaki kalıtım ilişkisini tanımlayan GeneralizeElement üst sınıf örnekleri tarafından oynanan bir roldür. Dönüşümde üst sınıfa ait özellik ve metotlar da ilgili model elemanlarına dönüştürüleceği için sorgu içerisinde üst sınıfa ait özellikler ve metotlar da sorgulanmaktadır.

114 96 Şekil 5.24 Tek Seviyeli Çoklu Kalıtım İçin Sorgu Tanımı İki seviyeli çoklu kalıtım içeren yapıların sorgulanmasında tek seviyeli çoklu kalıtım sorgusuna ek olarak bir seviye kalıtım ilişkisi daha sorgulanmaktadır. Şekil 5.25, iki seviyeli çoklu kalıtım desen tanımını göstermektedir. Şekil 5.25 İki Seviyeli Çoklu Kalıtım İçin Sorgu Tanımı

115 Sorgu tanımı içerisine ikinci kalıtım seviyesini ekleyebilmek için GrandParentClass isimli bir <<Class Rolü>> eklenmiştir. Bu rol, ParentClass rolünü oynayan üst sınıfların türediği bir üst sınıf tarafından oynanan roldür. Şekil 5.20, Şekil 5.21 ve Şekil 5.22 deki sorgu tanımlarının aksine Şekil 5.24 ve Şekil 5.25 de verilen sorgu tanımları, (Goknil and Topaloglu, 2006) da incelendiği şekilde karmaşık sorgulardır. Bu sorguların karmaşıklığının nedeni, sorgunun içerisindeki hiyerarşilerin ve sorgu elemanları arasındaki ilişkilerin üst model içerisinde tanımlı olmayıp problem alanında tanımlı olmasıdır. Bölüm 5.71 de sorgu tanımları verilen UML-RDBMS dönüşümü, sorgu içerisindeki hiyerarşiler üst modelde yer aldığı için kaynak ve hedef üst modellerin eşlenmesi sayesinde tanımlanabilen bir dönüşümdür. Bu tip bir dönüşümde kaynak üst modelde yer alan her bir model elemanı hedef üst model içerisinde yer alan bir ya da daha fazla model elemanıyla eşlenmektedir. Örneğin UML üst modelindeki her bir Class üst sınıfı RDBMS üst modelindeki her bir Table üst sınıfına karşılık gelirken yine her bir Attribute üst sınıfı hedef üst modeldeki Field üst sınıfına karşılık gelmektedir. Üst modellerin eşlenmesiyle tanımlanan dönüşümlerdeki her bir kuralın sorgu kısmında bütün bir yapıyı sorgulamak yerine sadece o kuralın eşlediği üst model elemanı sorgulaması yeterli olacaktır. Ancak çoklu kalıtım-tekli kalıtım dönüşümünde kaynak model içerisinde sorgulanacak model elemanları ve bu model elemanları arasındaki ilişkiler kaynak üst model içerisinde yer almayıp tamamen problem alanı içerisinde tanımlı olduğu için kaynak ve hedef üst modelin eşlenmesiyle dönüşüm tanımlarını oluşturmak mümkün olmamaktadır. Bu nedenle bir kaynak model elemanını eşleyen kurallara sahip dönüşüm dillerinde bu tip dönüşümler için tek başına bir kural bütün yapıyı sorgulayıp dönüştüremeyeceği için kurallar içerisindeki sorguların birbiriyle bağlanması gerekmektedir (Goknil and Topaloglu, 2006). Bu bağlantılar da dönüşüm içerisinde çok sayıda yardımcı kuralın tanımlanmasını gerektirmektedir. Bu kurallar, dönüşüm tanımlarını karmaşıklaştırmaktadır. Şekil 5.24 ve Şekil 5.25 deki gibi problemi tek bir kerede sorgulayabilecek bu sorgu tanımlarını kullanacak model dönüşüm dili ise, yardımcı kurallar olmaksızın tek bir kural içerisinde dönüşümü 97

116 98 gerçekleştirebilecektir. Bu şekilde her bir kural bir problem tanımına odaklanacağı için dönüşüm içerisindeki kural sayısı ve dönüşüm tanımlarının karmaşıklığı azalacaktır. Böyle bir model dönüşüm dilinde üst modellerin eşlenmesi üzerine kurulan dönüşümlerin yanı sıra problem alanında tanımlı kaynak desenlerin hedef desenlere eşlenmesi üzerine kurulan dönüşümler de aynı sadelikte tanımlanabilecektir. Rol tabanlı sorgu tanımlarındaki kısıtların yerel olması, bir sorguyu oluşturan parçaların diğer sorgu tanımları içerisinde de kullanılmasına izin verecektir. Şekil 5.25 deki iki seviyeli çoklu kalıtım sorgu tanımını oluşturan sorgu elemanlarından bazıları Şekil 5.24 deki tek seviyeli çoklu kalıtım sorgu tanımını oluşturmaktadır. Kısıtlar yerel olup her bir sorgu elemanına ayrı ayrı yazıldığı için sorgu tanımındaki her bir eleman başka bir sorgu içerisinde kullanılabilecektir. Örneğin Şekil 5.25 de birden fazla ParentClass ın bir GrandParentClass ile ilişkili olması kısıtı OCL kısıt dili ile yazılmayıp bu kısıt roller arasında bir ilişki ile gösterildiği için ParentClass, Şekil.5.24 deki sorgu tanımında üzerindeki aynı üst seviye kısıtları ile kullanılabilmektedir. Eğer yerel olmayan bu kısıt diğer bir çok model dönüşüm dilinde olduğu gibi diğer yerel kısıtlarla birlikte tek bir başlık altında yazılırsa ParentClass elemanını tek seviyeli çoklu kalıtım sorgu tanımında yeniden kullanabilmek için bu kısıtları ayrıştırmamız ve GrandParentClass elemanı ile ilgili olan kısıtlardan ayırarak kullanmamız gerekecektir.

117 6 SONUÇ Model Tabanlı Mühendislik, yazılım geliştirmede soyutlama düzeyinin yükseltilmesi ve farklı soyutlama düzeylerindeki modeller arasında otomatik model dönüşümlerini destekleyen araçlar geliştirilmesi fikrine dayanmaktadır. Model Tabanlı Mühendislik kapsamında model dönüşümlerinin tanımlanması ve işletilmesi için uygulanabilirliği en yüksek olan yaklaşım, model dönüşüm dillerinin kullanılmasıdır. Model dönüşüm dillerinin kaynak, hedef desen tanımları ile dönüşüm kurallarının her üçünü birden tek bir çatı içerisinde tanımlayabilmesi ve mantıksal işlemleri desteklemesi, diğer yaklaşımlara göre üstünlüklerini oluşturmaktadır. Literatürde model dönüşüm dilleri için tanımlanan istekler karşısında bir çok dil önerilmiş ve gerçekleştirilmiştir. Bu diller arasında tez içerisinde incelenen tanımlayıcı ve prosedürel özelliklerini kullanarak desen tabanlı model dönüşüm yaklaşımını gerçekleştiren ATL, çizge dönüşümlerini temel alan grafik gösterime sahip bir model dönüşüm dili olan MOLA, OMG nin MOF QVT adı altında tanımlamış olduğu model dönüşüm dili istekleri doğrultusunda tasarlanmış TEFKAT, Model Bağlantılı Programlama yaklaşımı içerisinde geliştirilmiş çizge tabanlı görsel bir dil olan GREAT ile tanımlayıcı ve imperative özellikleri bir arada barındıran YATL dilleri, model dönüşüm uygulamalarında sıklıkla kullanılan ve üzerinde araştırma yapılan dillerdir. Bu model dönüşüm dillerinin sınıflandırılması ve model dönüşüm dili kriterleri üzerine yapılan çalışmalar içerisinde Gronmo (Gronmo et al., 2005) ve Kurtev (Kurtev, 2005) tarafından ortaya konulan model dönüşüm dili istekleri, model dönüşüm dillerinin değişik amaçlı dönüşümleri tanımlayabilmesi için sahip olması gereken özellikleri tanımlamaktadır. Gronmo (Gronmo et al., 2005), MODELWARE projesi kapsamında geliştirilen model dönüşüm dilleri için genel kapsamlı gereksinimler tanımlarken Kurtev (Kurtev, 2005), çalışmasında dönüşüm parçalama ve birleşimi için bir model dönüşüm dilinin sağlaması gereken istekleri tanımlamıştır. Bu tez çalışmasında literatürdeki çalışmalar incelenerek model dönüşüm dillerinin sağlaması gereken genel amaçlı isteklerin tanımlanması, bu istekler doğrultusunda önde gelen model

118 100 dönüşüm dillerinin değerlendirilmesi ve rol tabanlı bir sorgu dilinin tasarlanması amaçlanmıştır. Tez içerisinde tanımlanan model dönüşüm dili istekleri Gronmo tarafından tanımlanan istekler ile benzerlik gösterse de Gronmo dan farklı olarak istekler arasındaki ilişkiler tanımlanmıştır. Tez içerisinde bu istekler, zorunlu istekler ve zorunlu olmayan istekler şeklinde sınıflandırılmış olmasına rağmen dil içerisinde başka bir isteğin sağlanabilmesi için daha önce zorunlu olmayan bir isteğin dil tarafından desteklenmesi zorunlu olabilir. Bu yapılan çalışmanın sonucunda incelenen model dönüşüm dillerinin özellikleri ve tanımlanan kriterlerin bu diller tarafından ne ölçüde desteklendiği araştırılmıştır. Bu araştırmadan yola çıkarak incelenen dillerden daha açıklayıcı ve tanımlayıcı bir dil olması planlanan rol tabanlı model dönüşüm dilinin ilk parçası olan rol tabanlı sorgu dili tasarlanmıştır. Rol tabanlı sorgu dili ile üzerinde çalıştığımız yaklaşımın modelleri sorgulamak için tanımladığı tasarım anlatılmaktadır. Bir model dönüşüm dilinin tanımlanmasında ve gösterilmesinde rol kavramından yararlanılabilir. Burada rol, model içerisinde yer alan ve aynı özellikleri taşıyan sınıfların model içerisindeki yapısal ve davranışsal özelliklerini tanımlamaktadır. Rol tabanlı sorgu diliyle önerilen, dil içerisinde tanımlı bütün yapıların roller ile ifade edilmesidir. Bütün yapıların roller ile ifade edilmesi; model sorguları için kısıtların yerelliği, üst seviyede daha açıklayıcı kısıtların yazılması, yazılan sorguların bir kısmının başka sorgular içerisinde de yeniden kullanılması gibi özellikleri sağlamaktadır. Dil içerisindeki yapıların roller ile ifade edilebilmesi için tanımlanacak rollerden bazıları dil üst modeli elemanları tarafından oynanırken bazı roller de kaynak ve hedef üst model elemanları tarafından oynanmaktadır. Örneğin, kaynak ve hedef desenler içerisinde yer alan model elemanları rol üst sınıfından türeyen örnekler tarafından ifade edilirken dil içerisinde yer alan dönüşüm kuralları, alt program çağrımları, kontrol yapıları ise aynı zamanda kendini tanımlayan rol elemanları için üst sınıfı oluşturmaktadır. Rol tabanlı sorgu dilinde rollerin ve dönüşümlerin ifade edilmesinde gösterim olarak Role-Based Modeling Language (RBML) (Kim et al., 2002) dilinden yararlanılmıştır. Bu gösterim, rolü oynayan sınıfların sayılarını belirtmemize ve bu sınıflara ait kısıtlamaları üst (meta) seviyede OCL kullanarak göstermemize olanak sağlamaktadır. Bu

119 101 yaklaşım, model dönüşümlerini görsel olarak ifade etmekte ve OCL gibi metin tabanlı kısıt dilini, bu görselliğin içerisine katarak sorguların daha yapısal olarak ifade edilmesini desteklemektedir. Bu tez çalışması ile model dönüşüm dillerinin özellikleri ve sağlaması gereken istekler tanımlanırken, tasarımı yapılan model sorgu dilinin ilerde yapılacak diğer model dönüşüm dili çalışmaları için bir çıkış noktası olacağı düşünülmektedir. Tasarlanan ve önerilen rol tabanlı sorgu dili, (Goknil and Topaloglu, 2006) da belirtilen karmaşık sorgu tanımlarını işleyecek bir model dönüşüm dilinin ilk adımı olarak kabul edilebilir. Kaynak ve hedef üst model elemanlarını bire-bir eşleyen kurallar yerine bir kaynak deseni hedef desene eşleyebilen bir model dönüşüm dilinde kural içerisindeki sorgu kısmı kaynak deseni bütün hiyerarşisi ve elemanlarıyla sorgulayabilmelidir. Böylece dönüşüm kuralı içerisinde tanımlanacak dönüşüm operasyonları ile sorgudan dönecek model elemanları hedef model elemanlarına dönüştürülebilecektir. Önerilen sorgu dili, bu tip dönüşümleri gerçekleştirmek için değişken sayılı desen tanımını destekleyecek olması, sorgu elemanları için yazılacak kısıtların yerelliği gibi özellikleriyle ileride tanımlanacak model dönüşüm dilinin sorgu dili alt yapısını oluşturacağı düşünülmektedir. Bir kısmını rol tabanlı sorgu dilinin oluşturacağı bir model dönüşüm dili, içerisindeki tüm yapıların roller ile ifade edildiği ve aynı veya farklı seviyelerde dönüşümlerin gerçekleştirilebildiği bir dil olacaktır. Böyle bir dilin diğer dillerden temel farkı, görsel gösterim ile metinsel kısıt dilini birleştirebilmesi, dönüşüm operasyonlarının birleşimini destekleyerek karmaşık dönüşüm tanımlarını yapılabilmesi ve model iyileştirmesi gibi (model refactoring) farklı yöntemler kullanan dönüşüm işlemlerini karşılayabilecek yapıda olması olacaktır.

120 102 KAYNAKLAR DİZİNİ Agrawal, A., Karsai, G., Shi, F., 2003, A UML-based Graph Transformation Approach for Implementing Domain-Specific Model Transformations, International Journal on Software and Systems Modeling Agrawal, A., Vizhanyo, A., Kalmar, Z., Shi, F., Narayanan, A., Karsai, G., 2004, Reusable Idioms and Patterns in Graph Transformation Languages, OOPSLA Workshop on Best Practices for Model Driven Software Development, Vancouver, Canada Agrawal, A., 2004, A Formal Graph Transformation Based Language for Model-To-Model Transformations, PhD Thesis, Vanderbilt University, 208p Akehurst, D., Kent, S., 2002, A Relational Approach to Defining Transformations in a Metamodel, 5 th Internation Conference on the Unified Modeling Language (UML 2002), Dresden, Germany. Atkinson, C., Kuhne, T., 2002, The Role of Metamodeling in MDA, In Proceedings of the 1 st UML Workshop in Software Model Engineering (WISME 2002), Dresden, Germany Bachman, C.W., Daya, M., 1977, The Role Concept in Data Models, In International Concept on Very Large Databases, pp Backlawski, K., Mieczyslaw, K., Kogut, P., Hart, L., Smith, J., Letkowski, J., Emery, P., 2002, Extending the Unified Modeling Language for Ontology Development, International Journal on Software and Systems Modeling, Vol.1, No.2, Bardohl, R., Ermel, C., Weinhold, I., 2003, GenGED A visual definition tool for visual definition environments, Proc. Application of Graph Transformations with Industrial Relevance (AGTIVE 03), Virginia, USA

121 103 KAYNAKLAR DİZİNİ (devam) Baresi, L., Heckel, R., 2002, Tutorial Introduction to Graph Transformation: A Software Engineering Perspective, In Proceedings of the First International Conference on Graph Transformation (ICGT 2002), Barcelona, Spain. Bezivin, J., Kurtev, I., 2005, Model-based Technology Integration with the Technical Space Concept, Metainformatics Symposium 2005, Esbjerg, Denmark. Bezivin, J., 2005, Model Driven Engineering: Principles, scope, deployment, and applicability, Technical Report TR for the Summer School on Generative and Transformational Techniques in Software Engineering (GTTSE 05), Braga, Portugal Bezivin, J., Devedzic, V., Djuric, D., Favreau, J.M., Gasevic, D., Jouault, F., 2005, Am M3-Neutral Infrastructure for Bridging Model Engineering and Ontology Engineering, INTEROP- ESA Bezivin, J., Dupe, G., Jouault, F., Pitette, G., Rougui, J. E., 2003, First Experiments with the ATL Model Transformation Language: Transforming XSLT into XQuery, 2 nd OOPSLA Workshop on Generative Techniques in the context of MDA, Anaheim California USA Bezivin, J., 2001, From Object Composition to Model Transformation with the MDA, Proceedings of TOOLS USA, Vol. IEEE TOOLS- 39. Booch, G., Brown, A., Iyengar, S., Rumbaugh, J., Selic, B., 2004, The IBM MDA Manifesto, The MDA Journal,

122 104 KAYNAKLAR DİZİNİ (devam) Celms, E., Kalnins, A., Lace, L., 2003, Diagram Definition Facilities based on Metamodel Mappings, OOPSLA Workshop on Domain- Specific Modeling, Anaheim California USA. Compuware, SUN, 2003, MOF 2.0 Query/Views/Transformations RFP Revised Submission, OMG Document ad/ , Csertan, G., Huszerl, G., Majzik, I., Pap, Z., Pataricza, A., Varro, D., 2002, VIATRA visual automated transformations for formal verification and validation of UML models, In Proc. 17 th International Conference Automated Software Engineering, pages , IEEE Computer Society. Czarnecki, K., Helsen, S., 2003, Classification of Model Transformation Approaches, 2 nd OOPSLA Workshop on Generative Techniques in the context of MDA, Anaheim California USA. Dao, M., Huchard, M., Libourel, T., Pons, A., Villerd, J., 2004, Proposals for Multiple to Single Inheritance Transformation, In Proceedings of the 3 rd International Workshop on Mechanisms for Specialization, Generalization and Inheritance MASPEGHI Dean, M., Schreiber, G., 2004, OWL Web Ontology Reference W3C Recommendation, Demirezen, Z., 2004, Tasarım Desenlerinin Uygulanması ve Araç Geliştirilmesi, Yüksek Lisans Tezi, Ege Üniversitesi Fen Bilimleri Enstitüsü DSTC, IBM, CBOP, 2003, MOF Query/Views/Transformation initial submission.

123 105 KAYNAKLAR DİZİNİ (devam) Duddy, K., Gerber, A., Lawley, M., Raymond, K., Steel, J., 2003, Model Transformation: A declarative, reusable patterns approach, 7 th International Enterprise Distributed Object Computing Conference 2003, Brisbane, Australia. EMF, 2002, Eclipse Modeling Framework, Ermel, C., Schultzke, T., 1999, The AGG Environment: A Short Manual, TU Berlin. Fabro, M., Jouault, F., 2005, Model Transformation and Weaving in the AMMA Platform, Technical Report TR-CCTC/DI-36 for the Summer School on Generative and Transformational Techniques in Software Engineering (GTTSE 05), Braga, Portugal Falkovych, K., Sabou, M., Stuckenschmidth, H., 2003, UML for the Semantic web: Transformation-Based Approaches, In Knowledge Transformation in Semantic Web, IOS Press, Vol. 95, France, R., Bieman, J., 2001, Multi-view Software Evolution: A UMLbased Framework for Evolving Object-Oriented Software, In Proceedings International Conference on Software Maintenance (ICSM 2001), Florence, Italy. France, R., Kim, D., Song, E., Ghosh, S., 2003a, Using Roles to Characterize Model Families, Practical Foundations of Business and System Specifications, Kluwer Academic Publisher, France, R., Ghosh, S., Song, E., Kim, D., 2003b, A Metamodeling Approach to Pattern based Model Refactoring, IEEE Software, Special Issue on Model Driven Development, Vol.20, No.5, pp

124 106 KAYNAKLAR DİZİNİ (devam) France, R., Kim, D., Ghosh, S., Song, E., 2004, A UML-Based Pattern Specification Technique, IEEE Transactions on Software Engineering, Vol.30, No.3, pp Gasevic, D., Djuric, D., Devedzic, V., Damjanovic, V., 2004, Approaching OWL to MDA through Technological Spaces, In Proceedings of the 3 rd UML Workshop in Software Model Engineering (WISME 2004), Lisbon, Portugal Gerber, A., Lawley, M., Raymond, K., Steel, J., Wood, A., 2002, Transformation: The Missing Link of MDA, 1 st International Conference on Graph Transformations (ICGT 2002), Barcelona, Spain. Goknil, A., Topaloglu, N.Y., 2005a, Ontology Based Model Transformation Infrastructure, Proceedings of the Joint Workshop on Web Services and Model-Driven Enterprise Information Services (WSMEDEIS 05) in conjunction with ICEIS 2005, Miami, USA. Goknil, A., Topaloglu, N.Y., 2005b, Ontological Perspective in Metamodeling for Model Transformations, Metainformatics Symposium 2005, Esbjerg, Denmark. Goknil, A., Topaloglu, N.Y., 2006, Composing Transformation Operations Based on Complex Pattern Definitions, European Workshop on Composition of Model Transformations in Conjuction with ECMDA-FA 2006, Bilbao, Spain. Greenfield, J., Short, K., Cook, S., Kent, S., 2004, Software Factories, Wiley Publishing

125 107 KAYNAKLAR DİZİNİ (devam) Gronmo, R., Belaunde, M., Aagedal, J.O., Engel, K., Faugere, M., Solheim, I., 2005, Evaluation of the Proposed QVTMerge Language for Model Transformations, In the Proceedings of the Joint Workshop on Web Services and Model-Driven Enterprise Information Systems Workshop (WSMDEIS 2005) in conjunction with ICEIS 2005, Miami, USA. Jouault, F., Kurtev, I., 2005, Transforming Models with ATL, In Proceedings of the Model Transformation in Practice Workshop, part of the MoDELS 2005 Conference, October 3 rd 2005 Judson, S., France, R., Carver, D., 2003, Specifying Model Transformations at the Metamodel Level, In Proceedings of the 2 nd UML Workshop in Software Model Engineering (WISME 2003), San Francisco, USA Kalnins, A., Barzdins, J., Celms, E., 2004a, MOLA Language: Methodology Sketch, EWMDA 2004, Canterbury, England Kalnins, A., Barzdins, J., Celms, E., 2004b, Model Transformation Language MOLA, Lecture Notes in Computer Science, Springer, Volume 3599/2005, MDAFA 2004, Sweden Kalnins, A., Celms, E., Sostaks, A., 2005, Model Transformation Approach Based on MOLA, In Proceedings of the Model Transformation in Practice Workshop, part of the MoDELS 2005 Conference, October 3 rd 2005 Kim, D., France, R., Ghosh, S., Song, E., 2002, Using Role-Based Modeling Language (RBML) as Precise Characterizations of Model Families, the 8 th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS)

126 108 KAYNAKLAR DİZİNİ (devam) Kim, D., France, R., Ghosh, S., Song, E., 2003, A Role-Based Metamodeling Approach to Specify Design Patterns, Proceedings of the 27 th IEEE Annual International Computer Software and Applications Conference (COMPSAC), Dallas, Texas. Kim, D., France, R., Ghosh, S., 2004, A UML-Based Language for Specifying Domain-Specific Patterns, Journal of Visual Languages and Computing, Special Issue Domain Modeling with Visual Languages, Vol.15, No.3-4. Kleppe, A., Warmer, J., Bast, W., 2003, MDA Explained. The model driven architecture: practice and promise, Addison-Wesley. KMF, 2002, Kent Modeling Framework, Kurtev, I, Berg, K., Jouault, F., 2006, Evaluation of Rule-based Modularization in Model Transformation Languages illustrated with ATL, Track on Model Transformations in the 21 st Annual ACM Symposium on Applied Computing, Dijon, France. Kurtev, I., 2005, Adaptability of Model Transformations, PhD Thesis, University of Twente, 240p, ISBN X Kurtev, I., Bezivin, J., Aksit, M., 2002, Technical Spaces: An initial appraisal, In: CoopIS, DOA 2002 Federated Conferences, Industrial Track. Lawley, M., Steel, J., 2005, Practical Declarative Model Transformation with TEFKAT, In the Proceedings of the Workshop on Model Transformations in Practice, Montego Bay, Jamaica

127 109 KAYNAKLAR DİZİNİ (devam) Mens, T., 2005, On the Use of Graph Transformations for Model Refactoring, Technical Report TR for the Summer School on Generative and Transformational Techniques in Software Engineering (GTTSE 05), Braga, Portugal OMG, 1997, Object Management Group Meta Object Facility (MOF) Specification, OMG, 2002, Object Management Group MOF 2.0 Query / Views / Transformations RFP, OMG, 2003a, Object Management Group MDA Guide Version 1.0.1, OMG, 2003b, Unified Modeling Language Specification. Version v1.5, Available from OMG, 2003c, XML Metadata Interchange Specification v2.0. OMG Document Available from OMG, 2004, Ontology Definition Metamodel, Available from Pahl, C., 2005, Ontology Transformation and Reasoning for Model- Driven Architecture, European Conference on Model Driven Architecture, Nuremberg, Germany. Patrascoiu, O., 2004a, YATL: Yet Another Transformation Language, In Proc. of First European Workshop MDA-IA, University of Twente, the Nederlands. Patrascoiu, O., 2004b, Mapping EDOC to Web Services using YATL, 8 th International Enterprise Distributed Object Computing Conference (EDOC 2004), California, USA

128 110 KAYNAKLAR DİZİNİ (devam) Roser, S., Bauer, B., 2005, Ontology Based Model Transformation, Doctoral Symposium in the MoDELS Conference, Jamaica. Rumpe, B., 1998, A Note on Semantics (with an Emphasis on UML), Second ECOOP Workshop on Precise Behavioral Semantics, Brussels, Belgium Schürr, A., 1994, PROGRES a visual language and environment for PROgramming with Graph Rewriting Systems, University of Aachen, Technical Report AIB Sebesta, R., 2002, Concepts of Programming Languages, Addison- Wesley Publishing Seidewitz, E., 2003, What models mean?, IEEE Software, Vol. 20, Sendall, S., Kozaczynski, W., 2003, Model Transformation-the Heart and Soul of Model-Driven Software Development, IEEE Computer Society Press Sztipanovitz, J., Karsai, G., 1997, Model-Integrated Computing, Computer, Apr. 1997, pp QVT-Merge_Group, 2004, Revised Submission for MOF 2.0 Query/ Views/Transformations RFP (ad/ ), Topaloglu, N.Y, Goknil, A., 2004, Model Tabanlı Yazılım Geliştirme, COMPOTEK 2004, İzmir Viehstaedth, G., Minas, M., 1995, Generating Editors for Direct Manipulation of Diagrams, 5 th International Conference on Human Computer-Interaction, Mascow, Russia

129 111 KAYNAKLAR DİZİNİ (devam) Wagner, A., 2002, A Pragmatical Approach to rule-based Transformations within UML using XMI Difference, Workshop on Integration and Transformation of UML Models, Malaga, Spain. Warmer, J., Kleppe, A., 2003, The Object Constraint Language: Getting Your Models Ready for MDA, The Addison-Wesley Willink, E.D., 2003, A Concrete UML-based graphical transformation syntax The UML to RDBMS example in UMLX, Workshop on Metamodeling for MDA, University of York, England Xu, P., (last modified ), Methods of Inference, Institute of Technology and Engineering, Massey University,

130 112 ÖZGEÇMİŞ Adı Soyadı : Arda Göknil Doğum Tarihi : 24/12/1980 Doğum Yeri : Bornova-İzmir Kariyer : Ege Üniversitesi - İzmir, Araştırma Görevlisi EĞİTİM : Ege Üniversitesi, Bilgisayar Mühendisliği Lisans : Türkbirliği Lisesi, Salihli-Manisa Yabancı Dil : İngilizce

131 1