Aspect-Oriented Software Development with Use Cases. Jacobson.2004.Addison-Wesley.
Ohjelmistotekniikan jatkoseminaari.
Tampereen teknillinen yliopisto. Porin yksikkö 2007

Mitä on Aspect Oriented Software Programming

Aspektiperustainen ohjelmointi (Aspect-oriented programming - AOP) on Xeroxin Palo Alton tutkimuskeskuksessa kehitetty ohjelmointimenetelmä, jonka avulla läpileikkaavat (cross-cutting) ominaisuudet voidaan kerätä yhteen paikkaan, jolloin niiden käsittely on helpompaa ja ohjelmakoodista saadaan siistimpää.
Läpileikkaavat ominaisuudet ovat toimintoja, joita käytetään useissa luokissa tai proseduureissa.

Mitä on Aspect Oriented Software Development ?
• Aspektiperustaisessa ohjelmistokehityksessä (aspect-oriented software development, AOSD) koko ohjelmistoa läpileikkaavat ominaisuudet kuvataan paitsi suunnittelussa myös ohjelmakoodin tasolla muusta luokkarakenteesta (ja toisistaan) erillisinä aspekteina.
• Aspektiympäristöön kuuluva punoja (weaver) yhdistää sitten aspektikuvaukset ja luokat erityisten liitoskohtien (join point, point cut) avulla suoritusvalmiiksi ohjelmaksi.
• Automaattinen punominen mahdollistaa myös uusien aspektien lisäämisen (esim. uuden lokitietojen tallennuspolitiikan käyttöönoton) ilman muutoksia muuhun järjestelmään.

Mitä on Aspect Oriented Software Development
• AOP:tä varten, tarvitset kokonaisvaltaisen lähestymistavan ohjelmistojärjestelmän kehittämiseen johon kuuluu näkökulmat vaatimuksista analysointiin and suunnitteluun, toteutukseen ja testaukseen.
• AOSD tarkoittaa parempaa modulariteettia koko järjestelmälle.
• parempi modulariteetti funktionaalisille vaatimuksille ja ei- funktionaalisille vaatimuksille
• rakentaa järjestelmä jolla on ymmärrettävämpi rakenne
Aspektiohjelmoinnin tarkoitus
• Aspektipohjaisella ohjelmoinnilla tarkoitetaan aspektien modularisoimista, koostamista ja uudelleenkäyttöä.
• Aspektiohjelmoinnin avulla voidaan ohjelmakoodista tehdä selkeämpää ja helpommin ymmärrettävää kuin perinteisten menetelmien, kuten olio-ohjelmoinnin tai proseduraalisen ohjelmoinnin avulla.
• Erityisesti ohjelmistojen muunneltavuuden ja uudelleenkäytön avuksi on kehitetty aspektiperustaisia menetelmiä.
Mitä järkeä, missä käytetään ja miten tehdään ?
• Eri asioiden erottaminen ja erillään pitäminen lähdekoodin tasolla
• Käytännön sovelluksia jäljitys (tracing), profilointi, lokit, jne
• Kerrotaan mihin kohtaan sovellusta aspekti kiinnittyy
– join point, kohta johon voi kiinnittyä
– point cut, mihin join pointiin tartutaan
– advice, mitä koodia ja ennen vai jälkeen join pointin se suoritetaan


Aspektiohjelma
Koostuu:
• kehotteista (advice):
– aspektien ohjelmakoodi
• liitoskohdista (join point):
– metodin alku/loppu
– poikkeusten käsittelijät
– liitoskohdan valitsin (pointcut designator)
• liitoskohtamäärityksistä (pointcut):
– kuvataan ne perusohjelman kohdat, joihin aspekti punotaan
– sidotaan aspektin kehote yhteen tai useampaan liitoskohtaan perusohjelmassa
– http://www.cs.helsinki.fi/u/eeanttil/seminaari/johdatus_aspektikasitteistoon.ppt#20


Aspektiohjelmointi
• Aspekti = näkökulma
• mahdollisuus esittää useita jaotteluperusteita
• kapseloidaan ohjelman läpileikkaavia ominaisuuksia
• Mielenkiinnon kohde (concern)
– eri mielenkiinnon kohteet johtavat erilaisiin jaotteluihin tai modularisointeihin
– voidaan kutsua myös jaotteluperusteeksi

