21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA)
|
|
- Kjell Børresen
- 7 år siden
- Visninger:
Transkript
1 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 3. Beskriv hvordan modellen virker. 4. Modellene deles opp for å vise større grad av detaljering. 5. De første modellene representerer det sentrale i problemet, mens de senere modellene gir detaljer for implementasjonen. I OOA skal en definere alle klasser og forbindelsene mellom dem som er relevante for å løse problemet. Systemutvikling Kap.21 Objektorientert analyse 1 Systemutvikling Kap.21 Objektorientert analyse Objektorientert Analyse (OOA) Når vi utfører OO analyse, må vi utføre følgende oppgaver: 1. Fundamentale brukerkrav må formidles mellom kundene og systemutviklerne. 2. Klasser må identifiseres, og attributter og metoder må defineres. 3. Et klassehierarki må spesifiseres. 4. Objekt-til-objekt relasjoner (objektforbindelser) må representeres (defineres). 5. Objektoppførsel (virkemåte) må modelleres. 6. Oppgavene 1 til 5 gjentas (iterativt) til modellen er komplett. Det er en rekke forskjellige metoder for OO analyse. Metodene er oppkalt etter de som har utviklet dem. Systemutvikling Kap.21 Objektorientert analyse 3 Systemutvikling Kap.21 Objektorientert analyse 4 Boochs metode har utviklingsprosess både på mikro- og makronivå. Mikronivået definerer en rekke analyseoppgaver som anvendes om igjen for hvert steg i makroprosessen. Metoden støttes også av en rekke automatiske verktøy. Hovedpunktene i metoden på mikronivå er: Identifiser klasser og objekter Identifiser betydningen til klasser og objekter. Identifiser relasjoner mellom klasser og objekter Utfør ei rekke av forbedringer (refinements) Implementer klasser og objekter (fullføring av analysemodellen) Rambaughs metode, også kjent som Object Modeling Technique (OMT) for analyse, system design og objektnivå design. Det lages tre modeller: 1. Objektmodell (objekter, klasser, hierarkier og relasjoner) 2. Dynamisk modell (objekter og systemoppførsel) 3. Funksjonell modell (DFD-liknende representasjon av info-flyt i systemet) Systemutvikling Kap.21 Objektorientert analyse 5 Systemutvikling Kap.21 Objektorientert analyse 6 1
2 Jacobsons metode, også kalt OOSE - OO Software Engineering er en forenklet versjon av Objectory - metoden som også er utviklet av Jacobson. Det spesielle med metoden er utstrakt bruk av use case som er en beskrivelse eller scenairo som viser hvordan brukerne kommuniserer med produktet eller systemet. Hovedtrekkene i Jacobsons metode er: Identifiser brukerne av systemet og deres overordnende ansvarsområder. Bygg en kravmodell Definer aktørene og deres ansvarsområder Identifiser use cases for hver aktør. Lag første versjon av systemobjektene og relasjonene. Gå gjennom (review) modellen der du bruker use cases som scenarier for å bestemme gyldigheten (validiteten). Bygg en analysemodell. Identifiser grensesnitt-objekter ut fra brukerkommunikasjon. Lag en struktur for grensesnitt-objektene. Representer objekt-virkemåte. Isoler subsystemer og submodeller. Gå gjennom modellen ved bruk av use cases som scenarier for å bestemme gyldigheten. Systemutvikling Kap.21 Objektorientert analyse 7 Systemutvikling Kap.21 Objektorientert analyse 8 Andre metoder: Coad og Yourdons metode. Wirfs-Brocks metode Metodene har mange fellestrekk. Når vi utfører OOA må vi gjennomføre følgende aktiviteter: Samle inn brukerkrav for OO systemet. Lag scenarier eller use cases Lag en kravmodell. Velg klasser og objekter ut fra fundamentale krav. Spesifiser attributter og operasjoner for hvert systemobjekt. Definer strukturer og hierarki som organiserer klassene. Lag en objekt-relasjonsmodell Lag en objekt-virkemåte-modell (object-behavior model) Gå gjennom (review) OO analysemodellen og sammenlign med use cases /scenarier. Hvert steg behandles i detalj i kap og Systemutvikling Kap.21 Objektorientert analyse 9 Systemutvikling Kap.21 Objektorientert analyse Unified Modelling Language - UML Booch, Rumbaugh og Jacobson har samarbeidet om å lage UML. Systemet representeres av 5 forskjellige views (perspektiver): 1. User model view - Brukermodell - systemet sett fra brukerens (aktørens) synspunkt. Bruker use cases. 2. Structural model view - Data og funksjonalitet sett fra innsiden av systemet. Modeller av statiske strukturer (klasser, objekter og relasjoner) 3. Behavioural model view - Viser virkemåten (dynamikken) til systemet og samarbeid mellom systemelementer fra bruker- og strukturmodellene. 4. Implementation model view. Representasjon av systemet (fra 2 og 3) slik det skal bygges. 5. Environment model view - Representasjon av systemets omgivelser. Systemutvikling Kap.21 Objektorientert analyse Analyse av kontrollområde (Domain analysis) OOA anvendes på flere nivå i bedriften: Overordnet, strategisk nivå der det utvikles modeller for hele bedriften. (omtales ikke i denne boka) Laveste (detaljert) nivå som er generell OO systemutvikling. (som er tema i de andre seksjonene i dette kapittel) På middels abstraksjonsnivå foregår domain analysis (analyse av kontrollområde, domeneanalyse) som brukes når en organisasjon ønsker å utvikle et bibliotek av gjenbrukbare klasser (komponenter) som vil bli mye brukt på flere applikasjons-områder. Dette er tema i denne seksjonen. Systemutvikling Kap.21 Objektorientert analyse 12 2
3 Gjenbruk og analyse av kontrollområde OO systemutvikling vil være mye mer effektiv når det er tilgang til et godt utbygd bibliotek av gjenbrukbare klasser. Vi skal i de følgende seksjonene se hvordan klasser utvikles for biblioteket Prosess for analyse av kontrollområde Domain analyse er identifisering, analyse og spesifisering av felles gjenbrukbare muligheter innen et spesielt applikasjonsområde i form av felles objekter, klasser, moduler og rammeverk. Applikasjonsområde kan være flyteknologi, bankvirksomhet, multimedia video spill osv. Det gjelder altså å finne eller lage klasser som er anvendelige for området. Domain analyse er en kontinuerlig (paraply)aktivitet som ikke er knyttet til et spesielt prosjekt. Fig viser de viktigste input og output for domain analyse. Systemutvikling Kap.21 Objektorientert analyse 13 Systemutvikling Kap.21 Objektorientert analyse Prosess for analyse av kontrollområde Kilder for kunnskaper om domenet Teknisk litteratur Eksisterende applikasjoner Kundeoversikt Ekspertråd Aktuelle og fremtidige krav Fig Input og output for domain analyse. Klasse taksonomi Gjenbruksstandarder Funksjonell modell Domenespråk Domensanalyse Analysemodell av domenet Prosess for analyse av kontrollområde Aktivitetene i domain analyse: Definer området som skal undersøkes. Klassifiser (sorter) elementene som er funnet. Finn et representativt utvalg av applikasjoner i domenet. Analyser hver applikasjon i utvalget. Identifiser kandidater til gjenbrukbare objekter Begrunn hvorfor objektet er valg ut. Definer tilpasninger til objektet som også kan gjenbrukes Estimer prosentvis antall applikasjoner som kan bruke objektet. Identifiser objektene med navn, og bruk konfigureringsadministrasjon for å kontrollere objektene. I tillegg bør det estimeres hvor stor del av en typisk applikasjon som kan konstrueres fra gjenbrukte objekter. Utvikle en analysemodell av objektene. Modellen tjener som basis for konstruksjon av domene objekter. Systemutvikling Kap.21 Objektorientert analyse 15 Systemutvikling Kap.21 Objektorientert analyse Generiske komponenter i OO analyse modellen OO analyse prosess er lik den vanlige analyseprosessen som vi har sett tidligere, og den har de samme mål... Statiske komponenter er strukturelle av natur, og indikerer karakteristikker som gjelder gjennom applikasjonens levetid. Dynamiske komponenter fokuserer på kontroll, og er følsomme for timing og prosessering av hendelser (events). De definerer hvordan et objekt kommuniserer med andre objekter over tid OOA prosessen OOA prosessen starter med å kartlegge hvordan systemet skal brukes: Er det en (interaktiv) applikasjon med personer som brukere, er det et prosesskontrollsystem som brukes av maskiner, eller brukes det av andre programmer ved at systemet koordinerer og kontrollerer applikasjoner? Når en slik kartlegging ( scenarier ) av bruken er definert, starter modelleringen av systemet. De følgende avsnitt viser teknikker for å samle inn brukerkrav, og deretter definere en analysemodell for et objektorientert system. Systemutvikling Kap.21 Objektorientert analyse 17 Systemutvikling Kap.21 Objektorientert analyse 18 3
4 Use cases Innsamling av krav er alltid første steg i alle analyseaktiviteter. Ut fra kravene lager systemutviklerne et sett med scenarier som hver viser en sammenhengende bruk av systemet som skal lages (en tråd gjennom systemet). Disse scenariene som kalles use cases, gir en beskrivelse av hvordan systemet vil bli brukt. Første steg i å lage use cases, er å identifisere de forskjellige typer av personer som bruker systemet. Disse kalles aktører og representer roller som personer (eller enheter) har i forhold til systemet når det brukes. En aktør er altså alt eksternt som kommuniserer med systemet. NB: En bruker er ikke det samme som en aktør. En bruker kan ha flere aktør-roller Use cases Det er mulig å skille mellom primæraktører som en finner i første analyserunde, og sekundære aktører som en finner senere. De primære aktørene bruker systemet regelmessig til de oppgaver som systemet primært skal utføre. De sekundære aktørene utfører støttefunksjoner i forhold til systemet. Systemutvikling Kap.21 Objektorientert analyse 19 Systemutvikling Kap.21 Objektorientert analyse Use cases UML: Use-Case Diagram Når aktørene er definert, starter utviklingen av use cases. En use case beskriver hvordan en aktør bruker (kommuniserer) med systemet. Jacobson foreslår følgende spørsmål som skal besvares av en use case: Hvilke hovedaktiviteter eller funksjoner utføres av aktøren? Hvilken systeminformasjon vil aktøren spørre om, produsere eller endre? Må aktøren informere systemet om endringer i de eksterne omgivelser? Hvilken informasjon ønsker aktøren å få fra systemet? Ønsker aktøren å bli informert om uventede endringer? Systemutvikling Kap.21 Objektorientert analyse 21 Systemutvikling Kap.21 Objektorientert analyse Use cases Når use case ene er laget, må de gjennomgås (reviews) grundig for å fjerne eventuelle tvetydigheter. Det er også mulig å legge inn tidskrav og andre begrensninger (rammebetingelser) i scenariet. Use cases oppfattes forskjellig av forskjellige aktører. Det er derfor hensiktsmessig å prioritere dem (på en skala 1-10) for hver aktør, og beregne et gjennomsnitt for hver. Dermed bestemmes hvilke use cases som er viktigst, og dette brukes til å prioritere hvilke systemdeler som leveres først Klasse-Ansvar-Samarbeids modellering CRC - Class-Responsibility-Collaborator Modeling CRC er en enkel teknikk for å identifisere og organisere klassene som er relevant for systemet eller kravene til produktet. En CRC-modell er en samling av indekskort som representer klasser. Kortet er delt i tre deler (se fig. 21.3): Navnet på klassen (toppen) Klasse ansvar (class responsibilities - til venstre) som er attributter og operasjoner i klassen Samarbeidspartnere (Collaborators - til høyre) som er de klasser som kreves for at klassen skal få det den trenger for å oppfylle sitt ansvarsområde. Systemutvikling Kap.21 Objektorientert analyse 23 Systemutvikling Kap.21 Objektorientert analyse 24 4
5 CRC Modeling class name: class type: (e.g., device, property, role, event,...) class characterisitics: (e.g., tangible, atomic, concurrent,...) responsibilities: collaborators: Klasse-Ansvar-Samarbeids modellering CRC - Class-Responsibility-Collaborator Modeling Samarbeid (collaborators) identifiserer relasjoner mellom klasser. Når et sett klasser samarbeider om å oppfylle et krav, kan de samles i et subsystem. Samarbeid bestemmes av om en klasse kan oppfylle sitt ansvar selv. Hvis ikke, må den samarbeide (kommunisere) med en annen klasse. Til hjelp med å identifisere samarbeid, kan en undersøke 3 generelle relasjoner mellom klasser: 1. Er-del-av (is-part-of) relasjon 2. Har-kunnskap-om (has-knowledge-of) relasjon 3. Avhenger-av (depends-upon) relasjon Systemutvikling Kap.21 Objektorientert analyse 25 Systemutvikling Kap.21 Objektorientert analyse Definering av strukturer og hierarkier UML: Class Diagrams Når klassene og objektene er definert, ved bruk av CRC modellen, må det lages en struktur i modellen, med hierarki av klasser og subklasser. Først bør en (i følge Coad Yourdon) lage en generaliseringspesialisering (gen-spec) struktur. Fig viser sensor objektet, der sensor er det generelle, og hver sensor er det spesielle (røyksensor). Vi får dermed et enkelt klassehierarki. I andre tilfeller kan et objekt som er representert i den opprinnelige modellen bestå av flere komponenter (deler) som selv skal kunne defineres som objekter. En slik struktur kalles hel-del-(whole-part)-struktur og defineres med en notasjon som vist i fig Generalizationspecialization Generalisering-spesialisering Klasse - subklasse Composite Agregat (består av) aggregates Systemutvikling Kap.21 Objektorientert analyse 27 Systemutvikling Kap.21 Objektorientert analyse Definering av subjekter og subsystemer Et subjekt eller et subsystem er en gruppe klasser som samarbeider for å oppfylle et sett med sammenhengende ansvarsforhold. Både et subjekt og et subsystem er abstraksjoner som gir en referanse eller peker til flere detaljer i analysemodellen. Sett utenfra kan et subjekt eller subsystem ses på som en svart boks som inneholder et sett ansvarsforhold som har egne samarbeidspartnere utenfor. Et subsystem implementer en eller flere kontrakter med sine utenforstående samarbeidspartnerne. En kontrakt er en spesifikk liste av forespørsler som samarbeidspartnere kan utføre. I CRC-modellen er det mulig å lage indekskort for subsystemer, med navn på subsystemet, kontraktene det imøtekommer, og klassene eller andre subsystem som støtter kontraktene. Pakke (subsystem) refaranse UML: Package Reference Systemutvikling Kap.21 Objektorientert analyse 29 Systemutvikling Kap.21 Objektorientert analyse 30 5
6 Relationships between Objects Definering av subjekter og subsystemer Fig viser flere detaljer i kontrollpanelet fra fig.21.5 som er en assembly struktur (består av). Hele strukturen kan refereres med subjekt som vises bokser. Vi lager subjekt referanse av hver struktur som har mer enn 5-6 objekter. På det mest abstrakte nivå vil OOA modellen inneholde bare subjekter (subsystemer, referanser). Hver referanse vil bli ekspandert i en struktur Fig viser referanse til kontrollpanel og sensorer. Systemutvikling Kap.21 Objektorientert analyse 31 Systemutvikling Kap.21 Objektorientert analyse Objekt-relasjonsmodell (the object-relationship model UML: State Transition Fig viser eksempel på en objekt-relasjonsmodell der kardinaliteten er definert Objekt oppførselsmodell (The object-behavior model) Systemets oppførsel må representeres som funksjoner av spesielle hendelser og tid. Modellen viser hvordan systemet reagere på eksterne stimuli. Modellen kan lages ved å utføre 5 trinn, se s Systemutvikling Kap.21 Objektorientert analyse 33 Systemutvikling Kap.21 Objektorientert analyse 34 UML: Event Trace Systemutvikling Kap.21 Objektorientert analyse 35 6
20.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
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
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
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
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
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,
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
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
Detaljersubsystem respons ibilities des ign mes s age des ign arkitekturkonstruksjon clas s and object des ign s ubs ys tem des ign
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
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,
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,
Detaljerdet offentlige kartgrunnlaget (DOK)
geografiske data som er tilrettelagt for plan- og byggesaksarbeid = det offentlige kartgrunnlaget (DOK) Terje Nuland, geodataavdelingen Det offentlige kartgrunnlaget ØK FKB DOK Lover forskrifter veiledning
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
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
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
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
DetaljerGJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN
GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING INF1050 V16 HELGA NYRUD & KRISTIN BRÆNDEN TEMAER SÅ LANGT I KURSET Forelesning 1: Systemutvikling og systemutviklingsprosesser Forelesning 2: Prosessmodeller
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
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
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
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!!!
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
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)
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
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
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
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
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
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
Detaljer1. Modellering av objektorienterte systemer
Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Modellering av objektorienterte systemer Tore Berg Hansen Lærestoffet er utviklet for faget IFUD Objektorientert systemutvikling 1. Modellering
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
DetaljerGod objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04
Mer om UML God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 1 I dag Litt repetisjon GRASP mønstre og OO design Prosjektoppgaven:
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
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
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
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
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
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
DetaljerUNIVERSITETET I OSLO
Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:
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
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
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,
DetaljerEn kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne.
A KRAVSPESIFIKASJON Dette notat er en generell beskrivelse av en kravspesifikasjon for et (teknisk) datasystem. Den er basert på «The STARTS Purchasers Handbook» kap.4 og Appendix B, oversatt til norsk
DetaljerProsessmodell. Hurtigguider - rammeverk Sist redigert 13.06.2009. Snorre Fossland Eier og driver Snorres Modellbyrå
Prosessmodell Hurtigguider - rammeverk Sist redigert 13.06.2009 For å arbeide med prosessene, må du kunne synliggjøre og kommunisere dem på overordnet nivå. Du må også kunne bryte dem ned i mer detaljerte
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
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
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 å
DetaljerKravhåndtering. INF1050: Gjennomgang, uke 03
Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle
DetaljerDRI2001 h04 - Forelesning Systemutvikling og nettsteder
Systemutvikling utvikling av offentlig nettsteder DRI2001 forelesning 20.10 Litt om eksperimentell systemutvikling og prototyping Systemutviklingsprosessene og utvikling av [offentlige] nettsteder Fasene
DetaljerKravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon
Kravspesifikasjon med UML use case modellering Erik Arisholm 01.03.2010 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet
DetaljerTom Røise 18. Februar 2009
Forelesning IMT2243 18. Februar 2009 Tema : Kravspesifisering : litt mer om prosessen Viewpoint en myk tilnærming Use Case en scenariebasert teknikk innen metoden Objektorientert Analyse brukes til å avklare
DetaljerA Study of Industrial, Component-Based Development, Ericsson
A Study of Industrial, Component-Based Development, Ericsson SIF8094 Fordypningsprosjekt Ole Morten Killi Henrik Schwarz Stein-Roar Skånhaug NTNU, 12. des. 2002 Oppgaven Studie av state-of-the-art : utviklingsprosesser
DetaljerKravspesifikasjon med. Erik Arisholm
Kravspesifikasjon med UML use case modellering Erik Arisholm 01.03.2010 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet
DetaljerUnified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert
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
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 å
DetaljerForfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.
2 Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein 5. april 2017 Innhold 1 Klassediagram 2 Sekvensdiagram 2.1 Oppgave 2a 2.2 Oppgave
DetaljerRepitisjonskurs. Arv, Subklasser og Grensesnitt
Repitisjonskurs Arv, Subklasser og Grensesnitt Subklasser Klasser i OO-programmering representerer typer av objekter som deler et sett med egenskaper. En subklasse har egenskapene til en klasse + ett sett
DetaljerUKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
UKE 13 Mer UML modellering Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Objektorientert design - kapittel 5 og 7 UML modellering Aktivitetsdiagrammer Klassediagram Ukesoppgaver
DetaljerEksamen 2013 Løsningsforslag
Eksamen 2013 Løsningsforslag Oppgave 1. Multiple choice 1b# 2a# 3b# 4c# 5b# 6a# 7a# 8b# 9d# 10b# Oppgave 2 - Bibliotek - Utlån av bøker a) Måle størrelse eller mengde funksjonalitet Denne oppgaven ser
DetaljerTom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse
Forelesning IMT2243 1. mars 2007 Tema : Litteratur : Art.saml. Punkt 9 : Kap. 9. SASD - modellen, E. Andersen Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser
DetaljerObjektorientering og UML. INF1050: Gjennomgang, uke 06
Objektorientering og UML INF1050: Gjennomgang, uke 06 Kompetansemål Objektorientert design Objektdesign og ansvarstilordning Bruk av UML Fokus på klassediagrammer Designmodeller Designmønstre ( design
DetaljerEtter uke 9 skal du. Introduksjon til objektorientert programmering. Innhold. Klasser som abstraksjoner
Etter uke 9 skal du Introduksjon til objektorientert programmering INF1001 Høst 2016 Uke 9 Kunne designe og implementere en programstruktur med flere klasser Kunne etablere og manipulere objekter i (sammensatte)
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
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
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:
DetaljerGJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG
GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:
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
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
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
DetaljerUse case modellering. Use case modellen. Metode for systembeskrivelse og Nettsted-design
Use case modellering Metode for systembeskrivelse og Nettsted-design Kirsten Ribu 11.09.2007 Use case modellen beskriver kravene til systemet beskriver systemet sett fra kundens perspektiv beskriver hva
DetaljerUtvikling fra skallet og inn
Utvikling fra skallet og inn Kravspesifikasjon Brukergrensesnitt! inn ut Erik Arisholm Simula Research Laboratory Utviklingsretning Applikasjon Virkelighetsmodell Bruker Oppfatning av interesseområdet
DetaljerGruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>
Gruppenavn Prosjektnavn Kravdokument For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1
DetaljerOppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 30.04.2007. IMT2243 : Systemutvikling 1
Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring
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
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
DetaljerEn ny generasjon standarder for bygging av geografisk infrastruktur Modellering av tjenester
En ny generasjon standarder for bygging av geografisk infrastruktur Modellering av tjenester Kurs i standarder, Oslo, 13.juni Modellering av tjenester Innhold Kort om tjenester og interoperabilitet NS-EN
DetaljerKONTINUASJONSEKSAMEN I FAG 78052 SYSTEMERING 2 Torsdag 24. august 2000 Tid: kl 0900-1300
NORGES TEKNISK- NATURVITENSKAPELIGE UNIVERSITET INSTITUTT FOR DATATEKNIKK OG INFORMASJONSVITENSKAP Faglig kontakt under eksamen: Navn: Hallvard Trætteberg Tlf.: 7359 3443 Hjelpemidler: Ingen tillatte hjelpemidler.
DetaljerPROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004
PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ
DetaljerDRI2001 forelesning
Systemutviklingsarbeidet et overblikk DRI2001 forelesning 6.10.04 Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer for SU-arbeidet Ulike SU-metoder Perspektiver i SU-arbeidet SU er
DetaljerForslag til løsning. Oppgave 1
Forslag til løsning Eksamen 2003 Oppgave 1 A) Lag en Business Model (COMET) for krisehåndteringssystemet. B) Diskuter fordeler og ulemper ved bruk av COMET i forhold til (Rational) Unified Process for
DetaljerOppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1
Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring
DetaljerKravdokument Innholdsfortegnelse 1 Innledning 2 Bakgrunn og oversikt 3 Detaljerte krav 4 Systemsekvensdiagram
Kravdokument Innholdsfortegnelse 1 Innledning 1.1 Avgrensning 1.2 Definisjoner og forkortelser 1.3 Referanser 1.4 Oversikt over innholdet 2 Bakgrunn og oversikt 2.1 Use-case UML-diagram 2.1.1 Oversiktsdiagram
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:
DetaljerInnhold. INF1000 Høst Unified Modeling Language (UML) Unified Modeling Language (UML)
Innhold Unified Modelling Language UML INF1000 Høst 2015 Uke 8: Mer objektorientert programmering Siri Moe Jensen En ny type for-løkke Organisering av mengder av objekter HashMap Valg av representasjon
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!
DetaljerRollemodell. for. det norske kraftmarkedet
Rollemodell for det norske kraftmarkedet Versjon: 1.1.A Dato: 27. mai 2010 INNHOLD 1. INNLEDNING... 3 1.1 OM ROLLEMODELLEN... 3 1.2 EDIEL/EBIX... 3 1.3 NOEN UAVKLARTE PROBLEMSTILLINGER... 4 1.3.1 Nettområder
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:
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
DetaljerAMS-case. Eksemplifisering av modellbasert. tilnærming til design av brukergrensesnitt
AMS-case Eksemplifisering av modellbasert tilnærming til design av brukergrensesnitt Domenemodell Sentrale begreper og relasjoner Utgangspunkt for både oppgave- og dialogmodeller Mange muligheter kan undersøkes
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
DetaljerEksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus
// class Bygning Oppgave 1 System.out.println( Bolighus ); // class Bolighus Hva blir utskriften fra dette programmet? class Blokk extends Bolighus{ // class Blokk IN105subclassesII-1 Eksekveringsrekkefølgen
DetaljerAkseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer
Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : IN 219 Store programsystemer Eksamensdag : Lørdag 13. desember 1997 Tid for eksamen : 09.00-15.00 Oppgavesettet er på : 3 sider
Detaljer1. Modellering av objektorienterte systemer
Tore Berg Hansen 3.2.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. Resymé: I denne leksjonen skal vi se på hva som genererelt
DetaljerAgenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen
TDT4140: Kravinnhenting Torbjørn Skramstad IDI / NTNU Introduksjon til objektorientert design Agenda Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav Intervju Scenarier Etnografi Eksempel
DetaljerStatisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere
Statisk testing Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Hva er statisk testing Analyser som utføres på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene
DetaljerSlides made by Sommerville adapted by Letizia Jaccheri This lecture will be filmed
Chapter 5 System Modeling Letizia Jaccheri Norsk Professor Institutt for Datateknikk (IDI) Office 106, tel. (735)93469, letizia@idi.ntnu.no www.letiziajaccheri.org English Course home page http://www.idi.ntnu.no/emner/tdt4140/
DetaljerAP226 Use Case Diagram - TUL
AP226 Use Case Diagram - TUL Use Case Diagram Dette dokumentet inneholder det komplette use case-diagrammet for Tjenesteutviklingsløsningen. Figur 1 har en grafisk oversikt over alle aktører og use case.
DetaljerDRI 2001 Systemutviklingsarbeidet et overblikk Forelesning
Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet
DetaljerINF 5120 Modellering med objekter
INF 5120 Modellering med objekter Obligatorisk oppgave nr. 1 Gruppe 4 Problem: Det skal designes en kaffemaskin til bruk blant de ansatte hos en bedrift. Eieren av bedriften ønsker en enkel og billig maskin.
Detaljer