Dlaczego nie wszyscy jeszcze opracowujemy modele? [Zamknięte]

Jestem prawdziwym zwolennikiem rozwoju opartego na modelu, myślę, że ma on możliwość zwiększenia produktywności, jakości i przewidywalności. Patrząc na MetaEdit wyniki są niesamowite. Dodatek w Holandii rośnie bardzo szybko i ma świetne wyniki.

Wiem też, że jest wiele problemów

• wersjonowanie generatorów, szablonów i frameworka
• projekty, które po prostu nie są odpowiednie dla rozwoju opartego na modelu (niewystarczająca ilość powtórzeń)
• wyższe ryzyko (gdy pierwszy projekt nie powiedzie się, masz mniej wyników niż przy bardziej tradycyjnym rozwoju)
• itp

Ale nadal problemy te wydają się możliwe do rozwiązania, a korzyści powinny przewyższać potrzebny wysiłek.

Pytanie : Co uważasz za największe problemy, które sprawiają, że nawet nie rozważasz rozwoju opartego na modelu?

Chcę wykorzystać te odpowiedzi nie tylko dla własnego zrozumienia, ale również jako możliwe źródło szeregu wewnętrznych artykułów, które zamierzam napisać.

Nie ma złotego młota. To, co działa dobrze w jednej domenie, jest zupełnie bezużyteczne w innej. Tworzenie oprogramowania ma pewną złożoność i żadne magiczne narzędzie go nie usunie.

Można również argumentować, że generowanie kodu jest użyteczne tylko wtedy, gdy sam język (lub środowisko) nie jest wystarczająco wysoki, aby umożliwić tworzenie silnych abstrakcji, które sprawiłyby, że MDD stałoby się bezcelowe.

Interesujące pytanie! Przyznaję, że nie jestem fanem, ale potem kilkakrotnie próbowałem wykorzystać rozwój oparty na modelach w projektach, które pasują do niektórych właśnie poruszonych problemów.

Oto moja lista przyczyn:

• nauka krzywej - narzędzia do modelowania ewoluowały tak szybko, że ciężko mi znaleźć inżynierów, którzy głęboko rozumieją to narzędzie. Nadal uważam, że jesteś tak dobry jak twoje narzędzie do modelowania. Trzeba przyznać, że wiele z poniższych problemów może rozwiązać ten jeden problem - za każdym razem, gdy uważasz, że narzędzie jest zbyt ograniczone, możliwe, że nie znasz go wystarczająco dobrze.
• Zbyt ustrukturyzowany - osobiście byłem w sytuacjach, w których zauważyłem, że narzędzie do modelowania było po prostu zbyt ustrukturyzowane, aby pozwolić mi opisać wszystko, co musiałem opisać. A kiedy przejdę do rysowania fragmentów modelu poza narzędziem, wszystko szybko się psuje, gdy ludzie zaczynają dryfować poza narzędziem, aby znaleźć informacje.
• Koszt strojenia narzędzia - za każdym razem, gdy próbuję wygenerować kod automatycznie, przerabiam go ręcznie, gdy widzę, co narzędzie uważało za właściwe. Wiem, że po kilku obchodach ten problem maleje, ale to oznacza, że ​​musisz przetrwać kilka pierwszych rund. Generalnie czułem, że graliśmy w walenie z kretem - twórz model -> generuj kod -> napraw kod -> zaktualizuj model -> napraw model, spłucz i powtórz.
• Zarządzanie konfiguracją modelu - ponieważ model opisuje duże części projektu, na pewnym poziomie model CM będzie bardziej przekrojowy niż zbudowany kod. Podział plików modelowania na segmenty sam w sobie jest sztuką - zrób to źle, a często kończy się impas programisty lub przestarzałe modele, gdy ludzie poddają się i przechodzą do kodu.
• czas na rynek - napotkałem określone problemy w sytuacji, gdy potrzeba pracy oprogramowania była pilna. Jeśli projekt i zespół są wystarczająco małe, nie widzę powodu, aby tracić czas na narzędzie do modelowania, kiedy można poświęcić czas na kodowanie i testowanie. Nie każdy projekt jest wystarczająco duży, aby wymagać takiej inwestycji.
• Koszt awarii - kiedy widziałem, jak projekty uciekają przed narzędziami do modelowania, wynika to z wysokiego kosztu awarii - aby korzystać z narzędzi, musisz zaangażować każdego programistę. To wielka inwestycja w szkolenie i praktyczna nauka oraz bardzo kosztowny błąd, jeśli ktoś źle skonfigurował model. Z mojego doświadczenia wynika, że ​​poprawność modelu może zająć dwie lub trzy wersje - tak wiele projektów nie przeżywa błędów modelowania wystarczająco długo, aby uświadomić sobie korzyści.

