Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Utforming for gjenbruk In 140 Sommerville kap 14.

Liknende presentasjoner


Presentasjon om: "Utforming for gjenbruk In 140 Sommerville kap 14."— Utskrift av presentasjonen:

1 Utforming for gjenbruk In 140 Sommerville kap 14

2 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

3 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

4 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

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

6 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

7 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)

8 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

9 Gjenbruk gjennom programgenerering

10 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)

11 Component interfaces

12 Printing services component

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

14 Opportunistisk gjenbruksprosess

15 Systematisk gjenbruksprosess

16 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

17 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

18 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.

19 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.

20 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.

21 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)

22 Model-view controller

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

24 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

25 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.

26 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

27 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

28 Gjenbruksforbedringsprosess

29 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

30 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

31 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

32 Et ressurshåndteringssystem

33 Utvidelse av applikasjonsfamilien: Biblioteksystem

34 Prosess for utvikling av et nytt medlem av applikasjonsfamilien

35  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

36 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

37 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

38 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

39 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.

40 Multiple displays

41 The Observer pattern Observatørmønsteret


Laste ned ppt "Utforming for gjenbruk In 140 Sommerville kap 14."

Liknende presentasjoner


Annonser fra Google