دسته: مهندسی نرم افزار

چگونه به سمت Agile حرکت کنیم؟

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

در دنیای نرم افزار نیز وضعیت مشابه مثال بالا داریم، در هر دوره ای راه حل ها، تکنیک ها و متدلوژ های خاصی بحث روز بودند و بعضی از آنها بعد از دوره ای به کلی فراموش شده اند. شاید یکی از بحث مورد علاقه بسیاری از شما متدلوژیهای سبک باشد که در شرایط فعلی بحث بر روی این متدلوژی زیاد می باشد و امروزه تکنیکها و طرز فکری که بر این متدلوژیها حاکم است مکررا توسط توسعه دهندگان نرم افزار استفاده می شود.اما سوال این است که آیا خود را می توانیم یک تیم یا سازمان چابک بنامیم  اگر فقط از تکنیک ها که بر این متدلوژیها حاکم است استفاده کنیم یا نه؟ جواب من به این سوال نه است، زیرا به نظر من Agile یک تکنیک نیست بلکه یک فرهنگ است که برای پیاده سازی آن در تیم یا سازمان خود نیازمند زیر ساخت های مختلف هستیم. حتی اگر Agile را به عنوان یک ابزار تصور کنیم باید فرهنگ استفاده از آن ابزار را داشته باشیم و زیر ساخت های استفاده از آن ابزار را یرای محیط خود فراهم آوریم.

برای اینکه شما در دانشگاه ثبت نام کنید ابتدا باید دپیلم گرفته باشید، سپس در کنکور ثبت نام کرده باشید و در آن آزمون قبول شده باشید تا بتوانید وارد دانشگاه بشوید. Agile نیز تقریبا شرایط مشابهی با مثال بالا دارید برای اینکه بتوانید خود را Agile بنامید ابتدا باید یک تیم یا سازمان یاد گیرنده باشید. بعد در مرحله بالاتری شما باید از تفکر ناب یا همان Lean معروف شرکت تویوتا تبعیت کنید بعد شما می توانید وارد دنیای Agile شوید. تصویر زیر نمایی جالب از گفته ها ما را نشان می دهید.

در ابتدا ما باید روش یاد گرفتن خود و تیم مان را کشف کنیم، سپس نحوه اشتراک دانسته ها و دانش خود را یاد بگیریم یعنی به سوی یک یادگیری جمعی رو بیاوریم و این فرهنگ را در کل تیم و سازمان خود توسعه بدهیم و این جریان را به عنوان یکی از شاهرگهای حیاتی تیم خود حفظ کنیم. هنگامیکه به فرهنگ یادگیری در تیم خود دست یافتیم می توانیم به سمت تفکر ناب حرکت کنیم. Lean یا معادل فارسی آن تفکر ناب، واژه ای است که برای سیستم تولید تویوتا به کار می رود، و اصولی را بیان می کند که توسط بنیان گذار تویوتا تائیچی اونو پايه گذاري و در طول تاریخ حيات تویوتا تا امروز سیر تکامل خود را طی کرده است.  بعد از آنکه یک تیم Lean شدیم می توانیم به مرتبه بالای هرم یعنی Agile صعود کنیم. پس تا پست بعد یادگیری، یادگیری و باز یادگیری ….

البته در بحث های جداگانه سازمانهای یادگیرنده و تاریخچه و اصول تفکر ناب را مورد بررسی قرار خواهیم داد و شکل خاصی از Lean را که برای فرآیند توسعه نرم افزار ارائه شده است (البته هنوز بحث بر روی اینکه آیا آنرا یک فرآیند توسعه نرم افزار در نظر بگیریم یا به عنوان مجموعه ای از ابزارها که می تواند همراه با Agile بکار گرفته شود) نیز مورد بحث قرار خواهیم داد.

Lessons in Software from Alok Srivastava

These are my top lessons learned drawing from my years of software experience.  I am sharing them with you here.

Summary of Lessons
Here is an index of the lessons that follow:

  • Lesson 1. Software development is a team sport.
  • Lesson 2. More lines-of-code does not mean better software.
  • Lesson 3. The Cloud is an inflection point.
  • Lesson 4. Scalability, performance and diagnostic ability are better achieved at design time.
  • Lesson 5. User experience and user expectation change continuously that is why UI projects are never done.
  • Lesson 6. Software maintainability is a key to longer life for any software.
  • Lesson 7. Development process should help development produce good quality software, if it comes in your way change it.
  • Lesson 8. Take agility with a grain of salt; result –oriented software development is what agility should help you gain.
  • Lesson 9. A great software engineer never stops working.
  • Lesson 10. Know the keys to writing great software; magic isn’t one of them…

Source : shapingsoftware.com

planning poker

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

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

اما درسال 2005، یکی از این شرکت ها به نام CEO دست به تجربه ای دیگری زد. آنها روند نرمال سالیانه را برای تحمین فروش به کار بردند، اما همچنین آنها به 100 نفر از کارمندان در سراسر شرکت که به طور تصادفی انتخاب شده بودند ایمیل زدند و از آنها درخواست کردند که حدس بزنند چه تعداد از کارت ها به فروش خواهد رسید. اطلاعاتی که برای هر دو گروه تدارک دیده شده بود فقط مقدار فروش سالهای قبل بود.

بعد از ایام عید، پیش بینی های هر دو گروه مورد بازبینی قرار گرفت. گروه کارشناسان 95 درصد فروش واقعی را تخمین زده بودند در حالیکه گروه کارمندان 99.9 درصد فروش واقعی را تخمین زده بودند. اما چگونه ممکن است که یک گروه از کارمندان به گروهی از کارشناسان خبره غلبه کنند؟

در پستهای قبلی درباره خرد جمعی، مالکیت اشتراکی نوشته بودم. در واقع در اینجا نیز با مسائل مشابهی روبرو هستیم و می توانیم بگویم که گاهی مجموعه ای از افراد با تفکرات گوناگون که به طور مستقل فکر می کنند می توانند نسبت به گروهی از کارشناسان خبره نتایج بهتری را پیش بینی کند. اما این چگونه ممکن است؟ خیلی ساده، افراد مختلف دارای  تجربیات مختلف هستند و از دیدگاههای مختلف به مسئله می نگرند و با استفاده از ورودیهای که از این افراد می توانیم بگیریم ، می توانیم ائده های مختلفی را درباره حل مسائل در نظر بگیریم و همچنین ائده های مختلف درباره موانعی که ممکن است در برخورد بر مسئله با آن روبرو شویم.

