5.

Darbas ”Programų sistemos eskizinis projektas”

5.1. Darbo tikslai ir paskirtis
Šiuo darbu siekiama mokyti studentus:
• projektuoti programų sistemas,
• UML kalbos pagrindų,
• rengti techninę dokumentaciją,
• dirbti pagal formalius reikalavimus,
• dirbti grupėse
• planuoti grupinį darbą ir baigti jį numatytais terminais,
• viešai pristatyti darbą, argumentuoti priimtus sprendimus.
“Programų sistemos eskizinis projektas” yra dokumentas, rengiamas atlikus dalykinės srities analizę ir
suformulavus programų sistemos reikalavimus. Dokumento paskirtis yra stambiu planu (eskizo lygmeniu) aprašyti
kuriamos programų sistemos reikalavimų įgyvendinimo būdą arba, kitaip tariant, aprašyti kuriamos programų
sistemos architektūrą ir veikimą. Tuo tikslu yra išsamiai ir pakankamai griežtai aprašoma, kokias užduotis vykdo
programų sistema, kokius scenarijus ji naudoja toms užduotims vykdyti, kokie resursai ir kaip yra panaudojami
realizuojant scenarijus, ir kokie rezultatai yra gaunami įvykdžius užduotis. Kitaip tariant, dokumento paskirtis yra
pateikti nuoseklų ir išsamų programų sistemos koncepcinį modelį, detalizavus kurį būtų galima gauti konkrečias
užduotis programuotojams. Rengdami dokumentą “ Programų sistemos eskizinis projektas ”, studentai veikia kaip
programų sistemų architektai. Jei dokumento “Programų sistemos eskizinis projektas” apimtis gaunasi per didelė,
studentams leidžiama projektuoti sistemą atmetant kai kurias dokumente „Reikalavimų specifikacija“ aprašytas
užduotis.
5.2. Darbo bendrosios dalies struktūra
Programų sistemos eskizinį projektą sudaro šie skyriai:
• programų sistemos projektiniai reikalavimai
• programų sistemos architektūra,
• išvados.
Pirmieji du skyriai papildo vienas kitą ir turi būti rengiami kartu. Kitaip tariant, pokyčiai viename iš skyrių
iššauklia esminius pokyčius kitame skyriuje.
5.3. Skyriaus “Programų sistemos projektiniai reikalavimai” paskirtis, struktūra ir turinys
Dokumente “Reikalavimų specifikacija” suformuluoti reikalavimai yra operacinio pobūdžio. Kitaip tariant, ji
aprašo systemą kaip “juodąją dėžę”, taip, kaip ją mato išoriniai agentai (užsakovai, operatoriai, informacijos
vartotojai ir kt.). Šiame skyriuje operaciniai reikalavimai yra transformuojami į projektinius, arba, kitaip tariant,
sistema yra aprašoma kaip “perregimoji dėžė”, taip, kaip ją regi projektuotojai ir programuotojai, žiūrintys į ją “iš
vidaus”. Tam naudojami reikalavimų lokalizavimo ir nuleidimo žemyn metodai (žr. paskaitų skaidrių 11 temą:
Projektavimas ir testavimas, taip pat A. Čaplinskas. Programų sistemų inžinerijos pagrindai, I dalis, 3.1 poskyris,
p.p. 101-104).
Skyrių sudaro šie poskyriai:
• programų sistemos dekompozicija,
• reikalavimų lokalizavimo matrica,
• reikalavimų ryšio matrica.
Poskyryje „Programų sistemos dekompozicija“ pateikiama UML komponentų diagrama, vaizduojanti į kokius
komponentus yra dekomponuota programų sistema, ir aprašomi kiekvieno komponento funkciniai ir nefunkciniai
reikalavimai, gauti lokalizavus jame aukštesniojo lygmens reikalavimus ir nuleidus juos žemyn. Atkreipkite dėmesį į
tai, kad kiekvienas komponentas vykdo tam tikras užduotis (použduotis), todėl sistemos dekompozicija turi atitikti
skyriuje „Programų sistemos architektūra“ atliekamai užduočių dekompozicijai. Formuluojant reikalavimus,
kiekvienas komponentas traktuojamas kaip „juodoji dėžė“, kurios struktūra atskleidžiama dekomponuojant jį į
žemesnio lygmens komponentus. Dekompozicija atliekama vadovaujantis pasirinktąja programų sistemos
architektūra. Rekomenduojama rinktis paskaitų skaidrių 11 temoje (taip pat ir knygoje A. Čaplinskas. Programų
sistemų inžinerijos pagrindai, II dalis, 4.4.3.2.5. poskyryje, p.p. 187-190) aptartą Koudo-Jodano architektūrą, bet
galima rinktis ir bet kurią kitą architektūrą. Priklausomai nuo pasirinktos architektūros, komponentams yra
formuluojami vadinamieji papildomi reikalavimai (žr. A. Čaplinskas. Programų sistemų inžinerijos pagrindai, I
dalis, 3.1 poskyris, 101 p.). Prieš projektuojant interfeiso paketus, rekomenduojama susipažinti su medžiaga, pateiktą
A. Čaplinskas. Programų sistemų inžinerijos pagrindai, II dalis, 4.6. poskyryje (p.p. 236-255)
Poskyryje „Reikalavimų lokalizavimo matrica“ pateikiama skaidrėse (11 tema) pateikta reikalavimų
lokalizavimo matrica.
Poskyryje „Reikalavimų ryšio matrica“ pateikiama skaidrėse (11 tema) aptartata reikalavimų ryšio matrica.
Stulpelis “Reikalavimo aprobavimo būdas” yra neprivalomas. Jei jis pildomas, tai nurodoma kaip numatoma
patikrinti reikalavimą programų sistemos baigiamųjų bandymų metu. Stulpelis “Aprobavimo rezultatai” nepildomas.
Pastaba. Atliekant reikalavimų lokalizavimą, jų nuleidimą žemyn ir aprašant reikalavimų aprobavimo būdus,
gali paaiškėti, kad dokumente “Reikalavimų specifikacija” pateikti reikalavimai buvo suformuluoti netinkamai ir
juos reikia taisyti.
29
5.4. Skyriaus “Programų sistemos architektūra” paskirtis, struktūra ir turinys
Programų sistemos architektūra vadinamas tos sistemos koncepcinis modelis. Jis gaunamas iš dalykinės srities
koncepcinio modelio, išreiškiant jį kuriamosios programų sistemos terminais ir sąvokomis. Taigi, projektuojant
programų sistemos architektūrą yra nusprendžiama, kurie dalykinės srities koncepcinio modelio elementai turės savo
atitikmenis programų sistemoje ir kokie tie atitikmenys bus. Priimant sprendimus, būtina atsižvelgti į tai, kad
dalykinės srities koncepcinis modelis aprašo kaip dalykinėje srityje yra dirbama, kol nėra sukurta programų sistema.
Ją sukūrus, bus pradėta dirbti taip, kaip numato “Poreikių specifikacijoje” aprašytas darbo su sistema scenarijus.
Todėl, dalykinės srities koncepcinį modelį atvaizduoti tiesiogiai į programų sistemos architektūrą pavyksta labai
retai. Be to, programų sistemoje atsiranda daugybė objektų, susijusių su nefunkcinių programų sistemos reikalavimų
įgyvendinimu.
Skyrių sudaro šie poskyriai:
• užduotys ir jų vykdymo scenarijai,
• struktūrinis programų sistemos modelis,
• dinaminis programų sistemosmodelis,
• programų sistemos komponentų diagrama,
• programų sistemos išskirstymas kompiuterių tinkle.
Šio skyriaus paskirtis – suprojektuoti programų sistemą, t.y. kiekvieno komponento vidų ir tų komponentų
tarpusavio ryšius. Atkreipkite dėmesį, kad šiame darbe sudaromas ne koncepcinis dalykinės srities modelis, bet
kuriamos programų sistemos architektūra. Tai reiškia, kad užduotys modeliuojamos taip, kaip jos turi būti vykdomos
sutinkamai su “Poreikių specifikacijoje” patektu scenarijumi.
5.4.1. Poskyrio “Užduotys ir jų vykdymo scenarijai” turinys ir struktūra
Šiame poskyryje detalizuojama “Poreikių specifikacijoje” pateikta užduočių diagrama ir aprašomas jos
realizavimo būdas. Pokyrį sudaro šie skyreliai:
• sistemos vykdomos užduotys,
• užduoties ….. įgyvendinimas.
Antrasis skyrelis kartojamas tiek kartų, kiek yra sistemos vykdomų užduočių.
Skyrelyje “Sistemos vykdomos užduotys”patekiama dokumente “Poreikių specifikacija” aprašyta užduočių
diagrama, pakoreguota, atsižvelgiant į užduočių aprašus, pateiktus dokumente “Dalykinės srities koncepcinis
modelis”.
Skyrelyje “Užduoties “…..” įgyvendinimas” pateikiamos atitinkamos užduoties vykdymo sekų ir ansamblių
diagramos UML kalba ir jas paaiškinantis tekstas. Diagrama parodo, kaip, vykdydami šią užduotį, komunikuoja
programų sistemos objektai. Sekų diagramą aiškinantis tekstas rengiamas pagal tas pačias taisykles, kaip ir dalykinės
srities koncepcinio modelio atveju.
Sekų diagramą sudarantys pranešimai traktuojami kaip žemesnio lygmens užduotys. Kiekvienai sekų diagramai
rengiama atitinkama užduočių diagrama, jai rengiamos atitinkamos sekų ir ansamblių diagramos ir t.t.
Dekompozicija tęsiama tol, kol sekų (ir ansamblių) diagramomis aprašomos objektų operacijų (metodų) realizacijos.
Dekompozicija turi būti suderinta su skyriuje “Programų sistemos projektiniai reikalavimai” aprašyta dekompozicija.
Kitaip tariant, kiekvieną ten aprašytą paketą turi atitikti užduočių diagrama ir atvirkščiai.
5.4.2. Poskyrio “Struktūrinis programų sistemos modelis” turinys ir struktūra
Šio skyriaus paskirtis aprašyti programų sistemos duomenų architektūrą. Skyriuje pateikiama UML koncepcinio
ir eskizinio lygmenų statinės struktūros diagramos ir jas paaiškinantis tekstas. Diagramosee turi būti parodytos visos
klasės bei visi objektai, pasirodantys sekų diagramose. Paaiškinamajame tekste trumpai aprašoma klasių bei objektų
paskirtis. Atkreipkite dėmesį, kad čia nagrinėjami klasės ir objektai, o ne sistemos komponentai. Viena klasių
diagrama reikalinga sistemos duomenų bazei aprašyti. Kiekvienam sistemos posistemiui reikalinga klasių diagrama,
aprašanti to posistemio vidines klases ir jų tarpusavio ryšius.
5.4.3. Poskyrio “Dinaminis programų sistemosmodelis” turinys ir struktūra
Šio poskyrio paskirtis aprašyti programų sistemos koncepcinio lygmens interfeisus ir per interfeisus pateikiamų
pranešimų (užduočių) sukeliamus efektus. Joje parodoma, kokie pranešimai (užduotys) ateina per vartotojo
interfeisą, kaip jie kečia programų sistemos duomenų bazes ir kokius rezultatus sukuria. Skyriuje pateikiamos UML
kalbos būsenų diagramos modeliuojančios statinės struktūros diagramoje pavaizduotų klasių bei objektų (bet ne
pačios sisyemos ir ne jos komponentų) gyvavymo ciklus, ir tas diagramas paaiškinantys tekstai.
5.4.4. Poskyrio “Programų sistemos išskirstymas kompiuterių tinkle” turinys ir struktūra
Šio poskyrio paskirtis parodyti kaip komponentai išskirstomi kompiuterių tinkle. Poskyryje pateikiama sistemos
išdėstymo diagrama (žr. paskaitų skaidrių 7 temą: UML) UML kalba ir ją paaiškinantis tekste. Tekste aprašomos
kiekvieno kompiuterių tinklo mazgo charakteristikos (sutinkamai su “Poreikių specifikacija”).

