Вы когда -нибудь видели ваш код как город?

Таблица ссылок

Аннотация и I. Введение

II Подход

А. Архитектурный дизайн

B. Доказательство реализации концепции

Iii. Представленные сценарии использования

IV Дизайн эксперимента и демография

А. Участники

B. Целевая система и задача

C. Процедура

V. Результаты и обсуждение

VI Связанная работа

VII. Выводы и будущая работа, признание и ссылки

Абстрактный- Визуализации сборов обычно реализуются как автономные и изолированные инструменты, которые используют встроенные зрители кода в рамках визуализации. В контексте понимания программы лишь немногие подходы интегрируют визуализации в редакторы кодов, такие как интегрированные среды разработки. Это удивительно, поскольку профессиональные разработчики рассматривают возможность чтения исходного кода как одного из наиболее важных способов понимания программного обеспечения, поэтому тратят много времени с редакторами кода.

В этой статье мы представляем реализацию проектирования и проверки концепции для подхода к визуализации программного обеспечения, который может быть включен в редакторы кода. Наш вклад отличается от связанной работы в том, что мы используем динамический анализ поведения времени выполнения программной системы. Кроме того, мы включаем распределенную трассировку. Это позволяет разработчикам понять, как, например, в настоящее время обработанного исходного кода ведет себя как полностью развернутая, распределенная программная система. Наш подход визуализации улучшает общие инструменты программирования удаленных пар и можно совместно использоваться, используя города общих кодов. В результате взаимодействие пользователей синхронизируется между редактором кода и визуализацией, а также транслируется для сотрудников.

Насколько нам известно, это первый подход, который объединяет редакторы кодов с совместно полезными городами кода. Поэтому мы провели исследование пользователя для сбора первых отзывов о воспринимаемой полезности и воспринимаемой удобстве использования нашего подхода. Мы дополнительно собрали информацию о ведении журнала, чтобы предоставить больше данных о времени, проведенных в городах, встроенных в редакторы кода. Семь команд с двумя студентами участвовали в этом исследовании. Результаты показывают, что большинство участников считают наш подход полезным и будет использовать его для собственного использования. Мы предоставляем видеозаписи каждого участника, необработанные результаты и все шаги, чтобы воспроизвести наш эксперимент как дополнительный пакет. Кроме того, живая демонстрация нашего инструмента доступна в Интернете.1 Мы приглашаем других исследователей расширить наше программное обеспечение OpenSource.2 Видео URL: https://youtu.be/3qzvsehneug

Индексные термины–Software Визуализация, динамический анализ, понимание программы, парное программирование, интегрированная среда разработки

I. Введение

Понимание исходного кода по -прежнему является основным методом, чтобы понять поведение программной системы [1]. Это не неожиданно, потому что разработчики обучены распознавать повторяющиеся закономерности и полученное поведение в исходном коде. Они даже могут провести большую часть своего времени разработки в интегрированных средах развития (IDE) [2]. Тем не менее, навигация в IDES приводит к избыточному, но неизбежным накладным расходам [3], а с точки зрения разработчиков визуализации программного обеспечения (SV) обеспокоены переключателем контекста, вызванным автономными инструментами SV [4]. В результате близость кода является необходимым свойством для SV [5], [6], чтобы добиться успеха в своей предполагаемой области, то есть в разработке профессионального программного обеспечения. Близость кода означает способность инструмента визуализации обеспечивать легкий и быстрый доступ к исходному, базовому исходному коду [7]. В этом контексте в прошлом были показаны подходы к исследованиям, которые внедряют SV в редакторы кода и IDE (оба отныне в качестве редактора кода), чтобы связать исходный код с его визуализацией [8] - [11].

