مقاله در مورد زبان مدل‎سازی یکنواخت ( 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 سريعتر انجام شد؛ بطوريكه در همان زمان استاندارد شدن UML در سال 1997، شركتهايي در ايران، اين ابزار را به عنوان استاندارد خود پذيرفتند و از آن در توليد محصولات خود استفاده كردند.
يكي از مشكلات پذيرش اين زبان در ايران، مقاومتهايي است كه در رابطه با خود شي‌گرايي مطرح مي‌شود. البته نظير اين مقاومتها در دنيا نيز وجود داشت و سرو صداهاي بسياري را سبب شد. اما تا قبل از ظهور UML و با ارائه متدهاي فراوان شي‌‌گرايي، اين مشكل تا حدودي حل شده بود.
با توجه به روند حركت شتابان به سمت UML در دنيا و با توجه به اهميت استانداردسازي براي صنعت نرم‌افزار كشور، حركت هرچه‌سريعتر به سوي اين فناوري در كشور توصيه مي‌شود.

اهميت ترويج UML در كشور:

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

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

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