CALM/arwiki huggingface dataset:
قبل إجراء بعض التحسينات على المراجعة 0.27, يؤكد منوتون على أن التحسين غالبًا ما يعزى إلى الخبرات المبدئية الفقيرة. وتعتبر أولى حركات المستخدم الجديد غالبًا ما تكون المواءمة (مطابقة) بين قاعدة بيانات مونوتون كبيرة، وهو ما يستغرق ساعات بسبب الصلاحية الواسعة وفحص التكامل الذي تنفذه مونوتون حينما تُنقل المراجعات إلى الشبكة. وبمجرد إنشاء القاعدة الأولية (المواءمة), غالبًا ما تستمر التحركات المتوالية بسرعة أكبر. ونظرًا لأننا في يوليو 2011 تحديث, لا يزال هناك مجال للتحسين الإضافي على بعض الوظائف النادرة.
تبدو مونوتون قوية على وجه الخصوص في سير العمل المدمج/المتشعب، وهو ما تحققه جزئيا بالسماح بالمعاينة قبل الدمج
رُغم إن مونوتون تدعُم بالأساس تشكيلة من بروتوكولات الشبكات لمواءمة تفريعات الأكواد، إلا أنها تختصّ الآن باستخدام بروتوكول معتاد يدعى netsync, وهو أقوى وأكفأ ويتشارك في بعض المفاهيم مع cvcup وrsync. (ومع ذلك، وفيما يتعلق بالإصدار 0.27, من المحتمل أنه يستخدم بروتوكول netsync عبر أي مسار يشمل بشكل ملحوظ وصلات ssh). ويمتلك netsync منفذًا لـ أياناالمخصص له (4591) ويتم دعم الإصدارات الأقدم عن طريق مكون إضافي لإجراء تحليل مروري إيثار ريال. وليس هناك خادم مونوتون خاص لأن أي عميل مونوتون يصلح للعمل كخادم.
التفاصيل الأخرى.
تشمل التفاصيل الأخرى للمونوتون:
بالنسبة لإصدار يناير 2008 [[تحديث]], تشمل مساوئ مونوتون:
[[كيوت|Qt]] لإدارة قواعد البيانات وساحات العمل.
قدم الإصدار 0.26 من مونتو تغييرات جذرية على البنية الداخلية لقاعدة البيانات منها بنية جديدة تعرف بين مطورين مونوتون بـroaster. ولا تتمكن قواعد البيانات التي أنشأها الإصدار 0.26 من تبادل المراجعات مع قواعد بيانات مونوتون القديمة. ولابد أن تُرقّى قواعد البيانات القديمة أولاً إلى تنسيق جديد. ولا يتفق بروتوكول netsync الجديد مع الإصدارات الأحدث من مونوتون.
تُطبّق المونوتون في اللهجة الجديدة من c++ في مقدمة [[بوست (مكتبات سي++)]] ومكتبة [[Botan (programming library)|Botan]] للكتابة الشفرية ومكتبة قواعد بيانات [[إس كيو لايت]]. وتدعم مونوتون التعديل والتمديد من خلال دوال الهووك المكتوبة في [[لغة برمجة]] Lua. وتعمل خاصية بناء العملية في المونوتون عبر [[buildbot]] وتشمل [[اختبارات استرداد]] واسعة المجال.
المونوتون كإلهام من ألجيت.
في أبريل 2005، أصبح المونوتون موضوع مشوّق للغاية في [[البرمجيات الحرة والمفتوحة المصدر]] بعد أن ذكره [[لينوس تورفالدس]] كبديل ممكن لـ [[Bit Keeper]] في عملية تطوير [[لينكس]]. وفي نشر بقائمة المراسلة Linux kernel، أشاد تروفالدز بمونوتون في حين انتقض طريقة الهدم (عمومًا كافة أنظمة التحكم في إصدار خادم العميل):
“ لا تنزعج بإبلاغي عن الطريقة الهدمية. إذا كان الأمر كذلك، فابدأ بالقراءة عن "مونوتون". ويبدوا أنه من أكثر البدائل صلاحية، لكن لا تتملّق المطور كثيرًا حتى لا يجدوا ما يعملوا عليه. فهم على وعى تام بمشاكلي)
بدلاً من تبنى مونوتون، قرر تروفالدز أن يكتب نظامه SCM الخاص, [[جت (برنامج)|جت]]. ويستخدم تصميم جيت بعض أفكار مونوتون، لكن المشروعان لا يشتركان في أي كود مصدر رئيسي. وركز جيت أكثر على الأداء العالي، الذي استلهمه من التاريخ الطويل لأنماط التعاون الموزعة عالية الطلب التي استخدمها تروفالدز وكتّاب linux kernel.
دار الجدل حول قضيه هامة هي ما إذا كان استبدال [[bitkeeper]] ينبغي أن يدعم [[التقاطية]], بينما يستطيع المخزن التفريعى أن يدعم دفعات متداخلة ويرفض غيرها على أساس فردى. ويجادل تروفالدز أن هذا المنهج "ينتج عن الديناميكيّات والحالات النفسيّة الخاطئة في النظام "بنقل العبء إلى [[المنبع (تطوير البرمجيات)|المنبع]] [[صيانة البرمجيات]] rather than forcing [[Downstream (computer science)|downstream]] مخازن معاكسة أكثر من نظيراتها الموافقة وذلك لبذل جهد أكبر للحفاظ على التفريعات من المهملات. وناقش مضيفًا أن مونوتون كانت صائبة في تحولها إلى cherry-picking كجزء تفصيلي لكنها فشلت في تطويعه بما يكفى ليسهل "إلقاء" أي تفريعات غير نظيفة بعد استيفاء غرضها. كما لاحظ تروفالدز أن مونوتون في هذا الوقت لم تحقق مستوى الأداء المطلوب لمشروع بحجم تطوير linux kernel.
تسرى هذه الحجة على خلاف ما يعتقده مطوّرو البرامج من أن cherry picking يعد تفصيلة متقدمة لدرجة أن أداة scm لابد وأن تسعى لتدعيمها. وتعتبر أدوات SCM الأخرى، مثل [[Darcs]] قويّة في هذه المنطقة على وجه الخصوص. بالنسبة لإصدار 2010 [[تحديث]] . دعّم كلاً من جيت ومونوتون لبعض الوقت
التدعيم.
التدعيم الحالي للبرامج يتم من خلال [[قوائم المراسلة]] و[[آي آر سي]] و http://wiki.monotone.ca/
[[تصنيف:برمجيات حرة للتحكم بالإصدار]]
[[تصنيف:برمجيات حرة بلغة سي++]]
مقياس البرمجيّات هو مقياس لبعض خصائص البرنامج أو مواصفاته. ولأن المقاييس الكميّة هامّة في كلّ العلوم، فهناك جهد متواصل من خلال ممارسي علوم الحاسب الآلي ومنظّريه ليصلوا إلى مناهج مماثلة لتطوير البرمجيات. والهدف هو التوصّل إلى مقاييس موضوعيّة ومنتجة وكميّة قد تصلح لاستخدامات هائلة كوضع جدول زمني وتخطيط ميزانيّة وتقدير ألتكاليف واختبار التأكد من الجودة وإصلاح البرنامج وتعديل أداء البرنامج والتوزيع الأمثل للمهام على الموظفين.
المقاييس الشائعة للبرمجيات.
تضمن المقاييس الشائعة للبرمجيّات:
نظرًا للتعقيد الذي يشوب عملية تطوير البرمجيّات بسبب التّفاوت الواسع سوءًا في الأغراض أو المنهجيّات فإنّه من الصعب أن نحدد أو نقيس جودةُ البرمجيّات وكمّها وأن نقرر مقياس حسابي متّفق وصالح لا سيّما عند القيام بمثل تلك التوقّعات قبل ألتصميم التفصيلي. ومن المصادر ألأخرى التي تثير الجدل والمشقّة هو تقرير أي المقاييس أفضل، وماذا يعنى.
لذا قُيّدت الفائدة العمليّة لمقاييس البرمجيّات لتقلّص مجالاتها التي تشمل:
قد يستهدف الغرض العام للمقياس أحد هذه المجالات بأعلى أو أكثر، أو يستهدف التوازن بينها كمؤشّر لدوافع فريق العمل أو أداء المشروع.
القبول والرأي العام.
يشير بعض الممارسين لتطوير البرمجيات إلى أن المقاييس التبسيطيّة قد تضرّ أكثر من أن تنفع. ويلاحظ البعض الآخر أن المقاييس أصبحت جزٌء لا يتجزأ في عمليّة تطوير البرمجيّات.
أثارت هذه المقاييس في نفسيّة المبرمجين المخاوف من الآثار السلبيّة على الأداء بسبب الإجهاد وتوتر الأداء ومحاولات الغش في المقاييس، بينما برى الآخرون أنها تحمل تأثير إيجابي على تقييّم المبرمجين لأعمالهم أنفسهم، وتحول دون الاستهانة بهم.
ويجادل البعض بأن تعريفات العديد من منهجيّات المقاييس ليست دقيقة، ومن ثمّ لا تتضح أحيانًا طريقة الأدوات في الحساب وتوصّلها لنتائجها المحددة, بينما يجادل البعض الآخر بأن وجود قياس غير دقيق أفضل من لا شيء ("لا يمكنك التحكم في ما لا يمكنك قياسه.”).
ويُظهر الدليل أن الهيئات الحكوميّة والجيش ألأمريكي و وكالة ناسا ومستشارين تكنولوجيا المعلومات والمؤسسات ألأكاديمية وبرمجيات تقييم التنمية الأكاديمية والتجاريّة تستخدم جميعها مقاييس البرمجيّات على نطاق واسع.
Covers a minimal set of essential metrics for a successful product delivery.
الأيزو 12207 ISO 12207 هو معيار من المنظمة الدولية للمعايير لتعريف العمليات التي تمر بها البرمجيات في دورة حياتها، ويهدف لأن يكون معيارا يعرف جميع المهام التي يلزم القيام بها لتطوير و صيانة البرمجيات.
يؤسس معيار الأيزو 12207 دورة حياة البرنامج وتشمل العمليات والأنشطة التي يتم تطبيقها أثناء الحصول على خدمات النظام وتنظيمها. ترتبط بكل عملية مجموعة من النتائج. هناك 23 عملية Process و95 نشاط Activity و325 مهمة Task و224 نتيجة Outcome (المعيار الجديد "أيزو\آي إي سي 12207:2008 هندسة الأنظمة والبرمجيات – عمليات دورة حياة البرنامج" يعرف 43 عملية نظام وبرنامج).
الهدف الرئيسي للمعيار هو تقديم منظومة مشتركة بحيث يتمكن كل المشتركين في عملية تطوير البرمجيات - مشترين ومزودي الخدمة ومطورين ومسئولين عن الصيانة ومسئولين عن التشغيل ومدراء وتقنيينن – من استخدام لغة مشتركة، وهذه اللغة المشتركة عبارة عن عمليات معرفة بدقة. الهدف أن تمتاز بنية هذا المعيار بالمرونة وأن تقبل التقسيم لوحدات بحيث يسهل أن تلائم احتياجات أي مستخدم. يبنى المعيار على مبدأين أساسيين: التقسيم والمسئولية، التقسيم يعني أن تكون العمليات على أعلى قدر من الوحدة وأقل قدر من الارتباط، وتعني المسئولية أن تتولي كل عملية مسئولية ما مما يسهل تطبيق المعيار في مشاريع يشترك فيها قانونيا العديد من الأشخاص.
يمكن تغيير العمليات والأنشطة والمهام حسبما تقتضي الحاجة أي مشروع برمجي. تقسم هذه العمليات لثلاثة أنواع: أساسية ودعم وتنظيمية، يجب أن تتوفر عمليات الدعم والتنظيم بشكل مستقل عن المؤسسة والمشروع الذي يتم تنفيذه، والعمليات الأساسية يتم البدأ فيها إذا استدعى الأمر.
العمليات الرئيسية في دورة الحياة.
تتضمن العمليات الرئيسية في دورة الحياة مجموعة العمليات الأساسية في عمل أي منتج برمجي، وتنقسم لخمسة عمليات أساسية:
تغطي العمليات الرئيسية مساحة ضخمة لذا تم تحديد نطاق (إدارة المشروع) scope. يشرح هذا المقال كل العمليات الرئيسية في دورة الحياة ولكنه يتناول عمليات الحيازة والتطوير بشكل أكثر استفاضة.
يمكن تقسيم كل عملية من عمليات دورة الحياة إلى مجموعة من الأنشطة. يشرح هذا الفصل الأنشطة المختلفة في كل عملية من هؤلاء.
تشمل مرحلة الحيازة الأنشطة المتعلقة بافتتاح المشروع، ويمكن تقسيمها إلى مجموعة من الأنشطة والمنتجات المستلمة التي يتم الانتهاء منها بترتيب زمني.
توضع في هذه المرحلة خطة إدارة المشروع، وتضم هذه الخطة معلومات عن المشروع مثل النقاط الفاصلة التي يجب الوصول إليها. هذه الخطة مطلوبة في المرحلة التالية وهي مرحلة التطوير.
في مرحلة التطوير يتم تصميم وبناء واختبار البرنامج وينتج عنها منتج برمجي جاهز للتسليم للعميل. قام العديد من الأشخاص بوضع أساليب مختلفة لتطوير البرمجيات، واختيار أسلوب منهم يعتمد على الوضع وقتها، ولكن النموذج-في V-model هو الأسلوب المستخدم في الكثير من المشاريع. يمكن استخدام بعض التقنيات أثناء عملية التطوير كاليو إم إل في التصميم وتي ماب للاختبار. يتضمن هذا الفصل أهم خطوات النموذج-في.
تجري مرحلتي التشغيل والصيانة على التوازي، تشمل مرحلة التشغيل أنشطة مثل مساعدة الممستخدمين على استخدام المنتج الجديد.
تشمل مرحلة الصيانة مهام صيانة للعمل على استمرار المنتج في آداء وظيفته. تشمل الصيانة أي تحسينات وتعديلات وإضافات محتملة من المستخدم النهائي. عادة ما تقوم الشركة المطورة للبرنامج بتوثيق أي عيوب أو قصور للعمل لاحقا على إيجاد حلول لها ومعالجة الأخطاء المكررة في مراحل الصيانة المستقبلية.
المنتجات المستلمة.
يبين هذا الفصل المنتجات التي يتم تسليمها في كل نشاط.
تشمل الحيازة الانشطة المتعلقة بافتتاح المشروع. يمكن تقسيم مرحلة الحيازة إلى مجموعة من الأنشطة والمنتجات المستلمة التي يتم الانتهاء منها واحدا تلو الآخر.
في مرحلة التطوير يتم تصميم وبناء واختبار المنتج ويكون المنتج بعدها جاهز للبيع للعميل.
يمكن استخدام الأسلوب الذي تم شرحه في هذا المقال في شركة مسئولة عن تطوير وصيانة برمجيات للعملاء، خاصة إذا قررت هذه الشركة أن تبدأ في بناء تطبيق ما من الصفر ويكون المطور هو أيضا المسئول عن صيانة التطبيق والمساعدة في تشغيله.
جميلة قد تشير إلى:
سنوبول SNOBOL (اللغة الرمزية لمعالجة النصوص String Oriented Symbolic Language) هو اسم لمجموعة من لغات برمجة الحاسوب التي ظهرت بين عامي 1962 و1967 في مختبرات بيل في إيه تي أند تي على يد ديفيد جي. فاربر ورالف إي. جريسولد وإيفان إي. بولونسكي توجتها ـسنوبول4. كانت سنوبول واحدة من لغات معالجة النصوص التي ظهرت بين الخمسينيات والستينيات التي كان من ضمنها كوميت COMIT وتراك TRAC.
تتميز سنوبول4 عن معظم لغات البرمجة بوجود الأنماط patterns كنوع بيانات من الدرجة الأولى (نوع بيانات يمكن معالجة محتواه بكل الطرق الممكنة لأنواع البيانات الأخرى) ووجود معاملات operators لربطها والاختيار بينها. يمكن التعامل مع السلاسل النصية التي تنشأ أثناء التنفيذ كبرامج ويمكن تنفيذها أيضا.
كانت سنوبول4 تدرس في العديد من كبرى الجامعات الأمريكية في أواخر الستينيات وأوائل السبعينيات وانتشر استخدامها في السبعينيات والثمانينيات في العلوم الإنسانية كلغة لمعالجة النصوص.
ولكنها تراجعت في السنوات الأخيرة أمام اللغات الأحدث مثل أوك AWK وبيرل التي جعلت معالجة النصوص بواسطة التعابير النمطية أكثر رواجا. تصنف سنوبول4 ضمن اللغات التي تستخدم قواعدها صيغة باكوس نور –التي تكافئ قواعد اللغات الحرة context-free grammars وتتفوق على التعابير النمطية. تعتبر "التعابير النمطية" في الإصدارات الحالية من لغتي أوك وبيرك امتدادا للتعابير النمطية بالمعنى التقليدي، ولكن التعابير النمطية على عكس أنماط سنوبول4 ليست تكرارية وهو ما يمنح انماط سنوبول4 ميزة حسابية. إلا أن التعابير النمطية بلغة بيرل أصبحت تكرارية منذ الإصدار 5.1 (الذي صدر في ديسمبر 2007).
قام أحد مصممي سنوبول4 بتصميم لغات لتخلف سنوبول4 سماها إس إل5 وأيكون Icon –التي جمعت بين خاصية التعقب في مطابقة الأنماط من سنوبول4 والهيكلة القياسية من اللغات الخوارزمية – كما تفردت ببعض المزايا الخاصة.
قام أصحاب لغة سنوبل الأصلية بعملها كآداة للتعامل مع السلاسل كثيرة الحدود، كتبوها بلغة التجميع لتعمل على آي بي إم 7090. كانت قواعدها بسيطة، وبها نوع بيانات واحد – السلاسل – ولا تحتوي على دوال أو تعريفات وتحكمها بالخطأ محدود جدا، ولكن على الرغم من بساطتها و"خصوصيتها" فقد بدأت تنتشر إلى مجموعات أخرى، لذلك قرر مؤلفوها تطويرها وتنسيقها، فأعادوا كتابتها وأضافوا بعض الدوال – قياسية أو من تعريف المستخدم – وأصدروها تحت اسم سنوبول3، كان هناك سنوبول2 ولكنها كانت مرحلة وسطية قصيرة العمر لم تدعم دوال المستخدم ولم يتم إصدارها أبدا. لاقت سنوبول3 نجاحا كبيرا وأعيدت كتابتها لحواسيب أخرى غير آي بي إم 7090 على يد مبرمجين آخرين مما أدى إلى وجود عدد من الإصدارات الغير متوافقة.
مع ازدياد نجاح سنوبول3 استمر مؤلفوها في تلقي طلبات متزايدة لتطويرها وشكاوي أيضا من عدم توافق وعيوب الإصدارات التي لم يقوموا بكتابتها، ولمعالجة هذا وللاستفادة من الحواسيب الجديدة التي ظهرت في الستينيات قرروا عمل سنوبول4 بإضافة العديد من أنواع البيانات والمزايا ولكن باستخدام آلة افتراضية لتسهيل انتقالها من حاسوب إلى آخر، ظل مترجم سنوبول4 مكتوبا بلغة التجميع، ولكنهم استخدموا مزايا الماكرو في المجمع لتعريف أوامر الآلة الافتراضية للغة تطبيق سنوبول SNOBOL Implementation Language (SIL) وأدى هذا إلى تحسن كبير في قابلية اللغة للانتقال فقد جعل انتقال الآلة الافتراضية التي تستضيف المترجم سهلا عن طريق إعادة بناء أوامرها الافتراضية على أي جهاز عليه مجمع ماكرو أو لغة برمجة عالية المستوى.
سنوبول4 هي المثال الرابع والأخير في سلسلة من لغات البرمجة المختصة لمعالجة النصوص.
قدم إصدار سنوبول4 عددا من أنواع البيانات الجاهزة مثل الأعداد الصحيحة والأعداد الحقيقية محدودة الدقة والسلاسل والأنماط والمصفوفات Arrays والجداول (المصفوفات المرتبطة associative arrays)، كما أن سنوبول4 مكنت المستخدم من تعريف أنواع بيانات ودوال جديدة. كانت إمكانية تعريف أنواع بيانات خاصة بالمبرمج خاصية متقدمة في هذا وقتها، كانت مشابهة لخاصية السجلات records التي ظهرت أولا في كوبول أخيرا في باسكال (لغة برمجة)).
كل سطور أوامر Command line سنوبول بهذه الصياغة Label1 Subject Pattern = Object :(Goto Label2)، كل الخانات الخمس اختيارية. بشكل عام يتم مطابقة subject بـالنمط pattern وإذا وجدت خانة object كان يتم استبدال الأجزاء التي تمت مطابقتها بـobject طبقا لقواعد معينة للاستبدال، goto يمكن أن يكون أمر تفرع فوري أو مشروط بنجاح أو فشل عملية مطابقة النمط.
يمكن ان يكون نمط سنوبول شديد البساطة أو بالغ التعقيد، فالنمط البسيط يمكن ان يكون عبارة عن سلسلة نصية ("ABCD") أما المعقد فيمكن أن يكون منظومة ضخمة تصف مثلا قواعد لغة برمجة بأكملها. يمكن كتابة مفسر لغة interpreter بسنوبول تقريبا بالكامل باستخدام التعبير الذي يمثله بصيغة باكوس نور مع بعض التغييرات، ويمكن ألا يزيد كود مجمع ماكرو ومفسر لعتاد نظري تماما عن بضع مئات من السطور وإضافة أمر جديد بسطر واحد.
يمكن أن تؤدي أنماط سنوبول المعقدة ما يعتبر آداؤه غير عملي أو مستحيل عن طريق التعابير النمطية الأقل تعقيدا المستخدمة في أغلب لغات مطابقة الأنماط الأخرى. تأتي بعض هذه القوة مما يسمى بإضافات سبيتبول “SBITBOL extensions” (التي تستخدم من وقتها في كل تطبيقات لغة سنوبول4 الأصلية) رغم أنه يمكن الوصول لنفس الآداء بدونها. بعض هذه القوة مصدرها الآثار الجانبية التي يمكن أن إحداثها أثناء عملية مطابقة النمط ومن ضمنها الاحتفاظ بالكثير من النتائج المؤقتة للمطابقة وإمكانية تنفيذ أي دالة من تعريف المبرمج لتقوم بأي معالجة مطلوبة وإمكانية التأثير في اتجاه عملية المطابقة الجارية أو حتى تغيير النمط نفسه أثناء العملية. يمكن حفظ الأنماط كأي نوع بيانات من الدرجة الأولى ويمكن ربطها واستخدامها بداخل أنماط أخرى واستخدامها بناء تعابير شديدة التعقيد، فيمكن مثلا كتابة نمط سنوبول4 لمطابقة "اسم كامل وعنوان بريدي دولي" وهو ما يستحيل تقريبا باستخدام التعابير النمطية.
تستخدم عملية مطابقة النمط في سنوبول4 خوارزمية التعقب التي تشابه تلك المستخدمة في لغة البرمجة المنطقية برولوغ – التي تستخدم بنية مشابهة للنمط من خلال دي سي جي. تجعل هذه الخوارزمية استخدام سنوبول كلغة برمجة منطقية أسهل من أغلب اللغات الأخرى.
تحتفظ سنوبول بالسلاسل في الكوم heap الذي يخضع لعملية جمع القمامة.
تنافس سنوبول لغة إيه بي إل APL في تميزها في الصياغة وأسلوب البرمجة فكلاهما يختلف جذريا عن لغات البرمجة الإجرائية procedural languages "القياسية" مثل بيسيك وفورتران وسي (لغة برمجة)|سي]].
التطبيق النموذجي كان على بي دي بي – 10 PDP-10، واستخدم لدراسة المصرفات والقواعد الشكلية والذكاء الاصطناعي خاصة الترجمة الآلية والفهم الآلي للغات طبيعية. كان التطبيق الأصلي على آي بي إم 7090 IBM 7090 في مختبرات بيل. صممت سنوبول4 في الأساس بهدف سهولة الانتقال، التطبيق الأول بدأ على آي بي إم 7094 ثم اكتمل على آي بي إم 360 عام 1967. تنقلت اللغة باستمرار بين العديد من المنصات.
تطبق اللغة عادة كمفسر نظرا لصعوبة تطبيق بعض مزاياها عالية المستوى، ولكن هناك مصرف وهو مصرف سبيتبول وبه كل إمكانيات المفسر تقريبا.
يأتي مصرف جنات للغة أيدا مع حزمة (GNAT.Spitbol) التي تطبق كل قواعد معالجة السلاسل في سبيتبول، ويمكن مناداتها بداخل أي برنامج أيدا.
استخدم محرر الملفات بنظام ميتشيجان الطرفي لغة معالجة أنماط مستمدة من سنوبول4.
هناك العديد من التطبيقات المتوفرة، ماكرو سنوبول4 هو تطبيق مفتوح المصدر كتبه فيل بودن يلغة السي وهو قادر على العمل على أي منصة تقريبا، وهو متاح على http://www.snobol4.org/. شركة كاتسبو Catspaw, Inc. تقدم تطبيق تجاري للغة سنوبول4 يعمل مع العديد من المنصات مثل الدوس وماكنتوش وصن وآر إس\6000 وغيرها على http://www.snobol4.org/. أحد الإصدارات القديمة سنوبول4+ متوفر الآن مجانا من كاتسبو. سنوبول4 مينيسوتا سنوبول4 Minnesota SNOBOL4 الذي كتبه فيكتورز بيرستيس هو تطبيق الحاسوب الشخصي الأقرب للإصدار الذي كان مستخدما على حاسب آي بي إم المركزي IBM mainframe (ويدعم حتى أمر FORMAT المستوحى من فورتران) وهو متاح مجانا أيضا على http://www.berstis.com/snobol4.htm.
برغم أن سنوبول نفسها تفتقر لمزايا البرمجة المهيكلة يوجد أحد إصداراتها الذي يحتوي على هذه المزايا وهو سنوستورم Snostorm وظهر في كلية لندن الجامعية (UCL) بين 1982 و1984 وإصدار آخر كتبه أندرو كوينيج اسمه سنوكون Snocone.
أضاف تطبيق سبيتبول أيضا عددا من المزايا - رغم عدم استخدام مصطلحات البرمجة المهيكلة التقليدية – التي يمكن استخدامها لتقديم العديد من الإمكانيات التي تعتبر من إمكانيات "البرمجة المهيكلة"، أبرزها البنية المتداخلة if/then/else. أصبحت هذه المزايا من وقتها متوفرة في معظم تطبيقات سنوبول4 الأخيرة. بعد أن ظل سبيتبول منتجا تجاريا لأعوام أصبح أخيرا مجانيا في أبريل 2009 ويخضع لرخصة جنو العمومية.
حسب كلام ديف فاربر, فقد "قرر هو وجريزولد وبولونسكي تسميتها Symbolic EXpression Interpreter SEXI"
كانت الأمور مستقرة حتى بدأت في إرسال أحد دفعات المهام لتجميع النظام كالعادة على بطاقة مهامي – التي كانت تسمى قياسيا بعملي واسمي - Sexi Farber فنظرت إحدى الفتيات إليها وقالت "هذا ما تظنه أنت" بطريقة مضحكة.
وهذا بين أننا نحتاج لاسم آخر فجلسنا وتحدثنا وشربنا القهوة وبعد وقت طويل قال أحدهم – غالبا رالف – "فرصنا في إيجاد اسم معدومة we don’t have a Snowball chance in hell of finding a name” فصحنا جميعا "وجدناها سنوبول" ثم بدأنا في التفكير فيما يمكن أن تشير إليه.
بعض التفاسير للفظ سنوبول “SNOBOL” ‘String Oriented Symbolic Language’ أو (على طريقة إنسيالسم) ‘StriNg Oriented symBOLic Language’..
سنوبول وبايثون.
بعد أن وجد بعض مستخدمي لغة بايثون أن استخدام التعابير النمطية مقيد تم عمل إضافة لبايثون تسمح باستخدام مطابقة النمط من سنوبول في برامج بايثون. الإضافة اسمها سنوبي SnoPy وكتبها دون روزنبرج.
لقد ابتكر دان سوينهارت وبوب سبورل لغة جديدة للتخاطب من خلالها مع جهاز الكمبيوتر تسمي الشراع وكانت تدعي رأس الغول 60 وهي تجسيد رائع للذكاء الاصطناعي ووفرت لهم الإمكانيات منظمة العفو الدولية في معامل جامعة ستانفورد وذلك عام 1970، والميزة ألكبري التي تمتاز بها لغة الشراع هو أن نظام البيانات الخاص بها يعتمد علي رموز مخزنه بشكل مرتب تصاعديا قد يتضاعف ثلاث مرات كنظام قفزة فيلدمان وجيري بول وتشمل تلك اللغة علي سمات عديدة أخرى كتناسق العمليات والأحداث والسياقات وسجل تراجع جمع القمامة مثلاً وإنتاج كتب عالية الجودة ولها وحدات ماكرو ومرفق معها بعض البيانات التي تهدف إلي بناء يشبه الأشجار للبحث وقوائم للجمعيات.
والمثير للاهتمام بهذه اللغة هي عملية ترميز أنظمة البرمجة في لغة الشراع حيث كان ذلك واضحا منذ الإصدارات الأولي في بروتوكول نقل الملفات ونظام تنسيق المستندات وبرنامج جداول البيانات الذي يتفاعل مع النص بشكل مبسط ومنظم في نفس الوقت وفي عام 1978 كان هناك نصف درزينة من أنظمة التشغيل المختلفة التي تستخدم في نظام المشاركة الزمنية الغير متطابق وأنظمة التشغيل الرقمية التي سميت فيما بعد بقمم10 وكانت عائلة الحاسوب الكبير محل قرصنة من معهد ماساتشوستس للتكنولوجيا وجامعة كارينجي ميلون وشركة بولت وبيرانك ونيومان ومنظومة العمل جميعها تستند إلي نظام تينكس (الربط بين الوقت وأنظمة التشغيل).
كما كانت لغة الشراع محل نظر الباحثين بمعهد ماساشوستس للتكنولوجيا حتى يتمكنوا من الاستفادة من برنامج تطويرها بجامعة ستانفورد فكل نافذة لها كانت تتطلب إعادة صيغتها حتى يسهل تطبيقها.
أجهزة الكمبيوتر تعتمد في استخدامها للغة الشراع علي إصدار يسمي مانسال وكان ذلك منذ أواخر 1970 وظل الاحتياج إلي تلك اللغة مطلوب تطبيقه علي برامج مثل برنامج اوتو كاد حتى عام 1980 واللجوء لها كان أساسة سهولة التعامل من خلالها مع أجهزة الكمبيوتر وما زال هناك استخدام محدود لها حتى 2005.
تعد عملية تطوير البرامج (المعروفة كذلك باسم تطوير التطبيقات أو تصميم البرامج أو برامج التصميم أو تطوير تطبيقات البرامج أو تطوير تطبيقات المؤسسات أو تطوير النظام الأساسي) عبارة عن تطوير منتج برمجية حاسوب. ويمكن استخدام المصطلح "تطوير البرامج" للإشارة إلى نشاط البرمجة، والذي هو عبارة عن عملية كتابة الكود المصدري والاحتفاظ به، ولكن بالتمعن في المصطلح على نطاق أعم فسنجد أنه يشمل على كل ما يفصل بين وضع تصور للبرنامج المطلوب وصولاً إلى الإعلان النهائي عن البرنامج، وذلك في عملية مرتبة ومخطط لها على نحو مثالي. ولذلك، قد تشتمل عملية تطوير البرامج على البحث أو التطوير الجديد أو تصميم القوالب أو التعديل أو إعادة الاستخدام أو إعادة الهندسة أو الصيانة أو أية أنشطة أخرى قد تؤدي لإنتاج منتج برمجي.
يمكن تطوير البرامج لعدة أغراض، والثلاثة الأكثر شيوعًا منها هي تلبية احتياجات خاصة لعميل/شركة معينة (كما هو الحال مع البرامج المخصصة)، أو لتلبية حاجة متوقعة لمجموعة من المستخدمين المحتملين (كما هو الحال مع برمجيات مفتوحة المصدر وتجارية)، أو للاستخدام الشخصي (على سبيل المثال، قد يكتب أحد العلماء برنامجًا لتشغيل برنامج اعتيادي بشكل تلقائي). وتتطلب عملية تطوير البرامج المضمنة، والتي تعني، تطوير برنامج مضمن كذلك الذي يتم استخدامه في التحكم في المنتجات الاستهلاكية، دمج عملية التطوير مع عملية تطوير المنتج المادي الخاضعة للسيطرة.
رفعت الحاجة إلى وجود مراقبة جودة أفضل في عملية تطوير البرامج من قيمة فرع العلم الخاص بـ هندسة البرمجيات، والتي تهدف لتطبيق نهجًا نظاميًا متمثلاً في نموذج الهندسة لعملية تطوير البرامج.
هناك عدة طرق منهجية لتطوير البرامج، تشبه كثيرًا وجهات النظر المختلفة للأحزاب السياسية حول طريقة حكم البلاد. فالبعض يتبع طريقة منهجية أكثر تنظيمًا وتستند إلى الهندسة لتطوير حلول الأعمال، بينما قد يلجأ الآخرون إلى نهج تدريجي بشكل أكبر، حيث يتطور البرنامج بينما يتم إنشاؤه جزء بعد جزء. وتشترك أغلب الطرق المنهجية في مجموعات معينة من المراحل التالية لتطوير البرامج:
غالبًا ما يُشار إلى تلك المراحل معًا باسم دورة حياة تطوير البرمجيات، أو SDLC. وقد تنفذ التوجهات المختلفة لتطوير البرامج تلك المراحل وفق ترتيبات مختلفة، أو تخصيص وقت أقل أو أكثر لمراحل مختلفة. وقد يختلف كذلك مستوى التفصيل للوثائق التي يتم إنتاجها عند كل مرحلة من عملية تطوير البرامج. وقد يتم تنفيذ تلك المراحل بالدور (نهج يستند إلى "الشلال")، أو قد يتم تكرارها وفق دورات أو تكرارات متنوعة (نهج أكثر "شدة"). وعادةً ما يتضمن النهج الأكثر شدة بإنفاق وقت أقل على عمليتي التخطيط والتوثيق، وإنفاق المزيد من الوقت على كتابة الأكواد وتطوير اختبارات يتم تشغيلها بشكل تلقائي. وتعمل النُهُج الأكثر "شدة" كذلك على تعزيز الاختبارات المستمرة على مدار دورة حياة التطوير، فضلاً عن امتلاك منتج يعمل (بدون أخطاء) طوال الوقت. وتحاول النُهُج التي تستند إلى "الشلال" تقييم غالبية المخاطر ووضع خطة مفصلة للبرنامج قبل بدء تنفيذه (كتابة الأكواد)، وتجنب تغيرات التصميم الهامة وإعادة كتابة الأكواد في مراحل لاحقة من دورة حياة تطوير البرنامج.
تمتلك الطرق المنهجية المتنوعة العديد من الميزات والعيوب، وسيعتمد أفضل نهج لحل مشكلة باستخدام برنامج في الغالب على نوع المشكلة. وإذا تم استيعاب المشكلة بشكل جيد والتخطيط لحل بشكل فعال مبكرًا، فقد يعمل التوجه الذي يستند إلى "الشلال" بشكل أكبر على النحو الأمثل. وعلى النحو الآخر، إذا كانت المشكلة فريدة (بالنسبة لفريق التطوير على الأقل) وتعذر وضع تصور لبنية حل البرنامج بسهولة، فيكون عندئذٍ التوجه التدريجي "الشديد" أفضل. وعملية تطوير البرامج عبارة عن بنية يتم دمجها في تطوير منتج برمجي. وتشمل المرادفات كذلك دورة حياة البرنامج أو عملية البرنامج. وهناك العديد من النماذج لتلك العمليات، تصف كل منها التوجهات المؤدية إلى مجموعة متنوعة من المهام أو الأنشطة التي قد تحدث خلال العملية.
التناسق في البرامج.
لضمان قدرة البرنامج على التطور بطريقة تحافظ على تعدد الأبعاد المتأصل فيه، يجب على الفرد أن يضمن تطور الأبعاد المختلفة معًا بطريقة متناسقة. وتتوفر لدى البرنامج العديد من الأبعاد التي يتعين الجمع بينها داخل إطار عمل واحد، فلا تقوم بالتدوينات المختلفة فحسب بل كذلك لا تتفاعل بشكل هرمي. ويجب عدم توجيه آلية لتناول مشكلة بعينها مثل ضمان تناسق مخطط فئة UML مع الكود المصدري. بل يجب أن تتمتع بدلاً من ذلك بالمرونة الكافية للتعامل مع مجموعة كبيرة من الأبعاد المضمنة بالفعل داخل عملية تطوير البرامج.[1]
موضوع تطوير البرامج.
تتسم مصادر الأفكار لمنتجات البرامج بالغزارة. وقد تنبع تلك الأفكار من بحث السوق والذي يشمل الأبعاد الديموغرافية للعملاء الجدد المحتملين والعملاء الحاليين أو نظريات المبيعات التي رفضت المنتج أو فريق تطوير البرامج المحلي أو الجهة الخارجية الإبداعية. وعادة ما يتم تقييم أفكار المنتجات البرمجية أولاً بواسطة موظفي التسويق المعنيين بالجدوى الاقتصادية، وذلك لضمان ملاءمتها مع قنوات التوزيع الحالية، ودراسة تأثيراتها المحتملة على مجموعات المنتجات الموجودة، وللتعرف على الميزات المطلوبة، ولضمان ملاءمتها لأهداف التسويق الخاصة بالشركة. وفي مرحلة التقييم للتسويق، يتم تقييم الفرضيات الخاصة بالوقت والتكلفة. ويتم الوصول لقرار في مرحلة مبكرة حول ما إذا كان سيتم المواصلة لتنفيذ المشروع أم لا، وذلك استنادًا إلى المعلومات الأكثر تفصيلاً التي يقدمها فريق التسويق والتطوير. باراناي.
في كتاب "مناظرات برمجية رائعة"، أفصح ألان م ديفيس في الفصل الفرعي الذي حمل عنوان "الحلقة المفقودة في تطوير البرامج" من فصل "المتطلبات" عما يلي