sainikumara / compressao-sem-perdas

Java implementation of LZ77 compression algorithm. Work in progress.

Compressão sem perdas

Data structures and algorithms Java project, implementing LZ77

Project Specifications

Implementation

Testing documentation

User guide

Release

Weekly reports

• Week 1
• Week 2
• Week 3
• Week 4
• Week 6
• Week 7

Hour reporting

compressao-sem-perdas's Issues

Koodikatselmus

Koodikatselmus 1 (ladattu 5.6. klo 20)

Projekti näyttää rakenteensa ja dokumentaation puolesta erittäin toimivalta ja hyvin edenneeltä, hieno homma!

Dokumentaatio ja käyttöliittymä:

(näistä ei toivottu erikseen kommentteja, mutta lyhyesti kuitenkin)

Dokumentaatiossa (esim. project specification) olisi hyvä olla melko alussa itse algoritmien ohessa maininta siitä, että missä muodossa ja minkälaisella käyttöliittymällä itse ohjelma tullaan toteuttamaan. Esimerkiksi pelkkä lyhyt maininta (tyyliin "toteutetttava ohjelma on suoritettava java-sovellus, joka pakkaa parametrinä annettavan tiedoston käyttäjän valitsemalla algoritmilla") olisi hyvä.

Käyttöliittymä: Ilmeisesti ohjelma toimii mainin kautta, ja erillistä käyttöliittymää ei toteuteta? Jos näin, niin olisi hyvä että käyttäjän kannalta relevantit parametrit (lähinnä varmaan tiedostosijainti ja käytettävä algoritmi) olisivat heti alussa, ja muu ohjelman käynnistys olisi ulkoistettu vaikkapa omaksi initialize-metodikseen, joka saa nämä asetukset parametreinä.

Sovelluksen käyttö

Ohjelmasta ei ainakaan tällä hetkellä ollut suoritettavaa versiota. Tämä varmasti work in progress, mutta loppuun mennessä olisi hyvä olla selvästi nähtävissä (ja dokumentoituna) että miten homma toimii.

Omalla koneellani projektin buildaaminen ja suorittaminen ainakin aiheuttivat errorin, eli myös tästä syystä suoritettava jar-tiedosto olisi kätevä.

Koodi

Ohjelman pääduuni vaikuttaisi tapahtuvan compress-luokan metodissa compressString. Metodi on 50 rivin mittaisena jo melko pitkä, ja se sisältää 4 sisäkkäistä if- tai while-lauseketta. Tämä alkaa olla jo melko raskasta, eli metodia olisi hyvä jakaa pienempiin osametodeihin.

Metodin alussa searchWindosStart-muuttuja määritellään ?- ja :-operaattoreiden avulla, kun taas seuraavaksi käytettään if/else lausekkeita. Nämä ovat käsittääkseni tässä yhteydessä ekvivalenttejä, joten käyttäisin mielellään vain toista ratkaisua. Oma preferenssini on if/else, koska ?/: on ainakin omasta mielestäni hankalampi hahmottaa.

Lisäksi myös itse luokka LZ77Compress on turhan pitkä (suositus on kuitenkin yleensä alle 100 riviä). Luettavuuden kannalta olisi hyvä refaktoroida luokkaa useampiin alaluokkiin.

Testit

UI-luokassa testissä writingDictionaryToAndReadingFromFilesWorks() on kaksi assertEquals-lauseketta. En ole ihan varma, että mitä nämä kaksi asserttia mittaavat, mutta olisi luultavasti selkeämpää, jos ne olisi eristetty omiksi testeikseen (mahdollisesti jaetulla beforeClass-metodilla).

LZ77Test-luokassa on hieman sama ongelma, eli testit näyttäisivät testaavaan useampaa asiaa yhtä aikaa eri asserteilla. Erityisen paha on compressedEntryHasCorrectProperties()-testi, joka näyttäisi testaavan ainakin kolmea eri metodia eri parametreillä. Jos tämä testi menee pieleen, niin ainakin itse en pystyisi millään sanomaan, että missä vika piilee, eli jakaisin testin useampaan, luultavasti kolmeen osaan.

Lopuksi

Kokonaisuutena näkisin kuitenkin, että ohjelman perusrakenne on hyvin kunnossa, ja edellämainitut asiat on helposti fiksattavissa ennnen loppupalautusta, eli kaiken kaikkiaan homma näyttää erittäin hyvältä. Tsemppiä siis loppukurssille, kyllä ne viimeiset kulmat vielä siitä hioutuu! -A

Koodikatselmointi 2

Projekti ladattu: 13.6. 19:30

Algoritmilla sai pakattua tiedostoja ja myös niiden purkaminen onnistui, mutta pakattujen tiedostojen koko oli alkuperäistä suurempi. Syynä tähän vaikutti olevan se, että algoritmi löysi tekstistä lähinnä vain yhden merkin pituisia matcheja.

LZ77Compress-luokan searchSubArrayContainsSearchTarget ei näytä toimivan toivotulla tavalla, sillä se ei löydä ikkunasta pisintä matchia jos tätä ennen on jokin muu, lyhyempi pätkä johon testattava syöte matchaa osittain. Tämän huomaa esim. seuraavalla testillä:

LZ77Compress compress = new LZ77Compress();
byte[] window = "a abc".getBytes();
byte[] target1 = "a".getBytes();
byte[] target2 = "ab".getBytes();
System.out.println(compress.searchSubArrayContainsSearchTarget(window, target1));
System.out.println(compress.searchSubArrayContainsSearchTarget(window, target2));

Metodi palautti arvon true syötteelle "a" mutta arvon false syötteelle "ab", vaikka se löytyy
myös annetusta ikkunasta.

Projektissa oli vain muutamia yksikkötestejä, ja testaamishetkellä IOTest-luokan testi writingDictionaryToAndReadingFromFilesWorks ei mennyt läpi. Varsinkin LZ77Compress-luokan logiikan kattavammasta testauksesta olisi hyötyä. Rajatapausten ja erilaisten skenaarioiden testaaminen voisi olla helpompaa, jos taulukoiden käsittelyyn tarvittavat apumetodit olisivat eri luokassa ja niitä voisi testata yksitellen.

Koodista löytyi useampia metodeja, joita ei kutsuttu missään. CompressionInfo-luokassa olikin tästä maininta, mutta sen lisäksi LZ77CompressedEntry-luokan ja muutaman käyttämättömän IO-luokan metodin tarkoitus jäi epäselväksi.

Jos ohjelmalle antoi tyhjän tai virheellisen tiedoston nimen, se heitti NullPointerExceptionin eli tuon virheen käsittelyä voisi vielä parantaa.