تحقیق در مورد آشنایی با UML

لینک دانلود و خرید پایین توضیحات

دسته بندی : وورد

نوع فایل :  .DOC ( قابل ویرایش و آماده پرینت )

تعداد صفحه : 26 صفحه

 قسمتی از متن .DOC : 

آشنایی با UML

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

Uml مجموعه ای از بهترین تجربیات مهندسی که موفقیتشان در مدل سازی سیستمهای بزرگ و پیچیده به اثبات رسیده است را عرضه می دارد.

تعریف UML شامل اسناد زیر می گردد :

معنا شناسی UML : که مفاهیم غنی و دستور نگارش وعلا ئم زبان مدلسازی یکپارچه را تعریف می کند UMLبه وسیله بسته ها به صورت معماری گونه لا یه بندی و سازماندهی میشود . در هر بسته عناصر مدل بر حست دستور نگارش (با استفاده از متن و عبارت زبان محدودیت شیء معروف به OCL )و معانی (با استفاده از متن دقیق) تعریف می شوند .

راهنمای علائم UML : فکر و اندیشه را تعریف می کند و مثال های خوبی را ارائه می کند. علائم UML نحو گرافیکی را برای بیان معانی توصیف شده توسط فرا مدل های UML ارائه می کند.

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

2) فراهم آوردن مکانیزم های توسعه و تخصیص برای بسط مفاهیم اساسی : بدین معنا که در عین آنکه انتظار میرود UML براساس نیازهای جدید در حوزه های خاص جفت و جور شود نمی خواهد اجبار کند تا مفاهیم اساسی و مشترک برای هر حوزه جدیدی دوباره تعریف شود و پیاده سازی گردد. البته مفاهیم اساسی نباید بیش از حد تغییر یابند. بنابراین کاربران نیازمندند که قادر باشند : 1- مدل ها را با استفاده از مفاهیم اساسی بسازند بدون آنکه مکانیزم های توسعه را برای بسیاری از برنامه های کاربردی نرمال بکار گیرند .

2- مفاهیم و علائم جدید را اضافه کنند البته برای مواردی که توسط اصول پوشیده نشده باشند .

3- زمانی که هیچ اتفاق نظر روشنی وجود ندارد تفاسیر مختلف را از مفاهیم موجود انتخاب کنند .

4- مفاهیم، علائم و محدودیت ها را برای حوزه های کاربردی خاص مشخص سازند .

3) استقلال از زبان های برنامه نویسی خاص و فرایندها ی توسعه .

4) فراهم آوردن پایه و اصولی رسمی برای درک زبان مدل سازی که برای این منظور UML تعریف رسمی از قالب استاتیک مدل را با استفاده از نمودار کلاس ارائه می کند این نمودار ، نموداری مشهور و مورد قبول در سطح وسیع برای تعییین قالب یک مدل است UML همچنین محدودیت هایی را بیا ن میدارد که در قالب زبان دقیق طبیعی و عبارات زبان محدودیت شیء (OCL ) بیان می شود .

5) تشویق به رشد بازار ابزارهای OO .

6) حمایت و پشتیبانی از مفاهیم توسعه سطح بالاتر نظیر : همکاری ها ، چهارچوب ها ،الگوها و اجزاء .

7) مجتمع سازی بهترین تجربیات : UML بدنبال آن است که بهترین تجربیات درصنعت

حوزه های مسئله ، معماری ها و … را یکجا بیاورد .

محدوده UML

زبان مدل سازی یکپارچه UML زبانی است برای مشخص سازی ساخت ،مجسم سازی و مستند سازی دست آوردهای یک سیستم متمرکز نرم افزاری اول آنکه این زبان از مفاهیم OOSE,OMT,BOOCH که متدولوژیهای متداول OOمیباشند متنج شده است . دوم ، UMLبر آنچه که در حال حاضر توسط روش های موجور فابل انجام همتند ، بان شده است . سوم زبا ن مدل سازی یکپارچه بر یک زبان مدل سازی استانارد تمرکز می کند و نه یک فرآیند استاندادر اگر چه UMLبایستی در زمینه یک فرایند به کارگیری شود تجرته نشان میدهد که در سازمان های مختلف و با حوزه های مسئله متفاوت فرایندهای متفاوتی مورد نیاز است بنابراین تلاش بر این است که ابتدا بر یک فرامدل مشترک (که معانی را یکپارچه میکند )تمرکز شود و در درجه دوم بر یک علامت گذاری مشترک (که برای فرد استنباط این معانی را فراهم میکند )تمرکز گردد مبدعین UMLبر فرایند توسعای تاکید میکنند که مورد کاربرد گرا معماری گرال و تکراری و افزایشی است .

UML یک زبان مدلسازی را مشخص می کند که اتفاق نظر جماعت شیگرا بر مفاهیم اساس مدل سازی است .

UMLبرای ایجار مدلها و نمرارهای حوزه مسئله هیچ توصیه ای نمیشود و این تجربیات و یادگیری افراد است که تشخیص استفاده از کدام نمودارها و مدل ها را به ایشان می دهد دریک دیدگاه مدل سازی UML نمودارهای گرافیکی زیر را تعریف می کند مورد کاربرد

نمودار مورد کاربرد diagram ) (use ca

نمودار کلاس (ClassDiagram)

نمودارهای رفتار: (BehaviorDiagra

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

نمودار فعالیت : )Activity Diagram(

نمودارهای تعامل Interaction Diagrams ))

نمودار توالی ((Sequence Diagram

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

* نمودارهای پیاده سازی) (Implementation Diagram

نمودار اجزاء (Component Diagram )

نموداراستقرار (Deployment Diagram)

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

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

UML 51 تحقیق درباره یو ام ال ص

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 51

فصل اول : UML

مقدمه:

با کمی اغماض می‌توان ادعا کرد که در میان شاخه‌های مختلف مهندسی در هرکدام که دارای قدمت بیشتری است، همگرایی بیشتری در اتخاذ روش و ابزار برای انجام اعمال نسبتاً مشابه از میان متخصصان و متولیان آن رشته وجود دارد. به طور مثال در حال حاضر برای اجرای یک سازه در هر نقطه از دنیا، مهندسین عمران از یک روند همسان با توالی مشابه شامل: الف)تولید طرح عمرانی ب)پیاده‌سازی نقشه ج)محاسبات سازه‌ای د)اجرا استفاده می‌کنند. ولی در رشته نوپایی چون مهندسی نرم‌افزار، گاه چنان روش‌ها متفاوت است که از دید یک ناظر خارجی، دو تیم نرم‌افزاری مختلف که هر دو قصد تولید محصولی مشابه را دارند، دو تیم در رشته‌های متفاوت به نظر بیایند. یکی از علل وجود تمایز در تولید نرم‌افزار میزان تخصص نیرو و زمان به پیاده‌سازی می‌باشد.بدین معنا که در نزد بسیاری از برنامه‌نویسان تولید نرم‌افزار معادل است با تولید کد. ولی از نظر بعضی دیگر تولید کد تنها بخشی از تولید نرم‌افزار است که در بسیاری از موارد حتی منابع و زمان. اختصاص داده شده به آن در طول پروسه.تولید نرم‌افزار کمتر از50% می‌باشد.

از یک دیدگاه کلی، پروسه تولید نرم‌افزار را می‌توان به دو بخش کلی شامل:

   الف)تحلیل و طراحی ب)پیاده‌سازی تقسیم کرد. از دیدگاه دسته اول، برنامه‌سازان، تحلیل و طراحی صرفاً فهم ذهنی مساله می‌باشد که دقیقا پس از آن بایستی اقدام به پیاده‌سازی کرد. در حالیکه در نظر دسته دوم، فاز تحلیل و طراحی پر اهمیت‌تر از فاز دوم می‌باشد که بایستی برای انجام آن از متدولوژی‌ها و روش‌های استاندارد استفاده کرد. UML یک زبان مدلسازی می‌باشد که در فاز تحلیل و طراحی مورد استفاده قرار می‌گیرد.

مدل‌سازی (Modeling) چیست؟

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

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

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

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

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

پس می‌توان گفت که هدف از مدل‌سازی دو چیز می‌باشد:

الف)شناخت(exploration) ب)تبیین(specification)

که بر اساس تعریف مسئله، مدل‌سازی یکی یا هردو هدف را در نظر می‌گیرد.

مهندسی نرم افزار و معرفی UML

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

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

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

فعالیت تحلیل نیازمندی ها برای درک بهتر آنها .

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

فعالیت ساخت سیستم .

آزمایش سیستم برای تایید اینکه آیا سیستم نیازمندی ها را برآورده کرده است یانه ؟

