Szoftver projekt laboratórium

2018-04-19T16:21:18Z

Szatmáry Péter:

{{Tantárgy
|név=Szoftver projekt laboratórium
|tárgykód=VIIIAB06
|régitárgykód=VIIIAB02, VIIIA220
|kredit=3
|felev=4
|kereszt=nincs
|tanszék=IIT
|kiszh=nincs
|vizsga=nincs
|nagyzh=nincs
|hf=11 db
|szak=info
|targyhonlap=https://www.iit.bme.hu/targyak/BMEVIIIAB02
|levlista=szoftlab4{{kukac}}sch.bme.hu }}

{{Átnevezett tárgy|Szoftver laboratórium 4}}

A labor célja objektum orientált alkalmazás készítése UML (Unified Modeling Language) leírással, JAVA-ban megvalósítva, RUP (Rational Unified Process) processz szerint. A hallgatók 4-5 fős csoportokban dolgoznak és készítik el a dokumentumokat a megadott ütemezés szerint (a félév során 11 beadandó feladat lesz). A dokumentumokat a megadott formátumban, az összefoglalás és a programkód kivételével nyomtatott változatban kell beadni.

==Követelmények==
===Előtanulmányi rend===
[[Szoftvertechnológia]] tárgyból aláírás és [[A programozás alapjai 3]] tárgyból kredit megszerzése szükséges a tárgy felvételéhez.

(A VIIIA220 tárgy felvételéhez [[Szoftvertechnológia]] tárgyból kredit megszerzése szükséges.)

===Szorgalmi időszakban===
*A kezdés feltétele, hogy az egyes hallgatók ''csapatokba szerveződjenek (4-5 fő)'', és ''konzultációs időpontot válasszanak'' maguknak. Ha ez explicit nem történik meg, LZ implicit módon a maradék embereket csapatokká kasztolja.
*A min. elégséges '''félévvégi jegy''' feltételei:
**A félév során kiadott '''11 feladat leadása''' (8 dokumentáció, 3 dokumentáció+szoftver). Egy feladat leadásának feltétele ''az összes előző feladat sikeres teljesítése''. A teljesítés feltétele a 3 szoftver fázisnál (Szkeleton, Proto, Grafikus) a kapható pontok 41%-nak teljesítése (ez rendre 9, 15, 17 pontot jelent), a többi feladatnál, hogy a konzulens a feladatot elfogadja (tehát itt nincs minimum pont követelmény).
*'''Pótlási lehetőségek:'''
**Késedelmes leadás esetén a kapható pontok ''naponta 10%-kal csökkennek'', tehát 10 nap késés esetén már biztosan nem jár pont (de ebben az esetben is le lehet adni a feladatot, hiszen ez a többi feladat teljesítésének feltétele). Késés esetén közvetlenül a konzulensnek, vagy a tanszéken lehet leadni az anyagot.
**Ha a konzulens egy feladatot ''nem'' fogad el, úgy azt a következő hétre (a következő beadandó feladattal együtt) újra be kell adni, ilyenkor a rá kapható pont a maximális pontszám 40%-a. Pótolni egy alkalommal lehet.
*'''Kontakt órák'''
**'''Gyakorlat:''' Heti egy alkalom (nem kötelező minden csapattagnak a részvétel).

===A vizsgaidőszakban===
*'''Vizsga:''' nincs.

