نرم افزار

 

نرم‌‌افزار در مقايسه با ساير مصنوعات توليدي يك تفاوت مهم و اساسي دارد. مصنوعات (مانند اتومبيل، تلويزيون، يخچال، ...) بر اساس يك مجموعه وظيفه‌‌مندي قطعي ساخته مي‌‌شوند و پس از آن در وظيفه‌‌مندي‌‌هاي مصنوع تغييري ايجاد نمي‌‌گردد. البته ممكن است وظيفه‌‌مندي‌‌هاي هر مصنوع، كم يا زياد شود امّا هرگونه تغيير در وظيفه‌‌مندي‌‌ها منجر به ساخت مدل جديدي از آن مصنوع مي‌‌گردد و كسي انتظار ندارد كه اين وظيفه‌‌مندي‌‌هاي جديد در مدل‌‌هاي موجود اعمال گردند. امّا نرم‌‌افزار پس از توليد اوليه تا پايان عمر در حال تغيير و تحول است و بايستي متناسب با نيازها، سياست‌‌ها، و قوانين جديد تغيير يابد. بنابراين بهتر است نرم‌‌افزار با يك موجود زنده به جاي يك مصنوع مقايسه گردد. بديهي است نرم‌‌افزاري را مي‌‌توان به راحتي و به شكل صحيح تغيير داد كه راجع به آن به اندازه كافي اطلاعات در دسترس باشد. چنانچه خواسته‌‌هاي اوليه، طراحي، چگونگي پياده‌‌سازي و آزمون نرم‌‌افزارها در مراحل ساخت به خوبي مستند شوند در اينصورت اعمال تغييرات در نرم‌‌افزارها به راحتي قابل مديريت و انجام است. بديهي است كه تأثير تغييرات جديد بايستي در مستندات سيستم اعمال گردد تا مستندات آخرين وضعيت سيستم نرم‌‌افزاري را نمايش دهند.
چهار دهه از شروع اقدامات اوليه براي سامان‌‌دهي پروسه توليد نرم‌‌افزار مي‌‌گذرد. اوايل به دليل فقدان يك رويه منظم (متدولوژي) براي طي پروسه توليد نرم‌‌افزار، مشكلات زيادي فراروي توليد كنندگان نرم‌‌افزار بود كه نتيجه آن كيفيت ضعيف نرم‌‌افزارهاي توليدي، سربار هزينه‌‌اي، و عدم تحقق برنامه‌‌هاي زمانبندي شده بود.
كم‌‌كم نياز به تدوين متدولوژي، مدل ساخت، و تبعيت از آنها در پروسه ساخت نرم‌‌افزار بيشتر ملموس شد و در اين چهاردهه متدولوژي‌‌هاي زيادي تدوين شد و با بكارگيري آنها، نرم‌‌افزارهاي با كيفيت بيشتري توليد شد. اين متدولوژي‌‌ها عموماً روي يكي از دو روش ساختيافته يا شي‌‌گرا پايه‌‌گذاري شده‌‌اند. متدولوژي‌‌هاي بر پايه روش ساختيافته در اواسط دهه 80 ميلادي كاملاً به بلوغ خود رسيدند و متدولوژي‌‌هاي بر پايه شي‌‌گرايي نيز با طراحي زبان مدلسازي UML سريعتر به سمت وحدت و بلوغ خود نزديك شدند. در همين راستا، مؤسساتي با بهره‌‌گيري از تجربيات حاصل از ده‌‌ها سال توليد نرم‌‌افزار اقدام به تدوين استانداردها و توصيه‌‌هايي براي توليد نرم‌‌افزار نمودند. مؤسساتي كه در تدوين استانداردهاي مورد نياز صنعت نرم‌‌افزار پيشرو هستند عبارتند از مؤسسه DOD(1.Department of Defense) (بزرگترين كارفرماي متقاضي توليد نرم‌‌افزار)، سازمان NASA، آژانس فضايي اروپا، مؤسسه IEEE (بزرگترين انجمن حرفه‌‌اي در رشته IT ( 2. Information Technology))، و مؤسسه تدوين استاندارد ISO.استانداردهاي مهندسي نرم‌‌افزار مجموعه‌‌اي از پروسه‌‌ها مي‌‌باشند كه تمامي وظايفي كه بايستي در چرخه توليد و بكارگيري يك محصول نرم‌‌افزاري انجام شود را بيان مي‌‌كنند. نكته مهم اينست كه اين پروسه‌‌ها چگونگي انجام يك وظيفه را بيان نمي‌‌كنند بلكه صرفاً مجموعه‌‌اي از وظايف و فعاليتها را بيان مي‌‌كنند كه بايستي در دوره‌‌هاي زماني معيني انجام شوند. اين رويه در تمامي استانداردهاي مهندسي نرم‌‌افزار رعايت مي‌‌شود تا اولاً آنها فراتر از يك متدولوژي عمل كنند و ثانياً اجازه دهند مهندسين نرم‌‌افزار بر حسب نوع محصول نرم‌‌افزاري از متدولوژي كه چگونگي انجام وظايف را بيان مي‌‌كند، استفاده كنند. نكته جالب توجه اينست كه استانداردهاي جهاني حتي از نظر نوع نگرش مهندسي نرم‌‌افزار (ساختيافته يا شي‌‌گرا) نيز خود را محدود نكرده‌‌اند و توصيه‌‌ها و قوانيني را مطرح كرده‌‌اند كه در هر دو ديدگاه قابليت استفاده دارند.

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

