BEGREPP

Question 1

Analys och design

Answer 1

• Analys – rätt sak

* Design –rätt sätt

Question 2

GRASP (1)

Answer 2

• Controller - Represents overall system/use case scenario (controls a system operation).
• Creator - Creates C if aggregates- , records-, closely uses- or has initializing info. for C.
• Information Expert - Assign responsibility where most information exists to fulfill it.
• High Cohesion (evaluative) - Keep classes highly focused, manageable, understandable.
• Low Coupling (evaluative) - Keep classes weakly connected/knowledgeable of others.

Question 3

GRASP (2)

Answer 3

• Polymorphism - Assign responsibility for variation of behaviors based on type.
• Protected Variations - Protect against variations by wrapping classes in an interface.
• Pure Fabrication - Class specially made up to achieve low coupling and high cohesion.
• Indirection - Assign mediation responsibility between objects to intermediate object.

Question 4

SOLID – Design Principles

Answer 4

…

Question 5

GoF Designmönster

Answer 5

• I sin bok presenterade GoF 23 designmönster, indeladei 3 kategorier

• Skapelsemönster (Creational Patterns)
Beskriver olika sätt att styra skapandet av objekt

• Strukturella mönster (Structural Patterns)
Beskriver hur klasser och objekt kan kombineras för att bilda större strukturer

• Beteendemönster (Behavioral Patterns)
Beskriver olika sätt för klasser och objekt att kommunicera med varandra

Question 6

Abstraction

Answer 6

Nedbryning av problem som döljer/gömmer komplexa detaljer

Mental model som fokuserar på ett objekts viktiga beteende och viktiga egenskapar och som

Question 7

Seperation of concerns

Answer 7

Tydlig skillnad mellan intra-komponent och inter- komponent. Seperation av affärslogik och gränssnitt.

Exempel : Lager indelning, Modeller för beräkning av saldo (business logik), modeller för presentation av information till kund (Gränssnitt)

•Att dela in din applikation i distinkta funktioner med så lite överlappning i funktionalitet som möjligt.
- Den viktiga faktorn är minimering av interaktionspunkter för att uppnå high cohesion och low coupling

Question 8

Egenskapar av komplexa system (grunnd till OOAD)

Answer 8

• hierachical,
• seperation of concerns,
• relative primitives
• common patterns
• stable intermediate forms

Question 9

Nedbrytning av processen

Answer 9

1. Text analys : identifiering av koncepter (Klasser & attribut)
2. Problem nedbrytning/roller ex: Medborgare ansöka om bank konto
3. Abstraktion : fokusera på systemets intressanta komponenter.
4. Hierarki – hur relatera man olika abstraktion med varan

Sammanfattning enligt kurslitteratur: Decompose, Abstraction, Identify hierarchies.

Question 10

Hur skilja sig OOD , OOA och OOP

Answer 10

• OOA: Analys nedbrytare problem som resulterar i en domänmodell (logiska, fysiska och dynamiska representation av komponenter) .
• OOD: Analys som abstraherar KLASSER och OBJEKT och resulterar i en eller flera designmodell.
• OOP :Är själva kodprogram som bestå av klasser och objekt

Question 11

Vad är de främsta skillnaderna mellan den Konceptuella domänmodellen och Designmodellen? T.ex. vad visas och vad visas inte i respektive modell.

Answer 11

Konceptuella domänmodellen – visualisera viktiga koncept i domänen och tillhörande
relationer mellan dessa koncept. Fokus i domänmodellen är övergripande systembeskrivning.
Inga riktningar mellan klassrelationer som representera dessa koncept.

Question 12

• Objekt

Answer 12

är en designkonstruktion som specificerar:
• Identitet : Typ och referens
• Tillstånd : Variabel
• Tjänster : Metoder

Question 13

Objekt & Klass

Skillnad *Viktigt

Answer 13

En klass är en beskrivning av
• Objekttyp
• Egenskaper
• Beteende

Att skapa ett objekt kallas INSTANTIERING. Ett objekt är en INSTANS av en klass

Skillnad :
•En klass beskrivs i programkoden medan objekten skapas och existerar under exekveringen av programmet.

Konkret klass : Vanlig klass som kan instansieras

Question 14

ABSTRAKT KLASS

Answer 14

Klass utan instans ( går inte att skapa objekt av klassen).

• Har ofta (minst) en abstrakt metodoch Tvingar alla subklasser att implementera de abstrakta metoderna.
• Skrivs i UML med kursiv

Question 15

Grundläggande Principer för OO-design

Answer 15

• Abstraktion –minska komplexitet
• Inkapsling –återge kontroll till objekt. Skapar dataintegritet.
• Arv –återanvändning av kod
• Polymorfism (Moduler) -Återanvändning

Question 16

Information hiding

Answer 16

Vid inkapsling har objekt har ansvar för attribut. objekt ska hantera vem får komma åt informationen?

• Objekt A kan ta reda på attribut i objekt B endast genom att anropa motsvarande metod som kan ge meddela information från Objekt B.

Enbart objekt som har rättighet till den, kan uppnås genom Interface och Synlighet.

Question 17

Skillnad mellan abstraktion & inkapsling

Answer 17

• Abstraktion använda oftast inkapsling

* Inkaspling behöva inte nödvändigtvis använda abstraktion

Question 18

Hierarki

Answer 18

Hierarki, resultant: beskrivning av övergripande relation mellan olika abstraktioner/modeller

• En abstraktion kan vara en typ av en annan abstraktion
Volvo och BMW är en/typ av Fordon
Systemvetare är en typ av program
• En abstraktion kan vara en del av en annan abstraktion

Question 19

“Typ av” relation - Arv (Hierarki)

Answer 19

• Superklass = generalisering =Base class
• Subklass = specialisering = Derived class

Enkel arv: En Två eller flera subklasser ärver från en super klass.

Multi arv: En //sub// klass kan ärva från flera //super// klasser

Question 20

“Del av” relation - komposition

Answer 20

Två klasser som kan INTE existera utan varandra.
-objekten kan ha olika livslängder
En klass är en ”del av”, via en referens

kort: oberoendet relation, objekt A & B –olika livslängd, B är en del av A
• “The death relationship”

Question 21

“Del av” relation -aggregation

Answer 21

Två klasser som kan existera oberoende av varandra.
-objekten måste ha samma livslängd
En klass är en ”del av”, ”på riktigt”

Kort :beroendet relation, objekt A & B -samma livslängd, B innehåller A. Mindre stark förhållande än komposition.

Question 22

relation - association

Answer 22

varken ”typ av” eller ”del av” relation - association
Två klasser som känner till varandras existens
Bankontor och Banklån

Kort relation, objekt A & B är medvetten om varan

Question 23

Modularity

Answer 23

Paketera abstraktioner till logiska moduler.
Kommunikation via gränssnitt.

Slutresultat:“cohesive”(enhetliga) och “loosely coupled” (svagt sammankopplade) moduler.

Question 24

F3 UML

Answer 24

• Unified Modeling Language (UML) är ett modelleringsspråk för att beskriva olika aspekter av objektorienterade system. Definierar ett systems struktur och beteende.

• visualisera
• specificera
• konstruera
• Dokumentera
[There are four kinds of things in the UML: 1. Structural things 2. Behavioral things 3. Grouping things
4. Annotational things]

Question 25

Modellering

Answer 25

Modellering är ett sätt för att: • Minska komplexitet av ett problem • Öka förståelse av ett system

Question 26

En objektorienterad process

Answer 26

Är iterativ •Analys, design, konstruktion och test upprepade gånger •Högre och högre detaljeringsgrad för varje iteration Är inkrementell •Någonting synligt levereras efter varje iteration •Den delfunktion/komponent utvecklas (iterativt) •Systemet byggs på vartefter med fler delfunktioner/komponenter

Question 27

Unified Process (UP)

Answer 27

• UP är en iterativ utvecklingsprocess för projekt som tillämpar objektorienterad utveckling. • Utvecklingen är organiserad I en uppsättning korta mini-projekt s.k. iterationer. • Slutprodukten av varje iteration är ett testat, integrerat och körbart system. • I ett UP-projekt är arbetet och iterationer organiserat I faser: Inception Elaboration Construction Transition Detta är inte den traditionella vattenfallsmodellen!

Question 28

Konstruktor

Answer 28

En konstruktor används för att skapa och initiera nya instanser av en klass. En konstruktor har alltid samma namn som klassen, men en klass kan ha flera konstruktorer som då måste ha olika argumentlistor. ``` public class Invoice : IInvoice { public Invoice(Reservation r, double distanceDriven) { ... } osv osv ```

Question 29

Konceptuell domänmodell arbetsprocess

Answer 29

Konceptuella klasser, attribut, associationer som hämtas ur problemdomän. 1. Läs noggrann problembeskrivning och utföra textanalys på problemdomän. 2. Med utgångspunkt i problembeskrivning, välja ut och motivera fem möjliga abstraktioner. 3. Föreslå nödvändiga konceptuella klasser samt dess attribut för problembeskrivning 4. Ge förslag på en fullständigt konceptuell domänmodell

Question 30

- Klassdiagram (Elaboration)

Answer 30

- Namn, attribut, relationer, operationer, beroende, arv * Klass är den grundläggande entiteten i ett objektorienterat språk. • Innehåller fält (attribut) och metoder (operationer). * Klasser är mallar för instanser.

Question 31

Designmönster

Answer 31

Designmönster är mikroarkitekturer

Question 32

Low Coupling (GRASP)

Answer 32

Svag koppling mellan objekt / klass, detta gör vi genom att tilldela ansvar. Få kopplingar ger lågt beroende.

Question 33

High cohesion (GRASP)

Answer 33

Keep classes highly focused, manageable, understandable. : Ett klass fokuserat, varje klass ska ha väl samlade ansvar, och inte ta hand om flera saker.

Question 34

Controller (GRASP)

Answer 34

Tilldela ansvar till den klass som representerar hela systemet. Represents overall system/use case scenario (controls a system operation).

Question 35

Creator (GRASP)

Answer 35

A kan skapa C om det uppfyller kriterier som aggregerar, registrerar, använder nära eller har initialisering information för C.

Question 36

Information Expert (GRASP)

Answer 36

Tilldela ansvar där mest information finns.

Question 37

Indirection (GRASP)

Answer 37

Assign mediation responsibility between objects to intermediate object. Ansvar till ett mellanliggande objekt så att de andra objekten mellan inte har direkt koppling.

Question 38

Protected variation (GRASP)

Answer 38

Skydda mot variationer genom att lasta in klasser i ett gränssnitt.

Question 39

Polymorphism (GRASP)

Answer 39

Tilldela ansvar för Varierande typ av beteende. En operation kan ha många former. Här används oftas Abstrakta klasser eller interface. * Poly = Many * Morph = Shapes * Samma meddelande kan skickas till olika klienter ex beräknaproto() under båda paket och brev klass. * Olika kunder kör meddelandet på sitt eget sätt * Flera beteenden för samma meddelande kallas polymorfism

Question 40

Pure Fabrikation (GRASP)

Answer 40

Skapa ett nytt objekt för att uppnå hög sammanhållning, och låg koppling... kan återanvändas.

Question 41

Design Patterns GoF : Skapande mönster (Creational patterns)

Answer 41

Skapande mönster (Creational patterns) Beskriver olika sätt att styra skapandet av objekt, dvs används för attvinstantiera objekt och dölja hur de egentligen skapas och kombineras.

Question 42

Design Patterns GoF : Strukturmönster (Structural patterns)

Answer 42

Strukturmönster (Structural patterns) | Beskriver hur klasser och objekt kan kombineras för att bilda större och komplicerade strukturer.

Question 43

Design Patterns GoF : Beteendemönster (Behavioral patterns)

Answer 43

Beteendemönster (Behavioral patterns) Beskriver olika sätt för objekt att kommunicera, dvs fokuserar på att lösa problem som relaterar till beteenden hos system.

Question 44

Domänmodell v.s. Designmodell

Answer 44

Den konceptuella domänmodellen är ett analysdiagram. Visar inte operationer Designmodellen visar operationer och synlighet (pilhuvud på associationen).