Csoport neve: HICON

Feladat sorszáma: 5 

Feladat címe: UML szerkesztő

 

 

 

 

 

Vízió

 

 

 

 

 

Gyakorlatvezető:

Tamás István

 

 

 

 

 

 

 

Csoport tagok:

Domby Tímea Katalin

BRV1N2

timi_muinfo@yahoo.com

Füzér Zsuzsanna

Z5VJ39

zsuzsi0690@freemail.hu

Katona János

IUAKNI

katonn@freemail.hu

Kovács Roland

ER9HLO

kovipolly@freemail.hu

Krajnc Norbert

RUIBB2

frodo19@freemail.hu

2006-03-09

 

 

Történet

 

Dátum

Verzió

Leírás

Szerző

2006. 02. 27.

0.01a

Kezdeti verzió

HICON

 

 

 

 

 

 

 

 

 


 

Tartalomjegyzék

1. Bevezetés. 4

2. Az alkalmazás helye. 4

2.1 Üzleti lehetőségek. 4

2.2 A probléma megfogalmazása. 5

2.3 Az elkészült termék helye. 6

3. Érintettek és felhasználók. 7

3.2. Az érintettek összefoglalása. 7

3.3. A felhasználók összefoglalása. 7

3.4 Felhasználói környezet 8

3.5. Illetékesek adatai 8

3.6. Felhasználók adatai 9

4. A végtermék áttekintése. 9

4.1. A  termék kapcsolatai 10

4.2. A termék használatának előnyei 10

4.3. Feltételezések és függőségek. 11

4.5.  Installáció. 12

5. A végtermék jellemzői, biztosított szolgáltatások. 12

6. Korlátozások. 13

7. Minőségi elvárások. 13

8. Dokumentációkkal kapcsolatos követelmények. 13

9. Kockázat lista. 14

10. Szótár 16


 

        1. Bevezetés

A rövidítés jelentése Unified Modelling Language, azaz Egységesített Modellező Nyelv. Az UML eredetileg Booch, Rumbaugh és Jacobson módszereit egyesítette, de ma már minden szoftverfejlesztéssel foglalkozó világcég felismerte a szabvány jelentőségét, és foglalkozik annak továbbfejlesztésével. Jelenlegi hivatalosan elfogadott verziója az 1.5-ös. Már a legújabb is kész van, de még hivatalosan nem teljesen elismert.

            Az UML egy grafikus nyelv, amelyben lehetőségünk van a probléma specifikációjára, megoldására, a megoldás dokumentálására. Az UML a jelöléseknek gazdag választékát kínálja, mely segítségével a szoftverfejlesztés összes fázisa modellezhető. Az UML a kiterjesztési mechanizmusok (pl. sztereotípusok) segítségével egyéni jelölések s azok szemantikájának bevezetését is támogatja, hogy minden segítséget megadjon a szoftverfejlesztőknek ahhoz, hogy könnyedén modellezhessék az akár egyéni vagy különleges rendszereket is. Az UML szerkesztő legismertebb modelljei:

   - Osztálydiagram
   - Objektumdiagram
   - Komponensdiagram
   - Telepítési diagram
   - Használatieset diagram
   - Szekvenciadiagram
   - Együttműködési diagram
   - Állapotdiagram
   - Aktivitásdiagram

Az UML felhasználása:
  - Tervezésnél: A szoftverek tervezésének egyik eszköze. Nagyon fontos, hogy a tervező lássa maga előtt a megoldást, ezért erre ki kellett találni egy vizuális megoldást. Egy idő után már UML diagramokban testesülnek meg a tervező gondolatai, ez sokat segít azok ledokumentálásában, illetve a tervezők közötti, valamint a fejlesztők, megrendelő, stb. felé történő kommunikációban.
  - Szemléltetés: Az UML jól áttekinthető diagramok formájában testesül meg, vagyis a szoftver struktúráját segítségével igen könnyen szemléltethetjük. Fontos, hogy elterjedt, szabványos jelölésmódról van szó, ezért joggal feltételezhetjük, hogy a „túloldalon” is ismerik, nem azzal kell vesződni, hogy megtaláljuk a közös nyelvet.

A választott feladatunk egy UML szerkesztő, mely megbízhatóan biztosítja azokat a tulajdonságokat, amiket egy ilyen programnak tudnia illik. A többféle modellezési lehetőség elég sokfajta szemléltetési módot tesz lehetővé. Természetesen a fentebb említett diagrammokat mi is integráljuk a programba. A grafikus megjelenésű szoftver ablaka igazodik a Windows szabványhoz, éppúgy, mint a menüje is.
           

