موضوع مقاله: زبان توصیف معماری | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # زبان توصیف معماری | مقدمه: جامعه مهندسی سیستم از یک زبان توصیف معماری به‌عنوان یک زبان یا یک مدل مفهومی برای توصیف و نمایش معماری سیستم‌ها استفاده می‌کند. | ## بخش 1: زبان توصیف معماری | جامعه مهندسی نرم‌افزار از یک زبان توصیف معماری به‌عنوان یک زبان کامپیوتری برای ایجاد توصیفی از یک معماری نرم‌افزاری بهره می‌برد. در مورد آنچه به عنوان معماری فنی شناخته می‌شود، معماری باید برای توسعه‌دهندگان نرم‌افزار منتقل شود؛ یک معماری عملکردی به ذینفعان و کاربران مختلف منتقل می‌شود. نمای کلی سند ISO/IEC/IEEE 42010 با عنوان «مهندسی سیستم‌ها و نرم‌افزار—توصیف معماری»، یک زبان توصیف معماری را به‌عنوان «هر نوع شکلی از بیان که در توصیف معماری به کار می‌رود» تعریف کرده و حداقل الزامات مربوط به زبان‌های توصیف معماری (ADLها) را مشخص می‌کند. جامعه مدل‌سازی و مهندسی سازمانی نیز زبان‌های توصیف معماری را برای استفاده در سطح سازمان توسعه داده است. این زبان‌ها معمولاً به اجزای نرم‌افزاری اشاره ندارند، اما اکثر آن‌ها معماری برنامه‌ای را به‌عنوان معماری‌ای که به مهندسان نرم‌افزار منتقل می‌شود، در نظر می‌گیرند. بخش عمده‌ای از مطالب ارائه‌شده در ادامه، به دیدگاه جامعه مهندسی نرم‌افزار می‌پردازد. یک نشانه‌گذاری استاندارد برای نمایش معماری‌ها به برقراری ارتباط متقابل، مستندسازی تصمیمات اولیه طراحی، و ایجاد یک انتزاع قابل‌انتقال از سیستم کمک می‌کند. در گذشته، معماری‌ها بیشتر از طریق نقشه‌های خطوط و جعبه نمایش داده می‌شدند که با عناصری مانند نوع اجزا، ویژگی‌ها، معانی اتصالات و رفتار کلی سیستم همراه بودند. زبان‌های توصیف معماری (ADLها) نتیجه رویکردی زبانی برای نمایش رسمی معماری‌ها هستند و به همین دلیل، کاستی‌های روش‌های قبلی را برطرف می‌کنند. همچنین، ADLهای پیشرفته امکان تحلیل اولیه و ارزیابی عملی بودن تصمیمات طراحی معماری را فراهم می‌کنند. دسته‌بندی نقشه‌های جعبه و خط (Box-and-line) برای مدت طولانی، نقشه‌های جعبه و خط یکی از رایج‌ترین روش‌ها برای توصیف معماری‌های نرم‌افزاری بودند. اگرچه این روش مستندسازی مفیدی ارائه می‌داد، اما سطح غیررسمی بودن آن باعث محدود شدن کاربرد توصیف معماری می‌شد. به همین دلیل، نیاز به روشی دقیق‌تر برای توصیف معماری‌های نرم‌افزاری احساس می‌شد. به نقل از الن و گارلان (۱۹۹۷): «هرچند این توصیفات ممکن است اسناد مفیدی فراهم کنند، اما سطح غیررسمی بودن آن‌ها کاربردشان را محدود می‌کند. از آنجا که اغلب مشخص نیست چنین توصیفاتی دقیقاً چه معنایی دارند، ممکن است تحلیل معماری برای سازگاری یا تعیین ویژگی‌های غیر بدیهی آن غیرممکن باشد. علاوه بر این، هیچ راهی برای بررسی تطابق اجرای سیستم با طراحی معماری وجود ندارد.» پری و ولف (۱۹۹۲) نیز به نتیجه مشابهی دست یافته‌اند و اشاره می‌کنند: «علاوه بر ارائه اسناد واضح و دقیق، هدف اصلی مشخصات، فراهم کردن تحلیل خودکار و شناسایی مشکلاتی است که در غیر این صورت شناسایی نمی‌شدند.» پس از این، رشته‌ای از پژوهش‌ها در مورد زبان‌های رسمی برای توصیف معماری‌های نرم‌افزاری انجام شد. | ## بخش 2: زبان توصیف معماری | ده‌ها ADL رسمی پیشنهاد شده است که هر کدام ویژگی‌های مفهومی، نحو یا معناشناسی متفاوتی دارند و روی یک حوزه عملیاتی خاص تمرکز کرده یا فقط برای تکنیک‌های تحلیل متفاوت مناسب هستند. چالش‌های پذیرش صنعتی با این وجود، تلاش‌ها برای پذیرش صنعتی این زبان‌ها به موفقیت مورد انتظار نرسید. برخی از دلایل این امر عبارت‌اند از: عدم یکپارچگی ADLها در چرخه عمر نرم‌افزار پشتیبانی ضعیف ابزارهای پیشرفته مستندات محدود تمرکز بر نیازهای بسیار خاص نبود فضای کافی برای گسترش ویژگی‌های جدید برای غلبه بر این محدودیت‌ها، UML به‌عنوان جایگزینی برای ADLهای موجود مطرح شده است. پیشنهادهای زیادی برای استفاده یا گسترش UML جهت مدل‌سازی مناسب‌تر معماری‌های نرم‌افزاری ارائه شده است. مطالعه‌ای در سال 2013 نشان داد که متخصصان عموماً از قابلیت‌های طراحی ADLها رضایت داشتند، اما نگرانی‌هایی در مورد آن‌ها داشتند: کمبود امکانات تحلیل و تعریف ویژگی‌های غیرعملکردی عدم رسمیت کافی پیچیدگی و نیاز به بهبود در قابلیت استفاده. ویژگی‌ها زبان‌های توصیف معماری (ADL) از تنوع بسیار بالایی برخوردارند و توسط گروه‌های دانشگاهی یا صنعتی توسعه یافته‌اند. بسیاری از این زبان‌ها در ابتدا با هدف ADL طراحی نشده بودند، اما به مرور مشخص شد که برای نمایش و تحلیل معماری مناسب‌اند. از زبان‌های برنامه‌نویسی متمایزند، زیرا معماری‌ها را به راه‌حل‌های خاص محدود نمی‌کنند. از زبان‌های مدل‌سازی متفاوت‌اند، زیرا تمرکز ADLها بر نمایش اجزا است، در حالی که زبان‌های مدل‌سازی رفتار را توصیف می‌کنند. الزامات حداقلی یک زبان باید شرایط زیر را داشته باشد: مناسب برای انتقال معماری به تمام ذی‌نفعان باشد. مبنایی برای اجرای سیستم فراهم آورد و امکان افزودن جزئیات به مشخصات ADL برای استخراج مشخصات نهایی سیستم را فراهم کند. توانایی نمایش سطوح سلسله‌مراتبی جزئیات، از جمله ایجاد ساختارهای فرعی از طریق نمونه‌سازی الگوها. تفاوت‌های ADLها توانایی برخورد با ساختارهای بلادرنگ، مانند ضرب‌الاجل‌ها و اولویت‌بندی وظایف. امکان تحلیل و ارزیابی معماری برای کامل بودن، سازگاری، ابهام، و عملکرد را می‌دهند. نقاط ضعف ADL اجماع جهانی در مورد آنچه باید نمایش دهند وجود ندارد، به‌ویژه در رابطه با رفتار معماری. نمایش‌های موجود به سختی قابل تفسیر هستند و توسط ابزارهای تجاری پشتیبانی نمی‌شوند. | ## بخش 3: زبان توصیف معماری | معماری در مقابل طراحی در زمینه سیستم‌های نرم‌افزاری، معماری به‌طور کلی به دسته‌های مختلفی تقسیم می‌شود که شامل معماری نرم‌افزار، معماری شبکه و معماری سیستم‌ها می‌شود. در هر یک از این دسته‌ها، تمایز واضح و دقیقی بین معماری و طراحی وجود ندارد، و این دو اغلب به‌طور مبهم از یکدیگر تفکیک می‌شوند. برای ایجاد تمایز میان آن‌ها، بهتر است که طراحی را به عنوان یک اسم در نظر بگیریم تا مقایسه‌ای میان دو اسم به جای دو فعل صورت گیرد. طراحی به انتزاع و مشخص کردن الگوها و اجزای عملکردی اطلاق می‌شود که قبلاً پیاده‌سازی شده‌اند یا قرار است در آینده پیاده‌سازی شوند. از نظر ماهیت، معماری بیشتر به ساختار کلی و روابط بین اجزای مختلف سیستم می‌پردازد، در حالی که طراحی به جزئیات و نحوه پیاده‌سازی دقیق‌تر این اجزا تمرکز دارد. تفاوت‌های اصلی معماری به تقسیم‌بندی عملکردها به اجزای اصلی و بزرگ‌تر، محل استقرار فیزیکی یا مجازی این اجزا، استفاده از اجزای آماده یا استاندارد، تعیین رابط‌های مورد نیاز بین اجزا و انتخاب پروتکل‌های ارتباطی برای آن‌ها، و در نهایت استفاده از الگوها و شیوه‌های کلی برای تحقق اهدافی مانند گسترش‌پذیری، پایداری، مقیاس‌پذیری و دیگر ویژگی‌های غیرعملکردی می‌پردازد. طراحی در واقع همین انتخاب‌ها را با دقت بیشتری مشخص می‌کند و توضیح می‌دهد که چگونه نیازهای عملکردی به اجزای کوچک‌تر تفویض خواهند شد و این اجزا به‌طور دقیق‌تر چگونه در ساختار کلی سازمان‌دهی می‌شوند. فرایند شکل‌گیری معماری و طراحی معماری معمولاً در مراحل اولیه مفهوم‌سازی یک برنامه، سیستم یا شبکه انجام می‌شود و می‌تواند به شکل بخش‌هایی از مستندات نیازمندی‌های غیرعملکردی ظاهر گردد. در حالی که طراحی معمولاً تحت تأثیر نیازمندی‌ها قرار می‌گیرد و به‌طور مستقیم از آن‌ها هدایت می‌شود. فرایند تعریف معماری ممکن است شامل استفاده از اصول اکتشافی باشد که معمار یا تیم معماری از تجربیات خود در حوزه مربوطه به دست آورده‌اند. مشابه طراحی، معماری نیز اغلب از طریق مجموعه‌ای از تکرارها و بازبینی‌ها تکامل می‌یابد. همان‌طور که اثربخشی طراحی در هنگام پیاده‌سازی و اجرای جزئیات آزمایش می‌شود، اثربخشی معماری نیز در حین تدوین طراحی‌های سطح بالاتر ارزیابی می‌شود. اگر این اثربخشی زیر سؤال برود، ممکن است نیاز به تکرار و بازنگری در معماری یا طراحی ایجاد شود. تمایز اصلی بین معماری و طراحی به سطح انتزاع و جزئیات و همچنین ترتیب زمانی آن‌ها مربوط می‌شود. | ## جمع‌بندی | به‌طور کلی، معماری قبل از طراحی انجام می‌شود، گرچه هم‌پوشانی و تکرار چرخه‌ای این دو فرایند رایج است.