کامپیوتر

آموزش

قفل گذاری روی پوشه بدون نرم افزار

برای این کار مثل زیر عمل کنید.

1- از منوی Start روی Run کلیک کنید تا منوی Run ظاهر بشه خوب حالا توش تایپ کنید cmd و اینتر بزنید تا ms-dos promt ویندوز ظاهر بشه

2-خب حالابه درایوی که پوشه توشه برید

برای این کار مثل زیر عمل کنید.

1- از منوی Start روی Run کلیک کنید تا منوی Run ظاهر بشه خوب حالا توش تایپ کنید cmd و اینتر بزنید تا ms-dos promt ویندوز ظاهر بشه

2-خب حالابه درایوی که پوشه توشه برید

3-خب حالا فرمان ren رو اجرا کنید و یه فاصله بدید و اسم پوشه رو وارد کنید و بازم یه فاصله و ودوباره اسم پوشه رو وارد کنید واین فرق که بعد از اسم پوشه بدون هیچ فاصله ای یه نقطه بذارید و کد زیرو بدید

({2559a1f2-21d7-11d4-bdaf-00c04f60b9f0})

یعنی مثل این خط فرمان:

x:ren folder folder.{2559a1f2-21d7-11d4-bdaf-00c04f60b9f0}

تذکر: به جای(x) اسم درایو و به جای folder اسم پوشه خودتونو بدید.

4-خب حالا اینتر کنید و تمام . توی محیط ویندوز به جایی که پوشه بوده برید اگه خوب کارتون رو انجام داده باشید فلدر به شکل یه قفل در اومده

5- برای برگردوندن این پوشه به حالت اولیه باید تمام مراحل رو انجام بدید فقط توی تغییر نام از اون کد استفاده نکنید .

قفل گذاری روی پوشه

برای این کار مثل زیر عمل کنید.

1- از منوی Start روی Run کلیک کنید تا منوی Run ظاهر بشه خوب حالا توش تایپ کنید cmd و اینتر بزنید تا ms-dos promt ویندوز ظاهر بشه

2-خب حالابه درایوی که پوشه توشه برید

3-خب حالا فرمان ren رو اجرا کنید و یه فاصله بدید و اسم پوشه رو وارد کنید و بازم یه فاصله و ودوباره اسم پوشه رو وارد کنید واین فرق که بعد از اسم پوشه بدون هیچ فاصله ای یه نقطه بذارید و کد زیرو بدید

({2559a1f2-21d7-11d4-bdaf-00c04f60b9f0})

یعنی مثل این خط فرمان:

x:ren folder folder.{2559a1f2-21d7-11d4-bdaf-00c04f60b9f0}

تذکر: به جای(x) اسم درایو و به جای folder اسم پوشه خودتونو بدید.

4-خب حالا اینتر کنید و تمام . توی محیط ویندوز به جایی که پوشه بوده برید اگه خوب کارتون رو انجام داده باشید فلدر به شکل یه قفل در اومده

5- برای برگردوندن این پوشه به حالت اولیه باید تمام مراحل رو انجام بدید فقط توی تغییر نام از اون کد استفاده نکنید .

+ نوشته شده در  دوشنبه هشتم مهر 1387ساعت 23:25  توسط حامد   | 

10 مورد ضروری RUP

برای کسی که اولین بار با RUP  (که دارای 4 فاز، 9 دیسیپلین، 31 نقش، 103 دست‌آورد، 136 فعالیت، بعلاوه رهنمودها، چک‌ لیست‌ها و راهنمای ابزار می‌باشد) مواجه می‌شود این سؤال پیش می‌آید که ”چطور می‌توان از میان این همه موارد تعیین کنیم که کدام یک برای پروژه ما مورد نیاز است؟“، ”آیا به این یکی نیاز دارم؟“، ”آیا RUP فقط برای پروژه‌های بزرگ است؟“ و پاسخ نیز اغلب به این صورت است : ”خب بستگی دارد به ... “ در این مطلب یک لیست از ده مورد اساسی و ضروری RUP که می‌تواند نقطة شروعی برای چگونگی بکارگیری RUP در هر پروژه باشد معرفی می‌شود. البته ضروری است که چارچوب کلی RUP که یک فرآیند تکراری و تکاملی  است  لحاظ شود.
این ده مورد عبارتند از :

1- تصویر کلی ( Vision) – تولید یک تصویر کلی
داشتن یک تصویر کلی واضح، برای تولید محصولی که نیازهای واقعی ذی‌نفعان را برآورده سازد، کلیدی است. تصویر کلی عصاره‌ای از دیسیپلین نیازمندی‌ها در RUP بدست می‌دهد : تحلیل مسأله، شناخت نیازهای ذی‌نفعان، تعریف سیستم و مدیریت نیازمندی‌ها(زمانی که تغییر می‌کند).
2- طرح (برنامه) – مدیریت طرح
طرح‌ریزی خوب روند تولید محصول تأثیر کاملا مستقیمی بر روی کیفیت خوب محصول خواهد داشت. در RUP، طرح تولید نرم‌افزار (Software Development Plan)، همه اطلاعات مورد نیاز برای مدیریت پروژه را گرد‌آوری می‌کند.
3- لیست مخاطرات- شناسایی و کاهش ریسک‌ها
یک دستور اساسی RUP، شناسایی و رفع هرچه زودتر به ریسک‌های عمده پروژه است. لیست ریسک‌ها، به منظور در نظرگرفتن ریسک‌های شناخته شده در راه موفقیت پروژه است.
4- موارد مهم – تعیین و ردیابی موارد مهم
ارتباط باز و مداوم با داده‌های عینی که مستقیما از فعالیت‌های در حال انجام مشتق می‌شوند، و تکمیل پیکربندی محصول در هر پروژه، اهمیت دارد.
5- طرح تجاری (Business Case)
طرح تجاری، اطلاعات لازم را از نقطه نظر تجاری فراهم می‌کند؛ به منظور تعیین اینکه آیا این پروژه ارزش سرمایه گذاری دارد یا نه؟
6- معماری – طراحی یک معماری بر اساس مؤلفه
در RUP، معماری یک سیستم نرم‌افزاری (در یک مقطع خاص)، سازمان یا ساختار مؤلفه‌های مهم سیستم است که از طریق واسط‌ها با مؤلفه‌های متشکل از مؤلفه‌های کوچکتر و واسط‌های آنها ارتباط دارند. در واقع پاسخ به این سؤال است که تکه‌های اصلی کدامند و چگونه با هم جور می‌شوند؟
7- محصول - ساخت و تست گام به گام (افزایشی) محصول
عصاره جریان کارهای پیاده‌سازی و تست در RUP، کدنویسی، ساخت و تست گام به گام مؤلفه‌های سیستم، با نشرهای قابل اجرا در پایان هر تکرار بعد از فاز آغازین است.
8- ارزیابی (Evaluation)
ارزیابی تکرار، نتایج یک تکرار، میزان برآورده شدن معیار ارزیابی، دروس آموخته شده و تغییرات فرآیند که باید پیاده‌سازی شوند، را دربر می‌گیرد
9- درخواست‌های تغییر (Change Request)
عصاره مدیریت پیکربندی و تغییرات، مدیریت و کنترل محدوده‌ پروژه در هنگامی است که تغییرات در طول چرخه حیات پروژه رخ می‌دهد و زمانیکه باید هدفِ در نظر گرفتن کلیه نیازهای ذی‌نفعان و برآورده کردن آنها، تا حد امکان، مورد نظر باشد.
10- حمایت از کاربر
حمایت از کاربر، باید دست‌ کم، شامل یک راهنمای کاربر باشد که شاید از طریق راهنمای برخط پیاده‌سازی شده و ممکن است شامل یک راهنمای نصب و یادداشت‌های نشر باشد، و بسته به میزان پیچیدگی محصول، ممکن است ابزار آموزشی نیز مورد نیاز باشد و بالاخره یک صورت از مواد همراه (BoM) با هر نوع بسته‌بندی محصول(در صورت وجود بسته‌بندی متنوع محصول).

