تصميم البرمجيات

الفصل السادس - دليل شامل لمبادئ هندسة البرمجيات في التصميم

مقدمة في تصميم البرمجيات

قدم ميتش كابور، مبتكر Lotus 1-2-3، "مانيفستو تصميم البرمجيات" الذي ينص على أن تصميم البرمجيات الجيد يجب أن يظهر:

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

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

ما هو تصميم البرمجيات؟

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

الغرض من التصميم

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

  • هل يحتوي التصميم على أخطاء أو تناقضات أو أوجه قصور؟
  • هل هناك بدائل تصميم أفضل؟
  • هل يمكن تنفيذ التصميم ضمن القيود والجدول الزمني والتكلفة المحددة؟

من نموذج التحليل إلى نموذج التصميم

تصميم البيانات/الفئات

يحول فئات التحليل إلى فئات تصميم/فئات تنفيذ مع هياكل البيانات المطلوبة لتنفيذ البرمجيات.

التصميم المعماري

يحدد العلاقة بين العناصر الهيكلية الرئيسية للبرمجيات؛ تساعد الأنماط المعمارية وأنماط التصميم في تحقيق المتطلبات.

تصميم الواجهات

يحدد كيفية تواصل عناصر البرمجيات وعناصر الأجهزة والمستخدمين النهائيين.

التصميم على مستوى المكونات

يحول العناصر الهيكلية لهندسة البرمجيات إلى وصف إجرائي لمكونات البرمجيات.

التصميم والجودة

خصائص الجودة

يجب أن يتمتع التصميم عالي الجودة بـ:

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

إرشادات الجودة

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

مبادئ التصميم

مبادئ التصميم الأساسية

١. تجنب النظرة النفقية

يجب ألا يعاني التصميم من التركيز الضيق. ضع في الاعتبار جميع جوانب وتأثيرات قرارات التصميم.

٢. القدرة على التتبع

يجب أن يكون التصميم قابلاً للتتبع إلى نموذج التحليل، مما يضمن معالجة جميع المتطلبات.

٣> إعادة الاستخدام

يجب ألا يعيد التصميم اختراع العجلة. يجب تصميم مكونات البرمجيات لإعادة الاستخدام الفعال لزيادة الإنتاجية.

٤. تقليل المسافة الفكرية

يجب أن يقلل التصميم الفجوة بين البرمجيات والمشكلة الواقعية التي تحلها.

٥. التوحيد والتكامل

يجب أن يظهر التصميم التوحيد والتكامل عبر جميع المكونات.

٦. استيعاب التغيير

يجب هيكلة التصميم لاستيعاب التغيير بسلاسة.

٧. التدهور الرشيق

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

٨. فصل الاهتمامات

التصميم ليس كتابة كود، وكتابة الكود ليس تصميمًا. كل مرحلة لها هدفها المميز.

٩. تقييم الجودة

يجب تقييم التصميم من حيث الجودة أثناء إنشائه، وليس بعد ذلك.

١٠. معالجة الدلالية قبل التركيبية

يجب مراجعة التصميم لتقليل الأخطاء المفاهيمية (الغموض وعدم الاتساق) قبل التعامل مع الأخطاء التركيبية.

النماذج الأولية

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

مهم: يجب أن يشارك الاختبار من المراحل الأولية للتصميم.

المفاهيم الأساسية

١. التجريد

التجريد يعني مستويات مختلفة من وصف التصميم. إنه مفهوم أساسي يسمح للمصممين بالعمل على مستويات تفاصيل مختلفة.

٢. الهندسة المعمارية

الهيكل العام للبرمجيات والطرق التي يوفر بها هذا الهيكل النزاهة المفاهيمية للنظام.

٣. الأنماط

تنقل الأنماط جوهر حلول التصميم المجربة. تمثل ما ثبت بالفعل أنه أفضل حل تصميم لمشكلة معينة.

٤. التحسين

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

٥. البرمجة الموجهة نحو الجوانب (AOP)

جانب البرنامج هو ميزة مرتبطة بالعديد من الأجزاء الأخرى من البرنامج ولكنها غير مرتبطة بوظائفه الأساسية. يعبر الجانب عن اهتمامات البرنامج الأساسية.

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

أفضل الممارسات

فصل الاهتمامات

يمكن التعامل مع أي مشكلة معقدة بسهولة أكبر إذا تم تقسيمها إلى أجزاء.

الوحدات

تجميع البيانات والوظائف المقترنة بشدة في وحدات (حزم أو مكتبات).

الاستقلال الوظيفي

