وصف بنية البرمجيات

وصف بنية البرمجيات هو مجموعة من الممارسات للتعبير عن بنية البرمجيات وتوصيلها وتحليلها (يسمى أيضًا العرض المعماري)، ونتيجة تطبيق هذه الممارسات من خلال منتج عمل يعبر عن بنية البرمجيات ( ISO/IEC/IEEE 42010 ).

تُعرف أوصاف البنية (ADs) أحيانًا أيضًا باسم تمثيلات البنية ، أو مواصفات البنية [ 1 ] أو وثائق بنية البرمجيات .

المفاهيم

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

غالبًا ما تُنظَّم نماذج وصف بنية النظام في وجهات نظر متعددة ، بحيث "تُعالج كل وجهة نظر اهتمامات محددة تهم مختلف أصحاب المصلحة في النظام". [ 2 ] وجهة نظر بنية النظام هي طريقة للنظر إلى النظام ( RM ODP ). يجب أن تتضمن كل وجهة نظر في وصف بنية النظام توثيقًا للاهتمامات وأصحاب المصلحة الذين تُوجَّه إليهم، وأنواع النماذج، والرموز، واتفاقيات النمذجة التي تستخدمها ( ISO/IEC/IEEE 42010 ).

على الرغم من فعالية استخدام وجهات نظر متعددة في التواصل مع مختلف الجهات المعنية وتسجيل وتحليل مختلف الشواغل، إلا أنه يثير بعض المشكلات المحتملة: فبما أن وجهات النظر عادةً ما تكون غير مستقلة، فإن احتمال التداخل يعني وجود تكرار أو تناقض بين وجهات نظر النظام الواحد. [ 3 ] ويمكن استخدام آليات متنوعة لتحديد وإدارة أوجه التشابه بين وجهات النظر لتبادل التفاصيل، والحد من التكرار، وضمان الاتساق.

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

تاريخ

استخدمت أقدم أوصاف البنية صورًا ومخططات غير رسمية ونصوصًا مصاحبة لها. ولا تزال الأوصاف غير الرسمية هي الأكثر استخدامًا في الصناعة. [ 4 ] وقد تأثر وصف البنية بمجالات هندسة البرمجيات (مثل تجريد البيانات والبرمجة على نطاق واسع) وتصميم الأنظمة (مثل SARA [ 5 ] ).

ركزت الدراسات المتعلقة بالبرمجة على نطاق واسع، مثل لغات ربط الوحدات (MILs)، على التعبير عن خصائص البرمجيات واسعة النطاق: [ 6 ] الوحدات (بما في ذلك البرامج والمكتبات والروتينات الفرعية والأنظمة الفرعية) وعلاقات الوحدات (التبعيات والترابطات بين الوحدات). وقد أثر هذا العمل على كلٍ من التفكير المعماري في لغات البرمجة (مثل لغة Ada)، ورموز التصميم والمعمارية (مثل مخططات Buhr وخرائط حالات الاستخدام، والمُضمنة في السمات المعمارية للغة UML: الحزم والأنظمة الفرعية والتبعيات)، وجزء كبير من العمل على لغات وصف المعمارية. بالإضافة إلى لغات ربط الوحدات، وتحت تأثير الأعمال الناضجة في مجالي المتطلبات والتصميم ضمن هندسة البرمجيات، تم استخلاص أنواع مختلفة من النماذج من هندسة البرمجيات وتصميمها لتطبيقها على وصف المعماريات. وشملت هذه النماذج نماذج الوظائف والأنشطة من التحليل الهيكلي (SADT) ، وتقنيات نمذجة البيانات (علاقة الكيان)، وتقنيات البرمجة الكائنية.

استشهد بيري وولف [ 1 ] بسابقة هندسة المباني لدور وجهات النظر المتعددة: "يعمل مهندس المباني مع العميل من خلال عدد من وجهات النظر المختلفة التي يتم فيها التأكيد على جانب معين من المبنى".

افترض بيري وولف أن تمثيل البنى يجب أن يشمل: {العناصر والشكل والأساس المنطقي} ، مع التمييز بين ثلاثة أنواع من العناصر (وبالتالي ثلاثة أنواع من وجهات النظر):

  • المعالجة: كيفية تحويل البيانات؛
  • البيانات: المعلومات التي يتم استخدامها وتحويلها؛
  • الربط: مادة لاصقة تربط العناصر الأخرى معًا؛

