Magic

A szoftvereszközök fejlõdése



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.

Szoftvermotorok

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?

 Magic - a motor

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:

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.

A hagyományos alkalmazásfejlesztési ciklus

4. ábra: A hagyományos alkalmazásfejlesztési ciklus

A Magic gyors, növekményes RADD ciklusa

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.

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ó

Egy formon lévő nyomógomb kikapcsolása

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.

Jellemző adatdefiníciós táblák

7. ábra: Jellemző adatdefiníciós táblák

Jellemző programozási 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: