Фреймовая технология (программная инженерия)

Фреймовая технология (FT) — это языково-нейтральная (т. е. обрабатывающая разные языки) система, которая производит специальное программное обеспечение. ^[1] из многоразовых, адаптируемых к машинам строительных блоков, называемых фреймами . FT используется для сокращения времени, усилий и ошибок, связанных с проектированием, созданием и развитием больших и сложных программных систем. Фундаментальным для FT является его способность остановить распространение ^[2] похожих, но слегка различающихся компонентов, что является проблемой разработки программного обеспечения, для которой конструкции языка программирования (подпрограммы, классы или шаблоны/обобщенные элементы) или дополнительные методы, такие как макросы и генераторы, не могут обеспечить практическое масштабируемое решение.

Существует ряд реализаций FT. Netron Fusion специализируется на разработке программного обеспечения для бизнеса и является проприетарным. ART (технология адаптивного повторного использования) — это универсальная реализация FT с открытым исходным кодом. Пол Г. Бассетт изобрел первый FT, чтобы автоматизировать повторяющееся, подверженное ошибкам редактирование, связанное с адаптацией (сгенерированных и написанных от руки) программ к меняющимся требованиям и контекстам.

Сейчас существует обширная литература ^[3]^[4]^[5]^[6]^[7]^[8]^[9]^[10] это объясняет, как FT может облегчить большинство аспектов жизненного цикла программного обеспечения, включая моделирование предметной области, сбор требований, архитектуру и проектирование, создание, тестирование, документацию, тонкую настройку и эволюцию. Независимые сравнения ФТ с альтернативными подходами ^[11] подтвердить, что время и ресурсы, необходимые для создания и обслуживания сложных систем, могут быть существенно сокращены. Одна из причин: FT защищает программистов от присущей программному обеспечению избыточности: FT воспроизводит COTS объектные библиотеки из эквивалентных библиотек фреймов XVCL , которые на две трети меньше и проще; ^[2]^[6] Пользовательские бизнес-приложения обычно определяются и поддерживаются фреймами Netron Fusion SPC, размер которых составляет 5–15 % от размера собранных исходных файлов. ^[7]

Рамки

Ниже приведены два неофициальных описания, за которыми следуют более точное определение и объяснение.

Рамка — это адаптируемый компонент на автоматизированной линии сборки программного обеспечения. Представьте себе автомобильный завод, на котором вместо конкретных бамперов, крыльев и других деталей, соответствующих специфике каждой модели автомобиля, у нас есть только один типовой бампер, одно универсальное крыло и так далее. А теперь представьте, что эти общие детали можно клонировать и придать им форму, подходящую для каждой модели автомобиля по мере ее выпуска. Такая фантазия произвела бы революцию в производстве; и хотя это невозможно для физических частей, именно это фреймы делают для программного обеспечения (и информации в целом).
Фрейм — это рецепт «приготовления» текста (программы). В его инструкциях говорится, как смешать ингредиенты — фрагменты текста фрейма внутри себя — с ингредиентами из других фреймов. «Шеф-повар» — это процессор кадров, который выполняет инструкции, то есть команды кадра , которые при необходимости изменяют (добавляют, модифицируют, удаляют) ингредиенты в соответствии с основным рецептом.

Формально фрейм — это процедурный макрос, состоящий из фрейм-текста — нуля или более строк обычного (программного) текста и фреймовых команд (которые выполняются процессором фреймов FT при создании пользовательских программ). Каждый кадр является одновременно общим компонентом в иерархии вложенных подсборок и процедурой интеграции с его кадрами подсборки (рекурсивный процесс, который разрешает конфликты интеграции в пользу подсборок более высокого уровня). Выходные данные представляют собой специальные документы, обычно компилируемые исходные модули.

Основные команды

вызвать фрейм (вызов процедуры, который происходит во время построения при построении текста программы);
присвоить выражение (список) параметру кадра (присвоение переменной времени построения);
вставлять текст фрейма до, вместо или после блоков текста фрейма, помеченных выражениями параметров;
создать экземпляр параметра кадра (оценка выражения во время построения);
выбрать тексты фреймов для обработки (оператор случая во время построения);
перебирать текст фрейма, изменяя при этом определенные параметры фрейма (оператор while во время создания).

Процессор преобразует текст кадра, заменяя команды обычным текстом и выдавая обычный текст как есть. Примеры: он заменяет вызов результатом обработки вызванного кадра; он заменяет присваивание ничего не ; и экземпляр становится обычным текстом, полученным в результате оценки назначенного выражения параметра фрейма, которое может быть конкатенацией строк, арифметических выражений и вложенных параметров фрейма.

Отношения компонентов

Invoke устанавливает отношения компонентов между кадрами. Например, на рисунке 1: F — а компонент J, C — J. подкомпонент Конечно, многие компоненты могут вызывать один и тот же подкомпонент, как в I и J, вызывая F , каждый из которых создает свой текст. Общая структура компонентов образует общую полурешетку . ^[12] при этом каждый кадр является корнем узла сборки. Таким образом, C является отдельной сборкой; F и C являются компонентами подсборки F , а J , F и C являются компонентами J. подсборки ^[13]

