Etki alanına özgü çok modelleme - Domain-specific multimodeling

Etki alanına özgü çok modelleme^[1] her bir görünümün ayrı olarak açık hale getirildiği bir yazılım geliştirme paradigmasıdır. alana özgü dil (DSL).

Modern bir kurumsal sistemin başarılı bir şekilde geliştirilmesi, çoklu görünümlerin yakınsamasını gerektirir. İş analistleri, etki alanı uzmanları, etkileşim tasarımcıları, veritabanı uzmanları ve farklı uzmanlık türlerine sahip geliştiriciler, hepsi böyle bir sistemi oluşturma sürecinde yer alır. Çalışan bir sistem oluşturmak için farklı çalışma ürünleri yönetilmeli, hizalanmalı ve entegre edilmelidir. Geliştirme sürecinin her katılımcısının, sistem hakkındaki görüşüne özgü sorunları çözmek için özel olarak tasarlanmış belirli bir dili vardır. Bu farklı görüşleri entegre etmenin ve birden çok farklı dilin olası kakofonisinden kaçınmanın zorluğu, koordinasyon sorunu.

Etki alanına özgü çok modelleme^[1] tek dilli programlama gibi daha geleneksel geliştirme paradigmalarına kıyasla umut vericidir ve genel amaçlı modelleme. Bu yeni paradigmanın faydalarından yararlanmak için koordinasyon problemini çözmeliyiz. Bu sorun, bağlamında parçalanma sorunu olarak da bilinir. Global Model Yönetimi.

Bu sorunu çözmek için bir öneri koordinasyon yöntemi.^[1] Bu, farklı görüşleri entegre etmenin ve birden çok dili koordine etmenin önündeki engelleri aşmak için üç aşamalı bir yöntemdir. Yöntem, referansların (1) nasıl tanımlanacağını ve (2) dil sınırları boyunca nasıl belirtileceğini, yani örtüşmeler farklı diller arasında. Son olarak, yöntem (3) bu bilginin tutarlılık, gezinme ve rehberlik şeklinde gerçek gelişimde nasıl uygulanacağına dair somut öneriler sunar.

Motive edici örnek

Girişimcilik sistemleri çoklu temelli alana özgü diller bol miktarda bulunur. Metamodeli tanımlanmış diller Genişletilebilir İşaretleme Dili (XML) özellikle yaygın bir şekilde benimsenmekten hoşlanır. Gelişimi birden çok dilde göstermek için, bir vaka çalışmasından bir örnek alacağız: Apache İş İçin Açık (OFBiz) sistemi. Kısaca belirtmek gerekirse, OFBiz bir kurumsal kaynak planlaması envanter, muhasebe gibi standart bileşenleri içeren sistem, e-ticaret vb. Bu bileşenler, XML tabanlı diller ve normal Java kodunun bir karışımı ile uygulanır. Örnek olarak, şuna odaklanalım: içerik yönetimi bileşeni, özellikle yönetici kullanıcının aşağıdaki ekran görüntüsünde gösterildiği gibi çevrimiçi bir web anketi oluşturduğu bir kullanım durumu. Bu örneğe şu şekilde değineceğiz: anket oluştur misal.

Şekilde, çalışan bir içerik yönetimi uygulamasının yönetim arayüzünün bir ekran görüntüsü gösterilmektedir. OFBiz örnek. Bir anket oluşturmak için, kullanıcı giriş formunun alanlarını doldurur ve Güncelleme buton. Bu, düzenlenebilir ve daha sonra bir ön uç web sitesinde yayınlanabilen yeni bir anket oluşturur. OFBiz. Perde arkasında, bu kullanım senaryosu farklı dillerde yazılmış birkaç eseri içerir. Bu örnekte, bu dillerden yalnızca üçüne odaklanalım: Varlık, Hizmet ve Form DSL.

