Çfarë është CASE-TOOLS
Inxhinieri) janë mjete
Automatizimi i dizajnit të IC.
MJETET CASE janë teknika të inxhinierisë softuerike për
dizajni software, e cila
bëjnë të mundur ofrimin cilesi e larte programe,
pa gabime dhe mirëmbajtje të lehtë
produkte softuerike.
RAST kuptohet edhe si një grup fondesh
projektimi i sistemeve të informacionit me
duke përdorur mjetet CASE.

Rasti do të thotë

Mjetet e rastit përfshijnë çdo softuer që
automatizon faza të ndryshme cikli i jetes
Softueri ka karakteristikat e mëposhtme:
1. Ekziston një mjet i fuqishëm grafik për
IS përshkrim që ofron komoditet në punë
përdorues,
2. Ka integrim komponente individuale
Rasti do të thotë
3. Përdoret ruajtja e centralizuar
Depoja e të dhënave të projektimit.

Funksionet e projektimit që më së shpeshti automatizohen brenda mjeteve CASE:

-
analiza dhe formulimi i kërkesave të IP;
databaza dhe dizajni i aplikacionit;
brezi kodi i programit;
duke testuar;
sigurimi i cilësisë së softuerit;
Menaxhimi i konfigurimit të IS;
menaxhimi i projektit etj.

Rezultati i përdorimit të mjeteve CASE:

optimizimi i strukturës së IS;
kostot e reduktuara të zhvillimit;
përmirësimi i efikasitetit të IS;
duke reduktuar gjasat e gabimeve kur
IS dizajn.

Arkitektura e një mjeti tipik Case

depo

Thelbi i çdo sistemi inxhinierik softuerësh është depoja.
Depoja është një bazë të dhënash e specializuar,
i cili përdoret për të shfaqur gjendjen e sistemit në çdo kohë
koha dhe përmban informacione për të gjitha objektet e projektit IS:
Emrat e projektuesve dhe të drejtat e tyre të aksesit,
strukturat e organizuara,
Komponentët e grafikut dhe grafiku në përgjithësi,
strukturat e të dhënave,
Marrëdhëniet ndërmjet diagrameve,
Modulet e programit, procedurat dhe bibliotekat e moduleve.

Klasifikimi i fondeve të rasteve moderne:

1. Klasifikimi i fondeve të rastit sipas
metodologjitë e mbështetura:
-
funksionale ose të orientuara nga struktura;
-
i orientuar nga objekti;
-
i orientuar nga kompleksi.

2. Klasifikimi i fondeve të rasteve moderne sipas llojeve:

Pasqyron orientimin funksional të fondeve për
proceset cikli i jetes zhvillimin e softuerit
siguria:
mjetet e analizës - të dizajnuara për të ndërtuar dhe
analiza e modelit të domenit;
mjetet e projektimit të bazës së të dhënave;
mjetet e zhvillimit të aplikacioneve;
Mjetet e riinxhinierimit të procesit;
mjetet e planifikimit dhe menaxhimit të projektit;
mjete testimi;
mjetet e dokumentimit.

Shembuj të veglave të rastit të llojeve të ndryshme:

Mjetet e analizës (Design, BpWin);
Mjetet e analizës dhe projektimit (Designer - Oracle);
Mjetet e projektimit të bazës së të dhënave (ErWin, Designer - Oracle);
Mjetet e zhvillimit të aplikacionit (Zhvilluesi - Oracle,
Delphi);
Mjetet e riinxhinierimit (ErWin, Rational Rose).

3. Klasifikimi i fondeve të rasteve moderne sipas kategorive:

Përcakton funksionet e kryera nga mjetet dhe përfshin:
individual fondet vendore, zgjidhjen e vogël autonome
detyra, një grup mjetesh pjesërisht të integruara që mbulojnë
shumica e fazave të ciklit jetësor dhe plotësisht të integruara
mjete që mbulojnë të gjithë ciklin jetësor të informacionit
sisteme dhe të lidhura nga një depo e përbashkët.
Mjetet tipike CASE janë:
mjetet e menaxhimit të konfigurimit;
mjete për modelimin e të dhënave;
mjetet e analizës dhe projektimit;
mjetet e konvertimit të modeleve;
mjetet e redaktimit të kodit;
gjeneratorë kodesh;
mjetet për ndërtimin e diagrameve UML.

Llojet e tjera të klasifikimit të rasteve:

4.
Klasifikimi i Mjeteve të Rastit sipas mbështetjes
shënime grafike;
5.
Klasifikimi i Rastit-do të thotë sipas shkallës
integrimi i mjeteve individuale;
6.
Klasifikimi i mjeteve të rastit sipas llojit dhe arkitekturës
teknologjia kompjuterike e përdorur;
7.
Klasifikimi i Rastit-mjetet sipas llojit të kolektivit
zhvillimet;
8.
Klasifikimi i veglave të kasës sipas llojit të përdorur
mjedis operativ.

Kur zgjidhni fondet e rastit, merrni parasysh aspektet e mëposhtme:

Disponueshmëria e një baze të dhënash, arkivi ose fjalori;
Disponueshmëria e ndërfaqeve me sisteme të tjera Case;
Aftësia për të eksportuar dhe importuar informacione;
Arkitektura e hapur;
Disponueshmëria e metodologjive të nevojshme;
Disponueshmëria e mjeteve grafike të mbështetjes së projektit;
Mundësia e gjenerimit automatik të kodit të programeve;
Aftësia për të planifikuar dhe menaxhuar një projekt.

Mjeti i rastit UML Gjuha universale e modelimit

Krijimi i gjuhës UML ndoqi qëllimet e mëposhtme:
ofrojnë zhvilluesve një gjuhë të vetme vizuale
modelim;
të sigurojë mekanizma për zgjerimin dhe specializimin e gjuhës;
të sigurojë pavarësinë e gjuhës nga gjuhët e programimit dhe
proceset e zhvillimit.

Marrëdhënia e Diagrameve UML

Diagrami i opsioneve
përdorni
Diagramë
sekuencat
Diagramë
klasat
Diagramë
bashkëpunimi
Diagramë
komponentët
Diagramë
shteteve
Diagramë
vendosjen
Diagramë
aktivitetet

IBM Rational Rose Case Tool

Rational Rose është një mjet analize moderne dhe e fuqishme,
modelimi dhe zhvillimi i sistemeve softuerike,
duke mbuluar të gjithë ciklin jetësor të softuerit
nga analiza e procesit të biznesit deri te gjenerimi i kodit
gjuhë programimi të dhënë.
Një arsenal i tillë lejon jo vetëm të hartojë një të re
sistemi i informacionit, por edhe për të modifikuar atë të vjetër,
përmes procesit të inxhinierisë së kundërt.

Karakteristikat kryesore të paketës Rational Rose:

inxhinieri e përparme dhe e kundërt në gjuhët: ADA,
Java, C, C++, Basic;
mbështetje për teknologjitë COM, DDL, XML;
aftësia për të gjeneruar skema të bazës së të dhënave Oracle dhe SQL.

Versionet e produktit Rational Rose:

Edicioni Rational Rose Modeler ju lejon të analizoni proceset e biznesit dhe
dizenjoni sistemin. Por nuk mbështet gjenerimin e kodit.
Rational Rose Botim Professional Në varësi të gjuhës së programimit të zgjedhur
ju lejon të kryeni inxhinieri përpara dhe të kundërt. Porosit vetëm në
konfigurim specifik (për shembull, Rose Professional C++ ose Rose Professional C++
Modeluesi i të dhënave). Nuk gjeneron kod 100% të ekzekutueshëm. Si rezultat, zhvilluesi merr
kodi kornizë i një sistemi informacioni në një gjuhë specifike (të renditur).
programimi, i cili më vonë duhet të zhvillohet më tej.
Edicioni Rational Rose RealTime është krijuar posaçërisht për të qenë 100% i ekzekutueshëm.
kodi në kohë reale, ju lejon të kryeni përpara dhe mbrapa
dizajnimi në C ose C++. Në dalje, modeli përpilohet automatikisht
dhe kompilohet në një skedar të ekzekutueshëm.
Versioni Rational Rose Enterprise Ky version i produktit mbulon gamën e plotë të detyrave për
dizajni, analiza dhe gjenerimi i kodit. Të gjitha funksionet e të tjerëve mbështeten
botime, me përjashtim të mundësisë së gjenerimit 100% të kodit.
Versioni Rational Rose DataModeler është një variant produkti i dizajnit të bazës së të dhënave.
Karakteristikat e DataModeler përfshihen me Rose Enterprise ose Professional.
Në paketën MS studio vizuale Visual Modeler i ndërtuar 6.0 - një version i cunguar i Rational Rose 98.

Informacion shtesë për paketën Rational Rose:

Versioni falas i produktit Rational Rose nuk është
ekzistojnë;
për institucionet arsimore të gjitha softuerët
Softueri IBM ofrohet pa pagesë;
përdorim falas në qëllime arsimore ndoshta
si pjesë e Iniciativës Akademike IBM.

Modelet hierarkike CASE korrespondojnë shumë më mirë me dimensionin e madh të problemit. Akronimi CASE (Computer-Aided Software/System Engineering) qëndron për projektimin e softuerit ose sistemeve të bazuara në mbështetjen e kompjuterit.

CASE-teknologjia është një fushë aktuale dhe në zhvillim intensiv e krijimit të CAD në fushën e produkteve softuerike dhe sistemeve të përpunimit të informacionit. Pothuajse asnjë produkt i huaj i madh softueri nuk krijohet aktualisht pa përdorimin e mjeteve CASE.

Ndër sistemet e brendshme të krijuara duke përdorur mjetet CASE, duhet theksuar sistemi BOSS-CORPORATION i IT Co. Në të gjitha fazat e krijimit të këtij sistemi, janë përdorur mjete zhvillimi që i përkasin familjes Oracle 2000 (Designer/2000, Developer/200, Programmer/2000).

Fushëveprimi i teknologjive CASE i referohet krijimit, para së gjithash, të sistemeve të informacionit ekonomik, gjë që shpjegohet me natyrën masive të këtyre sistemeve.

Duhet të theksohet se teknologjitë CASE përdoren jo vetëm për të krijuar sisteme të automatizuara të kontrollit, por edhe për të zhvilluar modele sistemesh që ndihmojnë në marrjen e vendimeve në fushën e planifikimit strategjik, menaxhimit financiar të kompanisë, trajnimit të personelit, etj. Kjo fushë e aplikimit të teknologjive CASE ka marrë emrin e vet - analiza e biznesit.

Teknologjitë CASE përdoren gjithashtu kur problemet e fushës lëndore janë shumë komplekse, për shembull, në zhvillimin e softuerit të sistemit.

Konsideroni bazat metodologjike të teknologjive CASE.

Baza e metodologjisë CASE është modelimi. Teknologjia CASE është një metodë model për automatizimin e dizajnit të sistemit.

Teknologjia CASE bazohet në paradigmën: metodologji - metodë - shënim - mjete

Metodologjia përcakton qasjet e përgjithshme për vlerësimin dhe përzgjedhjen e një opsioni të sistemit, sekuencën e fazave dhe fazave të projektimit, qasjet ndaj zgjedhjes së metodave.

