Eclipse به عنوان یک پلت فرم فناوری برای 1C: ابزارهای توسعه سازمانی

شاید، تحت الشعاع قرار دادن مدتهاست که نیازی به معرفی خاصی ندارد. بسیاری از مردم به لطف ابزارهای توسعه جاوا Eclipse با Eclipse آشنا هستند (JDT). این IDE منبع باز محبوب جاوا است که اکثر توسعه دهندگان آن را با کلمه "Eclipse" مرتبط می کنند. با این حال، Eclipse هم یک پلت فرم توسعه پذیر برای یکپارچه سازی ابزارهای توسعه (Eclipse Platform) و هم تعدادی از IDE های ساخته شده بر اساس آن، از جمله JDT است. Eclipse هم پروژه Eclipse است، پروژه سطح بالایی که توسعه پلتفرم Eclipse و JDT را هماهنگ می کند، و هم Eclipse SDK، نتیجه ارائه شده از آن توسعه. در نهایت، Eclipse یک بنیاد منبع باز با جامعه عظیمی از پروژه ها است، که همه آنها به زبان جاوا یا مربوط به ابزارهای توسعه (مثلاً پروژه ها) نیستند. Eclipse IoT и علم کسوف). دنیای Eclipse بسیار متنوع است.

در این مقاله که ماهیت اجمالی دارد، سعی خواهیم کرد به برخی از اصول معماری Eclipse به عنوان بستری برای ساخت ابزارهای توسعه یکپارچه نگاهی بیندازیم و ایده اولیه ای از اجزای Eclipse که پایه و اساس این فناوری را تشکیل می دهند ارائه دهیم. پلت فرم برای "Configurator جدید" 1C: Enterprise. 1C: ابزارهای توسعه سازمانی. البته، چنین بررسی ناگزیر تا حد زیادی سطحی و نسبتاً محدود خواهد بود، از جمله به این دلیل که ما نه تنها بر روی توسعه دهندگان Eclipse به عنوان مخاطبان هدف تمرکز می کنیم. با این حال، ما امیدواریم که حتی توسعه دهندگان با تجربه Eclipse نیز بتوانند اطلاعات جالبی را در مقاله بیابند. به عنوان مثال، ما در مورد یکی از "رازهای کسوف" صحبت خواهیم کرد، یک پروژه نسبتا جدید و کمتر شناخته شده. Eclipse Handly، که توسط 1C تاسیس و پشتیبانی می شود.

مقدمه ای بر معماری Eclipse

اجازه دهید ابتدا به برخی از جنبه های کلی معماری Eclipse با استفاده از مثال نگاه کنیم ابزارهای توسعه جاوا Eclipse (JDT). انتخاب JDT به عنوان نمونه تصادفی نیست. این اولین محیط توسعه یکپارچه است که در Eclipse ظاهر می شود. سایر پروژه های *DT Eclipse، مانند Eclipse C/C++ Development Tooling (CDT)، بعدها ایجاد شدند و هم اصول اولیه معماری و هم قطعات کد منبع فردی را از JDT به عاریت گرفتند. اصول معماری تعیین شده در JDT تا به امروز برای تقریباً هر IDE ساخته شده در بالای پلتفرم Eclipse، از جمله 1C: Enterprise Development Tools مرتبط است.

اول از همه، لازم به ذکر است که Eclipse با یک لایه بندی معماری نسبتاً واضح مشخص می شود، با جداسازی عملکرد مستقل از زبان از عملکرد طراحی شده برای پشتیبانی از زبان های برنامه نویسی خاص، و جداسازی اجزای "هسته" مستقل از UI از اجزای مرتبط. با پشتیبانی از رابط کاربری

بنابراین، پلتفرم Eclipse یک زیرساخت مشترک و مستقل از زبان تعریف می‌کند و ابزارهای توسعه جاوا یک Java IDE با ویژگی‌های کامل را به Eclipse اضافه می‌کنند. هر دو پلتفرم Eclipse و JDT از چندین مؤلفه تشکیل شده‌اند که هر کدام به یک «هسته» مستقل از رابط کاربری یا یک لایه رابط کاربری تعلق دارند (شکل 1).

برنج. 1. Eclipse Platform و JDT

بیایید اجزای اصلی پلتفرم Eclipse را فهرست کنیم:

