ارسال پاسخ 
 
امتیاز موضوع:
  • 1 رأی - میانگین امتیازات: 5
  • 1
  • 2
  • 3
  • 4
  • 5
آشنایی با UML
06-15-2016, 01:06 AM (آخرین ویرایش در این ارسال: 11-04-2019 12:15 PM، توسط ali.)
ارسال: #1
آشنایی با UML
مبلغ این فایل در قالب WORD و DOCX فقط 7500 تومن و دانلود پس از پرداخت دارای 300 صفحه می باشد: (09131253620)
پرداخت:
http://www.a00b.com/SelectEBank.aspx?ID=2201



فهرست مطالب
فصل اول:UML چیست 7
روند شکل گیری UML 9
دیاگرام های UML 9
آنالیز شی گراء (OOA) 10
طراحی شی گراء ( OOD ) 11
دیاگرام های کلاس UML 11
خصایص کلاس (Properties , Attributes) 12
علایم + و - 12
متدهای کلاس ( عملیات ) 13
متدهای کلاس و آرگومان ها 13
خــلاصه 15
فصل دوم:عناصر UML 17
ويژگيهاي UML 18
شرح نمودارهاي UML : 20
نمودار كلاس (Class Diagram): 20
نمودار اشياء (Object Diagram): 21
نمودار موردكاربرد (Usercase Diagram): 21
نمودارهاي تعامل (Interaction Diagram): 21
نمودارحالت (Statechart Diagram): 21
نمودار فعاليت (Activity Diagram): 22
نمودار اجزاء(Component Diagram): 22
نمودار به كارگماري(Deployment Diagram): 22
روند حركت به سمت UML در جهان: 22
فصل سوم:شناخت استانداردهاي ساخت و مستند‌‌سازي 24
فصل چهارم: اصول و تحولات استانداردهاي مهندسي نرم‌‌افزار 28
فصل پنجم: تحلیل و طراحی با استفاده از استاندارد MIL-STD-498 34
ويژگي‌‌هاي استاندارد MIL-STD-498 35
تجديد نظر در روشهاي بازرسي ( Audit ) رسمي 37
كاهش تأكيد روي مستندسازي دستي و افزايش سازگاري با ابزارهاي CASE 37
بهبود اتصالات با مهندسي سيستم 38
استفاده از شاخصهاي مديريت و ارزيابي نرم‌‌افزار 38
بهبود پوشش تغييرات ، استفاده مجدد و مهندسي مجدد (Reengineering ) 39
سازگاري با شي‌‌گرايي و ديگر روش‌‌ها 39
ساختار استاندارد MIL-STD-498 40
رئوس كلي بخش Detailed Requirements 42
فعاليت Project Planning and Oversight 44
فعاليت Establishing a Development Environment 44
فعاليت System Requirements Analysis 44
فعاليت System Design 45
فعاليت Software Requirements Analysis 45
فعاليت Software Design 46
فعاليت Software Implementation and Unit Testing 46
فعاليت Unit Integration and Testing 47
فعاليت CSCI Qualification Testing 47
فعاليت System Qualification Testing 48
فعاليت Preparing For Software Use 49
فعاليت Preparing for Software Transition 49
فعاليت Corrective Action 51
Other Activities 52
معرفي توصيف طراحي سيستم/ زير سيستم (SSDD-DID) 52
فصل ششم: DID چیست 65
فصل هفتم: معرفي استاندارد ISO/IEC 12207 77
معرفي استاندارد IEEE/EIA 12207 88
ساختار استانداردIEEE/EIA 12207 90
فصل هشتم: معرفي زبان استاندارد UML 95
تاريخچه 96
دياگرام هاي UML 97
-دياگرام Use Case 98
روابط مابين كلاسها و اشياء 102
دياگرام تعامل 103
دياگرام بسته (Package Diagram) 105
دياگرام حالت (State Diagram) 106
دياگرام فعاليت 107
دياگرام آرايش قوا (Deployment Diagram) 108
فصل نهم: آشنايي با CASE ابزارهاي توليد نرم‌‌افزار 110
تقسیم بندی سیستمهای CASE: 112
ويژگيهاي Power Designer 131
فصل دهم: قالبهای عمومی مستندات 136
ضوابط قالب عمومي "توصيف" 137
ضوابط توصيف طراحي واسط نرم ‏افزار 145
ضوابط توصيف طراحي بانك‏هاي اطلاعاتي 146
بخش چهارم گزارشات سيستم 153
ضوابط تدوين گزارش طراحي معماري سيستم 159
هدف 159
بخش پنجم گزارشات نرم ‏افزار 163
ضوابط تدوين گزارش تحليل نيازها و خواسته‏ هاي نرم ‏افزار 164
تجزیه و تحلیل و طراحی شی ء گرا با UML 169
طراحی بر مبنای جزء 171
طراحی سرویس گرا 172
طراحی بر مبنای واسط 173
زبان مدل سازی یکپارچه **UML 175
خلاصه 179
مروری بر اصطلاحات 181
Encapsulation (نهان سازي) 185
Inheritance (وراثت) 188
Polymorphism(چند ريختي) 191
مدلسازي بصري (Visual Modeling) چيست؟ 193
Booch, OMT, and UML 195
نمودارهاي UML 195
نمودارهاي Use Case 196
نمودارهاي CLASS (كلاس) 197
نمودارهاي حالت (State Transition Diagrams) 200
مدلسازي بصري و پردازش توليد و توسعه نرم‌افزار 203
شناخت Inception 206
Iteration One Use Cases 1.5.6 207
مهارت Elaboration 208
ساختار Construction 209
انتقال Transition 211
Rational Rose چيست؟ 212
پرداختن به Rational Rose 216
بخش‌هاي صفحه نمايش 217
چهار نماي موجود در يك مدل Rose 217
نماي منطقي 218
نماي Component 219
نماي Deployment 219
كار با برنامه Rational Rose 220
ايجاد مدل‌ها 220
واردكردن و ارسال مدل‌ها 221
انتشار مدل‌ها بر روي وب 222
كار با واحدهاي كنترل شده 223
نماي Use case 224
نمودارهاي Rational rose 225
كار با Use case 227
مستند سازي جريان رخدادها (Flow of Event) 231
تعريف (descripition) 232
پيش شرايط (Precondition) 233
Post Conditions (شرايط پسين) 236
كار كردن با عامل ها (Actor) 237
ساخت يك عامل Abstract 239
چگونگي كار با رابطه ها 240
نمودارهاي Interaction 241
يك Object چيست؟ 243
يك كلاس چيست؟ 245
يافتن آبجكت ها 245
استفاده از نمودارهاي Interaction 247
نمودارهاي Sequence 248
نمودارهاي Collaboration 250
نماي Logical(منطقي) يك مدلRose 252
نمودارهاي class 253
استفاده از صفات 254
يافتن صفات 254
تنظيم Visibility صفت 258
يافتن عمليتها 261
نمودارهاي تغيير حالت(State Transition) 263
فعاليت(Activity) 264
Action ورودي (Entry Action) 265
Action خروج (Exit Action) 266
رخداد(Event) 266
Action 267
حالت آغازين(Start State) 268
حالت پاياني 268
استفاده از حالات تو در تو (Nested State) 269
اهداف و موضوعات مورد بحث 272
نكات قابل توجه براي يادگيري 272
1-1- سيستمها در محيط اطراف ما 272
1-1-1- سيستم 272
1-1-2- سيستمهاى پيچيده‏تر و متشكل از زير سيستمها 273
1-1-3- اهميت سيستم 275
1-1- 4- مسئله پيچيدگى و نياز به سيستم 277
1-1-5- تجزيه و تحليل سيستم، تحليلگر سيستم 277
1-2- انواع سيستمها، سيستمهاي سازماني-انساني 277
1-2-1- تنوع سيستمها 277
1-2-2- طبقه بندى سيستمها 279
1-2-3- واكنش انسانها در پذيرش تغييرات در سيستمها 280
1-3- سير تحول و پيدايش علم تجزيه و تحليل سيستم 281
1-3-1- نظريه مديريت علمي 282
1-3-2- نظريه عمومي سيستمها 283
1-3-3- مهندسي سيستم و علم تجزيه و تحليل و طراحى سيستمها 285
1-4- نگاهي كلي به فراروند تجزيه و تحليل و طراحي سيستم 288
1-5- ديدگاهها از علم تجزيه و تحليل سيستم 290
1-6- رهيافتي بودن تجزيه و تحليل و طراحي سيستمها 292
1-7- اهداف عمومي تجزيه و تحليل سيستم 294
1-8- تفكر سيستمي 300
منابع 305


زبان مدل سازي يكپارچه (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 يك زبان مدلسازي را مشخص مي كند كه اتفاق نظر جماعت شيگرا بر مفاهيم اساس مدل سازي است .
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 معتقدند كه مجموعه اي از تكنيك هاي موفقيت آميز و عملي را كه در يك ديدگاه مستحكم و پا بر جا جفت مي شود ، تعريف كرده اند.


زبان برنامه نويسي
UML يك زبان بصري است و هدفش يك زبان برنامه نويسي بصري نيست ، در عين آنكه همه مفاهيم و تجسمات را پشتيباني مي كند تا جايگزين زبان هاي برنامه نويسي شود. UML زباني است براي بصري سازي ، مشخص سازي ، ساخت و مستند سازي دست آوردهاي يك سيستم نرم افزاري ، و از طرفي مسيري را فراهم مي كند كه شما را به سمت كد هدايت مي نمايد. برخي چيزها شبيه انشعاب ها و ادغام هاي پيچيده در يك زبان برنامه نويسي متني بهتر بيان مي شوند. UML نقشه اي قوي براي خانواده اي از زبان هاي دارد. در عين حال شما مي توانيد از بهترين هاي هر دو دنيا استفاده كنيد.

ابزار
استاندارد سازي يك زبان ضرورتا اساس ابزارها و فرآيندها هستند كه UML ، مفاهيم و علائم آن را تعريف مي كند و نه خود ابزار را . بنابراين UML ابزار نيست.

فرآيند
بسياري از سازما ن ها ، UML را به عنوان زبان متداول براي توليد دست آوردهاي پرروژه هايشان استفاده مي كنند، اما انواع نمودارهاي UML را در فرآيندهاي مختلف استفاده مي كنند. UML اساسا مستقل از فرآيند است ولي فرآيند استانداردي را نيز تعريف ميكند كه هدف UML نيست. فرآيندها بر اساس طبيعت شان بايستي براي سازمان ها ، فرهنگ ها و حوزه هاي مسئله دوخته شوند.

مقايسه UML با د يگر زبان هاي مدل سازي
UML بر اساس موفقيت هاي سه روش مدل سازي OOSE , OMT , BOOCH و ايجاد شده است و كاربران هر يك از اين سه روش ،‌ مي توانند به راحتي از UML استفاده نمايندت. UML براي استفاده شدن توسط كاربران روش هاي ديگر نيز آماده و آسان مي باشد.
UML هم اكنون روشن تر ، مستحكم تر و يك شكل تر از Booch,OMT.,OOSE و ديگر روش ها مي باشد . اين بدين معنا است كه در انتقال به UML اين ارزش وجود دارد كه به شما اجازه مي دهد تا در پروژه ها چيزهايي را مدل سازي كنيد كه قبل از اين انجام شدني نبودند.
كاربران روش هاي موجود، تغييرات اساسي و زيادي را در علامت گذاري تجربه خواهند كرد. اما اين به معناي نياز به يادگيري مجدد با تعريف مجدد مفاهيم حاضر نيست. كاربران هر يك از روش هاي OO مي توانند سرعت زيادي را در يادگيري شان انتظار داشته باشند. تكنيك هاي پيشرفته نظير به كارگيري كليشه ها و خواص ، نيازمند مطالعه هستند. البته اين موارد نيز در زمان برخورد با مسئله ، مورد نياز مي شوند.
ويژگي هاي جديد UML
هدف كليه تلاش هاي يكپارچه سازي كه در UML به كار مي رود ، حفظ سادگي است به گونه اي كه عناصر غير كاربردي روش هاي OMT, Booch,OOSE طرد شوند و عناصر مؤثر از روش هاي ديگر به آن اضافه گردند.
مفاهيم جديد زيادي در UML وارد شده اند ، نظير : مكانيزم هاي توسعه شامل كليشه ها ، مقادير ضميمه و محدوديت ها ، توزيع و همروندي (‌به عنوان مثال برا ي مدل سازي CORBA,Active/DCOM الگوها / همكاري ها ، نمودارهاي فعاليت (‌براي مدل سازي فرآيند كار ) ، پالايش (‌براي اجرا يا به كارگيري ارتباطات بين سطوح مجرد ) واسطه ها و اجزاء ، و يك زبان محدوديت .
بسياري از اين مفاهيم در نظريه ها و روش هاي انفرادي مختلف وجود داشتند و UML آنها را به دورن انسجام خودش كشاند . به علاوه اين تغييرات اساسي ، بهبودهاي ريز ديگري نيز بر اساس مفاهيم و علائم ،OOSE ,Booch.OMT وجود دارد. بنابراين بسياري از مفاهيم و علائم UML را خود نويسندگان آن ايجاد نكرده اند بلكه نقش آنها ، جمع آوري مناسب ، انتخاب و يكپارچه كردن اين مفاهيم و علائم در UML بو ه است . در اين زمينه ، موارد زير قابل ذكر است :
• نمودارهاي مورد كاربرد مشابه آنچه در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 محصولي از يك تاريخ عظيم انديشه ها در علم كامپيوتر و ناحيه مهندسي نرم افزار است.

UML ، گذشته ، حال و آينده
UML به وسيله شركت نرم افزاري (Ration So ftware ) و شركايش ايجاد شد . UML جانيشين هاي زبان هاي مدل سازي اي است كه در ،‌ Booch Reumbugh // OOSE Jacoboson و روش هاي ديگر يافت مي شوند. بسياري از شركت ها در حال جاي دادن UML در خود به عنوان يك استاندارد در فرآيند توسعه و محصلوات شان هستند ، كه نظام هايي نظير : مدل سازي كار ؤ مديريت نيازمندي ها ؤ تحليل و طراحي ؤ برنامه نويسي و تست را مي پوشاند.

UML0.8-0.91
زمينه 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 به تصويب رسيد.

UML حال و آينده
UML غير خصوصي است و براي همه باز است . UML نيازهاي كاربران و اجتماعات علمي را نشانه مي رود. بسياري از متدولوژيست ها ، سازمان ها و توليد كنندگان ابزار ، خود را در استفاده از آن متعهدا كرده اند. از آنجا كه UML مفاهيم و علائم مشابهي از Booch,OMT,OOSE و ديگر روش هاي مهم را ارائه مي كند و با وارد كردن شركاي UML و باز خور عمومي به خود ، شخصيت قانوني ارائه كرده است ، انتخاب وسيع UML بايستي كار درستي باشد.
دو جنبه يكپارچگي كه زبان مدل سازي يكپارچه (UML ) به دست آورده است عبارتند:
1) UML به صورت مؤثري به بسياري از اختلاف ها پايان مي دهد كه غالبا هم در زبان هاي مدل سازي روش هاي قبلي ظهور كرده بود.
2) UML ، ديدگاه ها را در انواع مختلف سيستم ها ( كسب و كار در مقابل نرم افزار ) ، مراحل توسعه (تحليل نيازمندي ها ، طراحي و پياده سازي )، و مفاهيم دروني ، يكپارچه مي كند.
3) استاندارد سازي UML
بسياري از سازمان ها ، UML را به عنوان استاندارد سازماني شان تاييد كرده اند ، به دليل آنكه UML از زبان هاي مدل سازي كه توسط روش هاي مهم OO ارائه شده اند منبعث شده است . UML براي استفاده روزمره و همگاني بسيار مطلوب است.


