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.

Slides:



Advertisements
Liknende presentasjoner
Repetisjon innkapsling static tabell av primitiv datatype LC191D Videregående programmering Høgskolen i Sør-Trøndelag, Avdeling for informatikk og e-læring.
Advertisements

Del 3 : Patterns (Kap 16 – kap 20, Craig Larman) Arne Maus Inst. for informatikk, UiO.
LC238D Datamodellering og databaser Introduksjon til fagfeltet Else Lervik, august 2012Forelesning 1, uke 34 Datafilerside.
Forelesning IMT Februar 2006
Programvaretesting In 140 Sommerville kap 20.
Prototyping & Use Case Software Engineering Gruppe
MS kap 61 Nye trender  Vi skal se på  Virtualisering  ”Cloud computing”
Flere UML diagrammer UML Distilled kap. 7,8, 9 Kirsten Ribu
Flere UML diagrammer UML Distilled kap. 7,8, 9 Kirsten Ribu
Java Server Faces (JSF) en introduksjon Frode Eika Sandnes.
Modellbruk i Referansekatalogen Øyvind Aassve NorStella.
1 Oppgave gjennomgang Kap Oppgaver -Kap 12: 1, 2, 3, 5, 7, 8, 11, 18, 19.
Utforming av arkitektur
Øving 6: Med utgangspunkt i Internett/Web teknologi skal vi se på hvordan vi kan opprette nye foretningsmodeller. Vi skal ta utgangspunkt i lærebok-produksjon.
Objektorientert utforming In 140 Forelesning Nr 13 Sommerville kap 12 – del 2.
Siste forelesning ER/EER-modellering
Om øvelse 9 Vedlikehold av data Databaser. Øvelse 9 I øvelse 8 så vi på: –Registrering av informasjon om hjelpere To små utvidelser av øvelse 8: –Endring.
RELASJONER, NETTVERK OG STRUKTURER
Patterns (mønstre) Patterns er erfaringer Patterns er best-practices Patterns er how-to Patterns er velkjent design Larman: ” ’new Pattern’ is an Oxymoron”
Læring og tenkning Systemutvikling er læring Gjensidig respekt og samarbeid Følge en konkret oppskrift Velge blant flere oppskrifter Nå målet uten oppskrift,
En kort innføring i Design Patterns
Hovedprinsipper i Rational Unified Process
Bendik Bygstad Høgskolen i Vestfold RUP-prosjekt Sammenhengen med UML 1.Hovedstruktur i RUP-prosjekter 2.Faser og iterasjoner 3.Sammenhengen med.
Klassediagrammer Klassen er en grunnleggende enhet i et objektorientert system Alle kan finne klasser i et domene Det å finne klasser er en intuitiv aktivitet.
Patterns (mønstre) Patterns er erfaringer Patterns er best-practices Patterns er how-to Patterns er velkjent design Larman: ” ’new Pattern’ is an Oxymoron”
Combining Compound Conceptual User Interface Components with Modelling Patterns - a Promising Direction for Model-based Cross-platform User Interface Development.
UML og grensesnitt UML er standard for modellering innen objekt-orientert programvare kan UML også brukes til modellering av grensesnitt? fordel: bedre.
Gruppe 3 – Presentasjon 2 Henning Kristiansen, Mats Lindh, André Hauge og Vegard Simensen.
DEKOMPONERING OG MODULARITET ~Gruppe 4~. Gjennomgang Designtyper/kriterier innen dekomponering Dekomponeringsspesifikasjon Strukturert og objektorientert.
Teknikker for å bedre design- prosessen -Design by contract -Prototyping design -Fault-tree analyses.
Programmering i ActionScript - hva er det, og hvordan undervise?
TAPAS Presentasjon TTM47AC Hva er TAPAS?  Telematics Architecture for Plug and play Systems  Et forskningsprosjekt ved institutt for Telematikk,
Prosjektoppgave Modelldrevet utvikling og brukeragenter for kommunikasjon i sykehusomgivelser Marie S. Fuglesang NTNU, høsten 2004.
Konfigurasjonsstyring Configuration Management
The Peer-to-Peer Architecture Av Ingunn Lund og Anja Lønningen.
DRI1002-V04 Fforelesning uke 17,19 Arild Jansen, AFIN DRI IKT og informasjonssøking Forelesning uke 17 og 18 Hovedpunktene i forelesningen Litt om.
Teknologiledelse 1 Økt sikkerhet og effektivitet i boring og produksjon Jostein Sveen Smartere Sammen Smartere Sammen ® En fire-faset prosess.
Eksempler på Rettskildestudier (“annen rettskildeforskning”) Dag Wiese Schartum, AFIN.
NOEA/IT FEN - Databaser/modellering 1 Datamodellering Hvorfor? E/R-modellen Begreber Fremgangsmåde Diagrammering.
Objektorientert utforming In 140 Sommerville kap. 12.
Fremtidens Web Pensum: Olsen, kap se også: Berre A & Olsen, K.A. (2004) Brytningsteknologier og pirater, kronikk i Bergens Tidende,
1 GeoPortal – Rammeverk Introduksjon. 2 Teknisk rammeverk - Interoperabilitet Interoperabilitet evne til å kommunisere, kjøre programmer, eller overføre.
Dokumentasjon av rettslige beslutningssystemer Dag Wiese Schartum, AFIN.
Utvikling av rettslige beslutningssystemer, oversikt over emnet og presentasjon av ”Fra lovtekst til programkode” Utvikling av rettslige beslutningssystemer,
Forstudie Nå situasjonen: dagens situasjon med ulemper og fordeler
Gamle systemer In 140 Sommerville kap 26. Forelesninger fremover 8/4:Gamle systemer 22/4: Systemevolusjon og vedlikehold 28/4: Konfigurasjonsstyring.
Gamle systemer In 140 Forelesning Nr 19 Sommerville kap 26.
DRI2001 h05 - Forelesning 21.sept Arild Jansen 1 Systemutviklingsarbeidet – et overblikk DRI2001 forelesning 21. sept. 05 Hva er systemutvikling.
DRI2001 h04 - Forelesning Arild Jansen 1 Systemutviklingsarbeidet – et overblikk DRI2001 forelesning Hva er systemutvikling (SU)
Foretak Bjørnar Sæther SGO 4601 V-07. Struktur på forelesningen Hva er foretak? Foretak i økonomisk geografi Dimensjoner ved foretak Foretak og territorier.
FINF- H -04, 21 september 2004 Arild Jansen. AFIN/UiO 1 FINF Forelesning uke 39 Personvern som premiss for SU-prosessen Diskusjon om personvern som.
FINF- H -05, 13. september 2005 Arild Jansen. AFIN/UiO 1 FINF Forelesning 13.sept Personvern som premiss for SU-prosessen Diskusjon om personvern.
Objektorientert design
IKT-prosjekt Ulike typer mobilt datautstyr Ulike konfigurasjoner Synkronisering av data og prosesser Ulike typer nettverk Mobile.
Objektorientert utforming In 140 Forelesning Nr 11 Sommerville kap 12 – del 1.
Objektorientert design In 140 Sommerville kap 12 – del 1.
Use case realisering Designmodellering Kirsten Ribu Kapittel 4 UML Distilled.
1 Programvaretesting del 2 In 140 Forelesning Nr 18 a Sommerville kap 20 del 2.
Produktnavn Tittel på presentasjon. Oversikt Gi en kort beskrivelse av produktet eller tjenesten, brukerproblemene som løses, og brukerne produktet eller.
RUP-prosjekt Sammenhengen med UML
Klassediagrammer II Klassen samler data og operasjoner i passe store enheter Klassen organiserer programdesignet.
Produktnavn.
Lover og forskrifter Kort introduksjon til modulen.
Nye trender Vi skal se på Virtualisering ”Cloud computing”
Lover og forskrifter Kort introduksjon til modulen.
Lover og forskrifter Kort introduksjon til modulen.
Sett inn bilde av produkt her
Dybdelæring – regneark B – Samarbeid
Utskrift av presentasjonen:

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 1 IN250 – 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 (utdrag)

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 4 Eksempel : Konferansesystemet: Forenklet komponent Arkitektur: Komponent ’brukergensesnitt Komponent ’modell – inkludert funksjoner Komponent ’Database

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 5 Eksempel: Klient-server arkitektur Nettverk Prinsipp: Forsøk å optimere utnyttelse av klientenes ressurser og nettverkets kapasitet

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 6 Oppdeling i komponenter

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 7 Processer (kapittel 11)

IN 265 Våren 2003 : Forelesning : 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.

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : 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.

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 13 Eksempel: Fartspiloten (fig. 22.3) l Fire logiske komponenter l Kjernen deles – skal håndteres

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 14 Fra arkitektur til komponenter (kap. 12) Eks: enkelt bank-system, læreboka fig l Detaljer i enkeltkomponenter l Forbindelser mellem komponenter l Iterere over arkitektur

IN 265 Våren 2003 : Forelesning : 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.

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 16 Eksemplet ‘Konto’

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 17 Eksemplet ‘Kunde’ og ‘Konto’

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : 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.

IN 265 Våren 2003 : Forelesning : 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

IN 265 Våren 2003 : Forelesning : 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å?

IN 265 Våren 2003 : Forelesning : Design av arkitektur og komponent 23 Tilstandsdiagram for systemets samlete atferd

IN 265 Våren 2003 : Forelesning : 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