Tervezőeszközök

A szoftvereket a megvalósításuk előtt érdemes megtervezni. Tapasztalatom szerint a tervezési hiányosságok keményen megbosszulják magukat, azon nem érdemes spórolni. (Ez egyébként igaz az élet más területeire is.) Ebben a fejezetben néhány tervezőeszközt mutatok be.

UML

Az UML a Unified Modelling Language rövidítése. Ez talán a legelterjedtebb modellező nyelv. Ennek segítségével diagramokat tudunk készíteni. A diagram fajtákat két fő kategóriába sorolhatjuk:

  • Strukturális diagramok (structural diagram): ezek statikus jellegű diagramok, amelyek a rendszer adott állapotát illusztrálják.
    • Osztálydiagram (class diagram): segítségével az objektumorientált nyelvek osztályait, azok tulajdonságait, egymáshoz való viszonyait tudjuk ábrázolni. Az egyik leggyakoribb diagram típus.
    • Komponensdiagram (component diagram): a rendszer fizikai komponenseit, azok kapcsolatait ábrázolja. Tapasztalatom szerint ez nem túl gyakori.
    • Összetett struktúradiagram (composite structure diagram): az osztályok belső szerkezetét mutatja. Ritka diagramtípus, "élesben" még sohasem találkoztam vele.
    • Telepítési diagram (deployment diagram): azt mutatja meg, hogy melyik hardveren melyik szoftverkomponens lesz (van) telepítve. Viszonylag gyakori.
    • Objektumdiagram: ez egy dinamikus állapotot tükröz, amikor létrejöttek az objektum példányok, és azok egymáshoz való viszonyát mutatja be. Ritkán lehet vele találkozni.
    • Csomagdiagram: azt mutatja meg, hogy melyik osztály melyik csomagban van. A valóságban nincs éles határ az osztály- és csomagdiagram között; ha az osztálydiagramon már elég sok osztály van, akkor azt csomagokba szokás szedni. Az UML eszközök többnyire ezt lehetővé teszik.
  • Viselkedési diagramok (behavior diagram): ezek dinamikus jellegű diagramok, amelyek a rendszerben végbemenő folyamatokat illusztrálják.
    • Aktivitásdiagram (activity diagram): ezek a munkafolyamatot modellezik. Leginkább azokra a diagramokra emlékeztet, amelyeket évtizedekkel ezelőtt használtak az informatikakönyvekben a program folyamatának bemutatásához (aminek egyébként semmi értelme nem volt, mert egy jó olvasható, pár soros programot bonyolítottak el vele). Nem túl gyakori diagramtípus.
    • Állapotgép diagram (state machine diagram): ha egy rendszernek vannak jól meghatározott állapotai és átmenetei, akkor ezt érdemes használni. Az olyan jellegű szoftverek megértését nagyban segíti.
    • Használati eset diagram (use case diagram): a program fő funkcióit mutatja be a végfelhasználó szempontjából. A felhasználót egy pálcika ember szimbolizálja; ez igen jellegzetes eleme ezeknek a diagramoknak. Ez az egyik leggyakoribb, és a tervezés kezdeténél leghasznosabb diagramtípus.
    • Interakciós diagramok (interaction diagram): a rendszerelemek közötti kommunikációt mutatják be. A következők tartoznak ide:
      • Szekvencia diagram (sequence diagram): ezzel gyakorlatilag a hívási láncot lehet illusztrálni. A diagramban az egyes szereplők egymás mellett vannak, és azok idővonalai függőlegesek, egymással párhuzamosak. A hívásokat vízszintes nyilak illusztrálják, és az adott időszakban aktív elem idővonalát vastagabban rajzolják. Igen gyakori diagram típus.
      • Kommunikációs diagram: az objektumok közötti kommunikációt illusztrálja. Az objektumok szimbóluma egy-egy téglalap, köztük nyilak találhatóak, a nyilakon pedig általában van egy sorszám és egy felirat. Korábban ezt kollaborációs diagramnak hívták, viszont mivel az negatív érzéseket vált ki, egyrészt átnevezték, másrészt egyszerűsítettek is rajta. Közepesen elterjedt diagram típus. Lehet hasznos, de túl is komplikálhatja a tervet.
      • Interakció áttekintő diagram (interaction overview diagram): az aktivitás diagramra hasonlít, viszont itt egy-egy komponensen belül lehetnek interakciós diagramok, pl. egy rövid szekvencia. Az UML 2.0-ban jelent meg. Még sohasem találkoztam ilyennel a valóságban, de ígéretes.
      • Időzítő diagram (timing diagram): segítségével precíz, akár ezredmásodpercre lebontott időzítést lehet illusztrálni. Ehhez hasonló diagramokkal gyakran lehet találkozni, leginkább a hardverközeli programozásban (pl. Arduino), de úgy mint UML 2.0 diagram, még számomra is újdonság.

Ezeket a diagramokat alapvetően két filozófiai megközelítéssel lehet használni:

  • Részletesen, precízen ki lehet dolgozni a rendszer majdani viselkedését. Egyes eszközök kódot is generálnak belőle.
  • A rendszer magas szintű áttekintését ehet vele illusztrálni, a legtöbb esetben kihagyva a részleteket.