Aspektiohjelmoinnin tavoite
• Aspektiohjelmoinnin tavoitteena ohjelmiston läpileikkaavien ominaisuuksien kapselointi
• Aspektit punotaan perusohjelmaan
• Staattinen aspektiohjelmointi
– Aspektit punotaan käännösaikana
– Tunnetuin ohjelmointikieli AspectJ
• Dynaaminen aspektiohjelmointi
– Aspektit punotaan ajonaikana

Aspektiohjelmointi
• Pystytään kapseloimaan koko ohjelman läpileikkaavia ei-toiminnallisia ominaisuuksia
• Ohjelma jaetaan kahteen eri osaan:
– perusohjelmaan
• ohjelman toiminnalliset osat
• ei tarvitse tietää aspekteista
– aspektiohjelmaan
• ei-toiminnalliset osat, sekä kuvaus niiden liittämisestä perusohjelmaan
• muutokset riittää tehdä yhdessä paikassa


Esimerkki
aspect SimpleTracing {
pointcut tracedCall():
call(void Figure.Draw(graphicContext));

before: tracedCall() {
System.out.println( ”Entering: ” + thisJoinPoint);
}
}


Aspektien edut
• ohjelmiston läpileikkaavat toiminnot voidaan modularisoida. (ei tarvitse monistaa)
• ohjelmakoodista tulee selkeämpää
• ohjelmistojen muuttaminen on helpompaa
• ohjelmistojen kehityssyklin nopeus ja hallittavuus paranee
• arkkitehtuurisia ratkaisuja helpompi vaihtaa
• aspektin toteuttavalle toiminnallisuudelle vastuuhenkilö
• aspektien toiminnallisuutta voidaan uudelleen käyttää

AOSD ja Use Cases
• systemaattinen lähestymistapa on use-case-driven lähestymistapa.
• se tarjoaa metodin kehityssovelluksille keskittymällä mielenkiinnon kohteiden toteuttamiseen.
• auttaa modularisoimaan mielenkiinnon kohteita
• käyttötapaukset ovat läpileikkaavia mielenkiinnon kohteita
• voit mallintaa läpileikkaavia mielenkiinnonkohteita käyttötapauksilla toteuttamalla ne aspektien kanssa.


• Komponentteihin perustuva kehitys on lähestymistapa rakentaa monimutkaisia systeemejä.
• jaat vaatimukset komponenteille kuten classes, packages, services jne.
• monia vaatimuksia ei voi paikallistaa tiettyyn komponenttiin vaan ne vaikuttavat moniin komponentteihin eli nämä vaatimukset läpileikkaavat komponentit ja niitä kutsutaan läpileikkaaviksi komponenteiksi.

The Use of Components Today

• jokaisella komponentilla on oma erityinen roolinsa ja vastuualueensa ja tarkoituksensa.
• komponentit muodostavat hyvin määriteltyjä rajapintoja
• ne tuottavat määriteltyjä vasteita, kuten tietokoneen komponentit.
• komponentti kapseloi sisältönsä
• ei tarvitse tietää miten komponentti toimii
• pitää vain osata lähettää oikea signaali rajapintaan ja saada haluttu vaste
• käytetään sopivinta komponenttia

Järjestelmän rakentaminen komponenttien avulla
Tavallisesti lähdetään liikkeelle järjestelmän ymmärtämisestä
• mitkä ovat vaatimukset
• tutkit ja tunnistat osat
• kartoitat vaatimukset komponenttien maailmaan.
• voi olla 1000 vaatimusta ja 50 komponenttia
• valitset valikoiman komponenteista ja tarkistat, että kaikki vaatimukset toteutuvat ko. komponenteilla
Kirjan esimerkkinä Hotel Management System
Hotel Management System
• Hotel Management System made up of interconnected components

Komponenttien edut
• komponentit edustavat järjestelmän pysyvää rakennetta
• niiden avulla voi ymmärtää koko järjestelmää.
• komponentti voi sisältää esim. huoneen varausjärjestelmän muuntelun.
• komponenttien avulla järjestelmää voi muuttaa asiakkaan vaatimusten mukaan.

