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