Eclipse כפלטפורמה טכנולוגית עבור 1C:Enterprise Development Tools

אולי, לקוי מזמן לא נזקק להקדמה מיוחדת. אנשים רבים מכירים את Eclipse הודות לכלי הפיתוח של Eclipse Java (JDT). זהו Java IDE הפופולרי הפופולרי הזה שרוב המפתחים מקשרים למילה "Eclipse". עם זאת, Eclipse היא גם פלטפורמה הניתנת להרחבה לשילוב כלי פיתוח (Eclipse Platform), וגם מספר IDEs שנבנו על בסיסה, כולל JDT. Eclipse הוא גם פרויקט Eclipse, הפרויקט ברמה העליונה שמתאם את הפיתוח של פלטפורמת ה-Eclipse וה-JDT, וה-Eclipse SDK, התוצאה המתקבלת של פיתוח זה. לבסוף, Eclipse היא קרן קוד פתוח עם קהילה ענקית של פרויקטים, שלא כולם כתובים ב-Java או קשורים לכלי פיתוח (לדוגמה, פרויקטים ליקוי חמה и מדע הליקוי). העולם של Eclipse מגוון מאוד.

במאמר זה, שהוא סקירה מטבעו, ננסה להסתכל על כמה מהיסודות של ארכיטקטורת Eclipse כפלטפורמה לבניית כלי פיתוח משולבים ולתת מושג ראשוני על רכיבי Eclipse המהווים את הבסיס לטכנולוגיה פלטפורמה עבור "הקונפיגורטור החדש" 1C: Enterprise. 1C:כלים לפיתוח ארגוני. כמובן, סקירה כזו תהיה בהכרח שטחית במידה רבה ודי מוגבלת, כולל מכיוון שאנו מתמקדים לא רק במפתחי Eclipse כקהל היעד. עם זאת, אנו מקווים שאפילו מפתחי Eclipse מנוסים יוכלו למצוא מידע מעניין במאמר. לדוגמה, נדבר על אחד מ"סודות הליקוי", פרויקט חדש יחסית ולא ידוע Eclipse Handly, שהוקמה ונתמכת על ידי 1C.

מבוא לארכיטקטורת Eclipse

בואו נסתכל תחילה על כמה היבטים כלליים של ארכיטקטורת Eclipse באמצעות הדוגמה כלי פיתוח של Eclipse Java (JDT). הבחירה ב-JDT כדוגמה אינה מקרית. זוהי סביבת הפיתוח המשולבת הראשונה שמופיעה ב-Eclipse. פרויקטים אחרים של *DT Eclipse, כגון Eclipse C/C++ Development Tooling (CDT), נוצרו מאוחר יותר ושואלים הן עקרונות ארכיטקטוניים בסיסיים והן קטעי קוד מקור בודדים מ-JDT. היסודות של הארכיטקטורה שנקבעו ב-JDT רלוונטיים עד היום כמעט לכל IDE שנבנה על גבי פלטפורמת Eclipse, כולל 1C:Enterprise Development Tools.

קודם כל, יש לציין כי Eclipse מתאפיין בריבוד ארכיטקטוני ברור למדי, עם הפרדה של פונקציונליות בלתי תלויה בשפה מפונקציונליות המיועדת לתמוך בשפות תכנות ספציפיות, והפרדה של רכיבי "ליבה" בלתי תלויים ממשק משתמש מרכיבים הקשורים עם ממשק משתמש תומך.

לפיכך, פלטפורמת Eclipse מגדירה תשתית משותפת, בלתי תלויה בשפה, וכלי הפיתוח של Java מוסיפים ל-Eclipse Java IDE בעל תכונות מלאות. גם פלטפורמת ה-Eclipse וגם ה-JDT מורכבים מכמה רכיבים, שכל אחד מהם שייך ל"ליבה" עצמאית של ממשק משתמש או לשכבת ממשק משתמש (איור 1).

