مقالات و سخنانی در زمینه مهندسی نرم افزار

[کربلایی]

طراحي نرم‌افزار از سال‌ها پيش در محافل محققان و مهندسان نرم‌افزار مورد بحث است. معمولاً بحث در مورد اين موضوع است كه طراحي سيستم نرم‌افزاري بر اساس سورس‌كدهاي نرم‌افزار استوار است و دياگرام‌ها و طرح‌هاي ابتدايي مي‌تواند در پياده‌سازي نرم‌افزار به ما كمك كند، ولي نمي‌توان گفت تمامي مراحل طراحي يك نرم‌افزار به آن دياگرام‌ها وابسته است. در واقع اين بحث بيان مي‌كند كه سورس‌كدهاي برنامه از دياگرام‌هاي UML مجزا نيست.

اگر تا به حال در تيم‌هاي نرم‌افزاري حضور داشته‌ايد و پروژه‌هاي نرم‌افزاري پياده‌سازي نموده‌ايد، حتماً با اشكالاتي، برخورد كرده‌ايد. اگر خيلي خوش‌شانس باشيد، در شروع پروژه مشتري يا همان كلاينت، اطلاعات دقيقي را از سيستمي كه نياز دارد در اختيار شما قرار خواهد داد. اگر خيلي زرنگ و باز خوش‌شانس باشيد، در همان جلسه اول مصاحبه با مشتري مي‌توانيد تصويري كلي از نرم‌افزاري كه قرار است تهيه شود را در فكر خود تجسم كنيد و شروع به طراحي و پياده‌سازي قسمت ابتدايي برنامه نماييد. با اين حال صبر كنيد؛ انگار با مشكلي روبه‌رو شده‌ايد! بله كوچك‌ترين تغييري از طرف مشتري تمام برنامه شما را با مشكل روبه‌رو مي‌سازد و پروژه شما دچار تغييراتي مي‌شود. از جمله مشكلاتي كه ممكن است براي شما پيش بيايد، مي‌توان به موارد زير اشاره كرد:

- ممكن است ماجول‌هاي برنامه بسيار سخت طراحي شده باشند. در ابتدا برنامه‌نويسان كدهاي هر ماجول را بسيار منظم و قابل فهم براي ساير اعضاي تيم آماده مي‌كنند، ولي به مرور زمان و ايجاد تغييراتي در متن كدها، به كدهايي تبديل مي‌شوند كه فهميدن آن‌ها بسيار سخت خواهد بود.

- كدهاي نرم‌افزار ممكن است دچار تكرارهاي غيرضروري شوند و قطعه‌اي از كد چندين بار در طول برنامه تكرار شود كه در نتيجه باعث سردرگمي برنامه‌نويسان تيم خواهد شد و طبيعتاً تغييرات در برنامه را با مشكلاتي رو‌به‌رو خواهد كرد. مثلاً تصور كنيد كه در برنامه با اشكالي روبه‌رو شده‌ايد و آن را مرتفع كرده‌ايد، ولي وقتي برنامه را مجدداً كامپايل مي‌كنيد، متوجه مي‌شويد برنامه باز اشكال دارد. در نتيجه مجبور مي‌شويد تمام قسمت هايي را كه اين اشكال در آن وجود دارد، اصلاح كنيد.

- كدهاي برنامه ممكن است داراي اجزايي باشند كه جز افزودن پيچيدگي به برنامه سود ديگري نداشته باشند. اين اشكال معمولاً وقتي پيش ميآيد كه برنامه‌نويسان پروژه امكاناتي كه احتمال مي‌دهند در آينده به آن نياز است را از ابتدا در برنامه قرار مي‌دهند كه باعث پيچيدگي در متن برنامه خواهد شد.

- يكي از اشكالات ديگري كه ممكن است در پروژه‌هاي نرم‌افزاري پيش آيد اين است كه وقتي برنامه‌نويسان با اشكال يا تغييري در برنامه مواجه مي‌گردند، بيش از يك راه‌حل براي آن تغيير پيدا مي‌كنند. برخي از اين تغييرات قالب طراحي نرم‌افزار را حفظ مي‌كند و برخي تنها با هك كردن سورس‌كدها اين تغيير را به وجود مي‌آورند و اين كار باعث به‌هم ريختگي و از هم گسيختگي طراحي يك نرم‌افرار و كدهاي آن مي‌شود.

- معمولاً تغييرات در برنامه باعث شكنندگي سيستم نرم‌افزاري مي‌شوند.

- معمولاً از آنجا كه هر تغيير در برنامه باعث تغييراتي در قسمت‌هاي مختلف برنامه مي‌شود، تغييرات در سيستم‌هاي نرم‌افزاري معمولاً دشوار است.

در مدل برنامه‌نويسي چابكانه اعضاي تيم با رعايت اصول اين مدل نرم‌افزاري نمي‌گذارند اشكالات ذكرشده در سيستم نرم‌افزاري به وجود آيد. در ادامه با ذكر يك مثال بسيار ساده، طراحي چابكانهِ اين مثال مورد بررسي قرار مي گيرد.

شكل 1​

تصور كنيد كه مدير شما صبح روز شنبه به دفترتان ميآيد و از شما مي خواهد برنامه‌اي ساده بنويسيد كه بتواند كاراكترها را از صفحه‌كليد به چاپگر كپي كند. تصور شما از اين برنامه ساده اين است كه مي توانيد آن را در عرض يك ساعت يا كمتر و با حداكثر ده خط كد بنويسيد، ولي ممكن است مسئوليت‌هاي ديگري جز اين كار داشته باشيد.

پس به مدير خود مي‌گوييد طي حدود دو هفته اين كار تمام خواهد شد. اولين كاري كه انجام مي‌دهيد اين است كه طرح اوليه اين برنامه ساده را ترسيم كنيد. طرح شكل 1 ممكن است طرح مورد نظر شما باشد.

به نظر ميآيد اين برنامه از سه قسمت تشكيل شده باشد: ماجول Copy كه دو ماجول ديگر را فراخواني مي‌كند. اين ماجول كاراكترها را از ماجول ReadKeyboard مي‌گيرد و آن‌ها را به ماجول WritePrinter مي‌فرستد. وقتي اين طرح را ترسيم كرديد، خيالتان راحت مي‌شود و به خود مي‌گوييد: اين برنامه خيلي ساده است و آن را حتي مي‌توانيد سريع به اتمام برسانيد و تحويل مديرتان بدهيد. همان موقع شروع به نوشتن ماجول Copy مي‌كنيد و كدي شبيه كد 1 را آماده مي‌كنيد.

کد1​

پس از نوشتن اين كدها، آن را كامپايل مي‌كنيد و متوجه مي‌شويد كه با موفقيت كامپايل مي‌شود. برنامه را آماده و در محلي ذخيره مي‌كنيد كه آخرين روز هفته به مدير خود تحويل دهيد و به او بگوييد: حتي يك هفته قبل از موعد برنامه آماده شده است. تا اينجا همه چيز به خوبي پيش رفته است.

بعد از چند هفته مدير به شما مراجعه مي كند و از شما مي‌خواهد برنامه كپي را تغيير دهيد. به نحوي كه بتواند اطلاعات را از Paper Tape Reader بخواند. عكس‌العمل شما نسبت به اين تغيير طبيعتاً اين خواهد بود كه اين كار وقت زيادي مي‌برد و در برنامه اوليه اين نياز كاربر در نظر گرفته نشده بود، ولي گريزي نيست و بايد اين كار انجام شود. پس يك آرگومان Boolean به ماجول Copy خود اضافه مي‌كنيم و به برنامه مي‌گوييم اگر اين مقدار صحيح بود، اطلاعات را از Paper Tape Reader بخواند وگرنه، مانند كد 1 از صفحه‌كليد بخواند.

كدهاي 2 قسمت اول، نتيجه اين تغييرات خواهند بود. پس از اعمال تغييرات اين كدها را كامپايل مي‌كنيد و به مدير خود تحويل مي‌دهيد. همه چيز به خوبي پيش مي‌رود، ولي چند هفته بعد باز مدير از شما مي‌خواهد كه برنامه را تغيير دهيد و كاري كنيد كه برنامه كپي خروجي خود را به Paper Tape Punch بفرستد. جواب احتمالي شما به مدير اين خواهد بود كه اين همه تغييرات روي طراحي تأثير خواهد گذاشت و باعث مي‌شود كار نگهداري نرم‌افزار با مشكل روبه‌رو شود، ولي آيا فكر مي‌كنيد اين استدلا‌ل براي مديرتان اهميت دارد؟

خير. از اين رو بايد همان چيزي را كه او مي‌خواهد آماده كنيد. در غير اين صورت، اين مسئوليت به فرد ديگري واگذار خواهد شد. از اين رو باز برنامه را تغيير مي‌دهيم و كدهاي 2 قسمت دوم را مي نوسيم.

كد 2 ​

اگر به ياد داشته باشيد در ابتداي اين نوشته اشكالاتي كه ممكن است در طراحي نرم‌افزار با آن روبه‌رو شويد ذكر شد. آيا فكر نمي كنيد كه برنامه Copy كه در مورد آن صحبت شد، از آن‌گونه نرم‌افزارها باشد؟

حال بياييم با توجه به اصول مدل نرم‌افزاري چابكانه برنامه Copy را بنويسيم. در طراحي چابكانه ممكن است اولين قدم نوشتن كدهاي 1 باشد (البته با استفاده از روش Test Driven Development)، ولي وقتي مدير از شما مي‌خواهد كه برنامه را طوري تنظيم كنيد كه بتواند از Paper Tape Reader بخواند بايد ابتدا طرح خود را با توجه به تغييري كه در نياز كاربر داده شده است، تغيير دهيد.

كد 3 برنامه كپي را با استفاده از مدل چابكانه نشان داده است. به جاي اين‌كه بخواهيم طرح خود را وصله‌كاري كنيم، تا نيازهاي جديد كاربر را تأمين نمايد، تيم برنامه‌نويس بايد طرح خود را به نحوي تنظيم كند كه اين قابليت و امكان را داشته باشد كه در آينده، در صورت نياز، تغيير كند.

طرح اوليه برنامه كه در شكل 1 نشان داده شده است، طرح قابل انعطافي نيست. چون كلاس‌ها مستقل نيستند و كلاس اصلي برنامه به كلاس‌هاي KeyboardReader و PrinterWriter وابسته است. با استفاده از مدل‌هاي Agile بايد اين وابستگي از ميان برداشته شود و در نتيجه تغييرات نتواند بر كلاس Copy تأثيرگذار باشد.

با استفاده از اصولي مانندOpen-Closed Principle) OCP، كه در قسمت‌هاي بعدي كدنبشته‌ها در مورد آن بحث خواهد شد)، مي‌توانيد طرح خود را به نحوي تنظيم كنيد كه تغييرات روي طرح شما تأثيري نداشته باشد. همان‌طور كه در كد 3 مشاهده مي‌كنيد، براي اين‌كه كلاس خود را در مقابل تغييرات مقاوم سازيم، از كلاس abstract استفاده كرده‌ايم و از الگوهاي Strategy نيز بهره جسته‌ايم.

كد 3 ​

در واقع طراحي چابكانه رويه‌اي است كه با استفاده از الگوها و اصول Agile Development ساختار برنامه را به نحوي طراحي مي‌كند كه برنامه در عين سادگي بتواند قابليت تغييرات احتمالي را نيز داشته باشد. در قسمت‌هاي بعدي كد‌نبشته‌ها اين اصول و الگوها مورد بررسي دقيق‌تر قرار خواهد گرفت.

منبع: ماهنامه شبکه

 

[دراک]

سلام
مطلب بسیار جالبی بود واقعا مدیریت تغییرات بعدی در هر برنامه نویسی چه برای سیستم های نرم افزاری سفارشی مشتری باشه و چه برای یک پروژه تحصیلی کار سختیه و تبحر در اون وابسته به تجربه در برنامه نویسی هستش. مطلب جدیدی که عنوان کردید روزنه امید برای تازه کارها باز کرد.

موفق باشید.

 

[کربلایی]

نگاهي كوتاه به برآورد نرم‌افزار

نگاهي كوتاه به برآورد نرم‌افزار

يكي از مهم‌ترين مسائلي كه مديران پروژه‌هاي نرم‌افزاري به آن توجه دارند، استفاده از ابزارها، تكنيك‌ها و روش‌هاي مختلف براي برآورد و كنترل راندمان كاري است. اين فاكتور مي‌تواند براي برآورد نيروي انساني،‌مدت زمان موردنياز پروژه‌ها و برنامه‌ريزي بسيار سودمند باشد.

دانستن <اندازه> نرم‌افزار قبل از توليد آن مي‌تواند ما را در اين برآوردها ياري رساند. در شروع هر پروژه نرم‌افزاري اولين سؤال و شايد سخت‌ترين سؤالي كه ممكن است مطرح شود اين است: هزينه توليد نرم‌افزار و اندازه آن چه‌قدر است ؟

وقتي از اندازه‌گيري نرم‌افزار صحبت مي‌كنيم، ‌بايد دنبال اندازه‌هايي از نرم‌افزار باشيم كه به ما در مورد آن اطلاعاتي مي‌دهند. همان‌طور كه سانتي‌متر و گرم، اطلاعاتي در مورد اندازه و وزن اشيا در فيزيك به ما مي‌دهند، اندازه‌هاي نرم‌افزاري اطلاعاتي درباره مرغوبيت و كيفيت نرم‌افزار به ما مي‌دهند.

به‌عنوان مثال، اگر بخواهيم مدت يك پروژه نرم‌افزاري را حدس بزنيم، بايد اندازه نرم‌افزار را تخمين بزنيم و اگر بخواهيم كيفيت نرم‌افزار را اندازه گيري كنيم بايد يك اندازه داشته باشيم كه بتواند كيفيت نرم‌افزار را مشخص كند.

براي اين‌كه بتوانيم هزينه نرم‌افزار را محاسبه كنيم، بايد اندازه نرم‌افزار را پيدا كنيم. اولين روشي كه براي اندازه‌گيري نرم‌افزارها مي‌توان استفاده كرد، محاسبه اندازه خطوط برنامه است. در اين روش كه روشي استاندارد به نظر نمي‌رسد، براساس تعداد خطوط برنامه اندازه آن و سپس قيمت آن محاسبه مي‌شود. البته، روش‌هاي ديگري مانند COSMIC و COCOMO روش‌هاي بهتري براي برآورد اندازه نرم افزار هستند.

از طرف ديگر، براي اندازه‌گيري نيروي كاري كه در يك پروژه نرم‌افزاري مشغول كار هستند نيز مشكلاتي وجود دارد. به عبارتي كار يك نفر در ماه به تخصص و مهارت آن فرد بستگي مستقيم دارد.

در نتيجه، پيش‌بيني نيروي كار مورد نياز به فاكتورهاي مختلفي بستگي دارد و بايد فرمول خاصي را براي به دست آوردن واحد كوشش يا Effort استفاده كرد. به‌عنوان مثال، فرمول زير را در نظر بگيريد:

