• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
LDP lecture 2
 

LDP lecture 2

on

  • 307 views

 

Statistics

Views

Total Views
307
Views on SlideShare
307
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    LDP lecture 2 LDP lecture 2 Presentation Transcript

    • DITF LDI Lietišķo datorsistēmu programmatūras profesora grupaLietišķo datorsistēmu programmatūra 2.lekcija Materiālu sagatavoja: V.Kotovs Atbildīgais pasniedzējs: prof. L.Novickis
    • ... 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 3.Šablonu klasifikācija (1/2) Konceptuāli Programmatūras šabloni šabloni Projektēšanas principi Arhitektūras Projektēšanas šabloni šabloni IdiomasProgrammatūras arhitektūras šabloni apraksta vispārējus programmatūras arhitektūras strukturēšanas principusProjektēšanas principi nosaka fundamentālas programmatūras sistēmu projektēšanas idejas un principusKonceptuā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 idejasProjektēšanas šabloni
    • 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
    • 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)
    • Memento Proxy Saglabā iterāciju stāvokli Adapter Builder Bridge Iterator Izveido Uzskaita elementus Papildina elementu Command funkcionalitāti Sastadīti ar Composite Definē ķēdiDecorator 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 izmantoPrototype Dinamiski konfigurē Factory Izveidots ar method Abstract factory Viens eksemplārs Viens eksemplārs Facade Singleton
    • “Stratēģija” projektēšanas šablonsNolūks: Definē algoritmu kopu, iekapsulē tos atsevišķajos objektos un nodrošina to izmaiņas iespējuKonteksts- 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ā
    • “Stratēģija” projektēšanas šablonsRisinā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()
    • “Abstraktā rūpnīca” projektēšanas šablonsNolū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ā
    • “Abstraktā rūpnīca” projektēšanas šablonsRisinā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
    • 4.OOP pamatiPrincipi1. _________________2. _________________3. _________________4. _________________Labs OO projektējums1. _________________2. _________________3. _________________ 18
    • 5.Projektēšanas šablonu izmantošana (1/5)1 Duck quack() swim() display() fly() // ... MallardDuck RedheadDuck display() { display() { //... // ... } } 19
    • 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
    • 5.Projektēšanas šablonu izmantošana (2/5) Duck3 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
    • 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
    • 5.Projektēšanas šablonu izmantošana (4/5)“Stratēģija” projektēšanas šablonsDefinē algoritmu kopu, iekapsulē tos un nodrošina to apmaiņas iespējuKonteksts- 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
    • 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()
    • 6.Projektēšanas šablonu izmantošana (1/2)“Tomato” piemērsProblēmas:1. __________________2. __________________3. __________________4. __________________ 25
    • 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
    • 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
    • 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
    • 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
    • 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
    • 7. MVC šablons. Struts (4/5)STRUTS 1 augstākā līmeņa arhitektūra 31
    • 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
    • 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
    • 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
    • 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
    • 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