مجموعه طلایی آموزش UML مهندسی نرم افزار شامل اسلاید و درس همراه با مثالهای کاربردی و قابل فهم
مجموعه طلایی آموزش uml
مجموعه طلایی آموزش UML مهندسی نرم افزار شامل اسلاید و درس همراه با مثالهای کاربردی و قابل فهم
فرمت فایل: word(قابل ویرایش)تعداد صفحات71
مقدمه:
با کمی اغماض میتوان ادعا کرد که در میان شاخههای مختلف مهندسی در هرکدام که دارای قدمت بیشتری است، همگرایی بیشتری در اتخاذ روش و ابزار برای انجام اعمال نسبتاً مشابه از میان متخصصان و متولیان آن رشته وجود دارد. به طور مثال در حال حاضر برای اجرای یک سازه در هر نقطه از دنیا، مهندسین عمران از یک روند همسان با توالی مشابه شامل: الف)تولید طرح عمرانی ب)پیادهسازی نقشه ج)محاسبات سازهای د)اجرا استفاده میکنند. ولی در رشته نوپایی چون مهندسی نرمافزار، گاه چنان روشها متفاوت است که از دید یک ناظر خارجی، دو تیم نرمافزاری مختلف که هر دو قصد تولید محصولی مشابه را دارند، دو تیم در رشتههای متفاوت به نظر بیایند. یکی از علل وجود تمایز در تولید نرمافزار میزان تخصص نیرو و زمان به پیادهسازی میباشد.بدین معنا که در نزد بسیاری از برنامهنویسان تولید نرمافزار معادل است با تولید کد. ولی از نظر بعضی دیگر تولید کد تنها بخشی از تولید نرمافزار است که در بسیاری از موارد حتی منابع و زمان. اختصاص داده شده به آن در طول پروسه.تولید نرمافزار کمتر از50% میباشد.
از یک دیدگاه کلی، پروسه تولید نرمافزار را میتوان به دو بخش کلی شامل:
الف)تحلیل و طراحی ب)پیادهسازی تقسیم کرد. از دیدگاه دسته اول، برنامهسازان، تحلیل و طراحی صرفاً فهم ذهنی مساله میباشد که دقیقا پس از آن بایستی اقدام به پیادهسازی کرد. در حالیکه در نظر دسته دوم، فاز تحلیل و طراحی پر اهمیتتر از فاز دوم میباشد که بایستی برای انجام آن از متدولوژیها و روشهای استاندارد استفاده کرد. UML یک زبان مدلسازی میباشد که در فاز تحلیل و طراحی مورد استفاده قرار میگیرد.
مدلسازی (Modeling) چیست؟
مدلسازی یکی از تکنیکهای ذهنی بشر میباشد که نه تنها برای اهداف علمی، بلکه برای انجام امور روزمره بشر به دفعات مورد استفاده قرار میگیرد. مدلسازی به طور کلی یعنی شبیهسازی یک محیط با اندازههای متفاوت و از محیط واقعی و احتمالا مواد و مصالحی متمایز از جنس مواد و مصالح محیط مدل شده. در مدلسازی ابتدا اجزای محیط واقعی انتخاب شده و متناسب با هدف مورد نظر از مدلسازی خصوصیاتی از هریک از اجزای واقعی انتزاع میشود، یعنی به ازای هزیک از اجزای محیط واقعی یک موجودیت تجریدی ساخته میشود و با برقراری ارتباطی مشابه با ارتباط اجزای واقعی، در میان موجودیتهای تجریدی، محیط واقعی مدل میشود. برای روشن شدن مثالی میزنیم:
فرض کنیم قصد داشته باشیم در فاز طراحی یک اتومبیل میزان موفقیت هوا در مقابل اتومبیل در حال حرکت را بسنجیم یکی از راهها برای انجام این آزمایش، ساخت یک اتومبیل واقعی، راندن و سپس اندازهگیری مقاومت هوا میباشد که انجام اینکار اگرچه ما را به هدف میرساند، ولی دارای هزینه بالاییست چرا که بایستی ابتدا ماشین ساخته شود، سپس مورد آزمایش قرار گیرد.در این صورت اگر در آزمایش به نتیجه مورد نظر نرسیم، بایستی دوباره طراحی را تغییر داد، و پس از ساخت یک نمونه واقعی دیگر آزمایش را تکرار کنیم و این روند آنقدر ادامه پیدا کند تا طراحی مناسب برای اتومبیلی با خصوصیات مورد نظر شکل گیرد. میبینیم که چنین روشی بسیار پرهزینه است و این هزینه هم شامل هزینههای اقتصادی است و هم هزینههای زمانی، چون علاوه بر این که در هر مرحله آزمایش بایستی اتومبیل با صرف هزینه بالا ساخته شود، زمان ساخت آن نیز طول خواهد کشید.
ولی متخصصان برای انجام چنین آزمایشی به مدل روی میآورند. یعنی یک جسم فیزیکی کوچک با خصوصیات آئرودینامیکی لحاظ شده در طراحی اتومبیل، ساخته میشود و با قرار دادن آن در یک تونل باد، حرکت اتومبیل در فضای واقعی را شبیه سازی میکنند و بدین طریق میزان مقاومت هوا را میسنجند.
نکات مورد توجه در این مدلسازی، یکی اندازه مدل و دیگری خصوصیات آن میباشد. مدل بسیار ساده و کوچک میباشد و از طرفی تنها خصوصیت آئرودینامیکی اتومبیل در مدل لحاظ میشود. چرا که هدف ما از مدلسازی تنها بررسی خصوصیات آئرودینامیکی اتومبیل است و مدل الزاماً نبایستی از جنبههای دیگر، شباهتی به اتومبیل واقعی داشته باشد. مثلا در ساخت چنین مدلی به هیچوجه به استحکام اجزا و یا زیبایی مدل توجه نمیشود چون بررسی چنین خصوصیاتی خارج از هدف این مدلسازی خاص است.
مثال بالاتنها یک جنبه از مدلسازی را بیان میکند و آن جنبه شناختExploration میباشد. یعنی در مدلسازیهای مشابه مدلسازی فوقالذکر، هدف از مدلسازی تنها شناخت محیط مورد مدل میباشد. یک جنبه دیگر از مدلسازی تبیین (specification) میباشد. یعنی گاه برای معرفی و ارائه خصوصیات یک موجودیت واقعی یک مدل از آن ارائه میشود. نقشه جغرافیایی مثال خوبی است که این جنبه از مدلسازی را مورد نظر دارد.
زبان مدل دهی شده متحد یا یکنواخت (UML) بطور گسترده توسط توسعه دهندگان کاربرد پذیرفته شده است ، اما توسط طراحان رابط استفاده کننده چندان پذیرفته نشده است (UI) به این دلیل ، زبان ساخته شده ترکیبی (متمایز) برای سیستم های محاوره ای (فعل و انفعالی) (UMLI) برای تقویت پایه UML در طرح UI پیشنهاد شده است . UMLI یک نمودار دستگاه علائم را برای مدل دهی نمایش UI معرفی کرده و فعالیت نمودار یا دستگاه علائم را برای همکاری بین اهداف یا موضوعات متقابل و اهداف محدود گسترش می دهد .
این مقاله تحقیقاتی با استفاده از طرح متریک یا متریکهای طرح به روشی کمی (کمیتی) نمایش داده می شود که مدلهای UMLI به طور عمده از لحاظ ساختاری ، عملکردی و عینی به نسبت مدلهای UML در موقع تعریف همان مجموعه از خواص یک سیستم محاوره ای یا فعل و انفعالی ، پیچیدگی کمتری دارند .
UMI ، با این وجود ، از کمبود حمایت در مدل دهی UIS رنج می برد . برای مثال ، طبقه یا طبقه بندی نمودارها به طور کلی برای مدل دهی نمایش UI مناسب نیستند . در نتیجه این مشکلات تحقیق مربوط با یک بررسی در مورد تقویت اثر گذاری UML برای UIS هدایت و راه اندازی می شود .
برای مثال ، رویکرد مارکوپولوس ، دانش و و UMLI ضمینه ها یا گسترده های قدیمی UML هستند ، در حالیکه نمودار درختی CONCURTASK معرفی یک دستگاه علائم جدید را برای وظیفه مدل دهی ساختارها به صورت استاندارد UML پیشنهاد می کند . با مقایسه ، تصور وظیفه یا کار مربوطه با طبقاتی در بخش دانش ( Wisdom ) و با فعالیت هایی در روکرد UMLI و مارکوپلو نشان داده می شود . وجود بیش از یک روش برای تقویت پایه UI در UMI ضرورت ارزیابی امتیازات چنین رویکردهایی را در مقایسه با استاندارد UML نشان می دهد . در واقع هنوز نامعلوم است که چگونه بهترین مورد برای تقویت پایه UI در بافت یا ساختار UML طراحی شده است .
بررسی های کیفی مبتنی بر تایید مطابقت سازگاری اصلاحات پیشنهاد شده با عملیات و دستورالعمل های طرح بوسیله اکثر این روش ها حمایت می شود . برای مثال ، 9 ، 14 ، 16 روش هایی هستند که از MB – VIDES به دست آمده اند . با این وجود ، چنین ارزیابی های کیفی یا کیفیتی گستره ( دامنه ) مزایای بدست آمده را مشخص نمی کند . بنابراین ، مقاله مربوطه برای اولین بار یک سنجش کمی از امتیازات یا فوائد پیشرفت های UML برای مدل دهی سیستم های محاوره ای ، ارائه می دهد . این ارزیابی در عبارات پیچیده ساختاری و عملی مدل های UMLI و UML برای سیستم های فعل و انفعالی یا محاوره ای تعریف می شود .
2- کار مربوطه (نسبی) :
چندین استراتژی سنجش برای طرحهای UI به بررسی کیفیت مدلهای ادراکی UI می پردازند . بررسی و تصور افراز و لوازم و سازندگان UI هیچ مشخصه ادراکی یا تصویری UIS را معمولاً اصلاً ایجاد نمی کند . در واقع ، کدهای ایجاد شده UI در حال حاضر نمایشات عینی (غیر خیالی) Ui هستند ، که عموماً مقید به طرح ریزی مرتب و خاص و مجموعه ای انتخاب شده از ویژگی ها هستند . تصور و بررسی UIMSs و MB – VIDES واکنشی متقابل با پیش نمونه های ایجاد شده UI و کدهای UI را نشان می دهد که به طراحان و کاربران اجازه بررسی کیفیت ترکیبی مدل های UI تکنیک هایی که برای ایجاد راه اندازی USI به کار رفته اند و ابزار آلاتی که ممکن است برای تکمیل هدایت USI به کار برده شوند را می دهد به نسبت کیفیت مدل های UI در جداسازی . مقداری از سنجش یا ارزیابی کیفیتی می تواند با شبیه سازی این مدل های تصویری و ادراکی به دست آید مثل نمودار درختی وظیفه یا کار ساختار ( 3 ) . شبیه سازی ها با این وجود ، بررسی بخش عملی ( رفتاری ) مدل ها را محدود می کنند .
شامل 23 صفحه فایل word قابل ویرایش
لینک پرداخت و دانلود *پایین مطلب*
فرمت فایل:Word (قابل ویرایش و آماده پرینت)
تعداد صفحات: 48
فهرست مطالب :
2- 1 usecase ها چه هستند ؟
1- 1 مقدمهusecase ها
3- 1 چراusecase ها مهم هستند ؟
1-4- 1 usecase خرید نوشابه
5- 1 Include یک usecase
6- 1 توسعه دادن usecase
2-2 نمایش مدل usecase
7- 1 شروع تحلیل usecase
1- 2 دیاگرامusecase
4-2 دیاگرام usecase در پردازش تحلیلی
5-2 کاربرد دیاگرام usecase : یک مثال
3-5-2 مفهوم usecaseها
2-5-2 مفهوم کاربران
1-5-2 مفهوم قلمرو (domain)
4-5-2 dirilling down
با توجه به مفاهیم کلاسها مورد مهمی در uml را بررسی میکنیم که همان usecase ها هستند. دراین فصل موضوعات زیر مطرح میشوند :
• usecase چیست
• ساختن یک usecase
• محتویات یک usecase
• extend یک usecase
• تحلیل یک usecase
در گذشته با دیاگرامهایی برخورد کردیم که دیدگاه ثابتی در مورد کلاسهای سیستم ارائه میکرد. به سراغ دیاگرامهایی میرویم که دیدگاهی پویا ارائه میکند ونشان میدهد چگونه سیستم و کلاسهایش با گذشت زمان تغییر میکنند .دیدگاه ثابت به روابط بین تحلیلگر و طراحان سیستم کمک میکند و دیدگاه پویا به روابط بین تحلیلگر وگروه طراحان کمک میکند و به طراحان اجازه میدهد که برنامه بنویسند .
مشتری و تیم طراحان یک مجموعه مهم از امینان سیستم را تشکیل می دهند. نه دیدگاه ثابت و نه دیدگاه پویا، کارکرد سیستم را از نقطه نظر کاربر نشان نمیدهند. فهمیدن این دیدگاه کلیدی است برای ساختن سیستمی که مفید وقابل استفاده باشد. این دیدگاه تقاضاها را بررسی میکند وکار کردن با آن آسان (و حتی جالب است) است.
مدل کردن سیستم از دیدگاه کاربر آن، کار usecase است . در این فصل درباره اینکه usecase چیست و چه کاری انجام میدهد صحبت میکنیم و همچنین درباره چگونگی استفاده از دیاگرام usecase در تصویرسازی در UML بحث میکنیم .
2- 1 usecase ها چه هستند ؟
چندین سال قبل من یک فاکس خریدم. وقتی که برای خرید به دفتر تهیهکننده رفته بودم با سطح وسیعی از انتخاب ها برخورد کردم. چگونه باید تصمیم خوبی میگرفتم؟ از خودم پرسیدم میخواهم با فاکس چه کاری انجام بدهم؟ چه مواردی را نیاز دارم، چه اعمالی را میخواهم با فاکس انجام بدهم؟ آیا میخواهم کپی بگیرم؟ به کامپیوتر متصلش کنم؟ به عنوان scanner از آن استفاده کنم؟ میخواهم فاکسها را به سرعت بفرستم، که به سرعت شمارهگیر احتیاج داشته باشم؟میخواهم تشخیص بدهم که fax آمده یا کسی تلفن کرده است ؟
از مراحل یک پردازش مانند مراحل بالا وقتیکه یک خرید بدون انگیزه را ترتیب دادیم گذشتیم. در تحلیل یک فرم از usecase چه کاری انجام میدهیم ؟ از خود میپرسیم چگونه از یک محصول یا سیستم استفاده میکنیم، تا پول خود را به خوبی خرج کنیم. بنابراین مهمترین چیز این است که نیازها را بشناسیم .
این نوع پردازش مخصوصاً برای بخش آنالیز سیستم طراحی شده است .چگونه کاربرها از درایور سیستم از همان راهی که شما طراحی کردهاید و سیستم را ساختهاید استفاده می کنند ؟
لینک و پرداخت دانلود * پایین مطلب *
فرمت فایل : word ( قابل ویرایش )
تعداد صفحه : 6
فهرست
قوانین فعال و انفعال UML
عناصر
قوانین عامل
چرخه
و ...
مقدمه
به طور معمول به اندازه کافی ساخت زیر مجموعه از عامل uml برای محققان دیگر مفید است . API ها کلاسی خاص از الگوی طراحی نرم افزار است به این ترتیب آنها مشکلاتی را که در سیستم های چند عاملی رخ می دهند را شرح می دهد و سپس هسته استفاده مجدد راه حل برای مشکلات را شرح می دهد .
توضیحات راجع به قوانین فعل و انفعالات قسمتی از خصوصیات مدل پویای یک سیستم عاملی می باشد . در uml ، این مدل از نمودارهای فعل و انفعالات گرفته شده است ، نمودارهای حالت در نمودارهای فعالیت.
نمودارهای فعل و انفعالات و نمودارهای توالی و نمودارهای تعامل برای شرح رفتار گروهی از اشیاء استفاده می شود .
معمولاً یک نمودار فعل و انفعال از رفتار یک مورد کاربری گرفته شده است این نمودارها به اصلی برای شرح فعل و انفعال پایه بین اشیاء در مرحله دستیابی به مدل استفاده می شوند .