Gaphor 2.8.0

Szerszám

Megjelent a Gaphor nevű, nyílt forráskódú, multiplatformos modellező eszköz 2.8.0-s verziója, diagram típus, magnet tool, sablon támogatással, illetve rengeteg hibajavítással.

Az új verzió a következő új funkciókat és hibajavításokat tartalmazza:

  • UML, SysML, RAAML sablonokból is lehet már modell-t indítani
  • Fejlettebb copy/paste támogatás: eddig csak egy link jött létre, most már a deep copy-t is támogatják
  • Törlés támogatása a fa nézetben: eddig csak a diagramon lehetett törölni, most már a fa nézetben is 
  • Diagram típusok támogatása: az általános diagram helyett specifikus diagramokat (pl. activity, use case) is létre lehet hozni
  • Magnet tool: az eszközzel az elemek közötti távolságot lehet nagyon szépen állítani
  • Újraírt kód generátor: a régi kódgenerátor le lett cserélve egy teljesen újra, reményeink szerint ez már karbantarthatóbb lesz.
  • Nyelvi frissítések, köztük magyar nyelvi fordítások frissítése

Release Notes elérhető itt. Letölteni innen.

( LCoder | 2022. 01. 16., v – 10:10 )

Elsõ ránézésre nem tûnik vészesen rossznak, bár szerintem ezeknek a cuccoknak az ideje úgy 10 éve kicsit lejárt. Nem tudom mennyire csinál még bárki UML diagramot az agilis módszertanok korában.

Valóban nem túl elterjedt, mivel minden jöttment rendszert tervez meg programoz, az UML pedig bonyolult (még ha nem is lenne nehéz olvasni, írni annál inkább), egy passzoló módszertan kell hozzá (RUP, Crystal vagy ICONIX pl.), az agilisben a tervezési módszertan max odáig tart, hogy UX Design, de hogy az melyik módszertannal azt hagyjuk.

Mindez azonban a kisebbik baj.

Néha hasznos lenne egyes projekteken, ha lenne EA vagy RR licensz (Enterprise Architect, Rational Rose), mert b.szottnagy modellekkel dolgozunk, és konzisztensen kell tartani. A tapasztalat az, hogy még a legnagyobb beszállítók (T-Systems, 4iG, Delta, soroljam?) is b.sznak megvenni a licenszet, ügyféloldalon én meg hiába pampogok, hogy kéne, ezt hozza a fejlesztő majd a sokpénzből (nemhozza), ne a fizura és szendvicsekre szánt büdzséből menjen. 
 

De ilyenkor gyakorlatilag mindig kollaboráció is kell, és enterprise policy-k vannak, azaz nem az a truváj, hogy van egy standalone GTK app, ami képes megnyitni valami fájlt, mert a fele nem tudja, a másik nem akarja felrakni, hanem egy webes felület kéne, amire különböző jogosultságokkal kapnak az egyes userek (a projektet aláíró főnökök, a BA-kkal veszekedő kliensoldali domain szakértők, a fejlesztők, akiknek a bőrére megy, és persze a BA-k/UX-esek, akik a modelleket összerakják 0-ról).

A fiatalok nyilván ilyeneknek a “visio” és “photoshop” szintű változatain vannak, azaz figma/figjam, lucidchart/lucidspark, drawio, miro - ezek mind online, webes platformok.

tök szép hogy van egy open source desktop alkalmazás erre, csak nem igazán látszik, mire.

Hú, ezt most teljesen átérzem. Van ez az agilis őrület, amit a fejlesztők se nem akarnak úgy valójában, csinálni se tudják normálisan, de cserébe 2 évet vannak max egy cégnél, aminek az az eredménye, hogy teljesen elveszik a cél (az, amit meg kellett volna csinálni) és lesz egy rakás izé (ezt a fejlesztők forráskódnak hívják, én általában gányolásnak) ami valamit/valahogy csinál. Aztán jönnek az új emberek, és próbálják onnan folytatni, ahol PHPPistike meg JávaJóska abbahagyta. Követelmény, use case, tracing, semmi nincs, és nem értik, hogy miért lassul be az egész projekt, és a végén dől össze mint a kártyavár.