===Félévvégi jegy===
*A feladatok részletes pontozása:
# Szkeleton (összesen 100 pont, ''min 41 pont'')
#* Követelmény, projekt, funkcionalitás (10 pont)
#* Analízis modell kidolgozása 1. (20 pont)
#* Analízis modell kidolgozása 2. (30 pont)
#* Szkeleton tervezése (20 pont)
#* Szkeleton beadása (20 pont, ''min 9 pont'')
# Proto (összesen 100 pont, ''min 41 pont'')
#* Prototípus koncepciója (20 pont)
#* Részletes tervek (45 pont)
#* Prototípus beadása (35 pont, ''min 15 pont'')
# Grafikus (összesen 100 pont, ''min 41 pont'')
#* Grafikus felület specifikálása (30 pont)
#* Grafikus változat beadása (40 pont, ''min 17 pont'')
#* Összefoglalás (30 pont)
*Mindhárom feladatrész 100 pontot ér. A sikeres teljesítéshez szükséges, hogy ''mindegyik ilyen blokkból a csapat legalább 41 pontot elér'' (és a ''blokkok végén található szoftver beadásra is legalább 41%-ot kap''). Ha ez a feltétel ''nem'' teljesül, az ''egyéni teljesítménytől függetlenül mindenki elégtelent kap'' a csapatban! Ha a minimum követelmények teljesülnek, úgy a Szkeleton (Sc), Proto (Pr), illetve Grafikus (Gr) feladatrészekre kapott pontok súlyozott átlagát kell venni, ahol a súlyok:
*<math>P= 0,3*Sc+0,5*Pr+0,2*Gr</math>
*Az így képzett átlag a csapat pontszáma. Ez a pontszám végül az egyes csapattagok kontribúciójának arányában oszlik el (ezt az arányt a csapat állapítja meg). Amennyiben ez az arány nem tükrözi a napló tartalmát, úgy a konzulens ezt az arányt a csapattagok részvételével (vagy akár anélkül) megváltoztathatja. A végső pontszám jegyre konvertálása az alábbi táblázat szerint működik:
:{|class="wikitable" align="center"
!P !!Jegy
|-
| 0 - 40 || 1
|-
| 41 - 54 || 2
|-
| 55 - 68 || 3
|-
| 69 - 82 || 4
|-
| 83 - 100|| 5
|}

==Jótanácsok==
* [[Szerkesztő:Madbence/Szoftver labor 4 tanácsok|Lennon tanácsai]] a tárgyhoz