Bu üç dil kabaca yapısal, davranışsal ve Kullanıcı arayüzü endişe OFBiz. Varlık DSL, temel veri modelini ve dolayısıyla oluşturulan anketin kaydedilme şeklini tanımlamak için kullanılır. Hizmet DSL'si, kullanıcı web sitesine ulaştığında çağrılan hizmetin arayüzünü tanımlamak için kullanılır. Güncelleme buton. Son olarak, Form DSL, formun görsel görünümünü tanımlamak için kullanılır. Üç dil farklı şeyler için uyarlanmış olsa da, tamamen ayrılamazlar. Kullanıcı arayüzü, belirli bir uygulama mantığını çağırır ve bu uygulama mantığı, uygulamanın verilerini işler. Bu bir örnektir ortogonal olmayan endişeler. Diller örtüşüyor çünkü temsil ettikleri endişeler tamamen ayrılamıyor. Bu üç dili bir altüst üslup ve örtüşmelerine dikkat edin.

Varlık DSL

Varlık DSL, veri yapısını OFBiz. Aşağıdaki liste, anket kavramını temsil eden iş nesnesi olan Anket varlığının tanımını göstermektedir. Listedeki kod kendinden açıklamalıdır: Anket adı verilen bir varlık 10 alanla tanımlanır. Her alanın bir adı ve türü vardır. Saha anket kimliği, birincil anahtar. Bu tanım, merkezi bir bileşen tarafından OFBiz aradı varlık motoru. Varlık motoru, karşılık gelen bir İş objesi. Varlık motorunun amacı, tüm iş nesnelerinin işlem özelliklerini yönetmek ve aşağıdakiler gibi çeşitli kalıcılık mekanizmalarıyla etkileşim kurmaktır. Java Veritabanı Bağlantısı, Kurumsal JavaBeans hatta biraz eski sistemi.

   varlık-adı ="Anket" ... başlık ="Anket Varlığı">     isim ="surveyId" type ="id-ne"/>     isim ="surveyName" type ="isim"/>     isim ="açıklama" type ="açıklama"/>     isim ="yorumlar" type ="yorum Yap"/>     isim ="submitCaption" type ="kısa varchar"/>     isim ="responseService" type ="uzun varchar"/>     isim ="isAnonymous" type ="gösterge" .../>     isim ="allowMultiple" type ="gösterge" .../>     isim ="allowUpdate" type ="gösterge" .../>     isim ="acroFormContentId" type ="id-ne" .../>     alan ="surveyId"/>  </entity>

DSL servisi

Servis DSL, servislerin arayüzünü belirtir. OFBiz. Her hizmet, sistemin uygulama mantığının bir kısmını kapsüller. Bu dilin amacı, çeşitli uygulama mekanizmaları üzerinde tek tip bir soyutlamaya sahip olmaktır. Bireysel hizmetler Java'da uygulanabilir. komut dosyası dili veya kullanarak kural motoru. Aşağıdaki liste, createSurvey hizmetinin arayüzünü gösterir.

Adın yanı sıra, hizmet öğesi, bu hizmet için uygulamanın konumunu ve başlatma komutunu belirtir. Varsayılan-varlık-adı özniteliği, bu hizmetin önceki listede tanımlanan Anket varlığına başvurduğunu belirtir. Bu, iki dil arasında bir örtüşmedir, özellikle sözde yumuşak referans. Servis DSL'deki bir model, Varlık DSL'deki bir modeli ifade eder. Bu referans, aşağıdaki iki otomatik öznitelik öğesinde, yazılan öznitelikler biçiminde hizmetin girdisini ve çıktısını belirtir. Hizmet, girdi olarak Anket varlığının tüm birincil olmayan anahtar (nonpk) alanlarına karşılık gelen öznitelikleri kabul eder ve bu öznitelikler isteğe bağlıdır. Çıktı olarak hizmet, Survey'in birincil anahtar (pk) alanlarına karşılık gelen öznitelikleri, yani bu durumda surveyId alanını döndürür ve bu öznitelikler zorunludur. Dillerde referansın amacı bu durumda fazlalığı azaltmaktır. CreateSurvey hizmetinin öznitelikleri, Anket varlığının alanlarına karşılık gelir ve bu nedenle bunların yalnızca bir kez belirtilmesi gerekir.

   isim ="createSurvey" varsayılan-varlık-adı ="Anket" ...           konum ="org / ofbiz / content / survey / SurveyServices.xml"           invoke ="createSurvey"> ...     service-name ="contentManagerPermission"                        ana eylem ="OLUŞTURMAK"/>     include ="nonpk" mode ="İÇİNDE" isteğe bağlı ="doğru"/>     include ="pk" mode ="DIŞARI" isteğe bağlı ="yanlış"/>  </service>

