Kihagyás

Implementáció

Az implementáció a tervezést követő folyamat. A tervezés során megtörténik a feladatokra bontás, valamint az egyes feladatokban érintett funkcionlitás és szerkezet modellezése. Az implementáció során a modellekből készítünk működő, futtatható kódot.

Az implementáció jellemzően egyéni tevékenység, de létezik az un. pair programming módszertan, mikoris konkrétan két programozó dolgozik egy feladaton ugyanazon munkaállomás előtt. Ennek a módszernek az az előnye, hogy a jellemzően eltérő taőpasztalatokkal rendelkező fejlesztők eltérő szemlélettel állnak neki egy feladat megoldásának, amely egy komplexebb probléma esetén segít az optimális megoldás megtalálásában, illetőleg egymásnak ötleteket adva egy további az egyéni szemléletektől eltérő harmadik megoldás kidolgozásában. A pair programming nemcsak személyes jelenléttel, hanem online módon is támogatható.

Az implementáció során célunk a működő program előállítása, a fejlesztés és a párhuzamos fejlesztői tesztelés együttesen végezhető folyamat. A hibatűrő alkalmazások fejlesztésére speciális módszertanokat is definiáltak, mint az Extreme programming vagy a Test-driven development.

Projektek buildelése

A fejlesztés során le kell tudnunk buildelni az adott projeket. A build folyamat általában összetett tekintettel arra, hogy a az aktuális projekt jellemzően több komponensből tevődik össze. Az újrafelhasználható komponensek egy függőségi fát alkotnak, a projekt csak abban az esetben fordul, ha ezeket a függőségeket feloldjuk, azaz a projekt által érintett library-ket, csomagokat elérhetővé tesszük a build rendszer számára. Ez nem mindig triviális, tekintettel arra, hogy az általunk akár black box módon használt csomagoknak további függőségeik is lehetnek. Az újrafelhasználás legnagyobb problémája egyébként az, hogy az általunk készített szoftver hibáját olyan komponens is okozhatja, aminek a létezéséről sem tudunk.

Az elmondottakat szem előtt tartva a build folyamat támogatására számos keretrendszert hoztak létre.

Ant

Az Apache Ant a C/C++ Make eszközéhez hasonló Java projektek buildeléséhez alkalmazott eszköz. A build konfigurációt egy XML alapú fájlbanm, a build.xml-ben kell beállítani.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
<?xml version="1.0"?>
<project name="Hello" default="compile">
    <target name="clean" description="remove intermediate files">
        <delete dir="classes"/>
    </target>
    <target name="clobber" depends="clean" description="remove all artifact files">
        <delete file="hello.jar"/>
    </target>
    <target name="compile" description="compile the Java source code to class files">
        <mkdir dir="classes"/>
        <javac srcdir="." destdir="classes"/>
    </target>
    <target name="jar" depends="compile" description="create a Jar file for the application">
        <jar destfile="hello.jar">
            <fileset dir="classes" includes="**/*.class"/>
            <manifest>
                <attribute name="Main-Class" value="HelloProgram"/>
            </manifest>
        </jar>
    </target>
</project>

A fenti példában egy egyszerű build.xml felépítését láthatjuk. Az egész szerkezet un. célok (targetek) felépítésére épül. A targetek a buildelés során az ant paraméterei, amelyeket megadva az adott célhoz definiált folyamatok futnak le (hasonlóan a make-hez). A célokon belül XML tagekben adjuk meg az elvégzendő műveleteket:

  • xml <delete dir="classes"/> classes megnevezésű könyvtár törlése
  • xml <delete file="hello.jar"/> hello.jar fájl törlése
  • xml <mkdir dir="classes"/> classes nevű könyvtár létrehozása
  • xml <javac srcdir="." destdir="classes"> Java compiler hívása, a forrásfájlok az aktuális könyvtárban vannak, míg az elkészült class fileok a classes könyvtárba kerülnek
  • xml <jar destfile="hello.jar">, ami az elkészítendő csomagot definiálja. Ennek további paraméterei a classokat tartalmazó könyvtár, valamint a manifest elem definiálása.

Maven

Az Apache Maven szoftverfejlesztés build folyamatainak automatizálására került kifejlesztésre. Plugin alapú architektúrára épül. A függőségek feloldásában képes a hiányzó csomagokat az Internetről letölteni és telepíteni a build folyamata alatt. A projekt leírása a POM.XML fájlban található (Project Object Model).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
<project>
  <!-- model verzió mindig 4.0.0 a Maven 2.x POM-oknak -->
  <modelVersion>4.0.0</modelVersion>

  <!-- projekt koordináták, olyan értékek csoportja amely egyedileg azonosítja ezt projektet -->
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0</version>

  <!-- könyvtár függőségek -->

  <dependencies>
    <dependency>
      <!-- szükséges könyvtárak -->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <!-- ez a függőség csak a tesztek futtatáshoz és fordításához használatos -->
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

