5M. Tétel: Programozási technológiák

Verziókezelés, verziókezelő rendszerek.

Verziókezelés:

• A verziókezelés lényege a forráskódot érintő változások megfelelő követése.

• Előnyei:

  • Backup (visszaállítás):

    • A fájlok a szerkesztés közben mentésre kerülnek és bármikor visszaállíthatók.

  • Szinkronizáció:

    • Ha egy szoftveren egynél több ember dolgozik, akkor fontos, hogy folyamatosan a kódbázis legfrissebb verzióját lássák mindannyian.

  • Változások követése:

    • Ahogy a fájlok változnak, az egyes változtatások információkkal láthatók el, leírást adva arról, hogy mit miért tettünk.

  • Felelősség követése:

    • Mivel az egyes változtatások egyértelmű felhasználóhoz/fejlesztőhöz köthetőek, mindig pontosan tudhatjuk, ki és mikor követett el bizonyos változtatásokat.

  • Elágazás (branching) és összefésülés (merging):

    • A kódbázis egy másolatát lemásolhatod egy külön ágba, ahol ott aztán elkülönítve követett változtatásokat hajt végre. Amint elkészült, ezeket a változtatásokat akár össze is fésülheted az eredeti kódbázissal.

  • Alapfogalmak:

    • Repository:

      • Az adatbázis, ami az összes fájlt tárolja nekünk.

    • Working copy:

      • A kódbázis helyi verziója, amin éppen dolgozunk.

    • Revision:

      • Fájlok halmazának egyértelműen azonosítható halmaza.

    • Head:

      • Repositoryban található legfrissebb verzió.

    • Branch:

      • Létrehozásakor másolatot készítünk az egész kódbázisról. Pl: mikor egy új funkción dolgozunk, és ha készen vagyunk vele, akkor akarjuk a projecthez csatolni.

    • Merge:

      • Amikor a funkció elkészült, ezzel a művelettel csatoljuk hozzá.

    • Conflict:

      • Merge közben jöhet létre, hiszen a miénktől függetlenül fejlődő másik ágban akár ugyanazok a fájlok is módosulhattak, amiken dolgoztunk.

    • Resolve:

      • Az ütközéseket vele oldjuk fel.

Verziókezelő rendszerek:

• A verziókezelést a verziókezelő rendszerek valósítják meg.
• Pl: CVS, SVN, GIT.
• Git a legnépszerűbb manapság, okai pedig, hogy ő a leggyorsabb, a rendszer eloszott, nincs szükség központi repositoryra.
• Teljes verziótörténet offline is elérhető minden egyes kliensen.

Szoftvertesztelési alapfogalmak (tesztszintek, teszttípusok, teszttervezési módszerek).

• Tesztelés célja, hogy hibát találjuk és azt rögzítsük.
• Hibák jelenthetők:
  • Kódolás során.
  • Szoftver használata során.
  • Elemzés, tesztelés során.
• Jelenthetjük:
  • Kód hibáit.
  • Futtatott rendszer.
  • Dokumentumok.
  • Követelmény.
  • Felhasználói történet.
• Célja:
  • Tájékoztatás nyújtása.
  • Javaslat.
• Hibajegy tartalma:
  • Leírás.
  • Lépések.
  • Aktuális eredmény.
  • Elvárt eredmény.
• Tesztelési módok:
  • White box testing:
    • Fejlesztőnek a feladata az elvégzése.
    • Olyan szoftver tesztelési módszer, amely során a szoftver (egy komponensének) belső struktúráját, felépítését, implementációját teszteljük. Pl: Unit teszt.
    • Fajtái:
      • Egység tesztelés:
        • legkisebb önállóan működő egységeket teszteli pl: metódusokat adott paraméterrel
      • Integrációs tesztelés:
        • programegységeket, modulokat, azok egymással és a környezettel történő együttműködését teszteli.
        • Az összeillesztés során keletkező hibákat keresi.
      • Rendszer tesztelés:
        • éles környezetben teszteljük, ahogy használni is fogják.
        • Megfele-e a követelmény specifikációnak
        • Funkcionális specifikációnak
        • Rendszertervnek
        • Ez gyakran inkább black boxing teszt.
      • Átvételi teszt:
        • Ügyfél végzi
        • Lehet alfa teszt (fejlesztői cégnél tesztelik, de nem a fejlesztői csapat), béta teszt (végfelhasználók tesztelik, ami lehet nyílt vagy zárt).
    • Előnyei:
      • Fejlesztés korai szakaszában elkezdhető a tesztírás.
      • Kód optimalizálható rejtett hibák kiszűrésével.
      • Le lehet fedni az összes lehetséges tesztesetet.
      • Könnyű automatizálni.
    • Hátrányai:
      • A tesztek nagyon komplexé válhatnak, a teszt írójának magasan képzettnek kell lennie.
      • A tesztek fenntarthatósága nehéz.
      • Programozási tudás szükséges hozzá.
  • Black box testing:
    • Tesztelő feladata az elvégzése.
    • Programozási tudás nem szükséges hozzá.
    • A tesztelő a kódot nem ismeri, nem lát bele a rendszerbe.
    • A hibákat maga deríti fel.

