TDT4240 · NTNU

Studieguide for TDT4240 Programvarearkitektur

Komplett pensumoversikt for programvarearkitektur ved NTNU — med forklaringer, sentrale begreper, eksamenstips og vanlige fallgruver. Eksamensoptimalisert basert på tidligere eksamener.

Introduksjon

Denne studieguiden dekker pensum i TDT4240 Programvarearkitektur ved NTNU. Faget bygger i hovedsak på Bass, Clements og Kazman sin bok Software Architecture in Practice (3. utgave) og Kruchtens 4+1 View Model of Software Architecture. Målet er at du skal kunne resonnere om, designe, dokumentere og evaluere programvarearkitektur med utgangspunkt i kvalitetsattributter framfor ren funksjonalitet.

Eksamen er en fire timers skriftlig prøve som følger et svært stabilt mønster: en del med korte teorispørsmål, en mønster-gjenkjenningsoppgave der du velger riktig arkitekturmønster for fem systembeskrivelser, en oppgave om edge-dominante systemer, en oppgave om skyarkitektur, en oppgave der du skriver kvalitetsattributt-scenarioer, og til slutt en stor designoppgave på 30 poeng (nesten halvparten av eksamen) der du designer en arkitektur for et beskrevet system med ASR-er, taktikker, mønstre, prosess-view, logisk view og begrunnelse.

Studieguiden er organisert tema for tema etter hvor tungt temaene faktisk veier på eksamen: dokumentasjon/views er klart tyngst (prosess- og logisk view alene er 22 av 30 poeng i designoppgaven), fulgt av arkitekturdesign og ASR, kvalitetsattributter, arkitekturstiler og sky- og edge-dominante arkitekturer (som til sammen utgjør en fast bolk på 9 poeng hvert år). Taktikker, designmønstre, arkitekturevaluering og vedlikeholdbarhet kommer først og fremst som korte teorispørsmål, men er nødvendige for å skrive et godt designsvar.

Arkitekturstiler

Eksamensrelevant

De sentrale arkitekturmønstrene (Layered, Broker, MVC, Pipe-and-Filter, Client-Server, Peer-to-Peer, Service-Oriented, Publish-Subscribe, Map-Reduce, Multi-tier) og hvilke kvalitetsattributter hvert mønster fremmer. Sentralt på eksamen i mønster-gjenkjenningsoppgaven.

Hva er et arkitekturmønster?

Et arkitekturmønster (architectural pattern/style) er en gjennomprøvd løsning på et tilbakevendende designproblem på systemnivå. Det beskriver et sett med elementtyper, hvordan de samhandler, og hvilke begrensninger (constraints) som gjelder. Et mønster fremmer noen kvalitetsattributter på bekostning av andre, og det er nettopp denne avveiningen du må kunne argumentere for.

De viktigste mønstrene

Layered (lagdelt): Programvaren deles i lag der hvert lag bare bruker tjenester fra laget under. Fremmer modifiserbarhet og portabilitet (man kan bytte ut et lag), men kan koste ytelse pga. gjennomgang av flere lag. Typisk for operativsystemer og systemer med tydelige abstraksjonsnivåer.
Broker: En mellomledd-komponent (broker) frikobler de som etterspør tjenester fra de som tilbyr dem. Klienter trenger ikke kjenne plassering eller detaljer (URL) til tjenesteyterne. Fremmer interoperabilitet og endringsisolasjon.
Model-View-Controller (MVC): Skiller data (model) fra presentasjon (view) og styringslogikk (controller). Gjør det enkelt å vise samme data i flere ulike visninger og på ulike enheter. Fremmer modifiserbarhet av brukergrensesnittet.
Pipe-and-Filter: Data strømmer gjennom en kjede av uavhengige filtre (transformasjoner) koblet med pipes. Filtre kan kombineres og gjenbrukes fritt. Egner seg når en input transformeres steg for steg.
Client-Server: Klienter ber om tjenester fra en sentral server. Sentraliserer data og ansvar; god for delte ressurser, men serveren kan bli flaskehals.
Peer-to-Peer (P2P): Noder samhandler direkte som likeverdige parter, der hver node kan være både klient og tjener. Egner seg når noder skal dele ressurser direkte uten en sentral server, f.eks. enheter som kommuniserer lokalt.
Service-Oriented (SOA): Funksjonalitet tilbys som uavhengige tjenester med veldefinerte, standardiserte grensesnitt (API-er) som andre applikasjoner kan kalle. Fremmer interoperabilitet og åpen datatilgang.
Publish-Subscribe: Komponenter publiserer hendelser og abonnerer på hendelser uten å kjenne hverandre. Sterk frikobling; egner seg ved hendelsesdrevet kommunikasjon.
Map-Reduce: Stort beregningsproblem deles i mange like, parallelle deloppgaver (map) hvis resultater senere slås sammen (reduce). Egner seg for effektiv parallell prosessering av store datamengder spredt over mange filer/noder.
Multi-tier (flerlags): Sentraliserte ressurser deles i fysiske/logiske lag, typisk presentasjonslag, applikasjonslag og datalag. Forveksles ofte med Layered, men multi-tier handler om fysisk distribusjon av kjørende deler (tiers), mens Layered handler om logisk organisering av kode i abstraksjonsnivåer.

