Laste ned presentasjonen
Presentasjon lastes. Vennligst vent
PublisertMarit Sletten Endret for 8 år siden
1
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 1 IN250 – 23.3.2002 Om komponent design Mål for forelesningen: l Se på prinsipper for design av arkitektur og komponent l Anvende OOA&D rammeverket på 3 eksempler med sikte på å illustrere ulike måter bruke OOA&D på, jf tabellen bakerst i. Pensumm : OOA&D-boka, kap. 10-13 (utdrag)
2
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 2 Lagdelt arkitektur (kap. 10) l Lag: beskriver en komponents ansvar: de operasjoner som tilbys oppover og de som brukes nedenfra l Del (eng. Part) : Ingen vesentlig interaksjon med andre dele i samme lag l Lukket arkitektur: kun anvende operasjoner på det umiddelbart underliggende lag l Åpen arkitektur: anvende alle underliggende lag
3
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 3 Grunnarkitektur l Grundarkitekturen avspeiler oppdelingen af omgivelsene i problemområde og anvendelsesområde l “Teknisk plattform” er en utvidelse og innkapsling av den underliggende tekniske platform
4
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 4 Eksempel : Konferansesystemet: Forenklet komponent Arkitektur: Komponent ’brukergensesnitt Komponent ’modell – inkludert funksjoner Komponent ’Database
5
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 5 Eksempel: Klient-server arkitektur Nettverk Prinsipp: Forsøk å optimere utnyttelse av klientenes ressurser og nettverkets kapasitet
6
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 6 Oppdeling i komponenter
7
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 7 Processer (kapittel 11)
8
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 8 Programkomponent l Et fysisk modul med programkode. l Utgjør hovedparten av et typisk system. l Kan utføres på en processor. l Passivt objekt, som blir kalt av et aktivt objekt eller en annen programkomponent. l Inneholder under utførelsen en dynamisk samling af objekter.
9
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 9 Mønstre for distribuering av komponenter Hvis programkomponenter og aktive objekter i en klient-server arkitektur skal fordeles på flere processorer, kan tre mønstre overveies: l Det Sentraliserede mønster l Det Distribuerte mønster l Det Desentraliserte mønster
10
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 10 Det sentraliserte mønster l Minimal distribuering – kun brukergrensesnitt på klienter l Fordeler: »billige klienter »konsistente data (et sted) » enkel og forståelig struktur »moderat netverkstrafik l Ulemper: »lav robusthet (serveren skal være oppe) »høy access-tid »ingen gratis backup
11
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 11 Det distribuerte mønster l Maksimal distribuering – alt er på alle klienter l Fordeler: »lav aksess-tid »høy robusthet »God med backup l Ulemper: »redundante og potentielt inkonsistente data »høy nettverkstrafik »dyre klienter »Komplisert å forstå strukturen
12
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 12 Det desentraliserede mønster l Klienter har deres egne lokalt relevante data. l Delte data er på serveren. l Fordeler: »konsistente data »lav nettverkstrafik »lav aksesstid l Ulemper: »dyre klienter »ingen gratis backup l Krever naturlig distribuering av data.
13
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 13 Eksempel: Fartspiloten (fig. 22.3) l Fire logiske komponenter l Kjernen deles – skal håndteres
14
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 14 Fra arkitektur til komponenter (kap. 12) Eks: enkelt bank-system, læreboka fig. 13.2 l Detaljer i enkeltkomponenter l Forbindelser mellem komponenter l Iterere over arkitektur
15
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 15 Oppdeling av modellkomponenten Fra helhet til deler l Komponent: En samling av programdeler som utgjør en helhet og har et veldefineret ansvar l Modelkomponentens ansvar: Vedlikeholde en oppdatert representasjon af problemområdet.
16
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 16 Eksemplet ‘Konto’
17
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 17 Eksemplet ‘Kunde’ og ‘Konto’
18
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 18 Designmulighed 1 l Objektsystem » ‘Kundeaktivitet’ er et nyt begreb l Struktur » Transaksjoner overlever selvom kontoen nedlegges l Funksjonalitet » Simpelt at lave kontouttog per konto og per kunde
19
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 19 Designmulighed 2 l Objektsystem » ‘Transaktion’ et sentralt og kendt begreb l Struktur » Transaksjoner tettere knyttet til konto » Færre strukturelle forbindelser l Funksjonalitet » Enkelt å lage kontouttak per konto » Men ikke per kunde
20
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 20 Funktionskomponenten (Kapitel 13) l Komponent: En samling av programdeler, som utgjør en helhet og har et veldefineret ansvar l Funksjonskomponentens ansvar: Gjør modellen som en ressurser tilgjengelige for aktørene.
21
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 21 Resultat av Funksjonskomponent l Utgangspunkt i klassediagrammet fra designet av modelkomponenten. l Utbygget med operasjoner, som realiserer krav til funksjoner fra analysen af anvendelsesområdet. Operation: En procesegenskab, der specificeres i en klasse og aktiveres gennem klassens objekter
22
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 22 Design ut fra funksjonstype l Felles for alle typer » Hva er inndata og utdata? » Hvilke objekter er involvert og hvordan identificeres de? » Hvordan skal funktionen realiseres som operationer i forskellige klasser? l Opdatering » Hvilke hendelser igangsetter opdateringen og hva er deres attributter? » Hvordan avgjøres det, om opdateringen er lovlig? l Aflesning » Hvilke attributter og forbindelser skal avleses? l Beregning » Hvilken algoritme skal utføres? l Signalering » Hvilke hendelser kan utløse signaleringen? » Hvilke regler gelder for signaleringen? » Hvordan skal signaleringen foregå?
23
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 23 Tilstandsdiagram for systemets samlete atferd
24
IN 265 Våren 2003 : Forelesning 1.4.2003 : Design av arkitektur og komponent 24 OOAD&D anvendt på eksempler Diskuterers på forelesningen FASE i SU FrisørsalongKonferansesystemSmart Kjøkken Systemdefinisjon Analyse av problem område: klasser Strukturer Adferd Analyse av appl. området: Use Cases Funksjoner Grensesnitt Arkitektur design Komponenter og prosesser Komponent design
Liknende presentasjoner
© 2024 SlidePlayer.no Inc.
All rights reserved.