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 info@combitechsystems.com 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

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design RE SD PD I UT IT ST AT Mjukvarudesign System Requirement Specification Inkrementell och iterativ! Konceptuell design (VAD) Systemdesign (OOA) Arkitekturell (grovkornig, UML) Teknisk design (HUR) Programdesign

Läs mer

Objektorienterad programmering, allmänt

Objektorienterad programmering, allmänt Objektorienterad programmering, allmänt Sven-Olof Nyström Uppsala Universitet 17 juni 2005 1 Vilka egenskaper vill vi att program ska ha? Förslag (en partiell lista): De ska... gå snabbt att skriva vara

Läs mer

Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt. Vilka egenskaper vill vi att våra program ska ha?

Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt. Vilka egenskaper vill vi att våra program ska ha? Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt Sven-Olof Nyström Uppsala Universitet 17 mars 2005 1. Korrekthet 2. Robusthet 3. Utökbarhet 4. Återanvändbarhet 5. Kompatibilitet

Läs mer

Objektorienterad programmering

Objektorienterad programmering Objektorienterad programmering Aletta Nylén http://user.it.uu.se/~aletta Epost: aletta.nylen@it.uu.se Rum: 1216 Kursinfo Lärare: Aletta Nylén Jesper Wilhelmsson Litteratur: Object-Oriented Software Development

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

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ Föreläsning 7 OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram - Kravspecifikationer, användningsfall, systemarkitektur - Analysfas vad är analys?

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

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

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

Designmönster, introduktion. Vad är det? Varför skall man använda mönster?

Designmönster, introduktion. Vad är det? Varför skall man använda mönster? Designmönster, introduktion. Vad är det? Varför skall man använda mönster? Kent Petersson EMW, Mölndal Datavetenskap, Chalmers epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.se/~kentp

Läs mer

Designmönster - EMW. Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.

Designmönster - EMW. Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers. Designmönster - EMW Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.se/~kentp arbetar på Inst. för Datavetenskap, Cth & Gu, 50% och Software

Läs mer

Mälardalens högskola

Mälardalens högskola Teknisk rapportskrivning - en kortfattad handledning (Version 1.2) Mälardalens högskola Institutionen för datateknik (IDt) Thomas Larsson 10 september 1998 Västerås Sammanfattning En mycket viktig del

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

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

Objektorienterad analys och design

Objektorienterad analys och design Objektorienterad analys och design Objektorienterad analys och design 1 Dagens föreläsning Första delen, innan rasten: Motivation och bakgrund Analys Funktioner Andra delen, efter rasten: Objektorienterade

Läs mer

Sammanfattning av modulen modeller och representationer Hur går jag vidare?

Sammanfattning av modulen modeller och representationer Hur går jag vidare? Naturvetenskap - gymnasieskolan Modul: Modeller och representationer Del 8: Representationskompetens Sammanfattning av modulen modeller och representationer Hur Konrad Schönborn, Linköpings universitet

Läs mer

SKOLFS. beslutade den -- maj 2015.

SKOLFS. beslutade den -- maj 2015. SKOLFS Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:247) om ämnesplan för ämnet programmering i gymnasieskolan och inom kommunal vuxenutbildning på gymnasial nivå; beslutade den -- maj

Läs mer

Objektorienterad analys och design

Objektorienterad analys och design Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 1 Objekt-orienterad analys och design: Litteratur Skansholm: Kapitel 4 Se även 1. http://www.uml.org/ 2. http://www-306.ibm.com/software/rational/uml/

Läs mer

Strategi Program Plan Policy» Riktlinjer Regler. Borås Stads. Riktlinjer för styrdokument. Riktlinjer för styrdokument 1

Strategi Program Plan Policy» Riktlinjer Regler. Borås Stads. Riktlinjer för styrdokument. Riktlinjer för styrdokument 1 Strategi Program Plan Policy» Riktlinjer Regler Borås Stads Riktlinjer för styrdokument Riktlinjer för styrdokument 1 Borås Stads styrdokument» Aktiverande strategi avgörande vägval för att nå målen för

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

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

KONSTRUKTION. Ämnets syfte

KONSTRUKTION. Ämnets syfte 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

1. Förtydliga och förstå lärandemål och bedömningskriterier

1. Förtydliga och förstå lärandemål och bedömningskriterier 1. Förtydliga och förstå lärandemål och bedömningskriterier En förutsättning för framgångsrikt arbete med bedömning för lärande bygger på att eleverna delges och får förståelse för målen med undervisningen