אורז. 1. Eclipse Platform ו-JDT

בואו נרשום את המרכיבים העיקריים של פלטפורמת Eclipse:

• זמן ריצה - מגדיר את תשתית הפלאגין. Eclipse מאופיין בארכיטקטורה מודולרית. בעיקרו של דבר, Eclipse הוא אוסף של "נקודות הרחבה" ו"הרחבות".
• מרחב עבודה - מנהל פרויקט אחד או יותר. פרויקט מורכב מתיקיות וקבצים הממופים ישירות למערכת הקבצים.
• ערכת כלי ווידג'ט רגילה (SWT) - מספק רכיבי ממשק משתמש בסיסיים המשולבים במערכת ההפעלה.
• JFace - מספק מספר מסגרות ממשק משתמש שנבנו על גבי SWT.
• שולחן עבודה - מגדיר את פרדיגמת ממשק המשתמש של Eclipse: עורכים, תצוגות, נקודות מבט.

יש לומר שפלטפורמת Eclipse מספקת גם רכיבים שימושיים רבים אחרים לבניית כלי פיתוח משולבים, כולל Debug, Compare, Search ו-Team. יש לציין במיוחד את JFace Text - הבסיס לבניית "עורכים חכמים" של קוד מקור. למרבה הצער, אפילו בחינה שטחית של רכיבים אלו, כמו גם רכיבי שכבת ה-UI, אינה אפשרית במסגרת מאמר זה, ולכן בהמשך חלק זה נצמצם את עצמנו לסקירה כללית של מרכיבי "הליבה" העיקריים של פלטפורמת Eclipse ו-JDT.

זמן ריצה ליבה

תשתית הפלאגין Eclipse מבוססת על OSGi ומסופק על ידי הפרויקט Eclipse Equinox. כל תוסף Eclipse הוא חבילת OSGi. מפרט OSGi מגדיר, במיוחד, מנגנונים לניהול גרסאות ופתרון תלות. בנוסף למנגנונים הסטנדרטיים הללו, Equinox מציגה את הרעיון נקודות הרחבה. כל תוסף יכול להגדיר נקודות הרחבה משלו, וגם להכניס פונקציונליות נוספת ("הרחבות") למערכת באמצעות נקודות הרחבה המוגדרות על ידי אותם תוספים או תוספים אחרים. כל תיאור מפורט של מנגנוני OSGi ו-Equinox הוא מעבר להיקף של מאמר זה. רק נציין שהמודולריזציה ב-Eclipse היא מוחלטת (כל תת-מערכת, כולל Runtime, מורכבת מתוספי אחד או יותר), וכמעט הכל ב-Eclipse הוא הרחבה. יתרה מכך, עקרונות אלו הוטמעו בארכיטקטורת Eclipse הרבה לפני הצגת OSGi (באותה תקופה הם השתמשו בטכנולוגיה משלהם, בדומה ל-OSGi).

סביבת עבודה ליבה

כמעט כל סביבת פיתוח משולבת הבנויה על גבי פלטפורמת Eclipse פועלת עם סביבת העבודה של Eclipse. זוהי סביבת העבודה שמכילה בדרך כלל את קוד המקור של האפליקציה שפותחה ב-IDE. סביבת העבודה ממפה ישירות למערכת הקבצים ומורכבת מפרויקטים, המכילים תיקיות וקבצים. הפרויקטים, התיקיות והקבצים האלה נקראים אֶמְצָעִי סביבת עבודה. הטמעת סביבת העבודה ב-Eclipse משמשת כמטמון ביחס למערכת הקבצים, מה שמאפשר להאיץ משמעותית את המעבר של עץ המשאבים. בנוסף, מרחב העבודה מספק מספר שירותים נוספים, לרבות מנגנון הודעות על שינויים במשאבים и תשתית בונה מצטברת.

