OFF!
Jellemző a magyar informatikára, hogy a dokumentum MS-Word formátumban van megírva.
Másutt azért figyelnek arra, hogy az ilyen publikus szövegek valamilyen gyártófüggetlen formátumban vagy szabad kategóriába eső szoftverrel olvashatóak legyenek.
De még ezt is lehet néha fokozni. Egy országos szerv kiadott egy terjedelmes dokumentumot, több (!) *.doc fájlban. Néhány fejezet Word x, néhány fejezet Word x+1.
Kiváncsi vagyok mit alkot ezen a területen az új minisztérium.
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.
Kiindulási fázis
Projekt-terv készítése
Elemzési fázis
Probléma tér definiálása
Üzleti modell kialakítása
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
Logikai, avagy konceptuális tervezés
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ójanem 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.
1 Fejezet Paradigmaváltás az alkalmazásfejlesztésben
Kis történeti áttekintés az OO eredeteirol, kiváltó igényekrol, valamint megtudjuk, hogy a komponens alapú fejlesztést eloször az Ericson vezette be a '60-as évek második felében, valamint azt, hogy az UML alapjául szolgáló SDL specifikáció és leírónyelv szabványt 1976-ban vezette be a CCITT. Az SDL volt az elso hivatalos OO szemléletu szabvány.
2. Fejezet Az objektumszemlélet sajátosságai
Rövid bevezetés abba, hogy mit is takar, mért jó, és egyáltalán mi az értelme az objektum-orientált szemléletnek.
Egész jó, bár elojön Raffai gyerekbetegsége - beszédusz külfölditisz, ami sajnos igen erosen rányomja a bélyegét a könyvre.
Mi az isten akar lenni a Paradigma Szinergia??? A legjobb még az objektum példánynak objektum instanciaként való megnevezése.
3. fejezet Az objektum-modell
Kezd komolyodni a dolog, alapveto fogalom tisztázás. Elso meglepetés, amikor azt mondja, hogy az objektum modell attribútumainak függoségi viszonyát legalább harmadik normálformára kell alakítani.
Normalizálásról még sehol nem olvastam ebben a témában, de o ezt Booch-tól idézi, az az ember meg ért vmit hozzá. Meg különben is, teljesen logikus.
A fogalom magyarázatoknál kiderül, hogy ahány koponya, annyi definició: Az objektumra 6 különbözo definíciót hoz - igaz, kiemeli az OMG Konzorcium definícióját - de érdekes, hogy Booch, Coad-Yourdon, Shlaer-Mellor, Martin-Odell és Kondorosi definíció között elég sok eltérés van. A végén leír egy disztillált változatot, ami a különbözo definíciók közös pontjai foglalja össze.
Megjegyzés [Az objektum a valós világ valamely elemének, vagy az elem egy absztrakciójának egy konkrét megnyilvánulása, amely lehet érzékelheto, de lehet az ember számára érzékelhetetlen is.]
Na ennyiben bírnak megegyezni az agyak, úgyhogy mi is egész jól állunk a meghatározással
Külön probléma, ami ebben a könyvben is jelentkezik, hogy folyamatosan keverednek a rendszer és program szereplok, foglamak.
entitás típusú objekum: számla, dolgozó, felhasználó, stb
interfész objektum: olyan objektumok amelyeknek a feladata a rendszer környezetével való kommunkiáció példák: ablak, képernyokép, kommunikációs protokoll, nyomtatott output.
Ha a rendszerrol beszélünk, akkor az interfésznél példának mondjuk az ügyintézot és az üzleti kapcsolattartót is meg kellett volna említeni, nem csak a program és a felhasználó közti kapcsolattartó elemeket. Ha meg csak programról beszélünk, akkor azt ne hívjuk rendszernek.
Másik hiba, ami kifejezetten irritál engem, az amit már korábban is írtam, de mégegyszer, csak hogy teljes legyen a kép:
"Az általános osztályt alaposztálynak (superclass), a speciális jellemzőkkel ellátott ostályt pedig származtatott osztálynak (subclass) nevezzük. Mivel a szuper és subosztályokra vonatkozóan..."
Bevezet egy elnevezést, és már nem is használja. Tudom, hogy irodalmilag kerülni kell a szóismétlést, de ez egy szakkönyv ami fogalmakat tisztáz, itt nem feltétlenül kéne tobzódni a szinonímákban.
Egészében véve az osztály jellemzoit egész jól ismerteti - negatívumként említeném a szándékosan több jelölési rendszer alkalmazását /egyik diagramm UML, a másik Booch, a harmadik OMT, kicsit zavaros/ és az idegen szavak fölösleges használatát.
Pédlául:
Példány helyett instancia, jelölésrendszer helyett szimbolizáció, számosság helyett multiplicitás, hogy csak néhányat említsek.
A minták, példák világosak, áttekinthetoek, a magyarázatok jók, /pl. az n-ed rendu kapcsolatokat érthetoen elmagyarázza/, és még az asszociációs osztályt is ismerteti. A fejezet utolsó része az objektummodell kialakításáról szól, tömören, röviden, de szerintem érthetoen, végül még az objektum dokumentációról is ír 2 1/2 oldalt - bár aki már látott igazi dokumentációt, annak siralmasan halvány ismertetonek tunik, Mondhatnánk, felesleges két oldal.
Mindazonáltal a fejezet jó, figyelembe véve, hogy a modellezés bovebb elemzésérol szól az ezt követo 302 oldal.
Elkezdem a rövid könyvismertetőt, egyenlőre az első három fejezet ismertetése jön, holnap szerintem meglesz 4. 5. fejezet, de a 6. (A fejlesztés folyamara) az elég izmos, úgyhogy az leghamarabb pénteken - szerintem. Aztán ha elég ügys vagyok, lehet, hamarabb is meg lesz.
'akkor vajh miért van az, hogy minden esettanulmány ezen lovagol - Panel -> Picture Box, Button, ListBox... '
Szerintem azert is lehet, mert a felhasznaloi feluleteket eleg sokan programoznak es ma mar az ehhez kapcsolodo megoldasokon (pl: a Borland fele Visual Component Library) elegge jol lehet tanitani az OO alapelveit.
Ugyanakkor nem győzzünk terjeszteni az igét, hogy a Visual Basic minden tévhit ellenére nem objektumorientált :)) Legalábbis a 6.0-ig. a .NEY meg szépen mondva Visual Basic.NOT :)))
Az SSADM nem eléggé ügyfél orientált.
Nem tudom, nekem eddig nem volt ezzel gondom - az is igaz ugyan, hogy a követelmények összeszedésének módja nincs meghatározva az SSADM által.
Az a tervezéshez, eléemzéshez adottnak tekinti a követelményjegyzéket.
És annak folyamatos bővítését.
Persze, az is igaz, hogy követelmények összeszedésére eddig nem nagyon volt módom - valahogy nem rajongtak a főnökeim az ötletért, a megrendelő meg általában a: "Ti vagytok a programozók, ti nektek kell tudni" kezdetű örökzöld slágert dalolták :))))
Aha igy mar vilagosabb. Akkor te egyszerre csinalod a business modelling, kovetelmenyek felallitasa + tervezes folyamatokat es az SSADM -t hasznalod az elso kettohoz es OO -t a harmadikhoz. Szerintem nyero kombinacio, de ezt ugyis te erzed :)
'De ha gondolod, netről ingyenesen letölthető az SSADM kézikönyv magyar fordítása - röpke 400 oldal, úgyhogy nem is sok.'
Mi a cim?
Dumalgattam az egyik kollegammal, aki a system analyst, o allitja ossze a use case-eket es ismeri a SSADM -t is. Azt mondta, hogy az SSADM nem a program tervezesre jo (mintahogy neked se jott be), hanem a kovetelmenyek felallitasahoz. A fo problema az a SSADM onallo alkalmazasaval, hogy nem elegge ugyfel orientalt, mert a rendszer mint valami elvont jelenik meg. Mig ha use case - kel le lehet rogziteni, hogy mi az amit az ugyfel akar.
'akkor vajh miért van az, hogy minden esettanulmány ezen lovagol - Panel -> Picture Box, Button, ListBox... '
Szerintem azert is lehet, mert a felhasznaloi feluleteket eleg sokan programoznak es ma mar az ehhez kapcsolodo megoldasokon (pl: a Borland fele Visual Component Library) elegge jol lehet tanitani az OO alapelveit.
'Ha esetleg van rá igény, akkor szóljatok'
Szolok :)
Volt egy korabbi munkam, ha lesz idom akkor elokeresem, szerintem nem rossz ahhoz, hogy filozunk az OO -rol.
Ja igen.
Ha valakit esetleg érdekel, gondolkoztam azon, hogy felteszem a honlapomra majd a diplomamunkámat - SSADM alapú rendszerterv.
Na nem egy mestermű - pláne, hogy úgymond, szűkíteni kellett tartalmilag -, viszont azt, hogy mi módn néz ki egy SSADM-es dokumentáció, és egy kisebb rendszerrész terve, azt jól lehet rajta látni.
Na igen.. De hát ugye..
Én alaposztályt vagy esetleg ősosztályt használnék.
Mondjuk a következő oldalon van egy táblázat, ott 4-4 szinoníma van az örökítő és az öröklő osztály kifejezésére.
Ott a szuperosztály a super-class-ból jön, az alaposztály angol megfelelőe pedig a base-class.
Kulon orom, hogy a 'super' jelentese 'felett', igy a 'superclass' es az 'alaposztaly' pont ellenkezo ertelmet sugall. (Szerintem itt a magyar szo sokkal kifejezobb).
Aranyköpés a könyvből - na ezektől tudok falramászni
"Az általános osztályt alaposztálnyak (<Í>superclass), a speciális jellemzőkkel ellátott ostályt pedig származtatott osztálynak (subclass) nevezzük. Mivel a szuper és subosztályokra vonatkozóan..."
Bevezet egy elnevezést, és már nem is használja. Tudom, hogy irodalmilag kerülni kell a szóismétlést, de ez egy szakkönyv ami fogalmakat tisztáz, itt ne használjunk szinonímákat!!!!
Másik topic: A programozásról mint szakma.....
abba írtam a te hozzászólásodra...
olvasd el kérlek :D
ja bizonyos informatikai (főleg programozás) könyvekkel ez a bajom:
elején marha részletes..aztán már az írója se érti
..
egy Delphi könyvben olvastam pl. ülésszakról az adatbáziskezelésnél, te tudod mi az?
nekem leesett elég hamar mert véletlen épp előtte olvastam angolul is ilyet...
de én járok erre
másik topicban is vartyogtam vmit...
arról hogy összevissza mennek a tervezések a cégemnél...pedig ez elvileg egy 130 fős ebből kb 60-70 programozó) cég...
BME-n írt valaki egy programtervező posztgrad képzést de nem találtam a neten....
amúgy én is úgy látom hogy valós példáknál minden könyvbeli okos ábratípus áttekinthetetlenné válik
a méretek miatt...
annyi mindent lehetne tanulni...
UML mélyebben
OOP mélyebben...
kíváncsian várom könyvkritikáidat :)
Talán azért, mert vannak, akik a valós problémákkal foglalkoznak. Ők azonban időhiány vagy lustaság okán nem írnak olyan rendszert, ami elméletileg hibátlan és így publikálható lenne.
Szerintem is felesleges, de akkor vajh miért van az, hogy minden esettanulmány ezen lovagol - Panel -> Picture Box, Button, ListBox...
Ezek szerint nem jól láttam a dolgot :)))
Természetesen: 'Ezek szerint jól láttam a dolgot :)))' akart lenni :))
Ezt mar korabban meg akartam kerdezni, hogy szamodra mi a program es a rendszer kozotti kulonbseg?
Számomra a rendszer az maga a cég. Ha konrét esetet akarok mondani, akkor előhozhatom a diplomamunkámat, ami egy távoktatási rendszerterv egy része.
Itt a rendszerbe beletartozik aa tananyag, tanterv kidolgozása, munkafeladatok kiosztása, ellenőrzése, a konzultációk, gyakorlatok számonkérések lebonyolítása, a tanulás, stb.
Ezek után a meghatározott funkciókhoz egy, vagy több alkalmazást kell készíteni - például a hallgatók által interneten elérhető, különböző eseményekre való jelentkezést, tanulmányi eredmények megtekintését segítő Web alkalmazás, és tanulmányi osztály által az események megszervezésére használt windows alapú alkalmazás külön program, de ugyanannak rendszernek a része.
Egyszerűen megfogalmazva: a rendszer a szervezet által végrehajtott dolgok összessége, a program(ok) pedig az(ok) az eszkör(ök) amelyek ezt segítik.
Az SSADM pedig kifejezetten erre jó - adatbázis terv, adatfolyam diagram (ki, mivel, mit csinál), ebből aztán funkcióleírások (ezekből lehet azOO-s program tervezésnél Use Case-t csinálni), lekérdezési útvonalak tervezése, egyedtörténeti diagrammok - elég adatközpontú -, stb.
Szerintem Bana István: Az SSADM rendszerfejlesztési módszertan című könyve jó betekintést nyújt. De ha gondolod, netről ingyenesen letölthető az SSADM kézikönyv magyar fordítása - röpke 400 oldal, úgyhogy nem is sok.
OOP-nál ami szerintem igen nagy nehézséget okozhat, és amin elcsúszhat az egész, az az objektumok felismerése' Ez igaz, de en ezert szeretem :)
Na igen, a nehézségben a szépség :)) Probléma az, hogy általában ez az amit a legkevésbé oktatnak. Ezért lenne jó, ha lehetne találni esettanulmányokat, és nem csak "Pistike golyót lök az asztalon", meg "Tanuló jelentkezik a nyelvkurzusra" méretű és bonyolultságúakat.
Hmm, de ez szerintem nem is a designer dolga eldonteni. A Rational Unified Process-nek erre van a system analyst szerepe. O allitja fel, hogy mik a funkcionalis es nem-funkcionalis kovetelmenyek.
Na ebben van valami :)))
Igen, csak OO-hoz nem találtam semmi olyat, ami a Használati esetek meghatározását komolyan segítené.
SSADM szerintem pont ebben nagyon jó.
'De amikor vizuális felületnek kéne megcsinálni az OO tervét, az valami iszonyatos tud lenni' Pont azert felesleges a teljes reszletesseggel ezt megadni, szerintem.
:)) Ezért mikor ezt kérték tőlem - persze utólag, mer mikor máskor - rászabadítottam a Rose-t, aztán meg is volt az osztály diagram. :))))
Szerintem is felesleges, de akkor vajh miért van az, hogy minden esettanulmány ezen lovagol - Panel -> Picture Box, Button, ListBox...
Ezek szerint nem jól láttam a dolgot :)))
Oké, megint hosszú voltam, csámcsogok az új könyvemen kicsit, a orítója tetszik :))))
Majd írok véleményt.
