PEMODELAN SISTEM INFORMASI Konsep Dasar Sistem Informasi Sistem

  • Slides: 119
Download presentation
PEMODELAN SISTEM INFORMASI

PEMODELAN SISTEM INFORMASI

Konsep Dasar Sistem Informasi � Sistem Informasi Suatu sistem di dalam suatu organisasi yang

Konsep Dasar Sistem Informasi � Sistem Informasi Suatu sistem di dalam suatu organisasi yang mempertemukan kebutuhan pengolahan transaksi harian yang mendukung fungsi operasi organisasi

Konsep Dasar Sistem Informasi � Sistem › Seperangkat unsur-unsur yang terdiri dari manusia, mesin

Konsep Dasar Sistem Informasi � Sistem › Seperangkat unsur-unsur yang terdiri dari manusia, mesin atau alat dan prosedur serta konsep-konsep yang dihimpun menjadi satu untuk maksud dan tujuan bersama � Informasi › Data yang dioleh menjadi bentuk yang lebih berguna dan berarti bagi yang menerimanya

Pengembangan Sistem Menyusun sistem baru utk menggantikan sistem lama secara keseluruhan atau memeperbaiki sistem

Pengembangan Sistem Menyusun sistem baru utk menggantikan sistem lama secara keseluruhan atau memeperbaiki sistem yg telah ada.

SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) Identifikasi : sasaran, jangka waktu, dana, team Mempelajari /mendefenisikan

SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) Identifikasi : sasaran, jangka waktu, dana, team Mempelajari /mendefenisikan sistem yg sedang berjalan rinci/d etail

Perencanaan: Keuntungan dari merencanakan proyek SI: · Menentukan lingkup dari proyek; · Mengenali berbagai

Perencanaan: Keuntungan dari merencanakan proyek SI: · Menentukan lingkup dari proyek; · Mengenali berbagai area permasalahan potensial; · Mengatur urutan tugas; · Memberikan dasar untuk pengendalian.

Analisis: 1) Mengumumkan Penelitian Sistem: untuk mengurangi kekuatiran akan adanya aplikasi komputer baru, kiranya

Analisis: 1) Mengumumkan Penelitian Sistem: untuk mengurangi kekuatiran akan adanya aplikasi komputer baru, kiranya perlu dikomunikasikan dengan cara (a)alasan perusahaan melaksanakan proyek; (b)bagaimana sistem baru akan menguntungkan perusahaan dan pegawai; 2) Mengorganisasikan tim proyek: sebaiknya pemimpin proyek adalah spesialis informasi, jangan pemakai;

3) Mendefinisikan kebutuhan pemakai: pengumpulan informasi kebutuhan pemakai dapat dilakukan dengan: wawancara perorangan, pengamatan,

3) Mendefinisikan kebutuhan pemakai: pengumpulan informasi kebutuhan pemakai dapat dilakukan dengan: wawancara perorangan, pengamatan, pencarian catatan dan survei. Wawancara lebih disukai, karena: (1) adanya komunikasi dua arah dan pengamatan terhadap bahasa tubuh; (2) meningkatkan antusiasme pada proyek baik dari pihak spesialis, maupun pemakai; (3) dapat menjalin kepercayaan antara pemakai dan spesialis informasi; (4) memberi kesempatan bagi peserta proyek kalau ada perbedaan pandangan.

Dokumentasinya dapat berupa flowchart, diagram arus data (data flow diagram), dan grafik serta penjelasan

Dokumentasinya dapat berupa flowchart, diagram arus data (data flow diagram), dan grafik serta penjelasan naratif dari proses dan data. Semua dokumentasi ini yang menjelaskan sistem ini disebut kamus proyek.

4) Mendefinisikan kriteria kinerja sistem: setelah kebutuhan informasi didefinisikan, langkah selanjutnya adalah menspesifikasikan secara

4) Mendefinisikan kriteria kinerja sistem: setelah kebutuhan informasi didefinisikan, langkah selanjutnya adalah menspesifikasikan secara tepat kriteria kinerja sistem. Contoh, manajer pemasaran menetapkan kriteria laporan biaya bulanan sbb: (1) laporan disiapkan dalam kertas dan tampilan; (2) laporan disediakan tidak lebih dari 3 hari setelah akhir bulan; (3) laporan harus membandingkan pendapatan dan biaya aktual dengan anggaran. 5) Menyiapkan usulan rancangan: analis sistem memberikan kesempatan bagi manajer untuk membuat keputusan teruskan/ hentikan untuk kedua kalinya. Manajer harus menyetujui tahap rancangan dukungan bagi keputusan itu termasuk usulan rancangan.

6) Menyetujui atau menolak rancangan proyek: manajer dan komite pengarah SIM mengevaluasi usulan rancangan

6) Menyetujui atau menolak rancangan proyek: manajer dan komite pengarah SIM mengevaluasi usulan rancangan dan menentukan apakah disetujui atau tidak.

Perancangan: Langkah-langkahnya adalah sebagai berikut: 1) Menyiapkan rancangan sistem yang terinci: analis bekerja sama

Perancangan: Langkah-langkahnya adalah sebagai berikut: 1) Menyiapkan rancangan sistem yang terinci: analis bekerja sama dengan pemakai dan mendokumentasikan rancangan sistem baru dengan alat-alat yang telah dijelaskan dalam modul teknis. Penggambaran dilakukan dari yang besar dan secara bertahap secara rinci dengan pendekatan top-down dan ini biasanya dilakukan untuk rancangan terstruktur (structured design). 2) Mengidentifikasikan berbagai alternatif konfigurasi sistem: Analis harus mengidentifikasikan konfigurasi (bukan merek atau model) peralatan komputer yang akan memberikan hasil terbaik bagi sistem untuk menyelesaikan pemrosesan. 3) Mengevaluasi berbagai alternatif konfigurasi sistem: analis bekerja bersama manajer mengevaluasi berbagai alternatif dan dipilih yangpaling memungkinkan subsistem memenuhi kriteria kinerja, dengan kendala-kendala yang ada.

4) Memilih konfigurasi yang terbaik: analis mengevaluasi semua konfigurasi subsistem dengan menyesuaikan kombinasi peralatan

4) Memilih konfigurasi yang terbaik: analis mengevaluasi semua konfigurasi subsistem dengan menyesuaikan kombinasi peralatan sehingga semua subsistem menjadi satu konfigurasi tunggal. Setelah dianalisis kemudian direkomendasikan kepada manajer untuk disetujui. Persetujuan dilakukan oleh Komite pengarah SIM. 5) Menyetujui usulan penerapan: analisis menyiapkan usulan penerapan yang mengikhtisarkan tugas-tugas penerapan yang harus dilakukan, keuntungan yang diharapkan dan biayanya. 6) Menyetujui atau menolak penerapan sistem: jika keuntungan dari sistem melebihi biayanya, penerapan akan disetujui.

