Struktureret system udvikling Minimodul 4: Introduktion til systematisk design

Struktureret system udvikling Minimodul 4: Introduktion til systematisk design Rasmus L. Olsen, 26 Marts, 2008

Kursusoversigt og tidsplan Mm1: Introduktion til kursus, UML og use cases (13/2, 2008) Mm2: Kravspecifikation og accepttest (27/2) Mm3: SPU og UML (12/3) Mm4: Design af system (26/3) Mm5: Test design og planlægning (9/4)

Dagens program Generelt om design Designprincipper Generelle designregler Software design Program design Process design Modul design

Generelt om design Ingen entydig opskrift på god design Design er en kreativ proces Design Kræver Et vist antal iterationer En god portion intuition Jo mere erfaring, jo bedre design Generelt er design vanskeligt - Men også sjovt

Generelt om design D. Parnas: Vi vil aldrig finde en metode, der tillader os at designe software på en rationel måde Men vi kan få det til at se ud sådan og det kan betale sig at gøre sådan!!! Design dokumenteres som om man havde fulgt en ideel og rationel arbejdsproces

Generelt om design Det gælder om at realisere kravspecifikationen! Designarbejdet skal udføres grundigt med omfattende dokumentation og reviews. Godt design er karakteriseret ved bla.: Let at forstå Let at implementere Let at teste Let at vedligeholde Har en høj ydelse, f.eks. Responstid, lavt strømforbrug, m.m.

Designprincipper Vælg en designmetode Code-and-fix Object Orienteret Fastlæg de eksterne grænseflader Hvilke muligheder er der indenfor de givne rammer Hvad er givet på forhånd Hvad mangler Foretag en opdeling af enheden Fastlæg de interne grænseflader Kontroller designet Dokumenter designet Først når designet er tilfredsstillende, færdiggøres dokumentet Dokumenter som designet var foregået på en rationel måde

Designprincipper Flere kandidater Object Orienteret Code-and-Fix Structural Circuit analysis. Vælg en designmetode Fastlæg de eksterne grænseflader Foretag en opdeling af enheden Fastlæg de interne grænseflader Kontroller designet Dokumenter designet U=R*I..og så videre. Class: Passenger + setlandingsign() + showmovie() + checkstatus() Class: Airplane + takeoff() + landing() Class: Fighter + armweapon() + fireweapon() If (a>b) { c=d+e; } else { c=0; } return c;

Designprincipper Fastlæggelse af enhedens omgivelser Kan komme fra bla. Analysen Andre moduler Eksterne kilder Vælg en designmetode Fastlæg de eksterne grænseflader Foretag en opdeling af enheden Fastlæg de interne grænseflader Kontroller designet Dokumenter designet MP3 afspiller Afspil mp3 fil Lytteren Vis ID-tag info Forstærker anlæg Upload af mp3 filer Uploader PC

Designprincipper Opdeling af system i moduler og komponenter Divide et impera Men baseret på hvilke kriterier? Vælg en designmetode Fastlæg de eksterne grænseflader Foretag en opdeling af enheden Fastlæg de interne grænseflader Kontroller designet Dokumenter designet System Program 1 Program 2 Program K Moduler 1 Moduler 2 Moduler M Funktion 1 Funktion 2 Funktion N

Designprincipper Muliggør parallel udvikling af enheden Skal specificeres og dokumenteres! Sker i tæt interaktion med opdeling af enheden De seks regler Vælg en designmetode Fastlæg de eksterne grænseflader Foretag en opdeling af enheden Fastlæg de interne grænseflader Kontroller designet Dokumenter designet Minimaliser og optimiser tætheden af grænseflader Design for og med genbrug Design for vedligeholdelse Design for og med del-leveringer Design for testbarhed Design for og med fejlsituationer Komp. A Komp. A Komp. B Komp. B

Designprincipper Teknisk gennemgang Review Checklister Vælg en designmetode Fastlæg de eksterne grænseflader Foretag en opdeling af enheden Fastlæg de interne grænseflader Kontroller designet Dokumenter designet

Designprincipper Udgangspunkt for Review Efterfølgende vedligeholdelse Intern kommunikation Vælg en designmetode Fastlæg de eksterne grænseflader Foretag en opdeling af enheden Fastlæg de interne grænseflader Kontroller designet Dokumenter designet

