Uppkomsten och framväxten av området programvaruarkitektur. sid 7. Ikläda sig rollen som arkitekt sid 13. Ideale arkitekten en stålman?

Storlek: px
Starta visningen från sidan:

Download "Uppkomsten och framväxten av området programvaruarkitektur. sid 7. Ikläda sig rollen som arkitekt sid 13. Ideale arkitekten en stålman?"

Transkript

1 ntime T E M A : P R O G R A M V A R U A R K I T E K T U R Nr 1 juni 2001 Uppkomsten och framväxten av området programvaruarkitektur sid 7 Ikläda sig rollen som arkitekt sid 13 Ideale arkitekten en stålman? sid 14 Mönsterbaserad omkonstruktion sid 16

2 Redaktion Ansvarig utgivare Christer Hoberg, vd Redaktionsråd Anders Magnusson, Göteborg Per-Ola Malm, Malmö Peter Uhlin, Linköping Redaktör Eva Holmquist, Jönköping Innehåll Ledare...3 Tema: Programvaruarkitektur...4 Uppkomsten och framväxten av området programvaruarkitektur...7 Ikläda sig rollen som arkitekt...13 Ideale arkitekten en stålman?...14 Mönsterbaserad omkonstruktion...16 Intressanta konferenser...23 Nya kurser...23 Vårt område är inbyggda system. Vi kommer aldrig att gå utanför detta område och måste därför behärska inbyggda system bättre än någon annan. Våra uppdragsgivare kallar in oss när de står inför sin tuffaste uppgift: bryta ny mark, gå in på främmande teknikområden eller skapa nytt liv i ett projekt som gått snett. Vår affärsidé bygger på att tillföra våra uppdragsgivare nytt kunnande och effektivare metoder inom systemutveckling i kombination med överföring av den erfarenhetsbaserade, tysta kunskapen. För detta har vi utvecklat en metodik som gör att vi successivt för över vårt kunnande till uppdragsgivarens organisation. Vi blir därmed så småningom överflödiga inom det dagliga jobbet, vilket som sagt är en del av vår affärsidé vår plats är först och främst inom de delar av projektet där de nya vägvalen är många och svåra. Nätvariant av OnTime Jönköping (lokalkontor: Växjö, Karlskrona, Ulricehamn) Box 1017, Jönköping Tel Fax Malmö (lokalkontor: Helsingborg) Box 4114, Malmö Tel Fax Göteborg (lokalkontor: Trollhättan) Mölndalsvägen 30C, Göteborg Tel Fax Stockholm (lokalkontor: Uppsala) Box 6776, Stockholm Tel Fax Linköping (lokalkontor: Örebro, Karlskoga) Teknikringen 9, SE LINKÖPING Tel Fax München Leopoldstr. 236, DE MÜNCHEN, TYSKLAND Tel Fax E-post www Produktion Erichs Communications AB, Linköping Grafisk design P51 Communication AB Tryck Tryckeri AB Småland Quebecor 2 Nr 1 juni 2001

3 LEDARE OnTime ska ge insikt i tid Välkomna till det första numret av OnTime! Tidningens första huvudtema är arkitektur. Vår ambition är att återkomma regelbundet med nya spännande nummer av OnTime, där vi tar upp olika aspekter och nyheter inom det som intresserar oss allra mest utveckling av inbyggda realtidssystem. Produkter som påverkar vår vardag Teknikområdet i sig är oerhört spännande och nya tekniska landvinningar möjliggör alltmer avancerade produkter, som påverkar vår vardag i allra högsta grad. I allt från mobiltelefoner, bilar, TV-apparater, symaskiner till medicinsk utrustning utvecklas idéer till verklighet med forskning och ny teknik. Detta innebär både möjligheter och risker av olika slag och vi vill därför kunna belysa både utvecklings- och användningsproblematiken runt detta. Produkterna formas i en dialog Genom att teknikutvecklingen alltmer påverkar vår vardag skapas också krav på att vi som är tekniker förstår den omvärld produkterna och systemen ska verka i. Produkterna måste formas i en dialog med andra perspektiv i en gemensam grundkunskap om helheten. Detta uppmärksammas alltmer till exempel i tankarna kring framtidens ingenjörsutbildning och här vill vi bidra med idéer och erfarenheter. Vår kunskap måste förnyas Ingenjörens yrkesroll och det livslånga lärandet är frågor som ständigt är på dagordningen genom att teknikkunskapen hela tiden måste förnyas. Samtidigt växer utvecklingsorganisationerna och alltfler nya ingenjörer ska tränas in i de gemensamma arbetssätt som den erfarne tar för självklart. Detta ställer stora krav på organisation och kunskapsutvecklingsmetoder. OnTime ska ställa olika perspektiv mot varandra Kort sagt; det finns många olika aspekter på utvecklingsarbetet och dess förutsättningar. Vi vill med OnTime ge en möjlighet för olika perspektiv att ställas mot varandra, samtidigt som vi vill visa helheten i teknik och samhällsutveckling och vems framtidsvisioner som styr vad! Christer Hoberg Nr 1 juni

4 AV ANDERS MAGNUSSON Tema: Programvaruarkitektur Är programvaruarkitektur bara ännu ett begrepp som man slänger sig med, precis som man under tidigt 90-tal talade om objektorientering? Över en natt blev alla system objektorienterade, trots att de tidigare arbetat utifrån ett funktionsorienterat perspektiv. Man döpte helt enkelt om modulerna till objekt. I detta temanummer har vi för avsikt att belysa begreppet programvaruarkitektur, som precis som begreppen objektorienterad analys/konstruktion (OOA/OOD) och strukturerad analys/konstruktion står för ett mer djuplodande synsätt. Man kan inte bara döpa om sin befintliga programvarukonstruktion och kalla den en programvaruarkitektur. Arkitekturen styr och vägleder Vad är det som gör att byggnadsingenjören väljer att använda sig av en fribärande takstol i sin konstruktion, istället för en lösning som kräver bärande väggar? Varför har byggnaden runda snirkliga pelare istället för fyrkantiga? I de flesta fall styrs detta av vad vi kallar byggnadens arkitektur, som vanligtvis är utarbetad av en arkitekt. Arkitekturen styr och vägleder byggnadsingenjören i dennes detaljkonstruktion av byggnadens olika element och deras placering. I vissa fall präglas byggnadens arkitektur av en speciell stil såsom gotisk, funkis, grekisk-romersk (t. ex. runda snirkliga pelare), som ger den en viss karaktär. Arkitekturen styrs också av ett antal faktorer och önskemål såsom ett ljust boende, öppen planlösning, många barn etc. som blir arkitektens drivande föreställningar i arbetet med arkitekturen. Vad har då byggnadsarkitektur gemensamt med programvaruarkitektur? Jo, idén om att skapa grunden för det detaljerade konstruktionsarbetet, att skapa möjligheter till planering och kostnadsberäkning av det fortsatta arbetet och att fördela ansvar till olika individer/organisationer. Programvaruarkitektur innebär att definiera och förmedla programvarans eller systemets bärande stil, i form av strategier, olika komponenter och deras kopplingar, samt de principer som gör att man kan konstruera detaljerna. Det gäller dessutom att se till att programvaran kan vidareutvecklas på ett enkelt sätt. Precis som byggnadsarkitekten måste programvaruarkitekten använda sig av skisser och modeller för att föra fram grundidén programvaruarkitekturen måste vara kommunicerbar. Det är arkitekturen som ska vägleda konstruktören att identifiera bra objekt vid en objektorienterad konstruktion. Skillnaden mellan arkitektur och konstruktion Eftersom området programvaruarkitektur fortfarande är nytt finns det säkert en undran hos många om vad som är skillnaden mellan en programvaruarkitektur och en programvarukonstruktion. För att inse skillnaderna måste man fylla begreppet programvaruarkitektur med en innebörd. Det går inte att bara döpa om sin programvarukonstruktion och kalla den programvaruarkitektur, precis som många trott att man kan kalla en modul för ett objekt. Inom byggnadsområdet har det under en lång tid pågått en debatt om skillnaden mellan arkitektur och konstruktion. Trots debatten finns det i realiteten en accepterad skillnad, som också börjar skönjas när det gäller områdena programvaruarkitektur och programvarukonstruktion. En antydan till skillnad Arkitektur omfattas huvudsakligen av omätbara storheter baserade på ickekvantitativa verktyg och riktlinjer baserade på egna och andras erfarenheter. Konstruktion omfattas vanligtvis av mätningar baserade på analytiska verktyg härledda från matematiken. Man kan också se det som att konstruktion omfattar mätbara kostnader medan arkitektur inbegriper en kvalitativ strävan. Konstruktion strävar då efter teknisk optimering medan arkitekturarbete strävar efter en nöjd kund. Flera närbesläktade begrepp Inom området inbyggda system och realtidssystem finns det flera begrepp som är närbesläktade med programvaruarkitektur. I figuren nedan ser vi några av dessa och hur de förhåller sig till varandra. Två specialiserade former av programvaruarkitektur är särskilt intressanta att belysa: Produktlinjearkitektur (referensarkitektur) är ett relativt nytt område som framför allt inbegriper problemen med att utveckla en programvara som stödjer variabilitet. Det innebär att kund 1 vill använda systemen på sätten A, B och C, medan kund 2 vill använda dem på sätten A, C, D och E. Vi får alltså en familj av produkter som skapas utifrån samma bas. För att klara detta definieras något som kallas produktlinjearkitektur. Att sänka utvecklingskostnaden genom att utnyttja inköpta komponenter är svårt. Det är stor skillnad mellan olika komponenter. Att använda skruvar och muttrar (länkade listor, koordinatsystem) är en sak, att köpa en komponent för motorstyrning eller en komponent för ett kommunikationsprotokoll är en helt annan sak. De sistnämnda närmar sig en specifik domän, vilket innebär att de måste passa in i en större helhet för att fungera. Tillgång till en vedertagen arkitektur för domänen, så kallad domänspecifik programvaruarkitektur, underlättar naturligtvis för tredjepartsleverantörer att tillhandahålla komponenter. 4 Nr 1 juni 2001

5 Fler faktorer än funktionalitet Systemets funktionalitet har under en lång tid varit i fokus under systemutvecklingen. Med programvaruarkitektur försöker man nu balansera detta, bland annat genom att titta på andra kvalitetsattribut, såsom hur utbyggbar, underhållsbar, flyttbar och omstruktureringsbar programvaran ska vara. Andra faktorer är tillgänglighet och tillförlitlighet eller till vilken grad den ska stödja interaktion med andra system. Tittar man på telekommunikationsdomänen, där bland annat företag som Ericsson, Nokia och Motorola konkurrerar, så är funktionaliteten (kommunicerande system) väldigt hårt styrd av standarder. Det gör att nästan alla erbjuder samma funktionalitet. Det som dessa spelare då konkurrerar med är alltså inte funktionalitet, utan andra egenskaper såsom tillgänglighet, säkerhet eller prestanda. Trots detta är funktionaliteten fokus i dessa företags utvecklingsprojekt. Den samlade bilden utgör arkitekturen I dagens inbyggda system, som blir allt mer komplexa och öppna mot omvärlden, finns många aspekter som måste fångas och förmedlas: När ska vi ha fram en viss funktionalitet? Hur ska programvaran exekvera? Var ska programvaran exekvera? Hur ska vi gruppera logiken? Dessa frågeställningar varierar, men det vi kan säga är att helheten och den samlade bilden av olika aspekter utgör programvaruarkitekturen. Tekniker som stödjer utvecklingen Vyer och modeller som stöd för kommunikation Precis som byggnadsarkitekten så behöver man som programvaruarkitekt fånga alla dessa olika aspekter som ska Maskinvaruarkitektur Produktlinjearkitektur Systemarkitektur En specialiserad form av Bild 1 visar några närbesläktade begrepp Domänspecifik programvaruarkitektur Programvaruarkitektur En specialiserad form av beaktas. De behöver inte bara fångas utan de måste även göras synliga på ett begripligt sätt. En byggnadsarkitekt, så även en byggnadsingenjör eller en mekanikingenjör, använder sig av ritningar som åskådliggör olika vyer av en viss aspekt. Exempel på aspekter är exteriör, interiör, avlopp, vatten eller el i ett hus. Synsättet att använda sig av olika vyer är även det tillämpligt inom området programvara. Ett annat begrepp för detta med vyer är modell, där modell är en avbildning av något för ett visst syfte. Genom åren har det utvecklats ett antal vedertagna tekniker 1 som stödjer utvecklingen av programvarusystem. En av dessa är separering av frågeställningar/intresseområden ( separation of concern ). Just användandet av modeller (vyer) stödjer detta synsätt att hålla olika aspekter separerade från varandra gör det mycket lättare att greppa varje enskild aspekt. Behövs formella språk? Behöver man då formella språk för att åskådliggöra dessa aspekter? Än en gång får man gå tillbaka till vad programvaruarkitektur har för syfte att skapa och förmedla en system-, konstruktions- och utvecklingsfilosofi. Det man då själv måste fråga sig är: Behöver byggnadsarkitekten formella språk för att förmedla bilden av en byggnadsarkitektur? Temaartiklar i detta nummer För att göra detta nummer av OnTime till ett temanummer om programvaruarkitektur krävs det några mer djuplodande artiklar. Eftersom området i sig inte är formellt definierbart krävs det att man bildar sig en helhetsuppfattning genom att även här förstå ett antal aspekter inom området. Fyra distinktioner skiljer arkitektur från konstruktion En av dessa aspekter är uppkomsten av området i sig självt, och varför det har blivit intressant. Detta belyses utmärkt i artikeln Uppkomsten och framväxten av området programvaruarkitektur, se sid 7. Artikeln är skriven av Dewayne E Perry och David Garlan, två av pionjärerna inom området programvaruarkitektur. Artikeln utgår från två identifierade trender ur vilka fyra distinktioner, som urskiljer programvaruarkitektur från mer traditionell programvarukonstruktion, definieras. Den ena distinktionen, som författarna kallar utvecklingsfokus, berör traditionell konstruktion av algoritmer (funktioner) och datastrukturer kontra arkitekturell organisering av komplexa system. 1 abstraction, encapsulation, information hiding, modularisation, separation of concerns, coupling and cohesion, sufficiency, completeness and primitiveness, separation of policy and implementation, separation of interface and implementation, single point of reference, divide-and-conquer. Nr 1 juni

