Mobil programozás

Java ME

A mobilprogramozás egyre fontosabb ágazata a szoftverfejlesztésnek, hiszen manapság már mindenki zsebében ott lapul egy egyszerű mobiltelefon, okostelefon vagy PDA, amelyek szolgáltatási köre egyre csak bővül. Ez alkalommal a Java alapú mobiltelefonok és okostelefonok programozásának alapjait vettük szemügyre.

Programozási nyelv és fejlesztőkörnyezet

Java ME – A Java nyelv mobiltelefonokra optimalizált változata. Honlap: http://java.sun.com/javame/index.jsp

NetBeans – Ingyenes integrált fejlesztőkörnyezet. Több változatban is elérhető. A Java ME-t támogató változat több mint egy tucat mobiltelefon emulátorral tölthető le. A mobilszoftverek fejlesztése ezzel az eszközzel a leg kényelmesebb, kezdők számára is kiváló választás. Honlap: http://netbeans.org/

Eclipse – Szintén ingyenes integrált fejlesztőkörnyezet – talán a legismertebb is. A Java ME-t csak a megfelelő plugin letöltése után támogatja. Emulátorról is külön nekünk kell gondoskodnunk. Honlap: http://www.eclipse.org/
http://eclipseme.org/

Platformok

Egy új Java ME projekt indításakor választhatunk, hogy milyen platformra szeretnénk fejleszteni. A két alapvető platformtípus, amely közül választanunk kell a CLDC és CDC, ám ezeken kívül opcionálisan választhatók egyéb függvénykönyvtárak is a projekthez. Természetesen minél “hájasabb” projektet indítunk, annál több funkciót fogunk tudni elérni: RMS, BlueTooth, multimedia, stb., ám annál nagyobb helyet fog követelni magának az alkalmazás a készülék memóriában.

Connected Limited Device Configuration (CLDC)

Korlátozott erőforrásokkal bíró eszközök programozására optimalizált platform. Kevés memóriával, rövid akkumulátor idővel és korlátozott grafikai képességekkel rendelkező eszközök fejlesztésére alkalmas. Ide tartoznak az egyszerű, Java alapú mobiltelefonok is, habár ezek képességei egyre inkább nőnek.

Connected Device Configuration (CDC)

Komolyabb erőforrásokkal bíró, többfajta hálózati kommunikációra is képes eszközök fejlesztésére optimalizált platform. Ilyen eszközök a PDA-k, és okostelefonok, és sokminden egyéb.

Mobile Information Device Profile (MIDP)

A Java ME nyelv egyik kulcs eleme a Mobile Information Device Profile (MIDP) csomag, amely a CLDC platformmal kombinálva hasznos szolgáltatásokat nyújt napjaink modern mobiltelefonjainak programozásához, kihasználva azok minden képességét.

Record Management System (RMS)
A MIDP platform által nyújtott újabb platform, amelynek segítségével adatokat tárolhatunk a mobil eszközökön, azok belső memóriájában úgy, hogy az adatok kikapcsolás után is megmaradjanak. Az RMS egy egyszerű, rekord orientált adatbázisnak fogható fel, amelyben mindössze egyetlen tábla van, és a táblának egyetlen oszlopa, viszont végtelen sok sora. Ezekben a sorokban tetszőleges adatot tárolhatunk bájtsorozat formájában.

Android OS

· Az Android 2.2 operációsrendszer szoftver architektúra rétegeinek a rövid ismertetése:

• alkalmazás réteg: Java nyelven elkésztett Android alkalmazások
• alkalmazás keretrendszer: a fejlesztők számára elérhető erőforrás kezelők és különböző menedzserek
• C/C++ könyvtárak
• futtató környezet (Android Runtime): az alkalmazásokat futtató Dalvik virtuális gép
• Linux kernel: vezérli az Android alap szolgáltatásait, mint a biztonság, a memória-, a folyamatmenedzsment és a hálózatkezelés