Az implementált program fantázia neve: MMUML (Magic Max Unified Modelling Language)

           

        2. Az alkalmazás helye

 

Az alkalmazás elsődleges célja a szoftvertervezés esetleges bonyolultabb műveletének megkönnyítése. Célunk az UML modellek minden lehetséges felhasználási módjának implementálása, elsődleges a szoftvertervezés támogatása. A piacon jelenlévő UML szoftverek bármelyikével felveszi a versenyt, sokoldalúsága és stabilitása miatt. Így egy abszolút piac képes és könnyen használható szoftver jöhet létre, a felhasználók nagy örömére.

         2.1 Üzleti lehetőségek

 

A project elsődleges célja a Szoftvertechnológia c. tárgy sikeres lezárása, a valóságban azonban ezen szoftverek jelentősen meggyorsíthatják és megkönnyítik a szoftverek ki –és továbbfejlesztését, ami értelemszerűen anyagi nyereséget jelent. Ha sikerül szoftverünket annyira stabillá, megbízhatóvá és hatékonnyá tenni mint azt tervezzük, akár üzleti értékesítése is elképzelhető. Célközönsége esetleg az egyéni programozók és kisvállalkozások lehetnek, akik nem akarnak túl sokat költeni egy ilyen szoftverre, mégis igényük lenne rá.

        

 

2.2 A probléma megfogalmazása

 

Az alapvető probléma az, hogy az élet igen sok területén –nem utolsó sorban a szoftverfejlesztésben - olyan bonyolult rendszereket kell teljes egészében és részletességében átlátni, megérteni, illetve leírni, hogy az egyszerű szöveges leírás ezt nem teszi lehetővé.

A rendszer megértéséhez és dokumentálásához a rendszert nézetekre és részekre (csoportokra)

szét kell szedni, és az így elkülönített dolgokat különböző absztrakciós szinteken külön-külön kell modellezni, leírni. Az UML grafikus segítséget nyújt a rendszer megértéséhez, kapcsolataival és kapcsolódó egységeivel egyértelművé teszi az összetartozó információkat, könnyen átláthatóvá téve ezzel az adatokat.

 

Az UML a jelöléseknek gazdag választékát kínálja, mely segítségével a szoftverfejlesztés összes fázisa modellezhető . Az UML a kiterjesztési mechanizmusok (pl. sztereotípusok) segítségével egyéni jelölések s azok szemantikájának bevezetésé t is támogatja, hogy minden segítséget megadjon a szoftverfejlesztőknek ahhoz, hogy könnyedén modellezhessük az akár egyéni vagy különleges rendszereket is.

 

A legmagasabb absztrakciós szintről indulva tetszőleges részletességgel képesnek kell lennünk az általunk keresett információk megjelenítésére, a részleteket elrejthetjük, de ha kell a legalacsonyabb szintű információkat is előhívhatjuk.

Mivel általában egy-egy problémán nem csak egy ember dolgozik, az UML modellnek olyan módon kell tárolni és ábrázolni az információkat, hogy az mindenki számára azonnal egyértelmű legyen. A saját feladatkörét mindenki teljes részletességben kezelheti, nem terhelik a többi alkalmazott munkáinak felesleges információi, de ha szüksége van rájuk mégis elérhetők maradnak. A szoftverfejlesztés során a programozó képes felmérni a feladatának helyét az egész projektben, és ismeri a szükséges protokollokat a többi programozó részfeladatához, képes hozzájuk igazítani a saját munkáját.

Bár a mi feladatunk a szoftverfejlesztés szemszögéből elemezni az UML modellt, manapság annyira univerzálisak ezen szoftverek, hogy a termékfelépítésektől a vállalatirányításig mindenhol használhatóak. Kifinomult kapcsolati és egyed modelljeikkel szinte bármilyen rendszer leírható.

 

Az UML modell feladata a szoftverfejlesztésben a programozó segítése a program objektumainak, osztályainak és kapcsolatainak átlátásában, megértésében. Le kell kezelnie a dinamikus kapcsolatokat, a függőségeket. Ha egy dolgot megváltoztatunk amihez egy másik dolog kapcsolódik, a változásnak automatikusan végbe kell mennie, mentesítve ez alól a program használóját. Ez a módszer az inkonzisztenciák elkerülésében egy hatékony fegyver lehet.

A szoftvernek képesnek kell lennie már elkészült programok forráskódja alapján ábrázolni az UML modellt, megkímélve ezzel a programozót a forráskód csak szöveges megértéstől. Ez jelentősen megkönnyíti, és meggyorsítja a szoftverfejlesztést, ami anyagi szempontból sem elhanyagolható.

A szoftvernek továbbá tudnia kell az UML modellből generálni a forráskódot, ami megkívánja bizonyos szabályok betartását(pl: minden szükséges információnak rendelkezésre kell állnia).

 

Az UML modell legnagyobb hatása a szoftver kifejlesztésekor közreműködő programozókra, és azokra van, akik majd a szoftver továbbfejlesztését végzik. Többnyire ezen két ember/emberek nem azonosak, így jelentős előnyt nyújt a teljes rendszer megértésben a grafikus szemléltetés.

Mivel nem kell mindenki kíváncsi a részletekre, a különböző absztrakciós szintekből aggregált információk is nyerhetők(pl: vállalatirányításnál a főnök csak az össznyereségre kíváncsi, az egyes részlegeké nem érdekli).

 

         2.3 Az elkészült termék helye


Célunk felvenni a versenyt a „konkurens” UML szerkesztő programokkal, koncepciónk egy olyan magas kategóriabeli UML szerkesztő szoftver készítése, mely lehetővé teszi az egyetem hallgatóinak az UML bemutatását egy olyan felhasználóbarát programon keresztül, mely implementálja az összes szükséges funkciót. Programozási ismeretek bővítésére is alkalmas lesz, hiszen grafikus kezelőfelülete, diagrammjai révén a C++ és Java nyelv forráskódjainak megértése, átláthatósága, változtatása egyszerűvé és gyorssá válik.

A felhasználói kört nem lehet leszűkíteni, mivel az UML világszerte egységesített szabványának köszönhetően nemcsak fejlesztőeszközként, hanem bármilyen rendszer tervezéséhez, egyszerű ábrázolásához használható, persze a szoftver elterjedtségétől függően. Tehát tulajdonképpen az UML-el és az OOP-val most ismerkedőket célozzuk meg, mivel egyszerű, könnyen áttekinthető kezelői felületet, valamint a szükséges funkciókat magába foglaló programot kínálunk. Egy korábban megírt vagy ismeretlen nagyobb terjedelmű forráskód átlátása és megértése nem feltétlenül könnyű és elsősorban nem elhanyagolható időbe telik. Ezt a problémát oldja meg ez a program méghozzá úgy, hogy a Java vagy C++ nyelven írt programot beimportálja és a kód alapján elkészíti a kívánt diagrammokat.

Az UML szerkesztők legnagyobb haszna az időmegtakarítás, ez által pedig a nagyobbfokú hatékonyság. Az adott rendszerről készült modelleket különböző nézetből ábrázoló diagrammok növelik a kezelhetőséget, az áttekinthetőséget és jól ábrázolják a rendszer komponensei közötti kapcsolatokat. Mivel a program létrehozásának elsődleges motivációja a Szoftvertechnológia című tárgy maximális teljesítése, így nem beszélhetünk professzionális szintű megvalósításról.

Mivel nagyon sok hasonló program létezik, így tulajdonképpen könnyen kategorizálható, a különbségek csupán az implementált funkciók mennyiségében jelentkeznek, mely a moduláris programozásnak köszönhetően bármikor könnyen behozható, vagyis a szoftver könnyen bővíthető. A Szoftvertechnológia című tárgy erre a feladatra vonatkozó alapkövetelményeinek megfelelően a program képes lesz GIF,JPG, HTML exportra és két nyelvű kód importra (Java, C++).

        3. Érintettek és felhasználók

A termék elsődleges célfelhasználói a C++/JAVA alkalmazásfejlesztők akiknek egy bonyolult, összetett program elkészítéséhez elengedhetetlen, hogy jól áttekinthető egyszerű képet kapjanak/készítsenek programjukról.

         3.2. Az érintettek összefoglalása

 

Elnevezés

Leírás

Szerep

Oktató (tárgy jegyzője)

Felhasználásával esetlegesen ellenőrzi a kódot, értékeli a feladatot, vagy jóváhagyja a konzulens által javasolt osztályzatot