Läs mer

Analys och design. Objekt. Klass. med hjälp av CRC. Klassdiagram

Analys och design. Objekt. Klass. med hjälp av CRC. Klassdiagram Analys och design med hjälp av CRC 83 Klassdiagram Objekt Ett objekt är en individuellt identifierbar entitet som kan vara konkret eller abstrakt. Ett objekt har tillstånd, beteende och identitet. Reellt,

Läs mer

Objektorientering Användning

Objektorientering Användning Objektorientering Användning Samt repetition av klasser Suzana Ramadani 1 Repetition Objektorientering bygger på Abstraktion Hierarkisk strukturering Inkapsling Klassificering Generalisering specialisering

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

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

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU TDDC30 Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU På denna föreläsning: Designmönster Adapter, Factory, Iterator,

Läs mer

Att bedöma. pedagogisk skicklighet

Att bedöma. pedagogisk skicklighet Att bedöma pedagogisk skicklighet Hur bedömer jag pedagogisk skicklighet? Vi blir allt fler som har anledning att ställa oss den frågan. Visad pedagogisk skicklighet är numera ett behörighetskrav vid anställning

Läs mer

TDDI02. Programmeringsprojekt, Föreläsning 2. Filip Strömbäck. Med utgångspunkt i tidigare slides av Jonas Lindgren

TDDI02. Programmeringsprojekt, Föreläsning 2. Filip Strömbäck. Med utgångspunkt i tidigare slides av Jonas Lindgren TDDI02 Programmeringsprojekt, Föreläsning 2 Filip Strömbäck Med utgångspunkt i tidigare slides av Jonas Lindgren På denna föreläsning: Dokument - kravspecifikation, projektplan Vad är klok design? Projektarbete

Läs mer

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

Undervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande: WEBBUTVECKLING Ämnet webbutveckling behandlar de tekniker som används för att presentera och bearbeta information i webbläsaren samt utifrån dessa tekniker skapa och vidareutveckla statiska och dynamiska

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

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu. Mina listor En Android-applikation Rickard Karlsson 2013-06-09 Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.se Innehållsförteckning 2. Innehållsförteckning 3. Abstrakt 4. Inledning/bakgrund

Läs mer

Arkitektur och metodbeskrivning. Nationell informationsstruktur

Arkitektur och metodbeskrivning. Nationell informationsstruktur Arkitektur och metodbeskrivning Nationell informationsstruktur Nationell informationsstruktur arkitektur och metodbeskrivning Nationell informationsstruktur (NI) ska bestå av sammanhängande modeller, vilket

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

Jag tror att alla lärare introducerar bråk

Jag tror att alla lärare introducerar bråk RONNY AHLSTRÖM Variabler och mönster Det är viktigt att eleverna får förståelse för grundläggande matematiska begrepp. Ett sätt att närma sig variabelbegreppet är via mönster som beskrivs med formler.

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

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar hur mjukvaror skapas, anpassas och utvecklas samt programmeringens roll i informationstekniska sammanhang som datorsimulering och praktisk datoriserad problemlösning.

Läs mer

Webbserverprogrammering

Webbserverprogrammering Webbserverprogrammering WES Webbserverprogrammering Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets

Läs mer

Datalogiskt tänkande är mer än Programmering. Fredrik Heintz Linköpings universitet

Datalogiskt tänkande är mer än Programmering. Fredrik Heintz Linköpings universitet Datalogiskt tänkande är mer än Programmering Fredrik Heintz Linköpings universitet Vad kommer jag säga idag? Datalogiskt tänkande är en uppsättning generella färdigheter och attityder som är viktiga för

Läs mer

TIPS FÖR ATT ÖKA 3DIN FÖRSÄLJNING

TIPS FÖR ATT ÖKA 3DIN FÖRSÄLJNING TIPS FÖR ATT ÖKA 3DIN FÖRSÄLJNING Alla kontakter bidrar till nya affärer Genom ett förändrat tankesätt kring försäljning, och genom att värdera sina kontakter som potentiella kunder över en längre tidshorisont,

Läs mer

Upprepade mönster (fortsättning från del 1)

Upprepade mönster (fortsättning från del 1) Modul: Algebra Del 2: Resonemangsförmåga Upprepade mönster (fortsättning från del 1) Anna-Lena Ekdahl och Robert Gunnarsson, Högskolan i Jönköping Ett viktigt syfte med att arbeta med upprepade mönster

Läs mer

WEBBSERVERPROGRAMMERING

