التحليل المنظم

الموسوعة الحرة
مثال على منهج التحليل المنظم. [ 1 ]

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

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

أهداف التحليل المنظم

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

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

يتم عرض SA و SD مع مخططات هيكلية ومخططات تدفق البيانات ومخططات نموذج البيانات ، والتي كان لها العديد من الاختلافات، بما في ذلك تلك التي طورها توم ديماركو ، وكين أور ، ولاري كونستانتين ، وفون فريك ، وإد يوردون ، وستيفن وارد، وبيتر تشين ، وغيرهم.

تم دمج هذه التقنيات في منهجيات تطوير الأنظمة المنشورة المختلفة ، بما في ذلك طريقة تحليل وتصميم الأنظمة المهيكلة ، والمعلومات المربحة عن طريق التصميم (PRIDE)، وتحليل وتصميم Nastec المهيكل، وSDM/70، ومنهجية تطوير الأنظمة المهيكلة Spectrum.

تاريخ

Structured analysis is part of a series of structured methods that represent a collection of analysis, design, and programming techniques that were developed in response to the problems facing the software world from the 1960s to the 1980s. In this timeframe most commercial programming was done in Cobol and Fortran, then C and BASIC. There was little guidance on "good" design and programming techniques, and there were no standard techniques for documenting requirements and designs. Systems were getting larger and more complex, and the information system development became harder and harder to do so."[4]

As a way to help manage large and complex software, the following structured methods emerged since the end of the 1960s:[4]

بحسب هاي (1999)، " كانت هندسة المعلومات امتدادًا منطقيًا للتقنيات الهيكلية التي طُوّرت خلال سبعينيات القرن العشرين. فقد أدت البرمجة الهيكلية إلى التصميم الهيكلي، الذي بدوره أدى إلى تحليل النظم الهيكلي. وتميزت هذه التقنيات باستخدامها للرسوم البيانية : مخططات الهيكل للتصميم الهيكلي، ومخططات تدفق البيانات للتحليل الهيكلي، وذلك لتسهيل التواصل بين المستخدمين والمطورين، ولتحسين كفاءة كل من المحلل والمصمم. وخلال ثمانينيات القرن العشرين، بدأت تظهر أدواتٌ تُؤتمت رسم المخططات، وتُسجّل البيانات المرسومة في قاموس بيانات ". [ 10 ] وبعد مثال التصميم والتصنيع بمساعدة الحاسوب ( CAD /CAM)، أُطلق على استخدام هذه الأدوات اسم هندسة البرمجيات بمساعدة الحاسوب (CASE).

مواضيع التحليل الهيكلي

آلية التجريد الفردي

مثال على التحليل المنظم. [ 11 ]

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

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

يقترب

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

يُطوّر منهج التحليل المنظم وجهات نظر حول كل من كائنات العمليات وكائنات البيانات. [ 12 ]

يتكون نهج دي ماركو [ 13 ] من العناصر التالية (انظر الشكل): [ 12 ]

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

مخطط السياق

مثال على مخطط سياق النظام. [ 14 ]

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

This type of diagram according to Kossiakoff (2003) usually "pictures the system at the center, with no details of its interior structure, surrounded by all its interacting systems, environment and activities. The objective of a system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of system requirements and constraints".[15] System context diagrams are related to data flow diagram, and show the interactions between a system and other actors which the system is designed to face. System context diagrams can be helpful in understanding the context in which the system will be part of software engineering.

Data dictionary

Entity relationship diagram, essential for the design of database tables, extracts, and metadata.[16]

A data dictionary or database dictionary is a file that defines the basic organization of a database.[16] A database dictionary contains a list of all files in the database, the number of records in each file, and the names and types of each data field. Most database management systems keep the data dictionary hidden from users to prevent them from accidentally destroying its contents. Data dictionaries do not contain any actual data from the database, only bookkeeping information for managing it. Without a data dictionary, however, a database management system cannot access data from the database.[16]

