Technologia ramowa (inżynieria oprogramowania)

Technologia ramek (FT) to neutralny językowo (tj. przetwarzający różne języki) system, który tworzy niestandardowe oprogramowanie z bloków konstrukcyjnych wielokrotnego użytku, które można dostosowywać maszynowo, zwanych ramkami . FT służy do zmniejszenia czasu, wysiłku i błędów związanych z projektowaniem, budową i rozwojem dużych, złożonych systemów oprogramowania. Podstawą FT jest zdolność do powstrzymania rozprzestrzeniania się podobnych, ale subtelnie różnych komponentów, problemu nękającego inżynierię oprogramowania, dla którego konstrukcje języka programowania (podprogramy, klasy lub szablony/rodzaje) lub techniki dodatków, takie jak makra i generatory, zawiodły zapewnić praktyczne, skalowalne rozwiązanie.

Istnieje wiele implementacji FT. Netron Fusion specjalizuje się w tworzeniu oprogramowania biznesowego i jest własnością firmy. ART (Adaptive Reuse Technology) [2] to uniwersalna implementacja FT o otwartym kodzie źródłowym. Paul G. Bassett wynalazł pierwszy FT w celu zautomatyzowania powtarzalnej, podatnej na błędy edycji związanej z dostosowywaniem (generowanych i pisanych odręcznie) programów do zmieniających się wymagań i kontekstów.

Obecnie istnieje obszerna literatura, która wyjaśnia, w jaki sposób FT może ułatwić większość aspektów cyklu życia oprogramowania, w tym modelowanie domeny, zbieranie wymagań, architekturę i projektowanie, konstrukcję, testowanie, dokumentację, dostrajanie i ewolucję. Niezależne porównania FT z alternatywnymi podejściami potwierdzają, że czas i zasoby potrzebne do zbudowania i utrzymania złożonych systemów można znacznie skrócić. Jeden powód: FT chroni programistów przed nieodłączną redundancją oprogramowania: FT odtworzył biblioteki obiektów COTS z równoważnych bibliotek ramek XVCL , które są o dwie trzecie mniejsze i prostsze; niestandardowe aplikacje biznesowe są rutynowo określane i utrzymywane przez ramki Netron Fusion SPC , które mają od 5% do 15% rozmiaru ich złożonych plików źródłowych.

Ramki

Poniżej znajdują się dwa nieformalne opisy, po których następuje bardziej precyzyjna definicja i wyjaśnienie.

1. Rama to elastyczny element na zautomatyzowanej linii montażowej oprogramowania. Wyobraź sobie fabrykę samochodów, w której zamiast specyficznych zderzaków, błotników i innych części pasujących do specyfiki każdego modelu samochodu, mamy tylko jeden ogólny zderzak, jeden ogólny błotnik i tak dalej. Teraz wyobraź sobie, że te ogólne części można sklonować i ukształtować tak, aby pasowały do ​​każdego modelu samochodu, który pojawił się na linii. Taka fantazja zrewolucjonizowałaby produkcję; i chociaż jest to niemożliwe w przypadku części fizycznych, to właśnie robią ramki dla oprogramowania (i ogólnie informacji).
2. Ramka jest receptą na „ugotowanie” tekstu (programu). Jego instrukcje mówią, jak łączyć jego składniki – fragmenty tekstu ramki w sobie – ze składnikami z innych ramek. „Szef kuchni” to procesor ramek, który wykonuje instrukcje, tj. polecenia ramek , które w razie potrzeby zmieniają (dodają, modyfikują, usuwają) składniki, aby pasowały do ​​głównego przepisu.

