10. Luento: Kohti suurempia sulautettuja ohjelmistoja Arto Salminen, arto.salminen@tut.fi
Viksut Vekottimet 2013 Viksut Vekottimet (Intelligent Machines) is a free seminar at Tampere University of Technology. It's aimed for professional developers and everyone else working in control system software development. It will be organized on 27th of March 2013. http://www.eventbrite.com/event/4828972587
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 11: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)
Mitä asialle voi tehdä ohjelmoijana? Mahdollisuuksien mukaan laadunvarmistus muualla kuin varsinaisessa laitteessa Abstraktioiden käyttö ongelman ja ratkaisun jäsentämisessä Parempia apuvälineitä, esim. domainspesifinen kieli Esim. TNSDL matkapuhelinkeskuksessa Omia kehitystä helpottavia rutiineja mukaan jo käytössä oleviin järjestelmiin Hyvän ohjelmistosuunnittelun periaatteet (siirrettävyys, modulaarisuus jne.)
Lyhyesti 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 (abstraktiot taas keskeisiä) Skriptit Konfiguraatiotiedostot buildausta varten. Usein kannattaa käyttää useampaa kääntäjää! 1 Miksi muuten näin monet sulut?
#include <QApplication> #include <QLabel> #ifdef Q_OS_SYMBIAN // Need these includes to lock orientation in Symbian #include <eikenv.h> #include <eikappui.h> #include <aknenv.h> #include <aknappui.h> #endif int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label; #ifdef Q_OS_SYMBIAN // Lock orientation to portrait in Symbian CAknAppUi* appui = dynamic_cast<caknappui*> (CEikonEnv::Static()->AppUi()); TRAP_IGNORE( if(appui) { appui->setorientationl(caknappui::eappuiorientationportrait); ); #endif #ifdef Q_WS_MAEMO_5 // Lock orientation to portrait in Maemo label.setattribute(qt::wa_maemo5portraitorientation, true); #endif
#if defined(q_os_symbian) // Symbian^3 specific code can be defined using the SV_S60_5_2 macro if (QSysInfo::s60Version() == QSysInfo::SV_S60_5_2) { label.settext("symbian^3"); else { label.settext("symbian"); #elif defined(q_ws_maemo_5) label.settext("maemo"); #elif defined(q_ws_simulator) label.settext("simulator"); #else label.settext("some other platform"); #endif #if defined(q_os_symbian) label.showmaximized(); #else // On Maemo and Simulator QMainWindow (to which the only QLabel will map behind the scene) // is automatically shown as maximised and we don't need to ifdef platform specific code // for it. label.show(); #endif return app.exec();
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!
Vuotavat abstraktiot Esimerkki: 0-loppuinen merkkijono char * strcat(char * c1, char * c2) { int i, j; for(i = 0; 0!= c1[i]; i++); for(j = 0; 0!= c2[j]; j++, i++) c1[i] = c2[j]; c1[i+1] = 0; return c1;
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 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