البرمجة القائمة على التدفق

📅 آخر تحديث: ١٧ يوليو ٢٠٢٦
✍️ نُشر في: ١٧ يوليو ٢٠٢٦
📷 يحتوي على 6 صور
الموسوعة الحرة

في برمجة الحاسوب ، تُعدّ البرمجة القائمة على التدفق ( FBP ) نموذجًا برمجيًا يُعرّف التطبيقات على أنها شبكات من العمليات المغلقة ، التي تتبادل البيانات عبر اتصالات مُحددة مسبقًا من خلال تمرير الرسائل ، حيث تُحدد هذه الاتصالات خارجيًا . ويمكن إعادة ربط هذه العمليات المغلقة بلا حدود لتشكيل تطبيقات مختلفة دون الحاجة إلى تغييرها داخليًا. ولذلك، فإن البرمجة القائمة على التدفق (FBP) موجهة بطبيعتها نحو المكونات .

FBP هو شكل خاص من أشكال برمجة تدفق البيانات يعتمد على المخازن المؤقتة المحدودة، وحزم المعلومات ذات فترات العمر المحددة، والمنافذ المسماة، والتعريف المنفصل للاتصالات.

مقدمة

تُعرّف البرمجة القائمة على التدفق التطبيقات باستخدام استعارة "مصنع البيانات". فهي لا تنظر إلى التطبيق كعملية واحدة متسلسلة تبدأ عند نقطة زمنية محددة، ثم تُنفّذ مهمة واحدة في كل مرة حتى تنتهي، بل كشبكة من العمليات غير المتزامنة التي تتواصل عبر تدفقات من أجزاء البيانات المهيكلة، والتي تُسمى "حزم المعلومات" (IPs). في هذا المنظور، ينصب التركيز على بيانات التطبيق والتحويلات المُطبقة عليها لإنتاج المخرجات المطلوبة. تُعرّف الشبكة خارجياً بالنسبة للعمليات، كقائمة اتصالات يُفسّرها برنامج يُسمى عادةً "المُجدوِل".

تتواصل العمليات عبر اتصالات ذات سعة ثابتة. يُربط الاتصال بعملية ما عبر منفذ ، يحمل اسمًا متفقًا عليه بين كود العملية وتعريف الشبكة. يمكن لأكثر من عملية تنفيذ نفس جزء الكود. في أي لحظة، لا يمكن أن يكون عنوان IP معين "مملوكًا" إلا لعملية واحدة، أو أن يكون قيد النقل بين عمليتين. قد تكون المنافذ بسيطة أو من نوع المصفوفة، كما هو مستخدم، على سبيل المثال، لمنفذ الإدخال لمكون التجميع الموصوف أدناه. إن الجمع بين المنافذ والعمليات غير المتزامنة هو ما يسمح بدعم العديد من وظائف معالجة البيانات الأساسية طويلة الأمد، مثل الفرز والدمج والتلخيص، وما إلى ذلك، في شكل صناديق سوداء برمجية .

نظراً لأن عمليات FBP يمكنها الاستمرار في التنفيذ طالما توفرت لديها بيانات للعمل عليها ومكان لتخزين مخرجاتها، فإن تطبيقات FBP تعمل عموماً في وقت أقل من البرامج التقليدية، وتستغل جميع المعالجات الموجودة على الجهاز على النحو الأمثل، دون الحاجة إلى برمجة خاصة لتحقيق ذلك. [ 1 ]

عادةً ما يكون تعريف الشبكة تخطيطيًا، ويُحوّل إلى قائمة اتصالات بلغة أو ترميز منخفض المستوى. غالبًا ما تكون FBP لغة برمجة مرئية على هذا المستوى. أما تعريفات الشبكات الأكثر تعقيدًا، فتتسم ببنية هرمية، حيث تُبنى من شبكات فرعية ذات اتصالات "ثابتة". تعتمد العديد من لغات/بيئات تشغيل التدفق الأخرى على لغات برمجة أكثر تقليدية، وأبرز مثال على ذلك RaftLib التي تستخدم عوامل تشغيل شبيهة بـ iostream في لغة C++ لتحديد مخطط التدفق.

تتشابه لغة FBP إلى حد كبير مع لغة Linda [ 2 ] ، فهي، وفقًا لمصطلحات جيليرنتر وكارييرو، "لغة تنسيق": [ 3 ] وهي مستقلة عن اللغة بشكل أساسي. في الواقع، عند استخدام مُجدوِل مكتوب بلغة منخفضة المستوى، يمكن ربط المكونات المكتوبة بلغات مختلفة معًا في شبكة واحدة. وبالتالي، تُناسب FBP مفهوم اللغات الخاصة بالمجال أو "اللغات المصغرة".

يُظهر نموذج FBP "ترابط البيانات"، الذي وُصف في مقال الترابط بأنه أضعف أنواع الترابط بين المكونات. ويرتبط مفهوم الترابط الضعيف بدوره بمفهوم البنى الموجهة نحو الخدمات ، ويتوافق نموذج FBP مع عدد من معايير هذه البنية، وإن كان ذلك على مستوى أدق من معظم أمثلة هذه البنية.

يشجع منهج FBP على استخدام أسلوب وظيفي رفيع المستوى في المواصفات، مما يُسهّل فهم سلوك النظام. ومن الأمثلة على ذلك نموذج تدفق البيانات الموزع لتحديد وتحليل دلالات البروتوكولات الموزعة متعددة الأطراف بشكل بنّاء.

