Új hozzászólás Aktív témák

• modder aktív tag

  #5254

  #5249 stevve

  2011-06-23 15:35:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  modder

  aktív tag

  #5249 stevve

  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ó, hogy sajnos a fejlesztőnek is részesülnie kell belőle.

  ...szerintem

Új hozzászólás Aktív témák