6 Den andra distinktionen anser författarna vara sättet att beskriva programvaran. I traditionell programvarukonstruktion baseras definitionen av programkoden på var den används, medan den arkitekturella beskrivningen baseras på grafer av interagerande komponenter. Tredje distinktionen är enligt artikelförfattarna skillnaden mellan arkitekturell instans och arkitekturell stil. En arkitekturell instans refererar till arkitekturen för ett specifikt system, medan en arkitekturell stil definierar begränsningar, form och struktur (typkomponenter) av en familj av arkitekturella instanser, precis som byggnadsarkitekten pratar om gotisk eller funkisstil. Den sista distinktionen anser författarna vara mellan konstruktionsmetoder, t ex OMT, Booch och Fusion och programvaruarkitektur, där de menar att dessa kompletterar varandra men har helt olika fokus. Båda behövs! Arkitekturella stilar och konstruktionsmönster Mer om arkitekturell instans kontra arkitekturell stil finns i artikeln Mönsterbaserad omkonstruktion i detta nummer, se sid 15. Artikeln belyser användningen av arkitekturella stilar och användningen av mer detaljerade konstruktionsstilar, kallade konstruktionsmönster, för att skapa högre underhållsbarhet och stabilitet i systemet, vilket är minst lika viktigt som funktionalitet. Praktiska erfarenheter som arkitekt Vid ett dialogseminarium på Combitech Systems skrevs ett antal texter där författarna reflekterade över rollen som programvaruarkitekt. I reflektionen Ikläda sig rollen som arkitekt, se sid 13, skriver Thomas Strömqvist från Stockholm om sina erfarenheter. I projektet försökte Thomas att tillämpa några av de principer som han tillgodogjort sig i en av Combitech Systems teknikgrupper med fokus på arkitektur och mönster. I Thomas reflektion ser vi svårigheten i att agera arkitekt. Om man jämför med en byggnadsarkitekt är det sällan som kunden verkligen vet vad det är han/hon vill ha. Det blir då byggnadsarkitektens uppgift att driva fram den slutliga lösningen, genom att ständigt ge nya förslag till en byggnad, och använda dessa för att locka fram kundens syn. Kanske är det precis så som man måste arbeta när man ikläder sig rollen som programvaruarkitekt att våga driva kunden mot en viss arkitektur. Problemet med förändringar Erik Dyrelius tar upp problemet med förändringar i arkitekturen i sin reflektion Den ideale arkitekten, en stålman?, se sid 14. Om dessa förändringar, eller mutationer som han kallar dem, sker okontrollerat kan de leda till att arkitekturen blir oanvändbar. Som motvikt till okontrollerade mutationer betonar Erik arkitektens roll och några av de egenskaper en ideal arkitekt bör ha. Anders Magnusson arbetar som Technology Management Consultant på Combitech Systems, med system och programvaruarkitektur samt arbetssätt och konstruktions-/modelleringsmetoder som specialitet. Anders har 14 års erfarenhet av branschen. På Combitech Systems har han drivit teknikgrupper inom områdena programvaruarkitektur och mönster. Anders är en flitig föredragshållare inom området samt har under ett antal år agerat som lärare i kursen programvaruarkitektur i inbyggda system. Böcker om programvaruarkitektur Software Architecture Perspectives on an Emerging Discipline. Mary Shaw / David Garlan. ISBN: Detta är den första boken inom området. Den kan kännas lite omodern eftersom området utvecklats, men man bör ändå kika på den för den sätter grunderna. David Garlan är också en av författarna till den inledande artikeln i detta nummer. Pattern-Oriented Software Architecture (POSA I) A Systems of Patterns. Frank Buschmann / Regine Meuner / Hans Rohnert / Peter Sommerlad / Michael Stal. ISBN: Det här är en av mina favoriter. Den är väldigt konkret och behandlar arkitekturella mönster och allmän information om arkitektur. The Art of Systems Architecting. Eberhardt Rechtin / Mark W. Maier. ISBN: Den här boken behandlar systemarkitekturer i olika skepnader, t ex tillverkningssystem, sociala system, builder-architected systems. Inledningsvis innehåller den några intressanta resonemang kring skillnader mellan arkitektur och konstruktion. Avslutningsvis fokuserar den på programvara. Software Architecture in Practice. Len Bass / Paul Clements / Rick Kazman. ISBN Boken tar upp arkitekturens roll i affärsverksamheten och varför arkitektur är viktigt. Boken förklarar vad som utgör en bra arkitektur och författarna resonerar om uppfyllning av olika kvalitetsattribut. De har en viktig poäng i sin klassificering av kvalitetsattribut, vilken skiljer sig mot den vedertagna. För att utvärdera arkitekturer introducerar de en metod som de kallar SAAM, Software Architechture Analysis Method. Kort innebär den att för de kvalitetsattribut som systemet ska uppfylla definieras olika scenarier, som man sedan kan använda för att resonera kring sin arkitektur. Applied Software Architecture. Christine Hofmesiter / Robert Nord / Dilip Soni. ISBN Boken tar upp några vyer och modeller som kan användas för att beskriva en programvaruarkitekur med många exempel. Pattern-Oriented Software Architecture (POSA II): Patterns for Concurrent and Networked Objects. Douglas C. Scmidt / Hans Rohnert / Michael Stal / Frank Buschmann. ISBN: Det här är en alldeles ny bok skriven av herrarna bakom POSA I. POSA II omfattar ett antal mönster, kanske inte lika arkitekturdrivande som förra bokens mönster, men ändock intressanta konstruktionsmönster. 6 Nr 1 juni 2001

7 Uppkomsten och framväxten av området programvaruarkitektur AV DAVID GARLAN OCH DEWAYNE E. PERRY 1995 IEEE. Publicerad med tillstånd av IEEE. Ursprungligen publicerad i IEEE nr 4, april 1995 med namnet Introduction to the Special Issue on Software Architecture. I. Vad är programvaruarkitektur? En kritisk infallsvinkel på konstruktionen av varje omfattande programvarusystem gäller dess grundstruktur representerad som en högnivåorganisation av beräknings-/dataelement och interaktion mellan dessa element. Allmänt sett är detta programvaruarkitekturens konstruktionsnivå. Programvarans struktur har länge betraktats som en betydelsefull fråga. Nyligen har emellertid programvaruarkitektur börjat växa fram som ett eget studieområde för praktiker och forskare. Bevis på detta framgår av en stor mängd av nyligen utgivna arbeten inom sådana områden som modulära gränssnittsspråk, domänspecifik arkitektur, arkitekturbeskrivande språk, konstruktionsmönster och handböcker, formellt stöd och miljö för konstruktion av arkitektur. Termen programvaruarkitektur Vad menar vi exakt med termen programvaruarkitektur? Som man kan förvänta sig av ett område, som tills nyligen har framkommit med speciell inriktning på forskning och utveckling, finns det för närvarande ingen allmänt accepterad definition. Om vi dessutom ser på den vanliga användningen av termen arkitektur för området programvara finner vi att den används på helt olika sätt, vilket ofta gör det svårt att förstå vilket perspektiv som avses. Bland de många användningssätten avses a) arkitekturen hos ett speciellt system, som i arkitekturen för detta system består av följande komponenter b) en arkitekturell stil som i detta system antar en klient-serverarkitektur och c) det allmänna studiet av arkitektur som i artiklarna i denna tidskrift handlar om arkitektur. Inom området programvarukonstruktion pekar de flesta sätten att använda termen programvaruarkitektur på den första av dessa tolkningar. Typiskt för dessa är följande definition (som utarbetats i en diskussionsgrupp för programvaruarkitektur vid SEI, Software Engineering Institute, år 1994): Strukturen för komponenterna i ett program/system, deras inbördes relationer och principer samt riktlinjer som stödjer deras konstruktion och utvecklingen över tiden. Som definition är detta ingen dålig start. Men sådana här definitioner berättar bara en liten del av historien. Inriktningen inom forskningen styr Viktigare än sådana speciella definitioner är inriktningen inom forskning och utveckling, vilken härigenom har kommit att definiera området för programvaruarkitektur. För att klargöra naturen hos denna inriktning är det nyttigt att notera att det senast uppkomna intresset för programvaruarkitektur har initierats av två skilda trender. Den första trenden avser konstaterandet att under åren har konstruktörer börjat utveckla ett delat urval av metoder, tekniker, mönster och idiom för att strukturera komplexa programsystem. Exempelvis har blockscheman och förklarande text ofta börjat hänvisa till uttryck som pipeline eller klient-serversystem. Även om dessa termer sällan har givits exakta definitioner tillåter de konstruktörer att beskriva komplexa system med användning av abstraktioner som gör hela systemet begripligt. De tillhandahåller dessutom ett signifikant semantiskt innehåll som upplyser andra om de typer av egenskaper som systemet kommer att ha: dess förväntade utvecklingsvägar, dess övergripande mönster för databehandling och dess relationer till liknande system. Den andra trenden avser intresset för exploatering av speciella domäner för att tillhandahålla återanvändbara ramar för produktfamiljer. Sådan exploatering baseras på idén att man kan utvinna gemensamma ramverk även på svenska på en samling relaterade system, så att varje nytt system kan byggas till en relativt låg kostnad genom instansiering av den delade konstruktionen. Bekanta exempel inkluderar den standardiserade uppdelningen av en kompilator (vilken gör det möjligt för studenter att konstruera en ny kompilator på en termin), standardiserade kommunikationsprotokoll (vilket gör det möjligt för olika leverantörer att interagera genom att tillhandahålla tjänster på olika abstraktionsnivå), fjärde generationens programspråk (som utnyttjar de allmänna mönstren för databehandling av affärsinformation) och verktygssatser med användargränssnitt och ramverk (vilka tillhandahåller både ett återanvändbart ramverk för att utveckla gränssnitt och en uppsättning återanvändbara komponenter, såsom menyer och dialogrutor). Fyra distinktioner Med utgångspunkt från dessa trender är det möjligt att identifiera fyra framträdande distinktioner mellan traditionell programvarukonstruktion och programvaruarkitektur. Angelägenhetsfokus: Den första distinktionen gäller mellan traditionellt fokus på konstruktion av algoritmer och datastrukturer på den ena sidan och arkitekturellt fokus på organisering av stora system på den andra. Den förra har gällt traditionell inriktning på mycken datavetenskap, medan den senare har vuxit fram som en signifikant och annorlunda konstruktionsnivå, som kräver sina egna notationer, teorier och verktyg. I synnerhet avser konstruktion av programvaruarkitektur mindre fokus på konstruktion av algoritmer och datastrukturer som används Nr 1 juni

