1. A programozási módszerek rövid történeti áttekintése

1.a ábra

Az 1960-as évekig a programozás módszerei heurisztikus utakat követtek. A programozók jobb híján assemblert használtak, ennélfogva csak kisméretû, egyszerû feladatok megoldására szorítkoztak. Gépi szintû programozás révén a csapatmunka jószerével elképzelhetetlen volt. A programok egyszerû elemi vezérlôszerkezeteket tartalmaztak, csak szimbólikus adatábrázolásra voltak képesek. A programok mobilizálhatósága minimális volt, mivel erôsen hardverspecifikusak voltak, karbantartásuk a programozón kívüli személyeknek szinte lehetelen volt. Program menedzsment nem létezett, az elkészített szoftverek csak igen szûk körben voltak alkalmazottak (iroda, mûhely). Hibakezelés nem volt, mûködését sem nyomon követni sem koordinálni nem lehetett. A programok sok elágazásokat tartalmaztak, gyakran meg kellett elégedni a programkód fôbb logikai szálainak nyomonkövetésével, ám ez azzal a kockázattal járt, hogy igan gyakran bukkant fel hiba az "éles" felhasználás közben. Erre az idôszakra jellemzô állapotot tükröz az 1.a ábra.

Az 1960-as évek végén következett be az ún. szoftverkrízis. A mikroprocesszorok teljesítménynövekedése a hardverárak radikális csökkenését vonták maguk után, ugyanakkor ezen hardverek teljesítménye hasonló ütemben növekedett. Természetes igényként merült fel ezen megnövekedett lehetôségeknek a kihasználása. Egyre nagyobb mennyiségû, terjedelmû és komplexitású programokra volt szükség. Ez viszont már olyan programozói környezetet, olyan eszköztárat és kódolási szemléletet igényelt, amely a 70-es évek elejére gyökeresen megváltoztatta a programok írásának módját. Elôtérbe került az algoritmikus programozás, a szimbólikus információszemléltetést a különbözô adatstruktúrák és algoritmusok váltották fel, amit a programnyelvek alkalmazása tett lehetôvé. A vezérlôszerkezetek is bonyolódtak ezáltal, a nyelveket gépi nyelvvé alakító fordítóprogramok, interpreterek készültek, azonban a programok csak magukban futottak vagy kezdetleges I/O szinten kommunikáltak egymással. A hibakezelés a compilerek és interpreterek révén rugalmasabbá vált (hibajelzés, leállás).

A 80-as évekre alakult ki a "nagybani" programozás. Komplett programrendszerek készültek amik nagy adatbázisokat használtak. A programok projektek formájában, csapatmunka révén készültek, szintén ilyen platformon zajlott a programok karbantartása és menedzselése is. Elkerülhetetlenné vált a programok strukturálása. Megjelentek a tudászemléltetô rendszerek. A hibakezelést átvették a fejlesztésre használt szoftverek, a programozást interaktív helpek, sokrétû dokumentációk segítették.

1. A szoftver engineering fogalma

A szoftverkrízis és annak vonzatai vezettek 1968-ban a szoftver engineering fogalmának megszületéséhez. A szoftver engineering végül is egy új szemlélet bevezetését jeleni, egy módszertant biztosít a programok, programfejlesztési eszközök termékszerû gyártására. Elôtérbe került a szoftver, mint szellemi produktum termékszerû jellege, azaz a minôség, az eladhatóság. A szoftver termékké válását a köztudatban az nehezítette, hogy - "mûszaki" termék létére - olyan tulajdonságokkal is rendelkezik, amelyek az ember által készített élvezeti termékeknek (mûvészet) is sajátjuk. Ezen tulajdonságokat szemlélteti a 2.a táblázat.

"mûvészeti" termék	szoftver	"mûszaki" termék
elsõsorban esztétikai igényt elégít ki	elsõsorban célszerûségi igényt elégít ki
nem az anyagi megjelenése a lényeges		anyagi megjelenésében funkcionál
nincs közvetlen kapcsolata a valósággal	közvetlen kapcsolatban van a valósággal
nem sorozatgyártással készül		sorozatgyártással készül
fejlesztés = gyártás	fejlesztés + gyártás
másolat eredeti	másolat = eredeti
használat miatt nem igényel karbantartást	használata közben karbantartást igényel
használata közben környezete nem befolyásolja a viselkedését	viselkedése függ a külsõ környezettõl (például helytelen kezelés által fellépõ hibák)

A szoftver engineering megszületése óta számos definíció látott napvilágot. A legegyszerûbb megfogalmazás szerint a szoftver engineering eszközök és módszerek a szoftver termékszerû elõállítására. A Boehm által 1976-ban adott "klasszikus" definíció kissé részletesebb: tudományos ismeretek célszerû alkalmazása számítógépprogramok valamint a fejlesztésükhöz, mûködésükhöz, karbantartásukhoz szükséges dokumentációk tervezésére és megalkotására. Egy késôbbi definíció jól mutatja a management szerepre jutását a szoftver engineering fogalomkörében: szoftver termékek szisztematikus gyártására és karbantartására és költségvetésére vonatkozó technológiai és menedzsment vezérelv (IEEE 1983).

1. A szoftver minôség jellemzôi

A szoftver minôség jellemzését az nehezíti, hogy egzakt mutatókkal nem lehet leírni. Ezért külsô és belsô tényezôket kell vizsgálunk, és így alkothatunk képet egy szoftver minôségérôl. A külsô tényezôk határozzák meg, hogy egy szoftvernek elkészülte után milyen kritériumoknak kell megfelelnie, a belsô tényezôk pedig a kódolás módszerét jellemzik. Tulajdonképpen a végeredmény szempontjából csak a külsô tényezôk számítanak, azonban ezeknek jó része erôsen függ a belsô tényezôktôl (módosíthatóság, újrahasználhatóság, kompatibilitás, stb):

