Object Oriented Design

Click here to load reader

  • date post

    08-Mar-2016
  • Category

    Documents

  • view

    218
  • download

    3

Embed Size (px)

description

Object Oriented Design

Transcript of Object Oriented Design

  • 2011

    RG van Voorthuizen 995279926

    LOI Hogeschool

    5-9-2011

    Object Oriented Design

    990X1

  • )990X1 RG van Voorthuizen 995279926

  • )990X1 RG van Voorthuizen 995279926

    1a Het gebruikte platform kan een variation point zijn, omdat te verwachten valt dat dit in de toekomst zal veranderen. Bij een Java-applicatie zal dit echter opgevangen worden door de JVM die

    daar verantwoordelijk voor is.

    Andere variation point is de gebruikersinterface. De gegevens die gepresenteerd worden zullen

    hetzelfde blijven, maar de wijze van presenteren zal veranderen.

    1b De software zou zodanig opgebouwd moeten worden dat de logica los staat van de presentatie, waardoor slechts het gedeelte van de software verantwoordelijk voor de presentatie

    aangepast hoeft te worden. Bijvoorbeeld door de software nu al op te bouwen met een adapter voor

    een lokaal te draaien applicatie, waardoor later slechts een web-adapter geschreven hoeft te

    worden.

    1c Design for Change

    2

    Quality Attribute Invloed op systeem- of softwarearchitectuur

    Availability In de systeemarchitectuur componenten redundant uitvoeren om hardware-

    uitval op te vangen. Back-ups en schaduwomgevingen gebruiken. Monitoring

    op de performance van de systeemarchitectuur, zodat bijv. capaciteit tijdig

    uitgebreid kan worden.

    De systeembeveiliging tegen misbruik (hackers) raakt ook dit attribuut.

    Performance De performance van softwarearchitectuur volgt uit de werking van algoritmen,

    resources alleen gebruiken wanneer dit nodig is; Technieken als caching en

    database-normalisatie gebruiken.

    Systeemarchitectuur dient berekend te zijn op system load; ook hier speelt

    monitoring een belangrijke rol om de performance van de hardware te

    beheren; Technieken als RAID gebruiken.

    Trade-off met andere attributen, zoals Portability.

    Scalability Systeemarchitectuur dient rekening te houden met groei, bijv. door servers

    met overcapaciteit in te zetten of met mogelijkheid tot directe uitbreiding.

    Virtuele servers kunnen scalability vergroten (bijv. PaaS of IaaS)

    Modifiability Software modulair en layered opbouwen. Zo hoeft er zo min mogelijk

    aangepast te worden in de software.

    Portability Abstractie van de applicatie-logica en de systeem interfaces.

    Er kan ook besloten worden bepaalde systeembibliotheken te bundelen met

    de software, zodat deze bij elke installatie aanwezig zijn.

    Als de systeemarchitectuur niet wijzigt, komt dat de portability uiteraard ook

    ten goede.

  • )990X1 RG van Voorthuizen 995279926

    3

    Stelling Waar/Onwaar

    Iteratief & incrementeel ontwikkelen verhoogt

    meteen de efficintie

    Waar, want als er een oplevering niet

    geaccepteerd wordt, hoeft slechts 1 iteratie

    opnieuw doorlopen te worden, ipv het gehele

    project.

    Een watervalproject brengt minder risicos met

    zich, omdat eerst de eisen (requirements) goed

    worden vastgelegd.

    Onwaar.

    Het blijkt in de praktijk erg lastig om van tevoren

    de requirements goed vast te leggen, waardoor

    deze kunnen wijzigen of pas duidelijk worden,

    tijdens het project.

    Deze werkwijze brengt daardoor juist een risico

    met zich mee.

    Een iteratief & incrementeel ontwikkelproces

    kan beter omgaan met veranderingen in de

    eisen (requirements)

    Waar, want bij veranderde requirements, hoeft

    men niet het gehele ontwikkeltraject opnieuw te

    doorlopen.

    Bij een agile-ontwikkelproces vertelt de

    teammanager de teamleden bij elke iteratie

    precies wat ze moeten doen.

    Onwaar, het is bij agile-ontwikkelproces juist de

    ontwikkelaar die verantwoordelijkheid dient te

    nemen en zelf mee moet denken over het werk

    dat volgt uit de verschillende iteraties en

    hoeveel tijd hij daarmee kwijt denkt en blijkt te

    zijn.

    Bij een agile-ontwikkelproces wordt er zo min

    mogelijk gedocumenteerd.

    Onwaar, agile softwareontwikkeling geeft

    prioriteit aan werkende software boven

    documentatie, maar dat betekent niet dat er zo

    min mogelijk gedocumenteerd moet worden.

    4

    Het hangt er vanaf, als ik Afb. 15 uit hoofdstuk 2 aan moet houden, zie ik dat Cirkel de Methode

    setRadius() kent, wat voor een Elips niet zou kunnen (want de straal is niet te bepalen), waardoor

    een Elips niet een subklasse van klasse Cirkel zou kunnen zijn.

    Zonder die methode zou klasse Elips wel kunnen worden afgeleid van klasse Cirkel, omdat overige

    eigenschappen gelijk zijn. Elips zou in dat geval een subklasse van Cirkel kunnen zijn en Cirkel een

    superklasse van Elips.

    Maar als ik uitga van het model in Afb. 15:

    Klasse Elips is niet af te leiden uit klasse Cirkel noch vice versa, omdat het allebei specialisaties zijn

    van de klasse Shape.

    Beide klassen erven attributen en operaties van de superklasse Shape en allebei kunnen ze hier

    attributen en operaties aan toevoegen.

    Ze hebben weliswaar overeenkomsten, vanwege dezelfde superklasse, maar het valt niet uit de

    subklasse af te leiden om welke gegevens dat precies gaat.

    Net zo goed als dat een Hond niet af te leiden is van een Kat, ondanks dat ze bepaalde

    eigenschappen delen.

  • 5a. Design Class Diagram

  • 990X1 RG van Voorthuizen 995279926

    5b. Use Case Realization