8 Krav Krav Krav Godtyckligt sätt som fungerar Metoder Programvaruarkitektur Implementation Implementation Implementation 1a 1b 1c Bild 1 Konstruktionsmetoder i förhållande till programvaruarkitektur inom moduler, än frågor om övergripande organisation och globala styrstrukturer: protokoll för kommunikation, synkronisering och dataåtkomst; allokering/tilldelning av funktionalitet/ansvar till konstruktionselement; fysisk distribution; sammansättning av konstruktionselement; skalning och prestanda; urval bland konstruktionsalternativ. Representation av programvaran: Den andra distinktionen gäller mellan systembeskrivningar baserade på struktur uppbyggd av definition av var moduler exekverar och arkitekturell beskrivning baserad på grafik över samverkande komponenter. De förra modulariserar ett system i termer av källkod, vanligen med explicita beroenden mellan kodens exekveringsplats och motsvarande definitionsplatser. Den senare modulariserar ett system som ett diagram eller konfiguration av komponenter och anslutningar. Komponenter definierar tillämpningsområdets beräkningar och datalager i ett system. Exempel på komponenter är klienter, servrar, filter, databaser och objekt. Anslutningar definierar principen för interaktion mellan dessa komponenter. Denna interaktion kan vara så enkel som ett proceduranrop, dataflöde och utsändning av händelser utan en specifik mottagare eller mycket mera komplext, inklusive klient-serverprotokoll, databasåtkomstprotokoll etc. Instans i förhållande till stil: Den tredje distinktionen avser förhållandet mellan en arkitekturell instans och arkitekturell stil. En arkitekturell instans hänvisar till arkitekturen för ett specifikt system. Blockscheman som åtföljer systemdokumentationen beskriver arkitekturella instanser, eftersom de avser individuella system. En arkitekturell stil å andra sidan definierar begränsningar i stil och struktur hos en familj av arkitekturella instanser. Som exempel kan en arkitekturell stil med pipes and filter definiera den familj av systemarkitekturer som är konstruerade som ett diagram över ett antal successiva filter som vart och ett bearbetar en ström av data/information. Arkitekturella stilar föreskriver sådana saker som en vokabulär för komponenter och anslutningsdon samt definierar typkomponenter och typkopplingar, t.ex. filter och rör (pipes), topologiska begränsningar (diagrammet ska t.ex. vara acykliskt) och semantiska begränsningar (filter kan t.ex. inte dela tillstånd). Stilar omfattar allt från abstrakta arkitekturella mönster och idiom (såsom klient-server eller skiktade organisationer) till konkreta referensarkitekturer (såsom ISO- IECs kommunikationsmodell eller den traditionella linjära uppdelningen av en kompilator). Konstruktionsmetoder i förhållande till arkitekturer: En fjärde distinktion gäller mellan konstruktionsmetoder för program såsom objektorienterad konstruktion, strukturerad analys och JSD (Jackson Structured Design), och programvaruarkitektur. Fastän både konstruktionsmetoder och arkitekturer berörs av problemet att överbrygga gapet mellan krav och realisering, finns det en signifikant skillnad i deras formulering av problemet. Bild 1 visar denna skillnad. Utan vare sig konstruktionsmetoder för program eller en disciplin för konstruktion av programvaruarkitektur lämnas implementatören att utveckla en lösning med användning av den tillfälliga teknik som råkar finnas till hands [Bild 1(a)]. Konstruktionsmetoder förbättrar situationen genom att tillhandahålla en väg mellan någon 8 Nr 1 juni 2001

9 klass av systemkrav och någon klass av systemtillämpningar [Bild 1(b)]. I det idealiska fallet definierar en konstruktionsmetod vart och ett av de steg som tar en konstruktör från kraven till en realisering. Den omfattning i vilken sådana metoder är framgångsrika beror ofta på deras förmåga att bearbeta de begränsningar på den klass av problem de vänder sig till och den klass av lösningar de kan tillhandahålla. Ett av de sätt de kan göra detta är att rikta in sig på vissa typer av arkitekturell konstruktion. Objektorienterade metoder leder exempelvis till system bildade av objekt, medan andra på ett mer naturligt sätt kan leda till system med tyngdpunkt på dataflöde. I kontrast därtill gäller att fältet för programvaruarkitektur avser området för arkitekturella konstruktioner [Bild 1 (c)]. Inom detta område är objektorienterade strukturer och dataflödesstrukturer två av många möjligheter. Arkitektur hänger samman med kompromisser vid val inom detta område egenskaperna för olika typer av arkitekturell konstruktion och deras möjligheter att lösa vissa typer av problem. Konstruktionsmetoder och arkitektur kompletterar sålunda varandra: bakom de flesta kontruktionsmetoder finns arkitekturella stilar som föredras och olika arkitekturella stilar kan leda till nya konstruktionsmetoder som exploaterar dem. II. Varför är programvaruarkitektur viktig? Arkitekturell konstruktion av stora system har alltid spelat en betydelsefull roll för ett systems framgång: val av en olämplig arkitektur kan ha en katastrofal inverkan. Det nuvarande erkännandet av betydelsen av programvaruarkitektur skulle tyckas signalera uppkomsten av en mera disciplinerad bas för arkitekturell konstruktion, vilken har potential att påtagligt förbättra vår förmåga att konstruera effektiva programvarusystem. En principiell användning av programvaruarkitektur kan specifikt ha ett positivt inflytande på minst fem aspekter på programvaruutveckling. 1) Förståelse: Programvaruarkitektur gör det lättare för oss att förstå stora system genom att presentera dem på en abstraktionsnivå vid vilken ett systems högnivåkonstruktion kan bli begriplig. Då det är som bäst kan arkitekturell beskrivning dessutom visa högnivåbegränsningar i systemkonstruktion likaväl som logisk grund för att göra specifika arkitekturella val. 2) Återanvändning: Arkitekturella beskrivningar stödjer återanvändning på flera nivåer. Pågående arbete för återanvändning inriktas främst på komponentbibliotek. Arkitekturell konstruktion stödjer dessutom både återanvändning av stora komponenter och även ramverk inom vilka komponenter kan integreras. Befintligt arbete på domänspecifika programvaruarkitekturer, referensramverk och konstruktionsmönster har redan börjat tillhandahålla bevis för detta. 3) Systemevolution: Programvaruarkitektur kan visa de dimensioner längs vilka ett system förväntas växa fram. Genom att göra stödmurarna i ett system tydliga kan de som underhåller systemet bättre förstå följderna av ändringar. Det leder i sin tur till att man kan kostnadsskatta förändringarna bättre än idag. Arkitekturella beskrivningar kan dessutom tydligt separera aspekter/intresseområden för en komponent, såsom en komponents funktionalitet, från de sätt på vilka den komponenten är ansluten (dvs. interagerar med) andra komponenter. Detta medger möjlighet att ändra anslutningsmekanismen till att hantera evolution av prestanda, interaktion, prototypkonstruktion och återanvändning. 4) Analys: Arkitekturella beskrivningar ger nya möjligheter till olika typer av analys, såsom högnivåformer av konsistenskontroller, överensstämmelse med en arkitekturell stil, överensstämmelse med kvalitetsattribut och domänspecifika analyser av arkitekturer som överensstämmer med domänspecifika stilar. 5) Hantering: Det finns ett starkt skäl till att göra uppnåendet av en genomförbar programarkitektur till en milstolpe i en industriell process för programutveckling. En sådan milstolpe innebär specificering av ett programvarusystems initiala operativa krav, dess förväntade tillväxt, programvaruarkitektur och en logisk grund, vilken visar att arkitekturen, om den blev tillämpad, skulle tillfredsställa systemets initiala krav och förväntade tillväxt. Om man fortsätter att utveckla en programvaruprodukt utan att tillgodose dessa villkor finns det en påtaglig risk att systemet kommer att bli antingen olämpligt eller ur stånd att kunna förändras. Inflytande på marknadskrafterna Betydelsen av programvaruarkitektur kan också beskrivas i termer av dess breda inflytande på marknadskrafter vilka är viktiga för programvaruintensiv verksamhet. Dessa krafter påverkar sättet på vilket företag planerar sina programvaruprojekt och i slutänden sättet på vilket de bygger sina programvarusystem. Bas av befintlig programvara Med utgångspunkt från att programvaror har blivit en integrerad del i en stor mångfald av produkter och att många av dessa produkter har funnits på marknaden under lång tid finns det en bred Nr 1 juni

10 Produktlinjechef * Sponsrar Sponsrar Initierar Initierar Forskare * producerar Produktlinje analytiker * producerar Komponenttillverkare * producerar verifierar Komponentsammanställare * Producerar Producerar Producerar/verifierar Producerar används i Principer för programvaruarkitektur Produktlinjestruktur och strategi används i Produktlinjekomponenter, specifikationer,verifikationsinformation Programvaruprodukter för användare Frågor, leveranser Överlämnas till Certifiering Inför artiklar till Bibliotek Tillhandahåller mäklarerfarenheter * tar emot erfarenheter från andra deltagare. Mäklare Verksamhet Mäklare * Bild 2. Boehm-Scherlis företagsmodell för megaprogrammering bas av befintlig programvara. Denna bas representerar en påtaglig kapitalinvestering och ska som sådan betraktas som tillgångar. Förmågan att använda dessa tillgångar är viktig för programvarproducenternas finansiella hälsa. I den utsträckning programvaruarkitekturen är inriktad på domänspecifika abstraktioner och användning av olika småbitar av existerande arkitekturella element stödjer den utnyttjandet av dessa tillgångar. Sätt att nå interaktion Interaktion är en annan marknadskraft som bidrar till det framgångsrika utnyttjandet av ett företags tillgångar, eftersom det främjar delning tvärs över produktlinjer. I den utsträckning det är ett effektivt sätt att upprätta en gemensam ram för olika domänrelaterade produkter, representerar programvaruarkitektur ett påtagligt sätt att uppnå sådan interaktion. Kostnaderna ökar Eftersom forsknings- och utvecklingskostnader för programvaror ökar finns det ett ökande marknadstryck för att skaffa fram snarare än att producera viktiga delar av programvarusystem, antingen genom tredjepartsproduktion eller genom uppköp av programvaror. Resultatet av denna omställning till konsumtion snarare än produktion av programvaror placerar en ökad betydelse på den resulterande integreringen av utvecklade och inköpta komponenter. I den utsträckning programvaruarkitektur tillhandahåller tillgänglig kodifiering av konstruktionselement och deras korrekta användning i samband med specifika arkitekturella stilar, kan den vara av avgörande betydelse för att garantera att dessa olika komponenter integreras effektivt. En betydelsefull pådrivande faktor för programvaruutveckling är intervallreducering, ledtiden för lansering av en programversion. D v s inom många avsnitt av den programvaruberoende marknaden efterfrågar marknadskrafterna minskade kostnader och kortare lanseringcykler. Om ett företag kan vidmakthålla kvalitetsnivån medan det minskar produktionscyklerna kan det uppnå betydelsefulla totala kostnadsminskningar och kan samtidigt förbättra lanseringstiderna. I den utsträckning programvaruarkitektur har förmåga att minska produktionstid genom använd- 10 Nr 1 juni 2001

11 ning av befintliga tillgångar, utnyttja gemensamma arkitekturella ramar och etablera effektivare integerings- och genereringsmekanismer hjälper den till att uppnå denna tidsminskning. III. Status på området programvaruarkitektur Mycket av den arkitekturella beskrivningen är i praktiken till stora delar informell: blockscheman, där rutor representerar bearbetande komponenter och pilar, vilka representerar interaktion mellan dessa komponenter. När de är som bäst visar dessa bilder sammanfattningar på hög nivå av programmet som identifierar viktiga konstruktiva komponenter och flöden för data och styrning, men de ger vanligen föga inblick i den roll, som data spelar vid beräkningar eller detaljer av samarbetet mellan komponenterna. Standardiserade komponenter Det växande erkännandet av betydelsen av programvaruarkitektur leder emellertid till mer explicit användning av arkitekturell konstruktion, vilket nyligen visats i följande synsätt: - standardiserade komponenter; - produktfamiljer; - plattformar; - domänspecifika arkitekturer. Användningen av standardiserade komponenter ökar när programvaruproducenter märker att det finns en gemensam uppsättning av komponenter som används för en uppsättning av produkter. Ett exempel på detta är BaseWorx, en uppsättning av standardiserade komponenter som utgör basen för en uppsättning av relaterade operativa stödsystem. Specifika system produceras genom att lägga till specialiserade komponenter till de standardiserade. Produktfamiljer som hjälpmedel Produktfamiljer är ett hjälpmedel att kapitalisera produktionstillgångar och använda denna tillgångsbas för att skapa en familj av nära relaterade produktarkitekturer. Medan instansieringarna för en produktfamilj alla tenderar att vara inom samma domän, är det uppdelningen av komponenter på dessa instansieringar och genereringen av dessa instansieringar som är den drivande kraften i produktfamiljarkitekturen. Använda plattformar Ett synsätt som blir allt populärare bland många programvaruproducenter är användandet av en programvaruplattform. En plattform är en generell uppsättning av komponenter, vilka bildar basen för ett antal relaterade produkter. Dessa komponenter utgör vanligen allmänna resurser, såsom databaser, generatorer för grafiska användargränssnitt, etc. Komponenterna tillhandahåller specialiserade tjänster genom antingen speciella deklarativa språk eller instruktionsspråk för speciella ändamål. En plattform liknar en uppsättning standardiserade komponenter, men innehåller något större komponenter än skruvar och muttrar och behöver skräddarsys för speciella programsystem. Det finns slutligen en rörelse mot domänspecifika arkitekturer. De flesta programvaruintensiva företag har domänspecifika system, vilka är vitala för deras lönsamhet och verksamhet. Genom koncentration på dessa domäner och genom att skapa arkitekturella abstraktioner vilka är specifika för deras domän kan dessa företag kombinera de bästa egenskaperna hos standardplattformar och standardiserade komponenter för att skapa och specialisera sina domänrelaterade produktfamiljer. Plattformarna är skräddarsydda för sina domäner och standardkomponenterna är byggda för att ge domänspecifik bearbetning och strukturer och ge det nödvändiga limmet för att förena de många olika arkitekturelementen till en helhet. Ett bra exempel på detta synsätt är den oscilloskoparkitektur som utvecklats av Tektronix, Inc. Produktingenjörer utvecklade tillsammans med forskare en återanvändbar produktarkitektur som gav en kundanpassad ram för instrumentsystem, baserad på en specialiserad dataflödesmodell. Andra nyare exempel inkluderade ett antal försvarssponsrade projekt inom domäner såsom flygelektronik, styrning och reglering och mobila missiler. Nya roller Denna trend mot återanvändning av arkitekturbaserade produktionslinjetillgångar leder till nya roller, artefakter och relationer i organisationer för programvaruutveckling. Ett exempel på en ny organisationsmodell baserad på arkitekturell återanvändning tillhandahålls av Boehm och Scherlis i deras Megaprogramming Enterprise Model. Som framgår av bild 2 innebär några av de nya rollerna, vilka införts i modellen, följande: produktlinjechefer, vilka granskar de mänskliga, finansiella resurserna och programvaruresurserna, vilka behövs för framgångsrik utveckling och utnyttjande av produktionslinjer för programvara; produktlinjeanalytiker, vilka ägnar sig åt domänanalys och konstruktion och utveckling av arkitektur för produktlinjer för programvara; komponentproducenter, vilka utvecklar, provar och kundanpassar komponenter; Nr 1 juni

