Transcript pps-4
OOMPA 2000
Föreläsning 4
Utvecklingsprocessen en översikt.
Lite om kravspecifikationer.
CRC-kort.
XP som exempel på lättviktigare process.
previous
next
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Utvecklingsmetoder ...
• Problem
Svårt att
utveckla system
kostnad
– Svårt att utveckla system
– 80% underhåll
– Vi vill ha formalism fast enkel och
användbar
– Kommunikation mellan inblandade
– Många anser att kostnaden för
krav
design
test
förändring av ett system ökar
implemproduktion
analys
exponentiellt över tiden.
entation
Fast inte säkert sant med dagens metoder.
• 70-talet
Strukturerad
programmering
– Flödesdiagram
– Strukturerad programmering
– Top-down, bottom-up och middle-out
• Flera objektorienterade metoder blev populära på 80-talet och dominerar idag
Flera metoder
previous
– OMT, ObjectOry, Booch, Shlaer-Mellor, Coad-Yourdon
– ...
next
2
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Design och utveckling
• Vilken typ av projekt kan vara avgörande för hur man
går tillväga
– Programmera i det lilla
Få utvecklare
• kod skapas av en eller få programmerare. En enskild person kan ha
överblick och vara insatt i alla delar av projektet.
• huvudproblem (mjukvara): designa och utveckla algoritmer
– Programmera i det stora
Många utvecklare
previous
next
• mjukvaran tas fram av ett stort team. Vissa personer kan specificera
eller designa andra kan koda vissa komponenter,
slutintegration/applikationen görs kanske av en tredje grupp, osv. Ingen
person har möjlighet att sätta sig in alla delar av projektet.
3
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Systemutveckling-mjukvaruindustri i kris
• "Om man frågar kunden efter vad han vill så skulle vi
börja koda med en gång"
• Endast en liten del av alla levererade system har all
önskad funktionalitet
• Dom flesta projekt förlitar sig på experter som har gjort
samma sak tidigare
• Vi söker en standard som löser alla problem
previous
next
4
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Systemutveckling-Processen, vad ger den?
• En välbeskriven arbetsprocedur med en organiserade
aktiviteter och information
• Ett av flera nödvändiga verktyg för utveckling
• Vi får
–
–
–
–
–
previous
next
Kontroll
Tillförlitliga resultat
Oberoende av fysisk organisation
Reducerar tid
Säkrare förutsägelser
5
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Varför används inte utvecklingsprocesser oftare
• Typiska kommentarer och påståenden
–
–
–
–
–
–
previous
next
Datorvetenskapen relativt ung
Systemutveckling är en konst
Systemutveckling är väldigt svårt
Alla vet hur man skriver ett program
Kunden är inte beredd att betala för det hela
....
6
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Systemutveckling-Processen, hur ser den ut?
Nya eller modifierade krav
previous
next
Systemutveckling
Ny version
av systemet
7
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Utvecklingsprocess typiskt tillvägangångsätt
Krav
• Kravanalys - beskriv och validera vad systemet skall
göra
Analys
• Analys - identifiera systemets struktur så att systemet är
enkelt att modifiera om kraven förändras
Design
• Design - beskriv hur systemet skall realiseras
Implementation
Test
previous
• Implementation - implementera systemet och utför
enhetstester
• Testning - verifiera systemet
next
8
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Proceduren
• Hitta potentiella aktörer
– Namnge och gör kortfattad beskrivning av varje aktör
– Begränsa systemet
• Sammanställ gloslista (så att vi kan enas om vokabulär)
• För varje aktör: Hitta nödvändiga användningsfall
– Namnge och gör kortfattad beskrivning av varje användningsfall
• Granska aktörer och användningsfall och iterera
– Missade aktörer eller användningsfall? Duplikat?
• Identifiera gemensamma delar, strukturera modellen, iterera
• Beskriv varje användningsfall
• Granska beskrivningarna och iterera
– Missad eller felaktig funktionalitet?
• Granska, validera och godkänn modellen
previous
next
9
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Analysfas
• Vad är analys?
– I analysen undersöker vi systemets krav och försöker att omforma och
strukturera dem
• Varför analys?
– Vi vill få en mer precis förståelse av kraven för att åstadkomma en
beskrivning som är enkel att underhålla och hjälper oss att skapa en
struktur för hela systemet
• Vad skiljer analys från (nästa steg) design och implementation?
– (Efter Rational Unified Process (RUP)) I design måste vi, till skillnad
från i analys, forma systemet så att det lever upp till alla krav i form av
Ingen kristallklar beskrivning
kodkomponenter, ta hänsyn till prestanda- och distributionskrav, visa hur
detta heller!
systemet skall optimeras för att klara av kraven, osv.
previous
next
10
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
...
• Vilket språk används?
– RUP
• Jo, utvecklarens
– därför kan vi införa mer formella beskrivningar och därmed får vi
möjlighet att i mer detalj resonera om systemet
– OCTOPUS (en realtidsmetod)
• Jo, domänens
– troligen därför att hjälpa till att hålla det hela på en abstrakt nivå, ha
bra (och naturlig/enkel) spårbarhet och undvika att olika delsystem
använder olika namn för samma objekt
previous
next
11
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
...
• Speciella problem/frågeställningar
– Vilken precision har beskrivningarna?
• Dom skall vara på en konceptuell översiktlig nivå, där tex bara
viktiga attribut och metoder visas i klassdiagrammen.
• I huvudsak används klassdiagram och avsikten är mer att förstå
systemet och ge en övergripande struktur än att beskriva hur det skall
implementeras
– Hur omfattande är analysen?
• 1:5-regeln som säger att analysen är en femtedel så omfattande som
designen. Jacobson, Booch och Rumbaugh"The Software
Development Process" sidan 177.
previous
next
12
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Från användningsfall till analys
• Det finns många olika strategier för att hitta klasser, objekt,
associationer och andra relationer i analysfasen
– tex kan man titta på substantiv, verb och adjektiv i kravspecifikationen
– RUP och även OCTOPUS förordar en användningsfallcentrerad
utgångspunkt
• via användningsfallen hittar vi aktörerna och viktig (yttre) funktionalitet
• kandidater till andra objekt, attribut och relationer genom att studera kraven
• vi kan sedan också studera scenarier, konstruera samarbetsdiagram och
sekvensdiagram för att se om vi missat några objekt, relationer eller
funktionalitet
• fast med användningsfallen har vi identifierat dom yttre ramarna
• Spårbarhet
– En analysmodell av en användningsfallsmodell skall kunna spåras
• genom att lämpligt dokument upprättas
previous
next
13
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
En jämförelse mellan användningsfall och analys, enligt RUP
Användningsfallsmodell
Analysmodell
•
•
•
Använd kundens språk
Extern vy av systemet
Struktureras mha användningsfall: ger
struktur till den externa vyn
Används primärt som kontrakt mellan
kund och utvecklare
Kan innehålla redundans,
inkonsekventa delar osv bland kraven
Fångar funktionaliteten för systemet
•
•
•
Definierar användningsfall som
analyseras vidare i analysmodellen
•
•
•
•
•
previous
next
•
•
•
Använd utvecklarens språk
Intern vy av systemet
Struktureras mha stereotypiska klasser:
ger struktur till den interna vyn
Används primärt av utvecklare för att
förstå hur systemet skall formas
Skall inte innehålla redundans,
inkonsekventa delar osv bland kraven
Ger en skiss över hur funktionaliteten
skall realiseras (fungerar också som ett
första designsteg)
Definierar realisering av
användningsfallen
14
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Alltså: Vad är (objektorienterad) analys?
• Den tidiga fasen i systemutvecklingen då en abstrakt modell av
systemet skapas, utan att gå in på detaljer i den tekniska
implementationen
• En modell av centrala objekt och relationer mellan objekten
• Analysen utförs utan hänsyn till tekniska lösningar eller
begränsningar
• Syftet är att skapa en förståelse för den verksamhet systemet skall
hantera
• Används som grund för att i en designfas konstruera systemet i
detalj och välja teknisk lösning
previous
next
15
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Analys: vanliga aktiviteter
• Insamla underlag
– kravspecifikationer, önskemål, beskrivningar av verksamheten eller befintligt
system, intervjuver. Problemdomän definieras
• Definiera användningsfall
– dvs hur systemet kommer användas
• Sök objektkandidater
– tex mha CRC-kort eller annan brainstormingliknande teknik
• Klassificera objekt
– klassnamn, ansvarsområde och eventuellt karaktäristiska attribut och metoder
• Relationer mellan objekt
– mha klass- och objektdiagram
• Slutdokumentation av analysfasen
– skrivbordstest där olika användningsfall gås igenom, relationer mellan klasser och
objekt testas. Valda namn på klasser värderas. Dokumenteras mha grafiska diagram
med kompletterande text.
previous
next
16
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Design
• Vad är design? Vad säger några i väldig förenkling:
– Enligt RUP
• I design formar vi systemet så att det lever upp till alla krav. Fysisk
modell. Specifik för viss implementation.
– Enligt OCTOPUS
• Målet är att systematiskt ta analysmodellen och skapa en beskrivning
av hur systemet skall fungera på en abstraktionsnivå närmast över ett
programmeringsspråk. Vi skapar en explicit modell och beskriver hur
objekt interagerar med varandra.
– Enligt Douglass (som är med om att utveckla realtids-UML)
• Definierar lösningar som optimerar applikationen och tar hänsyn till
speciella krav och mål i projektet samtidigt som den inte bryter mot
analysens beskrivningar. Design handlar alltid om optimering
previous
next
17
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Perspektiv
• Konceptuellt
– I detta perspektiv ritar man diagram över koncept i domänen. Dessa
koncept avbildas ofta på klasser som implementerar dem, men ofta är så
inte fallet.
– En konceptuell modell ritas med liten eller ingen hänsyn till den mjukvara
som skall användas vid implementationen
• Specifikations
– I detta perspektiv tittar vi i första hand på gränssnitten för mjukvaran, inte
implementationen. Vi tittar snarare på typer än klasser
• Implementations
– I detta perspektiv har vi verkligen klasser och implementationen görs tydlig
previous
next
18
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Processen
• bestäm strategi
och mål med projektet
• kalkylera kostnader
Påbörjande
konstruera systemet i en serie
av iterationer
Utformande
• samla detaljerade krav och gör analys och
design på en hög nivå för att konstruera en
grundarkitektur och planera konstruktionen.
• analysera risker (krav, teknik, skicklighet och
politiska)
previous
next
Konstruktion
Överföring
testa, prestandaoptimera,
träna användare
19
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Vattenfallsmodellen
Traditionell idealiserad modell av utvecklingsprocessen
Analys
Design
Implementation
Testning
Underhåll
previous
next
20
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Boehms
spiralmodell
previous
next
21
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Utvecklingsprocessen, olika konfigurationer
Implementation
Kravanalys
Design
Implementation
Testning
Kravanalys
Analys
previous
next
Design
Implementation
Testning
22
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Olika systemmodeller
• En modell är en komplett systemspecifikation från en
viss synvinkel och en viss abstraktionsnivå
• Olika typer av modeller
– Användningsfallsmodell - en beskrivning av systemets
funktionalitet och dess kommunikation med omgivningen
– Analysmodell - en beskrivning av systemets ideala struktur
– Designmodell - en beskrivning av det implementerade
systemets struktur
– Kodmodell - den mest detaljerade beskrivningen av ett system
(källkoden)
– Testmodell - en beskrivning av dom tester som skall göras
respektive deras resultat
previous
next
23
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Exempel-lagersystem: användningsfall
previous
next
24
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
...analysmodell...
previous
next
25
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
...designmodell...
previous
next
26
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
...kod- och testmodell
previous
next
27
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Varför flera modeller?
• Fokusera på ett problem
• Olika behov av information
Observera att alla modeller beskriver samma system
men från olika synvinklar och med olika abstraktionsgrad
previous
next
28
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Modeller är dokument
• Varje modell dokumenteras
med hjälp av flera olika
sorters dokument, som
–
–
–
–
–
–
–
previous
next
översiktsdokument
detaljerad beskrivning
diagram
designregler och beslut
produktbeskrivningar
spår- och förändringskartor
....
29
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Exempel: RUP, processen
previous
next
30
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., faser
previous
next
31
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., användningsfall
previous
next
32
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., beskrivning
previous
next
33
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., analysens klasser som deltar i en realisering av ta ut
pengar
previous
next
34
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., användningsfalls- och analysmodell
previous
next
35
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., samarbetsdiagram: ta ut pengar
previous
next
36
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., olika modellers beroende
previous
next
37
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., bankomaten
previous
next
38
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
... , klassdiagram i design
previous
next
39
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., sekvensdiagram
previous
next
40
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
..., delsystem
previous
next
41
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
CRC-kort (Class-Responsibility-Collaborators)
• Av Cunningham och Beck under mitten av 80-talet.
– Togs fram för att lära ut objektorienterad programmering
– För att ge komponenter fysisk presentation
• Bra vid ”brainstorming”/spånande
• Process:
– Man skriver ner klasser på kort. Selektera inte nu utan skriv ner alla förslag
– Efter ett tag när man har ett (tillräckligt) antal klasser väljer man ut ”dom
bästa”
– Sedan går man över till att identifiera ansvarsområden och beteende för
varje klass
– Sedan identifieras samarbete klasser emellan
– Man försöker också ordna klasserna hierarkiskt samt identifiera abstrakta
klasser
previous
next
42
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
…
• Ett blankt CRC-kort
Klassnamn
Ansvar
previous
next
”Samarbetspartners”
43
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
CRC: Exempel
• Grafiskt objekt som har en metod för att rita "sin" figur
och ett delobjekt som också skall ritas ut
GrafisktObjekt
Håller grafisk beskrivning i form av en en metod som
beskriver den aktuella presentationen
Skall kunna innehålla ett annat grafiskt objekt med
samma API som det själv
Det skall gå att lägga in ett nytt eller ta bort det
aktuella grafiska delobjektet
Vid utritning skall det grafiska objektet också se till
att delobjektet ritas ut
previous
next
GrafisktObjekt
44
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Exempel: register av studenter
Personregister
Hanterar ett register av personer
Personer kan läggas in eller tas bort
Kan sortera registret efter namn, födelsenummer
respektive adress
Person
Person
superklasser: Object
subklasser: Student
Hanterar information om en person: namn,
adress, telefon, födelsenummer
Student
superklasser: Person
subklasser:
Hanterar email och kursstatus
previous
next
45
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
CRC: Publicist och prenumerant
Publicist
Håller intressant
information/data
Meddelar prenumeranter om
informationen ändras
Prenumerant
Prenumerant
Prenumererar på intressanta förändringar hos en
eller flera publicister
Implementerar en strategi för att ta hand om
meddelanden om förändringar från publicisten
previous
next
Publicist
46
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
"Klassiska" MVC
Vy
Visualisera
modellen
Transformera
koordinater
Kontroll
Modell
Kontroll
Tolka inmatning
Vy
från användaren Modell
Fördela kontroll
Modell
Problemrelaterad information
Skicka ut meddelanden om
förändringar
previous
next
47
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Hur hitta klasser och objekt?
• Vi har bla diskuterat användningsfall och scenarier som
sätt att identifiera vad ett system skall göra
– Från dessa beskrivningar kan man hitta en del objekt i
systemet
• Vi har också diskuterat CRC-kort som ett sätt att spåna
fram klasser, ansvar och relationer
• Senare i kursen kommer vi också diskutera
designmönster som ett sätt att applicara återanvända och
identifiera framgångsrika strukturer på olika
designproblem
previous
next
48
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Ett annat sätt är: Wirfs-Brocks nominalfras-strategi
• Läs och förstå kravdokumentet. Målet är att hitta en
modell som väldigt väl avspeglar den aktuella
problemdomänen
• Läs igenom dokumentet igen. Titta speciellt efter
nominalfraser. Skapa en preliminär lista av dessa fraser
och ändra alla plural till singular
• Dela nominalfraserna i tre kategorier: definitivt objekt,
nonsensobjekt och möjliga objekt
• Strunta i nonsenobjekten
• Diskutera "möjliga objekt" och placera vart ett av dom i
någon av dom andra två kategorierna
previous
next
49
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Exempel
• Vi skall bygga ett datorsystem för ett
universitetsbibliotek
• Några krav
– Böcker och tidningar. Biblioteket innehåller böcker och
tidningar. Det kan finnas flera kopior av en given bok. Vissa
böcker kan bara lånas på korttidslån. Alla andra böcker kan
lånas av en lånekortsinnehavare i tre veckor. En
lånekortsinnehavare kan normalt låna sex saker samtidigt, men
anställda kan låna upp till 12 saker på en gång. Endast
anställda får låna tidningar.
– Lån. Systemet måste hålla reda på när böcker och tidningar är
lånade och tillbakalämnade under reglerna som beskrevs ovan.
previous
next
50
Utvecklingsprocessen. Kravspecifikationer. CRC-kort.
Nyare (kontroversiell?) lättviktig metod för systemutveckling
• eXtreme Programming (XP), av Kent Beck, inne och hett
• Tillvägagångsätt (12 grundpelare)
• Planeringsspel
planera snabbt förutsättningarna för
nästa release; prioritera, teknikkrav
• Små releaser
släpp nya versioner ofta
• Metafor
hitta en enkel och bra metafor
• Enkel design
gör designen så enkel som möjligt
• Testa
next
två programmerare per maskin
• Kollektivt ägande av koden
alla äger och kan ändra i koden
• Kontinuerlig integration
integrera och bygg systemet flera
gånger per dag
• 40-timmarsvecka
jobba som regel inte mer än 40
timmar per vecka
testa koden kontinuerligt. Måste
lyckas innan utvecklingen går vidare.
Skriv testerna först!
• Inkludera en "kund" i teamet
strukturera om ofta; ta bort onödig
kod, förenkla osv
förenklar kommunikation
• Omstrukturera ("refactoring")
previous
• Parprogrammering
inkludera en "riktig användare" på
full tid
• Följ kodstandard
51