Komponenttien rajoitukset
• Komponenttien rajoituksia lähestytään mielenkiinnon kohteiden kautta
• mielenkiinnon kohde voi olla funktionaalinen vaatimus tai ei-funktionaaliset vaatimukset
• mielenkiinnonkohde voi olla mikä tahansa ,joka on kiinnostuksen kohde loppukäyttäjälle, kehittäjälle jne.
• mielenkiinnon kohteiden erotteleminen on ongelmien pilkkomista pienempiin osiin
• tutkitaan ja kerätään vaatimuksia
• infrastruktuurin mielenkiinnon kohteet ovat läpileikkaavia mielenkiinnon kohteita

Laajennukset
• Laajennukset ovat komponentteja, jotka määritellään on top of the base.
• Hotellin varausjärjestelmässä varallaololistan jaotteluperuste on laajennus
• glue code: koodi joka lisätään uutta ominaisuutta varten

Arkkitehtonisesti merkittävät prosessielementit
Approaching a Solution
Saavuttaaksesi uuden modulariteetin tarvitset:
Ø mielenkiinnon kohteiden erottelutekniikkaa
Ø mielenkiinnonkohteiden muodostustekniikkaa

Varhainen tuki laajennuksille
• avainidea on, että sijoitat laajennuksen käännöksen tai suorituksen aikana.
• systeemin laajentaminen on helpompaa
• systeemi on ymmärrettävämpi
• tuki laajennuksille saavutetaan joko käännöksen tai suorituksen aikana.

Laajennukset
Support for Extension in UML
• käyttötapaustekniikka tarjoaa keinot määritellä miten laajennuksen ominaisuudet on sisällytetty laajennuksiin

Tarttuminen ongelmaan aspektien avulla
• Aspektiohjelmointi on kokoelma teknologioita, joiden tarkoitus tarjota parempi erottelu läpileikkaaville mielenkiinnonkohteille
• intertype declarations sallivat sinun muodostaa uusia ominaisuuksia olemassa oleviin luokkiin.
• Advices(neuvot) tarjoavat keinot laajentaa olemassaolevia toimintoja laajennuskohdissa point cuts:ien avulla

Keeping Peers Separate with Aspects
• Hotellivarausjärjestelmän toiminnallisuudet:
Ø varataksesi huoneen, tarkistat onko huone vapaa
Ø kun asiakas kirjoittautuu sisään, varaat hänelle huoneen.
Ø kun kirjaat asiakkaan ulos, laadit laskun.


Keeping Peers Separate
Classes composed from different concerns
Laajennukset pidetään erillään aspektien avulla
• tunnista laajennuskohdat (extension points) olemassa olevassa toiminnossa, johon behavior laajennetaan
• määrittele the additional behavior , jota käytetään laajentamaan the behavior laajennuskohdissa.
makeReservation operation
• Figure 2-2: vaiheet makeReservation toiminnossa

Use Cases nykyään
• Jokainen Use Case on järjestelmän behavior, kun ollaan vuorovaikutuksessa käyttäjän kanssa.
• Siinä on kyse variaatioista, joita järjestelmän pitää käsitellä toteuttaakseen käyttäjän tarpeet
• Jacobson esitteli Use Casen ja use-case-driven-development ensimmäisenä 1987

Mikä on Use Case ?
• Use Case on toimintojen jakso, jonka systeemi suorittaa saadakseen aikaan havaittavan tuloksen käyttäjälle
• Jokainen Use Case kuvaa välttämättömiä toimintoja tehtävän suorittamiseksi.
• use-case malli sisältää toimijat, use cases, ja suhteet niiden välillä

Use cases for Hotel management System
• kaksi päätoimijaa ovat asiakas, joka varaa huoneen ja hotellin vastaanottovirkailija, joka kirjaa asiakkaan sisään ja ulos.

Use-Case-Driven Development
suorita seuraavat toiminnot:
• etsi use cases ja määrittele jokainen niistä.
• suunnittele jokainen use case
• suunnittele ja toteuta jokainen luokka(class)
• testaa jokainen use case