Teszttervezési módszerek:

• Specifikáció alapú technikák:
  • Ezeket a módszerek a teszteseteket közvetlenül a rendszer specifikációjából (modelljéből) vezetik le.
  • Black-box technikának is nevezzük, mivel az egyes szoftver modulok belső szerkezetének ismerete nélkül, az egyes modulok által teljesítendő funkcionalitások alapján tervezhetjük meg a teszteseteket.
• Modell alapú technika:
  • Közvetlenül az UML (egységes modellező nyelv) modellből vezeti le a teszteseteket és formalizált teszt specifikációt alkalmaz.
• Struktúra alapú technikák:
  • Ezek a módszerek a kód ismeretében határozzák meg a teszteseteket. Ez lenne a white-box testing.
• Gyakorlat alapú technikák:
  • A tesztelőknek a munkájuk során megszerzett tapasztalataira épülő, a szakmai intuíciókat is értékesítő technikák.

Objektum orientált tervezési alapelvek (GoF, SOLID).

• GoF (Gang of four), és a négy szerzőre utal, akik a könyvet írták.
  • Címe: az újrahasznosítható objektumorientált szoftver elemei.
  • Maga a könyv 2 részből áll, az első 2 fejezetben az oop által nyújtott lehetőségekről esik és buktatókról esik szó, a többi fejezetben pedig tervezési mintákat mutat be.
  • Szerintük egy jó oop szoftvert tudunk készíteni akkor, ha megfogadjuk a következőket:
    • Programozz interface-re és ne implementációra.
      • Implementációra akkor programozunk, ha az osztály felelősségi körét rosszul határozzuk meg és egy osztály több felelősségi kört is lefed.
      • Ha implementációra programozunk és megváltozik az osztály, akkor a vele kapcsolatban álló osztályoknak is változniuk kell.
      • Ha interface-re programozunk és megváltozik az implementáció, de a felület nem, akkor nem kell megváltoztatni a többi osztályt.
      • Interface karbantarthatóbb.
    • Objektum összetétel az öröklődés helyett.
      • Osztályoknak polimorf viselkedést és a kód újrafelhasználását kell megvalósítania, ahelyett, hogy ősosztályból örökölnének.
      • Az öröklődés egyes esetekben súlyos problémákat okozhat, ha nincs kellő gondossággal implementálva.
      • Pl: gyémántprobléma, mikor egy gyerekosztály örök egy szülőosztálytól, akiknek közös a nagyszülőosztályuk.
      • Előnyök:
        • Az interface-ek használatának előnye, hogy nagyobb fokú flexibilitást nyújt.
        • Sokkal természetesebb az osztályokat különböző komponensekből, mint közös tulajdonságokat keresve felépíteni.
        • Pl: gázpedál és a kormány nagyon kevés közös tulajdonsággal rendelkezik, mégis mindkettő fontos az autóban.
        • Átláthatóbb lesz a rendszer.
      • Hátrányok:
        • Adott komponensek által nyújtott metódusokat implementálni kell az örököltetett osztályban, még akkor is, ha ezek csak a metódusokat továbbítják.
• SOLID ( [S]ingle Responsibility Principle, [O]pen/Closed Principle, [L]iskov Substitution Principle, [I]nterface Segregation Principle, [D]ependency Inversion Principle)
  • Egyetlen felelősség elve, Nyílt/Zárt elv, Liskov helyettesítési elv, Interfész elválasztási elv, Függőségi megfordítási elv.
    • Egyetlen felelősség elv
      • kimondja, hogy egy osztály vagy modul egy, és csak egy felelősséggel rendelkezzen (egy oka legyen a változásra).
    • Nyílt/Zárt elv
      • kimondja, hogy egy osztály vagy modul legyen nyílt a kiterjesztésre, de zárt a módosításra.
    • Liskov helyettesítési elv
      • kimondja, hogy minden osztály legyen helyettesíthető a leszármazott osztályával anélkül, hogy a program helyes működése megváltozna.
    • Interfész elválasztási elv
      • kimondja, hogy egyetlen kliens se legyen rákényszerítve arra, hogy olyan eljárásoktól függjön, amelyeket nem is használ.
    • Függőség megfordítási elv
      • Kimondja, hogy a magas szintű modulok ne függjenek az alacsony szintű moduloktól. Mindkettő absztrakcióktól függjön.

Függőség-befecskendezés.