نرم افزار و چند نمونه از آنها بصورت اجمالي معرفي مي گردد .

زبان مدلسازي يكنواخت (UML) مي‌تواند در جهت ارتقاي كيفيت و توجه به اصول مهندسي نرم‌افزار در كشور مؤثر باشد  

   

علي‌رغم مزيتهاي عمده‌اي كه كارشناسان براي صنعت نرم‌افزار ايران برمي‌شمرند (از جمله نيروي انساني مستعد و ارزان)، اين صنعت در كشور ما با افت شديد كيفيت روبرو است. نه شركتهاي نرم‌افزاري معدود كشور، چندان به دنبال بكارگيري استانداردها و روشهاي علمي طراحي و توليد نرم‌افزار هستند و نه فرهنگ مصرف ما كيفيت‌طلب است. مشتريان بزرگ و مشكل‌پسند (كه معمولاً شركتهاي بزرگ دولتي هستند) نيز طالب خريد از خارج هستند و عدم كيفيت نرم‌افزارهاي ساخت داخل را بهانه مي‌كنند. يكي از مهمترين اقداماتي كه دولت بايستي در جهت اصلاح اين بازار آشفته انجام دهد، ترويج استانداردهاي مدلسازی نرم‌افزار است. مدلهای استاندارد، تعريف دقيقتر نرم‌افزار را ممكن ساخته و از سوءتفاهمات جلوگيري مي‌كنند. اين مدلها همچنين ارزيابي نرم‌افزار را تسهيل نموده و ابزاري براي سوق دادن صنعت نرم‌افزار بسوي رعايت معيارهاي كيفي و اصول مهندسي نرم‌افزار فراهم مي‌آورند. مقالة زير به معرفي يكي از مهمترين اين استانداردها پرداخته است:

 

زبان مدلسازي يكنواخت:

 

زبان مدلسازي يكنواخت يا Unified Modeling Language (UML)، يك زبان مدلسازي است كه براي تحليل وطراحي سيستمهاي شي‌گرا بكار مي‌رود. UML اولين بار توسط شركت Rational ارائه شد و پس از آن از طرف بسياري از شركت‌هاي كامپيوتري و مجامع صنعتي و نرم‌افزاري دنيا مورد حمايت قرار گرفت؛ به طوريكه تنها پس از يك سال، توسط گروه Object Management Group، به عنوان زبان مدلسازي استاندارد پذيرفته شد. UML تواناييها و خصوصيات بارز فراواني دارد كه مي‌تواند به طور گسترده‌اي در توليد نرم‌افزار استفاده گردد. در ادامة اين مقاله ابتدا به تاريخچة UML و در ادامه به معرفي، ويژگيها و نمودارهاي آن پرداخته مي‌شود و در پايان، روند حركت به سمت UML و اهميت آن براي ايران، بررسي خواهد شد.

 