آیا می توانیم از روش مشابه بالا برای تخمین زدن اندازه کارها در پروژه های نرم افزاری استفاده کنیم یا نه؟ پاسخ بله است. در متدلوژهای Agile ما تکنیکی به نام planning poker برای تخمین زدن داریم که تقریبا مشابه روش بالا می باشد. در این تکنیک به جای اینکه فقط مدیران کار تخمین را انجام بدهند، کل تیم یعنی مدیران، تحلیلگران، معمارها، مدیران پایگاه داده و …. با هم اینکار را نجام می دهند.

در این روش ما مجموعه ای از کارت ها داریم، که بر روی هر کدام از آنها عددی نوشته شده است. این اعداد در اکثر موارد سری فیبوناچی یا یک سری مانند سری مقابل 0,1/2,1,2,3,5,8,13,20,40,100 می باشد.

روند انجام این تکینیک به این صورت است که، در جلسه ای که با شرکت اعضای تیم  تشکیل می شود به هر کدام از آنها یک دسته از کارت ها داده می شود. یکی از داستانهای کاربر (User story ) انتخاب می شود و یک نفر که آگاهی بیشتر نسبت به مسئله دارد شروع به شرح مسئله می کند این شخص ممکن است مشتری، صاحب محصول، مدیر پروژه یا هر عضوی از تیم باشد. پس از اینکه شرح مسئله تمام شد، اعضای تیم سوالات خود را درباره آن مسئله (داستان کاربر) از آن شخص می پرسند و به سوالات آنها پاسخ داده می شود. بعد از آنکه به همه سوالات پاسخ داده شد، اعضاء می توانند برآوردهای خود را نسبت به آن مسئله انجام دهند، که اینکار با انتخاب یکی از کارتها به صورت محرمانه که بیانگر تخمین آن فرد است انجام می پذیرد.
کارتها نمایش داده نمی شوند تا همه کارت خود را انتخاب کرده باشند، سپس به طور همزمان هر کس کارت خود را نشان می دهد تا همه شرکت کنندکان تخمین همدیگر را ببینند. روال طبیعی این است که در اول مرتبه اعداد مختلفی توسط اعضاء انتخاب شوند، چون همانطوریکه در بالا اشاره شد افراد داری تجربیات و دیدگاههای مختلفی هستند. اگر اعداد مشابه یا خیلی نزدیگ به هم نبودند، اعضاء می توانند روی داسنان و تخمین خودشان بحث کنند و سپس مجددا هر کدام از اعضاء یکی از کارتها را نتخاب می کند. این روند تکرار می شود تا زمانیکه همه اعضاء یا اکثر اعضاء یک عدد مشترک را انتخاب کنند. سپس کل روند از ابتدا برای یک داستان دیگر تکرار می شود.

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

افزایش و فقط افزایش

ظرفیت هارد دیسک با سرعت بسیار خوبی هر روز افزایش پیدا می کند، رم ها نیز این روزها از لحاظ افزایش سایز دارند هر روز بیشتر و بیشتر می شوند و به حد قابل قبولی می رسند و CPU ها نیز همینطور.

اما در این میان و با رشد قابل قبول سخت افزار از لحاظ حجم و سرعت، نرم افزار به کدام سو  می رود.  آیا این رشد به نفع توسعه دهندگان
نرم افزار است یا نه؟ به نظر شخصی من این روند برای نرم افزار زیاد مفید نیست، این را می توان در نیازمندیهای سخت افزاری برای نصب نرم افزار بر روی سیستم هایتان مشاهده کنید، نیازمندیهای سخت افزاری از یک نسخه به نسخه بعدی تفاوتهای بسیار می کند ولی از لحاظ کارائی و  خصوصیات جدید در نسخه جدید آیا تغییرات در این سطح است؟ اگر دنیای سخت افزار شتاب کمتری نسبت به وضعیت فعلی داشت آیا نرم افزارهای که توسعه داده می شد با نرم افزارهای موجود ا ز لحاظ کارائی و حجم تفاوتی بسیار می کرد؟ پاسخ من نه است، پاسخ شما چیست؟

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

سوالاتی در آنالیز و طراحی

یک تاپیک بسیار مفید و جالب به عنوان سوالاتی در آنالیز و طراحی توسط Elham_gh در سایت برنامه نویس ایجاد شده است. که واقعا جای اینگونه تاپیک ها در اکثر فروم ها خالی است. از تمام دوستان علاقمند می خواهم که سری به این تاپیک بزنند. هدف این تاپیک از دیدگاه Elham_gh :

دوستان برای برآورد سطح دانش و بالا بردن دانسته هامون، من یک پیشنهاد دارم . اگر دوستان هم همراهی کنند , من از اینکار در جاهای دیگه نتایج خوبی گرفتم. اگر استقبالی نشه که تاپیک رو حذف می کنم.

یکسری سئوال مطرح می شه و از بقیه دوستان خواسته می شه جوابی که می دونن بگن. اینکه جوابش چیه و یا اگه اون مسئله رو چطور طراحی و مدل و یا آنالیز می کنند. و یا از چه pattern ی استفاده می کنند. در نهایت جوابها جمع بندی می شه و نفر بعدی سئوال دیگه ای رو مطرح می کنه. جمع بندی هر سئوال به عهده مطرح کننده سئوال است.

فقط سئوال این مدلی نباشه که سیستم حسابداری را چگونه طراحی می کنید!!!

و به پیشنهاد مدیر محترم بخش هم , اولین پست به فهرست بندی سوال اختصاص داده می شود.

سئوال اول رو خودم مطرح می کنم. تا دوستان دیگر هم ادامه دهند.

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

تست واحد (Unit Testing)

