انتقل إلى المحتوى

تطوير مقاد بالسلوك

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

يعرف التطوير مقاد بالسلوك (بالإنجليزية: Behavior-driven development، واختصارًا: BDD)، في هندسة البرمجيات، على أنه عملية تطوير البرمجيات وفقًا لمنهجية أجايل تشجع التعاون بين المطورين ومختبري ضمان الجودة وممثلي العملاء في مشروع برمجي.[1][2][3] يشجع الفرق على استخدام المحادثة والأمثلة العملية لإضفاء الطابع الرسمي على الفهم المشترك لكيفية عمل التطبيق.[4] نشأ من التطوير المقاد بالاختبار (تي دي دي).[5][6][7] يجمع التطوير المقاد بالسلوك بين التقنيات العامة ومبادئ التطوير المقاد بالاختبار مع أفكار من التصميم المقاد بالمجال والتحليل والتصميم كائنيا التوجه لتزويد فرق تطوير وإدارة البرمجيات بأدوات مشتركة وعملية مشتركة للتعاون في تطوير البرمجيات.[2][7]

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

يسهل التطوير المقاد بالسلوك كثيرًا بفضل استخدام لغة مجال محدد (دي إس إل) بسيطة تستخدم تراكيب اللغة الطبيعية (الجمل الشبيهة بالإنجليزية مثلًا) التي يمكن أن تعبر عن السلوك والنتائج المتوقعة. لطالما كانت نصوص الاختبار تطبيقًا شائعًا للغات المجال المحدد بدرجات متفاوتة من التعقيد. يعتبر التطوير المقاد بالسلوك ممارسة تقنية فعالة خاصةً عندما تكون «مساحة المسألة» لمسألة العمل التي يجب حلها معقدة.[8]

مبادئ التطوير المقاد بالسلوك

[عدل]

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

  • تحديد مجموعة اختبار للوحدة أولاً؛
  • جعل الاختبارات تفشل؛
  • ثم تنفيذ الوحدة؛
  • والتحقق أخيرًا من أن تنفيذ الوحدة يجعل الاختبارات تنجح.

يعد هذا التعريف غير محدد نوعًا ما لأنه يسمح بإجراء اختبارات ذو متطلبات برمجية عالية المستوى أو تفاصيل تقنية منخفضة المستوى أو أي شيء بينهما. لذا، تتمثل إحدى طرق تعريف التطور المقاد السلوك في أنه تطور مستمر للتطوير المقاد بالاختبار يتخذ خيارات أكثر تحديدًا من التطوير المقاد بالاختبار. يحدد التطوير المقاد بالسلوك أنه يجب تحديد اختبارات أي وحدة برمجية وفقًا للسلوك المرغوب للوحدة. تتضمن استعارة «السلوك المرغوب» من تطوير البرمجيات وفقًا لأجايل في هذه الحالة المتطلبات التي تحددها الشركة - أي السلوك المرغوب الذي يسند قيمة أعمال لأي كيان مكلف لوحدة البرمجيات قيد الإنشاء. يشار إلى هذا في تطبيق التطوير المقاد بالسلوك، على أنه نشاط «من الخارج إلى الداخل».[1][7][9]

المواصفات السلوكية

[عدل]

يلي هذا الاختيار الأساسي، اختيار ثاني يتخذه التطوير المقاد بالسلوك يتعلق بكيفية تحديد السلوك المطلوب. في هذا المجال، يختار التطوير المقاد بالسلوك استخدام تنسيق شبه رسمي للمواصفات السلوكية المستعارة من مواصفات قصة المستخدم من مجال التحليل والتصميم كائنيا التوجه. يمكن اعتبار جانب السيناريو من هذا التنسيق تطبيق لمنطق هور للمواصفات السلوكية للوحدات البرمجية باستخدام لغة المجال المحدد للحالة.

يحدد التطوير المقاد بالسلوك أنه يجب على محللي الأعمال والمطورين التعاون في هذا المجال وتحديد السلوك وفقًا لقصة المستخدم، التي تدون كل منهما صراحةً في مستند مخصص. يجب أن تتبع كل قصة مستخدم، بطريقة ما، التركيب التالي:[1][5][9]

العنوان

عنوان واضح.

السرد

قسم تمهيدي قصير وفق التركيب التالي:

   باعتباري: الشخص أو الدور المستفاد من الميزة؛

   أريد: الميزة؛

   بحيث: فائدة أو قيمة الميزة.

معايير القبول

وصف لكل سيناريو محدد للسرد وفقًا للتركيب التالي:

نظرًا لأن: السياق الأولي في بداية السيناريو، في بند واحد أو أكثر؛

عندما: الحدث الذي أطلق السيناريو؛

بالتالي: النتيجة المتوقعة، في جملة واحدة أو أكثر.

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

تصاغ السيناريوهات بشكل مثالي تصريحيًا وليس إلزاميًا - بلغة الأعمال، مع عدم الإشارة إلى عناصر واجهة المستخدم التي تتم من خلالها التفاعلات.[10]