تاريخچة UML :

 

ديدگاه شي‌گرايي (Object Oriented) از اواسط دهه 1970 تا اواخر دهه 1980 در حال مطرح شدن بود. در اين دوران تلاشهاي زيادي براي ايجاد روشهاي تحليل و طراحي شي‌گرا صورت پذيرفت. در نتيجة اين تلاشها بود كه در طول 5 سال يعني 1989 تا 1994، تعداد متدولوژيهاي شي‌گرا از كمتر از 10 متدولوژي به بيش از 50 متدولوژي رسيد. تكثر متدولوژيها و زبانهاي شي‌گرايي و رقابت بين اينها به حدي بود كه اين دوران به عنوان "جنگ متدولوژيها" لقب گرفت. از جمله متدولوژيهاي پركاربرد آن زمان مي‌توان از Booch، OOSE، OMT، Fusion، Coad-Yourdan، Shlayer-Mellor وغيره نام برد. فراواني و اشباع متدولوژيها و روشهاي شي‌گرايي و نيز نبودن يك زبان مدلسازي استاندارد، باعث مشكلات فراواني شده بود. از يك طرف كاربران از متدولوژيهاي موجود خسته شده بودند، زيرا مجبور بودند از ميان روشهاي مختلف شبيه به هم كه تفاوت كمي در قدرت و قابليت داشتند يكي را انتخاب كنند. بسياري از اين روشها، مفاهيم مشترك شي‌گرايي را در قالبهاي مختلف بيان مي‌كردند كه اين واگرايي و نبودن توافق ميان اين زبانها، كاربران تازه‌كار را از دنياي شي‌گرايي زده مي‌كرد و آنها را از اين حيطه دور مي‌ساخت. عدم وجود يك زبان استاندارد، براي فروشندگان محصولات نرم‌افزاري نيز مشكلات زيادي ايجاد كرده بود.

 

اولين تلاشهاي استانداردسازي از اكتبر 1994 آغاز شد، زماني كه آقاي Rumbaurgh صاحب متدولوژي OMT به آقاي Booch در شركت Rational پيوست و اين دو با تركيب متدولوژيهاي خود، اولين محصول تركيبي خود به نام "روش يكنواخت" را ارائه دادند. در سال 1995 بود كه با اضافه شدن آقاي Jacobson به اين دو، روش يكنواخت ارائه شده با روش OOSE نيز تركيب شد واين خود سبب ارائة UML نسخة 0.9 در سال 1996 گرديد. سپس اين محصول به شركتهاي مختلفي در سراسر جهان به صورت رايگان ارائه شد و استقبال شديد شركت‌ها از اين محصول و تبليغات گسترده شركت Rational، سبب آن شد كه گروه OMG، نسخة 1.0 UML را به عنوان زبان مدلسازي استاندارد خود بپذيرد. تلاشهاي تكميلي UML استاندارد ادامه پيدا كرد و نسخة 1.1 آن در سال 1997 و نسخه 1.3 آن در سال 1999 ارائه گرديد.

 

 UML چيست؟

 

UML يا زبان مدلسازي يكنواخت، زباني است براي مشخص كردن (Specify)، مصورسازي (Visualize)، ساخت (Construction) و مستندسازي (Documenting) سيستمهاي نرم‌افزاري و غير نرم‌افزاري و نيز براي مدلسازي سيستمهاي تجاري. اما چرا مدل و مدلسازي؟

 

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

 

به عبارت ديگر، يك زبان، با ارائه يك فرهنگ لغات ويك مجموعه قواعد، امكان مي‌دهد كه با تركيب كلمات اين فرهنگ لغات و ساختن جملات، با يكديگر ارتباط برقرار كنيم. يك زبان مدلسازي، زباني است كه فرهنگ لغات و قواعد آن بر نمايش فيزيكي و مفهومي آن سيستم متمركزند. براي سيستمهاي نرم‌افزاري نياز به يك زبان مدلسازي داريم كه بتواند ديدهاي مختلف معماري سيستم را در طول چرخة توليد آن، مدل كند.

 