Jest już cytowany, ale nie ma srebrnej kuli całkiem dobrze odnosi się do tej kwestii:

Istotą bytu programowego jest konstrukcja powiązanych ze sobą pojęć: zestawów danych, relacji między elementami danych, algorytmów i wywoływania funkcji. Ta esencja jest abstrakcyjna, ponieważ taka konceptualna konstrukcja jest taka sama w wielu różnych reprezentacjach. Jest jednak bardzo precyzyjny i bogaty w szczegóły.

Uważam, że trudną częścią budowania oprogramowania jest specyfikacja, projekt i testowanie tego konceptualnego konstruktu, a nie pracochłonność jego reprezentowania i testowania wierności przedstawienia. Dla pewności wciąż popełniamy błędy składniowe; ale są one niewyraźne w porównaniu z błędami koncepcyjnymi większości systemów.

Jeśli to prawda, tworzenie oprogramowania zawsze będzie trudne. Z natury nie ma srebrnej kuli.

Później Brooks zwraca uwagę na następujące pojęcie „automatycznego programowania”:

Od prawie 40 lat ludzie przewidują i piszą o „programowaniu automatycznym” lub generowaniu programu do rozwiązania problemu na podstawie specyfikacji specyfikacji problemu. Niektórzy dziś piszą, jakby oczekiwali, że ta technologia zapewni kolejny przełom.

Parnas sugeruje, że termin ten jest używany dla glamour, a nie dla treści semantycznej, stwierdzając: „Krótko mówiąc, automatyczne programowanie zawsze było eufemizmem dla programowania w języku wyższego poziomu niż obecnie dostępny dla programisty”.

Twierdzi on w istocie, że w większości przypadków jest to metoda rozwiązania, a nie problem, którego specyfikację należy podać.

Zasadniczo twierdzę, że MDD to kolejny eufemizm programowania z językiem wyższego poziomu niż wcześniej dostępny.

Nie oznacza to, że programowanie w języku wyższego poziomu nie może pomóc - w rzeczywistości często może. Ale istota problemu pozostaje taka sama: nie ważne jak wielkie narzędzie lub jak wielkie to język, którego używasz, na koniec dnia jesteś trzeba przemyśleć wszystkie problemy i rozwiązywać problemy. Najlepsze narzędzie lub proces, jaki może zrobić, to usunięcie „kłębka”, abyś mógł skupić się na ważnym problemie, jakim jest, jak powiedział Brooks, „ specyfikacja , projekt i testowanie tego konceptualnego konstruktu ”.

Ponieważ nie każde programowanie jest zorientowane obiektowo, czego wydają się oczekiwać wszystkie narzędzia MDD. Sam UML opiera się na domniemaniu obiektów. Jasne, że możesz używać diagramów sekwencji do modelowania funkcji, ale wiele razy jest to niezdarne.

Ponieważ są programiści tacy jak ja, którzy uzyskują większy postęp i wyniki z TDD niż MDD.

Ponieważ Modelowanie! = Programowanie.

Ponieważ koszt / korzyść była zbyt wysoka po stronie kosztów i niewystarczająca po stronie korzyści. Prawdopodobnie zmieniło się to od czasu, gdy ostatnio spojrzałem na MDD, wtedy musiałbyś zapłacić> 6000 $ / stanowisko (USD) za narzędzie, które byłoby umiarkowanie zdolne do MDD.

Ponieważ model, który wystarczająco opisuje funkcję do wygenerowania kodu, nie jest już użyteczny jako model.