• زمان اجرا - زیرساخت پلاگین را تعریف می کند. Eclipse با معماری مدولار مشخص می شود. در اصل، Eclipse مجموعه ای از "نقاط گسترش" و "extensions" است.
• فضای کاری - یک یا چند پروژه را مدیریت می کند. یک پروژه شامل پوشه ها و فایل هایی است که مستقیماً به سیستم فایل نگاشت می شوند.
• ابزارک ابزار استاندارد (SWT) - عناصر اساسی رابط کاربری را با سیستم عامل یکپارچه فراهم می کند.
• جی فیس - تعدادی چارچوب UI که بر روی SWT ساخته شده اند را ارائه می دهد.
• میز کار مکانیکی و نجاری و غیره - پارادایم Eclipse UI را تعریف می کند: ویرایشگرها، نماها، دیدگاه ها.

باید گفت که پلتفرم Eclipse همچنین بسیاری از اجزای مفید دیگر را برای ساخت ابزارهای توسعه یکپارچه از جمله Debug، Compare، Search و Team فراهم می کند. باید به JFace Text اشاره ویژه ای کرد - مبنایی برای ایجاد "ویرایشگرهای هوشمند" کد منبع. متأسفانه، حتی یک بررسی گذرا از این مؤلفه‌ها و همچنین مؤلفه‌های لایه رابط کاربری در محدوده این مقاله امکان‌پذیر نیست، بنابراین در ادامه این بخش به مروری بر مؤلفه‌های اصلی «هسته» محدود می‌شویم. Eclipse Platform و JDT.

زمان اجرا هسته

زیرساخت پلاگین Eclipse بر اساس OSGi و توسط پروژه ارائه شده است Eclipse Equinox. هر پلاگین Eclipse یک بسته نرم افزاری OSGi است. مشخصات OSGi، به‌ویژه، مکانیسم‌هایی را برای نسخه‌سازی و تفکیک وابستگی تعریف می‌کند. علاوه بر این مکانیسم های استاندارد، Equinox این مفهوم را معرفی می کند نقاط گسترش. هر افزونه می تواند نقاط افزونه خود را تعریف کند و همچنین با استفاده از نقاط افزونه تعریف شده توسط همان پلاگین یا سایر پلاگین ها، قابلیت های اضافی ("افزونه ها") را به سیستم معرفی کند. هر گونه توضیح دقیق از مکانیسم های OSGi و Equinox خارج از محدوده این مقاله است. فقط توجه داشته باشیم که ماژولارسازی در Eclipse کامل است (هر زیر سیستمی، از جمله Runtime، از یک یا چند افزونه تشکیل شده است)، و تقریباً همه چیز در Eclipse یک افزونه است. علاوه بر این، این اصول مدت ها قبل از معرفی OSGi در معماری Eclipse تعبیه شده بود (در آن زمان آنها از فناوری خود استفاده می کردند، بسیار شبیه به OSGi).

فضای کار اصلی

تقریباً هر محیط توسعه یکپارچه ساخته شده در بالای پلتفرم Eclipse با فضای کاری Eclipse کار می کند. این فضای کاری است که معمولاً حاوی کد منبع برنامه توسعه یافته در IDE است. فضای کاری مستقیماً به سیستم فایل نگاشت می شود و شامل پروژه هایی است که حاوی پوشه ها و فایل ها هستند. این پروژه ها، پوشه ها و فایل ها نامیده می شوند منابع فضای کار پیاده‌سازی فضای کاری در Eclipse به عنوان یک حافظه پنهان در رابطه با سیستم فایل عمل می‌کند، که سرعت پیمایش درخت منبع را به میزان قابل توجهی ممکن می‌سازد. علاوه بر این، فضای کاری تعدادی خدمات اضافی از جمله مکانیسم اطلاع رسانی برای تغییرات منابع и زیرساخت های سازنده افزایشی.

مؤلفه Core Resources (افزونه org.eclipse.core.resources) مسئول پشتیبانی از فضای کاری و منابع آن است. به طور خاص، این مؤلفه دسترسی برنامه‌ای به فضای کاری در فرم را فراهم می‌کند مدل های منابع. برای کار موثر با این مدل، مشتریان به یک راه ساده برای ارائه پیوند به یک منبع نیاز دارند. در این مورد، مطلوب است که شیئی که مستقیماً وضعیت منبع را در مدل ذخیره می کند از دسترسی مشتری پنهان شود. در غیر این صورت، برای مثال، در مورد حذف یک فایل، کلاینت می‌تواند به نگه داشتن یک شی که دیگر در مدل نیست، با مشکلات بعدی ادامه دهد. Eclipse این مشکل را با استفاده از چیزی به نام حل می کند دسته منبع Handle به عنوان یک کلید عمل می کند (فقط مسیر منبع را در فضای کاری می داند) و دسترسی به شی مدل داخلی را که مستقیماً اطلاعات مربوط به وضعیت منبع را ذخیره می کند، کاملاً کنترل می کند. این طرح یک تنوع از الگو است دسته/بدنه.

