Software-arkitektur

Funktionslaget handler om den del af vores kode der gør systemet funktionelt for brugeren. Hvergang brugeren trykker på en knap eller på anden vis sætter en handling igang, så skal systemet gennemføre en række beregninger. Funktionslaget er således ikke noget brugeren skal se på, som præsentationslaget, men handler om den måde hvorpå systemet reagerer på brugerens input.

Funktionslaget udformes ofte i kodesprog som Java, C++, Javascript, Python etc.

Datalag

Datalaget handler opbevaring og håndtering af data. Data kan være mange forskellige ting, i sociale medier som Facebook og Snapchat er data både informationer om brugerne som navn, email og kodeord, men der kan også være tale om billeder, lyd og video.

Uanset hvilke typer af data der er tale om skal de opbevares på en systematisk måde således at de kan findes igen og præsenteres i den rigtige rækkefølge når brugeren skal bruge dem. Når du tjekker de nyeste beskeder i Messenger kalder du i virkeligheden på datalaget med en forespørgsel om at få de nyeste beskeder i kronologisk rækkefølge.

Et populært sprog til at håndtere data med er SQL (Structured Query Language - Struktureret Forespørgsels Sprog).

Helt konkret om de tre lag

Et IT-system består af en masse kode der fortæller en computer hvad den skal gøre. Koderne er inddelt i filer, og software arkitektur kan handle om tre ting:

Hvordan filerne sorteres.
Hvordan koderne i filerne sorteres.
Hvilket framework man bruger (man kan lave en klassisk hjemmeside eller web-app med html, javascript og SQL, man kan også bruge et Python framework der hedder Django, eller MEAN som er en blanding af MongoDB (database), Express.js, Angular.js og Node.js (alle tre er Javascript). Uanset ender alle web-frameworks med at bruge HTML og Javascript selvom det pakkes ind på forskellig vis).

På informatik B-niveau handler det som udgangspunkt kun om hvordan filerne sorteres.

Den arkitektur man skal kunne huske til eksamen er tre-lags-arkitektur som beskrevet ovenfor og herunder.

Filer og koder

Som det ses på diagrammet er hvert "lag" i et IT-system det samme som nogle filer der indeholder de samme typer af koder og som er forbundet til hinanden.

HTML og CSS er de sprog som de fleste hjemmesider skrives i. Sprogene fortæller din browser hvordan hjemmesiden skal se ud, hvilke knapper og farver og lignende der skal være. En hjemmeside skrevet udelukkende i HTML og CSS kan dog ikke særlig meget.

Javascript er et sprog man kan bruge til at lave mere avancerede funktioner på sin hjemmeside. F.eks. hvis det skal være muligt at tilføje en varer til sin kurv på en shopping-side er det nødvendigt med mere avancerede funktioner end hvad HTML og CSS er lavet til at håndtere.

SQL er et sprog der kan anvendes til at håndtere data. F.eks. data om varer eller brugerinformationer.

Filerne i et IT-system er forbundet til hinanden ved at der i koden i de enkelte filer står referencer til koder i de andre filer.

Skal der vises en vare frem på en hjemmeside kan det være at en af funktionerne i en Javascript-fil har til formål at få en SQL-funktion til at hente varen frem, for derefter at få den givne vare integreret i hjemmesiden via HTML, så brugeren også kan se den.

Hvorfor er der forskellige sprog? Se siden om programmering

Mange typer software-arkitektur

Tre-lags-arkitektur er fint til en eksamen på B-niveau, men det er en meget overordnet arkitektur som lidt siger sig selv. Selvfølgelig har et IT-system brug for at folk kan se på det (grafik), anvende det (funktionalitet) og at det kan huske deres aktivitet så de ikke skal starte forfra hver gang (data).

Når folk udvikler IT-systemer i dag taler de ofte om forskellige frameworks man kan bruge (nævnt længere oppe), men med hensyn til sortering af koder og filer, så er der ligeså stor forskel som på bygnings-arkitektur (ioniske, doriske og korinthiske søjler). På samme måde opstår navnene på forskellige typer arkitektur også først efter, nogen har lavet noget.

Med andre ord laver webdesignere og IT-ingeniører alle mulige systemer, og så er det først bagefter at nogen kommer og opdager at nogle af systemerne ligner hinanden og derefter finder på et navn for den arkitektur som de mener at de systemer har til fælles.

