• Save
LDP lecture 3
Upcoming SlideShare
Loading in...5
×
 

LDP lecture 3

on

  • 273 views

 

Statistics

Views

Total Views
273
Views on SlideShare
273
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 3 LDP lecture 3 Presentation Transcript

  • DITF LDI Lietišķo datorsistēmu programmatūras profesora grupaLietišķo datorsistēmu programmatūra 3.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 ... Projektēšanas šablons - nosauc, abstrahē un identificē galvenos projektēšanas struktūras aspektus, vērtīgus atkārtoti lietojama objektorientēta projektējuma izstrādē 2
  •  MVC projektēšanas šablons MVC izmantošana programmatūras izstrādē OO projektējuma pamata principi Ieskats aspektorientētā programmēšanā 3
  • 1. MVC projektēšanas šablonsPriekšnoteikumi- Informācijas sistēma ielādē un attēlo datus lietotājam- Lietotājs maina datus, sistēma saglābā informāciju krātuvēProblēmas- Biznesa un atspoguļošanas loģikas sajaukšana- Lietotāja saskarnes loģika mēdz mainīties biežāk par domēna biznesa loģiku, īpaši tīmekļa lietojumprogrammās- Lietotāja saskarnes realizācija vairāk par biznesa loģiku ir atkarīga no ierīces specifikas- Sistēma var atspoguļot tos pašus datus dažādos veidos 4
  • 1. MVC projektēšanas šablonsModel-View-Controller (MVC)- arhitektūras un projektēšanas šablons- pielietojams programmatūras sistēmās, lai atdalītu datu modeli sistēmas loģiku lietotāja saskarni- Struts, Spring MVC, ASP.NET MVC, ... Izmaina stāvokli Biznesa Sistēmas loģika dati 5 Pieprasa stāvokli
  • 1. MVC projektēšanas šablonsVēsture- MVC ir 33 gadus vecs- Smalltalk-80 (1980, Trygve Reenskaug)- MFC (Dokuments / View)- Java Swing- Apple Cocoa (Core Data) 6
  • 1. MVC projektēšanas šablonsMVC ModeliPasīvais - Modelis nevar ietekmēt skatu vai kontrolleri - Skati izmanto modeli par datu avotu - Kontrolleris pārvalda modeļa izmaiņas, atbild par skata atjaunošanu - Model 2 MVCAktīvais - Modelis paziņo skatus par savām izmaiņām - Skati, ieinteresēti dabūt paziņojumus par modeļa izmaiņām, pierakstās uz tiem 7
  • 1. MVC projektēšanas šablons 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 8
  • 1. MVC projektēšanas šablons 9
  • 1. MVC projektēšanas šablons Labumi  Labākā sistēmas uzturamība un testējamība  Labākā koda organizācija un strukturēšana  Izstrādes uzdevumu atdalīšana  Atkārtotā lietošana  Multi-skatu atbalsts  Jauno klientu tipu vieglākā ieviešana 10
  • 2. Kvalitatīva OO projektējuma pamata principi 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. 11
  • 2. Kvalitatīva OO projektējuma pamata principi 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. 12
  • 3.Projektēšanas šablonu novērtējums Š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 13
  • 3.Projektēšanas šablonu novērtējums Projektēšanas šabloni = baltas-kastes atkārtotā lietošana Š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) 14
  • 4. Ieskats aspektorientētā programmēšanā (1/4) Koda izkliedeif (logger.isLoggable(Level.INFO)) { logger.log(...)}...try { sessionFactory.getCurrentSession() .beginTransaction(); ... sessionFactory.getCurrentSession() .getTransaction().commit();}catch (RuntimeException re) { sessionFactory.getCurrentSession() .getTransaction().rollback(); throw re;}...if (param == null) throw new IllegalArgumentException(); 15
  • 4. Ieskats aspektorientētā programmēšanā (2/4) Koda izkliede  Koda rindas tiek atkārtotas vairākās klasēs  Parādās jebkurā izstrādes vidē  Samazina sistēmas uzturamību  Auditēšana, transakciju apstrāde, laiksakritības pārvaldība, sinhronizācija 16
  • 4. Ieskats aspektorientētā programmēšanā (3/4) Šķērsojošā funkcionalitāte (prasība) ✔ raksturīpašība, kas attiecas uz programmsistēmu kā uz vienu veselo, šķērsojot tās modulāro struktūru ✔ noteikta veida funkcionalitāte (piem., sinhronizācija), kas šķērso vairākus moduļus sistēmā 17
  • 4. Ieskats aspektorientētā programmēšanā (4/4) Aspektorientētā programmēšana  Programmatūras izstrādes paradigma koncepciju un šķērsojošās funkcionalitātes specificēšanai skaidri definētās programmatūras struktūrās (aspektos)  AOSD (programmatūras projektēšana), AORE (prasību inženierija), AOM (modelēšana)  AOP paplašina OOP  šķērsojošās funkcionalitātes implementēšana  pirmkoda izkliedēšanas novēršana  Java (AspectJ, JBossAOP); C++ (AspectC++), C# (AspectC#) 18
  • 5. AOP koncepcijas (1/2) Aspekti  šķērsojošās prasības, attiecas uz kvalitātes faktoriem vai funkcionalitāti, kurus nevar efektīvi iedalīt moduļos ar eksistējošām OOP izstrādes tehnikām Intereses (Concerns)  svarīgi sistēmas izstrādes,darbības vai citi aspekti (drošība, monitorings, transakciju vadība, laiksakritība, autorizācija) Aspektu kompilētājs (aspect weaver)  programma, kura integrē klases un aspektus  Kompilēšanas laikā  Pirmkoda vai bait-koda līmenī  Izpildes laikā 19
  • 5. AOP koncepcijas (2/2) Savienojuma punkts (Joinpoint)  Lietojuma izpildes plūsmas punkts, kurā jāpiemēro vienu vai vairākus aspektus  Metodes  Konstruktori  Izņēmuma stāvokļi  Piekļuve objektu atribūtiem Pointcut  Izteiksme savienojuma punktu kopas aprakstīšanai Padoms (Advice)  Aspekta uzvedības specificēšana (pirms, pēc, apkārt) Ieviešana (Introduction)  Atvasināšanas mehānisms jauno struktūras elementu ieviešanai lietojumā 20
  • 6. AspectJ piemērspublic aspect ArgValidationAspect {/* Pointcut declaration */ pointcut asserted(final Object target): execution(* test.pojo..*(*)) && this(target);/* Advice declaration */ before(final Object target) : asserted(target){ final Object[] args = thisJoinPoint.getArgs(); final String signature = String.valueOf(thisJoinPoint.getSignature()); for(Object o : args) { if (o==null) { throw new IllegalArgumentException(...); } }}}public class TestPojo {/** @param o Could not be NULL */public void doSmth(Object o) {}public static void main(String[] args) { new TestPojo().doSmth(null);}}Exception in thread "main" java.lang.IllegalArgumentException: 1 argument of voidTestPojo.doSmth(Object) could not be null. 21