2. HVA ER EN KOMPONENT?

Innholdsfortegnelse 1. INTRODUKSJON 3 2. HVA ER EN KOMPONENT? 3 2.1. Litt av historien 3 2.2. UML og komponenter 5 2.3. Noen definisjoner 5 REFERANSER 7

1. Introduksjon Komponenter og komponentbasert systemutvikling ser ut til å få større og større oppmerksomhet. Dette notatet skal gi en introduksjon til temaet. Begrepet komponent defineres og som vi skal se finnes det en rekke definisjoner. I systemutvikling vil vi bruke komponenter for å spare tid, øke kvaliteten og øke produktiviteten. 2. Hva er en komponent? 2.1. Litt av historien Innenfor systemutvikling har vi sett en rekke bølger når det gjelder metoder og teknikker. Fagets barndom bar preg av mangel på metoder. Senere fikk vi strukturerte metoder. Så skulle objektorientering gi løsningen på alle problemer. Og nå er det komponenter. Utfordringen har hele tiden vært å kunne utvikle programvaresystemer raskt og med en kvalitet som tilfredsstiller brukerne av systemet. Man har sett at innen andre bransjer er noe av nøkkelen til suksess at man bygger systemer ved hjelp av komponenter. Det er f.eks tilfellet innen utvikling av datamaskiner og andre elektroniske systemer. Likedan innenfor byggebransjen. De forskjellige produsenter leverer systemer satt sammen av standard komponenter. Komponentene er igjen fremstilt av virksomheter som har spesialisert seg på å lage en type eller familie av komponenter. Eksempler er CPU, disk, minne, skjerm. Disse komponentene er bygd opp av mindre komponenter. Systemleverandøren bruker disse komponentene på innovative måter når systemene bygges. Komponentene har standard grensesnitt og en komponent fra en leverandør kan byttes ut med en komponent fra en annen leverandør så lenge grensesnitt og funksjonalitet er den samme. Innenfor progrmvareindustrien har man vært på jakt etter tilsvarende løsninger. Visjonen er å kunne bygge programvaresystemer ved hjelp av komponenter. Komponentene skal kunne brukes om igjen i nye systemer og i nye sammenhenger. Hittil har man ikke helt lyktes med å finne den rette typen komponent som lett kan gjenbrukes og bygges videre på. Med strukturert analyse og design kom modulen basert på oppdeling etter funksjon. Den minste byggeklossen var funksjonen (prosedyren, subrutinen avhengig av hvilket programmmeringsspråk det dreier seg om).programvaresystemene fikk en hierarkisk struktur med moduler bestående av funksjoner som opererte på datastrukturer. Oppdelingen etter funksjon har ikke gitt den ønskede grad av gjenbruk. Funksjoner er ikke naturlige for gjenbruk med unntak av biblioteker (matematikk, grafikk) for spesielle formål. Den objektorienterte bølge slo inn for fullt på 80 tallet. Her var løsningen på gjenbruksproblemet.. Objekter avspeilet problemdomenet. Objekter innkapslet data. Objekter var enheter som ga tilgang på data gjennom definerte grensesnitt. Implementasjonsdetaljene var skjult. Kode kunne gjenbrukes ved arv. Programvareutviklerene skulle bli mer produktive ved at de skulle slippe å skrive om igjen kode. Samme objekter kunne brukes i nye applikasjoner. Om de ikke gjenbruktes som de var kunne de enkelt modifiseres gjennom mekanismer som enkel og multipel arv. Men nå har det vist seg at heller ikke objekter helt har klart å løse gjenbruksproblemet. Objektene er for finkornet til å kunne brukes i forskjellige sammenhenger. Man må ha større enheter. Det er her komponenten kommer inn. Lenger fremme i dette dokumentet skal vi se på noen definisjoner av begrepet komponent. Det vi kan slå fast er at komponenter er enheter for gjenbruk og som er større enn objekter. En måte å se det på er gjenbruk av tjenester. Tjenester tilbys gjennom et grensesnitt og flere objekter arbeider sammen for å kunne tilby tjenesten. Bak grensesnittet behøver det ikke nødvendigvis befinne seg objekter. Det vil si at objekter hverken er nødvendig eller tilstrekkelig for å kunne bygge systemer med komponenter. Men slike ting som innkapsling av data og tilgang gjennom

