RTU maģistra profesionālo studiju programma "Informācijas tehnoloģija"
LDP lecture 2
1. DITF LDI
Lietišķo datorsistēmu programmatūras
profesora grupa
Lietišķo datorsistēmu programmatūra
2.lekcija
Materiālu sagatavoja: V.Kotovs
Atbildīgais pasniedzējs: prof. L.Novickis
2. ...
PI tendences – sarežģītības un abstrakcijas līmeņa paaugstināšana;
izstrādes procesa uzlabošana, automatizēšanas un uzturamības
atvieglošana; efektīvu un pierādītu risinājumu atkārtota izmantošana;
prasību mainīgums
Atkārtotā lietošana - process, kura ietvaros organizācija definē
sistemātiski pielietojamo procedūru kopu, lai specificētu, izveidotu,
klasificētu, dabūtu un adaptētu programmatūras artefaktus, ko var
pielietot lietojumu izstrādes procesā
Modularitāte - Lingvistiski modulāras vienības princips, Atklāts-Slēgts
princips, Iekļautas dokumentācijas princips ...
2
3. Plāns
Programmatūras šabloni
Programmatūras šablonu klasifikācija un forma
Projektēšanas šablonu izmantošana programmatūras
izstrādē
OO projektējuma pamata principi
3
4. 1.Projektēšanas šabloni (1/3)
➢ Šablons
✔ forma, veidne, modelis, noteikumu kopa kādu lietu vai
to daļu ģenerēšanai (wikipedia.org)
✔ konkrētas formas abstrakcija, kura atkārtojas kādā
noteiktajā kontekstā (Rīle)
✔ pilnīgi realizēta forma, oriģināls vai modelis, pieņemts
un piedāvāts imitācijai; normatīvs piemērs, arhetips
(Kouds)
✔ apraksta problēmu, kura vairākas reizes atkārtojas
mūsu vidē, kopā ar problēmas risinājumu, kuru var
izmantot vairākas reizes (K.Aleksanders)
4
5. 1.Projektēšanas šabloni (2/3)
➢ Projektēšanas šablons datorzinātnē
● apzīmē galvenos projektēšanas struktūru aspektus
● identificē, nosauc un abstrahē veiksmīgas projektējuma
struktūras, lietderīgas elastīga un atkārtoti lietojama
objektorientēta projektējuma izstrādē
5
6. 1.Projektēšanas šabloni (3/3)
Fakti
✔ Dokumentē eksistējošo un pierādīto projektēšanas
pieredzi
✔ Balstās uz abstrakcijām, kuras atrodas augstākā līmenī
par procedūrām, klasēm un objektiem
✔ Nodrošina kopējo vārdnīcu un projektēšanas principu
saprašanu
✔ Ir instruments programmatūras arhitektūras
dokumentēšanai
✔ Palīdz izveidot sarežģītas programmatūras arhitektūru
✔ Palīdz tikt galā ar programmatūras sarežģītību
6
7. 2.MVC. Projektēšanas šablona
piemērs (1/3)
➢ Model-view-controller (MVC) – pielietojams
programmatūras sistēmās, lai atdalītu datu modeli,
sistēmas (biznesa) loģiku no lietotāja saskarnes aspektiem
➢ Dalībnieki
• Model – lietojuma domēna specifiskas informācija
• View – modeļa atspoguļošana
• Controller – apstrādā un reaģē uz lietotāja darbībām,
iniciē izmaiņas modelī
7
8. 2.MVC. Projektēšanas šablona
piemērs (2/3)
➢ Labumi:
● Izmaiņas lietotāju saskarnē neietekmē datu modeli
● Datu modeļa reorganizācija bez nepieciešamības
mainīt lietotāju saskarni
● Informācijas piekļuves un biznesa loģikas atkabināšana
no datu atspoguļošanas un lietotāju mijiedarbības
aspektiem
➢ Piemēri
● Java Swing, Struts, Spring MVC, Android, citi
8
10. 3.Šablonu klasifikācija (1/2)
Konceptuāli
Programmatūras šabloni
šabloni
Projektēšanas
principi
Arhitektūras Projektēšanas
šabloni šabloni Idiomas
Programmatūras arhitektūras šabloni
apraksta vispārējus programmatūras arhitektūras strukturēšanas principus
Projektēšanas principi
nosaka fundamentālas programmatūras sistēmu projektēšanas idejas un
principus
Konceptuāli šabloni (analīzes šabloni)
konceptuālie modeļi, izmantoti atkārtojošo lietojuma sfēras situāciju
modelēšanai analīzes laikā
Idiomas (kodēšanas šabloni)
noteiktas programmēšanas valodas vai tehnoloģijas specifiskas idejas
Projektēšanas šabloni
11. 3.Šablonu klasifikācija (2/2)
➢ GoF klasifikācija
✔ Ērihs Gamma, Ričards Helms, Ralfs Džonsons un
Džons Vlissides
✔ arhitektūras idejas, neatkarīgas no lietojuma
konteksta
✔ aprakstītas klases un saistības starp to
eksemplāriem
✔ “mikro-arhitektūras” šabloni
12. 3.Šablonu klasifikācija (3/3)
● Klasifikācijas kritēriji:
– Mērķa kritērijs (radošie, struktūras un uzvedības
šabloni)
– Granularitātes kritērijs (klase, objekts vai to
maisījums)
● Forma
– teksts un OMT/UML diagrammas
– apraksts atbilst unificētam formātam (nolūks,
motivācija, lietojamība, struktūra, dalībnieki,
sadarbība, rezultāti, realizācija, izmantošanas
gadījumi)
13. Memento Proxy
Saglabā iterāciju stāvokli
Adapter
Builder
Bridge
Iterator
Izveido
Uzskaita elementus
Papildina elementu Command
funkcionalitāti Sastadīti ar
Composite Definē ķēdi
Decorator Kopēji kompozīti
Papildina operācijas
Definē gramatiku Visitor
Flyweight
Definē operācijas Chain of responsibility
Interpreter
Kopējas stratēģijas
Kopēji stāvokli
Strategy Mediator
Salikta atkarību pārvalde Observer
State
Nosaka izpildes soļus
Template method Bieži izmanto
Prototype Dinamiski konfigurē
Factory
Izveidots ar method
Abstract factory
Viens eksemplārs
Viens eksemplārs
Facade
Singleton
14. “Stratēģija”
projektēšanas šablons
Nolūks: Definē algoritmu kopu, iekapsulē tos atsevišķajos
objektos un nodrošina to izmaiņas iespēju
Konteksts
- saistītas klases atšķiras dažos uzvedības aspektos
- sistēmā ir nepieciešams atbalstīt atšķirīgu algoritmu variantus
(stratēģijas)
- klase nodrošina vairākus uzvedības variantus, kas bieži ir
saistīts ar lielu nosacījumu konstrukciju skaitu tas kodā
15. “Stratēģija”
projektēšanas šablons
Risinājums
Šablons piedāvā iekapsulēt algoritmus atsevišķās klasēs un
nodrošināt tiem kopējo izmantošanas interfeisu.
Context +strategy Strategy
ContextInterface AlgorithmInterface()
ConcreteStartegyA ConcreteStrategyB
AlgorithmInterface() AlgorithmInterface()
16. “Abstraktā rūpnīca”
projektēšanas šablons
Nolūks: Nodrošina saskarni saistīto objektu ģimeņu
izveidošanai.
Konteksts: Sistēmas objektus var bieži apvienot saimēs, ar
iespēju aizvietot veselu objektu grupu uz kādu citu.
Problēma
- sistēma jābūt neatkarīga no tā, kā tiek izveidoti, apvienoti
un atspoguļoti tas objekti
- sistēma jābūt konfigurēta izmantot vienu no vairākām
objektu saimēm bez papildus koda izmaiņām
- vienas saimes objektiem jābūt izmantotiem kopējā
kontekstā
17. “Abstraktā rūpnīca”
projektēšanas šablons
Risinājums: Nodrošināt abstraktu interfeisu saistītu objektu
grupu izveidošanai bez norādēm uz tā konkrētām klasēm,
kurš nosaka katras grupas objekta izveidošanas metodi
(objektu rūpnīcu).
AbstractFactory
+CreateProductA()
+CreateProductB()
AbstractProductA ConcreteFactory1 ConcreteFactory
2
ProductA1 ProductA2
AbstractProductB ProductB1 ProductB2
23. 5.Projektēšanas šablonu
izmantošana (4/5)
“Stratēģija” projektēšanas šablons
Definē algoritmu kopu, iekapsulē tos un nodrošina to apmaiņas iespēju
Konteksts
- saistītas klases atšķiras dažos uzvedības aspektos
- sistēmā ir nepieciešams atbalstīt atšķirīgu algoritmu variantus (stratēģijas)
- klase nodrošina vairākus uzvedības variantus, kas bieži ir saistīts ar lielu nosacījumu
konstrukciju skaitu tās kodā
Rezultāts
- algoritmu saimes tiek definētas Strategy klašu hierarhijās
- labāka klašu alternatīva par klases atvasināšanu – algoritmu iekapsulēšana Strategy
klasēs ļauj izmanīt un papildināt tos neatkarīgi
Context +strategy Strategy
ContextInterface AlgorithmInterface()
ConcreteStartegyA ConcreteStrategyB
AlgorithmInterface() AlgorithmInterface()
23
26. 6.Projektēšanas šablonu
izmantošana (2/2)
Novērotājs (Observer) šablons
nosaka 1-M saistības starp objektiem, lai par
viena objekta stāvokļa izmaiņām tiktu
automātiski paziņoti visi atkarīgi objekti
Kopīga saskarne - vienīgais kas ir zināms par
“novērotājiem”
“Novērotājus” var pievienot jebkurā laikā
Nav nepieciešamības pielāgoties jauniem
“novērotāju” tipiem
Klašu neatkarība un atkārotā lietojamība
Vājsaistīta sistēma
26
28. 7. MVC šablons. Struts (1/5)
Model-View-Controller (MVC)
- arhitektūras un projektēšanas šablons
- pielietojams programmatūras sistēmās, lai atdalītu datu modeli, sistēmas
(biznesa) loģiku no lietotāja saskarnes aspektiem
- Struts 1/2, Stripes, Wicket, Spring MVC, ASP.NET MVC, ...
Izmaina stāvokli
Biznesa Sistēmas
loģika dati
Pieprasa stāvokli
28
29. 7. MVC šablons. Struts (2/5)
Modelis (Model)
Lietojuma dati un biznesa loģika
Neatkarīgs no lietotāju saskarnes
Skats (View)
Modeļa daļu atspoguļošana lietotājam
Neatkarīgs no modeļa realizācijas
Vairāki skati modeļa atspoguļošanai
Kontrolleris (Controller)
Savieno Skatu un Modeli
Kontrolē izpildes plūsmu
Saņem lietotāja ievades informāciju
Veic operācijas ar modeļa datiem
Iniciē skata atjaunošanu
29
30. 7. MVC šablons. Struts (3/5)
Vēsturiskās pieejas dinamiskā satura ģenerēšanai Java Web lietojumos
Java Servlet
Java klases, kuras implementē HttpServlet saskarnes metodes (doGet(),
doPost())
Loģikas un atspoguļojuma kods nav atdalīts
Piemērs: out.println("<h1>" + someString+ "</h1>");
JSP (Java Server Pages)
HTML kods ar iekļauto Java kodu (Scriptlets)
Loģikas un atspoguļojuma kods nav atdalīts
Piemērs: <h1><% out.println(someString); %></h1>
JSP un JSTL (JSP Standard Tag Library)
JSTL definē speciālo komandu (tagu) kopu, ko var izmantot kopā ar JSP
Speciālās JSTL komandas sadarbībai ar JavaBean klasēm
Rezultātā uzlabota koda lasāmība un sistēmas uzturamība
Piemērs: <h1><c:out value="${bean. someString}"/></h1>
30
31. 7. MVC šablons. Struts (4/5)
STRUTS 1 augstākā līmeņa arhitektūra
31
32. 7. MVC šablons. Struts (5/5)
Labumi
Labākā sistēmas uzturamība un testējamība
Izstrādes uzdevumu atdalīšana
Sistēmas stiepjamība
Atkārtotā lietošana
Izpildes plūsma deklaratīvi definēta konfigurācijas failā
Viegla lokalizēšana
Pamatā Java standarta tehnoloģijas
Atklātā koda lietojumu karkass
32
33. 8. Kvalitatīva OO projektējuma
pamata principi (1/2)
Neveiksmīga projektējuma cēloņi
neelastīgums, nemobilitāte, viskozitāte, trauslums (R.Martin)
saistīti ar projektējuma nespēju atbalstīt prasību izmaiņas un
nodrošināt efektīvu atkarību pārvaldību (R.Martin)
Veiksmīga projektējuma principi:
Atklāts-Slēgts princips (angl. Open-Closed principle, OCP) –
modulim jābūt aizvērtam modifikācijai, bet atvērtam
paplašināšanai (abstrakcija, polimorfisms, virtuālās metodes)
Liskovas aizstāšanas princips (angl. Liskov substitution
principle, LSP). Vienkāršotā variantā - apakšklasēm jābūt
maināmām ar to bāzes klasēm; funkcija ar bāzes klases
parametru jāstrādā korekti arī ar atvasināto klasi. Atbilstība
“Projektēšana pēc kontrakta” principam (angl. Design by
Contract, DBC)
33
34. 8. Kvalitatīva OO projektējuma
pamata principi (2/2)
Atkarības apgriešanas princips (angl. Dependency Inversion
Principle, DIP) paredz atkarību no abstrakcijām nevis no realizācijām.
Saskarnes atšķelšanas princips (angl. Interface segregation
principle, ISP). Ja pastāv klase, kurai ir vairāki klienti (citas klases,
kuras to izmanto), jānodrošina specifiskas saskarnes katram klientam
atbilstoši tā vajadzībām.
Vienas atbildības princips (angl. Single Responsibility Principle,
SRP) – klasei jābūt atbildīgai par ierobežotās funkcionalitātes
realizēšanu. Piemēram, ja klase ir atbildīga gan par datu piekļuvi, gan
par to atspoguļošanu, tas ir SRP pārkāpums.
34
35. 9.Projektēšanas šablonu
novērtējums (1/2)
Šablonu kvalitātes radītāji
Empīriskais kvalitātes pierādījums
OOP principu apmierināšana (LSP,OCP,ISP,SRP,DIP)
Neatkarīga autorība
Atbilstība modularitātes principiem:
Neatbilst lingvistiski modulāras vienības principam
Atbilstošu konstrukciju un mehānismu trūkums tradicionālās objektorientētas
programmēšanas valodās
Šablona “pazaudēšana kodā”
Atbilst iekļautas dokumentācijas principam
Daļēji atbilst “Atklāts-Slēgts” principam
35
36. 9.Projektēšanas šablonu
novērtējums (2/2)
Projektēšanas šabloni = baltas-kastes atkārtotā lietošana
Produktivitātes zaudējums
Kvalitātes zaudējums
Projektēšanas komponents?
Šablonu realizācija
Idejas par šablonu attīstību programmatūras valodas elementu veidā
(K.Čamberss, B.Harisons,D. Vlissides)
“Veiksmīgas programmatūras arhitektūras abstrakcijas kādreiz arī kļūs par
valodas daļu” (B.Kristensens)
36