Dlaczego nie możemy efektywniej uchwycić projektu oprogramowania? [Zamknięte]

Jako inżynierowie wszyscy „projektujemy” artefakty (budynki, programy, obwody, molekuły ...). To działanie (design-the-czasownik), które daje pewien wynik (design-the-rzeczownik).

Myślę, że wszyscy się zgadzamy, że rzeczownik jest innym bytem niż sam artefakt.

Kluczowym działaniem w branży oprogramowania (a właściwie w każdej firmie, w której należy ulepszyć powstały artefakt produktu) jest zrozumienie „projektu (rzeczownika)”. Wydaje się jednak, jako społeczność, całkowicie kompletnymi niepowodzeniami w rejestrowaniu tego, o czym świadczy wysiłek, jaki ludzie wkładają w odkrywanie faktów na temat swojej bazy kodu. Poproś kogoś, aby pokazał Ci projekt swojego kodu i zobaczył, co dostajesz.

Myślę, że projekt oprogramowania ma:

• Wyraźna specyfikacja tego, co oprogramowanie ma robić i jak dobrze to robi
• Wyraźna wersja kodu (ta część jest łatwa, wszyscy ją mają)
• Wyjaśnienie, w jaki sposób każda część kodu służy do osiągnięcia specyfikacji (np. Związek między fragmentami specyfikacji i fragmentami kodu)
• Uzasadnienie , dlaczego kod jest taki, jaki jest (na przykład, dlaczego dany wybór raczej niż inny)

To, co NIE jest projektem, jest szczególną perspektywą kodu. Na przykład [nie wybieraj specjalnie] diagramy UML nie są projektami. Są to raczej właściwości, które można uzyskać z kodu, lub prawdopodobnie właściwości, które można uzyskać z kodu. Ale z reguły nie można uzyskać kodu z UML.

Dlaczego po ponad 50 latach tworzenia oprogramowania dlaczego nie mamy regularnych sposobów na wyrażenie tego? (Zaprzeczaj mi wyraźnymi przykładami!)

Nawet jeśli to zrobimy, większość społeczności wydaje się tak skupiona na zdobywaniu „kodu”, że i tak gubi się rzeczownik projektu. (IMHO, dopóki projekt nie stanie się celem inżynierii, a artefakt zostanie wyjęty z projektu, nie będziemy tego omijać).

Co widziałeś jako środek do nagrywania projektów (w sensie, w którym to opisałem)? Przydałyby się wyraźne odniesienia do artykułów. Jak myślisz, dlaczego konkretne i ogólne środki okazały się nieskuteczne? Jak możemy to zmienić?

[Mam własne pomysły które podkreślają wypunktowany punkt widzenia powyżej, ale interesują mnie odpowiedzi innych ludzi ... i trudno jest wdrożyć mój plan [[i może to prawdziwy problem: -]]]

EDYCJA 2011/1/3: Jeden wątek odpowiedzi wskazuje, że „dokumentacja” (przypuszczalnie tekstowa, w szczególności nieformalna) może być odpowiednia. Chyba powinienem wyjaśnić, że nie wierzę w to. Narzędzia CASE pojawiły się na scenie od lat 80., ale wczesne narzędzia w większości przechwytywały piksele na schematach tego, co narysowałeś; chociaż narzędzia były prawdopodobnie komercyjnie udane, tak naprawdę nie były zbyt pomocne. Kluczowym wnioskiem było to, że jeśli dodatkowych artefaktów „projektowych” nie da się formalnie zinterpretować, nie można uzyskać poważnej pomocy ze strony narzędzia. Uważam, że ten sam wgląd dotyczy każdej długoterminowej użytecznej formy przechwytywania projektu: jeśli nie ma formalnej struktury, nie będzie miał żadnego rzeczywistego zastosowania. Dokumenty tekstowe prawie nie spełniają tego testu.

