الرئيسيةعريقبحث

التحليل الإنشائي

☰ جدول المحتويات

يُعد كل من التحليل الإنشائي (إس إيه) والتصميم الإنشائي (إس دي) في هندسة البرمجيات أساليب لتحليل متطلبات العمل وتطوير المواصفات لتحويل الممارسات إلى برامج حاسوبية وتكوينات أجهزة مادية وإجراءات يدوية ذات صلة.

التحليل الإنشائي وتقنيات التصميم هي الأدوات الأساسية لتحليل النظم. طُورت من تحليل النظم الكلاسيكية في الستينيات والسبعينيات.[1]

أهداف التحليل الإنشائي

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

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

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

جُمعت هذه التقنيات في منهجيات تطوير النظام العديدة المنشورة، بما فيها طريقة تحليل وتصميم النظم الإنشائية، والمعلومات المربحة حسب التصميم، وتحليل وتصميم ناستك الإنشائي، ومنهجية SDM/70 ومنهجية تطوير نظام الطيف الإنشائي.

تاريخيًا

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

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

موضوعات التحليل الإنشائي

آلية التجريد الأحادي

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

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

النهج

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

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

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

المخطط السياقي

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

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

المراجع

  1. إدوارد يوردون (1986). Managing the Structured Techniques: Strategies for Software Development in the 1990s. Yourdon Press. p.35.
  2. FAA (2000). FAA System Safety Handbook, Appendix D. December 30, 2000. نسخة محفوظة 29 أغسطس 2017 على موقع واي باك مشين.
  3. Dave Levitt (2000). "Introduction to Structured Analysis and Design." at faculty.inverhills.edu/dlevitt. Retrieved 21 Sep 2008. No longer online 2017.
  4. DoD Architecture Framework Working Group (2003). DoDAF 1.5 Volume 2, 15 August 2003. نسخة محفوظة 10 مايو 2009 على موقع واي باك مشين.
  5. Alan Hecht and Andy Simmons (1986) Integrating Automated Structured Analysis and Design with Ada Programming Support Environments NASA 1986. نسخة محفوظة 13 أغسطس 2011 على موقع واي باك مشين.
  6. Alexander Kossiakoff, William N. Sweet (2003). Systems Engineering: Principles and Practices p. 413.

موسوعات ذات صلة :