آشنایی با UML زبان مدل سازی یکپارچه در پروژه های مهندسی نرم افزار بخش سوم
فرآیند توسعه
مقدمه
UML یک زبان مدل سازی است و نه یک فرآیند و بر این اساس هیچ گونه علامت گذاری نیز برای فرآیند توسعه و ایجاد سیستم ارائه نمی دهد. سه مبدع UML ، فرآیندی را که در ابتدا به Objectory و هم اکنون به Unified Process معروف است را ارائه کرده اند. این فرآیند در شرکت Rational از سال ها قبل در حال اجرا است . البته در ایجاد یک سیستم نرم افزاری نمی توان فقط یک فرآیند را مطرح کرد. عوامل مختلفی که می توانند در فرآیند توسعه نرم افزار اثر گذار باشند ، موارد متعددی هستند ، مواردی نظیر : نوع نرم افزار (بیلادرنگ ، سیستم اطلاعاتی ، محصول رومیزی ، بازی کامپیوتری ) ، اندازیه (یک نفر توسعه دهنده ، گروه کوچک ، گروه بیش از 100 نفر ) و غیره .
بنابراین برای درک بهتر خواننده کمی هم از Unified Pricess می گوییم. فرآیند توسعه ، فرآیندی تکراری و افزایشی است و در چهار مرحله به انجام می رسد (شکل 1-7 ) . هر مرحله می تواند از چند تکرار تشکیل شود. در هر تکرار ، قدم های چرخه عمر وجود دارد. یعنی قدم های تعیین نیازمندی ها ، تحلیل ، طراحی ، پیاده سازی و تست در هر تکرار انجام می شود.
تعیین اساس کار و محدوده پروژه و اخذ تعهد از کاربر برای ادامه کار در اولین مرحله یعنی مرحله شروع انجام میشود.
جمع آوری مفصل نیازمندی ها و تحلیل و طراحی سطح بالا برای ایجاد خطوط پایه معماری در مرحله دوم یعنی مراحل تفضیل انجام می گردد.
در عین حال کارهایی را مجبورید به آخرین مرحله بیاندازید، به عنوان مثال بتاتست ، آموزش کاربر ، و … به آخرین مرحله یعنی مرحله انتقال سپرده می شود.
ساخت نرم افزار که عمده وقت پروژه را به خود اختصاص می دهد سومین مرحله فرآیند توسعه است. کلیه مدل هایاساس و ریز تا حد پیاده سازی در این مرحله ساخته می شود.
هر یک از مراحل می تواند دارای چندین تکرار باشد. اما در شکل 1-7 این تکرار را فقط برا ی مرحله سوم یعنی مرحله ساخت نشان دادم. فرض بر این است که در هر تکرار ، حداقل چهار قدم چرخه عمر وجود دارد. یعنی قدم های تحلیل ، طراحی ، پیاده سازی و تست در هر تکرار انجام می شود . این تکرارها به وسیله شکل های7-2 و 7-3 نیز قابل مشاهده است . در شکل 7-3 قدم های بیشتری برای چرخه عمر ذکر شده است که در صورتع علاقه مندی خواننده می تواند به سایت شرکت Rational مراجعه کند و توضیحات بیشتری را ببیند.
مرحله شروع
در این مرحله ممکن است به امکاان سنجی ، تحلیل مقدماتی برای به دست آوردن اندام پروژه و … نیاز شود. این مرحله با توجه به پروژ ه می تواند خیلی کوتاه و یا طولانی باشد. اساس کار و تعیین نیازمندی های کلی کاربر و نیز محدوده و مرز سیستم پروژه در این مرحله انجام می شود. وقتی که از نقطه نظرات جدی کاربر آگاه شدیم، مجوز ادامه کار را از او می گیریم. این مرحله از دید کاربر نباید چندان طولانی شود.
مرحله تفصیل
درک بهتر پروژه در این مرحله انجام می شود. در این مرحله کلیه نیازمندی های کاربر به صورت دقیق در قالب موارد کاربرد شناسایی می گردد. در تصمیم های این مرحله نیاز به ریسک و مخاطره دارید.
انواع ریسک های ممکن می تواند به صورت زیر دسته بندی شود.:
1 – ریسک نیازمندی ها : احتمال آنکه نیازمندی را خوب تشخیص ندهیم. کاربر چیزی بگوید و چیز دیگری فکر کنیم. نقطه شروع تعیین نیازمندی ها ، تعیین موارد کاربرد هستند.
2 – ریسک فنی : آیا می توانیم طراحی OO کنیم ؟ آیا با Web,java و بانک اطلاعاتی می توانیم خوب کار کنیم ؟ به عبارتی احتمال انتخاب معماری فنی مناسب چقدر است ؟
3 – ریسک مهارت ها : آیا نیروی متخصص داریم ؟ احتمال آنکه تخصص های لازم در پروژه را در دسترس داریم یا نه ، تحت عنوان ریسک مهارت ها مطرح می شود.
4 – ریسک شناسی : آیا نیروهای اثر گذار بیرونی وجود دارند ؟ یعنی چقدر احتمال دارد که از نظر ی ، پروژه تحت تاثیر نیروهای بیرونی قرار گیرد؟
ریسک نیازمندی ها
نقطه شروع تعیین نیازمندی ها ، تعیین موارد کاربرد است . مورد کاربرد تعاملی نوعی اس که کاربر با سیستم دارد برای آنکه به هدفی دست یابد. نقطه اساسی در هر مورد کاربرد اینست که هر مورد کاربرد ، یک وظیفه با اهمیت برای کاربر است . مهم ، کشف و شناسایی هر چه بیشتر موارد کاربرد بالقوه و مهم در سیستم است. موارد کاربرد خیلی ریز نمی شوند . ما بهتر است قبل از ترسیم نمودار مورد کاربرد ، نمودارهایی را که مدل حوزه مسئله را نشان می دهد ترسیم کنیم. مدل حوزه مسئله به مدل هایی اطلاق می شود که به حوزه مسئله و جهان واقعی بر می گردد و به نوعی حوزه مسئله مورد مطالعه ما را توصیف می کند.
این مدل می تواند هر نوع شکل ، نمودار ، تصویر ، جمله ، متن ، جدول ، ماکت و …. باشد تنها چیزی که از آن انتظار داریم آن است که بتواند تصوری کلی از ماهیت سیستم تحت مطالعه و عناصر آ را در اختیار ما قرار دهد.
==============
سلام
==============
جمعه 6 فروردین 1395 1:19 PM
a00bcom
a00bcom
کاربر تازه وارد
تاریخ عضویت : فروردین 1395
تعداد پست ها : 31
محل ست : اصفهان
آشنایی با UML زبان مدل سازی یکپارچه در پروژه های مهندسی نرم افزار بخش چهارم
انواع مدل ها
مدل های مختلفی را می توان ترسیم نمود :
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
1) مدل های حوزه مسئله و موارد کاربرد : این مدل ها ، نیازمندی های وظیفه های سیستم را نشان می دهند. با ترسیم این مدل ها نیازمندی های کاربر شناسایی می گردد.
2) مدل های تحلیلی : کاربرد خاص و تفصیل هر یک از نیازمندی های کاربر توسط مدل های تحلیلی نشان داده می شود. این مدل ها هر مورد کاربرد را به صورت مفصل تر نشان می دهند.
3) مدل های طراحی : که ساختار ایستای سیستم را به صورت زیر سیستم ، کلاس ها و واسط ها برای پیاده شدن بر اساس زیر ساخت های کاری نشان می دهند.
مدل های حوزه مسئله حتما قبل از مورد کاربرد ساخته می شود تا با فرهنگ حوزه مسئله آشنا شویم.
دو روش بر اساس UML می تواند برای ایجاد مدل های حوزه مسئله پیشنهاد شود:
1) نمودارهای کلاسی که از چشم انداز مفهومی ترسیم شده اند و بیشتر واژه ها و مفاهیم خبره های حوزه مسئله و نحوه ارتباط مفاهیم با یکدیگر را نشان می دهند. توجه شود که در الگوی حوزه مسئله بیشتر ، ساختا ر و فرهنگ لغات مسئله مورد توجه است در حالی که در مورد کاربرد ، بیشتر رفتار و فعالیت های حوزه مسئله مورد توجه قرار می گیرد.
2) نمودارهای فعالیت که به عنوان تکمیل کننده نمودارهای کلاس ، توصیف کننده جریان کار سیستم هستند.
3) نکته مهم نمودارهای فعالیت اینست که فرآیندهای موازی سیستم در آن کشف می شوند و توالی غیر ضروری فرآیندها مشخص می گردند. برخی افراد به جای نمودار فعالیت ، نمودار تعالم را می پسندند.
4) بعد از الگوی حوزه مسئله ، نوبت به موارد کاربرد می رسد. همانطور که قبلا نیز اشاره شد در مورد کابرد نیازمندی های سیستم شناسایی می گردند سپس همه نمودارها را در قالب یک نمودار حوزه مسئله می آوریم و با یک یا دو نفر از متخصصین خود حوزه مسئله تبا دل نظر می کنیم حال یک الگوی حوزه مسئله که همه نیازمندی ها را نشان می دهد در دست داریم. سپس به ساخت کلاس ها و ورود به مرحله ساخت می پردا زیم. حداقل گروه ایجاد کننده مدل حوزه مسئله یک یا دو توسعه دهنده و یک یا دو خبره مسئله و حداکثر 4 نفر برای این کار مناسبند. ایجاد نمونه اولیه نیز وسیله مناسبی در محقق سازی بهتر این مرحله است . البته همه این نکات صرفا یک توصیه است.
ریسک فنی
در بررسی فنی برای ایجاد نرم افزار ، لازم است تا تبعات به کار گیری تکنولوژی بررسی شود. به عنوان مثال از چه کامپایلری استفاده شود؟ (C++,Delphi,… ) ؤ موتور پایگاه داده چیست ؟ (Oracle, SQL,…. ) . همچنین اثر متقابل این انتخاب ها بر یکدیگر مهم است. در این بررسی لازم است تبعات سخت افزاری این انتخاب بر یکدگیر مهم است در این بررسی لازم است تبعات سخت افزاری این انتخاب نیز بررسی شود. به هر حال تصمیمات طراحی معماری مهم است . در این میان تمرکز بر نواحی ای که در آینده به سختی قابل تغییر باشند مهمتر است . برای کشف این نقاط نیز موارد کاربرد مناسب هستند. همچنین نمودارهای کلاس و تعامل برای نمایش اینکه اجزاء چگونه با هم مرتبط می شوند مفید هستند. نمودارهای بسته نیز می توانند تصویر سطح بالایی از اجزا را نشان دهند. همچنین نمودارهای استقرار می توانند منظر گاهی را از اینکه چگونه قسمت های مختلف سیستم توزیع شده اند به دست دهند. برای کسب اطلاعات بیشتر به فصل های مربوطه مراجعه کنید.
ریسکهای پروژه UML
ریسک مهارت
برای کسب مهارت در مبحث شی گرا ، بهترین راه استفاده از مربی است که در طول پروژه در کنار شما قرار گیرد اگر چنین حالتی امکان نداشته باشد استفاده از مربیان تمام وقت یا پاره وقت نیز برای بازنگری پروژه مفید است. اگر این حالت نیز امکان نداشت، هر ماه یا هر دو ماه با دعوت از یک مربی خبره مدل های خود را بازنگری کنید. توصیه می شود هر ماه یک کتاب تکنیکی بخوانید حتی بهتر است که به صورت گروهی مطالعه کنید و به تبادل نظر بپردازید .
الگوها نیز ابزا رهای مناسبی برای آموزش و اعتبار سنجی مدل هاست. بنابراین لازم است از آخرین وضعیت الگوها باطلاع باشید.
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
معماری خط پایه
نتایج و خروجی مرحله تفصیل ، معماری خط پایه است این معماری شامل موارد زیرمی گردد.
• فهرست موارد کاربرد که نیازمندی های سیستم را بیان می کند
• مدل حوزه مسئله که درک شما را از سیستم نشان می دهد و نقطه شروع کلاس های اساسی حوزه مسئله است.
• ساختار تکنولوژی انتخاب شده که تکنولوژی پیاده سازی و جفت و جور شدن عناصر آنها را توصیف می کند.
این معماری ، پایه ای برای توسعه است . اصطلاحا به این معماری ، طرح اولیه مراحل بعد گفته میشود.
چه زمانی مرحله تفصیل پایان می یابد؟
دو رخداد مهم برای نمایش دادن پایان مرحله تفصیل عبارتند از :
1) تقریبا با اطمینان بتوان برای آینده پروژه تخمین زد.
2) شناسایی همه ریسک ها و آمادگی برای حل هر کدام از آنها انجام شده باشد.
برنامه ریزی
اساس برنامه ریزی تعیین تکرارهای ساخت و تخصیص مورد کاربرد به هر تکرار است. برای این منظور قدم های زیر پیشنهاد می شود:
قدم اول : طبقه بندی موارد کاربرد : کاربر بایستی سطح اولویت هر یک از موارد کاربرد را مشخص کند. معمول می توان این کار را در سه سطح بالا ، متوسط و پایین انجام داد
قدم دوم : در نظر گرفتن ریسک معماری برای هر مورد کاربرد : توسعه دهنده ، این ریسک را در سه سطح مشخص می کند . این ریسک عبارت است از ریسکی که اگر این مورد کاربرد در پروژه برای مدتی به تعویق افتد ، تکمیل کارهایی که تاکنون انجام شده اند ، چقدر باعث دوباره کاری می گردد؟
قدم سوم : در نظر گرفتن ریسک برنامه ریزی برای هر مورد کاربرد : که عبارت از میزان اطمینان توسعه دهنده نسبت به تخمین کار مورد نیاز برای هر مورد کاربرد است.
طول زمانی که هر مورد کاربرد بر حسب نفر ـ هفته را با فرض انجام تحلیل ، طراحی ، کدنویسی ، تست ، مجتمع سازی و مستند سازی به دست آورید. نکته قابل توجه اینست که تخمین زدن را باید کارشناس توسعه انجام دهد نه مدیر. اگر برخی از موارد کاربرد دارای ریسک بالا بودند نیاز به مرحله تفصیل دوباره ، برای این موارد کاربرد پیش می آید.
قدم چهارم : تعیین طول تکرار برای کل پروژه : لازم است یک طول ثابت زمانی برای کلیه تکرارها در کل پروژه مشخص گردد. این طول زمانی بایستی باندازه کافی بزرگ باشد تا بتوانید چند مورد کاربرد را در هر تکرار انجام دهید. به عنوان مثال برای زبان Smalltalk میتوانید دو تا سه هفته و برای c++ شش هفته یا بیشتر باشد. در محاسبات لازم است این گونه در نظر بگیرید که از 50 % توان یک کارشناس توسعه استفاده می شود ، سپس طول تکرار را در نصف تعداد توسعه دهنده ها ضرب کنید ، نتیجه به دست آمده ، مقدار کار توسعه را برای هر تکرار مشخص می کند. برای نمونه با 8 توسعه و طول تکرار 3 هفته ای در هر تکرار (12 = 8 * 3 * 1.2 ) نفر – هفته در هر تکرار داریم.
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
جمع کل زمان موارد کاربرد را بر مقدار مورد نیاز در هر تکرار (عدد به دست آمده در مرحله قبل ) تقسیم کنید و با عدد یک جمع کنید ، عدد به دست آمده اولین تخمین شما از تعداد تکرارا مورد نیاز در پروژهتان است. عدد یک برای اطمینان بیشتر به مقدار فوق افزوده می شود.
قدم پنجم : تخصیص موارد کاربرد به تکرارها: بر اساس اولویت هایی که قبلا توضیح داده شد، در هر تکرار ، تعدادی مورد کاربرد قرار دهید. ابتدا موارد کاربرد با اولویت بالاتر را به تکرارها تخصیص دهید. برای پیش بینی مقدار زمان مورد نیاز در مرحله انتقال معمولا 10 % تا 35 % از مرحله ساخت را به عنوان تخمین مرحله انتقال قرار می دهند . همچنین 10% تا 20 % از مرحله ساخت را برای پیشامدهای اتفاقی قرار میدهند.
برنامه ای که به روش فوق به دست می آید و با تبادل نظر کاربر و کارشناس توسعه ایجاد می شود به برنامه توصیه ای معروف است .
بنابراین ، موارد کاربرد پایه های برنامه ریزی هستند که UML نیز بر آنها تاکید زیادی دارد.
مرحله ساخت
در مرحله ساخت ، سیستم در طی یک سری تکرار ایجاد می شود در هر تکرار نیز تأیید کاربر اخذ می شود . هدف از این فرایند کاهش ریسک است .
==============
سلام
==============
جمعه 6 فروردین 1395 1:28 PM
a00bcom
a00bcom
کاربر تازه وارد
تاریخ عضویت : فروردین 1395
تعداد پست ها : 31
محل ست : اصفهان
پاسخ به:آشنایی با UML زبان مدل سازی یکپارچه در پروژه های مهندسی نرم افزار بخش پنجم
معمولا تست ها را نیز به دو دسته تقسیم می کنند.
1) تست واحد : که به وسیله کارشناس توسعه انجام می شود .
2) تست سیستم : که به وسیله گروه تست بیرونی انجام می شود این گروه باید به دیدیک جعبه سیاه به برنامه اصلی نگاه کند .
دسته بندی مجدد
وقتی تابعی را به برنامه ای اضافه می کنید چون از قبل برای حضور آن پیش بینی نکرده اید برنامه ازکیفیت خوبی برخوردار نخواهد شد .برای جلوگیری از خراب شدن کیفیت برنامه دو راه وجود دارد :
1) طراحی دوباره برنامه و کدنویسی کامل برای طراحی جدید
2) اضافه کردن به برنامه موجود و اصلاح و تطبیق آن با برنامه
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
مراحل تست در UML
قدم های دسته بندی مجدد
تغییرات دسته بندی مجدد معمولا قدم های کوچکی دارد : تغییر نام یک متد ، انتقال یک صفت از کلاسی به کلاس دیگر ، تفکیک کردن متدهای مشابه از کلاس ها و قرار دادن در یک فوق کلاس و…
نکاتی در مورد دسته بندی مجدد
1) دسته بندی مجدد واضافه کردن به کد را هم زما ن ا نجام ندهید .
2) قبل از دسته بندی مجدد از تست برنامه مطمئن شوید .
3) ابتدا خوب فکر کنید و صفات مناسب را جابجا کنید و موارد مشابه را در فوق کلاس ها قراردهید .
چه وقت دسته بندی مجدد کنیم ؟
1) وقتی برای اضافه کردن وظیفه ای ، به یک کد قدیمی برمی خوریم که مشکل اضافه کردن کد ایجاد می شود .
2) وقتی فهمیدن کد موجود ، سخت است .
همه تکنیک های UML در مرحله ساخت مفید هستند . برخی از نمودارها که استفاده فراوان تری دارند در زیر توضیح داده می شود .
1) از نمودار مورد کاربرد برای تعیین محدوده مورد نظرتان استفاده کنید .
2) نمودار کلاس مفهومی برای درک مفاهیم درون مورد کاربرد مفید است .
3) نمورار فعالیت را برای تشخیص جریان کار عناصر درون مورد کاربرد مفید است .
قدم بعدی ،تحلیل این نمودارها و اصلاح آن با کمک و نظر کاربر است . در این مرحله به نظر کاربر بسیار اهمیت داده میشود و برون نظر او تصمیم گیری کردن کار نادرستی است.
برای ورود به طراحی ترسیم نمودار کلاس از چشم انداز تشخیصی برای آنکه کلاس را با جزئیات بیشتر ببینیم مفید است . نمودارهای تعغامل برای نمایش اینکه چگونه کلاس ها با هم تعامل میکنند تا مورد کاربرد را پیاده کنند ارزشمند هستند
برای ترسیم نقشه ای منطقی از سیستم از نمودارهای بسته استفاده کنید . این نمودار نقشه منطقی سیستم ووابستگی بین آنها را به خوبی نشان میدهد .
الگو ها
الگوها راه های متداول انجام بعضی کارها را نشان می دهند . الگوها به عنوان نتیجه فرایندها به صورت مدل های مثالی به نظر می رسند . یک الگو ، یک مدل ساده است که از نظر طراحی بسیاری از مشکلات را مرتفع می کند و توسعه دهنده ، پس از تجربیات زیاد و به کاربردن آن در سیستم های مختلف آن را کامل کرده است و به گونه ای در آمده است که می تواند در بسیاری از سیستم ها به کار رود و بسیاری از مشکلات را مرتفع کند و استحکام مدل را بالا ببرد . همچنین زمان مدل سازی را کاهش دهد و قابلیت استفاده مجدد را به نمایش گزارد .
کتاب های مهمی در زمینه الگوهای تحلیل و طراحی وجود دارد که بهتر است برای قوی کردن دیدگاههای مدل سازی تان آنها را مطالعه کنید .
مرحله انتقال
پس از همة تکرارها هنوز یک قدم باقی مانده است و آن مرحله انتقال است . بنابراین پس از همه تکرارها گروه توسعه دهنده به پایان کد نویسی می رسند . و آماده اند تا محصول را به کاربر تحویل دهند .
بهینه سازی ، کارایی را بهبود می بخشد . بهینه سازی برای آن است که سرعت سیستم را در جهت رفع نیازمندی های کاربر ، به اندازه کافی بالا ببرد . در طول مرحله انتقال ، اضافه کردن وظیفه ای به سیستم وجود ندارد بلکه حداکثر برای رفع اشکال سیستم این مورد می تواند بروز کند . مثال خوبی از مرحله انتقال فاصله زمانی مابین محصول بتا و محصول نهایی است . در زمینه فرآیند مراجع (Booch-94 ) و (Jacobson –99 ) مناسب هستند .
مرور
در ایجاد یک مدل شیء گرا می توان مدل را براساس سه دیدگاه یا چشم انداز ترسیم کرد که عبارتند از : مفهومی ، تشخیصی و پیاده سازی . بسته به آن که ترسیم کننده مدل ، با چه دیدگاهی در حال ترسیم مدل است جزئیات درون مدل کمتر یا بیشتر می باشند .
دید عمیق تر نسبت به سیستم و اینکه در هر مورد کاربردی چه اشیائی با هم در ارتباط هستند از طریق نمودارکلاس فراهم می آید در ابتدا بهتر است که نمودار کلاس را از دیدگاه یا چشم انداز مفهومی ترسیم کنید دراین دیدگاه در حال ترسیم نموداری هستید که زبان کاربر را نمایش می دهد .
همچنین برای آنکه جریان کاری سیستم کاربر را درک کنید و بفهمید که برای هر مورد کاربرد از چه فعالیت هایی و با چه ترتیبی استفاده می گردد، نمودار فعالیت ابزار مناسبی است .
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
در پروژه های پیچیده و بزرگ تحلیل گر یا مدیر پروژه برای آنکه بتواند سیستم را خیلی سریع مرور کند و از پیشرفت امور با خبر شود و نیز برای آنکه کنترل مدل آسانتر و درک آن ساده تر شود نیاز به ابزاری است تا این پیچیدگی را مدیریت کند . برای این منظور نموداربسته ها وسیله ای مناسب است .
مجموعه ای از کلاسها که با یکدیگر ارتباط تنگاتنگ دارند را در یک بسته قرار می دهیم و این کار را تکرا ر می کنیم در نهایت به عنوان مثال از یک نمودار کلاس که دارای 100 کلاس می باشد به یک نمودار بسته می رسیم که از 10 بسته تشکیل شده است این مدیریت پیچیدگی برای تمام عناصر درون مدل UML نظیر : مورد کاربرد ، نمودارفعالیت نمودار حالت و … کاربرد دارد و تنها مختص کلاس نیست .
الگوها نیز ابزار مناسبی هستند تا بتوا نید ایده های اساسی سیستم را بیان کنید الگو کمک می کند تا ارزیابی خوبی از طرح و مدل تان بیان کنید . آنها برای توصیف طرح هایی که پذیرفته نمی شوند نیز مفید هستند .
UML یک زبان مدل سازی است وفارغ ازفرایند و متدولوژی است .UML هیچ توصیه ای به روش به کارگیری خود نمی کند و به همین دلیل است که سه مبدأ آن را با عنوان زبان مدل سازی نام می برند و نه روش یا فرایند . اما از آنجا که به هرحال ایجاد هر مدلی مبتنی بر یک متدولوژی یا فرایند خواهد بود ، سه مبدع UMLکتابی نیز برای بیان فرایند با استفاده از UML به چاپ رسانده اند و در آن متذکر شده اند که برای استفاده از UMLچه فرایند و روشی را به کار می گیرند .
طول مدت(ساعت)
دوره تحلیل نیازمندی ها در یک نگاه
2
دلایل اهمیت مهندسی نیازمندی ها و تعاریف
2
تعاریف و مفاهیم
2
تکنیک های شناسایی مساله
8
مستند سازی مساله و راه حل های آن
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com8
تکنیک های ارائه و مستند سازی راه حل
8
نیازمندی های نرم افزاری در متدولوژی های RUP و Agile
4
مبانی تحلیل شی گرا
4
کاربرد UML در مدل سازی نیازمندی های نرم افزاری با استفاده از ابزار مدل سازی
4
در طی دوره ۳ پروژه با مفاهیم آموزش داده شده مورد بررسی قرار خواهد گرفت. انجام پروژه Power Designer
ویژوال پارادایم (Visual paradigm)
مدیریت فرآیند تولید نرم افزار UML , RUP
، ,های ,مدل ,کاربرد ,مرحله ,یک ,می شود ,مورد کاربرد ,حوزه مسئله ,موارد کاربرد ,09367292276 azsoftir@gmail ,09367292276 09367292276 azsoftir@gmail ,انداز مفهومی ترسیم ,کارشناس توسعه انجام ,برای نمایش اینکه
درباره این سایت