30
5.5. Ketvirto darbo vertinimo metodika
5.5.1. Vertinimas pagal skyrius
Skyrius Poskyris Skyrelis Įvertis
Titulinis
Anotacija
Turinys
1. Įvadas PS pavadinimas
DS
PS
Naudotojai
Darbo pagrindas
Naudoti dokumentai
2. Programų sistemos Programų sistemos
projektiniai reikalavimai dekompozicija (apimant
komponentų diagramą)
Reikalavimų
lokalizavimo matrica

Reikalavimų ryšio
matrica

3.Programų sistemos Užduotys ir jų Sistemos vykdomos

architektūra vykdymo scenarijai užduotys
Užduoties …..
įgyvendinimas
Struktūrinis
programų sistemos
modelis
Dinaminis programų
sistemosmodelis
Programų sistemos
išskirstymas
kompiuterių tinkle
5. Išvados
Skyrių numeracija
Terminų žodynas 0

5.5.2. Darbo tikslų realizavimas

• projektuoti programų sistemas (įvertis)
• UML kalbos pagrindų (įvertis)
• rengti techninę dokumentaciją (įvertis)
• dirbti pagal formalius reikalavimus (įvertis)
• dirbti grupėse (įvertis)
• planuoti grupinį darbą ir baigti jį numatytais terminais (įvertis)
• viešai pristatyti darbą, argumentuoti priimtus sprendimus (įvertis)

31
5.5.3. Darbo klaidų vertinimas
4 darbas. Klaidų suvestinė (+ pažymėtos klaidos, ? – vertinimui nepakanka informacijos)
Klaidos 1 2 3 4 5 6 7
Dokumentavimo klaidos
• titulinis
• anotacija
• turinys
• darbo struktūra
• dokumentų sąrašas bei
nuorodos į jį
• žodynėlis
• diagramų kokybė
• trūksta diagramų aprašų
• puslapiavimas
• puslapių numeriai
• skyrių numeracija
• kitos
Dalykines klaidos
• dalykinė sritis
• probleminė sritis
• vartotojų kvalifikaciniai
reikalavimai
Reikalavimų nuleidimas ir
lokalizavimas
• komponentų diagrama
• reikalavimų lokalizavimo
matrica
• reikalavimų nuleidimas žemyn
• ryšio matrica
Užduotys
• sistemos vykdomos užduotys
(diagramos)
• Užduotys neatitinka
reikalavimų specifikacijos
Užduočių įgyvendinimo
scenarijai
• neparametrizuoti pranešimai
• neteisingai aprašyti objektai
• tikslai
• agentai
• sąlygos
• trigeriai
• scenarijų kūnas
• plėtiniai
• variantai
Statinis modelis
o nesuprojektuo-
tas interfeisas
o interfeisas
netenkina
reikalavimų
specifikacijos
o nesuprojektuo-
tas dalykinis
posistemis
o nesuprojektuota
DB
o nesuprojektuo-
tas programos ir
DB sąveikos
32
 Klaidos 1 2 3 4 5 6 7
mechanizmas
o trūksta sistemos
komponentus
aprašančių
klasių ir objektų
o statinis modelis
gautas ne iš
užduočių
scenarijų
o nesuprasta
objektinė
paradigma
o modelis
nesuderintas su
komponentų
diagrama
Dinaminis modelis
o neparodytas
interfeiso
veikimas
o neparodytos
transakcijų
trasos
o transakcijos
nesusietos su
užduočių
įgyvendinimo
modeliais
o statinis ir
dinaminis
modeliai
neteisingai
susieti
tarpusavyje
Išskirstymo tinkle diagrama
• diagrama nesuderinta su
komponentų diagrama
• diagrama neatitinka
pasirinktosios architektūros
Pažeisti formalūs reikalavimai:
trūksta diagramų aprašų
Terminija
• terminija
• terminų žodynas
Lietuvių kalba
Minusai už vėlavimą 0 0 0 0 0

33