تمرین طراحی شی‏ءگرا

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

آقاي محسن صبوريان تقبل زحمت نموده و در اين ترم كمك استاد (T.A) درس سيستمهاي شيءگرا خواهند بود. در كنار مباحث تحقيقي كه به دانشجويان محول خواهد گرديد، قرار بر آن است كه دانشجويان يك سري تكليف جهت تمرين و درك بهتر طراحي و پياده‏سازي سيستمهاي شيءگرا انجام دهند. اولين تمرين از اين سري تهيه و انجام آن به دانشجويان محول شده است. از آن جا كه تمرين نكات جالبي در خود دارد، صورت مسئله آن را در ادامه آورده‏ام. همين جا از آقاي صبوريان جهت تقبل اين زحمت كمال تشكر را دارم.

به نام خدا

تمرين شماره‌ي 2 (مشق عيد) – درس تحليل و طراحي شي‌گرا
عنوان:تحليل، ‌طراحي و پياده‌سازي مورد كاربرد امانت گرفتن كتاب از كتابخانه‌ي دانشكده

تاريخ تحويل: …

شرح:
در ادامه‌ي تمرينِ Domain Model Analysis، شما بايد مورد كاربرد فرايند امانت‌گيري كتاب از كتابخانه‌ي دانشکده را تحليل، طراحي و پياده‌سازي كنيد. مورد كاربرد امانت‌گيري (مسير اصلي و مسيرهاي جايگزين) در قسمت پاياني توضيح داده شده است. به عنوان تمرين تحليل، شما بايد مفاهيم موجود در محيط ، مشخصات هر يك و ارتباطات بين آن‌ها را بيابيد. براي اين کار استخراج مشخصه‌ها/صفات اصول تجريد و الگوهاي GRASP را به دقت رعايت كنيد و براي در نظر گرفتن هر صفت دليل منطقي داشته باشيد. علاوه بر اين، از روي مورد كاربرد، نمودار توالی سيستم (SSD) را (فقط براي مسير اصلي ) رسم كنيد. از آنجايي كه پيشتر در درس مهندسي نرم‌افزار رسم SSD‌ را ياد گرفته‌ايد، فقط اشاره مي‌شود كه:
SSD، نوعي نمودارِ توالي است كه در سطح تجريدِ بالا و به ازاي يك مورد كاربرد رسم مي‌شود. در اين نمودارِ توالي، سيستم به عنوان يك جعبه‌ي سياه در نظر گرفته مي‌شود و تأكيد بر ورودي‌هايي (درخواست‌ها، پيغام‌ها و …) است كه از كاربر (External Actor) به سيستم مي‌رسد، هر چند خروجي و پاسخ‌هاي سيستم هم لحاظ مي‌شود.
در فاز طراحي، بايد نمودارِ کلاسِ تهيه شده در بخش تحليل را (كه فاقد عمليات است)، با افزودن متودهاي لازم تكميل كنيد. به علاوه بايد SSD را به يك نمودارِ تواليِ مشروح، بسط دهيد.
در فاز پياده‌سازي هم بايد كليه‌ي كلاس‌ها و رابط ‌هايي را كه در دو مرحله‌ي قبل بازشناختيد، به كد تبديل كنيد. از آنجايي كه اين مورد كاربرد، يك قسمت از يك سيستم بزرگ كتابخانه مي‌باشد، براي اجرايي شدن كد پياده‌سازي شده، به دلخواه خود مي‌توانيد به‌عنوان لايه‌ي داده‌ها، از اشياء ساختگي ، پايگاه‌داده‌هاي جاسازي‌شده و يا فايل‌هاي متني ساده استفاده كنيد. به علاوه شما ملزم به پياده‌سازي رابط كاربر (UI) نيستيد و تمامي پيغام‌هاي سيستم را مي‌توانيد به صورت متن در خروجي نمايش دهيد، مورد کاربرد بايد کاملاً اجرايي شود. به عنوان مثال بايد تعدادي کتاب پيش‌فرض و همچنين اعضاي کتابخانه در مقاطع مختلف در سيستم کتابخانه داشته باشيد.