Eksempel — velg riktig mønster:

For hver systembeskrivelse, velg ETT mønster og begrunn i én setning:

Et bildebehandlingssystem skal kunne kjede sammen flere uavhengige filtre (skarphet, kontrast, fargekorrigering) i valgfri rekkefølge. → Pipe-and-Filter: hvert filter transformerer input til output og kan kombineres fritt.
En sensoravlesning skal kunne vises samtidig som tallverdi, som søyle og som graf, og lett kunne få nye visninger. → Model-View-Controller: samme model kobles til flere views uten å endre dataene.
En nettbutikk skal kunne ta i mot betaling fra flere betalingsleverandører uten å kjenne den interne adressen til hver leverandør. → Broker: en mellomledd-komponent skjuler plassering og detaljer for tjenesteyterne.
Et system skal finne den raskeste maksverdien blant milliarder av måleverdier lagret i tusenvis av separate filer. → Map-Reduce: problemet deles i mange like parallelle delberegninger som slås sammen.

Nøkkelformler

•Layered: lag bruker kun laget under → fremmer modifiserbarhet/portabilitet
•Multi-tier ≠ Layered: tier = fysisk kjørende del, layer = logisk abstraksjonsnivå
•Pipe-and-Filter: input → filter → filter → output, kombinerbare transformasjoner
•MVC: samme model, flere views → fleksibelt UI
•Broker/SOA: frikobler tjeneste-etterspørrer fra tjeneste-yter via mellomledd/standard-API
•Map-Reduce: del opp → mange parallelle map → reduce/slå sammen

Vanlige feil

⚠️Forveksler Layered og Multi-tier — husk: tier handler om fysisk distribuerte kjørende deler (presentasjon/applikasjon/data), layer om logiske abstraksjonsnivåer i koden
⚠️Velger Client-Server der oppgaven krever direkte node-til-node-kommunikasjon uten sentral server (da er Peer-to-Peer riktig)
⚠️Glemmer å BEGRUNNE valget — i mønster-oppgaven gir begrunnelsen poeng, ikke bare riktig navn
⚠️Velger MVC for alt med brukergrensesnitt; bruk det kun når poenget er flere visninger av samme data

Eksamenstips

💡Mønster-oppgaven gir typisk 5 poeng (ett per beskrivelse). Skriv ALLTID både mønsternavn OG en konkret begrunnelse knyttet til nøkkelordene i beskrivelsen
💡Let etter signalord: 'kombinere filtre/transformere' → Pipe-and-Filter, 'samme data flere visninger' → MVC, 'skjule leverandør/mellomledd' → Broker, 'parallelle delberegninger' → Map-Reduce, 'tre deler: presentasjon/applikasjon/data' → Multi-tier, 'noder deler ressurser likeverdig' → Peer-to-Peer
💡I designoppgaven (Oppgave 6) kombineres ofte flere mønstre, f.eks. MVC + Layered — vis at du forstår hvorfor begge trengs

Laster...

Laster…