10. Luento: Kohti suurempia sulautettuja ohjelmistoja Tommi Mikkonen, tommi.mikkonen@tut.fi
Agenda Johdanto Ohjelmistopino Siirrettävyydestä Vuotavat abstraktiot Joitakin suunnitteluratkaisuja Formaali vai epäformaali menetelmä? Yhteenveto
Johdanto Sulautetut järjestelmät muuttuneet monimutkaisemmiksi Vertailun vuoksi: Apollo 8:n tietokone vetää vertoja nykyiselle (yksinkertaiselle) taskulaskimelle Kännykkä on kuin muutaman vuoden takainen PC Laitteisto nopeampaa, muistia enemmän, hajautus tarpeen mukaan Ohjelmiston kasvava rooli; samat ongelmat kuin mitä aiemmin pöytätietokoneissa Muunneltavuus, ylläpidettävyys, luotettavuus, jne
Ohjelmistopino (http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp? templateid=6123&navigationid=12844&contentid=53244)
Siirrettävyydestä Joskus välttämätöntä vaikka vain 1 kohdelaite (esim. emulaattori, simulaattori, laite itse) Useamman kohdelaitteen tapauksessa yleensä väistämätöntä Useita käytännön menetelmiä; tässä Ehdollinen käännös ( #ifdef ARM ) Ohjelmamakrot ( #define nelio (x) ((x)*(x)) 1 ) Moduulien erillinen toteutus Skriptit, konfiguraatiotiedostot, jne. Usein kannattaa käyttää useampaa kääntäjää! 1 Miksi muuten näin monet sulut?
Vuotavat abstraktiot Esimerkki: 0-loppuinen merkkijono char * strcat(char * c1, char * c2) { int i, j; while(i = 0; 0!= c1[i]; i++); while(j = 0; 0!= c2[j]; j++, i++) c1[i] = c2[j]; c1[i+1] = 0; return c1;
Vuotavien abstraktioiden vaikutus ohjelmointiin Abstraktioiden vuotaminen (ts. toteutustekniikka näkyy ohjelmoijalle) tapahtuu yleensä ääritilanteissa Suorituskyvyn ylitys Muistin loppuminen Ongelmat tietoliikenteessä Varautuminen yleisessä tapauksessa vaikeaa sillä vuotava abstraktio voi olla juuri vuotoon varautuva resurssi Nyrkkisääntö: Varaa ääritilanteisiin tarvittavat resurssit etukäteen!
Esimerkki public void push(object e) { ensurecapasity(); // Check slots count elements[size++] = e; public Object pop() { if (size == 0) throw new EmptyStackException(); return elements[--size]; Ok?
Pino johon viitteet kerätään size Stack Objects stored in Stack
ja vuotava abstraktio! Objects stored in Vector but not in Stack size Stack/Vector Objects stored in Stack
Korjaavat toimenpiteet public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; return result;
Sulautetun järjestelmän erityishaasteita Niukat resurssit Muisti, prosessori, levytila, kommunikointikanavat, jne. Toteutus tulee siis näkyviin n aiemmin kuin mitä perinteisimmissä järjestelmissä; toisaalta keinoja viestittää ongelmista on vähemmän Allokointivastuu joko ohjelmoijalla (C/C++) tai jollain osalla infrastruktuuria (Java) Lopulta ohjelmoija on kuitenkin vastuussa!
Esimerkki 1 static final int SIZE = 2000; private void arrayimp() { numbers = new int[size]; for (int i = 0; i < SIZE; i++) { numbers[i] = i; private void vectorimp() { numberv = new Vector(SIZE); for (int i = 0; i < SIZE; i++) { numberv.addelement(new Integer(i)); private void vectorimpsimple() { numberv2 = new Vector(); // Default size for (int i = 0; i < SIZE; i++) { numberv2.addelement(new Integer(i));
Tulokset ArrayImp (minimaalinen overhead) Bytes: 8016 Objects: 1 VectorImp (integerit olioiksi) Bytes: 40000 Objects: 2002 VectorImpSimple (lisäksi koon arvaus) Bytes: 52000 Objects: 2010 [Hartikainen: Java application and library memory consumption, TUT, 2005]
Esimerkki 2 static final int AMOUNT = 100; public void usestring() { String s = ; for(int i = 0; i < AMOUNT; i++) { s = s + a ; public void usestringbuffer() { String s = ; StringBuffer sb = new StringBuffer(AMOUNT); for(int i = 0; i < AMOUNT; i++) { sb = sb.append( a ); s = sb.tostring();
Tulokset UseString(yksinkertaisin) Bytes: 39000 Objects: 450 UseStringBuffer (optimoitu) Bytes: 304 Objects: 5 [Hartikainen: Java application and library memory consumption, TUT, 2005]
Esimerkki 3 Sovellus (14 luokkaa) refaktoroitiin suoraviivaisesti siten, että jäljelle jäi 1 luokka 14 classes: 14019 1 class: 7467 [Hartikainen: Java application and library memory consumption, TUT, 2005]
Kerrostaminen ja laitteiston kätkentä Resource 3 Resource Manager 3 Resource 1 Resource 2 Resource Manager 1 Resource Manager 4 Resource 4 Resource Manager 2 Laitteet (ja laiteabstraktiot) ohjaavat suunnittelua Jokaista laitetta varten oma hallintakomponentti Resurssien valvonta yksinkertaistuu Abstraktiorajapinnalla voidaan myös helpottaa siirrettävyyttä HAL, Hardware Abstraction Layer
Väyläabstraktio Resource 1 Resource 2 Resource 3 Resource Manager 3 Resource Manager 1 Resource Manager 2 Communication bus Resource Manager 4 Laitteet usein riippumattomia -> löyhä kytkentä sanomien avulla Uudet ominaisuudet uusien sanomien lisäämisellä Sopii myös hajautettuun sulautettuun ympäristöön Frakmentoinnin esto -> sanomat rengaspuskurissa tms. Resource 4
Käynnistysrutiinit Sama ohjelmisto erilaisessa laiteympäristössä voi vaatia erilaisen käynnistysrutiinin (esim. oheislaitteiden alustus) Muunneltava bootstrap Jokainen operaatio oma rutiininsa; boot-up script/procedure Käynnistysvektori Erilaiset konfiguraatiotiedostot, joilla käynnistystä voidaan ohjata
Muisti- ja ajoitusbudjetti Suunnitelma Muistin kulutukselle Suoritusajan käytölle Tarpeen, jotta valmistuskustannukset voitaisiin arvioida Lähtökohdaksi paras mahdollinen arvaus Kokonaan uusi kohdealue -> joitakin kokeiluja Aiemman toteutuksen uusi versio -> data aiemmasta/aiemmista versioista pohjaksi Nyrkkisääntö: Mitä enemmän vanhoja datapisteitä, sitä todennäköisemmin arvio osuu kohdalle
Formaalit menetelmät? Mitä myöhemmin virhe havaitaan, sitä kalliimpaa se on korjata Idea: Mitäpä jos mallinnetaan koko järjestelmä etukäteen täsmällisesti jotta kaikki virheet/erilaiset tulkinnat löydetään (ja korjataan) etukäteen? Täsmällisessä mallinnuksessa tarvitaan ns. formaaleja menetelmiä Matemaattinen tapa ilmaista ohjelmiston toiminta; tietokoneavusteinen päättely ja laadunvarmistus
Hyvät puolet Paljon erilaisia työkaluja, joiden kautta on mahdollista löytää ongelmia etukäteen Varsinkin tavalla tai toisella rajoitettujen ongelmien ratkaisu tuntuu olevan käytännössäkin mahdollista Usein käytössä silloin kun virheet ovat todella kalliita (esim. ilmailu, massatuotetut laitteet kuten prosessorit, jne) Joskus myös koodingenerointi ja oikeaksitodistaminen mahdollista Tosin usein vain rajoitetulle osalle ongelman ratkaisua
Huonot puolet Mistä tietää että formaali määritelmä on oikein? Etäisyys valmiiseen toteutukseen on edelleen melkoinen varsinkin silloin, kun toteutetaan ohjelmistopainotteista järjestelmää Monet käytännön asiat vaatisivat hyvin sovellusaluekohtaista formalismia Ratkaisu: Erilaiset puoliformaalit menetelmät, joissa yhdistyvät visuaalisuus ja matematiikka
Yhteenveto Painopiste laitteen hereille saamisesta laitteen pitkäaikaiseen käyttöön Valmiit ohjelmistopinot Vuotavien abstraktioiden hallinta Joustavuutta tuovat suunnitteluratkaisut Määrittelyn oikeellisuus ja täsmällisyys