Metoda specifikon rendin e projektimit të komponentëve individualë të sistemit (për shembull, metodat për projektimin e rrjedhave të të dhënave në sistem, vendosjen e specifikimeve (përshkrimeve) të proceseve, përfaqësimin e strukturave të të dhënave në ruajtje, etj. janë të njohura).

Shënimet janë mjete grafike të shënimit dhe rregulla të dizajnuara për të përshkruar strukturën e një sistemi, hapat e përpunimit të informacionit, strukturat e të dhënave, etj. Shënimet përfshijnë grafikët, diagramet, tabelat, diagramet e rrjedhës, gjuhët formale dhe natyrore.

Së fundi, mjetet janë mjete, mjete automatizimi të projektimit në formën e produkteve softuerike për sigurimin e një modaliteti ndërveprues të projektimit (krijimi dhe redaktimi i një projekti grafik të një sistemi informacioni) dhe gjenerimi i kodit të programit (krijimi automatik i kodeve të programit të sistemit).

Metodologjia e projektimit e bazuar në mbështetjen kompjuterike kërkon padyshim ndërtimin e një përshkrimi të formalizuar të sistemit të informacionit në formën e një modeli informacioni. Ndërtimi i një modeli CASE të sistemit parashikon zbërthimin e sistemit dhe renditjen hierarkike të nënsistemeve të zbërthyera.

Modeli i sistemit duhet të pasqyrojë:

Pjesa funksionale e sistemit;

Marrëdhëniet ndërmjet të dhënave;

Tranzicioni i gjendjes së sistemit gjatë funksionimit në kohë reale. Për të modeluar një sistem informacioni në këto tre aspekte, përdoren tre lloje mjetesh grafike me shënime të caktuara.

1. Diagramet e rrjedhës së të dhënave - DFD (Data Flow Diagrams). Ato përdoren në lidhje me fjalorët e të dhënave dhe specifikimet e procesit.

2. Diagramet entity-relation - ERD (Entity Relationship Diagrams), që tregojnë marrëdhëniet ndërmjet të dhënave.

3. Diagramet e tranzicionit të gjendjes - STD (State Transitign Diagrams) për të pasqyruar sjelljen e sistemit të varur nga koha (në kohë reale).

Roli kryesor në modelim i takon DFD.

DFD është krijuar për të pasqyruar marrëdhëniet e burimeve të të dhënave dhe marrësve (të ashtuquajturat entitete të jashtme në lidhje me sistemin e informacionit), rrjedhat e të dhënave, proceset e përpunimit (proceset llogaritëse që korrespondojnë me funksionet e sistemit), ruajtjen e të dhënave (magazinat).

Paraqitja grafike e diagramit të rrjedhës së të dhënave në ekranin e ekranit ofron qartësi të modelimit dhe lehtësinë e rregullimit të komponentëve kryesorë të modelit në mënyrë interaktive.

Meqenëse paraqitja grafike nuk është e mjaftueshme për të identifikuar me saktësi komponentët e një DFD, përdoren përshkrime tekstuale dhe mjete të tjera për të specifikuar proceset e përpunimit dhe strukturat e të dhënave.

Kështu, rrjedhat e të dhënave specifikohen për nga struktura e tyre në fjalorë të të dhënave. Çdo proces (funksion i sistemit) mund të shpohet duke përdorur një DFD të nivelit të ulët, ku ndahet në disa procese ndërsa rrjedhat e të dhënave shpohen në të njëjtën kohë.

Detajimi i procesit përfundon kur përshkrimi i secilit proces të detajuar mund të bëhet duke përdorur metodën e zgjedhur të shkrimit të algoritmit të procesit. Specifikimi i procesit përmban numrin dhe emrin e procesit, listat e emrave të të dhënave hyrëse dhe dalëse nga fjalori i të dhënave dhe një algoritëm procesi që transformon rrjedhat e të dhënave hyrëse në ato hyrëse. Teknologjia CASE përdor metoda të tilla për vendosjen e algoritmeve të procesit si:

Përshkrimi i tekstit;

Gjuhë e strukturuar natyrore;

Tabelat e vendimeve;

Pemët e Vendimit;

gjuhë vizuale;

Gjuhët e programimit.

Gjuhët e programimit (C, Cobol, etj.) shkaktojnë vështirësi në shkrimin e algoritmeve për DFD, pasi ato kërkojnë përdorimin e fjalorëve të të dhënave përveç rrjedhave të të dhënave dhe kërkojnë rregullim sinkron të specifikimeve të procesit gjatë rregullimit të DFD.

Gjuha e strukturuar natyrore kuptohet lehtësisht jo vetëm nga projektuesit dhe programuesit, por edhe nga përdoruesit përfundimtarë. Kjo është meritë e tij. Megjithatë, ai nuk ofron gjenerim automatik të kodit për shkak të paqartësive.

Tabelat dhe pemët e vendimeve, ndërkohë që pasqyrojnë vizualisht lidhjen e një kombinimi kushtesh me veprimet e nevojshme, nuk kanë aftësi procedurale për gjenerimin e kodeve të programeve.

Gjuhët vizuale ofrojnë gjenerim automatik të kodit, por specifikimet e procesit të paraqitura me ndihmën e tyre janë të vështira për t'u përshtatur.

Përmbajtja e çdo ruajtjeje të dhënash të përfaqësuar në diagramin e rrjedhës së të dhënave përshkruhet nga një fjalor i të dhënave dhe një model i të dhënave ERD. Në rastin e funksionimit të sistemit në kohë reale, DFD plotësohet nga STD.

Struktura hierarkike e modelit CASE është paraqitur në fig. 11.9.

Një parim i rëndësishëm metodologjik i teknologjisë CASE për krijimin e një sistemi informacioni është një ndarje e qartë e procesit të krijimit të një sistemi në 4 faza:

Para-projekt (faza e analizës, prototipizimi dhe ndërtimi i një modeli të kërkesave për sistemin);

Dizajn, që përfshin dizajnin logjik të sistemit (pa programim);

Faza e programimit (duke përfshirë hartimin e bazës së të dhënave fizike);

Pas projektit, duke përfshirë vënien në punë, funksionimin dhe mirëmbajtjen e sistemit.

Në fazën e para-projektimit, ndërtohet një model kërkesash për sistemin, pra një përshkrim i detajuar i asaj që duhet të bëjë, pa specifikuar se si do të zbatohen kërkesat.

Në fazën e projektit, modeli i kërkesave përpunohet (zhvillimi i një modeli hierarkik të detajuar bazuar në specifikimet e DFD dhe procesit) dhe zgjerimi i tij në modelin e zbatimit në nivel logjik. Në përfundim të kësaj faze, bëhet një kontroll i kujdesshëm i projektit në nivelin e modelit logjik të zbatimit.

Faza tjetër (programimi) është dizajni fizik i sistemit. Kjo fazë parashikon gjenerimin automatik të kodit sipas specifikave të proceseve të softuerit të sistemit dhe dizajnit fizik të bazës së të dhënave.

Faza e fundit pas projektit fillon me testet e pranimit. Kjo pasohet nga vënia në punë, mirëmbajtja dhe zhvillimi i sistemit.

Sekuenca e operacioneve për krijimin e një sistemi informacioni të bazuar në teknologjinë CASE është paraqitur në fig. 11.10.

Merrni parasysh faktorët e efikasitetit të teknologjisë CASE.

1. Duhet të theksohet se CASE-teknologjia krijon një mundësi dhe parashikon transferimin e qendrës së gravitetit në kompleksitetin e krijimit të një sistemi në fazat e para-projektimit dhe projektimit. Përpunimi i kujdesshëm i këtyre fazave në një mënyrë interaktive me mbështetje kompjuterike e zvogëlon numrin gabimet e mundshme në dizajn, të cilat janë të vështira për t'u korrigjuar në fazat e mëvonshme.

2. Forma grafike e paraqitjes së modelit, e aksesueshme për t'u kuptuar nga përdoruesit joprogramues, bën të mundur zbatimin e parimit të dizajnit të përdoruesit, i cili parashikon pjesëmarrjen e përdoruesve në krijimin e sistemit. Modeli CASE lejon arritjen e mirëkuptimit të ndërsjellë midis të gjithë pjesëmarrësve në krijimin e sistemit (klientët, përdoruesit, projektuesit, programuesit).

3. Prania e një modeli të formalizuar të sistemit në fazën e para-projektimit krijon një mundësi për analizë multivariate me prototip dhe një vlerësim të përafërt të efektivitetit të opsioneve. Analiza e sistemit prototip ju lejon të rregulloni sistemin e ardhshëm përpara se të zbatohet fizikisht. Kjo qasje shpejton dhe ul koston e krijimit të një sistemi.

4. Rregullimi i kërkesave të sistemit në një formë të formalizuar i shpëton projektuesit nga nevoja për rregullime të shumta ndaj kërkesave të reja të përdoruesve.

5. Ndarja e dizajnit të sistemit nga programimi krijon qëndrueshmërinë e zgjidhjeve të projektimit për implementim në platforma të ndryshme softuerike dhe harduerike.

6. Prania e një modeli të formalizuar për zbatimin e sistemit dhe mjeteve të përshtatshme të automatizimit lejon gjenerimin automatik të kodit të softuerit të sistemit dhe krijimin e një strukture racionale të bazës së të dhënave.

7. Në fazën e funksionimit të sistemit, bëhet e mundur të bëhen ndryshime në nivel modeli, pa iu referuar teksteve të programeve, mundësisht nga forcat e specialistëve të departamentit të automatizimit të kompanisë.

8. Modeli i sistemit mund të përdoret jo vetëm si bazë për krijimin e tij, por edhe për qëllimin e trajnimit të automatizuar të personelit duke përdorur diagrame.

9. Bazuar në modelin e sistemit aktual, analiza e biznesit mund të kryhet për të mbështetur vendimet e menaxhimit dhe riinxhinierimin e biznesit gjatë ndryshimit të drejtimit të kompanisë.

Merrni parasysh mjetet softuerike që ofrojnë teknologjinë CASE. Në varësi të qëllimit funksional, ato ndahen në grupet e mëposhtme të klasifikimit, duke siguruar:

Analiza dhe dizajnimi i sistemit të informacionit;

Dizajni i bazës së të dhënave;

Programimi;

Mirëmbajtja dhe riinxhinierimi;

Menaxhimi i procesit të projektimit.

Mjetet e analizës dhe projektimit përdoren për të ndërtuar një model CASE të sistemit të kontrollit aktual dhe të zbatuar. Ato mbështesin ndërtimin dhe kontrollin grafik të modelit hierarkik të diagrameve të rrjedhës së të dhënave dhe përshkrimin e komponentëve të tij. Këto mjete lejojnë analistët dhe projektuesit të kenë akses në bazën e të dhënave të sistemit të projektuar (depo).

Këto mjete përfshijnë: paketën e brendshme CASE. Analist, Design/IDEF (Meta Software), The Developer (ASYST Technologies), etj.

