هندسة البرمجيات

الموسوعة الحرة
مخطط بنية لينكس

هندسة البرمجيات هي مجموعة الهياكل اللازمة لفهم نظام برمجي ، وهي أيضاً منهجية إنشاء هذه الهياكل والأنظمة. يتألف كل هيكل من عناصر برمجية، وعلاقات فيما بينها، وخصائص كل من العناصر والعلاقات. [ 1 ]

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

تُعنى هندسة البرمجيات باتخاذ خيارات هيكلية أساسية يصعب تغييرها بعد التنفيذ. تشمل هذه الخيارات خيارات هيكلية محددة من بين إمكانيات تصميم البرمجيات . يوجد قانونان أساسيان في هندسة البرمجيات: [ 3 ] [ 4 ]

  1. كل شيء عبارة عن مقايضة
  2. "السبب أهم من الكيفية"

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

توثيق بنية البرمجيات يُسهّل التواصل بين أصحاب المصلحة ، ويُسجّل القرارات المبكرة المتعلقة بالتصميم عالي المستوى، ويُتيح إعادة استخدام مكونات التصميم بين المشاريع. [ 5 ] : 29-35

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

يمكن تصنيف بنى البرمجيات إلى نوعين رئيسيين: البنية المتجانسة والبنية الموزعة ، ولكل منهما فئاته الفرعية الخاصة. [ 4 ]

تميل بنية البرمجيات إلى أن تصبح أكثر تعقيدًا بمرور الوقت. ينبغي على مهندسي البرمجيات استخدام " وظائف الملاءمة " للحفاظ على سلامة البنية باستمرار . [ 4 ]

أنشطة هندسة البرمجيات

نِطَاق

تختلف الآراء فيما يتعلق بنطاق بنى البرمجيات: [ 6 ]

  • بنية النظام الكلية : يشير هذا إلى بنية النظام باعتبارها تجريدًا عالي المستوى لنظام برمجي يتكون من مجموعة من المكونات الحاسوبية بالإضافة إلى روابط تصف التفاعل بين هذه المكونات. [ 7 ]
  • الأمور المهمة - أياً كان المقصود بها : يشير هذا إلى حقيقة أن مهندسي البرمجيات يجب أن يهتموا بالقرارات التي لها تأثير كبير على النظام وأصحاب المصلحة فيه. [ 8 ]
  • ما هو أساسي لفهم النظام في بيئته [ 9 ]
  • الأمور التي يعتبرها الناس صعبة التغيير : بما أن تصميم بنية النظام يتم في بداية دورة حياة النظام البرمجي، ينبغي على المهندس المعماري التركيز على القرارات التي "يجب" أن تكون صحيحة من المرة الأولى. وبناءً على هذا المنطق، قد تصبح مشكلات التصميم المعماري غير معمارية بمجرد إمكانية التغلب على عدم إمكانية التراجع عنها. [ 8 ]
  • مجموعة من قرارات التصميم المعماري : لا ينبغي اعتبار هندسة البرمجيات مجرد مجموعة من النماذج أو الهياكل، بل يجب أن تشمل القرارات التي أدت إلى هذه الهياكل المحددة، والأساس المنطقي وراءها. [ 10 ] وقد أدت هذه الرؤية إلى إجراء بحوث مكثفة في إدارة المعرفة المتعلقة بهندسة البرمجيات . [ 11 ]

لا يوجد فرق واضح بين هندسة البرمجيات وتصميمها وهندسة متطلباتها (انظر المجالات ذات الصلة أدناه). فجميعها جزء من "سلسلة من النوايا" تبدأ من النوايا العامة وتنتهي بالتفاصيل الدقيقة. [ 12 ] : 18

الأنماط والأساليب

نمط نموذج-عرض-متحكم

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

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

الأنماط المضادة

قد تنشأ الأنماط المعمارية السلبية التالية عندما يتخذ المعماريون قراراتهم. غالباً ما تتبع هذه الأنماط السلبية تسلسلاً تصاعدياً، حيث قد يؤدي حل أحدها إلى ظهور نمط آخر. [ 4 ]

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

صفات

