'amikor el kell döntenem, hogy mit csinál a program.'
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. Ot gyakorlatilag nem is kell, hogy erdekelje, hogy a szoftver hogy csinalja, amit csinal, OO vagy nem OO. Valami ilyesmi az SSADM is?
'Objektumorientáltan ugyanis - legalábbis nekem - az adatbázis és a program közti kapcsolat, ki mikor, mit csinál, elég nehézkesen modellezhető'
Teljesen egyetertek, tenyleg nehez, reszben szerintem azert mert altalaban ha adatbazisban gondolkodunk, akkor zommel relacios adatbazis van a szemunk elott, tablak meg SQL es ezt nem konnyu lekepezni objektumokra. Vagyis inkabb nem trivialis.
'Úgyhogy én azt hiszem, hogy az objektumorientált egyelőre a program tervezésre kiváló, rendszertervezésre nem annyira szeretném egyenlőre használni.:)) '
Ezt mar korabban meg akartam kerdezni, hogy szamodra mi a program es a rendszer kozotti kulonbseg?
'Te amikor tervezel, komolyan figyelembe veszel minden gombot, cimkét, stb-t mint külön objektuomot, vagy egy felület - egy objektum megközelítésben használod az OO-t. '
Ooo, dehogyis, eloszor is szerintem nem erdemes tervezni UI feluletet, illetve nem ezt akartam irni, szoval egy UI tul osszetett ahhoz, hogy erdemes legyen vele az osszes listat, gombot azok funkcioit UML - lel lemodellezni. Nem baj, de tul sokaig tart es mire kesz lennel, egy programozo hamarabb kesz van magaval a felulettel (lasd Delphi, C++Builder, visual cuccok). En csak kijelolom, hogy mi az amit a UI - nak csinalnia kell a tervezes szempontjabol (melyek azok a fuggvenyek, amelyeknek mindenkeppen letezniuk kell es azok mit csinalnak). Az mindegy (nagyjabol), hogy az gombnyomasra, menubol vagy mindkettobol hivodik meg.
'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.
Fontosabb az un. business objektumok tervezese, ami a program lenyege szerintem.
'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 :)
A Műszaki Könyváruházban taáltam három könyvet, egy sorozat első három kötetét - nem biztos, hogy lesz folytatása, de előfordulhat :))
Raffai Mária: Objektumok az üzleti életben - Az objektumorientált fejlesztés elvei és módszerei
/ 3200 Ft./
Ez egy bevezető műnek néz ki.
Raffai Mária: Egységesített megoldások a fejlesztésben - UML modellező nyelv / RUP módszertan
/3917 Ft./
Ez az UML-lel és a Rational Unified Process (RUP) fejlesztési módszerrel foglalkozik.
A harmadik címe nem jut eszemnbe, mert csak az első kettőt vettem meg, az a Rational Rose-zal foglalkozik, valamint esettanulmány van benne - és méghozzá nem egy háromobjektum egy aktoros, ha jól láttam, hanem egy picit komolyabb.
Ez utóbbi 4125 Ft-ba kerül.
A könyvről, ahogy olvasom folyamatosan - mondjuk témánként - írok egy ismertetőt, ami ugyan nagyon szubjektív lesz, viszont garantáltan az én véleményemet fogja tartalmazni, és egyáltalán nem lesz objektív :))))
Ha esetleg valaki megveszi, vagy már beszerezte, kérem írja meg a véleményét.
Az asszociáció az a kapcsolatnak a neve infromatikusiul. :))
Aggregáció meg a tartalmazó kapcsolat.
Pl. Kutya és a lába, dialógus ablak és gomb :))
A szoros aggregáció meg az, amikor van egy fő objektum ami nélkül az alobjektumok nem létezhetnek, viszont az alobjektumok nélkül a főobjektum sem létezhet.
Számomra súlyos hiba ott kezdődött, hogy a "módszer" amit tanítottak, egyszerűen igen nehezen alkalmazható arra a fázisra, amikor el kell döntenem, hogy mit csinál a program.
Az SSADM szerintem ebben jó - meg tudom tervezni, hogy mit akarok csinálni, milyen szereplők, milyen adatokkal, mit csinálnak.
Viszont SSADM-ben nem lehet rendesen programot tervezni.
Kiválló képet ad, hogy mit kapok, de amikor a logikai feldolgozástervezéshez jutsz, akkor nagyon kell kapaszkodni. Szerintem nem az igazi.
Szóval amikor már a funkciók megvannak SSADM-ben, akkor jöhet az OOP - funkció = használati eset.
Objektumorientáltan ugyanis - legalábbis nekem - az adatbázis és a program közti kapcsolat, ki mikor, mit csinál, elég nehézkesen modellezhető. Ez persze lehet az én hibám is, de azt hiszem a végeredménynél tök mindegy kinek a hibájából rossz.
Szóval én az SSADM-et használnám a funkciók megtervezéséig, és amikor a program tervezési része jön, akkor váltok át objektumorientáltra.
OOP-nál ami szerintem igen nagy nehézséget okozhat, és amin elcsúszhat az egész, az az objektumok felismerése.
Ugye, klasszikus tanpéldáknál általában a 3 felhasznál, 2 használati eset, 4 objektum szintig jutnak el. Sajnos ezek a példák csak a fontos kérdésekre nem adnak választ.
Nekem fő problémát OOP-nál a Case eszközök által erősen forszírozott asszociáció keveredés okozott.
Ugyanis az a baj, hogy az UML csak a jelölésre ad útmutatást, de pl. még egy CASE rendszert nem láttam amelyik korrekt módon használta volna az aggregációt mint olyat.
A struktúrált tervezés program esetén nem igazán jó.
Viszont egy rendszer tervezésekor átláthatóbb. És mivel a rendszerek mindig struktúráltak, ezért arra jobb mint az objektumorientált.
Úgyhogy én azt hiszem, hogy az objektumorientált egyelőre a program tervezésre kiváló, rendszertervezésre nem annyira szeretném egyenlőre használni.:))
Salsa, akkor kérdésem van:
Te amikor tervezel, komolyan figyelembe veszel minden gombot, cimkét, stb-t mint külön objektuomot, vagy egy felület - egy objektum megközelítésben használod az OO-t.
Nekem ugyanis főleg a vizuális elemeknél támadnak gondjaim az OO-val.
Amíg nincsenek ablakok, listák, stb-k, addig oké.
De amikor vizuális felületnek kéne megcsinálni az OO tervét, az valami iszonyatos tud lenni. Itt jött ki az is, hogy pl. a Rose nem képes a gombot aggregációban kezelne - pedig elvileg az lenne.
Másik kérdés - az átmeneti asszociációkat (függvény közepén deklarálom, nem az osztály változók között) hogy ábrázolnád?
Végülis van kapcsolat.
Hirtelen most ennyi, baj az, hogy jelenleg egy 100% SSADM projekten dolgozom, annak is a nem igazán kedvelt részén - feldolgozás tervezés -, és nem nagyon áll most rá az agyam az OO problémáimra :))
Nehany szo a Iskola vs. Tanulo problemarol: szerintem is mind a ketto methodus (Iskola.AddTanulo(tanulo) meg a Tanulo.Beiratkozik(iskola)) jogosult LEHET es tenyleg a problema asszimetrikus ( a Tanulo.Beiratkozik - ban meghivodik a Iskola.AddTanulo), de ez igazabol esetfuggo, lehet hogy a tanulot nem kell modellezni osztalykent, akkor nem biztos hogy van Beiratkozik methodus. Az hogy milyen osztalyt csinalunk milyen metholdusokkal, azt nem egy 'altalanos elv' donti el, hanem a rendszer kovetelmeny (legalabbis tervezes soran). Az Iskolanak nem azert van egy AddTanulo methodusa, mert ezt jogosnak erezzuk, hanem mert a kovetelmenyekbol ezt vezettuk le.
'Ezért is szeretném megkérdezni, hogy van-e valaki, aki már komolyan tervezett Objektumorientált programot?'
En terveztem komolyan OO programot, osztalyokbol allt es mukodott, nagyjabol most is ezt csinaljuk :)
'Akkor rátaláltam pár súlyos hibára az OOP szemléletben, azóta esküszöm az SSADM-UML hibridre :))))'
Errol a rajongok tobbet akarnak tudni :), mi az a sulyos hiba? Nyilvan az OO sem tokeletes, de jobb mint a strukturalt.
Amugy sok felreertes abbol fakad, hogy mindenki mast ert kulonbozo fogalmakon es maga objektum orientaltsag is nagyon altalanos.
ja meg valami, szerintem ami zsenialis az OO-ban az az hogy van oroklodes. Szerintem ez az ami dontoen massa teszi mint a strukturalt programozas.
Igen, bár ez is téveszme, hiszen mi az, hogy tökéletes szoftver?
Az a szoftver amely a jelen pillanatban érvényes igényeket elégíti ki.
Tehát jövőre tovább kell majd fejleszteni.
Ja, hogy így nem lehet évekig szervízdíj címén leakasztani újabb pénzeket azért, hogy a tervezés nélkül megírt program, hibáinak, tervezés nélkül való javításából adódó őújabb hibákat kijavítsák?
Nem vagyok Oracle rajongó, egyáltalán nem az Oracle-t szándékoztam védeni. Csak egy pár példát mondtam, ahol Oracle adatbázisok vannak, és működnek is.
ON
Sajnos, jelen pillanatban épp egy olyan munkahelyen dolgozom (szoftverfejlesztőként), ahol csak a tervezés teljes hiánya van meg, és semmi más. A fejlesztők most kezdtek el lázadozni, hogy tervezés nélkül nem lehet normális szoftvert fejleszteni, de erre a felsőbb körökből még nem nagyon döbbentek rá. Ebben persze benne van az is, hogyha valaki egy olyan szofvert fejleszett ki, ami hibamentes ( persze, ilyen nincs, inkább úgy mondanám, hogy nincsenek benne a funkcionalitást akadályozó hibák), akkor nem kell a szoftvert továbbfejleszteni, és így nem lesz több megrendelés.
Hat a BMKH-ban nagyon sok fele rendszer mukodik, a fo gond az hogy nem egyutt-mukodnek, csak kulon-kulon... ennek szamos oka van, peldaul az hogy minden rendszert mas-mas KFT csinalt:-)
Azt hiszem itt senki nem az Oracle-t szidja, hanem valami olyanról van szó, hogy hiába van a legprofibb Black&Decker fúród, ha egyszer úgy használod mintha véső lenne, szart sem ér.
Persze, úgy örülnék ha mostmár a tervezési tapasztalatokat osztanánk meg egymással :)))
Én ugyanis azért nyitottam a topikot - még akkor is, ha nyakig sáros vagyok az offolásban :))))
Tehát, kedves NewcomeR, Te hozzátudsz valamit szólni a témához?
A BMKHban egy csomó Oracle alapú rendszer van. Illetve az adatbázis Oracle (természetesen triggerekkel, tárolt eljárásokkal). A serveroldal Java servlet. A kliensoldal Java Applet ( Egyéni vállalkozói igazolvány rendszer, Idegenrendészeti rendszer - tartózkodási és letelepedési engedélyek), illetve HTML ( Kötelező gépjárműfelelősségbiztosítás rendszer).
N.
(jah, és ezek működnek. Amikor meg nem működnek, akkor meg nem az Oracle a hunyó)
Igen, csak itt nem szabvány volt az ok, hanem:
1) A cég nem akarta tanfolyamra küöldeni a programozókat, akiket ettől a guta kerülgetett, mert még soha nem dolgoztak ORACLE alatt.
2) A programozók kb. 1/2 év munka után már teljesen lilát láttak, mert miközben dolgoztak az ORACLE-lel, rájöttek, hogy sokkal egyszerűbben is meg lehetne oldani dolgokat, de akkor már késő volt
3) Természetesen mindenki a programozókat csesztette
Szóval ismét a "Mi mindenhez értünk, persze, tudunk ilyet" feladat vállalás a cég részéről, ami nem lenne gond, ha ilyenkro legalább tennének is valamit azonkívül, hogy vesznek egy Oracle 8 utasításgyűjteményt, ami csak a kérdések 70%-ra nem ad választ.
ORACLE rendszer amivel elégedettek?
Azt hiszem az Excenture-nél van egy ilyen.
ORACLE rendszer, ORACLE Developerrel és Delphi-vel megoldva.
Az ORACLE-t csak SQL utasításokon keresztül érjük el, ORACLE specifikus dolgokat mellőzünk, ODBC-n keresztül kommunikálunk, és avalidálást egyebt majd a java program elintézi. :S
Most erre mit mondja?
Mi ebben a probléma? Ha az a filozófia, hogy egy adott szabvány szintjén kell megvalósítani a dolgot, akkor azt kell csinálni. Ennek ára van.
Most a TAH (Területi Államháztartási Hivatal) kitalálta, hogy lecseréli a nyilvántartási rendszerét. Ezért nálunk is le kell majd cserélni (?!). Oracle adatbáziskezelő. Volt Digital Alpha OpenVMS szerverünk, Novell szerverünk, Linux szerverünk (papíron mindegyikre van Oracle adatbáziskezelő). A TAH programot kizárólag Windows NT-re vagy Windows 2000-re telepítik.
Most erre én mit mondjak?
Arról nem is beszélve, hogy mért nem működik a program MySQL, PostgreSql, SyBase, Ingres (létezik még ??), .... adatbázikezelőkkel.
A TAH program nálunk még nincs itt. Év elején kellett volna bevezetni. A TAH-nál most indult. Én a kormányváltás edején csödöltek be vele. Nem tudták időre számfejteni a béreket. Ebből az a pletyka rémhír alakult ki, hogy a kormány leállította a bérfizetéseket. :-)
Nálunk megbukott egy Oracle-re írt számviteli rendszer. Egy közeli egyetemen az a mondás járja: "Ha a Neptun a barátunk, minek nekünk ellenség?". Most itt van a TAH csődje.
Summa summárum, még nem hallottam olyan Oracle-re írt rendszerről, amivel a vele dolgozók elégedettek lennének. Ti ismertek ilyet?
Az iskola olyan mint egy container, nyilvan ott kell legyenek a megfelelo add/remove/retrieve interfeszek.
Ez stimmel.
Kicsit lejjebb meg studentes plane studentID-s verziok: vegyuk eszre, hoyg a student sokkal inkabb tulajdonsag mint class. a gyerek ugye attol student hogy tagja egy iskolanak.
A Tanulo az ebben az esetben a Ssemély egy specialziált osztálya.
Megvan minden tulajdonsága ami egy Személynek, ezen kívül ilyen apró saját tulajdonságai vannak : Szemeszter, kapcsolat szakirányhoz, Mentorhoz/osztályfőnökhöz, kedvezményekhez, jelentkezésekhez, tantárgyi eredményekhez, stb.
Tehát a Tanuló az Iskolának egy Osztály típusú tulajdonsága lesz.
StudentID, ha van ilyen, magaban a beireatkozas aktusaban keletkezik. (Ahogy uj student is, ha erre kulon objektumot keszitunk.) Ez teljesen korrekt, az adott Személy Jelentkezőből Tanulóba vált.
Ne felejtsd el, hogy amennyiben adatbázist kezelsz, a program egy Egyed - Osztály megfeleltetéssel működik, és egy Rekord az egy Objektumnak felel meg.
Tehát az adott rekordon elvégzendő műveletek megfelelői meg fognak jelenni az adott Egyedet képviselő Osztály műveletei között.
Kicsit belemélyedtem az oktatással kapcsolatos adatbázis és egyéb témákba - diplomamunkám témája: Távoktatási rendszerterv - és valami hihetlen mennyiségű apróság van amivel foglalkozni kell.
Aműgy meg általánosságban igaz az, hogy ha objektumorientáltan csinálsz egy adatbázis kezelő programot, akkor minden kezelt táblához célszerű egy osztályt létrehozni - leszámítva a kapcsoló táblákat.
Az iskola olyan mint egy container, nyilvan ott kell legyenek a megfelelo add/remove/retrieve interfeszek.
A gyereknel lehet ugyan, ha nagyon kell, de igencsak meggondolando. Hiszen szamos kollekcioban el lehet helyezni, miert epitenenk bele ezeket mint speci elemeket.
Kicsit lejjebb meg studentes plane studentID-s verziok: vegyuk eszre, hoyg a student sokkal inkabb tulajdonsag mint class. a gyerek ugye attol student hogy tagja egy iskolanak.
StudentID, ha van ilyen, magaban a beireatkozas aktusaban keletkezik. (Ahogy uj student is, ha erre kulon objektumot keszitunk.)
A cég által kitalált Oracle adatbázis kezelés:
Az ORACLE-t csak SQL utasításokon keresztül érjük el, ORACLE specifikus dolgokat mellőzünk, ODBC-n keresztül kommunikálunk, és avalidálást egyebt majd a java program elintézi. :S
Itt nem erről van szó. Hanem arról, hogy aki az adatbázist csinálta, az csinálta a programot is, és a relációk, a validálás nem az adatbázis szerveren van, hanem a foxos program oldja meg.
Az nemes egyszeruseggel kikopi ha nem tisztesseges JOIN-t csinalsz, hanem arra akarsz hagyatkozni hogy a where alapjan a db majd kitalalja. :) Az Oracle pedig mongyon le! (gyk: ott nincs join, a where alapjan az db kitalalja:)
Emlékszem tavaly előtt a főiskolán egy okos elsőéves bedobta - minek tanulunk struktúráltan programozni, mikor ma már OOP a menő.
Megkérdeztem tőle, hogy ugyan már, ha nem tud struktúráltan programozni, akkor hogy a fenébe akarja az objektumon belül megírni a privát függvényeket. :)))
Ebben az osztályosdiban az a legjobb, hogy el lehet tenni, és - elvileg - jövőre, sőt utánna is felhasználhatod.
Ami miatt bukik az egész - évente új fejlesztőkörnyezetek jönnek ki, amikhez a múltban elkészített dolgokat nem tudod használni.
Éljen a piacgazdaság :))
És pont ezért mondtam, hogy az oop-ban semmi új nincs, két jól meghatározott feladatú exe állománnyal is pont ugyanígy meg lehet oldani. Más kérdés, hogy az exe-vel való megoldás technikailag baromi kényelmetlen, meg pazarló is.
Amúgy - nincs új a nap alatt.Annak idején ilyen elven már Quick Basicben is lehetett programot írni a SUB-ok jó szerkesztésével. Nem volt teljesen objektum orientált, de lehetett közelíteni.
Amúgy viszont nem érdemes ágálni ellene, mert úgyis marad még egy darabig, és annyira azért nem rossz.
Legalább jól lehet tagolni a programot.
Persze, ha valaki össze vissza programozik, OO-ban is lehet káoszt csinálni.
Amúgy azt mondják az Angster féle könyv igen jó. Most hirtelen más könyv nem jut eszembe, bár van itt még egy kisebb jegyzet kb 50 oldal, ami jónak tűnik.
Epp most mondtam, hogy meg azt sem tudom mi az!
Amikor en jartam a programozoiskolaba (10 eve vegeztem), meg a tipus-alapu modulok voltak divatban (lasd pl Modula2 DEFINITION+IMPLEMENTATION MODULE, ADA package). Epp ezert agalok mert szerintem ez az egesz OO-divat jol ismert regi elvek ujracsomagolasabol + uj szintaxisbol all...
zerintem ha a legrövidebben akarod megoldani, akkor egy darab függvény az Iskola oldalon, visszatérési érték az iskola azonosítója.
Kész.
Akkor egy lépésben letudtad az egészet, nincsen "elfelejtettem meghívni a Tanulo setIskola függvényét" probléma.
Végülis, erre van a visszatérési érték :)
Ráadásul, ha az Iskola oldaláról próbálom, mint az Iskola az addTanulo függvényének a része, megvalósítani a Tanulo iskolához rendelését, akkor biztosítani kell azt is, hogy a megfelelő Tanuló metódusát hívja meg az Iskola.
Úgyhogy ezt a visszatérési értékkel meg lehet spórolni.
Pl: egy tanulo beiratkozik egy iskolaba. Ez kinek a muvelete, a tanuloe vagy az iskolae? Nyilvan mindkettoe (mindkettot eri valtozas), amit igy logikus leirni: beiratkozik(t,i), sem t.beiratkozik(i), sem i.beiratkozik(t) nem logikus)
Szerintem is mindkettőé. De nem egyformák és kapcsolódnak egymáshoz. Ezért mindkét helyen meg kell valósítani.
Szerintem igazából ha jót akarsz - lehet, már olvastad :)) - olvass Halassy-t :)))
És javaslom a The Rational Edge magazin forgatását - ingyenes, neten terjed, html és pdf formában.
Ott minden van elméleti és gyakorlati szakemberek, megoldások, kérdések, bú baj bánat :)))
Na igen.
Hasonló problémákkal én is szembefutottam.
Anno mondták, a struktúrált programozással az a baj, hogy az ember menetközben a fejéhez kap: Jé ide kell egy függvény - aztán berakja a függvényt.
Nos én objektumorientáltnál ezt hasonlóképp láttam: Jé, ide kell egy új osztály.
A tanuló beiratkozás példánál elméletileg a Tanuló megkéri az Iskolát, hogy vegye fel -> Iskola.addTanulo(TanuloID).
Elvileg, OOP szemlélet szerint ez a helyes.
Más kérdés, hogy ekkor a tanuló még nem tudja, hogy Ő melyik iskolába jár, ehhez vagy egy új függvény kell Tanulo.setIskol(IskolaID), vagy pedig az Iskol addTanulo függvényéhnek kell visszatérési értékként megadnia az IskolaID-t.
Lehet ezen tökölni :))
Ezért is szeretném megkérdezni, hogy van-e valaki, aki már komolyan tervezett Objektumorientált programot?
Nekem egyszer kellett csinálnom egy Visual Fox rpogramhoz egy objektum orientált programtervet.
Akkor rátaláltam pár súlyos hibára az OOP szemléletben, azóta esküszöm az SSADM-UML hibridre :))))
Persze, ezzel is vannak gondok, csak még nem találkoztam velük - igaz, nagyon nem is próbálhattam még ki.
Ketsegtelen, van egy ilyen jelenseg, hogy jol ismert dolgokat (szubrutin) uj neven (eljaras, metodus) ujdonsagkent adunk el :-)
Egyik nyomorom ezzel az OO-divattal, hogy minden muveletet valamelyik parameterehez akar rendelni, pl a fun(a,b)-t ugy akarja latni, hogy a.fun(b).
Vannak esetek, amikor ez jogosan megteheto (open(filehandle,filenev) helyett filehandle.open(filenev) logikus).
Maskor viszont a parameterek szimmetrikusak (pl plusz(a,b) helyett a.plusz(b) eleg furcsan hat), illetve a parameter kulonbozo jelleguek, de nincs koztuk 'dominans' akihez a muvelet egyertelmuen tartozna.
Pl: egy tanulo beiratkozik egy iskolaba. Ez kinek a muvelete, a tanuloe vagy az iskolae? Nyilvan mindkettoe (mindkettot eri valtozas), amit igy logikus leirni: beiratkozik(t,i), sem t.beiratkozik(i), sem i.beiratkozik(t) nem logikus)
Kulon szepseghiba, hogy neha olyan objektumokat kell csinalni, amelyeknek nincsenek is adatmezoi, csak azert kellenek mert 'onallo' fuggvenyek es konstansok nem letezhetnek (pl Math a JavaScript-ben).
Na most erre szokták mondani, hogy minde objektum a saját adataival dolgozik.
Az, hogy te ezt szubrutinhívásnak hívod az egy dolog.
De bizony, akárhány OOP szakkönyvet megkérdezel, mind azt fogja mondani, hogy az objektumok komuninálnak, és műveleteket hajtanak végre a saját adataikon.
Amúgy szubrutint ezer éve nem hallottam, metódust, eljárás annál gyakrabban.
:)))
