programmera.net -> architecture -> normal     för utskrift      info@programmera.net

Komponentbaserad arkitektur

1. Divide and Conquer
2. Vad är en komponent?
3. Inkapsling och flexibilitet
4. Väl utformade komponenter
5. Komponentdiagram i UML

1. Divide and Conquer

Inom programmering hör man ofta devisen "Divide and Conquer":

  • Divide and Conquer: Det lättaste sättet att lösa ett komplext problem är att dela upp problemet i flera delproblem som var och en inte är lika komplexa.
De flesta programmerare vill utnyttja "Divide and Conquer" på kodmassan i ett program så att varje del löser var sitt delproblem. Detta är lättare sagt än gjort! Den svåraste frågan kvartstår: "Hur ska man dela?". På denna sida tittar vi på begreppet komponent, som är det vanligaste sättet att dela programmeringskod.

2. Vad är en komponent?

Jag har hittat några böcker där man definierar termen "komponent" och definitionen har varit samma på de flesta ställen. Jag hänvisar till boken "Systemutveckling på 2000-talet" av Lars Wiktorin.

  • Lars Wiktorin gör skillnad på begreppet "Modul" och "Komponent", där han påstår att en "Komponent" består av flera "Moduler". Jag vet inte om denna skillnad har någon fast förankring i programmeringslingon ute i stugorna, så jag betraktar därför dessa två termer som synonymer.
Definition: En komponent (eller modul) är ett stycke kod som har följande egenskaper:
  1. Sammanhängande inuti: Komponenten bör hantera ett avgränsat funktionsområde så att det blir tydligt för den som använder komponenten vilken funktionalitet som inkluderas i komponenten. Funktionerna inom komponenten bör vara så logiskt sammanhängande som möjligt.
  2. Oberoende av omgivningen: Komponenten bör vara så logiskt avgränsad och oberoende av övrig kod i programmet som möjligt. För att få detta oberoende vill vi att komponenten ska anropa så få andra komponenter som möjligt.
  3. Inkapsling: Komponenten bör dölja interna variabler och funktioner från omvärlden i så hög utsträckning som möjligt. Detta sker genom att alla anrop från andra komponenter måste gå via ett tydligt definierat gränssnitt. En komponent kanske har interna variabler som endast används för att utföra vissa beräkningar, dessa bör inte vara synliga utanför komponenten.

3. Inkapsling och flexibilitet

Om komponentens inre funktionalitet är "synlig" utanför komponenten kanske programmerare gör anrop direkt mot de interna funktionerna, och då är komponenten inte längre utbytbar. Anledningen till att man strävar efter inkapsling (alltså att man vill dölja den inre implementationen) är att det ska gå att byta ut komponenten mot en annan komponent med samma gränssnitt utan att den anropande koden slutar fungera.

  • Inkapsling ökar alltså systemets flexibilitet.

4. Väl utformade komponenter

En komponent kan vara mer eller mindre väl utformad, beroende på hur väl den uppfyller de krav som beskrivs ovan. Ofta har man problem med att en komponent är alltför starkt beroende av andra komponenter, då kanske det är dags att designa om. Ofta formar man komponenter efter termer som i språket representerar någon form av enhet, t.ex. "Kund" eller "Produkt", detta känner vi väl igen från objektorientering och jag kommer inte gå in på detta. Man brukar prata om att en komponent (eller modul) i ett objektorienterat programmeringsspråk motsvaras av en "klass", men i verkligheten är den definition som givits ovan mer generell än så, det finns komponenter på många nivåer i ett objektorienterat programmeringsspråk.

5. Komponentdiagram i UML

I UML har termen komponent ("Component") en speciell betydelse:

  • Komponent (i UML): En komponent är en "installerbar mjukvaruenhet", alltså en självständig del av mjukvara som har en fysisk motsvarighet och kan flyttas till och installeras på en maskin. Många andra enheter i UML har en motsvarighet i ett logiskt plan, men komponten är inget logiskt objekt utan ett fysiskt. Det kan vara ett exekverbart program, en applikation eller en DLL. Det kan också röra sig om källkod, eftersom man i vissa programspråk kan köra källkod direkt utan att kompilera den.
Komponenter används i Komponentdiagram ("Component diagram") men kanske främst i Sjösättningsdiagram ("Deployment diagram"). Ett sjösättningsdiagram visar hur komponenterna ska installeras på de olika maskinerna i en driftmiljö. Varje maskin (kallas "Nod") ritas som en fyrkant. Kompoenten ritas som en fyrkant med två mindre fyrkanter till vänster.