به تصویر بالا نگاه کنید فکر می کنید کلاس دیاگرام بالا متلعق به کدام قسمت از یک نرم افزار است. شاید حدس زدن آن در اولین مرحله برای خیلی ها مشکل باشد پس لطفا بر روی تصویر کلیک کنید تا تصویر را با اندازه واقعی مشاهده کنید و از نام متدها قضیه را حدس بزنید. تمام کلاس های بالا برای تست متدهای کلاس های نرم افزار یا همان تست واحد (Unit Test)  طراحی و پیاده سازی شده است. شاید اگر به سورس بسیاری از نرم افزارهای مشهور دسترسی داشته باشید، حتما مشابه این کلاس ها را در یک پکیچ جداگانه در سورس خواهید یافت (تصویر بالا مربوط به مولفه منوی  RadControls از شرکت Telerik است که حنما اکثر توسعه دهندگان وب با محصولات این شرکت آشنا هستند). پس اجازه بدهید در پایین به بررسی اصول و نحوه پیاده سازی تست های واحد بپردازیم.

تست واحد (Unit Testing):

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

هدف و فلسفه تست واحد

ما از تست واحد استفاده می کنیم تا نشان دهیم که واحد مورد نظر کاری را که ما فکر می کنم انجام می دهد یا نه.

چرا باید تست واحد را انجام بدهیم؟

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

مزایا و منافع

علاوه بر دلایلی که در بالا اشاره شد، ما با انجام تست های واحد منافع زیادی را به دست می آوریم که به بعضی از آنها در ادامه اشاره خواهد شد.

1-      تست های واحد همانند یک سند اجرایی هستند که نشان می دهند شما انتظار دارید که کد نوشته شده در شرایط مختلف چگونه عمل کند. اعضای تیم می توانند برای درک عملکرد کد و اینکه چگونه آن را بکار ببرند به تست های واحد مراجعه کنند.

تست های واحد مستنداتی هستند که با تغییر و اصلاح کد بروز رسانی می شوند.

علاوه بر اینها نظرات و حدس های برنامه نویس را در تست ها می توانیم مستند سازی کنیم.

2-      به اشتراک گذاری کد با دیگران راحتتر است، چون اگر عضوی از تیم کد را طوری دستکاری کنید که درست کار نکند، اجرای تست ها با شکست روبرو می شود.

3-        با انجام تست های واحد، زمان انجام تست ها در سایر فازها کاهش می یابد.

4-      تست ها، انتظارات برنامه نویس را در مورد چگونگی عمل کردن یک قطعه کد، ارزیابی می کنند.

بهانه و مقاومت

تغییر همیشه وجود دارد، رویه ها، قوانین و روش های جدید بوجود می آیند و ایجاد می شوند ولی هر پدیده جدیدی همیشه با مقاومت بعضی از افراد در اجراء روبرو می شود. اگر شما از تست های واحد استفاده نمی کردید احتمالا سوالات یا بهانه های مانند عناوین زیر را مطرح کنید:

1- نوشتن تست ها احتیاج به زمان زیادی دارد: این جمله ای که توسط افرادی زیادی گفته می شود ولی آیا اینگونه است. تصور کنید که شما یک باغچه دارید که مسئولیت رسیدگی آن بر عهده شما است، آخر هفته به باغچه نگاه می کنید مشاهده می کنید که چمن ها بزرگتر شده اند و گل ها نیز نیاز به رسیدگی دارند ولی تا هفته بعد صبر می کنید و هفته بعد دوباره  صبر، اما بعد از چند هفته مشاهده می کنید که چمن ها خیلی بزرگ شده اند، علف های هرز کل محیط را احاطه کرده اند، گل ها پژمرده شده اند   و …. در هفته اول شما می توانستید با یک قیچی باغبانی و در چند دقیقه کل کار را انجام دهید ولی حالا شاید با ساعت ها کارها و تجهیزات اضافی بتوانید کارتان را انجام بدهید البته شاید.  تست های قطعه نیز مانند انجام دادن کارهای باغبانی در آخر هفته است، یعنی با تست قطعه ما می توانیم فرآیند تست را ارزان تر و و با کیفیت بالا انجام دهیم و ریسک نیاز به زمان زیادی برای تست را در آخر پروژه حذف کنیم.

2-      اجرای تست های نیاز به زمان زیادی دارید: یک آگاهی بازرگانی بود که احتمالا از تلویزیون خودمان آنرا مشاهده کرده اید، خانمی که باید غذا را آماده می کرد، به خرید می رود و … خانم غذا را آماده می کرد آنرا تو آرام پز قرار می داد و دیگر تمام شد تا شب می توانست به کارهای دیگرش برسد. برای تست های که نیاز به زمانی زیادی برای اجرا دارند ما نیز همین کارها را انجام می دهیم. یعنی زمانی که باید کار دیگری را انجام دهم تست را اجراء می کنم چون اجرای تست فرآیندی خود کار است و به بقیه کارها می رسیم. یا در زمانهای بی کاری و یا آخر هفته. تست های را که نیاز به زمان زیادی دارند باید دسته بندی کرد و آنها را جدا از تست های دیگر و در دفعات کم اجرا کرد.

3-      تست کردن شغل من نیست: خوب این کار شما نیست. پس تصور کنید که دو توسعه دهنده داریم نفر اول تست ها واحد را انجام می دهد و دیگری نه. بعد از اتمام کار، کدهای نوشته شده به تیم تست و کنترل کیفیت ارجاع داده می شوند. نتیجه تقریبا روشن است  کدهای نفر اول با حداقل خطا برای رفع اشکال ارجاع داده می شود ولی نفر دوم باید لیست درازی از خطاها را اصلاح کند. کدام یک از اینها مسیر ترقی را سریع طی خواهد کرد و از امنیت شغلی برخودار خواهد بود حتما نفر اول.

4-      اگر من تست ها را انجام دهم احتمالا افراد دیگری که مسئول تست هستند احتمالا کارشان را از دست بدهند: شما اصلا نگران این موضوع نباشید شما فقط مسئول تست واحدها هستید، و این فقط مرحله بسیار کوچک از فرآیند کلی تست می باشد.

5-      چرا از تست کردن به صورت دستی، استفاده نکنیم؟ تست دستی امکان نفوذ خطاهای انسانی به سیستم را افزایش می دهد و همچنین تکرار کردن تست های دستی، بسیار مشکل تر است. برای اینکه تست های دستی را دوباره انجام بدهیم، به مستنداتی نیاز داریم که مراحل انجام تست ها را شرح بدهند. با تغییر کد، این مستندات به سرعت کهنه می شوند و این یعنی اینکه برای به روزنگهداشتن مستندات، باید کار اضافی انجام دهیم.

در مراحل اول بیماری تشیخص بسیار سخت ولی درمان خیلی آسان است. اما بعد از پیشرفت بیماری تشخیص آسان و درمان بسیار سخت می باشد. این جمله را برای تست واحد باز نویسی کنید.

(در قسمت بعدی به نحوه پیاده سازی تست های واحد و معرفی Nunit خواهیم پرداخت.)

مهندسی نرم افزار مبتنی بر مولفه :

مهندسی نرم افزار مبتنی بر مولفه :

در نوشته های قبلی در مورد اهمیت برنامه نویسی مبتنی بر مولفه وتعاریف مربوط به مولفه آشنا شدیم در این قسمت هم می خواهیم در مورد تفاوتهای بین انواع برنامه نویسی ها و مهندسی نرم افزار مبتنی بر مولفه اشنایی مختصری داشته باشیم  :

تفاوتهای COP با OOP :

  • COP مبتنی بر واسط می باشد ، در حالیکه OOP مبتنی بر اشیاست.
  • COP تکنولوژی بسته بندی و توزیع می باشد ؛ در حالیکه OOP   یک تکنولوژی پیاده سازی محسوب می گردد.
  • COP از قابلیت استفاده مجدد در سطح بالا پشتیبانی می کند ، در حالیکه OOP از قابلیت استفاده مجدد در سطح پایین پشتیبانی می کند.
  • COP ، در اصل می تواند در هر زبانی نوشته شود ، در حالیکه OOP محدود به زبانهای شی گرا می باشد.
  • در COP مولفه ها ارتباطات ضعیفی (Loosely Coupled) دارند در حالیکه در  OOP  اشیاء وابسته به همـدیگر از طریق پیاده سازی وراثت (ارث بری ) ، دارای ارتباطات محکم ( Loosely Coupled) می باشند.
  • COP ، از واسطهای چند گانه و طراحی مبتنی بر واسط پشتیبانی می کند ، در حالیکه OOP ارتباطات واضحی از واسطها ی میان ابرکلاس و زیر کلاسها را فراهم نمی کند.
  • COP از اتصـالات و اکتشافات پویا ( اتـصال در زمان اجرا ) پشتیبانی می کند، در حالیکه    OOPپشتیبانی محدودی از مـکانیزمهای ترکیب زمان اجرا و بازیـابی اشیا را فـراهم می آورد .
  • COP مکانیزمهای بهتری برای ترکیب فراهم می کند ، در حالیکه OOP شکلهای محدودی از اتصالات را از طریق فراخوانی فراهم می آورد .
  • COP  از خدمات امنیتی ، تراکنشها و غیره در سطح بالایی پشتیبانی می کند ، در حالیکه  OOP مجموعه  محدودی از خدمات امنیتی ، تراکنشها و غیره را   پشتیبانی می کند.
  • در COP ، مولفه ها با در نظر گرفتن  قوانین اساسی Framework (چهارچوب ) مولفه ها ، طراحی می شوند  در حالیکه  OOP با در نظر گرفتن   اهداف شیء گرایی  طراحی می شوند  .

جدول زیر بحث مختصری از شباهتها و تفاوتهای ما بین برنامه نویسی ساختیافته ، شیء گرا و   مولفه ای را ارائه کرده است.

قابلیت ترکیب در برنامه نویسی ساختیافته خیلی پایین است در شیء گرا بالاست و در مولفه ای خیلی بالاست . دو واحد پیاده سازی مختلف در  برنامه نویسی ساختیافته هرگز با همدیگر قابل تعویض نیستند ، در برنامه نویسی شیء گرا دو شی متفاوت پیاده سازی شده که ویژگیهای مشابه داشته باشند با همدیگر قابل تعویض هستند در حالیکه در برنامه نویسی  مولفه ای  ،  مولفه های متفاوت با  ویژگیهای مختلف با همدیگر قابل تعویض هستند .

قابلیتها

COP

OOP

SP

تقسیم و غلبه

·                                 مدیریت پیچیدگی

·                                 تقسیم کردن یک مسئله بزرگ به بخشهای کوچکتر

یکپارچگی داده و تابع

·                                 یک نهاد نرم افزاری ، داده ها و عملیاتی که بر روی داده ها انجام می گیرد را ترکیب می کند.

·                                 بهبود دادن انسجام یا پیوستگی ( cohesion )

کپسوله سازی

·                                 کاربر یک نهاد نرم افزاری ، از چگونگی ذخیره داده ها و پیاده سازی توابع اطلاعی ندارد.

·                                 کاستن اتصالات ( پیوستگی)

مشخصه

·                                 هر نهاد نرم افزاری یک مشخصه (ویژگی ) منحصر به فرد دارد .

واسط

·                                 وابستگی بین مشخصات را نشان می دهد.

·                                 مشخصه (ویژگی) مولفه را به واسطها تقسیم می کند

·                                 کاستن وابستگیهای داخلی مولفه ای

پیکربندی

·                                 یک واحد انتزاعی که به طور مستقل می تواند توسعه یابد.

  • SP : Structured Programming
  • OOP : Object Oriented Programming
  • COP : Component Oriented Programming

مهندسی نرم افزار مبتنی بر مولفه :

برخی اوقات COP (Component Oriented Programming ) و CBSE (Component Based Software Engineering ) در نوشتار با همدیگر اشتباه گرفته می شوند . هر چند که CBSE یک مفهوم کلی است در صورتیکه  COP  فقط یه عنوان قسمتی از CBSE به کار برده می شود.

CBSE= COA+COD+COP+COM

  • COA : Component Oriented Analysis
  • COD : Component Oriented Design
  • COP : Component Oriented  Programming
  • COM : Component Oriented  Management

COA ، COD ، COM به ترتیب  نشان دهنده تحلیل مبتنی بر مولفه ، طراحی مبتنی بر مولفه و مدیریت مبتنی بر مولفه می باشند . CBSE ، به تسریع کردن توسعه نرم افزار و کاهش دادن هزینه سیستم با ترکیب نمودن مولفه های نرم افزاری از پیش ساخته شده تاکید دارد .  طراحی ، توسعه و نگهداری مولفه ها ، برای استفاده مجدد فرآیند پیچیده ای است . CBSE شیوه های مهندسی نرم افزار و تکنیکهای مختلف نرم افزار  را پوشش می دهد چه از نظر عملی و چه از دیدگاه تئوریک که هنوز هم به طور کامل تعریف و توسعه نیافته اند.

در مهندسی نرم افزار  سنتی فرآیند توسعه نرم افزار در برگیرنده فعالیتها یا مراحل متوالی بود که عبارتنـد از : تحلیل ، طراحی ، برنامه نویسی ، تست و مجتمع سازی ( یکپارچه سازی ) . در CBSE ، مراحل اصلی  توسعه  ، تحلیل ، تولید و آماده سازی  و اسمبل کردن  می باشند. که در برنامه نویسی سنتی فعالیتهای تست و مجتمع سازی ( یکپارچه سازی ) جایگزین فعالیتهای  تولید و آماده سازی مولفه و اسمبل کردن مولفه در CBSE شده است .

دو نوع اصلی از فعالیتها در CBSE وجود دارند :

  • DF ( Developing For reuse)  : توسعه برای استفاده مجدد.
  • DW ( Developing Withr reuse)  : توسعه با استفاده مجدد.

برای DF ، فعالیت توسعه می تواند با دنبال نمودن رویکردها یا دیدگاههای مهندسی نرم افزار سنتی تاکید بر استانداردهای مولفه ای سازماندهی گردد. برای نمونه هر مولفه ارائه کننده  در برگیرنده دو نوع واسط می باشد :

    1. واسط تامیین کننده : که خدمات ارائه شده توسط مولفه را تعریف می کند.
    2. واسط مورد نیاز (ضروری ): که مشخص می کند سیستم استفاده کننده از مولفه ، چه خدماتی را باید ارائه کند.

اگر این واسطها مهیا نشوند ،مولفه کار نخواهد کرد . برای DW  ، جستجو و بازیابی مولفه نرم افزار ، فعالیتهای تعیین کننده ای برای ساختن برنامه کاربردی دارند.

از دیدگاه فرآیند مهندسی نرم افزار ، مولفه ها می توانند به 5 فرم مختلف طبقه بندی شوند ( یعنی مولفه در طی گذراندن 5  مرحله  حاصل می شود ):

1.       مشخصه (ویژگی ) مولفه : این فرم مشخصه (ویژگی ) یک واحد نرم افزاری را ارائه میکند که رفتار مجموعه ای از اشیا مولفه ای را توصیف می کند و یک واحد پیاده سازی را تعریف می کند. رفتار به عنوان یک مجموعه از واسطها تعریف می شود مشخصات مولفه نهایتا در غالب پیاده سازی مولفه خواهد بود.

2.       واسط مولفه : فرم واسط تعریفی از مجموعه رفتارهای مولفه را ارائه می کند که می توانند توسط اشیا مولفه ای ارائه شوند.

3.       پیاده سازی مولفه : پیاده سازی مـولفه شکـلی از مـشخصه (ویژگی ) مولفه می باشد. این بدین معنی است که می توانند به طور مستقل جایگزین دیگر مولفه ها شده و نصب گردد. آن بدین معنی نیست که مولفه مستقل از دیگر مولفه هاست .بلکه ممکن است وابستگیهای زیادی داشته باشد.

4.       مولفه نصب شده : فرم نصب شده که یک نسخه نصب شده یا توسعه یافته از پیاده سازی مولفه می باشد کـه با مستقر کـردن آن در مـحیط اجـرایی تـوسعـه می یابد.استقرار مولفه در محیط اجرائیش ، محیط اجرایی را قادر به شناسایی مولفه نصب شده برای استفاده از آن می کند .

5.       شی مولفه ای : نمونه ای از مولفه نصب شده می باشد . مشابه OOP یک شی مولفه در COP یک شی با داده ها و مـشخصات ( ویـژگیها ی) منحصر به فرد می باشد ، که رفتار پیاده سازی شده را اجرا می کند یک مولفه نصب شده ممکن است چند شی مولفـه ای داشته باشد کـه نیازمـند ویـژگیهای صـریح و روشن می باشد.

تست نرم افزار (قسمت 2)

دوست خوبمان آقای نوبر لطف کردند و نواقصی را که در قسمت اول تست نرم افزار بود کاملتر کردند که عبارتند از :

1.       در کتاب هنر تست نرم افزار – the art of software testing خواندم (و به نظرم کاملا منطقی می آید) که هدف نهایی از تست نرم افزار یافتن باگهای بیشتر است و نه چیز دیگر! البته ادله محکم و قابل قبولی نیز برای این تعریف ارایه میکند.

2.       در متن اشاره کرده ای که “یک مجموعه از ورودهای صحیح با خروج های مربوط به آن را تهیه می کنیم …”. در حوزه تست نرم افزار سناریوی ذکر شده در متن (سناریوی آفتابی-sunny scenario) کاملا لازم است اما سناریوی دیگر (سناریوی بارانی-rainy scenario) که هدف آن کشف اشکالات نرم افزار در مواجهه با مقادیر نادرست (مثلا عدم نمایش پیغام خطای مناسب) است نیز از اهمیت بالایی برخوردار است.

3.       . در تجربیاتی که داشتم Equivalence Partitioning و Boundary Value Analysis را در تستهای جعبه سیاه نیز به کار بردم که منجر به صرفه جویی در زمان و احتمال کشف خطاهای بیشتری شد.
و البته بعضی از موارد دیگر را می توانید تحت عنوان اصول اساسی تست نرم افزار از وبلاگ ایشان دنبال کنید و البته به همه دوستان توصیه می کنم حتما پست های اول وبلاگ ایشان را که بیانگر اهمیت تست نرم افزار می باشید را حتما مطالعه کنند. و البته از همه دوستان می خواهم که نواقص و اشکالات را بیان کنند تا به مطالبی با کیفیت خوب برسیم.