Külsô tényezôk:

1. Helyesség (correctness): Azt a követelményt jelöli meg, miszerint egy programnak pontosan a specifikációja szerint kell mûködni.
2. Robosztusság (robustness): A szélsôséges (nem specifikált) feltételek közötti mûködés módja. A szoftver a legváratlanabb esetekben sem okozhat jelentôs kárt.
3. Módosíthatóság (extendibility): Amennyiben a szoftver más környezetbe kerül, nem okozhat számottevô nehézséget a megváltozott körülményekhez igazítása.
4. Újrahasználhatóság (reuseability): A szoftver vagy egyes részei felhasználhatók lehessenek más problémák megoldása során is.
5. Kompatibilitás (compatibility): Alkalmas legyen más szoftverekkel való együttmûködésre is.
6. Könnyû használhatóság: Ne okozzon túl nagy erôfeszítést a szoftver kezelésének megtanulása, illetve kezelése emberközeli és logikus legyen.
7. Hatékonyság:
8. Hordozhatóság:
9. Tesztelhetôség:
10. Integritás:

Belsô tényezôk:

1. Olvashatóság: Egy programnak világosan és érthetôen kell kódolva lennie, logikája tisztának kell lennie
2. Modularitás: Azt jellemzi, mennyire van részekre bontva a program, és az egyes részek mennyire látnak el külön feladatokat.
3. Strukturáltság:

A külsô tényezôk közül az elsô kettô tulajdonképpen a szoftver megbízhatóságát (reliability) jelenti. Egy szoftver akkor tekinthetô megbízhatónak, ha minden körülmények között a specifikációjának megfelelôen mûködik. Váratlan körülménynek felel meg, például hibás adatok beérkezése. Ezt a szoftvernek le kell tudnia kezelni, és meg kell kísérelni a hiba okának meghatározását. Ugyanígy nem szabad problémát okoznia hardver hibának sem. Természetesen a szoftver biztonságosságának növelése költséges dolog, viszont egy olyan szoftver ami nincs felkészülve extrém körülményekre, sokkal nagyobb hibát képes okozni (pl. adatvesztés).

1. A szoftverfejlesztés fázisai

1. Követelmény analízis

Célja a fejlesztéssel szemben támasztott követelmények meghatározása. A fejlesztõk részérõl elõbb azt kell tisztázni, mik azok az információk amikre egyáltalán szükség van. A szükséges információknak valahogyan a birtokába kell jutniuk, aztán pedig rendszerezni kell a rendelkezésre álló információkat. Ez leggyakrabban egy kétoldalú megbeszélés (sorozat) a majdani felhasználó és a fejlesztômunkát végzô csapat között. Ezen tevékenység eredménye a Projekt terv (4.a ábra).

4.a ábra

A Projekt tervnek nincs standard formátuma, de a "házi" szabályokat szokás betartani, vagy ha egy adott meglévô fejlesztô eszköt használunk, akkor igazodni kell az abban található struktúrához. Az alábbiakban a Projekt terv egy lehetséges struktúrájára láthatunk példát.

Bevezetés a probléma leírása a környezet leírása az elérendõ célok megfogalmazása a megoldási javaslatok összefoglalása	Javaslatok a fejlesztés általános stratégiája javaslat a megoldásra a felhasználó és a XXXXXXXXXXX szerepe a javasolt megoldásban a javasolt megoldás által biztosított funkciók a javasolt megoldás elõnyei és hátrányai
Feltételek, korlátok, követelmények a megrendelõ prioritása a felhasználó profilja a termék elvárt élettartama teljesítmény követelmények a meglévõ XXXXXXXXXXX és szoftver-hardver követelmények továbbfejlesztési elképzelések betanítási, installációsm dokumnetációs követelmények a megrendelõ környezete (hardver és szoftver lehetõségei) alternatív megoldások a tervezett és az alternatív megoldások megvalósíthatósága	Becslések munkafelosztás ütemterv munkatársak (szervezet) költségvetés költség-XXXXXXXXXXX analízis kockázat analízis szükséges eszközök
Eljárások a fejlesztési stratégia (életciklus modell) módszerek és jelölés-rendszerek szabványok és minõségbiztosítás költség-figyelés gyártásirányítás tesztelés, teszt adatok elfogadás feltétele fizetési feltételek	Hivatkozások felhasznált dokumentumok szakkifejezések jegyzéke szerzõdés (tervezet)

1. Specifikáció

Szintén kétoldalú megbeszélés, az elkészítendô programrendszer részletes, formális leírását foglalja magában, speciális esetben szolgálhat a két fél közötti szerzôdésként is. A specifikáció úgy is felfogható, mint a követelmény analízis folytatása formális eszközökkel. Három fõ tevékenysége a következõ:

1. a felhasználó-orientált követelmények lefordítása a fejlesztõk nyelvére (4.b táblázat)

	Felhasználói követelmények	Specifikáció
Fogyasztó:	felhasználó	szoftver fejlesztõ
Nyelv:	természetes nyelv	formális nyelv
Pontosság:	nem precíz	precíz
Terminológia:	az alkalmazás szakkifejezései	szoftver terminológia
Szemlélet:	nem technológiai	technológiai

1. módszerek és eszközök intenzív használata
   1. meggyõzõdés a termék-definíció helyességérõl

