Pemodelan Sistem Perangkat Lunak Andronicus Riyono, M.T. Universitas Kristen Duta Wacana
Arsitektur & Prinsip-prinsip Desain Pemodelan Sistem Perangkat Lunak Pertemuan 3
Bagian I: Arsitektur Pemodelan Sistem Perangkat Lunak Pertemuan 3
Bingung?
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.
arsitektur adalah cetak biru dari sistem
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.
Apa yang harus dilakukan oleh sistem?
Buat prioritas
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 bukan dari mudah menjadi susah
Mengapa tidak mulai dengan hal-hal mudah lalu biarkan desainnya berkembang?
• Desain evolusioner berarti
kita dapat menambahkan hal-hal lain seiring berjalannya waktu
• Desain inkremental • Desain yang fleksibel • Iterative, incremental development
Arsitektur mengurangi resiko Easy first
Focus on architectural significance
Project duration
Logika prioritas
Menajamkan fokus
The Board
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
Board challenge scenario
Create message
20
Code for the board challenge (1)
21
Code for the board challenge (2)
22
Scenario scramble
23
One possible scenario
24
Structure and relationships
25
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.
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
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
Talk to the experts
29
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
Commonality analysis revisited
1 2 3 4
31
Some possible properties
32
Unit commonality analysis
33
No commonality
34
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
Handle the properties in a common way
36
We’ve covered the 2nd key feature
37
Three-step process 1 2 3 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
W fe
at u
ha t
re
do
es
th e ea n?
m
fe
Ho at
w
ur
e
do in
Ir
m
ea
ys
liz
ys
e
te
th
m
at
?
39
Step 1: Ask the customer
40
Step 2: commonality analysis
41
Step 3: how to implement There is no commonality!
42
Review: Reducing risk
43
And you’ve got an (executable) architecture!
44
Additions to your toolbox
45
Bagian 2: Prinsip-prinsip Desain Pemodelan Sistem Perangkat Lunak Pertemuan 3
Saya harus mempelajari prinsip-prinsip desain dan bagaimana menerapkannya? Kukira kita belajar dari pengalaman
Jadi, apa itu prinsip desain?
Yang sudah Anda ketahui
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
Contoh OCP
InstrumentSpec is closed for modification and open for extension
Langkah-langkah OCP
Atau, dengan delegasi
Don’t Repeat Yourself
Dog doors and DRY
Langkah-langkah DRY
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 staple things I do banana things
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?
Dengan kata lain... Setiap kelas (atau obyek) harus mempunyai tepat satu alasan untuk berubah.
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.
Contoh Penerapan SRP
Contoh Penerapan SRP
✓ ✓ ✓ ✓ ✓ ✓ ✓
Hasil Penerapan SRP
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.
A square is a rectangle, right? Who thinks this is true? Raise your hand high.
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 “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.
A game framework example
Problems with the example
One possible solution
Encapsulate what varies
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
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