برنج. شکل 2 اصطلاح Handle/Body را همانطور که در مدل منبع اعمال می شود نشان می دهد. رابط IResource نشان دهنده دسته یک منبع است و یک API است، بر خلاف کلاس Resource که این رابط را پیاده سازی می کند، و کلاس ResourceInfo که نشان دهنده بدنه است، که API نیستند. تاکید می کنیم که handle فقط مسیر منبع را نسبت به ریشه فضای کاری می داند و حاوی پیوندی به اطلاعات منبع نیست. اشیاء اطلاعات منبع به اصطلاح "درخت عنصر" را تشکیل می دهند. این ساختار داده به طور کامل در حافظه مادیت شده است. برای یافتن نمونه اطلاعات منبع مربوط به یک دسته، درخت عنصر مطابق مسیر ذخیره شده در آن دسته پیمایش می شود.

برنج. 2. IRResource و ResourceInfo

همانطور که بعدا خواهیم دید، طراحی اولیه مدل منبع (ممکن است آن را مبتنی بر دسته بنامیم) در Eclipse برای مدل‌های دیگر نیز استفاده می‌شود. در حال حاضر، اجازه دهید برخی از ویژگی های متمایز این طرح را فهرست کنیم:

• Handle یک شی ارزش است. اشیاء ارزشی اشیای تغییرناپذیری هستند که برابری آنها مبتنی بر هویت نیست. چنین اشیایی را می توان با خیال راحت به عنوان کلید در ظروف هش شده استفاده کرد. چندین نمونه از handle می توانند به یک منبع ارجاع دهند. برای مقایسه آنها باید از متد برابر (Object) استفاده کنید.
• Handle رفتار یک منبع را تعریف می کند، اما حاوی اطلاعاتی در مورد وضعیت منبع نیست (تنها داده ای که ذخیره می کند "کلید" است، مسیر دسترسی به منبع).
• Handle ممکن است به منبعی اشاره کند که وجود ندارد (یا منبعی که هنوز ایجاد نشده است یا منبعی که قبلاً حذف شده است). وجود یک منبع را می توان با استفاده از متد IResource.exists () بررسی کرد.
• برخی از عملیات ها را می توان تنها بر اساس اطلاعات ذخیره شده در خود دسته (به اصطلاح عملیات فقط دسته) پیاده سازی کرد. به عنوان مثال IResource.getParent()، getFullPath() و غیره هستند. برای موفقیت چنین عملیاتی نیازی به وجود منبع نیست. عملیاتی که برای موفقیت نیاز به وجود یک منبع دارند، در صورتی که منبع وجود نداشته باشد، یک CoreException ایجاد می کنند.

Eclipse یک مکانیسم کارآمد برای اطلاع رسانی تغییرات منابع فضای کاری ارائه می دهد (شکل 3). منابع می توانند در نتیجه اقدامات انجام شده در خود Eclipse IDE یا در نتیجه همگام سازی با سیستم فایل تغییر کنند. در هر دو مورد، به مشتریانی که در اعلان‌ها مشترک می‌شوند، اطلاعات دقیقی در مورد تغییرات در قالب «دلتای منابع» ارائه می‌شود. یک دلتا تغییرات بین دو حالت درخت (زیر) منبع فضای کاری را توصیف می کند و خود یک درخت است که هر گره آن تغییر یک منبع را توصیف می کند و شامل لیستی از دلتاها در سطح بعدی است که تغییرات منابع فرزند را توصیف می کند.

برنج. 3. IResourceChangeEvent و IResourceDelta

مکانیسم اطلاع رسانی مبتنی بر دلتاهای منبع دارای ویژگی های زیر است:

• یک تغییر واحد و بسیاری از تغییرات با استفاده از همان ساختار توصیف شده است، زیرا دلتا با استفاده از اصل ترکیب بازگشتی ساخته شده است. مشتریان مشترک می توانند اعلان های تغییر منبع را با استفاده از نزول بازگشتی از طریق درخت دلتا پردازش کنند.
• دلتا حاوی اطلاعات کاملی در مورد تغییرات در منبع، از جمله حرکت آن و/یا تغییرات در "نشانگرهای" مرتبط با آن است (به عنوان مثال، خطاهای کامپایل به عنوان نشانگر نشان داده می شوند).
• از آنجایی که منابع منبع از طریق دسته ساخته می شوند، دلتا به طور طبیعی می تواند به یک منبع راه دور ارجاع دهد.

همانطور که به زودی خواهیم دید، اجزای اصلی طراحی مکانیسم اعلان تغییر مدل منبع برای سایر مدل‌های مبتنی بر دسته نیز مرتبط هستند.

هسته JDT