مواردي که در پايان اين تمرين بايد تحويل دهيد:
1. محصولات فاز تحليل: مستندات Domain Model و SSD. جزئيات: نمودار SSD بايد به فرمت استاندارد نمودار توالي در UML باشد. به عنوان Domain Model بايد مستندي از مفاهيم موجود در سيستم به همراه صفات و رابطه‌هاي آن‌ها تحويل داده شود. رابطه‌هاي بين مفاهيم، به عنوان نمودار کلاس در فاز طراحي تحويل داده مي‌شود.
2. محصولات فاز طراحي: نمودار کلاس و نمودار توالي. جزئيات: يک نمودار توالي و تعدادي نمودار کلاس به فرمت استاندارد UML.
3. محصولات فاز پياده‌سازي: کد اين مورد کاربرد به علاوه‌ي چندين (حداقل 10) Test Case براي آزمايش مسير اصلي و همه‌ي مسيرهاي فرعي (اعضاي کتابخانه در مقاطع مختلف و جريمه‌هاي مختلف). همان‌طور که گفته شد، شما فقط موظف به پياده‌سازي منطق صحيح اجرا شدن برنامه هستيد و نيازي به پياده‌سازي UI نيست. در عوض با اجرا کردن هر Test Case، بايد جريان عمل (و خطاهاي احتمالي) با پيغام‌هاي مناسب نمايش داده شود. در هنگام تحويل، Test Caseهاي شما اجرا و نتيجه‌ي کار مشاهده مي‌شود. يک نمونه Test Case:

mid1 = 1234; // sample member ID
showMemberfInfo(mid1); // print out member info
bid = {123, 234, 345}; // sample book IDs
addBook(mid1, bid[1]); // OK
addBook(mid1, bid[2]); // OK
addBook(mid1, bid[3]); // err! 1234 is undergraduate
mid2 = 1235; // another sample member ID.
showMemberfInfo(mid2); // print out member info
addBook(mid2, bid[1]); // err! bid[1] is already borrowed!