Ponieważ są programiści tacy jak ja, którzy używają modeli tylko na wysokim poziomie, a następnie opracowują szczegóły za pomocą kodu. W kodzie widzisz inaczej niż w oprogramowaniu do modelowania.

To niektóre z powodów, dla których osobiście nie robię MDD. Byłem na to narażony, ale nic nie mogło mnie przekonać do nawrócenia. Być może jestem zbyt starą szkołą. Być może jestem zbyt nową szkołą (cokolwiek to jest). To po prostu nie jest narzędzie, za które byłem w stanie sam sobie zapłacić.

Microsoft / Apple / Google go nie naciska :)

Rodzaj popularyzacji rozwoju ma wiele wspólnego z narzędziami, wsparciem i ewangelizacją. Bardzo trudno jest przedostać się przez coś bez dużego backera (Ruby na szynach może być wyjątkiem, ale wciąż jest niewielki w porównaniu do Java / C # / Python)

Ze względu na proste prawo, które wpłynęło na wszystkie te narzędzia do modelowania, CASE, UML i takie:

Wejście między programistę a jego kod jest bardzo kosztowne.

Jeśli to zrobisz, musisz zbudować odpowiedni kompilator / interpreter, generatory kodu powodują okropny przepływ pracy i okropne informacje zwrotne dla programisty (komunikaty o błędach itp.).

Jednym ze wspaniałych wniosków związanych z projektowaniem opartym na domenach jest to, że modele powinny być w kodzie, a nie w czymś innym niż kod.

Ostatecznie pytanie brzmi: dlaczego twoje modele nie pasują do kodu? Jeśli zajmujesz się programowaniem osadzonym i utkniesz w C lub musisz wygenerować kod dla różnych platform, generowanie kodu może być tego warte. Dla wszystkich innych, bardziej zaawansowany język programowania i lepszy projekt kodu są zwykle lepsze niż projektowanie kodu w czymś innym niż kod.

• Wydaje się, że to gigantyczny kłopot, za bardzo niewielką korzyść.
• Wydaje mi się, że zawsze mam do czynienia z przypadkowymi przypadkami i dziwnymi rzeczami, magia nigdy tak naprawdę nie działa poprawnie.
• OO nie jest srebrną kulą; obrzucenie OO metodologią generującą oprogramowanie nie czyni go srebrnym.

Ale ogólnie nie lubię rozwiązań dla przedsiębiorstw.

Miałem dyskusję i chciałbym zrobić MDA, ale największą wadą jest na razie wsparcie narzędziowe. Korzystam z pochodnej MDA, którą lubię nazywać „oceną modelu wykonawczego”, ale o tym później.

Wady MDA to, jak wiem:

• Brak obsługi refaktoryzacji: Niech zgadnę, że chcę modelować jednostki mojego modelu danych za pomocą MDA (typowy przypadek użycia nr 1). Jeśli mam mój model, powiedzmy, diagram UML i zmieniam go, nic z mojego kodu nie zmienia się wraz z nim (przynajmniej wygenerowane klasy) i zamiast mieć działającą aplikację z lepiej nazwanymi atrybutami, otrzymuję wiele błędów muszę poprawić ręcznie.
• Brak obsługi debugowania: zwykle tłumaczenia z modelu na kod są wykonywane przy pomocy języka transformacji. Zwykle nie stanowiło to problemu, ale podczas debugowania optymalnie nie powinniśmy martwić się generowanym kodem, a debuger powinien wejść w model transformacji. Zamiast tego wkracza do wygenerowanego kodu i jak wszyscy wiemy transformacje powinny wyglądać dobrze, a nie wygenerowany kod. Okej, możemy go dość wydrukować, ale w optymalnym świecie wygenerowany kod jest artefaktem kompilatora i nigdy nie powinien być otwierany w edytorze do sesji debugowania (mógłbym z tym żyć, a ten argument jest trochę teoretyczny, ale jest to jeden powód przeciwko MDA)
• Modele kodowane są łatwe: w innych przykładach Model może modelować pewien aspekt domeny, a następnie jest kompilowany w kodzie. Tak, to MDA, ale większość modeli MDA to po prostu wyrafinowane pliki konfiguracyjne, które można łatwo obsłużyć w czasie wykonywania.
• Transformacje są trudne do przetestowania: jeśli używasz transformacji w specjalistycznym środowisku IDE, są one wykonywane przez „kompilator” IDE. Ale transformacje należy postrzegać jako część kodu aplikacji i jako takie powinny one również podlegać testom i wymaganiom pokrycia kodu aplikacji.

To, co obecnie preferuję, to „Runtime Model Evaluation” (jeśli ktoś zna akceptowaną nazwę tego, proszę mnie oświecić). Moje podmioty są przechowywane w zwykłych klasach Java, a wszystko, czego potrzebuję do „modelowania”, jest tworzone przez adnotacje czytane na początku aplikacji. Nie potrzebuję żadnych transformacji, tylko trochę trudno było poprawnie ustawić mój model meta.

Wszystko inne odbywa się albo za pomocą plików właściwości, albo XML dla danych hierarchicznych. Jeśli masz model, jest on zawsze hierarchiczny, więc nie możesz modelować niczego, czego nie można również wyrazić za pomocą XML. A jeśli potrzebujesz specjalnego edytora modeli, który prawdopodobnie będziesz musiał również napisać, możesz również zbudować edytor, który działa nawet w czasie wykonywania aplikacji i sprawia, że ​​aplikacja jest bardziej konfigurowalna niż wszystko, co możesz modelować.

Wydaje mi się, że większość osób używających No Silver Bullet Freda Brooksa, aby wyjaśnić, dlaczego ludzie nie robią MDD, nie rozumie, o czym mówi Brooks. Jasne, końcowy wniosek jest taki, że faktyczna złożoność oprogramowania nigdy nie zniknie, a więc MDD tego nie rozwiąże.

Ale jednym z powodów, dla których Brooks nawet omawia tę wewnętrzną złożoność, jest porównanie jej z dużą ilością czasu, jaki zwykle spędzamy na walce z językami, bibliotekami i narzędziami, tj. Nie zajmując się wewnętrzną złożonością problemu, który próbujemy rozwiązać. Właśnie w tym właśnie błyszczy MDD: odcinając wszystkie kłótnie i tworząc język, model lub inny formalizm dostosowany do rzeczywistej złożoności.

Z tego punktu widzenia No Silver Bullet jest doskonałym powodem do inwestowania w MDD. Oznacza to, że gdyby nie problem, który moim zdaniem utrudnia przyjęcie MDD: faktyczne opracowanie środowiska opartego na modelu, które pozwala całkowicie skupić się na wewnętrznej złożoności problemu, który próbujesz rozwiązać, jest znacznie trudniejsze niż po prostu rozwiązanie problemu w języku ogólnego przeznaczenia bezpośrednio. Głównie dlatego, że istniejące narzędzia MDD są niezwykle złożone.

Porównaj to w ten sposób: o wiele łatwiej jest napisać program w C niż napisać kompilator C. Zamiast po prostu rozwiązać problem i poradzić sobie z cruft w języku ogólnego przeznaczenia, stworzenie środowiska MDD dla innych programistów wymaga zasadniczo napisania programu, który rozwiąże wszystkie możliwe problemy związane z cruft w obszarze problemów z góry. To dość trudne.

Według mojej wiedzy, MDE i MDA w niewystarczający sposób zaspokajają potrzeby dewelopera wbudowanego kontrolera. Modele z pewnością mogą być użyte do opisania systemu, ale nie sądzę, że wbudowany programista jest gotowy zaufać modelowi, że dostarczy najlepszy, a nawet poprawny kod źródłowy.

Istnieje wiele wtyczek dla Eclipse, które pozwalają programistom użyć modelu do stworzenia / aktualizacji kodu Java lub kodu Java do stworzenia / aktualizacji modelu. To wydaje się przydatnym narzędziem. Niestety, cały mój rozwój odbywa się w ANSI / ISO C i nie ma żadnych wtyczek, o których jestem świadomy, które pozwoliłyby mi zrobić to samo.

Ponadto, w jaki sposób deweloper może poinstruować model, aby zaimplementował kod jako HSM sterowany zdarzeniem lub jakiś inny wzorzec projektowy w stosunku do dowolnego innego wzorca projektowego (lub anty-wzorca)? Jeśli kod jest ręcznie aktualizowany w celu użycia nieznanego wzorca projektowego, czy model może dokładnie to przedstawić?

Jak wdrożyć te funkcje, które nie pasują do modelu?

Krótka odpowiedź… ponieważ model sterowany jest często związany z generowaniem kodu, a kod jest kruchy; to, czego potrzebujemy, to eliminacja kodu i modelowanie, to z pewnością droga.

Niektórzy odrzucili pytanie, argumentując, że nie ma złotego młota i że tworzenie oprogramowania jest z natury złożone.

W pełni się z nimi zgadzam, że nie ma złotego młota, ale nie sądzę, że model napędzany jest poszukiwaniem złotych młotków lub srebrnych kul!

Chciałbym pójść dalej ze złożonością; istnieją dwa rodzaje złożoności, które nazywam złożonością organiczną lub naturalną, złożonością nieodłączną dla biznesu i jego procesów, ale mamy także ceremonialną złożoność.

Złożoność, która wkrada się do instrukcji systemowych według instrukcji, dzień po dniu. Ceremonialna złożoność - niepotrzebna złożoność - wynika przede wszystkim z niekontrolowanego mieszania kodu technicznego z kodem biznesowym, ale także z braku struktury i jednolitości w systemie.

Dziś cała złożoność, która nawiedza rozwój systemów informatycznych i powoduje awarie i talię, jest ceremonialną złożonością; złożoność, którą można wyeliminować.

Ceremonialna złożoność to marnotrawstwo, marnotrawstwo spowodowane przez kod, mniej wartości, zmień niekorzystny, niezmienny kod; kod, który należy zredukować do jego ścisłego minimum.

Jak to zrobić? Łatwo! Po prostu nie pisz tego i nie generuj go, po pierwsze!

Niezbędny, niezmienny kod techniczny; kod używany do odczytu / zapisu, wyświetlania, komunikowania się… Tam wkraczają modele, opisując logiczną strukturę danych - dodałbym w sposób relacyjny - modele mogą umożliwić ogólną obsługę standardowego odczytu / zapisu, wyświetlania i komunikacji dane.

Jest jak system operacyjny, nie przepisujesz go dla każdego projektu, z którego korzystasz. Potrzebny jest więc silnik techniczny, który obsługuje niezmienne aspekty oprogramowania w danym modelu. Nazywam to silnikiem AaaS (Architecture as a Service).

Jeśli chodzi o niepotrzebny kod, cóż, jest to niepotrzebny kod, więc równie dobrze może zostawić go niepisany.

To pozostawia nam niezbędny, zorientowany na biznes kod, który powinien zostać napisany, niezbędne dane zorientowane biznesowo, które powinny zostać zaprojektowane, niezbędny interfejs użytkownika oraz doświadczenie, które należy zaprojektować i wyobrazić.

Eliminując delikatny kod, możemy objąć architekturę jako usługę nowym paradygmatem rozwoju oprogramowania opartym bardziej na modelowaniu i projektowaniu niż na kodzie.

Uważam, że istnieje kilka powodów, ale jednym jest na pewno to, że MDD nie ma w programie nauczania uniwersytetów. Zazwyczaj najbliższy jest kurs, który uczy modelowania i tam modele pozostają jako szkice (bez sprawdzania, generowania kodu, debugowania na poziomie modelu). Ten kurs „modelowania” często wprowadza również UML, a studenci zastanawiają się, dlaczego uczyć się tak dużej i złożonej notacji, gdy wartość tworzonych modeli jest niska.

Porównaj to z innymi dziedzinami inżynierii, takimi jak deweloperzy sprzętu wbudowanego lub inżynierowie sterowania, w których studenci mają zupełnie inne doświadczenia. Za pomocą narzędzi takich jak Simulink lub Labview uczniowie mogą narysować model, a następnie wygenerować kod lub przynajmniej uruchomić go w symulacji.

W przeszłości uniwersytety uczyły kompilatorów i parserów, ale teraz powinny uczyć, jak tworzyć generatory, implementować DSL itp.

Rozwój oparty na modelach nie ma sensu, ponieważ jest to odgórne podejście do modelu. Niemożliwe jest stworzenie w pełni działającej aplikacji tylko z modelu, dlatego MDD jest bezużyteczne !!

Używam UML tylko na wyższym poziomie abstrakcji do stworzenia szkieletu mojej aplikacji. Mam na myśli tworzenie pakietów, klas itp., A następnie natychmiast rozpocząć kodowanie w języku Java.

Odkryłem, że synchronizacja na żywo z narzędziami takimi jak Togethersoft, Omondo była naprawdę przydatna, kiedy po raz pierwszy zacząłem modelować w 2004 roku. Omondo niedawno wprowadził nowy etap, który jest rodzajem mapowania między Javą, modelem i identyfikatorem bazy danych. Naprawdę potężny i działa dobrze w moich projektach.

Moje diagramy UML pomagają mi teraz przyspieszyć mój projekt i nie są już bezużyteczne :-)