Az egyébként külön érdekesség, hogy lehet agilisan modellezni, már 15 éve írtak róla könyveket, de valahogy ez sem ment át a népnek.

Az általad említett eszközök (figma, drawio, miro, stb.) nem modellező, hanem rajz eszközök, ez az, amit nem igazán képesek se a fejlesztők, se a UI/UX-es emberek megérteni. Pont a lényeges: model validáció, transzformáció, execution, projekt egyben tartása funkciót nem tudják ellátni.

A fillérb.ást sosem értettem, egy ilyen termék fullos licenszszel nagyjából 2-3 napi bérből kijön, és egy megfelelő termékkel nagyon jól és hatékonyan lehet dolgozni.

Visual Paradigm egyébként ilyen szempontból elég jópofa, én otthoni projektekre szoktam használni, alapvetően elég korrekt, kis projektre szerintem rendben van. A cégnél MagicDraw/SysML-t használunk, az tud nagy projekteket is egyben kezelni (amikor egy éve néztem, akkor tartottunk 600 ezer model elemnél, és 3000 diagramnál).

A Gaphor célja alapvetően egy UML/SysML/stb. open source modellező (nem rajzoló) alkalmazás, amely kényelmesen használható, jelenlegi állapotában elsősorban kisebb projektekre. A teljes UML megvalósítást valószínűleg nem mostanában fogjuk megugrani (tekintve hogy van 800 oldal az UML specifikáció) viszont már most használható, egy egyetemi feladathoz már megfelelő.

Ha ismered a többi open source terméket, akkor tudod, hogy azok mennyire kényelmetlenek, nehézkesek, legyenek modellezésileg bármennyire korrektek (Eclipse Papyrus és társai...)

Közbeszben elvileg van use case meg tracking, csak oda kell adnod ugye az elején a fejlesztőcsapatnak, aki kitisztázza. A harc ott van, hogy előtte is legyen valami rendszered, mert a közbeszt ugye "akárki" megnyerheti, neked meg már eleve egy konzisztens követelményrendszerre kell azt kiírnod lehetőleg. Namost a domain expert az nem random van kiválasztva, de nem az a kiválasztási szempont, hogy szeresse az open source UML modellező eszközöket. 

A miro meg a többi, persze, rajzeszköz, arra jó, hogy felszórd a modell egy diagrammját. Általában kiegészítik mindenféle excelek, meg wiki-rendszerek (confluence, notion, redmine, mi-hol-mi). Rosszabb esetben egy rakás word sharepointon valami sablonban, aztán győzd őket összefésülni. Még rosszabb esetben oda van nyögve a jogszabálylista, "kell egy olyan rendszer ami teljesíti ezeket az EU-s jogszabályokat", és ha van valami a magyar jogalkotásnál is kaotikusabb szövegeket tud eredményezni, azok a mindenféle nemzetközi bizottságok. 

Persze, mondhatod, hogy továbbtolod a felelősséget a fejlesztőre, mert nyilván aláíratsz vele egy papírt, hogy az ő programja be fogja tartani ezt és azt, csak nem mindegy, hogy a fejlesztés első hetén értette meg, mit kell csinálnia, vagy a második UAT-on esik le, és utána próbálja belenyomorítani a 90% kész rendszerbe azt, amit ha már amikor ajánlatot adott tud, akkor mindenkinek egyszerűbb az élete.

De itt azért miro-zok, mert felszórom a Teams meetingen, és mindenki érti. Áthúzom az excelben tartott modelljeimből a megfelelő sorokat, és voilá, post-itek lesznek belőle! utána a színek majd valamit jelenteni fognak, és össze tudjuk őket kötögetni. Hogy nem tudja, mikor használok szaggatott, mikor sima vonalat, mikor van rombusz az egyik végén, mikor van üres háromszög a másikon, nem baj, én tudok modellezni, majd én levezénylem, a lényeg az, hogy kapjak valami olyan anyagot, amit aztán amikor beírunk a műszaki leírásba, nem mondhatja senki hogy azért nem úgy lett mert nem értette, mit akarunk - és ezért UML.

