A fejlõdés
A programozás egyszerűsítésének problémája a kód alapkoncepciójával kezdõdött: a programozónak a gép nyelvét - a kódot - kellett használnia, hogy elmondja, mit akar csinálni. A programozó kódja vezérelt minden részletet, ami a hardver fizikai aspektusára vonatkozott. A legelsõ programozási koncepció, ami drámaian csökkentette a programozó terheit, a szimbolikus nyelv volt. Az assemblerek mechanikusan lefordították az ember számára olvasható szimbólumokat a számítógép számára olvasható bináris kódolású utasításokra. A fordítók megkönnyítették a programozó munkáját azáltal, hogy lehetõvé tették a magasabb absztrakciós szintű nyelvek használatát. Ennek ellenére ezeknek a fordításoknak a kimenetét még manuálisan össze kell szerkesztetni, betöltetni, és működtetni.
Az eszközök úgy fejlõdtek, hogy az absztrakció szintjének növelése által javítják a termelékenységet. A cél az volt, hogy lehetõvé tegyék a fejlesztõk számára, hogy az alkalmazáslogikára koncentráljanak, csökkentsék a fizikai környezettel való törõdést és csökkentsék a triviális ismétlõdõ erõfeszítést.
A koncepció: növeld az eszközök terhelését, hogy csökkentsd a programozók terhelését.
Az operációs rendszereket általános célú szoftvermotorként fejlesztették ki, amelyek végrehajtják a programokat, amikor végrehajtható formában tálalják nekik. Ahogy az iparág fejlõdött, olyan relációs adatbáziskezelõ rendszerek (RDBMS-ek) kerültek bevezetésre, amelyek az adatbázis követelményeinek logikai szintű leírásához szükséges eszközök biztosítása által magasabb szintű absztrakciót tettek lehetõvé. Fogalmilag - itt is - az RDBMS egy futtatómodul, egy különleges célú szoftvermotor, amelyet az adatbázis funkcióinak kezelésére terveztek. A következõ termelékenységi elõnyt a negyedik generációs nyelvek kifejlesztésével érték el, amelyek az absztrakció újabb szintjét honosították meg, ahol a programozási erõfeszítést csillapították a képernyõfunkciók és a végfelhasználói beavatkozás, amelyeket magasabb szinten lehet kezelni. Fogalmilag, a 4GL futtatómodul egy különleges célú szoftvermotor, amit kifejezetten a képernyõfunkciók és a végfelhasználói beavatkozás lekezelésére terveztek. Ez a három szoftvermotor a 2. ábrán kerül bemutatásra.
2. ábra: Szoftvermotorok
Magic - Az alkalmazásmotor
Épp az imént láttuk, hogy három egyszerű szoftverproblémára - operációs rendszerek, adatbáziskezelõ rendszerek, és 4GL eszközök - hogyan nyújtott megoldást egy egyszerű, egységesítõ koncepció: a motor.
Felmerül a roppant egyszerű kérdés: kitalálható-e egy olyan motor, ami olyan mértékben csökkenti a programozók terhelését, hogy egy új programozási elvrendszer jön létre aminek olyan drámai elõnyei vannak, hogy az már varázslatnak tűnik? Létrehozható-e egy olyan alkalmazásmotor, ami azokat a platform-függetlenséggel kapcsolatos elõnyöket biztosítja, amelyeket jellemzõen egy virtuális géphez társítanak, ami az alkalmazásfejlesztési termelékenységet nagyságrendekkel képes növelni?
3. ábra: Magic - a motor
Ennek a dokumentumnak a további része igenlõ választ ad erre a kérdésre, majd tovább lép, hogy elmagyarázza nem csak azt, hogy hogyan érhetõ ez el, de a Magic megoldásának az elágazásait is a kor számítógéprendszereinek gyorsan elillanó világában.
Hol van a Magic alkalmazáskódja?
Amióta csak az első generációs fordítóeszközök kifejlődtek, a számítógépes alkalmazás kódjának végrehajtható formája nagyon sokban különbözik attól a formától, amit a programozó bevitt. Akárhogy is, a Magic esetében, az olyan fogalmak, mint a forráskód, lefordított kód, tárgykód, félig lefordított kód, pszeudokód, meta-nyelvi kód, és végrehajtható betölthető modulok, mind elhagyhatók. Ehelyett, a Magic alkalmazások "kódjának" programozó által történő bevitelének formája és a forma, ahogy ezt a Magic alkalmazásmotor számára végrehajtásra tálalja, fogalmilag megegyeznek. Ez egy egyfázisú folyamat, ahol a fejlesztő által bevitt "kód" azonnal végrehajtható a motor által, bármilyen közbülső feldolgozás nélkül.
Fontos megjegyezni, hogy a Magic csökkentette a nyelv szintaxisát, míg megtartotta a szemantika gazdagságát, így megszüntetve az interpreteres nyelvekhez kapcsolódó tipikus lassulást. A Magicben a feldolgozási idő nagy része az alkalmazás különböző funkcióinak végrehajtásával telik. Ezek a funkciók az alkalmazásmotor részeként beépítettek, és erősen optimalizált, natív kódként kerültek megvalósításra. Ugyanakkor, ezek a funkciók elegendően paraméterezettek, így lehetővé téve a fejlesztő számára az alkalmazások széles választékának a leírását.
"A Magicnek jelentős sikerei vannak a komplex, üzletkritikus rendszerek gyors fejlesztésének területén. A kódját már lefordították majd' minden platformra, tehát teljes sebességen fut... Beolvas egy lefordítatlan, bináris kontrollfájlt. A kontrollfájl nyelve annyira sűrített, hogy gyakorlatilag megszüntet minden interpretálással kapcsolatos lassulást futás közben."
Meta Group
A tény, hogy az alkalmazás teljes leírása, beleértve a logikát, az üzleti szabályokat, az űrlapokat és az adatokat, a Magic gyűjtőiben kerül letárolásra (a Magic kontrollfájlja) és a Magic alkalmazásmotor hajtja végre, is hozzájárul a Magic híres fejlesztési sebességéhez.
Az eredmények:
- Az alkalmazás fejlesztési folyamatából teljesen ki vannak iktatva a fordítók és linkerek
- A fordítók és linkerek miatt a hardverbe történő tőkebefektetés megszűnik
- A fejlesztők a funkcionalitásra és az üzleti követelményekre koncentrálhatnak, a kód és az alacsony szintű "hogyan" utasítások helyett
- Egy alkalmazás minden része letesztelhető, amint a leírása bevitelre került, így megtakarítva az egyhangú "szerkesztés-fordítás-linkelés" ciklusokat
- Az alkalmazások végfelhasználói aktívan részt vehetnek a prototípuskészítésben
Gyors alkalmazásfejlesztés és futtatás a maximális termelékenységért
Az utóbbi években látható volt a tervezéshez, fejlesztéshez és az alkalmazások végfelhasználókhoz történő szállításához kötődő hagyományos "vízesés" megközelítés leváltása. Az alkalmazásfejlesztés klasszikus módszerei, mint a "vízesés" módszer, amely a végfelhasználókat a fejlesztés korai szakaszában az igényeik meghatározására kényszerítette, nem biztosította azt a rugalmasságot, amelyre a felbukkanó dinamikus szervezeteknek szüksége van.
A gyors alkalmazásfejlesztés és futtatás (RADD) elvét arra szánták, hogy alternatívát biztosítson az üzleti környezet számára a hagyományos módszerrel szemben, így lehetővé tegye a végfelhasználó bevonását az iteratív prototípus készítési technikák összes fázisában, lásd: 4. és 5. ábra. A tény, hogy minden modern eszköz érvényesíti ezt a megközelítést, bőségesen bizonyítja a hatékonyságát.
4. ábra: A hagyományos alkalmazásfejlesztési ciklus
5. ábra: A Magic gyors, növekményes RADD ciklusa
A Magicben, a RADD megközelítés eléri a legvégsõ kifejezési formát, maximalizálva a végfelhasználó hozzájárulását és az alkalmazással történõ azonosulását, és forradalmasítja a fejlesztõk és a felhasználók közötti kapcsolatot.
"A Magic kódolásmentes, gyors alkalmazásfejlesztő eszköze népszerű az ügyfelek körében a feladatkritikus kliens/szerver és Web-alapú alkalmazások nagy hatékonyságú fejlesztése miatt..."
Datapro Information Services
Egy RADD projekt előnyeinek maximális hasznosításához a fejlesztőknek a megfelelő eszközre van szükségük. A kezdeti koncepciótól kezdve a Magicet a gyors alkalmazásfejlesztés és futtatás támogatására tervezték. A Magic egyedi táblázatközpontú architektúrája elősegíti a fejlesztés egy dinamikus és iteratív megközelítéstét, ahol a felhasználók bevonhatók a fejlesztési folyamatba és láthatják az alkalmazást a szemük előtt fejlődni.
Habár a Magic nincs egy bizonyos életciklusbeli módszertanhoz kötve, a következő rész egy fejlett RADD-módszertant mutat be.
Dinamikus Rendszerfejlesztési Módszertan (Dynamic System Development Method - DSDM) RADD-eszközökhöz
A gyors alkalmazásfejlesztés és futtatás számára az egyik legjobb szemlélet a DSDM. A Magic a független DSDM-konzorcium egyik alapító tagja, szorosan együttműködik a szervezettel biztosítva, hogy a fejlesztési projektek előnyt szerezzenek a leggyakorlottabb RADD-fejlesztők tudásából és közös tapasztalatából.
A Magic és a DSDM kombinációja megszünteti egyszer és mindenkorra az úgynevezett elkerülhetetlen kieséseket.
- erő kontra hatékonyság
- gyors szállítás kontra karbantarthatósági képesség
- könnyű használat kontra funkciógazdagság
- üzleti igények kielégítése kontra telepíthetőségig eltelő idő
A DSDM biztosítja a megközelítést és módszertant a RADD projektkörnyezet számára, beleértve a nagy projekt- és konfigurációkezelő technikákat, irányelveket a kockázat- és erőforrásbecsléshez illetve a minőségi és alkalmassági kérdésekben. Mivel a DSDM módszertan a fejlesztési életciklus korai szakaszában bevonja a végfelhasználókat, valószínűbb, hogy a befejezett project megfelel az igényeiknek és a bevezetés simán fog történni. A módszertan arra szolgál, hogy biztosítsa, hogy a végső rendszer megfelel a szervezetek valódi üzleti követelményeinek, ugyanakkor nagyban csökkenti a talán tökéletes, de teljesen használhatatlan rendszerek építésének kockázatát.
Deklaratív programozás
A deklaratív programozás a programozási szemléletmódok összefoglalására használatos kifejezés, amelyben a programozó erőfeszítései inkább az alkalmazáslogikára összpontosulnak (a mit) mint a megvalósítás részleteire (a hogyan). Különböző tudományos intézetekben jelentős kutatások vannak folyamatban ezen a területen, a meghatározott céljuk, egy mennyiségi ugrás előre az alkalmazásfejlesztési termelékenység területén. Valójában, a Magicet használó fejlesztők által elért hatékony termelékenység tanúsítja a programozás deklaratív szemléletmódjának ígéretének betartását.
A deklaratív programozás az adatbázis-alkalmazás fejlesztés sok fontos aspektusán keresztül az egész Magicben megnyilvánul, beleértve az adatmanipulációt, a formok tulajdonságait, és az eseménykezelést.
"A Magic kiugró erőssége a procedurális programozás iránti igény megszüntetése"
Ovum
Adatbázismanipuláció
Vizsgáljuk meg a kiugró példáját a Magic által felhasznált deklaratív programozásnak, ahogy az az adatbázismanipulációban megnyilvánul.
Az adatbázismanipuláció programozásának egy nem deklaratív megközelítésében, a programozó jellemzően explicit módon ott határozza meg a kódban azt a bizonyos végrehajtandó adatbázistevékenységet, ahol logikailag végre kellene hajtódnia. Ezen tevékenységek közé tartozik egy rekord lekérdezése, egy új rekord hozzáadása, egy meglévő rekord törlése, vagy egy létező rekord módosítása.
A Magicnek azonban nincsenek ilyen jellegű adatbázisműveletek végrehajtására szolgáló parancsai. Akkor hogyan is adható meg és vezérelhető az adatbázismanipuláció?
A legkisebb teljes feldolgozási egység a Magicben az üzleti taszk. Egy üzemmód taszkhoz rendelésével, a Magic alkalmazásmotor megtudja, hogy milyen adatbázisműveletet kell végrehajtania. Az alkalmazásfejlesztő az alkalmazás fejlesztése közben eldönti a taszk végrehajtási módját (Módosítás, Létrehozás, Törlés, vagy Lekérdezés). Az alkalmazásfejlesztő nézőpontjából, a hely, ahol a Magicben deklarálásra kerül, nem kapcsolódik fizikailag ahhoz a helyhez, ahol a tulajdonképpeni logika meghatározásra kerül, értsd: Taszk végrehajtás tábla (Lásd: 21. és 23. ábra a 4. és 5. fejezetben).
Form tulajdonságok
A Magic által erősen használt deklaratív programozás másik kiugró példája a Magic formszerkesztőjénél játszik fontos szerepet. Nincs szükség procedurális kódolásra egy form jellemzőinek a megtervezéséhez és beállításához. Egy tulajdonságablak opciók széles körét biztosítja, ami megszünteti azt, hogy akár egyetlen sor kódot is kelljen írni. A tulajdonságok beállíthatók akár a teljes form szintjén, és a formon belül a vezérlők szintjén is. A Magic újraszámító motorja lehetővé teszi a "röptében" történő frissítéseket, biztosítja a belső konzisztenciát fejlesztői közbeavatkozás nélkül.
A következő példa bemutatja, hogy egy nyomógomb "látható" tulajdonsága könnyen vezérelhető egy kifejezés által, ami az Expression Rules táblázatban található
6. ábra: Egy formon lévő nyomógomb kikapcsolása
Nem kevésbé lenyűgöző a Form Editorból elérhető Variable Palette, amely lehetővé teszi a vezérlőknek közvetlenül az adatstruktúrából történő létrehozását. Az adatmodell és a GUI-n történő ábrázolása közötti közvetlen logikai kapcsolat ábrázolásának lehetővé tétele a Magic által megnövelt termelékenységnek egy másik jelentős megnyilvánulása.
Eseménykezelés
A Magic eseménykezelése még lenyűgözőbb példája a deklaratív programozás Magic által történő támogatásának. A nem procedurális kódolás erejét tanúsítja azzal, hogy programok vagy altaszkok végrehajtását gombnyomáshoz, eltelt időhöz, vagy egy feltétel igazzá válásához köti. Például, a végfelhasználó megnyomhat egy hot-keyt (egy előre definiált, az eseményt elindító gombot) és végrehajthat egy eseményprogramot egy mező szerkesztése közben. Mikor az eseményprogram, vagy az altaszk befejeződik, a végfelhasználó folytathatja a mező szerkesztését ugyanattól a karaktertől, ahova a kurzor mutatott az esemény elindítása előtt.
A Magic adatbázismanipulációra, formtulajdonságaira és eseménykezelésére vonatkozó alapkoncepcióját vázoltuk fel, a Magic által erősen támogatott deklaratív programozás példájaként. Ez az az egyedi, nem procedurális programozás, amely az okos alkalmazásmotorhoz hozzájárulva hatalmas előnyöket biztosít a Magic-fejlesztő termelékenységében.
A relációs táblastruktúrákra alapozott vizuális fejlesztés növeli a termelékenységet
A strukturált formában bemutatott információt könnyebb befogadni és felfogni, mint a strukturálatlan információt. A vizuális úton bemutatott információ sokféle formában jelentkezhet - szöveg, grafika, ikonok. A strukturált információ vizuális bemutatásának egyik példája a táblázat. Az a tény, hogy olyan sok mező oly sok információja jelenik meg táblázatos formában, a legmeggyőzőbb bizonyítéka a táblázatok hatékonyságának mind az információ-előkészítő, mind az információ-felhasználó szempontjából. A táblázatok kiegyensúlyozott mechanizmust biztosítanak a szöveges és numerikus információ strukturált módon történő bemutatásához.
"...a Magicnek ítéljük az Analyst's Choice díjat... Kifejezetten úgy találtuk, hogy egy alkalmazás leíró táblák által történő megépítése körülbelül feleannyi időt igényel, mint a hagyományos procedurális kód megírása."
Peter Coffee, PC/Week
A Magic teljesen kihasználja ezt az alkalmazásfejlesztő számára egy nagyon vizuális és nagyon magas szinten strukturált környezet biztosítása által. Terjedelmes scriptek írása helyett a Magic programozó az információkat egymással kapcsolatban lévő táblázatok sorozatába viszi be. Ez az információ relációs táblák halmazában kerül tárolásra, a redundáns tárolás csökkentésének érdekében, valamint a táblázat elemei közötti kapcsolatok pointerek által történő hivatkozás előnyeinek a legjobb kihasználásának érdekében. Lásd a 7. és 8. ábrát.
7. ábra: Jellemző adatdefiníciós táblák
8. ábra: Jellemző programozási táblák
A Magic elvrendszere hasznosítja az ezekből származó relációs elveket és előnyöket, hogy megdöbbentő termelékenységi előnyöket érjen el a teljes alkalmazásfejlesztési életciklus során. A nyelv alapú vagy script alapú programozási szemléletmóddal ellentétben, ahol minden nevesített egyedre történő hivatkozás explicit, a Magic relációs elveket alkalmaz, hogy a nevesített egyedekre mutató explicit hivatkozásokat pontosan egyre csökkentse - név szerint a táblabejegyzésre, ahol eredetileg meghatározásra került. Minden más hivatkozás implicit, és a táblabejegyzések közötti kapcsolatokon át érhető el. A Magic ötletes szemléletmódja az, hogy mindez teljesen felhasználóbarát és a programozó számára átlátható módon történik. A programozó sosem találja szembe magát pointerekkel. A programozó mindig a nevesített egyedeket látja, ahogy eredetileg meghatározta. Ugyanez vonatkozik az alkalmazás funkcionalitására (logikájára). Az elérhető műveletek (parancsok) és funkciók listája a programozó számára explicit néven kerül bemutatásra. Ezeknek a Magic táblastruktúráján belüli reprezentációja azonban kódból és linkekből áll a tárolás optimalizálására. Egy táblázatvezérelt vizuális fejlesztési módszertannak nagy szétágazásai vannak:
- a mai kor grafikus felhasználói felületei a táblastruktúrákkal történõ munkát gyorssá és hatékonnyá teszik
- a programozási folyamat vizuálissá válik, egyik tábláról a másikra váltva
- az alkalmazás-módosítások automatikusan végigvezetésre kerülnek, akárhol is történjen rájuk hivatkozás; ez egy közvetlen következménye a Magic táblázatos felépítésének relációs szemléletmódjának
- a taszkfa tartalmazza az alkalmazás adatnézetét
- szintaktikai hibák elõfordulása tulajdonképpen lehetetlen, mivel a programozás elõre definiált rendszerbejegyzések vagy elõre definiált táblabejegyzések - amelyek maguk is elõre definiált rendszerbejegyzésekbõl lettek létrehozva - létrehozásából áll
- a script alapú programozáshoz hasonlítva, a programozó által, az alkalmazás leszállításához szükséges bevitt kód mennyisége egy nagyságrenddel csökkent.
Beépített funkcionalitás a Magic alkalmazásmotorjában
A fejlesztőkre nehezedő teher további csökkentésére, maximális végfelhasználói funkcionalitás van a Magic alkalmazásmotorba beépítve, amely alapértelmezés szerint minden alkalmazás és minden végfelhasználó számára elérhető. A következő képernyő (9. ábra) egy tipikus adatképernyőt mutat, az összes Magic alkalmazás számára automatikusan elérhető beépített funkcionalitást tartalmazó legördülő menüvel együtt. A Magic szintén kényelmes mechanizmust biztosít a fejlesztők számára a különböző funkciók dinamikus és feltételes ki- és bekapcsolása.
9. ábra: A Magic beépített végfelhasználói funkciói
"Ez a szemléletmód lehetővé teszi az alkalmazások gyors definiálását, mert az alkalmazáslogika legnagyobb része a Magic-motor részeként automatikusan biztosított."
Ovum
Az előre meghatározott funkcionalitás nagy része az alkalmazásmotorba be van építve, így a programozási erőfeszítések jelentős csökkenése érhető el, mialatt a teljes rugalmasság megmarad Magic "nyelvében", hogy kezelje az alkalmazások nagy többségét.
A Magic alkalmazások robosztussága a beépített funkcionalitás járulékos előnye. A tény, hogy ugyanazt az alkalmazásmotort használják különböző alkalmazások ezrei, magában foglalja azt, hogy a Magic alkalmazásmotor nagyságrendekkel többször lett tesztelve és debuggolva mint egy egyedi alkalmazás.
Az újrafelhasználhatóság növeli a termelékenységet
Az újrafelhasználhatóság a Magic egyik elvrendszerének egyik alapvető koncepciója.
Az újrafelhasználhatóság első szempontja a Magic alkalmazásmotorba van beágyazva beépített funkciók átfogó készleteként, amelyek az adatbázisalkalmazások különlegesen széles skáláját fogadják be.
A programozó anélkül használhatja ezeket a beépített funkciókat, hogy bármilyen kódot vagy scriptet kéne írnia. Ehelyett, a programozónak csupán a beépített funkciók és paraméterek sorozatát kell meghatározni. A Magicben, ilyen meghatározások előre definiált táblázatok kitöltésével adhatók meg. Ez a táblázatvezérelt technika tovább növeli a könnyen használhatóságot és a Magic elvrendszerének általános termelékenységét.
A Magic elvrendszerében az újrafelhasználhatóság második szempontja a programozó által definiált egyedek újrafelhasználása egy önálló Magic alkalmazásban, illetve a Magic alkalmazások széles skáláján. A Magic programok könnyen meghívhatók a Magic alkalmazások között. A programok - egyszeri megírás után - újra használhatók a fejlesztők idejének megtakarítása érdekében.
A harmadik nagyszerű példája az újrahasznosíthatóságnak a Magic űrlap sablonjaiban található. Az űrlap sablonok kiváltják az űrlapok interaktív képernyős megjelenítésének általában unalmas és időpazarló előkészítését.
A programozó számára az olyan kényelmes mechanizmusok biztosításával, mint az űrlap sablon, az egyedek definiálásához és elmentéséhez, a Magic hatékony újrafelhasználhatóságot és hatalmas megtakarításokat tesz lehetővé.
"...Az újrahasználható űrlapok tovább növelik a fejlesztőknek a Magic segítségével elérhető, eddig is magas termelékenységét."
Hurwitz Client/Server Watch
Minél többet használhat fel újra a programozó, annál többet nyer a termelékenység területén.
Az absztrakció csökkenti a kódot
Az adatbázisműveletek meghatározására szolgáló SQL (Structured Query Language - Struktúrált Lekérdező Nyelv) megjelenése előtt, még a legegyszerűbb adatbázisfunkció végrehajtásához is jelentős programozási erőfeszítésre volt szükség.
Egy SQL-parancs megadásának a lehetősége, mint például:
SELECT ALL FROM CUSTOMERS WHERE ZIP=10016
hatalmas előrelépést hozott a programozói tevékenységbe.
A fenti SQL-parancsra gondolhatunk úgy is, mint egy alacsonyabb szintű nyelven létrehozott hosszú utasításszekvencia magas szintű absztrakciójára. Vagy, más irányból nézve, több jelentés (szemantika) lett becsomagolva kevesebb szövegbe (szintaktika). Mindazonáltal, a nyelv alapú (script) programozáshoz kapcsolódó veszteség még mindig megmarad.
Ezek után meg kell kérdeznünk, hogy elérhető-e még nagyobb absztrakció, olyan szintű, ahol a megmaradó veszteség annyira alacsony, hogy a végső alkalmazás végrehajtására történő hatása elhanyagolható. Ha ilyen cél elérhető, szerteágazó hatása az egész fejlesztési folyamatra hatalmas: a programozás egyfázisú folyamattá válik.
Fontos megjegyezni, hogy ha ez a cél elméletileg még el is érhető, nem lesz gyakorlati értéke, ha egy átlagos programozó számára nem tálalható könnyen megérthető, könnyen használható formában.
A Magic elvrendszere nem csak eléri a szükséges szintű absztrakciót, de ezt olyan, erősen vizuális formában teszi, ami ideális a mai világ grafikus felhasználói felületeinek a számára. Az olyan technikák ügyes kombinációjával, amelyek már bizonyították értéküket más környezetekben, a Magic még egy előrelépést biztosít az alkalmazásfejlesztési folyamat termelékenységében.
A kód összehasonlítása
Nehéz elképzelni néhány konkrét példa nélkül, hogy mit kell érteni a Magic kódmentes elvrendszere alatt. Sok példa van, amely megmutatja a Magic fejlesztői elvrendszerének az egyszerűségét és eleganciáját. A következő bekezdésben két példa kerül bemutatásra, hogy kóstolót adjon a Magickel elérhető óriási termelékenységi előnyből.
Magic kontra Oracle Developer/2000
Az első példában a feladat két különböző táblából származó adatokat megmutatni a képernyőn.
Nyilvánvalóan, ennek a feladatnak az elvégzéséhez az olyan népszerű eszközökben, mint az Oracle Developer/2000, négy trigger kódolására van szükség, amelyek mindegyike PL/SQL kódsorokat tartalmaz, debuggolni, lefordítani és linkelni kell őket.
10. ábra: A Developer/2000-nek négy SQL triggerre van szüksége
Másrészről, a Magicben egy egyszerű Link Query vagy Link Join parancs elvégzi ugyanazt a munkát!
11. ábra: A Link Query parancs
Magic kontra Progress
Egy másik szembeszökő példa az alábbiakban kerül bemutatásra. A feladat itt, egy adatbevitel befejezésekor egy fájlból kiválasztott név megmutatása.
A Progress 8 teszt értelmében a fejlesztőnek a következő 13 sornyi script alapú kódot kell megírnia, amit utána fordítani és linkelni kell.
12. ábra: A Progress kódból származó UI trigger
A Magicben ezt a feladatot már az alkalmazásmotorba beépített funkcionalitás elvégzi. A munkát automatikusan megcsinálja!
13. ábra: A Magic beépített Locate képessége elvégzi a munkát!
Az ezekhez hasonló példák bőségesen bizonyítják a Magic elvrendszerének használata által elérhető hatalmas termelékenységi előnyt.