سرفصل و محتوای دور
(1)The difference between “theory” and “practice” is that in theory there is no difference between theory and practice, but in practice, there is
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
معرفی و هدف دوره : مهمترین بخش از انجام یک پروژه نرم افزاری فهم مساله ای است که سیستم برای آن تولید می شود. تا جایی که می توان گفت اگر نیازمندی‌ها را به درستی شناسایی نکنید، خوب انجام دادن بقیه پروژه، دیگر اهمیتی نخواهد داشت.
در دوره تحلیل سیستم های نرم افزاری، راهکاری روش مند برای تعریف مساله و ارائه راه حل آن به دانشجویان به صورت عملی ارائه خواهد شد. این دروره بر استفاده عملی از مفاهیم مهندسی نیازمندی ها تاکید دارد و در طی دوره چند پروژه عملی با تکنیک های آموزش داده شده بررسی و حل خواهد شد.
در این دوره کاربردهای زبان UML به عنوان زبان استاندارد مدلسازی جهت کار تیمی و لازمه حضور در تیم و به عنوان ابزار نمایش جواب مسألهای که با آن روبرو هستید را خواهید آموخت. همچنین مبانی شیءگرا را که به عنوان نوعی نگرش برای بررسی مساله و ارائه راه حل را خواهید شناخت.
مشاهده رزومه استاد
مشاهده درس در نقشه راه
در این دوره در مدت۴۲ ساعت مفاهیم زیر را خواهید آموخت.
عنوان
آشنایی با UML زبان مدل سازی یکپارچه در پروژه های مهندسی نرم افزار بخش اول
آشنایی با UML
زبان مدل سازی یکپارچه (UML) زبانی است برای مشخص سازی ، مجسم سازی ، ساخت و مستند سازی دست آوردهای سیستم های نرم افزاری و مدل سازی و کار و دیگر سیستمهای غیر نرم افزاری .
Uml مجموعه ای از بهترین تجربیات مهندسی که موفقیتشان در مدل سازی سیستمهای بزرگ و پیچیده به اثبات رسیده است را عرضه می دارد.
تعریف UML شامل اسناد زیر می گردد :
معنا شناسی UML : که مفاهیم غنی و دستور نگارش وعلا ئم زبان مدلسازی یکپارچه را تعریف می کند UMLبه وسیله بسته ها به صورت معماری گونه لا یه بندی و سازماندهی میشود . در هر بسته عناصر مدل بر حست دستور نگارش (با استفاده از متن و عبارت زبان محدودیت شیء معروف به OCL )و معانی (با استفاده از متن دقیق) تعریف می شوند .
راهنمای علائم UML : فکر و اندیشه را تعریف می کند و مثال های خوبی را ارائه می کند. علائم UML نحو گرافیکی را برای بیان معانی توصیف شده توسط فرا مدل های UML ارائه می کند.
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
توسعه ی UML برای فرایند شیءدر مهندسی نرم افزارو توسعه UML برای مدل سازی تچارت : این توسعه های UML شامل توسعه خاص فرایند و توسعه خاص حوزه مسئله در UML برحسب مکانیزم های توسعه ای شان و آیکون نمودار فرایند می گردد .
2) فراهم آوردن مکانیزم های توسعه و تخصیص برای بسط مفاهیم اساسی : بدین معنا که در عین آنکه انتظار میرود UML براساس نیازهای جدید در حوزه های خاص جفت و جور شود نمی خواهد اجبار کند تا مفاهیم اساسی و مشترک برای هر حوزه جدیدی دوباره تعریف شود و پیاده سازی گردد. البته مفاهیم اساسی نباید بیش از حد تغییر یابند. بنابراین کاربران نیازمندند که قادر باشند : 1- مدل ها را با استفاده از مفاهیم اساسی بسازند بدون آنکه مکانیزم های توسعه را برای بسیاری از برنامه های کاربردی نرمال بکار گیرند .
2- مفاهیم و علائم جدید را اضافه کنند البته برای مواردی که توسط اصول پوشیده نشده باشند .
3- زمانی که هیچ اتفاق نظر روشنی وجود ندارد تفاسیر مختلف را از مفاهیم موجود انتخاب کنند .
4- مفاهیم، علائم و محدودیت ها را برای حوزه های کاربردی خاص مشخص سازند .
3) استقلال از زبان های برنامه نویسی خاص و فرایندها ی توسعه .
4) فراهم آوردن پایه و اصولی رسمی برای درک زبان مدل سازی که برای این منظور UML تعریف رسمی از قالب استاتیک مدل را با استفاده از نمودار کلاس ارائه می کند این نمودار ، نموداری مشهور و مورد قبول در سطح وسیع برای تعییین قالب یک مدل است UML همچنین محدودیت هایی را بیا ن میدارد که در قالب زبان دقیق طبیعی و عبارات زبان محدودیت شیء (OCL ) بیان می شود .
5) تشویق به رشد بازار ابزارهای OO .
6) حمایت و پشتیبانی از مفاهیم توسعه سطح بالاتر نظیر : همکاری ها ، چهارچوب ها ،الگوها و اجزاء .
7) مجتمع سازی بهترین تجربیات : UML بدنبال آن است که بهترین تجربیات درصنعت
حوزه های مسئله ، معماری ها و … را یکجا بیاورد .
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
محدوده UML
زبان مدل سازی یکپارچه UML زبانی است برای مشخص سازی ساخت ،مجسم سازی و مستند سازی دست آوردهای یک سیستم متمرکز نرم افزاری اول آنکه این زبان از مفاهیم OOSE,OMT,BOOCH که متدولوژیهای متداول OOمیباشند متنج شده است . دوم ، UMLبر آنچه که در حال حاضر توسط روش های موجور فابل انجام همتند ، بان شده است . سوم زبا ن مدل سازی یکپارچه بر یک زبان مدل سازی استانارد تمرکز می کند و نه یک فرآیند استاندادر اگر چه UMLبایستی در زمینه یک فرایند به کارگیری شود تجرته نشان میدهد که در سازمان های مختلف و با حوزه های مسئله متفاوت فرایندهای متفاوتی مورد نیاز است بنابراین تلاش بر این است که ابتدا بر یک فرامدل مشترک (که معانی را یکپارچه میکند )تمرکز شود و در درجه دوم بر یک علامت گذاری مشترک (که برای فرد استنباط این معانی را فراهم میکند )تمرکز گردد مبدعین UMLبر فرایند توسعای تاکید میکنند که مورد کاربرد گرا معماری گرال و تکراری و افزایشی است .
UML یک زبان مدلسازی را مشخص می کند که اتفاق نظر جماعت شیگرا بر مفاهیم اساس مدل سازی است .
1) 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 معتقدند که مجموعه ای از تکنیک های موفقیت آمیز و عملی را که در یک دیدگاه مستحکم و پا بر جا جفت می شود ، تعریف کرده اند.
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
زبان برنامه نویسی
UML یک زبان بصری است و هدفش یک زبان برنامه نویسی بصری نیست ، در عین آنکه همه مفاهیم و تجسمات را پشتیبانی می کند تا جایگزین زبان های برنامه نویسی شود. UML زبانی است برای بصری سازی ، مشخص سازی ، ساخت و مستند سازی دست آوردهای یک سیستم نرم افزاری ، و از طرفی مسیری را فراهم می کند که شما را به سمت کد هدایت می نماید. برخی چیزها شبیه انشعاب ها و ادغام های پیچیده در یک زبان برنامه نویسی متنی بهتر بیان می شوند. UML نقشه ای قوی برای خانواده ای از زبان های دارد. در عین حال شما می توانید از بهترین های هر دو دنیا استفاده کنید.
ابزار
استاندارد سازی یک زبان ضرورتا اساس ابزارها و فرآیندها هستند که UML ، مفاهیم و علائم آن را تعریف می کند و نه خود ابزار را . بنابراین UML ابزار نیست.
فرآیند
بسیاری از سازما ن ها ، UML را به عنوان زبان متداول برای تولید دست آوردهای پرروژه هایشان استفاده می کنند، اما انواع نمودارهای UML را در فرآیندهای مختلف استفاده می کنند. UML اساسا مستقل از فرآیند است ولی فرآیند استانداردی را نیز تعریف میکند که هدف UML نیست. فرآیندها بر اساس طبیعت شان بایستی برای سازمان ها ، فرهنگ ها و حوزه های مسئله دوخته شوند.
مقایسه UML با د یگر زبان های مدل سازی
UML بر اساس موفقیت های سه روش مدل سازی OOSE , OMT , BOOCH و ایجاد شده است و کاربران هر یک از این سه روش ، می توانند به راحتی از UML استفاده نمایندت. UML برای استفاده شدن توسط کاربران روش های دیگر نیز آماده و آسان می باشد.
UML هم اکنون روشن تر ، مستحکم تر و یک شکل تر از Booch,OMT.,OOSE و دیگر روش ها می باشد . این بدین معنا است که در انتقال به UML این ارزش وجود دارد که به شما اجازه می دهد تا در پروژه ها چیزهایی را مدل سازی کنید که قبل از این انجام شدنی نبودند.
کاربران روش های موجود، تغییرات اساسی و زیادی را در علامت گذاری تجربه خواهند کرد. اما این به معنای نیاز به یادگیری مجدد با تعریف مجدد مفاهیم حاضر نیست. کاربران هر یک از روش های OO می توانند سرعت زیادی را در یادگیری شان انتظار داشته باشند. تکنیک های پیشرفته نظیر به کارگیری کلیشه ها و خواص ، نیازمند مطالعه هستند. البته این موارد نیز در زمان برخورد با مسئله ، مورد نیاز می شوند.
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
ویژگی های جدید UML
هدف کلیه تلاش های یکپارچه سازی که در UML به کار می رود ، حفظ سادگی است به گونه ای که عناصر غیر کاربردی روش های OMT, Booch,OOSE طرد شوند و عناصر مؤثر از روش های دیگر به آن اضافه گردند.
مفاهیم جدید زیادی در UML وارد شده اند ، نظیر : مکانیزم های توسعه شامل کلیشه ها ، مقادیر ضمیمه و محدودیت ها ، توزیع و همروندی (به عنوان مثال برا ی مدل سازی CORBA,Active/DCOM الگوها / همکاری ها ، نمودارهای فعالیت (برای مدل سازی فرآیند کار ) ، پالایش (برای اجرا یا به کارگیری ارتباطات بین سطوح مجرد ) واسطه ها و اجزاء ، و یک زبان محدودیت .
بسیاری از این مفاهیم در نظریه ها و روش های انفرادی مختلف وجود داشتند و UML آنها را به دورن انسجام خودش کشاند . به علاوه این تغییرات اساسی ، بهبودهای ریز دیگری نیز بر اساس مفاهیم و علائم ،OOSE ,Booch.OMT وجود دارد. بنابراین بسیاری از مفاهیم و علائم UML را خود نویسندگان آن ایجاد نکرده اند بلکه نقش آنها ، جمع آوری مناسب ، انتخاب و یکپارچه کردن این مفاهیم و علائم در UML بو ه است . در این زمینه ، موارد زیر قابل ذکر است :
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
• نمودارهای مورد کاربرد مشابه آنچه درOOSE ارائه شد می باشند.
• نموداراهای کلاس ، ذوب شده Booch،OMT و دیگر روش ها است. کلیشه ها ، محدودیت و مقادیر ضمیمه مفاهیمی هستند که قبلا در زبان های مهم مدل سازی وجود نداشتند و اکنون در UML ظهور کرده اند.
• نمودارهای حالت اساسا مبتنی بر جداول حالت David Harel می باشند. نمندار فعالیت که مفاهیم مشابهی را بیان می دارد ، مشابه نمودئار جریان کار است که توسط بسیاری از منابع پیش از OO ایجاد گردیدند. شرکت Jim Odell , Oracle سبب ساز ورود نمودارهای فعالیت به UML بودند.
• نمودارهای توالی در بسیاری از روش های OO تحت نام های متفاوت (نظیر : تعامل ، ردگیری پیام و ردگیری واقعه ) و نیز روزهای قبل از OO یافت می شدند. نمودارهای همکاری از Booch ( با نام Object Diagram) و Fusion ( با نام Object Interaction Graph) ، و تعدادی منابع دیگر پذیرفته شدند.
• نمودارهای پیاده سازی (شامل نموداراهای اجزاء و استقرار ) از نمودارهای ماژول و فرآیند در Booch مشتق شدند، اما هم اکنون این نمودارها به جای آنکه ماژول گرا باشند ، اجزاء گرا هستند و خیلی بهتر به هم متصل می شوند
• کلیشه ها یکی از مکانیزم های توسعه هستند و مفاهیم فرامدل را بسط می دهند. آیکون های تعریف شده کاربر با کلیشه های موجود متناظر می شوند تا UML را برای فرآیندهای مشخصی خیاطی کنند.
• زبان محدودیت شی (OCL) به وسیله UML استفاده می گردد تا مفاهیم را مشخص سازد و به عنوان زبانی برای بیان مدل سازی جاری به کار گرفته شود. OCL یک زبان بیانی است که در روش Syntropy ریشه دارد و به وسیله زبان های بیانی ، در روش های دیگر نظیر Catalysis مورد تاکید واقع می شود.
• هر یک از این مفاهیم ، پیش فر ض ها و اثرات بسیار زیاد دیگری هم دارند. OMG اعتراف می کند که هر فهرست خلاصه ای از این اثرات ، ناقص است . UML محصولی از یک تاریخ عظیم اندیشه ها در علم کامپیوتر و ناحیه مهندسی نرم افزار است.
==============
سلام
==============
جمعه 6 فروردین 1395 1:00 PM
a00bcom
a00bcom
کاربر تازه وارد
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com31
محل سکونت : اصفهان
آشنایی با UML زبان مدل سازی یکپارچه در پروژه های مهندسی نرم افزار بخش دوم
UML ، گذشته ، حال و آینده
UML به وسیله شرکت نرم افزاری (Ration So ftware ) و شرکایش ایجاد شد . UML جانیشین های زبان های مدل سازی ای است که در ، Booch Reumbugh // OOSE Jacoboson و روش های دیگر یافت می شوند. بسیاری از شرکت ها در حال جای دادن UML در خود به عنوان یک استاندارد در فرآیند توسعه و محصلوات شان هستند ، که نظام هایی نظیر : مدل سازی کار ؤ مدیریت نیازمندی ها ؤ تحلیل و طراحی ؤ برنامه نویسی و تست را می پوشاند.
زمینه UML
زبان های مدل سازی شی گرا از اواسط دهه 1970 آغاز به ظهور کردند و از اواخر دهه 1980 ، متدولوژیست های زیادی ، رویکردهای متفاوتی را برای تحلیل و طراحی شی گرا بیان کردند. تکنیک های متعدد دیگری نیز بر این زبان ها اثر گذاشتند ، نظیر : مدل ساز ی ارتباط موجودیت ، زبان SDL و دیگر تکنیک ها .
تعداد زبان های مدل سازی تعریف شده در دوره زمانی بین 1989 تا 1994 ، از 10 عدد به بیش از 50 عدد رشد کرد. بسیاری از کا ربران روش های OO در یافتن یک زبان مدل سازی که رضایت کامل آنها را جلب کند ، با مشکل مواجه بودند و از طرفی در حال سوخت رسانی به جنگ روش ها بودند. از اواسط دهه 1990 ، تکرار جدیدی از این روش ها آغاز به ظهور کرد، نظیر Booch 93 ، تکامل مستمر OMT/Rumbugh و Fusion . این روش ها آغاز به داخل کردن تکنیک های دیگران به روش های خودشان کردند و روش هایی نظیر Booch93 , OMT-2.OOSE/Jacobson ایجاد گردید . هر یک از این روش ها نیز به نوبه خود یک روش کامل بود.
Jacobson, Rumbaugh ,Booch نیروهایشان را به هم پیوستند توسعه UML در اکتبر 1994 زمانی که Jim Rumbaugh,Grady Booch از شرکت Rational Software Corporation کارشان را برای یکی کردن روش های Booch و OMT آغاز کردند ، شروع گردید . در اکتبر 1995 نسخه 8 ، از Unified Method (که همین طور نام گذاری شده بود ) بیرون آمد . در پائیز 1995 ، Ivar Jacoboson و شرکت Objectory اش به Rational پیوستند. و روش OOSE را نیز در آن ادغام کردند. هم اکنون از نام Objectory برای توصیف فرآیند UML استفاده می شود.
تلاش های Jacobson.Rumbaugh,Booch در اصلاح و انتشار اسناد 0.9-0.91 در ژوئن و اکتبر 1996 به نتیجه رسید. در سال 1996 ، نویسندگان UML از جامعه دعوت کردند و بازخورهایی را نیز دریافت کردند. اگر چه آنها این بازخورها را یکپارچه کردند ، اما توجه متمرکز بیشتری هنوز مورد نیاز بود.
UML 1.0-1.1 و شرکای UML
در سال 1996 مشخص شد که سازمان های متعدد ، UML را از دید استراتژیک می بینند. درخواست پیشنهادی که از سوی OMG منتشر شد ، کاتالیزوری را فراهم کرد تا این سازمان ها برای تولید یک پیشنهاد به درخواست فوق بپیوندند. Rational ، کنسرسیوم شرکای UML را با سازمان های چندی ایجاد کرد تا منابع شارن را برای کار کردن بر روی تعریف UML 1.0 متمرکز کنند.
بیشترین مشارکت کنندگان در تعریف UML1.0 عبارت بودند از :
ICON,IBM , IntelliCrop > I-Logix, HP, Digital Equipment Corp.
Tl, Rational Software, Oracle, Microsoft, MCI Systembouse, Computing Unisys. این همکاری ، UML 1.0 را تولید کرد که یک زبان مدل سازی با تعریف ، بیان قدرت و کاربرد عمومی خوبی بود. این کار در ژنوایه 1997 به عنوان عکس العمل اولیه به درخواست فوق به وسیله OMG پذیرفته شد.
در ژانویه 1997 ، شرکت های Ptech, platinum Technology و Taskon & IBM & ObjecTime SofteamوReich Technologies نیز یک پیشنهاد مجزا را به OMG ارائه کردند . این شرکت ها به شرکای UML پیوستند تا افکارشان را سهیم کنند و با یکدیگر UML 1.1 را ایجاد نمایند. تمرکز به UML 1.1 بهبود وضوح و روشنی مفاهیم UML 1.0 و نیز شرکت دادن شرکای جدید در این همکاری بود. این نسخه نیز توسط OMG به تصویب رسید.
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
UML حال و آینده
UML غیر خصوصی است و برای همه باز است . UML نیازهای کاربران و اجتماعات علمی را نشانه می رود. بسیاری از متدولوژیست ها ، سازمان ها و تولید کنندگان ابزار ، خود را در استفاده از آن متعهدا کرده اند. از آنجا که UML مفاهیم و علائم مشابهی از Booch,OMT,OOSE و دیگر روش های مهم را ارائه می کند و با وارد کردن شرکای UML و باز خور عمومی به خود ، شخصیت قانونی ارائه کرده است ، انتخاب وسیع UML بایستی کار درستی باشد.
نمونه ای از نمودار UML
دو جنبه یکپارچگی که زبان مدل سازی یکپارچه (UML ) به دست آورده است عبارتند:
1) UML به صورت مؤثری به بسیاری از اختلاف ها پایان می دهد که غالبا هم در زبان های مدل سازی روش های قبلی ظهور کرده بود.
2) UML ، دیدگاه ها را در انواع مختلف سیستم ها ( کسب و کار در مقابل نرم افزار ) ، مراحل توسعه (تحلیل نیازمندی ها ، طراحی و پیاده سازی )، و مفاهیم درونی ، یکپارچه می کند.
3) استاندارد سازی UML
بسیاری از سازمان ها ، UML را به عنوان استاندارد سازمانی شان تایید کرده اند ، به دلیل آنکه UML از زبان های مدل سازی که توسط روش های مهم OO ارائه شده اند منبعث شده است . UML برای استفاده روزمره و همگانی بسیار مطلوب است.
صنعتی سازی
بسیاری از سازمان ها و تامین کنندگان جهان ، UML را پذیرفته اند. تعدادی از سازمان های تایید کننده UML انتظار می رود تا در آینده رشد قابل توجهی بنمایند. این سازمان ها ، استفاده از UML را به وسیله ایجاد اسناد قابل دسترس و ساده تشویق می کنند. همچنین با تشویق متدولوژیست ها ، تامین کنندگان ابزار ، سازما ن های آموزشی و نویسندگان به انتخاب UML در کارهایشان ، مسیر صنعتی سازی آن را هموارتر می نمایند.
تکامل UML آینده
اگر چه UML یک زبان دقیق را تعریف می کند اما سدی برای بهبودهای آینده در مفاهیم مدل سازی نیست . بسیاری از تکنیک های رهبری را در نظر گرفته شده است اما انتظار می رود تا تکنیک های اضافه تری ، نسخه های آینده UML را ایجاد کنند. بسیاری از تکنیک های پیشرفته می توانند با استفاده از UML به عنوان پایه ، تعریف گردند. UML می تواند بدون تعریف دوباره هسته خودش ، بسط داده شود. UML در شکل موجودش ، انتظار می رود تا پایه ای برای بسیاری از ابزارها باشد، ابزارهایی برای : مدل سازی تجسمی ، شبیه سازی و محیط های توسعه . همان گونه که یکپارچه سازی ابزارها توسعه داده می شوند ، استانداردهای پیاده سازی مبتنی بر UML نیز به صورت وسیعی قابل دسترس خواهند شد.
===
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.comPM
a00bcom
a00bcom
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
09367292276
09367292276
azsoftir@gmail.com
azsoftir.com
آشنایی با 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
در طی دوره ۳ پروژه با مفاهیم آموزش داده شده مورد بررسی قرار خواهد گرفت.