Ladda ner presentationen
Presentation laddar. Vänta.
1
Objektorienterad Modellering Programmering och Analys
OOMPA 2D1359 & 2D1360 Föreläsning 1 Objektorienterad Modellering Programmering och Analys Introduktion och översikt Hemsida: Registrering: res checkin oompa99 Hemkatalog: /info/oompa99 Kursmöte Newsmöte: news:nada.kurser.oompa Kursledare Björn Eiderbäck, Rum 1641, Osquars Backe 2, tel
2
Mål (saxade ur den formella beskrivningen)
ge ingående kännedom om principerna och begreppen bakom objektorienterad analys, design och programmering, ge kännedom om och färdighet i metoder för att utveckla, d.v.s. utforma, implementera och prova, objektorienterade program, ge erfarenhet av objektorienterad programmering för att deltagarna ska kunna tillämpa objektorienterade metoder vid design och implementation av moderna programsystem. © Björn Eiderbäck 1999
3
Kursinnehåll ... Objektorientering, principer och begrepp: objekt, klass, instans, attribut, metod, arv etc. Abstrakta datatyper, generiska datatyper, polymorfi. Objektorienterad analys, modellering och design: principiella tillvägagångssätt, exempel på notationer, kriterier på god design och robust programuppbyggnad. Systematiska principer för konstruktion av korrekta och robusta program. © Björn Eiderbäck 1999
4
... Kursinnehåll Objektorienterade språk: olika språkfamiljer, deras grundläggande begrepp och skillnader. Programmering i ett objektorienterat språk. Testning: typer av fel, felhantering, val av testdata och testprocedurer. © Björn Eiderbäck 1999
5
Kursens uppläggning ... Föreläsningar Seminarier
På kursen ingår 18 föreläsningar varav 13 i period 1 och 5 i period 2. Seminarier På kursen ingår också 6 seminarier. Varje seminarium består av två delmoment. Seminarierna redovisas i grupper vid speciella seminarietillfällen. För godkänt fordras att 9 delmoment utförs (av totalt 12) © Björn Eiderbäck 1999
6
... Kursens uppläggning ... Laborationer Tentamen
Laborationer genomförs i grupper om två personer. I kursen ingår fem stycken laborationer. Där varje laboration har två delar: en obligatorisk och en med två extrauppgifter. Den första laborationen redovisas period ett resterande i period två. Extrauppgifterna på respektive laboration kan också ersättas med speciell extrauppgiftslab. Publiceras på kursens hemsida. Laborationerna genomförs i salar plan 4 Osquars Backe 2 Tentamen Innehållet i period ett av kursen tenteras i tentaperioden efter period ett. © Björn Eiderbäck 1999
7
... Kursens uppläggning ... Seminarier Sem 1, Figurer i hierarki
Sem 2, CRC-kort Sem 3, UML och lite Java Sem 4, Kontemplation och reflektion Sem 5, Designmönster Sem 6, Modellering och UML. © Björn Eiderbäck 1999
8
... Kursens uppläggning ... Laborationer Lab 1, Figurer i hierarki
Lab 2, Designmönster Lab 3, Grafik Lab 4, Distribuering med CORBA Lab 5, VisualWorks\Smalltalk Extrauppgiftslab Värd 2-6 extrauppgifter beroende av omfattning © Björn Eiderbäck 1999
9
Kursböcker Vi kommer använda två böcker på kursen:
En fokuserad på analys, design och UML: Using UML: Software Engineering with Objects and Components, Rob Pooley and Perdita Stevens, pages, Addison-Wesley Samt en bok som handlar om objektorientering med Java: Understanding Object-Oriented Programming With Java 1st Edition, Timothy Budd, pages, Addison-Wesley © Björn Eiderbäck 1999
10
Objektorientering Historik språk...
Simula Av norrmännen Nygaard och Dahl 50-talet Simulering på kärnkraftsanläggning 60-talet utvecklades till Simula-67 Smalltalk 60-talet Allan Kays vision Dynabook 70-talet Införde terminologin och spred ideerna Resulterade i flera versioner av Smalltalk ”berömda” Smalltalk-80 som blev plattformsoberoende och använde JIT-teknik © Björn Eiderbäck 1999
11
… språk ... C++ Eiffel Objective-C Lisp-dialekter Object-Pascal mfl
Dansken Stroustrup C-syntax Inspirerad av Simula Eiffel Objective-C Lisp-dialekter Object-Pascal mfl © Björn Eiderbäck 1999
12
... språk Java Tidigt 90-tal med Gossling som drivande kraft
Inbäddade system WEB klient/server säkerket Plattformsoberoende © Björn Eiderbäck 1999
13
Mjukvarukonstruktion
Vad är ett bra system? Nyttigt och användbart Pålitligt Flexibelt Överkomligt Tillgängligt © Björn Eiderbäck 1999
14
Har vi bra system? Vi känner till att många system har "problem" eller fel Det finns exempel på system med mer drastiska fel Mariner 1 till Venus 1962 förstördes 290 s efter start, kostnad nästan 20 miljoner dollar Ariane Denvers godshanteringssystem överskred budget med 50% Londons ambulanssystem Therac-25 Hotmail ... © Björn Eiderbäck 1999
15
Hur ser ett bra system ut?
Problem Människans kognitiva förmåga är begränsad Ett bra system är välstrukturerat och nedbrutet på mindre delar som kan förstås och förändras utan att andra delar i onödan påverkas Man använder välkända designmönster Systemen brukar ha: svag koppling mellan delar sammanhållna delar inkapsling används vara byggda med utgångspunkt från respektive moduls gränssnitt © Björn Eiderbäck 1999
16
Inkapsling och lös koppling
Inkapsling är när en klient eller modul inte får veta mer än vad som som "finns i" gränssnittet hos ett annat objekt (som det använder) Lös koppling är när olika moduler, eller komponenter, är så lite beroende av varandra som möjligt © Björn Eiderbäck 1999
17
Fokusera på gränssnitt
Det har i många situationer visat sig bra om man designar ett system med utgångspunkt från komponenternas gränssnitt istället för beteende Då brukar det vara enklare att ändra eller byta ut en viss modul eller komponent än annars © Björn Eiderbäck 1999
18
Abstraktion Med abstraktion menas att detaljer elimineras och att man fokuserar på väsentligheter När man abstraherar "förloras" vissa detaljer Graden av abstraktion kan variera i olika beskrivningar av ett system Analys är mer abstrakt än Design som är mer abstrakt än Konstruktionen eller koden © Björn Eiderbäck 1999
19
Komponentbaserad konstruktion
Man har länge eftersträvat konstruktion av system mha av pluggbara komponenter, ibland enligt legometafor Objektorientering underlättar detta angreppsätt men är ändå inte lösningen på alla problem © Björn Eiderbäck 1999
20
Bygga (stora) system Process Faser Iteration Olika detaljnivå
Använd en process med klart avskiljbara faser, där slutprodukten är utgånsgpunkt för nästa fas Faser En fas är en viss typ av moment i systemets utveckling, tex analys, design eller konstruktion Iteration Upprepa hela processen om och om igen där varje fas successivt "förbättras" Olika detaljnivå Olika faser ger olika detaljnivå och olika beskrivningsätt beskriver ett system på olika sätt © Björn Eiderbäck 1999
21
OO Historik Metoder ... Problem Flera metoder utvecklades på 80-talet
Svårt att utveckla system 80% underhåll Modultänkande Formalism fast enkel och användbar Kommunikation Flera metoder utvecklades på 80-talet OMT ObjectOry Booch Shlaer-Mellor Coad-Yourdon ... © Björn Eiderbäck 1999
22
… UML ... Unified Modeling Language UML 90-talet
Förening av tre dominerande metoder ”Standard”, OMG Mer notation än metod (än så länge) Ej (för) stringent = användbart © Björn Eiderbäck 1999
23
… UML … © Björn Eiderbäck 1999
24
… UML © Björn Eiderbäck 1999
25
Objektorientering Ett sätt att se världen Meddelanden och metoder
Agenter som kommunicerar Dessa agenter kallas för objekt Objekten självständiga enheter Meddelanden och metoder Objekten kommunicerar genom att skicka meddelanden till varandra Hur ett objekt skall reagera på ett visst meddelande beskrivs i en metod Olika objekt kan reagera olika på samma meddelande Exempel: kalle.sitt() ger inte samma resultat som fido.sitt() Där kalle är en människa och fido en hund © Björn Eiderbäck 1999
26
Klasser En viss typ av objekt är definierad av en klass (eng class)
Ett objekt av en viss klass kallas för en instans (eng instance) Exempel-1 Klassen Bil Kan ha instanserna Volvo, SAAB, Renault, mfl Exempel-2 Klassen Människa Kan ha instanserna Kalle, Olle, Lisa, Greta, osv Exempel-3 Klassen Punkt Kan bla ha instanserna (10, 20), (13, 47), (200, -10) © Björn Eiderbäck 1999
27
Meddelanden och metoder
En uppmaning till ett objekt att utföra något kallas för ett meddelande (eng message) volvo.moveBy(10, 20); Beskrivningen av beteendet av ett visst meddelande kallas för metod (eng method) public void moveBy(int x, y) {position.x = position.x + x; position.y = position.y + y;} Objektet som uppmanas att utföra ett meddelande brukar kallas för mottagare (eng. receiver) mottagare meddelande argument © Björn Eiderbäck 1999
28
Klasshierarkier och arv
Klasser ordnas i hierarkier Window Win95Window MacWindow På tavlan Ellipse Circle Person Student En subklass ärver från sina superklasser Både attribut och metoder Student programme courses isReadyWithAllCourses() Person name socSecNo age() isMale() © Björn Eiderbäck 1999
29
Metodbindning Ett meddelande till ett objekt p = new Person();
p.age(); resulterar i att en sökning efter metod med samma namn söks i objektets klass Student programme courses isReadyWithAllCourses() Person name socSecNo age() isMale() om metoden inte hittas i klassen fortsätter sökningen i superklassen p = new Student(); p.age(); © Björn Eiderbäck 1999
30
Polymorfi och överskrivning
Olika klasser kan ha metoder med samma namn, s.k. polymorfi Rectangle paint() Ellipse paint() Cartoon paint() Button paint() Subklasser kan skriva över (eng. override) metoder i superklasser MotorVehicle numberOfWheels() Car Boat Ellipse paint() Circle Rectangle paint() Square © Björn Eiderbäck 1999
Liknande presentationer
© 2024 SlidePlayer.se Inc.
All rights reserved.