Tanácsaival használhatóbbá tehető a program!

Konzulens

Felügyeli a fejlesztés menetét. Felhasználásával ellenőrzi a kódot, értékeli a feladatot

Ellenőriz, instrukciókkal látja el a csoportot.

Fejlesztő csoport ( HICON )

Az alkalmazás készítői.

Fejlesztés,tesztelés, dokumentálás.

Külsős programozók

Felhasználásával a programjához UML ábrát készíthet

A fejlesztésben nincs szerepe, csak később az esetlegesen előforduló hibákra való figyelem felhísával segíti a fejlesztőket

        

3.3. A felhasználók összefoglalása

 

Elnevezés

Leírás

Illetékes

Alkalmazásfejlesztők

UML ábrát készít a programjához

Bármely cég programozói, vagy magánszemélyek.

Tanárok

Az UML ábrák segítségével egyszerűen szemléltethetik a diákoknak egy program felépítését, működését

Bármely oktatási intézmény oktatója

Egy alkalmazás megrendelője

Egy áttekinthető, érthető képet kap a kapott program felépítését, működését illetően

Egy alkalmazást felhasználó cég, vagy személy

Fejlesztők

A program fejlesztése, tesztelése, javítása

A csoport tagjai.

        

 

3.4 Felhasználói környezet

 

A termék nem lesz platformfüggetlen, de a világ egyik legelterjetebb operációs rendszerén (Windows XP) természetesen futni fog..

Hardverigénye:

Egyfelhasználós alkamazás, egy időben egy példányt csak egy felhasználó tud használni!

 

3.5. Illetékesek adatai

 

Ficsor Lajos , a Szoftverfejlesztés tárgy előadója. A csoport munkáját előadásaival, ismertetett módszereivel segíti.

Elérhetősége : Informatikai – Intézet  I em. 106. szoba

                        Tel.: 17-58

                        Mail : ficsor@iit.uni-miskolc.hu

                        Home page : http://www.iit.uni-miskolc.hu/ficsor

 

Tamás István , a gyakorlatvezetőnk. Minden a feladattal kapcsolatban felmerülő kérdéssel fordulhatunk hozzá, illetve a konzultációk is vele folynak. Információkkal és tanácsokkal látja el a csoportot , felügyeli a munkánkat.

 

Elérhetősége :

                        Mail : tamas2@iit.uni-miskolc.hu

                        Home page : http://www.iit.uni-miskolc.hu/~tamas2/

 

Krizsán Zoltán , egyetemi tanársegéd, a részfeladatokkal kapcsolatban felmerülő kérdéseinkkel fordulhatunk hozzá.

Elérhetősége : Informatikai – Intézet  I em. 106/b. szoba

                        Tel.: 17-58

                        Mail : krizsan@iit.uni-miskolc.hu

Home page : http://www.iit.uni-miskolc.hu/~krizsan

         3.6. Felhasználók adatai

 

Harmadéves műszaki – informatikus hallgatók, akik a program tesztelésében, valamint a kényelmi kialakításban segédkeznek.

        4. A végtermék áttekintése

            A program egy UML szerkesztő, amely segítségével bonyolultabb programok megírása és áttekintehtősége válik lehetővé. Nagyon fontos, hogy a tervező lássa maga előtt a megoldást, ezért erre ki kellett találni egy vizuális megoldást. Egy idő után már UML diagramokban testesülnek meg a tervező gondolatai, ez sokat segít azok ledokumentálásában, illetve a tervezők közötti, valamint a fejlesztők, megrendelő, stb. felé történő kommunikációban. Az UML jól áttekinthető diagramok formájában testesül meg, vagyis a szoftver struktúráját segítségével igen könnyen szemléltethetjük. Fontos, hogy elterjedt, szabványos jelölésmódról van szó, ezért joggal feltételezhetjük, hogy a „túloldalon” is ismerik, nem azzal kell vesződni, hogy megtaláljuk a közös nyelvet.
           

Mivel egy-egy szoftvert különböző szempontokból is vizsgálhatok, a tervezésnél előkerülhetnek különböző nézőpontok, ezért az UML is többféle nézetet biztosít, amelyek együttesen adják az adott szoftver teljes modelljét.
Ha mégsem egy szoftvert szeretnénk vele jellemezni, hanem egy bonyolultabb rendszer vázát próbáljuk megértetni, arra is tökéletesen alkalmas a program, mert képes GIF/JPG kiterjesztésű képbe kimenteni az általunk megszerkesztett modellt. Mindezzel megkönnyíti a tervezést és a bemutatást adott rendszerek esetén, és itt a rendszer fogalmába bele lehet érteni egy szoftver felépítését is.
           

