GoldenLine
Zaloguj się
Bogdan Rokicki

Bogdan Rokicki naturalnie zdrowy
manager systemowy

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Dzień dobry,

Na stronie visual paradigm możemy zobaczyć taki oto napisik:

Build Quality Applications Faster, Better and Cheaper

Co o tym myślicie - czy projektowanie aplikacji, modelowanie a następnie generowanie kodu w tego typu narzędziach rzeczywiście pozwala na sprawniejsze wykonywanie poprawnie działających aplikacji?
Czy rzeczywiście taka metoda jest lepsza od tradycyjnego sposobu gdzie programista tworzy aplikację tylko na podstawie wymagań, często nawet bez dobrego projektu/modelu aplikacji?
liczę na Wasze opinie
dopiero zaczynam wchodzić w temat więc proszę nie traktujcie pytania na które odpowiedź jest oczywista :)
pozdrowienia
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Bogdan R.:
Dzień dobry,

Na stronie visual paradigm możemy zobaczyć taki oto napisik:

Build Quality Applications Faster, Better and Cheaper

Ogólnie uważam, że dobre modele to zawsze szybciej, lepiej i taniej:)

Co do automatycznego generowania kodu to mało o tym słyszę ale bywało że ktos przy mnie mówił że się da i że ok....
Link do wypowiedziLink
Jacek Jakieła

Jacek Jakieła Adiunkt,
Politechnika
Rzeszowska im.
Ignacego
Łukasiewicz...

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Wydaje mi się, że jedyną odpowiedzią jest "zależy od wielu czynników". Jednym z kluczowych czynników jest czas realizacji projektu, rozmiar i złożoność projektowanego systemu i odpowiedzialność jaką bierze projektant za powstały system. W związku z tym stopień formalizacji procesu projektowego, liczba modeli i zastosowane narzędzia mogą się różnić od projektu do projektu. Oczywiście posiadanie dobrych modeli w formie diagramów jest zawsze przydatne, jednak nie zawsze jest na to czas. Istnieją w związku z tym różne podejścia jak np. metodyki zwinne, gdzie ilość dokumentacji i modeli jest zminimalizowana oraz tak zwane podejścia z procesem ciężkim, gdzie istnieje plan formalnych przeglądów i opasłe tomy dokumentacji zawierającej setki diagramów. Oczywiście można zastanowić się nad tym, które etapy muszą być sformalizowane w postaci modeli, a które mogą być zrealizowane mniej formalnie. Oczywiście każdy model, nawet najmniej formalny jest lepszy niż całokowity brak modelu.
Link do wypowiedziLink
Ar W.

Ar W. at

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Modele są opisem systemu z pewnego punktu widzenia. Są budowane po to, aby lepiej zrozumieć system. Są ważne, bo pomaga obrazowo przedstawić, wyspecyfikować, zbudować i udokumentować strukturę architektury systemu. Jednocześnie korzystanie z zunifikowanego języka modelowania usprawniamy komunikację między zespołami. Rozwiązują również wiele innych problemów.

Faktycznie, na podstawie modeli projektowych możemy generować szablony klas, tabel itp. (z tego co się orientuje można również pisać ciała metod, triggery, procedury itp. ). Dobre oprogramowanie powinno również zapewnić synchronizację projektu z kodem.

Modele ważne są nie tylko z punktu widzenia samego wytwarzania oprogramowania ale również jego późniejszego utrzymania i rozbudowy.

Należy pamiętać, że metodyka to jedynie zbiór pewnych zaleceń, notacji które strukturalizują proces wytwarzania oprogramowania. Myślę, że nie zawsze warto trzymać się stricte wybranej metodyki. To jak duży będzie formalizm zależy np. od specyfiki projektu, wymagań klienta itp.
Link do wypowiedziLink
Bogdan Rokicki

Bogdan Rokicki naturalnie zdrowy
manager systemowy

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

:) miałem ogromną nadzieję na jednoznaczną odpowiedź ale jak to bywa w przypadku wielu dziedzin, odpowiedź na moje pytanie zależy od wielu czynników, np:
powagi projektu
sposobu w jaki pracuje organizacja
i zapewne od wielu innych.

i pewnie trudno jest odpowiedzieć czy tańsze, lepsze, szybsze będzie wykonanie aplikacji wykonując ją generatorem kodu na podstawie modelu/projektu UMLowego czy też przez posadzenie obok siebie programisty i uzytkownika na czas tworzenia aplikacji oraz ograniczenia dokumentacji do niezbędnego minimum.

pierwsza metoda wydaje się w mniejszy sposób angażować twórcę systemu oraz użytkownika oraz wydaje się dawać większą elastyczność jeżeli dojdzie do późniejszych modyfikacji powstałego programu natomiast druga metoda w pewnych przypadkach będzie szybsza gdyż prawie od razu zabieramy się do tworzenia aplikacji.
a wybór odpowiedniej drogi zależy od możliwości jakie mamy i zasobów przeznaczonych na projekt.

