Projektavimas

Tema	Informatika
Tipas	Konspektas
Aprašymas	Funkciškai orientuotas projektavimas yra programinės įrangos projektavimo būdas, kuriame projektavimas yra suskaidytas į sąveikaujančių modulių aibę, kurių kiekvienas turi aiškiai apibrėžtas funkcijas. Funkcijos yra lokalaus būvio, bet paskirstytos sistemos būsena yra centralizuota ir yra pasiekiama visoms funkcijoms.
Patalpinta	2005-08-18
Parsisiuntė	1140
	Parsisiųsti9 KB

Išsamus aprašymas

Anksčiau buvo manoma, jog funkciškai orientuotas projektavimas yra pasenęs ir gali būti pakeistas objektiškai orientuotu projektavimu. Tačiau daug organizacijų buvo išvystę metodus ir standartus, pagrįstus funkcine dekompozicija ir todėl nenorėjo pripažinti palankumo objektiškai orientuotam projektavimui. Naudojant funkcinį metodą buvo sukurta daug sistemų. Todėl funkcinis projektavimas yra ir bus plačiai praktikuojamas.
Šio metodo strategija leidžia išskaidyti sistemą į aibę sąveikaujančių funkcijų su centralizuota sistemos būsena, paskirstyta šių funkcijų.
Funkciškai orientuotas projektavimas paslepia algoritmo detales funkcijose, bet sistemos būsenos informacija nėra paslėpta. Tai gali sukelti problemų, nes funkcija gali pakeisti būseną taip, kaip nesitiki kitos funkcijos. Funkcijų pakeitimai ir tai, kaip jos naudoja sistemos būseną, gali sukelti nenumatytą sąveiką su kitom funkcijom. Todól funkcinio projektavimo būdas yra labiausiai vykęs, kuomet sistemos būsenos apimtis yra minimizuota ir informacijos paskirstymas yra apibrėžtas.
Duomenų srauto diagramos
Duomenų srauto diagramos rodo kaip įvesti duomenys yra transformuojami rezultatų išvedimui per eilę funkcinių transformacijų. Diagramos - intuityvus ir naudingas kelias aprašant sistemą, bet jos nesuprantamos be papildomo mokymosi. Pirmas funkciškai orientuoto projektavimo etapas turėtų būti sukurti, vystyti sistemos srautų diagramas. Šios diagramos paprastai neįtraukia valdymo informacijos, bet jos gali dokumentuoti duomenų transformacijas.
Duomenų srauto diagramos yra projektavimo metodų sudedamoji dalis ir CASE priemonės paprastai palaiko duomenų srauto diagramų kūrimą. Žymėjimai, naudojami skirtinguose metoduose, yra panašūs ir perėjimas nuo vieno žymėjimo prie kito yra tiesioginis. Čia naudojama žymėjimų sistema buvo pasirinkta todėl, kad ji tinka piešti naudojant PC diagramų redagavimo sistemą.
Šioje žymėjimo sistemoje naudojami simboliai reiškia :
1.Apvalių kampų stačiakampiai.
Jie vaizduoja transformacijas, kuriose įvedimo duomenų srautas yra transformuojamas į išvedimo. Transformacija yra anotuojama ( užrašoma ) apibrėžimo vardu. 2.Stačiakampiai.
Vaizduoja duomenų talpą ( dydį ). Užrašomi apibrėžimo vardu. 3.Apskritimai.
Vaizduoja vartotojo santykį su sistema. Šie santykiai gali palaikyti įvedimą ar gauti išvedimą. 4.Rodyklės.
Rodo duomenų srauto kryptį. Jos gauna vardą, apibrėžiantį duomenis, kurie "teka" nurodyta kryptimi. 5.Raktiniai žodżiai 'and' ir 'or'.
Čia jie turi įprastines reikšmes, kaip ir loginėse išraiškose. Jie naudojami sujungti duomenų srautus, kuomet daugiau nei vienas srautas gali būti įvestas ar išvestas iš transformacijos. 6.Lanko simbolis, jungiantis duomenų srautus.
Jis naudojamas tik konjunkcijoje su 'and' ir 'or', ir naudojami indikuoti skliaustus. Iš esmės 'and' turi prioritetą prieš 'or', bet tai gali būti pakeista, sujungiant tinkamus duomenų srautus.
Žymėjimo sistema iliustruota paveiksle 12.3. Ji aprašo ataskaitų generatoriaus sistemos, naudojamos konjunkcijoje kartu su projektavimo redaktoriumi, loginį projektavimą.
Ataskaitų generatorius priima projektavimą ir pagamina ataskaitą apie kiekvieną objektą, naudojamą projektavime. Vartotojas įveda projekto vardą ir ataskaitų generatorius randa visus vardus, naudojamus šiame projektavime. Duomenų žodynas suteikia informacijos apie projektavimo objektus ir daromas ataskaitas. Informacija ataskaitoje yra pateikiama pagal tai, kuris iš dviejų objektų yra mazgo tipo ar jungties tipo.
Duomenų srautų diagramų nauda yra ta, kad jos rodo transformacijas, nedarydamos prielaidų kaip tos transformacijos realizuotos. Pvz., taip apibrėžta sistema gali būti realizuota kaip atskira programa, naudojanti programinius modulius tam, kad realizuoti kiekvienątransformaciją. Ir atvirkščiai, tai gali būti realizuota kaip skaičius susisiekiančių uždavinių arba, galbūt, realizacija gali būti šių metodų sujungimas.
2.Funkcinis projektavimas
Funkcinis projektavimas yra programų sudarymo metodas, kai programasusideda iš aibės tarpusavyje bendaujančių vienetų, kurie turi tiksliai apibrėžtą funkciją. Funkcujos turi lokalų būvį, bet padlintas sistemos būvis yra centralizuotas ir prieinamas visoms funkcijoms.
Funkcinis projektavimas buvo naudojamas nuo tada, kai prasidėjo programavimas. Bet tik šešto dešimtmečio gale septinto dešimtmečio pradžioje išgarsėjo. Daugelis laikraščių ir knygų, iš kurių labiausiai žinomos Virto (1971, 1976) Buvo publikuota būtent šio metodo pagrindu.
Buvo teigta, kad funkcinis projektavimas yra pasenęs ir turi būti pakeistas objektiškai orientuoto priėjimo. Tačiau daug organizacijų išvystė standartus, pagrįstus funkcine dekompozicija. Daug projektavimo priemonių ir susiję CASE įrankiai yra funkciškai orientuoti. Todėl funkcinis projektavimas turi būti pačiai taikomas.
Funkicinis projektavimas naudoja duomenų srautų diagramas, kurios aprašo loginių duomenų apdorojimą, struktūrų diagramų, kurios parodo programinės įrangos struktūrą ir PDL aprašymą, kuris aprašo detaliai projektavimą. Duomenų srautų žymėjimo sistema buvo modifikuota, kad padaryti ją labiau tinkama automatizuoto diagramų sudarymo sistemos naudojimui, ir yra naudojama truputi skirtinga struktūros diagramų forma, kuri neįtraukia valdymo informacijos.
Funkcinio programų projektavimo strategija pasikliauna sistemos dekompozicija į aibę iteraktyvių funkcijų.Funkcijos galipalaikyti lokalios būsenos informaciją, bet tik jų vykdymo metu. Funkcinis projektavimas paslepia algoritmo detales savyje, bet sistemos būsenos informacija nėra slepiama. Tai gali sukelti problemų, nes funkcija gali pakeisti būvi tokiu būdu, kokio kitos funkcijos nenumato. Pakeitimai funkcijoje ir būdas, kuruo jos naudoja sistemos būseną gali sukelti nenumatytų sąveikų su kitomis funkcijomis.
Funkcinis projektavimas vis dėl to yra sekmingiausias kai sistemos būvio informacijos gausa yra minimizuojama ir informacijos dalijimas yra apibrėžtas. Kai kurios sistemos, kurios reaguoja į pavienius poveikius ar duomenų įvedimą ir nereaguoja į įvedimo istoriją, yra funkciškai orientuotos. Geras tokios sistemos pavyzdys yra ATM sistema.
Šiame projektavime funkijos gali būti identifikuojamos taip, kad įvykdytų sisteminius veiksmus. Sistemos būvis yra minimalus. Operacijos yra nepriklausomos ir nereaguoja į anksesnes vartotojo užklausas. Iš tikrųjų objektiškai orientuotas projektavimas negali labai skirtis nuo šio (išskyrus sintaksiškai) ir objektiškai orientuotas priėjimas tursbūt nesibaigia vien projektavimu
Duomenų srautų diagramos
Duomenų srautų diagramos parodo kaip įvedami duomenys yra transormuojami į išvadamus rezultatus per eilę funkcinių transformacijų. Jos yra naudingas ir intuitvus sistemos aptanavimo būdas, be to diagramos suprantamos be specialių žinių. Pirma funkcinio projektavimo stadija turi sukurti sisteminių duomenų srautų diagramas. Šios diagramos neturi normaliai įtraukti valdymo informacijos, bet turi dokumentuoti duomenų transformacijas. Duomenų srautų diagramos yra sudėtinė projektavimo metodų ir CASE priemonių dalis ir dažniausiai palaiko duomenų srautų diagramų kurimą Pažymėjimai naudojami skirtinguose metoduose yra panašūs ir lengai transformuojami nuo viemų pažymėjimų prie kitų.
Duomenų srautų diagramų pranašumas yra tas, kad jos parodo transformacijas, bet nerodo, kaip transformacijos įgyvendinamos. Pavyzdžiui, sistema, parašyta šiuo budu gali būti įgyvendinama kaip viena programa, naudojant programų vienetus, įgyvendinančius kiekvieną transformaciją. Kaip alternatyva gali būti ygyvendintos keliois komunikuojančios užduotys arba gali būti realizuota kaip šių metodų junginys.
Struktūrinės diagramos
Struktūrinės diagramos yra grafinės priemonės, parodančios sistemos komponentų struktūros hierarchiją. Jos parodo, kad duomenų srauto elementų diagramos gali būti realizuotos kaip programų dalių hierarchija. Struktūrinės diagramos gali būti naudojamos vaizdininiam programų atvaizdavimui su svarbia informacija. Struktūrinės diagramos čia naudojamos tik statiniam projektavimo organizavimo atvaizadavimui.
Struktūrinėje diagramoje funkcinis elementas vaizduojamas kaip stačiakampis. Struktūrinėje diagramoje hierarchija vaizduojama sujungiant stačiakampius linijomis. Įėjimai ir išėjimai į komponentes vaizduojami naudojant rodykles. Rodyklė, įeinanti į figūrą, imituoja įėjimą, kitas linijos galas imituoja išėjimą. Duomenų saugykla vaizduojama kaip stačiakampis užapvalintais kampais, o vartotojo įėjimai kaip apskritimai. Kad sutaupyti diagramos vietą, kai kurie įėjimai ir išėjimai lieka nepažymėti.
Problema, kuri kyla programinės įrangos inžinieriui, yra kaip gauti geriausios struktūros diagramą iš duomenų srauto digramos. Kad iliustruoti tai, išnagrinėkime tas programinės įrangos sistemas, kurios gali būti šiuolaikinės aviacijos dalimi.
Struktūrinės diagramos gavimas
Ankstesniame skyrelyje buvo nagrinėta, kaip struktūrinės diagramos yra sudaromos iš duomenų srautų diagramų, tačiau nieko nebuvo pasakyta apie tai, kaip geriau tai pdaryti.
Projektuotojai turi suprojektuoti objektą, kuriame programos blokai yra aukštame lygyje surišti viduj ir žemame lygyje susieti su kitais blokais. Toks apibūdinimas gali būti supaprastintas, jeigu blokai turi ryšius su vienu iš keturių duomenų tipų:
1. Įėjimas. Šis programos blokas atsakingas už duomenų priėmimą iš žemesnio struktūrinės diagramos lygio, modifikavimą ir perdavimą į aukštesnį lygį.
2. Išėjimas. Šis blokas gauna duomenis iš aukštesnio lygio ir perduoda juos į žemesnį lygį.
3. Transformacija. Programos blokas gauna duomenis iš aukštesnio lygio, keičia juos ir grąžina juos atgal.
4. Valdymas. Blokas kontroliuoja ir valdo kitus blokus.
Pirmas žingsnis duomenų srauto diagramų konvertavimo į strukūrinę diagramą yra identifikuoti aukščiausius įėjimo ir išėjimo blokus. Šis žingsnis neįtraukia visų transformacijų, tačiau įtrauktosios vadinamos pagrindinėmis.
Aukščiausio lygio įėjimo ir išėjimo blokų nustatymas priklauso nuo projektuotojų patyrimo. Vienintelis galimas būdas išspręsti šią užduotį yra trasuoti įėjimus tol, kol bus rasta tokia transformacija, kurios išėjimas nepriklauso nuo įėjimo. Procesai, kurie validuoja įėjimus ar prideda jiems informacijos dar nėra vadinami pagrindiniais transformuotojais; jais vadinami tokie procesai, kurie rūšiuoja ar filtruoja duomenis. Panašiais kriterijais remiantis nustatomos ir aukščiausio lygio išėjimo transformacijos.
Pirmas struktūrinės diagramos projektavimo lygis sudaromas įėjimo ir išėjimo vienetus pažymint atskirais apskritimais ir kiekvieną atskirą pagrindinę transformaciją pažymint kaip atskirą stačiakampį. Stačiakampis, esantis struktūrinės diagramos viršuje vadinamas koordinuojamu bloku. Sudarymo procesas turi būti vykdomas tol, kol kol bus atvaizduoti visi duomenų srautų judėjimai.
Kiekvienas mazgas gerai suprojektuotoje struktūrinėje diagramoje turi turėti nuo dviejų iki septynių sau pavaldžių mazgų. Jei mazgas turi tik vieną sau pavaldų mazgą, vadinasi to mazgo programos blokas turės žemo lygio susietumą su kitais blokais. Jei mazgas turi daug sau pavaldžų mazgų, vadinasi programos projektavimas buvo vystomas žemo lygio fazėje.
Informacija, esanti duomenų srautų diagramose, paprastai naudojama projektuojant struktūrines diagramas, tačiau kiti į struktūrinę diagramą įtraukiami komponentai, kurių nebuvo duomenų srauto diagramoje, nėra tiesiogiai susiję su duomenų transformacija.
Struktūrinių diagramų sudarymas yra dviejų lygių procesas. Projektuojant duomenų srautus, apibrėžiamos pirminės projektavimo aprašymo struktūros, į kurias įeina valdymo informacija ir funkcijos. Struktūrinės diagramos turi būti modifikuojamos, įtraukiant papildomus valdymo komponentus.
Pagrindinės išvados:
* Duomenų srauto diagramos yra priemonė dokumentuoti sistemos duomenų srautus.
* Struktūrinės diagramos yra vienas iš būdų atvaizduoti sistemos hierarchinę organizaciją. Svarbu, kad kiekvienas funkcinis mazgas struktūroje turėtų nuo dviejų iki septynių sau pavaldžių mazgų.
Duomenų žodynai
Duomenų žodynai yra labai naudingi ne tik tai tam, kad palaikyti sistemos specifikacijas, bet ir tiek pat naudingi projektavimo procese. Kiekviena nustatyta esybė diagramoje turi turėti duomenų žodyno įėjimą, duodantį informaciją apie jo tipą, jo funkcijas ir, galbūt, logišką išaiškinimą jo priklausymui. Tai kartais yra vadinama minispekuliacija, pasitenkinant trumpu komponentų f-jos aprašymu.
Duomenų žodyno įėjimas turėtų būti komponento tekstinis aprašymas arba turėtų būti labiau išsamesnis aprašymas, išdėstytas projektavimo aprašymo kalba.
Duomenų žodynai yra atitinkamas būdas sujungti aprašomojo ir diagraminio projektavimo aprašymus. Ši schema parodo išnykstantį langą, aprašydama pažymėtą transformaciją slenkančių duomenų schemoje. Kai kurie CASE įrenginių išdėstymai aprūpina automatinį sujungimą tarp slenkančių duomenų schemos ir doumenų žodyno.
Konkuruojančių sistemų projektavimas
Kaip ir objektinis projektavimas, f-nis panašumas projektavimui neužkerta kelio šio projektavimo, kaip eilės lygiagrečiai sąveikaujančių procesų, realizavimui. Iš tikrųjų, slenkančių duomenų diagramos aiškiai pašalina valdymo informaciją ir standartinė įgyvendinimo technika realaus laiko sistemoms yra paimti slenkančių duomenų diagramą ir įvykdyti jos transformacijas kaip skirtingus procesus.
Vietinės informacijos grąžinimo sistema galėtų būti projektuojama naudojant konkuruojančius procesus. Komandos įvedimas, vykdymas, būsenos ataskaita-visosyra vykdomos kaip atskiros užduotys.
Get_command užduotis tęsiamai traukia pelę ir kai komandos plotas yra pažymėtas, pradedamas komandos vykdymo procesas. Taip pat komandos vykdymo procesas pateikia būsenos pranešimus, kurie yra perdirbti išėjimo užduočių. Darbo aplinkos sukūrimas taip pat vykdomas kaip lygiagreti užduotis ir autorius yra priimtas ar nušalintas priklausomai nuo to ar kursorius yra darbo lange, ar ne.
Šis pavyzdys iliustruoja, kad projektavimo lygiagretumas dažnai yra pasirinkimo teisė, prieinama projektuotojui. Kai kurie sistemų tipai yra paprastai vykdomi kaip lygiagrečių procesų rinkiniai kartu su procesu, susijusiu su kiekvienu sistemos techninės įrangos įrenginiu. Kaip bebūtų, problemomis dažnai tampa ir lygiagretaus, ir nuoseklaus projektavimo sprendimai, o skuboti projektavimo sprendimai turi būti anuliuojami.

Raktiniai žodžiai

• diagramos
• duomenų srautų diagrama
• duomenu srautu diagrama