Определение контекста

Определение контекста — это то, что отличает FT от других систем моделирования и построения: каждый кадр представляет собой контекст, в который он интегрирует свою сборку. Во вложенных узлах нижние уровни становятся все более контекстно-свободными, поскольку объединяют меньше информации. Конфликты интеграции разрешаются в пользу наиболее контекстно-зависимого фрейма для назначения или вставки параметра — он становится доступным только для чтения для всех остальных фреймов в подсборке этого фрейма. ^[14] На рисунке 1 кадры F и C будут конфликтовать, если они присвоят разные значения параметру p . Таким образом , F переопределяет C , то есть процессор кадров игнорирует и присвоение(я) C для использует значение для (я) F p в F и C. p Аналогично, J может переопределить как F , так и C и так далее.

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

Рамки и шаблоны спецификаций

Фрейм спецификации (SPC) — это самый верхний кадр всей сборки и, следовательно, наиболее контекстно-зависимый фрейм. Процессор начинает работу с SPC, такого как L или M на рисунке 1, чтобы создать полную программу или подсистему. Хотя в принципе SPC может настроить каждую деталь, на практике SPC представляет собой небольшую часть всей сборки, поскольку большинство исключений (и исключений из исключений и т. д.) уже обработаны различными кадрами подсборок.

Учитывая библиотеку фреймов, SPC логически влекут за собой программы, которые они создают; таким образом, SPC заменяют исходные файлы в качестве основных контрольных точек. Это обычная практика — использовать шаблоны для создания SPC, которые создают программы, а затем использовать SPC для управления этими программами и их развития в течение неопределенного времени. Такая практика значительно сокращает количество деталей, которые прикладные программисты должны знать и которыми должны управлять. Это также позволяет избежать избыточности, сложностей и ошибок, присущих копированию и редактированию исходных текстов вручную. Время отладки также сокращается, поскольку большинство компонентов используются повторно и, следовательно, проходят предварительное тестирование. Ошибки имеют тенденцию локализоваться в SPC, так как они наименее проверены.

Шаблон — это типичный SPC со встроенными комментариями, объясняющими , как его настроить. Обычно существует небольшое количество типов программ, причем каждый тип характеризуется шаблоном. Копируя и заполняя его, программисты преобразуют шаблон в SPC, не запоминая, какие кадры им нужны, взаимоотношения их компонентов или какие детали обычно необходимо настроить.

Предметно-ориентированные языки на основе фреймов

Предметно-ориентированный язык на основе FT (FT-DSL) — это предметно-ориентированный язык , семантика которого (выраженная в программном коде) встроена в фреймы . Типичный редактор FT-DSL преобразует выражения DSL в фрейм, который адаптирует семантику фрейма для выражения эквивалентов выражений DSL в программном коде. SPC, находящийся на вершине этого узла, может затем указать в программном коде любые настройки, невыразимые на языке предметной области. Таким образом, когда пользователи восстанавливают программный код из измененных выражений DSL, предыдущие настройки не теряются. ^[15]

Каркасная инженерия

Фреймовая инженерия применяет разработку программного обеспечения к среде каркасной технологии. Сюда входит анализ предметной области, проектирование, написание, тестирование и совместная разработка фреймов вместе с конструируемыми ими системами. ^[10] Кадрирование происходит как снизу вверх, так и сверху вниз. Снизу вверх инженеры фреймов обычно создают фреймы путем объединения и параметризации групп схожих программных элементов (любой степени детализации, от текстовых фрагментов до подсистем) в общие эквиваленты. Подход «сверху вниз» сочетает в себе экспертные знания предметной области с итеративным усовершенствованием прототипа, ограниченным требованиями приложений и архитектуры, корпоративными стандартами и желанием разработать набор повторно используемых активов, отдача от которых значительно превышает инвестиции. (Повторное использование измеряется путем деления общего размера библиотек фреймов на общий размер полученных конструкций и/или путем подсчета повторного использования отдельных фреймов.)

Развитая библиотека фреймов повышает экономическую эффективность, поскольку участники проекта программного обеспечения могут ограничить свое внимание новинками системы, принимая большую часть ее надежных компонентов и архитектуры как нечто само собой разумеющееся. Зрелая библиотека не статична. Разработчики фреймов могут, используя команду select, бесконечно развивать многоразовые фреймы, отвечая новым требованиям без необходимости модификации программ, созданных на основе предыдущих версий фреймов. ^[7]

Сноски