A HTC Dream telefon hardver architektúrája

• obe és kiviteli interfészek bemutatása
  • kapacitív érintőkijelző
  • QWERTY billentyűzet
  • trackball
  • gyorsulásmérő

· Andriod alkalmazásfejlesztés alapjai

• fejlesztőkörnyezet
  • ingyenes Eclipse bővítmény áll rendelkezésre
  • a telefonon is lehet hibakeresést végezni
• építő komponensek bemutatása:
  • aktivitások
  • szervizek
  • tartalomszolgáltatók
  • szórt üzenet fogadók (Broadcast receiver)
• aktivitások életciklusának ismertetése

Téma: RPC, MQ, WEBSERVICE

Témafelelős: Matyi

Folyamatok közötti kommunikáció

A folyamatok közötti kommunikáció, azaz Inter-Process Communication(IPC) a különbözõ, úgynevezett címterek között biztosít kapcsolatot. Ezek a címterek jelenthetnek ugyanazon, vagy két külön gépen futó szálakat, folyamatokat. Az 1967-ben elfogadott RFC707-es "High level framework for network-based resource sharing" nevû definícíóban már ezen kapcsolat alapjai írják le. Mint minden kommunikáció alapfeltétele, a közös nyelv, az IPC esetén is elengedhetetlen. A közös nevezõt az Interface Definition Language (IDL) segítségével határozzák meg és mivel a különbözõ típusú adatok egységes reprezentációja is szükséges, így ehhez egy External Data Representation (XDR) leírás is tartozhat.

• Tehát az IPC lehet:
  - helyi: LPC ún. Local Procedure Call, ami egy csak Microsoft Windows NT kernelek esetén alkalmazott hívás típus
  - távoli: Remote Procedure Call, továbbiakban ezt tárgyaljuk.
• Elsõ implementációk:
   - UNIX: DCE/RPC
   - Microsoft: MSRPC/DCOM

Az RPC-vel kapcsolatos alapvetõ jellemzõk:

• Szinkron vagy Aszinkron módon megy végbe, vagyis blokkolja-e a hívó szálat, vagy sem. Aszinkron hívás esetén fellép bizonyos callback esemény, illetve ez valamilyen -mondjuk kommunikációs- hiba folytán el is maradhat: elveszik a kérés, vagy a válasz a kommunikációs hálózaton
• Konkurencia: Ha a hívás egy távoli erõforrás használatára irányul, akkor valamilyen módon kezelni kell az esetleges konkurens kérések kezelését: ez történhet a kérés elutasításával, vagy várakozásra kényszerítésével.
• Átviteli közeg: Függ a folyamatok címtereinek elhelyezkedésétõl, átviteli közegnek tekinthetõ két gép között egy RS232 kapcsolat, vagy akár távolabbi gépek esetén az Ethernet.
• Biztonság: Egyfelõl itt felmerülhet akár a hívó, akár a kiszolgáló oldal kétséget kizáró, egyértelmû azonosítása, mely történhet bizonyítványok, vagy azonosító-jelszó páros segítségével, ez tulajdonképpen része az autentikációs folyamatnak. Másrészrõl a kommunikáció titkosítása jelenthet nagyobb biztonságot. Lehetséges a hívást lehetõvé tevõ kommunikációs közeg titkosítása, vagy magának a hívást leíró kérés titkosítása, vagy ezek kombinációja.
• Kliens oldali stub: Olyan kód-csonk, amely lehetõvé teszi a távoli eljárások hívását, nagyon hasonlóan mintha lokálisak lennének.

RPC analógiára épülõ megoldások:

