Specifikáció: hogyan?

A nagy házi feladat 2-es mérföldkövénél, a specifikációban kell leírni azt, hogy pontosan hogyan fog kinézni a program, amit házi feladatként szeretnél elkészíteni. Ez többek közt azért is fontos, mert értékelési szempont, hogy a program teljesíti-e a specifikációját. Ugyanakkor ha most programozol először vagy még nem igazán tervezted előre a programjaidat, nem biztos, elsőre tiszta, hogy mi ez és miért kell egyáltalán.

Specifikációt azért kell készíteni, mert az iparban ha programot írsz, leggyakrabban nem magadnak írod, hanem valaki másnak. Ez legfőképpen azt jelenti, hogy ilyenkor kezdetben nem a te tiszted tisztában lenni azzal, hogy mik az elvárások a programmal szemben: hogyan várja a bemenetét, mit kell csinálnia vele, milyen kimenetet adjon, milyen hibákat kell lekezelnie, és így tovább. Ezeket az elvárásokat ideális esetben a megrendelőnek kellene tudnia, azaz annak, aki a program elkészítését várja tőled. Ebben kell a megrendelőnek és a programozónak egyetértenie. A specifikáció pedig pontosan ez: a programmal szembeni elvárások összessége.

Persze sokszor van az, hogy távol állunk az ideális esettől. A megrendelő nagyon gyakran nem is tud programozni, így segítség nélkül nem is igazán tudja pontosan összeszedni az igényeit. Ezért aztán különösen fontos, hogy a megrendelő és a programozó közösen megbeszélve írásba foglalják a programmal szembeni elvárásokat. Ahol pedig a félreértésnek akár a lehetősége megjelenik, válasszanak a lehetséges alternatívák közül, a választást pontosításként rögzítve a specifikációban.

Előkerül emellett a specifikáció akkor is, amikor két programozó ugyanazon a programon dolgozik. Ilyenkor a benne leírt elvárások biztosítják azt, hogy ők ketten (vagy többen) ne álljanak hozzá véletlenül lényegesen máshogy a program elkészítéséhez, ne legyen ilyen természetű zűrzavar.

Összegezve tehát a jól megírt specifikáció garantálja, hogy a programozók biztosan egyazon feladat megoldásán dolgozzanak és ez a megoldás az elvárt megoldás legyen. Vagyis az, amit a megrendelő szeretne.

A specifikáció jóságát a következők határozzák meg:

• Elég részletesen ír olyan dolgokról, amikről írnia kell.
• Nem hagy ki olyat, amiről írnia kell.
• Nem ír olyanról, amiről nem kellene írnia.

Részletesség

A programozás nagy házihoz specifikációt írni abból a szempontból talán furcsa, hogy most lényegében egyszerre vagy a megrendelő és a megvalósító programozó is. Viszont amikor a specifikációt készíted, mégis érdemes ezt a két szerepet gondolatban különválasztanod: helyezd magad képzeletben a megrendelő szerepébe és gondold végig azt, hogy egy másik programozó el tudná-e pontosan a te elvárásaidnak megfelelően készíteni a programodat, ha csak a specifikációt kapná róla kézhez. Erre utal a legfontosabb tételmondat a pontosított specifikációról szóló követelményekben:

A pontosított specifikáció részletességére jellemző, hogy ha két külön programozó elkészíti a programot ugyanabból a specifikációból, de egymástól függetlenül dolgozva, akkor kívülről nézve nagyon hasonló programoknak kell keletkezniük.

Ami a probléma, hogy nem mindig gondolunk bele, hogy egy másik programozó hozzánk képest mennyire máshogy gondolkodhat. Biztosan (a program kifelé látszó viselkedését tekintve) ugyanúgy valósítaná meg azt, hogy „a program menüvezérelt és a következő menüpontok vannak: [...]”? Vagy hogy „a program az adatokat fájlba tudja menteni”?

Egy konkrét példa. Egy program rövid feladatleírása többek közt tartalmazza azt, hogy a program mentse fájlba az adatokat, amikkel dolgozik. Bár akár a megrendelőnek, akár a programozónak felületesen belegondolva nyilvánvalónak tűnhet, mit jelent ez – valójában itt számos dolgot félre lehet érteni. Pontosan milyen adatokat is mentünk? Hogyan nézzen ki a mentésfájl, mondjuk A␣B␣C formátumú sorok, ahol A, B és C a különböző adatfajták és ␣ egy szóköz, vagy inkább valahogy máshogy? Automatikusan mentsen a program kilépéskor, vagy erre mindig a felhasználónak kelljen utasítania? Az ilyen és ehhez hasonló dolgokat mind-mind meg kell határozni, rögzíteni kell a specifikációban.

