Struktureret system udvikling Minimodul 4: Struktureret ProgramUdvikling (SPU) - I

Transkript

1 Struktureret system udvikling Minimodul 4: Struktureret ProgramUdvikling (SPU) - I Rasmus L. Olsen, 17 Februar,

2 V-modellen - overordnet Kravspecifikation Arkitekturdesign System integrationstest Accepttest Moduldesign Modultest SW & HW Implementering 2

3 Hvor er vi jvnf. SPU? 3

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

5 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 5

6 Generelt om design David 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 One bad programmer can easily create two new jobs a year.. 6

7 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å: Kan andre overtage projektet uden at skulle starte forfra Let at implementere: Kræver implementering en kompleks industriel process, f.eks. smd lodning eller kan vi anvende wrapning Let at teste: Hvilke muligheder har vi for at teste efterfølgende Let at vedligeholde: Hvis jeg senere finder ud af at skulle opdatere min software, kræver det total omprogrammering, eller kan jeg erstatte et modul Har en høj ydelse, f.eks. Responstid, lavt strømforbrug, m.f. 7

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

9 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 9

10 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() Class: Airplane + checkstatus() + takeoff() + landing() Class: Fighter + armweapon() + fireweapon() If (a>b) { c=d+e; } else { c=0; } return c; 10

11 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 11

12 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 David Funktion Parnas: 2 We propose Funktion instead Nthat one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others 12

13 Designprincipper Muliggør parallel udvikling af enheden Skal specificeres og dokumenteres! Sker i tæt interaktion med opdeling af enheden 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 De seks regler Kompleks grænseflade 1. Minimaliser og optimiser tætheden af grænseflader 2. Design for og med genbrug 3. Design for vedligeholdelse 4. Design for og med del-leveringer 5. Design for testbarhed 6. Design for og med fejlsituationer Modul A Modul A Simpel grænseflade Modul B Modul B 13

14 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 14

15 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 15

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

17 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) Muligheder for Interface A a) N Digitale filter koefficienter b) 1 master parameter c) M lydkilde parametre d) Andre forslag? Volume kontrol GUI Interface A Lyd driver Hardware 17

18 Generelle designregler Minimaliser og optimiser tætheden Funktionstæthed af grænseflader Lav funktionstæthed: eks. et diverse Design for og med genbrug modul fyldt med urelaterede funktioner Design for vedligeholdelse Høj funktionstæthed: eks. Alle operatør Design for og med del-leveringer funktioner i et operatørmodul Design for testbarhed Jo højere funktionstæthed en modul Design for og med fejlsituationer kan opnå, jo lavere kobling mellem moduler David Parnas: Et modul skal indkapsle og beskytte en designbeslutning Robot Retnings kontrol Sensor læser??? Diverse Operatør modul? Hardware 18

19 Generelle designregler Genbrug af design og moduler er generelt godt fordi: Kortere udviklingstid Lavere pris Bedre kvalitet og pålidelighed 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 god vedligeholdelse af bibliotek Andre forhold kan også være gældende, f.eks. Hvad platform modulet er udviklet til/på Specifik interface (et genbrugeligt modul skal gerne have generelle interfaces) 19

20 Genbrugelighed - eksempler Nogle moduler er bedre egnede til genbrug end andre, f.eks. Et RS-232 kommunikationsmodul Læse/skrivemodul Kontrolmodul Sensormodul til sensor X 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 Robot Retnings kontrol Sattelit kontrol IR sensor Ultra sound sensor! RS-232 Diverse IR sensor - RS232 20

21 Generelle designregler Vedligeholdelse er nemt hvis der i designfasen er taget stilling til hvorledes dette skal/kan gøres 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 Nogle teknikker kan være Udforme designet med en passende åben struktur, f.eks. ved modulisering af opgaver/funktioner At samle og beskytte f.eks. Maskin, OS, compiler og hardwareafhængige funktioner i moduler der er lette at lokalisere og ændre 21