A specifikáció végtermékei a Szoftver követelmény analízis, a Szoftver ellenõrzési terv és a Felhasználói kézikönyv, melyekbõl a Szoftver követelmény analízis-re adunk meg egy követésre érdemes struktúrát (az elõzõ alfejezet végén található Projekt terv-hez hasonlóan).

Bevezetés XXXXXXXXXXX a környezet leírása a felhasználók körének lerögzítése a felhasznált jelölések az elérendõ célok megfogalmazása	A szoftver funkciói elõfeltételek folyamatok (processzek) leírása adatok leírása adatkapcsolatok leírása
Feltételek, korlátok külsõ kapcsolatok (hardver, szoftver, operációs rendszer, hálózat, felhasználók) kompatibilitás az elõzõ termékekkel feldolgozási teljesítmény-követelmények XXXXXXXXXXX megbízhatóság pontosság karbantarthatóság biztonság és védelem	Rendellenes mûködés tiltott viselkedések hardver hibák és következményeik szoftver hibák és következményeik adathibák és következményeik
Szoftver életciklus életciklus modell módszerek és szabványok elõre megjósolható módosítások	Hivatkozások felhasznált dokumentumok szakkifejezések jegyzéke

1. Tervezés

4.c ábra

A tervezési fázis során a követelmény analízis és a specifikáció által reprezentált bemenetbõl az elkészítendõ program(rendszer) struktúrája és annak elemei állnak elõ (4.c ábra). Ebben a fázisban történik a programrendszer mûködéséhez szükséges fontosabb adatszerkezeteknek, rutinoknak és azok interfészének, moduloknak és azok kapcsolatainak valamint a szükséges algoritmusoknak a kidolgozása. Míg a követelmény analízis a mit?, a specifikáció a milyet?, a tervezés a hogyan? kérdésre adja meg a választ, feladata az absztrakciós szint csökkentése. A megvalósítási folyamat ezen szakaszában lépnek be a hardver és szoftver környezet valamint a tervezõ személyek befolyásoló jellemzõi (4.d táblázat).

Hardver	Szoftver	Személyi
kapacitás korlátok hálózati viszonyok speciális eszközök architektúra	fejlesztõi környezet adatbáziskezelõ operációs rendszer	kreativitás gyakorlat fantázia

1. Implementáció

Ez tulajdonképpen a kódolási folyamat, a szükséges modulok és programok elkészítése.

1. Installálás és tesztelés

Ezen a ponton történik a program installálása és mûködésének vizsgálata a fejlesztõk által. Tesztelésre kerül a program viselkedése hibás adatbevitel illetve nem megfelelõ kezelés esetén. A programozás során elõre nehezen megjósolható futásidõben fellépõ hibák legtöbbje ebben a szakaszban bekövetkezik.

1. Karbantartás

Ha a programrendszert más környezetben, megváltozott igények mellett akarják felhasználni, bizonyos komponenseit meg kell változtatni. Továbbá a leggondosabb tervezés és implementáció mellett is elôfordulnak hibák, miket gyorsan és kis ráfordítással kell helyrehozni. Mind a megrendelõ mind a kivitelezõ részérõl fontos szerephez jutnak a specifikációban rögzített követelmények.

A karbantartás a teljes költség 80% -át is elérheti. Ennek megoszlása a következô lehet:

fejlesztô (perfective): 65%, a felhasználó vagy a programozó által még a fejlesztés fázisában javasolt módosítások;

alkalmazkodó (adaptive): 18%, a szoftver környezetében történt változásokhoz igazítás miatti módosítások;

javító (corrective): 17% a mûködés közben felfedezett hibák miatti javítások.

4.e ábra

A szoftver költségét befolyásolják:

• a szoftver tervezés és implementálás technikai faktorai:
  • a modulok egymástól való függetlensége
  • a programozási stílus
  • a tervezés ellenôrzése
  • a program tesztelése
  • programozási nyelv választás
  • szabványok, szabványos szoftver eszközök használata
  • a dokumentáció minôsége
• a szoftver függôsége a külsô tényezôktôl
• a mûködtetô hardver stabilitása
• a szoftver várható élettartama
• a szoftvert támogató team folytonossága, állandósága, stabilitása

1. A strukturált rendszer specifikáció formális módszerei

5.a ábra

Minden szoftver termék felbontható adat, processz és reláció komponensekre (5.a ábra). Attól függõen, hogy ezek közül mit választunk a rendszer specifikáció alapjául, beszélünk adat- illetve processz-specifikációról.

1. Processz specifikációs módszerek

Ennél a módszernél a struktúrát képezõ objektumok az eljárások, vagy módszerek, a struktúráló szempont pedig az eljárás funkcionális jelentése.

1. Adatfolyam diagram

Az adatfolyam diagram leírja

• a vizsgált rendszer be- és kimenõ adatait,
• a rendszerben tárolt adatokat,
• az egyes adatokon végzett mûveleteket.

A diagram komponensei és Yourdan-DeMarco-féle jelölésük a 5.b táblázatban látható.

adat	processz	tároló	adatforrás vagy -nyelõ

Az adatfolyam-diagram kifejtésében elsô lépésben minden processzt ki kell bontani úgy, hogy maximum 3-4 szint legyen, és azokban egy-egy ábra 4-5 processzt reprezentáljon. E folyamat révén újabb adatforrásokat és adatnyelôket lehet ábrázolni, továbbá növeli az adatelemek (azaz a nyilak) számát is. Gyakran hasznos alternatív megoldások kidolgozása is.

Célszerû a folyamatok idôegységek szerinti csoportosítása. Folyamatok idôhorizontjaira 3 kategória jellemzô:

