Utforming for gjenbruk In 140 Sommerville kap 14

Mål  Gjenbruk i utformingsprosessen  Fordeler og problemer med gjenbruk  Forstå forskjellige komponenter som kan gjenbrukes og utforming for gjenbruk  Kjenne til applikasjonsfamilier og hvordan de gir effektiv gjenbruk  Forstå at mønstre er høynivåabstraksjoner som fremmer gjenbruk av utforming i OO- utvikling

Introduksjon  Ferdige komponenter brukes mye i andre ingeniørdisipliner  Bør også brukes ved utvikling av programvaresystemer –Gjenbruk gjør det mulig å få mer ut av utviklingsarbeidet. –Krav om lavere utviklings og vedlikeholdskostnader, raskere levering og høyere kvalitet kan bare tilfredsstilles ved utstrakt gjenbruk  Må tas med i kravspesifikasjons- eller utformingsfasen –Opportunistisk gjenbruk –Systematisk gjenbruk

Introduksjon  Gjenbruksbasert systemutvikling satser på mest mulig bruk av ferdige komponenter  Varierende komponentstørrelse 1.Applikasjonssystem kan gjenbrukes ved inkorporering, utvikling av familier av applikasjoner for ulike plattformer eller spesialisering 2.Komponentgjenbruk. Fra undersystemer til enkeltobjekter. Eks: Mønstergjenkjenning. 3.Funksjonsgjenbruk. Gjenbruk av enkeltfunksjoner. Funksjonsbibliotek. – 1. og 3. har lange tradisjoner – Komponentgjenbruk 1980 teori, 2000 Praksis

Introduksjon  Fordeler ved gjenbruk: –Øket pålitelighet –Redusert risiko under utvikling (spesielt ved gjenbruk av undersystemer) –Bedre utnyttelse av spesialister –Standardisering –Akselerert utvikling

Introduksjon  Tre kritiske krav til utforming og utvikling med gjenbruk –Gjenbrukbare komponenter må være tilgjengelige (katalogisering og dokumentasjon) –Man må ha tillit til komponentenes kvalitet. –Komponentene må ha dokumentasjon.  Komponenter har bevist sin verdi i: –VB, VC++, JavaBeans, Delphi  Komponentbasert SE er i ferd med å bli akseptert

Introduksjon  Problemer med gjenbruk –Økte vedlikeholdskostnader (Hvis komponentkildekode mangler) –Svak verktøystøtte – CASE –Not-invented-here syndromet –Krever vedlikehold av komponentbibliotek –Finne og tilpasse gjenbrukbare komponenter  Systematisk gjenbruk kommer ikke av seg selv.  Må organiseres (Jap: Software Factory, Hewlett Packard)

Introduksjon  Generatorbasert –Generatoren fylles med gjenbrukbar kunnskap –Genererer system fra abstrakt systembeskrivelse som angir komponenter og hvordan de skal kobles sammen –Kan bare brukes der anvendelsesabstraksjoner og tilsvarende eksekverende kode kan identifiseres. 4.GL brukes deretter i spesifikasjonen. –Har vært anvendt med hell i: •Applikasjonsgeneratorer for administrativ databehandling •Parsergenerator for språkprosessering •Kodegeneratorer i CASE-verktøy •Kontroll og styringssystemer –Gir sluttbrukere muligheter for å programmer

Gjenbruk gjennom programgenerering

Komponentbasert utvikling  I bruk fra slutten av 90-åra  Frustrasjon over OO  Komponenter –Mer abstrakte enn objekter –Frittstående tjenesteleverandører –Eksempel: Kvadratrotkalkulator, regneark –Komponenter er uavhengig eksekverbare –Komponenter publiserer sine grensesnitt. All interaksjon gjennom de publiserte grensesnittene –To uavhengige grensesnitt: yter og krever. (provides og requires)

Component interfaces

Printing services component

Komponentnivåer  Funksjonell abstraksjon –Enkeltfunksjon  Tilfeldig gruppering  Dataabstraksjoner –Objektorientert klasse med metoder for skapelse, tilgang og endring.  Klyngeabstraksjoner (Rammeverk) –Samarbeidende klasser.  Systemabstraksjoner (COTS, API)

Opportunistisk gjenbruksprosess

Systematisk gjenbruksprosess

Komponentbasert gjenbruksprosess  Kan integreres i standardprosessen ved å ta med gjenbruksaktivitet i prosessen  I gjenbruksbasert utvikling tilpasses kravspesifikasjonen tilgjengelige komponenter  KBGP bruker gjerne prototyping eller inkrementell utvikling der komponenter limes sammen med Java eller et scriptspråk –Unix shell, VB, TCL/TK

Problemer med komponentbasert gjenbruksprosess  Dårlig tilpasning mellom komponenter reduserer innsparingspotensialet.  Finne og forstå komponenter  Uten kildekode blir det vanskelig å tilpasse komponentene til endrede krav –vedlikeholdskostnader

Application Framework (Rammeverk)  Frustrasjon over OO – For små biter  Bedre støtte for OO-gjenbruk gjennom rammeverk – storskalaabstraksjoner  Rammeverk er en undersystemutforming bygd opp av abstrakte og konkrete klasser  Rammeverket brukes gjennom å bruke komponenter og lage konkrete implementasjoner av de abstrakte klassene.

Rammeverksklasser  Systeminfrastruktur-rammeverk –Støtter utvikling av infrastruktur som kommunikasjon, UI og kompilatorer  Middleware integrasjonsrammeverk –Støtter komponentkommunikasjon og informasjonsutveksling: CORBA, COM, DCOM, Java Beans  Rammeverk for Selskapsapplikasjoner. –Se senere.