• JAVA RMI (Remote Method Invocation): elsõsorban JVM-ek közötti kommunikáció
• XMLRPC: a Simple Object Access Protocol (SOAP) elõdje, bizonyos korlátozásokkal
• Pyro: python nyelvû implementáció. Az objektumok pár sorral kiterjeszthetõk és használhatók távoli eljáráshívásra.
• CORBA (Common Object Request Broker Architecture): célja az volt, hogy architektúrától és nyelvtõl függetlenül lehetõvé tegye az eljáráshívásokat, minezt úgy, hogy gyakorlatilag mindenhez külön implementációt készítettek. Brokerek kezelik az üzeneteket.
• MQ (Message Queueing): Bár ez nem RPC megoldás, mégis gyakran közvetítenek rajt olyan kéréseket, amelyek távoli erõforrás elérésére irányulnak. Managerek kezelik az üzeneteket.

JAVA RMI:
Java Remote Method Protocol (JRMP). A protokoll a java.rmi, vagy a sun.rmi csomagok keresztül érhetõ el. Érdekesség, hogy 5-ös java elõtt a stubokat egy külön fordítóval kellett fordítani.
Plusz szolgáltatás, hogy ún. service lookup érhetõ el, amely segíti a hívó számára nem ismert, kiajánlott szolgáltatások felderítését.

XML-RPC:
XML formátumon, valamint HTTP átviteli protokollon alapuló, egyszerú RPC, mely széles körû implementációkkal rendelkezik. Egyszerre csak egy metódus hívható, valamint már támogat a HTTP által biztosított egyszerû autentikációt, vagy HTTPS-en keresztüli titkosítást. Bizonyos esetekben XML helyett, egy másik "lightweight" adatformátumot, a JSON-t is használják.

WebService:
Az XML-RPC-re épülõ szolgáltatás, mely SOAP üzeneteket forgalmaz. Ezek az üzenetek tartalmaznak egy fej elemet, testet, valamint lehetséges MIME objektumokat csatolni. A fejléc tartalmaz üzenet azonosítót, küldõt, fogadót, valamint a hívni kívánt metódus nevét, a test pedig tartalmazza a metódusnak átadandó paramétereket, adatokat. A szolgáltatások leírására az ún. WebService Definition Language (WSDL) áll rendelkezésre, amely akár több Szerviz, Port és Metódus leírását is támogatja egyszerre. Alapvetõen állapotmentes kommunikációról beszélünk RPC esetén, viszont a WebService-hez nagyon hasonló REST interface már biztosít állapotokat. A rest különlegessége, hogy míg a WebService-ek HTTP POST kérésekkel dolgoznak, addig a REST akár a HTTP GET, vagy DELETE kérésekkel is dolgozhat.
A WebService-ek biztonságáért a WebService Security (WSS) felelõs. Itt ugyanúgy lehetõség van a HTTP azonosítás, vagy titkosítás használatára, ezenfelül az XML üzenetet alá lehet írni egy az üzenethez csatolt karaktersorozat segítségével (XML signature), illetve akár titkosítani is lehet ám az XML formátum itt is megmarad (XML encryption).

MQ:
Az MQ biztosan aszinkron módon mûködik, az üzenetek pedig FIFO elv alapján kerülnek kézbesítésre, bár ezt az implementáció nem feltétlenül garantálja. A queue egy gépen helyezkedik el, ezt egy manager kezeli, ehhez csatlakoznak a kliensek. A sorba helyetett üzenetek tartósság szerint lehetnek csak memóriában tárolódóak, lemezre írottak, vagy adatbázisba mentettek. Az üzeneteknek lehet élettartama, ezután törlésre kerülnek. Elõny lehet RPC esetén az üzenetek routolása, illetve a tömeges kézbesítés, amely csak bizonyos számú összegyûlt kérés után kézbesít "burst" szerûen, így egy "költségesen elindítható" erõforrással lehet takarékoskodni.

A különbözõ nyelveken írt RPC támogató framework-ök nagyon nagy terhet vehetnek le a fejlesztõk válláról, kiszolgáló oldalon automatikus IDL generálással, kliens oldalon pedig ezeket beolvasva automatikus stub generálással, valamint magukban foglalják a közegtõl általában független kommunikációs megoldások implementációit.

