-
Fototrend
Új hozzászólás Aktív témák
-
-
#5272
Sk8erPeter
nagyúr
stevve
#5269
Sk8erPeter
nagyúr
Szerintem akár egyetlen emberből álló munkánál is hasznos lehet az UML-ismeret.
Most ez lehet, hogy nem a legjobb példa, de én is hadd mondjak egyet. Hobbiból folyamatosan csiszolgatom egy régen elkészített honlap kódját, állandóan változtatok rajta, és röhögök a korábban megírt kódjaimon, és annál jobbat írok, aztán később majd ezen is röhögni fogok, és átalakítottam már a kódnak nagyjából 60%-át objektumorientáltra, ami eléggé segít számomra a kódom áttekinthetőségében, módosíthatóságában, stb. Viszont már kellően sok kódot írtam ahhoz, hogy kezdjem egyre nehezebben átlátni az egyes objektumok kapcsolatait, mi örököl miből, mi tartalmaz mit, mihez milyen metódus, tagváltozó, stb. tartozik, ezért egy programmal legeneráltatttam a kód alapján az UML-diagrammokat, így csomó mindenre rájöttem, hogy mit lehetne egyszerűsíteni, megváltoztatni, áthelyezni, stb. - ismétlem, UML-ábrák alapján. Ezentúl mostanában egyre gyakrabban alkalmazom azt a módszert, hogy a kódírás előtt először megpróbálok valami összedobált UML-diagrammot készíteni arról, amit épp alkotni szeretnék - ez is jelentősen leegyszerűsíti a munkámat, mert sokkal könnyebben észreveszem az esetleges koncepcionális hibákat, főleg, miután UML-diagrammokkal szemléltetve verték a fejünkbe a különböző tervezési mintákat is egyes egyetemi tárgyakból. Ha már erről van szó - a különböző tervezési minták alkalmazása esetén is szinte elkerülhetetlen szerintem az áttekinthetőség érdekében egy normális UML-diagram megalkotása a programunkban szereplő objektumok kapcsolódásáról ahhoz, hogy a megfelelő tervezési mintát rá tudjuk húzni a saját feladatunkra. A tervezési mintákat meg ugye nem hülyeségből találták ki, hanem épp a fejlesztés gyorsítása érdekében.
Mindezt azzal együtt értem, hogy nyilván az UML-diagrammok is állandóan változnak attól függően, hogy a kód épp hogy módosult. Így szerintem az UML-diagrammok előzetes megtervezése, valamint kód alapján történő utólagos megalkotása (legenerálása, ha van rá mód, és elég jó a program, amit erre használunk) is nagyon hasznos lehet. Már csak pont amiatt is, amit azt hiszem Te is írtál, hogy nagyjából egy nyelvet beszéljenek a programozási folyamatok különböző fázisaiban részt vevő fejlesztők is.
Félreértés ne essék, nem azt mondom, hogy UML nélkül nem lehet létezni, sőt, nagyon is sok példa van rá, hogy egyszerűen elkerülik a használatát a fejlesztés során, de nem ördögtől való, és nem is haszontalan találmányról van szó, hanem épp ellenkezőleg, sok hasznát lehet venni adott esetben. -
#5268
Sk8erPeter
nagyúr
stevve
#5258
Sk8erPeter
nagyúr
"Ebben igazad van, ez tényleg kivétel, itt nincs mit tenni, valahogy le kell írni.
A különböző UML diagramokat valóban tudnia kell olvasni egy fejlesztőnek, mert lehet rá szükség, Ezt ki is felejtettem az előbb. Jó is, hogy írtad.
"Ami igazából a mondanivalóm, az az , hogy az UML teljesen alkalmas ezen megbeszélések alkalmával információátadásra, ideiglenes dokumentációként."
Abszolút így van. Ideális esetben mindenki érti és könnyű így megbeszélni, hogy közben táblán, bárhol rajzolgatunk. Csak sajnos sokszor a jelmagyarázattal kell kezdeni, ami elég időrabló."Most a végére rájöttél, hogy az UML mégsem csak egy helykitöltő baromság, ami remélhetőleg egyre kevesebb teret fog kapni a fejlesztésben?
Amúgy látom időközben modderrel regényeket írtatok, úgyhogy túl sokat nem tudok hozzátenni, úgy kiveséztétek, alapvetően modderrel értek egyet, persze Te is sok igazságot mondtál.
-
modder
aktív tag
Köszi
Igen, előnye a C# technológiáknak, hogy mobilra is adaptálták őket sőt, nem akarok hülyeséget mondani, de talán még iPhone-ra is lehet .net-ben fejleszteni. Nem gondoltam, de kábeltelevíziós set-top-boxokra is bizony .net-ben fejlesztenek.
Én pedig még annyit fűznék hozzá, hogy manapság sajnos egy programnyelv ismerete már nem azt jelenti, hogy bekérek a parancssorból és kiíratok. Nagyon komoly és összetett technológiákat kell ismerni a piacképes tudáshoz adott rétegen belül is. Olyanok, mint az említett WCF, WPF, vagy amit mostanában tanulgatok Java EE platformon JPA, JSF és megannyi sok csúnya 3-4 betűs mozaikszó
-
modder
aktív tag
Nem tudom milyen a kódból generált XML doksi. Amit én használtam az a Doxygen, ami feloldja az asszociációkat a jól dokumentált Osztályok és függvények között, majd ezt egy jól érthető HTML vagy PDF formátumban kimenti osztálydiagramokkal együtt. Sőt, léteznek olyan szoftverek is, amik pusztán a kód olvasásából megértik az együttműködéseket, és az alapján generálnak diagramokat. Ezzel felváltható a kézzel megírt végleges fejlesztői dokumentáció egy része is. Nyilván az olvasható, jól dokumentált kód erény, de nem lesz ettől rendszerszinten áttekinthető.
Most mindannyian sokkal okosabbak lettünk
-
modder
aktív tag
Igaz, hogy a kód lehet jó dokumentáció, de ehhez a kód jól dokumentáltsága is szükséges, amiből aztán jó dokumentáció generálható. Nem Javadoc, mert az nem mutat semmit, de pl. Doxygen (vagy fizetős vállalati eszközök). -- ezt csak megjegyzésben írtam, tegyük fel, hogy ez adott.
Jól kifejtetted, a teljesség igénye nélkül néhány dolog ami még eszembe jut.
Mint mondtad, különböző modulok kapcsolódási pontjához hasznos a dokumentáció. Tegyük fel, hogy egy library-t megírt egy fejlesztő, aminek a használata szükségessé válik a projekt egy előrehaladottabb fázisában. Itt már nem biztos, hogy az automatikusan generált osztálydiagram elég, mert az nem fog semmit jelenteni a többi fejlesztő számára a lib használatát illetően. ilyen esetben, akár a hivatalos fejlesztői dokumentációban is megjeleníthető legalább valami kollaborációs diagramra szükség lesz, amit a fejlesztőnek kell létrehozni. -- te is hasonlóra gondoltál?
Egy kis csoportról beszélve, akik egy modulon dolgoznak, pedig szintén nem árt, ha ismerik az UML-t. Egy megbeszélés alkalmával rögzített program flow-t lehet rögzíteni akár papírra, így az adott iterációban vissza lehet hivatkozni rá. Kvázi ez egyenlő azzal, hogy nem kell fejben tartani. Ez egy informális dokumentáció, de UML-t használva még kevesebb hibához is vezethet, mint egy "móriczkarajz"
A használati eset és az activity diagramm legyen a projektvezető dolga szintén.
Ebben igazad van, de valakinek (a szoftverfejlesztőnek) el kell tudni olvasni azt.Rengeteg példa van arra, hogy a rendszer változott, csak a doksikban nem vezették át.
Igen, sajnos a dokumentációt is karban kell tartani. Ha már automatikusan generált doksit említettem, ezt lehet a buildelési fázishoz is kötni. Viszont elvetemült öltet lenne minden iterációban újravizsgálni a dokumentációt is.Egyetértek azzal, hogy nem kell túldokumentálni mindent, és jól működik általában a szoftverfejlesztés formális és informális megbeszélések alapján. Ami igazából a mondanivalóm, az az , hogy az UML teljesen alkalmas ezen megbeszélések alkalmával információátadásra, ideiglenes dokumentációként.
Dekompozició elve:
Minden dekompozició legvégül egy adatbázis tervhez vezet, de tényleg fölösleges az egész rendszert megtervezni adatbázis szinten az elején. Tulajdonképpen az iteratív szoftverfejlesztés pont erről szól, nem? Nem lehet úgy végigcsinálni egy szoftverfejlesztést, mint egy hidat: terv -> implementáció -> kész
-
modder
aktív tag
Hali,
Az UML előnye nem is az 1-2 fős projekteknél ütközik ki, ahol a fejlesztő egy személyben a business analyst, az architect, a manager, a tesztelő is. Bár kifejezetten hasznos.
Amikor több: 5-10-20 fős fejlesztői csapatot kell koordinálni, akkor bizony a fejlesztési módszertanokkal együtt az UML-t is használni kell. Ezek együttesen segítenek mind a szoftver, mind a szoftverfejlesztés minőségét javítani. Persze a dokumentáció mennyiségének növekedésével a szoftverfejlesztés időtartama kitolódik.
Néhány példa, hogy mikor előnyös:
UML activity diagram: Egy nagyobb cégnél a fejlesztők nem találkoznak az ügyféllel közvetlenül, de tudniuk kell mit várnak el a szoftvertől. Ennek lekommunikálásának egyik leghatékonyabb módja pl. egy UML activity diagram.
UML use-case diagram: Az UML activity diagramot az ügyfél beszámolója alapján elkészített use-case-ből generálják. Máris van egy dokumentum, amihez tudnak a fejlesztők fordulni, ha kérdésük van a program flow-val kapcsolatban, és nem kell a BA-t csesztetni.
UML class diagram: szerintem erre gondoltál, amikor azt mondtad, hogy ez úgyis változik, hiszen a belső struktúra az, amit először nem lehet a legjobban eltalálni. Ugyanakkor egy nagyobb projektben szükség van rá interfészek deklarálásához, mert különböző komponenseket különböző fejlesztők készítenek el, tudniuk kell, hogyan csatlakoznak ezek egymáshoz.
UML szekvenciadiagram: Ennek előfeltétele az UML class diagram, megmondja, hogy a komponensek vagy osztályok hogyan kommunikálnak egymással. Ez egy specifikáció a tesztelők számára, akik nem ismerik teljes mértékben a szoftver belső működését, de felismerik, ha az üzenetváltások nem a specifikáció szerint alakulnak.
UML kommunikációs diagram: Más fejlesztők által létrehozott komponensek hogyan kommunikálnak majd egymással. Ennek szerepe lehet architektúra tervezésnél, és mérvadó lehet a kommunikáló komponensek interfészeinek kialakításánál.A diagramok egy része az implementáció megkezdése előtt születik, más részük közben, megint más részük utólag. Természetesen elkerülhetetlen a változás, mert nem lehet minden eshetőséget lefedni a fejlesztés során. Sajnos rossz gyakorlat az, hogy a dokumentációt fejlesztés után készítik el, és a fejlesztés gyakorlatilag ad-hoc módon történik: a fejlesztők egymás között ledumálják ki mit csinál, aztán probléma van, amikor össze kell hegeszteni a dolgot egy egésszé. Erről legtöbbször nem a fejlesztő tehet, mert a határidő mindig valamikor tegnap.
El kell fogadni, hogy a dokumentáció a fejlesztés szerves része, és mint említettem, nagyobb projekteknél a kommunikáció folyamatossága érdekében elkerülhetetlen rossz vagy éppen jó. A példákból pedig látható, hogysajnosa fejlesztőnek is részesülnie kell belőle....szerintem
-
#5194
Sk8erPeter
nagyúr
stevve
#5193
Sk8erPeter
nagyúr
-
tamas60
csendes tag
Egy valamit nem szabad elfelejteni.
Most a megrendelőnél van az a pénz amiből holnap a zsömlémet megvehetem. Ezt próbáltam megértetni a kollégáimmal, hogy nem azért van fizetés mert eljött a 8-a, hanem azért mert letettünk az asztalra valamit amiért pénzt kaptunk.
Aki alkalmazásban áll annak nyűg a megrendelő, mert mindig csak a gond van vele.
Semmi sértőt nem akartam írni, ha mégis sikerült akkor elnézést.Azt hogy mi van a nagy cégeknél nem tudom, én mindig kicsi voltam, de ha nagyobb céggel hozott össze jobb sorsom, akkor mindig van valami ami miatt nem jutunk zöld ágra egymással.
Példa a közelmúltból:
Tudatlan és pongyolán megfogalmaztam mint is szeretnék, egy nagyobb cégnél. Négy fő hallgatja mit is szeretnék. Megértették, a kérdéseikből ez kiderült. Eltelt négy hét, de még nem kaptam árajánlatot a munkára. Rákérdezek mi a helyzet, hol akadt el a dolog. Javasolnak még egy megbeszélést. Megint négyen vannak velem, szembe. Ismét a modern kor összes vívmányával felszerelve, notebook, table pc. Ezzel a négy emberrel én még nem találkoztam és ők sem velem. Kezdődik elölről minden. Azóta eltelt két hét de még árajánlatom máig sincs.
Hát nagyon akarni kell, hogy velük dolgoztasson az ember.
Rosszmájú akarnék lenni azt mondanám többen itt dolgoznak a fórumozók közül. :-) De nekem ez az eszembe sem jutott.:-)
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Eladó MSI B650 GAMING PLUS WIFI Alaplap
- Eladó PNY GeForce RTX 4070 Ti SUPER 16GB videokártya
- Bomba ár! Asus Slate EP121 Tablet - Intel Core i5 I 4GB I 64GB SSD I 12" Touch I Cam I W10 I Gari!
- Bomba ár! HP EliteBook 2570P - i5-3GEN I 4GB I 320GB I DVD I 12,5" HD I W10 I Garancia!
- Bomba ár! HP EliteBook 2560P - i5-2GEN I 4GB I 320GB I 12,5" HD I W10 I Garancia!
- Csere-Beszámítás! Felsőkategóriás számítógép PC Játékra! I9 13900KF / RTX 4080 / 32GB RAM / 1TB SSD
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Eredeti DELL 240W töltők (LA240PM160)
- Dell Latitude 8-11. gen i5, i7, 2-in-1 szinte minden típus csalódásmentes, jó ár, garancia
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest