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

(1)

Pemodelan Sistem

Perangkat Lunak

Andronicus Riyono, M.T.

(2)

Arsitektur &

Prinsip-prinsip Desain

Pemodelan Sistem Perangkat Lunak Pertemuan 3

(3)

Bagian I:

Arsitektur

(4)

(5)

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

(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

(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

(12)

(13)

Maaf, tapi menurut saya prioritasnya tidak demikian, dan saya yang membayar pekerjaan ini!

Mari kita mulai dari pembeli untuk mendapat mana yang akan

(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?

•

Apakah Anda sudah memahami fitur ini

•

Bagaimana cara mengimplementasikannya?

•

Kurang pengetahuan

(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

Project duration Easy first Focus on architectural significance

(17)

(18)

(19)

(20)

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?

(21)

Board challenge scenario

20

Create message

(22)

Code for the board challenge (1)

(23)

22

(24)

Scenario scramble

(25)

One possible scenario

(26)

Structure and relationships

(27)

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.

(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

(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?

(30)

Talk to the experts

(31)

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.

(32)

Commonality analysis revisited

31 1 2 3 4

(33)

Some possible properties

(34)

Unit commonality analysis

(35)

No commonality

(36)

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?

(37)

Handle the properties in a common way

(38)

We’ve covered the 2

nd

_{key feature}

(39)

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

(40)

39

What does the feature mean?

How do I realize that feature in my system?

(41)

Step 1: Ask the customer

(42)

Step 2: commonality analysis

(43)

Step 3: how to implement

42

(44)

Review: Reducing risk

(45)

44

And you’ve got an

(46)

Additions to your toolbox

(47)

Bagian 2:

Prinsip-prinsip Desain

(48)

Saya harus mempelajari prinsip-prinsip desain

dan bagaimana

menerapkannya? Kukira kita belajar dari

(49)

Jadi, apa itu prinsip desain?

(50)

(51)

Open-Closed Principle

Classes should be open for extension and closed for modification

No one can change the

(52)

Contoh OCP

InstrumentSpec is closed for

(53)

(54)

(55)

(56)

(57)

(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 do banana things I staple things I time 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)

(63)

Contoh Penerapan SRP

✓ ✓ ✓ ✓ ✓ ✓ ✓

(64)

(65)

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.

(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 “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”

(69)

(70)

(71)

(72)

(73)

Inheritance

‣ Usually the first choice (and usually wrong)

‣ Use when you know that the subclass has the same behavior as the base class

(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