Többféle ábrázolási módra is képes a program, ezekből kiválaszthatjuk a nekünk legmegfelelőbbet.
           

Választhatjuk azt a megoldást is, hogy már meglévő program kód alapján generáltatjuk a programmal az UML ábrákat. Az UML szerkesztő kétféle kód importot támogat az egyik a C, a másik a Pascal. Az adott program file behívása után a szerkesztő megvizsgálja a nyelvet, próbálja felderíteni jellegzetes tulajdonságait, hogy ezt követően megfelelő UML ábrát készíthessen az adott programról.

4.1. A  termék kapcsolatai

 

            Az évek során a programtervezés súlypontja az eljárások felől az adatszervezés irányába tolódott el. Egyebek mellett ez a programok nagyobb méretében tükröződik. Az egymással rokon eljárásokat az általuk kezelt adattagokkal együtt osztálynak és az egyes funkciókat biztosító oszályokat modulnak nevezzük. A készülő termék is szintén a moduláris felépítést tükrözi, az egyes funkciókat modulok fogják biztosítani a felhasználó számára, aminek a szimbolizálását az UML szerkesztő nagymértékben megkönnyíti.
           

A program barátságos, könnyen kezelhető felülete által könnyű modell szerkesztést tesz lehetővé, ezzel biztos kapcsolatot létesít a felhasználó és a program által szerkesztett UML ábrák között.
 

Minden program születése előtt, valamilyen ötlet alakul ki a programozó fejében, hogy mit szeretne megvalósítani, mire szeretné írni a szoftvert. A legtöbb esetben egy már meglévő program adja az alapötletet, ilyenkor a szoftverek közötti kapcsolat nyilvánvaló. Közös tulajdonságok, opciók fedezhetőek fel. 

4.2. A termék használatának előnyei

 

A megrendelő haszna (előnyei)

Az ezt támogató rendszerjellemző(k)

Már kész softwerek működésének átláthatósága 

Lehetőség arra, hogy kód import segítségével az MMUML készítse el az UML ábrákat 

Egy bonyolultabb software könnyebb elkészítése

Saját magunk is elkezdhetünk kód import nélkül UML ábrákat készíteni 

Könnyű hordozhatóság és megjeleníthetőség

Az elkészített UML ábrákat kimenthetjük .jpg vagy .gif formátumokban.

Ahol Windows XP van, ott majdnem bármely gépen módosítható az UML ábránk

A program fut az egyik legelterjettebb operációs rendszeren (Windows XP)

Egyszerű kezelhetőség, felhasználóbarát környezet

A kezelőfelület nem tartalmaz fölösleges, bonyolult dolgokat, következetes és jól használható

        

4.3. Feltételezések és függőségek


Mivel az UML 1.5 – ös verziója az utolsó teljes szabványos verzió, így szükséges e szabvány használatának ismerete.

A C++ és JAVA programozási nyelvek által készített kiterjesztésű fájlok beolvasására lesz képes a program. A szotver által támogatott operációs rendszer a Windows XP. Mint UML szerkesztő tud majd más hasonló programokban készült projekteket beolvasni. Ebből következően feltételezzük, hogy a vizsgálandó fájlok kiterjesztései a következők lehetnek:

  1. .cpp
  2. .c++
  3. .cc
  4. .hpp
  5. .hh
  6. .h
  7. .h++
  8. .java
  9. .uml

Valamint feltételezünk egy minimális szintű számítógép használati ismeretet, bár ez nem feltétlenül elegendő a program minden funkciójának használatához.

A minimális rendszer igény még nem konkrét, mindenesetre célunk, hogy termékünk bárkihez eljusson és optimálisan fusson a legtöbb ember PC-jén.

Mivel a platform függetlenség a cél, jelenleg nem határozható meg ilyen jellegű korlátozás. A telepítéshez igényelt tárhely még nem határozható meg, de valószínűleg 20-30 MB körül lesz a maximuma. A telepítéshez szükséges még vagy internet hozzáférés vagy optikai meghajtó.


4.4.  Költségbecslés