12 komponentassemblerare, vilka identifierar, värderar och sätter samman komponenter för produktion av programvarusystem; och mäklare, vilka hanterar och hjälper till att bygga upp ett bibliotek av komponenter och arkitekturer. IV. Tillståndet hos forskningen Medan tillämpningen av god arkitekturell konstruktion blir alltmer betydelsefull för programvarupraktiken kvarstår det faktum att mycket av allmän praxis leder till arkitekturella konstruktioner, vilka är informella, tillfälliga, omöjliga att analysera och handgjorda. Detta har till konsekvens att arkitekturella konstruktioner endast vagt förstås av utvecklare, att arkitekturella val är baserade mera på normalvärden än på solida konstruktionsprinciper; att arkitekturella konstruktioner inte kan analyseras med avseende på konsekvens eller fullständighet; att arkitekturer inte förstärks när systemet utvecklas; och att det i praktiken inte finns några verktyg för att hjälpa arkitekturkonstruktörer med deras uppgifter. Nu aktuell forskning i programvaruarkitektur försöker ta itu med alla dessa frågor. Bland de mer aktiva områdena finns följande. 1) Arkitekturella beskrivningsspråk: Detta område bearbetar behovet av att finna uttrycksfulla notationer för att representera arkitekturell form och arkitekturella stilar. Mycket av insatserna hos denna forskning är inriktade mot att tillhandahålla det lim som kan förena komponenter till större system. 2) Formellt stöd av programvaruarkitektur: Detta område bearbetar den rådande bristen på exakthet hos arkitekturella beskrivningar genom att tillhandahålla formella arkitekturmodeller, matematiska grunder för modularisering och systembyggnad, formell beskrivning av externa funktionella egenskaper (såsom prestation, möjlighet till underhåll etc.) och teorier för arkitekturell sammankoppling. 3) Arkitekturell analysteknik: Forskare inom detta område utvecklar ny teknik för att bestämma och förutspå egenskaper hos arkitekturer. I synnerhet görs framsteg ifråga om förståelse av relationerna mellan arkitekturella begränsningar och förmågan att prestera speciella analyser såväl som abstrakt teknik, som gör analys praktisk för stora system. 4) Arkitekturella utvecklingsmetoder: Då arkitekturell konstruktion får bättre förståelse blir det absolut nödvändigt att finna vägar för att integrera arkitekturella aktiviteter smidigt i mer omfattande metoder och processer för programvaruutveckling. 5) Arkitekturell återvinning och återanvändning: Förmågan att hantera äldre kod är viktig för stora system med ett långt liv. Forskningen börjar inriktas mot extraktion av arkitekturell konstruktion från befintliga system, likriktning av relaterade arkitekturella konstruktioner, abstraktion, generalisering och exemplifiering av domänspecifika komponenter och ramar. Det görs dessutom ökande forskningsinsatser med avseende på interaktion: teknik för upptäckt av missanpassning och överbryggning av sådana missanpassningar. 6) Arkitekturell kodifiering och vägledning: Medan sakkunskap på arkitekturell konstruktion för närvarande är ett område för konstruktionsvirtuoser finns David Garlan jobbar som forskare, med inriktning på bland annat programvaruarkitektur. David har tidigare arbetat med att utveckla arkitekturella modeller. Dewayne E. Perry är före detta programmerare som numera gått över till forskning kring bland annat programvaruarkitektur. det ett pågående arbete för beskrivning av denna sakkunskap så att andra kan använda den. Detta har lett till ett intresse för regler och teknik för val av arkitekturell stil, handböcker över mönster och konstruktionselement samt kursplaner för utbildning av programvaruarkitekter. 7) Verktyg och miljö för arkitekturell konstruktion: Med notationer och modeller för beskrivning av programvaruarkitektur har det blivit möjligt att stödja arkitekturell konstruktion med nya verktyg och miljöer. Pågående arbete är inriktat på verktyg för arkitekturell analys, miljöer för arkitekturell konstruktion och tillämpningsgeneratorer. 8) Fallstudier: Vi börjar till slut se uppkomsten av bra, publicerade fallstudier över arkitekturell konstruktion inklusive retrospektiv analys av framgångsrik (och ibland misslyckad) arkitekturell utveckling. Detta tjänar både till att öka vår förståelse av vad det innebär att göra arkitekturell konstruktion såväl som att tillhandahålla modellproblem, mot vilka andra forskare kan ställa effektiviteten hos sin egen teknik och sina egna verktyg. 12 Nr 1 juni 2001

13 AV THOMAS STRÖMQVIST Ikläda sig rollen som arkitekt Under våren och sommaren 1999 hade jag tillfälle att använda mig av arkitekturella principer under en förstudie. Under denna förstudie försökte jag ta på mig arkitektens roll, vilket visade sig vara svårare än jag trodde. Alla system vill ha alla goda egenskaper och undvika de dåliga Man behöver tillräckligt med information för att kunna bedöma vilken typ av system detta är och vilka egenskaper som är absoluta och vilka man kan laborera med. Parametrar som jag bedömde som viktiga var: Kvalitet på mätdata. Inga data får missas och tidstämplar på data måste hålla en viss kvalitet. Om detta inte kan garanteras har man inget mätsystem alls. Egenskaper och beteende hos olika potentiella användare; vad, hur, var, hur länge och hur snabbt. Med hjälp av scenariobeskrivningar skapade jag en tabell med olika egenskaper för att få en översikt över dem. Utifrån tabellen drog jag slutsatser om hur ett idealt system kunde vara konfigurerat för att tillgodose användarna. Verklighetens begränsningar förstör de ideala tankarna För att hitta en rimlig lösning inventeras och undersöks olika alternativa lösningar. Det gäller bland annat att inventera: Tillgång på komponenter som uppfyller kraven. I mångt och mycket begränsas lösningen av vad som finns, antingen på marknaden eller hos företaget självt. Fysiska begränsningar, såsom processorkapacitet eller bandbredd på bussar och hårddiskar. Jag uppskattade begränsningarna och gjorde beräkningar för att hitta flaskhalsar. Motstridiga krav, till exempel pris och utvecklingstid kontra önskad funktionalitet, samt nödvändiga prestanda kontra maximal strömförbrukning och pris. Kommunikation med beställare, användare och implementatör Det uppstår problem om man inte förstår varandra eller talar samma språk, vilket sker när: Användarna bevakar sina egenintressen, vilket är naturligt. Beställaren har gjort sig en bild av hur systemet kan se ut. De hade i vårt fall också svårt att vikta kraven och hade en tendens att betrakta alla krav som absoluta. Implementatörer bevakar sina egenintressen. De tittar mest på hur saker och ting drabbar deras del av systemet. Implementatören har därmed en tendens att inte se helheten. I vårt fall hade vi ingen implementatör under förstudien. Olika arkitekturmönster passar inte ihop Jag började projektet med att titta på olika arkitekturmönster, eftersom jag trodde mig ha en relativt god uppfattning om systemet. Det visade sig att det inte var rätt metod. Det var för tidigt att införa arkitekturmönster redan i förstudien. Mönster tillhör konstruktionsfasen, när man har en klar bild av vad man ska göra och man arbetar med att ta fram vissa egenskaper. Det är svårt att kombinera olika mönster. Hur renodlade måste de vara? Ska de betraktas som rekommendationer? I vårt fall blev det något slags client-server stil, med en lagrad server Thomas Strömqvist jobbade mellan åren 1997 och 2000 med programvaruarkitektur och formella metoder på Combitech Systems. och en klient som hade struktur enligt model-view-controller. Hur förhåller sig mönstren till processer och liknade i ett realtidssystem? Det känns som om krav på processer kommer före man har bestämt sig för vad som ingår i dem och hur de är organiserade. Arkitekturarbetet kan delas in i olika vyer Arkitekturarbetet kan delas upp på olika sätt. I artikeln Software Architecture in Industrial Applications delar författarna upp arkitekturen i vyer med olika syften: Konceptuell, Modul, Exekvering och Kod. Den förstudie som jag gjorde berörde den konceptuella vyn, där bara de viktigaste konstruktionselementen och deras relationer berörs. Detta kan jämföras med de beräkningsmodeller jag använt mig av i tidigare projekt, vilka kommer från området Design Exploration (Hardware/Software co-design), Nr 1 juni

14 AV ERIK DYRELIUS Ideale arkitekten en stålman? där motsvarande fas kallas konceptuell konstruktion. I denna fas görs grova statiska beräkningar för att finna potentiella flaskhalsar. De klassiska arkitekturmönstren som finns tillgängliga inom programvara bör då användas i modulvyn som gränsar till kodvyn. Pedagogiskt ansvar gentemot alla parter Vilken roll har då arkitekten? Det går inte att komma ifrån att arkitekten har ett pedagogiskt ansvar gentemot alla parter. Arkitektens förtroendekapital och auktoritet är väldigt viktig. Förstudien påverkar valet av arkitektur Frågan om rätt kontra fel arkitektur är mycket komplex. Troligtvis ser man att en stil är mer rätt än andra när man jämför den med de komponenter och krav som ingår i systemet. På något sätt föds stilen ur det arbete man lägger ned i början av projektet. Igenkännandet underlättas så klart om det finns en struktur och färdiga modeller att jämföra med, samt hur de förhåller sig till varandra i abstraktion, tid och egenskaper. Jag har många gånger hört åsikten att arkitektur är något som man arbetar med i början av projektet, ungefär som en översiktlig systemkonstruktion. Enligt min erfarenhet är så inte fallet. Snarare är arkitektur en färskvara, som kräver kontinuerligt arbete. Marc Maier, som skrivit artiklar inom området, är övertygad om att en framgångsrik arkitektur behöver en arkitekt, eller en liten grupp av arkitekter, som ansvarar för skapandet. Han påpekar också att arkitekturarbetet är en pågående process, men med fokus på inledningen när arkitekturen skapas och på kontroll av att den har följts. En arkitekturs död Det största hotet mot en etablerad arkitektur är när den drivande arkitekten försvinner. Jag har sett exempel på både när arkitekten försvunnit helt från projektet och när arkitekten fått andra arbetsuppgifter. Symptomen när en arkitektur dör tenderar att bli arkitekturmutation. Tyvärr fungerar systemutveckling ungefär som naturen i detta fall, och ytterst få mutationer är till gagn för den muterade organismen. Arkitektur som begrepp innefattar ofta visioner, skissartade överblicksbilder och infrastrukturella lösningar. Dokumentationen av dessa är svår om man vill att de ska följas som regler och inte som lösa rekommendationer. Om dokumentationen sedan används som en lös rekommendation leder det till tolkningar, som gör att arkitekturen sakta förvanskas och muterar till något som Erik Dyrelius arbetar som arkitekt på Combitech Systems i Stockholm. Erik är specialiserad på UML och arbetar parallellt som lärare inom området. den aldrig var menad att bli. Under ett av mina kundprojekt arbetade jag en hel del med arkitekturen, varpå jag sedan fick en mer administrativ roll och därmed inte kunde hålla ihop och försvara mina idéer. Följden blev att de begrepp jag hade myntat och de arkitekturella mönster jag hade infört, misstolkades och förvanskades. De levde kvar i projektet, men i en helt annan betydelse och utan att medföra de positiva egenskaper som var anledningen till att jag en gång introducerade dem. När arbetet sprungit ifrån en på detta sätt är det nästan omöjligt att få det på rätt kurs igen. Det är som en snöboll som rullar utför en sluttning. En bra arkitekt kan krama den ursprungliga snöbollen och 14 Nr 1 juni 2001