وظيفة واحدة واقتران منخفض بين المكونات.

إخفاء المعلومات

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

إعادة الهيكلة

تقنية إعادة تنظيم تبسط التصميم دون تغيير الوظائف.

مبادئ SOLID

المسؤولية الفردية، المفتوح/المغلق، استبدال ليسكوف، فصل الواجهات، انعكاس التبعية.

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

"الهيكل العام للبرمجيات والطرق التي يوفر بها هذا الهيكل النزاهة المفاهيمية للنظام."

تشير هندسة البرمجيات إلى هيكل النظام، المكون من مكونات البرنامج/النظام المختلفة، وخصائص (صفات) تلك المكونات، والعلاقات بينها. تتيح هندسة البرمجيات لمهندسي البرمجيات تحليل تصميم البرمجيات بكفاءة.

الجوانب المعمارية الرئيسية

الخصائص الهيكلية

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

الخصائص غير الوظيفية (الإضافية)

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

  • الأداء
  • السعة
  • الموثوقية
  • الأمان
  • القدرة على التكيف
  • خصائص النظام الأخرى

عائلات الأنظمة ذات الصلة

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

الوحدات

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

في هندسة البرمجيات، تشير الوحدات إلى المدى الذي يتم فيه تقسيم تطبيق البرمجيات/الويب إلى وحدات صغيرة. الوحدات هي السمة الأهم للبرمجيات التي تتيح إدارة البرنامج فكريًا.

هيكل الوحدة

البرنامج الرئيسي → الوحدات → الوظائف → بيانات الوحدة

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

إخفاء المعلومات

لماذا إخفاء المعلومات؟

  • يقلل من احتمالية "الآثار الجانبية"
  • يحد من التأثير العالمي لقرارات التصميم المحلية
  • يؤكد على الاتصال من خلال واجهات خاضعة للرقابة
  • يثبط استخدام البيانات العامة
  • يؤدي إلى التغليف - سمة من سمات التصميم عالي الجودة
  • ينتج برمجيات عالية الجودة

تخفي الوحدات "أسرارًا" تشمل:

  • الخوارزميات
  • هياكل البيانات
  • تفاصيل الواجهات الخارجية
  • سياسات تخصيص الموارد

التحسين التدريجي

التحسين التدريجي هو استراتيجية تصميم من أعلى إلى أسفل تستخدم لتفكيك النظام من مستوى عالٍ من التجريد إلى مستوى أكثر تفصيلاً. يتم تطوير تسلسل هرمي من خلال تحليل بيان وظيفي مجهري خطوة بخطوة حتى يتم الوصول إلى عبارات لغة البرمجة.

العملية: تبدأ ببيان وظيفي محدد على مستوى عالٍ من التجريد. يصف البيان الوظيفة أو المعلومات بشكل مفاهيمي ولكنه لا يوفر معلومات عن الآليات الداخلية. ثم تقدم المزيد والمزيد من التفاصيل مع كل تحسين لاحق.

ملاحظة: التجريد والتحسين هما مفهومان مكملان. يساعد التحسين في إدارة التعقيد من خلال التفكير في تفاصيل منخفضة المستوى مع تقدم التصميم.

الاستقلال الوظيفي

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

يتم تقييم استقلالية المكون باستخدام معيارين:

التماسك (داخل الوحدة)

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

الهدف: تماسك عالي

الاقتران (بين الوحدات)

مؤشر على الاعتماد المتبادل النسبي بين الوحدات. يعتمد الاقتران على تعقيد الواجهة بين الوحدات، ونقاط الدخول/المرجع، والبيانات المنقولة عبر الواجهات.

الهدف: اقتران منخفض

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

مستويات التجريد المعماري

المستوى الوصف التركيز
الهندسة المعمارية الصغيرة تهتم بهندسة البرامج الفردية كيفية تفكيك البرامج الفردية إلى مكونات
الهندسة المعمارية الكبيرة تهتم بأنظمة المؤسسات المعقدة أنظمة تشمل أنظمة وبرامج ومكونات أخرى موزعة على أجهزة كمبيوتر مختلفة

المتطلبات غير الوظيفية تحدد النمط المعماري

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

أنماط الهندسة المعمارية

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

يجب أن تتضمن الأنماط معلومات حول متى تكون مفيدة ومتى لا تكون. يمكن تمثيل الأنماط باستخدام أوصاف جدولية ورسومية.

نمط Model-View-Controller (MVC)

الوصف