Amikor a specifikációt fogalmazod, folyamatosan arra gondolj, hogyan lehet azt, amit éppen írsz, félreérteni. Ha találsz egy ilyen esetet, akkor rögtön tudni fogod, hol kell pontosítani, hogy a képzeletbeli másik programozó is pontosan azt kódolja majd a specifikáció elolvasása után, amit te szeretnél.

Tartalom: ami kell

A specifikáció tartalma tehát a feladatkiírás a fentieknek megfelelő módon elvégzett részletekbe menő pontosítása. Általánosságban a specifikációból látsszon, hogy felhasználói szemszögből hogyan lehet használni a programot. Kiindulhatsz a minta NHF specifikációjának felépítéséből is. Legyen itt néhány pont gondolatébresztőnek:

• Menüvezérelt program:
  • Hogyan jelenik meg a menü, hogyan lehet menüpontot választani?
  • Hogyan jelennek meg az egyes funkciók?
  • Hogyan lehet visszakerülni a főmenübe, mikor van vagy nincs rá mód?
  • Hogyan, milyen sorrendben kér be a program adatokat?
  • Milyen formában várja a program az egyes adatokat? (pl. ÉÉÉÉ/HH/NN?)
  • Vállalkozik-e a program hibás bemenet (pl. rossz formátumú adat) lekezelésére? Ha igen, milyen hibákat tud kezelni, hogyan jelzi a hibát? (hibaüzenet, stb.)
  • Milyen az elvárt kimenete az egyes funkcióknak?
• Játékprogram:
  • Játékszabályok: hogyan zajlik a játék, hogy lehet nyerni, mikor veszítünk? Akkor is, ha egyébként széles körben ismert játékról van szó. Mi van, ha a képzeletbeli programozók eddig valamiért sosem látott kígyós játékot? Ha nem ismeri a kártyajáték szabályait? Ha nem úgy ismeri a szabályait?
  • Milyen nézetek vannak? Pl. főmenü, dicsőséglista, játéknézet... még valami?
  • Mikor, hogyan lehet az egyes nézetekből másikba eljutni? („új játék gombbal indítható...”)
  • Hogyan jelenik meg a pálya? Főleg, ha nem grafikus a program, ekkor milyen szöveges karakter mit reprezentál, stb.
  • Menthető a játékállás? Ha igen, mikor, hogyan?
  • Milyen bemenettel irányítható a játék?
  • Hogyan reagál a játék az egyes bemenetekre?
• Mi az írt/olvasott fájlok belsejének formátuma? (lásd a fentebbi példát)
• Vállalkozik-e a program hibás formátumú fájl lekezelésére? Ha igen, mit csinál ilyen helyzetben?

Még egyszer: ezek csak gondolatébresztők, nem feltétlenül csak ezeket, de innen sem feltétlenül mindet kell a specifikációban kifejteni. Feladatfüggően simán lehet olyan dolog, ami fontos és leírandó, de ebben a listában nem szerepel és fordítva, azaz szerepel a listában, de az adott feladathoz nem releváns. A lista nem is jelenti azt, hogy kérdezz–felelek formában kellene a specifikációt megfogalmazni.

Tartalom: ami nem kell

A specifikáció írása közben vedd figyelembe a következőket:

A specifikáció nem megvalósítási terv. Ha ilyeneket vagy ehhez hasonlókat írnál bele, hogy „integerben tárolja”, „dinamikus tömb”, vagy „láncolt listát épít”, akkor töröld is ki rögtön, mert nem feladata a specifikációnak ezeket előírni. Sőt! A megvalósítási részletek a megrendelőnek érdektelenek, őneki csak az a fontos, hogy a program azt csinálja, amit ő akar, számára a hogyan nem érdekes.

Illetve, az előzővel kapcsolatosan: a specifikáció nem szándéknyilatkozat. (Néha kaptunk ilyet is.) Ha ilyeneket írnál, hogy „szeretnék”, „tervezek”, „úgy akarom, hogy”, vagy bármikor ehhez hasonlóan átcsúszik a szöveg egyes szám első személybe, azt töröld is ki, mert a specifikáció nem arról szól, hogy te elmagyarázod a laborvezetőnek, hogy mit akarsz lekódolni. (Személyes konzultáláskor, vagy levélben viszont megteheted! Örülünk a kérdéseknek.) A specifikáció a programról szól, azt mondja meg, hogy a programot milyenre kell megvalósítani.

A specifikáció arról szól, hogy elmondja egy másik (képzeletbeli) programozónak, aki elég sok mindent félreért, hogy a programot milyenre kell megvalósítani. A specifikáció akkor jó, ha ebben sikerrel jár.