A projekt definiálása során a feladatunk gyakran a függőségek szakasz (dependency) kitöltése. Itt meg kell adnunk a package nevét és verzióját, esetenként egyéb információkat is, mint a pédában a scope. A függőségeket az online Maven repository-k alapján oldja fel a rendszer, nekünk csak hivatkozni kell rájuk a POM.XML-ben.

Az alábbi ábrán a maven által automatikusan generált könyvtárszerkezetet mutatja: kep

Egy Maven projekt életciklusa az alábbi célokból tevődik össze:

  1. validate
  2. generate-sources
  3. process-sources
  4. generate-resources
  5. process-resources
  6. compile
  7. process-test-sources
  8. process-test-resources
  9. test-compile
  10. test
  11. package
  12. install
  13. deploy

Prancsorban minden cél egymást követően futtatható. Pl. a compile : mvn compile módon.

Gradle

A Gradle hasonlóan projektépítő eszköz, azonban a konfigurációra nem XML-t, hanem Groovy alapú doménspecifikus nyelvet használ. Alkalmas alprojektek kezelésére is. A konfigurációt a build.gradle fájl tartalmazza.

apply plugin: 'java'

A fenti példa a legegyszerűbb build.gradle állományt mutatja, ahol megadjuk az érintett nyelvet, ami a Java. Ezt követően a gradle build paranccsal buildelhetjük a projektünket.

Függőségek hozzáadásához a következőképpen járhatunk el:

repositories { 
    mavenCentral() 
}

A fenti példában a Maven repository-t használjuk.

3rd party függőségek hozzáadásához a következő szintaxist használjuk:

sourceCompatibility = 1.8
targetCompatibility = 1.8

dependencies {
    implementation "joda-time:joda-time:2.2"
    testImplementation "junit:junit:4.12"
}

Látható, hogy két függőség is megadásra került, egy az implementációhoz és egy a unit tesztekhez.

Jar előállításához definiálni kell magát a jar állományt is:

jar {
    archiveBaseName = 'gs-gradle'
    archiveVersion =  '0.1.0'
}

Ebben a példában gs-gradle-0.1.0.jar fájl fog elkészülni.

Egy összetettebb példa:

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'application'

mainClassName = 'hello.HelloWorld'

// tag::repositories[]
repositories { 
    mavenCentral() 
}
// end::repositories[]

// tag::jar[]
jar {
    archiveBaseName = 'gs-gradle'
    archiveVersion =  '0.1.0'
}
// end::jar[]

// tag::dependencies[]
sourceCompatibility = 1.8
targetCompatibility = 1.8

dependencies {
    implementation "joda-time:joda-time:2.2"
    testImplementation "junit:junit:4.12"
}
// end::dependencies[]

// tag::wrapper[]
// end::wrapper[]

A Gradle build eszközről részletesebb leírás olvasható a következő linken: https://gradle.org/

Hogyan kapcsolódjunk be egy open source projekt fejlesztésébe?

A gyakorlatban többször előfordulhat, hogy nyílt forráskódú szoftver fejlesztésébe kapcsolódunk be. Az ilyen projektek esetében több olyan tényezőt figyelembe kell venni, amely jelentősen eltér egy klasszikus ipari projekttől vagy egy zöldmezős fejlesztéstől. A legnagyobb nehézség talán az, hogy egymást személyesen nem feltétlenül ismerő fejlesztőknek kell együttműködniük. Az együttműködés csak közös szabályok mentén lehetséges, azonban ezeket a szabályokat maguk a közösségek alakítják ki és projektről projektre eltérhetnek.

Dokumentáció megismerése

Az első lépés, amit tehetünk, hogy magát a projektleírást elolvassuk, majd a rendelkezésre álló dokumentációt is tanulmányozzuk.

Mit tanultunk a leírásból és a dokumentáció elolvasásából?

  • ez egy library, azaz nem egy standalone program, hanem a saját kódunkban tudjuk felhasználni.
  • adatbázis elérésre és feldolgozásra is van lehetőségünk
  • Apache2 licence → „nem ragadós”
  • „szabvány” amit más szolgáltatók valósíthatnak meg

Bármit lehet tenni nyílt forrású rendszerrel?

Felmerülhetnek a következő kérdések az emberben, amikor egy Open-Source kódot vizsgál:

  • kereshetek vele pénzt?
  • ragadós? bezárható?
  • módosítható?
  • újra kiadható?
  • stb

A licensz olyan dokumentum, amely részletesen szabályozza egy adott szoftver, vagy más szellemi termék használatára vonatkozó feltételeket, utal a szerzői jog tulajdonosára, illetőleg részletezi a felhasználó (licensz tulajdonos) részére biztosított jogokat, valamint azok korlátait. Klasszikus esetben a szoftvertermékeket egyedi licensszel látnak el, amelyek un. proprietary licenszek. Ezek a felhasználók számára jellemzően csak használati jogokat biztosítanak, általában nem teszik lehetővé a használt technológia, a forráskód megismerését, sőt kifejezetten tiltanak minden visszafejtésre irányuló tevékenységet. A proprietary licenszek gyakran kizálógaos használati jogot biztosítanak a licensz birtokosának, azaz a licensz továbbadását csak kivételes esetben engedik. Jellemzően egy biztonsági másolat készítését szokták engedélyezni az adott szoftver esetében.

