X
تبلیغات
رایتل

دیاگرام متن Context Diagram

یکشنبه 27 آبان‌ماه سال 1386 ساعت 01:28 ق.ظ

اولین دیاگرام SSADM دیاگرام متن می باشد . این دیاگرام کلیات سیستم را منعکس می کند و از بیان جزئیات در این دیاگرام جداً خودداری می کنیم .

در دیاگرام متن ما سیستم را درون مربع در وسط فرم قرار می دهیم . هر فرد ، سازمان و یا ارگانی که به نحوی با سیستم در تعامل است و ما قصد داریم تعامل آن را میکانیزه کنیم را به عنوان موجودیت خارجی در نظر گرفته و درون بیضی دور سیستم قرار می دهیم . در SSADM ما می توانیم حاکثر 12 موجودیت خارجی داشته باشیم . اگر تعداد موجودیت های خارجی ما بیشتر از 12 موجودیت باشد ، سیستم را به چند بخش تقسیم کرده و برای هر بخش یک دیاگرام متن ترسیم می کنیم . به هر موجودیت یک کد نسبت می دهیم که با حروف M1,M2,M3,… مشخص می کنیم . اگر چند موجودیت تعامل یکسانی با سیستم دارند می توان آنها را با هم ترکیب کرد و تحت عنوان یک موجودیت تعامل آنها را با سیستم مشخص نمود . می توان فقط برای گزارشگیری موجودیتی که درون سیستم قرار دارد را به عنوان موجودیت خارجی در نظر گرفت . تعامل میان موجودیت های خارجی و سیستم را از طریق خطوط جریان داده ( Data Flow ) به تصویر می کشیم . این خطوط می بایست حتماً جهت دار باشند و مستقیم یا شکسته ترسیم شوند . بر روی خطوط جریان داده تعامل موجودیت خارجی و سیستم نوشته می شود . نکته اینکه از نوشتن فعل بر خط داده باید اجتناب کرد ، زیرا جهت خط نشان دهنده فعل است . در دیاگرام متن هیچ گاه تعامل میان موجودیت های خارجی را ترسیم نمی کنیم . در مواقع خاص اگر نیاز به ترسیم رابطه میان موجودیت های خارجی باشد این کار را با نقطه چین انجام می دهیم .

در انتهای دیاگرام متن نموداری تحت عنوان چارت عملیاتی ترسیم می شود که عملکرد بخشهای داخلی سیستم را به تصویر می کشد . برای شکست پروژه در SSADM قائم به فرد نیستیم بلکه قائم به عملیات هستیم .

 

  

فرم دیاگرام متن سیستم فروشگاه اسکی

فرم دیاگرام متن سیستم ورود و خروج پاسارگاد(یک نمونه دیاگرام متن دیگر)

فرم تقاضای سیستم میکانیزه

یکشنبه 27 آبان‌ماه سال 1386 ساعت 12:19 ق.ظ

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

در فرم تقاضای سیستم میکانیزه مسئله و تقاضای تائید پروژه تولید سیستم کامپیوتری درج شده است .

فرم تقاضای سیستم میکانیزه یک قرارداد کوچک نرم افزاری است که میان کارفرما و پیمان کار بسته می شود .

متقاضی : شخصی حقیقی یا حقوقی که در خواست سیستم میکانیزه کرده .

واحد مربوطه : اگر پروژه بخشی از یک ارگان باشد واحد مربوطه زیر بخش آن سیستم است .

نوع سیستم :

سیستم جدید : سیستم دستی کار می کرده و ما می خواهیم سیستم را میکانیزه کنیم .

ترمیم سیستم : سیستم میکانیزه وجود دارد ، اما بخشهایی از آن صحیح کار نمی کند .

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

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

تقاضا : درخواست برای ایجاد سیستم میکانیزه با توجه به مشکلات و نیازهای سیستم موجود .

تصمیم هیئت مدیره : تصمیم هیئت مدیره در مورد تقاضای سیستم میکانیزه .

نمونه فرم تقاضای سیستم میکانیزه

سناریو برای متدلوژی SSADM

دوشنبه 21 آبان‌ماه سال 1386 ساعت 01:34 ق.ظ

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

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

سناریو بانک اطلاعاتی ارزشیابی اساتید

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

ü      دسترسی سهل و آسان به این اطلاعات غیر ممکن است.

ü      جهت پیداکردن استاد مورد نظر زمان زیادی نیاز می باشد.

