Asystent oprogramowania opartego na wiedzy

Asystent oprogramowania opartego na wiedzy (KBSA) był programem badawczym finansowanym przez Siły Powietrzne Stanów Zjednoczonych . Celem programu było zastosowanie koncepcji sztucznej inteligencji do problemu projektowania i wdrażania oprogramowania komputerowego . Oprogramowanie byłoby opisywane za pomocą modeli w językach bardzo wysokiego poziomu (zasadniczo równoważnych logice pierwszego rzędu ), a następnie reguły transformacji przekształcałyby specyfikację w wydajny kod. Siły powietrzne miały nadzieję, że będą w stanie wygenerować oprogramowanie do sterowania systemami uzbrojenia oraz inne systemy dowodzenia i kontroli wykorzystujące tę metodę. Ponieważ oprogramowanie stawało się coraz bardziej krytyczne dla systemów uzbrojenia USAF, zdano sobie sprawę, że poprawa jakości i wydajności procesu tworzenia oprogramowania może przynieść znaczące korzyści dla wojska, a także dla technologii informatycznych w innych głównych gałęziach przemysłu USA.

Historia

Na początku lat 80. Siły Powietrzne Stanów Zjednoczonych zdały sobie sprawę, że odniosły znaczne korzyści z zastosowania technologii sztucznej inteligencji do rozwiązywania problemów eksperckich , takich jak diagnozowanie usterek w samolotach. Siły powietrzne zleciły grupie badaczy ze sztuczną inteligencją i metodami formalnymi opracowanie raportu na temat tego, w jaki sposób takie technologie mogą być wykorzystane do pomocy w bardziej ogólnym problemie tworzenia oprogramowania.

W raporcie opisano wizję nowego podejścia do tworzenia oprogramowania. Zamiast definiować specyfikacje za pomocą diagramów i ręcznie przekształcać je w kod, jak to miało miejsce w obecnym procesie, wizją Asystenta oprogramowania opartego na wiedzy (KBSA) było zdefiniowanie specyfikacji w językach bardzo wysokiego poziomu, a następnie użycie reguł transformacji w celu stopniowego udoskonalania specyfikacji w wydajny kod na heterogenicznych platformach.

Każdy etap projektowania i udoskonalania systemu byłby rejestrowany jako część zintegrowanego repozytorium. Oprócz artefaktów związanych z tworzeniem oprogramowania, procesy, różne definicje i transformacje byłyby również rejestrowane w sposób umożliwiający ich analizę, a także późniejsze odtworzenie w razie potrzeby. Chodziło o to, aby każdy krok był transformacją uwzględniającą różne wymagania niefunkcjonalne dla wdrażanego systemu. Na przykład wymagania dotyczące używania określonych języków programowania, takich jak Ada, lub wzmocnienia kodu w celu zapewnienia odporności na krytyczne błędy w czasie rzeczywistym.

Siły powietrzne zdecydowały się sfinansować dalsze badania nad tą wizją za pośrednictwem laboratorium Rome Air Development Center w bazie lotniczej Griffiss w Nowym Jorku. Większość wczesnych badań przeprowadzono w Instytucie Kestrel w Północnej Kalifornii (wraz z Uniwersytetem Stanforda ) oraz w Instytucie Nauk Informacyjnych (ISI) w Południowej Kalifornii (wraz z USC i UCLA ). ). Instytut Kestrel skupił się przede wszystkim na możliwej do udowodnienia poprawnej transformacji modeli logicznych w wydajny kod. ISI skupiło się przede wszystkim na przedniej części procesu, definiując specyfikacje, które można odwzorować na formalizmy logiczne, ale były one w formatach intuicyjnych i znanych analitykom systemowym. Ponadto Raytheon zrealizował projekt mający na celu zbadanie nieformalnego zbierania wymagań, a firma Honeywell i Uniwersytet Harvarda pracowały nad bazowymi platformami, integracją i koordynacją działań.

MIT Programmer's Apprentice nie był finansowany głównie z programu KBSA, miał również wiele takich samych celów i wykorzystywał te same techniki, co KBSA.

