این زبان مدلسازی یکپارچه (UML) برای دههها پایهای اصلی بصریسازی معماری نرمافزار بوده است. با این حال، در دنیای پرسرعت توسعه نرمافزار مدرن—که تحت تأثیر روشهای آگیل است، خطوط لوله DevOps، و تکرار سریع—UML اغلب با شک و تردید مواجه میشود. بسیاری از اشتباهات مرسوم باقی ماندهاند، که باعث میشود تیمها این ابزار قدرتمند را نادیده بگیرند.
اوقات آن رسیده است تا این افسانهها را نقض کنیم و نشان دهیم که UML همچنان بسیار مرتبط و ضروری است، حتی در محیطهای پیشرفتهترین.
افسرانه: UML فقط برای پروژههای Waterfall است
این احتمالاً پرطرفدارترین اشتباه است. UML در زمانی شکل گرفت که روشهای بیشتر ساختاریشده بودند، توسعه مبتنی بر سند، که باعث شد بسیاری آن را به طور انحصاری با مراحل سفت و سخت و توالیگرای Waterfall مرتبط کنند، مراحل توالیگرای Waterfall.
-
واقعیت: UML بیطرف نسبت به روشهای توسعه است. در آگیل و DevOps، نمودارهای UML به عنوانابزارهای سبک و در زمان مناسب برای ارتباط، نه اسناد جامع. یک نمودار توالی سریع تعامل API را روشن میکند، یا یک نمودار کلاس ساده به بازسازی کد در طول یک اسپرینت کمک میکند. هدف ازمستندسازی همه چیز بهارتباط برای اینکه چه چیز مهم است، حالا.
احلام: UML بیش از حد پیچیده است و ابزارهای تخصصی نیاز دارد
بسیاری از توسعه دهندگان از تعداد زیاد نمودارها و نمادها ترسیدهاند،با این فرض که باید کل مشخصات را یاد بگیرند و نرمافزارهای گرانقیمت خریداری کنند.
-
واقعیت: UML یک زبان است و شما تنها باید دیالکت مربوطه را یاد بگیرید.اکثر تیمها تنها به چند نمودار وابستهاند (کلاس,دنباله,مورد استفاده,فعالیت) و از ابزارهای ساده،ابزارهای رایگان یا حتی ابزارهای تولید نمودار بر اساس متن برای تولید نمودارها به صورت فوری از کد یا متن ساده استفاده میکنند.پیچیدگی با محدود شدن به زیرمجموعه ضروری مدیریت میشود.
احلام: UML کاملاً در مورد طراحی قبل از کدنویسی است
این از دیدگاه سنتی نشأت میگیرد که تمام مدلسازی باید اولیه انجام شود،که باعث تأخیر در شروع کدنویسی میشود.
-
واقعیت: UML هم پشتیبانی از مهندسی پیشرو و هم مهندسی معکوس را دارد.
-
پیشرو:مدلسازی قبل ازکدنویسی برای اعتبارسنجی ایدههای طراحی.
-
معکوس:تولید نمودارها از کد موجود برای کمک به یک توسعهدهنده جدید در درک ماژول پیچیده قدیمی، یا برای دیداری کردن تأثیر یک تلاش بازسازی. مدلسازی یک فعالیت مداوم است، نه یک شرط پیشنیاز.
-
احلام: نمودارهای UML خیلی سخت برای نگهداری هستند
تیمها نگران هستند که با تغییرات سریع کد، نمودارهای مربوط به UML به سرعت بهروز نخواهند ماند، که باعث میشود به بدهی فنی تبدیل شوند.
-
واقعیت: نگهداری با اتوماسیون سادهتر میشود.روشهای مدرن تولید نمودار را در فرآیند ساخت ادغام میکنند.ابزارها میتوانند به صورت خودکار نمودارهای کلاس و توالی را بر اساس آخرین پایگاه کد بهروزرسانی کنند. علاوه بر این، تیمهای آگیل فقط نمودارها را برای بخشهای بسیار حیاتی یا ناپایدار معماری نگهداری میکنند، مدلهای کماهمیت را به طور طبیعی فاسد شدن بگذارند.
احلام: UML فقط برایبرنامهنویسی شیءگرا (OOP)
چون UML توسط «سه دوست» که بر روی OOP تمرکز داشتند، حمایت میشد،بسیاری معتقدند که برای عملکردی،میکروسرویس،یا معماریهای مبتنی بر رویداد بیاهمیت است.
-
واقعیت: UML یک زبان مدلسازی عمومی است.
-
میکروسرویسها:ازنمودارهای مؤلفهبرای نقشهبرداری مرزهای سرویس و وابستگیها،ونمودارهای نصببرای دیداری کردن هماهنگی کانتینرها.
-
پیشبرد رویدادها: استفاده کنید نمودارهای فعالیت برای مدلسازی جریان رویدادها بین سرویسهای مختلف یانمودارهای توالی برای ردیابی مسیر یک رویداد.
-
احلام: UML خلاقیت را از بین میبرد
برخی توسعهدهندگان احساس میکنند که پایبندی سختگیرانه به یک مدل راهحلهای کدنویسی نوآورانه را محدود میکند و اجبار به یکدستی را ایجاد میکند.
-
واقعیت: UML فکر را استاندارد میکند، ایدهها را ممنوع نمیکند. آن به عنوان یک تابلوی مشترک عمل میکند، امکاندهنده آن است که معماران و توسعهدهندگان بتوانند بررسی کنند چندین گزینه طراحی را به صورت بصری قبل از اقدام به کدنویسی بررسی کنند. آن موجب بیان واضح محدودیتها و اهداف میشود، که اغلب منجر به بیشتر راهحلهای زیباتر و خلاقانهتر میشود.
احلام: UML ارتباط طبیعی (تبلوی سفید) را جایگزین میکند
برخی میگویند تبلوی سفید سریعتر و پویاتر از UML رسمی است.
-
واقعیت: UML ارتباط را استاندارد میکندپس ازجلسه تبلوی سفید. هرچند جلسه تبلوی سفید بدون محدودیت برای ایدهپردازی عالی است، طرحهای نهایی اغلب مبهم هستند. تبدیل آن طرح به یک نمودار UML ساده، نمودار استاندارد UML (مثلاًمثلاً یک آرایه بیاشتباه ایجاد میکند که قابل به اشتراک گذاشتن است، بررسی شود، و برای مراجعه آینده حفظ شود.
احلام: UML فقط برای سیستمهای سطح سازمانی است
انگاره این است که فقط سیستمهای بزرگ، سیستمهای پیچیده (مانند بانکداری یا فضایی) ارزش تلاش برای مدلسازی را دارند.
-
واقعیت: UML بهطور کامل برای پروژههای کوچک قابل تناسب است.حتی یک تیم استارتآپ که یک اپلیکیشن موبایل ساده ساخته، از یکنمودار موارد مورد استفاده برای تعیین حوزه ویژگیها یا یکنمودار توالیبرای توضیح جریان پیچیده احراز هویت. ارزش ارتباط واضح، جهانی است، بسته به اندازه پروژه نیست.
احلام: کد تنها منبع واقعی حقیقت است
باور این است که صرف زمان بر روی نمودارها بیفایده است، چون کد تعریف نهایی سیستم است.
-
واقعیت: کد،اجراییحقیقت؛ UMLمعماریحقیقت است.کد نشان میدهدچگونهسیستم به صورت خط به خط کار میکند. یک نمودار UML نشان میدهدچرااینگونه ساختار یافته است وچهقصد طراحی سطح بالا بوده است. هنگامی که یک معمار سیستم را بررسی میکند، به قصد طراحی (UML) نگاه میکند، نه به ۱۰۰،۰۰۰ خط کد.
احلام: UML فناوری منسوخ شدهای است
با توجه به سن آن، برخی فرض میکنند UML توسط روشهای جدیدتر و مدرنتر مدلسازی جایگزین شده است.
-
واقعیت: UML یک استاندارد در حال توسعه مداوم است. توسط گروه مدیریت شیء (OMG)، UML مواجه با چندین بازنگری اصلی شده است (تا به اینجا UML 2.5). این بهروزرسانیها ویژگیهایی را برای مدلسازی مفاهیم مدرن مانند خدمات، مؤلفهها و الگوهای پیچیده همگامسازی به خود گرفتهاند، که اطمینان حاصل میکند که این ابزار همچنان زبان مشترک طراحی نرمافزار باقی بماند.
با از بین بردن این اشتباهات، تیمهای توسعه مدرن میتوانند UML را به عنوان ابزاری قدرتمند، انعطافپذیر و ضروری برای دستیابی به شفافیت معماری، بهبود ارتباط تیم و ساخت سیستمهای نرمافزاری قوی و به خوبی درک شده بازیابی کنند.
اطلاعات بیشتر در مورد UML بگیرید و با مراجعه به مرکز منابع UML.
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Ру́сский, Việt Nam, 简体中文 and 繁體中文.