Use Case:ien roolit ja hyödyt
• Use Case:ien avulla voidaan hallita kiinnostuksenkohteita(concerns) tehokkaasti
• Use Cases ovat hyödyllisiä järjestelmän rakentamiseksi
• Use Case:ejä voidaan käyttää Test Case:einä
• Use Case:t helpottavat suunnittelua

Ongelmat Use-Case tekniikassa
• Pääasiallinen ongelma on, että perinteiset ohjelmointikielet eivät tue läpileikkaavien ominaisuuksien erottelua, niinpä erilaisten Use Case:ien vaikutuksia luokkaan ei voida erotella.
• Seurauksena et voi erotella peer use cases and laajennus use cases toteutuksen aikana.(s.35)

Use Case modulien tulevaisuus
• Use Case:t tarjoaa keinot mallintaa ja erotella läpileikkaavat ominaisuudet tehokkaasti, mutta ominaisuuksien erottelu pitää säilyä läpi suunnittelun ja toteutuksen
• This means that you have to collate the specifics of a use case during design in some modularity unit, joita kutsumme nimellä use-case slice
Järjestelmän rakentaminen on Overlays with Use-Case Slices
• kun toteutat use case:n, tunnistat vaaditut luokat ja näiden luokkien ominaisuudet (attributes, operations and realtionsships)
• Jokainen use-case slice keeps the specifics of a use-case realization yhdessä mallissa
• Use-case slices ovat erillisiä elementtirakenteesta
Element structure space and use-case slices
Figure 4-1

Use cases and classes in the Hotel Management system

Laajennus Use Case
Kehitystyö Use-Case Moduulien kanssa
• kyky työskennellä use-case modulien kanssa itsenäisesti vaikuttaa tapaan ohjata ohjelmiston kehitystä.
• työskentely jokaisen use-case modulin kanssa voi edetä erikseen separately ja rinnakkain erillisenä projektina.
Use-case modulien muodostaminen toistuvasti

Modeling and Concerns with Use Cases
• Use-case tekniikka tarjoaa keinot systemaattisesti mallintaa mielenkiinnonkohteita kulkemalla läpi interaktioiden käyttäjien ja systeemin välillä.
• ominaisuudet pitää tunnistaa ja muodostaa oikein suunnittelun ja toteutuksen avulla.
• ominaisuuksien erottelu pitää aloittaa vaatimusmäärittelyssä.

Modeling Concerns with Use Cases
• Ohjelmistokehitys alkaa mielenkiinnonkohteiden ymmärtämisestä.
• use-case tekniikka mallintaa mielenkiinnonkohteita kulkemalla läpi käyttäjien ja systeemin vuorovaikutuksen.

Use-Case mallinnus
• use case:t ovat keino määritellä vaadittu systeemin käyttö
• Vaadittu käyttö on määritelty yhdellä tai useammalla use case:lla.
• use case malli sisältää kaikki systeemin use case:t

Use-Case Instanssit ja tapahtuma virrat
• suoritus of a use-case instance(Customer wants to reserve a room)
• kun use case on käynnistetty, dialogi use case instanssin ja toimijan välillä voi alkaa

Use Case:ien kuvaaminen
• Use Case:n kuvauksessa aloitetaan yksinkertaisimmasta skenaariosta ja kuljetaan sen tapahtumajaksojen kautta
• kun pääasiallinen toiminto on kuvattu, kuvatan miten erilaisia variaatioita käsitellään


Lähteet
Jacobson. Aspect-Oriented Software Development with Use Cases. Addison-Wesley.2004
Tommi Mikkonen. Aspect-Oriented Programming part II: Luento Oliopäivillä.2007
http://www.cs.helsinki.fi/u/ktkonone/aop-evoluutio.pdf 17.5.2007
http://www.cs.helsinki.fi/u/eeanttil/seminaari/johdatus_aspektikasitteistoon.ppt#10 17.5.2007
http://www.helsinki.fi/~teerioja/seminaari/aop.pdf.Aspektipohjainen ohjelmointi.Jani Teerioja. Tietojenkäsittelytieteen seminaari, syksy 2003. Tietojenkäsittelytieteen laitos, Helsingin Yliopisto
http://www.helsinki.fi/~pyhajarv/seminaari/reflektio.pdf. 8.10.2007