==================================================
طراحی وب سایت
پروژه های برنامه نویسی تجاری
دانلود پروژه های ASP.NET وب سایتهای آماده به همراه توضیحات
دانلود پروژه های سی شارپ و پایگاه داده SQL Server همراه توضیحات و مستندات
دانلود پروژه های UML نمودار Usecase نمودار class نمودرا activity نمودار state chart نمودار DFD و . . .
دانلود پروژه های حرفه ای پایگاه داده SQL Server به همراه مستندات و توضیحات
پروژه های حرفه ای پایگاه داده Microsoft access به همراه مستندات و توضیحات
دانلود پروژه های کارآفرینی
دانلود گزارشهای کارآموزی کارورزی تمامی رشته های دانشگاهی
قالب تمپلیت های آماده وب سایت ASP.NET به همراه Master page و دیتابیس
برنامه های ایجاد گالری عکس آنلاین با ASP.NET و JQuery و اسلایدشو به همراه کد و دیتابیس SQL کاملا Open Source واکنشگرا و ساده به همراه پایگاه داده
==================================================
یافتن تمامی ارسال‌های این کاربر
نقل قول این ارسال در یک پاسخ
06-15-2016, 01:08 AM
ارسال: #2
RE: آشنایی با UML
صنعتي سازي
بسياري از سازمان ها و تامين كنندگان جهان ، UML را پذيرفته اند. تعدادي از سازمان هاي تاييد كننده UML انتظار مي رود تا در آينده رشد قابل توجهي بنمايند. اين سازمان ها ، استفاده از UML را به وسيله ايجاد اسناد قابل دسترس و ساده تشويق مي كنند. همچنين با تشويق متدولوژيست ها ، تامين كنندگان ابزار ، سازما ن هاي آموزشي و نويسندگان به انتخاب UML در كارهايشان ، مسير صنعتي سازي آن را هموارتر مي نمايند.

