Akış tabanlı programlama - Flow-based programming

Olarak bilgisayar programlama , akış bazlı programlama ( FBP ) a, programlama paradigması bu tanımlar uygulamaları "kara kutu" ve ağlar gibi işlemler tarafından önceden tanımlanmış bağlantılar üzerinden veri alış verişi, mesaj geçen bağlantılar belirtilen, harici işlemlere. Bu kara kutu süreçleri, dahili olarak değiştirilmeden farklı uygulamalar oluşturmak için sonsuz bir şekilde yeniden bağlanabilir. FBP bu nedenle doğal olarak bileşen odaklıdır .

FBP, sınırlı arabelleklere, tanımlanmış ömürleri olan bilgi paketlerine, adlandırılmış bağlantı noktalarına ve ayrı bağlantı tanımlarına dayanan özel bir veri akışı programlama biçimidir .

Tanıtım

Akış tabanlı programlama, uygulamaları bir "veri fabrikası" metaforunu kullanarak tanımlar. Bir uygulamayı, zaman içinde bir noktada başlayan ve daha sonra bitene kadar her seferinde bir şey yapan tek, sıralı bir süreç olarak değil , yapılandırılmış veri parçalarının akışları aracılığıyla iletişim kuran asenkron süreçlerin bir ağı olarak görür. "bilgi paketleri" (IP'ler) olarak adlandırılır. Bu görünümde, istenen çıktıları üretmek için uygulama verilerine ve bunlara uygulanan dönüşümlere odaklanılır. Ağ, süreçlerin dışında, genellikle "programlayıcı" olarak adlandırılan bir yazılım parçası tarafından yorumlanan bağlantıların bir listesi olarak tanımlanır.

Süreçler, sabit kapasiteli bağlantılar aracılığıyla iletişim kurar. İşlem kodu ve ağ tanımı arasında üzerinde anlaşmaya varılan bir ada sahip bir bağlantı noktası aracılığıyla bir işleme bağlantı eklenir . Aynı kod parçasını birden fazla işlem yürütebilir. Herhangi bir zamanda, belirli bir IP yalnızca tek bir işlem tarafından "sahip olunabilir" veya iki işlem arasında geçiş halinde olabilir. Bağlantı noktaları , örneğin aşağıda açıklanan Harmanlama bileşeninin giriş bağlantı noktası için kullanıldığı gibi, basit veya dizi tipi olabilir. Sıralama, Birleştirme, Özetleme, vb. gibi veri işlemenin birçok uzun süredir çalışan ilkel işlevlerinin yazılım kara kutuları biçiminde desteklenmesine izin veren, bağlantı noktalarının asenkron süreçlerle birleşimidir .

FBP süreçleri, üzerinde çalışacak verileri ve çıktılarını koyacakları bir yere sahip oldukları sürece yürütülmeye devam edebildiğinden, FBP uygulamaları genellikle geleneksel programlardan daha kısa sürede çalışır ve özel bir programlama gerektirmeden bir makinedeki tüm işlemcilerden en iyi şekilde yararlanır. Bunu başarmak için.

Ağ tanımı genellikle şematiktir ve bazı alt düzey dillerde veya gösterimlerde bir bağlantı listesine dönüştürülür. FBP genellikle bu seviyede görsel bir programlama dilidir . Daha karmaşık ağ tanımları, "yapışkan" bağlantılara sahip alt ağlardan oluşturulan hiyerarşik bir yapıya sahiptir. Diğer birçok akış tabanlı dil/çalışma zamanı, daha geleneksel programlama dilleri etrafında oluşturulmuştur; en dikkate değer örnek, akış grafiğini belirtmek için C++ iostream benzeri operatörleri kullanan RaftLib'dir .

FBP'nin Linda diliyle çok ortak yanı vardır, çünkü o, Gelernter ve Carriero'nun terminolojisinde bir "koordinasyon dili"dir: esasen dilden bağımsızdır. Gerçekten de, yeterince düşük seviyeli bir dilde yazılmış bir programlayıcı verildiğinde, farklı dillerde yazılmış bileşenler tek bir ağda birbirine bağlanabilir. Böylece FBP, alana özgü diller veya "mini diller" kavramına kendini borçludur .

FBP ile makalede açıklanan "bağlama verileri" sergiler bağlama parçası arasındaki bağlantı arasında gevşek türü. Kavramı, gevşek bir bağ 'dekine benzer da bir hizmet odaklı mimariler ve FBP Bu mimarinin Çoğu örneklerde daha ince taneli seviyede de olsa, bu tür bir mimari için bir dizi kriteri uyar.

FBP, sistem davranışı hakkında akıl yürütmeyi basitleştiren üst düzey, işlevsel belirtim stilini destekler. Bunun bir örneği, dağıtılmış çok taraflı protokollerin anlambilimini yapıcı bir şekilde belirlemek ve analiz etmek için dağıtılmış veri akışı modelidir.

Tarih

Akış Tabanlı Programlama, 1970'lerin başında J. Paul Morrison tarafından icat edildi ve başlangıçta bir Kanada bankası için yazılımda uygulandı. Başlangıcında FBP, dönemin bazı IBM simülasyon dillerinden, özellikle GPSS'den güçlü bir şekilde etkilenmiştir , ancak kökleri Conway'in coroutines dediği şeyle ilgili ufuk açıcı makalesine kadar uzanmaktadır .

FBP yıllar içinde bir dizi isim değişikliğine uğradı: orijinal uygulamaya AMPS (Gelişmiş Modüler İşleme Sistemi) adı verildi. Kanada'da büyük bir uygulama 1975'te yayına girdi ve 2013 itibariyle, neredeyse 40 yıldır günlük olarak çalışan sürekli üretim kullanımında. IBM, FBP'nin arkasındaki fikirlerin "bir doğa kanunu gibi" patentlenebilir olduğunu düşündüğünden, bunun yerine FBP'nin temel kavramlarını bir Teknik Açıklama Bülteni , "Veriye Duyarlı Modüler, Aralıklı Görev Programlama Sistemi" aracılığıyla kamuya açık hale getirdi. , 1971'de. 1978'de IBM Research IBM Systems Journal'da DSLM adı altında kavramlarını ve kullanım deneyimini anlatan bir makale yayınlandı . İkinci bir uygulama, IBM Kanada ve IBM Japonya'nın ortak projesi olarak "Data Flow Development Manager" (DFDM) adı altında yapıldı ve 80'lerin sonunda Japonya'da "Data Flow Programming Manager" adı altında kısaca pazarlandı.

Genellikle kavramlar IBM içinde "Veri Akışı" olarak anılırdı, ancak bu terimin çok genel olduğu hissedildi ve sonunda "Akış Tabanlı Programlama" adı kabul edildi.

80'lerin başından 1993'e kadar J. Paul Morrison ve IBM mimarı Wayne Stevens , FBP'nin arkasındaki kavramları geliştirdi ve destekledi. Stevens, FBP kavramını açıklayan ve destekleyen birkaç makale yazdı ve birkaç kitabına bununla ilgili materyal ekledi. 1994'te Morrison, FBP'yi açıklayan ve FBP'nin geliştirme sürelerinin azalmasına yol açtığına dair ampirik kanıtlar sağlayan bir kitap yayınladı.

kavramlar

Aşağıdaki diyagram, bir FBP diyagramının ana unsurlarını gösterir (Bilgi Paketleri dışında). Böyle bir diyagram, daha sonra uygun bir motor (yazılım veya donanım) tarafından yürütülebilen bir bağlantı listesine doğrudan dönüştürülebilir.

Basit FBP diyagramı

A, B ve C, kod bileşenlerini yürüten süreçlerdir. O1, O2 ve iki IN, M ve N bağlantılarını ilgili işlemlere bağlayan bağlantı noktalarıdır. B ve C işlemlerinin aynı kodu yürütmesine izin verilir, bu nedenle her işlemin kendi çalışma depolaması, kontrol blokları vb. olması gerekir. Kodu paylaşsınlar veya paylaşmasınlar, B ve C aynı bağlantı noktasını kullanmakta serbesttir. bağlantı noktası adları yalnızca onlara atıfta bulunan bileşenler içinde (ve elbette ağ düzeyinde) anlam taşıdığından, adlar.

M ve N, genellikle " sınırlı arabellekler " olarak adlandırılır ve herhangi bir zamanda tutabilecekleri IP sayısı açısından sabit bir kapasiteye sahiptir.

Bağlantı noktası kavramı , aynı bileşenin ağda birden fazla yerde kullanılmasına izin veren şeydir. Bağlantı noktaları, İlk Bilgi Paketleri (IIP'ler) adı verilen bir parametreleştirme yeteneğiyle birlikte, FBP'ye bileşeni yeniden kullanma yeteneği sağlayarak FBP'yi bileşen tabanlı bir mimari haline getirir . Böylece FBP , IBM Research'ten Raoul de Campo ve Nate Edwards'ın yapılandırılabilir modülerlik olarak adlandırdıkları şeyi sergiliyor .

Bilgi Paketleri veya IP'ler, "IP alanı" olarak adlandırılabilecek bir yerde tahsis edilir (tıpkı Linda'nın kümelerinin "tupler alanında" tahsis edilmesi gibi) ve atılana ve alanları geri kazanılana kadar iyi tanımlanmış bir ömre sahiptir - FBP'de bu sahip olma sürecinin açık bir eylemi olmalıdır. Belirli bir bağlantı üzerinden seyahat eden IP'ler (aslında seyahat eden onların "tutamaklarıdır"), asenkron olarak üretilen ve tüketilen bir "akım" oluşturur - bu nedenle bu kavram , 1976 makalesinde Friedman ve Wise tarafından açıklanan tembel eksiler kavramına benzerlik gösterir .

IP'ler genellikle yapılandırılmış veri parçalarıdır - ancak bazı IP'ler herhangi bir gerçek veri içermeyebilir, ancak yalnızca sinyal olarak kullanılır. Buna bir örnek, veri IP'lerini bir akış içinde "alt akışlar" olarak adlandırılan sıralı desenler halinde gruplamak için kullanılabilen "parantez IP'leridir". Alt akışlar sırayla iç içe olabilir. IP'ler, ağda tek nesneler olarak dolaşan "IP ağaçları" oluşturmak için birlikte zincirlenebilir.

Yukarıda açıklanan bağlantı ve işlemler sistemi, herhangi bir boyuta "dayalandırılabilir". Bir uygulamanın geliştirilmesi sırasında, süreç çiftleri arasına izleme süreçleri eklenebilir, süreçler alt ağlara "patlatılabilir" veya süreçlerin simülasyonları gerçek süreç mantığı ile değiştirilebilir. Bu nedenle FBP hızlı prototip oluşturmaya elverişlidir .

Bu gerçekten veri işlemenin bir montaj hattı görüntüsüdür: Bir süreçler ağı üzerinden seyahat eden IP'ler, bir montaj hattında istasyondan istasyona seyahat eden widget'lar olarak düşünülebilir. "Makineler" kolayca yeniden bağlanabilir, onarım için hattan çıkarılabilir, değiştirilebilir vb. Tuhaf bir şekilde, bu görüntü, bilgisayar günlerinden önce verileri işlemek için kullanılan birim kayıt ekipmanına çok benziyor , ancak kart destelerinin bir makineden diğerine elle taşınması gerekiyordu.

FBP'nin uygulamaları önleyici veya önleyici olmayabilir - önceki uygulamalar önleyici olmama eğilimindeyken (ana bilgisayar ve C dili), en son Java uygulaması (aşağıya bakın) Java Thread sınıfını kullanır ve önleyicidir.

Örnekler

"Telgraf Sorunu"

FBP bileşenleri genellikle tamamlayıcı çiftler oluşturur. Bu örnek, bu tür iki çift kullanır. Tarif edilen problem kelimelerle anlatıldığı gibi çok basit görünüyor, ama aslında geleneksel prosedürel mantık kullanarak başarmak şaşırtıcı derecede zor. Başlangıçta Peter Naur tarafından açıklanan "Telegram Problemi" olarak adlandırılan görev, metin satırlarını kabul eden ve her satırdaki karakter sayısının belirli bir değeri aşmadığı, mümkün olduğunca çok kelime içeren çıktı satırları üreten bir program yazmaktır. uzunluk. Sözcükler bölünemez ve hiçbir sözcüğün çıktı satırlarının boyutundan daha uzun olmadığını varsayıyoruz. Bu, metin düzenleyicilerdeki sözcük kaydırma sorununa benzer.

Geleneksel mantıkta programcı, kontrol akışının çağrı hiyerarşisini yönlendirmek için ne girdi ne de çıktı yapılarının kullanılamayacağını hızla keşfeder . FBP'de ise, problem tanımının kendisi bir çözüm önerir:

  • "kelimeler" sorunun açıklamasında açıkça belirtilmiştir, bu nedenle tasarımcının sözcükleri bilgi paketleri (IP'ler) olarak ele alması mantıklıdır.
  • FBP'de tek bir çağrı hiyerarşisi yoktur, bu nedenle programcı, çözümün bir alt modelini en üst düzey olmaya zorlamak için cazip değildir.

İşte FBP'deki en doğal çözüm (FBP'de tek bir "doğru" çözüm yoktur, ancak bu doğal bir uyum gibi görünüyor):

Peter Naur'un "Telgraf sorunu"

burada DC ve RC, sırasıyla "DeCompose" ve "ReCompose" anlamına gelir.

Yukarıda bahsedildiği gibi, Başlangıç ​​Bilgi Paketleri (IIP'ler), istenen çıktı kayıt uzunluğu (en sağdaki iki bileşen tarafından gereklidir) veya dosya adları gibi parametrik bilgileri belirtmek için kullanılabilir. IIP'ler, ilgili bağlantı noktası için bir "alma" verildiğinde "normal" IP'ler haline gelen ağ tanımındaki bir bağlantı noktasıyla ilişkili veri parçalarıdır.

Toplu güncelleme

Bu tür bir program, bir "ayrıntılar" (değişiklikler, ekler ve siler) dosyasını bir "ana dosyaya" geçirmeyi ve (en azından) güncellenmiş bir ana dosya ve bir veya daha fazla rapor üretmeyi içerir. İki (bazen daha fazla) giriş akışının senkronize tutulması gerektiğinden, ilgili ayrıntılara sahip olmayan master'lar veya tam tersi olabilir.

Kanonik "toplu güncelleme" yapısı

FBP'de, bir Harmanlayıcının birim kaydı fikrine dayanan yeniden kullanılabilir bir bileşen (Harmanlama), Collate iki akışı birleştirdiğinden ve gruplama seviyelerini belirtmek için parantez IP'leri eklediğinden, aşağı akış mantığını önemli ölçüde basitleştirdiği için bu tür bir uygulamayı yazmayı çok daha kolay hale getirir. Bir akışın (bu durumda "masters") 1, 2 ve 3 anahtar değerlerine sahip IP'lerden oluştuğunu ve ikinci akış IP'lerinin ("detaylar") 11, 12, 21, 31, 32, 33 anahtar değerlerine sahip olduğunu varsayalım. ve 41, burada ilk basamak ana anahtar değerlerine karşılık gelir. "Parantez" IP'lerini temsil etmek için köşeli ayraç karakterlerini kullanarak, harmanlanmış çıktı akışı aşağıdaki gibi olacaktır:

( m1 d11 d12 ) ( m2 d21 ) ( m3 d31 d32 d33 ) (d41)

4 değerinde master olmadığı için son grup tek bir detaydan (artı parantez) oluşmaktadır.

Yukarıdaki akışın yapısı, aşağıdaki gibi bir BNF benzeri notasyon kullanılarak kısa ve öz bir şekilde tarif edilebilir:

{ ( [m] d* ) }*

Harmanlama, yalnızca gelen IP'lerinde kontrol alanlarının nerede olduğunu bilmesi gereken yeniden kullanılabilir bir kara kutudur (kontrol alanlarını standart konumlara yerleştirmek için yukarı akışa transformatör işlemleri eklenebildiğinden bu kesinlikle gerekli değildir) ve aslında genelleştirilebilir herhangi bir sayıda giriş akışına ve herhangi bir parantez iç içe yerleştirme derinliğine. Harmanlama, giriş için değişken sayıda giriş akışına izin veren dizi tipi bir bağlantı noktası kullanır.

Çoğullama işlemleri

Akış tabanlı programlama, süreç çoğullamasını çok doğal bir şekilde destekler. Bileşenler salt okunur olduğundan, belirli bir bileşenin ("süreçler") herhangi bir sayıda örneği birbiriyle eşzamansız olarak çalışabilir.

Çoğullama örneği

Bilgisayarlar genellikle tek bir işlemciye sahip olduğunda, bu, çok sayıda G/Ç işlemi yapılırken kullanışlıydı; Artık makineler genellikle birden fazla işlemciye sahip olduğundan, işlemler de CPU yoğun olduğunda bu kullanışlı olmaya başlıyor. Bu bölümdeki şema, sırasıyla S1, S2 ve S3 olarak etiketlenen, tek bir bileşenin örnekleri olan ve sırasıyla "ilk gelen" ile tek bir işleme beslenen üç işlem arasında veri dağıtan tek bir "Yük Dengeleyici" işlemini gösterir. , Ilk verilen esastır.

Basit etkileşimli ağ

Genel etkileşimli uygulamanın şeması

Bu genel şemada, kullanıcılardan gelen istekler (işlemler) sol üstte diyagrama girer ve sol altta yanıtlar döndürülür. "Arka uçlar" (sağ tarafta) diğer sitelerdeki sistemlerle iletişim kurar, örneğin CORBA , MQSeries vb. kullanarak . Çapraz bağlantılar, arka uçlara gitmesi gerekmeyen istekleri veya geçiş yapması gereken istekleri temsil eder. kullanıcıya iade edilmeden önce ağın birden fazla

Farklı istekler farklı arka uçlar kullanabileceğinden ve arka uçların (kullanılıyorsa) bunları işlemesi için farklı süreler gerektirebileceğinden, döndürülen verileri uygun talep eden işlemlerle, örneğin karma tabloları veya önbelleklerle ilişkilendirmek için hüküm yapılmalıdır .

Yukarıdaki diyagram, son uygulamanın çok daha fazla süreç içerebileceği anlamında şematiktir: önbellekleri yönetmek, bağlantı trafiğini görüntülemek, çıktıyı izlemek vb. için diğer süreçler arasına süreçler eklenebilir. Ayrıca şemadaki bloklar "alt ağları" temsil edebilir - bir veya daha fazla açık bağlantıya sahip küçük ağlar.

Diğer paradigmalar ve metodolojilerle karşılaştırma

Jackson Yapılandırılmış Programlama (JSP) ve Jackson Sistem Geliştirme (JSD)

Bu metodoloji, bir programın tek bir prosedürel alt program hiyerarşisi olarak yapılandırılması gerektiğini varsayar. Başlangıç ​​noktası, uygulamayı giriş ve çıkış veri yapılarına dayalı bir dizi "ana hat" olarak tanımlamaktır. Bu "ana hatlardan" biri daha sonra tüm programı yürütmek için seçilir ve diğerlerinin onları alt programlara dönüştürmek için "ters çevrilmesi" gerekir (dolayısıyla "Jackson inversiyonu" adı verilir). Bu bazen, programın birden çok programa veya eşyordamlara bölünmesini gerektiren "çatışma" ile sonuçlanır. FBP kullanılırken, her FBP bileşeni ayrı bir "ana hat" olarak kabul edilebileceğinden, bu tersine çevirme işlemi gerekli değildir.

FBP ve JSP, bir programı (veya bazı bileşenleri) bir giriş akışının ayrıştırıcısı olarak ele alma kavramını paylaşır .

Jackson'ın sonraki çalışmasında, Jackson System Development (JSD), fikirler daha da geliştirildi.

JSD'de tasarım, son uygulama aşamasına kadar bir ağ tasarımı olarak korunur. Model daha sonra mevcut işlemcilerin sayısına göre bir dizi ardışık sürece dönüştürülür. Jackson, bu adımdan önce var olan ağ modelini doğrudan yürütme olasılığını kitabının 1.3 bölümünde (italikler eklenmiştir):

Sistem Zamanlaması adımının sonunda üretilen belirtim, prensipte doğrudan yürütülebilir. Gerekli ortam, her işlem için bir işlemci, her veri akışı için sınırsız bir arabelleğe eşdeğer bir cihaz ve sistemin gerçek dünyaya bağlı olduğu bazı giriş ve çıkış cihazlarını içerecektir. Böyle bir ortam, elbette, yeterince güçlü bir makinede çalışan uygun bir yazılımla sağlanabilir. Bazen, spesifikasyonun bu şekilde doğrudan uygulanması mümkün olabilir ve hatta makul bir seçim olabilir.

FBP, MA Jackson tarafından "Bir eşyordam benzeri mekanizma ile iletişim kuran sıralı süreçlere program ayrıştırma" yöntemini izleyen bir yaklaşım olarak kabul edildi.

uygulamalı programlama

WB Ackerman, uygulamalı bir dili, tüm işlemlerini değerlere uygulanan operatörler aracılığıyla yapan bir dil olarak tanımlar. Bilinen en eski uygulama dili LISP idi.

Bir FBP bileşeni, girdi akım(lar)ını çıktı akım(lar)ına dönüştüren bir fonksiyon olarak kabul edilebilir. Bu işlevler daha sonra burada gösterildiği gibi daha karmaşık dönüşümler yapmak için birleştirilir:

Birini besleyen iki işlev

Akışları gösterildiği gibi küçük harflerle etiketlersek, yukarıdaki diyagram kısaca aşağıdaki gibi gösterilebilir:

c = G(F(a),F(b));

Tıpkı işlevsel gösterimde olduğu gibi, yalnızca değerlerle çalıştığı ve bu nedenle yan etkisi olmadığı için F iki kez kullanılabilir, FBP'de belirli bir bileşenin iki örneği birbiriyle aynı anda çalışıyor olabilir ve bu nedenle FBP bileşenlerinin yan etkileri olmamalıdır. herhangi biri. İşlevsel gösterim, bir FBP ağının en azından bir bölümünü temsil etmek için açıkça kullanılabilir.

O zaman FBP bileşenlerinin kendilerinin fonksiyonel notasyon kullanılarak ifade edilip edilemeyeceği sorusu ortaya çıkar. WH Burge, özyinelemeli, uygulamalı bir programlama stili kullanılarak akış ifadelerinin nasıl geliştirilebileceğini gösterdi, ancak bu çalışma atomik değerler (akımlar) açısından yapıldı. FBP'de, yapılandırılmış veri parçalarını (FBP IP'leri) tanımlayabilmek ve işleyebilmek gerekir.

Ayrıca, çoğu uygulamalı sistem, tüm verilerin aynı anda bellekte mevcut olduğunu varsayar, oysa FBP uygulamalarının hala sınırlı kaynakları kullanırken uzun süreli veri akışlarını işleyebilmesi gerekir. Friedman ve Wise , Burge'un çalışmasına "tembel eksiler" kavramını ekleyerek bunu yapmanın bir yolunu önerdiler . Bu, "eksileri" argümanlarının her ikisinin de aynı anda mevcut olması gerekliliğini ortadan kaldırdı. "Tembel eksiler", her iki argümanı da gerçekleşene kadar aslında bir akış oluşturmaz - bundan önce sadece bunu yapmak için bir "söz" kaydeder. Bu, bir akışın önden dinamik olarak gerçekleştirilmesine, ancak gerçekleştirilmemiş bir arka uç ile gerçekleştirilmesine izin verir. Akışın sonu, sürecin en sonuna kadar gerçekleşmeden kalırken, başlangıcı sürekli uzayan bir öğeler dizisidir.

Linda

FBP'deki kavramların çoğu, yıllar içinde farklı sistemlerde bağımsız olarak keşfedilmiş görünüyor. Yukarıda bahsedilen Linda, bunlardan biridir. İki teknik arasındaki fark, Linda "piranhalar okulu" yük dengeleme tekniği ile gösterilmektedir - FBP'de bu, talepleri bekleyen en az sayıda IP'ye sahip bir listedeki bileşene yönlendiren ekstra bir "yük dengeleyici" bileşeni gerektirir. işlendi. Açıkça FBP ve Linda yakından ilişkilidir ve biri diğerini simüle etmek için kolayca kullanılabilir.

Nesne yönelimli programlama

OOP'deki bir nesne, hem bilgi hem de davranış içeren yarı özerk bir birim olarak tanımlanabilir. Nesneler, esasen alt program çağrıları olan ve alıcı nesnenin ait olduğu sınıf aracılığıyla dolaylı olarak yapılan "yöntem çağrıları" aracılığıyla iletişim kurar. Nesnenin dahili verilerine yalnızca yöntem çağrıları aracılığıyla erişilebilir, bu nedenle bu bir tür bilgi gizleme veya "kapsülleme"dir. Bununla birlikte, kapsülleme OOP'den önce gelir - David Parnas 70'lerin başında bununla ilgili ufuk açıcı makalelerden birini yazdı - ve hesaplamada temel bir kavramdır. Kapsülleme, bir kara kutu olarak düşünülebilecek bir FBP bileşeninin özüdür ve girdi verilerinin bir miktar çıktı verilerine dönüştürülmesini gerçekleştirir. FBP'de, bir bileşenin belirtiminin bir parçası, kabul edebileceği ve üreteceği veri biçimleri ve akış yapılarıdır. Bu , sözleşmeye dayalı bir tasarım biçimi oluşturur . Ayrıca, bir IP'deki verilere yalnızca o anda sahip olunan işlem tarafından doğrudan erişilebilir. Kapsülleme, dış süreçlerin iç süreçleri korumasını sağlayarak ağ düzeyinde de uygulanabilir.

C. Ellis ve S. Gibbs'in bir makalesi, aktif nesneler ile pasif nesneler arasında ayrım yapıyor . Pasif nesneler, yukarıda belirtildiği gibi bilgi ve davranışı içerir, ancak bu davranışın zamanlamasını belirleyemezler . Aktif nesneler ise bunu yapabilir. Ellis ve Gibbs makalelerinde aktif nesnelerin, pasif nesnelerden çok daha fazla sürdürülebilir sistemler geliştirme potansiyeline sahip olduğunu belirtiyor. Bir FBP uygulaması, FBP süreçlerinin aktif nesnelere karşılık geldiği, IP'lerin ise pasif nesnelere karşılık geldiği bu iki tür nesnenin bir kombinasyonu olarak görülebilir.

Aktör modeli

FBP, Carl Hewitt'in Aktörünü 2 portlu asenkron bir süreç olarak değerlendirir: biri giriş mesajları ve diğeri kontrol sinyalleri için. Her yürütme turundan sonra aktörün kendisi tarafından bir kontrol sinyali yayınlanır. Bu sinyalin amacı, aktörün vücudunun paralel yürütülmesini önlemek ve böylece aktör nesnesinin alanlarına senkronizasyon olmadan erişime izin vermektir.

Ayrıca bakınız

Referanslar

Dış bağlantılar