Transcript GRIP
OOMPA 2D1359 & 2D1360
Föreläsning 1
Objektorienterad Modellering Programmering
och Analys
Hemsida:
Introduktion och översikt
http://www.nada.kth.se/kurser/kth/2D1359
Registrering:
res checkin oompa99
Hemkatalog:
/info/oompa99
Kursmöte
Newsmöte: news:nada.kurser.oompa
Kursledare
Björn Eiderbäck, [email protected]
Rum 1641, Osquars Backe 2, tel 7906277
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
-2-
Kursinnehåll ...
Objektorientering, principer och begrepp: objekt,
Objektorienterad
klass, instans, attribut, metod, arv etc. Abstrakta
datatyper, generiska datatyper, polymorfi.
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
-3-
... Kursinnehåll
Objektorienterade språk: olika språkfamiljer, deras
Testning: typer av fel, felhantering, val av testdata och
grundläggande begrepp och skillnader. Programmering i
ett objektorienterat språk.
testprocedurer.
© Björn Eiderbäck 1999
-4-
Kursens uppläggning ...
Föreläsningar
– 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
-5-
... Kursens uppläggning ...
Laborationer
– 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
-6-
... Kursens uppläggning ...
Seminarier
–
–
–
–
–
–
Sem
Sem
Sem
Sem
Sem
Sem
© Björn Eiderbäck 1999
1,
2,
3,
4,
5,
6,
Figurer i hierarki
CRC-kort
UML och lite Java
Kontemplation och reflektion
Designmönster
Modellering och UML.
-7-
... Kursens uppläggning ...
Laborationer
–
–
–
–
–
Lab
Lab
Lab
Lab
Lab
1,
2,
3,
4,
5,
Figurer i hierarki
Designmönster
Grafik
Distribuering med CORBA
VisualWorks\Smalltalk
– Extrauppgiftslab
© Björn Eiderbäck 1999
Värd 2-6 extrauppgifter beroende av omfattning
-8-
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, 1999 280
pages, Addison-Wesley 0-201-36067-5
Samt en bok som handlar om objektorientering med
Java:
Understanding Object-Oriented Programming With Java 1st
Edition, Timothy Budd, 1998 384 pages, Addison-Wesley
0-201-30881-9.
© Björn Eiderbäck 1999
-9-
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
- 10 -
… språk ...
C++
– Dansken Stroustrup
– C-syntax
– Inspirerad av Simula
Eiffel
Objective-C
Lisp-dialekter
Object-Pascal
mfl
© Björn Eiderbäck 1999
- 11 -
... 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
- 12 -
Mjukvarukonstruktion
Vad är ett bra system?
Nyttigt och användbart
Pålitligt
Flexibelt
Överkomligt
Tillgängligt
© Björn Eiderbäck 1999
- 13 -
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 5 1996
Denvers godshanteringssystem överskred budget med 50%
Londons ambulanssystem
Therac-25
– Hotmail
– ...
© Björn Eiderbäck 1999
- 14 -
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
- 15 -
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
- 16 -
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
- 17 -
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
- 18 -
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
- 19 -
Bygga (stora) system
Process
– 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
- 20 -
OO Historik Metoder ...
Problem
–
–
–
–
–
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
- 21 -
… 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
- 22 -
… UML …
Client
Target
Adaptee
request()
specificRequest()
Adapter
adaptee
request()
© Björn Eiderbäck 1999
adaptee specificRequest()
- 23 -
… UML
Client
1:m
Adapter
4:r
© Björn Eiderbäck 1999
- 24 -
2:m’
3:r’
Adaptee
Objektorientering
Ett sätt att se världen
– 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
- 25 -
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
- 26 -
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)
volvo.moveBy(10, 20);
argument
mottagare
© Björn Eiderbäck 1999
meddelande
- 27 -
Klasshierarkier och arv
Klasser ordnas i hierarkier
Window
Person
Ellipse
Circle
MacWindow
Win95Window
Student
En subklass ärver från sina superklasser
Både attribut och metoder
Person
Student
name
socSecNo
age()
isMale()
© Björn Eiderbäck 1999
programme
courses
isReadyWithAllCourses()
- 28 -
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
Person
om metoden inte hittas i klassen
fortsätter sökningen i superklassen
name
socSecNo
age()
isMale()
p = new Student();
p.age();
Student
programme
courses
isReadyWithAllCourses()
© Björn Eiderbäck 1999
- 29 -
Polymorfi och överskrivning
Olika klasser kan ha metoder med samma namn, s.k. polymorfi
Rectangle
paint()
Ellipse
Cartoon
paint()
Button
paint()
paint()
Subklasser kan skriva över (eng. override) metoder i superklasser
Ellipse
paint()
Circle
paint()
© Björn Eiderbäck 1999
MotorVehicle
Rectangle
numberOfWheels()
paint()
Square
Car
paint()
numberOfWheels()
- 30 -
Boat
numberOfWheels()