Eclipse, როგორც ტექნოლოგიური პლატფორმა 1C: Enterprise Development Tools-ისთვის

Შესაძლოა, Eclipse დიდი ხანია არ სჭირდებოდა სპეციალური შესავალი. ბევრი ადამიანი იცნობს Eclipse-ს Eclipse Java-ის განვითარების ინსტრუმენტების წყალობით (JDT). ეს არის პოპულარული ღია კოდის Java IDE, რომელსაც დეველოპერების უმეტესობა ასოცირდება სიტყვასთან "Eclipse". თუმცა, Eclipse არის როგორც გაფართოებადი პლატფორმა განვითარების ინსტრუმენტების ინტეგრირებისთვის (Eclipse Platform), ასევე მის ბაზაზე აგებული მთელი რიგი IDE, მათ შორის JDT. Eclipse არის როგორც Eclipse Project, უმაღლესი დონის პროექტი, რომელიც კოორდინაციას უწევს Eclipse პლატფორმისა და JDT-ის განვითარებას, ასევე Eclipse SDK, ამ განვითარების მიწოდებულ შედეგს. დაბოლოს, Eclipse არის ღია კოდის ფონდი, პროექტების უზარმაზარი საზოგადოებათი, რომელთაგან ყველა არ არის დაწერილი Java-ში ან დაკავშირებული არ არის განვითარების ინსტრუმენტებთან (მაგალითად, პროექტები Eclipse IoT и დაბნელების მეცნიერება). Eclipse-ის სამყარო ძალიან მრავალფეროვანია.

ამ სტატიაში, რომელიც ბუნებით მიმოხილულია, შევეცდებით გადავხედოთ Eclipse არქიტექტურის საფუძვლებს, როგორც პლატფორმას ინტეგრირებული განვითარების ინსტრუმენტების შესაქმნელად და მივცეთ საწყისი იდეა Eclipse კომპონენტების შესახებ, რომლებიც ქმნიან ტექნოლოგიის საფუძველს. პლატფორმა "ახალი კონფიგურატორისთვის" 1C: Enterprise. 1C: საწარმოს განვითარების ინსტრუმენტები. რა თქმა უნდა, ასეთი მიმოხილვა აუცილებლად იქნება ძირითადად ზედაპირული და საკმაოდ შეზღუდული, მათ შორის იმიტომ, რომ ჩვენ ყურადღებას ვამახვილებთ არა მხოლოდ Eclipse-ის დეველოპერებზე, როგორც სამიზნე აუდიტორიაზე. თუმცა, ვიმედოვნებთ, რომ Eclipse-ის გამოცდილი დეველოპერებიც კი შეძლებენ სტატიაში საინტერესო ინფორმაციის მოძიებას. მაგალითად, ვისაუბრებთ ერთ-ერთ „დაბნელების საიდუმლოზე“, შედარებით ახალ და ნაკლებად ცნობილ პროექტზე. Eclipse Handly, რომელიც დაარსდა და მხარს უჭერდა 1C.

Eclipse Architecture-ის შესავალი

მოდით, ჯერ შევხედოთ Eclipse არქიტექტურის რამდენიმე ზოგად ასპექტს მაგალითის გამოყენებით Eclipse Java განვითარების ინსტრუმენტები (JDT). JDT-ის მაგალითის არჩევა შემთხვევითი არ არის. ეს არის პირველი ინტეგრირებული განვითარების გარემო, რომელიც გამოჩნდა Eclipse-ში. სხვა *DT Eclipse პროექტები, როგორიცაა Eclipse C/C++ Development Tooling (CDT), შეიქმნა მოგვიანებით და ისესხეს როგორც ძირითადი არქიტექტურული პრინციპები, ასევე ინდივიდუალური კოდის ფრაგმენტები JDT-დან. JDT-ში ჩამოყალიბებული არქიტექტურის საფუძვლები დღემდე აქტუალურია Eclipse პლატფორმის თავზე აგებული თითქმის ნებისმიერი IDE-სთვის, მათ შორის 1C: Enterprise Development Tools.

უპირველეს ყოვლისა, უნდა აღინიშნოს, რომ Eclipse-ს ახასიათებს საკმაოდ მკაფიო არქიტექტურული ფენა, ენიდან დამოუკიდებელი ფუნქციონალური განცალკევებით ფუნქციონალებისგან, რომლებიც შექმნილია კონკრეტული პროგრამირების ენების მხარდასაჭერად, და UI-დან დამოუკიდებელი „ძირითადი“ კომპონენტების გამოყოფა დაკავშირებული კომპონენტებისგან. დამხმარე მომხმარებლის ინტერფეისით.