يُظهر تصميم البرمجيات ما يلي:

تعدد أصحاب المصلحة: يجب أن تلبي أنظمة البرمجيات احتياجات مجموعة متنوعة من أصحاب المصلحة، مثل مديري الأعمال، والمالكين، والمستخدمين، والمشغلين. ولكل من هؤلاء أصحاب المصلحة اهتماماته الخاصة فيما يتعلق بالنظام. ويُعدّ تحقيق التوازن بين هذه الاهتمامات وإثبات معالجتها جزءًا من تصميم النظام. [ 5 ] : 29-31 وهذا يعني أن هندسة البرمجيات تتضمن التعامل مع طيف واسع من الاهتمامات وأصحاب المصلحة، وتتسم بطبيعة متعددة التخصصات.

فصل الاهتمامات : الطريقة المُعتمدة التي يتبعها المهندسون المعماريون لتقليل التعقيد هي فصل الاهتمامات التي تُحرك التصميم. تُظهر وثائق الهندسة المعمارية أن جميع اهتمامات أصحاب المصلحة تُلبى من خلال نمذجة ووصف الهندسة المعمارية من وجهات نظر منفصلة مرتبطة بمختلف اهتمامات أصحاب المصلحة. [ 16 ] تُسمى هذه الأوصاف المنفصلة وجهات نظر معمارية (انظر على سبيل المثال نموذج وجهة النظر المعمارية 4+1 ).

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

الأساليب المتكررة: كما هو الحال في هندسة المباني، طوّر تخصص هندسة البرمجيات أساليب قياسية لمعالجة المشكلات المتكررة. تُعرف هذه "الأساليب القياسية" بأسماء مختلفة على مستويات تجريد متنوعة. من المصطلحات الشائعة للحلول المتكررة: الأسلوب المعماري، [ 12 ] : 273-277 ؛ التكتيك، [ 5 ] : 70-72؛ الهندسة المعمارية المرجعية ؛ والنمط المعماري . [ 17 ] [ 18 ] [ 5 ] : 203-205

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

القيود المعرفية: ملاحظة وردت لأول مرة في ورقة بحثية عام 1967 من قِبل مبرمج الحاسوب ميلفين كونواي، مفادها أن المنظمات التي تصمم الأنظمة مقيدة بإنتاج تصاميم تحاكي هياكل التواصل داخل هذه المنظمات. [ 20 ] وقد عرّف فريد بروكس هذا المفهوم لجمهور أوسع عندما استشهد بالورقة البحثية والفكرة في كتابه "أسطورة الشهر الرجلي" ، وأطلق عليها اسم "قانون كونواي" .

تحفيز

تُعدّ هندسة البرمجيات تجريدًا "قابلًا للفهم الفكري" لنظام معقد. [ 5 ] : 5-6 يوفر هذا التجريد عددًا من المزايا:

  • يُوفر هذا أساسًا لتحليل سلوك أنظمة البرمجيات قبل بنائها. [ 2 ] إن القدرة على التحقق من أن نظام البرمجيات المستقبلي يُلبي احتياجات أصحاب المصلحة دون الحاجة إلى بنائه فعليًا تُمثل توفيرًا كبيرًا في التكاليف وتخفيفًا للمخاطر. [ 21 ] وقد طُوّرت العديد من التقنيات لإجراء مثل هذه التحليلات، مثل ATAM [ 22 ] أو من خلال إنشاء تمثيل مرئي لنظام البرمجيات.
  • يوفر ذلك أساسًا لإعادة استخدام العناصر والقرارات. [ 2 ] [ 5 ] : 35 يمكن إعادة استخدام بنية برمجية كاملة أو أجزاء منها، مثل الاستراتيجيات والقرارات المعمارية الفردية، عبر أنظمة متعددة تتطلب من أصحاب المصلحة سمات جودة أو وظائف مماثلة، مما يوفر تكاليف التصميم ويقلل من مخاطر أخطاء التصميم.
  • يدعم هذا النهج قرارات التصميم المبكرة التي تؤثر على تطوير النظام ونشره وصيانته. [ 5 ] : 31 إن اتخاذ القرارات المبكرة ذات التأثير الكبير بشكل صحيح أمر بالغ الأهمية لتجنب تجاوزات الجدول الزمني والميزانية .
  • يُسهّل ذلك التواصل مع أصحاب المصلحة، مما يُسهم في بناء نظام يُلبي احتياجاتهم على نحو أفضل. [ 5 ] : 29-31 يُساعد التواصل بشأن الأنظمة المعقدة من وجهة نظر أصحاب المصلحة على فهم تبعات متطلباتهم المعلنة وقرارات التصميم المبنية عليها. تُتيح بنية النظام إمكانية التواصل بشأن قرارات التصميم قبل تنفيذه، حين يكون تعديلها سهلاً نسبياً.
  • يساعد ذلك في إدارة المخاطر. تساعد بنية البرمجيات على تقليل المخاطر واحتمالية الفشل. [ 12 ] : 18
  • يُتيح ذلك خفض التكاليف . تُعدّ هندسة البرمجيات وسيلةً لإدارة المخاطر والتكاليف في مشاريع تكنولوجيا المعلومات المعقدة. [ 23 ]