يشار إلى هذا التنسيق باسم لغة غيركين، والتي تملك صيغة مشابهة للمثال أعلاه. ولكن، يعد مصطلح غيركين خاص بأدوات برمجيات كيوكامبر، وجيه بيهايف، وليتيس،[11] وبيهايف وبيهات.[12][13][14][15]

المواصفات كلغة سائدة

[عدل]

يستعير التطوير المقاد بالسلوك مفهوم اللغة السائدة من التصميم المقاد بالمجال. تعد اللغة السائدة لغة (شبه) رسمية يتشاركها جميع أعضاء فريق تطوير البرمجيات -مطورو البرمجيات والموظفون غير التقنيين. يستخدم جميع أعضاء الفريق اللغة المعنية ويطوروها كوسيلة مشتركة لمناقشة المجال البرمجي المعني. وبهذه الطريقة يصبح التطوير المقاد بالسلوك وسيلة للتواصل بين جميع الأدوار المختلفة في مشروع برمجي.[5][7][16][17]

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

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

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

انظر أيضًا

[عدل]

مراجع

[عدل]
  1. ^ ا ب ج North، Dan (مارس 2006). "Introducing BDD". Dan North. مؤرشف من الأصل في 2021-05-23. اطلع عليه بتاريخ 2019-04-25.
  2. ^ ا ب "Behaviour-Driven Development". مؤرشف من الأصل في 2015-09-01. اطلع عليه بتاريخ 2012-08-12.
  3. ^ Keogh، Liz (7 سبتمبر 2009). "Introduction to Behavior-Driven Development". SkillsMatter. مؤرشف من الأصل في 2021-02-25. اطلع عليه بتاريخ 2019-05-01.
  4. ^ John Ferguson Smart (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications. ISBN:9781617291654.
  5. ^ ا ب ج د Haring, Ronald (Feb 2011). de Ruiter, Robert (ed.). "Behavior Driven development: Beter dan Test Driven Development". Java Magazine (بالهولندية). Veen Magazines (1): 14–17. ISSN:1571-6236.
  6. ^ Solis، Carlos؛ Wang، Xiaofeng (2011). "A Study of the Characteristics of Behaviour Driven Development". Software Engineering and Advanced Applications (SEAA), 2011 37th EUROMICRO Conference on: 383–387. DOI:10.1109/SEAA.2011.76. hdl:10344/1256. ISBN:978-1-4577-1027-8.
  7. ^ ا ب ج د Bellware، Scott (يونيو 2008). "Behavior-Driven Development". Code Magazine. مؤرشف من الأصل في 2012-07-12. اطلع عليه بتاريخ 2019-05-01.
  8. ^ Tharayil، Ranjith (15 فبراير 2016). "Behavior-Driven Development: Simplifying the Complex Problem Space". SolutionsIQ. مؤرشف من الأصل في 2020-10-21. اطلع عليه بتاريخ 2018-02-15.
  9. ^ ا ب North، Dan (11 فبراير 2007). "What's in a Story?". Dan North. مؤرشف من الأصل في 2021-03-23. اطلع عليه بتاريخ 2012-08-12.
  10. ^ Mabey، Ben. "Imperative vs. Declarative Scenarios in user stories". مؤرشف من الأصل في 2010-06-03. اطلع عليه بتاريخ 2008-05-19.
  11. ^ "nutshell — Lettuce 0.2.23 (kryptonite release) documentation". lettuce.it. مؤرشف من الأصل في 2020-11-01. اطلع عليه بتاريخ 2020-02-06.
  12. ^ "Gherkin". مؤرشف من الأصل في 2021-06-11. اطلع عليه بتاريخ 2020-06-07.
  13. ^ "What is JBehave?". JBehave.org. مؤرشف من الأصل في 2021-03-03. اطلع عليه بتاريخ 2015-10-20.
  14. ^ "behave is behaviour-driven development, Python style". مؤرشف من الأصل في 2018-01-22. اطلع عليه بتاريخ 2018-01-30.
  15. ^ "Writing Features - Behat 3.0.12 documentation". behat documentation. مؤرشف من الأصل في 2015-09-19. اطلع عليه بتاريخ 2015-10-20.
  16. ^ Evans، Eric (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. ISBN:978-0-321-12521-7. مؤرشف من الأصل في 2021-05-07. اطلع عليه بتاريخ 2012-08-12.
  17. ^ North، Dan (31 مايو 2012). "BDD is like TDD if…". faster organisations, faster software. Dan North & Associates. مؤرشف من الأصل في 2021-06-08. اطلع عليه بتاريخ 2012-08-12.
  18. ^ Geneca (16 مارس 2011). "Why Software Projects Fail". مؤرشف من الأصل في 2016-12-30. اطلع عليه بتاريخ 2011-03-16.
  19. ^ Mahmudul Haque Azad (6 فبراير 2011). "Say Hello To Behavior Driven Development". مؤرشف من الأصل في 2020-01-22. اطلع عليه بتاريخ 2012-08-12.
  20. ^ Lübke, Daniel؛ van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software. ج. 33 ع. 5: 15–21. DOI:10.1109/MS.2016.117.
مجلوبة من «https://ar.wikipedia.org/w/index.php?title=تطوير_مقاد_بالسلوك&oldid=62676044»