(UoE= a+b (Siez)^c+ACCUM(factors

در اين فرمول ‌UoE (سرنام Units of Effort) يا واحد كوشش است كه اغلب به‌صورت نفر در ماه يا نفر در روز است. a حداقل قيمت پروژه و Size، اندازه نرم‌افزار است كه به وسيله دو پارامتر c و b با استفاده از تجربه‌هاي گذشته گروه نرم‌افزاري تغيير پيدا مي‌كند و در آخر نيز‌ ‌ مجموع انباشتگي يا Accumulation فاكتورهايي مانند تكنيك، ابزار، تخصص گروه، پروسس و... به اين اندازه اضافه شده و UoE پروژه را مشخص مي‌كند.

از آنجا كه اغلب پروژه‌هاي نرم‌افزاري هم‌اكنون به صورت شي‌ء گرا آماده مي‌شوند، به نظر مي‌رسد روش‌هاي COCOMO و COSMIC نيز نتوانند با دقت اندازه نرم‌افزار را مشخص كنند. از اين رو، استفاده از تكنيك‌هايي براي اندازه‌گيري نرم‌افزارهاي OO پيشنهاد مي‌شود.

يكي از اين روش‌ها روش Lorenz و kidd است كه بر مبناي اندازه‌گيري تعداد كلاس‌ها و كامپوننت‌هاي برنامه استوار است. اين اندازه مي‌تواند در فرمول UoE و به جاي پارامتر Size آورده‌شود و تعيين‌كننده هزينه پروژه نرم‌افزاري است. براي محاسبه تعداد كلاس‌ها و كامپوننت‌هاي برنامه بايد چهار مرحله زير را انجام داد:

1- محاسبه تقريبي تعداد كلاس‌هاي برنامه با استفاده از شرح نيازمندي‌هاي كاربران
2- تقسيم‌بندي انواع واسط كاربر و دادن وزن‌هاي زير به آن:
الف- عدم وجود رابط كاربري يا UI (وزن 2)
ب- وجود واسط كاربر ساده (وزن 25/2)
پ- واسط كاربر معمولي (وزن 5/2)
ت- واسط كاربر پيچيده (وزن 3)
3- محاسبه حاصل‌ضرب عدد به دست آمده از مرحله اول با عدد مرحله دوم و جمع آن با تعداد كلاس‌هاي پيش فرض در مرحله اول.
4- محاسبه حاصل‌ضرب عدد به دست آمده در مرحله 3 با عددهاي 15 تا 20 (با توجه به بازده‌اي كه گروه توليد نرم‌افزار در توليد يك كلاس دارد). به‌عنوان مثال، فرض كنيد برنامه‌اي را مي‌خواهيم طراحي كنيم كه حدود پنجاه كلاس دارد و به‌نظر مي‌رسد، اين برنامه داراي رابط كاربري پيچيده‌اي است.

در نتيجه class 200<=50+150=3×50 وجود دارد. به فرض اين‌كه هجده روز طول بكشد تا يك نفر يك كلاس را طراحي كند. Person-Days 3600=18×200

عدد Size مي‌شود و مي‌توان آن را در فرمول UoE قرار داد و با استفاده از عدد به دست آمده قيمت نرم‌افزار را به دست آورد. با استفاده از اين روش ديگر به شمارش خطوط برنامه نيازي نخواهد بود و مي‌توان با اين روش استاندارد برآورد دقيق‌تري نسبت به قيمت نرم‌افزار داشت.

البته، ناگفته نماند كه تمام اين اعداد تخمين است و مدير پروژه نرم‌افزاري با استفاده از تجربه‌هاي گذشته مي‌تواند پيش‌بيني دقيق‌تري داشته باشد. همان‌گونه كه در فرمول بالا نيز ذكر شد پارامترهاي b و c را مي‌توان بر اين اساس تغيير داد و پيش‌بيني دقيق‌تري داشت.

منبع: ماهنامه شبکه

 

[کربلایی]

با جنبه برنامه بنویسید------قسمت اول

با جنبه برنامه بنویسید------قسمت اول

بسياري از افراد معتقدند، علوم كامپيوتر آن قدرها هم كه به‌نظر مي آيد، سريع پيشرفت نمي‌كند. آن‌ها معتقدند، در بسياري از شاخه‌ها كار تقريباً تمام شده‌است و كارهاي جديد فقط در حد پيشرفت‌هاي جزئي انجام مي‌گيرد. در حقيقت، بعضي از موضوع‌هاي مطرح شده توسط اين گروه بدبين، تا حدودي به واقعيت نزديك است.

بسياري از پايه‌هاي علوم كامپيوتر شكل گرفته است و به نظر ميآيد تغيير آن‌ها، دست‌كم به اين زودي‌ها امكان‌پذير نيست. در بعضي از شاخه‌ها يك فناوري آن‌چنان جاي پايش را محكم كرده‌است كه حتي تصور وجود روشي ديگر كمي سخت به نظر مي‌رسد.

اما كامپيوتري‌ها مردم جالبي هستند. شايد آن‌ها خيلي پركار نباشند، اما هميشه ايده‌هاي جديد و خلاقانه راهي براي نفوذ به درون دنيايشان پيدا مي‌كنند. شايد در بسياري از زمينه‌ها، كار شما به مطالعه كارهاي كلاسيك انجام شده محدود شود، اما هميشه جاده‌هاي جديدي وجود دارد.

گريگور كيزالس (Gregor Kiczales)، بيشتر وقت خود را در آزمايشگاه پارك (PARC) كه مبدأ شروع بسياري از خلاقيت‌هاي بزرگ حوزه علوم كامپيوتر بوده، گذرانده است. محيط صنعتي - آكادميك آزمايشگاه علاوه بر دل‌مشغولي‌هاي آكادميك، كيزالس را به مسائل و مشكلات حوزه نرم‌افزار در دنياي واقعي آشنا ساخته است.

در حقيقت، يكي از همين مشكلات (Cross-cutting Concern) بود كه منجر به ارائه مدل AOP توسط اين پروفسور دانشگاه UBC و همكارانش در زيراكس پارك شد. مدلي كه به تحركات زيادي در حوزه نرم‌افزار منجر شد تا جايي كه Daniel Sabbah، معاون بخش استراتژي‌هاي نرم‌افزاري شركت آي‌بي‌ام درباره آن مي‌گويد: «زمان توسعه نرم‌افزارها به وسيله مفهوم Aspect-Oriented فرا رسيده‌است. صنعت نرم‌افزار به آن نياز دارد و آي‌بي‌ام در حال حاضر از آن استفاده مي‌كند.»

اولين ارائه رسمي از اين موضوع به سال 1997 برمي‌گردد. البته، اطلاعات تاريخي درباره AOP بسيار اندك است و ما از روند كار چيز زيادي نمي‌دانيم. كيزالس خود در پاسخ به پرسش نگارنده پيرامون تاريخچه و روند شكل‌گيري AOP مي‌گويد: «متأسفانه هيچ تاريخ مدوني براي AOP وجود ندارد.»

در اين مقاله سعي كرده‌ايم معرفي مناسبي از اين پارادايم جديد برنامه‌نويسي ارائه دهيم.
چرا از پارادايم استفاده مي‌كنيم؟

توماس كوهن، پارادايم را اين‌گونه تعريف مي‌كند: «پارادايم در نتيجه فعاليت‌هاي اجتماعي ظاهر مي‌شود كه در آن مردم ايده‌هايشان را توسعه مي‌دهند و قواعد و مثا‌ل‌هايي مي‌سازند كه اين ايده‌ها را بيان كند.1» اين شايد يكي از رسمي‌ترين تعريف‌هايي باشد كه در سراسر عمرتان براي پارادايم مي‌شنويد. اما اين جمله زيبا براي يك برنامه‌نويس چه معنايي دارد؟

كامپيوترهاي اوليه توسط كدهاي باينري برنامه‌ريزي مي‌شدند و برنامه‌نويس، با ارسال دنباله‌اي از صفر و يك ها به پردازنده مركزي به‌طور مستقيم براي آن كامپيوتر برنامه‌نويسي مي‌كرد. با گذشت زمان، زبان‌هايي با سطوح بالاتر عرضه شدند.

اسمبلي، C و جاوا نمونه‌اي از زبان‌هاي نسل‌هاي مختلف هستند. با معرفي هر نسل، نحوه نوشتن برنامه و نگرش به مفاهيم نيز در آن تغيير مي‌يافت. ارائه شيوه‌هاي جديد توليد نرم‌افزار به اميد ايجاد راه‌هاي بهتر براي طراحي و پياده‌سازي يك برنامه، هنوز نيز ادامه دارد.

روش پايه‌اي برنامه‌نويسي را كه در بالا بيان شد، پارادايم برنامه‌نويسي مي‌نامند. در حقيقت، پارادايم‌ها چهارچوب كلي معماري يك برنامه و نحوه ارتباط اجزاي آن با يكديگر را مشخص مي‌كنند. با ذكر مثال‌هايي از پارادايم‌هاي مختلف، مفهوم را روشن‌تر مي‌كنيم.

شايد برنامه‌نويسي رويه‌اي (Procedural Programming) اولين پارادايم مطرح‌شده براي زبان‌هاي برنامه‌نويسي است. در اين پارادايم، اعمال، مرحله به مرحله توسط فراخواني رويه‌هايي كه براي انجام كارهاي مختلف نوشته مي‌شوند، انجام مي‌گيرند. اين مدل با مشخص كردن ترتيبي براي فراخواني رويه‌ها يكي‌يكي آن‌ها را اجرا مي‌كند و با اتمام كار هر كدام رويه بعدي اجرا مي‌شود.

در حقيقت، برنامه‌نويسي رويه‌اي، ادامه ايده كلي‌تري به‌نام برنامه‌نويسي امري (Imperative Programming) است. به‌طور ساده استراتژي اين مدل برنامه‌نويسي به اين صورت است كه تعدادي دستور وجود دارند كه بايد توسط كامپيوتر اجرا شوند. زبان‌هاي امري دقيقاً مانند اسمشان عمل مي‌كنند: اول اين كار را انجام بده، بعد آن را و... .

برنامه‌نويسي شيءگرا نيز در بيشتر مواقع مثالي از مدل امري است، زيرا در آن‌جا نيز روش كار برنامه عموماً به صورت اجراي سلسله‌اي از دستورها است. اگرچه معمولاً برنامه‌نويسي شيءگرا به صورت يك مدل جداگانه مورد بررسي قرار مي‌گيرد.

در مقابل مدل برنامه‌نويسي امري، مدل اعلاني (Declarative) قرار دارد. در اين مدل تمركز روي ماهيت چيزها است نه نحوه كاركرد آن‌ها. در مدل اعلاني آن‌چه اهميت دارد، توصيف اين است كه يك جزء برنامه چگونه است، نه اين‌كه چگونه ساخته مي‌شود. اگر برنامه خود را به دو قسمت منطق و كنترل تقسيم كنيد، در مدل اعلاني شما منطق برنامه خود را در اختيار مي‌گيريد و نگران آن‌چه در بخش كنترل اتفاق مي‌افتد، نيستيد. مثال بارز اين‌گونه زبان‌ها، HTML است2.

با توجه به نزديك بودن ساختار مدل اعلاني به ساختار رياضيات، اثبات درستي يك برنامه در اين مدل راحت‌تر انجام مي‌گيرد. به همين دليل، مدل اعلاني در نوشتن برنامه‌هايي كه بايد درستي آن‌ها به صورت يك حكم رياضي ثابت شود، كاربرد فراواني دارد.

عموماً زبان‌هاي مدل امري در محيط‌هاي كاري از محبوبيت بيشتري برخوردارند، اما نمي‌توان از تأثير مدل اعلاني در ساخت برنامه‌هاي علمي (به خصوص رياضي) به سادگي گذشت.

اين معرفي بسيار كوتاه از پارادايم‌ها فقط براي اين بود كه بدانيم آن‌ها واقعاً يكي نيستند! هر پارادايم، يك سبك برنامه‌نويسي و از آن مهم‌تر يك سبك نگرش را به دنبال دارد كه مي‌تواند تعاريف و اصول يك برنامه‌نويس را دگرگون سازد. پارادايم‌ها قطعاً به وجود نيامده‌اند كه معجزه كنند، بلكه قرار است كار را براي برنامه‌نويسان راحت‌تر سازند.

Aspect-Oriented Programming نيز، كه در واقع در ادامه مدل OOP عرضه شد، يك پارادايم برنامه‌نويسي است كه در ادامه به معرفي آن مي‌پردازيم.

وقتي OOP جواب‌گو نيست‌...

سناريوي زير را در نظر بگيريد:
فرض كنيد شما مسئول طراحي وب‌سايت براي يك شركت فروش آنلاين لباس شده‌ايد. اين سايت، مانند بيشتر سايت‌هاي دنيا دو بخش دارد: بخش نخست براي مشتريان كه مي‌توانند در آن اجناس را مشاهده كنند و آن‌ها را بخرند. بخش دوم نيز براي انجام كارهاي اداري خود شركت است كه فقط كارمندان خاصي به آن دسترسي دارند.

به‌عنوان مثال، اضافه كردن اقلامي به فروشگاه آنلاين يا بررسي كردن حساب بعضي از مشتري‌ها. شما و گروه برنامه‌نويسي با تلاشي قابل ستايش سايتي بسيار جامع و زيبا طراحي مي‌كنيد و آن را به شركت ارائه مي‌دهيد. اما روزي كه براي دريافت حق‌الزحمه خود مي‌رويد، متوجه مي‌شويد كه همه از دست شما عصباني هستند.

كارمندان نمي‌توانند البسه جديد را وارد فهرست فروشگاه كنند، كاربران سايت در حال افزايش اعتبار حساب كاربري خود به صورت دستي هستند! ايميل كاربران با فرمت اشتباه ذخيره شده است، پيگيري فروش روز‌هاي قبل در مواردي دچار مشكل مي‌شود و... . مشكل چيست؟

با افزايش پيچيدگي در يك برنامه نحوه كنترل شما روي روند رشد آن نيز دشوارتر مي‌شود. با اين كه ممكن است در بسياري از قسمت‌هاي برنامه كارهايي شبيه به هم انجام دهيد، اما جا انداختن يكي از اين كارها در هر يك از قسمت‌ها مي‌تواند كارايي كل برنامه شما را زير سؤال ببرد.

به مثال امنيت سايت فروش لباس باز مي‌گرديم. شما متوجه مي‌شويد با توجه به پيچيده شدن معماري سايت، بسياري از كارهاي ضروري را از قلم انداخته‌ايد.

در بسياري از جاها فراموش شده كه قبل از فراخواني روش‌هاي امن (Secure) هويت كاربر مشخص شود تا فرد غيرمسئول نتواند به اطلاعات محرمانه دسترسي داشته باشد. در بسياري از قسمت‌ها ورودي‌هاي اشتباهي كه كاربران به صورت دستي به سيستم مي‌دهند، تأييد اعتبار (Validate) نمي‌شوند و اين باعث بروز سردرگمي در سيستم مي‌شود.

در ضمن در بعضي از روش‌ها با توجه به زياد بودن كارهاي حاشيه‌اي (مانند ثبت كردن عمليات يك سيستم (Logging)، تراكنش‌هاي پايگاه‌داده و مديريت خطاها فراخواني روش‌هاي بعضي كارها از قلم افتاده‌است. در نتيجه سايت كاملاً كارايي خود را از دست داده و عملاً به يك سيستم خراب تبديل شده‌است.

از تمام اين موارد بدتر اين‌كه مشكلات شما به اينجا ختم نمي‌شود. وقتي درصدد اصلاح كدها بربياييد، مي‌بينيد اين‌كار خيلي دشوارتر از آن است كه تصور مي‌كرديد، زيرا كد هر قسمت آميخته‌اي از روند كاري اصلي برنامه (Business Logic) و كارهاي حاشيه‌اي مانند بررسي كردن امنيت و Logging و ... است.

جداسازي كد به صورتي كه بتوانيم بخش‌هاي مختلف را مورد بررسي قرار دهيم، كار بسيار مشكلي است و اين‌كار شما و گروه طراحي را دشوارتر از قبل مي‌كند.

مشكل سايت قسمت بالا مشكل تمام سيستم‌هاي شيءگرا است. به كارهاي مذكور كه براي تمام قسمت‌هاي سايت يكسان هستند، Cross-Cutting Concern گفته مي‌شود. در حقيقت، Cross-Cutting Concern ،Concernهايي هستند كه در چندين قسمت سيستم مورد توجه قرار مي‌گيرند (به‌عنوان نمونه، در مثال بالا بررسي امنيت و تراكنش‌هاي پايگاه‌داده و عمليات Logging).

اين Concernها معمولاً نمي‌توانند در يك ماجول به‌طور كامل كپسوله شوند. همان‌طور كه در مثال مذكور مي‌بينيد، بايد چندين فراخواني هر كدام از آن‌ها را در سيستم‌هاي امنيتي بالا قرار دهيم تا بتوانند آن‌ها را به قسمت برقراري امنيت متصل كنند. Cross-Cutting Concern جايي است كه ديگر مدل شيءگرا جواب كارآمدي به ما نمي‌دهد.

ادامه دارد
منبع: ماهنامه شبکه​

 

[کربلایی]

با جنبه برنامه بنویسید------قسمت دوم

با جنبه برنامه بنویسید------قسمت دوم

AOP؛ تولد يك مفهوم‌

در 1997 گريگور كيزالس و گروهش در زيراكس پارك مفهومي را معرفي كردند كه Aspect Oriented Programming يا به اختصار AOP ناميده مي‌شود. نام اوليه اين پروژه تجزيه و سرهم كردن (Decomposition & Weaving) بود، اما بعدها به AOP تغيير نام داد.

كيزالس درباره اين موضوع مي‌گويد: «اين نظر يكي از اعضاي گروه بود كه به درستي اشاره كرد تلفظ اين نام بسيار سخت است و در ضمن به نظر كمي زيادي 3Nerdy است.»

AOP، در حقيقت به‌عنوان يك مكمل براي برنامه‌نويسي شيءگرا عرضه شد تا ضعف‌هايي را كه در قسمت قبل به اختصار به آن اشاره كرديم پوشش دهد. كار اصلي AOP كار كردن با Cross-Cutting Concernها است. اما بياييد دقيق‌تر به مفهوم AOP بپردازيم.

شما براي نوشتن يك برنامه علاوه بر منطق كاري برنامه خود (كه جريان اصلي برنامه است)، بايد به‌طور هم‌زمان نگران بسياري از كارهاي حاشيه‌اي ديگر نيز باشيد. سؤال‌هايي از قبيل: «اگر يك قسمت از برنامه مطابق پيش‌بيني كار نكرد، چه كنم؟» يا «چگونه امنيت را به برنامه‌ام تزريق كنم؟» يا حتي «چگونه مديريت حافظه را انجام دهم؟»، سؤالاتي هستند كه هر برنامه‌نويس در طول يك پروژه بارها از خود مي‌پرسد. اما چگونه بايد با اين Concernها كنار آمد؟

شايد به ذهن همه ما اين فكر خطور كرده باشد كه چه خوب بود اگر كارهاي حاشيه‌اي و كد اصلي در دو فرآيند كاملاً جدا توليد مي‌شدند تا علاوه بر افزايش Modularization، بتوانيم نگراني‌هاي خود را تقسيم كنيم. در حقيقت اين ايده، فكر اصلي پشت سر AOP است.

البته انجام كارهاي حاشيه‌اي در پشت صحنه ايده‌اي قديمي‌تر از AOP است. به‌عنوان مثال، مي‌توانيد انجام مديريت حافظه و Garbage Collection توسط JVM در زبان جاوا را در نظر بگيريد. شما مي‌توانيد كد خود را بدون نگراني درباره مسائل مربوط به دو مورد ذكرشده در بالا بنويسيد، زيرا جاوا خود با آن‌ها كنار مي‌آيد.

انجام جداگانه كد و كارها باعث افزايش modularization مي‌شود و همه برنامه‌نويسان مي‌دانند كه اين افزايش مي‌تواند چه‌قدر دنيا را زيبا كند!

جان هانت مي‌گويد: «من هنوز مي‌توانم خودم را جلوي سورس كد يك برنامه تصور كنم در حالي‌كه سعي مي‌كنم منطق كاري پايه‌اي آن را از بقيه چيزهاي دور و برش مجزا سازم.» شايد شما هم در غم او شريك باشيد. درك سازوكار اصلي كاركرد يك برنامه، موضوع بسيار مهمي است كه معمولاً بسيار سخت انجام مي‌گيرد.

زيرا تمام كد اصلي برنامه با جزئيات حاشيه‌اي (البته نه لزوماً از نوع پيش‌پا افتاده) مخلوط شده‌است كه علاوه بر مشغول ساختن ذهن كدنويس و كند كردن فرآيند عيب‌يابي، باعث مي‌شود تا درك روند كاري اصلي كد نيز براي كسي كه سعي در فهم آن دارد، بسيار مشكل شود.

اما راه حل گروه كيزالس براي اين موضوع چه بود؟ چيزي كه آن‌ها عرضه كردند مي‌توانست Cross-Cutting Concernها را به صورت يك ماجول جداگانه مورد بحث قرار دهد. ماجولي كه علاوه بر عمليات اصلي كه بايد انجام دهد، در برگيرنده شرط اجراي اين Concernها نيز است.

بگذاريد با ذكر يك مثال موضوع را مشخص كنيم. به همان بحث امنيت باز مي‌گرديم. در مدل شيء‌گرا راه‌حل ما ساختن يك كلاس (يا يك روش در يك كلاس) براي بررسي بحث دسترسي كاربر موردنظر بود. پس از ساخت يك ماجول براي بررسي، با اضافه كردن عبارت‌هاي فراخواني آن در قسمت‌هاي مختلف برنامه، كار را تكميل مي‌كنيم.

در حقيقت، روند كاري در مدل شيء‌گرا در دو جا دنبال مي‌شود. يكي كلاس يا روشي كه براي بحث امنيت نوشته‌ايم،‌ يكي هم مكان‌هاي فراخواني آن از كد اصلي برنامه.

اما راه‌حل AOP متفاوت است. در AOP دو مكان قبلي (ماجول امنيت و مكان فراخواني) تقريباً با يكديگر تركيب مي‌شوند. به اين ترتيب كه شما كد مربوط به Concern (در مثال ما چك كردن امنيت) را در يك ماجول جداگانه قرار مي‌دهيد و سپس در همان ماجول شرط‌هاي فراخواني اين كد را ذكر مي‌كنيد (به‌عنوان مثال، درباره بحث موردنظر ما بايد بررسي هويت در مواردي انجام شود كه يك روش امن فراخواني مي‌شود).

به اين ترتيب، تمام روند كاري Cross-cutting Concernها از سازوكار اصلي برنامه مجزا مي‌شوند. كاملاً مشخص است كه اين جدايي مي‌تواند چه مزيت‌هايي را براي سيستم به ارمغان بياورد. به‌عنوان مثال، مي‌توان اين دو بخش كد (كد اصلي و Cross-cutting Concernها) را به دو گروه مختلف برنامه‌نويسي واگذار كرد يا حتي درباره خود Cross-cutting Concernها مي‌توان هر بخش را به خبره آن كار سپرد. مثلاً بخش بررسي كردن امنيت به متخصصان امنيت يا بخش تراكنش‌هاي پايگاه‌داده به متخصصان آن.

شايد باز هم اصرار كنيد كه تمام اين كارها با مدل شيءگرا نيز قابل دسترس بود (بحث كامل‌تري درباره اين مقايسه در بخش آخر مقاله آمده است). البته درست مي‌گوييد! اما توجه داشته باشيد كه در يك مدل شيء‌گرا برنامه‌نويس بايد از نكات زير آگاهي داشته باشد:

1- برنامه‌نويس بايد از وجود چنين كلاس‌هايي كه براي هماهنگ كردن اين Cross-cutting Concernها ساخته شده است، خبر داشته باشد.

2- بايد Specification دقيق آن كلاس را بداند تا بتواند از آن استفاده كند.

3- بايد بداند دستور مربوط به فراخواني روش‌هاي آن كلاس را كجاي كد اصلي قرار دهد.

در تمام اين سه مرحله امكان رخ دادن خطا وجود دارد. به خصوص در قسمت آخر كه فراموشي برنامه‌نويس براي فراخواني تمام روش‌هاي لازم از شايع ترين اشتباه‌ها است. اما با استفاده از AOP، با توجه به جدا شدن دغدغه‌هاي برنامه‌نويسان اين دو بخش چنين مشكلاتي اصولاً مطرح نمي‌شوند (البته مشكلات ديگري مطرح مي‌شوند كه چند نمونه از آن‌ها در قسمت آخر مقاله مطرح مي‌شود).

با استفاده از AOP مي‌توانيم بدون تغيير كد اصلي، Concernهايي به آن اضافه كنيم كه رفتارهاي سيستم را تقويت كند. در بخش بعد به بررسي مفاهيم اصلي AOP مي‌پردازيم.

اين يك AOP است...

چه چيزي مُهر AOP را روي يك سيستم مي‌زند؟ مسلماً معيار طراحي يك سيستم براساس AOP، اين نيست كه سازنده آن اين‌گونه بگويد.

اين موضوع كه آيا يك پروژه از AOP استفاده مي‌كند يا خير، به مكانيزم كاري آن پروژه و ماهيت نيازهاي آن بستگي دارد. به‌عنوان مثال، كل عمليات مربوط به پرينت كردن يك سند را در نظر بگيريد. شما ممكن است در قسمت‌هاي مختلفي از برنامه خود عمليات پرينت كردن را نياز داشته باشيد. به اين ترتيب، بايد بارها روش‌هاي مربوط به آن را فراخواني كنيد. ممكن است با توجه به اين تعاريف شما پرينت را به صورت يك Concern در نظر بگيريد. اما آيا اين طراحي يك طراحي منطقي است؟

در تعريف Concernهايي كه در AOP مورد توجه قرار مي‌گيرند يك نكته فرعي وجود دارد و آن اين است: اين Concernها معمولاً به صورت يك ماجول جداگانه (در مدل هاي قبل از AOP) دسته‌بندي نمي‌شوند. اين تعريف جواب سؤال بالا را مشخص مي‌كند.

در مثال بالا روش‌هاي مربوط به عمليات پرينت كردن براي برنامه‌نويس كاملاً مشخص است و مطرح كردن اين نكته كه او ممكن است فراموش كند كه آن‌ها را فراخواني كند تا حدودي خنده‌دار به نظر مي‌آيد. پس چندان منطقي نيست كه پرينت كردن را به وسيله AOP پياده‌سازي كنيم.

عدم استفاده از AOP در مثال بالا بديهي بود، اما ايده پشت اين مطلب را مشخص مي‌كند. AOP بايد در مواردي به كار گرفته شود كه به آن نياز است. وقتي مكانيزمي كه وجود AOP را مي‌طلبد، موجود نيست مي‌توانيم خيلي راحت از پارادايم هاي ديگر استفاده كنيم. پس بايد قبل از استفاده از AOP نيازهاي يك سيستم را كاملاً تحليل كنيم تا لزوم يا عدم لزوم به كارگيري آن را مشخص سازيم.

در ادبيات AOP، تعاريفي رسمي‌تر از مفاهيم اوليه آن وجود دارد كه موارد استفاده AOP را روشن‌تر مي‌كند.

Quantification يا تعيين عناصر

Quantification ايده‌اي است كه در آن يك برنامه‌نويس مي‌تواند با نوشتن يك سري عبارت در قالب يك واحد و به صورت مجزا از بقيه سيستم، بسياري از جاهاي غيرمحلي برنامه را تحت‌تأثير قرار دهد. درباره AspectهاQuantification مي‌تواند به اين صورت معني شود كه توانايي Aspectها براي اثرگذاري در نقاط مختلف يك برنامه است.

Obliviousness يا فراموش‌كاري‌

Obliviousness بيانگر اين ايده است كه يك برنامه اطلاعي از اين كه يك Aspect كي و كجا اجرا مي‌شود، ندارد. نتيجه اين‌كه شما نمي‌توانيد با نگاه كردن به كد بگوييد كدام Aspect اجرا مي‌شود و اين باعث ارتقاي مفهوم جدا‌سازي مي‌شود.

تعريف Filman-Friedman

دو مفهوم ذكر شده در بالا (تعيين عناصر و فراموش‌كاري) از ديدگاه تعريف Filman-Friedman دو مفهوم لازم‌الاجرا در زمينه طراحي برنامه‌هاي Aspect Oriented هستند. در حقيقت، با توجه به اين تعريف هر طراحي بايد شامل هر دو ايده به‌طور كامل باشد.

هرچند خيلي‌ها اين دو تعريف را بسيار سخت‌گيرانه مي‌دانند، زيرا برنامه‌هاي بسياري با طراحي AOP وجود دارند كه تنها به خاطر جلوگيري از اختلا‌ط دو كد، يكي از آن‌ها Aspect محسوب مي‌شود كه اين طراحي لزوماً نقاط مختلف برنامه را مورد هدف قرار نمي‌دهد (مثال رعايت نشدن تعيين عناصر). همچنين در بعضي مواقع، برنامه‌نويسان AOP محل فراخواني Aspect را با علا‌متي خاص مشخص مي‌سازند (مثال رعايت نشدن فراموشكاري)​

ادامه دارد...

 

[کربلایی]

با جنبه برنامه بنویسید------قسمت سوم

با جنبه برنامه بنویسید------قسمت سوم

دو اصطلاح Tangling و Scattering

●‌ پراكندگي: (Scattering) پياده‌سازي يك Concern، پراكنده شده است هر گاه كد آن بين چند ماجول پخش شده باشد.
● پيچش: (Tangling) پياده‌سازي يك Concern، پيچيده شده‌است هر گاه كد آن با كد يك Concern ديگر مخلوط شده باشد.

پراكندگي و پيچش در Aspect Oriented به‌عنوان علائم يك Cross-Cutting Concern در نظر گرفته مي‌شوند. در حقيقت عموماً Concernهايي كه چنين خصوصياتي را در پياده‌سازي‌هاي غير AOP داشته باشند، مورد بحث قرار مي‌گيرند.

AOP در عمل‌

بايد اعتراف كرد كه با وجود ارزشمند بودن توضيحات و تئوري‌هاي برنامه‌نويسي، تا وقتي كه آن‌ها را در عمل، به وسيله برنامه‌نويسي مورد آزمايش قرار ندهيم، در حقيقت كار خاصي انجام نداده‌ايم. در ادامه سعي مي‌كنيم مفاهيم مطرح شده را به همراه كد آن مورد بررسي قرار دهيم تا علاوه بر معرفي و تعريف مفاهيم موجود در AOP، با نحوه به كارگيري آنان نيز آشنا شويم، اما قبل از هر چيز بايد به اين سؤال پاسخ دهيم كه كجا مي‌توانيم AOPبنويسيم؟

براي پاسخ دادن به اين پرسش، ابتدا بايد ببينيد AOP چگونه اجرا مي‌شود. براي نوشتن يك پروژه به صورت AOPشما ابتدا هر دو بخش كد خود را (اعم از روند كاري اصلي برنامه و كدهاي مربوط به Aspectها) به صورت جداگانه در يك زبان شيءگرا مي‌نويسيد و سپس موجودي به نام Aspect Weaver آن دو بخش را با يكديگر تركيب كرده و كد نهايي را مي‌سازد.

جداسازي كد اصلي و كد Concernها (كد اصلي نيازي به اطلاع از بخش Concernها ندارد) به افزايش قابليت استفاده دوباره‌ (Reusability) و قابليت نگهداري (Maintainability) پروژه كمك شاياني مي‌كند. شكل 1 نحوه كار Weaverها را نشان مي‌دهد.

دو نمونه بارز از ابزارهايي كه مي‌توان با استفاده از آن‌ها برنامه‌هاي Aspect-Oriented نوشت AspectJ و AspectWerkz هستند.

AspectJ يك Extension است كه براي زبان جاوا در زيراكس پارك و توسط گروه به‌وجود آورنده AOP نوشته شده‌است. اين Extension به دو صورت تنها و تعبيه شده در Eclipse IDE عرضه مي‌شود. AspectJ پتانسيل پشتيباني از مدلRT Weaver را نيزدارد، اما براي بهره بردن از توانايي‌هاي آن بايد از آن به‌صورت يك Compile-time Weaver استفاده كرد (هم‌اكنون به صورت Compile-time و loadtime عرضه مي‌شود).

Aspect Weaver !​

در حقيقت Aspect Weaver كد اصلي و كد Aspectها را به‌عنوان ورودي مي‌گيرد و محصول نهايي را توليد مي‌كند. توجه به اين موضوع ضروري است كه نگاه كلي به Weaverها مانند يك كامپايلر نيست، زيرا قرار نيست كه تمام كارهاي پيچيده‌اي را كه يك كامپايلر انجام مي‌دهد.

Weaver نيز در مورد تركيب دو بخش كد انجام دهد. در حقيقت، همان‌طور كه خود كيزالس هم اشاره مي كند، وظيفه Weaverها فقط Integration (مجتمع‌سازي) است.

تكنيك‌هاي اوليه Weaving به دو دسته عمده تقسيم مي‌شوند: Compile Time) CT) و Run-Time) RT Weaver)هايCT. همان‌طور كه از نامشان پيدا است، تمام كارهاي مربوط به تركيب كد را در زمان كامپايل انجام مي‌دهند و در حقيقت كد نهايي كه اجرا مي‌شود، محصول كامل است.

