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

19

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ć.

KeesDijk
źródło
21
Jestem prawdziwym zwolennikiem programowania i programowania. Prawie wszystkie z nich są do czegoś przydatne; żaden nie jest najlepszy na wszystko. Nie wierzę, że pytanie „prawdziwie wierzącego” jest konstruktywne według standardów P.SE.
David Thornley,
4
@David Thornley: Dzięki za komentarz, ale nie wiem, czy „prawdziwy wierzący” miał coś wspólnego z byciem konstruktywnym, czy nie. Jestem bardzo zadowolony z odpowiedzi i bardzo mi pomogło. Z mojego punktu widzenia było to bardzo konstruktywne. Uważam również, że wiele odpowiedzi na pytania dotyczące MDD ma wiele zalet.
KeesDijk,
1
@David Thornley dziękuje za komentarz podczas głosowania! Naprawdę doceniam to, gdy ludzie komentują, kiedy głosują.
KeesDijk,
Jak to ujął Martin Fowler ( martinfowler.com/bliki/ModelDrivenSoftwareDevelopment.html ): niewystarczająca obsługa narzędzi ( martinfowler.com/bliki/ProjectionalEditing.html ).
minghua,

Odpowiedzi:

54

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.

użytkownik 281377
źródło
14
Fred Brooks nazwał to „No Silver Bullet”, ale istota twojego argumentu i jego argumenty są identyczne: cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
Adam Crossland
5
KeesDijk: IMO, obsługa powtarzania jest rdzeniem samego programowania. Większość elementów struktury w programowaniu języków, od pętli, rekurencji, funkcji po koncepcje OO itp., Jest stworzona do obsługi jednego rodzaju powtórzeń.
user281377,
3
Fred Brooks ma kilka dokumentów z lat 50. i 60., które jeszcze nie zostały obalone. Sprawdź książkę „Mythical Man Month” (która zawiera także esej „No Silver Bullet”)
Berin Loritsch,
4
1987? Heck, Fred Brooks opublikował książkę w 1975 r., Która nie straciła na znaczeniu ani trafności ( en.wikipedia.org/wiki/The_Mythical_Man-Month ). Nie, nie sądzę, że zasady No Silver Bullet są dziś mniej prawdziwe niż wtedy. Jak to zwięźle ujęło @ammoQ: w tworzeniu oprogramowania występuje pewna złożoność ... „Teraz możesz wypróbować różne podejścia i techniki, ramy, metodologie, ale w większości próbują one po prostu włożyć całą złożoność w jedno szczególne wiadro, które nie znika
Adam Crossland,
4
@KeesDijk: Idea stojąca za „No Silver Bullet” nie będzie wkrótce przestarzała. Brooks dzieli trudności programistyczne na podstawowe i przypadkowe, używając terminów z filozofii. Jego założeniem jest, że istnieje wiele podstawowych trudności w programowaniu, a wszystkie nowe metody, które naprawdę mogą zrobić, to wyeliminowanie przypadkowych trudności. W tym eseju mówi, że najbardziej dramatycznym wydarzeniem było oprogramowanie do pakowania w folię termokurczliwą, które w porównaniu do oprogramowania niestandardowego lub niestandardowego to całe mnóstwo programowania, którego po prostu nie trzeba robić.
David Thornley,
16

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.
bethlakshmi
źródło
Dzięki ! Świetna lista! Muszę się zgodzić, że należy to wziąć pod uwagę, a jeśli popełnisz błąd, koszt niepowodzenia jest rzeczywiście bardzo wysoki. Jedno pytanie: czy masz więcej doświadczenia z narzędziami do tworzenia skrzynek UML w bardziej narzędziach DSL, takich jak MetaEdit?
KeesDijk
@KeesDijk - na pewno UML! Szczególnie Rational Rose, ale także trochę Rational SW Architect.
bethlakshmi
12

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 ”.

Daniel Pryden
źródło
3
Brooks twierdził, że co 30 lat temu?
Paul Nathan
Dzięki za dobrze postawioną odpowiedź. Twój ostatni akapit całkiem dobrze podsumowuje moje uczucia. A kiedy odkryjesz, że „programowanie na wyższym poziomie” może pomóc ci wziąć pod uwagę wiele innych świetnych odpowiedzi na to pytanie.
KeesDijk,
10

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ć.

Berin Loritsch
źródło
Dzięki! Modelowanie! = Programowanie samo w sobie zasługuje na pytanie. Znam wielu ludzi, którzy się nie zgadzają. Lepsze wyniki z TDD i modelem, który opisuje mi funkcję, oznacza, że ​​używany model nie ma odpowiedniego poziomu abstrakcji. Jeśli napiszesz model na poziomie kodu, utracone zostaną wszystkie korzyści. Koszty nie są i już się pojawiają, możesz modelować zaćmienie za darmo, narzędzia MS dsl są bezpłatne, są bezpłatne narzędzia UML, a EA nie jest tak drogie. Szczegóły nadal znajdują się w kodzie, umieszczasz je w ramach, z których może korzystać model, przy drugim generowaniu masz korzyści.
KeesDijk
Myślę, że dla każdego, kto się z tobą zgadza, mogę przynajmniej znaleźć dopasowanie, które zgadza się ze mną w kwestii programowania! = Modelowanie. Programowanie dotyczy abstrakcji, a modelowanie może pomóc w abstrakcji, ale nie zawsze jest to odpowiednie narzędzie do danego zadania.
Berin Loritsch,
Zgoda!
KeesDijk,
7

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)