تست نرم افزار عموما در چهار سطح مختلف صورت می گیرد که این چهار مرحله به صورت ترتیبی انجام می پذیرند و عبارتند از :

  1. تست واحد (Unit testing)
  2. تست مجتمع سازی  (Integration Testing)
  3. تست سیستم (System Testing)
  4. تست پذیرش (Acceptance Testing)

تست واحد (Unit testing) :

یک واحد کوچکترین قسمت قابل تست یک نرم افزار می باشد. که این واحد در برنامه نویسی شی گرا می تواند یک متد باشد و در برنامه نویسی رویه ای می تواند کل برنامه (در زبانی مانند کوبول)  یا یک تابع و … باشد.  هدف در این سطح از تست این است که آیا واحد مورد نظر به تنهایی کاری را که باید انجام بدهد می دهد یا نه.

تست مجتمع سازی (Integration Testing) :

تست واحد را برای هر کدام از واحدها به صورت جداگانه انجام دادید و از صحت عملکرد آنها مطمئن شدید. همه واحدها به صورت منفرد به طور صحیح وظایف خود را انجام می دهند، آیا نیازی به تست اینکه وقتی واحدها کنار هم قرار گرفتند و ارتباط برقرار کردند وظایفشان را به شکل صحیح انجام می دهند هست یا نیست. فرضی کنید 2 نفر مشغول کاری هستند هنگامیکه موارد مورد نیاز برای انجام کار بطور کامل مهیا باشد هر کدام از آن 2 فرد می توانند کارشان را به شکل کامل انجام بدهند. اما اگر موارد مورد نیاز برای یکی از آنها توسط دیگری تامین شود ممکن است موارد تهیه شده دقیقا چیزی نباشد که فرد دوم نیاز دارد، یا زمانی زیاد برای تحویل آن موارد مورد نیاز باشد که عملکرد فرد دوم را با مشکل روبرو کند. پس ما نیاز داریم تا مطمئن شویم که آیا واحدها در کنار هم کار می کنند، به درستی فراخوانی می شوند، و داده های درستی را در زمان مناسبی از طریق واسط های آنها عبور می دهند. (تست مجتمع سازی یکی از مهمترین و شاید مهمترین سطح از تست باشد، بخصوص زمانیکه سیستم تغییرات زیادی دارد بعد از انجام تغییرات هرگز این مرحله را فراموش نکنید. پس روشهای مختلف تست مجتمع سازی را بررسی و مطالعه کنید.)

تست سیستم (System Testing) :

تست مجتمع سازی را برای نرم افزار مورد نظر انجام دادید، و از این مطمئن شدید که تمام قطعات در کنار هم می توانند قرار بگیرند و بدون هیچ مشکلی وظایفشان را انجام دهند. قطعات در کنار هم مجتمع شده اند و پیکره اصلی نرم افزار تشکیل شد، ولی نرم افزار خود جزئی از یک سیستم  است و نیاز است که با عناصر دیگر این سیستم مانند سخت افزارها ارتباط برقرار کند و با آنها مجتمع شود. پس نیاز داریم تا مطمئن شویم که سیستم به عنوان یک واحد به طور کامل عمل خواهد کرد و نیازمندیهای سیستم را برآورده می کند. این سطح از تست آخرین سطحی است که توسط توسعه دهندگان صورت می گیرد تا قبل از تحویل نرم افزار به کاربرنهایی برای تست از عملکرد آن مطمئن شویم. برای نمونه موارد زیر در تست سیستم مورد بررسی قرار می گیرد:

تست امنیت (Security Testing) : فرضی کنید سیستم باید اطلاعات حساس و حیاتی را پردازش و مدیریت کند و افرادی هستند که بدنبال دسترسی غیر مجاز به این اطلاعات و سوء استفاده از آن هستند. برای اطمینان از عملکرد سیستم در برابر نفوذگران ما باید مکانیزم امنیتی ایجاد شده در سیستم را بررسی کنیم تا مطمئن شویم که سیستم می تواند نفوذهای غیر قانونی  را تشخیص دهد و در برابر آنها عکس العمل نشان دهد.

تست بازیابی (Recovery Testing) : در این نوع آزمایش باعث ایجاد مشکل و از کار افتادن سیستم به روش های مختلف می شویم و بررسی می کنیم که آیا سیستم می تواند خود را به طور خودکار بازیابی کند و به فعالیت خود ادامه دهد.

و …

تست پذیرش (Acceptance Testing) :

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

تست آلفا : تست آلفا در سایت توسعه دهنده نرم افزار و در اغلب موارد توسط کارمندان داخلی و در بعضی از موارد توسط مشتری انجام می گیرد.

تست بتا : تست بتا در سایت مشتریان و توسط مشتریان که از سیستم استفاده خواهند کرد صورت می گیرد و مشکلات مشاهده شده را به توسعه دهندگان گزارش می کنند.

و …

تست نرم افزار (قسمت 1)

فرمانده گروهان: بزرگترین عاملی که یک سازمان یا شرکت را از سازمانهای و شرکت های دیگر متمایر می کند چیست؟

فرمانده گروهان: محصولی که آن سازمان تولید می کند. محصولی که خروجی نیروی انتظامی است با ارزشترین محصولی است که یک سازمان می تواند تولید کند یعنی امنیت.

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

تست فقط می تواند وجود خطاها را نشان دهد نه عدم وجود آنها را

من عاشق یک پارگراف از یک کتاب طراحی نرم افزار هستم که به طور خلاصه اینرا می گفت: “نرم افزار خوب نرم افزاری است که مشتری را خوشحال کند و زمانی مشتری خوشحال خواهد شد که تمام نیازمندیهای که در نظر دارد برآورده شود”. پس ما به عنوان توسعه دهنده نرم افزار باید مطمئن شویم که مشتری خود را خوشحال خواهیم کرد، فرآیند و شیوه رسیدن به این اطمینان خاطر یعنی هدف تست نرم افزار. تست نرم افزار به طور رسمی جزی از بازبینی و اعتبارسنجی نرم افزار می باشد، که این دو واژه به صورت زیر تعریف و  با هم مقایسه می شوند.

وارسی:  “آیا محصول درستی را می سازیم؟”

اعتبارسنجی: “آیا محصول را به درستی می سازیم؟”