В этой статье мы представляем наш совместно полезный подход SV, который можно встроить в редакторы кода. По сравнению с соответствующими подходами мы используем динамический анализ в качестве источника для рендеринга трехмерных городов кода [12], [13]. SV связан непосредственно с исходным кодом, который находится в разработке в редакторе кода и наоборот. Поэтому мы напрямую связываем поведение времени выполнения с соответствующими элементами программы, например, методами Java. Пользовательские взаимодействия синхронизируются между редактором кода и визуализацией, а также транслируются сотрудникам. В качестве доказательства концепции мы реализовали расширение Visual Studio Code3 (VS Code), которое осознает наш дизайн. Мы провели первое исследование пользователя, чтобы собрать обратную связь, касающуюся воспринимаемой полезности и воспринимаемого удобства использования нашего подхода. Кроме того, мы собрали информацию о ведении журнала, чтобы предоставить больше данных, касающихся статистики использования SV, которые включены в редакторы кода. В этом исследовании семь команд с двумя студентами в каждом совместно использовали наш подход в сценарии, связанном с адаптацией. В целом, результаты показывают высоко оцененную полезность.

Остальная часть этой статьи структурирована следующим образом. В разделе II представлен архитектурный обзор и доказательство реализации концепции для нашего подхода. Мы продолжаем

Представляя предполагаемые сценарии использования для нашего подхода в разделе III. После этого раздел IV объясняет нашу экспериментальную настройку. Раздел V представляет и обсуждает результаты нашего исследования. Затем раздел VI вводит соответствующую работу. Наконец, мы завершаем эту статью и представляем будущую работу в разделе VII.

II ПОДХОД

В этом разделе мы представляем архитектурный дизайн и доказательство реализации концепции для этой исследовательской работы. Для этого мы опираемся на наш ранее опубликованный подход под названием «Визуализация программного обеспечения» в качестве услуги (SVAAS), то есть предоставление услуги по пониманию программы для совместной программы с использованием SV. Из -за пространственных ограничений мы передаем читателей [14] для описания основных понятий нашего подхода.

А. Архитектурный дизайн

На рисунке 1 показан (упрощенный обзор) архитектурного дизайна нашего подхода. Он независим от технологий, за исключением SV-компонента на основе браузера. Как показано, он разделен на четыре этапа (голубые области). На рисунке 1-A и на рисунке 1-B изображены этапы мониторинга и анализа, соответственно. Это основа нашей концепции SVAAS. Например, конвейер анализа может быть горизонтально масштабирован для обработки различной нагрузки одновременных пользователей, поэтому положительно влияет на эффективность общего инструмента [15]. Хотя получение данных, анализ и облачные технологии являются важными аспектами нашей концепции, подробное объяснение выходит за рамки данной статьи. Поэтому мы передаем читателей [14] для получения подробной информации и сосредоточены на оставшихся двух этапах.

WebServer (рисунок 1-C) обслуживает статические файлы, которые включают веб-SV, то есть CSS, JavaScript и HTML. Кроме того, он выступает в качестве обратного прокси для клиентов для подключения к бэкэнд -сервисам, например, для получения данных для визуализации. У пользователей теперь есть два параметра, чтобы связать SV со своим редактором кода:

• Для первого варианта они могут использовать автономный SV, который работает внутри их веб-браузера, и подключается к расширению в своем редакторе кода (рис. 1-D). Последний действует как шлюз между редактором кода и SV. Это похоже на «классический» подход для зрителей кода, встроенных в SVS, и относится ко многим другим работам (см. Раздел VI). Взаимодействия, которые должны быть связаны между редактором кода и SV, например, «Откройте файл класса в редакторе кода при нажатию на связанный объект визуализации», синхронизируются службой редактора кода (рисунок 1-E).

• Для второго варианта пользователи могут установить расширение в своем редакторе кода, который уже включает в себя Frontend (Рисунок 1-F). В этом случае нам не нужна внешняя служба для синхронизации событий взаимодействия, но используем встроенный механизм связи между редактором кода и его расширением. Поэтому мы уменьшаем переключение контекста, которое происходит при переключении от SV на редактор кода и наоборот [4]. Еще одним преимуществом второго варианта является то, что он также может быть установлен в облачных редакторах кода, которые работают в браузерах. Это может быть полезным в некоторых вариантах использования, например, в соответствии с новыми разработчиками, как показано в разделе III.

