Utforming for gjenbruk In 140 Forelesning Nr 15 Sommerville kap 14.

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

1 Utforming for gjenbruk In 140 Forelesning Nr 15 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 subsystemer 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 CBSE processes Component-based development can be integrated into a standard software process by incorporating a reuse activity in the process However, in reuse-driven development, the system requirements are modified to reflect the components that are available CBSE usually involves a prototyping or an incremental development process with components being ‘glued together’ using a scripting language

17 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

18 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

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

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

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

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

23 Model-view controller

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

25 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

26 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. (accessor, –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.

27 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

28 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

29 Gjenbruksforbedringsprosess

30 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

31 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

32 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

33 Et ressurshånderingssystem

34 Utvidelse av applikasjonsfamilien: Bibliotekssystem

35 Prosess for utvikling av et nytt medlem av applikasjonsfamilien

36 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

37 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

38 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

39 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

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

41 Multiple displays

42 The Observer pattern Observatørmønsteret

43 Design with reuse involves designing software around good design and existing components Advantages are lower costs, faster software development and lower risks Component-based software engineering relies on black-box components with defined requires and provides interfaces COTS product reuse is concerned with the reuse of large, off-the-shelf systems Key points

44 Software components for reuse should be independent, should reflect stable domain abstractions and should provide access to state through interface operations Application families are related applications developed around a common core Design patterns are high-level abstractions that document successful design solutions