زبان توصیف معماری

زبان‌های توصیف معماری (Architecture Description Languages یا ADLs) در چندین حوزه مورد استفاده قرار می‌گیرند: مهندسی سیستم، مهندسی نرم‌افزار، و مدل‌سازی و مهندسی سازمان.

جامعه مهندسی سیستم از یک زبان توصیف معماری به‌عنوان یک زبان یا یک مدل مفهومی برای توصیف و نمایش معماری سیستم‌ها استفاده می‌کند.

جامعه مهندسی نرم‌افزار از یک زبان توصیف معماری به‌عنوان یک زبان کامپیوتری برای ایجاد توصیفی از یک معماری نرم‌افزاری بهره می‌برد. در مورد آنچه به عنوان معماری فنی شناخته می‌شود، معماری باید برای توسعه‌دهندگان نرم‌افزار منتقل شود؛ یک معماری عملکردی به ذینفعان و کاربران مختلف منتقل می‌شود.

برخی از زبان‌های توصیف معماری که توسعه یافته‌اند عبارت‌اند از:

- Acme (توسعه‌یافته توسط دانشگاه Carnegie Mellon - CMU)

- AADL (استانداردشده توسط SAE)

- C2 (توسعه‌یافته توسط دانشگاه کالیفرنیا، ایرواین - UCI)

- SBC-ADL (توسعه‌یافته توسط دانشگاه ملی Sun Yat-Sen)

- Darwin (توسعه‌یافته توسط کالج امپریال لندن)

- Wright (توسعه‌یافته توسط CMU).

نمای کلی

سند ISO/IEC/IEEE 42010 با عنوان «مهندسی سیستم‌ها و نرم‌افزار—توصیف معماری»، یک زبان توصیف معماری را به‌عنوان «هر نوع شکلی از بیان که در توصیف معماری به کار می‌رود» تعریف کرده و حداقل الزامات مربوط به زبان‌های توصیف معماری (ADLها) را مشخص می‌کند.

جامعه مدل‌سازی و مهندسی سازمانی نیز زبان‌های توصیف معماری را برای استفاده در سطح سازمان توسعه داده است. از جمله این زبان‌ها می‌توان به ArchiMate (اکنون به‌عنوان استانداردی از گروه Open Group), DEMO و ABACUS (توسعه‌یافته توسط دانشگاه فناوری سیدنی) اشاره کرد. این زبان‌ها معمولاً به اجزای نرم‌افزاری اشاره ندارند، اما اکثر آن‌ها معماری برنامه‌ای را به‌عنوان معماری‌ای که به مهندسان نرم‌افزار منتقل می‌شود، در نظر می‌گیرند.

بخش عمده‌ای از مطالب ارائه‌شده در ادامه، به دیدگاه جامعه مهندسی نرم‌افزار می‌پردازد.

یک نشانه‌گذاری استاندارد برای نمایش معماری‌ها به برقراری ارتباط متقابل، مستندسازی تصمیمات اولیه طراحی، و ایجاد یک انتزاع قابل‌انتقال از سیستم کمک می‌کند. در گذشته، معماری‌ها بیشتر از طریق نقشه‌های خطوط و جعبه نمایش داده می‌شدند که با عناصری مانند نوع اجزا، ویژگی‌ها، معانی اتصالات و رفتار کلی سیستم همراه بودند. زبان‌های توصیف معماری (ADLها) نتیجه رویکردی زبانی برای نمایش رسمی معماری‌ها هستند و به همین دلیل، کاستی‌های روش‌های قبلی را برطرف می‌کنند. همچنین، ADLهای پیشرفته امکان تحلیل اولیه و ارزیابی عملی بودن تصمیمات طراحی معماری را فراهم می‌کنند.

تاریخچه

زبان‌های توصیف معماری (ADLs) به سه دسته کلی تقسیم‌بندی شده‌اند:

1. نقشه‌های غیررسمی از نوع جعبه و خط
2. زبان‌های رسمی توصیف معماری
3. نمادهایی مبتنی بر UML (Unified Modeling Language).

دسته‌بندی نقشه‌های جعبه و خط (Box-and-line)

برای مدت طولانی، نقشه‌های جعبه و خط یکی از رایج‌ترین روش‌ها برای توصیف معماری‌های نرم‌افزاری بودند. اگرچه این روش مستندسازی مفیدی ارائه می‌داد، اما سطح غیررسمی بودن آن باعث محدود شدن کاربرد توصیف معماری می‌شد. به همین دلیل، نیاز به روشی دقیق‌تر برای توصیف معماری‌های نرم‌افزاری احساس می‌شد.

به نقل از الن و گارلان (۱۹۹۷): «هرچند این توصیفات ممکن است اسناد مفیدی فراهم کنند، اما سطح غیررسمی بودن آن‌ها کاربردشان را محدود می‌کند. از آنجا که اغلب مشخص نیست چنین توصیفاتی دقیقاً چه معنایی دارند، ممکن است تحلیل معماری برای سازگاری یا تعیین ویژگی‌های غیر بدیهی آن غیرممکن باشد. علاوه بر این، هیچ راهی برای بررسی تطابق اجرای سیستم با طراحی معماری وجود ندارد.»

پری و ولف (۱۹۹۲) نیز به نتیجه مشابهی دست یافته‌اند و اشاره می‌کنند: «علاوه بر ارائه اسناد واضح و دقیق، هدف اصلی مشخصات، فراهم کردن تحلیل خودکار و شناسایی مشکلاتی است که در غیر این صورت شناسایی نمی‌شدند.» پس از این، رشته‌ای از پژوهش‌ها در مورد زبان‌های رسمی برای توصیف معماری‌های نرم‌افزاری انجام شد. ده‌ها ADL رسمی پیشنهاد شده است که هر کدام ویژگی‌های مفهومی، نحو یا معناشناسی متفاوتی دارند و روی یک حوزه عملیاتی خاص تمرکز کرده یا فقط برای تکنیک‌های تحلیل متفاوت مناسب هستند. به‌عنوان مثال:

• زبان‌های خاص دامنه برای سیستم‌های تعبیه‌شده و بلادرنگ (مانند AADL, EAST-ADL، و EADL)
• برنامه‌های کنترلی (مانند DiaSpec)
• معماری‌های مبتنی بر خط تولید (مانند Koala)
• سیستم‌های پویا (مانند Π-ADL).

زبان‌های خاص تحلیل نیز برای جنبه‌هایی مانند دسترس‌پذیری، اطمینان‌پذیری، امنیت، مصرف منابع، کیفیت داده و عملکرد بلادرنگ طراحی شده‌اند.

چالش‌های پذیرش صنعتی

با این وجود، تلاش‌ها برای پذیرش صنعتی این زبان‌ها به موفقیت مورد انتظار نرسید. برخی از دلایل این امر عبارت‌اند از:

• عدم یکپارچگی ADLها در چرخه عمر نرم‌افزار
• پشتیبانی ضعیف ابزارهای پیشرفته
• مستندات محدود
• تمرکز بر نیازهای بسیار خاص
• نبود فضای کافی برای گسترش ویژگی‌های جدید

برای غلبه بر این محدودیت‌ها، UML به‌عنوان جایگزینی برای ADLهای موجود مطرح شده است. پیشنهادهای زیادی برای استفاده یا گسترش UML جهت مدل‌سازی مناسب‌تر معماری‌های نرم‌افزاری ارائه شده است.

مطالعه‌ای در سال 2013 نشان داد که متخصصان عموماً از قابلیت‌های طراحی ADLها رضایت داشتند، اما نگرانی‌هایی در مورد آن‌ها داشتند:

• کمبود امکانات تحلیل و تعریف ویژگی‌های غیرعملکردی
• عدم رسمیت کافی
• پیچیدگی و نیاز به بهبود در قابلیت استفاده.

