PowerDesigner 1. Előnyök, tulajdonságok

 Miért is szerethető a PowerDesigner (PD)

PowerDesigner (PD) használatának az üzleti folyamatokra és minőség biztosításra gyakorolt hatása

-Igény, elvárás, követelménykezelés, függőség elemzés magas szintű biztosítása

-Kockázatelemzés (kockázati tényezők, bekövetkezés esélye, rögzíthetőek) elemezhetővé válik

- Változáskezelés és változások dokumentáltsága magasabb szinten valósulhat meg

- A rendszerek és rendszerkapcsolatok megértése és dokumentálása kiemelkedő

-Testre szabható projektdokumentáció előállítása, központi tárolása és publikálása (Repository)

- A tervezési és fejlesztési folyamatok hatékonyabb nyomon követése megvalósulhat

 

Az alábbi DWH fejlesztési területeken nyújt segítséget a PD:

·        Specifikációk készítése

·        Fejlesztések megvalósítása

·        Adattisztítási feladatok

·        Adat karbantartás

·        Új adatpiac fejlesztése

·        Rendszer migráció

·        Új rendszer bevezetése

 

 

PD felhasználási területek:

·        Egységes felületet biztosít a szervezet által kezelt adatok nyilvántartásához

·        Támogatja új folyamatok kialakítását, valamint a meglévők átalakítását

·        Támogatja a rendszerfejlesztést

·        Keretet biztosít a fejlesztői dokumentációk készítéséhez

·        Segíti a belső kommunikációt, különösen az üzleti és a támogató területek között

·        Segíti a külső kommunikációt a szervezet és az IT fejlesztők között

 

 

PD mint központi projektdokumentáció támogató eszköz

• Teljes projektdokumentáció tárolása központilag – Modellek – Projekt dokumentumok – Forráskód, SQL szkript – Strukturált formában (mappák)

• Csoportmunka (felhasználói jogosultság kezelés)

• Verzionálás (elemszintű)

 

 

DWH területen jól alkalmazható PD funkciók

Fizikai adatmodell: A logikai modellben történt változtatások automatikusan átvezethetőek a fizikai adatmodellbe (PDM), ahonnan adatbázis létrehozó és módosító SQL szkriptek generálhatóak.

Logikai szintű adatmodellezés: a PowerDesigner a fogalmi (CDM) és logikai modellen (LDM) keresztül biztosítja a platform-független adatmodellezést. Az E/R, Merise és Barker jelölésrendszert egyaránt támogatja, lehetőség van öröklési hierarchiákban történő tervezésre, valamint az ERwin modellek importálására.

Meglévő rendszerek visszafejtése: a meglévő adatbázisok szerkezetének teljes körű visszafejtése, az adatbázis struktúrában bekövetkezett változások összevetése a modellekkel.

Repository: a vállalati Repository valódi csoportmunkát kínál a felhasználóknak. A Repositoryban elhelyezett modellek verzionálhatóak. A Repository nem csak a modellek, hanem bármely projektdokumentum tárolására, verzionálására is alkalmas.

 

 

Helyi modell állomány és központi repozitori kapcsolata a PD konfigurációban:

 

Vállalati szintű egységes repozitori támogató funkciói főleg az alábbiak:

• Csoport munka: Egy időben többen is dolgozhatnak ugyanazokon a modelleken.
  
  
• Metaadat-kezelés: A Repository segítségével egyetlen helyen tárolhatjuk, kezelhetjük a Power Designer modelljeink vagy bármely állomány különböző verzióit.
  
  
• Hatáselemzés: A PD eltárolja az egyes modellek közötti összefüggéseket is a Repositoryban, így a modellek között hatáselemzést végezhetünk.
  
  
• Vállalati fogalomtár (Enterprise Glossary): Bármely modell bármely eleme összeköthető egy fogalommal, amely előzőleg felvételre került a közös fogalomtárban. Így biztosítható, hogy a tervezők és fejlesztők az eltérő adatbázisokban és rendszerekben egységes nyelvet, egységes fogalmakat használjanak ugyanannak az adatnak vagy elemnek a jelölésére.
  
  
• Újrahasznosítás: A Repository segítségével megoszthatjuk az egyes informatikai rendszerek felépítését más fejlesztőkkel, tervezőkkel, így elősegíthető a szoftverelemek újrahasznosítása.
  
  
• Biztonságos: Szerepkörök (felhasználók és csoportok) hozhatóak létre, a felhasználók hozzáférése így korlátozható modell- és diagram-szinten.
  
  
• Nyitott: A Repository bármely RDBMS-szerverre feltelepíthető, az adatbázisból SQL utasításokkal saját riportok állíthatóak elő.

 

 