+ نوشته شده در  یکشنبه دوم تیر 1387ساعت 6:24  توسط حامد   | 

مستندات دیاگرام متن

 

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

1)     فرم تشریح موجودیتهای خارجی :

 

نام موجودیت

کد موجودیت

شرح موجودیت خارجی

استاد

M2

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

دانشجو

M1

....

 

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

2)     فرم تشریح خطوط جریان داده :

 

از

به

نام خط جریان

شرح خط جریان

مرجع

-

M1

برگه پرسش نامه

برگه ای است که شامل سولاتی در مورد اساتید می باشد و در اختیار دانشجویان قرار می گیرد تا به آن پاسخ دهند .

فرم 1

 

 

 

 

 

 

فرم تشریح خطوط جریان شامل پنج ستون است که توضیح آن به شرح زیر است :

·        از : مبدا خطوط جریان می باشد . اگر مبدا خود سیستم باشد از " - " استفاده می کنیم .

·        به : مقصد خطوط جریان می باشد . اگر مقصد خود سیستم باشد از " - " استفاده می کنیم .

·        نام خط جریان :کلمه یا کلماتی است که بر روی خط جریان نوشته می شود که هدف خط جریان را در دیاگرام متن تشریح می کند .

·        شرح  خط جریان : شرح کامل خط جریان در این ستون نوشته می شود .

·        مرجع : مرجع در واقع شماره فرمی است که در سیستم دستی از آن استفاده می شود . ما در ابتدای تجزیه و تحلیل خود باید تمامی فرمهایی که در سیستم دستی مورد استفاده قرار می گیرد را جمع آوری کرده و آنها را شماره گذاری کنیم

+ نوشته شده در  یکشنبه دوم تیر 1387ساعت 6:21  توسط حامد   | 

دیاگرام گردش مستندات

 

در متد SSADM   پس از ترسیم دیاگرام متن باید دیاگرام گردش مستندات ترسیم شود .

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

 

نمونه دیگر از دیاگرام گردش مستندات مربوط به یک سیستم ورود و خروج

+ نوشته شده در  یکشنبه دوم تیر 1387ساعت 6:20  توسط حامد   | 

Rapid application development یا RAD

RAD یا Rapid application development اولین بار توسط جمیز مارتین در سال 1991 پیاده سازی شد. این متدلوژی بر پایه تکرار مرحله توسعه و تولید پروتوتایپ است. روش RAD شامل یک مصالحه میان قابلیت استفاده، خصوصیات و سرعت اجرا است. RAD فرآیندی است که می خواهد چرخه حیات توسعه نرم افزار را تسریع کند که باعث می شود که در زمان توسعه و منابع صرفه جویی شود.
برای اطلاعات بیشتر به منبع RAD در اینجا مراجعه کنید. همچنین لیستی از ابزارهایی که از RAD پشتیبانی می کنند را از اینجا ببینید.

JAD یا Joint Application Development محبوب ترین روش Fact-Finding است که تلاش می کنم افرادی که در گیر پروژه هستند را در توسعه پروژه دخیل کند. JAD بر پایه 4 ایده است:
1- افرادی (عادی) که مشغول فعالیتی هستند بیشترین اطلاعات را در مورد آن فعالیت دارند.
2- افرادی که در زمینه IT تخصص دارند بیشترین اطلاعات را در مورد امکانات تکنولوژی دارند.
3- سیستم های اطلاعاتی و فرآیندهای تجاری به ندرت از هم جدا هستند، آنها روی محدوده مشترک یک سیستم واحد یا دفتر عمل می کنند و نتیجه آن در کل سیستم تاثیر می گذارد. و افرادی که در سیستم های مربوط کار می کنند نقش با ارزشی را در سیستم ایفا می کنند.
4- بهترین سیستم های اطلاعاتی زمانی طرااحی می شوند که تمام گروه ها مشتراکا با هم کار کنند.
اطلاعات بیشتر را می توانید از اینجا ببینید.
+ نوشته شده در  یکشنبه دوم تیر 1387ساعت 6:19  توسط حامد   | 

بررسی روند تولید نرم افزار به روشXP