مورد كاربرد:
o پيش‌شرط‌ها:
1. کاربر براي ورود به سيستم بايد حساب (نام کاربري و کلمه‌ي عبور) داشته باشد.
2. متقاضي براي اخذ کتاب بايد کارت (شناسه) عضويت داشته باشد.
o مسير اصلي:
1. کاربر گزينه‌ي امانت را بر روي سيستم انتخاب مي‌کند؛
2. سيستم فرم پرسش شماره‌ي عضويت متقاضي امانت را نمايش مي‌دهد؛
3. کاربر شماره‌ي عضويت متقاضي امانت را وارد مي‌کند؛
4. سيستم مشخصاتِ عضو (شامل نام، نام خانوادگي، شماره‌ي عضويت، مقطع تحصيلي، ظرفيت مانده براي امانت و مجموع جريمه‌ي ديرکردِ تصفيه نشده) و مشخصات کتاب يا کتاب‌هاي پيشتر امانت گرفته‌شده (شامل نام کتاب، شناسه‌ي کتاب و همچنين تاريخ بازگشت آن) را نمايش مي‌دهد؛
5. کاربر شناسه‌ي کتاب را وارد مي‌کند و کليد ثبت فشار مي‌دهد. با اين کار: 1. شناسه‌ي کتاب و تاريخ امانت به همراه تاريخِ برگشتِ محاسبه شده براي عضو ذخيره مي‌شود. 2. وضعيت كتاب در سيستم به «امانت داده شده» تبديل مي‌شود.
6. در صورتي که عضو قصد دارد بيش از يک کتاب را امانت بگيرد مرحله‌ي 5 تکرار مي‌شود. پس از ثبت امانت اين مورد کاربرد به پايان مي‌رسد.
o مسيرهاي جايگزين:
[1] موجود نبودن کتاب
– در هنگام ثبت امانت، در صورتي که وضعيت کتاب، «امانت داده شده» بود، پيغام «کتاب امانت داده شده است» به کاربر نشان داده مي‌شود.
[2] پيدا نکردن کتاب
– در هنگام ثبت امانت، در صورتي که کتابي با شناسه‌ي وارد شده وجود نداشت، پيغام عدم وجود کتاب به کاربر نشان داده مي‌شود.
[3] پر بودن ظرفيت امانت عضو
– در صورت پر بودن ظرفيت امانت، در صفحه‌ي مشخصات عضو، پيغام پر بودن ظرفيت اخذ کتاب به کاربر نمايش داده مي‌شود و کليد/عمليات ثبت غير فعال مي‌گردد.
[4] منقضي شدن عضويت
– در صورتي که عضويت متقاضي امانت منقضي شده باشد، صفحه‌ي مشخصات عضو با پيغامِ منقضي شدن حساب، به کاربر نمايش داده مي‌شود و کليد/عمليات ثبت غير فعال مي‌گردد.
[5] غير فعال بودن (disabled) حساب عضو
– در صورتي که وضعيت عضويت متقاضيِ امانت «غير فعال» باشد، صفحه‌ي اطلاعات عضو با پيغام مشخصِ غير فعال بودن عضو به کاربر نمايش داده مي‌شود و کليد/عمليات ثبت غير فعال مي‌گردد.
[6] جريمه‌ي ديرکرد بيش از حد
– در صورتي كه به عضو کتابخانه جريمه‌اي بيش از 20.000 ريال تعلق گرفته‌باشد، در صفحه‌ي مشخصات عضو، پيغام جريمه‌ي بيش از 20.000 ريال نمايش داده مي‌شود و کليد/عمليات ثبت غير فعال مي‌گردد.
o قواعد کسب و کار :
دانشجويان كارشناسي، كارشناسي ارشد و دكترا، مشروط بر اينكه دانشجوي همان دانشكده باشند به ترتيب مي‌توانند 3، 4 و 5 كتاب به امانت بگيرند. دانشجويان ساير دانشكده‌ها (كه عضو كتابخانه هستند) بسته به مقطع تحصيلي‌شان، به ترتيب مجاز به امانت گرفتن 2، 3 و 4 كتاب هستند. مهلت بازگشت كتاب براي دانشجويان همان دانشكده به ترتيب 2، 3 و 4 هفته و براي دانشكده‌هاي ديگر 1، 2 و 3 هفته مي‌باشد.
جريمه‌ي ديرکرد بازگرداندن کتاب به ازاي هر روز، براي اعضاي همان دانشکده 500 ريال و براي ساير اعضا 1000 ريال مي‌باشد.

درگذشت خالق فرترن

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

John Backus خالق زبان فرترن که اولین زبان برنامه‏نويسي سطح بالا كه در سال ۱۹۵۴ ارائه شد، از دنيا رفت.

http://www.thocp.net/biographies/backus_john.htm

موزه تاريخ كامپيوتر

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

موزه تاريخ كامپيوتر را مي‏توانيد در آدرس زير ببينيد. ديدنش خالي از لطف نيست.

http://www.computerhistory.org

سال نو مبارک

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

دلم برای نوشتن تنگ شده

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

دیرزمانی است که چیزی ننوشته‏ام. پايان سال، فشار كار و هزار بهانه ديگر براي ننوشتن.

از خانم كراري هم خيلي ممنون هستم كه سري به وبلاگ زدند. برايشان در آزمون ورودي دانشگاه آرزوي مؤفقيت دارم.

براي همه عزيزان سال خوبي را آرزو مي‏كنم. اميدوارم سالي بهتر از سالهاي گذشته در پيش داشته باشيد.

تعطيلات خوش بگذرد.

مقالاتي در مورد الگوهاي طراحي(Design Patterns)

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

