REGULAČNÁ A METODICKÁ PODPORA VZNIKU AIS.
Základné koncepty návrhu AIS
Vo všeobecnosti AIS zahŕňa: používateľa (spotrebiteľa), informačné zdroje, nosiče informácií, prostriedky na zhromažďovanie, uchovávanie, spracovanie informácií a prostriedky na prenos informácií.
Dizajn AIS je založený na dvoch vzájomne súvisiacich komponentoch:
konštrukčné normy;
Metodika dizajnu.
Základné pojmy, prístupy a definície návrhu AIS sú regulované tromi typmi projektovej a softvérovej dokumentácie:
- jednotný systém projektovej dokumentácie (ESKD);
- jednotný systém programovej dokumentácie (USPD);
- súbor usmerňovacích dokumentov pre AIS.
Zloženie projektovej dokumentácie je súbor noriem a smerníc založených na AIS GOST 24.104-85, GOST 34.003-90, GOST 34.201-90, ktorý zahŕňa usmernenia pre informačné technológie a automatizované systémy, ako aj požiadavky na obsah dokumentov.
Cieľom návrhu je identifikovať relatívne jednoduchú vnútornú štruktúru, nazývanú architektúra systému.
AIS sa vyvíja ako projekt. Mnohé črty projektového manažmentu a fázy vývoja projektu (fázy životného cyklu) sú spoločné, nezávislé nielen od predmetnej oblasti, ale aj od charakteru projektu. Pojem projekt je komplexný pojem a je ťažké nájsť preň jednoznačnú formuláciu.
Projekt– ide o časovo obmedzenú, účelovú zmenu na samostatný systém s na začiatku jasne stanovenými cieľmi, ktorých dosiahnutie podmieňuje dokončenie projektu, ako aj so stanovenými požiadavkami na načasovanie, výsledky, riziko, rámec vynakladania finančných prostriedkov a zdrojov a pre organizačnú štruktúru.
Pre ekonomické systémov, pod projektom EIS rozumieme projektovú a inžiniersku dokumentáciu, ktorá poskytuje popis konštrukčných riešení pre tvorbu a prevádzku EIS v konkrétnom softvérovom a hardvérovom prostredí.
Pod dizajnom EIS rozumie procesu prevodu vstupných informácií o dizajnovom objekte, metódam navrhovania a skúsenostiam s navrhovaním objektov podobného účelu v súlade s GOST do projektu EIS. Z tohto hľadiska návrh EIS vychádza z dôslednej formalizácie návrhových riešení v rôznych fázach životného cyklu EIS: plánovanie a analýza požiadaviek, technický a detailný návrh, implementácia a prevádzka EIS.
Dizajnové predmety EIS sú jednotlivé prvky alebo ich komplexy funkčných a nosných častí. Funkčnými prvkami sú teda v súlade s tradičnou dekompozíciou úlohy, súbory úloh a riadiace funkcie. V rámci nosnej časti EIS sú návrhovými objektmi prvky a ich komplexy informačnej, softvérovej a hardvérovej podpory systému.
Ako predmet Návrh EIS zahŕňa tímy špecialistov, ktorí vykonávajú projekčnú činnosť, zvyčajne ako súčasť špecializovanej (projekčnej) organizácie, a zákaznícku organizáciu, pre ktorú je potrebné EIS vyvinúť. Rozsah vyvíjaných systémov určuje zloženie a počet účastníkov procesu navrhovania. Pri veľkom objeme a krátkych termínoch dokončenia projekčných prác sa na vývoji systému môže podieľať niekoľko projekčných tímov (vývojových organizácií). V tomto prípade sa identifikuje materská organizácia, ktorá koordinuje aktivity všetkých spoluvykonávajúcich organizácií.
Forma účasti spolurealizátorov na vývoji systémového projektu môže byť rôzna. Najbežnejšou formou je, že každý spolurealizátor vykonáva projekčné práce od začiatku do konca pre niektorú časť vyvíjaného systému. Typicky ide o funkčný subsystém alebo prepojený súbor úloh riadenia. Menej častá je forma účasti spoluvykonávateľov, pri ktorej jednotliví spoluvykonávatelia vykonávajú prácu v určitých fázach procesu návrhu. Je možná možnosť, v ktorej sú funkcie zákazníka a vývojára kombinované, to znamená, že EIS je navrhnutý interne.
Vykonanie návrhu EIS zahŕňa použitie dizajnérmi určitej konštrukčnej technológie zodpovedajúcej rozsahu a vlastnostiam vyvíjaného projektu.
Dizajnová technológia EIS- ide o súbor metodík a nástrojov na navrhovanie EIS, ako aj metód a prostriedkov na organizovanie návrhu (riadenie procesu tvorby a modernizácie projektu EIS)
Metodológia (koncept + metóda)
Organizácia nástrojov
dizajnový dizajn
Technológia návrhu je založená na technologickom procese, ktorý určuje akcie, ich postupnosť, zloženie účinkujúcich, prostriedky a zdroje potrebné na vykonanie týchto akcií.
Technologický proces navrhovania EIS ako celku je teda rozdelený na súbor sekvenčne-paralelných, prepojených a podriadených reťazcov akcií, z ktorých každý môže mať svoj vlastný predmet. Úkony, ktoré sa vykonávajú pri návrhu EIS, možno definovať ako nedeliteľné technologické operácie alebo ako podprocesy technologických operácií. Všetky činnosti môžu byť samotné návrhové úkony, ktoré tvoria alebo upravujú výsledky návrhu, a hodnotiace úkony, ktoré sa vyvíjajú podľa stanovených kritérií na hodnotenie výsledkov návrhu.
Technológia návrhu je teda špecifikovaná regulovanou postupnosťou technologických operácií vykonávaných v procese vytvárania projektu na základe konkrétnej metódy, v dôsledku čoho by bolo jasné nielen to, čo je potrebné urobiť pre vytvorenie projektu, ale aj AKO, KOMU a V AKOM POSTUPNOSTI to treba urobiť.
Predmet každej zvolenej technológie návrhu by mal byť odrazom vzájomne súvisiacich procesov návrhu vo všetkých fázach životného cyklu EIS.
Medzi hlavné požiadavky na zvolenú konštrukčnú technológiu patria:
Projekt vytvorený pomocou tejto technológie musí spĺňať požiadavky zákazníka;
Zvolená technológia by mala čo najviac odrážať všetky fázy životného cyklu projektu;
Zvolená technológia musí zabezpečiť minimálne náklady na prácu a náklady na návrh a podporu projektu;
Technológia by mala byť základom spojenia medzi dizajnom a údržbou projektu;
Technológia by mala pomôcť zvýšiť produktivitu dizajnérov;
Technológia musí zabezpečiť spoľahlivosť návrhu a prevádzky projektu;
Technológia by mala umožniť jednoduchú údržbu projektovej dokumentácie.
Základom technológie návrhu EIS je metodika, ktorá určuje podstatu, hlavné charakteristické technologické vlastnosti.
Metodológia dizajnu predpokladá prítomnosť určitého konceptu, princípov dizajnu, realizovaných súborom návrhových metód, ktoré zase musia byť podporované určitými návrhárskymi nástrojmi.
Organizácia dizajnu zahŕňa určenie metód interakcie medzi dizajnérmi medzi sebou a so zákazníkom v procese vytvárania projektu EIS, ktorý môže byť podporený aj súborom špecifických nástrojov.
Metódy návrhu EIS možno klasifikovať podľa stupňa využitia automatizačných nástrojov, štandardných konštrukčných riešení a adaptability na očakávané zmeny.
Áno, podľa stupňa automatizácie Metódy navrhovania sú rozdelené do metód:
ručný dizajn, v ktorom sa návrh komponentov EIS vykonáva bez použitia špeciálnych softvérových nástrojov a programovanie sa vykonáva v algoritmických jazykoch;
počítačový dizajn, ktorá generuje alebo konfiguruje (nastavuje) dizajnové riešenia založené na použití špeciálnych softvérových nástrojov.
Na základe stupňa použitia štandardných konštrukčných riešení sa rozlišujú tieto konštrukčné metódy:
originálny (individuálny) dizajn, keď sa dizajnové riešenia vyvíjajú „od začiatku“ v súlade s požiadavkami na EIS;
Štandardný dizajn, ktorý zahŕňa konfiguráciu EIS z hotových štandardných konštrukčných riešení (softvérových modulov).
Originálny (individuálny) návrh EIS sa vyznačuje tým, že všetky typy projekčných prác sú zamerané na vytváranie individuálnych projektov pre každý objekt, ktoré v maximálnej miere odrážajú všetky jeho vlastnosti.
Štandardný návrh je realizovaný na základe skúseností získaných pri vývoji jednotlivých projektov. Typické projekty ako zovšeobecnenie skúseností pre určité skupiny organizačných a ekonomických systémov alebo druhov prác v každom konkrétnom prípade sú spojené s mnohými špecifickými znakmi a líšia sa mierou pokrytia riadiacich funkcií, vykonávanej práce a vypracovanej projektovej dokumentácie.
Podľa stupňa prispôsobivosti konštrukčných riešení sa konštrukčné metódy delia na metódy:
Rekonštrukcia, kedy sa úprava konštrukčných riešení vykonáva spracovaním príslušných komponentov (preprogramovanie softvérových modulov);
Parametrizácia, kedy sa konštrukčné riešenia upravujú (regenerujú) v súlade so zmenenými parametrami;
Reštrukturalizácia modelu, kedy sa mení model problémovej oblasti, na základe čoho sa automaticky regenerujú dizajnové riešenia.
Kombinácia rôznych charakteristík klasifikácie metód navrhovania určuje povahu použitej technológie návrhu EIS, medzi ktorými vynikajú dve hlavné:
trieda: kanonické a priemyselné technológie (tabuľka 2.1). Technológia priemyselného dizajnu sa zase delí na dve podtriedy: automatizovaný (pomocou technológií CASE) a štandardný (parametrovo orientovaný alebo modelovo orientovaný) dizajn. Použitie technológií priemyselného dizajnu v niektorých prípadoch nevylučuje použitie kanonickej technológie.
Tabuľka 2.1 Charakteristika tried technológie návrhu
Špecifické typy návrhových technológií sú charakteristické používaním určitých vývojových nástrojov EIS, ktoré podporujú realizáciu jednotlivých návrhových prác, etáp a ich kombinácií. Preto vývojári EIS spravidla čelia úlohe vybrať si dizajnové nástroje, ktoré z hľadiska svojich vlastností najlepšie spĺňajú požiadavky konkrétneho podniku.
Dizajnové nástroje by mali byť:
Vo svojej triede, invariantný k objektu dizajnu;
Pokryť súhrnne všetky fázy životného cyklu EIS;
Technicky, softvér a informácie kompatibilné;
Ľahko sa učí a používa;
Ekonomicky realizovateľné.
Návrhárske nástroje EIS možno rozdeliť do dvoch tried: bez použitia počítača a s použitím počítača.
Dizajnové nástroje bez použitia počítača sa používajú vo všetkých fázach a fázach návrhu EIS. Spravidla ide o prostriedky organizačnej a metodickej podpory projektových operácií a predovšetkým o rôzne normy upravujúce proces projektovania systému. Patrí sem aj jednotný systém klasifikácie a kódovania informácií, jednotný dokumentačný systém, modely na popis a analýzu informačných tokov atď.
Dizajnové nástroje využívajúce počítač možno použiť ako v jednotlivých, tak aj vo všetkých fázach a fázach procesu návrhu EIS, a teda podporujú vývoj prvkov návrhu systému, častí návrhu systému a návrh systému ako celku. Celá sada návrhových nástrojov využívajúcich počítače je rozdelená do štyroch podtried.
Prvá podtrieda zahŕňa operačné nástroje, ktoré podporujú návrh operácií spracovania informácií. Táto podtrieda nástrojov zahŕňa algoritmické jazyky, knižnice štandardných podprogramov a tried objektov, makrogenerátory, generátory programov pre typické operácie spracovania dát atď., ako aj nástroje na rozšírenie funkcií operačných systémov (utilít). Do tejto triedy patria aj také jednoduché návrhárske nástroje ako nástroje na testovanie a ladenie programov, podpora procesu projektovej dokumentácie a pod. Zvláštnosťou najnovších programov je, že s ich pomocou sa zvyšuje produktivita dizajnérov, ale nie je vyvinuté úplné konštrukčné riešenie.
Nástroje tejto podtriedy teda podporujú jednotlivé operácie návrhu EIS a možno ich používať nezávisle od seba.
Druhá podtrieda zahŕňa nástroje, ktoré podporujú návrh jednotlivých komponentov projektu EIS. Táto podtrieda zahŕňa nástroje na všeobecné systémové účely:
Systémy správy databáz (DBMS);
Metodicky orientované balíky aplikačných programov (riešenie problémov diskrétneho programovania, matematická štatistika atď.)
Stolové procesory;
štatistické PPP;
Škrupiny expertných systémov;
grafický editor;
Textové editory;
Integrovaný softvér (interaktívne prostredie so vstavanými dialógovými možnosťami, ktoré vám umožňuje integrovať vyššie uvedené softvérové nástroje).
Uvedené návrhové nástroje sa vyznačujú využitím pre vývoj technologických subsystémov EIS: zadávanie informácií, organizácia ukladania a prístupu k údajom, výpočty, analýza a zobrazovanie údajov, rozhodovanie.
Tretia podtrieda zahŕňa prostriedky, ktoré podporujú návrh sekcií projektu EIS. Táto podtrieda zahŕňa nástroje funkčného dizajnu.
Funkčné nástroje sú zamerané na vývoj automatizovaných systémov, ktoré implementujú funkcie, súbory úloh a kontrolné úlohy. Rôznorodosť tematických oblastí vedie k vzniku rôznych nástrojov tejto podtriedy, zameraných na typ organizačného systému (priemyselná, nepriemyselná sféra), úroveň riadenia (napríklad podnik, dielňa, oddelenie, miesto, pracovisko), manažment funkcie (plánovanie, účtovníctvo atď.) .
Funkčné nástroje pre návrh systémov spracovania informácií zahŕňajú štandardné návrhové riešenia, funkčné balíky aplikačných programov a štandardné projekty.
Štvrtá podtrieda návrhových nástrojov EIS zahŕňa nástroje, ktoré podporujú vývoj projektu v etapách a etapách procesu návrhu. Táto trieda zahŕňa podtriedu nástrojov automatizácie návrhu EIS (CASE tools).
Moderné nástroje CASE sú zas klasifikované hlavne podľa dvoch kritérií:
1) podľa etáp zahrnutých v procese vývoja EIS;
2) podľa stupňa integrácie: samostatné lokálne nástroje (nástroje), súbor neintegrovaných nástrojov pokrývajúcich väčšinu fáz vývoja EIS (súprava nástrojov) a plne integrované nástroje prepojené spoločnou databázou návrhov – úložiskom (pracovným stolom).
Navrhovanie AIS je kreatívny proces. Každý projekt prechádza vo svojom vývoji určitými stavmi: od stavu, keď „projekt ešte neexistuje“ až po stav, keď „projekt už neexistuje“. Súbor etáp vývoja od vzniku myšlienky až po úplné dokončenie projektu sa zvyčajne delí na etapy (fázy, etapy). Určité rozdiely sú v určovaní počtu etáp (fáz) a ich obsahu, no napriek tomu je podstata obsahu životného cyklu vývoja AIS v rôznych prístupoch rovnaká.
Etapy vývoja CASE systémov
Za posledné desaťročie sa objavil nový smer v navrhovaní informačných systémov – počítačom podporovaný dizajn pomocou nástrojov CASE. Termín CASE (Computer Aided System/Software Engineering) pôvodne označoval len automatizáciu vývoja softvéru; teraz pokrýva celý proces vývoja komplexného AIS.
Spočiatku boli CASE technológie vyvinuté s cieľom prekonať nedostatky metodiky projektovania konštrukcií (ťažkosti s pochopením, vysoká pracovná náročnosť a náklady na používanie, ťažkosti pri vykonávaní zmien konštrukčných špecifikácií atď.) prostredníctvom automatizácie a integrácie podporných nástrojov.
CASE technológie neexistujú samy osebe a nie sú nezávislé. Automatizujú a optimalizujú používanie príslušnej metodiky a umožňujú zvýšiť efektivitu jej aplikácie.
Inými slovami, CASE technológie predstavujú súbor metodík pre analýzu, návrh, vývoj a údržbu komplexných softvérových systémov, podporovaný súborom vzájomne prepojených automatizačných nástrojov, ktoré umožňujú vizuálne modelovať predmetnú oblasť, analyzovať tento model vo všetkých fázach vývoja a údržby AIS a vyvíjať aplikácie v súlade s informačnými potrebami používateľov.
Moderné nástroje CASE pokrývajú širokú škálu podpory pre množstvo návrhových technológií AIS – od jednoduchých nástrojov na analýzu a dokumentáciu až po komplexné automatizačné nástroje pokrývajúce celý životný cyklus AIS. Najväčšia potreba využívania CASE systémov je v počiatočných fázach vývoja - vo fázach analýzy a špecifikácie požiadaviek na AIS. Chyby, ktoré sa tu dopustili, sú takmer fatálne, ich cena je výrazne vyššia ako cena chýb v neskorších fázach vývoja.
Hlavným cieľom nástrojov CASE je oddeliť počiatočné fázy (analýza a návrh) od následných a nezaťažovať vývojárov detailmi vývojového prostredia a prevádzky systému.
Väčšina moderných systémov CASE používa metodológie štrukturálne a/alebo objektovo orientovaná analýza A dizajn, na základe použitia vizuálnych tabuliek, grafov, tabuliek a diagramov.
Pri správnom využívaní nástrojov CASE sa dosahuje výrazný nárast produktivity práce dosahujúci (podľa odhadov zahraničných firiem, ktoré využívajú CASE technológie) od 100 do 600 % v závislosti od objemu, náročnosti práce a skúseností s CASE. Zároveň sa menia všetky fázy životného cyklu AIS, no najväčšie zmeny sa týkajú fáz analýzy a návrhu (tabuľky 2.5, 2.6).
Tabuľka 2.5. Odhady nákladov práce podľa fáz životného cyklu AIS
Tabuľka 2.6. Porovnanie použitia CASE a tradičného rozvoj
Použitie nástrojov CASE nielen automatizuje štrukturálnu metodiku a umožňuje využívať moderné metódy systémového a softvérového inžinierstva, ale poskytuje aj ďalšie výhody (obr. 2.22), najmä:
1. zlepšuje kvalitu vyvinutého softvéru prostredníctvom automatického generovania a riadenia;
2. umožňuje skrátiť čas na vytvorenie prototypu AIS, čo umožňuje posúdiť kvalitu a efektívnosť projektu v počiatočných fázach;
3. urýchľuje proces navrhovania a vývoja;
4. umožňuje opätovné použitie vyvinutých komponentov;
5. podporuje podporu AIS;
6. oslobodzuje vás od rutinnej práce na dokumentovaní projektu, keďže využíva vstavaný dokumentátor;
7. uľahčuje tímovú prácu na projekte.
Ryža. 2.22. Výhody vývoja AIS pomocou CASE technológií: A- koeficient zníženia nákladov na projekt; b - faktor zníženia času vývoja
Väčšina nástrojov CASE je založená na štyroch hlavných konceptoch: metodológia, metóda, zápis, nástroj [ 11,15, 16].
Metodológia definuje usmernenia pre hodnotenie a výber riešení pri návrhu a vývoji AIS, etapy prác, ich postupnosť, pravidlá pre rozdelenie a účel metód.
metódy - postupy na generovanie komponentov a ich popisy.
Notácie sú určené na opis všeobecnej štruktúry systému, dátových prvkov, fáz spracovania, môžu zahŕňať grafy, diagramy, tabuľky, vývojové diagramy, formálne a prirodzené jazyky.
Vybavenie- nástroje na podporu a posilnenie metód; podporuje používateľov pri interaktívnom vytváraní a úprave projektu, pomáha organizovať projekt vo forme hierarchie úrovní abstrakcie a kontroluje súlad komponentov.
Klasifikácia nástrojov CASE
Stále neexistuje stabilná klasifikácia nástrojov CASE, boli definované iba prístupy ku klasifikácii v závislosti od rôznych klasifikačných kritérií. Nižšie sú uvedené niektoré z nich.
Zamerajte sa na technologické etapy a procesy životného cyklu AIS:
1. nástroje analýzy a návrhu. Používa sa na vytvorenie špecifikácií a návrhu systému. Podporujú známe metodológie dizajnu;
2. nástroje na návrh databázy. Zabezpečiť modelovanie logických údajov, generovanie databázových štruktúr;
3. nástroje riadenia požiadaviek;
4. nástroje na správu konfigurácie softvéru. Podpora programovania, testovania, automatického generovania softvéru zo špecifikácií;
5. dokumentačné nástroje;
6. testovacie nástroje;
7. Nástroje projektového manažmentu. Podpora plánovania, kontroly, interakcie;
8. nástroje reverzného inžinierstva určené na prenos existujúceho systému do nového prostredia.
Podporované metodológie návrhu[ 11, 12, 15, 16]:
1. funkčne (štruktúrne orientovaný);
2. objektovo orientované;
3. komplexne orientované (súbor metodík návrhu).
Podporované grafické zápisy do grafov:
1. s pevným zápisom;
2. so samostatnými zápismi;
3. s najbežnejšími zápismi.
Stupeň integrácie:
1. pomocné programy (Nástroje), ktoré samostatne riešia autonómny problém;
2. vývojové balíky (Toolkit), ktoré sú súborom nástrojov, ktoré poskytujú pomoc pri jednej z tried softvérových úloh;
3. sady integrovaných nástrojov prepojených spoločnou návrhovou databázou - úložisko, automatizujúce celú alebo časť práce v rôznych fázach tvorby AIS (Workbench).
Vývoj kolektívneho projektu:
1. bez podpory kolektívneho rozvoja;
2. zameraná na vývoj projektu v reálnom čase;
3. zameraná na režim kombinovania podprojektov.
Typy nástrojov CASE:
1. analytické nástroje (veľké písmená); medzi špecialistami sa nazývajú počítačové plánovacie nástroje. Pomocou týchto nástrojov CASE sa vytvorí model, ktorý odráža všetky existujúce špecifiká. Je zameraná na pochopenie všeobecných a špecifických mechanizmov fungovania, dostupných schopností, zdrojov a cieľov projektu v súlade s účelom spoločnosti. Tieto nástroje vám umožňujú analyzovať rôzne scenáre a zhromažďovať informácie na prijímanie optimálnych rozhodnutí;
2. nástroje analýzy a návrhu (stredný prípad); sa považujú za nástroje na podporu fáz analýzy požiadaviek a návrhu špecifikácií a štruktúry AIS. Hlavným výsledkom použitia priemerného CASE nástroja je výrazné zjednodušenie návrhu systému, keďže návrh sa mení na iteratívny proces práce s požiadavkami na AIS. Navyše, priemerné CASE nástroje poskytujú rýchlu dokumentáciu požiadaviek;
3. nástroje na vývoj softvéru (nižšie); podpora systémov vývoja softvéru AIS. Obsahujú systémové slovníky a grafické nástroje, ktoré eliminujú potrebu vývoja fyzických špecifikácií – existujú systémové špecifikácie, ktoré sú priamo preložené do programových kódov vyvíjaného systému (až 80 % kódov je generovaných automaticky). Hlavnými výhodami nižších CASE nástrojov je výrazné skrátenie času vývoja, jednoduchšie úpravy a podpora práce s prototypmi.
Nástroje CASE sú tiež klasifikované podľa typu a architektúry výpočtovej techniky, a podľa typu operačného systému.
V súčasnosti je softvérový trh zastúpený širokou škálou softvéru, vrátane nástrojov CASE takmer ktorejkoľvek z uvedených tried.
Charakteristika nástrojov CASE
Silverrun. CASE nástroj Silverrun od americkej spoločnosti Computer Systems Advisers, Inc. (CSA) sa používa na analýzu a návrh business class AIS a je zameraný skôr na špirálový model životného cyklu. Je použiteľný na podporu akejkoľvek metodológie založenej na oddelenej konštrukcii funkčných a informačných modelov (diagramy toku údajov a diagramy vzťahov medzi subjektmi).
Prispôsobenie pre konkrétnu metodiku je zabezpečené výberom požadovaného grafického zápisu modelov a súboru pravidiel pre kontrolu špecifikácií návrhu. Systém má pripravené nastavenia pre najbežnejšie metodiky: DATARUN (hlavná metodika podporovaná Silverrunom), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Informačné inžinierstvo. Ku každému konceptu predstavenému v projekte je možné pridať vlastné deskriptory. Architektúra Silverrun vám umožňuje rozširovať vývojové prostredie podľa potreby.
Silverrun má modulárna štruktúra a pozostáva zo štyroch modulov, z ktorých každý je samostatným produktom a je možné ho zakúpiť a použiť samostatne.
1. Modul na vytváranie modelov podnikových procesov vo forme diagramov toku dát Business Process Modeler (BPM) umožňuje modelovať fungovanie automatizovanej organizácie alebo vytvoreného automatizovaného informačného systému. Schopnosť pracovať s vysoko komplexnými modelmi je zabezpečená funkciami automatického prečíslovania, práce s procesným stromom (vrátane vizuálneho ťahania vetiev), oddeľovania a pripájania častí modelu pre kolektívny vývoj. Diagramy môžu byť zobrazené v niekoľkých preddefinovaných notáciách, vrátane Yourdon/DeMarco a Gane/Sarson. Je tiež možné vytvárať vlastné notácie, napríklad pridať používateľom definované polia k počtu deskriptorov zobrazených na diagrame.
2. Modul koncepčného modelovania údajov Entity-Relationship eXpert (ERX) umožňuje konštrukciu dátových modelov entitných vzťahov, ktoré nie sú viazané na konkrétnu implementáciu. Vstavaný expertný systém vám umožňuje vytvoriť správny normalizovaný dátový model zodpovedaním zmysluplných otázok o vzťahu dát. Je zabezpečená automatická konštrukcia dátového modelu z popisov dátových štruktúr. Analýza funkčných závislostí atribútov umožňuje kontrolovať súlad modelu s požiadavkami tretej normálnej formy a zabezpečiť ich splnenie. Overený model sa odovzdá modulu Relational Data Modeler.
3. Modul relačného modelovania Relational Data Modeler (RDM) vám umožňuje vytvárať podrobné modely entít a vzťahov na implementáciu v relačnej databáze. Tento modul dokumentuje všetky konštrukcie spojené s budovaním databázy: indexy, spúšťače, uložené procedúry atď. Flexibilná, meniteľná notácia a rozšíriteľnosť úložiska vám umožňujú pracovať s akoukoľvek metodikou. Schopnosť vytvárať podschémy sa riadi prístupom ANSI SPARC k reprezentácii databázovej schémy. Uzly distribuovaného spracovania aj používateľské pohľady sú modelované v jazyku podobvodu. Tento modul poskytuje návrh a kompletnú dokumentáciu relačných databáz.
4. Správca úložiska pracovnej skupiny Workgroup Repository Manager (WRM) sa používa ako dátový slovník na ukladanie informácií spoločných pre všetky modely a tiež poskytuje integráciu modulov Silverrun do jedného dizajnového prostredia.
Výhodou nástroja Silverrun CASE je vysoká flexibilita a rôznorodosť vizuálnych prostriedkov na konštrukciu modelov a nevýhodou chýbajúca prísna vzájomná kontrola medzi komponentmi rôznych modelov (napríklad možnosť automatického šírenia zmien medzi DFD rôznych modelov). úrovne rozkladu). Treba však poznamenať, že táto nevýhoda môže byť významná len vtedy, ak sa použije vodopádový model životného cyklu.
Silverrun zahŕňa:
1. automatické generovanie databázových schém pre najbežnejšie DBMS: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;
2. prenos dát do nástrojov na vývoj aplikácií: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.
Je teda možné úplne definovať jadro databázy pomocou všetkých funkcií konkrétneho DBMS: spúšťače, uložené procedúry, obmedzenia referenčnej integrity. Pri vytváraní aplikácie sa údaje migrované z úložiska Silverrun použijú buď na automatické generovanie objektov rozhrania, alebo na ich rýchle manuálne vytvorenie.
Na výmenu údajov s inými nástrojmi na automatizáciu návrhu, na vytváranie špecializovaných postupov na analýzu a kontrolu špecifikácií návrhu a na zostavovanie špecializovaných správ v súlade s rôznymi štandardmi poskytuje systém Silverrun tri spôsoby výstupu informácií o návrhu do externých súborov.
1. Systém podávania správ. Výstupom zostáv sú textové súbory.
2. Systém exportu/importu. Špecifikuje sa nielen obsah exportného súboru, ale aj oddeľovače záznamov, oddeľovače polí v záznamoch a značky začiatku a konca textových polí. Takéto exportné súbory je možné vygenerovať a nahrať do úložiska. To umožňuje výmenu údajov s rôznymi systémami: inými nástrojmi CASE, DBMS, textovými editormi a tabuľkovými procesormi.
3. Uloženie úložiska do externých súborov s prístupom pomocou ovládačov ODBC. Pre prístup k dátam úložiska z najbežnejších DBMS je možné ukladať všetky informácie o projekte priamo vo formáte týchto DBMS.
Silverrun podporuje dve metódy skupinovej práce:
1) štandardná verzia pre jedného používateľa má mechanizmus na riadené delenie a spájanie modelov. Model je možné rozdeliť na časti a rozdeliť medzi viacerých vývojárov. Po detailnom vývoji sú diely znovu zmontované do jedného modelu;
2) sieťová verzia Silverrunu umožňuje paralelnú skupinovú prácu s modelmi uloženými v sieťovom úložisku založenom na Oracle, Sybase alebo Informix DBMS. Súčasne s rovnakým modelom môže pracovať viacero vývojárov, keďže k uzamykaniu objektov dochádza na úrovni jednotlivých prvkov modelu.
JAM. Nástroj na vývoj aplikácií JYACC's Application Manager (JAM) je produktom spoločnosti JYACC. Hlavnou funkciou je súlad s metodikou RAD, keďže JAM umožňuje rýchlo implementovať cyklus vývoja aplikácie, ktorý pozostáva z generovania ďalšej verzie prototypu aplikácie, berúc do úvahy požiadavky identifikované v predchádzajúcom kroku a prezentovať ho používateľovi.
JAM má modulárnu štruktúru a pozostáva z nasledujúcich komponentov:
1. jadrá systému;
2. JAM/DBi - špecializované moduly rozhrania k DBMS (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC atď.);
3. JAM/RW - modul generátora správ;
4. JAM/CASEi - špecializované moduly rozhrania k CASE nástrojom (JAM/CASE-TeamWork, JAM/CASE-Innovator, atď.);
5. JAM/TPi - špecializované moduly rozhrania pre manažérov transakcií (napríklad JAM/TPi-Server TUXEDO atď.);
6. Jterm - špecializovaný emulátor X-terminálu.
Jadro systému je kompletný produkt a možno ho nezávisle použiť na vývoj aplikácií. Všetky ostatné moduly sú doplnkové a nemožno ich používať samostatne.
Jadro systému zahŕňa tieto hlavné komponenty:
1. editor obrazovky. Editor obrazovky obsahuje vývojové prostredie obrazovky, úložisko vizuálnych objektov, vlastný JAM DBMS - JDB, manažér transakcií, debugger, editor štýlov;
2. editor menu;
3. súbor pomocných nástrojov;
4. prostriedky na výrobu priemyselnej verzie aplikácie.
Pri použití JAM je vývoj externého rozhrania aplikácie vizuálnym dizajnom a spočíva v vytváraní obrazovkových formulárov umiestnením štruktúr rozhrania na ne a definovaním polí obrazovky pre vstup/výstup informácií. Dizajn rozhrania v JAM sa vykonáva pomocou editor obrazovky. Aplikácie vyvinuté v JAM majú rozhranie s viacerými oknami. Vývoj obrazovky zahŕňa umiestnenie prvkov rozhrania na ňu, ich zoskupenie a nastavenie hodnôt ich vlastností.
Editor menu umožňuje vyvíjať a ladiť systémy menu. Bola implementovaná schopnosť vytvárať piktografické menu. Priradenie položiek ponuky k objektom aplikácie sa vykonáva v editore obrazovky.
Relačný DBMS JDB pre jedného používateľa je zabudovaný do jadra JAM. Hlavným účelom JDB je prototypovanie aplikácií v prípadoch, keď je práca so štandardným DBMS nemožná alebo nepraktická. JDB implementuje nevyhnutné minimálne schopnosti relačných DBMS, ktoré nezahŕňajú indexy, uložené procedúry, spúšťače a pohľady. Pomocou JDB môžete vytvoriť databázu identickú s cieľovou databázou (okrem funkcií chýbajúcich v JDB) a vyvinúť významnú časť aplikácie.
Debugger umožňuje komplexné ladenie vyvíjanej aplikácie. Všetky udalosti, ktoré sa vyskytnú počas vykonávania aplikácie, sú sledované.
Verejné služby JAMy zahŕňajú tri skupiny:
1) konvertory súborov obrazovky JAM na text. JAM ukladá obrazovky ako natívne binárne súbory;
2) konfigurácia vstupno/výstupných zariadení. JAM a aplikácie s ním vytvorené nefungujú priamo s I/O zariadeniami. Namiesto toho JAM pristupuje k logickým I/O zariadeniam (klávesnica, terminál, správa);
3) údržba knižníc obrazoviek.
Jedným z doplnkových modulov JAM je generátor správ. Rozloženie správy sa vykonáva v editore obrazovky JAM. Činnosť zostavy je popísaná pomocou špeciálneho jazyka. Generátor zostavy umožňuje definovať údaje zobrazené v zostave, zoskupenie výstupných informácií, formátovanie výstupu atď.
Z aplikácií vyvinutých pomocou JAM je možné urobiť spustiteľné moduly. Na to musia mať vývojári kompilátor jazyka C a linker.
JAM obsahuje vstavaný programovací jazyk JPL (JAM Procedural Language), pomocou ktorého možno v prípade potreby napísať moduly, ktoré implementujú konkrétne akcie. Tento jazyk sa vykladá. Je možné vymieňať si informácie medzi vizuálne vybudovaným aplikačným prostredím a takýmito modulmi. Okrem toho JAM implementuje možnosť pripojenia externých modulov napísaných v jazykoch kompatibilných s jazykom C z hľadiska volaní funkcií.
JAM je systém orientovaný na udalosti, pozostávajúce zo súboru udalostí - otváranie a zatváranie okien, stlačenie klávesu na klávesnici, spustenie systémového časovača, prijatie a odovzdanie kontroly nad každým prvkom obrazovky. Vývojár implementuje aplikačnú logiku definovaním obsluhy pre každú udalosť.
Ovládače udalostí JAM môže obsahovať vstavané funkcie JAM aj funkcie napísané vývojárom v C alebo JPL. Sada vstavaných funkcií obsahuje viac ako 200 funkcií na rôzne účely; sú dostupné pre volania z funkcií napísaných v JPL aj C.
Priemyselná verzia aplikácie, vyvinutý pomocou JAM, pozostáva z nasledujúcich komponentov:
1. spustiteľný modul interpreta aplikácií;
2. obrazovky, ktoré tvoria aplikáciu (dodávané ako samostatné súbory, ako súčasť knižníc obrazoviek alebo zabudované do tela tlmočníka);
3. externé moduly JPL (dodávané ako textové súbory alebo v predkompilovanej forme; predkompilované
4. externé moduly JPL - vo forme samostatných súborov a ako súčasť knižníc obrazoviek);
5. konfiguračné súbory aplikácie - konfiguračné súbory klávesnice a terminálu, súbor systémových správ, všeobecný konfiguračný súbor.
Priama interakcia s DBMS je realizovaná modulmi JAM/DBi (Database interface). Metódy implementácie interakcie v JAM sú rozdelené do dvoch tried: manuálne a automatické.
O manuálnym spôsobom Vývojár nezávisle píše dotazy v SQL, v ktorých môžu byť zdrojmi a cieľmi pre prijímanie výsledkov dotazov ako prvky rozhrania vizuálne navrhnutej externej úrovne, tak aj interné premenné neviditeľné pre koncového používateľa.
Automatický režim implementovaný manažérom transakcií JAM. Je to realizovateľné pre typické bežné typy databázových operácií, takzvané QBE (Query By Example - dotazy založené na vzorke), berúc do úvahy pomerne zložité vzťahy medzi databázovými tabuľkami a automatickú kontrolu atribútov vstupno-výstupných polí obrazovky v závislosti na type transakcie (čítanie, zápis a pod.), na ktorej sa vygenerovaná požiadavka zúčastňuje.
JAM vám umožňuje vytvárať aplikácie na prácu s viac ako 20 DBMS: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, DBMS kompatibilné s ODBC atď.
Charakteristickým rysom JAM je vysoká úroveň prenosnosti aplikácií medzi rôznymi platformami (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS atď.); pri prenose medzi prostrediami DOS-Windows-UNIX môže byť potrebné „prekresliť“ statické textové polia na obrazovkách ruským textom. Prenosnosť navyše uľahčuje skutočnosť, že v JAM sa aplikácie vyvíjajú skôr pre virtuálne I/O zariadenia ako pre fyzické. Preto pri migrácii aplikácie z platformy na platformu zvyčajne potrebujete iba mapovať fyzické I/O zariadenia na ich logické reprezentácie pre aplikáciu.
Používanie SQL ako prostriedku interakcie s DBMS tiež pomáha zabezpečiť prenosnosť medzi DBMS. Ak sa prenesie štruktúra databázy, aplikácie nemusia vyžadovať žiadne úpravy, s výnimkou inicializácie pracovnej relácie. Je to možné, ak aplikácia nepoužívala rozšírenia SQL špecifické pre DBMS.
Keď sa zvyšuje zaťaženie systému a využíva sa zložitosť riešených úloh (distribúcia a heterogenita použitých zdrojov, počet súčasne pripojených používateľov, zložitosť aplikačnej logiky). trojvrstvový model architektúry"klient - server" pomocou transakčných manažérov. Komponenty JAM/TPi-Client a JAM/TPi-Server uľahčujú prechod na trojvrstvový model. V tomto prípade hrá kľúčovú úlohu modul JAM/TPi-Server, keďže hlavný problém pri implementácii trojvrstvového modelu spočíva v implementácii aplikačnej logiky v službách manažéra transakcií.
Rozhranie JAM/CASE umožňuje výmenu informácií medzi úložiskom objektov JAM a úložiskom nástrojov CASE. Výmena je podobná tomu, ako sa štruktúra databázy importuje do úložiska JAM priamo z databázy. Rozdiel je v tom, že výmena medzi úložiskami je obojsmerná.
Okrem modulov JAM/CASEi existuje aj modul JAM/CASEi Developer's Kit, pomocou ktorého môžete samostatne vyvinúť rozhranie (t.j. špecializovaný modul JAM/CASEi) pre konkrétny CASE nástroj, ak existuje hotový modul JAM/CASEi preň neexistuje.
Existuje rozhranie, ktoré implementuje interakciu medzi nástrojom Silverrun CASE a JAM. Prenáša schému databázy a formuláre obrazovky aplikácie medzi nástrojom Silverrun-RDM CASE a JAM verzie 7.0; má dva prevádzkové režimy:
1) priamy režim (Silverrun-RDM->JAM) je určený na vytváranie objektov CASE slovníka a prvkov JAM úložiska na základe reprezentácie schém v Silverrun-RDM. Na základe reprezentácie dátových modelov rozhrania v Silverrun-RDM sa generujú obrazovky a prvky JAM úložiska. Most konvertuje tabuľky relačných schém RDM a vzťahy na sekvenciu objektov JAM príslušných typov. Metodológia vytvárania dátových modelov rozhrania v Silverrun-RDM zahŕňa použitie podobvodového mechanizmu na prototypovanie obrazoviek aplikácií. Na základe popisu každého z podokruhov RDM most generuje formulár obrazovky JAM;
2) reverzný režim (JAM->Silverrun-RDM) je určený na prenos modifikácií objektov CASE slovníka do relačného modelu Silverrun-RDM.
Režim reengineeringu umožňuje preniesť úpravy všetkých vlastností obrazovky JAM predtým importovaných z RDM do schémy Silvcrrun. Na kontrolu integrity databázy nie sú povolené zmeny schémy vo forme pridávania alebo odstraňovania tabuliek a polí tabuľky.
Jadro JAM má vstavané rozhranie pre nástroje na správu konfigurácie (PVCS na platforme Windows a SCCS na platforme UNIX). Knižnice obrazoviek a/alebo úložiská sa prenášajú pod kontrolu týchto systémov. Ak takéto systémy neexistujú, JAM nezávisle implementuje niektoré funkcie na podporu rozvoja tímu.
Na platforme MS-Windows má JAM vstavané rozhranie pre PVCS a akcie načítania/vrátenia sa vykonávajú priamo z prostredia JAM.
Vantage Team Builder (Westmount I-CASE). Vantage Team Builder je integrovaný softvérový produkt orientovaný na implementáciu s plnou podporou modelu životného cyklu vodopádu.
Vantage Team Builder poskytuje nasledujúce funkcie:
1. navrhovanie diagramov toku údajov, diagramov vzťahov medzi entitami, dátových štruktúr, blokových diagramov programov a sekvencií obrazovkových formulárov;
2. navrhovanie schém architektúry systému - SAD (návrh zloženia a komunikácie výpočtových nástrojov, distribúcia systémových úloh medzi výpočtovými nástrojmi, modelovanie vzťahov klient-server, analýza využitia transakčných manažérov a vlastností fungovania systémov v reálnom čase);
3. generovanie programového kódu v jazyku cieľovej DBMS s plnou podporou softvérového prostredia a generovanie SQL kódu pre tvorbu databázových tabuliek, indexov, integritných obmedzení a uložených procedúr;
4. programovanie v jazyku C so zabudovaným SQL;
5. riadenie verzie a konfigurácie projektu;
6. viacužívateľský prístup do projektového úložiska;
7. generovanie projektovej dokumentácie pomocou štandardných a individuálnych šablón;
8. export a import dát projektu vo formáte CDIF (CASE Data Interchange Format).
Vantage Team Builder sa dodáva v rôznych konfiguráciách v závislosti od použitých DBMS (ORACLE, Informix, Sybase alebo Ingres) alebo nástrojov na vývoj aplikácií (Uniface). Konfigurácia Vantage Team Builder pre Uniface sa líši od ostatných tým, že sa čiastočne zameriava na špirálový model životného cyklu vďaka schopnostiam rýchleho prototypovania. Na popis projektu AIS sa používa veľký súbor diagramov.
Pri konštrukcii všetkých typov diagramov je zabezpečená kontrola zhody modelov so syntaxou použitých metód, ako aj kontrola zhody prvkov rovnakého mena a ich typov pre rôzne typy diagramov.
Pri konštrukcii diagramov dátových tokov DFD je zabezpečená kontrola zhody diagramov rôznych úrovní rozkladu. DFD najvyššej úrovne sa overuje pomocou matice zoznamu udalostí ELM. Na riadenie rozkladu zložených dátových tokov sa používa niekoľko možností ich popisu: vo formulári diagramy štruktúry údajov DSD resp zápisy BNF (Backus - Naur forma).
Na zostavenie SAD sa používa rozšírená notácia DFD, ktorá umožňuje zaviesť koncepty procesorov, úloh a periférnych zariadení, čo poskytuje prehľadnosť návrhových rozhodnutí.
Pri budovaní dátového modelu vo forme ERD sa normalizuje a zavádza sa definícia fyzických názvov dátových prvkov a tabuliek, ktoré sa použijú v procese generovania fyzickej dátovej schémy konkrétneho DBMS. Poskytuje možnosť určiť alternatívne kľúče entít a polí, ktoré tvoria dodatočné vstupné body do tabuľky (polia indexov), a mohutnosť vzťahov medzi entitami.
Prítomnosť univerzálneho systému generovania kódu založeného na špecifikovaných prostriedkoch prístupu k úložisku projektu umožňuje vývojárom udržiavať vysokú úroveň vykonávania disciplíny dizajnu: prísne poradie generovania modelu; pevná štruktúra a obsah dokumentácie; automatické generovanie zdrojových kódov programu atď.; to všetko zabezpečuje zvýšenie kvality a spoľahlivosti vyvinutých integrovaných obvodov.
Na prípravu projektovej dokumentácie možno použiť publikačné systémy FrameMaker, Interleaf alebo Word Perfect. Štruktúra a skladba projektovej dokumentácie sú konfigurované v súlade so stanovenými normami. Prispôsobenie sa vykonáva bez zmeny konštrukčných riešení.
Pri vývoji veľkých AIS celý systém ako celok zodpovedá jednému projektu ako kategória Vantage Team Builder. Projekt je možné rozložiť na množstvo systémov, z ktorých každý zodpovedá nejakému relatívne autonómnemu subsystému AIS a je vyvíjaný nezávisle od ostatných. V budúcnosti je možné projektové systémy integrovať.
Proces návrhu AIS pomocou Vantage Team Builder je implementovaný vo forme štyroch po sebe nasledujúcich fáz (etap) - analýza, architektúra, dizajn A implementácia, v tomto prípade sa dokončené výsledky každej etapy úplne alebo čiastočne prenesú (importujú) do ďalšej fázy. Všetky diagramy, okrem ERD, sú prevedené na iný typ alebo menia svoj vzhľad v súlade s charakteristikami aktuálnej fázy. DFD sa teda konvertujú na SAD vo fáze architektúry, DSD na DTD. Po dokončení importu sa preruší logické spojenie s predchádzajúcou fázou, t.j. v diagramoch je možné vykonať všetky potrebné zmeny.
Konfigurácia Vantage Team Builder pre Uniface zabezpečuje zdieľanie dvoch systémov v rámci jedného technologického návrhového prostredia, pričom databázové schémy (modely SQL) sa prenášajú do úložiska Uniface a naopak, aplikačné modely generované nástrojmi Uniface je možné prenášať do Vantage. Úložisko Team Builder . Prípadné nezrovnalosti medzi úložiskami oboch systémov sú odstránené pomocou špeciálnej utility. Vývoj obrazovkových formulárov v prostredí Uniface prebieha na základe sekvenčných diagramov formulárov FSD po importe SQL modelu. Technológia vývoja AIS na základe tejto konfigurácie je znázornená na obr. 2.23.
Štruktúra úložiska uloženého v cieľovom DBMS a rozhrania Vantage Team Builder sú otvorené, čo v princípe umožňuje integráciu s akýmikoľvek inými nástrojmi.
Uniface. Produkt Compuware je vývojové prostredie pre rozsiahle aplikácie v architektúre klient-server a má nasledujúcu architektúru komponentov:
1. Repozitár aplikačných objektov (repozitár objektov aplikácie) obsahuje metadáta, ktoré automaticky používajú všetky ostatné komponenty počas životného cyklu AIS (modely aplikácií, popisy údajov, obchodné pravidlá, formuláre obrazovky, globálne objekty a šablóny). Úložisko môže byť uložené v ktorejkoľvek z databáz podporovaných Uniface;
Ryža. 2.23. Interakcia medzi Vantage Team Builder a Uniface
2. Application Model Manager podporuje aplikačné modely (E-R modely), z ktorých každý predstavuje podmnožinu všeobecnej databázovej schémy z pohľadu danej aplikácie a obsahuje zodpovedajúci grafický editor;
3. Rapid Application Builder – nástroj na rýchle vytváranie obrazovkových formulárov a zostáv na základe objektov modelu aplikácie. Zahŕňa grafický editor formulárov, nástroje na vytváranie prototypov, ladenie, testovanie a dokumentáciu. Pre existujúce grafické rozhrania - MS Windows (vrátane VBX), Motif, OS/2 bolo implementované rozhranie s rôznymi typmi ovládania okien Open Widget Interface. Rozhranie Universal Presentation Interface vám umožňuje používať rovnakú verziu aplikácie v rôznych grafických rozhraniach bez zmeny programového kódu;
4. Vývojárske služby sa používajú na podporu veľkých projektov a implementáciu správy verzií (Uniface Version Control System), prístupových práv (oddelenie právomocí), globálnych úprav atď. To poskytuje vývojárom nástroje na paralelný návrh, kontrolu vstupu a výstupu, vyhľadávanie, prezeranie, udržiavanie a vydávanie správ o údajoch systému riadenia verzií;
5. Deployment Manager (správa distribúcie aplikácií) - nástroje, ktoré umožňujú pripraviť vytvorenú aplikáciu na distribúciu, nainštalovať ju a udržiavať (v tomto prípade sa platforma používateľa môže líšiť od platformy vývojára). Zahŕňajú sieťové ovládače a ovládače DBMS, aplikačný server (polyserver), distribúciu aplikácií a nástroje na správu databáz. Uniface podporuje rozhranie s takmer všetkými známymi hardvérovými a softvérovými platformami, DBMS, CASE nástrojmi, sieťovými protokolmi a manažérmi transakcií;
6. Personal Series (osobné nástroje) sa používajú na vytváranie zložitých dotazov a zostáv v grafickej forme (Personal Query a Personal Access - PQ/PA), ako aj na prenos údajov do systémov ako WinWord a Excel;
7. Distributed Computing Manager - integračný nástroj s transakčnými manažérmi Tuxedo, Encina, CICS, OSF DCE.
Verzia Uniface 7 plne podporuje distribuovaný výpočtový model a trojvrstvovú architektúru klient-server (s možnosťou zmeny schémy dekompozície aplikácie za behu). Aplikácie vytvorené pomocou Uniface 7 je možné spúšťať v heterogénnych operačných prostrediach s použitím rôznych sieťových protokolov súčasne na niekoľkých heterogénnych platformách (vrátane internetu).
Komponenty Uniface 7 zahŕňajú:
1. Uniface Application Server - aplikačný server pre distribuované systémy;
2. WebEnabler - serverový softvér na prevádzku aplikácií na internete a intranete;
3. Name Server - serverový softvér, ktorý zabezpečuje využívanie distribuovaných aplikačných zdrojov;
4. PolyServer – nástroj na prístup k dátam a integráciu rôznych systémov.
Zoznam podporovaných DBMS zahŕňa DB2, VSAM a IMS; PolyServer tiež poskytuje interakciu s OS MVS.
Dizajnér/2000 + Vývojár/2000. Designer/2000 2.0 od ORACLE je integrovaný CASE nástroj, ktorý spolu s nástrojmi na vývoj aplikácií Developer/2000 poskytuje podporu pre celý životný cyklus softvéru pre systémy využívajúce ORACLE DBMS.
Designer/2000 je rodina metodológií a softvérových produktov, ktoré ich podporujú. Základná metodika Designer/2000 (CASE*Method) je štrukturálna metodika pre návrh systému, ktorá plne pokrýva všetky fázy životného cyklu AIS. Vo fáze plánovania sa stanovia ciele tvorby systému, priority a obmedzenia, vypracuje sa architektúra systému a plán rozvoja AIS. Počas procesu analýzy sa zostavujú: model informačných potrieb (diagram vzťahov entít), diagram funkčnej hierarchie (založený na funkčnom rozklade AIS), matica krížových odkazov a diagram toku údajov.
Vo fáze návrhu sa vypracuje detailná architektúra AIS, navrhne sa schéma relačnej databázy a softvérové moduly a vytvoria sa krížové referencie medzi komponentmi AIS na analýzu ich vzájomného vplyvu a zmien riadenia.
Vo fáze implementácie sa vytvorí databáza, vybudujú sa aplikačné systémy, testujú sa, kontroluje sa kvalita a súlad s požiadavkami používateľov. Vytvára sa systémová dokumentácia, školiace materiály a užívateľské príručky. V etapách prevádzky a údržby sa analyzuje výkonnosť a integrita systému, vykonáva sa podpora a v prípade potreby úprava AIS.
Designer/2000 poskytuje grafické rozhranie na vytváranie rôznych modelov (diagramov) predmetnej oblasti. Počas procesu vytvárania modelov sa informácie o nich vkladajú do úložiska. Designer/2000 obsahuje nasledujúce komponenty.
Dodržiavanie vyššie uvedených zásad je nevyhnutné pri vykonávaní prác vo všetkých etapách tvorby a prevádzky AIS a AIT, t.j. počas celého ich životného cyklu.
Životný cyklus(LC) - obdobie vytvárania a používania automatizovaných informačných systémov (AIT), počnúc okamihom vzniku potreby tohto automatizovaného systému a končiac okamihom jeho vyradenia z používania.
Životný cyklus AIS a AIT nám umožňuje rozlíšiť štyri hlavné etapy; každá etapa návrhu je rozdelená do niekoľkých etáp a zabezpečuje zodpovedajúcu prácu:
ja inscenujem - predprojektová kontrola:
1. etapa - tvorba požiadaviek, štúdia projektovaného objektu, vypracovanie a výber variantu koncepcie systému;
2. etapa - analýza materiálov a tvorba dokumentácie - vytvorenie a schválenie štúdie realizovateľnosti a technických špecifikácií pre návrh systému na základe analýzy prieskumných materiálov zozbieraných v prvej etape.
II etapa - dizajn:
1. etapa - technický dizajn, kde sa hľadajú najracionálnejšie konštrukčné riešenia vo všetkých aspektoch vývoja, vytvárajú a popisujú sa všetky komponenty systému a výsledky práce sa premietajú do technického návrhu;
2. etapa - detailný dizajn, pri ktorých sa vyvíjajú a dolaďujú programy, upravujú databázové štruktúry, vytvára sa dodávateľská dokumentácia, inštalujú sa technické zariadenia a návody na ich obsluhu a pre každého užívateľa sa pripravujú popisy práce. Technické a pracovné návrhy je možné spojiť do jedného dokumentu – technického pracovného návrhu.
III etapa - systémový vstup do akcie:
1. etapa - príprava na realizáciu- inštalácia a uvedenie do prevádzky technických zariadení, sťahovanie databáz a skúšobná prevádzka programov, školenia personálu;
2. etapa - vykonávanie pilotných testov všetky komponenty systému pred presunom do komerčnej prevádzky, školenie personálu;
Fáza 3 (záverečná fáza vytvárania AIS a AIT) - uvedenie do komerčnej prevádzky; sa formalizuje aktom prijatia a dodania diela.
IV štádium - priemyselná prevádzka - Okrem každodenného fungovania zahŕňa údržbu softvéru a celého projektu, prevádzkovú údržbu a správu databáz.
5. Metódy vykonávania projektových prác
Vytváranie automatizovaných informačných systémov a technológií je možné realizovať podľa dvoch možností. Prvá možnosť predpokladá, že túto prácu vykonávajú špecializované firmy s odbornými skúsenosťami s prípravou softvérových produktov špecifického zamerania. Podľa druhej možnosti návrh a vývoj vývoja vykonávajú dizajnéri a programátori, ktorí sú zamestnancami podnikov, kde sa vytvárajú nové informačné technológie a systémy.
V procese vývoja automatizovaných systémov, pracovísk a technológií čelia dizajnéri množstvu vzájomne súvisiacich problémov:
Pre projektanta je ťažké získať komplexné informácie na posúdenie požiadaviek formulovaných zákazníkom (používateľom) na nový systém alebo technológiu.
Zákazník často nemá dostatočné znalosti o problémoch automatizácie, aby mohol posúdiť možnosť implementácie určitých inovácií. Zároveň je projektant konfrontovaný s nadmerným množstvom detailných informácií o problémovej oblasti, čo spôsobuje ťažkosti pri modelovaní a formalizácii popisu informačných procesov a riešení funkčných problémov.
Špecifikácia navrhovaného systému je pre jeho veľký objem a technické podmienky často pre zákazníka nezrozumiteľná a jeho prílišné zjednodušenie nemôže uspokojiť špecialistov tvoriacich systém.
Pomocou známych analytických metód je možné vyriešiť niektoré z uvedených problémov, ale radikálne riešenie poskytujú iba moderné štruktúrne metódy, medzi ktorými má metodológia štruktúrnej analýzy ústredné miesto.
Štrukturálna analýza je metóda štúdia systému, ktorá začína všeobecným prehľadom o ňom a potom prechádza do detailov, pričom s narastajúcim počtom úrovní nadobúda hierarchickú štruktúru.
Štrukturálna analýza zahŕňa rozdelenie systému na úrovne abstrakcie s obmedzeným počtom prvkov na každej úrovni (zvyčajne od 3 do 6-7). Na každej úrovni sú zvýraznené iba detaily podstatné pre systém.
Metodika štrukturálnej analýzy je založená na princípoch dekompozície a princípe hierarchického usporiadania.
Princíp rozkladu zahŕňa riešenie zložitých problémov ich rozdelením na úlohy, ktoré sú ľahko pochopiteľné a riešiteľné.
Princíp hierarchického usporiadania vyhlasuje, že systém možno pochopiť a zabudovať do úrovní, z ktorých každá pridáva nové detaily.
Zapnuté predprojektová fáza vykonáva sa štúdia a analýza všetkých vlastností dizajnového objektu s cieľom objasniť požiadavky zákazníka. Identifikuje sa najmä súbor podmienok, za ktorých sa očakáva prevádzka budúceho systému (hardvérové a softvérové zdroje; vonkajšie podmienky jeho fungovania; zloženie ľudí a prác, ktoré s ním súvisia a podieľajú sa na informačných a riadiacich procesoch), a popis funkcií vykonávaných systémom atď. P.
V tejto fáze sa určujú:
Architektúra systému, jeho funkcie, vonkajšie podmienky, rozdelenie funkcií medzi hardvér a softvér;
Rozhrania a rozdelenie funkcií medzi osobou a systémom;
Požiadavky na softvérové a informačné komponenty systému, potrebné hardvérové prostriedky, požiadavky na databázu, fyzikálne vlastnosti komponentov systému, ich rozhrania.
Kvalita ďalšieho návrhu v rozhodujúcej miere závisí od správneho výberu metód analýzy a formulovaných požiadaviek na novovytvorenú technológiu.
Metódy používané vo fáze predprojektového prieskumu sa delia na:
- Metódy na štúdium a analýzu skutočného stavu objektu alebo technológie. Tieto metódy umožňujú identifikovať úzke miesta v skúmaných procesoch a zahŕňajú: ústny alebo písomný prieskum; písomný prieskum; pozorovanie, meranie a vyhodnocovanie; diskusia v skupine; analýza úloh; analýzy výrobných a riadiacich procesov.
Vo všeobecnosti metódy na štúdium a analýzu skutočného stavu manažérskych činností a existujúcej technológie na riešenie problémov majú za cieľ zhromaždiť potrebné materiály a vytvoriť základ pre návrh AIS a AIT.
- Metódy formovania daného stavu. Vychádzajú zo zdôvodnenia všetkých komponentov AIS na základe cieľov, požiadaviek a podmienok zákazníka. Medzi tieto metódy, ktoré sú pracovnými nástrojmi pre dizajnérov, patria tieto metódy: modelovanie procesu riadenia; konštrukčný dizajn; rozklad; analýza informačného procesu.
- Metóda modelovania procesu riadenia. V procese štúdia projektového objektu sa budujú ekonomicko-organizačné a informačno-logické modely. Odrážajú ekonomické a riadiace vzťahy, ako aj informačné toky s nimi spojené.
- Metóda konštrukčného návrhu umožňuje rozdeliť celý komplex úloh na pozorovateľné a analyzovateľné podkomplexy (moduly).
- Metóda rozkladu modulov zabezpečuje ďalšie členenie subkomplexov úloh na samostatné úlohy a ukazovatele.
- Analýza informačných procesov navrhnuté tak, aby identifikovali a reprezentovali vzťah medzi výsledkom, procesom spracovania a vstupom údajov. Používa sa aj na analýzu a vytváranie informačných väzieb medzi pracoviskami riadiacich pracovníkov, špecialistov, technického personálu a informačných technológií. Na tento účel sú popísané vstupné a výstupné informácie, ako aj algoritmus spracovania informácií vo vzťahu ku každému pracovisku.
- Metódy grafického znázornenia aktuálnych a množinových stavov zahŕňajú použitie vizuálnej reprezentácie procesov spracovania informácií. Medzi najznámejšie z nich patrí metóda vývojových diagramov, metódy šípkových diagramov, sieťové diagramy, tabuľky postupnosti operácií procesov.
Ak by v štádiu predprojektovania mali byť požiadavky na vytvorenie AIS a AIT formulované v technických špecifikáciách, potom by návrh mal zodpovedať otázku: „Ako bude systém spĺňať požiadavky, ktoré sú naň kladené?
Výsledkom fáz návrhu by mal byť návrh systému v rámci rozpočtu pridelených zdrojov.
Etapy návrhu zahŕňajú tieto hlavné práce:
Rozvoj cieľov a organizačných princípov AIS;
Vytvorenie verzie AIS a AIT;
Ladiace programy;
Skúšobná prevádzka;
Dodávka projektu AIS a AIT.
V procese organizácie dizajnu sa prijímajú rôzne rozhodnutia, ktoré ovplyvňujú dynamiku a kvalitu práce. Preto sa pre každú fázu projektovania určujú: očakávané výsledky a dokumenty; osobné funkcie manažéra; rozhodnutia manažéra; funkcie zákazníka a vývojára AIS a AIT.
Návrhová a výkonná dokumentácia obsahuje: návody na pracovné procesy, programy pre pracoviská, návody na prípravu podkladov, odporúčania na využitie informácií, metódy, rozhodovacie tabuľky a pod.
V moderných podmienkach sa AIS, AIT a automatizované pracoviská spravidla nevytvárajú od nuly. Potreba včasných, kvalitných, operatívnych informácií a ich vyhodnocovanie ako najdôležitejšieho zdroja v riadiacich procesoch, ako aj najnovšie výdobytky vedecko-technického pokroku si vyžadujú reštrukturalizáciu fungujúceho AIS a vytvorenie AIS a AIT na nový technický a technologický základ.
Dizajn AIS
Detailný vývoj návrh systému, obsahujúci kompletný súbor jeho organizačnej, projektovej, technologickej a prevádzkovej dokumentácie. V súlade s GOST 34.601-90. Návrh automatizovaných systémov zahŕňa implementáciu niekoľkých etáp, medzi ktoré patrí: tvorba požiadaviek na AS, vývoj koncepcie AS, vývoj technických špecifikácií, predbežný návrh, technický návrh a vypracovanie pracovnej dokumentácie. Etapy tvorby AS okrem návrhu zahŕňajú aj: uvedenie do prevádzky a údržbu AS. Každá etapa je rozdelená na etapy. Prílohy k tejto norme tiež definujú:
· Zoznam typov organizácií zúčastňujúcich sa na práci.
V závislosti od charakteru projektovaného objektu a jeho špecifických podmienok umožňuje GOST 34.601-90 vylúčenie jednotlivých etáp, ako aj ich kombináciu. Berúc do úvahy dlhodobú prax v Rusku pri vytváraní automatizovaných informačných systémov (" AIS”) zvyčajne sa vykonávajú tieto etapy návrhu: predprojektový prieskum, koncepčný návrh, predbežný návrh, technický návrh a podrobný návrh. Ďalšie štátne normy upravujúce rôzne aspekty dizajnu reproduktorov:
· GOST 34.602-89 Súbor noriem pre automatizované systémy. Referenčné podmienky pre vytvorenie automatizovaného systému. Zadané 01.01.90.
· Štandard 34.603-92 Informačné technológie. Typy AC testov.
· Štandardy 34. (971, 972,973, 974, 981) - 91 Informačné technológie. Prepojenie otvorených systémov.
· Štandardná 34,91. Informačné technológie. Lokálne siete atď.
Predprojektový prieskum- Zhromažďovanie a spracovanie informácií o organizácii a vlastnostiach fungovania objektu automatizácie, vrátane údajov o jeho interakcii s vonkajším prostredím a inými objektmi, ako aj o implementácii systémová analýza, vypracovanie štúdie uskutočniteľnosti automatizácie a vypracovanie všeobecných požiadaviek na vývoj automatizovaného systému. Obsah práce počas predprojektovej kontroly automatizačného zariadenia zodpovedá etape „Tvorba požiadaviek na automatizovaný systém“ GOST 34.601-90, etapám: „Kontrola objektu a zdôvodnenie potreby vytvorenia automatizovaného systému “, “Tvorba užívateľských požiadaviek na automatizovaný systém”, “Vytvorenie správy o vykonanej práci a aplikácie pre vývoj AS - taktické a technické špecifikácie.”
Koncepčný návrh- Zodpovedá etapám projektovania v súlade s GOST 34.601-90 - „Vypracovanie koncepcie JE“ (etapy: „Vývoj možností koncepcie JE a výber variantu koncepcie JE, ktorá vyhovuje užívateľovi“, „Vypracovanie správy o vykonaná práca“) a „Vypracovanie technických špecifikácií“. Druhy konečných dokumentov práce v tejto fáze sú predbežný projekt(používajú sa aj mená - “ Koncepčný návrh ”, “Pilotný projekt") alebo Program vytvorenie systému, ktorý obsahuje:
· Stručný popis počiatočného stavu objektu automatizácie a prostredia, v ktorom pracuje;
· Označenie hlavných cieľov a zoznam úloh automatizácie;
· Popis rozšírenej organizačnej a funkčnej štruktúry vybranej možnosti (alebo možností) na zostavenie vytváraného systému;
· Štúdie uskutočniteľnosti;
· Integrovaný popis a základné požiadavky na nástroje informačnej a jazykovej podpory;
· Všeobecné požiadavky na softvér a hardvér;
· zoznam a rozšírená charakteristika etáp tvorby systému, načasovanie ich implementácie, zloženie účinkujúcich a očakávané výsledky ich implementácie;
· Počiatočné posúdenie ukazovateľov nákladov na prácu;
· Technické špecifikácie systému ako celku a/alebo jeho hlavných komponentov (subsystémy, softvérové a hardvérové systémy a nástroje, jednotlivé úlohy atď.), schválené Zákazníkom.
Schematický dizajn- Vývoj predbežných konštrukčných riešení systému a jeho častí. Konečným dokumentom na vykonanie práce v tejto fáze návrhu je Predbežný návrh, ktorá obsahuje zásadné konštrukčné a obvodové riešenia vývojového objektu, ako aj údaje definujúce jeho účel a základné parametre (pri návrhu softvér systému, predbežný návrh musí obsahovať komplet špecifikácia sa vyvíja programy).
Technický dizajn - Fáza práce na návrhu systému reproduktorov, ktorá zahŕňa:
· Vývoj konštrukčných riešení systému a jeho častí;
· vypracovanie dokumentácie pre JE a jej časti;
· vypracovanie a vyhotovenie dokumentácie pre dodávku produktov na dostavbu JE a/alebo technické požiadavky (technické špecifikácie) na ich vypracovanie;
· Vývoj projektových úloh v priľahlých častiach projektu automatizačného zariadenia.
Posledným dokumentom tejto fázy návrhu je technický projekt, obsahujúci okrem uvedených materiálov, schém zapojenia a projektovej dokumentácie vývojového objektu a jeho komponentov aj zoznam vybraných hotových nástrojov softvér a hardvér(vrátane počítačov, operačný systém, aplikačné programy atď.) a tiež algoritmy riešenie problémov pri vývoji nových softvérových nástrojov a pod.
Detailný dizajn- Záverečná fáza dizajn, ktorý okrem vypracovania pracovnej dokumentácie pre systém a jeho časti vyžadované GOST 34.601-90 vo všeobecnosti zabezpečuje objasnenie a spresnenie výsledkov predchádzajúcich etáp, vytvorenie a testovanie prototypu a/alebo pilotného priemyselného modelu. automatizačného objektu, vývoj a testovanie softvérových produktov, technologickej a prevádzkovej dokumentácie. Výsledky sú prezentované v pracovné alebo projekt technickej práce. V modernej dizajnérskej praxi automatizované informačné systémy(Napríklad, ABIS, ASTI, ACS a pod.) ide o počiatočnú fázu ich implementácie v práci firmy, organizácie alebo služby, ktorá je objednávateľom projektu, prípadne rodičom v rade ďalších automatizovaných firiem, organizácií, služieb a pod.
Vývojový (dizajnový) cyklus) softvér - Súbor vývojových etáp softvér začať z systémová analýza a vývoj počiatočných požiadaviek pred jeho implementáciou.
Princípy návrhu AIS- Súbor pravidiel alebo požiadaviek stanovených na základe mnohoročných rôznorodých skúseností s tvorbou a prevádzkou AIS. Najbežnejšie sú:
· Identita- vývoj nového, zdokonaľovanie existujúceho alebo zavedenie externe získaného AIS sú vedecko-technické problémy obsahovo podobné, líšia sa od seba len obsahom viacerých etáp a časovými parametrami;
· Vyrobiteľnosť: automatizovaná technológia znamená vývoj novej technológie alebo modernizáciu existujúcej v podmienkach AIS a neumožňuje jednoduché použitie vyvinutého softvéru a hardvéru v podmienkach starých tradičných technológií;
· Kontinuita, fázovanie a kontinuita vývoja a vývoja: AIS sú systémy, ktoré sa neustále vyvíjajú na ich základe; každá inovácia slúži ako rozvoj základných systémových princípov a už dosiahnutej kvality;
· prispôsobivosť: Komponenty AIS by mali mať vlastnosti, ktoré zabezpečia rýchle prispôsobenie týchto komponentov zmenám vonkajšieho prostredia a novým nástrojom;
· Modulárny princíp konštrukcie softvéru a hardvéru: predpokladá, že zloženie týchto nástrojov pozostáva z blokov („modulov“), ktoré poskytujú možnosť ich nahradenia alebo zmeny s cieľom zlepšiť fungovanie AIS alebo jeho prispôsobenie novým podmienkam;
· Technologické (vrátane - siete) integrácia: znamená jednotu pre celý systém technológie na vytváranie, aktualizáciu, uchovávanie a využívanie informačných zdrojov a najmä jednorazové spracovanie dokumentov a údajov, ako aj ich viacúčelové a viacúčelové využitie;
· Úplná normalizácia procesov a ich sledovanie: viacúčelové využitie informácií AIS si vyžaduje vysokú spoľahlivosť údajov v systéme. K tomu je potrebné v rôznych fázach spracovania a zadávania informačných dokumentov využívať rôzne formy informačnej kontroly, na ktoré sa môžu formovať požiadavky zo skladby riešených úloh a spracovávaných údajov. neustále monitorovanie je potrebné aj na získanie kvalitatívnych a kvantitatívnych charakteristík fungovania AIS na základe vstavaných a špeciálne vyvinutých nástrojov intelektuálnej štatistiky;
· nariadenia: AIS sú zamerané na fungovanie v priemyselnom režime, poskytujúce hromadné streamingové spracovanie informačných dokumentov; toto spracovanie je regulované normami, traťovými a prevádzkovými technológiami, normami pre zdrojové a časové ukazovatele a rozvinutou dispečerskou službou.
· Ekonomická výhodnosť: tvorba AIS by mala zahŕňať výber takých konštrukčných riešení (vrátane softvérových, technických, organizačných a technologických), ktoré za predpokladu dosiahnutia cieľov a zámerov zabezpečia minimalizáciu nákladov na finančné, materiálne a pracovné zdroje.
· Typizácia konštrukčných riešení: rozvoj a rozvoj AIS a ich sietí sa uskutočňuje so zameraním na medziknižničnú spoluprácu a kooperáciu, ako aj v súlade s pravidlami a protokolmi medzinárodnej výmeny informácií;
· Maximálne využitie hotových riešení: na zníženie nákladov a času na vývoj a implementáciu AIS, ako aj na zníženie konštrukčných chýb ako systému ako celku, tak aj jeho jednotlivých komponentov, sa odporúča v maximálnej možnej miere využívať hotové riešenia a nástroje. V tomto pláne je pri vytváraní nového systému značné množstvo práce spojené s analýzou alternatívnych možností možných riešení, výberom toho najvhodnejšieho pre objekt automatizácie a jeho prispôsobením novým podmienkam používania;
· Firemný duch: pri navrhovaní automatizovaného systému, ktorý je súčasťou systému vyššej úrovne (mestá, rezorty, republiky atď.), by sa mala zabezpečiť jeho hardvérová, softvérová, jazyková a informačná kompatibilita s ostatnými účastníkmi systému a/alebo siete AIS. Firemné požiadavky môžu byť v rozpore s požiadavkami alebo rozhodnutiami diktovanými inými princípmi, napríklad kontinuitou konštrukčných riešení;
· Orientácia na prvé osoby objektu automatizácie: úspešná realizácia prác na vytvorení AIS, ich rozvoj a prevádzka je možná len vtedy, ak sú bezvýhradne podporované prvou osobou objektu automatizácie (napríklad riaditeľ knižnice alebo informačného orgánu) a priama zodpovednosť za ich implementáciu je príkazom organizácie pridelený vedúcemu na úrovni najmenej zástupcu riaditeľa
