آشنایی با UML زبان مدل سازي يكپارچه در پروژه های مهندسی نرم افزار بخش اول

آشنایی با UML زبان مدل سازي يكپارچه در پروژه های مهندسی نرم افزار بخش اول

آشنايي با UML

زبان مدل سازي يكپارچه (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 ، گذشته ، حال و آينده 

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

 

زمينه UML

زبان هاي مدل سازي شي گرا از اواسط دهه 1970 آغاز به ظهور كردند و از اواخر دهه 1980 ، متدولوژيست هاي زيادي ، رويكردهاي متفاوتي را براي تحليل و طراحي شي گرا بيان كردند. تكنيك هاي متعدد ديگري نيز بر اين زبان ها اثر گذاشتند ، نظير : مدل ساز ي ارتباط موجوديت ، زبان SDL و ديگر تكنيك ها .

تعداد زبان هاي مدل سازي تعريف شده در دوره زماني بين 1989 تا 1994 ، از 10 عدد به بيش از 50 عدد رشد كرد. بسياري از كا ربران روش هاي OO  در يافتن يك زبان مدل سازي كه رضايت كامل آنها را جلب كند ، با مشكل مواجه بودند و از طرفي در حال سوخت رساني به جنگ روش ها بودند. از اواسط دهه 1990 ، تكرار جديدي از اين روش ها آغاز به ظهور كرد، نظير Booch 93 ، تكامل مستمر OMT/Rumbugh  و Fusion . اين روش ها آغاز به داخل كردن تكنيك هاي ديگران به روش هاي خودشان كردند و روش هايي نظير Booch93 , OMT-2.OOSE/Jacobson  ايجاد گرديد . هر يك از اين روش ها نيز به نوبه خود يك روش كامل بود. 

Jacobson, Rumbaugh ,Booch  نيروهايشان را به هم پيوستند توسعه UML  در اكتبر 1994 زماني كه Jim Rumbaugh,Grady Booch  از  شركت Rational Software Corporation كارشان را براي  يكي كردن روش هاي Booch  و  OMT  آغاز كردند ، شروع گرديد . در اكتبر 1995 نسخه 8 ، از Unified Method  (كه همين طور نام گذاري شده بود ) بيرون آمد . در پائيز 1995 ،  Ivar Jacoboson  و شركت  Objectory اش به Rational  پيوستند. و روش OOSE  را نيز در آن ادغام كردند. هم اكنون از نام Objectory براي توصيف فرآيند UML  استفاده مي شود. 

تلاش هاي Jacobson.Rumbaugh,Booch  در اصلاح و انتشار اسناد 0.9-0.91  در ژوئن و اكتبر 1996 به نتيجه رسيد. در سال 1996 ، نويسندگان UML  از جامعه دعوت كردند و بازخورهايي را نيز دريافت كردند. اگر چه آنها اين بازخورها را يكپارچه كردند ، اما توجه متمركز بيشتري هنوز مورد نياز بود. 

 

UML 1.0-1.1  و شركاي UML 

در سال 1996 مشخص شد كه سازمان هاي متعدد ، UML  را از ديد استراتژيك مي بينند. درخواست پيشنهادي كه از سوي OMG  منتشر شد ، كاتاليزوري را فراهم كرد تا اين سازمان ها براي توليد يك پيشنهاد به  درخواست فوق بپيوندند. Rational ، كنسرسيوم شركاي UML  را با سازمان هاي چندي ايجاد كرد  تا منابع شارن را براي كار كردن بر روي تعريف UML 1.0  متمركز كنند. 

بيشترين مشاركت كنندگان در تعريف  UML1.0  عبارت بودند از : 

ICON,IBM , IntelliCrop > I-Logix, HP, Digital Equipment Corp.

Tl, Rational Software, Oracle, Microsoft, MCI Systembouse, Computing Unisys. اين همكاري ، UML 1.0    را توليد كرد كه يك زبان مدل سازي با تعريف ، بيان قدرت و كاربرد عمومي خوبي بود. اين كار در ژنوايه 1997 به عنوان عكس العمل اوليه به درخواست فوق به وسيله OMG  پذيرفته شد. 

در ژانويه 1997 ، شركت هاي ‍‍‍Ptech, platinum Technology       و  Taskon & IBM & ObjecTime SofteamوReich Technologies  نيز يك پيشنهاد مجزا را به OMG ارائه كردند . اين شركت ها به شركاي UML پيوستند تا افكارشان را سهيم كنند و با يكديگر UML 1.1  را ايجاد نمايند. تمركز به UML 1.1  بهبود وضوح و روشني مفاهيم UML 1.0  و نيز شركت دادن شركاي جديد در اين همكاري بود. اين نسخه نيز توسط OMG به تصويب رسيد. 

 

UML  حال و آينده 

UML  غير خصوصي است و براي همه باز است . UML  نيازهاي كاربران و اجتماعات علمي را نشانه مي رود. بسياري از متدولوژيست ها ، سازمان ها و توليد كنندگان ابزار ، خود را در استفاده از آن متعهدا كرده اند. از آنجا كه UML  مفاهيم و علائم مشابهي از Booch,OMT,OOSE  و ديگر روش هاي مهم را ارائه مي كند و با وارد كردن شركاي UML  و باز خور عمومي به خود ، شخصيت قانوني ارائه كرده است ، انتخاب وسيع UML  بايستي كار درستي باشد. 

دو جنبه يكپارچگي كه زبان مدل سازي يكپارچه (UML ) به دست آورده است عبارتند:

• 1) UML به صورت مؤثري به بسياري از اختلاف ها پايان مي دهد كه غالبا هم در زبان هاي مدل سازي روش هاي قبلي ظهور كرده بود. 
• 2) UML  ، ديدگاه ها را در انواع مختلف سيستم ها ( كسب و كار در مقابل نرم افزار ) ، مراحل توسعه (تحليل نيازمندي ها ، طراحي و پياده سازي )، و مفاهيم دروني ، يكپارچه مي كند.
• 3) استاندارد سازي UML 

بسياري از سازمان ها ، UML  را به عنوان استاندارد سازماني شان تاييد كرده اند ، به دليل آنكه UML از زبان هاي مدل سازي كه توسط روش هاي مهم OO  ارائه شده اند منبعث شده است . UML  براي استفاده روزمره و همگاني بسيار  مطلوب است. 

 

صنعتي سازي 

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

 

 

ريسك نيازمندي ها 

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

 

 

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

آشنایی با UML زبان مدل سازي يكپارچه در پروژه های مهندسی نرم افزار بخش چهارم

انواع مدل ها 

مدل هاي مختلفي را مي توان ترسيم نمود :

• 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 نيز بر آنها تاكيد زيادي دارد. 

 

 

مرحله ساخت 

در مرحله ساخت ، سيستم در طي يك سري تكرار ايجاد مي شود در هر تكرار نيز تأييد كاربر اخذ مي شود . هدف از اين فرايند كاهش ريسك است . 

 

پاسخ به:آشنایی با 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چه فرايند و روشي را به كار مي گيرند .