Nem rossz, de nem is tokeletes:-)
A programot inkabb objektumok "rendszerenek" kellene nevezni semmint "osszessegnek".
Nagyobb gond, hogy az objektumok nem 'kommunikalnak' es nem 'hajtanak vegre' semmit, itt egyszeruen 'szubrutinhivasrol' van szo (ami ugyan nem hangzik olyan elokeloen)... ezeket a szavakat a folyamatok (process/thread) egyuttmukodesere szoktuk alkalmazni. [Hasonlo eset a Windows programozasban a 'SendMessage': szo sincs uzenetrol, ez egy szubrutinhivas]
Amúgy az általam leírt mesét Ivar Jacobson egyik cikkében olvastam.
Azt hiszem, Ő rólla nehéz azt mondani, hogy nem tudja mi az az objektumorientált programozás :))
Objektumorientált program: Egy objektumorientált program egymással kommunikáló objektumok összessége, melyben minden objektumnak megvan a jól meghatározott feladata.
Objektum: Az objektum információt tárol, és kérésre feladatot hajt végre. Az objektum adatok és metódusok összessége, mely felelős feladatai elvégzéséért.
Az objektum a valós világ egy elemének absztrakt megjelenítési formája az adott programnyelven, minden tulajdonságával együtt.
Hány definíciót kérsz még?
Jelenleg Ivar Jacobson és társai is vitatkoznak az objektum pontos megfogalmazásán.
Masszoval: neked is csak hozzavetoleges fogalmaid vannak arrol, hogy mit is jelent az objektumorientalt programozas:-)
Tenyleg, tudna valaki preciz definiciot modnani... tehat nem "meset"!
Javaban irtak, igy ez sem veheti fel a versenyt sebessegben egy 'normal' windows-os alkalmazassal, de talan ez ma mar nem problema.
Nemreg csinaltunk a cegen belul egy vizsgalatot a kulonbozo modellezo eszkozok kozott (XDE, ControlCenter, PowerDesigner etc) es bar nem jott ki egyertelmu gyoztes, tobben (koztuk jomagam) a ControlCenter-t nagyon birtuk.
Jegyezzük meg, hogy az objektum alapú szervezést igen régóta használjuk, csak sokáig nem adtak nevet neki. Amúgy, pont adatbázisokban mindig is egyedekkel és példányokkal ábrázoltuk az adatokat.
Objektum orientált onnantól lesz az adatbázis, hogy az ÖSSZES adatokkal kapcsolatos műveletet az adott egyeddel tároljuk el mint tulajdonságot.
Ehhez közelítenek a tárolt eljárások, amennyiben ezeket a tárolt eljárásokat az adott "adatáblába" rakjuk be, akkor onnantól kezdve objektumorientált.
Programozási szempontból pedig az objektumorientált programozás tulajdonképpen igen
kevésben különbözik a moduláris programozástól, amikor is a különböző állományok hivogatták egymás nyilvános metódusait. Tulajdonképpen, ha egy exe egy másik exe-t paraméteresen indít, már beszélhetünk egy kezdetleges objektumorientáltságról, amennyiben mind a két exe alkalmazásnak szigorúan körülhatárolt feladata van, és csak a saját adatait módosítja.
Például: start.exe elindítja a kor.exe-t - három paraméterrel: kor kozéppont és átmérő - ami csak egy kört rajzol ki, akkor az már valahol objektumorientált. Ezt aztán tovább finomítjuk, és a kiterjesztést kicseréljük class -ra :)))
Így igaz, ha visszaolvasol az XDE-t külön kiemeltem, de a Visual Studio 6.0 J++-át nem támogatja az sem, hiszen kizárólag Studio .NET környezetben működik - na meg IBM WebSphere-rel mint mondod, de az sem segít a VS6-ot használókon :)).
Én a Rose-t [2000,2001] említettem, mint UML tekintetében hiányos eszközt - a szekvencia diagram sem az iterációt sem a szelekciót nem támogatja, az osztálydiagram nem tudja rendesen kezelni a kapcsolat szintű megszorításokat, és egy pár hasonló dolog.
Az XDE használatával egyenlőre hadilábon állok, rengeteg új dolgot vezettek be, amit még nem próbáltam ki.
Ez a Together ControlCenter ez érdekelne, valami Evaluation verziót lehet szerezni?
A Rational XDE (a Rose utoda) tamogatja a Java-t, mi ezt hasznaltuk. Egyenlore a IBM WebSphere Studio Application Developer-t, meg a Visual Studio .NET -et tamogatja. Beepul az IDE-be es onnan lehet hasznalni. Egesz ugyes, bar a WebSphere-hez egy egesz eromu kell, hogy ertelmesen lehessen hasznalni. Nem tudom mennyire hianyos a UML tamogatasa (1.3), de szerintem ha valami hianyzik, akkor azt csak nagyon ritkan kell hasznalni, szoval nekem teljesnek tunik.
Bar ha valasztani kene, akkor en a Together ControlCenter-re szavazok.
Hu de sok minden kavarog itt..., megprobalom osszeszedni:
1) kulcs: termeszetesen technikai kulcsot kell hasznalni, hiszen a nev, lakcim, szig-szam stb se nem egyedi se nem valtozatlan.
2) tablak tartalma: termeszetesen az 'ember' tablaba kerulnek azok az imformaciok, amik az emberekre jellemzok, pl nev, cim, telefon, anyja neve, szuletesi hely, ido, igazolvanyszam... megengedve azt is, hogy aki csak ugyfel, az eltitkolhatja az anyja nevet, de aki alkalmazott, az nem (persze ezt nem itt ellenorizzuk, hanem az alkalmazottra vonatkozo szabalyoknal).
3) jogi szemely: termeszetesen ok egy 'Szervezet' nevu tablaba fognak kerulni (mezok pl: nev, cim, adoszam, cegszam, telefon, telephely stb). (Szerencsere a szervezetekre nem vonatkozik az Avtv sem). Ekkor a 'partner' tablanak az lesz a szabalya, hogy az o kulcs elo kell forduljon vagy az 'Emberek' vagy a 'Szervezetek' tablaban. Ebbol maris latszik, hogy diszjunkt kulcsokat kell alkalmazni. (Esetleg lehet egy alaptabla 'Szemelyek' neven, akinek van kodja, neve, cime, es az 'Emberek' meg a 'Szervezetek' ennek a kiterjesztesei (Valaki mindjart felveti, hogy ezt nevezzuk objektum-alapu tervezesnek... szerintem ezt egyszeruen fogalom-alapu gondolkodasnak nevezzuk, es az informatikan kivul mindenutt alkalmazzuk is:))
4) Adatvedelem: az a gond, hogy az adatvedok es jogaszok nem ertenek az informatikahoz (ebben hasonlitanak a programozokhoz:) sem a szamitastechnikahoz (ebben hasonlitanak a szervezokhoz:), ezert senki sem tudja, hogy mi a fenere gondolnak amikor osszekapcsolasrol beszelnek...
Amúgy lehet, hogy csak a Java-t nem támogatja belőle, én arra próbáltam kifejezetten - az is megoldható, csak nem volt kedvem két hetet tökölni az osztályok visszafejtéséhez, hogy a Rose tudja használni őket.
Szóval lehet, hogy a VC 6-ot támogatja.
Azt őszintén nem próbáltam.
Ra kell szoritani oket, hogy a programjuk mukodjon access motorral is. Az nemes egyszeruseggel kikopi ha nem tisztesseges JOIN-t csinalsz, hanem arra akarsz hagyatkozni hogy a where alapjan a db majd kitalalja. :)
Utálom amikor az index elfelejti felrakni a hozzászólásomat :((((
Nos, ez természetesen nem gyakori, csak magyarország nagyobb bankjainál, biztosítóinál, mobilszolgáltatóinál találsz ilyen, SQL 7-re megvalósított DBase II-es adatbázisokat.
A probléma az, hogy valós munkában igen nehézkes a Rose használata. Rengeteg mindent nem ismer az UML-ből.
A Rational többi része - Purify, Quantify, Test, Soda, Requisite Pro, ClearQuest - ellenben igen jól használható.
Csak a Rose, az alkalmazás tervező része az, ami kívánni valót hagy maga után, nem is keveset.
Pláne, hogy a Visual Studio 6-ot mr nem is támogatja.
Anno leszedtem a trialt a Rose-bol, meg a graphical designert, de elso nekifutasok utan felreraktam jobb idokre.
Ha valaki meg tudna mutatni hogy eloben hogy lehet ezt tervezesre ES kodvaz generalasra hasznalni (ahogy hvatkozni szoktak ra, mint Columbo felesegere), nagyon orulnek.
Ahogy én látom - most épp egy fogorvosi progi van terítéken - erre általában célirányos, és nem a kibővíthetőségre kihegyezett progik vannak előnyben - Gyógyszertári program, Éttermi számlázó és készletnyilvántartó program, Fogorvosi nyilvántartó program - és ezeket viszik ugyan arra a területre, majd fejlesztgetik.
És én elismerem, ha ezt előre eldntöd, akkor úgy kell megtervezni. Viszont nagyon variálta dolgot nem lehet csinálni - hiszen egy fogorvosi készletnyilvántartó és egy éttermi nyilvántartó által tárolt adatok nem igazán hasonlíthatóak össze.
Viszont ugyanazon a területen - lásd kölcsönzés - általában eléggé egy kaptafára lehet csinálni a dolgokat, tulajdonképpen a kölcsönzött áru adatait tartalmazó táblákat kell kicserélni, a többi kisebb változtatásokkal maradhat.
Tehát az, hogy videókazéttát kölcsönzöl ott lehet érdeked, hogy ne lehessen összekapcsolni a kölcsönzőt egy dolgozóval - bár mint mondtam, az alkalmazotti kedvezmény miatt ez nem feltétlenül előnyös megoldás - de mondjuk egy szerszám vagy vizisí kölcsönző esetén ebből sok gond nem származhat, ráadásul - szintén az alkalmazotti kedvezmény miatt - még előnyös is, ha nem kell trükközni.
Valaki látott már olyant végig vinni rendesen, magyar cégnél?
Én nem. Pedig de jó lett volna...
Másrészt megfontolás tárgyát képezi sok esetben a téma továbbfejlesztése. (Kéziszerszám, autó, vizibicikli kölcsönzése). Ne kelljen mindent újraírni.
Na ige, ez is egy szempont. Ezért kell felmérni jól a helyzetet, és az esetleges jövőbeni igényeket.
Na mos, amennyiben profilbővítés történik egy cégnél azt kisvállalkozások esetén már jó időben lehet tudni.
Ilyenkor egyébként három eset lehetséges:
1) Vagy a már meglévő rendszert fejleszti a tulajdonos
2) Teljesen újat irat, az alapoktól
3) Az új profilnak teljesen másikat készíttet.
Mivel azonban az ügyfél nyilvántartás kisvállalkozások esetén általában a számlázási adatok rögzítésén alapul, ezért nincs komoly eltérés a magán illetve jogi személyek között.
(Kölcsönzés, illetve vásárlás esetén amúgy - ha jól emlékszem - mindenki jogi személyiségnek számít, mint szerződő fél. Többek között ezért is nem lehet 18 éves kor alatt kölcsönzőkbe beiratkozni. Ez mondjuk nem 100%, de én így emlékszem. Viszont ígérem megnézem, hogy ez hogy is van)
Amenniyben a kisvállalkozás közép illetve nagyvállalkozássá alakul, esetleg formát cserél - Bt->Kft, Kft->Rt.) , úgy mindenképpen teljesen le kell cserélni a nyilvántartási rendszert, hiszen onnantól kezdve teljesen más előírások vonatkoznak rá.
Egyébként azért nem kölcsönözhet jogi személy -tehát cég, honvédség, stb. - mert a Szerzői jogok alapján, tilos nyilvánosan vetíteni a filmeket, ergó sem vállalati sem honvédelmi, sem más rendezvényen nem lehet levetíteni. Márpedig ha a cég kölcsönzi a filmet, azért, hogy az igazgató úr megnézhesse, az már vállalati rendezvénynek számít, és mint ilyen nyilvános vetítés.
Na, ezt a szabály törvényhozó nem fogja áthágni, mert az előbb rosszul írtam: azAlkotmányban foglalt szerzői jog védelme miatt nem kölcsönözhető a terjesztővel kötött szerződés megszegése nélkül. Amely szerződés alapján a szerző csak magán jellegű megtekintés céljára engedélyezi műve felhasználását.
De ez meg már egy félig jogműveletlen informatikus magán fejtegetése, és jogértelmezése. Viszont nem OFF, hiszen fontos tényező a rendszer kialakításakor.
Diplomamunka, távoktatási rendszerterv.
Tuti már a végén vagyok, elvileg a héten jövő héten már mehet nyomdába.
Követelmény: Csatlakozzon a Felhasználói Nyilvántartáshoz, meg a Hallgatói nyilvántartáshoz, de legyen külön adatbázisa..
Persze a másik kettőről semmi infot nem kaptam :)))
Ezenkívül azt sem teljesen értem, hogy mért kell a szakokat, vizsgákat, előadásokat, tantárgyakat külön tárolni, külön kezelni.
Na, igen.
Erre mondja Halssy: És a végfelhasználóval senki nem törődik. A végfelhasználó ugyanis az, aki majdan sorban áll az ügyintézőnél, és kitölti a papírokat.
Amúgy ez szerintem nem teljesen OOF, hiszen kapcsolódik a témához, Tervezési Nehézségek kötet, Miért hülye a megrendelő? fejezet :))))
Amúgy, egy videókölcsönzőnél a következő miatt hülyeség ilyennel foglalkozni: Mindenki ismer mindenkit, és a saját haver/nem haver kollegádtól kölcsönzöd.
OFF!
De mennyi hülyeség van, amivel foglalkozni kell. Csakhogy kiöntsem a lelkemet. :-(
Emlőszűrés. Az ÁNTSZ adja a szűrendők adatait. De ún. adatvédelmi (?) szempontból nem adja a TAJ számot. Csak a nevet (+ születési év) és a címet, ahová a behívót küldeni kell.
Namármost nekünk jelenteni kell a teljesítést. Természetesen TAJ számmal. Ezért elkérjük szépen a TAJ kártyát, beírjuk a rendszerünkbe. :-)
A folyamat végén ugyanannyit tudunk az illetőről, mintha az ANTSZ odaadta volna előre az adatot.
Az ÁNTSZ adott a szarnak egy nagy pofont. Megnyugtatták a lelkiismeretüket, hogy ők mindent megtettek. Az unatkozó eü. dolgozókkal csináltak egy csomó plussz munkát. A pluszz adminisztráció okán lehet egy kicsit többet várni a vizsgálatnál.
Ügyfélről tárolhatsz:
Név
Cím
Ügyfélkártya azonosító
Tartozások
Letiltás időtartma (van, ahol bünetésként 1-2 hónapig nem kölcsönözhetsz)
Kedvezmény azonosító
Beiratkozás ideje
Kölcsönzések száma beiratkozás óta
Egyébként törvényileg nem TILOS a megoldás, hanem azt kell megoldani, hogy ne lehessen törvényellenes információkat szerezni.
Amúgy, egy videókölcsönzőnél a következő miatt hülyeség ilyennel foglalkozni: Mindenki ismer mindenkit, és a saját haver/nem haver kollegádtól kölcsönzöd. Másik indok, muszáj összekapcsolhatóvá tenned, hiszen rengeteg helyen jár alkalmazotti kedvezmény.
Videókölcsönzőből jogi személyek nem kölcsönöznek, hiszen ez törvényileg tiltott.
Szeretném kihangsúlyozni, hogy itt végig egy videókölcsönző niylvántartásáról volt szó.
Amennyiben pl. a Pannon GSM számára készítesz nyilvántartást, természetesen nem ezek a megoldások a korrektek, és a Te meglátásaid helytállóak.
Pont ezért mondtam, hogy a TELJES képet ismerni kell.
Mert ami jó egy viedókölcsönzőbe, az nem jó egy nagycégnek, mégkevésbée jó a Nemzetbiztonsági hivatalnak.
A harmadik szempont, hogy általában nincs cég, aki munkaügyi rendszert és kereskedelmi rendszert is szállít. Én még nem találkoztam két rendszerrel, amely a természetes személyeket - logikai szinten - azonos módon kezelte volna le. A fizikai szintről meg már ne is beszéljünk.
Na igen, kedvenc problémája mindenkinek. Mi az, hogy egy rendszer az két rendszer? Egy rendszer van: A Vállalat. Ez áll több rendszerrészből, mint munkaügyi, kereskedelmi, stb.
De ezek, egybe tartoznak, nem választhatóak szigorúan külön. (Lásd Halassy valamennyi könyve :)) )
Ismer valaki egy olyan személyt, aki ismer valakit, aki ilyesmiről már hallott? :-)
Papíron kb. 12-őt, valóságban egyet sem.
Ez a 12 személy pedig különböző szaklapokban hirdeti az igét, és pl. a Rationalnél dolgozik 2.
De sajnos, azt kell mondjam, hogy amíg minden újonnan felvett két táblát külön DB-ként kezeltetnek az MS SQL-lel, így oldva meg a hozzáférési jogosultság kérdését......
Na jó..
Magyarországon nem terveznek, csak diagnűózis nélkül szeletelnek. Aztán 4 évig gányolják, hogy mégis működjön.
Amúgy ResetGomb, a meglátásaid tényleg jók, de mint mondtam, itt én kifejezetten az adott példa kapcsán javasoltam megoldást.
Elnézést, ha ez nem derült ki egyértelműen.
Kellemes hétfőt :)))
u.i. Szig számot ne rögzíts sehová, mert megesznek az adatvédelmisek :))))
Az adatvédelmi érv valóban nem kifogástalan, de ilyen alapon bármit össze lehet kapcsolni. De mivel az ilyen összekapcsolás TILOS, nem tervezhetsz olyan rendszert, amiben ez eleve benne van. (És nem csak a lehetőség!!!)
De vizsgáljuk meg, milyen adatokat tárolhatsz egy ügyfélröl és egy dolgozóról:
Ügyfél:
- Név
- Cím
- Szig. szám????
Dolgozó:
- Családi név
- Keresztnév
- Leánykori név
- Születés dátuma
- Születés helye
- Anyja neve
- Állandó lakhely (?)
- Ideglenes lakhely (?)
- Szig szám (!)
- TAJ szám
- Adószám
- Személyi szám
Esetemben pl. ha csak a lakcimet és a nevet vesszük, nem lehetne egyértelműen azonosítani.
További kérdés, hogy az ügyfelek között nem csak természetes, de jogi személyek lehetnek. Ezek leírására pedig egészen más szerkezetű adatokat használnak.
Ha mindvégig teljesen következetes akarsz maradni, akkor a végén az "ember" tábla két, három oszlopra szűkül - EMBER_ID és születési adatok (születési ideje, helye, anyja neve).
Figyelembe kell venni, hogy:
- a név változó adat (gondoljatok a nőkre)
- a cím változó adat (költözés)
- telefonszám változó adat (költözés, ill. lehet több).
Egyébként adatbázistervezési szempontból NevemTeve megoldása teljesen korrekt. De az ilyen megoldások annyira elvinnék az (emberi)erőforrásokat, hogy az érdemi feladatra már nem jutna idő és a megrendelő türelme elfogy. :-(
A harmadik szempont, hogy általában nincs cég, aki munkaügyi rendszert és kereskedelmi rendszert is szállít. Én még nem találkoztam két rendszerrel, amely a természetes személyeket - logikai szinten - azonos módon kezelte volna le. A fizikai szintről meg már ne is beszéljünk.
Elméletileg korrekt megoldás lenne, ha egyetlen személy tervezné - koordinálná - az adatbázis felépítését. Minden más alvállalkozónak (munkaügy, pénzügy, logisztika) ehhez kellene igazodnia.
Ismer valaki egy olyan személyt, aki ismer valakit, aki ilyesmiről már hallott? :-)