تاريخ

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

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

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

كان معيار IEEE 1471-2000 ، "الممارسات الموصى بها لوصف بنية الأنظمة كثيفة البرمجيات"، أول معيار رسمي في مجال هندسة البرمجيات. وقد اعتمدته المنظمة الدولية للمقاييس (ISO) في عام 2007 تحت مسمى ISO/IEC 42010:2007. وفي نوفمبر 2011، تم استبدال معيار IEEE 1471-2000 بمعيار ISO/IEC/IEEE 42010:2011 ، "هندسة الأنظمة والبرمجيات - وصف البنية" (الذي نشرته كل من IEEE وISO بالاشتراك). [ 16 ]

بينما ركز معيار IEEE 1471 على هندسة البرمجيات، وتحديدًا على هندسة "الأنظمة كثيفة البرمجيات"، والتي تُعرَّف بأنها "أي نظام تُسهم فيه البرمجيات بشكلٍ جوهري في تصميمه وبنائه ونشره وتطويره ككل"، فإن إصدار 2011 يتجاوز ذلك ليشمل تعريفات ISO/IEC 15288 و ISO/IEC 12207 للنظام، والتي لا تقتصر على المكونات المادية والبرمجية فحسب، بل تشمل أيضًا "البشر والعمليات والإجراءات والمرافق والمواد والكيانات الطبيعية". وهذا يعكس العلاقة بين هندسة البرمجيات وهندسة المؤسسات وهندسة الحلول .

الأنشطة المعمارية

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

تقع على عاتق مهندس البرمجيات مسؤولية مطابقة الخصائص المعمارية (المعروفة أيضًا بالمتطلبات غير الوظيفية ) مع متطلبات العمل. على سبيل المثال: [ 4 ]

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

هناك أربعة أنشطة أساسية في تصميم بنية البرمجيات. [ 29 ] يتم تنفيذ أنشطة البنية الأساسية هذه بشكل تكراري وفي مراحل مختلفة من دورة حياة تطوير البرمجيات الأولية، وكذلك خلال تطور النظام.

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

  • ما الذي سيفعله النظام عند تشغيله (المتطلبات الوظيفية)
  • مدى جودة أداء النظام لمتطلبات وقت التشغيل غير الوظيفية مثل الموثوقية، وقابلية التشغيل، وكفاءة الأداء، والأمان، والتوافق المحدد في معيار ISO/IEC 25010 :2011 [ 30 ]
  • وقت تطوير المتطلبات غير الوظيفية مثل قابلية الصيانة وقابلية النقل المحددة في معيار ISO 25010:2011 [ 30 ]
  • متطلبات العمل والسياقات البيئية للنظام التي قد تتغير بمرور الوقت، مثل الاعتبارات القانونية والاجتماعية والمالية والتنافسية والتكنولوجية [ 31 ]

تتمثل مخرجات نشاط التحليل في تلك المتطلبات التي لها تأثير قابل للقياس على بنية نظام البرمجيات، وتسمى المتطلبات ذات الأهمية المعمارية. [ 32 ]