تكامل UML آينده

اگر چه UML يك زبان دقيق را تعريف مي كند اما سدي براي بهبودهاي آينده در مفاهيم مدل سازي نيست . بسياري از تكنيك هاي رهبري را در نظر گرفته شده است اما انتظار مي رود تا تكنيك هاي اضافه تري ، نسخه هاي آينده UML را ايجاد كنند. بسياري از تكنيك هاي پيشرفته مي توانند با استفاده از UML به عنوان پايه ، تعريف گردند. UML مي تواند بدون تعريف دوباره هسته خودش ، بسط داده شود. UML در شكل موجودش ، انتظار مي رود تا پايه اي براي بسياري از ابزارها باشد، ابزارهايي براي : مدل سازي تجسمي ، شبيه سازي و محيط هاي توسعه . همان گونه كه يكپارچه سازي ابزارها توسعه داده مي شوند ، استانداردهاي پياده سازي مبتني بر 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 – ريسك شناسي : آيا نيروهاي اثر گذار بيروني وجود دارند ؟ يعني چقدر احتمال دارد كه از نظر سياسي ، پروژه تحت تاثير نيروهاي بيروني قرار گيرد؟


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

مدل هاي مختلفي را مي توان ترسيم نمود :
1) مدل هاي حوزه مسئله و موارد كاربرد : اين مدل ها ، نيازمندي هاي وظيفه هاي سيستم را نشان مي دهند. با ترسيم اين مدل ها نيازمندي هاي كاربر شناسايي مي گردد.
2) مدل هاي تحليلي : كاربرد خاص و تفصيل هر يك از نيازمندي هاي كاربر توسط مدل هاي تحليلي نشان داده مي شود. اين مدل ها هر مورد كاربرد را به صورت مفصل تر نشان مي دهند.
3) مدل هاي طراحي : كه ساختار ايستاي سيستم را به صورت زير سيستم ، كلاس ها و واسط ها براي پياده شدن بر اساس زير ساخت هاي كاري نشان مي دهند.
مدل هاي حوزه مسئله حتما قبل از مورد كاربرد ساخته مي شود تا با فرهنگ حوزه مسئله آشنا شويم.
دو روش بر اساس UML مي تواند براي ايجاد مدل هاي حوزه مسئله پيشنهاد شود:

1) نمودارهاي كلاسي كه از چشم انداز مفهومي ترسيم شده اند و بيشتر واژه ها و مفاهيم خبره هاي حوزه مسئله و نحوه ارتباط مفاهيم با يكديگر را نشان مي دهند. توجه شود كه در الگوي حوزه مسئله بيشتر ، ساختا ر و فرهنگ لغات مسئله مورد توجه است در حالي كه در مورد كاربرد ، بيشتر رفتار و فعاليت هاي حوزه مسئله مورد توجه قرار مي گيرد.
2) نمودارهاي فعاليت كه به عنوان تكميل كننده نمودارهاي كلاس ، توصيف كننده جريان كار سيستم هستند.
3) نكته مهم نمودارهاي فعاليت اينست كه فرآيندهاي موازي سيستم در آن كشف مي شوند و توالي غير ضروري فرآيندها مشخص مي گردند. برخي افراد به جاي نمودار فعاليت ، نمودار تعالم را مي پسندند.
4) بعد از الگوي حوزه مسئله ، نوبت به موارد كاربرد مي رسد. همانطور كه قبلا نيز اشاره شد در مورد كابرد نيازمندي هاي سيستم شناسايي مي گردند سپس همه نمودارها را در قالب يك نمودار حوزه مسئله مي آوريم و با يك يا دو نفر از متخصصين خود حوزه مسئله تبا دل نظر مي كنيم حال يك الگوي حوزه مسئله كه همه نيازمندي ها را نشان مي دهد در دست داريم. سپس به ساخت كلاس ها و ورود به مرحله ساخت مي پردا زيم. حداقل گروه ايجاد كننده مدل حوزه مسئله يك يا دو توسعه دهنده و يك يا دو خبره مسئله و حداكثر 4 نفر براي اين كار مناسبند. ايجاد نمونه اوليه نيز وسيله مناسبي در محقق سازي بهتر اين مرحله است . البته همه اين نكات صرفا يك توصيه است.
ريسك فني

در بررسي فني براي ايجاد نرم افزار ، لازم است تا تبعات به كار گيري تكنولوژي بررسي شود. به عنوان مثال از چه كامپايلري استفاده شود؟ (C++,Delphi,….. ) ؤ موتور پايگاه داده چيست ؟ (Oracle, SQL,…. ) . همچنين اثر متقابل اين انتخاب ها بر يكديگر مهم است. در اين بررسي لازم است تبعات سخت افزاري اين انتخاب بر يكدگير مهم است در اين بررسي لازم است تبعات سخت افزاري اين انتخاب نيز بررسي شود. به هر حال تصميمات طراحي معماري مهم است . در اين ميان تمركز بر نواحي اي كه در آينده به سختي قابل تغيير باشند مهمتر است . براي كشف اين نقاط نيز موارد كاربرد مناسب هستند. همچنين نمودارهاي كلاس و تعامل براي نمايش اينكه اجزاء چگونه با هم مرتبط مي شوند مفيد هستند. نمودارهاي بسته نيز مي توانند تصوير سطح بالايي از اجزا را نشان دهند. همچنين نمودارهاي استقرار مي توانند منظر گاهي را از اينكه چگونه قسمت هاي مختلف سيستم توزيع شده اند به دست دهند. براي كسب اطلاعات بيشتر به فصل هاي مربوطه مراجعه كنيد.
ريسك مهارت
براي كسب مهارت در مبحث شي گرا ، بهترين راه استفاده از مربي است كه در طول پروژه در كنار شما قرار گيرد اگر چنين حالتي امكان نداشته باشد استفاده از مربيان تمام وقت يا پاره وقت نيز براي بازنگري پروژه مفيد است. اگر اين حالت نيز امكان نداشت، هر ماه يا هر دو ماه با دعوت از يك مربي خبره مدل هاي خود را بازنگري كنيد. توصيه مي شود هر ماه يك كتاب تكنيكي بخوانيد حتي بهتر است كه به صورت گروهي مطالعه كنيد و به تبادل نظر بپردازيد .
الگوها نيز ابزا رهاي مناسبي براي آموزش و اعتبار سنجي مدل هاست. بنابراين لازم است از آخرين وضعيت الگوها باطلاع باشيد.
معماري خط پايه

نتايج و خروجي مرحله تفصيل ، معماري خط پايه است اين معماري شامل موارد زيرمي
گردد.
• فهرست موارد كاربرد كه نيازمندي هاي سيستم را بيان مي كند
• مدل حوزه مسئله كه درك شما را از سيستم نشان مي دهد و نقطه شروع كلاس هاي اساسي حوزه مسئله است.
• ساختار تكنولوژي انتخاب شده كه تكنولوژي پياده سازي و جفت و جور شدن عناصر آنها را توصيف مي كند.
اين معماري ، پايه اي براي توسعه است . اصطلاحا به اين معماري ، طرح اوليه مراحل بعد گفته ميشود.
چه زماني مرحله تفصيل پايان مي يابد؟
دو رخداد مهم براي نمايش دادن پايان مرحله تفصيل عبارتند از :
1) تقريبا با اطمينان بتوان براي آينده پروژه تخمين زد.
2) شناسايي همه ريسك ها و آمادگي براي حل هر كدام از آنها انجام شده باشد.
برنامه ريزي

اساس برنامه ريزي تعيين تكرارهاي ساخت و تخصيص مورد كاربرد به هر تكرار است. براي اين منظور قدم هاي زير پيشنهاد مي شود:
قدم اول : طبقه بندي موارد كاربرد : كاربر بايستي سطح اولويت هر يك از موارد كاربرد را مشخص كند. معمول مي توان اين كار را در سه سطح بالا ، متوسط و پايين انجام داد
قدم دوم : در نظر گرفتن ريسك معماري براي هر مورد كاربرد : توسعه دهنده ، اين ريسك را در سه سطح مشخص مي كند . اين ريسك عبارت است از ريسكي كه اگر اين مورد كاربرد در پروژه براي مدتي به تعويق افتد ، تكميل كارهايي كه تاكنون انجام شده اند ، چقدر باعث دوباره كاري مي گردد؟
قدم سوم : در نظر گرفتن ريسك برنامه ريزي براي هر مورد كاربرد : كه عبارت از ميزان اطمينان توسعه دهنده نسبت به تخمين كار مورد نياز براي هر مورد كاربرد است.
طول زماني كه هر مورد كاربرد بر حسب نفر ـ‌ هفته را با فرض انجام تحليل ، طراحي ، كدنويسي ، تست ، مجتمع سازي و مستند سازي به دست آوريد. نكته قابل توجه اينست كه تخمين زدن را بايد كارشناس توسعه انجام دهد نه مدير. اگر برخي از موارد كاربرد داراي ريسك بالا بودند نياز به مرحله تفصيل دوباره ، براي اين موارد كاربرد پيش مي آيد.
قدم چهارم : تعيين طول تكرار براي كل پروژه : لازم است يك طول ثابت زماني براي كليه تكرارها در كل پروژه مشخص گردد. اين طول زماني بايستي باندازه كافي بزرگ باشد تا بتوانيد چند مورد كاربرد را در هر تكرار انجام دهيد. به عنوان مثال براي زبان Smalltalk ميتوانيد دو تا سه هفته و براي c++ شش هفته يا بيشتر باشد. در محاسبات لازم است اين گونه در نظر بگيريد كه از 50 % توان يك كارشناس توسعه استفاده مي شود ، سپس طول تكرار را در نصف تعداد توسعه دهنده ها ضرب كنيد ، نتيجه به دست آمده ، مقدار كار توسعه را براي هر تكرار مشخص مي كند. براي نمونه با 8 توسعه و طول تكرار 3 هفته اي
در هر تكرار (12 = 8 * 3 * 1.2 ) نفر – هفته در هر تكرار داريم.
جمع كل زمان موارد كاربرد را بر مقدار مورد نياز در هر تكرار (عدد به دست آمده در مرحله قبل ) تقسيم كنيد و با عدد يك جمع كنيد ، عدد به دست آمده اولين تخمين شما از تعداد تكرارا مورد نياز در پروژهتان است. عدد يك براي اطمينان بيشتر به مقدار فوق افزوده مي شود.
قدم پنجم : تخصيص موارد كاربرد به تكرارها: بر اساس اولويت هايي كه قبلا توضيح داده شد، در هر تكرار ، تعدادي مورد كاربرد قرار دهيد. ابتدا موارد كاربرد با اولويت بالاتر را به تكرارها تخصيص دهيد. براي پيش بيني مقدار زمان مورد نياز در مرحله انتقال معمولا 10 % تا 35 % از مرحله ساخت را به عنوان تخمين مرحله انتقال قرار مي دهند . همچنين 10% تا 20 % از مرحله ساخت را براي پيشامدهاي اتفاقي قرار ميدهند.
برنامه اي كه به روش فوق به دست مي آيد و با تبادل نظر كاربر و كارشناس توسعه ايجاد مي شود به برنامه توصيه اي معروف است .
بنابراين ، موارد كاربرد پايه هاي برنامه ريزي هستند كه UML نيز بر آنها تاكيد زيادي دارد.
مرحله ساخت
در مرحله ساخت ، سيستم در طي يك سري تكرار ايجاد مي شود در هر تكرار نيز تأييد كاربر اخذ مي شود . هدف از اين فرايند كاهش ريسك است .