a) 10 mp-en belüli: online programozást igényel;

b) 1 órán belüli: a felhasználó által indított háttérfolyamatokkal érhetô el;

c) "idônkénti": a hagyományos kötegelt (batch) feldolgozással valósítható meg.

Példa

1. Az SADT® (Structured Analysis and Design Technique) diagram

5.c ábra

A SADT egy formális top-down módszer funkcionális modell felépítésére grafikus úton. A top-down dekompozíciót kétféleképpen lehet alkalmazni: a grafikus ábrázolásban a téglalapok a tevékenységeket jelölik, a nyilak pedig az adatáramlást a tevékenységek között (tevékenység dekompzíció), vagy a téglalapok az adatokat reprezentálják, a nyilak pedig az adatok közötti mûveleteket (adat dekompozíció). A továbbiakban a tevékenység dekompozíciót részletezzük. A 5.c ábra mutatja, hogyan alakul egy tevékenység környezete.

A modell felépítése különbözô lapokon történik, a lapok a modell hierarchiai szintjeinek felelnek meg. Mindel alsóbb szintet kifejtô lap egy, a "fölötte" lévô lapon szereplô téglalap (tevékenység) kibontása (5.d ábra).

5.d ábra

Példa

1. Adatspecifikációs módszerek

Adatspecifikációs módszerek esetében a struktúra alapobjektumát az adategység, struktúráló szempontját az adatok közötti szemantikai tartalom szolgáltatja. A struktúrában szinteket különböztetönk meg, a magasabb szinteken csak általános tartalmi hozzárendeléseket teszünk az adatokra, melyeket az alsóbb szinteken szétbontunk konkretizálva ezáltal a szinteket.

1. Blokk diagram

Blokk diagramot akkor használunk, mikor egy rendszerben csak az adatok egymástól függõségét akarjuk szemléltetni, érdektelen a az illetõ adatok tartalma, formátuma. Például az egyetem hierarchikus felépítését szemlélteti az 5.e ábra.

5.e ábra

1. Warnier diagram

A Warnier diagram annyiban mutat túl a blokk diagramon, hogy benne van az adattagok ismétlõdésének és a feltételességének lekezelése.

Példa

1. Entitás-reláció (Entity-relationship, ER) diagram

5.f ábra

Az ER diagram a rendszert felépítõ adatokból és azoknak relációját mrghatározó relációkból épül fel. Az alkalmazott jelöléseket a 5.f ábra mutatja. A kapcsolat fajtáját tekintve 3 féle lehet:

• 1-1 kapcsolat. egy adattag és egy másik között egyértelmû megfeleltetést lehet tenni, azaz egy adattag egy konkrét példányához a másikféle adattagból csak egy példány rendelhetõ. Ilyen kapcsolatra lehet példa a személy-személyi szám viszony.
• 1-N kapcsolat. egy adattag egy konkrét elõfordulásához egy másik adattípus többféle példánya is hozzárendelhetõ. Példaként a szülõ-gyermek kapcsolatot lehet megemlíteni.
• N-N kapcsolat: egy adattag több példányához egy másik adattag többféle példányát lehet hozzárendelni. N-N kapcsolatra példa az oktató-hallgató adattípusok közötti kapcsolat.

Példa

1. Adatszótár

Az elkészült rendszerstruktúra elemeit (processz, elemi adat, adatszerkezet, adatcsoport) nyilván kell tartani. Ennek számítógépes megvalósítása az adatszótár. Ennek formátumára nincs megkötés, de ajánlatos a következô sémát követni:

adatelem	adatszerkezet	adatkapcsoport
Név Leírás Formátum Lehetséges értékek	Név Leírás Elemi adatok Az elemi adatok közötti kapcsolat	Név Leírás Szám (Az ábrán szereplô dekompozíciós szám.) Adatszerkezetek
processz	adatfolyam
Név Szám (Az ábrán szereplô dekompozíciós szám.) Leírás Input Output	Név Adatelem (adatszerkezet) neve Melyik processzbõl ered Melyik processzig tart

1. A tervezési fázis

A tervezési fázisban három szintet különböztetünk meg azon vezérelv alapján, hogy milyen mértékben áll kapcsolatban az illetõ rendszer a külvilággal. Ennek megfelelõen megkülönböztethetünk külsõ (interface), architekturális és részletes tervezést.

1. Külsõ tervezés

A külsõ tervezés feladata a szoftver külvilággal való kapcsolatának megtervezése. Külvilágnak a mûködtetõ hardvert vagy rendszer szoftvert, egyéb alkalmazásokat (további szoftverek), valamint a felhasználót tekintjük. Ezek a külsõ tényezõk egymással is kapcsolatban állnak, ahogyan azt a 6.a ábra mutatja.

6.a ábra

A felhasználó a tervezendõ szoftverrel a felhasználói felület-en keresztül tartja a kapcsolatot (6.a ábra), ezért ezen kapcsolódási felület megtervezése központi szerephez jut a tervezés tervezés során mivel más alkalmazói szoftverekkel és a hardver elemekkel való kapcsolat megoldása csupán technikai kérdés, a felhasználó csupán ezek járulékos hatásaival találkozhat a használat során (a hibák is a felhasználói felületen keresztül jelennek meg).

1. A felhasználói felület tervezésének technikai szempontjai

Ebben a fejezetben azon szempontokat tekinjük át, melyek technikai vonatkozásaiban fontosak a felhasználói felület és a felhasználó viszonylatában. Ezek a kritériumok olyan, a fejlesztõ(k) által lerögzített dolgok, melyek nélkül a felhasználó és az szoftver kapcsolata kritikussá válhat, tehát figyelembevételük elengedhetetlenül szükséges a tervezés során.