تاريخ

ابتكر ج. بول موريسون البرمجة القائمة على التدفق في أوائل سبعينيات القرن العشرين، وطُبقت مبدئيًا في برنامج لأحد البنوك الكندية. [ 4 ] تأثرت هذه البرمجة في بدايتها بشدة ببعض لغات المحاكاة التي طورتها شركة IBM في تلك الفترة، ولا سيما لغة GPSS ، لكن جذورها تعود إلى ورقة كونواي الرائدة حول ما أسماه بالروتينات الفرعية . [ 5 ]

خضع نظام FBP لعدة تغييرات في الاسم على مر السنين: كان يُطلق على التطبيق الأصلي اسم AMPS (نظام المعالجة المعياري المتقدم). تم إطلاق أحد تطبيقاته الكبيرة في كندا عام 1975، ومنذ عام 2013، وهو قيد الاستخدام الإنتاجي المستمر، ويعمل يوميًا، لما يقرب من 40 عامًا. ولأن شركة IBM اعتبرت الأفكار الكامنة وراء FBP "أشبه بقانون طبيعي" بحيث لا يمكن تسجيل براءة اختراع لها، فقد طرحت بدلاً من ذلك المفاهيم الأساسية لـ FBP في المجال العام، من خلال نشرة فنية بعنوان "نظام برمجة المهام المعياري المتداخل والمستجيب للبيانات" [ 6 ] عام 1971. [ 4 ] ونُشرت مقالة تصف مفاهيمه وتجربة استخدامه عام 1978 في مجلة IBM Systems Journal التابعة لأبحاث IBM تحت اسم DSLM. [ 7 ] تم تنفيذ تطبيق ثان كمشروع مشترك بين IBM Canada و IBM Japan، تحت اسم "Data Flow Development Manager" (DFDM)، وتم تسويقه لفترة وجيزة في اليابان في أواخر الثمانينيات تحت اسم "Data Flow Programming Manager".

بشكل عام، كانت المفاهيم يشار إليها داخل شركة IBM باسم "تدفق البيانات"، ولكن تم اعتبار هذا المصطلح عامًا جدًا، وفي النهاية تم اعتماد اسم "البرمجة القائمة على التدفق".

منذ أوائل الثمانينيات وحتى عام ١٩٩٣، قام كلٌ من جيه بول موريسون ومهندس شركة آي بي إم، واين ستيفنز، بتطوير ونشر المفاهيم الكامنة وراء منهجية FBP. كتب ستيفنز العديد من المقالات التي تشرح وتدعم مفهوم FBP، وأدرج موادًا عنه في عدد من كتبه. [ ٨ ] [ ٩ ] [ ١٠ ] . في عام ١٩٩٤، نشر موريسون كتابًا يشرح فيه منهجية FBP، ويقدم أدلة تجريبية على أنها أدت إلى تقليل أوقات التطوير. [ ١١ ]

المفاهيم

يوضح الرسم التخطيطي التالي العناصر الرئيسية لمخطط FBP (باستثناء حزم المعلومات). يمكن تحويل هذا المخطط مباشرةً إلى قائمة اتصالات، والتي يمكن تنفيذها بعد ذلك بواسطة محرك مناسب (برنامج أو جهاز).

مخطط FBP بسيط

A وB وC هي عمليات تُنفّذ مكونات برمجية. O1 وO2 وIN هما منفذان يربطان الاتصالين M وN بالعمليات الخاصة بهما. يُسمح للعمليتين B وC بتنفيذ نفس الكود، لذا يجب أن تمتلك كل عملية مجموعة خاصة بها من مساحة التخزين العاملة، وكتل التحكم، وما إلى ذلك. سواءً تشاركتا الكود أم لا، يحق لـB وC استخدام نفس أسماء المنافذ، لأن أسماء المنافذ لا معنى لها إلا داخل المكونات التي تشير إليها (وعلى مستوى الشبكة بالطبع).

M و N هما ما يشار إليه غالبًا باسم " المخازن المؤقتة المحدودة "، ولهما سعة ثابتة من حيث عدد عناوين IP التي يمكنهما الاحتفاظ بها في أي وقت.

يُتيح مفهوم المنافذ استخدام المكون نفسه في أكثر من موقع في الشبكة. وبالاقتران مع خاصية تحديد المعلمات، المعروفة باسم حزم المعلومات الأولية (IIPs)، تُوفر المنافذ لـ FBP إمكانية إعادة استخدام المكونات، مما يجعل FBP بنيةً قائمة على المكونات . وبذلك، يُجسد FBP ما أطلق عليه راؤول دي كامبو ونيت إدواردز من قسم أبحاث IBM مصطلح "النمطية القابلة للتكوين" .

تُخصص حزم المعلومات أو عناوين IP فيما يُمكن تسميته "مساحة IP" (تمامًا كما تُخصص مجموعات ليندا في "مساحة المجموعات")، ولها عمر افتراضي محدد حتى يتم التخلص منها واستعادة مساحتها - في FBP، يجب أن يكون هذا إجراءً صريحًا من جانب العملية المالكة. تُشكل عناوين IP التي تنتقل عبر اتصال معين (في الواقع، هي "مقابضها" التي تنتقل) "تيارًا"، يتم إنشاؤه واستهلاكه بشكل غير متزامن - وبالتالي، فإن هذا المفهوم يُشابه مفهوم lazy cons الموصوف في مقالة فريدمان ووايز عام 1976. [ 12 ]

