Vi förstår inte heller OOA&D

Bakgrund

Vi har fått frågor om analys och design utifrån en bok om en metod för OOA&D, utgiven på studentlitteratur. Då läraren hänvisat till boken och studenterna säger att de inte förstår boken och frågade oss, så läste vi boken för att förstå. Vi ville inte ge svar som går emot boken, och därigenom går emot vad läraren säger, varför vi läste boken i syfte att försöka förstå och förklara den.

Dock förstod inte heller vi boken. Vi tar här bokens exempel med ett konferenssystem som “designats” som utgångspunkt för en diskussion om varför vi inte förstår.

Vi har spelat in ett pod-avsnitt också: Vi förstår inte heller OOA&D-boken

Exempel från boken som inte heller vi förstår

Vi börjar med det designade klassdiagrammet (ett urval) för konferenssystemet.

Klassdiagram       

Konferensplanering

Klassbeskrivning från boken

Nedan beskrivs klasserna (i boken under rubriken “Klasser”) i vad som beskrivs som en “specifikation”. Specifikationen specificerar “de klasser som innehåller väsentliga attribut och icke-triviala operationer”. Återigen har vi gjort ett urval enligt klassdiagrammet ovan.

Person

Syfte: är att “Registrera basupplysningar om alla inblandade personer och aggregera varje persons konferensroller”.
Attribut:

  • Efternamn
  • Förnamn
  • institution
  • adress
  • e-mail

Operationer:

  • Skapa person
  • Skapa roll(!)

Deltagare

Syfte: “Registrera människor som kommer att delta i konferensen”.
Attribut:

  • datumregistrerad
  • tillstånd (Vad är det?)

Operationer:

  • Skapa deltagare
  • Skapa funktion(!)

Funktion

Syfte: “Registrera roller som en deltagare kan spela”.
Attribut:

  • föreslaget datum
  • tillstånd (Vad är det?)

Klassen Funktion saknar operationer. (se vår kommentar nedan om varför vi tycker det är märkligt)

Kommentar

Vi tycker det är oklart vad som menas med “registrera” (se syftena för klasserna Person, Deltagare och Funktion). Designen enligt klassdiagrammet är också något vi har frågor kring. Några designfrågor:

  • Enligt klassdiagrammet så består en Person, förutom kontaktuppgifter, även av noll till många Roll:er. Klassen Roll finns inte med i klasspecifikationen dock.
  • Enligt klassdiagrammet så består en Deltagare av noll till många Funktion:er. Vad skillnaden mellan en Roll och en Funktion är framgår inte av beskrivningarna.
  • Enligt klassdiagrammet så är Roll en basklass som ärvs ned till Deltagare, Författare och Bedömare. Dock är det endast Deltagare som har en lista med Funktion:er.

Här är klassdiagrammet igen (för referens):

Konferensplanering

Översatt till Java-kod (ett försök)

För att försöka förstå designen utifrån klassdiagrammet och klasspecifikationen, så ger vi oss på att tolka designen och skapa lite kodexempel. Vad annars skulle en design syfta till, än till att vara underlag till koden som skall skrivas? I Java-kod skulle skapandet av en Person med rollen Författare kunna se ut så här, givet klassdiagram och klasspecifikationen:

// Hur skulle man kunna skapa en Person med rollen “författare”?

// 1. Skapa en Person och registrera Roll:en Författare på den:

Person förf = new Person(“Anna”, “Bok”, ...);
// Vi tolkar "operationen" "skapa person" som konstruktor

// 2. Skapa rollen (författare):

Författare roll = förf.skapaRoll(FÖRFATTARE);
// Av någon anledning så finns "operationen" "skapa roll"
// i klassen Person...

// 3. Registrera rollen, men då måste vi ha en Funktion
// och eftersom blott Deltagare kan skapa funktioner, så får vi
// skapa en Deltagare:

Deltagare d = förf.skapaRoll(Deltagare);
Funktion f = d.skapaFunktion();
// Nu kan vi medelst funktionen registrera rollen för personen:
f.registreraRoll(roll, förf);

// Nej, det här blev ju rörigt?!
// Skapa en Deltagare för att skapa en Funktion för att registrera 
// Roll:en Författare på en Person? Känns inte intuitivt, direkt...

Problem med designen (som vi förstår den)

När vi skrev kod för att skapa en Person med Roll:en Författare, uppdagades:

  • Bara Funktion:er kan “registrera” Roller
  • Bara Deltagare kan skapa Funktion:er (och har av någon anledning en hel lista på Funktion:er vid behov)
  • Personer kan skapa Roller, så för att skapa en Person med rollen Författare måste vi:
    • 1. Skapa en Person p
    • 2.1 Be p skapa en Roll r1 av typen Deltagare
    • 2.2 Be p skapa en Roll r2 av typen Författare
    • 3. Be r1 skapa en Funktion f
    • 4. Be f registrera rollen r2Person p

Svårigheter för oss att förstå diagramm och specifikation

Vår bedömning är att det är mycket svårt att förstå klassdiagrammet och “specifikationen” av klasserna ovan. Den “specifikation” av klasserna som ges talar om attribut och operationer. Attribut betyder vanligtvis “instansvariabler” (t ex varje Person har olika e-postadresser, lagrade i objektens instansvariabel för e-post). Vad “operation” betyder har vi betydligt svårare att säkert avgöra genom att läsa boken. Boken talar ibland om “beteende” (hos objekt) och “funktioner” hos systemet. Nu finns också “operationer” som är listade tillsammans med klasserna. Vi har tolkat det som instansmetoder (dvs beteende) och inte statiska klassmetoder, eftersom det listas tillsammans med attribut som måste vara instansvariabler.

Nedan följer en lista på de saker vi har svårt att förstå i klassdiagrammet och “klasspecifikationen”:

  • Vad menas med “registrera” (från syftena med klasserna) – hur och var?
    • Varför ska klassen Funktion “registrera” roller som en Deltagare kan spela?
    • Eftersom klassen Funktion saknar “operationer”, hur kan den registrera roller en Deltagare kan spela?
  • Vad menas med attributet “tillstånd” som återfinns i klassen Deltagare och klassen Funktion?
    • Menas tillstånd som i “tillstånd från någon att göra något”, i så fall vad är det, vem gav tillståndet och hur gavs tillståndet och kan man bara ha ett tillstånd (att göra en sak)?
    • Menas tillstånd som i “ett objekts tillstånd”, vad kan det då vara? Ett objekts tillstånd är en funktion av värdet i objektets instansvariabler (i vart fall enligt den terminologi som används inom objektorienterad programmering). Att ha en instansvariabel som själv heter “tillstånd” blir då obegripligt.
  • Vad menas med “skapa” som i operationen “skapa person” i klassen Person
    • Menas konstruktor?
      • I så fall, varför har Person även operationen “skapa Roll”?
        • Har klassen Person en “factory method” för att skapa Roll-objekt?
  • Varför är inte klassen Roll med i klasslistan med specifikationer av klasserna?
  • Tittar man på klassdiagrammet så ser man att det finns tre sorters Roll:er eftersom man använder UML-notation för arv:
                       Roll
                   /    |      \
          Deltagare Författare Bedömare 

           Men bara Deltagare har association till Funktion.

  • Betyder det att klassen Person i själva verket enbart “aggregerar” Deltagare:s “konferensroller”?
  • Är Person i själva verket en basklass, så att Deltagare, Författare och Bedömare egentligen ärver Person och inte Roll? Eller ärver de från både Person och Roll? Hur ska vi tolka klassdiagrammet?
  • Igen, det blir svårt att förstå att klassen Funktions syfte är att registrera roller för Deltagare, särskilt eftersom Deltagare i klassdiagramet framställs som en sorts Roll – menas att Funktion registrerar till exempel rollen Deltagare för en Person? Se ovan om att registrera rollen Författare på en Person – Bara Deltagare har operationen skapa funktion, så vi måste alltså skapa en Deltagare för att skapa en funktion för att registrera rollen Författare på en Person… Whaaat?
  • Vad är attributet “föreslaget datum” i Funktion?
  • Vad är det för skillnad på en Roll och en Funktion? Varför är inte klassen Roll med i klassbeskrivningen?