Myślę, że istnieje kilka powodów, dla których wciąż nie jesteśmy w tym dobrzy.

1. Ludzie przez długi czas choć oprogramowanie było jak domy, korzystali z procesów i pomysłów z budownictwa. „Architekt oprogramowania” był tytułem, którego pragnęli wszyscy programiści. W ciągu ostatnich dziesięciu lat architekt oprogramowania prawie wymarł. Pomysł na procesy kaskadowe, w których najpierw masz architekta mówiącego, jak oprogramowanie powinno działać i wyglądać, a następnie zachęcić ludzi do tworzenia diagramów tego, jak powinien być skonstruowany, a na końcu kod małpki implementujący te fajne schematy przepływu pracy / UML do specyfikacji, ten pomysł jest teraz szeroko wyśmiewane. Tak więc cały przemysł szczekał złą ścieżkę przez 40 lat.

2. Narzędzia, których używamy, ciągle się zmieniają i ulepszają. Programowanie to logiczna łamigłówka, a my opracowujemy lepsze pomysły i techniki, aby ją streścić i uczynić zrozumiałym. Sposób, w jaki to modelujemy, musi ewoluować z tą samą prędkością, ale pozostaje w tyle. Udoskonalone techniki wyodrębniania łamigłówki programowania oznaczają również, że możemy zwiększyć złożoność. I tak robimy. Programowanie zawsze leży na granicy złożoności, którą my, programiści, możemy sobie poradzić.

3. Tworzenie sposobów opisu programu jest rodzajem abstrakcji. Jeśli uda nam się wymyślić dobry sposób abstrakcji oprogramowania, możemy również umieścić tę abstrakcję bezpośrednio w narzędziach programistycznych, a tym samym dodać kolejną abstrakcję / uproszczenie do programowania. Stało się to wiele razy. Przykładami takich abstrakcji są funkcje, klasy i biblioteki.

4. W związku z tym; Jeśli masz udany i dokładny model oprogramowania, ten model będzie równoważny oprogramowaniu. Który rodzaj sprawia, że ​​cały wysiłek jest bezcelowy, co z kolei potwierdza punkt 1 powyżej: Modelowanie oprogramowania jest znacznie mniej przydatne niż wcześniej sądzono. Zamiast tego lepiej jest wyodrębnić dane o oprogramowaniu z kodu. Tworzenie modelu UML na podstawie wyglądu kodu jest znacznie bardziej pouczające niż tworzenie modelu UML i próba zaimplementowania tego modelu teoretycznego.

Być może zechcesz przejrzeć literaturę dotyczącą identyfikowalności oprogramowania. W szczególnej kolejności:

