تبليغاتX
سماموس
 
  صفحه اصلی |  تماس با نویسنده  

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

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

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

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

  ساعت 20:59 به قلم مهرداد       

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

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

  ساعت 8:45 به قلم مهرداد       

 ذينفع (Stakeholder)پروژه نرم‏افزاری کيست؟

شنبه چهارم شهریور 1385

کلاس تحليل و طراحی شیءگرا(Object Oriented Analysis and Design with UML) در شرکت فراتر از دانش چند هفته‏ای  است که شروع شده است. فکر کردم بد نباشد بعضی مطالب و سوالاتی  را که در کلاس مطرح می‏شود، در وبلاگم قرار دهم.
يکی از موضوعات مهم در مديريت نيازمندهی‏ها(Requirement Management)، تعريف و مصداقهای ذينفع  در يک پروژه نرم‏افزاری است.
ذينفع در مديريت نيازمندی‏ها، عبارت از اشخاص يا گروههايی هستند که نيازها و انتظاراتشان در پروژه نرم‏افزاری برای حصول به نتيجه مطلوب، بايد منظور و برآورده گردد.
لزوماً ذينفع، کاربر پروژه نيست. در ادامه به ذکر نمونه‏هايی می‏پردازيم.
نمونه ۱: در پروژه اتوماسيون سيستم آژانسهای هواپيمايی هر چند مشتری با سيستم کار نخواهد کرد، ولی انتظارات و خواسته‏های وی جهت تحقق در سيستم نرم‏افزاری مدون می‏گردد.

نمونه ۲:  گر چه مدير شبکه و پشتيبانی شرکت کارفرما، استفاده‏ای از سيستم حسابداری نخواهد کرد، اما از آنجا که استقرار سيستم در شبکه و ساختار سخت‏افزاری تحت مديريت وی انجام خواهد شد، انتظارات وی در توليد و ساخت سيستم مورد توجه قرار می‏گيرد. به عنوان مثال، حداکثر فضايی که سيستم حسابداری می‏تواند استفاده نمايد 100 مگابايت خواهد بود.

نمونه ۳:  مدير عامل انتظار دارد که سيستم اتوماسيون اداری تا قبل از تابستان عملياتی شده باشد، چرا که انتخاب مدير عامل برای دوره بعدی در شهريورماه انجام خواهد شد و ايشان برای اينکه بتواند شانس بيشتری برای انتخاب مجدد داشته باشد، موفقيت استقرار سيستم، امتياز مهمی برای وی خواهد بود .

نمونه ۴:فروشنده بسته‏های نرم‏افزاری در پاساژهای رضا و پايتخت در پروژه سيستم حسابداری، ذينفع محسوب می‏گردند؛ چرا که انتظارات آنها از سيستم (حداقل در نحوه بسته‏بندی پاکت حاوی نرم‏افزار) يکی از عوامل موفقیت پروژه خواهد بود.
نکته ديگری که بايد توجه شود معنای لغوی عبارت است. بسياری از همکاران و دوستان، معادل فارسی اين لغت را سهامدار برگزيده‏اند که معادل shareholder می‏باشد و معادل مناسبی برای آن نيست.

  ساعت 8:45 به قلم مهرداد