در مقابل RTها اين‌كار را در زمان اجرا انجام مي‌دهند و ايجاد ارتباط را تا آن وقت به تأخير مي‌اندازند. Weaverهاي CT با توجه به اين كه تمام فرآيند ايجاد ارتباط را در ابتداي كار و هنگام كامپايل انجام مي‌دهند بسيار سريع‌تر از RTها عمل مي‌كنند، اما در مقابل RTها هم اين مزيت را دارند كه در صورت تغيير كد Aspectها نيازي به انجام دوباره عمليات Weaving نيست و برخلاف CTها در Run-Time Weaver تغييرات در كد بدون نياز به هيچ كاري سريع منعكس مي‌شوند.

همان‌طور كه در بالا ذكر كرديم، تكنيك‌هاي Weaving ديگري نيز وجود دارند كه در واقع فضاي بين Compile-time و Run-time قرار مي‌گيرند. اين دو تكنيك Weaving را (post-compile time (binary و Load-time مي‌نامند.

Binary Weaving در حقيقت عمليات Weaving را روي byte code انجام مي‌دهد (پس از كامپايل). Load time Weaving نيز يك نوع binary Weaving است. با اين تفاوت كه عمليات Weaving را تا زماني كه يك كلاس به Class loader معرفي نشده است، به تأخير مي‌اندازد.

(اين توانايي مي‌تواند برخي از نقص‌هاي مدل Compile-time را برطرف كند، زيرا شما مي‌توانيد بدون كامپايل كردن دوباره كد اصلي خود (Aspect ،(Business Logicهايي به برنامه اضافه كرده و سپس آن‌ها را به پروژه اصلي لينك دهيد). در حقيقت، در اين مدل تا جايي كه ممكن است عمليات Weaving به تأخير مي‌افتد و تا مرحله Load شدن كلاس‌هاي موردنياز هيچ تركيبي انجام نمي‌شود.

AspectJ محيطي ساده و بسيار كارا دارد و هم‌اكنون محبوب‌ترين ابزار برنامه‌نويسي Aspect-Oriented است. نسخه‌هاي جديدتر AspectJ به‌طور كامل با محيط توسعه Eclipse هماهنگي دارند و مي‌توان از تمام امكانات Eclipse در مورد Aspect‌ها نيز سود برد.

توجه به اين نكته ضروري است كه AspectJ تغييراتي در Syntax زبان به وجود مي‌آورد كه اين موضوع مي‌تواند باعث بروز مشكلاتي شود (Eclipse با توجه به اضافه كردن Keywordهاي مربوط به برنامه‌نويسي AOP اين مشكل را ندارد).

اين مشكلات باعث شدند تا ابزارهاي ديگري به وجود آيند كه به اين تغييرات گرامري در زبان برنامه‌نويسي نيازي نداشته باشند. يك نمونه مشهور از اين زبان‌ها‌ AspectWerkz است. AspectWerkz در حال حاضر از هر سه مدل Compile-time ،Load-time و Run time استفاده مي‌كند.

خصوصيت بارز AspectWerkz اين است كه Syntax زبان را تغيير نمي‌دهد و در حقيقت تغييرات را با استفاده از Annotation انجام مي‌دهد كه به يك ساختار زباني جديد نيازي ندارد.

در حال حاضر، دو پروژه AspectJ و AspectWerkz با يكديگر تركيب شده‌اند تا بتوانيم از قابليت‌هاي هر دو به صورت هم‌زمان استفاده كنيم.

تمام اين مقدمه‌ها براي اين ذكر شد كه شما كمي بيشتر با نحوه عملكرد داخلي ابزارهاي توسعه برنامه‌هاي Aspect-Oriented آشنا شويد. در قسمت بعد وارد بخش كدنويسي مي‌شويم.

ادامه دارد...

 

[کربلایی]

با جنبه برنامه بنویسید------قسمت چهارم

با جنبه برنامه بنویسید------قسمت چهارم

كدنويسي در AspectJ

Annotation​

شايد تعريف كردن Annotation كمي دشوار باشد. در حقيقت آن‌ها برچسب‌ها و شايد پايگاه‌داده‌هايي هستند كه اطلاعاتي درباره برنامه شما مي‌دهند.

در حقيقت، Annotationها تغييري در Semantic زبان ايجاد نمي‌كنند، اما مي‌توانند براي ابزارهاي مختلفي كه در روند اجراي برنامه دخيل هستند، پيغام‌هايي در برداشته باشند.

در حقيقت، مي‌توان Annotationها را علامت‌هايي تلقي كرد كه كامپايلر آن‌ها را به‌عنوان متاديتا در جايي ذخيره مي‌كند. سپس VM (سرنام Virtual Machine) با ديدن آن‌ها تعيين مي‌كند كه چگونه رفتار بعضي از Elementهاي برنامه را تغيير دهد.

توضيح كامل Annotationها در اين مقاله نمي‌گنجد. پس به ذكر همين مقدمات بسنده مي‌كنيم.
در اين قسمت به بررسي پياده‌سازي مفاهيم مختلف AOP توسط AspectJ مي‌پردازيم. هر چند بررسي تمام خصوصيات AspectJ خود يك مقاله جداگانه مي‌طلبد، اما سعي مي‌كنيم تا مفاهيم اصلي پركاربرد را در نوشتن يك برنامه Aspect-Oriented مطرح كنيم. در شماره‌هاي آينده، به‌طور عميق‌تري به بررسي جنبه‌هاي عملي AOPمي‌پردازيم.


Join Point

Join Point، در حقيقت مفهوم جديدي نيست. ما از اين مفهوم قبلاً بارها استفاده كرده‌ايم ، فقط شايد اسمي براي آن نداشته‌ايمJoint Point .ها نقاط خوش تعريف خاصي در برنامه هستند. به‌عنوان مثال، نقطه فراخواني يا بازگشت متد.
Aspect

شروع كاري ما براي آوردن AOP به صحنه عمل كليدواژه Aspect است. Aspectها تقريباً مشابه كليدواژه class در نوشتن كدهاي معمولي شيءگرا هستند. هر Aspect بايد در يك فايل جداگانه كه نام آن با نام Aspect يكي است، تعريف شود:

يك Aspect مجموعه‌اي از point-cutها و Adviceها است.


Point-cut

در AOP شما نياز داريد نقاط خاصي را به‌عنوان نقاطي كه موجب فراخواني يك Aspect مي‌شوند، تعريف كنيد. اين كار توسط Point-cutها انجام مي‌گيرد. در حقيقت، Point-cutها يك مجموعه از Join Pointها را تعريف مي‌كنند و مي‌توانيم آن‌ها را به‌عنوان يك Query براي انتخاب joint pointها در نظر بگيريم.

در حقيقت، تعريف يك point-cut بيان‌كننده اين موضوع است كه join Pointهاي كد اصلي (Business Logic) در چه جاهايي قرار دارند. به زبان ساده‌تر point-cut شرايط نقطه‌هايي را تعريف مي‌كند كه بايد با رسيدن به آن‌ها در كد اصلي اين Aspect اجرا شود.

اين مكانيسم، به مكانيسم فراخواني روش بسيار شبيه است. در حقيقت، در اينجا point-cutها حكم يك روش و join point حكم نقطه‌اي است كه دستور فراخواني متد در آن قرار دارد.

به عنوان مثال:

اين Pointcut مشخص مي‌كند كه پس از اجراي متد از كلاس Data كه با Write شروع مي‌شوند و هيچ ورودي‌اي ندارند، اين Aspect فراخواني مي‌شود.
‌مي‌توانيم در يك Aspect چند pointcut داشته باشيم. كد پايين سه pointcut تعريف مي‌كند.

در كد بالا سه pointcut تعريف شده است.

PC1: وقتي متدي از كلاس Data كه با Write شروع مي‌شود و آرگومان String مي‌گيرد، فراخواني مي‌شود، pointcut PC1 رخ مي‌دهد.
PC2: با فراخواني هر متدي (هر نامي با هر ورودي‌اي) كه در داخل كلاس Data است pointcut PC2 رخ مي‌دهد.
PC3: با اجراي بدنه اصلي متد SecurityChecking ،pointcut PC3 فراخواني مي‌شود.

Advice

كد تكميلي كه به سيستم اضافه مي‌شود تا كارهاي مربوط به يك Concern را انجام دهد، Advice نام دارد. Adviceها در حقيقت همان قطعه‌كدهاي معمولي هستند كه حكم انجام عملياتي يك Concern را دارند.
هر Advice كاري را كه يك Aspect بايد در ازاي وقوع يك اتفاق خاص (pointcut) انجام دهد، مشخص مي كند. باز هم با تعبير متدگونه advice در واقع حكم بدنه متد را دارد (point-cut حكم اعلان متد را دارد).

كاري كه كد زير انجام مي‌دهد اين است كه قبل از اجراي هر متدي از كلاس Data كه با Write شروع مي‌شود و هيچ ورودي ندارد، هويت كاربر حال حاضر بررسي مي‌شود.

Adviceها به سه نوع تقسيم مي‌شوند:

1-Before: اين Adviceها بلافاصله بعد از اين‌كه يك join point اتفاق افتاد و پيش از اين كه برنامه ادامه يابد اجرا مي‌شوند. به‌عنوان مثال، اگر join point فراخواني يك ljn باشد، بلافاصله پس از فراخواني ljn (و پيش از اجراي بدنه آن و برگرداندن يك مقدار)، قطعه كد Advice اجرا مي‌شود.
2- After: اين نوع Advice نيز همان‌طور كه از نامش پيدا است، درست برخلاف Before عمل مي‌كند. Adviceهاي نوع After پس از پايان اجراي join point، اجرا مي‌شوند. در حقيقت، در مثال بالا (فراخواني متد) يك Advice از اين دسته پس از پايان روند كاري متد (برگرداندن مقدار- وقوع exception) اجرا مي‌شود.
3- Around: اين نوع بسيار جالب از Adviceها مي‌توانند كلاً اجراي join point را ناديده بگيرند. در حقيقت Adviceهاي نوع Around دقيقاً به جاي join point اجرا مي‌شوند (اجراي join point ناديده گرفته مي‌شود و به جاي آن اين Advice اجرا مي‌شود). معني اين امر درباره متدها اين است كه بدنه اصلي متد اجرا نمي‌شود و به جاي آن كد موجود در Advice اجرا مي‌شود.

يك كد تركيبي‌

كد زير تركيبي از سه pointcut و سه Advice را نشان مي‌دهد.

كد زير نيز كد كلاس Data است كه شامل روش main نيز است.

پس از كامپايل و اجراي Data خروجي زير را دريافت مي‌كنيم:

 

[کربلایی]

با جنبه برنامه بنویسید------قسمت پنجم

با جنبه برنامه بنویسید------قسمت پنجم

به ترتيب خروجي‌ها دقت كنيد. در PC1 نحوه مشخص كردن آرگومان ورودي متد و استفاده از آن را مشاهده مي‌كنيد. در PC2 مطابق تعريف تمام پيغام‌هاي Logging همان‌طور كه در كد pcAspect2 تعريف شده بود، بعد از اجراي تمام متدها چاپ شده است.

در PC3 نحوه استفاده از شيء كلاس مبدأ را مشاهده مي‌كنيد. در ضمن كد متد SecurityChecking در كلاس Dataاصلاً اجرا نشده است، زيرا ما Advice‌اي را كه بايد درباره اين متد اجرا مي‌شد، around در نظر گرفته‌ايم و همان‌طور كه در بالا ذكر شد Adviceهاي نوع around كلاً اجراي عادي join point را متوقف مي‌كنند.

احتمالاً با بررسي اين كد، متد كار Adviceها و point-cutها تا حدود زيادي براي شما روشن شده‌است. البته پياده‌سازي‌هاي اين مفهوم ريزه‌كاري‌هاي بسيار پيچيده‌تري نيز دارند كه در اين مقاله نمي‌گنجد.

Inter-type Declaration

Inter-type Declaration امكان جالبي است كه به برنامه‌نويس اجازه مي‌دهد ساختار elementهاي برنامه را در صورت اجرا شدن يك Aspect تغيير دهد، اما تغيير ساختار به چه معنا است؟

- اضافه كردن متد، Constructor يا Field به ديگر Typeهاي برنامه (كلاس يا Aspectهاي ديگر)
- اضافه كردن يا تغيير اينترفيس‌ها و كلاس‌هاي والد تعيين شده براي Typeهاي ديگر
- تغيير حالت exceptionها از checked به unchecked
- ‌اضافه كردن warningهاي دلخواه و... .

در حقيقت، با استفاده از اين توانايي يك Aspect مي‌تواند به‌طور كامل وظيفه تعريف، نگهداري و اجراي elementهاي مورد استفاده خود را بر عهده بگيرد و اين موضوع باعث مي‌شود تا تمام موضوعات مربوط به Aspectنويس در همان فايل aspect خلاصه شود.

نوشتن كدي كه از Inter-type Declaration عموماً چيز جديدي در بر ندارد و در بيشتر موارد مانند روش كلاسيك كد نوشتن ما است. به‌عنوان مثال، كد زير به ترتيب يك Field و يك متد براي كلاس AirPlane تعريف مي‌كند.

قطعه كد زير نيز يك‌ Constructor دو Argumentي براي كلاس AirPlane تعريف مي‌كند.

كد زير نيز كلاس والد كلاس AirPlane را كلاس SomethingFly تعيين مي‌كند.

چگونه اين‌ها را اجرا كنيم؟

اجراي يك برنامه نوشته شده تحت AOP در AspectJ با اجراي يك برنامه معمولي جاوا چندان تفاوتي ندارد. ابتدا نحوه اجراي يك برنامه را كه براي Weaving از تكنيك Compile-time استفاده مي‌كند، نشان مي‌دهيم.

به‌طور كلي براي كامپايل كردن اين برنامه‌ها، AspectJ دستور ajc را در نظر گرفته است. ساده‌ترين نوع كامپايل به صورت زير است.

براي اجراي برنامه نيز نبايد مشكلي داشته باشيم. زيرا تركيب ‌(Weaving) بين Aspect و كد اصلي انجام شده است و ما هم‌اكنون يك فايل class. كامل در اختيار داريم. پس مي‌توانيم به سادگي آن را اجرا كنيم.

مدل Load-time

اكنون سعي مي كنيم با ذكر يك مثال، نحوه اجراي يك برنامه به صورت Load-time و اثرات آن را مشاهده كنيم.
كد ارائه‌شده در بخش <يك كد تركيبي> در قسمت قبل را در نظر بگيريد. فرض كنيد مي‌خواهيم يك Aspect ديگر به نام «pcAspect3» داشته‌‌باشيم. «pcAspect3.java» به صورت زير در نظر گرفته مي‌شود:

براي اضافه كردن aspect2 به پروژه مي‌توان دو كار انجام داد:

1- مانند قبل عمل مي‌كنيم و سه فايل data و pcAspect2 و pcAspect3 را با يكديگر كامپايل مي‌كنيم. عمليات Weaving به صورت Compile-time انجام مي‌شود و با اجراي كلاس Data نتيجه موردنظر را دريافت مي‌كنيم.

2- از ‌load-time Weaving استفاده كنيم (براي تعريف load-time Weaving به كادر Aspect Weaver مراجعه كنيد).

اصولاً در بعضي موارد ممكن است كامپايل كردن دوباره تمام پروژه بسيار هزينه‌بر باشد. با استفاده از load-time weaving نيازي به كامپايل كردن دوباره هيچ‌كدام از فايل‌هاي قبلي نيست. بلكه ما فقط كلاس فايل جديدمان را به بقيه فايل‌ها اضافه مي‌كنيم، سپس با اجراي دوباره پروژه تمام تغييرات لازم خود به خود، اعمال مي‌شود.

اما انجام اين كار به چه شكل است؟

همان‌طور كه ذكر شد ما بايد به نحوي بعد از كامپايل فايل اصلي يك Aspect را به آن معرفي كنيم.
اين اعلام به وسيله META-INF/aop.xml (فايل aop.xml درون دايركتوري META-INF) انجام مي‌گيرد. فايل aop.xml مي‌تواند به روش‌هاي مختلفي ايجاد شود. استفاده از دستور زير به هنگام كامپايل فايل اوليه يك زير دايركتوري در دايركتوري فعلي، META-INF/aop.xml را ايجاد مي‌كند.

اين كار (ساخت فايل aop.xml) به صورت دستي نيز مي‌تواند انجام شود. اكنون بايد كد جديد خود را به قسمت اصلي برنامه اضافه كنيم. براي اين كار ابتدا كد جديد را به همان روش هميشگي كامپايل مي‌كنيم.

اعلان Aspectها در فايل aop.xml بسيار ساده است. فقط كافي است aop.xml را به صورت زير اصلاح كنيم.

اكنون با اجراي Data هر دو Aspect در پروژه اثر مي‌كنند. توجه كنيد كه در اينجا ديگر نمي‌توانيد از جاوا براي اجراي Data استفاده كنيد، زيرا در اينجا عمليات Weaving در هنگام Load شدن كلاس‌ها و بعد از اجرا انجام مي‌شود. پس بايد از دستور مخصوص اجرا به‌صورت Load-time Weaving استفاده كنيد.

اين دستور aj5) aj براي Java5) است.

 

[کربلایی]

با جنبه برنامه بنویسید------قسمت آخر

با جنبه برنامه بنویسید------قسمت آخر

و اما بعد...

اما سرنوشت AOP به كجا مي‌انجامد؟ در طول ساليان اخير ايده‌هاي مختلفي براي ايجاد يك پارادايم برتر ارائه شده‌است، اما همچنان مدل شيءگرا، به‌عنوان يك 4Silver Bullet براي عرصه پارادايم‌ها باقي مانده و سال‌ها است كه محبوب‌ترين شيوه توليد نرم‌افزار است.

AOP در تقابل با برنامه‌نويسي شيءگرا قرار نمي‌گيرد، اما همچنان عده‌اي با ترديد به توليد كيزالس و گروهش مي‌نگرند و استفاده از آن در مقياس وسيع را نيازمند تحقيق و بررسي بيشتري مي‌دانند. در اين ميان، عده‌اي پا را از اين نيز فراتر مي‌گذارند و AOP را ايده‌اي ناكارآمد در عمل و غيرقابل استفاده براي پروژه‌هاي بزرگ مي‌نامند. البته در مقابل اين دسته، افرادي نيز وجود دارند كه AOP را انقلابي در زمينه پارادايم‌هاي برنامه‌نويسي معرفي و استفاده از آن را به شدت پيشنهاد مي‌كنند.5

اما از اين افراطي‌گري‌ها چيزي نصيب مهندسان نرم‌افزار نمي‌شود. هر نظري كه درباره AOP داشته باشيد، خواه طرفدار پر و پا قرص، خواه مخالف شديد يا يك آدم بي‌طرف، در تمام موارد چيزي كه وجود دارد اين است: AOP فقط يك پارادايم برنامه‌نويسي است.

قرار نيست با AOP مشكلاتي را حل كنيد كه قبلاً نمي‌توانستيد آن را حل كنيد يا به بيان ديگر قرار نيست اين پارادايم براي شما نرم‌افزارهايي بسازد كه قبلاً نمي‌توانستيد آن‌ها را بسازيد.

رايان گالبِك درباره اين موضوع مي‌گويد: «مطرح كردن اين واقعيت كه شما مي‌توانيد همچنان با OOP سر كنيد و Cross-Cutting Concernها را با آن پياده‌سازي كنيد، چيزي را عوض نمي‌كند. زيرا بر اساس تز چرچ/تورينگ6 شما مي‌توانيد تمام مباحث موجود در مدل شيءگرا را در قالب زبان‌هاي رويه‌اي يا حتي كد اسمبلي پياده‌سازي كنيد. توانايي اصلي‌اي كه AOP براي شما به ارمغان مي‌آورد Modularization بهتر است نه قدرت بيشتر!»

صحبت‌هاي گالبِك را مي‌توان به تمام پارادايم‌هاي برنامه‌نويسي تعميم داد. پارادايم‌هاي برنامه‌نويسي براي ما ناممكن را ممكن نمي‌كنند (يا برعكس). بلكه فقط كمك مي‌كنند تا هزينه توليد و نگهداري يك پروژه براي شما كاهش يابد.

جدا از تمام اين‌ها، بحث‌هاي انتقادي اصولي نيز درباره AOP و نحوه Modularization آن وجود دارد كه قابل تعمق است. اصولا ًدر يك سيستم AOP-based به يك برنامه‌نويس قدرت بسياري داده مي‌شود كه اين موضوع مي‌تواند علاوه بر اثرات مفيد، مشكلاتي را نيز براي سيستم ايجاد كند.

توانايي ايجاد تغييرات كلي در سيستم توسط برنامه‌نويسي كه مسئوليت نوشتن كدهاي مربوط به يك Aspect را برعهده دارد مي‌تواند اثرات زيان‌باري روي كارايي كل سيستم شما بگذارد. Andres Hejlsberg معمار زبان #‌C، با وجود اين كه ايده AOP را ايده‌اي قابل تقدير و مستعد بررسي و تحقيق بيشتر مي‌داند، اما نگراني‌اش را از بابت قدرت زياد برنامه‌نويس، پنهان نمي‌كند:

«من هنوز نگراني‌هاي اساسي درباره Aspectهايي كه قدرت استدلال شما درباره كد خودتان را دچار مشكل مي‌كند، دارم. دليل بروز اين نگراني به اين موضوع برمي‌گردد كه افراد مي‌توانند به هر بخش كد شما كه مي‌خواهند، چيزهايي بيافزايند. بله به هر بخش كد و اين مي‌تواند باعث ايجاد يك 7Side effect شود. اين كار شما استدلال در مورد كدتان را بسيار مشكل مي‌كند».

در حقيقت، بيشتر نگراني‌ها درباره AOP به دو موضوع پيچيده بودن استدلال و تأثيرات ناخواسته زيان‌بار نويسنده Aspect برمي‌گردد. هرچند كه ابداع‌كنندگان AOP ادعا مي‌كنند كه با استفاده از AOP و به دليل تجمع كل جريان كاري Cross-Cutting Concernها در يك فايل، توانايي استدلال در مورد كد بالا مي‌رود، اما بايد پذيرفت كه اشكالات مطرح شده كاملاً قابل وقوع است و بايد درباره آن تصميماتي اتخاذ شود.

علاوه بر اشكالاتي كه ممكن است از طرف برنامه‌نويسي كه Aspectها را مي‌نويسد پيش آيد، برنامه‌نويس بخش اصلي نيز ممكن است با تغيير join pointهاي پيش‌بيني شده (مثلاً با تغيير نام آن‌ها) باعث ايجاد مشكلاتي شود كه برنامه‌نويس Aspect از آن بي‌خبر است.

اين دسته از نگراني‌ها درباره عدم هماهنگي بين برنامه‌نويسان بخش‌هاي مختلف و توانايي اثرگذاري بالا در يك سيستم، دغدغه اصلي مهندسان نرم‌افزاري است كه به AOP مي‌انديشند. تمام اين موارد، اين واقعيت را بيشتر نمايان مي‌سازد؛ برنامه‌نويساني كه از AOP استفاده مي‌كنند بايد از تمام پتانسيل‌هاي آن اطلاع كامل داشته باشند تا بتوانند برنامه‌هايي به دور از مشكلاتي كه در بالا ذكر شد، ايجاد كنند.

در شماره‌هاي بعد به‌طور تخصصي‌تري به AOP مي‌پردازيم و سعي خواهيم كرد جنبه‌هاي عملي آن را بيشتر بيان كنيم.

پي‌نوشت:

1- توماس كوهن- ساختار انقلاب هاي علمي‌
2- با توجه به تقابل مفهوم اعلاني و امري، در تعريفي كلي‌تر كليه پارادايم‌هايي را كه زيرمجموعه زبان‌هاي امري محسوب نمي‌شوند، جزء دسته اعلاني‌ ‌به حساب مي‌آورند.
3- معادل فارسي Nerd احتمالاً چيزي مانند عشق كامپيوتر يا به معناي دقيق‌تر خوره كامپيوتر مي‌شود.
4- اشاره به يك فناوري (يا اصولاً يك راه‌حل) كه به‌عنوان راه‌حل تمام و كمال براي يك حوزه مطرح مي‌شود.
5- در واقع انتظاري جز اين نيز نمي‌رود. اين فرآيند درباره تمام فناوري‌هاي جديد اتفاق مي افتد (همان طور كه در مورد OOP نيز در بدو ايجاد مطرح مي‌شد) و خارج از كنترل ما است.
6- اشاره گالبك به توانايي تبديل هر عمليات محاسبه‌اي توسط كامپيوتر به يك مسئله تحت ماشين تورينگ است.
7- .Side Effect: اشاره به تغييراتي دارد كه يك function يا expression ممكن است علاوه بر برگرداندن يك مقدار در State سيستم انجام دهد. اين تغييرات مي‌تواند موجب ناهماهنگي هاي زيادي شود. مي‌توانيد آن را دست كاري ناخواسته متغيرهايي از برنامه در نظر بگيريد كه توسط ماجول‌هاي مختلفي مورد استفاده قرار مي‌گيرند.
منابع:

http://www-106.ibm.com/developerworks/rational/library/2782.html-
http://www.theregister.co.uk/2006/10/26/aspects_java_aop-
http://home.comcast.net/~refilman/text/oif/aop-is2.pdf-
http://www.ibm.com/developerworks/rational/library/mar06/pollice/index.html-
http://www.developer.com/design/article.php/3308941​

 

[arosak]

طراحي نرم‌افزار از سال‌ها پيش در محافل محققان و مهندسان نرم‌افزار مورد بحث است. معمولاً بحث در مورد اين موضوع است كه طراحي سيستم نرم‌افزاري بر اساس سورس‌كدهاي نرم‌افزار استوار است و دياگرام‌ها و طرح‌هاي ابتدايي مي‌تواند در پياده‌سازي نرم‌افزار به ما كمك كند، ولي نمي‌توان گفت تمامي مراحل طراحي يك نرم‌افزار به آن دياگرام‌ها وابسته است. در واقع اين بحث بيان مي‌كند كه سورس‌كدهاي برنامه از دياگرام‌هاي UML مجزا نيست.

اگر تا به حال در تيم‌هاي نرم‌افزاري حضور داشته‌ايد و پروژه‌هاي نرم‌افزاري پياده‌سازي نموده‌ايد، حتماً با اشكالاتي، برخورد كرده‌ايد. اگر خيلي خوش‌شانس باشيد، در شروع پروژه مشتري يا همان كلاينت، اطلاعات دقيقي را از سيستمي كه نياز دارد در اختيار شما قرار خواهد داد. اگر خيلي زرنگ و باز خوش‌شانس باشيد، در همان جلسه اول مصاحبه با مشتري مي‌توانيد تصويري كلي از نرم‌افزاري كه قرار است تهيه شود را در فكر خود تجسم كنيد و شروع به طراحي و پياده‌سازي قسمت ابتدايي برنامه نماييد. با اين حال صبر كنيد؛ انگار با مشكلي روبه‌رو شده‌ايد! بله كوچك‌ترين تغييري از طرف مشتري تمام برنامه شما را با مشكل روبه‌رو مي‌سازد و پروژه شما دچار تغييراتي مي‌شود. از جمله مشكلاتي كه ممكن است براي شما پيش بيايد، مي‌توان به موارد زير اشاره كرد:

- ممكن است ماجول‌هاي برنامه بسيار سخت طراحي شده باشند. در ابتدا برنامه‌نويسان كدهاي هر ماجول را بسيار منظم و قابل فهم براي ساير اعضاي تيم آماده مي‌كنند، ولي به مرور زمان و ايجاد تغييراتي در متن كدها، به كدهايي تبديل مي‌شوند كه فهميدن آن‌ها بسيار سخت خواهد بود.

- كدهاي نرم‌افزار ممكن است دچار تكرارهاي غيرضروري شوند و قطعه‌اي از كد چندين بار در طول برنامه تكرار شود كه در نتيجه باعث سردرگمي برنامه‌نويسان تيم خواهد شد و طبيعتاً تغييرات در برنامه را با مشكلاتي رو‌به‌رو خواهد كرد. مثلاً تصور كنيد كه در برنامه با اشكالي روبه‌رو شده‌ايد و آن را مرتفع كرده‌ايد، ولي وقتي برنامه را مجدداً كامپايل مي‌كنيد، متوجه مي‌شويد برنامه باز اشكال دارد. در نتيجه مجبور مي‌شويد تمام قسمت هايي را كه اين اشكال در آن وجود دارد، اصلاح كنيد.

- كدهاي برنامه ممكن است داراي اجزايي باشند كه جز افزودن پيچيدگي به برنامه سود ديگري نداشته باشند. اين اشكال معمولاً وقتي پيش ميآيد كه برنامه‌نويسان پروژه امكاناتي كه احتمال مي‌دهند در آينده به آن نياز است را از ابتدا در برنامه قرار مي‌دهند كه باعث پيچيدگي در متن برنامه خواهد شد.

- يكي از اشكالات ديگري كه ممكن است در پروژه‌هاي نرم‌افزاري پيش آيد اين است كه وقتي برنامه‌نويسان با اشكال يا تغييري در برنامه مواجه مي‌گردند، بيش از يك راه‌حل براي آن تغيير پيدا مي‌كنند. برخي از اين تغييرات قالب طراحي نرم‌افزار را حفظ مي‌كند و برخي تنها با هك كردن سورس‌كدها اين تغيير را به وجود مي‌آورند و اين كار باعث به‌هم ريختگي و از هم گسيختگي طراحي يك نرم‌افرار و كدهاي آن مي‌شود.

- معمولاً تغييرات در برنامه باعث شكنندگي سيستم نرم‌افزاري مي‌شوند.

- معمولاً از آنجا كه هر تغيير در برنامه باعث تغييراتي در قسمت‌هاي مختلف برنامه مي‌شود، تغييرات در سيستم‌هاي نرم‌افزاري معمولاً دشوار است.

در مدل برنامه‌نويسي چابكانه اعضاي تيم با رعايت اصول اين مدل نرم‌افزاري نمي‌گذارند اشكالات ذكرشده در سيستم نرم‌افزاري به وجود آيد. در ادامه با ذكر يك مثال بسيار ساده، طراحي چابكانهِ اين مثال مورد بررسي قرار مي گيرد.

شكل 1​

تصور كنيد كه مدير شما صبح روز شنبه به دفترتان ميآيد و از شما مي خواهد برنامه‌اي ساده بنويسيد كه بتواند كاراكترها را از صفحه‌كليد به چاپگر كپي كند. تصور شما از اين برنامه ساده اين است كه مي توانيد آن را در عرض يك ساعت يا كمتر و با حداكثر ده خط كد بنويسيد، ولي ممكن است مسئوليت‌هاي ديگري جز اين كار داشته باشيد.

پس به مدير خود مي‌گوييد طي حدود دو هفته اين كار تمام خواهد شد. اولين كاري كه انجام مي‌دهيد اين است كه طرح اوليه اين برنامه ساده را ترسيم كنيد. طرح شكل 1 ممكن است طرح مورد نظر شما باشد.

به نظر ميآيد اين برنامه از سه قسمت تشكيل شده باشد: ماجول Copy كه دو ماجول ديگر را فراخواني مي‌كند. اين ماجول كاراكترها را از ماجول ReadKeyboard مي‌گيرد و آن‌ها را به ماجول WritePrinter مي‌فرستد. وقتي اين طرح را ترسيم كرديد، خيالتان راحت مي‌شود و به خود مي‌گوييد: اين برنامه خيلي ساده است و آن را حتي مي‌توانيد سريع به اتمام برسانيد و تحويل مديرتان بدهيد. همان موقع شروع به نوشتن ماجول Copy مي‌كنيد و كدي شبيه كد 1 را آماده مي‌كنيد.

کد1​

پس از نوشتن اين كدها، آن را كامپايل مي‌كنيد و متوجه مي‌شويد كه با موفقيت كامپايل مي‌شود. برنامه را آماده و در محلي ذخيره مي‌كنيد كه آخرين روز هفته به مدير خود تحويل دهيد و به او بگوييد: حتي يك هفته قبل از موعد برنامه آماده شده است. تا اينجا همه چيز به خوبي پيش رفته است.

بعد از چند هفته مدير به شما مراجعه مي كند و از شما مي‌خواهد برنامه كپي را تغيير دهيد. به نحوي كه بتواند اطلاعات را از Paper Tape Reader بخواند. عكس‌العمل شما نسبت به اين تغيير طبيعتاً اين خواهد بود كه اين كار وقت زيادي مي‌برد و در برنامه اوليه اين نياز كاربر در نظر گرفته نشده بود، ولي گريزي نيست و بايد اين كار انجام شود. پس يك آرگومان Boolean به ماجول Copy خود اضافه مي‌كنيم و به برنامه مي‌گوييم اگر اين مقدار صحيح بود، اطلاعات را از Paper Tape Reader بخواند وگرنه، مانند كد 1 از صفحه‌كليد بخواند.

كدهاي 2 قسمت اول، نتيجه اين تغييرات خواهند بود. پس از اعمال تغييرات اين كدها را كامپايل مي‌كنيد و به مدير خود تحويل مي‌دهيد. همه چيز به خوبي پيش مي‌رود، ولي چند هفته بعد باز مدير از شما مي‌خواهد كه برنامه را تغيير دهيد و كاري كنيد كه برنامه كپي خروجي خود را به Paper Tape Punch بفرستد. جواب احتمالي شما به مدير اين خواهد بود كه اين همه تغييرات روي طراحي تأثير خواهد گذاشت و باعث مي‌شود كار نگهداري نرم‌افزار با مشكل روبه‌رو شود، ولي آيا فكر مي‌كنيد اين استدلا‌ل براي مديرتان اهميت دارد؟

خير. از اين رو بايد همان چيزي را كه او مي‌خواهد آماده كنيد. در غير اين صورت، اين مسئوليت به فرد ديگري واگذار خواهد شد. از اين رو باز برنامه را تغيير مي‌دهيم و كدهاي 2 قسمت دوم را مي نوسيم.

كد 2 ​

اگر به ياد داشته باشيد در ابتداي اين نوشته اشكالاتي كه ممكن است در طراحي نرم‌افزار با آن روبه‌رو شويد ذكر شد. آيا فكر نمي كنيد كه برنامه Copy كه در مورد آن صحبت شد، از آن‌گونه نرم‌افزارها باشد؟

حال بياييم با توجه به اصول مدل نرم‌افزاري چابكانه برنامه Copy را بنويسيم. در طراحي چابكانه ممكن است اولين قدم نوشتن كدهاي 1 باشد (البته با استفاده از روش Test Driven Development)، ولي وقتي مدير از شما مي‌خواهد كه برنامه را طوري تنظيم كنيد كه بتواند از Paper Tape Reader بخواند بايد ابتدا طرح خود را با توجه به تغييري كه در نياز كاربر داده شده است، تغيير دهيد.

كد 3 برنامه كپي را با استفاده از مدل چابكانه نشان داده است. به جاي اين‌كه بخواهيم طرح خود را وصله‌كاري كنيم، تا نيازهاي جديد كاربر را تأمين نمايد، تيم برنامه‌نويس بايد طرح خود را به نحوي تنظيم كند كه اين قابليت و امكان را داشته باشد كه در آينده، در صورت نياز، تغيير كند.

طرح اوليه برنامه كه در شكل 1 نشان داده شده است، طرح قابل انعطافي نيست. چون كلاس‌ها مستقل نيستند و كلاس اصلي برنامه به كلاس‌هاي KeyboardReader و PrinterWriter وابسته است. با استفاده از مدل‌هاي Agile بايد اين وابستگي از ميان برداشته شود و در نتيجه تغييرات نتواند بر كلاس Copy تأثيرگذار باشد.


با استفاده از اصولي مانندOpen-Closed Principle) OCP، كه در قسمت‌هاي بعدي كدنبشته‌ها در مورد آن بحث خواهد شد)، مي‌توانيد طرح خود را به نحوي تنظيم كنيد كه تغييرات روي طرح شما تأثيري نداشته باشد. همان‌طور كه در كد 3 مشاهده مي‌كنيد، براي اين‌كه كلاس خود را در مقابل تغييرات مقاوم سازيم، از كلاس abstract استفاده كرده‌ايم و از الگوهاي Strategy نيز بهره جسته‌ايم.