Formalnie ramka jest makrem proceduralnym składającym się z tekstu ramki – zero lub więcej wierszy zwykłego (programowego) tekstu i poleceń ramki (które są wykonywane przez procesor ramek FT podczas tworzenia własnych programów). Każda ramka jest zarówno ogólnym komponentem w hierarchii zagnieżdżonych podzespołów, jak i procedurą integrowania się z ramkami podzespołów (proces rekurencyjny, który rozwiązuje konflikty integracji na rzecz podzespołów wyższego poziomu). Dane wyjściowe to niestandardowe dokumenty, zazwyczaj kompilowalne moduły źródłowe.

Główne polecenia

• wywołać ramkę (wywołanie procedury występujące w czasie konstruowania tekstu programu);
• przypisać (listę) wyrażeń do parametru ramki (przypisanie zmiennej czasu konstrukcji);
• wstawić tekst ramki przed, zamiast lub po blokach tekstu ramki, oznaczonych wyrażeniami parametrycznymi;
• utwórz instancję parametru ramki (ocena wyrażenia w czasie konstrukcji);
• wybierz teksty ramek do przetworzenia (instrukcja przypadku w czasie budowy);
• iteruj tekst ramki, zmieniając niektóre parametry ramki (instrukcja while w czasie konstruowania).

Procesor przekształca tekst w ramce, zastępując polecenia zwykłym tekstem i emitując zwykły tekst w takiej postaci, w jakiej jest. Przykłady: Zastępuje wywołanie wynikiem przetworzenia wywołanej ramki; zastępuje cesjonariusza niczym ; a instancja staje się zwykłym tekstem wynikającym z oceny wyrażenia przypisanego do parametru ramki, które może być konkatenacją ciągów znaków, wyrażeń arytmetycznych i zagnieżdżonych parametrów ramki.

Relacje składowe

Invoke ustawia relacje komponentów między ramkami. Na przykład na rysunku 1: F to składowa J , a C to składowa podrzędna J. Oczywiście wiele komponentów może odwoływać się do tego samego podkomponentu, jak w I i J wywołujących F , z których każdy konstruuje inny tekst. Ogólna struktura komponentu tworzy rodzajową półsiatkę , w której każda rama jest podstawą podzespołu. Zatem C jest swoim własnym podzespołem; F i C są komponentami podzespołu F , a J , F i C są komponentami podzespołu J.

Zakres kontekstu

Określanie zakresu kontekstu jest tym, co odróżnia FT od innych systemów modelowania i konstrukcji: Każda rama stanowi kontekst, w który integruje swój podzespół. W zagnieżdżonych podzespołach niższe poziomy są coraz bardziej pozbawione kontekstu, ponieważ integrują mniej informacji. Konflikty integracji są rozwiązywane na korzyść najbardziej kontekstowej ramki do przypisania lub wstawienia parametru — staje się ona tylko do odczytu dla wszystkich innych ramek w podzespole tej ramy. Na rysunku 1 ramki F i C powodowałyby konflikt, gdyby przypisywały różne wartości parametrowi p . Tak więc F zastępuje C – tj. procesor ramek ignoruje przypisania C do p i używa wartości F dla p w F i C . Podobnie J może zastąpić zarówno F , jak i C i tak dalej.

Określanie zakresu kontekstu ma znaczenie, ponieważ wszystkie dostosowania potrzebne do dopasowania dowolnej liczby (pod)komponentów do danego kontekstu są jawne i lokalne dla tego kontekstu. Bez uwzględnienia kontekstu takie dostosowania są w większości niejawne, rozproszone i ukryte w wariantach komponentów. Takie warianty nie tylko mnożą się, powodując niepotrzebną redundancję i złożoność, ale także ewolucja systemu jest niepotrzebnie trudna i podatna na błędy.

Ramki specyfikacji i szablony

Ramka specyfikacji (SPC) to najwyższa ramka całego zespołu, a więc najbardziej kontekstowa ramka. Procesor zaczyna od SPC, takiego jak L lub M na rysunku 1, w celu wytworzenia kompletnego programu lub podsystemu. Chociaż w zasadzie SPC może dostosować każdy szczegół, w praktyce SPC stanowi niewielką część całego zespołu, ponieważ większość wyjątków (i wyjątków od wyjątków itp.) została już obsłużona przez różne ramy podzespołów.