يفصل العرض والتفاعل عن بيانات النظام. يتم هيكلة النظام إلى ثلاثة مكونات منطقية تتفاعل مع بعضها البعض:

  • النموذج: يدير بيانات النظام والعمليات المرتبطة بتلك البيانات
  • العرض: يحدد ويدير كيفية عرض البيانات للمستخدم
  • المتحكم: يدير تفاعل المستخدم (مثل ضغطات المفاتيح، نقرات الفأرة) ويمرر هذه التفاعلات إلى العرض والنموذج

متى يستخدم

يستخدم عندما تكون هناك طرق متعددة لعرض البيانات والتفاعل معها. يستخدم أيضًا عندما تكون متطلبات المستقبل للتفاعل وعرض البيانات غير معروفة.

المزايا

  • يسمح للبيانات بالتغير بشكل مستقل عن تمثيلها والعكس صحيح
  • يدعم عرض نفس البيانات بطرق مختلفة
  • التغييرات التي تم إجراؤها في تمثيل واحد تظهر في جميعها

العيوب

يمكن أن يتضمن كودًا إضافيًا وتعقيدًا في الكود عندما يكون نموذج البيانات والتفاعلات بسيطة.

هندسة MVC

المستخدم → يرى → العرض

المستخدم → يستخدم → المتحكم

المتحكم → يتلاعب → النموذج

النموذج → يحدث → العرض

قاعدة البيانات ↔ النموذج

المبدأ الرئيسي: MVC هو مثال على فصل الاهتمامات، وهو أساسي لتصميم البرمجيات الجيد.

الهندسة المعمارية ذات الطبقات

الوصف

يستخدم لنمذجة واجهة الأنظمة الفرعية. ينظم النظام إلى مجموعة من الطبقات (أو الآلات المجردة)، كل منها يوفر مجموعة من الخدمات.

المزايا

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