Form DSL

Form DSL, kullanıcı arayüzündeki giriş formlarının düzenini ve görsel görünümünü tanımlamak için kullanılır. Dil, Form ve Alan gibi alan kavramlarından oluşur. Aşağıdaki liste, EditSurvey formunun uygulamasını göstermektedir. Bu sefer Form DSL, DSL Hizmeti ile çakışıyor. Formun hedef özelliği ve alt hedef öğeleri, bu formun gönderilmesinden gelen girdinin updateSurvey veya createSurvey hizmetlerine yönlendirilmesi gerektiğini belirtir. Otomatik alanlar hizmet öğesi, formun, updateSurvey hizmetinin özniteliklerinin her birine karşılık gelen bir alan içermesi gerektiğini belirtir (bu, createSurvey hizmetinin özniteliklerine benzer). Bu, benzer bir etki yaratır ithal önceki listede yer alan otomatik öznitelik öğelerinin durumunda olduğu gibi başka bir modelden tanımlar. Daha aşağıda, bunların görünümünü özelleştirmenin mümkün olduğunu görebiliriz. ithal isAnonymous gibi alanlar. Son olarak, kullanıcının verilerini referans verilen hizmete gönderebilmesi için yerelleştirilmiş bir başlığa sahip bir submitButton eklenir.

   isim ="Anketi Düzenle" type ="tek" hedef ="updateSurvey"        başlık ="" default-map-name ="anket">     use-when ="anket == null" hedef ="createSurvey"/>     service-name ="updateSurvey"/>     use-when ="anket! = boş" isim ="surveyId" ... />    ...     isim ="isAnonymous">       no-current-selected-key ="N" allow-empty ="yanlış">         anahtar ="Y"/>  anahtar ="N"/>      </drop-down>    </field>    ...     isim ="submitButton" başlık ="$ {uiLabelMap.CommonUpdate}"           widget-style ="smallSubmit">       düğme tipi ="buton"/>    </field>  </form>

anket oluştur Örnek, burada anlatıldığı gibi, üç farklı dilde modeller kullanılarak uygulanmaktadır. Tam uygulama aslında, formun yerleştirildiği ekranın düzenini belirlemek için bir Screen DSL ve hizmeti uygulamak için kullanılan bir veri işleme dili olan bir Minilang DSL gibi daha fazla dili içerir. Bununla birlikte, bu üç dil, her bir konuyu somut hale getirme ana fikrini göstermektedir. Örnek ayrıca, dillerin biraz üst üste binmesine izin vererek artıklığı azaltmanın basit bir yolunu da göstermektedir.

Çok seviyeli özelleştirme

Etki alanına özgü diller, yukarıda açıklananlar gibi, sınırlı bir ifadeye sahiptir. Java gibi genel amaçlı bir dilde kod parçacıkları eklemek, dillerin kapsamının ötesinde özel işlevler uygulamak için genellikle gereklidir. Bu yönteme çok seviyeli özelleştirme.^[2]Bu yöntem çok dilli kurulumlarda çok yaygın olarak kullanıldığından, bunu örneğin devamı ile açıklayacağız. Buna diyelim PDF oluştur misal.

Bir oluşturmak istediğimizi varsayalım PDF dosyası kullanıcıların oluşturduğu çevrimiçi anketlere verilen her anket yanıtı için. Bir PDF dosyası oluşturmak, dillerimizin kapsamı dışındadır, bu nedenle bu özel işlevi gerçekleştirmek için üçüncü taraf bir PDF kitaplığını çağırabilecek bazı Java kodu yazmamız gerekir. İki eser gereklidir:

İlk olarak, somut hizmetin arayüzünü modelleme düzeyinde erişilebilecek şekilde tanımlayan Servis DSL'de aşağıda gösterildiği gibi ek bir hizmet modeli. Hizmet modeli, uygulamanın konumunu ve girdi ve çıktı özniteliklerinin neler olduğunu açıklar.

   isim ="buildPdfFromSurveyResponse" motor ="java"    konum ="org.ofbiz.content.survey.PdfSurveyServices"    invoke ="buildPdfFromSurveyResponse">    <özellik isim ="surveyResponseId" mode ="İÇİNDE"      isteğe bağlı ="yanlış" .../>    <özellik isim ="outByteWrapper" mode ="DIŞARI"      isteğe bağlı ="yanlış" .../>  </service>