ویژگی‌ها

زبان‌های توصیف معماری (ADL) از تنوع بسیار بالایی برخوردارند و توسط گروه‌های دانشگاهی یا صنعتی توسعه یافته‌اند. بسیاری از این زبان‌ها در ابتدا با هدف ADL طراحی نشده بودند، اما به مرور مشخص شد که برای نمایش و تحلیل معماری مناسب‌اند.

ADLها از زبان‌های مرتبط دیگر متمایز هستند:

• از زبان‌های نیازمندی متمایزند، زیرا ریشه در فضای راه‌حل (solution space) دارند، در حالی که نیازمندی‌ها به فضای مسئله مربوط می‌شوند.
• از زبان‌های برنامه‌نویسی متمایزند، زیرا معماری‌ها را به راه‌حل‌های خاص محدود نمی‌کنند.
• از زبان‌های مدل‌سازی متفاوت‌اند، زیرا تمرکز ADLها بر نمایش اجزا است، در حالی که زبان‌های مدل‌سازی رفتار را توصیف می‌کنند.

الزامات حداقلی

یک زبان باید شرایط زیر را داشته باشد:

1. مناسب برای انتقال معماری به تمام ذی‌نفعان باشد.
2. از وظایف ایجاد، اصلاح، و اعتبارسنجی معماری پشتیبانی کند.
3. مبنایی برای اجرای سیستم فراهم آورد و امکان افزودن جزئیات به مشخصات ADL برای استخراج مشخصات نهایی سیستم را فراهم کند.
4. قابلیت نمایش سبک‌های رایج معماری را داشته باشد.
5. تحلیل معماری یا تولید سریع نمونه‌های اولیه را پشتیبانی کند.

ویژگی‌های مشترک ADLها

• ترکیب نمادهای گرافیکی و فرم متنی با نحو و معناشناسی رسمی.
• امکاناتی برای مدل‌سازی سیستم‌های توزیع‌شده.
• پشتیبانی محدود از مستندسازی طراحی.
• توانایی نمایش سطوح سلسله‌مراتبی جزئیات، از جمله ایجاد ساختارهای فرعی از طریق نمونه‌سازی الگوها.

تفاوت‌های ADLها

• توانایی برخورد با ساختارهای بلادرنگ، مانند ضرب‌الاجل‌ها و اولویت‌بندی وظایف.
• پشتیبانی از سبک‌های مختلف معماری (محدودیت در مدیریت معماری‌های شیءگرا یا پویا).
• توانایی تحلیل معماری.
• مدیریت نمونه‌های مختلف یک معماری خاص در زمینه معماری‌های مبتنی بر خط تولید.

نقاط قوت ADL

1. راهی رسمی برای نمایش معماری ارائه می‌دهند.
2. هم برای انسان و هم برای ماشین قابل درک هستند.
3. امکان توصیف سیستم در سطحی بالاتر از روش‌های قبلی را فراهم می‌کنند.
4. امکان تحلیل و ارزیابی معماری برای کامل بودن، سازگاری، ابهام، و عملکرد را می‌دهند.
5. از تولید خودکار سیستم‌های نرم‌افزاری پشتیبانی می‌کنند.

نقاط ضعف ADL

1. اجماع جهانی در مورد آنچه باید نمایش دهند وجود ندارد، به‌ویژه در رابطه با رفتار معماری.
2. نمایش‌های موجود به سختی قابل تفسیر هستند و توسط ابزارهای تجاری پشتیبانی نمی‌شوند.
3. بیشتر ADLها بسیار بهینه‌سازی‌شده برای یک نوع تحلیل خاص هستند.

معماری در مقابل طراحی