معمولا تست ها را نيز به دو دسته تقسيم مي كنند.

1) تست واحد : كه به وسيله كارشناس توسعه انجام مي شود .
2) تست سيستم : كه به وسيله گروه تست بيروني انجام مي شود اين گروه بايد به ديديك جعبه سياه به برنامه اصلي نگاه كند .
دسته بندي مجدد
وقتي تابعي را به برنامه اي اضافه مي كنيد چون از قبل براي حضور آن پيش بيني نكرده ايد برنامه ازكيفيت خوبي برخوردار نخواهد شد .براي جلوگيري از خراب شدن كيفيت برنامه دو راه وجود دارد :
1) طراحي دوباره برنامه و كدنويسي كامل براي طراحي جديد
2) اضافه كردن به برنامه موجود و اصلاح و تطبيق آن با برنامه
قدم هاي دسته بندي مجدد

تغييرات دسته بندي مجدد معمولا قدم هاي كوچكي دارد : تغيير نام يك متد ، انتقال يك صفت از كلاسي به كلاس ديگر ، تفكيك كردن متدهاي مشابه از كلاس ها و قرار دادن در يك فوق كلاس و…

نكاتي در مورد دسته بندي مجدد

1) دسته بندي مجدد واضافه كردن به كد را هم زما ن ا نجام ندهيد .
2) قبل از دسته بندي مجدد از تست برنامه مطمئن شويد .
3) ابتدا خوب فكر كنيد و صفات مناسب را جابجا كنيد و موارد مشابه را در فوق كلاس ها قراردهيد .
چه وقت دسته بندي مجدد كنيم ؟
1) وقتي براي اضافه كردن وظيفه اي ، به يك كد قديمي برمي خوريم كه مشكل اضافه كردن كد ايجاد مي شود .
2) وقتي فهميدن كد موجود ، سخت است .
همه تكنيك هاي UML در مرحله ساخت مفيد هستند . برخي از نمودارها كه استفاده فراوان تري دارند در زير توضيح داده مي شود .
1) از نمودار مورد كاربرد براي تعيين محدوده مورد نظرتان استفاده كنيد .
2) نمودار كلاس مفهومي براي درك مفاهيم درون مورد كاربرد مفيد است .
3) نمورار فعاليت را براي تشخيص جريان كار عناصر درون مورد كاربرد مفيد است .
قدم بعدي ،تحليل اين نمودارها و اصلاح آن با كمك و نظر كاربر است . در اين مرحله به نظر كاربر بسيار اهميت داده ميشود و برون نظر او تصميم گيري كردن كار نادرستي است.
براي ورود به طراحي ترسيم نمودار كلاس از چشم انداز تشخيصي براي آنكه كلاس را با جزئيات بيشتر ببينيم مفيد است . نمودارهاي تعغامل براي نمايش اينكه چگونه كلاس ها با هم تعامل ميكنند تا مورد كاربرد را پياده كنند ارزشمند هستند
براي ترسيم نقشه اي منطقي از سيستم از نمودارهاي بسته استفاده كنيد . اين نمودار نقشه منطقي سيستم ووابستگي بين آنها را به خوبي نشان ميدهد .



الگو ها

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

مرحله انتقال

پس از همة تكرارها هنوز يك قدم باقي مانده است و آن مرحله انتقال است . بنابراين پس از همه تكرارها گروه توسعه دهنده به پايان كد نويسي مي رسند . و آماده اند تا محصول را به كاربر تحويل دهند .
بهينه سازي ، كارايي را بهبود مي بخشد . بهينه سازي براي آن است كه سرعت سيستم را در جهت رفع نيازمندي هاي كاربر ، به اندازه كافي بالا ببرد . در طول مرحله انتقال ، اضافه كردن وظيفه اي به سيستم وجود ندارد بلكه حداكثر براي رفع اشكال سيستم اين مورد مي تواند بروز كند . مثال خوبي از مرحله انتقال فاصله زماني مابين محصول بتا و محصول نهايي است . در زمينه فرآيند مراجع (Booch-94 ) و (Jacobson –99 ) مناسب هستند .
مرور