Për të përmbushur kërkesat e përdoruesve, krijohen prototipe të ndërfaqeve të përdoruesit, duke përfshirë menutë, format e ekranit dhe raportet në formën e tabelave ose grafikëve. Një shembull i një mjeti softuerësh të ndërfaqes së përdoruesit është Developer/2000 (Oracle).

Mjetet e projektimit të bazës së të dhënave sigurojnë modelimin logjik të të dhënave, konvertimin automatik të modeleve të të dhënave në formën e tretë normale dhe gjenerimin e skemave të bazës së të dhënave. Shembuj të mjeteve të tilla janë Designer/2000 nga Oracle, ERWin (Logic Works), etj.

Mjetet e programimit mbështesin gjenerimin automatik të kodit nga specifikimet e procesit, testimi dhe dokumentacioni i programit. Këto përfshijnë Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software), etj.

Mjetet e mirëmbajtjes dhe riinxhinierimit ju lejojnë të bëni ndryshime në sistem në nivel modeli në kushtet e ndryshimit të biznesit (Adpac CASE Tools nga Adpac, etj.).

Mjetet e menaxhimit të procesit të projektimit mbështesin planifikimin dhe kontrollin e një sërë pune projektimi, si dhe ndërveprimin e analistëve, projektuesve dhe programuesve bazuar në një bazë të dhënash të përbashkët të projektit (për shembull, Project Workbench nga Applied Business Technology). Rëndësia e krijimit të një pakete të integruar mjetesh për të mbështetur teknologjinë CASE në të gjitha fazat e ciklit jetësor të një sistemi informacioni është e dukshme.

Agjencia Federale për Arsimin

shteti federal institucion arsimor Arsimi i lartë profesional "Universiteti Shtetëror Chuvash. I.N. Ulyanova»

Instituti Financiar dhe Ekonomik

Fakulteti Ekonomik

Abstrakt mbi temën: CASE-teknologji për projektimin e sistemeve të automatizuara të informacionit

Plotësuar nga një student

Grupet EK 22-06

Evgrafova I.A.

Kontrolluar nga: Pavlova S.Yu.

Cheboksary 2007

Hyrje……………………………………………………………………………………………………………………………………………………………

Cikli jetësor i softuerit të sistemit të informacionit…………………………………………………………………….5

RAD-teknologjitë për aplikimet e prototipit…………….7

· Metoda strukturore e zhvillimit të softuerit……10

Literatura e përdorur………………………………………..17

Prezantimi

Gjatë dekadës së kaluar, është formuar një drejtim i ri në inxhinierinë e softuerit - CASE (Software me ndihmën e kompjuterit / Inxhinieri e Sistemit) - në përkthim fjalë për fjalë - zhvillimi i softuerit të sistemeve të informacionit me mbështetjen (me ndihmën) e një kompjuteri. Aktualisht nuk ka një përkufizim të pranuar përgjithësisht të CASE, termi CASE përdoret në një kuptim shumë të gjerë. Kuptimi origjinal i termit CASE, i kufizuar në çështjet e automatizimit të zhvillimit vetëm të softuerit, tani ka marrë një kuptim të ri, duke mbuluar procesin e zhvillimit të sistemeve komplekse të automatizuara të informacionit në tërësi. Tani, termi CASE-tools i referohet mjeteve softuerike që mbështesin proceset e krijimit dhe mirëmbajtjes së IS, duke përfshirë analizën dhe formulimin e kërkesave, hartimin e softuerit të aplikacionit (aplikacionet) dhe bazat e të dhënave, gjenerimin e kodit, testimin, dokumentacionin, sigurimin e cilësisë, menaxhimin e konfigurimit. dhe menaxhimin e projektit, si dhe procese të tjera. Mjetet CASE, së bashku me softuerin dhe harduerin e sistemit, formojnë një mjedis të plotë zhvillimi AIS.

Mjetet CASE lejojnë jo vetëm krijimin e produkteve "korrekte", por gjithashtu ofrojnë procesin "korrekt" të krijimit të tyre. Qëllimi kryesor i CASE është të ndajë dizajnin e softuerit nga kodimi i tij dhe fazat pasuese të zhvillimit, si dhe të fshehë nga zhvilluesit të gjitha detajet e mjedisit dhe funksionimit të zhvillimit të softuerit. Kur përdorni teknologjitë CASE, të gjitha fazat e ciklit jetësor të softuerit (më shumë për këtë do të diskutohet më poshtë) të sistemit të informacionit ndryshojnë, me ndryshimet më të mëdha në lidhje me fazat e analizës dhe projektimit. Shumica e mjeteve ekzistuese CASE bazohen në metodologjitë e analizës strukturore (kryesisht) ose të orientuara nga objekti, duke përdorur specifikime në formën e diagrameve ose teksteve për të përshkruar kërkesat e jashtme, marrëdhëniet midis modeleve të sistemit, dinamikën e sjelljes së sistemit dhe arkitekturat e softuerit. Metodologji të tilla ofrojnë një përshkrim rigoroz dhe vizual të sistemit të projektuar, i cili fillon me pasqyrën e tij të përgjithshme dhe më pas detajet, duke marrë një strukturë hierarkike me të gjitha një numër i madh nivelet. Teknologjitë CASE përdoren me sukses për të ndërtuar pothuajse të gjitha llojet e sistemeve softuerike, por ato zënë një pozicion të qëndrueshëm në fushat e mëposhtme:

♦ sigurimin e zhvillimit të softuerit të biznesit dhe komercial, përdorimin e gjerë të teknologjive CASE për shkak të natyrës masive të kësaj fushe aplikimi, në të cilën CASE përdoret jo vetëm për zhvillimin e softuerit, por edhe për krijimin e modeleve të sistemit që ndihmojnë në zgjidhjen e problemeve të planifikimi strategjik, menaxhimi financiar, përcaktimi i politikës së firmave, trajnimi i personelit etj. (ky drejtim ka marrë emrin e vet - analiza e biznesit);

♦ zhvillim i softuerit të sistemit dhe kontrollit. Përdorimi aktiv i teknologjive CASE shoqërohet me kompleksitetin e madh të këtij problemi dhe me dëshirën për të rritur efikasitetin e punës.

CASE nuk është një revolucion në inxhinierinë softuerike, por rezultat i zhvillimit natyror evolucionar të të gjithë industrisë së mjeteve, të quajtura më parë instrumentale ose teknologjike. Që nga fillimi, teknologjitë CASE kanë evoluar për të kapërcyer kufizimet e përdorimit të metodologjive të projektimit strukturor të viteve '60 dhe '70. Shekulli 20 (kompleksiteti i të kuptuarit, intensiteti i lartë i punës dhe kostoja e përdorimit, vështirësia për të bërë ndryshime në specifikimet e projektimit, etj.) për shkak të automatizimit të tyre dhe integrimit të mjeteve mbështetëse. Kështu, teknologjitë CASE nuk mund të konsiderohen metodologji të pavarura, ato vetëm zhvillojnë metodologji strukturore dhe e bëjnë aplikimin e tyre më efikas përmes automatizimit.

Përveç automatizimit të metodologjive strukturore dhe, si rezultat, mundësisë së përdorimit të metodave moderne të inxhinierisë së sistemit dhe softuerit, mjetet CASE kanë përparësitë kryesore të mëposhtme:

♦ përmirësimi i cilësisë së softuerit të krijuar me anë të kontrollit automatik (kryesisht kontrolli i projektit);

♦ bëjnë të mundur krijimin e një prototipi të një sistemi të ardhshëm në një kohë të shkurtër, i cili bën të mundur vlerësimin e rezultatit të pritur në një fazë të hershme;

♦ përshpejtojnë procesin e projektimit dhe zhvillimit;

♦ lironi zhvilluesin nga puna rutinë, duke e lejuar atë të përqendrohet tërësisht në pjesën krijuese të zhvillimit;

♦ mbështes zhvillimin dhe mirëmbajtjen e zhvillimit;

♦ Mbështet teknologjitë e ripërdorimit të komponentëve të zhvillimit.

Shfaqjes së teknologjisë CASE dhe mjeteve CASE i ka paraprirë kërkimet në fushën e metodologjisë së programimit. Programimi ka fituar tiparet e një qasjeje sistematike me zhvillimin dhe zbatimin e gjuhëve të nivelit të lartë, metodat e programimit të strukturuar dhe modular, gjuhët e projektimit dhe mjetet e tyre mbështetëse, gjuhët e përshkrimit formal dhe joformal. Kërkesat e sistemit dhe specifikimet etj.Në vitet 70-80. një metodologji strukturore filloi të zbatohej në praktikë, duke u ofruar zhvilluesve metoda të rrepta të zyrtarizuara për përshkrimin e AIS dhe të pranuara - zgjidhje teknike. Ai bazohet në një teknikë grafike vizuale: diagramet dhe diagramet përdoren për të përshkruar lloje të ndryshme të modeleve AIS. Dukshmëria dhe ashpërsia e mjeteve të analizës strukturore i lejoi zhvilluesit dhe përdoruesit e ardhshëm të sistemit që nga fillimi të marrin pjesë joformalisht në krijimin e tij, të diskutojnë dhe të konsolidojnë të kuptuarit e zgjidhjeve kryesore teknike. Sidoqoftë, përdorimi i gjerë i kësaj metodologjie dhe ndjekja e rekomandimeve të saj në zhvillimin e AIS-it të kontaktit ishte mjaft e rrallë, pasi është praktikisht e pamundur me zhvillim jo të automatizuar (manual). Kjo kontribuoi në shfaqjen e një klase të veçantë të softuerit dhe harduerit - mjetet CASE që zbatojnë teknologjinë CASE për krijimin dhe mirëmbajtjen e AIS.

Duhet të kuptohet se përdorimi i suksesshëm i mjeteve CASE është i pamundur pa një kuptim të teknologjisë themelore në të cilën bazohen këto mjete. Vetë veglat softuerike CASE janë mjete për automatizimin e proceseve të projektimit dhe mirëmbajtjes së sistemeve të informacionit. Pa kuptuar metodologjinë e projektimit të IS, është e pamundur të përdoren mjetet CASE.

1. Cikli jetësor i softuerit të sistemit të informacionit

Një nga konceptet bazë të metodologjisë së projektimit AIS është koncepti i ciklit jetësor të softuerit të tij (softveri LC). Cikli jetësor i softuerit është një proces i vazhdueshëm që fillon nga momenti kur merret një vendim për nevojën e krijimit të tij dhe përfundon në momentin e tërheqjes së plotë të tij nga funksionimi.

Struktura e ciklit jetësor të softuerit bazohet në tre grupe procesesh:

♦ proceset kryesore të ciklit jetësor të softuerit (blerja, furnizimi, zhvillimi, funksionimi, mirëmbajtja);

♦ procese ndihmëse që sigurojnë zbatimin e proceseve kryesore (dokumentimi, menaxhimi i konfigurimit, sigurimi i cilësisë, verifikimi, certifikimi, vlerësimi, auditimi, zgjidhja e problemeve);

♦ proceset organizative (menaxhimi i projektit, krijimi i infrastrukturës së projektit, përcaktimi, vlerësimi dhe përmirësimi i vetë ciklit jetësor, trajnimi).