عادةً ما تكون عناوين IP عبارة عن أجزاء منظمة من البيانات، إلا أن بعضها قد لا يحتوي على أي بيانات حقيقية، وإنما يُستخدم فقط كإشارات. ومن الأمثلة على ذلك "عناوين IP المُجمّعة"، والتي تُستخدم لتجميع عناوين IP الخاصة بالبيانات في أنماط متسلسلة ضمن تدفق يُسمى "التدفقات الفرعية". وقد تكون التدفقات الفرعية بدورها متداخلة. كما يمكن ربط عناوين IP معًا لتشكيل "أشجار IP"، التي تنتقل عبر الشبكة ككائنات منفردة.

يمكن توسيع نظام الاتصالات والعمليات الموصوف أعلاه إلى أي حجم. أثناء تطوير التطبيق، يمكن إضافة عمليات مراقبة بين أزواج العمليات، أو تقسيم العمليات إلى شبكات فرعية، أو استبدال محاكاة العمليات بمنطق العملية الحقيقي. لذلك، يُعدّ FBP مناسبًا للنماذج الأولية السريعة .

هذه صورةٌ تُشبه خط التجميع في معالجة البيانات: يمكن اعتبار وحدات المعالجة التي تنتقل عبر شبكة من العمليات بمثابة أدوات تنتقل من محطة إلى أخرى في خط التجميع. ويمكن إعادة توصيل هذه "الأجهزة" بسهولة، وإخراجها من الخدمة للصيانة، واستبدالها، وما إلى ذلك. ومن الغريب أن هذه الصورة تُشبه إلى حد كبير صورة معدات تسجيل البيانات التي كانت تُستخدم لمعالجة البيانات قبل ظهور الحواسيب، باستثناء أنه كان لا بد من نقل مجموعات البطاقات يدويًا من جهاز إلى آخر.

قد تكون تطبيقات FBP غير استباقية أو استباقية - تميل التطبيقات السابقة إلى أن تكون غير استباقية (الحاسوب المركزي ولغة C)، في حين أن أحدث تطبيق Java (انظر أدناه) يستخدم فئة Java Thread وهو استباقي.

أمثلة

مشكلة التلغراف

غالبًا ما تُشكّل مُكوّنات FBP أزواجًا مُتكاملة. يستخدم هذا المثال زوجين من هذا النوع. تبدو المُشكلة الموصوفة بسيطةً للغاية عند شرحها لفظيًا، ولكنها في الواقع صعبةٌ بشكلٍ مُفاجئ عند حلّها باستخدام المنطق الإجرائي التقليدي. تُعرف هذه المُشكلة باسم "مُشكلة التلغراف"، والتي وصفها بيتر نور في الأصل ، وتتمثل في كتابة برنامج يستقبل أسطرًا نصية ويُنتج أسطرًا مُخرجة تحتوي على أكبر عددٍ مُمكن من الكلمات، بحيث لا يتجاوز عدد الأحرف في كل سطر طولًا مُعينًا. لا يُمكن تقسيم الكلمات، ونفترض أن طول أي كلمة لا يتجاوز طول الأسطر المُخرجة. يُشابه هذا مُشكلة التفاف الكلمات في مُحررات النصوص. [ 13 ]

في المنطق التقليدي، يكتشف المبرمج سريعًا أنه لا يمكن استخدام هياكل الإدخال ولا الإخراج لتوجيه تسلسل استدعاءات تدفق التحكم . أما في FBP، من ناحية أخرى، فإن وصف المشكلة نفسه يوحي بالحل.

  • تم ذكر "الكلمات" بشكل صريح في وصف المشكلة، لذلك من المعقول أن يتعامل المصمم مع الكلمات على أنها حزم معلومات (IPs).
  • في FBP لا يوجد تسلسل هرمي واحد للاستدعاء، لذلك لا يميل المبرمج إلى فرض نمط فرعي من الحل ليكون المستوى الأعلى.

هذا هو الحل الأكثر طبيعية في FBP (لا يوجد حل "صحيح" واحد في FBP، لكن هذا يبدو مناسبًا بشكل طبيعي):

مشكلة بيتر نور مع التلغراف

حيث يرمز DC و RC إلى "DeCompose" و "ReCompose" على التوالي.

كما ذُكر أعلاه، يمكن استخدام حزم المعلومات الأولية (IIPs) لتحديد معلومات بارامترية مثل طول سجل الإخراج المطلوب (المطلوب من قبل المكونين الأخيرين)، أو أسماء الملفات. حزم المعلومات الأولية هي أجزاء بيانات مرتبطة بمنفذ في تعريف الشبكة، وتتحول إلى عناوين IP "عادية" عند إصدار أمر "استلام" للمنفذ ذي الصلة.

تحديث مجمع

يتضمن هذا النوع من البرامج تمرير ملف "تفاصيل" (تغييرات، إضافات، وحذف) إلى "ملف رئيسي"، وإنتاج (على الأقل) ملف رئيسي مُحدَّث، وتقرير واحد أو أكثر. تُعدّ برامج التحديث صعبة البرمجة عمومًا باستخدام التعليمات البرمجية الإجرائية المتزامنة، إذ يجب الحفاظ على تزامن تدفقين (أو أكثر أحيانًا) من المدخلات، حتى وإن وُجدت ملفات رئيسية بدون تفاصيل مُقابلة، أو العكس.