ამრიგად, Eclipse პლატფორმა განსაზღვრავს საერთო, ენიდან დამოუკიდებელ ინფრასტრუქტურას და Java-ს განვითარების ინსტრუმენტები ამატებენ სრულყოფილ Java IDE-ს Eclipse-ს. Eclipse პლატფორმა და JDT შედგება რამდენიმე კომპონენტისგან, რომელთაგან თითოეული ეკუთვნის UI-დან დამოუკიდებელ „ბირთს“ ან UI ფენას (სურათი 1).

ბრინჯი. 1. Eclipse Platform და JDT

მოდით ჩამოვთვალოთ Eclipse პლატფორმის ძირითადი კომპონენტები:

• Runtime — განსაზღვრავს დანამატის ინფრასტრუქტურას. დაბნელება ხასიათდება მოდულარული არქიტექტურით. არსებითად, Eclipse არის "გაფართოების წერტილების" და "გაფართოებების" კოლექცია.
• სამუშაო სივრცე — მართავს ერთ ან მეტ პროექტს. პროექტი შედგება საქაღალდეებისა და ფაილებისგან, რომლებიც პირდაპირ არის დატანილი ფაილურ სისტემაში.
• სტანდარტული ვიჯეტის ხელსაწყოების ნაკრები (SWT) - უზრუნველყოფს ოპერაციულ სისტემასთან ინტეგრირებულ მომხმარებლის ინტერფეისის ძირითად ელემენტებს.
• JFace — გთავაზობთ უამრავ UI ჩარჩოს, რომელიც აგებულია SWT-ზე.
• Workbench — განსაზღვრავს Eclipse UI პარადიგმას: რედაქტორები, ხედები, პერსპექტივები.

უნდა ითქვას, რომ Eclipse პლატფორმა ასევე გთავაზობთ ბევრ სხვა სასარგებლო კომპონენტს ინტეგრირებული განვითარების ინსტრუმენტების შესაქმნელად, მათ შორის Debug, Compare, Search და Team. განსაკუთრებული აღნიშვნის ღირსია JFace Text - წყარო კოდის „ჭკვიანი რედაქტორების“ შექმნის საფუძველი. სამწუხაროდ, ამ კომპონენტების, ისევე როგორც ინტერფეისის ფენის კომპონენტების ზედმიწევნითი გამოკვლევაც კი შეუძლებელია ამ სტატიის ფარგლებში, ამიტომ ამ განყოფილების დარჩენილ ნაწილში ჩვენ შემოვიფარგლებით ძირითადი „ძირითადი“ კომპონენტების მიმოხილვით. 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 მოდული) პასუხისმგებელია სამუშაო სივრცისა და მისი რესურსების მხარდაჭერაზე. კერძოდ, ეს კომპონენტი უზრუნველყოფს პროგრამულ წვდომას სამუშაო სივრცეში ფორმაში რესურსების მოდელები. ამ მოდელთან ეფექტური მუშაობისთვის, კლიენტებს სჭირდებათ რესურსის ბმულის წარმოდგენის მარტივი გზა. ამ შემთხვევაში, სასურველი იქნებოდა ობიექტის დამალვა, რომელიც უშუალოდ ინახავს მოდელში რესურსის მდგომარეობას კლიენტის წვდომისგან. წინააღმდეგ შემთხვევაში, მაგალითად, ფაილის წაშლის შემთხვევაში, კლიენტს შეუძლია გააგრძელოს ობიექტის შენახვა, რომელიც აღარ არის მოდელში, თანმდევი პრობლემებით. Eclipse ამ პრობლემას აგვარებს რაღაც ე.წ გაუმკლავდეს რესურსი. Handle მოქმედებს როგორც გასაღები (მან იცის მხოლოდ რესურსისკენ მიმავალი გზა სამუშაო სივრცეში) და მთლიანად აკონტროლებს წვდომას შიდა მოდელის ობიექტზე, რომელიც პირდაპირ ინახავს ინფორმაციას რესურსის მდგომარეობის შესახებ. ეს დიზაინი არის ნიმუშის ვარიაცია სახელური/სხეული.

ბრინჯი. სურათი 2 ასახავს Handle/Body იდიომას, რომელიც გამოიყენება რესურსის მოდელზე. IResource ინტერფეისი წარმოადგენს რესურსის სახელურს და არის API, განსხვავებით Resource კლასისგან, რომელიც ახორციელებს ამ ინტერფეისს და ResourceInfo კლასისგან, რომელიც წარმოადგენს სხეულს, რომელიც არ არის API. ჩვენ ხაზს ვუსვამთ, რომ handle-მა იცის მხოლოდ რესურსისკენ მიმავალი გზა სამუშაო სივრცის ფესვთან მიმართებაში და არ შეიცავს რესურსის ინფორმაციის ბმულს. რესურსის ინფორმაციის ობიექტები ქმნიან ეგრეთ წოდებულ "ელემენტის ხეს". მონაცემთა ეს სტრუქტურა მთლიანად მატერიალიზებულია მეხსიერებაში. რესურსის ინფორმაციის ინსტანციის საპოვნელად, რომელიც შეესაბამება სახელურს, ელემენტის ხე გაივლება ამ სახელურში შენახული ბილიკის მიხედვით.

