Hvordan Bygge og Vedlikeholde et Effektivt Gjenbrukssystem for Programvarekomponenter

Asset Utilization, eller utnyttelse av tilgjengelige ressurser, er en prosess hvor tidligere utviklede eiendeler brukes til å konstruere nye programvareprodukter. Denne tilnærmingen er sentral for utviklingsteam som ønsker å bygge effektive og kostnadseffektive løsninger ved å gjenbruke eksisterende komponenter fra en bibliotekbase. Når Asset Utilization er implementert på riktig måte, kan det redusere utviklingstiden, minimere feil og gjøre prosessen mer økonomisk bærekraftig.

En viktig del av denne prosessen er Asset Acquisition, hvor ressurser eller komponenter som kan bli inkludert i et bibliotek, blir anskaffet. Dette er første trinn i å bygge opp et bibliotek som kan brukes til fremtidig utvikling. For at en ressurs skal bli akseptert i biblioteket, må den tilfredsstille nødvendige politiske, lovmessige og tekniske kriterier. Asset Acceptance sørger for at komponenten er i samsvar med relevante regler og er egnet for videre bruk i fremtidige prosjekter.

Biblioteket er ikke bare en samling av filer; det fungerer som en strukturert base som organiserer og kategoriserer ressurser på en måte som gjør dem lett tilgjengelige for utviklere. For at en komponent skal bli ansett som egnet for bruk, må den gjennomgå en streng sertifiseringsprosess. Dette innebærer at komponenten blir testet og bekreftet som pålitelig etter spesifikasjoner. Når en komponent er sertifisert, får den et "offisielt godkjenningsstempel", som innebærer at den kan benyttes i pågående prosjekter.

I en annen tilnærming kalles disse komponentene for "komponenter" fremfor programvare-relaterte dokumenter. I denne sammenhengen kan biblioteket motta forslag til komponenter fra kunder eller andre kilder, som deretter vurderes for inkludering. En detaljert fil blir opprettet for hver foreslått komponent, og informasjon som beskrivelse, tilgjengelighet og årsakene til at den ble foreslått, blir dokumentert. Denne vurderingen sørger for at komponentene som blir valgt for inkludering, er kostnadseffektive og har potensial for bred anvendelse.

For å kunne anskaffe komponenter til biblioteket er det ikke nødvendigvis et krav at biblioteket inneholder en fysisk kopi av hver komponent. Dersom en komponent ikke er fysisk tilgjengelig, kan den i stedet bli referert til i biblioteket. Dette kan gjelde for komponenter som vedlikeholdes og distribueres av eksterne organisasjoner, eller for eksekverbar kode. Når en komponent er referert til, bør biblioteket inneholde online instruksjoner for hvordan komponenten kan hentes, sammen med nødvendig dokumentasjon for bruken.

Et sentralt aspekt ved denne prosessen er kostnadseffektivitet. Den viktigste vurderingen for å akseptere en komponent i biblioteket er at kostnadene ved å skaffe og gjenbruke komponenten må være lavere enn kostnadene for å utvikle en tilsvarende løsning fra bunnen av. Kvaliteten på komponenten er også avgjørende, og det vurderes hvordan den ble utviklet, enten av et anerkjent utviklingsteam eller på annen måte. En komponent som ikke har en forståelig beskrivelse av sine funksjoner eller klare bruksanvisninger, kan ikke anses som gjenbrukbar.

Målet med Asset Utilization er å bruke de eksisterende komponentene til å bygge nye applikasjoner eller systemer. Dette innebærer å bestemme et sett med kriterier for å velge hvilke eiendeler som skal gjenbrukes, finne passende kandidater som oppfyller disse kriteriene, og deretter tilpasse dem til de spesifikke behovene i det nye prosjektet. Når komponentene er valgt, er det viktig å tilpasse dem slik at de møter kravene til det nye systemet.

Tilpasning kan skje på to måter: enten ved å bruke de eksisterende tilpasningsmulighetene som komponenten tilbyr, eller ved å gjøre endringer i komponenten for å møte nye krav som ikke var forutsett ved utviklingen. I tilfelle av forutsett tilpasning, kan komponenten bruke parametere eller andre grensesnitt for å tilpasses systemet. Dette gjør det mulig for utviklere å utnytte komponentene effektivt uten å måtte gjøre store endringer i koden. For uforutsette behov, kan det være nødvendig med manuell modifikasjon av komponentene, som kan inkludere tillegg av nye funksjoner eller fjerning av unødvendige elementer.

Re-use prosessen innebærer også økonomiske vurderinger. I starten vil kostnadene ved å bygge opp et bibliotek være høye, ettersom opprettelsen og vedlikeholdet av et bibliotek krever ressurser og opplæring. Men over tid vil investeringene begynne å betale seg gjennom redusert utviklingstid og lavere kostnader for å lage nye applikasjoner. Økonomiske gevinster kan være vanskelige å måle nøyaktig, spesielt når det gjelder de ikke-tangible fordelene som bedre programvarekvalitet og mindre testing. Selv om de økonomiske besparelsene kan være usikre i starten, vil det etter hvert oppstå en balanse hvor investeringen i gjenbruk kan gi merkbare gevinster i form av reduserte utviklingskostnader og høyere kvalitet på sluttproduktene.

