‫هندسة البرمجيات الطبعة التاسعة إيان سومرفيل أديسون ويسلي بوسطن كولومبوس إنديانابوليس نيويورك سان فرانسيسكو نهر

السرج‬
‫العلوي أمستردام كيب تاون دبي لندن مدريد ميالن ميونيخ باريس مونتلاير تورونتو دلهي مكسيكو سيتي ساو باولو سيدني هونغ كونغ‬
‫سيول سنغافورة تايبيه طوكيو المدير اإلقليمي‪ :‬مارسيا هورتون رئيس التحرير‪ :‬مايكل هيرش محرر التزويد‪ :‬مات جولدشتاين مساعد‬
‫التحرير‪ :‬تشيلسي بيل مدير التحرير‪ :‬جيف هولكومب مدير مشروع اإلنتاج األول‪ :‬مارلين لويد مديرة التسويق‪ :‬مارغريت وابلز منسق‬
‫التسويق‪ :‬كاثرين فيرانتي مشتري التصنيع األقدم‪ :‬كارول ميلفيل مصمم النص‪ :‬سوزان ريمون مدير فن الغالف‪ :‬إيلينا سيدوروفا صورة‬
‫إدارة مشروع خدمة ‪: © graficart.net/Alamy‬افتتاح باب داخلي ‪: © Jacques Pavlovsky / Sygma / Corbis‬الغالف األمامي‬
‫التكوين والرسوم ‪ PreMedia Global، Inc.‬قسم من ‪ ، GGS Higher Education Resources ،‬كاملة‪ :‬أندريا ستيفانوفيتش‬
‫الطابعة ‪ /‬بيندر‪ :‬إدواردز براذرز طابعة ‪ PreMedia Global ، Inc.‬قسم من ‪: GGS Higher Education Resources ،‬التوضيحية‬
‫‪ Pearson‬حقوق النشر © ‪: Lehigh-Phoenix Color / Hagerstown 1996 ، 2001 ، 2005 ، 2006 ، 2011‬الغالف‬
‫الجميع الحقوق محفوظة‪ .‬صُنع في الواليات المتحدة األمريكية‪ .‬هذا المنشور ‪ُ Addison-Wesley.‬تنشر باسم ‪Education، Inc. ،‬‬
‫محمي بموجب حقوق النشر ‪ ،‬ويجب الحصول على إذن من الناشر قبل أي نسخ أو تخزين محظور في ملف نظام االسترجاع ‪ ،‬أو‬
‫اإلرسال بأي شكل أو بأي وسيلة ‪ ،‬إلكترونية ‪ ،‬ميكانيكية ‪ ،‬تصوير ‪ ،‬التسجيل أو بالمثل‪ .‬للحصول على إذن (تصاريح) الستخدام مادة من‬
‫‪ Boylston Street ، Suite‬قسم األذونات ‪ Pearson Education، Inc. ، 501 ،‬هذا العمل ‪ ،‬يرجى إرسال رسالة مكتوبة طلب إلى‬
‫ماساتشوستس ‪ . 02116‬يُزعم أن العديد من التعيينات من قبل الشركات المصنعة والبائع للتمييز بين منتجاتهم ‪900 ، Boston ،‬‬
‫كتجارة‪ -‬عالمات‪ .‬حيث تظهر تلك التسميات في هذا الكتاب ‪ ،‬وكان الناشر على علم بدعوى العالمة التجارية ‪ ،‬تم طباعة التعيينات‬
‫بأحرف استهاللية أولية أو جميع األحرف االستهاللية‪ .‬مكتبة الكونغرس بيانات الفهرسة في والنشر سومرفيل ‪ ،‬إيان هندسة البرمجيات‪/ W‬‬
‫ايان سومرفيل‪ - .‬الطبعة التاسعة‪ .‬ص‪ .‬سم‪ .‬يشمل الفهرس‪ .‬ردمك ‪ 1-703515-13-0-978 :13‬ردمك ‪2-703515-13-0 :10‬‬
‫‪ .1. QA76.758.S657 2011 005.1 - dc22 2009053058 10 9 8 7 6 5 4 3 2 1 – EB –14‬هندسة البرمجيات‪ .‬أوال العنوان‬
‫ردمك ‪ 2-703515-13-0 :10‬ردمك ‪ 1-703515-13-0-978 :13‬تمهيد أدركت أنني كنت أكتب الفصول األخيرة ‪13 12 11 10‬‬
‫من هذا الكتاب في صيف ‪ 2009‬أن هندسة البرمجيات كانت تبلغ من العمر ‪ 40‬عامًا‪ .‬كان اسم "هندسة البرمجيات" تم اقتراحه في عام‬
‫‪ 1969‬في مؤتمر الناتو لمناقشة‪ W‬مشاكل تطوير البرمجيات‪ - W‬تأخرت أنظمة البرامج الكبيرة ‪ ،‬ولم تقدم الوظائف التي يحتاجها المستخدمين‬
‫‪ ،‬بتكلفة أعلى مما كان متوقعً ا ‪ ،‬وكانوا غير موثوقين‪ .‬لم أحضر ذلك المؤتمر ولكن بعد مرور عام ‪ ،‬كتبت أول برنامج لي وبدأت حياتي‬
‫ملحوظ ا خالل حياتي المهنية‪ -‬وقت‪ .‬لم تستطع مجتمعاتنا العمل بدون‬‫ً‬ ‫المهنية في مجال البرمجيات‪ .‬لقد كان التقدم في هندسة البرمجيات‬
‫و ‪ SAP‬و ‪ SaaS‬و ‪ — J2EE ، .NET‬أنظمة برمجيات احترافية كبيرة‪ .‬لبناء أنظمة األعمال ‪ ،‬هناك مجموعة من التقنيات األبجدية‬
‫وما إلى ذلك ‪ -‬التي تدعم التطوير و نشر تطبيقات المؤسسة‪ W‬الكبيرة‪ .‬المرافق والبنية التحتية الوطنية ‪ CBSE -‬و ‪ SOAP‬و ‪BPEL4WS‬‬
‫الطاقة واالتصاالت والنقل ‪ -‬كلها تعتمد على التعقيد والموثوقية في الغالب أنظمة الكمبيوتر‪ .‬سمحت لنا البرمجيات باستكشاف الفضاء‬
‫وإنشاء العالم وايد ويب ‪ ،‬أهم نظام معلومات في التاريخللبشرية‪ .‬تواجه البشرية اآلن مجموعة جديدة من التحديات ‪ -‬تغير المناخ‬
‫والتحديات المتطرفة الطقس ‪ ،‬وتدهور الموارد الطبيعية ‪ ،‬وزيادة عدد سكان العالم المطلوب إطعامهم و المسكن ‪ ،‬واإلرهاب الدولي ‪،‬‬
‫والحاجة إلى مساعدة كبار السن تؤدي إلى إرضاء وحياة راضية‪ .‬نحتاج إلى تقنيات جديدة لمساعدتنا في معالجة هذه المشكالت‪، W‬‬
‫بالتأكيد ‪ ،‬ستلعب البرامج دورً ا مركز ًي ا في هذه التقنيات‪ .‬لذلك فإن هندسة البرمجيات هي تقنية بالغة األهمية للمستقبل للبشرية‪ .‬يجب أن‬
‫تعقيدا‪ .‬بالطبع ‪ ،‬ال يزال هناك مشاكل‬ ‫ً‬ ‫نستمر في تثقيف مهندسي البرمجيات وتطوير القرص حتى نتمكن من إنشاء أنظمة برمجية أكثر‬
‫مع مشاريع البرمجيات‪ .‬ال يزال البرنامج متأخرً ا في بعض األحيان ويكلف أكثر مما كان متوقعا‪ .‬ومع ذلك ‪ ،‬ال ينبغي أن ندع هذه‬
‫التي تم تطويرها‪ .‬تعد ‪- nologies‬المشاكل تخفي النجاحات‪ W‬الحقيقية في هندسة البرمجيات وأساليب وتقنيات هندسة البرمجيات الرائعة‬
‫هندسة البرمجيات اآلن مجااًل ضخ ًم ا لدرجة أنه من المستحيل تغطية الموضوع كله في كتاب واحد‪ .‬ولذلك فإن تركيزي ينصب على‬
‫الموضوعات الرئيسية التي تعتبر مقدمة أساسية لجميع عمليات التطوير والموضوعات المعنية بتطوير موثوق ‪ ،‬االنظمة الموزعة‪ .‬هناك‬
‫ً‬
‫راسخا أن األساليب الرشيقة لها مكانها‪ W‬ولكن أيضً ا "التقليدية‪-‬‬ ‫ً‬
‫اعتقادا‬ ‫تركيز متزايد على األساليب والبرامج الرشيقة إعادة استخدام‪ .‬أعتقد‬
‫هندسة البرمجيات القائمة على الخطة‪ .‬نحن بحاجة إلى الجمع بين أفضل هذه مناهج لبناء أنظمة برمجية أفضل‪ .‬تعكس الكتب حتمًا آراء‬
‫وتحيزات مؤلفيها‪ .‬يقرأ البعض‪ -‬سوف يختلفون حتما مع آرائي ومع اختياري للمواد‪ .‬مثل الخالف هو انعكاس صحي لتنوع االنضباط‬
‫وهو أمر ضروري لتطورها‪ .‬ومع ذلك ‪ ،‬آمل أن يقوم جميع مهندسي البرمجيات‪ W‬ومهندسي البرمجيات بما يلي‪ :‬يمكن للطالب الجدد‬
‫العثور على شيء مثير لالهتمام هنا‪ .‬التكامل مع الويب هناك قدر ال يصدق من المعلومات حول هندسة البرمجيات‪ W‬المتاحة على تساءل‬
‫الويب وبعض األشخاص عما إذا كانت الكتب المدرسية مثل هذا ال تزال مطلوبة‪ .‬ومع ذلك ‪ ،‬فإن جودة المعلومات المتاحة غير مكتملة‬
‫للغاية ‪ ،‬والمعلومات في بعض األحيان تم تقديمها بشكل سيئ وقد يكون من الصعب العثور على المعلومات التي تحتاجها‪ .‬بالتالي‪ ،‬أعتقد‬
‫أن الكتب المدرسية ال تزال تلعب دورً ا مه ًم ا في التعلم‪ .‬أنها بمثابة خارطة طريق للموضوع والسماح بتنظيم المعلومات حول الطريقة‬
‫والتقنيات وعرضها بطريقة متماسكة ومقروءة‪ .‬كما أنها توفر نقطة انطالق لـ استكشاف أعمق لمؤلفات البحث والمواد المتاحة على‬
‫راسخ ا أن الكتب المدرسية لها مستقبل ولكن فقط إذا تم دمجها معه وإضافة قيمة إلى المواد الموجودة على الويب‪.‬‬ ‫ً‬ ‫ً‬
‫اعتقادا‬ ‫الويب‪ .‬أعتقد‬
‫لذلك تم تصميم هذا الكتاب ليكون الطباعة المختلطة ‪ /‬نص الويب الذي ترتبط به المعلومات األساسية في اإلصدار المطبوع مواد تكميلية‬
 ‫على الويب‪ .‬تقريبا جميع الفصول مكتوبة بشكل خاص "أقسام الويب" التي تضيف إلى المعلومات الواردة في هذا الفصل‪ .‬هناك أيضًا‬
‫‪:‬أربعة "ويب الفصول حول الموضوعات التي لم أقم بتغطيتها في النسخة المطبوعة من الكتاب‪ .‬موقع الويب المرتبط بالكتاب هو‬
‫تتكون شبكة الكتاب من أربعة مكونات رئيسية‪ .1 :‬أقسام الويب هذه أقسام إضافية ‪http://www.SoftwareEngineering-9.com‬‬
‫تضيف إلى المحتوى المقدم في كل منها الفصل‪ .‬ترتبط أقسام الويب هذه من مربعات منفصلة في كل فصل‪ .2 .‬فصول الويب هناك أربعة‬
‫فصول على شبكة اإلنترنت تغطي األساليب الرسمية ‪ ،‬والتفاعل التصميم والتوثيق ود معماريات‪ W‬التطبيق‪ .‬يمكنني إضافة فصول أخرى‬
‫حول مواضيع جديدة خالل عمر الكتاب‪ . 3 .‬مواد للمعلمين تهدف المواد الواردة في هذا القسم إلى دعم‪ -‬األشخاص الذين يقومون بتدريس‬
‫هندسة البرمجيات‪ .‬راجع قسم "مواد الدعم" في هذه المقدمة‪ .4 .‬دراسات الحالة توفر معلومات إضافية حول دراسات الحالة المستخدمة‪W‬‬
‫باإلضافة إلى معلومات حول دراسات الحالة ‪ v‬في الكتاب (مضخة األنسولين ‪ ،‬نظام الرعاية الصحية العقلية ‪ ،‬نظام الطقس البري) مقدمة‬
‫ضا روابط لمواقع أخرى تحتوي على مواد مفيدة هندسة‬ ‫األخرى ‪ ،‬مثل فشل قاذفة‪ W‬آريان ‪ .5‬باإلضافة إلى هذه األقسام ‪ ،‬هناك أي ً‬
‫البرمجيات‪ ، W‬مزيد من القراءة ‪ ،‬المدونات ‪ ،‬الرسائل اإلخبارية ‪ ،‬إلخ‪ .‬أرحب بتعليقاتكم واقتراحاتكم البناءة حول الكتاب و موقع إلكتروني‪.‬‬
‫في موضوع رسالتك‪ .‬خالف ذلك ‪ ،‬من ]‪ [SE9‬يرجى تضمين ‪ ian@SoftwareEngineering-9.com.‬يمكنك االتصال بي على‬
‫المحتمل أن تكون مرشحات‪ W‬البريد العشوائي الخاصة بي رفض بريدك ولن تتلقى ر ًدا‪ .‬ليس لدي وقت لمساعدة الطالب مع واجباتهم‬
‫المدرسية ‪ ،‬لذا من فضلك ال تسأل‪ .‬القراء يستهدف الكتاب في المقام األول طالب الجامعات والكليات الذين يأخذون مرحلة تمهيدية‬
‫ودورات متقدمة في هندسة البرمجيات واألنظمة‪ .‬مهندسو البرمجيات‪ W‬في قد تجد الصناعة الكتاب مفي ًدا كقراءة عامة وكوسيلة للتحديث‬
‫معرفتهم بموضوعات مثل إعادة استخدام البرامج والتصميم المعماري واالعتمادية واألمن وتحسين العملية‪ .‬أفترض أن القراء قد أكملوا‬
‫دورة البرمجة التمهيدية وعلى دراية بمصطلحات البرمجة‪ .‬التغييرات من الطبعات السابقة احتفظ هذا اإلصدار بالمواد األساسية المتعلقة‬
‫بهندسة البرمجيات التي كانت تمت تغطيته في اإلصدارات السابقة ولكني قمت‪ W‬بمراجعة وتحديث جميع الفصول ولديها تضمنت مواد‬
‫جديدة حول العديد من الموضوعات المختلفة‪ .‬أهم التغييرات هي‪ . 1 :‬االنتقال من كتاب مطبوع فقط إلى كتاب مطبوع ‪ /‬كتاب ويب مختلط‬
‫مع رفيق الويب‪ -‬اللاير مدمج بإحكام مع أقسام الكتاب‪ .‬هذا سمح لي بالتقليل عدد الفصول في الكتاب والتركيز على المواد األساسية في‬
‫كل فصل‪ .2 .‬إعادة هيكلة كاملة لتسهيل استخدام الكتاب في تعليم البرمجيات‪ W‬هندسة‪ .‬يتكون الكتاب اآلن من أربعة أجزاء بدالً من ثمانية‬
‫أجزاء ويمكن أن يكون كل جزء منها مستخدمة‪ W‬بمفردها أو باالشتراك مع أجزاء أخرى كأساس‪ W‬للبرنامج دورة هندسية‪ .‬األجزاء األربعة‬
‫مقدمة لهندسة البرمجيات ‪ ،‬الموثوقية واألمان وهندسة البرمجيات المتقدمة ومهندس البرمجيات اإلدارة‪ .3 .‬يتم تقديم العديد من‬
‫إيجازا في واحدة الفصل ‪ ،‬مع نقل مواد إضافية إلى الويب‪ .4 .‬فصول ويب إضافية ‪ ،‬بنا ًء‬‫ً‬ ‫الموضوعات من الطبعات‪ W‬السابقة بشكل أكثر‬
‫لقد قمت بتحديث ومراجعة المحتوى في ‪ Web.vi 5.‬على فصول من الطبعات السابقة التي لدي غير مدرجة هنا ‪ ،‬متوفرة في مقدمة‬
‫جميع الفصول‪ .‬أقدر ذلك بين تمت إعادة كتابة ‪ ٪30‬و ‪ ٪40‬من النص بالكامل‪ .6 .‬لقد أضفت فصواًل جديدة حول تطوير البرمجيات‬
‫الرشيقة واألنظمة المدمجة‪ . 7 .‬باإلضافة إلى هذه الفصول الجديدة ‪ ،‬هناك مادة جديدة على المهندس الذي يحركه النموذج‪ -‬جي ‪ ،‬تطوير‬
‫نموذج ‪ ،‬معماريات أنظمة يمكن االعتماد عليها ‪ ،‬تحليل ‪ ، Reason’s Swiss Cheese‬المصادر المفتوحة ‪ ،‬التطوير القائم على االختبار‬
‫والبرمجيات‪ W‬كخدمة والتخطيط السريع‪ .8 .‬دراسة حالة جديدة حول نظام تسجيل المرضى ‪ COTS‬ثابت وفحص النموذج ‪ ،‬إعادة استخدام‬
‫للمرضى الذين يخضعون لها تم استخدام عالج مشاكل الصحة العقلية في عدة فصول‪ .‬استخدام الكتاب للتدريس لقد صممت‪ W‬الكتاب بحيث‬
‫يكونيمكن استخدامها في ثالثة أنواع مختلفة من البرامج الدورات الهندسية‪ .1 :‬دورات تمهيدية عامة في هندسة البرمجيات‪ W‬الجزء األول‬
‫من الكتاب تم تصميمه بشكل صريح لدعم دورة تمهيدية من فصل دراسي واحد هندسة البرمجيات‪ .2 .‬دورات تمهيدية أو متوسطة في‬
‫موضوعات هندسة برمجيات محددة أنت يمكن إنشاء‪ W‬مجموعة من الدورات التدريبية األكثر تقدمًا باستخدام الفصول الموجودة في‬
‫األجزاء ‪ .4-2‬ل على سبيل المثال ‪ ،‬قمت‪ W‬بتدريس دورة في هندسة النظم الحرجة باستخدام الفصول في الجزء ‪ 2‬باإلضافة إلى فصول‬
‫حول إدارة الجودة وإدارة التكوين‪ .3 .‬دورات أكثر تقد ًم ا في موضوعات هندسة برمجيات محددة في هذه الحالة ‪ ،‬فإن تشكل الفصول في‬
‫الكتاب أسا ًس ا للدورة التدريبية‪ .‬هذه ثم مرنة‪ -‬مع مزيد من القراءة التي تستكشف الموضوع بمزيد من التفصيل‪ .‬على سبيل المثال‪ ،‬يمكن‬
‫أن تستند الدورة التدريبية حول إعادة استخدام البرامج إلى الفصول ‪ 16‬و ‪ 17‬و ‪ 18‬و ‪ .19‬مزيد من المعلومات حول استخدام الكتاب‬
‫للتدريس ‪ ،‬بما في ذلك المقارنة مع اإلصدارات السابقة ‪ ،‬متاحة على موقع الكتاب على الويب‪ .‬مواد الدعم تتوفر مجموعة واسعة من‬
‫‪ PowerPoint‬مواد الدعم لمساعدة األشخاص الذين يستخدمون الكتاب في التدريس‪ -‬دورات هندسة البرمجيات‪ .‬هذا يتضمن‪ • :‬عروض‬
‫مقدمة السابع • دليل المعلم الذي يقدم نصائح حول كيفية استخدام الكتاب في دورات ‪ PowerPoint.‬لجميع فصول الكتاب‪ • .‬األشكال في‬
‫مختلفة ويشرح العالقة بين الفصول في هذه الطبعة والسابقة طبعات‪ • .‬مزيد من المعلومات حول دراسات الحالة للكتاب‪ • .‬دراسات حالة‬
‫إضافية حول هندسة النظم‪ • .‬أربعة فصول على شبكة ‪ PowerPoint‬إضافية يمكن استخدامها في دورات هندسة البرمجيات‪ • .‬عروض‬
‫اإلنترنت تغطي األساليب الرسمية وتصميم التفاعل والتطبيق المعماريات‪ W‬والتوثيق‪ .‬كل هذه المواد متاحة مجا ًنا لقراء الكتاب من موقع‬
‫أدناه‪ .‬مواد إضافية للمدربين متاح على أساس مقيد للمدربين المعتمدين فقط‪ Pearson • :‬الويب الخاص بالكتاب‪ -‬أو من موقع دعم‬
‫إجابات نموذجية لتمارين نهاية الفصل المختارة‪ • .‬أسئلة االختبار واإلجابات لكل فصل‪ .‬تتوفر جميع مواد الدعم ‪ ،‬بما في ذلك المواد‬
‫يمكن للمدرسين الذين يستخدمون الكتاب للتدريس ‪: http://www.pearsonhighered.com/sommerville/‬المحظورة ‪ ،‬من‬
‫اإللكتروني ‪ ،‬عن طريق االتصال بممثل ‪ Pearson‬الحصول على كلمة مرور للوصول مقيد المواد من خالل التسجيل في موقع‬
‫كلمات ‪ computing@aw.com.‬المحلي لديهم‪ -‬مستاء ‪ ،‬أو عن طريق طلب كلمة مرور عن طريق البريد اإللكتروني من ‪Pearson‬‬
‫المرور غير متوفرة من المؤلف‪ .‬شكر وتقدير ساهم عدد كبير من الناس على مر السنين في تطور هذا الكتاب وأود أن أشكر الجميع‬
‫(المراجعين والطالب ومستخدمي الكتاب) الذين لديهم علق على الطبعات السابقة وقدم اقتراحات بناءة للتغيير‪ .‬أود بشكل خاص أن أشكر‬
‫خاصة ألبنتي‪ً -‬‬
‫ثالثا ‪ ،‬جين ‪ ،‬التي اكتشفت موهبة‬ ‫ً‬ ‫عائلتي (آن وعلي وجين) على مساعدتهم و الدعم أثناء كتابة الكتاب‪ .‬شكراً جزيالً ‪-‬‬
‫التدقيق اللغوي والتحرير‪ .‬كانت تريمين‪ -‬دأب على قراءة الكتاب بأكمله وقام بعمل رائع في تحديد وإصالح ملف عدد كبير من األخطاء‬
‫المطبعية والنحوية‪ .‬إيان سومرفيل أكتوبر ‪ 2009‬المحتويات في لمحة مقدمة ثالثا الجزء ‪ 1‬مقدمة في هندسة البرمجيات‪ 1 W‬الفصل ‪1‬‬
‫مقدمة ‪ 3‬الفصل ‪ 2‬عمليات البرامج ‪ 27‬الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة ‪ 56‬الفصل الرابع ‪ -‬متطلبات الهندسة ‪ 82‬الفصل الخامس‬
‫نمذجة النظام ‪ 118‬الفصل السادس التصميم المعماري ‪ 147‬الفصل السابع التصميم والتنفيذ ‪ 176‬الفصل ‪ 8‬البرامج‪ 205‬الفصل التاسع‬
‫تطور البرمجيات ‪ 234‬الجزء الثاني االعتمادية واألمان ‪ 261‬الفصل العاشر النظم االجتماعية التقنية ‪ 263‬الفصل ‪ 11‬االعتمادية‬
‫واألمان ‪ 289‬الفصل ‪ 12‬االعتمادية ومواصفات األمان ‪ 309‬الفصل ‪ 13‬هندسة االعتمادية ‪ 341‬الفصل ‪ 14‬هندسة األمن ‪366‬‬
‫الفصل الخامس عشر االعتمادية والضمان األمني ‪ 393‬الجزء ‪ 3‬هندسة البرمجيات المتقدمة ‪ 423‬الفصل ‪ 16‬إعادة استخدام البرامج‬
‫‪ 425‬الفصل ‪ 17‬هندسة البرمجيات القائمة على المكونات ‪ 452‬الفصل الثامن عشر هندسة البرمجيات الموزعة ‪ 479‬الفصل التاسع‬
‫عشر العمارة الخدمية ‪ 508‬الفصل ‪ 20‬البرمجيات المضمنة ‪ 537‬الفصل ‪ 21‬هندسة البرمجيات الموجهة نحو الجانب ‪ 565‬الجزء ‪4‬‬
‫إدارة البرامج ‪ 591‬الفصل ‪ 22‬إدارة المشروع ‪ 593‬الفصل ‪ 23‬تخطيط المشروع ‪ 618‬الفصل ‪ 24‬إدارة الجودة ‪ 651‬الفصل ‪25‬‬
‫إدارة التكوين ‪ 681‬الفصل ‪ 26‬تحسين العملية ‪ 705‬مسرد المصطلحات ‪ 733‬فهرس الموضوع ‪ 749‬فهرس المؤلف ‪ 767‬المحتويات‬
‫مقدمة ثالثا الجزء ‪ 1‬مقدمة في هندسة البرمجيات ‪ 1‬الفصل ‪ 1‬مقدمة ‪ 1.1 3‬تطوير البرامج المهنية ‪ 1.2 5‬أخالقيات هندسة البرمجيات‬
‫‪ 1.3 14‬دراسات الحالة ‪ 17‬الفصل ‪ 2‬عمليات البرامج ‪ 2.1 27‬نماذج العمليات البرمجية ‪ 2.2 29‬العمليات العملية ‪ 2.3 36‬التعامل‬
‫مع التغيير ‪ 2.4 43‬العملية الموحدة العقالنية ‪ 50‬الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة ‪ 3.1 56‬طرق رشيقة ‪ 3.2 58‬التنمية السريعة‬
‫المحتويات ‪ 3.3‬البرمجة المتطرفة ‪ 3.4 64‬إدارة المشاريع الرشيقة ‪ 3.5 72‬طرق القياس الرشيقة ‪ 74‬الفصل ‪x‬والموجهة بخطة ‪62‬‬
‫الرابع ‪ -‬متطلبات الهندسة ‪ 4.1 82‬المتطلبات الوظيفية وغير الوظيفية ‪ 4.2 84‬وثيقة متطلبات البرمجيات ‪ 4.3 91‬مواصفات‬
‫المتطلبات ‪ 4.4 94‬عمليات هندسة المتطلبات ‪ 4.5 99‬استنباط المتطلبات وتحليلها ‪ 4.6 100‬التحقق من المتطلبات ‪ 4.7 110‬إدارة‬
‫المتطلبات ‪ 111‬الفصل الخامس نمذجة النظام ‪ 5.1 118‬نماذج السياق ‪ 5.2 121‬نماذج التفاعل ‪ 5.3 124‬النماذج اإلنشائية ‪129‬‬
‫‪ 5.4‬النماذج السلوكية ‪ 5.5 133‬الهندسة النموذجية ‪ 138‬الفصل السادس التصميم المعماري ‪ 6.1 147‬قرارات التصميم المعماري‬
‫‪ 6.2‬المناظر المعمارية ‪ 6.3 153‬األنماط المعمارية ‪ 6.4 155‬معماريات‪ W‬التطبيق ‪ 164‬الفصل السابع التصميم والتنفيذ ‪7.1 176‬‬
‫أنماط التصميم ‪ 189‬المحتويات ‪ 7.3 11‬قضايا التنفيذ ‪ 7.4 193‬تطوير المصادر ‪ UML 178 7.2‬التصميم الموجه للكائنات باستخدام‬
‫المفتوحة ‪ 198‬الفصل ‪ 8‬اختبار البرامج ‪ 8.1 205‬اختبار التطوير ‪ 8.2 210‬التطوير القائم على االختبار ‪ 8.3 221‬اختبار اإلصدار‬
‫‪ 8.4 224‬اختبار المستخدم ‪ 228‬الفصل التاسع تطور البرمجيات‪ 9.1 234 W‬عمليات التطور ‪ 9.2 237‬ديناميات تطور البرنامج ‪240‬‬
‫‪ 9.3‬صيانة البرمجيات ‪ 9.4 242‬إدارة النظام القديم ‪ 252‬الجزء الثاني االعتمادية واألمان ‪ 261‬الفصل العاشر النظم االجتماعية ‪263‬‬
‫‪ 10.1‬أنظمة معقدة ‪ 10.2 266‬هندسة النظم ‪ 10.3 273‬نظام المشتريات ‪ 10.4 275‬تطوير النظام ‪ 10.5 278‬تشغيل النظام ‪281‬‬
‫الفصل ‪ 11‬االعتمادية واألمان ‪ 11.1 289‬خصائص االعتمادية ‪ 11.2 291‬التوافر والموثوقية ‪ 11.3 295‬األمان ‪11.4 299‬‬
‫المحتويات الفصل ‪ 12‬االعتمادية ومواصفات األمان ‪ 12.1 309‬مواصفات المتطلبات التي تحركها المخاطر ‪xii 311‬األمن ‪302‬‬
‫‪ 12.2‬مواصفات السالمة ‪ 12.3 313‬مواصفة الموثوقية ‪ 12.4 320‬المواصفات األمنية ‪ 12.5 329‬المواصفات الرسمية ‪333‬‬
‫الفصل ‪ 13‬هندسة االعتمادية ‪ 13.1 341‬التكرار والتنوع ‪ 13.2 343‬عمليات يمكن االعتماد عليها ‪ 13.3 345‬معماريات‪ W‬أنظمة‬
‫يمكن االعتماد عليها ‪ 13.4 348‬برمجة يمكن االعتماد عليها ‪ 355‬الفصل ‪ 14‬هندسة األمن ‪ 14.1 366‬إدارة المخاطر األمنية ‪369‬‬
‫‪ 14.2‬تصميم لألمن ‪ 14.3 375‬بقاء النظام ‪ 386‬الفصل الخامس عشر‪393‬ـ مصلح ‪ 15.1‬التحليل الساكن ‪ 15.2 395‬اختبار‬
‫الموثوقية ‪ 15.3 401‬اختبار األمان ‪ 15.4 404‬ضمان العملية ‪ 15.5 406‬حاالت السالمة واالعتمادية ‪ 410‬الجزء ‪ 3‬هندسة‬
‫البرمجيات المتقدمة ‪ 423‬الفصل ‪ 16‬إعادة استخدام البرامج ‪ 16.1 425‬إعادة استخدام المشهد ‪ 16.2 428‬أطر التطبيق ‪431‬‬
‫الفصل ‪ 17‬هندسة البرمجيات القائمة على ‪ COTS 440‬خطوط إنتاج البرمجيات ‪ 16.4 434‬إعادة استخدام منتج ‪ xiii 16.3‬المحتويات‬
‫تكوين المكون ‪ 468‬الفصل الثامن عشر ‪ CBSE 461 17.3‬المكونات ‪ 17.1 452‬المكونات ونماذج المكونات ‪ 17.2 455‬عمليات‬
‫هندسة البرمجيات الموزعة ‪ 18.1 479‬إصدارات األنظمة الموزعة ‪ 18.2 481‬حوسبة العميل والخادم ‪ 18.3 488‬األنماط‬
‫المعمارية لألنظمة الموزعة ‪ 18.4 490‬البرمجيات‪ W‬كخدمة ‪ 501‬الفصل التاسع عشر العمارة الخدمية ‪ 19.1 508‬الخدمات‪ W‬كمكونات‬
‫قابلة إلعادة االستخدام ‪ 19.2 514‬هندسة الخدمات ‪ 19.3 518‬تطوير البرمجيات مع الخدمات ‪ 527‬الفصل ‪ 20‬البرمجيات المضمنة‬
‫‪ 20.1 537‬تصميم األنظمة المدمجة‪ 20.2 540 W‬األنماط المعمارية ‪ 20.3 547‬تحليل التوقيت ‪ 20.4 554‬أنظمة التشغيل في الوقت‬
‫الفعلي ‪ 558‬الفصل ‪ 21‬هندسة البرمجيات الموجهة نحو الجانب ‪ 21.1 565‬فصل االهتمامات‪ 21.2 567 W‬الجوانب ‪ ،‬ربط النقاط و‬
‫المحتويات الجزء ‪ 4‬إدارة البرامج ‪ 591‬الفصل ‪ 22‬إدارة المشروع ‪xiv‬هندسة البرمجيات مع الجوانب ‪pointcuts 571 21.3 576‬‬
‫‪ 22.1 593‬إدارة المخاطر ‪ 22.2 595‬إدارة األفراد ‪ 22.3 602‬العمل الجماعي ‪ 607‬الفصل ‪ 23‬تخطيط المشروع ‪23.1 618‬‬
‫تسعير البرامج ‪ 23.2 621‬التنمية المدفوعة بالخطة ‪ 23.3 623‬جدولة المشروع ‪ 23.4 626‬التخطيط الرشيق ‪ 23.5 631‬تقنيات‬
‫التقدير ‪ 633‬الفصل ‪ 24‬إدارة الجودة ‪ 24.1 651‬جودة البرمجيات‪ 24.2 655 W‬معايير البرمجيات ‪ 24.3 657‬المراجعات والتفتيش‬
‫‪ 24.4 663‬برامج القياس والمقاييس ‪ 668‬الفصل ‪ 25‬إدارة التكوين ‪ 25.1 681‬إدارة التغيير ‪ 25.2 685‬إدارة اإلصدار‬
‫‪ 25.3 690.0000‬بناء النظام ‪ 25.4 693‬إدارة اإلصدار ‪ 699‬الفصل ‪ 26‬تحسين العملية ‪ 26.1 705‬عملية تحسين العملية ‪708‬‬
‫‪ CMMI‬تحليل العملية ‪ 26.4 715‬تغيير العملية ‪ 26.5 718‬إطار عمل تحسين عملية ‪ 26.2 xv 26.3‬قياس العملية ‪ 711‬المحتويات‬
‫عمدا ‪721‬‬ ‫هدفي في هذا ‪ PART‬مسرد المصطلحات‪ 733 W‬فهرس الموضوع ‪ 749‬فهرس المؤلف ‪ 767‬تركت هذه الصفحة فارغة ً‬
‫الجزء من الكتاب هو تقديم مقدمة عامة عن هندسة البرمجيات‪ .‬أقدم مفاهيم مهمة مثل البرمجيات العمليات واألساليب الرشيقة ‪ ،‬ووصف‬
‫تطوير البرامج األساسية األنشطة ‪ ،‬من المواصفات األولية للبرنامج إلى تطور النظام‪ .‬تم تصميم الفصول في هذا الجزء لدعم فصل‬
‫دراسي واحد دورة في هندسة البرمجيات‪ .‬الفصل األول هو مقدمة عامة تقدم البرامج االحترافية الهندسة وتعريف بعض مفاهيم هندسة‬
‫البرمجيات‪ .‬أملك كتب أيضً ا مناقشة موجزة للقضايا األخالقية في هندسة البرمجيات‪ .‬أعتقد أنه من المهم لمهندسي البرمجيات التفكير في‬
‫اآلثار األوسع لعملهم‪ .‬يقدم هذا الفصل أيضً ا ثالث حاالت الدراسات‪ W‬التي أستخدمها في الكتاب ‪ ،‬وهي نظام إلدارة سجالت‪ W‬المرضى الذين‬
‫يخضعون للعالج من مشاكل الصحة العقلية ‪ ،‬وهو عنصر تحكم نظام لمضخة األنسولين المحمولة ونظام الطقس البري‪ .‬يغطي الفصالن‬
‫في الفصل ‪ ، 2‬أقدم البرامج العامة شائعة االستخدام نماذج ‪- opment.‬الثاني والثالث عمليات هندسة البرمجيات والتطور السريع‬
‫العمليات ‪ ،‬مثل نموذج الشالل ‪ ،‬وأنا أناقش األساسيات‪ W‬األنشطة التي هي جزء من هذه العمليات‪ .‬الفصل ‪ 3‬يكمل هذا مع مناقشة أساليب‬
‫ضا تقديم سكرم‬ ‫التطوير الرشيقة لمهندس البرمجيات‪ -‬عمل‪ .‬أنا أكثراستخدام البرمجة المتطرفة كمثال على أسلوب رشيق ولكن أي ً‬
‫باختصار في هذا الفصل‪ .‬مقدمة إلى البرامج الهندسة ‪ 1‬ما تبقى من الفصول في هذا الجزء عبارة عن أوصاف موسعة لـ أنشطة عملية‬
‫البرمجيات‪ W‬التي سيتم تقديمها في الفصل ‪ .2‬يغطي الفصل ‪ 4‬موضوعًا مه ًما‪ W‬للغاية وهو متطلبات مهندس‪ -‬جي ‪ ،‬حيث يتم تحديد متطلبات‬
‫حيث أركز على استخدام مخططات‪ W‬حالة االستخدام ‪ UML ،‬ما يجب أن يفعله النظام‪ .‬يقدم الفصل الخامس نمذجة النظام باستخدام‬
‫ومخططات الفئة ومخططات التسلسل و مخططات‪ W‬الحالة لنمذجة نظام برمجي‪ .‬يقدم الفصل ‪ 6‬التصميم المعماري وأنا ناقش أهمية‬
‫الهندسة المعمارية و استخدام األنماط المعمارية‪ W‬في تصميم البرمجيات‪ .‬يقدم الفصل ‪ 7‬التصميم الموجه للكائنات واستخدام نموذج التصميم‬
‫خطاف البحر‪ .‬أقدم أيضً ا قضايا التنفيذ المهمة هنا ‪ -‬إعادة االستخدام ‪ ،‬المحتوى إدارة الشكل ‪ ،‬وتطوير المضيف المستهدف ومناقشة‪W‬‬
‫مفتوحة تطوير المصدر‪ .‬يركز الفصل الثامن على اختبار البرنامج من اختبار الوحدة‪ -‬جي أثناء تطوير النظام الختبار إصدارات البرامج‪.‬‬
‫أنا أيضا ً مناقشة استخدام التطوير القائم على االختبار ‪ -‬وهو نهج رائد في أساليب رشيقة ولكن لها قابلية تطبيق واسعة‪ .‬أخيرً ا ‪ ،‬الفصل ‪9‬‬
‫عرض‪ -‬نظرة عامة على قضايا تطور البرمجيات‪ .‬أنا أغطي التطور العمليات وصيانة البرامج وإدارة النظام القديم‪ .‬مقدمة ‪ 1‬أهداف‬
‫أهداف هذا الفصل هي تقديم هندسة البرمجيات و لتوفير إطار لفهم بقية الكتاب‪ .‬عندما انت قرأت هذا الفصل سوف‪ :‬فهم ماهية هندسة‬
‫البرمجيات وسبب أهميتها ؛ نفهم أن تطوير أنواع مختلفة من البرامج قد تتطلب األنظمة تقنيات هندسة برمجيات مختلفة ؛ فهم بعض‬
‫القضايا األخالقية والمهنية المهمة لمهندسي البرمجيات‪ .‬تم إدخالها إلى ثالثة أنظمة ‪ ،‬من أنواع مختلفة ‪ ،‬والتي ستكون تستخدم كأمثلة في‬
‫جميع أنحاء الكتاب‪ .‬محتويات ‪ 1.1‬تطوير البرامج المهنية ‪ 1.2‬أخالقيات هندسة البرمجيات ‪ 1.3‬دراسات الحالة ‪ 4‬الفصل ‪ 1‬مقدمة ال‬
‫يمكننا تشغيل العالم الحديث بدون برامج‪ .‬البنى التحتية الوطنية والمرافق‪ -‬يتم التحكم في العالقات من خالل أنظمة قائمة على الكمبيوتر‬
‫وتشمل معظم المنتجات الكهربائية أ برامج الكمبيوتر والتحكم‪ .‬التصنيع والتوزيع الصناعي محوسبة بالكامل ‪ ،‬وكذلك النظام المالي‪.‬‬
‫الترفيه ‪ ،‬بما في ذلك صناعة الموسيقى وألعاب الكمبيوتر واألفالم والتلفزيون هي برامج مكثفة‪ .‬لذلك ‪ ،‬تعد هندسة البرمجيات ضرورية‬
‫لعمل األجهزة الوطنية والدولية‪ .‬الجمعيات الوطنية‪ .‬أنظمة البرمجيات مجردة وغير ملموسة‪ .‬ال تقيدهم خواص المواد التي تحكمها‪W‬‬
‫القوانين الفيزيائية أو عمليات التصنيع‪ .‬هذا يبسط هندسة البرمجيات ‪ ،‬حيث ال توجد حدود طبيعية إلمكانيات‪ W‬برمجة‪ .‬ومع ذلك ‪ ،‬بسبب‬
‫معقدا للغاية ويصعب فهمه‪ W‬وتغييره مكل ًفا‪ .‬هناك العديد من أنواع أنظمة‬‫ً‬ ‫نقص القيود المادية ‪ ،‬يمكن ألنظمة البرامج سرعان ما يصبح‬
‫ألنظمة المعلومات المعقدة في جميع أنحاء العالم‪ .‬من غير المجدي البحث ‪- tems‬البرامج المختلفة ‪ ،‬بدءًا من األنظمة المدمجة‪ W‬البسيطة‬
‫عن عالمي تدوينات أو طرق أو تقنيات لهندسة البرمجيات ألنواع مختلفة من البرامج تتطلب أساليب مختلفة‪ .‬تطوير المعلومات التنظيمية‬
‫نظام مختلف تما ًم ا عن تطوير وحدة تحكم ألداة علمية‪ -‬منة‪ .‬أيا من هذهتشترك األنظمة في الكثير من القواسم المشتركة مع أجهزة‬
‫الكمبيوتر ذات الرسومات المكثفة لعبة الكمبيوتر‪ .‬كل هذه التطبيقات تحتاج إلى هندسة برمجيات ؛ ال يحتاجون كلهم نفس تقنيات هندسة‬
‫البرمجيات‪ .‬ال تزال هناك العديد من التقارير عن حدوث أخطاء في مشروعات البرامج و "فشل البرامج"‪ .‬تم انتقاد هندسة البرمجيات‬
‫على أنها غير مالئمة لتطوير البرمجيات الحديثة‪ .‬ومع ذلك ‪ ،‬من وجهة نظري ‪ ،‬فإن العديد من حاالت فشل البرامج المزعومة هي نتيجة‬
‫لـ عاملين‪ . 1 :‬زيادة الطلبات حيث تساعدنا تقنيات هندسة البرمجيات الجديدة على البناء األنظمة األكبر واألكثر تعقي ًدا ‪ ،‬تتغير الطلبات‪.‬‬
‫تعقيدا مطلوبة ؛ يجب أن تتمتع األنظمة بإمكانات‪ W‬جديدة كان يُعتقد ساب ًقا أنها‬
‫ً‬ ‫يجب بناء األنظمة وتسليمها بسرعة أكبر ؛ أنظمة أكبر وأكثر‬
‫مهمة‪ - W‬السمور‪ .‬ال يمكن ألساليب هندسة البرمجيات الحالية التعامل مع البرامج الجديدة يجب تطوير التقنيات الهندسية لتلبية هذه‬
‫المتطلبات الجديدة‪ .2 .‬توقعات منخفضة من السهل نسبيًا كتابة برامج الكمبيوتر دون استخدام أساليب وتقنيات هندسة البرمجيات‪ .‬لقد‬
‫انجرفت العديد من الشركات في تطوير البرمجيات مع تطور منتجاتهم وخدماتهم‪ .‬إنهم يفعلون عدم استخدام أساليب هندسة البرمجيات في‬
‫عملهم اليومي‪ .‬بالتالي‪ ،‬غالبًا ما تكون برامجهم أغلى ثمنا ً وأقل موثوقية مما ينبغي‪ .‬نحن بحاجة إلى تعليم وتدريب أفضل في هندسة‬
‫البرمجيات‪ W‬لمعالجة هذه المشكلة‪ .‬يمكن لمهندسي البرمجيات أن يفخروا بإنجازاتهم بحق‪ .‬بالطبع ما زلنا لدينا مشاكل في تطوير البرامج‬
‫المعقدة ولكن بدون هندسة البرمجيات ‪ ،‬نحن لم يكن ليقوم باستكشاف الفضاء ‪ ،‬أو اإلنترنت أو االتصاالت الحديثة‪ -‬االيونات الموجبة‪.‬‬
‫كثيرً ا وأنا مقتنع بأن مساهماته في سوف يكون ‪ neering‬جميع أشكال السفر ستكون أكثر خطورة وتكلفة‪ .‬مهندس البرمجيات‪ -‬لقد ساهم‬
‫القرن الحادي والعشرون أعظم‪ 1.1 .‬تطوير البرمجيات االحترافية ‪ 5‬تاريخ هندسة البرمجيات تم اقتراح مفهوم "هندسة البرمجيات"‬
‫‪" (Naur and Randell، 1969).‬ألول مرة في عام ‪ 1968‬في مؤتمر عقد لمناقشة‪ W‬ما كان في ذلك الوقت تسمى "أزمة البرمجيات‬
‫أصبح من الواضح أن النهج الفردية للبرنامج لم يصل التطوير إلى أنظمة برمجية كبيرة ومعقدة‪ .‬كانت هذه غير موثوقة ‪ ،‬تكلف أكثر من‬
‫كان متوقعً ا ‪ ،‬وتم تسليمه متأخرً ا‪ .‬خالل السبعينيات والثمانينيات ‪ ،‬كانت هناك مجموعة متنوعة من تقنيات وأساليب هندسة البرمجيات‬
‫الجديدة المتقدمة ‪ ،‬مثل البرمجة المهيكلة وإخفاء المعلومات والتطوير الموجه للكائنات‪ .‬أدوات و تم تطوير الرموز القياسية وتستخدم اآلن‬
‫تطوير البرامج المهنية يكتب الكثير من ‪. http://www.SoftwareEngineering-9.com/Web/History/ 1.1‬على نطاق واسع‬
‫الناس البرامج‪ .‬يكتب األشخاص في مجال األعمال برامج جداول البيانات إلى تبسيط وظائفهم ‪ ،‬يكتب العلماء والمهندسون برامج لمعالجة‬
‫خبراتهم‪ -‬البيانات العقلية ‪ ،‬ويقوم الهواة بكتابة برامج لمصلحتهم الخاصة ومتعة‪ .‬ومع ذلك ‪ ،‬فإن الغالبية العظمى من تطوير البرمجيات‪W‬‬
‫هو نشاط احترافي حيث تم تطوير البرنامج ألغراض تجارية محددة ‪ ،‬إلدراجه في أجهزة أخرى ‪ ،‬أو كمنتجات برمجية مثل أنظمة‬
‫وما إلى ذلك عاد ًة ما يتم تطوير البرامج المخصصة لالستخدام من قِبل شخص آخر بخالف مطورها من قبل ‪ CAD‬المعلومات وأنظمة‬
‫الفرق وليس األفراد‪ .‬يتم الحفاظ عليها وتغييرها طوال حياتها‪ .‬تهدف هندسة البرمجيات إلى دعم تطوير البرامج االحترافية ‪ ،‬بدالً من‬
‫عادة ما تكون ذات صلة ‪h‬البرمجة الفردية‪ .‬يتضمن التقنيات التي تدعم البرنامج المواصفات والتصميم والتطور ‪ ،‬ال شيء من هذا القبيل‬
‫حول ‪ ،‬لقد قمت‪ W‬بتلخيص ‪ neering‬لكل تطوير البرمجيات الصوتية‪ .‬لمساعدتك في الحصول على نظرة عامة حول ماهية هندسة البرامج‬
‫بعض األسئلة المتداولة في الشكل ‪ . 1.1‬يعتقد الكثير من الناس أن البرامج هي مجرد كلمة أخرى لبرامج الكمبيوتر‪ .‬ومع ذلك ‪ ،‬عندما‬
‫ض ا جميع الوثائق المرتبطة وبيانات التكوين المطلوب‬‫نتحدث عن هندسة البرمجيات‪ ، W‬فإن البرمجيات ليست فقط البرامج نفسها ولكن أي ً‬
‫لجعل هذه البرامج تعمل بشكل صحيح‪ .‬تطوير مهني‪ -‬غالبًا ما يكون نظام البرمجيات المفتوحة أكثر من برنامج واحد‪ .‬عادة ما يعمد‬
‫النظام إلى‪ -‬مجموعات من عدد من البرامج المنفصلة وملفات التكوين المستخدمة‪ W‬في اإلعداد هذه البرامج‪ .‬قد يتضمن وثائق النظام ‪ ،‬التي‬
‫تصف الهيكل النظام؛ وثائق المستخدم التي تشرح كيفية استخدام النظام والويب‪ -‬مواقع للمستخدمين لتنزيل معلومات المنتج الحديثة‪ .‬هذا‬
‫هو أحد االختالفات المهمة بين المحترفين والهواة سوفت تطوير وير‪ .‬إذا كنت تكتب برنامجً ا لنفسك ‪ ،‬فلن يستخدمه أحد وال داعي للقلق‬
‫بشأن كتابة أدلة البرنامج وتوثيق المحترف تصميم غرام ‪ ،‬وما إلى ذلك ‪ ،‬ومع ذلك ‪ ،‬إذا كنت تكتب برنامجً ا سيستخدمه اآلخرون و‬
‫سيتغير المهندسون اآلخرون ‪ ،‬فعادة‪ W‬ما يتعين عليك تقديم معلومات إضافية وكذلك كود البرنامج ‪ 6‬الفصل ‪ 1‬مقدمة جواب السؤال ما هو‬
‫البرنامج؟ برامج الكمبيوتر والوثائق المرتبطة بها‪ .‬قد يتم تطوير منتجات البرامج من أجل معين العميل أو قد يتم تطويره لسوق عام‪ .‬ما‬
‫هي سمات‪ W‬البرمجيات الجيدة؟ يجب أن يقدم البرنامج الجيد المطلوب الوظائف واألداء للمستخدم ويجب أن تكون قابلة للصيانة ويمكن‬
‫االعتماد عليها وقابلة لالستخدام‪ .‬ما هي هندسة البرمجيات؟ هندسة البرمجيات‪ W‬هي تخصص هندسي يهتم بجميع جوانب إنتاج البرامج‪ .‬ما‬
‫هي هندسة البرمجيات األساسية أنشطة؟ مواصفات البرمجيات ‪ ،‬تطوير البرمجيات ‪ ،‬التحقق من صحة البرامج وتطور البرامج‪ .‬ما هو‬
‫الفرق بين البرامج الهندسة وعلوم الكمبيوتر؟ يركز علم الحاسوب على النظرية و األساسيات‪ .‬هندسة البرمجيات المعنية مع الجوانب‬
‫العملية للتطوير والتسليم برنامج مفيد‪ .‬ما هو الفرق بين البرامج الهندسة وهندسة النظم؟ تهتم هندسة النظام بجميع جوانب تطوير األنظمة‬
‫المستندة إلى الكمبيوتر بما في ذلك األجهزة والبرمجيات وهندسة العمليات‪ .‬برمجة الهندسة جزء من هذه العملية األكثر عمومية‪ .‬ما هي‬
‫التحديات الرئيسية التي تواجه البرمجيات هندسة؟ التعامل مع زيادة التنوع ‪ ،‬والمطالب لخفض مواعيد التسليم ‪ ،‬وتطوير برامج جديرة‬
‫بالثقة‪ .‬ما هي تكاليف هندسة البرمجيات؟‪ W‬ما يقرب من ‪ ٪60‬من تكاليف البرمجيات هي تكاليف تطوير التكاليف ؛ ‪ ٪40‬تكاليف االختبار‪.‬‬
‫بالنسبة للبرامج المخصصة ‪ ،‬غال ًب ا ما تتجاوز تكاليف التطوير تكاليف التطوير‪ .‬ما هي أفضل تقنيات هندسة البرمجيات والطرق؟ بينما‬
‫يجب أن تكون جميع مشاريع البرامج احترافية تتم إدارتها وتطويرها ‪ ،‬وتقنيات مختلفة مناسب‪ W‬ألنواع مختلفة من النظام‪ .‬على سبيل‬
‫المثال‪ ،‬يجب دائ ًم ا تطوير األلعاب باستخدام سلسلة من النماذج األولية بينما أنظمة التحكم الحرجة للسالمة تتطلب مواصفات كاملة وقابلة‬
‫للتحليل متطور‪ .‬لذلك ال يمكنك قول هذه الطريقة الواحدة أفضل من اآلخر‪ .‬ما هي االختالفات التي أحدثتها الويب في البرامج هندسة؟‬
‫أدى الويب إلى توفر البرامج الخدمات وإمكانيةيتطور بشكل كبير األنظمة القائمة على الخدمة الموزعة‪ .‬على شبكة اإلنترنت أدى تطوير‬
‫النظم إلى تطورات مهمة في لغات البرمجة وإعادة استخدام البرامج‪ .‬يهتم مهندسو البرمجيات بتطوير منتجات البرمجيات‪( W‬على سبيل‬
‫المثال ‪ ،‬وير التي يمكن بيعها للعميل)‪ .‬هناك نوعان من منتجات البرمجيات‪ .1 :‬المنتجات العامة هي أنظمة قائمة بذاتها تنتجها شركة‬
‫تطوير‪ -‬منظمة منة وبيعها في السوق المفتوحة ألي عميل قادر على ذلك الشكل ‪ 1.1‬بشكل متكرر طرح أسئلة حول البرمجيات ‪1.1‬‬
‫تطوير البرامج المهنية ‪ 7‬شرائهم‪ .‬تتضمن أمثلة هذا النوع من المنتجات برامج ألجهزة الكمبيوتر مثل قواعد البيانات ومعالجات‪W‬‬
‫النصوص وحزم الرسم وأدوات إدارة المشاريع‪ .‬ويشمل أيضً ا ما يسمى بالتطبيقات الرأسية المصممة لبعض األغراض المحددة تطرح‬
‫مثل أنظمة معلومات المكتبات أو أنظمة المحاسبة أو أنظمة االحتفاظ بسجالت األسنان‪ .2 .‬المنتجات المخصصة (أو المفصلة) هذه هي‬
‫األنظمة التي يتم تكليفها من قبل عميل معين‪ .‬يقوم مقاول البرمجيات بتطوير البرنامج بشكل خاص لهذا الزبون‪ .‬تتضمن أمثلة هذا النوع‬
‫من البرامج أنظمة التحكم لـ األجهزة اإللكترونية واألنظمة المكتوبة لدعم عملية تجارية معينة ‪ ،‬و أنظمة مراقبة الحركة الجوية‪ .‬يتمثل‬
‫أحد االختالفات المهمة بين هذه األنواع من البرامج في أنه في المنتجات العامة ‪ ،‬تتحكم المنظمة التي تطور البرنامج في مواصفات‬
‫البرنامج‪ .‬للعميل‪ -‬منتجات توم ‪ ،‬عادة ما يتم تطوير المواصفات والتحكم فيها من قبل المنظمة هو شراء البرنامج‪ .‬يجب أن يعمل مطورو‬
‫البرامج وف ًق ا لتلك المواصفات‪ .‬ومع ذلك ‪ ،‬أصبح التمييز بين أنواع منتجات النظام هذه ضبابية بشكل متزايد‪ .‬يتم اآلن بناء المزيد والمزيد‬
‫‪ (ERP) ،‬من األنظمة باستخدام عام المنتج كقاعدة ‪ ،‬والتي يتم تكييفها بعد ذلك لتالئم متطلبات العميل‪ .‬أنظمة تخطيط موارد المؤسسات‬
‫من خالل دمج المعلومات حول ‪ pany‬هي األفضل أمثلة على هذا النهج‪ .‬هنا ‪ ،‬يتم تكييف نظام كبير ومعقد من أجل ‪ SAP ،‬مثل نظام‬
‫قواعد العمل والعمليات والتقارير مطلوب ‪ ،‬وما إلى ذلك‪ .‬عندما نتحدث عن جودة البرامج االحترافية ‪ ،‬علينا أن نأخذ في االعتبار‬
‫الحساب الذي يستخدمه البرنامج وتغييره بواسطة أشخاص بخالف مطوريه‪ .‬لذلك ال تتعلق الجودة فقط بما يفعله البرنامج‪ .‬بدال من ذلك ‪،‬‬
‫يجب أن تتضمن سلوك البرنامج أثناء التنفيذ والهيكل والتنظيم من برامج النظام والوثائق المرتبطة بها‪ .‬وينعكس هذا في ما يسمى ب‬
‫الجودة أو سمات البرامج غير الوظيفية‪ .‬أمثلة على هذه السمات‪ W‬هي لينة‪ -‬وقت استجابة وير الستعالم المستخدم ومدى قابلية فهم رمز‬
‫يعتمد على تطبيقه‪ .‬لذلك ‪ ،‬يجب أن يكون النظام المصرفي ‪ obvi-‬البرنامج‪ .‬مجموعة السمات المحددة التي قد تتوقعها من نظام برمجيات‬
‫آم ًن ا و يجب أن تكون اللعبة التفاعلية سريعة االستجابة ‪ ،‬ويجب أن يكون نظام التحويل عبر الهاتف موثو ًقا به ‪ ،‬وما إلى ذلك وهلم جرا‪.‬‬
‫يمكن تعميمها في مجموعة السمات‪ W‬الموضحة في الشكل ‪ ، 1.2‬التي أعتقد أنها الخصائص األساسية لنظام برمجيات احترافي‪1.1.1 .‬‬
‫هندسة البرمجيات هندسة البرمجيات هي تخصص هندسي يهتم بجميع جوانب إنتاج البرامج من المراحل األولى لمواصفات النظام حتى‬
‫صيانة‪ -‬في النظام بعد استخدامه‪ .‬في هذا التعريف ‪ ،‬هناك عبارتان أساسيتان‪ .1 :‬االنضباط الهندسي المهندسون يجعلون األشياء تعمل‪.‬‬
‫ود عندما تكون هذه األدوات مناسبة‪ .‬ومع ذلك ‪ ،‬فهم يستخدمونها بشكل انتقائي ‪ 8‬الفصل ‪ 1‬مقدمة ‪ ods ،‬يطبقون النظريات ‪ ،‬ميث‬
‫ضا أنه يجب‬‫وحاول دائ ًم ا اكتشاف حلول للمشكالت حتى في حالة عدم وجود تطبيق‪ -‬نظريات وطرق الكابالت‪ .‬يدرك المهندسون أي ً‬
‫عليهم العمل القيود التنظيمية والمالية لذلك يبحثون عن حلول ضمن هذه قيود‪ .2 .‬جميع جوانب إنتاج البرمجيات ال تهتم هندسة‬
‫البرمجيات فقط مع العمليات التقنية لتطوير البرمجيات‪ .‬كما تشمل األنشطة مثل إدارة مشروع البرمجيات‪ W‬وتطوير األدوات واألساليب ‪،‬‬
‫ونظريات لدعم إنتاج البرمجيات‪ .‬تتعلق الهندسة بالحصول على نتائج الجودة المطلوبة ضمن الجدول الزمني والميزانية‪ .‬يتضمن هذا‬
‫غال ًب ا تقديم تنازالت ‪ -‬ال يمكن للمهندسين أن يكونوا مثاليين ‪ -‬المشعوذون‪ .‬ومع ذلك ‪ ،‬يمكن لألشخاص الذين يكتبون برامج ألنفسهم‬
‫قضاء الكثير من الوقت كما يحلو لهم في تطوير البرنامج‪ .‬بشكل عام ‪ ،‬يتبنى مهندسو البرمجيات نهجً ا منظمًا ومنظمًا لهم العمل ‪ ،‬فهذه‬
‫هي الطريقة األكثر فاعلية إلنتاج برامج عالية الجودة‪ .‬ومع ذلك ‪ ،‬فإن الهندسة تدور حول اختيار الطريقة األنسب لمجموعة من لذلك قد‬
‫يكون نهج التنمية أكثر إبدا ًعا وأقل رسمية فعال في بعض الظروف‪ .‬التطوير األقل رسمية مناسب‪ W‬بشكل خاص‪ -‬لتطوير األنظمة المستندة‬
‫إلى الويب ‪ ،‬األمر الذي يتطلب مزيجً ا من البرامج ومهارات التصميم الرسومي‪ .‬هندسة البرمجيات مهمة‪ W‬لسببين‪ .1 :‬يتزايد اعتماد‬
‫األفراد والمجتمع على أنظمة البرمجيات المتقدمة‪ .‬نحن يجب أن تكون قادرً ا على إنتاج أنظمة موثوقة وجديرة بالثقة اقتصاديًا و بسرعة‪.‬‬
‫وصف خصائص المنتج يجب كتابة برامج الصيانة بهذه الطريقة بحيث يمكن أن تتطور إلى تلبية االحتياجات‪ W‬المتغيرة للعمالء‪ .‬هذه سمة‬
‫مهمة ألن تغيير البرامج هو مطلب حتمي لـ بيئة األعمال المتغيرة‪ .‬االعتمادية واألمان تتضمن اعتمادية البرامج مجموعة من الخصائص‬
‫بما في ذلك الموثوقية واألمان والسالمة‪ .‬برنامج يمكن االعتماد عليه يجب أال يسبب ضررً ا ماديًا أو اقتصاديًا في حالة فشل النظام‪ .‬يجب‬
‫أال يتمكن المستخدمون الضارون من الوصول إلى ملفات إتالف النظام‪ .‬كفاءة البرمجيات ال ينبغي اإلسراف في استخدام موارد النظام‬
‫مثل مثل دورات الذاكرة والمعالج‪ .‬وبالتالي تشمل الكفاءة االستجابة ووقت المعالجة‪ W‬واستخدام الذاكرة وما إلى ذلك‪ .‬يجب أن يكون برنامج‬
‫القبول مقبوالً لنوع المستخدمين الذي يكون مقبوالً بالنسبة لهم مصمم‪ .‬هذا يعني أنه يجب أن يكون مفهومًا وقاباًل لالستخدام و متوافق مع‬
‫األنظمة األخرى التي يستخدمونها‪ .‬الشكل ‪ 1.2‬أساسي صفات الخير البرمجيات ‪ 1.1‬تطوير البرامج المهنية ‪ .2 9‬من األرخص عادة ‪،‬‬
‫على المدى الطويل ‪ ،‬استخدام طرق هندسة البرمجيات و تقنيات ألنظمة البرمجيات بدالً من مجرد كتابة البرامج كما لو كانت ملف‬
‫مشروع برمجة شخصية‪ .‬بالنسبة لمعظم أنواع األنظمة ‪ ،‬فإن غالبية التكاليف هي تكاليف تغيير البرنامج بعد استخدامه‪ .‬أحيا ًنا ما يسمى‬
‫النهج المنهجي المستخدم‪ W‬في هندسة البرمجيات عملية برمجية‪ .‬عملية البرمجيات هي سلسلة من األنشطة التي تؤدي إلى إنتاج منتج‬
‫برمجي‪ .‬هناك أربعة أنشطة أساسية مشتركة مون لجميع عمليات البرنامج‪ .‬هذه األنشطة هي‪ .1 :‬مواصفات البرنامج ‪ ،‬حيث يحدد‬
‫العمالء والمهندسون البرنامج الذي يتم إنتاجه والقيود المفروضة على تشغيله‪ .2 .‬تطوير البرمجيات حيث يتم تصميم البرنامجومبرمج‪.‬‬
‫‪ . 3‬التحقق من صحة البرنامج ‪ ،‬حيث يتم فحص البرنامج للتأكد من أنه هو يتطلب العميل‪ .4 .‬تطور البرامج ‪ ،‬حيث يتم تعديل البرنامج‬
‫ليعكس تغيير العميل ومتطلبات السوق‪ .‬تحتاج األنواع المختلفة من األنظمة إلى عمليات تطوير مختلفة‪ .‬على سبيل المثال‪ ،‬يجب تحديد‬
‫برامج الوقت الفعلي في الطائرة تما ًم ا قبل التطوير يبدأ‪ .‬في أنظمة التجارة اإللكترونية ‪ ،‬عادة ما تكون المواصفات والبرنامج متطورين‬
‫ً‬
‫اعتمادا على نوع‬ ‫تعمل معا‪ .‬وبالتالي ‪ ،‬يمكن تنظيم هذه األنشطة العامة في مختلف الطرق ووصفها بمستويات مختلفة من التفاصيل‬
‫البرنامج يجري تطويرها‪ .‬أصف عمليات البرامج بمزيد من التفصيل في الفصل الثاني‪ .‬ترتبط هندسة البرمجيات بكل من علوم الكمبيوتر‬
‫وهندسة النظم‪ . 1 :‬علم الحاسوب يهتم بالنظريات واألساليب التي تقوم عليها المضارب وأنظمة البرمجيات ‪ ،‬في حين تهتم هندسة‬
‫البرمجيات بـ مشاكل عملية إلنتاج البرمجيات‪ .‬بعض المعرفة بعلوم الكمبيوتر ضروري لمهندسي البرمجيات بنفس الطريقة التي يمتلك‬
‫بها بعض المعرفة الفيزياء ضرورية لمهندسي الكهرباء‪ .‬ومع ذلك ‪ ،‬فإن نظرية علوم الكمبيوتر غالبًا ما ينطبق على البرامج الصغيرة‬
‫ً‬
‫بسيطا حل وير‪ .2 .‬تهتم‬ ‫نسبيًا‪ .‬نظريات الكمبيوتر األنيقة ال يمكن تطبيق العلم دائمًا على المشكالت‪ W‬الكبيرة والمعقدة التي تتطلب حاًل‬
‫من األنظمة المعقدة حيث تلعب البرامج دورً ا رئيسيًا‪ .‬مهندس نظم‪ -‬ولذلك فإن جي ‪- lution‬هندسة النظم بجميع جوانب التطوير وتطوير‬
‫في تحديد النظام ‪ neers‬تهتم بتطوير األجهزة والسياسة‪ W‬والعملية تصميم ونشر النظام ‪ ،‬وكذلك هندسة البرمجيات‪ .‬مهندس النظام‪ -‬يشارك‬
‫‪ ،‬وتحديد بنيته الشاملة ‪ ،‬ثم دمج األجزاء المختلفة إلنشاء النظام النهائي‪ .‬هم انهم أقل اهتمامًا بهندسة مكونات النظام (األجهزة ‪ ،‬البرامج ‪،‬‬
‫وما إلى ذلك)‪ 10 .‬الفصل ‪ 1‬مقدمة كما أناقش في القسم التالي ‪ ،‬هناك العديد من أنواع البرامج المختلفة‪ .‬ال يوجد طريقة أو تقنية هندسة‬
‫البرمجيات العالمية التي تنطبق على كل هذه‪ .‬ومع ذلك ‪ ،‬هناك ثالث مشكالت‪ W‬عامة تؤثر على العديد من أنواع البرامج المختلفة‪ .1 :‬عدم‬
‫التجانس بشكل متزايد ‪ ،‬األنظمة مطلوبة للعمل كنظم موزعة عبر الشبكات‪ W‬التي تتضمن أنوا ًعا مختلفة من أجهزة الكمبيوتر واألجهزة‬
‫ضا تنفيذ البرنامج على الهواتف المحمولة‪.‬‬ ‫المحمولة‪ .‬مثل باإلضافة إلى التشغيل على أجهزة الكمبيوتر ذات األغراض العامة ‪ ،‬قد يتعين أي ً‬
‫مكتوبة بلغات برمجة مختلفة‪ .‬التحدي هنا هو التطور تقنيات ‪- tems‬غالبًا ما يتعين عليك دمج البرامج الجديدة مع األنظمة القديمة القديمة‬
‫لبناء برامج يمكن االعتماد عليها ومرنة بما يكفي للتعامل معها هذا عدم التجانس‪ . 2 .‬األعمال التجارية والتغيير االجتماعي تتغير األعمال‬
‫والمجتمع بسرعة مذهلة مع تطور االقتصادات الناشئة وإتاحة تقنيات جديدة‪ .‬هم يحتاجون إلى أن يكونوا قادرين على تغيير برامجهم‬
‫الحالية وأن يطوروا برمجيات جديدة بسرعة وير‪ .‬العديد من تقنيات هندسة البرمجيات التقليدية تستغرق وق ًتا طويالً و غالبًا ما يستغرق‬
‫تسليم األنظمة الجديدة وق ًت ا أطول مما هو مخطط له‪ .‬إنهم بحاجة إلى تطوير ذلك أن الوقت الالزم للبرامج لتقديم قيمة لعمالئها قد تم تقليله‪.‬‬
‫‪ . 3‬األمن والثقة بما أن البرمجيات متشابكة مع جميع جوانب حياتنا ‪ ،‬فهي كذلك من الضروري أن نثق في هذا البرنامج‪ .‬هذا ينطبق‬
‫بشكل خاص على جهاز التحكم عن بعد أنظمة وير يتم الوصول إليها من خالل صفحة ويب أو واجهة خدمة ويب‪ .‬علينا أن تأكد من أن‬
‫المستخدمين الضارين ال يستطيعونر مهاجمة برنامجنا وتلك المعلومات يتم الحفاظ على األمن‪ .‬بالطبع ‪ ،‬هذه ليست قضايا مستقلة‪ .‬على‬
‫سبيل المثال ‪ ،‬قد يكون من الضروري إجراء تغييرات سريعة على نظام قديم لتزويده بواجهة خدمة ويب‪ .‬ل لمواجهة هذه التحديات‬
‫سنحتاج إلى أدوات وتقنيات جديدة ومبتكرة طرق الجمع بين طرق هندسة البرمجيات الحالية واستخدامها‪ 1.1.2 .‬تنوع هندسة البرمجيات‬
‫هندسة البرمجيات هي نهج منظم إلنتاج البرمجيات التي يأخذ في االعتبار التكلفة العملية والجدول الزمني وقضايا االعتمادية ‪ ،‬باإلضافة‬
‫إلى احتياجات عمالء ومنتجي البرمجيات‪ .‬كيف يعمل هذا النهج المنهجي الحليف المنفذ بشكل كبير اعتما ًدا على المنظمة التي تقوم‬
‫بتطوير البرمجيات ونوع البرنامج واألشخاص المشاركين في عملية التطوير‪ .‬ال توجد طرق وتقنيات هندسة برمجيات عالمية مناسبة‪-‬‬
‫قادر على جميع األنظمة وجميع الشركات‪ .‬بدال من ذلك ‪ ،‬مجموعة متنوعة من هندسة البرمجيات تطورت األساليب واألدوات على مدار‬
‫الخمسين عا ًم ا الماضية‪ .‬ربما كان العامل األكثر أهمية في تحديد هندسة البرمجيات األساليب والتقنيات األكثر أهمية هو نوع التطبيق‬
‫الذي يتم إجراؤه متطور‪ .‬هناك العديد من أنواع التطبيقات المختلفة بما في ذلك‪ .1 :‬التطبيقات المستقلة هذه هي أنظمة التطبيقات التي يتم‬
‫تشغيلها على كمبيوتر محلي الكمبيوتر ‪ ،‬مثل جهاز الكمبيوتر‪ .‬وهي تشمل جميع الوظائف الضرورية وال تحتاج إلى ‪ 1.1‬تطوير برامج‬
‫برامج معالجة‪ CAD ، W‬احترافية ‪ 11‬أن تكون متصالً بشبكة‪ .‬أمثلة على هذه التطبيقات هي تطبيقات مكتبية‪ -‬على جهاز كمبيوتر ‪ ،‬برامج‬
‫الصور ‪ ،‬إلخ‪ .2 .‬التطبيقات التفاعلية القائمة على المعامالت‪ W‬هذه هي التطبيقات التي يتم تنفيذها على جهاز كمبيوتر بعيد ويتم الوصول‬
‫إليها من قبل المستخدمين من أجهزة الكمبيوتر الخاصة بهم أو محطات‪ .‬من الواضح أن هذه تشمل تطبيقات الويب مثل تطبيق التجارة‬
‫ضا أنظمة األعمال ‪،‬‬ ‫اإللكترونية‪ -‬الكاتيونات حيث يمكنك التفاعل مع نظام بعيد لشراء السلع والخدمات‪ .‬تتضمن هذه الفئة من التطبيقات أي ً‬
‫حيث تكون األعمال التجارية يوفر الوصول إلى أنظمته من خالل متصفح الويب أو العميل ألغراض خاصة البرامج والخدمات‪ W‬المستندة‬
‫إلى السحابة ‪ ،‬مثل البريد ومشاركة الصور‪ .‬تفاعلي غالبًا ما تتضمن التطبيقات مخز ًنا كبيرً ا للبيانات يتم الوصول إليه وتحديثه بتنسيق كل‬
‫معاملة‪ .3 .‬أنظمة التحكم المدمجة‪ W‬هذه أنظمة تحكم برمجية تتحكم في و إدارة األجهزة‪ .‬عدديًا ‪ ،‬من المحتمل أن يكون هناك المزيد من‬
‫من أي نوع آخر من النظام‪ .‬تتضمن أمثلة األنظمة المضمنة برنامج في هاتف محمول (خلوي) ‪ ،‬برنامج يتحكم ‪- tems‬األنظمة المضمنة‬
‫في الفرامل المانعة لالنغالق في ملف السيارة والبرامج الموجودة في فرن الميكروويف للتحكم في عملية الطهي‪ .4 .‬أنظمة معالجة‬
‫ال ُد فعات هذه هي أنظمة األعمال التي تم تصميمها من أجلها معالجة البيانات على دفعات كبيرة‪ .‬يقومون بمعالجة أعداد كبيرة من‬
‫المدخالت‪ W‬الفردية ل إنشاء النواتج المقابلة‪ .‬تتضمن أمثلة أنظمة الدفعات الدورية أنظمة الفوترة ‪ ،‬مثل أنظمة فواتير الهاتف ‪ ،‬وأنظمة دفع‬
‫الرواتب‪ . 5 .‬أنظمة الترفيه هذه هي األنظمة التي هي في األساس لالستخدام الشخصي و التي تهدف إلى ترفيه المستخدم‪ .‬معظم هذه‬
‫األنظمة هي ألعاب واحدة نوع أو آخر‪ .‬تعد جودة تفاعل المستخدم المقدمة هي األهم السمة المميزة ألنظمة الترفيه‪ .6 .‬أنظمة النمذجة‬
‫والمحاكاة هذه هي األنظمة التي تم تطويرها بواسطة العلماء والمهندسين لنمذجة العمليات الفيزيائية أو المواقف ‪ ،‬والتي تشمل العديد من‬
‫األشياء المتفاعلة المنفصلة‪ .‬هذه في كثير من األحيانحسابيا مكثفة وتتطلب أنظمة موازية عالية األداء للتنفيذ‪ .7 .‬أنظمة جمع البيانات هي‬
‫األنظمة التي تجمع البيانات من بيئتها‪ .‬باستخدام مجموعة من أجهزة االستشعار وإرسال تلك البيانات إلى أنظمة أخرى للمعالجة‪ .‬يجب أن‬
‫مثل داخل المحرك أو في مكان بعيد‪ .8 .‬أنظمة ‪ ronment‬يتفاعل البرنامج مع أجهزة االستشعار وغالبًا ما يتم تثبيته في بيئة معادية‬
‫األنظمة هذه هي األنظمة التي تتكون من عدد آخر أنظمة البرمجيات‪ .‬قد تكون بعض هذه المنتجات برامج عامة ‪ ،‬مثل ملف برنامج‬
‫جداول البيانات‪ .‬قد تكون األنظمة األخرى في التجمع مكتوبة بشكل خاص لتلك البيئة‪ .‬بالطبع ‪ ،‬الحدود بين أنواع األنظمة هذه غير‬
‫واضحة‪ .‬إذا قمت بتطوير لعبة للهاتف المحمول (الخلوي) ‪ ،‬عليك أن تأخذ في االعتبار نفس القيود (الطاقة ‪ ،‬التفاعل مع األجهزة)‬
‫بصفتهم مطوري برامج الهاتف‪ .‬دفعة برو‪ -‬غالبًا ما ُت ستخدم أنظمة التوقف باالقتران مع األنظمة المستندة إلى الويب‪ .‬على سبيل المثال ‪،‬‬
‫‪ 12‬الفصل ‪ 1‬مقدمة في شركة ‪ ،‬يمكن تقديم مطالبات نفقات السفر من خالل تطبيق ويب ولكن معالجتها في طلب دفعي للدفع الشهري‪.‬‬
‫أنت تستخدم تقنيات هندسة برمجيات مختلفة لكل نوع من أنواع األنظمة ألن البرنامج له خصائص مختلفة تمامًا‪ .‬على سبيل المثال ‪،‬‬
‫مضمن يعد نظام التحكم في السيارة أمرً ا بالغ األهمية للسالمة ويتم حرقه في ذاكرة القراءة فقط عندما مثبتة في السيارة‪ .‬لذلك فإن التغيير‬
‫مكلف للغاية‪ .‬يحتاج مثل هذا النظام التحقق والتحقق المكثف للغاية بحيث تكون فرص االضطرار إلى استدعاء السيارات يتم تقليل ما بعد‬
‫البيع إلصالح مشكالت‪ W‬البرامج‪ .‬تفاعل المستخدم ضئيل (أو ربما غير موجود) لذلك ليست هناك حاجة الستخدام عملية التطوير التي‬
‫تعتمد عليها النماذج األولية لواجهة المستخدم‪ .‬بالنسبة لنظام قائم على الويب ‪ ،‬نهج يعتمد على التطوير والتسليم التكراري قد يكون‬
‫مناس ًب ا ‪ ،‬حيث يتكون النظام من مكونات قابلة إلعادة االستخدام‪ .‬ومع ذلك ‪ ،‬قد يكون هذا النهج غير عملي لنظام من األنظمة ‪ ،‬حيث يجب‬
‫تحديد المواصفات التفصيلية لتفاعالت النظام مسب ًق ا يمكن تطوير كل نظام بشكل منفصل‪ .‬ومع ذلك ‪ ،‬هناك أساسيات هندسة البرمجيات‬
‫التي تنطبق على جميع األنواع من نظام البرمجيات‪ . 1 :‬يجب تطويرها باستخدام تطوير مُدار ومفهوم عملية‪ .‬يجب على المنظمة التي‬
‫تقوم بتطوير البرنامج أن تخطط للتطوير العملية ولديك أفكار واضحة عما سيتم إنتاجه ومتى سيحدث‪ -‬مطوي‪ .‬بالطبع ‪ ،‬يتم استخدام‬
‫عمليات مختلفة ألنواع مختلفة من البرامج‪ .2 .‬االعتمادية واألداء مهمان‪ W‬لجميع أنواع األنظمة‪ .‬برمجة يجب أن يتصرف كما هو متوقع ‪،‬‬
‫دون إخفاقات ويجب أن يكون متاحً ا لالستخدام عندما يكون ذلك مطلوبا‪ .‬يجب أن تكون آمنة في تشغيلها ‪ ،‬وبقدر اإلمكان ‪ ،‬يجب أن تكون‬
‫آمنة ضد أي هجوم خارجي‪ .‬يجب أن يعمل النظام بكفاءة وال ينبغي إهدار الموارد‪ .3 .‬فهم وإدارة مواصفات ومتطلبات البرامج (ماذا‬
‫يجب أن يقوم البرنامج بذلك) مهمة‪ .‬عليك أن تعرف ما العمالء المختلفين ويتوقع مستخدمو النظام منه وعليك إدارة توقعاتهم بحيث يمكن‬
‫تسليم نظام مفيد في حدود الميزانية والجدول الزمني‪ . 4 .‬يجب أن تستخدم الموارد الموجودة بأكبر قدر ممكن من الفعالية‪ .‬هذا يعنى أنه ‪،‬‬
‫عند االقتضاء ‪ ،‬يجب إعادة استخدام البرامج التي تم تطويرها بالفعل‪ -‬افتتح بدال من كتابة برامج جديدة‪ .‬هذه المفاهيم األساسية للعملية‬
‫واالعتمادية والمتطلبات واإلدارة ‪ ،‬وإعادة استخدامها هي مواضيع مهمة سو هذا الكتاب‪ .‬طرق مختلفة تعكسها بشكل مختلف بطرق‬
‫شرسة لكنها تكمن وراء جميع عمليات تطوير البرامج االحترافية‪ .‬يجب أن تالحظ أن هذه األساسيات‪ W‬ال تغطي التنفيذ والحماية النحو‪ .‬ال‬
‫أغطي تقنيات البرمجة المحددة في هذا الكتاب ألنها تختلف بشكل كبير من نوع نظام إلى آخر‪ .‬على سبيل المثال ‪ ،‬لغة البرمجة النصية‪-‬‬
‫لبرمجة النظام المستند إلى الويب ولكنه سيكون غير مناسب تمامًا لهندسة األنظمة المضمنة ‪ 1.1‬تطوير ‪ Ruby‬مثل ‪ guage‬يتم استخدام‬
‫البرامج االحترافية ‪ 1.1.3 13‬هندسة البرمجيات والويب كان لتطور شبكة الويب العالمية تأثير عميق على جميع مواقعنا األرواح‪ .‬في‬
‫البداية ‪ ،‬كان الويب في األساس عبارة عن مخزن معلومات يمكن الوصول إليه عالميًا و كان له تأثير ضئيل على أنظمة البرمجيات‪.‬‬
‫تعمل هذه األنظمة على أجهزة الكمبيوتر المحلية و ال يمكن الوصول إليها إال من داخل المنظمة‪ .‬حوالي عام ‪ ، 2000‬بدأ الويب تتطور‬
‫وتمت إضافة المزيد والمزيد من الوظائف إلى المتصفحات‪ .‬هذا يعني ذلك يمكن تطوير األنظمة المستندة إلى الويب حيث ‪ ،‬بدالً من‬
‫مستخدم ذي غرض خاص واجهة ‪ ،‬يمكن الوصول إلى هذه األنظمة باستخدام متصفح الويب‪ .‬هذا أدى إلى تطوير مجموعة واسعة من‬
‫يتم الوصول إليها عبر الويب‪ .‬غالبًا ما يتم تمويل هذه اإلعالنات من خالل ‪ ices ،‬منتجات النظام الجديدة التي تقدم خدمات مبتكرة‬
‫اإلعالنات المعروضة على شاشة‪ W‬المستخدم وال تتضمن دفعً ا مباشرً ا من المستخدمين‪ .‬فضال عن هذه المنتجات النظام ‪ ،‬وتطوير‬
‫متصفحات الويب التي يمكن تشغيل برامج صغيرة والقيام ببعض المعالجة المحلية أدت إلى تطور في األعمال التجارية و البرامج‬
‫التنظيمية‪ .‬بدالً من كتابة البرامج ونشرها على أجهزة الكمبيوتر الخاصة بالمستخدمين ‪ ،‬تم نشر البرنامج على خادم الويب‪ .‬هذا جعله‬
‫أرخص بكثير للتغيير وترقية البرنامج ‪ ،‬حيث لم تكن هناك حاجة لتثبيت البرنامج على كل جهاز كمبيوتر‪ .‬هو ‪ -‬هي خفض التكاليف‬
‫أيضً ا ‪ ،‬نظرً ا ألن تطوير واجهة المستخدم يعد مكل ًفا بشكل خاص‪ .‬وبالتالي ‪ ،‬أينما كان ذلك ممك ًنا ‪ ،‬انتقلت العديد من الشركات للتفاعل‬
‫المستند إلى الويب مع أنظمة برامج الشركة‪ .‬كانت المرحلة التالية في تطوير األنظمة المستندة إلى الويب هي فكرة الويب خدمات‪.‬‬
‫والتي يتم الوصول إليها عبر الويب‪ .‬يتم إنشاء التطبيقات عن طريق ‪- ality‬خدمات‪ W‬الويب هي مكونات برمجية تقدم وظيفة محددة ومفيدة‬
‫الدمج خدمات الويب هذه ‪ ،‬والتي قد تقدمها شركات مختلفة‪ .‬من حيث المبدأ ‪ ،‬هذا يمكن أن يكون االرتباط ديناميكيًا بحيث قد يستخدم‬
‫التطبيق خدمات‪ W‬ويب مختلفة في كل مرة أنه تم تنفيذه‪ .‬أغطي هذا النهج لتطوير البرمجيات في الفصل ‪ .19‬في السنوات القليلة الماضية ‪،‬‬
‫تم تطوير مفهوم "البرمجيات كخدمة"‪ .‬هو ‪ -‬هي تم اقتراح أن البرامج لن تعمل بشكل طبيعي على أجهزة الكمبيوتر المحلية ولكنها ستعمل‬
‫تعمل على "السحب الحاسوبية" التي يتم الوصول إليها عبر اإلنترنت‪ .‬إذا كنت تستخدم خدمة مثل البريد المستند إلى الويب ‪ ،‬فأنت‬
‫تستخدم نظامًا قائ ًم ا على السحابة‪ .‬سحابة الحوسبة عدد كبير من أنظمة الكمبيوتر المرتبطة التي يشاركها العديد من المستخدمين‪ .‬يفعل‬
‫المستخدمون ال تشتري البرامج ولكن تدفع وف ًق ا لمقدار استخدام البرنامج أو تقديمه حرية الوصول مقابل مشاهدة اإلعالنات التي يتم‬
‫عرضها على الشاشة‪ .‬لذلك ‪ ،‬أدى ظهور الويب إلى تغيير كبير في الطريقة التي يتم بها ذلك يتم تنظيم برامج األعمال‪ .‬قبل الويب ‪ ،‬كانت‬
‫تطبيقات األعمال في الغالب برامج أحادية متجانسة تعمل على أجهزة كمبيوتر فردية أو مجموعات كمبيوتر‪ .‬كانت االتصاالت محلية‬
‫في بعض األحيان في جميع أنحاء العالم‪ .‬تطبيقات األعمال ليست مبرمجة ‪- uted ،‬داخل المنظمة‪ .‬اآلن ‪ ،‬يتم توزيع البرامج بشكل كبير‬
‫من الصفر ولكنتنطوي على إعادة استخدام مكثف للمكونات والبرامج‪ .‬من الواضح أن هذا التغيير الجذري في تنظيم البرمجيات قد أدى‬
‫إلى تغييرات في الطرق التي يتم بها تصميم األنظمة المستندة إلى الويب‪ .‬على سبيل المثال‪ .1 :‬أصبحت إعادة استخدام البرامج هي‬
‫الطريقة السائدة لبناء شبكة اإلنترنت األنظمة‪ .‬عند بناء هذه األنظمة ‪ ،‬تفكر في كيفية التجميع ‪ 14‬الفصل ‪ 1‬مقدمة ‪ .2‬من المسلم به اآلن‬
‫بشكل عام أنه من غير العملي تحديد جميع المتطلبات‪ -‬إشارات لمثل هذه األنظمة مقدما‪ .‬يجب تطوير األنظمة المستندة إلى الويب ويتم‬
‫)‪ AJAX (Holdener ، 2008‬تسليمها بشكل تدريجي‪ . 3 .‬واجهات المستخدم مقيدة بإمكانيات متصفحات الويب‪ .‬بالرغم من تقنيات مثل‬
‫تعني أن الواجهات الغنية يمكن أن تكون كذلك تم إنشاؤها داخل مستعرض ويب ‪ ،‬ال تزال هذه التقنيات صعبة االستخدام‪ .‬الويب يتم‬
‫استخدام النماذج ذات البرمجة النصية المحلية بشكل أكثر شيوعً ا‪ .‬واجهات التطبيق قيد التشغيل غالبًا ما تكون األنظمة المستندة إلى الويب‬
‫ص ا على منتجات نظام الكمبيوتر‪ .‬األفكار األساسية لهندسة البرمجيات التي تمت مناقشتها‬ ‫أكثر فقراً من واجهات المستخدم المصممة خصي ً‬
‫في القسم السابق ‪ ،‬تنطبق على البرامج المستندة إلى الويب بنفس الطريقة التي تنطبق بها على األنواع األخرى من البرامج نظام وير‪.‬‬
‫الخبرة المكتسبة مع تطوير النظام الكبير في القرن العشرين ال يزال وثيق الصلة بالبرامج المستندة إلى الويب‪ 1.2 .‬أخالقيات هندسة‬
‫البرمجيات مثل التخصصات‪ W‬الهندسية األخرى ‪ ،‬يتم تنفيذ هندسة البرمجيات في نطاق اإلطار االجتماعي والقانوني الذي يحد من حرية‬
 ‫األشخاص العاملين في هذا المجال‪ .‬مثل مهندس برمجيات ‪ ،‬يجب أن تقبل أن وظيفتك تنطوي على مسؤوليات أكبر من مجرد تطبيق‬
‫المهارات الفنية‪ .‬يجب عليك أيضا أن تتصرف بطريقة أخالقية وطريقة مسؤولة أخالقيا إذا كنت تريد أن تحظى باالحترام كمهندس‬
‫محترف‪ .‬وغني عن القول أنه يجب عليك االلتزام بالمعايير العادية للصدق و نزاهة‪ .‬يجب أال تستخدم مهاراتك وقدراتك للتصرف بطريقة‬
‫غير شريفة أو بطريقة تؤدي إلى اإلضرار بسمعة مهنة هندسة البرمجيات‪ .‬لكن‪ ،‬هناك مجاالت ال تلتزم فيها معايير السلوك المقبول‬
‫بالقوانين ولكن بها المفهوم األكثر هشاشة للمسؤولية المهنية‪ .‬بعض هؤالء هم‪ .1 :‬السرية يجب أن تحترم عادة سرية عملك‪ -‬العمالء‪ W‬أو‬
‫العمالء بغض النظر عما إذا كانت اتفاقية سرية رسمية أم ال تم التوقيع‪ .2 .‬الكفاءة يجب أال تحرف مستوى كفاءتك‪ .‬يجب عدم قبول عمالً‬
‫خارج اختصاصك عن عمد‪ . 3 .‬حقوق الملكية الفكرية يجب أن تكون على دراية بالقوانين المحلية التي تحكم االستخدام للملكية الفكرية‬
‫مثل براءات االختراع وحقوق التأليف والنشر‪ .‬يجب أن تكون حريصً ا على ضمان حماية الملكية الفكرية ألصحاب العمل والعمالء‪.4 .‬‬
‫إساءة استخدام الكمبيوتر يجب أال تستخدم مهاراتك التقنية إلساءة استخدام اآلخرين أجهزة كمبيوتر األشخاص‪ .‬يتراوح سوء استخدام‬
‫الكمبيوتر من التافه نسب ًي ا (اللعب على جهاز صاحب العمل ‪ ،‬على سبيل المثال) إلى خطورة بالغة (نشر فيروسات أو البرامج الضارة‬
‫األخرى) ‪ 1.2.‬أخالقيات هندسة البرمجيات ‪ 15‬تلعب الجمعيات‪ W‬والمؤسسات‪ W‬المهنية دورً ا مهمًا في اإلعداد معليير أخالقية‪ .‬منظمات‪ W‬مثل‬
‫رمزا لـ السلوك المهني أو مدونة ‪ and Electronic Engineers) ،‬معهد الكهرباء( ‪ IEEE‬و ‪ACM ،‬‬ ‫ً‬ ‫وتنشر جمعية الكمبيوتر البريطانية‬
‫األخالق‪ .‬أعضاء هذه المنظمات يتعهدون اتبع هذا الرمز عند التسجيل للحصول على العضوية‪ .‬قواعد السلوك هذه عامة يهتم حرفيا‬
‫إنتاج مدونة مشتركة لألخالقيات والممارسات‪ IEEE W‬و ‪ ACM‬باألخالق األساسيةل‪ .‬السلوك‪ .‬وقد تعاونت الجمعيات‪ W‬المهنية ‪ ،‬وال سيما‬
‫)‪ (Gotterbarn et al. ، 1999‬المهنية‪ .‬هذا الرمز موجود في كل من ملف شكل قصير ‪ ،‬موضح في الشكل ‪ ، 1.3‬ونموذج أطول‬
‫يضيف التفاصيل والمضمون للنسخة األقصر‪ .‬األساس المنطقي وراء هذا الرمز هو ملخص‪ -‬منقسم في أول فقرتين من الشكل األطول‪:‬‬
‫تلعب أجهزة الكمبيوتر دورً ا مركزيًا ومتزاي ًد ا في التجارة والصناعة والحكومة الطب والتعليم والترفيه والمجتمع ككل‪ .‬مهندسو‬
‫البرمجيات هم أولئك الذين يساهمون عن طريق المشاركة‪ W‬المباشرة أو عن طريق التدريس ‪ ،‬في التحليل ‪ ،‬محددة‪ -‬اعتماد البرمجيات‬
‫وتصميمها وتطويرها وإصدار الشهادات لها وصيانتها واختبارها مدونة أخالقيات هندسة البرمجيات والممارسة المهنية فريق العمل‬
‫والمعني بأخالقيات‪ W‬هندسة البرمجيات والممارسات المهنية ديباجة تلخص النسخة القصيرة من الكود ‪ ACM / IEEE-CS‬المشترك بين‬
‫عال من التجريد ؛ البنود التي هي المدرجة في النسخة الكاملة تعطي أمثلة وتفاصيل عن كيفية تغيير هذه التطلعات‬ ‫التطلعات على مستوى ٍ‬
‫الطريقة التي نتصرف بها المتخصصين في هندسة البرمجيات‪ .‬بدون التطلعات ‪ ،‬يمكن أن تصبح التفاصيل قانونية ومملة ؛ بدون‬
‫رمزا متماس ًكا‪ .‬يلتزم مهندسو‬
‫ً‬ ‫التفاصيل ‪ ،‬يمكن أن تصبح التطلعات‪ W‬عالية الصوت ولكنها فارغة ؛ معا ‪ ،‬تطلعات و التفاصيل تشكل‬
‫البرمجيات‪ W‬بإجراء التحليل والمواصفات والتصميم والتطوير ‪ ،‬اختبار وصيانة البرمجيات مهنة مفيدة ومحترمة‪ .‬وف ًقا لها االلتزام بصحة‬
‫وسالمة ورفاهية الجمهور ‪ ،‬يلتزم مهندسو البرمجيات بما يلي ثمانية مبادئ‪ .1 :‬عام ‪ -‬يجب على مهندسي البرمجيات أن يتصرفوا بما‬
‫يتفق مع المصلحة العامة‪ .2 .‬العميل وصاحب العمل ‪ -‬يجب أن يتصرف مهندسو البرمجيات‪ W‬بطريقة في المصالح الفضلى للعميل‬
‫وصاحب العمل بما يتفق مع المصلحة العامة‪ . 3 .‬المنتج ‪ -‬يجب على مهندسي البرمجيات التأكد من أن منتجاتهم وما يتصل بها التعديالت‬
‫تفي بأعلى المعايير المهنية الممكنة‪ . 4 .‬الحكم ‪ -‬يجب على مهندسي البرمجيات الحفاظ على النزاهة واالستقاللية في الحكم المهنية‪.5 .‬‬
‫اإلدارة ‪ -‬يجب أن يشترك مديرو وقادة هندسة البرمجيات‪ W‬في و تعزيز النهج األخالقي إلدارة تطوير البرمجيات و صيانة‪ .6 .‬المهنة ‪-‬‬
‫مهندسو البرمجيات‪ W‬يجب أن يطوروا نزاهة وسمعة المهنة بما يتفق مع المصلحة العامة‪ .7 .‬الزمالء ‪ -‬يجب أن يكون مهندسو البرمجيات‪W‬‬
‫يجب أن يشارك مهندسو البرمجيات في التعلم مدى الحياة فيما يتعلق بـ ممارسة مهنتهم ويجب أن ‪. SELF -‬عادلين وداعمين لهم زمالء‪8 .‬‬
‫الفصل ‪ 1‬مقدمة ‪ (© IEEE / ACM 1999) 16‬األخالق ‪ ACM / IEEE Code of‬تعزز النهج األخالقي ل ممارسة المهنة‪ .‬الشكل ‪1.3‬‬
‫لديهم فرص كبيرة لفعل الخير أو التسبب في ضرر ‪ ،‬لتمكين اآلخرين من ‪ ، neers‬األنظمة‪ .‬بسبب أدوارهم في تطوير أنظمة البرمجيات‬
‫ذلك فعل الخير أو إلحاق الضرر ‪ ،‬أو التأثير على اآلخرين لفعل الخير أو التسبب في ضرر‪ .‬ل التأكد ‪ ،‬قدر اإلمكان ‪ ،‬من أن جهودهم‬
‫بجعل هندسة البرمجيات مفيدة و مهنة محترمة‪ .‬وف ًقا لهذا االلتزام ‪ ،‬مهندسو ‪ neers‬س ُتستخدم في هندسة البرمجيات‪ -‬يجب أن يلتزم‬
‫البرمجيات‪ W‬يجب أن تلتزم بقواعد األخالق والممارسة‪ W‬المهنية التالية‪ .‬تحتوي المدونة على ثمانية مبادئ تتعلق بسلوك وقرارات من صنع‬
‫مهندسي البرمجيات المحترفين ‪ ،‬بما في ذلكالممارسين والمعلمين ‪ ،‬المديرين والمشرفين وصانعي السياسات ‪ ،‬وكذلك المتدربين والطالب‬
‫المهنة‪ .‬تحدد المبادئ العالقات المسؤولة أخالقيا التي يشارك فيها األفراد والجماعات‪ W‬والمنظمات واألولية االلتزامات ضمن هذه العالقات‪.‬‬
‫في إنسانية مهندس ‪ gations‬تأسست‪ obli- W‬لبعض االلتزامات المدرجة في هذه العالقات‪ .‬هذه ‪- trations‬بنود كل مبدأ مضللة‬
‫البرمجيات‪ ، W‬في رعاية خاصة مستحقة لألشخاص المتأثرين بعمل مهندسي البرمجيات والعناصر الفريدة لممارسة‪ W‬هندسة البرمجيات‪.‬‬
‫ينص القانون على هذه األمور على أنها إلزامية‪ -‬أي شخص يدعي أنه مهندس برمجيات أو يطمح في أن يصبح‪ .‬في أي موقف يكون فيه‬
‫األشخاص المختلفون لديهم وجهات نظر وأهداف مختلفة أنت من المرجح أن تواجه معضالت أخالقية‪ .‬على سبيل المثال ‪ ،‬إذا كنت ال‬
‫التنوير القائل ‪ ،‬مع سياسات اإلدارة العليا في الشركة ‪ ،‬كيف ينبغي لك تتفاعل؟ من الواضح أن هذا يعتمد على ‪ princi-‬توافق ‪ ،‬في‬
‫األفراد المعينين وطبيعة العرض‪ .‬اتفاق‪ .‬هل من األفضل مناقشة قضية لموقفك من داخل المنظمة أم لالستقالة من حيث المبدأ؟ إذا شعرت‬
‫بوجود مشاكل في مشروع برمجي ‪ ،‬متى تكشف هذه لإلدارة؟ إذا ناقشت هذه بينما هم مجرد اشتباه ‪ ،‬قد تكون مبالغة في رد فعلك تجاه‬
‫موقف ما ؛ إذا تركته بعد فوات األوان ‪ ،‬فقد يكون األمر كذلك من المستحيل حل الصعوبات‪ .‬تواجهنا مثل هذه المعضالت‪ W‬األخالقية في‬
‫حياتنا المهنية ‪ ،‬ولحسن الحظ ‪ ،‬في معظم الحاالت إما أنها صغيرة نسبيًا أو يمكن حلها دون الكثير من الصعوبات‪ -‬صعوبة‪ .‬حيث ال يمكن‬
‫ص ا آخر مشكلة‪ .‬قد يكون اإلجراء المبدئي هو االستقالة من وظيفتهم ولكن هذا قد يكون ً‬
‫جيدا تؤثر‬ ‫حلها ‪ ،‬يواجه المهندس ‪ ،‬ربما ‪ ،‬شخ ً‬
‫على اآلخرين مثل شريكهم أو أطفالهم‪ .‬ينشأ موقف صعب بشكل خاص للمهندسين المحترفين عندما صاحب العمل يتصرف بطريقة غير‬
‫أخالقية‪ .‬لنفترض أن الشركة مسؤولة عن تطوير ملف نظام حرج للسالمة ‪ ،‬وبسبب ضغط الوقت ‪ ،‬يزور التحقق من السالمة السجالت‪.‬‬
‫تقع على عاتق المهندس مسؤولية الحفاظ على السرية أو تنبيه زبون أو يعلن ‪ ،‬بطريقة ما ‪ ،‬أن النظام الذي تم تسليمه قد يكون غير آمن؟‬
‫المشكلة هنا هي أنه ال توجد أمور مطلقة عندما يتعلق األمر بالسالمة‪ .‬بالرغم من ربما لم يتم التحقق من صحة النظام وف ًقا لمعايير محددة‬
‫ضا ‪ ،‬حتى عندما يتم التحقق من صحتها ‪ ria‬مسب ًقا ‪ ،‬قد تكون‬ ‫صارمة للغاية‪ .‬قد يعمل النظام في الواقع بأمان طوال حياته‪ .‬إنها الحالة أي ً‬
‫بشكل صحيح ‪ ،‬قد يفشل النظام ويسبب حادث‪ .‬قد يؤدي الكشف المبكر عن المشاكل إلى إلحاق الضرر بصاحب العمل و موظفين آخرين‬
‫قد يؤدي عدم الكشف عن المشاكل إلى إلحاق الضرر باآلخرين ‪ 1.3.‬دراسات الحالة ‪ 17‬يجب أن تتخذ قرارك في هذه األمور‪ .‬الموقف‬
‫األخالقي المناسب‪ -‬يعتمد هنا كليًا على آراء األفراد المعنيين‪ .‬في هذا احتمالية حدوث ضرر ‪ ،‬ومدى الضرر ‪ ،‬واألشخاص المتأثرين به‬
‫جد ا ‪ ،‬فقد يكون كذلك يمكن تبرير نشرها باستخدام الصحافة‪ W‬الوطنية (على‬ ‫يجب أن يؤثر الضرر على القرار‪ .‬إذا كان الوضع خطيرً ا ً‬
‫سبيل المثال)‪ .‬ومع ذلك ‪ ،‬يجب عليك حاول دائ ًم ا حل الموقف مع احترام حقوق صاحب العمل‪ .‬قضية أخالقية أخرى هي المشاركة في‬
‫تطوير العسكرية والنووية األنظمة‪ .‬يشعر بعض الناس بقوة تجاه هذه القضايا وال يرغبون في المشاركة‪ W‬فيها أي تطوير أنظمة مرتبطة‬
‫باألنظمة العسكرية‪ .‬آخرستعمل على ميلي‪ -‬لكن ليس على أنظمة األسلحة‪ .‬ومع ذلك ‪ ،‬يشعر اآلخرون أن األمن القومي هو المبدأ‬
‫األساسي وليس لديهم اعتراضات أخالقية على العمل على أنظمة األسلحة‪ .‬في هذه الحالة ‪ ،‬من المهم أن يقوم كل من أصحاب العمل‬
‫والموظفين بذلك وجهات نظرهم معروفة لبعضهم البعض مسب ًق ا‪ .‬حيث تشارك المنظمة في العمل العسكري أو النووي ‪ ،‬يجب أن يكونوا‬
‫قادرين على تحديد أن الموظفين يجب أن ‪ -‬جي لقبول أي مهمة عمل‪ .‬بالتساوي ‪ ،‬إذا تم أخذ الموظف وعمله واضحً ا أنهم ال يرغبون في‬
‫ضغط ا على‪ -‬تأكد منهم أن يفعلوا ذلك في وقت الحق‪ .‬أصبح المجال‬ ‫ً‬ ‫العمل على مثل هذه األنظمة ‪ ،‬فال ينبغي ألصحاب العمل أن يضعوا‬
‫العام لألخالق والمسؤولية المهنية أكثر مهم ألن األنظمة كثيفة البرامج تنتشر في كل جانب من جوانب العمل وكل يوم حياة‪ .‬يمكن‬
‫اعتباره من وجهة نظر فلسفية حيث المبادئ األساسية من األخالقيات‪ W‬وتناقش أخالقيات هندسة البرمجيات‪ W‬مع المرجع لهذه المبادئ‬
‫األساسية‪ .‬هذا هو النهج الذي اتبعه لودون (‪ )1995‬وإلى أقل منه مدى بواسطة هوف ومارتن (‪ .)1995‬نص جونسون عن أخالقيات‬
‫الكمبيوتر (‪ )2001‬أيضً ا يتعامل مع الموضوع من منظور فلسفي‪ .‬ومع ذلك ‪ ،‬أجد أن هذا النهج الفلسفي تجريدي للغاية ويصعب القيام به‬
‫تتعلق بالتجربة اليومية‪ .‬أنا أفضل النهج األكثر واقعية المتجسد في الرموز من السلوك والممارسة‪ .‬أعتقد أنه من األفضل مناقشة األخالق‬
‫في مهندس برمجيات‪ -‬جي السياق وليس كموضوع في حد ذاتها‪ .‬لذلك أنا ال أفعل في هذا الكتاب تتضمن مناقشات أخالقية مجردة ‪ ،‬ولكن‬
‫عند االقتضاء ‪ ،‬قم بتضمين أمثلة في التمارين التي يمكن أن تكون نقطة البداية لمناقشة جماعية حول القضايا األخالقية‪ 1.3 .‬دراسات‪W‬‬
‫الحالة لتوضيح مفاهيم هندسة البرمجيات ‪ ،‬أستخدم أمثلة من ثالثة مختلفة أنواع األنظمة في جميع أنحاء الكتاب‪ .‬سبب عدم استخدامي‬
‫على نوع األنظمة التي ‪ tice‬حالة واحدة الدراسة هي أن إحدى الرسائل الرئيسية في هذا الكتاب هي أن ممارسة‪ W‬هندسة البرمجيات يعتمد‬
‫يتم إنتاجها‪ .‬لذلك أختار مناسبًا‪ -‬أكل مثال عند مناقشة‪ W‬مفاهيم مثل السالمة واالعتمادية والنظام النمذجة وإعادة االستخدام وما إلى ذلك‪.‬‬
‫األنواع الثالثة لألنظمة التي أستخدمها‪ W‬كدراسات حالة هي‪ . 1 :‬نظام مضمن هذا نظام يتحكم فيه البرنامج في أحد األجهزة جهاز ومضمن‬
‫في هذا الجهاز‪ .‬المشكالت في األنظمة المضمنة عاد ًة ‪ 18‬الفصل األول مقدمة تشمل الحجم المادي ‪ ،‬واالستجابة ‪ ،‬وإدارة الطاقة ‪ ،‬وما‬
‫إلى ذلك‪ .‬مثال النظام المضمن الذي أستخدمه هو نظام برمجي للتحكم في جهاز طبي‪ .2 .‬نظام المعلومات هذا نظام هدفه األساسي هو‬
‫اإلدارة وتوفير الوصول إلى قاعدة بيانات للمعلومات‪ .‬قضايا في نظم المعلومات تشمل األمان وسهولة االستخدام والخصوصية والحفاظ‬
‫على تكامل البيانات‪ .‬المثال من نظام المعلومات الذي أستخدمه هو نظام السجالت الطبية‪ .3 .‬نظام جمع البيانات القائم على أجهزة‬
‫االستشعار هذا النظام غرضه األساسي هو جمع البيانات من مجموعة من أجهزة االستشعار ومعالجة تلك البيانات بطريقة ما‪ .‬ال‬
‫المتطلبات الرئيسية لهذه األنظمة هي الموثوقية ‪ ،‬حتى في البيئة المعادية الشروط وقابلية الصيانة‪ .‬مثال على نظام جمع البيانات أن أنا‬
‫استخدم محطة طقس برية‪ .‬أقدم كل من هذه األنظمة في هذا الفصل ‪ ،‬مع مزيد من المعلومات حول كل واحد منهم متاح على الويب‪.‬‬
‫البرنامج الذي ‪).‬عضو داخلي ‪ 1.3.1 (an‬نظام التحكم في مضخة األنسولين مضخة األنسولين هي نظام طبي يحاكي عمل البنكرياس‬
‫يتحكم في هذاالنظام هو نظام مضمن ‪ ،‬والذي يجمع المعلومات من جهاز االستشعار ويتحكم في المضخة التي توفر جهاز تحكم جرعة‬
‫األنسولين للمستخدم‪ .‬األشخاص الذين يعانون من مرض السكري يستخدمون هذا النظام‪ .‬مرض السكري شائع نسبيًا الحالة التي يكون فيها‬
‫البنكرياس البشري غير قادر على إنتاج كميات‪ W‬كافية من أ هرمون يسمى األنسولين‪ .‬يستقلب األنسولين الجلوكوز (السكر) في الدم‪.‬‬
‫يخدع‪ -‬العالج المتعمد لمرض السكري يشمل الحقن المنتظمة للهندسة الجينية األنسولين‪ .‬يقيس مرضى السكر مستويات السكر في الدم‬
‫باستخدام مقياس خارجي ثم احسب جرعة األنسولين التي يجب حقنها‪ .‬تكمن مشكلة هذا العالج في أن مستوى األنسولين المطلوب ليس‬
‫فقط تعتمد على مستوى الجلوكوز في الدم ولكن أيضً ا على وقت آخر حقن األنسولين‪ .‬هذا يمكن أن يؤدي إلى مستويات منخفضة جدا من‬
‫الجلوكوز في الدم (إذا كان هناك الكثير من األنسولين) أو جدا مستويات عالية من السكر في الدم (إذا كان هناك القليل من األنسولين)‪.‬‬
‫انخفاض نسبة الجلوكوز في الدم ‪ ،‬في على المدى القصير ‪ ،‬حالة أكثر خطورة ألنها يمكن أن تؤدي إلى خلل مؤقت في وظائف الدماغ‬
‫وفي النهاية فقدان الوعي والموت‪ .‬على المدى الطويل ‪ ،‬مع ذلك ‪ ،‬ارتفاع مستمر يمكن أن تؤدي مستويات الجلوكوز في الدم إلى تلف‬
‫العين وتلف الكلى ومشاكل في القلب‪ .‬إن التطورات الحالية في تطوير أجهزة االستشعار المصغرة تعني أنه أصبح اآلن ممك ًنا قادر على‬
 ‫تطوير أنظمة تلقائية لتوصيل األنسولين‪ .‬تراقب هذه األنظمة نسبة السكر في الدم المستويات وإعطاء جرعة مناسبة من األنسولين عند‬
‫الحاجة‪ .‬أنظمة توصيل األنسولين مثل هذا موجود بالفعل لعالج مرضى المستشفى‪ .‬في المستقبل ‪ ،‬قد يكون من الممكن‪ -‬يمكن للعديد من‬
‫مرضى السكر أن يكون لديهم مثل هذه األنظمة متصلة بأجسامهم بشكل دائم‪ .‬قد يعمل نظام توصيل األنسولين المتحكم فيه بالبرمجيات‬
‫باستخدام جهاز ميكرو جهاز استشعار مضمن في المريض لقياس بعض متغيرات الدم المتناسبة إلى مستوى السكر‪ .‬ثم يتم إرسال هذا إلى‬
‫وحدة تحكم المضخة‪ .‬وحدة التحكم هذه تحسب مستوى السكر وكمية األنسولين المطلوبة‪ .‬ثم يرسل إشارات إلى ملف ‪ 1‬مضخة مصغرة‬
‫لتوصيل األنسولين عبر إبرة متصلة بشكل دائم ‪ 1.3.‬دراسات‪ W‬الحالة ‪ 19‬يوضح الشكل ‪ 1.4‬مكونات األجهزة وتنظيم األنسولين مضخة‪.‬‬
‫لفهم األمثلة الواردة في هذا الكتاب ‪ ،‬كل ما تحتاج إلى معرفته هو أن جهاز استشعار الدم يقيس التوصيل الكهربائي للدم تحت مختلف‬
‫الشروط وأن هذه القيم يمكن أن تكون مرتبطة بمستوى السكر في الدم‪ .‬ال تقوم مضخة األنسولين بتوصيل وحدة واحدة من األنسولين‬
‫استجابة لنبضة واحدة من ترولر‪ .‬لذلك ‪ ،‬لتوصيل ‪ 10‬وحدات من األنسولين ‪ ،‬يرسل جهاز التحكم ‪ 10‬نبضات إلى المضخة‪ .‬الشكل ‪1.5‬‬ ‫ً‬
‫يوضح كيفية عمل البرنامج يحول مستوى السكر في الدم المدخل إلى سلسلة من األوامر التي تدفع مضخة ‪ UML‬هو نموذج نشاط‬
‫األنسولين‪ .‬من الواضح أن هذا نظام حرج للسالمة‪ .‬إذا فشلت المضخة في العمل أو ال تعمل تعمل بشكل صحيح ‪ ،‬فقد تتضرر صحة‬
‫المستخدم أو قد يقع في غيبوبة ألن مستويات السكر في الدم مرتفعة ج ًدا أو منخفضة ج ًدا‪ .‬هناك ‪ ،‬لذلك ‪ ،‬اثنين من المتطلبات األساسية‬
‫عالية المستوى التي يجب أن يلبيها هذا النظام‪ .1 :‬يجب أن يكون النظام متاحً ا لتوصيل األنسولين عند الحاجة‪ .2 .‬يجب أن يعمل النظام‬
‫عرض ‪ Display1‬بشكل موثوق وأن يسلم الكمية الصحيحة من األنسولين إليها مواجهة المستوى الحالي لسكر الدم‪ .‬إبرة َحشد المستشعر‬
‫‪ 2‬إنذار ساعة المضخة مراقب مزود الطاقة خزان األنسولين الشكل ‪ 1.4‬األنسولين أجهزة المضخة دم المستشعر األنسولين مضخة دم‬
‫سكر تحليل المستشعر قراءة إحصاء ‪ -‬عد األنسولين األنسولين جرعة األنسولين سجل لوز جرعة مضخة حساب أوامر مضخة بيانات‬
‫السيطرة على األنسولين مضخة الشكل ‪ 1.5‬النشاط نموذج األنسولين مضخة ‪ 20‬الفصل ‪ 1‬مقدمة لذلك يجب تصميم النظام وتنفيذه‬
‫لضمان أن النظام‪ -‬تيم يلبي دائ ًم ا هذه المتطلبات‪ .‬متطلبات ومناقشات أكثر تفصيال حول كيفية التأكد من أن النظام آمن ستتم مناقشته‪ W‬في‬
‫فصول الحقة‪ 1.3.2 .‬نظام معلومات المريض لرعاية الصحة العقلية نظام معلومات المريض لدعم رعاية الصحة العقلية هو معلومات‬
‫طبية‪ -‬نظام يحافظ على المعلومات حول المرضى الذين يعانون من مشاكل نفسية المشاكل الصحية والعالجات‪ W‬التي تلقوها‪ .‬معظم الصحة‬
‫العقلية ال يحتاج المرضى إلى عالج مخصص في المستشفى ولكنهم بحاجة إلى حضور أخصائي العيادات بانتظام حيث يمكنهم مقابلة‬
‫طبيب لديه معرفة مفصلة به مشاكلهم‪ .‬لتسهيل حضور المرضى ‪ ،‬فإن هذه العيادات ليست فقط تعمل في المستشفيات‪ .‬قد يتم احتجازهم‬
‫بمثابة معلومات‪) -‬نظام إدارة رعاية مرضى الصحة العقلية( ‪ MHC-PMS‬أيضً ا في الممارسات الطبية المحلية أو المجتمع المراكز‪ .‬يعد‬
‫نظام مخصص لالستخدام في العيادات‪ .‬يستخدم قاعدة بيانات مركزية لـ معلومات المريض ولكن تم تصميمها أيضً ا للتشغيل على جهاز‬
‫كمبيوتر ‪ ،‬بحيث يمكن الوصول إليها ويتم استخدامها من المواقع التي ال تحتوي على اتصال آمن بالشبكة‪ .‬عندما‪ -‬يتمتع الموظفون‬
‫بوصول آمن إلى الشبكة ‪ ،‬ويستخدمون معلومات المريض في قاعدة البيانات لكنهم يمكن تنزيل واستخدام نسخ محلية من سجالت‬
‫المرضى عند فصلها‪ .‬ال النظام ليس نظام سجالت‪ W‬طبية كامل لذلك ال يحتفظ بالمعلومات حول الحاالت الطبية األخرى‪ .‬ومع ذلك ‪ ،‬قد‬
‫على هدفين ‪ MHC-PMS‬يحتوي ‪ MHC-PMS.‬تتفاعل وتتبادل البيانات مع اآلخرين نظم المعلومات السريرية‪ .‬يوضح الشكل ‪ 1.6‬تنظيم‬
‫عامين‪ .1 :‬لتوليد معلومات اإلدارة التي تسمح لمديري الخدمات‪ W‬الصحية تقييم األداء مقابل األهداف المحلية والحكومية‪ .2 .‬لتزويد الطاقم‬
‫‪ MHC-PMS‬محلي ‪ MHC-PMS‬قاعدة بيانات المرضى ‪ MHC-PMS‬الطبي بالمعلومات في الوقت المناسب لدعم عالج مرضى‪ .‬خادم‬
‫طبيعة مشاكل الصحة العقلية هي أن المرضى غالبًا ما ‪ MHC-PMS1.3 21‬محلي الشكل ‪ 1.6‬تنظيم دراسات الحالة ‪ MHC-PMS‬محلي‬
‫يكونون غير منظمين لذلك قد يفوتك المواعيد أو يفقد الوصفات الطبية عم ًد ا أو عن طريق الخطأ ويؤدي‪ -‬انسى التعليمات واطلب من‬
‫الطاقم الطبي مطالب غير معقولة‪ .‬هم قد تسقط في العيادات بشكل غير متوقع‪ .‬في حاالت قليلة ‪ ،‬قد تكون خطرا على ألنفسهم أو‬
‫ألشخاص آخرين‪ .‬قد يغيرون العنوان بانتظام أو قد يكونون في المنزل‪ -‬أقل على المدى الطويل أو المدى القصير‪ .‬عندما يكون المرضى‬
‫خطرين ‪ ،‬فقد يحتاجون أن تكون "مقسمة"‪ - W‬محصورة في مستشفى آمن للعالج والمراقبة‪ .‬يشمل مستخدمو النظام الطاقم السريري مثل‬
‫المستخدمون غير ‪).‬الممرضات‪ W‬الذين يزورون الناس في المنزل للتحقق من عالجهم( ‪. tors‬األطباء والممرضات والزيارات الصحية‬
‫الطبيين تشمل موظفي االستقبال الذين يقومون بتحديد المواعيد وموظفي السجالت الطبية الذين يقومون بالحفاظ عليها نظام السجالت‪W‬‬
‫والموظفين اإلداريين الذين يقومون بإعداد التقارير‪ .‬يستخدم النظام لتسجيل المعلومات عن المرضى (االسم ‪ ،‬العنوان ‪ ،‬العمر ‪ ،‬التالي‬
‫األقارب ‪ ،‬وما إلى ذلك) ‪ ،‬االستشارات (التاريخ ‪ ،‬زيارة الطبيب ‪ ،‬االنطباعات الشخصية للمريض ‪ ،‬إلخ) والشروط والعالجات‪ .‬يتم إنشاء‬
‫الموظفين ومديري السلطات الصحية‪ .‬عادة ‪ ،‬تركز التقارير الخاصة بالطاقم الطبي على معلومات ‪ med-‬التقارير على فترات منتظمة لـ‬
‫حول المرضى األفراد في حين أن تقارير اإلدارة مجهولة المصدر ويهتمونالشروط وتكاليف العالج وما إلى ذلك‪ .‬الميزات الرئيسية‬
‫للنظام هي‪ .1 :‬يمكن ألطباء إدارة الرعاية الفردية إنشاء سجالت‪ W‬للمرضى ‪ ،‬وتحرير المعلومات في النظام ‪ ،‬وعرض تاريخ المريض ‪،‬‬
‫ضا من قبل أن يفعلوا ذلك بسرعة تعرف على‬ ‫وما إلى ذلك‪ .‬يدعم النظام البيانات الملخصات بحيث يمكن لألطباء الذين لم يقابلوا مري ً‬
‫المشاكل الرئيسية والعالجات‪ W‬التي تم وصفها‪ . 2 .‬مراقبة المريض يقوم النظام بمراقبة سجالت المرضى بانتظام يشاركون في العالج‬
‫ويصدرون تحذيرات إذا تم الكشف عن مشاكل محتملة‪ .‬لذلك ‪ ،‬إذا لم يقم المريض بزيارة الطبيب لبعض الوقت ‪ ،‬فقد يكون هناك تحذير‬
‫صادر‪ .‬الحفاظ على أحد أهم عناصر نظام المراقبة تتبع المرضى الذين تم تقسيمهم والتأكد من أن المطلوب قانونيًا يتم إجراء الفحوصات‬
‫في الوقت المناسب‪ . 3 .‬التقارير اإلدارية يقوم النظام بإنشاء تقارير إدارية شهرية بيان عدد المرضى المعالجين في كل عيادة وعدد‬
 ‫المرضى الذين دخلوا وخرجوا من نظام الرعاية ‪ ،‬وعدد المرضى المقطوعين ‪ ،‬و األدوية الموصوفة وتكاليفها ‪ ،‬إلخ‪ .‬قانونان مختلفان‬
‫يؤثران على النظام‪ .‬هذه هي قوانين حماية البيانات التي تحكم سرية المعلومات الشخصية وقوانين الصحة العقلية التي تحكم الشركة‪-‬‬
‫الحجز اإلجباري للمرضى الذين يعتبرون خطراً على أنفسهم أو على اآلخرين‪ .‬عقلي الصحة فريدة من نوعها في هذا الصدد ألنها‬
‫التخصص الطبي الوحيد الذي يمكن أن يوصي به احتجاز المرضى رغما ً عنهم‪ .‬هذا يخضع لسالمة تشريعية صارمة للغاية‪ -‬حراس‪.‬‬
‫في التأكد من أن الموظفين يتصرفون دائمًا وف ًقا لما يلي‪ -‬أن يخالفوا القانون وأن قراراتهم مسجلة ‪ MHC-PMS‬يتمثل أحد أهداف‬
‫للمراجعة القضائية إذا لزم األمر‪ .‬كما هو الحال في جميع األنظمة الطبية ‪ ،‬تعد الخصوصية مطلبًا أساسيًا للنظام‪ .‬فمن الضروري أن‬
‫‪ MHC-PMS‬معلومات المريض سرية وال يتم الكشف عنها ألي شخص باستثناء المؤلف‪ -‬الطاقم الطبي والمريض نفسه‪ .‬يعتبر نظام‬
‫أيضً ا عنصرً ا حرجً ا للسالمة ‪ 22‬الفصل ‪ 1‬مقدمة نظام‪ .‬تتسبب بعض األمراض العقلية في أن يصبح المرضى قادرين على االنتحار أو‬
‫أو ‪ cidal‬يشكلون خطراً على اآلخرين الناس‪ .‬حيثما كان ذلك ممك ًن ا ‪ ،‬يجب أن يحذر النظام الطاقم الطبي من احتمال وجود‪ -‬المرضى‬
‫الخطرين‪ .‬يجب أن يأخذ التصميم العام للنظام بعين االعتبار الخصوصية واألمان متطلبات‪ .‬يجب أن يكون النظام متاحً ا عند الحاجة وإال‬
‫فقد تكون السالمة للخطر وقد يكون من المستحيل وصف الدواء المناسب للمرضى‪ .‬يوجد تعارض محتمل هنا ‪ -‬الخصوصية أسهل في‬
‫الحفاظ عليها عندما ال يوجد سوى ملف نسخة واحدة من بيانات النظام‪ .‬ومع ذلك ‪ ،‬لضمان التوافر في حالة الخادم فشل أو عند قطع‬
‫االتصال بشبكة ‪ ،‬يجب أن تكون نسخ متعددة من البيانات صيانتها‪ .‬أناقش المفاضالت بين هذه المتطلبات في فصول الحقة‪1.3.3 .‬‬
‫محطة طقس برية للمساعدة في مراقبة تغير المناخ وتحسين دقة التنبؤات الجوية في المناطق النائية ‪ ،‬تقرر حكومة بلد به مساحات كبيرة‬
‫بيانات محاضرة من مجموعة من األدوات ‪ col-‬من البرية نشر عدة مئات من محطات‪ W‬الطقس في المناطق النائية‪ .‬هذه محطات الطقس‬
‫التي تقيس درجة الحرارة والضغط وأشعة الشمس ‪ ،‬هطول األمطار وسرعة الرياح واتجاه الرياح‪ .‬تعد محطات الطقس البرية جزءًا من‬
‫نظام أكبر (الشكل ‪ ، ) 1.7‬وهو أ نظام معلومات الطقس الذي يجمع البيانات من محطات الطقس ويصنعها متاح لألنظمة األخرى‬
‫بيانات الطقس ‪ ،‬إجراء بعض عمليات ‪g‬للمعالجة‪ .‬األنظمة في الشكل ‪ 1.7‬هي‪ .1 :‬نظام محطة الطقس هذا هو المسؤول عن التجميع‬
‫المعالجة األولية للبيانات ‪ ،‬وتحويلها إلى إدارة البيانات‪ -‬نظام منة‪ . 2 .‬نظام إدارة البيانات واألرشفة يقوم هذا النظام بجمع البيانات من‬
‫جميع محطات الطقس البرية ‪ ،‬وتقوم بمعالجة البيانات وتحليلها ‪ ،‬وأرشفة البيانات في شكل يمكن استرداده بواسطة أنظمة أخرى ‪ ،‬مثل‬
‫أنظمة التنبؤ بالطقس‪ . 3 .‬نظام صيانة المحطة يمكن لهذا النظام التواصل عبر األقمار الصناعية مع جميع محطات الطقس البرية لمراقبة‬
‫صحة هذه األنظمة و تقديم تقارير عن المشاكل‪ .‬يمكنه تحديث البرامج المضمنة في هذه األنظمة‪ .‬في حالة وجود مشاكل في النظام ‪،‬‬
‫يمكن أيضً ا استخدام هذا النظام ل التحكم عن بعد في نظام الطقس البري‪" .‬نظام" إدارة البيانات واألرشفة "نظام" صيانة المحطة "نظام"‬
‫لإلشارة إلى أن ‪ UML‬محطة الطقس الشكل ‪ 1.7‬الطقس بيئة المحطة ‪ 1.3‬دراسات‪ W‬الحالة ‪ 23‬في الشكل ‪ ، 1.7‬استخدمت رمز حزمة‬
‫نظام»‪ .‬تشير االرتباطات « ‪ UML‬كل نظام عبارة عن مجموعة من المكونات وقد حددت األنظمة المنفصلة باستخدام الصورة النمطية لـ‬
‫بين الحزم إلى وجود تبادل المعلومات ولكن ‪ ،‬في هذه المرحلة ‪ ،‬ليست هناك حاجة لتعريفها في أي منها تفاصيل اكثر‪ .‬تتضمن كل محطة‬
‫أرصاد جوية عد ًدا من األدوات التي تقيس الطقس معلمات‪ W‬مثل سرعة الرياح واتجاهها ودرجات حرارة األرض والجو ‪ ،‬الضغط‬
‫الجوي ‪ ،‬وهطول األمطار خالل فترة ‪ 24‬ساعة‪ .‬كل من هذه التعليمات‪ -‬يتم التحكم في البيانات من خالل نظام برمجي يأخذ قراءات‬
‫المعلمات بشكل دوري ويدير البيانات التي تم جمعها‪ W‬من األدوات‪ .‬يعمل نظام محطة الطقس من خالل جمع مالحظات الطقس على فترات‬
‫متقطعة‪ .‬فواصل خماسية ‪ -‬على سبيل المثال ‪ ،‬يتم قياس درجات الحرارة كل دقيقة‪ .‬لكن‪ ،‬ألن عرض النطاق الترددي للقمر الصناعي‬
‫بيانات بوابات عندما يطلبها ‪ aggre-‬ضيق نسبيًا ‪ ،‬فإن محطة الطقس تحمل خارج بعض المعالجة المحلية وتجميع البيانات‪ .‬ثم ينقل هذا‬
‫نظام جمع البيانات‪ .‬إذا كان كذلك ألي سبب من األسباب من المستحيل إجراء اتصال ‪ ،‬ثم تحتفظ محطة الطقس بالبيانات محليًا حتى يمكن‬
‫استئناف االتصال‪ .‬تعمل كل محطة أرصاد جوية بالبطارية ويجب أن تكون قائمة بذاتها ‪ -‬هناك ال تتوفر كبالت طاقة أو شبكة خارجية‪.‬‬
‫جميع االتصاالت من خالل عالقة يجب أن يشتمل ارتباط األقمار الصناعية بطيء السرعة ومحطة الطقس على بعض اآلليات (الطاقة‬
‫الشمسية أو طاقة الرياح) لشحن بطارياتها‪ .‬حيث يتم نشرهم في المناطق البرية ‪ ،‬يتعرضون لظروف بيئية قاسية ويمكن أن تتلفهم‬
‫الحيوانات‪ .‬لذلك فإن برنامج المحطة ال يهتم فقط بجمع البيانات‪ .‬يجب أيضًا‪ .1 :‬مراقبة األجهزة والطاقة وأجهزة االتصال واإلبالغ عن‬
‫األعطال لنظام اإلدارة‪ . 2 .‬إدارة طاقة النظام ‪ ،‬والتأكد من أن البطاريات مشحونة في أي وقت تسمح الظروف البيئية ولكن أي ً‬
‫ضا يتم‬
‫إغالق المولدات يحتمل أن تكون ضارة بالظروف الجوية ‪ ،‬مثل الرياح العاتية‪ . 3 .‬السماح بإعادة التكوين الديناميكي حيث يتم استبدال‬
‫أجزاء من البرنامج مع اإلصدارات الجديدة وحيث يتم تحويل أدوات النسخ االحتياطي إلى النظام في حالة فشل النظام‪ .‬نظرً ا ألن محطات‬
‫الطقس يجب أن تكون مكتفية ذات ًي ا وغير مراقبة ‪ ،‬فهذا يعني أن البرنامج المثبت معقد ‪ ،‬على الرغم من وظيفة جمع البيانات بسيط إلى حد‬
‫ما‪ 24 .‬الفصل ‪ 1‬مقدمة النقاط الرئيسية هندسة البرمجيات هي تخصص هندسي يهتم بجميع جوانببرمجة إنتاج‪ .‬البرامج ليست مجرد‬
‫ضا وثائق‪ .‬البرامج األساسية‪ W‬سمات‪ W‬المنتج هي قابلية الصيانة واالعتمادية واألمن والكفاءة والمقبولية‪.‬‬‫برنامج أو برامج ولكنها تتضمن أي ً‬
‫تتضمن عملية البرنامج جميع األنشطة التي ينطوي عليها تطوير البرامج‪ .‬عالية‪ -‬تعد أنشطة مستوى المواصفات والتطوير والتحقق من‬
‫الصحة والتطور جز ًء ا من جميع البرامج العمليات‪ .‬المفاهيم األساسية لهندسة البرمجيات قابلة للتطبيق عالميًا على جميع أنواع تطوير‬
‫النظام‪ .‬تتضمن هذه األساسيات‪ W‬عمليات البرامج ‪ ،‬واالعتمادية ‪ ،‬واألمان ‪ ،‬المتطلبات وإعادة االستخدام‪ .‬هناك العديد من أنواع األنظمة‬
‫المختلفة ويتطلب كل منها هندسة برمجيات مناسبة أدوات وتقنيات لتنميتها‪ .‬هناك عدد قليل ‪ ،‬إن وجد ‪ ،‬تصميم محدد و تقنيات التنفيذ التي‬
‫تنطبق على جميع أنواع األنظمة‪ .‬تنطبق األفكار األساسية لهندسة البرمجيات على جميع أنواع أنظمة البرمجيات‪ .‬تتضمن هذه األساسيات‬
 ‫عمليات البرامج المدارة ‪ ،‬واالعتماد على البرامج وأمانها ‪ ،‬هندسة المتطلبات وإعادة استخدام البرامج‪ .‬يتحمل مهندسو البرمجيات‬
‫مسؤوليات تجاه مهنة الهندسة والمجتمع‪ .‬يجب عليهم ال تهتم فقط بالمسائل الفنية‪ .‬تنشر الجمعيات‪ W‬المهنية قواعد السلوك التي تحدد معايير‬
‫السلوك المتوقعة من أعضائها‪ .‬قراءة متعمقة "ال حل سحري‪ :‬جوهر وحوادث هندسة البرمجيات"‪ .‬على الرغم من عمرها ‪ ،‬فإن هذه‬
‫‪ ، IEEE‬ف‪.‬بروكس( ‪.‬الورقة عبارة عن ملف مقدمة عامة جيدة لمشاكل هندسة البرمجيات‪ .‬الرسالة األساسية ل الورق لم يتغير بعد‬
‫تمت " ‪) http://doi.ieeecomputersociety.org/10.1109/MC.1987.1663532.‬أبريل ‪Computer ، 20 (4) ، 1987‬‬
‫والتي تشمل كال من ‪ ACM / IEEE‬الموافقة على مدونة أخالقيات هندسة البرمجيات"‪ .‬مقال يناقش خلفية ملف تطوير مدونة األخالق لدى‬
‫)‪. (Comm. ACM، D. Gotterbarn، K. Miller، and S. Rogerson، October 1999.‬الشكل القصير والطويل لـ شفرة‬
‫قضايا مهنية في هندسة البرمجيات‪ .‬هذا كتاب ممتاز يناقش ‪doid=317665.317682.‬؟‪http://portal.acm.org/citation.cfm‬‬
‫الشؤون القانونية و القضايا المهنية وكذلك األخالق‪ .‬أنا أفضل نهجها العملي على المزيد من النصوص النظرية حول أخالق مهنية‪( .‬ف‪.‬‬
‫‪ IEEE Software ،‬بوت ‪ ،‬أ‪.‬كولمان ‪ ،‬ج إيتون ود‪ .‬روالند ‪ ،‬الطبعة الثالثة ‪ ، 2000 ،‬تايلور وفرانسيس‪ ).‬الفصل األول تمارين ‪25‬‬
‫مارس ‪ /‬أبريل ‪ .2002‬هذا عدد خاص من المجلة مخصص لـ تطوير البرمجيات المستندة إلى الويب‪ .‬لقد تغيرت هذه المنطقة بسرعة‬
‫)‪ IEEE، 19 (2) ، 2002.‬برنامج( ‪.‬كبيرة لذا فإن بعض المقاالت قليلة مؤرخة ولكن معظمها‪ W‬ال تزال ذات صلة‬
‫منظر لهندسة البرمجيات في القرنين العشرين والحادي والعشرين"‪http://www2.computer.org/portal/web/software. " .‬‬
‫تميزا‪ .‬يعرف باري بوم مبادئ هندسة‬‫ً‬ ‫نظرة إلى الوراء واألمام على البرامج الهندسة من أحد أوائل مهندسي البرمجيات وأكثرهم‬
‫‪. (B. Boehm، Proc. 28th‬البرمجيات الخالدة ولكنها تشير أيضً ا إلى أن بعض الممارسات‪ W‬الشائعة االستخدام كذلك عفا عليها الزمن‬
‫)‪Software Engineering Conf.، Shanghai. 2006.‬‬
‫أخالقيات هندسة البرمجيات"‪ .‬عدد خاص من" ‪http://doi.ieeecomputersociety.org/10.1145/1134285.1134288.‬‬
‫‪.) E X E R C I S E S 1.1‬يونيو ‪. (IEEE Computer، 42 (6) ، 2009‬مع عدد من األوراق حول الموضوع ‪IEEE Computer ،‬‬
‫اشرح لماذا البرامج االحترافية ليست مجرد برامج تم تطويرها للعميل‪ 1.2 .‬ما هو االختالف األكثر أهمية بين تطوير منتجات البرامج‬
‫العامة و تطوير البرامج المخصصة؟ وهاقد يعني هذا عمليًا لمستخدمي البرامج العامة منتجات؟ ‪ 1.3‬ما هي السمات األربع المهمة التي‬
‫يجب أن تتمتع بها جميع البرامج االحترافية؟ يقترح أربع سمات أخرى قد تكون مهمة في بعض األحيان‪ 1.4 .‬بصرف النظر عن تحديات‬
‫عدم التجانس ‪ ،‬واألعمال التجارية والتغيير االجتماعي ‪ ،‬والثقة و األمان ‪ ،‬وتحديد المشكالت‪ W‬والتحديات األخرى التي من المحتمل أن‬
‫تواجهها‪ W‬هندسة البرمجيات القرن الحادي والعشرون (تلميح‪ :‬فكر في البيئة)‪ 1.5 .‬بنا ًء على معرفتك الخاصة ببعض أنواع التطبيقات التي‬
‫تمت مناقشتها‪ W‬في القسم ‪ ، 1.1.2‬اشرح ‪ ،‬بأمثلة ‪ ،‬لماذا تتطلب أنواع التطبيقات المختلفة برامج متخصصة التقنيات الهندسية لدعم‬
‫تصميمها وتطويرها‪ 1.6 .‬اشرح سبب وجود أفكار أساسية لهندسة البرمجيات‪ W‬تنطبق على جميع أنواع أنظمة البرمجيات‪ 1.7 .‬اشرح‬
‫كيف غيّر االستخدام العالمي للويب أنظمة البرامج‪ 1.8 .‬ناقش ما إذا كان يجب اعتماد المهندسين المحترفين بنفس طريقة اعتماد األطباء‬
‫الموضحة في الشكل ‪ ، 1.3‬اقترح ملف المثال المناسب ‪ ACM / IEEE‬أو المحامين‪ 1.9 .‬لكل بند من البنود الواردة في مدونة أخالقيات‬
‫ً‬
‫أعدادا‬ ‫الذي يوضح تلك الفقرة‪ .1.10 .‬للمساعدة في مكافحة‪ W‬اإلرهاب ‪ ،‬تخطط العديد من البلدان ألنظمة الكمبيوتر أو طورت التي تتعقب‬
‫كبيرة من مواطنيها وأفعالهم‪ .‬من الواضح أن هذا له خصوصية تداعيات‪ .‬ناقش أخالقيات العمل على تطوير هذا النوع من النظام‪26 .‬‬
‫تمت الموافقة على مدونة أخالقيات ‪ Gotterbarn ، D. ، Miller ، K. and Rogerson ، S. (1999).‬الفصل األول مقدمة مراجع‬
‫‪:‬هولدنر ‪ ،‬أ‪.‬ت‪ .)2008( .‬اياكس‪ :‬الدليل النهائي‪ .‬سيباستوبول ‪ ،‬كاليفورنيا ‪ ACM ، 42 (10) ، 102-7.‬هندسة البرمجيات‪ .‬باالتصاالت‬
‫هوف ‪ ،‬سي ومارتن ‪ ،‬سي دي (‪ .)1995‬عواقب الحوسبة‪ :‬إطار لتدريس األخالق الحوسبة‪ .‬باالتصاالت ‪O’Reilly and Associates.‬‬
‫جونسون ‪ ،‬دي جي (‪ .) 2001‬أخالقيات استخدام أجهزة الكمبيوتر‪ .‬إنجليوود كليفس ‪ ،‬نيوجيرسي‪ :‬برنتيس ‪ACM، 38 (12) ، 75-84.‬‬
‫نور ‪ ،‬ص‪ .‬وراندل ‪ ACM ، 38 (12) ، 33-9. ،‬هول‪ .‬لودون ‪ ،‬ك‪ .)1995( .‬المفاهيم األخالقية وتكنولوجيا المعلومات‪ .‬باالتصاالت‬
‫ب‪ .) 1969( .‬هندسة البرمجيات‪ :‬تقرير عن مؤتمر برعاية لجنة الناتو للعلوم ‪ ،‬جارمش ‪ ،‬ألمانيا‪ .‬من ‪ 7‬إلى ‪ 11‬أكتوبر ‪ 1968‬عمليات‬
‫البرامج ‪ 2‬أهداف الهدف من هذا الفصل هو تعريفك بفكرة البرنامج عملية ‪ -‬مجموعة متماسكة من األنشطة إلنتاج البرمجيات‪ .‬عندما انت‬
‫قرأت هذا الفصل سوف‪ :‬فهم مفاهيم عمليات البرمجيات وعملية البرمجيات‪ W‬عارضات ازياء؛ تم تقديم ثالثة نماذج عملية برمجية عامة و‬
‫متى يمكن استخدامها ؛ تعرف على أنشطة العملية األساسية للبرنامج هندسة المتطلبات ‪ ،‬وتطوير البرمجيات ‪ ،‬واالختبار ‪ ،‬و تطور؛ فهم‬
‫البرامج ‪ Rational Unified Process‬لماذا يجب تنظيم العمليات لمواكبة التغييرات في متطلبات البرمجيات والتصميم ؛ فهم كيف تدمج‬
‫الجيدة ممارسة هندسية إلنشاء عمليات برمجية قابلة للتكيف‪ .‬محتويات ‪ 2.1‬نماذج عملية البرمجيات ‪ 2.2‬عملية األنشطة ‪ 2.3‬التعامل‬
‫مع التغيير ‪ 2.4‬العملية الموحدة العقالنية ‪ 28‬الفصل ‪ 2‬عمليات البرامج عملية البرمجيات هي مجموعة من األنشطة ذات الصلة التي‬
‫ومع ذلك ‪ ،‬تطبيقات ‪ C.‬أو ‪ Java‬تؤدي إلى إنتاج منتج وير‪ .‬قد تتضمن هذه األنشطة تطوير البرامج من البداية بلغة برمجة قياسية مثل‬
‫األعمال ال يتم تطويرها بالضرورة بهذه الطريقة‪ .‬غالبًا ما يتم تطوير برامج األعمال الجديدة يتم تشغيله من خالل توسيع وتعديل األنظمة‬
‫الموجودة أو عن طريق التكوين والدمج البرامج الجاهزة أومكونات النظام‪ .‬هناك العديد من عمليات البرامج المختلفة ولكن يجب أن‬
‫تشتمل جميعها على أربعة أنشطة التي تعتبر أساسية لهندسة البرمجيات‪ . 1 :‬مواصفات البرنامج وظيفة البرنامج والقيود المفروضة عليه‬
‫يجب تحديد العملية‪ . 2 .‬تصميم البرامج وتنفيذها البرنامج يلبي المواصفات يجب أن تنتج‪ .3 .‬التحقق من صحة البرامج يجب التحقق من‬
 ‫صحة البرنامج للتأكد من أنه يقوم بما يفعله العميل يريد‪ . 4 .‬تطور البرامج يجب أن يتطور البرنامج لتلبية احتياجات‪ W‬العمالء المتغيرة‪.‬‬
‫بشكل ما ‪ ،‬تعتبر هذه األنشطة جز ًء ا من جميع عمليات البرامج‪ .‬في الممارسة العملية ‪ ،‬من بالطبع ‪ ،‬فهي أنشطة معقدة في حد ذاتها‬
‫ضا دعم‪ -‬جي مثل التوثيق وإدارة‬ ‫وتشمل أنشطة فرعية مثل التحقق من المتطلبات ‪ ،‬التصميم المعماري ‪ ،‬اختبار الوحدة ‪ ،‬إلخ‪ .‬هناك أي ً‬
‫تكوين البرامج‪ .‬عندما نصف العمليات ونناقشها‪ ، W‬عادة ما نتحدث عن األنشطة في هذه العمليات مثل تحديد نموذج البيانات ‪ ،‬وتصميم‬
‫واجهة المستخدم ‪ ،‬وما إلى ذلك ‪ ،‬و ترتيب هذه األنشطة‪ .‬ومع ذلك ‪ ،‬باإلضافة إلى األنشطة ‪ ،‬أوصاف العملية قد تشمل أيضًا‪.1 :‬‬
‫المنتجات ‪ ،‬وهي نتائج نشاط العملية‪ .‬على سبيل المثال ‪ ،‬يأتي من نشاط التصميم المعماري قد يكون نموذجً ا للبرنامج بنيان‪ .2 .‬األدوار ‪،‬‬
‫التي تعكس مسؤوليات األشخاص المشاركين في العملية‪ .‬أمثلة على األدوار هي مدير المشروع ‪ ،‬مدير التكوين ‪ ،‬المبرمج ‪ ،‬إلخ‪.3 .‬‬
‫الشروط المسبقة والالحقة ‪ ،‬وهي بيانات صحيحة قبل وبعد أ تم سن نشاط العملية أو إنتاج منتج‪ .‬على سبيل المثال ‪ ،‬من قبل يبدأ التصميم‬
‫المعماري ‪ ،‬قد يكون الشرط المسبق هو أن جميع المتطلبات لها تمت الموافقة عليها من قبل العميل ؛ بعد االنتهاء من هذا النشاط ‪ ،‬شرط‬
‫التي تصف العمارة قد تمت مراجعتها‪ .‬عمليات البرمجيات معقدة ‪ ،‬ومثل جميع العمليات الفكرية ‪ UML‬الحق قد يكون أن نماذج‬
‫واإلبداعية ‪ ،‬االعتماد على األشخاص الذين يتخذون القرارات واألحكام‪ .‬ال توجد عملية مثالية وأكثرها المنظمات طورت عمليات تطوير‬
‫البرمجيات‪ W‬الخاصة بها‪ .‬العمليات قد تطورت لالستفادة من قدرات األشخاص في المؤسسة والخصائص المحددة لألنظمة التي يجري‬
‫تطويرها‪ .‬بالنسبة لبعض ‪ 2.1‬نماذج معالجة البرامج ‪ 29‬األنظمة ‪ ،‬مثل األنظمة الحرجة ‪ ،‬مطلوب عملية تطوير منظمة للغاية‪ .‬ألنظمة‬
‫األعمال ‪ ،‬مع المتطلبات المتغيرة بسرعة ‪ ،‬أقل رسمية ومرونة من المرجح أن تكون العملية أكثر فعالية‪ .‬في بعض األحيان ‪ ،‬يتم تصنيف‬
‫عمليات البرامج على أنها إما مدفوعة بالخطة أو رشيقة العمليات‪ .‬العمليات التي تحركها الخطة هي العمليات التي تكون فيها جميع أنشطة‬
‫العملية المخطط لها مسب ًق ا ويتم قياس التقدم مقابل هذه الخطة‪ .‬في العمليات الرشيقة ‪ ،‬التي ناقشتها في الفصل ‪ ، 3‬التخطيط هو تدريجي‬
‫ومن األسهل تغيير عملية لتعكس متطلبات العمالء المتغيرة‪ .‬مثل بوم وتورنر (‪ )2003‬ناقش ‪ ،‬كل نهج مناسب‪ W‬ألنواع مختلفة من‬
‫البرامج‪ .‬بشكل عام ‪ ،‬أنت بحاجة إلى إيجاد توازن بين العمليات المدفوعة بالخطة والعمليات الرشيقة‪ .‬على الرغم من عدم وجود عملية‬
‫برمجية "مثالية" ‪ ،‬إال أن هناك مجااًل لتحسين عملية البرمجيات في العديد من المنظمات‪ .‬قد تشمل العمليات تقنيات عفا عليها الزمن أو قد‬
‫ال تستفيد من أفضل الممارسات‪ W‬في هندسة البرمجيات الصناعية‪ .‬في الواقع ‪ ،‬ال تزال العديد من المؤسسات ال تستفيد من هندسة‬
‫البرمجيات‪ W‬األساليب في تطوير برمجياتهم‪ .‬يمكن تحسين عمليات البرامج عن طريق المعالجةق التوحيد حيث الغواص‪ -‬يتم تقليل حجم‬
‫المسؤولية في عمليات البرامج عبر المؤسسة‪ .‬هذا يؤدي إلى تحسن التواصل وتقليل وقت التدريب ‪ ،‬وتقديم الدعم اآللي للعملية ميناء أكثر‬
‫اقتصادا‪ .‬التوحيد القياسي هو أيضً ا خطوة أولى مهمة في تقديم أساليب وتقنيات هندسة البرمجيات الجديدة وهندسة البرمجيات الجيدة‬
‫يمارس‪ .‬أناقش تحسين عملية البرامج بمزيد من التفصيل في الفصل ‪ 2.1 .26‬نماذج عملية البرمجيات كما أوضحت في الفصل األول ‪،‬‬
‫وبالتالي ‪ spective ،‬فإن نموذج عملية البرنامج عبارة عن تمثيل مبسط لعملية برمجية‪ .‬يمثل كل نموذج عملية عملية من شخص معين‬
‫يوفر معلومات جزئية فقط عن تلك العملية‪ .‬على سبيل المثال‪ ،‬يوضح نموذج نشاط العملية األنشطة وتسلسلها ولكن قد ال يظهر أدوار‬
‫األشخاص المشاركين في هذه األنشطة‪ .‬في هذا القسم ‪ ،‬أقدم عد ًدا نماذج العمليات العامة ج ًدا (تسمى أحيا ًنا "نماذج العمليات") و اعرض‬
‫هذه من منظور معماري‪ .‬وهذا هو ‪ ،‬نرى إطار العملية ولكن ليس تفاصيل أنشطة محددة‪ .‬هذه النماذج العامة ليست أوصا ًفا نهائية‬
‫لعمليات البرامج‪ .‬بدالً من‪ ،‬إنها تجريدات للعملية يمكن استخدامها لشرح األساليب المختلفة لها تطوير البرمجيات‪ .‬يمكنك التفكير فيها على‬
‫أنها أطر عملية قد تكون كذلك موسعة ومتكيفة إلنشاء عمليات هندسة برمجية أكثر تحدي ًدا‪ .‬نماذج العملية التي أغطيها هنا هي‪ .1 :‬نموذج‬
‫الشالل هذا يأخذ أنشطة العملية األساسية‪ W‬المحددة ‪ -‬نشوئها وتطويرها والتحقق من صحتها وتطورها وتمثيلها على أنها منفصلة مراحل‬
‫العملية مثل مواصفات المتطلبات ‪ ،‬تصميم البرمجيات‪ ، W‬التنفيذ‪ 30 -‬الفصل ‪ 2‬عمليات البرامج ‪ .2‬التطوير التدريجي هذا النهج يشتمل‬
‫على أنشطة محددة ‪ -‬نشوئها وتطويرها والتحقق من صحتها‪ .‬تم تطوير النظام كسلسلة من اإلصدارات (الزيادات) ‪ ،‬مع كل إصدار‬
‫يضيف وظائف إلى اإلصدار السابق‪ . 3 .‬هندسة البرمجيات الموجهة إلعادة االستخدام يعتمد هذا النهج على وجود عدد كبير من‬
‫المكونات القابلة إلعادة االستخدام‪ .‬عملية تطوير النظام يركز على دمج هذه المكونات في نظام بدالً من تطويرها منهم من الصفر‪ .‬هذه‬
‫النماذج ليست متعارضة وغالبًا ما تستخدم معً ا ‪ ،‬على وجه الخصوص لتطوير األنظمة الكبيرة‪ .‬بالنسبة لألنظمة الكبيرة ‪ ،‬من المنطقي‬
‫الجمع بين بعضها من أفضل مميزات الشالل ونماذج التنمية المتزايدة‪ .‬أنت بحاجة إلى معلومات حول متطلبات النظام األساسية لتصميم‬
‫حصيلة‪ .‬يمكن تطوير األنظمة الفرعية داخل نظام أكبر ‪ incremen-‬برنامج هندسة وير لدعم هذه المتطلبات‪ .‬ال يمكنك تطوير هذا‬
‫باستخدام مختلف اقتراب‪ .‬يمكن تحديد أجزاء النظام المفهومة جي ًدا وتطويرها افتتحت باستخدام عملية قائمة‪ W‬على الشالل‪ .‬أجزاء من‬
‫النظام يصعب القيام بها التحديد مسب ًقا ‪ ،‬مثل واجهة المستخدم‪ ، W‬يجب دائمًا تطويرها باستخدام النهج التدريجي‪ 2.1.1 .‬نموذج الشالل تم‬
‫تم توضيح هذا النموذج في ‪ (Royce، 1970).‬اشتقاق أول نموذج منشور لعملية تطوير البرمجيات من عمليات هندسة النظم العامة‬
‫الشكل ‪ .2.1‬نظرً ا للتسلسل من مرحلة إلى أخرى ‪ ،‬فإن هذا النموذج معروف باعتباره "نموذج الشالل" أو دورة حياة البرنامج‪ .‬نموذج‬
‫الشالل مثال على عملية مدفوعة بالخطة ‪ -‬من حيث المبدأ ‪ ،‬يجب عليك تخطيط وجدولة كل العملية األنشطة من قبلبدء العمل عليها‪.‬‬
‫متطلبات تعريف نظام و تصميم البرمجيات تطبيق واختبار الوحدة التكامل و اختبار النظام العملية و صيانة الشكل ‪ 2.1‬نموذج الشالل‬
‫‪ 2.1‬نماذج عمليات البرمجيات ‪ 31‬تعكس المراحل الرئيسية لنموذج الشالل بشكل مباشر التطور األساسي أنشطة العمليات‪ .1 :‬تحليل‬
‫وتعريف المتطلبات خدمات‪ W‬النظام والقيود و يتم تحديد األهداف بالتشاور مع مستخدمي النظام‪ .‬ثم يتم تعريفها بالتفصيل وتكون بمثابة‬
‫مواصفات النظام‪ . 2 .‬تصميم النظام والبرمجيات تحدد عملية تصميم األنظمة المتطلبات‪ -‬إشارات إلى أنظمة األجهزة أو البرامج من‬
 ‫خالل إنشاء‪ W‬نظام شامل بنيان‪ .‬يتضمن تصميم البرامج تحديد ووصف األساسيات‪ -‬تل تجريدات نظام البرمجيات وعالقاتها‪ .3 .‬التنفيذ‬
‫كمجموعة من البرامج أو وحدات البرنامج‪ .‬يتضمن اختبار ‪- ized‬واختبار الوحدة خالل هذه المرحلة ‪ ،‬يكون تصميم البرنامج حقيقيًا‬
‫الوحدة التحقق من ذلك كل وحدة تلبي مواصفاتها‪ . 4 .‬التكامل واختبار النظام وحدات أو برامج البرامج الفردية يتم دمجها واختبارها‬
‫كنظام كامل للتأكد من أن البرنامج تم استيفاء المتطلبات‪ .‬بعد االختبار ‪ ،‬يتم تسليم نظام البرنامج إلى الزبون‪ .5 .‬التشغيل والصيانة عادة‬
‫(وإن لم يكن بالضرورة) ‪ ،‬هذا هو أطول مرحلة في دورة الحياة‪ .‬يتم تثبيت النظام واستخدامه عمليًا‪ .‬تتضمن الصيانة تصحيح األخطاء‬
‫التي لم يتم اكتشافها في وقت سابق مراحل دورة الحياة ‪ ،‬وتحسين تنفيذ وحدات النظام و تحسين خدمات النظام عند اكتشاف متطلبات‬
‫جديدة‪ .‬من حيث المبدأ ‪ ،‬تكون نتيجة كل مرحلة هي وثيقة واحدة أو أكثر تمت الموافقة عليها ('تسجيل الخروج')‪ .‬يجب أال تبدأ المرحلة‬
‫التالية حتى تنتهي المرحلة السابقة‪ -‬مشد‪ .‬في الممارسة‪ W‬العملية ‪ ،‬تتداخل هذه المراحل وتغذي المعلومات لبعضها البعض‪ .‬خالل التصميم ‪،‬‬
‫ً‬
‫بسيطا ولكنها‬ ‫يتم تحديد مشاكل المتطلبات‪ .‬أثناء الترميز ‪ ،‬مشاكل التصميم تم العثور عليها وهلم جرا‪ .‬عملية البرنامج ليست نموذجً ا خطيًا‬
‫تتضمن ردود الفعل من مرحلة إلى أخرى‪ .‬قد يتم إنتاج المستندات في كل مرحلة بعد ذلك يجب تعديلها لتعكس التغييرات التي تم‬
‫إجراؤها‪ .‬نظرً ا لتكاليف إنتاج المستندات والموافقة عليها ‪ ،‬يمكن أن تكون التكرارات مكلفة وتنطوي على إعادة صياغة كبيرة‪ .‬لذلك ‪ ،‬بعد‬
‫مع مراحل التطوير الالحقة‪- tinue .‬عدد قليل من التكرارات ‪ ،‬من الطبيعي تجميد أجزاء من المشروع ‪ ،‬مثل المواصفات ‪ ،‬والتحكم في‬
‫يتم ترك المشاكل لحلها الح ًق ا ‪ ،‬تجاهله أو برمجته‪ .‬قد يعني هذا التجميد المبكر للمتطلبات أن النظام لن يفعل ما يريده المستخدم‪ .‬قد يؤدي‬
‫ض ا إلى سوء التنظيم األنظمة حيث يتم التحايل على مشاكل التصميم من خالل حيل التنفيذ‪ .‬خالل مرحلة دورة الحياة النهائية (التشغيل‬ ‫أي ً‬
‫والصيانة) يتم وضع البرنامج قيد االستخدام‪ .‬تم اكتشاف األخطاء والسهو في متطلبات البرنامج األصلي‪ .‬تظهر أخطاء البرنامج والتصميم‬
‫ويتم تحديد الحاجة إلى وظائف جديدة‪ .‬لذلك يجب أن يتطور النظام ليظل ً‬
‫مفيد ا‪ .‬إجراء هذه التغييرات (البرامج الصيانة) إعادة مراحل‬
‫العملية السابقة‪ 32 .‬الفصل ‪ 2‬عمليات البرامج هندسة برمجيات غرف األبحاث من األمثلة على عملية التطوير الرسمية ‪ ،‬التي طورتها‬
‫في ال عملية غرف األبحاث يتم تحديد كل زيادة في البرنامج رسميًا ويتم تحويل هذه ‪ Cleanroom.‬في األصل ‪ ،‬عملية ‪ IBM‬شركة‬
‫المواصفات إلى ملف تطبيق‪ .‬تم إثبات صحة البرنامج باستخدامنهج رسمي‪ .‬ال يوجد اختبار وحدة لـ العيوب في العملية واختبار النظام‬
‫عال ‪ Cleanroom‬يركز على تقييم موثوقية النظام‪ .‬الهدف من عملية‬ ‫هو برامج خالية من العيوب بحيث تتمتع األنظمة المقدمة بمستوى ٍ‬
‫يتوافق نموذج الشالل مع نماذج العمليات ‪. http://www.SoftwareEngineering-9.com/Web/Cleanroom/‬من الموثوقية‬
‫يتم إنتاج التوجيه في كل مرحلة‪ .‬هذا يجعل العملية مرئية حتى يتمكن المدراء من ذلك مراقبة التقدم مقابل ‪ docu-‬الهندسية األخرى و‬
‫خطة التنمية‪ .‬مشكلتها الرئيسية هي الجزء غير المرن تحويل المشروع إلى مراحل متميزة‪ .‬يجب أن يتم االلتزام في مرحلة مبكرة في‬
‫العملية ‪ ،‬مما يجعل من الصعب االستجابة لمتطلبات العمالء المتغيرة‪ .‬من حيث المبدأ ‪ ،‬يجب استخدام نموذج الشالل فقط عندما تكون‬
‫جيدا ومن غير المرجح أن تتغير جذريًا أثناء تطوير النظام‪ .‬ومع ذلك ‪ ،‬يعكس نموذج الشالل نوع العملية المستخدمة‪W‬‬ ‫المتطلبات مفهومة ً‬
‫في الهندسة األخرى المشاريع‪ .‬حيث أنه من األسهل استخدام نموذج إدارة مشترك للمشروع بأكمله ‪ ،‬ال تزال عمليات البرامج القائمة على‬
‫نموذج الشالل مستخدمة بشكل شائع‪ .‬من األشكال المهمة لنموذج الشالل تطوير النظام الرسمي ‪ ،‬حيث يتم إنشاء نموذج رياضي‬
‫كود قابل للقطع‪ .‬بنا ًء ‪ exe-‬لمواصفات النظام‪ .‬هذا النموذج هو إذن مكرر ‪ ،‬باستخدام التحوالت الرياضية التي تحافظ على اتساقها‪ ، W‬إلى‬
‫على افتراض أن التحوالت الرياضية الخاصة بك صحيح ‪ ،‬يمكنك بالتالي تقديم حجة قوية مفادها أن برنامجً ا تم إنشاؤه في هذا الطريقة‬
‫مناسبة )؛ وردزورث ‪ B (Schneider ، 2001 1996 ،‬تتفق مع مواصفاتها‪ .‬عمليات التطوير الرسمية ‪ ،‬مثل تلك القائمة على طريقة‬
‫بشكل خاص لتطوير األنظمة التي لديها متطلبات سالمة أو موثوقية أو أمنية صارمة‪ .‬النهج الرسمي سيم‪ -‬يبرر إنتاج قضية السالمة أو‬
‫األمن‪ .‬هذا يوضح للعمالء‪ W‬أو المنظمين أن النظام يلبي بالفعل متطلبات السالمة‪ W‬أو األمن الخاصة به‪ .‬يتم استخدام العمليات القائمة على‬
‫من أنظمة السالمة الحرجة أو األمن الحرجة‪ .‬تتطلب متخصصين خبرة‪ .‬بالنسبة ‪ opment‬التحوالت الرسمية بشكل عام فقط في التنمية‬
‫لغالبية األنظمة ‪ ،‬ال تقدم هذه العملية تكلفة كبيرة‪ -‬الفوائد على األساليب األخرى لتطوير النظام‪ 2.1.2 .‬التطوير التدريجي يعتمد التطوير‬
‫التدريجي على فكرة تطوير تنفيذ أولي ‪ ، -‬وعرض هذا لتعليق المستخدم وتطويره من خالل عدة إصدارات حتى تم تطوير نظام مالئم‬
‫(الشكل ‪ .)2.2‬المواصفات والتطوير ‪ 2.1‬نماذج عمليات البرمجيات ‪ 33‬تكون أنشطة التحقق متداخلة وليست منفصلة ‪ ،‬مع ردود فعل‬
‫سريعة عبر أنشطة‪ .‬تطوير البرمجيات‪ W‬التدريجي ‪ ،‬وهو جزء أساسي من أجايل أفضل من نهج الشالل لمعظم األعمال والتجارة‬
‫اإللكترونية و األنظمة الشخصية‪ .‬يعكس التطور التدريجي الطريقة التي نحل بها المشكلة يمس‪ .‬نادرً ا ما نتوصل إلى حل كامل للمشكلة‪W‬‬
‫مقد ًم ا ولكننا نتحرك نحو ذلك حل في سلسلة من الخطوات ‪ ،‬التراجع عندما ندرك أننا قمنا بعمل خطأ‪ .‬من خالل تطوير البرنامج بشكل‬
‫تدريجي ‪ ،‬يصبح صنعه أرخص وأسهل التغييرات في البرنامج أثناء تطويره‪ .‬تتضمن كل زيادة أو إصدار من النظام بعض الوظائف التي‬
‫يحتاجها العميل‪ .‬بشكل عام ‪ ،‬تشمل الزيادات المبكرة للنظام الوظيفة األكثر أهمية أو األكثر إلحاحً ا‪ .‬هذا يعني أن ملف عميليمكن تقييم‬
‫النظام في مرحلة مبكرة نسب ًي ا لرؤيته إذا كان يسلم ما هو مطلوب‪ .‬إذا لم يكن األمر كذلك ‪ ،‬فيجب أن تكون الزيادة الحالية فقط تغيير ‪،‬‬
‫وربما ‪ ،‬وظيفة جديدة محددة للزيادات الالحقة‪ .‬التطوير التدريجي له ثالث فوائد مهمة‪ ، W‬مقارنة بالشالل نموذج‪ .1 :‬يتم تقليل تكلفة‬
‫استيعاب متطلبات العمالء‪ W‬المتغيرة‪ .‬ال كمية التحليل والتوثيق التي يجب إعادة بناؤها أقل بكثير مما هي عليه مطلوب مع نموذج الشالل‪.‬‬
‫‪ .2‬من األسهل الحصول على مالحظات‪ W‬العمالء حول أعمال التطوير التي تم إجراؤها منتهي‪ .‬يمكن للعمالء التعليق على العروض‬
‫التوضيحية للبرنامج ومعرفة كيفية القيام بذلك تم تنفيذ الكثير‪ .‬يجد العمالء صعوبة في الحكم على التقدم وثائق تصميم البرمجيات‪.3 .‬‬
 ‫إمكانية التسليم السريع ونشر البرامج المفيدة للعميل‪ -‬بلي ‪ ،‬حتى لو لم يتم تضمين جميع الوظائف‪ .‬العمالء قادرون على االستخدام‬
‫واكتساب القيمة من البرنامج في وقت أبكر مما هو ممكن مع الشالل عملية‪ .‬منافس‪ W‬أنشطة تصديق أخير إصدار تطوير متوسط إصدارات‬
‫تخصيص أولي إصدار الخطوط العريضة وصف الشكل ‪ 2.2‬تزايدي التنمية ‪ 34‬الفصل ‪ 2‬عمليات البرامج التطوير التدريجي في شكل‬
‫ما هو اآلن النهج األكثر شيوعًا لـ تطوير أنظمة التطبيق‪ .‬يمكن أن يكون هذا النهج إما مدفو ًعا بالخطة أو رشي ًقا أو أو ‪ ،‬في العادة ‪ ،‬خليط‬
‫من هذه األساليب‪ .‬في نهج خطة مدفوعة ‪ ،‬النظام يتم تحديد الزيادات مقد ًم ا ؛ إذا تم اعتماد نهج رشيق ‪ ،‬فإن الزيادة المبكرة يتم تحديد‬
‫اإلدخاالت ولكن تطوير الزيادات الالحقة يعتمد على التقدم و أولويات العمالء‪ .‬من منظور إداري ‪ ،‬فإن النهج التدريجي له مشكلتان‪.1 :‬‬
‫العملية غير مرئية‪ .‬يحتاج المديرون إلى مخرجات‪ W‬منتظمة للقياس تقدم‪ .‬إذا تم تطوير األنظمة بسرعة ‪ ،‬فلن يكون إنتاجها فعاالً من حيث‬
‫التكلفة المستندات التي تعكس كل إصدار من إصدارات النظام‪ . 2 .‬تميل بنية النظام إلى التدهور مع إضافة زيادات جديدة‪ .‬ما لم يكن‬
‫الوقت و يتم إنفاق األموال على إعادة بناء البرامج لتحسين البرنامج ‪ ،‬ويميل التغيير المنتظم إلى ذلك يفسد هيكلها‪ .‬يؤدي دمج المزيد من‬
‫التغييرات في البرامج إلى زيادة‪ -‬صعبة ومكلفة‪ .‬تصبح مشاكل التطور التدريجي حادة بشكل خاص بالنسبة للكبار ‪ ،‬أنظمة معقدة وطويلة‬
‫العمر ‪ ،‬حيث تقوم فرق مختلفة بتطوير أجزاء مختلفة من نظام‪ .‬تحتاج األنظمة الكبيرة إلى إطار عمل أو بنية مستقرة والمسؤولية‪ -‬يجب‬
‫تحديد روابط الفرق المختلفة التي تعمل على أجزاء من النظام بوضوح فيما يتعلق بتلك العمارة‪ .‬يجب التخطيط لهذا مسب ًقا بدالً من‬
‫التطوير‪ -‬يتم تشغيله بشكل تدريجي‪ .‬يمكنك تطوير النظام بشكل تدريجي وعرضه على العمالء للتعليق عليه ‪ ،‬دون تسليمها فعليًا ونشرها‬
‫في بيئة العميل‪ .‬يعني التسليم والتوزيع التزايدي استخدام البرنامج في التشغيل الفعلي العمليات اإلقليمية‪ .‬هذا ليس ممك ًنا دائمًا كما يمكن‬
‫التسليم العقلي في القسم ‪ .2.3.2‬مشاكل التطور ‪ incre-‬تجربة البرامج الجديدة تعطل العمليات التجارية العادية‪ .‬أناقش مزايا وعيوب‬
‫التدريجي على الرغم من أن التطوير التدريجي له العديد من المزايا ‪ ،‬إال أنه ال يخلو من المشاكل‪ .‬السبب الرئيسي ل الصعوبة هي حقيقة‬
‫أن المنظمات‪ W‬الكبيرة لديها إجراءات بيروقراطية تطورت بمرور الوقت وهناك قد يكون هناك عدم تطابق بين هذه اإلجراءات وعملية‬
‫د أسباب ‪ -‬على سبيل المثال ‪ ،‬قد تكون ‪ goo‬تكرارية أو رشيقة أكثر رسمية‪ .‬في بعض األحيان تكون هذه اإلجراءات موجودة من أجل‬
‫‪ ، Sarbanes-Oxley‬على سبيل المثال ‪ ،‬في الواليات المتحدة( هناك إجراءات لضمان أن البرنامج ينفذ اللوائح الخارجية بشكل صحيح‬
‫‪.‬قد ال يكون تغيير هذه اإلجراءات ممك ًنا ‪ ،‬لذا قد يكون هناك تعارض في العمليات ال مفر منه ‪).‬اللوائح المحاسبية‬
‫نماذج معالجة البرامج ‪ 2.1.3 35‬هندسة ‪http://www.SoftwareEngineering-9.com/Web/IncrementalDev/2.1‬‬
‫البرمجيات‪ W‬الموجهة إلعادة االستخدام في غالبية مشاريع البرمجيات ‪ ،‬هناك بعض إعادة استخدام البرامج‪ .‬يحدث هذا غالبًا بشكل غير‬
‫رسمي عندما يعرف األشخاص العاملون في المشروع التصاميم أو الكود على غرار ما هو مطلوب‪ .‬يبحثون عنها ‪ ،‬ويعدلونها حسب‬
‫الحاجة ‪ ،‬ويدمجون‪ -‬بوريورهم في نظامهم‪ .‬تتم إعادة االستخدام غير الرسمية هذه بغض النظر عن عملية التطوير مستخدم‪ .‬ومع ذلك ‪،‬‬
‫في القرن الحادي والعشرين ‪ ،‬فإن عمليات تطوير البرامج التي تركز على إعادة استخدام البرامج الموجودة على نطاق واسع‪ .‬النهج‬
‫المعتمدة على إعادة االستخدام على قاعدة كبيرة من مكونات البرامج القابلة إلعادة االستخدام وإطار عمل متكامل لـ تكوين هذه المكونات‪.‬‬
‫التي قد توفر وظائف محددة )أو األنظمة التجارية الجاهزة ‪ (COTS‬في بعض األحيان ‪ ،‬تكون هذه المكونات أنظمة في حقوقهم الخاصة‬
‫مثل معالجة الكلمات‪ W‬أو جداول البيانات‪ .‬يظهر نموذج عملية عام للتنمية القائمة على إعادة االستخدام في الشكل ‪ .2.3‬على الرغم من أن‬
‫مرحلة تحديد المتطلبات األولية ومرحلة التحقق من الصحة بالمقارنة مع عمليات البرامج األخرى ‪ ،‬فإن المراحل الوسيطة في إعادة‬
‫االستخدام‪ -‬عملية موجهة مختلفة‪ .‬هذه المراحل هي‪ .1 :‬تحليل المكونات نظرً ا لمواصفات المتطلبات ‪ ،‬يتم البحث عن مكونات لتنفيذ تلك‬
‫المواصفات‪ .‬عادة ‪ ،‬ال يوجد تطابق تام و توفر المكونات التي يمكن استخدامها بعض الوظائف المطلوبة فقط‪ .2 .‬تعديل المتطلبات خالل‬
‫لتعكس المكونات المتاحة‪- ified .‬هذه المرحلة ‪ ،‬يتم تحليل المتطلبات باستخدام معلومات حول المكونات التي تم اكتشافها‪ .‬ثم يتم تعديلها‬
‫عندما تكون التعديالت مستحيلة ‪ ،‬فإن يمكن إعادة إدخال نشاط تحليل المكون للبحث عن حلول بديلة‪ .3 .‬تصميم النظام مع إعادة‬
‫االستخدام خالل هذه المرحلة ‪ ،‬يكون إطار عمل النظام مصمم أو يتم إعادة استخدام إطار عمل موجود‪ .‬يأخذ المصممون في االعتبار‬
‫المكونات التي يعاد استخدامها وتنظم اإلطار لتلبية ذلك‪ .‬بعض قد يلزم تصميم برامج جديدة في حالة عدم توفر المكونات القابلة إلعادة‬
‫إلنشاء‪ W‬نظام ‪ COTS‬االستخدام‪ .4 .‬برامج التطوير والتكامل التي ال يمكن شراؤها خارجيًا هي تم تطويرها ‪ ،‬وتم دمج المكونات وأنظمة‬
‫جديد‪ .‬قد يكون تكامل النظام ‪ ،‬في هذا النموذج ‪ ،‬جزءًا من التطوير عملية بدالً من نشاط منفصل‪ .‬متطلبات تخصيص عنصر تحليل‬
‫تطوير والتكامل تصميم النظام مع إعادة االستخدام متطلبات تعديل نظام تصديق الشكل ‪ 2.3‬إعادة المنحى هندسة البرمجيات ‪ 36‬الفصل‬
‫‪ 2‬عمليات البرمجيات هناك ثالثة أنواع من مكونات البرامج التي يمكن استخدامها في إعادة االستخدام عملية‪ .1 :‬خدمات الويب التي تم‬
‫تطويرها وف ًقا لمعايير الخدمة والتي هي متاح لالستدعاء عن بعد‪ .2 .‬مجموعات الكائنات التي تم تطويرها كحزمة ليتم دمجها‪ W‬مع أ إطار‬
‫أنظمة البرامج المستقلة التي تم تكوينها لالستخدام في معين بيئة‪ .‬تتمتع هندسة البرمجيات الموجهة ‪ J2EE. 3.‬أو ‪ .NET‬عمل المكون مثل‬
‫إلعادة االستخدام بميزة واضحة تتمثل في تقليل كمية البرامج التي سيتم تطويرها وبالتالي تقليل التكلفة والمخاطر‪ .‬عادة أيضا يؤدي‬
‫إليتسليم أسرع للبرنامج‪ .‬ومع ذلك ‪ ،‬فإن التنازالت المتطلبات هي أمر ال مفر منه وقد يؤدي ذلك إلى نظام ال يلبي االحتياجات الحقيقية‬
‫للمستخدمين‪ .‬عالوة على ذلك ‪ ،‬يتم فقد بعض التحكم في تطور النظام كإصدارات جديدة من المكونات القابلة إلعادة االستخدام ليست تحت‬
‫سيطرة المنظمة التي تستخدمها‪ .‬تعد إعادة استخدام البرامج أمرً ا مه ًما للغاية وقد كرست عدة فصول في الفصل الثالث جزء من الكتاب‬
‫هي مغطى في الفصل ‪ ، 16‬هندسة البرمجيات القائمة ‪ COTS‬لهذا الموضوع‪ .‬القضايا العامة إلعادة استخدام البرامج وإعادة استخدام‬
‫على المكونات في الفصلين ‪ 17‬و ‪ ، 18‬واألنظمة الموجهة نحو الخدمة في الفصل ‪ 2.2 .19‬عملية األنشطة عمليات البرمجيات الحقيقية‬
‫هي تسلسالت متداخلة من التقنية والتعاونية و األنشطة اإلدارية بهدف عام يتمثل في تحديد وتصميم وتنفيذ ‪ ،‬واختبار نظام برمجي‪.‬‬
‫يستخدم مطورو البرامج مجموعة متنوعة من البرامج المختلفة أدوات في عملهم‪ .‬األدوات مفيدة بشكل خاص لدعم تحرير ملفات أنواع‬
‫المستندات وإلدارة الحجم الهائل للمعلومات التفصيلية التي تم إنشاؤها في مشروع برمجيات كبير‪ .‬األنشطة األساسية األربعة للعملية هي‬
‫المواصفات والتطوير والتحقق من الصحة والتطور‪ -‬يتم تنظيم الغسول بشكل مختلف في عمليات التطوير المختلفة‪ .‬في الشالل النموذج ‪،‬‬
‫يتم تنظيمهم في تسلسل ‪ ،‬بينما هم في التطور التدريجي مدخل‪ .‬تعتمد كيفية تنفيذ هذه األنشطة على نوع البرنامج ‪ ،‬الناس ‪ ،‬والهياكل‬
‫التنظيمية المعنية‪ .‬في البرمجة المتطرفة ‪ ،‬على سبيل المثال ‪ ،‬المواصفات مكتوبة على البطاقات‪ .‬االختبارات قابلة للتنفيذ وتم تطويرها‬
‫قبل البرنامج نفسه‪ .‬قد ينطوي التطور على إعادة هيكلة أو إعادة هيكلة جوهرية للنظام‪ 2.2.1 .‬مواصفات البرنامج مواصفات البرامج أو‬
‫هندسة المتطلبات هي عملية الفهم وتحديد الخدمات المطلوبة من النظام وتحديد الضمانات‪ -‬قيود على تشغيل النظام وتطويره‪ .‬هندسة‬
‫تسمى أحيا ًنا هندسة البرمجيات بمساعدة ( أنشطة العملية ‪ 37‬أدوات تطوير البرمجيات أدوات تطوير البرمجيات ‪ a2.2‬المتطلبات‬
‫هي البرامج المستخدمة لدعم أنشطة عملية هندسة البرمجيات‪ .‬وبالتالي فإن هذه األدوات تشمل التصميم )‪ CASE‬الكمبيوتر أو أدوات‬
‫المحررين ‪ ،‬قواميس البيانات ‪ ،‬المجمعين ‪ ،‬أدوات تصحيح األخطاء ‪ ،‬أدوات بناء النظام ‪ ،‬إلخ‪ .‬توفر أدوات البرامج دعمًا للعملية من‬
‫خالل أتمتة بعض أنشطة العملية وتوفير المعلومات حول البرنامج الذي يتم تطويره‪ .‬تتضمن أمثلة األنشطة التي يمكن أتمتتها ما يلي‪:‬‬
‫تطوير نماذج األنظمة الرسومية كجزء من مواصفات المتطلبات أو تصميم البرنامج توليد الكود من هذه النماذج الرسومية إنشاء واجهات‬
‫المستخدم من وصف واجهة رسومية يتم إنشاؤها بشكل تفاعلي بواسطة المستخدم تصحيح أخطاء البرنامج من خالل توفير المعلومات‪W‬‬
‫حول البرنامج المنفذ الترجمة اآللية للبرامج المكتوبة باستخدام إصدار قديم من لغة البرمجة إلى لغة أخرى اإلصدار األخير يمكن دمج‬
‫هذا يوفر مجموعة مشتركة من المرافق التي يمكن لألدوات استخدامها ‪ IDE.‬األدوات في إطار عمل يسمى بيئة التطوير التفاعلية أو‬
‫على نطاق واسع وقد تم تصميمه لدمج العديد من ‪ ECLIPSE IDE‬بحيث يسهل على األدوات االتصال والتشغيل بطريقة متكاملة‪ .‬يستخدم‬
‫مرحلة حرجة بشكل ‪. http://www.SoftwareEngineering-9.com/Web/CASE/‬العناصر المختلفة أنواع أدوات البرمجيات‬
‫مشاكل في تصميم النظام وتنفيذه‪ .‬تهدف عملية هندسة ‪r‬خاص من عملية البرنامج كأخطاء‪ W‬حتمية في هذه المرحلة يؤدي إلى وقت متأخر‬
‫المتطلبات (الشكل ‪ )2.4‬إلى إنتاج اتفاق وثيقة المتطلبات التي تحدد نظا ًم ا يلبي متطلبات أصحاب المصلحة‪ .‬عادة ما يتم تقديم المتطلبات‬
‫على مستويين من التفاصيل‪ .‬المستخدمون النهائيون والعمالء بحاجة إلى بيان عالي المستوى بالمتطلبات ؛ مطورو النظام بحاجة إلى‬
‫المزيد المواصفات التفصيلية للنظام‪ .‬هناك أربعة أنشطة رئيسية في عملية هندسة المتطلبات‪ .1 :‬دراسة الجدوى يتم إجراء تقدير لما إذا‬
‫راض عن استخدام تقنيات البرامج واألجهزة الحالية‪ .‬تعتبر الدراسة ما إذا كان النظام‬
‫ٍ‬ ‫كانت احتياجات المستخدم المحددة قد تكون كذلك‬
‫المقترح سيكون فعاالً من حيث التكلفة من وجهة نظر األعمال وما إذا كان يمكن تطويره ضمن قيود الميزانية الحالية‪ .‬جدوى يجب أن‬
‫تكون الدراسة رخيصة نسبيًا وسريعة‪ .‬يجب أن تكون النتيجة إبالغ القرار حول ما إذا كان يجب المضي قدمًا في تحليل أكثر تفصيالً أم‬
‫ال‪ . 2 .‬استنباط المتطلبات وتحليلها هي عملية اشتقاق النظام المتطلبات من خالل مراقبة األنظمة الحالية ‪ ،‬والمناقشات‪ W‬مع المحتملة‬
‫المستخدمين والموردين ‪ ،‬وتحليل المهام ‪ ،‬وما إلى ذلك‪ .‬قد يشمل هذا تطوير‪ -‬منة واحد أو أكثر من نماذج ونماذج النظام‪ .‬هذه تساعدك‬
‫على الفهم النظام المراد تحديده‪ . 3 .‬مواصفات المتطلبات مواصفات المتطلبات هي نشاط النقل تحديد المعلومات‪ W‬التي تم جمعها‪ W‬أثناء‬
‫نشاط التحليل في مستند ‪ 38‬الفصل ‪ 2‬يعالج البرنامج يحدد مجموعة من المتطلبات‪ .‬قد يتم تضمين نوعين من المتطلبات في هذا وثيقة‪.‬‬
‫متطلبات المستخدم هي بيانات مجردة للنظام تتطلب‪ -‬إقرارات للعميل والمستخدم النهائي للنظام ؛ متطلبات النظام هي أ وصف أكثر‬
‫تفصيال للوظيفة التي سيتم توفيرها‪ . 4 .‬التحقق من صحة المتطلبات يتحقق هذا النشاط من متطلبات الواقعية ‪ ،‬ويتوافق مع‪ -‬الوقت‬
‫واالكتمال‪ .‬أثناء هذه العملية ‪ ،‬أخطاء في وثيقة المتطلبات ال محالة اكتشافها‪ .‬يجب بعد ذلك تعديله لتصحيح هذه المشاكل‪ .‬بالطبع ‪ ،‬ال يتم‬
‫تنفيذ األنشطة في عملية المتطلبات ببساطة في ملف تسلسل صارم‪ .‬يستمر تحليل المتطلبات أثناء التعريف والمواصفات و تظهر‬
‫المتطلبات الجديدة للضوء طوال العملية‪ .‬لذلك ‪ ،‬فإن أنشطة يتم تضمين التحليل والتعريف والمواصفات‪ .‬في األساليب الرشيقة ‪ ،‬مثل‬
‫المتطرفة البرمجة ‪ ،‬يتم تطوير المتطلبات بشكل تدريجي وف ًق ا ألولويات المستخدم و يأتي استحضار المتطلبات من المستخدمين الذين‬
‫يشكلون جزءًا من فريق التطوير‪ 2.2.2 .‬تصميم البرامج وتنفيذها مرحلة تنفيذ تطوير البرمجيات هي عملية تحويل ملف مواصفات‬
‫النظام في نظام قابل للتنفيذ‪ .‬إنها تتضمن دائ ًم ا عمليات تصميم وبرمجة وير ولكن ‪ ،‬إذا كان النهج التدريجي للتنمية المستخدمة‪ ، W‬قد‬
‫تتضمن أيضً ا تنقيح مواصفات البرنامج‪ .‬تصميم البرنامج هو وصف لهيكل البرنامج المراد تنفيذه ‪ ،‬نماذج البيانات والهياكل المستخدمة‪W‬‬
‫من قبل النظام ‪ ،‬والواجهات بين مكونات النظام المؤلفات وأحيا ًن ا الخوارزميات المستخدمة‪ .‬المصممون ال يصلون إلى النهاية التصميم‬
‫على الفور ولكن تطوير التصميم بشكل متكرر‪ .‬يضيفون الرسمية والتفاصيل كما يطورون تصميمهم مع التراجع المستمر لتصحيح‬
‫التصميمات السابقة‪ .‬الشكل ‪ 2.5‬هو نموذج تجريدي لهذه العملية يوضح مدخالت التصميم العملية وأنشطة العملية والوثائق المنتجة‬
‫كمخرجات‪ W‬من هذاعملية‪ .‬جدوى يذاكر متطلبات استخراج و تحليل متطلبات تخصيص متطلبات تصديق جدوى تقرير نظام عارضات‬
‫ازياء المستخدم والنظام متطلبات متطلبات وثيقة الشكل ‪ 2.4‬متطلبات العملية الهندسية ‪ 2.2‬أنشطة العملية ‪ 39‬يشير الرسم البياني إلى أن‬
‫مراحل عملية التصميم متسلسلة‪ .‬في الحقيقة‪ ،‬أنشطة عملية التصميم متداخلة‪ .‬ردود الفعل من مرحلة إلى أخرى و إعادة صياغة التصميم‬
‫الالحقة أمر ال مفر منه في جميع عمليات التصميم‪ .‬معظم واجهات البرامج مع أنظمة البرامج األخرى‪ .‬وتشمل هذه العملية النظام وقواعد‬
‫البيانات والبرمجيات الوسيطة وأنظمة التطبيقات األخرى‪ .‬هذه تشكل منصة وير ‪ ،‬البيئة التي سيتم فيها تنفيذ البرنامج‪ .‬معلومات حول هذه‬
 ‫المنصة هي مدخالت أساسية في عملية التصميم ‪ ،‬حيث يجب على المصممين أن يقرروا كيف األفضل لدمجها‪ W‬مع بيئة البرنامج‪.‬‬
‫مواصفات المتطلبات هي أ وصف الوظيفة التي يجب أن يوفرها البرنامج وأدائه و متطلبات االعتمادية‪ .‬إذا كان النظام سيعالج البيانات‬
‫الموجودة ‪ ،‬ثم الوصف من تلك البيانات قد يتم تضمينها في مواصفات النظام األساسي ؛ خالف ذلك ‪ ،‬وصف البيانات يجب أن يكون‬
‫مدخالً في عملية التصميم بحيث يتم تحديد تنظيم بيانات النظام‪ .‬تختلف األنشطة في عملية التصميم ‪ ،‬اعتما ًدا على نوع النظام متطور‪.‬‬
‫على سبيل المثال ‪ ،‬تتطلب أنظمة الوقت الفعلي تصميم توقيت ولكنها قد ال تتطلب ذلك تضمين قاعدة بيانات حتى ال يكون هناك تصميم‬
‫لقاعدة البيانات‪ .‬يوضح الشكل ‪ 2.5‬أربعة األنشطة التي قد تكون جزءًا من عملية تصميم أنظمة المعلومات‪ .1 :‬التصميم المعماري ‪،‬‬
‫حيث تحدد الهيكل العام للنظام ‪ ،‬فإن المكونات الرئيسية (تسمى أحيا ًن ا األنظمة الفرعية أو الوحدات النمطية) ‪ ،‬وعالقتها‪ -‬العالقات‪ W‬وكيف‬
‫يتم توزيعها‪ .2 .‬تصميم الواجهة ‪ ،‬حيث تحدد الواجهات‪ W‬بين مكونات النظام‪ .‬يجب أن تكون مواصفات الواجهة ال لبس فيها‪ .‬مع واجهة‬
‫دقيقة ‪ ،‬أ يمكن استخدام المكون دون الحاجة إلى معرفة المكونات األخرى له مُن ّفذ‪ .‬بمجرد الموافقة على مواصفات الواجهة ‪ ،‬يمكن أن‬
‫تكون المكونات تم تصميمها وتطويرها بشكل متزامن‪ .‬نظام بنيان قاعدة البيانات تخصيص واجهه المستخدم تخصيص عنصر تخصيص‬
‫واجهه المستخدم تصميم عنصر تصميم متطلبات تخصيص المعماري‪ W‬تصميم منصة معلومة بيانات وصف مدخالت التصميم أنشطة‬
‫التصميم مخرجات التصميم تصميم قاعدة البيانات الشكل ‪ 2.5‬عام نموذج التصميم عملية ‪ 40‬الفصل ‪ 2‬عمليات البرامج ‪ .3‬تصميم‬
‫ً‬
‫بسيطا للوظيفة المتوقعة تم التنفيذ ‪ ،‬مع‬ ‫المكونات ‪ ،‬حيث تأخذ كل مكون من مكونات النظام وتصمم كيف سيكون العمل‪ .‬قد يكون هذا بيا ًنا‬
‫ترك التصميم المحدد للمبرمج‪ .‬بدال من ذلك ‪ ،‬قد يكون تكون قائمة بالتغييرات التي يجب إجراؤها على مكون قابل إلعادة االستخدام أو‬
‫نموذج تصميم مفصل‪ .‬يمكن استخدام نموذج التصميم إلنشاء تنفيذ تلقائيًا‪ .4 .‬تصميم قاعدة البيانات ‪ ،‬حيث تقوم بتصميم هياكل بيانات‬
‫النظام وكيف يتم ذلك ليتم تمثيلها في قاعدة بيانات‪ .‬مرة أخرى ‪ ،‬يعتمد العمل هنا على ما إذا كان ملف يجب إعادة استخدام قاعدة البيانات‬
‫ضا في الشكل ‪ .2.5‬تفصيل‬ ‫الحالية أو إنشاء قاعدة بيانات جديدة‪ .‬تؤدي هذه األنشطة إلى مجموعة من مخرجات‪ W‬التصميم ‪ ،‬والتي تظهر أي ً‬
‫وتمثيل هذه تختلف اختالفا كبيرا‪ .‬لألنظمة الحرجة ‪ ،‬مفصلة يجب أن تكون مستندات التصميم التي تحدد األوصاف الدقيقة والدقيقة للنظام‬
‫أنتجت‪ .‬إذا تم استخدام نهج يحركه النموذج ‪ ،‬فقد تكون هذه المخرجات في الغالب عبارة عن رسوم بيانية‪ .‬أين أجيليتم استخدام طرق‬
‫التطوير ‪ ،‬وقد ال تكون مخرجات عملية التصميم تكون وثائق مواصفات منفصلة ولكن يمكن تمثيلها في كود البرنامج‪ .‬تم تطوير األساليب‬
‫‪ (Budgen ، 2003).‬والتصميم الموجه للكائنات ‪ UML‬الهيكلية للتصميم في السبعينيات والثمانينيات وكانت كذلك مقدمة لتصميم‬
‫يعتمدون على إنتاج نماذج رسومية للنظام ‪ ،‬وفي كثير من الحاالت ‪ ،‬يولد تلقائيًا‪ -‬جي كود من هذه النماذج‪ .‬تطوير يحركها نموذج‬
‫حيث يتم إنشاء نماذج البرنامج بشكل مختلف مستويات التجريد ‪ ،‬هو تطور ‪ (Schmidt ، 2006) ،‬أو يحركها نموذج الهندسة )‪(MDD‬‬
‫هناك أكبر التركيز على النماذج المعمارية مع الفصل بين التنفيذ المجرد‪ -‬النماذج المستقلة والنماذج ‪ MDD ،‬للطرق المنظمة‪ .‬في‬
‫الخاصة بالتنفيذ‪ .‬تم تطوير النماذج بتفاصيل كافية بحيث يمكن إنشاء النظام القابل للتنفيذ منها‪ .‬أناقش هذا النهج للتنمية في الفصل ‪.5‬‬
‫تطوير برنامج لتنفيذ النظام يتبع بشكل طبيعي من عمليات تصميم النظام‪ .‬على الرغم من أن بعض فئات البرامج ‪ ،‬مثل السالمة الحرجة‬
‫عادة ما يتم تصميمها بالتفصيل قبل أن يبدأ أي تنفيذ ‪ ،‬فهو أكثر من ذلك من الشائع أن تكون المراحل الالحقة من التصميم وتطوير‬
‫رمزا لتعريف الواجهات‪W‬‬‫ً‬ ‫البرنامج متداخلة‪ .‬يمكن استخدام أدوات تطوير البرامج إلنشاء برنامج هيكلي من ملف تصميم‪ .‬يتضمن ذلك‬
‫وتنفيذها ‪ ،‬وفي كثير من الحاالت ‪ ،‬ملف يحتاج المطور فقط إلى إضافة تفاصيل تشغيل كل مكون من مكونات البرنامج‪ .‬البرمجة نشاط‬
‫شخصي وال توجد عملية عامة عادة يتبع‪ .‬يبدأ بعض المبرمجين بمكونات يفهمونها ويطورونها هذه ‪ ،‬ثم ننتقل إلى المكونات األقل فهماً‪.‬‬
‫يأخذ آخرون العكس طرق منظمة األساليب الهيكلية هي نهج لتصميم البرامج حيث يجب تطوير النماذج الرسومية يتم تحديد جزء من‬
‫ض ا عملية لتطوير النماذج والقواعد التي تنطبق على كل نوع نموذج‪ .‬الطرق المهيكلة تؤدي إلى توثيق‬ ‫عملية التصميم‪ .‬قد تحدد الطريقة أي ً‬
‫‪.‬موحد للنظام وهي مفيد بشكل خاص في توفير إطار عمل تطوير لمطوري البرامج األقل خبرة واألقل خبرة‬
‫أنشطة العملية ‪ 41‬نهج ‪ ،‬وترك المكونات ‪http://www.SoftwareEngineering-9.com/Web/Structured-methods/2.2‬‬
‫المألوفة حتى آخر ألنهم يعرفون كيفية تطوير هم‪ .‬يحب بعض المطورين تحديد البيانات في وقت مبكر من العملية ‪ ،‬ثم يستخدمونها للقيادة‬
‫تطوير البرنامج يترك اآلخرون البيانات غير محددة ألطول فترة ممكنة‪ .‬عادة ‪ ،‬يقوم المبرمجون بإجراء بعض االختبارات على الكود‬
‫الذي طوروه‪ .‬هذا غال ًب ا ما يكشف عن عيوب في البرنامج يجب إزالتها من البرنامج‪ .‬هذا يسمي التصحيح‪ .‬اختبار العيوب وتصحيح‬
‫األخطاء هما عمليتان مختلفتان‪ .‬االختبار يؤسس وجود عيوب‪ .‬التصحيح معني بتحديد موقع هذه العيوب وتصحيحها‪ .‬عندما تقوم‬
‫بتصحيح األخطاء ‪ ،‬يجب عليك إنشاء فرضيات حول ما يمكن مالحظته سلوك البرنامج ثم اختبار هذه الفرضيات على أمل العثور على‬
‫الخطأ تسبب في حدوث خلل في اإلخراج‪ .‬قد يتضمن اختبار الفرضيات تتبع البرنامج رمز يدويًا‪ .‬قد يتطلب األمر حاالت اختبار جديدة‬
‫لتحديد موقع المشكلة‪ .‬تفاعلي أدوات التصحيح ‪ ،‬والتي تظهر القيم الوسيطة لمتغيرات البرنامج والتتبع من العبارات المنفذة ‪ ،‬يمكن‬
‫)‪ (V&V‬استخدامها لدعم عملية التصحيح‪ 2.2.3 .‬التحقق من البرامج التحقق من صحة البرامج ‪ ،‬أو بشكل عام ‪ ،‬التحقق والتحقق‬
‫‪ exe-‬منويإلثبات أن النظام يتوافق مع مواصفاته وأنه يلبي في نفس الوقت توقعات‪ W‬عمالء النظام‪ .‬اختبار البرنامج ‪ ،‬حيث يكون النظام‬
‫ضا عمليات الفحص ‪ ،‬مثل‬ ‫المقطوعة باستخدام بيانات االختبار المحاكاة‪ ، W‬هي تقنية التحقق الرئيسية‪ .‬التحقق من الصحة تتضمن أي ً‬
‫عمليات التفتيش والمراجعات ‪ ،‬في كل مرحلة من مراحل عملية البرمجيات من تعريف متطلبات المستخدم إلى تطوير البرنامج‪ .‬بسبب‬
‫هيمنة االختبار ‪ ،‬يتم تكبد غالبية تكاليف التحقق من الصحة أثناء وبعد التنفيذ‪ .‬باستثناء البرامج الصغيرة ‪ ،‬ال ينبغي اختبار األنظمة على‬
‫أنها أحادية ومتجانسة وحدة‪ .‬يوضح الشكل ‪ 2.6‬عملية اختبار من ثالث مراحل تكون فيها مكونات النظام تم اختباره ثم يتم اختبار النظام‬
 ‫المتكامل ‪ ،‬وأخيراً ‪ ،‬يتم اختبار النظام باستخدام بيانات العميل‪ .‬من الناحية المثالية ‪ ،‬يتم اكتشاف عيوب المكونات في وقت مبكر من‬
‫العملية ‪ ،‬و تم العثور على مشاكل الواجهة عند تكامل النظام‪ .‬ومع ذلك ‪ ،‬كما هي عيوب اكتشف ‪ ،‬يجب تصحيح البرنامج وقد يتطلب ذلك‬
‫مراحل أخرى في يجب تكرار عملية االختبار‪ .‬قد تظهر أخطاء في مكونات البرنامج ‪ ،‬على سبيل المثال ‪ ،‬أثناء اختبار النظام‪ .‬وبالتالي‬
‫فإن العملية تكرارية مع المعلومات يتم إعادتها من المراحل الالحقة إلى األجزاء السابقة من العملية‪ .‬مراحل عملية االختبار هي‪.1 :‬‬
‫اختبار التطوير يتم اختبار المكونات المكونة للنظام بواسطة الناس الذين يطورون النظام‪ .‬يتم اختبار كل مكون بشكل مستقل ‪ ،‬بدون‬
‫مكونات النظام األخرى‪ .‬قد تكون المكونات كيانات بسيطة مثل الوظائف اختبار النظام عنصر اختبارات قبول اختبارات الشكل ‪2.6‬‬
‫المراحل من االختبار ‪ 42‬الفصل ‪ 2‬عمليات البرامج أو فئات الكائنات ‪ ،‬أو قد تكون مجموعات متماسكة‪ W‬من هذه الكيانات‪ .‬اختبار تلقائي‪-‬‬
‫التي يمكنها إعادة تشغيل المكون اختبارات عند إنشاء إصدارات جديدة ‪ JUnit (Massol and Husted ، 2003) ،‬أدوات نشوئها ‪ ،‬مثل‬
‫من المكون ‪ ،‬يتم استخدامها بشكل شائع‪ . 2 .‬تم دمج مكونات نظام اختبار النظام إلنشاء نظام كامل‪ .‬هذه العملية معنية بإيجاد األخطاء التي‬
‫تنتج عن غير متوقعة التفاعالت بين المكونات ومشاكل واجهة المكونات‪ .‬بل هو أيضا يهتم بإثبات أن النظام يلبي وظيفته وغير الوظيفية‬
‫المتطلبات ‪ ،‬واختبار خصائص النظام الناشئة‪ .‬لألنظمة الكبيرة ‪ ،‬قد تكون هذه عملية متعددة المراحل حيث يتم دمج المكونات لتشكيل‬
‫فرعي األنظمة التي تم اختبارها بشكل فردي قبل هذه األنظمة الفرعية هي نفسها متكامل لتشكيل النظام النهائي‪ .3 .‬اختبار القبول هذه‬
‫هي المرحلة األخيرة في عملية االختبار قبل النظام مقبول لالستخدام التشغيلي‪ .‬يتم اختبار النظام بالبيانات المقدمة من عميل النظام بدالً‬
‫من بيانات االختبار المحاكاة‪ .‬قد يتم اختبار القبول تكشف عن األخطاء والسهو في تعريف متطلبات النظام ‪ ،‬ألن البيانات الحقيقية تمارس‬
‫ضا عن مشكالت‪ W‬المتطلبات حيث تفعل مرافق النظام ال تفي ح ًقا‬ ‫النظام بطرق مختلفة عن بيانات االختبار‪ .‬قبول قد يكشف االختبار أي ً‬
‫باحتياجات‪ W‬المستخدم أو أن أداء النظام غير مقبول‪ .‬عادة ‪ ،‬تكون عمليات تطوير واختبار المكونات متداخلة‪ .‬يقوم المبرمجون بتكوين‬
‫بيانات االختبار الخاصة بهم واختبار الكود بشكل تدريجي كما هو متطور‪ .‬هذا نهج معقول اقتصاديًا ‪ ،‬كما يعرف المبرمج وبالتالي فهو‬
‫أفضل شخص لتوليد حاالت االختبار‪ .‬إذا تم استخدام نهج تدريجي للتنمية ‪ ،‬فيجب أن تكون كل زيادة تم اختباره أثناء تطويره ‪ ،‬مع هذه‬
‫االختبارات بنا ًء على متطلبات تلك الزيادة‪ -‬منة‪ .‬في أقصى الحدودالبرمجة اإللكترونية ‪ ،‬يتم تطوير االختبارات جنبًا إلى جنب مع‬
‫المتطلبات قبل أن يبدأ التطوير‪ .‬هذا يساعد المختبرين والمطورين على فهم المتطلبات ويضمن عدم وجود تأخيرات عند إنشاء حاالت‬
‫االختبار‪ .‬عند استخدام عملية برمجية مدفوعة بالخطة (على سبيل المثال ‪ ،‬لتطوير األنظمة الهامة‪ -‬منة) ‪ ،‬يتم إجراء االختبار من خالل‬
‫مجموعة من خطط االختبار‪ .‬يعمل فريق مستقل من المختبرين من خطط االختبار المعدة مسب ًقا ‪ ،‬والتي تم تطويرها من النظام‬
‫المواصفات والتصميم‪ .‬يوضح الشكل ‪ 2.7‬كيف أن خطط االختبار هي الرابط بينها أنشطة االختبار والتطوير‪ .‬يسمى هذا أحيا ًنا النموذج‬
‫يسمى اختبار القبول أحيا ًنا "اختبار ألفا"‪ .‬األنظمة المخصصة هي تم تطويره لعميل ‪ V).‬اقلبها على جانبها لترى( الخامس للتطوير‪ -‬منة‬
‫واحد‪ .‬تستمر عملية اختبار ألفا حتى النظام يوافق المطور والعميل على أن النظام المقدم هو تنفيذ مقبول‪ -‬توصيف المتطلبات‪ .‬عندما يتم‬
‫تسويق نظام ما كمنتج برمجي ‪ ،‬تسمى عملية االختبار غالبًا ما يستخدم "االختبار التجريبي"‪ .‬يتضمن اختبار بيتا تسليم نظام لعدد من‬
‫العمالء المحتملين الذين يوافقون على استخدام هذا النظام‪ .‬يقومون بإبالغ النظام عن المشاكل‪ -‬مطوري تيم‪ .‬هذا يعرض المنتج لالستخدام‬
‫الحقيقي ويكشف األخطاء التي قد ال تكون كذلك تم توقعه من قبل بناة النظام‪ .‬بعد هذه المالحظات ‪ ،‬يتم تعديل النظام‪ -‬إذا تم إصداره‬
‫وإصداره إما لمزيد من االختبار التجريبي أو للبيع العام ‪ 2.3.‬التعامل مع التغيير ‪ 2.2.4 43‬تطور البرمجيات تعد مرونة أنظمة البرامج‬
‫أحد األسباب الرئيسية وراء المزيد والمزيد يتم دمج البرامج في أنظمة كبيرة ومعقدة‪ .‬بمجرد اتخاذ قرار مصنوعة لتصنيع األجهزة ‪ ،‬فمن‬
‫المكلف للغاية إجراء تغييرات على األجهزة تصميم‪ .‬ومع ذلك ‪ ،‬يمكن إجراء تغييرات على البرنامج في أي وقت أثناء أو بعد تطوير‬
‫النظام‪ .‬حتى التغييرات الواسعة النطاق ال تزال أرخص بكثير من المتوافقة‪ -‬تغييرات دينغ على أجهزة النظام‪ .‬تاريخيًا ‪ ،‬كان هناك دائمًا‬
‫وعملية تطور البرمجيات (صيانة البرمجيات)‪ .‬يعتقد الناس تطوير البرمجيات كنشاط إبداعي ‪ opment‬انقسام بين عملية تطوير البرامج‬
‫يتم فيه تطوير نظام برمجيات‪ -‬تم تشغيله من المفهوم األولي إلى نظام العمل‪ .‬ومع ذلك ‪ ،‬هم في بعض األحيان فكر في صيانة البرامج‬
‫على أنها مملة وغير مهمة‪ .‬على الرغم من أن تكاليف الرئيسي‪ -‬غالبًا ما تكون الصيانة عدة أضعاف تكاليف التطوير األولية وعمليات‬
‫الصيانة تعتبر أحيا ًنا أقل تحد ًي ا من تطوير البرامج األصلية‪ .‬هذا التمييز بين التطوير والصيانة غير ذي صلة على نحو متزايد‪ .‬ال تكاد‬
‫تكون أي أنظمة برمجية أنظمة جديدة تما ًم ا وهي تحقق الكثير من المنطقي أن نرى التطوير والصيانة كسلسلة متصلة‪ .‬بدال من اثنين‬
‫منفصل العمليات ‪ ،‬فمن الواقعي التفكير في هندسة البرمجيات على أنها تطورية العملية (الشكل ‪ )2.8‬حيث يتم تغيير البرنامج باستمرار‬
‫على مدار حياته في االستجابة للمتطلبات المتغيرة واحتياجات العمالء‪ 3 .2 .‬التعامل مع التغيير التغيير أمر ال مفر منه في جميع مشاريع‬
‫البرامج الكبيرة‪ .‬تتغير متطلبات النظام حيث أن األعمال التي تقوم بشراء النظام تستجيب للضغوط الخارجية واإلدارة تتغير األولويات‪.‬‬
‫مع توفر تقنيات جديدة ‪ ،‬تصميم جديد وتنفيذ‪ -‬تظهر االحتماالت‪ .‬لذلك مهما كان نموذج عملية البرنامج المستخدم ‪ ،‬فهو كذلك من‬
‫الضروري أنه يمكن أن يستوعب التغييرات التي تطرأ على البرنامجمتطور‪ .‬متطلبات تخصيص نظام تخصيص قبول امتحان نظام‬
‫إختبار اإلدماج النظام الفرعي إختبار اإلدماج نظام تصميم مفصلة تصميم خدمة وحدة و كود الوحدة واالختبار قبول خطة اختبار نظام‬
‫اندماج خطة اختبار النظام الفرعي اندماج خطة اختبار الشكل ‪ 2.7‬مراحل االختبار في خطة مدفوعة عملية البرمجيات ‪ 44‬الفصل ‪2‬‬
‫عمليات البرامج يضيف التغيير إلى تكاليف تطوير البرامج ألنه عادة ما يعني ذلك يجب إعادة العمل الذي تم االنتهاء منه‪ .‬هذا يسمى‬
‫إعادة العمل‪ .‬على سبيل المثال ‪ ،‬إذا تم تحليل العالقات‪ W‬بين المتطلبات في النظام وجديدها ثم يتم تحديد المتطلبات ‪ ،‬يجب تحديد بعض أو‬
‫كل تحليل المتطلبات معاد‪ .‬قد يكون من الضروري بعد ذلك إعادة تصميم النظام لتقديم المتطلبات الجديدة‪ -‬وتغيير أي برامج تم تطويرها‬
 ‫وإعادة اختبار النظام‪ .‬هناك طريقتان متصلتان يمكن استخدامهما‪ W‬لتقليل تكاليف إعادة العمل‪ .1 :‬تجنب التغيير ‪ ،‬حيث تتضمن عملية‬
‫التغييرات المحتملة قبل أن يتطلب األمر إجراء إعادة صياغة مهمة‪ .‬على سبيل المثال ‪ ،‬يمكن ‪- ipate‬البرامج أنشطة يمكن أن تمنع‬
‫إلظهار بعض الميزات الرئيسية للنظام عمالء‪ .‬يمكنهم تجربة النموذج األولي وتحسين متطلباتهم‪ -‬مالحظات‪ W‬قبل ‪ totype‬تطوير نظام‬
‫االلتزام بتكاليف إنتاج البرامج العالية‪ . 2 .‬تغيير التسامح ‪ ،‬حيث تم تصميم العملية بحيث يمكن استيعاب التغييرات‪ -‬تم تعديلها بتكلفة‬
‫تنمية المواهب‪ .‬قد يتم تنفيذ التغييرات المقترحة في الزيادات التي ‪ incremen-‬منخفضة نسبيًا‪ .‬هذا عادة ما ينطوي على شكل من أشكال‬
‫لم يتم تطويرها بعد‪ .‬إذا كان هذا مستحياًل ‪ ،‬فعندئ ٍذ فقط زيادة واحدة (جزء صغير من النظام) قد يلزم تعديله لدمج التغيير‪ .‬أناقش في هذا‬
‫القسم طريقتين للتعامل مع التغيير وتغيير النظام متطلبات‪ .‬هؤالء هم‪ . 1 :‬نماذج النظام ‪ ،‬حيث يتم تطوير إصدار من النظام أو جزء منه‬
‫بسرعة للتحقق من متطلبات العميل وجدوى بعض التصميم قرارات‪ .‬هذا يدعم تجنب التغيير ألنه يسمح للمستخدمين بتجربة ملف النظام‬
‫قبل التسليم وحتى صقل متطلباتهم‪ .‬عدد يتطلب‪ -‬ولذلك فمن المرجح أن يتم تخفيض مقترحات التغيير المقدمة بعد التسليم‪ .2 .‬التسليم‬
‫التزايدي ‪ ،‬حيث يتم تسليم زيادات النظام إلى العميل من أجل التعليق والتجريب‪ .‬هذا يدعم كالً من تجنب التغيير و تغيير التسامح‪ .‬يتجنب‬
‫االلتزام المبكر بمتطلبات النظام بأكمله ويسمح بإدراج التغييرات في الزيادات الالحقة عند منخفضة التكلفة‪ .‬إن فكرة إعادة البناء ‪ ،‬أي‬
‫تحسين هيكل وتنظيم أ البرنامج ‪ ،‬هو أيضً ا آلية مهمة‪ W‬تدعم تحمل التغيير‪ .‬أناقش هذا في الفصل ‪ ، 3‬الذي يغطي األساليب الرشيقة‪ .‬تقييم‬
‫الموجودة األنظمة تحديد النظام متطلبات اقتراح النظام التغييرات يُع ِّدل األنظمة جديد نظام موجود األنظمة الشكل ‪ 2.8‬النظام التطور‬
‫‪ 2.3‬التكيف مع التغيير ‪ 2.3.1 45‬النماذج األولية النموذج األولي هو نسخة أولية من نظام برمجي يُستخدم للتوضيح المفاهيم ‪ ،‬جرب‬
‫خيارات التصميم ‪ ،‬واكتشف المزيد حول المشكلة وإمكانياتها‪ -‬حلول بلي‪ .‬التطوير السريع والمتكرر للنموذج األولي أمر ضروري حتى‬
‫يتم دفع التكاليف يتم التحكم فيها ويمكن ألصحاب المصلحة في النظام تجربة النموذج األولي في وقت مبكر عملية البرنامج‪ .‬يمكن‬
‫استخدام نموذج أولي للبرنامج في عملية تطوير البرامج للمساعدة توقع التغييرات التي قد تكون مطلوبة‪ .1 :‬في عملية هندسة المتطلبات ‪،‬‬
‫يمكن أن يساعد النموذج األولي في الذكاءح اليكيتا‪ -‬نشوئها والتحقق من صحة متطلبات النظام‪ .2 .‬في عملية تصميم النظام ‪ ،‬يمكن‬
‫استخدام نموذج أولي الستكشاف برامج معينة حلول وير ودعم تصميم واجهة المستخدم‪ .‬تسمح نماذج النظام للمستخدمين بمعرفة مدى‬
‫جودة دعم النظام لعملهم‪ .‬قد يحصلون على أفكار جديدة للمتطلبات ‪ ،‬ويجدون مجاالت القوة والضعف فيها البرنامج‪ .‬يمكنهم بعد ذلك‬
‫اقتراح متطلبات نظام جديدة‪ .‬عالوة على ذلك ‪ ،‬مثل تم تطوير النموذج األولي ‪ ،‬فإنه قد يكشف عن األخطاء والسهو في المتطلبات التي‬
‫تم االقتراح‪ .‬قد تبدو الوظيفة الموصوفة في المواصفات مفيدة وجيدة مُعرف‪ .‬ومع ذلك ‪ ،‬عندما يتم دمج هذه الوظيفة مع وظائف أخرى ‪،‬‬
‫غال ًب ا ما يقوم المستخدمون بذلك وجدوا أن وجهة نظرهم األولية كانت غير صحيحة أو غير كاملة‪ .‬قد تكون مواصفات النظام ثم يتم‬
‫تعديلها لتعكس فهمهم المتغير للمتطلبات‪ .‬يمكن استخدام نموذج أولي للنظام أثناء تصميم النظام لتنفيذه تجارب التصميم للتحقق من جدوى‬
‫التصميم المقترح‪ .‬على سبيل المثال ‪ ،‬أ قد يتم تصميم نماذج أولية واختبارها للتحقق من أنها تدعم البيانات الفعالة الوصول إلى استعالمات‬
‫ضا جزءًا أساسيًا من عملية تصميم واجهة المستخدم‪ .‬بسبب الطبيعة الديناميكية لواجهات‪W‬‬ ‫المستخدم األكثر شيو ًعا‪ .‬تعد النماذج األولية أي ً‬
‫المستخدم ‪ ،‬األوصاف والرسوم البيانية ليست جيدة بما يكفي للتعبير عن واجهة المستخدم متطلبات‪ .‬لذلك ‪ ،‬فإن النماذج األولية السريعة‬
‫بمشاركة المستخدم النهائي هي الوحيدة طريقة معقولة لتطوير واجهات المستخدم الرسومية ألنظمة البرمجيات‪ .‬يظهر نموذج عملية‬
‫لتطوير النموذج األولي في الشكل ‪ . 2.9‬الهدف‪ -‬يجب توضيح مجموعات النماذج األولية من بداية العملية‪ .‬قد تكون هذه يتم تطوير نظام‬
‫لعمل نموذج أولي لواجهة المستخدم‪ ، W‬لتطوير نظام للتحقق من صحته متطلبات النظام الوظيفية ‪ ،‬أو لتطوير نظام إلثبات الجدوى يٌرسّخ‬
‫النموذج المبدئي أهداف يُعرِّ ف النموذج المبدئي وظائف يطور النموذج المبدئي يقيم النموذج المبدئي النماذج يخطط الخطوط العريضة‬
‫تعريف تنفيذ النموذج المبدئي تقييم تقرير الشكل ‪ 2.9‬العملية من النموذج األولي تطوير ‪ 46‬الفصل ‪ 2‬عمليات البرمجيات التطبيق‬
‫للمديرين‪ .‬نفس النموذج األولي ال يمكن أن يلبي جميع األهداف‪ .‬إذا كان األهداف التي ُتركت دون ذكر ‪ ،‬قد تسيء اإلدارة أو المستخدمون‬
‫النهائيون فهم الوظيفة‪ -‬من النموذج األولي‪ .‬وبالتالي ‪ ،‬قد ال يحصلون على الفوائد التي كانوا يتوقعونها من تطوير النموذج األولي‪.‬‬
‫المرحلة التالية من العملية هي تحديد ما يجب القيام به ‪ ،‬وربما أكثر من ذلك واألهم من ذلك ‪ ،‬ما يجب تركه خارج نظام النموذج األولي‪.‬‬
‫لتقليل تكاليف النماذج األولية وتسريع جدول التسليم ‪ ،‬فقد تترك بعض الوظائف خارج نطاق النموذج المبدئي‪ .‬قد تقرر تخفيف المتطلبات‬
‫غير الوظيفية مثل االستجابة استخدام الوقت والذاكرة‪ .‬قد يتم تجاهل معالجة وإدارة األخطاء إال إذا الهدف من النموذج األولي هو إنشاء‪W‬‬
‫واجهة مستخدم‪ .‬معايير الموثوقية وقد تنخفض جودة البرنامج‪ .‬المرحلة األخيرة من العملية هي تقييم النموذج األولي‪ .‬يجب توفير الحكم‬
‫خالل هذه المرحلة لتدريب المستخدم ويجب استخدام أهداف النموذج األولي استنبط خطة للتقييم‪ .‬يحتاج المستخدمون إلى وقت لالرتياح‬
‫ثم يكتشفون أخطاء المتطلبات ‪- mally ،‬واالستقرار في نمط االستخدام العادي‪ .‬بمجرد استخدامهم للنظام ال ‪- tem‬مع نظام جديد‬
‫واإلغفاالت‪ .‬مشكلة عامة في النماذج األولية هي أن النموذج األولي قد ال يكون بالضرورة كذلك تستخدم بنفس طريقة النظام النهائي‪ .‬قد‬
‫مختبر النموذج األولي من النوع‬
‫ِ‬ ‫للنظامالمستخدمين‪ .‬قد يكون وقت التدريب أثناء تقييم النموذج األولي غير كافٍ ‪ -‬سيئ‪ .‬إذا ‪- ical‬ال يكون‬
‫كان النموذج األولي بطيًئ ا ‪ ،‬فقد يقوم المقيمون بتعديل طريقة عملهم و تجنب ميزات النظام التي لها أوقات استجابة بطيئة‪ .‬عندما يتم‬
‫ثالث ا في النظام النهائي ‪ ،‬قد يستخدمونه بطريقة مختلفة‪ .‬يتعرض المطورون أحيا ًنا للضغط من قبل المديرين لتقديم‬ ‫تزويده بالرهان‪ً -‬‬
‫خاصة عند وجود تأخيرات في تسليم اإلصدار النهائي من البرنامج وير‪ .‬ومع ذلك ‪ ،‬هذا عادة ما يكون غير حكيم‪:‬‬ ‫ً‬ ‫عرض أولي األنواع ‪،‬‬
‫‪ . 1‬قد يكون من المستحيل ضبط النموذج األولي لتلبية المتطلبات غير الوظيفية ‪ ،‬مثل متطلبات األداء واألمان والمتانة والموثوقية ‪ ،‬والتي‬
‫تم تجاهله أثناء تطوير النموذج األولي‪ .2 .‬التغيير السريع أثناء التطوير يعني حت ًما أن النموذج األولي غير صحيح‪ -‬غير معروف‪.‬‬
 ‫مواصفات التصميم الوحيدة هي رمز النموذج األولي‪ .‬هذا ليس جيدا يكفي للصيانة طويلة األمد‪ .3 .‬من المحتمل أن تكون التغييرات التي‬
‫تم إجراؤها أثناء تطوير النموذج األولي قد تدهورت هيكل النظام‪ .‬سيكون النظام صعبًا ومكل ًفا للصيانة‪ .4 .‬عادة ما يتم تخفيف معايير‬
‫الجودة التنظيمية لتطوير النموذج األولي‪ .‬ال يجب أن تكون النماذج األولية قابلة للتنفيذ حتى تكون مفيدة‪ .‬النماذج الورقية يمكن أن تكون‬
‫فعالة في مساعدة المستخدمين على تحسين ملف تصميم الواجهة والعمل من خالل سيناريوهات )‪ (Rettig ، 1994‬واجهة مستخدم النظام‬
‫جد ا للتطوير ويمكن بناؤها في غضون أيام قليلة‪ .‬امتداد لهذه التقنية هو ساحر نموذج‬ ‫حيث تم تطوير واجهة ‪ Oz‬االستخدام‪ .‬هذه رخيصة ً‬
‫المستخدم فقط‪ .‬يتفاعل المستخدمون مع هذا واجهة ولكن يتم تمرير طلباتهم إلى الشخص الذي يفسرها والمخرجات ‪ 2/3‬التعامل مع‬
‫التغيير ‪ 2.3.2 47‬التسليم اإلضافي التسليم المتزايد (الشكل ‪ ) 2.10‬هو نهج لتطوير البرمجيات حيث يتم تسليم بعض الزيادات المطورة‬
‫إلى العميل ونشرها لالستخدام في بيئة تشغيلية‪ .‬في عملية التسليم التزايدي ‪ ،‬يحدد العمالء‪ -‬تيفي ‪ ،‬بإيجاز ‪ ،‬الخدمات‪ W‬التي سيقدمها النظام‪.‬‬
‫يحددون أي من الخدمات‪ W‬هي األكثر أهمية واألقل أهمية بالنسبة لهم‪ .‬عدد من يتم بعد ذلك تحديد زيادات التسليم ‪ ،‬مع توفير كل زيادة‬
‫مجموعة فرعية من وظائف النظام‪ .‬يعتمد تخصيص الخدمات على الزيادات على الخدمة األولوية ‪ ،‬مع تنفيذ الخدمات‪ W‬ذات األولوية‬
‫القصوى وتسليمها أوالً ‪ .‬بمجرد تحديد زيادات النظام ‪ ،‬فإن متطلبات الخدمة‪ -‬يتم تعريف العناصر التي سيتم تسليمها بالزيادة األولى‬
‫بالتفصيل وهذه الزيادة هي متطور‪ .‬أثناء التطوير ‪ ،‬مزيد من تحليل المتطلبات للزيادات الالحقة يمكن أن تحدث ولكن التغييرات المطلوبة‬
‫للزيادة الحالية غير مقبولة‪ .‬بمجرد اكتمال الزيادة وتسليمها ‪ ،‬يمكن للعمالء وضعها في الخدمة‪ .‬هذا يعني أنهم يأخذون التسليم المبكر‬
‫لجزء من وظائف النظام‪ .‬يستطيعون تجربة مع النظام وهذا يساعدهم في توضيح متطلباتهم ألنظمة الحقة‪ -‬زيادات تيم‪ .‬عند اكتمال‬
‫الزيادات الجديدة ‪ ،‬يتم دمجها مع القائمة الزيادات بحيث تتحسن وظائف النظام مع كل زيادة يتم تسليمها‪ .‬التسليم التزايدي له عدد من‬
‫المزايا‪ . 1 :‬يمكن للعمالء استخدام الزيادات المبكرة كنماذج أولية واكتساب الخبرة في ذلك بإعالمهم بمتطلبات زيادات النظام الالحقة‪.‬‬
‫على عكس النماذج األولية ‪ ،‬هذه هي جزء من النظام الحقيقي ‪ ،‬لذلك ال توجد إعادة تعلم عندما يكون النظام كامالً متاح‪ .2 .‬ال يتعين على‬
‫العمالء االنتظار حتى مجملهايتم تسليم النظام اإللكتروني قبل ذلك يمكن أن تكتسب قيمة منه‪ .‬الزيادة األولى تفي بأهم متطلباتهم‪ -‬إشارات‬
‫حتى يتمكنوا من استخدام البرنامج على الفور‪ . 3 .‬تحافظ العملية على فوائد التطوير التدريجي في أنه ينبغي يكون من السهل نسبيًا دمج‬
‫التغييرات في النظام‪ .4 .‬نظرً ا ألن الخدمات ذات األولوية القصوى يتم تسليمها أوالً ثم يتم إدخال الزيادات في‪ -‬مبشور ‪ ،‬فإن أهم خدمات‪W‬‬
‫النظام تتلقى معظم االختبارات‪ .‬هذا يعنى نظام التصميم بنيان تحديد مخطط تفصيلي متطلبات متطلبات التعيين للزيادات نظام غير‬
‫مكتمل؟ أخير نظام تطوير النظام زيادة راتب تحقق زيادة راتب دمج زيادة راتب تحقق نظام نشر زيادة راتب نظام مكتمل؟ الشكل ‪2.10‬‬
‫تزايدي تسليم ‪ 48‬الفصل ‪ 2‬عمليات البرامج أن العمالء أقل احتمالية لمواجهة إخفاقات البرامج في أكثر األمور أهمية‪ -‬أجزاء تانت من‬
‫النظام‪ .‬ومع ذلك ‪ ،‬هناك مشاكل في التسليم اإلضافي‪ . 1 :‬تتطلب معظم األنظمة مجموعة من المرافق األساسية التي تستخدمها أجزاء‬
‫مختلفة من نظام‪ .‬حيث لم يتم تحديد المتطلبات بالتفصيل حتى يتم زيادة قد يكون من الصعب تحديد المرافق المشتركة التي يحتاجها‬
‫ض ا عند إجراء نظام بديل متطور‪ .‬يريد المستخدمون جميع وظائف النظام‬ ‫الجميع الزيادات‪ .2 .‬يمكن أن يكون التطوير التكراري صعبًا أي ً‬
‫القديم وهم في كثير من األحيان غير راغب في تجربة نظام جديد غير مكتمل‪ .‬لذلك ‪ ،‬الحصول على استخدام‪ -‬مالحظات‪ W‬العمالء الكاملة‬
‫صعبة‪ . 3 .‬جوهر العمليات التكرارية هو أن المواصفات تم تطويرها باالشتراك ‪ -‬مع البرنامج‪ .‬ومع ذلك ‪ ،‬فإن هذا يتعارض مع نموذج‬
‫الشراء العديد من المؤسسات‪ ، W‬حيث تكون مواصفات النظام الكاملة جز ًء ا من النظام عقد تطوير‪ .‬في النهج التدريجي ‪ ،‬ال يوجد نظام‬
‫كامل المواصفات حتى يتم تحديد الزيادة النهائية‪ .‬هذا يتطلب شكال جديدا من العقد ‪ ،‬والذي قد يجد كبار العمالء مثل الوكاالت الحكومية‬
‫صعوبة في القيام به يستوعب‪ .‬هناك بعض أنواع األنظمة التي يتم فيها التطوير والتسليم التدريجي ليس أفضل نهج‪ .‬هذه أنظمة كبيرة ً‬
‫جدا‬
‫قد تنطوي على التطوير فرق تعمل في مواقع مختلفة ‪ ،‬بعض األنظمة المضمنة فيها البرنامج يعتمد على تطوير األجهزة وبعض األنظمة‬
‫المهمة‪ W‬حيث تتطلب كل المتطلبات‪ -‬يجب تحليل البيانات للتحقق من التفاعالت التي قد تعرض السالمة للخطر أو أمن النظام‪ .‬هذه األنظمة‬
‫‪ ،‬بالطبع ‪ ،‬تعاني من نفس المشاكل غير المؤكدة والمتغيرة‪ -‬المتطلبات جي‪ .‬لذلك ‪ ،‬لمعالجة هذه المشاكل والحصول على بعض الفوائد‬
‫من التطوير التدريجي ‪ ،‬يمكن استخدام عملية يكون فيها النموذج األولي للنظام تم تطويره بشكل متكرر واستخدامه كمنصة للتجارب مع‬
‫النظام المتطلبات والتصميم‪ .‬مع الخبرة المكتسبة من النموذج األولي ‪ ،‬نهائية يمكن بعد ذلك االتفاق على المتطلبات‪ 2.3.3 .‬نموذج بوهم‬
‫الحلزوني تم اقتراح إطار عملية برمجية مدفوعة بالمخاطر (النموذج الحلزوني) بواسطة بوم (‪ .)1988‬هذا موضح في الشكل ‪.2.11‬‬
‫هنا ‪ ،‬عملية البرنامج ممثلة‪ -‬تم إرسالها على شكل دوامة ‪ ،‬بدالً من سلسلة من األنشطة مع بعض التراجع عنها نشاط إلى آخر‪ .‬تمثل كل‬
‫حلقة في اللولب مرحلة من مراحل البرنامج عملية‪ .‬وبالتالي ‪ ،‬قد تكون الحلقة األعمق معنية بجدوى النظام ‪ ،‬وهي الحلقة التالية مع‬
‫تعريف المتطلبات ‪ ،‬والحلقة التالية مع تصميم النظام ‪ ،‬وما إلى ذلك‪ .‬يجمع النموذج الحلزوني بين تجنب التغيير وتحمل التغيير‪ .‬يفترض‬
‫أن ‪ 2.3‬التأقلم مع التغيير ‪ 49‬التغييرات هي نتيجة المشروعوتشمل أنشطة إدارة المخاطر الصريحة لتقليل هذه المخاطر‪ .‬تنقسم كل حلقة‬
‫في اللولب إلى أربعة أقسام‪ . 1 :‬تحديد األهداف يتم تحديد األهداف المحددة لتلك المرحلة من المشروع‪ .‬يتم تحديد القيود المفروضة على‬
‫العملية والمنتج وإدارة مفصلة‪ -‬يتم وضع خطة منة‪ .‬تحديد مخاطر المشروع‪ .‬استراتيجيات بديلة ‪ ،‬اعتمادا على هذه المخاطر ‪ ،‬قد يتم‬
‫مفصل يتم إجراء التحليل‪ .‬يتم اتخاذ خطوات لتقليل ‪ ، a‬التخطيط لها‪ .2 .‬تقييم المخاطر والحد منها لكل من مخاطر المشروع المحددة‬
‫المخاطر‪ .‬على سبيل المثال ‪ ،‬إذا كان هناك ملف خطر عدم مالءمة‪ W‬المتطلبات ‪ ،‬قد يتم تطوير نظام نموذج أولي‪ .3 .‬التطوير والتحقق‬
‫بعد تقييم المخاطر ‪ ،‬نموذج تطوير ل تم اختيار النظام‪ .‬على سبيل المثال ‪ ،‬قد تكون النماذج األولية التي يتم التخلص منها هي أفضل‬
‫إذا كانت مخاطر واجهة المستخدم هي السائدة‪ .‬إذا كانت مخاطر السالمة‪ W‬هي الرئيسية في االعتبار ‪ ،‬قد تكون ‪ opment‬تطوير نهج‬
 ‫التنمية القائمة على التحوالت الرسمية هي األكثر العملية المناسبة ‪ ،‬وما إلى ذلك‪ .‬إذا كان الخطر الرئيسي المحدد هو تكامل النظام‬
‫الفرعي‪ -‬قد يكون نموذج الشالل هو أفضل نموذج تطوير يمكن استخدامه‪ .4 .‬التخطيط تتم مراجعة المشروع واتخاذ قرار بشأن‬
‫استمراره حلقة أخرى من اللولب‪ .‬إذا تقرر االستمرار ‪ ،‬يتم وضع الخطط لـ المرحلة التالية من المشروع‪ .‬الشكل ‪ 2.11‬بوم نموذج‬
‫مخاطرة تحليل مخاطرة تحليل مخاطرة تحليل مخاطرة تحليل بروتو‪ -‬اكتب ‪ 1‬النموذج )‪ (© IEEE 1988‬حلزوني عملية البرمجيات‬
‫منتج تصميم مفصلة تصميم ‪ V & V‬متطلبات متطلبات تصديق تصميم ‪ S / W‬األولي ‪ 2‬النموذج ‪ 3‬التشغيل النموذج المبدئي مفهوم عملية‬
‫شفرة اختبار الوحدة اندماج امتحان قبول امتحان تطوير الخدمة والتحقق منها منتج من المستوى التالي تقييم البدائل ‪ ،‬تحديد المخاطر‬
‫وحلها تحديد األهداف ‪ ،‬بدائل و قيود التخطيط للمرحلة التالية اندماج وخطة االختبار تطوير يخطط خطة المتطلبات خطة دورة الحياة‬
‫مراجعة عمليات المحاكاة‪ W‬والنماذج والمعايير ‪ 50‬الفصل ‪ 2‬عمليات البرامج الفرق الرئيسي بين النموذج اللولبي ونماذج معالجة البرامج‬
‫األخرى هو اعترافها الصريح بالمخاطر‪ .‬تبدأ دورة الحلزون من خالل تحديد األهداف مثل األداء والوظائف‪ .‬طرق بديلة لتحقيق هذه‬
‫والتعامل مع القيود المفروضة على كل منها‪ .‬كل يتم تقييم البديل مقابل كل هدف ويتم تحديد مصادر مخاطر ‪ tives‬األهداف‪ -‬ثم يتم تعداد‬
‫الخطوة التالية هي حل هذه المخاطر من خالل أنشطة جمع المعلومات مثل كتحليل ونماذج أولية ومحاكاة أكثر تفصيالً‪- fied. .‬المشروع‬
‫بمجرد تقييم المخاطر ‪ ،‬يتم إجراء بعض التطوير ‪ ،‬تليها خطة‪ -‬نينج للمرحلة التالية من العملية‪ .‬بشكل غير رسمي ‪ ،‬المخاطرة تعني شيًئ ا‬
‫ما يمكن أن يحدث خطأ‪ .‬على سبيل المثال ‪ ،‬إذا كانت النية هي استخدام لغة برمجة جديدة ‪ ،‬يتمثل الخطر في أن المجمعين المتاحين غير‬
‫تؤدي المخاطر إلى تغييرات البرامج المقترحة ومشاكل المشروع مثل الجدول ‪ cient.‬موثوقين أو ال ينتجون كفاءة كافية كود كائن‬
‫الزمني وتجاوز التكلفة ‪ ،‬لذا فإن تقليل المخاطر هو إدارة مهمة ج ًد ا للمشروع نشاط‪ .‬يتم تناول إدارة المخاطر ‪ ،‬وهي جزء أساسي من‬
‫هي مثال على )‪ (RUP) (Krutchen ، 2003‬إدارة المشروع ‪ ،‬في الفصل ‪ 2.4 .22‬العملية العقالنية الموحدة العملية العقالنية الموحدة‬
‫وآخرون ‪ (Rumbaugh ، ،‬والموحد المرتبط به عملية تطوير البرمجيات ‪ UML‬الحديث نموذج العملية الذي تم اشتقاقه من العمل على‬
‫د مثال على نموذج العملية المختلطة‪ .‬يجمع ‪ goo‬لقد قمت بتضمين وصف هنا ‪ ،‬حيث إنه ‪ 1999 Arlow and Neustadt ، 2005).‬؛‬
‫عناصر من جميع نماذج العمليات العامة (القسم ‪ ، )2.1‬وهم‪ -‬يقرن الممارسات الجيدة في المواصفات والتصميم (القسم ‪ )2.2‬ويدعم‬
‫ً‬
‫واحدا لـ العملية‪ .‬في المقابل ‪ ،‬يتم ‪ RUP‬النماذج األولية والتسليم اإلضافي (القسم ‪ .)2.3‬تدرك‬ ‫أن نماذج العمليات التقليدية تقدم عر ً‬
‫ضا‬
‫عاد ًة من ثالث وجهات نظر‪ . 1 :‬منظور ديناميكي ‪ ،‬يوضح مراحل النموذج بمرور الوقت‪ .2 .‬منظور ثابت ‪ ،‬يُظهر أنشطة ‪ RUP‬وصف‬
‫‪ RUP‬العملية التي تم تفعيلها‪ . 3 .‬منظور الممارسة ‪ ،‬الذي يقترح الممارسات الجيدة الستخدامها خالل العملية‪ .‬تحاول معظم أوصاف‬
‫أعتقد أن هذا يجعل العملية أكثر صعوبة فهم ‪ (Krutchen ، 2003). ،‬في مخطط واحد ‪- tives‬الجمع بين المنظور الثابت والديناميكي‬
‫هو نموذج مرحلي يحدد أربع مراحل منفصلة في البرنامج عملية‪ .‬ومع ‪. RUP‬لذلك أستخدم أوصا ًفا منفصلة لكل من هذه المنظورات‬
‫ارتباطا وثي ًقا بالعمل وليس ‪ RUP‬ذلك ‪ ،‬على عكس نموذج الشالل حيث يتم معادلة المراحل بالعملية األنشطة ‪ ،‬فإن المراحل في‬ ‫ً‬ ‫ترتبط‬
‫هؤالء هم‪ .1 :‬البداية الهدف من المرحلة االستهاللية هو إنشاء دراسة جدوى لـ ‪ RUP.‬مخاوف فنية‪ .‬يوضح الشكل ‪ 2.11‬المراحل في‬
‫نظام‪ .‬يجب عليك تحديد جميع الكيانات الخارجية (األشخاص واألنظمة) التي ستقوم بذلك ‪ 2.4‬العملية العقالنية الموحدة ‪ 51‬تتفاعل مع‬
‫لتقييم المساهمة التي يقدمها النظام لألعمال‪ .‬اذا هذا المساهمة طفيفة ‪- mation ،‬النظام وتحدد هذه التفاعالت‪ .‬ثم تستخدم هذه المعلومات‬
‫ثم يمكن إلغاء المشروع بعد هذه المرحلة‪ . 2 .‬التفصيل إن أهداف مرحلة الصياغة هي تطوير الفهم في مجال المشكلة ‪ ،‬إنشاء إطار‬
‫معماري للنظام ‪ ،‬تطوير خطة المشروع ‪ ،‬وتحديد مخاطر المشروع الرئيسية‪ .‬عند االنتهاء من هذا يجب أن يكون لديك نموذج متطلبات‬
‫ووصف معماري ‪ ،‬وخطة تطوير لـ برمجة‪ .3 .‬البناء مرحلة البناء تتضمن ‪ UML ،‬للنظام ‪ ،‬والذي قد يكون مجموعة حاالت استخدام‬
‫متواز ومتكامل أثناء ذلك مرحلة‪ .‬عند االنتهاء من هذه‬‫ٍ‬ ‫تصميم النظام ‪ ،‬والبرمجة ‪ ،‬و اختبارات‪ .‬تم تطوير أجزاء من النظام بشكل‬
‫المرحلة ‪ ،‬يجب أن يكون لديك نظام برمجي يعمل والوثائق ذات الصلة الجاهزة للتسليم إلى المستخدمين‪ .4 .‬االنتقال تختص المرحلة‬
‫بتحريك النظام من مجتمع التطوير إلى مجتمع المستخدمين وجعله يعمل بيئة حقيقية‪ .‬هذا شيء يتم تجاهله في معظم ‪ RUP‬األخيرة من‬
‫عمليات البرامج نماذج ولكنه ‪ ،‬في الواقع ‪ ،‬نشاط مكلف وأحيا ًن ا إشكالي‪ .‬على بعد االنتهاء من هذه المرحلة ‪ ،‬يجب أن يكون لديك نظام‬
‫بطريقتين‪ .‬يمكن تفعيل كل مرحلة في بطريقة ‪ RUP‬برمجيات‪ W‬موثق تعمل بشكل صحيح في بيئتها التشغيلية‪ .‬يتم دعم التكرار داخل‬
‫تكرارية مع النتائج التي تم تطويرها بشكل تدريجي‪ .‬باإلضافة إلى ذلك ‪ ،‬فإن المجموعة بأكملها من المراحل قد يتم تفعيلها بشكل‬
‫على األنشطة التي ‪ RUP‬تدريجي ‪ ،‬كما هو موضح في السهم الحلقي من االنتقال إلى البداية في الشكل ‪ .2.12‬يركز العرض الثابت لـ‬
‫هناك ستة تدفقات عمل أساسية للعملية تم تحديدها في العملية ‪ RUP.‬تحدث أثناء عمليات التطوير‪ .‬تسمى هذه مهام سير العمل في وصف‬
‫‪ UML‬وبالتالي سير العمل الوصف موجه حول نماذج ‪ UML ،‬باالشتراك مع ‪ RUP‬وثالثة أعمال داعمة أساسية‪ -‬يطفو‪ .‬تم تصميم‬
‫المرتبطة مثل نماذج التسلسل ‪ ،‬نماذج الكائن ‪،‬إلخ‪ .‬تم وصف العمليات األساسية للهندسة والدعم في الشكل ‪ .2.13‬الميزة في تقديم‬
‫غير مرتبطة بمهام سير عمل محددة‪ .‬من حيث المبدأ على ‪ opment‬وجهات النظر الديناميكية والثابتة هي أن مراحل التطور عملية‬
‫قد تكون نشطة في جميع مراحل العملية‪ .‬في المراحل المبكرة للعملية ‪ ،‬من المحتمل أن يتم ‪ RUP‬األقل ‪ ،‬كل شيء من مهام سير عمل‬
‫إنفاق معظم الجهد على مهام سير العمل مثل األعمال النمذجة والمتطلبات ‪ ،‬وفي المراحل الالحقة ‪ ،‬في االختبار والنشر‪ .‬التأسيس‬
‫التفصيلي البناء تكرار المرحلة انتقال الشكل ‪ 2.12‬مراحل في عقالني موحد عملية ‪ 52‬الفصل ‪ 2‬عمليات البرامج يصف منظور‬
‫التي يوصى باستخدامها‪ W‬في تطوير األنظمة‪ .‬أفضل ستة أساسيات‪ W‬يوصى ‪ tices‬تطبيق هندسة البرمجيات الجيد ‪ RUP‬الممارسة‪ W‬في‬
‫بالممارسات‪ . 1 :‬تطوير البرامج بشكل تكراري قم بتخطيط الزيادات في النظام بنا ًء على العميل األولويات وتطوير ميزات النظام ذات‬
‫األولوية القصوى في وقت مبكر من التطوير‪ -‬عملية منة‪ . 2 .‬إدارة المتطلبات توثيق صريح لمتطلبات العميل و تتبع التغييرات على هذه‬
‫المتطلبات‪ .‬تحليل تأثير التغييرات على النظام قبل قبولها‪ . 3 .‬استخدام البنى القائمة على المكونات قم ببناء بنية النظام في كوم‪ -‬المؤلفات ‪،‬‬
‫الرسومية لتقديم ثابت و وجهات النظر الديناميكية ‪ UML‬كما نوقش ساب ًقا في هذا الفصل‪ .4 .‬برمجيات النماذج المرئية استخدم نماذج‬
‫للبرنامج‪ . 5 .‬التحقق من جودة البرنامج تأكد من أن البرنامج يتوافق مع الجودة التنظيمية المعايير‪ .‬الشكل ‪ 2.13‬ثابت سير العمل في‬
‫عقالني موحد عملية وصف سير العمل نمذجة األعمال يتم تصميم عمليات األعمال باستخدام حاالت استخدام األعمال‪ .‬المتطلبات يتم‬
‫تحديد الجهات‪ W‬الفاعلة التي تتفاعل مع النظام واستخدامها تم تطوير الحاالت لنمذجة متطلبات النظام‪ .‬التحليل والتصميم يتم إنشاء نموذج‬
‫التصميم وتوثيقه باستخدام الهندسة المعمارية النماذج ونماذج المكونات ونماذج الكائن والتسلسل عارضات ازياء‪ .‬التنفيذ يتم تنفيذ مكونات‬
‫النظام و منظم في تنفيذ النظم الفرعية‪ .‬كود تلقائي الجيل من نماذج التصميم يساعد في تسريع هذه العملية‪ .‬االختبار هو عملية تكرارية يتم‬
‫تنفيذها بالتزامن مع التنفيذ‪ .‬يتبع اختبار النظام االنتهاء من التطبيق‪ .‬النشر يتم إنشاء إصدار منتج وتوزيعه على المستخدمين وتثبيته في‬
‫مكان عملهم‪ .‬إدارة التكوين والتغيير هذا سير العمل الداعم يدير التغييرات على النظام (انظر الفصل ‪ .)25‬إدارة المشروع يدير سير‬
‫العمل الداعم هذا تطوير النظام (انظر الفصلين ‪ 22‬و ‪ .) 23‬البيئة يهتم سير العمل هذا بصنع البرامج المناسبة األدوات المتاحة لفريق‬
‫تطوير البرمجيات الفصل الثاني النقاط الرئيسية ‪ 53‬النقاط الرئيسية عمليات البرمجيات هي األنشطة التي ينطوي عليها إنتاج نظام‬
‫برمجي‪ .‬عملية البرمجيات النماذج هي تمثيالت مجردة لهذه العمليات‪ .‬تصف نماذج العمليات العامة تنظيم عمليات البرمجيات‪ .‬أمثلة على‬
‫هؤالء العامة تتضمن النماذج نموذج الشالل والتطوير التدريجي والتطوير الموجه إلعادة االستخدام‪ .‬هندسة المتطلبات هي عملية تطوير‬
‫مواصفات البرنامج‪ .‬تحديد تهدف إلى توصيل احتياجات‪ W‬النظام للعميل لمطوري النظام‪ .‬تهتم عمليات التصميم والتنفيذ بتحويل المتطلبات‬
‫المواصفات في نظام برمجي قابل للتنفيذ‪ .‬يمكن استخدام طرق التصميم المنهجي على أنها جزء من هذا التحول‪.‬التحقق من صحة‬
‫البرنامج هو عملية التحقق من أن النظام يتوافق مع مواصفاته و أنه يلبي االحتياجات الحقيقية لمستخدمي النظام‪ .‬يحدث تطور البرامج‬
‫عندما تقوم بتغيير أنظمة البرامج الحالية لتتوافق مع األنظمة الجديدة متطلبات‪ .‬التغييرات مستمرة ويجب أن يتطور البرنامج ليظل ً‬
‫مفيدا‪.‬‬
‫يجب أن تتضمن العمليات أنشطة للتعامل مع التغيير‪ .‬قد ينطوي هذا على مرحلة النماذج األولية يساعد على تجنب القرارات السيئة بشأن‬
‫المتطلبات والتصميم‪ .‬قد يتم تنظيم العمليات من أجل التطوير والتسليم التكراري بحيث يمكن إجراء التغييرات دون تعطيل النظام ككل‪.‬‬
‫العملية الموحدة العقالنية هي نموذج عملية عام حديث يتم تنظيمه في مراحل (التأسيس ‪ ،‬التفصيل ‪ ،‬البناء ‪ ،‬واالنتقال) ولكنه يفصل بين‬
‫األنشطة (المتطلبات ‪ ،‬التحليل والتصميم وما إلى ذلك) من هذه المراحل‪ . 6 .‬التحكم في التغييرات التي تم إجراؤها على البرنامج إدارة‬
‫عملية مناسبة ‪ RUP‬التغييرات التي يتم إجراؤها على البرنامج باستخدام التغيير نظام اإلدارة وإجراءات وأدوات إدارة التكوين‪ .‬ال تعد‬
‫لجميع أنواع التطوير ‪ ،‬على سبيل المثال ‪ ،‬المضمنة تطوير البرمجيات‪ .‬ومع ذلك ‪ ،‬فإنه يمثل نهجً ا يحتمل أن يكون يجمع بين نماذج‬
‫هي الفصل بين المراحل وتدفقات العمل ‪ RUP ،‬العمليات العامة الثالثة التي تمت مناقشتها في القسم ‪ .2.1‬األكثر أهمية االبتكارات في‬
‫والتعرف على‪ -‬أن نشر البرامج في بيئة المستخدم جزء من العملية‪ .‬المراحل ديناميكية ولها أهداف‪ .‬مهام سير العمل ثابتة وهي أنشطة‬
‫فنية ليست كذلك مرتبط بمرحلة واحدة ولكن يمكن استخدامها طوال فترة التطوير ل تحقيق أهداف كل مرحلة‪ 54 .‬الفصل ‪ 2‬عمليات‬
‫البرمجيات‪ W‬قراءة متعمقة إدارة جودة البرمجيات ومخاطر األعمال‪ .‬هذا في المقام األول كتاب عن إدارة البرمجيات لكنه يتضمن فصالً‬
‫ممتازا (الفصل ‪ )4‬عن نماذج العملية‪( .‬م‪ .‬ولد ‪ ،‬جون وايلي وأوالده المحدودة ‪ ).1999 ،‬نماذج العمليات في هندسة البرمجيات‪ .‬هذه‬ ‫ً‬
‫دبليو سكاتشي ‪ ،‬موسوعة البرمجيات ( ‪.‬نظرة عامة ممتازة على مجموعة واسعة من البرامج نماذج العمليات الهندسية التي تم اقتراحها‬
‫‪ / SE-‬األوراق ‪. Marciniak، John Wiley and Sons، 2001.) http://www.ics.uci.edu/~wscacchi/‬الهندسة ‪ ،‬محرر‪ .‬ج‬
‫العملية العقالنية الموحدة ‪ -‬مقدمة (الطبعة الثالثة)‪ .‬هذا هو الكتاب األكثر قراءة متوفر ‪Encyc / Process-Models-SE-Encyc.pdf.‬‬
‫العملية بشكل جيد ‪ ،‬لكن أود أن أرى المزيد عن الصعوبات العملية الستخدام ‪ Krutchen‬في وقت كتابة هذه السطور‪ .‬يصف ‪ RUP‬على‬
‫إبداء أسباب إلجابتك بنا ًء على نوع النظام الذي يتم ‪.) E X E R C I S E S 2.1.‬أديسون ويسلي ‪. (P. Krutchen، 2003 ،‬هذه العملية‬
‫تطويره ‪ ،‬اقترح أنسب نموذج عملية برمجي عام يمكن استخدامه كأساس لإلدارة تطوير األنظمة التالية‪ :‬نظام للتحكم في الفرامل المانعة‬
‫لالنغالق في السيارة نظام واقع افتراضي لدعم صيانة البرامج نظام محاسبة جامعي يحل محل نظام قائم نظام تخطيط سفر تفاعلي يساعد‬
‫المستخدمين على تخطيط الرحالت بأقل األسعار تأثير بيئي ‪ . 2.2‬اشرح لماذا يعتبر التطوير التدريجي هو النهج األكثر فاعلية لتطوير‬
‫األعمال أنظمة البرمجيات‪ .‬لماذا يعتبر هذا النموذج أقل مالءمة‪ W‬لهندسة أنظمة الوقت الفعلي؟ ‪ 2.3‬ضع في اعتبارك نموذج العملية‬
‫المعتمد على إعادة االستخدام الموضح في الشكل ‪ . 2.3‬اشرح لماذا من الضروري لديها نوعان من األنشطة الهندسية منفصلة المتطلبات‬
‫في العملية‪ 2.4 .‬اقترح سبب أهمية التمييز بين تطوير المستخدم‪ W‬المتطلبات والتطورمتطلبات النظام في المتطلبات الهندسية عملية‪2.5 .‬‬
‫صف األنشطة الرئيسية في عملية تصميم البرامج ومخرجاتها أنشطة‪ .‬باستخدام رسم تخطيطي ‪ ،‬أظهر العالقات الممكنة‪ W‬بين مخرجات‪W‬‬
‫هذه أنشطة‪ . 2.6 .‬اشرح سبب حتمية التغيير في األنظمة المعقدة وقدم أمثلة (بصرف النظر عن النماذج األولية والتسليم المتزايد) ألنشطة‬
‫عمليات البرامج التي تساعد في التنبؤ بالتغييرات وجعل البرامج التي يجري تطويرها أكثر مرونة للتغيير‪ .‬اشرح سبب عدم استخدام‬
‫الحلزوني نموذجً ا قاباًل للتكيف يمكنه ‪ Boehm‬األنظمة التي تم تطويرها كنماذج أولية كإنتاج األنظمة‪ .2.8 .‬اشرح سبب كون نموذج‬
 ‫دعم كال التغييرين التجنب وتغيير أنشطة التسامح‪ .‬في الممارسة العملية ‪ ،‬لم يتم استخدام هذا النموذج على نطاق واسع‪ .‬اقترح لماذا قد‬
‫يكون هذا هو الحال‪ 2.9 .‬ما هي مزايا تقديم آراء ثابتة وديناميكية لعملية البرنامج كما في العملية العقالنية الموحدة؟ ‪ .2.10‬تاريخيا ً ‪،‬‬
‫تسبب إدخال التكنولوجيا في حدوث تغييرات عميقة في سوق العمل ‪ ،‬مؤق ًت ا على األقل ‪ ،‬نازحون من الوظائف‪ .‬ناقش ما إذا كان إدخال‬
‫واسع النطاق من المحتمل أن يكون ألتمتة العمليات نفس النتائج بالنسبة لمهندسي البرمجيات‪ .‬إذا لم تفعل ذلك أعتقد أنه سيفعل ‪ ،‬اشرح‬
‫لماذا ال‪ .‬إذا كنت تعتقد أنه سيقلل من فرص العمل ‪ ،‬فهل هذا أمر أخالقي بالنسبة لـ تأثر المهندسين بمقاومة إدخال هذه التكنولوجيا بشكل‬
‫والعملية الموحدة‪ :‬كائن عملي التحليل ‪. UML 2‬سلبي أو نشط؟ الفصل ‪ 2‬المراجع ‪ 55‬مراجع أرلو ‪ ،‬جيه ونوشتات ‪ ،‬آي (‪)2005‬‬
‫والتصميم (اإلصدار الثاني)‪ .‬بوسطن‪ :‬أديسون ويسلي‪ .‬بوم ‪ ،‬ب ‪ ،‬وتورنر ‪ ،‬ر‪ .)2003( .‬موازنة الرشاقة‪ W‬واالنضباط‪ :‬دليل للحيرة‪.‬‬
‫كمبيوتر ‪'. IEEE .72-61 ، )5( 21 ،‬بوسطن‪ :‬أديسون ويسلي‪ .‬بوم ‪ ،‬ب و‪' .)1988( .‬نموذج حلزوني لتطوير البرمجيات وتعزيزها‬
‫بودجن ‪ ،‬د‪ .) 2003( .‬تصميم البرمجيات (اإلصدار الثاني)‪ .‬هارلو ‪ ،‬المملكة المتحدة‪ :‬أديسون ويسلي‪ .‬كروتشين ‪ ،‬ص‪.)2003( .‬‬
‫‪. Massol ، V. and Husted ، T. (2003).‬العملية العقالنية الموحدة ‪ -‬مقدمة (اإلصدار الثالث)‪ .‬القراءة ‪ ،‬ماجستير‪ :‬أديسون ويسلي‬
‫ريتيج ‪ ،‬م‪" .)1994( .‬مبرمج عملي‪ :‬النماذج األولية لألصابع ‪: Manning Publications Co.‬في العمل‪ .‬غرينتش ‪ ،‬كونيتيكت ‪JUnit‬‬
‫رويس ‪ ،‬دبليو دبليو (‪" .)1970‬إدارة تطوير أنظمة البرمجيات الكبيرة‪ :‬المفاهيم و ‪ ACM ، 37 (4) ، 21-7.‬الصغيرة"‪ .‬باالتصاالت‬
‫رامبو ‪ ،‬ج ‪ ،‬جاكوبسون ‪ ،‬آي وبوش ‪ ،‬جي (‪ .)1999‬عملية تطوير ‪. IEEE WESTCON، Los Angeles CA: 1–9.‬التقنيات‬
‫‪". IEEE Computer، 39 (2) ،‬البرمجيات الموحدة‪ .‬القراءة ‪ ،‬ماس‪ :‬أديسون ويسلي‪ .‬شميدت ‪ ،‬دي سي (‪" .)2006‬الهندسة النموذجية‬
‫شنايدر ‪ ،‬س‪ .) 2001( .‬الطريقة ب‪ .‬هاوندميلز ‪ ،‬المملكة المتحدة‪ :‬بالجريف ماكميالن‪ .‬وردزورث ‪ ،‬ج‪ .)1996( .‬هندسة ‪25-31.‬‬
‫تطوير ‪ 3‬أهداف الهدف من هذا الفصل هو تعريفك ‪ B. Wokingham: Addison-Wesley.Agile software‬البرمجيات مع‬
‫بالبرنامج الرشيق طرق التطوير‪ .‬عندما تقرأ الفصل ‪ ،‬سوف‪ :‬فهم األساس المنطقي ألساليب تطوير البرمجيات‪ W‬الرشيقة ‪ ،‬البيان الرشيق ‪،‬‬
‫تنمية مدفوعة تعرف على الممارسات‪ W‬الرئيسية في البرمجة المتطرفة وكيف يتم ذلك تتعلق بالمبادئ ‪ plan-‬و ‪ Agile‬واالختالفات بين‬
‫العامة لألساليب الرشيقة ؛ فهم نهج سكرم إلدارة المشاريع الرشيقة ؛ كن على دراية بقضايا ومشاكل توسيع نطاق التنمية الرشيقة طرق‬
‫تطوير أنظمة البرمجيات الكبيرة‪ .‬محتويات ‪ 3.1‬طرق رشيقة ‪ 3.2‬التنمية المدفوعة بالخطة ورشيقة ‪ 3.3‬البرمجة المتطرفة ‪ 3.4‬إدارة‬
‫المشاريع الرشيقة ‪ 3.5‬طرق القياس الرشيقة الفصل ‪ - 357‬تطوير البرمجيات تعمل الشركات اآلن في بيئة عالمية سريعة التغير‪ .‬إنهم‬
‫يجب عليهم االستجابة للفرص واألسواق الجديدة ‪ ،‬والظروف االقتصادية المتغيرة ‪ ،‬و ظهور المنتجات والخدمات‪ W‬المنافسة‪ .‬يعد البرنامج‬
‫جزءًا من جميع األعمال تقري ًب ا نيس لذلك يتم تطوير البرامج الجديدة بسرعة لالستفادة من الجديد الفرص واالستجابة للضغوط التنافسية‪.‬‬
‫لذلك ‪ ،‬تعد اآلن في كثير من األحيان أكثر المتطلبات أهمية ألنظمة البرمجيات‪ .‬في الحقيقة‪ ،‬العديد من ‪ deliv-‬التطوير السريع و‬
‫الشركات على استعداد للمقايضة بجودة البرامج والتنازل عنها المتطلبات لتحقيق نشر أسرع للبرنامج الذي يحتاجون إليه‪ .‬نظرً ا ألن هذه‬
‫الشركات تعمل في بيئة متغيرة ‪ ،‬فغالبًا ما يكون من العملي‪ -‬من المستحيل اشتقاق مجموعة كاملة من متطلبات البرامج المستقرة‪ .‬األولي‬
‫تتغير المتطلبات حت ًم ا ألن العمالء يجدون أنه من المستحيل التنبؤ بكيفية أ سيؤثر النظام على ممارسات‪ W‬العمل ‪ ،‬وكيف سيتفاعل مع‬
‫األنظمة األخرى ‪ ،‬وماذا يجب أن تتم أتمتة عمليات المستخدم‪ .‬قد يكون ذلك فقط بعد تسليم النظام ويكتسب المستخدمون الخبرة معها حتى‬
‫تتضح المتطلبات الحقيقية‪ .‬حتى ذلك الحين ‪ ،‬من المحتمل أن تتغير المتطلبات بسرعة وبشكل غير متوقع بسبب عوامل خارجية تورس‪.‬‬
‫قد يكون البرنامج بعد ذلك قدي ًم ا عند تسليمه‪ .‬عمليات تطوير البرمجيات التي تخطط لتحديد المتطلبات بالكامل ومن ثم فإن تصميم وبناء‬
‫واختبار النظام ليس موج ًه ا للبرامج السريعة تطوير‪ .‬مع تغير المتطلبات أو اكتشاف مشاكل المتطلبات ‪ ،‬يجب إعادة صياغة تصميم النظام‬
‫أو تنفيذه وإعادة اختباره‪ .‬نتيجة‪ ،‬الشالل التقليدي أو العملية القائمة على المواصفات عادة ما تكون طويلة ونهائية يتم تسليم البرنامج إلى‬
‫العميل بعد فترة طويلة من تحديده في األصل‪ .‬بالنسبة لبعض أنواع البرامج ‪ ،‬مثل أنظمة التحكم الحرجة للسالمة ‪ ،‬حيث يعد التحليل‬
‫الكامل للنظام أمرً ا ضرور ًي ا ‪ ،‬والنهج القائم على الخطة هو النهج الصحيح‪ .‬ومع ذلك ‪ ،‬في بيئة األعمال سريعة الحركة ‪ ،‬يمكن أن يتسبب‬
‫ذلك في مشاكل حقيقية‪ .‬بواسطة وقت إتاحة البرنامج لالستخدام ‪ ،‬يجوز أن يكون السبب األصلي لشرائه تغيرت بشكل جذري بحيث‬
‫على وجه الخصوص ‪ ،‬عمليات التطوير التي تركز على البرمجيات السريعة ‪ busi-‬أصبح البرنامج عديم الفائدة فعليًا‪ .‬لذلك ‪ ،‬بالنسبة لـ‬
‫التنمية والتسليم ضروريان‪ .‬الحاجة إلى تطوير سريع للنظام والعمليات التي يمكنها التعامل مع التغيير تم التعرف على المتطلبات لبعض‬
‫تدريجيًا التنمية في الثمانينيات (ميلز وآخرون ‪ .)1980 ،‬إدخال ما يسمى الرابع دعمت لغات الجيل ‪ ،‬أيضًا ‪ IBM‬الوقت‪ .‬قدمت‪ W‬شركة‬
‫في الثمانينيات ‪ ،‬فكرة التطور السريع وتقديم البرمجيات (مارتن ‪ .)1981 ،‬ومع ذلك ‪ ،‬فإن الفكرة انطلقت ح ًقا في أواخر التسعينيات مع‬
‫والبرمجة ‪ DSDM (Stapleton ، 1997) ، Scrum (Schwaber and Beedle ، 2001) ،‬تطوير مفهوم األساليب الرشيقة مثل‬
‫المتطرفة (بيك ‪ 1999 ،‬؛ بيك ‪ .) 2000 ،‬تم تصميم عمليات التطوير السريع للبرامج إلنتاج برامج مفيدة بسرعة‪ .‬لم يتم تطوير البرنامج‬
‫كوحدة واحدة ولكن كسلسلة من الزيادات مع كل زيادة بما في ذلك وظائف النظام الجديدة‪ .‬رغم أن هناك الكثير طرق التطوير السريع‬
‫للبرامج ‪ ،‬فهي تشترك في بعض الخصائص األساسية‪ . 1 :‬عمليات المواصفات والتصميم والتنفيذ متداخلة‪ .‬ال توجد مواصفات مفصلة‬
‫للنظام ‪ ،‬ووثائق التصميم صغيرة تم تحجيمها أو إنشاؤها تلقائيًابواسطة بيئة البرمجة المستخدمة في الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة‬
‫تنفيذ النظام‪ .‬وثيقة متطلبات المستخدم تحدد فقط أكثر الخصائص الهامة للنظام‪ .2 .‬تم تطوير النظام في سلسلة من اإلصدارات‪.‬‬
‫المستخدمون النهائيون والنظام اآلخر يشارك أصحاب المصلحة في تحديد وتقييم كل إصدار‪ .‬انهم قد اقتراح التغييرات على البرنامج‬
 ‫والمتطلبات الجديدة التي يجب تنفيذها‪ -‬في إصدار الحق من النظام‪ .3 .‬غالبًا ما يتم تطوير واجهات مستخدم النظام باستخدام التطوير‬
‫التفاعلي النظام الذي يسمح بإنشاء تصميم الواجهة بسرعة عن طريق الرسم ووضع‪ -‬جي على الواجهة‪ .‬قد يقوم النظام بعد ذلك بإنشاء‬
‫األساليب الرشيقة هي طرق تطوير ‪ Microsoft Windows.‬واجهة على شبكة اإلنترنت لـ متصفح أو واجهة لمنصة معينة مثل‬
‫تدريجية تكون فيها الزيادات عاد ًة ما يتم إنشاء‪ W‬إصدارات صغيرة وجديدة من النظام وإتاحتها للعميل‪ -‬تومرز كل أسبوعين أو ثالثة‬
‫أسابيع‪ .‬أنها تشرك العمالء في عملية التطوير للحصول على مالحظات سريعة حول المتطلبات المتغيرة‪ .‬هم يقللون من الوثائق عن‬
‫طريق استخدام االتصاالت غير الرسمية بدال من االجتماعات الرسمية مع الوثائق المكتوبة‪ 3.1 .‬طرق رشيقة في الثمانينيات وأوائل‬
‫التسعينيات ‪ ،‬كان هناك رأي واسع االنتشار مفاده أن أفضل طريقة لذلك تحقيق برنامج أفضل كان من خالل التخطيط الدقيق للمشروع ‪،‬‬
‫و عمليات تطوير البرمجيات الخاضعة للرقابة ‪ CASE ،‬والجودة الرسمية ضمان واستخدام أساليب التحليل والتصميم التي تدعمها أدوات‬
‫والصارمة‪ .‬جاء هذا الرأي من مجتمع هندسة البرمجيات الذي كان مسؤوالً عن تطوير كبير وطويل أنظمة البرمجيات الحية مثل الفضاء‬
‫واألنظمة الحكومية‪ .‬تم تطوير هذا البرنامج من قبل فرق كبيرة تعمل لشركات مختلفة‪ .‬فرق غالبًا ما كانت مشتتة جغرافيًا وعملت على‬
‫البرنامج لفترات طويلة من وقت‪ .‬مثال على هذا النوع من البرامج هو أنظمة التحكم لطائرة حديثة ‪ ،‬والتي قد تستغرق ما يصل إلى ‪10‬‬
‫سنوات من المواصفات األولية إلى النشر‪ .‬هذه الخطة‪ -‬تتضمن المناهج المدفوعة نفقات عامة كبيرة في التخطيط والتصميم والتوثيق‪ -‬جي‬
‫النظام‪ .‬هذا الحمل له ما يبرره عند عمل فرق تطوير متعددة يجب أن يكون منس ًقا ‪ ،‬عندما يكون النظام نظامًا حرجً ا ‪ ،‬وعندما يكون هناك‬
‫العديد من األنظمة المختلفة سيشارك األشخاص في صيانة البرنامج طوال حياته‪ .‬ومع ذلك ‪ ،‬عند تطبيق نهج التطوير هذا ذو الوزن‬
‫الثقيل والقائم على الخطة بالنسبة ألنظمة األعمال الصغيرة والمتوسطة الحجم ‪ ،‬فإن النفقات العامة المتضمنة كبيرة ج ًدا لدرجة أنها يهيمن‬
‫على عملية تطوير البرمجيات‪ .‬يتم إنفاق المزيد من الوقت على كيفية عمل النظام يجب تطويرها من تطوير البرنامج واختباره‪ .‬كنظام‬
‫تغيير المتطلبات ‪ ،‬إعادة العمل أمر ضروري ‪ ،‬ومن حيث المبدأ على األقل ‪ ،‬المواصفات ويجب أن يتغير التصميم مع البرنامج‪ .‬أدى‬
‫عدم الرضا عن هذه األساليب الثقيلة في هندسة البرمجيات إلى أ عدد مطوري البرمجيات في التسعينيات القتراح "أساليب رشيقة" جديدة‪.‬‬
‫والتوثيق‪ .‬تعتمد األساليب الرشيقة ‪ Agile 59‬هؤالء سمح لفريق التطوير بالتركيز على البرنامج نفسه بدالً من تصميمه ‪ 3.1‬أساليب‬
‫حيث عادة ما تتغير متطلبات ‪- opment‬عالميًا على نهج تدريجي في مواصفات وير ‪ ،‬التطوير ‪ ،‬والتسليم‪ .‬هم األنسب لتطوير التطبيق‬
‫النظام بسرعة أثناء التطوير عملية‪ .‬الغرض منها هو تقديم برامج العمل بسرعة للعمالء الذين يمكنهم ذلك ثم اقتراح متطلبات جديدة‬
‫النظام اإللكتروني‪ -‬تيم‪ .‬إنهم يهدفون إلى تقليص بيروقراطية العمليات من خالل ‪ th‬ومتغيرة ليتم تضمينها في التكرارات الالحقة من‬
‫تجنب العمل المشكوك فيه قيمة طويلة األجل وإلغاء الوثائق التي ربما لن يتم استخدامها أب ًدا‪ .‬تنعكس الفلسفة الكامنة وراء األساليب‬
‫الرشيقة في البيان الرشيق الذي كان وافق عليه العديد من المطورين الرائدين لهذه األساليب‪ .‬ينص هذا البيان على ما يلي‪ :‬نحن نكشف‬
‫النقاب عن طرق أفضل لتطوير البرامج من خالل القيام بذلك والمساعدة اآلخرون يفعلون ذلك‪ .‬من خالل هذا العمل وصلنا إلى قيمة‪:‬‬
‫األفراد والتفاعالت على العمليات واألدوات تعمل البرامج على وثائق شاملة تعاون العمالء على التفاوض على العقود وردا على تغيير‬
‫خالل اتباع خطة أي ‪ ،‬بينما توجد قيمة في العناصر الموجودة على اليمين ‪ ،‬فإننا نقدر العناصر الموجودة في غادر أكثر‪ .‬ربما تكون‬
‫والذي أصفه الح ًقا في هذا الفصل‪ .‬تشمل ‪ Beck ، 2000) ،‬؛‪ (Beck، 1999‬أفضل طريقة رشيقة معروفة هي البرمجة المتطرفة‬
‫كوكبيرن ‪ Schwaber and Beedle، 2001)، Crystal (،‬؛‪ Schwaber، 2004‬؛‪ (Cohn، 2009‬األساليب الرشيقة األخرى سكرم‬
‫‪ Stapleton ،‬؛ ‪ ، DSDM (Stapleton ، 1997‬تطوير البرمجيات‪ W‬التكيفية (هايسميث‪ 2001) ، )2000 ، W‬؛ كوكبيرن ‪2004 ،‬‬
‫والتطوير المدفوع بالميزات (بالمر وفيلسينج ‪ .) 2002 ،‬أدى نجاح هذه األساليب إلى بعض التكامل مع أساليب تطوير تقليدية ‪2003) ،‬‬
‫والتشكيالت الرشيقة لـ العملية )‪ (Ambler and Jeffries، 2002‬تعتمد على نمذجة النظام ‪ ،‬مما يؤدي إلى مفهوم النمذجة الرشيقة‬
‫‪ ، opment‬العقالنية الموحدة (الرمان ‪ .)2002 ،‬على الرغم من أن هذه األساليب الرشيقة تستند جميعها‪ W‬إلى مفهوم التطور التدريجي‬
‫والتسليم ‪ ،‬يقترحون عمليات مختلفة لتحقيق ذلك‪ .‬ومع ذلك ‪ ،‬هم تشترك في مجموعة من المبادئ ‪ ،‬بنا ًء على البيان الرشيق ‪ ،‬وبالتالي‬
‫‪ ciples‬هناك الكثير من القواسم المشتركة‪ .‬هذه المبادئ موضحة في الشكل ‪ .3.1‬تعمل طرق رشيقة مختلفة على إنشاء هذه األساسيات‬
‫بطرق مختلفة وليس لدي مساحة‪ W‬لمناقشة‪ W‬جميع األساليب الرشيقة‪ .‬بدال من ذلك أنا ركز على طريقتين من أكثر الطرق استخدامًا‪ :‬البرمجة‬
‫جدا في بعض أنواع تطوير النظام‪ .1 :‬تطوير المنتج حيث‬ ‫المتطرفة (القسم ‪ )3.3‬و سكرم (القسم ‪ .)3.4‬كانت األساليب الرشيقة ناجحة ً‬
‫تقوم شركة برمجيات بتطوير مشروع صغير أو منتج متوسط الحجم للبيع‪ .2 .‬تطوير نظام مخصص داخل منظمة ‪ ،‬حيث يوجد توافق‬
‫واضح التخفيف من العميل للمشاركة في عملية التطوير و ‪ 60‬الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة كما أناقش في القسم األخير من هذا‬
‫الفصل ‪ ،‬نجح نجاح األساليب الرشيقة يعني أن هناك الكثير من االهتمام باستخدام هذه األساليب ألنواع أخرى من البرامج تطوير‪ .‬ومع‬
‫ذلك ‪ ،‬نظرً ا لتركيزهم على الفرق الصغيرة والمتكاملة بإحكام ‪ ،‬هناك مشاكل في توسيع نطاقها إلى أنظمة كبيرة‪ .‬كانت هناك أيضًا‬
‫تجربة‪ -‬إشارات في استخدام األساليب الرشيقة لهندسة النظم الحرجة (دروبنا وآخرون ‪ .)2004 ،‬ومع ذلك ‪ ،‬بسبب الحاجة إلى تحليل‬
‫األمن والسالمة واالعتمادية في األنظمة الحرجة ‪ ،‬تتطلب األساليب الرشيقة تعديالت كبيرة قبل أن تكون كذلك تستخدم بشكل روتيني‬
‫لهندسة النظم الحرجة‪ .‬من الناحية العملية ‪ ،‬يصعب أحيا ًن ا تحديد المبادئ التي تقوم عليها األساليب الرشيقة يدرك‪ .1 :‬على الرغم من أن‬
‫فكرة مشاركة العمالء‪ W‬في عملية التنمية هي واحد جذاب ‪ ،‬يعتمد نجاحه على وجود عميل لديه الرغبة والقدرة لقضاء الوقت مع فريق‬
‫التطوير ومن يمكنه تمثيل النظام بأكمله المالكون‪ .‬في كثير من األحيان ‪ ،‬يخضع ممثلو العمالء إلى عروض أخرى أكيد وال تستطيع‬
‫المشاركة بشكل كامل في تطوير البرمجيات‪ . 2 .‬أعضاء الفريق الفرديين قد ال يكون لديهم شخصيات مناسبة للمكثفة المشاركة‪ W‬التي تعتبر‬
‫نموذجية لألساليب الرشيقة ‪ ،‬وبالتالي ال تتفاعل معها‪ W‬بشكل جيد أعضاء الفريق اآلخرين‪ .3 .‬قد يكون تحديد أولويات التغييرات أمرً ا بالغ‬
‫الصعوبة ‪ ،‬ال سيما في األنظمة التي تتطلب ذلك هناك العديد من أصحاب المصلحة‪ .‬عاد ًة ما يعطي كل صاحب مصلحة أولوية مختلفة‪-‬‬
‫روابط للتغييرات المختلفة‪ .4 .‬يتطلب الحفاظ على البساطة عمالً إضافيا ً‪ .‬تحت ضغط التسليم الجداول الزمنية ‪ ،‬قد ال يكون لدى أعضاء‬
‫طرق وصف المبدأ مشاركة العمالء يجب أن يشارك العمالء‬ ‫الفريق الوقت لتنفيذ النظام المرغوب فيه التبسيط‪ .‬الشكل ‪ 3.1‬مبادئ رشاقة ُ‬
‫عن كثب في جميع مراحل عملية التطوير‪ .‬دورهم هو توفير وتحديد أولويات متطلبات النظام الجديدة وتقييمها تكرارات النظام‪ .‬التسليم‬
‫التزايدي تم تطوير البرنامج بزيادات مع تحديد العميل لـ المتطلبات التي سيتم تضمينها في كل زيادة‪ .‬الناس ال يعالجون يجب التعرف‬
‫على مهارات فريق التطوير واستغاللها‪ .‬فريق يجب ترك األعضاء لتطوير طرقهم الخاصة في العمل بدون عمليات إلزامية‪ .‬تبني التغيير‬
‫توقع أن تتغير متطلبات النظام ‪ ،‬لذا صمم النظام وف ًقا لذلك استيعاب‪ W‬هذه التغييرات‪ .‬حافظ على البساطة ركز على البساطة في كل من‬
‫البرامج التي يتم تطويرها وفي عمليات التطوير‪ .‬حيثما أمكن ‪ ،‬اعمل بنشاط إلزالة التعقيد ‪ 3.1‬طرق رشيقة ‪ .5 61‬لقد أمضت العديد‬
‫من المنظمات ‪ ،‬وخاصة الشركات‪ W‬الكبيرة ‪ ،‬سنوات في التغيير ثقافتهم بحيث يتم تحديد العمليات واتباعها‪ .‬من الصعب عليهم أن يفعلوا‬
‫ذلك االنتقال إلى نموذج عمل تكون فيه العمليات غير رسمية ومحددة من قبل التنمية‪ -‬فرق العمليات‪ .‬مشكلة أخرى غير تقنية ‪ -‬وهي‬
‫عضوا خارجيًا‬ ‫ً‬ ‫لتطوير النظام‪ .‬عادة ما تكون ‪- ization‬مشكلة عامة مع التزايدية التطوير والتسليم ‪ -‬يحدث عندما يستخدم عميل النظام‬
‫وثيقة متطلبات البرامج جز ًء ا من العقد بين العميل والمورد‪ .‬ألن المواصفات المتزايدة الكاتيون متأصل في األساليب الرشيقة ‪ ،‬كتابة‬
‫العقود لهذا النوع من التطوير قد يكون صعبًا‪ .‬وبالتالي ‪ ،‬يجب أن تعتمد األساليب الرشيقة على العقود التي يدفع فيها العميل للوقت الالزم‬
‫لتطوير النظام بدالً من تطوير التخصص‪ -‬مجموعة محددة من المتطلبات‪ .‬طالما سارت األمور على ما يرام ‪ ،‬فإن هذا يفيد كل من العميل‬
‫و المطور‪ .‬ومع ذلك ‪ ،‬إذا ظهرت مشاكل فقد تكون هناك خالفات‪ W‬صعبة حولها على من يقع اللوم ومن يجب أن يدفع مقابل الوقت‬
‫اإلضافي والموارد المطلوبة حل المشاكل‪ .‬معظم الكتب واألوراق التي تصف األساليب الرشيقة والتجارب مع أجايل طرق الحديث عن‬
‫استخدام هذه األساليب لتطوير أنظمة جديدة‪ .‬ومع ذلك ‪ ،‬كما أوضحت في الفصل التاسع ‪ ،‬هناك قدر هائل من الجهد في هندسة البرمجيات‬
‫يدخل في صيانة وتطوير أنظمة البرمجيات الحالية‪ .‬ال يوجد سوى عدد قليل من تقارير الخبرة حول استخدام األساليب الرشيقة لصيانة‬
‫البرامج‪ -‬نانس (بول وهيسمان ‪ .) 2001 ،‬هناك سؤاالن يجب أن يؤخذ في االعتبار‪ -‬تم تقديمه عند التفكير في األساليب الرشيقة‬
‫والصيانة‪ . 1 :‬هي األنظمة التي تم تطويرها باستخدام نهج رشيق قابلة للصيانة ‪ ،‬بالنظر إلى التركيز في عملية التطوير لتقليل الوثائق‬
‫استجابة إلى طلبات التغيير تومر؟ من المفترض أن يصف‬ ‫ً‬ ‫الرسمية؟ ‪ . 2‬هل يمكن استخدام األساليب الرشيقة بشكل فعال لتطوير نظام‬
‫الرسمي‪ -‬غالبًا ما ال ‪ docu‬التوثيق الرسمي النظام وبالتالي يجعله أسهل للناسه تغيير النظام للفهم‪ .‬في الممارسة‪ W‬العملية ‪ ،‬ومع ذلك ‪ ،‬فإن‬
‫يتم تحديث التوجيه وبالتالي ال يعكس البرنامج بدقة شفرة‪ .‬لهذا السبب ‪ ،‬يجادل المتحمسون لألساليب الرشيقة بأنها مضيعة للوقت اكتب‬
‫هذه الوثائق وأن مفتاح تنفيذ البرامج القابلة للصيانة هو إلنتاج كود عالي الجودة وقابل للقراءة‪ .‬لذلك تؤكد الممارسات الرشيقة على أهمية‬
‫كتابة كود جيد التنظيم واستثمار الجهود في تحسين الكود‪ -‬منة‪ .‬لذلك ‪ ،‬ال ينبغي أن يكون نقص الوثائق مشكلة في الصيانة أنظمة تم‬
‫تطويرها باستخدام نهج رشيق‪ .‬ومع ذلك ‪ ،‬فإن تجربتي في صيانة النظام تشير إلى أن المستند األساسي هي وثيقة متطلبات النظام ‪ ،‬والتي‬
‫تخبر مهندس البرمجيات بملف من المفترض أن يفعله النظام‪ .‬بدون هذه المعرفة ‪ ،‬من الصعب تقييم التأثير من تغييرات النظام المقترحة‪.‬‬
‫تجمع العديد من األساليب الرشيقة المتطلبات بشكل غير رسمي وبشكل تدريجي وال تنشئ وثيقة متطلبات متماسكة‪ .‬في هذا الفصل ‪62‬‬
‫تطوير البرمجيات‪ W‬الرشيقة فيما يتعلق ‪ ،‬فإن استخدام األساليب الرشيقة من المرجح أن يؤدي إلى صيانة النظام الح ًقا أكثر صعوبة وتكلفة‪.‬‬
‫من المرجح أن تكون الممارسات الرشيقة المستخدمة في عملية الصيانة نفسها فعالة ‪ ،‬سواء تم استخدام نهج رشيق لتطوير النظام أم ال‪.‬‬
‫تدريجي التسليم والتصميم للتغيير والحفاظ على البساطة كلها منطقية عند استخدام البرنامج يتم تغييره‪ .‬في الواقع ‪ ،‬يمكنك التفكير في‬
‫عملية التطوير الرشيقة كعملية تطور البرمجيات‪ .‬ومع ذلك ‪ ،‬من المرجح أن تكون الصعوبة الرئيسية بعد تسليم البرنامج هي الحفاظ على‬
‫تومرز تشارك في هذه العملية‪ .‬على الرغم من أن العميل قد يكون قادرً ا على تبرير كامل‪ -‬وقت إشراك ممثل أثناء تطوير النظام ‪ ،‬وهذا‬
‫أقل احتماال أثناء الصيانة حيث ال تكون التغييرات مستمرة‪ .‬ممثلو العمالء هم من المحتمل أن يفقد االهتمام بالنظام‪ .‬لذلك ‪ ،‬من المحتمل‬
‫مثل مقترحات التغيير ‪ ،‬التي تمت مناقشتها‪ W‬في الفصل ‪ 25‬متطلبات النظام الجديدة‪ nisms ، .‬أن الميكا البديلة‪ -‬سيكون مطلوبا ً إنشاء‬
‫المشكلة األخرى التي من المحتمل أن تنشأ هي الحفاظ على استمرارية التطوير‪ -‬فريق منة‪ .‬تعتمد األساليب الرشيقة على أعضاء الفريق‬
‫الذين يفهمون جوانب النظام دون الحاجة إلى الرجوع إلى الوثائق‪ .‬إذا كان فريق التطوير رشيقة تفكك ‪ ،‬ثم تضيع هذه المعرفة الضمنية‬
‫ويصعب على أعضاء الفريق الجدد‪ -‬لبناء نفس الفهم للنظام ومكوناته‪ .‬كان أنصار األساليب الرشيقة إنجيليين في الترويج الستخدامها و‬
‫تميل إلى التغاضي عن عيوبها‪ .‬وقد أدى هذا إلى تطرف مماثل االستجابة ‪ ،‬التي ‪ ،‬في رأيي ‪ ،‬تضخيم المشاكل مع هذا النهج‬
‫يسلطان الضوء )‪ Boehm (DeMarco and Boehm، 2002‬و ‪ DeMarco‬نقاد أكثر منطقية مثل ‪).‬روزنبرغ ‪(Stephens 2003 ،‬‬
‫على مزايا وعيوب طرق رشيقة‪ .‬يقترحون نهجً ا هجي ًن ا حيث يتم دمج األساليب الرشيقة قد تكون بعض األساليب من التطوير المبني على‬
‫الخطة هي أفضل طريقة للمضي قدمًا‪ 3.2 .‬التنمية المدفوعة بالخطة ورشيقة المناهج الرشيقة لتطوير البرمجيات تعتبر التصميم والتنفيذ‬
‫األنشطة المركزية في عملية البرمجيات‪ .‬أنها تدمج أنشطة أخرى ‪ ،‬مثل متطلبات االستنباط واالختبار ‪ ،‬في التصميم والتنفيذ‪ .‬على‬
‫النقيض من ذلك ‪ ،‬أ النهج القائم على الخطة لهندسة البرمجيات يحدد مراحل منفصلة في البرنامج عملية وير مع المخرجات‪ W‬المرتبطة‬
‫بكل مرحلة‪ .‬مخرجات‪ W‬مرحلة واحدة هي تستخدم كأساس‪ W‬لتخطيطبعد نشاط العملية‪ .‬يوضح الشكل ‪ 3.2‬العرض تداخالت بين المناهج‬
 ‫المستندة إلى الخطة والرشاقة لمواصفات النظام‪ .‬في النهج القائم على الخطة ‪ ،‬يحدث التكرار ضمن األنشطة ذات المستند الرسمي‪-‬‬
‫تستخدم للتواصل بين مراحل العملية‪ .‬على سبيل المثال ‪ ،‬تتطلب سوف تتطور اإلشارات ‪ ،‬وفي النهاية ‪ ،‬سيتم إنتاج مواصفات المتطلبات‪.‬‬
‫يعد هذا بعد ذلك مدخالً في عملية التصميم والتنفيذ‪ .‬في نهج رشيق ‪ ،‬يحدث التكرار عبر األنشطة‪ .‬لذلك ‪ ،‬المتطلبات والتصميم ‪٣.٢‬‬
‫تطوير رشيق ومدفوع بالخطة ‪ 63‬يمكن أن تدعم عملية البرامج المدفوعة بالخطة التطوير التدريجي وتقديم‪ -‬إيري‪ .‬من الممكن تمامًا‬
‫تخصيص المتطلبات وتخطيط التصميم والتطوير‪ -‬مرحلة منة كسلسلة من الزيادات‪ .‬ال تركز العملية الرشيقة على الكود حتمًا وقد ينتج‬
‫عنه بعض وثائق التصميم‪ .‬كما أناقش في القسم التالي‪ -‬نشوئها ‪ ،‬قد يقرر فريق التطوير السريع تضمين "زيادة" في التوثيق ‪ ،‬حيث ‪ ،‬بدالً‬
‫من إنتاج نسخة جديدة من النظام ‪ ،‬يقوم الفريق بإنتاج النظام توثيق‪ .‬في الواقع ‪ ،‬تتضمن معظم مشاريع البرامج ممارسات‪ W‬من خطة‬
‫مدفوعة ورشيقة اقتراب‪ .‬التخاذ قرار بشأن التوازن بين النهج القائم على الخطة والنهج الرشيق ‪ ،‬عليك اإلجابة على مجموعة من األسئلة‬
‫الفنية والبشرية والتنظيمية‪ . 1 :‬هل من المهم أن يكون لديك مواصفات وتصميم مفصالن للغاية قبل االنتقال إلى تطبيق؟ إذا كان األمر‬
‫كذلك ‪ ،‬فربما تحتاج إلى استخدام نهج مبني على الخطة‪ . 2 .‬عبارة عن إستراتيجية تسليم تدريجي ‪ ،‬حيث تقوم بتسليم البرنامج للعمالء‪W‬‬
‫والحصول على ردود فعل سريعة منهم ‪ ،‬واقعية؟ إذا كان األمر كذلك ‪ ،‬ففكر في استخدام األساليب الرشيقة‪ .3 .‬ما هو حجم النظام الذي‬
‫عندما يمكن تطوير النظام مع فريق صغير قادر على ذلك التواصل بشكل غير ‪- tive‬يتم تطويره؟ الطرق الرشيقة هي األكثر فعالية‬
‫رسمي‪ .‬قد ال يكون هذا ممك ًن ا لألنظمة الكبيرة التي تتطلب فرق تطوير أكبر لذا قد يتعين استخدام نهج يحركها خطة‪ .4 .‬ما هو نوع‬
‫النظام الذي يتم تطويره؟ األنظمة التي تتطلب الكثير من التحليل قبل التنفيذ (على سبيل المثال ‪ ،‬يتطلب نظام الوقت الفعلي مع توقيت‬
‫معقد‪ -‬إشارات) عاد ًة إلى تصميم مفصل إلى حد ما إلجراء هذا التحليل‪ .‬خطة‪ -‬قد يكون النهج الدافع هو األفضل في تلك الظروف‪ .5 .‬ما‬
‫هو العمر المتوقع للنظام؟ قد تتطلب أنظمة العمر الطويل المزيد وثائق التصميم لإلبالغ عن النوايا األصلية للنظام متطلبات تخصيص‬
‫متطلبات هندسة تصميم و تطبيق تغيير المتطلبات الطلبات التنمية القائمة على الخطة تطوير البرامج بتقنية أجيل متطلبات هندسة تصميم‬
‫و تطبيق الشكل ‪ 3.2‬خطة مدفوعة والمواصفات الرشيقة ‪ 64‬الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة المطورين لفريق الدعم‪ .‬ومع ذلك ‪،‬‬
‫فإن مؤيدي األساليب الرشيقة محقون يجادل بأن الوثائق ال يتم تحديثها في كثير من األحيان وأنها ليست كثيرة تستخدم لصيانة النظام على‬
‫المدى الطويل‪ .6 .‬ما هي التقنيات المتاحة لدعم تطوير النظام؟ طرق رشيقة غالبًا ما تعتمد على أدوات جيدة لتتبع التصميم المتطور‪ .‬إذا‬
‫ال يحتوي على أدوات جيدة لتصور البرنامج‪ -‬نشوئها وتحليلها ‪ ،‬ثم قد تكون هناك حاجة إلى مزيد من ‪ IDE‬كنت تتطور‪ -‬نظام يستخدم‬
‫وثائق التصميم‪ . 7 .‬كيف يتم تنظيم فريق التطوير؟ إذا تم توزيع فريق التطوير أو إذا تم االستعانة بمصادر خارجية لجزء من التطوير ‪،‬‬
‫فقد تحتاج إلى التطوير وثائق التصميم للتواصل عبر فرق التطوير‪ .‬يمكنك بحاجة إلى التخطيط المسبقه ما هذه‪ .8 .‬هل هناك قضايا ثقافية‬
‫قد تؤثر على تطوير النظام؟ تقليدي المنظمات الهندسية لديها ثقافة التطوير المبني على الخطة ‪ ،‬كما هي القاعدة في الهندسة‪ .‬يتطلب هذا‬
‫عاد ًة وثائق تصميم واسعة النطاق ‪ ،‬بدالً من المعرفة غير الرسمية المستخدمة في العمليات الرشيقة‪ .9 .‬ما مدى جودة المصممين‬
‫والمبرمجين في فريق التطوير؟ إنها جادل أحيا ًن ا بأن األساليب الرشيقة تتطلب مستويات مهارة أعلى من القائمة على الخطة األساليب‬
‫التي يقوم فيها المبرمجون ببساطة بترجمة التصميم التفصيلي إلى رمز‪ .‬إذا كان لديك فريق بمستويات مهارة منخفضة نسبيًا ‪ ،‬فقد تحتاج‬
‫إلى استخدام األفضل الناس لتطوير التصميم ‪ ،‬مع اآلخرين المسؤولين عن البرمجة‪ .10 .‬هل النظام خاضع للتنظيم الخارجي؟ إذا كان‬
‫توافق على البرنامج هذا أمر ]‪ [FAA‬على سبيل المثال ‪ ،‬هيئة الطيران الفيدرالية( النظام يجب أن تتم الموافقة عليه من قبل منظم خارجي‬
‫فمن المحتمل أن تكون مطلوبًا إلنتاج وثائق مفصلة كجزء من حالة سالمة النظام‪ .‬في الواقع ‪ ،‬مسألة ما إذا ‪) ،‬بالغ األهمية لتشغيل طائرة‬
‫كان يمكن تصنيف المشروع على أنه موجه للخطة أو رشيق هو ليس مهما‪ W‬جدا‪ .‬في نهاية المطاف ‪ ،‬الشاغل األساسي لمشتري نظام‬
‫البرمجيات هو ما إذا كان لديهم نظام برمجيات قابل للتنفيذ يلبي احتياجاتهم أم ال يفعل أشياء مفيدة للمستخدم الفردي أو المنظمة‪ .‬في‬
‫تبنت الشركات التي تدعي أنها استخدمت أساليب رشيقة بعض الممارسات‪ W‬الرشيقة و قد دمجوا هذه ‪ com-‬الممارسة‪ W‬العملية ‪ ،‬العديد من‬
‫هي أشهر البرامج وأكثرها استخدامًا على )‪ (XP‬مع العمليات التي تحركها الخطة‪ 3.3 .‬البرمجة المتطرفة ربما تكون البرمجة المتطرفة‬
‫االسم (‪ )2000‬ألن النهج كان تم تطويرها من خالل دفع الممارسات‪ W‬الجيدة المعترف بها ‪ ،‬مثل ‪ Beck‬نطاق واسع طرق رشيقة‪ .‬صاغ‬
‫قد يتم تطوير عدة إصدارات جديدة من النظام تم تشغيلها ‪ XP ،‬التطوير التكراري ‪ ،‬إلى مستويات "المتطرفة"‪ .‬على سبيل المثال ‪ ،‬في‬
‫بواسطة مبرمجين مختلفين ‪ ،‬وتم دمجها‪ W‬واختبارها في يوم واحد ‪ 3.3.‬البرمجة المتطرفة ‪ 65‬في البرمجة المتطرفة ‪ ،‬يتم التعبير عن‬
‫المتطلبات في صورة سيناريوهات (تسمى المستخدم‪ W‬القصص) ‪ ،‬والتي يتم تنفيذها مباشرة كسلسلة من المهام‪ .‬يعمل المبرمجون في أزواج‬
‫وتطوير االختبارات لكل مهمة قبل كتابة الكود‪ .‬يجب أن تكون جميع االختبارات ناجحة‪ -‬يتم تنفيذه بشكل متوقف عند دمج رمز جديد في‬
‫لإلنتاج زيادة في النظام الذي يتم تطويره‪ .‬تتضمن ‪ XP‬النظام‪ .‬هناك وقت قصير فجوة بين إصدارات النظام‪ .‬يوضح الشكل ‪ 3.3‬عملية‬
‫البرمجة المتطرفة عد ًدا من الممارسات‪ ، W‬ملخصة في الشكل ‪ ، 3.4‬التي تعكس مبادئ األساليب الرشيقة‪ .1 :‬يتم دعم التطوير المتزايد‬
‫من خالل اإلصدارات الصغيرة والمتكررة من نظام‪ .‬تعتمد المتطلبات على قصص أو سيناريوهات العمالء البسيطة تستخدم كأساس‪W‬‬
‫لتقرير الوظيفة التي يجب تضمينها في النظام زيادة راتب‪ .2 .‬يتم دعم مشاركة العمالء‪ W‬من خالل المشاركة المستمرة لـ العميل في فريق‬
‫التطوير‪ .‬يشارك ممثل العميل في التطوير وهو مسؤول عن تحديد اختبارات القبول للنظام‪ .3 .‬يتم دعم األشخاص ‪ ،‬وليس العملية ‪ ،‬من‬
‫خالل البرمجة الزوجية ‪ ،‬المالك الجماعي‪ -‬سفينة من رمز النظام ‪ ،‬وعملية التنمية المستدامة التي ال تتطلب ساعات‪ W‬عمل طويلة للغاية‪.‬‬
‫‪ . 4‬يتم تبني التغيير من خالل إصدارات النظام المنتظمة للعمالء ‪ ،‬االختبار أوالً التطوير وإعادة البناء لتجنب انحطاط الكود والتكامل‬
 ‫المستمر وظائف جديدة‪ . 5 .‬يتم دعم الحفاظ على البساطة من خالل إعادة البناء المستمر التي تعمل على تحسين الكود الجودة‬
‫يشارك العمالء بشكل وثيق في ‪ XP ،‬وبواسطةباستخدام‪ W‬تصميمات بسيطة ال تتوقع المستقبل دون داع تغييرات على النظام‪ .‬في عملية‬
‫التحديد وتحديد األولويات متطلبات النظام‪ .‬لم يتم تحديد المتطلبات كقوائم للنظام المطلوب المهام‪ .‬بدالً من ذلك ‪ ،‬يكون عميل النظام جزءًا‬
‫من فريق التطوير ويناقش سيناريوهات مع أعضاء الفريق اآلخرين‪ .‬م ًعا ‪ ،‬يطورون "بطاقة قصة" تغلف‪ -‬يحسب احتياجات العميل‪.‬‬
‫في إصدار مستقبلي للبرنامج‪ .‬مثال على بطاقة قصة للعقلية انفصال من ‪- nario‬ويهدف فريق التطوير بعد ذلك إلى تنفيذ هذا المجلس‬
‫القصص إلى المهام اختر المستخدم قصص عن هذا يطلق إصدار الخطة يطلق برمجة يقيم نظام يطور‪ /‬دمج‪ /‬اختبار البرمجيات الشكل‬
‫‪ 3.3‬الحد األقصى إصدار البرمجة دورة ‪ 66‬الفصل ‪ 3‬تطوير البرمجيات الرشيقة يظهر نظام إدارة مرضى الرعاية الصحية في الشكل‬
‫أو "التخطيط لعبة'‪ .3.5 XP .‬هذا قصير وصف لسيناريو وصف الدواء للمريض‪ .‬بطاقات‪ W‬القصة هي المدخالت الرئيسية لعملية تخطيط‬
‫بمجرد تطوير بطاقات القصة ‪ ،‬يقوم فريق التطوير بكسرها إلى المهام (الشكل ‪ )3.6‬وتقدير الجهد والموارد الالزمة لتنفيذ‪ -‬إرشاد كل‬
‫مهمة‪ .‬يتضمن هذا عاد ًة مناقشات مع العميل لتحسين متطلبات‪ .‬ثم يعطي العميل األولوية للقصص للتنفيذ واالختيار تلك القصص التي‬
‫يمكن استخدامها على الفور لتقديم دعم تجاري مفيد‪ .‬ال النية هي تحديد الوظائف المفيدة التي يمكن تنفيذها في حوالي اثنين أسابيع ‪ ،‬عندما‬
‫يتم توفير اإلصدار التالي من النظام للعميل‪ .‬بالطبع ‪ ،‬مع تغير المتطلبات ‪ ،‬تتغير القصص غير المنفذة أو قد تتغير مهملة‪ .‬إذا كانت‬
‫التغييرات مطلوبة لنظام تم تسليمه بالفعل ‪ ،‬فهو جديد يتم تطوير بطاقات القصة ومرة أخرى ‪ ،‬يقرر العميل ما إذا كانت هذه التغييرات‬
‫يجب أن يكون لها األولوية على الوظائف الجديدة‪ .‬المبدأ أو الممارسة‪ W‬الوصف يتم تسجيل متطلبات التخطيط اإلضافية في بطاقات‪W‬‬
‫القصص والقصص التي سيتم تضمينها في ملف يتم تحديد اإلصدار حسب الوقت المتاح وأولويتها النسبية‪ .‬ال يقسم المطورون هذه‬
‫القصص إلى "مهام" التطوير‪ .‬انظر الشكلين ‪ 3.5‬و ‪ . 3.6‬اإلصدارات الصغيرة تم تطوير الحد األدنى من مجموعة الوظائف المفيدة التي‬
‫توفر قيمة لألعمال أوالً ‪ .‬إصدارات النظام متكررة وتضيف وظائف بشكل متزايد إلى اإلصدار األول‪ .‬تصميم بسيط يتم تنفيذ التصميم‬
‫الكافي لتلبية المتطلبات الحالية وليس أكثر‪ .‬تطوير االختبار أوالً يتم استخدام إطار عمل اختبار الوحدة اآللي لكتابة االختبارات لقطعة‬
‫جديدة من قبل تنفيذ هذه الوظيفة نفسها‪ .‬إعادة بناء الكود من المتوقع أن يقوم جميع المطورين بإعادة بناء الكود بشكل مستمر في أسرع‬
‫بسيطا وقاباًل للصيانة‪ .‬يعمل مطورو البرمجة الزوجية في‬ ‫ً‬ ‫وقت ممكن تم العثور على تحسينات التعليمات‪ W‬البرمجية‪ .‬هذا يجعل الكود‬
‫أزواج ‪ ،‬ويتحققون من عمل بعضهم البعض ويقدمون الدعم للقيام بعمل جيد دائمًا‪ .‬الملكية الجماعية أزواج المطورين تعمل في جميع‬
‫مجاالت النظام ‪ ،‬بحيث ال توجد جزر تطوير الخبرة وجميع المطورين يتحملون المسؤولية عن جميع التعليمات البرمجية‪ .‬يمكن ألي‬
‫شخص تغيير أي شيء‪ .‬التكامل المستمر بمجرد اكتمال العمل على المهمة‪ ، W‬يتم دمجها‪ W‬في النظام بأكمله‪ .‬بعد أي تكامل من هذا القبيل ‪،‬‬
‫يجب أن تمر جميع اختبارات الوحدة في النظام‪ .‬وتيرة مستدامة كميات‪ W‬كبيرة من العمل اإلضافي ال تعتبر مقبولة ألن التأثير الصافي هو‬
‫في كثير من األحيان لتقليل جودة الكود ومتوسط ً‬
‫ثالث ام اإلنتاجية العميل في الموقع يجب أن يكون ممثل المستخدم النهائي للنظام (العميل)‬
‫في برمجة متطرفة العملية ‪ ،‬العميل عضو في فريق التطوير وهو مسؤول لجلب متطلبات النظام ‪ XP.‬متاح بدوام كامل الستخدام فريق‬
‫إلى الفريق للتنفيذ‪ .‬الشكل ‪ 3.4‬المتطرفة ممارسات البرمجة ‪ 3.3‬البرمجة المتطرفة ‪ 67‬في بعض األحيان ‪ ،‬أثناء لعبة التخطيط ‪ ،‬أسئلة‬
‫ال يمكن اإلجابة عليها بسهولة يأتي إلى النور ويلزم عمل إضافي الستكشاف الحلول الممكنة‪ .‬الفريق قد تنفذ بعض النماذج األولية أو‬
‫هذا هو "ارتفاع" ‪ ،‬زيادة حيث ال يتم إجراء البرمجة‪ .‬قد يكون هناك أيضًا ‪ XP ،‬التطوير التجريبي لفهم المشكلة و حل‪ .‬في مصطلحات‬
‫"ارتفاعات" لتصميم بنية النظام أو لتطوير النظام توثيق‪ .‬تأخذ البرمجة المتطرفة نهجً ا "متطر ًفا" للتطوير التدريجي‪ .‬قد يتم إنشاء‪W‬‬
‫إصدارات جديدة من البرنامج عدة مرات في اليوم واإلصدارات يتم تسليمها للعمالء كل أسبوعين تقريبًا‪ .‬المواعيد النهائية لإلفراج ليست‬
‫أبد ا انزلق؛ إذا كانت هناك مشاكل في التنمية ‪ ،‬يتم استشارة العميل وعمل‪ -‬تتم إزالة‬ ‫من اإلصدار المخطط له‪ .‬عندما يقوم المبرمج ‪ً ality‬‬
‫ببناء النظام إلنشاء إصدار جديد ‪ ،‬يجب عليه أو عليها تشغيله جميع االختبارات اآللية الموجودة وكذلك اختبارات الوظائف الجديدة‪.‬‬
‫الجديد ال يتم قبول إنشاء البرنامج إال إذا تم تنفيذ جميع االختبارات بنجاح‪ .‬هذا بعد ذلك يصبح أساس التكرار التالي للنظام‪ .‬من المبادئ‬
‫األساسية لهندسة البرمجيات التقليدية أنه يجب عليك ذلك التصميم من أجل التغيير‪ .‬بمعنى ‪ ،‬يجب أن تتوقع التغييرات المستقبلية للبرنامج‬
‫و تصميمه بحيث يمكن تنفيذ هذه التغييرات بسهولة‪ .‬البرمجة المتطرفة‪ ،‬ومع ذلك ‪ ،‬فقد تجاهل هذا المبدأ على أساس أن التصميم من أجل‬
‫التغيير غالبًا ما يكون جهد ضائع‪ .‬ال يستحق األمر قضاء‪ W‬بعض الوقت في إضافة عمومية إلى برنامج للتعامل معه يتغير‪ .‬غالبًا ما ال‬
‫يقبل ذلك ستحدث التغييرات وإعادة ‪ XP‬تتحقق التغييرات المتوقعة وهي مختلفة تما ًما قد يتم بالفعل إجراء طلبات التغيير‪ .‬لذلك ‪ ،‬فإن نهج‬
‫تنظيم البرنامج عند حدوث هذه التغييرات بالفعل‪ .‬الشكل ‪ 3.5‬أ "وصف الدواء" قصة‪ .‬كيت طبيبة ترغب في وصف دواء لمريض يتردد‬
‫على العيادة‪ .‬سجل المريض معروض بالفعل على جهاز الكمبيوتر الخاص بها لذا تنقر على مجال الدواء ويمكنه تحديد الدواء الحالي "أو"‬
‫دواء جديد "أو" كتيب الوصفات "‪ .‬إذا اختارت "الدواء الحالي" ‪ ،‬يطلب منها النظام فحص الجرعة‪ .‬لو هي تريد تغيير الجرعة ‪ ،‬تدخل‬
‫الجرعة ثم تؤكد الوصفة الطبية‪ .‬إذا اختارت "دواء جديد" ‪ ،‬يفترض النظام أنها تعرف أيها دواء لوصف‪ .‬تقوم بكتابة األحرف القليلة‬
‫األولى من اسم الدواء‪ .‬النظام يعرض قائمة األدوية الممكنة بدءا من هذه الحروف‪ .‬اختارت المطلوب الدواء ويستجيب النظام عن طريق‬
‫مطالبتهم بالتأكد من أن الدواء المحدد هو الصحيح‪ .‬تدخل الجرعة ثم تؤكد الوصفة‪ .‬إذا اختارت "كتيب الوصفات" ‪ ،‬فسيعرض النظام‬
‫مربع بحث للموافق عليه كتيب الوصفات‪ .‬يمكنها بعد ذلك البحث عن الدواء المطلوب‪ .‬تختار الدواء وتطلب منه للتأكد من صحة الدواء‪.‬‬
‫تدخل الجرعة ثم تؤكد روشتة‪ .‬يتحقق النظام دائ ًم ا من أن الجرعة تقع ضمن النطاق المعتمد‪ .‬إذا لم يكن األمر كذلك ‪ ،‬كيت يطلب تغيير‬
‫الجرعة‪ .‬بعد أن أكدت كيت الوصفة الطبية ‪ ،‬سيتم عرضها للتحقق منها‪ .‬هي اما ينقر على "موافق" أو "تغيير"‪ .‬لو هيينقر على‬
 ‫"موافق" ‪ ،‬يتم تسجيل الوصفة في المراجعة قاعدة البيانات‪ .‬إذا نقرت على "تغيير" ‪ ،‬فإنها تعيد الدخول في عملية "وصف الدواء"‪.‬‬
‫وصف الدواء ‪ 68‬الفصل الثالث تطوير البرمجيات الرشيقة هناك مشكلة عامة تتعلق بالتنمية المتزايدة وهي أنها تميل إلى تدهور هيكل‬
‫البرنامج ‪ ،‬لذلك تصبح التغييرات التي تطرأ على البرنامج أصعب وأصعب في التنفيذ‪ -‬منة‪ .‬بشكل أساسي ‪ ،‬يستمر التطوير من خالل‬
‫طرق خاصة ‪ inap- ،‬إيجاد حلول للمشاكل ‪ ،‬ونتيجة لذلك ‪ ،‬غالبًا ما يتم تكرار الرمز ‪ ،‬تتم إعادة استخدام أجزاء من البرنامج في‬
‫ويتدهور الهيكل العام عند إضافة رمز إلى النظام‪ .‬تعالج البرمجة المتطرفة هذه المشكلة من خالل اقتراح أن البرنامج يجب إعادة بنائها‬
‫باستمرار‪ .‬هذا يعني أن فريق البرمجة يبحث عنها التحسينات الممكنة للبرنامج وتنفيذها على الفور‪ .‬عندما يرى عضو الفريق التعليمات‪W‬‬
‫البرمجية التي يمكن تحسينها ‪ ،‬بل يقومون بإجراء هذه التحسينات في الحاالت التي ال توجد فيها حاجة فورية لهم‪ .‬أمثلة على إعادة بناء‬
‫ديون تتضمن إعادة تنظيم التسلسل الهرمي للفئة إلزالة الكود المكرر ‪ ،‬إعادة تسمية السمات‪ W‬والطرق وإعادة تسميتها ‪ ،‬واستبدال الكود بـ‬
‫تتضمن أدوات إلعادة البناء ‪ Eclipse (Carlson ، 2005) ،‬يستدعي األساليب المحددة في مكتبة البرنامج‪ .‬بيئات تطوير البرنامج ‪ ،‬مثل‬
‫والتي تبسط عملية إيجاد التبعيات بين أقسام الكود وإنشاء كود عالمي التعديالت‪ .‬من حيث المبدأ إذن ‪ ،‬يجب أن يكون البرنامج دائمًا سهل‬
‫الفهم والتغيير يتم تنفيذ قصص جديدة‪ .‬في الممارسة العملية ‪ ،‬هذا ليس هو الحال دائ ًم ا‪ .‬أحيانا ضغط التطوير يعني تأخر إعادة البناء ألن‬
‫الوقت مكرس لتنفيذ وظائف جديدة‪ .‬بعض الميزات والتغييرات الجديدة ال يمكن يمكن استيعابها بسهولة من خالل إعادة بناء ديون على‬
‫ال تستخدم أقصى الحدود ‪ XP‬مستوى الكود وتتطلب بنية النظام المراد تعديله‪ .‬من الناحية العملية ‪ ،‬العديد من الشركات التي تبنت‬
‫ممارسات البرمجة المدرجة في الشكل ‪ .3.4‬ينتقون ويختارون وف ًق ا لهم طرق العمل المحلية‪ .‬على سبيل المثال ‪ ،‬تجد بعض الشركات‪W‬‬
‫تعليمات البرمجة الزوجية‪ -‬فول‪ .‬يفضل البعض اآلخر استخدام البرمجة والمراجعات الفردية‪ .‬الستيعاب الفرق مستويات عالية من‬
‫المهارة ‪ ،‬ال يقوم بعض المبرمجين بإعادة البناء في أجزاء من النظام لم يتم تطويرها ‪ ،‬ويمكن استخدام المتطلبات التقليدية بدالً من‬
‫تستخدم حجمًا صغيرً ا اإلصدارات وتطوير االختبار أوالً ‪ XP‬المستخدم قصص‪ .‬ومع ذلك ‪ ،‬فإن معظم الشركات التي تبنت متغير‬
‫والتكامل المستمر‪ .‬الشكل ‪ 3.6‬أمثلة من بطاقات‪ W‬المهام لـ وصف الدواء‪ .‬المهمة ‪ :1‬تغيير جرعة الدواء الموصوف المهمة ‪ :2‬اختيار‬
‫الصيغ المهمة‪ : 3 W‬فحص الجرعة فحص الجرعة هو إجراء وقائي للتحقق من ذلك لم يصف الطبيب دوا ًء صغيرً ا بشكل خطير أو جرعة‬
‫كبيرة‪ .‬باستخدام معرف كتيب الوصفات السم الدواء العام ‪ ،‬ابحث في كتيب الوصفات واسترجع الموصى به الجرعة القصوى والدنيا‪.‬‬
‫تحقق من الجرعة الموصوفة مقابل الحد األدنى و أقصى‪ .‬إذا كان خارج النطاق ‪ ،‬فقم بإصدار خطأ رسالة تفيد بأن الجرعة مرتفعة ً‬
‫جدا‬
‫كما ناقشت‪ W‬في ‪ XP‬أو منخفضة ج ًد ا‪ .‬إذا كان ضمن النطاق ‪ ،‬فقم بتمكين الزر "تأكيد" ‪ 3.3.‬البرمجة القصوى ‪ 3.3.1 69‬االختبار في‬
‫مقدمة هذا الفصل ‪ ،‬أحد االختالفات‪ W‬المهمة بين التنمية المتزايدة والتنمية المدفوعة بالخطة على هذا النحو تم اختبار النظام‪ .‬مع التطوير‬
‫بعض ‪- quence ،‬التدريجي ‪ ،‬ال توجد مواصفات للنظام التي يمكن أن يستخدمها فريق اختبار خارجي لتطوير اختبارات النظام‪ .‬كسلعة‬
‫التطوير التدريجي له اختبار غير رسمي للغاية العملية ‪ ،‬بالمقارنة مع االختبار المبني على الخطة‪ .‬لتجنب بعض مشاكل ‪o‬األساليب ر‬
‫نهجً ا لالختبار يقلل فرص إدخال أخطاء غير مكتشفة ‪ XP‬أهمية اختبار البرنامج‪ .‬يتضمن ‪ XP‬االختبار والتحقق من صحة النظام ‪ ،‬يؤكد‬
‫هي‪ .1 :‬تطوير االختبار أوالً ‪ .2 ،‬تطوير االختبار اإلضافي من ‪ XP‬في اإلصدار الحالي من النظام‪ .‬الميزات الرئيسية لالختبار في‬
‫السيناريوهات ‪ .3 ،‬مشاركة المستخدم في تطوير االختبار والتحقق من صحته ‪ ،‬و ‪ .4‬استخدام أطر االختبار اآللي‪ .‬يعد تطوير االختبار‬
‫بدالً من كتابة بعض التعليمات البرمجية ثم كتابة االختبارات لذلك الرمز ‪ ،‬تكتب االختبارات أمامك ‪ XP.‬أوالً أحد أهم االبتكارات في‬
‫اكتب الكود‪ .‬هذا يعني أنه يمكنك إجراء االختبار أثناء كتابة التعليمات البرمجية و اكتشاف المشاكل أثناء التطوير‪ .‬تحدد اختبارات الكتابة‬
‫ضم ًنا كالً من الواجهة ومواصفات السلوك للوظيفة التي يجري تطويرها‪ .‬مشاكل المتطلبات والواجهة الخاطئة‪ -‬يتم تقليل‬
‫يمكن اعتماد هذا النهج في أي عملية هناك هي عالقة واضحة بين متطلبات النظام والقانون الذي ينفذ ذلك متطلبات‪derstandings. .‬‬
‫يمكنك دائ ًم ا رؤية هذا الرابط ألن بطاقات القصة تمثل يتم تقسيم المتطلبات إلى مهام والمهام هي الوحدة الرئيسية لـ تطبيق‪ .‬أدى ‪ XP ،‬في‬
‫أناقش هذه في ‪ (Astels ، 2003).‬إلى مزيد من العمومية مناهج التطوير التي تعتمد على االختبار ‪ XP‬اعتماد تطوير االختبار األول في‬
‫الفصل ‪ .8‬في تطوير االختبار أوالً ‪ ،‬يجب على منفذي المهام أن يفهموا تما ًم ا المواصفات حتى يتمكنوا من كتابة االختبارات للنظام‪ .‬هذا‬
‫يعني أن الغموض‪ -‬يجب توضيح التكرارات والسهو في المواصفات قبل التنفيذ يبدأ‪ .‬عالوة على ذلك ‪ ،‬فإنه يتجنب أيضً ا مشكلة "تأخر‬
‫االختبار"‪ .‬قد يحدث هذا عندما مطور النظام يعمل بوتيرة أسرع من المختبر‪ .‬المنفذ‪ -‬يتقدم االختبار أكثر فأكثر وهناك ميل لتخطي‬
‫كسيناريوهات أو قصص ‪ XP‬االختبارات ‪ ،‬بحيث يمكن الحفاظ على الجدول الزمني للتطوير‪ .‬يتم التعبير عن متطلبات المستخدم‪ W‬في‬
‫هذه من أجل التنمية‪ .‬يقوم فريق التطوير بتقييم كل سيناريو و يقسمها إلى مهام‪ .‬على سبيل المثال ‪ ،‬تم تطوير ‪- tizes‬وأولوية المستخدم‬
‫بعض بطاقات المهام من تظهر بطاقة القصة لوصف الدواء (الشكل ‪ )3.5‬في الشكل ‪ .3.6‬كل مهمة يولد واح ًدا أو أكثر من اختبارات‬
‫الوحدة التي تتحقق من التنفيذ الموضح في تلك المهمة‪ .‬الشكل ‪ 3.7‬عبارة عن وصف مختصر لحالة اختبار تم تطويرها للتحقق منها ‪70‬‬
‫الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة يتمثل دور العميل في عملية االختبار في المساعدة في تطوير اختبارات القبول للقصص التي سيتم‬
‫في الفصل ‪ ، 8‬اختبار القبول هو العملية التي يتم فيها اختبار النظام باستخدام بيانات ‪ cuss‬تنفيذها في اإلصدار القادم من النظام‪ .‬كما أنا‬
‫يكون اختبار القبول ‪ ،‬مثل التطوير ‪ ،‬تدريجيًا‪ .‬الزبون الذي هو يكتب ‪ XP ،‬العميل للتحقق من أنها تلبي احتياجات العميل الحقيقية‪ .‬في‬
‫مصممة‪ W‬لضمان أن هذا هو ما يحتاجه العميل‪ val- .‬جزء من الفريق االختبارات أثناء استمرار التطوير‪ .‬وبالتالي فإن كل الكود الجديد هو‬
‫للقصة في الشكل ‪ ، 3.5‬فإن سيشمل اختبار القبول سيناريوهات حيث (أ) تم تغيير جرعة الدواء ‪( ،‬ب) تم اختيار عقار جديد ‪ ،‬و (ج) تم‬
‫سلسلة من اختبارات القبولبدال من اختبار واحد عادة ما تكون مطلوبة‪- tice ، .‬استخدام دليل الوصفات للعثور على عقار‪ .‬في براك‬
‫األشخاص الذين يتبنون دور العميل ‪ XP.‬االعتماد على العميل لدعم تطوير اختبار القبول هو أحيا ًنا أ صعوبة كبيرة في عملية اختبار‬
‫لديهم الوقت المتاح محدود للغاية وقد ال يكون قادرً ا على العمل بدوام كامل مع التطوير‪ -‬فريق منة‪ .‬قد يشعر العميل أن توفير المتطلبات‬
‫كان كافيًا لـ المساهمة وبالتالي قد تكون مترددة في المشاركة في عملية االختبار‪ .‬أتمتة االختبار ضرورية لتطوير االختبار أوالً‪ .‬تتم كتابة‬
‫االختبارات على أنها قابلة للتنفيذ قبل تنفيذ المهمة‪ .‬يجب أن تكون مكونات االختبار هذه قائمة‪ -‬وحدها ‪ ،‬يجب أن تحاكي إرسال المدخالت‬
‫المراد اختبارها ‪ ،‬ويجب أن تتحقق من أن النتيجة تفي بمواصفات اإلخراج‪ .‬إطار االختبار اآللي هو نظام يجعل من السهل كتابة‬
‫هو مثال مستخدم على نطاق )‪ (Massol and Husted، 2003‬االختبارات القابلة للتنفيذ وتقديم مجموعة من االختبارات للتنفيذ‪ .‬جونيت‬
‫واسع إلطار عمل اختبار آلي‪ .‬نظرً ا ألن االختبار يتم تلقائيًا ‪ ،‬فهناك دائ ًم ا مجموعة من االختبارات التي يمكن أن تكون سريعة وسهلة‪ -‬تم‬
‫إعدامه‪ .‬كلما تمت إضافة أي وظيفة إلى النظام ‪ ،‬يمكن إجراء االختبارات والمشكالت‪ W‬التي أدخلها الكود الجديد يمكن اكتشافها‪ W‬على الفور‪.‬‬
‫عاد ًة ما ينتج عن تطوير االختبار أوالً واالختبار اآللي عدد كبير من يتم كتابة االختبارات وتنفيذها‪ .‬ومع ذلك ‪ ،‬فإن هذا النهج ال يؤدي‬
‫بالضرورة إلى اختبار شامل للبرنامج‪ .‬هناك ثالثة أسباب لذلك‪ .1 :‬يفضل المبرمجون البرمجة على االختبار وأحيا ًنا يتخذون اختصارات‬
‫عند كتابة االختبارات‪ .‬على سبيل المثال ‪ ،‬قد يكتبون اختبارات غير مكتملة ال تفعل ذلك تحقق من جميع االستثناءات الممكنة التي قد‬
‫تحدث‪ .‬الشكل ‪ 3.7‬اختبار الحالة وصف الجرعة تدقيق مدخل‪ .1 :‬عدد بالملغم يمثل جرعة واحدة من الدواء‪ .2 .‬عدد يمثل عدد‬
‫الجرعات المفردة في اليوم‪ .‬االختبارات‪ . 1 :‬اختبار المدخالت حيث تكون الجرعة المفردة صحيحة ولكن التردد مرتفع للغاية‪ .2 .‬اختبر‬
‫جدا ومنخفضة ج ًدا‪ .3 .‬اختبر المدخالت‪ W‬حيث تكون الجرعة المفردة × التردد مرتفعًا ً‬
‫جدا‬ ‫المدخالت‪ W‬حيث تكون الجرعة المفردة عالية ً‬
‫جدا‪ . 4 .‬اختبار المدخالت حيث الجرعة المفردة × التردد في النطاق المسموح به‪ .‬انتاج‪ :‬موافق أو رسالة خطأ تشير إلى أن‬ ‫ومنخفضًا ً‬
‫جدا كتابة بعض االختبارات‬ ‫الجرعة خارج النطاق اآلمن‪ .‬اختبار ‪ :4‬فحص الجرعة ‪ 3.3‬البرمجة الشديدة ‪ .2 71‬قد يكون من الصعب ً‬
‫غالبًا ما يكون من الصعب كتابة اختبارات الوحدة للرمز الذي ‪ plex ،‬بشكل تدريجي‪ .‬على سبيل المثال ‪ ،‬في كوم‪ -‬واجهة مستخدم‬
‫يفرض‪ -‬يذكر "منطق العرض" وسير العمل بين الشاشات‪ . 3 .‬من الصعب الحكم على اكتمال مجموعة االختبارات‪ .‬على الرغم من أنه‬
‫قد يكون لديك ملف الكثير من اختبارات النظام ‪ ،‬قد ال توفر مجموعة االختبار الخاصة بك تغطية كاملة‪ .‬مهم قد ال يتم تنفيذ أجزاء من‬
‫النظام ولذا تظل غير مختبرة‪ .‬لذلك ‪ ،‬على الرغم من أن مجموعة كبيرة من االختبارات التي يتم تنفيذها بشكل متكرر قد تعطي التأثيرات‪-‬‬
‫أن النظام كامل وصحيح ‪ ،‬قد ال يكون هذا هو الحال‪ .‬إذا كانت االختبارات لم تتم مراجعتها والمزيد من االختبارات المكتوبة بعد‬
‫التطوير ‪ ،‬ثم قد يتم اكتشاف أخطاء غير مكتشفة يتم تسليمها في إصدار النظام‪ 3.3.2 .‬البرمجة الزوجية من الممارسات‪ W‬المبتكرة األخرى‬
‫هو المبرمجين العمل في أزواج لتطوير البرنامج‪ .‬يجلسون معً ا في نفس مكان العمل‪ -‬لتطوير البرنامج‪ .‬ومع ذلك ‪ XP ،‬التي تم تقديمها في‬
‫ال يتم برمجة نفس األزواج دائمًا معاً‪ .‬بدالً من ذلك ‪ ،‬يتم إنشاء أزواج بشكل ديناميكي بحيث يعمل معها جميع أعضاء الفريق بعضها‬
‫و الملكية الجماعية والمسؤولية عن ‪ o‬البعض خالل عملية التطوير‪ .‬استخدام البرمجة الزوجية له عدد من المزايا‪ .1 :‬وهو يدعم فكرة‬
‫النظام‪ .‬يعكس هذا فكرة واينبرغ (‪ ) 1971‬عن البرمجة الخالية من الذات حيث تعود ملكية األدوات إلى الفريق ككل وال يتحمل األفراد‬
‫المسؤولية لمشاكل مع الكود‪ .‬بدالً من ذلك ‪ ،‬يتحمل الفريق مسؤولية جماعية عن حل هذه المشاكل‪ .2 .‬إنها بمثابة عملية مراجعة غير‬
‫رسمية ألن كل سطر من التعليمات البرمجية يتم النظر إليه من خالل شخصان على األقل‪ .‬عمليات التفتيش على الكود والمراجعات‪( W‬التي‬
‫تمت تغطيتها في الفصل ‪ )24‬شديدة للغاية ناجحً ا في اكتشاف نسبة عالية من أخطاء البرامج‪ .‬ومع ذلك ‪ ،‬هم تستغرق وق ًتا طويالً في‬
‫على الرغم من أن البرمجة الزوجية هي عملية أقل رسمية ‪ opment.‬التنظيم ‪ ،‬وعاد ًة ما تتسبب في حدوث تأخيرات في التنمية‪ -‬عملية‬
‫وتشكل باقتدار ال يجد الكثير من األخطاء مثل عمليات فحص التعليمات البرمجية ‪ ،‬فهو أرخص بكثير عملية التفتيش من عمليات التفتيش‬
‫الرسمية للبرنامج‪ . 3 .‬يساعد في دعم إعادة البناء ‪ ،‬وهي عملية تحسين البرامج‪ .‬الصعوبة ثقافة تنفيذ هذا في بيئة تنمية طبيعية هو هذا‬
‫قد يتم الحكم على التمزق على أنه أقل كفاءة من الشخص ‪ refac-‬الجهد في يتم إنفاق إعادة الهيكلة لفائدة طويلة األجل‪ .‬الفرد الذي يمارس‬
‫الذي يواصل التطور شفرة‪ .‬عند استخدام البرمجة الزوجية والملكية الجماعية ‪ ،‬يستفيد اآلخرون على الفور من إعادة الهيكلة ‪ ،‬لذلك من‬
‫المحتمل أن يدعموا العملية‪ .‬قد تعتقد أن البرمجة الزوجية ستكون أقل كفاءة من المحترفين الفرديين النحو‪ .‬في وقت معين ‪ ،‬سينتج زوج‬
‫من المطورين نصف كمية الكود التي تنتجها ‪ 72‬الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة فردين يعمالن بمفردهما‪ .‬كانت هناك دراسات‪W‬‬
‫‪ (Cockburn‬مختلفة حول إنتاجية مبرمجين مدفوعين مع نتائج مختلطة‪ .‬باستخدام متطوعين من الطالب ‪ ،‬وليامز ولها وجد المتعاونون‬
‫أن المؤيدين يبدو أن ليونة مع البرمجة الزوجية يمكن مقارنتها مع شخصين )‪ Williams et al. ، 2000‬؛ ‪and Williams ، 2001‬‬
‫العمل بشكل مستقل‪ .‬األسباب المقترحة هي أن األزواج يناقشون البرنامج قبل التطوير ‪ ،‬لذا من المحتمل أن يكون لديك عدد أقل من‬
‫البدايات الخاطئة وأقل إعادة صياغة‪ .‬باإلضافة إلى‪ ،‬عدد األخطاء التي تم تجنبها بواسطة التفتيش غير الرسمي هو أن يتم قضاء وقت أقل‬
‫‪ Parrish et‬؛‪ (Arisholm et al.، 2007‬إصالح الخلل المكتشفة أثناء عملية االختبار‪ .‬ومع ذلك ‪ ،‬دراسات مع مبرمجين أكثر خبرة‬
‫لم يكرر هذه النتائج‪ .‬وجدوا أن هناك داللة‪ -‬ال يمكن فقدان اإلنتاجية مقارنة مع اثنين من المبرمجين الذين يعملون بمفردهم‪al.، 2004) .‬‬
‫كانت هناك بعض مزايا الجودة ولكن هذه لم تعوض بشكل كامل عن البرمجة الزوجية تكاليف غير مباشرة‪ .‬ومع ذلك ‪ ،‬فإن مشاركة‪W‬‬
‫مهم ج ًد ا ألنه يقلل من المخاطر العامة للمشروع عند أعضاء الفريق يترك‪ .‬في حد ‪- ming‬المعرفة التي تحدث أثناء البرنامج الثنائي‬
‫ذاته ‪ ،‬قد يجعل هذا البرمجة الزوجية جديرة باالهتمام‪ 3.4 .‬إدارة المشاريع الرشيقة المسؤولية الرئيسية لمديري مشاريع البرمجيات هي‬
 ‫إدارة المشروع على هذا النحو أن البرنامج يتم تسليمه في الوقت المحدد وفي حدود الميزانية المخطط لها للمشروع‪ .‬يشرفون على عمل‬
‫مهندسي البرمجيات ويراقبون مدى جودة البرنامج التنمية تتقدم‪ .‬النهج القياسي إلدارة المشروع يحركها الخطة‪ .‬كما أناقش في الفصل ‪23‬‬
‫‪ ،‬يضع المديرون خطة للمشروع توضح ما يجب تقديمه‪ -‬وجد ‪ ،‬ومتى ينبغي تسليمه ‪ ،‬ومن سيعمل على تطوير المشروع‪ -‬المخرجات‪W‬‬
‫إلخ‪ .‬يتطلب النهج القائم على الخطة ح ًق ا أن يكون لدى المدير استقرار عرض كل ما يجب تطويره وعمليات التطوير‪ .‬ومع ذلك ‪ ،‬فإنه ال‬
‫يعمل بشكل جيد مع أجايالألساليب التي تكون فيها المتطلبات تم تطويرها بشكل تدريجي حيث يتم تسليم البرنامج بزيادات قصيرة‬
‫وسريعة ؛ وحيث تكون التغييرات في المتطلبات والبرامج هي القاعدة‪ .‬مثل أي عملية تطوير برمجيات احترافية أخرى ‪ ،‬التطوير السريع‬
‫يجب إدارتها بحيث يتم استخدام الوقت والموارد المتاحة على أفضل وجه الفريق‪ .‬هذا يتطلب نهجً ا مختل ًفا إلدارة المشروع ‪ ،‬وهو تتكيف‬
‫)‪ Schwaber and Beedle ، 2001‬؛ ‪ (Schwaber ، 2004‬مع التطور التدريجي ونقاط القوة الخاصة لألساليب الرشيقة‪ .‬نهج سكرم‬
‫هو نهج عام طريقة رشيقة لكن تركيزها ينصب على إدارة التطوير التكراري وليس محد ًدا األساليب التقنية لهندسة البرمجيات الرشيقة‪.‬‬
‫عملية االدارة‪ .‬ال يصف سكرم استخدام ممارسات البرمجة مثل كبرمجة زوجية وتطوير اختبار ‪ Scrum‬الشكل ‪ 3.8‬هو رسم تخطيطي لـ‬
‫لتوفير إطار عمل إداري للمشروع‪ .‬هناك ثالث مراحل في ‪ XP ،‬أوالً ‪ .‬لذلك يمكن استخدامه مع المزيد من التقنيات‪ -‬أساليب رشيقة ‪ ،‬مثل‬
‫سكرم‪ .‬األولى هي مرحلة التخطيط التفصيلي حيث أنت وضع األهداف العامة للمشروع وتصميم بنية البرنامج ‪ 3.4.‬إدارة المشروع‬
‫الرشيقة ‪ 73‬يتبع ذلك سلسلة من دورات العدو ‪ ،‬حيث تطور كل دورة زيادة النظام‪ .‬أخيرً ا ‪ ،‬تنتهي مرحلة إغالق المشروع وتنتهي من‬
‫المشروع الوثائق المطلوبة مثل إطارات تعليمات النظام وأدلة المستخدم والتقييمات الدروس المستفادة من المشروع‪ .‬الميزة المبتكرة لـ‬
‫هو وحدة تخطيط يتم فيها تقييم العمل الذي يتعين القيام به ‪ Scrum ،‬هي مرحلتها المركزية ‪ ،‬وهي دورات العدو‪ .‬إن سباق ‪Scrum‬‬
‫يتم تسليم الوظيفة المكتملة إلى أصحاب المصلحة‪ .‬الخصائص الرئيسية من ‪ Sprint ،‬والميزات للتطوير ‪ ،‬ويتم تنفيذ البرنامج‪ .‬في نهاية أ‬
‫‪ XP. 2.‬هذه العملية هي كما يلي‪ .1 :‬فترات العدو السريع ثابتة ‪ ،‬عادة من ‪ 4-2‬أسابيع‪ .‬تتوافق مع تطوير‪ -‬منة من إصدار النظام في‬
‫نقطة البداية للتخطيط هي تراكم المنتج ‪ ،‬وهي قائمة العمل على المشروع‪ .‬خالل مرحلة تقييم العدو ‪ ،‬هذا هو مراجعة وتحديد األولويات‬
‫والمخاطر‪ .‬العميل متورط بشكل وثيق في هذه العملية ويمكن أن تقدم متطلبات أو مهام جديدة في بداية كل عدو‪ .3 .‬تشمل مرحلة‬
‫االختيار كل فريق المشروع الذي يعمل مع العميل لتحديد الميزات والوظائف التي سيتم تطويرها أثناء العدو‪ .4 .‬بمجرد االتفاق على ذلك‬
‫‪ ،‬ينظم الفريق نفسه لتطوير البرنامج‪ُ .‬ت عقد اجتماعات يومية قصيرة يشارك فيها جميع أعضاء الفريق لمراجعة التقدم وإذا لزم األمر ‪،‬‬
‫أعد ترتيب أولويات العمل‪ .‬خالل هذه المرحلة يتم عزل الفريق عن العميل والمؤسسة ‪ ،‬مع توجيه جميع االتصاالت من خاللها ما يسمى‬
‫ب "سيد سكرم"‪ .‬دور سيد سكرم هو حماية فريق التطوير من االنحرافات‪ W‬الخارجية‪ .‬الطريقة التي يتم بها العمل يعتمد ذلك على المشكلة‬
‫ال يصنع سكرم اقتراحات محددة حول كيفية كتابة المتطلبات ‪ ،‬وتطوير االختبار أوالً ‪ ،‬وما إلى ذلك‪ .‬ومع ذلك ‪ XP ،‬والفريق‪ .‬على عكس‬
‫هذه إذا رأى الفريق أنها مناسبة‪ .5 .‬في نهاية السباق ‪ ،‬تتم مراجعة العمل المنجز وتقديمه إلى أصحاب ‪ ، XP‬يمكن استخدام ممارسات‬
‫هي أنه يجب تمكين الفريق بأكمله للقيام بذلك القرارات لذلك تم تجنب مصطلح ‪ Scrum‬المصلحة‪ .‬ثم تبدأ دورة العدو التالية‪ .‬الفكرة وراء‬
‫"مدير المشروع" عمدا‪ .‬بدال من ذلك ‪ ،‬فإن التخطيط التفصيلي اد المعمارية تصميم إقفال المشروع تقييم حدد مراجعة التطوير دورة‬
‫الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة "سكرم ماستر" هو الميسر الذي يرتب االجتماعات‪ process74 W‬سبرينت الشكل ‪ 3.8‬سكروم‬
‫اليومية ويتتبع األعمال المتراكمة العمل الذي يتعين القيام به ‪ ،‬وتسجيل القرارات ‪ ،‬وقياس التقدم في مقابل التراكم ‪ ،‬و يتواصل مع‬
‫العمالء واإلدارة خارج الفريق‪ .‬يحضر الفريق بأكمله االجتماعات اليومية ‪ ،‬والتي تكون أحيا ًنا "الوقوف" اجتماعات‪ W‬لجعلها قصيرة‬
‫ومركزة‪ .‬خالل االجتماع ‪ ،‬جميع أعضاء الفريق تبادل المعلومات ‪ ،‬وصف التقدم الذي أحرزوه منذ االجتماع األخير ‪ ،‬والمشكالت‪ W‬التي‬
‫حدثت نشأ وما هو مخطط له في اليوم التالي‪ .‬هذا يعني أن الجميع في يعرف الفريق ما يجري ‪ ،‬وإذا ظهرت مشاكل ‪ ،‬يمكنه إعادة‬
‫صياغة العمل قصير المدى إليه التعامل معهم‪ .‬يشارك الجميع في هذا التخطيط قصير المدى ‪ -‬ال يوجد أعلى‪ -‬باتجاه األسفل من سيد‬
‫يناقشان‪. Rising and Janoff (2000) W‬المتاحة على الويب ‪ Scrum‬سكرم‪ .‬هناك العديد من التقارير القصصية عن االستخدام الناجح لـ‬
‫استخدامه الناجح في االتصاالت بيئة تطوير البرمجيات ‪ ،‬ويسردون مزاياها على النحو التالي‪ .1 :‬يتم تقسيم المنتج إلى مجموعة يمكن‬
‫التحكم فيها ومفهومة قطع‪ .2 .‬المتطلبات غير المستقرة ال تعرقل التقدم‪ . 3 .‬يتمتع الفريق بأكمله بإمكانية رؤية كل شيء وبالتالي التواصل‬
‫الجماعي‪ -‬تم تحسين نشوئها‪ . 4 .‬يرى العمالء تسليم الزيادات في الوقت المحدد ويكتسبون مالحظات حول كيفية يعمل المنتج‪ .5 .‬يتم‬
‫كما ‪ Scrum ،‬إنشاء الثقة بين العمالء والمطورين وثقافة إيجابية التي تم إنشاؤها والتي يتوقع الجميع أن ينجح المشروع فيها‪ .‬تم تصميم‬
‫تم تصميمه في األصل ‪ ،‬لالستخدام مع فرق العمل المشتركة حيث يمكن لجميع أعضاء الفريق أن يجتمعوا كل يوم في اجتماعات‬
‫الوقوف‪ .‬لكن‪ ،‬يتضمن الكثير من تطوير البرامج اآلن فر ًق ا موزعة مع أعضاء الفريق تقع في أماكن مختلفة حول العالم‪ .‬وبالتالي ‪ ،‬هناك‬
‫؛ ساذرالند وآخرون ‪ Pshigoda ، 2007 ،‬و ‪ (Smits‬لبيئات التطوير الموزعة ‪ Scrum‬تجارب مختلفة‪ -‬اإلشارات الجارية لتطوير‬
‫‪ 3.5‬طرق القياس الرشيقة تم تطوير األساليب الرشيقة الستخدامها من قبل فرق البرمجة الصغيرة القادرة على ذلك العمل معًا ‪2007).‬‬
‫في نفس الغرفة والتواصل بشكل غير رسمي‪ .‬أساليب رشيقة لها لذلك تم استخدامها في الغالب لتطوير األنظمة الصغيرة والمتوسطة‬
‫ضا على األنظمة األكبر‪ .‬وبالتالي ‪،‬‬ ‫الحجم‪ .‬بالطبع ‪ ،‬الحاجة إلى تسليم أسرع للبرنامج ‪ ،‬وهو أكثر مالءمة‪ W‬للعمالء االحتياجات ‪ ،‬ينطبق أي ً‬
‫كان هناك قدر كبير من االهتمام بتوسيع نطاق األساليب الرشيقة للتعامل مع األنظمة األكبر حجمًا ‪ ،‬والتي تم تطويرها على نطاق واسع‬
‫‪ 3.5‬توسيع نطاق األساليب الرشيقة ‪ 75‬دينينج وآخرون‪ ) 2008( .‬يجادل بأن الطريقة الوحيدة لتجنب مهندس البرمجيات الشائع‪-‬‬
 ‫المشكالت‪ ، W‬مثل األنظمة التي ال تلبي احتياجات العمالء وتجاوزات الميزانية إليجاد طرق لجعل األساليب الرشيقة تعمل مع األنظمة‬
‫التي تتناسب‪ W‬الممارسات‪ W‬الرشيقة مع تطوير األنظمة الكبيرة‪ .‬مور وسبينس (‪ )2008‬تقريرً ا ‪- cusses‬الكبيرة‪ .‬ليفينجويل (‪ )2007‬ديس‬
‫مع ‪ 300‬مطور يعملون في فرق موزعة جغرافيًا‪ .‬يختلف ‪ ical‬عن تجربتهم في استخدام نهج رشيق لتطوير إدارة طبية كبيرة نظام‬
‫تطوير أنظمة البرامج الكبيرة عن تطوير األنظمة الصغيرة بعدة طرق‪ .1 :‬عادة ما تكون األنظمة الكبيرة عبارة عن مجموعات من أنظمة‬
‫اتصال منفصلة ‪ ،‬حيث تقوم فرق منفصلة بتطوير كل نظام‪ .‬في كثير من األحيان ‪ ،‬تعمل هذه الفرق في أماكن مختلفة ‪ ،‬وأحيا ًنا في‬
‫مناطق زمنية مختلفة‪ .‬من المستحيل عمليا‪ -‬بلي لكل فريق للحصول على عرض للنظام بأكمله‪.‬وبالتالي ‪ ،‬فإن ما سبق ‪ -‬عادة ما تكون‬
‫إلكمال الجزء الخاص بهم من النظام دون النظر إلى األوسع قضايا األنظمة‪ .2 .‬األنظمة الكبيرة هي "أنظمة براونفيلد" (هوبكنز ‪ities‬‬
‫وجينكينز ‪ ) 2008 ،‬؛ إنه أنها تشمل وتتفاعل مع عدد من األنظمة الحالية‪ .‬كثير من النظام المتطلبات معنية بهذا التفاعل ولذلك ال‬
‫تقرضها ح ًق ا‪ -‬إلى المرونة والتطور التدريجي‪ .‬يمكن أن تكون القضايا السياسية أيضا مهم هنا ‪ -‬غالبًا ما يكون الحل األسهل لمشكلة هو‬
‫تغيير ملف موجود نظام‪ .‬ومع ذلك ‪ ،‬هذا يتطلب التفاوض مع مديري هذا النظام إقناعهم بأنه يمكن تنفيذ التغييرات دون المخاطرة بالنظام‬
‫عملية‪ . 3 .‬حيث يتم دمج عدة أنظمة إلنشاء نظام ‪ ،‬جزء كبير من التطوير معني بتكوين النظام وليس األصلي تطوير الكود‪ .‬هذا ال يتوافق‬
‫بالضرورة مع التطوير التدريجي‪ -‬منة وتكامل النظام المتكرر‪ .4 .‬غالبًا ما تكون األنظمة الكبيرة وعمليات تطويرها مقيدة بالخارج‪-‬‬
‫القواعد واللوائح التي تحد من الطريقة التي يمكن بها تطويرها تتطلب إنتاج أنواع معينة من وثائق النظام ‪ ،‬إلخ‪ .5 .‬األنظمة الكبيرة لها‬
‫وقت طويل في الشراء والتطوير‪ .‬من الصعب ان الحفاظ على فرق متماسكة‪ W‬تعرف عن النظام خالل تلك الفترة ‪ ،‬حتما ‪ ،‬ينتقل الناس إلى‬
‫وظائف ومشاريع أخرى‪ . 6 .‬عادة ما يكون لألنظمة الكبيرة مجموعة متنوعة من أصحاب المصلحة‪ .‬على سبيل المثال ‪ ،‬الممرضات و قد‬
‫يكون المسؤولون هم المستخدمين النهائيين لنظام طبي ولكن كبار الموظفين الطبيين ‪ ،‬مديرو المستشفيات‪ ، W‬وما إلى ذلك ‪ ،‬هم أيضًا‬
‫أصحاب مصلحة في النظام‪ .‬من الناحية العملية فإنه يفرض‪ -‬يمكن إشراك جميع أصحاب المصلحة المختلفين في عملية التنمية‪ .‬هناك‬
‫منظورين لتوسيع نطاق األساليب الرشيقة‪ . 1 :‬منظور "التوسع" ‪ ،‬والذي يهتم باستخدام هذه األساليب من أجل تطوير أنظمة برمجية‬
‫كبيرة ال يمكن تطويرها بواسطة فريق صغير ‪ . 2‬منظور "التوسع" ‪ ،‬والذي يهتم بمدى إمكانية أن تكون األساليب الرشيقة تم تقديمها عبر‬
‫مؤسسة كبيرة مع سنوات عديدة من تطوير البرامج خبرة‪ .‬يجب تكييف األساليب الرشيقة للتعامل مع هندسة األنظمة الكبيرة‪ .‬يجادل‬
‫ليفينجويل (‪ )2007‬بأنه من الضروري الحفاظ على أساسيات‪ W‬أجايل الطرق ‪ -‬التخطيط المرن ‪ ،‬إصدارات النظام المتكررة ‪ ،‬التكامل‬
‫المستمر ‪ ،‬االختبار‪ -‬تنمية مدفوعة ‪ ،‬واتصاالت فريق جيدة‪ .‬أعتقد أن التكيف الحاسم‪ -‬المواد التي يجب تقديمها هي كما يلي‪ .1 :‬لتطوير‬
‫األنظمة الكبيرة ‪ ،‬ليس من الممكن التركيز فقط على كود نظام‪ .‬تحتاج إلى القيام بالمزيد من وثائق النظام والتصميم المسبق‪ .‬ال يجب‬
‫تصميم بنية البرنامج ويجب أن يكون هناك توثيق للمحترفين وصف الجوانب الحرجة للنظام ‪ ،‬مثل مخططات قاعدة البيانات ‪ ،‬و تقسيم‬
‫العمل عبر الفرق ‪ ،‬إلخ‪ . 2 .‬يجب تصميم آليات االتصال بين الفرق واستخدامها‪ .‬هذا يجب أن تتضمن مؤتمرات هاتفية وفيديو منتظمة بين‬
‫أعضاء الفريق و اجتماعات إلكترونية متكررة وقصيرة حيث ُت طلع الفرق بعضها البعض على التقدم المحرز‪ .‬مجموعة من قنوات‬
‫االتصال مثل البريد اإللكتروني ‪ ،‬والرسائل الفورية ‪ ،‬وويكي ‪ ،‬وأنظمة الشبكات‪ W‬االجتماعية يجب توفيرها لتسهيل االتصاالت‪.3 .‬‬
‫التكامل المستمر ‪ ،‬حيث يتم بناء النظام بأكمله في كل مرة وفي أي تطور‪ -‬أوبرا تحقق في التغيير ‪ ،‬عمليا مستحيل عندما العديد من‬
‫واإلصدارات ‪ t‬المؤيدين المنفصلين يجب دمج الجرامات إلنشاء النظام‪ .‬ومع ذلك ‪ ،‬فمن الضروري أن الحفاظ على التردديبني نظام‬
‫المنتظمة للنظام‪ .‬هذا ممكن يعني أن أدوات إدارة التكوين الجديدة التي تدعم البرامج متعددة الفرق يجب إدخال تطوير األدوات‪ .‬كانت‬
‫شركات البرمجيات الصغيرة التي تطور منتجات البرمجيات من بين أكثر المتحمسين لألساليب الرشيقة‪ .‬هذه الشركات ال تقيدها‬
‫البيروقراطيات التنظيمية أو معايير العمليات ويمكن أن تتغير بسرعة إلى تبني أفكار جديدة‪ .‬بالطبع ‪ ،‬جربت الشركات الكبرى أيضًا‬
‫وآخرون‪. Lindvall ( .‬أسلوب أجايل األساليب في مشاريع محددة ‪ ،‬ولكن يصعب عليهم "توسيع نطاق" هذه األساليب عبر المنظمة‬
‫‪ ) 2004‬مناقشة بعض مشاكل في توسيع نطاق األساليب الرشيقة في أربع شركات تقنية كبيرة‪ .‬من الصعب إدخال أساليب رشيقة في‬
‫الشركات الكبيرة لعدد من األسباب‪ . 1 :‬قد يتردد مديرو المشاريع الذين ليس لديهم خبرة في األساليب الرشيقة لقبول مخاطر اتباع نهج‬
‫جديد ‪ ،‬ألنهم ال يعرفون كيف سيؤثر ذلك مشاريعهم الخاصة‪ .2 .‬المنظمات الكبيرة غالبًا ما يكون لديها إجراءات ومعايير جودة لجميع‬
‫المشاريع من المتوقع أن يتبعوا ‪ ،‬وبسبب طبيعتهم البيروقراطية ‪ ،‬فمن المحتمل أن يفعلوا ذلك تكون غير متوافقة مع األساليب الرشيقة‪.‬‬
‫في بعض األحيان ‪ ،‬يتم دعم هذه بواسطة البرامج ‪ 76‬الفصل الثالث تطوير البرمجيات الرشيقة الفصل الثالث النقاط الرئيسية النقاط‬
‫الرئيسية األساليب الرشيقة هي طرق تطوير تدريجية تركز على التطور السريع والمتكرر إصدارات البرنامج ‪ ،‬وتقليل النفقات العامة‪W‬‬
‫للعملية ‪ ،‬وإنتاج كود عالي الجودة‪ .‬هم إشراك العميل مباشرة في عملية التطوير‪ .‬يجب اتخاذ قرار بشأن استخدام نهج رشيق أو نهج‬
‫مدفوع بالخطة في التنمية تعتمد على نوع البرنامج الذي يتم تطويره ‪ ،‬وقدرات فريق التطوير ‪ ،‬و ثقافة الشركة المطورة للنظام‪ .‬البرمجة‬
‫المتطرفة هي طريقة رشيقة معروفة تدمج مجموعة من األشياء الجيدة ممارسات البرمجة مثل اإلصدارات المتكررة للبرنامج والبرامج‬
‫المستمرة التحسين ومشاركة العمالء في فريق التطوير‪ .‬تتمثل إحدى نقاط القوة الخاصة في البرمجة الشديدة في تطوير االختبارات اآللية‬
‫قبل أ تم إنشاء ميزة البرنامج‪ .‬يجب تنفيذ جميع االختبارات بنجاح عند دمج الزيادة في نظام‪ .‬األدوات (على سبيل المثال ‪ ،‬أدوات إدارة‬
‫المتطلبات) واستخدام هذه األدوات مطلوب لجميع المشاريع‪ . 3 .‬يبدو أن األساليب الرشيقة تعمل بشكل أفضل عندما يكون لدى أعضاء‬
‫الفريق مستوى مرتفع نسبيًا مستوى المهارة‪ .‬ومع ذلك ‪ ،‬داخل المؤسسات‪ W‬الكبيرة ‪ ،‬من المحتمل أن يكون هناك نطاق واسع مجموعة من‬
‫في العمليات الرشيقة‪ .4 .‬قد ‪ tive‬المهارات والقدرات ‪ ،‬وقد ال يكون األشخاص ذوو المستويات األقل من المهارة فعالين‪ -‬أعضاء الفريق‬
 ‫تكون هناك مقاومة ثقافية لألساليب الرشيقة ‪ ،‬خاصة في تلك المنظمات‪ W‬التي لها تاريخ طويل في استخدام عمليات هندسة النظم التقليدية‪.‬‬
‫إدارة التغيير وإجراءات االختبار هي أمثلة على إجراءات الشركة‪ -‬إجراءات قد ال تكون متوافقة مع األساليب الرشيقة‪ .‬إدارة التغيير هي‬
‫عملية التحكم في التغييرات التي تطرأ على النظام ‪ ،‬بحيث يكون تأثير التغييرات مسب ًقا قابلة لإلمالء ويتم التحكم في التكاليف‪ .‬يجب‬
‫أي مطور يمكنه تحسين أي ‪ XP ،‬الموافقة على جميع التغييرات مسب ًقا من قبل إنها مصنوعة وهذا يتعارض مع فكرة إعادة البناء‪ .‬في‬
‫ض ا اختبار المعايير حيث يتم تسليم بناء النظام إلى اختبار‬ ‫رمز دون الحصول على موافقة خارجية‪ .‬بالنسبة لألنظمة الكبيرة ‪ ،‬هناك أي ً‬
‫إدخال والحفاظ على االستخداممن األساليب ‪ XP.‬خارجي فريق‪ .‬قد يتعارض هذا مع نهج االختبار أوالً ونهج االختبار غالبًا المستخدم في‬
‫الرشيقة عبر مؤسسة كبيرة عملية تغيير ثقافي‪ .‬التغيير الثقافي يستغرق وقتا طويال لتنفيذ و غالبًا ما يتطلب تغييرً ا في اإلدارة قبل أن يتم‬
‫تحقيقها‪ .‬شركات إن الراغبين في استخدام األساليب الرشيقة يحتاجون إلى مبشرين لتعزيز التغيير‪ .‬يجب أن يكرسوا موارد كبيرة لعملية‬
‫التغيير‪ .‬في وقت كتابة هذا التقرير ‪ ،‬كان عدد قليل من الشركات الكبيرة‪ -‬لقد نجحت البلدان في االنتقال بنجاح إلى التطوير السريع عبر‬
‫هي طريقة رشيقة توفر إطار عمل إلدارة المشروع‪ .‬إنها تتمحور حول مجموعة من سباقات‪ W‬السرعة ‪ ،‬وهي ‪ Scrum‬المنظمة‪ .‬طريقة‬
‫فترات زمنية ثابتة عندما تكون زيادة النظام متطور‪ .‬يعتمد التخطيط على تحديد أولويات العمل المتراكم واختيار أعلى‪ -‬المهام ذات‬
‫األولوية للعدو‪ .‬من الصعب تحجيم األساليب الرشيقة لألنظمة الكبيرة‪ .‬تحتاج األنظمة الكبيرة إلى تصميم مسبق و بعض الوثائق‪ .‬التكامل‬
‫المستمر مستحيل عمليا عندما يكون هناك العديد فرق تطوير منفصلة تعمل على مشروع‪ .‬قراءة متعمقة شرح البرمجة المتطرفة‪ .‬كان هذا‬
‫وال يزال ‪ ،‬على األرجح ‪ ،‬األكثر مقروء‪ .‬يشرح النهج من منظور أحد مخترعيه ومنظوره يأتي الحماس بوضوح ‪ XP‬هو أول كتاب عن‬
‫شديد في الكتاب‪( .‬كينت بيك ‪ ،‬أديسون ويسلي ‪" ). 2000 ،‬استعد للطرق السريعة بعناية"‪ .‬نقد مدروس لألساليب الرشيقة التي تناقش‬
‫)‪.‬يناير ‪ ، IEEE Computer ، 2002‬ب‪ .‬بوم( ‪.‬نقاط قوتهم وضعفهم ‪ ،‬كتبها مهندس برمجيات ذو خبرة كبيرة‬
‫توسيع نطاق رشاقة البرامج‪ :‬أفضل الممارسات للمؤسسات‪http://doi.ieeecomputersociety.org/10.1109/2.976920. W‬‬
‫صا للطرق الرشيقة الرئيسية‬ ‫ضا ملخ ً‬
‫الكبيرة‪ .‬على الرغم من أن تركز على قضايا توسيع نطاق التطور السريع ‪ ،‬يتضمن هذا الكتاب أي ً‬
‫تركز معظم الكتب ‪ Agile.‬تشغيل مشروع تطوير برمجيات )‪.‬د‪ .‬ليفينجويل ‪ ،‬أديسون ويسلي ‪ Crystal. (2007 ،‬و ‪ Scrum‬و ‪ XP‬مثل‬
‫في ممارسة في مشروع‪ .‬نصيحة ‪ XP‬حول األساليب الرشيقة على أ طريقة محددة ولكن هذا الكتاب يأخذ نهجً ا مختل ًفا ويناقش كيفية وضع‬
‫اشرح سبب أهمية التسليم السريع ونشر األنظمة ‪ E X E R C I S E S 3.1.‬جيدة وعملية‪( .‬إم هولكومب ‪ ،‬جون وايلي وأوالده ‪).2008 ،‬‬
‫الجديدة في كثير من األحيان للشركات‪ W‬من الوظائف التفصيلية لهذه األنظمة‪ 3.2 .‬اشرح كيف أن المبادئ التي تقوم عليها األساليب‬
‫الرشيقة تؤدي إلى التطور المتسارع ونشر البرامج‪ 3.3 .‬متى تنصح بعدم استخدام طريقة رشيقة لتطوير برنامج نظام؟ ‪ .3.4‬تعبر‬
‫البرمجة المتطرفة عن متطلبات المستخدم كقصص ‪ ،‬مع كتابة كل قصة على البطاقة‪ .‬ناقش مزايا وعيوب هذا النهج للمتطلبات وصف‪.‬‬
‫‪ 78‬الفصل ‪ 3‬تطوير البرمجيات‪ W‬الرشيقة الفصل ‪ 3‬تمارين ‪ 3.5 79‬اشرح لماذا يساعد تطوير االختبار أوالً المبرمج على تطوير فهم‬
‫أفضل من متطلبات النظام‪ .‬ما هي الصعوبات المحتملة في تطوير االختبار أوالً؟ ‪ 3.6‬اقترح أربعة أسباب لماذا قد يكون معدل إنتاجية‬
‫المبرمجين الذين يعملون كزوج أكثر من نصف المبرمجين العاملين بشكل فردي‪ 3.7 .‬قارن وقارن بين نهج سكرم إلدارة المشاريع مع‬
‫التقليدية النهج القائمة على الخطة ‪ ،‬كما نوقش في الفصل ‪ . 23‬ينبغي أن تستند المقارنات على فعالية كل نهج للتخطيط لتخصيص‬
‫األشخاص للمشاريع ‪ ،‬تقدير تكلفة المشاريع والحفاظ على تماسك الفريق وإدارة التغييرات فيها عضوية فريق المشروع‪ 3.8 .‬أنت مدير‬
‫برمجيات‪ W‬في شركة ثيطور برنامج التحكم الحرج للطائرات‪ .‬أنت مسؤول عن تطوير دعم تصميم البرامج نظام يدعم ترجمة متطلبات‬
‫البرامج إلى برنامج رسمي المواصفات (تمت مناقشتها‪ W‬في الفصل ‪ .) 13‬التعليق على المزايا والعيوب من استراتيجيات التنمية التالية‪ :‬أ‪.‬‬
‫جمع متطلبات مثل هذا النظام من مهندسي البرمجيات‪ W‬والخارجيين أصحاب المصلحة (مثل هيئة إصدار الشهادات‪ W‬التنظيمية) وتطوير‬
‫قم بتقييمه هذا ‪ Python ،‬أو ‪ Ruby‬النظام باستخدام نهج خطة مدفوعة‪ .‬ب‪ .‬قم بتطوير نموذج أولي باستخدام لغة برمجة نصية ‪ ،‬مثل‬
‫النموذج األولي مع مهندسي البرمجيات وأصحاب المصلحة اآلخرين ‪ ،‬ثم راجع متطلبات النظام‪ .‬أعد تطوير النظام النهائي باستخدام‬
‫باستخدام نهج رشيق مع مستخدم مشارك في فريق التطوير‪ 3.9 .‬لقد تم اقتراح أن إحدى مشاكل وجود ‪ Java‬ج‪ .‬طور النظام في ‪Java.‬‬
‫مستخدم متورط بشكل وثيق معها يتمثل فريق تطوير البرمجيات في أنهم "يتحولون إلى أصليين" ؛ أي أنهم يتبنون النظرة فريق التطوير‬
‫وتفقد احتياجات زمالئهم المستخدمين‪ .‬أقترح ثالثة طرق كيف يمكنك تجنب هذه المشكلة ومناقشة المزايا والعيوب من كل نهج‪.3.10 .‬‬
‫لتقليل التكاليف واألثر البيئي للتنقل ‪ ،‬تقرر شركتك ذلك إغالق عدد من المكاتب وتقديم الدعم للموظفين للعمل من المنزل‪ .‬لكن‪ ،‬اإلدارة‬
‫العليا التي تقدم السياسة غير مدركة أن البرمجيات قد تم تطويرها باستخدام األساليب الرشيقة ‪ ،‬والتي تعتمد على العمل الجماعي الوثيق‬
‫والبرمجة الزوجية‪ .‬يناقش الصعوبات التي قد تسببها هذه السياسة الجديدة وكيف يمكنك التغلب عليها المشاكل ‪ 80‬الفصل ‪ 3‬تطوير‬
‫النمذجة الرشيقة‪ :‬الممارسات الفعالة للبرمجة المتطرفة ‪ Ambler، S.W and Jeffries، R. (2002).‬البرمجيات الرشيقة مراجع‬
‫تقييم " ‪. Arisholm، E.، Gallis، H.، Dyba، T. and Sjoberg، D.I K. (2007).‬والعملية الموحدة‪ .‬نيويورك‪ :‬جون وايلي وأوالده‬
‫في هندسة البرمجيات ‪ .86-65 ، )2( 33 ،‬أستيلز ‪ ،‬د‪. IEEE Trans. ( .‬البرمجة المزدوجة مع احترام تعقيد النظام وخبرة المبرمج‬
‫‪ .) 2003‬التطوير المدفوع باالختبار‪ :‬دليل عملي‪ .‬نهر السرج العلوي ‪ ،‬نيوجيرسي‪ :‬برنتيس هول‪ .‬بيك ‪ ،‬ك‪" .)1999( .‬احتضان التغيير‬
‫بيك ‪ ،‬ك‪ .)2000( .‬وأوضح البرمجة المتطرفة‪ .‬القراءة ‪ ،‬ماس‪". IEEE Computer، 32 (10)، 70–8. :‬مع البرمجة المتطرفة‬
‫أديسون ويسلي‪ .‬كارلسون ‪ ،‬د‪ .)2005( .‬كسوف مقطر‪ .‬بوسطن‪ :‬أديسون ويسلي‪ .‬كوكبيرن ‪ ،‬أ‪ .)2001( .‬تطوير البرمجيات رشيق‪.‬‬
 ‫القراءة ‪ ،‬ماس‪ :‬أديسون ويسلي‪ .‬كوكبيرن ‪ ،‬أ‪ .) 2004( .‬وضوح الكريستال‪ :‬منهجية تعمل بالطاقة البشرية للفرق الصغيرة‪ .‬بوسطن‪:‬‬
‫أديسون ويسلي‪ .‬كوكبيرن ‪ ،‬أ‪.‬ويليامز ‪ ،‬إل‪" .) 2001( .‬تكاليف وفوائد البرمجة الزوجية"‪ .‬في المتطرفة تم فحص البرمجة‪( .‬محرر)‪.‬‬
‫بوسطن‪ :‬أديسون ويسلي‪ Scrum. .‬تطوير البرمجيات‪ W‬باستخدام ‪ Agile:‬بوسطن‪ :‬أديسون ويسلي‪ .‬كوهن ‪ ،‬م‪ .)2009( .‬النجاح مع‬
‫‪. J.، Gunderson، C.‬دينينج ‪ ،‬ص ‪". IEEE Computer، 35 (6)، 90-2.‬ديماركو ‪ ،‬ت‪ .‬وبوم ‪ ،‬ب‪" .)2002( .‬أساليب الرشيقة‬
‫دروبنا ‪ ،‬ج‪ ، .‬نوفتز ‪ ،‬د‪ ACM، 51 (12) ، 29-31. .‬تطوير النظام التطوري"‪ .‬باالتصاالت" ‪and Hayes-Roth، R. (2008).‬‬
‫البرمجيات ‪ .5-70 ، )6( 21 ،‬هايسميث ‪ ،‬جى أ‪". IEEE ( .‬في أربعة مشاريع ذات مهام حرجة ‪ XP‬وراغو ‪ ،‬ر‪" .)2004( .‬تجريب‬
‫‪ .) 2000‬تطوير البرمجيات التكيفية‪ :‬نهج تعاوني لإلدارة أنظمة معقدة‪ .‬نيويورك‪ :‬دورست هاوس‪ .‬هوبكنز ‪ ،‬آر وجينكينز ‪ ،‬ك‪( .‬‬
‫إلى براونفيلد‪ .‬بوسطن ‪ ،‬ماساتشوستس‪ :‬مطبعة آي ‪ .)2008 Greenfield Development‬أكل فيل تكنولوجيا المعلومات‪ :‬االنتقال من‬
‫واألنماط‪ :‬مقدمة في التحليل الموجه للكائنات و التصميم والعملية الموحدة‪ .‬إنجليوود ‪ UML‬بي إم‪ .‬الرمان ‪ ،‬سي (‪ .)2002‬يتم تطبيق‬
‫كليف ‪ ،‬نيوجيرسي‪ :‬برنتيس هول‪ .‬ليفينجويل ‪ ،‬د‪ .)2007( .‬توسيع نطاق رشاقة البرامج‪ :‬أفضل الممارسات‪ W‬للمؤسسات الكبيرة‪.‬‬
‫‪. Lindvall ، M. ، Muthig ، D. ، Dagnino ، A. ، Wallin ، C. ، Stupperich ، M. ، Kiefer ، D. ،‬بوسطن‪ :‬أديسون ويسلي‬
‫)‪ IEEE ، 37 (12‬في المؤسسات الكبيرة"‪ .‬كمبيوتر ‪May ، J. and Kahkonen ، T. (2004). "Agile Software Development‬‬
‫‪. Massol ، V. and‬مارتن ‪ ،‬ج‪ .) 1981( .‬تطوير التطبيقات بدون مبرمجين‪ .‬إنجليوود كليفس ‪ ،‬نيوجيرسي‪ :‬برنتيس هول ‪، 26–34‬‬
‫ميلز ‪ ،‬إتش دي ‪ ،‬أونيل ‪ ،‬دي ‪ ،‬لينجر ‪: Manning Publications Co.‬في العمل‪ .‬غرينتش ‪ ،‬كونيتيكت ‪Husted ، T. (2003). JUnit‬‬
‫مور ‪ ،‬إي وسبينز ‪ ، IBM. J.، 19 (4) ، 414–77. ،‬آر سي ‪ ،‬داير ‪ ،‬إم وكوينان ‪ ،‬آر إي (‪' .)1980‬إدارة هندسة البرمجيات'‪ .‬أنظمة‬
‫‪: IEEE Computer‬بروك‪ .‬رشيق ‪ 2008‬مؤتمر ‪ ،‬تورنتو ‪. "Scaling Agile: Finding your Agile Tribe".‬ج‪)2008( .‬‬
‫بالمر ‪ ،‬إس آر وفيلسينج ‪ ،‬جي إم (‪ .) 2002‬دليل عملي للتطوير المدفوع بالميزات‪ .‬إنجليوود كليفس ‪Society. 121-124. ،‬‬
‫نيوجيرسي‪ :‬برنتيس هول‪ .‬باريش ‪ ،‬أ ‪ ،‬سميث ‪ ،‬ر‪ ، .‬هيل ‪ ،‬د‪ .‬وهيل ‪ ،‬ج‪" .)2004( .‬دراسة ميدانية ألزواج المطورين‪ :‬اإلنتاجية اآلثار‬
‫بول ‪ ،‬سي وهيسمان ‪ ،‬جيه دبليو (‪" .)2001‬استخدام البرمجة القصوى في بيئة الصيانة"‪ IEEE، 21 (5) ، 76-9. .‬والتداعيات‪ .‬برنامج‬
‫رايزينج ‪ ،‬إل وجانوف ‪ ،‬إن إس (‪" .)2000‬عملية تطوير برامج سكروم للفرق الصغيرة"‪ .‬برنامج ‪ IEEE ، 18 (6) ، 42-50.‬برنامج‬
‫‪.‬مع سكرم‪ .‬سياتل‪ :‬مطبعة مايكروسوفت ‪. Agile Project Management‬شوابر ‪ ،‬ك‪IEEE ، 17 (4) ، 26–32. )2004( .‬‬
‫تطوير البرمجيات الرشيقة مع سكرم‪ .‬إنجليوود كليفس نيوجيرسي‪ :‬برنتيس هول‪Schwaber ، K. and Beedle ، M. (2001). .‬‬
‫‪:‬واشنطن العاصمة ‪'. Agile 2007 ،‬سميتس ‪ ،‬إتش وبشيجودا ‪ ،‬جي (‪" .)2007‬تنفيذ سكرم في تطوير البرمجيات الموزعة منظمة‬
‫هارلو ‪ ،‬المملكة المتحدة‪ :‬أديسون ‪ DSDM.‬ستابلتون ‪ ،‬ج‪ .)1997( .‬طريقة تطوير األنظمة الديناميكية ‪IEEE Computer Society.‬‬
‫التنمية المركزة على األعمال ‪ ،‬الطبعة الثانية‪ .‬هارلو ‪ ،‬المملكة المتحدة‪ :‬بيرسون تعليم‪. DSDM: .‬ويسلي‪ .‬ستابلتون ‪ ،‬ج‪)2003( .‬‬
‫ساذرالند ‪ ،‬ج‪ ، .‬فيكتوروف ‪ ،‬أ‪: Apress. ، .‬ستيفنز ‪ ،‬إم وروزنبرغ ‪ ،‬د‪ .)2003( .‬برمجة متطرفة معاد تشكيلها‪ .‬بيركلي ‪ ،‬كاليفورنيا‬
‫بلونت ‪ ،‬ج‪ .‬وبونتيكوف ‪ ،‬إن‪ .) 2007( .‬توزيع سكرم‪ :‬مشروع رشيق اإلدارة مع االستعانة بمصادر خارجية فرق التطوير‪ 40 .‬هاواي‬
‫للكمبيوتر‪ .‬واينبرغ ‪ ،‬ج‪ .)1971( .‬علم نفس برمجة الحاسوب‪ IEEE .‬كثافة العمليات‪ .‬أسيوط‪ .‬في علوم النظام ‪ ،‬هاواي‪ :‬جمعية‬
‫نيويورك‪ :‬فان نوستراند‪ .‬وليامز ‪ ،‬إل‪ ، .‬كيسلر ‪ ،‬آر آر ‪ ،‬كننغهام ‪ ،‬دبليو وجيفريز ‪ ،‬ر‪" .)2000( .‬تعزيز حالة الزوج برمجة'‪ .‬برنامج‬
‫الفصل ‪ 3‬المراجع ‪ 81‬المتطلبات هندسة ‪ 4‬أهداف الهدف من هذا الفصل هو تقديم متطلبات البرامج و ‪IEEE ، 17 (4) ، 19-25.‬‬
‫لمناقشة العمليات التي ينطوي عليها االكتشاف والتوثيق هذه المتطلبات‪ .‬عندما تقرأ الفصل سوف‪ :‬فهم مفاهيم المستخدم ومتطلبات النظام‬
‫و لماذا يجب كتابة هذه المتطلبات بطرق مختلفة ؛ فهم االختالفات بين الوظيفية وغير الوظيفية متطلبات البرنامج؛ فهم كيفية تنظيم‬
‫المتطلبات في البرنامج وثيقة المتطلبات فهم المتطلبات الرئيسية لألنشطة الهندسية لـ االستنباط والتحليل والتحقق والعالقات بين هذه‬
‫االنشطة؛ فهم سبب أهمية إدارة المتطلبات وكيف أنها تدعم األنشطة الهندسية األخرى المتطلبات‪ .‬محتويات ‪ 4.1‬المتطلبات الوظيفية‬
‫وغير الوظيفية ‪ 4.2‬وثيقة متطلبات البرنامج ‪ 4.3‬الشرطالمواصفات ‪ 4.4‬عمليات هندسة المتطلبات ‪ 4.5‬استنباط المتطلبات وتحليلها‬
‫‪ 4.6‬التحقق من المتطلبات ‪ 4.7‬إدارة المتطلبات الفصل الرابع هندسة المتطلبات ‪ 83‬متطلبات النظام هي أوصاف لما يجب أن يفعله‬
‫ضا معي ًنا مثل‪:‬‬
‫النظام ‪ -‬الخدمات التي تقدمها والقيود المفروضة على عملها‪ .‬هذه المتطلبات تعكس احتياجات العمالء لنظام يخدم غر ً‬
‫التصيد بجهاز أو تقديم طلب أو العثور على معلومات‪ .‬عملية البحث يتم استدعاء وتحليل وتوثيق والتحقق من هذه الخدمات‪ W‬والقيود‬
‫ال يتم استخدام مصطلح "المتطلبات" باستمرار في صناعة البرمجيات‪ .‬في بعض الحاالت ‪ ،‬المطلب هو ببساطة ‪ (RE).‬متطلبات الهندسة‬
‫قيد ا على النظام‪ .‬في الطرف اآلخر ‪ ،‬هو مفصل ‪ ،‬التعريف الرسمي ‪ tem‬بيان تجريدي عالي المستوى للخدمة التي ‪ -‬يجب أن يوفر‬ ‫أو ً‬
‫لوظيفة النظام‪ .‬يشرح ديفيس (‪ ) 1993‬سبب هذه االختالفات يخرج‪ :‬إذا رغبت إحدى الشركات في إبرام عقد لمشروع تطوير برمجيات‬
‫كبير ‪ ،‬يجب أن تحدد احتياجاتها بطريقة مجردة بما فيه الكفاية بحيث ال يكون الحل مسب ًقا ‪ -‬مُعرف‪ .‬يجب كتابة المتطلبات بحيث يمكن‬
‫بمجرد منح ‪ zation.‬للعديد من المقاولين تقديم عطاءات بالنسبة للعقد ‪ ،‬وربما تقديم طرق مختلفة لالجتماع مع منظمة العميل‪ -‬احتياجات‬
‫العقد ‪ ،‬يجب على المقاول كتابة تعريف النظام للعميل بمزيد من التفصيل حتى يفهم العميل و يمكن التحقق من صحة ما سيفعله البرنامج‪.‬‬
‫قد يتم استدعاء كل من هذه المستندات وثيقة المتطلبات للنظام‪ .‬بعض المشاكل التي تنشأ أثناء عملية هندسة المتطلبات هي نتيجة للفشل في‬
 ‫الفصل بشكل واضح بين هذه المستويات المختلفة من وصف‪ .‬أنا أميز بينهما باستخدام مصطلح "متطلبات المستخدم"‪ W‬تعني المتطلبات‬
‫المجردة عالية المستوى و "متطلبات النظام" لتعني وصف مفصل لما يجب أن يفعله النظام‪ .‬متطلبات المستخدم والنظام يمكن تعريف‬
‫المتطلبات على النحو التالي‪ . 1 :‬متطلبات المستخدم هي بيانات ‪ ،‬بلغة طبيعية باإلضافة إلى الرسوم البيانية ‪ ،‬لماذا الخدمات‪ W‬التي يتوقع أن‬
‫يوفرها النظام لمستخدمي النظام والقيود التي يجب أن تعمل تحتها‪ .2 .‬متطلبات النظام هي أوصاف أكثر تفصيالً لنظام البرمجيات‪W‬‬
‫يجب أن تحدد منة (تسمى أحيا ًنا المواصفات الوظيفية) ما هو بالضبط ليتم ‪ docu-‬الوظائف والخدمات والقيود التشغيلية‪ .‬متطلبات النظام‬
‫تنفيذها‪ .‬قد يكون جز ًء ا من العقد المبرم بين مشتري النظام و مطوري البرمجيات‪ .‬المستويات المختلفة من المتطلبات مفيدة ألنها تنقل‬
‫المعلومات‪ -‬حول النظام ألنواع مختلفة من القراء‪ .‬يوضح الشكل ‪ 4.1‬التمييز بين متطلبات المستخدم والنظام‪ .‬هذا المثال من رعاية‬
‫كيف يمكن أن تكون متطلبات المستخدم توسعت في العديد من متطلبات )‪ (MHC-PMS‬الصحة العقلية يوضح نظام إدارة المريض‬
‫جدا‪ .‬توفر متطلبات النظام أكثر تحدي ًدا معلومات حول خدمات‪W‬‬ ‫النظام‪ .‬يمكنك أن ترى من الشكل ‪ 4.1‬أن ملف متطلبات المستخدم عامة ً‬
‫بإنشاء تقارير إدارية شهرية تظهر تكلفة ‪ MHC-PMS‬ووظائف النظام الذي سيتم تنفيذه‪ 84 .‬الفصل الرابع هندسة المتطلبات ‪ .1‬يقوم‬
‫األدوية الموصوفة من قبل كل عيادة خالل ذلك الشهر‪ 1.1 .‬في آخر يوم عمل من كل شهر ‪ ،‬ملخص األدوية المقررة ‪ ،‬وتكلفتها ‪،‬‬
‫والعيادات التي توصف‪ 1.2 .‬يجب أن يقوم النظام تلقائيًا بإنشاء ملفتقرير للطباعة بعد الساعة ‪ 17.30‬في آخر يوم عمل من الشهر‪1.3 .‬‬
‫يجب عمل تقرير لكل عيادة ‪ ،‬ويجب أن يسرد الفرد أسماء األدوية ‪ ،‬العدد اإلجمالي للوصفات ‪ ،‬عدد الجرعات المقررة ‪ ،‬والتكلفة‬
‫اإلجمالية لألدوية الموصوفة‪ 1.4 .‬إذا كانت األدوية متوفرة بوحدات جرعات مختلفة (على سبيل المثال ‪ 10 ،‬مجم ‪ 20 ،‬مجم) يجب‬
‫إنشاء تقارير منفصلة لكل وحدة جرعة‪ 1.5 .‬يجب أن يقتصر الوصول إلى جميع تقارير التكلفة على المستخدمين المصرح لهم المدرجة‬
‫أسماؤهم في قائمة التحكم في الوصول لإلدارة‪ .‬تعريف متطلبات المستخدم مواصفات متطلبات النظام الشكل ‪ 4.1‬المستخدم و متطلبات‬
‫النظام تحتاج إلى كتابة المتطلبات بمستويات مختلفة من التفاصيل ألن القراءة المختلفة‪ -‬يستخدمونها بطرق مختلفة‪ .‬يوضح الشكل ‪4.2‬‬
‫القراء المحتملين للمستخدم‪ W‬والنظام‪ -‬متطلبات تيم‪ .‬ال يهتم قراء متطلبات المستخدم عادة مع الكيفية التي سيتم بها تنفيذ النظام وقد يكونون‬
‫مديرين غير مشتركين مقدرة في المرافق التفصيلية للنظام‪ .‬قراء متطلبات النظام بحاجة إلى معرفة أكثر دقة ما سيفعله النظام ألنهم قلقون‬
‫مع الكيفية التي ستدعم بها العمليات التجارية أو ألنها تشارك في تنفيذ النظام‪ .‬في هذا الفصل ‪ ،‬أقدم وجهة نظر "تقليدية" للمتطلبات بدالً‬
‫من طلب‪ -‬إشارات في العمليات الرشيقة‪ .‬بالنسبة لمعظم األنظمة الكبيرة ‪ ،‬ال يزال هناك ملف المتطلبات الهندسية التي يمكن تحديدها‬
‫بوضوح قبل تنفيذ يبدأ النظام‪ .‬النتيجة هي وثيقة متطلبات ‪ ،‬والتي قد تكون جز ًء ا من عقد تطوير النظام‪ .‬بالطبع ‪ ،‬عادة ما تكون هناك‬
‫تغييرات الحقة على يمكن توسيع المتطلبات ومتطلبات المستخدم إلى نظام أكثر تفصيالً متطلبات‪ .‬ومع ذلك ‪ ،‬فإن النهج الرشيق المتمثل‬
‫في استحضار الطلب بشكل متزامن يتطلب‪ -‬نادرً ا ما يتم استخدام اإلشارات أثناء تطوير النظام لتطوير األنظمة الكبيرة‪ 4.1 .‬المتطلبات‬
‫الوظيفية وغير الوظيفية غال ًب ا ما يتم تصنيف متطلبات نظام البرامج على أنها متطلبات وظيفية أو غير المتطلبات الوظيفية‪ .1 :‬المتطلبات‬
‫الوظيفية هذه هي بيانات الخدمات التي ينبغي للنظام تقدم ‪ ،‬كيف يجب أن يتفاعل النظام مع مدخالت معينة ‪ ،‬وكيف النظام ‪ 4.1‬المتطلبات‬
‫ً‬
‫صراحة‬ ‫الوظيفية وغير الوظيفية ‪ 85‬يجب أن تتصرف في مواقف معينة‪ .‬في بعض الحاالت ‪ ،‬تتطلب الوظيفة‪ -‬قد تشير اإلشارات أيضً ا‬
‫إلى ما ال ينبغي أن يفعله النظام‪ . 2 .‬المتطلبات غير الوظيفية هذه هي القيود المفروضة على الخدمات‪ W‬أو الوظائف التي يقدمها النظام‪.‬‬
‫وهي تشمل قيود التوقيت والقيود على التنمية عملية التشغيل ‪ ،‬والقيود التي تفرضها المعايير‪ .‬غير الوظيفية تتطلب‪ -‬غالبًا ما تنطبق‬
‫المالحظات على النظام ككل ‪ ،‬بدالً من النظام الفردي الميزات أو الخدمات‪ .‬في الواقع ‪ ،‬فإن التمييز بين أنواع المتطلبات المختلفة ليس‬
‫واضحً ا تما ًم ا كما توحي هذه التعريفات البسيطة‪ .‬مطلب مستخدم معني باألمان ‪ ،‬مثل بيان يقيد الوصول إلى المستخدمين المصرح لهم ‪،‬‬
‫قد يبدو أنه ليس ‪ -‬متطلبات وظيفية‪ .‬ومع ذلك ‪ ،‬عند تطوير هذا المطلب بمزيد من التفصيل قد تولد متطلبات أخرى تعمل بشكل واضح ‪،‬‬
‫مثل الحاجة إلى تضمين تسهيالت مصادقة المستخدم في النظام‪ .‬هذا يدل على أن المتطلبات ليست مستقلة وهذا مطلب واحد في كثير من‬
‫األحيان يولد أو يقيد متطلبات أخرى‪ .‬وبالتالي فإن متطلبات النظام ال تفعل ذلك ما عليك سوى تحديد الخدمات‪ W‬أو ميزات النظام‬
‫المطلوبة ؛ هم أيضا يحددون الوظائف الالزمة للتأكد من أن أطروحاتيتم تقديم الخدمات ‪ /‬الميزات اإللكترونية بشكل صحيح‪4.1.1 .‬‬
‫المتطلبات الوظيفية تصف المتطلبات الوظيفية لنظام ما ما يجب أن يفعله النظام‪ .‬هؤالء تعتمد المتطلبات على نوع البرامج التي يتم‬
‫تطويرها والمستخدمين المتوقعين لها البرنامج ‪ ،‬والنهج العام الذي تتبعه المنظمة عند الكتابة متطلبات‪ .‬عندما يتم التعبير عنها كمتطلبات‬
‫المستخدم ‪ ،‬تكون المتطلبات الوظيفية عادة ما يتم وصفه بطريقة مجردة يمكن أن يفهمها مستخدمو النظام‪ .‬ومع ذلك ‪ ،‬فإن متطلبات النظام‬
‫الوظيفية األكثر تحدي ًد ا تصف وظيفة النظام‪ -‬التفاصيل ‪ ،‬ومدخالتها ومخرجاتها ‪ ،‬واالستثناءات ‪ ،‬وما إلى ذلك ‪ ،‬بالتفصيل‪ .‬تختلف‬
‫متطلبات النظام الوظيفي عن المتطلبات العامة التي تغطي ماذا يجب أن يقوم النظام بمتطلبات محددة للغاية تعكس طرق العمل المحلية أو‬
‫األنظمة الحالية للمؤسسة‪ .‬على سبيل المثال ‪ ،‬فيما يلي أمثلة وظيفية مديري العمالء مستخدمو النظام مهندسو العميل مدراء المقاول‬
‫مهندسو النظام مستخدمو النظام مهندسو العميل مهندسو النظام مطوري البرامج مستخدم متطلبات نظام متطلبات الشكل ‪ 4.2‬القراء من‬
‫المستخدمة للحفاظ على ‪ MHC-PMS ،‬أنواع مختلفة من المتطلبات المواصفات ‪ 86‬الفصل ‪ 4‬المتطلبات الهندسية متطلبات نظام‬
‫المعلومات حول المرضى تلقي العالج لمشاكل الصحة العقلية‪ .1 :‬يجب أن يكون المستخدم قادرً ا على البحث في قوائم المواعيد لجميع‬
‫العيادات‪ . 2 .‬يجب أن يُنشئ النظام كل يوم ‪ ،‬لكل عيادة ‪ ،‬قائمة بالمرضى الموجودين من المتوقع أن يحضر المواعيد في ذلك اليوم‪.3 .‬‬
‫يتم تعريف كل موظف يستخدم النظام بشكل فريد من قبله رقم الموظف المكون من ثمانية أرقام‪ .‬تحدد متطلبات المستخدم الوظيفية هذه‬
‫التسهيالت المحددة التي سيقدمها‪ W‬نظام‪ .‬تم أخذ هذه من مستند متطلبات المستخدم وهي تظهر يمكن كتابة المتطلبات الوظيفية بمستويات‬
 ‫مختلفة من التفاصيل (على النقيض المتطلبات ‪ 1‬و ‪ .) 3‬عدم الدقة في مواصفات المتطلبات هو سبب العديد من مهندسي البرامج نيران‬
‫المشاكل‪ .‬من الطبيعي أن يقوم مطور النظام بتفسير الغموض المطلب بطريقة تبسط تنفيذه‪ .‬في كثير من األحيان ‪ ،‬هذا ليس كذلك ما يريده‬
‫الزبون‪ .‬يجب إنشاء متطلبات جديدة وإجراء تغييرات صنع للنظام‪ .‬بالطبع ‪ ،‬هذا يؤخر تسليم النظام ويزيد التكاليف‪ .‬على سبيل المثال ‪،‬‬
‫على أنه يجب على المستخدم تكون قادرة على البحث في قوائم المواعيد لجميع العيادات‪ MHC-PMS .‬ينص أول مثال متطلب لنظام‬
‫األساس المنطقي لهذا المطلب هو أن المرضى الذين يعانون من مشاكل الصحة العقلية يتم الخلط بينهم في بعض األحيان‪ .‬قد يكون لديهم‬
‫موعد في عيادة واحدة ولكن في الواقع اذهب إلى عيادة مختلفة‪ .‬إذا كان لديهم موعد‪ -‬منة ‪ ،‬سيتم تسجيلهم على أنهم حضروا ‪ ،‬بغض‬
‫النظر عن العيادة‪ .‬قد يتوقع عضو الطاقم الطبي الذي يحدد ذلك أن "البحث" يعني ذلك ‪ ،‬معطى اسم المريض ‪ ،‬يبحث النظام عن هذا‬
‫االسم في جميع المواعيد في جميع العيادات‪ .‬ومع ذلك ‪ ،‬هذا ليس صريحً ا في المطلب‪ .‬قد يفسر مطورو النظام ملف بطريقة مختلفة وقد‬
‫بحث ا بحيث يتعين على المستخدم القيام بذلك اختر عيادة ثم قم بالبحث‪ .‬من الواضح أن هذا سيتضمن المزيد من مدخالت المستخدم‬ ‫ينفذ ً‬
‫وهكذا يستغرق وقتا أطول‪ .‬من حيث المبدأ ‪ ،‬يجب أن تكون مواصفات المتطلبات الوظيفية للنظام كالهما كاملة ومتسقة‪ .‬يعني االكتمال‬
‫أن جميع الخدمات‪ W‬التي يطلبها المستخدم يجب تحديدها‪ .‬االتساق يعني أن المتطلبات ال ينبغي أن تكون متناقضة متطلبات المجال يتم‬
‫اشتقاق متطلبات المجال من مجال تطبيق النظام بدالً من ذلكمن المحدد احتياجات مستخدمي النظام‪ .‬قد تكون متطلبات وظيفية جديدة في‬
‫حد ذاتها ‪ ،‬تقيد الموجودة المتطلبات الوظيفية ‪ ،‬أو تحدد كيفية إجراء عمليات حسابية معينة‪ .‬تكمن مشكلة متطلبات المجال في أن مهندسي‬
‫البرمجيات قد ال يفهمون خصائص المجال الذي يعمل فيه النظام‪ .‬غالبًا ال يمكنهم معرفة ما إذا كان أحد متطلبات المجال يحتوي على أم‬
‫‪.‬ال تم تفويتها أو تعارضها مع المتطلبات األخرى‬
‫المتطلبات الوظيفية ‪http://www.SoftwareEngineering-9.com/Web/Requirements/DomainReq.html FPO4.1‬‬
‫وغير الوظيفية ‪ 87‬تعريفات‪ .‬في الممارسة العملية ‪ ،‬بالنسبة لألنظمة الكبيرة والمعقدة ‪ ،‬من المستحيل عمليا القيام بذلك تحقيق تناسق‬
‫واكتمال المتطلبات‪ .‬أحد أسباب ذلك هو أنه سهل الرتكاب األخطاء والسهو عند كتابة المواصفات لألنظمة المعقدة‪ .‬سبب آخر هو أن‬
‫هناك العديد من أصحاب المصلحة في نظام كبير‪ .‬صاحب المصلحة هو شخص أو دور يتأثر بالنظام بطريقة ما‪ .‬أصحاب المصلحة‬
‫مختلفون ‪ -‬وغالبًا ما تكون غير متسقة ‪ -‬االحتياجات‪ .‬قد ال تكون هذه التناقضات‪ W‬واضحة عند ملف يتم تحديد المتطلبات أوالً ‪ ،‬لذلك يتم‬
‫تضمين المتطلبات غير المتسقة في المواصفات‪ -‬الكاتيون‪ .‬قد تظهر المشاكل فقط بعد تحليل أعمق أو بعد النظام تم تسليمها للعميل‪.‬‬
‫‪ 4.1.2‬المتطلبات غير الوظيفية المتطلبات غير الوظيفية ‪ ،‬كما يوحي االسم ‪ ،‬هي متطلبات ليست كذلك يهتم بشكل مباشر بالخدمات‪W‬‬
‫المحددة التي يقدمها النظام لمستخدميه‪ .‬قد تتعلق بخصائص النظام الناشئة مثل الموثوقية ووقت االستجابة و إشغال المتجر‪ .‬بدالً من ذلك ‪،‬‬
‫يمكنهم تحديد قيود على تنفيذ النظام‪ -‬مثل إمكانيات أجهزة اإلدخال ‪ /‬اإلخراج أو تمثيالت البيانات المستخدمة في يواجه مع أنظمة أخرى‪.‬‬
‫المتطلبات غير الوظيفية ‪ ،‬مثل األداء أو األمان أو التوفر ‪ ،‬عاد ًة تحديد أو تقييد خصائص النظام ككل‪ .‬غير الوظيفية تتطلب‪ -‬غالبًا ما‬
‫تكون المالحظات أكثر أهمية من المتطلبات الوظيفية الفردية‪ .‬يمكن لمستخدمي النظام عاد ًة ما يجدون طر ًقا للتغلب على وظيفة نظام ال‬
‫تلبي احتياجاتهم ح ًق ا‪ .‬ومع ذلك ‪ ،‬فإن الفشل في تلبية متطلبات غير وظيفية يمكن أن يعني أن النظام بأكمله غير قابل لالستخدام‪ .‬على‬
‫سبيل المثال ‪ ،‬إذا كان نظام الطائرات ال يفي بمتطلبات الموثوقية الخاصة به ‪ ،‬لن يتم التصديق على أنها آمنة للتشغيل ؛ إذا فشل نظام‬
‫التحكم المدمج في تلبية متطلبات األداء ‪ ،‬وظائف التحكم لن تعمل بشكل صحيح‪ .‬على الرغم من أنه من الممكن في كثير من األحيان‬
‫تحديد مكونات النظام التي يتم تنفيذها متطلبات وظيفية محددة (على سبيل المثال ‪ ،‬قد تكون هناك مكونات التنسيق التي تنفيذ متطلبات‬
‫إعداد التقارير) ‪ ،‬غالبًا ما يكون من الصعب ربط المكونات بها متطلبات غير مجدية‪ .‬قد يكون تنفيذ هذه المتطلبات مختل ًفا‪ -‬منصهر في‬
‫جميع أنحاء النظام‪ .‬هناك سببان لهذا‪ . 1 :‬قد تؤثر المتطلبات غير الوظيفية على الهيكل العام للنظام بدال من المكونات الفردية‪ .‬على سبيل‬
‫المثال ‪ ،‬لضمان األداء استيفاء المتطلبات ‪ ،‬قد تضطر إلى تنظيم النظام لتقليل كوم االتصاالت بين المكونات‪ .2 .‬قد ينشأ عن مطلب واحد‬
‫غير وظيفي ‪ ،‬مثل مطلب األمن عدد من المتطلبات الوظيفية ذات الصلة التي تحدد خدمات النظام الجديدة التي مطلوبة‪ .‬باإلضافة إلى ذلك‬
‫ض ا إلى إنشاء متطلبات تقيد الموجودة متطلبات‪ .‬تنشأ المتطلبات غير الوظيفية من خالل احتياجات المستخدم ‪ ،‬بسبب‬ ‫‪ ،‬قد يؤدي أي ً‬
‫التزحزحر يخدع القيود والسياسات‪ W‬التنظيمية والحاجة إلى قابلية التشغيل البيني مع البرامج األخرى أو هندسة متطلبات الفصل الرابع ‪88‬‬
‫أنظمة األجهزة ‪ ،‬أو العوامل الخارجية مثل لوائح السالمة أو تشريعات‪ W‬الخصوصية‪ -‬نشوئها‪ .‬الشكل ‪ 4.3‬هو تصنيف للمتطلبات غير‬
‫الوظيفية‪ .‬يمكنك أن ترى من هذا الرسم البياني أن المتطلبات غير الوظيفية قد تأتي من السمات‪ W‬المطلوبة‪ -‬خصائص البرنامج (متطلبات‬
‫المنتج) ‪ ،‬تقوم المنظمة بتطوير البرمجيات وير (المتطلبات التنظيمية) ‪ ،‬أو من مصادر خارجية‪ .1 :‬متطلبات المنتج تحدد هذه المتطلبات‬
‫أو تقيد سلوك برمجة‪ .‬تتضمن األمثلة متطلبات األداء حول مدى سرعة النظام يجب أن تنفذ ومقدار الذاكرة التي تتطلبها ‪ ،‬ومتطلبات‬
‫الموثوقية التي تم تعيينها من معدل الفشل المقبول ومتطلبات األمان ومتطلبات قابلية االستخدام‪ .2 .‬المتطلبات التنظيمية هذه المتطلبات‬
‫هي متطلبات نظام واسعة المستمدة من السياسات واإلجراءات في منظمة العميل والمطور‪ -‬نشوئها‪ .‬تتضمن األمثلة متطلبات العملية‬
‫متطلبات عملية التطوير التي تحدد البرمجة اللغة أو بيئة التطوير أو معايير ‪ tem ،‬التشغيلية التي تحدد كيفية قيام النظام سيتم استخدام‬
‫التي تحدد بيئة تشغيل النظام‪ .3 .‬المتطلبات الخارجية يغطي هذا العنوان ‪ ronmental‬العملية التي سيتم استخدامها والبيئة‪ -‬المتطلبات‬
‫الواسع جميع المتطلبات مستمدة من عوامل خارجة عن النظام وعملية تطويره‪ .‬هؤالء قد تتضمن متطلبات تنظيمية تحدد ما يجب عمله‬
‫من قبل جهة تنظيمية ‪ ،‬مثل البنك المركزي ؛ تشريعي المتطلبات التي يجب اتباعها للتأكد من ‪ tem‬للنظام‪ -‬يجب الموافقة على استخدام‬
‫أن النظام يعمل داخل قانون؛ والمتطلبات األخالقية التي تضمن قبول النظام مستخدميها وعامة الناس‪ .‬أداء متطلبات فضاء‪ W‬متطلبات‬
 ‫سهولة االستخدام متطلبات كفاءة متطلبات االعتمادية متطلبات حماية متطلبات تنظيمية متطلبات أخالقي متطلبات تشريعي متطلبات‬
‫التشغيل متطلبات تطوير متطلبات بيئي متطلبات سالمة االمن متطلبات محاسبة متطلبات منتج متطلبات التنظيمية متطلبات خارجي‬
‫متطلبات غير وظيفية متطلبات الشكل ‪ 4.3‬أنواع غير وظيفية المتطلبات الوظيفية وغير الوظيفية ‪ 4.1‬المتطلبات الوظيفية وغير‬
‫التي تم تقديم ‪ MHC-PMS‬الوظيفية ‪ 89‬يوضح الشكل ‪ 4.4‬أمثلة على المنتجات والمتطلبات التنظيمية والمتطلبات الخارجية مأخوذة من‬
‫متطلبات المستخدم الخاصة بها في القسم ‪ . 4.1.1‬متطلبات المنتج هي مطلب التوفر الذي يحدد وقت النظام يجب أن تكون متاحة ووقت‬
‫وتحدد بوضوح القيد الذي يجب أن يؤخذ في االعتبار‪ -‬من قبل ‪ MHC-PMS‬التوقف المسموح به كل يوم‪ .‬ال تقول شيًئ ا عن وظيفة‬
‫مصممي النظام‪ .‬يحدد المتطلب التنظيمي كيفية مصادقة‪ W‬المستخدمين ألنفسهم إلى نظام‪ .‬تنتقل السلطة الصحية التي تشغل النظام إلى‬
‫مصادقة قياسية‪ -‬إجراء الكاتيون لجميع البرامج حيث ‪ ،‬بدالً من أن يكون لدى المستخدمين اسم تسجيل دخول ‪ ،‬فإنهم تمرير بطاقة هويتهم‬
‫من خالل قارئ للتعرف على أنفسهم‪ .‬تتطلب الخارجية‪ -‬منة مشتق من الحاجة إلى أن يتوافق النظام مع تشريعات الخصوصية‪.‬‬
‫خصوصية من الواضح أنها قضية مهمة للغاية في أنظمة الرعاية الصحية ويتم تحديد المتطلبات أنه يجب تطوير النظام وف ًقا لمعيار‬
‫الخصوصية الوطني‪ .‬مشكلة شائعة مع المتطلبات غير الوظيفية هي أن المستخدمين أوعمالء غالبًا ما يقترحون هذه المتطلبات كأهداف‬
‫عامة ‪ ،‬مثل سهولة االستخدام وقدرة يتعافى النظام من الفشل ‪ ،‬أو استجابة المستخدم السريعة‪ .‬األهداف المحددة حسن النية‪ -‬لكنها تسبب‬
‫مشاكل لمطوري النظام ألنها تترك مجااًل للتفسير والنزاع الالحق بمجرد تسليم النظام‪ .‬على سبيل المثال ‪ ،‬النظام التالي‪ -‬الهدف المؤقت‬
‫نموذجي لكيفية تعبير المدير عن متطلبات قابلية االستخدام‪ :‬يجب أن يكون النظام سهل االستخدام من قبل الطاقم الطبي ويجب أن يكون‬
‫منظ ًم ا فيه بهذه الطريقة يتم تقليل أخطاء المستخدم‪ .‬لقد أعدت كتابة هذا إلظهار كيف يمكن التعبير عن الهدف باعتباره "غير قابل‬
‫لالختبار" متطلبات وظيفية‪ .‬من المستحيل التحقق بشكل موضوعي من هدف النظام ‪ ،‬ولكن في الوصف أدناه يمكنك على األقل تضمين‬
‫أدوات برمجية لحساب األخطاء التي يرتكبها المستخدمون أثناء اختبارهم للنظام‪ .‬يجب أن يكون الطاقم الطبي قادرً ا على استخدام جميع‬
‫وظائف النظام بعد أربع ساعات من تمرين‪ .‬بعد هذا التدريب ‪ ،‬متوسط عدد األخطاء التي ارتكبتها التجربة‪ -‬يجب أال يتجاوز المستخدمون‬
‫المشفرون اثنين في الساعة من استخدام النظام‪ .‬كلما كان ذلك ممك ًن ا ‪ ،‬يجب عليك كتابة المتطلبات غير الوظيفية بشكل كمي حتى يمكن‬
‫اختبارها بشكل موضوعي‪ .‬يوضح الشكل ‪ 4.5‬المقاييس التي يمكنك استخدامها تحديد خصائص النظام غير الوظيفية‪ .‬يمكنك قياس هذه‬
‫متاحً ا لجميع ‪ MHC-PMS‬متطلبات المنتج يجب أن يكون ‪ MHC-PMS‬الخصائص الشكل ‪ 4.4‬أمثلة من غير وظيفية المتطلبات في‬
‫العيادات خالل ساعات العمل العادية (من االثنين إلى الجمعة ‪ ،‬من الساعة ‪ 8:30‬إلى الساعة ‪ .)17:30‬التوقف يجب أال تتجاوز ساعات‬
‫المصادقة‪ W‬على أنفسهم باستخدام ‪ MHC-PMS‬العمل العادية خمس ثوان في أي يوم واحد‪ .‬المتطلبات التنظيمية يجب على مستخدمي نظام‬
‫بطاقة هوية الهيئة الصحية الخاصة بهم‪ .‬المتطلبات الخارجية يجب أن ينفذ النظام أحكام خصوصية المريض على النحو المنصوص عليه‬
‫الفصل الرابع هندسة المتطلبات عندما يتم اختبار النظام للتحقق مما إذا كان النظام قد استوفى أم ال ‪ HStan-03-2006-priv.90‬في‬
‫المتطلبات الوظيفية‪ .‬من الناحية العملية ‪ ،‬غالبًا ما يجد عمالء النظام صعوبة في ترجمة أهدافهم في متطلبات قابلة للقياس‪ .‬بالنسبة لبعض‬
‫‪-‬األهداف ‪ ،‬مثل قابلية الصيانة ‪ ،‬ال يوجد المقاييس التي يمكن استخدامها‪ .‬في حاالت أخرى ‪ ،‬حتى عندما تكون المواصفات الكمية ممكنة‬
‫قد ال يتمكن العمالء من ربط احتياجاتهم بهذه المواصفات‪ .‬هم ال تفهم ما يعنيه بعض األرقام التي تحدد الموثوقية المطلوبة (على ‪sible ،‬‬
‫سبيل المثال) من حيث خبرتهم اليومية مع أنظمة الكمبيوتر‪ .‬عالوة على ذلك ‪ ،‬فإن تكلفة التحقق الموضوعي من المتطلبات غير الوظيفية‬
‫والقابلة للقياس يمكن أن يكون مرتفعًا ً‬
‫جد ا و قد ال يعتقد العمالء الذين يدفعون مقابل النظام أن هذه التكاليف مبررة‪ .‬غالبًا ما تتعارض‬
‫المتطلبات غير الوظيفية وتتفاعل مع الوظائف األخرى أو غير وظيفية‪ .‬على سبيل المثال ‪ ،‬متطلبات المصادقة‪ W‬في من الواضح أن الشكل‬
‫‪ 4.4‬يتطلب تثبيت قارئ بطاقات‪ W‬مع كل كمبيوتر تعلق على النظام‪ .‬ومع ذلك ‪ ،‬قد يكون هناك مطلب آخر يطلب الوصول المحمول إلى‬
‫النظام من أجهزة الكمبيوتر المحمولة لألطباء أو الممرضات‪ .‬هذه ليست بالعادة مجهزة بقارئات البطاقات ‪ ،‬لذلك ‪ ،‬في هذه الظروف ‪،‬‬
‫بعض المصادقة البديلة‪ -‬قد يتعين السماح بطريقة نشوئها‪ .‬من الصعب ‪ ،‬من الناحية العملية ‪ ،‬الفصل بين المتطلبات الوظيفية وغير‬
‫الوظيفية في وثيقة المتطلبات‪ .‬إذا تم تحديد المتطلبات غير الوظيفية بشكل منفصل‪ -‬في اآلونة األخيرة من المتطلبات الوظيفية ‪ ،‬قد تكون‬
‫ً‬
‫صراحة ه بوضوح المتعلقة بخصائص النظام الناشئة ‪ ،‬مثل األداء أو‬ ‫العالقات بينهما صعبة لفهم‪ .‬ومع ذلك ‪ ،‬يجب عليك إبراز المتطلبات‬
‫الموثوقية‪ .‬يمكنك ان تفعل هذا عن طريق وضعها في قسم منفصل من وثيقة المتطلبات أو عن طريق تمييز‪ -‬توجيههم ‪ ،‬بطريقة ما ‪ ،‬من‬
‫متطلبات النظام األخرى‪ .‬الشكل ‪ 4.5‬المقاييس لتحديد غير وظيفية متطلبات قياس الملكية سرعة معالجة المعامالت‪ / W‬ثانية وقت استجابة‬
‫المستخدم ‪ /‬الحدث وقت تحديث الشاشة الحجم ميغا بايت عدد شرائح ذاكرة القراءة فقط سهولة االستخدام وقت التدريب عدد إطارات‬
‫المساعدة الموثوقية تعني وقت الفشل احتمال عدم التوفر معدل حدوث الفشل التوفر المتانة وقت إعادة التشغيل بعد الفشل نسبة األحداث‬
‫المسببة للفشل احتمال تلف البيانات عند الفشل إمكانية النقل النسبة المئوية للبيانات التابعة للهدف عدد األنظمة المستهدفة ‪ 4.2‬وثيقة‬
‫معايير ‪ IEEE ،‬متطلبات وثيقة المعايير حدد عدد من المنظمات الكبيرة ‪ ،‬مثل وزارة الدفاع األمريكية و ‪ FPO‬متطلبات البرمجيات ‪91‬‬
‫محددة لوثائق المتطلبات‪ .‬هذه عاد ًة ما تكون عامة ج ًد ا ولكنها مع ذلك مفيدة كأساس لها تطوير معايير تنظيمية أكثر تفصيالً‪ .‬المعهد‬
‫هو أحد أشهر موفري المعايير وقد طوروا معيارً ا لهيكل مستندات المتطلبات‪ .‬هذا )‪ (IEEE‬األمريكي للمهندسين الكهربائيين واإللكترونيين‬
‫المعيار هو األنسب ألنظمة مثل القيادة والسيطرة العسكرية األنظمة التي لها عمر طويل وعادة ما يتم تطويرها من قبل مجموعة من‬
‫المتطلبات غير ‪. http://www.SoftwareEngineering-9.com/Web/Requirements/IEEE-standard.html‬المنظمات‬
‫الوظيفية مثل الموثوقية والسالمة والسرية المتطلبات مهمة بشكل خاص لألنظمة الحرجة‪ .‬أنا أغطي هذه تتطلب‪ -‬إشارات في الفصل‬
‫تسمى ( ومتطلبات األمن‪ 4.2 .‬وثيقة متطلبات البرنامج وثيقة متطلبات البرنامج ‪ ، 12- ity‬حيث أصف تقنيات محددة لتحديد االعتماد‬
‫بيان رسمي لما يجب على مطوري النظام ينفذ‪ .‬يجب أن يتضمن كالً من متطلبات )‪ SRS‬أحيا ًنا متطلبات البرنامج المواصفات أو‬
‫المستخدم لنظام وتفاصيل مواصفات متطلبات النظام‪ .‬في بعض األحيان ‪ ،‬يطلب المستخدم والنظام‪ -‬يتم دمج اإلشارات في وصف واحد‪.‬‬
‫في حاالت أخرى ‪ ،‬متطلبات المستخدم تم تعريفها في مقدمة لمواصفات متطلبات النظام‪ .‬إذا كان هناك ملف عد ًدا كبيرً ا من المتطلبات ‪،‬‬
‫يمكن تقديم متطلبات النظام التفصيلية في وثيقة منفصلة‪ .‬تعد مستندات المتطلبات ضرورية عند تطوير مقاول خارجي نظام البرنامج‪.‬‬
‫ومع ذلك ‪ ،‬فإن أساليب التطوير الرشيقة تجادل بهذه المتطلبات التغيير سريعً ا لدرجة أن مستند المتطلبات أصبح قديمًا بمجرد كتابته ‪،‬‬
‫متطلبات )‪ Extreme Programming (Beck، 1999‬لذلك يضيع الجهد إلى حد كبير‪ .‬بدالً من وثيقة رسمية ‪ ،‬مناهج مثل تجمع‬
‫المستخدم بشكل تدريجي و اكتب هذه على البطاقات‪ W‬كقصص للمستخدمين‪ .‬ثم يعطي المستخدم األولوية لمتطلبات تنفيذ‪ -‬اإلرشاد في‬
‫الزيادة التالية للنظام‪ .‬بالنسبة ألنظمة األعمال حيث المتطلبات غير مستقرة ‪ ،‬أعتقد أن هذا النهج فكرة جيدة‪ .‬ومع ذلك ‪ ،‬أعتقد أنه ال يزال‬
‫من المفيد كتابة مستند دعم قصير‪ -‬منة تحدد متطلبات العمل واالعتمادية للنظام ؛ إنها يسهل نسيان المتطلبات التي تنطبق على النظام‬
‫ككل عند التركيز عليه المتطلبات الوظيفية إلصدار النظام التالي‪ .‬يحتوي مستند المتطلبات على مجموعة متنوعة من المستخدمين ‪،‬‬
‫تتراوح منكبير إدارة المؤسسة التي تدفع ثمن النظام للمهندسين مسؤول عن تطوير البرنامج‪ .‬الشكل ‪ ، 4.6‬مأخوذ من كتابي مع جيرالد‬
‫عروض المستخدمين المحتملين للوثيقة وكيفية استخدامها‪ (Kotonya and Sommerville ، 1998) .‬كوتونيا حول متطلبات الهندسة‬
‫‪ 92‬الفصل ‪ - 4‬المتطلبات الهندسية استخدم المتطلبات لـ تطوير اختبارات التحقق من الصحة النظام‪ .‬استخدم المتطلبات وثيقة للتخطيط‬
‫لتقديم العطاءات‪ W‬النظام وتخطيط عملية تطوير النظام‪ .‬استخدم المتطلبات لـ فهم ما هو النظام لتطويرها‪ .‬نظام اختبار المهندسين المديرين‬
‫نظام المهندسين حدد المتطلبات و اقرأها للتحقق من أنها تلبية احتياجاتهم‪ .‬عمالء تحديد التغييرات على متطلبات‪ .‬نظام عمالء استخدم‬
‫المتطلبات لـ فهم النظام و العالقات بين أجزائه‪ .‬نظام صيانة المهندسين الشكل ‪ 4.6‬مستخدمو أ وثيقة المتطلبات تنوع المستخدمين‬
‫المحتملين يعني أن وثيقة المتطلبات يجب أن تكون أ حل وسط بين توصيل المتطلبات للعمالء‪ W‬وتحديد المتطلبات بالتفصيل الدقيق‬
‫للمطورين والمختبرين ‪ ،‬بما في ذلك المعلومات حول التطور المحتمل للنظام‪ .‬يمكن أن تساعد المعلومات المتعلقة بالتغييرات المتوقعة‬
‫الذين يتعين عليهم تكييف النظام ‪ neers‬قرارات التصميم التقييدية ويساعدون مهندسي صيانة النظام ‪ tem‬على النظام‪ -‬يتجنب مصممو‬
‫مع المتطلبات الجديدة‪ .‬يعتمد مستوى التفاصيل التي يجب تضمينها في مستند المتطلبات على نوع النظام الذي يتم تطويره وعملية‬
‫بالتفصيل‪ .‬عندما يتم ‪ - lyzed‬التطوير المستخدمة‪ .‬شديد األهمية تحتاج األنظمة إلى متطلبات مفصلة ألن السالمة واألمن يجب أن يكونا‬
‫تطوير النظام من قبل شركة منفصلة (على سبيل المثال ‪ ،‬من خالل االستعانة بمصادر خارجية) ‪ ،‬يجب أن تكون مواصفات النظام‬
‫مفصلة ودقيقة‪ .‬إذا كان في‪ -‬المنزل ‪ ،‬يتم استخدام عملية التطوير التكراري ‪ ،‬يمكن أن تكون وثيقة المتطلبات كثيرً ا أقل تفصيالً ويمكن‬
‫لمستندات ‪ IEEE‬حل أي غموض أثناء تطوير النظام‪ .‬يوضح الشكل ‪ 4.7‬منظمة واحدة محتملة لمستند المتطلبات وهو بنا ًء على معيار‬
‫هذا المعيار هو معيار عام يمكن تكييفه مع استخدامات محددة‪ .‬في هذه الحالة لدي مدد المعيار ليشمل ‪ (IEEE ، 1998).‬المتطلبات‬
‫معلومات حول تطور النظام المتوقع‪ .‬هذا تساعد المعلومات‪ W‬القائمين على صيانة النظام وتسمح للمصممين بتضمين الدعم منفذ لميزات‬
‫النظام المستقبلية‪ .‬بطبيعة الحال ‪ ،‬تعتمد المعلومات المضمنة في مستند المتطلبات على نوع البرمجيات التي يجري تطويرها ونهج‬
‫التطوير الذي هو يستخدم‪ .‬إذا تم اعتماد نهج تطوري لمنتج برمجي (على سبيل المثال) ‪ ،‬فإن ‪ 4.2‬وثيقة متطلبات البرنامج ‪ 93‬الشكل‬
‫‪ 4.7‬هيكل أ متطلبات وثيقة وثيقة المتطلبات ستترك العديد من الفصول التفصيلية المقترحة أعاله‪ .‬وسينصب التركيز على تحديد متطلبات‬
‫المستخدم رفيعة المستوى وغير وظيفية متطلبات النظام‪ .‬في هذه الحالة ‪ ،‬يستخدم المصممون والمبرمجون حكمهم‪ W‬لتقرير كيفية تلبية‬
‫متطلبات المستخدم التفصيلية للنظام‪ .‬ومع ذلك ‪ ،‬عندما يكون البرنامج جز ًء ا من مشروع نظام كبير يتضمن التفاعل‪ -‬في أنظمة األجهزة‬
‫والبرامج ‪ ،‬من الضروري عادة تحديد المتطلبات وصف الفصل تمهيد يجب أن يحدد هذا القارئ القراء المتوقعين للوثيقة ويصفها‬
‫محفوظات اإلصدار ‪ ،‬بما في ذلك األساس المنطقي إلنشاء إصدار جديد و ملخص التغييرات التي تم إجراؤها في كل إصدار‪ .‬مقدمة هذا‬
‫شولد وصف الحاجة إلى النظام‪ .‬يجب أن يصف بإيجاز وظائف النظام وشرح كيف سيعمل مع األنظمة األخرى‪ .‬أنه ينبغي صف أيضًا‬
‫كيف يتناسب النظام مع األعمال التجارية أو االستراتيجية بشكل عام أهداف المنظمة بتكليف البرنامج‪ .‬المسرد يجب أن يحدد‬
‫المصطلحات الفنية المستخدمة في المستند‪ .‬ال يجب عليك أن وضع افتراضات حول تجربة أو خبرة القارئ‪ .‬متطلبات المستخدم تعريف‬
‫ض ا وصف متطلبات النظام في هذا القسم‪ .‬هذا قد يستخدم الوصف لغة‬ ‫هنا ‪ ،‬تصف الخدمات‪ W‬المقدمة للمستخدم‪ .‬غير وظيفية يجب أي ً‬
‫طبيعية أو رسوم بيانية أو رموز أخرى مفهومة للعمالء‪ .‬معايير المنتج والعملية التي يجب أن تكون يجب تحديد ما يلي‪ .‬بنية النظام يجب‬
‫أن يقدم هذا الفصل نظرة عامة رفيعة المستوى على النظام المتوقع العمارة ‪ ،‬توضح توزيع الوظائف عبر وحدات النظام‪ .‬يجب إبراز‬
‫المكونات المعمارية التي يعاد استخدامها‪ .‬متطلبات النظام تخصيص يجب أن يصف هذا المتطلبات الوظيفية وغير الوظيفية في المزيد‬
‫ض ا إضافة مزيد من التفاصيل إلى الوظائف غير الوظيفية متطلبات‪ .‬يمكن تحديد واجهات أنظمة‬ ‫التفاصيل‪ .‬إذا لزم األمر ‪ ،‬يمكن أي ً‬
‫أخرى‪ .‬نماذج النظام قد يشمل ذلك نماذج نظام رسومية توضح العالقات‪ W‬بين مكونات النظام والنظام وبيئته‪ .‬أمثلة ممكنة‪ W‬النماذج هي‬
‫نماذج الكائنات أو نماذج تدفق البيانات أو نماذج البيانات الداللية‪ .‬تطور النظام يجب أن يصف هذا االفتراضات األساسية‪ W‬التي يقوم عليها‬
‫النظام على أساس ‪ ،‬وأي تغييرات متوقعة بسبب تطور األجهزة ‪ ،‬والتغيير احتياجات المستخدم ‪ ،‬وما إلى ذلك‪ .‬هذا القسم مفيد لمصممي‬
‫النظام قدر المستطاع تساعدهم على تجنب قرارات التصميم التي من شأنها تقييد التغييرات المحتملة في المستقبل للنظام‪ .‬المالحق يجب‬
 ‫أن توفر هذه المعلومات معلومات مفصلة ومحددة تتعلق بـ التطبيق قيد التطوير ؛ على سبيل المثال ‪ ،‬أوصاف األجهزة وقاعدة البيانات‪.‬‬
‫تحدد متطلبات األجهزة الحد األدنى واألمثل من التكوينات لـ نظام‪ .‬تحدد متطلبات قاعدة البيانات التنظيم المنطقي للبيانات المستخدمة‬
‫بواسطة النظام والعالقات‪ W‬بين البيانات‪ .‬فهرس قد يتم تضمين عدة فهارس للوثيقة‪ .‬وكذلك طبيعي فهرس أبجدي ‪ ،‬قد يكون هناك فهرس‬
‫من الرسوم البيانية ‪ ،‬فهرس للوظائف ‪ ،‬وما إلى ذلك‪ 94 .‬الفصل ‪ - 4‬متطلبات الهندسة إلى مستوى جيد من التفاصيل‪ .‬هذا يعني أنه من‬
‫جد ا ويجب أن تشمل معظم إن لم يكن كل الفصول الموضحة في الشكل ‪ .4.7‬ل المستندات‬ ‫المحتمل أن تكون مستندات المتطلبات طويلة ً‬
‫الطويلة ‪ ،‬فمن المهم بشكل خاص تضمين جدول شامل للمراقبة الخيام وفهرس المستندات حتى يتمكن القراء من العثور على المعلومات‪W‬‬
‫التي يحتاجون إليها‪ 4.3 .‬مواصفات المتطلبات مواصفات المتطلبات هي عملية تدوين المستخدم‪ W‬والنظام المتطلبات في وثيقة المتطلبات‪.‬‬
‫من الناحية المثالية ‪ ،‬متطلبات المستخدم والنظام يجب أن تكون واضحة ‪ ،‬ال لبس فيها ‪ ،‬سهلة الفهم ‪ ،‬كاملة ‪ ،‬ومتسقة‪ .‬في براك‪ -‬ولكن‬
‫من الصعب تحقيق ذلك ألن أصحاب المصلحة يفسرون المتطلبات بشكل مختلف طرق وغالبًا ما تكون هناك تعارضات وتناقضات‪W‬‬
‫متأصلة في المتطلبات‪ .‬يجب أن تصف متطلبات المستخدم للنظام ما هو وظيفي وغير المتطلبات الوظيفية بحيث تكون مفهومة من قبل‬
‫مستخدمي النظام الذين ليس لديهم معرفة فنية مفصلة‪ .‬من الناحية المثالية ‪ ،‬يجب أن يحددوا فقط السلوك الخارجي لـ النظام‪ .‬يجب أال‬
‫محاضرة أو تصميم‪ .‬وبالتالي ‪ ،‬إذا كنت تكتب متطلبات المستخدم ‪ ،‬فال يجب عليك ذلك ‪ archi-‬تتضمن وثيقة المتطلباتتفاصيل نظام‬
‫استخدام المصطلحات البرمجية أو الرموز المنظمة أو الرموز الرسمية‪ .‬يجب عليك كتابة المستخدم متطلبات اللغة الطبيعية ‪ ،‬مع الجداول‬
‫والنماذج البسيطة والمخططات البديهية‪ .‬متطلبات النظام هي إصدارات موسعة من متطلبات المستخدم التي يتم استخدامها بواسطة‬
‫مهندسي البرمجيات كنقطة انطالق لتصميم النظام‪ .‬يضيفون التفاصيل و اشرح كيف يجب أن يوفر النظام متطلبات المستخدم‪ .‬قد يكونوا‬
‫ُت ستخدم كجزء من عقد تنفيذ النظام ويجب أن ‪ -‬أن تكون مواصفات كاملة ومفصلة للنظام بأكمله‪ .‬من الناحية المثالية ‪ ،‬يجب أن تصف‬
‫متطلبات النظام ببساطة السلوك الخارجي للنظام وقيوده التشغيلية‪ .‬ال ينبغي أن يهتموا بالكيفية يجب تصميم النظام أو تنفيذه‪ .‬ومع ذلك ‪،‬‬
‫على مستوى التفاصيل مطلوبًا لتحديد نظام برمجي معقد تمامًا ‪ ،‬فمن المستحيل عمليًا‪ -‬بلي الستبعاد جميع معلومات التصميم‪ .‬هناك عدة‬
‫‪ FPO‬أسباب لذلك‪ . 1 :‬قد تضطر إلى تصميم بنية أولية للنظام للمساعدة في هيكلة مواصفات المتطلبات‪ .‬يتم تنظيم متطلبات النظام وف ًقا لـ‬
‫مشاكل استخدام اللغة الطبيعية لمواصفات المتطلبات غالبًا ما تسبب مرونة اللغة الطبيعية ‪ ،‬والتي تعد مفيدة ج ًدا في المواصفات ‪،‬‬
‫مشكالت‪ .‬هناك مجال ل كتابة متطلبات غير واضحة ‪ ،‬وقد يسيء القراء (المصممون) تفسير المتطلبات ألن لديهم خلفية مختلفة‬
‫‪.‬للمستخدم‪ .‬من السهل دمج العديد من المتطلبات في جملة واحدة و قد يكون من الصعب هيكلة متطلبات اللغة الطبيعية‬
‫مواصفات المتطلبات ‪http://www.SoftwareEngineering-9.com/Web/Requirements/NL-problems.html4.3 95‬‬
‫األنظمة الفرعية المختلفة التي يتكون منها النظام‪ .‬كما أناقش في الفصول ‪ 6‬و ‪ ، 18‬هذا التعريف المعماري ضروري إذا كنت ترغب في‬
‫إعادة استخدام البرنامج المكونات عند تنفيذ النظام‪ . 2 .‬في معظم الحاالت ‪ ،‬يجب أن تتفاعل األنظمة مع األنظمة الموجودة ‪ ،‬والتي تقيد‬
‫لتحقيق ‪ N‬مثل كبرمجة إصدار( تصميم وفرض المتطلبات على النظام الجديد‪ .3 .‬استخدام بنية محددة لتلبية المتطلبات غير الوظيفية‬
‫كن ضروريا‪ .‬منظم خارجي يحتاج إلى التصديق على أن النظام آمن قد تحدد استخدام تصميم )الموثوقية ‪ ،‬تمت مناقشتها‪ W‬في الفصل ‪13‬‬
‫معماري معتمد بالفعل‪ .‬تتم كتابة متطلبات المستخدم دائ ًم ا باللغة الطبيعية مكملة عن طريق المخططات والجداول المناسبة في وثيقة‬
‫ضا أن تكون النماذج أو نماذج النظام‬ ‫ض ا كتابة المتطلبات بلغة طبيعية ولكن تستند إلى رموز أخرى يمكن أي ً‬‫المتطلبات‪ .‬نظام يمكن أي ً‬
‫الرسومية أو نماذج األنظمة الرياضية مستخدم‪ .‬يلخص الشكل ‪ 4.8‬الرموز الممكنة التي يمكن استخدامها للكتابة متطلبات النظام‪ .‬تكون‬
‫النماذج الرسومية مفيدة للغاية عندما تحتاج إلى إظهار كيف تتغير الحالة أو عندما تحتاج إلى وصف سلسلة من اإلجراءات‪ .‬مخططات‬
‫استجابة لذلك لرسالة أو ‪ UML‬تسلسل‬ ‫ً‬ ‫والحالة توضح الرسوم البيانية ‪ ،‬الموصوفة في الفصل الخامس‪ ، W‬تسلسل اإلجراءات التي تحدث‬
‫حدث معين‪ .‬المواصفات الرياضية الرسمية في بعض األحيان تستخدم لوصف متطلبات أنظمة السالمة أو األمن الحرجة ‪ ،‬ولكنها كذلك‬
‫نادرا ما تستخدم في ظروف أخرى‪ .‬أشرح هذا النهج لكتابة المواصفات في الفصل ‪ .12‬الشكل ‪ 4.8‬طرق كتابة نظام متطلبات تخصيص‬
‫تتم كتابة المتطلبات اإللكترونية باستخدام جمل مرقمة باللغة الطبيعية لغة‪ .‬يجب أن تعبر كل جملة ‪ Th‬وصف التدوين جمل اللغة الطبيعية‬
‫عن مطلب واحد‪ .‬اللغة الطبيعية المهيكلة المتطلبات مكتوبة بلغة طبيعية في شكل قياسي أو نموذج‪ .‬يوفر كل حقل معلومات حول جانب‬
‫من جوانب متطلبات‪ .‬لغات وصف التصميم يستخدم هذا األسلوب لغة مثل لغة البرمجة ‪ ،‬ولكن مع المزيد من الميزات المجردة لتحديد‬
‫المتطلبات من خالل تحديد ملف النموذج التشغيلي للنظام‪ .‬نادرا ما يستخدم هذا النهج اآلن على الرغم من أنه يمكن أن يكون مفي ًدا‬
‫لمواصفات الواجهة‪ .‬المالحظات الرسومية تستخدم النماذج الرسومية ‪ ،‬مدعومة بتعليقات توضيحية نصية ‪ ،‬للتعريف المتطلبات الوظيفية‬
‫وتسلسلها يشيع استخدام المخططات‪ .‬المواصفات الرياضية تستند هذه الرموز إلى مفاهيم رياضية مثل ‪ UML‬للنظام ؛ حالة استخدام‬
‫الحالة المحدودة آالت أو مجموعات‪ .‬على الرغم من أن هذه المواصفات ال لبس فيها يمكن أن تقلل الغموض في مستند المتطلبات ‪ ،‬ال‬
‫يفعله معظم العمالء فهم المواصفات الرسمية‪ .‬ال يمكنهم التحقق من أنه يمثل ما يريدون ويترددون في قبوله كعقد نظام (‪ .)96‬متطلبات‬
‫هندسة الفصل الرابع ‪ 4.3.1‬مواصفات اللغة الطبيعية تم استخدام اللغة الطبيعية لكتابة متطلبات البرامج منذ البداية هندسة البرمجيات‪ .‬إنه‬
‫ض ا غامض وغامض ويعتمد معناه على خلفية القارئ‪ .‬ك نتيجة لذلك ‪ ،‬كان هناك العديد من‬ ‫معبر وبديهي وعالمي‪ .‬من المحتمل أي ً‬
‫المقترحات لطرق بديلة لكتابة المتطلبات‪ .‬ومع ذلك ‪ ،‬لم يتم اعتماد أي من هذه على نطاق واسع وستستمر اللغة الطبيعية لتكون الطريقة‬
‫األكثر استخدا ًم ا لتحديد متطلبات النظام والبرامج‪ .‬لتقليل سوء الفهم عند كتابة متطلبات اللغة الطبيعية ‪ ،‬أوصي باتباع بعض اإلرشادات‬
 ‫البسيطة‪ .1 :‬اخترع تنسي ًقا قياس ًي ا وتأكد من أن جميع تعريفات المتطلبات تلتزم به هذا الشكل‪ .‬يؤدي توحيد التنسيق إلى تقليل احتمالية‬
‫اإلغفال ويتطلب‪ -‬من األسهل التحقق من اإلشارات‪ .‬يعبر التنسيق الذي أستخدمه عن المتطلبات في ملف واحد جملة‪ .‬أقوم بربط بيان‬
‫ضا معلومات عن من اقترح المتطلب‬ ‫األساس المنطقي بمتطلبات كل مستخدم لـ شرح سبب اقتراح المتطلب‪ .‬قد يشمل األساس المنطقي أي ً‬
‫(مصدر المتطلبات) بحيث أنت تعرف من تستشيره إذا كان ال بد من تغيير الشرط‪ .2 .‬استخدم اللغة باستمرار للتمييز بين اإللزامي‬
‫وعادة ما يتم كتابتها باستخدام "يجب"‪ support .‬والمطلوب متطلبات‪ .‬المتطلبات اإللزامية هي المتطلبات التي يجب أن يقوم بها النظام‬
‫المتطلبات المرغوبة ليست كذلك أساسية ومكتوبة باستخدام "ينبغي"‪ . 3 .‬استخدم تمييز النص (غامق أو مائل أو ملون) النتقاء األجزاء‬
‫الرئيسية من المتطلب‪ . 4 .‬ال تفترض أن القراء يفهمون لغة هندسة البرمجيات التقنية‪ .‬من السهل أن يساء فهم كلمات مثل "الهندسة‬
‫المعمارية" و "الوحدة"‪ .‬أنت لذلك ‪ ،‬يجب تجنب استخدام المصطلحات‪ W‬واالختصارات والمختصرات‪ .5 .‬كلما كان ذلك ممك ًنا ‪ ،‬يجب أن‬
‫تحاول ربط األساس المنطقي بكل مستخدم متطلبات‪ .‬يجب أن يشرح األساس المنطقي سبب وجود الشرط متضمن‪ .‬إنها مفيدة بشكل‬
‫خاص عندما يتم تغيير المتطلبات ألنها قد تساعد تحديد التغييرات التي قد تكون غير مرغوب فيها‪ .‬يوضح الشكل ‪ 4.9‬كيف يمكن‬
‫استخدام هذه اإلرشادات‪ .‬يتضمن اثنين تتطلب‪ -‬مالحظات‪ W‬للبرنامج المضمن لمضخة األنسولين اآللية ‪ ،‬التي تم إدخالها في الفصل ‪.1‬‬
‫يمكنك تنزيل المواصفات الكاملة لمتطلبات مضخة األنسولين منصفحات‪ W‬الويب للكتاب‪ 3.2 .‬يقوم النظام بقياس نسبة السكر في الدم‬
‫وتوصيل األنسولين ‪ ،‬إذا لزم األمر ‪ ،‬كل ‪ 10‬دقائق‪( .‬تغييرات في نسبة السكر في الدم بطيئة نسبيًا لذا فإن القياس األكثر تكرارً ا غير‬
‫ضروري ؛ قياس أقل تواترا يمكن أن يؤدي إلى ارتفاع مستويات السكر دون داع‪ 3.6 ).‬يجب أن يقوم النظام بإجراء اختبار ذاتي‬
‫روتيني كل دقيقة مع الشروط المراد اختبارها وما يرتبط بها اإلجراءات المحددة في الجدول ‪( .1‬يمكن لروتين االختبار الذاتي اكتشاف‬
‫مشاكل األجهزة والبرامج وتنبيه المستخدم إلى حقيقة أن العملية العادية قد تكون مستحيلة‪ ).‬الشكل ‪ 4.9‬متطلبات المثال لمضخة األنسولين‬
‫نظام البرامج ‪ 4.3‬مواصفات المتطلبات ‪ 4.3.2 97‬المواصفات الهيكلية اللغة الطبيعية المهيكلة هي طريقة لكتابة متطلبات النظام حيث‬
‫حرية كاتب المتطلبات محدودة وكل المتطلبات مكتوبة في أ الطريقة القياسية‪ .‬يحافظ هذا النهج على معظم التعبيرات والفهم‪ -‬القدرة على‬
‫اللغة الطبيعية ولكنها تضمن أن يتم فرض بعض التوحيد على تخصيص‪ .‬تستخدم تدوينات اللغة المنظمة القوالب لتحديد النظام متطلبات‪.‬‬
‫قد تستخدم المواصفات تراكيب لغة البرمجة لـ إظهار البدائل والتكرار ‪ ،‬وقد يبرز العناصر األساسية‪ W‬باستخدام التظليل أو خطوط مختلفة‪.‬‬
‫يوصى بأن تكون متطلبات ‪ VOLERE ،‬روبرتسون (روبرتسون وروبرتسون ‪ ، )1999 ،‬في كتابهما عن طريقة هندسة متطلبات‬
‫المستخدم مكتوبًا في البداية على البطاقات‪ ، W‬شرط واحد لكل بطاقة‪ .‬يقترحون عددا من الحقول الموجودة في كل بطاقة ‪ ،‬مثل مبررات‬
‫المتطلبات ‪ ،‬واالعتماد على أخرى المتطلبات ‪ ،‬ومصدر المتطلبات ‪ ،‬والمواد الداعمة ‪ ،‬وما إلى ذلك‪ .‬هذا مشابه للنهج المستخدم في مثال‬
‫المواصفات الهيكلية الموضحة في الشكل ‪ . 4.10‬الستخدام نهج منظم لتحديد متطلبات النظام ‪ ،‬يمكنك تحديد واحد أو المزيد من القوالب‬
‫الوظائف ‪- tem ،‬القياسية للمتطلبات وتمثيل هذه القوالب كمنظمة نماذج‪ .‬قد يتم تنظيم المواصفات حول الكائنات التي يتالعب بها النظام‬
‫التي يؤديها النظام ‪ ،‬أو األحداث التي يعالجها النظام‪ .‬ان مثال على المواصفات المستندة إلى النموذج ‪ ،‬في هذه الحالة ‪ ،‬أحد المواصفات‬
‫التي تحدد كيفية حساب جرعة األنسولين المراد توصيلها عندما يكون سكر الدم ضمن النطاق اآلمن ‪ ،‬موضح في الشكل ‪ .4.10‬مضخة‬
‫الوظيفة حساب جرعة األنسولين‪ :‬مستوى السكر اآلمن‪ .‬الوصف يحسب جرعة األنسولين ‪ / SRS / 3.3.2‬األنسولين ‪ /‬برنامج التحكم‬
‫‪ (r2) ،‬التي سيتم توصيلها عندما يكون مستوى السكر المقاس حاليًا المنطقة اآلمنة بين ‪ 3‬و ‪ 7‬وحدات‪ .‬المدخالت قراءة السكر الحالية‬
‫الجرعة ‪ CompDose -‬مصدر قراءة السكر الحالية من المستشعر‪ .‬قراءات أخرى من الذاكرة‪ .‬النواتج ‪ r1).‬و ‪ (r0‬القراءتان السابقتان‬
‫في األنسولين المراد توصيلها‪ .‬حلقة التحكم الرئيسية الوجهة‪ .‬تكون تركيبة اإلجراء هي صفر إذا كان مستوى السكر مستقرً ا أو ينخفض‬
‫بقسمة ‪ CompDose‬أو إذا كان المستوى يتزايد ولكن معدل الزيادة يتناقص‪ .‬إذا كان المستوى يتزايد ومعدل الزيادة زيادة ‪ ،‬ثم يتم حساب‬
‫‪ CompDose‬الفرق بين التيار مستوى السكر والمستوى السابق بمقدار ‪ 4‬وتقريب النتيجة‪ .‬إذا كانت النتيجة مقربة إلى صفر ثم يتم تعيين‬
‫على الحد األدنى للجرعة التي يمكن تسليمها‪ .‬المتطلبات قراءتان سابقتان بحيث يمكن حساب معدل تغير مستوى السكر‪ .‬الشرط المسبق‬
‫ثم ‪ r1‬بالشرط الالحق ‪ r0‬يحتوي خزان األنسولين على األقل على الحد األقصى للجرعة المفردة المسموح بها من األنسولين‪ .‬يتم استبدال‬
‫اآلثار الجانبية ال يوجد‪ .‬الشكل ‪ 4.10‬منظم تخصيص لشرط ل مضخة األنسولين ‪ 98‬الفصل ‪ 4‬هندسة المتطلبات ‪ r2.‬بـ ‪ r1‬يتم استبدال‬
‫عند استخدام نموذج قياسي لتحديد المتطلبات الوظيفية ‪ ،‬فإن ما يلي‪ :‬يجب تضمين المعلومات‪ .1 :‬وصف الوظيفة أو الكيان الذي يتم‬
‫تحديده‪ .2 .‬وصف لمدخالته ومن أين تأتي‪ .3 .‬وصف لمخرجاتها وأين تذهب‪ .4 .‬معلومات حول المعلومات‪ W‬المطلوبة للحساب‪ W‬أو غيره‬
‫الكيانات في النظام المستخدمة (الجزء "يتطلب")‪ .5 .‬وصف لإلجراء الواجب اتخاذه‪ .6 .‬إذا تم استخدام نهج وظيفي ‪ ،‬فإن الشرط المسبق‬
‫يحدد ما يجب أن يكون صحيحً ا قبل استدعاء الوظيفة ‪ ،‬وشرط الحق يحدد ما هو صحيح بعد ذلك الوظيفة تسمى‪ .7 .‬وصف لآلثار‬
‫الجانبية (إن وجدت) للعملية‪ .‬يؤدي استخدام المواصفات المهيكلة إلى إزالة بعض مشكالت الشبكات المحلية الطبيعية‪ -‬مواصفات‬
‫يتم تقليل التباين في المواصفات ويتم تقليل المتطلبات منظمة بشكل أكثر فعالية‪ .‬ومع ذلك ‪ ،‬ال يزال من الصعب أحيا ًنا كتابة ‪guage.‬‬
‫طلب‪ -‬يذكر بطريقة واضحة ال لبس فيها ‪ ،‬وال سيما عند الحسابات‪ W‬المعقدة (على سبيل المثال ‪ ،‬كيفية حساب جرعة األنسولين) يجب‬
‫تحديدها‪ .‬لمعالجة هذه المشكلة ‪ ،‬يمكنك إضافة معلومات إضافية إلى اللغة الطبيعية المتطلبات ‪ ،‬على سبيل المثال ‪ ،‬باستخدام الجداول أو‬
‫النماذج الرسومية للنظام‪ .‬هؤالء يمكن أن يوضح كيفية سير العمليات الحسابية ‪ ،‬وكيف تتغير حالة النظام ‪ ،‬وكيف يتفاعل المستخدمون‬
‫‪-‬التعامل مع النظام ‪ ،‬وكيف يتم تنفيذ تسلسل اإلجراءات‪ .‬الجداول مفيدة بشكل خاص عندما يكون هناك عدد من المواقع البديلة الممكنة‬
‫وتحتاج إلى وصف اإلجراءات التي يجب اتخاذها لكل من هذه‪ .‬األنسولين تعتمد المضخة في حساباتها‪ W‬على متطلبات األنسولين ‪uations‬‬
‫الشكل ‪ 4.11‬هو وصف ‪٪ s.‬على معدل التغيير مستويات السكر في الدم‪ .‬يتم حساب‪ W‬معدالت التغيير باستخدام الحالي والسابق قراءة‬
‫)‪ (r2 r1‬جدولي لكيفية معدل تغير الدم يستخدم السكر لحساب كمية األنسولين التي سيتم توصيلها‪ .‬إجراء الشرط انخفاض مستوى السكر‬
‫التركيب ))‪ ((r2 r1) (r1 r0‬زيادة مستوى السكر ومعدل الزيادة تناقص ‪ (r2 r1) CompDose 0‬مستوي السكر مستقر ‪CompDose 0‬‬
‫إذا كانت النتيجة مقربة )‪ 0 ((r2 r1) (r1 r0)) CompDose round ((r2 r1) / 4‬زيادة مستوى السكر ومعدل الزيادة مستقر أو زيادة‬
‫الشكل ‪ 4.11‬جدولي مواصفات حساب ل مضخة األنسولين ‪ 4.4‬عمليات هندسة ‪ 0 CompDose MinimumDose‬ثم جرعة‬
‫المتطلبات ‪ 99‬متطلبات تخصيص متطلبات تصديق متطلبات استخراج متطلبات النظام المواصفات و النمذجة نظام مطلوب‪ .‬استخراج‬
‫متطلبات المستخدم تخصيص مستخدم‪ W‬متطلبات استخراج متطلبات العمل تخصيص النماذج جدوى يذاكر المراجعات متطلبات النظام‬
‫وثيقة يبدأ ‪ 4.4‬عمليات هندسة المتطلبات كما ناقشت في الفصل ‪ ، 2‬قد تتضمن العمليات الهندسية المتطلبات أربعة األنشطة عالية‬
‫مفيد ا لألعمال (دراسة الجدوى) ‪ ،‬اكتشاف المتطلبات (االستنباط والتحليل) ‪ ،‬التحويل‬‫المستوى‪ .‬تركز هذه على تقييم ما إذا كان النظام ً‬
‫هذه المتطلبات في شكل معياري (مواصفات) ‪ ،‬والتحقق من أن تحدد المتطلبات بالفعل النظام الذي يريده العميل (التحقق من الصحة)‪.‬‬
‫أملك تظهر هذه كعمليات متسلسلة في الشكل ‪ .2.6‬ومع ذلك ‪ ،‬في الممارسة‪ W‬العملية ‪ ،‬تتطلب‪ -‬تعتبر هندسة اإلشارات عملية تكرارية يتم‬
‫فيها تشذير األنشطة‪ .‬يوضح الشكل ‪ 4.12‬هذا التشذير‪ .‬يتم تنظيم األنشطة كتكرار عملية حول أحلزونيًا ‪ ،‬مع كون اإلخراج مستند‬
‫متطلبات النظام‪ .‬يعتمد مقدار الوقت والجهد المخصصين لكل نشاط في كل تكرار على مرحلة العملية الكلية ونوع النظام الذي يتم‬
‫تطويره‪ .‬في وقت مبكر من العملية ‪ ،‬سيتم إنفاق معظم الجهد على فهم األعمال عالية المستوى و الشكل ‪ 4.12‬لولب المنظر التابع ل‬
‫دراسات‪ W‬جدوى دراسة الجدوى هي دراسة قصيرة مركزة يجب إجراؤها ‪ FPO‬متطلبات عملية هندسية ‪ 100‬الفصل ‪ 4‬هندسة المتطلبات‬
‫في وقت مبكر من عملية تعلم المخاطر‪ .‬يجب أن يجيب ثالثة األسئلة الرئيسية‪ :‬أ) هل يساهم النظام في األهداف العامة للمنظمة؟ ب) هل‬
‫يمكن أن يكون النظام نفذت ضمن الجدول الزمني والميزانية باستخدام التكنولوجيا الحالية؟ ج) هل يمكن دمج النظام مع األنظمة األخرى‬
‫‪.‬التي يتم استخدامها؟‪ W‬إذا كانت اإلجابة على أي من هذه األسئلة بالنفي ‪ ،‬فمن المحتمل أال تمضي قد ًما‪ W‬في المشروع‬
‫المتطلبات غير الوظيفية ‪http://www.SoftwareEngineering-9.com/Web/Requirements/FeasibilityStudy.html‬‬
‫ومتطلبات المستخدم للنظام‪ .‬في وقت الحق العملية ‪ ،‬في الحلقات الخارجية للولبية ‪ ،‬سيتم تكريس المزيد من الجهد الستنباط و فهم‬
‫متطلبات النظام التفصيلية‪ .‬يالئم هذا النموذج الحلزوني مناهج التطوير حيث تتطلب‪ -‬تم تطوير اإلشارات إلى مستويات مختلفة من‬
‫التفاصيل‪ .‬عدد التكرارات حول يمكن أن يختلف اللولب بحيث يمكن الخروج منه بعد بعض أو كل متطلبات المستخدم تم استنباطه‪ .‬يمكن‬
‫استخدام التطوير السريع بدالً من النماذج األولية بحيث يكون ملف يتم تطوير المتطلبات وتنفيذ النظام معً ا‪ .‬يعتبر بعض األشخاص أن‬
‫هذا يتضمن تحليل ‪ (Larman ، 2002).‬المتطلبات الهندسية هي عملية تطبيق أ طريقة التحليل المهيكلة ‪ ،‬مثل التحليل الموجه للكائنات‬
‫النظام وتطوير مجموعة من نماذج النظام الرسومية ‪ ،‬مثل كنماذج لحاالت االستخدام ‪ ،‬والتي تعمل بعد ذلك كمواصفات للنظام‪ .‬مجموعة‬
‫النماذج يصف سلوك النظام ويتم شرحه بمعلومات إضافية لوصف ‪ ،‬على سبيل المثال ‪ ،‬األداء المطلوب للنظام أو الموثوقية‪ .‬على الرغم‬
‫طرق‪ .‬استنباط‬ ‫من أن األساليب المنظمة لها دور تلعبه في هندسة المتطلبات العملية ‪ ،‬هناك متطلبات هندسية أكثر بكثير مما تغطيه هذه ُ‬
‫المتطلبات ‪ ،‬على وجه الخصوص ‪ ،‬هو نشاط محوره اإلنسان و يكره الناس القيود التي تفرضها عليها نماذج النظام الصارمة‪ .‬في جميع‬
‫األنظمة تقريبًا ‪ ،‬تتغير المتطلبات‪ .‬يطور األشخاص المشاركون رها ًنا‪ -‬فهم ً‬
‫ثالث ا لما يريدون أن يفعله البرنامج ؛ المنظمة التي تشتري‬
‫تغييرات النظام يتم إجراء تعديالت على أجهزة وبرامج النظام و البيئة التنظيمية‪ .‬عملية إدارة هذه المتطلبات المتغيرة يسمى إدارة‬
‫المتطلبات ‪ ،‬والتي أغطيها في القسم ‪ 4.5 .4.7‬استنباط المتطلبات وتحليلها بعد دراسة الجدوى األولية ‪ ،‬المرحلة التالية من المتطلبات‬
‫الهندسية العملية هي متطلبات االستنباط والتحليل‪ .‬في هذا النشاط ‪ ،‬مهندسو البرمجيات العمل مع العمالء والمستخدمين النهائيين للنظام‬
‫للتعرف على مجال التطبيق ‪ ،‬ما هي الخدمات‪ W‬التي يجب أن يوفرها النظام ‪ ،‬واألداء المطلوب للنظام ‪ ،‬قيود األجهزة ‪ ،‬وما إلى ذلك‪4.5 .‬‬
‫استحضار المتطلبات وتحليلها ‪ 101‬قد يشمل استنباط المتطلبات وتحليلها مجموعة متنوعة من أنواع مختلفة من الناس في منظمة‪.‬‬
‫أصحاب المصلحة في النظام هو أي شخص يجب أن يكون لديه بعض تأثير مباشر أو غير مباشر على متطلبات النظام‪ .‬يشمل أصحاب‬
‫سوف يتفاعل مع النظام وأي شخص آخر في المنظمة سيفعل ذلك تتأثر به‪ .‬قد يكون أصحاب ‪ who‬المصلحة النهاية‪ -‬مستخدمين‬
‫المصلحة اآلخرون في النظام من المهندسين الذين يطورون أو صيانة األنظمة األخرى ذات الصلة ومديري األعمال وخبراء المجال‬
‫والتجارة ممثلي النقابات‪ .‬يظهر نموذج عملية لعملية االستنباط والتحليل في الشكل ‪ .4.13‬سيكون لكل مؤسسة نسختها الخاصة أو إنشاء‬
‫ً‬
‫اعتماد ا على العوامل المحلية مثل خبرة الموظفين ونوع النظام المطورة والمعايير المستخدمة وما إلى ذلك‪.‬‬ ‫مثيل لهذا النموذج العام‬
‫أنشطة العملية هي‪ . 1 :‬اكتشاف المتطلبات هذه هي عملية التفاعل مع أصحاب المصلحة في نظام الكتشاف متطلباتهم‪ .‬متطلبات المجال‬
‫ضا أثناء هذا النشاط‪ .‬هناك العديد من‬‫التقنيات المستقرة التي يمكن استخدامها ‪ comple-‬من أصحاب المصلحة و تم اكتشاف الوثائق أي ً‬
‫الكتشاف المتطلبات ‪ ،‬والتي أناقشها الح ًقا في هذا القسم‪ . 2 .‬تصنيف وتنظيم المتطلبات يأخذ هذا النشاط العملية ‪ -‬مجموعة مؤمنة من‬
‫المتطلبات والمتطلبات المتعلقة بالمجموعات والتنظيمات منهم في مجموعات متماسكة‪ .‬الطريقة األكثر شيو ًعا لتجميع المتطلبات هي‬
‫الستخدام نموذج لهيكل النظام لتحديد األنظمة الفرعية وربط‪ -‬أكلت المتطلبات مع كل نظام فرعي‪ .‬في الممارسة العملية ‪ ،‬متطلبات‬
‫الهندسة ال يمكن أن يكون التصميم المعماري أنشطة منفصلة تمامًا‪ .3 .‬تحديد أولويات المتطلبات والتفاوض حتما ً ‪ ،‬عند وجود رهان‬
‫متعدد‪ -‬أصحاب المشاركة ‪ ،‬سوف تتعارض المتطلبات‪ .‬هذا النشاط معني ب تحديد أولويات المتطلبات وإيجاد وحل تعارضات المتطلبات‬
‫من خالل التفاوض‪ .‬عادة ‪ ،‬يجب أن يجتمع أصحاب المصلحة لحل الخالفات وتوافق على متطلبات التسوية‪ .1 .‬المتطلبات اكتشاف ‪.2‬‬
‫المتطلبات التصنيف و منظمة ‪ .3‬المتطلبات تحديد األولويات و تفاوض ‪ .4‬المتطلبات تخصيص الشكل ‪ 4.13‬متطلبات االستنباط وعملية‬
‫التحليل ‪ 102‬الفصل ‪ 4‬هندسة المتطلبات ‪ . 4‬مواصفات المتطلبات يتم توثيق المتطلبات وإدخالها في الجولة القادمة من اللولب‪ .‬قد تكون‬
‫وثائق المتطلبات الرسمية أو غير الرسمية أنتجت ‪ ،‬كما تمت مناقشته‪ W‬في القسم ‪ .4.3‬يوضح الشكل ‪ 4.13‬أن استنباط المتطلبات وتحليلها‬
‫تكراري عملية مع تغذية مرتدة مستمرة من كل نشاط إلى أنشطة أخرى‪ .‬العملية تبدأ الدورة باكتشاف المتطلبات وتنتهي بمستند المتطلبات‬
‫نشوئها‪ .‬يتحسن فهم المحلل للمتطلبات مع كل جولة الدورة‪ .‬تنتهي الدورة عند اكتمال وثيقة المتطلبات‪ .‬يعد الحصول على المتطلبات‬
‫وفهمها من أصحاب المصلحة في النظام أمرً ا صعبًا العملية لعدة أسباب‪ .1 :‬غالبًا ما ال يعرف أصحاب المصلحة ما يريدون من نظام‬
‫الكمبيوتر إال بعبارات عامة ؛ قد يجدون صعوبة في التعبير عما يريدون النظام المطلوب القيام به ؛ قد يقدمون مطالب غير واقعية ألنهم‬
‫ال يعرفون ما هو ممكن وما هو غير ممكن‪ . 2 .‬أصحاب المصلحة في نظام ما يعبرون بطبيعة الحال عن المتطلبات بشروطهم الخاصة و‬
‫بمعرفة ضمنية بعملهم‪ .‬متطلبات المهندسين ‪ ،‬بدون خبرة في مجال العميل ‪ ،‬قد ال تفهم هذه المتطلبات‪ .3 .‬أصحاب المصلحة المختلفين‬
‫لديهم متطلبات مختلفة ويمكن أن يعبروا عنها بطرق مختلفة‪ .‬يجب أن يكتشف مهندسو المتطلبات جميع المصادر المحتملة المتطلبات‬
‫واكتشاف القواسم المشتركة والصراع‪ . 4 .‬العوامل السياسية قد تؤثر على متطلبات النظام‪ .‬المديرينيمكن تطلب متطلبات نظام محددة ألنها‬
‫ستسمح لهم بالزيادة تأثيرهم في المنظمة‪ . 5 .‬البيئة االقتصادية والتجارية التي يتم فيها التحليل متحرك‪ .‬يتغير حتما أثناء عملية التحليل‪.‬‬
‫أهمية متطلبات معينة قد تتغير‪ .‬قد تظهر متطلبات جديدة من الجديد أصحاب المصلحة الذين لم يتم استشارتهم في األصل‪ .‬حتما ‪ ،‬تختلف‬
‫وجهات نظر أصحاب المصلحة المختلفين حول أهمية وأولويات‪ -‬متطلبات ‪ ،‬وأحيا ًنا ‪ ،‬تكون وجهات‪ W‬النظر هذه متضاربة‪ .‬أثناء ال‬
‫العملية ‪ ،‬يجب عليك تنظيم مفاوضات منتظمة مع أصحاب المصلحة بحيث تكون هناك تنازالت من الممكن الوصول اليه‪ .‬من المستحيل‬
‫إرضاء كل أصحاب المصلحة تما ًم ا ولكن إذا كان بعضهم يشعر أصحاب المصلحة أنه لم يتم النظر في وجهات نظرهم بشكل صحيح‬
‫عندئ ٍذ تعمد محاولة تقويض عملية تعلم المخاطر‪ .‬في مرحلة تحديد المتطلبات ‪ ،‬المتطلبات التي تم استنباطها حتى اآلن موثقة بطريقة‬
‫يمكن استخدامها للمساعدة في تلبية المتطلبات اكتشاف‪ .‬في هذه المرحلة ‪ ،‬قد يتم إصدار إصدار مبكر من مستند متطلبات النظام يتم‬
‫إنتاجها بأقسام‪ W‬مفقودة ومتطلبات غير مكتملة‪ .‬بدال من ذلك ‪ ،‬فإن قد يتم توثيق المتطلبات بطريقة مختلفة تمامًا (على سبيل المثال ‪ ،‬في‬
‫نطاق‪ -‬ورقة أو على بطاقات)‪ .‬يمكن أن تكون متطلبات الكتابة على البطاقات فعالة ج ًدا مثل هذه سهل على أصحاب المصلحة التعامل‬
‫وجهات النظر وجهة النظر هي طريقة لجمع وتنظيم مجموعة من ‪ FPO‬معه وتغييره وتنظيمه ‪ 4.5..‬استنباط المتطلبات وتحليلها ‪103‬‬
‫المتطلبات من مجموعة من أصحاب المصلحة الذين لديهم شيء مألوف‪ .‬ولذلك تتضمن كل وجهة نظر مجموعة من متطلبات النظام‪ .‬قد‬
‫تأتي وجهات النظر من المستخدمين النهائيين ‪ ،‬والمديرين ‪ ،‬وما إلى ذلك ‪ ،‬فهي تساعد في تحديد األشخاص الذين يمكنهم تقديم معلومات‪W‬‬
‫‪.‬عنهم المتطلبات وهيكلية متطلبات التحليل‬
‫اكتشاف المتطلبات ‪http://www.SoftwareEngineering-9.com/Web/Requirements/Viewpoints.html 4.5.1‬‬
‫اكتشاف المتطلبات (يسمى أحيا ًن ا استحضار المتطلبات) هو عملية جمع المعلومات عن النظام المطلوب واألنظمة الحالية والتقطير‬
‫المستخدم ومتطلبات النظام من هذه المعلومات‪ .‬مصادر المعلومات خالل‪ -‬تتضمن مرحلة اكتشاف المتطلبات التوثيق ‪ ،‬وأصحاب‬
‫المصلحة في النظام ‪ ،‬ومواصفات األنظمة المماثلة‪ .‬أنت تتفاعل مع أصحاب المصلحة من خالل وجهات النظر والمالحظة ويمكنك‬
‫استخدام السيناريوهات والنماذج األولية لمساعدة أصحاب المصلحة‪ -‬فهم ما سيكون عليه النظام‪ .‬يتراوح أصحاب المصلحة من‬
‫المستخدمين النهائيين للنظام من خالل المديرين إلى أصحاب المصلحة الخارجيين‪ -‬أصحاب مثل المنظمين ‪ ،‬الذين يشهدون على قبول‬
‫النظام‪ .‬على سبيل المثال‪ ،‬يشمل أصحاب المصلحة في نظام نظام معلومات مرضى الرعاية الصحية النفسية ما يلي‪ .1 :‬المرضى الذين‬
‫يتم تسجيل معلوماتهم في النظام‪ .2 .‬األطباء المسؤولون عن تقييم وعالج المرضى‪ .3 .‬الممرضات الذين ينسقون االستشارات مع‬
‫األطباء ويديرون البعض العالجات‪ . 4 .‬موظفو االستقبال الطبيون الذين يديرون مواعيد المرضى‪ .5 .‬موظفو تكنولوجيا المعلومات‬
‫‪ cal‬المسؤولون عن تثبيت النظام وصيانته‪ . 6 .‬مدير األخالقيات الطبية الذي يجب أن يتأكد من أن النظام يلبي األخالق الحالية‪ -‬إرشادات‬
‫لرعاية المرضى‪ . 7 .‬مدراء الرعاية الصحية الذين يحصلون على المعلومات اإلدارية من النظام‪ .8 .‬موظفو السجالت‪ W‬الطبية المسؤولون‬
‫عن ضمان معلومات النظام يمكن صيانتها وحفظها ‪ ،‬وأن إجراءات حفظ السجالت كانت نفذت بشكل صحيح‪ .‬باإلضافة إلى نظام‬
‫أصحاب المصلحة ‪ ،‬ثلقد رأينا بالفعل أن المتطلبات قد تأتي أيضً ا من مجال التطبيق ومن األنظمة األخرى التي تتفاعل مع يتم تحديد‬
‫النظام‪ .‬كل هذه يجب أن تؤخذ في االعتبار خالل المتطلبات عملية االستنباط‪ .‬يمكن أن تكون مصادر المتطلبات المختلفة هذه (أصحاب‬
‫المصلحة ‪ ،‬المجال ‪ ،‬األنظمة) يتم تمثيلها كوجهات نظر نظام مع كل وجهة نظر تعرض مجموعة فرعية من هندسة متطلبات الفصل‬
‫الرابع ‪ 104‬متطلبات النظام‪ .‬وجهات نظر مختلفة حول مشكلة ترى المشكلة في طرق مختلفة‪ .‬ومع ذلك ‪ ،‬فإن وجهات نظرهم ليست‬
‫مستقلة تما ًم ا ولكنها تستخدم‪ -‬حليف متداخلة بحيث يكون لديهم متطلبات مشتركة‪ .‬يمكنك استخدام وجهات‪ W‬النظر هذه لهيكلة كل من‬
‫االكتشاف والتوثيق لمتطلبات النظام‪ 4.5.2 .‬إجراء المقابالت تعد المقابالت الرسمية أو غير الرسمية مع أصحاب المصلحة في النظام‬
‫جز ًء ا من معظم المتطلبات‪ -‬مينتس العمليات الهندسية‪ .‬في هذه المقابالت فريق هندسة المتطلبات يطرح أسئلة على أصحاب المصلحة‬
‫ليتم تطويرها‪ .‬المتطلبات مستمدة من اإلجابات على هذه األسئلة‪ .‬قد تكون المقابالت من ‪- tem‬حول النظام الذي يستخدمونه حاليًا والنظام‬
‫نوعين‪ .1 :‬المقابالت المغلقة ‪ ،‬حيث يجيب صاحب‪ W‬المصلحة على مجموعة محددة مسب ًقا من األسئلة‪ .2 .‬المقابالت المفتوحة ‪ ،‬التي ال‬
‫يوجد فيها جدول أعمال محدد مسبقا‪ .‬المتطلبات يستكشف فريق الهندسة مجموعة من المشكالت مع أصحاب المصلحة في النظام وبالتالي‬
‫تطوير فهم أفضل الحتياجاتهم‪ .‬في الممارسة العملية ‪ ،‬عادة ما تكون المقابالت مع أصحاب المصلحة مزيجً ا من االثنين‪ .‬قد تضطر إلى‬
‫الحصول على إجابة ألسئلة معينة ولكنها تؤدي عاد ًة إلى ذلك القضايا األخرى التي تمت مناقشتها‪ W‬بطريقة أقل تنظيماً‪ .‬عرض مفتوح‬
‫بالكامل نادرا ما تعمل الدعائم بشكل جيد‪ .‬عادة ما يتعين عليك طرح بعض األسئلة للبدء و للحفاظ على تركيز المقابلة على النظام الذي‬
‫سيتم تطويره‪ .‬المقابالت مفيدة للحصول على فهم شامل لما يفعله أصحاب المصلحة ‪ ،‬كيف يمكن أن يتفاعلوا مع النظام الجديد ‪،‬‬
‫والصعوبات التي يواجهونها األنظمة الحالية‪ .‬يحب الناس التحدث عن عملهم ‪ ،‬لذلك يسعدهم عاد ًة الحصول عليه تشارك في المقابالت‪.‬‬
‫ومع ذلك ‪ ،‬فإن المقابالت ليست مفيدة للغاية في فهم المتطلبات من مجال التطبيق‪ .‬قد يكون من الصعب استخالص المعرفة بالمجال من‬
‫اِختِصاص‪ .‬من المستحيل ‪ a‬خالل المقابالت لسببين‪ . 1 :‬يستخدم جميع المتخصصين في التطبيق المصطلحات والمصطلحات الخاصة بـ‬
‫عليهم مناقشة متطلبات المجال دون استخدام هذه المصطلحات‪ .‬عادة ما يستخدمون المصطلحات بطريقة دقيقة ودقيقة من السهل أن يسيء‬
‫جد ا ألصحاب المصلحة لدرجة أنهم يجدونها يصعب شرحه أو يعتقدون أنه‬ ‫فهم متطلبات المهندسين‪ .2 .‬بعض المعرفة بالمجال مألوفة ً‬
‫جد ا بحيث ال يستحق الذكر‪ -‬عمل‪ .‬على سبيل المثال ‪ ،‬بالنسبة ألمين المكتبة ‪ ،‬من نافلة القول أن جميع عمليات االستحواذ كذلك‬‫أساسي ً‬
‫إلى القائم بإجراء المقابلة ‪ ،‬وبالتالي ال يتم أخذها في االعتبار ‪- ous‬مفهرسة قبل إضافتها إلى المكتبة‪ .‬ومع ذلك ‪ ،‬قد ال يكون هذا واضحً ا‬
‫ضا تقنية فعالة الستنباط المعرفة حول‬ ‫المتطلبات والقيود الوطنية بسبب وجود عالقات قوة خفية ‪ orga-‬في المتطلبات‪ .‬المقابالت ليست أي ً‬
‫بين مختلف األشخاص في المنظمة‪ .‬الهياكل التنظيمية المنشورة ‪ 4.5‬استنباط المتطلبات وتحليلها ‪ 105‬نادرً ا ما يتطابق مع واقع اتخاذ‬
‫القرار في منظمة ما ‪ ،‬لكن يمكن لألشخاص الذين تمت مقابلتهم ال ترغب في الكشف عن الهيكل الفعلي وليس النظري لشخص غريب‪.‬‬
‫في عام عموما ‪ ،‬معظم الناس بشكل عاممترددة في مناقشة‪ W‬السياسية والتنظيمية القضايا التي قد تؤثر على المتطلبات‪ .‬يتمتع القائمون‬
‫بالمقابالت الفعالون بخاصيتين‪ . 1 :‬إنهم منفتحون ‪ ،‬ويتجنبون األفكار المسبقة حول المتطلبات ‪ ،‬و على استعداد لالستماع إلى أصحاب‬
‫المصلحة‪ .‬إذا كان صاحب المصلحة يأتي بمفاجأة المتطلبات ‪ ،‬إذن فهم على استعداد لتغيير رأيهم بشأن النظام‪ .2 .‬يطلبون من الشخص‬
‫الذي تمت مقابلته أن يبدأ المناقشات باستخدام سؤال نقطة انطالق ‪ ،‬اقتراح متطلبات ‪ ،‬أو من خالل العمل م ًعا على نظام نموذج أولي‪.‬‬
‫قائال ل من غير المرجح أن ينتج عن "أخبرني بما تريد" معلومات‪ W‬مفيدة‪ .‬وجدوا من األسهل التحدث في سياق محدد بدالً من التحدث‬
‫بعبارات عامة‪ .‬المعلومات المستمدة من المقابالت تكمل معلومات أخرى عن النظام من الوثائق التي تصف العمليات التجارية أو األنظمة‬
‫الحالية ‪ ،‬مالحظات المستخدم ‪ ،‬في بعض األحيان ‪ ،‬وبصرف النظر عن المعلومات الواردة في وثائق النظام ‪ ،‬المقابلة قد تكون‬
‫المعلومات هي المصدر الوحيد للمعلومات حول متطلبات النظام‪ .‬ومع ذلك ‪ ،‬فإن إجراء المقابالت من تلقاء نفسه قد يفقد المعلومات‬
‫األساسية‪ W‬وهكذا يجب استخدامها جنبًا إلى جنب مع تقنيات استنباط المتطلبات األخرى‪ 4.5.3 .‬السيناريوهات عادة ما يجد الناس أنه من‬
‫األسهل أن يرتبطوا بأمثلة من الحياة الواقعية بدالً من مجردة األوصاف‪ .‬يمكنهم فهم وانتقاد سيناريو لكيفية تفاعلهم مع نظام برمجي‪.‬‬
‫يمكن لمهندسي المتطلبات استخدام المعلومات المكتسبة من هذه المناقشة‪ W‬لصياغة متطلبات النظام الفعلية‪ .‬يمكن أن تكون السيناريوهات‬
‫مفيدة بشكل خاص إلضافة التفاصيل إلى متطلبات المخطط التفصيلي وصف‪ .‬إنها أوصاف أمثلة لجلسات التفاعل‪ .‬كل سيناريو عاد ًة ما‬
‫يغطي واح ًدا أو ً‬
‫عددا صغيرً ا من التفاعالت الممكنة‪ .‬أشكال مختلفة من يتم تطوير السيناريوهات وهي توفر أنوا ًعا مختلفة من المعلومات‬
‫في الفصل ‪ ، 3‬نوع من سيناريوهات ‪ ، cussed‬في مختلف مستويات التفاصيل حول النظام‪ .‬القصص المستخدمة في البرمجة المتطرفة‬
‫المتطلبات‪ .‬يبدأ السيناريو بمخطط للتفاعل‪ .‬أثناء عملية االستنباط ‪ ،‬تتم إضافة التفاصيل إلى هذا إلنشاء وصف كامل لهذا التفاعل‪ .‬عندها‬
‫بشكل عام ‪ ،‬قد يشمل السيناريو‪ . 1 :‬وصف لما يتوقعه النظام والمستخدمون عند بدء السيناريو‪ .2 .‬وصف للتدفق الطبيعي لألحداث في‬
‫السيناريو‪ .3 .‬وصف لما يمكن أن يحدث بشكل خاطئ وكيف يتم التعامل معه‪ .4 .‬معلومات حول األنشطة األخرى التي قد تجري في‬
‫نفس الوقت‪ .5 .‬وصف لحالة النظام عند انتهاء السيناريو‪ 106 .‬الفصل ‪ 4‬هندسة المتطلبات يتضمن االستنباط القائم على السيناريو‬
‫وللتقاط التفاصيل التي سيتم تضمينها في هذه السيناريوهات‪ .‬يمكن كتابة ‪- iOS‬العمل مع أصحاب المصلحة لتحديد السيناريوهات‬
‫السيناريوهات كنص ‪ ،‬تكمله المخططات ‪ ،‬لقطات الشاشة ‪ ،‬إلخ‪ .‬بدال من ذلك ‪ ،‬أكثر تنظيما يمكن استخدام نهج مثل سيناريوهات األحداث‬
‫تستخدم إلدخال البيانات ‪ MHC-PMS‬أو حاالت االستخدام‪ .‬كمثال لسيناريو نص بسيط ‪ ،‬ضع في اعتبارك كيف يمكن أن يكون نظام‬
‫لمريض جديد (الشكل ‪ .) 4.14‬عندما يحضر مريض جديد أ العيادة ‪ ،‬سجل جديد يتم إنشاؤه بواسطة موظف استقبال طبي ومعلومات‬
‫ثم ‪ ical.‬شخصية (االسم والعمر وما إلى ذلك) يضاف إليها‪ .‬ثم تقوم ممرضة بإجراء مقابالت مع المريض وتجمع األدوية‪ .‬التاريخ‬
‫يخضع المريض الستشارة أولية مع الطبيب الذي يقوم بعمل التشخيص ‪ ،‬وإذا كان ذلك مناسبًا ‪ ،‬يوصي بدورة عالجية‪ .‬السيناريو يوضح‬
‫ما يحدث عندما يتم جمع التاريخ الطبي‪ 4.5.4 .‬حاالت االستخدام حاالت االستخدام هي شرطتقنية االكتشاف التي تم تقديمها ألول مرة‬
‫في الطريقة الموضوعية (جاكوبسون وآخرون ‪ .)1993 ،‬لقد أصبحوا اآلن أساسيًا سمة من سمات‪ W‬لغة النمذجة الموحدة‪ .‬في أبسط‬
‫أشكالها ‪ ،‬يتم تحديد حالة االستخدام االفتراض األولي‪ :‬شاهد المريض موظف استقبال طبي قام بإنشاء سجل في النظام وجمع بيانات‬
‫المريض المعلومات الشخصية (االسم والعنوان والعمر وما إلى ذلك)‪ .‬تم تسجيل دخول ممرضة إلى النظام وتقوم بجمع التاريخ الطبي‪.‬‬
‫طبيعي‪ :‬الممرضة تبحث عن المريض باسم العائلة‪ .‬إذا كان هناك أكثر من مريض بنفس اللقب ‪ ،‬يتم استخدام االسم األول (االسم األول‬
‫باللغة اإلنجليزية) وتاريخ الميالد لتعريف المريض‪ .‬تختار الممرضة خيار القائمة إلضافة التاريخ الطبي‪ .‬ثم تتبع الممرضة سلسلة من‬
‫المطالبات من النظام إلدخال معلومات‪ W‬حول االستشارات في مكان آخر حول مشاكل الصحة العقلية (إدخال نص مجاني) ‪ ،‬والحاالت‬
‫الطبية الحالية (تختار الممرضة الشروط من القائمة) ‪ ،‬األدوية التي يتم تناولها حاليًا (مختارة من القائمة) ‪ ،‬والحساسية (نص مجاني) ‪،‬‬
‫والحياة المنزلية (النموذج)‪ .‬ما الذي يمكن أن يكون خطأ‪ :‬سجل المريض غير موجود أو ال يمكن العثور عليه‪ .‬يجب على الممرضة إنشاء‬
‫سجل جديد معلومات شخصية‪ .‬لم يتم إدخال شروط المريض أو األدوية في القائمة‪ .‬يجب أن تختار الممرضة الخيار "آخر" و أدخل نصًا‬
‫صا مجانيًا يسجل‬ ‫مجان ًي ا يصف الحالة ‪ /‬الدواء‪ .‬ال يستطيع المريض ‪ /‬لن يقدم معلومات عن التاريخ الطبي‪ .‬يجب أن تدخل الممرضة ن ً‬
‫ملف عدم قدرة ‪ /‬عدم رغبة المريض في تقديم المعلومات‪ .‬يجب أن يقوم النظام بطباعة نموذج االستبعاد القياسي يذكر أن نقص‬
‫محدودا أو متأخرً ا‪ .‬يجب أن يتم التوقيع على هذا وتسليمها للمريض‪ .‬نشاطات أخرى‪ :‬يمكن الرجوع‬ ‫ً‬ ‫المعلومات قد يعني أن العالج سيكون‬
‫إلى السجل ولكن ال يجوز تحريره من قبل فريق عمل آخر أثناء إدخال المعلومات‪ .‬حالة النظام عند االكتمال‪ :‬تم تسجيل دخول المستخدم‪.‬‬
‫يتم إدخال سجل المريض بما في ذلك التاريخ الطبي في قاعدة البيانات ‪ ،‬ويضاف إلى السجل يوضح سجل النظام وقت بدء الجلسة ووقت‬
‫استنباط المتطلبات وتحليلها ‪ MHC-PMS4.5 107‬انتهائها والممرضة المشاركة‪ .‬الشكل ‪ 4.14‬السيناريو لجمع األدوية التاريخ في‬
‫الجهات الفاعلة المشاركة‪ W‬في التفاعل وتسمية نوع التفاعل‪ .‬هذا إذن تستكمل بمعلومات إضافية تصف التفاعل مع النظام‪ .‬قد تكون‬
‫أو مخططات الحالة‪ .‬يتم توثيق حاالت ‪ UML‬المعلومات اإلضافية وص ًفا نصيًا أو وص ًفا رسوميًا واح ًدا أو أكثر نماذج مثل تسلسل‬
‫االستخدام باستخدام مخطط حالة استخدام عالي المستوى‪ .‬مجموعة االستخدام تمثل الحاالت جميع التفاعالت الممكنة التي سيتم وصفها في‬
‫النظام متطلبات‪ .‬الفاعلون في العملية ‪ ،‬الذين قد يكونون بشريين أو أنظمة أخرى ‪ ،‬هم ممثلون‪ -‬أرسلت كأرقام العصا‪ .‬يتم تمثيل كل فئة‬
‫من التفاعالت على أنها قطع ناقص مسمى‪ .‬خطوط تربط الممثلين بالتفاعل‪ .‬اختياريا ‪ ،‬يمكن إضافة رؤوس األسهم إلى خطوط إلظهار‬
‫كيفية بدء التفاعل‪ .‬هذا موضح في الشكل ‪ ، 4.15‬والذي يوضح بعض حاالت االستخدام لنظام معلومات المريض‪ .‬ال يوجد فرق صارم‬
‫وسريع بين السيناريوهات وحاالت االستخدام‪ .‬بعض األخالقيات المهنية‪ -‬يعتبر التنوير القائل أن كل حالة استخدام هي سيناريو واحد ؛‬
‫يلخصان مجموعة من السيناريوهات في حالة استخدام واحدة‪ .‬كل سيناريو هو خيط ‪ Pooley (2006) ،‬اآلخرين ‪ ،‬كما اقترح ستيفنز و‬
‫واحد من خالل حالة االستخدام‪ .‬لذلك ‪ ،‬سيكون هناك سيناريو لـ التفاعل العادي باإلضافة إلى سيناريوهات لكل استثناء محتمل‪ .‬يمكنك ‪،‬‬
‫في الممارسة العملية ‪ ،‬استخدمها بأي طريقة‪ .‬حاالت االستخدام تحددالتفاعالت الفردية بين النظام ومستخدميه أو أنظمة أخرى‪ .‬يجب‬
‫ستعمل على تطوير السيناريو في المزيد ‪ UML‬توثيق كل حالة استخدام مع وصف نصي‪ .‬هؤالء يمكن بعد ذلك ربطها بنماذج أخرى في‬
‫التفاصيل‪ .‬على سبيل المثال ‪ ،‬وصف موجز لحالة استخدام استشارة اإلعداد من قد يكون الشكل ‪ :4.15‬تسمح استشارة اإلعداد لطبيبين أو‬
‫أكثر ‪ ،‬يعملون في مكاتب مختلفة ‪ ،‬بـ عرض نفس السجل في نفس الوقت‪ .‬يبدأ طبيب واحد االستشارة من قبل اختيار األشخاص المعنيين‬
‫من القائمة المنسدلة لألطباء الموجودين على‪ -‬خط‪ .‬ثم يتم عرض سجل المريض على شاشاتهم ولكن فقط على شاشة البدء يمكن للطبيب‬
‫تحرير السجل‪ .‬باإلضافة إلى ذلك ‪ ،‬يتم إنشاء نافذة دردشة نصية للمساعدة موظف استقبال طبي مدير يسجل مريض منظر معلومات‬
‫شخصية‪ .‬يولد تقرير يص ّدر إحصائيات ممرضة طبيب منظر سِ ِج ّل يحرر سِ ِج ّل يثبت التشاور الشكل ‪ 4.15‬حاالت االستخدام لهندسة‬
‫تنسيق اإلجراءات‪ .‬من المفترض أن مؤتمرً ا هاتفيًا للتواصل الصوتي‪ -‬سيتم إعدادها بشكل منفصل‪ MHC-PMS108 .‬متطلبات الفصل ‪4‬‬
‫السيناريوهات وحاالت االستخدام هي تقنيات فعالة الستنباط المتطلبات من أصحاب المصلحة الذين يتفاعلون مباشرة مع النظام‪ .‬يمكن أن‬
‫يكون كل نوع من أنواع التفاعل ممثلة كحالة استخدام‪ .‬ومع ذلك ‪ ،‬ألنهم يركزون على التفاعالت مع النظام‪ -‬تيم ‪ ،‬فهي ليست فعالة في‬
‫هو معيار واقعي للنمذجة الكائنية ‪. UML ،‬إثارة القيود أو األعمال عالية المستوى وغير المتطلبات الوظيفية أو الكتشاف متطلبات المجال‬
‫لذا استخدم حاالت و يتم اآلن استخدام االستنباط المستند إلى حالة االستخدام على نطاق واسع الستنباط المتطلبات‪ .‬أناقش حاالت‬
‫االستخدام بشكل أكبر في الفصل ‪ 5‬وإظهار كيفية استخدامها جنبًا إلى جنب مع نظام آخر نماذج لتوثيق تصميم النظام‪4.5.5 .‬‬
‫اإلثنوغرافيا أنظمة البرمجيات ال توجد بمعزل عن غيرها‪ .‬يتم استخدامها في المنظمات االجتماعية‪ -‬السياق اإلقليمي ومتطلبات نظام‬
‫البرنامج يمكن اشتقاقها أو تقييدها بواسطة هذا السياق‪ .‬غالبًا ما يكون تلبية هذه المتطلبات االجتماعية والتنظيمية أمرً ا بالغ األهمية لنجاح‬
‫أبد ا هو أن متطلباتهم ال تأخذ في االعتبار كيف االجتماعية‬‫النظام‪ .‬أحد أسباب تسليم العديد من أنظمة البرامج ولكن لم يتم استخدامها ً‬
‫والسياق التنظيمي يؤثر على التشغيل العملي للنظام‪ .‬اإلثنوغرافيا هي تقنية مراقبة يمكن استخدامها لفهم األوبرا العمليات اإلقليمية‬
‫ينغمس في بيئة العمل حيث يود النظام يستخدم‪ .‬تتم مالحظة العمل اليومي ‪- lyst‬والمساعدة في اشتقاق متطلبات الدعم لهذه العمليات‪ .‬آنا‬
‫وتدوين المالحظات‪ W‬حول المهام الفعلية في التي يشارك فيها المشاركون‪ .‬تكمن قيمة اإلثنوغرافيا في أنها تساعد على االكتشاف متطلبات‬
‫النظام الضمنية التي تعكس الطرق الفعلية التي يعمل بها الناس بدالً من ذلك من العمليات الرسمية التي حددتها المنظمة‪ .‬غالبًا ما يجد‬
‫الناس صعوبة بالغة في توضيح تفاصيل عملهم ألنها كذلك الطبيعة الثانية لهم‪ .‬يفهمون عملهم ولكنهم قد ال يفهمون ذلك العالقة بالعمل‬
‫اآلخر في المنظمة‪ .‬العوامل االجتماعية والتنظيمية التي تؤثر على العمل ‪ ،‬ولكنها ليست واضحة لألفراد ‪ ،‬قد تتضح فقط عندما الحظها‬
‫مراقب غير متحيز‪ .‬على سبيل المثال ‪ ،‬قد تقوم مجموعة العمل بالتنظيم الذاتي حتى يعرف األعضاء عمل بعضهم البعض ويمكنهم تغطية‬
‫بعضهم البعض إذا كان هناك شخص ما غائب‪ .‬قد ال يتم ذكر هذا أثناء مقابلة ألن المجموعة قد ال ترى كجزء ال يتجزأ من عملهم‪ .‬كان‬
‫رائد ا في استخدام اإلثنوغرافيا للترصيعذ العمل المكتبي‪ .‬هي وجدت أن ممارسات‪ W‬العمل الفعلية كانت أكثر ثرا ًء )‪Suchman (1987‬‬ ‫ً‬
‫وتعقيد ا وأكثر ديناميكية من النماذج البسيطة التي تفترضها أنظمة التشغيل اآللي للمكاتب‪ .‬االختالف‪ -‬بين العمل المفترض والفعلي كان‬ ‫ً‬
‫السبب األهم وراء ذلك لم يكن لهذه األنظمة المكتبية تأثير كبير على اإلنتاجية‪ .‬كرابتري (‪ )2003‬يناقش مجموعة واسعة من الدراسات‬
‫منذ ذلك الحين ويصف ‪ ،‬بشكل عام ‪ ،‬استخدام اإلثنوغرافيا في تصميم النظم‪ .‬في بحثي الخاص ‪ ،‬لقد بحثت في طرق ‪ 4.5‬استنباط‬
‫‪ (Viller and‬المتطلبات وتحليلها ‪ 109‬دمج اإلثنوغرافيا في عملية هندسة البرمجيات من خالل ربطها بـ متطلبات األساليب الهندسية‬
‫وتوثيق أنماط التفاعل في النظم التعاونية (مارتن وآخرون ‪ 2001 ،‬؛ )‪ Viller and Sommerville ، 2000‬؛‪Sommerville، 1999‬‬
‫مارتن وآخرون ‪ 2002 ،‬؛ مارتن وسومرفيل ‪ .) 2004 ،‬اإلثنوغرافيا فعالة بشكل خاص في اكتشاف نوعين من المتطلبات‪.1 :‬‬
‫المتطلبات المستمدة من الطريقة التي يعمل بها األشخاص بالفعل ‪ ،‬بدالً من الطريقة التي تقول بها تعريفات العملية أنها يجب أن تعمل‪ .‬ل‬
‫على سبيل المثال ‪ ،‬قد يقوم مراقبو الحركة الجوية بإيقاف تشغيل نظام تنبيه الصراع يكتشف الطائرات ذات مسارات الطيران المتقاطعة ‪،‬‬
‫على الرغم من التحكم العادي تحدد اإلجراءات أنه ينبغي استخدامه‪ .‬وضعوا الطائرة عمدا على مسارات متضاربة لفترة قصيرة للمساعدة‬
‫للتأكد من أن هذه الطائرات قد تم فصلها عن بعضها من قبل تحدث المشاكل ‪ trol‬في إدارة المجال الجوي‪ .‬عيوبهم‪ -‬تم تصميم استراتيجية‬
‫ووجدوا أن إنذار تنبيه التعارض يصرفهم عنهم عملهم‪ . 2 .‬المتطلبات المستمدة من التعاون والوعي لدى اآلخرين أنشطة‪ .‬على سبيل‬
‫المثال ‪ ،‬قد يستخدم مراقبو الحركة الجوية وع ًي ا باآلخرين عمل المراقبين للتنبؤ بعدد الطائرات التي ستدخل قطاع التحكم‪ .‬ثم يقومون‬
‫اعتماد ا على ذلك عبء العمل المتوقع‪ .‬لذلك ‪ ،‬يجب أن يسمح نظام‬ ‫ً‬ ‫اآللي بوحدات التحكم ‪ ATC‬بتعديل استراتيجيات التحكم الخاصة بهم‬
‫في قطاع ما للحصول على بعض الوضوح للعمل في القطاعات المجاورة‪ .‬يمكن دمج اإلثنوغرافيا مع النماذج األولية (الشكل ‪.)4.16‬‬
‫اإلثنوغرافيا يُعلم تطوير النموذج األولي بحيث يقل عدد دورات صقل النموذج األولي مطلوبة‪ .‬عالوة على ذلك ‪ ،‬يركز النموذج األولي‬
‫على اإلثنوغرافيا من خالل تحديد المشاكل واألسئلة التي يمكن مناقشتها‪ W‬بعد ذلك مع اإلثنوغرافي‪ .‬هو او هي يجب بعد ذلك البحث عن‬
‫إجابات لهذه األسئلة خالل المرحلة التالية من النظام‪ -‬دراسة تيم (سومرفيل وآخرون ‪ .)1993 ،‬يمكن للدراسات اإلثنوغرافية أن تكشف‬
‫عن تفاصيل عملية مهمة غال ًب ا ما يفوتها تقنيات استنباط المتطلبات األخرى‪ .‬ومع ذلك ‪ ،‬بسبب تركيزها على المستخدم النهائي ‪ ،‬فإن هذا‬
‫النهج ليس مناسبًا دائ ًم ا الكتشاف التنظيم أو متطلبات المجال‪ .‬ال يمكنهم دائ ًم ا تحديد الميزات الجديدة التي يجب أن تكون أضيفت إلى‬
‫النظام‪ .‬وبالتالي ‪ ،‬فإن اإلثنوغرافيا ليست مقاربة كاملة إلليسيتا‪ -‬من تلقاء نفسها ويجب استخدامها لتكملة النهج األخرى ‪ ،‬مثل االستخدام‬
‫تحليل حالة‪ .‬إثنوغرافي تحليل استخالص المعلومات‪ W‬االجتماعات مركزة األجناس البشرية النموذج المبدئي تقييم نظام عام تطوير نظام‬
‫الفصل ‪ - 4‬متطلبات الهندسة مراجعات المتطلبات ‪ analysis110‬النماذج الشكل ‪ 4.16‬اإلثنوغرافيا و النماذج األولية لـ متطلبات‬
‫مراجعة المتطلبات هي عملية يقوم فيها مجموعة من األشخاص من عميل النظام والنظام قام المطور بقراءة مستند المتطلبات بالتفصيل‬
‫والتحقق من وجود أخطاء وحاالت شاذة وتناقضات‪ .‬مرة واحدة تم اكتشافها وتسجيلها ‪،‬بعد ذلك ‪ ،‬يعود األمر إلى العميل والمطور‬
‫‪.‬للتفاوض بشأن كيفية إجراء يجب حل المشاكل المحددة‬
‫التحقق من المتطلبات التحقق من ‪http://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html 4.6‬‬
‫صحة المتطلبات هو عملية التحقق من تحديد المتطلبات بالفعل النظام الذي يريده العميل ح ًقا‪ .‬يتداخل مع التحليل كما هو معني مع إيجاد‬
‫مشاكل مع المتطلبات‪ .‬التحقق من صحة المتطلبات مهم ألن األخطاء في مستند المتطلبات يمكن أن تؤدي إلى تكاليف إعادة العمل المكثفة‬
‫عندما يتم اكتشاف هذه المشكالت أثناء التطوير أو بعد تشغيل النظام‪ .‬عادة ما تكون تكلفة إصالح مشكلة المتطلبات عن طريق إجراء‬
‫تغيير في النظام أكبر بكثير من إصالح أخطاء التصميم أو الترميز‪ .‬والسبب في ذلك هو أن أ عاد ًة ما يعني التغيير في المتطلبات أن‬
‫ض ا تغييرها‪ .‬عالوة على ذلك ‪ ،‬يجب إعادة اختبار النظام‪ .‬أثناء عملية التحقق من المتطلبات ‪ ،‬يجب إجراء‬ ‫تصميم النظام وتنفيذه ‪ -‬يجب أي ً‬
‫أنواع مختلفة من الشيكات نفذت على المتطلبات في وثيقة المتطلبات‪ .‬تشمل هذه الفحوصات ما يلي‪ .1 :‬فحوصات الصالحية قد يعتقد‬
‫المستخدم أن هناك حاجة إلى نظام ألداء وظائف معينة‪ -‬نشوئها‪ .‬ومع ذلك ‪ ،‬قد يؤدي المزيد من التفكير والتحليل إلى تحديد عناصر‬
‫إضافية أو مختلفة الوظائف المطلوبة‪ .‬األنظمة لديها أصحاب مصلحة متنوعين مع اختالف االحتياجات‪ W‬وأي مجموعة من المتطلبات هي‬
‫حتمًا حل وسط عبر الحصة‪ -‬المجتمع صاحب‪ . 2 .‬فحوصات االتساق يجب أال تتعارض المتطلبات الواردة في المستند‪ .‬إنه‪ ،‬يجب أال‬
‫تكون هناك قيود متناقضة أو أوصاف مختلفة لـ نفس وظيفة النظام‪ .3 .‬فحوصات االستيفاء يجب أن تتضمن وثيقة المتطلبات المتطلبات‬
‫التي تحدد جميع الوظائف والقيود التي يقصدها مستخدم النظام‪ . 4 .‬ضوابط الواقعية باستخدام المعرفة بالتكنولوجيا الحالية ‪ ،‬والمتطلبات‬
‫يجب فحصها للتأكد من إمكانية تنفيذها بالفعل‪ .‬هذه الشيكات يجب أيضً ا مراعاة الميزانية والجدول الزمني لتطوير النظام‪ .5 .‬إمكانية‬
‫يجب دائ ًم ا كتابة متطلبات النظام بحيث يمكن التحقق منها‪ .‬هذا يعني ‪ contrac- Tor ،‬التحقق لتقليل احتمالية حدوث نزاع بين العميل و‬
‫أنه يجب أن تكون قادرً ا على كتابة مجموعة من االختبارات التي يمكن أن توضح ‪ 7-4‬إدارة المتطلبات ‪ 111‬هناك عدد من تقنيات‬
‫التحقق من المتطلبات التي يمكن استخدامها بشكل فردي أو باالشتراك مع بعضهم البعض‪ .1 :‬مراجعة المتطلبات يتم تحليل المتطلبات‬
‫بشكل منهجي من قبل فريق المراجعين الذين يتحققون من وجود أخطاء وتناقضات‪ .2 .‬النماذج األولية في هذا النهج للتحقق من الصحة ‪،‬‬
‫يوجد نموذج قابل للتنفيذ للنظام في يتم عرض السؤال للمستخدمين النهائيين والعمالء‪ .‬يمكنهم تجربة هذا النموذج لمعرفة ما إذا كان يلبي‬
‫احتياجاتهم الحقيقية‪ . 3 .‬يجب أن تكون متطلبات إنشاء حالة االختبار قابلة لالختبار‪ .‬إذا كانت اختبارات يتم وضع المتطلبات كجزء من‬
‫عملية التحقق ‪ ،‬وهذا غال ًب ا ما يكشف مشاكل المتطلبات‪ .‬إذا كان من الصعب أو المستحيل تصميم االختبار ‪ ،‬فهذا عادة يعني أن المتطلبات‬
‫ستكون صعبة التنفيذ ويجب إعادة‪ -‬تعتبر‪ .‬تطوير االختبارات من متطلبات المستخدم قبل كتابة أي كود جزء ال يتجزأ من البرمجة‬
‫المتطرفة‪ .‬يجب أال تستهين بالمشاكل التي ينطوي عليها التحقق من صحة المتطلبات‪ .‬في النهاية ‪ ،‬من الصعب إثبات أن مجموعة من‬
‫المتطلبات تلبي في الواقع متطلبات المستخدم يحتاج‪ .‬يحتاج المستخدمون إلى تصور النظام قيد التشغيل وتخيل هوث هذا النظام سوف‬
‫تتناسب مع عملهم‪ .‬من الصعب حتى على محترفي الكمبيوتر المهرة القيام بما يلي يشكل هذا النوع من التحليل المجرد واألكثر صعوبة‬
‫لمستخدمي النظام‪ .‬نتيجة لذلك ‪ ،‬أنت نادرً ا ما تجد جميع مشكالت‪ W‬المتطلبات أثناء عملية التحقق من المتطلبات‪ .‬هو ‪ -‬هي أمر ال مفر منه‬
‫أنه سيكون هناك المزيد من التغييرات في المتطلبات لتصحيح اإلغفاالت و سوء الفهم بعد االتفاق على وثيقة المتطلبات‪ 4.7 .‬إدارة‬
 ‫المتطلبات تتغير متطلبات أنظمة البرامج الكبيرة دائ ًم ا‪ .‬سبب واحد لذلك هو أن هذه األنظمة عادة ما يتم تطويرها لمعالجة المشاكل‬
‫"الشريرة" ‪ -‬المشاكل التي ال يمكن تعريفه بالكامل‪ .‬نظرً ا ألنه ال يمكن تحديد المشكلة بالكامل ‪ ،‬فإن متطلبات وير ال بد أن تكون غير‬
‫مكتملة‪ .‬أثناء عملية البرنامج ‪ ،‬فإن الحصة‪ -‬يتغير فهم أصحاب المشكلة باستمرار (الشكل ‪ .)4.17‬النظام يجب أن تتطور المتطلبات بعد‬
‫ذلك أيضً ا لتعكس وجهة نظر المشكلة المتغيرة هذه‪ .‬وقت تغير فهم من مشكلة أولي فهم من مشكلة تغير متطلبات أولي متطلبات الشكل‬
‫الفصل ‪ 4‬متطلبات الهندسة متطلبات دائمة ومتقلبة بعض المتطلبات أكثر عرضة للتغيير من غيرها‪ 4.17 Evolution112 .‬متطلبات‬
‫المتطلبات الدائمة هي المتطلبات التي المرتبطة باألنشطة األساسية بطيئة التغيير للمؤسسة‪ .‬المتطلبات الدائمة مرتبطة مع أنشطة العمل‬
‫األساسية‪ .‬من المرجح أن تتغير المتطلبات المتقلبة‪ .‬وعادة ما ترتبط مع دعم األنشطة التي تعكس كيفية قيام المنظمة بعملها بدالً من العمل‬
‫بمجرد تثبيت النظام ‪. http://www.SoftwareEngineering-9.com/Web/Requirements/EnduringReq.html‬نفسه‬
‫واستخدامه بانتظام ‪ ،‬ال بد من وجود متطلبات جديدة يظهر‪ .‬يصعب على المستخدمين وعمالء النظام توقع تأثيرات الجديد النظام على‬
‫العمليات التجارية الخاصة بهم والطريقة التي يتم بها ذلك العمل‪ .‬بمجرد االنتهاء‪ -‬المستخدمين لديهم خبرة في النظام ‪ ،‬وسوف يكتشفون‬
‫احتياجات وأولويات جديدة‪ .‬هناك هناك عدة أسباب تجعل التغيير أمرً ا حتميًا‪ .1 :‬تتغير بيئة العمل والتقنية للنظام دائمًا بعد ذلك تثبيت‪ .‬قد‬
‫يتم إدخال جهاز جديد ‪ ،‬قد يكون من الضروري الواجهة النظام مع األنظمة األخرى ‪ ،‬قد تتغير أولويات العمل (مع ما يترتب على ذلك‬
‫التغييرات في دعم النظام المطلوبة) ‪ ،‬والتشريعات واللوائح الجديدة قد يتم تقديم أن النظام يجب بالضرورة االلتزام به‪ .2 .‬األشخاص‬
‫الذين يدفعون مقابل نظام ما ومستخدمي هذا النظام نادرً ا ما يكونون هم نفس األشخاص‪ .‬يفرض عمالء النظام متطلبات بسبب التنظيم‬
‫وقيود الميزانية‪ .‬قد تتعارض هذه مع متطلبات المستخدم النهائي و ‪ ،‬بعد التسليم ‪ ،‬قد يلزم إضافة ميزات جديدة لدعم المستخدم إذا كان‬
‫النظام هو تحقيق أهدافه‪ . 3 .‬عادة ما يكون لألنظمة الكبيرة مجتمع مستخدم متنوع ‪ ،‬مع وجود العديد من المستخدمين المتطلبات‬
‫ً‬
‫وسطا بينهم و ‪ ،‬مع الخبرة ‪ ،‬غالبًا ما‬ ‫واألولويات المختلفة التي قد تكون متضاربة أو متناقضة‪ .‬تعتبر متطلبات النظام النهائية حتمًا حالً‬
‫يُكتشف أن توازن الدعم المقدم يختلف‪ -‬يجب تغيير المستخدمين‪ .‬إدارة المتطلبات هي عملية الفهم والتحكم التغييرات في متطلبات النظام‪.‬‬
‫تحتاج إلى تتبع المتطلبات الفردية والحفاظ على الروابط بين المتطلبات التابعة حتى تتمكن من تقييم تأثير تغييرات المتطلبات‪ .‬تحتاج إلى‬
‫إنشاء عملية رسمية لصنع تغيير المقترحات وربطها بالنظاممتطلبات‪ .‬العملية الرسمية لـ يجب أن تبدأ إدارة المتطلبات بمجرد إصدار‬
‫مسودة للمتطلبات المستند متاح‪ .‬ومع ذلك ‪ ،‬يجب أن تبدأ في التخطيط لكيفية إدارة التغيير المتطلبات أثناء عملية استنباط المتطلبات‪.‬‬
‫‪ 4.7.1‬تخطيط إدارة المتطلبات التخطيط هو مرحلة أولى أساسية في عملية إدارة المتطلبات‪ .‬ال تحدد مرحلة التخطيط مستوى تفاصيل‬
‫إدارة المتطلبات مطلوب‪ .‬خالل مرحلة إدارة المتطلبات ‪ ،‬عليك أن تقرر‪ 4.7 :‬إدارة المتطلبات ‪ 113‬يتغير تطبيق تحليل التغيير والتكلفة‬
‫تحليل المشكلة و تغيير المواصفات محدد مشكلة مُراجع متطلبات الشكل ‪ 4.18‬تغيير المتطلبات إدارة ‪ .1‬تحديد المتطلبات يجب تحديد‬
‫كل متطلب بشكل فريد على هذا النحو أنه يمكن الرجوع إليها مع متطلبات أخرى واستخدامها في التتبع التقييمات‪ .2 .‬عملية إدارة التغيير‬
‫هذه هي مجموعة األنشطة التي تقيم األثر وتكلفة التغييرات‪ .‬أناقش هذه العملية بمزيد من التفصيل في القسم التالي‪ .3 .‬سياسات‪ W‬التتبع‬
‫تحدد هذه السياسات‪ W‬العالقات بين كل منها تتطلب‪ -‬وبين المتطلبات وتصميم النظام الذي يجب تسجيله‪ .‬يجب أن تحدد سياسة التتبع أيضًا‬
‫كيفية الحفاظ على هذه السجالت‪ .4 .‬تتضمن إدارة متطلبات دعم األداة معالجة كميات كبيرة من المعلومات‪ W‬حول المتطلبات‪ .‬األدوات‬
‫التي يمكن استخدامها تتراوح بين المتخصصين نظم إدارة المتطلبات لجداول البيانات وأنظمة قواعد البيانات البسيطة‪ .‬تحتاج إدارة‬
‫المتطلبات إلى دعم آلي وأدوات برمجية لـ يجب اختيار هذا خالل مرحلة التخطيط‪ .‬أنت بحاجة إلى دعم األداة من أجل‪ .1 :‬تخزين‬
‫المتطلبات يجب الحفاظ على المتطلبات في مكان آمن ورجل مخزن بيانات قديم يمكن الوصول إليه لجميع المشاركين في متطلبات‬
‫إذا كان دعم األداة النشط متاحً ا‪ .3 .‬إدارة ‪- plified‬إدارة التغيير عملية إدارة التغيير (الشكل ‪ )4.18‬بسيطة ‪ neering. 2.‬الهندسة عملية‬
‫التتبع كما تمت مناقشته أعاله ‪ ،‬أداة دعم التتبع يسمح باكتشاف المتطلبات ذات الصلة‪ .‬تتوفر بعض األدوات التي استخدام تقنيات معالجة‬
‫اللغة الطبيعية للمساعدة في اكتشاف العالقة المحتملة‪ -‬السفن بين المتطلبات‪ .‬بالنسبة لألنظمة الصغيرة ‪ ،‬قد ال يكون من الضروري‬
‫يمكن دعم عملية إدارة المتطلبات باستخدام التسهيالت المتاحة في ‪ agement.‬استخدام المتطلبات المتخصصة من قبل اإلنسان‪ -‬أدوات‬
‫صا‪ .‬لقد قمت‬ ‫معالجات‪ W‬الكلمات وجداول البيانات وقواعد بيانات الكمبيوتر‪ .‬لكن‪ ،‬لألنظمة األكبر حجمًا ‪ ،‬يلزم دعم أداة أكثر تخص ً‬
‫بتضمين الروابط للحصول على معلومات حول أدوات إدارة المتطلبات في صفحات الويب للكتاب‪ 4.7.2 .‬إدارة تغيير المتطلبات يجب‬
‫تطبيق إدارة تغيير المتطلبات (الشكل ‪ ) 4.18‬على جميع المقترحات التغييرات على متطلبات النظام بعد الموافقة على وثيقة المتطلبات‪.‬‬
‫تعد إدارة التغيير أمرً ا ضرور ًي ا ألنك تحتاج إلى تحديد ما إذا كانت فوائد التنفيذ‪ -‬توجيه المتطلبات الجديدة لها ما يبررها من خالل تكاليف‬
‫التنفيذ‪ .‬ميزة هندسة متطلبات الفصل الرابع ‪ 114‬باستخدام عملية رسمية إلدارة التغيير يتم التعامل مع جميع مقترحات التغيير باستمرار‬
‫ويتم إجراء التغييرات على مستند المتطلبات بطريقة مسيطر عليها‪ .‬هناك ثالث مراحل رئيسية لعملية إدارة التغيير‪ .1 :‬تحليل المشكلة‬
‫وتغيير المواصفات تبدأ العملية مع تحديد مشكلة المتطلبات أو ‪ ،‬في بعض األحيان ‪ ،‬مع اقتراح تغيير محدد‪ .‬خالل في هذه المرحلة ‪ ،‬يتم‬
‫تحليل المشكلة أو اقتراح التغيير للتحقق من ذلك صالح‪ .‬يتم إرسال هذا التحليل إلى طالب التغيير الذي قد يستجيب بـ متطلبات أكثر تحدي ًدا‬
‫لتغيير االقتراح ‪ ،‬أو تقرر سحب الطلب‪ . 2 .‬تحليل التغيير وتقدير التكلفة يتم تقييم تأثير التغيير المقترح يتطلب استخدام معلومات التتبع‬
‫والمعرفة العامة بالنظام‪ -‬إشارات‪ .‬يتم تقدير تكلفة إجراء التغيير من حيث التعديل‪ -‬إلى وثيقة المتطلبات ‪ ،‬وإذا كان ذلك مناسبا ‪ ،‬تصميم‬
‫النظام و تطبيق‪ .‬بمجرد اكتمال هذا التحليل ‪ ،‬يتم اتخاذ قرار بشأن ما إذا كان أو عدم المضي قدما في تغيير المتطلبات‪ .3 .‬تغيير تنفيذ‬
‫وثيقة المتطلبات ‪ ،‬وعند الضرورة ‪ ،‬تعديل تصميم النظام وتنفيذه‪ .‬يجب عليك تنظيم وثيقة المتطلبات بحيث يمكنك إجراء تغييرات عليها‬
 ‫دون تفصيل إعادة الكتابة أو إعادة التنظيم‪ .‬كما هو الحال مع البرامج ‪ ،‬فإن قابلية التغيير في المستندات هي تم تحقيقه عن طريق تقليل‬
‫المراجع الخارجية وعمل أقسام المستند معياري قدر اإلمكان‪ .‬وبالتالي ‪ ،‬يمكن تغيير األقسام الفردية واستبدالها دون التأثير على أجزاء‬
‫أخرى من المستند‪ .‬إذا كان ال بد من تنفيذ مطلب جديد بشكل عاجل ‪ ،‬فهناك دائ ًم ا إغراء تغيير النظام ثم تعديل مستند المتطلبات بأثر‬
‫رجعي‪ .‬أنت يجب أن تحاول تجنب ذلك ألنه يؤدي حتما ً إلى مواصفات المتطلبات و خروج تنفيذ النظام عن الخطوة‪ .‬بمجرد إجراء‬
‫تغييرات النظام ‪ ،‬فإنه من السهل نسيان تضمين هذه التغييرات في مستند المتطلبات أو إضافة معلومات‪ -‬وثيقة المتطلبات التي ال تتوافق‬
‫مع التنفيذ‪ .‬تم تصميم عمليات التطوير الرشيقة ‪ ،‬مثل البرمجة القصوى لمواكبة المتطلبات التي تتغير أثناء عملية التطوير‪ .‬في هذه‬
‫العمليات ‪ ،‬عندما يقترح المستخدم تغيير المتطلبات ‪ ،‬فإن هذا التغيير ال يذهب من خالل عملية إدارة التغيير الرسمية‪ .‬بدال من ذلك ‪ ،‬يجب‬
‫على المستخدم إعطاء األولوية لذلك التغيير ‪ ،‬وإذا كانت أولوية عالية ‪ ،‬فحدد ميزات النظام التي تم التخطيط لها لـ يجب إسقاط التكرار‬
‫متطلبات التتبع تحتاج إلى تتبع العالقات بين المتطلبات ومصادرها وتصميم النظام أنه يمكنك تحليل أسباب التغييرات ‪. FPO‬التالي‬
‫المقترحة والتأثير المحتمل لهذه التغييرات عليها أجزاء أخرى من النظام‪ .‬يجب أن تكون قادرً ا على تتبع كيف يموج التغيير طريقه عبر‬
‫الفصل الرابع ‪ http://www.SoftwareEngineering-9.com/Web/Requirements/ReqTraceability.html‬النظام‪ .‬لماذا؟‬
‫قراءات إضافية ‪ 115‬النقاط الرئيسية تحدد متطلبات نظام البرنامج ما يجب أن يفعله النظام وتحديد القيود على تشغيله وتنفيذه‪ .‬المتطلبات‬
‫الوظيفية هي بيانات عن الخدمات التي يجب أن يوفرها النظام أو يقدمها أوصاف لكيفية إجراء بعض الحسابات‪ .‬غالبًا ما تقيد المتطلبات‬
‫غير الوظيفية النظام الذي يتم تطويره والتطور العملية المستخدمة‪ .‬قد تكون هذه متطلبات المنتج أو المتطلبات التنظيمية أو المتطلبات‬
‫الخارجية‪ .‬غال ًب ا ما تتعلق بالخصائص الناشئة للنظام وبالتالي تنطبق على النظام ككل‪ .‬وثيقة متطلبات البرامج عبارة عن بيان متفق عليه‬
‫لمتطلبات النظام‪ .‬هو ‪ -‬هي يجب تنظيمه بحيث يمكن لكل من عمالء النظام ومطوري البرامج استخدامه‪ .‬تتضمن عملية هندسة المتطلبات‬
‫دراسة الجدوى واستنباط المتطلباتو التحليل ومواصفات المتطلبات والتحقق من صحة المتطلبات وإدارة المتطلبات‪ .‬استنباط المتطلبات‬
‫وتحليلها عملية تكرارية يمكن تمثيلها على شكل دوامة من األنشطة ‪ -‬اكتشاف المتطلبات وتصنيف المتطلبات والتنظيم ‪ ،‬التفاوض بشأن‬
‫المتطلبات ووثائق المتطلبات‪ .‬التحقق من صحة المتطلبات هو عملية التحقق من متطلبات الصالحية واالتساق ‪ ،‬االكتمال والواقعية‬
‫وإمكانية التحقق‪ .‬التغييرات التجارية والتنظيمية والتقنية تؤدي حتما إلى تغييرات في المتطلبات لنظام برمجيات‪ .‬إدارة المتطلبات هي‬
‫عملية اإلدارة والتحكم هذه التغيرات‪ .‬قراءة متعمقة متطلبات البرمجيات ‪ ،‬الطبعة الثانية‪ .‬هذا الكتاب مصمم للكتاب ومستخدمي المتطلبات‬
‫هندسة المتطلبات المتكاملة‪ :‬برنامج " )‪ ،. (K.M Weigers، 2003، Microsoft Press.‬يناقش متطلبات الممارسة الهندسية الجيدة‬
‫تعليمي"‪ .‬هذه ورقة تعليمية كتبتها فيها مناقشة‪ W‬متطلبات األنشطة الهندسية وكيف يمكن تكييفها لتتالءم مع العصر الحديث ممارسة هندسة‬
‫‪. (I. Sommerville، IEEE Software، 22 (1)، Jan-Feb 2005.) http://dx.doi.org/10.1109/MS.2005.13.‬البرمجيات‬
‫ولكنها تتضمن أيضً ا الكثير )‪ (VOLERE‬إتقان عملية المتطلبات ‪ ،‬الطبعة الثانية‪ .‬كتاب جيد الكتابة وسهل القراءة ومبني على طريقة معينة‬
‫اتجاهات " )‪. (S. Robertson and J. Robertson، 2006، Addison-Wesley.‬من النصائح العامة‪ W‬الجيدة حول المتطلبات الهندسية‬
‫البحث في هندسة المتطلبات"‪ .‬هذا مسح جيد للمتطلبات البحث الهندسي الذي يسلط الضوء على تحديات البحث المستقبلية في المنطقة‬
‫‪. (B. H.C Cheng and J.M Atlee، Proc. Conf on Future of Software‬لمعالجة قضايا مثل كمقياس وخفة الحركة‬
‫‪Engineering، IEEE Computer Society، 2007.) http://dx.doi.org/10.1109/FOSE.2007.17.E X E R C I S E S 4.1‬‬
‫حدد ووصف بإيجاز أربعة أنواع من المتطلبات التي يمكن تحديدها لجهاز كمبيوتر‪ -‬نظام قائم‪ 4.2 .‬اكتشف أوجه الغموض أو السهو في‬
‫نظام إصدار التذاكر‪ :‬يبيع نظام إصدار التذاكر اآللي تذاكر القطارات‪ .‬يختار المستخدمون وجهتهم و ‪ a‬بيان المتطلبات التالي لجزء من‬
‫إدخال بطاقة ائتمان ورقم تعريف شخصي‪ .‬يتم إصدار تذكرة القطار و حساب بطاقة االئتمان المشحونة‪ .‬عندما يضغط المستخدم على زر‬
‫البداية ‪ ،‬يتم عرض قائمة يتم تنشيط الوجهات المحتملة ‪ ،‬إلى جانب رسالة إلى المستخدم لتحديد وجهة‪ .‬بمجرد تحديد الوجهة ‪ ،‬يُطلب من‬
‫المستخدمين إدخال بطاقة االئتمان الخاصة بهم‪ .‬إنه يتم التحقق من الصالحية ثم يُطلب من المستخدم إدخال معرف شخصي‪ .‬عندما تم‬
‫التحقق من صحة معاملة‪ W‬االئتمان ‪ ،‬وتم إصدار التذكرة‪ 4.3 .‬أعد كتابة الوصف أعاله باستخدام المنهج المنظم الموضح في هذا الفصل‪.‬‬
‫حل الغموض الذي تم تحديده بطريقة مناسبة‪ 4.4 .‬اكتب مجموعة من المتطلبات غير الوظيفية لنظام إصدار التذاكر ‪ ،‬مع تحديدها‬
‫الموثوقية المتوقعة ووقت االستجابة‪ 4.5 .‬باستخدام التقنية المقترحة هنا ‪ ،‬حيث يتم تقديم أوصاف اللغة الطبيعية بتنسيق تنسيق قياسي ‪،‬‬
‫اكتب متطلبات مستخدم معقولة للوظائف التالية‪ :‬نظام ضخ بنزين (غاز) غير مراقب يتضمن قارئ بطاقات ائتمان‪ .‬ال يمرر العميل‬
‫البطاقة عبر القارئ ثم يحدد كمية الوقود المطلوبة‪ .‬يتم تسليم الوقود وخصم من حساب العميل‪ .‬وظيفة صرف النقد في ماكينة الصراف‬
‫اآللي للبنك‪ .‬وظيفة التدقيق اإلمالئي والتصحيح في معالج النصوص‪ .4.6 .‬اقترح كيف يكون المهندس مسؤوالً عن وضع مواصفات‬
‫متطلبات النظام قد تتبع العالقات‪ W‬بين المتطلبات الوظيفية وغير الوظيفية‪ 4.7 .‬باستخدام معرفتك بكيفية استخدام أجهزة الصراف اآللي ‪،‬‬
‫من الذي يجب أن يشارك في ‪ ATM. 4.8‬قم بتطوير مجموعة من حاالت االستخدام التي يمكن أن تخدم كأساس لفهم متطلبات نظام‬
‫مراجعة المتطلبات؟ ارسم نموذج عملية يوضح كيف أ قد يتم تنظيم مراجعة المتطلبات‪ 4.9 .‬عند الحاجة إلى إجراء تغييرات طارئة على‬
‫األنظمة ‪ ،‬قد يلزم إجراء تغييرات طارئة على برامج النظام تم تعديله قبل الموافقة على التغييرات على المتطلبات‪ .‬اقترح نموذجً ا لـ عملية‬
‫إلجراء هذه التعديالت التي ستضمن وثيقة المتطلبات وتنفيذ النظام ال تصبح غير متسقة‪ .4.10 .‬لقد توليت وظيفة مع مستخدم برنامج‬
‫تعاقد مع صاحب العمل السابق تطوير نظام لهم‪ .‬تكتشف أن تفسير شركتك لـ تختلف المتطلبات عن التفسير الذي اتخذه صاحب العمل‬
 ‫السابق‪ .‬يناقش ما يجب عليك القيام به في مثل هذه الحالة‪ .‬أنت تعلم أن التكاليف على صاحب العمل الحالي الخاص بك ستزداد إذا لم يتم‬
‫حل الغموض‪ .‬ومع ذلك ‪ ،‬فإنك تتحمل أيضً ا مسؤولية السرية لرب عملك السابق‪ 116 .‬الفصل الرابع ‪ -‬المتطلبات الهندسية الفصل الرابع‬
‫كرابتري ‪ -". IEEE Computer، 32 (10)، 70–8.‬المراجع ‪ 117‬مراجع بيك ‪ ،‬ك‪" .)1999( .‬احتضان التغيير مع البرمجة المتطرفة‬
‫ديفيس ‪ ،‬أ‪.‬م (‪ .)1993‬متطلبات البرنامج‪ ،: Springer-Verlag. :‬أ‪ .) 2003( .‬تصميم النظم التعاونية‪ :‬دليل عملي لإلثنوغرافيا‪ .‬لندن‬
‫لمواصفات ‪ IEEE‬الممارسة الموصى بها من" ‪. IEEE. (1998).‬الكائنات والوظائف والدول‪ .‬إنجليوود كليفس ‪ ،‬نيوجيرسي‪ :‬برنتيس هول‬
‫‪. Los Alamitos، Ca: IEEE Computer Society Press.‬مجموعة معايير هندسة البرمجيات ‪ IEEE‬متطلبات البرامج"‪ .‬في‬
‫برنامج كائني التوجه هندسة‪ .‬ووكينغهام‪ :‬أديسون ‪ Overgaard ، G. (1993).‬جاكوبسون ‪ ،‬آي‪ ، .‬كريسترسون ‪ ،‬إم ‪ ،‬جونسون ‪ ،‬بي‪ .‬و‬
‫ويسلي‪ .‬كوتونيا ‪ ،‬ج‪.‬سومرفيل ‪ ،‬آي (‪ .) 1998‬هندسة المتطلبات‪ :‬العمليات والتقنيات‪ .‬شيشستر ‪ ،‬المملكة المتحدة‪ :‬جون وايلي وأوالده‪.‬‬
‫واألنماط‪ :‬مقدمة في التحليل الموجه للكائنات و التصميم والعملية الموحدة‪ .‬إنجليوود كليف ‪ UML ،‬الرمان ‪ ،‬سي (‪ .)2002‬تطبيق‬
‫نيوجيرسي‪ :‬برنتيس هول‪ .‬مارتن ‪ ،‬د‪ ، .‬روددين ‪ ،‬ت‪ ، .‬رونسفيلد ‪ ،‬إم ‪ ،‬سومرفيل ‪ ،‬آي وفيلر ‪ ،‬س‪" .)2001( .‬العثور على األنماط في‬
‫بون‪ :‬كلوير‪ .58-39 .‬مارتن ‪ ،‬د‪ ، .‬رونسفيلد ‪ ،‬إم وسومرفيل ‪ ،‬آي (‪" .)2002‬تطبيق أنماط ‪. ECSCW’01.‬العمل الميداني‪ .‬بروك‬
‫مارتن ‪. ACM CHI’2002، ACM Press. 235-42. ،‬التفاعل على العمل (إعادة) التصميم‪ :‬الحكومة اإللكترونية والتخطيط‪ .‬بروك‬
‫حول التفاعل بين اإلنسان والحاسوب ‪'. ACM Trans. ( 11 ،‬د‪.‬سومرفيل ‪ ،‬آي (‪" .)2004‬أنماط التفاعل‪ :‬ربط المنهج العرقي و تصميم‬
‫‪ .89-59 ، )1.‬روبرتسون ‪ ،‬س‪ .‬وروبرتسون ‪ ،‬ج‪ .) 1999( .‬إتقان عملية المتطلبات‪ .‬هارلو ‪ ،‬المملكة المتحدة‪ :‬أديسون ويسلي‬
‫التكامل اإلثنوغرافيا في عملية " ‪Sommerville، I.، Rodden، T.، Sawyer، P.، Bentley، R. and Twidale، M. (1993).‬‬
‫مطبعة جمعية الكمبيوتر‪ .73-165 .‬ستيفنز ‪ ،‬ص‪ .‬وبولي ‪ ،‬ر‪. RE’93، San Diego CA: IEEE .)2006( .‬هندسة المتطلبات‪ .‬بروك‬
‫هندسة البرمجيات مع الكائنات و المكونات ‪ ،‬الطبعة الثانية‪ .‬هارلو ‪ ،‬المملكة المتحدة‪ :‬أديسون ويسلي‪ .‬سوشمان ‪ ،‬إل ( ‪ UML:‬باستخدام‬
‫الترابط‪ .)1987. Viller، S. and Sommerville، I. (1999). ":‬الخطط واإلجراءات الموضوعة‪ .‬كامبريدج‪ :‬مطبعة جامعة كامبريدج‬
‫‪ .and‬نهج لتمثيل اإلثنوغرافي التحليالت في تصميم النظم‪ .‬التفاعل بين اإلنسان والحاسوب ‪ .41-9 ، )2 & 1( 14 ،‬فيلير ‪ ،‬س‬
‫في دراسات اإلنسان والحاسوب ‪ J. 53 ،‬تحليل مستنير إثنوغرافيًا لمهندسي البرمجيات"‪ .‬كثافة العمليات" ‪Sommerville، I. (2000).‬‬
‫(‪ .96-169 ، )1‬نمذجة النظام ‪ 5‬أهداف الهدف من هذا الفصل هو تقديم بعض أنواع نماذج النظام التي قد يتم تطويرها كجزء من‬
‫المتطلبات الهندسية و عمليات تصميم النظام‪ .‬عندما تقرأ الفصل ‪ ،‬سوف‪ :‬فهم كيف يمكن استخدام النماذج الرسومية للتمثيل أنظمة‬
‫البرمجيات‪ W‬فهم سبب الحاجة إلى أنواع مختلفة من النماذج و وجهات نظر نمذجة النظام األساسية للسياق والتفاعل ‪ ،‬الهيكل والسلوك‪ .‬تم‬
‫وكيف يمكن استخدام هذه الرسوم البيانية في نمذجة النظام كن على )‪ (UML‬لغة النمذجة ‪ Unified‬تقديم بعض أنواع المخططات في‬
‫دراية باألفكار الكامنة وراء الهندسة القائمة على النموذج ‪ ،‬حيث أ يتم إنشاء النظام تلقائيًا من الهيكلية والسلوكية عارضات ازياء‪.‬‬
‫محتويات ‪ 5.1‬نماذج السياق ‪ 5.2‬نماذج التفاعل ‪ 5.3‬النماذج اإلنشائية ‪ 5.4‬النماذج السلوكية ‪ 5.5‬الهندسة المعتمدة على النموذج الفصل‬
‫الخامس نمذجة النظام ‪ 119‬نمذجة النظام هي عملية تطوير نماذج مجردة للنظام ‪ ،‬مع كل منها نموذج يقدم وجهة نظر أو منظور مختلف‬
‫لهذا النظام‪ .‬نمذجة النظام يعني بشكل عام تمثيل النظام باستخدام نوع من الرسوم البيانية التدوين ‪ ،‬والذي يعتمد دائمًا تقريبًا على‬
‫ومع ذلك ‪ ،‬من الممكن أيضً ا تطوير أسلوب رسمي (رياضي) نماذج نظام ‪ ،‬عادة ‪ (UML).‬المالحظات‪ W‬في النمذجة الموحدة اللغة‬
‫في هذا الفصل والنمذجة الرسمية في الفصل ‪ .12‬يتم ‪ UML‬كمواصفات نظام مفصلة‪ .‬أنا أغطي الرسوم البيانية النمذجة باستخدام‬
‫استخدام النماذج أثناء عملية هندسة المتطلبات للمساعدة في اشتقاق متطلبات النظام ‪ ،‬أثناء عملية التصميم لوصف النظام للمهندسين‪-‬‬
‫يطلب تنفيذ النظام وبعد التنفيذ لتوثيق النظام الهيكل والتشغيل‪ .‬يمكنك تطوير نماذج لكل من النظام الحالي و النظام المراد تطويره‪ .1 :‬يتم‬
‫استخدام نماذج النظام الحالي أثناء المتطلبات الهندسية‪ .‬هم المساعدة في توضيح ما يفعله النظام الحالي ويمكن استخدامه كأساس‪ W‬للمناقشة‪W‬‬
‫لعنة نقاط قوتها وضعفها‪ .‬هذه ثم تؤدي إلى متطلبات نظام جديد‪ . 2 .‬يتم استخدام نماذج النظام الجديد أثناء المتطلبات الهندسية للمساعدة‬
‫شرح المتطلبات المقترحة ألصحاب المصلحة اآلخرين في النظام‪ .‬يستخدم المهندسون هذه النماذج لمناقشة‪ W‬مقترحات التصميم وتوثيق‬
‫النظام لتنفيذ‪ -‬اإلرشاد‪ .‬في عملية هندسية تعتمد على نموذج ‪ ،‬من الممكن إنشاء ملف التنفيذ الكامل أو الجزئي للنظام من نموذج النظام‪.‬‬
‫أهم جانب في نموذج النظام هو أنه يترك التفاصيل‪ .‬عارضة هو تجريد للنظام قيد الدراسة وليس تمثياًل بدياًل من هذا النظام‪ .‬من الناحية‬
‫المثالية ‪ ،‬يجب أن يحافظ تمثيل النظام على جميع المعلومات‪ -‬حول الكيان الذي يتم تمثيله‪ .‬التجريد يبسط عمدا و يختار أبرز الخصائص‪.‬‬
‫على سبيل المثال ‪ ،‬في حدث بعيد االحتمال للغاية يجري تسلسل هذا الكتاب في إحدى الصحف ‪ ،‬وسيكون العرض التقديمي هناك امتناعًا‪-‬‬
‫جميع ‪: tain‬من النقاط الرئيسية للكتاب‪ .‬إذا تمت ترجمته من اإلنجليزية إلى اإليطالية ‪ ،‬فهذا سيكون تمثيل بديل‪ .‬قد تكون نية المترجم هي‬
‫المعلومات كما هي معروضة باللغة اإلنجليزية‪ .‬يمكنك تطوير نماذج مختلفة لتمثيل النظام من منظور مختلف‪ -‬الشجر‪ .‬على سبيل المثال‪:‬‬
‫و النظام‪ . 2 .‬منظور التفاعل حيث تقوم بنمذجة التفاعالت بين النظام وبيئتها أو‪ .1 o‬منظور خارجي ‪ ،‬حيث تقوم بنمذجة السياق أو البيئة‬
‫بين مكونات النظام‪ . 3 .‬منظور هيكلي ‪ ،‬حيث تقوم بنمذجة تنظيم نظام أو هيكل البيانات التي يعالجها النظام‪ .4 .‬منظور سلوكي ‪ ،‬حيث‬
‫تقوم بنمذجة السلوك الديناميكي للنظام وكيف تستجيب لألحداث‪ 120 .‬الفصل ‪ 5‬نمذجة النظام تشترك وجهات النظر هذه كثيرً ا مع‬
‫حيث يقترح عليك توثيق نظام هيكل وتنظيم تيم من ‪ (Kruchten ، 1995) ،‬للنظام الهندسة المعمارية ‪ Krutchen 4 + 1‬عرض‬
‫‪ UML (Booch et al.،‬وجهات نظر مختلفة‪ .‬أناقش هذا ‪ 1 + 4‬النهج في الفصل ‪ .6‬في هذا الفصل ‪ ،‬أستخدم المخططات المحددة في‬
‫على العديد من ‪ UML‬والتي أصبحت لغة نمذجة قياسية للكائنات المنحى النمذجة‪ .‬يحتوي ‪) ،‬وآخرون ‪ Rumbaugh 2004 ،‬؛‪2005‬‬
‫أنواع المخططات وبالتالي فهو يدعم إنشاء العديد أنواع مختلفة من نموذج النظام‪ .‬ومع ذلك ‪ ،‬فقد أجريت دراسة استقصائية في عام‬
‫اعتقدوا أن خمسة أنواع من الرسوم البيانية يمكنها ذلك تمثل ‪ UML‬أظهر أن معظم مستخدمي )‪2007 (Erickson and Siau ، 2007‬‬
‫أساسيات‪ W‬النظام‪ .1 :‬مخططات‪ W‬النشاط ‪ ،‬والتي تبين األنشطة المتضمنة في عملية أو في البيانات يعالج‪ .2 .‬استخدم مخططات الحالة ‪،‬‬
‫مخططات‪ W‬التسلسل التي تظهر التفاعالت بين الجهات الفاعلة والنظام و بين ‪- ronment. 3.‬التي توضح التفاعالت بين النظام وبيئته‬
‫مكونات النظام‪ . 4 .‬الرسوم البيانية للفصل ‪ ،‬والتي تظهر فئات الكائن في النظام والجمعيات‪ -‬بين هذه الفئات‪ .5 .‬مخططات‪ W‬الحالة ‪ ،‬والتي‬
‫هنا ‪ ،‬فأنا ‪ UML‬توضح كيفية تفاعل النظام مع األحداث الداخلية والخارجية‪ .‬بما أنه ليس لدي مساحة‪ W‬لمناقشة‪ W‬جميع أنواع مخططات‬
‫أركز عليها كيف يتم استخدام هذه األنواع الخمسة الرئيسية من الرسوم البيانية في نمذجة النظام‪ .‬عند تطوير نماذج النظام ‪ ،‬يمكنك غالبًا‬
‫أن تكون مر ًن ا بالطريقة التي يستخدمها ملف تم استخدام تدوين رسومي‪ .‬ال تحتاج دائ ًما إلى االلتزام الصارم بتفاصيل ملف الرموز‪ .‬تعتمد‬
‫تفاصيل النموذج ودقته على الطريقة التي تنوي استخدامها به‪ .‬هناك هي ثالث طرق تستخدم فيها النماذج الرسومية بشكل شائع‪.1 :‬‬
‫كوسيلة لتسهيل المناقشة‪ W‬حول نظام قائم أو مقترح‪ .2 .‬كطريقة لتوثيق نظام موجود‪ .3 .‬كوصف مفصل للنظام يمكن استخدامه إلنشاء‪W‬‬
‫نظام تطبيق‪ .‬في الحالة األولى ‪ ،‬الغرض من النموذج هو تحفيز المناقشة من بين مهندسي البرمجيات المشاركين في تطوير النظام‪ .‬نماذج‬
‫قد تكون غير مكتملة (طالما أنها تغطي النقاط الرئيسية للمناقشة) و قد يستخدمون تدوين النمذجة بشكل غير رسمي‪ .‬هذه هي الطريقة التي‬
‫عندما تكون النماذج ‪" (Ambler and Jeffries، 2002).‬تكون بها النماذج بشكل طبيعي المستخدمة في ما يسمى "النمذجة الرشيقة‬
‫تستخدم كوثائق ‪ ،‬ال يجب أن تكون كاملة كما قد ترغب في ذلك فقط تطوير نماذج لبعض أجزاء النظام‪ .‬ومع ذلك ‪ ،‬يجب أن تكون هذه‬
‫النماذج صحيح ‪ -‬يجب أن يستخدموا الترميز بشكل صحيح وأن يكونوا وص ًفا دقي ًقا لـ النظام ‪ 5.1‬نماذج السياق ‪ 121‬في الحالة الثالثة ‪،‬‬
‫حيث يتم استخدام النماذج كجزء من التطوير القائم على النموذج العملية ‪ ،‬يجب أن تكون نماذج النظام كاملة وصحيحة‪ .‬سبب ذلك هي‬
‫أنها تستخدم كأساس لتوليد شفرة المصدر للنظام‪ .‬لذلك ‪ ،‬يجب أن تكون حريصًا ج ًد ا على عدم الخلط بين الرموز المتشابهة ‪ ،‬مثل العصا‬
‫وكتلة رؤوس األسهم التي لها معاني مختلفة‪ 5.1 .‬نماذج السياق في مرحلة مبكرة من مواصفات النظام ‪ ،‬يجب أن تقرر النظام حدود‪.‬‬
‫يتضمن هذا العمل مع أصحاب المصلحة في النظام التخاذ القرارما وظيفة‪ -‬يجب أن يتم تضمين التخصصية في النظام وما توفره بيئة‬
‫قد تقرر هذا الدعم اآللي لبعض العمليات التجارية يجب تنفيذها ولكن يجب أن تكون العمليات األخرى عمليات يدوية ‪- ronment.‬النظام‬
‫أو مدعومة بمختلف أنظمة شديدة‪ .‬يجب أن تنظر في التداخالت المحتملة في الوظائف مع القائمة األنظمة وتقرر أين يجب تنفيذ وظائف‬
‫جديدة‪ .‬هذه ديسي‪ -‬يجب إجراء عمليات التنفيذ في وقت مبكر من العملية للحد من تكاليف النظام والوقت الالزمة لفهم متطلبات النظام‬
‫والتصميم‪ .‬في بعض الحاالت ‪ ،‬تكون الحدود بين النظام وبيئته نسبيًا واضح‪ .‬على سبيل المثال ‪ ،‬حيث يحل نظام آلي محل دليل موجود‬
‫أو نظام محوسب ‪ ،‬عادة ما تكون بيئة النظام الجديد هي نفسها مثل بيئة النظام الحالي‪ .‬في حاالت أخرى ‪ ،‬هناك المزيد من المرونة وأنت‬
‫تحديد ما يشكل الحدود بين النظام وبيئته أثناء عملية المتطلبات الهندسية‪ .‬على سبيل المثال ‪ ،‬لنفترض أنك تقوم بتطوير المواصفات‬
‫لمعلومات المريض نظام للرعاية الصحية النفسية‪ .‬يهدف هذا النظام إلى إدارة معلومات حول المرضى الذين يترددون على عيادات‬
‫بشكل ‪ tem‬الصحة النفسية والعالجات‪ W‬الموصوفة‪ .‬عند تطوير مواصفات هذا النظام ‪ ،‬عليك أن تقرر ما إذا كان النظام‪ -‬يجب أن تركز‬
‫حصري على جمع المعلومات حول االستشارات (باستخدام أنظمة أخرى لجمع المعلومات الشخصية عن المرضى) أو ما إذا كان ينبغي‬
‫ض ا معلومات المريض الشخصية‪ .‬ميزة االعتماد على أنظمة أخرى للحصول على معلومات المريض هو أنك تتجنب تكرار‬ ‫ذلك تجمع أي ً‬
‫البيانات‪ .‬العيب الرئيسي ‪ ،‬ومع ذلك ‪ ،‬فإن استخدام أنظمة أخرى قد يجعل الوصول إلى المعلومات أبطأ‪ .‬لو هذه األنظمة غير متوفرة ‪،‬‬
‫لغة النمذجة الموحدة هي مجموعة من ‪ 13‬نوعً ا مختل ًفا من المخططات التي يمكن استخدامها لنمذجة ‪ MHC-PMS.‬فال يمكن استخدام‬
‫البرامج األنظمة‪ .‬لقد ظهر من العمل في التسعينيات على النمذجة الشيئية حيث يكون التشابه موجهًا للكائنات تم دمج الرموز إلنشاء‬
‫هو مقبول عالميًا كنهج معياري لتطوير نماذج أنظمة ‪. UML‬في عام ‪ (UML 2) 2004‬تم االنتهاء من مراجعة رئيسية ‪UML.‬‬
‫‪. http://www.SoftwareEngineering-9.com/Web/UML/‬البرمجيات‪ .‬كانت المتغيرات المقترحة لنمذجة نظام أكثر عمومية‬
‫نظام" سجل المريض نظام "نظام" تعيينات نظام "نظام" القبول" ‪" MHC-PMS‬لغة النمذجة الموحدة ‪ 122‬الفصل ‪ 5‬نمذجة النظام "نظام‬
‫إن ‪ MHC-PMS‬نظام "نظام" إدارة اإلبالغ نظام "نظام" روشتة نظام "نظام" إحصائيات المفوض السامي نظام الشكل ‪ 5.1‬السياق من‬
‫تعريف حدود النظام ليس حكما ً خاليا ً من القيمة‪ .‬االجتماعية و قد تعني المخاوف التنظيمية أن موقع حدود النظام قد يكون تحددها عوامل‬
‫تم وضعه في مكان مناسب بحيث يمكن إجراء عملية التحليل جميعً ا في موقع ‪ delib-‬غير فنية‪ .‬على سبيل المثال ‪ ،‬قد تكون حدود النظام‬
‫واحد ؛ هو ‪ -‬هي قد يتم اختياره بحيث ال يحتاج إلى استشارة مدير صعب بشكل خاص ؛ ممكن يتم وضعها بحيث يتم زيادة تكلفة النظام‬
‫وقسم تطوير النظام‪ -‬لذلك يجب أن تتوسع في تصميم وتنفيذ النظام‪ .‬بمجرد اتخاذ بعض القرارات بشأن حدود النظام ‪ ،‬يكون جزء من‬
‫نشاط التحليل هو تعريف هذا السياق والتبعيات التي يقوم بها النظام على بيئتها‪ .‬عادة ‪ ،‬إنتاج نموذج معماري بسيط هو األول خطوة في‬
‫هذا النشاط‪ .‬الشكل ‪ 5.1‬هو نموذج سياق بسيطيظهر ر نظام معلومات‪ W‬المريض واألنظمة األخرى في بيئتها‪ .‬من الشكل ‪ ، 5.1‬يمكنك أن‬
‫بنظام المواعيد ومريض أكثر عمومية نظام التسجيل الذي تشارك به البيانات‪ .‬النظام متصل أيضًا ‪ MHC-PMS‬ترى أن ملف يرتبط‬
‫بأنظمة إعداد التقارير اإلدارية وتخصيص أسرة المستشفى ونظام اإلحصاء الذي يجمع يكتشف المعلومات‪ W‬للبحث‪ .‬أخيرً ا ‪ ،‬فإنه يستخدم‬
‫نظام الوصفات الطبية لتوليد وضع وصفات طبية ألدوية المرضى‪ُ .‬تظهر نماذج السياق عاد ًة أن البيئة تتضمن العديد من السيارات‬
 ‫األخرى أنظمة التزاوج‪ .‬ومع ذلك ‪ ،‬فإنها ال تعرض أنواع العالقات بين األنظمة في البيئة والنظام الذي يتم تحديده‪ .‬األنظمة الخارجية قد‬
‫تنتج بيانات من النظام أو تستهلكها‪ .‬يمكنهم مشاركة‪ W‬البيانات مع النظام ‪ ،‬أو قد يكونون متصلين مباشرة ‪ ،‬من خالل شبكة أو غير متصلين‬
‫مبان منفصلة‪ .‬كل قد تؤثر هذه العالقات على متطلبات وتصميم النظام‬ ‫ٍ‬ ‫على االطالق‪ .‬قد تكون موجودة فعليًا في مكان واحد أو تقع في‬
‫الذي يتم تحديده ويجب أن يؤخذ في االعتبار‪ .‬لذلك ‪ ،‬يتم استخدام نماذج السياق البسيطة جنبًا إلى جنب مع نماذج أخرى ‪ ،‬مثل نماذج‬
‫العمليات التجارية‪ .‬تصف هذه العمليات البشرية واآللية التي أنظمة برمجية معينة مستخدمة ‪ 5.1‬نماذج السياق ‪ 123‬الشكل ‪ 5.2‬هو‬
‫احيانا المرضى الذين يعانون من مشاكل نفسية قد تشكل ‪ MHC-PMS.‬نموذج لعملية نظام مهمة توضح العمليات في الذي يستخدم‬
‫المشاكل الصحية خطرا على اآلخرين أو على أنفسهم‪ .‬لذلك قد يفعلون ذلك يجب أن يتم احتجازهم رغما ً عنهم في المستشفى حتى يمكن‬
‫إجراء العالج‪ -‬متدرج‪ .‬يخضع هذا االحتجاز لضمانات‪ W‬قانونية صارمة ‪ -‬على سبيل المثال ‪ ،‬القرار الحتجاز مريض يجب أن تتم‬
‫في ‪ MHC-PMS‬مراجعته بانتظام حتى ال يتم احتجاز األشخاص إلى أجل غير مسمى بدون سبب وجيه‪ .‬تتمثل إحدى وظائف نظام‬
‫تهدف مخططات النشاط إلى إظهار األنشطة التي تشكل عملية ‪ UML.‬ضمان ذلك يتم تنفيذ الضمانات‪ .‬الشكل ‪ 5.2‬هو مخطط نشاط‬
‫النظام وتدفق التحكم من نشاط واحد إلى اخر‪ .‬يشار إلى بداية العملية بدائرة مملوءة ؛ النهاية بدائرة مملوءة داخل دائرة أخرى‪ .‬تمثل‬
‫المستطيالت ذات الزوايا الدائرية األنشطة ‪ ،‬أي العمليات الفرعية المحددة التي يجب تنفيذها‪ .‬يمكنك تضمين كائنات في مخططات النشاط‪.‬‬
‫في الشكل ‪ ، 5.2‬أوضحت األنظمة المستخدمة‪ W‬لدعم العمليات المختلفة‪ .‬لقد أشرت إلى أن هذه أنظمة منفصلة تستخدم ميزة الصورة‬
‫تمثل األسهم تدفق العمل من نشاط واحد إلى اخر‪ .‬يتم استخدام شريط متصل لإلشارة إلى ‪ UML ،‬في مخطط نشاط ‪ UML.‬النمطية لـ‬
‫تنسيق النشاط‪ .‬عندما يتدفق من يؤدي أكثر من نشاط واحد إلى شريط صلب ثم يجب أن تكون كل هذه األنشطة قبل أن يكون التقدم ممك ًنا‪.‬‬
‫عندما يؤدي التدفق من شريط متصل إلى رقم من األنشطة ‪ ،‬يمكن تنفيذها بالتوازي‪ .‬لذلك ‪ ،‬في الشكل ‪ ، 5.2‬األنشطة إلبالغ الرعاية‬
‫االجتماعية وأقرباء المريض ‪ ،‬وتحديث سجل الحجز‪ً -‬‬
‫ثالثا قد يكون متزام ًن ا‪ .‬قد يتم وضع تعليقات توضيحية على األسهم باستخدام أدوات‬
‫الحماية التي تشير إلى الحالة عند حدوث ذلك التدفق مأخوذ‪ .‬في الشكل ‪ ، 5.2‬يمكنك أن ترى حرا ًسا يظهرون التدفقات للمرضى يتأكد‬
‫احتجاز قرار البحث عن األمان مكان اعترف ب مستشفى حول إلى قسم االمن حول إلى يؤمن مستشفى "نظام" القبول نظام إبالغ التالي‬
‫يخبر مريضل حقوق سِ ِج ّل احتجاز ‪" MHC-PMS‬نظام" ‪" MHC-PMS‬من ذوي القربى يخبر الرعاية االجتماعية تحديث يسجل "نظام‬
‫قرار [خطير] [غير متاح] [ال خطير] [متاح] الشكل ‪ 5.2‬العملية نموذج ال إرادي االحتجاز ‪ 124‬الفصل ‪ 5‬نمذجة النظام خطير وغير‬
‫خطير على المجتمع‪ .‬يجب على المرضى الذين يشكلون خطورة على المجتمع أن يتم احتجازهم في منشأة آمنة‪ .‬ومع ذلك ‪ ،‬فإن المرضى‬
‫الذين لديهم ميول انتحارية وكذلك أ خطر على أنفسهم قد يتم احتجازهم في جناح مناسب في المستشفى‪ 5.2 .‬نماذج التفاعل تتضمن جميع‬
‫األنظمة تفاعاًل من نوع ما‪ .‬يمكن أن يكون هذا تفاعل المستخدم ‪ ،‬والذي يتضمن مدخالت ومخرجات المستخدم ‪ ،‬والتفاعل بين النظام قيد‬
‫التطوير وغيرها من األنظمة أو التفاعل بين مكونات النظام‪ .‬النمذجة تفاعل المستخدم مهم ألنه يساعد على تحديد متطلبات المستخدم‪.‬‬
‫إلى النظام الضوء على مشاكل االتصال التي قد تنشأ‪ .‬يساعدنا تفاعل مكون النمذجة على فهم ما إذا كان هيكل ‪ tem‬النمذجة يسلط تفاعل‬
‫النظام المقترح من المرجح أن تقدم أداء النظام المطلوب واالعتمادية‪ .‬في هذا القسم ‪ ،‬أغطي نهجين مرتبطين بنمذجة التفاعل‪ .1 :‬استخدم‬
‫نمذجة الحالة ‪ ،‬والتي تستخدم في الغالب لنمذجة التفاعالت بين أ النظام والجهات‪ W‬الفاعلة الخارجية (مستخدمون أو أنظمة أخرى)‪.2 .‬‬
‫مخططات‪ W‬التسلسل ‪ ،‬والتي تستخدم لنمذجة التفاعالت بين النظام على الرغم من إمكانية تضمين عوامل خارجية أيضً ا‪ .‬استخدام نماذج‬
‫الحالة ومخططات التسلسل تقدم التفاعل على مستويات مختلفة من التفاصيل وهكذا يمكن استخدامها م ًعا‪ .‬تفاصيل التفاعالت المتضمنة في‬
‫أيضً ا مخططات االتصال التي يمكن استخدامها لنمذجة التفاعالت‪ UML .‬يمكن توثيق حالة استخدام المستوى في مخطط تسلسلي‪ .‬يتضمن‬
‫أنا ال أناقش هذه هنا ألنها تمثيل بديل لمخططات التسلسل‪ .‬في الواقع ‪ ،‬بعض يمكن لألدوات إنشاء مخطط اتصال من مخطط تسلسل‪.‬‬
‫في التسعينيات وتم دمجه )‪ 5.2.1 Jacobson et al. (1993‬استخدام نمذجة الحالة تم تطوير نمذجة حالة االستخدام في األصل بواسطة‬
‫مثل لقد ناقشت في الفصل ‪ُ ، 4‬تستخدم نمذجة حالة االستخدام على نطاق ‪ UML (Rumbaugh et al. ، 1999).‬في اإلصدار األول من‬
‫بسيطا يصف ماهية ملف يتوقع المستخدم من النظام‪ .‬تمثل كل‬ ‫ً‬ ‫واسع لدعم المتطلبات‪ -‬االستنباط‪ .‬يمكن اعتبار حالة االستخدام سيناريو‬
‫حالة استخدام مهمة منفصلة تتضمن تفاعاًل خارجيًا مع ملف نظام‪ .‬في أبسط أشكالها ‪ ،‬تظهر حالة االستخدام على شكل قطع ناقص مع‬
‫الذي يمثل مهمة‪ W‬تحميل ‪ MHC-PMS‬الممثلين المتورط في حالة االستخدام ممثلة بأشكال العصا‪ .‬يوضح الشكل ‪ 5.3‬حالة استخدام من‬
‫إلى نظام سجالت المرضى األكثر عمومية‪ .‬يحافظ هذا النظام األكثر عمومية على مجموع بيانات ماري حول ‪ MHC-PMS‬البيانات من‬
‫نماذج التفاعل ‪ 125‬نظام سجل المريض لموظف ‪ MHC-PMS.5.2‬مريض بدالً من البيانات حول كل استشارة ‪ ،‬وهي مسجلة في‬
‫االستقبال الطبي نقل البيانات الشكل ‪ 5.3‬التحويل‪ -‬حالة استخدام البيانات الحظ أن هناك ممثلين اثنين في حالة االستخدام هذه‪ :‬المشغل‬
‫الذي يقوم بالتحويل البيانات ونظام تسجيل المريض‪ .‬كان تدوين الرقم العصا في األصل تم تطويره لتغطية التفاعل البشري ولكنه يستخدم‬
‫ضا لتمثيل خارجي آخر‬ ‫لألنظمة واألجهزة‪ .‬بشكل رسمي ‪ ،‬يجب استخدام مخططات الحالة استخدام خطوط بدون تشير األسهم ‪ nal‬اآلن أي ً‬
‫إلى اتجاه تدفق الرسائل‪ .‬بوضوح‪ ،‬في حالة االستخدام تمر الرسائل في كال االتجاهين‪ .‬ومع ذلك ‪ ،‬فإن األسهم في الشكل ‪ UML‬كسهم‪ W‬في‬
‫‪ 5.3‬هي تستخدم بشكل غير رسمي لإلشارة إلى أن موظف االستقبال الطبي هو من بدأ المعاملة و يتم نقل البيانات إلى نظام تسجيل‬
‫مزيدا من التفاصيل لفهم ما ينطوي‬ ‫ً‬ ‫المرضى‪ .‬استخدم مخططات الحالةنظرة عامة بسيطة إلى حد ما للتفاعل ‪ ،‬لذا يجب عليك ذلك قدم‬
‫عليه األمر‪ .‬يمكن أن تكون هذه التفاصيل بسيطة وصف نصي أو وصف منظم في جدول أو مخطط تسلسلي على النحو التالي لعن أدناه‪.‬‬
 ‫لقد اخترت التنسيق األنسب بنا ًء على حالة االستخدام و مستوى التفاصيل الذي تعتقد أنه مطلوب في النموذج‪ .‬أجد جدول قياسي ليكون‬
‫الشكل األكثر فائدة‪ .‬يوضح الشكل ‪ 5.4‬وص ًفا جدوليًا لـ "التحويل حالة استخدام البيانات‪ .‬كما ناقشت في الفصل ‪ُ ، 4‬تظهر الرسوم البيانية‬
‫عدد ا من حاالت االستخدام المختلفة‪ .‬في بعض األحيان ‪ ،‬من الممكن تضمين جميع التفاعالت الممكنة‪ W‬مع نظام‬ ‫لحالة االستخدام المركب ً‬
‫بسبب عدد حاالت االستخدام‪ .‬في مثل هذه الحاالت ‪- sible ،‬في مخطط حالة استخدام مركب واحد‪ .‬ومع ذلك ‪ ،‬قد يكون هذا فرض‬
‫يمكنك تطوير العديد الرسوم البيانية ‪ ،‬كل منها يعرض حاالت االستخدام ذات الصلة‪ .‬على سبيل المثال ‪ ،‬يوضح الشكل ‪ 5.5‬كل شيء من‬
‫نقل البيانات موظف استقبال ‪. MHC-PMS:‬التي يكون فيها الممثل "موظف استقبال طبي" متضمن ‪ MHC-PMS‬حاالت االستخدام في‬
‫إلى قاعدة بيانات سجل المريض ‪ MHC-PMS‬الوصف قد يقوم موظف االستقبال بنقل البيانات من )‪ (PRS‬طبي ‪ ،‬نظام سجالت المرضى‬
‫العام تدار من قبل هيئة صحية‪ .‬قد يتم تحديث المعلومات المنقولة المعلومات الشخصية (العنوان ورقم الهاتف وما إلى ذلك) أو ملخص‬
‫لتشخيص المريض والعالج‪ .‬البيانات الشخصية للمريض ‪ ،‬ملخص العالج أمر مستخدم التحفيز صادر عن موظف استقبال طبي تأكيد‬
‫التعليقات يجب أن يكون لدى موظف االستقبال أذونات أمنية مناسبة للوصول إلى معلومات المريض و ‪ PRS‬االستجابة بأنه تم تحديث‬
‫الشكل ‪ 5.4‬جدولي الوصف ل "نقل البيانات" حالة االستخدام ‪ 126‬الفصل ‪ 5‬نمذجة النظام طبي موظف اإلستقبال يسجل مريض ‪PRS.‬‬
‫معلومات‪ .‬غير مسجل مريض الشكل ‪ 5.5‬حاالت االستخدام تنطوي على الدور ‪ Patient‬نقل البيانات اتصال مريض مشاهدة ملف‬
‫بشكل أساسي لنمذجة التفاعالت بين الفاعلون ‪" UML‬موظف استقبال طبي" ‪ 5.2.2‬مخططات التسلسل ُتستخدم مخططات التسلسل في‬
‫على صيغة غنية لمخططات التسلسل ‪ ،‬مما يسمح بالعديد من ‪ UML‬واألشياء في النظام والتفاعالت بين األشياء منهم‪ -‬النفس‪ .‬يحتوي‬
‫االختالفات يجب نمذجة أنواع شديدة من التفاعل‪ .‬ليس لدي مساحة لتغطية كل االحتماالت هنا لذا أركز على أساسيات‪ W‬هذا النوع من‬
‫المخططات‪ .‬كما يوحي االسم ‪ ،‬يوضح مخطط التسلسل تسلسل التفاعالت خالل حالة استخدام معينة أو حالة استخدام معينة‪ .‬الشكل ‪5.6‬‬
‫مثال لمخطط تسلسل يوضح أساسيات التدوين‪ .‬نماذج هذا الرسم البياني التفاعالت المتضمنة في حالة استخدام عرض معلومات‬
‫المريض ‪ ،‬حيث الطبية يمكن لموظف االستقبال رؤية بعض معلومات المريض‪ .‬يتم سرد الكائنات والممثلين المعنيين على طول الجزء‬
‫العلوي من الرسم التخطيطي ‪ ،‬مع نقطة‪ -‬خط تيد مرسوم عموديًا من هؤالء‪ .‬يشار إلى التفاعالت بين الكائنات بواسطة سهام مشروحة‪.‬‬
‫يشير المستطيل الموجود على الخطوط المنقطة إلى شريان الحياة للكائن المعنية (أي الوقت الذي يشارك فيه مثيل الكائن في الحساب)‪.‬‬
‫أنت اقرأ تسلسل التفاعالت من أعلى إلى أسفل‪ .‬التعليقات التوضيحية على األسهم تشير إلى المكالمات‪ W‬إلى الكائنات ومعلماتها وقيم‬
‫أعرض أيضً ا الترميز المستخدم لإلشارة إلى البدائل‪ .‬يتم استخدام مربع يسمى بديل بالشروط المبينة بين ‪- ple ،‬اإلرجاع‪ .‬في هذا االختبار‬
‫من كائن ‪ P‬في مثيل ‪ ViewInfo‬قوسين معقوفين‪ .‬يمكنك قراءة الشكل ‪ 5.6‬كما يلي‪ .1 :‬يقوم موظف االستقبال الطبي بتشغيل طريقة‬
‫هو مستخدم بين‪ -‬كائن الوجه ‪ ،‬والذي يتم عرضه كنموذج يظهر معلومات ‪ ، PID. P‬فئة ‪ ،‬توفير معرف المريض‪PatientInfo‬‬
‫قاعدة البيانات إلرجاع المعلومات المطلوبة ‪ ،‬مع توفيرها معرّ ف موظف االستقبال للسماح بالتحقق ‪ P‬المريض‪ .2 .‬يستدعي المثيل‬
‫نماذج التفاعل ‪ .3 127‬تتحقق قاعدة البيانات من خالل نظام ‪ UID) .5.2‬في هذه المرحلة ‪ ،‬ال نفعل ذلك اهتم من أين يأتي هذا( األمني‬
‫ترخيص مصرح للمستخدم به هذا الفعل‪ . 4 .‬إذا تم التصريح بذلك ‪ ،‬يتم إرجاع معلومات المريض واستمارة على شاشة‪ W‬المستخدم في‬
‫ثان لمخطط تسلسل من نفس النظام يوضح ميزتين إضافيتين‪ .‬هذه هي‬ ‫حالة فشل التفويض ‪ ،‬يتم إرجاع رسالة خطأ‪ .‬الشكل ‪ 5.7‬هو مثال ٍ‬
‫االتصاالت المباشرة بين الجهات‪ W‬الفاعلة في النظام وإنشاء‪ W‬األشياء كجزء من سلسلة من العمليات‪ .‬في في هذا المثال ‪ ،‬يتم إنشاء كائن من‬
‫يمكنك قراءة هذا الرسم ‪ (PRS).‬نوع الملخص لالحتفاظ بالبيانات الموجزة التي سيتم إنشاؤها يتم تحميلها على نظام تسجيل المرضى‬
‫هناك خياران متاحان‪ .‬هذه تسمح بالتحويل المباشر لتحديث ‪ PRS. 2.‬البياني كما يلي‪ .1 :‬يقوم موظف االستقبال بتسجيل الدخول إلى‬
‫في كل حالة ‪ ،‬يتم التحقق من أذونات موظف ‪ PRS. 3.‬إلى ‪ MHC-PMS‬ونقل البيانات الصحية الموجزة من ‪ PRS‬معلومات المريض إلى‬
‫بدال من ذلك ‪ ،‬يمكن ‪ PRS.‬االستقبال باستخدام التفويض نظام‪ .4 .‬قد يتم نقل المعلومات الشخصية مباشرة من كائن واجهة المستخدم‪ W‬إلى‬
‫رسالة حالة والمستخدم سجالت ‪ PRS‬إنشاء سجل موجز من قاعدة البيانات ثم يتم نقل هذا السجل‪ .5 .‬عند االنتهاء من التحويل ‪ ،‬يصدر‬
‫‪ D:‬معلومات المريض )‪ ، UID‬معلومات( تفويض )‪ ، PID ، UID‬معلومات( تقرير )‪. P: PatientInfo ViewInfo (PID‬الخروج‬
‫إذن تفويض خطأ (ال يوجد وصول) [التفويض موافق] [فشل التفويض] موظف استقبال طبي بديل الشكل ‪MHCPMS-DB AS: 5.6‬‬
‫تسجيل ‪ (TF ، UID) P: PatientInfo‬التسلسل رسم تخطيطي للعرض معلومات المريض ‪ 128‬الفصل ‪ 5‬نمذجة النظام تفويض تفويض‬
‫نعم تحديث المعلومات( ) تحديث ‪ PRS‬موظف استقبال طبي ]إرسال موجز[ ]‪ [SendInfo‬إذن ‪ ( ) D: MHCPMS-DB AS:‬الدخول‬
‫تحديث )‪ (PID‬ملخص تحديث‪ (TF ، UID) :‬تفويض تفويض )‪ (UID‬تحديث حسنا رسالة (موافق) تلخيص )‪ (PID‬تحديث )‪PRS (UID‬‬
‫الملخص () تسجيل خروج ( ) تحديث حسنا رسالة (موافق) بديل الشكل ‪ 5.7‬التسلسل رسم بياني للنقل بيانات ما لم تكن تستخدم‬
‫مخططات التسلسل إلنشاء الكود أو المستند التفصيلي‪ -‬التوجيه ‪ ،‬ليس عليك تضمين كل تفاعل في هذه المخططات‪ .‬اذا أنت تطوير نماذج‬
‫النظام في وقت مبكر من عملية التطوير لدعم المتطلبات الهندسة والتصميم عالي المستوى ‪ ،‬سيكون هناك العديد من التفاعالت التي تعتمد‬
‫على قرارات التنفيذ‪ .‬على سبيل المثال ‪ ،‬في الشكل ‪ 5.7‬قرار بشأن كيفية الحصول على معرف المستخدم للتحقق من التفويض هو‬
‫معرف يمكن تأخيره‪ .‬في تنفيذ‪ -‬قد يتضمن ذلك التفاعل مع كائن مستخدم ولكن هذا ليس مهمًا في هذا الصدد وبالتالي ال يلزم تضمينها في‬
‫مخطط التسلسل ‪ 5.3.‬النماذج الهيكلية ‪ 129‬تحليل المتطلبات الكينونية في تحليل المتطلبات الموجه للكائنات ‪ ،‬تقوم بنمذجة كيانات العالم‬
‫الحقيقي باستخدام فئات الكائنات‪ .‬يمكنك إنشاء ملفات أنواع مختلفة من نموذج الكائن ‪ ،‬توضح كيفية ارتباط فئات الكائن ببعضها البعض ‪،‬‬
 ‫وكيفية ارتباط الكائنات مجمعة لتكوين كائنات أخرى ‪ ،‬وكيفية تفاعل الكائنات مع الكائنات األخرى ‪ ،‬وما إلى ذلك‪ .‬هذه كل حاضر‬
‫ستيتكتورانماذج ‪. http://www.SoftwareEngineering-9.com/Web/OORA/ 5.3‬معلومات فريدة عن النظام الذي يتم تحديده‬
‫ل تعرض النماذج الهيكلية للبرنامج تنظيم النظام من حيث المكونات التي تشكل هذا النظام وعالقاتها‪ .‬قد النماذج الهيكلية تكون نماذج‬
‫ثابتة ‪ُ ،‬ت ظهر هيكل تصميم النظام أو النماذج الديناميكية ‪ ،‬التي تظهر تنظيم النظام عند تنفيذه‪ .‬هذه ليست نفس األشياء ‪ -‬التنظيم الديناميكي‬
‫للنظام كمجموعة من الخيوط المتفاعلة قد يكون مختل ًفا تما ًم ا عن النموذج الثابت لمكونات النظام‪ .‬تقوم بإنشاء نماذج هيكلية للنظام أثناء‬
‫وحزمه ‪ UML‬مناقشته وتصميمه بنية النظام‪ .‬يعد التصميم المعماري‪ W‬موضوعًا مهمًا بشكل خاص في هندسة البرمجيات ومكونات‬
‫ورسوماته التخطيطية كلها قد تكون كلها تستخدم عند تقديم النماذج المعمارية‪ .‬أنا أغطي جوانب مختلفة من البرنامج النمذجة المعمارية‬
‫والنمذجة المعمارية في الفصول ‪ 6‬و ‪ 18‬و ‪ . 19‬في هذا القسم ‪ ،‬أنا التركيز على استخدام الرسوم البيانية للفئة لنمذجة البنية الثابتة للكائن‬
‫دروس في نظام برمجي‪ 5.3.1 .‬الرسوم البيانية للفئة ُت ستخدم الرسوم البيانية للفئة عند تطوير نموذج نظام موجه للكائنات إلظهاره‬
‫بمثابة تعريف عام لنوع واحد من كائن النظام‪ .‬أسو‪ class -‬الطبقات في النظام والجمعيات‪ W‬بين هذه الفئات‪ .‬فضفاضة ‪ ،‬كائن يمكن اعتبار‬
‫االرتباط هو ارتباط بين الفئات يشير إلى وجود عالقة بينهما هذه الفئات‪ .‬وبالتالي ‪ ،‬قد يتعين على كل فئة أن يكون لديها بعض المعرفة‬
‫الكائنات تمثل شيًئ ا ما في ‪ neering ،‬بها فئة مرتبطة‪ .‬عندما تقوم بتطوير النماذج خالل المراحل األولى من هندسة البرمجيات‪ -‬عملية‬
‫العالم الحقيقي ‪ ،‬مثل المريض ‪ ،‬أ وصفة طبية ‪ ،‬طبيب ‪ ،‬إلخ‪ .‬عند تطوير التطبيق ‪ ،‬تحتاج عاد ًة إلى ذلك تحديد كائنات التنفيذ اإلضافية‬
‫هنا ‪ ،‬أركز على نمذجة كائنات العالم الحقيقي كجزء من المتطلبات أو عمليات ‪ tem.‬التي يتم استخدامها لتوفير النظام المطلوب‪ -‬وظائف‬
‫بمستويات مختلفة من التفاصيل‪ .‬عندما انت تقوم بتطوير نموذج ‪ UML ،‬تصميم البرامج المبكرة‪ .‬يمكن التعبير عن مخططات الفصل في‬
‫وعادة ما تكون المرحلة األولى هي النظر إلى العالم ‪ ،‬وتحديد األشياء األساسية ‪ ،‬وتمثيلها على أنها فئات‪ .‬أبسط طريقة لكتابة هذه هي‬
‫ضا مالحظة وجود نمذجة النظام ‪ 130‬الفصل ‪ 5‬ببساطة مريض مريض سِ ِج ّل ‪ 1 1‬الشكل ‪5.8‬‬ ‫اكتب اسم الفصل في صندوق‪ .‬يمكنك أي ً‬
‫الطبقات والجمعيات‪ W‬مريض عام ممارس المهنة التشاور مستشار دواء عالج مستشفى طبيب حالة نسب من قبل باإلشارة إلى تم ‪UML‬‬
‫تشخيصه‪ -‬مع يحضر يصف يصف أشواط ‪ * .. 1 * .. 1 * .. 1 * .. 1 4..1 * .. 1 * .. 1 * .. 1 * .. 1 1 * .. 1 1 * .. 1‬الشكل‬
‫عن طريق رسم خط بين الطبقات‪ .‬على سبيل المثال ‪ ،‬الشكل ‪ 5.8‬عبارة عن مخطط فئة بسيط ‪ 5.9 MHC-PMS‬الفئات والجمعيات في‬
‫عرض فئتين‪ :‬سجل المريض والمريض مع ارتباط بينهما‪ .‬في الشكل ‪ ، 5.8‬أوضحت ميزة أخرى لمخططات الفئة ‪ -‬القدرة على العرض‬
‫كم عدد العناصر المشاركة‪ W‬في االرتباط‪ .‬في هذا المثال ‪ ،‬كل نهاية من تمت إضافة تعليق توضيحي على االرتباط بـ ‪ ، 1‬مما يعني أن‬
‫هناك عالقة ‪ 1 :1‬بين كائنات هذه الفئات‪ .‬أي أن كل مريض لديه سجل واحد بالضبط وكل سجل يحتفظ بمعلومات حول مريض واحد‬
‫بالضبط‪ .‬كما ترى من االمتحان الالحق‪ -‬من فضلك ‪ ،‬من الممكن تعدد أخرى‪ .‬يمكنك تحديد هذا العدد الدقيق من الكائنات متورطون أو ‪،‬‬
‫باستخدام * ‪ ،‬كما هو موضح في الشكل ‪ ، 5.9‬أن هناك عد ًد ا غير محدد من األشياء المشاركة في الجمعية‪ .‬يتطور الشكل ‪5.9‬هذا النوع‬
‫من الرسم التخطيطي للفصل إلظهار أن كائنات فئة المريض تشارك أيضً ا في عالقات‪ W‬مع عدد من الفئات األخرى‪ .‬في هذا المثال ‪ ،‬أنا‬
‫أيضً ا بدور الكائنات المشاركة في الجمعية ‪ UML‬تبين أنه يمكنك تسمية الجمعيات إلعطاء القارئ إشارة إلى نوع العالقة الموجودة‪ .‬يسمح‬
‫المراد تحديدها‪ .‬في هذا المستوى من التفاصيل ‪ ،‬تبدو الرسوم البيانية للفصل مثل نماذج البيانات الداللية‪ .‬متعلق بدالالت األلفاظ تستخدم‬
‫نماذج البيانات في تصميم قواعد البيانات‪ .‬أنها تظهر كيانات البيانات ‪ ،‬المرتبطة بها والعالقات بين هذه الكيانات‪ .‬كان هذا النهج للنمذجة‬
‫‪ (Codd ،‬تم اقتراحه ألول مرة في منتصف السبعينيات من قبل تشين (‪ ) 1976‬؛ تم تطوير العديد من المتغيرات‪ -‬افتتح منذ ذلك الحين‬
‫تدوي ًنا ‪ UML‬جميع بنفس الشكل األساسي‪ .‬ال يتضمن ‪ Hull and King ، 1987) ،‬؛ ‪ Hammer and McLeod ، 1981‬؛ ‪1979‬‬
‫محدد ا لنمذجة قاعدة البيانات هذه يفترض عملية التطوير الموجهة للكائنات ونماذج البيانات باستخدام الكائنات و عالقاتهم‪ .‬ومع ذلك ‪،‬‬ ‫ً‬
‫لتمثيل البيانات الداللية نموذج‪ .‬يمكنك التفكير في الكيانات في نموذج البيانات الداللية على أنها فئات كائنات مبسطة ‪ UML‬يمكنك استخدام‬
‫‪ 5.3‬النماذج الهيكلية ‪( 131‬ليس لديهم عمليات) ‪ ،‬والسمات كسمات‪ W‬فئة الكائن والعالقات كما هو مسمى االرتباطات بين فئات الكائن‪.‬‬
‫عند إظهار االرتباطات بين الطبقات ‪ ،‬من المالئم تمثيلها هذه الفئات بأبسط طريقة ممكنة‪ .‬لتحديدها بمزيد من التفصيل ‪ ،‬أضف معلومات‬
‫حول سماتها‪( W‬خصائص كائن) وعملياتها (األشياء التي يمكنك طلبها من كائن)‪ .‬على سبيل المثال ‪ ،‬كائن المريض سوف لديك عنوان‬
‫وهو ما يتم استدعاؤه عندما يشير المريض إلى أنه انتقل من عنوان إلى اخر‪ ChangeAddress ، .‬السمة ويمكنك تضمين عملية تسمى‬
‫يمكنك إظهار السمات والعمليات من خالل توسيع البسيط مستطيل يمثل فئة‪ .‬هذا موضح في الشكل ‪ 5.10‬حيث‪ .1 :‬اسم فئة ‪ UML ،‬في‬
‫الكائن موجود في القسم العلوي‪ . 2 .‬سمات الفئة موجودة في القسم األوسط‪ .‬يجب أن يتضمن هذا السمة أسماء وأنواعها اختياريًا‪.3 .‬‬
‫المرتبطة بفئة الكائن في القسم السفلي من المستطيل‪ .‬يوضح الشكل ‪) 5.10‬األخرى ‪ OO‬ولغات برمجة ‪ Java‬تسمى الطرق في( العمليات‬
‫السمات‪ W‬والعمليات المحتملة في استشارة الفصل‪ .‬في في هذا المثال ‪ ،‬أفترض أن األطباء يسجلون المالحظات الصوتية التي تم نسخها‬
‫الح ًق ا إلى تسجيل تفاصيل االستشارة‪ .‬لوصف الدواء ‪ ،‬يجب على الطبيب المعني استخدم طريقة الوصفة الطبية إلنشاء وصفة طبية‬
‫إلكترونية‪ 5.3.2 .‬التعميم التعميم هو أسلوب يومي نستخدمه إلدارة التعقيد‪ .‬بدال من تعلم الخصائص التفصيلية لكل كيان نختبره ‪ ،‬فنحن‬
‫نضع هذه الكيانات‪ -‬روابط في فئات عامة (حيوانات ‪ ،‬سيارات ‪ ،‬منازل ‪ ،‬إلخ) وتعلم خصائص التشاور األطباء تاريخ وقت عيادة سبب‬
‫نسخ () ‪ ...‬الشكل ‪ 5.10‬فئة )( ‪ ( ) RecordNotes‬الدواء الموصوف العالج الموصوف مالحظات صوتية نص ‪ ...‬جديد ( ) وصفة‬
‫التشاور ‪ 132‬الفصل ‪ 5‬نمذجة النظام طبيب عام ممارس المهنة مستشفى طبيب طبيب الفريق االستشاري المتدرب طبيب مؤ َهل طبيب‬
‫الشكل ‪ 5.11‬تعميم َت َس لسُل هذه الفئات‪ .‬هذا يسمح لنا باستنتاج أن أعضاء مختلفين من هذه الفئات لديهم بعض الخصائص المشتركة (على‬
‫سبيل المثال ‪ ،‬السناجب‪ W‬والجرذان من القوارض)‪ .‬يمكننا أن نجعل الحالة العامة‪ -‬المالحظات‪ W‬التي تنطبق على جميع أعضاء الفصل (على‬
‫سبيل المثال ‪ ،‬جميع القوارض لها أسنانص قضم)‪ .‬في أنظمة النمذجة ‪ ،‬غالبًا ما يكون من المفيد فحص الفئات في نظام ما لمعرفة ذلك إذا‬
‫كان هناك مجال للتعميم‪ .‬هذا يعني أن المعلومات المشتركة ستكون يتم االحتفاظ بها في مكان واحد فقط‪ .‬هذه ممارسة تصميم جيدة ألنها‬
‫تعني ‪ ،‬إذا التغييرات المقترحة ‪ ،‬فال داعي للنظر في جميع الفئات في النظام معرفة ما إذا كانوا قد تأثروا بالتغيير‪ .‬في اللغات الموجهة‬
‫نوع معين من االرتباط لإلشارة إلى ‪ UML‬يتم تنفيذ التعميم باستخدام آليات وراثة الفئة المضمنة في لغة‪ .‬لدى ‪ Java ،‬للكائنات ‪ ،‬مثل‬
‫في الشكل ‪ . 5.11‬يظهر التعميم كرأس سهم يشير إلى الطبقة العامة‪ .‬هذا يدل على أن الممارسين العامين ‪- trated‬التعميم ‪ ،‬على أنه وهم‬
‫وأطباء المستشفيات‪ W‬يمكن تعميمها كأطباء وأن هناك ثالثة أنواع من أطباء المستشفى— أولئك الذين تخرجوا للتو من كلية الطب ويجب‬
‫أن يتم اإلشراف عليهم (طبيب متدرب) ؛ أولئك الذين يمكنهم العمل بدون إشراف كجزء من فريق استشاري (طبيب مسجل) ؛‬
‫واالستشاريين ‪ ،‬من كبار األطباء ذوي القرار الكامل‪ -‬صنع المسؤوليات‪ .‬في التعميم ‪ ،‬السمات‪ W‬والعمليات المرتبطة بالمستوى األعلى‬
‫ترتبط الطبقات أيضً ا بفئات المستوى األدنى‪ .‬في جوهرها ‪ ،‬المستوى األدنى الفئات هي فئات فرعية ترث السمات‪ W‬والعمليات من الفئات‬
‫الفائقة‪ .‬ثم تضيف هذه الفئات ذات المستوى األدنى سمات وعمليات أكثر تحدي ًدا‪ .‬ل على سبيل المثال ‪ ،‬كل األطباء لديهم اسم ورقم‬
‫هاتف ؛ جميع أطباء المستشفى لديهم طاقم عمل رقم وقسم ولكن الممارسين العامين ال يمتلكون هذه السمات‪ W‬كما هي العمل باستقاللية‪.‬‬
‫ومع ذلك ‪ ،‬لديهم اسم وعنوان للممارسة‪ .‬هذا هو هو موضح في الشكل ‪ ، 5.12‬والذي يوضح جزءًا من التسلسل الهرمي للتعميم امتدت‬
‫النماذج ‪ MHC-PMS.5.4‬مع سمات‪ W‬الطبقة‪ .‬العمليات المرتبطة بالفصل دكتور الغرض من تسجيل ذلك الطبيب وإلغاء تسجيله في‬
‫السلوكية ‪ 5.3.3 133‬التجميع غال ًب ا ما تتكون الكائنات في العالم الحقيقي من أجزاء مختلفة‪ .‬على سبيل المثال ‪ ،‬دراسة قد تتكون حزمة‬
‫ومسابقات وتسجيل‪ -‬توصيات لمزيد من القراءة‪ .‬في بعض األحيان في نموذج النظام ‪ PowerPoint ،‬الدورة التدريبية من كتاب وشرائح‬
‫واحدا (الكل) يتكون من ‪ UML‬هذا‪ .‬يوفر ‪- trate‬عليك أن تخدع‬ ‫ً‬ ‫ص ا من االرتباط بين الفئات المسماة التجميع الذي يعني أن كائ ًنا‬
‫نوعً ا خا ً‬
‫اًل‬
‫كائنات أخرى ( القطع)‪ .‬إلظهار ذلك ‪ ،‬نستخدم شك ماسيًا بجوار الفئة التي تمثل جميع‪ .‬يظهر هذا في الشكل ‪ ، 5.13‬والذي يوضح أن‬
‫سجل المريض عبارة عن تركيبة‪ -‬للمريض وعدد غير محدد من االستشارات‪ 5.4 .‬النماذج السلوكية النماذج السلوكية هي نماذج للسلوك‬
‫الديناميكي للنظام أثناء تنفيذه‪ .‬إنها تظهر ما يحدث أو ما يفترض أن يحدث عندما يستجيب النظام لـ التحفيز من بيئتها‪ .‬يمكنك التفكير في‬
‫هذه المحفزات على أنها من نوعين‪ .1 :‬البيانات تصل بعض البيانات التي يجب معالجتها‪ W‬بواسطة النظام‪ .2 .‬األحداث يحدث بعض‬
‫األحداث التي تؤدي إلى تشغيل معالجة النظام‪ .‬قد يكون لألحداث البيانات المرتبطة ولكن هذا ليس هو الحال دائمًا‪ .‬طبيب اسم هاتف ‪#‬‬
‫بريد إلكتروني يسجل ( ) إلغاء التسجيل () طبيب مستشفى طاقم عمل ‪ #‬بيجر ‪ #‬طبيب عام يمارس عنوان الشكل ‪ 5.12‬تعميم التسلسل‬
‫الهرمي مع التفاصيل المضافة مريض سِ ِج ّل استشارة المريض ‪ * .. 1 1 1 1‬الشكل ‪ 5.13‬تجميع الترابط ‪ 134‬الفصل ‪ 5‬نمذجة النظام‬
‫العديد من أنظمة األعمال هي أنظمة معالجة البيانات التي يقودها في المقام األول بيانات‪ .‬يتم التحكم فيها من قبإلدخال البيانات إلى النظام‬
‫مع خارجي قليل نسبيًا معالجة الحدث‪ .‬تتضمن معالجتها‪ W‬سلسلة من اإلجراءات على تلك البيانات و توليد المخرجات‪ .‬على سبيل المثال ‪،‬‬
‫سيقبل نظام فوترة الهاتف المعلومات حول المكالمات التي أجراها عميل ‪ ،‬وحساب تكاليف هذه المكالمات ‪ ،‬وإنشاء فاتورة ليتم إرسالها‬
‫إلى هذا العميل‪ .‬على النقيض من ذلك ‪ ،‬غالبًا ما تكون أنظمة الوقت الفعلي مدفوعة باألحداث الحد األدنى من معالجة البيانات‪ .‬على سبيل‬
‫المثال ‪ ،‬يستجيب نظام تبديل الهاتف األرضي أحداث مثل "ربط جهاز االستقبال" عن طريق توليد نغمة اتصال أو الضغط على المفاتيح‬
‫هاتف عن طريق التقاط رقم الهاتف ‪ ،‬وما إلى ذلك‪ 5.4.1 .‬النمذجة المبنية على البيانات ُتظهر النماذج المبنية على البيانات تسلسل‬
‫اإلجراءات المتضمنة في معالجة‪ W‬بيانات اإلدخال وتوليد مخرجات مرتبطة‪ .‬إنها مفيدة بشكل خاص أثناء التحليل من المتطلبات حيث يمكن‬
‫استخدامها إلظهار المعالجة الشاملة في النظام‪ .‬الذي ‪ -‬التي هو أنها تظهر التسلسل الكامل لإلجراءات التي تحدث من كائن مُدخل معالجة‬
‫إلى الناتج المقابل ‪ ،‬وهو استجابة النظام‪ .‬كانت النماذج المبنية على البيانات من بين نماذج البرامج الرسومية األولى‪ .‬في ال سبعينيات‬
‫كطريقة )‪ (DFDs‬قدم مخططات تدفق البيانات )‪ DeMarco (DeMarco ، 1978‬القرن الماضي ‪ ،‬طرق منظمة مثل التحليل الهيكلي لـ‬
‫لتوضيح خطوات المعالجة في النظام‪ .‬تعد نماذج تدفق البيانات مفيدة ألن تتبع وتوثيق كيفية عمل البيانات المرتبطة بعملية معينة تتحرك‬
‫ومن الممكن عاد ًة شرحها ‪ itive‬من خالل النظام تساعد المحللين والمصممين يفهمون ما يجري‪ .‬مخططات تدفق البيانات بسيطة وسهلة‬
‫مخططات تدفق البيانات كما تم ‪ UML‬لمستخدمي النظام المحتملين الذين يمكنهم ذلك المشاركة في التحقق من صحة النموذج‪ .‬ال يدعم‬
‫تركز على النظام وظائف وال تتعرف على كائنات ‪ DFDs‬اقتراحها في األصل و تستخدم لنمذجة معالجة البيانات‪ .‬والسبب في ذلك هو أن‬
‫مخططات النشاط ‪ ،‬والتي تشبه ‪ UML 2.0‬النظام‪ .‬ومع ذلك ‪ ،‬ألن األنظمة تعتمد على البيانات شائعة ج ًدا في األعمال التجارية ‪ ،‬فقد قدم‬
‫مخططات تدفق البيانات‪ .‬على سبيل المثال ‪ ،‬يوضح الشكل ‪ 5.14‬سلسلة المعالجة المتضمنة في برنامج مضخة األنسولين‪ .‬في هذا الرسم‬
‫والبيانات المتدفقة بين هذه الخطوات (ممثلة ككائنات)‪ .‬طريقة )يتم إرسالها كأنشطة ‪ (repre-‬البياني ‪ ،‬يمكنك رؤية خطوات المعالجة‬
‫مخططات التسلسل‪ .‬لقد رأيت كيف يمكن استخدامها لنمذجة التفاعل ولكن ‪ UML ،‬بديلة إلظهار تسلسل المعالجة في النظام هي استخدام‬
‫هي نماذج نظام ُتظهر منظورً ا وظيفيًا حيث كل تحويل يمثل وظيفة أو )‪ (DFDs‬إذا مخططات تدفق البيانات مخططات‪ W‬تدفق البيانات‬
‫إلظهار كيفية تدفق البيانات من خالل سلسلة من المعالجة خطوات‪ .‬على سبيل المثال ‪ ،‬يمكن أن تتمثل ‪ DFDs‬عملية واحدة‪ .‬يتم استخدام‬
‫خطوة المعالجة في تصفية السجالت المكررة في قاعدة بيانات العمالء‪ .‬البيانات يتحول في كل خطوة قبل االنتقال إلى المرحلة التالية‪.‬‬
‫‪.‬خطوات المعالجة‪ W‬هذه أو التحوالت تمثل عمليات أو وظائف البرامج حيث ُتستخدم مخططات‪ W‬تدفق البيانات لتوثيق تصميم البرنامج‬
‫النماذج السلوكية ‪ 135‬تقوم برسم هذه الرسائل بحيث يتم إرسال ‪http://www.SoftwareEngineering-9.com/Web/DFDs5.4‬‬
‫الرسائل فقط من اليسار إلى اليمين ‪ ،‬ثم تعرض ملف معالجة البيانات المتسلسلة في النظام‪ .‬يوضح الشكل ‪ 5.15‬هذا باستخدام تسلسل‬
‫نموذج لمعالجة الطلب وإرساله إلى المورد‪ .‬نماذج التسلسل عالية األجسام الخفيفة في النظام ‪ ،‬بينما ُتبرز الرسوم البيانية لتدفق البيانات‬
‫صفحات ب‪ 5.4.2 .‬النمذجة المدفوعة باألحداث ُتظهر ‪ we‬الوظائف‪ .‬ال يظهر مخطط تدفق البيانات المكافئ لمعالجة الطلبات في كتاب‬
‫النمذجة المدفوعة باألحداث كيف يستجيب النظام لألحداث الخارجية والداخلية‪ .‬إنها بنا ًء على افتراض أن النظام لديه عدد محدود من‬
‫قد يتسبب في االنتقال من حالة إلى أخرى‪ .‬على سبيل المثال ‪ ،‬نظام يتحكم في ملف قد ينتقل الصمام )‪- uli‬التحفيز( الحاالت وأن األحداث‬
‫مغلق" عند عامل التشغيل يتم استالم األمر (التحفيز)‪ .‬وجهة النظر هذه للنظام مناسبة ‪ "V alve‬إلى حالة "‪ "V alve open‬من حالة‬
‫بشكل خاص لـ أنظمة الوقت الفعلي‪ .‬تم تقديم النمذجة المستندة إلى الحدث في طرق التصميم في الوقت الفعلي مثل تلك التي اقترحها وارد‬
‫النمذجة القائمة على الحدث باستخدام مخططات‪ W‬الحالة ‪ ،‬والتي كانت مبنية ‪ UML‬وميلور (‪ )1985‬وهاريل (‪ .)1988 ، 1987‬يدعم‬
‫ُتظهر مخططات‪ W‬الحالة حاالت النظام واألحداث التي تسبب ‪:‬طلب أمأل ( ) ضابط ‪).‬هاريل ‪ Statecharts (1988 ، 1987 ،‬على‬
‫شراء التحقق من صحة () [التحقق من صحة جيدة] "مخزن البيانات" طلبات ميزانية تحديث (المبلغ) يحفظ ( ) المورد يرسل ( ) الشكل‬
‫‪ 5.14‬نشاط نموذج األنسولين تشغيل المضخة سكر الدم المستشعر سكر الدم مستوى األنسولين متطلبات التحكم في المضخة أوامر‬
‫األنسولين مضخة احصل على جهاز االستشعار قيمة احسب مضخة أوامر المستشعر بيانات إحصاء ‪ -‬عد مستوى السكر احسب‬
‫األنسولين توصيل يتحكم مضخة الشكل ‪ 5.15‬ترتيب معالجة ‪ 136‬الفصل ‪ 5‬نمذجة النظام انتقاالت من دولة إلى أخرى‪ .‬ال تظهر تدفق‬
‫البيانات داخل النظام ولكن قد تتضمن معلومات إضافية عن الحسابات التي أجريت في كل والية‪ .‬أستخدم مثاالً لبرمجيات التحكم لفرن‬
‫تعقيدا من هذا النظام ‪ trate.‬ميكروويف بسيط ج ًدا ألفهم‪ -‬النمذجة التي يقودها الحدث‬ ‫ً‬ ‫أفران الميكروويف الحقيقية هي في الواقع أكثر‬
‫ولكن النظام المبسط أسهل في الفهم‪ .‬هذا بسيط يحتوي الميكروويف على مفتاح الختيار الطاقة الكاملة أو نصف ‪ ،‬ولوحة مفاتيح رقمية‬
‫إلدخال وقت الطهي وزر بدء ‪ /‬إيقاف وشاشة أبجدية رقمية‪ .‬لقد افترضت أن تسلسل اإلجراءات في استخدام الميكروويف هو‪ .1 :‬حدد‬
‫ويتم ‪ Start‬مستوى الطاقة (إما نصف الطاقة أو الطاقة الكاملة)‪ .2 .‬أدخل وقت الطهي باستخدام لوحة مفاتيح رقمية‪ .3 .‬اضغط على‬
‫طهي الطعام في الوقت المحدد‪ .‬ألسباب تتعلق بالسالمة ‪ ،‬يجب أال يعمل الفرن عند فتح الباب وتشغيله االنتهاء من الطهي ‪ ،‬ويطلق‬
‫ُتستخدم لعرض العديد من التنبيهات ورسائل التحذير‪ meric .‬شاشة‪ alphanu- W‬الجرس‪ .‬يحتوي الفرن على حرف بسيط للغاية من نوع‬
‫تمثل المستطيالت الدائرية حاالت النظام‪ .‬انهم قد قم بتضمين وصف موجز (بعد "فعل") لإلجراءات المتخذة ‪ UML ،‬في مخططات حالة‬
‫في تلك الحالة‪ .‬ال تمثل األسهم المسمى المنبهات التي تفرض االنتقال من حالة إلى أخرى‪ .‬أنت يمكن أن تشير إلى حاالت البداية والنهاية‬
‫باستخدام الدوائر المملوءة ‪ ،‬كما هو الحال في مخططات‪ W‬النشاط‪ .‬من الشكل ‪ ، 5.16‬يمكنك أن ترى أن النظام يبدأ في حالة انتظار و‬
‫يستجيب مبدئ ًي ا إما لزر الطاقة الكاملة أو زر نصف الطاقة‪ .‬يمكن للمستخدمين التغيير ممكن ممتلىء قوة نصف قوة نصف قوة ممتلىء‬
‫قوة رقم باب يفتح باب مغلق الباب مغلق باب يفتح يبدأ نصف القوة افعل‪ :‬ضبط الطاقة = ‪ 300‬ضبط الوقت افعل‪ :‬احصل على الرقم‬
‫خروج‪ :‬ضبط الوقت عاجز يلغي منتظر قم بما يلي‪ :‬العرض وقت منتظر قم بما يلي‪ :‬العرض وقت القوة الكاملة افعل‪ :‬ضبط الطاقة =‬
‫‪ 600‬عملية هل‪ :‬تعمل فرن قم بما يلي‪ :‬العرض 'مستعد' قم بما يلي‪ :‬العرض 'منتظر' الموقت الموقت الشكل ‪ 5.16‬مخطط الحالة ‪5.4‬‬
‫النماذج السلوكية ‪ 137‬رأيهم بعد اختيار واحد من هؤالء والضغط على الزر اآلخر‪ .‬تم ضبط الوقت و ‪ ،‬إذا كان الباب مغل ًقا ‪ ،‬فسيتم‬
‫تمكين زر البدء‪ .‬الضغط على هذا الزر يبدأ الفرن يتم التشغيل والطهي في الوقت المحدد‪ .‬هذه نهايةيطبخ‪ -‬دورة جي ويعود النظام إلى‬
‫اإلشارة إلى النشاط الذي يحدث في حالة ما‪ .‬في مواصفات النظام التفصيلية التي يجب أن تقدم مزي ًدا ‪ UML‬حالة االنتظار‪ .‬يتيح لك تدوين‬
‫من التفاصيل حول كل من المحفزات وينص النظام‪ .‬أوضح ذلك في الشكل ‪ ، 5.17‬الذي يوضح وص ًفا جدوليًا‪ -‬عن كل حالة وكيف يتم‬
‫إنشاء المحفزات التي تفرض تحوالت الحالة‪ .‬مشكلة النمذجة القائمة على الدولة هي أن عدد الحاالت الممكنة يزداد بسرعة‪ .‬لذلك ‪،‬‬
‫بالنسبة لنماذج النظام الكبيرة ‪ ،‬تحتاج إلى إخفاء التفاصيل في ملف وصف الحالة في انتظار الفرن ينتظر اإلدخال‪ .‬تعرض الشاشة الوقت‬
‫الحالي‪ .‬نصف قوة الفرن تم ضبطه على ‪ 300‬وات‪ .‬يظهر على الشاشة "نصف القوة"‪ .‬الطاقة الكاملة تم ضبط طاقة الفرن على ‪600‬‬
‫وات‪ .‬تعرض الشاشة "القوة الكاملة"‪ .‬ضبط الوقت يتم ضبط وقت الطهي على قيمة إدخال المستخدم‪ .‬تظهر الشاشة يتم تحديد وقت الطهي‬
‫ويتم تحديثه عند ضبط الوقت‪ .‬تم تعطيل تشغيل الفرن المعطل من أجل السالمة‪ .‬ضوء الفرن الداخلي مضاء‪ .‬يظهر على الشاشة "غير‬
‫جاهز"‪ .‬تم تمكين تشغيل الفرن المم ّك ن‪ .‬ضوء الفرن الداخلي مطفأ‪ .‬يظهر العرض 'على استعداد لطهي الطعام'‪ .‬فرن التشغيل قيد‬
‫التشغيل‪ .‬ضوء الفرن الداخلي مضاء‪ .‬يظهر على الشاشة الموقت العد التنازلي‪ .‬عند االنتهاء من الطهي ‪ ،‬يصدر صوت الجرس خمس‬
‫ثواني‪ .‬إضاءة الفرن مضاءة‪ .‬يظهر على الشاشة "الطهي الكامل" أثناء سماع صوت الجرس‪ .‬وصف التحفيز نصف الطاقة ضغط‬
‫المستخدم على زر نصف الطاقة‪ .‬القوة الكاملة قام المستخدم بالضغط على زر الطاقة الكاملة‪ .‬المؤقت قام المستخدم بالضغط على أحد‬
‫أزرار المؤقت‪ .‬الرقم ضغط المستخدم‪ W‬على مفتاح رقمي‪ .‬الباب مفتوح مفتاح باب الفرن غير مغلق‪ .‬الباب مغلق مفتاح باب الفرن مغلق‪.‬‬
‫بدء ضغط المستخدم على زر ابدأ‪ .‬إلغاء ضغط المستخدم على زر إلغاء‪ .‬الشكل ‪ 5.17‬الدول ومحفزات فرن الميكروويف ‪ 138‬الفصل‬
‫عدد الدول المنفصلة‪ 5 a .‬نمذجة النظام عارضات ازياء‪ .‬تتمثل إحدى طرق القيام بذلك في استخدام فكرة الدولة العظمى التي تلخص‬
‫عال النموذج ولكن يتم توسيعه بعد ذلك إلظهار مزيد من التفاصيل في مخطط‬ ‫تبدو هذه الدولة العظمى وكأنها دولة واحدة على مستوى ٍ‬
 ‫منفصل‪ .‬لتوضيح هذا المفهوم ‪ ،‬ضع في اعتبارك حالة العملية في الشكل ‪ .5.15‬هذه دولة عظمى يمكنها ذلك يتم توسيعها ‪ ،‬كما هو‬
‫عدد ا من الحاالت الفرعية‪ .‬يظهر أن العملية تبدأ مع فحص الحالة وأنه إذا تم اكتشاف أي‬‫موضح في الشكل ‪ .5.18‬تتضمن حالة العملية ً‬
‫مشاكل ‪ ،‬فسيتم اإلشارة إلى إنذار و العملية معطلة‪ .‬يشمل الطهي تشغيل مولد الميكروويف لـ وقت محدد؛ عند االنتهاء ‪ ،‬يصدر صوت‬
‫صفارة‪ .‬إذا تم فتح الباب أثناء العملية ‪ ،‬ينتقل النظام إلى حالة التعطيل ‪ ،‬كما هو موضح في الشكل ‪ 5.5 .5.15‬الهندسة التي يحركها‬
‫هي نهج لتطوير البرامج حيث إلس بدالً من البرامج هي المخرجات الرئيسية لعملية )‪ (MDE‬النموذج الهندسة التي تعتمد على النموذج‬
‫البرامج التي يتم تنفيذها على منصة األجهزة ‪ /‬البرامج هي ثم يتم إنشاؤها تلقائيًا من ‪).‬؛ شميت ‪ (Kent ، 2002 2006 ،‬التطوير‬
‫يجادلون بأن هذا يثير مستوى التجريد في هندسة البرمجيات بحيث ال يضطر المهندسون ألن يكونوا كذلك تهتم ‪ MDE‬النماذج‪ .‬أنصار‬
‫تم )‪ (MDA‬بتفاصيل لغة البرمجة أو تفاصيل منصات التنفيذ‪ .‬الهندسة التي يحركها النموذج لها جذورها في العمارة القائمة على النموذج‬
‫في عام ‪ 2001‬كبرنامج جديد نموذج التنمية‪ .‬الهندسة التي يحركها النموذج والعمارة )‪ (OMG‬اقتراحه من قبل مجموعة إدارة الكائنات‬
‫نطا ًقا أوسع من القرص الدوار عيب ‪ t MDE‬التي يحركها النموذج هي غالبًا ما يُنظر إليه على أنه نفس الشيء‪ .‬ومع ذلك ‪ ،‬أعتقد أنيمتلك‬
‫باعث عيب نفذ الوقت يطبخ افعل‪ :‬تشغيل مولد كهرباء منتهي قم بما يلي‪ :‬تشغيل الجرس لمدة ‪ 5‬ثوانى‪ .‬منتظر إنذار قم بما يلي‪ :‬العرض‬
‫حدث افعل‪ :‬تحقق حالة تدقيق عاجز نعم وقت الباب مفتوح عملية يلغي الشكل ‪ 5.18‬الميكروويف تشغيل الفرن ‪ 5.5‬الهندسة النموذجية‬
‫‪ MDE‬على التصميم والتنفيذ مراحل نشوئها من تطوير البرمجيات بينما يهتم ‪ MDA‬كما أناقش الح ًقا في هذا القسم ‪ ،‬تركز ‪139 MDA.‬‬
‫الهندسة والعمليات البرمجية ‪- Ments‬بجميع جوانب عملية هندسة البرمجيات‪ .‬لذلك ‪ ،‬تتطلب موضوعات مثل المستندة إلى النموذج‬
‫حاليًا‪ .‬على الرغم من ‪ MDA‬ولكنه ليس جزءًا من ‪ MDE‬جزءًا من ‪ MDE‬للتطوير القائم على النموذج والنموذج‪ -‬يعد االختبار القائم على‬
‫منذ عام ‪ ، 2001‬إال أن الهندسة القائمة على النموذج ال تزال في مستوى مرحلة مبكرة من التطور وليس من الواضح ما ‪ MDA‬استخدام‬
‫إذا كان سيكون له أهمية كبيرة أم ال تأثير على ممارسة هندسة البرمجيات‪ .‬الحجج الرئيسية المؤيدة والمعارضة هي‪ .1 :‬بالنسبة للهندسة‬
‫عال من التجريد ‪ ،‬دون االهتمام بتفاصيل تنفيذها ‪ MDE ،‬القائمة على نموذج‬ ‫تسمح للمهندسين بالتفكير في األنظمة على مستوى مستوى ٍ‬
‫ويسمح بإنشاء نظام أساسي قابل إلعادة االستخدام ‪ - tation ،‬نشوئها‪ .‬هذا يقلل من احتمالية األخطاء ويسرع التصميم وتنفيذ‪ -‬عملية‬
‫ومستقل عن النظام األساسي نماذج التطبيق‪ .‬باستخدام أدوات قوية ‪ ،‬يمكن أن تكون تطبيقات النظام تم إنشاؤه لمنصات مختلفة من نفس‬
‫لتلك المنصة‪ .‬عندما ‪- Tor‬النموذج‪ .‬لذلك ‪ ،‬للتكيف مع نظام لبعض تقنيات النظام األساسي الجديدة ‪ ،‬فمن الضروري فقط كتابة ترجمة‬
‫يكون هذا متاحً ا ‪ ،‬فإن جميع الطرز المستقلة عن النظام األساسي يمكن إعادة استضافته بسرعة على النظام األساسي الجديد‪ .2 .‬ضد‬
‫كما ناقشت ساب ًقا في هذا الفصل ‪ ،‬النماذج هي طريقة جيدة تسهيل المناقشات‪ W‬حول تصميم البرنامج‪ .‬ومع ذلك ‪ ،‬هذا ليس دائما اتبع ‪MDE‬‬
‫أن األفكار المجردة التي يدعمها النموذج هي االمتيازات الصحيحة‪ -‬من أجل التنفيذ‪ .‬لذلك ‪ ،‬يمكنك إنشاء‪ W‬نماذج تصميم غير رسمية ولكن‬
‫بعد ذلك استمر في تنفيذ النظام باستخدام حزمة جاهزة قابلة للتكوين‪ .‬عالوة على ذلك ‪ ،‬فإن الحجج المؤيدة الستقالل النظام األساسي‬
‫صالحة فقط للكثير األنظمة طويلة العمر حيث تصبح األنظمة األساسية قديمة خالل النظام حياة‪ .‬ومع ذلك ‪ ،‬بالنسبة لهذه الفئة من األنظمة‬
‫مع األنظمة القديمة ‪ ،‬واالختبار ‪ ، ، inte- gration‬نعلم أن التنفيذ ليس كذلك المشكلة الرئيسية ‪ -‬المتطلبات الهندسية واألمن واالعتمادية‬
‫على هذه القصص صفحات الويب ‪ OMG‬من قبل ‪ MDE‬أكثر أهمية‪ .‬تم اإلبالغ عن قصص نجاح مهمة‬
‫تم ‪ Siemens.‬و ‪ IBM‬والطريقة المستخدمة داخل الشركات الكبيرة مثل )‪(www.omg.org/mda/products_success.htm‬‬
‫استخدام التقنيات بنجاح توقف في تطوير أنظمة برمجيات كبيرة وطويلة العمر مثل الحركة الجوية أنظمة اإلدارة‪ .‬ومع ذلك ‪ ،‬في وقت‬
‫كتابة هذا التقرير ‪ ،‬نهج يحركها النموذج ال تستخدم على نطاق واسع لهندسة البرمجيات‪ .‬مثل األساليب الرسمية في هندسة البرمجيات‬
‫تطور مهم‪ -‬منة‪ .‬ومع ذلك ‪ ،‬كما هو الحال أيضً ا مع األساليب الرسمية ‪ ،‬ليس ‪ MDE‬الذي ناقشته في الفصل ‪ ، 12‬أعتقد أن ‪neering ،‬‬
‫من الواضح ما إذا كان تكاليف ومخاطر النهج التي يحركها النموذج تفوق الفوائد المحتملة‪ 5.5.1 .‬العمارة التي يحركها النموذج العمارة‬
‫هو نهج يركز على )‪ Stahl and V oelter ، 2006‬؛‪ Mellor et al.، 2004‬؛‪ (Kleppe، et al.، 2003‬التي يحركها النموذج‬
‫لوصف النظام‪ .‬هنا ‪ ،‬نماذج مختلفة في نظام النمذجة ‪ UML 140‬النموذج لتصميم البرامج وتنفيذها يستخدم مجموعة فرعية من نماذج‬
‫الفصل ‪ 5‬يتم إنشاء مستويات التجريد‪ .‬من منصة رفيعة المستوى مستقلةالنموذج هو عليه من الممكن ‪ ،‬من حيث المبدأ ‪ ،‬إنشاء برنامج‬
‫بضرورة وجود ثالثة أنواع من نموذج النظام المجرد يتم إنتاجه‪ .1 :‬نموذج حسابي مستقل ‪ MDA‬عمل بدون تدخل يدوي‪ .‬توصي طريقة‬
‫مختلفة تعكس ‪ CIMs‬نماذج المجال‪ .‬يمكنك تطوير عدة ‪ CIMs‬يمثل المجال المهم التجريدات المستخدمة في النظام‪ .‬تسمى أحيا ًنا )‪(CIM‬‬
‫أمني تحدد فيه أهمية تجريدات األمان مثل األصول والدور ‪ CIM‬وجهات نظر مختلفة للنظام‪ -‬تيم‪ .‬على سبيل المثال ‪ ،‬قد يكون هناك‬
‫)‪ (PIM‬في الذي تصف فيه أفكارً ا مجردة مثل المرضى واالستشارات وما إلى ذلك‪ .2 .‬نموذج مستقل للمنصة ‪ CIM ،‬وسجل المريض‬
‫التي ُتظهر بنية النظام الثابتة وكيف ‪ UML‬باستخدام نماذج ‪ PIM‬يقوم بنمذجة تشغيل النظام دون الرجوع إلى تنفيذه‪ .‬عادة ما يتم وصف‬
‫منفصل ‪ PSM‬وهي تحويالت للمنصة‪ -‬نموذج مستقل مع )‪ (PSM‬تستجيب للخارج‪ -‬نال واألحداث الداخلية‪ .3 .‬نماذج خاصة بالمنصة‬
‫مع إضافة كل طبقة بعض النظام األساسي‪ -‬تفاصيل محددة‪ .‬لذلك ‪ PSM ، ،‬لكل منصة تطبيق‪ .‬في المبدأ ‪ ،‬قد تكون هناك طبقات من‬
‫من المستوى األول خاصً ا بالبرامج الوسيطة ولكن قاعدة بيانات مستقلة‪ .‬عندما يتم اختيار قاعدة بيانات محددة ‪ ،‬فإن ‪ PSM‬يمكن أن يكون‬
‫محدد‪ .‬كما قلت ‪ ،‬يمكن تحديد وتطبيق التحوالت بين هذه النماذج تلقائيًا بواسطة أدوات ‪ PSM‬قاعدة البيانات‪ -‬يمكن بعد ذلك إنشاء‬
‫ض ا مستوى نهائي من التحول التلقائي‪ .‬يتم تطبيق التحول على‬ ‫إلى إنشاء ‪ PSM‬البرامج‪ .‬هذا موضح في الشكل ‪ ، 5.19‬والذي يظهر أي ً‬
‫تعليمات برمجية قابلة للتنفيذ يتم تشغيلها على النظام األساسي للبرنامج المحدد‪ .‬في وقت كتابة هذا التقرير ‪ ،‬كانت الترجمة التلقائية لـ‬
‫المرحلة‪ .‬من غير المحتمل أن تكون أدوات الترجمة المؤتمتة بالكامل متاحة في المستقبل ‪ - totype‬ال تزال قيد البحث ‪ PIM‬إلى ‪CIM‬‬
‫القريب‪ .‬التدخل البشري ‪ ،‬المشار إليه برقم عصا في الشكل ‪ ، 5.19‬سيفي بالغرض ستكون ضرورية في المستقبل المنظور‪ .‬ترتبط‬
‫وجزء من الترجمة منصة محدد نموذج منصة مستقل نموذج تنفيذ شفرة مترجم مترجم مترجم مجال محدد القواعد االرشادية ‪CIMs‬‬
‫التحوالت ‪ 5.5‬الهندسة النموذجية ‪ 141‬قد ‪ MDA‬منصة أنماط محددة والقواعد لغة محدد أنماط حساب مستقل نموذج الشكل ‪5.19‬‬
‫يمكن تعيينه على مفهوم الموظف في ‪ CIM‬المختلفة‪ .‬على سبيل المثال ‪ ،‬مفهوم دور في األمن ‪ CIMs‬تتضمن العملية ربط المفاهيم في‬
‫إلى آخر‪ .‬تعد ‪ CIM‬اسم "الجسور" للمعلومات التي تدعم‪ -‬تعيين المنافذ من )‪ Mellor and Balcer (2002‬أعطى ‪ CIM.‬المستشفى‬
‫إلى منصات مشتركة مثل ‪ PIMs‬أكثر نضجً ا والعديد من األدوات التجارية المتوفرة التي توفر مترجمين من ‪ PSM‬إلى ‪ PIMs‬ترجمة‬
‫‪ PSMs‬قد يكون هناك عدة ‪ PSM.‬إلى ‪ PIM‬هذه تعتمد على مكتبة واسعة من القواعد واألنماط الخاصة بالمنصة تحويل ‪ J2EE.‬و ‪Java‬‬
‫إذن ‪ .NET) ،‬و ‪ ، J2EE‬على سبيل المثال( في النظام‪ .‬إذا كان الهدف من نظام برمجي أن يعمل على أنظمة أساسية مختلفة ‪ PIM‬لكل‬
‫لكل منصة تلقائية‪ -‬تم إنشاؤه بشكل متقطع‪ .‬هذا موضح في الشكل ‪ .5.20‬على ‪ PSMs‬تكون ‪ PIM.‬فمن الضروري فقط الحفاظ على‬
‫تتضمن مترجمين خاصين بمنصة معينة ‪ ،‬إال أنها غالبًا ما تكون كذلك في حالة أن هذه لن تقدم سوى ‪ MDA‬الرغم من أن أدوات دعم‬
‫( في الغالبية العظمى من الحاالت ‪ ،‬تكون بيئة التنفيذ للنظام أكثر من منصة التنفيذ القياسية ‪ PSMs.‬إلى ‪ PIMs‬دعم جزئي للترجمة من‬
‫كذلك يتضمن أنظمة التطبيقات األخرى ‪ ،‬مكتبات التطبيقات التير خاصة ب مكتبات واجهة ‪).‬إلخ ‪ ، J2EE ، .NET ،‬على سبيل المثال‬
‫إلى آخر ‪ ،‬ال يتوفر دعم األداة القياسي‪ .‬لذلك ‪ ،‬عندما ‪ pany‬المستخدم والشركة‪ .‬نظرً ا ألن هذه تختلف اختال ًفا كبيرً ا من شركة واحدة‬
‫مقد ًم ا ‪ ،‬قد يتعين إنشاء مترجمين ألغراض خاصة يأخذون الطابع‪ -‬عوامل البيئة المحلية في االعتبار‪ .‬في بعض الحاالت ‪ MDA‬يكون‬
‫مستحيل‪ .‬هناك عالقة غير مستقرة بين ‪ PSM‬المؤتمتة بالكامل إلى ‪( PIM‬على سبيل المثال ‪ ،‬للمستخدم إنشاء واجهة) ‪ ،‬قد تكون ترجمة‬
‫األساليب الرشيقة واألرشيف الذي يحركه النموذج‪ -‬محاضرة‪ .‬تتناقض فكرة النمذجة المسبقة الشاملة مع األفكار األساسية في بيان رشيق‬
‫أنه يهدف إلى دعم‪ -‬وضع نهج ‪ MDA‬وأعتقد أن القليل من المطورين الرشيقة يشعرون بالراحة تجاه الهندسة النموذجية‪ .‬يدعي مطورو‬
‫تكراري للتطوير وبالتالي يمكن استخدامه ضمن األساليب الرشيقة (ميلور وآخرون ‪ .)2004 ،‬إذا كان من الممكن أن تكون التحوالت‬
‫في ملف عملية تطوير رشيقة حيث ‪ MDA‬ثم ‪ ،‬من حيث المبدأ ‪ ،‬يمكن استخدام ‪ PIM ،‬الذي تم إنشاؤه من ‪ plete‬مؤتمتة بالكامل وعملية‬
‫تدعم ممارسات‪ W‬مثل اختبار االنحدار‪ -‬جي ‪ MDA‬لن تكون هناك حاجة إلى ترميز منفصل‪ .‬ومع ذلك ‪ ،‬بقدر ما كما أعلم ‪ ،‬ال توجد أدوات‬
‫برنامج المترجم ‪ J2EE‬مولد كهرباء كود جافا مولد كهرباء مترجم ‪ C #‬و اختبار يحركها التنمية‪ .‬منصة مستقل نموذج برنامج جافا كود‬
‫النموذج هو ‪ K E Y P O I N T S‬محددة نموذج الشكل ‪ 5.20‬متعدد منصة خاصة الموديالت ‪ NET‬نموذج ‪ J2EE‬خاص بـ ‪ C #‬الصافي‬
‫عرض تجريدي لنظام يتجاهل بعض تفاصيل النظام‪ .‬النظام التكميلي يمكن تطوير النماذج إلظهار سياق النظام والتفاعالت والبنية‬
‫والسلوك‪ .‬توضح نماذج السياق كيف يتم وضع النظام الذي يتم تصميمه في بيئة بها أنظمة وعمليات أخرى‪ .‬تساعد في تحديد حدود النظام‬
‫المطلوب تطويره‪ .‬يتم استخدام مخططات‪ W‬الحالة ومخططات التسلسل لوصف التفاعالت بين المستخدم النظام الذي يجري تصميمه‬
‫والمستخدمون ‪ /‬األنظمة األخرى‪ .‬تصف حاالت االستخدام التفاعالت بين أ النظام والجهات الفاعلة الخارجية ؛ تضيف مخططات‬
‫‪ UML‬التسلسل مزي ًد ا من المعلومات إليها من خالل إظهارها التفاعالت بين كائنات النظام‪ 142 .‬الفصل الخامس نمذجة النظام ‪5.5.2‬‬
‫قابل للتنفيذ الفكرة األساسية وراء الهندسة التي يحركها النموذج هي أنها آلية بالكامل يجب أن يكون تحويل النماذج إلى رمز ممك ًنا‪.‬‬
‫ضا بحاجة إلى ملف طريقة‬ ‫لتحقيق ذلك ‪ ،‬عليك أن تكون كذلك قادر على بناء نماذج رسومية يتم تعريف دالالتها بشكل جيد‪ .‬أنت أي ً‬
‫إضافة معلومات إلى النماذج الرسومية حول الطرق التي تتم بها العمليات المحددة في النموذج يتم تنفيذها‪ .‬هذا ممكن باستخدام مجموعة‬
‫ليس لدي مساحة هنا وصف تفاصيل ‪ xUML (Mellor and Balcer ، 2002).‬قابل للتنفيذ أو ‪ UML‬تسمى ‪ UML 2 ،‬فرعية من‬
‫كلغة لدعم وتوثيق البرامج التصميم ‪ ،‬وليس كلغة ‪ UML‬لذلك أقدم ببساطة لمحة موجزة عن ميزاتها الرئيسية‪ .‬تم تصميم ‪xUML ،‬‬
‫قلقين مع التفاصيل الداللية للغة ولكن مع تعبيرها‪ .‬أدخلوا مفاهيم مفيدة مثل استخدام المخططات‪ W‬التي ‪ UML‬برمجة‪ .‬لم يكن مصممو‬
‫ض ا مفيدة غير رسمي لدعم التنفيذ‪ .‬إلنشاء مجموعة فرعية قابلة للتنفيذ من‬ ‫الرقم لذلك تم تقليل أنواع ‪ UML ،‬تساعد في التصميم ولكنها أي ً‬
‫النماذج بشكل كبير إلى ثالثة أنواع رئيسية من النماذج‪ .1 :‬تحدد نماذج المجال االهتمامات‪ W‬الرئيسية في النظام‪ .‬يتم تعريف هذه باستخدام‬
‫التي تتضمن الكائنات والسمات والجمعيات‪ .2 .‬نماذج الفصل ‪ ،‬حيث يتم تحديد الفئات ‪ ،‬إلى جانب سماتها ‪ UML‬الرسوم التخطيطية لفئة‬
‫و عمليات‪. 3 .‬نماذج الحالة ‪ ،‬حيث يرتبط مخطط الحالة بكل فئة ويستخدم لوصف دورة حياة الفصل‪ .‬يمكن تحديد السلوك الديناميكي‬
‫مقياس‪ .‬لغة العمل هي مثل ‪ UML-‬أو يمكن التعبير عنها باستخدام لغة عمل )‪ (OCL‬للنظام بشكل تصريحي باستخدام امتداد لغة قيد الكائن‬
‫لغة البرمجة عالية المستوى حيث يمكنك الرجوع إلى الكائنات وخصائصها وتحديد اإلجراءات التي يجب القيام بها‪.‬تظهر النماذج الهيكلية‬
‫تنظيم وبنية النظام‪ .‬الرسوم البيانية للفئة تستخدم لتعريف الهيكل الثابت للفئات في النظام وجمعياتهم‪ .‬تستخدم النماذج السلوكية لوصف‬
‫السلوك الديناميكي لنظام تنفيذي‪ .‬هذا يمكن نمذجة من منظور البيانات التي يعالجها النظام أو األحداث التي تحفز االستجابات من النظام‪.‬‬
‫يمكن استخدام مخططات النشاط لنمذجة معالجة البيانات ‪ ،‬حيث كل نشاط يمثل خطوة عملية واحدة‪ُ .‬تستخدم مخططات الحالة لنمذجة‬
 ‫ً‬
‫استجابة للداخلية أو الخارجية األحداث‪ .‬الهندسة التي يحركها النموذج هي نهج لتطوير البرمجيات‪ W‬يكون فيه النظام يتم‬ ‫سلوك النظام‬
‫تمثيلها كمجموعة من النماذج التي يمكن تحويلها تلقائيًا إلى كود قابل للتنفيذ‪ .‬قراءة متعمقة تحليل المتطلبات وتصميم النظام‪ .‬يركز هذا‬
‫أديسون ‪. (L. Maciaszek ،‬المختلفة في عملية التحليل ‪ UML‬الكتاب على تحليل نظم المعلومات ويناقش كيف يمكن استخدام نماذج‬
‫إنه ‪ MDA.‬المقطر‪ :‬مبادئ العمارة التي يحركها النموذج‪ .‬هذا موجز ويمكن الوصول إليه مقدمة عن طريقة ‪.) MDA‬ويسلي ‪2001 ،‬‬
‫‪. (S.J.Mellor، K. Scott and D. Weise،‬مكتوب من قبل المتحمسين لذلك ال يذكر الكتاب الكثير عنه المشاكل المحتملة مع هذا النهج‬
‫هندسة البرمجيات مع الكائنات والمكونات ‪ ،‬الطبعة الثانية‪ .‬قصير ومقروء مقدمة ‪ UML:‬باستخدام )‪Addison-Wesley، 2004.‬‬
‫‪.‬على الرغم من أنها ليست وص ًفا كامالً للتدوين ‪ UML ،‬في مواصفات وتصميم النظام‪ .‬هذا الكتاب ممتاز ل تعلم وفهم ‪ UML‬الستخدام‬
‫اشرح سبب أهمية نمذجة سياق النظام الذي ‪(P. Stevens with R. Pooley، Addison-Wesley، 2006.) E X E R C I S E S 5.1‬‬
‫يتم تطويره‪ .‬يعطي مثالين على األخطاء المحتملة التي يمكن أن تنشأ إذا لم يفهم مهندسو البرمجيات‪ W‬سياق النظام‪ 5.2 .‬كيف يمكنك‬
‫استخدام نموذج نظام موجود بالفعل؟ اشرح لماذا ليس دائما من الضروري أن يكون نموذج النظام هذا كامالً وصحيحً ا‪ .‬هل سيكون األمر‬
‫طلب منك‬ ‫نفسه صحيحً ا إذا كنت تعمل على تطوير نموذج لنظام جديد؟ الفصل ‪ 5‬تمارين ‪ 143144‬الفصل ‪ 5‬نمذجة النظام ‪ 5.3‬لقد ُ‬
‫تطوير نظام يساعد في التخطيط لألحداث واسعة النطاق والحفالت مثل حفالت الزفاف ‪ ،‬واحتفاالت التخرج ‪ ،‬وحفالت أعياد الميالد ‪،‬‬
‫وما إلى ذلك‪ .‬باستخدام ملف مخطط النشاط ‪ ،‬نموذج سياق العملية لمثل هذا النظام الذي يعرض األنشطة يشارك في التخطيط لحفلة‬
‫اقترح ‪( MHC-PMS ،‬حجز مكان ‪ ،‬تنظيم الدعوات ‪ ،‬إلخ) والنظام العناصر التي يمكن استخدامها في كل مرحلة‪ .5.4 .‬بالنسبة لنظام‬
‫‪ MHC-‬مجموعة من حاالت االستخدام التي توضح التفاعالت بين أ الطبيب الذي يفحص المرضى ويصف لهم األدوية والعالجات و‬
‫قم بتطوير مخطط تسلسل يوضح التفاعالت المتضمنة عند تسجيل الطالب لدورة في الجامعة‪ .‬قد يكون التسجيل في الدورات ‪PMS. 5.5‬‬
‫محدو ًد ا ‪ ،‬وبالتالي فإن التسجيل يجب أن تتضمن العملية عمليات التحقق من توفر األماكن‪ .‬افترض أن الطالب يصل كتالوج الدورة‬
‫اإللكترونية للتعرف على الدورات المتاحة‪ 5.6 .‬مرحاضك بعناية في كيفية تمثيل الرسائل وصناديق البريد في نظام البريد اإللكتروني‬
‫انت تستخدم‪ .‬قم بنمذجة فئات الكائنات التي يمكن استخدامها في تنفيذ النظام إلى تمثل صندوق بريد ورسالة بريد إلكتروني‪ 5.7 .‬بنا ًء‬
‫على تجربتك مع ماكينة الصراف اآللي للبنك ‪ ،‬ارسم مخطط نشاط يصمم البيانات المعالجة المتضمنة عندما يقوم العميل بسحب النقود من‬
‫الجهاز‪ 5.8 .‬ارسم مخطط تسلسل لنفس النظام‪ .‬اشرح لماذا قد ترغب في التطوير كل من مخططات النشاط والتسلسل عند نمذجة سلوك‬
‫النظام‪ . 5.9 .‬ارسم مخططات الحالة الخاصة ببرنامج التحكم من أجل‪ :‬غسالة أوتوماتيكية بها برامج مختلفة ألنواع مختلفة من مالبس‪.‬‬
‫يجب أن يسمح ‪ LED.‬نظام للرد على الهاتف يسجل الرسائل الواردة ويعرض عدد الرسائل المقبولة على مؤشر ‪ DVD.‬برنامج مشغل‬
‫النظام للهاتف العميل لالتصال من أي مكان ‪ ،‬اكتب سلسلة من األرقام (يتم تحديدها كنغمات)‪ ، W‬وتشغيل أي رسائل مسجلة‪ .5.10 .‬أنت‬
‫مدير هندسة برمجيات ويقترح فريقك هذا النموذج يجب استخدام الهندسة لتطوير نظام جديد‪ .‬ما هي العوامل التي يجب أن تأخذها حساب‬
‫‪ R E F E R E N C E S Ambler، S.W and Jeffries، R.‬عند اتخاذ قرار بشأن تقديم هذا النهج الجديد إلى البرامج أم ال التنمية؟‬
‫النمذجة الرشيقة‪ :‬الممارسات الفعالة للتطرف البرمجة والعملية الموحدة‪ .‬نيويورك‪ :‬جون وايلي وأوالده‪ .‬بوش ‪ ،‬جي ‪ ،‬رامبو ‪(2002). ،‬‬
‫جيه ‪ ،‬وجاكوبسون ‪ ،‬آي (‪ .) 2005‬دليل مستخدم لغة النمذجة الموحدة ‪ ،‬الطبعة الثانية‪ .‬بوسطن‪ :‬أديسون ويسلي‪ .‬تشين ‪ ،‬ب‪.)1976( .‬‬
‫على نظم قواعد البيانات ‪ .36-9 ، )1( 1 ،‬كود ‪ ،‬إي إف ( ‪"". ACM Trans.‬نموذج عالقة الكيان ‪ -‬نحو عرض موحد للبيانات‬
‫عبر‪ .‬في أنظمة قواعد البيانات ‪" .) 1979". ACM -397 ، )4( 4 ،‬توسيع النموذج العالئقي لقاعدة البيانات اللتقاط المزيد من المعنى‬
‫‪ .434‬دي ماركو ‪ ،‬ت‪ .) 1978( .‬التحليل الهيكلي ومواصفات النظام‪ .‬نيويورك‪ :‬مطبعة يوردون‪ .‬إريكسون ‪ ،‬جيه وساو ‪ ،‬ك‪( .‬‬
‫هامر ‪ ،‬إم وماكلويد ‪ ،‬د‪" .)2007 ACM ، 50 (8) ، 46-51. .)1981( .‬التعقيد النظري والعملي لطرق النمذجة"‪ .‬باالتصاالت‬
‫في أنظمة قواعد البيانات ‪'. ACM Trans. .86–351 ، )3( 6 ،‬قاعدة بيانات داللية نموذج ‪" SDM:‬أوصاف قاعدة البيانات باستخدام‬
‫هاريل ‪ ،‬د‪" .)1987( .‬مخططات الحالة‪ :‬شكليات بصرية لألنظمة المعقدة"‪ .‬علوم‪ .‬حاسوب‪ .‬البرمجة ‪ .74–231 ، )3( 8 ،‬هاريل ‪ ،‬د‪.‬‬
‫هال ‪ ،‬ر‪ .‬وكينغ ‪ ،‬ر‪ .)1987( .‬نمذجة قاعدة البيانات ‪" .)1988( ACM، 31 (5) ، 514-30.‬في الشكليات‪ W‬المرئية"‪ .‬باالتصاالت‬
‫جاكوبسون ‪ ،‬آي‪ ، .‬كريسترسون ‪ ،‬إم ‪ ACM ، 19 (3) ، 201-60. ،‬الداللية‪ :‬المسح والتطبيقات والبحث مشاكل'‪ .‬مسوحات‪ W‬الحوسبة‬
‫برنامج كائني التوجه هندسة‪ .‬ووكينغهام‪ :‬أديسون ويسلي‪ .‬كينت ‪ ،‬س‪ Overgaard ، G. (1993). .)2002( .‬جونسون ‪ ،‬بي‪ .‬و‬
‫‪. Kleppe، A.،‬كثافة العمليات‪ .‬أسيوط‪ .‬بشأن األساليب الرسمية المتكاملة ‪"rd 98-286 ،‬الهندسة التي تعتمد على النموذج"‪ .‬بروك‪3 .‬‬
‫النموذج القائم على العمارة ‪ -‬الممارسة‪ W‬والوعد‪ .‬بوسطن‪ :‬أديسون ويسلي‪ MDA: .‬شرح ‪Warmer، J. and Bast، W. (2003).‬‬
‫ميلور ‪ ،‬إس جيه وبالسير ‪ IEEE ، 11 (6) ، 42-50. ،‬كروشتن ‪ ،‬ص‪" .)1995( .‬نموذج العرض ‪ 1 + 4‬للهندسة المعمارية"‪ .‬برنامج‬
‫المقطر‪ . MDA :‬قابل للتنفيذ‪ .‬بوسطن‪ :‬أديسون ويسلي‪ .‬ميلور ‪ ،‬إس جيه ‪ ،‬سكوت ‪ ،‬ك‪.‬و وايز ‪ ،‬د‪. UML )2004( .‬إم جيه (‪)2002‬‬
‫مبادئ يحركها النموذج بنيان‪ .‬بوسطن‪ :‬أديسون ويسلي‪ .‬رامبو ‪ ،‬ج ‪ ،‬جاكوبسون ‪ ،‬آي وبوش ‪ ،‬جي (‪ .)1999‬مرجع لغة النمذجة‬
‫‪ Rumbaugh، J.، Jacobson، I. and Booch، G.‬الموحدة يدوي‪ .‬القراءة ‪ ،‬ماس‪ :‬أديسون ويسلي‪ .‬الفصل الخامس المراجع ‪145‬‬
‫الدليل المرجعي للغة النمذجة الموحدة ‪ ،‬الطبعة الثانية‪ .‬بوسطن‪ :‬أديسون ويسلي‪ .‬شميدت ‪ ،‬دي سي (‪" .)2006‬الهندسة ‪(2004).‬‬
‫تطوير البرمجيات القائمة على النماذج‪".IEEE Computer، 39 (2) ، 25-31. Stahl، T. and Voelter، M. (2006). :‬النموذجية‬
 ‫التكنولوجيا ‪ ،‬الهندسة ‪ ،‬إدارة‪ .‬نيويورك‪ :‬جون وايلي وأوالده‪ .‬وارد ‪ ،‬ص‪ .‬و ميلور ‪ ،‬س‪ .)1985( .‬التطوير المهيكل ألنظمة الوقت‬
‫الحقيقي‪ .‬إنجليوود كليفس نيوجيرسي‪ :‬برنتيس هول‪ 146 .‬الفصل الخامس نمذجة النظام التصميم المعماري‪ 6 W‬أهداف الهدف من هذا‬
‫الفصل هو تقديم مفاهيم البرمجيات العمارة والتصميم المعماري‪ .‬عندما تقرأ الفصل ‪ ،‬سوف تفعلها‪ :‬فهم سبب أهمية التصميم المعماري‪W‬‬
‫للبرنامج ؛ فهم القرارات التي يجب اتخاذها بشأن النظام العمارة أثناء عملية التصميم المعماري ؛ تم تقديم فكرة األنماط المعمارية ‪ ،‬تمت‬
‫تجربتها جي ًدا طرق تنظيم معماريات‪ W‬النظام ‪ ،‬والتي يمكن إعادة استخدامها فيها تصميمات النظام تعرف على األنماط المعمارية التي غالبا‬
‫ما تستخدم في أنواع مختلفة من نظام التطبيق ‪ ،‬بما في ذلك أنظمة معالجة المعامالت‪ W‬و أنظمة معالجة‪ W‬اللغة‪ .‬محتويات ‪ 6.1‬قرارات‬
‫التصميم المعماري ‪ 6.2‬المناظر المعمارية ‪ 6.3‬األنماط المعمارية‪ 6.4 W‬معماريات التطبيق ‪ 148‬الفصل السادس التصميم المعماري‬
‫يهتم التصميم المعماري بفهم كيف يجب أن يكون النظام تنظيم وتصميم الهيكل العام لهذا النظام‪ .‬في نموذج اللين عملية تطوير األدوات ‪،‬‬
‫كما هو موضح في الفصل ‪ ، 2‬التصميم المعماري هو األول المرحلة في عملية تصميم البرنامج‪ .‬إنه الرابط الحاسم بين التصميم و‬
‫المتطلبات الهندسية ‪ ،‬حيث تحدد المكونات الهيكلية الرئيسية في النظام والعالقات بينهم‪ .‬ناتج عملية التصميم المعماري هو نموذج‬
‫معماري يصف كيفية تنظيم النظام كمجموعة من االتصاالت مكونات لطيفة‪ .‬في العمليات الرشيقة ‪ ،‬من المقبول عمومًا أن تكون مرحلة‬
‫مبكرة من التطور يجب أن تهتم العملية بإنشاء بنية نظام شاملة‪ .‬التطوير التدريجي للهياكل ال يكون عادة ناجحً ا‪ .‬أثناء إعادة البناء‪ -‬عاد ًة‬
‫استجابة للتغييرات سهلة نسبيًا ‪ ،‬حيث يتم إعادة هيكلة نظام من المرجح أن تكون بنية‬ ‫ً‬ ‫المعمارية باهظة الثمن‪ tem .‬ما تكون المكونات‬
‫لمساعدتك على فهم ما أعنيه بهندسة النظام ‪ ،‬ضع في اعتبارك الشكل ‪ .6.1‬يُظهر هذا نموذجً ا تجريديًا للهندسة المعمارية لنظام روبوت‬
‫التعبئة يوضح المكونات التي يجب تطويرها‪ .‬يمكن لهذا النظام اآللي أن يحزم أنواع كثيرة من األشياء‪ .‬يستخدم مكون الرؤية الختيار‬
‫األشياء على ناقل ‪ ،‬تحديد نوع الكائن ‪ ،‬واختيار النوع المناسب من التعبئة والتغليف‪ .‬ثم النظام ينقل األشياء من ناقل التسليم ليتم تعبئتها‪.‬‬
‫يضع األشياء المعبأة على ناقل آخر‪ .‬يوضح النموذج المعماري‪ W‬هذه المكونات والروابط بينهم‪ .‬في الممارسة العملية ‪ ،‬هناك تداخل كبير‬
‫بين عمليات المتطلبات التصميم الهندسي والمعماري‪ .‬من الناحية المثالية ‪ ،‬ال ينبغي لمواصفات النظام تتضمن أي معلومات عن التصميم‪.‬‬
‫جدا‪ .‬عادة ما يكون التحلل المعماري‪ W‬ضروريًا لهيكلة المواصفات وتنظيمها‬ ‫لذلك ‪- ification. ،‬هذا غير واقعي باستثناء األنظمة الصغيرة ً‬
‫كجزء من عملية هندسة المتطلبات ‪ ،‬يمكنك دعم‪ -‬تشكل بنية نظام مجردة حيث تقوم بربط مجموعات من وظائف النظام أو ميزات ذات‬
‫مكونات واسعة النطاق أو أنظمة فرعية‪ .‬يمكنك بعد ذلك استخدام هذا التحلل لمناقشة متطلبات وميزات النظام مع االهتمام‪ -‬حوامل‪ .‬يمكنك‬
‫تصميم معماريات‪ W‬البرامج على مستويين من التجريد ‪ ،‬والتيأنا أتصل العمارة في الصغر والعمارة في الكبير‪ .1 :‬العمارة في الصغر تهتم‬
‫بهندسة المشاريع الفردية جرامات‪ .‬في هذا المستوى ‪ ،‬نحن مهتمون بالطريقة التي يقوم بها البرنامج الفردي تتحلل إلى مكونات‪ .‬هذا‬
‫الفصل يهتم في الغالب بالمحترفين‪ -‬معماريات غرام‪ . 2 .‬العمارة في العموم تهتم بهندسة المدخل المعقد‪ -‬أنظمة الجوائز التي تشمل أنظمة‬
‫يتم توزيع أنظمة المؤسسة هذه على أجهزة كمبيوتر مختلفة ‪ ،‬والتي قد تكون مملوكة ومدارة من ‪- nents.‬وبرامج أخرى وتكوين برامج‬
‫قبل شركات‪ W‬مختلفة‪ .‬أنا أغطي العمارة‪ -‬في الفصلين ‪ 18‬و ‪ ، 19‬حيث أناقش األنظمة الموزعة الفصل السادس‪ W‬التصميم المعماري ‪149‬‬
‫رؤية نظام هدف تعريف نظام ذراع مراقب القابض مراقب التعبئة والتغليف اختيار نظام التعبئة نظام ناقل مراقب الشكل ‪ 6.1‬هندسة‬
‫التعبئة نظام التحكم اآللي تعتبر بنية البرامج مهمة ألنها تؤثر على األداء والمتانة قابلية التوزيع والصيانة للنظام (بوش ‪ .)2000 ،‬كما‬
‫يناقش بوش ‪ ،‬تقوم المكونات الفردية بتنفيذ متطلبات النظام الوظيفية‪ .‬ثم على‪ -‬تعتمد المتطلبات الوظيفية على بنية النظام ‪ -‬الطريقة التي‬
‫ضا بالمكونات الفردية ‪ ،‬ولكن ليس‬ ‫يتم بها ذلك يتم تنظيم المكونات والتواصل‪ .‬في العديد من األنظمة ‪ ،‬غير وظيفية تتأثر المتطلبات أي ً‬
‫هناك شك أن بنية النظام هي التأثير المهيمن‪ .‬باس وآخرون‪ )2003( .‬ناقش ثالث مزايا لتصميم وتوثيق صراحة‪ -‬هندسة البرمجيات‬
‫جي‪ . 1 :‬التواصل مع أصحاب المصلحة الهيكل هو عرض تقديمي عالي المستوى للنظام‪ -‬يمكن استخدامه كمحور للمناقشة‪ W‬من قبل‬
‫مجموعة من أصحاب المصلحة المختلفين‪ . 2 .‬تحليل النظام جعل بنية النظام واضحة في مرحلة مبكرة في يتطلب تطوير النظام بعض‬
‫التحليل‪ .‬قرارات التصميم المعماري لها تأثير عميق على ما إذا كان النظام يمكنه تلبية المتطلبات الحرجة أم ال إشارات مثل األداء‬
‫والموثوقية وقابلية الصيانة‪ . 3 .‬إعادة االستخدام على نطاق واسع إن نموذج بنية النظام هو نموذج مضغوط ويمكن التحكم فيه وصف‬
‫كيفية تنظيم النظام وكيفية تفاعل المكونات‪ .‬غالبًا ما تكون بنية النظام هي نفسها بالنسبة لألنظمة ذات المتطلبات المماثلة وهكذا يمكن دعم‬
‫إعادة استخدام البرامج على نطاق واسع‪ .‬كما أشرح في الفصل ‪ ، 16‬قد يحدث ذلك يكون من الممكن تطوير معماريات‪ W‬خط اإلنتاج حيث‬
‫توجد نفس البنية يعاد استخدامها عبر مجموعة من األنظمة ذات الصلة‪ 150 .‬الفصل ‪ 6‬التصميم المعماري هوفميستر وآخرون‪( .‬‬
‫‪ )2000‬يقترح أن بنية البرنامج يمكن أن تعمل أوالً كملف خطة التصميم للتفاوض بشأن متطلبات النظام ‪ ،‬وثانيًا كوسيلة لـ تنظيم‬
‫المناقشات‪ W‬مع العمالء والمطورين والمديرين‪ .‬يقترحون أيضا أنها أداة أساسية إلدارة التعقيد‪ .‬يخفي التفاصيل ويسمح لـ المصممين‬
‫للتركيز على تجريدات النظام الرئيسية‪ .‬غالبًا ما يتم نمذجة معماريات‪ W‬النظام باستخدام مخططات كتلة بسيطة ‪ ،‬كما في الشكل ‪ .6.1‬يمثل‬
‫كل مربع في الرسم البياني مكو ًن ا‪ .‬تشير المربعات الموجودة داخل المربعات إلى أن ملف المكون قد تحلل إلى مكونات فرعية‪ .‬األسهم‬
‫من مكون إلى آخر في اتجاه األسهم‪ .‬أنت يمكن أن ترى العديد من األمثلة على هذا ‪ trol‬تعني تلك البيانات و ‪ /‬أو يتم تمرير إشارات‬
‫تقدم المخططات‪ W‬الكتل ‪ ture (Booch ، 2009).‬كتالوج ‪ Booch-‬النوع من النماذج المعمارية في هندسة البرمجيات الخاصة بشركة‬
‫صورة عالية المستوى لهيكل النظام ‪ ،‬والتي يقوم بها األشخاص من االختالفالتخصصات‪ ، W‬الذين يشاركون في عملية تطوير النظام ‪،‬‬
‫يمكنهم ذلك فهم بسهولة‪ .‬ومع ذلك ‪ ،‬على الرغم من استخدامها على نطاق واسع ‪ ،‬باس وآخرون‪ )2003( .‬ديس‪ -‬مثل المخططات‪ W‬غير‬
‫الرسمية لوصف العمارة‪ .‬يزعمون أن هؤالء المخططات غير الرسمية هي تمثيالت معمارية رديئة ‪ ،‬ألنها ال تظهر أيا من نوع العالقات‪W‬‬
 ‫بين مكونات النظام وال المكونات خارجيًا الخصائص المرئية‪ .‬تظهر التناقضات الواضحة بين الممارسة‪ W‬والنظرية المعمارية ألن هناك‬
‫طريقتين يتم من خاللهما استخدام النموذج المعماري للبرنامج‪ .1 :‬كطريقة لتسهيل المناقشة‪ W‬حول تصميم نظام عالي المستوى المنظر‬
‫المعماري لنظام مفيد للتواصل مع حصة النظام‪ -‬أصحاب وتخطيط المشروع ألنه ال تشوش بالتفاصيل‪ .‬حصة‪ -‬يمكن ألصحابها االرتباط‬
‫بها وفهم نظرة مجردة للنظام‪ .‬هم يمكن بعد ذلك مناقشة النظام ككل دون الخلط بينه وبين التفاصيل‪ .‬ال يحدد النموذج المعماري المكونات‬
‫الرئيسية التي سيتم تطويرها حتى يمكن للمديرين البدء في تعيين أشخاص للتخطيط لتطوير هذه األنظمة‪ .2 .‬كطريقة لتوثيق العمارة التي‬
‫تم تصميمها الهدف هنا هو إنتاج نموذج نظام كامل يُظهر المكونات المختلفة في نظام وواجهاتهم ووصالتهم‪ .‬حجة هذا هو أن مثل هذا‬
‫الوصف المعماري التفصيلي يسهل فهمه وتطويره النظام‪ .‬تعد المخططات‪ W‬الكتلية طريقة مناسبة لوصف بنية النظام خالل‪ -‬في عملية‬
‫التصميم ‪ ،‬ألنها طريقة جيدة لدعم االتصاالت بين األشخاص المشاركين في العملية‪ .‬في العديد من المشاريع ‪ ،‬غالبًا ما تكون هذه ملفات‬
‫فقط الوثائق المعمارية الموجودة‪ .‬ومع ذلك ‪ ،‬إذا كانت بنية النظام يتم توثيقها بدقة ‪ ،‬فمن األفضل استخدام تدوين محدد جي ًدا دالالت‬
‫للوصف المعماري‪ .‬ومع ذلك ‪ ،‬كما أناقش في القسم ‪ ، 6.2‬بعض يعتقد الناس أن التوثيق التفصيلي ليس مفي ًدا وال يستحق التكلفة ح ًقا ‪6.1‬‬
‫قرارات التصميم المعماري ‪ 6.1 151‬قرارات التصميم المعماري التصميم المعماري هو عملية إبداعية حيث تقوم بتصميم نظام تنظيم‬
‫من شأنها أن تفي بالمتطلبات الوظيفية وغير الوظيفية للنظام‪ .‬ألن إنها عملية إبداعية ‪ ،‬تعتمد األنشطة داخل العملية على نوع النظام قيد‬
‫التطوير ‪ ،‬وخلفية مهندس النظام وخبرته ‪ ،‬و المتطلبات المحددة للنظام‪ .‬لذلك من المفيد التفكير في الهندسة المعمارية التصميم كسلسلة من‬
‫القرارات التي يجب اتخاذها بدالً من سلسلة من األنشطة‪ .‬أثناء عملية التصميم المعماري ‪ ،‬يتعين على مهندسي النظام عمل رقم للقرارات‬
‫الهيكلية التي تؤثر بشكل كبير على النظام وتطوره عملية‪ .‬بنا ًء على معرفتهم وخبراتهم ‪ ،‬يتعين عليهم مراعاة ما يلي‪ :‬األسئلة األساسية‪W‬‬
‫حول النظام‪ . 1 :‬هل توجد بنية عامة للتطبيق يمكن أن تكون بمثابة نموذج للنظام‪ -‬تيم التي يجري تصميمها؟ ‪ .2‬كيف سيتم توزيع النظام‬
‫عبر عدد من النوى أو المعالجات؟ ‪ .3‬ما هي األنماط أو األنماط المعمارية التي يمكن استخدامها؟ ‪ .4‬ما هو النهج األساسي المستخدم‬
‫لهيكلة النظام؟ ‪ . 5‬كيف سيتم تحلل المكونات الهيكلية في النظام إلى فرعية عناصر؟ ‪ .6‬ما هي االستراتيجية التي سيتم استخدامها للتحكم‬
‫في تشغيل المكونات في النظام؟ ‪ . 7‬ما هو التنظيم المعماري األفضل لتقديم الوظائف غير الوظيفية أل تتطلب‪ -‬إشارات النظام؟ ‪ .8‬كيف‬
‫سيتم تقييم التصميم المعماري؟ ‪ . 9‬كيف يجب توثيق معمارية النظام؟ على الرغم من أن كل نظام برمجي فريد من نوعه ‪ ،‬إال أن األنظمة‬
‫في نفس التطبيق غالبًا ما يكون للمجال بنى متشابهة تعكس المفاهيم األساسية لـ اِختِصاص‪ .‬على سبيل المثال ‪ ،‬خطوط منتجات التطبيقات‬
‫هي تطبيقات مبنية حولها بنية أساسية مع متغيرات تلبي متطلبات العمالء المحددة‪ .‬متى عند تصميم بنية النظام ‪ ،‬عليك أن تقرر ما هو‬
‫نظامك وأوسع نطا ًق ا تشترك فصول التطبيق في األمر ‪ ،‬وتقرر مقدار المعرفة من هذه معماريات التطبيق التي يمكنك إعادة استخدامها‪.‬‬
‫أناقش معماريات التطبيقات العامة‪ W‬في القسم ‪ 6.4‬وخطوط منتجات التطبيق في الفصل ‪ .16‬بالنسبة لألنظمة واألنظمة المدمجة المصممة‪W‬‬
‫واحد ا فقط ولن تضطر إلى تصميم معماري موزع‪ -‬تلح للنظام‪ .‬ومع ذلك ‪ ،‬فإن‬ ‫ً‬ ‫ألجهزة الكمبيوتر الشخصية ‪ ،‬هناك عاد ًة ما يكون معالجً ا‬
‫معظم األنظمة الكبيرة هي اآلن أنظمة موزعة بتنسيق الذي يتم توزيع برنامج النظام عبر العديد من أجهزة الكمبيوتر المختلفة‪ .‬ال اختيار‬
‫هندسة التوزيع هو قرار رئيسي يؤثر على األداء و ‪ 152‬الفصل ‪ 6‬التصميم المعماري موثوقية النظام‪ .‬هذا موضوع رئيسي في حد ذاته‬
‫في الفصل ‪ . 18‬قد تعتمد بنية نظام برمجي على معمارية معينة نمط أو نمط‪ .‬النمط المعماري هو ‪- rately‬وأنا أغطيه بشكل منفصل‬
‫مثل مؤسسة خادم ‪ -‬عميل أو بنية ذات طبقات‪ .‬تلتقط األنماط المعمارية جوهر ‪ (Garlan and Shaw ، 1993) ،‬وصف لمؤسسة النظام‬
‫الهندسة المعمارية التي تم استخدامها في مختلف أنظمة برمجية قوية‪ .‬يجب أن تكون على دراية باألنماط الشائعة ‪ ،‬حيث يمكن أن تكون‬
‫المستخدمة ‪ ،‬ونقاط القوة والضعف عند اتخاذ القرارات بشأن المهندس المعماري‪ -‬تلح من النظام‪ .‬أناقش عد ًدا من األنماط المستخدمة‪W‬‬
‫بشكل متكرر في القسم ‪ . 6.3‬مفهوم جارالن وشو عن األسلوب المعماري (جاء األسلوب والنمط يعني نفس الشيء) يغطي األسئلة من ‪4‬‬
‫إلى ‪ 6‬في القائمة السابقة‪ .‬عليك ان تختار الهيكل األنسب ‪ ،‬مثل العميل ‪ -‬الخادم أو الهيكل متعدد الطبقات ‪ ،‬الذي سيفعل ذلك تمكنك من‬
‫تلبية متطلبات النظام‪ .‬لتحلل وحدات النظام اإلنشائي ‪ ،‬عليك أن تقرر استراتيجية تفكيك المكونات إلى مكونات فرعية‪ .‬ال األساليب التي‬
‫يمكنك استخدامها تسمح بتنفيذ أنواع مختلفة من الهندسة المعمارية‪ .‬أخيرً ا ‪ ،‬في عملية نمذجة التحكم ‪ ،‬يمكنك اتخاذ قرارات حول كيفية يتم‬
‫التحكم في المكونات‪ .‬تقوم بتطوير نموذج عام لعالقة التحكم‪ -‬الصالت بين مختلف أجزاء النظام‪ .‬بسبب العالقة الوثيقة بين المتطلبات‬
‫هندسة وير ‪ ،‬النمط المعماري الخاص والهيكل الذي تختاره يجب أن يعتمد النظام على متطلبات النظام غير ‪ soft-‬غير الوظيفية و‬
‫الوظيفية‪ .1 :‬األداء إذا كان األداء مطلبًا حاس ًما‪ ، W‬فينبغي للهندسة المعمارية أن تكون مصممة لتوطين العمليات الحرجة ضمن عدد صغير‬
‫مع نشر جميع هذه المكونات على نفس الكمبيوتر بدالً من موزعة عبر الشبكة‪ .‬قد يعني هذا استخدام عدد قليل ‪ ponents ،‬من الشركات‬
‫من الكومبيوترات الكبيرة نسبيًا المكونات بدالً من المكونات الصغيرة الدقيقة ‪ ،‬مما يقلل من عدد اتصاالت المكون‪ .‬يمكنك أيضً ا التفكير‬
‫في تنظيم نظام وقت التشغيل‪ -‬التي تسمح بتكرار النظام وتنفيذه على معالجات مختلفة‪ .2 .‬األمن إذا كان األمن مطلبًا حاس ًما‪ ، W‬فإن بنية‬
‫عال من التحقق‬ ‫الطبقات لـالعمارة‪ -‬يجب استخدام هذه األصول ‪ ،‬مع حماية األصول األكثر أهمية في الطبقة األعمق‪ ، -‬مع مستوى ٍ‬
‫األمني المطبق على هذه الطبقات‪ .3 .‬السالمة‪ W‬إذا كانت السالمة مطلبًا حاس ًم ا ‪ ،‬فيجب تصميم الهيكل على هذا النحو أن العمليات المتعلقة‬
‫بالسالمة تقع جميعها إما في مكون واحد أو في عدد قليل من المكونات‪ .‬هذا يقلل من تكاليف ومشاكل صمام األمان الهوية ويجعل من‬
‫الممكن توفير أنظمة الحماية ذات الصلة التي يمكن إغالق النظام بأمان في حالة حدوث عطل‪ .4 .‬التوافر إذا كان التوافر مطلبًا حاسمًا ‪،‬‬
‫فينبغي أن يكون التصميم كذلك مصممة‪ W‬لتشمل مكونات زائدة عن الحاجة بحيث يمكن استبدالها و تحديث المكونات دون إيقاف النظام‪.‬‬
‫أصف اثنين متسامحين مع الخطأ معماريات النظام ألنظمة التوافر العالي في الفصل ‪ .5 .13‬قابلية الصيانة إذا كانت قابلية الصيانة مطلبًا‬
 ‫بالغ األهمية ‪ ،‬فإن مهندس النظام‪ -‬يجب أن يتم تصميمه باستخدام مكونات دقيقة ومكتفية ذاتيًا قد ‪ 6.2‬المناظر المعمارية ‪ 153‬يمكن‬
‫تغييرها بسهولة‪ .‬يجب فصل منتجي البيانات عن المستهلكين و يجب تجنب هياكل البيانات المشتركة‪ .‬من الواضح أن هناك تعارضًا‬
‫محتمالً بين بعض هذه البنى‪ .‬ل على سبيل المثال ‪ ،‬يؤدي استخدام مكونات كبيرة إلى تحسين األداء واستخدام حبيبات صغيرة دقيقة‬
‫المكونات يحسن الصيانة‪ .‬إذا كان كل من األداء وقابلية الصيانة متطلبات النظام الهامة ‪ ،‬ثم يجب العثور على بعض الحلول الوسط‪ .‬هذا‬
‫يمكن يتم تحقيقه أحيا ًنا باستخدام أنماط أو أنماط معمارية‪ W‬مختلفة مختلفة أجزاء من النظام‪ .‬يعد تقييم التصميم المعماري أمرً ا صعبًا ألن‬
‫االختبار الحقيقي لمهندس معماري‪ -‬هذا هو مدى تلبية النظام لمتطلباته الوظيفية وغير الوظيفية عندما يكون قيد االستخدام‪ .‬ومع ذلك ‪،‬‬
‫يمكنك إجراء بعض التقييم من خالل مقارنة التصميم الخاص بك ضد البنى المرجعية أو األنماط المعمارية العامة‪ .‬بوش (‪ )2000‬يمكن‬
‫أيضً ا وصف الخصائص غير الوظيفية لألنماط المعمارية تستخدم للمساعدة في التقييم المعماري‪ 6.2 .‬المناظر المعمارية شرحت في‬
‫مقدمة هذا الفصل أن النماذج المعمارية للبرنامج يمكن استخدام النظام لتركيز المناقشة حول متطلبات البرنامج أو التصميم‪ .‬بدالً من ذلك ‪،‬‬
‫يمكن استخدامها لتوثيق التصميم بحيث يمكن استخدامه كأساس‪ W‬لمزيد من التصميم والتنفيذ التفصيلي ‪ ،‬وللتطور المستقبلي للنظام‪ -‬تيم‪ .‬في‬
‫هذا القسم ‪ ،‬أناقش مسألتين لهما صلة بكليهما‪ . 1 :‬ما هي وجهات النظر أو وجهات النظر المفيدة عند تصميم وتوثيق نظام‪ -‬الهندسة‬
‫المعمارية تيم؟ ‪ . 2‬ما هي الرموز التي يجب استخدامها لوصف النماذج المعمارية؟ من المستحيل تمثيل جميع المعلومات ذات الصلة حول‬
‫بنية النظام في نموذج معماري واحد ‪ ،‬حيث يُظهر كل نموذج وجهة نظر أو منظور واحد فقط لـ نظام‪ .‬قد يوضح كيف يتحلل النظام إلى‬
‫وحدات ‪ ،‬وكيف يتم تشغيله تتفاعل العمليات ‪ ،‬أو الطرق المختلفة التي يتم بها توزيع مكونات النظام عبر الشبكة‪ .‬كل هذه مفيدة في أوقات‬
‫مختلفة ‪ ،‬لذلك ‪ ،‬لكل من التصميم والوثيقة‪ -‬تحتاج عاد ًة إلى تقديم عروض متعددة لهندسة البرنامج‪ .‬هناك آراء مختلفة حول وجهات النظر‬
‫المطلوبة‪ .‬كروتشين (‪ ، )1995‬إن نموذج عرض ‪ 1 + 4‬المشهور لهندسة البرمجيات ‪ ،‬يقترح أنه يجب أن يكون هناك أن تكون أربعة‬
‫مناظر معمارية أساسية ‪ ،‬مرتبطة باستخدام حاالت االستخدام أو السيناريوهات‪ -‬دائرة الرقابة الداخلية‪ .‬اآلراء التي يقترحها هي‪.1 :‬‬
‫وجهة نظر منطقية تظهر اله التجريدات الرئيسية في النظام كأشياء‪ W‬أو فئات الكائن‪ .‬ينبغي أن يكون من الممكن ربط متطلبات النظام‬
‫بالكيانات في هذا الرأي المنطقي‪ )154( .‬الفصل السادس التصميم المعماري ‪ .2‬عرض العملية ‪ ،‬والذي يوضح كيف ‪ ،‬في وقت التشغيل‬
‫عمليات التمثيل‪ .‬هذا الرأي مفيد إلصدار أحكام حول غير‪ -‬خصائص النظام الوظيفية مثل األداء والتوافر‪ ، inter- .3 .‬يتكون النظام من‬
‫أي أنه يُظهر انهيار البرنامج إلى مكونات ينفذها ‪- opment ،‬وجهة نظر التطوير ‪ ،‬والتي توضح كيفية تحلل البرنامج من أجل التطوير‬
‫مطور واحد أو فريق تطوير‪ .‬هذا الرأي مفيد ل مديري البرامج والمبرمجين‪ .4 .‬عرض مادي ‪ ،‬يُظهر أجهزة النظام وكيفية تكوين‬
‫البرامج يتم توزيع الخانات عبر المعالجات في النظام‪ .‬هذا الرأي مفيد ل مهندسو النظم يخططون لنشر النظام‪ .‬هوفميستر وآخرون‪( .‬‬
‫‪ )2000‬يقترح استخدام وجهات‪ W‬نظر مماثلة ولكن أضف إلى هذا المفهوم من وجهة نظر مفاهيمية‪ .‬هذا الرأي هو نظرة مجردة للنظام‬
‫يمكن أن يكون األساس لتحليل المتطلبات عالية المستوى إلى مواصفات أكثر تفصيالً ‪ ،‬مساعدة يتخذ المهندسون قرارات بشأن المكونات‬
‫التي يمكن إعادة استخدامها وتمثيلها خط إنتاج (تمت مناقشته‪ W‬في الفصل ‪ )16‬بدالً من نظام واحد‪ .‬الشكل ‪ ، 6.1‬الذي يصف بنية روبوت‬
‫التعبئة ‪ ،‬هو مثال على المفهوم عرض النظام‪ .‬من الناحية العملية ‪ ،‬يتم دائ ًم ا تطوير وجهات النظر المفاهيمية أثناء التصميم عملية‬
‫وتستخدم لدعم اتخاذ القرارات المعمارية‪ .‬هم وسيلة ل توصيل جوهر النظام إلى مختلف أصحاب المصلحة‪ .‬أثناء التصميم عملية ‪ ،‬بعض‬
‫وجهات النظر األخرى يمكن أيضا تطويرها عند جوانب مختلفة من تمت مناقشة النظام ‪ ،‬ولكن ليست هناك حاجة إلى وصف كامل من‬
‫ضا ربط األنماط المعمارية التي تمت مناقشتها‪ W‬في القسم التالي ‪ ،‬مع وجهات النظر المختلفة للنظام‪.‬‬ ‫الجميع أطياف‪ .‬قد يكون من الممكن أي ً‬
‫‪ (Clements، et al.، 2002).‬للوصف المعماري ‪ UML‬هناك آراء مختلفة حول ما إذا كان ينبغي لمهندسي البرمجيات‪ W‬استخدامها أم ال‬
‫تم تطبيقه في الغالب في بطريقة فضفاضة وغير رسمية‪ .‬جادل ‪ UML ،‬أنه عند استخدام )‪ (Lange et al. ، 2006‬مسح في عام ‪2006‬‬
‫لوصف وجوه المنحى األنظمة ‪ ،‬وفي مرحلة التصميم ‪ UML‬مؤلفو تلك الورقة أن هذا كان شيًئ ا سيًئ ا‪ .‬أنا ال أتفق مع هذا الرأي‪ .‬تم تصميم‬
‫جدا من التنفيذ مفيد للوصف المعماري‪ .‬ال‬ ‫المعماري ‪ ،‬غالبًا ما تريد وصف األنظمة في مستوى أعلى من التجريد‪ .‬فئات الكائنات قريبة ً‬
‫التي تكون أسرع في الكتابة والتي يمكن رسمها بسهولة ‪ mal‬مفيدة أثناء عملية التصميم نفسها وأفضل المعلومات تدوينات ‪ UML‬أجد أن‬
‫ذا قيمة كبيرة عندما تقوم بتوثيق معمارية بتنسيق التفصيل أو استخدام التطوير المستند إلى النموذج ‪ UML ،‬على األبيض‪ -‬سبورة‪ .‬يكون‬
‫صا لغات الوصف‬ ‫باس ( )‪ (ADL‬كما تمت مناقشته في الفصل الخامس‪ .‬اقترح عدد من الباحثين استخدام هندسة معمارية أكثر تخص ً‬
‫هي المكونات والموصالت ‪ ،‬وهي تشمل القواعد وإرشادات ‪ ADLs‬لوصف معماريات النظام‪ .‬العناصر األساسية‪ W‬لـ )وآخرون ‪2003 ،‬‬
‫‪ ADLs.‬للبنى جيدة التشكيل‪ .‬ومع ذلك ‪ ،‬بسبب تخصصهم يجد المتخصصون في الطبيعة والمجاالت والتطبيقات صعوبة في فهم واستخدام‬
‫المصممة لمجال معين (مثل أنظمة السيارات) ‪ ADLs‬هذا يجعل من الصعب تقييم فائدتها في هندسة البرمجيات‪ W‬العملية‪ .‬يمكن استخدام‬
‫‪ UML ،‬المعمارية ‪ 155‬أساسللتطوير الذي يحركه النموذج‪ .‬ومع ذلك ‪ ،‬أعتقد أن النماذج غير الرسمية و الرموز ‪ ،‬مثل ‪ a6.3‬كنماذج‬
‫معماريات نظام التوجيه‪ .‬يدعي مستخدمو األساليب الرشيقة أن وثائق التصميم التفصيلية هي في ‪ docu-‬ستظل أكثر الطرق شيوعًا في‬
‫الغالب غير مستعمل‪ .‬وبالتالي ‪ ،‬فإن تطويره مضيعة للوقت والمال‪ .‬أنا أتفق مع هذا الرأي وأعتقد أنه ‪ ،‬بالنسبة لمعظم األنظمة ‪ ،‬ال‬
‫يستحق وضع تفاصيل وصف معماري من وجهات النظر األربعة‪ .‬يجب عليك تطوير وجهات النظر مفيدة للتواصل وال تقلق بشأن ما إذا‬
‫كاملة‪ .‬ومع ذلك ‪ ،‬هناك استثناء لهذا عندما تكون كذلك تطوير األنظمة الحرجة ‪ ،‬عندما تحتاج إلى ‪ tural‬كان مهندسك المعماري‪ -‬وثائق‬
‫للنظام‪ .‬قد تحتاج إلى إقناع المنظمين الخارجيين بأن نظامك يتوافق مع لوائحهم وبالتالي قد تكون ‪- sis‬إجراء تحليل مفصل للوثوقية‬
 ‫التوثيق المعماري الكامل مطلوب‪ 6.3 .‬األنماط المعمارية‪ W‬فكرة األنماط كطريقة لتقديم ومشاركة وإعادة استخدام المعرفة حول تستخدم‬
‫أنظمة البرمجيات اآلن على نطاق واسع‪ .‬كان الدافع وراء ذلك هو نشر ملف كتاب عن أنماط التصميم الموجه للكائنات (جاما وآخرون ‪،‬‬
‫‪ ، ) 1995‬والذي دفع تطوير أنواع أخرى من األنماط ‪ ،‬مثل أنماط التصميم التنظيمي (كوبلين وهاريسون ‪ ، )2004 ،‬أنماط قابلية‬
‫‪ (Berczuk and‬إدارة التكوين ‪ (Martin and Sommerville ، 2004) ،‬االستخدام (مجموعة قابلية االستخدام ‪ ، )1998 ،‬التفاعل‬
‫الوصف يفصل العرض والتفاعل عن بيانات النظام‪ .‬النظام منظم إلى ثالثة مكونات منطقية )‪ MVC (Model-View-Controller‬االسم‬
‫تتفاعل مع بعضها البعض‪ .‬عنصر النموذج يدير بيانات النظام والعمليات المرتبطة بها على تلك البيانات‪ .‬يع ّرف مكون العرض و يدير‬
‫كيفية تقديم البيانات للمستخدم‪ .‬عنصر تحكم يدير المستخدم التفاعل (على سبيل المثال ‪ ،‬الضغط على المفاتيح ونقرات الماوس وما إلى‬
‫ذلك) ويمرر هذه التفاعالت إلى العرض والنموذج‪ .‬انظر الشكل ‪ .6.3‬مثال يوضح الشكل ‪ 6.4‬بنية نظام تطبيق قائم على الويب منظم‬
‫عند استخدامها ‪ ،‬يتم استخدامها عند وجود طرق متعددة لعرض البيانات والتفاعل معها‪ .‬تستخدم أيضً ا عندما يكون ‪ MVC.‬باستخدام نمط‬
‫ملف المتطلبات المستقبلية للتفاعل وعرض البيانات غير معروفة‪ .‬المزايا يسمح للبيانات بالتغير بشكل مستقل عن تمثيلها والعكس صحيح‪.‬‬
‫ً‬
‫تعقيدا‬ ‫يدعم عرض نفس البيانات بطرق مختلفة مع التغييرات التي أجريت في تمثيل واحد يظهر في كل منهم‪ .‬العيوب يمكن أن تتضمن‬
‫إضافيًا في التعليمات‪ W‬البرمجية والتعليمات البرمجية عند نموذج البيانات والتفاعالت بسيطة‪ .‬الشكل ‪ 6.2‬النموذج‪ -‬وحدة التحكم في الرؤية‬
‫وما إلى ذلك‪ .‬تم اقتراح األنماط المعمارية في التسعينيات تحت اسم ‪) ،‬نمط ‪ 156‬الفصل ‪ 6‬التصميم المعماري أبليتون ‪(MVC) 2002 ،‬‬
‫مع سلسلة من خمسة مجلدات من كتيبات حول بنية البرامج الموجهة لألنماط ‪"" (Shaw and Garlan ، 1996) ،‬األنماط المعمارية‬
‫‪ Buschmann et al.،‬؛‪ Buschmann et al.، 2007a‬؛‪ (Buschmann et al.، 1996‬المنشورة بين عامي ‪ 1996‬و ‪2007‬‬
‫أنماطا معمارية وأشرح بإيجاز مجموعة مختارة من ‪).‬؛ كيرشر وجاين ‪ 2004 ،‬؛ شميت وآخرون ‪2007b2000 ،‬‬ ‫ً‬ ‫في هذا القسم ‪ ،‬أقدم‬
‫األنماط المعمارية التي يشيع استخدامها في أنواع مختلفة من األنظمة‪ .‬ل مزيد من المعلومات حول األنماط واستخدامها ‪ ،‬يجب عليك‬
‫الرجوع إلى األنماط المنشورة الكتيبات‪ .‬يمكنك التفكير في النمط المعماري باعتباره وص ًفا تجريديًا منم ًقا للخير الممارسة التي تم تجربتها‬
‫واختبارها في أنظمة وبيئات مختلفة‪ .‬لذا‪ ،‬يجب أن يصف النمط المعماريمنظمة نظام كانت ناجحة‪ -‬فول في األنظمة السابقة‪ .‬يجب أن‬
‫تتضمن معلومات عن الوقت المناسب وغير المناسب‪ .‬استخدام هذا النمط ونقاط القوة والضعف فيه‪ .‬على سبيل المثال ‪ ،‬يصف الشكل‬
‫هذا النمط هو أساس إدارة التفاعل في العديد من األنظمة المستندة إلى ‪ 6.2 Model-View-Controller.‬النمط المعروف ً‬
‫جيدا في‬
‫موجزا (مع ملحق نموذج رسومي مرتبط) ‪ ،‬ومثال على نوع النظام الذي‬ ‫ً‬ ‫الويب‪ .‬ال يتضمن وصف النمط منمنمة اسم النمط ووص ًفا‬
‫يوجد به النمط يستخدم (مرة أخرى ‪ ،‬ربما مع نموذج رسومي)‪ .‬يجب عليك أيضا تضمين المعلومات حول متى يجب استخدام النمط‬
‫في الشكالن ‪ 6.3‬و ‪ .6.4‬تعرض هذه الهندسة ‪ MVC‬ومزاياه وعيوبه‪ .‬تظهر النماذج الرسومية للهندسة المعمارية‪ W‬المرتبطة بنمط‬
‫المعمارية من وجهات نظر مختلفة ‪ -‬الشكل ‪ 6.3‬هو عرض مفاهيمي ويوضح الشكل ‪ 6.4‬معمارية وقت تشغيل محتملة عند ذلك يستخدم‬
‫النمط إلدارة التفاعل في نظام قائم على الويب‪ .‬في قسم قصير من فصل عام ‪ ،‬من المستحيل وصف جميع ملفات األنماط العامة التي‬
‫يمكن استخدامها في تطوير البرمجيات‪ .‬بدال من ذلك ‪ ،‬أقدم بعض أمثلة مختارة من األنماط المستخدمة على نطاق واسع والتي تجسد‬
‫على صفحات الويب ‪ tural‬العمارة الجيدة‪ -‬مبادئ التصميم التربيعي‪ .‬لقد قمت بتضمين بعض األمثلة األخرى على العمارة العامة‪ -‬أنماط‬
‫للكتاب‪ .‬عرض المراقب المالي نموذج منظر اختيار والية يتغير يتغير إشعار والية استفسار أحداث المستخدم إجراءات مستخدم الخرائط‬
‫لنموذج التحديثات يختار طريقة العرض يجسد النموذج يطلب تحديثات النموذج يرسل أحداث المستخدم‪ W‬إلى مراقب يغلف التطبيق والية‬
‫األنماط المعمارية ‪ 157‬المستعرض مراقب شكل إلى عرض تحديث ‪ MVC6.3‬يخطر وجهة نظر الدولة التغييرات الشكل ‪ 6.3‬تنظيم‬
‫منطق خاص بالتطبيق تأكيد صحة البيانات صفحة ديناميكية جيل ‪ HTTP‬طلب يتغير إشعار ينعش طلب أحداث المستخدم معالجة طلب‬
‫العمارة متعددة ‪ MVC 6.3.1‬إدارة النماذج منطق األعمال قاعدة البيانات منظر نموذج الشكل ‪ 6.4‬الويب هندسة التطبيق باستخدام نمط‬
‫الموضح في الشكل ‪ MVC ،‬الطبقات تعتبر مفاهيم الفصل واالستقالل أساسية للتصميم المعماري ألنها تسمح بترجمة التغييرات‪ .‬نمط‬
‫إضافة طريقة عرض جديدة أو تغيير ‪ ، 6.2- ple ،‬يفصل بين عناصر النظام ‪ ،‬مما يسمح لهم بالتغيير بشكل مستقل‪ .‬من أجل اإلختبار‬
‫طريقة عرض موجودة يمكن أن يتم دون أي التغييرات على البيانات األساسية في النموذج‪ .‬نمط العمارة متعدد الطبقات هو طريقة أخرى‬
‫لتحقيق االنفصال واالستقالل‪ .‬يظهر هذا النمط في الشكل ‪ . 6.5‬هنا ‪ ،‬يتم تنظيم وظائف النظام في طبقات منفصلة ‪ ،‬ولكل منها تعتمد‬
‫الطبقة فقط على المرافق والخدمات التي تقدمها الطبقة على الفور تحتها‪ .‬يدعم هذا النهج متعدد الطبقات التطوير التدريجي لألنظمة‪ .‬ك تم‬
‫تطوير الطبقة ‪ ،‬يمكن االستفادة من بعض الخدمات التي توفرها تلك الطبقة‪ -‬قادرة على المستخدمين‪ .‬الهندسة أي ً‬
‫ضا قابلة للتغيير‬
‫والمحمولة‪ .‬طالما أن بين الوجه لم يتغير ‪ ،‬يمكن استبدال طبقة بطبقة أخرى مكافئة‪ .‬باإلضافة إلى‪ ،‬عندما تتغير واجهات الطبقة أو تضاف‬
‫مرافق جديدة إلى طبقة ‪ ،‬فقط المجاورة طبقة تتأثر‪ .‬نظرً ا ألن األنظمة ذات الطبقات توضع تبعيات اآللة في الطبقات الداخلية ‪ ،‬هذا يجعل‬
‫من السهل توفير تطبيقات متعددة المنصات لنظام التطبيق‪ -‬تيم‪ .‬فقط الطبقات الداخلية المعتمدة على اآللة هي التي تحتاج إلى إعادة تنفيذ‬
‫حساب‪ W‬لمنشآت نظام تشغيل أو قاعدة بيانات مختلفة‪ .‬الشكل ‪ 6.6‬مثال على الطبقاتالعمارة بأربع طبقات‪ .‬األخفض تتضمن الطبقة برنامج‬
‫دعم النظام — عاد ًة قاعدة البيانات ونظام التشغيل يدعم‪ .‬الطبقة التالية هي طبقة التطبيق التي تتضمن المكونات تهتم بوظائف التطبيق‬
‫ومكونات األداة المساعدة المستخدمة بواسطة مكونات التطبيق األخرى‪ .‬الطبقة الثالثة تختص بواجهة المستخدم‪ 158 W‬الفصل السادس‬
‫التصميم المعماري الشكل ‪ 6.5‬الطبقات نمط العمارة واجهة المستخدم منطق األعمال األساسي ‪ /‬وظائف التطبيق نظام المرافق دعم‬
 ‫النظام (نظام التشغيل ‪ ،‬قاعدة البيانات ‪ ،‬إلخ‪ ).‬إدارة واجهة المستخدم المصادقة‪ W‬والتخويل الشكل ‪ 6.6‬عام العمارة الطبقية اإلدارة وتوفير‬
‫مصادقة‪ W‬المستخدم والترخيص ‪ ،‬مع الطبقة العليا توفير تسهيالت واجهة المستخدم‪ .‬بالطبع ‪ ،‬عدد الطبقات تعسفي‪ .‬أي من الطبقات في‬
‫الشكل ‪ 6.6‬يمكن تقسيمها إلى طبقتين أو أكثر‪ .‬الشكل ‪ 6.7‬هو مثال على كيفية تطبيق نمط العمارة الطبقي هذا على أ نظام مكتبة يسمى‬
‫والذي يسمح بالوصول اإللكتروني إلى حقوق النشر مادة من مجموعة مكتبات جامعية‪ .‬هذا له بنية من خمس طبقات ‪ ،‬مع ‪LIBSYS ،‬‬
‫الطبقة السفلية هي قواعد البيانات الفردية في كل مكتبة‪ .‬يمكنك رؤية مثال آخر لنمط العمارة متعدد الطبقات في الشكل ‪( 6.17‬وجد في‬
‫التي ناقشتها‪ W‬في الفصول السابقة‪ .‬اسم العمارة ذات )‪ (MHC-PMS‬القسم ‪ .)6.4‬هذا يدل على تنظيم نظام الصحة النفسية‪ -‬الرعاية‬
‫الطبقات الوصف ينظم النظام في طبقات ذات وظائف مرتبطة بكل طبقة‪ .‬توفر الطبقة خدمات للطبقة التي فوقها بحيث تمثل الطبقات ذات‬
‫المستوى األدنى النواة الخدمات‪ W‬التي يحتمل استخدامها في جميع أنحاء النظام‪ .‬انظر الشكل ‪ .6.6‬مثال نموذج متعدد الطبقات لنظام‬
‫لمشاركة وثائق حقوق النشر المحفوظة في مكتبات مختلفة ‪ ،‬مثل هو مبين في الشكل ‪ .6.7‬عند استخدامها تستخدم عند بناء مرافق جديدة‬
‫فوق األنظمة الحالية ؛ عندما يكون التطور تنتشر عبر عدة فرق مع مسؤولية كل فريق عن طبقة من الوظائف ؛ متى هناك مطلب لألمان‬
‫متعدد المستويات‪ .‬المزايا يسمح باستبدال الطبقات بأكملها طالما تم الحفاظ على الواجهة‪ .‬متكرر يمكن توفير التسهيالت (مثل المصادقة)‬
‫في كل طبقة لزيادة االعتمادية النظام‪ .‬العيوب من الناحية العملية ‪ ،‬غالبًا ما يكون توفير فصل نظيف بين الطبقات صعبًا وعالي المستوى‬
‫قد تضطر الطبقة إلى التفاعل مباشرة مع الطبقات ذات المستوى األدنى بدالً من التفاعل من خالل الطبقة تحته مباشرة‪ .‬يمكن أن يكون‬
‫األداء مشكلة بسبب المستويات المتعددة من تفسير طلب خدمة أثناء معالجته في كل طبقة ‪ 6.3‬األنماط المعمارية ‪ 159‬واجهة متصفح‬
‫تسجيل الدخول أشكال و ‪ DB1 DB2 DB3 DB4 DBn LIBSYS‬الويب فهرس المكتبة وزعت يبحث وثيقة استرجاع حقوق مدير محاسبة‬
‫‪ MVC‬بنية المستودع الهندسة المعمارية الطبقية وأنماط ‪ LIBSYS 6.3.2‬مدير االستعالم مطبعة مدير الشكل ‪ 6.7‬الهندسة المعمارية نظام‬
‫هي أمثلة على األنماط حيث العرض المقدمة هي التنظيم المفاهيمي للنظام‪ .‬المثال التالي ‪ ،‬ملف يصف نمط المستودع (الشكل ‪ )6.8‬كيف‬
‫يمكن لمجموعة من المكونات المتفاعلة مشاركة البيانات‪ .‬يتم تنظيم غالبية األنظمة التي تستخدم كميات‪ W‬كبيرة من البيانات حول ملف‬
‫قاعدة بيانات مشتركة أو مستودع‪ .‬ولذلك فإن هذا النموذج مناسب للتطبيقات التي مستودع االسم الوصف تتم إدارة جميع البيانات في‬
‫النظام في مستودع مركزي يمكن الوصول إليه من قبل كل النظام عناصر‪ .‬المكونات ال تفعلر تتفاعل مباشرة ‪ ،‬فقط من خالل المستودع‪.‬‬
‫حيث تستخدم المكونات مستودع معلومات‪ W‬تصميم النظام‪ .‬كل أداة برمجية تولد المعلومات التي ثم ‪ IDE‬مثال الشكل ‪ 6.9‬هو مثال على‬
‫متاح لالستخدام بواسطة أدوات أخرى‪ .‬عند االستخدام ‪ ،‬يجب استخدام هذا النمط عندما يكون لديك نظام به أحجام كبيرة من يتم إنشاء‬
‫ض ا استخدامه في األنظمة التي تعتمد على البيانات حيث يؤدي تضمين البيانات في‬ ‫المعلومات التي يجب تخزينها لفترة طويلة‪ .‬يمكنك أي ً‬
‫المستودع إلى تشغيل إجراء أو أداة‪ .‬المزايا يمكن أن تكون المكونات مستقلة ‪ -‬فهي ال تحتاج إلى معرفة وجود اآلخر عناصر‪ .‬يمكن نشر‬
‫التغييرات التي تم إجراؤها بواسطة مكون واحد على جميع المكونات‪ .‬الجميع يمكن إدارة البيانات بشكل متسق (على سبيل المثال ‪ ،‬النسخ‬
‫االحتياطية التي يتم إجراؤها في نفس الوقت) ألنها كلها في جهاز واحد مكان‪ .‬العيوب يعتبر المستودع نقطة فشل واحدة لذا فإن المشاكل‬
‫الموجودة في المستودع تؤثر على الكل نظام‪ .‬قد يكون هناك قصور في تنظيم جميع االتصاالت من خالل المستودع‪ .‬قد يكون توزيع‬
‫المستودع عبر العديد من أجهزة الكمبيوتر أمرً ا صعبًا‪ .‬الشكل ‪ 6.8‬نموذج المستودع ‪ 160‬الفصل ‪ 6‬التصميم المعماري مشروع مخزن‬
‫المحررين شفرة مولدات كهرباء تصميم محلل تقرير مولد كهرباء جافا محرر بايثون محرر الشكل ‪ 6.9‬مستودع ‪ UML‬تصميم مترجم‬
‫يتم إنشاء البيانات من قبل أحد المكونات واستخدامها من قبل آخر‪ .‬أمثلة على هذا النوع من ملفات يشمل النظام ‪ IDE‬هندسة معمارية لـ‬
‫وبيئات التطوير التفاعلية للبرامج‪ .‬الشكل ‪ 6.9‬هو توضيح لحالة يمكن ‪ CAD‬أنظمة القيادة والتحكم وأنظمة المعلومات اإلدارية ‪ ،‬أنظمة‬
‫الذي يتضمن أدوات مختلفة لدعم النموذج القائم تطوير‪ .‬قد يكون المستودع في هذه ‪ IDE‬فيها استخدام المستودع‪ .‬يوضح هذا الرسم البياني‬
‫الحالة بيئة يتحكم فيها اإلصدار (كما تمت مناقشته في الفصل ‪ ) 25‬الذي يتتبع التغييرات التي تطرأ على البرامج ويسمح بالتدوير‪ -‬العودة‬
‫إلى اإلصدارات السابقة‪ .‬يعد تنظيم األدوات حول المستودع طريقة فعالة لمشاركة كميات‪ W‬كبيرة من ملفات بيانات‪ .‬ليست هناك حاجة لنقل‬
‫البيانات بشكل صريح من مكون إلى آخر‪ .‬ومع ذلك ‪ ،‬يجب أن تعمل المكونات حول نموذج بيانات المستودع المتفق عليه‪ .‬ال محالة ‪ ،‬هذا‬
‫هو حل وسط بين االحتياجات المحددة لكل أداة ويمكن يكون من الصعب أو المستحيل دمج المكونات الجديدة إذا كانت نماذج البيانات‬
‫الخاصة بهم غير مناسبة المخطط المتفق عليه‪ .‬في الممارسة العملية ‪ ،‬قد يكون من الصعب توزيع المستودع على أ عدد اآلالت‪ .‬على‬
‫الرغم من أنه من الممكن توزيع مركزي منطقي المستودع ‪ ،‬قد تكون هناك مشاكل مع تكرار البيانات وعدم تناسقها‪ .‬في المثال الموضح‬
‫في الشكل ‪ ، 6.9‬يكون المستودع سلبيًا والتحكم هو مسؤولية المكونات التي تستخدم المستودع‪ .‬نهج بديل ‪ ،‬الذي تم اشتقاقه ألنظمة الذكاء‬
‫االصطناعي ‪ ،‬يستخدم نموذج "السبورة" الذي يؤدي إلى تشغيل المؤلفات عند توفر بيانات معينة‪ .‬هذا مناسب عندما يكون شكل بيانات‬
‫‪ Nii‬المستودع أقل تنظيما ً‪ .‬يمكن اتخاذ قرارات حول األداة التي يجب تفعيلها فقط عندما يتم تحليل البيانات‪ .‬تم تقديم هذا النموذج بواسطة‬
‫مناقشة جيدة لكيفية ارتباط هذا النمط بالنظام عالمات الجودة‪ 6.3.3 .‬هندسة العميل والخادم يهتم نمط )‪ Bosch (2000‬يتضمن ‪(1986).‬‬
‫جدا تنظيم وقت التشغيل‬‫المستودع بالبنية الثابتة للنظام وال يفعل ذلك تظهر تنظيم وقت التشغيل‪ .‬يوضح المثال التالي استخدامًا شائعًا ً‬
‫لألنظمة الموزعة‪ .‬يتم وصف نمط العميل ‪ -‬الخادم في الشكل ‪ 6.10.6.3‬األنماط المعمارية ‪ 161‬نظام يتبعيتم تنظيم نمط العميل ‪-‬‬
‫الخادم كمجموعة من الخدمات والخوادم المرتبطة والعمالء الذين يصلون إلى الخدمات ويستخدمونها‪ .‬الرئيسية كوم‪ -‬مؤلفات هذا النموذج‬
‫هي‪ .1 :‬مجموعة من الخوادم التي تقدم خدمات‪ W‬لمكونات أخرى‪ .‬أمثلة على الخوادم تشمل خوادم الطباعة التي تقدم خدمات‪ W‬الطباعة ‪،‬‬
‫وخادم تجميع يوفر لغة برمجة خدمات‪ W‬الترجمة‪ .2 .‬مجموعة من العمالء الذين ‪- agement‬وخوادم الملفات التي توفر إدارة الملفات‬
‫يطلبون الخدمات التي تقدمها الخوادم‪ .‬سوف يكون هناك عادة تكون عدة حاالت لبرنامج عميل يتم تنفيذه بشكل متزامن على مختلف‬
‫أجهزة الكمبيوتر‪ .3 .‬شبكة تتيح للعمالء الوصول إلى هذه الخدمات‪ .‬معظم العمالء‪ - W‬الخادم يتم تنفيذ األنظمة كنظم موزعة متصلة‬
‫باستخدام اإلنترنت البروتوكوالت‪ .‬عاد ًة ما يُنظر إلى معماريات‪ W‬الخادم والعميل على أنها مهندس أنظمة موزعة‪ -‬ولكن يمكن للنموذج‬
‫المنطقي للخدمات‪ W‬المستقلة التي تعمل على خوادم منفصلة يتم تنفيذها على جهاز كمبيوتر واحد‪ .‬مرة أخرى ‪ ،‬فائدة مهمة‪ W‬هي االنفصال و‬
‫استقالل‪ .‬يمكن تغيير الخدمات‪ W‬والخوادم دون التأثير على أجزاء أخرى من النظام‪ .‬قد يتعين على العمالء‪ W‬معرفة أسماء الخوادم المتاحة‬
‫والخدمات التي انهم يقدموا‪ .‬ومع ذلك ‪ ،‬ال تحتاج الخوادم إلى معرفة هوية العمالء‪ W‬أو كيفية القيام بذلك العديد من العمالء يصلون إلى‬
‫خدماتهم‪ .‬يصل العمالء‪ W‬إلى الخدمات‪ W‬التي يقدمها أ الخادم من خالل استدعاءات اإلجراءات عن بُعد باستخدام بروتوكول الطلب والرد مثل‬
‫اسم العميل ‪ -‬الخادم الوصف في بنية العميل والخادم ‪ ،‬يتم تنظيم وظائف النظام في خدمات ‪ ،‬مع كل خدمة يتم تسليمها من خادم ‪http‬‬
‫منفصل‪ .‬العمالء هم مستخدمو هذه الخدمات‪ W‬و الوصول إلى الخوادم لالستفادة منها‪ .‬مثال الشكل ‪ 6.11‬هو مثال لمكتبة أفالم ومكتبة فيديو‬
‫منظمة كخادم عميل نظام‪ .‬عند استخدامها تستخدم عندما يتعين الوصول إلى البيانات الموجودة في قاعدة بيانات مشتركة من ‪/ DVD‬‬
‫مجموعة من المواقع‪ .‬نظرً ا ألنه يمكن نسخ الخوادم ‪ ،‬يمكن أيضً ا استخدامها عند التحميل على النظام عامل‪ .‬المزايا الميزة الرئيسية لهذا‬
‫النموذج هي أنه يمكن توزيع الخوادم عبر الشبكة‪ .‬يمكن أن تكون الوظائف العامة (على سبيل المثال ‪ ،‬خدمة الطباعة) متاحة لجميع‬
‫العمالء ولكنها ال تتوفر تحتاج إلى تنفيذها من قبل جميع الخدمات‪ .‬العيوب كل خدمة هي نقطة فشل واحدة بحيث تكون عرضة لرفض‬
‫هجمات الخدمة أو فشل الخادم‪ .‬قد يكون األداء غير متوقع ألنه يعتمد على الشبكة فضال عن النظام‪ .‬قد تكون مشاكل اإلدارة إذا كانت‬
‫الخوادم مملوكة من قبل مختلف المنظمات‪ .‬الشكل ‪ 6.10‬العميل ‪ -‬الخادم نمط ‪ 162‬الفصل ‪ 6‬التصميم المعماري فهرس الخادم مكتبة‬
‫فهرس فيديو الخادم متجر األفالم صورة الخادم متجر الصور الويب الخادم فيلم و معلومات الصورة‪ .‬العميل ‪ 1‬العميل ‪ 2‬العميل ‪3‬‬
‫بشكل أساسي ‪ ،‬يقوم العميل بتقديم ‪ WWW.‬العميل ‪ 4‬إنترنت الشكل ‪ 6.11‬عميل ‪ -‬بنية الخادم لمكتبة أفالم البروتوكول المستخدم‪ W‬في‬
‫طلب إلى الخادم و ينتظر حتى يتلقى الرد‪ .‬الشكل ‪ 6.11‬هو مثال على نظام يعتمد على نموذج العميل والخادم‪ .‬هذا هو نظام قائم على‬
‫الويب متعدد المستخدمين لتوفير مكتبة أفالم وصور‪ .‬في هذا النظام ‪ ،‬تقوم عدة خوادم بإدارة وعرض أنواع مختلفة من الوسائط‪ .‬إطارات‬
‫ً‬
‫مضغوطا في متجر ‪ ،‬بحيث يمكن لخادم الفيديو‬ ‫الفيديو يجب إرسالها بسرعة وبشكل متزامن ولكن بدقة منخفضة نسبيًا‪ .‬هم قد يكون‬
‫التعامل مع ضغط الفيديو وملفات فك الضغط بأشكال مختلفة‪ .‬ومع ذلك ‪ ،‬يجب الحفاظ على الصور الثابتة عند أ دقة عالية ‪ ،‬لذلك من‬
‫المناسب الحفاظ عليها‬