Téma: DB

Témafelelős: Félis, Csongor
Leírás: ORACLE és MSSQL adatbáziskezelők átbeszélése, alapok tisztázása, valamint egy két érdekes és hasznos kiegészítés view, index, stored producere, indexelt view.

Téma: Tesztelés

Témavezetők: Pali, Krisztián
Leírás:

A Brainstorming témája a szoftvertesztelés volt. A szoftvertesztelés a szoftverfejlesztés egyik kiemelt szakasza, fontosságát az is jelzi, hogy a tesztelési erőfeszítések közel felét ennek a szakasznak a sikerre vitele jelenti. Nyilvánvaló, hogy a megírt szoftver hibátlanságáról és használhatóságáról meg kell győződni, mielőtt azt a megrendelő használatba venné.

A tesztelés általában két szinten zajlik, modul és rendszer szinten, a modulszintű tesztelés esetén a modulokat a teljes rendszerből kiemelve, szeparáltan tesztelik le, míg a rendszerszintű tesztelésnél a teljes rendszert vizsgálják összefüggéseiben.

A tesztelés két fő  típusát különböztetjük meg, ezek a validációs ill. a verifikációs tesztelések. A verifikációs teszt a programozás helyességét, a programírás és tervezés mérnöki folyamatának hibátlanságát vizsgálja, míg a validációs tesztelés a specifikációnak, a felhasználó igényeinek való megfelelést vizsgálja. A kétféle teszt végrehajtása biztosítja, hogy jó minőségű és funkcionálisan megfelelő szoftver készült.

A tesztek elvégzésére általában két utat különböztetünk meg. A fejlesztők általában úgynevezett white box tesztelést folytatnak, míg a tesztelők főleg black vagy iron box tesztelést. A white box tesztelés lényege, hogy a tesztelő belelát a kódba, míg a black box tesztelésnél a tesztelő csak azt tudja, milyen kimenet várható el egy bizonyos bemenet esetén, de a belső funkciók működését nem ismeri.

Ez a két megközelítés egyben a tesztesetek tervezésénél is meghatározó, a white box tesztek tervezésénél strukturális teszteket terveznek, míg a black box tesztelésnél rengeteg technika ismert, például tapasztalaton alapuló, ekvivalencia - partícionálás, határérték-analízis, ok-hatás analízis.

A tesztelési visszacsatolás általában manuális követést jelent, a tesztelés szempontjából ez rendkívül fontos, hiszen ez alapján lehet kiértékelni a tesztelés eredményességét, illetve követni a tesztelési folyamat állapotát.

A manuális tesztelésen kívül léteznek automatizált tesztelési módszerek is. Az automatizált tesztelés eléggé megosztja a tesztelőket, általánosságban elmondható, hogy az automatizált tesztek létrehozása már magában is egy mini fejlesztési folyamat, a tesztelési idő nem csökken az automatizált tesztek esetében, csak a ráfordítás csökkenhet, de ez sem minden esetben.

Téma: Alkalmazásaink, Projektjeink vizsgálata

Témafelelős: Péter

Leírás: A cég álltal fejlesztett alkalmazások felépítése, bemutatása, átbeszélése. Megoldási javaslatok, jövőbeni használatos módszerek átbeszélése.

Téma: Alkalmazások architechtúrája

Témafelelős: Péter

Leírás: Programok, szoftverek, szoftverrendszerek felépítése, tervezési szempontjai. Modulok, rétegek (layers/tiers), interface-ek, facade-ok. Design patterns.

Téma: Hibakezelés

Témafelelős: Krisz, Ákos
Leírás: A hibakezelés szerepe, hibakezelés módszerek és azok hiányosságai az alkalmazásfejlesztés során. Általános fejlesztői, technológiától függetlenített és függősített hibakezés.