Metodologi Pengembangan Sistem Yaitu : metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan yang akan digunakan sebagai

Metodologi Pengembangan Sistem Yaitu : metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan yang akan digunakan sebagai pedoman bagaimana dan apa yang harus dikerjakan selama pengembangan ini.

Metodologi Pengembangan Sistem Metode dalam penerapan tahapan pengembangan SI Daur Hidup Pengembangan Sistem (System

Metodologi Pengembangan Sistem Metode dalam penerapan tahapan pengembangan SI Daur Hidup Pengembangan Sistem (System Development Life Cycle (SDLC)) Waterfall (Model air terjun) Defenisi kebutuhan Perancangan sistem Pemasangan sistem Pengoperasian sistem Sistem menjadi usang

Pemodelan � Model › Suatu penyederhanaan dari yang nyata › Menyediakan cetak biru (blue

Pemodelan � Model › Suatu penyederhanaan dari yang nyata › Menyediakan cetak biru (blue print) dari suatu sistem › Suatu perwakilan atau abstraksi dari suatu objek atau situasi aktual � Pemodelan › Rangkaian aktivitas pembuatan model

� Banyak bentuk model yang digunakan dalam perancangan sistem, diantaranya : › › �

� Banyak bentuk model yang digunakan dalam perancangan sistem, diantaranya : › › � model narasi Model prototype Model grafis Dll Perangkat yang digunakan untuk pemodelan suatu sistem : › › › Aliran Sistem Informasi (ASI) Contex Diagram Data flow diagram Kamus data UML (Unified Modeling Language)

Berbagai model penggambaran sistem a. Model sistem yang logis (logical system model) Melukiskan suatu

Berbagai model penggambaran sistem a. Model sistem yang logis (logical system model) Melukiskan suatu sistem atau apa yang harus dikerjakan oleh suatu sistem, dan bukan bagaiman suatu sistem harus diimplementasikan Menggambarkan kebutuhan utama sisten (essential system model) b. Model rinci untuk proses, misalnya DFD level rinci c. Model untuk data, mis ERD d. Model utk menggambarkan interface, mis Context Diagram e. Model utk menggambarkan objek, mis UML f. dll

ALIRAN SISTEM INFORMASI (ASI) Disebut juga document flowchart atau form flowchart atau Bagan Alir

ALIRAN SISTEM INFORMASI (ASI) Disebut juga document flowchart atau form flowchart atau Bagan Alir Dokumen (BAD) � Merupakan salah satu alat bantu perancangan sistem untuk menunjukkan bagan alir sistem dari sebuah organisasi � Menunjukkan urut-urutan dokumen dari satu bagian ke bagian lainnya, proses-proses yang dilakukan sehingga menghasilkan serangkaian informasi. � Yang menjadi tolok ukur prosedur-prosedur apa yang harus dibenahi dalam sebuah organisasi, apakah perlu dipotong, ditambah, di komputerisasikan dan lain sebagainya. �

Simbol-simbol ASI

Simbol-simbol ASI

Sistem informasi Penjualan: 1. Distributor yang menyerahkan nota permintaan barang pada bagian marketing. 2.

Sistem informasi Penjualan: 1. Distributor yang menyerahkan nota permintaan barang pada bagian marketing. 2. Bagian merketing kemudian mencek nota yang diterima tersebut dan kemudian diserahkan pada bagian logistik. 3. Bagian logistik melakukan pengecekan persedian dari barang yang diminta dan langsung membuat faktur penjualan dari barang-barang yang dipesan. faktur dibuat rangkap tiga 4. Rangkap satu dan dua diserahkan ke bagian marketting. 5. Rangkap ketiga disimpan sebagai arsip. 6. Marketting menyerahkan Faktur kepada distributor beserta barang yang dipesan sebagai bukti transaksi penjualan. 7. Faktur yang tinggal pada bagian marketting diolah menjadi daftar penjualan. 8. Bagian marketing kemudian membuat laporan penjualan berdasarkan daftar penjualan. 9. Laporan dibuat rangkap dua, rangkap pertama diserahkan pada direktur dan yang kedua disimpan sebagai arsip.

TUGAS. . . Sistem Pemesanan Barang pada PT. Kelana Bahari � Bagian gudang menyerahkan

TUGAS. . . Sistem Pemesanan Barang pada PT. Kelana Bahari � Bagian gudang menyerahkan orderan kepada supervisor keuangan � Oleh supervisor keuangan permintaan orderan diproses dan membuatkan daftar orderan untuk dikirim ke kantor pusat. � Daftar orderan yang diterima oleh kantor pusat digunakan untuk proses pengadaan, kemudian mengirimkan daftar pengiriman orderan pada supervisor keuangan. � Oleh supervisor keuangan daftar pengiriman orderan diberikan ke bagian gudang. � Bagian gudang membuat laporan penerimaan barang sebanyak 3 rangkap berdasarkan daftar pengiriman order, kemudian laporan tadi diberikan ke supervisor keuangan untuk di acc. � Laporan penerimaan barang yang di acc oleh supervisor keuangan satu rangkap diarsip, satu rangkap diberikan ke manager operasi dan satu rangkap lagi diberikan ke bagian gudang.

TUGAS. . . Jika terjadi permintaan barang dari loket, bagian gudang akan melakukan pengecekan

TUGAS. . . Jika terjadi permintaan barang dari loket, bagian gudang akan melakukan pengecekan stock dan membuat daftar pengeluaran barang. � Berdasarkan laporan penerimaan barang yang di acc dan daftar pengeluaran barang, bagian gudang membuat laporan pengeluaran dan laporan persediaan sebanyak 3 rangkap, kemudian diberikan ke manager operasi untuk di acc. � Manager operasi melakukan acc laporan � Laporan yang telah di acc satu rangkap diarsipkan oleh manager operasi, dua rangkap diberikan ke bagian gudang. Oleh bagian gudang laporan tadi satu rangkap diarsip dan satu rangkap lagi diberikan ke supervisor keuangan. �

CONTEXT DIAGRAM Merupakan kejadian tersendiri dari suatu Diagram Alir Data (DAD/DFD) � Satu lingkaran

CONTEXT DIAGRAM Merupakan kejadian tersendiri dari suatu Diagram Alir Data (DAD/DFD) � Satu lingkaran merepresentasikan seluruh sistem � Harus berupa suatu pandangan, yang mencakup masukan-masukan dasar, sistem dan keluaran � Tingkatan tertinggi dalam DFD � Hanya memuat satu proses, menunjukkan sistem secara keseluruhan �

� Proses tersebut diberi nomor 0 (nol) � Semua entitas eksternal berikut aliran data

� Proses tersebut diberi nomor 0 (nol) � Semua entitas eksternal berikut aliran data utama menuju dan dari sistem � Tidak memuat penyimpanan data � CD menggarisbawahi sejumlah karakteristik dari suatu sistem : › Kelompok pemakai �Organisasi atau sistem lain dimana sistem kita melakukan komunikasi. Disebut juga TERMINATOR › Data dimana sistem menerima dari lingkungan dan harus diproses dgn cara tertentu

› Data yang dihasilkan sistem akan diberikan ke dunia luar/ext entity › Penyimpanan data

› Data yang dihasilkan sistem akan diberikan ke dunia luar/ext entity › Penyimpanan data yang digunakan bersama antara sistem dengan terminator, dibuat oleh sistem dan digunakan oleh terminator atau sebaliknya, dibuat terminator dan digunakan oleh sistem › Batasan antara sistem dengan lingkungannya

Contoh Context Diagram Sistem Pemesanan Makanan

Contoh Context Diagram Sistem Pemesanan Makanan

Context Diagram memiliki aturan : a. Jika terdapat banyak terminator yang mempunyai banyak masukan

Context Diagram memiliki aturan : a. Jika terdapat banyak terminator yang mempunyai banyak masukan dan keluaran diperbolehkan untuk digambarkan lebih dari satu kali, ditandai secara khusus untuk menjelaskan bahwa terminator yang dimaksud adalah identik. Berupa tanda asterik (*) atau pagar (#). b. Jika terminator mewakili individu sebaiknya diwakili oleh peran yang dimainkan personil tersebut. Alasan pertama adalah personil yang berfungsi untuk melakukan itu dapat berganti sedang Context Diagram harus tetap akurat walaupun personil berganti. Alasan kedua adalah seorang personil dapat memainkan lebih dari satu peran.

c. Karena fokus utama adalah mengembangkan model, maka penting untuk membedakan 5`sesuatu yang harus

c. Karena fokus utama adalah mengembangkan model, maka penting untuk membedakan 5`sesuatu yang harus digambarkan lebih dari sumber data itu sendiri. Sedangkan sistem baru dengan konsep pengembangan teknologinya membuat pelaku menjadi sesuatu yang tidak perlu digambarkan

Contoh Context Diagram dengan duplikasi terminator

Contoh Context Diagram dengan duplikasi terminator

� Bentuk dari eksternal entity diantaranya adalah sebagai berikut: • Suatu kantor, departemen atau

� Bentuk dari eksternal entity diantaranya adalah sebagai berikut: • Suatu kantor, departemen atau divisi dalam perusahaan tetapi di luar sistem yang sedang dikembangkan. • Orang/sekelompok orang di organisasi tetapi di luar sistem yang sedang dikembangkan • Suatu organisasi atau orang yang berada di luar organisasi seperti misalnya langganan, pemasok, dll. • Sistem informasi yang lain di luar sistem yang sedang dikembangkan • Sumber asli dari suatu transaksi • Penerima akhir dari suatu laporan yang dihasilkan oleh sistem

Data Flow Diagram (DFD)

Data Flow Diagram (DFD)

Data Flow Diagram (DFD) Empat simbol dasar yang digunakan untuk memetakan gerakan diagram aliran

Data Flow Diagram (DFD) Empat simbol dasar yang digunakan untuk memetakan gerakan diagram aliran data adalah: � a. External Entity (Entitas)/terminator � Dengan simbol sebagai berikut: � � � Kotak ini digunakan untuk menggambarkan suatu entitas eksternal (bagian lain, sebuah perusahaan, seseorang atau sebuah mesin) yang dapat mengirim data atau menerima data dari sistem. Disebut juga sumber atau tujuan data, dan dianggap eksternal terhadap sistem yang sedang digambarkan. Setiap entitas diberi label dengan sebuah nama yang sesuai. Meskipun berinteraksi dengan sistem, namun dianggap di luar batas sistem. Entitas-entitas tersebut harus diberi nama dengan suatu kata benda bisa digunakan lebih dari sekali utk entitas yang sama

b. Data Flow/Arus data � Simbol yang digunakan adalah tanda panah berikut. � Menunjukkan

b. Data Flow/Arus data � Simbol yang digunakan adalah tanda panah berikut. � Menunjukkan perpindahan data dari satu titik ke titik yang lain, dengan kepala tanda panah mengarah ke tujuan data. � Harus digambarkan dalam kata benda.

� c. Process/Proses � Proses-proses selalu menunjukkan suatu perubahan data � Jadi, aliran data

� c. Process/Proses � Proses-proses selalu menunjukkan suatu perubahan data � Jadi, aliran data yang meninggalkan suatu proses selalu diberi label yang berbeda dari aliran data yang masuk. � Sebuah nama yang jelas memudahkan untuk memahami proses apa yang sedang dilkukan.

Pemberian nama pada proses: 1. Menetapkan nama sistem secara keseluruhan saat menamai proses pada

Pemberian nama pada proses: 1. Menetapkan nama sistem secara keseluruhan saat menamai proses pada level yang lebih tinggi. Contoh: sistem kontrol inventaris. 2. Menamai suatu subsistem utama, menggunakna nama seperti : Sistem pelaporan inventaris atau Sistem pelayanan konsumen internet. 3. Menggunakan format kata kerja – kata sifat – kata benda untuk proses-proses yang mendetail. Kata kerja yang menggambarkan jenis kegiatan yang seperti ini, Misalnya menghitung, memverifikasi, menyiapkan, mencetak atau menambahkan.

d. Data Store (Penyimpanan Data) � Data store dilambangkan dengan bujur sangkar dengan ujung

d. Data Store (Penyimpanan Data) � Data store dilambangkan dengan bujur sangkar dengan ujung terbuka � Menunjukkan penyimpanan data. � Penyimpanan data menandakan penyimpanan manual, seperti lemari file/sebuah file/basisdata terkomputerisasi. Diberi nama dengan sebuah kata benda. � Penyimpanan data sementara seperti kertas catatan/sebuah file komputer sementara tidak dimasukkan ke dalam diagram aliran data. Bentuk dari penyimpanan data diantaranya adalah sebagai berikut: • Suatu file atau database di sistem komputer • Suatu arsip atau catatan manual • Suatu kotak tempat data di meja seseorang • Suatu tabel acuan manual • Suatu agenda atau buku

� Dalam penggambaran penyimpanan data perlu diperhatikan beberapa hal, antara lain: a. Hanya proses

� Dalam penggambaran penyimpanan data perlu diperhatikan beberapa hal, antara lain: a. Hanya proses saja yang berhubungan dengan simpanan data, karena yang mengggunakan/ merubah data di simpanan data adalah suatu proses. b. Arus data yang menuju ke simpanan data dari suatu proses menunjukkan proses update terhadap data yang tersimpan di simpanan data. Update dapat berupa proses: • Menambah/menyimpankan record baru atau dokumen baru ke dalam simpanan data. • Menghapus record atau mengambil dokumen dari simpanan data • Merubah nilai data di suatu record atau di suatu dokumen yang ada di simpanan data

c. Arus data yang berasal dari simpanan data ke suatu proses menunjukkan bahwa proses

c. Arus data yang berasal dari simpanan data ke suatu proses menunjukkan bahwa proses tersebut menggunakan data yang ada di simpanan data. d. Untuk suatu proses yang melakukan keduaduanya yaitu menggunakan dan update simpanan data dapat dipilih salah satu penggambaran. •

Menggambarkan sebuah garis dengan panah mengarah kedua arah yang berlawanan dari simpanan data sebagai

Menggambarkan sebuah garis dengan panah mengarah kedua arah yang berlawanan dari simpanan data sebagai berikut: Menggunakan arus data yang terpisah sebagai berikut: Untuk menghindari garis arus data yang saling berpotongan sehingga membuat gambar di DFD menjadi ruwet, maka simpanan data/kesatuan luar dapat digambar lebih dari sebuah.

PENGGAMBARAN DFD Tidak ada aturan baku untuk menggambarkan DFD, tapi dari berbagai referensi yg

PENGGAMBARAN DFD Tidak ada aturan baku untuk menggambarkan DFD, tapi dari berbagai referensi yg ada, secara garis besar: 1. Buat diagram context � Diagram ini adalah diagram level tertinggi dari DFD yg menggambarkan hubungan sistem dengan lingkungan luarnya. Cara : - Tentukan nama sistemnya. - Tentukan batasan sistemnya. - Tentukan terminator apa saja yg ada dalam sistem. - Tentukan apa yg diterima/diberikan terminator dari/pada sistem. - Gambarkan diagram context. 2. Buat diagram level Satu � Diagram ini adalah dekomposisi dari diagram Context. Cara : - Tentukan proses utama yg ada pada sistem. - Tentukan apa yg diberikan/diterima masing-masing proses pada/dari sistem sambil memperhatikan konsep keseimbangan (alur data yang keluar/masuk dari suatu level harus sama dgn alur data yang masuk/keluar pada level berikutnya) - Apabila diperlukan, munculkan data store (master) sebagai sumber maupun tujuan alur data. - Gambarkan diagram level satu. - Hindari perpotongan arus data - Beri nomor pada proses utama (nomor tidak menunjukkan urutan proses).

3. Buat diagram level Dua � Diagram ini merupakan dekomposisi dari diagram level satu.

3. Buat diagram level Dua � Diagram ini merupakan dekomposisi dari diagram level satu. Cara : - Tentukan proses yg lebih kecil (sub-proses) dari proses utama yg ada di level satu. - Tentukan apa yg diberikan/diterima masing-masing sub-proses pada/dari sistem dan perhatikan konsep keseimbangan. - Apabila diperlukan, munculkan data store (transaksi) sbg sumber maupun tujuan alur data. - Gambarkan DFD level Dua - Hindari perpotongan arus data. - Beri nomor pada masing-masing sub-proses yang menunjukkan dekomposisi dari proses sebelumnya. Contoh : 1. 1, 1. 2, 2. 1

4. DFD level tiga, empat. . � Diagram ini merupakan dekomposisi dari level sebelumnya.

4. DFD level tiga, empat. . � Diagram ini merupakan dekomposisi dari level sebelumnya. � Proses dekomposisi dilakukan sampai dg proses siap dituangkan ke dalam program. � Aturan yg digunakan sama dgn level dua. � KESIMPULAN :

Entity Relationship Diagram � � � ERD adalah model konseptual yang mendeskripsikan hubungan antara

Entity Relationship Diagram � � � ERD adalah model konseptual yang mendeskripsikan hubungan antara penyimpanan (dalam DFD). ERD digunakan untuk memodelkan struktur data dan hubungan antar data. Dengan ERD, model dapat diuji dengan mengabaikan proses yang dilakukan. ERD pertama kali dideskripsikan oleh Peter Chen yang dibuat sebagai bagian dari perangkat lunak CASE. Notasi yang digunakan dalam ERD dapat dilihat pada Tabel di bawah ini :

Langkah-langkah teknis yang dapat dilakukan untuk mendapatkan ERD awal adalah : 1. Mengidentifikasi dan

Langkah-langkah teknis yang dapat dilakukan untuk mendapatkan ERD awal adalah : 1. Mengidentifikasi dan menetapkan seluruh himpunan entitas yang akan terlibat. 2. Menetukan atribut-atribut key (kunci) dari masing himpunan entitas. 3. Mengidentifikasi dan menetapkan seluruh himpunan relasi diantara himpunan entitas yang ada beserta foreign-keynya (kunci asing/ kunci tamu). 4. Menentukan derajad /kardinalitas relasi untuk setiap himpunan relasi. 5. Melengkapi himpunan entitas dan himpunan relasi dengan atribut dekriptif (atribut yang bukan kunci)

Kardinalitas Relasi Dalam ERD hubungan (relasi) dapat terdiri dari sejumlah entitas yang disebut dengan

Kardinalitas Relasi Dalam ERD hubungan (relasi) dapat terdiri dari sejumlah entitas yang disebut dengan derajad relasi. � Derajad relasi maksimum disebut dengan kardinalitas sedangkan derajad minimum disebut dengan modalitas. � Kardinalitas relasi menunjukkan jumlah maksimum entitas yang dapat berelasi dengan entitas pada himpunan entitas lain. � Kardinalitas relasi yang terjadi diantara dua himpunan entitas (misalnya A dan B) dapat berupa : 1. Satu ke satu (one to one/ 1 -1) Setiap entitas pada himpunan entitas A dapat berelasi dengan paling banyak satu entitas pada himpunan entitas B, demikian juga sebaliknya. 2. Satu ke banyak (one to many/ 1 - N) Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas pada himpunan entitas B, tetapi tidak sebaliknya. 3. Banyak ke banyak (many to many/ N –N) Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas pada himpunan entitas B, demikian juga sebaliknya. �

KAMUS DATA Model berikutnya yang akan dibahas adalah data dictionary/DD (Kamus Data/KD). � KD

KAMUS DATA Model berikutnya yang akan dibahas adalah data dictionary/DD (Kamus Data/KD). � KD tidak menggunakan notasi grafis sebagaimana halnya DAD, tetapi porsinya dalam memodelkan sistem tidak perlu diragukan lagi (sebuah model tidak lengkap tanpa KD). � KD berfungsi membantu pelaku sistem untuk mengerti aplikasi secara detil � KD mereorganisasi semua elemen data yang digunakan dalam sistem dengan presisi yang sedemikan rupa sehingga pemakai dan penganalisas sistem memiliki dasar pengertian yang sama tentang masukan, keluaran, penyimpanan dan proses. �

Kamus Data adalah katalog fakta tentang data dan kebutuhan-kebutuhan informasi dari suatu sistem informasi.

Kamus Data adalah katalog fakta tentang data dan kebutuhan-kebutuhan informasi dari suatu sistem informasi. � Kamus data selain digunakan untuk dokumentasi dan mengurangi redudansi, juga dapat digunakan untuk: 1. Memvalidasi diagram aliran data dalam hal kelengkapan dan keakuratan 2. Menyediakan suatu titik awal untuk mengembangkan layar dan laporan-laporan 3. Menentukan muatan data yang disimpan dalam file 4. Mengembangkan logika untuk proses-proses diagram aliran data �

� � Kamus data dibuat berdasarkan arus data yang ada di DAD KD mendefinisikan

� � Kamus data dibuat berdasarkan arus data yang ada di DAD KD mendefinisikan elemen data dengan fungsi sebagai berikut: -Menjelaskan arti aliran data dan penyimpanan data dalam DFD -Mendeskripsikan komposisi paket data yang bergerak melalui aliran (misalnya alamat diuraikan menjadi kota, negara dan kode pos) - Mendeskripsikan komposisi penyimpanan data -Menspesifikasikan nilai dan satuan yang relevan bagi penyimpanan dan aliran -Mendeskripsikan hubungan detil antar penyimpanan (yang akan menjadi titik perhatian dalam entity-relationship diagram)

KD mencerminkan keterangan yang jelas tentang data yang akan dicatat. � Untuk maksud keperluan

KD mencerminkan keterangan yang jelas tentang data yang akan dicatat. � Untuk maksud keperluan ini, maka kamus data harus memuat hal-hal berikut: 1. Nama arus data, karena kamus data dibuat berdasarkan arus data yang mengalir di DAD, maka nama dari arus data juga harus dicatat di KD. 2. Alias, alias atau nama lain dari data dapat dituliskan bila nama lain ini ada. Alias perlu ditulis karena data yang sama mempunyai nama yang berbeda untuk orang atau departemen satu dengan yang lainnya. Misalnya bagian pembuat faktur dan langganan menyebut bukti penjualan sebagai faktur, sedangkan bagian gudang menyebutnya sebagai tembusan permintaan persediaan. � Baik faktur dan tembusan permintaan persediaan ini elemen yang berbeda. �

3. Bentuk data, telah diketahui bahwa arus data dapat mengalir: • Dari kesatuan luar

3. Bentuk data, telah diketahui bahwa arus data dapat mengalir: • Dari kesatuan luar ke suatu proses, data yang mengalir ini biasanya tercatat di suatu dokumen atau formulir. • Hasil dari suatu proses ke kesatuan luar, data yang mengalir ini biasanya terdapat di media laporan atau query tampilan layar atau dokumen hasil cetakan komputer; • Hasil suatu proses ke proses yang lain, data yang mengalir ini biasanya dalam bentuk variabel atau parameter yang dibutuhkan oleh proses penerimanya; • Hasil suatu proses yang direkamkan ke simpanan data, data yang mengalir ini biasanya berbentuk suatu variabel. • Dari simpanan data dibaca oleh suatu proses, data yang mengalir ini biasanya berupa suatu field (item data).

� Dengan demikian bentuk dari data yang mengalir dapat berupa: dokumen dasar atau formulir,

� Dengan demikian bentuk dari data yang mengalir dapat berupa: dokumen dasar atau formulir, dokumen hasil cetakan komputer, laporan tercetak, tampilan di layar monitor, variabel, parameter, field.

4. Arus data, arus data menunjukkan dari mana data mengalir dan ke mana data

4. Arus data, arus data menunjukkan dari mana data mengalir dan ke mana data akan menuju. Keterangan ini perlu dicatat di KD agar mudah mencari arus data di DAD. 5. Penjelasan, Untuk lebih memperjelas lagi tentang makna dari arus data yang dicatat di KD, maka bagian penjelasan dapat diisi dengan keterangan-keterangan tentang arus data tersebut. Misalnya nama dari arus data adalah Tembusan Permintaan Persediaan, maka dapat lebih dijelaskan sebagai tembusan dari faktur penjualan untuk meminta barang dari gudang.

6. . Periode, periode ini menunjukkan kapan terjadinya arus data ini. Periode perlu dicatat

6. . Periode, periode ini menunjukkan kapan terjadinya arus data ini. Periode perlu dicatat di KD karena dapat digunakan untuk mengidentifikasikan kapan input data harus dimasukkan ke sistem, kapan proses dari program harus dilakukan dan kapan laporan-laporan harus dihasilkan.

7. . Volume, volume yang perlu dicatat di KD adalah tentang volume rata-rata dan

7. . Volume, volume yang perlu dicatat di KD adalah tentang volume rata-rata dan volume puncak dari arus data. Volume rata-rata menunjukkan banyaknya rata-rata arus data yang mengalir dalam satu periode tertentu dan volume puncak menunjukkan volume yang terbanyak. V olume ini digunakan untuk mengidentifikasikan besarnya simpanan luar yang akan digunakan, kapasitas dan jumlah dari alat input, alat pemroses dan alat output. 8. . Struktur data, struktur data menunjukkan arus data yang dicatat di KD terdiri dari item data apa saja.

� Contoh-contoh dari pemakaian simbol-simbol di atas, adalah: Contoh 1: Tembusan Permintan Persediaan =

� Contoh-contoh dari pemakaian simbol-simbol di atas, adalah: Contoh 1: Tembusan Permintan Persediaan = Kode Langganan + Nama Langganan + Tanggal Penjualan + Nomor Faktur + 1{ Informasi Barang }5 + Total Penjualan + ( Potongan Penjualan) + Pajak Penjualan + Total Dibayar + Jenis Penjualan

Informasi Barang = Kode Barang + Nama Barang + Unit Jual + Harga Satuan

Informasi Barang = Kode Barang + Nama Barang + Unit Jual + Harga Satuan + Total Harga Jenis Penjualan = [ Cash | Credit ]

Contoh 2 :

Contoh 2 :

Struktur Data: Record Pegawai = Nomor Pegawai + Informasi Pribadi + Informasi Gaji +

Struktur Data: Record Pegawai = Nomor Pegawai + Informasi Pribadi + Informasi Gaji + Informasi Pembayaran Saat Ini + Informasi Gaji Tahunan Sampai Hari Ini Record File Waktu = Nomor Pegawai + Nama Pegawai + Jam Kerja Pembayaran Cek Gaji = Nomor Pegawai + Nama Pegawai + Alamat + Jumlah Pembayaran Saat Ini + Jumlah Gaji Tahunan Sampai Saat Ini

Informasi Gaji = Perhitungan Pembayaran + Jumlah Tanggungan Jumlah Pembayaran Saat Ini = Gaji

Informasi Gaji = Perhitungan Pembayaran + Jumlah Tanggungan Jumlah Pembayaran Saat Ini = Gaji Kotor + Potongan Pajak Pemerintah + Potongan Pajak Negara Bagian + Potongan Pajak Jaminan Sosial + Gaji Bersih

Untuk mengecek kebenaran (kelengkapan, konsistensi dan kontradiksi) dari kamus data, maka dapat digunakan testing

Untuk mengecek kebenaran (kelengkapan, konsistensi dan kontradiksi) dari kamus data, maka dapat digunakan testing dengan sejumlah pertanyaan sebagai berikut: • Apakah semua aliran dalam DFD sudah didefinisikan dalam kamus data? • Apakah semua komponen elemen data sudah didefinisikan? • Adakah elemen data yang didefinisikan lebih dari satu kali? • Apakah semua notasi yang digunakan pada kamus data sudah dikoreksi? • Adakah elemen data dalam kamus data tidak menjelaskan sesuatu dalam data flow diagram, entity relation atau state transition diagram?

UML Unified Modeling Language

UML Unified Modeling Language

Sejarah UML (Unified Modeling Language) Pada Oktober 1994, Dr. James Rumbaugh bergabung dengan Perusahaan

Sejarah UML (Unified Modeling Language) Pada Oktober 1994, Dr. James Rumbaugh bergabung dengan Perusahaan Rational sotware, dimana Grady Booch sudah bekerja disana sebelumnya. Grady Booch mengembangkan Object Oriented Design (OOD) dan Dr. James Rumbaugh mengembangkan Object Modeling Technique (OMT). Duet Mereka pada Oktober 1995 menghasilkan Unified Method versi 0. 8. � Musim gugur 1995 Dr. Ivar Jacobson ikut pula bergabung dengan duet Rumbaugh-Booch, dengan memperkenalkan tool use case. Trio tersebut pada bulan Juni 1996 menghasilkan Unified Modeling Language (UML) versi 0. 9. Sebelumnya Dr. Ivar Jacobson mengembangkan Object Oriented Software Engineering (OOSE) � Trio ini mengembangkan Ratinal Unified Process (RUP) � Banyak perusahaan software merasakan bagaimana pentingnya UML dalam tujuan strategis mereka, sehingga beberapa perusahaan membentuk sebuah konsorsium yang terdiri dari perusahaan-perusahaan seperti � Microsoft Oracle IBM Hewlett-Packard Intellicorp I-Logix DEC, Digital Equipment Corp. texas instrument Rational software ICON computing MCI systemhouse Unisys Platinum Technology Ptech Taskon and Reich Technologies Softeam

Sejarah UML (Unified Modeling Language) Dari konsorsium tersebut pada bulan Januari 1997 lahirlah UML

Sejarah UML (Unified Modeling Language) Dari konsorsium tersebut pada bulan Januari 1997 lahirlah UML versi 1. 0 Pada bulan September 1997 lahirlah UML versi 1. 1, dengan 8 buah diagram, yaitu �Use case diagram �Activity diagram �Sequence diagram �Collaboration diagram �Class diagram �Statechart diagram Grady Booch �Component diagram Ivar Jacobson James Rumbaugh �Deployment diagram � Pada bulan November 1997 sebuah organisasi non profit standarisasi Object Management Group (OMG) mengakui UML sebagai sebuah bahasa pemodelan standar untuk aplikasi object oriented. � OMG didirikan pada bulan April 1989 oleh sebelas perusahaan software, dengan kantor pusat di Needham, MA, USA. (www. omg. org) � Pada tahun 1999 lahirlah UML versi 1. 3, menjadi 9 buah diagram, dengan penambahan � � › Business use case diagram

Sejarah UML (Unified Modeling Language) Pada May 2001 lahirlah UML versi 1. 4, menjadi

Sejarah UML (Unified Modeling Language) Pada May 2001 lahirlah UML versi 1. 4, menjadi 10 buah diagram, dengan penambahan › Object Diagram � Pada tahun 2002 lahirlah UML versi 2. 0, menjadi 13 buah diagram, dengan penambahan dan penggantian yaitu : � 1. Use case diagram 2. Activity diagram 3. Sequence diagram 4. Communication Diagram (Collaboration diagram in versi 1. x) 5. Class diagram 6. State Machine Diagram (Statechart diagram in versi 1. x) 7. Component diagram 8. Deployment diagram 9. Composite Structure Diagram 10. Interaction Overview Diagram 11. Object Diagram 12. Package Diagram 13. Timing Diagram

● UML adalah bahasa model standar untuk pengembangan cetak biru perangkat lunak. ● Bahasa

● UML adalah bahasa model standar untuk pengembangan cetak biru perangkat lunak. ● Bahasa model merupakan bahasa yang memiliki kamus kata dan aturan yang berpusat pada gambaran konseptual dan fisik dari suatu sistem ● UML sebagai bahasa model menyatakan bagaimana membuat dan membaca model dengan benar, namun tidak menyatakan model apa yang harus dibuat dan kapan seharusnya dibuat

Peran UML adalah bahasa untuk ● Visualisasi Menggambarkan ide dalam notasi dan semantik yang

Peran UML adalah bahasa untuk ● Visualisasi Menggambarkan ide dalam notasi dan semantik yang lebih mudah dipahami oleh siapapun ● Spesifikasi dari semua keputusan penting analisa, perancangan, dan penerapan yang harus diambil dalam pengembangan deployment sistem PL

● Konstruksi – UML bukan bahasa pemrograman visual – Model UML dapat dihubungkan secara

● Konstruksi – UML bukan bahasa pemrograman visual – Model UML dapat dihubungkan secara langsung dengan beberapa bahasa pemrograman – Forward engineering: menghasilkan kode dari model – Reverse engineering: membangun model dari kode ● Dokumentasi – UML mencakup dokumentasi arsitektur sistem dan rincinya – Sebagai suatu bahasa untuk menyatakan kebutuhan dan pengujian. – UML menyediakan bahasa untuk aktifitas perencanaan proyek dan manajemen release

Blok Pembangun UML ● Thing – “penghuni” paling elit dalam model ● Structural, Behavioral,

Blok Pembangun UML ● Thing – “penghuni” paling elit dalam model ● Structural, Behavioral, Grouping, Annotations ● Relationship – Menghubungkan antar thing ● Dependency, Association, Generalization, Realization ● Diagram – Kumpulan thing dan relationship

Structural Things (1) ● Structural thing merupakan kata benda model UML – Class ●

Structural Things (1) ● Structural thing merupakan kata benda model UML – Class ● Gambaran dari sekumpulan objek yang berbagi atribut, operasi, hubungan dan semantik yang sama ● Sebuah class menerapkan satu atau lebih antarmuka – Interface ● Sekumpulan operasi yang menyatakan layanan suatu class atau component ● Suatu interface menggambarkan perilaku objek yang disediakan untuk pihak luar. ● Interface bisa saja menyatakan sebagian atau seluruh perilaku suatu class/component.

● Collaboration – Suatu interaksi dan suatu kumpulan aturan dan elemen lain yang bekerja

● Collaboration – Suatu interaksi dan suatu kumpulan aturan dan elemen lain yang bekerja bersama untuk perilaku yang bekerja sama – Menyatakan penerapan pola yang membentuk sistem ● Use Case – Suatu gambaran dari sekumpulan urutan aksi yang terjadi pada sistem yang menghasilkan suatu nilai kepada actor – Digunakan untuk menstrukturkan perilaku sistem dalam suatu model – Merupakan realisasi dari collaboration.

● Active Class – Suatu class dimana objek memiliki satu atau lebih proses/thread sehingga

● Active Class – Suatu class dimana objek memiliki satu atau lebih proses/thread sehingga dapat memulai aktifitas kontrolnya ● Component – Suatu bagian fisik dan replaceable dari suatu sistem menyediakan realisasi dari sekumpulan antarmuka – Menyatakan paket fisik daripada elemen logika, seperti class, interface dan collaboration ● Node – Elemen fisik yang ada pada saat run time dan menyatakan suatu sesumber perhitungan, yang memiliki memori dan kemampuan pemrosesan

Behavioral Things ● Behavioral things merupakan bagian dinamis dari model UML, yang menyatakan kata

Behavioral Things ● Behavioral things merupakan bagian dinamis dari model UML, yang menyatakan kata kerja dari suatu model, menyatakan perilaku sepanjang waktu dan ruang. – Interaction: suatu perilaku yang terdiri dari sekumpulan pertukaran pesan diantara sekumpulan objek dalam suatu kontek untuk mencapai suatu tujuan – state machine: suatu perilaku yang menentukan urutan state dari suatu objek atau interaksi terhadap objek tersebut selama “hidup”nya.

Grouping Things ● Grouping things : bagian organisasional model UML. ● Package : mekanisme

Grouping Things ● Grouping things : bagian organisasional model UML. ● Package : mekanisme umum untuk mengorganisasikan elemen-elemen ke dalam kelompok-kelompok – Structural things, behavioral things, dan pengelompokan yang lain dapat ditempatkan dalam sebuah package. – Berbeda dengan component (yang ada selama run time), package sepenuhnya konseptual (ada hanya pada waktu pengembangan)

Annotations Things ● Annotational things : bagian model UML yang memberikan keterangan. – Note:

Annotations Things ● Annotational things : bagian model UML yang memberikan keterangan. – Note: suatu simbol yang memberikan batasan dan komentar yang dikaitkan pada suatu elemen atau kumpulan elemen

Relationships ● Dependency – Suatu hubungan semantik antara dua things dimana perubahan pada satu

Relationships ● Dependency – Suatu hubungan semantik antara dua things dimana perubahan pada satu thing (independent) mungkin mempengaruhi semantik thing (dependent) lain. ● Association – Hubungan struktural yang menggambarkan sehimpunan mata rantai antar objek.

– Aggregation merupakan bentuk association khusus yang menyatakan hubungan struktural antara whole dan part

– Aggregation merupakan bentuk association khusus yang menyatakan hubungan struktural antara whole dan part ● Generalization – Hubungan spesialisasi dimana objek dari elemen khusus (anak) merupakan pengganti untuk objek elemen umum (induk)

● Realization – Hubungan antara antarmuka yang tersedia secara umum (interface atau use case)

● Realization – Hubungan antara antarmuka yang tersedia secara umum (interface atau use case) dengan penerapan detail dari antarmuka (class, package, atau use case realization).

UML View ● Arsitektur dan perancangan sistem memungkinkan kita untuk mengatur cara pandang yang

UML View ● Arsitektur dan perancangan sistem memungkinkan kita untuk mengatur cara pandang yang berbeda terhadap sistem dan kontrol terhadap sistem keseluruhan ● UML memungkinkan kita untuk memodelkan sistem untuk kepentingan berbagai cara pandang.

Diagram-diagram UML (1) ● Business Use Case Diagrams – Digunakan untuk menyatakan fungsionalitas yang

Diagram-diagram UML (1) ● Business Use Case Diagrams – Digunakan untuk menyatakan fungsionalitas yang disediakan oleh suatu organisasi secara keseluruhan – Digunakan secara intensif selama aktifitas pemodelan bisnis untuk menghimpun kontek sistem dan membentuk dasar pembuatan use case – Tidak dibedakan antara proses manual atau otomatis (use case fokus ke proses otomatis) (dipandang dari sudut pandang organisasi) – Business use case: proses fungsional bisnis – Business actor: peran dimana bisnis berinteraksi

● Business Use Case Diagrams – Kapan digunakan? ● Merupakan organisasi yang baru ●

● Business Use Case Diagrams – Kapan digunakan? ● Merupakan organisasi yang baru ● Sedang menjalankan dan atau sedang menerapkan rekayasa ulang bisnis ● Membangun software yang berimbas pada bagian penting perusahaan ● Terdapat workflow komplek yang tidak terdokumentasi ● Konsultan pada organisasi yang baru – Kapan tidak perlu membuat Business Use Case? ● Sudah memahami visi, misi dan workflow organisasi ● Hanya membangun software yang tidak berimbas besar pada organisasi ● Jika tidak tersedianya waktu.

Contoh Business Use Case

Contoh Business Use Case

● Use Case Diagrams – Memperlihatkan inetarksi antara use case dan actor. – Use

● Use Case Diagrams – Memperlihatkan inetarksi antara use case dan actor. – Use cases mewakili fungsionalitas sistem, kebutuhan sistem dari sudut pandang pemakai. – Actors mewakili orang atau sistem yang menyediakan atau menerima informasi dari sistem.

Contoh Use Case

Contoh Use Case

● Activity Diagram – Menggambarkan aliran fungsionalitas dalam suatu sistem. – Dapat digunakan dalam

● Activity Diagram – Menggambarkan aliran fungsionalitas dalam suatu sistem. – Dapat digunakan dalam pemodelan bisnis untuk menunjukkan business workflow. – Atau juga digunakan dalam analisa kebutuhan untuk menggambarkan aliran kejadian melalui suatu use case. – Mendefinisikan dimana workflow dimulai, dimana berhentinya, aktifitas apa yang terjadi selama workflow, bagaimana urutan kejadian aktifitas – Suatu aktifitas adalah suatu pekerjaan yang dilaksanakan selama workflow

Contoh Activity Diagram

Contoh Activity Diagram

● Sequence Diagram – Merupakan diagram interaksi yang menekankan urutan waktu pertukaran pesan ●

● Sequence Diagram – Merupakan diagram interaksi yang menekankan urutan waktu pertukaran pesan ● Collaboration Diagram – Collaboration diagrams menampilkan informasi yang sama dengan Sequence diagrams. – Hanya saja, interaksi antara objek dan actor tidak ditampilkan berdasar urutan waktu.

Contoh Sequence Diagram

Contoh Sequence Diagram

Contoh Collaboration Diagram

Contoh Collaboration Diagram

● Class Diagram – Memperlihatkan interaksi antar class dalam sistem. – Class merupakan suatu

● Class Diagram – Memperlihatkan interaksi antar class dalam sistem. – Class merupakan suatu cetak biru untuk objek – Memperlihatkan gambaran statik dari class-class dan hubungannya ● Statechart Diagram – Menyediakan cara memodelkan berbagai state keberadaan objek. – Digunakan untuk memodelkan lebih dinamis perilaku dari sistem

Contoh Class Diagram

Contoh Class Diagram

Statechart Diagram

Statechart Diagram

● Component Diagrams – Memperlihatkan organisasi dan ketergantungan antara sekumpulan komponen. (Implementation view) –

● Component Diagrams – Memperlihatkan organisasi dan ketergantungan antara sekumpulan komponen. (Implementation view) – Dihubungkan dengan class diagram dimana komponen tersebut memetakan satu atau lebih class, interface, atau collaboration. ● Deployment Diagrams – Memperlihatkan konfigurasi run-time pada node pemrosesan dan komponen yang berjalan padanya. – (static deployment view) – Dihubungkan dengan component diagrams dimana sebuah node menyertakan satu atau lebih komponen

Contoh Component Diagram

Contoh Component Diagram

Deployment Diagram

Deployment Diagram

Pemakai model UML (1) ● Tidak hanya pengembang yang akan menggunakan UML – Seluruh

Pemakai model UML (1) ● Tidak hanya pengembang yang akan menggunakan UML – Seluruh tim akan menggunakan Business Use Case diagram untuk memahami bisnis dalam sistem. – Pelanggan dan manajer proyek akan menggunakan Use Case diagram untuk mendapat gambaran level tinggi dari sistem dan menyetujui ruang lingkup proyek. – Manajer proyek akan menggunakan Use Case diagram dan dokumentasi untuk membagi proyek ke dalam sub proyek yang mudah diatur.

● Analis dan pelanggan akan meninjau dokumentasi use case untuk melihat fungsi apa saja

● Analis dan pelanggan akan meninjau dokumentasi use case untuk melihat fungsi apa saja yang akan disediakan oleh sistem. ● Penulis teknis akan melihat pada dokumentasi use case untuk memulai menulis user manual dan rencana pelatihan. ● Analis dan pengembang akan melihat Sequence dan Collaboration diagram untuk mendapat gambaran bagaimana aliran logika dalam sistem, objek dalam sistem dan pertukaran pesan antar objek. ● Pegawai asuransi kualitas (QA) menggunakan dokumentasi use case dan Collaboration diagram untuk mendapatkan informasi yang mereka butuhkan untuk menguji script

● Pengembang menggunakan Class dan Statechart diagram untuk mendapat gambaran detil sebagian sistem dan

● Pengembang menggunakan Class dan Statechart diagram untuk mendapat gambaran detil sebagian sistem dan bagaimana mereka menghubungkan. ● Pegawai Deployment menggunakan Component dan Deployment diagram untuk melihat file executable, DLL , atau komponen lain yang akan dibuat, dan dimana komponen tersebut akan di-deploy pada jaringan. ● Seluruh tim menggunakan model untuk memastikan kebutuhan terselusuri ke kode program, demikian juga sebaliknya.

Mekanisme Umum dalam UML (1) ● Specification – Setiap notasi grafik UML memiliki spefisikasi

Mekanisme Umum dalam UML (1) ● Specification – Setiap notasi grafik UML memiliki spefisikasi yang merupakan pernyataan sintak dan semantiknya ● Adornment – Setiap elemen dalam UML memiliki notasi grafik unik yang menyediakan visualisasi aspek penting dari elemen yang bersangkutan ● Common Division – Pembagian antara class dan object – Pemisahan antara interface dan implementasinya

● Extensibility Mechanism – Stereotype ● Memperluas kamus kata UML, yang memungkinkan kita membangun

● Extensibility Mechanism – Stereotype ● Memperluas kamus kata UML, yang memungkinkan kita membangun blok yang diturunkan dari yang sudah ada namun khusus untuk masalah yang ada. Contoh: Exception pada Java/C++ yang sebetulnya sebuah class yang memiliki fungsi khusus. – Tagged Value ● Memperluas informasi dari spesifikasi elemen – Constraint ● Memperluas semantik dari blok UML yang dibangun

� SELESAI

� SELESAI