Friday, January 13, 2017
Thursday, January 12, 2017
12.01.2017: tarkvara arendusprotsess x4 (Väino L.)
Tarkvara disain:
protsess, kus agent loob tarkvaratehise spetsifikatsiooni, kasutades algseid komponente
1)Algoritmi disain
Algoritmid:
1)probleemi määraimine
Jada liikmed käivad loogeliste sulgude vahele
CASE vahendid: Eclipse, NetBeans
CASE: tööriistade valdkond, mida kasutatakse tarkvara loomiseks ja disainimiseks
CASE kolm gruppi:
1)Tööriistad
2)Tööpingid
3)Keskkonnad
Tööriistad:
1)Äri ning analüüsi modelleerimine
2)Arendus, debuggerid
3)Verifitseerimine ning valideerimine; koodi analüsaatorid
4)Seadistuste haldus
5)mõõtmine; koodi analüsaatorid koodi keerukuse suhtes
6)projektijuhtimine
Tööpingid:
integreerivad kaks või rohkem CASE tööriista
Fundamentaalsed modelleerimis kontseptid (FMC)
1)süsteemi struktuur
2)protsess süsteemis
3)domeeniväärtused süsteemis
*Liitstruktuuri skeem ehk FMC plokk-skeem
*Dünaamilise struktuuri skeem ehk FMC Petri-net
*Väärtuste raadiuse struktuuri skeem ehk FMC E/R skeem
FMC plokkskeem
Pilt (see link siin eelmisel real) on liitstruktuuri skeemi näide. Selles on agendid tellimuse protsessor (Order Processor), tarnija haldur (Supplier Manager) , tarnija (Supplier), veebipood (Online Shop), ning nimetu inimagent (Human Agent)
DAVIS
1)disainiprotsess ei tohiks kannatada "silmaklappidest", peaks proovima erinevaid lähenemisi
2)disain peaks olema seotud ning jälitatav
3)ära leiuta jalgratast
4)disain peaks näima ühtlane,
5)peaks olema struktuurne ning peaks võimaldama muutuste sisseviimist
6)peaks olema disainitud nii, et suudaks ootamatustele vastata
7)disain pole koodimine, koodimine pole disain
8)peaks hindama disaini kvaliteetsust
9)disaini peab üle vaatama, et minimiseerida põhimõttelisi vigu
Disaini põhimõtted
1)abstraktsioon - üldistamine
2)viimistlemine/täpsustamine:
3)modulaarsus- tarkvara arhitektuur võiks olla jaotatud komponentideks
4)Tarkavara arhitektuur
5)Juhtimise hirearhia
6)jaotiste ülesehitus- programmi ülesehitus tuleks jagada horisontaalselt ning vertikaalselt juppideks
7)Andmestruktuur
8)Tarkvaraprotseduur
9)Polümorfism
Disaini kaalutlused
1)ühilduvus: tarkvara peab töötama teiste toodetega koos
2)laiendatavus: võimalus lisada uusi võimekusi
3)modulaarsus
4)hooldatavus
5)taaskasutatav
6)robustne
7)turvalisus
8)kasutatavus
9)jõudlus: asi ei tohi venima jääda
10)porditavus
11)mastaapsus
Arhitektuuri kirjeldamise keel
https://github.com/osate
camunda.org/bpmn/tutorial/
https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation#Overview
EEML
Vooskeem
IDEF: modelleerimiskeelte perekond
Jackson
LePUS3: kuulub objekt-orienteeritud programmeerimiskeelte hulka
Alloy: on loodud keeruliste struktuursete piirangute kirjeldamiseks (uuri Alloy'd!)
Service-oriented modeling framework (SOMF)
hirmus UI
Disaini mustrid
protsess, kus agent loob tarkvaratehise spetsifikatsiooni, kasutades algseid komponente
1)Algoritmi disain
Algoritmid:
1)probleemi määraimine
Jada liikmed käivad loogeliste sulgude vahele
CASE vahendid: Eclipse, NetBeans
CASE: tööriistade valdkond, mida kasutatakse tarkvara loomiseks ja disainimiseks
CASE kolm gruppi:
1)Tööriistad
2)Tööpingid
3)Keskkonnad
Tööriistad:
1)Äri ning analüüsi modelleerimine
2)Arendus, debuggerid
3)Verifitseerimine ning valideerimine; koodi analüsaatorid
4)Seadistuste haldus
5)mõõtmine; koodi analüsaatorid koodi keerukuse suhtes
6)projektijuhtimine
Tööpingid:
integreerivad kaks või rohkem CASE tööriista
Fundamentaalsed modelleerimis kontseptid (FMC)
1)süsteemi struktuur
2)protsess süsteemis
3)domeeniväärtused süsteemis
*Liitstruktuuri skeem ehk FMC plokk-skeem
*Dünaamilise struktuuri skeem ehk FMC Petri-net
*Väärtuste raadiuse struktuuri skeem ehk FMC E/R skeem
FMC plokkskeem
Pilt (see link siin eelmisel real) on liitstruktuuri skeemi näide. Selles on agendid tellimuse protsessor (Order Processor), tarnija haldur (Supplier Manager) , tarnija (Supplier), veebipood (Online Shop), ning nimetu inimagent (Human Agent)
DAVIS
1)disainiprotsess ei tohiks kannatada "silmaklappidest", peaks proovima erinevaid lähenemisi
2)disain peaks olema seotud ning jälitatav
3)ära leiuta jalgratast
4)disain peaks näima ühtlane,
5)peaks olema struktuurne ning peaks võimaldama muutuste sisseviimist
6)peaks olema disainitud nii, et suudaks ootamatustele vastata
7)disain pole koodimine, koodimine pole disain
8)peaks hindama disaini kvaliteetsust
9)disaini peab üle vaatama, et minimiseerida põhimõttelisi vigu
Disaini põhimõtted
1)abstraktsioon - üldistamine
2)viimistlemine/täpsustamine:
3)modulaarsus- tarkvara arhitektuur võiks olla jaotatud komponentideks
4)Tarkavara arhitektuur
5)Juhtimise hirearhia
6)jaotiste ülesehitus- programmi ülesehitus tuleks jagada horisontaalselt ning vertikaalselt juppideks
7)Andmestruktuur
8)Tarkvaraprotseduur
9)Polümorfism
Disaini kaalutlused
1)ühilduvus: tarkvara peab töötama teiste toodetega koos
2)laiendatavus: võimalus lisada uusi võimekusi
3)modulaarsus
4)hooldatavus
5)taaskasutatav
6)robustne
7)turvalisus
8)kasutatavus
9)jõudlus: asi ei tohi venima jääda
10)porditavus
11)mastaapsus
Arhitektuuri kirjeldamise keel
https://github.com/osate
camunda.org/bpmn/tutorial/
https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation#Overview
EEML
Vooskeem
IDEF: modelleerimiskeelte perekond
Jackson
LePUS3: kuulub objekt-orienteeritud programmeerimiskeelte hulka
Alloy: on loodud keeruliste struktuursete piirangute kirjeldamiseks (uuri Alloy'd!)
Service-oriented modeling framework (SOMF)
hirmus UI
Disaini mustrid
Wednesday, January 11, 2017
11.01.2017: Tarkvara arendusprotsess x2 (Väino L.), andmebaasirakenduste arendaja x2 (Tatjana P.)
Nõuete esilekutsumine:
sisaldab intervjuusid, küsimustikke, kasutaja vaatlusi, töötubasid, ajurünnakuid, kasutajalugusid, rollimänge ning prototüüpimine.
Enne kui nõudeid saab analüüsida, modelleerida või spetsifitseerida, tuleb neid koguda esilekutsumise protsessiga.
Süsteemi modelleerimis keeli on mitmesugused.
Tavaline esilekutsumisprotsess on huvigruppidega kohtumine või intervjuud. Nt esimene tähtis kohtumine oleks tarkvara arendajate ning klientide kus nad arutavad nõuete perspektiivi.
Probleemid:
1)Probleemide ulatus: ei tasu kliente terminoloogiaga segadusse ajada
2)Mõistmise probleem: kliendid ei ole kindlad, mida vaja, ei tea arvutite suutlikkust, ei suuda selgitada
3)Muutumise probleem: nõuded muutuvad ajaga.
Nõuete kvaliteedi parandamine:
1)visualiseerimine
2)kooskõlaline keel: kasuta lihtsat/loomulikku keelt nõuete kirjeldamiseks
3)reeglid: järgi ettevõttes väljakujunenud reegleid.
4)pidev mallide kasutamine
5)dokumenteerimise sõltuvused
6)muudatuste analüüs
Nõuete esiletoomise juhised:
1)hinda süsteemi ärilist ning tehnilist teostatavust
2)inimeste, kes võiksid nõuete väljaselgitamist aidata, leidmine
3)määratle tehniline keskkond, nt op-süsteem
4)tuvasta tegevusvaldkonna piirangud
5)määratle rohkem kui üks esiletõstmismeetod
6)korralda erinevate huvigruppidega kohtumisi
7)tuvasta tähtsaimad nõuded, mida on vaja prototüübi loomised
8)loo kasutuslood, et aidata klientidel tuvastada võtmenõudmisi
Sammude järjekord:
1)tuvasta reaalne probleem, võimalus või väljakutse
2)tuvasta jooksvad meetmed, mis tõestavad, et probleem on reaalne
3)tuvasta eesmärk-meetmed et tõestada probleemi olemasolu
4)tuvasta probleem olemus
5)määratle ärivaldkonna "miksid"
6)määratle tootedisain
Täiendavad lähenemised:
1)tuvasta huvigrupid
2)modelleerimise eesmärgid
3)modelleerimise kontekst
4)stsenaariumite avastamine (kasutuslugude jaoks)
5)kvaliteetide ning piirangute avastamine
6)eelduste ja kirjapaneku modelleerimine
7)sõnastiku kirjutamine
8)mõõtmete analüüsimine
9)
Analüüs:
võtame arvesse kõik vastuolud mida proovib nõuete kirjapanekul lahendada
Huvigrupid:
1)ükskõik, kes tegelevad süsteemiga (tavakasutajad ning hooldajad)
2)igaüks, kes saavad süsteemist tulu
3)igaüks, kes ostits süsteemi
4)ettevõtted, mis reguleerivad süsteemi aspekte
5)inimesed või ettevõtted kes on selle süsteemi vastu
6)ettevõtted, mis vastutavad teatud süsteemiliidese eest
Läbivad funktsionaalsused
Lepingu-stiilis nõuete loetelud
CIA: konfiguratsioon, tervikus, kättesaadavus
Kohustuslik kirjandus: "Tarkvaratehnika sissejuhatus 2008"
SRS on suhtlusvahend huvigruppide ning tarkvaraarendajate vahel
SRS eesmärgid:
1)aluseks koodiülevaatustele
2)tööulatuse kirjeldamine
3)tarvaradisaineritele annab viite
4)aluseks testimisele, testidokumendile (testiraamistik)
5)sisaldab iseärasusui kliendi nõuetega
6)on platvormiks edasiseks arenduseks
Uuri FreeMind'i
Tatjana tunnis õppisime vene keelt ning tegime harjutusi.
Mida õppisin: kes on huvigrupid.
sisaldab intervjuusid, küsimustikke, kasutaja vaatlusi, töötubasid, ajurünnakuid, kasutajalugusid, rollimänge ning prototüüpimine.
Enne kui nõudeid saab analüüsida, modelleerida või spetsifitseerida, tuleb neid koguda esilekutsumise protsessiga.
Süsteemi modelleerimis keeli on mitmesugused.
Tavaline esilekutsumisprotsess on huvigruppidega kohtumine või intervjuud. Nt esimene tähtis kohtumine oleks tarkvara arendajate ning klientide kus nad arutavad nõuete perspektiivi.
Probleemid:
1)Probleemide ulatus: ei tasu kliente terminoloogiaga segadusse ajada
2)Mõistmise probleem: kliendid ei ole kindlad, mida vaja, ei tea arvutite suutlikkust, ei suuda selgitada
3)Muutumise probleem: nõuded muutuvad ajaga.
Nõuete kvaliteedi parandamine:
1)visualiseerimine
2)kooskõlaline keel: kasuta lihtsat/loomulikku keelt nõuete kirjeldamiseks
3)reeglid: järgi ettevõttes väljakujunenud reegleid.
4)pidev mallide kasutamine
5)dokumenteerimise sõltuvused
6)muudatuste analüüs
Nõuete esiletoomise juhised:
1)hinda süsteemi ärilist ning tehnilist teostatavust
2)inimeste, kes võiksid nõuete väljaselgitamist aidata, leidmine
3)määratle tehniline keskkond, nt op-süsteem
4)tuvasta tegevusvaldkonna piirangud
5)määratle rohkem kui üks esiletõstmismeetod
6)korralda erinevate huvigruppidega kohtumisi
7)tuvasta tähtsaimad nõuded, mida on vaja prototüübi loomised
8)loo kasutuslood, et aidata klientidel tuvastada võtmenõudmisi
Sammude järjekord:
1)tuvasta reaalne probleem, võimalus või väljakutse
2)tuvasta jooksvad meetmed, mis tõestavad, et probleem on reaalne
3)tuvasta eesmärk-meetmed et tõestada probleemi olemasolu
4)tuvasta probleem olemus
5)määratle ärivaldkonna "miksid"
6)määratle tootedisain
Täiendavad lähenemised:
1)tuvasta huvigrupid
2)modelleerimise eesmärgid
3)modelleerimise kontekst
4)stsenaariumite avastamine (kasutuslugude jaoks)
5)kvaliteetide ning piirangute avastamine
6)eelduste ja kirjapaneku modelleerimine
7)sõnastiku kirjutamine
8)mõõtmete analüüsimine
9)
Analüüs:
võtame arvesse kõik vastuolud mida proovib nõuete kirjapanekul lahendada
Huvigrupid:
1)ükskõik, kes tegelevad süsteemiga (tavakasutajad ning hooldajad)
2)igaüks, kes saavad süsteemist tulu
3)igaüks, kes ostits süsteemi
4)ettevõtted, mis reguleerivad süsteemi aspekte
5)inimesed või ettevõtted kes on selle süsteemi vastu
6)ettevõtted, mis vastutavad teatud süsteemiliidese eest
Läbivad funktsionaalsused
Lepingu-stiilis nõuete loetelud
CIA: konfiguratsioon, tervikus, kättesaadavus
Kohustuslik kirjandus: "Tarkvaratehnika sissejuhatus 2008"
SRS on suhtlusvahend huvigruppide ning tarkvaraarendajate vahel
SRS eesmärgid:
1)aluseks koodiülevaatustele
2)tööulatuse kirjeldamine
3)tarvaradisaineritele annab viite
4)aluseks testimisele, testidokumendile (testiraamistik)
5)sisaldab iseärasusui kliendi nõuetega
6)on platvormiks edasiseks arenduseks
Uuri FreeMind'i
Tatjana tunnis õppisime vene keelt ning tegime harjutusi.
Mida õppisin: kes on huvigrupid.
Tuesday, January 10, 2017
10.01.2017: veebirakenduste loomise alused x4 (Jaan P.)
Esmaspäeval toodi kooli uued arvutid. Neil olid osadel BIOS lukus. Pidime BIOS luku deaktiveerima. Peale seda pidime paigaldama nendele arvutitele Windows 7. Win 7 Pro 4GB RAM'iga arvutile. Win 7 Home 2 GB RAM'iga arvutile. Ühele arvutile paigaldati Kodi MediaCenter.
Mida õppisin: kuidas BIOS lukku eemaldada.
Mida õppisin: kuidas BIOS lukku eemaldada.
Monday, January 9, 2017
9.01.2017: Tarkvara arendusprotsess x2 (Väino L.), veebirakenduste loomise alused x1 (Aire I.)
Tarkvaraarendus on:
1)teaduslike ja tehnoloogiliste teadmiste ja meetodite süstemaatiline rakendamine;
2)süstemaatiline, distsiplineeritud ja oluline lähenemine tarkvara arendamisele ja haldamisele;
3)kindlate arendusmeetodite rajamine ning kasutamine, et ekonoomiliselt saada tarkvara, mis on usaldusväärne ning töötab päris masinates
Nelja P meetod: product (toode), valitud meetod, people (inimested kes realiseerivad), project (projekt)
COCOMO (Constructive Cost Model)- tarkvara arendamise panus programmile, mees-aastates T, lähtekoodi ridadeni (SLOC- source lines of code). T = k*SLOC^(1+x)
Tarkvaranõuded: väli tarkvara arenduses mis tegeleb huvigruppide nõuete täitmisega.
Nõuded
1)Tingimus või võimekus mida kasutaja vajab, et lahendada probleeme või eesmärke saavutada.
2)Tingimus või võimekus millele süsteem peab vastama, standard, spetsifikatsioon
3)punktide 1 või kahe dokumenteeritud esitlus
SRS osad (SRS malli leiab siit):
(PS: osasid asju aru ei saanud, sisukord on kaos)
1)projekti muudatuste ajalugu
2)dokumendi heakskinnitajad
3)sisukord
1)Sissejuhatus
a)eesmärk
b)ulatus
c)definitsioonid, akronüümid. lühendid
d)viited
e)ülevaade
2)
3)Nõuded
a)Välise liidese nõuded
1)Kasutajaliidesed
2)Riistvaraliidesed
3)tarkvaralised liidesed
b)Funktsionaalsed nõuded
c)
d)klassid/objektid
5)Mittefunktsionaalsed nõudued (link dokumendile ria.ee's)
1)jõudlus
2)portimine
f)Pöörded
g)disainipiirangud
Andmeobjekt Register sisu ja piirangud:
1)Sissejuhatus
2)Sisendid
3)Andmete töötlemine
4)Väljundid
5)Veakäitlus
Aire tunnis tegime arvsõnade käänamise harjutusi.
Mida õppisin: mis on nelja P meetod.
1)teaduslike ja tehnoloogiliste teadmiste ja meetodite süstemaatiline rakendamine;
2)süstemaatiline, distsiplineeritud ja oluline lähenemine tarkvara arendamisele ja haldamisele;
3)kindlate arendusmeetodite rajamine ning kasutamine, et ekonoomiliselt saada tarkvara, mis on usaldusväärne ning töötab päris masinates
Nelja P meetod: product (toode), valitud meetod, people (inimested kes realiseerivad), project (projekt)
COCOMO (Constructive Cost Model)- tarkvara arendamise panus programmile, mees-aastates T, lähtekoodi ridadeni (SLOC- source lines of code). T = k*SLOC^(1+x)
Tarkvaranõuded: väli tarkvara arenduses mis tegeleb huvigruppide nõuete täitmisega.
Nõuded
1)Tingimus või võimekus mida kasutaja vajab, et lahendada probleeme või eesmärke saavutada.
2)Tingimus või võimekus millele süsteem peab vastama, standard, spetsifikatsioon
3)punktide 1 või kahe dokumenteeritud esitlus
SRS osad (SRS malli leiab siit):
(PS: osasid asju aru ei saanud, sisukord on kaos)
1)projekti muudatuste ajalugu
2)dokumendi heakskinnitajad
3)sisukord
1)Sissejuhatus
a)eesmärk
b)ulatus
c)definitsioonid, akronüümid. lühendid
d)viited
e)ülevaade
2)
3)Nõuded
a)Välise liidese nõuded
1)Kasutajaliidesed
2)Riistvaraliidesed
3)tarkvaralised liidesed
b)Funktsionaalsed nõuded
c)
d)klassid/objektid
5)Mittefunktsionaalsed nõudued (link dokumendile ria.ee's)
1)jõudlus
2)portimine
f)Pöörded
g)disainipiirangud
Andmeobjekt Register sisu ja piirangud:
1)Sissejuhatus
2)Sisendid
3)Andmete töötlemine
4)Väljundid
5)Veakäitlus
Aire tunnis tegime arvsõnade käänamise harjutusi.
Mida õppisin: mis on nelja P meetod.
Tuesday, December 13, 2016
Monday, December 12, 2016
22.11.2016 kuni 12.12.2016
Tegime oma mänge JavaScripti ning HTML'iga. Esmaspäeviti käisime koolis, kuna Jaak TTÜ-st tuli ning vastas meil tekkinud küsimustele. Ülejäänud aja olin ühikas ning tegin mängu.
Esimesel nädalal tegime seenekorjamise mängu. Tegelane, keda sai liigutada, oli animeeritud spriidilehe abil. Seened "kasvasid" ning kasvas kas korjatav seen või mürgiseen. Mul algas mängija 90 seenega, võitmiseks oli vaja 100 seent korjata. Mürgiseene korjamisel kaotad kolm seent, õige seene korjamisel saab ainult ühe punkti juurde.
Teisel nädalal tegime tulistamismängu. Ma tegin Space Invaders klooni, aga see jäi poolikuks. Kui tulnuka kuuliga pihta said ei saanud mäng läbi.
Kolmas nädal tegime iseenda mängu. Tegin erinevaid asju, kuid lõpuks tegin rahvastepalli mängu, kus mänguväljal põrkavad pallid ringi aga kui tegelasega pallile pihta minna, saab mäng läbi.
Mida õppisin: mängu tegemine on keeruline, kuna nii palju mänge on juba olemas ning täiesti uus mänguidee on päris haruldane.
Esimesel nädalal tegime seenekorjamise mängu. Tegelane, keda sai liigutada, oli animeeritud spriidilehe abil. Seened "kasvasid" ning kasvas kas korjatav seen või mürgiseen. Mul algas mängija 90 seenega, võitmiseks oli vaja 100 seent korjata. Mürgiseene korjamisel kaotad kolm seent, õige seene korjamisel saab ainult ühe punkti juurde.
Teisel nädalal tegime tulistamismängu. Ma tegin Space Invaders klooni, aga see jäi poolikuks. Kui tulnuka kuuliga pihta said ei saanud mäng läbi.
Kolmas nädal tegime iseenda mängu. Tegin erinevaid asju, kuid lõpuks tegin rahvastepalli mängu, kus mänguväljal põrkavad pallid ringi aga kui tegelasega pallile pihta minna, saab mäng läbi.
Mida õppisin: mängu tegemine on keeruline, kuna nii palju mänge on juba olemas ning täiesti uus mänguidee on päris haruldane.
Subscribe to:
Posts (Atom)