التصميم المعماري أو التركيب المعماري هو عملية إنشاء تصميم معماري. وبناءً على المتطلبات المعمارية الهامة التي تحددها التحليلات، والحالة الراهنة للتصميم، ونتائج أي أنشطة تقييمية، يتم إنشاء التصميم وتحسينه. [ 29 ] [ 5 ] : 311-326

تقييم بنية النظام هو عملية تحديد مدى كفاءة التصميم الحالي، أو جزء منه، في تلبية المتطلبات المستخلصة خلال التحليل. يمكن إجراء التقييم عند اتخاذ أي قرار تصميمي، أو بعد إتمام جزء من التصميم، أو بعد إتمام التصميم النهائي، أو بعد بناء النظام. تتضمن بعض تقنيات تقييم بنية البرمجيات المتاحة أسلوب تحليل المفاضلة بين البنية (ATAM) و TARA. [ 33 ] وتُناقش أطر عمل مقارنة هذه التقنيات في أطر عمل مثل تقرير SARA [ 21 ] ومراجعات البنية: الممارسة والخبرة . [ 34 ]

تطوير بنية البرمجيات هو عملية صيانة وتكييف بنية البرمجيات الحالية لمواكبة التغيرات في المتطلبات والبيئة. وبما أن بنية البرمجيات توفر الهيكل الأساسي لنظام البرمجيات، فإن تطويرها وصيانتها يؤثران بالضرورة على هذا الهيكل. ولذلك، يهتم تطوير بنية البرمجيات بإضافة وظائف جديدة، بالإضافة إلى الحفاظ على الوظائف الحالية وسلوك النظام.

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

الأنشطة المعمارية الداعمة

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

  • إدارة المعرفة والتواصل هي عملية استكشاف وإدارة المعرفة الأساسية لتصميم بنية البرمجيات. لا يعمل مهندس البرمجيات بمعزل عن الآخرين، بل يحصل على المدخلات، والمتطلبات الوظيفية وغير الوظيفية، وسياقات التصميم من مختلف الجهات المعنية، ويقدم المخرجات إليها. غالبًا ما تكون معرفة بنية البرمجيات ضمنية، وتُحفظ في أذهان الجهات المعنية. تتمحور أنشطة إدارة معرفة بنية البرمجيات حول إيجاد المعرفة، والتواصل بشأنها، والاحتفاظ بها. نظرًا لتعقيد قضايا تصميم بنية البرمجيات وترابطها، فإن أي فجوة معرفية في منطق التصميم قد تؤدي إلى تصميم غير صحيح لبنية البرمجيات. [ 35 ] [ 36 ] تشمل أمثلة أنشطة إدارة المعرفة والتواصل البحث عن أنماط التصميم، وإنشاء النماذج الأولية، واستشارة المطورين والمهندسين ذوي الخبرة، وتقييم تصاميم الأنظمة المشابهة، ومشاركة المعرفة مع المصممين والجهات المعنية الأخرى، وتوثيق الخبرات على صفحة ويكي.
  • يُعدّ التفكير التصميمي واتخاذ القرارات عملية تقييم قرارات التصميم، وهي أساسية لجميع أنشطة هندسة البرمجيات الثلاثة الرئيسية. [ 10 ] [ 37 ] وتشمل هذه العملية جمع سياقات القرار وربطها، وصياغة مشكلات قرارات التصميم، وإيجاد خيارات الحلول، وتقييم المفاضلات قبل اتخاذ القرارات. وتحدث هذه العملية على مستويات مختلفة من دقة القرار أثناء تقييم متطلبات البنية الهامة وقرارات هندسة البرمجيات، وتحليل بنية البرمجيات وتوليفها وتقييمها. ومن أمثلة أنشطة التفكير: فهم تأثيرات المتطلب أو التصميم على سمات الجودة، والتساؤل عن المشكلات التي قد يُسببها التصميم، وتقييم خيارات الحلول الممكنة، وتقييم المفاضلات بين الحلول.
  • التوثيق هو عملية تسجيل التصميم الناتج خلال عملية هندسة البرمجيات. يُوصف تصميم النظام باستخدام عدة وجهات نظر، تشمل عادةً وجهة نظر ثابتة تُظهر بنية كود النظام، ووجهة نظر ديناميكية تُظهر إجراءات النظام أثناء التنفيذ، ووجهة نظر النشر التي تُظهر كيفية تثبيت النظام على الأجهزة لتنفيذه. يقترح نموذج كروشتن 4+1 وصفًا لوجهات النظر الشائعة الاستخدام لتوثيق هندسة البرمجيات؛ [ 38 ] يتضمن كتاب "توثيق هندسة البرمجيات: وجهات النظر وما بعدها" وصفًا لأنواع الرموز التي يمكن استخدامها ضمن وصف وجهة النظر. [ 1 ] من أمثلة أنشطة التوثيق: كتابة المواصفات، وتسجيل نموذج تصميم النظام، وتوثيق الأساس المنطقي للتصميم، وتطوير وجهة نظر، وتوثيق وجهات النظر.

