Softwarekonstruktion

Præsentationer af emnet: "Softwarekonstruktion"— Præsentationens transcript:

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 Ulemper Anvendelse
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 Ulemper
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 spiralmodel eksempel
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 Fælles mekanismer Arkitektur
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. Specifikationer og semantik
Lektion 4 - SWK

21 Eks. Udvidelser af modelelement med vigtige detaljer
Lektion 4 - SWK

22 Classifier and instance
Lektion 4 - SWK

23 Lektion 4 - SWK

24 Eksempler på 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 Faser Inception Mål og afgrænsning Elaboration Arkitekturens basis
Construction Transition time Inception Må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