مدل منبع فضای کاری Eclipse یک مدل اساسی زبان-آگنوستیک است. مؤلفه JDT Core (افزونه org.eclipse.jdt.core) یک API برای پیمایش و تجزیه و تحلیل ساختار فضای کاری از منظر جاوا ارائه می دهد که به اصطلاح "مدل جاوا" نامیده می شود.مدل جاوا). این API بر اساس عناصر جاوا تعریف شده است، برخلاف API مدل منبع اصلی که بر اساس پوشه ها و فایل ها تعریف می شود. رابط های اصلی درخت عنصر جاوا در شکل نشان داده شده است. 4.

برنج. 4. عناصر مدل جاوا

مدل جاوا از همان اصطلاح handle/body مانند مدل منبع استفاده می کند (شکل 5). IJavaElement دسته است و JavaElementInfo نقش بدنه را بازی می کند. رابط IJavaElement یک پروتکل مشترک برای تمام عناصر جاوا تعریف می کند. برخی از متدهای آن فقط handle هستند: getElementName()، getParent() و غیره. شی JavaElementInfo وضعیت عنصر مربوطه را ذخیره می کند: ساختار و ویژگی های آن.

برنج. 5. IJavaElement و JavaElementInfo

مدل جاوا تفاوت هایی در اجرای طراحی دسته/بدنه اولیه در مقایسه با مدل منبع دارد. همانطور که در بالا ذکر شد، در مدل منبع، درخت عنصر، که گره های آن اشیاء اطلاعات منبع هستند، به طور کامل در حافظه موجود است. اما مدل جاوا می‌تواند تعداد عناصر بسیار بیشتری نسبت به درخت منبع داشته باشد، زیرا ساختار داخلی فایل‌های .java و .class را نیز نشان می‌دهد: انواع، فیلدها و روش‌ها.

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

مکانیسم اطلاع رسانی تغییرات به عناصر جاوا به طور کلی شبیه مکانیسم ردیابی تغییرات منابع فضای کاری است که در بالا مورد بحث قرار گرفت. مشتری که مایل به نظارت بر تغییرات در مدل جاوا است، مشترک اعلان‌هایی می‌شود که به‌عنوان یک شی ElementChangedEvent نشان داده می‌شوند که حاوی یک IJavaElementDelta است (شکل 6).

برنج. 6. ElementChangedEvent و IJavaElementDelta

مدل جاوا حاوی اطلاعاتی در مورد بدنه های روش یا وضوح نام نیست، بنابراین برای تجزیه و تحلیل دقیق کد نوشته شده در جاوا، JDT Core یک مدل اضافی (غیر مبتنی بر دسته) ارائه می دهد: درخت نحو انتزاعی (درخت نحو انتزاعی، AST). AST نتیجه تجزیه متن منبع را نشان می دهد. گره های AST با عناصر ساختار ماژول منبع (اعلامیه ها، عملگرها، عبارات و غیره) مطابقت دارند و حاوی اطلاعاتی در مورد مختصات عنصر مربوطه در متن مبدا و همچنین (به عنوان یک گزینه) اطلاعاتی در مورد وضوح نام در متن هستند. شکل پیوند به اصطلاح پیوستگی. Binding ها اشیایی هستند که موجودیت های نامگذاری شده را نشان می دهند، مانند انواع، متدها و متغیرها که توسط کامپایلر شناخته شده است. برخلاف گره‌های AST که یک درخت را تشکیل می‌دهند، پیوندها از ارجاع متقابل پشتیبانی می‌کنند و به طور کلی یک نمودار را تشکیل می‌دهند. کلاس انتزاعی ASTNode کلاس پایه مشترک برای همه گره های AST است. زیر کلاس های ASTNode با ساختارهای نحوی خاص زبان جاوا مطابقت دارند.

از آنجایی که درخت های نحوی می توانند مقدار قابل توجهی از حافظه را مصرف کنند، JDT تنها یک AST را برای ویرایشگر فعال ذخیره می کند. برخلاف مدل جاوا، AST معمولاً به عنوان یک مدل «واسطه»، «موقت» در نظر گرفته می‌شود که اعضای آن نباید توسط مشتریان خارج از چارچوب عملیاتی که منجر به ایجاد AST شده است، ارجاع داده شوند.

سه مدل فهرست شده (مدل جاوا، AST، اتصالات) با هم پایه ای را برای ساخت «ابزارهای توسعه هوشمند» در JDT تشکیل می دهند، از جمله یک ویرایشگر قدرتمند جاوا با «کمک های» مختلف، اقدامات مختلف برای پردازش کد منبع (از جمله سازماندهی فهرستی از واردات). نام ها و قالب بندی با توجه به سبک سفارشی)، ابزارهای جستجو و بازسازی. در این مورد، مدل جاوا نقش ویژه ای ایفا می کند، زیرا از آن به عنوان پایه ای برای نمایش بصری ساختار برنامه در حال توسعه استفاده می شود (به عنوان مثال، در Package Explorer، Outline، Search، Call Hierarchy، و نوع سلسله مراتب).