Fizikai adatmodell felhasználási területe:

Fizikai adatmodell (PDM) generálható vagy frissíthető a meglévő logikai adatmodellekből

            – Lehetőség: egy logikai modell több fizikai platformra

• Platformfüggő modellezési szint

– a PowerDesigner több mint 60 RDBMS-t ismer

– a választott platformnak megfelelő fizikai kapcsolatokat épít a táblák között

– Egyéb fizikai paraméterek megadása (pl. particionálás, szegmenskezelés, lockolási sémák, jogosultsági szintek)

• SQL szkript-generálás és -visszafejtés – adatbázis létrehozása és módosítása – SQL állományok és ODBC-n keresztül is • Jogosultságok modellezése

• multidimenzionális nézet

– Ténytáblák, dimenziótáblák kezelése

– Cube generálás

– Denormalizáció

• generálás: CDM, UML osztálydiagram, XML modell

 

 

Magas szintű változás követés

• Változási igények keletkezése időben:

– Már a tervezési/fejlesztési fázisba

– Bevezetést követően fellelt hibák javítása (bugtracking)

– Módosítási igények (akár évekkel később)

• Hatékony változáskezelés PowerDesignerrel:

– A változások alapján hatás elemzés

– A változásokat elsőként a modellekbe is be kell vezetni, utána a kódba (van mód re-engineeringre) – Verzionálás a Repositoryban

• A változáskövetés a projekt-életciklust követi iteratív módon

 

 

Üzeleti szótárak kialakítása

A PD támogatást nyújt a csoportmunkához, az üzleti és IT fogalmak egységesítése érdekében vállalati fogalomtár (Enterprise Glossary) alakítható ki benne.

A Központi repositoryban elhelyezett modellek és dokumentumok verziózható formában egyszerűen megoszthatóak, és publikálhatóak egy webes felületen keresztül azok számára is, akik PowerDesigner telepített eszközzel nem rendelkeznek.

 

PD három főbb előnye, mely a DWH fejlesztésben is jelentkezik:
- Függőségelemzés a meglévő dokumentációk alapján a specifikációs fázisban
- Fejlesztési dokumentáció készítése a tervezés és fejlesztés fázisaiban
- Élesítés utáni dokumentáció frissítése a tényleges éles rendszer alapján

A technikai és üzleti függőségek figyelembevételének, felmérésének és modellben jelzés fontossága: 

 Ha kitörlünk egy adatbázistábla adott oszlopát, melyet egy másik DWH töltőeljárás használ, akkor a töltőeljárás működésképtelenné válik, mely megakasztja a napi DWH töltést technikai függés figyelmen kívül hagyása miatt. 

Ennek elhárítása a legtöbb esetben magas prioritású és rendkívüli ráfordítást igényel. 

 Az előbbinél sokkal nagyobb probléma azonban, egy üzleti függőség figyelmen kívül hagyása. Hiszen, ha például üzleti értelemben megváltozik egy mező tartalma, amelyre függőség épül, akkor a töltőeljárás technikailag még lehet, hogy lefut. Ebben az esetben azonban előfordulhat, hogy a megváltozott mezőtartalom olyan helyekre kerül betöltésre, ahova üzleti értelemben nem való. 

Ez azért veszélyes hiba, mert előfordulhat, hogy a hibát hosszabb ideig senki sem fedezi fel, a napi töltés üzemszerűen folyik, de megtévesztő adatok kerülnek betöltésre.

