Softwarekonstruktion

1. Softwarekonstruktion Udviklingsmodeller generelt Introduktion til UML Udviklingsmodellen UP UML strukturer

2. Udviklingsmodel, metode og notation • Et udviklingsmodel er en samling af aktiviteter, der fører frem til det færdige produkt • En metode er konkrete retningslinier for, hvordan de enkelte aktiviteter skal udføres • UP er både en udviklingsmodel og metode • En notation er et sprog til beskrivelse og visualisering • UML er en fælles standard for visualisering af modeller og understøttes af forskellige case – værktøjer • UP og mange andre metoder benytter UML Lektion 4 - SWK

3. Udviklingsmodeller – oversigt Basis modeller: • Vandfaldsmodellen • Specifikation (først) og udvikling (sidst) i adskilte faser • Et sekventielt gennemløb • Evolutionær systemudvikling • Prototyper der iterativt forbedres på baggrund af brugerinput • Specifikation, udvikling og test er vævet ind i hinanden ”Moderne” modeller (UP, XP m. fl.) indeholder alle et miks af elementer fra ovennævnte basismodeller – derfor er det vigtigt at forstå deres fordele/ulemper Lektion 4 - SWK

4. Vandfaldsmodellen (Royce) Lektion 4 - SWK

5. Vandfaldsmodellen – laksen Lektion 4 - SWK

6. Fordele / ulemper • Fordele • God synlighed - let at styre efter • God dokumentation • Ulemper • Går ofte fejl af brugerne, idet beslutninger tages på grundlag af abstrakte specifikationer og med begrænset brugerinddragelse (ingen kodning/test i de første faser) • Ændringshåndtering vanskelig (kun et gennemløb) • Fejl-/misforståelser opdages først sidst i processen, hvor de er dyre at rette (test sent i processen) • Anvendelse • Modellen passer bedst til situationer, hvor kravene kan specificeres, er forståelige, og senere ændringer er begrænsede, hvilket sjældent er tilfældet Lektion 4 - SWK

7. Evolutionær systemudvikling(evolutionsmodellen) • Udforskende udvikling • Formålet at udvikle et system, mens der løbende integreres med kunden. • Der startes med de mest forståelige dele • Features tilføjes efterhånden af kunden • Bruges i situationer, hvor det ikke er klart, hvordan systemet skal fungere • Smid - væk prototyper • Målet er en bedre kravspecifikation. • Prototypen bruges for at afklare det reelle behov • Bruges i situationer, hvor kravene til systemet kendes, men er vanskelige at forstå. Lektion 4 - SWK

8. Evolutionær udvikling Lektion 4 - SWK

9. Fordele / ulemper • Fordele • Hurtig udvikling af noget der ligner et rigtigt system • Stor grad af brugerdeltagelse, motiverende • God opfyldelse kundekrav • Ulemper • Vanskelig af måle fremdrift – samt afgøre hvornår systemet er færdigt. Vanskeliggør projektledelse • Mange ændringer ødelægger strukturen • Specielle krav til uddannelse og værktøjer Lektion 4 - SWK

10. Iterative og inkrementelle modeller • Set over tid vil der altid komme krav til ændringer • Derfor er iterationer nødvendige • Hver iteration resulterer i en udvidelse af systemet - et inkrement • Moderne modeller forener det bedste fra vandfald og evolutionær • Risikostyrede iterative modeller: • Et første bud: Spiral modellen • Et praktisk anvendeligt bud: Unified Proces (UP) Lektion 4 - SWK

11. Boehm’s spiralmodeleksempel Lektion 4 - SWK

12. Situationsbestemt udvikling • Hvilken type projekt? • Stabile / dynamiske krav • Lille/stort • Simpelt/Komplekst • Fejl har store/små konsekvenser • Hvilke type udviklere? • Erfarne/uerfarne • Selvstændige/uselvstændige • Hvilken type software – hardware? • Prøvet før/nyt Lektion 4 - SWK

13. Historien bag UML Lektion 4 - SWK

14. Udviklingsmodel, metode og notation • Et udviklingsmodel er en samling af aktiviteter, der fører frem til det færdige produkt • En metode er konkrete retnings linier for, hvordan de enkelte aktiviteter skal udføres • UP er både en udviklingsmodel og metode • En notation er et sprog til beskrivelse og visualisering • UML er en fælles standard for visualisering af modeller og understøttes af forskellige case – værktøjer • UP og mange andre metoder benytter UML Lektion 4 - SWK

15. Perspektiver • Analyse (Hvad skal systemet indeholde?) • en simplifikation af virkeligheden i et black box view • gør udviklerne i stand til bedre at forstå det system de udvikler • Design (Hvordan skal systemet bygges?) • et white box view på systemet • betragter systemet ud fra et bestemt perspektiv for bedre at forstå kompleksiteten • UML binder analyse, design og kode sammen. • ældre strukturerede metoder bruger forskellig notation i analyse og design Lektion 4 - SWK

16. UML model og kode UML modellen kan mappes til forskellige platforme fx Java, og automatisk omsættes til kode Lektion 4 - SWK

17. UML grundelementer er objekter • UML bygger på, at det der skal modelleres, kan betragtes som en samling af interagerende objekter • Der er to hovedaspekter: • Den statiske struktur, som er objekterne i systemet og deres relationer • Den dynamiske opførsel, der beskriver hvordan objekterne kalder hinanden i run time tilstanden Lektion 4 - SWK

