Programutvecklingsteknik 9 maj 2001

Övning 6

  1. qm.gif Nadas pruttlabbar har använt programmet qm som väntelista för hjälp och redovisning. Objektmodellera ett sådant program där man som klient kan välja kurs, köa in sej och se kamratkön växa nedanför. Tänk även på aspekter som inte syns i objektmodellen och kommentera dom särskilt.


  2. UML är en halvgrafisk standard för objektmodellering. Man skulle vilja ha ett datorhjälpmedel för att rita och redigera UML. Det vore inte dumt om det på något sätt kunde kopplas till programmeringen också. Modellera och fundera!

Lösningar

  1. Första frågan bör vara hur personuppgiftslagen påverkar utformningen av tjänsten. Kölistan innehåller personuppgifter och därför bör man inte använda webben. En applet skulle annars ligga bra till, men då får man spridning till tredje land. Vi gör alltså ett javaprogram som bara är tillgängligt på Teknis, men det räcker inte - vi bör införskaffa samtycke från användarna. Första gången en användare startar programmet bör det komma upp ett fönster med information om vad som står i lagen och en OK-knapp för den som accepterar programmets personuppgiftshantering. En fil med alla som klickat på OK-knappen måste finnas och detta ska anmälas till högskolans personuppgiftsombud.

    Det behövs minst tre program:

    Klientens grafik måste innehålla en kursmeny (där man väljer kurs) och själva kölistan.
       ______     _________    ______
      |JFrame|   |JComboBox|  |JTable|
      |______|   |_________|  |______|
         ^            ^           ^
       __|___ 1  1 ___|___        |
      |Klient|----|Kursval|    ___|___         __________
      |      |1   |_______|  1|Kölista|- - - >|JPopupMenu|- - - >Servern  
      |______|----------------|_______|       |__________|
    
    
    Precis som i labb 3 tar klienten kontakt med servern och skickar över sitt användarnamn och sitt datornamn. Servern skickar tillbaka kursförteckningen, skriven i XML, alltså
    <?xml version="!.0"?>
    <kurslista>
      <kurs nummer="2D1385"> Prutt </kurs>
      <kurs nummer="2D1320"> Tilda </kurs>
      - - -
    </kurslista>
    
    Klienten läser in kurslistan i en vektor och skickar den till kursvalsmenyns konstruktor. Den första kursen kommer att stå förvald och eftersom servern sparar alla uppkopplingar i en fil kan den se till att det blir samma kurs som denna användare valde förra gången. Mycket användarvänligt! Eventuellt kan senaste kursval skrivas in i filen .kursval på användarens hemkatalog, men det är lite osäkrare.

    Sedan är det dags att skicka över kölistan, också i XML.

    <?xml version="!.0"?>
    <kölista>
      <elev namn="Henrik Eriksson" dator="brown17" ärende="hjälp" tid="0:31">
       Kommentar överflödig. </elev>
      - - -
    </kölista>
    
    Den läggs in i en matris och skickas över till kölistans konstruktor. Hur JTable funkar vet man när man gjort labb 6. Sedan lägger sej klienten och lyssnar tills antingen servern skickar en uppdaterad kölista eller användaren klickar på högerknappen och en meny poppar upp med alternativen "Köa", "Ta bort", "Avsluta". Valt alternativ skickas till servern.

    Servern startar en tråd för varje klient som tar kontakt (se föreläsning 4). För varje kurs skapas en kölista som uppdateras när det kommer meddelanden från klienterna. Dessutom körs en tråd som sover en minut i taget och sedan skickar ut ny kölista med väntetiderna++.

         ______ 1    * __________         _______________
        |Server|------|Klienttråd|- - - >|Kölisthanterare|
        |      |      |__________|       |               |
        |      |1    * __________        |               |
        |______|------|Minuttråd |- - - >|_______________|
                      |__________|
    



  2. Eftersom den del av UML som vi använt bara består av klassrutor, harlinjer, ärpilar och påverkarstreckpilar kan det vara lämpligt med dessa fyra objekttyper. En klass ärver högst en annan klass men har och påverkar hur många klasser som helst, därför kan har och påverkar slås ihop till associerad.
         ------------
        |0..1       1|
       _|__        __|___ 1  * __________
      | Är |      |Objekt|----|Associerad| 
      |____|      |      |1  *|          |
        |*        |______|----|__________|
        |           1|          ^      ^
        |____________|        __|_    _|______
                             |Har |  |Påverkar|
                             |____|  |________|
    
    
    Ritprogrammet bör ha en palett med dessa objekttyper. Nya objekt skapas och förbinds med musen och då kommer det upp en dialogruta som begär namn etc.

    Hittills har vi talat om objekt som ingår i den logiska strukturen, inte om dom grafiska objekt som ritprogrammet ska hantera. I stället för att lägga till grafiska egenskaper som koordinater, färg och font är det lämpligt att ha en parallell uppsättning av rent grafiska objekt. Dessutom ska det finnas lyssnare som låter grafikobjektens mushändelser påverka dom logiska objektens. Det är denna uppdelning som kallas Model-View-Control

    Kopplingen till javakoden kan göras så att programmet kollar om klassrelationerna stämmer med UML-koden. I den förra uppgiften skulle programmet kolla att class Klient extends JFrame, att klienten har ett datafält av klassen Kursval och ett av klassen Kölista osv.

    Ännu häftigare vore det om programmet kunde generera kod direkt ur UML-diagrammet. Jag vet inte om det är praktiskt möjligt men i teorin borde det fungera.


^ Upp till kurssidan.


Sidansvarig: <henrik@nada.kth.se>
Senast ändrad 15 mars 2002
Tekniskt stöd: <webmaster@nada.kth.se>