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
•
Jika ada banyak proses dan skenario pada aplikasi
•
Bisa menunjukkan kemajuan pengembangan lebih cepat
•
Bisa menunjukkan kemajuan berupa proses yang utuh
•
Fokus pada fungsionalitas, tidak akan ada yang terlewat
•
Fokus pada pengguna dan alur penggunaan aplikasi
•
Baik untuk sistem dengan banyak bagian fungsional yang independen, tidak tergantung satu dengan yang lainnya
•
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)
Hmm, sekarang mulai kelihatan bagaimana programnya bekerja. Bagaimana dengan…
Output from our demo
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?
Our new developer
Ini mungkin saat yang tepat untuk revisi desain & kode
The big -picture What’s this and why does the Board have one?
Board has Tiles
What about Coordinate and IDGenerator? Tile has Units
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
Very inefficient Easy to implement
The map must be updated whenever the unit moves Does not enable us to ask where a unit is on the board
Keep a map between the units and board coordinates
Easy to implement
The map is usually one way so given a coordinate, we can’t We know how to get the tile at directly get the units at that a specific coordinate so we can coordinate easily relate the tile, unit, and coordinates We can answer where a unit is on the board
public class UnitBoardAssociation { private Map
unitBoardMap; public UnitBoardAssociation() { unitBoardMap = new HashMap(); } 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
