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 efficiëntie

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 risico’s 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