Rammeverk  Et rammeverk er en struktur som kan utvides for å lage et anvendbart system. –Konkrete klasser –Call-backs.  Gjenbruk blir enklere ved bruk av rammeverk  Største problem er kompleksitet og dermed læringsterskel – Derfor er det dyrt å innføre rammeverk.

Modell-view kontroller (MVC)  Systeminfrastrukturrammeverk for GUI  Tillater flere presentasjoner av et objekt og separate interaksjoner med disse presentasjonene  MVC rammeverk innebærer instansiering av mange klasser. (se senere)

Model-view controller

COTS-produktgjenbruk  Databasehåndteringssystemer  Tilgang fra program til systemfunksjoner gjennom API  Bør alltid vurderes fordi det reduserer tid, kostnad og risiko

Problemer med COTS  Mangler kontroll over funksjonalitet og ytelse  Problemer med interoperabiliteten. –Hvem eier hendelsene?  Mangler kontroll over systemevolusjon  Støtte fra COTS-leverandøren (svært nødvendig)  Disse problemene gjør at –ventet besparelse blir sterkt redusert –vedlikeholdskostnadene kan bli store  Allikevel mest fordeler

Komponentutvikling for gjenbruk  Ideelt bygd på erfaring om hvor fleksibel komponenten må være  Hva kreves for at komponenten skal være gjenbrukbar: –Stabil anvendelsesabstraksjon –Innkapsling. All tilstandsendring og avlesning gjennom metoder. –Så uavhengig som mulig –Unntak skal sendes ut av komponenten  Hva må til for å gjøre om eksisterende kode til gjenbrukbare komponenter? –Pakking og provides og requires grensesnitt  Kompromiss mellom brukbarhet og gjenbrukbarhet – mellom forståelig og generell.

Gjenbrukbare komponenter  Det er dyrere å utvikle gjenbrukbare komponenter – bør være organisasjons heller enn prosjektkostnad  Generelle komponenter kan ta større plass og kan være mindre effektive enn spesialiserte

Generalisering av eksisterende kode for gjenbruk  Navnegeneralisering –Navnene bør ikke gjelde en bestemt anvendelse  Operasjonsgeneralisering –Operasjoner kan legges til for å gjøre komponenten mer anvendelig, mens mer spesialiserte operasjoner fjernes.  Unntaksgeneralisering –Unntakshåndtering forbedres, så komponenten blir mer robust.  Komponentsertifisering og dokumentasjon –Komponenten testes og dokumenteres skikkelig

Gjenbruksforbedringsprosess

Applikasjonsfamilier  Produktlinje med felles arkitektur  Hver applikasjon er spesialisert  Felles kjerne  Utvikling er tilpasning av komponenter evt legge til komponenter  Spesialisering kan være –Plattform –Konfigurering –Funksjonell

Eksempel på applikasjonsfamilie: Ressurshåndteringssystemer  Holde orden på eiendeler  En del er likt for alle – en felles kjerne av funksjonalitet  Noe er avhengig av ressurstypen

Arkitektur for applikasjonsfamilier  Arkitekturen må skille grunnleggende funksjonalitet fra ressurs- og UI-beskrivelse.  Lagdelt arkitektur med eget lag for ressurs- og UI-beskrivelse ellers uavhengig av bruksområdet.  Noen bruksområder krever flere moduler i systemlagene.  Mulig objektorientering

Et ressurshåndteringssystem

Utvidelse av applikasjonsfamilien: Biblioteksystem

Prosess for utvikling av et nytt medlem av applikasjonsfamilien

 Analyser interessentenes krav –Vanlig kravspesifisering –Lettes ved at man kan ta utgangspunkt i eksisterende familiemedlem som demonstreres.  Velg det nærmeste familiemedlemmet  Reforhandle krav for å redusere endringsbehov  Tilpass eksisterende system –Tilpasning av moduler –Nye moduler  Levér nytt familiemedlem

Applikasjonsfamilier  Applikasjonsfamilier kommer vanligvis fra eksisterende applikasjoner –Mange kunder med lignende behov –Men endringer ødelegger programstruktur  Ny generell arkitektur som er lettere å tilpasse  Denne arkitekturen bygger på gjenbruk av kunnskap høstet under tilpasning av tidligere arkitekturer

Patterns  Utformingsmønstre – gjenbruk av kunnskap om utforming.  Historisk –Standardalgoritmer (1971 Knuth) –Abstrakte datatyper- trær, stakk, lister (1987 Booch) –Utformingsmønstre (1995) fra Christopher Alexander(1977) mønstre i bygningsutforming  Mønster –beskriver et problem og dets generelle løsning –ikke detaljert –Basert på erfaring

Patterns (Gamma 1995)  Fire essensielle deler –Meningsfullt navn på mønsteret. –En beskrivelse av problemet mønsteret kan brukes på. –En løsningsbeskrivelse. •Ikke konkret •Ofte grafisk framstilt –Beskrivelse av konsekvensene •resultater •kompromisser

Eksempel på mønstre  Navn –Observer (Observatør)  Beskrivelse –Skiller visning av en objekttilstand fra selve objektet  Problembeskrivelse –Brukes når tilstanden skal vises i flere former  Løsningsbeskrivelse –Se neste side  Konsekvenser –Vanskelig å optimalisere visningsytelsen.

Multiple displays

The Observer pattern Observatørmønsteret