Designmönster - EMW. Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL:

Transkript

1 Designmönster - EMW Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: arbetar på Inst. för Datavetenskap, Cth & Gu, 50% och Software Laboratory (FT/K), EMW, 50% Designmönster - EMW Innehåll: Översikt av arbetet med designmönster på EMW Presentation av examensarbete: Design Patterns Presentation av examensarbete: Beskrivning av oo-system med hjälp av designmönster Presentation av ytterligare arbete med att försöka beskriva mjukvaruarkitekturer m.h.a. mönster (Kent.Petersson@emw.ericsson.se) 1

2 Designmönster - EMW Designmönster, studiecirkel genomgång av GoF-boken, april-juni, 1999 (genomförd ytterligare 2ggr i FT/Ks regi) Examensarbete om Designmönster: Marcus Engene & Carl Åsman, Göteborgs Univ: Design Patterns våren 1999 grundläggande genomgång av olika tillämpningar på mönster Designmönster - EMW Studiecirkel om arkitekturmönster: genomgång av POSA-boken (PatternsOfSoftwareArchitecture) mars-maj, 2000 Examensarbete om arkitekturmönster: Stefan Wendt, HISkövde: Beskrivning av objektorienterade system med hjälp av mönster. våren 1999 Försök att beskriva arkitekturen i ett projekt med hjälp av arkitekturmönster: hösten (Kent.Petersson@emw.ericsson.se) 2

3 Examensarbete 1: Software Patterns. Carl Åsman och Marcus Engene, Institutionen för datavetenskap, Göteborgs Universitet vårterminen Examensarbete 1: Design Patterns Examensarbetet är en bred och grundlig genomgång av begreppet Software Patterns : vad som är ett mönster hur mönster kan introduceras på ett företag vilka konsekvenser som mönsteranvändning kan medföra (Kent.Petersson@emw.ericsson.se) 3