Az egyetemen meg ne tanítsunk UML-t, ha egyszer az iparba kiesik, és ott lesz Béla, a PM, aki közgazdász, de hogy hol adtak neki közgazdasági diplomát az is rejtély, UML viszont tuti nem volt, meg Sanyi, nos Sanyi megbukott matekból, ezért csak a Testnevelési Egyetemre vették fel, utána végigtolt 20 évet mint tesitanár, de már annyira lementek a tanári reálbérek, és a mellékes se volt elég, hogy őszülő halántékkal elment valami fél éves programozó kurzusra, ami amúgy csak 2 hónap elmélet, 4 hónap "cégnél kint töltött gyakorlat", és ott is a Javascript, a Python, meg mi az hogy programozás egyáltalán volt a téma, és felvették mint junior (de egyetlen) frontend, mert 2000 javascript fejlesztő van az országban vele együtt, mellette Rudi a backendes, nos, Rudi a PHP fekete könyvből tanult programozni, ami ugyan 20 éve elavult, de ő még mindig ebből él, szóval ezek az emberek nem fognak neki MagicDraw modelleket mutogatni, és ha van is MagicDraw, max rajzprogramnak használják.

Tanítsunk helyette szemléletet, hogy dinamikus modell és statikus modell, hogy a statikus modell akkor most az invariánsokat ábrázolja, vagy egy pillanatfelvétel csak, stb. Tanulja meg, hogy milyen dolgokat nem keverünk, mi az amit nem találunk ki ex has, és mi az, amit le kell írni egy programozónak, hogy ne fussunk a pénzünk után amikor kiadja a kezéből.

Mert nem lesz körülötte, aki az UML-t lingua franca-ként beszélni fogja. Az UML-re irassa be a cég, mint a Cisco Certified Cisco Guy jellegű dolgokra.

Az inas módszerrel betanított BA/FA/rendszerszervező/rendszertervező generációkról ne is beszéljünk, komolyan, egyesek úgy tanulják, mint Homérosz előtt az irodalmat, az előd elődjének elődje tudta az UML-t (vagy a RUP-ot, vagy a Crystal-t, mindegy), és elmondta, mint a Kalevalát, aztán az illető ebből továbbadta azt, amit ő megértett, meg picit csavart egyet rajt, és így tovább, és a negyedik generáció, aki nyomokban még mindig a SzámAlk rendszerszervezői képzésének 80-as évekbeli kifejezéseit használja, de elvi szinten fogalma nincs róla mit miért csinál, így szoktuk.

Szóval alapvető kibernetikai ismereteket kéne tanítani.

De igen, az eclipse papyrus (meg úgy egyáltalán az egész eclipse univerzum) egy halál, mindig is az volt.

Ebben a világban nekem egy kollaboratív webes szerkesztőprogram kellene, ami mellesleg azt is elmagyarázza a delikvensnek, hogy amúgy hogyan kell, hogyan érdemes modellezni.

Lehet, alapítanom kéne rá egy startupot.

(Bocs a rantért, mindenkit nagyon szeretek, megértek, stb, csak én mondjuk 5 évig készültem modellezni, mert 19 évesen elhittem, hogy ez a mérnök-informatika, hogy itt van egy rakás ember, aki beszél UML-ül, és én csak megcsinálom a fejlesztőknek a modellt, ők pedig lefejlesztik az adott nyelven. Nem ez.)

Tök jó volt amit leírtál, kb. mintha magamat hallgatnám vissza :D

Egyébként pont ezért is kezdtem el a modellezésről blogolni, hogy próbáljuk egy kicsit az elméletet és a gyakorlatot közelíteni egymáshoz: https://www.modeldriven.hu/

Az a vicc, hogy egy ismerős megkért hogy segítsek nekik egy kicsit, és két tökre nem IT-s leányzó volt mint domain expert, 10 perc alatt megbeszéltük a fogalmi modellezést azon a szinten, ahogy nekik kellett, és bár kicsit vezetni kellett a kezüket, de simán ráéreztek, és már ők mondták, hogy oda kell egy számosság, meg azt a rombuszt ott tessék kitölteni, mert úgy lesz az, ahogy mi látjuk a világot.