در زمینه سیستم‌های نرم‌افزاری، معماری به‌طور کلی به دسته‌های مختلفی تقسیم می‌شود که شامل معماری نرم‌افزار، معماری شبکه و معماری سیستم‌ها می‌شود. در هر یک از این دسته‌ها، تمایز واضح و دقیقی بین معماری و طراحی وجود ندارد، و این دو اغلب به‌طور مبهم از یکدیگر تفکیک می‌شوند. برای ایجاد تمایز میان آن‌ها، بهتر است که طراحی را به عنوان یک اسم در نظر بگیریم تا مقایسه‌ای میان دو اسم به جای دو فعل صورت گیرد.

• طراحی به انتزاع و مشخص کردن الگوها و اجزای عملکردی اطلاق می‌شود که قبلاً پیاده‌سازی شده‌اند یا قرار است در آینده پیاده‌سازی شوند.
• معماری سطحی بالاتر از انتزاع دارد و دقت کمتری در جزئیات می‌طلبد. از نظر ماهیت، معماری بیشتر به ساختار کلی و روابط بین اجزای مختلف سیستم می‌پردازد، در حالی که طراحی به جزئیات و نحوه پیاده‌سازی دقیق‌تر این اجزا تمرکز دارد.

تفاوت‌های اصلی

1. معماری به تقسیم‌بندی عملکردها به اجزای اصلی و بزرگ‌تر، محل استقرار فیزیکی یا مجازی این اجزا، استفاده از اجزای آماده یا استاندارد، تعیین رابط‌های مورد نیاز بین اجزا و انتخاب پروتکل‌های ارتباطی برای آن‌ها، و در نهایت استفاده از الگوها و شیوه‌های کلی برای تحقق اهدافی مانند گسترش‌پذیری، پایداری، مقیاس‌پذیری و دیگر ویژگی‌های غیرعملکردی می‌پردازد.
2. طراحی در واقع همین انتخاب‌ها را با دقت بیشتری مشخص می‌کند و توضیح می‌دهد که چگونه نیازهای عملکردی به اجزای کوچک‌تر تفویض خواهند شد و این اجزا به‌طور دقیق‌تر چگونه در ساختار کلی سازمان‌دهی می‌شوند.

فرایند شکل‌گیری معماری و طراحی

• معماری معمولاً در مراحل اولیه مفهوم‌سازی یک برنامه، سیستم یا شبکه انجام می‌شود و می‌تواند به شکل بخش‌هایی از مستندات نیازمندی‌های غیرعملکردی ظاهر گردد.
• در حالی که طراحی معمولاً تحت تأثیر نیازمندی‌ها قرار می‌گیرد و به‌طور مستقیم از آن‌ها هدایت می‌شود. طراحی معمولاً در مستندات نیازمندی‌ها به وضوح مشخص نمی‌شود.

فرایند تعریف معماری ممکن است شامل استفاده از اصول اکتشافی باشد که معمار یا تیم معماری از تجربیات خود در حوزه مربوطه به دست آورده‌اند. مشابه طراحی، معماری نیز اغلب از طریق مجموعه‌ای از تکرارها و بازبینی‌ها تکامل می‌یابد. همان‌طور که اثربخشی طراحی در هنگام پیاده‌سازی و اجرای جزئیات آزمایش می‌شود، اثربخشی معماری نیز در حین تدوین طراحی‌های سطح بالاتر ارزیابی می‌شود. اگر این اثربخشی زیر سؤال برود، ممکن است نیاز به تکرار و بازنگری در معماری یا طراحی ایجاد شود.

تمایز اصلی بین معماری و طراحی به سطح انتزاع و جزئیات و همچنین ترتیب زمانی آن‌ها مربوط می‌شود. به‌طور کلی، معماری قبل از طراحی انجام می‌شود، گرچه هم‌پوشانی و تکرار چرخه‌ای این دو فرایند رایج است.

نمونه‌ها

• ArchiMate
• Architecture Analysis & Design Language
• C4 model (software)
• Darwin (ADL)
• EAST-ADL
• Wright (ADL)