VI praktikum: Projekteerimine

Ülesanne klassis

Disainime uue kalkulaatori, kus saaks tehteid ilma Caclulator klassi muutmata juurde lisada. Vaatame, mis mustreid saab kasutada.

1. Toetatavate operatsioonide abstrahheerimine.

  • Kalkulaatori poolt toetatavate operatsioonide abstrahheerimine strategy patterni abil.
  • Eesmärk: klass Calculator peaks olema laiendatav selliselt, et selle kasutajad saaksid lisada uusi operatsioone (tehteid) ilma klassi ennast muutmata. (Taolised nõudmised on väga tüüpilised erinevatele frameworkide disainimisel. Seejuures on oluline, et kasutajad saaksid selle erinevaid osasid kerge vaevaga laiendada, aga ei peaks seejuures muutma frameworki enda klasse).
  • Teostus:
    1. Lahendada ülesanne kasutades strategy patternit. Luua tehete jaoks interface BinaryOperation ja seda realiseerivad klassid AdditionOperation liitmise ja SubtractionOperation lahutamise jaoks.
    2. Lisada klassi Calculator meetod performOperation, mis võtab argumendiks objekte tüüpi BinaryOperation ja teostab vastavaid tehteid.
    3. Muuta klassi Calculator meetodeid add ja subtract, et kasutataks liitmist ja lahutamist realiseerivaid operatsiooniklasse ja meetodit performOperation.
    4. Lisada ka analoogne interface UnaryOperation unaarsete tehete jaoks (näiteks ruutu tõstmine, kuupi tõstmine, faktori leidmine, jne).
    5. Kontrollida, et olemasolevad automaattestid endiselt läbiksid. Lisada testidesse uus test-meetod korrutamise testimiseks ja kontrollida et see läbiks:
    @Test
    public void testMultiply() {
        BinaryOperation multiply = new BinaryOperation() {
            public Integer performOperation(Integer a, Integer b) {
                return a*b;
            }
        };

        // 7 * 3 = 21?
        calculator
            .setDisplayValueTo(7)
            .performOperation(multiply, 3);
        assertEquals(calculator.getDisplayValue(), new Integer(21));
    }

2. Operatsioonide loomise viimine factory'sse

  • Eesmärk: interface'i BinaryOperation realiseerivate klasside isendite loomine viikse klassi OperationFactory.
  • Teostus:
    1. Luua klass OperationFactory, millel on staatilised meetodid BinaryOperation isendite loomiseks:
      • public static BinaryOperation createAdditionOperation()
      • public static BinaryOperation createSubtractionOperation()
      • public static BinaryOperation createMultiplicationOperation()
      • public static UnaryOperation createSquareOperation()
    2. Muuta klassi Calculator ja ka teste nii, et igal pool BinaryOperation isendite loomiseks kasutataks OperationFactoryt.
    3. Peale seda võib kaotada ka nüüdseks üleliigsed klassid AdditionOperation ja SubtractionOperation.

3. Valemite kirjeldamine puuna

  • Eesmärk: Kalkulaator panna ainult viimase väärtuse asemel meelde jätma kogu järjestikkust arvutuskäiku valemina. Valemid esitada composite pattern abil puu-struktuurina.
  • Teostus:
    1. Luua interface AbstractValue ja seda laiendavad klassid:
      • SimpleValue - sisaldab ainult ühte Integer välja
      • UnaryOperationValue - sisaldab mingit UnaryOperation tehet ja tehte argumenti tüübina IValue.
      • BinaryOperationValue - sisaldab mingit BinaryOperation tehet ja kahte tehte argumenti tüüpidena IValue
  • Näide:
    • Näiteks valem (7^2 + 1) * 2 näeks puu kujul välja järgmine. Kui kujutada ette taskukalkulaatorit, siis sellise tulemuseni jõudmiseks tuleks järjest vajutada kalkulaatori nuppe "7", "^2", "+", "1", "*", "2". Vaata ka all järgnevat testi.
  1. Lisada testide hulka järgmine test. Lõpuks peab see test läbima:
    @Test
    public void testEquation() {

        (7^2 + 1) * 2  == 100? 
    	calculator
    		.setDisplayValueTo(7)
    		.performOperation(OperationFactory.createSquareOperation())
    		.performOperation(OperationFactory.createAdditionOperation(), 1)
    		.performOperation(OperationFactory.createMultiplicationOperation(), 2);

        assertEquals(calculator.getDisplayValue(), new Integer(100));
    }