يك سري از مقالات نشريه شيءگرايي در مورد الگوهای طراحی (Design Patterns) را در زير آورده‏ام. مطالعه آنها را توصيه مي‏كنم.
مقالات را به صورت یکجا از اینجا دریافت نمایید.

الگو چيست؟
تأليف و ترجمه: حميده مطهريان
در اين مقاله به اختصار به تعريف الگوي نرم‏افزاري پرداخته شده است.

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

الگوهای طراحی، لزوم، کاربرد و مثال
تأليف و ترجمه: یوسف مهرداد بی‏بالان

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

الگوي طراحي سازگارساز
تأليف و ترجمه: نيوشا قريشي
الگوي طراحي سازگارساز يكي از 23 الگوي طراحي GOF است. اين الگو از جمله الگوهاي ساختاري است كه هم در حوزه كلاسها و هم در حوزه اشياء استفاده مي‏شود. الگوي سازگارساز واسط يك كلاس را به واسط كلاس ديگري به گونه‏اي تبديل مي‏كند كه مورد انتظار مشتري باشد. الگوي سازگارساز امكان همكاري را براي آن دسته از كلاس‏هايي كه به دليل داشتن واسط‏هاي ناسازگار نمي‏توانستند با يكديگر كار كنند، فراهم مي‏كند. در اين مقاله به معرفي الگوي سازگارساز با توجه به قالب GOF پرداخته شده است.

مثالهايي از کاربرد الگوي طراحي سازگارساز
تأليف و ترجمه: نيوشا قريشي، يوسف مهرداد بي‏بالان
پس از بيان مفاهيم كلي و ارائه دسته‏بندي الگوها، جهت واضح شدن بحث به ارائه مثالهاي شهودي از كاربردهاي مختلف الگوها مي‏پردازيم كه قطعا” به درك بهتر مفهوم كمك مي‏نمايد.

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

روزی روزگاری مهندس نرم‏افزار خوبي بود كه …

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

كتاب Object-Oriented Reengineering Patterns از Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz در نوع خود كتاب جالبي است. در مقدمه اين كتاب داستان خيالي را تعريف شده و پس از آن ديدگاه نويسندگان آن در مورد مهندسي نرم‏افزار بيان شده است. آوردن مقدمه كتاب از آن جهت مفيد دانستم كه در آن به چند مورد خيلي مهم اشاره شده است كه در حالي كه اشاره به ماهيت مهندسي نرم‏افزار و تفاوت ماهوي آن با ساير گرايشهاي مهندسي دارد، در عين حال بيانگر موضوع بسيار مهمي است: راه حلهاي ما هنوز جواب مسئله‏اي كه با آن روبرو هستيم، نيست(كمي آهسته، كسي نشنود). اين مسئله چيزي نيست جز تغيير و پيچيدگي.

A Fairy Tale

Once upon a time there was a Good Software Engineer whose Customers knew exactly what they wanted. The Good Software Engineer worked very hard to design the Perfect System that would solve all the Customers’ problems now and for decades. When the Perfect System was designed, implemented and finally deployed, the Customers were very happy indeed. The Maintainer of the System had very little to do to keep the Perfect System up and running, and the Customers and the Maintainer lived happily ever after.

Why isn’t real life more like this fairy tale?

Could it be because there are no Good Software Engineers? Could it be because the Users don’t really know what they want? Or is it because the Perfect System doesn’t exist?

Maybe there is a bit of truth in all of these observations, but the real reasons probably have more to do with certain fundamental laws of software evolution identified several years ago by Manny Lehman and Les Belady. The two most striking of these laws are [Lehm85a]:

  • The Law of Continuing Change: The Law of Continuing Change — A program that is used in a real-world environment must change, or become progressively less useful in that environment.
  • The Law of Increasing Complexity: As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure.

In other words, we are kidding ourselves if we think that we can know all the requirements and build the perfect system. The best we can hope for is to build a useful system that will survive long enough for it to be asked to do something new.

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