22 Generelle designregler At modulisere logik og datastrukturer, således varianter udelukkende opsættes i datastrukturer, f.eks. - Flytte dialogtekst eller konfigurationer ud i en tekstfiler 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 RS-232 RS-232 Config Hardware platform 1 Hardware platform 2 file 22

23 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) 23

24 Generelle designregler Anvendelse af dummy og midlertidige versioner er nemt med en modul tilgang til implementering Ved parallel udvikling af f.eks. Motorstyring IR og Ultra sound sensor RS-232 modul Robotstyring Kan robot styring anvende simulerede input til design og valg af parametre RS-232 folkene kan fokusere på data transmission Sensor folkene på hvordan sensor data skal betragtes Motor folkene hvordan motorene skal styres 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 Motor styring Robot kontrol IR sensor RS-232 Ultra sound sensor 24

25 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 Gode tests kræver planlægning!! 25

26 Generelle designregler Ofte mangler specifikation på fejlsituationer Ikke optimalt i de fleste tilfælde, og katastrofalt i andre tilfælde 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 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 26

27 Generelle designregler Ofte mangler specifikation på fejlsituationer Ikke optimalt i de fleste tilfælde, og katastrofalt i andre tilfælde 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 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 27

28 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 28

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

30 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 30

31 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? 31

32 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 32

33 Eksempel på Data Flow Diagram 33

34 Eksempel på Data Flow Diagram med proces opdeling 34

35 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 35

36 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 36

37 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 = 0 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 37

38 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? 38

39 Hændelser og interproces kommunikation Proces 4 Proces 3 Proces 2 Proces 1 Processer 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 ressourcer beregnet til en-ad-gangen Disk- og hukommelsesadgang A/D og D/A konvertere Time 39

40 Proces synkronisering - Software Typiske operationer der kan anvendes Semaforer 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 , Posix), se 40

41 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 41

42 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 42

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

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

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

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

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

48 Pseudo kode 48

49 Flowcharts - byggesten 49

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

51 Tilstandsdiagrammer 51

52 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 52

53 Tid Basis komponenter og sekvensdiagrammer Komp. A Komp. B Aktivitet Aktivitet Komponenter eller del-systemer Beskeder eller aktioner Aktiviteter Beslutninger (eller rettere resultat af beslutninger) 53

54 Tid En god hjælp til definering af interfaces Komp. A Komp. B Aktivitet Aktivitet Interface A - Knap - Lampe Interface B - Besked A-B - Besked B-A 54

55 V-modellen - overordnet Kravspecifikation Arkitekturdesign System integrationstest Accepttest Moduldesign Modultest SW & HW Implementering 55

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

57 Opgaver 1. Med udgangspunkt i jeres projekt, identificer en række overordnede blokke og specificer overordnede funktionalitet og grænseflade. Uddyb blokkene til mindre moduler og specificer funktionalitet og grænseflade. 2. Overvej en robot og en fjerntliggende PC. Formålet er udforskning af vulkansk aktivitet på svært tilkommelige områder på Hawaii. Den skal bl.a. kunne bevæge sig i ugæstfrie og ujævne områder, hvor overfladen kan være tynd og med lava flydende under sig. Den skal kunne vidergive informationer omkring forskellige sensor målte data; jordrystelser, forskellige luftpartikler, temperaturer, og skal kunne samle prøver og medbringe disse tilbage. Hvilke fysiske enheder vil i have på en sådan robot? Hvilke moduler vil i have på robotten? Vælg et eller to moduler: Hvordan vil et fornuftigt interface se ud? Hvilke parametre skal i tage højde for? Hvad for noget data skal der udveksles mellem de to enheder? Er der krav til hvor hurtigt data udveksles mellem moduler, og hvordan sikrer i jer at disse krav er overholdt i forhold til valg af interface? 3. Uanset hvilken opgave i har påtaget jer, hvordan vil i sikre jer at tingene kan integreres som sidste del at projektforløbet? 57