وارسی بررسی می کند که آیا نرم افزار از مشخصاتش پیروی می کند یا خیر. اعتبارسنجی باید تضمین کند که نرم افزار انتظارات مشتری را برآورده می سازد یا نه. توجه کنید که آنچه در مشخصات می آید ممکن است دقیقا خواسته های مشتری را برآورده نسازد.

استراتژی تست

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

استراتژی جعبه سیاه:

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

در یک استراتژی آزمایش جعبه سیاه ما عموما موارد زیر را مورد بررسی و آزمایش قرار می دهیم:

1.       بررسی اینکه سیستم نیازمندهای عملیاتی و غیر عملیاتی را تامین می کند یا نه.

2.       اعتبارسنجی ورودیها

3.       بررسی مقادیر مرزی برای متغییرها: به یک متغییر مقداری کمتر از حداقل مقداری که می تواند قبول کند یا بیشتر از حداکثر مقداری که می تواند قبول کند می دهیم و سیستم را در این شرایط تست می کنیم.

4.       بررسی خروج های سیستم: یک مجموعه از ورودهای صحیح با خروج های مربوط به آن را تهیه می کنیم و سپس ورودها را به سیستم وارد می کنیم و خروج های که توسط سیستم داده می شود را با خروجی های واقعی مقایسه می کنیم.

5.       بررسی رفتار سیستم در برابر پردازش ورودها و پرس و جوهای بزرگ و سنگین

6.       …

برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سیاه وجود دارد که عبارتند از:

functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing, system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing , ….

آیا می توان در استراتژی جعبه سیاه، از این مطمئن شد که سیستم به طور کامل تست شده است؟ خیر، هرگز در این استراتژی نمی توان مطمئن شد که سیستم به طور کامل تست شده است. برای نمونه با چه احتمالی کاربر می تواند ورودهای را انتخاب کند تا شرط زیر چک شود.

if (name=="Lee" && employeeNumber=="1234" &&
    employmentStatus=="RecentlyTerminatedForCause") {
    send Lee a check for $1,000,000;

}

پس همیشه در این استراتژی مسیرهای خواهند بود که تست نمی شوند و همیشه سیستم با داده های ورودی محدود می توانند تست شوند.

استراتژی جعبه سفید

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

در یک استراتژی آزمایش جعبه سفید ما عموما موارد زیر را مورد توجه و بررسی قرار می دهیم:

1.       بررسی سطر به سطر کد (Code coverage): در این حالت باید سیستم را به گونه ای اجراء و بررسی کنیم که مطمئن شویم سطر به سطر کد برنامه حداقل یکبار اجراء شده است.

2.       بررسی همه انشعاب ها در کد برنامه (branch) : در کد برنامه باید تمام عبارت های شرطی ( if elseها و Switch case ها)   را تک به تک مورد بررسی قرار داد. به این صورت که در یک عبارت if else هم فسمت if و هم قسمت else هر کدام بصورت مجزا یکبار اجراء شوند.

3.       بررسی همه حلقه ها در برنامه : حلقه ها در نرم افزار نقش اساسی دارند، چون می تونند با اشتباه جزئی مقدار زیادی از منابع را مصرف کرد برای مثال شرط خروج از حلقه به اشتباه هیچ وقت True نشود. برای نمونه حلقه ها را با ورودی بزرگتر از شرط خروج حلقه چک کنید یعنی حلقه اصلا اجر نشود. تستی طراحی کنید که حلقه دقیقا یکبار اجراء شود، تستی طراحی کنید که حلقه در یک بازه خاص اجراء شود و ….

4.       مدیریت خطای مطلوب : برسی اینکه اگر به یک متد یک ورودی نامعتبر وارد شود، نحوه آگاه سازی و نمایش مطلوب خطا برای کاربر چگونه باشد؟

5.       بررسی امنیت : سیستم را از این جهت که چگونه در برابر دسترسی های غیرمجاز، هک، کرک و هر چیز دیگر که می تواند به آن آسیب برساند مورد بررسی قرار می دهد. در اینجا  ما باید مکانهای از کد را که داده ها را اعتبارسنجی و مدیریت می کنند، دسترسی به منابع یا عملیات مهم و حیاتی را انجام می دهند را بررسی کنیم.

6.       …

7.       برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سفید وجود دارد که عبارتند از:

Basis Path Testing, Equivalence Partitioning/Boundary Value Analysis, Method Coverage, Statement Coverage, Branch Coverage, Condition Coverage, Data Flow Testing, Flow Graphs Revisited, ….

ادامه دارد.

چرا برنامه نویسی مبتنی بر مولفه اهمیت دارد؟

چرا برنامه نویسی مبتنی بر مولفه اهمیت دارد؟

صنایعی که به طور کامل رشد کرده اند و یا مهندسین منضبط چگونه با توسعه سیستمهای پیچیده برخورد می کنند؟برای نمونه صنایع خودکار، ماشینهای خیلی پیچیده را با استفاده از مولفه ها ( با هر اندازه ای از خیلی کوچک مثل پیچ تا زیر سیستمهای پیچیده مثل موتورها و جعبه دنده ها و … ) می سازند. کارخانه های خودکار مدرن ، به عنوان ایجادکنندگان سیستم مشهور شده اند تا تولیدکنندگان سیستم. به خاطر اینکه صنایع و مهندسین منضبط با استفاده موثر از مولفه ها ( که با تنظیم استانداردها که قابلیت همکاری آنها را تعریف می کنند) تحت تاثیر قرار گرفته اند. صنایع، استانداردهای مولفه ای را برای قطعات قابل تعویض و ابزارهای اسمبلی ساده را ، برای سرعت بخشیدن به توسعه محصولات پیچیده تر پذیرفته اند این تحولات انقلاب صنعتی است که تغییر چشمگیری در تولیدات صورت گرفته است ، در صنعت نرم افزاری محصولات هنوز هم بیشتر دستی ( مصنوع دست) هستند. بازدهی ( بهره وری ) پایین است ،کیفیت تضمین شده نیست ، پروژه ها  دارای خطا هستند (مثلا در انتقال اطلاعات دارای خطا هستند که این خطا در مواقعی رخ می دهد که وسیله دریافت کننده داده ها قادر به مدیریت یا کاربرد اطلاعات با همان سرعت ارسال نیست). این چنین پدیده یا عارضه بحران نرم افزاری شناخته شد.

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

