Pemodelan Sistem Perangkat Lunak. Andronicus Riyono, M.T. Universitas Kristen Duta Wacana

Transkripsi

1 Pemodelan Sistem Perangkat Lunak Andronicus Riyono, M.T. Universitas Kristen Duta Wacana

2 Arsitektur & Prinsip-prinsip Desain Pemodelan Sistem Perangkat Lunak Pertemuan 3

3 Bagian I: Arsitektur Pemodelan Sistem Perangkat Lunak Pertemuan 3

4 Bingung?

5 Jika saja kita memiliki cara untuk menyatukan semua informasi ini kita mungkin bisa mencari tahu apa yang harus dilakukan terlebih dahulu. Kamu perlu arsitektur!

6 Arsitektur Perangkat Lunak adalah... a. Struktur aplikasi atau sistem yang Anda buat b. komponen-komponen utama (yang paling penting) dari sistem yang Anda buat c. Hubungan antara bagian-bagian dari sistem yang Anda buat d. Alasan Anda memilih komponen tertentu atau representasi hubungan antar komponen e. Pola desain yang Anda terapkan f. semua benar

7 Arsitektur perangkat lunak Arsitektur perangkat lunak adalah struktur organisasi dari sistem, termasuk dekomposisinya menjadi beberapa bagian, keterkaitan antar bagiannya, mekanisme interaksinya, dan prinsip-prinsip serta keputusan yang Anda gunakan dalam desain suatu sistem.

8 Jadi sekarang kita perlu untuk mendokumentasikan semua detail? Ini akan memakan waktu terlalu lama. Bisakah kita mulai membuat programnya saja? Banyak orang berpikir bahwa mereka harus mendapatkan semua rincian. Anda hanya perlu "mewujudkan" hal-hal besar.

9 arsitektur adalah cetak biru dari sistem

10 apa itu cetak biru perangkat lunak Requirements, terutama use cases UML diagrams Class Package / component Sequence dan lain-lain Interfaces Key classes with methods Prototypes Saya masih tidak tahu apa yang menjadi cetak biru untuk perangkat lunak.

11 Apa yang harus dilakukan oleh sistem?

12 Buat prioritas

13 Maaf, tapi menurut saya prioritasnya tidak demikian, dan saya yang membayar pekerjaan ini! Mari kita mulai dari pembeli untuk mendapat mana yang akan diprioritaskan?

14 Tiga pertanyaan arsitektur Apakah bagian ini penting untuk sistem? Jika tidak bisa membangun sistem tanpa bagian tersebut, maka itu penting Apa arti bagian ini untuk sistem? Kurang pengetahuan Apakah Anda sudah memahami fitur ini Bagaimana cara mengimplementasikannya? Teknologi baru atau bahkan belum ada

15 Evolutionary design Desain berevolusi, tetapi bukan dari mudah menjadi susah Desain evolusioner berarti kita dapat menambahkan hal-hal lain seiring berjalannya waktu Desain inkremental Desain yang fleksibel Iterative, incremental development Mengapa tidak mulai dengan hal-hal mudah lalu biarkan desainnya berkembang?

16 Arsitektur mengurangi resiko Easy first Focus on architectural significance Project duration

17 Logika prioritas

18 Menajamkan fokus

19 The Board

20 Scenarios Isn t the board challenge a scenario? A scenario can be one path through a use case The use case consists of many, possibly infinite, scenarios A scenario can be a part of a use case or any meaningful sequence of actions Scenarios help us think about how the system works for one particular situation 19

21 Board challenge scenario Create message 20

22 Code for the board challenge (1) 21

23 Code for the board challenge (2) 22

24 Scenario scramble 23

25 One possible scenario 24

26 Structure and relationships 25

27 Stop or go on? Wait a minute. What about saving the board, loading saved games, and so on. We can t move on yet. Can we move on now? I know what we have to do for the board? This is too simple.