WEBBSERVERPROGRAMMERING WEBBSERVERPROGRAMMERING Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets syfte Undervisningen i ämnet

Läs mer

IT OCH PROGRAMMERING I SKOLAN. Jan Erik Moström Peter Vinnervik

IT OCH PROGRAMMERING I SKOLAN. Jan Erik Moström Peter Vinnervik IT OCH PROGRAMMERING I SKOLAN Jan Erik Moström Peter Vinnervik VILKA ÄR VI OCH VAD KOMMER VI ATT PRATA OM? Jan Erik Moström - undervisar på institutionen för datavetenskap Peter Vinnervik - doktorand vid

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

Blue Ocean Strategy. Blue Oceans vs Red Oceans. Skapelse av Blue Oceans. Artikelförfattare: W. Chan Kim & Renée Mauborgne

Blue Ocean Strategy. Blue Oceans vs Red Oceans. Skapelse av Blue Oceans. Artikelförfattare: W. Chan Kim & Renée Mauborgne Blue Ocean Strategy Artikelförfattare: W. Chan Kim & Renée Mauborgne Artikeln belyser två olika marknadstillstånd som företag strävar efter att etablera sig inom. Dessa kallar författarna för Red Ocean

Läs mer

Företagsmodellering i UML

Företagsmodellering i UML Företagsmodellering i UML En kort-kort introduktion av Ambjörn Naeve http://kmr.nada.kth.se Modellering En modell är en förenklad beskrivning av ett komplext område En modell är motiverad av mål (= har

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

SKOLFS. beslutade den XXX 2017.

SKOLFS. beslutade den XXX 2017. 1 (11) Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:247) om ämnesplan för ämnet programmering i gymnasieskolan, inom kommunal vuxenutbildning på gymnasial nivå och inom vidareutbildning

Läs mer

Arkitektur Michael Åhs

Arkitektur Michael Åhs Arkitektur Michael Åhs Kalle & Hobbe: En utvecklares drömsystem 1. Vad är arkitektur? 2. Arkitektur i UML Innehåll 3. Utveckla en arkitektur 4. Arkitektur i projektet Del 1 - Vad är Arkitektur? Pattern-Oriented

Läs mer

SPECIALPEDAGOGIK. Ämnets syfte

SPECIALPEDAGOGIK. Ämnets syfte SPECIALPEDAGOGIK Ämnet specialpedagogik är tvärvetenskapligt och har utvecklats ur pedagogik med nära kopplingar till filosofi, psykologi, sociologi och medicin. I ämnet behandlas människors olika villkor

Läs mer

Riktlinjer för styrdokument

Riktlinjer för styrdokument Riktlinjer för styrdokument Fastställt av: Kommunfullmäktige Datum: 2014-12-15, 135 Diarienummer: 2014-000378 För revidering ansvarar: Kommunchef För eventuell uppföljning och tidplan ansvarar: Kommunchef

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

Programmering = modellering

Programmering = modellering Programmering = modellering Ett datorprogram är en modell av en verklig eller tänkt värld. Ofta är det komplexa system som skall modelleras I objektorienterad programmering består denna värld av ett antal

Läs mer

Utbildningsplan för. International Software Engineering, 180 högskolepoäng

Utbildningsplan för. International Software Engineering, 180 högskolepoäng Utbildningsplan för Dnr 56-1113/07 International Software Engineering, 180 högskolepoäng (International Software Engineering, 180 ECTS credit points) 1. Allmän information Software Engineering Software

Läs mer

Objektorienterad programmering

Objektorienterad programmering Objektorienterad programmering Emil Ahlqvist (c10eat@cs.umu.se) Didrik Püschel (dv11dpl@cs.umu.se) Johan Hammarström (c08jhm@cs.umu.se) Hannes Frimmel Moström (c10hml@cs.umu.se) 1 1. Introduktion 1.1 Objektorienterad

Läs mer

Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document

Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document Programutvecklingsprojekt 2003-04-24 Projektgrupp Elvin Detailed Design Document Björn Engdahl Fredrik Dahlström Mats Eriksson Staffan Friberg Thomas Glod Tom Eriksson engdahl@kth.se fd@kth.se d94-mae@nada.kth.se

Läs mer

MULTIPLATTFORMAR STÄLLER KRAV PÅ DIN STRATEGI OCH LEDNING

