مهندسی نرم افزار با استفاده ابزار UML و Case Tools

مهندسی نرم افزار با استفاده از UML و Case Tools

توسط admin | گروه مهندسی نرم افزار | 1399/04/23

نظرات 0

 فهرست مطالب 

فصل اول: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(Unified Modeling Languageمبتنی بر چنین رویکردی است . 
UML ،زبانی استاندارد بمنظور مشخص نمودن ، پیش بینی ، ایجاد و مستند سازی تولیدات نرم افزاری است . UML ، مجموعه ای از بهترین امکانات مهندسی را بمنظور استفاده در مدل سازی سیستم های بزرگ و پیچیده ارائه که کارآئی آنان به اثبات رسیده است . UML یک متدولوژی رسمی برای پیاده سازی نرم افزار است . 

روند شکل گیری UML 
برنامه نویسی شی گراء ( OOP ) ، از اوایل  سال 1960 مطرح  گردید . برنامه نویسی شی گراء با اینکه  بعنوان یک ایده جدید مطرح شده بود ولی بسرعت زبان های مدل سازی شی گراء برای پوشش ایده فوق ، مطرح و پیاده سازی گردیدند. در فاصله سال های 1970 تا اواخر 1980 چندین زبان مدل سازی شی گراء پیاده سازی گردید . تعداد زبان ها ی مدل سازی شی گراء در سال 1995 به بیش از پنجاه نمونه رسیده بود . 
از افراد فعال و پیشرو در این زمینه می توان به  Jim Rumbaugh ( شرکت جنرال الکتریک )، Grady Booch  ( شرکت Rational software  )  و  Ivar Jacobson  ( شرکت  Objectory )  اشاره نمود. هر یک از افراد فوق ، تلاش گسترده ای  را در جهت مدل سازی زبان برنامه نویسی انجام داده بودند . در سال 1994 ، Rumbaugh شرکت جنرال الکتریک را ترک و به Booch در شرکت Rational Software ملحق گردید. یک سال بعد ، شرکت Rational Software ، شرکت Objectory را خریداری و افراد یاد شده همکاری  خود را با یکدیگر و در یک شرکت مشترک آغاز نمودند. ماحصل همکاری فوق ، ارائه  اولین نسخه UML 0.9 توسط شرکت Rational software  در سال 1996 بود. 
در سالیان بعد ، OMG)Object Management Group) ،  تلاش های گسترده ای را بمنظور ارتقاء و  بهسازی UML آغاز نمود. در اواسط سال 2001 ، اعضاء OMG ، کار خود را بمنظور ارتقاء به UML 2.0 آغاز نمودند. در حا ل حاضر ، UML شامل مدل سازی ویژوال ، شبیه سازی و امکانات پیاده سازی است . تعداد زیادی از ابزارهای UML طراحی و در اختیار علاقه مندان قرار گرفتند .  Rational Rose 2002  از شرکت Rational Software  ، نرم افزار Describe Enterprise از شرکت Embarcadero Technologies و Visio 2002  از شرکت مایکروسافت . نمونه هائی از ابزارهای UML می باشند . 

دیاگرام های UML 
UML یک ابزار ویژوال بوده و از انواع متفاوتی دیاگرام استفاده می نماید . هر یک از دیاگرام های  UML ، امکان مشاهده یک سیستم نرم افزاری را از دیدگاههای متفاوت و با توجه به درجات متفاوت Abstraction در اختیار پیاده کنندگان قرار می دهد. برخی از دیاگرام های UML عبارتند از : 
Class Diagram 
State Diagram 
Sequence Diagram 
Collaboration Diagram 
Activity Diagram 
Component Diagram 
Deployment Diagram
  
آنالیز شی گراء  (OOA) 
آنالیز شی گراء  و یا OOA ، یک متدولوژی قدرتمند برای تجزیه و تحلیل  فرآیند پیاده سازی نرم افزار است . در زمان استفاده
از OOA ،  هر چیز در فرآیند پیاده سازی نرم افزار بمنزله کلاس در نظر گرفته خواهد شد ( این طرز تفکر می بایست محور آنالیز سیستم قرار گیرد ) . مثلا" در یک بیمارستان هر یک از عناصر موجود نظیر : دکتر ، پرستار ، بیمار و ملاقات کننده ، بمنزله یک کلاس در نظر گرفته می شوند . هر نسخه جدیدی که از یک کلاس ایجاد می گردد ، بمنزله یک نمونه ( Instance ) از کلاس در نظر گرفته خواهد شد . محوریت فرآیند آنالیز شی گراء ، تاکید بر ایجاد کلاس های مورد نیاز سیستم است .
مهمترین و اصلی ترین رویکرد OOA ،یافتن پاسخ مناسب برای سوالاتی است که با What شروع و در  فرآیند پیاده سازی نرم افزار حضوری موثر دارند . نمونه سوالات OOA در این زمینه عبارتند از : " چه کلاس هائی در برنامه وجود دارد؟"  . " چه چیزی را برنامه انجام خواهد داد ؟"  " هر یک از کلاس ها در برنامه چه عملیاتی را بمنظور حل مسئله انجام خواهند داد ؟"  " مسئولیت هر کلاس در برنامه چیست ؟" در  OOA ، تاکید بر آنالیز اشیاء ، فعالیت ها و مسئولیت های سیستم نرم افزاری است . 

طراحی شی گراء ( OOD ) 
نکته اساسی  در طراحی شی گراء ، تاکید و سرو کار داشتن با سوالاتی است که با  How  شروع و در فرآیند پیاده سازی  نرم افزار حضوری فعال و موثر خواهند داشت . " چگونه این کلاس داده را جمع آوری می کند ؟" . " چگونه این کلاس گزارش را چاپ می نماید ؟"  ، نمونه سوالاتی در این زمینه می باشند .در نمونه مثال بیمارستان، وضعیت فوق  به خصلت ها ، صفات و متدهای یک کلاس  مرتبط می گردد . 
بنابراین OOA ، کلاس های مورد نظر و ضروری  بمنظور نیل به اهداف نرم افزار را مشخص می نماید و محور عملیات بر جستجو و تبین جایگاه یک کلاس در برنامه متمرکز است . در OOD ، تاکید بر پیاده سازی  کلاس ها ، صفات و خصایصی است   که بمنزله هسته یک کلاس مطرح می گردند . ترکیب  هر یک از فعالیت های فوق ( آنالیز شی گراء و طراحی شی گراء ) بهمراه پیاده سازی لینک هائی که با کلاس ها سروکار دارند جملگی بعنوان  بخشی از فرآیند OOP ( برنامه نویسی شی گراء ) محسوب می گردند.

دیاگرام های کلاس UML 
دیاگرام کلاس در UML یکی از مهمترین دیاگرام ها تلقی می گردد . دیاگرام فوق ، مسئولیت مدل سازی ساختار کلاس و محتویات را با استفاده از عناصری نظیر کلاس ها ، اشیاء و پکیج ها برعهده دارد . این دیاگرام همچنین ، ارتباطاتی نظیر : توارث و پیوستگی را نمایش خواهد داد. دیاگرام فوق ، شکل خلاصه و استانداردی بمنظور نمایش یک کلاس را ارائه می نماید. در این راستا از یک مستطیل که به سه بخش متفاوت تقسیم می گردد ، استفاده می شود.  در اولین بخش مستطیل ، نام کلاس قرار می گیرد . در دومین بخش مستطیل ، خصلت های یک کلاس قرار خواهند گرفت ( ممکن است از واژه صفات و یا متغیر نیز استفاده گردد ) و در بخش سوم ، متدهای یک کلاس قرار می گیرند.متدهای هر کلاس ، عملیاتی را که یک کلاس می تواند انجام دهد ، مشخص می نمایند.  شکل زیر ، یک دیاگرام کلاس نمونه  را نشان می دهد. در اولین بخش ، نام کلاس Vehicle مشخص شده است .نام هر کلاس با یک حرف بزرگ شروع و در مواردیکه نام کلاس شامل بیش از یک کلمه باشد ، هر کلمه در نام کلاس با یک حرف بزرگ آغاز می گردد . Vehicle ، PassengerCar و IncomeStatement نمونه هائی در این زمینه می باشند .استفاده از از فضای خالی بین کلمات  تشکیل دهنده نام یک کلاس ، مجاز نمی باشد . 