حدد بيري وولف أربعة أهداف أو استخدامات لأوصاف الهندسة المعمارية (المسماة "مواصفات الهندسة المعمارية" في ورقتهم البحثية):

  • تحديد القيود المعمارية دون الإفراط في تحديد الحلول
  • افصل بين الجماليات والهندسة
  • التعبير عن جوانب مختلفة من الهندسة المعمارية، كلٌّ منها بطريقة مناسبة.
  • إجراء تحليل معماري، وخاصة تحليلات التبعية والاتساق

بعد ورقة بيري وولف، ظهرت مدرستان فكريتان حول وصف بنية البرمجيات :

  • مدرسة متعددة وجهات النظر
  • المدرسة البنيوية

آليات وصف البنية

توجد عدة آليات شائعة الاستخدام لوصف بنية الأنظمة. وتسهل هذه الآليات إعادة استخدام أساليب الوصف الناجحة بحيث يمكن تطبيقها على العديد من الأنظمة:

  • وجهات نظر معمارية
  • لغات وصف البنية
  • أطر معمارية

وجهات نظر معمارية

تُصنَّف أوصاف بنية البرمجيات عادةً في واجهات ، تُشابه أنواع المخططات المختلفة المستخدمة في هندسة المباني . تتناول كل واجهة مجموعة من اهتمامات النظام، وفقًا لاتفاقيات وجهة نظرها ، حيث تُعرَّف وجهة النظر بأنها مواصفة تصف الرموز وتقنيات النمذجة المستخدمة في واجهة ما للتعبير عن البنية المعنية من منظور مجموعة معينة من أصحاب المصلحة واهتماماتهم ( ISO/IEC 42010 ). لا تقتصر وجهة النظر على تحديد الاهتمامات المطروحة (أي التي يجب معالجتها) فحسب، بل تشمل أيضًا طريقة العرض، وأنواع النماذج المستخدمة، والاتفاقيات المتبعة، وأي قواعد اتساق (توافق) للحفاظ على اتساق الواجهة مع الواجهات الأخرى.

ومن أمثلة وجهات النظر ما يلي:

  • وجهة نظر وظيفية
  • وجهة نظر منطقية
  • وجهة نظر المعلومات/البيانات
  • وجهة نظر الوحدة
  • وجهة نظر المكونات والموصلات
  • وجهة نظر المتطلبات
  • وجهة نظر المطور/التنفيذ
  • منظور التزامن/العمليات/وقت التشغيل/الخيوط/التنفيذ
  • نقطة الأداء
  • نقطة أمنية
  • وجهة نظر مادية/نشر/تركيب
  • وجهة نظر المستخدم بشأن الإجراءات/التعليقات

يُستخدم مصطلح "نمط العرض" للإشارة إلى فئات من العروض المتشابهة التي تشترك في مجموعة مشتركة من العناصر والعلاقات. [ 4 ]

لغات وصف الهندسة المعمارية

لغة وصف البنية ( ADL ) هي أي وسيلة تعبير تُستخدم لوصف بنية برمجية ( ISO/IEC/IEEE 42010 ). وقد طُوّرت العديد من لغات وصف البنية المتخصصة منذ تسعينيات القرن الماضي، بما في ذلك AADL (معيار SAE)، وWright (التي طورتها جامعة كارنيجي ميلون)، وAcme (التي طورتها جامعة كارنيجي ميلون)، وxADL (التي طورتها جامعة كاليفورنيا في إرفاين)، و Darwin (التي طورتها كلية إمبريال كوليدج لندن )، وDAOP-ADL (التي طورتها جامعة مالقة)، و ByADL (جامعة لاكويلا، إيطاليا). ركزت لغات وصف البنية المبكرة على نمذجة الأنظمة من حيث مكوناتها وروابطها وتكويناتها. أما لغات وصف البنية الأحدث (مثل ArchiMate وSysML) فقد اتسمت بكونها لغات "واسعة النطاق" قادرة على التعبير ليس فقط عن المكونات والروابط، بل عن مجموعة متنوعة من الجوانب من خلال لغات فرعية متعددة. بالإضافة إلى اللغات ذات الأغراض الخاصة، يمكن استخدام اللغات الموجودة مثل UML كلغات وصفية للأنشطة "لتحليل وتصميم وتنفيذ الأنظمة القائمة على البرمجيات وكذلك لنمذجة الأعمال والعمليات المماثلة".

أطر معمارية

