2203$ ) UHOlVQLQJ. Utvecklingsprocessen en översikt. Lite om kravspecifikationer. CRC-kort. XP som exempel på lättviktigare process.

Transkript

1 2203$ ) UHOlVQLQJ Utvecklingsprocessen en översikt. Lite om kravspecifikationer. CRC-kort. XP som exempel på lättviktigare process. previous next Utvecklingsmetoder... Problem Svårt att Svårt att utveckla system 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 krav exponentiellt över tiden. Fast inte säkert sant med dagens metoder. 70-talet kostnad design analys Strukturerad Flödesdiagram programmering Strukturerad programmering Top-down, bottom-up och middle-out Flera objektorienterade metoder blev populära på 80-talet och dominerar idag Flera metoder OMT, ObjectOry, Booch, Shlaer-Mellor, Coad-Yourdon... implementation previous next 2 test produktion Björn Eiderbäck

2 Få utvecklare 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 Många utvecklare 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. previous next 3 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 Björn Eiderbäck

3 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 previous next 5 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... previous next 6 Björn Eiderbäck

4 Systemutveckling-Processen, hur ser den ut? Nya eller modifierade krav Systemutveckling Ny version av systemet previous next 7 Krav Analys Design Implementation Test 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 previous next 8 Björn Eiderbäck

5 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 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 Ingen kristallklar beskrivning detta heller! 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. previous next 10 Björn Eiderbäck

6 ... 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 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 Björn Eiderbäck

7 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 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 previous next 14 Björn Eiderbäck

8 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 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 Björn Eiderbäck

9 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 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 Björn Eiderbäck

10 Processen 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 previous next 19 Vattenfallsmodellen 7UDGLWLRQHOOLGHDOLVHUDGPRGHOODYXWYH NOLQJVSUR HVVHQ Analys Design Implementation Testning Underhåll previous next 20 Björn Eiderbäck

11 Boehms spiralmodell previous next 21 Utvecklingsprocessen, olika konfigurationer Implementation Kravanalys Design Implementation Testning Kravanalys Analys Design Implementation Testning previous next 22 Björn Eiderbäck

12 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 Exempel-lagersystem: användningsfall previous next 24 Björn Eiderbäck

13 ...analysmodell... previous next 25...designmodell... previous next 26 Björn Eiderbäck

14 ...kod- och testmodell previous next 27 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 Björn Eiderbäck

15 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... previous next 29 Exempel: RUP, processen previous next 30 Björn Eiderbäck

16 ..., faser previous next 31..., användningsfall previous next 32 Björn Eiderbäck

17 ..., beskrivning previous next 33..., analysens klasser som deltar i en realisering av ta ut pengar previous next 34 Björn Eiderbäck

18 ..., användningsfalls- och analysmodell previous next 35..., samarbetsdiagram: ta ut pengar previous next 36 Björn Eiderbäck

19 ..., olika modellers beroende previous next 37..., bankomaten previous next 38 Björn Eiderbäck

20 ..., klassdiagram i design previous next 39..., sekvensdiagram previous next 40 Björn Eiderbäck

21 ..., delsystem previous next 41 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 Björn Eiderbäck

22 Ett blankt CRC-kort Klassnamn Ansvar Samarbetspartners previous next 43 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 previous next 44 Björn Eiderbäck

23 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 och kursstatus previous next 45 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 Publicist previous next 46 Björn Eiderbäck

24 Vy "Klassiska" MVC 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 previous next 47 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 Björn Eiderbäck

25 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 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 Björn Eiderbäck

26 Nyare (kontroversiell?) lättviktig metod för för systemutveckling extreme Programming (XP), av Kent Beck, inne och hett Tillvägagångsätt (12 grundpelare) 3ODQHULQJVVSHO SODQHUD VQDEEW I UXWVlWWQLQJDUQD I U QlVWD UHOHDVH SULRULWHUD WHNQLNNUDY 6Pn UHOHDVHU VOlSS Q\D YHUVLRQHU RIWD 0HWDIRU KLWWD HQ HQNHO RFK EUD PHWDIRU (QNHO GHVLJQ J U GHVLJQHQ Vn HQNHO VRP P MOLJW 7HVWD WHVWD NRGHQ NRQWLQXHUOLJW 0nVWH O\FNDV LQQDQ XWYHFNOLQJHQ JnU YLGDUH 6NULY WHVWHUQD I UVW 2PVWUXNWXUHUD UHIDFWRULQJ VWUXNWXUHUD RP RIWD WD ERUW RQ GLJ NRG I UHQNOD RVY 3DUSURJUDPPHULQJ WYn SURJUDPPHUDUH SHU PDVNLQ.ROOHNWLYW ljdqgh DY NRGHQ DOOD ljhu RFK NDQ lqgud L NRGHQ.RQWLQXHUOLJ LQWHJUDWLRQ LQWHJUHUD RFK E\JJ V\VWHPHW IOHUD JnQJHU SHU GDJ WLPPDUVYHFND MREED VRP UHJHO LQWH PHU lq WLPPDU SHU YHFND,QNOXGHUD HQ NXQG L WHDPHW LQNOXGHUD HQ ULNWLJ DQYlQGDUH Sn IXOO WLG ) OM NRGVWDQGDUG I UHQNODU NRPPXQLNDWLRQ previous next 51 Björn Eiderbäck