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
Marked
EfterspørgselUdbud
Forventninger Resultater
Kvalitets mangel
Krav
System udvikling Forretningsmuligheder
Resultater
Udbud
MarkedEfterspørgsel
Forventninger
Krav Udbud
Ekstern proces(Samfundet)
Intern proces(Virksomheden)
Udbud
Kvalitets mangel
Hvorfor SPU?
• Tidsstyring• Vedligeholdelse• Dokumenentation• Risikominimering• Kvalitetsoptimering• Genbrug• m.m.
Fejlretningsudgifter
Jo længere henne i udviklingsprocessen, jo mere koster det at rette fejl i tid og penge
Krav Design Kodning Test Drift
Relativ udgift forfejlretning
1
10
100
• Systematisk design gør det lettere at rette fejl
• Kravfejl -> Designfejl• Designfejl -> Kodefejl • Mangel på erfaring
Styringsproblemer
Hvad går galt her?• Problemer bliver først opdaget når koden er skrevet
og skal integreres!
Krav Design Kodning Test Integration
Planlagt
Realitet
Udgifter/Tidsplan/Problemer
• Manglende kravspecifikation-> ringe estimeringsgrundlag
• Mangel på indsigt i SWudviklingsproblematik
• Dårlig koordinering mellemudviklere pga. dårlige interfacedesign
• Mangel på forståelse mellemudviklere
Software fejludvikling
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
• Spaghetti kode er svært atvedligeholde- Umuligt at huske efter 10 mdr.
• Udokumenteret kode ersvært at udvikle videre på- Centreret omkring få udviklere- Øger afhængighed af disse
Ustruktureret/Udokumenteret
UdviklingStart V1.0 V2.0 V3.0
Fejlhyppighed
Held
Uheld
Struktureret
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)
Udvikling er ikke let, specielt ikke hvis det skal ende med succes!Højere succesrate: Struktureret Systemudvikling
Konklusion
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 udviklingsmodel2. Udarbejd en kravspecifikation3. Design før kodning4. Planlæg test5. Anvend review teknikken6. Foretag projektstyring7. Dokumentér undervejs8. Foretag konfigurationsstyring
Apparatudvikling
SPU - udviklingsmodellen
SPU – udviklingsmodellen (Detaljeret)
SPU V-model (Software)
Kravspec.
Programdesign
Procesdesign
Moduldesign
Implementation
Procesintegration
Accept-test
Modultest
Modulintegration
SPU V-model (Hardware)
Kravspec.
Strukturdesign
HW moduldesign
Layoutdesign
Wrapning/Printudlægning
Integrationstest
Accept-test
Forbindelsestest
HW Modultest
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
Use Case
Aktør“Deltagelse i”
Association
SystemGrænse(Ofte underforstået)
Use case, eksempel
Kunde
Finansorgan
Online butik
Bestil vareSalgs
AssistentBehandle kunde-
regning
Send ordre
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
SpecifikAktør
SpecifikAktør
Aktør
Grund Use Case
Udvidet Use Case
<<extend>>
Grund Use Case
Specifik Use Case
Grund Use Case
InkluderetUse Case
<<include>>
Eksempel på relationer mellem grundkomponenter
ValiderUser
Sendordre
<<include>>
CheckPassword
Håndterordre
<<extend>>Kunde
Kommercielkunde
Privatkunde
Use case komponenter
Komponent Beskrivelse SyntaksUse case En sekvens af handlinger, som
et system (eller andre enheder) kan udføre, interagere med aktørerne i use caset
Aktør Et sammenhængende sæt af roller, som brugere af use caset, har mens denne interagere med use caset.
System grænse
Repræsentation af grænse mellem det fysiske system og aktørerne som interagerer med det fysiske system
Use caseName
Aktør navn
Use case, relationer
Relation Beskrivelse SyntaksAssociation Interaktion mellem en aktør og
en use caseGeneralisering 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
“Lytteren”
MP3 afspiller
Afspil mp3 fil
Vis ID-tag info
Upload af mp3 filer
PC
Forstærkeranlæg
“Uploader”
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 afspilleren2.Et musiknummer vælges3.Dette afspilles4.Afspilning stopper
Use case eksempel, tekst beskrivelse #2/2
• Undtagelser:• Enkodningen ikke understøttet
1.send besked til display2.fortsæt til næste nummer
• Ingen filer uploaded1.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. Sehttp://kom.aau.dk/~rlo/lectures/systemDesign08/Skitse%20analysedokument.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 International25-28 June 1995 Page(s):293 – 298, Digital Object Identifier 10.1109/IEMC.1995.524596