Pemodelan Sistem Perangkat Lunak Andronicus Riyono, M.T. Universitas Kristen Duta Wacana
Iterating, Testing, and OOA&D Lifecycle Pemodelan Sistem Perangkat Lunak Pertemuan 5
Waterfall: All or nothing (Usually nothing) Iterative development: Regular delivery of working software
Feature driven development
Feature driven development steps 1. Buat model keseluruhan (model analisis) 2. Buat daftar fitur 3. Buat rencana kerja berdasarkan fitur 4. Buat rancangan berdasarkan fitur 5. Buat program berdasarkan fitur lakukan langkah 2-5 hingga selesai
Use case driven development
Use case driven development steps 1. Identifikasi use cases 2. Buat model keseluruhan (model analisis) 3. Buat rencana kerja berdasarkan sebuah use case atau sebuah skenario 4. Buat rancangan berdasarkan use case/skenario 5. Buat program berdasarkan use case/skenario lakukan langkah 3-5 hingga selesai
Memilih pendekatan yang tepat
Memilih pendekatan yang tepat Jika ada banyak fitur yang tidak terlalu saling tergantung Bisa menunjukkan kemajuan pengembangan lebih cepat Fokus pada fungsionalitas, tidak akan ada yang terlewat Baik untuk sistem dengan banyak bagian fungsional yang independen, tidak tergantung satu dengan yang lainnya Jika ada banyak proses dan skenario pada aplikasi Bisa menunjukkan kemajuan berupa proses yang utuh Fokus pada pengguna dan alur penggunaan aplikasi Baik untuk sistem transaksional, yang sebagian besar sistemnya merupakan proses-proses yang kompleks
Sebuah Iterasi
Analisis (lagi) Does the Unit class do what Gary needs?
Feature completion list
Feature completion list
Daftar, daftar, daftar, bikin daftar melulu! Hasilnya mana?
Demo (sekaligus pengujian)
Skenario pergerakan
Tunjukkan kemampuan program yang dibuat Demonstrate unit movement capability Created a 10 x 10 board Created 1st Infantry Division Placed 1st Infantry Division on square (3, 3) Moved 1st Infantry Division from (3,3) to (5, 2) Where is 1st Infantry Division at? (5, 2) Output from our demo Hmm, sekarang mulai kelihatan bagaimana programnya bekerja. Bagaimana dengan
Jadi, pengujian yang dibuat hanya berdasar skenario yang ada saja? Asik!
Enak saja! Masih banyak pengujian yang perlu dibuat! Demo-demo tadi baru sebagian kecil dari pengujian yang diperlukan.
Pengujian negatif (Board class) @Test public void testillegalcoordinate() { Board b = new Board(3,3); try { b.gettileat(new Coordinate(3, 0)); fail("expected out of bounds index"); } catch (Exception e) { asserttrue(true); } }
Bagaimana sih mendapatkan koordinat yang ditempati sebuah Unit? Bisakah Anda membantu saya memahami implementasi bagian ini? Ini mungkin saat yang tepat untuk revisi desain & kode Our new developer
Tile has Units The big -picture What s this and why does the Board have one? Board has Tiles What about Coordinate and IDGenerator?
How to move a unit Find the tile the unit is on Remove the unit from the tile Add the unit to the tile at the new location How do you find the tile the unit is on? I don t remember code to do that?
Choice Advantages Disadvantages Have the unit keep a reference to its tile Easy to implement and efficient Extra field in the unit Does not enable us to ask where a unit is on the board Every time the unit moves this field must be updated Search the board for the tile with the unit Keep a map between the units and tiles Keep a map between the units and board coordinates Easy to implement Easy to implement We know how to get the tile at a specific coordinate so we can easily relate the tile, unit, and coordinates We can answer where a unit is on the board Very inefficient The map must be updated whenever the unit moves Does not enable us to ask where a unit is on the board The map is usually one way so given a coordinate, we can t directly get the units at that coordinate
public class UnitBoardAssociation { private Map<Unit, Coordinate> unitboardmap; public UnitBoardAssociation() { unitboardmap = new HashMap<Unit, Coordinate>(); } public void associate(unit unit, Coordinate coordinate) { unitboardmap.put(unit, coordinate); } public void removeassociation(unit unit) { unitboardmap.remove(unit); } So getcoordinate() is why you have a Coordinate class. } public Coordinate getcoordinate(unit unit) { return unitboardmap.get(unit); } Associating units and coordinates
Mengapa Coordinate class diperlukan? getcoordinate() mengembalikan sebuah koordinat kita tidak dapat mengembalikan lebih dari satu nilai kembalian Tidak ada kepastian apakah semua papan (board) memiliki dua dimensi (dua buah bilangan bulat untuk sebuah koordinat) Coordinate Class membungkus perbedaan yang mungkin terjadi agar lebih fleksibel
Pengujian positif untuk "pergerakan unit"
@Test public void testmovefromsingleunitsquaretoemptysquare() { Board b = new Board(10, 10); Unit u = new Unit(); b.addunit(u, new Coordinate(1, 1)); b.moveunit(u, new Coordinate(2, 2)); asserttrue(b.gettileat(new Coordinate(2, 2)).containsUnit(u)); assertfalse(b.gettileat(new Coordinate(1, 1)).containsUnit(u)); assertequals(new Coordinate(2, 2), b.whereis(u)); } @Test public void testmovefrommultiunitsquaretomultiunitsquare() { Board b = new Board(10, 10); Unit u1 = new Unit(); Unit u2 = new Unit(); Unit u3 = new Unit(); Coordinate c1 = new Coordinate(3, 3); Coordinate c2 = new Coordinate(4, 5); b.addunit(u1, c1); b.addunit(u2, c1); b.addunit(u3, c2); b.moveunit(u1, c2); assertfalse(b.gettileat(c1).containsunit(u1)); asserttrue(b.gettileat(c1).containsunit(u2)); asserttrue(b.gettileat(c2).containsunit(u1)); asserttrue(b.gettileat(c2).containsunit(u3)); assertequals(c2, b.whereis(u1)); }
Kapan kita dapat mengatakan bahwa pengujian yang kita buat sudah cukup? Apakah semua kemungkinan harus diujikan? Berapa banyak pengujian?
Do you trust other programmers to use your code properly?
Perbedaannya
Jadi, tidak perlu melakukan pengujian untuk data yang tidak valid dan kemungkinan error lainnya? Asik! Bukan seperti itu yang dimaksud dengan program by contract!
Contoh tes negatif lainnya @Test public void testmoveunitnotonboard() { Board b = new Board(10, 10); Unit u = new Unit(); b.moveunit(u, new Coordinate(3, 3)); assertfalse(b.gettileat( new Coordinate(3, 3)).containsUnit(u)); } @Test public void whereisunitnotonboard() { Board b = new Board(10, 10); assertnull(b.whereis(new Unit())); }
Feature completion list
Yang telah dilakukan (dan yang perlu dilakukan) We ve incrementally improved the capabilities of GSF in small iterations After each iteration we review the results with the customer, revise and re-prioritize the requirements if necessary Repeat for the next iteration
OOAD Lifecycle
Perjalanan kita
Puzzle...
...solved