Noter til dm529 Jonas Nyrup 11. november 2011 Indhold 1 Kravdisciplinen: Kravmodellen og Indfangning af Krav 2 1.1 (ikke)-funktionelle krav...................... 2 1.2 Kravattributter........................... 2 1.3 Indfangning............................. 3 1.4 UP (unified process)........................ 4 2 Kravdisciplinen: Brugsmønstermodellen 4 3 Analysedisciplinen: analyseklasser 4 4 Analysedisciplinen: Brugsmønsterrealisering 5 5 Designdisciplinen: designmodellen 6 6 Implementeringsdisciplinen: konvertering fra design til kode 6 1
1 Kravdisciplinen: Kravmodellen og Indfangning af Krav 1.1 (ikke)-funktionelle krav Metamodel: En overordnet model for benyttede modeller Funktionelle krav (Det skal systemet kunne) Ikke-funktionelle krav (Hvor, hvornår, hvordan) Kvalitetskrav Betingelser FURPS (Benyttes ofte til organisering af krav) Functionality Useability Reliability Performance Supportability +Design requirement +Implementation requirement +Interface requirement +Operations requirement +Legal requirement Formelle krav: Brug syntaksten <ID> Systemet skal <funktion> Pas på generalisering: alle, altid, aldrig, ingen 1.2 Kravattributter MoSCoW (fortæller om prioritering - nøjes med brugbare attributter) Must have (skal med i systemet) Should have (Vigtige, men kan udelades) Could have (Valgfrie, hvis tiden tillader) Would have (Udskydes til senere versioner) RUP (Rational Unified Process) Attribut Værdi Betydning 2
Status Foreslået Godkendt Afvist Inkluderet Fordel (benefit) Kritisk Skal implementeres Vigtig Kan udelades, men ikke uden at påvirke brugbarhed Nyttig Kan udelades, uden at påvirke systemets antagelighed Indsats (effort) Risiko Høj Medium Lav Estimat af tids- og resursebehov Stabilitet Høj Sandsynligheden for at kravet vil ændres Medium Lav Version 1.3 Indfangning Interview Den produkt-version som kravet skal være implementeret i Vær er et neutralt sted som f.eks. en café - så begge er afslappede og åbne Stil ikke ledende spørgsmål Stil ikke ja/nej-spørgsmål Udelad tanker om et komplet system, du skal finde krav Lyt og lær - det er kunden, der skal snakke Tålmodighed - Et godt interview er grundlaget for et godt program Spørgeskemaer er farlige Brug evt. workshop/brainstorming 3
1.4 UP (unified process) Kravdisciplinen har mest betydning i Inception- og Elaboration-faserne i UP Iterativ: Store problemer deles op i mindre letløselige problemer Inkrementel: Løsninger (iterationer) bygger videre på hinanden. 2 Kravdisciplinen: Brugsmønstermodellen Aktører: Aktørbeskrivelse Aktørgeneralisering Brugsmønstre: Brugmønsterdiagram Brugsmønsterspecifikation Main flow / alternative flows Brugsmønstergeneralisering «include» «extend» UP er brugmønsterstyret: Brugmønstre bruges direkte i udviklingen. 3 Analysedisciplinen: analyseklasser Analysedisciplin: Analyse er afdækning af analyseklasser, deres indbyrdes strukturer og interaktioner gennem Analyse af et brugsmønster" 4
Navneordsanalyse på brugsmønstre for at finde klasser Analysemodel: (analyse)klassediagram Attributter Associationer: relation mellem to klasser Multiplicitet: det antal objekter der kan deltage i en relation på ethvert tidspunkt Generalisering: Generel klasse med egenskaber og adfærdsmønstre, som er fælles for subklasser Pakker: gruppering af klasser i logiske kategorier. En pakke kan erstatte en mængde klasser i klassediagram Objekt: en instans af en klasse. På en klasse knytter sig attributter og metoder. En klasse beskriver (oftest) en aktør eller en genstand i problemdomænet. I UP er vi aktive i Elaborations-fasen. 4 Analysedisciplinen: Brugsmønsterrealisering UP-aktiviteten analyse af brugsmønstre er der hvor man laver brugsmønsterrealisering, der er en aktivitet, som opretter en del af det dynamiske over af systemet. Brugmønsterbeskrivelse: Tekstuel beskrivelse af systemsekvensdiagram Systemsekvensdiagram interaktion mellem bruger og system Sekvensdiagram Interaktioner mellem livslinier «create», «destroy» (lav/dræb objekter) if, loop synkron (ufyldt) pil - implicit svarpil asynkron (ikke-udfyldt) pil - kræver eksplicit svarpil (Side 247) Operator: operationer til at kontrolellere flow et (side 257) Systemfunktionskontrakt Knytter sig til sekvensdiagram Beskriver metoderne med ansvar, formål... 5
I brugsmønsterrealisering i Designdiciplinen tager højde for public/private og datatyper 5 Designdisciplinen: designmodellen Fastlægge hvordan funktionaliteten beskrevet i analyse-modellen skal implementeres. Designklassediagram Putter private/public, datatyper på variabler, input-/ouput-datatyper på metoder Aggregering: splitte klasser op i mindre klasser (pc og printer) Komposition: Uløseligt sammenbundne klasser (tv med indbygget video) Høj samhørighed Lav kobling Interface: kontrakt om hvilke metoder og attributter klasser skal indeholde. Designsekvensdiagram Putter datatyper på variabler, input-/ouput-datatyper på metoder UP: ligger midt mellem Elaboration og Konstruktion 6 Implementeringsdisciplinen: konvertering fra design til kode At konvertere designmodellen til et kørbart program Laver klasser, metoder, attributter i forhold til designklassediagram 6