و در نهایت فعالیت تحویل سیستم .

حال متدلوژی های مختلفی برای انجام این فعالیت ها وجود دارد و هر کدام به نحوی به انجام این کار ها می پردازند .

متدولوژی

در ابتدا باید به تعریف متدلوژی و اینکه یک متدلوژی چه کاری انجام می دهد پرداخت .

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

یک متدلوژی در حقیقت سه وظیفه دارد .

فرموله کردن مسئله .

بیان نحوه حل مسئله

پیاده سازی مسئله .

هدف من در اینجا بررسی متدلوژی های شی گرا می باشد . دیدگاه شی گرایی از اواسط دهه 70 میلادی در مباحث برنامه نویسی کامپیوتر متولد شد . پس از گذشت چند

مقاله درباره آشنایی با UML

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 26

آشنایی با UML

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

Uml مجموعه ای از بهترین تجربیات مهندسی که موفقیتشان در مدل سازی سیستمهای بزرگ و پیچیده به اثبات رسیده است را عرضه می دارد.

تعریف UML شامل اسناد زیر می گردد :

معنا شناسی UML : که مفاهیم غنی و دستور نگارش وعلا ئم زبان مدلسازی یکپارچه را تعریف می کند UMLبه وسیله بسته ها به صورت معماری گونه لا یه بندی و سازماندهی میشود . در هر بسته عناصر مدل بر حست دستور نگارش (با استفاده از متن و عبارت زبان محدودیت شیء معروف به OCL )و معانی (با استفاده از متن دقیق) تعریف می شوند .

راهنمای علائم UML : فکر و اندیشه را تعریف می کند و مثال های خوبی را ارائه می کند. علائم UML نحو گرافیکی را برای بیان معانی توصیف شده توسط فرا مدل های UML ارائه می کند.

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

2) فراهم آوردن مکانیزم های توسعه و تخصیص برای بسط مفاهیم اساسی : بدین معنا که در عین آنکه انتظار میرود UML براساس نیازهای جدید در حوزه های خاص جفت و جور شود نمی خواهد اجبار کند تا مفاهیم اساسی و مشترک برای هر حوزه جدیدی دوباره تعریف شود و پیاده سازی گردد. البته مفاهیم اساسی نباید بیش از حد تغییر یابند. بنابراین کاربران نیازمندند که قادر باشند : 1- مدل ها را با استفاده از مفاهیم اساسی بسازند بدون آنکه مکانیزم های توسعه را برای بسیاری از برنامه های کاربردی نرمال بکار گیرند .

2- مفاهیم و علائم جدید را اضافه کنند البته برای مواردی که توسط اصول پوشیده نشده باشند .

3- زمانی که هیچ اتفاق نظر روشنی وجود ندارد تفاسیر مختلف را از مفاهیم موجود انتخاب کنند .

4- مفاهیم، علائم و محدودیت ها را برای حوزه های کاربردی خاص مشخص سازند .

3) استقلال از زبان های برنامه نویسی خاص و فرایندها ی توسعه .

4) فراهم آوردن پایه و اصولی رسمی برای درک زبان مدل سازی که برای این منظور UML تعریف رسمی از قالب استاتیک مدل را با استفاده از نمودار کلاس ارائه می کند این نمودار ، نموداری مشهور و مورد قبول در سطح وسیع برای تعییین قالب یک مدل است UML همچنین محدودیت هایی را بیا ن میدارد که در قالب زبان دقیق طبیعی و عبارات زبان محدودیت شیء (OCL ) بیان می شود .

5) تشویق به رشد بازار ابزارهای OO .

6) حمایت و پشتیبانی از مفاهیم توسعه سطح بالاتر نظیر : همکاری ها ، چهارچوب ها ،الگوها و اجزاء .

7) مجتمع سازی بهترین تجربیات : UML بدنبال آن است که بهترین تجربیات درصنعت

حوزه های مسئله ، معماری ها و … را یکجا بیاورد .

محدوده UML

