Pemodelan Sistem Perangkat Lunak

Andronicus Riyono, M.T.Universitas Kristen Duta Wacana

Arsitektur & Prinsip-prinsip Desain

Pemodelan Sistem Perangkat LunakPertemuan 3

Bagian I: Arsitektur

Pemodelan Sistem Perangkat LunakPertemuan 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 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?

Arsitektur mengurangi resiko

Project duration

Easy first

Focus on architectural significance

Logika prioritas

Menajamkan fokus

The Board

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?

Board challenge scenario

20

Create message

Code for the board challenge (1)

21

22

Code for the board challenge (2)

Scenario scramble

23

One possible scenario

24

Structure and relationships

25

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

Talk to the experts

29

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?

Commonality analysis revisited

31

1

2

3

4

Some possible properties

32

Unit commonality analysis

33

No commonality

34

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?

Handle the properties in a common way

36

We’ve covered the 2nd key feature

37

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

39

What does the

feature mean?

How do I realize that

feature in my system?

Step 1: Ask the customer

40

Step 2: commonality analysis

41

Step 3: how to implement

42

There is no commonality!

Review: Reducing risk

43

44

And you’ve got an (executable) architecture!

Additions to your toolbox

45

Bagian 2: Prinsip-prinsip Desain

Pemodelan Sistem Perangkat LunakPertemuan 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 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?

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

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!!!

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 “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.

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