et grensesnitt er hentet fra objektorientering. Imidlertid kan det bak et grensesnitt befinne seg eksisterende systemer 1 utviklet i forskjellige teknologier. På samme måte som for objekter brukes begrepet komponent på forskjellig måte av forskjellige personer. For de som sympatiserer med Microsoft er komponent det samme som ActiveX. Komponenter er binære, dvs de er kjørbar kode. For personer fra objektorienterte miljøer er komponent et annet ord for objekt. Det har vært en gradvis utvikling. Objekter kom med språk som Simula og SmallTalk. Ada hadde klassemoduler og skille mellom grensesnitt og implementasjon. Men Ada hadde ikke arv. De første populære komponenter var Microsofts Visual Basic Extensions som senere fikk betegnelsen controls. Men utgangspunktet var ikke å lage komponenter. Etter hvert har forskjellige ting blitt omtalt som komponenter. Og vi har fått flere teknologier som støtter komponenter. Disse er CORBA, COM, Java Beans. CORBA var opprinnelig en objektorientert teknologi. Utgangspunktet var at objekter skrevet i forskjellige objektorienterte språk skulle kunne kommunisere i nettverk. Flere ting må til for å få dette til. Man har et felles språk for å definere grensesnitt (IDL Interface Definition Language). I tillegg trenger man et lager hvor beskrivelser av grenssnitt kan lagres, en mekanisme som gjør det mulig for et objekt å finne ut hvor et annet objekt befinner seg, en kommunikasjonsprotokoll for å håndtere meldingsutveksling og en del andre ting. Poenget er at en komponentomgivelse må gjøre det mulig å holde orden på hvor komponenter kan finnes. CORBA har i tillegg forskjellige tjenester Navnetjeneste Persistens Samtidighet Sikkerhet Transaksjoner Microsoft hadde et annet utgangspunkt. På den ene siden ønsket de å lage et system som tillot brukere av Office applikasjoner å kutte og lime elementer fra en applikasjon til en annen. Man fikk OLE. På den andre siden hadde man Visual Basic Controls (VBX). Det var en måte som utviklere kunne lage grafiske brukergrensesnitt ved å hente inn elementer fra et sett med ferdige slike elementer. Disse elementene kunne opprinnelig ikke brukes i applikasjoner skrevet i andre språk. Men det var antagelig den første standard som hadde komponenter for gjenbruk. I takt med utviklingen av operativsystemene til Microsoft utviklet også komponentene seg. OLE ble til OLE1 og OLE2. VBX ble til OCX. Disse ble sammenfattet under COM Component Object Model og senere DCOM med sikte på kommunikasjon mellom forskjellige plattformer. ActiveX er dagens begrep. COM definerer et komponentsystem for Windows operativsystemer. Det er to nøkkelelementer et COM grensesnitt og et system for å registrere og å sende meldinger mellom COM grensesnitt. COM grensesnitt er signaturer skrevet i Microsoft Interface Description Language (MIDL). Alle COM objekter er binære. COM var opprinnelig for Windows. NT er fremtiden. Med NT kommer DCOM. Kort kan man si at DCOM er COM pluss en ORB. Microsoft sin ORB er noe som ligner på RPC på toppen av TCP/IP. MTS er Microsoft Transaction Server. Det er en omgivelse som skal gjøre det mulig å kreere COM objekter som skal brukes i applikasjoner som håndterer transaksjoner. MTS + COM = komponenter for serversiden. Java Beans komponenter er med fremmarsjen av Java blitt en populær komponentmodell. I Java er det innebygget støtte for grensesnitt, arv mellom grensesnitt og implisitt registrering av grensesnitt. Enterprise Java Beans er Java Beans innkapslet som et CORBA objekt. 1 På engelsk kalt legacy systemer. Det er systemer som er utviklet med bruk av gammel teknologi. Det er investert mye i disse systemene og de har fremdeles stor nytte for en virksomhet. Derfor er det ønskelig å ta vare på disse systemene så lenge som mulig. Det kan man oppnå ved å kapsle dem inn i komponenter. På den måten kan de gradvis byttes ut ved at innmaten i disse komponentene kan endres og lages ved nyere teknologi.