كد 3 ​

در واقع طراحي چابكانه رويه‌اي است كه با استفاده از الگوها و اصول Agile Development ساختار برنامه را به نحوي طراحي مي‌كند كه برنامه در عين سادگي بتواند قابليت تغييرات احتمالي را نيز داشته باشد. در قسمت‌هاي بعدي كد‌نبشته‌ها اين اصول و الگوها مورد بررسي دقيق‌تر قرار خواهد گرفت.

منبع: ماهنامه شبکه

سلام
اول تبریک
بعدم مرسی از مطالب خوبی که گذاشتید (این تاپیک خیلی به درد من یکی میخوره)
ولی خواهشن اگه امکانش هست اون بحث مهندسی نرم افزار رو ادامه بدین وبه تمام جنبه های مهندسی نرم افزار(مثله هدف از تحلیل وطراحی یه سیستم وارزیابی وتعیین صحت نرم افزارو قابلیت اطمینان نرم افزار )بپردازید و بعد بریم سر مشکلات برنامه نویسی
و اگه شد در مورد هر کدوم مطلب بزارید (هر کی نخونه من یکی میخونم چون به رشتم مربوط میشه .البته من اومدم توی این تالار دنباله مطلبی در مورد فرستنده وگیرنده و چگونگی ارتباط این دو با هم و تبادل اطلاعات بینه این دو میگشتم که چیزی دستگیرم نشد که چشم به این تاپیک خورد )
بازم مرسی

 

