PEMROGRAMAN BERORIENTASI OBJEK : BAB 11

Statechart,Class,Component & Deployment Diagram

Statechart diagram

  • Statechart diagram menggambarkan transisi dan perubahan status (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima.
  • Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).
  • Status
  • Mendeskripsikan bagaimana suatu object mengalami perubahan status dari event-event
  • Event: internal dan eksternal
  • Status object: kondisi (harga-harga atribut) saat ini
  • Muncul sebagai adjective dalam deskripsi problem, eg., bank account “is open” atau “is overdrawn”, pengeluaran cek akan ditolak jika berada dalam status overdrawn

Class Diagram
Pendahuluan

  • Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek.
  • Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).
  • Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

Pendahuluan
Class memiliki tiga area pokok :
1. Nama
2. Atribut
3. Method
Contoh: mahasiswa (kelas) memiliki NIM, alamat, dan nomor telepon (atribut). Mahasiswa mendaftar kelas, membatalkan kelas, meminta transkripsi nilai (metode)

Atribut dan metoda dapat memiliki salah satu sifat berikut :

  • Private, tidak dapat dipanggil dari luar class yang bersangkutan
  • Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya
  • Public, dapat dipanggil oleh siapa saja

Class Diagram – Association

  • Obyek berhubungan dengan obyek lain
  • Hubungan digambarkan dalam garis yang menghubungkan antara dua kelas
  • Label (meski opsional) biasanya dalam satu atau dua kata menggambarkan asosiasi (relasi)

Inheritance

  • Seringkali satu atau lebih kelas memiliki atribut dan/atau metode yang sama.
  • Kita tidak perlu menuliskan kode yang sama berulang kali, sehingga digunakan mekanisme

CONTOH CLASS DIAGRAM
Contoh Class + Program

public class Mahasiswa {
String nrp;
String nama;
public Mahasiswa(String newNrp, String newNama){
this.nrp = newNrp;
this.nama = newNama;
}
public String getNrp(){
return nrp;
}
public String getNama(){
return nama;
}

public static void main(String[] args){
Mahasiswa mhs = new Mahasiswa (“07054110006″, “Andi”);
System.out.println(“Nrp : ” + mhs.getNrp());
System.out.println(“Nama : ” + mhs.getNama());
}
}

Deployment Diagram

  • Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal
  • Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

Component Diagram

  • Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya.
  • Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time.
  • Pada umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.
  • Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 10

Sequence Diagram & Collaboration Diagram

Sequence Diagram

  • Merupakan suatu diagram interaksi yang memodelkan suatu skenario tunggal yang dijalankan pada sistem
  • Digunakan untuk memperlihatkan interaksi antar obyek dalam perintah yang berurut.
  • Tujuan utama adalah mendefinisikan urutan kejadian yang dapat menghasilkan output yang diinginkan
  • Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).
  • Partisipan : obyek atau entitas yang bertindak dalam sequence diagram
  • Message : komunikasi antar obyek partisipan
  • Terdapat 2 tipe garis yaitu vertikal dan horisontal

Vertikal : waktu -> maju berdasarkan waktu
Horisontal : obyek mana yang beraksi

name : class/actor name

  • name bersifat optional
  • boxes berupa object diberikan tanda garis bawah
  • object yang tidak bernama disebut anonymous objects
  • boxes berupa actor dapat
    juga digambar dengan stick figure

Collaboration Diagram

  • Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 9

ACTIVITY DIAGRAM

  • Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses
  • Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis
  • Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur
  • Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan
  • Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram

Activity

  • Activity menggambarkan sebuah pekerjaan/tugas dalam workflow.
  • Pada UML, activity digambarkan dengan simbol belah ketupat=‘lozenge’ (horizontal top and bottom with convex sides).

Start State

  • Start state dengan tegas menunjukkan dimulainya suatu workflow pada sebuah activity diagram.
  • Hanya ada satu start state dalam sebuah workflow.
  • Pada UML, start state digambarkan dengan simbol lingkaran yang solid.

End State

  • End state menggambarkan akhir atau terminal dari pada sebuah activity diagram.
  • Bisa terdapat lebih dari satu end state pada sebuah activity diagram.
  • Pada UML, end state digambarkan dengan simbol sebuah bull’s eye.

State Transitions

  • State transition menunjukkan kegiatan apa berikutnya setelah suatu kegiatan sebelumnya.
  • Pada UML, state transition digambarkan oleh sebuah solid line dengan panah.

Decisions

  • Decision adalah suatu titik/point pada  activity diagram yang mengindikasikan suatu kondisi dimana ada kemungkinan perbedaan transisi.
  • Pada  UML, decision digambarkan dengan sebuah simbol diamond.

Swimlanes

  • Object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 8

Use Case Diagram

  • Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.

Komponen Use Case Diagram

  • Aktor adalah seseorang atau apa saja yang berhubungan dengan sistem yang sedang dibangun.
  • Aktor sebaiknya diberi nama dengan kata benda.
  • Dalam UML direpresentasikan dengan notasi berikut ini:

Pertanyaan …

  • Siapa yang menggunakan sistem?
  • Siapa yang memasang sistem?
  • Siapa yang memulai sistem?
  • Siapa yang memelihara sistem?
  • Siapa yang mematikan sistem?
  • Sistem lain apa yang menggunakan sistem ini?
  • Siapa yang mengambil informasi dari sistem?
  • Siapa yang menyediakan informasi ke sistem?
  • Apakah segala sesuatu terjadi secara otomatis pada waktu saat ini?

Actor
Ada 3 tipe

  1. Pengguna sistem
  2. Sistem yang lain dan berhubungan dengan sistem yang dibangun
  3. Waktu

Tipe pertama actor secara fisik atau seorang pengguna, gambaran secara umum dan selalu ada pada setiap sistem

  • Ketika memberi nama actor, gunakan nama peranan dan jangan nama posisi
  • Seorang individu dapat memainkan beberapa peranan.

Tipe Kedua adalah sistem yang lain. Misalkan pada sebuah sistem Informasi Puskesmas memerlukan koneksi dengan aplikasi sistem yang lain, semisal SIM rumah sakit.

  • Maka dalam kasus ini, SIM rumah sakit adalah actor.

Tipe ketiga adalah waktu

  • Dapat menjadi actor jika seiring perjalan waktu dapat memicu event/kejadian dalam sistem.

Use Case

  • Adalah bagian fungsionalitas tingkat tinggi yang disediakan oleh sistem.
  • Dengan kata lain, use case menggambarkan bagaimana seseorang menggunakan sistem.
  • Use dalam UML dinotasikan dengan simbol
  • Nama use case

– Simple name
Biasanya berupa kata kerja + kata benda
– Path name
nama di bagian depan menyatakan paket (package) dimana use case tersebut berada

Relasi

  • Relasi antara actor dan use case
  • Arah panah menunjukkan siapa yang mengawali komunikasi.
  • Dengan mengecualikan use case dalam relasi include dan relasi extend, setiap use case harus diinisialisasi oleh actor

Jenis Relasi

  • Generalization
  • Include
  • extends

generalization

  • Hubungan antara induk dan anak
  • Anak mewarisi sifat dan method dari induk
  • Induk disebut root / base
  • Class yang tidak memiliki anak disebut leaf
  • Terbagi menjadi 2
  1. Actor Generalization
  2. Use Case Generalization

Actor generalization

  • Aktor bisa umum atau spesifik
  • Menggunakan generalization

– Pelanggan : General actor
– Pelanggan Perusahaan & Pelanggan Individu:
Specific

Use case generalization

  • Use case anak mewarisi arti dari use case induk sambil menambahkan/memodifikasi behaviour dari induk

Relasi Include

  • Memungkinkan satu use case menggunakan fungsionalitas yang disediakan oleh use case lainnya.

Relasi Extend

  • Memungkinkan suatu use case secara optional menggunakan fungsionalitas yang disediakan oleh use case lainnya.
  • Use case pemeriksaan kesehatan suatu saat memerlukan tes laboratorium, tapi pada saat lain tidak. Tergantung pada kondisi pasien yang diperiksa.

Batasan sistem

  • Untuk memperlihatkan batasan sistem dalam diagram use case, Anda dapat menggambarkan sebuah kotak yang melingkupi semua use case, namun actor tetap berada di luar kotak.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 7

Pengantar UML

Topik Bahasan

  • Pengenalan Berorientasi Objek
  • Pemodelan visual
  • UML
  • Diagram – diagram UML

Pengenalan Berorientasi Obyek

  • Berorientasi Obyek  adalah mengorganisasikan perangkat lunak sebagai kumpulan obyek-obyek yg bekerja sama antara informasi atau struktur data dan perilaku yg mengaturnya.

Konsep Berorientasi Obyek

  • Enkapsulasi
  • Inheritance
  • Polymorhism
  • Enkapsulasi
  • Enkapsulasi adalah menyembunyikan kompleksitas dari luar dan hanya membuka operasi-operasi yg diperlukan saja terhadap obyek-obyek lain.

Contoh Encapsulation Pada Perbankan

  • Informasi/properties objek rekening : No rekening, Nama , alamat dll
  • Perilaku/method objek rekening : buka, tutup, penarikan, penyimpanan, ubah nama, ubah alamat dll
  • Kita bungkus/encapsulate informasi dan perilaku tersebut pada objek rekening
  • Sehingga perubahan-perubahan pada sistem perbankan yang berkaitan dengan rekening diimplementasikan sederhana pada objek rekening

Contoh Pewarisan Pada Perbankan
Objek Induk Rekening :

  • Mempunyai karakteristik umum seperti no rekening, pemilik, tingkat suku bunga

Objek Turunan (Mempunyai karakteristik yang unik dan mewarisi karakteristik umum dari objek induk)

  • Rekening Deposito : atribut jatuh tempo dll
  • Rekening Pinjaman : atribut batas kredit, cicilan minimum

Polymorphism

  • Polymorphism (Banyak Bentuk) adalah suatu operasi yg mempunyai nama yg sama tetapi jika diberikan pada obyek yg berbeda akan mengakibatkan operasi yg berbeda pula.

2. Pemodelan Visual

  • Beberapa pemodelan berorientasi objek
  1. Notasi Booch
  2. Obyek Management Methodology (OMT)
  3. Unified Modeling Language

1. Notasi Booch
Diambil dari nama pembuatnya, Grady Booch di rational Siftware Corporation.
Mengembangkan simbol grafik untuk menyajikan beberapa macam aspek model seperti objek disajikan dengan awan, beberapa anak panah yang merepresentasikan hubungan
Contoh notasi Booch

2. Obyek Management Methodology (OMT)

  • Dibuat oleh DR. James Rumbaugh
  • Pentingnya pemodelan sistem dalam komponen dunia nyata yang disebut objek
  • Penggunaan grafik OMT lebih sederhana dari pada Booch untuk menggambarkan sistem

3. Unified Modeling Language

  • Notasi booch dan OMT ide sama tapi notasi berbeda kendala. Bagi developer dan komunikasi menjadi sulit.
  • 1994 James Rumbaugh & Grady Booch bergabung bersama pada Rational diikuti ivar jacobson pada 1995 Menggabungkan Notasi Booch dan OMT
  • 1996 OMG (Object Management Group) meminta standard notasi OO modeling Rational (James Rumbaugh , Grady Booch & ivar Jacobson) menawarkan final proposal OMG menerima Unified Modeling Language (UML) sebagai bahasa standard pemodelan visual pada Nopember 1997. diikuti developer dan pers. Lainnya.
  • 2001 anggota merevisi kekurangan dan feature yang kurang 2004 UML2.0 dikeluarkan

C. SEJARAH UML
Pengertian UML

  • Unified Modelling Language (UML) adalah sebuah bahasa yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak.
  • UML menawarkan sebuah standar untuk merancang model sebuah sistem.

UNIFIED MODELLING LANGUAGE
UML mendefinisikan diagram-diagram berikut ini :

  • use case diagram
  • class diagram
  • behaviour diagram : – statechart diagram – activity diagram
  • interaction diagram : – sequence diagram – collaboration diagram
  • component diagram
  • deployment diagram

Use case diagram

  • Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 6

Building the Requirements Model

Pendahuluan

  • Analisa kebutuhan merupakan langkah awal untuk menentukan perangkat lunak seperti apa yang akan dihasilkan.
  • Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat bergantung kepada keberhasilan dalam melakukan analisa kebutuhan.
  • Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak [IEE93].
  • Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan kendala yang harus dihadapi oleh perangkat lunak [PRE01].
  • Analisa kebutuhan adalah sebuah proses untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna.

Faktor-faktor analisa kebutuhan

  • Lengkap, semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisa.
  • Detail, berhasil mengumpulkan informasi yang rinci sampai hal-hal yang kecil
  • Benar, semua data haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang difikirkan oleh pihak yang melakukan analisa.

Langkah-langkah analisa kebutuhan

  • Komunikasi yang baik, mengenal user lebih dekat
  • Mengetahui “apa”, tentang apa yang dikerjakannya, apa data yang menjadi masukan, apa yang dihasilkan.
  • Gunakan istilah yang sederhana
  • Terbuka dengan langkah yang dilakukan dlm pembuatannya termasuk konsekuensinya
  • Menampilkan contoh nyata.

PELAKSANAAN ANALISIS KEBUTUHAN

  • Untuk setiap peruntukan perangkat lunak, tentukan manfaat atau fungsi utamanya.
  • Dari masing-masing manfaat atau fungsi utama tersebut, tentukan bagaimana proses penggunaan atau interaksinya dengan pemakai.
  • Klasifikasi proses interaksi mana yang merupakan proses pengolahan data.
  • Tentukan antarmuka eksternal dan kinerjanya.
  • Buat daftar kebutuhan kemudian modelkan

DAFTAR KEBUTUHAN KINERJA
Contoh:

  • Perangkat lunak harus dapat dioperasikan maksimal sampai 5 pemakai.
  • Boleh ditambahkan dengan atribut kualitas perangkat lunak, misalnya:
  1. Sistem login untuk masing-masing pemakai di awal penggunaan perangkat lunak
  2. Fasilitas backup data historis sesuai periode yang diinginkan
  3. Fasilitas untuk load data historis yang sudah di-back up

PEMODELAN KEBUTUHAN FUNGSIONAL

  • Menggambarkan / menyajikan kembali kebutuhan fungsional perangkat lunak dengan menggunakan diagram dan notasi (tools) tertentu.
  • Diagram dan notasi yang digunakan:
  1. Context Diagram
  2. Data Flow Diagram (DFD)
  3. UML

PEMODELAN KEBUTUHAN FUNGSIONAL ( 2 )
Bagaimana cara memodelkan kebutuhan fungsional ?

Penyebab software gagal diimplementasikan

  • Software yang dihasilkan tidak sesuai dengan kebutuhan pengguna (user).  Contoh, instansi sekolah, kebutuhan pengguna yang paling mendesak adalah untuk mengefektifkan proses penerimaan siswa baru, namun justru yang dibuat malah sistem absensi siswa atau sistem perpustakaan.
  • Software yang dihasilkan tidak menyelesaikan masalah yang dihadapi oleh pengguna (perusahaan). Contohnya permasalahan yang dihadapi oleh perusahaan adalah proses pelaporan yang lambat dan tidak segera sampai ke pimpinan yang sering berada di luar kota. Solusi yang ditawarkan justru aplikasi berbasis desktop dimana untuk mengakses aplikasi pimpinan harus berada di kantor.
  • Software yang dihasilkan tidak sesuai dengan kondisi perusahaan (instansi). Misalnya untuk sebuah instansi yang hanya memiliki beberapa buah komputer tanpa adanya jaringan, ternyata dibuatkan suatu sistem yang berbasis client-server dimana diperlukan konektivitas antar semua komputer.
  • Software yang dihasilkan tidak user-friendly dan lebih rumit dari proses yang sudah ada saat ini, sehingga pengguna dari sistem dapat mengalami banyak kesulitan dan kekecewaan terhadap sistem
  • Software yang dihasilkan dibangun dengan teknologi tinggi dan mutakhir namun tidak tepat guna. Contohnya penerapan SMS Gateway dalam sistem penjualan di suatu toko kelontong yang pelanggannya hanya tetangga sekitarnya.

Seharusnya….
Software yang baik adalah software yang sesuai dengan kebutuhan dan keinginan pengguna, serta menjadi solusi dari permasalahan yang dihadapi oleh pengguna maupun perusahaan.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 5

The Object-Oriented Development Life Cycle (OODLC)

TOPIK BAHASAN

  • The Life Cycle
  • The Object-Oriented Analysis Phase
  • The Object-Oriented Design Phase
  • The Construction Phase
  • The Object-Oriented Testing Phase
  • The Maintenance Phase

The Life Cycle

  • OODLC merupakan update dari SDLC (System Development Life Cycle)
  • SDLC merupakan suatu proses yang yang digunakan oleh analis sistem untuk mengembangkan suatu sistem informasi, mulai dari analysis, Design,construction, testing dan implementation sistem.

The Object-Oriented Analysis Phase

  • Dalam analisis, kita memodelkan kebutuhan user
  • Untuk apa sistem dibuat?
  • Output berupa model konseptual.
  • Terdiri dari :

1. Model kebutuhan
2. Model Obyek

The Object-Oriented Analysis Phase

  • Model kebutuhan mempunyai 5 komponen
  1. Lingkup proyek
  2. Context Diagram
  3. Use Case Model
  4. Deskripsi Interface
  5. Studi Kelayakan
  • Lingkup Proyek
  1. Apa yang akan dihasilkan ?
  2. Secara umum, apa yang akan dikerjakan sistem untuk user.
  3. Termasuk mendeskripsikan apa yang tidak bisa dikerjakan sistem.
  • Context Diagram
  1. Dideskripsikan dengan kotak besar yang dikelilingi dengan kotak kecil.
  2. Mewakili entitas eksternal seperti orang, organisasi, sistem, atau hal-hal lain di luar sistem yang berhubungan dengan sistem yang akan dibangun.
  • Use case Model
  1. Mendeskripsikan tentang bagaimana user dapat menggunakan sistem dalam mengerjakan pekerjaannya.
  • Deskripsi interface
  1. GUI
  2. Komunikasi antar interface
  • Studi Kelayakan
  1. Kelayakan Teknis
  2. Kelayakan Ekonomis
  3. Kelayakan Resiko
  • Desain System, Custom development, package
    development.
  • Desain Arsitektur Jaringan, Desain Hardware,
    Desain jaringan
  • Desain Interface, Chart Struktur Interface, Desain input ,
    Desain output
  • Desain File dan Database, Pemilihan format
    penyimpanan data, optimasi data storage
  • Desain Object, Chart Struktur Program, Spesifikasi
    program
  1. Analisis, apa yang harus dikerjakan sistem?
  2. Desain, bagaimana sistem akan mengerjakannya?

The Construction Phase

  • Coding

Seharusnya dibuat dengan bahasa dan database yang berorientasi objek.
The Object-Oriented Testing Phase

  • Lengkapi pengujian untuk masing-masing class dan program.
  • Kemudian pengujian sistem
  • Pengujian harus teliti, lengkap dan otomatis.

The Maintenance Phase

  • Perbaikan bug
  • Perangkat tambahan
  • Virus
  • End-user computing
  • Backup dan restore
  • Pencegahan dari hal yang tidak diinginkan dan pemulihan.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 4

Analisa Desain Berorientasi Objek

Obyek dan Class

  • Real-World vs Data-World Objects
  • Class dan klasifikasi
  • Objek Transient dan Persistent Objects
  • Objek: Class atau Instance?
  • Asosiasi

Real-World vs Data-World Objects

  • Seorang analis harus memahami dan mendokumentasikan dunia nyata dimana user berada
  • Kemudian membuat produk pada komputer
  • Untuk membantu user dlm mengerjakan pekerjaannya
  • Analis yg efektif harus menjamin produk pada komputer secara akurat merupakan cermin dunia nyata kebutuhan pengguna

Sesuatu Hal…
ENTITY
Obyek adalah segala sesuatu yang ada di sekitar kita, dimana obyek-obyeklah yg menyusun dunia ini.

  • mobil, kereta api, sale, faktur, rekening, dll

Atribut /properti mendeskripsikan:

  • Merek, Model, Tahun,
  • Warna, Berat,
  • No seri, No Izin.

Relationship pada obyek lain:

  • Pada obyek Orang, seperti : pemilik.

OBJECT

  • Behavior :
  • Pembuatan
  • Perubahan warna
  • Penggantian Pemilik
  • Dihancurkan sendiri

Pada DATA WORLD

ENTITY
– Kita mempunyai beberapa jenis record pada komputer untuk setiap objek dunia nyata
– Membawa data untuk atribut

  • Merek, Model, tahun, warna, berat, no seri, no izin
  • Nilai atribut merepresentasikan state (keadaan) obyek

– Menghubungkan beberapa jenis relationship

  • Foreign Key atau pointer

OBJECT
– Membawa kode program utk setiap behavior

  • Create, Change Owner, Change Color, Delete
  • CRUD: Create, Read, Update, Delete.

Contoh : Aktivitas Perkuliahan

  • Dari aktifitas perkuliahan tsb. Ada 3 objek yang langsung dapat dikenali yaitu :
  • Dosen (yang memberikan kuliah)
  • Mahasiswa (yang mengikuti kuliah)
  • Materi Kuliah

Ada 2 objek lain yang bisa dikenali :

  • Jadwal Kuliah dan Nilai yg didapat mhs dr mt kuliah yg diikutinya

 

  • Abstraksi dan pemodelan untuk salah satu dari ke 5 objek tsb,mis: objek DOSEN adalah :

– Menjadi kelas : DOSEN
– atribut : kode dosen
– nama dosen
– pendidikan dll.
– Operasi : rekam
– update
– delete dll.

Sehingga…

  • Sebuah Obyek Data adalah suatu abstraksi dari beberapa hal di dunia nyata dengan dua hal yg dibawanya, data yang menggambarkan objek dunia nyata, dan operasi (yaitu, kode program) untuk mengakses data tersebut.

Obyek

  • Dalam pemrograman, data-data di dalam objek akan direpresentasikan dengan variabel atau  konstanta, sedangkan perilaku akan direpresentasikan dengan prosedur atau fungsi, yang kemudian disebut dengan method.

Obyek dan Class

  • Real-World vs Data-World Objects
  • Class dan klasifikasi
  • Objek Transient dan Persistent Objects
  • Objek: Class atau Instance?
  • Asosiasi

Class

  • Adalah kumpulan dari objek2 dengan karakteristik sama.
  • Setiap kelas akan mempunyai sifat(atribut),kelakuan(operasi), hubungan(relationship) dan arti
  • Suatu kelas dapat diturunkan dari kelas yg lain,dmn atribut dari kelas semula dapat diwariskan ke kelas yang baru
  • Class Kendaraan terdiri dari obyek :

– mobil, bis, truk, motor, becak dan sepeda

  • Kategori dari class ini bergantung kepada semesta pembicaraan

– Class Kendaraan bermotor maka obyek :

  • mobil, bis, truk, motor.

Sub Class

  • Dalam perusahaan, apakah costumer mempunyai nama?

– Tentu.
– Tetapi, mengapa?
– karena costumer adalah orang, orang memiliki nama

  • Apakah Nasabah memiliki Tingkat Upah?
  • Tidak, hanya orang :Karyawan yg memiliki salah satu dari tingkat upah !

Class dan Klasifikasi

  • Menemukan Class merupakan aktifitas inti dari OOA.
  • Kemudian membangun sebuah Class Diagram dan tambahkan atribut dan behavior ke dlmnya.

Objek Transient dan Persistent

  • Untuk setiap kelas yg kita buat, kita harus memutuskan apakah obyek ini harus:
  • Transient, hancur pada atau sebelum akhir sesi, atau
  • Persistent, disimpan pd storage untuk waktu yang cukup lama.

Obyek : Class atau Instance

  • Kelas Objek merupakan wadah bagi Objek. Dapat digunakan untuk menciptakan Objek.
  • Objek mewakili fakta/keterangan dari sebuah kelas
  • Kelas merupakan struktur umum dari objek2 tertentu. Misal saya, anda dan yg lainnya adalah objek, yg termasuk dalam kelas manusia. Istilah objek dan kelas adalah dua hal yg berbeda.
  • Dalam bahasa pemrograman, sering dikatakan bahwa objek merupakan instansiasi dari sebuah kelas.
  • Instansiasi  merupakan wujud nyata dari suatu objek. Sebagai contoh: jika terdapat kelas manusia, maka udin, amir dan ali adalah instance dari kelas manusia.
  • Objek-objek pada sebuah class disebut instance dari class. Setiap instance mempunyai nilainya sendiri untuk setiap atribut, tetapi nama atribut dan method-nya sama seperti instance lainnya dari sebuah class.
  • Dianalogikan juga bahwa tipe data adalah kelas, sedangkan var yg didefinisikan berdasarkan tipe data tersebut adalah objek. Sebagai contoh jika:
    x : integer;
  • berarti objek x adalah instance dari kelas integer.

Asosiasi

  • Asosiasi digunakan untuk menghubungkan antara kelas dengan kelas lainnya.
  • Seseorang dpt mengendarai mobil dan juga dpt mengendarai motor.
  • Maka kelas orang berasosiasi dengan kelas mobil dan sekaligus dengan kelas motor.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 3

Model Berorientasi Data

  • Pemodelan Sistem
  • Pemodelan Data : ERD
  • Pemodelan Entity-Relationship
  • Model berorientasi objek
  • Pengenalan Objek
  • Object-Oriented vs Object-based
  • Model sbg alat komunikasi

Pemodelan sistem
Model adalah representasi kenyataan.

Model Logika mendokumentasikan persyaratan bisnis untuk menunjukkan sistem apakah itu atau apa yang dilakukannya. Model tersebut menggambarkan sistem independent (lepas) dari implementasi teknisnya.

Model Fisik tidak hanya menunjukkan apakah sistem tersebut atau apa yang dilakukannya, tetapi juga bagaimana sistem tersebut diimplementasikan secara fisik dan teknis.

Pemodelan data
Pemodelan Data adalah teknik untuk mengatur dan mendokumentasikan data sistem. Pemodelan data sering disebut pemodelan database karena model data biasanya diimplementasikan sebagai database. Hal ini biasanya disebut pemodelan informasi.

Namun paling sering disebut Entity Relationship Diagram (ERD) karena menggambarkan data dalam konteks entitas dan hubungan yang dideskripsikan oleh data.

ERD merupakan tool analisis sistem pertama yg fokus pada
DATA
Dan

Bagaimana data dihubungkan dan diorganisasi.

Konsep Pemodelan Data : Entitas

  • Entitas adalah kelompok orang, tempat, obyek, kejadian atau konsep tentang apa yang kita perlukan untuk menyimpan data
  • Orang : agen, kontraktor, costumer, pegawai, instruktur, siswa, supplier.
  • Tempat: wilayah sales, bangunan, ruangan, kantor cabang, kampus.
  • Objek : buku, mesin, produk, model kendaraan, kendaraan.
  • Peristiwa : penerbangan, registrasi, pelayanan.
  • Konsep : stok, laporan keuangan.

Konsep pemodelan data : atribut

  • Atribut mendeskripsikan sifat atau karakteristik suatu entitas. Sinonim dengan field.
  • Atribut Composite adalah atribut yang terdiri dari atribut lain.

Konsep pemodelan data : identifikasi
Key adalah atribut atau kelompok atribut yang mengasumsikan nilai unik untuk tiap contoh entitas.
Concatened key adalah kelompok atribut yang secara unik mengidentifikasi entitas.
Candidate key adalah kandidat untuk menjadi identifier utama pada entitas
Primary key adalah candidate key yang terpilih untuk mengidentifikasi secara unik suatu entitas
Alternate key adalah candidate key yang tidak terpilih
Foreign key adalah Atribut dengan domain yang sama yang menjadi kunci utama pada sebuh relasi tetapi pada relasi lain atribut tersebut hanya sebagai atribut biasa

Konsep pemodelan data : Asosiasi
Asosiasi merupakan interaksi dua entitas dan dinyatakan dengan kata kerja.

Konsep pemodelan data : Cardinality
– Menjelaskan batasan jumlah keterhubungan satu entity dengan entity lainnya.
– Jenis Cardinality Ratio

  • 1 : 1
  • 1: M / M : 1
  • M : N

E-R model untuk desain database.
E-R model pada dasarnya penting untuk pengembangan sistem karena:

  • Setiap entitas akan menjadi tabel.
  • Setiap atribut akan menjadi field (kolom)
  • Setiap asosiasi akan menjadi jalan akses (foreign key)

Model Berorientasi Objek
Object-Oriented Programming (OOP)

  • Kelompok programmer C  C++
  • Semua orang sekarang belajar Java

Object-Oriented Analysis and Design (OOA&D) untuk analisa dan desain.
Object-Oriented Databases (OODBMS) dengan menerapkan dalam Relational database (RDBMS) > Oracle9i.

Pengenalan Objek

  • Sama seperti entitas, objek dinyatakan dengan kt benda.
  • Obyek dalam ‘software analysis & design’ adalah sesuatu berupa konsep (concept), benda (thing), dan sesuatu yang membedakannya dengan lingkungannya. Secara sederhana obyek adalah mobil, manusia, alarm, tabel, database, event, system messages.
  • Tetapi objek ini lebih dari entitas dengan penambahan pada datanya, objek memuat program code (penggunaan dan perubahan data)

Object-Oriented vs Object-Based
Beberapa bahasa pemrograman mempunyai objek tetapi tidak dimasukkan dlm Object-Oriented.

  • ADA 85, Clipper

O-O seharusnya mempunyai dua ciri-ciri penting:

  • Inheritance, 
  • Polymorphism 

Model sbg alat komunikasi

  • Untuk membangun model yg tepat, hal yang penting dalam pemodelan adalah pandangan user.
  • User mempelajari notasi secara cepat dengan menggunakan model ini, kemudian berdiskusi dan mengatasi permasalahan dengan sistem analis.

PEMROGRAMAN BERORIENTASI OBJEK : BAB 2

Model dan Pemodelan

Topik  Bahasan :

1.Definisi Model dan Pemodelan
2.Beberapa jenis model
3.Model pada Pengembangan Sistem
– Menurut Anda, apa itu data?
Data
“Data” berasal dari bahasa Latin yang bersifat jamak “Datum” yang berarti “Fact.”
Akan lebih tepat jika kita mengatakannya sebagai “Raw Facts” fakta yang mentah karena belum diproses.

Informasi
Apa perbedaan antara “data” dengan “Informasi” ?
Informasi diturunkan dari data yang telah dilakukan suatu proses tertentu yang membuatnya menjadi berarti pada suatu kondisi, sehingga dapat digunakan untuk mendukung keputusan.

Menurut  Anda, apa itu model ?
Model

  • Lebih kecil ukurannya
  • Tampak sama dengan aslinya
  • Dibuat dengan bahan yang berbeda
  • Melakukan sesuatu yang sama dengan tiruannya

Contoh Model
P. Bagaimana caranya seorang auto designer memutuskan untuk merancang bentuk sebuah mobil?

J1. Buat sebuah mobil dan kendarai.
Salah

J2. Buat sebuah mobil dan coba di terowongan angin.
Hampir Benar

J3. Buat model dan coba di terowongan angin.
Benar.

Tapi, Apakah model harus sama persis dengan aslinya ?
Tidak selalu.

  • Bentuknya sama
  • Skalanya 1/3
  • Dibuat dari tanah, Fiber, Kayu dll

 

  • Tanpa pintu
  • Tanpa mesin
  • Tanpa jendela
  • Tanpa tempat duduk
  • Tanpa cat

Model-model yang lain

  • Rancangan rumah
  • Peta
  • Flowchart program
  • Equation (matematika)

Setiap model diatas merepresentasikan sesuatu benda di dunia nyata yang terlalu besar atau complex untuk dipahami, sehingga perlu penyederhanaan (simplified) dengan (mengurangi ukurannya, scope atau skalanya)

Definisi Model
Model adalah Representasi penyederhanaan dari sebuah realita yang complex (biasanya bertujuan untuk memahami realita tersebut) dan mempunyai feature yang sama dengan tiruannya dalam melakukan task atau menyelesaikan permasalahan.

A Child’s First Model. . 
Sejak lahir kita menggunakan/berinteraksi dengan model objek

Objek-objek ini :

  • Mempunyai atribut
  • Mempunyai nilai atribut
  • Mempunyai behaviour
  • Behaviour dilakukan dengan memberikan pesan

Proses ini sama dengan apa yang dilakukan oleh seorang analis ketika mencoba untuk memahami dunia bisnis user.

Objek merupakan cara yang paling natural/alami dan efektif untuk mengerti dan memahami kompleksitas yang ada

Pemodelan

  • suatu bentuk penyederhanaan dari sebuah elemen dan komponen yang sangat komplek untuk memudahkan pemahaman dari informasi yang dibutuhkan.

Pemodelan sistem

  • Pemodelan Berdasarkan Skenario (Scenario Based Modelling)
  • Pemodelan Berorientasi Aliran (Flow-Oriented Modelling)
  • Pemodelan Berdasarkan Kelas (Class-Based Modelling)
  • Pemodelan Perilaku (Behavioral Modelling)
  • Pemodelan Berdasarkan Skenario
  • Merupakan pemodelan sistem yang dilakukan dari sudut pandang pengguna
  • Pemodelan ini menggunakan UML (Unified Modeling Language) yang dijelaskan pada pertemuan lain

Pemodelan Berdasarkan Aliran

  • Pemodelan ini mendefinisikan bagaimana obyek – obyek data ditransformasikan oleh fungsi proses.
  • Biasanya dimodelkan dengan Data Flow Diagram

Pemodelan Berbasis Kelas

  • Pemodelan ini mendefinisikan obyek, atribut dan relasi
  • Biasanya menggunakan ERD (entity Relationship Diagram)

Pemodelan berbasis perilaku

  • Pemodelan ini lebih mengarah pada perilaku dari sistem atau produk.
  • Menggambarkan bagaimana sistem atau perangkat lunak akan merespon jika ada event dari luar.

Model pada Pengembangan Sistem

  • Pertama, beberapa hal yang berkaitan dengan penggunaan model sebagai pengembangan sistem:
  1. Skill mendengarkan
  2. Notasi, Teknik, dan Sensitifitas
  3. User memperoleh paradigma yang baru mengenai pekerjaannya
  4. Usaha pengembangan direncanakan di awal
  5. Deteksi error dini
  6. Kualitas
  • Kemudian, dua pemodelan awal :
  1. Functional decomposition
  2. Process models: Data Flow Diagrams (DFDs)

Listening Skills
“God gave us two ears and one mouth!”
Analis mendengarkan dan mempelajari operasi bisnis user dan permasalahannya
Listening adalah skill yang perlu dikembangkan
Metode pemodelan menambahkan struktur ketika melakukan interview pada user.
Ini merupakan tool yang efektif untuk Analisa dan Design

Untuk dapat mengerti dunia user kita perlu 3 hal

  1. Modeling notations > mendokumentasikan apa yang kita pelajari, untuk berkomunikasi dengan user.
  2. Modeling techniques > Untuk meyakinkan kita menggunakan tool yang layak, Untuk memberikan gambaranyang akurat mengenai operasi-operasi user.
  3. People sensitivity > Interview dan skill mendengarkan, meyakinkan kita mendapatkan semua informasi yang kita perlukan, sehingga model kita menjadi komplet dan akurat

User memperoleh paradigma yang baru mengenai pekerjaannya
kita bisa mengatakan bahwa
Suatu bisnis itu dikendalikan oleh data
atau:
Suatu bisnis terletak pada banyaknya persediaan data

Data merepresentasikan semua hal-hal yang harus diketahui pengguna pada setiap langkah dari pekerjaan mereka untuk membuat usaha mereka berjalan

Merencanakan usaha pengembangan di awal
Semua pendekatan pemodelan menekankan kita melakukan pekerjaan yang lebih berat pada awal proyek.
Penting, bahwasanya kita harus benar-benar paham,mengerti dan mendefinisikan permasalahan yang ada sebelum merancang suatu solusi

Permasalahan

  • Manajemen mengharapkan melihat hasil pada jangka waktu tertentu dan untuk setiap uang yang dikeluarkannya.
  • kita dapat membuat suatu model pada mingguan atau bulanan, tanpa membuat kode atau tampilan
  • Kita mengenalnya dengan konsep “Deliverables.”
  1. Deliverables: Dokumentasi atau produk yang dihasilakn pada setiap akhir fase dan sub fase projek.
  2. Dengan membuat dokumen atau produk tersebut, akan memberikan informasi kepada manajemen progress pada setiap akhir fase atau sub fase projek

Early detection of errors
Pada suatu pengembanagn sistem
56 % error ada pada fase pendefinisian kebutuhan user.
Namun, 81 % waktu, usaha dan biaya kita habiskan untuk memperbaiki error pada 56 % fase tersebut

  • Jadi, pertama kali kita harus bisa melakukannya dengan benar
  • Ketika kita melakukan kesalahan, penting untuk menemukan dan memperbaiki sesegera mungkin

Quality
Kita membangun sistem :

  • Melakukan hal yang benar (Effectiveness)
  • Dengan Baik (Efficiency)
  • Melakukan apa yang dibutuhkan user
  • Untuk waktu/tahun yang cukup
  • Fleksibel dalam perubahannya

Kualitas adalah
Quality = Customer Satisfaction
(kepuasan pelanggan)

Functional Decomposition

  • Decomposition = Breaking Down.
  • Memecah fungsi bisnis atau proses user menjadi fungsi yang lebih kecil
  • Membantu proses

Data Flow Diagrams (DFDs)

  • Diprmososikan pada 1970an oleh Yourdon, DeMarco, Gane and Sarson, Michael Jackson(!) dan yang lainnya
  • Do not fully address data.
  • Pada 1980an lahir ERDs model.