XP یا Extreme Programming در واقع یک فرآیند توسعه نرم افزار عمیق و منظم می باشد. این روش از سال 1990 توسط شخصی به نام Kent Beck به همراه Ward Cunningham این فرآیند را برای توسعه آسان نرم افزارها ایجاد و در سالهای بعد آن را تکمیل کردند به نحوی که از سال 1996 به عنوان یک روش مناسب کاربردهای خود را نشان داد و هم اکنون در شرکتهای مختلفی با سایز های متفاوت مورد استفاده می باشد. یکی از دلایل موفقیت این روش تاکید آن بر رضایت مشتری است. این متدلوژی برای ارائه چیزی که واقعا مشتری نیاز دارد طراحی شده است. همچنین این روش کمک می کند که نیازهای مشتری را حتی در پایانی ترین مراحل تولید در سیستم اعمال کنند. از دیگر تاکید های روش توجه به کار گروهی است و این کار را با ساده ترین و مؤثرترین راه انجام می دهد.. مدیران، مشتریان و توسعه دهندگان همه اعضای تیمی هستند که مختص تحویل یک نرم افزار خوب (با کیفیت) ایجاد شده است.
XP یک پروژه نرم افزاری را در چهار وجه ، ارتباطات (Communication) ، سادگی (Simplicity) ، بازخورد ها (Feedback ) و شجاعت (Courage ) بهبود می بخشد: 1-برنامه نویس XP ابتدا با مشتری ارتباط بر قرار می کند، سپس برنامه سازی را دنبال می کند. 2- آنها طراحی خود را ساده و تمیز نگه می دارند. 3- با آزمایش نرم افزارهای خود ار روز اول بازخورد می گیرند. 4- سیستم را در اولین فرصت به مشتری تحویل می دهند و تغییرات را به محض پیشنهاد دادن انجام می دهند. بر پایه XP، برنامه نویسان قادر خواهند بود که شجاعانه به تغییرات نیازها و فنآوری پاسخ دهند.
XP شامل اجزا زیاد کوچکی است که در نگاه اول هر کدام معنی خاصی نمی دهد اما وقتی بایکدیگر ترکیب شدند یک تصویر کامل می سازند. این یک فاصله اساسی با توسعه سنتی نرم افزارها ایجاد می کند. در یک کلام XP متفاوت است.
مطلب بالا خلاصه است از ادعاهایی که طراحان XP در مورد روش خودشان مطرح کرده اند. در سلسله مطالبی، به مرور این روش خواهیم پرداخت.
اعضای تیم در پروژه
در روش اکس‌پی مشتری نرم‌افزار باید جزئی از تیم اجرایی پروژه باشد و برنامه‌نویس و مشتری باید با هم کار کنند و از مشکلات و نیازهای هم مطلع باشند. در اکس‌پی مشتری به کسی یا گروهی گفته می‌شود که نیازهای برنامه و اولویت‌های آن نیازها را خوب می‌داند. در این روش مشتری و برنامه‌نویسان باید در یک اتاق کار کنند (البته تبصره‌ای نیز در این قسمت وجود دارد که می‌گوید مشتری می‌تواند تا حداکثر پنجاه متر از برنامه‌نویسان دور باشد).
داستان‌های کاربران یا User Stories
برای این‌که بتوانیم برای پروژه‌ای برنامه‌ریزی کنیم، باید از نیازهای کاربران مطلع باشیم. البته نیازی نیست که همه چیز را از همان اول بدانیم و از جزئیات نیازهای کاربران اطلاعاتی کسب کنیم؛ زیرا آن جزئیات به احتمال زیاد در طول پروژه تغییر پیدا می‌کنند. در اکس‌پی باید در مورد هر نیاز کاربر یا Requirement مقداری با مشتری صحبت کنیم و از مشتری بخواهیم چند کلمه‌ای در مورد هر یک از نیازها روی فیش یا کاغذهای یادداشت چسب‌دار (Post-it) بنویسد‌.‌ همزمان برنامه‌نویس نیز می‌تواند برداشت خود را از آن موضوع روی کاغذی مشابه بنویسد و هر دو برگه را روی دیوار اتاق بچسبانند. این برگه‌ها می‌توانند باعث یادآوری اعضای تیم از نیازهای اولیه و همچنین سهولت در تخمین زمان و هزینه پروژه شوند.
دوره‌های زمانی کوتاه
پروژه اکس‌پی هر دوهفته یک ‌بار یک قسمت از نرم‌افزار که کارایی بالایی دارد و قسمتی از نیازهای اولیه مشتری بوده است را تحویل می‌دهد و از مشتری در مورد آن قسمت نظرخواهی می‌شود و اگر نیاز بود، نظر مشتری سریعاً اعمال می‌گردد. به این دوره دو هفته‌ای Iteration نیز می‌گویند. هر Iteration قسمتی از نرم‌افزار را با توجه به User Storiesها تولید می‌کند که چند نیاز کاربر را برآورده می‌سازد. وقتی یک Iteration شروع شد، دیگر مشتری حق عوض کردن نیازهایی که بر سر آن‌ها توافق کرده است را ندارد.
تست های قبول شده
جزئیات نیازهای کاربران که در ‌User Stories وجود دارد، در قالب Acceptance Tests) AT) که مشتری تعیین می‌کند برداشت می‌شود. این تست همزمان با Iteration می‌تواند انجام گردد و در قالب زبان‌های اسکریپتی نوشته می‌شود تا بتوان آن را چندین بار تکرار کرد. هدف اصلی ATها تست کردن برنامه و حصول اطمینان از این است که آن قسمت از برنامه نوشته می‌شود که صددرصد نیاز مشتری را برآورده می‌سازد.
این تست‌ها هر وقت که قسمت جدیدی به برنامه اضافه می‌شود و برنامه کامپایل می‌گردد، دوباره اجرا می‌شوند و اگر اشکالی داشته باشند، پیغام خطا می‌دهند. در نتیجه وقتی سیستم به اتمام رسید، می‌توان مطمئن بود که سیستم بدون خطا است.
به علا‌وه، در اکس‌پی تمامی کدها به روش Test-Driven Development تولید می‌شوند. یعنی قبل از نوشتن هر قطعه کد، باید تست آن تولید شود و کاری کرد که کد در پاس کردن Unit Test ناتوان باشد. بدین‌معنی که اول یک قطعه کد مثلاً برای افزودن دانشجوی جدید به فهرست دانشجویان می‌نویسیم، ولی چون در آن کد قطعه‌ای از کد کلاسی که insert را انجام می‌دهد وجود ندارد، برنامه اشکال می‌گیرد. حال کار گروه اکس‌پی این است که برنامه را طوری درست کنند که این تست پاس شود و به قدری روی برنامه کار کنند تا برنامه دلخواه به دست آید.
برنامه نویسی دوتایی
معمولاً در اکس‌پی برنامه‌نویسان در گروه‌های دوتایی قرار می‌گیرند و وظیفه تکمیل قسمتی از برنامه را به عهده می‌گیرند. هر دو برنامه‌نویس در مورد هر کدام از نیازهای کاربران با هم بحث می‌کنند و قدم به قدم کلاس‌های برنامه را آماده می‌کنند. بدین ترتیب که در ابتدا کلاسی را به صورت خیلی ابتدایی و بدون هیچ طراحی اولیه به وجود میآورند و این کلاس را امتحان می کنند و در صورتی که این کلاس فاقد هر گونه اشکال باشد، کد اصلی برنامه را بر اساس این امتحان کلاس می‌نویسند. وقتی یکی از برنامه‌نویسان مشغول نوشتن قسمتی از برنامه است، برنامه‌نویس دیگر وظیفه کنترل صحت این کدها را عهده‌دار است و در صورت مشاهده هر گونه اشکال، نویسنده کد را مطلع می کند.
تیم همه کاره
در اکس‌پی همه اعضای تیم همه کار می‌کنند. همه روی GUI، پایگاه اطلاعات و ... کار می کنند. این بدین منظور نیست که اعضای تیم نمی‌توانند در کار مشخصی حرفه‌ای باشند، بلکه همکاری در تمامی بخش‌های پروژه باعث خواهد شد که تجربه جدیدی کسب کنند. این تیم حق دارد کدهایی که دیگران نوشته‌اند را بارها چک کند، اشکالات آن را مشخص نماید و اگر اصلاحی دارد، آن را متذکر شود.
محیط کاری باز
تیم باید در مکانی باز کار کند. در اتاق پروژه باید میزهایی فراهم شوند که روی آن چند کامپیوتر قرار دارد. در جلوی هر کامپیوتر هم باید دو صندلی برای اعضای Pair تعبیه شود. دیوارهای اتاق باید از نقشه‌ها و طرح‌های نرم‌افزاری به همراه UML مملو باشد. صدای اتاقی که در آن کار انجام می‌شود، معمولاً پر از زمزمه‌های اعضای تیم است. شاید بگویید که در محیطی پر زمزمه که نمی‌شود کار کرد. در جواب این سؤال باید گفت طبق تحقیقاتی که در دانشگاه میشیگان انجام شده است، راندمان کار در محیط‌های کاری‌ای که در آن زمزمه باشد و سکوت محض نباشد، به دو برابر حالت عادی می‌رسد.
طراحی ساده نرم‌افزار
در اکس‌پی تیم سعی می کند طراحی نرم‌افزار را تا حد ممکن ساده انجام دهد. اعضای تیم تمام انرژی خود را فقط روی نیازهای فعلی کاربران می‌گذارند و نگران نیازهای جدیدی که ممکن است در آینده مطرح شوند، نیستند. در ابتدای کار تمرکز برنامه‌نویسان تیم به انتخاب پایگاه اطلاعاتی، انتخاب معماری نرم‌افزار و ... نیست و تمام سعی تیم این است که قسمتی از نرم‌افزار را به ساده ترین راه ممکن تحویل مشتری دهد و وقتی واقعاً به تغییرات نیاز پیدا شد، می‌توانند تغییرات لازم را اعمال نمایند.
در اکس‌پی اعضای گروه می‌توانند روند تکمیلی تولید نرم‌افزار را مشاهده کنند و در جریان کار قرار گیرند. اکس‌پی روش مناسبی برای پروژه‌های کوچک است که اعضای تیم از دو تا دوازده برنامه‌نویس تشکیل شده است؛ هرچند اصولاً اکس‌پی هیچ رویه خاص و مراحل پیوسته‌ای را مشخص نکرده است. می‌توان گفت که اکس‌پی چهار مرحله اصلی دارد:
●‌‌مرحله زمانبندی پروژه
‌‌●‌‌طراحی ابتدایی
‌‌●‌‌نوشتن کدهای برنامه
‌‌●‌‌امتحان کدهای نوشته شده
طبق تحقیقات انجام شده مشخص شده است که اکس‌پی تنها در پروژه‌های کوچک نرم‌افزاری می‌تواند مفید باشد و در پروژه‌های بزرگ، اصلاً موفق نخواهد بود. شاید به این دلیل که در این روش مستندات چندانی برای نرم‌افزار وجود ندارد و چند نفر بیشتر نمی‌توانند در مورد قسمتی از نرم‌افزار اطلاعاتی داشته باشند. همچنین نرم‌افزار تولید شده با این روش هیچ‌گونه طراحی سازمان یافته‌ای ندارد و این امر می‌تواند برای مراحل پس از نصب، یعنی تعمیرات و نگهداری سیستم، باعث بروز مشکلاتی گردد.
از جمله مزایای اکس‌پی این است که از آن جایی که یک برنامه‌نویس به صورت مستقیم کدهای برنامه را چک می‌کند، کیفیت نرم‌افزارهای تولیدی بالاتر می‌رود. همچنین از آن جایی که دو برنامه‌نویس با هم کار می‌کنند، آموزش کمتری نیاز است و در نتیجه هزینه تولید نرم‌افزار پایین میآید، اما این روش مشکلات خاصی نیز دارد. مثلاً تصور کنید اگر در یک گروه یک برنامه‌نویس تمایلی برای کار با دیگر برنامه‌نویسان نداشته باشد، چه اتفاقی خواهد افتاد؟!
متخصصان نرم‌افزار پس از تحقیقات زیاد روی این روش به این نتیجه رسیده‌اند که وقتی برنامه‌نویسی در کدهای برنامه به دنبال اشکال می‌گردد، حداکثر می‌تواند پانزده درصد از اشکالات برنامه را پیدا کند، ولی در روش‌هایی مانند اکس‌پی که دو برنامه‌نویس با هم کار می‌کنند و یکی از این برنامه‌نویسان کدها را چک می‌کند، تا چهل درصد از اشکالات ساختاری برنامه مشخص می‌شود.
+ نوشته شده در  دوشنبه بیست و هفتم خرداد 1387ساعت 4:53  توسط حامد   | 

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

 

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

فرم دیاگرام متن سیستم ارزشیابی اساتید

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

+ نوشته شده در  دوشنبه بیست و هفتم خرداد 1387ساعت 4:51  توسط حامد   | 

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

 

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

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

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

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

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

نوع سیستم :

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

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

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

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

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

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

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

+ نوشته شده در  دوشنبه بیست و هفتم خرداد 1387ساعت 4:46  توسط حامد   | 

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

 

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

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

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

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

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

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

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

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

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

ü      و غیره

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

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

+ نوشته شده در  یکشنبه بیست و ششم خرداد 1387ساعت 6:19  توسط حامد   | 

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

 

مهندسی معکوس عبارت است از توانایی گرفتن اطلاعات از کد منبع و ایجاد یا ارتقاء مدل 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 خواهد کرد .

+ نوشته شده در  یکشنبه بیست و ششم خرداد 1387ساعت 6:17  توسط حامد   | 

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

 

دوستان بخش اول مستندات 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)     تاریخ آخرین به روز رسانی چه موقع بوده است

+ نوشته شده در  یکشنبه بیست و ششم خرداد 1387ساعت 6:16  توسط حامد   | 

10 مورد ضروری RUP

 
برای کسی که اولین بار با RUP  (که دارای 4 فاز، 9 دیسیپلین، 31 نقش، 103 دست‌آورد، 136 فعالیت، بعلاوه رهنمودها، چک‌ لیست‌ها و راهنمای ابزار می‌باشد) مواجه می‌شود این سؤال پیش می‌آید که ”چطور می‌توان از میان این همه موارد تعیین کنیم که کدام یک برای پروژه ما مورد نیاز است؟“، ”آیا به این یکی نیاز دارم؟“، ”آیا RUP فقط برای پروژه‌های بزرگ است؟“ و پاسخ نیز اغلب به این صورت است : ”خب بستگی دارد به ... “ در این مطلب یک لیست از ده مورد اساسی و ضروری RUP که می‌تواند نقطة شروعی برای چگونگی بکارگیری RUP در هر پروژه باشد معرفی می‌شود. البته ضروری است که چارچوب کلی RUP که یک فرآیند تکراری و تکاملی  است  لحاظ شود.
این ده مورد عبارتند از :
ادامه مطلب ...
پنجشنبه 12 مهر ماه سال 1386
فازها و milestone های یک پروژه در RUP

