Systemudvikling Flashcards
Hvad vil det sige at en systemudviklingsmodel er iterativ?
At man bevæger sig mellem processens delelementer flere gange, og dermed genbesøger de samme processer igen og igen.
Hvad er fordelen ved en iterativ tilgang til systemudvikling?
At det er nemmere at løse eventuelle problemer eller fejl, og at det kan lade sig gøre at skifte kurs hvis virksomhedens krav ændrer sig undervejs.
Hvad er UP forkortelse for?
Unified Process
Hvad kendetegner UP?
En iterativ systemudviklingsmodel. Use case dreven. Risikodreven.
Hvad vil det sige at UP er risikodreven?
Udviklingen har hele tiden riscici for øje. Derfor fastlægges eks. arkitekturen hurtigt i processen.
Hvad er modsætningen til et iterativt udviklingsforløb?
Et sekventielt forløb hvor man bevæger sig fra trin til trin. Og kun besøger hvert trin én gang.
Hvad er det primære formål med en IT-forundersøgelse?
At kortlægge virksomhedens nuværende aktiviteter og processer.
Hvad er formålet med en medarbejder-mål tabel?
At kortlægge virksomhedens nuværende arbejdsopgaver, og hvem der udfører dem, på baggrund af et interview med virksomheden.
Hvad er formålet med et aktivitetsdiagram/workflow?
At visualisere virksomhedens nuværende arbejdsproces i et happy days format.
Hvad tager aktivitetsdiagrammet udgangspunkt i?
Målene fra medarbejder-mål tabellen. Målenes trin medtages ikke.
Hvad betyder det at et artefakt udarbejdes i et “happy days” format?
At det tager udgangspunkt i et perfekt scenarie, uden alternative flows.
Hvad er mock-ups?
Primitive og ikke-funktionelle visualiseringer af brugergrænsefladen på det system kunden skal have.
Hvad er formålet med en “tænke-højt-test”?
At få en brugers umiddelbare indtryk af systemet. Her bruges ofte mock-ups eller andre prototyper.
Hvad er en use case?
Et funktionelt krav til et IT-system. En beskrivelse af en funktion i systemet fra aktørens perspektiv.
Hvad er formålet med et use case diagram?
At visualisere de funktionelle krav til systemet, samt hvilke aktører der kan tilgå de forskellige funktionaliteter.
Hvad er en brief use case beskrivelse?
En kort og præcis beskrivelse i et happy days format.
Hvad er en casual use case beskrivelse?
En kort og præcis beskrivelse der medtager alternative flows der er meget hyppigt forekomne.
Hvad er en fully dressed use case beskrivelse?
En detaljeret og nøjagtig beskrivelse af hvert trin i en use case. Medtager alle alternative flows og eventuelle særlige forretningskrav.
Hvorfor prioriterer man på use cases?
For at finde ud af hvilke der er vigtigst at implementere først.
Hvilke parametre prioriterer man use cases på?
Risiko, dækningsgrad og forretnings kritikalitet.
Hvad er formålet med domænemodellen?
At vise et problemfelt fra virkeligheden. Samt at definere informationskravene i systemet; altså hvilke data der skal lagres.
Hvad kendetegner domænemodellen?
Den viser et udsnit af virkeligheden. Den består af konceptuelle klasser - klasser der afbilleder data fra virkeligheden.
Hvordan udvælges klasser til domænemodellen?
Med en kandidatliste der finder inspiration i navneord fra tidligere artefakter.
Hvad siger multiplicitet i domænemodellen noget om?
Hvor mange objekter af hver klasse der kan eksistere.
Hvad er formålet med et systemsekvensdiagram?
At visualisere input og output mellem bruger og system.
Hvad kendetegner et systemsekvensdiagram?
Det udarbejdes i et “happy days” format. Laves altid på engelsk.
Hvad er formålet med operationskontrakter?
At beskrive de ændringer der forventes når en operation er udført.
Hvad kendetegner operationskontrakter?
Udføres på state ændrende input i systemsekvensdiagrammet; er der oprettet eller slettet en instans? Er der sket en ændring eller en tilskrivning af værdi? Er der oprettet eller brudt associeringer?
Hvad er formålet med et interaktionsdiagram?
At visualisere objektinteraktionen i et system for en given use case.
Hvad er formålet med et designklassediagram?
At vise alle systemets klasser, attributter, constructors og metoder, samt associeringer mellem designklasserne.
Hvordan kan interaktionsdiagrammet valideres?
Ved at tjekke om post-conditions i operationskontrakterne er opfyldt.
Hvad er et kommunikationsdiagram?
Et interaktionsdiagram i en komprimeret udgave.
Hvad er et sekvensdiagram?
En interaktionsdiagram i en mere “udvidet” udgave end kommunikationsdiagrammet.
Hvad betyder den fuldt-optrukne pil i designklassediagrammet.
At to designklasser associeres så længe de lever.
Hvad betyder den stiplede pil i designklassediagrammet?
At to designklasser associeres ved et bestemt metodekald, hvorefter forbindelsen “dør”.
Hvad er formålet med test helt generelt?
At undersøge om systemet lever op til kravene, samt udbedre fejl og mangler.
Hvad er unit test?
En test af et lille udsnit kode.
Hvad er integrationstest?
Test af om flere stykker kode snakker korrekt sammen.
Hvad er systemtest?
Test af hvorvidt systemet lever op til kravene. Både de funktionelle og ikke-funktionelle.
Hvad er en acceptance test?
En test som udføres af kunden og som gerne skal udmunde i kundens accept af, at systemet opfylder kravene.
Hvad viser billedet?
En generalisering i en domænemodel.
Hvad viser billedet?
The role pattern (rolle mønstret) i en domænemodel.
Hvad viser billedet?
Et item-descripter mønster i domænemodellen.
Hvad viser billedet?
Et aftalemønster i en domænemodel.
Hvad viser billedet?
En relationel model (relationel database skema).
Forklar følgende mapping fra en konceptuel klasse til skemaer i den relationelle model. (Primære og fremmede nøgler, relation, osv.) Hvad er det for et problem der løses?
Den konceptuelle klasse Employee indeholder en multi-valued attribut (education). Derfor laves endnu en relation (EmployeeEducation) hvor education attributten vises. I denne relation laves der en sammensat primærnøgle der består af education attributten og primær nøglen fra Employee relationen - som desuden også er en fremmednøgle der peger på Employee id.
Forklar følgende mapping fra en konceptuel klasse til skemaer i den relationelle model. (Primære og fremmede nøgler, relation, osv.) Hvad er det for et problem der løses?
Den konceptuelle klasse Employee indeholder en composite attribut (address). Derfor laves endnu en relation (Address) hvor address attributten splittes i alle dens delelementer. Relationens fremmednøgle peger på Employee relationens primær nøgle (id).
Hvad er den typiske måde at mappe en one-to-many associering fra domænemodellen til den relationelle database?
I tabellen på “mange-siden” tilføjes primær nøglen fra “en-siden” som attribut. Denne bliver fremmednøglen der peger på primærnøglen på “en-siden”.
Hvad er den typiske måde at mappe en one-to-one associering fra domænemodellen til den relationelle database? Og hvilken generel regel om mapping af relationelle databaser er vigtig at overveje i den forbindelse?
Den ene relation får tilføjet den anden relations primær nøgle som attribut. Denne bliver samtidig en fremmednøgle der peger på den anden tabels primær nøgle. Hvilken der referer til den anden afhænger af, om det ene eller det andet giver risiko for flest NULL værdier - hvilket er vigtigt for at mindske antallet af NULL værdier i databasen.
Hvad er den typiske måde at mappe en many-to-many associering fra domænemodellen til den relationelle database?
Der laves en ny “join” relation der får primær nøglerne fra begge af de to relationer som attributter. Disse to attributter bliver en sammensat primær nøgle. Hver attribut er desuden en fremmed nøgle der peger på hver af de oprindelige relationers primær nøgle. Hvis der er behov for flere attributter i join relationen må de gerne tilføjes.
Billedet viser et eksempel på mapping fra domænemodel til relationel database. Forklar hvad der er gjort og hvorfor.
Viser mapping af en many-to-many associering i domænemodellen. Der er lavet tre relationer, hvoraf en af dem er en “join relation” der har de to øvrige relationers primær nøgler som attributter. Disse danner tilsammen en sammensat primær nøgle. De er desuden hver i sær fremmed nøgler der peger tilbage på henholdsvis Customer og Account.
Hvilke tre fremgangsmåder findes der til mapping af generaliseringer fra domænemodellen til den relationelle model?
Fremgangsmåder: “table-each”, “pull-down”, “pull-up”.
Hvordan mappes en generalisering fra domænemodellen til den relationelle model med fremgangsmåden “table-each”? Hvad er ulemperne ved fremgangsmåden?
Hver klasse (både super- og subklasser) får sin egen relation. Primærnøglerne i subrelationerne er også fremmednøgler der peger på superrelationen. I superrelationen defineres en “type” attribut der viser hvilken subrelation den enkelte række er associeret til.
Ulemper: Flere tabeller skal joines for at udføre basale operationer (CRUD).
Hvordan mappes en generalisering fra domænemodellen til den relationelle model med fremgangsmåden “pull-down”? Hvad er ulemperne ved fremgangsmåden?
Alle subklasser får hver sin relation. Der laves ikke en relation for superklassen. I stedet trækkes superklassens attributter ned i hver af subrelationerne.
Ulempe: duplikering af superklassen attributter. Gør det mere komplekst at vedligeholde eller foretage ændringer i superklassens attributter.
Hvordan mappes en generalisering fra domænemodellen til den relationelle model med fremgangsmåden “pull-up”? Hvad er ulemperne ved fremgangsmåden?
Der laves en relation for superklassen men ingen for subklasserne. I stedet trækkes alle subklassernes attributter op i relationen for superklassen.
Ulempe: relationen vil indeholde mange NULL værdier.
Forklar billedet ifht. principperne omkring high cohesion og low coupling.
Figurerne i kasserne repræsenterer et bestemt ansvarsområde. Når de fordeles i kasserne efter figurtype, sikres high cohesion. Stregerne imellem kasserne repræsenterer afhængigheden mellem dem. Med færre forbindelser sikres low coupling.
Hvilket problem viser billedet? Og hvad er løsningen på problemet?
Der opnås spurious tupler ved join af to tabeller, hvilket betyder at join tabellen forårsager et brud på data integriteten ved visning af forkerte data. Løsningen er normalisering af databaseskemaet for at sikre kvaliteten.