wrócę jeszcze do wątku - że się da automatycznie wygenerować kod programu na podstawie projektu - czy potrzebna do tego jest wiedza programistyczna z danego języka programowania czy te cudowne automaty zrobią naprawdę wszystko za programistę?
Link do wypowiedziLink
Paweł Kornacki

Paweł Kornacki Web Developer -
Graphic Designer -
Front-End Developer

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Po pierwsze - nie ma co się łudzić - cudowne automaty nie zrobią wszystkiego za programistę. Tak jak przy wielu innych dziedzinach nic nie zastąpi myślenia. A pamietajmy, że proces wytwarzania oprogramowania to proces niesamowicie twórczy. Oczywiście możemy i powinnniśmy automatyzować pewne procesy - generatory kodu umożliwiają np. stworzyć, spójny, zwięzły i bardziej przejrzysty szkielet kodu. Ale nie wierze, że uda się tak zautomatyzować proces tworzenia oprogramowania ażeby wyeliminować z tego procesu programistów.

Po drugie - jeśli mówimy o poważnym podejściu do zagadnienia wytwarzania oprogramowania - to nie zapominajmy że tworzenie systemu to nie tylko programista - klient. To również analitycy biznesowi, analitycy systemowi, projektanci czy architekci. Niestety w naszej krajowej rzeczywistości zbyt czesto wszystkie te role skupiają sie na jednym czlowieku - programiscie.
Link do wypowiedziLink
Paweł Kornacki

Paweł Kornacki Web Developer -
Graphic Designer -
Front-End Developer

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Dodam jeszcze jedno - żeby stworzyć poprawny projekt niskopoziomowy (zwany często perpesktywą wewnętrzną) niezbędna jest wiedza programistyczna. Projektant nie jest w stanie stworzyć diagramu klas nie mając pojęcia czym jest klasa.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Paweł K.:
Dodam jeszcze jedno - żeby stworzyć poprawny projekt niskopoziomowy (zwany często perpesktywą wewnętrzną) niezbędna jest wiedza programistyczna. Projektant nie jest w stanie stworzyć diagramu klas nie mając pojęcia czym jest klasa.

Już w średnio rozbudowanych systemach (obiektowych) dominującym wzorcem jest model dziedziny. Nie wyobrażam sobie jak można nazwać kogoś nie mającego pojęcia o analizie obiektowej analitykiem lub projektantem...

Co do automatyzacji i etapu analizy przytoczę słowa kolegi "nabywcy" usług IT mającego za sobą już kilka wdrożeń: "każdy oszczędzony dzień analityka to tydzień dodatkowej pracy programisty". Mowa o analityku rozumiejącego co to klasa :).

Osobiście też nie wierzę w możliwość wyeliminowania z jakiejkolwiek twórczej pracy człowieka, mam jednak wiare w to, że dobry CASE pomaga panować na złożonością projektu.
Link do wypowiedziLink
Paweł Kornacki

Paweł Kornacki Web Developer -
Graphic Designer -
Front-End Developer

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

[author]Jarosław
Link do wypowiedziLink
Piotr Aftewicz

Piotr Aftewicz Analityk biznesowy

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Witam wszystkich.
Może na początek mojej obecności w tej grupie podzielę się jednym z moich ulubionych cytatów odnośnie modelowania i tego tematu.

"One of the things that tools can do is to help bad designers create ghastly designs much more quickly than they ever could in the past."
Grady Booch.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Piotr Aftewicz:
Witam wszystkich.
Może na początek mojej obecności w tej grupie podzielę się jednym z moich ulubionych cytatów odnośnie modelowania i tego tematu.

"One of the things that tools can do is to help bad designers create ghastly designs much more quickly than they ever could in the past."
Grady Booch.

Ano dlatego na jednej z list napisałem, że jest poważna różnica pomiędzy tworzeniem diagramów a modelowaniem ;) oraz że narzędzia CASE automatyzują pewne rutynowe prace ale absolutnie nie pomagają modelować, analizować a w szczególności nie wyręczają w myśleniu (szczegółnie tym twórczym).

Tak więc narzędzia UML (tu należy chyba myślec właśnie o systemach CASE) pomagają pewne rzeczy wykonac szybciej i taniej ale nie sądzy by pomagały robić to lepiej. Jak ktoś nie potrafi czegoś ołówkiem na papierze to żadne narzędzie mu w tym nie pomoże.
Link do wypowiedziLink

konto usunięte

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Dołączam się do głosów przedmówców. Wg. mnie jest kilka dobrych rad, którymi powinno się kierować przy używaniu narzędzi typu CASE.

1. Żadne narzędzie nie zastąpi myślenia.
Widziałem wiele przypadków, gdy ludzie zachłyśnięci niesamowitymi możliwościami narzędzi tworzyli modele, których nie dało się zrozumieć , już nie mówiąc o implementacji.