A függőségfelmérést a PowerDesigner ’Lineage and Impact analysis’ funkciójával lehet elvégezni. A felmérés során előfordulhat, hogy csak olyan információ áll rendelkezésünkre, hogy egy tábla, vagy mező mely programon, adatbázis eljáráson (mapping-en) belül töltődik, de maga a forrás tábla, vagy mező információja nem található meg a dokumentációban. 

Ilyen állapot jellemzően az olyan nagy bonyolultságú töltő logikák esetében fordulhat elő, melyek értelmezése szoftveres úton nem megoldható.

Ebben az esetben a felmérést a Lineage elemzés, majd ezt követően a kód elemzés mellett, akár egy újabb Lineage elemzéssel, több lépésben lehet elvégezni.

Fejlesztési folyamat és folyamatágak kialakítása

Lépések és szabályok

Az éles PowerDesigner repository-ban létrehoztunk egy DWH Dokumentáció – Master nevű Branch-et. 

Ez a Branch lesz minden Release kiindulási alapja. 

Az egyes Release Branch-ek pedig a Fejlesztési Branch-ek alapjául szolgálnak. 

A Master Branch tartalmaz minden adatbázis dokumentációhoz köthető fizikai adatmodellt. 

Minden adatbázis séma külön fizikai adatmodellbe került, melynek neve megegyezik a séma nevével. 

 Az üzletileg összetartozó objektumok azonos sémába kerültek. 

Minden Release esetén a Master Branch-ből kiindulva klónozással elkészítjük az új Releasehez tartozó Branch-et. A Release Branch nevének tartalmaznia kell a Release számát a sablonos DHW_ÉÉRMM formátumban, ahol az ÉÉ és MM a release év és hónapját jelentik. 

Tervezés megkezdése előtt a PowerDesigner repository-ján belül a Release Branch-ből kiindulva klónozással elkészítjük az új fejlesztéshez tartozó szálat. 

Az új Branch nevének tartalmaznia kell a fejlesztés azonosító számát. Amíg a fejlesztés azonosító szám nem érhető el, addig a Branch létrehozójának felhasználó azonosítóját kell hogy a Branch neve tartalmazza. 

A későbbiekben, amikor a fejlesztés azonosító szám kiderül, akkor a Branch-et át kell nevezni úgy, hogy aa fejlesztés azonosító szám is bekerüljön a névbe. 

A származtatáskor a Branch jogosultságait úgy kell beállítani, hogy minden a feladathoz köthető személynek, aki szerkeszteni fogja a modell-t, írás szintű hozzáférése legyen a Branch-hez. 

A klónozás során minden esetben a legfrissebb verzióból indulunk ki, másra nincs is lehetőség. 

Csak abban esetben nem szabadna a legfrissebb állapotból kiindulni, ha egy adott verzió nem kerülne élesítésre, de ilyen állapot nem lesz, mert csak az élesítésre kerülő verziókat fogjuk a Master Branch-be visszatölteni. 

A leszármaztatott Fejlesztési Branch repository-ból kiindulva Check-Out lépés után kezdjük a tervezést a saját gépünkön. E Check-Out lépés során a saját fejlesztési Branch-ünk szerkesztendő adatmodelljeit kell a gépünkre lokálisan lementeni. 

Fontos megjegyezni, hogy mapping-ek esetén egy mapping több adatmodellt (sémát) is érinthet, mivel a mapping source és target oldali objektuma különböző adatmodellekben is lehet. Erre mindenképpen fel kell készülni.

A napi munkát az adott nap végén a Check-In funkció használatával visszaszinkronizáljuk a saját leszármaztatott Fejlesztési Branch-be a repository-n belül. 

Ezáltal egy szerveren, biztonságosan kerül tárolásra a munkánk. Továbbá a Check-In naponta történő használatával elérhetővé válnak a napi szintű változások az adatmodellben. 

A Check-In eljárás során a verziók automatikusan commentezésre kerülnek. A commentben megtalálható a módosító neve, és dátum is. Illetve további megjegyzések hozzáfűzésére is van lehetőség, mely a tervező munkáját segíti a napi feladatok ellátása közben.

