Ett modelleringsspråk : Exempel Fönster Klassnamn Unified Modelling Language Av Booch, Jacobson, Rumbaugh Exempel: En klass position storlek Attribut (instansvariaböe) Resultatet av en sammanslagning av tidigare system Stort system. Beskrivs i ett antal läroböcker & manualer Vi ser på hur man kan beskriva datastrukturer (objekt och klasser) i. ( har mycket annat, tex diagram för dynamisk modellering och use-case) öppna() stäng() flytta() visa() Ofta utelämnas attribut & metoder pga platsbrist (eller: för att göra modellen tydligare) Operationer (metoder) Objectorienterad programmering Sida 1 Objectorienterad programmering Sida 3 : Ansvar : tre huvudanvändningar Analysmodell: analysera problemformuleringen Designmodell: rita upp programmet i stora drag Reverse-engineering: hjälp att förstå beintligt program Ett fjärde fält i klassdiagrammet. Datum Datum(år, mån, dag) Lagrar information om visst datum Objectorienterad programmering Sida 2 Objectorienterad programmering Sida 4
Association Samband mellan klasser Bok 0..* 1 Bibliotek Två klasser har nåt att göra med varandra Almanacka Datum Klassen Almanacka använder klassen Datum. 0 eller flera böcker associerade till ett visst bibliotek Associationen kan tillåta både att man tar reda på till vilket bibliotek en viss bok tillhör att man tar fram en lista på alla böcker i ett visst bibliotek Objectorienterad programmering Sida 5 Objectorienterad programmering Sida 7 Generalisering (I Java: Att en klass ärver en annan, att den ärvande klassen på nåt sätt är mera specifik) Exempel: Mera komplext exempel: Fordon Fordon motorstyrka Cykel 0..* äger tillhör 1 Person namn ålder Objectorienterad programmering Sida 6 Objectorienterad programmering Sida 8
Exempel (forts) Ett fordon är antingen en bil eller en cykel Associationsbegreppet En fördel med associationsbegreppet: Man tvingas tänka över multiplicitet Varje cykel har en associerad person (cyklisten) Hur många telefonnummer kan en person ha? Pilen anger att vi kan gå från cykel till cyklist, men ej tvärtom Den svarta pilen vid äger anger hur associationen ska läsas Hur många fruar? Hur många adresser? Hur många föräldrar? Hur många nationaliteter? Objectorienterad programmering Sida 9 Objectorienterad programmering Sida 11 Multirelationer Om inget annat anges är en association (relation) många till många. Bra eller dåligt? - Person Associationsbegreppet (forts) Det visar sig ofta att man vill öka multiplicitet (att en person kan ha flera telefonnummer eller adresser, tex) Det visar sig ofta att man vill kunna gå åt båda hållen Lärare undervisar Student Objectorienterad programmering Sida 10 Objectorienterad programmering Sida 12
Sammansättning Användningsfall, (scenarier, use cases) En slags association. Anger att ett objekt är en del av ett annat Utgå från viktiga användningar av systemet Exempel (bankomat) Kund vill ta ut pengar Kund vill kontrollera saldot Beskriv i modellen hur tjänsten ska utföras Hjul Kräver förstås att systemet har tillräcklig funktionalitet för att kunna tillhandahålla tjänsten Objectorienterad programmering Sida 13 Objectorienterad programmering Sida 15 Olika typer av diagram i Objekt-orienterad utveckling Användarfallsdiagram Saker man vill uppnå: Klassdiagram (redan beskrivet) Dynamisk modellering: tillståndsdiagram, sekvensdiagram Interaktionsdiagram Komponentdiagram - beskriver implementeringsmoduler Det finns även diagram för att beskriva den fysiska realiseringen, processer,... en systematisk metod för att gå från problembeskrivning till färdigt system metod för formell beskrivning av problem som ska lösas metod för övergripande beskrivning av systemet [en ritning] kunna ge beskrivningar av olika delsystem så att varje programmerare (i ett större projekt) vet vad han ska göra Objectorienterad programmering Sida 14 Objectorienterad programmering Sida 16
Objekt-orienterad programutveckling Att gå från problem till färdig lösning Iterativ utveckling Unified process Exempel: Affärssystem för företag (något eller några av bokföring, fakturahantering, lagerhantering, orderhantering) Inte tekniskt komplicerat. Men: systemet ska integreras i befintlig verksamhet. Av Jacobson et. al samma arbetsmoment som vattenfallsmodellen, men ej ett i taget Iterationer av fix längd Eventuellt anpassas till befintliga system. Varje iteration arbetar i alla faser Viktigt att anpassa till kundens önskemål. Varje iteration producerar ett körbart system Kunden ej tekniskt kompetent stor risk för missförstånd. Objectorienterad programmering Sida 17 Objectorienterad programmering Sida 19 Klassisk modell för systemutveckling (vattenfallsprincipen) Extreme programming Utveckla i små steg, fokusera på nästa version av systemet Fyra faser: Unit testing 1. Analys Enkelhet 2. Design Refactoring 3. Implementation/unit testing Parprogrammering 4. Integration/testning OBS: vattenfallsprincipen har stora brister! Gemensamt ägande av kod Ständig integration Kund på plats Objectorienterad programmering Sida 18 Objectorienterad programmering Sida 20