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,
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
-3-
... 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
-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()