در ايجاد يك مدل شيء گرا مي توان مدل را براساس سه ديدگاه يا چشم انداز ترسيم كرد كه عبارتند از : مفهومي ، تشخيصي و پياده سازي . بسته به آن كه ترسيم كننده مدل ، با چه ديدگاهي در حال ترسيم مدل است جزئيات درون مدل كمتر يا بيشتر مي باشند .
ديد عميق تر نسبت به سيستم و اينكه در هر مورد كاربردي چه اشيائي با هم در ارتباط هستند از طريق نموداركلاس فراهم مي آيد در ابتدا بهتر است كه نمودار كلاس را از ديدگاه يا چشم انداز مفهومي ترسيم كنيد دراين ديدگاه در حال ترسيم نموداري هستيد كه زبان كاربر را نمايش مي دهد .
همچنين براي آنكه جريان كاري سيستم كاربر را درك كنيد و بفهميد كه براي هر مورد كاربرد از چه فعاليت هايي و با چه ترتيبي استفاده مي گردد، نمودار فعاليت ابزار مناسبي است .
در پروژه هاي پيچيده و بزرگ تحليل گر يا مدير پروژه براي آنكه بتواند سيستم را خيلي سريع مرور كند و از پيشرفت امور با خبر شود و نيز براي آنكه كنترل مدل آسانتر و درك آن ساده تر شود نياز به ابزاري است تا اين پيچيدگي را مديريت كند . براي اين منظور نموداربسته ها وسيله اي مناسب است .
مجموعه اي از كلاسها كه با يكديگر ارتباط تنگاتنگ دارند را در يك بسته قرار مي دهيم و اين كار را تكرا ر مي كنيم در نهايت به عنوان مثال از يك نمودار كلاس كه داراي 100 كلاس مي باشد به يك نمودار بسته مي رسيم كه از 10 بسته تشكيل شده است اين مديريت پيچيدگي براي تمام عناصر درون مدل UML نظير : مورد كاربرد ، نمودارفعاليت نمودار حالت و … كاربرد دارد و تنها مختص كلاس نيست .
الگوها نيز ابزار مناسبي هستند تا بتوا نيد ايده هاي اساسي سيستم را بيان كنيد الگو كمك مي كند تا ارزيابي خوبي از طرح و مدل تان بيان كنيد . آنها براي توصيف طرح هايي كه پذيرفته نمي شوند نيز مفيد هستند .
UML يك زبان مدل سازي است وفارغ ازفرايند و متدولوژي است .UML هيچ توصيه اي
به روش به كارگيري خود نمي كند و به همين دليل است كه سه مبدأ آن را با عنوان زبان مدل سازي نام مي برند و نه روش يا فرايند .
اما از آنجا كه به هرحال ايجاد هر مدلي مبتني بر يك متدولوژي يا فرايند خواهد بود ، سه مبدع UMLكتابي نيز براي بيان فرايند با استفاده از UML به چاپ رسانده اند و در آن متذكر شده اند كه براي استفاده از UMLچه فرايند و روشي را به كار مي گيرند .


==================================================
طراحی وب سایت
پروژه های برنامه نویسی تجاری
دانلود پروژه های ASP.NET وب سایتهای آماده به همراه توضیحات
دانلود پروژه های سی شارپ و پایگاه داده SQL Server همراه توضیحات و مستندات
دانلود پروژه های UML نمودار Usecase نمودار class نمودرا activity نمودار state chart نمودار DFD و . . .
دانلود پروژه های حرفه ای پایگاه داده SQL Server به همراه مستندات و توضیحات
پروژه های حرفه ای پایگاه داده Microsoft access به همراه مستندات و توضیحات
دانلود پروژه های کارآفرینی
دانلود گزارشهای کارآموزی کارورزی تمامی رشته های دانشگاهی
قالب تمپلیت های آماده وب سایت ASP.NET به همراه Master page و دیتابیس
برنامه های ایجاد گالری عکس آنلاین با ASP.NET و JQuery و اسلایدشو به همراه کد و دیتابیس SQL کاملا Open Source واکنشگرا و ساده به همراه پایگاه داده
==================================================
یافتن تمامی ارسال‌های این کاربر
نقل قول این ارسال در یک پاسخ
ارسال پاسخ 


پرش به انجمن:


کاربرانِ درحال بازدید از این موضوع: 1 مهمان