18. UML strukturer • Byggeklodser • symboler for ting som fx en klasse eller use case • symboler for relationer • diagrammer der er views af modeller over ting og deres relationer • Fælles mekanismer • specifikationer og semantik • udvidelse med vigtige detaljer på diagrammerne • fælles beskrivelser af elementer ved klassificering og interfaces • udvidelse med fx egne modelleringselementer • Arkitektur Lektion 4 - SWK

19. Oversigt over UML diagrammer Lektion 4 - SWK

20. Eks. Specifikationerogsemantik Lektion 4 - SWK

21. Eks. Udvidelserafmodelelement med vigtigedetaljer Lektion 4 - SWK

22. Classifier and instance Lektion 4 - SWK

23. Lektion 4 - SWK

24. Eksemplerpåstereotyper Lektion 4 - SWK

25. UP bygger på en 4+1 View arkitektur Lektion 4 - SWK

26. Lektion 4 - SWK

27. UP ~ RUP Lektion 4 - SWK

28. Hvorfor UP ? • De hidtidige metoder er utidssvarende • Behov for en ”reference proces” • Behov for en proces der kan • guide et teams aktiviteter • styre teamets og den enkeltes opgaver • specificerer hvilke opgaver der skal løses • angiver kriterier for overvågning og måling af et projekts resultater Lektion 4 - SWK

29. UP • Understøtter iterationer og illustrerer god udviklingspraksis. • Drevet af use cases og risici • Arkitektur centreret • Iterativ og inkrementel • Beskrives normalt ud fra 3 perspektiver: • Et dynamisk perspektiv, der viser faserne over tid • Et statisk perspektiv der viser procesaktiviteterne (workflows/discipliner) • Et udførende perspektiv som viser god praksis • Kritiseres af nogen for at være for tung! Lektion 4 - SWK

30. Lektion 4 - SWK

31. Workflows Lektion 4 - SWK

32. time Faser Inception Elaboration Construction Transition • InceptionMål og afgrænsning • Elaboration Arkitekturens basis • Construction Systemet gjort køreklar • Transition Færdig produkt release Lektion 4 - SWK

33. Fokus i inception fasen • I denne fase er det afgørende kriterium gennemførbarhed opnået gennem: • identificering og reducering af risici • arbejde med use case modellering af vigtige krav • opstilling af en første arkitektur • udarbejdelse af et første estimat • forretningsmæssige/økonomiske overvejelser (inception kan oversættes med påbegyndelse - så der er ingen mystik Lektion 4 - SWK

34. Milestone efter inception Lektion 4 - SWK

35. Fokus i elaboration fasen • I denne fase er det afgørende kriterium evnen til at bygge systemet indenfor en given økonomisk ramme ved at • identificere og reducere risici af væsentlig betydning for systemets konstruktion • specificere de fleste use cases og dermed systemets funktionalitet • præcisering af systemets arkitektur • udarbejdelse af projekt plan for konstruktionsfasen • præcisering af estimater og overvejelser over den forretningsmæssige side(elaboration kan oversættes med uddybning….) Lektion 4 - SWK

36. Milestone efter elaboration Lektion 4 - SWK

37. Fokus i construction fasen • Det er et afgørende kriterium at få udviklet et system som er i stand til at fungere i brugernes omgivelser • Dette opnås ved en serie af iterationer, som leder til nye ”byggesten”. Gennemførligheden af systemet er synlig ud fra de konstruerede dele af systemet Lektion 4 - SWK

38. Milestone efter construction Lektion 4 - SWK

39. Fokus i transition fasen • Målet med denne fase er at opnå et system, der er klar til at gå i drift. Opnås ved: • at løse de problemer der ikke blev konstateret tidligere i forløbet, herunder deciderede fejl • planlægge brugerkurser mv. Lektion 4 - SWK

40. Milestone efter transition Lektion 4 - SWK

41. Den iterative tilgang i UP er risikodrevet • En risiko er et anliggende ved et projekt som, der er en sandsynlighed for, kan ødelægge eller påvirke systemets succes • Kategorisering af risici • tekniske risici • ikke tekniske risici Lektion 4 - SWK

42. Tekniske risici • Tekniske risici kan inddeles i fire grupper: • Risici i forbindelse med funktionelle og ikke funktionelle krav • Risici i forbindelse med ny teknologi • Risici relateret til arkitektur(integration af delsystemer, kvalitet af eksterne komponenter ,,,) • Risici relateret til performance Lektion 4 - SWK

43. Ikke tekniske risici • Risici som ledelsen har mulighed for umiddelbart at tage hånd om, f.eks. • urealistisk tidsplan fra en kundes side • afhængighed af delleverandører, som ikke tidligere har været anvendt • mangel på bestemte ressourcer • Det er ikke denne type risici UP tager sigte på Lektion 4 - SWK

44. Håndtering af risici • Når risici er identificeret og prioriteret, skal det besluttes, hvordan de håndteres • Der er ifølge UP grundlæggende fire valg • undgå risikoen ved at ændre planer og/eller krav • begræns eller indkapsl risikoen • afprøv risikoen. Hvis den materialiseres (viser sig at være reel) må den genovervejes • nogle risici kan ikke fjernes, men må overvejes og besluttes ud fra en foretaget risikoanalyse Lektion 4 - SWK

45. Manifesto for Agile Software Development Lektion 4 - SWK

46. Principles of agile methods Lektion 4 - SWK

47. Klasser og objekter Lektion 4 - SWK

48. UML klasse notation Lektion 4 - SWK

49. Lektion 4 - SWK