• CUBRANIC, D., MURPHY, GC, SINGER, J., AND BOOTH KELLOGG, S. Hipikat: pamięć projektu do tworzenia oprogramowania. Transakcje dotyczące inżynierii oprogramowania 31, 6 (2005), 446–65.
• TANG, A., BABAR, MA, GORTON, I., AND HAN, J. Badanie wykorzystania i dokumentacji uzasadnienia projektowania architektury. W Proc. V roboczej konferencji IEEE / IFIP nt. Architektury oprogramowania (2005).
• RAMESZ, B., POWERS, T., STUBBS, C. I EDWARDS, M. Identyfikowalność wymagań wykonawczych: studium przypadku. W Proc of the Int'l Symp on Requirements Engineering (York, 1995).
• HORNER, J., AND ATWOOD, ME Uzasadnienie projektowe: uzasadnienie i bariery. W Proc 4. Konferencji Nordyckiej na temat interakcji człowiek-komputer: zmiana ról (Oslo, Norwegia, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., AND CLARK, S. Najlepsze praktyki w zakresie automatycznej identyfikowalności. Komputer 40, 6 (czerwiec 2007), 27–35.
• ASUNCION, H., FRANÇOIS, F., AND TAYLOR, RN Kompleksowe narzędzie do śledzenia oprogramowania przemysłowego. W Proc. Szóstego wspólnego spotkania European Software Eng Conf i ACM SIGSOFT Int'l Symp na temat podstaw inżynierii oprogramowania (ESEC / FSE) (Dubrownik, 2007).

Zauważ, że to tylko wierzchołek góry lodowej i jestem pewien, że pominąłem kilka kluczowych dokumentów.

W osobnej notatce moja własna praca nad Arcum była dla programistów sposobem na wyrażenie IDE użycia przekrojowych idiomów projektowych. Po wyrażeniu, programiści mogli następnie przekształcić kod źródłowy, aby użyć alternatywnych implementacji:

• Macneil Shonle, William G. Griswold i Sorin Lerner. Więcej niż refaktoryzacja: ramy dla modułowej konserwacji idiomów projektowania przekrojowego . W materiałach z 6. Wspólnego Spotkania Europejskiej Konferencji Inżynierii Oprogramowania oraz Sympozjum ACM SIGSOFT na temat podstaw inżynierii oprogramowania (ESEC-FSE '07; 3-7 września 2007 r.). 175–184.

Nawiasem mówiąc, Arcum jest również związane z twoją pracą w DMS.

UML jest dla programu tym, czym są plany budynku w moim skromnym widoku. Same plany nie są oczywiście projektem, potrzebujesz do tego specyfikacji materiałowych (używanych narzędzi kodowych), ogólnego widoku budynku (niektóre schematyczne przedstawienie całego oprogramowania, w tym projektów GUI), jak budynek jest sadzony w otoczeniu (wyraźny schemat interakcji oprogramowania z innymi / jest instalowany w systemie operacyjnym), jego wpływ na klimat i glebę (interakcja ze sprzętem), ... Wiele książek o projektowaniu próbuje to zdefiniować, ale tak jak w przypadku wiele rzeczy w nauce, każdy naukowiec ma trochę swoją własną definicję.

Teraz również nie zgadzam się z twoją obserwacją, że nie możesz uzyskać kodu z UML. Możesz, jeśli masz dodatkowe informacje wymienione. Ale prawdziwy kod nie jest już projektem, to artefakt. Nie możesz też wydobywać prawdziwych kamieni i betonu z planu, ale potrzebujesz planu, aby umieścić prawdziwe kamienie i beton we właściwej formie i we właściwym miejscu.

W tym świetle uważam następujący artykuł za interesujący (spotkałem go w innym kontekście, kiedy szukałem oprogramowania graficznego, ale mimo to ...). Graficzne podejście do opisu projektu miało dla mnie sens, chociaż - znowu - to moim zdaniem tylko część projektu. Interesujące jest to, że takie podejście daje ramy do zrozumienia i refaktoryzacji projektów (w przeciwieństwie do refaktoryzacji oprogramowania), jak wskazano w następujących dokumentach:

• Wermelinger i Fiadeiro

• Tsantalis i in

Istnieje wiele innych podejść do opisu (części) projektu, takich jak projektowanie strukturalne (wykresy HIPO) lub projektowanie programów zintegrowanych , wzorce projektowe , ...

Jednak dopóki nie ma ustalonego standardu branżowego, uzyskanie „zwykłego” sposobu na wyrażenie tego jest mało prawdopodobne. Nawet po ponad 50 latach. I szczerze mówiąc, jeśli Twoja firma znajdzie dobry sposób na wyrażenie projektu, czy podzieliłbyś się nim ze światem?

Z własnego doświadczenia twierdziłbym, że dobrze wychwytujemy projektowanie oprogramowania. Posiadamy bazę danych dokumentów wymagań i projektu dla każdej pojedynczej funkcji, którą kiedykolwiek wdrożyliśmy na naszej platformie. Przypuszczam, że moja okoliczność może być wyjątkowa. Oto kilka rzeczy do przemyślenia.

Każda osoba w moim zespole ma dyplom inżyniera ... głównie EE lub CE. Inżynieria uczy projektowania w ramach programu nauczania.

Myślę, że jest wielu tak zwanych inżynierów oprogramowania, którzy pochodzą ze środowisk CS. Projektowanie oprogramowania nie jest integralną częścią większości programów CS. Nie twierdzę, że wszystkie kierunki CS są kiepskie w projektowaniu, ale chciałbym się założyć, że większość nie ma formalnego wykształcenia, które ich nauczyłoby. Myślę, że wiele osób zakłada, że ​​jeśli potrafisz programować, możesz projektować oprogramowanie, co nie jest prawdą. Biorąc pod uwagę, że wielu programistów nie ma wykształcenia inżynierskiego, nie jest zaskakujące, że w wielu projektach programowych nie ma zespołu, który byłby dobry w przechwytywaniu projektów.

Widzę dwa problemy.

Po pierwsze, cholernie trudno jest zsynchronizować kod i dokumentację. Jeśli są oddzielne, będą się rozchodzić, a dokumentacja stanie się bezużyteczna. Programiści próbowali używać narzędzi do synchronizacji (takich jak narzędzia CASE), ale narzędzia te dostały się między programistami a ich kodem, co spowodowało więcej szkód niż pożytku. Jednym z kluczowych wniosków dotyczących projektowania opartego na domenach (Evans, 2004) jest to, że dobry projekt jest naprawdę trudny, więc aby coś z niego uzyskać, musisz:

• wybierz najmniejszy możliwy obszar programu, w którym dobry projekt przyniesie ogromne korzyści, tzw. domena podstawowa
• bardzo ciężko pracować, aby uzyskać dobry projekt w postaci wszechobecnego języka, którego wszyscy członkowie zespołu używają przez cały czas
• w miarę możliwości, uczyń część projektu kodem

Innym dużym problemem związanym ze sposobem projektowania jest to, że nasze metody projektowania nie są wystarczająco matematyczne. Nieszczelne abstrakcje nie pozwalają na wyciąganie z nich rzetelnych wniosków, a świat ściśle stosowanej logiki i jasnej prawdy nazywa się matematyką, przed którą programiści w większości się unikają.

Nieliczne narzędzia matematyczne, jakie posiadamy, takie jak metody formalne, są bardzo nieporęczne.

Mapa-redukcja jest dobrym przykładem matematyki w programowaniu. Podstawowa idea jest taka: gdy masz asocjacyjną, binarną operację, możesz bardzo łatwo rozdzielić jej wykonanie. Operacja binarna jest funkcją o dwóch parametrach, skojarzenie oznacza, że ​​(a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 to

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99), gdzie As, Bs i Cs można w prosty sposób dodawać w różnych lokalizacjach, ich wyniki są gromadzone i podsumował w mgnieniu oka.

Zmniejszenie mapy to absurdalnie prosty pomysł. Można to opisać na jednym kawałku papieru. Jeśli możesz założyć, że czytelnik dobrze orientuje się w koncepcji asocjatywności, jeśli mieści się na dość małym kawałku papieru. Teraz spróbuj wyjaśnić komuś redukcję mapy bez używania terminu „skojarzenie” lub odwoływania się do niego pośrednio. Wyzywam cię.

Projektowanie oprogramowania bez abstrakcji matematycznych przypomina próbę tworzenia architektury bez zawracania sobie głowy nauką geometrii.

Może Haskell może to naprawić z czasem. Zastosowanie pojęć z teorii kategorii do opisywania programów wydaje mi się obiecujące. Teoria kategorii jest tak abstrakcyjna, że ​​nawet matematycy mieli z niej niewiele pożytku, ale najwyraźniej kategorie, które są abstrakcyjne nie do poznania, wydają się wystarczająco abstrakcyjne, aby opisać strukturę oprogramowania. Dowiemy się. Powoli.