يُجسّد إطار العمل المعماري "الاتفاقيات والمبادئ والممارسات الخاصة بوصف البنى المعمارية المُعتمدة ضمن مجال تطبيق مُحدد و/أو مجتمع من أصحاب المصلحة" ( ISO/IEC/IEEE 42010 ). ويُطبّق إطار العمل عادةً من خلال وجهة نظر واحدة أو أكثر، أو من خلال لغات وصف البنى المعمارية (ADLs). وتشمل أطر العمل ذات الأهمية في هندسة البرمجيات ما يلي:

وجهات نظر متعددة

وقد تم تمثيل هذا النهج في ورقة كروشتن المؤثرة للغاية عام 1995 حول "نموذج الرؤية 4+1" ، حيث أكد على أصحاب المصلحة والاهتمامات المختلفة التي يجب نمذجتها. [ 2 ]

البنيوية

ثانيًا، وكما يتضح في أعمال جامعة كارنيجي ميلون وغيرها، فإن مفهوم أن بنية النظام هي التنظيم عالي المستوى للنظام في وقت التشغيل، وأنه ينبغي وصف بنية النظام من حيث مكوناته وروابطه: "إن بنية نظام البرمجيات تحدد ذلك النظام من حيث المكونات الحسابية والتفاعلات بين تلك المكونات". [ 7 ]

خلال الفترة من تسعينيات القرن الماضي وحتى العقد الأول من الألفية الثانية، تركزت معظم الدراسات الأكاديمية حول لغات وصف البنية (ADLs) ضمن نموذج المكونات والموصلات. مع ذلك، لم يكن لهذه اللغات تأثير يُذكر في الصناعة. [ 8 ] منذ تسعينيات القرن الماضي، شهدت مناهج وصف البنية تقاربًا ملحوظًا، حيث قام معيار IEEE 1471 في عام 2000 بتدوين أفضل الممارسات: دعم وجهات نظر متعددة في وصف البنية، دون اشتراطها.

وصف البنية المعمارية من خلال القرارات

بتوسيع نطاق الجانب المنطقي من صيغة بيري وولف الأصلية، ظهر اتجاه فكري ثالث، يوثق القرارات وأسبابها كطريقة أساسية لتصور بنية البرمجيات والتعبير عنها. [ 9 ] يعامل هذا النهج القرارات كعناصر أساسية في وصف البنية، موضحًا ما كان غالبًا ضمنيًا في التمثيلات السابقة.

استخدامات أوصاف الهندسة المعمارية

تخدم أوصاف البنية مجموعة متنوعة من الأغراض بما في ذلك ( ISO/IEC/IEEE 42010 ):

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

مراجع

  1. 1 2 بيري، دي إي؛ وولف، إيه إل (1992). "أسس دراسة هندسة البرمجيات". ملاحظات هندسة البرمجيات ACM SIGSOFT 17 (4): 40. doi:10.1145/141874.141884
  2. 1 2 ب. ب. كروشتن، "نموذج عرض '4+1' للهندسة المعمارية"، مجلة IEEE Software، المجلد 12، العدد 6، الصفحات 42-50، نوفمبر 1995
  3. أ. فينكلشتاين، ج. كرامر، ب. نوسيبة، ل. فينكلشتاين، و م. غوديكه. وجهات النظر: إطار عمل لدمج وجهات نظر متعددة في تطوير الأنظمة. المجلة الدولية لهندسة البرمجيات وهندسة المعرفة، 2(1):31-58، 1992.
  4. 1 2 بي. سي. كليمنتس، إف. باخمان، إل. باس، دي. جارلان، جيه. إيفرز، آر. ليتل، آر. نورد، وجيه. ستافورد، توثيق بنى البرمجيات: وجهات نظر وما بعدها. أديسون ويسلي، 2003.
  5. G. Estrin , RS Fenchel, RR Razouk, MK Vernon , "The System Architect 's Apprentice " , IEEE Transactions of Software Engineering, 1986.
  6. F. DeRemer و HH Kron، "البرمجة على نطاق واسع مقابل البرمجة على نطاق صغير"، معاملات IEEE في هندسة البرمجيات، 1976.
  7. م. شو ود. جارلان، هندسة البرمجيات: منظورات حول تخصص ناشئ، برنتيس هول، 1996.
  8. إي. وودز و ر. هيليارد، "لغات وصف البنية في الممارسة العملية" http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
  9. أ. جانسن وج. بوش، "هندسة البرمجيات كمجموعة من قرارات التصميم المعماري" وقائع المؤتمر الخامس لـ IEEE/IFIP حول هندسة البرمجيات، 2005.

انظر أيضاً