Case technologijos

Įvadas.

Šios apžvalgos tikslas yra įvadas į šiolaikinių informacinių sistemų projektavimo metodų ir priemonių ypatumus naudojant CASE – technologijas.

Šiolaikinių informacinių technologijų vystymosi tendencijos skatina nuolatinį informacinių sistemų (toliau IS) sudėtingumo laipsnio kilimą.

Stambūs šiolaikiniai IS projektai charakterizuojami sekančiais ypatumais:

1. aprašymo sudėtingumas (didelis funkcijų, procesų, duomenų elementų kiekis, sudėtingi tarpusavio ryšiai)

2. surištų procesais komponentų aibė (posistemių, atliekančių lokalias funkcijas aibė)

3. tiesioginių analogų trūkumas, ribojantis kokių nors tipinių projektinių sprendimų panaudojimo galimybę

4. egzistuojančių bei naujai kūriamų priedų integravimo būtinumas

5. funkcionavimas keliose OS

6. ilgas projekto vykdymo laikas

Sėkmingam projekto realizavimui projektavimo objektas ((IS) turi būti adekvačiai aprašytas, turi būti sukurti pilni funkcionalūs informaciniai IS modeliai.

Terminas CASE (Computer Aided Software Engineering) šiais laikais naudojamas labai plačia prasme. Pirminė termino CASE reikšmė, apribota programinės įrangos (toliau PĮ) kūrimo automatizavimo klausimais, šiais laikais įgyjo naują reikšmę, kuri apglebia sudėtingų IS kūrimo procesą bendrai. Dabar CASE – priemonės suprantamos kaip programiniai įrankiai, palaikantys IS kūrimo bei išlaikymo procesus, taip pat reikalavimų formuluotę bei analizę, taikomsios PĮ ir duomenų bazių (toliau DB) projektavimą, kodo generavimą, testavimą, dokumentavimą, kkokybės užtikrinimą, konfiguracinį valdymą bei projekto valdymą, taip pat kitus procesus. CASE – priemonių, sisteminės PĮ ir techninių priemonių visuma – pilnai sukomplektuota IS kūrimo aplinka.

CASE – technologija – tai IS projektavimo metodologija, taip pat instrumentinių priemonių, kurios leidžia aiškia fforma modeliuoti daiktinę sritį, analizuoti minėtą modelį visuose kūrimo arba išlaikimo etapuose ir kurti priedus atitinkančius vartotojo informacinius poreikius.

Nežiūrint į visas CASE – priemonių potencialias galimybes, egzistuoja daug nesėkmingų jų diegimo pavyzdžių, ko pasekoje CASE – priemonės tampa “lentynine” PĮ (shelfware).

Taikant CASE – priemones yra keletas galimo efekto apibrėžimą komplikuojančių faktorių:

1. CASE – priemonių galimybių ir kokybės įvairovė.

2. Naudojimosi CASE – priemonėmis patirties stoka organizacijose.

3. Detalių metrikų ir duomenų nebuvimas jau atliktiems bei atliekamiems projektams.

4. Skirtingas CASE – priemonių integracijos projektuose laipsnis.

Kai kurie analitikai mano, jog reali kai kurių CASE – priemonių pritaikymo nauda gali būti gauta tik po 1-2 metų patirties. Kiti mano, kad įtaką gali būti daroma jau IS gyvenimo ciklo (toliau GC) eksploatacijos fazėje, kai technologiniai patobulinimai gali privesti prie eksploatacinių iišlaidų mažėjimo.

Sėkmingam CASE – priemonių įdiegimui organizacija turi turėti tokias savybes:

1. Technologija. Egzistuojančių galimybių ribotumo suvokimas bei sugebėjimas priimti naujas technologijas.

2. Kultūra. Pasiruošimas naujųjų procesų diegimui.

3. Valdymas. Tikslus vadovavimas ir organizuotumas svarbiausių diegimo etapų ir procesų atžvilgiu.

Jeigu organizacija neturi nors vienos iš aukščiau išvardytų savybių CASE – priemonių diegimas gali nepasisekti neatsižvelgiant į vadovavimosi diegimo rekomendacijomis kruopštumo laipsnį.IS projektavimo metodologijos pagrindai

IS PĮ gyvenimo ciklas

PĮ gyvenimo ciklas (PĮ GC) – nepertraukiamas procesas, kuris prasideda nuo sprendimo apie jo sukurimo būtinumą momento ir baigiasi jjo išėmimo iš eksploatacijos momentu. (paruošimas, eksploatacija, projekto valdymas, konfiguracijos valdymas ir pan.)

Bendras normatyvinis dokumentas, reglamentuojantis PĮ GC, yra tarptautinis standartas ISO/IEC 12207 (ISO – International Organization of Standartization, IEC – International Electronical Commission). Standartas apibūdina GC struktūrą.

PĮ GC modeliai

Standartas ISO/IEC 12207 apibūdina GC struktūrą, bet nekonkretizuoja detaliai, kaip realizuoti arba atlikti veiksmus arba uzduotis, įtrauktus į šuos procesus.

Šiuo metu labiausiai paplitę kaskadinis ir spiroklinis GC modeliai.

Kaskadinis modelis.

Pagrindinė charakteristika – paruošimo proceso padalinimas į etapus, kur perėjimas į sekantį etapą vykdomas tik tuomet kai darbas einamajame etape yra pilnai atliktas.

PĮ kūrimo proceso eigoje atsirado sugrįžimo prie pereitų etapų ir jau priimtų sprendimų patikslinimo arba peržiūros poreikis.

Tada realus PĮ kūrimo procesas pradėjo keistis, o būtent, atrodė taip:

Pagrindinis kaskadinio modelio trukumas yra esminis vėlavimas gaunant rezultatus. Rezultatų suderinimas su vartotojais vykdomas tik taškuose, planuojamuose jau po kiekvieno veiksmų etapo užbaigimo.

Išvardytoms problemoms išvengti buvo pasiūlytas spiroklinis GC modelis, sukoncentruotas pradiniuose GC etapuose, o būtent, analizėje ir projektavime.

Kiekviena spiroklės vija atitinka PĮ fragmentą arba versiją, joje tikslinami projekto tikslai ir charakteristikos, nustatoma jo kokybė ir planuojami sekančios spiroklės vijos veiksmai.

Pagrindinė spiroklinio modelio problema – perėjimo į sekantį etapą momento nustatymas.

IS projektavimo technologijos ir metodologijos.

Bendri reikalavimai metodologijai ir technologijai.

Metodologijos, technologijos ir instrumentinės projektavimo priemonės ssudaro bet kurios IS projekto pagrindą. Metodologija realizuojama per konkrečias technologijas ir jas palaikančius standartus, metodikas ir instrumentines priemones, kurios užtikrina GC procesų atlikimą.

Projektavimo technologija apibrėžiama kaip trijų dalių visuma:

1. poetapinė procedūra, apibūdinanti technologinių projektavimo operacijų eiliškumą.

2. taisyklės ir kriterijai, naudojami technologinių operacijų atlikimo rezultatų vertinimui.

3. notacijos (tekstinių ir grafinių priemonių), naudojamos projektuojamos sistemos aprašymui.

Metodologija RAD

Vienas iš galimų PĮ paruošimo būdų spiroklinio GC modelio ribose yra greito aplikacijų paruošimo metodologija RAD (Rapid Application Development).

RAD – PĮ paruošimo procesas, kurį sudaro 3 elementai:

1. 2-10 žm. programuotojų komanda.

2. 2-6 mėn. gamybos grafikas.

3. Pasikartojantis ciklas, kurio metu programinės įrangos kūrėjai realizuoja produkte reikalavimus, gautus iš užsakovo.

Pagal RAD metodologiją PĮ GC sudaro 4 fazės:

1. Reikalavimų analizės ir planavimo fazė (sistemos vartotojas nustato funkcijas, kurios turi būti vykdomos, išskiria pagrindines iš jų, aprašo informacinius poreikius).

2. Projektavimo fazė (vartotojų dalis dalyvauja sistemos techninio projektavimo procese).

3. Kūrimo fazė (programinės įrangos kūrėjai vykdo iteracinį realios sistemos gamybos procesą).

4. Įdiegimo fazė (vartotojų apmokymas, organizaciniai pakeitimai).

Pažymetina, kad metodologija RAD nėra universali, nes ji gali būti taikoma tik ne dideliems projektams pagal konktetų užsakymą.

RAD negali būti taikoma sudėtingų apskaitos programų gamybai, operacinių sistemų arba kosminių laivų valdymo programų gamybai, t.y. programų, kurios reikalauja šimtų tūkstančių unikalaus kodo elučių, gamybai.

Taip pat netinka aplikacijų, kuriose nėra ryškiai vaizduojama interfeisinė dalis, nes iteracinis būdas nnumato, kad kelios pirmos versijos nebus kokybiškai veikiančios, kas minėtu atveju yra neleistina.

Struktūrinis IS projektavimas.

Struktūrinio IS projektavimo pagrindas yra jos dekompozicija (suskaidymas) į automatizuojamas funkcijas: sistema suskaidoma į funkcionalias posistemes, kurios dalinasi į pofunkcijas, dalinamas į uždavinius ir t.t. Procesas vyksta iki konkrečių procedūrų.

Labiausiai paplitusios struktūrinio projektavimo metodologijos turi bendrus principus.

Du baziniai principai:

1. Principas “skaidyk ir valdyk” – sudėtingų užduočių sprendimo būdas suskaidant jas į kelias paprastesnes ir geriau suprantamas.

2. Ierarchinio sutvarkymo principas – sudedamųjų problemos dalių sutvarkymas į ierarchines struktūras su naujų detalių kiekviename lygyje papildymo galimybe principas.

Struktūrinėje analizėje pagrinde naudojamos dvi priemonių grupės, iliustruojančios funkcijas, vykdomas sistemos ir santykius tarp duomenų. Kiekvienai priemonių grupei atitinka apibrėžtos modelių (diagramų) rūšys, iš kurių labiausiai paplitusios yra:

1. SADT (Structured Analysis and Design Technique)

2. DFD (Data Flow Diagrams)

3. ERD (Entity – Relationship Diagrams)

*Smulkiai jų nenagrinėsime, nes referato rašymui suteikta per mažai laiko 

CASE – priemonių charakteristikos.

SILVERRUN+JAM

Silverrun.

CASE – priemonė Silverrun naudojama verslo klasės IS projektavimui bei analizei. Naudojama DFD ir ERD modelių palaikymui.

Struktūra ir funkcijos.

Silverrun susidaro iš keturių modulių, iš kurių kiekvienas yra “savarankiškas” produktas, todėl gali būti įgytas ir panaudotas be visų kitų modulių.

Modulis BPM (Business Process Modeler) užtikrina galimybę modeliuoti tyriamos organizacijos arba kūriamos IS funkcionavimą.

Modulis ERX (Entity-Relationship eXpert) užtikrina galimybę duomenų modelių “Entity-Relationship” kūrimą.

(skirtų realizuoti reliacinėje db)

Modulis RDM (Relational Data Modeler) užtikrina galimybę kurti detalizuotus “Entity-Relationship” modelius. (skirtus realizuoti reliacinėje db)

WRM (Workgroup Repository Manager) naudojamas kaip duomenų žodynas, kuriame saugomi bendri visiems moduliams duomenys, be to jis realizuoja Silverrun modulių integraciją į vieningą projektavimo aplinką.

Saveika su kitomis priemonėmis

Automatiniam duomenų bazių schemų generavimui Silverrun turi “tiltus” (interface) į labiausiai paplitusias duomenų bazių valdymo sistemas (toliau DBVS): Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Duomenų perdavimui priedų kurimo priemonėms yra “tiltai” (interface) į kkalbas: JAM, 4GL, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.

Duomenų mainams su kitomis projektavimo automatizavimo priemonėmis, specializuotų procedūrų analizės ir projektinių specifikacijų kūrimo tikrinimui, specializuotų ataskaitų generavimui Silverrun sistemoje yra trys projektinės informacijos išvedimo į išorinius failus būdai:

1. Ataskaitų sistema.

2. Eksporto/Importo sistema.

3. Saugyklos (Repository) saugojimas išoriniuose failuose per ODBC draiverius.

Grupinis darbas.

Grupinis darbas Silverrun sistemoje palaikomas dviem būdais:

1. Standartinėje Silverrun (vienos darbo vietos) versijoje yra kontroliuojamo modelių išskirimo bei suliejimo mechanizmas.

2. Tinklo Silverrun versija leidžia įgyvendinti lygiagretų grupinį darba su modeliais, saugomais tinklo saugykloje (Repository) DBVS Oracle, SSybase arba Informix DB.

Funkcionavimo aplinka.

MS Windows, Macintosh ir OS/2 Presentation Manager.

Funkcionavimui Windows terpėje rekalningas ne senesnis negu i486 procesorius ir ne mažiau negu 8 Mb operatyviosios atminties. Pilnai įdiegtas Silverrun diske užima 20 Mb.

JAM

Pagrindinis JAM bruožas – pilnas atitikimas metodologijai RRAD.

Struktūra ir funkcijos.

JAM turi modulių struktūrą ir susideda iš šių komponentų:

1. Sistemos branduolis.

2. JAM/Dbi – specializuoti interfeiso su DBVS moduliai (JAM/Dbi – Oracle, JAM/Dbi – Informix ir kt.)

3. JAM/RW – ataskaitų generatoriaus modulis.

4. JAM/CASEi – specializuoti interfeiso su CASE-priemonėmis moduliai (JAM/CASE-TeamWork, JAM/CASE-Innovator ir kt.)

5. JAM/Tpi – specializuoti interfeiso su tranzakcijų menedžeriais moduliai (JAM/Tpi – Server TUXEDO ir kt.)

6. Jterm – specializuotas X terminalo emuliatorius.

Sistemos branduolis susidaro iš komponentų:

1. ekranų redaktorius.

2. meniu redaktorius.

3. pagalbinių paslaugų (utility) rinkinys.

4. gamyklinės aplikacijos versijos gamybos priemonės.

Interfeiso projektavimas realizuojamas ekranų redaktoriaus pagalba.

Meniu redaktorius leidžia ruošti ir tvarkyti meniu sistemas.

Tvarkytojas leidžia atlikti kompleksinį priedo tvarkymą.

Vienas iš papildomų JAM modulių yra ataskaitų generatorius.

JAM turi įntegruotą programavimo kalbą JPL (JAM Procedural Language), kuri leidžia prireikus parašyti modulius, realizuojančius specifinius veiksmus.

Sąveika su kitomis priemonėmis.

Sąveiką su DBVS realizuoja JAM/DBi moduliai. Sąveikos rrealizavimo metodai dalinasi į dvi klases: rankinio valdymo ir automatiniai.

Rankinio valdymo metodas – SQL užklausos rašomos savarankiškai.

Automatinis metodas – tipinių operacijų su DB (QBE – Query By Example) atlikimui (užklausos generuojamos automatiškai pagal šabloną).

JAM leidžia kurti priedus darbui su daugiau nei 20 DBVS: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC ir kt.

Interfeisas Silverrun-RDM realizuoja sąveiką tarp Silverrun ir JAM.

Grupinis darbas:

JAM branduolis turi integruotą interfeisą su konfiguracinio valdymo priemonėmis. (PVCS – Windows, SCCS – UNIX)

Minėtų sistemų valdymo ddėka perduodamos ekranų bibliotekos ir/arba saugyklai (Repository). Nesant tokiom sistemom JAM savarankiškai realizuoja grupinio ruošimo palaikimo funkcijų dalį.

Funkcionavimo aplinka.

Windows – 8 Mb operatyviosios atminties, 50Mb diske.

UNIX – reikalavimai apibrėžiami pačios OS.

Designer/2000 + Developer/2000

CASE – priemonė Designer/2000 2.0 (ORACLE) yra integruota CASE – priemonė, kuri kartu su Developer/2000 užtikrina sistemoms, naudojančioms DBVS ORACLE, GC palaikimą.

Struktūra ir funkcijos.

Bazinė Designer/2000 metodologija – struktūrinė sistemų projektavimo metodologija, apimanti visus GC etapus.

Planavimo etape nustatomi sistemos kurimo tikslai, prioritetai ir apribojimai, ruošiama sistemos architektūra ir IS ruošimo planas.

Analizės proceso metu kuriamas informacinių poreikių modelis, funkcinės ierarchijos diagrama, persikryžiuojančių nuorodų matrica, duomenų srautų diagrama.

Projektavimo etape ruošiama išsami IS architektūra, projektuojama reliacinės DB schema, programiniai moduliai.

Realizavimo etape kūriama DB, taikomosios sistemos, vykdomas jų testavimas, kokybės bei atitikimo vartotojo poreikiams tikrinimas.

Designer/2000 komponentai:

1. Repository Administrator – saugyklos (Repository) valdymo priemonės. (aplikacijų kūrimas ir šalinimas, priėjimų prie duomenų valdymas, duomenų eksportas/importas)

2. Repository Object Navigator – priėjimo prie saugyklos (Repository) priemonės.

3. Process Modeller – verslo veiklos analizės ir modeliavimo priemonė.

4. Systems Modeller – projektuojamos IS funkcionalių ir informacinių modelių kūrimo priemonių rinkinys. (Entity – Relationship Diagrammer, Function Hierarchy Diagrammer, Data Flow Diagrammer, Matrix Diagrammer)

5. Systems Designer – IS projektavimo priemonių rinkinys, kuriame yra reliacinės DB struktūros kūrimo priemonė (Data Diagrammer), taip pat diagramų, atvaizduojančių sąveiką su duomenimis, iierarchiją, aplikacijų logiką ir struktūrą, realizuojamą saugojomis PL/SQL kalba procedūromis, kūrimo priemonės. (Module Data Diagrammer, Module Structure Diagrammer, Module Logic Diagrammer)

6. Server Generator – ORACLE DB objektų aprašymų generatorius (lentelių, indeksų, raktų ir pan.) Generavimas gali būti vykdomas Informix, DB/2, Microsoft SQL Server, Sybase DBVS, taip pat ANSI SQL DDL standartui ir DB, prie kurių priejimas realizuojamas ODBC pagalba.

7. Forms Generator (ORACLE Forms aplikacijų generatorius). (Įvairių ekraninių formų generavimas, automatinių pasakinėjimų generavimas ir pan.) *Tolimesnis darbas vykdomas Developer/2000 terpėje.

8. Repository Reports – standartinių ataskaitų saugykla (Repository), integruota su ORACLE Reports ir leidžianti keisti struktūrinį informacijos pristatymą.

Sąveika su kitomis priemonėmis.

Designer/2000 galima integruoti su kitomis priemonėmis, naudojant atvirą API aplikacijų interfeisą. Priemonę ORACLE CASE galima naudoti saugyklos (Repository) objektų eksportui/importui.

Developer/2000 užtikrina kilnojamų aplikacijų, veikiančių grafinėse Windows, Macintosh, Notif terpėse, ruošimą. Windows teprėje Developer/2000 aplikacijų integracija su kitomis priemonėmis realizuojama per OLE mechanizmą ir VBX valdančius elementus. Aplikacijų sąveika su kitomis DBVS (DB/2, DB2/400, Rdb) realizuojama ORACLE Client Adapter (ODBC), ORACLE Open Gateway ir API priemonių pagalba.

Funkcionavimo aplinka.

Windows 3.x, Windows 95, Windows NT.

Lokalinės priemonės (ERwin, BPwin, S-Designor, CASE.Аналитик)

ERwin – konceptualaus DB modeliavimo priemonė, naudojanti IDEF1X metodologiją. ERwin realizuoja DB schemos projektavimą, jos aprašymo DBVS (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress ir kkt.) kalbomis generavimą.

BPwin – funkcionalaus modeliavimo priemonė, realizuojanti IDEF0 metodologiją.

S-Designor – reliacinių DB projektavimo CASE – priemonė. S-Designor realizuoja standartinę duomenų modeliavimo metodologiją ir generuoja DB aprašymą tokioms DBVS kaip ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server ir kt.

CASE.Аналитик – funkcionalaus modeliavimo CASE – priemonė, realizuoja duomenų srautų diagramų rengimą sutinkamai su DFD metodologija.

Projekto DB realizuota Paradox formatu ir yra laisvai prieinama.

Objektiškai orientuotos CASE – priemonės (Rational Rose)

Rational Rose – tai CASE – priemonė skirta PĮ projektavimui bei analizės etapų automatizavimui, taip pat kodų generavimui.

Pagrindinis Rational Rose/C++ variantas leidžia rengti projektinę dokumentaciją diagramų ir specifikacijų pavidalu, taip pat generuoti programinius kodus su C++.

Be to, Rational Rose turi programų reinzinerijos priemonę, užtikrinančią programos komponentų panaudojimą naujuose projektuose.

Struktūra ir funkcijos.

Rational Rose susideda iš šešių pagrindinių struktūrinių komponentų: saugykla (Repository), vartotojo grafinis interfeisas, projekto peržiūros priemonės (Browser), projekto kontrolės priemonės, statistikos rinkimo priemonės ir dokumentų generatorius. Be to, yra kodo generatorius (kiekvienai kalbai individualus) ir C++ analizatorius, užtikrinantis reinžineriją – projekto modelio pagal programos pradinius tekstus atstatymą.

Rengiant projekta Rational Rose pagalba formuojami sekantys dokumentai:

1. klasių diagramos

2. būvio (būsenos) klasės

3. scenarijų diagramos

4. modulių diagramos

5. procesų diagramos

6. klasių, objektų, atributų, operacijų specifikacijos

7. programų tekstų ruošiniai

8. programinės sistemos modelis

Paskutinis iš išvardintų dokumentų yra tekstinis failas, kuriame yra visa reikalinga informacija apie projektą.

Programų tekstai

– tai tolesnio programuotojų darbo ruošiniai. Jie formuojami darbiniame kataloge failų su “h” išplėtimų pavidalu (headers su klasių aprašymu) ir failų su “cpp” išplėtimu pavidalu (programų ruošiniai metodams).

Toliau visi šie tekstai “išvystomi” programuotojų į pilnavertes programas.

Sąveika su kitomis priemonėmis ir grupinio darbo organizavimas.

Rational Rose integruojasi su PVCS priemone grupinio darbo bei projekto valdymo organizavimui, su SoDA – projektų dokumentavimui.

Rational Rose ir SoDA integracija vykdoma SoDA priemonėmis.

Grupinio darbo organizavimui Rational Rose gali būti vykdomas modelio skaidymas i valdomus pomodelius. Kiekvienas iš jjų nepriklausomai išsaugomas diske arba užkraunamas į modelį.

Funkcionavimo aplinka.

IBM PC (Windows)

Sun SPARC stations (UNIX, Solaris, SunOS)

Hewlett – Packard (HP UX)

IBM RS/6000 (AIX)

Reikalavimai:

Windows – procesorius > 80386SX, atmintis > 8Mb, diskas = 8Mb+(1-3Mb) vienam modeliui.

UNIX – atmintis = 32+(16 * vartotojų skaičius)Mb, diskas = 30Mb+20 diegiant+(1-3Mb) vienam modeliui.

CASE – priemonių kompleksų pavyzdžiai.

Pabaigai pateiksiu keletą CASE – priemonių kompleksų, užtikrinančių pilno PĮ GC palaikymą.

1. Vantage Team Builder for Uniface + Uniface.

2. Designer/2000 (pagrindinė), ERwin BPwin ir OOwin (alternatyvios).

3. Developer/2000, ORACLE Power Objects (pagrindinės) ir Usoft DDeveloper (alternatyvi).