A Review-k szerepe

Annak érdekében, tovább erősítsük a dokumentáció megfelelő minőségének elkészültét, módszertanilag javasolt a review elvégzése. 

A review során egy csapaton belüli szakértővel, aki a tervezésben nem vett részt újra át lehet tekinteni a megtervezett objektumokat, és könnyebben fel lehet fedezni az esetleges javítandó hibákat. 

Gyakran előfordul, hogy egy külső szemlélő könnyebben észrevesz bizonyos javítandókat. 

A review célja, hogy az elkészült végeredmény minél jobb minőségű lehessen. 

Közös cél és érdek tehát a teljességre való törekvés. 

A tapasztalat azt mutatja, hogy e tervezéskori részletes kidolgozás és a tervezéskori befektetés a későbbi fejlesztések során többszörösen megtérül

PowerDesigner Branch migrálása/Integrálása 

A tervek elkészülte után a származtatott fejlesztési Branch-et az ’Integrate’ funkcióval visszatöltjük a Release Branch-be. 

Itt rendkívül körültekintően kell eljárni, mivel a folyamtban ez a legfelelősségteljesebb lépés, hiszen az éles dokumentációba, melyet mindenki más is használ, töltjük vissza a módosításainkat. 

Egy Branch Integráláskor hasonló merge funkcióval találkozunk, mint a Check-In lépések során. Összehasonlításra kerülnek a két modell objektumai, majd a különbségeket lehetőség van beszinkronizálni egyik modellből a másikba. 

Ennél a lépésnél részletesebb comment-et várunk el az integrálást végző személytől azért, hogy később könnyebben nyomon lehessen követni a verziók tartalmát.

Párhuzamos fejlesztéseknél (több Branch párhuzamos élete során) a nagyobb felelősség az Integrálást később végző személyt terheli.

Nézzünk egy elvi példát a több fejlesztési szálas branch -ra

Az ábrán az idősíkot függőlegesen, fentről lefelé ábrázoltuk. 

Párhuzamosan láthatóak egymás mellett az egyes Branch-ek (fejlesztési szálak) élettörténete azonos időpillanatokban szemlélve. 

Zöld nyilakkal jelöltük a Branch leszármaztatások lépéseit. 

Kék nyilakkal jelöltük a Branch Integrálások lépéseit. 

Az első szálon a Master Branch élettörténete látható, a többi szálon pedig a fejlesztési szálak tekinthetőek meg. A rajzon látszódnak továbbá, hogy mely lépéseknél történnek verzióváltozások az idő haladtával. 

Vegyük észre, hogy a koncepció szerint a Master Branch verziószámai csakis Branch Integráláskor változnak. Ennek az az oka, hogy a Master Branch-et közvetlenül soha nem szerkeszthetjük egy-egy fejlesztés miatt. 

A fejlesztést minden esetben csakis a saját fejlesztési Branch-ben kell elvégezni, majd a végeredményt innen lehet visszaintegrálni a Master Branch-be. 

Az egyes fejlesztési szálak vissza Integrálása nem feltétlenül a leszármaztatás sorrendjében történik meg. Ez ugye a fejlesztési feladatok hosszától függ, mely a különböző fejlesztéseknél eltér egymástól.

Jelen példánknál maradva, az 1. fejlesztés kiindulási alapja nem tartalmaz olyan objektum módosításokat, melyek a 2. fejlesztés során korábban kerültek Integrálásra, mint az 1. fejlesztés módosításai. 

Ilyen esetben hangsúlyosan figyelni kell az Integráláskor arra, hogy ütközés esetén mely változtatás legyen a végeredmény. Ebben nyújt segítséget az Integráláskor megkövetelt comment-ezés, mellyel könnyen kideríthető, hogy kivel szükséges egyeztetni a felmerülő kérdésekről.

Hasznos funkció a modellen állva helyi menüből kért listák megjelenítése

Igény szerint szűrhető rendezhető az információ (például a táblák mezői)

Listából egyből a megjelenítésre tudunk átfúrni egy gomb segítségével