Pemodelan Sistem Perangkat Lunak

Andronicus Riyono, M.T.Universitas Kristen Duta Wacana

Analisis & DesainPemodelan Sistem Perangkat Lunak

Pertemuan 3

Bagian I: Analisis

Pemodelan Sistem Perangkat LunakPertemuan 3

Apakah analisis itu?*

• penguraian suatu pokok atas berbagai bagiannya dan penelaahan bagian itu sendiri serta hubungan antarbagian untuk memperoleh pengertian yg tepat dan pemahaman arti keseluruhan;

• analisis sistem: pengamatan mengenai suatu kegiatan, metode, prosedur, atau teknik untuk menentukan manfaat kegiatan tsb dan cara terbaik untuk memperolehnya;

* Kamus Besar Bahasa Indonesia dalam jaringan

Apakah analisis itu?

• Metode untuk mempelajari sifat sesuatu atau menentukan fitur esensial serta keterkaitan antar fiturnya

• Metode untuk menguraikan konsep-konsepyang kompleks menjadi bagian-bagian atau fungsi-fungsi yang lebih mendasar

• Evaluasi kegiatan untuk mengidentifikasi tujuan-tujuan yang dikehendaki dan menentukan prosedur untuk mencapai tujuan-tujuan tersebut secara efisien

Apa hubungannya dengan membuat perangkat lunak?

Apakah kita sudah menganalisis masalah?

The Perfect World

DogDoor.java

Apakah kita sudah menganalisis masalah?

The Real World

DogDoor.java

The RealWorld

Betul, tapi kita bisa mengidentifikasi mana fitur-fitur penting dan bagaimana keterkaitannya?

Kita tidak bisa menghabiskan waktu menelusuri semua

kemungkinan yang ada

Menurut Anda, apa sajakah yang membuat sebuah fitur menjadi penting?

________________________________

________________________________

________________________________

________________________________

Suatu fitur menjadi penting bila

• pembeli tidak akan mau membeli software Anda jika fitur tersebut tidak ada

• sistem tidak akan bekerja tanpa fitur tersebut

• Banyak bagian lain dari sistem bergantung pada fitur tersebut

Tidak disebutkan mengenai hewan-hewan lain di dalam spesifikasi

sistem

Tapi kita sudah membuat sesuai

dengan requirements yang ada

Bagaimana kita bisa tahu bahwa hal itu penting?

Mengapa pembeli tidak memberitahukannya?

Menuju ke hal penting

Kumpulkan requirements

Analisis dalam konteks nyata

Bangun arsitekturnya

Penting bagiku, belum tentu penting bagimu.

Mau ambil garam, koq adanya sekop? Mau gali lubang di

kebun, ada yang punya sekop nggak

ya? cape deh...

Physical ViewProgress View

Development ViewLogical View

Skenario-skenario, menyatukan pandangan

Skenario-skenario

End-userFunctionality

ProgrammerSoftware Management

IntegratorsPerformanceScalability

System engineersTopology

Communications

ClassesObjectsBehaviors

ThreadsProcessesCommunications

Code structurePackagesLibraries

ProcessorsData stores

Mari berpikir...

bagaimanakalau...

Sequence diagram

Lifeline

Message

Object

Control focus

memikirkan alur menjadi lebih mudah

usahakan agar umum

• Apa yang harus diubah?

• Coba ubah sequence diagram-nya

Jadi, semua anjing dapat membuka pintunya?

Sepertinya tidak benar.

Kita dapat memberikan komentar, tetapi hal ini tidak terlalu membantu untuk mendapatkan desain yang benar

Solusinya

Beberapa panduan‣ Buat classes sederhana yang

bekerjasama dengan mengirimkan dan merespon pesan-pesan

‣ Setiap class seharusnya memiliki satu tanggungjawab (responsibility)

‣ Kebanyakan persistent object (misal, Bark) memiliki class yang mengelolanya

‣ Create

‣ Retrieve

‣ Update

‣ Delete

Bagaimana bisa tahu bahwa kita perlu class BarkManager?

Beberapa panduanBagaimana dengan

use case-nya?

Use case harus diperbaharui juga

Perubahan ≠ Ubah Use Case

Jadi, tiap kali membuat perubahan, use case harus diubah juga?

‣ Tidak harus

‣ Ubah use case jika memang perubahannya berpengaruh pada use case

‣ Tidak semua perubahan terjadi pada tingkat use case

‣ Kalau use case bersifat umum dan menjelaskan sebuah urutan untuk mencapai tujuan tunggal, tidak akan banyak berubah

‣ Beberapa use cases bahkan tidak perlu banyak detil

Use cases lainnya

• Pengelolaan Bark (CRUD)

• Inisialisasi sistem

• Nonaktifkan (mengunci) pintu

• Membuat laporan aktivitas

Sepertinya untuk menjaga agar use cases tetap lengkap dan up to date, diperlukan usaha yang tidak sedikit. Apakah tidak ada cara lain untuk mendeskripsikan sistem dengan

cara yang lebih mudah?

Ada, kita bisa menggunakan user stories atau dengan CRC cards

CRC Cards

• Class-Responsibility-Collaborator

• Beck & Cunningham

• Teknologi rendah

• Kertas dan pensil

• Mudah dibuat dan dihancurkan

• Menggunakan penempatan untuk menunjukkan keterkaitan antara yang satu dan yang lain

• Baik untuk belajar berpikir Object Oriented

Class DogDoor dalam sebuah CRC

Class name

Optional

Responsibilities of this class

Classes this class work with to perform its responsibilities

Use case utama kitadalam CRC Cards

Panduan CRCSepertinya mudah.

Adakah hal lainyang perlu

saya ketahui? ‣ Jangan takut untuk menyobek salah satu kertas dan menggantinya (jika salah)

‣ Jika sebuah class memiliki lebih dari satu tanggungjawab primer, atau tanggungjawabnya tidak muat dalam sebuah kartu, mungkin perlu dipecah menjadi lebih dari satu class

‣ Pastikan Anda dapat membuat susunan kartu dan menjalankan skenario-skenario dengan kartu-kartu yang ada

‣ Tulislah dengan jelas

‣ Jangan masukkan kartu-kartu ke dalam bak mandi, kertas akan rusak bila terendam air terlalu lama.

User Stories

• Mendeskripsikan sebuah fitur atau unit pekerjaan bagi programmer

• Memberikan informasi yang cukup untuk mendefinisikan kebutuhan dasar

• Harus dapat diuji dengan unit test

Contoh user story

Open the dog door

The DogDoor will receive a signal to open the door from some peripheral device, such as the remote button or the bark recognizer. When the signal to open the door is received, the door will open and remain open for 5 seconds

Bagaimana kalau pintunya sudah terbuka?

Contoh user story (perbaikan)

Open the dog door

The DogDoor will receive a signal to open the door from some peripheral device, such as the remote button or the bark recognizer. When the signal to open the door is received, the door will open and remain open for 5 seconds. At the end of 5 seconds, the door will close. If the door is already open, then the door will not close until 5 seconds from the current signal reception has elapsed.

User stories untuk use case utama kita

Saya suka ini. Ada petuah bijak lain?

Panduan user story

‣ Jika user story menjadi terlalu panjang, pecahkan agar menjadi dua atau lebih

‣ Jika terlalu sederhana, mungkin perlu digabungkan dengan yang lain

‣ Pastikan ada informasi yang cukup untuk programmer dapat mengimplementasikannya atau setidaknya menanyakan pertanyaan yang penting tentang itu

‣ Jika sebuah user story perlu waktu lama (relatif) untuk diimplementasi, pecah menjadi beberapa user stories

Membandingkan ketiga teknik

Fokus pada BarkSepertinya tidak ada yang salah dengan String untuk Bark.

Kamu pasti baru belajar Object Oriented, ya?

Apa yang salah dengan pendekatan Randy?

Bandingkan kodenya

String mungkin tidak masalah untuk sekarang, karena kita belum punya

hardware untuk mengenali suara anjing. Namun, ketika kita punya hardware

semacam itu, format asli suara anjing akan diperlukan dan kita pasti harus mengubah program. Dengan class Bark, kita cukup

mengubah di satu tempat saja.

Jadi, mengapa Maria memenangkan laptop?

Apa yang dilewatkan Maria dan bagaimana seharusnya ia menyelesaikan pekerjaannya?

Tidak terlalu penting sebenarnya. Saya hanya melakukan analisis

dengan lebih baik dibandingkan mereka yang lain.

Ya, tetapi sebenarnya pekerjaanmu kurang lengkap. Kamu melewatkan sebuah

kemungkinan yang sangat penting.

Tiga hal yang mungkin kita temukan

• Mungkin ada lebih dari satu anjing

• Mungkin ada lebih dari satu pintu

• Mungkin ada lebih dari satu remote control

‣ Analisis kata-kata‣ kata benda pada requirements

dan dokumen-dokumen lain

‣ Entities dan konsep-konsep‣ Dari lingkup aplikasi

‣ Pengalaman‣ Dari sistem yang telah dibuat

sebelumnya

Tanya! Dari manakah datangnya class?

Analisis kata-kata

1. Cari semua kata benda dalam dokumen (use case)

2. Hilangkan perulangan

3. Jika ada beberapa nama (untuk hal yang sama) pilih nama yang paling tepat dan hilangkanyang lainnya

Contoh analisis kata-kata

Berikut ini adalah kata benda yang didapat dari use case yang ada:‣ the (owner's) dog

‣ the owner

‣ the button

‣ bark recognizer

‣ request

‣ inside/outside

‣ dog door

‣ remote control

‣ bark

‣ Tidak semua kata adalah penting‣ Bahkan ketika kita pikir penting

‣ Beberapa kata benda merujuk pada hal-hal di luar sistem‣ Pemilik, anjing

‣ Beberapa kata benda merujuk pada hal yang tidak perlu dibuat atau dimodelkan‣ Request

Apakah pasti ada class untuk setiap kata benda?

Jika kata benda adalah class, maka kata kerja...

...adalah methods

Analisis membuat kita yakin bahwa kita telah mengerti bagaimana sistem akan bekerja.

Sekarang mari belajar desain.

Akhir dari Bagian Pertama

Bagian 2: Desain

Pemodelan Sistem Perangkat LunakPertemuan 3

Kukira dari tadi kita sudah melakukan desain? Apakah ada perbedaan

yang besar antara analisis dan desain?

Kapan kita masuk ke pemrogramannya?

Bagaimana menurut Anda?

Apa itu desain?

Saya coba cari 'design' di Internet,

dan mendapat banyak sekali definisi yang

berbeda. Mana yang benar?

Karakteristik umum desain

‣ Desain memiliki tujuan

‣ Desain mendeskripsikan bagaimana sesuatu akan bekerja (dalam sebuah konteks)

‣ Desain memiliki informasil yang cukup sehingga seseorang dapat melakukan implementasi

‣ Ada banyak macam desain

‣ Seperti ada banyak macam arsitektur rumah

‣ Desain dapat disajikan dalam berbagai tingkat detil

‣ Sebuah rumah anjing butuh jauh lebih sedikit detil dibandingkan dengan gedung pencakar langit

Definisi yang kita gunakan

• Desain perangkat lunak adalah proses merencanakan bagaimana memecahkan masalah dengan perangkat lunak.

• Sebuah desain perangkat lunak memiliki informasi yang cukup sehingga tim pengembangan dapat membuat implementasi solusi. Ini adalah perwujudan dari rencana(cetak biru untuk solusi perangkat lunak).

Desain disebut bagus bila

• mudah dimengerti

• fleksibel, mudah diubah

• memenuhi requirements (sekarang dan di masa depan)

Ingat Rick? (dari Bab 1 buku HFOOA&D)

Bisnis berjalan lancar.Sekarang saya siap untuk

mengembangkan usaha saya dan saya perlu beberapa perubahan pada aplikasi

Aplikasi yang telah dibuat

Requirement baru!

Saya sekarang berjualan Mandolin juga. Nama toko saya juga berubah, dari Rick's Guitars menjadi Rick's Music. Bisakah Anda mengubah aplikasi agar dapat menangani

perubahan-perubahan ini?

Saya pikir kita sebaiknya membuat

class Instrument dengan property "type"

Kita tambahkan saja class Mandolin. Lalu copy-paste dari class

Guitar.

Kalau kita menggunakan

desain O-O yang baik, saya pikir

class Instrument harus menjadi

parent class dari Guitar dan Mandolin.

Membandingkan ketiga solusi yang mungkin...

Solution Advantages Disadvantages

class Mandolin Mudah diimplementasi •Duplikasi kode

•Sulit dikelola

class Instrument dengan property "type"

Tidak ada duplikasi kode •Bukan solusi O-O

•Perlu memeriksa "type" dari setiap object yang ada

Instrument sebagai base class

•solusi O-O

•Tidak perlu memeriksa "type" dari tiap object•Tidak ada duplikasi kode

Apakah Rickmemiliki Instrument di gudangnya?

Abstract classes membungkus perilaku yang samadan mendefinisikan protokol untuk seluruh subclasses-nya

Karena tidak mungkin ada object Instrument, kita harus membuatnya menjadi sebuah

abstract class

Tidak sesederhana itu

‣ Masih banyak hal yang harus dikerjakan

‣ Buat agar class Inventory menggunakan Instrument dan bukan lagi Guitar

‣ Tambahkan class InstrumentSpec

‣ Abstract base class untuk GuitarSpec

‣ Tambahkan MandolinSpec yang diturunkan dari Instrument Spec

‣ Buat agar class Inventory menggunakan InstrumentSpec dan bukan lagi GuitarSpec

Aplikasi setelah direvisi

Kode setelah direvisi

Kode setelah direvisi

Kode setelah direvisi

Tiga langkah menujuGreat Software

1. Pastikan bahwa perangkat lunak yang Anda buat bekerja sesuai dengan apa yang diperlukan oleh customer

2. Terapkan prinsip-prinsip object-oriented yang baik

3. Usahakan desain yang dapat dikelola dan dapat digunakan kembali

Bagaimana dengan yang kita lakukan tadi?

Apakah program pencarian di Rick's Music sudah dapat disebut 'great software'?

1. Apakah program tersebut sudah melakukan apa yang seharusnya dilakukannya?Ya. Aplikasi dapat menemukan gitar dan mandolin, meski tidak pada waktu yang sama. Mungkin sudah tepat. Untuk lebih pastinya, tanya pada Rick.

2. Apakah sudah menggunakan prinsip-prinsip OO seperti enkapsulasi untuk menghindari duplikasi kode dan membuat software menjadi mudah untuk dikembangkan lebih lanjut?Sudah menggunakan enkapsulasi ketika membuat class InstrumentSpec, dan juga inheritance ketika membuat Instrument dan InstrumentSpec sebagai abstract superclass. Tapi masih perlu mengerjakan banyak hal untuk menambahkan jenis instrumen baru

3. Seberapa mudah untuk menggunakan kembali aplikasi pencarian ini? Apakah perubahan di satu bagian memaksa Anda mengubah banyak bagian lain? Apakah sudah loosely coupled?Agak sulit menggunakan kembali bagian-bagian dari aplikasi ini. Semua masih sangat erat terkait, dan InstrumentSpec seharusnya merupakan bagian dari Instrument (aggregation)

• mudah dimengerti

• fleksibel, mudah diubah

• memenuhi requirements

Saya telah menggunakan prinsip-prinsip OO dan

aplikasi saya lebih baik dari sebelumnya, tapi apakah desainnya sudah baik?

Bertanyalah, bagaimana jika...

‣ Bagaimana jika Rick menjual lebih banyak macam Instrument

‣ Bagaimana jika Rick ingin menjual tidak hanya Instruments saja?

‣ Asesoris

‣ CD

‣ Bagaimana jika sistem inventory harus diintegrasikan dengan program akuntansi dan penjualan

Menambah Instruments

Jadi, duplikasi kode dan perlunya membuat perubahan

di berbagai tempat untuk memenuhi sebuah perubahan

requirement menunjukkan desain yang masih jelek?

Betul! Kita akan melihat ide-ide ini disebutkan sebagai prinsip-prinsip desain nantinya, tapi Anda sudah pada jalur yang benar untuk memahami prinsip-prinsip dasar dari desain Object-Oriented yang baik.

Setiap akan menambahkan Instrument baru, kita harus mengubah class Inventory.Juga harus menambahkan

sebuah method search baru. Ini sepertinya bukandesain yang bagus

Tepat. Jika kita mendeskripsikan pencarian inventory dalam kata-kata, kemungkinan kita akan mengatakan bahwa kita ingin untuk "mencari di seluruh inventori untuk melihat apakah ada instrumen yang cocok dengan yang dicari oleh pembeli"

Kode pencarian yang ada public List search(GuitarSpec searchSpec) { List matchingGuitars = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext(); ) { Guitar guitar = (Guitar)i.next(); if (guitar.getSpec().matches(searchSpec)) matchingGuitars.add(guitar); } return matchingGuitars; }

public List search(MandolinSpec searchSpec) { List matchingMandolins = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext(); ) { Mandolin mandolin = (Mandolin)i.next(); if (mandolin.getSpec().matches(searchSpec)) matchingMandolins.add(mandolin); } return matchingMandolins; }

Kode ditujukan pada interface (atau abstract class)

public List<Instrument> search(InstrumentSpec searchSpec) { List<Instrument> matchingInstruments = new LinkedList<Instrument>(); for (Iterator<Instrument> i = inventory.iterator(); i.hasNext(); ) { Instrument instrument = i.next(); if (instrument.getSpec().matches(searchSpec)) matchingInstruments.add(instrument); } return matchingInstruments;}

Tapi class InstrumentSpec kan masih abstract. Apakah benar

harus begitu?

Yang menginginkan InstrumentSpec untuk

menjadi sebuah concrete class, silakan berdiri.

Oke, saya benar-benar bingung sekarang. Apakah kita perlu

concrete Instrument class atau tidak?

Bagaimana menurut Anda?Apa yang dapat menolong kita untuk menentukan apakah perlu ada concrete Instrument class atau tidak?

Selamat datang di Analisis Kesamaan

• Carilah apa saja properties dan methods yang sama-sama dimiliki oleh semua object dari tipe yang sedang dipertimbangkan

• Apa yang dimiliki oleh semua Instruments

• Dalam konteks permasalahannya

• Buatlah sebuah class yang membungkus semua elemen yang umum

• Kita tetap tidak tahu apakah harus abstract atau concrete

• Biasanya dimulai dengan bentuk abstractKalau dilihat-lihat, kita mirip juga ya!

Perbedaan, pelengkap kesamaan

• Carilah apa saja properties dan methods yang berbeda dari semua object dari tipe yang sedang dipertimbangkan

• Beda perilaku mungkin berarti beda implementasi

• Mungkin ada kesamaan dalam perbedaan

• Buat abstraksi dan bungkus perbedaan yang ada dalam abstraksi yang dibuat

• Abstraksi yang dimaksud adalah interface atau class abstract

Sepertinya ada yang berbeda denganmu...

Cobalah untuk Instruments

• Persamaan

1.

2.

3.

4.

• Perbedaan

1.

2.

3.

4.

Kesamaan/Perbedaan Instruments

• Persamaan

1. Pembuat (Builder)

2. Jenis (Guitar, Mandolin)

3. Harga

4. Nomor seri

5. Spesifikasi

• Perbedaan

1. Kesamaan

2. Cocok dengan spesifikasi

3. Berbagai properties

Jadi tipe adalah sebuah property yang umum dan kita melihat

implementasi dengan subclasses. Sepertinya semua baik-baik saja.

Saya tidak terlalu yakin. Jika tipe adalah property, mengapa kita perlu inheritance. Tidak bisakah kita buat sebuah property dengan nama tipe

atau mungkin enum?

Jenis instrumen tidak terkait dengan perilaku. Itu hanyalah sebuah property dan dapat diimplementasikan dengan

mudah di class Instrument.

Bagaimana dengan mencocokkan dua instrument? Bukankah itu

sebuah perilaku!

Anda benar, namun kita telah mengurusnya dengan membungkus perilaku tersebut dan property yang mungkin berbeda dengan membuat InstrumentSpec. Kita cukup menyebutkan sebuah InstrumentSpec ketika membuat Instrument baru.

Change is goodTerkadang Anda harus merelakan sebuah desain lama untuk desain baru yang lebih fleksibel

Desain yang baru

Tapi kita masih punya banyak macam classes untuk setiap

spesifikasi instrumen. Jadi apa yang sebenarnya kita perbaiki? Selesaikan satu masalah pada satu

waktu. Iterate! Increment!

Tetapi, tidak ada yang mirip diantara spesifikasi instrumen yang

berbeda. Jadi kita tidak bisa menerapkan solusi yang sama. Kita

sudah melakukan enkapsulasi terhadap perbedaan yang ada.

Apakah teman kita ini benar?Atau kita di ambang kehancuran dengan memisahkan classes untuk setiap tipe instrument specification?

Silakan diskusikan...

Struktur data, sang penyelamat

Jangan takut, saya Kapten Strukdat, siap menolong Anda dengan sebuah

Map untuk membantumu menemukan solusi

Perbaikan berikutnya

getProperty("builder")getSpec ()instrument

Masih ada satu masalah dengan 'kesamaan'. Apakah semua ini sama untuk instrumen-instrumen yang berbeda? Atau baru sebagian masalah saja yang terselesaikan?

Apakah kami sama?

Tergantung apa yang disebut 'sama'

public boolean matches(InstrumentSpec otherSpec) { for (Iterator i = otherSpec.getProperties().keySet().iterator(); i.hasNext(); ) { String propertyName = (String)i.next(); if (!properties.get(propertyName).equals( otherSpec.getProperty(propertyName))) { return false; } } return true; }

Di sini sama berarti bahwa sebuah spesifikasi cocok dengan spesifikasi yang lain jika spesifikasi tersebut memiliki semua properti dari spesifikasi keduadan setiap property keduanya memiliki nilai yang sama

Strategy Design Pattern

Singletons

Uji 'Kemudahan Pengubahan'1. Berapa banyak class yang harus ditambahkan agar pada aplikasi dapat

ditambahkan instrumen jenis baru?______________________________________________________________________________________________________________________

2. Berapa banyak class yang harus ditambahkan agar pada aplikasi dapat ditambahkan instrumen jenis baru?______________________________________________________________________________________________________________________

3. Jika Rick menginginkan untuk mencatat tahun pembuatan setiap instrumen, berapa banyak class yang harus diubah untuk mendukung pencatatan informasi baru ini?______________________________________________________________________________________________________________________

4. Jika Rick ingin menambah property baru neckWood, berapa banyak class yang harus diubah untuk pencatatan informasi baru ini?______________________________________________________________________________________________________________________

Hasil 'pengujian'1. Berapa banyak class yang harus ditambahkan agar pada aplikasi dapat

ditambahkan instrumen jenis baru?Kita harus menambahkan MatchStrategy interface dan classes. (Sebenarnya tidak harus, namun itu membuat aplikasinya menjadi semakin fleksibel) Kita harus menambahkan beberapa enum seperti InstrumentType, dan seterusnya.

2. Berapa banyak class yang harus ditambahkan agar pada aplikasi dapat ditambahkan instrumen jenis baru?Kita perlu mengubah class Instrument dan Instrument Spec

3. Jika Rick menginginkan untuk mencatat tahun pembuatan setiap instrumen, berapa banyak class yang harus diubah untuk mendukung pencatatan informasi baru ini?Kita menambahkan sebuah pasangan key-value baru pada property map

4. Jika Rick ingin menambah property baru neckWood, berapa banyak class yang harus diubah untuk pencatatan informasi baru ini?Kita mungkin perlu mengubah value yang terdapat pada enum Wood

Fleksibilitas dan Kohesi

The design life cycle

Ilmu baru di kotak Anda

Ilmu baru di kotak Anda

Ilmu baru di kotak Anda

Ilmu baru di kotak Anda

Ilmu baru di kotak Anda

Keren! Sekarang kita punya aplikasi yang sangat hebat. Rick

pasti suka dengan apa yang telah kita buat. Sangat fleksibel. Bahkan tidak terpikirkan satu masalahpun!

Teman-teman, Rick barusan memberitahukan bahwa tokonya akan segera menjual buku, asesoris, dan juga

kartu ucapan. Dia ingin agar semua segera dapat masuk dalam

inventorinya.

Tugas Kelompok• Cari tahu bagaimana untuk memenuhi

requirements yang baru dari Rick

• Ubahlah desain agar memenuhi requirements yang baru tersebut

• Buatlah diagram UML untuk menunjukkan desain yang dibuat

• Sertakan dokumentasi lain yang sekiranya diperlukan

• Lakukan uji 'kemudahan pengubahan' terhadap desain baru yang telah dibuat

Perhatian!• Margin: (atas, kanan, bawah, kiri) 3, 3, 4, 4cm

• Font: Verdana 12pt, Spacing: 1,5 spasi

• Filetype: PDF

• Subject: PSPL-TUGAS-KEL1

• Body: Nama Kelompok (satu kata, misal: Singleton), NIM para anggota, dan nama panggilan para anggota kelompok

• Nama File: PSPL-TUGAS-KEL1-namakelompok.pdf

• dikirim ke: ukdw@riyono.net