ბრინჯი. 2. IResource და ResourceInfo

როგორც მოგვიანებით დავინახავთ, რესურსის მოდელის ძირითადი დიზაინი (შეიძლება მას სახელურზე დაფუძნებული ვუწოდოთ) გამოიყენება Eclipse-ში სხვა მოდელებისთვისაც. ახლა მოდით ჩამოვთვალოთ ამ დიზაინის ზოგიერთი გამორჩეული თვისება:

• სახელური არის ღირებულების ობიექტი. ღირებულების ობიექტები არის უცვლელი ობიექტები, რომელთა თანასწორობა არ ემყარება იდენტობას. ასეთი ობიექტები შეიძლება უსაფრთხოდ იქნას გამოყენებული, როგორც გასაღებად დაქუცმაცებულ კონტეინერებში. სახელურის მრავალმა შემთხვევამ შეიძლება მიუთითოს ერთი და იგივე რესურსი. მათი შესადარებლად, თქვენ უნდა გამოიყენოთ Equals (Object) მეთოდი.
• Handle განსაზღვრავს რესურსის ქცევას, მაგრამ არ შეიცავს ინფორმაციას რესურსის მდგომარეობის შესახებ (ერთადერთი მონაცემი, რომელიც მას ინახავს არის "გასაღები", რესურსისკენ მიმავალი გზა).
• Handle შეიძლება მიუთითებდეს რესურსზე, რომელიც არ არსებობს (ან რესურსი, რომელიც ჯერ არ არის შექმნილი, ან რესურსი, რომელიც უკვე წაშლილია). რესურსის არსებობის შემოწმება შესაძლებელია IResource.exists() მეთოდის გამოყენებით.
• ზოგიერთი ოპერაციების განხორციელება შესაძლებელია მხოლოდ სახელურში შენახული ინფორმაციის საფუძველზე (ე.წ. მხოლოდ სახელური ოპერაციები). მაგალითებია IResource.getParent(), getFullPath() და ა.შ. რესურსი არ არის საჭირო, რომ ასეთი ოპერაცია წარმატებული იყოს. ოპერაციები, რომლებიც საჭიროებენ რესურსის არსებობას წარმატებისთვის, აგდებენ CoreException, თუ რესურსი არ არსებობს.

Eclipse უზრუნველყოფს ეფექტურ მექანიზმს სამუშაო სივრცის რესურსების ცვლილებების შესახებ შეტყობინებისთვის (სურათი 3). რესურსები შეიძლება შეიცვალოს ან Eclipse IDE-ში შესრულებული მოქმედებების შედეგად, ან ფაილურ სისტემასთან სინქრონიზაციის შედეგად. ორივე შემთხვევაში, კლიენტებს, რომლებიც გამოიწერენ შეტყობინებებს, ეძლევათ დეტალური ინფორმაცია ცვლილებების შესახებ „რესურსების დელტას“ სახით. დელტა აღწერს სამუშაო სივრცის რესურსის (ქვე)ხის ორ მდგომარეობას შორის ცვლილებებს და თავისთავად არის ხე, რომლის თითოეული კვანძი აღწერს ცვლილებას რესურსში და შეიცავს დელტათა სიას შემდეგ დონეზე, რომლებიც აღწერს ცვლილებებს ბავშვის რესურსებში.

ბრინჯი. 3. IResourceChangeEvent და IResourceDelta

რესურსების დელტაზე დაფუძნებული შეტყობინების მექანიზმს აქვს შემდეგი მახასიათებლები:

• ერთი ცვლილება და მრავალი ცვლილება აღწერილია იმავე სტრუქტურის გამოყენებით, რადგან დელტა აგებულია რეკურსიული კომპოზიციის პრინციპით. აბონენტ კლიენტებს შეუძლიათ რესურსის ცვლილების შეტყობინებების დამუშავება დელტას ხის მეშვეობით რეკურსიული წარმოშობის გამოყენებით.
• დელტა შეიცავს სრულ ინფორმაციას რესურსში ცვლილებების შესახებ, მათ შორის მისი გადაადგილების ან/და მასთან დაკავშირებული „მარკერების“ ცვლილებების შესახებ (მაგალითად, კომპილაციის შეცდომები წარმოდგენილია მარკერების სახით).
• ვინაიდან რესურსის მითითება ხდება სახელურის მეშვეობით, დელტას შეუძლია ბუნებრივია მიმართოს დისტანციურ რესურსს.

