Transcript Slide 1

Aspektu orientēta prasību
inženierija
Materiālu sagatavoja: L. Bušinska
Atbildīgā pasniedzēja: M. Kirikova
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_t
he_theme_approach.html
◦ http://www.cs.bilkent.edu.tr/AOSDEarlyAspects/Papers/AraujoCoutinho.pdf
◦ http://www.early-aspects.net/
2
Ievads (1)
3
Ievads (2)

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)
4
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-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ē
Aspektu orientēta prasību inženierija, arhitektūra un projektējums
AOSD tehnikas prasību un projektējuma līmenī izstrādātas, par pamatu ņemot AOP
sasniegumus tehniku un metodoloģiju jomā
5
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?
7
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
8
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.
9
Nefunkcionālo
prasību tipi un
klasifikācijas
10
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
11
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ā
12
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
Lietotāja vajadzība
Lietotāja intereses
Nefunkcionālās
prasības
Funkcija
1. Viegli lietojama
2. Neautorizēta pieeja
3. Kļūmju iespējamība
1. Lietojamība
2. Drošība
3. Ticamība
Veiktspēja
1. Resursu utilizācija
2. Veiktspējas verifikācija
3. Saskarnes vienkāršums
1. Efektivitāte
2. Pārbaudāms
3. Sadarbspēja
Izmaiņa
1.
2.
3.
4.
1.
2.
3.
4.
Viegli labot
Viegli mainīt
Viegli transportēt
Viegli palielināt vai veikt
jauninājumus veiktspējas
ietilpībai
Uzturamība
Elastība
Pārnesamība
Paplašināšanas
iespējas
13
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)
14

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ēt aspektus 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
15
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)

Katru šādu jēdzienu ir jānodala atsevišķi
Bāzes intereses
Šķērsojošās intereses
1. Apmaksāt noteiktus procentus
3. ... transakcija pilnīgi izpildīta
2. Izņemt no viņu kontiem naudu
4. ... audita vēsture ir saglabāta
17
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
1. Apmaksāt noteiktus procentus
2. Izņemt no viņu kontiem naudu
Šķērsojošās intereses
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
18
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
19
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 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
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ī
21
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.
22
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
23
Uz viedokļiem
balstītas AO pieejas
(Process)
24
• 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.
Uz viedokļiem
balstītas AO pieejas
(Piemērs)
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)
25
Aspektu orientētas pieejas
priekšrocības un trūkumi
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
26
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
27
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
28