^ Здесь особое внимание уделяется программному обеспечению; но при наличии соответствующих фреймов FT может собирать любые документы: технические руководства и руководства для конечных пользователей, модели UML, тестовые примеры, юридические контракты, спецификации материалов и т. д.
^ Jump up to: ^а ^б С. Джарзабек и С. Ли, «Устранение избыточности с помощью метода метапрограммирования «композиция и адаптация», Proc. Европейское программное обеспечение, англ. Conf./ACM/SIGSOFT Symp. Основы программной инженерии (ESEC/FSE 03), ACM Press, 2003, стр. 237–246; получил награду ACM Distinguished Paper Award
^ PGBassett «Разработка программного обеспечения на основе фреймов», IEEE Software , июль 1987 г., стр. 9–16.
^ «К. Холмс и А. Эвенс, «Обзор рамной технологии». 28 ноября 2003 г.»; (PDF) . Архивировано из оригинала (PDF) 19 июля 2004 г. Проверено 10 октября 2008 г.
^ Ф.Зауэр, «Генерация многоартефактного кода на основе метаданных с использованием фрейм-ориентированного программирования», Семинар по генеративным методам в контексте архитектуры, управляемой моделями (Oopsla 02), 2002 [1]
^ Jump up to: ^а ^б Х. Басит, Д. К. Раджапаксе и С. Джарзабек, «За пределами шаблонов: исследование клонов в STL и некоторые общие последствия», Proc. Международная конференция. Программное обеспечение англ. (ICSE 05), ACM Press, 2005, стр. 451–459.
^ Jump up to: ^а ^б ^с П.Г. Бассетт, Повторное использование программного обеспечения: уроки реального мира , Prentice Hall, 1997.
^ С. Ярзабек, Эффективное обслуживание и эволюция программного обеспечения: подход, основанный на повторном использовании , Ауэрбах, 2007.
^ PGBassett, «Обоснование разработки программного обеспечения на основе фреймов», IEEE Software, июль 2007 г., стр. 90–99.
^ Jump up to: ^а ^б П.Г.Бассетт, «Адаптивные компоненты: туз в рукаве разработки программного обеспечения», Agile Project Management, Cutter Consortium, Vol.5 #5
^ И. Гроссман и М. Мах, «Независимое исследование повторного использования программного обеспечения», техн. отчет, QSM Associates, 1994 г.
^ Полурешетка является универсальной, поскольку ее узлы и структура графа могут различаться в зависимости от значений параметров.
^ Двусмысленность отражает ментальную привычку думать о сборочном узле как об одном компоненте.
^ Невложенным узлам конструкции можно переназначить один и тот же параметр.
^ Ручное редактирование одних и тех же настроек в восстановленный код снова и снова стимулировало изобретение FT.

[1] Здесь особое внимание уделяется программному обеспечению; но при наличии соответствующих фреймов FT может собирать любые документы: технические руководства и руководства для конечных пользователей, модели UML, тестовые примеры, юридические контракты, спецификации материалов и т. д.

[jar0-2] Jump up to: ^а ^б С. Джарзабек и С. Ли, «Устранение избыточности с помощью метода метапрограммирования «композиция и адаптация», Proc. Европейское программное обеспечение, англ. Conf./ACM/SIGSOFT Symp. Основы программной инженерии (ESEC/FSE 03), ACM Press, 2003, стр. 237–246; получил награду ACM Distinguished Paper Award

[3] PGBassett «Разработка программного обеспечения на основе фреймов», IEEE Software , июль 1987 г., стр. 9–16.

[4] «К. Холмс и А. Эвенс, «Обзор рамной технологии». 28 ноября 2003 г.»; (PDF) . Архивировано из оригинала (PDF) 19 июля 2004 г. Проверено 10 октября 2008 г.

[5] Ф.Зауэр, «Генерация многоартефактного кода на основе метаданных с использованием фрейм-ориентированного программирования», Семинар по генеративным методам в контексте архитектуры, управляемой моделями (Oopsla 02), 2002 [1]

[basit-6] Jump up to: ^а ^б Х. Басит, Д. К. Раджапаксе и С. Джарзабек, «За пределами шаблонов: исследование клонов в STL и некоторые общие последствия», Proc. Международная конференция. Программное обеспечение англ. (ICSE 05), ACM Press, 2005, стр. 451–459.

[bas-7] Jump up to: ^а ^б ^с П.Г. Бассетт, Повторное использование программного обеспечения: уроки реального мира , Prentice Hall, 1997.

[jar-8] С. Ярзабек, Эффективное обслуживание и эволюция программного обеспечения: подход, основанный на повторном использовании , Ауэрбах, 2007.

[9] PGBassett, «Обоснование разработки программного обеспечения на основе фреймов», IEEE Software, июль 2007 г., стр. 90–99.

[bas1-10] Jump up to: ^а ^б П.Г.Бассетт, «Адаптивные компоненты: туз в рукаве разработки программного обеспечения», Agile Project Management, Cutter Consortium, Vol.5 #5

[11] И. Гроссман и М. Мах, «Независимое исследование повторного использования программного обеспечения», техн. отчет, QSM Associates, 1994 г.

[12] Полурешетка является универсальной, поскольку ее узлы и структура графа могут различаться в зависимости от значений параметров.

[13] Двусмысленность отражает ментальную привычку думать о сборочном узле как об одном компоненте.

[14] Невложенным узлам конструкции можно переназначить один и тот же параметр.

[15] Ручное редактирование одних и тех же настроек в восстановленный код снова и снова стимулировало изобретение FT.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]