Özellik odaklı programlama - Feature-oriented programming

İçinde bilgisayar Programlama, özellik odaklı programlama (FOP) veya özellik odaklı yazılım geliştirme (FOSD) bir programlama paradigması program üretimi için yazılım ürün grupları (SPL'ler) ve programların kademeli olarak geliştirilmesi için.

Tarih

dikey katman istiflemesi
Katman yığınları ve dönüştürme bileşimleri arasındaki bağlantı

FOSD, katman temelli tasarımlardan ve 1980'lerin sonlarında ağ protokollerinde ve genişletilebilir veritabanı sistemlerinde soyutlama seviyelerinden ortaya çıktı.[1] Bir program bir katmanlar yığınından ibaretti. Her katman, önceden oluşturulmuş katmanlara işlevsellik kattı ve farklı katman bileşimleri farklı programlar üretti. Şaşırtıcı olmayan bir şekilde, bu tür tasarımları ifade etmek için kompakt bir dile ihtiyaç vardı. Temel cebir faturaya uyuyor: her katman bir işlevdi (a program dönüşümü ) yeni bir program üretmek için mevcut bir programa yeni kod ekleyen ve bir programın tasarımı bir ifadeyle, yani bir dönüşüm bileşimi (katmanlar) tarafından modellenmiştir. Soldaki şekil, i, j ve h katmanlarının istiflenmesini gösterir (burada h altta ve i üsttedir). Bu tasarımları ifade etmek için cebirsel notasyonlar i (j (h)), i • j • h ve i + j + h kullanılmıştır.

Zamanla, katmanlar özniteliklere eşitlendi. özellik program işlevselliğinde bir artıştır. Program tasarımı ve üretimi için paradigma, sorgu değerlendirme programlarının ilişkisel cebir ifadeleri olarak tanımlandığı ve sorgu optimizasyonunun ifade optimizasyonu olduğu ilişkisel sorgu optimizasyonunun bir sonucu olarak kabul edildi.[2] Yazılım ürün grubu, her programın benzersiz bir özellik bileşimi ile tanımlandığı bir programlar ailesidir. O zamandan beri FOSD, özellik tabanlı program oluşturmayı desteklemek için özellik modülerliği, araçlar, analizler ve tasarım teknikleri çalışmasına dönüşmüştür.

İkinci nesil FOSD araştırması, telekomünikasyondan kaynaklanan özellik etkileşimleri üzerineydi. özellik odaklı programlama icat edildi;[3] bu çalışma katmanlar arasındaki etkileşimleri ortaya çıkardı. Etkileşimler, diğer özelliklerle oluşturulduğunda özelliklerin uyarlanmasını gerektirir.

Üçüncü nesil bir araştırma, her programın birden çok temsiline (örneğin kaynak, makefile, dokümantasyon vb.) Sahip olduğu ve bir programa bir özellik eklenmesi, her birinin tutarlı olması için temsillerinin her birini detaylandırmalıdır. Ek olarak, bazı temsiller diğerlerinden üretilebilir (veya türetilebilir). Aşağıdaki bölümlerde, FOSD'nin en son üç neslinin matematiği, yani GenVoca,[1] ÖNDE,[4] ve FOMDD[5][6] FOSD araçları kullanılarak geliştirilmiş ürün serilerine bağlantılar ve ayrıca tüm FOSD nesilleri için geçerli olan dört ek sonuç şunlardır: FOSD metamodelleri, FOSD program küpleri ve FOSD özelliği etkileşimler.

GenVoca

GenVoca (bir Portmanteau Genesis ve Avoca isimleri)[1] ürün gruplarının programlarını tanımlamak için bir kompozisyon paradigmasıdır. Temel programlar 0-ary işlevler veya adı verilen dönüşümlerdir değerler:

  f - özelliğine sahip temel program f h - h özelliğine sahip temel program

ve özellikler, bir programı ayrıntılandıran (değiştiren, genişleten, iyileştiren) tek işlevler / dönüşümlerdir:

  i + x - x programına i özelliğini ekler j + x - x programına j özelliğini ekler

burada + işlev bileşimini belirtir. tasarım bir programın adı adlandırılmış bir ifadedir, örneğin:

  p1 = j + f - program p1 j ve f p özelliklerine sahiptir2 = j + h - program p2 j ve h p özelliklerine sahiptir3 = i + j + h - program p3 i, j ve h özelliklerine sahiptir

Bir GenVoca modeli Bir etki alanının veya yazılım ürün grubunun, temel programların ve özelliklerin bir koleksiyonudur (bkz. MetaModels ve Program Küpleri Oluşturulabilecek programlar (ifadeler) bir ürün serisini tanımlar. İfade optimizasyonu program tasarım optimizasyonuve ifade değerlendirmesi program üretimi.

Not: GenVoca, programların aşamalı olarak geliştirilmesine dayanmaktadır: tasarımın basitliğini ve anlaşılabilirliğini vurgulayan, programın anlaşılması ve otomatikleştirilmiş program yapımının anahtarı olan bir süreç. P programını düşünün3 yukarıda: temel program h ile başlar, ardından j özelliği eklenir (okuma: j özelliğinin işlevselliği h'nin kod tabanına eklenir) ve son olarak i özelliği eklenir (okuma: i özelliğinin işlevselliği kod tabanına eklenir j • h).
Not: özelliklerin tüm kombinasyonları anlamlı değildir. Özellik modelleri (önerme formüllerine çevrilebilir), özelliklerin yasal kombinasyonlarını tanımlayan grafiksel temsillerdir.[7]
Not: GenVoca'nın daha yeni bir formülasyonu simetrik: yalnızca bir temel program vardır, 0 (boş program) ve tüm özellikler tekli işlevlerdir. Bu, GenVoca'nın program yapılarını oluşturduğu yorumunu önermektedir. süperpozisyon, karmaşık yapıların daha basit yapıların üst üste binmesiyle oluştuğu fikri.[8][9] GenVoca'nın bir başka yeniden formülasyonu ise monoid: GenVoca modeli, bir kompozisyon işlemi (•) içeren bir dizi özelliktir; kompozisyon ilişkiseldir ve bir kimlik öğesi vardır (yani 1, kimlik işlevi). Tüm kompozisyonlar mümkün olsa da hepsi anlamlı değildir. Nedeni bu özellik modelleri.

GenVoca özellikleri başlangıçta C ön işlemcisi (#ifdef özelliği ... #endif) teknikleri. Daha gelişmiş bir teknik adı verilen katmanları karıştırmak, özelliklerin nesneye yönelik işbirliğine dayalı tasarımlarla bağlantısını gösterdi.

ÖNDE

Uygulama Tasarımı için Cebirsel Hiyerarşik Denklemler (ÖNDE)[4] GenVoca'yı iki şekilde genelleştirdi. Önce GenVoca değerlerinin iç yapısını tuple olarak ortaya çıkardı. Her programın kaynak, dokümantasyon, bayt kodu ve makefiles gibi birden çok temsili vardır. GenVoca değeri, program temsillerinden oluşan bir gruptur. Ayrıştırıcıların bir ürün serisinde, örneğin, bir temel ayrıştırıcı f, grameri g ile tanımlanırf, Java kaynaklarıfve dokümantasyon df. Ayrıştırıcı f, f = [g demetiyle modellenirf, sf, df]. Her program temsilinin alt beyanları olabilir ve bunların da yinelemeli olarak alt beyanları olabilir. Genel olarak, bir GenVoca değeri, belirli bir program için temsiller hiyerarşisini tanımlayan iç içe geçmiş gruplardan oluşan bir gruptur.

Program yapıları arasındaki hiyerarşik ilişkiler

Misal. Uçbirim temsillerinin dosya olduğunu varsayalım. AHEAD'de gramer gf tek bir BNF dosyasına karşılık gelir, kaynak sf Java dosyalarının bir demetine karşılık gelir [c1… Cn] ve dokümantasyon df HTML dosyalarının bir demetidir [h1… Hk]. Bir GenVoca değeri (iç içe geçmiş demetler) yönlendirilmiş bir grafik olarak gösterilebilir: ayrıştırıcı f için grafik sağdaki şekilde gösterilmiştir. Oklar, projeksiyonları, yani bir demetten bileşenlerinden birine eşlemeleri belirtir. AHEAD tupleları dosya dizinleri olarak uygular, dolayısıyla f, g dosyasını içeren bir dizindir.f ve alt dizinlerf ve df. Benzer şekilde, dizinlerf c dosyaları içerir1… Cnve df dizini h dosyalarını içerir1… Hk.

Not: Dosyalar hiyerarşik olarak daha da ayrıştırılabilir. Her bir Java sınıfı, bir üye demetine ve diğer sınıf bildirimlerine (örn., Başlatma blokları, vb.) Ayrıştırılabilir. Buradaki önemli fikir, AHEAD matematiğinin yinelemeli olmasıdır.

İkinci olarak, AHEAD özellikleri, adı verilen tekli işlevlerin iç içe geçmiş demetleri olarak ifade eder. deltalar. Deltalar olabilir program ayrıntılandırmaları (semantiği koruyan dönüşümler), uzantılar (anlamsal genişleyen dönüşümler) veya etkileşimler (anlambilim değiştiren dönüşümler). Her biri FOSD'de olduğu gibi, tüm bu olasılıkları temsil etmek için nötr bir terim olan "delta" kullanıyoruz.

Örnek vermek gerekirse, j özelliğinin bir dilbilgisini şu kadar genişlettiğini varsayalım: gj (yeni kurallar ve belirteçler eklenir), kaynak kodunu şu kadar genişletir: sj (yeni sınıflar ve üyeler eklenir ve mevcut yöntemler değiştirilir) ve dokümantasyonu şu şekilde genişletir: dj. J özelliği için deltaların demeti j = [gj,sj,dj], biz buna delta demeti. Delta demetlerinin unsurlarının kendileri delta demetleri olabilir. Misal: sj her sınıfa yapılan değişiklikleri temsil eder.f j özelliğine göre, yani sj=[c1cnBir programın gösterimleri, iç içe vektör toplama ile özyinelemeli olarak hesaplanır. Ayrıştırıcı p için temsiller2 (GenVoca ifadesi j + f olan):

  p2 = j + f - GenVoca ifadesi = [gj, sj, dj] + [gf, sf, df] - ikame = [gj+ gf, sj+ sf, dj+ df] - eleman bazında tuples oluştur

Yani, p'nin grameri2 uzantısı ile oluşturulan temel gramerdir (gj+ gf), p kaynağı2 uzantısı ile oluşturulan temel kaynaktır (sj+ sf), ve benzeri. Delta demetlerinin öğeleri kendileri delta demetleri olabileceğinden, kompozisyon tekrar eder, örn. sj+ sf= [c1cn] + [c1… Cn]=[c1+ c1cn+ cnÖzetlemek gerekirse, GenVoca değerleri, program yapılarının iç içe geçmiş demetleridir ve özellikler, + vektör toplamayla bunları yinelemeli olarak oluşturduğu iç içe delta demetleridir. Bu, AHEAD'in özüdür.

Yukarıda sunulan fikirler iki FOSD ilkesini somut olarak ortaya koymaktadır. Tekdüzelik İlkesi tüm program yapılarının aynı şekilde ele alındığını ve değiştirildiğini belirtir. (Bu, yukarıdaki farklı yapı türleri için deltalar ile kanıtlanmıştır). Ölçeklenebilirlik İlkesi tüm soyutlama seviyelerinin aynı şekilde ele alındığını belirtir. (Bu, yukarıdaki tuple'ların hiyerarşik olarak iç içe geçmesine yol açar).

AHEAD'in orijinal uygulaması, hem Tekdüzelik hem de Ölçeklenebilirlik İlkelerini sergileyen AHEAD Tool Suite ve Jak dilidir. Yeni nesil araçlar CIDE'yi içerir[10]ve FeatureHouse.[11]

FOMDD

Program yapıları arasında türetme ve iyileştirme ilişkileri

Özellik Odaklı Model Odaklı Tasarım (FOMDD)[5][6] AHEAD'in fikirlerini Model Odaklı Tasarım (MDD) (diğer adıyla. Model Odaklı Mimari (MDA)). AHEAD işlevleri, bir programa bir özellik eklendiğinde program yapılarının kilit adımı güncellemesini yakalar. Ancak, türetmeleri ifade eden program yapıları arasında başka işlevsel ilişkiler de vardır. Örneğin, gramer g arasındaki ilişkif ve ayrıştırıcı kaynaklarıf bir derleyici-derleyici aracı, örneğin javacc ile tanımlanır. Benzer şekilde, Java kaynakları arasındaki ilişkif ve bayt kodu bf javac derleyicisi tarafından tanımlanır. Bir işe gidip gelme diyagramı bu ilişkileri ifade eder. Nesneler program temsilleridir, aşağı doğru oklar türetilmiştir ve yatay oklar deltalardır. Sağdaki şekil p programı için işe gidip gelme diyagramını gösterir.3 = i + j + h = [g3, s3, b3].

Bir temel özelliği işe gidip gelme diyagramı iki nesne arasındaki tüm yolların eşdeğer olmasıdır. Örneğin, bayt kodunu türetmenin bir yolu b3 ayrıştırıcı p3 (sağdaki şekilde sağ alt nesne) gramerden gh ayrıştırıcının h (sol üst nesne) bayt kodu b'yi türetmektirh ve b'ye göre düzeltin3, başka bir yol g'yi rafine ederkenh g'ye3ve sonra b'yi türet3, burada + delta bileşimini temsil eder ve () işlev veya araç uygulamasıdır:

  b3 = bj + bben + javacc (javac (gh )) = javac (javacc ( gben + gj + gh ) )

Var bayt kodunu türetmek için olası yollar b3 ayrıştırıcı p3 gramerden gh ayrıştırıcı h. Her yol bir metaprogram yürütülmesi hedef nesneyi oluşturan (b3) başlangıç ​​nesnesinden (gf). Potansiyel bir optimizasyon var: bir satırın her okunu geçerek işe gidip gelme diyagramı bir maliyeti var. Bir içindeki iki nesne arasındaki en ucuz (yani en kısa) yol işe gidip gelme diyagramı bir jeodezik, belirli bir nesneden hedef nesneyi üreten en verimli metaprogramı temsil eder.

Not: Bir "maliyet metriğinin" parasal bir değer olması gerekmez; maliyet, üretim süresi, en yüksek veya toplam bellek gereksinimleri, güç tüketimi veya "açıklama kolaylığı" gibi bazı resmi olmayan ölçütler veya yukarıdakilerin bir kombinasyonu olarak ölçülebilir (ör. çok amaçlı optimizasyon ). Bir jeodezik fikri geneldir ve bu daha genel bağlamdan anlaşılmalı ve değerlendirilmelidir.
Not: Bir jeodezikte m başlangıç ​​nesnesi ve n bitiş nesnesi olması mümkündür; m = 1 ve n> 1 olduğunda, bu Yönetilen Steiner Ağacı Sorunu NP-zordur.

İşe gidip gelme diyagramları en az iki nedenden dolayı önemlidir: (1) yapay nesnelerin (ör. jeodezik) üretimini optimize etme olasılığı vardır ve (2) bir başlangıç ​​nesnesinden bir hedef nesne oluşturmanın farklı yollarını belirtirler.[5][12] Bir diyagramdan geçen bir yol, bir araç zincirine karşılık gelir: Bir FOMDD modelinin tutarlı olması için, bir nesneyi diğerine eşleyen tüm araç zincirlerinin aslında eşdeğer sonuçlar verdiği kanıtlanmalıdır (veya test yoluyla gösterilmelidir). Durum böyle değilse, ya bir ya da daha fazla araçta bir hata vardır ya da FOMDD modeli yanlıştır.

Not: Yukarıdaki fikirlerden ilham alınmıştır: kategori teorisi.[5][6]

Başvurular

Ayrıca bakınız

Referanslar

  1. ^ a b c "Yeniden Kullanılabilir Bileşenlerle Hiyerarşik Yazılım Sistemlerinin Tasarımı ve Uygulanması" (PDF).
  2. ^ "İlişkisel Veritabanlarında Erişim Yolu Seçimi".
  3. ^ "Özellik Odaklı Programlama: Nesnelere Yeni Bir Bakış". Arşivlenen orijinal 2003-08-03 tarihinde. Alındı 2015-12-16.
  4. ^ a b "Adım Adım İyileştirmeyi Ölçeklendirme" (PDF).
  5. ^ a b c d "Özellik Odaklı Model Odaklı Geliştirme: Portletler İçin Bir Örnek Olay" (PDF).
  6. ^ a b c Trujillo, Salvador; Azanza, Maider; Díaz, Óscar (Ekim 2007). "Üretken Metaprogramlama". GPCE '07: Üretimsel programlama ve bileşen mühendisliği üzerine 6. uluslararası konferansın bildirileri: 105–114. doi:10.1145/1289971.1289990.
  7. ^ "Özellik Modelleri, Dilbilgileri ve Önerme Formülleri" (PDF).
  8. ^ "Özellikler ve Özellik Kompozisyonu İçin Bir Cebir" (PDF).
  9. ^ "Üst üste binme: Yazılım Bileşimine Dilden Bağımsız Bir Yaklaşım" (PDF).
  10. ^ "Tüm Ürün Serisi Varyantları için Sözdizimsel Doğruluğu Garanti Etmek: Dilden Bağımsız Bir Yaklaşım" (PDF).
  11. ^ "FeatureHouse: Dilden Bağımsız, Otomatik Yazılım Oluşturma" (PDF).
  12. ^ "Artımlı Test Üretimi Kullanarak Yazılım Ürün Hatlarını Test Etme" (PDF).