Наша праца над пошукавым кодам створана, каб дазволіць праграмістам скарыстацца перавагай вялікіх сховішчаў даступнага і адкрытага пошукавага кода. Традыцыйныя механізмы пошукавага кода, такія як пошукавы код Гугл, Кодэрс або Кругл прадастаўляюць доступ да такіх сховішчаў, але не зусім спрашчаюць працу праграмістаў у выкарыстанні кода. Яны бяруць ключавыя словы і вяртаюць патэнцыйна сотні падыходных частак кода. Затым праграміст павінен праглядзець кожны з гэтых вернутых файлаў. Затым ім неабходна паглядзець, ці адпавядае код. Калі так, ім неабходна прачытаць яго ў дэталях, каб вызначыць, ці з’яўляецца ён тым, што яны хочуць ці, па меншай меры, набліжаны да гэтага. І, у рэшце рэшт, ім варта прыстасаваць код, каб адпавядаць сваім канкрэтным патрабаванням адносна назвы, фармату, постапрацоўку і т. д.
Мы адчуваем, што лепшы падыход будзе заключацца ў тым, каб праграмісты падалі больш дакладную інфармацыю, як, напрыклад, тое, што яны хочуць, а затым даць сістэме зрабіць цяжкую працу праверкі вернутых кодавых фрагментаў, мадыфікуючы код рабіць тое, што хоча праграміст, або трансфармуючы код, каб той падыходзіў да мэтавых стандартаў. Наш пошукавы камунікацыйны працэсар дае праграмісту вызначыць семантыку таго, што хочуць. Гэта ўключае ў сябе ключавыя словы, як нефармальныя апісанні, подпіс, справа-прэцэдэнт і кантракты (праз JML) для функцыянальнай канкрэтыкі, бяспечную прывязку дадзеных (выкарыстоўваючы мадэль бяспекі Java), звязваючы прывязку дадзеных (цалкам не выкананую). У дадатак, карыстальнік можа даць кантэкст, да якога будзе падыходзіць код. Камунікацыйны працэсар робіць гэтыя ўдакладненні даступнымі.
Сістэма працуе, выкарыстоўваючы ключавыя словы, каб атрымаць доступ да аднаго з даступных механізмаў пошукавага кода (або лакальнага механізму пошукавага кода ў Brown), каб атрымаць прыдатныя файлы. Кожны клас або метад у гэтых файлах (у залежнасці ад таго, што карыстальнік шукае) лічыцца патэнцыйным рашэннем. Гэтыя рашэнні затым трансфармуюцца, выкарыстоўваючы набор каля 30 трансфармацый у спробе адзначыць код канкрэтна ў тое, што ўдакладніў праграміст. Трансфармацыі вар’іруюцца ад простых (напр., змена назвы метаду, каб адпавядаць подпісу) да складаных (напр., знайсці радок у метадзе, які вылічае характарыстыку вернутых тыпаў, а затым зрабіць зваротны ход да таго часу, пакуль адзіныя свабодныя зменныя не стануць характарыстыкамі пастаянных тыпаў). Усе рашэнні, якія можна трансфармаваць, каб тыя адпавядалі подпісам, затым правяраюцца, выкарыстоўваючы дадзеныя справы-прэцэдэнты, бяспечныя прывязкі дадзеных і правілы JML. Дадатковыя трансфармацыі можна ўжыць, грунтуючыся на выніках спраў-прэцэдэнтаў. Рашэнні, якія прайшлі справы-прэцэдэнты, затым фарматуюцца ў адпаведнасці з канкрэтным стылем карыстальнікаў, пасартаваны па памеры, складанасці або прадукцыйнасці ў справе-прэцэдэнце, і назад прадстаўлены карыстальніку.
Сістэму можна выпрабаваць (у большасці часу сервер не працуе) на http://conifer.cs.brown.edu/s6.
У наступнай працы з арыгінальным S6, мы пашырылі сістэму, каб знайсці інтэрфейсы карыстальнікаў, дадзеныя накіды інтэрфейсу карыстальніка і знайсці справы-прэцэдэнты, якім дадзены код, які неабходна выпрабаваць.
Работы
Пошукавы код, заснаваны на семантыцы, ICSE 2009, Май 2009.
Удакладняючы, што шукаць, SUITE 2009, Май 2009.
У пошуках інтэрфейсу карыстальніка, ASE 2014.
Стварэнне спраў-прэцэдэнтаў, выкарыстоўваючы пошукавай код не апублікаваны.
Паляўнічы: наступнае пакаленне паўторнага выкарыстання кода для Java — Yuepeng Want, Yu Feng, Ruben Martins, Arati Kaushik, Isil DIllig and Steven Reiss, FSE 2016.
У пошуках інтэрфейсу карыстальніка — Steven Reiss, Yun Miao and Qi Xin, Automated Software Engineering Journal, 2017.
Малюнкі
Камунікацыйны працэсар:
Камунікацыйны працэсар паказвае вынікі:
Дыяграма ўнутраных элементаў:
Праграмнае забеспячэнне
Праграмнае забеспячэнне даступна тут ftp://ftp.cs.brown.edu/u/spr/s6.tar.gz.
Добавить комментарий