اجزای Eclipse مورد استفاده در 1C: Enterprise Developments Tools

در شکل شکل 7 مؤلفه‌های Eclipse را نشان می‌دهد که پایه و اساس پلتفرم فناوری 1C: ابزارهای توسعه سازمانی را تشکیل می‌دهند.

برنج. 7. Eclipse به عنوان یک پلتفرم برای 1C:Enterprise Development Tools

پلتفرم Eclipse زیرساخت های اساسی را فراهم می کند. ما در بخش قبل به برخی از جنبه های این زیرساخت نگاه کردیم.

چارچوب مدل‌سازی Eclipse (EMF) وسیله ای کلی برای مدل سازی داده های ساخت یافته ارائه می دهد. EMF با پلتفرم Eclipse یکپارچه شده است، اما می تواند به طور جداگانه در برنامه های معمولی جاوا نیز استفاده شود. اغلب، توسعه دهندگان جدید Eclipse از قبل به خوبی با EMF آشنا هستند، اگرچه هنوز به طور کامل پیچیدگی های پلتفرم Eclipse را درک نکرده اند. یکی از دلایل چنین محبوبیت شایسته ای طراحی جهانی است که از جمله شامل یک API یکپارچه در سطح متا است که به شما امکان می دهد با هر مدل EMF به طور کلی کار کنید. پیاده سازی های اولیه برای اشیاء مدل ارائه شده توسط EMF و زیرسیستم برای تولید کد مدل بر اساس متا مدل به طور قابل توجهی سرعت توسعه را افزایش می دهد و تعداد خطاها را کاهش می دهد. EMF همچنین دارای مکانیسم‌هایی برای سریال‌سازی مدل‌ها، ردیابی تغییرات مدل و موارد دیگر است.

مانند هر ابزار واقعاً همه منظوره، EMF برای حل طیف وسیعی از مشکلات مدل‌سازی مناسب است، اما برخی از کلاس‌های مدل‌ها (به عنوان مثال، مدل‌های مبتنی بر دسته که در بالا توضیح داده شد) ممکن است به ابزارهای مدل‌سازی تخصصی‌تری نیاز داشته باشند. صحبت کردن در مورد EMF، به ویژه در محدوده محدود یک مقاله، کاری ناسپاس است، زیرا این موضوع یک کتاب جداگانه و نسبتاً غلیظ است. فقط توجه داشته باشیم که سیستم باکیفیت تعمیم های زیربنایی EMF اجازه تولد طیف وسیعی از پروژه های اختصاص داده شده به مدل سازی را داد که در پروژه سطح بالا گنجانده شده اند. مدل سازی کسوف همراه با خود EMF. یکی از این پروژه ها Eclipse Xtext است.

Eclipse Xtext زیرساخت "مدل سازی متن" را فراهم می کند. Xtext استفاده می کند ANTLR برای تجزیه متن مبدا و EMF برای نمایش ASG (گراف معنایی انتزاعی، که اساساً ترکیبی از AST و اتصالات است)، که "مدل معنایی" نیز نامیده می شود. گرامر زبان مدل شده توسط Xtext به زبان خود Xtext شرح داده شده است. این به شما امکان می دهد نه تنها یک توصیف دستور زبان برای ANTLR ایجاد کنید، بلکه یک مکانیسم سریال سازی AST را نیز به دست آورید (یعنی Xtext هم تجزیه کننده و هم تجزیه کننده را ارائه می دهد)، یک اشاره زمینه، و تعدادی از اجزای زبان دیگر. از سوی دیگر، زبان گرامر مورد استفاده در Xtext نسبت به مثلاً زبان گرامر مورد استفاده در ANTLR انعطاف‌پذیری کمتری دارد. بنابراین، گاهی اوقات لازم است زبان پیاده سازی شده را به Xtext "خم کنید"، که معمولاً اگر صحبت از زبانی است که از ابتدا توسعه می یابد، مشکلی ایجاد نمی کند، اما ممکن است برای زبان هایی با نحو از قبل تعیین شده غیرقابل قبول باشد. با وجود این، Xtext در حال حاضر بالغ ترین، غنی ترین و همه کاره ترین ابزار در Eclipse برای ساخت زبان های برنامه نویسی و ابزارهای توسعه برای آنها است. به طور خاص، این یک ابزار ایده آل برای نمونه سازی سریع است زبان های خاص دامنه (زبان مخصوص دامنه، DSL). علاوه بر «هسته زبان» فوق الذکر مبتنی بر ANTLR و EMF، Xtext بسیاری از مؤلفه‌های مفید سطح بالاتر، از جمله مکانیسم‌های نمایه‌سازی، ساخت‌وساز افزایشی، «ویرایشگر هوشمند» و بسیاری موارد دیگر را ارائه می‌کند، اما دسته‌بندی را کنار گذاشته است. مدل های زبانی مبتنی بر مانند EMF، Xtext نیز موضوعی است که ارزش یک کتاب جداگانه را دارد و در حال حاضر به سختی می‌توانیم درباره همه قابلیت‌های آن صحبت کنیم.

