პროგრამირების გარემოს კვლევა

Original web-page: http://cs.brown.edu/~spr/research/env.html

ისტორია

პროგრამირება რთული ამოცანაა. პროგრამირების გარემოს მიზანია უზრუნველყოს ინსტრუმენტები, რომლებიც დაეხმარება პროგრამისტს და გაამარტივებს ამოცანას. ჩვენ ვართ პროგრამირების ინსტრუმენტების ძლიერი მომხრე და დიდი ხანია ვავითარებთ ასეთ ინსტრუმენტებს. ბაკალავრიატის დროს ვმუშაობდი Dartmouth Basic Runtime სისტემაზე. აქ ერთ-ერთი მთავარი ინოვაცია იყო წყაროს ენის გამართვის გარემოში დამატება.

ჩვენი რეალური კვლევა პროგრამირების გარემოში დაიწყო სამუშაო სადგურების გამოჩენით (Apollos, Suns, Percs,…). ჩვენ (სხვა რამდენიმე ჯგუფთან ერთად) ვიგრძენით, რომ უნდა შეგვეძლოს დამატებითი გამოთვლითი სიმძლავრის და გრაფიკული დისპლეის გამოყენება პროგრამირების გამოცდილების გასამარტივებლად და გასაუმჯობესებლად. ჩვენი საწყისი მცდელობა აქ აისახება PECAN-ში სისტემა. PECAN-მა გამოიყენა შემდგენელი ტექნოლოგია ენისთვის ხელსაწყოების კომპლექტის შესაქმნელად. ხელსაწყოების კომპლექტი მოიცავდა ტექსტურ (ნაწილობრივ სინტაქსზე მართულ) და გრაფიკულ (ნასი-შნეიდერმანის დიაგრამები, როტონის დიაგრამები) რედაქტორებს, სიმბოლოების ცხრილის სემანტიკის ხედებს, საკონტროლო ნაკადს და გამონათქვამებს, და სტეკის და კოდის შესრულების ხედებს. მას ასევე ასახავდა დამატებითი კომპილაცია მომხმარებლის აკრეფისას. ეს იყო სახალისო სისტემა და ბევრი რამ გვასწავლა, მაგრამ ნამდვილად არ იყო პრაქტიკული (მას ამოიწურა მეხსიერება დაახლოებით 1000 სტრიქონში კოდით) და არ ისარგებლა სამუშაო სადგურების გრაფიკული შესაძლებლობებით.

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

GARDEN-ის შემუშავებისას, რამდენიმე ადამიანმა დაუპირისპირდა პროგრამირების გარემოში საერთო კვლევას, აცხადებდა, რომ მიუხედავად იმისა, რომ ინსტრუმენტები, რომლებსაც ჩვენ და სხვები ვავითარებდით, კარგი იყო და შესაძლოა სასარგებლო ყოფილიყო, არაფერი იყო რეალურად პრაქტიკული და არცერთ პროექტს არ შეეძლო რეალურად გამოიყენოს საკუთარი თავი განვითარებისთვის; UNIX-ზე (ან იმდროინდელ ნებისმიერ სხვა ოპერაციულ სისტემაზე) პროგრამების ყოველდღიური შემუშავება ხდებოდა ცალკეული და ტექსტური რედაქტორების, დებაგერების და ა.შ. გამოყენებით, რომლებიც მნიშვნელოვნად არ შეცვლილა ათი წლის განმავლობაში. ამრიგად, ჩვენ დავიწყეთ რეალური პროგრამირების პრაქტიკული გარემოს შემუშავება. ჩვენ მივხვდით, რომ თქვენ არ გჭირდებათ საერთო მაღაზია ან ცენტრალური წარმომადგენლობა, რომ გქონდეთ ინტეგრირებული გარემო და არც ახალი ინსტრუმენტების შემუშავება გჭირდებათ გრაფიკული წინა ნაწილებისთვის. ამის ნაცვლად, ჩვენ შევიმუშავეთ მარტივი შეტყობინებებზე დაფუძნებული ინტეგრაციის მექანიზმი, რომელიც საშუალებას აძლევს ინსტრუმენტებს ისაუბრონ ერთმანეთთან, და შეფუთვების სერია, რომლებიც უზრუნველყოფდნენ გრაფიკულ ინტერფეისებს არსებულ ინსტრუმენტებს (dbx, gdb, make, rcs,…). შედეგი იყო FIELD გარემო. როგორც ის შეიქმნა, ჩვენ გავაფართოვეთ გარემო სხვადასხვა გრაფიკული ხედებით, მათ შორის სტრუქტურული ხედებით (ნაკადის სქემა, კლასის იერარქია) და დინამიური ხედები (მონაცემთა სტრუქტურის ჩვენება, გროვის ვიზუალიზაცია, შეყვანა/გამომავალი ვიზუალიზაცია). FIELD საკმაოდ წარმატებული იყო. ჩვენ ვიყენებდით მას რამდენიმე წლის განმავლობაში ჩვენს შესავალ პროგრამირების კურსებში, მისი კომერციალიზაცია მოხდა DEC-ის მიერ (როგორც FUSE) და კოპირებულია HP (Softbench), Sun (Tooltalk), SGI და სხვები.

