زبان مدلسازی یکنواخت (بخش دوم)

نمودارهای 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 در تولید نرم‌افزار در کشور به یک فرهنگ تبدیل گردد، گام بزرگی به سوی دقت، کیفیت، مستندسازی و رعایت اصول مهندسی نرم‌افزار برداشته شده است.