Aspektu orientēta prasību inženierija

1. Aspektu orientēta prasību inženierija Materiālu sagatavoja: L. Bušinska Atbildīgā pasniedzēja: M. Kirikova

2. Izmantojamā literatūra • Pamatgrāmata • Survey of Analysis and Design Approaches Type: Survey Language: English Version: 1.0 Date: 18 May 2005 Document ID: AOSD-Europe-ULANC-9 • Interneta resursi • http://www.comp.lancs.ac.uk/computing/aod/index.htm • http://www.aosd.net/wiki/index.php?title=Glossary • http://ebuki.lionhost.ru/2007/02/06/aspectoriented_analysis_and_design_the_theme_approach.html • http://www.cs.bilkent.edu.tr/AOSD-EarlyAspects/Papers/AraujoCoutinho.pdf • http://www.early-aspects.net/

3. Ievads (1)

4. Ievads (2) • Aspektu orientēta programmēšana AOP (Aspect-OrientedProgramming) • Aspektu orientēta prasību inženierija AORE (Aspect-OrientedRequirementsEngineering) • Aspektu orientēta programmatūras projektēšana AOSD (Aspect-OrientedSoftwareDesign ) • Aspektu orientēta modelēšana AOM (AspectOrientedModeling)

5. Aspektu orientētas pieejas attīstības vēsture Aspektu orientēta programmatūra Galvenās pieejas, kuras var uzskatīt par Aspektu orientētas programmatūras (AOP) pirmavotiem: • Pieeja, kas balstās uz AspectJ valodu (Xerox PARC komanda, 1997.g.) • „Subject-orientedprogramming” (IBM T.J. WatsonResearchCenter komanda, 1993. g.) • Pieeja, kas balstās uz kompozīcijas filtriem ( viena no Holandes universitātēm, 1990. g.) • Demeter metode (viena no universitātēm Savienotajās valstīs, 1990.g.) • D-Java valoda un pirmā oficiāla AOP valodu kopa (1997.g.) • Aptuveni 2004. gadā AOP valodas sāka plaši pielietot praksē AOSD tehnikas prasību un projektējuma līmenī izstrādātas, par pamatu ņemot AOP sasniegumus tehniku un metodoloģiju jomā Aspektu orientēta prasību inženierija, arhitektūra un projektējums

6. Kāpēc aspekti ir vajadzīgi? • Tradicionālajās pieejās pastāv “dominējošās dekompozīcijas tirānija” – balstās uz pieņēmumu, ka prasības sistēmas īpašībai var viennozīmīgi piesaistīt kādai sistēmas komponentei (piem., klasiskās OO pieejas) • Pastāv vairākas prasību klases (aspekti jeb šķērsojošās prasības), kurām skaidra iedalīšana moduļos nav iespējama ar „tradicionālajām” programmatūras paradigmām: • raksturīpašības (piem., kvalitātes faktori), kas attiecas uz programmsistēmu kā uz vienu veselo, šķērsojot tās modulāro struktūru • noteikta veida funkcionalitāte (piem., izplatīšana, sinhronizācija), kas šķērso vairākus moduļus sistēmā • Ja kādas prasības nevar efektīvi iedalīt moduļos, nav iespējams spriest par to ietekmi uz sistēmu un spriest par to savstarpējo ietekmi • Šķērsošanās ir kompleksu sistēmu raksturīga pazīme

7. Kāpēc aspekti ir vajadzīgi?

8. Kāpēc aspekti ir vajadzīgi? OOP valodās koda rindas tiek atkārtotas ļoti daudz dažādās objektorientētās klasēs, jo šīm klasēm ir vajadzīga viena un tā pati funkcionalitāte. Rezultātā nav iespējas tos iestarpināt vienā vietā: piem, auditēšana, transakciju apstrāde, laiksakritības pārvaldība, sinhronizācija. Pastāv vairākas prasību klases, kuras šķērso programmsistēmas modulāro struktūru Prasību kopa Programmatūras kods

9. Prasību tipi un detalizācijas līmeni • Prasības - Prasības tiek formulētas kā intereses (eng., concerns) un ir specifiskas projektam vai projektiem • Ierobežojumi - Ierobežojumi tiek definēti, lai ierobežotu biznesa problēmai iespējamo risinājumu kopu.

10. Nefunkcionālo prasību tipi un klasifikācijas