Homde
źródło
Okej, muszę się zgodzić. Chociaż Microsoft próbuje trochę z pakietem SDK do wizualizacji i modelowania Visual Studio, Archive.msdn.microsoft.com/vsvmsdk nie wypycha.
KeesDijk,
7

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.

Waquo
źródło
W odniesieniu do DDD: Muszę przyznać, że naprawdę lubię DSEL. Śledzę (z daleka) rozwój systemu operacyjnego barrelfish ( barrelfish.org ) i oni stworzyli Filet-o-Fish, który jest narzędziem do tworzenia DSL, a następnie pracują na wyższym poziomie abstrakcji bezpośrednio w kodzie.
Matthieu M.
6
  • 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.

Paul Nathan
źródło
+1 za „Wydaje się, że to gigantyczny kłopot przy bardzo niewielkich korzyściach”.
rreeverb
5

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ć.

Daniel
źródło
Dzięki! kolejna świetna lista. Wierzę, że Refaktoryzacja pracuje nad kilkoma polami, a MetaEdit może debugować model graficzny, ale tak, nie widziałem wielu wspaniałych rzeczy w tym obszarze.
KeesDijk
3

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.

Deckard
źródło
2

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?

oosterwal
źródło
Dzięki ! Uczestniczyłem w CodeGeneration w Cambridge ( codegeneration.net/cg2010 ) i ogólnie panuje zgoda, że ​​świat osadzony jest szczególnie odpowiedni dla MDD. Również holenderska firma Thales ( thalesgroup.com ) robi duże postępy, stosując MDD w systemach radarowych. Modelowana jest ogólna praca systemów, poszczególne bloki konstrukcyjne są kodowane ręcznie dla każdego nowego elementu sprzętu. Dzięki temu wymiana sprzętu jest znacznie szybsza.
KeesDijk
Model nie powinien wiedzieć nic o wzorach projektowych. Masz architekturę oprogramowania referencyjnego, która ma wzorce. Generatory interpretują model i generują do referencyjnej architektury oprogramowania. Gdy trzeba zastosować nowy wzorzec, architektura i generatory są zmieniane.
KeesDijk
@KeesDijk: Kiedy stwierdzasz, że osadzony świat jest szczególnie odpowiedni dla MDD, czy masz na myśli aplikacje na telefony komórkowe lub µController SW w samochodach i sprzęcie AGD.
oosterwal
Monitory pracy serca, systemy radarowe, sprzęt drukarki. Ale spójrz na link do metaedytów i zobacz, co zrobili. Słyszałem tylko o µController SW znalezionym w samochodach i że jest naprawdę skomplikowany, nigdy nie słyszałem o żadnym MDD, ale to, że nie słyszałem o tym, nie jest dobrym miernikiem :)
KeesDijk
Jakiś czas temu koleś z Matlab / Simulink próbował sprzedać nam generator kodu. Skierowany prosto na wbudowane kontrolery. Nie zrobiłem MISRA-C i nie miałem certyfikatu, więc trochę smutno, że mogło się to zmienić. Spójrz, generowało C.
Tim Williscroft
2

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.

Fredy
źródło
2

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.

Juha-Pekka
źródło
Dzięki za wkład. Muszę się zgodzić i nie widzę rozwiązania w najbliższej przyszłości.
KeesDijk
2

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 :-)

UML_GURU
źródło
1

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.

hotpaw2
źródło
1

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.

vartec
źródło
1

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.

CyberFonic
źródło
0

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.

Kevin Cline
źródło
1
Myślę, że mówimy o różnych rodzajach powtórzeń. Mówisz o powtarzaniu w ramach jednego oprogramowania, mówię o budowie wielu podobnych programów, które na przykład mają tę samą architekturę oprogramowania, ale udostępniają inną funkcjonalność. Funkcjonalność jest modelowana i generowana architektura. Dziękuję za odpowiedź.
KeesDijk,
@Kees: co rozumiesz przez „architekturę”? Jeśli jest to kod, mógłbym rozliczyć powtórzenie i po prostu utworzyć architekturę, określając rzeczy charakterystyczne dla każdej instancji. Przy dobrym języku KAŻDE powtórzenie można rozłożyć na czynniki.
Kevin Cline,
Nie ma czegoś takiego, jak dobre lub złe języki programowania, tylko dobrzy lub źli programiści, takie przykłady, które podajesz, mogą być wykonane przy użyciu dowolnego środowiska WWW. Co MDA / MDD / itp. stara się rozwiązać, utrzymując model, aby wygenerowanie kilku komponentów mogło odbywać się automatycznie, takich jak baza danych, kontrolery, widoki, usługi itp. Idealnie model powinien być niezależny od języka i struktury (z uwzględnieniem języków OO), więc każdy model może być eksportowany do Rails, Spring, Zend itp.
Cenobyte321