A mai post kicsit alapszintűbb, műegyetemi infoképzést őszintén végighallgatók sok újat nem fognak benne találni. Az apropója egy új, fiatal kolléga a csapatban, aki teljesen új modult fog kapni, és arról beszélgettünk, ehhez hogy kell nekilátni - szerintem.

A kezdő informatikus - vagy a nem kezdő, ugyanakkor más szemléletű vagy épp autodidakta - ha kap egy feladatot, mivel kezdi?

Az adatstruktúrák felállításával.

You’re doing it wrong. *

(* Legalábbis szerintem, a legtöbb esetben)

Egy programnál sohasem az a kérdés, hogy milyen elemek vannak, ez részletkérdés. Ami a fontosabb: mit kell csinálnia annak a szegény programnak?

Erről ad információt az (egyesek kedvéért huszonötször átnevezett, elrejtett, átsematizált) use case modellezés.

Hadd kezdjem egy kijelentéssel: ha valami hülyeség az UML-ben, akkor a use case diagrammok bátran ilyenek lehetnek: a karikákkal ábrázolt use case-ek sokkal kevésbé hatékonyak, mint az egyszerű, jól megfogalmazott felsorolások. (Védelmükben: az UML 2.0-nak azért sok olyan része van, amit nem véletlenül nem emlegetnek egyáltalán nyilvánosan, azoknál azért hasznosabb, de talán leginkább a tisztán UML-alapú tárgyalás miatt szerepel a tananyagokban.)

De egyáltalán: miért is kellenek nekünk use case-ek?

Kedvenc példám: egy kisgyereket megkérdeztek arról, milyen az a kedvenc játékrobot, amit kezében tart. A gyerek nem azt mondta, hogy vannak szárnyai, csipogója, meg villogója, hanem hogy: “Hát ha kinyitod ííígy akkor wooooom és ha megnyomod iiitt akkor brrrrrrrrr és ha hátrahúzod így, akkor vijuvijuviju…” Nem azt mondta, milyen struktúrális elemei vannak - hanem hogy miket lehet vele csinálni!

Pl. ha nincsenek use case-eid, akkor jó esélyed van arra, a programod felesleges. Nem egy alkalmazás volt, amiről megkérdezték a véleményemet (vagy nem kérdezték, csak mondtam) különféle cégek, szervezetek, és a specifikáció megtekintése után azt kérdeztem: hol vannak a use case-ek?

Ezek egy része bemutatott, az Olvasó számára is hallomásból ismert, és kivétel nélkül bukott szolgáltatások.

A use case elemzéstől félünk a webszakmában, ugyanis kiderülhet, az oldalunk felesleges, nincs igény arra, amit mi ott kitaláltunk, vagy van már, ami jobban, szebben teszi ezt célcsoportunk számára, és ismerik is azt. Ezt persze nehéz beismerni, így a weboldal bukása után érdemes lehet a use case analízist a pszichoanalízissel együtt alkalmazni.

De mégis szükséges. Szükséges egyrészt programoknál is, másrészt viszont jó ötlet sima, statikus honlapoknál is.

És akkor most elárulok egy szakmai titkot: a szereplő fogalmat lehet párosítani a média és marketing célközönség fogalmával, gyakran meglepő (semmiképp nem korosztály-alapú) célközönségfelosztást alkalmazva, sikeressé tehetjük oldalainkat, hisz azt, és csak azt készítjük el, amire céközönségünknek szüksége van!

Miből is áll a use case analízis?

  • szereplőkből
  • use case-ekből, azaz a használat módjaiból (hogy lehet zümmögtetni, és vijjogtatni, és…)
  • forgatókönyvekből, azaz ezek hogyanjából (a zümmögtetéshez meg kell fogni iitt és aztán megnyomni iiitt…)

Először is a szereplőkről.