Sammanfattning

  • Vi tror att vi inte förstår klassdiagrammet – vad är arv och vad är komposition?
    • Är det vi som inte förstår UML, eller är det en dialekt av UML som vi inte sett?
  • Vi tror att vi inte förstår syftet uttryckt i “registrera X” – t ex:
    • syftet med Funktion som var att “registrera roller som en Deltagare kan spela”
    • syftet med Person var att “registrera basuppgifter om alla inblandade personer”
    • Det är ju stor skillnad på att en klass “registrerar” det som lagras i objektens instansvariabler (attribut) som i fallet Person, och att en klass registrerar objekt av annan klass (t ex Roll) i ett annat objekt av en annan klass (t ex Deltagare) som i fallet med Funktion vars syfte det är att “registrera Roll:er Deltagare kan spela” (det blir ännu kostigare då en Deltagare genom arv är en Roll som ska registreras på en Deltagare)
  • Vi tror att vi inte förstår skillnaden på Funktion och Roll – Det är inte tydligt eftersom klassen Roll inte är med i “klasspecifikationen”
  • Vi tror att en Person bara behöver en lista på Roller och att Funktion inte behövs
  • Vi tror att vi inte förstår varför en Funktion inte har några operationer, trots att syftet är att “registrera roller”
  • Vi tror att vi inte förstår varför en Deltagare behöver en hel lista på Funktioner, då funktioners syfte är att registrera en roll
  • Vi tror särskilt att vi inte förstår varför bara Roll:en Deltagare har en lista på Funktion:er – eftersom Funktion ska registrera Roll:er så behöver man ju då skapa en Deltagare bara för att komma åt en Funktion för att t ex registrera Roll:en Författare på en Person
  • Vi tror att vi måste ha typer i klassdiagrammet för att förstå åtminstone vad attributen “tillstånd” skulle kunna representera (antagligen skulle vi ändå inte förstå, på grund av namnet “tillstånd” som vi förknippar med objekt)
  • Det är möjligt att det är översättningsproblem som ligger till grund för vår oförmåga att förstå, men vi förstår likväl inte klassdiagrammet
    • Om det är dåligt översatt så bör vi nog inte använda boken
    • Om det är korrekt översatt så kan nog vi inte rekommendera boken
  • Vi tror att vi blir förvirrade av terminologin som används i “klasspecifikationen”, t ex vad är skillnaden mellan:
    • “personer”, “människor”, “deltagare” i konferensen?

Vi skulle kunna skriva en liknande analys av andra exempel från boken, bland annat angående klassdiagram för ett bankkonto men det lämnar vi till en annan gång.

Utifrån vårt försök att förstå boken, så kan vi inte annat än konstatera att antingen är vi för dumma för att förstå boken (då får gärna någon som förstår boken hjälpa oss att förstå) eller så syftar boken till något annat än att förklara OOA&D. I alla fall sådan OOA&D som leder fram till något som går att implementera. Oavsett så får vi tyvärr hänvisa till någon annan, vad gäller boken och frågor kring den. Vi förstår inte vad bokens “design” syftar till och i synnerhet inte hur designen går att implementera i kod (om man inte har tur och gissar eller tolkar designdokumenten “rätt”).

En annan sak som vi saknar är själva designhantverket. Vi har alltid trott att design är en process för att koden som implementerar designen skall bli så bra som möjligt utifrån objektorienterade principer. Den “design” som ges i exemplet ovan är så ofullständig (och för oss obegriplig) att den måste tolkas och koden kan ju då bli hur som helst, beroende på hur man tolkar den. Programmerarna måste ju designa sina klasser utifrån den ofullständiga “design” som ges i boken. Frågan vi ställer oss då är:

“Vad ska programmerarna med bokexemplets ofullständiga (och i vårt tycke otympliga) design till?”

Vi får tyvärr säga till er studenter som frågat (bland annat om exemplet ovan) om boken, att vi inte heller förstår boken. Då boken tyvärr inte innehåller ett enda kodexempel, är det svårt att med säkerhet säga att det är lämpligt, lätt eller ens är möjligt att implementera designen, eller ens om detta är syftet med designen.

Kanske är tanken med bokens metod att programmerarna under implementationen vid behov skall göra om designen från grunden (kanske med hjälp av någon annan metod för OOA&D) så att den uppfyller såväl objektorienterade principer som kravspecifikationen.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s