VIK Wiki

„Szoftver projekt laboratórium” változatai közötti eltérés

← Régebbi szerkesztésÚjabb szerkesztés →
VizuálisWikiszöveges
Csia Klaudia Kitti (vitalap | szerkesztései)
felületadminisztrátorok, oauth2, smwadministrator, smwcurator, adminisztrátorok, upwizcampeditors
1 846 szerkesztés
aNincs szerkesztési összefoglaló
97. sor: 97. sor:
*** Funkciók: A feladat szövegében sok olyan részlet van, ami nincsen kifejtve, a csapatra van bízva, hogy ők hogyan képzelik el. Ebben a részben főleg az ilyen részleteket kell kifejteni, azaz úgy kell átfogalmazni a feladat szövegét, hogy abból minden egyértelmű legyen, ne lehessen részeket többféleképpen értelmezni.
*** Funkciók: A feladat szövegében sok olyan részlet van, ami nincsen kifejtve, a csapatra van bízva, hogy ők hogyan képzelik el. Ebben a részben főleg az ilyen részleteket kell kifejteni, azaz úgy kell átfogalmazni a feladat szövegét, hogy abból minden egyértelmű legyen, ne lehessen részeket többféleképpen értelmezni.
*** Követelmények: Ennek összhangban kell lennie a Funkciók résszel, a szövegben főleg az igékre fókuszálva célszerű kigyűjteni ezeket. (ajánlott legalább 15-20 követelmény megfogalmazása) Ez alapján a use-case-ek meghatározása már könnyű.
*** Követelmények: Ennek összhangban kell lennie a Funkciók résszel, a szövegben főleg az igékre fókuszálva célszerű kigyűjteni ezeket. (ajánlott legalább 15-20 követelmény megfogalmazása) Ez alapján a use-case-ek meghatározása már könnyű.
*** Szótár: Mindent fontos benne meghatározni, nem szabad olyan fogalomnak maradnia a korábbi részekben, ami itt nincsen egyértelműen meghatározva. Természetesen nem csak a mennyiség, hanem a minőség is fontos. A funkciók olvasása közben könnyen kigyűjthetőek ezek a fogalmak. Ajánlott, hogy több ember is olvassa át ezt, mert ekkor még a csapatban nem alakul ki egy tlejesen közös kép a feladatról, és emiatt mindenki a saját elképzelését fogalmazza meg, így fellelhetőek az olyan részek, amik nem lettek még a csapaton belül normálisan tisztázva.
*** Szótár: Mindent fontos benne meghatározni, nem szabad olyan fogalomnak maradnia a korábbi részekben, ami itt nincsen egyértelműen meghatározva. Természetesen nem csak a mennyiség, hanem a minőség is fontos. A funkciók olvasása közben könnyen kigyűjthetőek ezek a fogalmak. Ajánlott, hogy több ember is olvassa át ezt, mert ekkor még a csapatban nem alakul ki egy teljesen közös kép a feladatról, és emiatt mindenki a saját elképzelését fogalmazza meg, így fellelhetőek az olyan részek, amik nem lettek még a csapaton belül normálisan tisztázva.
** Többi rész főleg a dokumentum keretbe foglalásáért felelős, de azok kitöltése is követelmény.
** Többi rész főleg a dokumentum keretbe foglalásáért felelős, de azok kitöltése is követelmény.
* 3. Analízis modell kidolgozása 1:
* 3. Analízis modell kidolgozása 1:
105. sor: 105. sor:
** State-chartok: Nálunk az hangzott el, hogy nem túl fontos, csak tényleg akkor rakjunk bele, hogyha van olyan része a feladatnak, amit jól jellemez.
** State-chartok: Nálunk az hangzott el, hogy nem túl fontos, csak tényleg akkor rakjunk bele, hogyha van olyan része a feladatnak, amit jól jellemez.
* 4. Analízis modell kidolgozása 2:
* 4. Analízis modell kidolgozása 2:
** Általában az előző részt nem szokta senki sem elsőre jól megcsinálni, emiatt mégegyszer meg lehet próbálni. A labor vezetők rá fognak mutatni az előző beadandó hibáira, és legalább azokat ajánlott javítani a jó pontért. Természetesen aki az előzőt jobbra megcsinálta, annak itt kvesebb tennivalója van.
** Általában az előző részt nem szokta senki sem elsőre jól megcsinálni, emiatt mégegyszer meg lehet próbálni. A labor vezetők rá fognak mutatni az előző beadandó hibáira, és legalább azokat ajánlott javítani a jó pontért. Természetesen aki az előzőt jobbra megcsinálta, annak itt kevesebb tennivalója van.
* 5. Szkeleton tervezése:
* 5. Szkeleton tervezése:
** A szekelton lényege, hogy a korábban megfogalmazott működést kellene egyszerű konzolos felületen keresztül bemutatnia, azaz nyomon kell tudni követni egy adott szekvenciát például.
** A szkeleton lényege, hogy a korábban megfogalmazott működést kellene egyszerű konzolos felületen keresztül bemutatnia, azaz nyomon kell tudni követni egy adott szekvenciát például.
** Sok (>10) use-case-t ajánlott megfogalmazni, nagyjából a program teljes működését le kellene velük fedni.
** Sok (>10) use-case-t ajánlott megfogalmazni, nagyjából a program teljes működését le kellene velük fedni.
** A menüben az előtte megfogalmazott use-case-ek közül kell tudni választani, aminek hatására elindul egy szekvencia végrehajtása. Fontos, hogyha a szekvenciát valamilyen döntési feltétel van (opt, alt), akkor azt a felhasználótól meg kell kérdezni, hogy ez most igaz vagy hamis. Akár az is lehetséges, hogy a felhasználónak előre elmondjuk (kiírjuk), hogy a várt végrahajtáshoz milyen válaszokat kell adnia a megjelenő kérdésekre.
** A menüben az előtte megfogalmazott use-case-ek közül kell tudni választani, aminek hatására elindul egy szekvencia végrehajtása. Fontos, hogyha a szekvenciát valamilyen döntési feltétel van (opt, alt), akkor azt a felhasználótól meg kell kérdezni, hogy ez most igaz vagy hamis. Akár az is lehetséges, hogy a felhasználónak előre elmondjuk (kiírjuk), hogy a várt végrehajtáshoz milyen válaszokat kell adnia a megjelenő kérdésekre.
** A konzolra a függvény meghívását (a paramétereivel együtt akár) és a visszatérését is ki kell írni (identálás - tabulátorok használata erősen javasolt).
** A konzolra a függvény meghívását (a paramétereivel együtt akár) és a visszatérését is ki kell írni (identálás - tabulátorok használata erősen javasolt).
** Kommunikációs diagramok: UML2-ben objektum diagram nincsen, és ennek a résznek az lenne a lényege, hogy az objektumok közötti kapcsolatokat megjelenítse, azaz a szekvencia diagramok felülnézetét. Nálunk azt mondta Goldschmidt Balázs, hogy itt nem kell megjelennie az üzenetváltásoknak, hiszen azok a szekvencia diagramokon már szerepelnek, azaz itt csak össze kell kötni azokat az objektumokat (nem osztályokat), amik a szekvencia diagramokon szerepelnek, tehát egy szekvencia diagramhoz alapvetően tartozik egy "kommunikációs diagram" is.
** Kommunikációs diagramok: UML2-ben objektum diagram nincsen, és ennek a résznek az lenne a lényege, hogy az objektumok közötti kapcsolatokat megjelenítse, azaz a szekvencia diagramok felülnézetét. Nálunk azt mondta Goldschmidt Balázs, hogy itt nem kell megjelennie az üzenetváltásoknak, hiszen azok a szekvencia diagramokon már szerepelnek, azaz itt csak össze kell kötni azokat az objektumokat (nem osztályokat), amik a szekvencia diagramokon szerepelnek, tehát egy szekvencia diagramhoz alapvetően tartozik egy "kommunikációs diagram" is.
121. sor: 121. sor:
** Nagyjából ezt a részt úgy kell elképzelni, mint a szkeleton általánosítását, azaz adott funkciók nem "bedrótozva" vannak, hanem a programunk parancsokat értelmez, és a parancsoknak megfelelő funkcionalitást hajtja végre. Gyakorlatilag ezzel a programnak a modell része majdhogynem teljesen kész lesz, csak a grafikus rész fog hozzákerülni, de az is ehhez hasonló interfészt fog használni.
** Nagyjából ezt a részt úgy kell elképzelni, mint a szkeleton általánosítását, azaz adott funkciók nem "bedrótozva" vannak, hanem a programunk parancsokat értelmez, és a parancsoknak megfelelő funkcionalitást hajtja végre. Gyakorlatilag ezzel a programnak a modell része majdhogynem teljesen kész lesz, csak a grafikus rész fog hozzákerülni, de az is ehhez hasonló interfészt fog használni.
** A parancsok beolvasására a konzolról célszerű egy segéd osztályt felvenni, amire jó eséllyel nem lesz már szükség a grafikus résznél.
** A parancsok beolvasására a konzolról célszerű egy segéd osztályt felvenni, amire jó eséllyel nem lesz már szükség a grafikus résznél.
** A parancsok definiálásának egyértelműnek kell lennie, azaz még azt is jelölni, kell, hogy a parancs paraméterezésénél milyen elválaszt karakter van, mi a paraméterek sorrendje, azok mit jelentenek.
** A parancsok definiálásának egyértelműnek kell lennie, azaz még azt is jelölni kell, hogy a parancs paraméterezésénél milyen elválasztó karakter van, mi a paraméterek sorrendje, azok mit jelentenek.
** A use-case-ek megfogalmazása ezek alapján nem túl nehéz feladat.
** A use-case-ek megfogalmazása ezek alapján nem túl nehéz feladat.
** Tesztelési tervnél a program fontosabb funkcióit legalább le kell fedni. Hogyha van olyan rész, ami több esetben ugyanúgy működik és lényegében csak a megjelenítésben lesz különbség, akkor nem kell többszörösen elkészíteni az adott tesztet.
** Tesztelési tervnél a program fontosabb funkcióit legalább le kell fedni. Hogyha van olyan rész, ami több esetben ugyanúgy működik és lényegében csak a megjelenítésben lesz különbség, akkor nem kell többszörösen elkészíteni az adott tesztet.
** Nem ajánlott JUnit vagy valami ehhez hasonló környezetben gondolkodni, mert csak feleslegesen elbonyolítja a helyzetet, bőven elég karakterese bemenetre és kimenetre gondolni.
** Nem ajánlott JUnit vagy valami ehhez hasonló környezetben gondolkodni, mert csak feleslegesen elbonyolítja a helyzetet, bőven elég karakteres bemenetre és kimenetre gondolni.
* 8. Részletes tervek:
* 8. Részletes tervek:
** Az előző rész részletezéséről szól ez a dokumentum.
** Az előző rész részletezéséről szól ez a dokumentum.
A lap eredeti címe: „https://vik.wiki/Szoftver_projekt_laboratórium”