Adam Nemeth’s Blog

Ez már majdnem kód… bocsi, kitaláltam valamit, kell a gondolatmenet felépítéséhez ennek az ismerete… Meg aztán remélem, haszonnal forgatjátok, megismerkedtek egy olyan eszközzel, amiről eddig sokszor csak előítéleteket hallottatok…

A modellek sokszor folyamatokat írnak le, nem struktúrákat (Beiratkozás az egyetemen, forrás: Agilemodeling.com)

Az előző postban elejtettem, hogy “a diagramjaim rendszerint rövidtávra készülnek”. Ez egy nagyon fontos mondat, szeretnék rajt elidőzni.

A modellezésről a legtöbb embernek a Model-Driven Development jut eszébe, ami egy szép elméleti elképzelés, a gyakorlatban viszont nehéz kivitelezni, bár vannak működő rendszerek, főleg bankoknál.

Pedig a modellezés fontos része a programozásnak, enélkül nem lehet átlátni a szoftvereket, nemhogy minőségi programot írni.

A modellezés definíciója

Két definícióm van. Az egyik, amit az egyetemen tanultunk:

A modell a világ adott szempontú nézete, amely a szempont szerint lényeges dolgokat kiemeli, a lényegteleneket elrejti.

A másik a sajátom:

A modell a [rendszer] dolg[aina]k [tulajdonságai és] összefüggései [és összefüggéseinek tulajdonságai] [adott szempontok szerint] [ábrázolva]

([] - opcionális)

Tévhitek a modellezésről

• Nem igaz, hogy az egész rendszert modellezni kell.
  Általában csak egy kis, de fontos / bonyolult / más módon megbeszélést igénylő részét szoktuk

• Nem igaz, hogy minden modellt folyamatosan frissiteni kell.
  Alapvetően háromféle modell van:
  • Az egyszerhasználatos, ezt teljesen logikus okokból nem frissítjük nagyon.
  • Az architekturális, vagy egyéb nagy, szükséges és fontos modell, amik ritkán változnak, akkor viszont napra készen kell őket tartani. Végül pedig:
  • A rendszer részét képező modell, azaz, amikor az adott modell adatfájlját beolvassa a program, és aszerint működik (akár konvertáláson keresztül) Ez pedig definició szerint friss.
• A modell nem feltétlenül létezik ábrázolva
  ha az a modelled a Mariskáról, hogy nagyok a csöcsei, formás a popsija, és jól tud ezekkel végigvonulni az irodán (elnézést a hölgyektől), világos, hogy ebből a szempontból lényegtelen, hogy tök jól tud németül, ugyanakkor az is, hogy ez a mentális kép inkább a fejedben, semmint ábrázolva jelenik meg.

• A modell nem feltétlenül diagram
  
  Sőt, az UML-nek is vannak olyan részei, amik szöveges leírásként fogalmazzák meg a problémát! De a modell lehet adatfájl is (doc, txt, 3ds, de a kedvencem: YAML) - Sokféle módon lehet ábrázolni egy rendszer összefüggéseit, lényeges tulajdonságait

• A modell nem feltétlenül UML nyelvű
  
  Bár az UML készlete bőséges, és helyenként jó is (máshol szódával elmegy persze), bármikor előfordulhat olyan probléma, ahol nem áll kézre épp, vagy egy más rendszer jobban megfelel.
  Az egyik projektemnél például sokat használtam az AAM-től lesett folyamatábrák egy saját származékát, (minden botrányuk ellenére sok tehetséges, fiatal informatikust ismerek ott, akik komolyan veszik a szakmájukat.), nem teszem ki ide
  (szellemi tulajdonuk), de a trükköt elárulom: nem csupán a feladat-, de a vele párhuzamosan folyó adatfolyamat is fontos.

Mire jó a modell?

A modell elsősorban a kommunikáció segédeszköze.

Attól jó, hogy:

• Félexplicit
  Már nem csinálhatsz benne bámit, mintha simán írnál, de még nem program
• Olcsó
  Nem kerül annyiba, mint a tényleges program (Nem értek egyet azzal, hogy egy jó UML ábra elkészítése annyi idő mint a vele ekvivalens programé, vagy én programozok baromi lassan.)
• Átlátható
  Persze, csak ha jól csinálod

Mivel ez egy kommunikációs eszköz, ezért három helye van tipikusan:

• Az ügyfél és közted
• Egymás között (programozók)
• Magadban

Igazából ha valamit nem értesz, az ügyfél nem ért, vagy a kollega nem ért, akkor nem szabadna kódhoz nyúlnod, akkor kellene használnod a modellezést. Ezért kéne a modellezési eszközöket és szabályokat ugyanúgy ismerni, mint a programnyelveket.

Modellezés a mindennapi életben

Ha vitás kérdés van, évek óta berántom a csapatot tábla elé, ez mostani munkahelyemen se változott sokat