Database users and application developers can benefit from an authoritative data dictionary document that catalogs the organization, contents, and conventions of one or more databases.[17] This typically includes the names and descriptions of various tables and fields in each database, plus additional details, like the type and length of each data element. There is no universal standard as to the level of detail in such a document, but it is primarily a distillation of metadata about database structure, not the data itself. A data dictionary document also may include further information describing how data elements are encoded. One of the advantages of well-designed data dictionary documentation is that it helps to establish consistency throughout a complex database, or across a large collection of federated databases.[18]

Data flow diagrams

Data flow diagram example.[19]

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

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

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

مخطط هيكلي

مخطط هيكل نظام التكوين. [ 21 ]

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

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

التصميم الهيكلي

يهتم التصميم الهيكلي بتطوير الوحدات البرمجية وتجميعها في ما يُسمى "التسلسل الهرمي للوحدات". [ 24 ] ولتصميم بنية وواجهات مثالية للوحدات البرمجية، يُعدّ مبدأان أساسيان:

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

طُوِّر التصميم الهيكلي على يد لاري كونستانتين في أواخر الستينيات، ثم نُقِّح ونُشِر بالتعاون مع آخرين في السبعينيات؛ [ 5 ] [ 6 ] انظر: لاري كونستانتين: التصميم الهيكلي لمزيد من التفاصيل. وقد اقترح بيج-جونز (1980) منهجه الخاص الذي يتكون من ثلاثة عناصر رئيسية  :

  • مخططات هيكلية
  • مواصفات الوحدة
  • قاموس البيانات.

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

الانتقادات

تضمنت مشاكل مخططات تدفق البيانات ما يلي: [ 3 ]

  1. اختيار الفقاعات بشكل مناسب
  2. تقسيم الفقاعات بطريقة هادفة ومتفق عليها بشكل متبادل،
  3. حجم الوثائق اللازمة لفهم تدفقات البيانات،
  4. تتميز مخططات تدفق البيانات بطبيعتها الوظيفية القوية، وبالتالي فهي عرضة للتغيير المتكرر.
  5. على الرغم من التركيز على تدفق "البيانات"، إلا أنه لا يتم التركيز على نمذجة "البيانات"، لذا فإن فهم موضوع النظام ضئيل.
  6. يواجه العملاء صعوبة في فهم كيفية تحويل المفهوم إلى تدفقات البيانات والفقاعات
  7. يجب على المصممين تحويل هيكل مخطط تدفق البيانات إلى شكل قابل للتنفيذ

انظر أيضاً

