Pertemuan 14 Class Diagram.

Slides:



Advertisements
Presentasi serupa
UNIFIED MODELLING LANGUAGE
Advertisements

Nur Hayatin, S.ST Jurusan Teknik Informatika Universitas Muhammadiyah Malang Sem Genap 2010.
Polymorphism Viska Mutiawani, M.Sc.
CLASS DIAGRAM.
UML (Unified Modelling Language)
Architecture dan design
USE CASE DIAGRAM.
KelompoK 4 Agus Dwi Prayogo / 2928 Rian Chikita / 2942
Bab 6 class diagram Catur Iswahyudi.
Inheritance (Pewarisan)
Pemrograman Berorientasi Obyek Oleh Tita Karlita
PEMODELAN SISTEM INFORMASI
Hubungan Antar Kelas.
Rekayasa Perangkat Lunak IT104
1 Pertemuan 9 Inheritance Matakuliah: T0044/Pemrograman Berorientasi Obyek Tahun: 2005 Versi: 1.0.
Class Diagram.
CLASS DIAGRAM Materi Pertemuan 26
USE CASE DIAGRAM.
Source Code edit, compile, debug, link
Unified Modeling Language [UML]
UNIFIED MODELLING LANGUAGE
CLASS DIAGRAM.
TEKNIK – TEKNIK ANALISA DESAIGN MENGGUNAKAN ERD DAN UML
Diagram Class, Diagram Objek Diagram Component dan Deployment
USE CASE DIAGRAM.
Object-Oriented Design (OOD)
CLASS DIAGRAM Kelompok 2 Moch Riesdyan mulya ( )
E. Haodudin Nurkifli Universitas Ahmad Dahlan Pertemuan
OBJEK dan KELAS Sutrisno PTIIK-UB.
Access Modifier.
Inheritance dan Kata Kunci static
USE CASE DIAGRAM.
ADBO (Analisa Desain Berorientasi Obyek)
Rekayasa Perangkat Lunak Class Diagram
Encapsulation, Inheritance, Polymorphism
Class Diagram Level Design
Pewarisan Disusun Oleh: Reza Budiawan Untuk:
MODIFIER JAVA.
Contoh Kasus: Agregasi
Rekayasa Perangkat Lunak
Class Diagram oleh : Bambang Hermawan, S.Si
UNIFIED MODELLING LANGUAGE
Association, Composition dan Inheritance
CLASS DIAGRAM.
CLASS DIAGRAM Pertemuan 6.
PEMODELAN SISTEM INFORMASI
PEMODELAN SISTEM INFORMASI BERORIENTASI OBYEK
UML Class Diagram.
Inheritance.
USE CASE DIAGRAM.
INHERITANCE (PEWARISAN)
Statechart , Class, Component & Deployment Diagram
Statechart , Class, Component & Deployment Diagram
Perancangan PL berorientasi objeck
Unified Modelling Languange (UML)
Pertemuan 4 CLASS DIAGRAM.
OOP ENKAPSULASI SMKN 2 SINGOSARI Kelas XI RPL.
SEKOLAH TINGGI MANAJEMEN INFORMATIKA DAN KOMPUTER (STMIK) PALANGKARAYA
Visualisasi Class dan Association Relationship
UML Class Diagram.
KelompoK 4 Agus Dwi Prayogo / 2928 Rian Chikita / 2942
Pertemuan 9 UML Diagram Class & Diagram Objek
Perancangan Perangkat Lunak –Part 2
Class Diagram oleh : Bambang Hermawan, S.Si
Perancangan Berorientasi Objek (UML)
Perancangan Berorientasi Objek (UML)
Rekayasa Perangkat Lunak
OBJECT ORIENTED ANALISYS AND DESIGN
Encapsulation / Visibility, Getter Setter, Pewarisan, Overloading dan Overriding PBO.
Pemrograman berorientasi objek
Transcript presentasi:

Pertemuan 14 Class Diagram

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. Metoda Contoh: mahasiswa (kelas) memiliki NIM, alamat, dan nomor telepon (atribut). Mahasiswa mendaftar kelas, membatalkan kelas, meminta transkripsi nilai (metode)

CLASS DIAGRAM (LANJUTAN) 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 Nama Class Atribut Metode/operasi

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)

MULTIPLICITY Unspecified Exactly one Zero or more (many, unlimited) One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges Specification of multiplicity flushes out business rules and assumptions. The lower bound is critical, as the lower bound is what determines whether or not the relationship is optional (e.g., a lower bound of 0 indicates that the relationship is optional). Multiplicity is needed on both ends of a relationship, even if you can only navigate in one direction. Even though there is no need to navigate in that direction, the multiplicity still provides valuable business information. Sometimes navigation decisions are made for performance reasons, which may change over time. The multiplicity should reflect the requirements. Navigation is discussed on later slides. The use of ‘N’ instead of ‘*’ is Booch, not UML (e.g., the use of “0..N” and ‘N’ is not UML). 1 0..* * 1..* 0..1 2..4 2, 4..6

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 Inheritance If A inherits from B A is the subclass of B, B is the superclass of A Pure inheritance: jika A mewarisi seluruh atribut dan metode dari B.

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());