Struktureret system udvikling Minimodul 1: Introduktion, UML og use cases Rasmus L. Olsen, 27 februar 2008
Introduktion Kursets hjemmeside http://www.kom.aau.dk/~rlo/ Kursus holder Rasmus L. Olsen Færdiguddannet i 2003 Opnået PhD i Januar 2008 Arbejdet i Europæisk forskningsprojekter MAGNET 2004-2005 Udvikling af nyt netværksparadigmer (Personal Networks) MAGNET Beyond 2006-2008 (http://www.ist-magnet.org) OPEN fra 2008
Kursus indhold og mål System begreb Analyse, kravspecifikation og accepttest Designprincipper og faldgruber Testprincipper Implementering Dokumentation Bruger, -installations og vedligeholdelses- dokumenter
Opfyldelse af studiemål Læsning af litteratur (primære og supplerende) Forelæsninger Opgaveløsninger (med udgangspunkt i jeres projekter) Analysedokumenter Designdokumenter Reviewdokument(er) Aktiv deltagelse i opgaveløsninger Fordelagtigt, også i forhold til jeres projekt
Kursusoversigt og tidsplan Mm1: Introduktion til kursus, UML og use cases (i dag 11 Februar, 2008) Mm2: Kravspecifikation og accepttest (18/2) Mm3: SPU og UML (11/3) Mm4: Design af system (18/3) Mm5: Test design og planlægning (25/3??)
Dagens program Baggrund og motivation for Struktureret System Udvikling (SPU) Introduktion til SPU og V-model UML og use cases Opgaver
Dagens program Baggrund og motivation for Struktureret System Udvikling (SPU) Introduktion til SPU og V-model UML og use cases Opgaver
Problem stilling
System udvikling set i perspektiv Udbud Efterspørgsel Forventninger Marked Kvalitets mangel Resultater Ekstern proces (Samfundet) Krav Udbud System udvikling Forretningsmuligheder Resultater Kvalitets mangel Forventninger Udbud Marked Efterspørgsel Intern proces (Virksomheden) Krav Udbud
Hvorfor SPU? Tidsstyring Vedligeholdelse Dokumenentation Risikominimering Kvalitetsoptimering Genbrug m.m.
100 10 Fejlretningsudgifter Relativ udgift for fejlretning Systematisk design gør det lettere at rette fejl Kravfejl -> Designfejl Designfejl -> Kodefejl Mangel på erfaring 1 Krav Design Kodning Test Drift Jo længere henne i udviklingsprocessen, jo mere koster det at rette fejl i tid og penge
Styringsproblemer Udgifter/ Tidsplan/ Problemer Realitet Planlagt Manglende kravspecifikation -> ringe estimeringsgrundlag Mangel på indsigt i SW udviklingsproblematik Dårlig koordinering mellem udviklere pga. dårlige interface design Mangel på forståelse mellem udviklere Krav Design Kodning Test Integration Hvad går galt her? Problemer bliver først opdaget når koden er skrevet og skal integreres!
Software fejludvikling Fejlhyppighed Uheld Held Ustruktureret/ Udokumenteret Struktureret Spaghetti kode er svært at vedligeholde - Umuligt at huske efter 10 mdr. Udokumenteret kode er svært at udvikle videre på - Centreret omkring få udviklere - Øger afhængighed af disse Start V1.0 V2.0 V3.0 Udvikling Introduktion af SW opdateringer Skal være nemt for brugeren og ikke stille alt for store krav Skal ikke introducere flere problemer end der løses
Undtagelser En person om en simpel ting, f.eks. Ens personlige hjemmeside Et lille hobby projekt Eller mere generelt: når der er tale om et minimalt personligt system til engangsbrug Ellers altid en god ide at bruge struktureret system design
Konklusion Systemudvikling er mere håndværk end videnskab! Der markedsføres mange forskellige metoder! Ingen passer præcist til nogen situation! Skal skræddersys til det aktuelle tilfælde! To metoder I vil støde på i løbet af tiden på AAU: Struktureret SystemUdvikling (el. Systematisk SystemUdvikling) - SPU Objekt Orienteret Analyse og Design (OOAD)
Konklusion Udvikling er ikke let, specielt ikke hvis det skal ende med succes! Højere succesrate: Struktureret Systemudvikling
Dagens program Baggrund og motivation for Struktureret System Udvikling (SPU) Introduktion til SPU og V-model UML og use cases Opgaver
SPU-UML konceptet 1. Benyt en udviklingsmodel 2. Udarbejd en kravspecifikation 3. Design før kodning 4. Planlæg test 5. Anvend review teknikken 6. Foretag projektstyring 7. Dokumentér undervejs 8. Foretag konfigurationsstyring
Apparatudvikling
SPU - udviklingsmodellen
SPU udviklingsmodellen (Detaljeret)
SPU V-model (Software) Kravspec. Programdesign Procesdesign Moduldesign Accepttest Procesintegration Modulintegration Modultest Implementation
SPU V-model (Hardware) Kravspec. Strukturdesign HW moduldesign Layoutdesign HW Modultest Forbindelsestest Accepttest Integrationstest Wrapning/Printudlægning
Dagens program Baggrund og motivation for Struktureret System Udvikling (SPU) Introduktion til SPU og V-model UML og use cases Opgaver
Krav specifikation Opstilling af de rigtige krav er en disciplin for sig selv. Typisk 20% af de samlede udviklingsresurser Beskriver hvad der skal udvikles, og IKKE hvordan! Nogle af metoderne til at finde de rigtige krav er: Brugerinddragelse Use Case-teknikken Genbrug af krav Krav fra samfundet, regler/love etc.
Relation mellem kravspecifikation og use cases
Unified Modelling Language (UML) UML (Unified Modelling Language) = en OMG (Object Management Group) standard (www.omg.org) OMG er en sammenslutning af ca. 800 virksomheder. UML anvendes i dag verden over som beskrivelsesværktøj i forbindelse med udviklingsprojekter. Eksempler på værktøjer: ArgoUML: http://argouml.tigris.org/ Visual Paradigm: http://www.visual-paradigm.com/
Use case notation Aktør Use Case Deltagelse i Association System Grænse (Ofte underfor stået)
Use case, eksempel Online butik Kunde Bestil vare Behandle kunderegning Salgs Assistent Send ordre Finans organ
Mål med Use Cases En Use Case: specificerer en komplet funktionalitet, som har værdi for brugeren Aktør (aktør/bruger) befinder sig eksternt i forhold til systemet. Kan være en person, hardware, m.m. Aktør er karakteriseret ved sin rolle, hvilket også skal fremgå af navnet! systemet betragtes som en black box skal ikke omhandle design! kun det antal use cases der er nødvendige for at forstå systemets funktionalitet
Relationer mellem grundkomponenter Grund Use Case Grund Use Case Aktør <<extend>> Specifik Use Case Udvidet Use Case Specifik Aktør Specifik Aktør Grund Use Case Inkluderet Use Case <<include>>
Eksempel på relationer mellem grundkomponenter Kunde Send ordre <<extend>> Håndter ordre <<include>> Valider User Kommerciel kunde Privat kunde Check Password
Use case komponenter Komponent Beskrivelse Syntaks Use case Aktør System grænse En sekvens af handlinger, som et system (eller andre enheder) kan udføre, interagere med aktørerne i use caset Et sammenhængende sæt af roller, som brugere af use caset, har mens denne interagere med use caset. Repræsentation af grænse mellem det fysiske system og aktørerne som interagerer med det fysiske system Use case Name Aktør navn
Use case, relationer Relation Beskrivelse Syntaks Association Interaktion mellem en aktør og en use case Generalisering Relation mellem en generel use case og en mere specifik use case Udvidelse Relation mellem en udvidet use case, baseret på en given use case Indeholdende Relation mellem en given use case, og i en base use case <<extend>> <<include>>
Use case beskrivelse Use Case navn: f.eks. overvåg temperatur Målbeskrivelse: hvad er det use caset tilbyder aktøren Normal scenario: beskrevet ved et antal trin Undtagelser: beskrivelse af undtagelser og afvigelser samt hvordan de håndteres af systemet
Eksempel MP3 afspiller MP3 afspiller Lytteren Afspil mp3 fil Vis ID-tag info Forstærker anlæg Uploader PC Upload af mp3 filer
Use case eksempel, tekst beskrivelse #1/2 Use Case Navn: Afspil mp3 fil Målbeskrivelse: På baggrund af lytterens valg dekodes og afspilles en mp3 fil Nomal scenario: 1. Lytteren tænder for mp3 afspilleren 2.Et musiknummer vælges 3.Dette afspilles 4.Afspilning stopper
Use case eksempel, tekst beskrivelse #2/2 Undtagelser: Enkodningen ikke understøttet 1.send besked til display 2.fortsæt til næste nummer Ingen filer uploaded 1.send besked til display
Dagens program Baggrund og motivation for Struktureret System Udvikling (SPU) Introduktion til SPU og V-model UML og use cases Opgaver
Opgaver Med udgangspunkt i jeres projekt, udarbejd et analysedokument. Se http://kom.aau.dk/~rlo/lectures/systemdesign08/skitse%20analysedokum ent.htm Opgaverne er tænkt følgende jeres projekt og bør ses som yderligere support til projektet Review af analyse dokumenter udføres (senere) af to grupper
Grupper... Fyldes ind her: (Gruppe nr. + rumnummer)
Referencer The system engineering process, Boarder, J.C.; Engineering Management Conference, 1995. 'Global Engineering Management: Emerging Trends in the Asia Pacific'., Proceedings of 1995 IEEE Annual International 25-28 June 1995 Page(s):293 298, Digital Object Identifier 10.1109/IEMC.1995.524596