خصایص کلاس (Properties , Attributes) 
در دیاگرام کلاس Vehicle و در  بخش  دوم از شش خصلت Integer استفاده شده است  . در نمونه کلاس های دیگر ، یک کلاس ممکن است  دارای دهها خصلت باشد .در برخی زبانهای برنامه نویسی نظیر ویژوال بیسیک دات نت ،از خصلت  با نام  Prtoperty  نیز یاد می گردد. هر خصلت می تواند دارای مقادیر متفاوتی باشد . مقادیر جاری خصلت ها ، وضعیت یک کلاس را تشریح می نمایند .  در مقام مقایسه می توان خصایص یک شی را نظیر نقش اسامی در یک جمله در نظر گرفت ( مقایسه فوق صرفا" جنبه آموزشی دارد ) .

علایم +  و - 
همانگونه که مشاهده می گردد ، هر entry دربخش دوم  دیاگرام کلاس Vehicle ، دارای یک علامت -  در جلوی نام خود است .در بخش سوم ، برخی از Entry ها ، دارای  علامت +  و برخی دیگر دارای علامت - می باشند . وجود علامت + در ابتدای یک آیتم ( خصلت ، متد ) ، نشاندهنده در دسترس بودن آن از طریق خارج از کلاس است . بعبارت دیگر ، علامت +، امکان استفاده از آیتم مورد نظر و تاثیرگذاری بر وضعیت یک کلاس را نشان می دهد . علامت + ، عمومی بودن (Public) عناصر کلاس مربوطه را نشان می دهد. 
اگر یک Entry با یک علامت -  شروع گردد ، بدین معنی خواهد بود که آیتم مورد نظر صرفا" برای استفاده خود کلاس دردسترس بوده و امکان استفاده از آن برای خارج از کلاس میسر نخواهد بود. بنابراین علامت - ، نشاندهنده خصوصی ( Private ) بودن عناصر مربوط به یک کلاس است. 
استفاده از علائم + و - ، نشاندهنده نوع دستیابی به هر یک از عناصر مربوط به یک کلاس است . در حقیقت علامت + ، روشی بمنظور ارتباط با کلاس را مشخص نموده و علامت - نشاندهنده عناصری است که صرفا" برای خود کلاس قابل استفاده خواهند بود . 
ایجاد یک آیتم بصورت خصوصی  همواره مورد توجه طراحان شی گراء بوده و تامین کننده اهداف کپسوله سازی در برنامه نویسی شی گراء است . با کپسوله سازی داده ، امکان بروز تغییرغیرعمد داده در برخی بخش ها ی برنامه و  از طریق خارج از کلاس به حداقل مقدار خود خواهد رسید . بدین ترتیب،  تشخیص و برطرف نمودن خطاهای احتمالی ، بسرعت و بسادگی میسر خواهد شد .

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

متدهای کلاس و آرگومان ها 
در برخی موارد یک متد نیازمند اطلاعات خارجی بمنظور انجام وظایف محوله  است . مثلا" در دیاگرام کلاس Vehicle از متد زیر استفاده شده است  : 
+SetSpeed (DesiredSpeed:Integer):Integer
علامت + نشاندهنده این موضوع است که ( ) SetSpeed  یک متد Public است . بنابراین امکان استفاده از آن توسط یک برنامه نویس وجود خواهد داشت .بمنظور ارسال داده به متد مورد نظر از آرگومان استفاده شده که بین علامت پرانتز قرار می گیرند.در مثال فوق ، پارامتر مورد نظر DesiredSpeed بوده و از نوع Integer است . در انتهای علامت پرانتز بسته ، ازیک کالون ":" ،  که بدنبال آن کلمه Integer آمده است ، استفاده شده است . این بدان معنی است که متد  ( ) SetSpeed یک مقدار صحیح را به برنامه صدازننده  ، بر می گرداند. 
در نمونه کلاس Vehicle از دومتد بمنظور افزایش و یا کاهش سرعت استفاده شده است : 
-IncreaseSpeed(DesiredSpeed:Integer):Integer
-DecreaseSpeed(DesiredSpeed:Integer):Integer
هر یک از متدهای فوق ، عملیات مورد نظر در رابطه با افزایش و یا کاهش سرعت را انجام خواهند داد . برای نیل به خواسته فوق ( افزایش و یا کاهش سرعت )  می توان دو متد فوق را با یکدیگر تلفیق و در یک متد واحد دیگر جایگزین نمود:
-ChangeSpeed(DesiredSpeed:Integer):Integer
در صورتیکه پارامتر DesiredSpeed مثبت باشد ، سرعت افزایش و در غیر اینصورت ( پارامتر منفی باشد ) ، سرعت کاهش خواهد یافت. 
Dim MyVehicle as New Vehicle
Dim ObjectSpeed as integer
' Some code that does something...
ObjectSpeed = MyVehicle.GetSpeed()
ObjectSpeed = MyVehicle.ChangeSpeed(-ObjectSpeed)

درنمونه مثال فوق ، در ابتدا یک شی Vehicle با نام MyVehicle تعریف شده است . در ادامه ، متد   GetSpeed  در ارتباط با شی MyVehicle فرا خوانده شده است .بمنظور جداسازی نام شی از متد مربوطه از علامت نقطه استفاده شده است.
فرض کنید که Vehicle  با سرعت 55مایل در ساعت در حال حرکت است . مقدار ObjectSpeed ، پنجاه و پنج  در نظر گرفته می شود .در صورتیکه در ادامه مقداری منفی را به متد فوق پاس دهیم سرعت کاهش پیدا خواهد کرد.  اگر مقدار 55 -  را به متد  ChangeSpeed()  پاس دهیم ، توقف اتومبیل  را بدنبال خواهد داشت.
همانگونه که مشاهده می شود ،  برخی از متدها با علامت -  شروع شده اند .  این بدان معنی است که آنان متدهای اختصاصی ( Private) بوده  و خارج از کلاس قابل دستیابی نخواهند بود. چنین متدهائی به سایر متدها ی موجود در کلاس ، سرویس و خدمات لازم را ارائه و استفاده از آنان برای برنامه نویس مجاز نخواهد بود.بعبارت دیگر متدهای فوق بعنوان ایترفیس کلاس مطرح نبوده و از خدمات آنان در داخل کلاس استفاده خواهد شد . در چنین مواردی ممکن است یک متد که بصورت Public تعریف و امکان استفاده از آن در خارج از کلاس و توسط برنامه نویسان وجود دارد ، خود از خدمات چندین متد خصوصی استفاده نماید . 
یک دیاگرام کلاس UML ، امکان مرور سریع و فشرده پتانسیل ها ی یک کلاس را فراهم و نحوه ارتباط یک برنامه نویس با کلاس مورد نظر را نیز مشخص خواهد شد. اگر یک کلاس را بعنوان یک جعبه سیاه  در نظر بگیریم ، علامت "-" ،  نشاندهنده آیتم هائی درون جعبه سیاه است که امکان استفاده از آنان توسط برنامه نویسان وجود نخواهد داشت . علامت  "+" ،  نشاندهنده امکاناتی است که می توان از آنان بمنظور ارتباط با متدها و خصایص یک کلاس استفاده کرد . آیتم های Public یک کلاس ، اینترفیس لازم برای یک کلاس را تعریف و نحوه ارتباط با آن را مشخص می نمایند.  در حقیقت متدهای Public ، نحوه استفاده از یک کلاس را به برنامه نویسان دیکته خواهند کرد. 

خــلاصه 
 الگوریتم ،اعلامیه ای  سازماندهی شده  بمنظور حل یک مسئله خاص و یا سوالاتی است که می بایست پاسخ آنان مشخص گردد . یک الگوریتم مناسب  ، تمامی مراحل لازم بمنظور انجام فرآیندهای  مورد نیاز و حل یک مسئله را ارائه می نماید.
مقداردهی اولیه ، ورودی ، پردازش ، خروجی و پاکسازی ، پنج مرحله متفاوت برنامه نویسی می باشند. مراحل پنج گانه برنامه نویسی ، نگرشی  ماکرو از یک برنامه را ارائه می نمایند . مثلا" مرحله ورودی ممکن است نیازمند اخذ داده از صفحه کلید ، خواندن یک جدول تنظیمات از یک بانک اطلاعاتی و نهایتا" خواندن اطلاعات بیشتر از بانک اطلاعاتی دیگر باشد . بهسازی ( پالایش ) یکطرفه ، فرآیندی است که بر اساس آن یکی از مراحل  برنامه نویسی (نظیر مرحله ورودی )  بررسی و به آن جزئیات بیشتری اضافه اضافه خواهد شد . عملیات فوق  تا استخراج و مشخص شدن تمامی جزئیات لازم در رابطه با یک مرحله خاص ادامه خواهد یافت . عملیات بهسازی ( پالایش ) یکطرفه ، زمانی متوقف می گردد که کد واقعی  یک تابع نوشته گردد .محوریت فرآیند فوق ، تبدیل الگوریتم های ماکرو به میکرو است  : 
Input Step->ReadKeyboard( )
ReadSetupTable( ) ->ReadTable1( ) ->(Code)
ReadTable2( )
ReadTable3( )
UML ، از کلمات Unified Modeling Language  اقتباس شده است . مزیت استفاده از UML ، تفکر مبتنی بر برنامه نویسی شی گراء است .بلاک های اولیه ایجاد UML  کلاس ، خصلت و متد  نامیده می شوند. دیاگرام های کلاس UML تمام سه عنصر OOP را در یک دیاگرام مناسب  نمایش می دهند . 
 در OOP ، واژه های Private و Public به نحوه دستیابی به خصلت ها بر می گردد . اگرخصلتی از نوع Private باشد ،امکان تغییر آن صرفا" برای کسانی که به کلاس فوق تعلق دارند، وجود خواهد داشت .اگر خصلتی از نوع Public باشد ، سایر اشیاء امکان دستیابی کامل به خصلت را ( اعمال تغییرات مورد نظر ) خواهند داشت.

فصل دوم:عناصر UML

UML شامل تعدادي عنصر گرافيكي است كه از تركيب آنها نمودارهاي UML شكل مي گيرند . هدف استفاده از نمودارهاي مختلف در UML ، ارائه ديدگاه هاي گوناگون از سيستم است. همانطور كه مهندسين عمران جهت ساختن يك ساختمان پلانهاي مختلفي از ساختمان تهيه مي كنند ، ما با استفاده از نمودارهاي UML نماهاي مختلفي از نرم افزار مورد نظر را تهيه مي كنيم. 
نكته اي كه بايد حتما به آن توجه كنيد اين است كه : مدل UML آنچه كه يك سيستم بايد انجام دهد را توضيح مي دهد، ولي چيزي درباره نحوه پياده سازي سيستم نمي گويد. 
با توجه به رشد نرم افزارهاي پشتيباني كننده UML امروزه با استفاده از نرم افزارهايي مانند Visio ، Enterprise Architecture و rational rose شما مي توانيد بعد از كشيدن نمودارهاي UML مستقيما نمودارهاي خود را به بانك اطلاعاتي و كد تبديل كنيد (البته اين نرم افزارها ساختار كد شما را برايتان توليد مي كنند!) اين نرم افزارها همچنين كد برنامه شما را گرفته و نمودارهاي UML برنامه را توليد مي كنند. 
پس از آشنايي با مفاهيم شيء گرايي، در اينجا زبان مدلسازي UML را معرفي کرده و خواهيم ديد چگونه اين زبان مفاهيم شيء گرايي را پشتيباني مي كند.
زبان مدل سازي يكنواخت ( Unified Modeling Language ) یا UML يك زبان مدلسازي است كه براي تحليل و طراحي سيستم هاي شی گرا به كار مي‌رود. UML اولين بار توسط شركت Rational ارائه شد و پس از آن از طرف بسياري از شركت هاي كامپيوتري و مجامع صنعتي و نرم افزاري دنيا مورد حمايت قرار گرفت؛ به طوريكه تنها پس از يك سال، توسط گروه Object Management Group، به عنوان زبان مدلسازي استاندارد پذيرفته شد. UML توانايي ها و خصوصيات بارز فراواني دارد كه مي‌تواند به طور گسترده‌اي در توليد نرم‌افزار استفاده گردد. در ادامه اين مقاله ابتدا به تاريخچة UML و در ادامه به معرفي، ويژگي ها و نمودارهاي آن پرداخته مي شود.
ويژگيهاي UML
UML داراي ويژگيهاي بارز فراواني است كه در اين قسمت به آنها مي پردازيم. UML يك زبان مدلسازي است اما چيزي فراتر از چند نماد گرافيكي است. به طوريكه در وراي اين نمادها، يك سمانتيك (معناشناسي) قوي وجود دارد، به طوريكه يك توليدكننده مي‌تواند مدلهايي توليد كند كه توليد‌كننده هاي ديگر و يا حتي يك ماشين آن را بخواند و بفهمد. بنابراين يكي ديگر از نقش هاي مهم UML "تسهيل ارتباط" بين اعضاي پروژه و يا بين توليدكنندگان مختلف مي باشد. اين ارتباط بسيار مهم است. شايد دليل اصلي اينكه توليد نرم افزار به صورت فريبنده اي دشوار است، همين عدم ارتباط مناسب بين اعضاي پروژه باشد و اگر در توليد نرم افزار، بين اعضاي پروژه گزارشهاي هفتگي و مداوم وجود داشته باشد، بسياري از اين دشواريها برطرف خواهد شد. 
البته اين را هم بايد در نظر گرفت كه UML كمي پيچيده است و اين به خاطر آن است كه سعي شده است نمودارهايي فراهم شود كه در هر موقعيتي و با هر ترتيبي قابل استفاده باشند. دليل ديگر پيچيدگي از آنجا ناشي مي شود كه UML تركيبي است از زبانهاي مختلف، كه براي حفظ سازگاري و جمع كردن خصوصيات مثبت آنها، ناگزير از پذيرش اين پيچيدگي مي باشد. 
UML موفقيت طرح را تضمين نمي كند، اما در عين حال خيلي چيزها را بهبود مي‌بخشد. به عنوان مثال استفاده از UML، تا حد زيادي، هزينه هاي ثابتي نظير آموزش و استفاده مجدد از ابزارها را در هنگام ايجاد تغيير در سازمان و طرحها كاهش می دهد. 
مساله ديگر اينكه، UML يك زبان برنامه نويسي بصري (visual) نيست، اما مدلهاي آن را مي‌توان مستقيماً به انواع زبانهاي مختلف ارتباط داد. يعني امكان نگاشت از مدلهاي UML به كد زبانهاي برنامه نويسي مثل Java و ++C وجود دارد كه به اين عمل "مهندسي رو به جلو" مي گويند. 
عكس اين عمل نيز ممكن است؛ يعني اين امكان وجود دارد كه شما بتوانيد از كد يك برنامه زباني شي گرا، مدلهاي UML معادل آن را به دست آوريد. به اين عمل "مهندسي معكوس" مي گويند. مهندسي رو به جلو و معكوس از مهمترين قابليت هاي UML به شمار مي روند، البته نياز به ابزار Case مناسبي داريد كه از اين مفاهيم پشتيباني كنند. 
اگر با زبانهاي مدلسازي ديگر كار كرده باشيد، براي كار با UML مشكل چنداني نخواهيد داشت. اما براي شروع كار با UML به عنوان اولين زبان مدلسازي، بهتر است فقط با نمودارهاي خاصي كار كنيد. براي اين كار بهتر است ابتدا با نمودارهاي مورد كاربرد و تعامل كار كنيد و پس از مدتي كار و آشنا شدن با ويژگيهاي اولیه آن، به يادگيري و استفاده از نمودارها و اجزاي ديگر بپردازيد. در مقايسه با زبانهاي مدلسازي ديگر مثل ER و زبان فلوچارتي DR، زبان UML نمودارهاي قوي تر و قابل فهم تري را ارائه مي دهد كه شامل تمامي مراحل چرخه حيات توليد نرم افزار (تحليل، طراحي، پياده سازي و تست) مي‌شود. 
يكي ديگر از ويژگي هاي مهم UML اين است كه مستقل از متدولوژي يا فرايند توليد نرم افزار مي باشد و اين بدان معني است كه شما براي استفاده از UML، نياز به استفاده از يك متدولوژي خاص نداريد و مي توانيد طبق متدولوژي هاي قبلي خود عمل كنيد با اين تفاوت كه مدلهايتان را با UML نمايش مي دهيد. البته مستقل بودن از متدولوژي و فرايند توليد، يك مزيت براي UML مي‌باشد؛ زيرا بسياري از انواع پروژه ها و سيستمها نياز به متدولوژي خاص خود دارند. اگر UML در پي پياده كردن همه اينها بر مي آمد، يا بسيار پيچيده مي شد و يا استفاده خود را محدود مي كرد. البته متدولوژيهايي براساس UML در حال شكل گيري مي باشند. 
از ديگر ويژگيهاي UML مي توان به پشتيباني از مفاهيم سطح بالاي شي گرايي مثل Collaboration، Framework، Pattern و Component اشاره كرد. همچنين UML با استفاده از يك سري مكانيزم هاي گسترش پذير امكان مي دهد كه بتوان زبانهاي مدلسازي جديدتري (با گسترش مفاهيم پايه اي موجود) ايجاد كرد.

شرح نمودارهاي UML : 
در اين بخش به معرفي نمودارهاي UML مي‌پردازيم: 

نمودار كلاس (Class Diagram): 
اين نمودار، كلاس ها، واسط ها و همكاري و روابط بين آنها را نمايش می دهد. و نمودار اصلي و مركزي UML مي‌باشد. كه بيان كننده ساختار ايستاي سيستم نرم افزاري مي باشد. 

نمودار اشياء (Object Diagram): 
اين نمودار، اشياء سيستم و روابط بين آنها را نمايش مي دهد. در واقع يك تصوير لحظه‌اي از نمودار كلاس مي باشد. 

نمودار موردكاربرد (Usercase Diagram): 
اين نمودار، تعامل كاربران خارجي و سيستم را مدل مي كند و از جهاتي شبيه نمودار سطح صفر DFD مي باشد كه جنبه هاي رفتاري سيستم را نمايش مي دهد. اين نمودار نقطه‌ ورودي براي تمامي نمودارهاي ديگري است كه به تشريح نيازمنديها و معماري و پياده سازي سيستم مي پردازند. 


نمودارهاي تعامل (Interaction Diagram): 
اين نمودارها، بيان كننده تعامل هستند كه شامل اشياء مختلف است و نیز روابط بين آنها و همچنين پيغام هايي كه بين آنها رد و بدل مي شود. 
اين نمودارها جنبه هاي پوياي يك سيستم را مدل مي كنند و خود بر دو نوعند: نمودار توالي (Sequence Diagram) كه ترتيب زماني تعامل ها را نشان مي دهد و نمودار همكاري (Collaboration Diagram) كه تاكيد بر نمايش ساختاري تعامل ها دارد. 

نمودارحالت (Statechart Diagram): 
اين نمودار، بيان كننده جنبه هاي رفتاري سيستم مي باشد و در واقع توصيف رسمي يك كلاس بوده كه شامل حالات، انتقال بين حالات، رخدادها و فعاليت ها مي‌باشد. از اين نمودارها براي نمايش دادن چرخه حيات اشياء يك كلاس خاص نيز مي توان استفاده كرد. 

نمودار فعاليت (Activity Diagram): 
اين نمودار، نوع خاصي است از نمودار حالت، كه انتقال جريان از يك فعاليت به فعاليت ديگر را نمايش مي دهد. اين نمودار جنبه هاي پوياي يك سيستم را نمايش مي دهد. در واقع حالات اين نمودار، گام هاي ترتيبي انجام يك عمل را نمايش مي دهند. 

نمودار اجزاء(Component Diagram): 
از جمله نمودارهاي پياده سازي مي‌باشد و سازمان دهي و روابط بين مجموعه‌اي از اجزاء را نمايش مي دهد. اين نمودار، جنبه هاي ايستاي پياده سازي يك سيستم را مدل مي كند. 

نمودار به كارگماري(Deployment Diagram): 
پيكربندي گره هاي پردازشي زمان اجرا را نمايش مي دهد. كه براي مدل كردن جنبه هاي ايستاي به كار‌گماري يك معماري بكار مي رود. همچنين نمايش دهنده اجزای استفاده شده زمان اجرا مثل كتابخانه هاي DLL، فايل‌هاي اجرايي، كدهاي مبدا و روابط بين آنها مي باشد. 
البته اين نمودارها تمام نمودارهاي UML نيستند بلكه بسته به نياز و با كمك ابزارهاي Case مي توان نمودارهاي ديگري نيز تعريف و استفاده كرد.

روند حركت به سمت UML در جهان: 
قبل از ارائه UML، زبان مدلسازي استانداردي وجود نداشت و استفاده كنندگان مجبور بودند از ميان زبانهاي مختلف موجود ‌كه تقريباً هیچ کدام كامل نبودند و تفاوتهايي با هم داشتند، يكي را انتخاب كنند. تفاوتهاي زبانهاي مدلسازي، چندان قدرت مدلسازي را افزايش نداده بود، اما در عوض باعث افول صنعت شي گرايي و سردرگمي كاربران شده بود. در چنين شرايطي طبيعي بود كه استقبال زيادي از چنین زبان مدلسازي استانداردی بشود كه ويژگيهاي بارز زيادي داشت. بسياري از شركتها در همان اوايل كار به UML روي آوردند و تعداد ديگري نيز پس از تثبيت UML، آن را به عنوان استراتژي توليد و مستندسازي خود پذيرفتند. 
OMG كه كنسرسيومي است متشكل از 700 شركت معتبر آمريكا، از UML حمايت كرد و آن را به عنوان زبان مدلسازي استاندارد خود اعلام كرد. البته علاوه بر استاندارد شدن، حمايت جداگانه شركت هاي بزرگ دنيا مثل Hewlett-Packard، I-Logix، Microsoft، IBM، Oracle و بسياري ديگر، خود سبب افزايش كاربرد آن در محافل صنعتي و نرم افزاري دنيا گرديد.

فصل سوم:شناخت استانداردهاي ساخت و مستند‌‌سازي

با توجه به تجارت بين‌‌الملل و نياز به استفاده از استانداردهايي كه مورد قبول كشورها باشد، مؤسسه بين‌‌المللي ISO با همكاري مؤسسه IEC با تشكيل گروههاي اشتراكي (JTC1) اقدام به تدوين استانداردهاي بين‌‌المللي براي توليد و مستندسازي محصولات نرم‌‌افزاري نمودند. استاندارد ISO/IEC 12207 كه در سال 1995 ارائه شد توصيه‌‌هايي براي كل چرخه ساخت و حيات يك محصول نرم‌‌افزاري پيشنهاد كرده است. پس از آن انجمن IEEE كه مهمترين انجمن حرفه‌‌اي بين‌‌المللي در تدوين استانداردهاي مهندسي نرم‌‌افزار است به كمك مؤسسه EIA اقدام به بومي‌‌سازي استاندارد 12207 در جامعه امريكا نمود و نسخه بومي شده و بهتر توصيف شده آن تحت عنوان IEEE/EIA 12207 را ارائه نمود. نهايتاً DOD امريكا كه چهار دهه است استانداردهاي متعددي را براي توليد و مستندسازي محصولات نرم‌‌افزاري ارائه كرده است با پذيرش استاندارد IEEE/EIA 12207 ، استانداردهاي قبلي خود يعني J-STD-016-1995 و MIL-STD-498 را از رده خارج كرد. يادآوري مي‌‌گردد ساير كشورهاي پيشرفته مانند ژاپن، آلمان، انگلستان، كانادا، ... نيز اقدام به بومي‌‌سازي استاندارد ISO/IEC 12207 در كشور خود نموده‌‌اند.
نرم‌‌افزار در مقايسه با ساير مصنوعات توليدي يك تفاوت مهم و اساسي دارد. مصنوعات (مانند اتومبيل، تلويزيون، يخچال، ...) بر اساس يك مجموعه وظيفه‌‌مندي قطعي ساخته مي‌‌شوند و پس از آن در وظيفه‌‌مندي‌‌هاي مصنوع تغييري ايجاد نمي‌‌گردد. البته ممكن است وظيفه‌‌مندي‌‌هاي هر مصنوع، كم يا زياد شود امّا هرگونه تغيير در وظيفه‌‌مندي‌‌ها منجر به ساخت مدل جديدي از آن مصنوع مي‌‌گردد و كسي انتظار ندارد كه اين وظيفه‌‌مندي‌‌هاي جديد در مدل‌‌هاي موجود اعمال گردند. امّا نرم‌‌افزار پس از توليد اوليه تا پايان عمر در حال تغيير و تحول است و بايستي متناسب با نيازها، سياست‌‌ها، و قوانين جديد تغيير يابد. بنابراين بهتر است نرم‌‌افزار با يك موجود زنده به جاي يك مصنوع مقايسه گردد. بديهي است نرم‌‌افزاري را مي‌‌توان به راحتي و به شكل صحيح تغيير داد كه راجع به آن به اندازه كافي اطلاعات در دسترس باشد. چنانچه خواسته‌‌هاي اوليه، طراحي، چگونگي پياده‌‌سازي و آزمون نرم‌‌افزارها در مراحل ساخت به خوبي مستند شوند در اينصورت اعمال تغييرات در نرم‌‌افزارها به راحتي قابل مديريت و انجام است. بديهي است كه تأثير تغييرات جديد بايستي در مستندات سيستم اعمال گردد تا مستندات آخرين وضعيت سيستم نرم‌‌افزاري را نمايش دهند.
چهار دهه از شروع اقدامات اوليه براي سامان‌‌دهي پروسه توليد نرم‌‌افزار مي‌‌گذرد. اوايل به دليل فقدان يك رويه منظم (متدولوژي) براي طي پروسه توليد نرم‌‌افزار، مشكلات زيادي فراروي توليد كنندگان نرم‌‌افزار بود كه نتيجه آن كيفيت ضعيف نرم‌‌افزارهاي توليدي، سربار هزينه‌‌اي، و عدم تحقق برنامه‌‌هاي زمانبندي شده بود.
كم‌‌كم نياز به تدوين متدولوژي، مدل ساخت، و تبعيت از آنها در پروسه ساخت نرم‌‌افزار بيشتر ملموس شد و در اين چهاردهه متدولوژي‌‌هاي زيادي تدوين شد و با بكارگيري آنها، نرم‌‌افزارهاي با كيفيت بيشتري توليد شد. اين متدولوژي‌‌ها عموماً روي يكي از دو روش ساختيافته يا شي‌‌گرا پايه‌‌گذاري شده‌‌اند. متدولوژي‌‌هاي بر پايه روش ساختيافته در اواسط دهه 80 ميلادي كاملاً به بلوغ خود رسيدند و متدولوژي‌‌هاي بر پايه شي‌‌گرايي نيز با طراحي زبان مدلسازي UML سريعتر به سمت وحدت و بلوغ خود نزديك شدند. در همين راستا، مؤسساتي با بهره‌‌گيري از تجربيات حاصل از ده‌‌ها سال توليد نرم‌‌افزار اقدام به تدوين استانداردها و توصيه‌‌هايي براي توليد نرم‌‌افزار نمودند.
ضوابط تدوين گزارش تحليل نيازها و خواسته‏ هاي نرم ‏افزار
هدف
تعيين نيازها و خواسته‏ هاي نرم ‏افزار (يا جزء نرم ‏افزاري ) و روش‏هايي كه براي حصول اطمينان از دست يافتن به اين خواسته‏ ها مورد استفاده قرار مي‏گيرد.
شرح كلي
كاربري‏هاي مشخص شده براي نرم ‏افزاري كه قرار است توليد شود مورد تجزيه و تحليل قرار مي‏گيرد تا خواسته‏ ها از نرم ‏افزار مشخص شوند. گزارش تحليل نيازها و خواسته‏ ها بايستي به گونه اي تهيه شود كه ضوابط عملكردي و قابليت‏ها، كارآيي، خصوصيات فيزيكي، محيطي، واسط‏ هاي خارجي، مشخصات امنيتي و مواردي كه اطلاعات حساس را به خطر مي‏اندازد، مهندسي فاكتورهاي انساني و محيط كار ، تعاريف داده اي و نيازهاي اطلاعاتي، نيازهاي نصب، ره اندازي و تحويل، مستندات مورد نياز كاربران، نيازهاي اجرايي و عملياتي و حفظ و نگهداري نرم ‏افزار را تعيين نمايد. اطلاعات مندرج در اين گزارش اساس و مبناي انجام مرحله طراحي معماري نرم ‏افزار و مراحل بعد از آن مي‏باشد. 

قالب عمومي 
قالب عمومي اين گزارش از نوع "توصيفي" است در نتيجه بايستي از "ضوابط قالب عمومي توصيف" در تهيۀ اين گزارش استفاده شود. 
چنانچه نرم ‏افزاري كه مورد تحليل قرار مي‏گيرد خود يك سيستم مستقل باشد در اين صورت بايستي از "ضوابط قالب عمومي مشخصات" در تهيه اين گزارش استفاده شود.

محتوا
گزارش "تحليل نيازها و خواسته‏ هاي نرم ‏افزار" بسته به نوع پروژه و گستردگي آن بايستي حاوي موارد زير باشد : 
1- معرفي اجمالي سيستمي كه نرم ‏افزار بخشي از آن به شمار مي‏آيد.
2- كارآيي مورد نياز نرم ‏افزار با توجه به :
2-1- نيازهاي اجرايي
2-2- خصوصيات فيزيكي 
2-3- شرايط محيطي 
3- نيازهاي نرم ‏افزار به واسط‏هاي خارجي
4- نيازها و خواسته‏ هاي كيفي نرم ‏افزار 
5- نيازهاي ايمني (شامل مواردي كه با روش‏هاي اجراء، حفظ و نگهداري، تأثيرات محيطي و آسيب‏هاي اثرگذار بر پرسنل در ارتباط هستند)
6- خواسته‏ هاي امنيتي و حيطۀ خصوصي كاربران 
7- نيازها از نقطه نظر مهندسي فاكتورهاي انساني و محيط كار (ارگونوميك)، مواردي مثل : 
7-1- عمليات دستي
7-2- تعامل انسان - كامپيوتر 
7-3- قيد و شرط‏هاي حاكم بر كاركنان
7-4- ناحيه‏ هايي كه نيازمند توجه خاص انسان هستند و نسبت به آموزش‏هاي نيروي انساني و خطاهاي انساني حساس هستند. 
8- نيازهاي اطلاعاتي و تعاريف داده‏ هاي مورد نياز (اين بخش شامل داده‏ هاي مرتبط با نصب نرم ‏افزار، به منظور تنظيم و تطابق با نيازها هم مي‏شود)
9- نيازها از نقطه نظر نصب و تأييد محصول نرم ‏افزاري تحويلي، در محل(هاي) اجرا
10- نيازها از نقطه ‏نظر نصب و تأييد محصول نرم ‏افزاري تحويلي، در محل(هاي) حفظ و نگهداري
11- نياز كاربران از نظر مستندات
12- نياز كاربران از نظر اجرا و عمليات
13- نياز كاربران از نظر حفظ و نگهداري
14- خصوصيات كيفيتي نرم ‏افزار
15- محدوديت‏هاي حاكم بر طراحي و پياده سازي
16- منابع كامپيوتري مورد نياز
17- نيازها از نظر چگونگي بسته بندي محصول نرم ‏افزاري
نرم ‏افزارها، به همراه جزوات و كتاب‏هاي راهنماي نصب، به كارگيري ، رفع اشكال و ساير موارد لازم براي نصب و عملياتي نمودن (مثل قفل سخت ‏افزاري و چگونگي بسته بندي) در اختيار كاربران قرار گيرند.
18- اولويت‏بندي نيازها و خواسته‏ ها و تعيين موارد حساس
19- توصيف قابليت تعقيب نيازها و خواسته‏ ها (مستند نمودن نيازها بايد به گونه اي باشد كه نيازها و خواسته‏ هاي تعيين شده در طول چرخۀ توليد نرم ‏افزار يعني مراحل طراحي، اجراء، حفظ و نگهداري قابل تعقيب و دنبال نمودن باشند.)
20- دلايل توجيهي درخصوص نيازهاي تعيين شده 
الزاماتي كه در تهيه گزارش "تحليل نيازها و خواسته‏ هاي نرم ‏افزار" بايستي رعايت شوند : (بايدها)
1- ضوابط مطرح شده در بخش H3 ضميمه H استاندارد IEEE/EIA 12207.0 رعايت شود.
2- براي توصيف، از علائم و نشانه‏ هايي استفاده شود كه كاملاً از لحاظ نحوي و لغوي تعريف شده باشند.
3- نيازهايي كه با ساير نيازها در تضاد هستند، تعريف نشوند.
4- در سراسر مستندات از تعاريف و الفاظ استاندارد (متداول) استفاده شود.
5- هر نياز يا خواسته به صورت مجزا تعيين گردد.
6- به منظور جلوگيري از ناسازگاري ناشي از به روز رساني‏هاي چندگانه، هر نياز يا خواسته فقط يكبار تعريف شود.
توصيه مي‏شود : 
1- گزارش "تحليل نيازها و خواسته‏ هاي نرم ‏افزار" با در نظر گرفتن موارد زير مورد بازنگري و ارزيابي قرار گيرد :
1-1- قابليت تعقيب نيازها و خواسته‏ هايي كه در تعريف اوليه نرم ‏افزار اعلام شده اند.
1-2- تطابق نيازها و خواسته‏ هاي شناسايي شده با موارد مطرح شده در تعريف اوليه نرم ‏افزار
1-3- قابل آزمون بودن نيازها و خواسته‏ ها
1-4- امكان‏پذير بودن طراحي معماري نرم ‏افزار
1-5- امكان‏پذير بودن اجراء، حفظ و نگهداري نرم ‏افزار
2- نتايج حاصل از ارزيابي گزارش تحليل نيازها و خواسته‏ هاي نرم ‏افزار به عنوان سوابق ارزيابي و بخشي از مستندات تهيه و توليد نرم ‏افزار، تدوين و نگهداري شوند.
يادآوري مي‏گردد :‌ كليۀ مواردي كه تحت عنوان "سابقه" تهيه مي‏شوند، بايستي در تدوين آنها از "ضوابط قالب عمومي سابقه”‌ استفاده شود.
راهنمايي‏هايي كه در تهيۀ گزارش "تحليل نيازها و خواسته‏ هاي نرم ‏افزار" قابل استفاده هستند :
1- مطابق استاندارد ISO/IEC 9126 ، شش خصوصيت از نظر كيفيت نرم ‏افزار بايستي مورد توجه قرار گيرد :
1-1- عملي بودن
1-2- قابل اطمينان بودن
1-3- قابل استفاده بودن
1-4- كارايي
1-5- قابل حفظ و نگهداري بودن
1-6- قابل جابجايي بودن
2- تمامي موارد مطرح شده در قالب خصوصيات كيفي نرم ‏افزار بايستي به نحوي باشند كه تعريف يك خط‏مشي واقع‏بينانه براي آنها امكان‏پذير باشد.
3- راهنمايي‏هاي مرتبط با امنيت نرم ‏افزار در استاندارد IEEE Std 1228 موجود مي‏باشد.
4- ارزيابي امكان‏پذير بودن "طراحي معماري نرم ‏افزار" و "اجرا، حفظ و نگهداري نرم ‏افزار" از جمله مواردي است كه به عهده تهيه كننده نرم ‏افزار است. ممكن است لازم باشد نماهايي از طرح به وسيلۀ نمونه سازي يا شبيه سازي تهيه شود تا تصميم گرفته شود آيا تهيه چنين محصولي كه نيازها و خواسته‏ هاي مطرح شده را پوشش دهد امكان‏پذير است يا خير؟
منابع مورد استفاده
موارد مرتبط منابع موضوع
IEEE 830, 
EIA/IEEE J-STD-016 F.2.3, F.2.4, 
MIL-STD-961D.
هم‏چنين :
ISO/IEC 5806, 5807, 6593, 8631 ,8790
و
11411 براي راهنمايي در استفاده از نشانه‏ ها IEEE /EIA-12207.1  (6.22.1) هدف
IEEE /EIA-12207.2  (5.3.4) شرح كلي
IEEE/EIA-12207.1  (6.22.3) قالب عمومي
IEEE/EIA-12207.1  (6.22.3) محتوا
IEEE/EIA-12207.1  (6.22.4) الزامات
IEEE /EIA-12207.0  (5.3.4) توصيه‏ ها
IEEE/EIA-12207.2  (5.3.4 GUIDANCE) راهنمايي‏ها


تجزیه و تحلیل و طراحی شی ء گرا با UML
Larman در نوشته Applying uml and pattems (مقدمه ای بر تجزیه و تحلیل و طراحی شیء گرا) ، و تجزیه و تحلیل و طراحی شیء گرا را به طور خلاصه بدین صورت مورد ملاحظه قرار می دهد : « یک حوزه مسئله و راه حل منطقی از چشم انداز اشیاء ( چیزها، مفاهیم یا موجودیتها ) . Jacobson و همکاران در نوشتة «مهندسی نرم افزار شیء گرا»، این اشیاء را بدین صورت تعریف می کنند : « تعدادی عملیات و حالت که اثرات این عملیات را تداعی می کند.»
در تجزیه و تحلیل و شیء گرا، این اشیاء در حوزه مسأله ، شناسایی و توصیف می شوند، در حالی که در طراحی شیء گرا، آنها به اشیاء نرم افزاری منطقی تغییر می یابند و در نهایت در یک زبان برنامه نویسی شیء گرا پیاده سازی می شوند.
با تجزیه و تحلیل و طراحی شیء گرا، مفاهیم خاصی از شیء (یا گروهی از اشیاء) می توانند برای ساده کردن شرح مختصر برنامه های تجارت پیچیده، خلاصه و ساده شوند. همچنین برای کاهش پیچیدگی خصوصیات خاصی از شیء (یا اشیاء) می توانند خلاصه شوند به طوریکه فقط جنبه های مهم یا ضروری مد نظر قرار گیرد.
 
مطالعه ادامه در فایل word اصلی 309 صفحه ای ضمیمه . . . لطفا پس از دانلود یک فاتحه رفتگان مرا میهمان فرمائید . . . 
 
لینک دانلود فایل . . .

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

حرف 500 حداکثر