Biorąc pod uwagę bibliotekę ramek, SPC logicznie pociągają za sobą programy, które konstruują; w ten sposób SPC zastępują pliki źródłowe jako podstawowe punkty kontrolne. Rutynową praktyką jest używanie szablonów do tworzenia SPC, które tworzą programy, a następnie używanie SPC do zarządzania i rozwijania tych programów w nieskończoność. Ta praktyka znacznie zmniejsza liczbę szczegółów, które programiści aplikacji muszą znać i którymi muszą zarządzać. Pozwala również uniknąć redundancji, złożoności i błędów związanych z ręcznym kopiowaniem i redagowaniem tekstów źródłowych. Czas debugowania również się skraca, ponieważ większość komponentów jest ponownie wykorzystywana, a więc wstępnie testowana. Błędy mają tendencję do lokalizowania się w SPC, ponieważ są one najmniej testowane.

Szablon jest archetypem SPC z osadzonymi komentarzami wyjaśniającymi, jak go dostosować . Zazwyczaj istnieje niewielka liczba typów programów, z których każdy charakteryzuje się szablonem. Kopiując i wypełniając go, programiści przekształcają szablon w SPC bez konieczności pamiętania, jakich ramek potrzebują, relacji między komponentami lub jakie szczegóły zwykle wymagają dostosowania.

Języki specyficzne dla domeny oparte na ramkach

Oparty na FT język specyficzny dla domeny (FT-DSL) jest językiem specyficznym dla domeny , którego semantyka (wyrażona w kodzie programu) została umieszczona w ramkach . Typowy edytor FT-DSL dokonuje translacji między wyrażeniami DSL a ramką, która dostosuje semantykę ramek, aby wyrazić ekwiwalenty wyrażeń DSL w kodzie programu. SPC siedzący na szczycie tego podzespołu może następnie określić w kodzie programu wszelkie dostosowania niewyrażalne w języku specyficznym dla domeny. W ten sposób, gdy użytkownicy ponownie generują kod programu ze zmienionych wyrażeń DSL, wcześniejsze dostosowania nie są tracone.

Inżynieria ramy

Inżynieria ramowa stosuje inżynierię oprogramowania do środowiska technologii ramowej. Obejmuje to analizę domeny, projektowanie, pisanie, testowanie i współewolucję ram wraz z konstruowanymi przez nie systemami. Kadrowanie odbywa się zarówno od dołu do góry, jak i od góry do dołu. Oddolni inżynierowie ram zwykle tworzą ramki, łącząc i parametryzując grupy podobnych elementów programu (o dowolnej szczegółowości, od fragmentów tekstu po podsystemy) w ogólne odpowiedniki. Podejście odgórne łączy wiedzę specjalistyczną w danej dziedzinie z iteracyjnym udoskonalaniem prototypów, ograniczonym wymaganiami aplikacji i architektury, standardami korporacyjnymi oraz chęcią opracowania zestawu zasobów wielokrotnego użytku, których zwrot znacznie przewyższa inwestycję. (Ponowne wykorzystanie jest mierzone przez podzielenie całkowitego rozmiaru bibliotek ramek przez całkowity rozmiar powstałych konstruktów i/lub przez zliczenie pojedynczych ponownych zastosowań ramek.)

Dojrzała biblioteka ram zwiększa efektywność kosztową, ponieważ interesariusze projektu oprogramowania mogą ograniczyć swoją uwagę do nowości systemu, uznając większość jego solidnych komponentów i architektury za coś oczywistego. Dojrzała biblioteka nie jest statyczna. Inżynierowie ram mogą, używając polecenia select, ewoluować ramki wielokrotnego użytku w nieskończoność, spełniając nowe wymagania bez konieczności modernizacji programów wyprodukowanych z poprzednich wersji ramek.