İkinci olarak, aşağıda gösterildiği gibi bu hizmetin gerçek uygulamasını içeren bir kod parçacığına ihtiyacımız var. Bir hizmet birden çok girdi ve çıktıya sahip olabilir, bu nedenle Java yöntemine girdi, bağımsız değişken adlarından bağımsız değişken değerlerine bağlam olarak adlandırılan bir eşlemedir ve sonuç olarak adlandırılan başka bir eşleme biçiminde çıktı verir.

  halka açık statik Harita buildPdfFromSurveyResponse  (DispatchContext dctx , Harita bağlam) {    Dize İD = (Dize) bağlam.almak("surveyResponseId");    Harita Sonuçlar = yeni HashMap();    Deneyin {      // ... yanıt veritabanından alınır ...      // ... yanıttan bir pdf oluşturulur ...      // ... pdf bytearray olarak serileştirildi ...    ByteWrapper outByteWrapper = ...;    Sonuçlar.koymak("outByteWrapper",outByteWrapper );    } tutmak (İstisna e) {}    dönüş Sonuçlar;  }

Bu çok seviyeli özelleştirme yöntemi, yumuşak referanslar benzer anket oluştur misal. Temel fark, buradaki referansın model ve model arasında değil, model ve kod arasında olmasıdır. Bu durumda avantaj, PDF'leri oluşturmak için üçüncü taraf bir Java kitaplığından yararlanılabilmesidir. Başka bir tipik uygulama, harici web hizmetlerini çağırmak ve sonuçları uygun bir formatta içe aktarmak için Java kod parçacıkları kullanmaktır.

Koordinasyon sorunu

Örnek, geliştirme aşamasında birden çok dil kullanmanın bazı avantajlarını göstermektedir. Bununla birlikte, bu tür bir gelişmeyle ilişkili zorluklar da vardır. Bu zorluklar, sürecimize ne kadar çok eser ekledikçe geliştirici çabaları arasında daha fazla koordinasyona ihtiyaç duyulduğunun gözleminden kaynaklanmaktadır. Bu zorluklara şu şekilde değineceğiz: Koordinasyon Problemi. Koordinasyon Probleminin kavramsal ve teknik bir yönü vardır. Kavramsal olarak temel sorun, farklı dilleri ve bunların etkileşimlerini anlamaktır. Modelleri birden çok dilde düzgün bir şekilde tasarlamak ve koordine etmek için, geliştiricilerin dillerin nasıl etkileşim kurduğuna dair yeterli bir anlayışa sahip olması gerekir. Teknik olarak asıl sorun tutarlılığı sağlamaktır. Tutarsızlıkları erkenden, yani modelleme zamanında tespit etmek ve geliştiricilere bu tutarsızlıkları çözmede yardımcı olmak için araçlar sağlanmalıdır. Aşağıda bu iki yönü daha ayrıntılı olarak inceleyeceğiz.

Kavramsal bir zorluk olarak koordinasyon

Geliştiricilerin birden çok dille geliştirmeye başlarken karşılaştığı ilk sorun, dil kakofoni. Farklı dilleri öğrenmek ve onların etkileşimini anlamak, eserlerin karmaşık bileşimini anlamlandırmak için gereklidir. OFBiz Örneğin framework on yedi farklı dile ve 200.000 satırdan fazla alana özgü dil koduna sahiptir, bu yüzden karmaşıklık oldukça zor olabilir! Şu anda, geliştiricilerin hızlı bir şekilde operasyonel bir anlayışa ulaşabilmeleri için farklı dilleri karakterize etmenin yerleşik bir yöntemi yoktur. Araçlar burada bir özel öğrenme ve keşfetme mekanizması çünkü geliştiriciler genellikle deneylerle öğrenmek için araçlar kullanırlar. Alana özgü modeller için araçların yararlı olduğu özellikle üç alan vardır:

1. Bir dili anlamak
2. Dil etkileşimlerini anlamak
3. Dillerin nasıl kullanılacağını anlamak

İlk olarak, bir dili anlamak zor olabilir ve XML tabanlı alana özgü diller söz konusu olduğunda sık ve sezgisel bir itiraz, sözdizimi önemlidir itiraz. Bu argüman şu şekilde ifade edilebilir: “Farklı dillerin anlaşılması zordur ve sadece karışıklığa katkıda bulunur, çünkü bunların XML tabanlı sözdizimi özellikle ayrıntılı ve anlaşılmazdır. Java gibi tek bir genel amaçlı dil kullanmak daha iyi olurdu çünkü o zaman geliştiriciler zaten bildikleri bir sözdizimine güvenebilirler ”. Bu itiraz kesinlikle önemli olmakla birlikte, merkezi bir noktayı gözden kaçırmaktadır. XML veya benzer bir temsil biçimi, geliştiricilerin gerçekte çalıştığı sözdizimi olmayabilir. XML tabanlı etki alanına özgü dilleri kullanmanın avantajlarından biri, etki alanına özgü düzenleyiciler sağlayabilmemizdir. Aşağıdaki şekil, Entity DSL için varsayımsal bir düzenleyicinin nasıl görünebileceğini göstermektedir. Bu düzenleyici, alanı basit ve görsel olarak çekici bir şekilde sunar, ancak altındaki XML gösterimini (ve belki de bir düzen yapılandırmasını) çok iyi kullanabilir.

XML'in kötü bir seçim olduğundan şikayetçi olabileceğimiz gibi, Java gibi genel amaçlı bir dilin bazı görevler için kötü bir seçim olduğuna da itiraz edebiliriz. Dahası, geliştiriciler şekil olarak editör tarafından XML veya Java'daki kod listelemelerinden daha az korkabilirler. Kabul edersek sözdizimi önemlidir özel düzenleyicilerle farklı dillerin kullanılması mantıklı bir strateji haline gelir. Editörün basitliği, dilin anlaşılmasını ve dolayısıyla kullanımını kolaylaştırır. Başka bir deyişle, sözdizimi önemlidir itiraz, şu alanı keşfetmemizin nedeni olabilir: Etki alanına özgü diller.

İkincisi, dil etkileşimleri diller arasındaki ilişkileri ortaya çıkarır. Geliştiriciler, farklı yapılardaki ilgili öğeler arasında geçiş yapabilmelidir. Farklı yazılım yapıları arasında gezinme kolaylığı, geleneksel geliştirme ortamlarındaki araçlar için önemli bir kriterdir. Hayır yapmamıza rağmen ampirik çalışmalar Bu alanda, uygun navigasyon olanaklarının üretkenliği artırdığını varsayıyoruz. Bu iddia, günümüzde tüm büyük geliştirme ortamlarının, tür hiyerarşi tarayıcısı veya bir yöntem tanımına hızlı bir şekilde bulunma ve referanslara atlama yeteneği gibi oldukça karmaşık gezinme olanakları sunduğu gözlemiyle desteklenmektedir. Geliştirme ortamları bu gezinme olanaklarını sağlayabilir çünkü kaynak dosyaların sürekli güncellenen bir modelini bir soyut sözdizimi ağacı.

İçinde geliştirme ortamı birden çok dilde gezinmek çok daha zordur. Mevcut ortamlar, DSL modellerini, keyfi ve hatta önceki örnekteki diller gibi uygulamaya özel diller için soyut sözdizimi ağaçları olarak ayrıştırmaya ve temsil etmeye yönelik değildir. Dahası, bu dahili temsil olmadan, mevcut ortamlar bu tür diller için ne dil içi ne de diller arası referansları çözemez ve bu nedenle yararlı gezinme sağlayamaz. Bu, geliştiricilerin bir kavramsal model sistemlerinin parçalarının birbiriyle nasıl ilişkili olduğu konusunda. Diğer yandan, birden çok dile yönelik navigasyon olanaklarına sahip yeni araçlar, diller arasındaki ilişkileri anlamada çok yardımcı olacaktır. Açısından anket oluştur Örneğin, bu tür araçlar, yumuşak referansları navigasyon noktaları olarak kullanarak üç dil arasındaki ilişkileri görüntülemelidir.

Üçüncüsü, dil kullanımını anlamak için geliştirme ortamımızda doğru düzenleme işlemlerini yanlış olanlardan ayırt edebilmeliyiz. Geleneksel geliştirme ortamları, bir programın yazılması sırasında uzun süredir rehberlik sağlamıştır. Artımlı derleme, ortamın geliştiriciye bir ifadenin nasıl tamamlanacağı gibi ayrıntılı öneriler sunmasına olanak tanır. Yalnızca dilbilgisine uygun girdinin girilebildiği sözdizimi odaklı düzenleyiciler gibi daha müdahaleci rehber türleri de mevcuttur. Bir dilin grameri ile parametrelendirilebilen genel metin editörleri uzun zamandır var olmuştur.^[3]

Mevcut editörler rehberlik sağlarken diller arası tutarlılık ilişkilerini hesaba katmazlar. Önceki örnekte, ideal bir düzenleyici, örneğin, geliştirici Form tanımındaki hedef niteliği düzenlediğinde createSurvey hizmetini geçerli bir değer olarak önerebilmelidir. Farklı dillerdeki eserler hakkında akıl yürütebilecek bir ortam, geliştiricinin yerel tutarlılığın olduğu ancak küresel tutarlılığın olmadığı program durumlarını belirlemesine de yardımcı olabilir. Böyle bir durum, bir modelin iyi biçimli ve dolayısıyla yerel olarak tutarlıdır, ancak aynı zamanda bir diller arası kısıtlamayı da ihlal eder. Bir modelin nasıl tamamlanacağına dair öneriler şeklinde rehberlik veya akıllı yardım, birden çok dil ve karmaşık tutarlılık kısıtlamaları içeren kurulumlar için yararlı olacaktır. Araç tarafından önerilen düzenleme işlemleri, geliştiricinin dillerin nasıl kullanılacağını öğrenme sürecine başlamasını kolaylaştırabilir.

Teknik bir zorluk olarak koordinasyon

Koordinasyon sorununun teknik yönü, esas olarak tutarlılığı zorlama meselesidir. Modelleme zamanında birden çok dilden modeller arasındaki tutarsızlıkları nasıl tespit edebiliriz? Birden çok dile dayalı bir sistemin tutarlılık gereksinimlerinin karmaşıklığını tam olarak anlamak için tutarlılık kavramımızı geliştirmek yararlıdır.

Tutarlılık, intra veya inter-tutarlılık olabilir. Tutarlılık, tek bir model içindeki öğelerin tutarlılığı ile ilgilidir. Buradaki gereklilikler, modelin metamodeline uyması, yani sözdizimsel olarak iyi biçimlendirilmiş olmasıdır. Anket oluşturma örneği açısından, varlık modeli örneğin Entity DSL'in XSD şemasına uygun olmalıdır. Bu şema, Entity DSL'in metamodelidir ve öğelerin nasıl oluşturulabileceğini ve bir dereceye kadar özniteliklerin geçerli alanlarının ne olduğunu belirtir.

Dil sınırlarının ötesindeki referanslar çözülebildiğinde, ara tutarlılık elde edilir. Bu tür bir tutarlılık, (1) modelden modele tutarlılık ve (2) modelden koda tutarlılık olarak daha da alt gruplara ayrılabilir. Modelden modele tutarlılık, bilgi tutarlılığı ve sistemin üst düzey kısıtlamaları. İçinde anket oluştur Örneğin, Hizmet listesindeki varsayılan-varlık-adı özniteliği, Varlık listesindeki ad özniteliğini ifade eder. Bu değerlerden birini diğerini güncellemeden değiştirirsek referansı bozarız. Daha sonra tartışıldığı gibi, farklı modeller arasında daha yüksek düzey tutarlılık kısıtlamaları da mevcuttur. Bir proje, model öğelerini adlandırmak ve ilişkilendirmek için belirli kalıplara veya kurallara sahip olabilir. Önceki örnekte olduğu gibi diller arasında tutarlılığı sağlamak için mevcut geliştirme ortamları el yazısı eklentiler veya benzer mekanizmalarla belirli dillere uyarlanmalıdır.

Modelden koda tutarlılık, çok düzeyli özelleştirmede temel bir gerekliliktir. Modeller, olduğu gibi kod parçacıklarıyla desteklendiğinde PDF oluştur Örneğin, modellerin ve kodun gerçekten kontrol edilmesi gerekir. Uygun. Bu kısmen, modelden modele tutarlılıktaki referans bütünlüğüne benzer şekilde, modeller ve kod arasındaki yumuşak referansların bozulmamasını sağlamakla ilgilidir. Ama aynı zamanda, kodun modelde belirlenen beklentileri ihlal etmediğinden emin olma meselesidir. İçinde PDF oluştur Örneğin, model outByteWrapper'ın her zaman çıktının bir parçası olacağını belirtir, yani outByteWrapper anahtarı sonuç haritasına yerleştirilir. Kodun bir analizi, outByteWrapper'ın, 10. satırdan önce hiçbir istisna atılmaması durumunda çıktının yalnızca bir parçası olacağını gösterir. Diğer bir deyişle, kodun bazı olası uygulamaları, modelleme seviyesindeki bir belirtimi ihlal eder. Daha genel olarak, çok seviyeli özelleştirmenin ilgili modeller ve kod parçacıkları üzerinde çok ince sınırlamalar getirdiğini söyleyebiliriz.

Koordinasyon problemini çözme

Koordinasyon sorunu, tek bir sistemde birden fazla dilin kullanılmasından kaynaklanmaktadır. Önceki iki Alt Bölüm, bu sorunun hem kavramsal hem de düşük düzeyli bir teknik yanı olduğunu göstermektedir. Tanımladığımız zorluklar, varsayımsal zorluklardan çok gerçektir. Spesifik olarak, bu zorluklarla iki somut ve temsili vaka incelemesinde karşılaştık: bir kurumsal kaynak planlama sistemi, OFBiz ve bir sağlık sistemi İlçe Sağlık Bilgi Sistemi (DHIS ). Her iki durum da gerçek endüstriyel kullanımda olan orta ölçekli sistemlerdir. Bu sistemlerle yaptığımız çalışmalar sırasında karşılaştığımız pratik sorunlara çözümümüz bir dizi kılavuz ve prototiptir. Aşağıda, kılavuzları ve prototipleri tutarlı bir yöntemle birleştiren genel bir kavramsal çerçeve sunacağız: koordinasyon yöntemi.

Koordinasyon yöntemi

Koordinasyon yönteminin amacı^[1] koordinasyon problemini çözmek ve böylelikle birden çok dil ile geliştirme için daha iyi destek sağlamaktır. Yöntemi doğru bir şekilde değerlendirmek için, tek tek dillerin tasarımını öngörmediğini anlamak önemlidir. Bunun için zaten birçok yöntem ve araç önerilmiştir.^[4][5] Bu yöntem, birden çok alana özgü dil içeren bir kurulumun varlığını varsayar. Böyle bir kurulum verildiğinde, yöntem uygulanabilir. Yöntem, aşağıdaki şemada gösterildiği gibi üç adımdan oluşur. Her adım, diyagramda küçük kutular olarak gösterilen birkaç parçadan oluşur. Noktalı çizgiler içeren kutular otomatik işlemleri temsil eder ve düz çizgili kutular manuel olanları temsil eder. Aşağıda bu aşamaları biraz daha detaylı anlatacağız.

Adım 1: Tanımlama

Tanımlama adımının amacı, dil örtüşmelerini belirlemektir. Örnekte açıklandığı gibi, örtüşme, iki dilin endişelerinin kesiştiği bir alandır. yumuşak referanslar Anket oluşturma durumunda Form DSL'den Hizmet DSL'e ve Hizmet DSL'den Kurum DSL'e bu tür örtüşme örnekleridir. Diğer bir örnek, bir modeli genişletmek için özelleştirilmiş bir kod parçacığının kullanıldığı durumdur. Modelin kapsamı dışındaki özel gereksinimleri uygulamak için genel amaçlı dillerin ifade gücüne ihtiyaç duyulduğunda bu tür örtüşmeler sık ​​görülür. Tanımlama aşaması, çakışmaların karmaşıklığına bağlı olarak manuel veya otomatik bir süreç olabilir. Örtüşmeler tanımlandığında ve açık hale getirildiğinde, bu bilgi yöntemdeki ikinci adım olan spesifikasyon adımı için girdi olarak kullanılır.

Adım 2: Özellikler

Spesifikasyon adımının amacı, bir koordinasyon modeli dillerin nasıl etkileşim kurduğunu belirtir. Bir sistemdeki dil sınırlarının ötesindeki referanslar, o belirli sistem için koordinasyon modelini oluşturur. Ana yazılım yapılarını ortak bir temsilde eşleyerek oluşturulur. Alana veya uygulamaya özgü kısıtlamalar gibi ek bilgiler de zengin bir temsil sağlamak için kodlanabilir. Koordinasyon modeli, dil gramerleri ve kısıtlamalar gibi genel bilgilerin yanı sıra somut modeller ve uygulamaya özgü kısıtlamalar gibi uygulamaya özgü bilgilere dayanmaktadır. Bu, birkaç üründe aynı diller kullanılsa bile, her ürünün kendi benzersiz koordinasyon modelinin bir özelliğine sahip olduğu anlamına gelir. Koordinasyon modeli, yöntemin son adımı olan uygulama adımında çeşitli akıl yürütme biçimleri için temel olarak kullanılır.

3. Adım: Uygulama

Uygulama adımının amacı koordinasyon modelinden yararlanmaktır. Koordinasyon modeli, araçların üç kat yararlı bilgi türetmesine izin verir. İlk olarak, koordinasyon modeli birden çok dilde tutarlılığı sağlamak için kullanılabilir. Koordinasyon modeli, farklı dillerden öğelerin birbirine nasıl başvurabileceği gibi tutarlılık ilişkilerini belirtir. Araçlar, bilgi tutarlılığını zorlayabilir ve dağıtımdan önce son sistemin statik kontrollerini gerçekleştirebilir. İkincisi, tutarlılık ilişkileri, bir geliştirme kurulumundaki farklı dillerin ağında gezinmek, görselleştirmek ve haritalamak için kullanılır. Bu bilgiler, farklı dillerdeki öğeleri hızlı bir şekilde bağlamak ve ilişkilendirmek ve farklı modeller arasında izlenebilirlik sağlamak için kullanılır. Üçüncüsü, tutarlılık ilişkilerine ve öğelerin birbiriyle nasıl ilişkili olduğuna dair navigasyon bilgilerine dayalı olarak araçlar rehberlik, özellikle tamamlama veya yardım sağlayabilir. Model tamamlama, örneğin alana özgü araçlarda genel bir şekilde sağlanabilir.

Koordinasyon yönteminin değerlendirilmesi

Koordinasyon yöntemi^[1] en iyi, birden çok dilde çalışırken belirli bir iş akışını öngören kavramsal bir çerçeve olarak görülebilir. Bu iş akışını oluşturan üç ardışık adım, entegre bir çalışma tezgahı veya geliştirme ortamı tarafından desteklenmez. Odak noktası, (1) tanımlama, (2) spesifikasyon ve (3) uygulama için destek eklemek üzere geliştiricinin mevcut ortamlarını genişletmektir. Bu yaklaşımın temel avantajı, geliştiricilerin çalışmalarımızı gerçekten test etmesi ve bize geri bildirim vermesiydi. Yöntemin bu tür bir değerlendirmesi değerlidir çünkü tamamen varsayımsal bir problemi çözme riskini azaltır. Çeşitli makaleler, koordinasyon yönteminin farklı adımlarını tanıtmakta, bu değerlendirme hakkında rapor sunmakta ve her bir deneyin teknik yönlerini detaylandırmaktadır. Genel olarak, sonuçlar ümit vericidir: üretim sistemlerinde önemli sayıda hata bulundu ve gelecekteki araç gereksinimleri konusunda geliştiricilerle yapıcı bir diyaloğa yol açtı. Bu kılavuzlara dayalı ve araçlarla desteklenen bir geliştirme süreci, koordinasyon problemini çözmek ve alana özgü çoklu modellemeyi pratik bir teklif haline getirmek için ciddi bir girişimdir.

Ayrıca bakınız

• Alana özgü dil
• Etki alanına özgü modelleme
• Model odaklı mühendislik

Referanslar