=== Verzókezelés ===
Mindenképpen kell egy értelmes verzókezelő rendszer, ha dropboxon vagy haosnlón küldözgetitek, csak magatokkal toltok ki. Jelenleg (2014) működik a [https://git.sch.bme.hu kszk git verziókezelője], pár perc alatt el lehet sajátitani hozzá az alapokat: [https://www.atlassian.com/git/tutorials tutorial]

=== Doksi írás===
Érdemes olyan platformot választani, amit egyszerre mindenki tud használni, nem kell várni a másikra, illetve utólag összeollózni. Jelenleg a [https://drive.google.com Google Drive]nál nem tudok jobbat ajánlani.

=== Kommunikáció ===
Nem kell mindig találkozni, a lényeg, hogy legyen egy olyan közös csatorna, amit mindenki tud követni. Akár facebookbeszélgetés, akár levlista, a lényeg hogy mindig, mindenki kapja meg. (A kódokat viszont ne itt küldözgessétek...)

=== Kommentezés ===
Bármilyen függvényt írsz, mindig kommenteld oda, hogyan kell használni, mire szánod, mert a csapattársad nem tud olvasni a gondolataid között

=== Beadandó tartalmi követelménye ===
2017 tavaszán nekünk Goldschmidt Balázs volt a labvezünk, ezek az információk főleg tőle származnak.
* 2. Követelmény, projekt, funkcionalitás:
** Ennek a dokumentumnak a legfontosabb részei:
*** 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ű.
*** 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.
** 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:
** Objektum katalógus: Ennél a résznél még nem osztályokban kell gondolkodni, hanem a feladatot olvasva ki kell gyűjteni az entitásokat. Ez alapján utána könnyebben lehet az osztályokat meghatározni. Itt még nem szabad az osztályoknak, interfészeknek, öröklésnek megjelennie.
** Statikus struktúra diagram (osztály diagram), szekvencia diagram: Ezt a két részt együtt ajánlott készíteni, hiszen az osztálydiagram hibái előkerülnek a szekvenciák megfogalmazása közben és fordítva is igaz. Fontos az összhang, azaz ami megjelenik az osztálydiagramon, az legalább egy szekvencián is szerepeljen, és ami a szekvencia diagramokon rajta van, az az osztálydiagramon is kell, hogy szerepeljen. Nagyságrendileg 20 szekvenciadiagram ajánlott.
** Osztályok leírása: Jellemzően csak szöveg gyártásáról szól ez a rész az eddig elkészítettek alapján.
** 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:
** Á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.
* 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.
** 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 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.
* 6. Szkeleton beadása:
** Az első rész vége, tartalmaznia kell egy értékelést is, ahol a tagokra bontva megjelenik, hogy ki mekkora százalékban járúlt hozzá az első rész elkészítéséhez (aláírás javasolt a nevek mellé).
** A dokumentum többi részének a kitöltése értelemszerű.
** Ennél a résznél a program elkészítése az, amire több időt kell fordítani.
* VÁLTOZÁSOK:
** A szekelton beadását követően előszeretettel csinálnak valami módosítást a feladat kiírásában (erről emailben értesítenek mindenkit). Általában ez olyan változás, amit jól elkészített modell esetén könnyű elkészíteni. A következő dokumentum elején ezeket a változásokat meg kell jeleníteni, azaz célszerű egy összefoglalást írni a változásról, majd utána a módosított/új osztály és szekvencia diagramokat kell elhelyezni a dokumentumban.
* 7. Prototípus koncepciója:
** 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 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.
** 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.
* 8. Részletes tervek:
** Az előző rész részletezéséről szól ez a dokumentum.
** Az osztályok leírása nagyrészt csak copy-paste a korábban beadott leírásokból.
** Tesztek részletes terveinél az előző dokumentumban definiált nyelvnek megfelelően kell megfogalmazni. Ajánlott tesztenként külön txt-be gyűjteni (főleg a bemenetet), mert később jól fog jönni.
* 10. Prototípus beadása:
** A második blokk vége ez a doksi, úgyhogy ismét kell bele értékelést rakni.
** A dokumentum kitöltése nagyjából értelemszerű, hasonlít az előző ilyenhez.
** Tesztelési jegyzőkönyveknél ajánlott nem csak sikereseket belerakni (mindegyik definiált teszthez kell lennie sikeresnek), hanem egy-két hibás is legyen, hogy látszódjon, hogy van értelme a teszteknek, meg az azért valószínű, hogy elsőre úgysem volt hibátlan a kód, és ez látszódjon a dokumentációban is.
** Teszt bemeneteket ajánlott txt formátumban is mellékelni a beadásnál, mert a tesztelést végző csapatnak nem túl kellemes élmény lehet mindent kézzel beírni.
** A programnak működnie kell úgy is, hogy a bemenetét szöveg fájlból kapja, azaz parancssorban a mellékelt txt fájlokat beleirányítjuk. (nem fájlbeolvasó függvényekre kell gondolni)
* 11. Grafikus felület specifikációja:
** Java Swing-ben kötelező gondolkozni, JavaFX-et el kell felejteni!
** Grafikus interfésznél ajánlott szövegesen leírni, hogy a funkciót hogyan képzeljük el, és néhány (akár paint-ben készült) képpel illusztrálni.
** Felület működési elvénél meg kell fogalmazni, hogy a grafikus megjelenítésért felelős osztályok és a modell osztályok között milyen jellegű kapcsolat van. Alapvetően mindegyik osztályhoz tartozik egy csomagoló/wrapper osztály, amiben a grafikus megjelenítésért felelős kódrészek vannak, de a működésért felelős információk továbbra is a modell osztályban kell maradniuk, azaz az eddig elkészített kódrészekhez nem igazán kell hozzányúlni majd. Alapvetően kétféle megközelítés van: a garfikus rész kérdezi le a modell osztályoktól, hogy hogyan rajzolja ki magát vagy a modell osztályok szólnak, hogy változás történt és rajzold ki magad. A szekvenciáknál az elképzelt elvet be kell mutatni, hogy hogyan fog majd működni, tehát legalább 5-10 diagram kellhet a normális részletezettséghez.
* 13. Grafikus változat beadása:
** Ezzel együtt kell beadni a kész programot is.
** Ismét kell bele értékelést írni a tagok hozzájárulásáról.
* 14. Összefoglalás
** A ráfordított munkaórák alapján a korábban megadott százalékokon akár módosíthat a labvez, hogyha úgy látja, hogy a kettő nincs összhangban.
** A vélemény nem számít bele a kapott jegybe, de azért illik normálisan kitölteni.
(A leírtakért felelősséget nem vállalok, nálunk ezek az elvek voltak igazak, bár tapasztaltuk, hogy labvezenként kisebb/nagyobb eltérés volt, de nincs rá garancia, hogy nálatok is ezek igazak lesznek. Ajánlott laborra úgy menni, hogy előre megnézitek, hogy mit kell a héten csinálni, és akár az itt felsoroltak segítségével kérdéseket fogalmazzatok meg magatokban, és ezekre a kérdésekre a labvezek egyértelmű választ tudnak adni. Csak a doksiban leírt kék szövegek alapján elég nehéz a doksi elkészítése. Tényleg ajánlott figyelni a labor során, mert kellemetlen, amikor másoktól kell információmorzsákat összeszedni, mert éppenséggel senki sem figyelt kellő mértékben a laboron, vagy mindenki másra emlékszik.)

==Feladatok==
{{Rejtett
|mutatott= '''2016/17 tavasz - Vonatos'''
|szöveg=
Sheldon terepasztalt épít vonatjai számára. A terepasztal széleiről időnként vonatok indulnak. Egy vonat egy mozdonyból és valahány kocsiból áll. A kocsikban utasok ülnek, akiket a megfelelő állomásokra kell eljuttatni a megfelelő sorrendben.

A terepasztalon sínek futnak, a vonatok csak a síneken közlekedhetnek. Elágazásoknál a síneket váltók kötik össze. Egy vonat mindig abba az irányba halad tovább, amerre a váltó áll. Bizonyos helyek különlegesek a pályán, ezeken a helyeken egy alagút száját lehet felépíteni vagy megszüntetni. Egyszerre maximum csak két alagútbejárat lehet megépítve a pályán. A két bejáratot egy speciális alagút köti össze, és ha a vonat bemegy az egyik szájon, akkor a másikon jön ki. Az alagút lehet rövidebb is, mint a vonat hossza, és a vonat alagútban lévő része nem látható.

A sínek mellett különböző színű állomások lehetnek. A vonatok kocsijainak is van színe, és amikor egy vonat egy állomáson átrobog, az állomáson csak azok az utasok ugranak le, akik ugyanolyan színű kocsiban utaznak, mint amilyen az állomás színe. A kocsik azonban csak a mozdonytól kezdődő sorrendben ürülnek ki. Tehát hiába ér a vonat egy olyan állomásra, amely megegyezik az utolsó kocsi színével, az utasok nem fognak onnan leszállni, amíg a korábbi kocsik még nem ürültek ki.

A játékos a váltókat tudja állítani, illetve alagútszájakat tud építeni vagy megszüntetni. A játék célja, hogy minden utas eljusson a megfelelő állomásra anélkül, hogy a vonatok egymással összeütköznének. Ha két vonat összeütközik, a játékos veszít. Miután egy terepasztalt sikerült teljesíteni, a játék a következő pályával folytatódik.

'''Módosítás'''
# Sheldon új pályaelemet, kereszteződő síneket vásárolt. A kereszteződés egyszintű, a különböző irányokból jövő vonatok a kereszteződésben ütköznek.
# Egyes állomásokon utasok a megfelelő színű üres kocsikba (a kocsi szerelvényben elfoglalt helyzetétől függetlenül) fel tudnak szállni.
# Sheldon bővítette a vagonkészletét. Vett szeneskocsikat, amiken nem utaznak utasok, nem is tudnak felszállni. Az utasok leszállásánál az ilyen vagonokat nem vesszük figyelembe.

A változásokkal kapcsolatos modellmódosításokat már a március 27-ei, Prototípus koncepciója c. beadandó anyagban is figyelembe kell venni. Az anyagnak legyen egy 0. fejezete, ami tartalmazza a módosítással kapcsolatos szöveges elemzést, a frissített osztálydiagramot, valamint a fenti pontok sorrendjében a módosult és új szekvenciadiagramokat.
}}

==Befejezett projektek galériái==
* [[Szoftlab4_Kindergarten_galéria_2006|Kindergarten Galéria 2006]]
* [[SzgLab4Galeria2008|SnakeFarm Galéria 2008]]
* [[SzgLab4Galeria2010|Bankrabló Galéria 2010]]
* [[SzgLab4Galeria2012|Continuity Galéria 2012]]
* [[Szoftlab4_AntFarm_galéria|AntFarm Galéria 2013]]
* [[Szoftlab4_Két_Torony_galéria|Két Torony Galéria 2014]]

==Csapattoborzás==
Ha nincs csapatod, [https://lists.sch.bme.hu/wws/arc/szoftlab4 levlistán] érdemes szóvá tenni, a legkönnyebben ott lehet csapatot verbuválni. Mivel a csapatban mindenképpen szükség lesz jó kóderre, dokumentálóra, érdemes az ilyen jellegű igényeket is beleírni a toborzó emailekbe. Viszont azt, hogy ''szeretném elvégezni a tárgyat'', lehetőleg ne, hisz én még nem találkoztam olyan emberrel, aki azért vette föl, mert ''nem'' szeretné elvégezni. ([[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 21:32 (CET))

{{Lábléc_-_Mérnök_informatikus_alapszak_2014}}
{{Lábléc_-_Mérnök_informatikus_alapszak}}

VIK Wiki - Felhasználó közreműködései [hu]

Szoftver projekt laboratórium