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ő tapasztalatokkal 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, illetve 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 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.

<?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).

<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:

validate
generate-sources
process-sources
generate-resources
process-resources
compile
process-test-sources
process-test-resources
test-compile
test
package
install
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.

1	`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.

A gyakorlati órán a CodeMetropolis projektet fejlesztjük tovább. A CodeMetropolis egy több éve futó projekt, amelyet sok fejlesztő fejlesztett már. Mivel sok fejlesztő dolgozik a projekten ezért elkerülhetetlen, hogy kialakuljanak szabályok amit minden fejlesztőnek be kell tartania annak érdekében, hogy a projekt egységes és karbantartható maradhasson.

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. A CodeMetropolisnak github repositoryja és weboldala is létezik. Mindkét helyen található dokumentáció, így érdemes mindkettőt szemügyre venni. Érdemes a weboldalon lévő bevezetéssel/rövid leírással kezdeni, így megtudhatjuk, hogy mit is csinál a program. A CodeMetropolisnál olyan szerencsés helyzetben vagyunk, hogy van bemutató videó. Mivel az emberek nagy része vizuális típus, így sokat segít a program működésének megértésében ha látja az ember működés közben. Nyílván ez nem minden programnál megvalósítható pl. library, ebben az esetben a dokumentáció írójának példákat kell felsorolnia amelyek segítik a megértést és használatot.

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

A CodeMetropolis egy szoftver vizualizációt megvalósító program csomag
A CodeMetropolis a Minecraft játékra épül
Város metafórát használ
Az épületek fizikai tulajdonságai megfelelnek kód metrikáknak
GNU GENERAL PUBLIC licence-szel rendelkezik

Tehát a CodeMetropolis egy Minecraft világot fog generálni, amelyben az elemzett szoftvert vizualizáljuk városként. A városban található épületek tulajdonságai megfelelnek a kód tulajdonságainak (metrikák). Továbbá megtudtuk azt is, hogy ez egy command line tool, amely a SourceMeter által generált gráfot olvassa be. Viszont bármilyen szoftver elemző programot használhatunk amely gráfot állít elő. A leírásból az is kiderül, hogy 1.8-as Java verziót kell feltelepítenünk, illetve, hogy Maven build rendszert használ. A repositoryn az is látszódik, hogy a develop branch a karbantartott branch amely tartalmazza a legfrissebb fejleszteseket.

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/

A CodeMetropolis github repositoryjban a linken érhető el a licensz. Ennek a leírása a linken található

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.

A CodeMetropolis esetében ez az about oldalon található meg a Contribution guide fejezet alatt. A gyakorlaton megvalósítandó issue esetében is ezek alapján kell eljárni, azaz új branchet kell létrehoznunk, viszont ezt a gyakorlathoz tartozó GitLab oldalon kell megtennünk, majd készítenünk kell egy Pull Requestet, amely az oldalon említett patchet tartalmazza.

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?)

A CodeMetropolis hivatalos oldala a linken érhető el. Az előző fejezetben már esett szó a szoftver céljáról és használatáról. A repository oldalán található Releases fül alatt találjuk az előre lefordított csomagot amellyel használhatjuk a programot.

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. A CodeMetropolis esetében ezek a szabályok a link alatti Contribution guide fejezetben található.

Hol található a forráskód? (Milyen verziókövetőt használ?)
- Git, SVN, stb.
- A gyakorlaton lévő beadandó (CodeMetropolis) gitet használ.
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, Discord, Messenger, . . .

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, . . . ?

A CodeMetropolis maven alapú, ezért a korábban említett módon tudjuk lebuildelni, azaz a mvn clean package parancsot használjuk. A toolchain négy komponensből áll, amelyek a converter, mapping, placing, rendering. Továbbá láthatjuk, hogy a program Java nyelven íródott.

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: 2023-02-03 13:52:41