MULTIPLATTFORMAR STÄLLER KRAV PÅ DIN STRATEGI OCH LEDNING BiTA Service Management Gamla Brogatan 11 111 20 Stockholm MULTIPLATTFORMAR STÄLLER KRAV PÅ DIN STRATEGI OCH LEDNING Mats Voxlin, managementkonsult 8 november 2017 mats.voxlin@bita.eu +46 70-910 05 48

Läs mer

AffärsCoaching i privata och offentliga organisationer. En praktisk handledning.

AffärsCoaching i privata och offentliga organisationer. En praktisk handledning. Gunnela Westlander, bokanmälan Gunnar Kihlblom: AffärsCoaching i privata och offentliga organisationer. En praktisk handledning. Värmdö: Solid Affärs Coaching. ISBN 978-91-633-8657-2 Coaching är en metod

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

13 1MA302 Automatateori DV1 4 A D, M 1TD442 Algoritmer och datastrukturer DV1 6 A D

13 1MA302 Automatateori DV1 4 A D, M 1TD442 Algoritmer och datastrukturer DV1 6 A D 4.2 Årskurs 1 Studierna inleds med en frivillig introduktion till utbildningen omfattande två veckor. Därefter enligt nedanstående lista. Period Kurskod Kursnamn Poäng Nivå Ämne 11 1MA316 Introduktionskurs

Läs mer

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg Programmering Seminarier i datavetenskap, datorteknik och informationsteknik Niklas Broberg niklas.broberg@chalmers.se 2017-09-21 Hur många från Datavetenskap? Datateknik? Informationsteknik? Översikt

Läs mer

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur 2016:1 Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur arkitektur och metodbeskrivning Nationell informationsstruktur (NI) ska bestå av sammanhängande

Läs mer

Beslut Utbildningsplanen är fastställd av Nämnden för konstnärligt utvecklingsarbete (KUnämnden)

Beslut Utbildningsplanen är fastställd av Nämnden för konstnärligt utvecklingsarbete (KUnämnden) Utbildningsplan Kandidatprogrammet i Inredningsarkitektur och möbeldesign Beslut Utbildningsplanen är fastställd av Nämnden för konstnärligt utvecklingsarbete (KUnämnden) 2015-12-09 Gäller studenter antagna

Läs mer

Informationsteknologi och etik Introduktion. Kursen. Etikteorier och forskning. Filosofisk forskning: Psykologisk forskning:

Informationsteknologi och etik Introduktion. Kursen. Etikteorier och forskning. Filosofisk forskning: Psykologisk forskning: Informationsteknologi och etik Introduktion Iordanis Kavathatzopoulos Uppsala universitet Avd. för människa-datorinteraktion Kursen Registrering Föreläsningar, grupparbete, seminarier Litteratur: Bynum-Rogersson,

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

Det handlar om dig. Björn Täljsten vd, Sto Scandinavia AB

Det handlar om dig. Björn Täljsten vd, Sto Scandinavia AB Att jobba på Sto Det handlar om dig Björn Täljsten vd, Sto Scandinavia AB Som medarbetare på Sto är det i grunden dig och dina kollegor det handlar om. Utan att förringa vår fina produktportfölj, är det

Läs mer

Köpguide för mobila växlar. Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan.

Köpguide för mobila växlar. Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan. Köpguide för mobila växlar Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan. Tänk om din nya telefonilösning kunde förenkla din vardag och hjälpa dina medarbetare att arbeta

Läs mer

Datavetenskapliga programmet, 180 hp

Datavetenskapliga programmet, 180 hp HÖGSKOLAN I GÄVLE UTBILDNINGSPLAN GRUNDNIVÅ DATAVETENSKAPLIGA PROGRAMMET Programkod: TGDAK Inriktningskod IT-arkitekt: ITAR Inriktningskod visiomatik: VISI Fastställd av NT-nämnden 2006-09-21 Reviderad

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

Sammanfattning av Workshop om validering 15 november

Sammanfattning av Workshop om validering 15 november 2011-11-22 2011 Sammanfattning av Workshop om validering 15 november Susanna Carling Palmér Fastighetsbranschens Utbildningsnämnd 2011-11-21 1 Sammanfattning av konferens om validering den 15 november

Läs mer

Rapport av genomförd "Lesson study" av en lektion med temat ekvationer i gymnasiets B-kurs. Bultar, muttrar och brickor

Rapport av genomförd Lesson study av en lektion med temat ekvationer i gymnasiets B-kurs. Bultar, muttrar och brickor Rapport av genomförd "Lesson study" av en lektion med temat ekvationer i gymnasiets B-kurs Bultar, muttrar och brickor Vågad problemlösning Förberedelser Ekvationssystem i matematik B ger progression från

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

