RUP بهتر است يا Agile؟

  • یوسف مهرداد بی‌بالان

امروز يکی از دوستان خوبم زنگ زد و گفت که RUP بهتر است یا Agile؟اين سوال بهانه‌ای شد تا نوشته زير را آماده کنم.
واقعيت امر اين است که فرآيندها و متدولوژی‌های توليد نرم‌افزار هر يک دارای نکات مثبت و منفی خاص خود هستند و هر کدام با شرايطی، می‌توانند تجارب ديگران به ما منتقل نمايند تا ما چرخ را دوباره اختراع نکنيم و از ياد نبريم که نبايد مسخ آنها شويم و خلاقيت‌مان را ناديده گرفته و خودباوری‌مان را از دست بدهيم. اما مشکل عمده ما در ايران اين است که خيلی مدگرا هستيم و دانسته‌های ما “ناشی از شنيده‌ها و برداشتهای شخصی است” [اين جمله مال من نيست] و نه بر اساس تجربه و مطالعه.
من در معرفی يکی از دوره‌هايم متنی را آماده کردم که فکر کنم بد نباشد آن را اينجا بياورم:

“در جامعه نرم‌افزاری، هر از چند گاهی، تکنولوژی يا روشی مد روز می‌شود و اين جامعة ذاتاً نوگرا را چون جاذبه‌های عجيب به سمت خود می­‌کشاند، بدون آن که لزوم استفاده و مفاهيم بنيادی آن به اين جامعه منتقل گردد، مدتی به کار گرفته می­‌شود و پس از مدتی به دلايل مختلف از مد خارج شده و با مدی ديگر جايگزين می­‌گردد. يکی از مهم‌ترين دلايلی که باعث از مد خارج شدن اين ابزارها می‌گردد، برداشت نادرستی است که علاقمندان و استفاده‌کنندگان از آن‌ها دارند و دليل ديگر، کاربری نادرست آن‌ها در کنار بی‌تجربگی استفاده‌کنندگان و مهم‌­تر از همه عدم وجود توانمندی لازم جهت ساده‌سازی و بومی‌سازی آن‌ها می‌باشد.
RUP نيز از اين قاعده مستثنی نيست. فرآيند توليد يکپارچه شرکت IBM به دلايل مختلفی در جامعه نرم‌افزاری مد شد و به دلايلی که بخشی از آن را برشمرديم، از مد روز خارج شد، بدون آن که فلسفه و نگرش اين فرآيند به کاربران آن منتقل شود.

هدف اين نيست که از اين فرآيند دفاع نماييم و آن را معجزه قرن بيست و يکم بناميم، بلکه نکته‌ای که بدان پافشاری می‌نماييم اين است که فلسفه و نگرش درون RUP نشأت گرفته از تمامی روش‌هايی بوده است که تا آن زمان ظهور کرده‌­اند و هر يک به طريقی سعی در حل مشکلات توليد نرم‌­افزار داشته­‌اند. فارغ از اين که اين نام چه باشد – FDD،RUP، ICONIX، Agile، XP – آن چه که جامعه نرم‌­افزاری بايد فرابگيرد، فلسفه و نگرش و تکنيک‌هايی است که در اين روش‌ها به صورت ضمنی وجود دارد.”

به عنوان مثال مفهوم معماری. در روش‌های مدرن، معماری به عنوان يکی از مبانی اصلی شمرده می‌شود (the architecture is first). با اين که همه در کوی و برزن اين نام را بر سر زبان می‌آورند، واقعاً به اندازه انگشتان يک دست نمی‌توانيد متخصصينی را پيدا کنيد که اين مفهوم را لمس کرده باشند و نه آن که جملات کتاب‌ها را از بر برايتان بخوانند.

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

يا مفهوم روش‌های تکراری-افزايشی. يکی از دوستان عزيزم که ديگر اکنون در ايران نيست، می‌گفت من پس از سال‌ها پروژه خراب کردن! فهميدم که مفهوم و هدف از روش‌های تکراری-افزايشی چيست. بعد همه ادعای استفاده از اين تکنيک را دارند و وقتی خوب دقت می‌کنيد می‌بينيد روش‌های آبشاری را تحت نام‌های مدرن در حال انجام هستند. وحشتناک‌تر آن که بی‌دانشی و بی‌تجربگی باعث شده خيلی‌ها فکر کنند که RUP مجموعه مستندات است و آن را با کتاب‌های آيين نگارش اشتباه می‌گيرند.
سخن قشنگ ديگری که از همه می‌شنويد اين است که RUP برای پروژه‌های بزرگ است. حتی اين جمله هم ناشی از مطالعه نکردن و بی‌اطلاعی و تحت تأثير شنيده‌ها بودن است.

هفته پيش من جايی بودم و در مورد پروژه‌ای مشاوره می‌دادم. تأکيد من بر اين بود که می‌شود سيستم را بدون بازنويسی، با Refactoring در سطح مطلوبی بازسازی کرد. يکی از دوستان که در جلسه بود گفت: فکر می‌کردم که شما به جای RUP متمايل به XP method شده‌ايد و من هم هاج واج نگاه به همکارم کردم. تأکيد من برگرفته از تجربه و نيز تکنيکی بود که در يکی از روش‌ها تجربه کرده بودم و نه اينکه علاقه‌ای به اسامی داشته باشم.

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

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

اگر به موضوع تفاوت متدولوژی از ديدگاه کاربردی علاقمند هستيد پيشنهاد می‌کنيم که حتما مقاله The New Methodoloyرا از آقای مارتین فولر مطالعه نمایید.

رقبای نشريه شیءگرايی مدار

  • یوسف مهرداد بی‌بالان

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

با خانم دکتر تقی‌ياره که بنده افتخار شاگردی‌شان را دارم، صحبت کردم و ايشان با همه مشغله‌شان در دانشگاه تهران، قبول زحمت فرمودند تا ليست مقالاتی را که دانشجويانشان در دروس CRM و ITM کارشناسی ارشد ارائه می‌دهند، پس از ارزيابی در اختيار ما قرار دهند تا در دو نشريه مستقل به همين نام‌ها منتشر گردد. دست خانم دکتر درد نکند.

با آقای مهندس عسگری هم صحبتی داشتيم و ايشان هم پيشنهاد انتشار نشريه‌ای در زمينه مهندسی صنايع داشتند و من هم استقبال کردم. قرار شد ايشان مديريت اين کار را به عهده بگيرند.
اميدوارم اثربخشی‌اش اين کارها هر چه زودتر همه ما را خوشحال و راضی نمايد.

با نشرياتی که اسامی آنها را عرض کردم به نظر می‌رسد که نشريه شیءگرايی مدار با رقبای جدی و سرسختی روبرو است.

عناوين مقالات نشريه شیءگرايی مدار

  • یوسف مهرداد بی‌بالان

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

  • مفاهيم
    • مفاهيم شیءگرا
    • پارادايم شیءگرا
  • مدلسازی
    • UML 1.x
    • UML 2.0
  • نيازمندی‌ها
  • تحليل
  • طراحی
    • الگوهای طراحی
  • پياده‌سازی
    • Refactoring
  • متدولوژی
    • RUP
    • Agile
  • تکنولوژی
    • Java
    • NET.
  • ابزارها
  • بانک اطلاعاتی
    • OR Mapping
    • OR Mapper
  • واسط کاربر
  • معماری
    • الگوهای معماری
    • ..
  • جنبه‌گرایی(Aspect Orientation)

نشریه شیءگرايی مدار

  • یوسف مهرداد بی‌بالان

در پی توافقی که با مديرعامل شرکت و دست‌اندرکاران نشريه الکترونيک شرکت مدار گسترش (http://itorbit.net/issue/issueuser)انجام دادم، تصمیم گرفتم که نشريه‌ای را با استفاده از اين نرم‌افزار منتشر نمايم.
ایده اولیه این است که نشريه در مورد موضوعات مختلف مهندسی نرم‌افزار مبتنی بر شیءگرايی باشد و نيز مطالب آن را از مطالب داخلی منتشر شده يا مقالات معتبرخارجی فراهم شود. نشريه دارای سردبیر،هيأت تحريريه و داورانی باشد که مقالات ارسالی را داوری نموده و از طرف ديگر نويسندگانی که مطالب نشريه را تهيه و ارسال نمايند. همچنين بتوان برای ارسال نشريات عضوگيری نمود و پس از انتشار نشريه، آن را برای اعضا ارسال نمود.
در صورتی که برای نام نشريه و نيز نحوه ارائه مطالب آن ايده‌ و نظری داريد، لطفاً آن را با من در ميان بگذاريد.

همچنین اگر علاقمند هستید که در این کار مشارکت نمایید، بسم الله. نشریه با آغوش باز پذیرای شما خوبان است.

منتظر دريافت اعلام مشارکت، مطالب و راهنمايی‌های شما هستم.

تجريد (Abstraction) چيست؟

  • یوسف مهرداد بی‌بالان

دوست خوبم آقای احمد حسينيان در نامه‌ای از من خواسته بودند تا در مورد تجريد که يکی از اصول شیءگرایی محسوب می‌گردد، مراجعی را برايشان ارسال نمايم. من هم فرصت را غنيمت شمردم و توضيحاتی در اين مورد نوشتم که در ذيل می‌آيد.

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

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

در شناخت انسان از محیط پیرامون خودنيز اين اصل به خوبی نمايانگر است. وقتی يک روانشناس در مورد يک فيلم صحبت می‌کند، صرف‌نظر از تمامی خصوصيت‌های فيلم، به جزييات و نکات روانشناسی فيلم توجه می‌کند و در مورد آنها سخن می‌گويد. در حالی که يک بازيگر به تکنيک‌های بازيگری آن توجه نموده و آنها را مد نظر قرار می‌دهد. در حالی که فيلم در برگيرنده همه اين‌هاست.
در تحليل سيستمها نيز ما با اين مسأله روبرو هستيم. يک دانشجو دارای مشخصات و جزييات فراوانی است و بسته به نوع سیستم (خواننده)، مشخصات آن متفاوت خواهد بود. در حالی که در حوزه سيستم آموزش، دانشجو دارای مشخصاتی مانند دروس پاس شده، معدل و … می‌باشد، در حوزه سيستم رفاه (مثلاً وام ازدواج ) مشخصات ديگری مانند محل سکونت، نوع تأهل و … را برای دانشجو متصور می‌شويم.

اما ما به تنهايی و با ديدگاه تجريد نمی‌توانيم به جنگ پيچيدگی برويم. به ابزارهای ديگری نيز نياز داريم. آيا می‌دانيد اين ابزارها چه هستند؟ خوشحال می‌شوم نظرتان را اعلام نماييد.

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

http://www.itmweb.com/essay550.htm

بازگشت يک مرد بزرگ و يک معلم دوست‌داشتنی

  • یوسف مهرداد بی‌بالان

شب وصل است و طی شد نامه هجر
سلام فيه حتی مطلع الفجر

تمامی کسانی که آقای دکتر رامان رامسين را در دانشگاه صنعتی شريف می‌شناسند بر اين نکته متفق‌القولند که ايشان انسانی بزرگوار و استادی با دانش و معلمی دل‌سوز هستند. در کنار تمامی ويژگی‌هاي علمی‌شان، يک معلم اخلاق و نمونه‌اند.
من آن قدر به ايشان ارادت داشتم که حتی مسائل شخصی‌ و کاری‌ام را برايشان بازگو می‌کردم و ايشان با سعه صدر گوش فرا می‌دادند و راهنمايی می‌کردند.اين موضوع نه تنها در مورد من، که در مورد بسياری ديگر از دانشجويانش صادق بود.
چند سالی بود که ايشان برای ادامه تحصيل و اخذ مدرک دکترا به خارج از کشور تشريف برده بودند و ما از نعمت ديدارشان و کسب معرفت از محضرشان محروم بودیم. سعادت با جامعه انفورماتيک ايران يار بود و ايشان پس از اتمام تحصيلشان به ايران برگشتند.
بازگشت ايشان را به جامعه انفورماتيک ايران، دانشجويانش و به خصوص به ارادتمندانش تبريک عرض می‌کنم.
مطالعه رساله دکترای ايشان با عنوان The Engineering of an Object-Oriented Software Development Methodologyرا از دست ندهيد.

ايشان ترم آينده، درسهای طراحی شیءگرا و متدولوژی‌های شیءگرا را ارائه خواهند نمود که حضور در کلاس ايشان را به همه شما توصيه می‌کنم.

گستره مفاهيم و اصول شیءگرا

  • یوسف مهرداد بی‌بالان

آقای بهروز بختياری که نويسنده وبلاگ زيبا و پرمحتوای ooa.blogfa.com هستند، در مورد نوشته من درباره ذينفع‌های پروژه، ابراز لطف کرده بودند و اين موضوع باعث شد تا من با وبلاگ ایشان آشنا گشته و از مطالب ایشان استفاده نمايم.
وقتی مطالب ايشان در مورد مفاهيم شیءگرا را مطالعه می‌کردم، نکته‌ای برایم جالب آمد که آن را با ذکر خيری از دوران دانشجويی‌ام عرض می‌کنم.
وقتی که من درس مهندسی نرم‌افزار را با استاد عزيزم آقای مهندس سیدابراهيم ابطحی می‌گذراندم، از ايشان خواهش کردم که اجازه بدهند تا من سميناری در مورد مفاهيم شیءگرا داشته باشم. ايشان نيز لطف کردند و موافقت نمودند.
پس از اتمام سمينارم، استاد نکته‌ای را اشاره کردند که آن موقع منظورشان را درست برداشت نکردم و بعدها به نکته مطلبشان پی بردم.ايشان در آن جلسه فرمودند که نگاه شما به مفاهيم شیءگرا در سطح برنامه‌نويسی متمرکز شده است، در حالی که اين مفاهيم گستره وسيع‌تری را در بر می‌گيرند.
برای اين که منظورشان را بيشتر توضيح دهم، اجازه بدهيد در مورد اصل Encapsulation که در فارسی آن را لفاف‌بندی، محصورسازی و مخفی‌سازی ترجمه کرده‌اند، مطالبی را عرض کنم.
اين اصل وقتی در سطح برنامه‌نويسی مطرح می‌شود، در ذهن اين موضوع را تداعی می‌کند که شیء ساختار و رفتارش را مخفی می‌کند، ساختار و رفتاری که استفاده کننده برای استفاده نيازی به دانستن آن ندارد. درست مانند مثالی که دوستمان در وبلاگش آورده است.
اما گستره اين به مراتب بيش از سطح اشيای سيستم است.
در تعريف لفاف‌بندی گفته شده است که «لفاف‌بندی يعنی در اختيار گذاشتن مواردی که استفاده کننده برای استفاده به آن نياز دارد و حذف مواردی که استفاده کننده برای استفاده به دانستن آن نياز ندارد». دقيقاً مثل فيلم‌های پليسی و مافيايی که متهم برای اينکه اطرافيانش را در امنيت قرار دهد، به آن‌ها می‌گويد: هر چه کم‌تر بدانيد به نفع شماست.
اين مفهوم در هر سطحی قابل به کارگيری است. به عنوان مثال فرض کنيد می‌خواهيم اين مسأله را حل و طراحی کنيم: سيستم انبار پس از ثبت رسيد بايد سندی را در سيستم حسابداری ثبت نمايد. خوب اصل لفاف‌بندی به ما می‌گويد که سيستم انبار بايد موارد لازم جهت انجام کارش را بداند. اين موارد شامل سرويسی است که سيستم حسابداری در اختيارش قرار می‌دهد به علاوه ساختاری است که اين سرويس جهت دريافت اطلاعات لازم برای ثبت سند، تعبيه کرده است.
(boolean AccountSystem.AccountingService.SaveVoucher(AccountSystem.AccountInfo accInfo))
حال سيستم انبار نيازی به دانستن چگونگی ثبت سند در سيستم حسابداری (شامل طراحی داخلی، طراحی بانک اطلاعاتی، الگوريتمهای محاسباتی و قوانين کاری) ندارد و نبايد داشته باشد. چرا؟ برای اينکه مانند فيلم‌های مافيايی «در امان باشد». از چه؟ از تغييرات داخلی سيستم حسابداری (شامل تغيير طراحی، طراحی بانک، الگوريتمها و قوانين کاری).
به عبارت ديگر تأکيد بر اين است که واسط(interface) يعنی تعريف سرويس از نحوه پياده‌سازی(implementation) جدا باشد. اين مفهوم نه تنها در سطح اشياء، بلکه در هر سطحی قابل کاربرد است. اين مفهوم، يکی از اصول دنيای شیءگراست و در بر طراحی تمامی اجزای آن مانند سيستم، زيرسيستم، مولفه و غيره نيز حاکم است.

برای خروج از جستجو کلید ESC را بفشارید