Én måde som de fleste arbejder på i dag er "modul-baseret", hvilket vil sige at de inddeler deres systemer i klumper af kode, som vi kalder moduler. Ideen er at hvert modul er selvstændigt nok til at det færdige system kan køre både med og uden. F.eks. vil jeg antage at et system som lectio indeholder følgende moduler:

Skema-modul
Besked-modul
Dokument-modul
Bruger-modul
etc.

Det vil sige at man sikkert kan køre en version af lectio, hvor brugere i form af elever og lærere kan se skemaet, men de kan ikke sende beskeder og dele dokumenter for de moduler er blevet taget fra.

Skal man bruge tre-lags-arkitekturen til at forklare moduler vil det se noget anderledes ud (se grafik).

Som det ses af grafikken kan vi stadig godt tale om tre-lags-arkitektur, men det er bare ikke hele historien (medmindre man skal til eksamen i informatik B).

I de fleste systemer i dag, vil man typisk have en central database, som alle modulerne kan trække på, derfor er ovenstående grafik misvisende, men den er korrekt for Lectio. Som bruger af lectio er det nemlig ret tydeligt at de forskellige moduler ikke taler godt sammen og at man som bruger ofte kommer til at uploade de samme ting igen og igen fordi det at lægge en fil op på skemaet, ikke er det samme som at lægge den ind i dokumenter. Jeg kan slet ikke forestille mig deres udgifter til database. En udgift de kunne ændre ved enten at centralisere deres data (grafikken herunder), eller at forklare undervisere hvordan de kan bruge systemet mere effektive. For der er nu engang nogle enkelte, omend kryptiske måder at gøre det på i det eksisterende system.

Et bedre Lectio

Her er et eksempel på et bedre lectio.

For at opsummere, og som jeg håber at det fremgår af grafikkerne, så er der mange måder at lave software-arkitektur på.

Eksempel på software-arkitektur-diagrammer

Software-arkitektur-diagrammer

Et software-arkitektur-diagram har, i denne sammenhæng, til formål at vise hvilke dele af et IT-system der skal være tilgængelige online og hvilke der skal være tilgængelige offline.

Hvis man er i tvivl om hvordan man skal gå til det kan man bare stille sig selv følgende spørgsmål: "Hvis jeg ikke har internet på min mobil, hvilke dele af min app skal jeg så stadig kunne bruge?"

Hvis svaret er ingen, så skal du vælge den løsning der vises længst ude til højre i diagrammet, hvor både grafiklag, funktionslag og datalag ligger på server-siden. Det vil sige at din app grundlæggende set er en web-app eller bare en hjemmeside, som ganske enkelt ikke virker, hvis man ikke har internet (det er nok den fremtid vi går i møde).

Grunde til at det giver mening at tale om software-arkitektur

Det er interessant at vide hvor IT-systemets koder ligger henne fordi de jo fylder noget. Hvis hele IT-systemet ligger på klient-siden, så kan det være at folk ikke har plads på telefonen til at downloade den, for man har jo gerne i omegnen af tre tusinde billeder af babyer og kæledyr, og diverse grimme videoer af solopgange fra når man endnu en morgen slæber sig ind i sin dødkedelige hverdag og et kort øjeblik kigger drømmende op på himlen, men ikke kan acceptere at øjeblikket er levet og i stedet hiver sin telefon op foran øjnene for at forlænge oplevelsen i dårligere kvalitet.
En anden grund til at software-arkitektur er vigtigt at have overblik over er at apps kan forskellige ting. Der findes apps som er for tunge, har for mange komplekse kommandoer i sin kode, til at kunne blive kørt ordentligt på en telefon. Telefonen har for lidt computer-kraft (CPU, GPU, RAM). Derfor kan det være en fordel at have appen online, på en server med mere kraft.
Hertil er der også andre overvejelser. Eksempelvis kan man ikke have Facebook liggende på sin telefon. Det fylder for meget, der er for mange mennesker med for meget data som deler for mange dank-memes og tager for mange quizzer om hvem de er i Harry Potter-universet. Hertil skulle Facebook jo ligge på hver eneste brugers telefon og derfor ville det være et helvede, når én sendte en besked til en stor gruppe, at skulle opdatere alles versioner af Facebook, så alle kunne se beskeden. Det ville i øvrigt kræve en server.

Hvordan gør man?

Man kan sagtens tegne et software-arkitektur-diagram i hånden. Hvis man hellere vil lave det på computeren kan man bruge https://www.draw.io/ .

Page updated

Report abuse