بنية "التحديث الدفعي" الكلاسيكية

في FBP، يُسهّل مُكوّن قابل لإعادة الاستخدام (Collate)، قائم على فكرة سجل الوحدة في المُجمِّع، كتابة هذا النوع من التطبيقات بشكل كبير، حيث يقوم Collate بدمج التدفقين وإدراج عناوين IP بين قوسين للإشارة إلى مستويات التجميع، مما يُبسّط منطق المعالجة اللاحقة بشكل ملحوظ. لنفترض أن أحد التدفقين ("masters" في هذه الحالة) يتكون من عناوين IP بقيم مفتاحية 1 و2 و3، وأن التدفق الثاني ("details") له قيم مفتاحية 11 و12 و21 و31 و32 و33 و41، حيث يُشير الرقم الأول إلى قيم المفتاح الرئيسي. باستخدام أحرف الأقواس لتمثيل عناوين IP "بين قوسين"، سيكون تدفق الإخراج المُجمَّع كما يلي:

( م1 د11 د12 ) ( م2 د21 ) ( م3 د31 د32 د33 ) (د41)

وبما أنه لم يكن هناك عنصر رئيسي بقيمة 4، فإن المجموعة الأخيرة تتكون من تفصيل واحد (بالإضافة إلى الأقواس).

يمكن وصف بنية التدفق المذكور أعلاه بإيجاز باستخدام تدوين مشابه لـ BNF مثل:

{ ( [m] d* ) }*

Collate عبارة عن صندوق أسود قابل لإعادة الاستخدام ، لا يحتاج إلا إلى معرفة مواقع حقول التحكم في وحدات المعالجة الواردة (وحتى هذا ليس ضروريًا تمامًا، إذ يمكن إدراج عمليات تحويل في المراحل السابقة لوضع حقول التحكم في مواقع قياسية). ويمكن تعميمه ليشمل أي عدد من تدفقات الإدخال، وأي عمق لتداخل الأقواس. يستخدم Collate منفذًا من نوع المصفوفة للإدخال، مما يسمح بعدد متغير من تدفقات الإدخال.

عمليات تعدد الإرسال

يدعم البرمجة القائمة على التدفق تعدد العمليات بطريقة طبيعية للغاية. وبما أن المكونات للقراءة فقط، يمكن تشغيل أي عدد من مثيلات مكون معين ("عمليات") بشكل غير متزامن مع بعضها البعض.

مثال على تعدد الإرسال

عندما كانت الحواسيب تحتوي عادةً على معالج واحد، كان هذا مفيدًا عند وجود عدد كبير من عمليات الإدخال/الإخراج؛ أما الآن، ومع احتواء الأجهزة عادةً على معالجات متعددة، فقد أصبح هذا مفيدًا أيضًا عند العمليات التي تستهلك موارد المعالج بكثافة. يوضح الرسم التخطيطي في هذا القسم عملية "موازنة الأحمال" التي توزع البيانات بين ثلاث عمليات، مُسماة S1 وS2 وS3 على التوالي، وهي نسخ من مكون واحد، تُغذي بدورها عملية واحدة وفقًا لأسبقية الوصول.

شبكة تفاعلية بسيطة

رسم تخطيطي لتطبيق تفاعلي عام

في هذا المخطط العام، تدخل الطلبات (المعاملات) الواردة من المستخدمين إلى الرسم التخطيطي من أعلى اليسار، وتُعاد الاستجابات من أسفل اليسار. تتواصل "الخوادم الخلفية" (على الجانب الأيمن) مع الأنظمة في مواقع أخرى، باستخدام تقنيات مثل CORBA و MQSeries وغيرها. تمثل الوصلات المتقاطعة الطلبات التي لا تحتاج إلى المرور عبر الخوادم الخلفية، أو الطلبات التي يجب أن تمر عبر الشبكة أكثر من مرة قبل إعادتها إلى المستخدم.

بما أن الطلبات المختلفة قد تستخدم أنظمة خلفية مختلفة، وقد تتطلب فترات زمنية مختلفة للأنظمة الخلفية (إن وجدت) لمعالجتها، فيجب توفير آلية لربط البيانات المُعادة بالمعاملات الطالبة المناسبة، مثل جداول التجزئة أو ذاكرة التخزين المؤقت.

الرسم التخطيطي أعلاه هو رسم تخطيطي بمعنى أن التطبيق النهائي قد يحتوي على العديد من العمليات الأخرى: يمكن إدراج العمليات بين العمليات الأخرى لإدارة ذاكرة التخزين المؤقت، وعرض حركة مرور الاتصال، ومراقبة الإنتاجية، وما إلى ذلك. كما أن الكتل الموجودة في الرسم التخطيطي قد تمثل "شبكات فرعية" - شبكات صغيرة ذات اتصال مفتوح واحد أو أكثر.

مقارنة مع النماذج والمنهجيات الأخرى

برمجة جاكسون الهيكلية (JSP) وتطوير أنظمة جاكسون (JSD)