[کربلایی]

آشنایی با مفهوم Uml

آشنایی با مفهوم Uml

1. تكامل :

زبان مدل های متحد (UML) زبانی برای معین كردن ، به تصویر كشیدن ، ساختن و مستند كردن محصولات سیستم های نرم افزاری ، سیستم های تجاری و سایر سیستم های غیر نرم افزاری است. UML برای نشان دادن یك همكاری عالی مهندسی علمی كه موفقیت آنها در مدل های سیستم های بزرگ و كامل ثابت شده است می باشد.


تعاریف UML عبارتند از :


: (Semantics) UML معنای تركیب توصیفات و معنایی UML را تعریف می كند .UML را می توان از لایه های معماری شده و سازمان داده شده درست شده و میان هر بسته ، عناصر مدل را در دوره هایی كه از تركیب انتزاعی خودش ( با استفاده از توضیحات دیاكرام كلاس ) ، نقش فرم های صحیح ( استفاده از متن و توضیح زبان ساختار ) و معناها ( با استفاده از متن های دقیق ) تعریف نمود . و شامل دو ضمیمه : عناصر استاندارد و فهرست لغات UML می باشد.


یاداشت های راهنمای UML : یاداشتها و تهیه مثالهای پشتیبانی را تعریف می كند . یاداشتهای UML تركیب گرافیكی برای توضیح معنایی توصیفات با UML MetaModel را نشان می دهد.