A nyílt forráskódú licenszek a kód, a technológia megismerését alapjogként biztosítják. A nyílt forráskódú termékek esetében a működő kód mellé annak forrását is megkapjuk, azt szabadon módosíthatjuk és terjeszthetjük. A licenszek azonban itt is megkövetelik a szerzők jogainak tisztletben tartását, tehát a forráskód szerzői továbbra is változatlanok, a forráskód módosításával az eredeti kód elérhetőségét továbbra is biztosítani kell. A nyílt forráskódú licenszek tehát a korlátozások helyett inkább szabadságjogokat biztosítanak, de nem mentesek a korlátozásoktól. A General Public Licence (GPL) esetében, amennyiben a projektünkben ilyen licensszel ellátott kódrészt használunk, úgy a teljes termékünknek is a GPL alá kell esnie. Azaz nem lehetséges, hogy részben nyílt, részben zárt forráskódú termékünk legyen, így a GPL csak ritkán használt az ipari projektekben. Vannak viszont olyan licenszek (Apache, MIT, stb.), amelyek ezt nem követelik meg, tehát lehetővé teszik a forrásunk egyes részeinek eltérő licenszelését is. Fontos szempont tehát minden nyílt forráskódú rendszer esetén a licensz típusának megválasztása.

Fontos megemlíteni, hogy az open source nem azonos a free szoftverrel. A nyílt forráskód csak annyit jelent, hogy a forráskódot nem zárhatjuk el az felhasználó előtt, ettől még egy ilyen termék is lehet fizetős, sőt proprietary licenszelésű szoftver is lehet ingyenes.

A nyílt forráskódú szoftverek licenszelésének rejtelmeiről itt olvashatsz: https://opensource.guide/hu/legal/, illetőleg a következő linken is hasznos információkhoz juthatsz a jogi szabályozás kérdéseiről: https://choosealicense.com/

Közösség szabályai

Ha mégis arra adjuk a fejünket, hogy belevágjunk egy Open-Source program fejlesztésébe érdemes utánna néznünk a szabályoknak amelyeket követnünk kell. Ez a dokumentum az alábbi kérdésekre adhat választ:

  • Ki küldhet be módosításokat?
  • Ki ellenőrzi a beküldött kódot?
  • Milyen minőségűnek kell lennie a kódnak?
  • Hibák javítása? Tesztelés?

Általában egy külön wiki oldal van ennek dedikálva, de előfordulhat, hogy nem találjuk meg ezt. Ezesetben ne habozzunk e-mailt küldeni a fejlesztőknek, hiszen nagy valószínűséggel szívesen válaszolnak a kérdéseinkre.

Hogyan kezdjünk neki?

Ismerkedés a projekttel

  • Mi a hivatalos oldal? (Mire való a szoftver?)
  • Hol található a dokumentáció?
    • Tutorials, Getting started, First steps, . . .
    • referencia dokumentáció
    • Javadoc
  • Van-e előre fordított csomag? (Milyen fordítási rendszert használ?)

Hozzájárulás a projekthez

Ha később PR-t (azaz Pull Request-et) akarunk indítani, tehát a fejlesztésünket az eredeti repository részeként akarjuk tudni, akkor érdemes már a fejlesztés előtt megkeresni, hogy milyen szabályokat érdemes betartanunk.

  • Hol található a forráskód? (Milyen verziókövetőt használ?)

    • Git, SVN, stb.
    • A gyakorlaton olyan programok lettek összeválogatva amik csak gitet használnak.
  • Milyen szabályokkal lehet hozzájárulni a projekthez?

    • Community → Contribution/Developer Guide
    • Általában létezik leírás ami alapján kódolnunk kell, de ha nem találjuk érdemes lehet keresni a repository tulajdonosát
  • Hol tartják számon a hibákat és változásokat?
    • Jira
    • GitHub/GitLab issues
    • Redmine
  • Kitől tudok kérdezni?
    • Felhasználói levelező lista
    • Fejlesztői levelezői lista
    • Slack, Twitter, Messanger, . . .

Ismerkedés a forráskóddal

  • Hogyan lehet lefordítani a projektet?
  • Milyen fordítási rendszert használ?
    • Maven, Gradle, Ant stb.
    • Docker
    • egyedi build szkript
  • Milyen programozási nyelveken íródott?
    • Java, C#, C++, . . . ,
    • XML, JSON, . . . ,
    • Bash, Batch, PowerShell, . . .
  • Hogyan épül fel a projekt?
  • Milyen modulokból áll?
  • Milyen rendszer architektúrát követ?
    • Model-View-Control, Pipe and Filter, . . . ?

Demonstráció

Az órához kapcsolódó projekt demonstrációs feladat itt érhető el.

Feladat

  • Alkalmas build keretrendszert választva buildeljük le a projektünket!
  • Ismerjük meg a projekt által fejlesztett termék licenszét!

Utolsó frissítés: 2022-01-13 12:46:16