subsystem respons ibilities des ign mes s age des ign arkitekturkonstruksjon clas s and object des ign s ubs ys tem des ign
|
|
- Ketil Løken
- 7 år siden
- Visninger:
Transkript
1 Kap. 22 Objektorientert konstruksjon (OO, OOD) 22. Objektorientert Design (OOD) OO konstruksjon () overfører OO analysemodellen til en OODmodell. OOD har modularitet på flere nivå: Hovedkomponenter i systemet organiseres i systemnivå moduler som vi kaller. Data og operasjoner innkapsles i objekter (klasser) som er moduler som er byggesteiner i OO systemer. OOD må beskrive data(attributter), hvordan de er organisert, og operasjonene (prosedyrene) som utføres (data og algoritmer). Systemutvikling Kap.22 Objektorientert 1 Systemutvikling Kap.22 Objektorientert Objektorientert Design (OOD) OOD bygger på 4 viktige konstruksjonsbegreper: 1. Abstraksjon (abstraction). 2. Informasjonsskjuling (information hiding) 3. Funksjonell uavhengighet (functional independence). 4. Modularitet (modularity). Konstruksjonsaktivitetene i OOD inkluderer: OO Design OO Programmering OO Testing Systemutvikling Kap.22 Objektorientert Konstruksjon av OO system Som i tradisjonell (kap.13), har vi også i OOD en konstruksjonspyramide med 4 lag (fig. 22.1): 1. Subsystem konstruksjon. 2. Klasse- og objektlag. - Klassehierarki og representasjon for hvert objekt. 3. Meldingslag. - Kommunikasjon med samarbeidspartnerne, eksterne og interne grensesnitt i systemet. 4. Ansvarslag. - Datastrukturer og algoritmekonstruksjon for alle attributter og operasjoner for hvert objekt. Ansvars Det er også et lag til i som er fundamentet som pyramiden hviler på. Det er domene objekter (her kalt Meldings konstruksjonsmønster) som har en nøkkelrolle i å bygge en infrastruktur for OO systemer. De skal gi støtte Klasse og objekt til menneske-maskin grensesnitt, oppgave- og dataadministrasjon, og de kan også Subsystem brukes til å utfylle selve applikasjonen. Fig.22.1: OO pyramide Systemutvikling Kap.22 Objektorientert 4 Object-Oriented Design message des ign class and object subsys tem des ign res ponsibilities Sammenlikning av vanlig og OO OO er lik vanlig på: data (når attributter skal representeres) grensesnitt (når en meldingsmodell lages) prosedyrekonstruksjon (når operasjoner (metoder) lages). På arkitekturkonstruksjon er det forskjeller: Et OO system har ikke en hierarkisk kontrollstruktur som vanlige program. I et OO system er det mer samarbeid mellom objekter. Fig viser sammenhengen mellom OO analysemodell (kap. 21), og desingmodellen som utvikles fra den. På side 588 er det også listet opp 10 punkter for sammenlikning av vanlig og OO Systemutvikling Kap.22 Objektorientert 5 Systemutvikling Kap.22 Objektorientert 6 1
2 OOA and OOD OOA and OOD Attributes, operations, collaborators Objectrelationship CRC Index Cards model Use cases Object-Behavior Mode l message Class and object subsys tem res pons ibilities Analysis Model classes attributes methods relations hips behavior Design Model objects data structures algorithms messaging control THE ANALYSIS MODEL THE DESIGN MODEL Systemutvikling Kap.22 Objektorientert 7 Systemutvikling Kap.22 Objektorientert Hovedtrekk i Meyer foreslår 5 kriterier for å vurdere en metodes evne til å oppnå modularitet: Dekomponeringsmuligheter (decomposability) Sammensetningsmuligheter (composability) Forståelighet, selvforklarende (understandability) Kontinuitet (continuity) Beskyttelse (protection) OO metoder De OO analysemetodene vi så på i kap 21 har også tilsvarende metoder. Metodene er: Boochs metode Rambaughs metode Jacobsons metode (OOSE) Coad og Yourdans metode Wirfs-Brocks metode Systemutvikling Kap.22 Objektorientert 9 Systemutvikling Kap.22 Objektorientert OO metoder Metodene er ganske like, og de kan sammenfattes til følgende generelle trinn: 1. Beskriv hvert 2. Velg en stategi for implementering av dataadm, grensesnitt, og oppgave adm. 3. Lag en kontrollmekanisme for systemet 4. Objektkonstruksjon prosedyrebeskrivelse for operasjoner og datastrukturer for attributter. 5. Meldingskonstruksjon ut fra samarbeid mellom objekter og obj. relasjoner. 6. Lag en meldingsmodell. 7. Gjennomgå konstruksjonsmodellen, og gjør nødvendige iterasjoner Disse stegene er iterative (gjentas), og det må utføres mer OOA innimellom. Prosessen fortsetter til vi har en komplett konstruksjon UMLs OO Design UML har to (hoved-) aktiviteter: System representasjon av program-arkitektur. Objekt fokuserer på å beskrive objekter og kommunikasjonen mellom dem: Detaljert spesifikasjon av datastrukturene til attributtene. Prosedyre av alle operasjoner Grensesnitt mellom objekter Komplett meldingsmodell I forhold til andre OOD er UML utvidet med Design av brukergrensesnitt Data-administrasjon (data management) Oppgaveadministrasjon (task management) for ene Fig 22 viser prosessflyten fra analyse til Systemutvikling Kap.22 Objektorientert 11 Systemutvikling Kap.22 Objektorientert 12 2
3 Process Flow for OOD 22.2 Systemkonstruksjonsprosessen Følgende trinn inngår i OO systemkonstruksjon: Del analysemodellen opp i Identifiser parallelle (samtidige) aktiviteter. Fordel er på oppgaver (og prosessorer). Design brukergrensesnitt Velg basisstrategi for dataimplementering og -administrasjon Identifiser globale ressurser og kontrollmekanismer som er nødvendige for å aksessere dem. Konstruer en passende kontrollmekanisme for systemet. Vurder hvordan grensebetingelser skal håndteres. Gå gjennom (review) og vurder avveininger (valgmuligheter - trade-offs) I de følgende seksjoner gjennomgås detaljene i hvert steg. Systemutvikling Kap.22 Objektorientert 13 Systemutvikling Kap.22 Objektorientert Del opp analysemodellen Kriterier for å isolerer : Subsystemet skal ha et klart definert grensesnitt som all kommunikasjon med resten av systemet skal gå gjennom. Med unntak av et lite antall kommunikasjonsklasser, skal klassene i et bare samarbeide med andre klasser i et. Det bør være et lite antall er Subsystemene kan deles internt for å redusere kompleksiteten. Når to kommuniserer, kan de etablere en klient-server eller toveis (peer-to-peer) forbindelse. (Klient-server: et utfører tjenester for andre, peer-to-peer: ene utfører tjenester for hverandre.) Kommunikasjons- og informasjonsflyten kan representeres i et dataflytdiagram (DFD) der sirklene (prosessene) er. Systemutvikling Kap.22 Objektorientert Samtidighet og allokering av Objekter eller er som reagerer asynkront og samtidig på hendelser er parallelle (samtidige). Vi har da to allokeringsalternativ: Hvert tildeles en egen uavhengig prosessor Subsystemene kjører på samme prosessor. Operativsystemet må da synkronisere parallelliteten. Samtidige oppgaver defineres ut fra tilstandsdiagrammet for hvert objekt. Hvis hendelsesflyten indikerer at bare et objekt er aktivt av gangen, kan en kontrolltråd (thread of control) etableres. Oppgaver (tasks) i OO systemet konstrueres ved å isolere kontrolltrådene. For å velge prosessorstrategi, må ytelseskrav, kostnader, og administrasjon av prosessor-prosessor-kommunikasjon vurderes. Systemutvikling Kap.22 Objektorientert Oppgaveadministrasjon Coad og Yourdon foreslår følgende strategi for å konstruere objektene som administrerer parallelle oppgaver: Bestem karakteristikken til oppgavene (event/interrupt eller klokkestyrt) En koordinatoroppgave og tilsvarende objekter defineres. Koordinator og andre oppgaver integreres. Vi må også bestemme prioriteten til oppgavene, og hvor kritiske de er: Høyt prioriterte oppgaver må ha umiddelbar aksess til prosessor. Høyt kritiske oppgaver må fortsette selv om tilgjengelige ressurser reduseres, eller system kjører i redusert utgave Oppgaveadministrasjon Når karakteristikkene til oppgavene er bestemt, må objektenes attributter og operasjoner som kreves for koordinering og kommunikasjon defineres. Mønstret for spesifisering av en oppgave: Objekt (oppgave)navn (task name) Beskrivelse Prioritet (på oppgaven) Tjenester - liste av operasjoner som objekter er ansvarlige for. Koordinert av - måten objektet er aktivert (startet) på. Kommuniserer via - input og output dataverdier relevante for oppgaven. Systemutvikling Kap.22 Objektorientert 17 Systemutvikling Kap.22 Objektorientert 18 3
4 Brukergrensesnitt Ved konstruksjon av brukergrensesnitt (Human-computer interface - HCI) tar en utgangspunkt i brukerscenarier (use cases). Det lages et kommandohierarki som definerer de forskjellige menyer. I dag finnes det ferdige klasser for GUI. De har funksjoner for kontroll av vinduer, ikoner, mus osv Dataadministrasjonskomponenten Dataadministrasjon kan deles i to områder: 1. Adm av data som er kritisk (viktig) for applikasjonen. 2. Oppretting av en infrastruktur for lagring og gjenfinning av objekter. Dataadministrasjon konstrueres lagdelt: Lavnivå krav for manipulering av datastrukturer skilles fra høynivå krav for behandling av systemattributter. På systemnivå kan et databasesystem brukes, med egne klasser fra leverandøren (gjenbruk). Ved konstruksjon av dataadministrasjon, må en konstruere attributter og operasjoner. Systemutvikling Kap.22 Objektorientert 19 Systemutvikling Kap.22 Objektorientert Ressursadministrasjon Globale systemressurser kan være: eksterne enheter som tilgang til disk, prosessor, kommunikasjonslinjer, eller abstraksjoner som en database eller et objekt. Det bør lages en kontrollmekanisme for adm av ressurser, for eksempel ved å lage en klasse som eier ressursene, og som administrerer all tildeling av dem. (Synkronisering, løse opp konflikter) Kommunikasjon mellom Vi kan bruke samme modell for samarbeid mellom er som vi brukte til O-O samarbeid. Fig viser prinsipper for samarbeid, enten klient-server, eller to-veis (peer-to-peer) modell. Vi må spesifisere kontrakten som er opprettet mellom ene. Kontrakten spesifiserer hvordan er kommuniserer med hverandre. Systemutvikling Kap.22 Objektorientert 21 Systemutvikling Kap.22 Objektorientert 22 client peer contract System Design request request request server contract peer contract Kommunikasjon mellom Vi kan bruke følgende fremgangsmåte for å spesifisere en kontrakt for et : 1. List alle forespørsler som samarbeidspartnere kan gjøre til et. Sorter forespørslene etter, og definer dem innenfor en eller flere passende kontrakter. Husk også kontrakter som er arvet! 2. For hver kontrakt, noter operasjonene (også de arvede) som kreves for å implementere ansvarsforhold som følger av kontrakten. Sørg for å tilordne operasjonene til spesifikke klasser i et. 3. Ta en kontrakt av gangen, og lag en tabell som vist i fig Hvis kommunikasjon og samarbeid mellom ene er komplisert, kan det lages en samarbeidsgraf som vist i fig Systemutvikling Kap.22 Objektorientert 23 Systemutvikling Kap.22 Objektorientert 24 4
5 Subsystem Collaboration Table Subsystem Example Control panel request for status assign to zone test status Sensor request for system status specification of type of alarm periodic status check request for alarm notification periodic check-in require for configuration update Central communication Systemutvikling Kap.22 Objektorientert 25 Systemutvikling Kap.22 Objektorientert Objektkonstruksjonsprosessen I objektkonstruksjon lager vi en detaljer konstruksjon av attributtene og operasjonene som hver klasse består av, og meldingene som forbinder klassen til samarbeidspartene Objektbeskrivelse En beskrivelse kan ha en av to former: 1. En protokollbeskrivelse som beskriver grensesnitt og meldinger som objektet kan motta, og operasjonene som utføres som følge av de enkelte meldingene. 2. En implementasjonsbeskrivelse som viser implementasjonsdetaljer for hver operasjon som følger av en melding som sendes til objektet. Den vil bestå av: 1. En spesifikasjon av objektets navn og referanse til klasse. 2. En spesifikasjon av private datastrukturer med elementer og typer. 3. Prosedyrebeskrivelse av hver operasjon, evt. referanse til en beskrivelse. Systemutvikling Kap.22 Objektorientert 27 Systemutvikling Kap.22 Objektorientert Konstruksjon av algoritmer og datastrukturer Konstruksjon av algoritmer og datastrukturer i OOD følger samme prinsipper som i vanlig konstruksjon (og i alg. met.!). En algoritme spesifiserer en operasjon, for eksempel en beregning eller en prosedyresekvens som kan implementeres som en selvstendig modul. Kompliserte moduler må deles opp i mindre moduler. Datastrukturer konstrueres parallelt med algoritmene. Operasjoner kan deles i tre klasser: 1. Datamanipulering (legge til, slette, reformatere, velge (søke)) 2. Beregningsoperasjoner 3. Overvåking (monitorering) av et objekt for en kontrollhendelse Konstruksjon av algoritmer og datastrukturer Når objektmodellen er konstruert, må den optimaliseres. Følgende tre innfallsvinkler brukes: Gå gjennom objekt-relasjonsmodellen for å kontrollere at konstruksjonen fører til effektiv utnyttelse av ressurser, og at den er lett å implementere. Legg til redundans der det er nødvendig. Kontroller attributt datastrukturene og tilsvarende operasjoner (algoritmer) for å forbedre prosesseringseffektiviteten. Lag nye attributter for å spare utledet (beregnet) informasjon, og dermed spar reberegning. Systemutvikling Kap.22 Objektorientert 29 Systemutvikling Kap.22 Objektorientert 30 5
6 22.4 Konstruksjonsmønster Gode konstruktører på alle områder har en evne til å se mønster som karakteriserer et problem, og tilsvarende mønster kan kombineres for å lage en løsning. OOD er mer fleksibel, elegant og utnytter gjenbruk. I hele OOD prosessen må en undersøke mulighetene for å bruke eksisterende konstruksjonsmønster, og lage nye der gjenbruk ikke er mulig Eksempler på konstruksjonsstruktur Eksempler på konstruksjonsstrukturer: Et eksemplar av et objekt i en anvendelse (en file manager i et operativsystem). Mønster for å overvåke lagring og gjenfinning av systemtilstand (Memento) Sekvensiell prosessering av data (rapporteringsprogram) Systemutvikling Kap.22 Objektorientert 31 Systemutvikling Kap.22 Objektorientert Beskrivelse av en konstruksjonsstruktur Alle konstruksjonsstrukturer (-mønster, pattern) kan beskrives ved å spesifisere følgende punkter (klassifikasjonskriterier, taxonomi): Navnet på strukturen Hensikten med strukturen Problemet strukturen vanligvis anvendes på. Klasser som er nødvendig for implementering Ansvar og samarbeid mellom klaser Retningslinjer for programmering (effektiv implementering). Eksempel på kildekode Kryssreferanse til relaterte konstruksjonsmønstre Fremtiden for konstruksjonsstruktur Konstruksjonsstrukturer (-mønster, pattern) vil (kanskje), sammen med komponenter, føre til at systemutvikling blir mer likt andre ingeniørdisipliner. Klasser vil tilsvare komponenter i elektronikk, og mønstre vil tilsvare små kretser som er bygd opp av komponenter. Det er fortsatt mye arbeid i å kartlegge og katalogisere mønstre. Systemutvikling Kap.22 Objektorientert 33 Systemutvikling Kap.22 Objektorientert Objektorientert programmering (OOP) Dette underkapitlet viser hvordan objekter dokumenteres i UML Klassemodell Fig viser klassebeskrivelse Kunde Navn Adresse Status GetKonto():Kontosamling SetNavn(Nyttnavn); GetNavn(): String Generalisering Fig viser generalisering AktivKonto Konto SpareKonto Kommentarboks: Ikke alle attributter og operasjoner er vist Ingen attributter og operasjoner er vist Systemutvikling Kap.22 Objektorientert 35 Systemutvikling Kap.22 Objektorientert 36 6
7 Aggregering og sammensetning Fig viser aggregering Fabrikkprodukt Fig viser generalisering og aggregering Fabrikkprodukt Aggregering og sammensetning Fig viser sammensetning Kunde Assosiasjon (forbindelse) Fig viser multiplicitet Leder Komponent Hul diamant viser aggregat Komponent KontoSamling Fylt diamant viser sammensetning (composition) 1 1..* En leder er leder for En eller flere ansatte Ansatt Komponent Komponent Komponent Systemutvikling Kap.22 Objektorientert 37 Systemutvikling Kap.22 Objektorientert Brukstilfeller (Use-Cases) Fig viser enkelt brukstilfelle Fig Flere brukstilfeller Fig Eksempel på brukstilfeller som bruker et annet brukstilfelle Lag statusrapport <<uses>> Låner Lån bøker Leder Fordel arbeidsoppg Varehusleder Spør etter produkt <<uses>> Spør etter lagerbeholdning Verifiser produkt Avslutt prosjekt Det vil være mange flere brukstilfeller for en varehusleder <<uses>> Spør etter ordredetaljer Initier prosjekt Systemutvikling Kap.22 Objektorientert 39 Systemutvikling Kap.22 Objektorientert 40 Fig Et enkelt sekvensdiagram Fig Eksempel på tilstandsdiagram GammelKunde: BankKunde Leder: Ansatt Oppdater Rapport SalgsRapport Salgs- Transaksjon Avslutt konto Opprett konto Endredetaljer Lag transaksjoner Aktiv konto Transaksjon Tom konto Transaksjon Systemutvikling Kap.22 Objektorientert 41 Systemutvikling Kap.22 Objektorientert 42 7
21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA)
21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA) Når vi skal lage en OO analysemodell, bruker vi 5 hovedprinsipper: 1. Lag en modell av informasjonsdomenet. 2. Beskriv modul-funksjonene
Detaljer20.1 Det objektorienterte paradigme (mønster)
Kap. 20 Objektorienterte begreper og prinsipper Kap. 20 Objektorienterte begreper og prinsipper OOP - objektorientert programmering Opprinnelig fra norske SIMULA (67) Objektorientert utvikling kom i bruk
DetaljerUML-Unified Modeling Language
UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram
DetaljerUML-Unified Modeling Language. Prosess-oversikt. Use case realisering
Use case realisering Designmodellering 31.01.2005 Kirsten Ribu UML-Unified Modeling Language Use Case diagram Klassediagram Oppførselsdiagrammer Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram
DetaljerFra krav til objektdesign
Fra krav til objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050-ansvar-1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller
DetaljerUML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller
UML- Use case drevet analyse og design Bente Anda 23.09.2004 23.09.04 INF320 I dag Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller 23.09.04 INF320
DetaljerSpesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign
Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objektdesign Hva skal systemet gjøre? UML: Bruksmønstermodeller o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer
DetaljerOptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål
OptimalJ-kurs UIO 2004 Agenda Time 1: Oppsummering av kurset Time 2: De ulike modellene egenskaper og formål Team Development med OptimalJ Domain Patterns Egenutviklede transformasjoner (krever Architect
DetaljerUse case drevet design med UML
Use case drevet design med UML Bente Anda 26.09.2005 23.09.04 INF3120 1 I dag Domenemodeller System sekvensdiagrammer Operasjonskontrakter GRASP patterns Designmodeller med sekvens- og klassediagram 26.09.05
DetaljerGenerelt om operativsystemer
Generelt om operativsystemer Operativsystemet: Hva og hvorfor Styring av prosessorer (CPU), elektronikk, nettverk og andre ressurser i en datamaskin er komplisert, detaljert og vanskelig. Maskinvare og
DetaljerSpesifikasjon av Lag emne
Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer
DetaljerMetode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur
Dagens forelesning o Litt mer om design med UML sekvensdiagrammer Sentralisert og delegert kontrollstil Resultater fra et eksperiment o UML klassediagrammer Notasjon: UML klassediagram og objektdiagram
DetaljerAnsvarsdrevet OO: CRC og UML Sekvensdiagrammer
Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use
DetaljerTom Røise IMT 2243 : Systemutvikling 1. Forelesning IMT Mars Designfasen i SU-prosjekter : Generelle steg i Designprosessen
Forelesning IMT2243 12. Mars 2007 Tema : Design av programvare Hva ønsker vi å oppnå i designfasen? Generelle steg ved design av programvare Softwarearkitektur Struktur og organisering Dekomponering Kontrollmekanismer
DetaljerBeskjed fra Skagestein
Beskjed fra Skagestein "I forbindelse med prosjektoppgavens delinnlevering 4 vil gruppelærerne sette opp en PHP-orakeltjeneste torsdag 7. april kl 1415-1800 på termstua i Niels Henrik Abels hus." INF1050-klasser-1
DetaljerTom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse
IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler
DetaljerKap3: Klassemodellering
Kap3: Klassemodellering I dag: Litt repetisjon fra sist (innledende om klassemodellen) Deretter egentlig litt mer repetisjon, men nå fra intro- Felt-/Instansvariabler og kurset i Java: Klasser og Objekt,
DetaljerNB! Endring i undervisningsplanen
NB! Endring i undervisningsplanen Forelesningen 24. mars må dessverre avlyses på grunn av Fagkritisk dag Se beskjed som er lagt ut på kursets nettsider og den oppdaterte undervisningsplanen INF1050-klasser-1
DetaljerHensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen
Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker
DetaljerSpesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter
Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer
DetaljerUML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu
UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering
DetaljerKap. 12 Analysemodellering (Analysis Modeling)
Kap. 12 Analysemodellering (Analysis Modeling) Strukturert analyse er en av de mest brukte brukte modelleringsmetoder i analysen. Den andre er objektorientert analyse. 12.1 Kort historikk Strukturert analyse
DetaljerGruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>
Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning
DetaljerCORBA Component Model (CCM)
CORBA Component Model (CCM) INF5040 Høst 2005 Erlend Birkedal Jan Erik Johnsen Tore Ottersen Løkkeberg Denne presentasjonen CORBA Svakheter ved CORBA Object Model Komponenter CORBA Component Model Hva
DetaljerI dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?
UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering
DetaljerMer$om$objektorientering$og$UML
INF1030:&25.&april&2019 Mer$om$objektorientering$og$UML Yngve&Lindsjørn ynglin@ifi.uio.no IN1030& >&Systemutvikling6>objektorientert modellering 1 Gjennomgang&i&dagens&forelesning! Tabeller&(arrays)&vs.&objekter!
DetaljerKap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner
Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er
DetaljerSpesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter
Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer
DetaljerDistributed object architecture
Forelesning IMT2243 6. April 2010 Tema: forts. arkitektur og design av programvare Prosjektstatus Programvarearkitektur Oppsummering fra før påske Distribuerte objektarkitektur MDA - Model Driven Architecture
DetaljerGenerelt om operativsystemer
Generelt om operativsystemer Hva er problemet? Styring av maskinvare og ressurser tilknyttet en datamaskin er komplisert, detaljert og vanskelig Maskinvare, komponenter og programvare endres og forbedres
DetaljerINF5120 - Oblig 2. Hour Registration System (HRS)
INF5120 - Oblig 2 Hour Registration System (HRS) 1 av 40 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 2 2 Innholdsfortegnelse for figurer... 3 3 Hour Registration System (HRS)... 4 3.1 Introduksjon...
DetaljerIN2001: Kravhåndtering, modellering, design
IN2001: Kravhåndtering, modellering, design 30 januar 2018 Yngve Lindsjørn ynglin@ifi.uio.no IN2001 -> Kravhåndtering og modellering 1 Gode beskrivelser av krav er viktig for kontrakt oppdragsgiver leverandør
DetaljerKapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process
INF 329 Web-teknologier Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process Navn: Bjørnar Pettersen bjornarp.ii.uib.no Daniel Lundekvam daniell.ii.uib.no Presentasjonsdato:
DetaljerEksamen INF
Eksamen INF5120 06.06.2005 Et løsningsforslag Oppgave 1 a) Business Model Oppgaven spør om en business model for samhandlingen mellom Buyer og Seller, og det er da viktig å ikke modellere alt det andre!!!
DetaljerIN2000:&Kravhåndtering,&modellering,&design
IN2000:&Kravhåndtering,&modellering,&design 31&januar&2019 Yngve&Lindsjørn ynglin@ifi.uio.no IN2001&'>&Kravhåndtering og modellering 1 Gode&beskrivelser&av&krav er&viktig&for kontrakt&oppdragsgiver& leverandør
DetaljerUniversitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte
Universitetet i Oslo Institutt for informatikk Eskild Busch UML hefte 6. desember 2000 Innhold Dette heftet tar for seg deler av UML som er sentralt i kurset IN29. Use case-, sekvens-, tilstand- og klassediagrammer,
DetaljerFra krav til modellering av objekter
INF1050: Systemutvikling 14. februar 2017 Fra krav til modellering av objekter Førstelektor Yngve Lindsjørn INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 1 Temaer i dagens forelesning
DetaljerOppsummering. Thomas Lohne Aanes Thomas Amble
Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt
DetaljerUKE 11 UML modellering og use case. Gruppetime INF1055
UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav
DetaljerINF 5120 Obligatorisk oppgave Nr 2
INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping
DetaljerTom Røise 9. Februar 2010
Forelesning IMT2243 9. Februar 2010 Tema : Kravspesifisering : prosessen og produktet Viewpoint en myk tilnærming Pensum : Kap. 6 og 7 i Sommerville, Kravspesifisering Kravspesifisering = arbeidet med
DetaljerHva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP
Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å
DetaljerKapittel 13 Advanced Hypertext Implementation. Martin Lie Ole Kristian Heggøy
Kapittel 13 Advanced Hypertext Implementation Martin Lie Ole Kristian Heggøy 08.11.04 Forbedring av arkitektur Problem med alt i ett -løsning: Spredning av forretningslogikk. Avhengighet mellom presentasjonssider
DetaljerModel Driven Architecture (MDA) Interpretasjon og kritikk
Model Driven Architecture (MDA) Interpretasjon og kritikk Ragnhild Kobro Runde (Ifi, UiO) Veileder: Ketil Stølen (Ifi/SINTEF) Stuntlunsj SINTEF Oversikt Bakgrunn/utgangspunkt for presentasjonen MDA stuntlunsj
DetaljerAlgDat 12. Forelesning 2. Gunnar Misund
AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av
DetaljerKap. 10 Systemutvikling System Engineering
Kap. 10 Systemutvikling System Engineering - Utvikling og integrering av både maskin- og programvare. - Hvordan oppstår behov for programvare? - Hvordan inngår programvare i en sammenheng med andre (del)systemer,
DetaljerTom Røise 24.Mars 2009
Forelesning IMT2243 24. Mars 2009 Tema : Design av programvare Offshore Software Development (se foiler for sist) Hva er målet i designfasen? Generelle steg ved design av programvare Softwarearkitektur
DetaljerProduktrapport Gruppe 9
Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette
DetaljerKirsten Ribu - Høgskolen i Oslo 05.05.04
Prosessmodellering Strukturert analyse og design et overblikk Gurholt & Hasle, kapittel 10 Kirsten Ribu - Høgskolen i Oslo 05.05.04 1 Perspektiver på modellering Datamodellering var lenge den mest brukte
DetaljerTeam2 Requirements & Design Document Værsystem
Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 22/01/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerProgramvare arkitekturer
Programvare arkitekturer 14. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker
DetaljerArkitektur. 4 april Mål for forelesningen: Se på kriterier for design, arkitektur av komponent og prosess. Kriterier. Komponenter.
4 april 2006 Arkitektur Mål for forelesningen: Se på kriterier for design, arkitektur av komponent og prosess Kriterier Komponenter Prosesser Kap 9-11 OO A & D 1 Design av arkitektur Arkitektur: En generell
DetaljerModellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn
INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering
DetaljerProsjektrettet systemarbeid
Prosjektrettet systemarbeid Funksjonsmodellering Faglærer: Kjell Toft Hansen Funksjonsmodellering Fra prosjektets brukerkravdokument: Kap. 3.1 Krav til funksjoner Kravene til funksjoner beskriver hva bruker
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:
DetaljerGJENNOMGANG UKESOPPGAVER 9 TESTING
GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.
DetaljerGJENNOMGANG UKESOPPGAVER 7 REPETISJON
GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon
DetaljerInnholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.
Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:
Detaljer2. HVA ER EN KOMPONENT?
Innholdsfortegnelse 1. INTRODUKSJON 3 2. HVA ER EN KOMPONENT? 3 2.1. Litt av historien 3 2.2. UML og komponenter 5 2.3. Noen definisjoner 5 REFERANSER 7 1. Introduksjon Komponenter og komponentbasert systemutvikling
DetaljerKravspesifisering (3): Forhold til OO Analyse og Design
Dagens tema / læremål Kravspesifisering (3): Forhold til Analyse og Design Guttorm Sindre, IDI Problemanalyse, kravspesifisering og design Forstå forskjeller mellom disse tre Forstå hvor modellering passer
DetaljerDistributed object architecture
Forelesning IMT2243 1. April 2009 Tema: forts. arkitektur og design av programvare Oppsummering fra forrige gang Programvarearkitektur i distribuerte systemer Programvarearkitektur i RUP Eksempler på arkitekturvurderinger
DetaljerNOVUG 3 februar 2009
NOVUG 3 februar 2009 Tjenestekatalog og CMDB En kombinasjon som fungerer i praksis 2008 Prosesshuset AS All tillhørende informasjon kan bli endret uten varsel 1 Introduksjon Stig Bjørling Ellingsen Gründer
Detaljer4.1. Kravspesifikasjon
4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens
DetaljerSTE6221 Sanntidssystemer Løsningsforslag
HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag Tid: Fredag 02.03.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator,
DetaljerKravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009
Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet
DetaljerLykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet
Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:
Detaljercase forts. Alternativ 1 Alternativer Sammensetning Objekt-interaktor med valg
Objekt-interaktor med valg AMS- case forts. Eksemplifisering av modellbasert tilnærming til design av brukergrensesnitt Relatert objekt velges ofte blant mange kandidater Output av kandidat-sett Input
DetaljerDistribuerte objekter og objekt-basert mellomvare
Distribuerte objekter og objekt-basert mellomvare INF 5040 H2004 foreleser: Frank Eliassen Frank Eliassen, SRL & Ifi/UiO 1 Hvorfor objekt-basert distribuert mellomvare?! Innkapsling " naturlig tilnærming
DetaljerTilstandsmaskiner med UML og Java
Tilstandsmaskiner med UML og Java DAT2160 DAT2160 Høst Høst 2002 2002 Tilstandsmaskiner Tilstandsmaskiner med med UML UML og og Java Java Hva er en (endelig) tilstandsmaskin? En tilstandsmaskin kan sees
DetaljerSystem integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,
System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration
DetaljerKirsten Ribu - Høgskolen i Oslo 05.05.04
Prosessmodellering Strukturert analyse og design et overblikk Gurholt & Hasle, kapittel 10 Kirsten Ribu - Høgskolen i Oslo 05.05.04 1 Prosessrapporten Prosessrapporten skal beskrive valg av systemutviklings-prosess,
DetaljerModellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn
INF1050: Systemutvikling 07. februar 2017 Modellering av krav Førstelektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering av
DetaljerDistribuerte objekter og objekt-basert mellomvare
Distribuerte objekter og objekt-basert mellomvare INF 5040 H2006 foreleser: Frank Eliassen INF5040 Frank Eliassen 1 Hvorfor objekt-basert distribuert mellomvare? Innkapsling naturlig tilnærming til utvikling
DetaljerKapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20
Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 Kravspesifikasjoner & Data design Thomas Tjøstheim og Thomas Edvinsen 20 September 2004 Kapittel 7 & 8 p.2/20 Introduksjon Kravspesifikasjoner består av to underdeler:
DetaljerUse Case-modellering. INF1050: Gjennomgang, uke 04
Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram
DetaljerInnhold. Forord Det første programmet Variabler, tilordninger og uttrykk Innlesing og utskrift...49
Innhold Forord...5 1 Det første programmet...15 1.1 Å kommunisere med en datamaskin 16 1.2 Programmeringsspråk 17 1.3 Et program som skriver på skjermen 18 1.4 Kompilering og kjøring 19 1.5 Kommentarer
DetaljerPresentasjon 1, Requirement engineering process
Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv
DetaljerDistribuerte objekter og objekt-basert mellomvare
Distribuerte objekter og objekt-basert mellomvare INF5040 foreleser: Olav Lysne Frank Eliassen, SRL & Ifi/UiO 1 Hvorfor objekt-basert distribuert mellomvare? Innkapsling naturlig tilnærming til utvikling
Detaljer(MVC - Model, View, Control)
INF1010 - våren 2008 Modell - Utsyn - Kontroll (MVC - Model, View, Control) Stein Gjessing Inst. for informatikk Et bankprogram Vi skal lage et program som håndterer kontoene i en bank. En konto eies av
DetaljerGruppenavn. Beskrivelse av arkitektur For Navn på systemet. Versjon <1.0>
Gruppenavn Beskrivelse av arkitektur For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1
DetaljerMetode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur
Dagens forelesning o Litt mer om design med UML sekvensdiagrammer Sentralisert og delegert kontrollstil Resultater fra et eksperiment o UML klassediagrammer Notasjon: UML klassediagram og objektdiagram
DetaljerFra krav til objekter. INF1050: Gjennomgang, uke 05
Fra krav til objekter INF1050: Gjennomgang, uke 05 Kompetansemål Systemmodellering og systemperspektiv Utvikle abstrakte modeller av et system Ulike modeller representerer ulike perspektiver av systemet
DetaljerIntroduksjon til fagfeltet
LC238D http://www.aitel.hist.no/fag/_dmdb/ Introduksjon til fagfeltet Datafiler side 2 Databasesystemer side 3-5 Databasearkitektur ANSI/SPARC side 6-7 Datamodeller side 8 Flerbruker databasesystem side
DetaljerLæringsmål uke 7. Objektorientert programmering i Python: Introduksjon. Innhold uke 7. Lite tilbakeblikk: Programflyt og skop
Læringsmål uke 7 Objektorientert programmering i Python: Introduksjon IN1000 Høst 2018 uke 7 Siri Moe Jensen Kjenne til motivasjon og bakgrunn for objektorientert programmering Kunne definere en klasse,
DetaljerLæringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering
1 2 Læringsmål og pensum TDT4110 Informasjonsteknologi grunnkurs: Uke 38 Utvikling av informasjonssystemer Læringsmål Kunne seks faser for systemanalyse og design Kunne femstegs prosedyre for programmering
DetaljerGruppe 11. Frank Petter Larsen Vegard Dehlen
qoskets Gruppe 11 Frank Petter Larsen Vegard Dehlen Problematikk Dagens mellomvare for objektbaserte distribuerte systemer har ikke innebygget støtte for å spesifisere, overvåke og kontrollere tjenestekvalitet
DetaljerINF1010 MVC i tekstbaserte programmer
INF1010 MVC i tekstbaserte programmer Marit Nybakken marnybak@ifi.uio.no 9. februar 2004 Marit har ingen utdanning innen systemutvikling og vet antageligvis ikke hva hun prater om. Hun har dog skumlest
DetaljerFakultet for informasjonsteknologi, Løsning på kontinuasjonseksamen i TDT4190 Distribuerte systemer 19. august 2006,
Side 1 av 8 NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Løsning på kontinuasjonseksamen
DetaljerUse case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel
Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,
DetaljerHvorfor objektorientert programmering? Objektorientert programmering i Python: Introduksjon. Læringsmål uke 7. Undervisning og pensum IN1000
Objektorientert programmering i Python: Introduksjon IN1000 Høst 2019 uke 7 Siri Moe Jensen Læringsmål uke 7 Kjenne til motivasjon og bakgrunn for objektorientert programmering Kunne definere en klasse,
DetaljerUse case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?
1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten
DetaljerForelesning IMT Mars 2011
Forelesning IMT2243 24. Mars 2011 Tema : Design av programvare Hva er målet i designfasen? Generelle steg ved design av programvare Softwarearkitektur Struktur og organisering Kontrollmekanismer Dekomponering
DetaljerSystem Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk
System Dokumentasjon Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentsjon 23/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerAlgDat 10. Forelesning 2. Gunnar Misund
AlgDat 10 Forelesning 2 Oversikt Java repetisjon IDE eller teksteditor + kommandolinje? Java Collections and Generics Programvareutvikling En mengde mer eller mindre veldefinerte metoder (software engineering):
DetaljerHva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP
Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å
DetaljerKravspesifiseringsprosessen
IMT2243: 18.februar 2010 DAGENS : Metoder for å få kartlagt de Funksjonelle kravene Strukturert Analyse den gamle måten og gjøre det på (dette foilsettet + wikipedia-omtalen er eneste pensum innen SA)
DetaljerHvorfor objektorientert programmering?
Objektorientert programmering i Python: Introduksjon IN1000 Høst 2019 uke 7 Siri Moe Jensen Læringsmål uke 7 Kjenne til motivasjon og bakgrunn for objektorientert programmering Kunne definere en klasse,
DetaljerMetode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur
Dagens forelesning o Litt mer om design med UML sekvensdiagrammer Sentralisert og delegert kontrollstil Resultater fra et eksperiment o UML klassediagrammer Notasjon: UML klassediagram og objektdiagram
DetaljerInnhold uke 7. Objektorientert programmering i Python: Introduksjon. Lite tilbakeblikk: Programflyt og skop. Lite tilbakeblikk: Funksjoner er uttrykk
Innhold uke 7 Objektorientert programmering i Python: Introduksjon IN1000 Høst 2017 uke 7 Siri Moe Jensen Lite tilbakeblikk: Prosedyrer og funksjoner Objektorientert programmering Introduksjon: Hvorfor,
DetaljerModellering av brukstilfeller og forretningsprosesser. Kurs i standarder, Oslo, 12. juni 2018
Modellering av brukstilfeller og forretningsprosesser Kurs i standarder, Oslo, 12. juni 2018 Modellering av brukstilfeller Innhold Kort innføring i brukstilfeller Elementer i Use Case diagram Relevante
Detaljer