როგორც მალე დავინახავთ, რესურსის მოდელის ცვლილების შეტყობინებების მექანიზმის დიზაინის ძირითადი კომპონენტები ასევე აქტუალურია სახელურზე დაფუძნებული სხვა მოდელებისთვის.

JDT Core

Eclipse სამუშაო სივრცის რესურსის მოდელი არის ფუნდამენტური ენა-აგნოსტიკური მოდელი. JDT Core კომპონენტი (მოდული org.eclipse.jdt.core) უზრუნველყოფს API-ს სამუშაო სივრცის სტრუქტურის ნავიგაციისა და ანალიზისთვის Java-ს პერსპექტივიდან, ე.წ. „ჯავას მოდელი“ (ჯავის მოდელი). ეს API განისაზღვრება Java ელემენტების მიხედვით, განსხვავებით ძირითადი რესურსის მოდელის API-სგან, რომელიც განისაზღვრება საქაღალდეებისა და ფაილების მიხედვით. Java ელემენტის ხის ძირითადი ინტერფეისები ნაჩვენებია ნახ. 4.

ბრინჯი. 4. ჯავის მოდელის ელემენტები

ჯავის მოდელი იყენებს იგივე სახელურს/სხეულის იდიომს, როგორც რესურსის მოდელს (სურათი 5). IJavaElement არის სახელური, ხოლო JavaElementInfo ასრულებს სხეულის როლს. IJavaElement ინტერფეისი განსაზღვრავს პროტოკოლს, რომელიც საერთოა Java-ის ყველა ელემენტისთვის. მისი ზოგიერთი მეთოდი მხოლოდ სახელურია: getElementName(), getParent() და ა.შ. JavaElementInfo ობიექტი ინახავს შესაბამისი ელემენტის მდგომარეობას: მის სტრუქტურას და ატრიბუტებს.

ბრინჯი. 5. IJavaElement და JavaElementInfo

ჯავის მოდელს აქვს გარკვეული განსხვავებები ძირითადი სახელურის/სხეულის დიზაინის განხორციელებაში რესურსის მოდელთან შედარებით. როგორც ზემოთ აღინიშნა, რესურსის მოდელში ელემენტის ხე, რომლის კვანძები რესურსის ინფორმაციის ობიექტებია, მთლიანად შეიცავს მეხსიერებაში. მაგრამ ჯავის მოდელს შეიძლება ჰქონდეს ელემენტების გაცილებით მეტი რაოდენობა, ვიდრე რესურსების ხე, რადგან ის ასევე წარმოადგენს .java და .class ფაილების შიდა სტრუქტურას: ტიპებს, ველებს და მეთოდებს.

მეხსიერებაში ელემენტების მთელი ხის სრული მატერიალიზაციის თავიდან ასაცილებლად, ჯავის მოდელის დანერგვა იყენებს ელემენტის ინფორმაციის შეზღუდული ზომის LRU ქეშს, სადაც გასაღები არის IJavaElement სახელური. ელემენტის ინფორმაციის ობიექტები იქმნება მოთხოვნისამებრ, როდესაც ხდება ელემენტის ხე ნავიგაცია. ამ შემთხვევაში, ყველაზე ნაკლებად ხშირად გამოყენებული ელემენტი გამოიდევნება ქეშიდან და მოდელის მეხსიერების მოხმარება შეზღუდულია მითითებული ქეშის ზომით. ეს არის სახელურზე დაფუძნებული დიზაინის კიდევ ერთი უპირატესობა, რომელიც სრულად მალავს ამ განხორციელების დეტალებს კლიენტის კოდიდან.

ჯავის ელემენტების ცვლილებების შეტყობინების მექანიზმი ზოგადად მსგავსია ზემოთ განხილული სამუშაო სივრცის რესურსებში ცვლილებების თვალყურის დევნების მექანიზმს. კლიენტი, რომელსაც სურს აკონტროლოს Java მოდელის ცვლილებები, გამოიწერს შეტყობინებებს, რომლებიც წარმოდგენილია როგორც ElementChangedEvent ობიექტი, რომელიც შეიცავს IJavaElementDelta-ს (სურათი 6).

ბრინჯი. 6. ElementChangedEvent და IJavaElementDelta