چندین دلیل مهم وجود دارد که چرا برنامه نویسی مبتنی بر مولفه اهمیت دارند. این نوع برنامه نویـسی، سطح بالاتـری ازانتزاع را فراهـم می کند. تعـداد زیادی از مـولفـه های کتـابـخانه ای قابل استفاده مـجدد وجود دارند که به تـوسعه برنامه های کاربردی در قلمروهای مختلف کمک می کند.

سه هدف اصلی از برنامه نویسی مبتنی بر مولفه عبارتند از :

     *غلبه بر پیچیدگی   * مدیریت تغییر  * قابلیت استفاده مجدد.

غلبه بر پیچیدگی: ما در یک دنیای پیچیده ای از عصر انفجار اطلاعات زندگی می کنیم .طبق تحقیقات انجام گرفته توسط تیمی در دانشگاه برکلی : دنیا ما بین یک و دو اگزا بایت اطلاعات بی نظیر در هر سال تولید می کند که تقریبا 250 مگا بایت برای هر مرد ، زن و بچه در روی زمین است . هر اگزا بایت یک بیلییون گیگا بایت است . در علم کامپیوتر اندازه پیچیدگی نرم افزار به طور قابل توجه در حال افزایش است .. برنامه نویسی مبتنی بر مولفه یک روش موثر با نام تقسیم و غلبه را برای برخورد با پیچیدگی نرم افزار فراهم می کند.

مدیریت تغییر:تغییرات در مهندسی نرم افزار ذاتی است ، تغییر خواسته های کاربران ، تغییر مشخصه ها ، تغییر کارکنان ، تغییر بودجه ، تغییر تکنولوژی و غیره.یکی از اهداف اساسی مهندسی نرم افزار تاکیید بر اهمیت مدیریت تغییر می باشد.برنامه نویسی مبتنی بر مولفه یک روش موثر به نام برنامه ریزی برای تغییر و ساخت طراحی را  برای برخورد با تغییرات  در مهندسی نرم افزار فراهم آورده است . مولفه ها به آسانی با خواسته های جدید و در حال تغییر وفق داده می شوند . مهندسین نرم افزار توافـق کرده اند که روش بـهتر در برخـورد با تغییرات دائمی در ساخت سیستمها ، مولفه های قابل استفاده مجدد می باشند.

قابلیت استفاده مجدد: نرم افزار با قابلیت استفاده مجدد باعث می شود که طراحی و پیاده سازی فقط یکبار انجام گیرد و در زمینه ها و قلمرو های متفاوتی بارها و بارها مورد استفاده قرار گیرد که قابلیت استفاده مجدد باعث افزایش بازدهی ، بکارگیری مفید از راه حلهای ارائه شده ، اصلاح کیفیت و غیره می باشد. سطوح مختلفی از قابلیت استفاده مجدد نرم افزار وجود دارد برای نمونه کپی کردن کد منبع ، که پایین ترین سطح از قابلیت استفاده مجدد می باشد. کتابخانه ای از توابع رویه ای بهتر از کپی کد منـبع می باشد اما توسعـه پذیر نیست. کتـابخانه ای از کلاسها بهتر از دو حالت قبلی است و توسعه پذیـراست. قبل از اینکـه کـلاسها بتوانند به طـور مـجدد اسـتفاده شوند نیاز به درک بیشتری دارند .علاوه بر این استفاده مـجدد ازکلاسها فقـط استفاده مـجدد جعبه سیاه را پشتیبانی می کند .اگر داخل کلاسها تغییر کنند کاربران تحت تاثیر قرار خواهند گرفت . برای نمونه در زبان برنامه نویسی شی گرا شبیه C++  یا جاوا ، کلاسهای مشتق شده برای پیاده سازی کلاس پایه با یکدیگر ترکیب می شوند . تغییرات در هر کدام از کلاسهای پایه به طور سلسله مراتبی توسط کلاسهای مشتق شده به ارث برده می شود. این سطح از استفاده مجدد مخصوص یک زبان است نه استفاده مجدد در مقابل دیگر زبانها . برنامه نویسی مبتنی بر مولفه سطح بالایی از استفاده مجدد نرم افزار را پشتیبانی می کند. به خاطر اینکه در برگیرنده انواع گوناگونی از استفاده مجدد می باشد ، از قبیل :

* جعبه سفید  * جعبه خاکستری  * جعبه سیاه  .

جعبه سفید ( White Box  ) :  بدین معنی است که منبع (Source  ) یک مولفه نرم افزاری قابل دسترس می باشد و می تواند مطالعه شود ، استفاده مجدد گردد ، وفق داده شود یا تغییر یابد.

 

 جعبه سیاه (  Black Box ) :  مبتنی بر اصل مخفی نمودن اطلاعات می باشد . این واسط سرویسهایی که یک  Client  ممکن است از یک مولفه در خواست کند را مشخص  می کند . مولفه پیاده سازی واسطی که  Client  بر آن تاکید دارد را فراهم می کند ، از آنجاییکه  واسطها بدون تغییر باقی می مانند مولفه ها می توانند به طور داخلی تغییر کنند بدون اینکه کاربر را تحت تاثیر قرار دهد .

جعبه خاکستری (Gray Box ) :  چیزی ما بین جعبه سفید و جعبه سیاه می باشد.

همانگونه که اندازه و پیجیدگی سیستمهای نرم افزاری رشد می کنند شناسایی و مدیریت مناسب اتصالات ما بین قطعه هایی از سیستم نیز اهمیت دارد. برنامه نویسی مبتنی بر مولفه یک راه حل قابل کنترل برای برخورد با پیچیدگی سیستمها ، تغییرات دائمی سیستمها و مشکلات استفاده مجدد از نرم افزار را ارائه می کند. امروزه COP  نمونه عملی برای توسعه سیستمهای نرم افزاری بزرگ می باشد. برای مثال : برنامه های کاربردی توزیع شده در مقیاس موسسه اقتصادی ، برنامه های کاربردی تحت وب و خدمات وب.