مراجع

  1. ↑ تريشيا جيلبرت (2006) معايير تقييم FCS لتقييم التكنولوجيا. مؤرشف في 18 سبتمبر 2008 على موقع Wayback Machine.
  2. ↑ إدوارد يوردون (1986). إدارة التقنيات المنظمة: استراتيجيات تطوير البرمجيات في التسعينيات . دار نشر يوردون. ص 35.
  3. 1 2 إدارة الطيران الفيدرالية (2000). دليل سلامة النظام لإدارة الطيران الفيدرالية، الملحق د . 30 ديسمبر 2000.
  4. 1 2 ديف ليفيت (2000). "مقدمة في التحليل والتصميم الهيكلي". على faculty.inverhills.edu/dlevitt . تم الاطلاع عليه بتاريخ 21 سبتمبر 2008. لم يعد متاحًا على الإنترنت منذ عام 2017.
  5. 1 2 ستيفنز، مايرز وقسطنطين 1974 .
  6. 1 2 يوردون وقسطنطين 1979 .
  7. ↑ ماكمينامين، ستيفن م.؛ بالمر، جون ف. (1984). تحليل النظم الأساسي . دار يوردون للنشر. ISBN 978-0-13-287905-7.
  8. ↑ غافرييل سالفندي (2001). دليل الهندسة الصناعية: التكنولوجيا وإدارة العمليات. ص 508.
  9. ↑ يوردون، إدوارد (1989). التحليل الهيكلي الحديث . برنتيس هول. ISBN 978-0-13-598632-5.
  10. ↑ ديفيد سي. هاي (1999) تحقيق الامتثال للكلمات الطنانة في التوجه الكائني مؤرشف في 2008-10-20 في آلة Wayback الاستراتيجيات الأساسية، Inc.
  11. 1 2 3 فريق عمل إطار عمل هندسة وزارة الدفاع (2003). DoDAF 1.5 المجلد 2 ، 15 أغسطس 2003.
  12. 1 2 3 4 5 6 7 آلان هيشت وأندي سيمونز (1986) دمج التحليل والتصميم الهيكلي الآلي مع بيئات دعم برمجة Ada، ناسا 1986.
  13. ↑ توم ديماركو (1978). التحليل الهيكلي وتحديد مواصفات النظام . دار نشر يوردون، نيويورك، 1978.
  14. ↑ إدارة مشروع NDE مؤرشفة بتاريخ 2008-11-07 على موقع Wayback Machine (NPOESS) لاستغلال البيانات. 2008.
  15. 1 2 ألكسندر كوسياكوف ، ويليام ن. سويت (2003). هندسة النظم: المبادئ والممارسات ، ص 413.
  16. 1 2 3 مسرد تكامل البيانات مؤرشف بتاريخ 2012-02-18 في Wayback Machine ، وزارة النقل الأمريكية، أغسطس 2001.
  17. ↑ TechTarget، SearchSOA ، ما هو قاموس البيانات؟
  18. ↑ موجز ممارسات AHIMA، إرشادات لتطوير قاموس البيانات ، مجلة AHIMA 77، العدد 2 (فبراير 2006): 64A-D.
  19. ↑ جون أزوليني (2000). مقدمة في ممارسات هندسة النظم . يوليو 2000.
  20. ↑ W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
  21. 1 2 "إدارة التكوين" في: موارد مصلحة الضرائب الأمريكية، الجزء 2. تكنولوجيا المعلومات، الفصل 27. إدارة التكوين . تم الاطلاع عليه في 14 نوفمبر 2008.
  22. ↑ جيمس مارتن ، كارما إل. ماكلور (1988). التقنيات المنظمة: أساس دراسة الحالة . برنتيس هول. ص 56.
  23. ↑ ديفيد وولبر " مخططات الهيكل مؤرشفة 2009-02-19 في Wayback Machine : ملاحظات تكميلية مخططات الهيكل والتنفيذ من الأسفل إلى الأعلى: إصدار جافا.
  24. ↑ بيج-جونز 1980 .
  25. ↑ بلخوش، ب.، وج. إي. أوربان. (1986). "التنفيذ المباشر لأنواع البيانات المجردة من المواصفات المجردة". في: معاملات IEEE في هندسة البرمجيات ، الصفحات 549-661، مايو 1986.

للمزيد من القراءة

  • ستيفنز، دبليو بي ؛ مايرز، جي جي ؛ قسطنطين، إل إل (يونيو 1974). "التصميم الهيكلي". مجلة أنظمة آي بي إم . 13 (2): 115-139 . doi : 10.1147/sj.132.0115 .
  • يوردون، إدوارد ؛ قسطنطين، لاري ل. (1979) [1975]. التصميم الهيكلي: أساسيات تخصص تصميم برامج وأنظمة الحاسوب . دار نشر يوردون. ISBN 0-13-854471-9.
  • توم ديماركو (1978). التحليل الهيكلي وتحديد مواصفات النظام . يوردون. ISBN 0-91-707207-3
  • بيج-جونز، م (1980)، الدليل العملي لتصميم الأنظمة الهيكلية ، نيويورك: دار يوردون للنشر
  • ديريك ج. هاتلي، امتياز أ. بيربهاي (1988). استراتيجيات تحديد مواصفات أنظمة الوقت الحقيقي . جون وايلي وأولاده المحدودة. ISBN 0-932633-04-8
  • ستيفن ج. ميلور وبول ت. وارد (1986). التطوير الهيكلي لأنظمة الوقت الحقيقي: تقنيات نمذجة التنفيذ: 003. برنتيس هول. ISBN 0-13-854803-X
  • إدوارد يوردون (1989). التحليل الهيكلي الحديث ، سلسلة يوردون برس للحوسبة، 1989، رقم ISBN 0-13-598624-9
  • كيث إدواردز (1993). الأساليب الهيكلية في الوقت الحقيقي، تحليل النظم . وايلي. ISBN 0-471-93415-1