الطبقات النموذجية (من الأعلى إلى الأسفل)

  1. واجهة المستخدم - طبقة العرض (HTML5، JavaScript، CSS)
  2. إدارة واجهة المستخدم / المصادقة والتفويض
  3. منطق الأعمال الأساسي / وظائف التطبيق / أدوات النظام - طبقة التطبيق (Java، .NET، C#، Python، C++)
  4. دعم النظام (نظام التشغيل، قاعدة البيانات، إلخ) - طبقة البيانات (MySQL، Oracle، PostgreSQL، SQL Server، MongoDB)

هندسة الخادم-العميل

الهندسة ذات المستويين

العميل النحيل

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

العميل السمين

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

الهندسة المعمارية المركزية على البيانات/المستودع

الخصائص

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

التركيز

كيفية وضع البيانات حتى يتمكن الجميع من الوصول إليها بشكل متكرر.

مثال

يتم وضع بيانات المؤسسة على الخادم ويصل إليها جميع الموظفين (بيانات السحابة).

الاستخدام

  • يدعم هذا النوع من التصميم العديد من هندسات خدمات الويب (Microsoft .NET، Java 2 Enterprise Edition)
  • تستخدمه Siebel وOracle
  • عندما تكون القضية المركزية هي التخزين والتمثيل والإدارة واسترجاع كميات كبيرة من البيانات المستمرة ذات الصلة

الفوائد الرئيسية

  • هدف دمج البيانات
  • العملاء مستقلون نسبيًا عن بعضهم البعض (يمكن إضافتهم أو إزالتهم أو تغييرهم)
  • مخزن البيانات مستقل عن العملاء

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

هندسة تدفق البيانات/الأنابيب والمرشحات

التركيز

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

المكونات

يحتوي نمط الأنبوب والمرشح على مجموعة من المكونات، تسمى المرشحات، متصلة بواسطة أنابيب تنقل البيانات من مكون إلى التالي.

خصائص المرشح

  • يعمل كل مرشح بشكل مستقل عن المكونات في المنبع والمصب
  • مصمم لتوقع إدخال بيانات بصيغة معينة
  • ينتج إخراج بيانات بصيغة محددة
  • لا يتطلب معرفة بكيفية عمل المرشحات المجاورة

الدفعات المتسلسلة

إذا تحول تدفق البيانات إلى سطر واحد من التحويلات، فإنه يسمى الدفعات المتسلسلة. يقبل هذا الهيكل دفعة من البيانات ويطبق سلسلة من المكونات المتسلسلة (المرشحات) لتحويلها.

هندسة الأنبوب والمرشح

الإدخال → مرشح → أنبوب → مرشح → أنبوب → مرشح → الإخراج

(مسارات متوازية متعددة ممكنة مع مرشحات متصلة عبر أنابيب)

تصميم الواجهات

يجب أن تكون واجهة المستخدم: سهلة التعلم، سهلة الاستخدام، سهلة الفهم، سريعة الاستجابة، وجذابة.

ما هو تصميم الواجهة؟

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

فئات واجهات المستخدم

  • واجهة سطر الأوامر (CLI)
  • واجهة المستخدم الرسومية (GUI)

قضايا التصميم

وقت الاستجابة

يجب أن يستجيب النظام بسرعة لإجراءات المستخدم

مرافق المساعدة

توفير مساعدة وتوثيق كافيين

معالجة الأخطاء

معالجة الأخطاء والتواصل بشأنها بسلاسة

تسمية القوائم والأوامر

استخدام تسميات واضحة ومتسقة

إمكانية الوصول إلى التطبيق

ضمان وصول جميع المستخدمين إلى الميزات

التدويل

دعم لغات ومناطق متعددة

القواعد الذهبية لتصميم الواجهات

١. ضع المستخدم في السيطرة

  • حدد التفاعل بحيث لا يُجبر المستخدمون على تنفيذ إجراءات غير ضرورية
  • وفر تفاعلًا ودودًا مع المستخدم
  • أخفِ التفاصيل التقنية الداخلية عن المستخدمين العاديين

٢. قلل من حمل ذاكرة المستخدم

  • قلل المطالب على الذاكرة قصيرة المدى
  • أنشئ إعدادات افتراضية ذات معنى
  • حدد اختصارات للمستخدمين ذوي الخبرة

٣. اجعل الواجهة متسقة

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

أخطاء التصميم النموذجية التي يجب تجنبها

  • عدم الاتساق
  • تطلب الكثير من الحفظ
  • عدم وجود إرشادات أو مساعدة
  • عدم وجود حساسية للسياق
  • وقت استجابة ضعيف
  • رسائل غير واضحة أو غير ودية

تحليل الواجهة

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

تحليل الواجهة يعني فهم:

  1. الأشخاص (المستخدمون النهائيون) الذين سيتفاعلون مع النظام من خلال الواجهة
  2. المهام التي يجب على المستخدمين النهائيين تنفيذها للقيام بعملهم
  3. المحتوى الذي يتم تقديمه كجزء من الواجهة
  4. البيئة التي سيتم فيها إجراء هذه المهام

تصميم واجهة تطبيقات الويب

يجب أن تجيب واجهة تطبيق الويب على ثلاثة أسئلة رئيسية للمستخدم النهائي:

أين أنا؟

يجب أن تقوم الواجهة بـ:

  • توفير مؤشر على تطبيق الويب الذي تم الوصول إليه
  • إعلام المستخدم بالموقع في التسلسل الهرمي للمحتوى

ماذا يمكنني أن أفعل الآن؟

يجب أن تساعد الواجهة المستخدمين على فهم:

  • ما هي الوظائف المتاحة؟ (مثل القائمة الفرعية)
  • ما هي الروابط النشطة؟ (ممكنة أو معطلة)
  • ما هو المحتوى ذو الصلة؟

أين كنت، وإلى أين أنا ذاهب؟

يجب أن تسهل الواجهة التنقل:

  • توفير "خريطة" توضح أين كان المستخدم
  • عرض مسارات للانتقال إلى مكان آخر داخل تطبيق الويب

خصائص واجهات تطبيقات الويب الفعالة

يقترح بروس توغنوزي:

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

الملخص والنقاط الرئيسية

مبادئ التصميم الأساسية

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

عملية التصميم خطوة بخطوة

  1. افحص نموذج مجال المعلومات وصمم هياكل البيانات المناسبة
  2. اختر نمطًا معماريًا وأنماط تصميم مناسبة
  3. قسّم نموذج التحليل إلى أنظمة فرعية للتصميم
  4. صمم واجهات النظام الفرعي
  5. خصص فئات أو وظائف التحليل لكل نظام فرعي
  6. أنشئ مجموعة من فئات أو مكونات التصميم
  7. حول كل فئة تحليل إلى فئة تصميم
  8. تحقق من كل فئة تصميم مقابل معايير التصميم
  9. حدد الأساليب المرتبطة بكل فئة تصميم
  10. قيم واختر أنماط التصميم
  11. صمم الواجهات المطلوبة مع الأنظمة الخارجية
  12. صمم واجهة المستخدم
  13. أجرِ تصميمًا على مستوى المكونات
  14. حدد الخوارزميات وحسّن واجهات المكونات

تذكر

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