Zhvillimi përfshin të gjithë punën për krijimin e softuerit dhe përbërësve të tij në përputhje me kërkesat e specifikuara, duke përfshirë përgatitjen e dokumentacionit të projektimit dhe operacional, përgatitjen e materialeve të nevojshme për të testuar funksionueshmërinë dhe cilësinë e duhur të produkteve softuerike, materialet e nevojshme për organizimin e personelit trajnimi, etj. Zhvillimi i softuerit zakonisht përfshin analizën, dizajnimin dhe zbatimin (programimin).

Operacioni përfshin punën për zbatimin e komponentëve të softuerit në funksionim, duke përfshirë konfigurimin e bazës së të dhënave dhe stacioneve të punës së përdoruesit, sigurimin e dokumentacionit operacional, kryerjen e trajnimit të stafit, etj. dhe funksionimin e drejtpërdrejtë, duke përfshirë lokalizimin e problemeve dhe eliminimin e shkaqeve të shfaqjes së tyre, modifikimin e softuerit brenda rregulloret e vendosura, përgatitja e propozimeve për përmirësimin, zhvillimin dhe modernizimin e sistemit.

Menaxhimi i projektit lidhet me çështjet e planifikimit dhe organizimit të punës, krijimit të ekipeve të zhvilluesve dhe monitorimit të kohës dhe cilësisë së punës së kryer.

Mbështetja teknike dhe organizative e projektit përfshin zgjedhjen e metodave dhe mjeteve për zbatimin e projektit, përcaktimin e metodave për përshkrimin e gjendjeve të ndërmjetme të zhvillimit, zhvillimin e metodave dhe mjeteve për testimin e softuerit, trajnimin e stafit, etj. Sigurimi i cilësisë së projektit shoqërohet me problemet e verifikimit, verifikimit dhe testimit të softuerit. Verifikimi është procesi i përcaktimit nëse gjendja aktuale e zhvillimit të arritur në një fazë të caktuar i plotëson kërkesat e asaj faze. Validimi ju lejon të vlerësoni përputhshmërinë e parametrave të zhvillimit me kërkesat origjinale. Verifikimi përputhet me testimin, i cili ka të bëjë me identifikimin e dallimeve midis rezultateve aktuale dhe të pritshme dhe vlerësimin nëse veçoritë e softuerit përmbushin kërkesat origjinale. Në procesin e zbatimit të projektit, një vend të rëndësishëm zënë çështjet e identifikimit, përshkrimit dhe kontrollit të konfigurimit të përbërësve individualë dhe të gjithë sistemit në tërësi.

Menaxhimi i konfigurimit është një nga proceset ndihmëse që mbështet proceset kryesore të ciklit jetësor të softuerit, kryesisht proceset e zhvillimit dhe mirëmbajtjes së softuerit. Kur krijohen projekte komplekse IS që përbëhen nga shumë komponentë, secila prej të cilave mund të ketë varietete ose versione, lind problemi i marrjes parasysh të marrëdhënieve dhe funksioneve të tyre, krijimit të një strukture të unifikuar dhe sigurimit të zhvillimit të të gjithë sistemit. Menaxhimi i konfigurimit ju lejon të organizoni, merrni parasysh dhe kontrolloni në mënyrë sistematike ndryshimet në softuer në të gjitha fazat e ciklit jetësor. Parimet e përgjithshme dhe rekomandimet për kontabilitetin e konfigurimit, planifikimin dhe menaxhimin e konfigurimeve të softuerit janë pasqyruar në draft standardin ISO 12207-2.

Çdo proces karakterizohet nga detyra dhe metoda të caktuara për zgjidhjen e tyre, të dhënat fillestare të marra në fazën e mëparshme dhe rezultatet. Rezultatet e analizës, në veçanti, janë modelet funksionale, modelet e informacionit dhe diagramet e tyre përkatëse. Cikli i jetës së softuerit është përsëritës në natyrë: rezultatet e fazës tjetër shpesh shkaktojnë ndryshime në vendimet e projektimit të zhvilluara në fazat e mëparshme.

Modelet ekzistuese të ciklit jetësor përcaktojnë rendin e ekzekutimit të fazave gjatë zhvillimit, si dhe kriteret për kalimin nga faza në fazë. Në përputhje me këtë, tre modelet e mëposhtme të ciklit jetësor përdoren më gjerësisht:

♦ Modeli kaskadë (1970-1980) - ofron një kalim në fazën tjetër pas përfundimit të punës në fazën e mëparshme;

♦ model i shkallëzuar me kontroll të ndërmjetëm (1980-1985) - një model i përsëritur i zhvillimit të softuerit me unaza kthyese ndërmjet fazave. Avantazhi i këtij modeli është se rregullimet ndërfazore ofrojnë më pak intensitet të punës në krahasim me modelin e ujëvarës, megjithatë, jetëgjatësia e secilës prej fazave zgjatet gjatë gjithë periudhës së zhvillimit;

♦ model spirale (1986-1990) - thekson fazat fillestare të ciklit jetësor: analiza e kërkesave, dizajni i specifikimeve, projektimi paraprak dhe i detajuar. Në këto faza kontrollohet dhe arsyetohet fizibiliteti i zgjidhjeve teknike duke krijuar prototipa. Çdo kthesë e spirales korrespondon me një model hap pas hapi për krijimin e një fragmenti ose versioni të një produkti softuer, në të cilin specifikohen qëllimet dhe karakteristikat e projektit, përcaktohet cilësia e tij dhe puna e kthesës tjetër të spiralja është planifikuar. Kështu, detajet e projektit thellohen dhe konkretizohen në mënyrë konsekuente dhe si rrjedhojë zgjidhet një opsion i arsyeshëm, i cili vihet në zbatim.

Ekspertët vërejnë avantazhet e mëposhtme të modelit spirale:

♦ akumulim dhe ripërdorim mjete softuerike, modele dhe prototipe;

♦ fokus në zhvillimin dhe modifikimin e softuerit në procesin e hartimit të tij;

♦ Analiza e rrezikut dhe kostos në procesin e projektimit.

tipar kryesor Industria e zhvillimit të softuerit konsiston në përqendrimin e kompleksitetit në fazat fillestare të ciklit jetësor (analizë, dizajn) me kompleksitet dhe intensitet relativisht të ulët të punës së fazave të mëvonshme. Për më tepër, çështjet e pazgjidhura dhe gabimet e bëra gjatë fazave të analizës dhe projektimit sjellin probleme të vështira, shpesh të pazgjidhshme në fazat pasuese dhe, në fund të fundit, çojnë në dështimin e të gjithë projektit.

2. RAD - teknologjitë e prototipit të aplikimit

Një nga qasjet e mundshme për zhvillimin e softuerit në kuadrin e modelit të ciklit jetësor spirale është metodologjia e përdorur gjerësisht së fundmi për zhvillimin e shpejtë të aplikacioneve RAD (Rapid Application Development). Ky term zakonisht i referohet një procesi të zhvillimit të softuerit që përmban tre elementë:

♦ ekip i vogël programuesish (nga 2 deri në 10 persona);

♦ orar prodhimi i shkurtër, por i përpunuar me kujdes (nga 2 deri në 6 muaj);

♦ një cikël përsëritës në të cilin zhvilluesit, kur aplikacioni fillon të marrë formë, kërkojnë dhe zbatojnë në produkt kërkesat e marra nëpërmjet ndërveprimeve me klientin.

Ekipi i zhvillimit duhet të jetë një grup profesionistësh me përvojë në analizën, dizajnimin, gjenerimin e kodit dhe testimin e softuerit duke përdorur mjetet CASE. Anëtarët e ekipit duhet gjithashtu të jenë në gjendje të transformojnë propozimet e përdoruesve fundorë në prototipe pune.

Cikli i jetës së softuerit sipas metodologjisë RAD përbëhet nga katër faza:

♦ Fazat e analizës dhe planifikimit të kërkesave;

♦ fazat e projektimit;

♦ fazat e ndërtimit;

♦ fazat e zbatimit.

Në fazën e analizës dhe planifikimit të kërkesave, përdoruesit e sistemit përcaktojnë funksionet që duhet të kryejë, nxjerrin në pah prioritetin më të lartë të tyre që kërkojnë përpunim në radhë të parë dhe përshkruajnë nevojat për informacion. Përcaktimi i kërkesave kryhet kryesisht nga përdoruesit nën drejtimin e zhvilluesve specialistë. Shkalla e projektit është e kufizuar, përcaktohet afati kohor për secilën nga fazat pasuese. Gjithashtu, përcaktohet edhe vetë mundësia e zbatimit të këtij projekti brenda kornizës së përcaktuar të financimit, në këto pajisje, etj.. Rezultati i kësaj faze duhet të jetë një listë dhe prioritet i funksioneve të AIS-it të ardhshëm, modele paraprake funksionale dhe informative të. IS.

Gjatë fazës së projektimit, disa përdorues marrin pjesë në hartimin teknik të sistemit nën drejtimin e zhvilluesve specialistë. Mjetet CASE përdoren për të marrë shpejt prototipet e aplikacioneve që funksionojnë. Përdoruesit, duke ndërvepruar drejtpërdrejt me ta, sqarojnë dhe plotësojnë kërkesat për sistemin që nuk ishin identifikuar në fazën e mëparshme. Proceset e sistemit konsiderohen më në detaje. Modeli funksional analizohet dhe, nëse është e nevojshme, korrigjohet. Çdo proces konsiderohet në detaje. Nëse është e nevojshme, krijohet një prototip i pjesshëm për çdo proces elementar: një ekran, një dialog, një raport që eliminon paqartësitë ose paqartësitë. Përcaktohen kërkesat e diferencimit të aksesit të të dhënave. Në të njëjtën fazë, përcaktohet grupi i dokumentacionit të nevojshëm.

Pas një përcaktimi të detajuar të përbërjes së proceseve, numri i elementet funksionale të sistemit të zhvilluar dhe merret një vendim për të ndarë AIS në nënsisteme që mund të zbatohen nga një ekip zhvilluesish në një kohë të pranueshme për projektet RAD - afërsisht 60-90 ditë. Duke përdorur mjetet CASE, projekti shpërndahet midis ekipeve të ndryshme (modeli funksional është i ndarë). Kjo fazë duhet të rezultojë në:

♦ modeli i përgjithshëm i informacionit të sistemit;

♦ modelet funksionale të sistemit në tërësi dhe nënsistemet e zbatuara nga ekipet individuale të zhvillimit;

♦ Ndërfaqet e përcaktuara nga CASE ndërmjet nënsistemeve të zhvilluara në mënyrë autonome;

♦ prototipe të ndërtuara ekranesh, raportesh, dialogësh.

Të gjitha modelet dhe prototipet duhet të merren duke përdorur ato mjete CASE që do të përdoren më vonë gjatë ndërtimit të sistemit. Kjo kërkesë për shkak të faktit se në qasjen tradicionale, gjatë transferimit të informacionit në lidhje me projektin nga faza në fazë, mund të ndodhë shtrembërim praktikisht i pakontrolluar i të dhënave. Përdorimi i një mjedisi të vetëm ruajtjeje për informacionin rreth projektit e shmang këtë rrezik.