ჩვენი შემდეგი გარემო, უდაბნო, სცადა FIELD გაფართოება რამდენიმე გზით. პირველ რიგში, მას სურდა პროგრამისტს მიეწოდებინა კოდის მაღალი ხარისხის ჩვენება. ეს გაკეთდა Adobe Framemaker-ის, როგორც პროგრამის რედაქტორის გაფართოებით. გაფართოებაში წარმოდგენილი იყო ბეკერ-მარკუსი სტილის კოდის ფორმატირება, რომელიც შესრულდა მომხმარებლის აკრეფისას, რომელიც მოიცავდა სიმბოლოების სემანტიკურ ძიებას მთელ სისტემაში (და არა მხოლოდ მიმდინარე ფაილში). მეორეც, გვინდოდა პროგრამისტს საშუალება ენახათ სისტემა სხვადასხვა გზით, რათა შეეძლოს კონკრეტული ცვლილების ან ფუნქციის შესაბამისი კოდის იზოლირება. ეს გაკეთდა პროგრამის ფრაგმენტებად დაყოფით და რედაქტორის მიერ იმ ვირტუალურ ფაილებზე მუშაობით, რომლებიც შედგებოდა სხვადასხვა ფრაგმენტებისგან, რომლებიც შეგროვდა რეალური წყარო ფაილებიდან. პროგრამისტს შეეძლო ფრაგმენტების ნაკრების მითითება შესაბამისი მოთხოვნების გამოყენებით. ფრაგმენტები კონფიგურაციის მენეჯმენტის ქვეშ იყო და ვირტუალურ ფაილებში განხორციელებული ცვლილებები ინტეგრირებული იყო ორიგინალურ წყაროს ფაილებში ვირტუალური ფაილების შენახვისას. და ბოლოს, ჩვენ გვინდოდა მოგვეწოდებინა კოდისა და შესრულების უფრო მაღალი ხარისხის ვიზუალიზაცია და ამით შეგვემუშავებინა 3D ვიზუალიზაციის სისტემა, რომელიც ინტეგრირებული იყო გარემოში.

ჩვენი ბოლოდროინდელი ძალისხმევა კონცენტრირებულია ევოლუციისა და პროგრამული უზრუნველყოფის თანმიმდევრულობის მხარდაჭერაზე, ვიდრე პროგრამირების ყოვლისმომცველი გარემოს უზრუნველყოფის მცდელობაზე. ეს პაკეტი, CLIME, ვარაუდობს, რომ არსებობს ინსტრუმენტები ყველა სხვადასხვა არტეფაქტის შესაქმნელად და შესანარჩუნებლად, რომლებიც თან ახლავს პროგრამულ სისტემას: სპეციფიკაციები, დიზაინი, წყარო, ტესტის შემთხვევები, დოკუმენტაცია და ა.შ. თითოეული ამ არტეფაქტის სემანტიკა შემდეგ განისაზღვრება მეტაშეზღუდვების სიმრავლის მიხედვით. სხვა არტეფაქტებთან მიმართებაში. დიზაინი განიხილება, როგორც წყაროს შეზღუდვა (და პირიქით), ისე, რომ UML დიაგრამაში კლასს უნდა ჰქონდეს შესაბამისი კლასი წყაროში; ენის გამოყენების წესები ზღუდავს წყაროს ფორმას; დოკუმენტაცია უნდა შეესაბამებოდეს კოდს; სატესტო შემთხვევები უნდა მოიცავდეს კოდს და განმეორდეს კოდის ცვლილებისას. ეს ყველაფერი ეტაპობრივად შემოწმდება, რადგან გამოყენება ასწორებს არტეფაქტებს და ნებისმიერი შეუსაბამობა ნაჩვენებია გრაფიკული ინტერფეისის გამოყენებით.

მიუხედავად იმისა, რომ CLIME კონცენტრირებულია წყაროს სტატიკურ სტრუქტურაზე და სხვადასხვა პროგრამულ არტეფაქტებზე, ჩვენ მივხვდით, რომ ზოგიერთი სპეციფიკაცია და დიზაინის არტეფაქტები დაკავშირებულია აპლიკაციის ქცევასთან და არა თავად კოდთან. ამის დასაკმაყოფილებლად, ჩვენ  ვამუშავებთ CHET, ინსტრუმენტს კლასისა და ბიბლიოთეკის სპეციფიკაციების შესამოწმებლად რეალურ პროგრამულ სისტემებში. CHET-ს შეუძლია მიიღოს ინფორმაცია გაფართოებული ავტომატის საფუძველზე მოვლენებზე (რომელიც შეიძლება იყოს მიღებული UML ურთიერთქმედების დიაგრამებიდან, კლასის კონტრაქტებიდან და ა.შ.), იპოვნოს სპეციფიკაციის ყველა მაგალითი დიდ სისტემაში და შემდეგ შეამოწმოს თითოეული ინსტანცია.

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