6.b ábra

1. A felhasználói felület tervezésénél kulcskérdés a majdani felhasználók körének ismerete. A felületet a megcélzott réteg gondolkodásmódjához és nyelvi terminológiájához kell igazítani. Nem mindegy, hogy az adott rendszert mely munkakörben dolgozók fogják használni, például egy adminisztratív jellegû dolgozónak nem lehet olyan kifejezésekkel felületet tervezni mint egy programozó szakembernek. Ajánlatos azt is figyelembe venni, hogy milyen gyakorlattal rendelkeznek a felhasználók például a 6.b ábrán látható módon csoportosítva.
2. Pontosítani kell a teljesítményre vonatkozó követelményeket. Ha például egy olyan szoftverre van szükség, amelynek sebességi mutatói lényegesek, nem szabad, hogy az interfész mûködése lassítson a mûködésén.

6.c ábra

1. Csoportosítani kell a program használata során alkalmazott funkciókat. A 6.c ábra mutat egyfajta besorolási lehetõséget. A leggyakrabban használt funkciókat például alfanumerikus felületnél rövid, de a funkcióra emlékeztetõ parancsokkal kell ellátni, grafikus interfész esetén a képernyõ mindig elérhetõ helyére kell helyezni. A veszélyes funkciókat kiváltó akciókat mindig konfirmálással kell ellátni.
2. Szem elõtt kell tartani a funkciók végrehajtásának módszerét. Nagyban megkönnyíti például a munkát az alapértelmezés szerinti (default) értékek használata, vagy az egyes funkciók összekapcsolása (QUIT elõtt mindig legyen SAVE lehetõség, MODIFY után legyen UPDATE, stb.)
3. Gyakorlott felhasználó számára nem biztos, hogy ugyanaz a kezelési módszer felel meg, mint egy kezdõ felhasználónak, ezért az egyes funkciók kiváltására alternatív lehetõséget is kell biztosítani. Például a Windows 3.1 felület kezelésekor a kezdõ felhasználóknak nagy segítséget nyújt az egérrel kezelhetõség, míg a gyakorlottabbak billentyûzetkombinációkkal ugyanazokat a funkciókat jóval gyorsabban tudják kiváltani. (Negatív példa az X-Windows környezetben futó - Silicon Graphics gépekre implementált - Jot szövegszerkesztõ, ahol az egyes funkciókat kizárólag egérrel lehet kiváltani, vagy a másik oldalon maga az UNIX operációs rendszer amely az awk, ps, grep, stb. -szerû parancselnevezéseivel igen megnehezíti a kezdõk dolgát.)
4. Pontosan specifikálni kell a lehetséges alternatív mûveleteket. XXXXXXXXXXX
5. A rendszer viselkedését a hibákkal szemben körültekintõen kell megtervezni. A legfontosabb vezérelv, hogy hiba nem "csúszhat" keresztül a rendszeren! A szerencsés eset az, ha a hiba olyan, hogy automatikusan ki lehet javítani. Ha azonban ez nem lehetséges, azt mindig úgy kell a felhasználó tudomására hozni, hogy még véletlenül se kerülhesse el a figyelmét. Az igazán jó rendszerek a hiba típusától függõen javaslatokat tesznek a hiba javítására. (Némely munkaállomásokon futó X-Windows-os alkalmazás például hibáit egyszerûen a bejelentkezéskor aktivizálódott konzol ablakra írja, így ha a konzol ablak épp el van takarva, vagy ikonizálva van a felhasználó nem vesz tudomást a hibáról. Ezzel ellentétben a Mosaic vagy a Netscape alkalmazások mindig egy külön ablakkal hívják fel a figyelmet a "problémáikra".)
6. Bizonyosodjunk meg arról, hogy nincsenek hibás feltételezéseink a szoftver mûködését illetõen, és készüljünk fel arra, hogy a felhasználó bármilyen inputot képes produkálni tekintet nélkül arra, hogy van-e annak értelme. A példa kissé primitívnek hat, de egy rajzoló program esetében például nem lehet arra építeni, hogy a felhasználó nem fog 0 hosszúságú vonalakat definiálni mivel nem logikus olyan vonalak beállítani, melyeknek kezdõ és végpontjuk egybeesik, hiszen egy vonalhosszúságon alapuló algoritmus esetében a 0-val való osztás végzetes lehet.
7. A felület tervezés emberi vonatkozásai

Míg az elõzõ alfejezet a felhasználó és a felhasználói felület kapcsolatának technikai vonatkozásait tekintette át, ez a fejezet inkább a kapcsolat emberi oldaláról közelíti meg a kérdést. Ezen szempontok nem elengedhetetlenül szükségesek a felület és a felhasználó kapcsolatában, de a szoftverrel való munka hatékonyságát nagymértékben megnövelik