Személy szerint ez utóbbit tartom hasznosabbnak, több okból is:

  • Sokkal gyorsabban elkészíthető. (Nem kell túlzottan törődnünk a precizitással, szabadabban szárnyalhatnak a gondolataink.)
  • Kisebb módosulás esetén nem feltétlenül kell a terveket is módosítani. (Ha az első megközelítést alkalmazzuk, akkor minden apró változtatás maga után vonzza a tervek módosításait is. Ehhez meg kell találnunk az eredeti szoftvert, amivel készült, adott esetben meg kell vele ismerkedünk, esetleg még licenszt is szereznünk kell.)
  • Sokkal áttekinthetőbb. (A részleteiben kidolgozott diagram általában egy nagy áttekinthetetlen katyvasz.)
  • Rosszak a tapasztalataim a generált kódokkal, azok karbantarthatóságával. (Elkerülhetetlen, hogy utólag bele kelljen írni, és ez problémát jelent az újragenerálásnál.)

Lent látni fogunk UML modellező eszközöket; egy összefoglaló lista a Wikipédián ezen az oldalon található: https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools.

Elmetérkép

Az elmetérkép (angolul mindmap) egy hierarchikusan, fa szerkezetben felépített diagram, melynek mindig van pontosan egy központi eleme, ahhoz kapcsolódnak fogalmak, majd azokat is tovább lehet bontani. Az elmetérképeken általában lehet színezni úgy az elemeket mind a kapcsolatokat, és ennek segítségével jól áttekinthető ábrákat lehet készíteni.

Adatmodellezés

Segítségével SQL táblákat, azok oszlopait, egyéb tulajdonságait, valamint az egyes táblák közötti kapocslatokat lehet illusztrálni. Általában egyszerűbb mint a megvalósítás, mert az m-n kapcsolatokat is egy (megfelelő alakú) szakasz ábrázolja (tehát nem kell külön kapcsolótáblát létrehozni), ill. a hivatkozásokat is elég az adott táblát illusztráló téglalapból kiinduló egyenesekkel ábrázolni.

Az UML-ez képest még hangsúlyosabban merül fel az a kérdés, hogy hogyan szeretnénk használni: ebből szeretnénk generálni a sémát létrehozó SQL scripteket, vagy inkább csak a rendszer adatmodelljének az általános bemutatására használjuk. Én ez utóbbit részesítem előnyben, így a megértés szempontjából lényegtelen táblákat előszeretettel hagyom ki.

Gantt-diagram

Klasszikus projektmenedzsment eszköz, melynek segítségével az tervezhető, hogy mikor ki mivel fog foglalkozni. Általában jól kezelhetőek vele a függőségek, és segítségével egyből látszik, hogy egy újabb feladat mennyivel tolja ki a projekt elkészültét.

Itt is felvetődik az, hogy mire, mennyire precízen szeretnénk használni. A problémát az okozza, hogy sokkal precízebben lehet tervezni a mostani feladatokat, mint a több hónappal későbbieket, erre a bizonytalanságra viszont pont nincs felkészítve. Pl. nem lehet neki olyat mondani, hogy "ez a feladat olyan 6-8 napig fog tartani, de ha pont az a fejlesztő, aki jól ért hozzá, épp szabadságon lesz, akkor érdemes inkább 10 nappal számolni, de elkezdeni csak akkor tudjuk, ha az a második feladat 80%-os készültségen van". Valószínűleg emiatt kopott ki a gyakorlatból. Személy szerint én magas szintű tervezésre használtam, pl. negyedéves vagy max. havi lebontásban, és ennek megfelelően nagyobb tevékenységekre. A feladatokra történő alábontás más módon történt.

Szoftverek

Lássunk néhány tervezőszoftvert!

  • Visio: egész sokféle ábrát lehet segítségével készíteni. Az UML szabványt - fogalmazzunk finoman - nem veszi túl komolyan, valójában egy adott diagramra mindenféle ikont rá tudunk helyezni. Segítségével gyorsan tudunk látványos (bár nem feltétlenül 100%-ban precíz) ábrákat készíteni. Sajnos fizetős, és noha a Microsoft Office csomag része, a tapasztalatom szerint szinte alapból szinte soha nincs feltelepítve.
  • DIA: a Visio ingyenes párja. Kicsit kevesebbe tud, kicsit csúnyább is az eredmény, viszont (érzésem szerint) valamelyest precízebb annál. Sokféle diagramot lehet segítségével létrehozni, szívesen használom.
  • PlantUML: ahogy a nevéből sejthető, ezzel UML diagramokat lehet készíteni. A legtöbb UML tervezővel szemben itt nem egy WYSIWYG szerkesztőt használunk, hanem szövegesen kell megadnunk a tervet. Számos beépülője van, pl. a Confluence oldalakra, vagy Word-be is. A http://plantuml.com/ oldalon egy nagyon jól használható, példákkal alátámasztott tananyag található. Elég gyorsan meg lehet szokni, és igen szerethető!
  • ArgoUML, StarUML: ez két ingyenes WYSIWYG UML szerkesztő, melyekkel tényleg csak UML diagramokat tudunk készíteni. Ha ki szeretnénk zárni még a kísértését is annak, hogy ne UML ábrát készítsünk, hanem csak UML elemeket is tartalmazó akármilyen ábrát, akkor ezeket érdemes használni. Viszonylag gyorsan tanulhatóak.
  • Enterprise Architekt: régebben ez volt a kedvencem. Segítségével precíz UML ábrákat, adatmodelleket és elmetérképeket is lehetett készíteni. Sajnos fizetős, bár amikor használtam, úgy éreztem, hogy megérte az árát.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License