گسترش UML در پردازش های شئی گرا برای مهندسی نرم افزار و گسترش UML برای مدل های تجاری : توسعه UML ، توسعه پردازش ها است و دامنه معین در UML در تصویر دیاگرام در دوره های كه مكانیسم توسعه و پردازش خاص دارند را شامل می شود.

OCL در UML استفاده می شود كه برای تفكیك تعریف مستند قید شئی زبان معین (Object Constraint Language Specification) به كار می رو د.

1.1 معنی برای بینندگان :



این مستند شده از مجموعه معناهای اولیه جامع و خود مركب كه تعریف شده از معنا ها و یاداشت های UML است می باشد . اولین ملاقات از این مدارك مجموعه مركب از گروه مدیریت اشیاء ، سازمان دهی استاندارد ها ، نویسندگان كتاب ، فرهیختار و ابزار سازنده است .

نویشندگان آشنایی با آنالیز شئی گرا و طراحی متد ها را به عهده دارند .این مستندات ،برای متن های وابسته به مقدمه روی مدلهای اشیاء برای سیستم های پیچیده نوشته نشده اگر چه آنها می توانند در اتصال با مواد یا یا آموزش استفاده شوند. این مجموعه از مستندات بیشتر نیتشان در ضمیمه های اضافی كتاب ها ، دوره های آموزشی ، و ابزار مناسب در دسترسی به UML بكار می رود.

3. هدف UML اولین اهداف در طراحی UML عبارت بودند از :



1 ) آماده سازی كاربران خواندن برای استفاده ، توضیح زبان مدل تصویری چنان كه بتوان آن را گسترش و تغییر مدل داد .
2 ) میسر ساختن توسعه پذیری و مكانیسمهای تخصصی در برابر مفاهیم هسته داخلی
3 ) وجود استقلال از زبان های برنامه نویسی خاص و گسترش پردازش .
4 )آماده سازی یك قرارداد اساسی برای فهمیدن زبانهای مدل .
5) تفویت رشد از طرف بازار ابزارهای مدلهای شئی گرا.
6) پشتیبانی سطح بالا از گسترش مفهوم از قبیل همكاری ها ، چهار چوب ها ، الگوها ، و اجزاء .
7) یكپارچكی بهترین تمرین است .

این هدف ها كه در زیر آمده اند قابل بحث می باشند :
آماده سازی كاربران خواندن برای استفاده ، توضیح زبان مدل تصویری چنان كه بتوان آن را گسترش و تغییر مدل داد . این از مهمترین چیزهایی است كه استاندارد OOAD یك زبان مدل پشتیبانی می كند كه می توان " خارج از جعبه " در برابر وظایف عادی مدل هایی كه مقصود آنها عمومی می باشد استفاده كرد .
اگر استانداردهای انحصاری تهیه كنندگان به صورت meta-meta-description كه نیاز به تصیحح برای یك مجموعه خاص از مفهومهای مدل ، كه نمی خواهند به مقاصدی دست یابند كه كاربران اجازه تغییرات مدل بدون گم شدن اطلاعات یا كارهای بیش از حد به نقشه های مدل خودشان برای هر فرم جداگانه را تحمیل كنند.

UML محكم سازی یك مجموعه از مفهومهای درونی و اصلی مدل را كه عموما در سراسر متد ها و ابزار های مدل در حال جریان را به عهده دارد. این مفهومها در چندین یا بیشتر برنامه های كاربردی نیاز است .اگر چه هر مفهومی نیازمند هر فسمت از هر برنامه كاربردی نیست . ویژگی مفاهیم یك فرمت meta-meta-level برای كاربران مدل كافی نیست ، زیرا مفاهیم باید از مدل های واقعی رخدادی ، محكم ساخته شده باشند. اگر مفاهیم در چندین منطقه برنامه كاربردی چندین اساس را دار بودند سپس این قبیل قدرت كار كردن نزدیك تری دارند ، اما اساس داخلی یك مفهوم نیازمند بیشترین مناطق استفاده كه شبیه و دلیلی برای پشتیبانی مستقیم با استاندارد بدون نیاز به لایه های دیگر هستند .

میسر ساختن توسعه پذیری و مكانیسمهای تخصصی در برابر مفاهیم هسته داخلی . ما انتظار داریم كه UML خواهد توانست تصیحح نیاز های جدید را پوشش دهد و دامنه ها را معین نماید . در بعضی از مواقع ما نمی خواهیم در هسته داخلی مفاهیم عمومی برای دوباره تعریف كردن یا پیاده سازی هر منطقه اصلاحی نفوذ كنیم. از اینرو ما كم كم مكانیسمی را كه می بایست از پشتیبانی بواسطه قالب عمومی نسبت به نیاز های شروع برای پیاده سازی هسته OOA&D مفهومی خودشان انحراف داشته باشند را توسعه می دهیم .
هسته های مفهومی برای اینكه موفق باشند نمی بایست تغییرات داشته باشند . كاربرانی نیاز دارند كه توانایی های همچون زیر را داشته باشند .

1)ساخت مدلهای قابل استفاده مفاهیم هسته بدون استفاده از مكانیسم توسعه برای بیشتر كاربرد های عادی
2) اضافه كردن مفاهیم و یاداشت های جدید برای خارج نشدن پوشش هسته
3) انتخاب از میان مفاد گوناگون موجود در مفاهیم موجود ، زمانی كه توافقات جمع از بین نرفته باشد.
4) مفاهیم ، یاداشت ها و قیدها ی ویژه برای دامنه های كاربردهای خاص .


وجود استقلال از زبان های برنامه نویسی خاص و گسترش پردازش .UML باید و بتواند از همه زبانهای مستدل برنامه نویسی پشتیبانی نماید .آن همچنین باید و بتواند از متد ها و پردازش های گوناگون مدل های ساخته شده پشتیبانی نماید . UML بدون هیچ اشكالی می تواند از چندن زبان برنامه نویسی و متد های در حال گسترش پشتیبانی نماید .

آماده سازی یك قرارداد اساسی برای فهمیدن زبانهای مدل .زیرا كاربران می خواهند به صورت مرسوم از كمك(Help) برای زبانهایی كه نمی دانند استفاده می كنند . آن می بایست مختصرو مفید و معنای نزدیك را برساند یك كسری از این دو اندازه ای ضرر دارد كه آن را غیر مفید می سازد . به طور مرسوم نیازی به لایه لایه و غیر مستقیم بودن ندارد .
استفاده از ریاضی سطح پایین غیر صمیمی از دامنه مدل ها ، به طوری كه مجموعه ای از یاداشت های تئوری ، یا تعاریف موثرآن برای برنامه نویسی یك پیاده سازی یكسان باشد. UML یك معنی عادی را از یك فرمت ساكن از مدل استفاده شده در MetaModelكه در دیاگرامهای كلاس UML بیان شده آماده می كند .این قرار داد قابل دسترس پذیرفته شده ، محبوب و وسیع است كه برای فرمت های خاص از یك مدل و راهنمایی مستقیم برای پیادسازی فرمت های تغییر یافته می باشد .

UML اجبارا تركیبی خوب در زبان های جامع طبیعی به اضافه اشیاء زبان را بیان می كند .UML معانی قابل استفاده كه بیشتر در نهاد زبان مختصر و مفید است را بیان می كند. یك قرارداد نزدیكی كامل به زبان های خاص دارد به طوری كه Algol-68 به اندازه كافی به این مقصود نزدیك نبود

تقویت رشد از طرف بازار ابزارهای مدلهای شئی گراء . فعالیت فروشندگان برای پشتیبانی از استاندارد های زبان مدل و استفاده كردن بیشتر كاربران و ابزار ها ، مفید بودن این صنعت را نشان می دهد . ازمانی كه فروشندگان هنوز می توانند مقادیر را در ابزار پیاده سازی اضافه كنند فعالیت در آن ضرورت دارد. فعالیت در آن نیاز مند مدل ها، بدون گم شدن اطلاعات ، كه بتوانند میان كاربران و ابزار مبادله كنند. این فقط اگر ابزار روی فرمت و معنی با همه مفهوم مطابقت داشته باشند می تواند رخ دهد . استفاده از یك meta-level سطح بالا راه حلی مناسب نیست مگر اینكه نگاشت های مفهومی شامل استاندارد های سطح كاربر باشد.

پشتیبانی سطح بالا از گسترش مفهوم از قبیل همكاری ها ، چهار چوب ها ، الگوها ، و اجزاء . صراحت در تعریف معانی كه مفهوم آن ضرورتی برای همه استفاده كننده های شئی گرا و دوباره استفاده كردن دارد. و تعریف آن در میان مفاد همگانی از یك زبان مدل كه همكاری یكتا با زبان UML دارد .

یكپارچكی بهترین تمرین است . یك كلید محرك در میان UML در حال پردازش كه یكپارچگی دارد بهترین تمرین در صنعت ، شامل تغییرات وسیع مناظر اساسی روی سطوح مجرد ، دامنه ها ، معماری ، مراحل چرخه حیات ، تكنولوژی پیاده سازی و غیره است . بدرستی كه UML بهترین یك یكپارچگی برای تمرین است.
4 . میدان دید در UML :


زبان مدل متحد (UML) زبانی خاص ، ساخت یافته ، متجسم و مستند كه محصولی از سیستم نرم افزاری متمركز می باشد است .


اولین و بهترین ، زبان متحد مدل از مفاهیم Boochf, OMT و OOSE تركیب شده است. این نتایج منفرد ، عمومی ،و استفاده ای وسیع در زبان های مدل برای كاربران خود و سایر متد دارد .

دومین جلو برنده زبان های متحد مدل پوششی است كه می توانند با متد های موجود صورت پذیرد..برای مثال ،هدف نویسندگان UML مدلسازی همزمان سیستم های توزیع شده، برای مجاب كردن آدرسدهی كافی UML در دامنه های خودش است .

سومین ، متمركز شدن زبان متحد مدل روی استاندارد های زبان مدل و نه روی پردازش زبان است ، اگرچه UML می بایست در پردازش مفاهیم بكار رود ، این تجربه ای است كه چندین سازمان و دامنه های مسائل نیاز به پردازش های مختلف دارند . ( برا ی مثال ، گسترش پردازش برای نرم افزار های فشرده كوچك بسیار چالب است اما ساخت نرم افزار های فشرده كوچك با وسعت مختلف در سیستم های خودكار منوط به زندگی آن است .)

از اینرو اولین تلاش برای تمركز روی یك مدل برتر عمومی ( كه معانی متحد دارند ) و دومی روی یك یاداشت عمومی (كه یك فرد را برای ترجمه معانی خودش آماده می سازد) می باشد . نویسندگان UML گسترش پردازش روی راهبری UseCase ها، معماری مركزی ، و توسعه و تكراری را ترویج داده اند .
UML تعیین كننده یك زبان مدل ، كه متحد كننده اجتماع موافق شئی گرا روی هسته اصلی مدل های مفهومی می باشد . این اجازه انحراف توضیحات در دوره های كه مكانیسم توسعه دارند را می دهد . توسعه هایی كه UML دارد پیروی از قابل مشاهده بودن مفاهیم در طول اجرا است


این توسعه ها عبارتند از :


• آمادگی كافی معنی شناسی و نماد ها برای آدرسهای وسیع مركب از موضوعات مدل های همزمان در یك هدایت و سبك اقتصادی .


• آمادگی كافی معنی شناسی برای همانند سازی آدرس مورد انتظار مدل های نمونه آینده ، وابستگی ویژه برای تكنولوژی اجزاء ، محاسبه بدنه توزیع شده ، و اجرا پذیری .

• آمادگی مكانیسم توسعه پذیری به طوری كه یك پروژه مستقل بتواند MetaModel را برای كاربرد ها به سوی ارزش پایین گسترش دهد . ما نمی خواهیم كه كاربران نیاز داشته باشند كه خودشان را با UML MetaModel وقف دهند.

• آمادگی مكانیسم توسعه پذیری به طوری در آینده ، مدل های های در حال رشد به UML نزدیك باشند .

• آمادگی كافی معنی شناسی برای كمك كردن مدل در حال تفییر در میان انواع گوناگون از ابزار .

• آمادگی كافی معنی شناسی برای واسطه های معین در برابر مخازن برای تقسیم بندی و ذخیره سازی محصولات مدل.

اولین محصولات UML 3.1 :


چه چیزهایی محصولات اولیه UML هستند ؟ این پاسخ می تواند دو جنبه مختلف داشته باشد . UML خودش و آن چیزهای كه محصولات پروژه ها استفاده می كنند را تعریف می نماید.


تعاریف محصولات UML 3.1.1 :


اولین درك ، از محصولاتی است كه خودشان زبان مدل متحد را تشكیل داده اند ، این سند شامل مجموعه از معناها UML ،راهنمای یاداشت های UML ، و مستندات الحاقات UML ، به اضافه ضمایم است. بعضی از این مفاهیم در زیر آمده است . در اضافه این مستندات ، كتاب ها تدابیری كانونی برای درك ، مثال ها و اصطلاحات كاربردی عمومی ما هستند .



مفاهیم UML :

مدارك مفاهیم UML زبان تعریف استفاده از سه عبارت را بیان می كند :
تركیب انتزاعی دیاگرام كلاس های UML ،MetaModel های UML كه مفاهیم (MetaModel) ، ارتباطات ، و خود كنترل ها را نشان می دهد. كه مفاهیم شامل شده را بیان می كند.



قواعد فرم بندی خوب قواعد و خود كنترل كننده ها روی یك مدل صحیح تعریف می شوند ، قواعد ، توضیح به نثر درآمده انگلیسی و در یك زبان خود كنترل شئی(OCL) دقیق و مختصرشده است.OCL یك زبان ویژه كه منطقا ساده برای خواص یكسان معین از سیستم های كه شامل مجموعه ها و ارتباطات بین مجموعه ها است .
مفاهیم مفاهیم مدل برای به نثر در آوردن توصیحات انگلیسی به كار می رود ، این چشم اندازی برای تشكیل یك تعریف قرارداد در UMLاست. بیشتر قراردادها می توانند به صورت توضیحات ریاضی وارد شوند كه بیشتر افراد می توانند به طور مستقیم آن را درك نمایند.

یك متا مدل (MetaModel) زبانی برای مدلهای معین ، و در قالب یك شئی مدل است . در كلمات دیگر مدلی
برای مدل عناصر است . مقصود UML از متا مدل آماده سازی یك فرد ، عموم ، و تعریف توضیح از علم نحو و مفاهیم عناصر UML است . پیش از این متا مدل هایی ساخته شده بودند كه امكانی برای گسترش ترتیب روی مفاهیم غیر زوج از نمونه مفاهیم كه آن مفاهیم می خواهند بهترین منتقل كننده باشند را دارا بود.

اضافا ، متامدل برای به وجود آوردن امكان برای تیم هایی كه كاوش راه ها را در به وسیله زبان های مدل خیلی ساده، در كنار مفاد، عناصر یكی شده ، از زبان مدل متحد ساخته شده، بود ( برای مثال ، عموما میان مفاهیم كلاس ، الگو ها ، و قالب های مورد اسبفاده را پوشش می داد ) . نویسندگان انتظار دارند شخصا این متا مدل زوج بیشتر توصیفات جامع را توضیح دهند . استفاده از این مفاهیم تكنیكی قراردادی است .