تعتمد هذه المنهجية على افتراض أن البرنامج يجب أن يُبنى على شكل تسلسل هرمي إجرائي واحد من الإجراءات الفرعية. وتبدأ بوصف التطبيق كمجموعة من "الخطوط الرئيسية"، استنادًا إلى هياكل بيانات الإدخال والإخراج. ثم يُختار أحد هذه "الخطوط الرئيسية" لتوجيه البرنامج بأكمله، بينما تُعكس الخطوط الأخرى لتحويلها إلى إجراءات فرعية (ومن هنا جاء اسم "انعكاس جاكسون"). ينتج عن ذلك أحيانًا ما يُسمى "التعارض"، مما يستدعي تقسيم البرنامج إلى برامج أو إجراءات فرعية متعددة. عند استخدام FBP، لا تكون عملية العكس هذه ضرورية، إذ يُمكن اعتبار كل مكون من مكونات FBP "خطًا رئيسيًا" منفصلًا.

يشترك كل من FBP و JSP في مفهوم التعامل مع البرنامج (أو بعض المكونات) كمحلل لتدفق الإدخال.

في أعمال جاكسون اللاحقة، "تطوير نظام جاكسون " (JSD)، تم تطوير الأفكار بشكل أكبر. [ 14 ] [ 15 ]

في منهجية جاكسون للتصميم (JSD)، يُحافظ على التصميم كشبكة حتى مرحلة التنفيذ النهائية. ثم يُحوّل النموذج إلى مجموعة من العمليات المتسلسلة بعدد المعالجات المتاحة. يناقش جاكسون إمكانية تنفيذ نموذج الشبكة الموجود قبل هذه الخطوة مباشرةً، في القسم 1.3 من كتابه (تمت إضافة الخط المائل).

المواصفات الناتجة في نهاية خطوة توقيت النظام قابلة للتنفيذ المباشر من حيث المبدأ. وتتضمن البيئة اللازمة معالجًا لكل عملية، وجهازًا يُعادل مخزنًا مؤقتًا غير محدود لكل تدفق بيانات، بالإضافة إلى بعض أجهزة الإدخال والإخراج التي تربط النظام بالعالم الخارجي. ويمكن توفير هذه البيئة، بالطبع، بواسطة برنامج مناسب يعمل على جهاز ذي قدرة كافية. وفي بعض الأحيان، يكون التنفيذ المباشر للمواصفات ممكنًا، بل وقد يكون خيارًا مناسبًا. [ 15 ]

تم الاعتراف بـ FBP من قبل MA Jackson كنهج يتبع أسلوبه المتمثل في "تقسيم البرنامج إلى عمليات متسلسلة تتواصل من خلال آلية تشبه الروتين الفرعي" [ 16 ].

البرمجة التطبيقية

يعرّف دبليو بي أكرمان اللغة التطبيقية بأنها اللغة التي تُجري جميع عملياتها باستخدام عوامل تُطبّق على القيم. [ 17 ] وكانت لغة ليسب أقدم لغة تطبيقية معروفة.

يمكن اعتبار مكون FBP بمثابة دالة تحوّل تدفق (تدفقات) الإدخال إلى تدفق (تدفقات) الإخراج. ثم تُدمج هذه الدوال لإجراء تحويلات أكثر تعقيدًا، كما هو موضح هنا:

وظيفتان تغذيان وظيفة واحدة

إذا قمنا بتسمية الجداول، كما هو موضح، بأحرف صغيرة، فيمكن تمثيل الرسم التخطيطي أعلاه بإيجاز على النحو التالي:

ج = ج(ف(أ)،ف(ب))؛

كما هو الحال في الترميز الوظيفي، حيث يمكن استخدام F مرتين لأنه يعمل فقط مع القيم، وبالتالي لا يُحدث أي آثار جانبية، فإنه في FBP يمكن تشغيل نسختين من مكون معين بالتزامن، ولذلك يجب ألا تُحدث مكونات FBP أي آثار جانبية أيضًا. من الواضح أنه يمكن استخدام الترميز الوظيفي لتمثيل جزء على الأقل من شبكة FBP.

يثور التساؤل إذن عما إذا كان بالإمكان التعبير عن مكونات FBP نفسها باستخدام الترميز الوظيفي. وقد أوضح دبليو إتش بيرج كيفية تطوير تعبيرات التدفق باستخدام أسلوب برمجة تكراري تطبيقي، ولكن هذا العمل كان من حيث (تدفقات) القيم الذرية. [ 18 ] في FBP، من الضروري القدرة على وصف ومعالجة أجزاء البيانات المهيكلة (وحدات معالجة FBP).

علاوة على ذلك، تفترض معظم الأنظمة التطبيقية أن جميع البيانات متاحة في الذاكرة في الوقت نفسه، بينما تحتاج تطبيقات FBP إلى معالجة تدفقات البيانات الطويلة مع استخدام موارد محدودة. اقترح فريدمان ووايز طريقةً لتحقيق ذلك بإضافة مفهوم "التحقق الكسول" إلى عمل بيرج. أزال هذا المفهوم شرط توفر وسيطي "cons" في اللحظة نفسها. لا يُنشئ "التحقق الكسول" تدفقًا فعليًا إلا بعد تحقق كلا وسيطيه، وقبل ذلك يُسجل ببساطة "وعدًا" بذلك. يسمح هذا بإنشاء تدفق ديناميكيًا من البداية، مع بقاء نهايته غير مُحققة. تبقى نهاية التدفق غير مُحققة حتى نهاية العملية، بينما تكون بدايته سلسلة متزايدة الطول من العناصر.