A modellezés tökéletesen alkalmas arra, hogy ezeket a vitákat tisztázzuk (nem feltétlenül pusztán hierarchikus alapon, “merénaszontam”), illetve annak ellenőrzésére, hogy tartja-e magát mindenki ehhez (az adott szempontú) közös megegyezéshez.

A kódolás végeztével ezzel a modellel lehet ellenőrizni, jól csináltuk-e azt, amit csináltunk, többet viszont nem használjuk, max mellérakjuk a modulnak valahogy, hogy ha kell, itt van egy ábra, ki tudja még, mire lesz jó.

Az ilyen ábrák elsősorban táblára készülnek. Ezért van a legtöbb informatikai cégnél jó sok nagy fehér filctábla. Ha ez nincs, akkor van flipchart, de az pici, és kényelmetlen is.

Sokan max befényképezik ezt az ábrát, úgy küldik szét, vagy akár csak ezt se, annyira egyszerhasználatos.

Szerintem viszont készítsd el rendesen, gép előtt. Ilyenkor mindig figyelek arra, a megfelelő szavakat, a megfelelő vonalakat, megfelelő sztereotípiákat használjam, mindent oda, úgy kössek be ahogyan kell, a felesleges részeket kihagyjam, ha rájövök, több nézőpont egyesül az ábrán, esetleg szétszedjem azt.

Fontos ugyanis, hogy ne egy körülbelüli massza alapján dolgozzunk. A tapasztalat az, hogy a programozók ezeket az ábrákat utána kinyomtatják, és ott van előttük, miközbe dolgoznak (akkor is, ha ezt nem kérem külön). Amikor jössz átnézni a kódot, akkor is lehet hivatkozni a kezedben lévő lapra, hogy hol vannak az egyes modulok, hol vannak az összekötések. Sokkal tisztább ez így.

Ez másfél-két órát vesz el maximum ábránként az életemből: az érvényességük általában 1-2 hét, ez alatt bőven megtermelik ezt, mivel nem a kétértelműségeken vitatkozunk naponta fél órát egy-egy apróbb félreértés miatt.

Mi ezeknek az ábráknak a sorsa? Van egy megbeszélés, felskicceljük a táblára, én megrajzolom gépen, körbeküldöm, ez alapján leimplementálunk egy modult, vagy épp megváltoztatjuk azt, ellenőrizzük a végén, hogy jól van-e, de alapvetően egyetlen iterációra, vagy még annyira sem érvényesek, tehát tényleg 1-2 hét, egy-egy hónap az, amíg aktuálisnak nevezhetőek. Ezzel nincs semmi baj, ez alatt az idő alatt is rengeteget segítenek, sok félreértéstől kimélnek meg minket.

Persze vannak állandóbb ábrák, ilyenek az architektúra-leírások, a keretrendszerek ábrái, a fizikai topológia, adatbázis-séma. Ezeket figyelnünk kell, karban kell tartani, és emiatt lehetőleg minél kevesebb ilyen ábránk legyen, azok viszont legyenek jók, és a ciklusok végén naprakészek.

Rendszerszintű modellek

Hogy ez egy osztály, egy validálandó űrlap, vagy egy adatbázis-tábla? Te döntöd el. Hogy ez PHP, Ruby, Python vagy Java? Bármelyik lehet, ettől is modell. Azt döntsd el, érthető-e egyetlen ránézésre?

Említettem, hogy nem fogok Model Driven Developmenttel foglalkozni, most egy picit mégis. Van nekem egy trükköm ugyanis: a legtöbb model hierarchiára, gráfra, illetve függvénynevekre fog leképződni. Ezeket tök jól lehet pl. egy YAML fájlban tárolni, és megfelelően általános program ebből fog dolgozni, vagy használhatunk speciálisan elnevezett, esetleg más módon jelölt (annotációkkal, PHP-sok: getDocComment) függvényeket, sőt, MVC frameworkök, pl. a Symfony vagy a Zend Framework be is tartat velünk ilyeneket sokszor.

A YAML-ek jók, mert néha jobban átláthatóak, mint az ábrák, a modell pedig nem feltétlenül ábra. Ha ábrát akarunk belőlük csinálni, vegyünk fel egy új tulajdonságot: hideInModel. Ha ez van, skippeljük, egyébként tegyük lehetővé, hogy valamilyen ábrát (legegyszerűbb: GraphViz Dot ) tudjunk belőle készíteni.

A keretrendszereknél tipikusan az executeAction függvények szoktak ilyenek lenni, hogy mely modulokon milyen metódusok végezhetőek. Ezeket is össze lehet gyűjteni akár egy jobban átlátható YAML fájlba, akár egy DOT-ból generált diagramba.

A jo-helynél a modellek többsége nem létezett grafikus formában.

Mindehhez nem kell más, csak pár szöveges eszköz, pl. grep, find, esetleg az IDE beépített modellje a programkódról. Ne kézzel gyűjtögessük, írjunk programot rá!

De alapvetően akkor vagyunk jók, ha a programkódunk maga is olyan tiszta, mint egy model: más szempontokat máshol modellez,mégis, pont annyit ír le, amennyi szükséges.