2. Narzędzia należy używać rozsądnie, czyli nie za wszelką cenę, tylko dlatego że jest takie narzędzie kupione za ciężkie pieniądze i jego używanie jest trendy lub wymuszają standardy.
Czasami lepiej używać tego narzędzia do dokumentacji rozwiązania niż jego szczegółowego modelowania. Szczególnie przydatna opcja Reverse Engineering. :) Moim zdaniem lepiej jest coś zamodelować bardziej ogólnie i doprecyzować na etapie implementacji, niż stworzyć model, który nie da sie wcielić w życie.

3. Nie można zamodelowac ze szczegółami całego systemu, rozwiązania od razu, a nie raz widziałem takie zakusy - kończyło sie jak zwykle - modelami, które szły do kosza.

4. Automatyczna generacja kodu: jeśli ktoś mysli, że zastapi to programowanie, to grubo sie myli. W zasadzie nadaje sie wyłącznie do generacji szablonów klas i interfejów. Po generacji i tak trzeba sprawdzić czy kod się kompiluje i czy dobrze narzędzie wykonalo swoja pracę, więc czasami wolę interfejsy napisać ręcznie, bo i tak prawie zawsze muszę poprawiać po automatach. :)

5. Narzędzia typu CASE świetnie sie nadają nie tylko do modelowania ale rowniez jako repozytorium wiedzy, pod warunkiem, ze mamy mozliwośc efektywnego przeszukiwania ich bazy.

Reasumując narzędzia UML są jak każde inne - młotkiem można wbić gwóźdź ale i rozwalić palec. Czasami zamiast pomoc, moga one sprawić, że budowa rozwiązania będzie wolniejsza i droższa, a samo rozwiązanie gorsze.

pozdr. edi
Link do wypowiedziLink
Grzegorz M.

Grzegorz M. szef projektu,
Macrologic S.A.

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Witam wszystkich,

dorzucę i swoje słówko.

Przy obecnych możliwościach technologicznych programowanie bez projektu to jak wymachiwanie bombą atomową.

Przy mozliwościach technologicznych z lat na przyklad 80-tych - było to zaledwie wymachiwanie siekierą. Wtedy całość projektu, który można było zakodować w ówczesnych narzędziach, mieściła się w cache'u mózgu przecietnego programisty.

Jestem przekonany, że przy przedsięwzięcich bardziej skomplikowanych niż oprogramowanie spisu znajomych do wysyłania kartek świątecznych, konieczne jest użycie technik porządkujących opisywanie rzeczywistości. W przeciwnym razie nasza praca przypominać będzie rozpoczynanie budowy mostu od rozrobienia kupki zaprawy na brzegu rzeki.

Widziałem wiele potworków, utworzonych przez "wydajnych programistów" (jak mówili o nich ich przełożeni), a będących dowodami na to, że ich twórcy nie zhańbili się nawet uzyciem choćby archaicznych technik ELH. Potworków, podczas których powstawania żaden dorosły człowiek nawet nie zerknął na model danych, bo takiego modelu w ogóle nie było. "Dodawano pola..." :-) :-) :-0 :-} :-( :-( :-(

Zaoszczędzono na technikach. Na nauce technik, narzędzi, na zakupie narzędzi, zaoszczędzono czas, który byłby zużyty na posłużenie się narzędziami. No i mamy systemy, których zrozpaczony operator zgaduje, w jakiej fazie przetwarzania znajduje się jakiś obiekt (dokument czy inny twór), z których wydobycie informacji do tak dzisiaj modnej analizy wielowymiarowej wymaga katorżniczego rzeźbienia w kodzie. Mamy systemy rozliczeniowe z kredytami bez identyfikatorów (!!!!!!), rejestry dokumentów, które operatorzy identyfikują według na przykład daty, imienia założyciela, kwoty... a jeśli to się powtarza, to na przykład godziny utworzenia.

No ale było TANIO.

Sam raz usłyszałem: "tylko nie zrób tego za dobrze".

Niestety, powyższe podejście jest powszechne w naszej, polskiej rzeczywistości. Rzeczywistości pełnej bezkompromisowego wyścigu przede wszystkim czasowego, cenowego, a rzadko jakościowego.

Podoba mi się hasło "Taniej, szybciej, lepiej", o ile tylko dążąc do taniości, szybkości i jakości zachowamy RÓWNOWAGĘ. I nie poświęcimy jakości dla taniości i szybkości.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jak narzędzia UML mogą pomóc w lepszym, szybszym i...

Jestem pod wrażeniem :), poważnie. Dlaczego? Bo mam dokałdnei takie same doświadczenia.

Nie raz dyskutowałem z tak zwanymi "wyżartymi" programistami, pytałem o projekt, model danych, podział na komponenty... mówili mi że za dużo czytam i mam sp.....ć (to usłyszałem swego czasu w naprawdę w poważnej firmie) ciekawe, że ich twory wyglądały właśnie tak jak opisałeś...

Teraz zanim zaczne współprace z jakimkolwiek programista pytam czy przyda mu sie model danych lub dziedziny systemu. Jak mówi, ze nie bo to niepotrzebna robota i strata czasu, że sam to zrobi podczas pisania to "uciekam".
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Narzędzia UML/ Sys-ML




Wyślij zaproszenie do
Anuluj