Независимо от выбранной опции, пользователи могут совместно использовать SV. Чтобы достичь этого, служба совместной работы (рис. 1-G) транслирует события, например, «пользователь x открыл пакет Y», для всех клиентов того же сеанса, за исключением того, что вызвало событие [16]. Затем клиенты применяют полученные события к своему SV, поэтому синхронизируют их государства.

B. Доказательство реализации концепции

Мы прототипировали наш подход в нашем SV Tool Explorviz.4. Развитие нашего инструмента началось в 2012 году [17] и было сосредоточено на нескольких аспектах в течение времени, таких как проблемы развития [18], [19] и расширенная реальность [16], [20]. Совсем недавно мы используем Explorviz для исследования совместной визуализации программного обеспечения в контексте понимания программы [16], [21]. Explorviz в настоящее время использует динамический анализ в качестве источника для визуализации. Наш изображенный SV настроен для визуализации агрегированного поведения времени выполнения десяти секунд [14].

На рисунке 2 показан скриншот нашей реализации прототипа. Мы разработали расширение кода VS, которое осознает ранее упомянутый дизайн. Его можно использовать в качестве шлюза, чтобы связать внешний SV с редактором кода или вместо этого предоставить встроенный SV. Из -за пространственных ограничений мы сосредоточены на последнем и передаем читателей на наше дополнительное видео. Расширение использует HTML Iframe для встроенного веб-фронта, поэтому SV, в коде VS (см. Рисунок 1-F на предыдущей странице). Встроенный SV может быть включен или выключен через кнопку логотипа Explorviz (Рисунок 2-A). Он автоматически помещается в новую группу редакторов рядом с исходным кодом (рисунок 2-b). Пользователи могут выбрать одну из своих (в настоящее время или ранее) проанализированных программных систем (как показано в дополнительном видео) и открыть связанный SV. Последнее предоставляется в виде трехмерных городов кода с использованием Three.js5 для рендеринга (рис. 2-C). Встроенный фронт использует передачу кроссоригина на основе объекта окна JavaScript для взаимодействия с VS-кодом. Следовательно, нам не нужна внешняя служба, которая синхронизирует события взаимодействия, как это происходит при использовании внешнего фронта или, как показано в связанных работах (см. Раздел VI). Каждую десятую секунду фронтэнд запускает обновление SV. Для этого он получает последние данные времени выполнения для выбранной системы программного обеспечения из конвейера анализа и обновляет визуализацию, если это необходимо. Кроме того, Frondend отправляет новые данные в код VS, который затем выделяет классы и методы Java, которые использовались в агрегированном поведении времени выполнения. Это показано значками желоба и кодовыми линзами на рисунке 2-D. Пользователи могут щелкнуть на кодовую линзу, чтобы сосредоточить связанную сущность в SV, например, многоэтажное здание, визуализируя класс Java. Наоборот, нажатие, например, в строке связи, приведет к открытию файла и сосредоточено на связанном методе в коде VS. С точки зрения совместной работы, пользователи могут присоединиться или провести совместную сеанс из встроенного фронта и использовать совместные функции SV, например, пингирование или общие всплывающие окна (рисунок 2-E), чтобы взаимодействовать друг с другом (пожалуйста, см. [16] для получения более подробной информации). Кроме того, совместная сессия также позволяет программировать удаленную пар. Для кода VS в целом разработчики могут, например, использовать расширение Microsoft Liveshare для кода VS. LiveShare имеет отличные функции и удобство использования, но использует серверы Microsoft, которые могут быть недоступны в будущем или не могут быть использованы из -за проблем соблюдения. Ради воспроизводимости нашей оценки, мы поэтому решили не использовать доступный продукт, такой как Liveshare Microsoft, но разработали собственное решение (для исследования пользователя). Это можно увидеть на рисунке 2- F, где изображен выбор живого текста другого пользователя (как желтый фон владельца). Эти события выбора текста синхронизируются путем реализации службы редактора внешнего кода (рисунок 1-E) с использованием веб-питания для почти в реальном времени.