Kodune töö

NB! Teisipäevane praktikum: 6nda praktikumi juurde kuuluva klassis tehtud ülesande lahendus tuleb kindlasti esitada koos kodutöö lahendusega!

Esialgne kassasüsteem on mõnda aega töös olnud ja tellija on vahepeal laienenud teistesse ülikoolidesse ning neis üsna populaarseks muutunud. Praegune kassasüsteem ei saa enam oma ülesannetega hakkama.

Uued tingimused:

  • Kaupade nimetuste hulk ja kogused suurenevad
  • Tekib vajadus mitme poe ühendamiseks ühtsesse süsteemi
  • Mitu kasutajat peavad saama sama infosüsteemi kasutada erinevatest müügikohtadest
  • Iga ostu jaoks tuleb trükkida arve
  • Erinevad maksevahendid (sularaha, kaart, mobiil)
  • Juhtkond soovib saada rohkem informatsiooni müügi kohta.

1. Disaini küsimused

1.1 Mis on süsteemil puudu selleks, et lahendada soovitud nõuded?

1.2 Millistes kohtades peaks süsteemi täiendama, et neid nõudeid rahuldada.

Suunavad küsimused:

  1. Millise infrastruktuuri peal peaks süsteem töötama? Pakkuda välja erinevaid võimalusi. Milline on parim?
  2. Kuidas võimaldada võimalikult kiire statistika edastamine juhtkonnale? Kas ja kuidas saaks seda võimaldada reaalajas?
  3. Kuidas lahendada arvete trükkimine. Mis probleemid tekivad? Kuidas neid lahendada?
  4. Kui keeruliseks peate erinevate maksevahendite lisamist süsteemile? Mis seadmetega või infosüsteemidega peaks olema kassasüsteem ühildatud, et kõiki makseid saaks aktsepteerida. Uurida internetist, kuidas saab maksevahendeid süsteemidele lisada.

1.3 Mõelda jõudlus- ja turvaküsimuste peale.

Suunavad küsimused:

  1. Kuidas optimeerida andmebaasikihti seoses päringute mahu kasvamisega?
  2. Mis on cache’imine? Kuidas seda saaks süsteemi optimeerimisel kasutada?
  3. Ühe nõude kohaselt peavad mitu inimest korraga saama andmeid muuta. Kuidas seda süsteemi tasemel lahendada?
  4. Mis on andmeturbe seisukohalt süsteemi kõige nõrgem punkt? Kuidas seda teha turvalisemaks?
  5. Kuidas piirata kasutajate ligipääsu andmetele?

Kas kusagil on abi mustri(te) kasutamisest? Millistest mustritest? Kuidas need disaini paremaks muudaksid?


Nii punktis 1.2 kui ka 1.3 tuleb kirjeldada vähemalt 6 (kokku 12) aspekti, millest 3 võib valida väljapakututest ja lisaks veel 3 , mille grupp ise välja pakub.

Iga aspekti puhul:

  • kirjeldada seda vähemalt 3-4 lausega
  • tuua välja klassid (vajadusel kirjeldada, milliseid on vaja lisada/muuta/kustutada), mis on sellega seotud.

2. Ostu disain

Disainida ostu sooritamise kasutajalugu.

Kasutajalugu hõlmab endas:

  • kliendi valikut
  • ostu sisestamist
  • kauba kontrolli
  • makseviisi valikut
  • makse sooritamist
  • laoseisu vähenemist
  • tsheki trükki
  • ajalookirje tekkimist

Luua sequence diagram(id), kus on selgesti eristatavad erinevad kihid ja komponendid ning nendevahelised seosed. Diagrammi osapooled on teie süsteemi praegused või tulevased klassid (nt. controller jne.).

Milliste mustrite kasutamine võiks tulla kasuks antud use case'i realiseerimisel?

Tulemid

1. Ülesanne

1. Dokument peab olema vormistatud korrektselt (vt. Analüüsi praktikumi)

2. Iga punkti juures tuua välja:

  • Muutused tarkvaras
  • Muutused riistvaraplatvormis
  • Vajadusel lisada selgitavad diagrammid/joonised

2. Ülesanne

  • Esitada sequence diagrammid PDF failis

Lingid

edit