1C: Enterprise Development Tools به طور فعال از خود EMF و تعدادی دیگر از پروژه های Eclipse Modeling استفاده می کند. به طور خاص، Xtext یکی از پایه های ابزارهای توسعه برای چنین زبان های 1C: Enterprise به عنوان زبان برنامه نویسی داخلی و زبان پرس و جو است. یکی دیگر از پایه‌های این ابزارهای توسعه، پروژه Eclipse Handly است که در مورد آن با جزئیات بیشتر صحبت خواهیم کرد (از مؤلفه‌های Eclipse ذکر شده، هنوز کمتر شناخته شده است).

Eclipse Handly، یک پروژه فرعی از پروژه سطح بالای Eclipse Technology، در نتیجه مشارکت کد اولیه در بنیاد Eclipse که توسط 1C در سال 2014 انجام شد، پدیدار شد. از آن زمان، 1C به حمایت از توسعه پروژه ادامه داده است: committers Handly کارمندان شرکت هستند. این پروژه کوچک است، اما جایگاه نسبتاً منحصر به فردی را در Eclipse اشغال می کند: هدف اصلی آن پشتیبانی از توسعه مدل های مبتنی بر دسته است.

اصول اولیه معماری مدل های مبتنی بر دسته، مانند اصطلاح دسته/بدنه، در بالا با استفاده از مدل منبع و مدل جاوا به عنوان مثال مورد بحث قرار گرفت. همچنین اشاره کرد که هم مدل منبع و هم مدل جاوا پایه های مهمی برای ابزارهای توسعه جاوا Eclipse (JDT) هستند. و از آنجایی که تقریباً تمام پروژه‌های *DT Eclipse دارای معماری مشابه JDT هستند، اغراق‌آمیز نیست اگر بگوییم مدل‌های مبتنی بر دسته زیربنای بسیاری از IDE‌های ساخته شده در بالای پلتفرم Eclipse هستند. به عنوان مثال، Eclipse C/C++ Development Tooling (CDT) دارای یک مدل C/C++ مبتنی بر دسته است که همان نقشی را در معماری CDT ایفا می کند که مدل جاوا در JDT انجام می دهد.

قبل از Handly، Eclipse کتابخانه های تخصصی برای ساخت مدل های زبان مبتنی بر دسته ارائه نمی داد. مدل‌هایی که در حال حاضر وجود دارند عمدتاً با تطبیق مستقیم کد مدل جاوا (با نام مستعار کپی/پیست) ایجاد شده‌اند. در مواردی که اجازه می دهد مجوز عمومی Eclipse (EPL). (بدیهی است که این موضوع معمولاً برای پروژه های خود Eclipse یک مسئله قانونی نیست، اما برای محصولات منبع بسته نیست). و غیره. بدتر از آن این است که مدل‌های به‌دست‌آمده «چیزها در خودشان» باقی می‌مانند و از پتانسیل یکپارچه‌سازی استفاده نمی‌کنند. اما جداسازی مفاهیم و پروتکل‌های رایج برای مدل‌های زبانی مبتنی بر دسته می‌تواند منجر به ایجاد اجزای قابل استفاده مجدد برای کار با آنها شود، مشابه آنچه در مورد EMF رخ داد.

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

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

• شناسایی انتزاعات اصلی حوزه موضوعی.
• کاهش تلاش و بهبود کیفیت اجرای مدل‌های زبان مبتنی بر دسته از طریق استفاده مجدد از کد.
• ارائه یک API یکپارچه در سطح متا برای مدل‌های به دست آمده، ایجاد مؤلفه‌های مشترک IDE که با مدل‌های مبتنی بر دسته زبان کار می‌کنند.
• انعطاف پذیری و مقیاس پذیری.
• ادغام با Xtext (در یک لایه جداگانه).