W późniejszych etapach programu KBSA (począwszy od 1991 r.) badacze opracowali prototypy, które były używane w przypadku problemów związanych z tworzeniem oprogramowania na średnią i dużą skalę. Ponadto na tych późniejszych etapach nacisk przesunął się z podejścia opartego wyłącznie na KBSA na bardziej ogólne pytania dotyczące wykorzystania technologii opartej na wiedzy w celu uzupełnienia i rozszerzenia istniejących i przyszłych inżynierii oprogramowania wspomaganego komputerowo (CASE). Na tych późniejszych etapach istniała znacząca interakcja między społecznością KBSA a społecznościami zorientowanymi obiektowo i inżynierią oprogramowania. Na przykład koncepcje i badacze KBSA odegrali ważną rolę w programach mega-programowania i inżynierii oprogramowania zorientowanych na użytkownika, sponsorowanych przez Agencja Zaawansowanych Projektów Badawczych w Obronie (DARPA). Na tych późniejszych etapach program zmienił nazwę na Inżynieria oprogramowania oparta na wiedzy (KBSE). Zmiana nazwy odzwierciedlała inny cel badawczy, którym nie było już tworzenie całkowicie nowego, wszechstronnego narzędzia, które obejmowałoby cały cykl życia oprogramowania, ale stopniowe wprowadzanie technologii opartej na wiedzy do istniejących narzędzi. Firmy takie jak Andersen Consulting (jeden z największych integratorów systemów i wówczas dostawca własnego narzędzia CASE) odegrały główną rolę w programie na późniejszych etapach.

Kluczowe idee

Zasady transformacji

Reguły transformacji stosowane przez KBSA różniły się od tradycyjnych reguł dla systemów ekspertowych. Reguły transformacji dopasowane do specyfikacji i języków implementacji, a nie do faktów na świecie. Możliwe było określenie transformacji za pomocą wzorców, symboli wieloznacznych i rekurencji zarówno po prawej, jak i po lewej stronie reguły. Wyrażenie po lewej stronie określa wzorce w istniejącej bazie wiedzy do wyszukania. Wyrażenie prawej ręki może określać nowy wzór do przekształcenia lewej strony. Na przykład przekształć typ danych teorii mnogości w kod przy użyciu biblioteki zestawów Ada.

Początkowym celem reguł transformacji było udoskonalenie specyfikacji logicznej wysokiego poziomu w dobrze zaprojektowany kod dla określonej platformy sprzętowej i programowej. Zostało to zainspirowane wczesnymi pracami nad dowodzeniem twierdzeń i programowaniem automatycznym. Jednak naukowcy z Instytutu Nauk Informacyjnych (ISI) opracowali koncepcję przemian ewolucyjnych . Zamiast przekształcania specyfikacji w kod, transformacja ewolucyjna miała na celu zautomatyzowanie różnych stereotypowych zmian na poziomie specyfikacji, na przykład opracowanie nowej nadklasy poprzez wyodrębnienie różnych możliwości z istniejącej klasy, które można ogólnie współdzielić. Transformacje ewolucyjne zostały opracowane mniej więcej w tym samym czasie, co pojawienie się społeczności wzorców oprogramowania, a obie grupy miały wspólne koncepcje i technologię. Transformacje ewolucyjne były zasadniczo tym, co jest znane jako refaktoryzacja w społeczności zorientowanych obiektowo wzorców oprogramowania.

Repozytorium oparte na wiedzy

Kluczową koncepcją KBSA było to, że wszystkie artefakty: wymagania, specyfikacje, transformacje, projekty, kod, modele procesów itp. były reprezentowane jako obiekty w repozytorium opartym na wiedzy . Oryginalny raport KBSA opisuje tak zwany język szerokiego spektrum. Wymagano reprezentacji wiedzy , które mogłyby obsługiwać cały cykl życia : wymagania, specyfikacja i kod, a także sam proces tworzenia oprogramowania. Podstawowa reprezentacja bazy wiedzy miała wykorzystywać te same ramy, chociaż można było dodawać różne warstwy w celu obsługi określonych prezentacji i implementacji.

Te wczesne ramy bazy wiedzy zostały opracowane głównie przez ISI i Kestrel, budując na środowiskach maszynowych Lisp i Lisp . Środowisko Kestrel zostało ostatecznie przekształcone w komercyjny produkt o nazwie Refine, który został opracowany i wspierany przez firmę wydzieloną z Kestrel o nazwie Reasoning Systems Incorporated.

Język i środowisko Refine sprawdziły się również w przypadku problemu inżynierii wstecznej oprogramowania: przejęcie starszego kodu, który ma kluczowe znaczenie dla biznesu, ale brakuje mu odpowiedniej dokumentacji, oraz wykorzystanie narzędzi do jego analizy i przekształcenia go w łatwiejszą w utrzymaniu formę. Wraz z rosnącym niepokojem związanym z problemem roku 2000 , inżynieria odwrotna stała się głównym problemem biznesowym wielu dużych amerykańskich korporacji i była obszarem zainteresowania badań KBSA w latach 90.