ü      نگهداری این پاسخ برگها دشوار می باشد.

ü      قابل دسترسی همگان نیست.

ü      همراه با کاغذ بازی فراوانی می باشد.

ü      و غیره

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

 فرم سناریو سیستم ورود و خروج پاسارگاد ( یک مثال دیگر )

با عرض سلام خدمت دوستان

پنج‌شنبه 17 آبان‌ماه سال 1386 ساعت 10:59 ب.ظ

 

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

یکی از دوستان در رابطه با آموزش SSADM مطلب خواسته بودند که به زودی آموزش این متدولوژی را با یک مثال عملی شروع می کنیم . در یکی از یادداشتهای مربوط به SSADM به مراحل کار را به ترتیب اشاره کرده ایم .

مهندسی معکوس با استفاده از Rational Rose :

یکشنبه 13 آبان‌ماه سال 1386 ساعت 10:09 ب.ظ

مهندسی معکوس عبارت است از توانایی گرفتن اطلاعات از کد منبع و ایجاد یا ارتقاء مدل Rose .

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

در فرایند مهندسی معکوس ، Rose نسبت به خواندن بسته ، Component ها ، کلاسها رابطه ها ، صفات و عملیات از کد اقدام خواهد کرد . هنگامی که این مدل در یک مدل Rose قرار می گیرد ، می توانید هر تغییر لازمی را ایجاد کرده سپس کد را از طریق امکانات مهندسی مستقیم Rose مجدداً تولید کنید .

گزینه هایی که در اختیار شما قرار خواهند گرفت به نسخه مورد استفاده شما بستگی خواهد داشت .

  • Rose Modeler : شامل هیچ گونه عملیات مهندسی معکوس نخواهد بود .
  • Rose Professional : شامل قابلیت های مهندسی معکوس به یک زبان است .
  • Rose Enterprise : شامل مهندسی معکوس C++ ،  Visual C++ ، Visual Basic و جاوا خواهد بود .همانطور مهندسی معکوس شمای Oracle 8 را نیز شامل خواهد بود .
  • Add_ins : متعلق به Rose قابلیتهای مهندسی معکوس در زبانهای دیگر نظیر PowerBuilder یا Forte را به شما خواهند داد .

عناصر مدل ایجاد شده در طول مهندسی معکوس :

در طول مهندسی معکوس ، Rose به جمع آوری اطلاعاتی درباره موارد زیر خواهد پرداخت .

  • کلاسها
  • صفات
  • روابط
  • عملیات
  • بسته ها
  • component ها

با استفاده از این اطلاعات ، Rose اقدام به ایجاد یا ارتقاء یک مدل Object خواهد کرد .

مستندات Use Case ( بخش اول )

شنبه 12 آبان‌ماه سال 1386 ساعت 12:32 ق.ظ

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

هر یک از مستندات Use Case برای نمایش ضمیمه ها بکار می روند . در این بخش شرح کاملی از هر یک از بخشهای الگوی Use case آماده شده است .

  تعیین هویت Use Case

        ·        شماره Use Case  : هر یک از Use Case ها باید توسط یک عدد   صحیح بی همتا مشخص شود . برای شماره گذاری متناوب Use Case هایی که در یک گروه قرار دارند از شکل X:Y استفاده می شود .

·        نام Use Case  : توضیح مختصری برای نامی که برای Use Case انتخاب شده است . این نام ها وظیفه های مورد نیاز که برای انجام نیازهای سیستم که شامل یک کار یا اسمی که شبیه مثالهای زیر است را منعکس می کند .

1)     نمایش اطلاعات قسمت عددی

2)     نشانه گذاری دستی منابع و فرامتنها و ایجاد لینک به مقصد

3)     مکان یک دستورالعمل برای CD با بروز شدن نسخه نرم افزار

·        تاریخچه Use Case  :

1)     چه کسی Use Case را ایجاد کرده است .

2)     در جه تاریخی Use Case ایجاد شده است .

3)     آخرین بار توسط چه کسی به روز شده است .

4)     تاریخ آخرین به روز رسانی چه موقع بوده است .

 

با عرض سلام خدمت دوستان

شنبه 5 آبان‌ماه سال 1386 ساعت 01:20 ق.ظ

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

با تشکر

عید سعید فطر مبارک باد

جمعه 20 مهر‌ماه سال 1386 ساعت 09:40 ب.ظ

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

با تشکر مدیریت