הרכיב Core Resources (org.eclipse.core.resources plugin) אחראי לתמיכה בסביבת העבודה ובמשאביה. בפרט, רכיב זה מספק גישה פרוגרמטית לסביבת העבודה בטופס מודלים של משאבים. כדי לעבוד ביעילות עם מודל זה, לקוחות צריכים דרך פשוטה להציג קישור למשאב. במקרה זה, רצוי להסתיר את האובייקט שמאחסן ישירות את מצב המשאב במודל מגישה ללקוח. אחרת, במקרה של, למשל, מחיקת קובץ, הלקוח יכול להמשיך להחזיק אובייקט שכבר אינו במודל, עם הבעיות הנובעות מכך. Eclipse פותר את הבעיה הזו באמצעות משהו שנקרא לטפל מַשׁאָב. Handle פועל כמפתח (הוא יודע רק את הנתיב למשאב בסביבת העבודה) ושולט לחלוטין בגישה לאובייקט המודל הפנימי, המאחסן ישירות מידע על מצב המשאב. עיצוב זה הוא וריאציה של הדפוס ידית/גוף.

אורז. איור 2 ממחיש את ניב הידית/גוף כפי שהוחל על מודל המשאבים. ממשק ה-IResource מייצג את הידית של משאב והוא API, בניגוד למחלקת Resource, המיישמת ממשק זה, ומחלקה ResourceInfo, המייצגת את הגוף, שאינם ממשקי API. נדגיש ש-handle מכירה רק את הנתיב למשאב ביחס לשורש סביבת העבודה ואינה מכילה קישור למידע על המשאב. אובייקטי מידע על משאבים יוצרים מה שנקרא "עץ אלמנטים". מבנה נתונים זה מתממש לחלוטין בזיכרון. כדי למצוא את מופע המידע של המשאב התואם לטיפול, עוברים על עץ האלמנטים בהתאם לנתיב המאוחסן בנקודת אחיזה זו.

אורז. 2. IResource ו-ResourceInfo

כפי שנראה בהמשך, העיצוב הבסיסי של מודל המשאבים (אפשר לקרוא לו מבוסס ידית) משמש ב-Eclipse גם עבור דגמים אחרים. לעת עתה, בואו נרשום כמה מהמאפיינים הייחודיים של עיצוב זה:

• ידית היא אובייקט ערכי. אובייקטים ערכיים הם אובייקטים בלתי ניתנים לשינוי שהשוויון ביניהם אינו מבוסס על זהות. חפצים כאלה יכולים לשמש בבטחה כמפתח במכולות גובבות. מופעים מרובים של ידית יכולים להפנות לאותו משאב. כדי להשוות ביניהם, עליך להשתמש בשיטת equals(Object).
• Handle מגדיר את ההתנהגות של משאב, אך אינו מכיל מידע על מצב המשאב (הנתונים היחידים שהיא מאחסנת הוא ה"מפתח", הנתיב למשאב).
• Handle עשוי להתייחס למשאב שאינו קיים (או למשאב שטרם נוצר, או למשאב שכבר נמחק). ניתן לבדוק את קיומו של משאב באמצעות שיטת IResource.exists() .
• ניתן ליישם פעולות מסוימות רק על סמך מידע המאוחסן ב-handle עצמו (מה שנקרא פעולות handle-only). דוגמאות הן IResource.getParent(), getFullPath() וכו'. המשאב לא צריך להתקיים כדי שמבצע כזה יצליח. פעולות הדורשות קיים משאב כדי להצליח זורקות CoreException אם המשאב אינו קיים.

Eclipse מספק מנגנון יעיל להודיע ​​על שינויים במשאבי סביבת העבודה (איור 3). משאבים יכולים להשתנות או כתוצאה מפעולות שבוצעו בתוך Eclipse IDE עצמו או כתוצאה מסנכרון עם מערכת הקבצים. בשני המקרים, לקוחות המנויים להתראות מקבלים מידע מפורט על השינויים בצורה של "דלתא משאבים". דלתא מתארת ​​שינויים בין שני מצבים של עץ משאב (משנה) של סביבת עבודה והיא עצמה עץ, שכל צומת שלו מתאר שינוי למשאב ומכיל רשימה של דלתות ברמה הבאה המתארות שינויים במשאבי צאצא.