سطح متا در یك مدل قدری قابل داوری است و توسعه دهنده UML از روی قصد مفاهیم سطح بالا را انتخاب می كند زیرا آن سطح ضروری است ، و مفاهیم قابل قبول برای طراحی سیستم های پیچیده ، سازگار با استفاده ، و ابزار قابل تعویض را ضروری می سازد.
عناصر استاندارد و فهرست UML دو ضمیمه هستند .


یاداشت های راهنمای UML :


راهنمای یاداشت های UML ، یاداشت ها UML و مثال های آماده آن را توضیح می دهد . یاداشت های گرافیكی و تركیب متنی بیشتر برای قسمت های قابل دید UML ( از دید خارجی ) كه افراد و ابزار ها سیستم مدل استفاده می كند است . اینها نشان دهنده سطح مدل كاربر ، كه كدام مفاهیم نمونه ای از متا مدل در UML است را بیان می كند. انواع دیاگرام استاندارد در قسمت 4.1.2 در پایین لیست شده اند . یاداشت های راهنما همچنین خلاصه ای از مفاهیم UMLهستند ; به هر حال مفاهیم مستندات UML محتوی تعاریف است..



الحاقات UML :


الحاقات تعریف شده توسط كاربران در UML قادرند در سرتا سر قالب ها ، مقادیر ضمیمه و خود كنترل استفاده شوند .


دو نوع الحاق در حال جریان به صورت زیر تعریف می شوند.
1 – پردازش شئی
2-مهندسی تجاری

كاربرد UMLوسیع است بدون الحاقات ، همینطور شركت ها و پروژه ها می توانند تعریف شوند الحاقات را فقط زمانی برای معرفییادداشت جدید و كلمات فنی ضرورتپیدا كردند می توان استفاده نمود. الحاقات نمی خواهند به صورت عمومی درك ، پشتیبانی و ترتیب دهنده برروی خود UML باشند .

در مراحلی كه برای كاهش عوامل اشتباه زا اطرافیك فروشندهپیادهساز در دوره های متناوب تعریف می شود كه دوره های آن عبارت است از :
گوناگونی UMLكه زبانی بامفاهیمخوش تعریف كه روی متا مدلیك متا مدل UMLساخته شده است.این می تواندویژگی متا مدل UMLبدونتغییرات هر UMLازمفاهیمیا دوباره تعریف كردن هر دور از آن باشد ( برای مثال ایننمی تواند در جزء ای كه ساخته شده دوباره تعریف گردد.)

الحاقات UML مجموعه ای از قبل تعریف شده از قالب ، مقادیر برچسب دار و خود كنترل ها و شمایلیادداشت ها كه توسعه ای مجتمع و تصیحح UML برای دامنه ای معین یا پردازشی ، برنامه ای الحاقی پردازشی دارند است












بر گرفته از سایت اینترنتی رشد

 

[کربلایی]

سلام
اول تبریک
بعدم مرسی از مطالب خوبی که گذاشتید (این تاپیک خیلی به درد من یکی میخوره)
ولی خواهشن اگه امکانش هست اون بحث مهندسی نرم افزار رو ادامه بدین وبه تمام جنبه های مهندسی نرم افزار(مثله هدف از تحلیل وطراحی یه سیستم وارزیابی وتعیین صحت نرم افزارو قابلیت اطمینان نرم افزار )بپردازید و بعد بریم سر مشکلات برنامه نویسی
و اگه شد در مورد هر کدوم مطلب بزارید (هر کی نخونه من یکی میخونم چون به رشتم مربوط میشه .البته من اومدم توی این تالار دنباله مطلبی در مورد فرستنده وگیرنده و چگونگی ارتباط این دو با هم و تبادل اطلاعات بینه این دو میگشتم که چیزی دستگیرم نشد که چشم به این تاپیک خورد )
بازم مرسی

سلام سحر خانوم
از لطف شما ممنونم، هدف من از این تایپیک ارائه مقالات و دست نوشته هایی گلچین در حوزه مهندسی نرم افزار هست، با این پیش فرض که مخاطب این نوشته قبلا با مباجث مطرح در این حوزه آشنایی داره!
امیدوارم برای خودم و بقیه دوستان مفید باشه
موفق باشید

 

[کربلایی]

تحليل، ارزيابي و ارائه الگويي براي انتخاب روش‌هاي سريع‌الانتقال ساخت نرم‌افزار--- بخش اول

تحليل، ارزيابي و ارائه الگويي براي انتخاب روش‌هاي سريع‌الانتقال ساخت نرم‌افزار--- بخش اول

1. مقدمه
امروزه يک عامل مهم براي سازمان‌ها و توليدكنندگان نرم‌افزار کاهش مدت زمان لازم براي ارائه سيستم‌هاي نرم‌افزاري به بازار و انعطاف‌پذيري در مقابل تغيير نيازها است (Abrahamsson et al. 2002, 2003; Laurie 2004; Voigt 2004) . برنامه‌ريزي جامع، مستندسازي از ابتدا تا انتها، طراحي‌هاي کامل و گسترده قبل از توليد، و زمانبربودن چرخه توليد که در روش‌هاي قديمي‌ و سنتي متداول است، جوابگوي چنين نيازمندي‌هايي نبودند. از اين رو براي پوشش چنين نيازمندي‌هايي محققان به دنبال ابداع روش‌هاي جديدي بودند که در آن‌ها، اعمال تغييرات و حجم فعاليت‌هاي مربوط به برنامه‌ريزي و تهيه مستندات و به طور کلي چرخه کاري، بهينه شود (Abrahamsson et al. 2003) . از اين رو روش‌هاي سريع‌الانتقال [3] در مقابل روش‌هاي قديمي‌ که سنگين‌وزن ناميده مي‌شوند مطرح شدند.
به دليل استقبال بسيار زيادي که از اين گونه روش‌ها شد، محققان به تحقيق گسترده در اين زمينه پرداختند و روش‌هاي جديد سريع‌الانتقال يکي پس از ديگري ابداع و معرفي شدند (Laurie 2004; Melnik and Maurer 2002; Abrahamsson et al. 2003) . ايده اصلي در وراي روش‌هاي سريع‌الانتقال اين است که پيش‌بيني آينده، کار بسيار دشوار و تغيير نيازها، يکي از امور اجتناب‌ناپذير است. بنابراين برنامه‌ريزي جامع اوليه در روش‌هاي سنگين‌وزن پاسخگو نيست. روش‌هاي سريع‌الانتقال با کاستن از حجم مستندات و طرح‌هاي زمانبر، امکان همکاري و مشارکت بين افراد تيم را فراهم مي‌کنند (Abrahamsson 2002) . بعلاوه اين روش‌ها باعث بازگشت زودهنگام سرمايه مي‌شوند، به طوري که با روش‌هاي سنگين‌وزن قابل مقايسه است. معيار موفقيت در روش‌هاي سريع‌الانتقال، تحويل زودهنگام و پيوسته نرم‌افزار است و بر آزمون دائم نرم‌افزار به منظور شناسايي سريع کاستي‌ها تأکيد شده است (Abrahamsson et al. 2002; Laurie 2004) .
هدف اين مقاله سازماندهي، تحليل و بررسي نقاط ضعف و قوت هر يک از روش‌هاي سريع‌الانتقال به همراه مقايسه جامع آن‌ها براساس 16 معيار مطرح‌شده در فرايند ساخت نرم‌افزار است. براي اين منظور يک چهارچوب تحليلي ارائه مي‌گردد که تحليلگران را در انتخاب روش‌هاي مختلف راهنمايي مي‌کند و موقعيت بهتري را براي درک ويژگي‌هاي مختلف هر يک از روش‌ها و نيز قضاوت در مورد آن‌ها ارائه مي‌دهد.
در بخش 2 روش‌هاي سريع‌الانتقال به اختصار معرفي مي‌شوند. در بخش 3 معيارهاي مقايسه و تحيل بررسي مي‌شوند. در بخش 4 روش‌هاي مطرح‌شده را از 16 منظر با هم مقايسه مي‌کنيم. بخش 5 نيز به نتيجه‌گيري حاصل از تحقيق اختصاص داده شده است.

2. معرفي روش‌ها
2-1. معرفي «ايكس‌پي» [4]
«ايكس‌پي» يکي از شيوه‌هاي ساخت نرم‌افزار است که بر پايه اصولي مثل سادگي, ارتباط با مشتري، و بازخورد استوار است (Beck 1999) . اين شيوه براي استفاده در تيم‌هاي کوچک که به توليد سريع نرم‌افزار در يک محيط تغييرپذير نياز دارند طراحي شده است (Abrahamsson et al. 2003) . ايده اصلي اين شيوه متعلق به «بك‌ كنت» [5] بوده و در حقيقت نتيجه تجارب وي در استفاده از شيوه‌هاي شيء‌گرا مي‌باشد. اين شيوه به توليدكنندگان اين امکان را مي‌دهد که بي هيچ ترديدي به تغيير نيازهاي مشتريان پاسخ دهند و به هدف اصلي خود (يعني رضايت مشتري) دست يابند و اين، عامل موفقيت «ايكس‌پي» است (Abrahamsson et al. 2002) . «ايكس‌پي» بر ساخت مبتني بر آزمايش نرم‌افزار استوار است و در آن به همه نقش‌ها از جمله مشتريان، توجه خاص مي‌شود و به عنوان يک اصل، بر تعامل و همکاري متقابل بين نقش‌هاي کليدي در توليد نرم‌افزار تکيه مي‌گردد و تلاش مي‌شود که محصول در حداقل زمان ممکن به مشتري تحويل گردد (Abrahamsson 2003) .​

2-1-1. فرآيند «ايكس‌پي»
چرخه حيات «ايكس‌پي» شامل پنج مرحله است: اکتشاف، برنامه‌ريزي، تکرار نسخه‌ها، توليد، نگهداري (Abrahamsson et al. 2002) .
در مرحله اکتشاف، مشتريان ويژگي‌هايي را که مايل‌اند در برنامه وجود داشته باشد در قالب يکسري «نكته برگ» [6] مي‌نويسند. در مرحله برنامه‌ريزي، نكته‌ها براساس اولويت مرتب مي‌شوند و يک توافق بر سر نسخه‌هاي کوچک اوليه حاصل مي‌شود. در مورد اولويت انجام کارها، مشتريان به صورت مستقيم دخالت مي‌کنند. مرحله تکرار نسخه‌ها، شامل چندين تکرار قبل از اولين نسخه است. مرحله توليد نيازمند آزمايش‌هاي اضافي کارآيي سيستم، قبل از تحويل اولين نسخه به مشتري است. در اين مرحله ممکن است نيازهاي جديدي کشف شوند که در مورد آن‌ها تصميم‌گيري مي‌شود. در مرحله نگهداري، بايد سيستم در حالت اجراي محصول نگه داشته شود و نسخه‌هاي جديد توليد شوند و کاربر مي‌تواند از نسخه‌هاي جديداً توليدشده استفاده کند. زماني چرخه خاتمه مي‌يابد که مشتري ديگر نيازي براي پياده‌سازي نداشته باشد. علاوه بر اين ممکن است به دليل برآورده‌نشدن نيازهاي مورد انتظار يا هزينه بالا, فرايند توسعه با شکست مواجه شود و وارد اين مرحله شويم (Pressman 2006, 225-240; Martin, Biddle, and Noble. 2004.) .​

2-2. معرفي «اف‌‌دي‌دي» [7]
اين روش مبتني بر توسعه تکراري با انتخاب بهترين و مؤثرترين فعاليت‌ها است و بر جنبه‌هاي کيفيتي تأکيد دارد . اين روش شامل نسخه‌هاي محسوس پيگيري دقيق پيشرفت پروژه است که در سال 2002 توسط «پالمر» [8] و «فلسينگ» [9] معرفي شد. اين روش تمام فرايند ساخت نرم‌افزار را پوشش نمي‌دهد و بيش‌تر روي دو مرحله- طراحي و پياده‌سازي- متمرکز مي‌شود (Palmer and Felsing 2002, 123-132, 201-209) . اين روش براي استفاده همراه با ديگر فعاليت‌هاي يک پروژه ساخت نرم‌افزار طراحي شده و هيچ مدل فرايندي خاصي را لازم ندارد (Coad, LeFebvre, and De Luca 2000, 5:167-190) .
فرايند ساخت نرم‌افزار شامل تکرارهاي بسيار کوتاه است و همه خواص مورد ساخت به صورت واضحي که براي کاربر قابل فهم است توضيح داده مي‌شوند (Palmer and Felsing 2002, 123-132, 201-209) . در هر زماني در طول پروژه مي‌توان تخمين زد که تا پايان کار چقدر فاصله داريم. اين کار توسط فراورده‌هاي زماني خاصي که در اين روش وجود دارند محقق مي‌شود (Abrahamsson et al. 2003) .​

2-2-1. فرايند «اف‌دي‌دي»
«اف‌دي‌دي» شامل پنج فرايند ترتيبي- توليد مدل کلي، ساخت فهرست امکانات، طرح‌ريزي براساس امکانات، و طراحي و ساخت براساس امکانات- است که از طريق آن‌ها فعاليت‌هاي طراحي و پياده‌سازي انجام مي‌شوند. قسمت تکراري فرايند «اف‌دي‌دي» (طراحي و ساخت) از توليد سريع‌الانتقال حمايت مي‌کند Laurie 2004) ).
مرحله توليد مدل کلي با ايجاد يک مدل سراسري، و زماني آغاز مي‌شود که متخصصان از نيازمندي‌هاي سيستم اطلاع کافي پيدا کرده باشند. دامنه سراسري به چندين دامنه مختلف تقسيم مي‌شود که براي هر يک از آن‌ها يک بازديد سريع با جزئيات زياد وجود دارد؛ سپس از اعضاي هر دامنه يک مدل شيئي اوليه تهيه مي‌کنند و مجموعه اين مدل‌هاي شيئي، مدل سراسري را تشکيل مي‌دهند (Abrahamsson et al. 2002) .
در مرحله ساخت، با بازنگري‌هاي سريع، مدل‌هاي شيئي و مستندات نيازمندي‌هاي سيستم، يک ليست جامع از خواص سيستم ايجاد مي‌شود. در مرحله طرح‌ريزي، يک طرح سطح بالا که در آن، مجموعه خواص براساس اولويتشان مرتب شده‌اند ايجاد مي‌شود (Laurie 2004) . در اين فرايند بايد زمان‌بندي صورت گيرد و جداول خاصي براي تحويل خواص ايجاد گردد. کلاس‌هاي شناسايي‌شده در فرايند طراحي مدل سراسري، در اين مرحله به يک توليدكننده خاص به نام صاحب کلاس تحويل داده مي‌شوند (Palmer and Felsing 2002, 123-132, 201-209) .
در مرحله طراحي و ساخت، يک گروه کوچک از مجموعه خواص براي پياده‌سازي انتخاب مي‌شوند و صاحبان کلاس‌ها يک تيم را براي پياده‌سازي اين خواص انتخاب مي‌کنند. اين مرحله يک فرايند تکراري است که در طول آن، خواص انتخاب شده پياده‌سازي مي‌شوند (Palmer and Felsing 2002, 123-132, 201-209) . هر تکرار بين چند روز تا دو هفته طول مي‌کشد. اين تکرار ممکن است شامل موارد طراحي, بازبيني طراحي, كد‌نويسي, آزمايش, يکپارچه‌سازي، و بازبيني کد باشد. در پايان هر تکرار يک محصول اصلي خواهيم داشت و کار با خواص جديد ادامه پيدا مي‌کند (Pressman 2006, 225-240) .​

2-3. معرفي «دي‌اس‌دي‌ام» [10]
در سال 1997 روش «دي‌اس‌دي‌ام» به عنوان يک چهارچوب کلي براي ساخت سريع نرم‌افزارهاي کاربردي معرفي شد (Abrahamsson et al. 2002) . در اين چهارچوب، مجموعه‌اي از موارد کنترلي وجود دارد که سازندگان براي کنترل فرايند ساخت نرم‌افزار از آن‌ها استفاده مي‌کنند (Pressman 2006, 225-240) . ايده اصلي در اين روش اين است که به جاي كشف وظايف سيستم و سپس اختصاص زمان و هزينه براي انجام آن‌ها، ابتدا زمان و هزينه را مشخص مي‌کنيم و سپس با توجه به آن، وظيفه‌مندي‌ها را متناسب با آن‌ها تنظيم مي‌کنيم (Abrahamsson et al. 2003) . اين روش بيش‌تر دانش مربوط به مديريت پروژه را در خود دارد و اصول و چهارچوب آن بسيار پويا و انعطاف‌پذير است (Voigt 2004) .​

