نحن نتبع عملية من خمس خطوات في تصميم البرامج الثابتة

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

قد يكون إتقان إنشاء بنية قوية للبرامج الثابتة وإعادة هندسة البرامج القديمة في الوقت نفسه عملية صعبة وتستغرق وقتًا طويلاً.

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

الخطوة الأولى: تحديد المواصفات اللازمة.

تعد المتطلبات الواضحة أمرًا بالغ الأهمية قبل البدء في التصميم المعماري للنظام المضمن أو البرامج الثابتة الخاصة به. تحدد المتطلبات المحددة بدقة السمات والصفات الضرورية للمنتج.

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

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

العنصر الأساسي هو قابلية الاختبار. يسمح المتطلبات المكتوبة جيدًا بإنشاء مجموعة من الاختبارات بسهولة للتحقق من استيفاء المتطلبات.

تتكون المجموعة الكاملة من المتطلبات من بيانات مكتوبة تبدأ بالعبارة الرئيسية "يجب على [المنتج] ...".

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

الخطوة الثانية: التمييز بين الهندسة المعمارية والتصميم

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

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

تصميم النظام بمثابة الطبقة المتوسطة للتنفيذ. من المهم ملاحظة أن البنية لا تتضمن تفاصيل الوظيفة أو أسماء المتغيرات. تم توثيق هذه التفاصيل في مستند تصميم البرنامج الثابت.

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

التنفيذ هو المرحلة الأكثر تفصيلاً في العملية. تسمح الواجهات الواضحة التي تم إنشاؤها خلال مرحلة التصميم للمهندسين بتنفيذ الأجزاء المكونة الفردية بشكل متزامن.

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

الخطوة 3: إدارة الوقت

وسوف تشمل مواصفات المنتج الأطر الزمنية. عادة، تحتوي المنتجات على مزيج من متطلبات الوقت الحقيقي غير الحقيقي، والوقت الحقيقي الناعم، والوقت الحقيقي الصعب.

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

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

يسمح فصل متطلبات التوقيت عن جسم البرنامج الرئيسي للمنفذين الأقل خبرة بتأليف التعليمات البرمجية التي لن تعرض سلامة المستخدم للخطر.

يؤدي أيضًا الجمع بين وظائف الوقت الفعلي إلى تبسيط التحليل المطلوب لإثبات الوفاء بالمواعيد النهائية.

الخطوة 4: التصميم الموجه للاختبار

يعد الاختبار أمرًا بالغ الأهمية لكل نظام مضمن. يعد إجراء الاختبار على مستويات متعددة أمرًا إلزاميًا ومهمًا للغاية. تشمل مستويات الاختبار الرئيسية ما يلي:

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

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

3. تؤكد اختبارات الوحدة أن مكونات البرنامج المحددة، المحددة في التصميم الوسيط، تعمل على النحو المقصود من قبل المطور.

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

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

لتبسيط عملية تطوير التكامل واختبارات الوحدة واستخدامها وصيانتها، من المفيد هيكلة البرنامج الثابت بما يتماشى مع إطار عمل اختبار البرنامج. تتمثل الإستراتيجية المثلى في تصميم الاتصال بين جميع عناصر البرنامج على المستويات التي سيتم اختبارها.

الخطوة 5: الاستعداد للتغيير

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

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

وبالمثل، تعمل البنية الأقوى على تسهيل دمج الميزات الجديدة بسلاسة دون المساس بوظيفة المنتج.