Aspektu orientēta prasību Aspektu orientēta prasību inženierijainženierija

Materiālu sagatavoja: L. Bušinska

Atbildīgā pasniedzēja: M. Kirikova

Izmantojamā literatūraIzmantojamā literatūraPamatgrā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/ 2

Ievads (1)Ievads (1)

3

Ievads (2)Ievads (2)

4

Aspektu orientēta programmēšana AOP (Aspect-Oriented Programming) Aspektu orientēta prasību inženierija AORE (Aspect-Oriented Requirements

Engineering) Aspektu orientēta programmatūras projektēšana AOSD (Aspect-Oriented

Software Design ) Aspektu orientēta modelēšana AOM (Aspect Oriented Modeling)

Aspektu orientētas pieejas Aspektu orientētas pieejas attīstības vēstureattīstības vēsture

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-oriented programming” (IBM T.J. Watson Research Center 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 programmatūra

Aspektu orientēta prasību inženierija, arhitektūra un projektējums

5

Kāpēc aspekti ir vajadzīgi? 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

6

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

7

8

Programmatūras kods

Prasību kopa

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

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

Prasību tipi un detalizācijas līmeniPrasī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.

9

10

Nefunkcionālo Nefunkcionālo prasību tipi un prasību tipi un

klasifikācijasklasifikācijas

AspektsAspekts 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

11

Intereses (Concerns)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

12

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ā

Attiecības starp interesēm, aspektiem, Attiecības starp interesēm, aspektiem, nefunkcionālām prasībāmnefunkcionālām prasībām

13

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

Lietotāja vajadzība Lietotāja intereses Nefunkcionālās prasības

Funkcija 1. Viegli lietojama2. Neautorizēta pieeja3. Kļūmju iespējamība

1. Lietojamība2. Drošība3. Ticamība

Veiktspēja 1. Resursu utilizācija2. Veiktspējas verifikācija3. Saskarnes vienkāršums

1. Efektivitāte2. Pārbaudāms3. Sadarbspēja

Izmaiņa 1. Viegli labot2. Viegli mainīt3. Viegli transportēt4. Viegli palielināt vai veikt

jauninājumus veiktspējas ietilpībai

1. Uzturamība2. Elastība3. Pārnesamība4. Paplašināšanas

iespējas

14

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)

Aspektu orientētas pieejas pamatidejaAspektu orientētas pieejas pamatideja

Prasību dzīves cikls aspektu kontekstā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ībasspecificēt un modularizēt aspektus atsevišķi no pārējām prasībām parādīt sasaisti starp aspektiem un pārejām prasībāmvalidēt un verificēt aspektusrisinā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

15

Aspektu noteikšana prasībās (1)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

16

Aspektu noteikšana prasībās (2)Aspektu noteikšana prasībās (2)

Katru šādu jēdzienu ir jānodala atsevišķi

17

3. ... transakcija pilnīgi izpildīta1. Apmaksāt noteiktus procentus

2. Izņemt no viņu kontiem naudu 4. ... audita vēsture ir saglabāta

Bāzes intereses Šķērsojošās intereses

Aspektu noteikšana prasībās (3)Aspektu noteikšana prasībās (3) Salikšana specificē šķērsojošās attiecības, parādot kā šķērsojošās

intereses ietekmē bāzes intereses

18

1. Apmaksāt noteiktus procentus

2. Izņemt no viņu kontiem naudu

Bāzes intereses

3. ... transakcija pilnīgi izpildīta

4. ... audita vēsture ir saglabāta

Šķērsojošās intereses

Auditēt procentu apmaksu un naudas izņemšanu

Pilnīgi pabeigt procentu apmaksāšanu un naudas

izņemšanu

Aspektu identifikācijaAspektu 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

19

Aspektu orientētas prasību Aspektu orientētas prasību inženierijas pieejasinženierijas pieejasAspektu 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 with Arcade)Uz mērķiem balstītas AO pieejas (ARGM)Uz lietošanas gadījumiem balstītas AO pieejas (AOSD/UC, Scenario Modelling with Aspects, Aspectual Use Case Driven Approach) Uz interesēm balstītas AO pieejas (Concern Modelling with Cosmos, Concern-oriented Requirements Engineering)Uz komponentēm balstītas AO pieejas (AOREC)Citas AO pieejas: Theme/Doc, ...

20

Prasības pret aspektu orientētām Prasības pret aspektu orientētām pieejāmpieejāmKatrai 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ībasTrasejamība - izsekot prasībām aspektu līmenī vēlākās attīstības fāzēs un reinženierijas fāzēsSalikums - salikt kopā atsevišķus analīzes un projektēšanas modeļus, apskatot sistēmu kā vienu veseluIespēja attīstīties - iestrādāt izmaiņas, kas ir nedalāma izstrādes sastāvdaļaMērogošana – pieejai jābūt vienādi pielietojamai gan maziem, gan lieliem projektiemValidācija un verifikācija - pārbaudīt aspektus, kas identificēti prasību līmenī

21

Uz viedokļiem balstītas AO Uz viedokļiem balstītas AO pieejaspieejas

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.

22

Uz viedokļiem balstītas AO pieejas Uz viedokļiem balstītas AO pieejas (Artifakti)(Artifakti)

23

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 Uz viedokļiem balstītas AO pieejas balstītas AO pieejas

(Process)(Process)

25

• 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)

Uz viedokļiem Uz viedokļiem balstītas AO pieejas balstītas AO pieejas

(Piemērs)(Piemērs)

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

26

Priekšrocības Trūkumi

Labāka interešu atdalīšana Nedisciplinēta programmēšana var palielināt sarežģītību

Modularitāte Lielāka nepieciešamība pēc rīku atbalsta salīdzinājumā ar tradicionālo OO pieeju

Pieļauj moduļu dekompozīciju, kuri iepriekš ir uzskatīt par monolītiem

Nevar izmantot visu veidu lietojumiem

Nodrošina labākus līdzekļus, lai identificētu un pārvaldītu konfliktus

Konkurences un Atteices vadība

Aspektu orientēta arhitektūraAspektu 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

27

Objektu orientēts projektējumsObjektu 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

28