Arkitektur

From CCT - Vidensdeling
Revision as of 15:39, 20 June 2017 by Mr.mathiasen (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Læreplanen om kernestoffet knyttet til It-systemers arkitektur:

    • (STX, C-niveau) tre-lagsarkitektur (eller tilsvarende) som generel ramme for at forstå en meget stor klasse af it-systemer, deres komponenter og samspillet mellem disse.
    • (STX, B-niveau) ”cloud-computing”, ”client-server”-arkitektur og model-view-controller; konkrete systemer baseret på disse arkitekturer.




Arkitektur handler om strukturen af it-systemer, og der findes mange forskellige varianter og forståelser af arkitekturbegrebet: man kan tale om applikations-arkitektur, som er strukturen af individuelle systemer, om informations-arkitektur, der handler om strukturen af data (repræsentationer), om system-arkitektur, der handler om strukturen ml. en familie af sammenhængende systemer, osv. Fælles for dem alle er, at når man anvender et arkitektursyn på it, så fokuserer man på strukturen og interaktionen mellem delene (og ikke på selve komponenterne, modulerne, programmerne). Grunden til at dette er vigtigt, er at man erfaringsmæssigt har erkendt, at når et system bliver sat i drift, så kommer der uværgeligt rettelser og tilføjelser til systemerne. Hvis systemet har en uhensigtsmæssigt struktur, så bliver det ofte vanskeligt at vedligeholde disse systemer. Nogle gange så vanskeligt, at man må skrotte et system, og lave et helt nyt, hvilket er dyrt. Omvendt, hvis systemet har en god arkitektur - typisk beskrevet som løs kobling mellem delene - så er det nemmere at vedligeholde systemet.

Naturligvis har UML et omfattende beskrivelsesapparat til at modellere arkitektur - faktisk fra en hel række (typisk 4 eller 5) forskellige synsvinkler (ofte kaldet views). I denne note vil vi dog gå lidt mere praktisk og pædagogisk til værks, idet vi vil beskæftige os med en helt generel model for arkitektur, som kan være vældig nyttig, når man skal forstå, bruge, ændre, eller skabe systemer. Modellen er således ikke specifik for et bestemt konkret system, men er generel anvendelig som mental model (forståelse) af alle systemer. Modellen opdeler et system i 3 dele: grænseflade, funktionalitet, repræsentation (Repræsentationen kaldes ofte for “modellen”, idet den er en model af systemets problemområde, men det forvirrer begreberne i forhold til det, vi indtil videre har sagt om modeller og modellering.), i det følgende benævnt G, F, og R.

  • Grænsefladen er den del af systemet (af koden), som brugeren (eller andre eksterne systemer) kommunikerer med. Tænk på knapper, vinduer, scroll-barer, indtastningsfelter - alt det som du kan navigere rundt i med mus og tastatur på en pc eller med fingrene på en smartphone.
  • Repræsentationen er den del af systemet (koden), som indeholder repræsentationerne af det som systemet handler om - dataene. Hvis det er en musik-app vi kigger på, så drejer det sig om selve musiknumrene, som de er gemt i systemet, og hvad der ellers er gemt af yderligere information i forbindelse med disse musiknumre: coverbillede, titel, albumtitel, kunstner, længde, kvalitet, genre, antal afspilninger, osv.
  • Funktionaliteten er den del af systemet (koden), som typisk indeholder algoritmerne for det som vi ønsker at gøre ved vores data. Hvis det f.eks. er et program til at lave ringetoner med, vi kigger på, så er der typisk funktioner til at udvælge, redigere og gemme lyden: vælge en del ud, ændre lydstyrken, lave ekko, ændre pitch, sætte delen ind på et andet tidspunkt i nummeret, lave loops, osv.

Øvelse: Hvorfor tror du disse 3 aspekter typisk er adskilt fra hinanden i et system?

Ovenfor har vi ikke taget stilling til, hvor systemdelen (koden) rent fysisk befinder sig: om det hele er placeret på samme computer eller fordelt på flere forskellige maskiner. Der er nemlig flere muligheder. Betragt figuren nedenfor.

To arkitekturmønstre: GFR og Klient-Server.

Figuren viser to klassiske mønstre i arkitektur. Til venstre har vi ideen om lagdeling, hvor vi har opdelt et system i grænseflade, funktionalitet, og repræsentation, som forklaret tidligere. Til højre har vi ideen om klienter og servere: pointen i dette mønster er, at en række forskellige brugere af systemet kan benytte hver deres klient til at forbinde sig til og kommunikere med en fælles server. Dels betyder det, at flere brugere kan bruge deres klienter samtidigt (uden at skulle slås om tastatur og skærm), dels betyder det, at brugerne og klienterne kan være geografisk distribuerede. Forskellige kombinationer af disse to simple mønstre giver en god forståelse for mange af de systemer, vi bruger i det daglige. Betragt figuren nedenfor. De grønne kasser er klienter, de blå er servere, og de røde er vores forskellige logiske systemdele (G, F, R).

4 forskellige applikationsarkitekturer.
  • I a-varianten har vi alle tre systemdele kørende på samme computer. Et eksempel er applikationerne fra officepakken, hvor vi kan bruge henholdsvis Word, Powerpoint, og Excel isoleret på vores egen maskine uden at være på nettet.
  • I b-varianten har vi vores grænsefladekomponent placeret på en klient, hvorimod funktionaliteten og repræsentationen er placerede på en server. Dette er typisk for mange web-baserede systemer, at vi har vores browser kørende på vores egen computer, men at vi så kan koble op på en webside, der tilbyder noget funktionalitet og noget data vi kan arbejde på. F.eks. Facebook.
  • I c-varianten har vi både grænsefladen og funktionaliteten placeret på vores egen klient. Hvis du har prøvet at arbejde med et “fællesdrev”, som bruges til at dele dokumenter og filer på en skole eller en arbejdsplads, så kender du også denne variant. Dette gælder f.eks. hvis du bruger Word til at rette i et dokument som ligger på et fællesdrev. Eller hvis du har adgang til en database, som du kan bruge eller opdatere. Hvis du har prøvet dette, så kender du også fornemmelsen, når netværksforbindelsen mistes - enten pga. en fejl, eller fordi du sidder i sommerhuset uden internet og skulle have lagt sidste hånd på en opgave, der skulle afleveres i morgen.
  • Endelig er der d-varianten, som skal forstås på den måde, at repræsentationen (vores data) er fordelt på både klient og server. Dette kender du sikkert fra de mange såkaldte cloud-baserede services, som er dukket op de senere år: Google Drive, Microsoft Skydrive, Apple’s iCloud, eller DropBox. Her er idéen, at man kan arbejde videre på sine data, selv om man ikke har netforbindelse. Klient- computeren (f.eks. din bærbare) opretholder nemlig en lokal kopi af dine data fra serveren, som du altid kan arbejde på. Når computeren så igen får netforbindelse, så opdaterer den automatisk både din lokale kopi (hvis der er ændringer på serveren, f.eks. fra andre brugere af DropBox, som har uploadet nye filer til jeres delte dropbox) og serveren (hvis du har ændret i eller oprettet nye dokumenter i din lokale kopi af jeres dropbox). Dropbox synkroniserer således klienter og serveren.

Øvelse:

  • Vælg en håndfuld applikationseksempler, som du kender fra pc/mac, ipads, og smartphones.
  • Overvej for hver enkelt applikation, hvilken af varianterne a-d du tror, der bliver anvendt.
  • For hver variant a-d, overvej fordele og ulemper ved denne arkitektur.
  • Overvej om der er flere varianter end de nævnte a-d.