استراتيجيات تصميم بنية البرمجيات

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

يتضمن هذا النهج عادةً دورة تتكون من عدة مراحل: [ 4 ]

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

تُشكل هذه الدورة إطاراً عاماً ويمكن تكييفها مع مجالات مختلفة.

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

هندسة البرمجيات والتطوير الرشيق

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

تآكل بنية البرمجيات

يشير تآكل بنية البرمجيات إلى فجوة تدريجية بين البنية المقصودة والبنية المُطبقة لنظام برمجي مع مرور الوقت. [ 40 ] وقد تم تسليط الضوء على ظاهرة تآكل بنية البرمجيات لأول مرة عام 1992 من قِبل بيري وولف بالتزامن مع تعريفهما لبنية البرمجيات. [ 2 ]

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

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

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

استعادة بنية البرمجيات

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

تصميم

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

هندسة المتطلبات

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

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

أنواع أخرى من "العمارة"

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

انظر أيضاً

مراجع

  1. 1 2 3 كليمنتس، بول؛ فيليكس باخمان؛ لين باس ؛ ديفيد جارلان؛ جيمس إيفرز؛ ريد ليتل؛ باولو ميرسون؛ روبرت نورد؛ جوديث ستافورد (2010). توثيق بنى البرمجيات: وجهات نظر وما وراءها، الطبعة الثانية . بوسطن: أديسون-ويسلي. ISBN 978-0-321-55268-6.
  2. 1 2 3 4 بيري، دي إي؛ وولف، إيه إل (1992). "أسس دراسة هندسة البرمجيات" (ملف PDF) . ملاحظات هندسة البرمجيات ACM SIGSOFT . 17 (4): 40. CiteSeerX 10.1.1.40.5174 . doi : 10.1145/141874.141884 . S2CID 628695 .  
  3. ↑ هندسة البرمجيات من Head First . دار نشر O'Reilly Media. 2024. رقم ISBN 978-1-0981-3435-8.
  4. 1 2 3 4 5 6 7 8 9 10 11 أساسيات هندسة البرمجيات: منهج هندسي . دار نشر أورايلي ميديا. 2020. ISBN 978-1-4920-4345-4.
  5. 1 2 3 4 5 6 7 8 9 10 باس، لين؛ بول كليمنتس؛ ريك كازمان (2012). هندسة البرمجيات في الممارسة، الطبعة الثالثة . بوسطن: أديسون-ويسلي. ISBN 978-0-321-81573-6.
  6. ↑ SEI (2006). "كيف تُعرّف هندسة البرمجيات؟" . تم الاطلاع عليه بتاريخ 12-09-2012 .
  7. ↑ جارلان وشاو (1994). "مقدمة في هندسة البرمجيات" (ملف PDF) . تم الاطلاع عليه بتاريخ 13-09-2012 .
  8. 1 2 فاولر، مارتن (2003). "التصميم - من يحتاج إلى مهندس معماري؟". مجلة IEEE للبرمجيات . 20 (5): 11-44 . Bibcode : 2003ISoft..20e..11F . doi : 10.1109/MS.2003.1231144 . S2CID 356506 . 
  9. ↑ ISO/IEC/IEEE 42010: تعريف "البنية" . Iso-architecture.org. تاريخ الاطلاع: 21 يوليو 2013.
  10. 1 2 جانسن، أ.؛ بوش، ج. (2005). "هندسة البرمجيات كمجموعة من قرارات التصميم المعماري". المؤتمر الخامس لهندسة البرمجيات IEEE/IFIP (WICSA'05) . ص 109. CiteSeerX 10.1.1.60.8680 . doi : 10.1109/WICSA.2005.61 . ISBN   978-0-7695-2548-8. S2CID 13492610 . 
  11. ↑ علي بابار، محمد؛ دينجسور، تورجير؛ لاغو، باتريشيا؛ فان فليت، هانز (2009). إدارة المعرفة لهندسة البرمجيات . دوردريخت هايدلبرغ لندن نيويورك: سبرينغر. رقم ISBN 978-3-642-02373-6.
  12. 1 2 3 جورج فيربانكس (2010). هندسة البرمجيات الكافية . مارشال وبرينرد.
  13. 1 2 أساسيات هندسة البرمجيات: منهج هندسي . دار نشر أورايلي ميديا. 2020. ISBN 978-1-4920-4345-4.
  14. 1 2 لارمان، كريج (2005). أنماط التصميم: عناصر البرمجيات القابلة لإعادة الاستخدام والموجهة للكائنات . بيرسون دويتشلاند جي إم بي إتش. ISBN 978-0-201-63361-0.
  15. 1 2 أنماط هندسة تطبيقات المؤسسات . ISBN 978-0-321-12742-6.
  16. 1 2 ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 هندسة النظم والبرمجيات - وصف البنية" . تم الاطلاع عليه بتاريخ 12-09-2012 .
  17. ↑ مولر، جيريت (20 أغسطس 2007). "مقدمة في العمارة المرجعية" (ملف PDF) . موقع غاودي . مؤرشف (ملف PDF) من الأصل بتاريخ 19 ديسمبر 2011. تم الاطلاع عليه بتاريخ 13 نوفمبر 2015 .
  18. ↑ أنجيلوف، س.؛ غريفين، ب.؛ غريفورست، د. (2009). "تصنيف بنى البرمجيات المرجعية: تحليل نجاحها وفعاليتها". المؤتمر المشترك لعام 2009 بين معهد مهندسي الكهرباء والإلكترونيات والاتحاد الدولي لمعالجة المعلومات حول هندسة البرمجيات والمؤتمر الأوروبي حول هندسة البرمجيات . معهد مهندسي الكهرباء والإلكترونيات. الصفحات 141-150 . doi : 10.1109/WICSA.2009.5290800 . ISBN  978-1-4244-4984-2.
  19. ↑ بروكس، فريدريك ب. الابن (1975). الشهر الأسطوري للرجل - مقالات في هندسة البرمجيات . أديسون-ويسلي. ISBN 978-0-201-00650-6.
  20. ↑ كونواي، ميلفين. "قانون كونواي" . الصفحة الرئيسية لميل كونواي . مؤرشف من الأصل بتاريخ 29-09-2019 . تم الاطلاع عليه بتاريخ 29-09-2019 .
  21. 1 2 أوبينك، هـ.؛ كروشتن، ب.؛ كوزاتشينسكي، و.؛ بوستما، هـ.؛ ران، أ.؛ دومينيك، ل.؛ كازمان، ر.؛ هيليارد، ر.؛ تراز، و.؛ كاهان، إ. (6 فبراير 2002). "تقرير مراجعة وتقييم بنية البرمجيات (SARA)" (ملف PDF) . تم الاطلاع عليه في 1 نوفمبر 2015 .
  22. ↑ "ATAM: منهجية لتقييم البنية" (ملف PDF) . apps.dtic.mil . مؤرشف (ملف PDF) من الأصل بتاريخ 2025-02-02 . تم الاطلاع عليه بتاريخ 2025-12-20 .
  23. ↑ بورت، إلتجو؛ فان فليت، هانز (سبتمبر 2012). "RCDA: الهندسة المعمارية كمنهج لإدارة المخاطر والتكاليف" . مجلة الأنظمة والبرمجيات . 85 (9): 1995-2013 . doi : 10.1016/j.jss.2012.03.071 .
  24. ↑ ب. نور؛ ب. راندل، محرران (1969). "هندسة البرمجيات: تقرير مؤتمر برعاية اللجنة العلمية لحلف الناتو، غارميش، ألمانيا، 7-11 أكتوبر 1968" (ملف PDF) . بروكسل: حلف الناتو، قسم الشؤون العلمية. مؤرشف (ملف PDF) من الأصل بتاريخ 7 يونيو 2003. تم الاطلاع عليه بتاريخ 16 نوفمبر 2012 .
  25. ↑ ب. كروشتن؛ هـ. أوبينك؛ ج. ستافورد (2006). "ماضي وحاضر ومستقبل هندسة البرمجيات". مجلة IEEE للبرمجيات . 23 (2): 22. رمز Bibcode : 2006ISoft..23b..22K . doi : 10.1109/MS.2006.59 . S2CID 2082927 . 
  26. ↑ جامعة واترلو (2006). "تاريخ موجز جداً لعلوم الحاسوب" . تم الاطلاع عليه بتاريخ 23-09-2006 .
  27. ↑ "مقدمة العدد الخاص حول هندسة البرمجيات". IEEE.org . 2006. doi : 10.1109/TSE.1995.10003 .
  28. ↑ جارلان وشاو (1994). "مقدمة في هندسة البرمجيات" (ملف PDF) . تم الاطلاع عليه بتاريخ 25-09-2006 .
  29. 1 2 3 كريستين هوفميستر؛ فيليب كروشتن؛ روبرت ل. نورد؛ هينك أوبينك؛ ألكسندر ران؛ بيير أمريكا (2007). "نموذج عام لتصميم بنية البرمجيات مستمد من خمسة مناهج صناعية". مجلة الأنظمة والبرمجيات . 80 (1): 106-126 . doi : 10.1016/j.jss.2006.05.024 .
  30. 1 2 المنظمة الدولية للمقاييس/اللجنة الكهروتقنية الدولية (2011). "ISO/IEC 25010:2011 هندسة النظم والبرمجيات - متطلبات جودة النظم والبرمجيات وتقييمها (SQuaRE) - نماذج جودة النظم والبرمجيات" . تم الاطلاع عليه بتاريخ 8 أكتوبر 2012 .
  31. ↑ أوستروالدر وبيغنيور (2004). "أنطولوجيا لنماذج الأعمال الإلكترونية" (ملف PDF) . خلق القيمة من نماذج الأعمال الإلكترونية . الصفحات 65-97 . CiteSeerX 10.1.1.9.6922 . doi : 10.1016/B978-075066140-9/50006-0 . ISBN   978-0-7506-6140-9. S2CID 14177438 . مؤرشف من الأصل (PDF) بتاريخ 2018-11-17. 
  32. ↑ تشين، ليان بينغ؛ علي بابار، محمد؛ نسيبة، بشار (2013). "توصيف المتطلبات ذات الأهمية المعمارية". مجلة IEEE للبرمجيات . 30 (2): 38-45 . Bibcode : 2013ISoft..30b..38C . doi : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 . 
  33. ↑ وودز، إي. (2012). "التقييم المعماري الصناعي باستخدام TARA". مجلة الأنظمة والبرمجيات . 85 (9): 2034-2047 . doi : 10.1016/j.jss.2012.04.055 . S2CID 179244 . 
  34. ↑ مارانزانو، جيه إف؛ روزسيبال، إس إيه؛ زيمرمان، جي إتش؛ وارنكن، جي دبليو؛ ويرث، بي إي؛ فايس، دي إم (2005). "مراجعات معمارية: الممارسة والخبرة". مجلة IEEE للبرمجيات . 22 (2): 34. رمز Bibcode : 2005ISoft..22b..34M . doi : 10.1109/MS.2005.28 . S2CID 11697335 . 
  35. ↑ كروشتن، ب. (2008). "ماذا يفعل مهندسو البرمجيات حقًا؟". مجلة الأنظمة والبرمجيات . 81 (12): 2413-2416 . doi : 10.1016/j.jss.2008.08.025 .
  36. ↑ بابار، م.أ؛ دينغسوير، ت.؛ لاغو، ب.؛ فان فليت، هـ. (2009). إدارة المعرفة في هندسة البرمجيات: النظرية والتطبيق (محررون)، الطبعة الأولى . سبرينغر. ISBN 978-3-642-02373-6.
  37. ↑ تانغ، أ.؛ هان، ج.؛ فاسا، ر. (2009). "الاستدلال في تصميم بنية البرمجيات: حالة لتحسين دعم المنهجية". مجلة IEEE للبرمجيات . 26 (2): 43. Bibcode : 2009ISoft..26b..43T . doi : 10.1109/MS.2009.46 . hdl : 1959.3/51601 . S2CID 12230032 . 
  38. ↑ كروشتن، فيليب (1995). "المخططات المعمارية - نموذج عرض '4+1' لهندسة البرمجيات" (ملف PDF) . مجلة IEEE للبرمجيات . 12 (6): 42-50 . arXiv : 2006.04975 . doi : 10.1109/52.469759 . S2CID 219558624 . 
  39. ↑ بوهم، باري؛ تيرنر، ريتشارد (2004). الموازنة بين الرشاقة والانضباط . أديسون-ويسلي. ISBN 978-0-321-18612-6.
  40. 1 2 3 لي، رويين؛ ليانغ، بينغ؛ سليمان، محمد؛ أفغيريو، باريس (2022). "فهم تآكل بنية البرمجيات: دراسة مسحية منهجية" . مجلة البرمجيات: التطور والعملية . 34 (3) e2423. arXiv : 2112.10934 . doi : 10.1002/smr.2423 .
  41. ↑ لي، رويين؛ ليانغ، بنغ؛ سليمان، محمد؛ أفغيريو، باريس (2021). "فهم تآكل البنية: منظور الممارسين". المؤتمر الدولي التاسع والعشرون لـ IEEE/ACM حول فهم البرامج (ICPC) . الصفحات 311-322 . doi : 10.1109/icpc52881.2021.00037 . ISBN  978-1-6654-1403-6.
  42. ↑ فان جورب، ج. وبوش، ج.: 2002، تآكل التصميم: المشاكل والأسباب، مجلة الأنظمة والبرمجيات 61(2)، 105-119.
  43. ↑ لونغو، م. "استعادة بنية البرمجيات"، جامعة لوغانو، 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
  44. 1 2 أمنون ح. إيدن؛ ريك كازمان (2003). "تنفيذ التصميم المعماري" (ملف PDF) . مؤرشف من الأصل (ملف PDF) بتاريخ 28-09-2007.
  45. ↑ سي. شيكاران؛ دي. جارلان؛ إم. جاكسون؛ إن. آر. ميد؛ سي. بوتس؛ إتش. بي. روبنشتاين (1994). "دور هندسة البرمجيات في هندسة المتطلبات". وقائع المؤتمر الدولي لهندسة المتطلبات التابع لمعهد مهندسي الكهرباء والإلكترونيات . الصفحات 239-245 . doi : 10.1109/ICRE.1994.292379 . ISBN  978-0-8186-5480-0. S2CID 3129363 . 
  46. ^ ريمكو سي. دي بوير، هانز فان فليت (2009). “على التشابه بين المتطلبات والهندسة المعمارية”. مجلة النظم والبرمجيات . 82 (3): 544-550 . سايتسيركس 10.1.1.415.6023 . دوى : 10.1016/j.jss.2008.11.185 . 
  47. ↑ بشار نسيبة (2001). "دمج المتطلبات والهياكل" (ملف PDF) . مجلة الحاسوب . 34 (3): 115-119 . doi : 10.1109/2.910904 . مؤرشف (ملف PDF) من الأصل بتاريخ 2012-09-07.
  48. ↑ "كيفية استخدام بنية الحوسبة بلا خوادم" . DashDevs . تم الاطلاع عليه بتاريخ 28-08-2023 .

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