UML for Java Programmers

by (2003)
ISBN-10 0131428489 ISBN-13 9780131428485
13 Flashcards en notities
1 Studenten

Studeer slimmer met eFaqt samenvattingen

  • Beschikbaar voor computer, tablet, telefoon en op papier
  • Vragen met antwoorden over de leerstof
  • Ongelimiteerde toegang tot 300.000 online samenvattingen
  • Tools voor slim studeren & timers voor betere resultaten

Bekijk deze samenvatting

Samenvatting - UML for Java Programmers

  • 1 Overview

  • Martin Fowler omscrijft 3 niveaus in softwareontikkeling. Welke zijn dit?
    - Conceptual
    - Specification
    - Implementation
  • Wat zijn de 5 soorten diagrammen?
    - Klasse
    - Object
    - Sequence
    - Collaboration
    - State
  • 2.1 Why model?

  • Diagrammen zijn goedkoper om te produceren dan code. ALs we een fout in een model maken, is dat snel te compenseren. Met code schrijven is dat niet zo.
  • Wat is de rede waarom we modellen maken?
    Om er achter te komen of iets gaat werken
  • 2.2 Making effective use of UML

  • Noem 3 redenen om UML te gebruiken?
    * Communcatie met anderen. Samen werken aan diagrammen is een snelle manier van ideeen uitwisselen.
    * Road maps. Je kan simpel uitleggen hoe stukken software met elkaar moeten gaan werken.
    * Technische documentatie.
  • Het is meestal geen goed idee om diagrammen lang te bewaren. Wat moeten we dan wel doen?
    * Veel diagrammen tijdelijk op een whiteboard zetten
    * Nooit opslaan en ook geen CASE tools
  • Wanneer mag ik diagrammen wel opslaan?
    sdaf
  • De geboden van het houden van diagrammen:

    - Maak een gewoonte om diagrammen weg te gooien
    - Slechts als een diagram een permanent communicatiemiddel is, mag je ze bewaren. Weest heel selectief hiermee!
    - Bedenkt ze nooit van te voren. Je gaat dan gissen en je gist mis!
    - Maak kleine stappen. Maak een simpel diagram, controleer deze, en breidt hem eventueel uit.
    - Gedrag eerst. Als je iets moet uitdenken helpt een sequence diagram het meest.
    - Hou in de gaten dat het code moet worden. Maak geen diagram waarvan je niet kan inzien dat het code wordt.
  • 2.5 When and how to draw diagrams

  • Als je een CASE tool wilt gebruiken. Wat is het advies?
    Bezint voor gij begint. Een CASE tool is zeer beperkt bruikbaar, zelfs al genereert hij code.
  • Noem 5 redenen om diagrammen te tekenen.
    * Om jezelf of anderen een stuk code uit te leggen
    * Als je een keuze moet maken tussen meerdere ontwerpen. (compromis sluiten).
    * Ideeen opdoen
    * Als er om documentatie gevraagd wordt.

    Het advies is: Stop ermee zodra het duidelijk is.
  • Noem 4 redenen om geen diagrammen te tekenen.
    * Omdat een proces het zegt
    * Je denkt dat het professioneel is.
    * Om als volledige documentatie te gelden.
    * Om dat co-progammeurs het nodig hebben. Iedere architect moet zelf meeden in het maken van fouten.
  • Als je 12 man op een project hebt zitten, hoeveel documentatie verwacht je dan? 
    Een wiki van 25-200 paginas met als doel zo dicht mogelijk bij de 25 te blijven.
  • Javadoc is handig, maar wanneer gebruik je het (niet)?
    Omschrijf goed, kort maar krachtig, de publieke delen van classes. De private delen mogen wat meer als notitie opgeschreven worden.
Lees volledige samenvatting
Maak nu je eigen eFaqt account aan voor toegang tot deze en duizenden andere hoge kwaliteit samenvattingen.

Voorbeelden van vragen in deze samenvatting

Wat zijn de 5 soorten diagrammen?
1
Martin Fowler omscrijft 3 niveaus in softwareontikkeling. Welke zijn dit?
1
Wat is de rede waarom we modellen maken?
1
Noem 3 redenen om UML te gebruiken?
1
Pagina 1 van 3