Generelle designregler Lav kobling mellem moduler F.eks. hvis data udveksles som parametre Få interaktioner mellem moduler Simple interaktioner mellem moduler Høj kobling Kræver mange interaktioner mellem moduler Minimaliser og optimiser tætheden af grænseflader Design for og med genbrug Design for vedligeholdelse Design for og med del-leveringer Design for testbarhed Design for og med fejlsituationer Kræver mange data bliver udvekslet (evt. pak data ind i strukturer) Funktionstæthed Lav funktionstæthed: eks. et diverse modul fyldt med urelaterede funktioner Høj funktionstæthed: eks. Alle opetør funktioner i et operatørmodul Jo højere funktionstæthed en modul kan opnå, jo lavere kobling mellem moduler D.Parnas: Et modul skal indkapsle og beskytte en designbeslutning

Generelle designregler Genbrug af design og moduler er generelt godt fordi: Kortere udviklingstid Lavere pris Bedre kvalitet og pålidelighed Kræver god vedligeholdelse af bibliotek Nogle moduler er bedre egnede til genbrug end andre, f.eks. Et RS-232 kommunikationsmodul Læse/skrivemodul Kontrolmodul Sensormodul til sensor X Andre forhold kan også være gældende, f.eks. Hvad platform modulet er udviklet til/på Minimaliser og optimiser tætheden af grænseflader Design for og med genbrug Design for vedligeholdelse Design for og med del-leveringer Design for testbarhed Design for og med fejlsituationer Specifik interface (et genbrugeligt modul skal gerne have generelle interfaces)

Generelle designregler Vedligeholdelse er nemt hvis der i designfasen er taget stilling til hvorledes dette skal/kan gøres Nogle teknikker kan være Udforme designet med en passende åben struktur, f.eks. ved modulisering af opgaver/funktioner Minimaliser og optimiser tætheden af grænseflader Design for og med genbrug Design for vedligeholdelse Design for og med del-leveringer Design for testbarhed Design for og med fejlsituationer At samle og beskytte f.eks. Maskin, OS, compiler og hardwareafhængige funktioner i moduler der er lette at lokalisere og ændre At modulisere logik og datastrukturer, således varianter udelukkende opsættes i datastrukturer. Eksempler Flytte dialogtekst eller konfigurationer ud i en tekstfiler

Generelle designregler Delleveringer kan give tidlig feedback Designet skal omfatte samtlige delleverancer Delleverancer kan også med fordel specificeres i kravspecifikationen Minimaliser og optimiser tætheden af grænseflader Design for og med genbrug Design for vedligeholdelse Design for og med del-leveringer Design for testbarhed Design for og med fejlsituationer Designet skal foretages således delleverancer bliver lette. Med en god modulopdeling er det dog ikke nødvendigvis et problem Et alarmeringssystem kunne i første omgang implementere en simpel alarm Senere leveringer kunne indføre mere sofistikerede alarmeringsmetoder (men stadig have samme interfaces som alarm V1.0)

Generelle designregler Alt skal testes Husk: Hvis ikke det er testet, så virker det ikke!! Et mål for godt design er muligheden for at teste moduler og system Minimaliser og optimiser tætheden af grænseflader Design for og med genbrug Design for vedligeholdelse Design for og med del-leveringer Design for testbarhed Design for og med fejlsituationer

Generelle designregler Ofte mangler specifikation på fejlsituationer Ikke optimalt i de fleste tilfælde, og katastrofalt i andre tilfælde Minimaliser og optimiser tætheden af grænseflader Design for og med genbrug Design for vedligeholdelse Design for og med del-leveringer Design for testbarhed Design for og med fejlsituationer Fejl bør lede til fornuftige handlinger Reboot? Fortsætte? Stoppe helt? Gå i fejlsikker tilstand? Hvem og hvad involverer en fejl? Slutbrugeren? En ekspert? Redundante systemblokke? Hvordan designes disse ind i eksisterende systemer og systemløsninger? Konklusion: Fejlsikre systemer er decideret udviklings- og forskningsemner

Arbejdsformer og dokumentation Rådspørg kunden ved kravspørgsmål Deltag flere ved design Anvend en dokumentstandard Benyt grafik til at give overblik Vurder og beskriv alternativer Vedligehold designdokumenter Evaluer benyttede metoder

Software design Program design Process design Modul design SPU modellen opdeler designprocessen i tre step Program design Process design Modul design Godt for parallelisering af opgaver Men pas på, nogle opgaver kræver synkronisering! Kræver godt design og tanker omkring proces kommunikation

Programdesign Opdeling af program i flere sekventielle processer (multiprogrammering) Proces = job = task = Eksempel Brugerdialog Overvågning Specifikation af eksterne grænseflader Specifikation af grænseflader mellem processer Men hvordan?

Data flow diagrammer Firkantede kasser angiver hvor data opstår eller slutter Start/Slut Cirkler angiver data transformationer (input -> output) 0 proces Flow angives med pile Information flow Ikke-lukkede kasser angiver en fil (disk, hukommelse, database, ) Database