2-3-1. فرايند «دي‌اس‌دي‌ام»
فرايند اين روش شامل پنج مرحله مي‌باشد: امکان‌سنجي، مطالعه فرآيند کسب‌وکار، تکرار مدل کارکردي، تکرار طراحي و ساخت، پياده‌سازي.
دو مرحله اول، ترتيبي هستند و فقط يک بار انجام مي‌شوند. سه مرحله ديگر به صورت افزايشي و تکراري صورت مي‌گيرند. تکرارهاي «دي‌اس‌دي‌ام» به عنوان يک جعبه زماني عمل مي‌کنند و پيشاپيش، زمان هر جعبه مشخص مي‌شود و با اتمام زمان، کار آن تکرار تمام است (Voigt 2004) .
در مرحله امکان‌سنجي مشخص مي‌شود که آيا «دي‌اس‌دي‌ام» براي انجام پروژه مناسب است يا خير (Abrahamsson et al. 2002) ، در مرحله مطالعه کسب‌و‌کار، خواص کاري و فني تحليل مي‌شوند، مشتريان و اعضاي تيم توليد بر روي اولويت‌ها توافق مي‌کنند و يک ذهنيت کلي از سيستم ايجاد مي‌شود، فرايندهاي کاري و کلاس‌هاي کاربر در محصولي به نام «تعريف ناحيه کاري» [11] توصيف مي‌شوند. دو محصول ديگر نيز در اين مرحله توليد مي‌شوند: يکي شماي کلي از معماري سيستم، و ديگري راهبرد نمونه‌برداري (Beck 1999) .
در مرحله تکرار مدل کارکردي، در هر تکرار در مورد زمينه و روش آن تکرار برنامه‌ريزي مي‌شود و نتايج براي تکرار بعدي بررسي مي‌شوند؛ تحليل و كدنويسي انجام مي‌شود؛ نمونه‌ها ساخته مي‌شوند و از تجربه به‌دست‌آمده براي بهبود مدل تحليل، استفاده مي‌شود (Voigt 2004) . آزمايش نيز به‌صورت پيوسته در اين مرحله انجام مي‌شود.
اساساً سيستم در مرحله طراحي و ساخت، ساخته مي‌شود. خروجي اين مرحله يک سيستم آزمايش‌شده است که حداقل نيازهاي مورد توافق را برآورده مي‌کند (Abrahamsson et al. 2002) . توسعه مجدد براساس توضيحات کاربران صورت مي‌گيرد.
در مرحله پياده‌سازي، سيستم از محيط توليد به محيط واقعي منتقل مي‌شود. به کاربران آموزش داده مي‌شود و سيستم به کاربران تحويل مي‌گردد (Pressman 2006, 225-240) .​

2-4. معرفي «اسكرام» [12]
روش «اسكرام» يک شيوه مديريتي است. لفظ «اسكرام» از يک راهبرد در نوعي توپ‌بازي گرفته شده است. اين روش در سال 2002 توسط «شوابر» [13] و «بيدل» [14] براي مديريت فرايند توسعه سيستم‌ها معرفي شد (Abrahamsson et al. 2002) . تأکيد اصلي اين روش بر انعطاف‌پذيري، سازگاري و سودمندي است. اما روش «اسكرام» هيچ تکنيک خاصي براي ساخت نرم‌افزار تعريف نمي‌کند (Schwaber and Beedle 2002, 6:201-208, 8:288-295) . «اسكرام» بر اين مطلب متمرکز مي‌شود که اعضاي تيم چگونه بايد عمل کنند تا سيستم توليدشده، در يک محيط کاملاً تغييرپذير، انعطاف‌پذيري کافي داشته باشد (Schwaber 1995) . ايده اصلي «اسكرام» اين است که توسعه سيستم‌ها شامل چندين متغير محيطي و فني (نيازها، زمان، منابع، و فناوري) است که احتمالاً در طول فرايند ساخت، تغيير مي‌کنند و اين امر، فرايند ساخت نرم‌افزار را پيچيده‌تر و غيرقابل‌پيش‌بيني مي‌کند و انعطاف‌پذيري فرايند ساخت را مي‌طلبد تا در مقابل تغيير نيازها، واکنش مطلوبي نشان دهد (Coad, LeFebvre, and De Luca 2000, 5:167-190) .
2-4-1. فرايند «اسكرام»
فرايند «اسكرام» شامل سه مرحله است: قبل از ساخت ، ساخت ، پس از ساخت.
مرحله قبل از ساخت ، شامل دو زير- مرحله «برنامه‌ريزي» و «طراحي معماري سطح بالا» مي‌باشد. هدف از مرحله برنامه‌ريزي، تعريف سيستم در حال توليد است که شامل «سياهه پس‌افتادگي‌هاي محصول» (پي‌بي‌ال) [15] ، تعريف تاريخ تحويل و وظيفه‌مندي‌هاي هر نسخه، انتخاب نسخه‌هاي ضروري براي توليد آن‌ها، تعريف تيم پروژه، شناسايي ريسک‌ها و پيش‌بيني براي کنترل مناسب آن‌ها، تأييد يا انتخاب مجدد ابزارهاي توليد، تعيين نيازهاي آموزشي، و بررسي روش‌هاي مديريت مي‌باشد. در هر تکرار، «پي‌بي‌ال» توسط تيم توليد بازبيني مي‌شود تا براي استفاده در تکرار بعدي آماده شود (SchWaber, K. 2000) .
در مرحله معماري، يک طراحي سطح بالا از سيستم که همه موارد موجود در «پي‌بي‌ال» را دربرمي‌گيرد انجام مي‌شود. طراحي انجام‌شده مورد بازبيني قرار مي‌گيرد و به‌عنوان يک طرح براي پياده‌سازي، از آن استفاده مي‌شود. علاوه بر اين، طرح‌هاي مقدماتي براي نسخه‌ها در اين مرحله توليد مي‌شوند (Abrahamsson et al. 2002) . بعد از اتمام اين مرحله وارد مرحله ساخت مي‌شويم که به آن مرحله Game نيز گفته مي‌شود. اين مرحله همچون يک جعبه سياه است و متغيرهاي محيطي و فني که در مرحله قبل شناسايي شده‌اند و ممکن است در طول فرايند توليد تغيير کنند، با فعاليت‌هاي انجام‌شده در قسمت «تاخت» [16] از مرحله ساخت، کنترل مي‌شوند (Coad, LeFebvre, and De Luca 2000, 5:167-190) .
هدف «اسكرام» از کنترل اين متغيرها اين است که فرايند ساخت، در مقابل تغيير نيازها انعطاف‌پذير باشد. در مرحله ساخت، سيستم در «تاخت‌»ها توسعه داده مي‌شود. «تاخت‌»ها چرخه‌هاي تکراري هستند که فعاليت‌هاي خاصي در آن‌ها براي توسعه محصول انجام مي‌شود. معماري و طراحي سيستم در طول يک «تاخت‌» تکامل مي‌يابد. يک «تاخت‌» ممکن است از يک هفته تا يک ماه طول بکشد. در واقع در يک «تاخت‌» کار توليد انجام مي‌شود (Pressman 2006, 225-240) .
مرحله بعدي توليد نسخه‌ها است. وقتي به اين مرحله مي‌رسيم که توافق اساسي روي متغيرهاي محيطي (مانند نيازها) صورت گرفته و ديگر هيچ نياز جديدي وجود نداشته باشد. هم اکنون سيستم براي انتشار نسخه‌ها آماده است (Coad, LeFebvre, and De Luca 2000, 5:167-190) . در اين مرحله فعاليت‌هايي مانند يکپارچه‌سازي، آماده‌سازي سيستم و مستندسازي انجام مي‌شود (Abrahamsson et al. 2002) .
2-5. معرفي «كريستال»
اين روش شامل مجموعه‌اي از شيوه‌هاي متفاوت است که مناسب‌ترين آن‌ها براي هر پروژه منحصربه‌فرد انتخاب مي‌شود. روش «كريستال» داراي اصولي است که شيوه‌ها را براي شرايط مختلف موجود در پروژه‌ها، سفارشي مي‌کند (Abrahamsson et al. 2003) . در حال حاضر سه شيوه اصلي «كريستال» وجود دارد: «كريستال شفاف» [17] ، «كريستال نارنجي» [18] ، و «كريستال نارنجي تورينه» [19] (Abrahamsson et al. 2002) .
2-5-1. فرايند «كريستال»
تمامي‌ پروژه‌ها از توليد افزايشي با بازه زماني حداکثر ٤ ماه استفاده مي‌کنند. تأکيد اصلي بر ارتباطات و همکاري بين افراد درگير در پروژه است (Pressman 2006, 225-240) . روش «كريستال» براي توليد، هيچ فعاليت يا ابزاري را محدود نمي‌کند. مثلاً مي‌توان از فعاليت‌هاي «ايكس‌پي» و «اسكرام» با هم در اين روش استفاده کرد (Abrahamsson et al. 2002) .
2-6. معرفي «اي‌اس‌دي [20] »
اين روش‌هاي ساخت نرم‌افزار توسط «هاي‌‌اسميت» [21] در سال 2000 معرفي شد که بر پايه اصولي مثل مديريت پروژه، جوابگويي تغييرات در پروژه، ارائه چهارچوبي براي جلوگيري از هرج و مرج و آشفتگي در پروژه، و توسعه سريع وفق‌پذيري حتي در پروژه‌هاي بزرگ استوار است (Abrahamsson et al. 2003) . روش «اي‌اس‌دي» از مدل ساخت نرم‌افزار «آراي‌دي» [22] استنتاج شده، بيش‌تر روي مشکلات مهم و اصلي سيستم‌هاي پيچيده و بزرگ متمرکز است و قصد دارد روش جديدي براي ساخت نرم‌افزار در سيستم‌هاي بزرگ و پيچيده ارائه دهد. در ابتدا يک مدل اوليه از نمونه اصلي براي ساخت نرم‌افزار ارائه مي‌دهد و ساخت نرم‌افزار ، مبتني بر مدل افزايشي تدريجي و تکراري است (Abrahamsson et al. 2002; Abrahamsson et al. 2003) . «اي‌اس‌دي» به دنبال از بين ‌بردن بي‌نظمي‌ها و متوازن‌کردن فرايند ساخت نرم‌افزار است و رهنمودهاي کافي را براي جلوگيري از قرارگرفتن پروژه در بي‌نظمي‌ فراهم مي‌کند (Abrahamsson et al. 2002) .​

ادامه دارد...
برگرفته از فصلنامه علوم و فناوری اطلاعات

 

[کربلایی]

2-6-1. فرايند «اي‌اس‌دي»
فرايند «اي‌اس‌دي» سه مرحله اصلي دارد: 1- انديشيدن [23] ، 2- همکاري،
3- يادگيري (Abrahamsson et al. 2002; Cohen, Lindvall, and Coasta 2004b; Subramaniam 2005) .
در مرحله انديشيدن، يک طرح اوليه ارائه مي‌شود. چون طرح کلي و جامع كه در ابتداي پروژه ايجاد شود، طرح ضعيفي است و با توجه به اينکه انحراف از طرح، خطا محسوب مي‌شود، امکان هيچ نوع انعطاف‌پذيري وجود نخواهد داشت. بنابراين در ابتدا يک طرح اوليه و مدل پيش-الگو ارائه مي‌شود. در مرحله همکاري، بر کار تيمي ‌براي حل مشکلات ناشي از وجود تغييرات در پروژه و مهندسي اجزاي همروند تأكيد مي‌شود. مرحله يادگيري بر داشتن دانش کافي براي عکس‌العمل نشان‌دادن در برابر خطاها تأکيد دارد (Abrahamsson et al. 2002; Beck 1999) .
در جدول 1 مزايا و معايب هر روش به اختصار توضيح داده شده است.

جدول 1 مزايا و معايب روش‌ها​

​

​

3. معرفي ابزارهاي مقايسه
به منظور بررسي و مقايسه روش‌هاي سريع‌الانتقال موجود، مجموعه‌اي از معيارهاي تحليلي مناسب موردنيازند. در منابع و متن‌ها، معيارهاي مختلفي بدين منظور معرفي و استفاده شده‌اند (Iivari and Hirscheim 1996; Olle, Sol, and Verrijn-Stuart 1982, 56-62) . تعدادي از اين ابزارهاي تحليلي که مناسب و تکميل‌کننده اهداف نهايي ما در اين مقاله بودند در جدول 2 نشان داده شده‌اند.
چرخه حيات ساخت نرم‌افزار، دنباله‌اي از فرآيندها است که سازمان‌ها براي درک و طراحي محصولات نرم‌افزاري از آن استفاده مي‌کنند (Boehm 1988; Cugola and Ghezzi 1998) . چرخه حيات ساخت نرم‌افزار دقيقاً نشان مي‌دهد که هر يک از روش‌هاي مختلف سريع‌الانتقال، چه مراحلي از ساخت نرم‌افزار را مي‌پوشانند. چرخه حيات نرم‌افزار شامل 9 مرحله مي‌باشد (Sommerville 1996, 10:203-228,13:289-330) : تعريف پروژه، تشخيص نيازمندي‌ها، طراحي، برنامه‌نويسي، آزمون واحد، آزمون جامعيت، آزمون سيستم، آزمون پذيرش، و نگهداري سيستم . چرخه حيات نرم‌افزار مراحل مختلفي را که براي توليد نرم‌افزار بايد طي شوند معين مي‌کند. روش‌ها بايد از نظر زمان کمينه شوند و از لحاظ استفاده از منابع موجود، از کارآيي بالايي برخوردار باشند (Kumar and Welke 1992) .
دستيابي به کارآيي بالا به مديريت فعال پروژه نياز دارد تا مراحل ساخت نرم‌افزار را به خوبي اجرا کند. مديريت پروژه يک فعاليت پشتيباني است که به منزله ستون فقرات ساخت نرم‌افزار محسوب مي‌شود (Gilb 1988, 301-360)و بنابراين يک معيار مهم در ارزيابي روش‌هاي سريع‌الانتقال ساخت نرم‌افزار محسوب مي‌گردد (Abrahamsson et al. 2003) .
از روش‌هاي ساخت نرم‌افزار معمولاً براي اهدافي غير از آنچه در اصل مدنظر بوده، استفاده مي‌شود. بنابراين براي ارزيابي اين‌که آيا يک روش را مي‌توان براي مقاصدي غير از اهداف ضروري خود به کار برد، بحث اصول تجريد در مقابل رهنمودهاي عيني مطرح مي‌شود. در واقع اين معيار براي ارزيابي اين‌که آيا روش‌هاي سريع‌الانتقال ساخت نرم‌افزار، رهنمودهاي واقعي و عيني ارائه مي‌دهند يا تنها به مجموعه‌اي از قوانين انتزاعي تکيه مي‌کنند، به کار مي‌روند. مثلاً «احترام به مشتري و افراد درگير پروژه» بدون هيچ توضيح واقعي از چگونگي اجراي آن، يک نمونه از قوانين انتزاعي است؛ در حالي‌که رهنمودهاي واقعي به فعاليت‌ها و محصولات کاري در مراحل مختلف چرخه حيات ساخت نرم‌افزار اشاره دارند (Abrahamsson et al. 2003) .
يکي ديگر از معيارهاي مقايسه روش‌هاي مختلف سريع‌الانتقال، قابليت انطباق روش بر شرايط پروژه است. در روش‌هاي منطبق بر ديدگاه از پيش تعريف‌شده، يک راه‌حل آماده و از پيش تعريف‌شده براي تمام موقعيت‌هاي ساخت سريع‌الانتقال ارائه مي‌شود؛ در حالي‌که ديدگاه متناسب با شرايط، به حوزه‌اي از روش‌ها که بر حسب شرايط قابل انعطاف هستند، اشاره مي‌کند.
معيار بعدي بررسي‌شده، وجود يا نبود نمونه‌هاي واقعي و عيني براي بررسي روش سريع‌الانتقال در شرايط مختلف زندگي واقعي است. از آنجا ‌که ساخت نرم‌افزار يک فرآيند کاربردي است و تجارب عملي و واقعي، نقش مهمي ‌در بهبود روش و ارزيابي کارآيي آن بازي مي‌کنند، بررسي اين‌که آيا روش‌هاي مختلف سريع‌الانتقال از پشتيباني عملي واقعي برخوردار هستند، نقش برجسته‌اي در مقايسه روش‌ها دارند (Abrahamsson et al. 2003) .
هنر هماهنگ‌سازي توليد نرم‌افزار با هدف به حداقل‌رساندن سردرگمي، «مديريت پيکربندي» [24] ناميده مي‌شود.
«مديريت پيکربندي» هنر مشخص كردن، سازماندهي و کنترل اصلاحات نرم‌افزاري است که توسط تيم برنامه‌نويس انجام مي‌شود. مديريت پيکربندي نرم‌افزار يک مؤلفه اصلي براي تضمين کيفيت نرم‌افزار در طول فرايند توليد آن مي‌باشد و بنابراين به عنوان يکي از معيارهاي اساسي، غيرقابل چشم‌پوشي است (Beck 1999) . يکي از واقعيت‌هاي اجتناب‌ناپذير در توليد نرم‌افزار، تغيير مي‌باشد. تغيير باعث افزايش سردرگمي‌ طراحان و سازندگان درگير در پروژه مي‌شود. سردرگمي‌زماني به وجود مي‌آيد که تغييرات قبل از رخداد، تحليل و ثبت نشده باشند. بنابراين مشخص نمودن تغييرات و تصميم‌گيري در مورد آن ضروري است (Pressman 2006, 225-240) .
مديريت پيکربندي نرم‌افزار شامل مجموعه فعاليت‌هايي است که براي مديريت تغييرات در طول دوره زندگي نرم‌افزار رايانه‌اي تدوين شده‌اند (Pressman 2006, 225-240) . فرايند مديريت تغييرات را بايد بخشي از پياده‌سازي مديريت پيکربندي نرم‌افزار شمرد.

ادامه دارد​