Mivel a programon 5 ember dolgozik, az esetleges magasabb költségekkel számolni kell, mert időben elég sok egy ilyen program kifejlesztése. A projekten dolgozó csapattagok órabére nettó 1000 HUF A projekt végére ez összesen kb. nettó 200 000 HUF összköltséget jelent. A karbantartása nem jár költségekkel, kivétel, ha a felhasználó opció bővítést kér.        

4.5.  Installáció

A program telepítése gyerekjáték, mert szinte önműködő. Két dologra kérdez rá a telepítő, hogy hova telepítse a programot, illetve akarunk-e az alapból beállított telepítési helyen változtatni, a másik, hogy hova szeretnénk ikont kitenni a programról. Alapból a StartMenübe mindenképp tesz, emellett választható, hogy a Desktop-ra ill. QuickLaunch-ra akarunk-e kitenni vagy nem.   

5. A végtermék jellemzői, biztosított szolgáltatások

 

Hasonlóan a társaihoz ez az UML szerkesztő is megbízhatóan biztosítja azokat a tulajdonságokat, amiket egy ilyen programnak tudnia illik. A többféle modellezési lehetőség elég sokfajta szemléltetési módot tesz lehetővé. A grafikus megjelenésű program ablaka igazodik a Windows szabványhoz, éppúgy, mint a menüje is.
           
            A menü kód import pontján hívhatjuk be azt a program kódot, amiből UML ábrát szeretnénk a programmal generáltatni. A File menü Új menüpontja alatt kezdhetünk új dokumentum készítéséhez, amelyet később vagy elmentünk .xml kiterjesztéssel későbbi tovább szerkesztéshez, esetleges másik UML modellel való kombináláshoz, vagy egyszerűen egy tömörített kép formátumot választva -GIF vagy JPG- kimentünk a merevlemezre, innetől kezdve, már tovább szerkesztés nem lehetséges.
           

Érdemes mindig elmenteni a nem nagy méretű, a szerkesztő által generált .xml file-t, hogy később bármikor módosítható és továbbfejleszthető legyen. Természetesen, mint a legtöbb rajzoló programban itt is kijelölhetjük, másolhatjuk, kivághatjuk az objektumainkat, ezek az opciók a menüből is elérhetőek.
           

A kényelmet szolgálja a File menüből közvetlenül elérhető Nyomtatás menüpont is, amely segítségével közbetlenül a programból kinyomtathatjuk az UML modelljeinket.
           

A program igyekszik minden eshetőségre megoldást nyújtani, itt kell megemlíteni az automatikus mentés opciót, amely segítségével, bizonyos időközönként emlékeztet minket arra a program, hogy munkánkat folyamatosan elmentsük, mivel mindenki járt már úgy, hogy egy esetleges áramszünet, vagy rendszerhiba miatt elveszett az addig készített több órás munkája. Emellett a program minden egyes export esetén a saját könyvtárába elmenti az aktuális .gif vagy .jpg képfile-hoz tartozó .xml program file-t, így ha meggondolnánk, hogy szükségünk lenne a továbbszerkesztésre, de elfelejtettük elmenteni, a program telepítési könyvtárában megtalálhatjuk a keresett file-okat.
           

Minden program talán egyik legfontosabb része a help, egy jó súgó nagyban segít elsajátítani a szerkesztő működését, tulajdonságait és képességeit. A legfontosabb itt is az átláthatóság, a tömörség de mindemellett a közérthetűség.

        6. Korlátozások


A program platformfüggetlensége miatt nincsen szükség ilyen irányú korlátozásra. A minimum tárhelyen túl szükség van egy minimális szintű hardverkorlátozásra, mely azonban még nem konkrét. A telepítéshez pedig szükséges internet hozzáférés vagy optikai meghajtó.

        7. Minőségi elvárások

 

A könnyen kezelhető programot felhasználóbarátnak hívjuk. A felhasználóbarát programtól elvárhatjuk, hogy minél több segítséget nyújtson a felhasználó számára. Ennek jegyében a felhasználói felületet átláthatóvá kell tenni, minden funkciót könnyen elérhető helyre kell helyezni. A menünek logikus felépítésűnek kell lennie és a leggyakrabban használt funkciókhoz gyorsgombokat helyezhetünk el a kezelői felületen, esetleg billentyűkombinációkat rendelhetünk hozzájuk a gyors kezelés végett. Mivel a program lényege grafikus segítségnyújtás, nyilvánvalóan lesz egy grafikus felülete, ahol dolgozhatunk, létrehozhatunk objektumokat és kezelhetjük őket. Lehetőség nyílik a „forráskód” megtekintésére is, vagy akár osztott képernyőn mindkettőjére.

 

A felhasználó segítségére lesz továbbá egy HELP menü is, ahol minden a programmal kapcsolatos kérdésére megpróbálunk választ adni. Ez tartalomjegyzék, vagy kulcsszavas keresés alapján is lehetséges.

 

Bár a program forráskód-UML, és UML-forráskód generálása nem real-time feladat, nem lenne szükség nagy teljesítményű számítógépre, a grafikus része miatt azonban mégis ajánlott. Az UML ábrák kirajzolása, mozgatása real-time, és nagy rendszereknél nagyon is sok lehet belőlük ezért viszonylag nagy teljesítményű képmegjelenítőre, videokártyára van szükség. A hosszabb időt igénybe vevő feladatokhoz mindeképp szükség van a felhasználó tájékoztatására, pl.: folyamatjelző csík.

 

Adatvédelem szempontjából szükséges legalább jelszavas védelmet alkalmaznunk, mivel munkánk jogtalan eltulajdonítása, felhasználása, törlése, jelentős anyagi kárt jelenthet.

Hálózati környezetben való alkalmazása esetén a hálózati azonosításokhoz is külön védelmet kell kidolgoznunk, pl:titkosítás. A már elkészült projekteket is titkosítva kell tárolnia a gépnek, hogy lemásolásuk esetén ne legyenek felhasználhatók csak a jelszó birtokában.

 

A program automatikus mentésekkel fog védeni az áramkimaradásokból és egyéb hibákból származó veszteségek ellen, melyet egy history is kiegészít.

 

A program minden funkciójának helyes működéséről alapos, körültekintő, minden eshetőségre kitérő teszteléssel győződünk meg!

A program telepítése automatikusan egy saját telepítő (install) elindításával történik.

        8. Dokumentációkkal kapcsolatos követelmények

 

Előző elképzeléseink alapján többféle - több irányt megcélzó - dokumentáció elkészítését tűztük ki célul.

·        Először is egy teljes körű leírást, alaposan kitérve minden momentumra. Ezt hozzáférhetővé tesszük az összes felhasználónk számára.

·        Az analízis fázis dokumentációja, ami nem tiszta forráskód, Microsoft Word vagy OpenOffice formátumban kell beadni. A dokumentumok csak egyszerű formázott szöveget (Times, Arial vagy Courier fontokkal), táblázatokat és beillesztett képeket tartalmazhatnak. A tartalmat decimális számozású fejezet – alfejezet rendszerbe kell rendezni, és tartalomjegyzéket kell generáltatni. A Word dokumentumoknak az Office2000-el, Az OpenOffice dokumentumoknak az 1.1.3 verzióval olvashatóknak kell lenniük. A dokumentumok file-neve csak ékezet nélküli betűket, számjegyeket, a kötőjel és az _ (aláhúzás) karaktereket tartalmazhat. (Helyközt sem.) Ha egy dokumentumot több verzióban is el kell készíteni, a névnek a verziószámra is utalnia kell.

·        Specifikációs fázis dokumentuma.

·        Tervezési fázis dokumentuma.

·        Jegyzőkönyvek illetve munkanaplók, a jegyzőkönyvre kizárólag a címlap kinézetének kikötése van, a formai megjelenés az esztétikusságra és a pontosságra kell hogy törekedjen. A munkanapló tartalmára és kinézetére erős megkötések vannak, amelyeket be kell tartanunk.

·        A csoport vezetője rendelkezik ezenkívül a csoport értékelésére vonatkozó dokumentummal, amely tagokra lebontva táblázat formájában százalékos értékelést tartalmaz.

·        Írunk egy a felhasználók számára, a program használatában segítő dokumentumot, melyet a program felületéből is elérhetővé teszünk (Súgó).

·        Ezen kívül tervezünk egy reklám célt szolgáló szórólap tervezetet, melyet egy esetleges reklámkampány során sokszorosításra felhasználhatunk.

·        Elkészítünk egy internetes, ugyancsak reklám célra felhasználható hirdetési képcsíkot, melyet más oldalakon jeleníttethetünk meg.