For at et gjenbrukssystem skal være vellykket, er det essensielt at utviklerne ser på det som et verktøy som forenkler arbeidsprosessen og forbedrer resultatene. Når teamet har erfaring med å bruke et godt organisert bibliotek og opplever de faktiske fordelene med gjenbruk, vil motivasjonen for å investere i et slikt system øke. Det er viktig å ha klare bevis på gevinstene, selv om det kan være vanskelig å isolere effektene av gjenbruk fra andre faktorer som påvirker prosjektutviklingen.

Hvordan Objektorienterte Programmeringsspråk Har Revolusjonert Softwareutvikling og Gjenbruk

Alle objektorienterte programmeringsspråk som har dukket opp, for eksempel Smalltalk 80, sammen med objektorienterte utvidelser til eksisterende funksjonelle språk som Object Pascal, Objective C og C++, har endret måten vi tenker på softwareutvikling. Objektorienterte programmer består av samhandlende komponenter, kjent som objekter. Disse objektene kan representere virkelige entiteter, som bankkontoer, eller programvare- og maskinvarekomponenter. Andre kan være databasert, som lister, stakker og køer. Programvareutvikling med objektorienterte språk handler om å sette sammen disse objektene for å bygge et system.

En videreutvikling av objektorientert metodologi er rammene, eller frameworks. Begrepet "framework" har mange betydninger i ulike sammenhenger, men innenfor programvareutvikling refererer det til en gjenbrukbar, semikomplett applikasjon som kan spesialtilpasses for å lage tilpassede applikasjoner. I motsetning til tidligere teknikker for objektorientert gjenbruk, som var basert på klassebiblioteker, er rammeverkene rettet mot bestemte forretningsenheter eller applikasjonsdomener. Rammeverkene gjør det mulig å utvikle applikasjoner ved å utvide stabiliteten gjennom eksplisitte “hook metoder” som lar applikasjoner tilpasse rammeverkets stabile grensesnitt.

Mange utviklere i ulike domener har brukt rammeverk i flere år. Eksempler på dette inkluderer Microsoft Foundation Classes, som er blitt den de facto industristandarden for å lage grafiske applikasjoner på personlige datamaskiner. Java bringer med seg nye rammeverk som AWT og Beans. Rammeverkene fungerer som komponenter i den forstand at de selges som produkter, men de er mer tilpassbare enn de fleste komponenter og har mer komplekse grensesnitt. Dette gjør rammeverkene til mer effektive verktøy for gjenbruk i programvareutvikling, selv om de kan være mer utfordrende å lære enn individuelle komponenter.

Rammeverk gir en standardisert kontekst for komponenter, og sørger for at standardproblemer som feilbehandling, datadeling og operasjonsutveksling blir håndtert på en organisert måte. Komponentbaserte systemer som OLE, OpenDoc og Java Beans er i realiteten rammeverk som løser standardproblemer som oppstår ved bygging av sammensatte objekter og dokumenter. Rammeverkene gjør det mulig for eksisterende komponenter å gjenbrukes på en effektiv måte ved å tilby standardiserte grensesnitt for samhandling.

En interessant distinksjon i rammeverkene er mellom de såkalte "hvite" og "svarte" boksene for gjenbruk. Den svarte boksen representerer funksjonalitet som kan gjenbrukes med små justeringer, mens de hvite boksene, eller klassebibliotekene, kan spesialiseres ved å legge til subklasser etter behov. Denne dualiteten gjør rammeverk svært allsidige verktøy for utviklere som ønsker å bygge på eksisterende kode samtidig som de kan tilpasse systemene til spesifikke behov.

Mønstre og rammeverk er nært beslektede begreper. Begge er utvidelser av den objektorienterte tilnærmingen som integrerer domeneanalyse for å adressere spesifikke problemområder med delvise løsninger som er mer omfattende enn de tradisjonelle objektene eller klassene. Hver mønster beskriver et beslutningspunkt i utviklingen av en applikasjon, og grupper av relaterte mønstre kan organiseres i et tre eller et grafisk diagram som leder utvikleren gjennom en serie av beslutninger mot et komplett design. Et mønster-språk kan dermed guide utviklingsprosessen gjennom konkrete domene-spesifikke råd.

Bøker om mønstre eller rammeverk for spesifikke domener har blitt tilgjengelige, som for eksempel bøker som tar for seg forretningsmønstre. Et eksempel på dette er en bok som fokuserer på to typer mønstre: analysemønstre og støtte-mønstre. Analysemønstre representerer felles konstruksjoner i forretningsmodellering som er relevante for flere domener, mens støttemønstrene viser hvordan disse analysene kan anvendes. Rammeverkene som benyttes her er tilpasset de spesifikke behovene til virksomheten og gir en konkret metode for systemutvikling innenfor et gjenbrukbart mønster.

Som med alle komplekse teknologiske konsepter er organiseringen av programvarekomponenter avgjørende for effektiv utvikling og gjenbruk. For både dokumentorienterte og objektorienterte systemer er det viktig å forstå hvordan informasjonen er strukturert og hvordan komponentene samhandler med hverandre. Spesielt når man jobber med store databaser eller systemer med flere brukere, er det avgjørende at de valgte metodene for komponentorganisering og gjenbruk er konsistente og tilpasset det spesifikke domene.