pemodelan sistem perangkat lunak -...
TRANSCRIPT
Jika saja kita memiliki cara untuk menyatukan semua informasi ini kita mungkin bisa mencari tahu apa yang harus dilakukan terlebih dahulu.
Kamu perlu arsitektur!
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
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.
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.
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.
Maaf, tapi menurut saya prioritasnya tidak demikian, dan saya yang membayar pekerjaan ini!
Mari kita mulai dari pembeli untuk mendapat mana yang akan diprioritaskan?
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?
• Apakah Anda sudah memahami fitur ini
• Bagaimana cara mengimplementasikannya?
• Kurang pengetahuan
• Teknologi baru atau bahkan belum ada
Evolutionary design
• Desain berevolusi, tetapi bukandari mudah menjadi susah
• Desain evolusioner berartikita dapat menambahkanhal-hal lain seiring berjalannyawaktu
• Desain inkremental
• Desain yang fleksibel
• Iterative, incremental development
Mengapa tidak mulai dengan hal-hal mudah lalu biarkan desainnya berkembang?
Scenarios
‣ 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
Isn’t the board challenge a scenario?
Stop or go on?
Can we move on now? I know what we have to do for the board?
This is too simple.
Wait a minute. What about saving the board, loading saved games, and so on. We can’t move on yet.
Focus on the goalsReasons 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
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
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.
What does “game-specific units” mean?
Draw upon your experience
35
Where have you had to solve a problem similar to this before?
So, everything can be unique and maybe even different types. Haven’t we solved a similar
problem?
Three-step process
38
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”?
1
2
3
Saya harus mempelajari prinsip-prinsip desain
dan bagaimana menerapkannya? Kukira
kita belajar dari pengalaman
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
Single Responsibility PrincipleEvery 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 do banana
things
I staple things
I time things
Assign responsibilityresponsibly
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?
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.
Liskov Substitution Principle
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.
DUH!!!
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());
So a square isn’t a rectangle? I thought inheritance meant “is-a”. And a square really is a rectangle, right?
Contrary to what you may have learned, inheritance isn’t an “is-a” relationship. It’s more like a “has the behavior of” relationship.
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