RUP Phases 

 Inception (آغازین)

هدف اصلی این فاز دستیابی به توافق میان کلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد که در آن ریسک‌های نیازسنجی و تجاری مهمی وجود دارد که باید پیش از اینکه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی که بر توسعه سیستم موجود متمرکزند، فاز Inception کوتاهتر است، با اینحال این فاز برای حصول اطمینان از اینکه پروژه ارزش انجام دادن دارد و امکان‌پذیر نیز هست، انجام می‌شود. اهداف اصلی فاز آغازین شامل موارد زیر است :‌
  • بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
  • مشخص کردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می‌کند.
  • نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی
  • برآورد هزینه و زمان کلی برای کل پروژه
Elaboration (جزییات)
هدف فاز جزئیات تعیین معماری کلی سیستم به منظور فراهم آوردن یک زمینه‌ی مناسب برای قسمت عمده‌ی طراحی و پیاده‌سازی در فاز Construction است. معماری با درنظرگرفتن بیشتر نیازمندی‌های مهم (آن دسته از نیازمندی‌ها که تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسک کامل می‌شود. پایداری معماری از طریق یک یا چند نمونه‌ی اولیه ساختاری ارزیابی می‌‌شود. اهداف اصلی فاز جزئیات شامل موارد زیر است :
  • اطمینان از اینکه معماری، نیازمندی‌ها و طرح‌ها به اندازه‌ی کافی پایدارند و ریسک‌ها به اندازه‌ی کافی کاهش یافته‌اند بطوریکه بتوان هزینه و زمان‌بندی لازم برای تکمیل تولید را پیش‌بینی کرد. برای اکثر پروژه‌ها، گذر از این مرحله‌ی مهم مانند انتقال از یک عملیات سبک و سریع و با ریسک پایین به یک عملیات با هزینه و ریسک بالا همراه با اجبار سازمانی است.
  • بیان همه‌ی ریسک‌های پروژه که از نظر ساختاری اهمیت دارند.
  • ایجاد یک معماری پایه، مشتق شده از سناریوهای مهم که از لحاظ ساختاری اهمیت دارند، که این معماری ریسک‌های فنی عمده پروژه را نیز مشخص می‌کند.
  • تولید یک نمونه‌ی اولیه‌ی تکاملی از مولفه‌های با کیفیت تولیدی خوب، و همچنین یک یا چند نمونه‌ی اولیه‌ی اکتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت کاهش ریسکهای خاص مانند :‌
    • سازش‌های مربوط به نیازمند‌ی‌ها یا طراحی
    • استفاده‌ی مجدد از مؤلفه‌ها
    • عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و کاربران نهایی
  • توضیح اینکه معماری پایه از نیازمندی‌های سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌کند
  • ایجاد یک محیط پشتیبانی کننده
  Construction (ساخت)
هدف این فاز واضح سازی نیازمندی‌های باقیمانده و تکمیل تولید سیستم بر اساس معماری مبنا می‌باشد. فاز ساخت به نوعی یک فرآیند ساخت است که در آن تأکید بر مدیریت منابع و کنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و کیفیت است. در این حالت یک انتقال از تولید یک نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction وTransition می‌شود. اهداف اصلی فاز Construction شامل موارد زیر می‌باشد :
  • کمینه کردن هزینه‌های تولید با بهینه‌سازی منابع و پرهیز از دور انداختن و دوباره‌کاری غیر ضروری
  • دستیابی هرچه سریعتر به کیفیت کافی
  • دستیابی هر جه سریعتر به ویرایش‌های مفید (آلفا، بتا و سایر نسخه‌های تست)
  • کامل کردن تحلیل، طراحی، تولید و تست کارآیی مورد نیاز
  • تولید تکراری و گام به گام یک محصول کامل که آماده‌ی انتقال به محیط کاربران باشد
  • تصمیم در مورد اینکه آیا نرم‌افزار، سایت‌ها و کاربران همه برای استقرار طرح آمادگی دارند
  • دستیابی به میزانی از موازی سازی در کار تیم‌های تولید.
  Transition (انتقال)
تمرکز این فاز بر این است که تضمین نماید نرم‌افزار برای کاربران نهایی آماده می‌باشد. فاز Transition می‌تواند به چندین تکرار تقسیم شود، و شامل تست کردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات کوچک بر اساس بازخورد کاربر می‌باشد. در این نقطه از چرخه‌ی حیات، بازخورد کاربر باید بطور عمده بر تنظیم دقیق محصل، پیکربندی، نصب و نکات مربوط به قابلیت استفاده تمرکز یابد، و همه‌ی نکات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند. با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد که بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخه‌ی حیات فعلی ممکن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت کند. برای پروژه‌های دیگر، پایان فاز Transition ممکن است با تحویل کامل خروجی‌ها به گروه سومی که ممکن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده می‌باشند، همزمان شود. این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یک نسخه‌ی جدید از یک بسته نرم‌افزاری موجود ممکن است بسیار ساده باشد، در حالیکه جایگزینی سیستم کنترل ترافیک هوایی یک کشور ممکن است بسیار پیچیده باشد. فعالیت‌هایی که در طول یک تکرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشکالات، پیاده‌سازی و تست کافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تکرار شبیه به تکراری در فاز Construction می‌شود که نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل می‌شود که یک خط مبنا آنقدر بالغ شده که بتواند در دامنه‌ی کاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است که تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با کیفیت قابل قبول و مستندات کاربر، کامل شده باشند، تا انتقال به کاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد. اهداف مهم فاز Transition عبارتند از :
  • تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات کاربر
  • تست بتا و عملیات موازی همراه با یک سیستم قدیمی که در حال جایگزینی می‌باشد.
  • تبدیل پایگاه‌های داده‌ی عملیاتی
  • آموزش کاربران و نگهداری کنندگان
  • بازاریابی، توزیع و فروش برای نخستین انتشار محصول
  • تنظیم فعالیت‌ها از قبیل رفع اشکال، افزایش کارایی و قابلیت استفاده
  • ارزیابی خط مبناهای استقرار در مقایسه با تصویر کلی و معیار قابلیت قابل قبول برای محصول
  • دستیابی به موافقت ذینفع در مورد اینکه خط مبناهای استقرار کامل می‌باشند
  • دستیابی به موافقع ذینفع در مور اینکه خط مبناهای استقرار با معیار ارزیابی تصویر کلی سازگارند.
+ نوشته شده در  یکشنبه بیست و ششم خرداد 1387ساعت 6:14  توسط حامد   | 

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

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 را انتخاب کنید . به این ترتیب می توانید به کلاس خود عملیات جدید اضافه کنید .

+ نوشته شده در  شنبه بیست و پنجم خرداد 1387ساعت 7:11  توسط حامد   | 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

درس سیزدهم نمودار حالت ۳( State Chart Diagram )

 

همانطور که در درس گذشته بیان کردیم ، عمده کاربرد نمودار حالت در مدل سازی اشیاء سخت افزاری می باشد . به همین دلیل ما در این درس قصد داریم رفتار یک عابربانک را با نمودار حالت ( StateChart Diagram ) مدل کنیم .

فرض کنید یک Use Case به نام "پرداخت اتوماتیک" داریم که می خواهیم برای آن یک نمودار حالت را بر اساس فایل الصاقی به آن رسم کنیم . با هم دیگر نگاهی به این فایل الصاقی می اندازیم .

 

رفتار عابربانک

  1. دستگاه منتظر ورود کارت می ماند .
  2. با ورود کارت کلمه عبور و نام کاربری پرسیده می شود .
  3. درصورت صحت کلمه عبور و نام کاربری منویی برای فرد نمایش داده می شود که شامل سه گزینه برداشت پول ، کنترل موجودی و خروج است .
  4. اگر کلمه عبور و نام کاربری اشتباه بود دستگاه بوق می زند و تا دو بار این کار را انجام می دهد و برای بار سوم اگر کلمه عبور و نام کاربری اشتباه بود کارت را مصادره می کند .
  5. اگر منوی کنترل موجودی انتخاب شد میزان موجودی برای فرد نشان داده می شود .
  6. اگر برداشت انتخاب شد دستگاه صفحه ای را نشان می دهد که منتظر دریافت مبلغ برداشتی است .
  7. مشتری مبلغ را نوشته و Enter می کند .
  8. اگر میزان برداشتی بیشتر از موجودی بود یک پیغام به کاربر نمایش داده شود .
  9. اگر میزان برداشتی کمتر از موجودی بود پول را از خروجی دستگاه به مشتری می دهد .

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

 

قسمت اول :

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

 

 

قسمت دوم :

با انتخاب گزینه نمایش موجودی در State " نمایش عملیات ممکن " به State " نمایش موجودی " می رویم . در این State به محض ورود مشتری از میزان موجودی در حساب خود آگاه می شود و گزینه برای خروج در ادامه کار برای او نمایان می شود . با انتخاب گزینه خروج دوباره به State " نمایش عملیات ممکن بر می گردیم .

 

 

قسمت سوم :

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

 

 

 

 

+ نوشته شده در  چهارشنبه بیست و دوم خرداد 1387ساعت 6:52  توسط حامد   | 

درس دوازدهم نمودار حالت ۲ ( State Chart Diagram )

نحوه انتقال State از نوار ابزار به داخل State Chart Diagram

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

 در مورد State ها آنچه باید گفت این است که می توانید روی آن دوبار کلیک نماید . منوی زیر برای شما باز می شود . در قسمت Name می توانید نام State را وارد کنید .

قسمت مهم Action ها هستند که ما می توانیم آنچه در رابطه با Entry و Do  و Exit  گفتیم مشاهده کنیم . در تب Actions می توانید کلیک راست کنید و گزینه Insert را انتخاب کنید ، ملاحظه می کنید که یک Entry اضافه شده است .

بر روی Entry می توانید دابل کلیک کنید ، در قسمت مشخص شده در شکل زیر می توانید نوع event را مشخص کنید . عملی که باید انجام شود را در قسمت Name وارد کنید .

خواهید دید که event انتخابی شما به همراه عملی که باید انجام شود به نمودار شما اضافه شده است . در شکل زیر event انتخابی Do می باشد .

برای Transition ها نیز ابتدا آن را انتخاب کرده و سپس از مبدا به مقصد آن را می کشیم . در مورد Transition ها باید گفت آنچه مهم است event است که منجر به چنین Transition شده است .

نوع event را در قسمت Event و آرگومانهایی که به همراه event ارسال می شوند را در قسمت Arguments می توانید مشخص کنید . آنچه در شکل می بینید event است که باعث ورود به State 1 شده است .

برای انتقال سایر اشیاء به صفحه همانند گذشته عمل می کنیم . ابتدا آن را انتخاب کرده سپس در صفحه کلیک می کنیم .

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

+ نوشته شده در  چهارشنبه بیست و دوم خرداد 1387ساعت 6:51  توسط حامد   | 

درس یازدهم نمودار حالت ۱ ( State Chart Diagram )

درس یازدهم { نمودار حالت ۱ ( State Chart Diagram ) }

نمودار حالت نسبت به نمودارهای توالی و همکاری کمتر مورد استفاده قرار می گیرد . این نمودار همانطور که از نامش پیداست حالت های مختلفی که یک شی در آن قرار می گیرد را مدل می کند . در واقع این نمودار تصویری از چرخه حیات شی ( Object life cycle ) را به نمایش می گذارد .

موارد استفاده از نمودار حالت ( State Chart Diagram )

  1. اشیائی که دارای تعداد زیادی حالت هستند .
  2. اشیائی که برای Update کردن صفات خاصه خود شروط متنوعی دارند .
  3. اشیائی که معمولاً به صورت سخت افزاری هستند .
  4. اشیائی که عملکرد بعدی آنها به عملکرد قبلی شان بستگی دارد .

اشیا گفته شده بالا اشیائی هستند ، که رسم نمودار حالت معمولاً برای آنها مفید خواهد بود . بررسی نمودارهای حالت به این دلیل است که نمودارها قابلیت این را دارند که یک سری از رفتارهای کلاسها را برای ما مشخص نمایند .

ایجاد نمودار حالت

ایجاد یک نمودار حالت مشابه ایجاد نمودارهای توالی ، همکاری یا فعالیت می باشد . برای این ایجاد یک نمودار حالت کافی است بر روی Use Case مورد نظر کلیک راست کرده و میسر New > StateChart Diagram  را دنبال کنید . ملاحظه خواهید کرد که یک نمودار حالت به Use Case شما اضافه شده است . به شکل زیر توجه کنید .

نوار ابزار نمودار حالت

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

دکمه اول ( State ) : بیان کننده حالت یک شی می باشد .

دکمه دوم ( Start State ) : نقطه شروع چرخه حیات شی است .

دکمه سوم ( End State ) : بیان کننده نقطه پایانی چرخه حیات یک شی می باشد یعنی طول عمر شی در این نقطه به پایان می رسد .

دکمه چهارم ( State Transition ) : مسیری برای عبور شی از یک حالت به حالت دیگر را نشان می دهد .

دکمه پنجم ( Transition to self ) : مسیری را نشان می دهد که شی در آن تغییر حالت نمی دهد یعنی حالت تغییری پیدا نمی کند .

انواع فعالیتهای یک حالت ( State )

  1. Entry : مجموعه فعالیتهایی که در زمان ورود شی به یک حالت ( State ) باید انجام گیرند را در Entry قرار می دهند .
  2. Exit : مجموعه فعالیتهایی که در زمان خروج شی از یک حالت ( State ) باید انجام شوند را در Exit قرار می دهند .
  3. Do : حالت ( State ) برای انجام یک سری فعالیت ایجاد شده است یعنی شی به یک حالت ( State ) می رود تا یک سری عملیات را انجام دهد . این فعالیت ها با نام Do در حالت ( State ) قرار می گیرند .
+ نوشته شده در  چهارشنبه بیست و دوم خرداد 1387ساعت 6:50  توسط حامد   | 

درس دهم ( نمودار فعالیت Activity diagram )

در این نمودار چگونگی جریان انجام یک کار صرف نظر از فاعل آن مشخص می شود . بر خلاف نمودارهای همکاری که فاعلان کار ( Actors ) در جریان انجام کار وجود دارند . این نمودار را می توان برای شرح Use Case و یا هر یک از افعال ( Operation ) کلاسها ترسیم نمود .

نمودارهای فعالیت بیشتر برای مدل کردن یک عملیات مورد استفاده قرار می گیرد ، یعنی گاهی اوقات که یک عملیات پیچیده می شود ، می توان از این مدل برای توضیح بیشتر استفاده کرد . این نمودار شباهت فراوانی به فلوچارت دارد و از لحاظ معنایی نیز همان مفهوم را دنبال می کند . درمدلهای شی گرایی از این نمودار کمتر استفاده می شود زیرا همانطور که گفتیم بیشتر برای مدل سازی عملیاتها از این نمودار استفاده می شود ، حال آنکه تمرکز برانامه های شی گرا عمدتاً روی اشیاء است . با این وجود شما به عنوان یک طراح ، هرگاه که لازم دانستید از این نمودار برای شرح یک Use Case یا متد از آن استفاده کنید . این نمودار برای افرادی که به روش Process Oriented برنامه می نویسند بیشترین کاربرد را در مدل سازی سیستم پیدا می کند .

ایجاد یک نمودار فعالیت

ایجاد یک نمودار فعالیت شبیه ایجاد یک نمودار توالی یا همکاری است . ابتدا بر روی Use Case مورد نظر که می خواهیم برای آن نمودار ترسیم کنیم کلیک راست کرده و مسیر New > Activity Diagram را می رویم . مشاهده می کنید که یک نمودار فعالیت برای شما ایجاد شده است . به شکل زیر توجه کنید .

 در ادامه به معرفی اشکال استاندارد نمودار فعالیت می پردازیم .

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

دکمه اول ( Stat ) : بیانگر حالت سیستم در یک جریان کار می باشد . ( در درس Stat Diagram بیشتر در مورد آن صحبت می کنیم )

دکمه دوم ( Activity ) : بخشی از یک جریان کار ( Workflow )  است که باید انجام شود ، به عبارت دیگر قسمتی از کلمه ای است که در یک جریان کار اجرا می شود .

دکمه سوم ( Start stat ) : بیانگر شروع یک جریان کار است .

دکمه چهارم ( End stat ) : بیانگر اتمام یک حالت است .

دکمه پنجم (  Horizontal Synchronization) : نحوه کاربرد آن برای همزمانی فعالیتها است . به شکل زیر توجه کنید . در این شکل مشخص شده NewActivity1 با NewActivity2 همزمان شروع به فعالیت می کنند .

 

نکته : با میله های همزمان سازی می تواند بطور همزمان دو یا چند انتقال در سیستم رخ دهد در این صورت می توان با دو یا چند میله همزمان سازی چند فعالیت موازی را join یا fork کرد .

Fork : با اتمام یک فعالیت یا حالت چند فعالیت یا حالت شروع می شود .

Join : با اتمام چند فعالیت یا حالت یک فعالیت یا حالت شروع می شود .

دکمه ششم ( Vertical Synchronization ) : کاربرد این دکمه نیز همانند دکمه شماره 5 است . به شکل زیر توجه کنید . در این شکل نیز مشخص شده NewActivity1  با NewActivity2  همزمان شروع به فعالیت می کنند .

دکمه هفتم ( Decision ) : برای نشان دادن شرط ها و اما و اگرها از این دکمه استفاده می شود. دقیقاً مشابه شکلی است که در فلوچارتها برای نمایش شرط ها استفاده می شد .

دکمه هشتم ( Swim lane ) : با این می توان Actor ی که فعالیت را انجام می دهد را مشخص نمود . به شکل زیر توجه کنید . مشتری درخواست کالا می دهد و فروشنده کالا را به همراه فاکتور به مشتری ارائه می دهد .

اهداف و موارد کاربرد :

  1. برای مدل سازی یک جریان کار ( Work flow )
  2. برای شناسایی Use Case ها
  3. برای تشریح ارتباط میان Use Case ها
  4. برای تشریح پیچیدگی و فلوچارت یک عمل در یک Use Case
  5. برای تشریح جزئیات فرایندها در یک Activity سطح بالا

مدل کردن یک سری فعالیت با استفاده از یک Activity Diagram

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

  1. شناسایی هدف یک Work flow . سوالاتی مانند اینکه چه چیزی برای انجام شدن نیاز دارد یا وقتی Work flow به پایان رسید چه چیزی برای به پایان رسیدن نیاز دارد . برای مثال اگر Activity Diagram شما در Work flow مربوط به سفارشات یک کتاب از یک کتاب فروشی است هدف تمام Work flow ها می تواند گرفتن آن کتاب از کتاب فروشی باشد .
  2. تصمیم . نوشتن تمام شرایط یک Work flow از مرحله شروع به یک مرحله پایان . Activity Diagram دارای دستورات فلوچارتی مانند مرحله شروع و مرحله پایان که برای تعیین شروع و پایان  Work flow به کار می روند است . مرحله شروع و پایان حیطه Work flow را مشخص می کند .
  3. تعیین و تشخیص تمام فعالیتها و مرحله ها و نیاز به شناختن هدف شما دارد . مکان و نام آنها در Activity Diagram در یک دستور منطقی می آید .
  4.  تصمیم اینکه چه کسی مسئول انجام فعالیتها و مرحله در  Swim lanes هستند .
  5. اتصال تمام عناصر موجود در دیاگرام را با انتقال از شروع Work flow اصلی
  6. تعیین مکانها در دیاگرام که کجاها یک Work flow به flow های متناوب تقسیم می شود .
  7. ارزیابی دیاگرام و ملاحظه آن . اگر داری چند Work flow همزمان باشد برای همگام سازی از Joining و forking می توان استفاده کرد .
  8. ست کردن تمام اعمال و شرایط هر عنصر مدل را برآوده کردن .

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

 

 

+ نوشته شده در  سه شنبه بیست و یکم خرداد 1387ساعت 6:54  توسط حامد   | 

درس نهم نمودار همکاری ( Collaboration Diagram )

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

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

در Rose شما می توانید از روی یک نمودار توالی ( Sequence Diagram ) به آسانی یک نمودار همکاری ( Collaboration Diagram ) بسازید . برای این کار یا کلید F5 را فشار دهید یا Browser و سپس Create ( Collaboration Sequence ) Diagram را انتخاب کنید . نموداری که از این طریق ساخته می شود کمی آشفته است . برای نظم بخشیدن به نمودار خود کافی است آبجکت ها را بوسیله موس در محل های مناسب قرار دهید .

 شما همچنین می توانید بر روی Use Case مورد نظر در مرورگر کلیک راست کرده و مسیر New  Collaboration Diagram را انتخاب کنید ( به شکل زیر توجه کنید ) .

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

نوار ابزار نمودار همکاری :

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

دکمه اول : برای انتخاب یک آیتم مکان نما را به یک فلش تبدیل می کند .

دکمه دوم : یک کادر متن را به نمودار می افزاید.

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

دکمه چهارم : یادداشتی را به آیتمی درون نمودار متصل می کند .

دکمه پنجم : یک آبجکت جدید را به نمودار می افزاید .

دکمه ششم : یک نمونه کلاس جدید را به نمودار می افزاید .

دکمه هفتم : مسیری را برای ایجاد ارتباط بین دو آبجکت می سازد .

دکمه هشتم : نشان می دهد که یک آبجکت می تواند عملیات شخصی خود را فراخوانی نماید .

دکمه نهم : پیغامی را بین دو آبجکت یا از یک آبجکت به آبجکت دیگر می افزاید .

دکمه دهم : پیغامی را در جهت مخالف بین دو آبجکت یا از یک آبجکت به آبجکت دیگر می افزاید .

دکمه یازدهم : جریان اطلاعات بین دو آبجکت را نشان می دهد .

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

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

برای ایجاد یک آبجکت عامل بر روی نمودار Interaction :

  1. نمودار Interaction (توالی یا همکاری) را باز کنید .
  2. عامل را در مرورگر انتخاب کنید .
  3. عامل را از مرورگر به نمودار باز بکشید .

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

شماره گذاری پیغامها در نمودار همکاری :

در نمودار توالی چون نمودار را از بالا به پائین می خوانید ، شماره گذاری پیغامها آن چنان ضروری به نظر نمی رسد . ولی در مودار همکاری چنانچه شماره گذذاری پیغامها را حذف کنید ، اطلاعات مربوط ، تناوب خویش را از دست می دهند . با اینکه رعایت نکات ذکر شده مهم است ولی در Rose برای نمودارهای همکاری می توانید بطور دلخواه ، شماره گذاری پیغامها را غیر فعال کنید .

 برای غیر فعال کردن یا فعال کردن شماره گذاری پیغامها :

1.     از منوی Tools گزینه Options را انتخاب کنید .

2.     برگه Diagram را انتخاب کنید .

3.       کادر انتخاب Collaboration and Sequence Numbering را فعال یا غیر فعال کنید .

 

برای نمونه به نمودار همکاری « ثبت مشخصات پرسنل » که نمودار توالی آن در درس هشتم برای شما نشان داده شده بود توجه کنید .

 

در پایان آموزش نمودارهای Interaction توجه شما را به چند نکته جلب می کنم .

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

+ نوشته شده در  سه شنبه بیست و یکم خرداد 1387ساعت 6:53  توسط حامد   | 

درس هشتم نمودار توالی۲ ( Sequence Diagram)

در درس هفتم تا حدودی با نحوه ایجاد یک نمودار توالی و همچنین با نوار ابزار آن و آبجکت ها و پیغامها آشنا شدیم . حال می خواهیم از دانش خود جهت ترسی یک نمودار توالی استفاده کنیم .

برای اضافه نمودن یک آبجکت به دیاگرام خود کافی است در نوار ابزار دکمه آبجکت را به حالت انتخاب در آورده سپس در دیاگرام خود کلیک کنیم . ملاحظه می کنید که یک آبجکت به دیاگرام شما اضافه شده است . برای حذف یک آبجکت کافی است آن را انتخاب کنید سپس کلیدهای Ctrl + D را بفشارید . برای نام گذاری آبجکت کافی است بر روی آن دابل کلیک کرده یا کلیک راست نمائید و از گزینه open specification راانتخاب کنید تا پنجره ای شبیه پنجره زیر برای شما به تصویر کشیده شود .

 

شما می توانید در این پنجره نام ، کلاس ، مستندسازی ، Persistence (پایداری) و اینکه آبجکت چندین خصوصیت دارد یا خیر را تنظیم کنید .

آبجکت ها دارای Stereotype های مختلفی هستند که در زیر آنها را معرفی می کنیم .

Actor  : یا عامل که قبلاً درباره آن بحث نموده ایم .

 

Boundary : به معنای User Interface   هستند . یعنی هرکجا خواستیم بگوئیم  واسط کاربر از این شکل استفاده می کنیم . در زیر شکل آن را مشاهده می کنید .

 

Control : این آبجکت ها همان اشیاء کنترلی هستند یعنی هرکجا در تحلیل قصد نمایش اشیاء کنترلی را داشتیم از این شکل استفاده می کنیم . در زیر شکل آن را مشاهده می کنید .

 

Entity : اشیای هستند که در سیستم وجود دارند . مثلاً شی بلیط را در سیستم صدور بلیط با این شکل نمایش می دهند . در زیر شکل آن را مشاهده می کنید .

 

Table  : اگر از میان اشیاء از جدولی از پایگاه داده استفاده می کنید می توانید برای نمایش آن از این شکل استفاده کنید . در زیر شکل آن را مشاهده می کنید .

برای اضافه نمودن یک پیغام کافی است که دکمه Object Message را از نوار ابزار به حالت انتخاب در بیاوریم . سپس برای اضافه شدن پیغام بین دو آبجکت یا عامل و آبجکت ، موس را از خط عمر (life line) آبجکت یا عامل در حال ارسال پیغام به آبجکت یا عامل در حال دریافت پیغام بکشید . به شکل زیر توجه کنید .

 

اضافه نمودن یک Message to self شبیه Object Message عمل می کنیم با این تفاوت که فقط موس را بر روی خط عمر آبجکت یا عامل مورد نظر یک بار کلیک می کنیم .

برای گذاشتن اسم بر روی پیغامها کافی است روی آن دابل کلیک یا بر روی آن کلیک راست کرده و گزینه open specification را انتخاب کنیم . در پنجره ظاهر شده در قسمت Name می توانیم نامی برای پیغام خود انتخاب کنیم .

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

در زیر شما نمونه ای از یک نمودار توالی (Sequence Diagram) که برای یک Use Case طراحی شده را مشاهده می کنید .

 

 

+ نوشته شده در  سه شنبه بیست و یکم خرداد 1387ساعت 6:52  توسط حامد   | 

مطالب قدیمی‌تر