15 sätta den i rullning, men om han inte springer bredvid och knuffar den i rätt riktning innan den har hunnit bygga upp sin storlek och fart, så har han sedan ingen möjlighet att påverka dess bana, rörelsemängden blir för stor. Avvikelser från den etablerade arkitekturen måste kvävas i sin linda, annars kommer de att mutera arkitekturen till i bästa fall något oanvändbart som slängs bort, och i sämsta fall något oanvändbart som lever kvar och sätter käppar i hjulen för fortsatt konstruktion. Detta stadium är en död arkitektur, och arvtagarna, drabbas hårt av sin arvedel. Den ideale arkitekten Hur ska då arkitekten arbeta? Vilka egenskaper behöver han ha för att hålla sin arkitektur vid liv? Stark och okuvlig Arkitekten behöver vara stark nog att försvara sina idéer och får inte vika sig för något. Jag har vid flera tillfällen upplevt hur en bra grundarkitektur har degenererat på grund av att arkitekten inte klarat av att försvara sina idéer mot konstruktörerna. Kompromisser är i många lägen bra, men eftersom konstruktörerna oftast inte drar åt samma håll, kommer arkitekturen att töjas åt olika håll och slutligen antingen rämna eller bli så uttunnad att den inte förmår hålla ihop konstruktionen längre. Här gäller det att försvara sin arkitekturella stil, för att hålla konsekvens och stabilitet i konstruktionen. Arkitekten behöver också kunna försvara sina idéer mot andra delar av projektet, som ledning, kvalitetskrav och resurshantering, och helst vara framsynt nog att kunna kväsa sådan inverkan tidigt. Lyhörd och flexibel Eftersom mycket av arkitekturarbetet är skissartat, översiktligt och ofta abstrakt, kan det behöva modifieras, exemplifieras och konkretiseras. Att avgöra när det är nödvändigt kräver lyhördhet gentemot konstruktörerna, och att våga erkänna eventuella misstag kräver ett flexibelt tankesätt. Om man misslyckas med detta kommer konstruktionen att ta längre tid än nödvändigt och bli långt ifrån optimal. Maiers, Consensual, säger att varken en envåldsarkitekt eller en arkitekturkommitté är ideal, även om endera kan vara bättre för ett visst projekt. Skicklig Precis som Maier resonerar i stycket om Rational, angående konstruktionsteori, är det bra att arbeta rationellt, eller åtminstone att använda sina heuristiker på ett rationellt sätt, när det rationella arbetssättet inte fullt ut går att använda. Det skrattas ofta åt folk som säger att man inte behöver testa deras konstruktioner, eftersom de har gjort rätt från början, men man ska inte iterera sig fram till en korrekt lösning, eftersom man inte orkar tänka. Att iterera i arkitekturen är vanskligt eftersom hela konstruktionen antagligen kommer att vackla, som i en jordbävning, för varje iteration. Eftersom en arkitektur dessutom är svårtestad så är det bäst om arkitekten gör rätt istället. Detta ska inte blandas ihop med att arkitekten gärna får göra en stegvis förfining av sin arkitektur. Det är inte samma sak som att bygga om, utan snarare att bygga till. Vidsynt En arkitekt som bara ser ett system från ett perspektiv kommer att misslyckas. Faktum är att en av arkitektens huvuduppgifter, precis som Maiers påpekar, är att ansvara för det integrerade perspektivet ; att se systemet från många håll på en gång. Det svåra arbetet här är att se kopplingarna mellan olika vyer, och länkarna mellan elementen. De vanliga konstruktörerna ser kanske en, eller högst två, sidor av systemet och kan inte, på grund av fokusering på den egna uppgiften, förväntas inse kopplingarna till de andra vyerna. Arkitekten, som inte behöver fokusera så djupt på en vy, kan däremot försöka titta åt olika håll samtidigt. En skicklig arkitekt vet också vilka vyer som är viktiga i just det system han bygger. Stålmannen Det vore självfallet bra om den arkitekt som jag just har skissat upp verkligen existerade. Antagligen behöver han låna ytterligare några egenskaper från stålmannen innan han är perfekt. Vi andra dödliga varelser får nöja oss med att analysera på vilka punkter vi fallerar, och sträva efter dessa ideal. Nr 1 juni

16 AV GEORG WILHELM, PETER WOYZESCHKE OCH KARIN ERNI Mönsterbaserad omkonstruktion Publicerad med tillstånd av 101communications. Ursprungligen publicerad i The Journal of Object-Oriented Programming, december 2000 med namnet "Lessons Learned: Pattern-Based Redesign of an Object-Oriented Knowledge-Engineering System". Vid omkonstruktion av kunskapsbyggande system har mönster använts på arkitekturell nivå såväl som på konstruktionsnivå för att uppnå större underhållsbarhet och stabilitet. En efterhandsanalys och en konvergensanalys under betatesten visade att konstruktionsmönster verkligen kunde tillämpas framgångsrikt på bägge nivåerna. Fördelarna med att tillämpa mönster på arkitekturell nivå ligger i att uppnå en beskrivning av de viktiga metaforerna och arkitekturella koncepten hos systemet, som är enkel att förstå och förklara, som en bas och vägledning för konstruktion och implementation. Arkitekturella mönster visade sig också vara effektiva hjälpmedel för att presentera idéerna för intressenter utanför utvecklingsteamet. Fördelarna med att tillämpa mönster på konstruktionsnivå var två: Konstruktionsmönster stödjer den individuella utvecklaren att reflektera över konstruktionsbeslut och tänka nya konstruktionslösningar, samtidigt som konstruktionsmönster påskyndar konstruktionsdiskussioner och granskningar inom utvecklingsteamen. Omvandling på ett halvår Sedan 1995 har ABB Utility Automation (ABB UTA) använt det internt utvecklade kunskapsbyggande systemet SmartPlant Expert (ett gemensamt utvecklingsprojekt för ABB UTA och ABB Corporate Research, Tyskland) för att stödja grundkonstruktion av fabriksanläggningar och för att fånga upp och bevara konstruktionskunnande i sina kunskapsdatabaser. Det beslöts att en första produkt baserad på den interna kunskapsbyggande tillämpningen skulle släppas i slutet av hösten För utvecklingsteamet gällde utmaningen att styra omvandlingen av ett internt verktyg till en riktig produkt på mindre än ett halvt år. Det togs beslut om att starta ett omstruktureringsprojekt med det slutliga målet att komma till rätta med systemets brister ifråga om stabilitet och underhållsbarhet. För vissa utsatta punkter i systemet var en fullständig omarbetning ofrånkomlig, men för de flesta av tillämpningspaketen gällde att koppla loss delar från varandra för att uppnå mindre beroenden och därigenom bättre hantering. Dessutom blev många av tillämpningspaketen varken omkonstruerade eller avskilda utan snarare bara internt ändrade. Tillämpningen: funktionell överblick av SmartPlant Expert Systemet består av två tillämpningar: det kunskapsbyggande verktyget och den projektbyggande tillämpningen. Det kunskapsbyggande verktyget tillåter att en kunskapsingenjör med solid bakgrund, så kallad domänkunskap, i instrument och instrumentstyrning (I&C) och processhantering och processinstrumentering (P&I) att införa kunskap om P&I och I&C i systemet för att göra det (åter)användbart och tillgängligt för andra konstruktionsteam. Tillämpningen för projektkonstruktion tillhandahåller funktionalitet för att alstra konceptuell P&I och I&C för nästan alla delar av en anläggning. Alla lösningar som produceras av systemet är baserade på kunskapen i kunskapsdatabasen och planeringsingenjörens konfigurationsbeslut. Konceptuell vy av systemet Följande huvudsakliga komponenter finns på konceptuell nivå inom SmartPlant Expert (se bild 1): P&I-kunskapseditor, vilken tillåter en domänexpert att föra in P&I-kunskap; I&C-kunskapseditor, vilken tillåter en domänexpert att föra in I&C-kunskap; slutsatsmaskin för P&I, en tolk som skapar P&I för en specifik modul, baserat på P&I-kunskap för denna modul och på de grundläggande beslut, vilka fattats av planeringsingenjören; slutsatsmaskin för I&C, en tolk som skapar I&C för en specifik modul, baserat på det konceptuella P&I-schemat för en viss modul genom att tillämpa I&C-kunskap på denna typ av modul med ledning av de inställningar som planeringsingenjören tillhandahållit. Slutsatsmaskinen för I&C är i sig själv strukturerad i sex komponenter: P&I-editorn, vilken tillåter planeringsingenjören att anpassa sig till det konceptuella P&I (lägga till och ta bort komponenter etc.); I&C-editorn, vilken tillåter användaren att anpassa sig till I&C-lösningen; projektdatabasen, vilken innehåller den uppsättning av konkret planerade moduler där I&C och P&I bearbetas tillsammans (var och en av filerna lagras fysiskt i en separat fil); kunskapsdatabasen, vilken innehåller den uppsättning av abstrakta processmoduler, där I&C-och P&I-kunskap för denna modul infångas (var och en av modulerna lagras fysiskt i en separat fil); SmartPlant Expert ACAD-överföring, vilken skapar en ASCII-fil, som innehåller beskrivningar på P&I- och I&Cresultat och Wizdraw -överföringen, vilken skapar ACAD-grafik från de alstrade ASCII-filerna. Viktiga problemområden för omkonstruktionsuppgiften Utvecklingen av SmartPlant Expert startade 1993 som en ren genomförbarhetsstudie med avsikt att pröva idéer och koncept med hjälp av en prototyp. Underhållsbarhet och arkitektur var av mindre vikt på detta konceptprövningsstadium. Vid slutet av denna fas visade 16 Nr 1 juni 2001

17 det sig att koncepten fungerade väl, och det beslöts att utveckla ett konstruktionssystem för internt bruk baserat på genomförbarhetsstudien. Begränsningen på grund av det fastställda leveransdatumet gjorde det nödvändigt att bygga den interna produkten baserad på prototypen med dess redan befintliga (eller mer exakt icke-existerande) arkitektur. De flesta av de koncept som utgör basen för SmartPlant Expert är tämligen intelligenta och passar perfekt tillsammans (sex programvarupatent blev resultatet av denna fas 1-6 ) men genomförbarhetsprototypen hade ingen riktig arkitektur alls, vare sig från en konceptuell synpunkt eller från tillämpningssynpunkt 2,3. Efter den första leveransen av den interna produkten 1995 införde vi en enkel och snabb felavhjälpningskultur, där fel åtgärdades omgående utan någon strukturerad tankegång. Dessutom lades på toppen av den icke-existerande arkitekturen till en mängd nya funktioner under följande år. Resultatet blev att systemets entropi ökade och systemet blev i stigande grad svårt och tidsödande att underhålla, felsöka och förbättra. Det blev också mycket svårt att ta in nya medlemmar i utvecklingsteamet, på ett sätt som inte införde ännu mer entropi i systemet. Problembeskrivning I Big Ball of Mud 7 beskriver författarna arkitekturella problem såsom dessa. De problem som belyses i deras problembeskrivning stämmer perfekt överens med de problem som bearbetats med SmartPlant Expert. På grund av systemets interna framgång beslöts 1999 att göra extern affär av denna interna produkt. Detta beslut ökade trycket enormt på att lösa de nämnda problemen: För referenser se noterna på sidan 22 P&Ikunskapseditor P&I-inferensmaskin P&I-scheman Bild 1. Översikt av huvudkomponenterna inom SmartPlant Expert 1. Ingen riktig arkitektur 2. Exploderande entropi på grund av nya funktioner på toppen av denna arkitektur 3. Mer entropi på grund av teammedlemmarnas vacklan 4. Underhåll och stabilitet Dessa problem ledde till beslutet att rikta in produktifieringen kring ett omstruktureringsprojekt. Hur dessa högnivåkrav ursprungligen tacklades inom omstruktureringsprojektet beskrivs i nästa avsnitt, och det sätt på vilket dessa åtgärder visade sig verka presenteras i avsnittet Läxan som vi lärde oss. Assistent för anläggningskonstruktion FwPp P&I-editor ACAD-överföring ASCII-filer WIZDRAW ACAD I&C-inferensmaskin I&Ckunskapseditor P&Ischema I&Ceditor P&I- och I&Ckunskap I&C-editor Målsystem neutral I&C Planen: tillämpning av mönster för omstrukturering På den arkitekturella sidan beslöt vi att införa ett litet antal arkitekturella mönster (för ytterligare läsning om arkitekturella mönster se A System of Patterns 8 ) för att fungera som metaforer och beskriva den stora bilden av systemet på ett enkelt sätt, inklusive ömsesidigt beroende mellan systemets komponenter. I den utsträckning dessa metaforer inte redan, eller inte helt, var närvarande i systemet måste omstruktureringen göras enligt metaforerna. Detta gällde huvudsakligen frågan om beroendehantering mellan olika komponenter. Tillämpningen av dessa metaforer Nr 1 juni