MDD dodaje kolejny krok do procesu rozwoju, co jest wadą w sytuacjach, w których nie ma dobrego modelu, a pierwsze nieprzewidywalne lub prawie zepsute częściowe rozwiązanie rynkowe może wygrać najwięcej marmurów.

Holly Graal ma wykonalne modele procesów biznesowych. Teoretycznie wcale nie potrzebujesz do tego programistów. Praktyka pokazuje, że przy MDE faktyczne uruchomienie modelu jest tak samo skomplikowane jak pisanie kodu.

Dla doświadczonego programisty powiedziałbym, że o wiele łatwiej byłoby wypełnić klasy wygenerowane z UML, niż zawracać sobie głowę np. ExecutableUML. Z drugiej strony, dla ExecutableUML potrzebujesz znacznej wiedzy informatycznej, więc nie możesz liczyć na to, że menedżer samodzielnie ją stworzy. Teoretycznie po prostu łączyłby gotowe bloki (klasy), ale tak naprawdę „klej” powoduje problemy.

Przydatność MDE jest również ograniczona do systemów z dużą ilością ponownego wykorzystania komponentów.

MBSE - inżynieria oprogramowania oparta na modelu jest bardziej trafnym terminem.

Stawiając problem różnych narzędzi, które są punktowymi rozwiązaniami, MBSE wymaga innego przepływu pracy w projekcie. DSML (język modelowania specyficzny dla domeny) musi znajdować się na poziomie abstrakcji wymaganym do skutecznego komunikowania wymagań do przeglądu z interesariuszami. Następnie musisz przekształcić model poprzez coraz wyższe poziomy udoskonalenia, aby ostatecznie wygenerować kod.

