4. Fejezet Objektum-modellezési technikák

Ebben a fejezetben a fejlesztés során alkalmazható technikákat mutatja be.
Elso nagy csalódásom a Rendszer-diagram ismertetésénél következett: A minta példa - könyvtár, könyv

nyilvántartó, kölcsönző, stb funkciókkal, és a könyvtár alkalmazottait valamint a kölcsönzőket a redszer határain kívülre helyezi, holott mind a két szereplő a rendszer fontos része - ugye, a kölcsönző a rendszer végfelhasználója.

Örömmel láttam amúgy, hogy a használati esetek (use case) kidolgozásának alapjául a funkció listát, és a funkciómátrixot határozta meg - ez is bizonyítja, nem hülyeség, hogy az SSADM-et jó kiindulásnak tartom az üzleti modell elkészítésére /csak, hogy dícsérjem magam :))/.

A technikák ismertetése szerintem jó - habár nem egy jelölésrendszerről beszél, de az a következo könyv témája -, az összes alapvető tudnivaló megtalálható.

5. Fejezet Az OO fejlesztés életciklusa

Ennek a fejezetnek a célja az, hogy egy átfogó képet adjon a fejlesztés életciklusáról.
Ismertetésre kerülnek a fejlesztés egys fázisai.

Ez az a fejezet, ahol először találkoztam olyan dolgokkal, amikről egyértelmuen tudjuk, hogy szüségesek és fontosak, mégis, az esetek nagy részében már annak örülünk, ha valami hasonlót, halványan hasonlító dolgot létrehoznak.

Elég rövid fejezet, ismerteti a főbb fázisok által igényelt tevékenységeket, és a célokat.

1. Kiindulási fázis
   
   Projekt-terv készítése
   
   
2. Elemzési fázis
   
   
   
   1. Probléma tér definiálása
      
   2. Üzleti modell kialakítása
      
   3. Követelmények elemzése és specifikálása
      
   
   
   Egy igen jó észrevétel a könyvben:
   
   Fontos hangsúlyozni, hogy az elemzési munka nem felesleges tevékenysége, hanem a fejlesztési folyamat olyan, az eredmény, a szoftvertermék minősége szempontjából meghatározó feladat, amellyel elkerülhetőek az önkényes, vagy végzetesen hibás tervezési és implementációs döntések!
   
   • Tervezési fázis
     
     
     
     1. Logikai, avagy konceptuális tervezés
        
     2. Fizikai tervezés
        
     
     
     Megjegyzés:
     
     Nem igazán értek egyet a konceptuális (értsd, fogalmi szintű) tervezés és a logikai tervezés összemosásával, de annyira nem zavaró.
     
     • Építkezési fázis
       
     • Elfogadás, átadás
       
     • A rendszer üzemeltetése, karantartása
       

Külön kihangsúlyozza, hogy ezek a lépések nem választhatóak élesen el, és hogy iteratív szervezésű fejlesztésről van szó.

Ezután a fejlesztés architektúrájáról beszél, a nagyobb feladatok esetén szükséges részfaladat megosztásról.
Ebben a fejezetben ismét zavar engem, hogy rendszerkommunikáción kizárólag a gép - felhasználó, valamint a gép - periféria kapcsolatokat érti, ami egy rendszer esetében abszulút nem reális megközelítés, pontosabban mondva túlzottan program szemléletű.
Egy banki rendszer esetében ugyanis igen fontos lehet többek között az ügyintéző - ügyfél kommunikáció, ami szintén a rendszer keretein belül kerül megvalósításra, és mint ilyet illene figyelembe venni, hiszen - ahogy Halassy-nál is olvasható - a rendszer végfelhasználója nem az ügyintéző, aki a monitort nézi, hanem az ügyfél aki sorban áll és kitölti az űrlapokat. És egy rendszertervben igenis figyelembe kell venni a nem számítógép által megvalósított funkciókat is.
Amennyiben viszont ezeket nem vesszük figyelembe, akkor nem rendszer fejlesztésről beszélünk, hanem alkalmazás fejlesztésről.

Nos, miután így kimorogtam magam, eljutottam a könyvben a modellnézetekek tárgyaló részhez, ahol kibújt a szög a zsákból:

"...és végtermékként egy a valós rendszer működését támogató szoftver-rendszert szolgáltat."
"Tekintettel arra, hogy a szoftverfejlesztés folyamat-jellegét kívánjuk hangsúlyozni..."

Ezek szerint a problémát eddig az okozta, hogy nem tisztázta a könyv szerzője, hogy ő kizárólag a
szoftver fejlesztésről beszél, ellenben sok helyen félreérthetően fogalmazott.
Tanulság: TIsztázzuk, hogy mit jelent a rendszer szó a könyv keretein belül. A fogalomjegyzékben
ugyanis minden kifejezés jelentése le van írva, csak a rendszer meghatározása hiányzik.
Azért ezt illett volna beletenni, vagy az elején tisztázni.
Pláne, hogy a fogalmat nem konzekvensen használja. A rendszer hol szoftver-rendszert jelent - lásd fenti idézetet-, hol pedig ténylegesen a szervezetet, amely a fejlesztendő alkalmazással szembeni elvárásokat támasztja.
Azért ez kicsit bekavar. Használna minősítőket: szoftver rendszer, valós rendszer.

Mindenesetre ez a fejezetrész tisztázza azt, hogy amikor a rendszerről, mint a fejlesztés tárgyáról van szó, akkor kizárólag a szoftverre gondol.

--------------------------------------

Most pedig nekilátok a hatodik fejezetnek, ez már igen érdekes lesz. Eddig ment a mese - amúgy összességében nagyon jó eddig, az említett hiányosságokat illetve negatívumokat is figyelembe véve.