ليندا

يبدو أن العديد من مفاهيم FBP قد تم اكتشافها بشكل مستقل في أنظمة مختلفة على مر السنين. ليندا، المذكورة أعلاه، هي إحدى هذه الأنظمة. ويتضح الفرق بين التقنيتين من خلال تقنية موازنة الأحمال "مدرسة أسماك البيرانا" في ليندا - في FBP، تتطلب هذه التقنية مكون "موازنة أحمال" إضافي يقوم بتوجيه الطلبات إلى المكون الموجود في قائمة تحتوي على أقل عدد من عناوين IP المنتظرة للمعالجة. من الواضح أن FBP وليندا مرتبطتان ارتباطًا وثيقًا، ويمكن استخدام إحداهما بسهولة لمحاكاة الأخرى.

البرمجة الكائنية التوجه

يمكن وصف الكائن في البرمجة الكائنية التوجه (OOP) بأنه وحدة شبه مستقلة تتضمن معلومات وسلوكًا. تتواصل الكائنات عبر "استدعاءات الدوال"، وهي في جوهرها استدعاءات للروتينات الفرعية، تتم بشكل غير مباشر عبر الفئة التي ينتمي إليها الكائن المُستقبِل. لا يمكن الوصول إلى البيانات الداخلية للكائن إلا من خلال استدعاءات الدوال، وهذا يُعد شكلًا من أشكال إخفاء المعلومات أو "التغليف". مع ذلك، فإن التغليف أقدم من البرمجة الكائنية التوجه - فقد كتب ديفيد بارناس إحدى المقالات الرائدة حوله في أوائل السبعينيات [ 19 ] - وهو مفهوم أساسي في الحوسبة. يُعد التغليف جوهر مكون FBP، الذي يمكن اعتباره صندوقًا أسود ، يقوم بتحويل بيانات الإدخال إلى بيانات الإخراج. في FBP، يتضمن جزء من مواصفات المكون تنسيقات البيانات وهياكل التدفق التي يمكنه قبولها، وتلك التي سيولدها. وهذا يُشكل شكلًا من أشكال التصميم التعاقدي . بالإضافة إلى ذلك، لا يمكن الوصول إلى البيانات في IP إلا مباشرةً من قِبل العملية المالكة الحالية. يمكن أيضًا تطبيق التغليف على مستوى الشبكة، من خلال جعل العمليات الخارجية تحمي العمليات الداخلية.

تُفرّق ورقة بحثية من تأليف سي. إليس وإس. جيبس ​​بين الكائنات النشطة والكائنات السلبية. [ 20 ] تتضمن الكائنات السلبية المعلومات والسلوك، كما ذُكر سابقًا، لكنها لا تستطيع تحديد توقيت هذا السلوك. أما الكائنات النشطة، فتستطيع ذلك. ويذكر إليس وجيبس في مقالتهما أن الكائنات النشطة لديها إمكانات أكبر بكثير لتطوير أنظمة قابلة للصيانة مقارنةً بالكائنات السلبية. ويمكن النظر إلى تطبيق FBP على أنه مزيج من هذين النوعين من الكائنات، حيث تُقابل عمليات FBP الكائنات النشطة، بينما تُقابل وحدات الملكية الفكرية الكائنات السلبية.

عارض أزياء ممثل

تعتبر خوارزمية FBP الممثل الخاص بكارل هيويت عملية غير متزامنة ذات منفذين: أحدهما لرسائل الإدخال والآخر لإشارات التحكم. يُصدر الممثل نفسه إشارة تحكم بعد كل جولة تنفيذ. والغرض من هذه الإشارة هو تجنب التنفيذ المتوازي لجسم الممثل، وبالتالي السماح بالوصول إلى حقول كائن الممثل دون الحاجة إلى التزامن.

انظر أيضاً

مراجع

  1. ↑ "البرمجة القائمة على التدفق" .
  2. ↑ كاريرو، نيكولاس؛ جيلرنتر، ديفيد (1989). "ليندا في سياقها" . اتصالات رابطة آلات الحوسبة . 32 (4): 444-458 . doi : 10.1145/63334.63337 . S2CID 5900105 . 
  3. ↑ جيلرنتر، ديفيد؛ كاريرو، نيكولاس (1992). "لغات التنسيق وأهميتها". اتصالات رابطة آلات الحوسبة . 35 (2): 97-107 . doi : 10.1145/129630.129635 . S2CID 7748555 . 
  4. 1 2 غابي شتاين (أغسطس 2013). "كيف يمكن لأسلوب برمجة غامض من برامج مصرفية من سبعينيات القرن الماضي أن ينقذ عقول مطوري الويب في كل مكان" . فاست كومباني . تم الاطلاع عليه بتاريخ 24 يناير 2016 .
  5. ↑ كونواي، ميلفين إي. (1963). "تصميم مُجمِّع مخطط انتقالي قابل للفصل" . اتصالات رابطة آلات الحوسبة . 6 (7): 396-408 . doi : 10.1145/366663.366704 . S2CID 10559786 . 
  6. ↑ ج. بول موريسون، نظام برمجة المهام المتداخلة المعياري المستجيب للبيانات، نشرة الإفصاح الفني لشركة IBM، المجلد 13، العدد 8، 2425-2426، يناير 1971
  7. ↑ موريسون، جيه بي (1978). "آلية ربط تدفق البيانات". مجلة أنظمة آي بي إم . 17 (4): 383-408 . doi : 10.1147/sj.174.0383 .
  8. ↑ ستيفنز، دبليو بي (1982). "كيف يمكن لتدفق البيانات تحسين إنتاجية تطوير التطبيقات". مجلة أنظمة آي بي إم . 21 (2): 162-178 . doi : 10.1147/sj.212.0162 .
  9. ↑ دبليو بي ستيفنز، استخدام تدفق البيانات لتطوير التطبيقات ، بايت، يونيو 1985
  10. ↑ دبليو بي ستيفنز، تصميم البرمجيات - المفاهيم والأساليب ، سلسلة هندسة البرمجيات العملية، تحرير ألين ماكرو، برنتيس هول، 1990، رقم ISBN 0-13-820242-7
  11. ↑ جونستون، ويسلي م.؛ حنا، جيه آر بول؛ ميلار، ريتشارد جيه. (2004). "تطورات في لغات برمجة تدفق البيانات". مجلة ACM Computing Surveys . 36 (1): 1–34 . CiteSeerX 10.1.1.99.7265 . doi : 10.1145/1013208.1013209 . S2CID 5257722 .  
  12. ↑ دي بي فريدمان ودي إس وايز، لا ينبغي لـ CONS تقييم حججها، الأوتوماتا واللغات والبرمجة، مطبعة جامعة إدنبرة، إدنبرة، 1976
  13. ↑ "مشكلة التلغراف لبيتر نور"تمت أرشفة هذا النص من المصدر الأصلي بتاريخ 2014-09-06 . تم الاطلاع عليه بتاريخ 2014-09-06 .
  14. ↑ " البرمجة مؤرشفة بتاريخ 2021-12-05 على موقع Wayback Machine " بقلم إم إيه جاكسون، نُشر في وقائع ورشة عمل حول البرمجيات في فيزياء الطاقة العالية، الصفحات 1-12 ، سيرن، جنيف، 4-6 أكتوبر 1982
  15. 1 2 " منهجية تطوير النظام " مؤرشفة بتاريخ 2012-02-06 في Wayback Machine " بقلم إم إيه جاكسون، نُشرت في كتاب أدوات ومفاهيم لبناء البرامج: دورة متقدمة ، مطبعة جامعة كامبريدج، 1982
  16. ↑ " JSP من منظورها" مؤرشفة بتاريخ 16-05-2017 على موقع Wayback Machine " مايكل جاكسون؛ JSP من منظورها؛ في رواد البرمجيات: مساهمات في هندسة البرمجيات؛ مانفريد بروي، إرنست دينرت (محرران)؛ سبرينغر، 2002
  17. ↑ دبليو بي أكرمان، لغات تدفق البيانات ، وقائع المؤتمر الوطني للحاسوب، الصفحات 1087-1095، 1979
  18. ↑ دبليو إتش بيرج، تقنيات البرمجة التكرارية ، أديسون-ويسلي، ريدينغ، ماساتشوستس، 1975
  19. ↑ بارناس، د. ل. (1972). "حول المعايير المستخدمة في تقسيم الأنظمة إلى وحدات" . اتصالات رابطة مكائن ​​الحوسبة . 15 (12): 1053-1058 . doi : 10.1145/361598.361623 . S2CID 53856438 . 
  20. ↑ سي. إليس وإس. جيبس، الكائنات النشطة: الحقائق والإمكانيات ، في مفاهيم وقواعد بيانات وتطبيقات البرمجة الكائنية ، تحرير دبليو. كيم وإف إتش لوخوفسكي، مطبعة إيه سي إم، أديسون ويسلي، 1989
  • رازداو، ألين (ديسمبر 1997). "بناء مصافي بيانات المؤسسات" . DMReview . مؤرشف من الأصل بتاريخ 15 مارس 2005. تم الاطلاع عليه بتاريخ 15 يوليو 2006 .
  • ماير، أنتوني؛ ماكغوف، ستيفن؛ غلام علي، مرتضى؛ يونغ، لوري؛ ستانتون، جيم؛ نيوهوس، ستيفن؛ دارلينغتون، جون (2002). "المعنى والسلوك في المكونات الموجهة بالشبكة" (ملف PDF) . مركز لندن للعلوم الإلكترونية، إمبريال كوليدج للعلوم والتكنولوجيا والطب. مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 4 فبراير 2012.
  • بلاك، أندرو ب.؛ هوانغ، جي؛ كوستر، راينر؛ والبول، جوناثان؛ بو، كالتون (2002). "Infopipes: تجريد لبث الوسائط المتعددة" (ملف PDF) . أنظمة الوسائط المتعددة . 8 (5). سبرينغر-فيرلاغ: 406-419 . doi : 10.1007/s005300200062 . S2CID 5700383. تاريخ الاسترجاع : 10 أغسطس 2006 . 
  • كرا، ديفيد (أكتوبر 2004). "خوادم zSeries و iSeries في مجال الشبكة" . IBM DeveloperWorks . تم الاسترجاع في 13 يوليو 2006 .
  • لوداشر، بيرترام؛ ألتينتاس، إيلكاي؛ بيركلي، تشاد؛ وآخرون  . (سبتمبر 2004). "إدارة سير العمل العلمي ونظام كيبلر" (ملف PDF) . مركز سان دييغو للحوسبة الفائقة . تاريخ الاسترجاع: 14 يوليو 2006 .
  • بيكل، جيري؛ ريتشاردسون، كيفن؛ سميث، جيف (2005). "نظرة عامة على مواصفات راديو البرمجيات OMG للروبوتات" (ملف PDF) . مجموعة إدارة الكائنات - الاتصالات القائمة على البرمجيات. مؤرشف من الأصل (ملف PDF) بتاريخ 14 يوليو 2006. تم الاطلاع عليه بتاريخ 15 يوليو 2006 .
  • بلازيفيتش، ماريو (2006). "مُركِّبات مُكوِّنات التدفق" . وقائع مؤتمر لغات الترميز المتطرفة . مؤرشف من الأصل بتاريخ 18-09-2007 . تم الاطلاع عليه بتاريخ 09-11-2006 .
  • كاولر، باري (1999). تصميم التدفق للأنظمة المدمجة، الطبعة الثانية . كتب البحث والتطوير/ميلر فريمان. رقم ISBN 978-0-87930-555-0.
  • براءة الاختراع الأمريكية رقم 5204965 ، غوثري، سكوت ب.؛ بارث، بول س.؛ وبارستو ، ديفيد ر.، "نظام معالجة البيانات باستخدام مخازن البيانات المتدفقة"، صدرت في 20 أبريل 1993، ومُسجلة باسم شركة شلمبرجير للتكنولوجيا. 
  • موريسون، ج. بول (مارس 2013). "البرمجة القائمة على التدفق" . أخبار مطوري التطبيقات (1). مؤرشف من الأصل بتاريخ 8 أغسطس 2014. تم الاطلاع عليه بتاريخ 25 مايو 2014 .
  • ستابلين، جورج بيتر (2006). "برمجة Tcl القائمة على التدفق - TFP" . تم الاسترجاع في 7 أكتوبر 2010 .
  • جونستون، ويسلي م.؛ حنا، جيه آر بول؛ ميلار، ريتشارد جيه. (مارس 2004). "تطورات في لغات برمجة تدفق البيانات". مجلة ACM Computing Surveys . 36 (1): 1-34 . doi : 10.1145/1013208.1013209 . S2CID 5257722 . 
  • كوستر، راينر؛ بلاك، أندرو ب.؛ هوانغ، جي؛ والبول، جوناثان؛ بو، كالتون (أبريل 2003). "شفافية الخيوط في برمجيات وسيطة لتدفق المعلومات" . البرمجيات: الممارسة والخبرة . 33 (4): 321-349 . CiteSeerX 10.1.1.15.3933 . doi : 10.1002/spe.510 . S2CID 37356020. تاريخ الاسترجاع: 5 ديسمبر 2006 .  
  • ستيفنسون، توني (فبراير 1995). "مراجعة لكتاب "البرمجة القائمة على التدفق"" مجلة PC Update، مجلة مجموعة مستخدمي الكمبيوتر في ملبورن، أستراليا. مؤرشفة من الأصل بتاريخ 25 سبتمبر 2006. تم الاطلاع عليها بتاريخ 6 ديسمبر 2006. "
  • ليا، دوغ (مايو 2001). "تأليف الرسائل أحادية الاتجاه" . مؤرشف من الأصل بتاريخ 7 سبتمبر 2006. تم الاطلاع عليه بتاريخ 6 ديسمبر 2006 .
  • باورس، شون؛ لوداشر، ب.؛ نجو، أ.هـ.هـ .؛ كريتشلو، ت. "تمكين إعادة استخدام سير العمل العلمي من خلال التركيب المنظم لتدفق البيانات وتدفق التحكم" (ملف PDF) . مؤتمر SciFlow '06. مؤرشف من النسخة الأصلية (PDF) بتاريخ 5 فبراير 2007. تم الاطلاع عليه بتاريخ 6 ديسمبر 2006 .
  • سوربر، جاكوب؛ كوستادينوف، ألكسندر؛ غاربر، ماثيو؛ برينان، ماثيو؛ كورنر، مارك د.؛ بيرغر، إيمري د. (2007). "إيون". إيون: لغة ونظام تشغيل للأنظمة الدائمة . وقائع المؤتمر الدولي الخامس حول أنظمة الاستشعار الشبكية المدمجة - الجلسة: إدارة الطاقة. ص  161. doi : 10.1145/1322263.1322279 . ISBN 978-1-59593-763-6. S2CID 12851752 . 
  • فيدلر، لارس؛ داسي، تيموثي (2014). "أنظمة وأساليب التحليلات القابلة للتركيب" . الخدمة الوطنية للمعلومات التقنية. مؤرشف من الأصل بتاريخ 26 أغسطس 2014. تم الاطلاع عليه بتاريخ 1 أبريل 2014 .
  • مات، كاركسي (2014). أنظمة تدفق البيانات والبرمجة التفاعلية: دليل عملي . منصة النشر المستقلة كريت سبيس. رقم ISBN 978-1-4974-2244-5.
  • لامبا، صموئيل؛ داهلو، مارتن؛ ألفارسون، جوناثان؛ سبيوث، أولا (2019). "SciPipe: مكتبة سير عمل لتطوير سريع لخطوط أنابيب المعلوماتية الحيوية المعقدة والديناميكية" . GigaScience . 8 (5). bioRxiv 10.1101/380808 . doi : 10.1093/gigascience/giz044 . PMC 6486472 .