زبان مدل سازی یکپارچه UML زبانی است برای مشخص سازی ساخت ،مجسم سازی و مستند سازی دست آوردهای یک سیستم متمرکز نرم افزاری اول آنکه این زبان از مفاهیم OOSE,OMT,BOOCH که متدولوژیهای متداول OOمیباشند متنج شده است . دوم ، UMLبر آنچه که در حال حاضر توسط روش های موجور فابل انجام همتند ، بان شده است . سوم زبا ن مدل سازی یکپارچه بر یک زبان مدل سازی استانارد تمرکز می کند و نه یک فرآیند استاندادر اگر چه UMLبایستی در زمینه یک فرایند به کارگیری شود تجرته نشان میدهد که در سازمان های مختلف و با حوزه های مسئله متفاوت فرایندهای متفاوتی مورد نیاز است بنابراین تلاش بر این است که ابتدا بر یک فرامدل مشترک (که معانی را یکپارچه میکند )تمرکز شود و در درجه دوم بر یک علامت گذاری مشترک (که برای فرد استنباط این معانی را فراهم میکند )تمرکز گردد مبدعین UMLبر فرایند توسعای تاکید میکنند که مورد کاربرد گرا معماری گرال و تکراری و افزایشی است .

UML یک زبان مدلسازی را مشخص می کند که اتفاق نظر جماعت شیگرا بر مفاهیم اساس مدل سازی است .

UMLبرای ایجار مدلها و نمرارهای حوزه مسئله هیچ توصیه ای نمیشود و این تجربیات و یادگیری افراد است که تشخیص استفاده از کدام نمودارها و مدل ها را به ایشان می دهد دریک دیدگاه مدل سازی UML نمودارهای گرافیکی زیر را تعریف می کند مورد کاربرد

نمودار مورد کاربرد diagram ) (use ca

نمودار کلاس (ClassDiagram)

نمودارهای رفتار: (BehaviorDiagra

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

نمودار فعالیت : )Activity Diagram(

نمودارهای تعامل Interaction Diagrams ))

نمودار توالی ((Sequence Diagram

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

* نمودارهای پیاده سازی) (Implementation Diagram

نمودار اجزاء (Component Diagram )

نموداراستقرار (Deployment Diagram)

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

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

آموزی uml 47 ص

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 48

فصل اول

1- 1 مقدمهusecase ها

با توجه به مفاهیم کلاس‌ها مورد مهمی در uml را بررسی می‌کنیم که همان usecase ها هستند. دراین فصل موضوعات زیر مطرح می‌شوند :

usecase چیست

ساختن یک usecase

محتویات یک usecase

extend یک usecase‌

تحلیل یک usecase

در گذشته با دیاگرام‌هایی برخورد کردیم که دیدگاه ثابتی در مورد کلاس‌های سیستم ارائه می‌کرد. به سراغ دیاگرام‌هایی می‌رویم که دیدگاهی پویا ارائه می‌کند ونشان می‌دهد چگونه سیستم و کلاس‌هایش با گذشت زمان تغییر می‌کنند .دیدگاه ثابت به روابط بین تحلیلگر و طراحان سیستم کمک می‌کند و دیدگاه پویا به روابط بین تحلیلگر وگروه طراحان کمک می‌کند و به طراحان اجازه می‌دهد که برنامه بنویسند .

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

مدل کردن سیستم از دیدگاه کاربر آن، کار usecase است . در این فصل درباره اینکه usecase چیست و چه کاری انجام می‌دهد صحبت می‌کنیم و همچنین درباره چگونگی استفاده از دیاگرام usecase در تصویرسازی در UML بحث می‌کنیم .

2- 1 ‌usecase ها چه هستند ؟

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

از مراحل یک پردازش مانند مراحل بالا وقتی‌که یک خرید بدون انگیزه را ترتیب دادیم گذشتیم. در تحلیل یک فرم از usecase چه کاری انجام می‌دهیم ؟ از خود می‌پرسیم چگونه از یک محصول یا سیستم استفاده می‌کنیم، تا پول خود را به خوبی خرج کنیم. بنابراین مهم‌ترین چیز این است که نیازها را بشناسیم .

این نوع پردازش مخصوصاً برای بخش آنالیز سیستم طراحی شده است .چگونه کاربرها از درایور سیستم از همان راهی که شما طراحی کرده‌اید و سیستم را ساخته‌اید استفاده می کنند ؟

usecase یک ساختار است که به تحلیلگر سیستم که با کاربر کار می‌کند، کمک می‌کند تا سیستم کاربردیی را طراحی کند .

اصطلاح جدید : usecase مجموعه‌ای از سناریوها است که سیستم از آنها استفاده می‌کند. هر سناریو یک ترتیب زمانی از وقایع را شرح می‌دهد. هر ترتیب زمانی به وسیله شخصی یا سیستمی دیگر یا یک قطعه‌ای از سخت‌افزار و یا به‌وسیله گذر زمان بنا نهاده می‌شود. موجودیت‌های که ترتیب زمانی را شروع میکنند actor نامیده می‌شوند. ترتیب زمانی باعث می‌شود که استفاده‌های دیگری از actor‌ توسط کسانی که actor‌ را بنا گذاشته‌اند و یا توسط دیگر actor ها بشود .

3- 1 چراusecase ها مهم هستند ؟

تنها یک راه با ارزش برای تحریک مشتری به صحبت در مورد دیدگاهش درباره سیستم وجود دارد. usecase یک ابزار عالی برای تحریک مشتری است. معمولا‏ً تحریک مشتری برای صحبت مفصل در مورد چگونگی استفاده‌ا‌ش از سیستم کار آسانی نیست. چراکه توسعه سیستم‌های قدیمی اغلب یک پردازش اتفاقی است، که در تحلیل بسیار کوتاه است. کاربرها برخی مواقع وقتی در مورد ورودی‌هایشان از آنها سوال می‌شود، گیج می‌شوند . ایده‌ای موجود این است که سیستمی که کاربرها با آن کار می‌کنند را در مراحل اولیه آنالیز و تحلیل سیستم در نظر بگیریم. این کار احتمال اینکه سیستم در نهایت برای کاربر بهتر شود را بالا می‌برد ، مثل تعویض مفاهیم محاسباتی یک سیستم قدیمی که باعث گیج شدن کاربران برای کار با آن می‌شود.

4- 1 یک مثال : ماشین نوشابه

فرض کنید که می‌خواهیم یک ماشین نوشابه طراحی کنیم. برای بدست‌ آوردن دیدگاه کاربران باید با چند نفر از کاربران برای دانستن نحوه برخوردشان باسیستم مصاحبه کنیم. زیرا عمل اصلی ماشین این است که به مشتری اجازه می‌دهد یک قوطی نوشابه بخرد ، بنابراین کاربران سریعاً به ما می‌گویند که مجموعه‌ای از سناریوها(به عبارتیusecase ها)را داریم که احتمالاً عنوان ”خرید نوشابه“ را دارند. بنابراین هر سناریو ممکن را بررسی می‌کنیم. توجه داریم که در طراحی سیستم معمولی سناریوها در اثر صحبت با کاربر به وجود می‌آیند.

1-4- 1 usecase خرید نوشابه

actor این usecase‌مشتری است، که می‌خواهد یک قوطی نوشابه بخرد. مشتری سناریو را با انداختن پول آغاز می‌کند. سپس او امکان انتخاب دارد. اگر همه چیز به خوبی پیش برود دست کم یک قوطی نوشابه به مشتری تحویل داده می‌شود.

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

به مرحله دیگر از usecase خرید نوشابه می‌رویم. به سراغ سناریو alternative می‌رویم. مشتری usecase را با انداختن پول به داخل ماشین آغاز می‌کند. سپس امکان انتخاب دارد، اما ماشین در انتها قوطی نوشابه‌ای که انتخاب شده را تحویل نمی‌دهد و به مشتری پیام می‌دهد که پول خارج از محدوده ماشین است. پیام باید به گونه‌ای باشد که مشتری را برای انتخاب دیگر تحریک کند. همچنین ماشین باید پیشنهادی برای پس دادن پول به مشتری بدهد. در این‌ جا، مشتری نوشابه دیگری را انتخاب می‌کند و ماشین آن را تحویل می‌دهد (اگر انتخاب جدیدی صورت نگیرد نوشابه نیز فروخته نمی‌شود) و یا عمل تحویل پول اتفاق می‌افت . شرایط بعدی، تحویل یک قوطی نوشابه یا تحویل پول است.

سناریو دیگری نیز ممکن است اتفاق بیفتد. ”خارج از محدوده“ پیامی است که زمانی‌که ماشین موجودی نداشته باشد نمایان می‌شود و در این مرحله باقی می‌ماند تا زمانی که دوباره پر شود و بتواند نوشابه را تحویل دهد. در این مرحله ممکن است که مشتری پول را نیانداخته باشد. مشتری‌ که ما ماشین را برایش طراحی کرده‌ایم ممکن است سناریو اول را ترجیح بدهد. اگر مشتری پول را وارد ماشین کرده ممکن است مایل باشد انتخاب دیگری انجام بدهد، تا اینکه در مورد پس دادن پول از او سوال شود.

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

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

2-4- 1 Usecaseهای اضافی

ماشین خرید نوشابه را از دیدگاه مشتری بررسی کردیم. علاوه بر مشتری کاربران دیگری هم وجود دارند . یکی از آنها تهیه‌کننده است که در ماشین نوشابه می‌گذارد و دیگری تحصیلدار است، (ممکن است همان تهیه‌کننده باشد) که پول‌های جمع شده در ماشین را جمع آوری می‌کن .

این مورد روشن می‌کند که حداقل دو usecase‌ ،اضافه‌تر باید ساخته شود. موجودی داخل ماشین گذاشتن وجمع‌آوری پول ماشین که جزئیات آنها در اثر صحبت با تهیه‌کننده و تحصیلدار روشن می‌شود.

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

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

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

5- 1 Include ‌یک usecase

در usecase‌ قرار دادن نوشابه در ماشین وusecase جمع‌آوری پول باید به یک سری مراحل عمومی توجه شود.

هر دو با باز کردن قفل و در ماشین آغاز می‌شوند و با بستن قفل و در ماشین پایان می‌یابند. آیا می‌شود یکی از دو نسخه مراحل را از یکی از دو usecase‌ حذف کرد؟ راه ممکن برای انجام این کار این است که هر کدام از مراحل زمانی عمومی را گرفته و یک usecase‌ اضافی برای هر کدام بگیریم. سپس مراحل باز کردن قفل و در ماشین را در یک usecase‌ با نام نمایش داخل ماشین ترکیب کرده و مراحل بستن در و قفل ماشین را در یک usecase با نام پنهان کردن داخل ماشین ترکیب می‌کنی .

با این usecaseهای جدید گذاشتن نوشابه داخل ماشین با usecase نمایش داخل ماشین آغاز می‌شود. تهیه‌کننده مراحل قبل را طی کرده و با usecase‌ پنهان کردن داخل ماشین به انتها می‌رسد. همچنین usecase جمع‌آوری پول با usecase‌ نمایش داخل ماشین آغاز شده و مراحل قبلی را طی می‌کند و با usecase پنهان کردن داخل ماشین تمام می‌شود. همانطور که دیدیم قرار دادن نوشابه و جمع‌آوری پول در یک usecase‌ جمع شده‌اند، بنابراین با این روش استفاده دوباره از usecase‌ به محتویات آن برمی‌گردد.

نسخه جدید uml‌ به include،usecase ‌ به عنوان usecase‌ استفاده شده تعبیر می‌کند. ممکن است هنوز روش قدیمی موجود باشد. including دو مزیت دارد . اول‌ : واضح‌تر است. مراحل usecase اول شامل مراحل دیگری هم هست. دوم :‌ از آشفتگی و شلوغی جلوگیری می‌کند. این راه را نباید به عنوان استفاده دوباره از usecase به وسیله خودش تلقی کرد.

6- 1 توسعه دادن usecase‌

می‌توان از usecase در روش دیگری غیر از include استفاده کرد. بعضی اوقات می‌توان یک usecase‌ جدید را با اضافه کردن بعضی مراحل به usecase موجود ساخت. به usecase قرار دادن نوشابه برمی‌‌گردیم. قبل از قرار دادن قوطی‌ها در ماشین، فرض می‌کنیم تهیه‌کننده به نوشابه‌ای که خوب فروش می‌رود و نوشابه‌ای که خوب

آموزش توسعه نرم افزار های شیء گرا توسط UML 53 ص

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 53

آموزش توسعه نرم افزار های شیء گرا توسط UML

فصل اول: مفاهیم شیء گرایی

مقدمه

شئ گرایی برای توسعه نرم افزار اولین بار در سال 1960 پیشنهاد شد، این روش پس از 20 سال به طور گسترده مورد استفادة جامعه نرم افزاری قرار گرفت. توسعه دهندگان نرم افزار در دهه 1980 توجه جدی خو د را روی شئ گرایی معطوف کردند. تکنولوژی شئ، قابلیت استفاده مجدد را برای مؤلفه های نرم افزاری به ارمغان آورد و این نیز به نوبه خود در تسریع توسعه نرم افزار و تولید محصول با کارایی بالا تاثیر بسزایی دارد؛ بعلاوه سیستمهای شئ گرا، براحتی قابل توسعه و به سهولت با محیط سازگار- از نظر تعامل با سیستمهای موجود در محیط استفاده از نرم افزار- می شوند . دیدگاه شئ گرایی یک سیر تکاملی دارد؛ همچنانکه در بخشهای بعدی خواهیم دید، تعیین همه کلاسهای لازم برای یک سیستم دریک تکرار تا اندازه ای غیرممکن است و به محض تکمیل مدلهای تحلیل و طراحی نیاز به کلاسهای جدید در سیستم نمایان می شود.

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

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

در متد شئ گرا از زبان مدلسازی استانداردUML که در فصل چهارم به تفصیل خواهدآمد، استفاده می شود. این زبان به وسیله ابزارهای مختلفی نظیر Rational Rose ، visio و … پشتیبانی می شود، میتوان ازUML در فرآیندهای مختلف استفاده کرد.

مفاهیم اساسی

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

متد، متدلوژی و اشیاء

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

متد شئ گرا برپایه شئ استوار است، دیدگاه شئ گرا دنیای واقعی مسئله را بصورت مجموعه ای از اشیاء مرتبط به هم می بیند. شئ یک موجودیت است که در دامنة مسئله نقش تعریف شده ای دارد و دارای حالت، رفتار و شناسة خاص خودش است. شئ می تواند یک ساختار ، نقش ، مکان و ... باشد؛ شئ داده و رفتار را در خود کپسوله میکند و از دسترسی اشیاء دیگر به داده های خود جلوگیری و همچنین تا ثیر تغییرات محیطی بر این داده ها را کاهش می دهد و تنها راه دسترسی به این داده ها استفاده از اعمال یا سرویس های خود شئ می باشد. کلاس نوع اشیاء را نشان می دهد و شامل ویژگی های مشترک مجموعه ای از اشیاء می باشد، شئ نمونه ای از کلاس است . داده های شئ تحت عنوان صفات در کلاس شناخته می شوند و مقادیر این صفات است که شئ را از دیگر اشیای همنوع متمایز می نمایند. اعمال به دستکاری تعداد محدودی از صفات می پردازند و ارتباط بین کلاس ها و دیگر عناصرسیستم نیز از طریق همین سرویسها- اعمال – صورت می گیرد. به عبارت دیگر کلاس یک مشخصه کلی (قالب ، الگو یا طرح اولیه )است که مجموعه ای ازاشیاء مشابه را نشان می- دهد.نماد گرافیکی کلاس در شکل زیر نشان داده شده است، این نماد شامل سه قسمت است که بترتیب نام کلاس ، لیست صفات و لیست اعمال را نشان می دهند.

------------------------ نام کلاس

------------------------ لیست صفات

------------------------ لیست اعمال

------------------------

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

پیامها وسیله برقراری ارتباط و تعامل بین اشیاء می باشند ، این پیامها شئ مقصد را تحریک می کنند تا یک کار خاص را انجام دهد. سرویسی که در شیء فرستنده پیام تولید می کند، یک پیام با قالب message:[destination, operation, parameters] ارسال میکند که در آن destination شیء گیرنده و operation سرویسی از شیء گیرنده است که پیام را دریافت می کند و parameters شامل اطلاعات لازم جهت انجام موفق سرویس خواسته شده است. شکل 1-2 مثالی از کلاسهای تعمیم و تخصیص را نشان می دهد که در آن برای دانشجو یک فوق کلاس دانشجو داریم که شامل داده ها و اعمال مشترک بین دانشجویان دورة لیسانس و فوق لیسانس است، همچنین دو زیر کلاس تخصیص جداگانه برای دانشجویان لیسانس و فوق لیسانس نشان داده شده است که حالات خاصی از کلاس دانشجو هستند. در عمل ما شیئی از نوع فوق کلاس دانشجو نخواهیم داشت، در این حالت به کلاسstudent یک کلاس مجرد گفته می- شود . کلاس مجرد کلاسی است که هیچ شیئی از آن نوع نداشته باشیم.

کپسوله سازی، ارث بری و چند ریختی

با توجه به مطالب ذکر شده در بالا، شیء گرایی به واسطه سه خاصیت مهم کپسوله سازی، ارث بری و چند ریختی یک روش منحصر بفرد است . بطور کلی کپسوله سازی تکنیکی است که