دوستان پیام نور
به اطلاع برسونم که انتخاب واحد دانشجویان دانشگاه پیام نور از تاریخ 21/11/1387 شروع شده است لذا برای انتخاب واحد باید به سایت مراجعه کنید و زمان انتخاب واحدتان را مشخص کنید
لازم به ذکر است که از زمان مشخص شده توسط سیستم فقط 72 ساعت مهلت دارید که انتخاب واحد کنید
طراحی نرم‌افزار از سال‌ها پیش در محافل محققان و مهندسان نرم‌افزار مورد بحث است. معمولاً بحث در مورد این موضوع است که طراحی سیستم نرم‌افزاری بر اساس سورس‌کدهای نرم‌افزار استوار است و دیاگرام‌ها و طرح‌های ابتدایی می‌تواند در پیاده‌سازی نرم‌افزار به ما کمک کند، ولی نمی‌توان گفت تمامی مراحل طراحی یک نرم‌افزار به آن دیاگرام‌ها وابسته است. در واقع این بحث بیان می‌کند که سورس‌کدهای برنامه از دیاگرام‌های UML مجزا نیست.
اگر تا به حال در تیم‌های نرم‌افزاری حضور داشته‌اید و پروژه‌های نرم‌افزاری پیاده‌سازی نموده‌اید، حتماً با اشکالاتی، برخورد کرده‌اید. اگر خیلی خوش‌شانس باشید، در شروع پروژه مشتری یا همان کلاینت، اطلاعات دقیقی را از سیستمی که نیاز دارد در اختیار شما قرار خواهد داد. اگر خیلی زرنگ و باز خوش‌شانس باشید، در همان جلسه اول مصاحبه با مشتری می‌توانید تصویری کلی از نرم‌افزاری که قرار است تهیه شود را در فکر خود تجسم کنید و شروع به طراحی و پیاده‌سازی قسمت ابتدایی برنامه نمایید. با این حال صبر کنید؛ انگار با مشکلی روبهرو شده‌اید! بله کوچک‌ترین تغییری از طرف مشتری تمام برنامه شما را با مشکل روبهرو می‌سازد و پروژه شما دچار تغییراتی می‌شود. از جمله مشکلاتی که ممکن است برای شما پیش بیاید، میتوان به موارد زیر اشاره کرد:
- ممکن است ماجول‌های برنامه بسیار سخت طراحی شده باشند. در ابتدا برنامه‌نویسان کدهای هر ماجول را بسیار منظم و قابل فهم برای سایر اعضای تیم آماده می‌کنند، ولی به مرور زمان و ایجاد تغییراتی در متن کدها، به کدهایی تبدیل می‌شوند که فهمیدن آنها بسیار سخت خواهد بود.
- کدهای نرم‌افزار ممکن است دچار تکرارهای غیرضروری شوند و قطعه‌ای از کد چندین بار در طول برنامه تکرار شود که در نتیجه باعث سردرگمی برنامه‌نویسان تیم خواهد شد و طبیعتاً تغییرات در برنامه را با مشکلاتی روبهرو خواهد کرد. مثلاً تصور کنید که در برنامه با اشکالی روبهرو شده‌اید و آن را مرتفع کرده‌اید، ولی وقتی برنامه را مجدداً کامپایل می‌کنید، متوجه می‌شوید برنامه باز اشکال دارد. در نتیجه مجبور می‌شوید تمام قسمت هایی را که این اشکال در آن وجود دارد، اصلاح کنید.
- کدهای برنامه ممکن است دارای اجزایی باشند که جز افزودن پیچیدگی به برنامه سود دیگری نداشته باشند. این اشکال معمولاً وقتی پیش میآید که برنامه‌نویسان پروژه امکاناتی که احتمال می‌دهند در آینده به آن نیاز است را از ابتدا در برنامه قرار می‌دهند که باعث پیچیدگی در متن برنامه خواهد شد.
- یکی از اشکالات دیگری که ممکن است در پروژه‌های نرم‌افزاری پیش آید این است که وقتی برنامه‌نویسان با اشکال یا تغییری در برنامه مواجه می‌گردند، بیش از یک راه‌حل برای آن تغییر پیدا می‌کنند. برخی از این تغییرات قالب طراحی نرم‌افزار را حفظ می‌کند و برخی تنها با هک کردن سورس‌کدها این تغییر را به وجود می‌آورند و این کار باعث به‌هم ریختگی و از هم گسیختگی طراحی یک نرم‌افرار و کدهای آن می‌شود.
- معمولاً تغییرات در برنامه باعث شکنندگی سیستم نرم‌افزاری می‌شوند.
- معمولاً از آنجا که هر تغییر در برنامه باعث تغییراتی در قسمت‌های مختلف برنامه می‌شود، تغییرات در سیستم‌های نرم‌افزاری معمولاً دشوار است.
در مدل برنامه‌نویسی چابکانه اعضای تیم با رعایت اصول این مدل نرم‌افزاری نمی‌گذارند اشکالات ذکرشده در سیستم نرم‌افزاری به وجود آید. در ادامه با ذکر یک مثال بسیار ساده، طراحی چابکانهِ این مثال مورد بررسی قرار می گیرد.
منبع : ماهنامه شبکه - خرداد 1386 شماره 76
با سلام مجدد خدمت دوستان
در ادامه پست قبلی کل مطلب مربوط به طراحی چابکانه را آپلود کرده ام .
امیدوارم مورد استفاده دوستان واقع شود .
با سلام خدمت دوستان و عرض تسلیت به مناسبت ایام سوگواری مولی الموحدین حضرت علی (ع) و قبولی طاعات و عبادات شما عزیزان .
در این پست چند لینک در رابطه با قراردادهای نرم افزاری و پشتیبانی نرم افزار برای استفاده شما عزیزان قرار گرفته شده است .
نمونه قرارداد خدمات و نگهداری سخت افزار و نرم افزار
قواعد اساسی در تنظیم قراردادهای انفورماتیک
سلام خدمت دوستان
"سلام،
از مطالبتون ممنون،
ولی ای کاش در مورد انوع ارتباطات کلاس و اینکه چطور میتوان نوع ارتباط رو تشخیص داد هم توصیح میدادید"
جمله بالا نظر یکی از دوستان است که به نکته خوبی اشاره کرده اند و من هم با برسی در سهای چهارده و پانزده مربوط به آموزش رشنال متوجه این کمبود شدم و تصمیم گرفتم که در یک پست جداگانه به این مطلب اشاره کنم .
**************************************************
انواع رابطه ها در کلاس دیاگرام
در کلاس دیاگرام چهار نوع رابطه وجود دارد که می توانید آنها را بین کلاسها برقرار کنید . association , dependency, aggregation , generalization
Association رابطه های معنایی بین کلاسها هستند که در نمودار کلاس بوسیله یک خط ساده به هم متصل می شوند . وقتی یک association دو کلاس را به هم وصل می کند ، هر کلاس می تواند از طریق یک نمودار توالی یا همکاری به کلاس دیگر پیغام بفرستد . association می توانند دو طرفه یا یک طرفه باشند . با یک association ، رز(Rose) صفتها را در کلاسها قرار می دهد . برای مثال اگر یک رابطه association بین یک کلاس خانه و یک کلاس شخص وجود دارد ، Rose یک صفت شخص (Person) را درون خانه (House) قرار می دهد تا به خانه بگوید که چه کسی صاحب آن است و یک صفت خانه را درون شخص قرار می دهد تا به شخص بگوید صاحب چه خانه ای هستند .
Dependency شبیه به association ها هستند با یک تفاوت که همیشه یک طرفه هستند . Rose در یک رابطه Dependency صفتها را برای کلاسها تولید نمی کند . Dependency ها با فلش خط چین نشان داده می شوند .
Aggregation ها یک فرم قویتر از association ها هستند . یک Aggregation یک رابطه بین یک واحد کل و بخشهای آن می باشد . برای مثال رابطه بین یک کلاس ماشین را در نظر بگیرید با یک کلاس موتور یا یک کلاس بدنه . aggregation ها مانند یک خط با یک لوزی در کنار کلاسی که واحد کل را نمایش می دهد نشان داده می شوند .
Generalization ها برای نشان دادن یک رابطه وراثتی بین کلاسها استفاده می شوند .
پیدا کردن رابطه ها
1) 1) کار را با بررسی نمودارهای توالی و همکاری آغاز کنید . اگر کلاس A از طریق یک نمودار توالی یا همکاری پیامی را به کلاس B بفرستد ، یک رابطه باید بین آنها وجود داشته باشد . معمولاً رابطه های که با این روش پیدا می کنید ، association یا dependency هستند .
2) 2) کلاسهایتان را بررسی کنید و به دنبال رابطه های کل به جزء بگردید . هر کلاسی که از سایر کلاسها تشکیل شده ، ممکن است در یک aggregation شرکت کند .
3) 3) کلاس هایتان را بررسی کنید و به دنبال رابطه های generalization بگردید . سعی کنید کلاسهایی را پیدا کنید که انواع مختلف داشته باشند . مثلاً در یک شرکت ممکن است کارمند به دوصورت ساعتی و حقوقی باشد ، در این صورت ما یک کلاس کارمند ساعتی و یک کلاس کارمند حقوقی داریم که هر کدام از یک کلاس کارمند ارث بری دارند .
4) 4) کلاسها یتان را برای یافتن رابطه های بیشتر generalization بررسی کنید . سعی کنید کلاسهایی را پیدا کنید که مشترکات بسیار زیادی باهم دارند . مثلاً در یک دانشگاه هم دانشجو و هم استاد و هم کارمند از کلاس انسان ارث بری دارند .
در رابطه با کلاسهایی که خیلی رابطه بین آنها است محتاط باشید . یک معیار برای یک برنامه خوب طراحی شده ، کم بودن تعداد رابطه ها در سیستم است . یک کلاس با تعداد زیادی رابطه نیاز دارد تا درباره تعداد زیادی کلاسهای دیگر بداند . در نتیجه استفاده مجدد می تواند سخت تر شود و سختی نگهداری می تواند بیشتر باشد . اگر هر کدام از کلاسهای دیگر تغییر کنند ، کلاس اصلی ممکن است تحت تاثیر فراوان قرار گیرد .