18 minskade i stor utsträckning entropin inom systemet. Kritiska punkter Som tillägg till införandet och implementeringen av dessa metaforer beslöt vi att fullständigt strukturera om systemets kritiska punkter. Med kritiska punkter avser vi delar av systemet, där ändringar och fel uppträdde oftast. En av dessa kritiska punkter var kommandotolken för I&C-sökning (SCI). Vi angrep den inre omstruktureringen av dessa komponenter baserat på olika konstruktionsmönster. I denna kolumn väljer vi att konstruera om I&C-sökningstolken som ett exempel på mönsterbaserad omkonstruktion på konstruktionsnivå. Kunskapseditor Kunskap = Regler formulerade inom språket Språksyntaxdefinition = kunskapsrepresentation Resultat Kunskapstolk Kunskapsdata Bild 2 Tillämpning av Interpreter -mönstret för ett kunskapssystem Tillämpning av arkitekturella mönster Följande arkitekturella mönster beskriver mekanismerna för interaktion, komponenternas beroenden och systemets strukturella koncept (typkomponenter): - Översättare ( Interpreter ) - Öppen skiktningsprincip ( Relaxed layer ) - En komponentmetafor genom ett fasadmönster ( Facade ) Öppet, uppifrån och ned skiktat tillvägagångssätt Editorer Uppifrån och ned (endast återuppringning eller kommunikation uppåt med hjälp av konstruktionsmönstret "Observer") Tolkar Öppen skiktningsprincip Editorskikt Tolknings-/ reflektionsskikt Översättare Applicering av konstruktionsmönstret "Interpreter". Interpreter 9 beskriver hur P&I- och I&C-slutsatsmaskinerna arbetar. Kunskap matas in i systemet via kunskapseditorn. En analysator översätter denna kunskap till en tolkningsbar representation. I samband med anläggningsprojektering är denna tolkningsbara representation verkställd och försedd med aktuella uppgifter om anläggningen. Resultatet är de projektspecifika P&I- och I&C-uppgifterna. Tillämpningen av Interpreter avser kravsynpunkterna, underhållsbart sys- Datahanterare Tjänsteleverantör Bild 3 En öppen SmartPlant-skiktning G2-tjänster, G2 OM-skikt UT-skikt G2-skikt 18 Nr 1 juni 2001

19 Klasser i ett delsystem (subsystem) Delsystemets fasad tem och pålitligt system (förutsägbart/deterministiskt system) samt bygger en fast grund för vidare utvidgningar (utbytbarhet). Bild 2 visar tillämpningen av Interpreter -mönstret för vårt kunskapsbaserade tillvägagångssätt. Bild 4 Användning av konstruktionsmönstret "Facade" 9 I-sekvens Sekvensfasad sekvens 1 sekvens 3 sekvens 2 sekvens N Sekvensmodul Detta gränssnitt erbjuder endast en mycket liten uppsättning av tjänster i ett gränssnitt En klass, sekvensfasaden, förenklar de sammansatta och komplicerade sekvenserna med ett API Facade kommer mest sannolikt att vara en Singleton Befintlig modul Bild 5. Tillvägagångssättet med komponenter förbättrat med den fasadförenklande mekanismen Öppen skiktningsprincip Applicering av en öppen skiktningsprincip. Systemet är strukturerat i fem huvudskikt som framgår av bild 3. Detta skiktade tillvägagångssätt följer i själva verket en variant av det skiktade arkitekturmönstret öppen skiktning, relaxed layer (för vidare läsning se A System of Patterns 8 ). Varje skikt får använda tjänster från alla skikt som är under detta. Dessutom är tillvägagångssättet med relaxed layered strikt uppifrån och ned, vilket betyder att det lägre skiktet aldrig känner till de övre skikten. Endast observationsmekanismer eller återuppringning tillåts kommunicera bakåt. Denna begränsning infördes för att hålla beroenden under kontroll. Bild 3 visar detta tillvägagångssätt. Applicering av en komponentmetafor tillsammans med ett fasadmönster. Denna metafor är ett i grunden traditionellt komponentorienterat tillvägagångssätt för att försöka hålla varje komponent så avskild som möjligt från de andra komponenterna och begränsa beroenden hos samhörande komponenter endast till gränssnitten aldrig till det interna hos denna komponent. För att göra det lättare för klienter att använda komponenten är gränssnittet hos varje funktionell modul, som är bearbetad som en komponent, realiserat genom tillämpning av ett konstruktionsmönster kallat fasad, "Facade" (se bild 4; för ytterligare läsning se Design Patterns 9 ). Komplext gränssnitt Före omkonstruktion erbjöd alla dessa Nr 1 juni

20 Klient SCI- FACADE sci-exekvering Facade Adapter SCI-ADAPTER sci-exekvering SCI-LEGACY ADAPTER sci-exekvering SCI-LEGACY ADAPTEE sök komponent, sök mätning sök sammansättning OBJEKT-EVALUATOR SCI-ADAPTEE ITERATOR Strategy evaluate sök komponent, sök mätning, sök sammansättning Adaptee nästa, föregående Strategy COMPONENT- EVAL MEASUREMENT- EVAL EVAL-ITERATOR SÖKNING- ITERATOR KONKRETISERARE konkretisera metod 1 metod 2 metod 3 Strategy Template Method Bild 6. Mönster tillämpade i SCI-paketet KOMPONENT- KONKRETISERARE metod 1 metod 2 metod 3 SAMMANSÄTTNING- KONKRETISERARE metod 1 metod 2 metod 3 funktionella moduler ett ganska komplext och svåranvändbart gränssnitt. Under omkonstruktionen infördes fasader för nästan varje större funktionell modul som inte erbjöd en mager och konsistent uppsättning av gränssnitt. Bild 5 visar komponentkonceptet tillsammans med den förenklingsmekanism som erbjuds genom det fasadbaserade tillvägagångssättet. Tillämpning av mönster på konstruktionsnivå Ett exempel på tillämpning av mönster på konstruktionsnivå utgör den fullständiga omkonstruktionen av kritiska punkter i systemen. För demonstration valde vi ut omkonstruktion av SCI, ett av kärnpaketen i I&C-slutsatsmaskinen. Tolken kan lätt delas upp i sex logiska delkomponenter: - konkretiserare - iterator - programgrensutvärderare - objektutvärderare - utvärderare för stoppkriterier - kvantitetsutvärderare Beroende på det aktuella schemaobjektet (pump, ventil etc.) som just bearbetas av tolken (kontextinformation) måste dessa delkomponenter tillhandahålla något varierande beteenden. Vi har använt strategimönstret ("Strategy") för att belysa detta i vår konstruktion. För att på ett elegant sätt stödja den ärvda SCI (beroende på oförenligheter i specifikationerna för de nya och de gamla) tillämpades anpassningsmönstret Adapter. Dessa två mönster användes mer på strukturnivå, men vi använde även ett annat mönster på implementeringsnivå: Template Method. En fast stomme Konkretiseringskomponenten är den avgjort största, beroende på en mängd 20 Nr 1 juni 2001

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Introduktion. Byggstenar TDBA63 2005-11-22

Introduktion. Byggstenar TDBA63 2005-11-22 Introduktion UML står för Unified Modeling Language. Det är tänkt att fungera som hjälpmedel vid modellering av alla tänkbara typer av utvecklingsarbeten, inte bara inom dataomdrådet. Det största värdet

Läs mer

KONSTRUKTION. Ämnets syfte. Kurser i ämnet

KONSTRUKTION. Ämnets syfte. Kurser i ämnet KONSTRUKTION Ämnet konstruktion behandlar konstruktionsprocesser från idé till färdig produkt, där syftet är att utforma och dimensionera produkter med sikte på ändamålsenlig formgivning, funktion och

Läs mer

Kort om kursplanen i teknik

Kort om kursplanen i teknik Kort om kursplanen i teknik är ett sammandrag av Skolverkets kursplan i teknik från Läroplan för grundskolan, förskoleklassen och fritidshemmet 2011 1 samt Kommentarmaterial till kursplanen i teknik 2.

Läs mer

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell Informationsstruktur 2015:1 Bilaga 7: Arkitektur och metodbeskrivning Innehåll Nationell informationsstruktur arkitektur och metod... 3 Standarder inom informatik... 3 NI relaterat till ISO 42010...

Läs mer

Kursplan för Matematik

Kursplan för Matematik Sida 1 av 5 Kursplan för Matematik Inrättad 2000-07 SKOLFS: 2000:135 Ämnets syfte och roll i utbildningen Grundskolan har till uppgift att hos eleven utveckla sådana kunskaper i matematik som behövs för

Läs mer

Objektorientering. Grunderna i OO

Objektorientering. Grunderna i OO Objektorientering Grunderna i OO 1 Systemutveckling Tre systemnivåer: Verksamhet Informationssystem Datasystem Huvuduppgifterna i ett systemutvecklingsarbete: Verksamhetsanalys Informationsbehovsanalys

Läs mer

Spetskompetens inom systemintegration, SOA och systemutveckling

Spetskompetens inom systemintegration, SOA och systemutveckling Spetskompetens inom systemintegration, SOA och systemutveckling Mjukvarukraft är ett företag som inriktar sig på konsultation och systemutveckling baserad på och omkring Microsofts plattformar och produkter.

Läs mer

Om kompetens och lärande

Om kompetens och lärande Om kompetens och lärande Vi bär på mycket mer kunskap än vi tror och kan så mycket mer än vi anar! När som helst i livet har du nytta och glädje av att bli medveten om delarna i din kompetens. Du funderar

Läs mer

Om ämnet Engelska. Bakgrund och motiv

Om ämnet Engelska. Bakgrund och motiv Om ämnet Engelska Bakgrund och motiv Ämnet engelska har gemensam uppbyggnad och struktur med ämnena moderna språk och svenskt teckenspråk för hörande. Dessa ämnen är strukturerade i ett system av språkfärdighetsnivåer,

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Ett projektarbete i svenska, teknik och engelska, riktat mot DICE. Thoren Innovation School HT2012.

Ett projektarbete i svenska, teknik och engelska, riktat mot DICE. Thoren Innovation School HT2012. PROJEKT: DICE Ett projektarbete i svenska, teknik och engelska, riktat mot DICE. Thoren Innovation School HT2012. UPPDRAG Uppgiften är att arbeta med den första delen av teknikutvecklingsprocessen d.v.s.

Läs mer

Vad är professionell kunskap? Ivor F. Goodson och Studentlitteratur 2005

Vad är professionell kunskap? Ivor F. Goodson och Studentlitteratur 2005 Del 1 Vad är professionell kunskap? Kapitel 1: Introduktion: olika former av professionell kunskap I detta inledande kapitel ges en översikt över synen på professionell kunskap med avseende på undervisning

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

Rätt information till rätt person vid rätt tillfälle

Rätt information till rätt person vid rätt tillfälle Rätt information till rätt person vid rätt tillfälle System för samverkan, effektivitet och konkurrenskraft Du håller säkert med om att ditt företags kanske mest värdefulla tillgång består av all den information

Läs mer

Riktlinjer för digital arkivering i Linköpings kommun

Riktlinjer för digital arkivering i Linköpings kommun 1 (8) E-Lin projektet 2014-06-05 Riktlinjer Riktlinjer för digital arkivering i Linköpings kommun 2 Innehåll Inledning och bakgrund... 3 Ansvar... 4 Systemupphandling... 4 Gallring... 5 Informationssäkerhet...

Läs mer

ICF:s kärnkompetenser för professionell coaching

ICF:s kärnkompetenser för professionell coaching Ämne ICF Kärnkompetenser en översättning till svenska Dokumentansvarig Styrelsen för ICF Sverige 2009 Datum ICF:s kärnkompetenser för professionell coaching ICF har definierat elva kompetenser som utgör

Läs mer

Mål som eleverna skall ha uppnått i slutet av år 5 enligt nationella kursplanen

Mål som eleverna skall ha uppnått i slutet av år 5 enligt nationella kursplanen Teknik Mål att sträva mot enligt nationella kursplanen Skolan skall i sin undervisning i teknik sträva efter att eleven utvecklar sina insikter i den tekniska kulturens kunskapstraditioner och utveckling

Läs mer

Distribuerade affärssystem

Distribuerade affärssystem Distribuerade affärssystem Kursens mål Bygga upp, strukturera och programmera distribuerade system med en flerskiktsarkitektur Beskriva och förklara teorier och uttryck som används inom affärskritiska

Läs mer

Internationell säljare/marknadsförare, 80 poäng