1. A felhasználó érezze, hogy a rendszer megfelelõen kezeli le az egyes hibákat, tehát érezze "biztonságban" magát. Hatékonyabb a munka, ha a biztonságérzettel kezeli a rendszert, nem pedig azzal a tudattal, hogy esetleg már nem konzisztens adatokkal dolgozik. (Ezen sorok írója komolyan megszenvedett egy ízben, mikor az egyik legszélesebb körben használt grafikus CAD rendszer által elõállított, két érintõlegesen csatlakozó spline foltból álló felület megmunkálásához próbált szerszámpályát generálni. Több óra és több nagyítási mélység után derült ki, hogy ami az egyik rendszerben kapcsolódó felület, az a másikban nem.)
2. A felhasználó érezze magát tájékozottnak. Sok idõ eltelhet azzal, hogy olyan információt keres, ami a rendszerben olyan helyen van elhelyezve aminek keresése sok idõt igényel, vagy nincs is szüksége. Mindig legyen a képernyõn a megfelelõ mennyiségû információ, de csak annyi, amennyi még nem zavaró. Nagyon hatékony módszer például a nem használható menüpontok "kiszürkítése".
3. XXXXXXXXXXX
4. Esztétikailag kulturált legyen a felület. Az ember szívesebben dolgozik egy "szép" programmal, mint egy elnagyolt felületûvel. Például a képernyõ ne legyen túlzsúfolt, vagy túl színes, szemet bántó. Ez a kritérium az elsõ benyomások megszerzésekor különösen fontos, sõt sok embernél az elsõ szempontok között szerepel.
5. Ne érezze a felhasználó kényelmetlennek a rendszert. Az interfészt olyanra kell megtervezni, hogy a funkciók kényelmesen elérhetõk legyenek, a leggyakoribbakat minimális keresés után el lehessen érni. Például az alapvetõ parancsokat ne menübõl lehessen aktivizálni, hanem mindig legyenek jelen a felhasználó képernyõjén. Tudja befolyásolni a párbeszédek ütemét, ne kelljen egy akció kiváltására sokat várni. Amennyiben egy hosszadalmasabb mûvelet kezdõdött annak megindulásáról mindig legyen informálva. (Lassabb X-Windows alapú felületek kezdõ felhasználói gyakran okoznak kavarodást azáltal, hogy egyszerre több alkalmazást elindítanak, mivel egy ablakos applikáció elindulásáról - a konzol ablakon kívül - semmilyen információt nem kapnak. Ezzel szemben a jóval lassabb VMS alapú VAX gépek esetében egy alkalmazás elindításakor a felhasználó "rögtön" visszajelzést kap a processz futtatásának megkezdésérõl.)
6. A dialógusok legyenek minél egyszerûbbek, világosabbak, ugyanakkor könnyen kezelhetõek. Például nagyon fárasztó és nehézkes egy grafikus tervezõrendszernél a rajzi paramétereket egymás után feljövõ, egysoros dialógus ablakokban beállítani, viszont a "Boing mûszerfal" stílusú dialógusdobozokban nehezen áttekinhetõségük miatt információk veszhetnek el.
7. A felület felépítése legyen legyen rugalmas. Mindig legyen megszakító funkció (ESCAPE, CANCEL, DROP, stb), és a kilépési pontok (EXIT, QUIT, stb.) egyértelmûen legyenek jelölve. (Több szintû dialógus esetén csak a legfelsõn legyen kilépési pont, az alsóbb szinteken csak megszakítás, különben a felhasználó nem tudja, hogy a beállított változtatások elvesznek-e kilépéskor, vagy nem.) A HELP funkció minden szituációban elérhetõ legyen, és mindig az adott szituációról szolgáltasson információt. (Például a Windows rendszerben a feljövõ dialógusablakok majdnem mindegyikében van HELP szolgáltatás egészen a legalsóbb szintekig, a Borland C++ 3.1 környezetben pedig hiba felléptekor lehet információt kapni az illetõ hibával kapcsolatban.)
8. A felület legyen következetes. A "veszélyes" funkciók elkülönítve a leggyakrabban használtaktól (legyenek azok funkcióbillentyûk, vagy ikonok révén aktivizálhatók). Az azonos jellegû üzenetek közlésének módja legyen hasonló (például informatív jellegû üzenetek zölddel a képernyõ aljára, a hibák pirossal a tetejére). Világosan különöljön el az üzenetek és az adatbeadás helye a képernyõn.
9. A felhasználó egyszerûen tudja javítani a hibákat. Ha mód van rá, a rendszer ajánljon fel hibajavítási lehetõségeket. (Hajlékony mágneslemezzel dolgozó rendszerek esetében elõfordulhat, hogy a lemezre írás nem sikerült. Tegyük fel, hogy az írás során a rendszer visszaellenõrizte a kiírt adatokat, majd megállapította, hogy az írási mûvelet hibás szektor miatt nem sikerült. Ebben az esetben a felhasználó választhat: új lemezzel kísérli meg a mentést, vagy a rendszer segítségével kiiktatja a hibás szektort, és újra megkísérli az írást.)
10. Végül ide kívánkozik még az a szempont is, hogy ne érezze unalmasnak a felhasználó a munkát, legyen látványos a felület.

1. Architektúrális tervezés

Az architekturális tervezési fázisban kerül megtervezésre, hogy hogyan és milyen lépéseken keresztül lehet a külsõ tervezéstõl a részletes tervezésig eljutni (6.d ábra). Egy tervezési szintet reprezentáló komponens a fölötte álló szint dekompozíciójával jön létre. A lépések száma a tervezendõ rendszer méretétõl függ.

Minden lépés a következõ tevékenységek sorozata:

1. Az adott komponens dekompozíciója,
2. az új, kisebb komponensek közötti interfészek leírása,
3. a részkomponensek formális leírása a felírt sorozatban,

azaz a rendszert modulok és interface-k segítségével írjuk le. A modul egy jól definiált, független egység, az interface pedig a modulok közötti kapcsolatot írja le. Vigyázni kell azonban, mert a modul nem biztos, hogy egy procedúrát, eljárást jelent, lehet az egy adatelem is. Ílymódon különböztethetünk meg adat-alapú és funkcionális alapú dekompozíciót. Ezt nevezzük az architekturális tervezés dualitásának.

