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

9. 2.MVC. Projektēšanas šablona
piemērs (3/3)
Citi klasiskie projektēšanas šabloni:
Novērotājs (Observer), Vienpatis (Singleton), Dekorators(Decorator),
Apmeklētājs (Visitor), Rupnīca (Factory), Starpnieks (Mediator),
Atbildību ķēde (Chain of responsibility) ...
9

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

18. 4.OOP pamati
Principi
1. _________________
2. _________________
3. _________________
4. _________________
Labs OO projektējums
1. _________________
2. _________________
3. _________________
18

19. 5.Projektēšanas šablonu
izmantošana (1/5)
1
Duck
quack()
swim()
display()
fly()
// ...
MallardDuck RedheadDuck
display() { display() {
//... // ...
} }
19

20. 5.Projektēšanas šablonu
izmantošana (1/5)
1 2
Duck Duck
quack()
quack() swim()
swim() display()
fly()
display() // ...
fly()
// ...
MallardDuck RedheadDuck RubberDuck
display() display()
{ { display()
//... // ... quack()
MallardDuck RedheadDuck } } fly() {
//
display() { display() { }
//... // ...
} }
20

21. 5.Projektēšanas šablonu
izmantošana (2/5)
Duck
3 quack()
swim() DecoyDuck
display()
fly() display()
quack() {
//
}
MallardDuck RedheadDuck RubberDuck
fly() {
display() { display() { //
//... // ... display()
} } quack()
fly() {
//
}
1. Koda dublēšanās apakšklasēs
2. Sarežģītas uzvedības izmaiņas izpildes laikā
3. Grūtības dabūt zināšanas par visiem uzvedības variantiem
4. _____________________________
5. _____________________________
21

22. 5.Projektēšanas šablonu
izmantošana (3/5)
4
Flyable
Duck
fly()
swim()
display()
//
MallardDuck RedheadDuck RubberDuck DecoyDuck
display() display() display() display()
fly() fly() quack()
quack() quack()
?!
Quackable
quack()
22

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

24. 5.Projektēšanas šablonu
izmantošana (5/5)
 Identificēt lietojuma mainīgus aspektus,
atdalīt tos no stabiliem, iekapsulēt
 Izmantot saskarnes konkrēto realizāciju
vietā FlyBehaviour
 Dot priekšroku kompozīcijai fly()
FlyWithWings FlyNoWay
fly() fly()
Duck
FlyBehaviour fb
QuackBehaviour qb
swim()
display() QuackBehaviour
performQuack()
performFly() quack()
MallardDuck DecoyDuck
RedheadDuck
Quack Squeak
display() RubberDuck display()
display() quack() quack()
display()
MuteQuack 24
quack()

25. 6.Projektēšanas šablonu
izmantošana (1/2)
“Tomato” piemērs
Problēmas:
1. __________________
2. __________________
3. __________________
4. __________________
25

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

27. Vairāk projektēšanas šablonu ?
Abstract Builder
factory
Prototype Facade
Factory
method Adapter Bridge
Singleton
Composite Proxy
Decorator
Flyweight
Chain of
responsibility
Memento
Command Interpreter
Mediator
State
Iterator Strategy
Visitor
Observer
Template
method ...
27

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