Internationell säljare/marknadsförare, 80 poäng Internationell säljare/marknadsförare, 80 poäng Kursplan Projektmetodik (2 KY-poäng) ha kunskap om vad ett projekt är och känna till varför och när projekt är en lämplig arbetsform vara medveten om vilka

Läs mer

Bibliotekarien som intern konsult - erfarenheter från omvärldsbevakning i kommun och företag.

Bibliotekarien som intern konsult - erfarenheter från omvärldsbevakning i kommun och företag. Katarina Kristoffersson & Bibliotekarien som intern konsult - erfarenheter från omvärldsbevakning i kommun och företag. Paper presenterat vid konferensen 11-12 oktober 2006 i Borås Om föredragshållarna

Läs mer

Föreläsning 15: Repetition DVGA02

Föreläsning 15: Repetition DVGA02 Föreläsning 15: Repetition DVGA02 Vad handlar kursen om? Kursen kan i grova drag delas upp i tre delar: 1. Objekt-orienterad programmering 2. Grafiska användargränssnitt 3. Datastrukturer Dessutom genomsyras

Läs mer

Rymdutmaningen koppling till Lgr11

Rymdutmaningen koppling till Lgr11 en koppling till Lgr11 När man arbetar med LEGO i undervisningen så är det bara lärarens och elevernas fantasi som sätter gränserna för vilka delar av kursplanerna man arbetar med. Vi listar de delar av

Läs mer

CAD. Ämnets syfte. Kurser i ämnet

CAD. Ämnets syfte. Kurser i ämnet CAD Ämnet cad (computer aided design) behandlar hur man använder olika programvaror för att konstruera och designa verkliga och virtuella objekt. I ämnet är geometri grunden för att, via skiss och ritteknik,

Läs mer

Kursplanering Objektorienterad programmering

Kursplanering Objektorienterad programmering Kursplanering Objektorienterad programmering Fakta Ämne Programmering Poäng 40 Yh-poäng Kurskod YSYS-OOP Klass Systemutvecklare.NET 2 Syfte och koppling till yrkesrollen Syftet är att få en stabil grund

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

UTBILDNING: Effektiv processutveckling

UTBILDNING: Effektiv processutveckling UTBILDNING: Effektiv processutveckling Introduktion Kursen i effektiv processutveckling fokuserar på effektiva, väl beprövade arbetssätt för att identifiera, definiera, kartlägga och utveckla företagets

Läs mer

SKOLFS. beslutade den maj 2015.

SKOLFS. beslutade den maj 2015. Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:244) om ämnesplan för ämnet cad i gymnasieskolan och inom kommunal vuxenutbildning på gymnasial nivå; beslutade den maj 2015. Med stöd av

Läs mer

Utdrag från kapitel 1

Utdrag från kapitel 1 Utdrag från kapitel 1 1.1 Varför en bok om produktionsutveckling? Finns det inte böcker om produktion så att det räcker och blir över redan? Svaret på den frågan är både ja och nej! Det finns många bra

Läs mer

Övergripande granskning av ITverksamheten

Övergripande granskning av ITverksamheten Övergripande granskning av ITverksamheten Februari 2006 (1) 1. Inledning PricewaterhouseCoopers (PwC) har på uppdrag av kommunrevisionen i Borås Stad genomfört en övergripande granskning av Borås Stads

Läs mer

RIKTLINJER FÖR STYRDOKUMENT

RIKTLINJER FÖR STYRDOKUMENT RIKTLINJER FÖR STYRDOKUMENT Fastställt av: Kommunfullmäktige Datum: 2012-06-19, 81 För revidering ansvarar: Kommunstyrelsen För eventuell uppföljning och tidplan ansvarar: - Dokumentet gäller för: Alla

Läs mer

DD2458-224344 - 2014-12-19

DD2458-224344 - 2014-12-19 KTH / KURSWEBB / PROBLEMLÖSNING OCH PROGRAMMERING UNDER PRESS DD2458-224344 - 2014-12-19 Antal respondenter: 26 Antal svar: 18 Svarsfrekvens: 69,23 % RESPONDENTERNAS PROFIL (Jag är: Man) Det var typ en

Läs mer

Programmering. Hur, var, när och varför. 22 November. Lars Ohlén Tieto lars.ohlen@tieto.com

Programmering. Hur, var, när och varför. 22 November. Lars Ohlén Tieto lars.ohlen@tieto.com Programmering Hur, var, när och varför 22 November Lars Ohlén Tieto lars.ohlen@tieto.com Agenda Om mig Programmering Vad är? Varför kunna? Hur använda kunskapen? Framtiden Sammanfattning Q+A 2 Om mig Arbetat

Läs mer

Utveckling av ett grafiskt användargränssnitt

Utveckling av ett grafiskt användargränssnitt Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat

Läs mer

Naturvetenskapsprogrammet (NA)

Naturvetenskapsprogrammet (NA) Naturvetenskapsprogrammet (NA) Naturvetenskapsprogrammet (NA) ska utveckla elevernas kunskaper om sammanhang i naturen, om livets villkor, om fysikaliska fenomen och skeenden och om kemiska processer.

Läs mer

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Att bedriva effektiv framgångsrik förändring har varit i fokus under lång tid. Förändringstrycket är idag högre än någonsin

Läs mer

Riktlinjer för bedömning av examensarbeten

Riktlinjer för bedömning av examensarbeten Fastställda av Styrelsen för utbildning 2010-09-10 Dnr: 4603/10-300 Senast reviderade 2012-08-17 Riktlinjer för bedömning av Sedan 1 juli 2007 ska enligt högskoleförordningen samtliga yrkesutbildningar

Läs mer

AvI-index. Ett instrument för att mäta IT-systems användbarhet

AvI-index. Ett instrument för att mäta IT-systems användbarhet ANDERS GUNÉR AvI-index Ett instrument för att mäta IT-systems användbarhet Iordanis Kavathatzopoulos Uppsala universitet ISBN 978-91-976643-5-6 Copyright 2008 Iordanis Kavathatzopoulos. Uppsala universitet,

Läs mer

2012-01-12 FÖRSLAG TILL KURSPLAN INOM KOMMUNAL VUXENUTBILDNING GRUNDLÄGGANDE NIVÅ

2012-01-12 FÖRSLAG TILL KURSPLAN INOM KOMMUNAL VUXENUTBILDNING GRUNDLÄGGANDE NIVÅ Matematik, 600 verksamhetspoäng Ämnet handlar bland annat om mängder, tal och geometriska figurer. Matematiken har en flertusenårig historia med bidrag från många kulturer. Den utvecklas såväl ur praktiska

Läs mer

Teknikprogrammet (TE)

Teknikprogrammet (TE) Teknikprogrammet (TE) Teknikprogrammet (TE) ska utveckla elevernas kunskaper om och färdigheter i teknik och teknisk utveckling. Efter examen från programmet ska eleverna ha kunskaper för högskolestudier

Läs mer

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 Document: STG/PS K 525SV1 Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 SIS, Projekt Kvalitetsledning 1 1) Introduktion Produktstöd Två av de viktigaste målsättningarna i arbetet

Läs mer

De t Mobil Tim gl as e t

De t Mobil Tim gl as e t Det Mobila Timglaset Det mobila timglaset Det mobila timglaset är framtaget för att öka förståelsen för hur en organisation påverkas och kan höja sin effektivitet genom att införa mobil ärendehantering.

Läs mer

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08 JavaRats Kravspecifikation Version 1.1 Gustav Skoglund gussk258@student.liu.se Marcus Widblom marwi026@student.liu.se Senast ändrad: 13 / 05 / 08 Sammanfattning Kravspecifikationen för JavaRats har skrivit

Läs mer

Projekt intranät Office 365 av Per Ekstedt

Projekt intranät Office 365 av Per Ekstedt Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget

Läs mer

INGENJÖRSPROGRAMMET FÖR PROJEKTLEDNING, 120 POÄNG Programme for Project Management in Engineering, 120 points

INGENJÖRSPROGRAMMET FÖR PROJEKTLEDNING, 120 POÄNG Programme for Project Management in Engineering, 120 points UTBILDNINGSPLAN INGENJÖRSPROGRAMMET FÖR PROJEKTLEDNING, 120 POÄNG Programme for Project Management in Engineering, 120 points Utbildningsprogrammet inrättades den 31 november 2001 av fakultetsnämnden för

Läs mer

AVKODAR DIN TANKE- OCH BESLUTSSTIL

AVKODAR DIN TANKE- OCH BESLUTSSTIL AVKODAR DIN TANKE- OCH BESLUTSSTIL Maj 29, 2015 OMDÖMES RAPPORT John Doe ID UH565474 2014 Hogan Assessment Systems Inc. SAMMANFATTNING Denna rapport utvärderar John Does omdömes- och sstil genom att analysera

Läs mer

Ur sammanställning av delprojektet Organisationen som inkluderande eller exkluderande. Linnea Lundin. Del två, Verktyg för en öppnare organisation.

Ur sammanställning av delprojektet Organisationen som inkluderande eller exkluderande. Linnea Lundin. Del två, Verktyg för en öppnare organisation. Ur sammanställning av delprojektet Organisationen som inkluderande eller exkluderande. Linnea Lundin. Del två, Verktyg för en öppnare organisation. För att kunna arbeta med mångfald i organisationen är

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kurswebb: www.creativerooms.se/edu, välj Gränssnittsdesign eller Webbutveckling 1 Lärare: Aino-Maria Kumpulainen, aino-maria.kumpulainen@it-gymnasiet.se

Läs mer

Min syn på optimal kommunikation i en PU-process

Min syn på optimal kommunikation i en PU-process Min syn på optimal kommunikation i en PU-process KN3060 Produktutveckling med formgivning Mälardalens högskola Anders Lindin Inledning Denna essä beskriver min syn på optimal kommunikation i en produktutvecklingsprocess.

Läs mer

Ordinarie tentamen ht 2011 för biologimomentet i Klimatförändringar orsaker och verkan.

Ordinarie tentamen ht 2011 för biologimomentet i Klimatförändringar orsaker och verkan. Ordinarie tentamen ht 2011 för biologimomentet i Klimatförändringar orsaker och verkan. Observera att a) dina svar måste vara läsbara för att du ska få poäng för dem, samt b) grafer måste ha axelbenämningar

Läs mer

ENGELSKA. Ämnets syfte. Kurser i ämnet

ENGELSKA. Ämnets syfte. Kurser i ämnet ENGELSKA Det engelska språket omger oss i vardagen och används inom skilda områden som kultur, politik, utbildning och ekonomi. Kunskaper i engelska ökar individens möjligheter att ingå i olika sociala

Läs mer

Design. Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering sammanfa0ning 13/04/14

Design. Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering sammanfa0ning 13/04/14 Design Vad är design? Vad är arkitektur? Architectural Pa:erns Designprinciper Design Pa:erns UML Domain Driven Design Domänmodell Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering

Läs mer

Vilket moln passar dig bäst?

Vilket moln passar dig bäst? Vilket moln passar dig bäst? Idag diskuteras ofta huruvida man ska kliva in i molnets underbara värld eller inte, men sällan om skillnaderna mellan olika moln och vilka tillämpningar som är lämpliga att

Läs mer

Vår vision Vi skapar öppna vägar till kunskap för ett gott samhälle