درس پانزدهم{ کلاس دیاگرام ۲ ( Class Diagram ) }

جمعه 20 مهر‌ماه سال 1386 ساعت 09:21 ب.ظ

Stereotype کلاسها

انواع Stereotype های کلاسها در درس هشتم توضیح داده شده است . ما فقط بطور مختصری آنها را یادآوری می کنیم .

Actor یا عامل ، Boundary : که به معنای User Interface   هستند ، Control : این آبجکت ها همان اشیاء کنترلی هستند ، Entity : اشیای هستند که در سیستم وجود دارند ، Table : جدول از پایگاه داده هستند .

صفات کلاس و افزودن صفات به کلاس

برای یافتن صفات می توان به Use Case ها رجوع کرده و در جریان رخدادها اسامی را پیدا نمود .

برای افزودن صفات به کلاس کافی است بر روی کلاس مورد نظر کلیک راست نموده و سپس گزینه New Attribute را انتخاب کنید . به این ترتیب می توانید به کلاس خود صفات جدید اضافه کنید .

 

یک صفت از لحاظ Visibility چهار وضعیت زیر را می تواند داشته باشد :

  • عمومی ( Public ) : صفت برای تمامی کلاسهای دیگر نیز قابل روئیت است . در UML از علامت + برای نمایش دادن این صفات استفاده می شود .
  • خصوصی ( Private ) : این نوع صفات برای کلاسهای دیگر قابل روئیت نیست . در UML از علامت - برای نمایش دادن این صفات استفاده می شود .
  • محافظت شده ( Protected ) : این نوع کلاس فقط بتوسط همان کلاس و فرزندانش قابل روئیت است . در UML از علامت # برای نمایش دادن این صفات استفاده می شود .
  • Implementation : فقط کلاسهای یک بسته می توانند به صفات یکدیگر دسترسی داشته باشند .

عملیات و یافتن عملیاتها

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

  1. کلاسهایی که دارای یک یا دو عملیات هستند بهتر است با هم ترکیب شوند .
  2. کلاسهایی که فاقد عملیات هستند بهتراست به عنوان یک یا چند صفت مدلسازی شوند .
  3. کلاسهایی که عملیاتهای زیادی دارند را بهتر است به دو یا چند کلاس کوچکتر تقسیم نمود .

برای افزودن عملیات به کلاس کافی است بر روی کلاس مورد نظر کلیک راست نموده و سپس گزینه New Operation را انتخاب کنید . به این ترتیب می توانید به کلاس خود عملیات جدید اضافه کنید .

 

فایل PDF درس پانزدهم

درس چهاردهم{ کلاس دیاگرام ۱ ( Class Diagram )}

دوشنبه 16 مهر‌ماه سال 1386 ساعت 01:26 ق.ظ

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

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

نمودارهای کلاس ( Class )

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

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

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

نمودار کلاس یک ابزار طراحی خوب برای تیم می باشند . آنها به برنامه نویسان کمک می کنند تا ساختار سیستم را قبل از اینکه کدی نوشته شود ، ببینند و طراحی کنند و کمک می کنند تا مطمئن شوند که سیستم از ابتدا خوب طراحی شده است .

در نمودار کلاس ، تمام کلاسهای سیستم نشان داده می شود و تمام ارتباط بین آنها بطور کامل باید مشخص شود . به نمونه ای ازاین نمودار که در شکل زیر آمده است توجه کنید . همانطور که دیده می شود هر کلاس از سه بخش تشکیل شده است .

  1. نام کلاس که می توان در ادامه نام کلاس نام بسته را نیز بکار برد .
  2. صفات که می تولند به سه صورت Private , Public , Protected باشند .
  3. اعمال که می توانند به سه صورت Private , Public , Protected باشند .

منابعی جهت استخراج کلاسها

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

 

راههای تجربی جهت شناسایی کلاسها

    1. کلاسها معمولاً حاوی اطلاعاتی هستندکه سیستم قصد دارد بصورت دارز مدت آنها را ثبت و پردازش کند .
    2. یک کلاس حتماً باید دارای صفت باشد .
    3. یک کلاس حتماً یک کلید داشته باشد که کلاس و اجزاء آن را تفکیک نماید .
    4. یک کلاس باید بیش از یک نمونه را تولید کند .

 فایل PDF درس چهاردهم

( تعداد کل: 104 )
<<    1       ...       3       4       5       6       7       ...       11    >>