Gdy proces przetwarzania i generowania DSML jest w pełni i poprawnie zaimplementowany, generowanie artefaktów jest bardzo tanie. Ale dopóki nie osiągniesz etapu debugowania narzędzi, jest to bardzo bolesne.

Większość historii sukcesu MDD dotyczy inżynierii linii produktów (PLE), w której szereg podobnych produktów jest generowanych przy użyciu sprawdzonych narzędzi. Oczywiście wiele generatorów kodu Java to naprawdę uproszczone wersje MDD. Trochę XML i wygenerowany kod.

Napisałeś:

Wiem też, że istnieje wiele problemów ... projekty, które po prostu nie są odpowiednie dla rozwoju opartego na modelu (niewystarczająca ilość powtórzeń)

Jeśli kod jest powtarzalny, oznacza to, że wybrałeś zły język programowania lub źle go używasz. Przy lepszych językach nie ma potrzeby powtarzania. Rozważ bibliotekę Ruby Active Record. Tabele bazy danych są tworzone przez pisanie migracji. Nie ma potrzeby powtarzania definicji schematu w żadnym innym miejscu. Nie musisz definiować klasy z elementami danych odpowiadającymi kolumnom tabeli. Pojedynczy wiersz kodu łączy klasę z tabelą.

Uważam, że rozwój oparty na modelu jest złożonym i nieefektywnym obejściem słabych języków programowania.