Ezt szinte mindig utólag finomítani kell, előszőr mindig gondolkozzunk azon, van-e a “rendes felhasználón” kívül esetleg valamiféle “karbantartó-jellegű” felhasználónk is, pl. adminisztrátor, moderátor, hírfeltöltő, anyagrögzítő, sőt, az informatikai modellezés szabályai szerint a külső rendszerek (pl. API-kliensek) is szereplőnek számítanak.

Ha már vannak szereplőink, gondoljuk végig: “mit is akarnak ezek az emberek (gépek) a leendő programunktól?”

Ez egy nagyon nehéz kérdés, pláne azért, mert arra is rá kell jönnünk, mit nem akarnak (pl. nem akarom, hogy az iWiW kávét főzzön, de a facebook se. Nem érdekel, készíthető-e kávéfőző app, én oda nem azért járok, arra ott van a kávéfőzőm adminfelülete. Integrált youtube se kell.)

(Nincs ilyen kávéfőző gépem: megrögzött teamániás vagyok. :) )

Ezek listái, szereplőkre bontva, lesznek a use case-ek

Ezeknek a leírásoknak viszont, mint már említettem, van formátumuk. A formátum alapesetben:

Ki mit mivel, azaz
Géza főz kávét a kávéfőzővel (Angolul: George cooks a coffee with the coffee machine: alany, ige, tárgy, többi. Tudom, hogy George az György…)

Ez nem véletlenül van így. Amikor áttekintjük őket, lesz egy rakás igénk és tárgyunk: ezek lesznek a rendszer alapkövei, a gombjaink, menüpontjaink feliratai. Érdemes esetleg segédigéket (Géza tud főzni kávét, akar főzni, szeretne, képes, stb) bevenni azért, sokszor könnyebben csúszik le így a torkon.

Ugyanakkor: lehet rossz use case: A Rendszer főz kávét Gézának. A Rendszer, ha egy mód van rá, ne csináljon semmit, amíg meg nem kérik. Géza főz kávét a segítségével, ez inkább. Vannak kivételes esetek, tipikusan az autonóm működés. Meg aztán ne feledjük, minden use case-nek lesz forgatókönyve (későbbi algoritmusa), amiben majd ott lesznek az autonóm részek, ahol a vizet forralja a Rendszer, meg kávét pörköl, de a use case az az, hogy mi az elvárás, mindig egy felhasználó igényét, és így interakcióját írja le.

(Honlaptervezés: Diák megnézi az órarendet / végigböngészi a galériát. Szülő tájékozódik a tanév menetéről / értekezletek időpontjairól / csemetéi állásáról / felvételi információkról. Felhasználó zenevideót keres előadó alapján. Kutató cikket keres évkritériumok alapján. Páciens felküldi frissen felújított mellei képét twitterre.)

Forgatókönyvek

A use case-ek forgatókönyvei szintén szövegesen szoktak készülni, itt már picit elválik egymástól az agilisabb user story, és a merev use case fogalom, előbbi ugyanis kevésbé foglalkozik a hibalehetőségek kezelésével és az intelligens hibaelhárítással, míg utóbbi nagyon is.

A forgatókönyvekre hasonló szabály vonatkozik ige-elrendezés szempontjából, de itt többször fog szerepelni a rendszer vagy a szervezet, mint alany. Pl. az use case, hogy pénzt akarunk levenni az automatából, az viszont már forgatókönyv-részlet, hogy a Bank leellenőrzi a pin-kódunkat.

Belőlük kivadászva a főneveket, és ezek rész-egész kapcsolatait elemezve fogjuk megkapni a struktúráinkat, amikből aztán osztályok, űrlapok, táblázatfejlécek, és persze osztálydiagramjaink lesznek.

De az már egy másik téma.

Ja, tudjátok, hol pionírkodták ki többek közt a use case-orientált gondolkodást?

Az én emlékeim szerint - de lusta vagyok adatokat kutatni, házi feladat - Palo Altoban, a Xerox PARC laborban. Talán ezért van annyira kevés gomb az Apple programokon?