Ndryshe nga qasja tradicionale, e cila përdorte mjete specifike të prototipit që nuk ishin të destinuara për ndërtimin e aplikacioneve reale, dhe prototipat i hodhën poshtë pasi kishin përfunduar detyrën e eliminimit të paqartësive në dizajn, në qasjen RAD, çdo prototip zhvillohet në një pjesë. sistemi i ardhshëm. Kështu, informacioni më i plotë dhe më i dobishëm transmetohet në fazën tjetër.

Gjatë fazës së ndërtimit, zhvillimi i shpejtë i vetë aplikacionit kryhet drejtpërdrejt. Në këtë fazë, zhvilluesit ndërtojnë në mënyrë të përsëritur një sistem real bazuar në modelet e marra në fazën e mëparshme, si dhe kërkesat jofunksionale. Kodi i programit gjenerohet pjesërisht duke përdorur gjeneratorë automatikë që marrin informacion direkt nga depoja e veglave CASE. Përdoruesit përfundimtarë në këtë fazë vlerësojnë rezultatet e marra dhe bëjnë rregullime nëse, gjatë procesit të zhvillimit, sistemi nuk i plotëson më kërkesat e përcaktuara më parë. Testimi i sistemit kryhet drejtpërdrejt në procesin e zhvillimit.

Pas përfundimit të punës së secilit ekip zhvillimor individual, kjo pjesë e sistemit integrohet gradualisht me pjesën tjetër, formohet një kod i plotë programi dhe kryhet testimi. punë e përbashkët këtë pjesë të aplikacionit me pjesën tjetër, dhe më pas testimin e sistemit në tërësi. Dizajni fizik i sistemit është duke u përfunduar:

♦ përcaktohet nevoja për shpërndarje të të dhënave;

♦ kryhet një analizë e përdorimit të të dhënave;

♦ dizajn fizik i bazës së të dhënave;

♦ janë përcaktuar kërkesat për burimet e harduerit;

♦ Janë identifikuar mënyra për të rritur produktivitetin;

♦ po përfundon zhvillimi i dokumentacionit të projektit. Rezultati i fazës është një sistem i përfunduar që plotëson të gjitha kërkesat e dakorduara.

Në fazën e zbatimit kryhen trajnimet e përdoruesve, ndryshimet organizative dhe paralelisht me futjen e sistemit të ri, punohet me sistemin ekzistues (derisa sistemi i ri të zbatohet plotësisht). Meqenëse faza e ndërtimit është relativisht e shkurtër, planifikimi dhe përgatitja për zbatim duhet të fillojë herët, zakonisht gjatë fazës së projektimit të sistemit.

Skema e mësipërme për zhvillimin e AIS nuk është absolute. E mundshme opsione të ndryshme në varësi, për shembull, në kushtet fillestare ku po zhvillohet zhvillimi: nëse po zhvillohet një sistem krejtësisht i ri; nëse është kryer një studim informacioni i organizatës dhe nëse ekziston një model i veprimtarisë së saj; nëse ka ndonjë AIS në organizatë që mund të përdoret si prototip fillestar ose duhet të integrohet me atë që po zhvillohet, etj.

Sidoqoftë, duhet të theksohet se metodologjia RAD, si çdo tjetër, nuk mund të pretendojë të jetë universale, ajo është e mirë kryesisht për projekte relativisht të vogla të zhvilluara për një klient specifik. Nëse po zhvillohet një sistem tipik, i cili nuk është një produkt i përfunduar, por është një kompleks komponentësh tipikë, të mirëmbajtur në qendër, të përshtatur me platformat softuerike dhe harduerike, DBMS, telekomunikacionin, veçoritë organizative dhe ekonomike të objekteve të zbatimit dhe të integruar me zhvillimet ekzistuese, dalin në plan të parë metrikat e projektit si menaxhueshmëria dhe cilësia, të cilat mund të bien ndesh me lehtësinë dhe shpejtësinë e zhvillimit. Projekte të tilla kërkojnë një nivel të lartë planifikimi dhe disiplinë të rreptë të projektimit, respektim të rreptë të protokolleve dhe ndërfaqeve të paracaktuara, gjë që redukton shpejtësinë e zhvillimit.

Metodologjia RAD nuk është e zbatueshme për ndërtimin e programeve komplekse të llogaritjes, sistemeve operative ose programeve të kontrollit anije kozmike, pra programe që kërkojnë të shkruajnë një sasi të madhe (qindra mijëra rreshta) kodi unik.

Aplikacionet që nuk kanë një pjesë të theksuar të ndërfaqes që përcakton qartë logjikën e funksionimit të sistemit (për shembull, aplikacionet në kohë reale) dhe aplikacionet që ndikojnë në sigurinë e njerëzve (për shembull, kontrolli i një avioni ose një termocentrali bërthamor) janë jo i përshtatshëm për zhvillim duke përdorur metodologjinë RAD, pasi një qasje përsëritëse supozon se versionet e para me shumë mundësi nuk do të jenë plotësisht funksionale, gjë që në këtë rast përjashtuar. Parimet themelore të metodologjisë RAD:

♦ zhvillim i aplikacioneve me përsëritje;

♦ përfundimi i plotë me dëshirë i punës në çdo fazë të ciklit jetësor;

♦ Përfshirja e detyrueshme e përdoruesve në zhvillimin e AIS;

♦ përdorimin e nevojshëm të mjeteve CASE që sigurojnë integritetin e projektit;

♦ përdorimin e mjeteve të menaxhimit të konfigurimit që lehtësojnë futjen e ndryshimeve në projekt dhe mirëmbajtjen e sistemit të përfunduar;

♦ përdorimin e nevojshëm të gjeneratorëve të kodit;

♦ përdorimin e prototipit për të kuptuar dhe plotësuar më mirë nevojat e përdoruesit përfundimtar;

♦ testimi dhe zhvillimi i projektit, i kryer njëkohësisht me zhvillimin;

♦ zhvillim i udhëhequr nga një ekip i vogël profesionistësh i mirëmenaxhuar;

♦ Menaxhimi kompetent i zhvillimit të sistemit, planifikimi dhe kontrolli i qartë i punës.

3. Metoda strukturore e zhvillimit të softuerit

Thelbi qasje strukturore Zhvillimi i AIS qëndron në zbërthimin (ndarjen) e tij në funksione të automatizuara: sistemi ndahet në nënsisteme funksionale, të cilat, nga ana tjetër, ndahen në nënfunksione, të nënndara në detyra, etj. Procesi i ndarjes vazhdon deri në procedura specifike. Në të njëjtën kohë, sistemi i automatizuar ruan një pamje holistike në të cilën të gjithë komponentët janë të ndërlidhur. Kur zhvillohet një sistem nga poshtë lart, nga detyrat individuale në të gjithë sistemin, humbet integriteti, shfaqen probleme në lidhjen informative të komponentëve individualë.

Të gjitha metodologjitë e analizës strukturore bazohen në një numër të parimet e përgjithshme, disa prej të cilave rregullojnë organizimin e punës në fazat fillestare të ciklit jetësor, dhe disa përdoren në zhvillimin e rekomandimeve për organizimin e punës. Si dy parimet bazë përdoren: parimi “përça dhe sundo” dhe parimi i renditjes hierarkike. E para është parimi i zgjidhjes së problemeve të vështira duke i zbërthyer ato në shumë probleme më të vogla, të pavarura që janë më të lehta për t'u kuptuar dhe zgjidhur. Parimi i dytë deklaron se rregullimi i këtyre pjesëve është gjithashtu thelbësor për të kuptuar. Niveli i të kuptuarit të problemit rritet ndjeshëm kur pjesët e tij paraqiten në formën e një peme. strukturat hierarkike, pra sistemi mund të kuptohet dhe ndërtohet në nivele, secila prej të cilave shton detaje të reja.

Zgjedhja e dy parimeve bazë të inxhinierisë softuerike nuk do të thotë se parimet e tjera janë dytësore, injorimi i ndonjërit prej tyre mund të çojë në pasoja të paparashikueshme (duke përfshirë dështimin e të gjithë projektit). Le të hedhim një vështrim në disa nga parimet kryesore.

1. Parimi i abstraksionit - konsiston në nxjerrjen në pah të aspekteve të sistemit që janë domethënëse nga disa pozicione dhe abstragimin nga ato jo thelbësore për të paraqitur problemin në një formë të thjeshtë të përgjithshme.

2. Parimi i formalizimit - qëndron në nevojën për një qasje metodologjike rigoroze për zgjidhjen e problemit.

3. Parimi i “fshehjes” – është fshehja e informacionit që nuk është thelbësor në një fazë të caktuar: secila pjesë “di” vetëm informacionin që i nevojitet.

4. Parimi i përbashkësisë konceptuale - është ndjekja e një filozofie të vetme në të gjitha fazat e ciklit jetësor (analiza strukturore - projektimi strukturor - programimi strukturor - testimi strukturor).

5. Parimi i plotësisë - është të kontrollohet prania e elementeve të tepërta.

6. Parimi i konsistencës - është vlefshmëria dhe konsistenca e elementeve.

7. Parimi i pavarësisë logjike - është fokusimi në dizajnin logjik për të siguruar pavarësinë nga dizajni fizik.

8. Parimi i pavarësisë së të dhënave - është se modelet e të dhënave duhet të analizohen dhe dizajnohen në mënyrë të pavarur nga proceset e përpunimit logjik të tyre, si dhe nga struktura fizike dhe shpërndarja e tyre.

9. Parimi i strukturimit të të dhënave – është se të dhënat duhet të jenë të strukturuara dhe të organizuara në mënyrë hierarkike.

10. Parimi i aksesit të përdoruesit fundor - është që përdoruesi duhet të ketë qasje në bazën e të dhënave, të cilën mund ta përdorë drejtpërdrejt (pa programim).

Pajtueshmëria me këto parime është e nevojshme gjatë organizimit të punës në fazat fillestare të ciklit jetësor, pavarësisht nga lloji i softuerit që po zhvillohet dhe metodologjitë e përdorura. Të udhëhequr nga të gjitha parimet në një kompleks, është e mundur që në fazat e hershme të zhvillimit të kuptojmë se çfarë do të jetë sistemi që po krijohet, për të zbuluar gabimet dhe mangësitë, të cilat, nga ana tjetër, do të lehtësojnë punën në fazat vijuese të ciklit jetësor dhe do të ulin koston e zhvillimit.

Në analizën strukturore përdoren kryesisht dy grupe mjetesh që ilustrojnë funksionet e kryera nga sistemi dhe marrëdhëniet ndërmjet të dhënave. Secili grup mjetesh korrespondon me lloje të caktuara modelesh (diagrame), më të zakonshmet prej të cilave janë këto:

♦ SADT (Structured Analysis and Design Technique) - modele dhe diagrame funksionale përkatëse;

♦ DFD (Data Flow Diagrams) - diagrame të rrjedhës së të dhënave;

♦ ERD (Entity-Relationship Diagrams) - diagrame "entitet-marrëdhënie";