فرهنگ واژگان و قواعد زباني مثل UML به شما مي‌گويند كه چگونه يك مدل را بسازيد و يا چگونه يك مدل را بخوانيد. اما به شما نمي‌گويند كه در چه زماني، چه مدلي را ايجاد كنيد. يعني UML فقط يك زبان نمادگذاري (Notation) است نه يك متدولوژي. يك زبان نمادگذاري شامل نحوة ايجاد و نحوة خواندن يك مدل مي‌باشد، اما يك متدولوژي بيان مي‌كند كه چه محصولاتي بايد در چه زماني توليد شوند و چه كارهايي با چه ترتيبي توسط چه كساني، با چه هزينه‌اي، در چه مدتي و با چه ريسكي انجام شوند.

 

 

 ويژگيهاي UML :

 

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

 

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

 

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

 

مساله ديگر اينكه، UML يك زبان برنامه‌نويسي بصري (visual) نيست، اما مدلهاي آن را مي‌توان مستقيماً به انواع زبانهاي مختلف ارتباط داد. يعني امكان نگاشت از مدلهاي UML به كد زبانهاي برنامه‌نويسي مثل Java و VC++ وجود دارد كه به اين عمل "مهندسي روبه‌جلو" مي‌گويند. عكس اين عمل نيز ممكن است؛ يعني اين امكان وجود دارد كه شما بتوانيد از كد يك برنامه زباني شي‌گرا، مدلهاي 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 و بسياري ديگر، خود سبب افزايش كاربرد آن در محافل صنعتي و نرم‌افزاري دنيا گرديد. امروزه نيز با ارائه نسخه 1.3 و رفع مشكلات گذشته، روز به روز بر كاربران آن افزوده مي‌شود.

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 يک متد Public است . بنابراين امکان استفاده از آن توسط يک برنامه نويس وجود خواهد داشت .بمنظور ارسال داده به متد مورد نظر از آرگومان استفاده شده که بين علامت پرانتز قرار می گيرند.در مثال فوق ، پارامتر مورد نظر DesiredSpeed بوده و از نوع Integer است . در انتهای علامت پرانتز بسته ، ازيک کالون ":" ، که بدنبال آن کلمه Integer آمده است ، استفاده شده است . اين بدان معنی است که متد ( ) SetSpeed يک مقدار صحيح را به برنامه صدازننده ، بر می گرداند.
در نمونه کلاس Vehicle از دومتد بمنظور افزايش و يا کاهش سرعت استفاده شده است :

هر يک از متدهای فوق ، عمليات مورد نظر در رابطه با افزايش و يا کاهش سرعت را انجام خواهند داد . برای نيل به خواسته فوق ( افزايش و يا کاهش سرعت ) می توان دو متد فوق را با يکديگر تلفيق و در يک متد واحد ديگر جايگزين نمود:

در صورتيکه پارامتر DesiredSpeed مثبت باشد ، سرعت افزايش و در غير اينصورت ( پارامتر منفی باشد ) ، سرعت کاهش خواهد يافت.

درنمونه مثال فوق ، در ابتدا يک شی Vehicle با نام MyVehicle تعريف شده است . در ادامه ، متد GetSpeed در ارتباط با شی MyVehicle فرا خوانده شده است .بمنظور جداسازی نام شی از متد مربوطه از علامت نقطه استفاده شده است .

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

 

خلاصه

 

·   الگوريتم ،اعلاميه ای سازماندهی شده بمنظور حل يک مسئله خاص و يا سوالاتی است که می بايست پاسخ آنان مشخص گردد . يک الگوريتم مناسب ، تمامی مراحل لازم بمنظور انجام فرآيندهای مورد نياز و حل يک مسئله را ارائه می نمايد .

·        مقداردهی اوليه ، ورودی ، پردازش ، خروجی و پاکسازی ، پنج مرحله متفاوت برنامه نويسی می باشند .