Eksempel på Data Flow Diagram

Eksempel på Data Flow Diagram med proces opdeling

Check af program design Nemt og overskueligt for andre (f.eks. Kunden) at se hvorvidt et system overholder krav, og hvor i systemet kravene bliver opfyldt

Guidelines til opdeling af processer Tidsmæssige sammenlægnings-kriterium: Transformationer der aktiveres af samme hændelse, kan efter dette kriterium sættes sammen i en proces Sekventielt sammenlægnings-kriterium: Hvis flere transformationer altid sker i samme rækkefølge, kan de slås sammen i en proces Prioritets sammenlægnings-kriterium: Transformationer der har forskellig prioritet skal IKKE lægges i samme proces, idet det modvirker opfyldelsen af tidskrav til de enkelte transformationer

Race condition Tænk på to opgaver der løses parallelt A, B gør hver flg. 1. Read X 2. Do X=X+1 3. Write X back Task A Synkronisering Task B Integer X Sekventielt udføres programmerne således, X bliver 2 efter at A og B er færdige Read X X = X+1 Write X=1 Read X X = X+1 Write X=2 I et multitask miljø, risikerer X at blive 1 Time Task A Read X X = X+1 Write X=1 Time Task B Read X X = X+1 Write X=1

Deadlocks When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone. Proces A venter på at Proces B skal blive færdig med et resultat Proces B venter på at Proces A skal levere input til beregningen.. Hvor lang tid skal de vente på hinanden?

Hændelser og interproces kommunikation Processer Proces 4 Proces 3 Proces 2 Proces 1 Processer har somme tider behov for at kommunikere Vente på resultater fra andre processer, f.eks. Ved beregning af resultater Ved venten på eksterne events, såsom hardware interrupts Anvendelse af resourcer beregnet til en-ad-gangen Disk- og hukommelsesadgang A/D og D/A konvertere Time

Proces synchronisering - Software Typiske operationer der kan anvendes Semaphorer og/eller mutexes: Anvendes til at ekskludere andre processer til en given ressource, f.eks. Variablen X Signaler: Anvendes til at kommunikere til andre processer, f.eks. Stop eksekvering, Sov 100 ms, vent på hændelse Y Event: Benyttes til at signalere en hændelse er sket; jeg er færdig med at beregne Y, data er klar, A/D konverteringen er færdig, IEEE definerer en standard for proces kommunikation (IEEE Std 1003.1, Posix), se http://standards.ieee.org/regauth/posix/

Software design Program design Process design Modul design Opdeling af processen i mindre moduler Del og hersk Uddelegering af opgaver Nemmere vedligeholdelse Fejldetektering og retning bliver nemmere

Opsplitning af processer i moduler Formål: Designe den enkelte proces som et sekventielt program Opdeling af processen i simplere opgaver (udført af moduler) Udarbejdelse af modul specifikation Specifikation af modul integrationstest Definition af modul: En selvstændig enhed, der skjuler en designbeslutning taget under procesdesignet

Modul design Designes som black-box Modul specifikation Beskrivelse af modulets funktionalitet Funktioner inkl. parametre

Funktionsorienteret design Top-down funktions-nedbrydning Bottom-up funktions-opbygning Hybrid Mest kritisk først Bottom down approach Bottom up approach

Funktionsorienteret design Nedbrydning i input, behandling og output Funktion Input Behandl Output Input Behandl Output

Balanceret opdeling Fan-out: Forgreningsfaktor jvf. SPU max. 7 +/- 2 Fan-in: Tilstræb fan-in i dybden Balanceret Ubalanceret

Software design Program design Process design Modul design Detaljeret design af datastrukturer og funktioner Pseudokode Grafiske Flowcharts Tilstandsdiagrammer.

Pseudo kode

Flowcharts - byggesten

Flowcharts typiske eksempler

Flowcharts flere eksempler

UML State Diagram Initial state State transition Ready Stop [User quits] State Event /ctr 0 := 0 Final/End State Done Stop Guard Action

Tilstandsdiagrammer

Regler for moduldesign Ingen globale variabler eller datastrukturer der kan ændres udefra Grænseflader ud af modulet består af entry funktioner Lokale funktioner bør ikke være synlige udadtil Initialisering af modulets datastrukturer eller hardware bør ske gennem initialiseringsfunktion med parametre Evt. inkluder testfunktion til udskrivning af modulets skjulte informationer Design modulet med henblik på senere genbrug i andre sammenhæng/projekter

Nogen spørgsmål?

Opgaver Reviewmøder mellem grupper som planlagt