♦ STD (State Trasition Diagrams) - diagrame të tranzicionit të gjendjes.

Në fazën e projektimit të IS, modelet zgjerohen, rafinohen dhe plotësohen me diagrame që pasqyrojnë strukturën e softuerit: arkitektura e softuerit, bllok diagramet e programeve dhe diagramet e formës së ekranit.

Modelet e listuara së bashku japin një përshkrim të plotë të AIS, pavarësisht nëse është ekzistues apo i sapo zhvilluar. Përbërja e diagrameve në çdo rast të veçantë varet nga plotësia e kërkuar e përshkrimit të sistemit.

Metodologjia SADT

Metodologjia SADT u zhvillua nga Douglas Ross; mbi bazën e saj u zhvillua metodologjia e mirënjohur IDEFO (Icam Definition), e cila është pjesa kryesore e programit Icam (Integrimi i Teknologjive Kompjuterike dhe Industriale) të iniciuar nga Shtetet e Bashkuara. Metodologjia SADT është një grup metodash, rregullash dhe procedurash të krijuara për të ndërtuar një model funksional të një objekti në çdo fushë lëndore. Modeli funksional SADT shfaq strukturën funksionale të një objekti, d.m.th., veprimet që ai kryen dhe marrëdhëniet midis këtyre veprimeve. Elementet kryesore të kësaj metodologjie bazohen në konceptet e mëposhtme:

♦ paraqitje grafike modelimi i bllokut. Grafikët e bllokut dhe harkut të diagramit SADT shfaqin funksionin si bllok, dhe ndërfaqet hyrëse/dalëse përfaqësohen nga harqe që hyjnë dhe dalin nga blloku, përkatësisht. Ndërveprimi i blloqeve me njëri-tjetrin përshkruhet me anë të harqeve të ndërfaqes që shprehin "kufizime", të cilat, nga ana tjetër, përcaktojnë se kur dhe si kryhen dhe kontrollohen funksionet;

♦ ashpërsi dhe saktësi. Zbatimi i rregullave të SADT kërkon rigorozitet dhe saktësi të mjaftueshme pa vendosur kufizime të panevojshme mbi veprimet e analistit.

Rregullat e SADT përfshijnë:

♦ kufizimi i numrit të blloqeve në çdo nivel dekompozimi (rregulli i blloqeve 3-b);

♦ lidhje e diagrameve (numrat e blloqeve);

♦ veçanti e etiketave dhe emrave (mungesë e emrave të dyfishtë);

♦ rregulla sintaksore për grafikë (blloqe dhe harqe);

♦ ndarje e hyrjeve dhe kontrolleve (rregulli për përcaktimin e rolit të të dhënave);

♦ ndarja e organizatës nga funksioni, pra, përjashtimi i ndikimit të strukturës organizative në modelin funksional.

Metodologjia SADT mund të përdoret për të modeluar një gamë të gjerë sistemesh dhe për të përcaktuar kërkesat dhe funksionet, dhe më pas për të hartuar një sistem që i plotëson ato kërkesa dhe i zbaton ato funksione. Për tashmë sistemet ekzistuese SADT mund të përdoret për të analizuar funksionet e kryera nga sistemi, si dhe për të treguar mekanizmat përmes të cilëve ato kryhen.

Rezultati i aplikimit të metodologjisë SADT është një model që përbëhet nga diagrame, fragmente teksti dhe një fjalor që kanë lidhje me njëri-tjetrin. Diagramet janë komponentët kryesorë të modelit, të gjitha funksionet dhe ndërfaqet IS janë paraqitur si blloqe dhe harqe. Pika e lidhjes së harkut me bllokun përcakton llojin e ndërfaqes. Informacioni i kontrollit hyn në bllok nga lart, ndërsa informacioni që përpunohet shfaqet në anën e majtë të bllokut dhe rezultatet e daljes shfaqen në anën e djathtë. Mekanizmi (sistemi njerëzor ose i automatizuar) që kryen operacionin përfaqësohet nga një hark që hyn në bllok nga poshtë (Fig. 1.6.1).

Një nga karakteristikat më të rëndësishme të metodologjisë SADT është futja graduale e niveleve në rritje të detajeve ndërsa krijohen diagramet që përfaqësojnë modelin.

Ndërtimi i modelit SADT fillon me paraqitjen e të gjithë sistemit në formën e komponentit më të thjeshtë - një bllok dhe harqe që përfaqësojnë ndërfaqe me funksione jashtë sistemit. Për shkak se një bllok i vetëm përfaqëson të gjithë sistemin në tërësi, emri i dhënë në bllok është i përgjithshëm. Kjo është gjithashtu e vërtetë për harqet e ndërfaqes - ato përfaqësojnë gjithashtu grupin e plotë të ndërfaqeve të jashtme të sistemit në tërësi.

Pastaj blloku që përfaqëson sistemin si një modul i vetëm detajohet në një diagram tjetër duke përdorur disa blloqe të lidhura me harqe ndërfaqe. Këto blloqe përfaqësojnë nënfunksionet kryesore të funksionit origjinal. Ky zbërthim zbulon një grup të plotë nënfunksionesh, secila prej të cilave përfaqësohet si një bllok, kufijtë e të cilit përcaktohen nga harqet e ndërfaqes. Secili prej këtyre nënfunksioneve mund të zbërthehet në një mënyrë të ngjashme për një pamje më të detajuar.

Në të gjitha rastet, çdo nënfunksion mund të përmbajë vetëm ato elemente që përfshihen në funksioni origjinal. Për më tepër, modeli nuk mund të heqë asnjë element, d.m.th., siç u përmend tashmë, i ashtuquajturi blloku prind dhe ndërfaqet e tij ofrojnë kontekst. Asgjë nuk mund t'i shtohet dhe asgjë nuk mund të hiqet prej saj.

Modeli SADT është një seri diagramesh me dokumentacion shoqërues që prishen objekt kompleks në pjesë përbërëse, të cilat paraqiten në formën e blloqeve. Detajet e secilit prej blloqeve kryesore tregohen si blloqe në diagrame të tjera. Në çdo hap të dekompozimit, diagrami më i përgjithshëm quhet prind i diagramit më të detajuar.

Harqet që hyjnë dhe dalin nga kutia në diagramin e nivelit të lartë janë saktësisht të njëjta me harqet që hyjnë në diagram nivel më të ulët dhe duke dalë prej tij, sepse blloku dhe diagrami përfaqësojnë të njëjtën pjesë të sistemit.

Disa harqe janë bashkangjitur në blloqet e diagramit në të dy skajet, ndërsa të tjerët kanë një skaj të mbetur pa lidhje. Harqet e palidhur korrespondojnë me hyrjet, kontrollet dhe daljet e bllokut prind. Burimi ose destinacioni i këtyre harqeve kufitare mund të gjendet vetëm në diagramin mëmë. Skajet e lirshme duhet të përputhen me harqet grafiku origjinal. Të gjithë harqet e kufirit duhet të vazhdojnë në diagramin prind që ai të jetë i plotë dhe konsistent.

Diagramet SADT nuk tregojnë në mënyrë të qartë as sekuencën dhe as kohën. Reagimet, përsëritjet, proceset e vazhdueshme dhe funksionet e mbivendosura (në kohë) mund të përshkruhen duke përdorur harqe. Reagimet mund të jenë në formën e komenteve, vërejtjeve, korrigjimeve, etj.

Siç u përmend, mekanizmat (harqet në pjesën e poshtme) tregojnë mjetet me të cilat kryhen funksionet. Mekanizmi mund të jetë një njeri, një kompjuter ose çdo pajisje tjetër që ndihmon në kryerjen e një funksioni të caktuar.

Çdo bllok në diagram ka numrin e vet. Një bllok i çdo diagrami mund të përshkruhet më tej nga një diagram i nivelit më të ulët, i cili, nga ana tjetër, mund të detajohet më tej me numrin e kërkuar të diagrameve. Kështu, formohet një hierarki diagramesh. Për të treguar pozicionin e çdo diagrami ose blloku në hierarki, përdoren numrat e diagramit.

Modelimi i rrjedhave të të dhënave (proceseve)

Mjeti kryesor i simulimit kërkesat funksionale AIS janë diagrame të rrjedhës së të dhënave (DFD:- Diagramet e rrjedhës së të dhënave). Me ndihmën e tyre, këto kërkesa zbërthehen në komponentë (procese) funksionale dhe paraqiten si një rrjet i lidhur nga rrjedhat e të dhënave. objektivi kryesor mjete të tilla janë për të demonstruar se si çdo proces i transformon inputet e tij në outpute dhe për të identifikuar marrëdhëniet ndërmjet këtyre proceseve.

Në përputhje me metodologjinë, modeli i sistemit përkufizohet si një hierarki e diagrameve të rrjedhës së të dhënave (DFD, ose DFD) që përshkruajnë procesin asinkron të transformimit të informacionit nga futja e tij në sistem deri në lëshimin e tij tek përdoruesi. Diagramet e niveleve të sipërme të hierarkisë (diagramet e kontekstit) përcaktojnë proceset ose nënsistemet kryesore të IS me hyrje dhe dalje të jashtme. Ato janë të detajuara duke përdorur diagrame të nivelit më të ulët. Ky zbërthim vazhdon, duke krijuar një hierarki me shumë nivele të diagrameve, derisa të arrihet një nivel i tillë zbërthimi në të cilin proceset bëhen elementare dhe është e pamundur të detajohen më tej.

Burimet e informacionit (entitetet e jashtme) gjenerojnë flukse informacioni (flukse të dhënash) që transferojnë informacionin në nënsisteme ose procese. Ata, nga ana tjetër, transformojnë informacionin dhe gjenerojnë flukse të reja që transferojnë informacion në procese ose nënsisteme të tjera, akumulues të dhënash ose subjekte të jashtme - konsumatorë të informacionit. Kështu, përbërësit kryesorë të diagrameve të rrjedhës së të dhënave janë:

♦ entitete të jashtme;

♦ sisteme/nënsisteme;

♦ procese;

♦ pajisje për ruajtjen e të dhënave;

♦ rrjedha e të dhënave.

Një ent i jashtëm është një objekt material ose individual A që përfaqëson burimin ose destinacionin e informacionit, siç janë klientët, personeli, furnitorët, klientët, depoja. Përkufizimi i një objekti ose sistemi si një entitet i jashtëm tregon se ai është jashtë kufijve të AIS-it të analizuar.

Procesi është shndërrimi i rrjedhave të të dhënave hyrëse në ato dalëse në përputhje me një algoritëm të caktuar. Fizikisht, procesi mund të zbatohet në mënyra të ndryshme: mund të jetë një nënndarje e një organizate (departamenti) që përpunon dokumentet hyrëse dhe nxjerr raporte, një program, një pajisje logjike e implementuar në harduer, etj. Në shënime të ndryshme, procesi mund të jetë të paraqitura në diagrame në mënyra të ndryshme. Numri i procesit përdoret për ta identifikuar atë. Në fushën e emrit, emri i procesit futet si një fjali me një folje aktive të paqartë në formën e pacaktuar (llogarit, llogarit, kontrolloni, përcaktoni, krijoni, merrni), e ndjekur nga emrat në rasën kallëzore, për shembull:

♦ "Fut informacione për klientët";

♦ “Jepni informacion për shpenzimet aktuale”;

♦ "Kontrollo kreditueshmërinë e klientit".

Përdorimi i foljeve të tilla si "përpunoj", "modernizoj" ose "redakto" zakonisht do të thotë se nuk ka kuptim të mjaftueshëm të thellë të këtij procesi dhe kërkon analiza të mëtejshme.

AT kohët e funditështë gjithashtu zakon të përdoret fusha e zbatimit fizik, informacioni në të cilin tregon se cili departament i organizatës, programit ose pajisjes harduerike kryen këtë proces.

Magazinimi (disku i të dhënave) është një pajisje abstrakte për ruajtjen e informacionit që mund të vendoset në disk në çdo kohë dhe të merret pas njëfarë kohe, dhe metodat e vendosjes dhe marrjes mund të jenë të gjitha.

Pajisja e ruajtjes së të dhënave mund të zbatohet fizikisht në formën e një mikrofiche, një sirtar në një kabinet skedarësh, një tabelë në RAM, një skedar në media magnetike etj. Disku i të dhënave identifikohet me shkronjën "D" dhe një numër arbitrar. Emri i diskut zgjidhet nga pikëpamja e përmbajtjes më të madhe të informacionit për projektuesin.

Disku i të dhënave është përgjithësisht një prototip i bazës së të dhënave të ardhshme dhe përshkrimi i të dhënave të ruajtura në të duhet të lidhet me modelin e informacionit. Rrjedha e të dhënave përcakton informacionin e transmetuar përmes një lidhjeje nga burimi te marrësi. Rrjedha aktuale e të dhënave mund të jetë informacioni i transmetuar përmes një kablloje midis dy pajisjeve, të dërguara me letra postare, shirita magnetikë ose disqe, të transferuara nga një kompjuter në tjetrin, etj.

Rrjedha e të dhënave në diagram përfaqësohet nga një vijë që përfundon me një shigjetë që tregon drejtimin. Çdo rrjedhë e të dhënave ka një emër që pasqyron përmbajtjen e tij.

Hapi i parë në ndërtimin e një hierarkie DFD është ndërtimi i diagrameve të kontekstit. Në mënyrë tipike, kur projektohet AIS relativisht i thjeshtë, ndërtohet një diagram i vetëm konteksti me një topologji ylli, në qendër të të cilit është i ashtuquajturi procesi kryesor, i lidhur me marrës dhe burime informacioni përmes të cilave përdoruesit dhe të tjerët ndërveprojnë me sistemin. sistemet e jashtme. Për AIS komplekse, ndërtohet një hierarki e diagrameve të kontekstit. Në të njëjtën kohë, diagrami i kontekstit të nivelit të lartë nuk përmban një proces të vetëm kryesor, por një grup nënsistemesh të lidhura nga rrjedhat e të dhënave. Diagramet e kontekstit të nivelit tjetër detajojnë kontekstin dhe strukturën e nënsistemeve.

Hierarkia e diagrameve të kontekstit përcakton ndërveprimin e kryesore nënsistemet funksionale projektuar AIS si ndërmjet tyre ashtu edhe me rrjedhat e jashtme të të dhënave hyrëse dhe dalëse dhe objektet e jashtme (burimet dhe marrësit e informacionit) me të cilët AIS ndërvepron.

Zhvillimi i diagrameve të kontekstit zgjidh problemin e përcaktimit të rreptë të strukturës funksionale të AIS në fazën më të hershme të projektimit të tij, i cili është veçanërisht i rëndësishëm për sistemet komplekse multifunksionale, në zhvillimin e të cilave organizata të ndryshme dhe ekipet e zhvillimit.

Pas ndërtimit të diagrameve të kontekstit, modeli që rezulton duhet të kontrollohet për plotësinë e të dhënave fillestare mbi objektet e sistemit dhe izolimin e objekteve (mungesa e lidhjeve të informacionit me objekte të tjera). Për çdo nënsistem të pranishëm në diagramet e kontekstit, ai detajohet duke përdorur DFD. Çdo proces në një DFD, nga ana tjetër, mund të detajohet duke përdorur një DFD ose një mini-specifikim. Gjatë detajimit, duhet të ndiqen rregullat e mëposhtme:

♦ Rregull balancimi - do të thotë që kur detajohet një nënsistem ose proces, diagrami detajues si burime/marrëse të jashtme të të dhënave mund të ketë vetëm ata komponentë (nënsisteme, procese, entitete të jashtme, akumulatorë të dhënash) me të cilët nënsistemi ose procesi i detajuar në diagramin mëmë ka lidhje informative;

♦ Rregulli i numërimit - do të thotë që gjatë detajimit të proceseve, duhet të mbështetet numërimi i tyre hierarkik. Për shembull, proceseve që detajojnë procesin numër 12 u caktohen numrat 12.1, 12.2, 12.3, e kështu me radhë.

Mini-specifikimi (përshkrimi i logjikës së procesit) duhet të formulojë funksionet e tij kryesore në atë mënyrë që në të ardhmen specialisti që zbaton projektin t'i kryejë ato ose të zhvillojë një program të përshtatshëm.

Mini-specifikimi është maja përfundimtare e hierarkisë DFD. Vendimi për të përfunduar detajet e procesit dhe përdorimin e mini-specifikimeve merret nga analisti bazuar në kriteret e mëposhtme:

♦ procesi ka një numër relativisht të vogël të të dhënave hyrëse dhe dalëse (2-3 rrjedha);

♦ mundësia e përshkrimit të transformimit të të dhënave nga një proces në formë algoritmi sekuencial;

♦ ekzekutimi me anë të procesit të funksionit të vetëm logjik të shndërrimit të informacionit hyrës në informacion dalës;

♦ mundësia e përshkrimit të logjikës së procesit duke përdorur një mini-specifikim të një vëllimi të vogël (jo më shumë se 20-30 rreshta).

Kur ndërtohet një hierarki DFD, duhet të vazhdohet me detajimin e proceseve vetëm pasi të përcaktohet përmbajtja e të gjitha flukseve dhe ruajtjes së të dhënave, e cila përshkruhet duke përdorur strukturat e të dhënave. Strukturat e të dhënave janë ndërtuar nga elementë të të dhënave dhe mund të përmbajnë alternativa, kushte dhe përsëritje. Ndodhja e kushtëzuar do të thotë që ky komponent mund të mos jetë i pranishëm në strukturë. Alternativa do të thotë që një nga elementët e listuar mund të përfshihet në strukturë. Përsëritja nënkupton futjen e çdo numri elementësh në diapazonin e specifikuar. Për çdo element të dhënash, mund të specifikohet lloji i tij (të dhëna të vazhdueshme ose diskrete). Për të dhëna të vazhdueshme, mund të specifikohet njësia e matjes (kg, cm, etj.), diapazoni i vlerave, saktësia e paraqitjes dhe forma e kodimit fizik. Për të dhëna diskrete, mund të specifikohet një tabelë vlerat e lejuara.

Pas ndërtimit të një modeli të plotë të sistemit, ai duhet të verifikohet. Në një model të plotë, të gjitha objektet e tij (nënsistemet, proceset, rrjedhat e të dhënave) duhet të përshkruhen dhe detajohen në detaje. Objektet jo të detajuara të identifikuara duhet të detajohen duke u kthyer në hapat e mëparshëm të zhvillimit. Në një model të qëndrueshëm, të gjitha rrjedhat e të dhënave dhe depozitat e të dhënave duhet t'i binden rregullit të ruajtjes së informacionit: të gjitha të dhënat që vijnë diku duhet të lexohen dhe të gjitha të dhënat e lexuara duhet të shkruhen.

Modelimi i të dhënave

Qëllimi i modelimit të të dhënave është t'i sigurojë zhvilluesit të AIS një skemë konceptuale të bazës së të dhënave në formën e një ose më shumë modeleve. modelet lokale, të cilat mund të hartohen relativisht lehtë në çdo sistem bazë të dhënash.

Mjeti më i zakonshëm i modelimit të të dhënave është Diagramet e Marrëdhënieve me Entitet (ERD). Me ndihmën e tyre, përcaktohen objekte (entitete) të rëndësishme për fushën lëndore, vetitë (atributet) e tyre dhe marrëdhëniet me njëri-tjetrin (lidhjet). ERD-të përdoren drejtpërdrejt për të dizajnuar bazat e të dhënave relacionale (shih seksionin 2.2).

Shënimi ERD u prezantua për herë të parë nga P. Chen dhe u zhvillua më tej nga Barker.

Metodologjia IDEF 1

Metoda IDEF1, e zhvilluar nga T. Ramey, bazohet gjithashtu në qasjen e P. Chen dhe ju lejon të ndërtoni një model të dhënash ekuivalent me një model relacional në formën e tretë normale. Aktualisht, bazuar në përmirësimin e metodologjisë IDEF1, ajo një version të ri- Metodologjia IDEF1X. IDEF1X është projektuar duke pasur parasysh lehtësinë e të mësuarit dhe automatizimin. Diagramet IDEF IX përdoren nga një sërë veglash të zakonshme CASE (p.sh. ERWin, Design/IDEF).

Referencat

Fedotova D.E. RASTI - teknologjitë: tekst shkollor - M: Linja telefonike - Telekom, 2007

Trofimov V.E., Lobacheva I.N. Sistemet e informacionit në ekonomi - M: Unity-Dana, 2008

· Baldin N.V., Utkin V.B. Sistemet dhe teknologjitë e informacionit në ekonomi - M: Unity, 2007

Titorenko T.A. Teknologjitë e automatizuara të informacionit në ekonomi - M: Unity, 2006

Baranovskaya T.P., Loiko V.I., Semenov M.I., Trubilin I.T. Teknologjitë e automatizuara të informacionit në ekonomi - M: Financa dhe statistika, 2006

1.3.1. Kërkesat e përgjithshme për metodologjinë dhe teknologjinë

Metodologjitë, teknologjitë dhe mjetet e projektimit (CASE-tools) përbëjnë bazën e çdo projekti IS. Metodologjia zbatohet përmes teknologjive specifike dhe standardeve, metodologjive dhe mjeteve mbështetëse të tyre që sigurojnë zbatimin e proceseve të ciklit jetësor.

Teknologjia e projektimit përkufizohet si një kombinim i tre komponentëve:

• një procedurë hap pas hapi që përcakton sekuencën e operacioneve të projektimit teknologjik (Fig. 1.4);
• kriteret dhe rregullat e përdorura për të vlerësuar rezultatet e operacioneve teknologjike;
• shënimet (grafike dhe mjetet e tekstit) përdoret për të përshkruar sistemin që po projektohet.

Oriz. 1.4. Përfaqësimi i funksionimit teknologjik të projektimit

Udhëzimet teknologjike, të cilat përbëjnë përmbajtjen kryesore të teknologjisë, duhet të përbëhen nga një përshkrim i sekuencës së operacioneve teknologjike, kushteve në varësi të të cilave kryhet një ose një tjetër operacion dhe përshkrimet e vetë operacioneve.