ჯავის მოდელი არ შეიცავს ინფორმაციას მეთოდის ორგანოების ან სახელების გარჩევადობის შესახებ, ამიტომ Java-ში დაწერილი კოდის დეტალური ანალიზისთვის JDT Core გთავაზობთ დამატებით (არასახელურზე დაფუძნებულ) მოდელს: აბსტრაქტული სინტაქსის ხე (აბსტრაქტული სინტაქსის ხე, AST). AST წარმოადგენს საწყისი ტექსტის გარჩევის შედეგს. AST კვანძები შეესაბამება წყაროს მოდულის სტრუქტურის ელემენტებს (განცხადებები, ოპერატორები, გამონათქვამები და ა. ბმულების ფორმა ე.წ სავალდებულო. Bindings არის ობიექტები, რომლებიც წარმოადგენენ დასახელებულ ერთეულებს, როგორიცაა ტიპები, მეთოდები და ცვლადები, რომლებიც ცნობილია შემდგენელისთვის. AST კვანძებისგან განსხვავებით, რომლებიც ქმნიან ხეს, აკინძები მხარს უჭერენ ჯვარედინი მითითებას და ზოგადად ქმნიან გრაფიკს. აბსტრაქტული კლასი ASTNode არის საერთო საბაზისო კლასი ყველა AST კვანძისთვის. ASTNode ქვეკლასები შეესაბამება Java ენის კონკრეტულ სინტაქსურ კონსტრუქტებს.

იმის გამო, რომ სინტაქსურ ხეებს შეუძლიათ მეხსიერების მნიშვნელოვანი მოხმარება, JDT ქეშირებს მხოლოდ ერთ AST-ს აქტიური რედაქტორისთვის. Java მოდელისგან განსხვავებით, AST ჩვეულებრივ განიხილება, როგორც "შუალედური", "დროებითი" მოდელი, რომლის წევრები არ უნდა იყოს მითითებული კლიენტების მიერ იმ ოპერაციის კონტექსტის მიღმა, რამაც გამოიწვია AST-ის შექმნა.

ჩამოთვლილი სამი მოდელი (Java მოდელი, AST, აკინძები) ერთად ქმნიან საფუძველს JDT-ში „ინტელექტუალური განვითარების ინსტრუმენტების“ შესაქმნელად, მათ შორის ძლიერი Java რედაქტორი სხვადასხვა „დამხმარებით“, სხვადასხვა ქმედებები წყაროს კოდის დასამუშავებლად (მათ შორის იმპორტის სიის ორგანიზება. სახელები და ფორმატირება მორგებული სტილის მიხედვით), საძიებო და რეფაქტორირების ხელსაწყოები. ამ შემთხვევაში ჯავის მოდელი განსაკუთრებულ როლს ასრულებს, რადგან სწორედ ის გამოიყენება, როგორც საფუძველი შემუშავებული აპლიკაციის სტრუქტურის ვიზუალური წარმოდგენისთვის (მაგალითად, Package Explorer, Outline, Search, Call Hierarchy და ტიპი იერარქია).

Eclipse კომპონენტები, რომლებიც გამოიყენება 1C: Enterprise Developments Tools-ში

ნახ. სურათი 7 გვიჩვენებს Eclipse-ის კომპონენტებს, რომლებიც ქმნიან ტექნოლოგიური პლატფორმის საფუძველს 1C: Enterprise Development Tools-ისთვის.

ბრინჯი. 7. Eclipse, როგორც პლატფორმა 1C: Enterprise Development Tools-ისთვის

Eclipse პლატფორმა უზრუნველყოფს ძირითად ინფრასტრუქტურას. ჩვენ გადავხედეთ ამ ინფრასტრუქტურის ზოგიერთ ასპექტს წინა ნაწილში.

Eclipse Modeling Framework (EMF) უზრუნველყოფს სტრუქტურირებული მონაცემების მოდელირების ზოგად საშუალებებს. EMF ინტეგრირებულია Eclipse პლატფორმასთან, მაგრამ ასევე შეიძლება ცალკე გამოიყენებოდეს ჩვეულებრივ Java აპლიკაციებში. ხშირად, Eclipse-ის ახალი დეველოპერები უკვე კარგად იცნობენ EMF-ს, თუმცა მათ ჯერ კიდევ არ ესმით Eclipse პლატფორმის სირთულეები. ასეთი დამსახურებული პოპულარობის ერთ-ერთი მიზეზი არის უნივერსალური დიზაინი, რომელიც მოიცავს, სხვა საკითხებთან ერთად, ერთიანი მეტა დონის API, რომელიც საშუალებას გაძლევთ იმუშაოთ ნებისმიერ EMF მოდელთან ზოგადი გზით. EMF-ის მიერ მოწოდებული მოდელის ობიექტების ძირითადი დანერგვა და მეტამოდელზე დაფუძნებული მოდელის კოდის გენერირების ქვესისტემა მნიშვნელოვნად ზრდის განვითარების სიჩქარეს და ამცირებს შეცდომების რაოდენობას. EMF ასევე შეიცავს მექანიზმებს მოდელების სერიალიზაციისთვის, მოდელში ცვლილებების თვალყურის დევნებისთვის და მრავალი სხვა.

ნებისმიერი ჭეშმარიტად ზოგადი დანიშნულების ხელსაწყოს მსგავსად, EMF შესაფერისია მოდელირების პრობლემების ფართო სპექტრის გადასაჭრელად, მაგრამ მოდელების ზოგიერთი კლასი (მაგალითად, სახელურზე დაფუძნებული მოდელები ზემოთ განხილული) შეიძლება მოითხოვოს უფრო სპეციალიზებული მოდელირების ხელსაწყოები. EMF-ზე ლაპარაკი მადლიერი ამოცანაა, განსაკუთრებით ერთი სტატიის შეზღუდულ ფარგლებში, რადგან ეს ცალკე წიგნის თემაა და საკმაოდ სქელი. მოდით მხოლოდ აღვნიშნოთ, რომ EMF-ის საფუძვლად არსებული განზოგადებების მაღალი ხარისხის სისტემამ დაუშვა მოდელირებაზე მიძღვნილი პროექტების მთელი რიგის დაბადება, რომლებიც შედის უმაღლესი დონის პროექტში. Eclipse მოდელირება თავად 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 უმაღლესი დონის პროექტის ქვეპროექტი, გაჩნდა 1 წელს 2014C-ის მიერ Eclipse Foundation-ში საწყისი კოდის შეტანის შედეგად. მას შემდეგ 1C აგრძელებს პროექტის განვითარების მხარდაჭერას: Handly committers კომპანიის თანამშრომლები არიან. პროექტი მცირეა, მაგრამ ის საკმაოდ უნიკალურ ნიშას იკავებს Eclipse-ში: მისი მთავარი მიზანია ხელი შეუწყოს სახელურზე დაფუძნებული მოდელების განვითარებას.

სახელურზე დაფუძნებული მოდელების ძირითადი არქიტექტურული პრინციპები, როგორიცაა სახელური/სხეულის იდიომა, ზემოთ იყო განხილული რესურსის მოდელის და ჯავის მოდელის მაგალითების გამოყენებით. მან ასევე აღნიშნა, რომ როგორც რესურსის მოდელი, ასევე ჯავის მოდელი მნიშვნელოვანი საფუძველია Eclipse Java-ის განვითარების ინსტრუმენტებისთვის (JDT). და რადგანაც თითქმის ყველა *DT Eclipse პროექტს აქვს JDT-ის მსგავსი არქიტექტურა, დიდი გაზვიადება არ იქნება იმის თქმა, რომ სახელურზე დაფუძნებული მოდელები ეფუძნება Eclipse პლატფორმის თავზე აგებულ ბევრ, თუ არა ყველა IDE-ს. მაგალითად, Eclipse C/C++ განვითარების ინსტრუმენტს (CDT) აქვს სახელურზე დაფუძნებული C/C++ მოდელი, რომელიც იგივე როლს ასრულებს CDT არქიტექტურაში, როგორც ჯავის მოდელი JDT-ში.

Handly-მდე Eclipse არ სთავაზობდა სპეციალიზებულ ბიბლიოთეკებს სახელურზე დაფუძნებული ენის მოდელების შესაქმნელად. ამჟამად არსებული მოდელები შეიქმნა ძირითადად ჯავის მოდელის კოდის უშუალო ადაპტირებით (აკა კოპირება/პასტი), იმ შემთხვევებში, როდესაც ის საშუალებას იძლევა Eclipse საჯარო ლიცენზია (EPL). (ცხადია, ეს ჩვეულებრივ არ არის იურიდიული საკითხი, ვთქვათ, Eclipse-ის პროექტებისთვის, მაგრამ არა დახურული წყაროს პროდუქტებისთვის.) თანდაყოლილი შემთხვევითობის გარდა, ეს ტექნიკა აჩენს ცნობილ პრობლემებს: კოდის დუბლირებას, რომელიც შემოტანილია შეცდომებთან ადაპტაციის დროს, და ა.შ. უარესი ის არის, რომ მიღებული მოდელები რჩება „თავისთავად“ და არ სარგებლობენ გაერთიანების პოტენციალით. მაგრამ სახელურზე დაფუძნებული ენობრივი მოდელებისთვის საერთო ცნებებისა და პროტოკოლების იზოლირებამ შეიძლება გამოიწვიოს მათთან მუშაობისთვის მრავალჯერადი გამოყენების კომპონენტების შექმნა, ისევე როგორც EMF-ის შემთხვევაში.

Eclipse-ს არ ესმოდა ეს საკითხები. ჯერ კიდევ 2005 წელს მარტინ აშლიმანიCDT პროტოტიპის შემუშავების გამოცდილების შეჯამება, კამათობდა ენის მოდელებისთვის საერთო ინფრასტრუქტურის შექმნის აუცილებლობა, სახელურზე დაფუძნებული მოდელების ჩათვლით. მაგრამ, როგორც ხშირად ხდება, უფრო პრიორიტეტული ამოცანების გამო, ამ იდეების განხორციელება არასოდეს მიუღწევია. იმავდროულად, *DT კოდის ფაქტორიზაცია კვლავ ერთ-ერთი განუვითარებელი თემაა Eclipse-ში.

გარკვეული გაგებით, Handly პროექტი შექმნილია დაახლოებით იგივე პრობლემების გადასაჭრელად, როგორც EMF, მაგრამ სახელურზე დაფუძნებული მოდელებისთვის და, პირველ რიგში, ენისთვის (ანუ ზოგიერთი პროგრამირების ენის სტრუქტურის ელემენტებს წარმოადგენს). Handly-ის დიზაინის დროს დასახული ძირითადი მიზნები ჩამოთვლილია ქვემოთ:

• საგნობრივი არეალის ძირითადი აბსტრაქციების იდენტიფიცირება.
• ძალისხმევის შემცირება და სახელურზე დაფუძნებული ენის მოდელების განხორციელების ხარისხის გაუმჯობესება კოდის ხელახალი გამოყენების გზით.
• მიღებული მოდელებისთვის ერთიანი მეტა დონის API-ის მიწოდება, რაც შესაძლებელს გახდის შექმნას საერთო IDE კომპონენტები, რომლებიც მუშაობენ ენაზე დაფუძნებულ მოდელებზე.
• მოქნილობა და მასშტაბურობა.
• ინტეგრაცია Xtext-თან (ცალკე ფენაში).

საერთო ცნებებისა და პროტოკოლების ხაზგასასმელად, გაანალიზდა ენების სახელურზე დაფუძნებული მოდელების არსებული იმპლემენტაციები. Handly-ის მიერ მოწოდებული ძირითადი ინტერფეისები და ძირითადი დანერგვები ნაჩვენებია ნახ. 8.

ბრინჯი. 8. Handly ელემენტების საერთო ინტერფეისები და ძირითადი დანერგვები

IElement ინტერფეისი წარმოადგენს ელემენტის სახელურს და საერთოა Handly-ზე დაფუძნებული ყველა მოდელის ელემენტებისთვის. აბსტრაქტული კლასი Element ახორციელებს განზოგადებულ სახელურ/სხეულის მექანიზმს (ნახ. 9).

ბრინჯი. 9. IElement და generic handle/body განხორციელება

გარდა ამისა, Handly უზრუნველყოფს განზოგადებულ მექანიზმს მოდელის ელემენტების ცვლილებების შესახებ შეტყობინებისთვის (ნახ. 10). როგორც ხედავთ, ის ფართოდ წააგავს რესურსის მოდელსა და ჯავის მოდელში განხორციელებულ შეტყობინების მექანიზმებს და იყენებს IElementDelta-ს ელემენტის ცვლილების ინფორმაციის ერთიანი წარმოდგენის უზრუნველსაყოფად.

ბრინჯი. 10. Handly შეტყობინების მექანიზმის ზოგადი ინტერფეისები და ძირითადი დანერგვები

ზემოთ განხილული Handly ნაწილი (ნახ. 9 და 10) შეიძლება გამოყენებულ იქნას თითქმის ნებისმიერი სახელურზე დაფუძნებული მოდელის წარმოსაჩენად. შესაქმნელად ლინგვისტური მოდელები, პროექტი გთავაზობთ დამატებით ფუნქციონირებას - კერძოდ, საერთო ინტერფეისებს და ძირითად იმპლემენტაციებს საწყისი ტექსტის სტრუქტურის ელემენტების, ე.წ. წყარო ელემენტები (ნახ. 8). ISourceFile ინტერფეისი წარმოადგენს წყაროს ფაილს, ხოლო ISourceConstruct წარმოადგენს ელემენტს წყაროს ფაილში. აბსტრაქტული კლასები SourceFile და SourceConstruct ახორციელებენ განზოგადებულ მექანიზმებს წყაროს ფაილებთან და მათ ელემენტებთან მუშაობის მხარდასაჭერად, მაგალითად, ტექსტის ბუფერებთან მუშაობა, ელემენტის კოორდინატებთან დაკავშირება წყარო ტექსტში, მოდელების შეჯერება სამუშაო ასლის ბუფერის მიმდინარე შინაარსთან. და ა.შ. ამ მექანიზმების დანერგვა, როგორც წესი, საკმაოდ გამოწვევაა და Handly-ს შეუძლია მნიშვნელოვნად შეამციროს სახელურზე დაფუძნებული ენის მოდელების შემუშავების ძალისხმევა მაღალი ხარისხის საბაზისო განხორციელების მიწოდებით.

ზემოთ ჩამოთვლილი ძირითადი მექანიზმების გარდა, Handly უზრუნველყოფს ინფრასტრუქტურას ტექსტის ბუფერებისთვის და სნეპშოტებისთვის, წყაროს კოდის რედაქტორებთან ინტეგრაციის მხარდაჭერას (მათ შორის, Xtext რედაქტორთან ინტეგრაციის გარეშე), ასევე ზოგიერთ საერთო UI კომპონენტს, რომელიც იმუშავეთ წყაროს კოდის რედაქტორებთან. მოსახერხებელი მოდელები, როგორიცაა კონტურის ჩარჩო. მისი შესაძლებლობების საილუსტრაციოდ, პროექტში მოცემულია რამდენიმე მაგალითი, მათ შორის Java-ის მოდელის განხორციელება Handly-ში. (JDT-ში ჯავის მოდელის სრულ განხორციელებასთან შედარებით, ეს მოდელი განზრახ გარკვეულწილად გამარტივებულია მეტი სიცხადისთვის.)

როგორც ადრე აღვნიშნეთ, Handly-ის თავდაპირველი დიზაინისა და შემდგომი განვითარების დროს ძირითადი აქცენტი გაკეთდა და გრძელდება მასშტაბურობასა და მოქნილობაზე.

პრინციპში, სახელურზე დაფუძნებული მოდელები საკმაოდ კარგად ნაწილდება „დიზაინის მიხედვით“. მაგალითად, სახელური/სხეულის იდიომა საშუალებას გაძლევთ შეზღუდოთ მოდელის მიერ მოხმარებული მეხსიერების რაოდენობა. მაგრამ არის ნიუანსებიც. ამრიგად, Handly-ის მასშტაბურობის ტესტირებისას, გამოვლინდა პრობლემა შეტყობინებების მექანიზმის განხორციელებაში - როდესაც შეიცვალა ელემენტების დიდი რაოდენობა, დელტას მშენებლობას ძალიან დიდი დრო დასჭირდა. აღმოჩნდა, რომ იგივე პრობლემა იყო 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-ში, კონტაქტშია პროექტთან და უზრუნველყოფს სასიცოცხლო გამოხმაურებას „მესამე მხარის მიმღების“ სახელით. მან კი შეძლო გამოენახა თავისუფალი დრო პროექტის შემუშავებაში უშუალო მონაწილეობის მისაღებად, UI ფენის (~ 4000 სტრიქონი კოდის) დანერგვით Handly-ის ერთ-ერთი მაგალითისთვის, Java მოდელისთვის. უფრო დეტალური პირველადი ინფორმაცია ადაპტერების მიერ Handly-ის გამოყენების შესახებ შეგიძლიათ იხილოთ გვერდზე წარმატებები პროექტი.

ვიმედოვნებთ, რომ 1.0 ვერსიის გამოშვების შემდეგ, API სტაბილურობის გარანტიით და ინკუბაციური მდგომარეობიდან გასვლის შემდეგ, Handly-ს ეყოლება ახალი მიმღებები. იმავდროულად, პროექტი აგრძელებს API-ს ტესტირებას და შემდგომ გაუმჯობესებას, წელიწადში ორ "ძირითადი" გამოშვების გამოშვებას - ივნისში (იგივე თარიღი, როგორც Eclipse-ის ერთდროული გამოშვება) და დეკემბერში, რაც უზრუნველყოფს პროგნოზირებად განრიგს, რომელსაც მიმღებებს შეუძლიათ დაეყრდნონ. ჩვენ ასევე შეგვიძლია დავამატოთ, რომ პროექტის „შეცდომის მაჩვენებელი“ რჩება მუდმივად დაბალ დონეზე და Handly საიმედოდ მუშაობს ადრეული მიმღებების პროდუქტებზე პირველივე ვერსიებიდან. Eclipse Handly-ის შემდგომი შესასწავლად შეგიძლიათ გამოიყენოთ დაწყების გაკვეთილი и არქიტექტურული მიმოხილვა.

წყარო: www.habr.com