Dehogyis, csak dolgozni is kell valamikor :))) sajna mostanaban olvasni sem volt idom :((.
Beszeljunk akkor pattern alapu tervezesrol. Mit ertesz ezalatt? :)
A tervezesi pattern-ek (leforditsuk, ne forditsuk ?) szerintem egy szinttel magasabb absztrakciot valositanak meg, mint az osztalyok, objektumok. Igazabol valami olyasmit probalnak leirni (strukturat, viselkedest), amik fuggetlenek attol, hogy az adott osztalyoknak mik a konkret funkcioi. A legjobb konyv ehhez szerintem a lentebb mar emlitett Design Patterns konyv. Ahogy olvassa az ember sokszor erzi, hogy aha ilyesmit mar csinaltam, de nem volt tudatos. Vagy peldaul kulonbozo konyvtarak (SUN Java API vagy a Delphi/C++Builder VCL) hasznalnak meg ha nincs is leirva es klassz, hogy az ember egy kicsit 'felulrol' nez ra a dolgokra. Es otleteket is kaphat igy az ember hogy teheti rugalmasabba a programot amit csinal.
Ja es meg fontos lehet amiatt, hogy egy a tervezo meg a programozo jobban megertheti egymast a munka soran.
Igen, ez egy külön osztályba volt berakva.
Csak az ini állományok mérte változó, és ez az osztály beolvasta és eldöntötte, hogy érvényes-e azadott sor. Erre a Vector kiváló volt.
:)))
Igen, rugalmas, rugalmas, de nem mindig rugalmassagra van szukseged, hanem szigorusagra mar ami a tipusossagot illeti. Mondjuk Javaban is elerhetsz hasonlot, ha a Vector-t bezarod egy osztalyba, aminek a metodusai csak adott tipust fogadnak el ill. adnak vissza.
De.
Most pont arról volt szó, hogy mit tud az interfész.
Pontosabban, arról, hogy a könyv mennyire nem tudta ezt megfogalmazni érthetően.
Most tananyagról beszéltünk :)
'Az IKönyv interfész nem tudja, hogy az olvasKonyv eljárása implementálás után a KonyvSQL, a KonyvTable vagy esetleg a KonyvODBC segítségével olvassa be az adatokat be, úgyhogy ahogy én látom igazából az interfészt megvalósító osztály tudja hogy mi(ke)t használ az interfészben definiált függvény'
Erre gondoltam en is, de nem fogalmaztam eleg normalisan :)
Mert mért nem tudta így megfogalmazni: Az interfész egy olyan absztrakt osztály, ami csak függvény definíciókat tartlamaz.
Amúgy az interfésznek szerintem gőze nincs, hogy kiből fogja olvasni az adatot.
Az IKönyv interfész nem tudja, hogy az olvasKonyv eljárása implementálás után a KonyvSQL, a KonyvTable vagy esetleg a KonyvODBC segítségével olvassa be az adatokat be, úgyhogy ahogy én látom igazából az interfészt megvalósító osztály tudja hogy mi(ke)t használ az interfészben definiált függvény.
Amúgy ez még a 2004-es olimpiáról szól, és a könyv szerint egy létező tenderkiírás alapján jött az ötlet.
1. parameteresitett osztaly:
Ez a olyan mint C++ - ban a template osztalyok. Tudsz ugy egy osztalyt megadni (deklaralni), hogy nem minden jellemzoje ismert elore, peldaul egy vektor milyen TIPUSU elemeket tartalmaz majd es enelkul tudod az osztalyt definialni. Peldaul C++ hez van a STL (Standard Template Library) ami egy osztaly konyvtar tele kulonbozo un. collection osztalyokkal pl. vektor, lista, map, set stb. A vektor osztaly definalja a muveleteit egy elemre (aminek a tipusa meg nem ismert) hivatkozva pl. a push_back fuggveny hozzaad egy uj elemet a vektorhoz. Aztan a programodban definialhatsz egy uj vektort a te altalad ismert tipussal pl:
vektor books;
akkor a books egy vektor osztaly, ami csak Book tipusu elemet hajlando elfogadni pl:
Book MesterEsMargarita;
books.push_back(MesterEsMargarita);
ha mast adsz meg akkor a compiler error.
Klassz, elegans dolog ha C++ ben programozol, de azert meg lehet lenni nelkule, lasd mas nyelvekben ilyen nem nagyon van, legalabb is ami ismertebb.
2. interfesz
Hat ez szerintem talan a legfontosabb dolog az OO - ban. Gyakorlatilag ez ugyanaz mint amirol nehany hozzaszolassal korabban beszeltunk: absztrakt osztaly -> definalja hogy MIT tud vagy csinal, de azt nem hogy HOGYAN, azt majd kesobb az interfeszt implementalo osztaly fogja tudni.
Megfelel Javaban az interface-nek, C++ egy osztalynak, aminek csak pure (ezt hogy lehet leforditani?) virtualis fuggvenyei vannak es Object Pascal-ban is van valami hasonlo szerintem.
A 138-as hozzaszolasomban beszeltunk errol. Ott van az absztrakt Konyv. Na az peldaul lehet egy interfesz. Az a programresz, amelyik a konyvet hasznalja, az nem tud a KonyvSQL-rol, csak a Konyvrol es az interfesz lenyege. Tulajdonkeppen egy szerzodes a hivo programresz es az implementalo kozott.
'Szóval ez a része egész jó, de kicsit idealisztikus állapotot rajzol'
masok is mondtak ezt, a XP topicban is van egy kis vita errol.
'Olimpiai játékok rendezését támogató alklamazás fejlesztése'
A politika itt is :)
Nos, mivel jelenleg diplomámat csinálom - államvizsga közelg :)))) -, ezért van időm ilyennel foglalkozni, és még hasznos is, mert az államvizsga B tétele szoftver témájú, az A pedig hardver.
Mondjuk én a hardverhez vagyok hülye, lehet azt kéne olvasni, de az nem tud lekötni. :))))
Tééényleg, valaki nem tud egy állást, fiatal majdnem pályakezdő informatikusnak?
Hááát... Bevezetőnek az UML-be nem rossz.
de például az alábbiak nem tiszták a könyv alapján:
- interfész
- paraméteresett osztály
- use case - állítólag több mint egy funkció, de az nem derül ki, hogy miben
- mit helent az üzenet jellegét meghatározó jellemző (mert van ilyen, egy ábra kapcsán esik szó róla, de hogy mit takar...)
- objektumok a folyam diagramban - elég hiányos ismertető
RUP ismertető, egész jó, de a munkában résztvevő személyek nem igazán jellemzőek a maagyar cégekre.
Szóval ez a része egész jó, de kicsit idealisztikus állapotot rajol (merthogy állandóan az "általában...." kitétellel hivatkozik olyanra, amit igencsak ritkán látni itthon).
A Harmadik könyv, szintén vegyes.
Az első fele a CASE eszközökről szól, illetve "részletes" használati útmutató a Rational Rose 2000-hez.
Na ez a rész tök felesleges. Ha valaha Rose közelébe kerül az ember, a Help-ben több infót talál.
Viszont a könyvben található Használati eset, az Olimpiai játékok rendezését támogató alklamazás fejlesztése.
Elég masszív, 255 oldalas kis mintapélda, plusz a végén mellékletben képernyőtervek, adatbázis modell - nem mintha lehetne bármit is látni belőle, de azért szép, hogy gondoltak rá - és a mntapéldában megvalóstott komponensek forráskódja C++-ban.
Szóva ez a második rész, ami igazán jó belőle, meg az első fejezet, ahol különbző CASE eszközökről ír rövid ismertetőt. A Rose leírást ki lehetett volna hagyni.
Összességében nem bántam meg, hogy beszereztem őket, végül is a három könyv erült annyiba mint bármelyik használható szakkönyv - mondjuk az a Patternes dolog izgatja a fantáziá, de elég drágán számolja a Kiskapu. A kisker árat 330-cal szorozni :SSSSS
Na, elkezdtem a második könyvet.
Most tartok a 3. fejezetnél, eddig jó, mi az UML, mi mit jelent, hogy kell használni, mik a jelölések, egész részletesen.
Egyértelűen és bevallottan a Booch-Rumbaugh-Jacobson könyv többet tartalmaz - ajánlgatja is -, de az meg nincsen magyarul és különben is vmi 45-50 dólares.
Szóval aki azt a könyvet kiolvasta, sok údonságot nem fog találni UML-lel kapcsolatban.
A második fele viszont Rational Unified Process leírása, na arra nagyon kiváncsi vagyok.
/A Rational Rose-ról pedig annyit ír, hogy
Nem minden esetben kompatibilis az UML-lel és a RUP módszertannal / ez már azért is gáz, mert ugyanaz a cég fejlesztett mind a kettőt.
több vonatkozásban sem támogatja a szbványos modellező nyelv megoldási ajánlásait, illetve
náha hosszadalmas kísérletezés után "kidolgozott" trükkökkel lehet csak bizonyos modellezési specifikációkat megvalósítani.
Ettől független én kedvelem a Rose-t bár a fentiekkel egyetértek.
Mindenesetre jövő héten jön ennek a könyvnek a bemutatása. Egyszer majd csak megtanulom, hogy kell kritikát írni :)))
Igen, probléma a szoftver vs. rendszer.
Ezért lett volna jó, ha - mint mondtam - a könyv elején, vagy legalább a fogalom jegyzékben tisztázza, hogy számára a rendszer mit jelent.
Akkor egy szavam sincs. Így viszont, hol így, hol úgy használja, ami kifejezetten zavaró.
Ha rendszreen a programot értjük, akkor valóban, a felhasználó külső objektum.
Azonban ha a rendszeren a könyvtárat értjük, akkor a rendszer belső objektumai.
Logikai tervezés: számomra - a la Halssy :))) - azt jelenti, hogy programfüggetlenül, csak absztrakt osztályokkal tervezek. Tehát ahogy mondtad, Könyv osztály, aminek Olvasás, Írás, Szerkesztés eljárásai vannak, és utánna, az implementáló szoftver kiválasztásakor készítem el a fizikai tervét : TKonyv, getContents, writeContents, setAvailable, stb..
Ennek szvsz az az előnye, hogy a logikai terv alapján - ami OO volt - FoxPro-ban is meglehetett valósítani a progit, ami ügye nem túl OO nyelv :))
Igazad van, hogy ez talán az analysis területéhez tartozik, bár itt megint a fogalomzavar jön, hiszen az analysis sok embernél a Jelenlegi állapot fetárása, problémák, követelmények elemzése címen fut.
A gondom ismét az volt, hogy következetlenül használta: üzleti modell, fogalmi modell, logikai modell, fizikai modell, volt minden, csak a logikai modellt hol a fogalmi (nála konceptuális) modellel, hol a fizikai modellel mosta össze.
Részemről előnyben részesítem annak a gonolatát, hogy egy nyelv független modellt készítsünk, mert amíg dolgoztam, többször láttam, hogy ugyanazt a programot, megrendelői kérésre hol FoxPro-b an, hol Java -ban, hol VB-ben kellett megvalósítani.
Ha van egy nyelvfüggetlen terv, akkor ez nem akkora probléma, mintha a FoxPro megkötéseivel készített tervet kellene átültetni Java-ra.
Szakkönyvlista:
- Dr. Halassy Béla: Ember - Információ - Rendszer
- Dr. Halassy Béla: Az adatbázis-tervezés alapjai és titkai
- Raffai Mária: Objektuomk az üzleti életben
- Raffai Mária: Egységes módszerek a fejlesztésben
- Bana István: Az SSADM rendszerszervezési módszertan
- Adamcsik János: Irodaautomatizálás
- Dave Ensor & Ian Stevenson: Oracle-tervezés
- Kende Mária - Kotsis Domokos - Nagy István: Adatbázis-kezelés az ORACLE rendszerben
Elekronikus formában:
Az informatikai strategia iranyitasanak alapelvei
Bevezetes a PRINCE projektiranyitasi modszertanba
Intromatikai Strategiai tervezes a gyakorlatban
Applying requirement Management with Use Cases
Conducting SEI-Assisted Software Process Assessments
Issues in Requirement Elicitation
Iterative Process Overview
RUP System Engineering 1.0 /látjátok, ők is külön veszik a szoftvert, és a rnedszert :)))/
RUP Best Practices
Metrics Practices 2002
Capability Maturity Model for Softwares Version 1.1
Software Measurement for DoD Systems - Recommendations for Initial Core Measures
Software Measures and the Capability Maturity Model
SSADM - ITB fordítás
CASE Planing and the Software Process /ez a CASE eszközök használatáról és bwevezetéséről szól/
Developing Large Scale Systems with the RUP
The UML and Data Modeling
The Ten Essential of RUP
A Rational Developement Process
UML 1.4 / a 800 oldalas UML leírás :)) /
Euromethod
The Rational Edge Magazine - 2000 dec.-től 2002 jún.-ig
Rose Wire Magazine
+ Magyar Infromatikusok I. és II. Világtalálkozójának előadási könyv formában.
eloszor is koszonet hogy vetted a faradtsagot es megosztottad velunk a velemenyed a konyvrol.
Latom a rendszer vs. szoftver fogalmak kisse osszekavartak. Igazabol ezert kerdeztem korabban mi a kulonbseg a ketto kozott, mert en is (es a konyv is) a rendszer szot a szoftverre hasznalja, rendszer = szoftver. Ebben az ertelemben a kovetkezo ertelmet nyer:
'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'
Az alkalmazottak es a kolcsonzok is hasznaljak a szoftvert (rendszert) ezert kivul allnak rajta. Az mas ha a szoftver tarol valamilyen infot az alkalmazottakrol es a kolcsonzokrol, attol meg nem reszei a rendszernek. Persze ez nagy altalanossagban feladatspecifikus.
'Vannak fenntartásaim a leírtakkal kapcsolatban - pl. a logikai tervezéshez szükséges a fizikai környezet ismerete, mert annak megfelelően kell azt végrehajtani, ami szerintem abszurd, ha
kifejezetten Delphi-re tervezek, akkor az már nem teljesen logikai, de ízlések és pofonok.'
Mert igazabol itt ket lepes van: analysis es design. Az elsoben allitod fel azokat a interface -eket es osztalyokat, amelyek a problemara jellemzoek, a masodikban alakitod ki azokat az osztalyokat amelyek technologia fuggoek es az elso lepesben elkeszult osztalyok feladatait oldja meg. Az elso lepes osztalyai absztraktabbak. Peldaul, az elsoben csinalsz egy Konyv osztalyt, a masodikban egy KonyvSQL osztalyt ami mar SQL + relacios adatbazist hasznal, ez mar technologia fuggo. Vagy csinalsz egy absztrakt KonyvLista ablakot aminek van egy JelenitsdmegAzOsszesKonyvet metodusa. Aztan a masodik lepesben lesz egy KonyvListaForm delphi formod, aminek szinten van JelenitsdmegAzOsszesKonyvet methodusa es lehet hogy a delphi adatbazis komponenseit (TDataSet stb) hasznalja, ami megint technologia fuggo.
Amugy sokszor tenyleg nem kene mindig leforditani szakszavakat angolrol magyarra, mert elveszhet a jelentese es ezt meg tetezheti az is, hogy sokszor az angol jelentesen se erti mindenki ugyanazt.
Milyen programnyelvet ajánlotok egy ábraszerkesztő program vizuális felületének megvalósítására?
Windows alá, választható programok: Visual Studio .NET, Visual Studio 6.0, Delphi 5, Delphi 6, Visual Java, bármilyen más Java.
Csinálni szeretnék magamnak egy normális ábraszerkesztőt, ami SSADM és UML komform.
Délután pedig felrakom a "szakkonyv" listámat - elég lightos, attól tartok, de hátha valakinek megtetszik valami :))
Hát, elértünk a legtartalmasabb fejezethez, a könyvnek kicsit több mint egy negyede - 142 oldal.
A fejlesztést a következő részekre bontja:
Az üzleti modell kialakítása
Követelmény specifikáció
Tervezés
Ez a legzaftosabb rész, van itt minden, logikai tervezéstől, a komponens tervezésig, architektúra
tervezés, minden.
Sajnos mivel általánosságban ír, nem módszer bemutatás, ezért elég sok minden zavaros benne, ezek főleg
azok a területek, ahol a módszerek eltérően dolgoznak.
Vannak fenntartásaim a leírtakkal kapcsolatban - pl. a logikai tervezéshez szükséges a fizikai
környezet ismerete, mert annak megfelelően kell azt végrehajtani, ami szerintem abszurd, ha
kifejezetten Delphi-re tervezek, akkor az már nem teljesen logikai, de ízlések és pofonok.
Mindenesetre a fejezet nem rossz, mint "Bevezetés az OO fejlesztés alapjaiba" egész jó, de ez alapján
nehéz megtanulni, hogyan kell fejleszteni. Igaz,a sorozat következő könyve kifejezetten ezzel
foglalkozik.
Építkezés, tesztelés, bevezetés
Üzemeltetés, rendszerkövetés
Szoftverfejlesztési ajánlások
Összességében egész jó, részletes, hasznos információkat tartalmaz, a "Mit is kéne csinálni?"
kategóriában, jó checklist-et ad a fejlesztés különböző fázisaihoz, bemutatja, hogy az előző fejezetben
alkalmazott technikák hol használhatóak, és a dokumentációs minták is hasznosak.
Az persze fura, hogy az összes javasolt modellezési technika a struktúrált tervezésből van átemelve,
csak a neve más.
Amiket ebből a részből külön kiemelnék, mint kifejezetten hasznos és jó témákat - értsd: feltétlen
olvasd el -, azok a következők:
6.3.2.2 Interfészek tervezése, főleg BEN SHNEIDERMAN-nak a felhasználói interfészekkel szemben
támasztott elvárásokat tartalmazó nyolc pontja.
6.6 Szoftverfejlesztési ajánlások, ebből az egészet, úgy ahogy van.
7. Fejezet Elemzési/tervezési módszertanok
Ez a fejezet néhány fontosabb elemzési/tervezési módszer ismertetésével és "elemzésével" foglalkozik.
Hasznos olvasmány lehet, én ajánlom, hogy ne hagyja ki senki.
Megjegyzés: Nem tudom mi ez a mánia, hogy minden módszert módszertannak neveznek. Téves
meghatározásként elterjedt, hogy a módszertan a módszerek összessége.
Ezzel szemben Halssy is kűifejtette - és még sokan mások is - hogy
"A módszer az adott tárgy megvalósítását elősegítő technikák és megoldási módszerek
szervezett, konkrét együttese. Ezzel szemben a módszertan 'a módszerek módszere". Azzal
foglalkozik az absztrakció magasabb síkján, hogy miképpen épülnek fel a konkrét módszerek, mint olyan
dolgok, amelyek maguk is rendszerként szemlélendők. A ,specifikusban[módszer] a
módszer-alkalmazó, a generikusban [módszertan] a módszer-alkotó érdekelt."
- Halassy Béla: Ember - Információ - rendszer (4.1 Szemléleti zavarok, 136. oldal)
8. Fejezet - Migráció az OO irányába
Ez a fejezet azzal foglakozik, hogy milyen döntéseket kell hozni, és milyen szempontokat kel figyelembe
venni, amennyiben az OO fejlesztésre állunk át. Ehhez a részhez igazából nem tudok hozzászólni, talán
valami hozzáértőbb, menedzser típusú ember.
Ajánlott elolvasni a 8.3 Az OT tízparancsolata részt: Ha valaki, úgy veszi észre, hogy a tízparancsolat
megvalósult körülötte,
Keresse fel orvosát, hátha csak halucinál.
Készüljön fel, ez már a menyország, valószínűleg kihagyta a feltámadást
:)))))
Viccen kívül, alap meglátások, á la józan parszati ész...
Csak külföldön, de az nem számít, mert ránk nincs hatással. És különben sem engedtek túlságosan belekukkolni, mindenféle hülye titoktartási kötelezettségre, meg szerződésre hivatkozva.
Ja, igen, és magyarországon is láttam egy SSADM-es tervezést, méghozzá aktív felhasználói részvétellel.
Persze, igazából az is csak adatbázis terv lett a végén.
A BME posztgrad képzését én valami brossúrában láttam, de már elhagytam, de ha látok valamit szólok.
Ja igen, van nálam egy EuroMethod nevezetű gyöngyszem - állítólag az EU hivatalos fejlesztési módszerének készül. Elég vaskos, még nem jutottam a végére, de ez is Word doksi.
Mondjuk csinálhatok belőle Pdf-et.
Mint mondottam az első pár fejezet célja az OO ismertetése, fogalm magyarázat. Ez egész jól sikerült.
Úgyhogy szerintem nem annyira igaz a "magyarul nem szabad semmifele programozassal kapcsolatos konyvet olvasni. " - pláe, hogy ennek a könyvnek semmi köze a programozáshoz :)
Kb annyi, mint a Bevezetés a műszaki tervezésnek az esztergáláshoz :)))
Csak vannak hibái.
Amúgy, volt szerencsém néhány külföldi gyöngyszemhez is, hááát...
bocs nem tűnt fel a másik topicban hogy nekem feleltél :) most elolvastam újra és ott van hogy "rám reagáltál".
Mindenkihez:
A MEH-es SSADM doksi érdekes , egy projektnél a megrendelő tanácsadója ebből mreg egy angol nyelvű SSADM leírásból vagdosott ki részleteket
mit kell megcsinálnunk...egész normálisan...aztán mi ett nem tudom mert átraktak másik projektbe :(.
Arra még senki se reagált, hogy hol találok infot a BME állítólagosan létező posztgrad porgramtervező képzéséről..legalább kíváncsi lennék mit tanítanak ott.
Meg ugye arra is kíváncsi lennék ebből a sok elméletből lett-e gyakorlat: látott már valaki rendesen _végigvitt_ tervezést?