Teknologjia për projektimin, zhvillimin dhe mirëmbajtjen e IS duhet të plotësojë kërkesat e përgjithshme të mëposhtme:

• teknologjia duhet të mbështesë ciklin e plotë të jetës së softuerit;
• teknologjia duhet të sigurojë arritjen e garantuar të qëllimeve të zhvillimit të SI me një cilësi të caktuar dhe në një kohë të caktuar;
• teknologjia duhet të ofrojë mundësinë e kryerjes së projekteve të mëdha në formën e nënsistemeve (dmth. mundësinë e zbërthimit të projektit në pjesë përbërëse të zhvilluara nga grupe interpretuesish të një numri të kufizuar me integrimin e mëvonshëm të pjesëve përbërëse). Përvoja e zhvillimit të IS të madh tregon se për të rritur efikasitetin e punës, është e nevojshme të ndahet projekti në nënsisteme të veçanta që janë të lidhura dobët për sa i përket të dhënave dhe funksioneve. Zbatimi i nënsistemeve duhet të kryhet nga grupe të veçanta specialistësh. Në të njëjtën kohë, është e nevojshme të sigurohet koordinimi i projektit të përgjithshëm dhe të përjashtohet dyfishimi i rezultateve të punës së secilit grup të projektit, që mund të lindin për shkak të pranisë së të dhënave dhe funksioneve të përbashkëta;
• teknologjia duhet të sigurojë mundësinë e kryerjes së punës për hartimin e nënsistemeve individuale në grupe të vogla (3-7 persona). Kjo është për shkak të parimeve të menaxhimit të ekipit dhe rritjes së produktivitetit duke minimizuar numrin e lidhjeve të jashtme;
• teknologjia duhet të sigurojë kohën minimale për marrjen e një IS të zbatueshëm. Kjo nuk ka të bëjë me kohën e gatishmërisë së të gjithë IS, por me kohën e zbatimit të nënsistemeve individuale. Zbatimi i IP në përgjithësi në një kohë të shkurtër mund të kërkojë përfshirjen e një numër i madh zhvilluesit, ndërsa efekti mund të jetë më i ulët se kur nënsistemet individuale zbatohen në një kohë më të shkurtër nga një numër më i vogël zhvilluesish. Praktika tregon se edhe në prani të një projekti plotësisht të përfunduar, zbatimi vazhdon në mënyrë konsistente për nënsistemet individuale;
• teknologjia duhet të sigurojë mundësinë e menaxhimit të konfigurimit të projektit, ruajtjen e versioneve të projektit dhe përbërësve të tij, mundësinë e lëshimit automatik të dokumentacionit të projektit dhe sinkronizimit të versioneve të tij me versionet e projektit;
• teknologjia duhet të sigurojë pavarësinë e zgjidhjeve të projektimit të ekzekutuara nga mjetet e zbatimit të IS (sistemet e menaxhimit të bazës së të dhënave (DBMS), sistemet operative, gjuhët dhe sistemet e programimit);
• teknologjia duhet të mbështetet nga një grup mjetesh CASE të koordinuara që ofrojnë automatizimin e proceseve të kryera në të gjitha fazat e ciklit jetësor. Qasje e Përgjithshme për vlerësimin dhe përzgjedhjen e mjeteve CASE është përshkruar në seksionin 4, shembuj të komplekseve të mjeteve CASE - në seksionin 5.7.

Aplikimi real i çdo teknologjie për projektimin, zhvillimin dhe mirëmbajtjen e IS në një organizatë të caktuar dhe një projekt të caktuar është i pamundur pa zhvillimin e një numri standardesh (rregullash, marrëveshjesh) që duhet të respektohen nga të gjithë pjesëmarrësit e projektit. Këto standarde përfshijnë sa vijon:

• standardi i projektimit;
• standardi i dokumentacionit të projektimit;
• standardi i ndërfaqes së përdoruesit.

Standardi i projektimit duhet të thotë:

• komplet modelet e nevojshme(diagramet) në çdo fazë të projektimit dhe niveli i tyre i detajimit;
• rregullat për fiksimin e vendimeve të projektimit në diagrame, duke përfshirë: rregullat e emërtimit për objektet (përfshirë konventat e terminologjisë), një grup atributesh për të gjitha objektet dhe rregulla për plotësimin e tyre në çdo fazë, rregullat e projektimit të diagramit, duke përfshirë kërkesat për formën dhe madhësinë e objekteve etj.;
• kërkesat për konfigurimin e stacioneve të punës së zhvilluesit, duke përfshirë cilësimet sistemi operativ, cilësimet e mjetit CASE, Cilësimet e përgjithshme projekt etj.;
• një mekanizëm për sigurimin e punës së përbashkët në një projekt, duke përfshirë: rregullat për integrimin e nënsistemeve të projektit, rregullat për mbajtjen e një projekti në të njëjtën gjendje për të gjithë zhvilluesit (rregulloret për shkëmbimin e informacionit të projektit, një mekanizëm për fiksimin e objekteve të përbashkëta, etj.), rregullat për kontrollin e konsistencës së vendimeve të projektimit, etj. d.

Standardi i dokumentacionit të projektimit duhet të përcaktojë:

• plotësinë, përbërjen dhe strukturën e dokumentacionit në çdo fazë të projektimit;
• kërkesat për hartimin e tij (përfshirë kërkesat për përmbajtjen e seksioneve, nënseksioneve, paragrafëve, tabelave, etj.),
• rregullat për përgatitjen, shqyrtimin, miratimin dhe miratimin e dokumentacionit, duke treguar afatet për çdo fazë;
• kërkesat për ngritjen e një sistemi publikimi që përdoret si një mjet për përgatitjen e dokumentacionit të integruar;
• kërkesat për personalizimin e mjeteve CASE për të siguruar përgatitjen e dokumentacionit në përputhje me kërkesat e përcaktuara.

Standardi i ndërfaqes së përdoruesit duhet të tregojë:

• rregullat e dizajnit të ekranit (fontet dhe paleta e ngjyrave), kompozimi dhe rregullimi i dritareve dhe kontrolleve;
• rregullat për përdorimin e tastierës dhe miut;
• rregullat për formatimin e teksteve ndihmëse;
• lista e mesazheve standarde;
• rregullat e përpunimit të reagimit të përdoruesit.

CASE-mjete për dizajnimin e sistemeve të informacionit

Në kushtet moderne, kompleksiteti i krijimit të sistemeve të informacionit është shumë i lartë. Prandaj, në hartimin e IC-ve, teknologjia CASE tani është bërë gjerësisht e përdorur.

Teknologjia CASE është një paketë softuerike që automatizon të gjithë procesin teknologjik të analizës, projektimit, zhvillimit dhe mirëmbajtjes së mjeteve komplekse softuerike.

Mjetet moderne CASE mbulojnë një gamë të gjerë mbështetjeje për shumë teknologji të projektimit IC: nga mjete të thjeshta analiza dhe dokumentacion për mjetet e automatizimit në shkallë të plotë që mbulojnë të gjithë ciklin e jetës së softuerit.

Fazat që kërkojnë më shumë kohë të zhvillimit të SI-së janë fazat e analizës dhe projektimit, gjatë të cilave CASE-tools ofrojnë zgjidhje teknike me cilësi të lartë dhe përgatitjen e dokumentacionit të projektit. Në të njëjtën kohë, mjetet e modelimit të domenit grafik luajnë një rol të rëndësishëm, të cilat lejojnë zhvilluesit të studiojnë vizualisht IS ekzistues, ta rindërtojnë atë në përputhje me qëllimet dhe kufizimet ekzistuese.

Mjetet e integruara CASE kanë sa vijon tipare karakteristike :

· Sigurimi i menaxhimit të procesit të zhvillimit të SI;

Përdorimi i një depoje të organizuar posaçërisht të meta të dhënave të projektit (depo).

Mjetet e integruara CASE përmbajnë komponentët e mëposhtëm:

· Analiza grafike dhe mjetet e projektimit të përdorura për të përshkruar dhe dokumentuar IS;

Mjetet e zhvillimit të aplikacioneve, duke përfshirë gjuhët e programimit dhe gjeneruesit e kodeve;

një depo që siguron ruajtjen e versioneve të projektit në zhvillim dhe komponentëve të tij individualë, sinkronizimin e informacionit të marrë nga zhvillues të ndryshëm gjatë zhvillimit të grupit, kontrollin e meta të dhënave për plotësinë dhe qëndrueshmërinë;

· mjetet e menaxhimit për zhvillimin e IS;

mjetet e dokumentacionit;

mjete testimi;

Mjetet e riinxhinierimit që ofrojnë analiza të kodeve të programit dhe skemave të bazës së të dhënave dhe formimin mbi bazën e tyre modele te ndryshme dhe specifikimet e projektimit.

Të gjitha mjetet moderne CASE ndahen në dy grupe. grupi i parë organizoni mjete të integruara në sistemin e zbatimit, në të cilin të gjitha vendimet e projektimit dhe zbatimit janë të lidhura me sistemin e zgjedhur të menaxhimit të bazës së të dhënave. grupi i dytë organizoni mjete të pavarura nga sistemi i zbatimit, në të cilin të gjitha vendimet e projektimit fokusohen në unifikimin fazat fillestare ciklin jetësor dhe mjetet e dokumentimit të tyre. Këto mjete ofrojnë fleksibilitet më të madh në zgjedhjen e mjeteve të zbatimit.

Kryesor dinjitet CASE-technologies - mbështetje për punën ekipore në një projekt për shkak të aftësisë për të punuar në rrjet lokal, eksporti dhe importi i fragmenteve të projektit individual ndërmjet zhvilluesve, organizimi i menaxhimit të projektit.

Si fazat duke krijuar produkte softuerike për sistemet e informacionit, mund të dallohen këto:

1. Përcaktohet mjedisi i funksionimit. Në këtë fazë, përcaktohet një grup i proceseve të ciklit jetësor të IS, përcaktohet shtrirja e IS, përcaktohet madhësia e aplikacioneve të mbështetura, d.m.th. kufizimet vendosen në vlera të tilla si numri i rreshtave të kodit të programit, madhësia e bazës së të dhënave, numri i elementeve të të dhënave, numri i objekteve të kontrollit, etj.

2. Grafikët po ndërtohen dhe analiza grafike. Në këtë fazë, ndërtohen diagrame që krijojnë një lidhje me burimet e informacionit dhe konsumatorët, përcaktojnë proceset e transformimit të të dhënave dhe vendndodhjet e ruajtjes së tyre.

3. Përcaktohen specifikimet dhe kërkesat për sistemin (lloji i ndërfaqes, lloji i të dhënave, struktura e sistemit, cilësia, performanca, mjetet teknike, kostot totale etj.).

4. Kryhet modelimi i të dhënave, d.m.th. futet informacion që përshkruan elementet e të dhënave të sistemit dhe marrëdhëniet e tyre.

5. Kryhet modelimi i procesit, d.m.th. paraqitet informacion që përshkruan proceset e sistemit dhe marrëdhëniet e tyre.