Wystąpiła znacząca interakcja między społecznościami KBSA a społecznościami języka ramkowego i zorientowanymi obiektowo . Wczesne bazy wiedzy KBSA były implementowane w językach obiektowych, a nie zorientowanych obiektowo . Obiekty były reprezentowane jako klasy i podklasy, ale nie było możliwości definiowania metod na obiektach. W późniejszych wersjach KBSA, takich jak Andersen Consulting Concept Demo, język specyfikacji został rozszerzony, aby obsługiwał również przekazywanie komunikatów.

Inteligentny asystent

KBSA przyjęło inne podejście niż tradycyjne systemy eksperckie, jeśli chodzi o rozwiązywanie problemów i pracę z użytkownikami. W tradycyjnym podejściu do systemu eksperckiego użytkownik odpowiada na szereg interaktywnych pytań, a system dostarcza rozwiązanie. Podejście KBSA pozostawiło kontrolę użytkownikowi. Tam, gdzie system ekspercki próbował w pewnym stopniu zastąpić i wyeliminować potrzebę eksperta, podejście inteligentnego asystenta w KBSA dążyło do ponownego wynalezienia procesu za pomocą technologii. Doprowadziło to do szeregu innowacji na poziomie interfejsu użytkownika.

Przykładem współpracy społeczności zorientowanej obiektowo z KBSA była architektura interfejsów użytkownika KBSA. Systemy KBSA wykorzystywały interfejs użytkownika modelu-widok-kontroler (MVC). Był to pomysł zaczerpnięty ze środowisk Smalltalk. Architektura MVC była szczególnie dobrze dopasowana do interfejsu użytkownika KBSA. Środowiska KBSA zawierały wiele heterogenicznych widoków bazy wiedzy. Przydatne może być spojrzenie na powstający model z punktu widzenia jednostek i relacji, interakcji między obiektami, hierarchii klas, przepływu danych i wielu innych możliwych perspektyw. Ułatwiła to architektura MVC. W architekturze MVC podstawowym modelem była zawsze baza wiedzy, która była metamodelu specyfikacji i języków implementacji. Gdy analityk dokonał jakiejś zmiany za pomocą określonego diagramu (np. dodał klasę do hierarchii klas), zmiana ta została wprowadzona na poziomie modelu bazowego, a różne widoki modelu zostały automatycznie zaktualizowane.

Jedną z korzyści płynących z zastosowania transformacji było to, że wiele aspektów specyfikacji i implementacji można było modyfikować jednocześnie. W przypadku prototypów na małą skalę diagramy wynikowe były na tyle proste, że wystarczyły podstawowe algorytmy układu w połączeniu z poleganiem na użytkownikach w celu oczyszczenia diagramów. Kiedy jednak transformacja może radykalnie przerysować modele z dziesiątkami, a nawet setkami węzłów i powiązań, ciągła aktualizacja różnych widoków staje się zadaniem samym w sobie. Badacze z Andersen Consulting wykorzystali prace z teorii grafów z University of Illinois, aby automatycznie aktualizować różne widoki powiązane z bazą wiedzy i generować wykresy, które mają minimalne przecięcia łączy, a także uwzględniają ograniczenia specyficzne dla domeny i układu użytkownika.

Inną koncepcją wykorzystaną do zapewnienia inteligentnej pomocy było automatyczne generowanie tekstu. Wczesne badania w ISI dotyczyły możliwości wyodrębnienia formalnych specyfikacji z nieformalnych dokumentów tekstowych w języku naturalnym. Uznali, że podejście nie jest opłacalne. Język naturalny jest z natury po prostu zbyt niejednoznaczny, aby mógł służyć jako dobry format do definiowania systemu. Uznano jednak, że generowanie języka naturalnego jest wykonalne jako sposób generowania opisów tekstowych, które mogą być odczytywane przez menedżerów i personel nietechniczny. Było to szczególnie atrakcyjne dla sił powietrznych, ponieważ zgodnie z prawem wymagały one od wszystkich wykonawców generowania różnych raportów opisujących system z różnych punktów widzenia. Naukowcy z ISI, a później Cogentext i Andersen Consulting wykazali wykonalność tego podejścia, wykorzystując własną technologię do generowania dokumentacji wymaganej przez ich kontrakty sił powietrznych.