Az összes dokumentáció szerkesztésekor egyaránt ügyelni kell a pontos, áttekinthető, logikus szerkesztésre!

        9. Kockázat lista

 

A határidő(k) esetleges be nem tartását (, az eredménytelenséget) több dolog is előidézheti melyekre, ha lehetséges előre föl kell készülnünk.

Ilyen tényezők lehetnek:

·        Egy tag elhalaszthatatlan dolga folytán kimarad egy megbeszélésből. Ilyen lehet pl.: egy családi, illetve valamilyen hivatalos ügy... .
Ebben az esetben, ha fontos a megbeszélés tárgya, tehát elengedhetetlen a jelenléte akkor, ha lehetőség van rá el kell halasztani a megbeszélést! Azonban ha ez nem lehetséges, illetve nem fontos az illető részvétele, akkor elegendő a megbeszélést követően az első adandó alkalommal tájékoztatni!

·        Egy tag elhalaszthatatlan dolga folytán hosszabb időre kiesik a fejlesztésből. Ilyen ok lehet pl.: betegség, műtét, családi ügy… .
Ilyen esetben rögtön meg kell szervezni a tag munkájának ellátását: vagy a munka szétosztásával, vagy esetleg új ember valamilyen szintű beszervezésével.

·        Veszélyt jelenthet a rossz vezetés, illetve a hanyagság. Ilyenkor minél hamarabb dönteni kell a tag sorsáról, illetve a projekt további menetének alakulásáról.

·        A tagok munkájának rossz ütemezése. Ezt úgy kell megoldani, hogy a kiosztott részfeladatok lehetőleg párhuzamosan futhassanak, ne kelljen a másik eredményeire várni, csak ha ez elkerülhetetlen!

·        Tagok közti rossz kapcsolat! Semmilyen munkahelyen nem engedhető meg viszály, ellenségeskedés a munkatársak között. Ezeket nagyon szigorúan meg kell szüntetni különböző intézkedésekkel! A tagok közti harmonikus kapcsolat fenntartásához szükség van az egyenlő munkamegosztás megteremtésére, és az egyéni feladatok időbeni elvégzésére!

·        Problémát jelenthet, hogy 3. évesek lévén csak idén, párhuzamosan kezdtünk el foglalkozni a Java nyelvvel (mely az implementációs nyelv a feladatunkban), ezért valószínűleg nehézkesebben megy majd a feladat készítése. Ez a probléma kellő szorgalommal, és odaadással megoldható!

·        Szintén nehézségek támadhatnak abból, hogy eddig még egyik tag sem vett részt ilyen jellegű, és nagyságrendű több fős munkában. Kellő odafigyeléssel azonban ez a probléma is leküzdhető.

 

A kockázatokkal szembeni fölkészülés gyökerét a megfelelő időbeosztás képzi! Mindig, mindent időben el kell végezni, ha mód van rá, akkor esetleg korábban is, így mindig marad idő egy közben felmerülő probléma megoldására, és nem érheti szinte semmilyen meglepetés a csapatot. Fontos lehet a tájékozottság szerepe a többiek munkájára nézve, ez ugyanis elengedhetetlen, ha helyettesítenünk kell egy társunkat.

       

 

 

10. Szótár

UML (Unified Modelling Language)

Egységesített Modellező Nyelv
Grafikus, valamint lehetőségünk van a probléma specifikációjára, megoldására a megoldás dokumentálására.

sztereotípus

Dolgok körének bővítése. Mivel az UML nem képes a világ összes bonyolult rendszerének modellezésére. A sztereotípus segítségével az UML elemei bővíthetők.

szemantika

A jelentéstan tudománya, a nyelv szavainak jelentésével, azok árnyalataival és változásaival foglalkozik.

implementált

 végrehajtó (program)

absztrakció

elvont fogalom, elvonatkoztatás

inkonzisztens

A szabályoknak nem megfelelő, ellentmondásokat tartalmazó.

forráskód

(source code) számítógép-program, amit később gépi kódra fordítanak. Forrásnak (source) és forrásnyelvnek (source language) is nevezik.

aggregál

összegez

import

importálás, behívás

program file

Azon fájl, mellyel az adott alkalmazás elindul.

real-time

valós idejű

telepítés 

A program telepítése a számítógépre. A program működéséhez szükséges fájlok felmásolása, és a szükséges beállítások elvégzése

felhasználóbarát

Könnyen kezelhető, logikus felépítésű, jól átlátható program