Vår vision Vi skapar öppna vägar till kunskap för ett gott samhälle Vår vision Vi skapar öppna vägar till kunskap för ett gott samhälle Den högre utbildningen i Dalarna har långa traditioner inom ingenjörsutbildning (Fahlu Bergsskola 1822), lärarutbildning (Folkskolelärarinneseminariet

Läs mer

- Budget och uppföljning - Kundfakturor fakturor till kund/brukare - Leverantörsfakturor fakturor från leverantör - Lönehantering

- Budget och uppföljning - Kundfakturor fakturor till kund/brukare - Leverantörsfakturor fakturor från leverantör - Lönehantering 1(5) KS 2011/0014 Svar på revisionsrapport- Granskning av ekonomiadministrativa processer - Effektivitetsgranskning Bakgrund Danderyds förtroendevalda revisorer har uppdragit till PricewaterhouseCoopers

Läs mer

Det balanserade ledarskapet

Det balanserade ledarskapet Det balanserade ledarskapet Jag talade nyligen med en utländsk kontakt och vi talade om ledarskap. En av frågorna han ställde till mig var då; hur definierar du skillnaden mellan chef och ledare? Bra fråga

Läs mer

Datorrepresentation av vårdriktlinjer

Datorrepresentation av vårdriktlinjer Datorrepresentation av vårdriktlinjer Innehåll Introduktion/bakgrund Behov Uppdateringsproblem Metoder PROforma Asgaard/Arbru Arden Praktiska implementeringar Hypertoni-behandling Guidelines/vårdriktlinjer

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer

Visionen om en Tjänstekatalog

Visionen om en Tjänstekatalog Visionen om en Tjänstekatalog Varför ska vi införa tjänster? Copyright BiTA Service Management/Rolf Norrman 1 IT:s värde för verksamheten tydliggörs i verksamhetens egna termer Organisationens kundfokus

Läs mer

En CAD-ansvarigs syn på integrering mot CAD.

En CAD-ansvarigs syn på integrering mot CAD. En CAD-ansvarigs syn på integrering mot CAD. Kraven på att minska ledtiderna ökar. Hur kan man med de verktyg som finns på marknaden organisera det hela så att det förenklar konstruktörens arbete och hela

Läs mer

Kompetenskriterier för ledare i Lunds kommun

Kompetenskriterier för ledare i Lunds kommun Kompetenskriterier för ledare i Lunds kommun Som ledare i Lunds kommun har du en avgörande betydelse för verksamhetens kvalitet. Du har stort inflytande på hur medarbetare presterar och trivs samt hur

Läs mer

Frågor och svar. Programvaror och tjänster 2014 - Systemutveckling. Statens inköpscentral vid Kammarkollegiet

Frågor och svar. Programvaror och tjänster 2014 - Systemutveckling. Statens inköpscentral vid Kammarkollegiet Frågor och svar Köpare Upphandling Köpare: Statens inköpscentral vid Kammarkollegiet Namn: Handläggare: Daniel Melin Referensnr: 96-36-2014 Programvaror och tjänster 2014 - Systemutveckling Telefon: +46

Läs mer

Kursen kommer att handla om: Mål med arbetet från Lgr 11. Lokal Pedagogisk Planering Läsåret 12-13

Kursen kommer att handla om: Mål med arbetet från Lgr 11. Lokal Pedagogisk Planering Läsåret 12-13 Kurs: Storyline Market place Tidsperiod: Vecka 46- Skola: Åsens Skola Klass: F-5 Lärare: Alla Kursen kommer att handla om: Du kommer att få arbeta med Storylinen Market place där du ska få lära dig hur

Läs mer

Programmering B med Visual C++ 2008

Programmering B med Visual C++ 2008 Programmering B med Visual C++ 2008 Innehållsförteckning 1 Repetition och lite nytt...5 I detta kapitel... 5 Programexekvering... 5 Loop... 5 Källkod... 6 Verktyg... 6 Säkerhetskopiera... 6 Öppna, kompilera,

Läs mer

Utveckling av Läsaren

Utveckling av Läsaren Utveckling av Läsaren Projektet steg för steg Läsaren har utvecklats sucessivt till att bli den anpassningsbara och situationsoberoende tjänst den är idag. Tabellen nedan visar hur utvecklingen har skett

Läs mer

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1 Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

Niccolo Machiavelli 1469

Niccolo Machiavelli 1469 Det finns ingenting så svårt att ta itu med, ingenting så vådligt att leda, ingenting så osäkert i framgång som att söka införa de nya tingens ordning. Den som förändrar får nämligen som motståndare alla

Läs mer

Resultatrapport. Exempel IOL TOOL. Framtagen till: Framtagen av: Sammanställd den 12 oktober, 2014

Resultatrapport. Exempel IOL TOOL. Framtagen till: Framtagen av: Sammanställd den 12 oktober, 2014 Resultatrapport Sammanställd den 12 oktober, 2014 Framtagen till: Exempel Framtagen av: IOL TOOL Kopieringsförbud Denna rapport är skyddad av upphovsrättslagen. Kopiering är förbjuden utöver vad som anges

Läs mer

1-3: Några enkla ord och begrepp för att benämna och samtala om tekniska lösningar.

1-3: Några enkla ord och begrepp för att benämna och samtala om tekniska lösningar. Skisser, ritningar och modeller Centralt innehåll Lgr11 årskurs 1-9 Tekniska lösningar 1-3: Några enkla ord och begrepp för att benämna och samtala om tekniska lösningar. 4-6: Ord och begrepp för att benämna

Läs mer

Maskininvesteringar. Gör rätt från start. Låt oss hjälpas åt - för att få lönsamhet på din maskin. Mycket snabbare.

Maskininvesteringar. Gör rätt från start. Låt oss hjälpas åt - för att få lönsamhet på din maskin. Mycket snabbare. Maskininvesteringar Gör rätt från start Låt oss hjälpas åt - för att få lönsamhet på din maskin. Mycket snabbare. 12 minuter kan ge dig 12 månader Om du funderar på att köpa en ny maskin, ge oss 12 minuter

Läs mer

a White Paper by Idea2Innovation Framtidens arbetssätt.

a White Paper by Idea2Innovation Framtidens arbetssätt. a White Paper by Idea2Innovation Framtidens arbetssätt. Det är tveklöst så att arbetslivet så som vi känner till det genomgår en snabb förändring. Även om det sker olika snabbt i olika branscher, så genomsyrar

Läs mer

Utforma säkerhetsprocesser

Utforma säkerhetsprocesser Utforma säkerhetsprocesser www.informationssäkerhet.se 2 Upphovsrätt Tillåtelse ges att kopiera, distribuera, överföra samt skapa egna bearbetningar av detta dokument, även för kommersiellt bruk. Upphovsmannen

Läs mer

UTBILDNING: Företagsstrategi i praktiken

UTBILDNING: Företagsstrategi i praktiken UTBILDNING: Företagsstrategi i praktiken Introduktion Ett effektivt lednings- och strategiarbete med en strukturerad affärsplanering är en förutsättning för att skapa långsiktigt lönsamma och konkurrenskraftiga

Läs mer

Affärssamhällets grund aktiviteter på kundens villkor i kundens värld

Affärssamhällets grund aktiviteter på kundens villkor i kundens värld Affärssamhällets grund aktiviteter på kundens villkor i kundens värld Är finanskrisen ett resultat av bristande kompetens? Det låter spontant som om frågan borde besvaras ja, med tanke på att om det går

Läs mer

Affärssystem. Linda Askenäs Linköpings universitet

Affärssystem. Linda Askenäs Linköpings universitet Affärssystem Linda Askenäs Linköpings universitet AS AS i sitt sammanhang i verksamheten - val, införande och användning Finns flera sätt att betrakta detta. Vi skall gå in på några framförallt tekniska,

Läs mer

Praesideo digitalt högtalar- och utrymningslarmssystem Få fram ert budskap vad som än händer

Praesideo digitalt högtalar- och utrymningslarmssystem Få fram ert budskap vad som än händer Praesideo digitalt högtalar- och utrymningslarmssystem Få fram ert budskap vad som än händer 2 Praesideo högtalar- och utrymningslarmssystem från Bosch Hålla allmänheten informerad och skyddad Med fler

Läs mer

SBL Företagsledning. för bygg och fastighet

SBL Företagsledning. för bygg och fastighet SBL Företagsledning för bygg och fastighet SBL FörETagSLEdning FÖr bygg och fastighet Företagsledningsprogram med fokus på utmaningar inom bygg- och fastighetssektorn Vår utgångspunkt är att utveckla ditt

Läs mer

Vad är. Domändriven design?

Vad är. Domändriven design? Vad är Domändriven design? 1 Domändriven design är utvecklare och domänexperter som arbetar tillsammans för att skapa mjukvara som är både begriplig och möjlig att underhålla. ett sätt att fånga och sprida

Läs mer

Kursplan ENGELSKA. Ämnets syfte. Mål. Innehåll. Insikt med utsikt

Kursplan ENGELSKA. Ämnets syfte. Mål. Innehåll. Insikt med utsikt Kursplan ENGELSKA Ämnets syfte Undervisningen i ämnet engelska ska syfta till att deltagarna utvecklar språk- och omvärldskunskaper så att de kan, vill och vågar använda engelska i olika situationer och

Läs mer

Projekt- och kvalitetsstyrning på Frontec

Projekt- och kvalitetsstyrning på Frontec Projekt- och kvalitetsstyrning på Frontec Detta dokument beskriver hur Frontec bedriver utvecklingsprojekt med kvalitetssäkring FSAB_LS020_Projekt och kvalitetsstyrning A.doc Sida 1(6) Frontec kan projekt

Läs mer

2. Den andra sanningen är att trovärdighet är grunden för ledarskap.

2. Den andra sanningen är att trovärdighet är grunden för ledarskap. LEDARSKAPETS SANNINGAR (Liber, 2011) James Kouzes är Barry Posner är båda professorer i ledarskap och i boken sammanfattar de det viktigaste de lärt sig efter att ha studerat framgångsrikt ledarskap i

Läs mer

Insikt. kräver kunskap, erfarenhet och förståelse

Insikt. kräver kunskap, erfarenhet och förståelse Insikt kräver kunskap, erfarenhet och förståelse Målet är utveckling... håller inte måttet Företag med teknologibaserad utveckling står idag inför många utmaningar. Den viktigaste är utan tvekan förmågan

Läs mer

En infrastruktur för administrativ informationsförsörjning IT-strategiska avdelningen

En infrastruktur för administrativ informationsförsörjning IT-strategiska avdelningen UFV 2009/256 IT-strategiska avdelningen PM 2009-02-05 Beställare Per Lindgren Författare Gerolf Nauwerck En infrastruktur för administrativ informationsförsörjning Universitetets administration på alla

Läs mer

Riktlinjer för kompetensutveckling

Riktlinjer för kompetensutveckling Riktlinjer för kompetensutveckling Haparanda Stad Antagen av kommunstyrelse 2000-06-13 RIKTLINJER FÖR KOMPETENSUTVECKLING I HAPARANDA STAD Inledning Kompetens och kompetensutveckling är ord som vi kan

Läs mer

Undervisningen i ämnet engelska ska ge eleverna förutsättningar att utveckla följande:

Undervisningen i ämnet engelska ska ge eleverna förutsättningar att utveckla följande: ENGELSKA Det engelska språket omger oss i vardagen och används inom skilda områden som kultur, politik, utbildning och ekonomi. Kunskaper i engelska ökar individens möjligheter att ingå i olika sociala

Läs mer

HUR MAN LYCKAS MED BYOD

HUR MAN LYCKAS MED BYOD HUR MAN LYCKAS MED BYOD WHITE PAPER Innehållsförteckning Inledning... 3 BYOD Checklista... 4 1. Val av system... 4 2. Installation och konfiguration... 5 3. Prestanda... 5 4. Valfrihet ökar upplevelsen...

Läs mer

INSTITUTIONEN FÖR MATEMATIK OCH NATURVETENSKAP. Fastställd i institutionsstyrelsen 2003-06-11 Dnr 853/333-03

INSTITUTIONEN FÖR MATEMATIK OCH NATURVETENSKAP. Fastställd i institutionsstyrelsen 2003-06-11 Dnr 853/333-03 INSTITUTIONEN FÖR MATEMATIK OCH NATURVETENSKAP LOKAL UTBILDNINGSPLAN MEDIEINFORMATIKPROGRAMMET 120 POÄNG MI03 Fastställd i institutionsstyrelsen 2003-06-11 Dnr 853/333-03 INNEHÅLL LOKAL UTBILDNINGSPLAN

Läs mer

SODEXOS FÖRKLARING OM AFFÄRSINTEGRITET

SODEXOS FÖRKLARING OM AFFÄRSINTEGRITET Stockholm 2009-06-01 SODEXOS FÖRKLARING OM AFFÄRSINTEGRITET Sodexos ambition är att ses som normgivande när det gäller de typer av tjänster vi tillhandahåller. Vår vision att som partner till våra kunder

Läs mer

Business Model Transformation. Banbrytande affärsmodeller genom transformation av affärsarkitektur

Business Model Transformation. Banbrytande affärsmodeller genom transformation av affärsarkitektur Business Model Transformation Banbrytande genom transformation av affärsarkitektur Business Model Transformation Vår grundläggande metod för affärsutveckling och transformation av verksamheter kallar vi

Läs mer

KOMMUNIKATIVT LEDARSKAP

KOMMUNIKATIVT LEDARSKAP KOMMUNIKATIVT LEDARSKAP 7, 100, 85, 7 EN ANALYS AV INTERVJUER MED CHEFER OCH MEDARBETARE I FEM FÖRETAG NORRMEJERIER SAAB SANDVIK SPENDRUPS VOLVO Mittuniversitetet Avdelningen för medieoch kommunikationsvetenskap

Läs mer

KOMMUNIKATIVT LEDARSKAP

KOMMUNIKATIVT LEDARSKAP KOMMUNIKATIVT LEDARSKAP 7, 100, 85, 7 EN ANALYS AV INTERVJUER MED CHEFER OCH MEDARBETARE I FEM FÖRETAG NORRMEJERIER SAAB SANDVIK SPENDRUPS VOLVO Mittuniversitetet Avdelningen för medieoch kommunikationsvetenskap

Läs mer

Vad utmärker ett bra användargränssnitt?

Vad utmärker ett bra användargränssnitt? Vad utmärker ett bra användargränssnitt? Att kommunicera med användarna Feedback och Pliancy Excise kontra Flow GUI = Graphic User Interface GUI = Graphic User Interface GUIn, eller grafiska gränssnitt

Läs mer