برای برجسته کردن مفاهیم و پروتکل‌های رایج، پیاده‌سازی‌های موجود مدل‌های مبتنی بر دسته زبان مورد تجزیه و تحلیل قرار گرفتند. رابط های اصلی و پیاده سازی های اساسی ارائه شده توسط Handly در شکل 8 نشان داده شده است. XNUMX.

برنج. 8. رابط های مشترک و پیاده سازی های اساسی عناصر Handly

رابط IElement نشان دهنده دسته یک عنصر است و در عناصر همه مدل های Handly-based مشترک است. کلاس انتزاعی Element مکانیزم دسته/بدنه تعمیم یافته را پیاده سازی می کند (شکل 9).

برنج. 9. پیاده سازی IElement و دسته/بدنه عمومی

علاوه بر این، Handly یک مکانیسم کلی برای اطلاع رسانی در مورد تغییرات در عناصر مدل ارائه می دهد (شکل 10). همانطور که می بینید، به طور کلی شبیه مکانیسم های اطلاع رسانی پیاده سازی شده در مدل منبع و مدل جاوا است و از IElementDelta برای ارائه یک نمایش یکپارچه از اطلاعات تغییر عنصر استفاده می کند.

برنج. 10. رابط های عمومی و پیاده سازی های اساسی مکانیسم اطلاع رسانی Handly

بخش Handly که در بالا مورد بحث قرار گرفت (شکل 9 و 10) را می توان برای نمایش تقریباً هر مدل مبتنی بر دسته استفاده کرد. برای ایجاد وابسته به زبانشناسی مدل‌ها، پروژه قابلیت‌های اضافی را ارائه می‌دهد - به ویژه، رابط‌های مشترک و پیاده‌سازی‌های اساسی برای عناصر ساختار متن منبع، به اصطلاح عناصر منبع (شکل 8). رابط ISourceFile یک فایل منبع را نشان می دهد و ISourceConstruct یک عنصر را در فایل منبع نشان می دهد. کلاس‌های انتزاعی SourceFile و SourceConstruct مکانیسم‌های تعمیم‌یافته را برای پشتیبانی از کار با فایل‌های منبع و عناصر آن پیاده‌سازی می‌کنند، به عنوان مثال، کار با بافرهای متن، اتصال به مختصات یک عنصر در متن مبدا، تطبیق مدل‌ها با محتوای فعلی یک بافر کپی در حال کار. ، و غیره. پیاده‌سازی این مکانیسم‌ها معمولاً یک چالش است و Handly می‌تواند تلاش برای توسعه مدل‌های زبان مبتنی بر دسته را با ارائه پیاده‌سازی‌های پایه با کیفیت بالا به‌طور قابل‌توجهی کاهش دهد.

علاوه بر مکانیسم‌های اصلی ذکر شده در بالا، Handly زیرساختی برای بافرهای متنی و عکس‌های فوری، پشتیبانی از یکپارچه‌سازی با ویرایشگرهای کد منبع (از جمله ادغام خارج از جعبه با ویرایشگر Xtext) و همچنین برخی از مؤلفه‌های متداول رابط کاربری فراهم می‌کند. با ویرایشگرهای کد منبع کار کنید. مدل های دستی مانند چارچوب کلی. برای نشان دادن قابلیت های خود، این پروژه چندین مثال از جمله پیاده سازی مدل جاوا در Handly ارائه می دهد. (در مقایسه با اجرای کامل مدل جاوا در JDT، این مدل به عمد تا حدودی برای وضوح بیشتر ساده شده است.)

همانطور که قبلا ذکر شد، تمرکز عمده در طول طراحی اولیه Handly و توسعه بعدی بر مقیاس پذیری و انعطاف پذیری بود و همچنان ادامه دارد.

در اصل، مدل‌های مبتنی بر دسته «بر اساس طراحی» به خوبی مقیاس می‌شوند. به عنوان مثال، اصطلاح handle/body به شما امکان می دهد مقدار حافظه مصرف شده توسط یک مدل را محدود کنید. اما تفاوت های ظریف نیز وجود دارد. بنابراین، هنگام آزمایش Handly برای مقیاس پذیری، مشکلی در اجرای مکانیسم اعلان کشف شد - زمانی که تعداد زیادی از عناصر تغییر کردند، ساخت دلتاها زمان زیادی را صرف کرد. معلوم شد که همین مشکل در مدل JDT جاوا وجود دارد، که یک بار کد مربوطه از آن اقتباس شده است. ما این باگ را در Handly برطرف کردیم و پچ مشابهی را برای JDT آماده کردیم که با تشکر دریافت شد. این فقط یک مثال است که در آن معرفی Handly به پیاده‌سازی‌های مدل موجود می‌تواند به طور بالقوه مفید باشد، زیرا در این مورد چنین اشکالی می‌تواند تنها در یک مکان برطرف شود.

