OOMPA 2000 Föreläsning 4 Utvecklingsprocessen en översikt. Lite om kravspecifikationer. CRC-kort. XP som exempel på lättviktigare process.

Utvecklingsmetoder ... Problem 70-talet 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 förändring av ett system ökar exponentiellt över tiden. Fast inte säkert sant med dagens metoder. 70-talet Flödesdiagram Strukturerad programmering Top-down, bottom-up och middle-out Flera objektorienterade metoder blev populära på 80-talet och dominerar idag OMT, ObjectOry, Booch, Shlaer-Mellor, Coad-Yourdon ... kostnad Svårt att utveckla system krav design test analys implem- entation produktion Strukturerad programmering Flera metoder

Design och utveckling Vilken typ av projekt kan vara avgörande för hur man går tillväga Programmera i det lilla 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 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. Få utvecklare Många utvecklare

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

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 Kontroll Tillförlitliga resultat Oberoende av fysisk organisation Reducerar tid Säkrare förutsägelser

Varför används inte utvecklingsprocesser oftare Typiska kommentarer och påståenden 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 ....

Systemutveckling-Processen, hur ser den ut? Nya eller modi- fierade krav Ny version av systemet Systemutveckling

Utvecklingsprocess typiskt tillvägangångsätt Kravanalys - beskriv och validera vad systemet skall göra Analys - identifiera systemets struktur så att systemet är enkelt att modifiera om kraven förändras Design - beskriv hur systemet skall realiseras Implementation - implementera systemet och utför enhetstester Testning - verifiera systemet Krav Analys Design Implemen- tation Test

Hitta potentiella aktörer 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

Analysfas Vad är analys? Varfö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 kodkomponenter, ta hänsyn till prestanda- och distributionskrav, visa hur systemet skall optimeras för att klara av kraven, osv. Ingen kristall- klar beskrivning detta heller!

... Vilket språk används? RUP OCTOPUS (en realtidsmetod) 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

... 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.

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

En jämförelse mellan användningsfall och analys, enligt RUP Användningsfallsmodell 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 Analysmodell 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

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

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.

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

Perspektiv Konceptuellt Specifikations Implementations 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

Processen Påbörjande Utformande Konstruktion Överföring bestäm strategi och mål med projektet kalkylera kostnader konstruera systemet i en serie av iterationer Påbörjande Utformande Konstruktion Överföring 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) testa, prestandaoptimera, träna användare

Vattenfallsmodellen Traditionell idealiserad modell av utvecklingsprocessen Analys Design Implementation Testning Underhåll

Spiralmodellen Boehms spiralmodell

Utvecklingsprocessen, olika konfigurationer Implementation Kravanalys Design Implementation Testning Kravanalys Analys Design Implementation Testning

Olika typer av modeller 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

Exempel-lagersystem: användningsfall

...analysmodell...

...designmodell...

...kod- och testmodell

Fokusera på ett problem Olika behov av information 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

Modeller är dokument Varje modell dokumenteras med hjälp av flera olika sorters dokument, som översiktsdokument detaljerad beskrivning diagram designregler och beslut produktbeskrivningar spår- och förändringskartor ....

Exempel: RUP, processen

..., faser

..., användningsfall

..., beskrivning

..., analysens klasser som deltar i en realisering av ta ut pengar

..., användningsfalls- och analysmodell

..., samarbetsdiagram: ta ut pengar

..., olika modellers beroende

..., bankomaten

... , klassdiagram i design

..., sekvensdiagram

..., delsystem

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

… Ett blankt CRC-kort Klassnamn Ansvar ”Samarbetspartners”

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 GrafisktObjekt

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 Hanterar information om en person: namn, adress, telefon, födelsenummer Person superklasser: Object subklasser: Student Hanterar email och kursstatus Student superklasser: Person subklasser:

CRC: Publicist och prenumerant 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 Publicist

"Klassiska" MVC Vy Kontroll Modell Visualisera modellen Transformera koordinater Kontroll Modell Kontroll Tolka inmatning från användaren Fördela kontroll Vy Modell Modell Problemrelaterad information Skicka ut meddelanden om förändringar

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

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

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.

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 testa koden kontinuerligt. Måste lyckas innan utvecklingen går vidare. Skriv testerna först! Omstrukturera ("refactoring") strukturera om ofta; ta bort onödig kod, förenkla osv Parprogrammering 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 Inkludera en "kund" i teamet inkludera en "riktig användare" på full tid Följ kodstandard förenklar kommunikation