Szóval lehetne ezt jól is csinálni, csak mint minden más, ezt is iszonyatosan rosszul oktatják.

Alapvetően egyetértek veled. Siralmas amit a projektek dokumentáció szinten előadnak (többnyire a nagy semmit, DB szinten még a foreign key-ek is le vannak hagyva általában, nehogy már ki lehessen találni, hogy mi mivel van összekötve, drótozva, gányolva. Persze nevezéktan sincs, az ellenség megtévesztése végett. Esetleg valami generált semmitmondó javadoc.)
Csakhogy annak idején, kb. húsz évvel ezelőtt mikor megpróbáltam megtanulni és használni az UML-t, az jött le, hogy a gyakorlatban kész katasztrófa. Rengeteg féle ábra, még több jelölés, és az egész mögött akkor semmiféle meta modell nem volt (RR-ben). Nem akartam elhinni, hogy ez az egész ekkora foshalmaz. Szóval nem véletlenül kopott ki. Azóta lehet hogy fejlődött, de pont az említett 800 oldalas specifikáció miatt nem hiszem, hogy több értelme lenne. Persze jobb híján, főleg szemléltetésre, lehet értelmes subset-eket használni belőle.
Plusz van még egy gond a DB-OO mismatch. De ebbe nem akarok belemenni. Én inkább adatbázist tervezek mint class diagramot rajzolok. Pláne hogy a bevett gyakorlat szerint a class-ok POJO-k, és minden logika a service-ekben van. Azaz visszasüllyedtünk a procedurális programozás szintjére. Az nem OO, hogy a service egy objektum. Ez sem véletlen, de hagyjuk.
Az emberekről meg annyit, hogy előfordult hogy elte-s friss diplomás(2019) programozó matematikus nem értette a class diagram-ot. Odaadtam neki az UML distilled könyvet, hogy olvassa el. Másnap látom, vissza van téve a polcra (nem azért mert elolvasta).
A korrekt modellezés viszont egy nehéz téma. Egyszer a főnököm kitalálta, hogy majd a tanácsadók fogják modellezni az adatbázist, tartsak már nekik valami bevezetőt. Lehet hogy nem én vagyok a legjobb tanár, de nagy nehezen a fejükbe vertem mi az a kulcs meg az idegen kulcs, aztán legközelebbre elfelejtették. Közelébe nem jutottak, hogy a tervezett 6 táblás móricka projekttel elboldoguljanak. Pedig IQ volt bőven.
Száz szónak is egy a vége tényleg kellene valami kollaboratív modellező program, de az UML mint "elméleti" alap, szerintem összességében alkalmatlan (bár úgy látszik valakinek mégis sikerült valami használhatót kihozni belőle), és jobbat sem ismerek. Talán ez jutott messzebb: https://en.wikipedia.org/wiki/Object-role_modeling, de kutya nem ismeri, pláne nem használja.
Megmondták nekem annak idején: figyelj, ne rajzolgassá' má' össze vissza, írjuk a kódot! A táblákat meg majd felvesszük ahogy jön!

Az UML 2.X-ben már van normális metamodell. Ha túl sok a diagram típus, akkor nézz rá a SysML-re, amit rendszermodellezéshez használnak, és egészen tip-top össze van rakva. Az UML-ből egy subset-et használ, és azt eléggé konzisztens módon. Lényegében bármi, amit az égen látsz (műhold, repülő, helikopter, stb.) azt SysML-ben modellezték.

Mi a cégnél full model driven dolgozunk, van egy rövid 2 órás képzés ahol megmutatjuk a srácoknak az alapokat, és majd onnan tanulják tovább, nyilván azon a szinten, ahogy nekik kell. Elég sok idő volt összerakni egy működő rendszert, amely egyébként egy agilis környezetben is használható, de egyébként simán megoldható, csak olyan emberek kellenek hozzá, akik már tudnak programozni, de képesek tőle elvonatkoztatni (erről szólna igazából a mérnök-informatikus). Talán a legnagyobb problémánk a megfelelő absztrakciós szint megtalálása volt, de igazából ezt is meg tudtuk ugrani.