برای اینکه پیاده سازی Handly در پیاده سازی های مدل موجود از نظر فنی امکان پذیر باشد، کتابخانه باید انعطاف پذیری قابل توجهی داشته باشد. مشکل اصلی حفظ سازگاری به عقب در سراسر مدل API است. این مشکل در حل شد Handly 0.5 با جدا کردن واضح API مخصوص مدل، تعریف شده و کاملاً کنترل شده توسط توسعه دهنده، از API یکپارچه فراسطح ارائه شده توسط کتابخانه. این نه تنها پیاده سازی Handly در پیاده سازی های موجود را از نظر فنی ممکن می کند، بلکه به توسعه دهنده مدل جدید آزادی قابل توجهی در هنگام طراحی API می دهد.

انعطاف پذیری جنبه های دیگری نیز دارد. برای مثال، Handly تقریباً هیچ محدودیتی بر ساختار مدل اعمال نمی‌کند و می‌تواند برای مدل‌سازی زبان‌های همه منظوره و دامنه‌های خاص استفاده شود. هنگام ساختن ساختار فایل منبع، Handly هیچ شکل خاصی از نمایش AST را تجویز نمی کند و در اصل، حتی نیازی به حضور خود AST ندارد، بنابراین سازگاری تقریباً با هر مکانیزم تجزیه را تضمین می کند. در نهایت، Handly از یکپارچگی کامل با فضای کاری Eclipse پشتیبانی می‌کند، اما همچنین می‌تواند مستقیماً با سیستم‌های فایل به لطف ادغام با سیستم فایل Eclipse (EFS).

نسخه فعلی Handly 0.6 در دسامبر 2016 منتشر شد. علیرغم این واقعیت که پروژه در حال حاضر در مرحله انکوباسیون است و API هنوز در نهایت ثابت نشده است، Handly در حال حاضر در دو محصول تجاری بزرگ استفاده می شود که ریسک عمل به عنوان "پذیرش کنندگان اولیه" را به عهده گرفتند، و باید بگویم، هنوز پشیمان نشو

همانطور که در بالا ذکر شد، یکی از این محصولات 1C:Enterprise Development Tools است که در آن Handly از همان ابتدا برای مدلسازی عناصر ساختار سطح بالای چنین زبانهای 1C:Enterprise به عنوان زبان برنامه نویسی داخلی و زبان پرس و جو استفاده می شود. . محصول دیگری برای عموم مردم کمتر شناخته شده است. این استودیو Codasip، یک محیط طراحی یکپارچه برای پردازنده مجموعه دستورالعمل های خاص برنامه (ASIP) که هم در شرکت چک Codasip و هم توسط مشتریانش از جمله استفاده می شود. AMD, AVG, موبایل, طراحی های سیگما. Codasip از سال 2015 از Handly در تولید استفاده کرده است و با نسخه Handly 0.2 شروع شده است. آخرین نسخه Codasip Studio از نسخه 0.5 استفاده می کند که در ژوئن 2016 منتشر شد. Ondřej Ilčík، که توسعه IDE را در Codasip رهبری می کند، با پروژه در تماس است و بازخورد حیاتی را از طرف "پذیرنده شخص ثالث" ارائه می دهد. او حتی توانست مقداری وقت آزاد برای مشارکت مستقیم در توسعه پروژه پیدا کند و یک لایه رابط کاربری (~4000 خط کد) را برای یکی از نمونه های Handly، یک مدل جاوا، پیاده سازی کند. اطلاعات دست اول دقیق تر در مورد استفاده از Handly توسط پذیرندگان را می توان در صفحه یافت داستان های موفقیت پروژه

امیدواریم پس از انتشار نسخه 1.0 با ضمانت پایداری API و خروج پروژه از وضعیت نهفتگی، Handly پذیرندگان جدیدی داشته باشد. در همین حال، پروژه به آزمایش و بهبود بیشتر API ادامه می‌دهد و هر سال دو نسخه «مهم» را منتشر می‌کند - در ماه ژوئن (همان تاریخ انتشار همزمان Eclipse) و دسامبر، یک برنامه زمان‌بندی قابل پیش‌بینی ارائه می‌کند که پذیرندگان می‌توانند بر آن تکیه کنند. همچنین می‌توانیم اضافه کنیم که «نرخ اشکال» پروژه به‌طور مداوم در سطح پایینی باقی می‌ماند و Handly از همان نسخه‌های اولیه به‌طور قابل اعتمادی در محصولات پذیرندگان اولیه کار می‌کرد. برای کاوش بیشتر Eclipse Handly، می توانید استفاده کنید آموزش شروع به کار и بررسی اجمالی معماری.

منبع: www.habr.com