A két dekompozíciós példa között nem húzható éles határvonal, mint ahogyan azt az objektum orientált programozás példája is illusztrálja. Az OOP technikák alkalmazásával osztályok tartalmazzák az adatmodulokat, függvény interface-k teszik lehetõvé az adatmodulok korlátozott manipulálását. Mindkét dekompozíciós módszer ugyanolyan fontos és ugyanúgy alkalmazható a tervezésben.

Egy tervezési fázisnak akkor lesz vége, ha a modulok közötti interface-k komplexitása megközelíti a modulokon belóli funkcionális- és adatstruktúrák komplexitását. A modulok egymással kohéziós kapcsolatban állnak, ami szoros összetartozásukat, más moduloktól való elkülönülésüket jelenti, és ez nehézzé teszi a további lebontást. Ennek az lesz a következménye, hogy a modulok valamely egyszerû, de fontos adatelem köré szervezõdnek, vagy valamilyen egyszerû funkcionális absztrakciót implementálnak. A moduláris kohézió fajtáit és azok jellemzõit a 6.f táblázat foglalja össze.

elnevezés	a kohéziót létrehozó összefüggés
funkcionális	jól definiált, egyszerû funkció
informális	osztott adatstruktúra vagy adatbázis
szekvenciális	kötött sorrendben következõ funkciók
kommunikációs	XXXXXXXXXXX, nem strukturált adathalmaz
procedurális	a szoftver által elõállított, ugyanazon eredménnyel kapcsolatos funkciók
temporális	a szoftver vérgehajtásának ugyanazon részéhez kapcsolódó funkciók (például inicializálás)
logikai	felületes hasonlóság
véletlen	véletlenszerûen csoportosított funkciók

A kohézió további következménye, hogy a modulok relatíve függetlenek egymástól, interface-eik relatíve egynemûek. Ennek az önállóságnak különbözõ fokozatai vannak, amiket a 6.g táblázat összegez.

típus	leírás
függetlenség	semmi kapcsolat nincs a modulok között
adat	csak a szükséges adatelemek, jól definiált interface-eken keresztül
adatstruktúra	az inteface-en egy nagyobb adatstruktúra jelenik meg, amely a modul számára fölösleges adatokat is tartalmaz
vezérlés	az interface-en olyan adatok jelennek meg, amely más modulok végrehajtását vezérli
külsõ	a modulok az interface-en kívül más eszközökkel (például fájlok) is kommunikálnak
közös	a modulok nem explicit interface-ekkel, hanem globális adatstruktúrákon keresztül kommunikálnak
tartalmi	a modulok el tudják érni és módosítani tudják egymás belsõ adatait és utasításait

1. A tervezés klasszikus módszerei

A feladat tehát a rendszer modulokra bontása és a modulok közötti kapcsolatok tisztázása. Ennek véghezviteléhez általában több absztrakciós szintet kell alkalmazni, így az esetek többségében beszélhetünk magasszintû, középszintû és alacsonyszintû tervezésrõl.

Magasszintû tervezés:

Elsô lépés a rendszer alrendszerekre bontása. Döntéshozatal történik az alrendszerek struktúrájáról, az alrendszerek közötti kommunikációról, a globális adatszerkezetekrôl. Ezen a szinten a részletes tervezés az input és output adatok megállapítására terjed ki. A tervezés felülrôl-lefelé történik (top-down dekompozíció). Segédletei a HIPO kártyák illetve a rendszer folyamatábrák.

Középszintû tervezés:

Ezen a szinten az alrendszerek is lebontódnak iteratív módon programokra. Rögzítôdik a vezérlés módja és a programegységek közötti adatcsere. Erre a következô technikák és adateszközök ismertek:

• programleíró (tervezô) nyelvek;
• struktúra folyamatábra;
• Jackson módszer;
• Warnier-Ohr módszer.

Alacsonyszintû tervezés:

A programok lebontása alprogram szintre. Lokális adatstruktúrák és algoritmusok definíciója is ezen a szinten történik. Itt kell lerögzíteni a programban használt neveket is. Az erre használt technikák és eszözök:

• struturált programozás;
• pszeudokód;
• folyamatábra

Az input adatok megtervezésénél az input adatok forrása valamilyen speciális eszköz (scanner, vonalkód olvasó, mágneskártya olvasó stb.) fájlok, adatbázisok vagy a képernyô lehet. Ezen legutolsó esetben ismét felhívjuk a figyelmet az ergonómiai tervezésre, hiszen a felhasználói felület a rendszer elfogadtatása szempontjából döntô lehet.

A fejezet következõ részében a hagyományos középszintû tervezésekbõl tekintünk át néhányat.

1. Stukturált analízis és tervezés (Structured analysis and design)
2. A strukturált analízis és tervezés részei

7.a ábra

A tervezési módszer kiindulási segédletei az adatfolyam diagramok valamit a specifikációs fázis végén elõálló adatszótár (lásd 5.2.4 fejezet). Az adatfolyam diagramokból a modulokat tartalmazó struktúra diagram és modul-leírás készül. A struktúra diagram rajzi jeleit a 7.a ábra mutatja. Architekturális (középszintû) tervezésre ez a módszer a legalkalmasabb. Tartalmazza a modulok hívási (függõségi) hierarchiáját, az adatelemeket és azok áramlási irányát, az adatelemek leírását, a modulok funkcionális leírását. Nem tartalmazza viszont a modulok hívási sorrnedjét és a modulok hívásának számát, tehát nincsenek benne alacsony szintû vezérlési struktúrák (ezek megalkotása az alacsonyszintû tervezés feladata).

1. Struktúra diagram készítése

A struktúra diagram részei