Talán az lehet a gond, hogy a régi modellező eszközök igazából nem is modellező, hanem rajzoló eszközök voltak. A mostani eszközök (Enterprise Architect, Visual Paradigm, Cameo MagicDraw) és a régi izék között ég és föld a különbség.

A visszasüllyedtünk a procedurális programozás szintjére. Sírok. De tényleg, mert valóban ez van.

Az UML magában nem sokat ér, olyan, mintha adnának egy szerszámosdobozt, aztán tessék, itt ez a vadiúj audi (elektronika, CAN BUS, apple watch nyitja és Android carshare van benne), szerelgesd - nyilván nem fog menni.

Ami keretbe foglalja, az a RUP, ha lázadni akarsz, akkor az ICONIX vagy a Crystal: ezek a módszertanok, amik elmondják, mikor mit kell rajzolni.

namost egyik se ott kezd, hogy class vagy entity diagram: használati esetek, robustness diagram, szekvenciadiagram, és ebből már kiesnek az osztályok. Utána némi üzleti modellezés még activity diagrammal, és meg is tudod, mit kell leprogramoznod.

Kivéve, hogy a gyakorlatban már a mi időnkben, 2007-ben is minél előbb felületrajzra kellett vinni a dolgot, mert az egységsugarú domain expert semmit nem fog érteni a fentiekből, ha megkérdezed, akkor ez így jo lesz-e. Amiről az UML amúgy egy szót se szól, hogy akkor azt hogy is.

itt jön be amúgy szabályosan a UX design, a saját full külön ábrázolásrendszerével, aminen vannak szintén szabályai (Jesse James Garrett Elements of User Experience, az is kb. 20 éves), sőt, vannak ún. 360-as tooljai, amik értik, hogy ez a user journey ahhoz a perszónadiagramhoz tartozik, és ezt a konkrét dobozt az a userflow fejti ki részleteiben. Persze ezt se fogod a gyakorlatban sokat látni, mert jó szemű gyerekek fognak ülni a Figma előtt, és gondolkoznak, ez hogy nézne ki divatosan.

(hidd el, a garrett-féle information architecture jelöléseket pont annyira értik mint az UML-t)

szóval persze, meg lehet ezt csinálni, csak sokkal bonyolultabb annál, amit a legtöbben felfognak belőle, és a what could possibly go wrong kérdésre néha többmilliárdosak a válaszok.

a legtöbb projekt azért ezek nélkúl is kikecmereg élesbe idővel, én azokon a projekteken szeretek lenni, amik ezek nélkül megdöglenének.

Nyilván nem a class diagrammal kezdem a tervezést. Csak példaképp hoztam elő, mert még azt láttam legtöbbször. Néha még szekvenciát.

Most jöhetne itt egy kirohanás az informatikában megjelenő "megoldásokról". Mert többször előfordult velem, hogy valamivel dolgoznom kellett, és egy kalap szar volt.
Pl. a rational rose, az ejb2, vagy  html3, de mondjuk később a vaadin, vagy az swt. Az engem nem vigasztalt, hogy 10-20 év, és használható lesz. Meg hogy "csak érteni kéne hozzá". Nekem akkor és ott égett a pofám, hogy olyan eszközkészletem van, ami nem jó szinte semmire. De ezen úgysem lehet változtatni, felesleges dühöngeni rajta.

Hogy egy ellenpéldát is mondjak, ott volt nagyon régen a Magic. Még a 90-es évek elején találkoztam vele. A maga korlátozott módján zseniális volt. Egy eszközön belül mindent meg lehetett oldani. Persze sok mindent csak nehezen vagy sehogy. De ha én pénzt akarok keresni, akkor olyan eszközre van szükségem, amivel a rutinfeladatokat (vagy ami már nekem rutin) gyorsan meg lehet oldani.

Manapság ilyen sajnos nincs. A tervezőeszközök és a tényleges megvalósítás nincs összekötve, kézileg kellene szinkronban tartani őket, ami általában elsikkad. De ez megint messzire vezet.

Na de ezért mondjuk, hogy nézz meg egy MagicDraw/Visual Paradigm/Enterprise Architect-et. Nézz meg egy Quarkus-t az EJB-k helyett. Nézz meg egy modern C#-os környezetet egy SWT helyett. Nézz meg egy modern modellező módszertant (ha rendszermodellezés, akkor pl. ott a SysML, de fent is írtak egy csomót), iszonyat mennyiségű anyag, tudás, tapaszalat, és fejlődést történt az elmúlt 10-15 évben, nem szabad leragadni annál, hogy régen mi volt.

Sokáig én is így gondolkodtam, de mostanában már máshogy. Az egyetemen a problémák absztrakcióját tanították meg. Nekem, mint mérnöknek az a feladatom, hogy megtaláljam ezen absztrakciók helyét az ipari alkalmazás során. Ha kell, kísérletezéssel, ha kell oktatással, stb. Ezen gondolkodásmódbeli váltás miatt van most fullos MBSE folyamatunk, agilisan, amelyik ráadásul folyamatosan fejlődik. Mert lehet ezt csinálni, de ebbe bele kell rakni az időt, munkát, kutatást, ki kell szórni az akadémiai tévutakat, és alkalmazni kell az adott helyzetre.

Nyilván, az EJB3-at kiirtottuk, a PHP-nak volt igaza (stateless oszt szevasz… anno sokat cikkeztem róla, hogy a PHP alkalmazásokat a legnagyobb gányból is skálázhatóvá lehet tenni emiatt, hülyének néztek, nem baj).

az én use case-emben a tervezés után a szinkronbantartás már nem kell: azok a DSL-ek, ilyen a mindenféle BPML / BPMN futtató csoda, mint a camunda meg a bonita. Az a bajom velük, hogy ezek grafikus programozási környezetek, nem modellezőeszközök - én a kevés tervező egyike vagyok.

az én use case-em az, hogy valaki, tipikusan az állam, el akar szórni egy rakás pénzt valami nagyra, amit nem teljesen tud, hogy hogyan kell. Ez ugye úgy zajlik (kb. az egész EU-ban és kormányoktól függetlenül), hogy egy szervezet kitalálja, hogy kell neki valami, megkérik, hogy írja össze, pontosan mi kell, és az összeírt anyaggal körbekérdeznek, hogy ki mennyiért vállalja. Aztán lecsippentenek neki a közösből ennyi pénzt, de egy fillérrel se többet (ez a közbeszerzés dióhéjban).

nade amikor össze kell irni, hogy mi kell, azt úgy kell megcsinálni, hogy ne legyenek benne nagy csapdák, mert a pénz az véges lesz, bármit mondunk, szóval össze kell szedni, ki mit akar ettől pontosan a szervezeten belül. Letervezünk egy kis modell rendszert, de a pénz töredékéből, ezen megvitatjuk, hogy pontosan mi is kéne, és utána hívunk valakit, aki megcsinálja az igazit.

a versenyszférában ugye ez a modellezősdi nem nagyon van: ott meg kell csinálni az igazzy rendszernek egy olyan miniváltozatát, amiért pénzt lehet már kérni, csinál értéket, azaz ott day one éles kód kell: megcsinálhatod te egy grafikus programkörnyezetben is, tökmindegy, az a lényeg, hogy a proof of concept, meg az MVP, meg bármi, az egy hús-vér program, amitől igazi üzleti funkciókat várnak.

innentől kezdve ez nem modellezés, ez programozás.

nagyobb cégeknél vannak solution architect-ek meg hasonlók, akik azért előtte lemodellezik, mi kéne, de ekkora cégek nem szerveznek ki Magyarországra ilyen horderejű melót. Szóval itt kb. van az állam, ahol lehet modellezgetni, egy-egy értelmesebb startup, meg értelmes SaaS cég, minden más az programozás.

bármi, ami éles rendszert futtat, és ha átírod, éles rendszer íródik át, az nekem nem modell, az program.