28 Focus on the goals Reasons to move on We know how to create a board We have described the interface for getting a particular tile and adding units to a particular tile on the board We have an idea about how the units, tiles, and board are related Reasons to keep working on the board It s not complete We haven t figured out how to implement persistence so we can save and reload boards We haven t established the coordinate system 27

29 Game specific units We can probably work on the units next. I think I m getting the hang of this evolving design. What the heck does this mean? 28

30 Talk to the experts 29

31 What does game-specific units mean? Each game based on the framework has different types of units, with different attributes and capabilities. So we need to be able to have properties for a unit that are different for each game, and support multiple data types for those properties. 30

32 Commonality analysis revisited

33 Some possible properties 32

34 Unit commonality analysis 33

35 No commonality 34

36 Draw upon your experience So, everything can be unique and maybe even different types. Haven t we solved a similar problem? Where have you had to solve a problem similar to this before? 35

37 Handle the properties in a common way 36

38 We ve covered the 2 nd key feature 37

39 Three-step process We ve gone through this a couple of times now. Can you identify a three-step process that will help you move forward with the third key feature: coordinate movements? 38

40 What does the feature mean? How do I realize that feature in my system? 39

41 Step 1: Ask the customer 40

42 Step 2: commonality analysis 41

43 Step 3: how to implement There is no commonality! 42

44 Review: Reducing risk 43

45 And you ve got an (executable) architecture! 44

46 Additions to your toolbox 45

47 Bagian 2: Prinsip-prinsip Desain Pemodelan Sistem Perangkat Lunak Pertemuan 3

48 Saya harus mempelajari prinsip-prinsip desain dan bagaimana menerapkannya? Kukira kita belajar dari pengalaman

49 Jadi, apa itu prinsip desain?

50 Yang sudah Anda ketahui

51 Open-Closed Principle Classes should be open for extension and closed for modification No one can change the class s implementation The class can be subclassed and extended

52 Contoh OCP InstrumentSpec is closed for modification and open for extension

53 Langkah-langkah OCP

54 Atau, dengan delegasi

55 Don t Repeat Yourself

56 Dog doors and DRY

57 Langkah-langkah DRY

58 Single Responsibility Principle Every object in your system should have a single responsibility and all the object s services should be focused on carrying out that single responsibility. I do dog things I time things I do banana things I staple things

59 Assign responsibility responsibly Didn t we do this with domain analysis and CRC cards? We identified the responsibility and assigned it to classes, but did we guarantee cohesion?

60 Dengan kata lain... Setiap kelas (atau obyek) harus mempunyai tepat satu alasan untuk berubah.

61 Menerapkan SRP 1. Create a card or table as shown. 2. Place the class name in the first blank line and each method in the second class. 3. Read each line. If the line does not make sense, you re probably violating the SRP.

62 Contoh Penerapan SRP

63 Contoh Penerapan SRP

64 Hasil Penerapan SRP

65 Liskov Substitution Principle DUH!!! Jika T adalah sebuah class dan S adalah subclass (diturunkan dari) T, maka pada program Anda, di bagian manapun yang dapat menggunakan T, Anda harus juga dapat menggunakan S.

66 A square is a rectangle, right? Who thinks this is true? Raise your hand high.

67 Maybe a square is not a rectangle void testrectangle(rectangle r) { r.setwidth(5); r.setlength(6); assertequals(5, r.getwidth()); assertequals(6, r.getlength()); } testrectangle(new Rectangle()); testrectangle(new Square());

68 So a square isn t a rectangle? I thought inheritance meant isa. And a square really is a rectangle, right? Contrary to what you may have learned, inheritance isn t an isa relationship. It s more like a has the behavior of relationship.

69 A game framework example

70 Problems with the example

71 One possible solution

72 Encapsulate what varies

73 Inheritance Usually the first choice (and usually wrong) Use when you know that the subclass has the same behavior as the base class Must obey the LSP

74 Delegation Delegate the responsibility for a task to another class or object Use when you want to use another class s functionality without changing it or when you can encapsulate variability in a supporting task Prefer delegation to inheritance