·   مراحل پنج گانه برنامه نويسی ، نگرشی ماکرو از يک برنامه را ارائه می نمايند . مثلا" مرحله ورودی ممکن است نيازمند اخذ داده از صفحه کليد ، خواندن يک جدول تنظيمات از يک بانک اطلاعاتی و نهايتا" خواندن اطلاعات بيشتر از بانک اطلاعاتی ديگر باشد . بهسازی ( پالايش ) يکطرفه ، فرآيندی است که بر اساس آن يکی از مراحل برنامه نويسی (نظير مرحله ورودی ) بررسی و به آن جزئيات بيشتری اضافه اضافه خواهد شد . عمليات فوق تا استخراج و مشخص شدن تمامی جزئيات لازم در رابطه با يک مرحله خاص ادامه خواهد يافت . عمليات بهسازی ( پالايش ) يکطرفه ، زمانی متوقف می گردد که کد واقعی يک تابع نوشته گردد .محوريت فرآيند فوق ، تبديل الگوريتم های ماکرو به ميکرو است :

·   UML ، از کلمات Unified Modeling Language اقتباس شده است . مزيت استفاده از UML ، تفکر مبتنی بر برنامه نويسی شی گراء است .بلاک های اوليه ايجاد UML کلاس ، خصلت و متد ناميده می شوند. دياگرام های کلاس UML تمام سه عنصر OOP را در يک دياگرام مناسب نمايش می دهند .

·   در OOP ، واژه های Private و Public به نحوه دستيابی به خصلت ها بر می گردد . اگرخصلتی از نوع Private باشد ،امکان تغيير آن صرفا" برای کسانی که به کلاس فوق تعلق دارند، وجود خواهد داشت .اگر خصلتی از نوع Public باشد ، ساير اشياء امکان دستيابی کامل به خصلت را ( اعمال تغييرات مورد نظر ) خواهند داشت.

 

امنیت در تولید نرم افزار ها

 

امنیت در تولید نرم افزار ها...

آموزش فلش

 

آموزش فلش

اگه دوست دارید فلش یاد بگیرید لطفا این مقاله رو

مطالعه کنید ...

آموزش نرم افزار مایا 5

اینم یه مقاله انیمیشنی برای دوست داران انیمیشن

در این مقاله آموزش نرم افزار مایا ۵ در چند قسمت اومده بخونید و نظر هم

یادتون نره ...

مبانی آشنايی با Word

مبانی Word و آشنایی با این نرم افزار رو می تونین در این مقاله مطالعه

کنید ...

ادامه بحث فتوشاپ

فصل پنجم ...

ادامه بحث فتوشاپ

فصل چهارم ...

ادامه بحث فتوشاپ

فصل سوم ...

ادامه بحث فتوشاپ

فصل دوم ...

آموزش فتوشاپ

من می خوام فتوشاپ رو به شما عزیزان آموزش بدم امیدوارم که این مقاله آموزشی مورد علاقه شما عزیزان قرار بگیره

این مقاله آموزشی در پنج فصل تهیه شده.

فصل اول ...

فرآینده توسعه نرم افزار

در ساخت يک سيستم نرم افزاري سه فرآيند مهم تاثير گذار مي باشند:
- فرآيند توسعه (Development Process): سازماندهی فعالیت ها است برای ساخت یک سیستم
- فرآيند مديريت (Management Process): انتخاب افراد، تجهیزات و فرآیند هاست برای توسعه یک سیستم و کنترل و نظارت بر روند اجرای پروژه (مدیریت پروژه)
- فرآيند پشتيباني (Maintenance Process): کنترل و پشتیبانی نرم افزار پس از تولید آن

 

در این بین در فرآیند توسعه هدف آن است که یک سیستم با مشخصات خواسته شده تولید شود و بنابراین برای تولید هر نوع سیستم متفاوت است.فرآیند توسعه از مرحله طرح یک راه حل مفهومی برای مساله خواسته شده (امکان سنجی) آغاز شده، پس از دریافت خواسته ها و تحلیل سیستم طراحی صورت گرفته و در نهایت این طراحی با کمک ابزارهای پیاده سازی تبدیل به یک سیستم واقعی می شود. هدف این فرآیند آن است که از یک سو برآورده ساختن نیازهای کاربران و از سوی دیگر کیفیت مناسب عملکرد سیستم تضمین گردد و بنابراین بایستی حاوی مکانیسم هایی برای اعتبار سنجی: خروجی مطابق با خواسته ها (Validation) و وارسی پذیری: صحت عملکرد خروجی (Verification)  باشد. فرآیند توسعه ضمن دادن آزادی به تحلیل گر باید تضمین کند که زمانبندی رعایت شود.

 