אורז. 3. IResourceChangeEvent ו-IResourceDelta

למנגנון ההודעות המבוסס על דלתות משאבים יש את המאפיינים הבאים:

• שינוי בודד ושינויים רבים מתוארים תוך שימוש באותו מבנה, שכן הדלתא נבנית באמצעות עקרון ההרכב הרקורסי. לקוחות מנויים יכולים לעבד התראות על שינוי משאבים באמצעות ירידה רקורסיבית דרך עץ של דלתות.
• הדלתא מכילה מידע מלא על שינויים במשאב, כולל תנועתו ו/או שינויים ב"סמנים" המשויכים אליו (לדוגמה, שגיאות קומפילציה מיוצגות כסמנים).
• מכיוון שהפניות למשאב נעשות דרך הידית, דלתא יכולה להפנות באופן טבעי למשאב מרוחק.

כפי שנראה בקרוב, המרכיבים העיקריים של עיצוב מנגנון ההתראה על שינוי מודל משאבים רלוונטיים גם למודלים אחרים מבוססי ידית.

JDT Core

מודל המשאבים של סביבת העבודה של Eclipse הוא מודל בסיסי של שפה אגנוסטית. רכיב JDT Core (plugin org.eclipse.jdt.core) מספק API לניווט וניתוח מבנה סביבת העבודה מנקודת מבט של Java, מה שנקרא "מודל Java" (דגם Java). API זה מוגדר במונחים של רכיבי Java, בניגוד ל-API של מודל המשאבים הבסיסי, המוגדר במונחים של תיקיות וקבצים. הממשקים העיקריים של עץ האלמנטים של Java מוצגים באיור. 4.

אורז. 4. Java Model Elements

מודל Java משתמש באותו ניב ידית/גוף כמו מודל המשאבים (איור 5). IJavaElement היא הידית, ו-JavaElementInfo ממלא את תפקיד הגוף. ממשק IJavaElement מגדיר פרוטוקול משותף לכל רכיבי Java. חלק מהשיטות שלו הן לטיפול בלבד: getElementName(), getParent() וכו'. האובייקט JavaElementInfo מאחסן את המצב של האלמנט המתאים: המבנה והתכונות שלו.

אורז. 5. IJavaElement ו-JavaElementInfo

למודל Java יש כמה הבדלים ביישום של עיצוב הידית/גוף הבסיסי בהשוואה למודל המשאבים. כפי שצוין לעיל, במודל המשאבים, עץ האלמנטים, שהצמתים שלו הם אובייקטי מידע על משאבים, כלול כולו בזיכרון. אבל למודל Java יכול להיות מספר גדול משמעותית של אלמנטים מעץ המשאבים, מכיוון שהוא מייצג גם את המבנה הפנימי של קבצי .java ו-.class: סוגים, שדות ושיטות.

כדי להימנע מהתממשות מוחלטת של כל עץ האלמנטים בזיכרון, יישום מודל Java משתמש במטמון LRU בגודל מוגבל של מידע על רכיבים, כאשר המפתח הוא handle IJavaElement. אובייקטי מידע על אלמנטים נוצרים לפי דרישה תוך כדי ניווט בעץ האלמנטים. במקרה זה, הפריטים בשימוש הפחות תכופים מסולקים מהמטמון, וצריכת הזיכרון של הדגם נשארת מוגבלת לגודל המטמון שצוין. זהו יתרון נוסף של עיצוב מבוסס ידית, אשר מסתיר לחלוטין פרטי יישום כאלה מקוד הלקוח.

מנגנון ההודעה על שינויים ברכיבי Java דומה באופן כללי למנגנון מעקב אחר שינויים במשאבי סביבת העבודה שנדון לעיל. לקוח המעוניין לעקוב אחר שינויים במודל Java נרשם להודעות, אשר מיוצגות כאובייקט ElementChangedEvent המכיל IJavaElementDelta (איור 6).

אורז. 6. ElementChangedEvent ו- IJavaElementDelta

מודל ה-Java אינו מכיל מידע על גופי השיטה או רזולוציית השמות, ולכן לצורך ניתוח מפורט של קוד שנכתב ב-Java, JDT Core מספק מודל נוסף (שאינו מבוסס על ידית): עץ תחביר מופשט (עץ תחביר מופשט, AST). AST מייצג את התוצאה של ניתוח טקסט המקור. צמתי AST תואמים לאלמנטים של מבנה מודול המקור (הצהרות, אופרטורים, ביטויים וכו') ומכילים מידע על הקואורדינטות של האלמנט המתאים בטקסט המקור, כמו גם (כאופציה) מידע על החלטת שמות ב הצורה של קישורים למה שנקרא כריכות. כריכות הן אובייקטים המייצגים ישויות עם שם, כגון טיפוסים, שיטות ומשתנים, המוכרים למהדר. בניגוד לצמתי AST, היוצרים עץ, כריכות תומכות בהפניה צולבת ובדרך כלל יוצרות גרף. המחלקה המופשטת ASTNode היא מחלקת הבסיס המשותפת לכל צמתי ה-AST. תת-מחלקות ASTNode מתאימות למבנים תחביריים ספציפיים של שפת Java.

מכיוון שעצי תחביר יכולים לצרוך כמות משמעותית של זיכרון, JDT מאחסן AST אחד בלבד עבור העורך הפעיל. שלא כמו מודל Java, ה-AST נתפס בדרך כלל כמודל "בינוני", "זמני", אשר אין להתייחס לחבריו על ידי לקוחות מחוץ להקשר של הפעולה שהובילה ליצירת ה-AST.

שלושת הדגמים המפורטים (מודל Java, AST, bindings) מהווים יחד את הבסיס לבניית "כלי פיתוח חכמים" ב-JDT, כולל עורך Java חזק עם "עוזרים" שונים, פעולות שונות לעיבוד קוד מקור (כולל ארגון רשימת ייבוא שמות ועיצוב לפי הסגנון המותאם), כלי חיפוש ועיבוד מחדש. במקרה זה, מודל ה-Java ממלא תפקיד מיוחד, שכן הוא משמש כבסיס לייצוג חזותי של מבנה האפליקציה המפותחת (לדוגמה, בסייר החבילות, Outline, חיפוש, היררכיית שיחות ו היררכיית הקלדה).

רכיבי Eclipse המשמשים בכלי 1C:Enterprise Developments

באיור. איור 7 מציג את רכיבי Eclipse המהווים את הבסיס לפלטפורמת הטכנולוגיה עבור 1C:Enterprise Development Tools.

אורז. 7. Eclipse כפלטפורמה לכלי פיתוח 1C:Enterprise

פלטפורמת Eclipse מספק תשתית בסיסית. בחנו כמה היבטים של תשתית זו בסעיף הקודם.

Eclipse Modeling Framework (EMF) מספק אמצעי כללי למידול נתונים מובנים. EMF משולב עם פלטפורמת Eclipse, אך ניתן להשתמש בו גם בנפרד ביישומי Java רגילים. לעתים קרובות למדי, מפתחי Eclipse חדשים כבר מכירים היטב את EMF, למרות שהם עדיין לא מבינים עד הסוף את המורכבויות של Eclipse Platform. אחת הסיבות לפופולריות כה ראויה היא העיצוב האוניברסלי, הכולל בין היתר API מאוחד ברמת מטה, המאפשר לעבוד עם כל דגם EMF בצורה כללית. ההטמעות הבסיסיות לאובייקטי מודל שמסופקים על ידי EMF ותת המערכת להפקת קוד מודל המבוסס על המטא-מודל מגדילות משמעותית את מהירות הפיתוח ומקטינות את מספר השגיאות. EMF מכיל גם מנגנונים להצגה בסידרה של דגמים, מעקב אחר שינויים בדגם ועוד ועוד.

כמו כל כלי למטרות כלליות באמת, EMF מתאים לפתרון מגוון רחב של בעיות דוגמנות, אך מחלקות מסוימות של דגמים (לדוגמה, הדגמים מבוססי הידית שנדונו לעיל) עשויים לדרוש כלי דוגמנות מיוחדים יותר. לדבר על EMF היא משימה חסרת תודה, במיוחד בגבולות המצומצמים של מאמר אחד, שכן זהו נושא של ספר נפרד, ועבה למדי. נציין רק שמערכת ההכללות האיכותית העומדת בבסיס ה-EMF אפשרה את הלידה של מגוון שלם של פרויקטים המוקדשים למידול, הנכללים בפרויקט ברמה העליונה Eclipse Modeling יחד עם ה-EMF עצמו. פרויקט אחד כזה הוא Eclipse Xtext.

Eclipse Xtext מספק תשתית "דוגמנות טקסט". Xtext משתמש ANTLR לניתוח טקסט המקור וה-EMF לייצוג ה-ASG המתקבל (גרף סמנטי מופשט, שהוא בעצם שילוב של AST ו-bindings), הנקרא גם "המודל הסמנטי". הדקדוק של השפה שדגם 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 ממשיכה לתמוך בפיתוח הפרויקט: מתחייבים Handly הם עובדי החברה. הפרויקט קטן, אבל הוא תופס נישה די ייחודית באקליפס: המטרה העיקרית שלו היא לתמוך בפיתוח דגמים מבוססי ידיות.

העקרונות הארכיטקטוניים הבסיסיים של מודלים מבוססי ידית, כגון ניב ידית/גוף, נדונו לעיל תוך שימוש במודל המשאבים ובמודל Java כדוגמאות. זה גם ציין כי גם מודל המשאבים וגם מודל Java הם יסודות חשובים לכלי הפיתוח של Eclipse Java (JDT). ומכיוון שכמעט לכל פרויקטי *DT Eclipse יש ארכיטקטורה דומה ל-JDT, לא תהיה הגזמה גדולה לומר שמודלים מבוססי ידיות עומדים בבסיס רבים, אם לא כל ה-IDEs שנבנו על גבי פלטפורמת Eclipse. לדוגמה, ל-Eclipse C/C++ Development Tooling (CDT) יש מודל C/C++ מבוסס ידית הממלא את אותו תפקיד בארכיטקטורת ה-CDT כמו שמודל Java עושה ב-JDT.

לפני Handly, Eclipse לא הציעה ספריות מיוחדות לבניית מודלים של שפה מבוססי ידיות. המודלים הקיימים כיום נוצרו בעיקר על ידי התאמה ישירה של קוד המודל של Java (המכונה העתק/הדבק), במקרים שזה מאפשר Eclipse Public License (EPL). (ברור שבדרך כלל זה לא עניין משפטי עבור, נניח, Eclipse מקרין את עצמו, אבל לא עבור מוצרי קוד סגור.) בנוסף לאקראיות המובנית שלה, הטכניקה הזו מציגה בעיות ידועות: שכפול קוד שהוכנס על ידי בעת התאמה לשגיאות, וכו ' מה שיותר גרוע הוא שהמודלים המתקבלים נשארים "דברים בפני עצמם" ואינם מנצלים את פוטנציאל האיחוד. אבל בידוד מושגים ופרוטוקולים נפוצים עבור מודלים של שפה מבוססי ידית יכול להוביל ליצירת רכיבים לשימוש חוזר לעבודה איתם, בדומה למה שקרה במקרה של EMF.

זה לא שאקליפס לא הבין את הבעיות האלה. עוד ב-2005 מרטין אישלימן, מסכם את הניסיון בפיתוח אב הטיפוס של CDT, טען הצורך ליצור תשתית משותפת למודלים של שפה, כולל מודלים מבוססי ידיות. אבל, כפי שקורה לעתים קרובות, עקב משימות בעדיפות גבוהה יותר, היישום של רעיונות אלה מעולם לא הצליח. בינתיים, הפירוק לגורמים של קוד *DT הוא עדיין אחד מהנושאים הלא מפותחים ב-Eclipse.

במובן מסוים, פרויקט Handly נועד לפתור בערך את אותן בעיות כמו EMF, אבל עבור מודלים מבוססי ידיות, ובעיקר שפה (כלומר, מייצג אלמנטים של המבנה של שפת תכנות כלשהי). היעדים העיקריים שנקבעו בעת עיצוב Handly מפורטים להלן:

• זיהוי ההפשטות העיקריות של תחום הנושא.
• צמצום המאמץ ושיפור איכות ההטמעה של מודלים של שפה מבוססי ידית באמצעות שימוש חוזר בקוד.
• מתן API מאוחד ברמת מטה למודלים המתקבלים, מה שמאפשר ליצור רכיבי IDE נפוצים שעובדים עם מודלים מבוססי ידית שפה.
• גמישות ומדרגיות.
• אינטגרציה עם Xtext (בשכבה נפרדת).

כדי להדגיש מושגים ופרוטוקולים נפוצים, נותחו יישומים קיימים של מודלים מבוססי ידית שפה. הממשקים העיקריים והיישומים הבסיסיים המסופקים על ידי Handly מוצגים באיור. 8.

אורז. 8. ממשקים נפוצים והטמעות בסיסיות של רכיבי Handly

ממשק IElement מייצג את הידית של אלמנט ומשותף לאלמנטים של כל הדגמים המבוססים על Handly. אלמנט המחלקה המופשט מיישם את מנגנון הידית/גוף המוכלל (איור 9).

אורז. 9. IElement והטמעת ידית/גוף גנרית

בנוסף, Handly מספקת מנגנון כללי להודעה על שינויים ברכיבי הדגם (איור 10). כפי שניתן לראות, הוא דומה במידה רבה למנגנוני ההודעות המיושמים במודל המשאבים ובמודל ה-Java, ומשתמש ב-IElementDelta כדי לספק ייצוג אחיד של מידע על שינוי אלמנטים.

אורז. 10. ממשקים כלליים והטמעות בסיסיות של מנגנון ההודעות Handly

ניתן להשתמש בחלק Handly שנדון לעיל (איור 9 ו-10) כדי לייצג כמעט כל מודל מבוסס ידית. ליצירה לשוני מודלים, הפרויקט מציע פונקציונליות נוספת - בפרט, ממשקים נפוצים והטמעות בסיסיות עבור אלמנטים של מבנה טקסט המקור, מה שנקרא מרכיבי מקור (איור 8). ממשק ISourceFile מייצג קובץ מקור, ו-ISourceConstruct מייצג אלמנט בתוך קובץ המקור. המחלקות המופשטות SourceFile ו-SourceConstruct מיישמות מנגנונים כלליים לתמיכה בעבודה עם קבצי מקור והאלמנטים שלהם, למשל עבודה עם מאגרי טקסט, חיבור לקואורדינטות של אלמנט בטקסט המקור, התאמה של מודלים עם התוכן הנוכחי של מאגר עותק עבודה , וכו. הטמעת מנגנונים אלו היא בדרך כלל אתגר לא קטן, והנדי יכולה להפחית משמעותית את המאמץ בפיתוח מודלים של שפה מבוססי ידיות על ידי מתן הטמעות בסיסיות באיכות גבוהה.

בנוסף למנגנוני הליבה המפורטים לעיל, Handly מספקת תשתית למאגרי טקסט ותצלומי מצב, תמיכה באינטגרציה עם עורכי קוד מקור (כולל אינטגרציה מחוץ לקופסה עם עורך Xtext), כמו גם כמה רכיבי ממשק משתמש נפוצים עבודה עם עורכי קוד מקור. מודלים שימושיים כגון מסגרת מתאר. כדי להמחיש את יכולותיו, הפרויקט מספק מספר דוגמאות, כולל הטמעה של מודל Java ב-Handly. (בהשוואה למימוש המלא של מודל ה-Java ב-JDT, מודל זה מפושט מעט בכוונה לצורך בהירות רבה יותר.)

כפי שצוין קודם לכן, דגש מרכזי במהלך התכנון הראשוני של Handly והפיתוח שלאחר מכן היה וממשיך להיות מדרגיות וגמישות.

באופן עקרוני, מודלים מבוססי ידית מתקדמים די טוב "לפי עיצוב". לדוגמה, ניב הידית/גוף מאפשר לך להגביל את כמות הזיכרון הנצרכת על ידי דגם. אבל יש גם ניואנסים. לפיכך, בעת בדיקת Handly עבור מדרגיות, התגלתה בעיה ביישום מנגנון ההתראות - כאשר שונו מספר רב של אלמנטים, בניית deltas לקחה יותר מדי זמן. התברר שאותה בעיה הייתה קיימת במודל JDT Java, ממנו הותאם פעם הקוד המתאים. תיקנו את הבאג ב-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 כמו שפת התכנות המובנית ושפת השאילתה . מוצר אחר פחות מוכר לציבור הרחב. זֶה סטודיו קודאסיפ, סביבת עיצוב משולבת עבור מעבד ערכת הוראות ספציפי ליישום (ASIP), בשימוש הן בתוך החברה הצ'כית Codasip עצמה והן על ידי לקוחותיה, כולל AMD, AVG, ריהוט, סיגמא עיצובים. Codasip משתמשת ב- Handly בייצור מאז 2015, החל מגרסה Handly 0.2. המהדורה האחרונה של Codasip Studio משתמשת בגרסה 0.5, שפורסמה ביוני 2016. Ondřej Ilčík, שמוביל פיתוח IDE ב-Codasip, נמצא בקשר עם הפרויקט, ומספק משוב חיוני בשם "המאמץ של הצד השלישי". הוא אפילו הצליח למצוא קצת זמן פנוי להשתתף ישירות בפיתוח הפרויקט, תוך הטמעת שכבת ממשק משתמש (~4000 שורות קוד) עבור אחת הדוגמאות של Handly, מודל Java. מידע מפורט יותר ממקור ראשון על השימוש ב-Handly על ידי מאמצים ניתן למצוא בעמוד סיפורי הצלחה פּרוֹיֶקט.

אנו מקווים שאחרי שחרורו של גרסה 1.0 עם הבטחה ליציבות API והפרויקט שיוצא ממצב הדגירה, ל-Handly יהיו מאמצים חדשים. בינתיים, הפרויקט ממשיך לבחון ולשפר עוד יותר את ה-API, ומוציא שתי מהדורות "עיקריות" בשנה - ביוני (אותו תאריך לשחרור Eclipse בו-זמנית) ובדצמבר, מה שמספק לוח זמנים צפוי שהמאמצים יכולים לסמוך עליו. אנו יכולים גם להוסיף ש"שיעור הבאגים" של הפרויקט נשאר ברמה נמוכה באופן עקבי, והאנדלי עובדת בצורה אמינה במוצרים של מאמצים מוקדמים כבר מהגרסאות הראשונות. כדי לחקור עוד יותר את Eclipse Handly, אתה יכול להשתמש הדרכה לתחילת העבודה и סקירה אדריכלית.

מקור: www.habr.com