4 Examensarbete 1: Design Patterns Innehåll: Syfte och läsanvisning Var mönster kommer från. Olika typer av mönster (idiom, designmönster, arkitekturmönster, organisationsmönster, antimönster ) Tillämpning av mönster Olika sätt att introducera mönster i ett företag Mönster hos FY/D (en avdelning på EMW) Examensarbete 2: Beskrivning av objektorienterade system med hjälp av designmönster. Stefan Wendt, Institutionen för datavetenskap, Högskolan i Skövde vårterminen (eller från (Kent.Petersson@emw.ericsson.se) 4

5 Examensarbete 2: Beskrivning av oo-syst. m.h.a. designmönster Problem: I detta projekt har designmönster studerats utifrån aspekten att använda dessa för att förbättra dokumentationen av objektorienterade programvarusystem. Metod: Användning av reverse engineering, dvs. analysera programsystemet i syfte att skapa en representation av detta på en högre abstraktionsnivå. Utgångsdata: källkod Metod: BACKDOOR (Shull, 96) Examensarbete 2: Beskrivning av oo-syst. m.h.a. designmönster Slutsatser (i examensarbetsrapporten): Designmönster kan användas för att öka förståelsen för ett system och det går att identifiera designmönster i efterhand. Det är svårt att skapa en förståelse för helheten genom att bara använda designmönster. Det finns en risk att arkitekturen förvanskas vid reverse engineering. Att använda mönster för dokumentation kompletterar de två övriga och mer kända användningsområdena (återanvändning och gemensamt språk) (Kent.Petersson@emw.ericsson.se) 5

6 Examensarbete 2: Beskrivning av oo-syst. m.h.a. designmönster Slutsatser (mina): Jag anser att ett mönster beskriver ett problem/lösningspar och där problemet är nyckeln till användandet av ett mönster. Det är därför svårt att med reverse engineering (bottom-up) dokumentera ett program med mönster. Jag anser att en del av de hittade mönstren inte i någon högre grad bidrar till förståelsen av programmet medan andra ger bra förståelse för programmet samt ger förslag på förbättringar i programstrukturen Jag anser att man bör använda mönster top-down om de skall bidra till förståelsen och dokumentationen av ett program Examensarbete 2: Beskrivning av oo-syst. m.h.a. designmönster Slutsatser (mina): Designmönster (från GoF) är begränsade när man skall uttrycka intentionen med programlösningar. Arkitekturmönster (från POSA) beskriver lösningar i termer av programdelar (många klasser). Dessa delar kan vara svåra (omöjliga) att hitta i ett klassdiagram. Mönster har mycket med användning (dynamik) att göra. Detta syns inte i klassdiagrammet. Flera mönster har samma klass-struktur! Mönster bra för refactoring! Mönster handlar om återanvändning / kräver mycket insikt i programmets användning (Kent.Petersson@emw.ericsson.se) 6

7 Examensarbete 2: Beskrivning av oo-syst. m.h.a. designmönster Slutsatser (min sammanfattning): Mönster är bra som verktyg för att dokumentera program. Designmönster ibland på för låg abstraktionsnivå. Mönster är bra som verktyg för att förbättra strukturen på existerande program (refactoring) Mönster för dokumentation kräver stor insikt i hur programmet fungerar programmets struktur vilka förändringar som programmet kan tänkas utsättas för dvs. det är lika svårt som att designa programmet (och i själva verket är det samma sak!!) Efter dessa examensarbeten, hur skulle vi fortsätta? Vi bestämde att försöka beskriva arkitekturen av ett större existerande system med hjälp av mönster. System: Databehandlingen i ett spaningsradarprojekt. Vi hade för några år sedan försökt göra en arkitektur för att befrämja återanvändningen av delar mellan olika projekt (inom samma familj av produkter) Beslutade att använda mönster (arkitekturmönster) för att beskriva denna arkitektur och speciellt de frågeställningar som beaktades vid designen. Se om vi kunde finna detaljer som skulle kunna förbättras (Kent.Petersson@emw.ericsson.se) 7

8 Resultat: Rapport: Kent Petersson: Beskrivning av arkitektur med hjälp av mönster. Ett exempel Speciella hänsyn vid definition av arkitekturen: Återanvändning (reuse), utbyggbar. Så oberoende delar som möjligt. Samma arkitektur i många (alla) projekt Problem med förändringar av hårdvara/operativsystem. Strukturera med avseende på abstraktionsnivå (användare - maskin). Problem med att få delarna så oberoende av varandra som möjligt för att förbättra flexibiliteten. Lösning: introducera en lagrad arkitektur (beroenden nedåt) Mönster: Layers (POSA-boken) (Kent.Petersson@emw.ericsson.se) 8

9 applikationslager supportlager kärnlager Alla komponenter är självständiga program (processer). Alla gränssnitt är skrivna i IDL (Interface Definition Language) All kommunikation mellan komponenterna sker med hjälp av CORBA. Detta medför att: vi har frihet att ta med olika applikationer i olika projekt vi har separerat logisk (funktionell) arkitektur från fysisk (hårdvaru) arkitektur. Komponenter kan exekvera på samma eller olika maskiner (Kent.Petersson@emw.ericsson.se) 9

10 Problem med att strukturera funktionaliteten i lämpliga delar Lösning: använd dataflödesprincipen Mönster: Pipes and Filters (POSA-boken) Följning Korrelering Hotutvärdering Insatsplanering Nytt problem: Användningen av Layers och Pipes & Filters fungerar inte bra tillsammans! Applikationerna (Komponenterna i översta lagret) får inte vara direkt beroende av varandra. Lösning: Introducera speciella datalagringskomponenter i supportlagret. Applikationerna hämtar indata och lämnar resultatet i datalagringskomponenterna (Kent.Petersson@emw.ericsson.se) 10

11 applikationer Följning Korrelering Hotutvärdering Insatsplanering Plottar Följen System mål Hotdata datalagringskomponenter Problem: Applikationerna hämtar data från datalagringskomponenterna (pollning). Detta blir ineffektivt för data som sällan ändras, t.ex. olika sorters styrningar. Lösning: Händelsehantering Mönster: Publisher / Subscriber (POSA-boken) En applikation prenumererar på styrningar från datalagringskomponenten. En annan applikation (OPC) genererar en styrning genom att påverka datalagringskomponenten. Datalagringskomponenten behöver inte a priori känna till vilka applikationer som är intresserade av styrningar (Kent.Petersson@emw.ericsson.se) 11

12 Problem: En del av systemet som är speciellt ändringsbenäget är presentation/styrningsdelen. Kunderna brukar ha mycket Lösning: Separera ut presentation och styrning från de andra komponenterna Mönster: Model-View-Controller Modifiering: Vi har inte separerat View och Control utan har en komponent för båda Operator Presentation & Control Presentation Styrning Distribution View & Control Model

13 Designmönsterarbetet, slutsatser Designmönster (och andra mönster) ger en bra vokabulär för att diskutera programmeringsproblem och dess lösningar (börjar inkluderas i nyare läroböcker) Designmönster förmedlar kunskap i hur objektorienterad programmering används för att lösa verkliga problem Leta INTE efter mönster i gammal kod! Designmönster - EMW Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: (Kent.Petersson@emw.ericsson.se) 13