11. Aspekts • Aspekts – ir objektorientētas paradigmas dabīgais turpinājums • Aspekts – ir šķērsojošās prasības (crosscutting requirements), kas attiecas uz tādiem kvalitātes programmatūras faktoriem vai funkcionalitāti (drošība, sinhronizācija utml.), kurus nevar efektīvi iedalīt moduļos ar eksistējošām programmizstrādes tehnikām • Aspekti – ir tādas funkcionālās vai nefunkcionālās prasības, kas šķērso vairākas intereses. Tātad aspekts ir intereses (conern) viena kategorija

12. Intereses (Concerns) • Intereses – ir “kaut kas, kas ir jāņem vērā izstrādātājam” (piem.,funkcionalitāte, prasības,..) • Intereses – ir “... jautājumi, kuri attiecas uz sistēmas izstrādi, tās darbību un jebkuri citi aspekti, kas ir kritiski vai svarīgi kādam no sistēmas īpašniekiem“ IEEE. Piemēram, drošība, reģistrācijas žurnāli, stabilitāte, darbības monitorings, atmiņas optimizācija • Intereses veidi: • Vispārējās - intereses, kas ir katrā lietojumā (stabilitāte, darbības monitorings) • Specifiskās - intereses, kuras var identificēt tikai noteiktos lietojumos (iegūstamas vai nu prasību definēšanas procesā vai aspektu izguves (mining) procesā

13. Attiecības starp interesēm, aspektiem, nefunkcionālām prasībām • Ieinteresētajām pusēm parasti ir vairākas ‘intereses’ • Intereses vairākos gadījumos ir nefunkcionālas, tādējādi tās varētu sasaistīt ar nefunkcionālām prasībām. Savukārt, nefunkcionālās prasības ir kandidāti uz aspektiem

14. Aspektu orientētas pieejas pamatideja • Prasību inženierijas laikā aspekti un bāzes prasības tiek glabāti kā atsevišķas dimensijas • Aspektiem jeb šķērsojošajām interesēm: • ir skaidrs iemesls (Kas) • ir regulāri mijiedarbības punkti(Kur un Kad)

15. Prasību dzīves cikls aspektu kontekstā Aspektu orientētas prasību inženierijas procesā papildus tradicionālajām aktivitātēm jābūt līdzekļiem, kas ļauj: • noteikt un izprast iespējamos aspektus jeb šķērsojošās prasības • specificēt un modularizētaspektus atsevišķi no pārējām prasībām • parādīt sasaisti starp aspektiem un pārejām prasībām • validēt un verificēt aspektus • risināt konfliktus • pārvaldīt prasības, t.i., izsekot prasībām aspektu līmenī vēlākās attīstības fāzēs un reinženierijas fāzēs

16. Aspektu noteikšana prasībās (1) • Lai sameklētu šķērsojošās prasības, jāskatās uz terminiem vai jēdzieniem, kas apraksta uzvedību un kas ir minēti vairāk nekā vienu reizi 1. Apmaksāt noteiktus procentus katrā kontā, pārliecinoties, ka transakcija pilnīgi izpildīta un ir saglabāta audita vēsture. 2. Jāļauj klientiem izņemt no viņu kontiem naudu, pārbaudot, ka transakcija pilnīgi pabeigta un audita vēsture ir saglabāta

17. Aspektu noteikšana prasībās (2) • Katru šādu jēdzienu ir jānodala atsevišķi • Bāzes intereses • Šķērsojošās intereses 1. Apmaksāt noteiktus procentus 2. Izņemt no viņu kontiem naudu 3. ... transakcija pilnīgi izpildīta • 4. ... audita vēsture ir saglabāta

18. Aspektu noteikšana prasībās (3) • Salikšana specificē šķērsojošās attiecības, parādot kā šķērsojošās intereses ietekmē bāzes intereses • Bāzes intereses • Šķērsojošās intereses 1. Apmaksāt noteiktus procentus 2. Izņemt no viņu kontiem naudu 3. ... transakcija pilnīgi izpildīta • Pilnīgi pabeigt procentu apmaksāšanu un naudas izņemšanu • 4. ... audita vēsture ir saglabāta • Auditēt procentu apmaksu un naudas izņemšanu

19. Aspektu identifikācija • Prasības var tikt savāktas no dažādiem avotiem: • Intervijas, rokasgrāmatas, uzmetumi • Standartizācijas dokumentācija • Organizācijas procedūras • Prasības var būt aprakstītas dažādos veidos: • Dabīgajā valodā • Modeļos • Formālajās specifikācijās

20. Aspektu orientētas prasību inženierijas pieejas Aspektu orientētas programmatūras izstrādes (AOSD) tehnikas ļauj sistemātiskā veidā identificēt, modularizēt (modularisation), aprakstīt un salikt kopā (composition) šķērsojošās prasības. Var izdalīt šādas AOSD tehniku grupas: • Uz viedokļiem balstītas AO pieejas (AORE withArcade) • Uz mērķiem balstītas AO pieejas (ARGM) • Uz lietošanas gadījumiem balstītas AO pieejas (AOSD/UC, ScenarioModellingwithAspects, AspectualUseCaseDrivenApproach) • Uz interesēm balstītas AO pieejas (ConcernModellingwithCosmos, Concern-orientedRequirementsEngineering) • Uz komponentēm balstītas AO pieejas (AOREC) • Citas AO pieejas: Theme/Doc, ...

21. Prasības pret aspektu orientētām pieejām Katrai jaunai pieejai ir jābūt tik pat labai kā tradicionālās pieejas, līdz ar to tai jānodrošina arī vispārējās kvalitātes prasības: • Modelēšana - identificēt un modelēt funkcionālās un nefunkcionālās šķērsojošās un nešķērsojošās prasības • Trasejamība - izsekot prasībām aspektu līmenī vēlākās attīstības fāzēs un reinženierijas fāzēs • Salikums - salikt kopā atsevišķus analīzes un projektēšanas modeļus, apskatot sistēmu kā vienu veselu • Iespēja attīstīties - iestrādāt izmaiņas, kas ir nedalāma izstrādes sastāvdaļa • Mērogošana – pieejai jābūt vienādi pielietojamai gan maziem, gan lieliem projektiem • Validācija un verifikācija - pārbaudīt aspektus, kas identificēti prasību līmenī

22. Uz viedokļiem balstītas AO pieejas • Viena no pirmām pieejām, kas piedāvāja aspektu orientēto jēdzienu prasību līmenī. • Pieeja balstās uz PREview tehniku un XML valodas salikšanas (composition) mehānismiem • Atšķirībā no PREview šī pieeja papildus nodrošina prasību iedalīšanu moduļos un salikšanu, pārbaudot prasību pilnīgumu. Tas tiek panākts, identificējot konfliktus starp viedokļiem, jēdzieniem un prasībām.

23. Uz viedokļiem balstītas AO pieejas (Artifakti) • Redzesviedokli un ar tiem saistītas prasības/apakšprasības • Intereses un ar tiem saistītas prasības/apakšprasības - mērķa jēdziena vispārinājums; tās ietver gan organizācijas mērķus, gan ierobežojumus. Intereses izmanto kā līdzekli prasību atrašanai • Salikšanas likumi -specificē attiecības starp aspektiem (prasībām definētām priekš interesēm) un redzesviedokļļ prasībām. • Ierpbežojumu zīme - izmanto salikšanai, jo tā parāda kā redzesviedokļu prasības ierobežojas ar aspektualām prasībām • Matricas -ļauj sasaistīt intereses savā starpā un ar redzesviedokliem, kā arī tās izmanto, lai norādītu svarus konfliktējošām prasībām risinot konflikta situācijas • PROBE - standartu lineārā temporālā loģika, kas nodrošina starndatu obligātumu

24. Uz viedokļiem balstītas AO pieejas (Process)

25. Uz viedokļiem balstītas AO pieejas (Piemērs) • Katram redzesviedoklim un aspektam tiek norādīts unikālais identifikators (id=) • Katram redzesviedoklim un aspektam ir unikālais nosaukums un katrs no tiem ietver prasību un apakšprasību kopu. Funkcionalitāte ‘pieeja depozītam’ aspektā CacheAccess ir jānodrošina numura rezervēšanai un cenu apskatīšanai, kas ir redzesviedokļa Customer prasības (id=1)

26. Aspektu orientētas pieejas priekšrocības un trūkumi

27. Aspektu orientēta arhitektūra PCS, DAOP-ADL, AOGA, TranSAT, ASAAM,... • Atšķirība starp • Arhitektūras interesēm, kuras var lokalizēt izmantojot arhitektūras abstrakcijas • Arhitektūras interesēm, kuras šķērso vairākus arhitektūras moduļus

28. Objektu orientēts projektējums AODM, Theme/UML, SUP, UFA, AML, CoCompose .... • Aspektu specificēšana projektējuma līmenī • Notācija • Kompozīcijas specifikācija • Aspektu integrācijas precīza semantika