• Függőségnek nevezzük azt, amikor class A használja class B néhány funkcióját, mivel ilyenkor az A class függ a B classtól.
• A függőségbefecskendezés annak a megnevezése, hogy a függőségek hogyan kapcsolódnak az osztályhoz.
• Dependecy Injection:
  • A függőség kívülről adódik be az osztálynak.
  • Vagyis nem szükséges a new operátor használata a classban, helyette legyen a konstruktornak egy paramétere vagy settere.
• Egy task továbbítása valaki másnak, úgy, hogy ezt egy objektum létrehozásával egyidejűleg tesszük meg, közvetlenül a függőség használatával, ezt nevezzük dependency injection-nek (függőség befecskendezésnek).
• 3 fajtája van:
  • Konstruktor befecskendezés:
    • A függőség a konstruktoron keresztül van biztosítva.
    • Konstuktor paramétere kapja meg az osztály interface-ét.
  • Metodus befecskendezés:
    • Metódus állítja be a függőséget.
  • Interface befecskendezés:
    • A függőség biztosít egy befecskendező metódust, ami befecskendezi a függőséget bármelyik kliensnek, amelynek ez át lesz adva.
• Felelős:
  • Objektumok létrehozásáért.
  • Tudja, hogy melyik classoknak van szüksége azokra az objektekre.
  • És biztosítja számukra azokat az objekteket.
• Használatának előnyei:
  • Segít a unit tesztelésben.
  • Egyszerűbb vele az alkalmazás bővítése.
• Hátrányai:
  • Komplex az elsajátítása.
  • Sok fordítási hiba futási időre tolódik át.

Architekturális minták (MVC).

• Model-View-Controller.
• Gyakori egy alkalmazás több rétegre való bontása, megjelenítés, tartománylogika, adatelérés.
• Az MVC-ben a megjelenítés tovább bomlik nézetre és vezérlőre.
• Jobban meghatározza egy alkalmazás szerkezetét, mint az egy programtervezési mintára jellemző.
• Modell:
  • Az alkalmazás által kezelt információ tartomány-specifikus ábrázolása.
• View:
  • A modell megjelenítése egy megfelelő alakban.
• Controller:
  • Az eseményeket, jellemzően felhasználói műveleteket dolgozza fel és válaszol rájuk.
• Service:
  • A contoller és a modell közötti réteg. A modelltől kér le adatokat és a controller-nek adja.
  • Használata nem kötelező, mivel nem része az MVC-nek.
• Előnyei:
  • Egyidejű fejlesztés (több fejlesztő esetén).
  • Könnyen változtatható.
  • Tesztelhetőség.
  • Több nézet egy modellhez.
• Hátrányai:
  • Kód olvashatósága.
  • Nehezebben tanulható.

Tervezési minták.

• Nevezzük a gyakran előforduló programozási feladatokra adható általános, újrafelhasználható megoldásokat.
• Rendszerint egymással együttműködő objektumok és osztályok leírása.
• Célja, hogy leírást, sablont nyújtson.
• Előnyeik:
  • Lerövidítik a tapasztalatszerzési időt, mivel a legtöbb problémára már van megoldás.
  • Lerövidítik a tervezési időt, mivel az összes minta jól dokumentált, könnyen újrafelhasználható.
  • Közös szótár a fejlesztőket tekintve, megkönnyítve az egymás közötti kommunikációt.
  • Magasabb szintű programozást tesz lehetővé.

Szabad és nem szabad szoftverek.

• A szabad szoftver az olyan szoftver, amelyet a felhasználó:
  • tetszőleges céllal, tetszőleges alkalommal futtathat.
  • Működését tanulmányozhatja, és módosíthatja.
  • Terjesztheti.
  • Ezeket a jogokat a szoftverhez írásban kiadott licencszerződés biztosítja.
  • Nem feltétlenül ingyenes.
• A nem szabad szoftver olyan szoftver, amelyet nem lehet szabadon módosítani és továbbadni.

Szoftverlicencek, szabad és nyílt forrású licencek fajtái.

• A szoftverlicenc:
  • Szoftverek használatának és terjesztésének módját szabályozó jogi eszköz.
  • Nem szabad szoftverek esetén a végfelhasználói licencszerződés kifejezést használják.
• Nyílt forráskódú szoftver nem azonos a szabad szoftverrel.
  • Forráskódnak végig nyíltnak kell maradnia, és be kell tartani a programozás során egy fejlesztési modellt.
• Korlátozott szoftver:
  • Olyan szoftver, amit korlátozottan lehet használni, így nem tekinthető szabad szoftvernek.
    • Pl: trial
• Licenc fajták:
  • Amelyik licenc előírja a licenselés megőrzését a módosított programokra is, copyleft licensnek nevezzük.
  • BSD:
    • Nem követeli meg a módosított kód egészére az eredeti licencet.
  • GNU General Public License:
    • Minden módosításra az eredeti licenc kell, hogy vonatkozzon.