روشهای مختلفی برای فرآیند توسعه سیستم وجود دارد که در این میان می توان گفت 12 روش مطرح تر وجود دارد که بدون اشاره به مزایا و معایب آنها عبارتند از:

1- ساده ترین روش: تبدیل فرآیند توسعه سیستم در قالب دنباله ای از وظایف مشخص و ترسیم CPM: Critical Path Model ، یک نمودار از تمام فعالیت ها

2- فرایند توسعه خطی Liner: به ترتیب مراحل انتخاب پروژه، تعریف مفهومی (تعریف مساله، امکان سنجی) ، تعریف مشخصات (خواسته ها ، تعریف مساله) ، طراحی (طراحی معماری، تفصیلی) ، توسعه (ساخت سیستم، تست) ، ارزیابی و درنهایت تعریف پروژه جدید

3- مدل آبشاری (Water Fall) : تقسیم وظائف توسعه سیستم در قالب یک مدل آبشاری از تعریف مساله، امکان سنجی، تحلیل (سیستم، خواسته ها)، طراحی ، پیاده سازی و تست ، یکپارچه سازی و تست، نصب و تست ، نگهداری و مرور , با امکان برگشت از یک مرحله به مرحله قبل

4- توسعه مرحله ای، افزایشی و یا نموی Incremental Methods : تقسیم یک مساله به مسائل کوچکتر و انجام هر زیر سیستم (مساله کوچکتر) و انجام هر یک به صورت جداگانه و در صورت امکان اجرا به صورت همزمان

5- الگو سازی (Prototyping) :ایجاد یک الگو برای کاربران برای اینکه درک بهتری از سیستم داشته باشند و درنهایت پیاده سازی سیستم بر اساس این نمونه

6- توسعه سریع سیستم RAD: Rapid Application Development : ادغام برخی مراحل با یکدیگر و استفاده از زبانهای نسل چهارم برای توسعه سیستم (مراحل: برنامه ریزی، طراحی و تست)

7- طراحی تکاملی به صورت حلزونی و یا مارپیچی (Spiral) : توسعه سیستم به صورت افزایشی به صورت بازگشتی Recursive

8- با اضافه کردن مفاهیم برنامه سازی شی گرایی (OOP) به روش حلزونی و تبدیل به صورت موازی بازگشتی (Parallel Recursive Method )

9- توسعه سیستم مبتنی بر مولفه ها (CBSD: Component Based Software Development )

10- مهندسی همزمان (Concurrent Engineering ) : توسعه به صورت یک فرآیند سیستم. تقسیم سیستم به بخش های مختلف و تقسیم نیروها در بین پروژه های مختلف برای اجرای این بخش ها به صورت همزمان

11- روشهای فرمال : بکارگیری مدل ها و مفاهیم ریاضی در توسعه سیستم

12- روشهای نسل چهارم: بگارگیری از ابزارهای گرافیکی و ابزارهای مهندسی نرم افزار (CASE Tools)

با توجه به تعدد روشها و مدل های فرآیند توسعه باید در یک پروژه انتخاب صورت بگیرد. این انتخاب بر اساس موارد زیر می تواند باشد:

- درجه ساختاری سیستم

- آشنایی با فنآوری

- اندازه پروژه

برای مثال چرخه های خطی برای پروژه های آسان و ساختیافته و یا زمانی که با فنآوری کاملا آشنا هستیم مناسب می باشند و برای پروژه های بزرگ و ناشناخته روشهای افزایشی بهتر می باشند.

اما نمی توان انتظار داشت یک گروه تولید کننده نرم افزار در هر پروژه یک معیار را انتخاب کند. چون این کار بسیار هزینه بر است و به لحاظ مختلف ناصواب. دلایل انتخاب یک روش استاندارد برای یک تیم و استفاده در همه پروژه ها آنست که:

- طراحان برای یادگیری تکنیک های جدید وقت زیاد تلف نمی کنند.

- مستند سازی بهتر صورت می گیرد

- کاهش هزینه آموزش کاربران سیستم ها