2.2. UML og komponenter I UML er begrepet komponent knyttet til implementasjon. En komponent er en fysisk og utbyttbar del av et system. Den realiserer og er i samsvar med et sett grensesnitt. Det er to modeller som brukes til å beskrive hvordan et system er implementert. De to modellene er: Komponentmodellen som viser avhengighet mellom deler av koden. Deploymentmodellen som viser strukturen i kjøretids systemet. Dvs hvilke deler som kjører på hvilken prosessor og hvordan maskinvaren er konfigurert. Det er mange typer komponenter (i UML): Kildekode som kan være avhengig av mange andre komponenter ved kompileringstid. Binær objektkode som er avhengig av objektkode som må lenkes for å gi et kjørbart program. En eksekverbar applikasjon som kan være avhengig av andre eksekverbare programmer i kjøretid (f.eks klient og tjener). 2.3. Noen definisjoner Her kommer noen definisjoner som er funnet i litteraturen. Ikke alle definisjoner svarer til definisjonen i UML av hva en komponent er. Det man kan slå fast er at det er forskjellige oppfatninger om begrepet komponenter: En komponent er en ikke-triviell, nesten uavhengig og utbyttbar del av et system. Komponenten har en klart definert funksjon i en definert arkitektur. En komponent oppfyller og gir den fysiske realisering av et sett med grensesnitt. En programvarekomponent er en enhet som kan brukes i bygging av systemer. Den har spesifiserte, kontraktsfestete grensesnitt. En programvarekomponent er uavhengig og gjenstand for bruk av tredjepart innenfor visse typer av systemer. En kjøretids programvarekomponent er en pakke som kan bindes dynamisk til et eller flere programmer. Den håndteres som en enhet og aksesseres gjennom et dokumentert grensesnitt som kan oppdages i kjøretid. Eksempler er DLL er, ActiveX, JavaBeans. En forretningskomponent er implementasjonen i programvare av et selvstendig forretningskonsept eller forretningsprosess. Den inneholder det som er nødvendig for å være et gjenbrukbart element i et større forretningssystem. En komponent er det en markedsfører vil at det skal være. En ting som vi kan gjenbruke eller erstatte. Et distribuerbart stykke av implementasjonen av et system inkludert kode (kilde, binær eller eksekverbar), men også forskjellige typer dokumenter. En komponent er en eksekverbar enhet kode. Den er en fysisk svartboks innkapsling av relaterte tjenester. Dens tjenester kan bare nås gjennom et konsistent, publisert grensesnitt som inkluderer en interaksjonsstandard. En komponent må kunne kobles til andre komponenter (gjennom et kommunikasjons-grensesnitt) slik at de danner en større gruppe. En komponent er et gjenbrukbart objekt. En komponent er et objekt som spiller en standardisert rolle. En komponent er et programelement med den egenskap at det kan brukes av andre programelementer (klienter). Som vi ser er det menge definisjoner. Men vi kan trekke ut noen viktige ting: 1. Gjenbruk. En komponent skal kunne brukes i mange systemer. 2. Byggekloss. Skal kunne samspille med andre komponenter i nye systemer. 3. Definert grensesnitt. En komponent har et grensesnitt som representerer en kontraktsmessig forpliktelse til å oppfylle en definert funksjonalitet. 4. Forskjellige typer komponenter. Den største forskjellen er om komponenten er en eksekverbar enhet eller et annet såkalt artefakt 2 (kildekode, objektkode eller andre dokumnenter). 2 Engelsk artifact. I engelsk-norsk ordbok oversatt med kulturgjenstand eller artefakt. Ting laget av mennesker spesielt verktøy, våpen eller noe av arkeologisk interesse.

For meg ser det ut som den største interessen knytter seg til eksekverbare komponenter som kan hentes inn i kjøretid eller komponenter som kan hentes inn under lenking av programmet.

Referanser 1. Paul Allen & Stuart Frost, Component-Based Development for Enterprise Systems, Cambridge University Press, 1998, ISBN 0-521-64999-4. 2. Don Kiely, Are Components the Future of Software?, IEEE Computer, Feb. 1998. 3. Bertrand Meyer, On to Components, IEEE Computer, Jan. 1999. 4. David Krieger & Richard M.Adler, The Emergence of Distributed Component Platforms, IEEE Computer, Mars 1998.