A struktúra diagram moduljainak négy alaptípusát különböztetjük meg a 7.b ábrán látható módon, a leírásban szereplõ alapvetõ folyamatokat pedig a 7.c ábra mutatja.

7.b ábra

7.c ábra

A struktúra diagram készítésének lépései

1. A rendszer részekre bontása a tranzakció analízis segítségével. A tranzakció analízis tulajdonképpen a tranzakciós központ megkeresésébõl és az input-output rész lehatárolását jelenti (7.d ábra)

7.d ábra

1. Az egyes részrendszerek struktúra diagramjánk megkonstruálása a transzformációs analízis segítségével. Ez a szakasz a központi transzformáció megkersését továbbá a lényegtelenebb részek elhagyásával történõ egyszerûsítést foglalja magában (7.e ábra)

7.e ábra

1. A részrendszerek összekapcsolásával a rendszer ismételt felépítése.

A struktúra diagramban középen helyezkednek el a központi transzformáció elemei, tõle balra az afferens, jobbra az efferens részek (7.f ábra az elõzõ példa alapján). A határok megválasztása részben szubjektív. A "fontos" transzformáció kell, hogy alkossa a transzformációs központot.

Elemekre bontás (faktoring)

Az elemekre bontás az egy modellben elhelyezkedõ funkciók önálló modulokra történõ szétválasztását jelenti. Ez a következõk miatt elõnyös:

• Csökken a modulméret.
• A föntrõl lefelé történõ dekompozíciós elvnek megfelelõen így egy könnyebben átlátható és könnyebben módosítható rendszert kapunk.
• Elkerülhetõ a funkcionális redundancia, azaz egy funkció csak egy helyen lesz megvalósítva.
• Jobban elkülöníthetõk lesznek a munkavégzõ és a vezérlõ részek.
• Általánosan használható modulokat nyerhetümk.
• Egyszerûsíthetkük az implementációt.

7.f ábra

A döntés összetartás elve

A döntések két részbõl állnak: feltétel és végrehajtandó akció. A struktúra diagram megalkotásánál alapvetõ szempont, hogy a két rész minél közelebb kerüljön egymáshoz. Egy ágban lehetõleg minimális számú végrehajtandó mûveletet gyûjtsünk össze.

A kiegyenlített rendszer

A rendszer kiegyenlített, ha igaz rá, hogy:

• A felsõ szinten lévõ modulok inkább logikai, az alsó szinten lévõk inkább fizikai adatokkal foglalkoznak.
• Az afferens oldal az adatokat úgy csoportosítja, hogy a központi transzformáció az input adatszerkezettõl független.
• Az efferens oldalon az output formátumtól független adatok vannak.

A kiegyenlített rendszer azért hasznos, mert könnyû implementálni, külsõ interface könnyet változtatható, továbbá ezzel a módszerrel az alsóbb szinteken újrahasznosítható rutinok keletkeznek.

Vegyünk példaként a kiegyenlített rendszer illusztrálására egy tipikus részfeladatot: egy rekord szerkezetû adatbázis (adatfájl) tranzakció vezérelt karbantartását! ( 7.g ábra) A tranzakciót egy-egy adatsor írja le.

7.g ábra

A programstruktúra és az adatstruktúra egyeztetése

A programsztruktúra és az adatstruktúra egyeztetés azt jelenti, hogy lehetõség szerint a feldolgozás szerkezete kövesse az adatszerkezetet. Ha például az adott fájlból az adatok karakterenként érkeznek, akkor a feldolgozás is történjen karakterenként. Ennek az ellenkezõje a rekordonként érkezõ adatok karakterenkénti feldolgozása. (7.h ábra).

7.h ábra

1. A Jackson-féle adatstruktúra orientált programtervezési módszer

Az adatstruktúrák kifejezésének uniformizálására vonatkozó igény megköveteli, hogy általános, nyelvfüggetlen módon is le lehessen írni azokat. Erre alkalmas a Jackson módszer.

A Jackson-módszer alapelvei

• A programszerkezetet a be- és kimenõ adatszerkezetek határozzák meg.
• Top-down technika (fentrõl-lefelé történõ dekompozíció)
• Lépésenkénti finomítás elve.
• Döntések elhasználásának elve.
• Döntések elrejtésének elve.
• A cél a feladat által implicite tartalmazott struktúra megtalálása a probléma elemzésén keresztül.
• A struktúrát az abszrakcióra építve kell megközelíteni nem pedig a számítógép fogalomkészletével.

A Jackson-módszer lépései

1. A bemenõ és kimenõ adatszerkezet(ek) hierarchiadiagramjának megrajzolása.
2. A bemenõ és kimenõ adatszerkezetek összefésülésével a programszerkezet hierarchiadiagramjának kialakítása.
3. Elemi tevékenységjegyzék készítése.
4. Feltételek listájának elkészítése.
5. Elemi tevékenységek és feltételek elhelyezése a szerkezet diagramjában.
6. Pszeudokód elkészítése

1. Az adatszerkezet leírás elemei

elnevezés	grafikus	pszeudo-kód
szekvencia		A seq B C D A end
iteráció		A iter until feltétel B A end vagy A iter while feltétel B A end
szelekció		A select feltétel1 B A or feltétel2 C A or feltétel3 D A end

A 7.i táblázatban találhatók a Jackson-módszerben alkalmazott adatszerkezet elemek mind grafikus, mind pszeudokód alakjukban. Vigyázni kell, azonben, mert ezek elemi szerkezetek, a szerkezetben pedig csak egyféle viszony lehet egy felsõbb elemhez kapcsolva, ezért lenne hibás a

konstrukció.