Ämnesblock matematik 112,5 hp

Ämnesblock matematik 112,5 hp 2011-12-15 Ämnesblock matematik 112,5 hp för undervisning i grundskolans år 7-9 Ämnesblocket omfattar ämnesstudier inklusive ämnesdidaktik om 90 hp, utbildningsvetenskaplig kärna 7,5 hp och VFU 15 hp.

Läs mer

Pedagogisk planering till klassuppgifterna Teknikåttan 2019

Pedagogisk planering till klassuppgifterna Teknikåttan 2019 Pedagogisk planering till klassuppgifterna åttan 2019 åttans intentioner med årets klassuppgifter är att den ska vara väl förankrad i Lgr 11. Genom att arbeta med klassuppgifterna tror vi att eleverna

Läs mer

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

Undervisningen i ämnet mobila applikationer ska ge eleverna förutsättningar att utveckla följande: MOI Ämnet mobila applikationer behandlar olika tekniker för att utveckla programvara riktad mot mobila enheter samt processen från idé till färdigt program. Ämnet mobila applikationer får bara anordnas

Läs mer

EV3 Design Engineering Projects Koppling till Lgr11

EV3 Design Engineering Projects Koppling till Lgr11 EV3 Design Engineering Projects 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

Läs mer

TEKNIK. Ämnets syfte. Undervisningen i ämnet teknik ska ge eleverna förutsättningar att utveckla följande:

TEKNIK. Ämnets syfte. Undervisningen i ämnet teknik ska ge eleverna förutsättningar att utveckla följande: TEKNIK Ämnet teknik är till sin karaktär tvärvetenskapligt. Teknik handlar om att uppfylla människors behov och önskemål genom att omvandla naturens fysiska resurser eller immateriella tillgångar i produkter,

Läs mer

Att välja sin framtid entreprenörskap

Att välja sin framtid entreprenörskap Ämne: Teknik Strävansmål - utvecklar kunskaper om rättigheter och skyldigheter i ett demokratiskt samhälle, - utvecklar sin förmåga att argumentera och uttrycka ståndpunkter samt en tilltro till den egna

Läs mer

SA TER Vision Center. SAUTER Vision Center. håller dig uppdaterad.

SA TER Vision Center. SAUTER Vision Center. håller dig uppdaterad. SA TER Vision Center SAUTER Vision Center håller dig uppdaterad. Modern fastighetsautomation blir alltmer komplex men, tack vare SAUTER Vision Center, så är konsten att övervaka systemet ganska enkel.

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

Projecticon PKS. Microsoft Project och dokumenthantering

Projecticon PKS. Microsoft Project och dokumenthantering Projecticon PKS Microsoft Project och dokumenthantering "Kunskap och färdigheter inom trafik är nyckelbegrepp hos oss. Då krävs exakthet och en inarbetad metodik eftersom vi bland annat levererar kritiska

Läs mer

Regional utvecklingsstrategi för Västerbottens län Övergripande synpunkter avseende strategin

Regional utvecklingsstrategi för Västerbottens län Övergripande synpunkter avseende strategin 1(5) Datum Diarienummer Region Västerbotten 2013-09-13 Vårt dnr 1.6.2-2013-2621 Box 443 Ert dnr 12RV0136-16 Dokumenttyp 901 09 UMEÅ REMISSVAR Regional utvecklingsstrategi för Västerbottens län 2014-2020

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

UML 1(5) Introduktion till Unified Modeling Language. 1 Bakgrund och historik

UML 1(5) Introduktion till Unified Modeling Language. 1 Bakgrund och historik UML 1(5) Introduktion till Unified Modeling Language 1 Bakgrund och historik UML är ett objektorienterat modellspråk för att specificera och visualisera system. Det är framtaget i första hand för IT-orienterade

Läs mer

I arbetet hanterar eleven flera procedurer och löser uppgifter av standardkaraktär med säkerhet, både utan och med digitala verktyg.

I arbetet hanterar eleven flera procedurer och löser uppgifter av standardkaraktär med säkerhet, både utan och med digitala verktyg. Kunskapskrav Ma 2a Namn: Gy Betyg E D Betyg C B Betyg A 1. Begrepp Eleven kan översiktligt beskriva innebörden av centrala begrepp med hjälp av några representationer samt översiktligt beskriva sambanden

Läs mer

Föreläsning 5. Deduktion

Föreläsning 5. Deduktion Föreläsning 5 Deduktion Hur ett deduktivt system fungerar Komponenter - Vokabulär Ett deduktivt system använder ett visst slags språk som kan kallas för systemets vokabulär. I mindre formella fall är kanske

Läs mer

SAS Intelligence Architecture. Patrick Eckemo IT Arkitekt / PM Arkitektur EIP @ SAS Institute

SAS Intelligence Architecture. Patrick Eckemo IT Arkitekt / PM Arkitektur EIP @ SAS Institute SAS Intelligence Architecture Patrick Eckemo IT Arkitekt / PM Arkitektur EIP @ SAS Institute Agenda Inledning vad är arkitektur? Definition Vyer Nivåer av arkitektur Behovet av arkitektur SAS Intelligence

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

Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg

Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg Datavetenskap Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg Oppositionsrapport, C-nivå 2006:12 1 Sammanfattat omdöme av examensarbetet Examensarbetet är intressant eftersom

Läs mer

Arkitekturell förmåga. Så bygger du upp den!

Arkitekturell förmåga. Så bygger du upp den! Arkitekturell förmåga. Så bygger du upp den! Lottie Aderinne - In Change Consultant AB Kommer prata om: - Hur bygger man upp arkitekturell förmåga - Praktiska exempel när det gått bra och när det gått

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

Vilken utbildning väljer du? skräddarsydda kurser för dig som är controller eller ekonomichef

Vilken utbildning väljer du? skräddarsydda kurser för dig som är controller eller ekonomichef Aktuella kurser hösten 2013 Vilken utbildning väljer du? skräddarsydda kurser för dig som är controller eller ekonomichef Vi ordnar kompetensen Tillväxten kommer per automatik Controllerrollen har aldrig

Läs mer

Upprepade mönster kan talen bytas ut mot bokstäverna: A B C A B C eller mot formerna: Anna-Lena Ekdahl, Högskolan i Jönköping

Upprepade mönster kan talen bytas ut mot bokstäverna: A B C A B C eller mot formerna: Anna-Lena Ekdahl, Högskolan i Jönköping Algebra Del 1 Upprepade mönster Anna-Lena Ekdahl, Högskolan i Jönköping Det är välkänt att barn långt innan de börjat skolan utforskar och skapar mönster på olika sätt och med olika material. Ofta skapas

Läs mer

Storyline och matematik

Storyline och matematik Storyline och matematik Av Eva Marsh och Ylva Lundin I ett storylinearbete om energi fick eleverna i årskurs åtta vid många tillfällen diskutera och lösa matematiska problem som karaktärerna ställdes inför.

Läs mer

Urban Jansson En liten presentation av mitt pågående projekt Fast-Flyktigt

Urban Jansson En liten presentation av mitt pågående projekt Fast-Flyktigt Urban Jansson En liten presentation av mitt pågående projekt Fast-Flyktigt Bakgrund Denna bakgrundspresentation har till syfte att förtydliga vad som ligger till grund för min problemformulering. Begreppen

Läs mer

Mer OOP. Variation i typ. Medlen repetition. Generiska klasser. Gränssnitt - Interface. Mer om klasser Några exempel UML

Mer OOP. Variation i typ. Medlen repetition. Generiska klasser. Gränssnitt - Interface. Mer om klasser Några exempel UML Målet Mer OOP Mer om klasser Några exempel UML Modularitet Språkligt modulära enheter Få gränssnitt Små gränssnitt Tydliga gränssnitt Dold information Återanvändbarhet Variation i typer Variation i datastrukturer

Läs mer

Styrdokumentkompendium

Styrdokumentkompendium Styrdokumentkompendium Information och kommunikation 2 Sammanställt av Joni Stam Inledning Jag brukar säga till mina elever, halvt på skämt och halvt på allvar, att jag förhåller mig till kursens centrala

Läs mer

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten?

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? Introduktion till objektorientering Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? TDDD78, TDDE30, jonas.kvarnstrom@liu.se 729A85 jonas.kvarnstrom@liu.se

Läs mer

Strategi Program Plan Policy» Riktlinjer Regler. Borås Stads. Riktlinjer för styrdokument

Strategi Program Plan Policy» Riktlinjer Regler. Borås Stads. Riktlinjer för styrdokument Strategi Program Plan Policy» Riktlinjer Regler Borås Stads Riktlinjer för styrdokument Borås Stads styrdokument» Aktiverande strategi avgörande vägval för att nå målen för Borås program verksamheter och

Läs mer