19 Grudnia opublikowano nową wersję pakietu Visual Paradigm: 14.0, w stosunku do poprzednie (13.2) wiele ulepszeń i kilka nowych “zabawek”. Nie będę opisywał wszystkich (szczegóły na stronie producenta, link na końcu artykułu).
Na początek ważna uwaga i wyjaśnienie: korzystanie z narzędzi CASE z równoległym tworzeniem dokumentów “na boku”, z użyciem pakietów biurowych jest kompletnie pozbawionym sensu podejściem: tracimy 3/4 wartości tych narzędzi, jaką jest generowanie ad-hoc wysokiej jakości, spójnej, kompletnej i niesprzecznej dokumentacji. Modele tworzymy z kilku powodów: zapisujemy wyniki analizy, projektujemy rozwiązania, testujemy je, ale przede wszystkim przekazujemy tę wiedzę, czyli tworzymy dokumenty opisujące efekty naszej pracy. Główną pracą jaką wykonuje analityk jest analiza i projektowanie. Jeżeli więc tworzenie dokumentów zajmuje mu więcej niż umowne 20%, staje się po prostu nieefektywny czyli bardzo kosztowny. Często spotykam się z sytuacją gdy tak na prawdę 90% czasu analizy zajmuje spotykanie się i mozolne tworzenie dokumentów, 10% to faktyczna analityczna i twórcza praca. To mega marnotrawstwo (lub kompletny brak szacunku dla zamawiającego). Dlatego generowanie wysokiej jakości merytorycznej dokumentacji (a nie tylko ślicznie sformatowanej) jest kluczowym elementem dobrego pakietu CASE (poza oczywiście zestawem notacji i ich zgodnością ze standardami). Tu tylko wspomnę, że od wielu lat nie używam edytorów tekstów do tworzenia produktów swojej pracy (w tym obszarze). (more…)
Dzisiaj niespodzianka pod choinkę 🙂 czyli VP wersja 12.00. Zaczynam prace a tu taki email:
Dear Jarek Zelinski,
We are thrilled to introduce to you the brand new Visual Paradigm – Visual Paradigm 12.0 with a new user interface and suite of new tools which improves your modeling efficiency. One of the highlighted improvements is the increase in diagram editing space, which means you have more room for editing your design and can be more focused on modeling. Click here to watch the introduction video of the Sleek UI, the official name of the new look and feel.
Besides the change of user interface, there are tons of new features and enhancements as well. Please visit our What’s New page for more details on both the new user interface and new features.
Hope you enjoy the new Visual Paradigm. Feel free to let us know if you have any questions or suggestions. Wish you all a Merry Christmas in advance.
Sincerely,
Visual Paradigm
Pierwsze co rzuca się w oczy po uruchomieniu nowej wersji to nowy interfejs użytkownika. Wygodniejszy, ukrywa na bieżące niepotrzebne elementy menu, więcej miejsca na ekranie ale z tym, widzę muszę się oswoić. Tak to teraz wy
Wśród wielu przydatnych rzeczy pojawiły się:
poszerzony panel edycyjny,
wyszukiwarka diagramów i obiektów na nich,
poszerzony panel przeglądu modeli,
bardzo przydatne: ostatnie moje zmiany i ostatnie zmiany jakie wprowadził zespól współpracujący,
generator dokumentacji interfejsów REST,
bogate zarządzanie user story (dla full zwinnych pełny pakiet narzędzi wraz z zarządzaniem sprintami itp.),
dodawanie diagramów podrzędnych do każdego elementu “zwinnego” toku projektu (tego akurat brakowało a teraz jest: agile zorientowane na modele),
łączenie user story z przypadkami użycia i całym projektem, śledzenie postępów implementacji,
tworzenie “story boardów”, bardzo przydatne w kontaktach z klientem,
bardzo pomocna możliwość robienia zrzutów ekranów podczas tworzenia mock-up’ów, szczególnie gdy dotyczy to istniejącej aplikacji,
w modelach BPMN wsparcie dla symulacji modelu zawierających pod-procesy (wykonywane są pod-procesy w toku symulacji).
I have an assignment for developing a hotel reservation system! One of tasks is to develop UML class diagram! However, in the task description it is written “Class diagram should represent your database”. I am a bit confused about the rules, notations and etc… because I can’t find any official UML class diagrams specifically for databases! Could you help me please? (UML class diagram for database).
i regularnie piszę: używanie diagramu klas jako reprezentacji [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca UML) mówiących o modelowaniu relacyjnych modeli danych diagramami klas notacji UML. Do modelowania relacyjnego modelu danych używamy notacji ERD (ang. Entity Relationship Diagram, diagram związków encji). Niestety takie wzmianki – jak stosować diagram klas UML do modelowania RDBMS – można znaleźć w książkach uznawanych za wartościowe (okładka jednej z nich po prawej), można usłyszeć na wielu szkoleniach dotyczących notacji UML, a nawet usłyszeć o tym można – modelowanie danych w UML – z ust niejednego wykładowcy na uczelniach wyższych technicznych (co jest smutne, mam na półce podręcznik akademicki z opisem stosowania kluczy głównych i obcych na diagramach klas w modelowaniu danych).
Przy okazji. Książkę tę [zotpressInText item=”{5085975:AFU3SXIM}”], mam na półce, przeczytałem, i mam obawy przez jej polecaniem, mimo, że przez wielu jest uważana niemalże za biblię analityka biznesowego (ale jako ogólny opis modelu kompetencyjnego analityka można ją uznać).
Krótkie przypomnienie pojęć (sł. j. polskiego):
dane 1. ?fakty, liczby, na których można się oprzeć w wywodach? 2. ?informacje przetwarzane przez komputer?
obiekt 1. ?przedmiot, który można zobaczyć lub dotknąć? 2. ?rzecz abstrakcyjna, np. cecha lub pojęcie? 3. ?coś, czego dotyczą czyjeś działania, zainteresowania lub uczucia? 4. ?budynek lub zespół budynków; też: urządzenia terenowe?
Generalnie dane to zapis faktów (informacje, wiedza), obiekt to abstrakcyjny bądź rzeczywisty byt, mający określone cechy i reagujący na bodźce. To dwa różne światy. Tak zwany paradygmat obiektowy to modelowanie (traktowanie) systemu jako zbioru współpracujących w określonym celu obiektów. Model danych zaś, to opis organizacji danych w ich repozytorium. Model obiektowy to struktura współpracujących obiektów mających określone zachowania. Nie tylko na uczelniach nadal pokutuje “stare”: Algorytmy plus struktury danych równa się programy, ale to definicja jeszcze z czasów przetwarzania wsadowego. Dzisiaj mamy wokół siebie współdziałające komputery, smartfony, linie produkcyjne, a nawet sprzęt AGD, gdzie tu są te oddzielne “struktury danych i algorytmy”? Nie ma, są współdziałające obiekty. Owszem, każdy obiekt operuje określonymi danymi, ale są one “w środku” i nie są “jedną wielką bazą danych” [zotpressInText item=”{5085975:JMUUJ5TN}”].
Notacja UML bazuje na obiektowym paradygmacie, diagram klas tej notacji służy do modelowania obiektowej struktury dowolnego systemu (obiekt to nazwa, atrybuty i operacje jakie wykonuje on na żądanie). Nie ma tu mowy o żadnych danych, co najwyżej obiekty cechują się określonymi atrybutami, te jednak nie są współdzielone a zamknięte w tych obiektach, bo to ich “prywatne” cechy. Gdyby te atrybuty były współdzielone, system taki byłby niemodyfikowalny, niepodzielny i niepodatny na zmiany, na wymianę w nim jednego obiektu na inny (co obserwujemy nadal w systemach zintegrowanych metodą współdzielenia danych, tak jest skonstruowane wiele systemów ERP!).
Owszem, na poziomie technologicznym nadal korzystamy z plików na dyskach i baz danych (nie zawsze relacyjnych) ale to co innego, korzystamy z nich do zapisu (utrwalania) danych/treści, utrwalania informacji (danych). Na styku tych dwóch światów korzystamy (jeżeli jest taka konieczność) z mapowania modelu obiektowego na utrwalane dane i wtedy korzystamy z notacji UML do modelowania obiektowej architektury aplikacji i np. z notacji ERD do modelowania np. relacyjnej struktury danych, łącznie nazywa się mapowanie obiektowo-relacyjne (ORM). Tak więc modelowanie danych notacją UML to pogwałcenie zasad stosowania tej notacji i niezrozumienie samej notacji, pojęcia obiekt i klasa. Skąd się biorą takie pomysły? Bardzo wielu ludzi używa notacji tylko w charakterze bibliotek obrazków/symboli, zaś notacja to system pojęciowy, a to nie jest to samo.
A przy okazji: tworzenie takich modeli w notacji UML, jako projekty modelu dziedziny systemu (obiektowego), to klasyczny antywzorzec projektowy o nazwie anemiczny model dziedziny:
Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji – znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób. (https://pl.wikipedia.org/wiki/Antywzorzec_projektowy)
